From dd6488cbb96a276303e47e7c515c988b0f3b1859 Mon Sep 17 00:00:00 2001
From: Jean-Noel Avila <jn.avila@free.fr>
Date: Fri, 30 Aug 2013 23:07:34 +0200
Subject: [PATCH 001/690] enable parallel check of languages

Use parallel to spawn as many subprocesses as possible to accelerate
the tests.
---
 Gemfile  |   2 +-
 Rakefile | 127 ++++++++++++++++++++++++++++++++++---------------------
 2 files changed, 80 insertions(+), 49 deletions(-)

diff --git a/Gemfile b/Gemfile
index 79f6c3029..aa6b79223 100644
--- a/Gemfile
+++ b/Gemfile
@@ -2,4 +2,4 @@ source 'https://rubygems.org'
 
 gem 'maruku', '0.6.1'
 gem 'redcarpet'
-gem 'rdiscount'
+gem 'parallel'
diff --git a/Rakefile b/Rakefile
index 03c0bb9e7..836f5044b 100644
--- a/Rakefile
+++ b/Rakefile
@@ -168,7 +168,78 @@ class StderrDecorator
   end
 end
 
+def test_lang(lang)
+  error_code = false
+  chapter_figure = {
+    "01-introduction"       => 7,
+    "02-git-basics"         => 2,
+    "03-git-branching"      => 39,
+    "04-git-server"         => 15,
+    "05-distributed-git"    => 27,
+    "06-git-tools"          => 1,
+    "07-customizing-git"    => 3,
+    "08-git-and-other-scms" => 0,
+    "09-git-internals"      => 4}
+  mark = ''
+  source_files = FileList.new(File.join(lang, '0*', '*.markdown')).sort
+  source_files.each do |mk_filename|
+    mk_file = File.open(mk_filename, 'r') do |mk|
+      mark+= mk.read.encode("UTF-8")
+    end
+    src_file = File.open(mk_filename, 'r')
+    figure_count = 0
+    until src_file.eof?
+      line = src_file.readline
+      matches = line.match /^#/
+      if matches
+        if line.match /^(#+).*#[[:blank:]]+$/
+          print "\nBadly formatted title in #{mk_filename}: #{line}\n"
+          error_code = true
+        end
+      end
+      if line.match /^\s*Insert\s(.*)/
+        figure_count = figure_count + 1
+      end
+    end
+    # This extraction is a bit contorted, because the pl translation renamed
+    # the files, so the match is done on the directories.
+    tab_fig_count = chapter_figure[File.basename(File.dirname(mk_filename))]
+    expected_figure_count = tab_fig_count ? tab_fig_count:0
+    if figure_count > expected_figure_count
+      print "\nToo many figures declared in #{mk_filename}\n"
+      error_code = true
+    end
+  end
+  begin
+    require 'maruku'
+    code = Maruku.new(mark, :on_error => :raise, :error_stream => StderrDecorator.new)
+  rescue
+    print $!
+    error_code = true
+  end
+  error_code
+end
+
 namespace :ci do
+  desc "Parallel Continuous integration"
+  task :parallel_check do
+    require 'parallel'
+    langs = FileList.new('??')+FileList.new('??-??')
+    results = Parallel.map(langs) do |lang|
+      Rake::Task["ci:" +lang+"_check"].execute
+      0
+    end
+    fail "At least one language conversion failed" if results.any? { |result| result!=0}
+  end
+
+  (FileList.new('??')+FileList.new('??-??')).each do |lang|
+    desc "testing " + lang
+    task (lang+"_check").to_sym do
+      error_code = test_lang(lang)
+      fail "processing #{lang} KO\n" if error_code
+      print "processing #{lang} OK\n"
+      end
+  end
 
   desc "Continuous Integration"   
   task :check do
@@ -184,59 +255,19 @@ namespace :ci do
       end
       langs -= excluded_langs
     end
-    error_code = false
-    chapter_figure = {
-      "01-introduction"       => 7,
-      "02-git-basics"         => 2,
-      "03-git-branching"      => 39,
-      "04-git-server"         => 15,
-      "05-distributed-git"    => 27,
-      "06-git-tools"          => 1,
-      "07-customizing-git"    => 3,
-      "08-git-and-other-scms" => 0,
-      "09-git-internals"      => 4}
+    global_error_code = false
     langs.each do |lang|
       print "processing #{lang} "
-      mark = ''
-      source_files = FileList.new(File.join(lang, '0*', '*.markdown')).sort
-      source_files.each do |mk_filename|
-        mk_file = File.open(mk_filename, 'r') do |mk|
-          mark+= mk.read.encode("UTF-8")
-        end
-        src_file = File.open(mk_filename, 'r')
-        figure_count = 0
-        until src_file.eof?
-          line = src_file.readline
-          matches = line.match /^#/
-          if matches
-            if line.match /^(#+).*#[[:blank:]]+$/
-              print "\nBadly formatted title in #{mk_filename}: #{line}\n"
- 	      error_code = true
-            end
-          end
-          if line.match /^\s*Insert\s(.*)/
-            figure_count = figure_count + 1
-          end
-        end
-	# This extraction is a bit contorted, because the pl translation renamed
-	# the files, so the match is done on the directories.
-        tab_fig_count = chapter_figure[File.basename(File.dirname(mk_filename))]
-        expected_figure_count = tab_fig_count ? tab_fig_count:0
-        if figure_count > expected_figure_count
-          print "\nToo many figures declared in #{mk_filename}\n"
-          error_code = true
-        end
-      end
-      begin
-        code = Maruku.new(mark, :on_error => :raise, :error_stream => StderrDecorator.new)
-        print "OK\n"
-      rescue
+      error_code=test_lang(lang)
+      if error_code
         print "KO\n"
-        print $!
-        error_code = true
+      else
+        print "OK\n"
       end
+      global_error_code|=error_code
+
     end
-    fail "At least one language conversion failed" if error_code
+    fail "At least one language conversion failed" if global_error_code
   end
 
 end

From e36c02acad6d7fd7ab356f90842ad17ac1c3d9e8 Mon Sep 17 00:00:00 2001
From: Jean-Noel Avila <jn.avila@free.fr>
Date: Sun, 27 Oct 2013 11:50:11 +0100
Subject: [PATCH 002/690] Change Maruku check to fully functional mode

this is cleans up the code.
---
 Rakefile | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/Rakefile b/Rakefile
index 836f5044b..7d3039367 100644
--- a/Rakefile
+++ b/Rakefile
@@ -180,12 +180,8 @@ def test_lang(lang)
     "07-customizing-git"    => 3,
     "08-git-and-other-scms" => 0,
     "09-git-internals"      => 4}
-  mark = ''
   source_files = FileList.new(File.join(lang, '0*', '*.markdown')).sort
   source_files.each do |mk_filename|
-    mk_file = File.open(mk_filename, 'r') do |mk|
-      mark+= mk.read.encode("UTF-8")
-    end
     src_file = File.open(mk_filename, 'r')
     figure_count = 0
     until src_file.eof?
@@ -211,6 +207,8 @@ def test_lang(lang)
     end
   end
   begin
+    mark = (source_files.map{|mk_filename| File.open(mk_filename, 'r'){
+                |mk| mk.read.encode("UTF-8")}}).join('')
     require 'maruku'
     code = Maruku.new(mark, :on_error => :raise, :error_stream => StderrDecorator.new)
   rescue

From cc1d0d6ace74ea67222d5684997e2d6932c2748a Mon Sep 17 00:00:00 2001
From: Jean-Noel Avila <jn.avila@free.fr>
Date: Wed, 30 Oct 2013 22:44:32 +0100
Subject: [PATCH 003/690] Force output of Rake messages to stderr

---
 Rakefile | 39 ++++++++++++++++++++++++---------------
 1 file changed, 24 insertions(+), 15 deletions(-)

diff --git a/Rakefile b/Rakefile
index 7d3039367..8e8f9eac3 100644
--- a/Rakefile
+++ b/Rakefile
@@ -160,15 +160,19 @@ namespace :pdf do
 end
 
 class StderrDecorator
+  def initialize(out)
+    @out = out
+  end
+
   def <<(x)
-    $stderr<< "#{x}"
+    @out << "#{x}"
     if x.match /REXML/
       raise ""
     end
   end
 end
 
-def test_lang(lang)
+def test_lang(lang, out)
   error_code = false
   chapter_figure = {
     "01-introduction"       => 7,
@@ -189,7 +193,7 @@ def test_lang(lang)
       matches = line.match /^#/
       if matches
         if line.match /^(#+).*#[[:blank:]]+$/
-          print "\nBadly formatted title in #{mk_filename}: #{line}\n"
+          out<< "\nBadly formatted title in #{mk_filename}: #{line}\n"
           error_code = true
         end
       end
@@ -202,7 +206,7 @@ def test_lang(lang)
     tab_fig_count = chapter_figure[File.basename(File.dirname(mk_filename))]
     expected_figure_count = tab_fig_count ? tab_fig_count:0
     if figure_count > expected_figure_count
-      print "\nToo many figures declared in #{mk_filename}\n"
+      out << "\nToo many figures declared in #{mk_filename}\n"
       error_code = true
     end
   end
@@ -210,7 +214,7 @@ def test_lang(lang)
     mark = (source_files.map{|mk_filename| File.open(mk_filename, 'r'){
                 |mk| mk.read.encode("UTF-8")}}).join('')
     require 'maruku'
-    code = Maruku.new(mark, :on_error => :raise, :error_stream => StderrDecorator.new)
+    code = Maruku.new(mark, :on_error => :raise, :error_stream => StderrDecorator.new(out))
   rescue
     print $!
     error_code = true
@@ -218,22 +222,29 @@ def test_lang(lang)
   error_code
 end
 
+$out = $stdout
+
 namespace :ci do
   desc "Parallel Continuous integration"
   task :parallel_check do
     require 'parallel'
     langs = FileList.new('??')+FileList.new('??-??')
     results = Parallel.map(langs) do |lang|
-      Rake::Task["ci:" +lang+"_check"].execute
-      0
+      error_code = test_lang(lang, $out)
+      if error_code
+        print "processing #{lang} KO\n"
+      else
+        print "processing #{lang} OK\n"
+      end
+      error_code
     end
-    fail "At least one language conversion failed" if results.any? { |result| result!=0}
+    fail "At least one language conversion failed" if results.any?
   end
 
   (FileList.new('??')+FileList.new('??-??')).each do |lang|
     desc "testing " + lang
     task (lang+"_check").to_sym do
-      error_code = test_lang(lang)
+      error_code = test_lang(lang, $out)
       fail "processing #{lang} KO\n" if error_code
       print "processing #{lang} OK\n"
       end
@@ -253,19 +264,17 @@ namespace :ci do
       end
       langs -= excluded_langs
     end
-    global_error_code = false
-    langs.each do |lang|
+    errors = langs.each do |lang|
       print "processing #{lang} "
-      error_code=test_lang(lang)
+      error_code=test_lang(lang, $out)
       if error_code
         print "KO\n"
       else
         print "OK\n"
       end
-      global_error_code|=error_code
-
+      error_code
     end
-    fail "At least one language conversion failed" if global_error_code
+    fail "At least one language conversion failed" if errors.any?
   end
 
 end

From bdef6f762f3cc3652c142cc64aa2342f9e0da9da Mon Sep 17 00:00:00 2001
From: Daniel Rosen <skiasaurus@users.noreply.github.com>
Date: Mon, 16 Dec 2013 00:35:12 -0500
Subject: [PATCH 004/690] Monospace branch names

---
 en/03-git-branching/01-chapter3.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/en/03-git-branching/01-chapter3.markdown b/en/03-git-branching/01-chapter3.markdown
index 8924dbe5e..bf0028744 100644
--- a/en/03-git-branching/01-chapter3.markdown
+++ b/en/03-git-branching/01-chapter3.markdown
@@ -460,7 +460,7 @@ To set up a local branch with a different name than the remote branch, you can e
 	Branch sf set up to track remote branch refs/remotes/origin/serverfix.
 	Switched to a new branch "sf"
 
-Now, your local branch sf will automatically push to and pull from origin/serverfix.
+Now, your local branch `sf` will automatically push to and pull from `origin/serverfix`.
 
 ### Deleting Remote Branches ###
 

From 1ca5ef1602de99198882a0153b8c3f399317e76f Mon Sep 17 00:00:00 2001
From: Daniel Rosen <skiasaurus@users.noreply.github.com>
Date: Mon, 16 Dec 2013 13:53:24 -0500
Subject: [PATCH 005/690] Monospace branch names

---
 en/05-distributed-git/01-chapter5.markdown | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/en/05-distributed-git/01-chapter5.markdown b/en/05-distributed-git/01-chapter5.markdown
index 6bf3e1d49..839206022 100644
--- a/en/05-distributed-git/01-chapter5.markdown
+++ b/en/05-distributed-git/01-chapter5.markdown
@@ -174,7 +174,7 @@ John has a reference to the changes Jessica pushed up, but he has to merge them
 The merge goes smoothly — John’s commit history now looks like Figure 5-5.
 
 Insert 18333fig0505.png
-Figure 5-5. John’s repository after merging origin/master.
+Figure 5-5. John’s repository after merging `origin/master`.
 
 Now, John can test his code to make sure it still works properly, and then he can push his new merged work up to the server:
 
@@ -215,7 +215,7 @@ Jessica thinks her topic branch is ready, but she wants to know what she has to
 
 	    removed invalid default value
 
-Now, Jessica can merge her topic work into her master branch, merge John’s work (`origin/master`) into her `master` branch, and then push back to the server again. First, she switches back to her master branch to integrate all this work:
+Now, Jessica can merge her topic work into her `master` branch, merge John’s work (`origin/master`) into her `master` branch, and then push back to the server again. First, she switches back to her `master` branch to integrate all this work:
 
 	$ git checkout master
 	Switched to branch "master"
@@ -255,7 +255,7 @@ Each developer has committed a few times and merged each other’s work successf
 Insert 18333fig0510.png
 Figure 5-10. Jessica’s history after pushing all changes back to the server.
 
-That is one of the simplest workflows. You work for a while, generally in a topic branch, and merge into your master branch when it’s ready to be integrated. When you want to share that work, you merge it into your own master branch, then fetch and merge `origin/master` if it has changed, and finally push to the `master` branch on the server. The general sequence is something like that shown in Figure 5-11.
+That is one of the simplest workflows. You work for a while, generally in a topic branch, and merge into your `master` branch when it’s ready to be integrated. When you want to share that work, you merge it into your own `master` branch, then fetch and merge `origin/master` if it has changed, and finally push to the `master` branch on the server. The general sequence is something like that shown in Figure 5-11.
 
 Insert 18333fig0511.png
 Figure 5-11. General sequence of events for a simple multiple-developer Git workflow.

From 2a0a8371ed727a2f536fa3a51d14201de97540ca Mon Sep 17 00:00:00 2001
From: Chris Down <chris@chrisdown.name>
Date: Fri, 3 Jan 2014 16:34:54 +0800
Subject: [PATCH 006/690] Note that, when locally copying, the hardlinked files
 are the objects

Previously it was possible to infer from this sentence that the actual
work tree was hard linked, but it is the Git objects that are
hard linked. This makes the passage much less ambiguous.
---
 en/04-git-server/01-chapter4.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/en/04-git-server/01-chapter4.markdown b/en/04-git-server/01-chapter4.markdown
index af7665115..ec3f415a4 100644
--- a/en/04-git-server/01-chapter4.markdown
+++ b/en/04-git-server/01-chapter4.markdown
@@ -26,7 +26,7 @@ Or you can do this:
 
 	$ git clone file:///opt/git/project.git
 
-Git operates slightly differently if you explicitly specify `file://` at the beginning of the URL. If you just specify the path, Git tries to use hardlinks or directly copy the files it needs. If you specify `file://`, Git fires up the processes that it normally uses to transfer data over a network which is generally a lot less efficient method of transferring the data. The main reason to specify the `file://` prefix is if you want a clean copy of the repository with extraneous references or objects left out — generally after an import from another version-control system or something similar (see Chapter 9 for maintenance tasks). We’ll use the normal path here because doing so is almost always faster.
+Git operates slightly differently if you explicitly specify `file://` at the beginning of the URL. If you just specify the path, and the source and the destination are on the same filesystem, Git tries to hardlink the objects it needs. If they are not on the same filesystem, it will copy the objects it needs using the system's standard copying functionality. If you specify `file://`, Git fires up the processes that it normally uses to transfer data over a network which is generally a lot less efficient method of transferring the data. The main reason to specify the `file://` prefix is if you want a clean copy of the repository with extraneous references or objects left out — generally after an import from another version-control system or something similar (see Chapter 9 for maintenance tasks). We’ll use the normal path here because doing so is almost always faster.
 
 To add a local repository to an existing Git project, you can run something like this:
 

From 83a4198d37f28a782d0e1306b73fcca391ea3589 Mon Sep 17 00:00:00 2001
From: Ralph Haussmann <ralph@scanmyfood.de>
Date: Thu, 2 Jan 2014 19:28:05 +0100
Subject: [PATCH 007/690] [de] First translation of chapter 6.6 (submodules)

---
 de/06-git-tools/01-chapter6.markdown | 70 ++++++++++++++++++++++++++++
 de/README.md                         |  4 +-
 2 files changed, 72 insertions(+), 2 deletions(-)

diff --git a/de/06-git-tools/01-chapter6.markdown b/de/06-git-tools/01-chapter6.markdown
index 3f1726928..f928356ac 100644
--- a/de/06-git-tools/01-chapter6.markdown
+++ b/de/06-git-tools/01-chapter6.markdown
@@ -1104,14 +1104,23 @@ Wenn Du die untere, genannte Zeile ausführst, führt Git automatisch nach jedem
 
 <!--It often happens that while working on one project, you need to use another project from within it. Perhaps it’s a library that a third party developed or that you’re developing separately and using in multiple parent projects. A common issue arises in these scenarios: you want to be able to treat the two projects as separate yet still be able to use one from within the other.-->
 
+Oft möchte man während der Arbeit an einem Projekt ein weiteres Projekt darin einbinden und verwenden. Das kann zum Beispiel eine Bibliothek von einer anderen Firma oder vielleicht auch eine selbstentwickelte Bibliothek sein. In einem solchen Szenario tritt dann meistens folgendes Problem auf: Die zwei Projekte sollen unabhängig voneinander entwickelt werden können, aber trotzdem soll es möglich sein, das eine Projekt im anderen zu verwenden.
+
 <!--Here’s an example. Suppose you’re developing a web site and creating Atom feeds. Instead of writing your own Atom-generating code, you decide to use a library. You’re likely to have to either include this code from a shared library like a CPAN install or Ruby gem, or copy the source code into your own project tree. The issue with including the library is that it’s difficult to customize the library in any way and often more difficult to deploy it, because you need to make sure every client has that library available. The issue with vendoring the code into your own project is that any custom changes you make are difficult to merge when upstream changes become available.-->
 
+Dazu ein Beispiel. Nehmen wir an, Du entwickelt gerade eine Webseite, die unter anderem einen Atom-Feed zur Verfügung stellen soll. Anstatt den notwendigen Code zur Auslieferung des Atom-Feeds selber zu schreiben, entscheidest Du Dich für eine geeignete Bibliothek. Dann wirst Du wahrscheinlich den Code in Dein Projekt inkludieren müssen, zum Beispiel durch eine CPAN Installation oder Ruby gem oder durch Kopieren des Quellcodes in das Arbeitsverzeichnis Deines Projekts. Das Problem beim Einbinden einer Bibliothek ist, dass es schwierig ist, diese an die eigene Bedürfnisse anzupassen. Noch schwieriger gestaltet sich dann die Veröffentlichung des Projekts, da man sicherstellen muss, dass jeder der die Software verwendet, auf die Bibliothek zugreifen kann. Wenn man die Bibliothek im eigenen Projekt projektspezifisch anpasst, hat man meist ein Problem, wenn man eine neue Version der Bibliothek einspielen will.
+
 <!--Git addresses this issue using submodules. Submodules allow you to keep a Git repository as a subdirectory of another Git repository. This lets you clone another repository into your project and keep your commits separate.-->
 
+Git löst dieses Problem mit Hilfe von Submodulen. Mit Hilfe von Submodulen kann man innerhalb eines Git Repositorys ein weiteres Git Repository in einem Unterverzeichnis verwalten. Daraus entsteht der Vorteil, dass man ein anderes Repository in das eigene Projekt klonen kann und die Commits der jeweiligen Projekte trennen kann.
+
 <!--### Starting with Submodules ###-->
+### Die ersten Schritte mit Submodulen ###
 
 <!--Suppose you want to add the Rack library (a Ruby web server gateway interface) to your project, possibly maintain your own changes to it, but continue to merge in upstream changes. The first thing you should do is clone the external repository into your subdirectory. You add external projects as submodules with the `git submodule add` command:-->
 
+Nehmen wir einmal an, dass Du die Rack Bibliothek (eine Ruby Gateway Schnittstelle für Webserver) zu Deinem Projekt hinzufügen willst. Dabei möchtest Du Deine eigenen Änderungen an dieser Bibliothek nachverfolgen, aber auch weiterhin Änderungen von den Rack Bibliothek-Entwicklern verwalten und zusammenmergen. Das erste was Du dazu tun musst, ist das Repository der Rack Bibliothek in ein Unterverzeichnis Deines Projekts zu klonen. Diesen Vorgang kannst Du mit Hilfe des Befehls `git submodule add` ausführen:
+
 	$ git submodule add git://github.com/chneukirchen/rack.git rack
 	Initialized empty Git repository in /opt/subtest/rack/.git/
 	remote: Counting objects: 3181, done.
@@ -1122,6 +1131,8 @@ Wenn Du die untere, genannte Zeile ausführst, führt Git automatisch nach jedem
 
 <!--Now you have the Rack project under a subdirectory named `rack` within your project. You can go into that subdirectory, make changes, add your own writable remote repository to push your changes into, fetch and merge from the original repository, and more. If you run `git status` right after you add the submodule, you see two things:-->
 
+Innerhalb Deines Projekts befindet sich nun im Unterverzeichnis `rack` das komplette Rack-Projekt. Man kann jetzt in diesem Verzeichnis Änderungen vornehmen und ein eigenes Remote Repository mit Schreibrechten, zu welchem man pushen kann, hinzufügen. Ebenso ist es möglich, Änderungen von den Rack Entwicklern in sein Repository zu laden und diese mit den eigenen Ergebnissen zu mergen. Im Prinzip kann man innerhalb eines Submoduls die gleichen Vorgänge, wie in einem normalen Repository ausführen. Vorher müssen wir aber noch ein paar weitere Dinge zu Submodulen besprechen. Wenn Du gleich nach dem Hinzufügen des Submoduls, den Befehl `git status` ausführst, wirst Du gleich zwei Dinge bemerken: 
+
 	$ git status
 	# On branch master
 	# Changes to be committed:
@@ -1133,6 +1144,8 @@ Wenn Du die untere, genannte Zeile ausführst, führt Git automatisch nach jedem
 
 <!--First you notice the `.gitmodules` file. This is a configuration file that stores the mapping between the project’s URL and the local subdirectory you’ve pulled it into:-->
 
+Als erstes wird Dir die neue Datei `.gitmodules` auffallen. Das ist eine Konfigurationsdatei, welche die Zuordnung der URL des geklonten Projekts und dem lokalen Unterverzeichnis, in welches das Projekt geklont wurde, festlegt:
+
 	$ cat .gitmodules
 	[submodule "rack"]
 	      path = rack
@@ -1140,8 +1153,12 @@ Wenn Du die untere, genannte Zeile ausführst, führt Git automatisch nach jedem
 
 <!--If you have multiple submodules, you’ll have multiple entries in this file. It’s important to note that this file is version-controlled with your other files, like your `.gitignore` file. It’s pushed and pulled with the rest of your project. This is how other people who clone this project know where to get the submodule projects from.-->
 
+Wenn Du mehrere Submodule in einem Projekt verwaltest, werden auch mehrere Einträge in dieser Datei auftauchen. Dabei ist es wichtig zu wissen, dass diese Datei zusammen mit all den anderen Dateien aus Deinem Projekt, ebenso in die Versionskontrolle aufgenommen wird, ähnlich wie die Datei `.gitignore`. Die Datei wird so wie der Rest Deines Projekts gepusht und gepullt. Dadurch wissen andere Personen, die Dein Projekt klonen, von welchem Ort sie die Submodule erhalten können.
+
 <!--The other listing in the `git status` output is the rack entry. If you run `git diff` on that, you see something interesting:-->
 
+Die zweite Auffälligkeit bei der Ausgabe von `git status` ist der Eintrag rack. Wenn Du auf diesen Eintrag ein `git diff` durchführst, erhält man in etwa die folgende, interessante Ausgabe:
+
 	$ git diff --cached rack
 	diff --git a/rack b/rack
 	new file mode 160000
@@ -1153,10 +1170,16 @@ Wenn Du die untere, genannte Zeile ausführst, führt Git automatisch nach jedem
 
 <!--Although `rack` is a subdirectory in your working directory, Git sees it as a submodule and doesn’t track its contents when you’re not in that directory. Instead, Git records it as a particular commit from that repository. When you make changes and commit in that subdirectory, the superproject notices that the HEAD there has changed and records the exact commit you’re currently working off of; that way, when others clone this project, they can re-create the environment exactly.-->
 
+Obwohl `rack` ein Unterverzeichnis in Deinem Arbeitsverzeichnis ist, erkennt Git dieses Verzeichnis als Submodul und verfolgt die Änderungen innerhalb dieses Verzeichnis nicht, wenn Git nicht innerhalb dieses Verzeichnis aufgerufen wird. Stattdessen erfässt Git welcher Commit in diesem Repository ausgecheckt ist. Wenn Du also Änderungen in diesem Unterverzeichnis durchführst und eincheckst, kann das Superprojekt erkennen, dass sich der aktuelle HEAD von diesem Projekt geändert hat. Das Superprojekt kann sich jetzt diesen Commit merken. Auf diese Art und Weise ist es möglich den kompletten Zustand des Projekts mit allen Projekten, die als Submodul hinzugefügt wurden, zu reproduzieren. In der Git Terminologie wird das Projekt, welches eines oder mehrere Submodule enthält, als Superprojekt bezeichnet.
+
 <!--This is an important point with submodules: you record them as the exact commit they’re at. You can’t record a submodule at `master` or some other symbolic reference.-->
 
+Dabei muss man sich folgender Eigenschaft bewusst sein: Git verwaltet den exakten Commit, der gerade ausgecheckt ist und nicht etwa den Branch oder eine andere Referenz. Git kann also zum Beispiel nicht speichern, dass der aktuelle Stand im Branch `master` enthalten ist. 
+
 <!--When you commit, you see something like this:-->
 
+Wenn Du Dein Projekt das erste mal eincheckst, erhälst Du in etwa folgende Ausgabe:
+
 	$ git commit -m 'first commit with submodule rack'
 	[master 0550271] first commit with submodule rack
 	 2 files changed, 4 insertions(+), 0 deletions(-)
@@ -1165,8 +1188,12 @@ Wenn Du die untere, genannte Zeile ausführst, führt Git automatisch nach jedem
 
 <!--Notice the 160000 mode for the rack entry. That is a special mode in Git that basically means you’re recording a commit as a directory entry rather than a subdirectory or a file.-->
 
+Der Mode 160000, der für den rack Eintrag gilt, ist ein spezieller Mode in Git. Er bedeutet in etwa, dass man einen Commit als Verzeichnis-Eintrag in Git verwaltet und damit nicht wie normalerweise ein Verzeichnis oder eine Datei.  
+
 <!--You can treat the `rack` directory as a separate project and then update your superproject from time to time with a pointer to the latest commit in that subproject. All the Git commands work independently in the two directories:-->
 
+Das Verzeichnis `rack` kann man wie ein separates Projekt behandeln und verwenden. Und von Zeit zur Zeit aktualisiert man auch das Superprojekt und speichert damit die letzte Commit Id des Unterprojekts. Jedes Git Kommando arbeitet unabhängig in einem der beiden Unterverzeichnisse:
+
 	$ git log -1
 	commit 0550271328a0038865aad6331e620cd7238601bb
 	Author: Scott Chacon <schacon@gmail.com>
@@ -1182,9 +1209,12 @@ Wenn Du die untere, genannte Zeile ausführst, führt Git automatisch nach jedem
 	    Document version change
 
 <!--### Cloning a Project with Submodules ###-->
+### Klonen eines Projekts mit den dazugehörigen Submodulen ###
 
 <!--Here you’ll clone a project with a submodule in it. When you receive such a project, you get the directories that contain submodules, but none of the files yet:-->
 
+Als nächstes klonen wir ein Projekt, welches ein Submodul verwendet. Wenn man ein solches Projekt klont, werden die entsprechenden Verzeichnisse, welche ein Submodul enthalten, erstellt. Allerdings enthalten diese Verzeichnisse noch keinen Inhalt:
+
 	$ git clone git://github.com/schacon/myproject.git
 	Initialized empty Git repository in /opt/myproject/.git/
 	remote: Counting objects: 6, done.
@@ -1201,6 +1231,8 @@ Wenn Du die untere, genannte Zeile ausführst, führt Git automatisch nach jedem
 
 <!--The `rack` directory is there, but empty. You must run two commands: `git submodule init` to initialize your local configuration file, and `git submodule update` to fetch all the data from that project and check out the appropriate commit listed in your superproject:-->
 
+Das Verzeichnis `rack` wurde zwar erzeugt, aber es ist leer. Deshalb musst Du zwei Dinge ausführen: `git submodule init`, damit wird die Datei für die lokale Konfiguration initiailisiert. Und `git submodule update`, welches die gesamten Daten des Projekts von der im `.gitmodules` angegebenen Quelle holt und den entsprechenden Commit, welcher im Superprojekt hinterlegt ist, auscheckt:
+
 	$ git submodule init
 	Submodule 'rack' (git://github.com/chneukirchen/rack.git) registered for path 'rack'
 	$ git submodule update
@@ -1214,6 +1246,8 @@ Wenn Du die untere, genannte Zeile ausführst, führt Git automatisch nach jedem
 
 <!--Now your `rack` subdirectory is at the exact state it was in when you committed earlier. If another developer makes changes to the rack code and commits, and you pull that reference down and merge it in, you get something a bit odd:-->
 
+Nach Ausführung der beiden Befehle befindet sich das Verzeichnis `rack` in genau dem gleichen Zustand, wie wir es ursprünglich eingecheckt haben. Wenn ein anderer Entwickler Änderungen am Rack Code durchführt, diese eincheckt und Du diese dann pullst und mergst, erhält man einen etwas seltsamen Zustand:  
+
 	$ git merge origin/master
 	Updating 0550271..85a3eee
 	Fast forward
@@ -1230,6 +1264,8 @@ Wenn Du die untere, genannte Zeile ausführst, führt Git automatisch nach jedem
 
 <!--You merged in what is basically a change to the pointer for your submodule; but it doesn’t update the code in the submodule directory, so it looks like you have a dirty state in your working directory:-->
 
+Der Merge, der gerade durchgeführt worden ist, ist eigentlich nur eine Aktualisierung des Zeigers auf einen neuen Commit des Submoduls. Der eigentliche Inhalt des Submodul-Verzeichnis wurde allerdings nicht aktualisiert. Das sieht dann so aus, als gäbe es noch nicht eingecheckte Dateien innerhalb Deines Arbeitsverzeichnis:
+
 	$ git diff
 	diff --git a/rack b/rack
 	index 6c5e70b..08d709f 160000
@@ -1241,6 +1277,8 @@ Wenn Du die untere, genannte Zeile ausführst, führt Git automatisch nach jedem
 
 <!--This is the case because the pointer you have for the submodule isn’t what is actually in the submodule directory. To fix this, you must run `git submodule update` again:-->
 
+Dieser Zustand tritt auf, weil der Zeiger auf den Commit im Submodul derzeit nicht der Commit ist, welcher im Submodul ausgecheckt ist. Um dies zu beheben, muss man den Befehl `git submodule update` erneut ausführen:
+
 	$ git submodule update
 	remote: Counting objects: 5, done.
 	remote: Compressing objects: 100% (3/3), done.
@@ -1252,14 +1290,20 @@ Wenn Du die untere, genannte Zeile ausführst, führt Git automatisch nach jedem
 
 <!--You have to do this every time you pull down a submodule change in the main project. It’s strange, but it works.-->
 
+Dieser Update muss jedes mal ausgeführt werden, wenn man das Superprojekt pullt und dort ein Änderung in einem Submodul enthalten ist. Es ist vielleicht ein wenig merkwürdig, aber es funktioniert.
+
 <!--One common problem happens when a developer makes a change locally in a submodule but doesn’t push it to a public server. Then, they commit a pointer to that non-public state and push up the superproject. When other developers try to run `git submodule update`, the submodule system can’t find the commit that is referenced, because it exists only on the first developer’s system. If that happens, you see an error like this:-->
 
+Häufig tritt beim Arbeiten mit Submodulen ein Problem bei folgendem Szenario auf: Ein Entwickler führt Änderungen in einem Submodul durch, checkt diese ein, vergisst aber diese Änderungen zum zentralen Server zu pushen. Wenn dann im Superprojekt die Änderung des Submoduls ebenso eingecheckt wird und dieses dann gepusht wird, tritt ein Problem auf. Wenn jetzt andere Entwickler den neuen Stand des Superprojekts holen und den Befehl `git submodule update` ausführen, erhalten sie eine Fehlermeldung, dass der entsprechend referenzierte Commit von dem Submodul nicht gefunden werden konnte. Das passiert weil dieser Commit bei dem zweiten Entwickler noch gar nicht existiert. Wenn ein solcher Fall auftritt, erhält man in etwa folgende Fehlermeldung:  
+
 	$ git submodule update
 	fatal: reference isn’t a tree: 6c5e70b984a60b3cecd395edd5b48a7575bf58e0
 	Unable to checkout '6c5e70b984a60b3cecd395edd5ba7575bf58e0' in submodule path 'rack'
 
 <!--You have to see who last changed the submodule:-->
 
+Dann kann man allerdings herausfinden, wer zum letzten mal eine Änderung eingecheckt hat:
+
 	$ git log -1 rack
 	commit 85a3eee996800fcfa91e2119372dd4172bf76678
 	Author: Scott Chacon <schacon@gmail.com>
@@ -1269,20 +1313,34 @@ Wenn Du die untere, genannte Zeile ausführst, führt Git automatisch nach jedem
 
 <!--Then, you e-mail that guy and yell at him.-->
 
+Dann kannst Du diesem Entwickler eine E-Mail schreiben und ihn auf seinen Fehler aufmerksam machen.
+
 <!--### Superprojects ###-->
+### Superprojekte ###
 
 <!--Sometimes, developers want to get a combination of a large project’s subdirectories, depending on what team they’re on. This is common if you’re coming from CVS or Subversion, where you’ve defined a module or collection of subdirectories, and you want to keep this type of workflow.-->
 
+In manchen großen Projekten möchten die Entwickler die Arbeit in verschiedenen Verzeichnissen aufteilen, sodass das jeweilige Team in diesen Verzeichnissen arbeiten kann. Man trifft diese Vorgehensweise häufig an, wenn ein Team gerade von CVS oder Subversion nach Git gewechselt hat, im alten System ein Modul oder eine Sammlung von solchen Unterverzeichnissen gebildet hat und diesen Arbeitsablauf weiterhin verwenden möchte.
+
 <!--A good way to do this in Git is to make each of the subfolders a separate Git repository and then create superproject Git repositories that contain multiple submodules. A benefit of this approach is that you can more specifically define the relationships between the projects with tags and branches in the superprojects.-->
 
+In Git kann man diese Vorgehensweise gut abbilden, indem man für jedes Unterverzeichnis ein neues Git Repository erzeugt. Zusätzlich kann man dann ein Superprojekt erzeugen und die ganzen Git Repositorys als Submodul hinzufügen.  Ein Vorteil dabei ist, dass man mit Hilfe von Tags und Branches im Superprojekt das Verhältnis der einzelnen Submodule zueinander festhalten kann.
+
 <!--### Issues with Submodules ###-->
+### Häufige Probleme mit Submodulen ###
 
 <!--Using submodules isn’t without hiccups, however. First, you must be relatively careful when working in the submodule directory. When you run `git submodule update`, it checks out the specific version of the project, but not within a branch. This is called having a detached HEAD — it means the HEAD file points directly to a commit, not to a symbolic reference. The issue is that you generally don’t want to work in a detached HEAD environment, because it’s easy to lose changes. If you do an initial `submodule update`, commit in that submodule directory without creating a branch to work in, and then run `git submodule update` again from the superproject without committing in the meantime, Git will overwrite your changes without telling you.  Technically you won’t lose the work, but you won’t have a branch pointing to it, so it will be somewhat difficult to retrieve.-->
 
+Die Arbeit mit Submodulen verläuft jedoch nicht immer reibungslos. Man muss verhältnismäßig gut aufpassen, wenn man in einem Submodul-Verzeichnis arbeitet. Wenn man nämlich den Befehl `git submodule update` ausführt, checkt Git den entsprechenden Zustand des Commits aus, aber checkt dabei keinen Branch aus. Diesen Zustand nennt man auch `detached HEAD`. Das bedeutet das die Datei HEAD direkt auf einen Commit zeigt und nicht wie sonst üblich auf eine symbolische Referenz, also zum Beispiel auf einen Branch. Das Problem dabei ist, dass man normalerweise in einem solchen Zustand nicht weiterarbeiten möchte, weil es sehr leicht vorkommen kann, dass Änderungen verloren gehen. Wenn man also den Befehl `git submodule update` aufruft, dann einen Commit in dem entsprechenden Submodul-Verzeichnis ausführt, ohne davor einen Branch auszuchecken, und dann noch einmal `git submodule update` im Superprojekt aufruft, ohne dass man die Änderungen im Submodul im Superprojekt eingecheckt hat, verliert man die ganzen Änderungen, ohne das Git einen darauf vorher hinweist. Tatsächlich ist es so, dass die Änderungen nicht verloren gehen, aber es gibt keinen Branch der auf die entsprechenden Commits hinzeigt und damit kann es schwierig werden die entsprechenden Commits wiederherzustellen beziehungsweise sichtbar zu machen. 
+
 <!--To avoid this issue, create a branch when you work in a submodule directory with `git checkout -b work` or something equivalent. When you do the submodule update a second time, it will still revert your work, but at least you have a pointer to get back to.-->
 
+Um dieses Problem zu vermeiden, sollte man also immer in dem Submodul-Verzeichnis einen neuen Branch mit `git checkout -b work` oder auf eine andere Art und Weise erzeugen. Wenn man dann wieder das Aktualisieren des Submoduls ausführt, wird Git wieder den ursprünglichen Commit auschecken, allerdings hat man jetzt mit dem Branch einen Zeiger auf die neuen Commits und man kann sie leicht wieder auschecken.
+
 <!--Switching branches with submodules in them can also be tricky. If you create a new branch, add a submodule there, and then switch back to a branch without that submodule, you still have the submodule directory as an untracked directory:-->
 
+Wenn ein Projekt ein Submodul enthält und man im Superprojekt zwischen einzelnen Branches hin und her wechseln möchte, kann sich das manchmal auch schwierig gestalten. Wenn man zum Beispiel einen neuen Branch erzeugt, in diesem dann ein Submodul hinzufügt und dann wieder in den ursprünglichen Branch, welcher das Submodul noch nicht enthält, zurückwechselt, hat man im Arbeitsverzeichnis immer noch das Submodul-Verzeichnis, welches auch so dargestellt wird, als ob es von Git noch nicht verfolgt wird:
+
 	$ git checkout -b rack
 	Switched to a new branch "rack"
 	$ git submodule add git@github.com:schacon/rack.git rack
@@ -1306,14 +1364,20 @@ Wenn Du die untere, genannte Zeile ausführst, führt Git automatisch nach jedem
 
 <!--You have to either move it out of the way or remove it, in which case you have to clone it again when you switch back—and you may lose local changes or branches that you didn’t push up.-->
 
+In diesem Fall muss man das Verzeichnis entweder an einen anderen Ort verschieben oder löschen. Im letzteren Fall muss man aber wieder das Submodul komplett klonen, wenn man in den anderen Zweig zurückwechselt. Außerdem kann man dabei lokale Änderungen zu nichte machen oder Zweige, welche man noch nicht gepusht hat, verlieren.
+
 <!--The last main caveat that many people run into involves switching from subdirectories to submodules. If you’ve been tracking files in your project and you want to move them out into a submodule, you must be careful or Git will get angry at you. Assume that you have the rack files in a subdirectory of your project, and you want to switch it to a submodule. If you delete the subdirectory and then run `submodule add`, Git yells at you:-->
 
+Die letzte Falle in die viele Leute tappen, tritt auf, wenn man bereits vorhandene Verzeichnisse in Submodule umwandeln will. Wenn man also Dateien, die bereits von Git verwaltet werden, entfernen und in ein entsprechendes Submodul verschieben möchte, muss man vorsichtig sein. Ansonsten können schwer zu behebende Probleme mit Git auftreten. Nehmen wir zum Beispiel an, dass Du die Dateien vom Rack Projekt in ein Unterverzeichnis Deines Projekts abgelegt hast und diese jetzt aber in ein Submodul verschieben möchtest. Wenn Du das Unterverzeichnis einfach löschst und dann den Befehl `submodule add` ausführst, zeigt dir Git folgende Fehlermeldung an:  
+
 	$ rm -Rf rack/
 	$ git submodule add git@github.com:schacon/rack.git rack
 	'rack' already exists in the index
 
 <!--You have to unstage the `rack` directory first. Then you can add the submodule:-->
 
+Man muss dann das Verzeichnis `rack` erst aus der Staging Area entfernen. Danach kann man dann das Submodul erzeugen:
+
 	$ git rm -r rack
 	$ git submodule add git@github.com:schacon/rack.git rack
 	Initialized empty Git repository in /opt/testsub/rack/.git/
@@ -1325,11 +1389,15 @@ Wenn Du die untere, genannte Zeile ausführst, führt Git automatisch nach jedem
 
 <!--Now suppose you did that in a branch. If you try to switch back to a branch where those files are still in the actual tree rather than a submodule — you get this error:-->
 
+Wenn wir jetzt annehmen, dass Du diesen Vorgang innerhalb eines Zweigs durchgeführt hast und jetzt auf einen anderen Zweig, in dem das Submodul noch nicht existiert hat und damit die Dateien noch ganz normal im Repository enthalten waren, wechselst, erhält Du folgenden Fehler:
+
 	$ git checkout master
 	error: Untracked working tree file 'rack/AUTHORS' would be overwritten by merge.
 
 <!--You have to move the `rack` submodule directory out of the way before you can switch to a branch that doesn’t have it:-->
 
+Dann musst Du das Submodul-Verzeichnis `rack` an einen anderen Ort verschieben, bevor Du diesen Branch auschecken kannst:
+
 	$ mv rack /tmp/
 	$ git checkout master
 	Switched to branch "master"
@@ -1338,6 +1406,8 @@ Wenn Du die untere, genannte Zeile ausführst, führt Git automatisch nach jedem
 
 <!--Then, when you switch back, you get an empty `rack` directory. You can either run `git submodule update` to reclone, or you can move your `/tmp/rack` directory back into the empty directory.-->
 
+Wenn man dann wieder in den Zweig mit dem Submodul zurückwechseln will, erhält man ein leeres Verzeichnis `rack`. Um dieses zu befüllen, kannst du entweder `git submodule update` ausführen oder Du kannst Deine Kopie von `/tmp/rack` wieder an den ursprünglichen Ort wiederherstellen.
+
 <!--## Subtree Merging ##-->
 ## Subtree Merging ##
 
diff --git a/de/README.md b/de/README.md
index e5774f6d9..d9e8abcad 100644
--- a/de/README.md
+++ b/de/README.md
@@ -418,10 +418,10 @@ Bitte den Status nicht aktualisieren. Dies übernimmt ein Maintainer.
 </tr>
 <tr>
 <td>6.6</td>
-<td>Nein</td>
+<td>Ja</td>
 <td>Nein</td>
 <td>Ja</td>
-<td bgcolor="red">Übersetzung fehlt</td>
+<td bgcolor="yellow">Review notwendig</td>
 </tr>
 <tr>
 <td>6.7</td>

From 81d9ebed352637ff3390f11034cb5119014916e4 Mon Sep 17 00:00:00 2001
From: Jean-Noel Avila <jean-noel.avila@scantech.fr>
Date: Fri, 3 Jan 2014 13:16:29 +0100
Subject: [PATCH 008/690] [fr] update README to bypass progit-fr

Now the french translation's fixup don't need a specific repo. Just
use the main repo for forking and submitting.
---
 fr/README.md | 8 +++-----
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/fr/README.md b/fr/README.md
index 75cf1f4f3..4e8bfe586 100644
--- a/fr/README.md
+++ b/fr/README.md
@@ -2,10 +2,8 @@
 
 ## Dépôt de référence ##
 
-Le dépot de référence de la traduction française est situé ici :
-https://github.com/progit-fr/progit
-
-C'est le dépôt de fusion des travaux sur la branche fr, avant de lancer les requêtes de tirage sur le dépôt principal Progit.
+Comme le mainteneur des traductions du livre est français, le dépot de référence de la traduction française est situé ici.
+https://github.com/progit/progit
 
 ## Liste de diffusion ##
 
@@ -15,7 +13,7 @@ Si vous travaillez ou souhaitez travailler sur la traduction française de Progi
 
 ## Workflow ##
 
-Pour simplifier la gestion et utiliser pleinement les capacités de Git et Github, la manière la plus directe de collaborer consiste à faire un fork sur Github du dépôt progit-fr/progit sur votre propre compte pour y générer vos modifications, si possible sur une branche thématique.
+Pour simplifier la gestion et utiliser pleinement les capacités de Git et Github, la manière la plus directe de collaborer consiste à faire un fork sur Github du dépôt progit/progit sur votre propre compte pour y générer vos modifications, si possible sur une branche thématique.
 
 Ensuite, il suffit de lancer une requête de tirage pour nous avertir que les modifications peuvent être revues et intégrées.
 

From fab4c1ed65d96f848cd3298738944d364960e3b9 Mon Sep 17 00:00:00 2001
From: Ralph Haussmann <ralph@scanmyfood.de>
Date: Fri, 3 Jan 2014 17:42:11 +0100
Subject: [PATCH 009/690] [de] First translation of chapter 6.7 (subtree-merge)

---
 de/06-git-tools/01-chapter6.markdown | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)

diff --git a/de/06-git-tools/01-chapter6.markdown b/de/06-git-tools/01-chapter6.markdown
index f928356ac..e266f393e 100644
--- a/de/06-git-tools/01-chapter6.markdown
+++ b/de/06-git-tools/01-chapter6.markdown
@@ -1413,12 +1413,20 @@ Wenn man dann wieder in den Zweig mit dem Submodul zurückwechseln will, erhält
 
 <!--Now that you’ve seen the difficulties of the submodule system, let’s look at an alternate way to solve the same problem. When Git merges, it looks at what it has to merge together and then chooses an appropriate merging strategy to use. If you’re merging two branches, Git uses a _recursive_ strategy. If you’re merging more than two branches, Git picks the _octopus_ strategy. These strategies are automatically chosen for you because the recursive strategy can handle complex three-way merge situations — for example, more than one common ancestor — but it can only handle merging two branches. The octopus merge can handle multiple branches but is more cautious to avoid difficult conflicts, so it’s chosen as the default strategy if you’re trying to merge more than two branches.-->
 
+Nachdem wir neben den Vor- und Nachteilen beim Arbeiten mit Submodulen kennengelernt haben, möchte ich jetzt noch eine alternative Lösung zeigen, wie man ähnliche Probleme lösen kann. Wenn Git etwas zusammenführt, also mergt, analysiert es die Teile, die es mergen muss. Auf Basis dieser Analyse entscheidet Git sich für eine geeignete Merging-Methode. Wenn man zwei Branches mergt, dann verwendet Git automatisch, die sogenannte Recursive-Strategie. Wenn man mehr als zwei Branches mergt, verwendet Git die sogenannte Octopus Strategie. Diese Strategien werden automatisch für Dich gewählt, weil die Recursive-Strategie normalerweise sehr gut geeignet ist, um einen Drei-Wege-Merge (engl. three-way merge) durchzuführen — zum Beispiel, wenn es mehr als einen gemeinsamen Vorgänger-Commit gibt — aber der Drei-Wege-Merge ist nur für das Mergen von zwei Branches geeignet. Die Octopus-Merge-Strategie kann mehrere Branches zusammenführen, aber es wird dabei vorsichtiger vorgegangen um schwierig aufzulösende Konflikte zu vermeiden. Aus diesem Grund wird diese Strategie standardmäßig verwendet, wenn man mehr als zwei Branches zusammenführen möchte. 
+
 <!--However, there are other strategies you can choose as well. One of them is the _subtree_ merge, and you can use it to deal with the subproject issue. Here you’ll see how to do the same rack embedding as in the last section, but using subtree merges instead.-->
 
+Es gibt jedoch noch weitere Strategien die man verwenden kann. Einer dieser Strategien ist der sogenannte Subtree-Merge. Dies kann verwendet werden um unser Problem mit Unterprojekten zu lösen. Ich möchte Dir im folgenden aufzeigen, wie man das Rack-Projekt aus dem letzten Kapitel einbindet und dabei den Subree-Merge anstatt den Submodulen verwendet.
+
 <!--The idea of the subtree merge is that you have two projects, and one of the projects maps to a subdirectory of the other one and vice versa. When you specify a subtree merge, Git is smart enough to figure out that one is a subtree of the other and merge appropriately — it’s pretty amazing.-->
 
+Das Prinzip, das hinter einem Subtree-Merge steckt, ist, dass man zwei Projekte hat und eines der Projekte wird in ein Unterverzeichnis des anderen Projekts abgebildet. Wenn man ein Subtree-Merge ausführt, ist Git schlau genug um zu erkennen, dass ein Projekt ein Abbild von einem anderen Projekt ist und es kann den Merge in geeigneter Weise durchführen — das ist wirklich sehr erstaunlich.
+
 <!--You first add the Rack application to your project. You add the Rack project as a remote reference in your own project and then check it out into its own branch:-->
 
+Als erstes musst Du dazu die Rack Applikation zu Deinem Projekt hinzufügen. Dazu fügst Du das Rack Projekt als neues Remote Repository in Deinem Projekt hinzu und checkst dieses in einem separaten Branch aus:
+
 	$ git remote add rack_remote git@github.com:schacon/rack.git
 	$ git fetch rack_remote
 	warning: no common commits
@@ -1438,6 +1446,8 @@ Wenn man dann wieder in den Zweig mit dem Submodul zurückwechseln will, erhält
 
 <!--Now you have the root of the Rack project in your `rack_branch` branch and your own project in the `master` branch. If you check out one and then the other, you can see that they have different project roots:-->
 
+Nach der Ausführung der drei Befehle befindet sich das Rack Projekt in Deinem Branch `rack_branch` und Dein eigenes Projekt liegt weiterhin im Branch `master`. Wenn man jetzt den jeweiligen Zweig auscheckt, sieht man die unterschiedlichen Inhalte im Wurzelverzeichnis:
+
 	$ ls
 	AUTHORS	       KNOWN-ISSUES   Rakefile      contrib	       lib
 	COPYING	       README         bin           example	       test
@@ -1448,15 +1458,21 @@ Wenn man dann wieder in den Zweig mit dem Submodul zurückwechseln will, erhält
 
 <!--You want to pull the Rack project into your `master` project as a subdirectory. You can do that in Git with `git read-tree`. You’ll learn more about `read-tree` and its friends in Chapter 9, but for now know that it reads the root tree of one branch into your current staging area and working directory. You just switched back to your `master` branch, and you pull the `rack` branch into the `rack` subdirectory of your `master` branch of your main project:-->
 
+Jetzt möchten wir das Rack Projekt in Deinen Branch `master` als Unterverzeichnis hinzufügen. Dies kann man in Git mit dem Befehl `git read-tree` durchführen. In Kapitel 9 werde ich den Befehl `read-tree` und dessen verwandten Befehle näher erläutern. Hier möchte ich nur erklären, dass der Befehl das Wurzelverzeichnis eines Branches in die aktuelle Staging Area und in das Arbeitsverzeichnis packt. Damit hast Du jetzt zu Deinem Branch `master` zurückgewechselt, den Inhalt des Branches `rack` in das Unterverzeichnis `rack` im Branch `master` Deines Projekts hinterlegt:
+
 	$ git read-tree --prefix=rack/ -u rack_branch
 
 <!--When you commit, it looks like you have all the Rack files under that subdirectory — as though you copied them in from a tarball. What gets interesting is that you can fairly easily merge changes from one of the branches to the other. So, if the Rack project updates, you can pull in upstream changes by switching to that branch and pulling:-->
 
+Wenn Du jetzt einen Commit ausführst, erscheint es einem so, als ob die ganzen Dateien aus dem Rack Projekt in diesem Unterverzeichnis liegen — als ob man das Projekt aus einem Tarball-Container hineinkopiert hätte. Das Besondere ist jetzt aber, dass man Änderungen zwischen den verschiedenen Branches jetzt einfach zusammenführen kann. Das beduetet, wenn das Rack Projekt aktualisiert wird, kann man sich diese Änderungen einfach holen indem man in diese Branch wechselt und dort einen Pull durchführt:   
+
 	$ git checkout rack_branch
 	$ git pull
 
 <!--Then, you can merge those changes back into your master branch. You can use `git merge -s subtree` and it will work fine; but Git will also merge the histories together, which you probably don’t want. To pull in the changes and prepopulate the commit message, use the `-\-squash` and `-\-no-commit` options as well as the `-s subtree` strategy option:-->
 
+Danach kann man diese Änderungen wieder in den master Branch mergen. Wenn man den Befehl `git merge -s subtree` verwendet, sollte dies einwandfrei funktionieren. Allerdings wird Git bei Ausführen dieses Befehl auch die jeweilige Historie mergen, was Du wahrscheinlich nicht haben möchtest. Um nun die Änderungen zu holen und eine entsprechende Commit Nachricht vorzubereiten, hängt man einfach `--squash`, `--no-commit` und natürlich `-s subtree` als Option an:
+
 	$ git checkout master
 	$ git merge --squash -s subtree --no-commit rack_branch
 	Squash commit -- not updating HEAD
@@ -1464,12 +1480,18 @@ Wenn man dann wieder in den Zweig mit dem Submodul zurückwechseln will, erhält
 
 <!--All the changes from your Rack project are merged in and ready to be committed locally. You can also do the opposite — make changes in the `rack` subdirectory of your master branch and then merge them into your `rack_branch` branch later to submit them to the maintainers or push them upstream.-->
 
+Die ganzen Änderungen des Rack Projekts wurden nun zusammengeführt, Du musst jetzt nur noch einen entsprechenden Commit durchführen. Man kann aber auch genau das Gegenteil machen: Man führt Änderungen im Unterverzeichnis `rack` des master Branch aus und mergt diese dann später in den Zweig `rack_branch`. Diesen kann man dann den Entwicklern des Rack Projekts zur Verfügung stellen.
+
 <!--To get a diff between what you have in your `rack` subdirectory and the code in your `rack_branch` branch — to see if you need to merge them — you can’t use the normal `diff` command. Instead, you must run `git diff-tree` with the branch you want to compare to:-->
 
+Um die Unterschiede zwischen dem Inhalt in Deinem Verzeichnis `rack` und dem Code im Zweig `rack_branch` anzuzeigen, kann man keinen normalen Vergleich mit `diff` durchführen. Man muss stattdessen den Befehl `git diff-tree` verwenden und als Argument den zu vergleichenden Branch angeben:
+
 	$ git diff-tree -p rack_branch
 
 <!--Or, to compare what is in your `rack` subdirectory with what the `master` branch on the server was the last time you fetched, you can run-->
 
+Um Dein Verzeichnis `rack` mit dem letzten Stand des Branches `master` auf dem Server zu vergleichen, kannst Du folgenden Befehl verwenden:
+
 	$ git diff-tree -p rack_remote/master
 
 <!--## Summary ##-->

From abbe03223bf378246608c95f4316fb84b6a9509c Mon Sep 17 00:00:00 2001
From: Ralph Haussmann <ralph@scanmyfood.de>
Date: Fri, 3 Jan 2014 17:50:49 +0100
Subject: [PATCH 010/690] [de] First translation of chapter 6.8 (summary)

---
 de/06-git-tools/01-chapter6.markdown | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/de/06-git-tools/01-chapter6.markdown b/de/06-git-tools/01-chapter6.markdown
index e266f393e..f83fc9c52 100644
--- a/de/06-git-tools/01-chapter6.markdown
+++ b/de/06-git-tools/01-chapter6.markdown
@@ -1498,3 +1498,5 @@ Um Dein Verzeichnis `rack` mit dem letzten Stand des Branches `master` auf dem S
 ## Zusammenfassung ##
 
 <!--You’ve seen a number of advanced tools that allow you to manipulate your commits and staging area more precisely. When you notice issues, you should be able to easily figure out what commit introduced them, when, and by whom. If you want to use subprojects in your project, you’ve learned a few ways to accommodate those needs. At this point, you should be able to do most of the things in Git that you’ll need on the command line day to day and feel comfortable doing so.-->
+
+In diesem Kapitel hast Du viele ausgeklügelte Werzeuge kennengelernt, die es Dir ermöglichen Commits und die Staging Area nach Deinen Vorstellungen zu beeinflussen. Wenn ein Problem in Deinem Projekt auftaucht, solltest Du jetzt leicht bestimmen können, welcher Commit den Fehler verursacht hat, genauso die Information wann und von wem der Fehler begangen wurde. Wenn Du andere Projekte in Deinem Projekt verwendet möchtest, hast Du jetzt mehrere Möglichkeiten kennengelernt, wie Du dies handhaben kannst. An dieser Stelle solltest Du jetzt in der Lage sein die meisten Dinge, die Du bei der täglichen Arbeit benötigst, in der Kommandozeile durchzuführen, ohne das Dir dabei Schweißperlen auf der Stirn stehen.

From 13b7ee3e6bec9b4314313a3c828989bf3b9e62b1 Mon Sep 17 00:00:00 2001
From: Ralph Haussmann <ralph@scanmyfood.de>
Date: Fri, 3 Jan 2014 17:54:27 +0100
Subject: [PATCH 011/690] [de] Use Dir instead of dir and Du instead of Du

---
 de/06-git-tools/01-chapter6.markdown | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/de/06-git-tools/01-chapter6.markdown b/de/06-git-tools/01-chapter6.markdown
index f83fc9c52..032a2ef52 100644
--- a/de/06-git-tools/01-chapter6.markdown
+++ b/de/06-git-tools/01-chapter6.markdown
@@ -14,7 +14,7 @@ Als nächstes werden wir einige sehr mächtige Werkzeuge besprechen, die Dir Git
 
 <!--Git allows you to specify specific commits or a range of commits in several ways. They aren’t necessarily obvious but are helpful to know.-->
 
-Git erlaubt dir, Commits auf verschiedenste Art und Weise auszuwählen. Diese sind nicht immer offensichtlich, aber es ist hilfreich diese zu kennen.
+Git erlaubt Dir, Commits auf verschiedenste Art und Weise auszuwählen. Diese sind nicht immer offensichtlich, aber es ist hilfreich diese zu kennen.
 
 <!--### Single Revisions ###-->
 ### Einzelne Revisionen ###
@@ -145,7 +145,7 @@ Außerdem kannst Du dieselbe Syntax verwenden, um eine Zeitspanne anzugeben. Um
 
 <!--That shows you where the branch tip was yesterday. This technique only works for data that’s still in your reflog, so you can’t use it to look for commits older than a few months.-->
 
-Das zeigt dir, wo der `master` Branch gestern war. Diese Technik funktioniert nur mit Daten, die noch im Reflog sind, d.h. man kann sie nicht für Commits verwenden, die ein älter sind als ein paar Monate.
+Das zeigt Dir, wo der `master` Branch gestern war. Diese Technik funktioniert nur mit Daten, die noch im Reflog sind, d.h. man kann sie nicht für Commits verwenden, die ein älter sind als ein paar Monate.
 
 <!--To see reflog information formatted like the `git log` output, you can run `git log -g`:-->
 
@@ -527,7 +527,7 @@ Im Allgemeinen, wirst Du `y` oder `n` nutzen wenn Du jeden Hunk stagen willst, a
 
 <!--The status of the simplegit.rb file is interesting. It shows you that a couple of lines are staged and a couple are unstaged. You’ve partially staged this file. At this point, you can exit the interactive adding script and run `git commit` to commit the partially staged files.-->
 
-Der Status der simplegit.rb ist interessant. Er zeigt dir, dass ein paar Zeilen gestagd und ein paar ungestaged sind. Du hast diese Datei teilweise gestaged. An dieser Stelle kannst Du das interaktive add Skript verlassen und `git commit` ausführen, um die teilweise gestageden Dateien zu commiten.
+Der Status der simplegit.rb ist interessant. Er zeigt Dir, dass ein paar Zeilen gestagd und ein paar ungestaged sind. Du hast diese Datei teilweise gestaged. An dieser Stelle kannst Du das interaktive add Skript verlassen und `git commit` ausführen, um die teilweise gestageden Dateien zu commiten.
 
 <!--Finally, you don’t need to be in interactive add mode to do the partial-file staging — you can start the same script by using `git add -p` or `git add -\-patch` on the command line.-->
 
@@ -1368,7 +1368,7 @@ In diesem Fall muss man das Verzeichnis entweder an einen anderen Ort verschiebe
 
 <!--The last main caveat that many people run into involves switching from subdirectories to submodules. If you’ve been tracking files in your project and you want to move them out into a submodule, you must be careful or Git will get angry at you. Assume that you have the rack files in a subdirectory of your project, and you want to switch it to a submodule. If you delete the subdirectory and then run `submodule add`, Git yells at you:-->
 
-Die letzte Falle in die viele Leute tappen, tritt auf, wenn man bereits vorhandene Verzeichnisse in Submodule umwandeln will. Wenn man also Dateien, die bereits von Git verwaltet werden, entfernen und in ein entsprechendes Submodul verschieben möchte, muss man vorsichtig sein. Ansonsten können schwer zu behebende Probleme mit Git auftreten. Nehmen wir zum Beispiel an, dass Du die Dateien vom Rack Projekt in ein Unterverzeichnis Deines Projekts abgelegt hast und diese jetzt aber in ein Submodul verschieben möchtest. Wenn Du das Unterverzeichnis einfach löschst und dann den Befehl `submodule add` ausführst, zeigt dir Git folgende Fehlermeldung an:  
+Die letzte Falle in die viele Leute tappen, tritt auf, wenn man bereits vorhandene Verzeichnisse in Submodule umwandeln will. Wenn man also Dateien, die bereits von Git verwaltet werden, entfernen und in ein entsprechendes Submodul verschieben möchte, muss man vorsichtig sein. Ansonsten können schwer zu behebende Probleme mit Git auftreten. Nehmen wir zum Beispiel an, dass Du die Dateien vom Rack Projekt in ein Unterverzeichnis Deines Projekts abgelegt hast und diese jetzt aber in ein Submodul verschieben möchtest. Wenn Du das Unterverzeichnis einfach löschst und dann den Befehl `submodule add` ausführst, zeigt Dir Git folgende Fehlermeldung an:  
 
 	$ rm -Rf rack/
 	$ git submodule add git@github.com:schacon/rack.git rack
@@ -1406,7 +1406,7 @@ Dann musst Du das Submodul-Verzeichnis `rack` an einen anderen Ort verschieben,
 
 <!--Then, when you switch back, you get an empty `rack` directory. You can either run `git submodule update` to reclone, or you can move your `/tmp/rack` directory back into the empty directory.-->
 
-Wenn man dann wieder in den Zweig mit dem Submodul zurückwechseln will, erhält man ein leeres Verzeichnis `rack`. Um dieses zu befüllen, kannst du entweder `git submodule update` ausführen oder Du kannst Deine Kopie von `/tmp/rack` wieder an den ursprünglichen Ort wiederherstellen.
+Wenn man dann wieder in den Zweig mit dem Submodul zurückwechseln will, erhält man ein leeres Verzeichnis `rack`. Um dieses zu befüllen, kannst Du entweder `git submodule update` ausführen oder Du kannst Deine Kopie von `/tmp/rack` wieder an den ursprünglichen Ort wiederherstellen.
 
 <!--## Subtree Merging ##-->
 ## Subtree Merging ##

From ac5ab1130658d2425fc6a57d7e4c37e803d87ac4 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Fri, 3 Jan 2014 18:06:45 +0100
Subject: [PATCH 012/690] Reviewing translation

to ensure compliance within the chapter, before proceeding translation
---
 it/06-git-tools/01-chapter6.markdown | 22 +++++-----------------
 1 file changed, 5 insertions(+), 17 deletions(-)

diff --git a/it/06-git-tools/01-chapter6.markdown b/it/06-git-tools/01-chapter6.markdown
index d22624086..e06ba3e1f 100644
--- a/it/06-git-tools/01-chapter6.markdown
+++ b/it/06-git-tools/01-chapter6.markdown
@@ -1,28 +1,16 @@
 # Git Tools #
 
-Fin'ora sono stati imparati la maggior parte dei comandi giornalieri a i
-workflow che potrebbero essere necessari a gestire e mantenere un repository Git
-per il controllo del codice sorgente.
-Sono state compiute le attività di base per il tracciamento e il commit dei
-file, ed è stato sfruttato il potere della *staging area* e argomenti leggeri il
-*branching* (ramificazione) e il *merge*.
+Finora hai imparato la la maggior parte dei comandi d’uso quotidiani e i workflow che potrebbero essere necessari a gestire e mantenere un repository per il controllo del codice sorgente con Git. Hai eseguito le attività di base per il tracciamento e la commit dei file, e hai sfruttato il potere della *staging area* e il *branch* (la ramificazione) e il *merge* di argomenti dall’impatto leggero.
 
-Ora verrà esplorato un numero di cose veramente potenti che Git può fare che non
-vengono necessariamente usate di base quotidianamente ma che potrebbero servire
-ad un certo punto.
+Vedremo ora una serie di potenzialità di Git che potresti non usare quotidianamente, ma di cui potresti averne bisogno a un certo punto.
 
 ## Selezione della revisione ##
 
-Git permette di specificare determinati *commit* o una serie di *commit* in
-diversi modi.
-Non sono necessariamente evidenti ma può essere d'aiuto conoscerli.
+Git ti permette di specificare una o più *commit* in diversi modi. Non sono sempre ovvi, ma è utile conoscerli.
 
-### Singola revisione ###
+### Singole versioni ###
 
-E' possibile ovviamente riferirsi a un *commit* tramite l'hash SHA-1 che viene
-dato, ma ci sono modi più alla portata degli umani per riferirsi ai *commit*.
-Questa sezione delinea i diversi modi con cui ci si può riferire ad un singolo
-commit.
+Puoi fare riferimento a una singola commit usando l’hash SHA-1 attribuito, ma ci sono altri metodi più amichevoli per fare riferimento a una *commit*. Questa sezione delinea i modi con cui ci si può riferire a una singolo commit.
 
 ### SHA breve ###
 

From 4277884d857c18b7f5b4f7135f4ab75e20f70416 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Fri, 3 Jan 2014 18:51:20 +0100
Subject: [PATCH 013/690] Reviewing translation

---
 it/06-git-tools/01-chapter6.markdown | 18 ++++--------------
 1 file changed, 4 insertions(+), 14 deletions(-)

diff --git a/it/06-git-tools/01-chapter6.markdown b/it/06-git-tools/01-chapter6.markdown
index e06ba3e1f..602aec655 100644
--- a/it/06-git-tools/01-chapter6.markdown
+++ b/it/06-git-tools/01-chapter6.markdown
@@ -14,14 +14,9 @@ Puoi fare riferimento a una singola commit usando l’hash SHA-1 attribuito, ma
 
 ### SHA breve ###
 
-Git è abbastanza intelligente da capire a quale *commit* ci si riferisce se si
-fornisce i primi caratteri, purché il codice SHA-1 sia di almeno quattro
-caratteri e univoco - solo un oggetto nel *repository* corrente inizia con quel
-SHA-1 parziale.
+Git è abbastanza intelligente da capire a quale *commit* ti riferisci scrivi i primi caratteri purché il codice SHA-1 sia di almeno quattro caratteri e sia univoco, ovvero che un solo oggetti nel *repository* attuale inizi con quel SHA-1.
 
-Per esempio, per vedere uno specifico *commit*, supponiamo che venga eseguito un
-comando 'git log' e venga identificato un *commit* dove sono state aggiunte
-certe funzionalità:
+Per vedere per esempio una *commit*  specifica, immaginiamo di eseguire 'git log' e venga identificata una *commit* dove sono state aggiunte determinate funzionalità:
 
 	$ git log
 	commit 734713bc047d87bf7eac9674765ae793478c50d3
@@ -43,18 +38,13 @@ certe funzionalità:
 
 	    added some blame and merge stuff
 
-In questo caso, scegliamo '1c002dd....' Se viene eseguito 'git show' su quel
-*commit*, i seguenti comandi sono equivalenti (assumendo che le versioni più
-corte siano univoche):            
+In questo caso scegliamo '1c002dd....'. Se vuoi eseguire 'git show' su quella *commit*, i seguenti comandi sono equivalenti (assumendo che le versioni più brevi siano univoche):            
 
 	$ git show 1c002dd4b536e7479fe34593e72e6c6c1819e53b
 	$ git show 1c002dd4b536e7479f
 	$ git show 1c002d
 
-Git riesce a capire una corta, univoca abbreviazione del valore SHA-1. Se viene
-passato '--abbrev-commit' al comando 'git-log', l'*output* userà valori più
-corti ma li manterrà unici; in maniera predefinita utilizza sette caratteri ma
-se necessario ne userà di più per mantenere il codice SHA-1 univoco:
+Git riesce a capire un valore SHA-1 intero da uno corto, abbreviato. Se usi l’opzione '--abbrev-commit' col comando 'git-log', l'*output* userà valori più corti ma garantirà che siano unici: di default usa sette caratteri ma ne userà di più se sarà necessario per mantenere l’univocità del valore SHA-1:
 
 	$ git log --abbrev-commit --pretty=oneline
 	ca82a6d changed the version number

From ced105a89e1b4acc9bb04993aff79bf40e08e73a Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Fri, 3 Jan 2014 18:58:45 +0100
Subject: [PATCH 014/690] Reviewing translation

---
 it/06-git-tools/01-chapter6.markdown | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/it/06-git-tools/01-chapter6.markdown b/it/06-git-tools/01-chapter6.markdown
index 602aec655..c6b8026ab 100644
--- a/it/06-git-tools/01-chapter6.markdown
+++ b/it/06-git-tools/01-chapter6.markdown
@@ -51,10 +51,8 @@ Git riesce a capire un valore SHA-1 intero da uno corto, abbreviato. Se usi l’
 	085bb3b removed unnecessary test code
 	a11bef0 first commit
 
-Generalmente, da otto a dieci caratteri sono più che sufficienti per essere
-univoci all'interno di un progetto.
-Uno dei progetti Git più grandi, il kernel Linux, inizia a necessitare 12
-caratteri, dei 40 possibili, per rimanere univoco.
+Da otto a dieci caratteri sono, generalmente, più che sufficienti per essere
+univoci all'interno di un progetto. Uno dei progetti Git più grandi, il kernel di Linux, inizia a necessitare 12 caratteri, dei 40 possibili, per essere univoco.
 
 ### Una breve nota su SHA-1 ###
 

From ec260b072d9ec0c5b9e9be980c14c6eab1951f45 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Fri, 3 Jan 2014 19:02:48 +0100
Subject: [PATCH 015/690] Reviewing translation

---
 it/06-git-tools/01-chapter6.markdown | 1 +
 1 file changed, 1 insertion(+)

diff --git a/it/06-git-tools/01-chapter6.markdown b/it/06-git-tools/01-chapter6.markdown
index c6b8026ab..0c75784aa 100644
--- a/it/06-git-tools/01-chapter6.markdown
+++ b/it/06-git-tools/01-chapter6.markdown
@@ -56,6 +56,7 @@ univoci all'interno di un progetto. Uno dei progetti Git più grandi, il kernel
 
 ### Una breve nota su SHA-1 ###
 
+Arriva un momento in cui molte persone si preoccupano che 
 Un sacco di gente si preoccupa ad un certo punto che, per una qualche casualità,
 potrebbe avere due oggetti nel proprio *repository* che abbiano lo stesso hash
 SHA-1. Cosa accadrebbe a quel punto?

From e18f755aea8fae6313f9990c088629773c94e98a Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Fri, 3 Jan 2014 19:15:00 +0100
Subject: [PATCH 016/690] Reviewed "Una breve nota su SHA-1"

---
 it/06-git-tools/01-chapter6.markdown | 34 +++++++---------------------
 1 file changed, 8 insertions(+), 26 deletions(-)

diff --git a/it/06-git-tools/01-chapter6.markdown b/it/06-git-tools/01-chapter6.markdown
index 0c75784aa..c44e8b2dd 100644
--- a/it/06-git-tools/01-chapter6.markdown
+++ b/it/06-git-tools/01-chapter6.markdown
@@ -56,34 +56,16 @@ univoci all'interno di un progetto. Uno dei progetti Git più grandi, il kernel
 
 ### Una breve nota su SHA-1 ###
 
-Arriva un momento in cui molte persone si preoccupano che 
-Un sacco di gente si preoccupa ad un certo punto che, per una qualche casualità,
-potrebbe avere due oggetti nel proprio *repository* che abbiano lo stesso hash
-SHA-1. Cosa accadrebbe a quel punto?
-
-Se capita di fare il *commit* di un oggetto che ha lo stesso SHA-1 di un oggetto
-precedente nel proprio *repository*, Git noterà il precedente oggetto già
-presente nel database Git e lo riterrà già scritto.
-Provando ad ottenere informazioni su quell'oggetto nuovamente ad un certo punto,
-verranno sempre restituiti i dati del primo oggetto.
-
-Ad ogni modo, è necessario essere consapevoli di quanto ridicolmente improbabile
-sia questo scenario. Il codice SHA-1 riassunto è di 20 bytes o 160 bits. Il
-numero casuale di oggetti necessari per assicurare un 50% di una singola
-collisione è di circa 2^80 (la formula per determinare la probabilità di
-collisione è `p = (n(n-1)/2) * (1/2^160))`. 2^80 è 1.2 x 10^24 o un milione di
-miliardi di miliardi. E' 1,200 volte il numero di granelli di sabbia sulla
-terra.
+Arriva un momento in cui molte persone si preoccupano che possano avere, per puro caso, due oggetti nel proprio *repository* che abbiano lo stesso hash SHA-1. E allora?
+
+Se capita di fare la *commit* di un oggetto a che abbia lo stesso SHA-1 di un oggetto
+già presente nel tuo *repository*, Git vedrà l’oggetto precedente già nel database di Git e lo riterrà già scritto. Se successivamente proverai a fare il checkout di quest’ultimo oggetto, otterrai sempre i dati del primo oggetto.
+
+Ad ogni modo, è necessario essere consapevoli di quanto sia ridicolmente improbabile
+questo scenario. Il codice SHA-1 è di 20 bytes o 160 bits. Il numero di oggetti casuali necessari perché ci sia la probabilità del 50% di una singola collisione è di circa 2^80 (la formula per determinare la probabilità di collisione è `p = (n(n-1)/2) * (1/2^160))`. 2^80 è 1.2 x 10^24 ovvero un milione di miliardi di miliardi. È 1.200 volte il numero di granelli di sabbia sulla terra.
 
 Ecco un esempio per dare un'idea di cosa ci vorrebbe per ottenere una collisione
-SHA-1. Se tutti i 6.5 miliardi di esseri umani sulla Terra stessero
-programmando, e ogni secondo, ognuno stesse producendo codice che fosse
-equivalente all'intera storia del kernel Linux (1 milione di oggetti Git) e se
-lo stesse caricando su un enorme *repository* Git, ci vorrebbero 5 anni per
-contenere abbastanza oggetti in quel *repository* da avere il 50% di possibilità
-di una singola collisione di oggetti SHA-1. Esiste una probabilità più alta che
-ogni membro del team venga attaccato e ucciso dai lupi in situazioni
-indipendenti durante la stessa notte.
+SHA-1. Se tutti i 6.5 miliardi di esseri umani sulla Terra programmassero e, ogni secondo, ognuno scrivesse codice che fosse equivalente all'intera cronologia del kernel Linux (1 milione di oggetti Git) e ne facesse la push su un enorme *repository* Git, ci vorrebbero 5 anni per contenere abbastanza oggetti in quel *repository* per avere il 50% di possibilità di una singola collisione di oggetti SHA-1. Esiste una probabilità più alta che ogni membro del tuo gruppo di sviluppo, per pura coincidenza, venga attaccato e ucciso da dei lupi nella stessa notte.
 
 ### Riferimenti al *branch* ###
 

From 551e61c66e505541ae0dbe5a93f94c2d258142cc Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Fri, 3 Jan 2014 19:24:16 +0100
Subject: [PATCH 017/690] Reviewing translation

---
 it/06-git-tools/01-chapter6.markdown | 17 +++--------------
 1 file changed, 3 insertions(+), 14 deletions(-)

diff --git a/it/06-git-tools/01-chapter6.markdown b/it/06-git-tools/01-chapter6.markdown
index c44e8b2dd..f0fead5e5 100644
--- a/it/06-git-tools/01-chapter6.markdown
+++ b/it/06-git-tools/01-chapter6.markdown
@@ -67,25 +67,14 @@ questo scenario. Il codice SHA-1 è di 20 bytes o 160 bits. Il numero di oggetti
 Ecco un esempio per dare un'idea di cosa ci vorrebbe per ottenere una collisione
 SHA-1. Se tutti i 6.5 miliardi di esseri umani sulla Terra programmassero e, ogni secondo, ognuno scrivesse codice che fosse equivalente all'intera cronologia del kernel Linux (1 milione di oggetti Git) e ne facesse la push su un enorme *repository* Git, ci vorrebbero 5 anni per contenere abbastanza oggetti in quel *repository* per avere il 50% di possibilità di una singola collisione di oggetti SHA-1. Esiste una probabilità più alta che ogni membro del tuo gruppo di sviluppo, per pura coincidenza, venga attaccato e ucciso da dei lupi nella stessa notte.
 
-### Riferimenti al *branch* ###
+### Riferimenti ai *branch* ###
 
-La strada più diretta per specificare un *commit* richiede che punti ad un
-riferimento di un *branch*. A quel punto potrebbe essere usato il nome del
-*branch* in qualsiasi comando Git che richiede un oggetto *commit* o un valore
-SHA-1. Per esempio, se si vuole mostrare l'ultimo oggetto *commit* di un
-*branch*, i seguenti comandi sono equivalenti, ammesso che il *branch* 'topic1'
-punti a 'ca82a6d':
+Il modo più diretto per specificare una *commit* è avere un *branch* che vi faccia riferimento, che ti permetterebbe di usare il nome del *branch* in qualsiasi comando Git che richieda un oggetto *commit* o un valore SHA-1. Se vuoi, per esempio, mostrare l'ultima *commit* di un *branch*, i seguenti comandi sono equivalenti, supponendo che il *branch* 'topic1' punti a 'ca82a6d':
 
 	$ git show ca82a6dff817ec66f44342007202690a93763949
 	$ git show topic1
 
-Se si vuole vedere a quale specifico SHA un *branch* punta, o se si vuole vedere
-a cosa si riduce ognuno di questi esempi in termini di SHA, si può usare un
-*plumbing tool* di Git chiamato 'rev-parse'. Nel Capitolo 9 ci sono più informazioni
-sui *plumbing tool*; sostanzialmente, 'rev-parse' esiste per operazioni di basso
-livello e non è concepito per essere usato in operazioni quotidiane. Comunque,
-può essere d'aiuto a volte quanto c'è bisogno di vedere cosa succede realmente.
-A quel punto si può lanciare 'rev-parse' sul proprio *branch*.
+Se vuoi vedere a quale SHA specifico punti un *branch*, o se vuoi vedere a quale SHA puntino questi esempi, puoi usare il comando 'rev-parse' di Git, che fa parte dei comandi *plumbing* . Nel Capitolo 9 trovi maggiori informazioni sui comandi *plumbing*: brevemente, 'rev-parse' esiste per operazioni di basso livello e non è concepito per essere usato nelle operazioni quotidiane. Può Comunque essere d'aiuto quando hai bisogno di vedere cosa sta succedendo. Puoi quindi eseguire 'rev-parse' su tuo *branch*.
 
 	$ git rev-parse topic1
 	ca82a6dff817ec66f44342007202690a93763949

From 9a8c4a124b79338bd6597a590e65ec7a432c5359 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Fri, 3 Jan 2014 19:30:56 +0100
Subject: [PATCH 018/690] Fixed typo

---
 it/09-git-internals/01-chapter9.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/it/09-git-internals/01-chapter9.markdown b/it/09-git-internals/01-chapter9.markdown
index 2bcf1ca5e..820f5b305 100644
--- a/it/09-git-internals/01-chapter9.markdown
+++ b/it/09-git-internals/01-chapter9.markdown
@@ -837,7 +837,7 @@ Muovi ora il branch `master` a una commit centrale:
 
 Così facendo hai perso le due commit più recenti: questa commit non sono più raggiungibili in nessun modo. Devi scoprire l’hash SHA dell’ultima commit e aggiungere quindi un branch che vi punti. Il trucco è trovare l’hash SHA dell’ultima commit: non è come lo ricordavi, vero?
 
-Spesso il modo più veloce è usare `git reflog`. Mentre lavori Git memorizza silenziosamente lo stato del tuo HEAD ogni volta che lo cambi. IL reflag viene aggiornato ogni volta che fai una commit o cambi un branch. Il reflog viene aggiornato anche dal comando `git update-ref`, che è un’altra buona ragione per usarlo, invece di scrivere direttamente il valore dell’SHA nei tuoi file ref, come abbiamo visto nella sezione “I Riferimenti di Git" in questo stesso capitolo. Eseguendo `git reflog` puoi vedere dov’eri in qualsiasi dato momento:
+Spesso il modo più veloce è usare `git reflog`. Mentre lavori Git memorizza silenziosamente lo stato del tuo HEAD ogni volta che lo cambi. IL reflog viene aggiornato ogni volta che fai una commit o cambi un branch. Il reflog viene aggiornato anche dal comando `git update-ref`, che è un’altra buona ragione per usarlo, invece di scrivere direttamente il valore dell’SHA nei tuoi file ref, come abbiamo visto nella sezione “I Riferimenti di Git" in questo stesso capitolo. Eseguendo `git reflog` puoi vedere dov’eri in qualsiasi dato momento:
 
 	$ git reflog
 	1a410ef HEAD@{0}: 1a410efbd13591db07496601ebc7a059dd55cfe9: updating HEAD

From aeb37a2bf6705ea30a40be1f3199a750a24b309a Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Fri, 3 Jan 2014 19:31:15 +0100
Subject: [PATCH 019/690] Fixed typo

---
 it/09-git-internals/01-chapter9.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/it/09-git-internals/01-chapter9.markdown b/it/09-git-internals/01-chapter9.markdown
index 820f5b305..b39dc0830 100644
--- a/it/09-git-internals/01-chapter9.markdown
+++ b/it/09-git-internals/01-chapter9.markdown
@@ -837,7 +837,7 @@ Muovi ora il branch `master` a una commit centrale:
 
 Così facendo hai perso le due commit più recenti: questa commit non sono più raggiungibili in nessun modo. Devi scoprire l’hash SHA dell’ultima commit e aggiungere quindi un branch che vi punti. Il trucco è trovare l’hash SHA dell’ultima commit: non è come lo ricordavi, vero?
 
-Spesso il modo più veloce è usare `git reflog`. Mentre lavori Git memorizza silenziosamente lo stato del tuo HEAD ogni volta che lo cambi. IL reflog viene aggiornato ogni volta che fai una commit o cambi un branch. Il reflog viene aggiornato anche dal comando `git update-ref`, che è un’altra buona ragione per usarlo, invece di scrivere direttamente il valore dell’SHA nei tuoi file ref, come abbiamo visto nella sezione “I Riferimenti di Git" in questo stesso capitolo. Eseguendo `git reflog` puoi vedere dov’eri in qualsiasi dato momento:
+Spesso il modo più veloce è usare `git reflog`. Mentre lavori Git memorizza silenziosamente lo stato del tuo HEAD ogni volta che lo cambi. Il reflog viene aggiornato ogni volta che fai una commit o cambi un branch. Il reflog viene aggiornato anche dal comando `git update-ref`, che è un’altra buona ragione per usarlo, invece di scrivere direttamente il valore dell’SHA nei tuoi file ref, come abbiamo visto nella sezione “I Riferimenti di Git" in questo stesso capitolo. Eseguendo `git reflog` puoi vedere dov’eri in qualsiasi dato momento:
 
 	$ git reflog
 	1a410ef HEAD@{0}: 1a410efbd13591db07496601ebc7a059dd55cfe9: updating HEAD

From 84305e50526f18673c9d5f35a27a0918484f75c3 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Fri, 3 Jan 2014 19:35:15 +0100
Subject: [PATCH 020/690] Reviewing translation

---
 it/06-git-tools/01-chapter6.markdown | 7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/it/06-git-tools/01-chapter6.markdown b/it/06-git-tools/01-chapter6.markdown
index f0fead5e5..9efcffa29 100644
--- a/it/06-git-tools/01-chapter6.markdown
+++ b/it/06-git-tools/01-chapter6.markdown
@@ -79,12 +79,11 @@ Se vuoi vedere a quale SHA specifico punti un *branch*, o se vuoi vedere a quale
 	$ git rev-parse topic1
 	ca82a6dff817ec66f44342007202690a93763949
 
-### RefLog ###
+### Nomi brevi di RefLog ###
 
-Una delle cose che Git fa mentre si lavora è tenere un reflog - un log sui
-riferimenti di *HEAD* e *branch* degli ultimi mesi.
+Una delle cose che Git fa dietro le quinte è aggiornare il file reflog, che memorizza silenziosamente la posizione negli ultimi mesi del tuo HEAD e dei riferimenti ai tuoi branch , ogni volta che li cambi.
 
-E' possibile vedere il reflog usando il comando 'git reflog':
+Puoi consultare il reflog con il comando 'git reflog':
 
 	$ git reflog
 	734713b... HEAD@{0}: commit: fixed refs handling, added gc auto, updated

From 80adfd77d793668ed07c8c17f473629408406b0a Mon Sep 17 00:00:00 2001
From: Tuan Vu <contact@tuanva.co.uk>
Date: Fri, 3 Jan 2014 18:44:48 +0000
Subject: [PATCH 021/690] =?UTF-8?q?using=20't=C3=ADch=20h=E1=BB=A3p'=20ins?=
 =?UTF-8?q?tead=20of=20'g=E1=BB=99p'=20as=20translation=20for=20merge?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 vi/02-git-basics/01-chapter2.markdown    |  22 +--
 vi/03-git-branching/01-chapter3.markdown | 211 ++++++++++++-----------
 2 files changed, 117 insertions(+), 116 deletions(-)

diff --git a/vi/02-git-basics/01-chapter2.markdown b/vi/02-git-basics/01-chapter2.markdown
index 73ef3e6a7..5904099a7 100644
--- a/vi/02-git-basics/01-chapter2.markdown
+++ b/vi/02-git-basics/01-chapter2.markdown
@@ -107,7 +107,7 @@ Hãy sửa một tập tin đang được theo dõi. Nếu bạn sửa một t
 	#	modified:   benchmarks.rb
 	#
 
-Tập tin `benchmarks.rb` nằm trong danh sách "Các thay đổi chưa được tổ chức/đánh dấu để commit" - có nghĩa là một tập tin đang được theo dõi đã bị thay đổi trong thư mục làm việc nhưng chưa được "staged". Để làm việc này, bạn chạy lệnh `git add` (đó là một câu lệnh đa chức năng - bạn có thể dùng nó để bắt đầu theo dõi tập tin, tổ chức tập tin, hoặc các việc khác như đánh dấu đã giải quyết xong các tập tin có nội dung mâu thuẫn nhau khi gộp). Chạy `git add` để "stage" tập tin `benchmarks.rb` và sau đó chạy lại lệnh `git status`: 
+Tập tin `benchmarks.rb` nằm trong danh sách "Các thay đổi chưa được tổ chức/đánh dấu để commit" - có nghĩa là một tập tin đang được theo dõi đã bị thay đổi trong thư mục làm việc nhưng chưa được "staged". Để làm việc này, bạn chạy lệnh `git add` (đó là một câu lệnh đa chức năng - bạn có thể dùng nó để bắt đầu theo dõi tập tin, tổ chức tập tin, hoặc các việc khác như đánh dấu đã giải quyết xong các tập tin có nội dung mâu thuẫn nhau khi tích hợp). Chạy `git add` để "stage" tập tin `benchmarks.rb` và sau đó chạy lại lệnh `git status`: 
 
 	$ git add benchmarks.rb
 	$ git status
@@ -589,7 +589,7 @@ The lines must be formatted as follows
 
 Có thể bạn băn khoăn về sự khác nhau giữa _tác giả_ (author) và _người commit_ (committer). _Tác giả_ là người đầu tiên viết bản vá (patch), trong khi đó _người commit_ là người cuối cùng áp dụng miếng vá đó. Như vậy, nếu bạn gửi một bản vá cho một dự án và một trong các thành viên chính của dự án "áp dụng" (chấp nhận) bản vá đó, cả hai sẽ cùng được ghi nhận công trạng (credit) - bạn với vai trò là tác giả và thành viên của dự án trong vai trò người commit. Chúng ta sẽ bàn kỹ hơn một chút về sự khác nhau này trong *Chương 5*.
 
-Lựa chọn `oneline` và `formar` đặc biệt hữu ích khi sử dụng với một tham số khác của `log` là `--graph`. Khi sử dụng, tham số này sẽ thêm một biểu đồ sử dụng dựa trên các ký tự ASCII hiển thị nhánh và lịch sử gộp các tập tin của bạn, chúng ta có thể thấy trong dự án Grit như sau:
+Lựa chọn `oneline` và `formar` đặc biệt hữu ích khi sử dụng với một tham số khác của `log` là `--graph`. Khi sử dụng, tham số này sẽ thêm một biểu đồ sử dụng dựa trên các ký tự ASCII hiển thị nhánh và lịch sử tích hợp các tập tin của bạn, chúng ta có thể thấy trong dự án Grit như sau:
 
 	$ git log --pretty=format:"%h %s" --graph
 	* 2d3acf9 ignore errors from SIGCHLD on trap
@@ -619,7 +619,7 @@ The lines must be formatted as follows
 	--name-status	Hiển thị các tập tin bị ảnh hưởng với các thông tin như thêm mới/sửa/xoá.
 	--abbrev-commit	Chỉ hiện thị một số ký tự đầu của mã băm SHA-1 thay vì tất cả 40.
 	--relative-date	Hiển thị ngày ở định dạng tương đối (ví dụ, "2 weeks ago") thay vì định dạng đầy đủ.
-	--graph	Hiển thị biểu đồ ASCII của nhánh và lịch sử gộp cùng với thông tin đầu ra khác.
+	--graph	Hiển thị biểu đồ ASCII của nhánh và lịch sử tích hợp cùng với thông tin đầu ra khác.
 	--pretty	Hiện thị các commit sử dụng một định dạng khác. Các lựa chọn bao gồm oneline, short, full, fuller và format (cho phép bạn sử dụng định dạng riêng).
 	--oneline	Một lựa chọn ngắn, thuận tiện cho `--pretty=oneline --abbrev-commit`.
 
@@ -651,7 +651,7 @@ The lines must be formatted as follows
 	--author	Chỉ hiện thị các commit mà tên tác giả thoả mãn điều kiện nhất định.
 	--committer	Chỉ hiện thị các commit mà tên người commit thoả mãn điều kiện nhất định.
 
-Ví dụ, bạn muốn xem các commit đã thay đổi các tập tin thử nghiệm trong lịch sử mã nguồn của Git, được commit bởi Junio Hâmno trng tháng 10 năm 2008 mà chưa được gộp/trộn, bạn có thể chạy lệnh sau:
+Ví dụ, bạn muốn xem các commit đã thay đổi các tập tin thử nghiệm trong lịch sử mã nguồn của Git, được commit bởi Junio Hâmno trng tháng 10 năm 2008 mà chưa được tích hợp/gộp, bạn có thể chạy lệnh sau:
 
 	$ git log --pretty="%h - %s" --author=gitster --since="2008-10-01" \
 	   --before="2008-11-01" --no-merges -- t/
@@ -815,7 +815,7 @@ Bây giờ bạn có thể sử dụng `pb` trong các câu lệnh, nó có tác
 	 * [new branch]      master     -> pb/master
 	 * [new branch]      ticgit     -> pb/ticgit
 
-Nhánh chính của Paul có thể truy cập cục bộ như là `pb/master` - bạn có thể gộp nó vào các nhánh của bạn, hoặc sử dụng nó như là một nhánh cục bộ ở thời điểm đó nếu như bạn muốn kiểm tra nó.  
+Nhánh chính của Paul có thể truy cập cục bộ như là `pb/master` - bạn có thể tích hợp nó vào các nhánh của bạn, hoặc sử dụng nó như là một nhánh cục bộ ở thời điểm đó nếu như bạn muốn kiểm tra nó.  
 
 ### Truy Cập Và Kéo Về Từ Máy Chủ Trung Tâm ###
 
@@ -823,11 +823,11 @@ Như bạn vừa thấy, để lấy dữ liệu của các dự án từ xa v
 
 	$ git fetch [remote-name]
 
-Lệnh này sẽ truy cập vào dự án từ xa đó và kéo xuống toàn bộ dữ liệu mà bạn chưa có trong đó cho bạn. Sau khi thực hiện xong bước này, bạn đã có các tham chiếu đến toàn bộ các nhánh của dự án từ xa đó, nơi mà bạn có thể gộp hoặc kiểm tra bất kỳ thời điểm nào. (Chúng ta sẽ đề cập chi tiết hơn về nhánh là gì và sử dụng chúng như thế nào ở *Chương 3*.)
+Lệnh này sẽ truy cập vào dự án từ xa đó và kéo xuống toàn bộ dữ liệu mà bạn chưa có trong đó cho bạn. Sau khi thực hiện xong bước này, bạn đã có các tham chiếu đến toàn bộ các nhánh của dự án từ xa đó, nơi mà bạn có thể tích hợp hoặc kiểm tra bất kỳ thời điểm nào. (Chúng ta sẽ đề cập chi tiết hơn về nhánh là gì và sử dụng chúng như thế nào ở *Chương 3*.)
 
-Nếu bạn tạo bản sao từ một kho chứa nào đó khác, lệnh này sẽ tự động kho chứa từ xa đó vào dưới tên *origin*. Vì thế, `git fetch origin` sẽ truy xuất (fetch) bất kỳ thay đổi mới nào được đẩy lên trên máy chủ từ sau khi bạn sao chép (hoặc lần truy xuất cuối cùng). Hãy ghi nhớ một điều quan trọng là lệnh `fetch` kéo tất cả dữ liệu về kho chứa trên máy của bạn - nó không tự động gộp với bất kỳ thay đổi nào mà bạn đang thực hiện. Bạn phải gộp nó một cách thủ không vào kho chứa nội bộ khi đã sẵn sàng.
+Nếu bạn tạo bản sao từ một kho chứa nào đó khác, lệnh này sẽ tự động kho chứa từ xa đó vào dưới tên *origin*. Vì thế, `git fetch origin` sẽ truy xuất (fetch) bất kỳ thay đổi mới nào được đẩy lên trên máy chủ từ sau khi bạn sao chép (hoặc lần truy xuất cuối cùng). Hãy ghi nhớ một điều quan trọng là lệnh `fetch` kéo tất cả dữ liệu về kho chứa trên máy của bạn - nó không tự động tích hợp với bất kỳ thay đổi nào mà bạn đang thực hiện. Bạn phải tích hợp nó một cách thủ không vào kho chứa nội bộ khi đã sẵn sàng.
 
-Nếu bạn có một nhánh được cài đặt để theo dõi một nhánh từ xa khác (xem phần tiếp theo và *Chương 3* để biết thêm chi tiết), bạn có thể sử dụng lệnh `git pull` để tự động truy xuất và sau đó gộp nhánh từ xa vào nhánh nội bộ. Đây có thể là cách dễ dàng và thoải mái hơn cho bạn; và mặc định thì, lệnh `git clone` tự động cài đặt nhánh chính nội bộ (local master branch) để theo dõi nhanh chính trên máy chủ từ xa (remote master branch) - nơi mà bạn sao chép về, (giả sử máy chủ từ xa có một nhánh chính). Thường thì khi chạy lệnh `git pull` nó sẽ truy xuất dữ liệu từ máy chủ trung tâm nơi lần đầu bạn sao chép và cố gắng tự động gộp chúng vào kho chứa hiện thời nơi bạn đang làm việc. 
+Nếu bạn có một nhánh được cài đặt để theo dõi một nhánh từ xa khác (xem phần tiếp theo và *Chương 3* để biết thêm chi tiết), bạn có thể sử dụng lệnh `git pull` để tự động truy xuất và sau đó tích hợp nhánh từ xa vào nhánh nội bộ. Đây có thể là cách dễ dàng và thoải mái hơn cho bạn; và mặc định thì, lệnh `git clone` tự động cài đặt nhánh chính nội bộ (local master branch) để theo dõi nhanh chính trên máy chủ từ xa (remote master branch) - nơi mà bạn sao chép về, (giả sử máy chủ từ xa có một nhánh chính). Thường thì khi chạy lệnh `git pull` nó sẽ truy xuất dữ liệu từ máy chủ trung tâm nơi lần đầu bạn sao chép và cố gắng tự động tích hợp chúng vào kho chứa hiện thời nơi bạn đang làm việc. 
 
 ### Đẩy Lên Máy Chủ Trung Tâm ###
 
@@ -835,7 +835,7 @@ Nếu bạn có một nhánh được cài đặt để theo dõi một nhánh t
 
 	$ git push origin master
 
-Lệnh này chỉ hoạt động nếu bạn sao chép từ một máy chủ mà trên đó bạn được cấp phép quyền ghi và chưa có ai khác đẩy dữ liệu lên tại thời điểm đó. Nếu bạn và ai khác cùng sao chép tại cùng một thời điểm; người kia đẩy ngược lên, sau đó bạn cũng muốn đẩy lên, thì hành động của bạn sẽ bị từ chối ngay tức khắc. Trước hết bạn phải thực hiện kéo các thay đổi mà người đó đã thực hiện và sát nhập/gộp nó vào của bạn, sau đó bạn mới được phép đẩy lên. Xem *Chương 3* để hiểu chi tiết hơn về làm thế nào để đẩy lên máy chủ trung tâm. 
+Lệnh này chỉ hoạt động nếu bạn sao chép từ một máy chủ mà trên đó bạn được cấp phép quyền ghi và chưa có ai khác đẩy dữ liệu lên tại thời điểm đó. Nếu bạn và ai khác cùng sao chép tại cùng một thời điểm; người kia đẩy ngược lên, sau đó bạn cũng muốn đẩy lên, thì hành động của bạn sẽ bị từ chối ngay tức khắc. Trước hết bạn phải thực hiện kéo các thay đổi mà người đó đã thực hiện và tích hợp/gộp nó vào của bạn, sau đó bạn mới được phép đẩy lên. Xem *Chương 3* để hiểu chi tiết hơn về làm thế nào để đẩy lên máy chủ trung tâm. 
 
 ### Kiểm Tra Một Máy Chủ Trung Tâm ###
 
@@ -850,7 +850,7 @@ Nếu bạn muốn xem chi tiết hơn các thông tin về một kho chứa tru
 	    master
 	    ticgit
 
-Lệnh này liệt kê địa chỉ của kho chứa trung tâm cũng như thông tin các nhánh đang theo dõi. Nó cho bạn biết rằng nếu như bạn đang ở nhánh master và chạy lệnh git pull, nó sẽ tự động gộp nhánh này với nhánh trung tâm sau khi truy xuất toàn bộ các tham chiếu từ xa. Nó cũng liệt kê tất cả các tham chiếu từ xa mà nó đã kéo xuống đó.
+Lệnh này liệt kê địa chỉ của kho chứa trung tâm cũng như thông tin các nhánh đang theo dõi. Nó cho bạn biết rằng nếu như bạn đang ở nhánh master và chạy lệnh git pull, nó sẽ tự động tích hợp nhánh này với nhánh trung tâm sau khi truy xuất toàn bộ các tham chiếu từ xa. Nó cũng liệt kê tất cả các tham chiếu từ xa mà nó đã kéo xuống đó.
 
 Đây là một ví dụ đơn giản mà bạn thường xuyên gặp phải. Khi bạn sử dụng Git thường xuyên hơn, bạn sẽ thường thấy nhiều thông tin hơn từ lệnh `git remote show`:
 
@@ -876,7 +876,7 @@ Lệnh này liệt kê địa chỉ của kho chứa trung tâm cũng như thôn
 	  Local branch pushed with 'git push'
 	    master:master
 
-Lệnh này hiển thị nhánh nào tự động được đẩy lên khi bạn chạy `git push` trên một nhánh nhất định. Nó cũng cho bạn thấy nhánh nào trên máy chủ trung tâm mà bạn chưa có, nhánh nào bạn có mà đã bị xóa trên máy chủ, và các nhánh nào sẽ tự động được gộp khi chạy lệnh `git pull`. 
+Lệnh này hiển thị nhánh nào tự động được đẩy lên khi bạn chạy `git push` trên một nhánh nhất định. Nó cũng cho bạn thấy nhánh nào trên máy chủ trung tâm mà bạn chưa có, nhánh nào bạn có mà đã bị xóa trên máy chủ, và các nhánh nào sẽ tự động được tích hợp khi chạy lệnh `git pull`. 
 
 ### Xóa Và Đổi Tên Từ Xa ###
 
diff --git a/vi/03-git-branching/01-chapter3.markdown b/vi/03-git-branching/01-chapter3.markdown
index 8924dbe5e..6feadfe84 100644
--- a/vi/03-git-branching/01-chapter3.markdown
+++ b/vi/03-git-branching/01-chapter3.markdown
@@ -1,152 +1,152 @@
-# Git Branching #
+# Phân Nhánh Trong Git #
 
-Nearly every VCS has some form of branching support. Branching means you diverge from the main line of development and continue to do work without messing with that main line. In many VCS tools, this is a somewhat expensive process, often requiring you to create a new copy of your source code directory, which can take a long time for large projects.
+Hầu hết mỗi hệ quản trị phiên bản (VCS) đều hỗ trợ một dạng của phân nhánh. Phân nhánh có nghĩa là bạn phân tách ra từ luồng phát triển chính và tiếp tục làm việc mà không sợ làm ảnh hưởng đến luồng chính. Trong nhiều VCS, đây dường như là một quá trình đòi hỏi nhiều công sức và sự cố gắng, thường thì bạn tạo một bản sao mới từ thư mục chứa mã nguồn, nó có thể mất khá nhiều thời gian trên các dự án lớn.
 
-Some people refer to the branching model in Git as its “killer feature”  , and it certainly sets Git apart in the VCS community. Why is it so special? The way Git branches is incredibly lightweight, making branching operations nearly instantaneous and switching back and forth between branches generally just as fast. Unlike many other VCSs, Git encourages a workflow that branches and merges often, even multiple times in a day. Understanding and mastering this feature gives you a powerful and unique tool and can literally change the way that you develop.
+Nhiều người nhắc đến mô hình phân nhánh của Git như là "chức năng hủy diệt", và chính nó làm cho Git trở nên khác biệt trong cộng đồng VCS. Tại sao nó lại đặc biệt đến vậy? Cách Git phân nhánh "nhẹ" một cách đáng kinh ngạc, các hoạt động tạo nhánh xảy ra gần như ngay lập tức và việc di chuyển đi lại giữa các nhánh cũng thường rất nhanh. Không giống các VCSs khác, Git khuyến khích sử dụng rẽ nhánh và tích hợp thường xuyên cho workflow, thậm chí nhiều lần trong một ngày. Hiểu và thành thạo tính năng này cung cấp cho bạn một công cụ mạnh mẽ, độc đáo và có thể thay đổi được cách bạn thường phát triển phần mềm.
 
-## What a Branch Is ##
+## Nhánh Là Gì? ##
 
-To really understand the way Git does branching, we need to take a step back and examine how Git stores its data. As you may remember from Chapter 1, Git doesn’t store data as a series of changesets or deltas, but instead as a series of snapshots.
+Để có thể thực sử hiểu được cách phân nhánh của Git, chúng ta cần nhìn và xem xét lại cách Git lưu trữ dữ liệu. Như bạn đã biết từ Chương 1, Git không lưu trữ dữ liệu dưới dạng một chuỗi các thay đổi hoặc delta, mà thay vào đó là một chuỗi các ảnh (snapshot).
 
-When you commit in Git, Git stores a commit object that contains a pointer to the snapshot of the content you staged, the author and message metadata, and zero or more pointers to the commit or commits that were the direct parents of this commit: zero parents for the first commit, one parent for a normal commit, and multiple parents for a commit that results from a merge of two or more branches.
+Khi bạn commit, Git lưu trữ đối tượng commit mà có chứa một con trỏ tới ảnh của nội dung bạn đã tổ chức (stage), tác giả và thông điệp, hay 0 hoặc nhiều con trỏ khác trỏ tới một hoặc nhiều commit cha trực tiếp của commit đó: commit đầu tiên không có cha, commit bình thường có một cha, và nhiều cha cho commit là kết quả được tích hợp lại từ hai hoặc nhiều nhánh.
 
-To visualize this, let’s assume that you have a directory containing three files, and you stage them all and commit. Staging the files checksums each one (the SHA-1 hash we mentioned in Chapter 1), stores that version of the file in the Git repository (Git refers to them as blobs), and adds that checksum to the staging area:
+Để hình dung ra vấn đề này, hãy giả sử bạn có một thư mục chứa ba tập tin, và bạn tổ chức tất cả chúng để commit. Quá trình tổ chức các tập tin sẽ thực hiện băm từng tập (sử dụng mã SHA-1 được đề cập ở Chương 1), lưu trữ phiên bản đó của tập tin trong kho chứa Git (Git xem chúng như là các blob), và thêm mã băm đó vào khu vực tổ chức:
 
 	$ git add README test.rb LICENSE
 	$ git commit -m 'initial commit of my project'
 
-Running `git commit` checksums all project directories and stores them as `tree` objects in the Git repository. Git then creates a `commit` object that has the metadata and a pointer to the root project `tree` object so it can re-create that snapshot when needed.
+Lệnh `git commit` khi chạy sẽ băm tất cả các thư mục trong dự án và lưu chúng lại dưới dạng đối tượng `tree`. Sau đó Git tạo một đối tượng `commit` có chứa các thông tin mô tả (metadata) và một con trỏ trỏ tới đối tương `tree` gốc của dự án vì thế nó có thể tạo lại ảnh đó khi cần thiết.
 
-Your Git repository now contains five objects: one blob for the contents of each of your three files, one tree that lists the contents of the directory and specifies which file names are stored as which blobs, and one commit with the pointer to that root tree and all the commit metadata. Conceptually, the data in your Git repository looks something like Figure 3-1.
+Kho chứa Git của bạn bây giờ có chứa năm đối tượng: một blob cho nội dung của từng tập tin, một "cây" liệt kê nội dung của thư mục và chỉ rõ tên tập tin nào được lưu trữ trong blob nào, và một commit có con trỏ trỏ tới cây gốc và tất cả các thông tin mô tả commit. Về mặt lý thuyết, dữ liệu trong kho chứa Git có hình dạng như trong Hình 3-1. 
 
 Insert 18333fig0301.png
-Figure 3-1. Single commit repository data.
+Hình 3-1. Dữ liệu trong kho chứa với một commit.
 
-If you make some changes and commit again, the next commit stores a pointer to the commit that came immediately before it. After two more commits, your history might look something like Figure 3-2.
+Nếu bạn thực hiện một số thay đổi và commit lại thì commit tiếp theo sẽ lưu một con trỏ tới commit ngay trước nó. Sau hai commit, lịch sử của dự án sẽ tương tự như trong Hình 3-2.
 
 Insert 18333fig0302.png
-Figure 3-2. Git object data for multiple commits.
+Hình 3-2. Các đối tượng dữ liệu của Git trong kho chứa nhiều commit. 
 
-A branch in Git is simply a lightweight movable pointer to one of these commits. The default branch name in Git is master. As you initially make commits, you’re given a `master` branch that points to the last commit you made. Every time you commit, it moves forward automatically.
+Một nhánh trong Git đơn thuần là một con trỏ có khả năng di chuyển được, trỏ đến một trong những commit này. Tên nhánh mặc định của Git là master. Như trong những lần commit đầu tiên, chúng đều được trỏ tới nhánh `master`. Và mỗi lần bạn thực hiện commit, nó sẽ được tự động ghi vào theo hướng tiến lên. (move forward)
 
 Insert 18333fig0303.png
-Figure 3-3. Branch pointing into the commit data’s history.
+Hình 3-3. Nhánh trỏ tới dữ liệu commit.
 
-What happens if you create a new branch? Well, doing so creates a new pointer for you to move around. Let’s say you create a new branch called testing. You do this with the `git branch` command:
+Chuyện gì xảy ra nếu bạn tạo một nhánh mới? Làm như vậy sẽ tạo ra một con trỏ mới cho phép bạn di chuyển vòng quanh. Ví dụ bạn tạo một nhánh mới có tên testing. Việc này được thực hiện bằng lệnh `git branch`:
 
 	$ git branch testing
 
-This creates a new pointer at the same commit you’re currently on (see Figure 3-4).
+Nó sẽ tạo một con trỏ mới, cùng trỏ tới commit hiện tại (mới nhất) của bạn (xem Hình 3-4).
 
 Insert 18333fig0304.png
-Figure 3-4. Multiple branches pointing into the commit’s data history.
+Hình 304. Nhiều nhánh cùng trỏ vào dữ liệu commit.
 
-How does Git know what branch you’re currently on? It keeps a special pointer called HEAD. Note that this is a lot different than the concept of HEAD in other VCSs you may be used to, such as Subversion or CVS. In Git, this is a pointer to the local branch you’re currently on. In this case, you’re still on master. The git branch command only created a new branch — it didn’t switch to that branch (see Figure 3-5).
+Vậy làm sao Git có thể biết được rằng bạn đang làm việc trên nhánh nào? Git giữ một con trỏ đặc biệt có tên HEAD. Lưu ý khái niệm về HEAD ở đây khác biệt hoàn toàn với các VCS khác mà bạn có thể đã sử dụng qua, như là Subversion hoặc CVS. Trong Git, đây là một con trỏ tới nhánh nội bộ mà bạn đang làm việc. Trong trường hợp này, bạn vẫn đang trên nhánh master. Lệnh git branch chỉ tạo một nhánh mới chứ không tự chuyển sang nhánh đó cho bạn (xem Hình 3-5).
 
 Insert 18333fig0305.png
-Figure 3-5. HEAD file pointing to the branch you’re on.
+Hình 3-5. Tập tin HEAD trỏ tới nhánh mà bạn đang làm việc.
 
-To switch to an existing branch, you run the `git checkout` command. Let’s switch to the new testing branch:
+Để chuyển sang một nhánh đang tồn tại, bạn sử dụng lệnh `git checkout`. Hãy cùng chuyển sang nhánh testing mới:
 
 	$ git checkout testing
 
-This moves HEAD to point to the testing branch (see Figure 3-6).
+Lệnh này sẽ chuyển con trỏ HEAD sang nhánh testing (xem Hình 3-6).
 
 Insert 18333fig0306.png
-Figure 3-6. HEAD points to another branch when you switch branches.
+Hình 3-6. HEAD trỏ tới nhánh khác khi bạn chuyển nhánh.
 
-What is the significance of that? Well, let’s do another commit:
+Ý nghĩa của việc này là gì? Hãy cùng thực hiện một commit khác:
 
 	$ vim test.rb
 	$ git commit -a -m 'made a change'
 
-Figure 3-7 illustrates the result.
+Hình 3-7 minh họa kết quả.
 
 Insert 18333fig0307.png
-Figure 3-7. The branch that HEAD points to moves forward with each commit.
+Hình 3-7. Nhánh mà HEAD trỏ tới di chuyển tiến lên phía trước theo từng commit.
 
-This is interesting, because now your testing branch has moved forward, but your `master` branch still points to the commit you were on when you ran `git checkout` to switch branches. Let’s switch back to the `master` branch:
+Điều này thật thú vị, bởi vì nhánh testing của bạn bây giờ đã tiển hẳn lên phía trước, nhưng nhánh `master` thì vẫn trỏ tới commit ở thời điểm khi bạn chạy lệnh `git checkout` để chuyển nhánh. Hãy cùng chuyển trở lại nhánh `master`:
 
 	$ git checkout master
 
-Figure 3-8 shows the result.
+Hình 3-8 hiển thị kết quả.
 
 Insert 18333fig0308.png
-Figure 3-8. HEAD moves to another branch on a checkout.
+Hình 3-8. HEAD chuyển sang nhánh khác khi checkout.
 
-That command did two things. It moved the HEAD pointer back to point to the `master` branch, and it reverted the files in your working directory back to the snapshot that `master` points to. This also means the changes you make from this point forward will diverge from an older version of the project. It essentially rewinds the work you’ve done in your testing branch temporarily so you can go in a different direction.
+Lệnh này vừa thực hiện hai việc. Nó di chuyển lại con trỏ về nhánh `master`, và sau đó nó phục hồi lại các tập tin trong thư mục làm việc của bạn trở lại snapshot mà `master` trỏ tới. Điều này cũng có nghĩa là các thay đổi bạn thực hiện từ thời điểm này trở đi sẽ tách ra so với phiên bản cũ hơn của dự án. Nó "tua lại" các thay đổi cần thiết mà bạn đã thực hiện trên nhánh `testing` một cách tạm thời để bạn có thể đi theo một hướng khác.
 
-Let’s make a few changes and commit again:
+Hãy cùng tạo một vài thay đổi và commit lại một lần nữa:
 
 	$ vim test.rb
 	$ git commit -a -m 'made other changes'
 
-Now your project history has diverged (see Figure 3-9). You created and switched to a branch, did some work on it, and then switched back to your main branch and did other work. Both of those changes are isolated in separate branches: you can switch back and forth between the branches and merge them together when you’re ready. And you did all that with simple `branch` and `checkout` commands.
+Bây giờ lịch sử của dự án đã bị tách ra (xem Hình 3-9). Bạn tạo mới và chuyển sang một nhánh, thực hiện một số thay đổi trên đó, và rồi chuyển ngược lại nhánh chính và tạo thêm các thay đổi khác. Cả hai sự thay đổi này bị cô lập với nhau ở hai nhánh riêng biệt: bạn có thể chuyển đi hoặc lại giữa cách nhánh và tích hợp chúng lại với nhau khi cần thiết. Và bạn đã thực hiện những việc trên một cách đơn giản với lệnh `branch` và `checkout`.
 
 Insert 18333fig0309.png
-Figure 3-9. The branch histories have diverged.
+Hình 3-9. Lịch sử các nhánh đã bị phân tách.
 
-Because a branch in Git is in actuality a simple file that contains the 40 character SHA-1 checksum of the commit it points to, branches are cheap to create and destroy. Creating a new branch is as quick and simple as writing 41 bytes to a file (40 characters and a newline).
+Bởi vì một nhánh trong Git thực tế là một tập tin đơn giản chứa một mã băm SHA-1 có độ dài 40 ký tự của commit mà nó trỏ tới, chính vì thế tạo mới cũng như hủy các nhánh đi rất đơn giản. Tạo mới một nhánh nhanh tương đương với việc ghi 41 bytes vào một tập tin (40 ký tự cộng thêm một dòng mới).
 
-This is in sharp contrast to the way most VCS tools branch, which involves copying all of the project’s files into a second directory. This can take several seconds or even minutes, depending on the size of the project, whereas in Git the process is always instantaneous. Also, because we’re recording the parents when we commit, finding a proper merge base for merging is automatically done for us and is generally very easy to do. These features help encourage developers to create and use branches often.
+Điều này đối lập rất lớn với cách mà các VCS khác phân nhánh, chính là copy toàn bộ các tập tin hiện có của dự án sang một thư mục thứ hai. Việc này có thể mất khoảng vài giây, thậm chí vài phút, phụ thuộc vào dung lượng của dự án, trong khi đó trong Git thì quá trình này luôn xảy ra ngay lập tức. Thêm một lý do nữa là, chúng ta đang lưu trữ cha của các commit, nên việc tìm kiếm gốc/cơ sở để tích hợp lại được thực hiện một cách tự động và rất dễ dàng. Những tính năng này giúp khuyến khích các lập trình viên tạo và sử dụng nhánh thường xuyên hơn.
 
-Let’s see why you should do so.
+Hãy cùng xem tại sao bạn nên làm như vậy.
 
-## Basic Branching and Merging ##
+## Cơ Bản Về Phân Nhánh và Tích Hợp ##
 
-Let’s go through a simple example of branching and merging with a workflow that you might use in the real world. You’ll follow these steps:
+Hãy cùng xem qua một ví dụ đơn giản về phân nhánh và tích hợp với một quy trình làm việc mà có thể bạn sẽ sử dụng nó vào thực tế. Bạn sẽ thực hiện theo các bước sau: 
 
-1. Do work on a web site.
-2. Create a branch for a new story you’re working on.
-3. Do some work in that branch.
+1. Làm việc trên một web site
+2. Tạo nhánh cho một câu chuyện mới mà bạn đang làm.
+3. Làm việc trên nhánh đó.
 
-At this stage, you’ll receive a call that another issue is critical and you need a hotfix. You’ll do the following:
+Đến lúc này, bạn nhận được thông báo rằng có một vấn đề nghiêm trọng cần được khắc phục ngay. Bạn sẽ làm theo các bước sau:
 
-1. Revert back to your production branch.
-2. Create a branch to add the hotfix.
-3. After it’s tested, merge the hotfix branch, and push to production.
-4. Switch back to your original story and continue working.
+1. Chuyển lại về nhánh sản xuất (production)
+2. Tạo mới một nhánh khác để khắc phục lỗi
+3. Sau khi đã kiểm tra ổn định, tích hợp nhánh đó lại và đưa vào hoạt động.
+4. Chuyển ngược lại với câu chuyện của bạn và tiếp tục làm việc.
 
-### Basic Branching ###
+### Cơ Bản về Phân Nhánh ###
 
-First, let’s say you’re working on your project and have a couple of commits already (see Figure 3-10).
+Đầu tiên, giả sử bạn đang làm việc trên một dự án đã có một số commit từ trước (xem Hình 3-10).
 
 Insert 18333fig0310.png
-Figure 3-10. A short and simple commit history.
+Hình 3-10. Một lịch sử commit ngắn và đơn giản.
 
-You’ve decided that you’re going to work on issue #53 in whatever issue-tracking system your company uses. To be clear, Git isn’t tied into any particular issue-tracking system; but because issue #53 is a focused topic that you want to work on, you’ll create a new branch in which to work. To create a branch and switch to it at the same time, you can run the `git checkout` command with the `-b` switch:
+Bạn quyết định sẽ giải quyết vấn đề số #53 sử dụng bất kỳ hệ thống giám sát vấn đề (issue-tracking) nào mà công ty bạn đang dùng. Để cho rõ ràng, Git không cung cấp kèm bất kỳ hệ thống giám sát vấn đề nào; nhưng bởi vì vấn đề số #53 là cái mà bạn sẽ tập trung vào nên bạn sẽ tạo một nhánh mới để làm việc trên đó. Để tạo một nhánh và chuyển sang nhánh đó đồng thời, bạn có thể chạy lệnh `git checkout` với tham số `-b`:
 
 	$ git checkout -b iss53
 	Switched to a new branch "iss53"
 
-This is shorthand for:
+Đây là cách sử dụng vắn tắt của:
 
 	$ git branch iss53
 	$ git checkout iss53
 
-Figure 3-11 illustrates the result.
+Hình 3-11 minh họa kết quả.
 
 Insert 18333fig0311.png
-Figure 3-11. Creating a new branch pointer.
+Hình 3-11. Tạo con trỏ nhánh mới.
 
-You work on your web site and do some commits. Doing so moves the `iss53` branch forward, because you have it checked out (that is, your HEAD is pointing to it; see Figure 3-12):
+Bạn làm việc trên đó và sau đó thực hiện một số commit. Làm như vậy sẽ khiến nhánh `iss53` di chuyển tiến lên, vì bạn đã checkout nó (hay, HEAD đang trỏ đến nó; xem Hình 3-12):
 
 	$ vim index.html
 	$ git commit -a -m 'added a new footer [issue 53]'
 
 Insert 18333fig0312.png
-Figure 3-12. The iss53 branch has moved forward with your work.
+Hình 3-12. Nhánh iss53 đã di chuyển tiến lên cùng với thay đổi của bạn.
 
-Now you get the call that there is an issue with the web site, and you need to fix it immediately. With Git, you don’t have to deploy your fix along with the `iss53` changes you’ve made, and you don’t have to put a lot of effort into reverting those changes before you can work on applying your fix to what is in production. All you have to do is switch back to your master branch.
+Bây giờ bạn nhận được thông báo rằng có một vấn đề với trang web, và bạn cần khắc phục nó ngay lập tức. Với Git, bạn không phải triển khai bản vá lỗi cùng với các thay đổi bạn đã thực hiện trên nhánh `iss53`, và bạn không phải tốn quá nhiều công sức để khôi phục lại các thay đổi đó trước khi áp dụng bản vá vào sản xuất. Tất cả những gì bạn cần phải làm là chuyển lại nhánh master.
 
-However, before you do that, note that if your working directory or staging area has uncommitted changes that conflict with the branch you’re checking out, Git won’t let you switch branches. It’s best to have a clean working state when you switch branches. There are ways to get around this (namely, stashing and commit amending) that we’ll cover later. For now, you’ve committed all your changes, so you can switch back to your master branch:
+Tuy nhiên, trước khi làm điều này, bạn nên lưu ý rằng nếu thư mục làm việc hoặc khu vực tổ chức có chứa các thay đổi chưa được commit mà xung đột với nhánh bạn đang làm việc, Git sẽ không cho phép bạn chuyển nhánh. Tốt nhất là bạn nên ở trạng thái làm việc "sạch" (đã commit hết) trước khi chuyển nhánh. Có các cách khác để khắc phục vấn đề này (đó là stashing và sửa commit) mà chúng ta sẽ bàn tới sau. Hiện tại, bạn đã commit hết các thay đổi, vì vậy bạn có thể chuyển lại nhánh master:
 
 	$ git checkout master
 	Switched to branch "master"
 
-At this point, your project working directory is exactly the way it was before you started working on issue #53, and you can concentrate on your hotfix. This is an important point to remember: Git resets your working directory to look like the snapshot of the commit that the branch you check out points to. It adds, removes, and modifies files automatically to make sure your working copy is what the branch looked like on your last commit to it.
+Tại thời điểm này, thư mục làm việc của dự án giống hệt như trước khi bạn bắt đầu giải quyết vấn đề #53, và bạn có thể tập trung vào việc sửa lỗi. Điểm quan trọng cần ghi nhớ: Git khôi phục lại thư mục làm việc của bạn để nó giống như snapshot của commit mà nhánh bạn đang làm việc trỏ tới. Nó thêm, xóa, và sửa các tập tin một cách tự động để đảm bảo rằng thư mục làm việc của bạn giống như lần commit cuối cùng.
 
-Next, you have a hotfix to make. Let’s create a hotfix branch on which to work until it’s completed (see Figure 3-13):
+Tiếp theo, bạn có mỗi lỗi cần phải sửa. Hãy tạo mỗi nhánh để làm việc này cho tới khi nó được hoàn thành (xem Hình 3-13):
 
 	$ git checkout -b hotfix
 	Switched to a new branch "hotfix"
@@ -156,9 +156,9 @@ Next, you have a hotfix to make. Let’s create a hotfix branch on which to work
 	 1 files changed, 0 insertions(+), 1 deletions(-)
 
 Insert 18333fig0313.png
-Figure 3-13. hotfix branch based back at your master branch point.
+Hình 3-13. Nhánh hotfix dựa trên nhánh master.
 
-You can run your tests, make sure the hotfix is what you want, and merge it back into your master branch to deploy to production. You do this with the `git merge` command:
+Bạn có thể chạy để kiểm tra, để chắc chắn rằng bản vá lỗi hoạt động đúng theo ý bạn muốn, và sau đó tích hợp nó lại nhánh chính để triển khai. Bạn có thể làm sử dụng lệnh `git merge` để làm việc này:
 
 	$ git checkout master
 	$ git merge hotfix
@@ -167,19 +167,19 @@ You can run your tests, make sure the hotfix is what you want, and merge it back
 	 README |    1 -
 	 1 files changed, 0 insertions(+), 1 deletions(-)
 
-You’ll notice the phrase "Fast forward" in that merge. Because the commit pointed to by the branch you merged in was directly upstream of the commit you’re on, Git moves the pointer forward. To phrase that another way, when you try to merge one commit with a commit that can be reached by following the first commit’s history, Git simplifies things by moving the pointer forward because there is no divergent work to merge together — this is called a "fast forward".
+Bạn sẽ nhận thấy rằng cụm từ "Fast forward" trong lần tích hợp đó. Bởi vì commit được trở tới bởi nhánh mà bạn tích hợp vào lại trực tiếp là upstream của commit hiện tại, vì vậy Git di chuyển con trỏ về phía trước. Nói cách khác, khi bạn cố gắng tích hợp một commit với một commit khác mà có thể truy cập được từ lịch sử của commit trước thì Git sẽ đơn giản hóa bằng cách di chuyển con trỏ về phía trước vì không có sự rẽ nhánh nào để tích hợp - đây được gọi là "fast forward".
 
-Your change is now in the snapshot of the commit pointed to by the `master` branch, and you can deploy your change (see Figure 3-14).
+Thay đổi của bạn bây giờ ở trong snapshot của commit được trỏ tới bởi nhánh `master`, và bạn có thể triển khai thay đổi này (xem Hình 3-14).
 
 Insert 18333fig0314.png
-Figure 3-14. Your master branch points to the same place as your hotfix branch after the merge.
+Hình 3-14. Nhánh master và nhánh hotfix cùng trỏ tới một điểm sau khi tích hợp.
 
-After your super-important fix is deployed, you’re ready to switch back to the work you were doing before you were interrupted. However, first you’ll delete the `hotfix` branch, because you no longer need it — the `master` branch points at the same place. You can delete it with the `-d` option to `git branch`:
+Sau khi triển khai xong bản vá lỗi quan trọng đó, bạn đã sẵn sàng để quay lại với công việc bị gián đoạn trước đó. Tuy nhiên, việc đầu tiên cần làm là xóa nhánh `hotfix` đi, vì bạn không còn cần tới nó nữa - nhánh `master` trỏ tới cùng một điểm. Bạn có thể xóa nó đi bằng cách sử dụng tham số `-d` cho lệnh `git branch`:
 
 	$ git branch -d hotfix
 	Deleted branch hotfix (3a0874c).
 
-Now you can switch back to your work-in-progress branch on issue #53 and continue working on it (see Figure 3-15):
+Bây giờ bạn đã có thể chuyển lại nhánh mà bạn đang làm việc trước đó về vấn đề #53 và tiếp tục làm việc (xem Hình 3-15):
 
 	$ git checkout iss53
 	Switched to branch "iss53"
@@ -189,13 +189,13 @@ Now you can switch back to your work-in-progress branch on issue #53 and continu
 	 1 files changed, 1 insertions(+), 0 deletions(-)
 
 Insert 18333fig0315.png
-Figure 3-15. Your iss53 branch can move forward independently.
+Hình 3-15. Nhánh iss53 có thể di chuyển về phía trước một cách độc lập.
 
-It’s worth noting here that the work you did in your `hotfix` branch is not contained in the files in your `iss53` branch. If you need to pull it in, you can merge your `master` branch into your `iss53` branch by running `git merge master`, or you can wait to integrate those changes until you decide to pull the `iss53` branch back into `master` later.
+Điều đáng chú ý ở đây là những công việc bạn đã thực hiện ở nhánh `hotfix` không bao gồm trong nhánh `iss53`. Nếu bạn muốn đưa chúng vào, bạn có thể tích hợp nhánh `master` vào nhánh `iss53` bằng cách chạy lệnh `git merge master`, hoặc bạn có thể chờ đợi đến khi bạn quyết định tích hợp nhánh `iss53` ngược trở lại nhánh `master` về sau.
 
-### Basic Merging ###
+### Cơ Bản Về Tích Hợp ###
 
-Suppose you’ve decided that your issue #53 work is complete and ready to be merged into your `master` branch. In order to do that, you’ll merge in your `iss53` branch, much like you merged in your `hotfix` branch earlier. All you have to do is check out the branch you wish to merge into and then run the `git merge` command:
+Giả sử bạn đã quyết định việc giải quyết vấn đề #53 đã hoàn thành và sẵn sàng để tích hợp vào nhánh `master`. Để làm được điều này, bạn sẽ tích hợp nhánh `iss53` lại, giống như bạn đã làm với nhánh `hotfix` trước đó. Tất cả những gì cần phải làm là chuyển sang (check out) nhánh mà bạn muốn được tích hợp vào và chạy lệnh `git merge`:
 
 	$ git checkout master
 	$ git merge iss53
@@ -203,32 +203,32 @@ Suppose you’ve decided that your issue #53 work is complete and ready to be me
 	 README |    1 +
 	 1 files changed, 1 insertions(+), 0 deletions(-)
 
-This looks a bit different than the `hotfix` merge you did earlier. In this case, your development history has diverged from some older point. Because the commit on the branch you’re on isn’t a direct ancestor of the branch you’re merging in, Git has to do some work. In this case, Git does a simple three-way merge, using the two snapshots pointed to by the branch tips and the common ancestor of the two. Figure 3-16 highlights the three snapshots that Git uses to do its merge in this case.
+Lần này có hơi khác so với lần tích hợp `hotfix` trước đó. Trong trường hợp này, lịch sử phát triển của bạn đã bị phân nhánh tại một thời điểm nào đó trước kia. Bởi vì commit trên nhánh mà bạn đang làm việc (master) không phải là "cha" trực tiếp của nhánh mà bạn đang tích hợp vào, Git phải làm một số việc. Trường hợp này, Git thực hiện một tích hợp 3-chiều, sử dụng hai snapshot được trỏ tới bởi các đầu mút của nhánh và "cha chung" của cả hai. Hình 3-16 minh họa ba snapshot mà Git sử dụng để thực hiện phép tích hợp trong trường hợp này.
 
 Insert 18333fig0316.png
-Figure 3-16. Git automatically identifies the best common-ancestor merge base for branch merging.
+Hình 3-16. Git tự động nhận dạng "cha chung" phù hợp nhất để tích hợp các nhánh lại với nhau.
 
-Instead of just moving the branch pointer forward, Git creates a new snapshot that results from this three-way merge and automatically creates a new commit that points to it (see Figure 3-17). This is referred to as a merge commit and is special in that it has more than one parent.
+Thay vì việc chỉ di chuyển con trỏ về phía trước, Git tạo một snapshot mới - được hợp thành từ lần tích hợp 3-chiều này và cũng tự tạo một commit mới trỏ tới nó (xem Hình 3-17). Nó được biết tới như là "commit tích hợp" (merge commit) và nó đặc biệt vì có nhiều hơn một cha.
 
-It’s worth pointing out that Git determines the best common ancestor to use for its merge base; this is different than CVS or Subversion (before version 1.5), where the developer doing the merge has to figure out the best merge base for themselves. This makes merging a heck of a lot easier in Git than in these other systems.
+Đáng để chỉ ra rằng Git tự quyết định cha chung phù hợp nhất để sử dụng làm cơ sở cho việc tích hợp; điểm này khác với CVS hay Subversion (các phiên bản trước 1.5), khi mà các lập trình viên phải tự xác định cơ sở phù hợp nhất để tích hợp. Điều này khiến cho việc tích hợp trong Git trở nên dễ dàng hơn rất nhiều so với các hệ quản trị phiên bản khác.
 
 Insert 18333fig0317.png
-Figure 3-17. Git automatically creates a new commit object that contains the merged work.
+Hình 3-17. Git tự động tạo đối tượng commit mới chứa đựng các thay đổi đã tích hợp.
 
-Now that your work is merged in, you have no further need for the `iss53` branch. You can delete it and then manually close the ticket in your ticket-tracking system:
+Bây giờ công việc của bạn đã được tích hợp lại với nhau, bạn không cần thiết phải giữ lại nhánh `iss53` nữa. Bạn có thể xóa nó đi và sau đó tự xóa vấn đề này trong hệ thống quản lý vấn đề của bạn:
 
 	$ git branch -d iss53
 
-### Basic Merge Conflicts ###
+### Mâu Thuẫn Khi Tích Hợp ###
 
-Occasionally, this process doesn’t go smoothly. If you changed the same part of the same file differently in the two branches you’re merging together, Git won’t be able to merge them cleanly. If your fix for issue #53 modified the same part of a file as the `hotfix`, you’ll get a merge conflict that looks something like this:
+Đôi khi, quá trình này không diễn ra một cách suôn sẻ. Nếu bạn thay đổi cùng một nội dung của cùng một tập tin ở hai nhánh khác nhau mà bạn đang muốn tích hợp vào, Git không thể tích hợp chúng một cách gọn gàng. Nếu bản vá lỗi cho vấn đề #53 cùng thay đổi một phần của một tập tin giống như nhánh `hotfix`, bạn sẽ nhận được một sự xung đột khi tiến hành tích hợp như sau:
 
 	$ git merge iss53
 	Auto-merging index.html
 	CONFLICT (content): Merge conflict in index.html
 	Automatic merge failed; fix conflicts and then commit the result.
 
-Git hasn’t automatically created a new merge commit. It has paused the process while you resolve the conflict. If you want to see which files are unmerged at any point after a merge conflict, you can run `git status`:
+Git chưa tự tạo commit tích hợp mới. Nó tạm dừng quá trình này lại cho đến khi bạn giải quyết xong xung đột. Nếu bạn muốn xem tập tin nào chưa được tích hợp tại bất kỳ thời điểm nào sau khi xung đột xảy ra, bạn có thể sử dụng lệnh `git status`:
 
 	[master*]$ git status
 	index.html: needs merge
@@ -240,7 +240,7 @@ Git hasn’t automatically created a new merge commit. It has paused the process
 	#	unmerged:   index.html
 	#
 
-Anything that has merge conflicts and hasn’t been resolved is listed as unmerged. Git adds standard conflict-resolution markers to the files that have conflicts, so you can open them manually and resolve those conflicts. Your file contains a section that looks something like this:
+Với bất kỳ xung đột nào xảy ra mà chưa được giải quyết, chúng sẽ được liệt kê là unmerged (chưa được tích hợp). Git thêm các dấu hiệu chuẩn riêng để giải quyết xung đột vào các tập tin có xảy ra xung đột, vì thế bạn có thể mở và giải quyết các xung đột đó một cách thủ công. Tập tin của bạn sẽ chứa một phần tương tự như sau:
 
 	<<<<<<< HEAD:index.html
 	<div id="footer">contact : email.support@github.com</div>
@@ -250,14 +250,13 @@ Anything that has merge conflicts and hasn’t been resolved is listed as unmerg
 	</div>
 	>>>>>>> iss53:index.html
 
-This means the version in HEAD (your master branch, because that was what you had checked out when you ran your merge command) is the top part of that block (everything above the `=======`), while the version in your `iss53` branch looks like everything in the bottom part. In order to resolve the conflict, you have to either choose one side or the other or merge the contents yourself. For instance, you might resolve this conflict by replacing the entire block with this:
+Điều này có nghĩa là phiên bản trong HEAD (nhánh master, vì nó là nhánh bạn đã check out khi chạy lệnh merge) là phần mới nhất của đoạn đó (mọi thứ phía trên `=======`), trong khi phiên bản ở nhánh `iss53` chính là phần phía dưới. Để giải quyết vấn đề này, bạn phải chọn một trong hai phần hoặc tự gộp nội dung của chúng lại. Ví dụ, có thể bạn giải quyết xung đột này bằng cách thay thế toàn bộ đoạn code đó bằng:
 
 	<div id="footer">
 	please contact us at email.support@github.com
 	</div>
 
-This resolution has a little of each section, and I’ve fully removed the `<<<<<<<`, `=======`, and `>>>>>>>` lines. After you’ve resolved each of these sections in each conflicted file, run `git add` on each file to mark it as resolved. Staging the file marks it as resolved in Git.
-If you want to use a graphical tool to resolve these issues, you can run `git mergetool`, which fires up an appropriate visual merge tool and walks you through the conflicts:
+Cách giải quyết này có chứa nội dung của cả hai phần, và tôi đã xóa bỏ hoàn toàn các dòng `<<<<<<<`, `=======`, và `>>>>>>>`. Sau khi giải quyết xong tất cả các phần này trong các tập tin bị xung đột, chạy lệnh `git add` cho từng tập tin để đánh dấu là chúng đã được giải quyết. Tổ chức chúng cùng đồng nghĩa với việc đánh dấu là đã được giải quyết trong Git. Nếu bạn muốn sử dụng một công cụ có giao diện đồ họa để giải quyết những vấn đề này, bạn có thể sử dụng `git mergetool`, Git sẽ tự động mở chương trình tương ứng và trợ giúp bạn giải quyết các xung đột: 
 
 	$ git mergetool
 	merge tool candidates: kdiff3 tkdiff xxdiff meld gvimdiff opendiff emerge vimdiff
@@ -268,11 +267,11 @@ If you want to use a graphical tool to resolve these issues, you can run `git me
 	  {remote}: modified
 	Hit return to start merge resolution tool (opendiff):
 
-If you want to use a merge tool other than the default (Git chose `opendiff` for me in this case because I ran the command on a Mac), you can see all the supported tools listed at the top after “merge tool candidates”. Type the name of the tool you’d rather use. In Chapter 7, we’ll discuss how you can change this default value for your environment.
+Nếu bạn muốn sử dụng một công cụ tích hợp khác thay vì chương trình mặc định (Git sử dụng `opendiff` cho tôi trong trường hợp này vì tôi đang sử dụng một máy tính Mac), bạn có thể xem danh sách các chương trình tương thích bằng cách chạy lệnh "merge tool candidates". Gõ tên chương trình bạn muốn sử dung. Trong Chương 7, chúng ta sẽ cùng bàn luận về việc làm thế nào để thay đổi giá trị mặc định này.
 
-After you exit the merge tool, Git asks you if the merge was successful. If you tell the script that it was, it stages the file to mark it as resolved for you.
+Sau khi thoát khỏi chương trình hỗ trợ tích hợp, Git sẽ hỏi bạn nếu tích hợp thành công. Nếu bạn trả lời đúng, nó sẽ đánh dấu tập tin đó là đã giải quyết cho bạn.
 
-You can run `git status` again to verify that all conflicts have been resolved:
+Bạn có thể chạy `git status` lại một lần nữa để xác thực rằng tất cả các xung đột đã được giải quyết:
 
 	$ git status
 	# On branch master
@@ -282,7 +281,7 @@ You can run `git status` again to verify that all conflicts have been resolved:
 	#	modified:   index.html
 	#
 
-If you’re happy with that, and you verify that everything that had conflicts has been staged, you can type `git commit` to finalize the merge commit. The commit message by default looks something like this:
+Nếu bạn hài lòng với điều này, và chắc chắn rằng tất cả các xung đột đã được tổ chức, bạn có thể chạy lệnh `git commit` để hoàn thành commit tích hợp. Thông điệp mặc định của commit có dạng như sau:
 
 	Merge branch 'iss53'
 
@@ -295,66 +294,68 @@ If you’re happy with that, and you verify that everything that had conflicts h
 	# and try again.
 	#
 
-You can modify that message with details about how you resolved the merge if you think it would be helpful to others looking at this merge in the future — why you did what you did, if it’s not obvious.
+Bạn có sửa lại nội dung này với các chi tiết về việc bạn đã giải quyết như thế nào nếu bạn cho rằng các thông tin đó sẽ có ích cho các thành viên khác sau này - tại sao bạn lại làm như vậy, nếu như chúng còn chưa rõ ràng.
 
-## Branch Management ##
+## Quản Lý Các Nhánh ##
 
-Now that you’ve created, merged, and deleted some branches, let’s look at some branch-management tools that will come in handy when you begin using branches all the time.
+Bạn đã tạo mới, tích hợp, và xóa một số nhánh, bây giờ hãy cùng xem một số công cụ giúp việc quản lý nhánh trở nên dễ dàng hơn khi tần suất sử dụng nhánh của bạn ngày càng nhiều.
 
-The `git branch` command does more than just create and delete branches. If you run it with no arguments, you get a simple listing of your current branches:
+Lệnh `git branch` thực hiện nhiều việc hơn là chỉ tạo và xóa nhánh. Nếu bạn chạy nó không có tham số, bạn sẽ có danh sách của tất cả các nhánh hiện tại:
 
 	$ git branch
 	  iss53
 	* master
 	  testing
 
-Notice the `*` character that prefixes the `master` branch: it indicates the branch that you currently have checked out. This means that if you commit at this point, the `master` branch will be moved forward with your new work. To see the last commit on each branch, you can run `git branch -v`:
+Lưu ý về  ký tự `*` đứng trước nhánh `master`: nó chỉ cho bạn thấy nhánh mà bạn đang làm việc (Checkout). Có nghĩa là nếu bạn commit ở thời điểm hiện tại, thì nhánh `master` sẽ di chuyển tiến lên phía trước với các thay đổi mới. Để xem commit mới nhất trên từng nhánh, bạn có thể chạy lệnh `git branch -v`:
 
 	$ git branch -v
 	  iss53   93b412c fix javascript issue
 	* master  7a98805 Merge branch 'iss53'
 	  testing 782fd34 add scott to the author list in the readmes
 
-Another useful option to figure out what state your branches are in is to filter this list to branches that you have or have not yet merged into the branch you’re currently on. There are useful `--merged` and `--no-merged` options available in Git for this purpose. To see which branches are already merged into the branch you’re on, you can run `git branch --merged`:
+Một lựa chọn hữu ích khác để tìm ra trạng thái của các nhánh là lọc qua các nhánh bạn đã hoặc chưa tích hợp vào nhánh hiện tại. Các lựa chọn để sử dụng cho mục đích này gồm `--merged` và `--no-merged`. Để biết nhánh nào đã được tích hợp vào nhánh hiện tại, bạn có thể sử dụng `git branch --merged`:
 
 	$ git branch --merged
 	  iss53
 	* master
 
-Because you already merged in `iss53` earlier, you see it in your list. Branches on this list without the `*` in front of them are generally fine to delete with `git branch -d`; you’ve already incorporated their work into another branch, so you’re not going to lose anything.
+Bởi vì bạn đã tích hợp nhánh `iss53` vào trước đó, bạn sẽ thấy nó ở trong danh sách này. Cách nhánh trong danh sách không có dấu `*` ở phía trước thường an toàn để xóa bằng cách sử dụng `git branch -d`; bạn đã tích hợp các thay đổi trong đó vào một nhánh khác, vì thế bạn sẽ không hề bị mất bất cứ dữ liệu gì.
 
-To see all the branches that contain work you haven’t yet merged in, you can run `git branch --no-merged`:
+Để xem cách nhánh chứa các công việc/thay đổi chưa được tích hợp vào, bạn có thể chạy lệnh `git branch --no-merged`:
 
 	$ git branch --no-merged
 	  testing
 
-This shows your other branch. Because it contains work that isn’t merged in yet, trying to delete it with `git branch -d` will fail:
+Lệnh này lại hiện thị các nhánh khác. Bởi vì chúng bao gồm các công việc mà bạn chưa tích hợp vào, xóa nó đi bằng lệnh `git branch -d` sẽ báo lỗi:
 
 	$ git branch -d testing
 	error: The branch 'testing' is not an ancestor of your current HEAD.
 	If you are sure you want to delete it, run 'git branch -D testing'.
 
-If you really do want to delete the branch and lose that work, you can force it with `-D`, as the helpful message points out.
+Nếu bạn thực sự muốn xóa nó đi và chấp nhận mất các thay đổi, bạn có thể bắt buộc bằng cách sử dụng tham số `-D`, như hướng dẫn trong thông báo trên.
 
-## Branching Workflows ##
+## Quy Trình Làm Việc Phân Nhánh ##
 
-Now that you have the basics of branching and merging down, what can or should you do with them? In this section, we’ll cover some common workflows that this lightweight branching makes possible, so you can decide if you would like to incorporate it into your own development cycle.
+Bây giờ bạn đã có được các kiến thức cơ bản về phân nhánh và tích hợp, vậy bạn có thể hay nên làm gì với chúng. Trong phần này, chúng ta sẽ đề cập tới một số quy trình làm việc phổ biến áp dụng phân nhánh, vì thế bạn có thể tự quyết định có áp dụng chúng vào quy trình làm việc riêng của bạn hay không.
 
-### Long-Running Branches ###
+### Nhánh Lâu Đời ###
 
-Because Git uses a simple three-way merge, merging from one branch into another multiple times over a long period is generally easy to do. This means you can have several branches that are always open and that you use for different stages of your development cycle; you can merge regularly from some of them into others.
+Bởi vì Git sử dụng tích hợp 3 chiều đơn giản, nên tích hợp từ nhánh này vào nhánh khác nhiều lần trong cùng một giai đoạn thường dễ dàng. Có nghĩa là bạn có thể có nhiều nhánh luôn mở và sử dụng chúng cho các giai đoạn phát triển khác nhau; bạn có thể tích hợp từ một số nhánh nào đó vào các nhánh khác một cách thường xuyên.
 
-Many Git developers have a workflow that embraces this approach, such as having only code that is entirely stable in their `master` branch — possibly only code that has been or will be released. They have another parallel branch named develop or next that they work from or use to test stability — it isn’t necessarily always stable, but whenever it gets to a stable state, it can be merged into `master`. It’s used to pull in topic branches (short-lived branches, like your earlier `iss53` branch) when they’re ready, to make sure they pass all the tests and don’t introduce bugs.
+Nhiều lập trình viên Git sử dụng quy trình làm việc dựa theo phương pháp này, chẳng hạn như chỉ chứa mã nguồn ổn định hoàn toàn ở nhánh `master` - hầu như là mã nguồn đã phát hành hoặc chuẩn bị phát hành. Họ có một nhánh song song khác có tên develop hoặc next, nơi mà họ làm việc hoặc sử dụng để kiểm tra độ ổn định - nó không nhất thiết luôn luôn phải ổn định, tuy nhiên mỗi khi nó đạt được trạng thái ổn định, nó sẽ được tích hợp vào nhánh `master`. Chúng được sử dụng với vai trò là các nhánh chủ đề (topic branch) - các nhánh có vòng đời ngắn, giống như nhánh `iss53` trước đó - để đảm bảo chúng qua được các bài kiểm tra và không gây ra lỗi.
 
-In reality, we’re talking about pointers moving up the line of commits you’re making. The stable branches are farther down the line in your commit history, and the bleeding-edge branches are farther up the history (see Figure 3-18).
+Trong thực tế, chúng ta đang nói về các con trỏ di chuyển dọc theo đường thẳng của các commit. Các nhánh ổn định hơn thường ở phía cuối của đường thẳng, còn các nhánh đang phát triển thường ở phía đầu hàng (xem Hình 3-18).
 
 Insert 18333fig0318.png
-Figure 3-18. More stable branches are generally farther down the commit history.
+Hình 3-18. Nhánh ổn định hơn thường ở phía cuối hàng trong lịch sử commit.
 
-It’s generally easier to think about them as work silos, where sets of commits graduate to a more stable silo when they’re fully tested (see Figure 3-19).
+Sẽ dễ hình dung hơn khi nghĩ về chúng như là các xi-lô, nơi mà tập hợp các commit cô đặc dần thành một xi-lô ổn định hơn khi đã được kiểm tra đầy đủ (xem Hình 3-19).
 
 Insert 18333fig0319.png
-Figure 3-19. It may be helpful to think of your branches as silos.
+Hình 3-19. Có lẽ sẽ dễ hiểu hơn khi coi các nhánh là các xi-lô.
+
+Bạn có thể tiếp tục làm theo cách này cho nhiều tầng ổn định khác nhau. Nhiều dự án lớn có nhánh `proposed` hoặc `pu` (proposed updates) được sử dụng cho các nhánh chưa đủ điều kiện để tích hợp vào `next` hoặc `master`. 
 
 You can keep doing this for several levels of stability. Some larger projects also have a `proposed` or `pu` (proposed updates) branch that has integrated branches that may not be ready to go into the `next` or `master` branch. The idea is that your branches are at various levels of stability; when they reach a more stable level, they’re merged into the branch above them.
 Again, having multiple long-running branches isn’t necessary, but it’s often helpful, especially when you’re dealing with very large or complex projects.

From d730643df638f852eefe5c8ef8670d6aa0d3031a Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Fri, 3 Jan 2014 23:09:07 +0100
Subject: [PATCH 022/690] Reviewing translation

---
 it/06-git-tools/01-chapter6.markdown | 24 +++++++-----------------
 1 file changed, 7 insertions(+), 17 deletions(-)

diff --git a/it/06-git-tools/01-chapter6.markdown b/it/06-git-tools/01-chapter6.markdown
index 9efcffa29..604ba8225 100644
--- a/it/06-git-tools/01-chapter6.markdown
+++ b/it/06-git-tools/01-chapter6.markdown
@@ -94,25 +94,20 @@ Puoi consultare il reflog con il comando 'git reflog':
 	1c36188... HEAD@{5}: rebase -i (squash): updating HEAD
 	7e05da5... HEAD@{6}: rebase -i (pick): updating HEAD
 
-Ogni volta che il *branch* è aggiornato, Git registra l'informazione in questa
-lista temporanea. Si possono specificare anche *commit* più vecchi. Se si vuole
-vedere il quinto valore precedente della *HEAD* del proprio *repository*, si può
-usare il riferimento '@{n}' che si vede nel *output* di reflog:
+Ogni volta che un *branch* viene aggiornato per qualsiasi ragione, Git memorizza questa informazione in questa cronologia temporanea. E puoi anche specificare *commit* più vecchie. Se vuoi vedere la cronologia a partire dalla quinta commit più vecchia a partire dalla *HEAD* del tuo *repository*, puoi usare il riferimento '@{n}' che vedi nel *output* di reflog:
 
 	$ git show HEAD@{5}
 
-Si può anche usare questa sintassi per vedere dove era un *branch* una certa
-quantità di tempo fa. Per esempio, per vedere dov'era il 'master' *branch* ieri,
-si può scrivere:
+Puoi usare usare questa sintassi anche per vedere dove era un *branch* a una certa data. Se vuoi vedere, per esempio, dov'era il 'master' *branch* ieri, puoi scrivere:
 
 	$ git show master@{yesterday}
 
 Questo mostra dove era il *branch* ieri. Questa tecnica funziona solo per i dati
-che sono ancora nel *reflog*, non è possibile usarla per vedere *commit* più
-vecchi di qualche mese.
+che sono ancora nel *reflog* e non puoi quindi usarla per vedere *commit* più
+vecchie di qualche mese.
 
-Per vedere le informazioni del *reflog* formattate come il '*git log*', si può
-lanciare il comando 'git log -g':
+Per vedere le informazioni del *reflog* formattate come l’output di '*git log*', puoi
+eseguire il comando 'git log -g':
 
 	$ git log -g master
 	commit 734713bc047d87bf7eac9674765ae793478c50d3
@@ -131,12 +126,7 @@ lanciare il comando 'git log -g':
 
 	    Merge commit 'phedders/rdocs'
 
-E' importante notare che l'informazione del *reflog* è strettamente locale - è
-un log di cosa è stato fatto nel proprio *repository*. I riferimenti non saranno
-uguali nella copia del *repository* tenuta da qualcun altro.
-Lanciare 'git show HEAD@{2.months-ago}' funzionerà solo se il progetto è stato
-clonato almeno due mesi fa - se è stato clonato cinque minuti prima non verrà
-restituito alcun risultato.
+E' importante notare che l'informazione del *reflog* è strettamente locale: è un log di cosa hai fatto nel tuo *repository*. I riferimenti non saranno uguali sui cloni degli altri. Appena dopo aver clonato un *repository* il tuo reflog sarà vuoto perché ancora non hai svolto nessuna attività sul tuo *repository*. Eseguendo 'git show HEAD@{2.months.ago}' funzionerà solo se hai clonato il progetto almeno due mesi fa: se è stato clonato cinque minuti fa non otterrai nessun risultato.
 
 ### Riferimenti di discendenza ###
 

From 1b3cc066089c1b61dccdf85d8fba3ebc30da1ef6 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Fri, 3 Jan 2014 23:15:53 +0100
Subject: [PATCH 023/690] Reviewing translation

---
 it/06-git-tools/01-chapter6.markdown | 11 ++++-------
 1 file changed, 4 insertions(+), 7 deletions(-)

diff --git a/it/06-git-tools/01-chapter6.markdown b/it/06-git-tools/01-chapter6.markdown
index 604ba8225..15b084b9a 100644
--- a/it/06-git-tools/01-chapter6.markdown
+++ b/it/06-git-tools/01-chapter6.markdown
@@ -128,12 +128,10 @@ eseguire il comando 'git log -g':
 
 E' importante notare che l'informazione del *reflog* è strettamente locale: è un log di cosa hai fatto nel tuo *repository*. I riferimenti non saranno uguali sui cloni degli altri. Appena dopo aver clonato un *repository* il tuo reflog sarà vuoto perché ancora non hai svolto nessuna attività sul tuo *repository*. Eseguendo 'git show HEAD@{2.months.ago}' funzionerà solo se hai clonato il progetto almeno due mesi fa: se è stato clonato cinque minuti fa non otterrai nessun risultato.
 
-### Riferimenti di discendenza ###
+### Riferimenti ancestrali ###
 
-L'altro modo per specificare un *commit* è attraverso la sua discendenza. Se
-viene posizionato un `^` alla fine di un riferimento, Git lo interpreta come il
-genitore di quel determinato *commit*.
-Supponiamo che si guardi la lista delle modifiche effettuate nel progetto:
+L'altro modo principale per specificare una *commit* è attraverso i suoi ascendenti. Se metti un `^` alla fine di un riferimento, Git lo risolve interpretandolo come il padre
+padre di quella determinata *commit*. Immagina di guardare la cronologia del tuo progetto:
 
 	$ git log --pretty=format:'%h %s' --graph
 	* 734713b fixed refs handling, added gc auto, updated tests
@@ -145,8 +143,7 @@ Supponiamo che si guardi la lista delle modifiche effettuate nel progetto:
 	* 1c36188 ignore *.gem
 	* 9b29157 add open3_detach to gemspec file list
 
-E' possibile vedere il precedente *commit* specificando `HEAD^`, che significa
-"il genitore di HEAD":
+È possibile vedere la *commit* precedente specificando `HEAD^`, che significa "il genitore di HEAD":
 
 	$ git show HEAD^
 	commit d921970aadf03b3cf0e71becdaab3147ba71cdef

From 8274af5adb147632b926daae9bd497f16a133e91 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Fri, 3 Jan 2014 23:16:32 +0100
Subject: [PATCH 024/690] Reviewing translation

---
 it/06-git-tools/01-chapter6.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/it/06-git-tools/01-chapter6.markdown b/it/06-git-tools/01-chapter6.markdown
index 15b084b9a..9a0191656 100644
--- a/it/06-git-tools/01-chapter6.markdown
+++ b/it/06-git-tools/01-chapter6.markdown
@@ -143,7 +143,7 @@ padre di quella determinata *commit*. Immagina di guardare la cronologia del tuo
 	* 1c36188 ignore *.gem
 	* 9b29157 add open3_detach to gemspec file list
 
-È possibile vedere la *commit* precedente specificando `HEAD^`, che significa "il genitore di HEAD":
+Puoi quindi vedere la *commit* precedente specificando `HEAD^`, che significa "il genitore di HEAD":
 
 	$ git show HEAD^
 	commit d921970aadf03b3cf0e71becdaab3147ba71cdef

From 7f30733ba450bd4d4fca6cc2a52ccdfba96db59e Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Fri, 3 Jan 2014 23:18:24 +0100
Subject: [PATCH 025/690] Reviewing translation

---
 it/06-git-tools/01-chapter6.markdown | 8 +++-----
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/it/06-git-tools/01-chapter6.markdown b/it/06-git-tools/01-chapter6.markdown
index 9a0191656..2e597b7fb 100644
--- a/it/06-git-tools/01-chapter6.markdown
+++ b/it/06-git-tools/01-chapter6.markdown
@@ -153,11 +153,9 @@ Puoi quindi vedere la *commit* precedente specificando `HEAD^`, che significa "i
 
 	    Merge commit 'phedders/rdocs'
 
-Si può anche specificare un numero dopo `^` - per esempio, `d921970^2` significa
-"il secondo genitore di d921870." Questa sintassi è utile per fare il *merge* di
-*commit* che hanno più di un genitore.
-Il primo genitore è il *branch* dove ci si trova al momento del *merge*, e il
-secondo è il *commit* sul *branch* di cui è stato fatto il *merge*:
+Puoi anche specificare un numero dopo `^`: per esempio `d921970^2` significa
+"il secondo genitore di d921870." Questa sintassi è utile solo per fare il *merge* di
+*commit* che hanno più di un genitore. Il primo genitore è il *branch* dove ti trovi al momento del *merge*, e il secondo è la *commit* sul *branch* da cui hai fatto il *merge*:
 
 	$ git show d921970^
 	commit 1c002dd4b536e7479fe34593e72e6c6c1819e53b

From 0d69a9f6f9f6bdf739988c2e2c95947a0daee38c Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Fri, 3 Jan 2014 23:26:31 +0100
Subject: [PATCH 026/690] Reviewing translation

---
 it/06-git-tools/01-chapter6.markdown | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/it/06-git-tools/01-chapter6.markdown b/it/06-git-tools/01-chapter6.markdown
index 2e597b7fb..f232b8859 100644
--- a/it/06-git-tools/01-chapter6.markdown
+++ b/it/06-git-tools/01-chapter6.markdown
@@ -171,8 +171,7 @@ Puoi anche specificare un numero dopo `^`: per esempio `d921970^2` significa
 
 	    Some rdoc changes
 
-Un altro modo per specificare la discendenza è `~`. Anche questo si riferisce al
-primo genitore, quindi `HEAD~` e `HEAD^` sono equivalenti. La differenza si nota
+Un altro modo riferimento ancestrale è `~`. Questo si riferisce anche al primo genitore, quindi `HEAD~` e `HEAD^` sono equivalenti. La differenza si nota
 quando viene specificato un numero.
 `HEAD~2` significa "il primo genitore del primo genitore", o "il nonno" -
 attraversa i primi genitori il numero di volte specificato. Per esempio, nella

From dc4780291b2004164b45e6bd8c757b70cacb2284 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Fri, 3 Jan 2014 23:31:13 +0100
Subject: [PATCH 027/690] Finished reviewing translation

ready to translate new text
---
 it/06-git-tools/01-chapter6.markdown | 14 ++++----------
 1 file changed, 4 insertions(+), 10 deletions(-)

diff --git a/it/06-git-tools/01-chapter6.markdown b/it/06-git-tools/01-chapter6.markdown
index f232b8859..262e771cc 100644
--- a/it/06-git-tools/01-chapter6.markdown
+++ b/it/06-git-tools/01-chapter6.markdown
@@ -171,11 +171,8 @@ Puoi anche specificare un numero dopo `^`: per esempio `d921970^2` significa
 
 	    Some rdoc changes
 
-Un altro modo riferimento ancestrale è `~`. Questo si riferisce anche al primo genitore, quindi `HEAD~` e `HEAD^` sono equivalenti. La differenza si nota
-quando viene specificato un numero.
-`HEAD~2` significa "il primo genitore del primo genitore", o "il nonno" -
-attraversa i primi genitori il numero di volte specificato. Per esempio, nella
-lista mostrata precedentemente, `HEAD~3` sarebbe
+Un altro modo riferimento ancestrale è `~`. Questo si riferisce anche al genitore, quindi `HEAD~` e `HEAD^` sono equivalenti. La differenza si nota quando specifichi un numero. `HEAD~2` significa "il genitore del genitore", o "il nonno”: attraversa i primi genitori il numero di volte che specifichi. Per esempio, nella
+cronologia precedente, `HEAD~3` sarebbe
 
 	$ git show HEAD~3
 	commit 1c3618887afb5fbcbea25b7c013f4e2114448b8d
@@ -184,8 +181,7 @@ lista mostrata precedentemente, `HEAD~3` sarebbe
 
 	    ignore *.gem
 
-Potrebbe essere anche scritto come `HEAD^^^`, che è sempre il primo genitore del
-primo genitore del primo genitore:
+Che può anche essere scritto come `HEAD^^^` che, di nuovo, è sempre il genitore del genitore del genitore:
 
 	$ git show HEAD^^^
 	commit 1c3618887afb5fbcbea25b7c013f4e2114448b8d
@@ -194,6 +190,4 @@ primo genitore del primo genitore:
 
 	    ignore *.gem
 
-E' possibile anche combinare queste sintassi - si può prendere il secondo
-genitore del precedente riferimento (assumendo che si tratti di un *merge
-commit*) usando `HEAD~3^2`, e così via.            
+È anche possibile combinare queste sintassi: puoi prendere il nonno del riferimento precedente (assumendo che si tratti di una commit di *merge*) usando `HEAD~3^2`, e così via.            

From 9527bcd791661066eeaa121241c4c2712e959859 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Fri, 3 Jan 2014 23:36:57 +0100
Subject: [PATCH 028/690] Translated "Commit Ranges"

---
 it/06-git-tools/01-chapter6.markdown | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/it/06-git-tools/01-chapter6.markdown b/it/06-git-tools/01-chapter6.markdown
index 262e771cc..0f77a3e99 100644
--- a/it/06-git-tools/01-chapter6.markdown
+++ b/it/06-git-tools/01-chapter6.markdown
@@ -190,4 +190,10 @@ Che può anche essere scritto come `HEAD^^^` che, di nuovo, è sempre il genitor
 
 	    ignore *.gem
 
-È anche possibile combinare queste sintassi: puoi prendere il nonno del riferimento precedente (assumendo che si tratti di una commit di *merge*) usando `HEAD~3^2`, e così via.            
+È anche possibile combinare queste sintassi: puoi prendere il nonno del riferimento precedente (assumendo che si tratti di una commit di *merge*) usando `HEAD~3^2`, e così via.
+
+### Intervalli di Commit ###
+
+Ora che sai come specificare delle commit singole, vediamo come specificare intervalli di commit. Ciò è particolarmente utile per gestire i tuoi branch: se hai molti branch puoi usare gli intervalli per rispondere a domande come “cosa c’è nel tuo branch di cui io non ho ancora fatto il merge?”
+
+

From 569f47f9390d0c91d38380f2e1c464578034e3b3 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Fri, 3 Jan 2014 23:39:52 +0100
Subject: [PATCH 029/690] Started "Double Dot"

---
 it/06-git-tools/01-chapter6.markdown | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/it/06-git-tools/01-chapter6.markdown b/it/06-git-tools/01-chapter6.markdown
index 0f77a3e99..0af6f17db 100644
--- a/it/06-git-tools/01-chapter6.markdown
+++ b/it/06-git-tools/01-chapter6.markdown
@@ -196,4 +196,9 @@ Che può anche essere scritto come `HEAD^^^` che, di nuovo, è sempre il genitor
 
 Ora che sai come specificare delle commit singole, vediamo come specificare intervalli di commit. Ciò è particolarmente utile per gestire i tuoi branch: se hai molti branch puoi usare gli intervalli per rispondere a domande come “cosa c’è nel tuo branch di cui io non ho ancora fatto il merge?”
 
+#### Doppio punto ####
 
+Il modo più comune per specificare un intervallo è con il doppio punto che, praticamente, chiede a Git di risolvere l’intervallo tra commit che sia raggiungibile da una commit, ma che non sia raggiungibile dall’altra. Per esempio, immaginiamo di avere una cronologia come nell’immagine 6-1
+
+Insert 18333fig0601.png
+Figure 6-1. Esempio di cronologia per selezione di intervalli.

From 24b9b821a0aefab5c4418327b6cfcd7349650ff3 Mon Sep 17 00:00:00 2001
From: Tuan Vu <contact@tuanva.co.uk>
Date: Sat, 4 Jan 2014 02:52:56 +0000
Subject: [PATCH 030/690] update chapter 3

---
 vi/03-git-branching/01-chapter3.markdown | 34 ++++++++++++------------
 1 file changed, 17 insertions(+), 17 deletions(-)

diff --git a/vi/03-git-branching/01-chapter3.markdown b/vi/03-git-branching/01-chapter3.markdown
index 6feadfe84..d8f26deb5 100644
--- a/vi/03-git-branching/01-chapter3.markdown
+++ b/vi/03-git-branching/01-chapter3.markdown
@@ -355,39 +355,39 @@ Sẽ dễ hình dung hơn khi nghĩ về chúng như là các xi-lô, nơi mà t
 Insert 18333fig0319.png
 Hình 3-19. Có lẽ sẽ dễ hiểu hơn khi coi các nhánh là các xi-lô.
 
-Bạn có thể tiếp tục làm theo cách này cho nhiều tầng ổn định khác nhau. Nhiều dự án lớn có nhánh `proposed` hoặc `pu` (proposed updates) được sử dụng cho các nhánh chưa đủ điều kiện để tích hợp vào `next` hoặc `master`. 
+Bạn có thể tiếp tục làm theo cách này cho nhiều tầng ổn định khác nhau. Nhiều dự án lớn có nhánh `proposed` hoặc `pu` (proposed updates) được sử dụng cho các nhánh chưa đủ điều kiện để tích hợp vào `next` hoặc `master`. Ý tưởng ở đây là, các nhánh ở các tầng khác nhau của sự ổn định; khi chúng đạt tới một mức ổn định hơn nào đó, chúng sẽ được tích hợp vào tầng trên nó. 
+Tóm lại, có nhiều nhánh tồn lại lâu dài không thật sự cần thiết, nhưng nó thường rất hữu ích, đặc biệt là khi bạn làm việc với các dự án lớn và phức tạp.
 
-You can keep doing this for several levels of stability. Some larger projects also have a `proposed` or `pu` (proposed updates) branch that has integrated branches that may not be ready to go into the `next` or `master` branch. The idea is that your branches are at various levels of stability; when they reach a more stable level, they’re merged into the branch above them.
-Again, having multiple long-running branches isn’t necessary, but it’s often helpful, especially when you’re dealing with very large or complex projects.
+### Nhánh Chủ Đề ###
 
-### Topic Branches ###
+Nhánh chủ đề (topic branches) thì ngược lại, nó lại khá hữu ích cho các dự án ở bất kỳ cỡ nào. Một nhánh chủ đề là nhánh có vòng đời ngắn mà bạn tạo để phát triển một tính năng nào đó hoặc tương tự. Nó giống như một thứ gì đó mà bạn chưa từng làm với một VCS trước đây bởi vì nhìn chung nó đòi hỏi rất nhiều nỗ lực để tạo mới cũng như tích hợp các nhánh lại với nhau.
 
-Topic branches, however, are useful in projects of any size. A topic branch is a short-lived branch that you create and use for a single particular feature or related work. This is something you’ve likely never done with a VCS before because it’s generally too expensive to create and merge branches. But in Git it’s common to create, work on, merge, and delete branches several times a day.
+Như bạn đã thấy trong phần trước với các nhánh `iss53` và `hotfix` bạn đã tạo ra. Bạn thực hiện một số commit trên đó và xóa chúng đi ngay sau khi tính hợp chúng lại với nhánh chính. Kỹ thuật này cho phép bạn chuyển ngữ cảnh một cách nhanh chóng và toàn diện - vì công việc của bạn tách biệt hoàn toàn ở các xi-lô nơi mà tất cả các thay đổi ở nhánh đó chỉ liên quan đến chủ đề đó, điều này khiến cho việc xem xét lại (review) mã nguồn hoặc tương tự trở nên dễ dàng hơn rất nhiều. Bạn có thể giữ các thay đổi ở đó trong bất kỳ khoảng thời gian nào bạn muốn, có thể tính bằng phút, ngày, hoặc tháng, và sau đó tích hợp lại khi chúng đã sẵn sàng, không quan trọng thứ tự chúng được tạo ra hay làm việc.
 
-You saw this in the last section with the `iss53` and `hotfix` branches you created. You did a few commits on them and deleted them directly after merging them into your main branch. This technique allows you to context-switch quickly and completely — because your work is separated into silos where all the changes in that branch have to do with that topic, it’s easier to see what has happened during code review and such. You can keep the changes there for minutes, days, or months, and merge them in when they’re ready, regardless of the order in which they were created or worked on.
-
-Consider an example of doing some work (on `master`), branching off for an issue (`iss91`), working on it for a bit, branching off the second branch to try another way of handling the same thing (`iss91v2`), going back to your master branch and working there for a while, and then branching off there to do some work that you’re not sure is a good idea (`dumbidea` branch). Your commit history will look something like Figure 3-20.
+Hãy cùng xét một ví dụ về thực hiện một số công việc (trên nhánh `master`), tạo nhánh cho một vấn đề cần giải quyết (`iss91`), làm việc trên đó một chút, tạo một nhánh thứ hai cùng giải quyết vấn đề đó nhưng theo một cách khác (`iss91v2`), quay trở lại nhánh `master` và làm việc trong một khoảng thời gian nhất định, sau đó tạo một nhánh khác từ đó cho một ý tưởng mà bạn không chắc chắn là nó có phải là ý hay hay không (nhánh `dumbidea`). Lúc này lịch sử commit của bạn sẽ giống Hình 3-20.
 
 Insert 18333fig0320.png
-Figure 3-20. Your commit history with multiple topic branches.
+Hình 3-20. Lịch sử commit với nhiều nhánh chủ đề.
 
-Now, let’s say you decide you like the second solution to your issue best (`iss91v2`); and you showed the `dumbidea` branch to your coworkers, and it turns out to be genius. You can throw away the original `iss91` branch (losing commits C5 and C6) and merge in the other two. Your history then looks like Figure 3-21.
+Bây giờ, giả sử bạn quyết định lựa chọn cách giải quyết thứ hai (`iss91v2`); và bạn trình bày ý tưởng `dumbidea` cho các đồng nghiệp, điều mà bạn không ngờ tới rằng mọi người lại cho đó là một ý tưởng tuyệt vời. Bạn đã có thể bỏ đi nhánh ban đầu `iss91` (mất commit C5 và C6) và tích hợp hai commit còn lại. Lịch sử của bạn lúc này sẽ giống Hình 3-21.
 
 Insert 18333fig0321.png
-Figure 3-21. Your history after merging in dumbidea and iss91v2.
+Hình 3-21. Lịch sử commit sau khi tích hợp dumbidea và iss91v2.
 
-It’s important to remember when you’re doing all this that these branches are completely local. When you’re branching and merging, everything is being done only in your Git repository — no server communication is happening.
+Ghi nhớ một điều quan trọng là khi bạn làm tất cả những việc này, các nhánh hoàn toàn nằm ở máy nội bộ. Khi bạn phân nhánh và tích hợp, tất cả mọi thứ xảy ra trên kho chứa Git của bạn - không có giao tiếp tới máy chủ nào xảy ra.
 
-## Remote Branches ##
+## Nhánh Từ Xa ##
 
-Remote branches are references to the state of branches on your remote repositories. They’re local branches that you can’t move; they’re moved automatically whenever you do any network communication. Remote branches act as bookmarks to remind you where the branches on your remote repositories were the last time you connected to them.
+Nhánh từ xa là các tham chiếu tới trạng thái của các nhánh trên kho chứa từ xa/trung tâm của bạn. Chúng là các nhánh nội bộ mà bạn không thể di chuyển; chúng chỉ di chuyển một cách tự động mỗi khi bạn thực hiện bất kỳ giao tiếp nào qua mạng lưới. Nhánh từ xa hoạt động như là các bookmark (dấu) để nhắc nhở bạn các nhánh trên kho chứa trung tâm của bạn ở đâu vào lần cuối cùng bạn kết nối tới.
 
-They take the form `(remote)/(branch)`. For instance, if you wanted to see what the `master` branch on your `origin` remote looked like as of the last time you communicated with it, you would check the `origin/master` branch. If you were working on an issue with a partner and they pushed up an `iss53` branch, you might have your own local `iss53` branch; but the branch on the server would point to the commit at `origin/iss53`.
+Chúng có dạng `(remote)/(branch)`. Ví dụ, nếu bạn muốn xem nhánh `master` trên nhánh từ xa `origin` của bạn như thế nào từ lần giao tiếp cuối cùng, bạn sẽ dùng `origin/master`. Nếu bạn đang giải quyết một vấn đề với đối tác và họ đẩy dữ liệu lên nhánh `iss53`, bạn có thể có riêng nhánh `iss53` trên máy nội bộ; nhưng nhánh trên máy chủ sẽ trỏ tới commit tại `origin/iss53`.
 
-This may be a bit confusing, so let’s look at an example. Let’s say you have a Git server on your network at `git.ourcompany.com`. If you clone from this, Git automatically names it `origin` for you, pulls down all its data, creates a pointer to where its `master` branch is, and names it `origin/master` locally; and you can’t move it. Git also gives you your own `master` branch starting at the same place as origin’s `master` branch, so you have something to work from (see Figure 3-22).
+Điều này có thể hơi khó hiểu một chút, vậy hãy cùng xem một ví dụ. Giả sử bạn có một máy chủ Git trên mạng của bạn tại địa chỉ `git.ourcompany.com`. Nếu bạn tạo bản sao từ đây, Git sẽ tự động đặt tên nó là `origin` cho bạn, tải về toàn bộ dữ liệu, tạo một con trỏ tới nhánh `master` và đặt tên nội bộ cho nó là `origin/master`; và bạn không thể di chuyển nó. Git cũng cung cấp cho bạn nhánh `master` riêng, bắt đầu cùng một vị trí với `master` của origin để cho bạn có thể bắt đầu làm việc (xem Hình 3-22).
 
 Insert 18333fig0322.png
-Figure 3-22. A Git clone gives you your own master branch and origin/master pointing to origin’s master branch.
+Hình 3-22. Một bản sao Git cung cấp cho bạn nhánh master riêng và nhánh origin/master trỏ tới nhánh master của origin.
+
+
 
 If you do some work on your local master branch, and, in the meantime, someone else pushes to `git.ourcompany.com` and updates its master branch, then your histories move forward differently. Also, as long as you stay out of contact with your origin server, your `origin/master` pointer doesn’t move (see Figure 3-23).
 

From 2e306d4754051ab1aa9c0cd466646ab24b41934a Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Sat, 4 Jan 2014 11:03:53 +0100
Subject: [PATCH 031/690] Translated "Double Dot"

---
 it/06-git-tools/01-chapter6.markdown | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/it/06-git-tools/01-chapter6.markdown b/it/06-git-tools/01-chapter6.markdown
index 0af6f17db..1a2a13c6a 100644
--- a/it/06-git-tools/01-chapter6.markdown
+++ b/it/06-git-tools/01-chapter6.markdown
@@ -202,3 +202,23 @@ Il modo più comune per specificare un intervallo è con il doppio punto che, pr
 
 Insert 18333fig0601.png
 Figure 6-1. Esempio di cronologia per selezione di intervalli.
+
+Vuoi vedere cosa sia nel tuo branch sperimentale che non sia ancora stato incluso nel branch master: puoi chiedere a Git di mostrarti il log esclusivamente di quelle commit con `master..experiment`: questo significa “tutte le commit raggiungibili da experiment che non siano raggiungibili da master”. Affinché questi esempi siano sintetici ma chiari, invece del log effettivamente scritto da Git, userò le lettere degli oggetti commit del diagramma:
+
+	$ git log master..experiment
+	D
+	C
+
+Se, invece vuoi vedere il contrario, ovvero tutte le commit in `master` che non siano in `experiment`, puoi invertire i nomi dei branch: `experiment..master` ti mostra tutto ciò che è in `master` e che non sia raggiungibile da `experiment`:
+
+	$ git log experiment..master
+	F
+	E
+
+Questo è utile se vuoi mantenere il branch `experiment` aggiornato e sapere di cosa stai per fare il merge. Un’altro caso in cui si usa spesso questa sintassi è quando stai per fare una push verso un repository remoto:
+
+	$ git log origin/master..HEAD
+
+Questo comando mostra tutte le commit nel tuo branch che non sono nel branch `master` del tuo repository remoto `origin`. Se esegui `git push` quando il tuo branch è associato a `origin/master`, le commit elencate da `git log origin/master..HEAD` saranno le commit che saranno inviate al server.
+Puoi anche omettere una delle parti della sintassi, e Git assumerà che sia HEAD. Puoi per esempio ottenere lo stesso risultato dell’esempio precedente scrivendo `git log origin/master..`: Git sostituisce la parte mancante con HEAD.
+

From ee7f909251e3319febfa4337a61438e4a802e58f Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Sat, 4 Jan 2014 11:21:49 +0100
Subject: [PATCH 032/690] Translated "Multiple Points"

---
 it/06-git-tools/01-chapter6.markdown | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/it/06-git-tools/01-chapter6.markdown b/it/06-git-tools/01-chapter6.markdown
index 1a2a13c6a..4f0c06524 100644
--- a/it/06-git-tools/01-chapter6.markdown
+++ b/it/06-git-tools/01-chapter6.markdown
@@ -222,3 +222,17 @@ Questo è utile se vuoi mantenere il branch `experiment` aggiornato e sapere di
 Questo comando mostra tutte le commit nel tuo branch che non sono nel branch `master` del tuo repository remoto `origin`. Se esegui `git push` quando il tuo branch è associato a `origin/master`, le commit elencate da `git log origin/master..HEAD` saranno le commit che saranno inviate al server.
 Puoi anche omettere una delle parti della sintassi, e Git assumerà che sia HEAD. Puoi per esempio ottenere lo stesso risultato dell’esempio precedente scrivendo `git log origin/master..`: Git sostituisce la parte mancante con HEAD.
 
+#### Punti multipli ####
+
+La sintassi del doppio punto è utile come la stenografia, ma potresti voler specificare più di due branch, così come vedere le commit che sono nei vari branch e che non sono nel tuo branch attuale. Git ti permette di farlo sia con il carattere `^` che con l’opzione `--not` prima di ciascun riferimento del quale vuoi vedere le commit non raggiungibili. Quindi questi tre comandi sono equivalenti:
+
+	$ git log refA..refB
+	$ git log ^refA refB
+	$ git log refB --not refA
+
+Questo è interessante, perché con questa sintassi puoi specificare più di due riferimenti nella tua query, cosa che non puoi fare con il doppio punto. Se per esempio vuoi vedere tutte le commit che siano raggiungibili da `refA` o da `refB` ma non da `refC` puoi usare una delle seguenti alternative:
+
+	$ git log refA refB ^refC
+	$ git log refA refB --not refC
+
+Questo la rende un sistema potente di query di revisione che dovrebbe aiutarti a capire cosa c’è nei tuo branch.
\ No newline at end of file

From 22c2e5711316bfc680e4b393bbd4847314a7c677 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Sat, 4 Jan 2014 11:23:58 +0100
Subject: [PATCH 033/690] Renamed "Doppio Punto"

Per coerenza con il paragrafo seguente "Tre punti"
---
 it/06-git-tools/01-chapter6.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/it/06-git-tools/01-chapter6.markdown b/it/06-git-tools/01-chapter6.markdown
index 4f0c06524..0bbdc6821 100644
--- a/it/06-git-tools/01-chapter6.markdown
+++ b/it/06-git-tools/01-chapter6.markdown
@@ -196,7 +196,7 @@ Che può anche essere scritto come `HEAD^^^` che, di nuovo, è sempre il genitor
 
 Ora che sai come specificare delle commit singole, vediamo come specificare intervalli di commit. Ciò è particolarmente utile per gestire i tuoi branch: se hai molti branch puoi usare gli intervalli per rispondere a domande come “cosa c’è nel tuo branch di cui io non ho ancora fatto il merge?”
 
-#### Doppio punto ####
+#### Due punti ####
 
 Il modo più comune per specificare un intervallo è con il doppio punto che, praticamente, chiede a Git di risolvere l’intervallo tra commit che sia raggiungibile da una commit, ma che non sia raggiungibile dall’altra. Per esempio, immaginiamo di avere una cronologia come nell’immagine 6-1
 

From 0f8eeff5595e0180261da91ad52825f249ae5ecb Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Sat, 4 Jan 2014 19:47:33 +0100
Subject: [PATCH 034/690] Translated "Triple Dot"

---
 it/06-git-tools/01-chapter6.markdown | 31 ++++++++++++++++++++++++----
 1 file changed, 27 insertions(+), 4 deletions(-)

diff --git a/it/06-git-tools/01-chapter6.markdown b/it/06-git-tools/01-chapter6.markdown
index 0bbdc6821..f83a8e306 100644
--- a/it/06-git-tools/01-chapter6.markdown
+++ b/it/06-git-tools/01-chapter6.markdown
@@ -198,7 +198,7 @@ Ora che sai come specificare delle commit singole, vediamo come specificare inte
 
 #### Due punti ####
 
-Il modo più comune per specificare un intervallo è con il doppio punto che, praticamente, chiede a Git di risolvere l’intervallo tra commit che sia raggiungibile da una commit, ma che non sia raggiungibile dall’altra. Per esempio, immaginiamo di avere una cronologia come nell’immagine 6-1
+Il modo più comune per specificare un intervallo è con i due punti che, praticamente, chiedono a Git di risolvere l’intervallo tra commit che sia raggiungibile da una commit, ma che non sia raggiungibile dall’altra. Per esempio, immaginiamo di avere una cronologia come nell’immagine 6-1
 
 Insert 18333fig0601.png
 Figure 6-1. Esempio di cronologia per selezione di intervalli.
@@ -224,15 +224,38 @@ Puoi anche omettere una delle parti della sintassi, e Git assumerà che sia HEAD
 
 #### Punti multipli ####
 
-La sintassi del doppio punto è utile come la stenografia, ma potresti voler specificare più di due branch, così come vedere le commit che sono nei vari branch e che non sono nel tuo branch attuale. Git ti permette di farlo sia con il carattere `^` che con l’opzione `--not` prima di ciascun riferimento del quale vuoi vedere le commit non raggiungibili. Quindi questi tre comandi sono equivalenti:
+La sintassi dei due punti è utile come la stenografia, ma potresti voler specificare più di due branch, così come vedere le commit che sono nei vari branch e che non sono nel tuo branch attuale. Git ti permette di farlo sia con il carattere `^` che con l’opzione `--not` prima di ciascun riferimento del quale vuoi vedere le commit non raggiungibili. Quindi questi tre comandi sono equivalenti:
 
 	$ git log refA..refB
 	$ git log ^refA refB
 	$ git log refB --not refA
 
-Questo è interessante, perché con questa sintassi puoi specificare più di due riferimenti nella tua query, cosa che non puoi fare con il doppio punto. Se per esempio vuoi vedere tutte le commit che siano raggiungibili da `refA` o da `refB` ma non da `refC` puoi usare una delle seguenti alternative:
+Questo è interessante, perché con questa sintassi puoi specificare più di due riferimenti nella tua query, cosa che non puoi fare con i due punti. Se per esempio vuoi vedere tutte le commit che siano raggiungibili da `refA` o da `refB` ma non da `refC` puoi usare una delle seguenti alternative:
 
 	$ git log refA refB ^refC
 	$ git log refA refB --not refC
 
-Questo la rende un sistema potente di query di revisione che dovrebbe aiutarti a capire cosa c’è nei tuo branch.
\ No newline at end of file
+Questo la rende un sistema potente di query di revisione che dovrebbe aiutarti a capire cosa c’è nei tuo branch.
+
+#### Tre punti ####
+
+L’ultima sintassi per la selezione di intervalli è quella dei tre punti che indica tutte le commit raggiungibili da ciascuno dei riferimenti ma non da entrambi. Rivedi la cronologia delle commit nella Figura 6-1.
+Se vuoi vedere cosa sia in `master` o in `experiment` ma non i riferimenti comuni puoi eseguire questo comando
+
+	$ git log master...experiment
+	F
+	E
+	D
+	C
+
+Che ti mostra l’output normale del *log*, ma solo con le informazioni di quelle quattro commit nel solito ordinamento cronologico.
+
+In questo è comune usare il parametro `--left-right` con il comando `log`, che mostra da che parte è la commit nell’intervallo selezionato, che rende i dati molto più utili:
+
+	$ git log --left-right master...experiment
+	< F
+	< E
+	> D
+	> C
+
+Con questi strumenti puoi dire facilmente a Git quale o quali commit vuoi ispezionare.
\ No newline at end of file

From 5d2d9128ba3c7405817e659051a6c2ec5cc187d3 Mon Sep 17 00:00:00 2001
From: Tuan Vu <contact@tuanva.co.uk>
Date: Sun, 5 Jan 2014 04:11:24 +0000
Subject: [PATCH 035/690] [vi] Finished chapter 3

---
 vi/03-git-branching/01-chapter3.markdown | 143 +++++++++++------------
 1 file changed, 71 insertions(+), 72 deletions(-)

diff --git a/vi/03-git-branching/01-chapter3.markdown b/vi/03-git-branching/01-chapter3.markdown
index d8f26deb5..56fb8f8d0 100644
--- a/vi/03-git-branching/01-chapter3.markdown
+++ b/vi/03-git-branching/01-chapter3.markdown
@@ -387,33 +387,31 @@ Chúng có dạng `(remote)/(branch)`. Ví dụ, nếu bạn muốn xem nhánh `
 Insert 18333fig0322.png
 Hình 3-22. Một bản sao Git cung cấp cho bạn nhánh master riêng và nhánh origin/master trỏ tới nhánh master của origin.
 
-
-
-If you do some work on your local master branch, and, in the meantime, someone else pushes to `git.ourcompany.com` and updates its master branch, then your histories move forward differently. Also, as long as you stay out of contact with your origin server, your `origin/master` pointer doesn’t move (see Figure 3-23).
+Nếu bạn thực hiện một số thay đổi trên nhánh `master` nội bộ, và cùng thời điểm đó, một người nào đó đẩy lên `git.ourcompany.com` và cập nhật nhánh master của nó, thì lịch sử của bạn sẽ di chuyển về phía trước khác đi. Miễn là bạn không kết nối tới máy chủ thì con trỏ `origin/master` sẽ vẫn không đổi (xem Hình 3-23).
 
 Insert 18333fig0323.png
-Figure 3-23. Working locally and having someone push to your remote server makes each history move forward differently.
+Hình 3-23. Làm việc nội bộ và ai đó đẩy lên máy chủ khiến cho lịch sử thay đổi khác biệt nhau.
 
-To synchronize your work, you run a `git fetch origin` command. This command looks up which server origin is (in this case, it’s `git.ourcompany.com`), fetches any data from it that you don’t yet have, and updates your local database, moving your `origin/master` pointer to its new, more up-to-date position (see Figure 3-24).
+Để đồng bộ hóa các thay đổi, bạn chạy lệnh `git fetch origin`. Lệnh này sẽ tìm kiếm máy chủ nào là origin (trong trường hợp này là `git.ourcompany.com`), truy xuất toàn bộ dữ liệu mà bạn chưa có từ đó, và cập nhật cơ sở dữ liệu nội bộ của bạn, di chuyển con trỏ `origin/master` tới vị trí mới được cập nhật (xem Hình 3-24).
 
 Insert 18333fig0324.png
-Figure 3-24. The git fetch command updates your remote references.
+Hình 3-24. Lệnh git fetch cập nhật các tham chiếu từ xa.
 
-To demonstrate having multiple remote servers and what remote branches for those remote projects look like, let’s assume you have another internal Git server that is used only for development by one of your sprint teams. This server is at `git.team1.ourcompany.com`. You can add it as a new remote reference to the project you’re currently working on by running the `git remote add` command as we covered in Chapter 2. Name this remote `teamone`, which will be your shortname for that whole URL (see Figure 3-25).
+Để minh họa cho việc có nhiều máy chủ từ xa và các nhánh từ xa của các dự án thuộc các máy chủ đó, giả sử bạn có một máy chủ Git nội bộ khác sử dụng riêng cho các nhóm "thần tốc". Máy chủ này có địa chỉ là `git.team1.ourcompany.com`. Bạn có thể thêm nó như là một tham chiếu từ xa tới dự án bạn đang làm việc bằng cách chạy lệnh `git remote add` như đã giới thiệu ở Chương 2. Đặt tên cho remote đó là `teamone`, đó sẽ là tên rút gọn thay thế cho địa chỉ đầy đủ kia (xem Hình 3-25).
 
 Insert 18333fig0325.png
-Figure 3-25. Adding another server as a remote.
+Hình 3-25. Thêm một máy chủ từ xa khác.
 
-Now, you can run `git fetch teamone` to fetch everything the remote `teamone` server has that you don’t have yet. Because that server has a subset of the data your `origin` server has right now, Git fetches no data but sets a remote branch called `teamone/master` to point to the commit that `teamone` has as its `master` branch (see Figure 3-26).
+Bây giờ bạn có thể chạy lệnh `git fetch teamone` để truy xất toàn bộ nội dung mà bạn chưa có từ máy chủ `teamone`. Bởi vì máy chủ đó có chứa một tập con dữ liệu từ máy chủ `origin` đang có, Git không truy xuất dữ liệu nào cả mà thiết lập một nhánh từ xa mới là `teamone/master` để trỏ tới commit mà `teamone` đang có như là nhánh `master` (xem Hình 3-26).
 
 Insert 18333fig0326.png
-Figure 3-26. You get a reference to teamone’s master branch position locally.
+Hình 3-26. Bạn sẽ có một tham chiếu tới vị trí nội bộ của nhánh `master` của teamone.
 
-### Pushing ###
+### Đẩy Lên ###
 
-When you want to share a branch with the world, you need to push it up to a remote that you have write access to. Your local branches aren’t automatically synchronized to the remotes you write to — you have to explicitly push the branches you want to share. That way, you can use private branches for work you don’t want to share, and push up only the topic branches you want to collaborate on.
+Khi bạn muốn chia sẻ một nhánh với mọi người, bạn cẩn phải đẩy nó lên một máy chủ mà bạn có quyền ghi trên đó. Nhánh nội bộ của bạn sẽ không tự động thực hiện quá trình đồng bộ hóa - mà bạn phải tự đẩy lên cách nhánh mà bạn muốn chia sẻ. Theo cách này, bạn có thể có các nhánh riêng tư cho những công việc mà bạn không muốn chia sẻ, và chỉ đẩy lên các nhánh chủ đề mà bạn muốn mọi người cùng tham gia đóng góp.
 
-If you have a branch named `serverfix` that you want to work on with others, you can push it up the same way you pushed your first branch. Run `git push (remote) (branch)`:
+Nếu bạn có một nhánh là `serverfix` mà bạn muốn mọi người cùng cộng tác, bạn có thể đẩy nó lên theo cách mà chúng ta đã làm đối với nhánh đầu tiên. Chạy `git push (remote) (branch)`:
 
 	$ git push origin serverfix
 	Counting objects: 20, done.
@@ -423,9 +421,9 @@ If you have a branch named `serverfix` that you want to work on with others, you
 	To git@github.com:schacon/simplegit.git
 	 * [new branch]      serverfix -> serverfix
 
-This is a bit of a shortcut. Git automatically expands the `serverfix` branchname out to `refs/heads/serverfix:refs/heads/serverfix`, which means, “Take my serverfix local branch and push it to update the remote’s serverfix branch.” We’ll go over the `refs/heads/` part in detail in Chapter 9, but you can generally leave it off. You can also do `git push origin serverfix:serverfix`, which does the same thing — it says, “Take my serverfix and make it the remote’s serverfix.” You can use this format to push a local branch into a remote branch that is named differently. If you didn’t want it to be called `serverfix` on the remote, you could instead run `git push origin serverfix:awesomebranch` to push your local `serverfix` branch to the `awesomebranch` branch on the remote project.
+Đây là một cách làm tắt. Git tự động mở rộng nhánh `serverfix` thành `refs/heads/serverfix:refs/heads/serverfix`, có nghĩa là, "Hãy sử dụng nhánh nội bộ serverfix của tôi và đẩy nó lên để cập nhật nhánh serverfix trên máy chủ từ xa." Chúng ta sẽ đi sâu vào phần `refs/heads/` ở Chương 9, nhưng bạn thường có thể bỏ qua nó. Bạn cũng có thể chạy lệnh sau `git push origin serverfix:serverfix`, cách này cũng cho kết quả tương tự - nó có nghĩa là "Hãy sử dụng serverfix của tôi để tạo một serverfix trên máy chủ". Bạn có thể sử dụng định dạng này để đẩy một nhánh nội bộ lên một nhánh từ xa với một tên khác. Nếu bạn không muốn gọi nó là `serverfix` trên máy chủ, bạn có thể chạy lệnh sau `git push origin serverfix:awesomebranch` để đẩy nhánh nội bộ `serverfix` vào nhánh `awesomebranch` trên máy chủ trung tâm. 
 
-The next time one of your collaborators fetches from the server, they will get a reference to where the server’s version of `serverfix` is under the remote branch `origin/serverfix`:
+Lần tới một trong các đồng nghiệp của bạn truy xuất nó từ trên máy chủ, họ sẽ có một tham chiếu tới phiên bản trên máy chủ của `serverfix` dưới tên `origin/serverfix`:
 
 	$ git fetch origin
 	remote: Counting objects: 20, done.
@@ -435,165 +433,166 @@ The next time one of your collaborators fetches from the server, they will get a
 	From git@github.com:schacon/simplegit
 	 * [new branch]      serverfix    -> origin/serverfix
 
-It’s important to note that when you do a fetch that brings down new remote branches, you don’t automatically have local, editable copies of them. In other words, in this case, you don’t have a new `serverfix` branch — you only have an `origin/serverfix` pointer that you can’t modify.
+Điều quan trọng cần chú ý ở đây là khi bạn truy xuất dữ liệu từ máy chủ mà có kèm theo nhánh mới, Git sẽ không tự động tạo phiên bản nội bộ của nhánh đó. Nói cách khác, trong trường hợp này, bạn sẽ không có nhánh `serverfix` mới - bạn chỉ có một con trỏ tới `origin/serverfix` mà bạn không thể chỉnh sửa.
 
-To merge this work into your current working branch, you can run `git merge origin/serverfix`. If you want your own `serverfix` branch that you can work on, you can base it off your remote branch:
+Để tích hợp công việc hiện tại vào nhánh bạn đang làm việc, bạn có thể chạy `git merge origin/serverfix`. Nếu bạn muốn nhánh `serverfix` riêng để có thể làm việc trên đó, bạn có thể tách nó ra khỏi nhánh trung tâm bằng cách:
 
 	$ git checkout -b serverfix origin/serverfix
 	Branch serverfix set up to track remote branch refs/remotes/origin/serverfix.
 	Switched to a new branch "serverfix"
 
-This gives you a local branch that you can work on that starts where `origin/serverfix` is.
+Cách này sẽ tạo cho bạn một nhánh nội bộ mà bạn có thể làm việc, bắt đầu cùng một vị trí với `origin/serverfix`.
 
-### Tracking Branches ###
+### Theo Dõi Các Nhánh ###
 
-Checking out a local branch from a remote branch automatically creates what is called a _tracking branch_. Tracking branches are local branches that have a direct relationship to a remote branch. If you’re on a tracking branch and type `git push`, Git automatically knows which server and branch to push to. Also, running `git pull` while on one of these branches fetches all the remote references and then automatically merges in the corresponding remote branch.
+Check out một nhánh nội bộ từ một nhánh trung tâm tự động tạo ra một _tracking branch_. Tracking branches là các nhánh nội bộ có liên quan trực tiếp với một nhánh trung tâm. Nếu bạn đang ở trên một tracking branch và chạy `git push`, Git tự động biết nó sẽ phải đẩy lên nhánh nào, máy chủ nào. Ngoài ra, chạy `git pull` khi đang ở trên một trong những nhánh này sẽ truy xuất toàn bộ các tham chiếu từ xa và sau đó tự động tích hợp chúng với các nhánh từ xa tương ứng.
 
-When you clone a repository, it generally automatically creates a `master` branch that tracks `origin/master`. That’s why `git push` and `git pull` work out of the box with no other arguments. However, you can set up other tracking branches if you wish — ones that don’t track branches on `origin` and don’t track the `master` branch. The simple case is the example you just saw, running `git checkout -b [branch] [remotename]/[branch]`. If you have Git version 1.6.2 or later, you can also use the `--track` shorthand:
+Khi bạn tạo bản sao của một kho chứa, thông thường Git tự động tạp một nhánh `master` để theo dõi `origin/master`. Đó là lý do tại sao `git push` và `git pull` có thể chạy tốt mà không cần bất kỳ tham số nào. Tuy nhiên, bạn có thể cài đặt các tracking branch khác nếu muốn - các nhánh này không theo dõi nhánh trên `origin` cũng như `master`. Một ví dụ đơn giản giống như bạn vừa thấy: `git checkout -b [branch] [remotename]/[branch]`. Nếu bạn đang sử dụng Git phiên bản 1.6.2 trở lên, bạn có thể sử dụng `--track`:
 
 	$ git checkout --track origin/serverfix
 	Branch serverfix set up to track remote branch refs/remotes/origin/serverfix.
 	Switched to a new branch "serverfix"
 
-To set up a local branch with a different name than the remote branch, you can easily use the first version with a different local branch name:
+Để cài đặt một nhánh nội bộ sử dụng tên khác với tên mặc định trên nhánh trung tâm, bạn có thể dễ dàng sử dụng phiên bản đầu tiên với một tên nội bộ khác:
 
 	$ git checkout -b sf origin/serverfix
 	Branch sf set up to track remote branch refs/remotes/origin/serverfix.
 	Switched to a new branch "sf"
 
-Now, your local branch sf will automatically push to and pull from origin/serverfix.
+Bây giờ, nhánh nội bộ sf sẽ tự động "kéo và đẩy" từ origin/serverfix.
 
-### Deleting Remote Branches ###
+### Xóa Nhánh Trung Tâm ###
 
-Suppose you’re done with a remote branch — say, you and your collaborators are finished with a feature and have merged it into your remote’s `master` branch (or whatever branch your stable codeline is in). You can delete a remote branch using the rather obtuse syntax `git push [remotename] :[branch]`. If you want to delete your `serverfix` branch from the server, you run the following:
+Giả sử bạn và đồng nghiệp đã hoàn thành một chức năng nào đó và đã tích hợp nó vào nhánh `master` trung tâm (hoặc bất kỳ nhánh nào khác sử dụng cho việc lưu trữ các phiên bản ổn định). Bạn có thể xóa một nhánh trung tâm đi sử dụng cú pháp sau `git push [remotename] :[branch]`. Nếu bạn muốn xóa nhánh `serverfix` trên máy chủ, bạn có thể chạy lệnh sau:
 
 	$ git push origin :serverfix
 	To git@github.com:schacon/simplegit.git
 	 - [deleted]         serverfix
 
-Boom. No more branch on your server. You may want to dog-ear this page, because you’ll need that command, and you’ll likely forget the syntax. A way to remember this command is by recalling the `git push [remotename] [localbranch]:[remotebranch]` syntax that we went over a bit earlier. If you leave off the `[localbranch]` portion, then you’re basically saying, “Take nothing on my side and make it be `[remotebranch]`.”
+Vậy là đã xong, nhánh đó đã bị xóa khỏi máy chủ. Có thể bạn muốn đánh dấu trang này lại, vì bạn sẽ cần đến câu lệnh này và có thể bạn sẽ quên cú pháp của nó. Một cách để nhớ lệnh này là xem lại cú pháp chúng ta đã nhắc tới trước đó `git push [remotename] [localbranch]:[remotebranch]`. Nếu bạn bỏ qua phần `[localbranch]`, thì cơ bản bạn đang thực hiện "Không sử dụng gì từ phía nội bộ để tạo nhánh `[remotebranch]`."
 
 ## Rebasing ##
 
-In Git, there are two main ways to integrate changes from one branch into another: the `merge` and the `rebase`. In this section you’ll learn what rebasing is, how to do it, why it’s a pretty amazing tool, and in what cases you won’t want to use it.
+Trong Git, có hai cách chính để tích hợp các thay đổi từ nhánh này vào nhánh khác: đó là `merge` và `rebase`. Trong phần này bạn sẽ được tìm hiểu rebase là gì, sử dụng nó như thế nào, tại sao nó được coi là một công cụ khá tuyệt vời, và trong trường hợp nào thì không nên sử dụng nó.
 
-### The Basic Rebase ###
+### Cơ Bản về Rebase ###
 
-If you go back to an earlier example from the Merge section (see Figure 3-27), you can see that you diverged your work and made commits on two different branches.
+Nếu bạn xem lại ví dụ trước trong phần Tích Hợp (xem Hình 3-27), bạn có thể thấy rằng bạn đã phân nhánh công việc của bạn và thực hiện commit trên hai nhánh khác nhau.
 
 Insert 18333fig0327.png
-Figure 3-27. Your initial diverged commit history.
+Hình 3-17. Lần phân nhánh đầu tiên.
 
-The easiest way to integrate the branches, as we’ve already covered, is the `merge` command. It performs a three-way merge between the two latest branch snapshots (C3 and C4) and the most recent common ancestor of the two (C2), creating a new snapshot (and commit), as shown in Figure 3-28.
+Cách đơn giản nhất để tích hợp các nhánh, như chúng ta đã đề cập từ trước, đó là lệnh `merge`. Nó thực hiện tích hợp 3-chiều giữa hai snapshot mới nhất của hai nhánh (C3 và C4) và cha chung gần nhất của cả hai (C2), tạo mới một snapshot khác (và commit), như trong Hình 3-28.
 
 Insert 18333fig0328.png
-Figure 3-28. Merging a branch to integrate the diverged work history.
+Hình 3-28. Gộp nhánh lại để hợp nhất công việc bị tách ra trước đây.
 
-However, there is another way: you can take the patch of the change that was introduced in C3 and reapply it on top of C4. In Git, this is called _rebasing_. With the `rebase` command, you can take all the changes that were committed on one branch and replay them on another one.
+Tuy nhiên, còn có một cách khác: bạn có thể sử dụng bản vá của thay đổi được đưa ra ở C3 và áp dụng nó lên trên C4. Trong Git, đây được gọi là _rebasing_. Bằng cách sử dụng lệnh `rebase`, bạn có thể sử dụng tất cả các thay đổi được commit ở một nhánh và "chạy lại" (replay) chúng trên một nhánh khác.
 
-In this example, you’d run the following:
+Trong ví dụ này, bạn thực hiện như sau:
 
 	$ git checkout experiment
 	$ git rebase master
 	First, rewinding head to replay your work on top of it...
 	Applying: added staged command
 
-It works by going to the common ancestor of the two branches (the one you’re on and the one you’re rebasing onto), getting the diff introduced by each commit of the branch you’re on, saving those diffs to temporary files, resetting the current branch to the same commit as the branch you are rebasing onto, and finally applying each change in turn. Figure 3-29 illustrates this process.
+Nó thực hiện bằng cách đi tới commit cha chung của hai nhánh (nhánh bạn đang làm việc và nhánh bạn đang muốn rebase), tìm sự khác biệt trong mỗi commit của nhánh mà bạn đang làm việc, lưu lại các thay đổi đó vào một tập tin tạm thời, khôi phục lại nhánh hiện tại về cùng một commit với nhánh bạn đang rebase, và cuối cùng áp dụng lần lượt các thay đổi. Hình 3-29 minh họa toàn bộ quá trình này.
 
 Insert 18333fig0329.png
-Figure 3-29. Rebasing the change introduced in C3 onto C4.
+Hình 3-29. Quá trình rebase thay đổi ở C3 vào C4.
 
-At this point, you can go back to the master branch and do a fast-forward merge (see Figure 3-30).
+Đến lúc này, bạn có thể quay lại nhánh `master` và thực hiện fast-forward merge (xem Hình 3-30).
 
 Insert 18333fig0330.png
-Figure 3-30. Fast-forwarding the master branch.
+Hình 3-30. Di chuyển nhánh master lên phía trước.
+
+Bây giờ snapshot mà C3 trỏ tới cũng giống như snapshot được trở tới bởi C5 trong ví dụ sử dụng merge. Không có sự khác biệt nào khi so sánh kết quả của hai phương pháp này, nhưng sử dụng rebase sẽ cho chúng ta lịch sử rõ ràng hơn. Nếu bạn xem xét lịch sử của nhánh mà chúng ta rebase vào, nó giống như một đường thẳng: mọi thứ dường như xảy ra theo trình tự, thậm chí ban đầu nó diễn ra song song.
 
-Now, the snapshot pointed to by C3' is exactly the same as the one that was pointed to by C5 in the merge example. There is no difference in the end product of the integration, but rebasing makes for a cleaner history. If you examine the log of a rebased branch, it looks like a linear history: it appears that all the work happened in series, even when it originally happened in parallel.
 
-Often, you’ll do this to make sure your commits apply cleanly on a remote branch — perhaps in a project to which you’re trying to contribute but that you don’t maintain. In this case, you’d do your work in a branch and then rebase your work onto `origin/master` when you were ready to submit your patches to the main project. That way, the maintainer doesn’t have to do any integration work — just a fast-forward or a clean apply.
+Bình thường, bạn sử dụng cách này để đảm bảo rằng các commit được áp dụng một cách rõ ràng, rành mạch trên nhánh remote - có lẽ là một dự án mà bạn đang đóng góp chứ không phải duy trì nó. Trong trường hợp này, bạn thực hiện công việc trên một nhánh và sau đó rebase trở lại nhánh `origin/master` khi đã sẵn sàng. Theo cách này thì người duy trì dự án đó không phải thực hiện việc tích hợp - mà chỉ chi chuyển tiến lên phía trước (fast-forwar) hoặc đơn giản là áp dụng chúng vào.
 
-Note that the snapshot pointed to by the final commit you end up with, whether it’s the last of the rebased commits for a rebase or the final merge commit after a merge, is the same snapshot — it’s only the history that is different. Rebasing replays changes from one line of work onto another in the order they were introduced, whereas merging takes the endpoints and merges them together.
+Lưu ý rằng snapshot được trỏ tới bởi commit cuối cùng, cho dù nó là kết quả của việc rebase hay merge, thì nó vẫn giống nhau - chỉ khác nhau về các bước thực hiện mà thôi. Quá trình rebase được thực hiện bằng cách thực hiện lại các thay đổi từ nhánh này qua nhánh khác theo thứ tự chúng đã được thực hiện, trong khi đó merge lại lấy hai điểm kết thúc và gộp chúng lại với nhau.
 
-### More Interesting Rebases ###
+### Rebase Nâng Cao ###
 
-You can also have your rebase replay on something other than the rebase branch. Take a history like Figure 3-31, for example. You branched a topic branch (`server`) to add some server-side functionality to your project, and made a commit. Then, you branched off that to make the client-side changes (`client`) and committed a few times. Finally, you went back to your server branch and did a few more commits.
+Bạn cũng có thể thực hiện rebase trên một đối tượng khác mà không phải là nhánh rebase. Xem ví dụ Hình 3-31. Bạn tạo một nhánh chủ để (`server`) để thêm một số tính năng server-side vào dự án, và thực hiện một số commit. Sau đó bạn tạo một nhánh khác để thực hiện một số thay đổi cho phía client (`client`) và cũng commit vài lần. Cuối cùng, bạn quay trở lại nhánh server và thực hiện thêm một số commit nữa.
 
 Insert 18333fig0331.png
-Figure 3-31. A history with a topic branch off another topic branch.
+Hình 3-31. Nhánh chủ đề được tạo từ một nhánh chủ đề khác.
 
-Suppose you decide that you want to merge your client-side changes into your mainline for a release, but you want to hold off on the server-side changes until it’s tested further. You can take the changes on client that aren’t on server (C8 and C9) and replay them on your master branch by using the `--onto` option of `git rebase`:
+Giả sử bạn quyết định tích hợp các thay đổi phía client vào nhánh chính cho bản phát hành sắp tới, nhưng bạn vẫn muốn giữ các thay đổi server-side cho đến khi nó được kiểm tra kỹ lưỡng. Bạn có thể lấy các thay đổi ở client mà không có mặt ở server (C8 và C9) sau đó chạy lại (replay) chúng trên nhánh master bằng cách sử dụng lựa chọn `--onto` cho lệnh `git rebase`:
 
 	$ git rebase --onto master server client
 
-This basically says, “Check out the client branch, figure out the patches from the common ancestor of the `client` and `server` branches, and then replay them onto `master`.” It’s a bit complex; but the result, shown in Figure 3-32, is pretty cool.
+Lệnh này cơ bản nói rằng, "Hãy check out nhánh client, tìm ra các bản vá từ commit chung của nhánh `client` và `server`, sau đó thực thi lại vào nhánh `master`." Nó hơi phức tạp một chút nhưng kết quả như Hình 3-32 thì lại rất tuyệt.
 
 Insert 18333fig0332.png
-Figure 3-32. Rebasing a topic branch off another topic branch.
+Hình 3-32. Quá trình rebase nhánh chủ đề khỏi một nhánh chủ đề khác.
 
-Now you can fast-forward your master branch (see Figure 3-33):
+Bây giờ bạn có thể di chuyển con trỏ của nhánh master tiến lên phía trước (xem Hình 3-33):
 
 	$ git checkout master
 	$ git merge client
 
 Insert 18333fig0333.png
-Figure 3-33. Fast-forwarding your master branch to include the client branch changes.
+Hình 3-33. Di chuyển nhánh master lên phía trước để bao gồm các thay đổi của nhánh client.
 
-Let’s say you decide to pull in your server branch as well. You can rebase the server branch onto the master branch without having to check it out first by running `git rebase [basebranch] [topicbranch]` — which checks out the topic branch (in this case, `server`) for you and replays it onto the base branch (`master`):
+Giả sử rằng bạn quyết định kéo về cả nhánh trên máy chủ. Bạn có thể rebase nhánh trên máy chủ đó vào nhánh master mà không phải checkout trước bằng lệnh `git rebase [basebranch] [topicbranch]` - lệnh này sẽ checkout nhánh chủ để (trong trường hợp này là `server`) cho bạn và áp dụng lại các thay đổi vào nhánh cơ sở (base) `master`:
 
 	$ git rebase master server
 
-This replays your `server` work on top of your `master` work, as shown in Figure 3-34.
+Lệnh này sẽ thực hiện lại các thay đổi trên nhánh `server` chèn vào nhánh `master` như trong Hình 3-34.
 
 Insert 18333fig0334.png
-Figure 3-34. Rebasing your server branch on top of your master branch.
+Hình 3-34. Rebase nhánh server chèn lên nhánh master. 
 
-Then, you can fast-forward the base branch (`master`):
+Sau đó bạn có thể di chuyển con trỏ nhánh base (`master`):
 
 	$ git checkout master
 	$ git merge server
 
-You can remove the `client` and `server` branches because all the work is integrated and you don’t need them anymore, leaving your history for this entire process looking like Figure 3-35:
+Bạn có thể xóa nhánh `client` và `server` vì tất cả công việc đã được tích hợp vào master và bạn không cần đến chúng nữa, lịch sử quả toàn bộ quá trình vừa rồi giống như Hình 3-35:
 
 	$ git branch -d client
 	$ git branch -d server
 
 Insert 18333fig0335.png
-Figure 3-35. Final commit history.
+Hình 3-35. Lịch sử commit cuối cùng.
 
-### The Perils of Rebasing ###
+### Rủi Ro của Rebase ###
 
-Ahh, but the bliss of rebasing isn’t without its drawbacks, which can be summed up in a single line:
+Mặc dù rebase rất hữu ích nhưng nó cũng có không ít những mặt hạn chế, điều này có thể tổng kết bằng câu sau đây:
 
-**Do not rebase commits that you have pushed to a public repository.**
+**Không được rebase các commit mà bạn đã đẩy lên một kho chứa công khai.**
 
-If you follow that guideline, you’ll be fine. If you don’t, people will hate you, and you’ll be scorned by friends and family.
+Miễn là bạn làm theo hướng dẫn này, sẽ không có chuyện gì xảy ra. Nếu không, mọi người sẽ ghét bạn, và bạn sẽ bị bạn bè và gia đình coi thường.
 
-When you rebase stuff, you’re abandoning existing commits and creating new ones that are similar but different. If you push commits somewhere and others pull them down and base work on them, and then you rewrite those commits with `git rebase` and push them up again, your collaborators will have to re-merge their work and things will get messy when you try to pull their work back into yours.
+Khi bạn thực hiện rebase, bạn đang bỏ đi các commit đã tồn tại và tái tạo lại các commit mới tương tự nhưng thực ra khác biệt. Nếu bạn đẩy commit ở một nơi nào đó và mọi người kéo xuống máy của họ, sau đó bạn sửa lại các commit đó bằng lệnh `git rebase` và đẩy lên một lần nữa, đồng nghiệp của bạn sẽ phải tích hợp lại công việc của họ và mọi thứ sẽ rối tung lên khi bạn cố gắng kéo các thay đổi của họ ngược lại máy bạn.
 
-Let’s look at an example of how rebasing work that you’ve made public can cause problems. Suppose you clone from a central server and then do some work off that. Your commit history looks like Figure 3-36.
+Hãy cùng xem một ví dụ làm sao việc rebase công khai có thể gây sự cố. Giả sử bạn tạo bản sao từ một máy chủ trung tâm và thực hiện một số thay đổi từ đó. Lịch sử commit của bạn sẽ giống như Hình 3-36.
 
 Insert 18333fig0336.png
-Figure 3-36. Clone a repository, and base some work on it.
+Hình 3-36. Tạo bản sao một kho chứa, và base một số thay đổi vào đó.
 
-Now, someone else does more work that includes a merge, and pushes that work to the central server. You fetch them and merge the new remote branch into your work, making your history look something like Figure 3-37.
+Bây giờ, một người khác thực hiện một số thay đổi khác có kèm theo một lần tích hợp (merge), và đẩy lên máy chủ trung tâm. Bạn truy xuất chúng và tích hợp nhánh trung tâm mới đó vào của bạn, lúc này lịch sử của bạn sẽ giống như Hình 3-37.
 
 Insert 18333fig0337.png
-Figure 3-37. Fetch more commits, and merge them into your work.
+Hình 3-37. Truy xuất thêm các commit và tích hợp lại.
 
-Next, the person who pushed the merged work decides to go back and rebase their work instead; they do a `git push --force` to overwrite the history on the server. You then fetch from that server, bringing down the new commits.
+Tiếp theo, người đã đẩy tích hợp đó quyết định lại và rebase lại những thay đổi của họ; họ thực hiện `git push --force` để ghi đè lịch sử trên máy chủ. Sau đó bạn truy xuất lại dữ liệu từ máy chủ, đưa về các commit mới.
 
 Insert 18333fig0338.png
-Figure 3-38. Someone pushes rebased commits, abandoning commits you’ve based your work on.
+Hình 3-38. Một người nào đó đẩy lên các commit rebase, bỏ đi các commit có chứa thay đổi của bạn.
 
-At this point, you have to merge this work in again, even though you’ve already done so. Rebasing changes the SHA-1 hashes of these commits so to Git they look like new commits, when in fact you already have the C4 work in your history (see Figure 3-39).
+Lúc này, bạn phải tích hợp lại một lần nữa các thay đổi này, mặc dù trước đó bạn đã làm rồi. Quá trình rebase thay đổi mã băm SHA-1 của các commit này vì thế đối với Git chúng giống như các commit mới, mà thực tế thì bạn đã có C4 trong lịch sử của bạn (xem Hình 3-39).
 
 Insert 18333fig0339.png
-Figure 3-39. You merge in the same work again into a new merge commit.
+Hình 3-39. Bạn tích hợp các thay đổi tương tự lại một lần nữa vào một commit tích hợp mới.
 
-You have to merge that work in at some point so you can keep up with the other developer in the future. After you do that, your commit history will contain both the C4 and C4' commits, which have different SHA-1 hashes but introduce the same work and have the same commit message. If you run a `git log` when your history looks like this, you’ll see two commits that have the same author date and message, which will be confusing. Furthermore, if you push this history back up to the server, you’ll reintroduce all those rebased commits to the central server, which can further confuse people.
+Bạn phải tích hợp thay đổi đó để có thể theo kịp với các lập trình viên khác về sau này. Sau khi thực hiện việc này, lịch sử commit của bạn sẽ bao gồm cả hai commit C4 và C4' có mã SHA-1 khác nhau nhưng lại có cùng chung nội dung thay đổi cũng như thông điệp commit. Nếu bạn chạy lệnh `git log` trong trường hợp này bạn sẽ thấy hai commit cùng chung ngày commit và thông điệp, điều này sẽ gây khó hiểu cho bạn. Hơn nữa, nếu bạn đẩy chúng ngược lên máy chủ, bạn sẽ đưa vào một lần nữa tất cả các commit đã rebase đó và sẽ gây khó hiểu cho nhiều người khác nữa.
 
-If you treat rebasing as a way to clean up and work with commits before you push them, and if you only rebase commits that have never been available publicly, then you’ll be fine. If you rebase commits that have already been pushed publicly, and people may have based work on those commits, then you may be in for some frustrating trouble.
+Nếu bạn sử dụng rebase như là cách để dọn dẹp các commit trước khi đẩy chúng lên, và nếu như bạn chỉ rebase commit chưa bao giờ được công khai, thì sẽ không có chuyện gì xảy ra. Nếu bạn rebase các commit đã được công khai và mọi người có thể đã tích hợp (base) nó vào công việc của họ thì bạn có thể gặp phải các vấn đề thực sự khó chị.
 
-## Summary ##
+## Tổng Kết ##
 
-We’ve covered basic branching and merging in Git. You should feel comfortable creating and switching to new branches, switching between branches and merging local branches together.  You should also be able to share your branches by pushing them to a shared server, working with others on shared branches and rebasing your branches before they are shared.
+Chúng ta đã đề cập tới các khái niệm cơ bản về phân nhánh và tích hợp trong Git. Bạn nên nắm vững việc tạo mới, di chuyển giữa các nhánh và tích hợp các nhánh nội bộ lại với nhau. Bạn cũng nên có khả năng chia sẽ các nhánh bằng cách đẩy chúng lên một máy chủ trung tâm, cộng tác với các thành viên khác trên các nhánh dùng chung và rebase chúng trước khi chia sẻ.
\ No newline at end of file

From b487a47a4092655e3068a7284084ed9ab8aa2da4 Mon Sep 17 00:00:00 2001
From: Tuan Vu <contact@tuanva.co.uk>
Date: Fri, 3 Jan 2014 18:44:48 +0000
Subject: [PATCH 036/690] =?UTF-8?q?using=20't=C3=ADch=20h=E1=BB=A3p'=20ins?=
 =?UTF-8?q?tead=20of=20'g=E1=BB=99p'=20as=20translation=20for=20merge?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 vi/02-git-basics/01-chapter2.markdown    |  22 +--
 vi/03-git-branching/01-chapter3.markdown | 211 ++++++++++++-----------
 2 files changed, 117 insertions(+), 116 deletions(-)

diff --git a/vi/02-git-basics/01-chapter2.markdown b/vi/02-git-basics/01-chapter2.markdown
index 73ef3e6a7..5904099a7 100644
--- a/vi/02-git-basics/01-chapter2.markdown
+++ b/vi/02-git-basics/01-chapter2.markdown
@@ -107,7 +107,7 @@ Hãy sửa một tập tin đang được theo dõi. Nếu bạn sửa một t
 	#	modified:   benchmarks.rb
 	#
 
-Tập tin `benchmarks.rb` nằm trong danh sách "Các thay đổi chưa được tổ chức/đánh dấu để commit" - có nghĩa là một tập tin đang được theo dõi đã bị thay đổi trong thư mục làm việc nhưng chưa được "staged". Để làm việc này, bạn chạy lệnh `git add` (đó là một câu lệnh đa chức năng - bạn có thể dùng nó để bắt đầu theo dõi tập tin, tổ chức tập tin, hoặc các việc khác như đánh dấu đã giải quyết xong các tập tin có nội dung mâu thuẫn nhau khi gộp). Chạy `git add` để "stage" tập tin `benchmarks.rb` và sau đó chạy lại lệnh `git status`: 
+Tập tin `benchmarks.rb` nằm trong danh sách "Các thay đổi chưa được tổ chức/đánh dấu để commit" - có nghĩa là một tập tin đang được theo dõi đã bị thay đổi trong thư mục làm việc nhưng chưa được "staged". Để làm việc này, bạn chạy lệnh `git add` (đó là một câu lệnh đa chức năng - bạn có thể dùng nó để bắt đầu theo dõi tập tin, tổ chức tập tin, hoặc các việc khác như đánh dấu đã giải quyết xong các tập tin có nội dung mâu thuẫn nhau khi tích hợp). Chạy `git add` để "stage" tập tin `benchmarks.rb` và sau đó chạy lại lệnh `git status`: 
 
 	$ git add benchmarks.rb
 	$ git status
@@ -589,7 +589,7 @@ The lines must be formatted as follows
 
 Có thể bạn băn khoăn về sự khác nhau giữa _tác giả_ (author) và _người commit_ (committer). _Tác giả_ là người đầu tiên viết bản vá (patch), trong khi đó _người commit_ là người cuối cùng áp dụng miếng vá đó. Như vậy, nếu bạn gửi một bản vá cho một dự án và một trong các thành viên chính của dự án "áp dụng" (chấp nhận) bản vá đó, cả hai sẽ cùng được ghi nhận công trạng (credit) - bạn với vai trò là tác giả và thành viên của dự án trong vai trò người commit. Chúng ta sẽ bàn kỹ hơn một chút về sự khác nhau này trong *Chương 5*.
 
-Lựa chọn `oneline` và `formar` đặc biệt hữu ích khi sử dụng với một tham số khác của `log` là `--graph`. Khi sử dụng, tham số này sẽ thêm một biểu đồ sử dụng dựa trên các ký tự ASCII hiển thị nhánh và lịch sử gộp các tập tin của bạn, chúng ta có thể thấy trong dự án Grit như sau:
+Lựa chọn `oneline` và `formar` đặc biệt hữu ích khi sử dụng với một tham số khác của `log` là `--graph`. Khi sử dụng, tham số này sẽ thêm một biểu đồ sử dụng dựa trên các ký tự ASCII hiển thị nhánh và lịch sử tích hợp các tập tin của bạn, chúng ta có thể thấy trong dự án Grit như sau:
 
 	$ git log --pretty=format:"%h %s" --graph
 	* 2d3acf9 ignore errors from SIGCHLD on trap
@@ -619,7 +619,7 @@ The lines must be formatted as follows
 	--name-status	Hiển thị các tập tin bị ảnh hưởng với các thông tin như thêm mới/sửa/xoá.
 	--abbrev-commit	Chỉ hiện thị một số ký tự đầu của mã băm SHA-1 thay vì tất cả 40.
 	--relative-date	Hiển thị ngày ở định dạng tương đối (ví dụ, "2 weeks ago") thay vì định dạng đầy đủ.
-	--graph	Hiển thị biểu đồ ASCII của nhánh và lịch sử gộp cùng với thông tin đầu ra khác.
+	--graph	Hiển thị biểu đồ ASCII của nhánh và lịch sử tích hợp cùng với thông tin đầu ra khác.
 	--pretty	Hiện thị các commit sử dụng một định dạng khác. Các lựa chọn bao gồm oneline, short, full, fuller và format (cho phép bạn sử dụng định dạng riêng).
 	--oneline	Một lựa chọn ngắn, thuận tiện cho `--pretty=oneline --abbrev-commit`.
 
@@ -651,7 +651,7 @@ The lines must be formatted as follows
 	--author	Chỉ hiện thị các commit mà tên tác giả thoả mãn điều kiện nhất định.
 	--committer	Chỉ hiện thị các commit mà tên người commit thoả mãn điều kiện nhất định.
 
-Ví dụ, bạn muốn xem các commit đã thay đổi các tập tin thử nghiệm trong lịch sử mã nguồn của Git, được commit bởi Junio Hâmno trng tháng 10 năm 2008 mà chưa được gộp/trộn, bạn có thể chạy lệnh sau:
+Ví dụ, bạn muốn xem các commit đã thay đổi các tập tin thử nghiệm trong lịch sử mã nguồn của Git, được commit bởi Junio Hâmno trng tháng 10 năm 2008 mà chưa được tích hợp/gộp, bạn có thể chạy lệnh sau:
 
 	$ git log --pretty="%h - %s" --author=gitster --since="2008-10-01" \
 	   --before="2008-11-01" --no-merges -- t/
@@ -815,7 +815,7 @@ Bây giờ bạn có thể sử dụng `pb` trong các câu lệnh, nó có tác
 	 * [new branch]      master     -> pb/master
 	 * [new branch]      ticgit     -> pb/ticgit
 
-Nhánh chính của Paul có thể truy cập cục bộ như là `pb/master` - bạn có thể gộp nó vào các nhánh của bạn, hoặc sử dụng nó như là một nhánh cục bộ ở thời điểm đó nếu như bạn muốn kiểm tra nó.  
+Nhánh chính của Paul có thể truy cập cục bộ như là `pb/master` - bạn có thể tích hợp nó vào các nhánh của bạn, hoặc sử dụng nó như là một nhánh cục bộ ở thời điểm đó nếu như bạn muốn kiểm tra nó.  
 
 ### Truy Cập Và Kéo Về Từ Máy Chủ Trung Tâm ###
 
@@ -823,11 +823,11 @@ Như bạn vừa thấy, để lấy dữ liệu của các dự án từ xa v
 
 	$ git fetch [remote-name]
 
-Lệnh này sẽ truy cập vào dự án từ xa đó và kéo xuống toàn bộ dữ liệu mà bạn chưa có trong đó cho bạn. Sau khi thực hiện xong bước này, bạn đã có các tham chiếu đến toàn bộ các nhánh của dự án từ xa đó, nơi mà bạn có thể gộp hoặc kiểm tra bất kỳ thời điểm nào. (Chúng ta sẽ đề cập chi tiết hơn về nhánh là gì và sử dụng chúng như thế nào ở *Chương 3*.)
+Lệnh này sẽ truy cập vào dự án từ xa đó và kéo xuống toàn bộ dữ liệu mà bạn chưa có trong đó cho bạn. Sau khi thực hiện xong bước này, bạn đã có các tham chiếu đến toàn bộ các nhánh của dự án từ xa đó, nơi mà bạn có thể tích hợp hoặc kiểm tra bất kỳ thời điểm nào. (Chúng ta sẽ đề cập chi tiết hơn về nhánh là gì và sử dụng chúng như thế nào ở *Chương 3*.)
 
-Nếu bạn tạo bản sao từ một kho chứa nào đó khác, lệnh này sẽ tự động kho chứa từ xa đó vào dưới tên *origin*. Vì thế, `git fetch origin` sẽ truy xuất (fetch) bất kỳ thay đổi mới nào được đẩy lên trên máy chủ từ sau khi bạn sao chép (hoặc lần truy xuất cuối cùng). Hãy ghi nhớ một điều quan trọng là lệnh `fetch` kéo tất cả dữ liệu về kho chứa trên máy của bạn - nó không tự động gộp với bất kỳ thay đổi nào mà bạn đang thực hiện. Bạn phải gộp nó một cách thủ không vào kho chứa nội bộ khi đã sẵn sàng.
+Nếu bạn tạo bản sao từ một kho chứa nào đó khác, lệnh này sẽ tự động kho chứa từ xa đó vào dưới tên *origin*. Vì thế, `git fetch origin` sẽ truy xuất (fetch) bất kỳ thay đổi mới nào được đẩy lên trên máy chủ từ sau khi bạn sao chép (hoặc lần truy xuất cuối cùng). Hãy ghi nhớ một điều quan trọng là lệnh `fetch` kéo tất cả dữ liệu về kho chứa trên máy của bạn - nó không tự động tích hợp với bất kỳ thay đổi nào mà bạn đang thực hiện. Bạn phải tích hợp nó một cách thủ không vào kho chứa nội bộ khi đã sẵn sàng.
 
-Nếu bạn có một nhánh được cài đặt để theo dõi một nhánh từ xa khác (xem phần tiếp theo và *Chương 3* để biết thêm chi tiết), bạn có thể sử dụng lệnh `git pull` để tự động truy xuất và sau đó gộp nhánh từ xa vào nhánh nội bộ. Đây có thể là cách dễ dàng và thoải mái hơn cho bạn; và mặc định thì, lệnh `git clone` tự động cài đặt nhánh chính nội bộ (local master branch) để theo dõi nhanh chính trên máy chủ từ xa (remote master branch) - nơi mà bạn sao chép về, (giả sử máy chủ từ xa có một nhánh chính). Thường thì khi chạy lệnh `git pull` nó sẽ truy xuất dữ liệu từ máy chủ trung tâm nơi lần đầu bạn sao chép và cố gắng tự động gộp chúng vào kho chứa hiện thời nơi bạn đang làm việc. 
+Nếu bạn có một nhánh được cài đặt để theo dõi một nhánh từ xa khác (xem phần tiếp theo và *Chương 3* để biết thêm chi tiết), bạn có thể sử dụng lệnh `git pull` để tự động truy xuất và sau đó tích hợp nhánh từ xa vào nhánh nội bộ. Đây có thể là cách dễ dàng và thoải mái hơn cho bạn; và mặc định thì, lệnh `git clone` tự động cài đặt nhánh chính nội bộ (local master branch) để theo dõi nhanh chính trên máy chủ từ xa (remote master branch) - nơi mà bạn sao chép về, (giả sử máy chủ từ xa có một nhánh chính). Thường thì khi chạy lệnh `git pull` nó sẽ truy xuất dữ liệu từ máy chủ trung tâm nơi lần đầu bạn sao chép và cố gắng tự động tích hợp chúng vào kho chứa hiện thời nơi bạn đang làm việc. 
 
 ### Đẩy Lên Máy Chủ Trung Tâm ###
 
@@ -835,7 +835,7 @@ Nếu bạn có một nhánh được cài đặt để theo dõi một nhánh t
 
 	$ git push origin master
 
-Lệnh này chỉ hoạt động nếu bạn sao chép từ một máy chủ mà trên đó bạn được cấp phép quyền ghi và chưa có ai khác đẩy dữ liệu lên tại thời điểm đó. Nếu bạn và ai khác cùng sao chép tại cùng một thời điểm; người kia đẩy ngược lên, sau đó bạn cũng muốn đẩy lên, thì hành động của bạn sẽ bị từ chối ngay tức khắc. Trước hết bạn phải thực hiện kéo các thay đổi mà người đó đã thực hiện và sát nhập/gộp nó vào của bạn, sau đó bạn mới được phép đẩy lên. Xem *Chương 3* để hiểu chi tiết hơn về làm thế nào để đẩy lên máy chủ trung tâm. 
+Lệnh này chỉ hoạt động nếu bạn sao chép từ một máy chủ mà trên đó bạn được cấp phép quyền ghi và chưa có ai khác đẩy dữ liệu lên tại thời điểm đó. Nếu bạn và ai khác cùng sao chép tại cùng một thời điểm; người kia đẩy ngược lên, sau đó bạn cũng muốn đẩy lên, thì hành động của bạn sẽ bị từ chối ngay tức khắc. Trước hết bạn phải thực hiện kéo các thay đổi mà người đó đã thực hiện và tích hợp/gộp nó vào của bạn, sau đó bạn mới được phép đẩy lên. Xem *Chương 3* để hiểu chi tiết hơn về làm thế nào để đẩy lên máy chủ trung tâm. 
 
 ### Kiểm Tra Một Máy Chủ Trung Tâm ###
 
@@ -850,7 +850,7 @@ Nếu bạn muốn xem chi tiết hơn các thông tin về một kho chứa tru
 	    master
 	    ticgit
 
-Lệnh này liệt kê địa chỉ của kho chứa trung tâm cũng như thông tin các nhánh đang theo dõi. Nó cho bạn biết rằng nếu như bạn đang ở nhánh master và chạy lệnh git pull, nó sẽ tự động gộp nhánh này với nhánh trung tâm sau khi truy xuất toàn bộ các tham chiếu từ xa. Nó cũng liệt kê tất cả các tham chiếu từ xa mà nó đã kéo xuống đó.
+Lệnh này liệt kê địa chỉ của kho chứa trung tâm cũng như thông tin các nhánh đang theo dõi. Nó cho bạn biết rằng nếu như bạn đang ở nhánh master và chạy lệnh git pull, nó sẽ tự động tích hợp nhánh này với nhánh trung tâm sau khi truy xuất toàn bộ các tham chiếu từ xa. Nó cũng liệt kê tất cả các tham chiếu từ xa mà nó đã kéo xuống đó.
 
 Đây là một ví dụ đơn giản mà bạn thường xuyên gặp phải. Khi bạn sử dụng Git thường xuyên hơn, bạn sẽ thường thấy nhiều thông tin hơn từ lệnh `git remote show`:
 
@@ -876,7 +876,7 @@ Lệnh này liệt kê địa chỉ của kho chứa trung tâm cũng như thôn
 	  Local branch pushed with 'git push'
 	    master:master
 
-Lệnh này hiển thị nhánh nào tự động được đẩy lên khi bạn chạy `git push` trên một nhánh nhất định. Nó cũng cho bạn thấy nhánh nào trên máy chủ trung tâm mà bạn chưa có, nhánh nào bạn có mà đã bị xóa trên máy chủ, và các nhánh nào sẽ tự động được gộp khi chạy lệnh `git pull`. 
+Lệnh này hiển thị nhánh nào tự động được đẩy lên khi bạn chạy `git push` trên một nhánh nhất định. Nó cũng cho bạn thấy nhánh nào trên máy chủ trung tâm mà bạn chưa có, nhánh nào bạn có mà đã bị xóa trên máy chủ, và các nhánh nào sẽ tự động được tích hợp khi chạy lệnh `git pull`. 
 
 ### Xóa Và Đổi Tên Từ Xa ###
 
diff --git a/vi/03-git-branching/01-chapter3.markdown b/vi/03-git-branching/01-chapter3.markdown
index 8924dbe5e..6feadfe84 100644
--- a/vi/03-git-branching/01-chapter3.markdown
+++ b/vi/03-git-branching/01-chapter3.markdown
@@ -1,152 +1,152 @@
-# Git Branching #
+# Phân Nhánh Trong Git #
 
-Nearly every VCS has some form of branching support. Branching means you diverge from the main line of development and continue to do work without messing with that main line. In many VCS tools, this is a somewhat expensive process, often requiring you to create a new copy of your source code directory, which can take a long time for large projects.
+Hầu hết mỗi hệ quản trị phiên bản (VCS) đều hỗ trợ một dạng của phân nhánh. Phân nhánh có nghĩa là bạn phân tách ra từ luồng phát triển chính và tiếp tục làm việc mà không sợ làm ảnh hưởng đến luồng chính. Trong nhiều VCS, đây dường như là một quá trình đòi hỏi nhiều công sức và sự cố gắng, thường thì bạn tạo một bản sao mới từ thư mục chứa mã nguồn, nó có thể mất khá nhiều thời gian trên các dự án lớn.
 
-Some people refer to the branching model in Git as its “killer feature”  , and it certainly sets Git apart in the VCS community. Why is it so special? The way Git branches is incredibly lightweight, making branching operations nearly instantaneous and switching back and forth between branches generally just as fast. Unlike many other VCSs, Git encourages a workflow that branches and merges often, even multiple times in a day. Understanding and mastering this feature gives you a powerful and unique tool and can literally change the way that you develop.
+Nhiều người nhắc đến mô hình phân nhánh của Git như là "chức năng hủy diệt", và chính nó làm cho Git trở nên khác biệt trong cộng đồng VCS. Tại sao nó lại đặc biệt đến vậy? Cách Git phân nhánh "nhẹ" một cách đáng kinh ngạc, các hoạt động tạo nhánh xảy ra gần như ngay lập tức và việc di chuyển đi lại giữa các nhánh cũng thường rất nhanh. Không giống các VCSs khác, Git khuyến khích sử dụng rẽ nhánh và tích hợp thường xuyên cho workflow, thậm chí nhiều lần trong một ngày. Hiểu và thành thạo tính năng này cung cấp cho bạn một công cụ mạnh mẽ, độc đáo và có thể thay đổi được cách bạn thường phát triển phần mềm.
 
-## What a Branch Is ##
+## Nhánh Là Gì? ##
 
-To really understand the way Git does branching, we need to take a step back and examine how Git stores its data. As you may remember from Chapter 1, Git doesn’t store data as a series of changesets or deltas, but instead as a series of snapshots.
+Để có thể thực sử hiểu được cách phân nhánh của Git, chúng ta cần nhìn và xem xét lại cách Git lưu trữ dữ liệu. Như bạn đã biết từ Chương 1, Git không lưu trữ dữ liệu dưới dạng một chuỗi các thay đổi hoặc delta, mà thay vào đó là một chuỗi các ảnh (snapshot).
 
-When you commit in Git, Git stores a commit object that contains a pointer to the snapshot of the content you staged, the author and message metadata, and zero or more pointers to the commit or commits that were the direct parents of this commit: zero parents for the first commit, one parent for a normal commit, and multiple parents for a commit that results from a merge of two or more branches.
+Khi bạn commit, Git lưu trữ đối tượng commit mà có chứa một con trỏ tới ảnh của nội dung bạn đã tổ chức (stage), tác giả và thông điệp, hay 0 hoặc nhiều con trỏ khác trỏ tới một hoặc nhiều commit cha trực tiếp của commit đó: commit đầu tiên không có cha, commit bình thường có một cha, và nhiều cha cho commit là kết quả được tích hợp lại từ hai hoặc nhiều nhánh.
 
-To visualize this, let’s assume that you have a directory containing three files, and you stage them all and commit. Staging the files checksums each one (the SHA-1 hash we mentioned in Chapter 1), stores that version of the file in the Git repository (Git refers to them as blobs), and adds that checksum to the staging area:
+Để hình dung ra vấn đề này, hãy giả sử bạn có một thư mục chứa ba tập tin, và bạn tổ chức tất cả chúng để commit. Quá trình tổ chức các tập tin sẽ thực hiện băm từng tập (sử dụng mã SHA-1 được đề cập ở Chương 1), lưu trữ phiên bản đó của tập tin trong kho chứa Git (Git xem chúng như là các blob), và thêm mã băm đó vào khu vực tổ chức:
 
 	$ git add README test.rb LICENSE
 	$ git commit -m 'initial commit of my project'
 
-Running `git commit` checksums all project directories and stores them as `tree` objects in the Git repository. Git then creates a `commit` object that has the metadata and a pointer to the root project `tree` object so it can re-create that snapshot when needed.
+Lệnh `git commit` khi chạy sẽ băm tất cả các thư mục trong dự án và lưu chúng lại dưới dạng đối tượng `tree`. Sau đó Git tạo một đối tượng `commit` có chứa các thông tin mô tả (metadata) và một con trỏ trỏ tới đối tương `tree` gốc của dự án vì thế nó có thể tạo lại ảnh đó khi cần thiết.
 
-Your Git repository now contains five objects: one blob for the contents of each of your three files, one tree that lists the contents of the directory and specifies which file names are stored as which blobs, and one commit with the pointer to that root tree and all the commit metadata. Conceptually, the data in your Git repository looks something like Figure 3-1.
+Kho chứa Git của bạn bây giờ có chứa năm đối tượng: một blob cho nội dung của từng tập tin, một "cây" liệt kê nội dung của thư mục và chỉ rõ tên tập tin nào được lưu trữ trong blob nào, và một commit có con trỏ trỏ tới cây gốc và tất cả các thông tin mô tả commit. Về mặt lý thuyết, dữ liệu trong kho chứa Git có hình dạng như trong Hình 3-1. 
 
 Insert 18333fig0301.png
-Figure 3-1. Single commit repository data.
+Hình 3-1. Dữ liệu trong kho chứa với một commit.
 
-If you make some changes and commit again, the next commit stores a pointer to the commit that came immediately before it. After two more commits, your history might look something like Figure 3-2.
+Nếu bạn thực hiện một số thay đổi và commit lại thì commit tiếp theo sẽ lưu một con trỏ tới commit ngay trước nó. Sau hai commit, lịch sử của dự án sẽ tương tự như trong Hình 3-2.
 
 Insert 18333fig0302.png
-Figure 3-2. Git object data for multiple commits.
+Hình 3-2. Các đối tượng dữ liệu của Git trong kho chứa nhiều commit. 
 
-A branch in Git is simply a lightweight movable pointer to one of these commits. The default branch name in Git is master. As you initially make commits, you’re given a `master` branch that points to the last commit you made. Every time you commit, it moves forward automatically.
+Một nhánh trong Git đơn thuần là một con trỏ có khả năng di chuyển được, trỏ đến một trong những commit này. Tên nhánh mặc định của Git là master. Như trong những lần commit đầu tiên, chúng đều được trỏ tới nhánh `master`. Và mỗi lần bạn thực hiện commit, nó sẽ được tự động ghi vào theo hướng tiến lên. (move forward)
 
 Insert 18333fig0303.png
-Figure 3-3. Branch pointing into the commit data’s history.
+Hình 3-3. Nhánh trỏ tới dữ liệu commit.
 
-What happens if you create a new branch? Well, doing so creates a new pointer for you to move around. Let’s say you create a new branch called testing. You do this with the `git branch` command:
+Chuyện gì xảy ra nếu bạn tạo một nhánh mới? Làm như vậy sẽ tạo ra một con trỏ mới cho phép bạn di chuyển vòng quanh. Ví dụ bạn tạo một nhánh mới có tên testing. Việc này được thực hiện bằng lệnh `git branch`:
 
 	$ git branch testing
 
-This creates a new pointer at the same commit you’re currently on (see Figure 3-4).
+Nó sẽ tạo một con trỏ mới, cùng trỏ tới commit hiện tại (mới nhất) của bạn (xem Hình 3-4).
 
 Insert 18333fig0304.png
-Figure 3-4. Multiple branches pointing into the commit’s data history.
+Hình 304. Nhiều nhánh cùng trỏ vào dữ liệu commit.
 
-How does Git know what branch you’re currently on? It keeps a special pointer called HEAD. Note that this is a lot different than the concept of HEAD in other VCSs you may be used to, such as Subversion or CVS. In Git, this is a pointer to the local branch you’re currently on. In this case, you’re still on master. The git branch command only created a new branch — it didn’t switch to that branch (see Figure 3-5).
+Vậy làm sao Git có thể biết được rằng bạn đang làm việc trên nhánh nào? Git giữ một con trỏ đặc biệt có tên HEAD. Lưu ý khái niệm về HEAD ở đây khác biệt hoàn toàn với các VCS khác mà bạn có thể đã sử dụng qua, như là Subversion hoặc CVS. Trong Git, đây là một con trỏ tới nhánh nội bộ mà bạn đang làm việc. Trong trường hợp này, bạn vẫn đang trên nhánh master. Lệnh git branch chỉ tạo một nhánh mới chứ không tự chuyển sang nhánh đó cho bạn (xem Hình 3-5).
 
 Insert 18333fig0305.png
-Figure 3-5. HEAD file pointing to the branch you’re on.
+Hình 3-5. Tập tin HEAD trỏ tới nhánh mà bạn đang làm việc.
 
-To switch to an existing branch, you run the `git checkout` command. Let’s switch to the new testing branch:
+Để chuyển sang một nhánh đang tồn tại, bạn sử dụng lệnh `git checkout`. Hãy cùng chuyển sang nhánh testing mới:
 
 	$ git checkout testing
 
-This moves HEAD to point to the testing branch (see Figure 3-6).
+Lệnh này sẽ chuyển con trỏ HEAD sang nhánh testing (xem Hình 3-6).
 
 Insert 18333fig0306.png
-Figure 3-6. HEAD points to another branch when you switch branches.
+Hình 3-6. HEAD trỏ tới nhánh khác khi bạn chuyển nhánh.
 
-What is the significance of that? Well, let’s do another commit:
+Ý nghĩa của việc này là gì? Hãy cùng thực hiện một commit khác:
 
 	$ vim test.rb
 	$ git commit -a -m 'made a change'
 
-Figure 3-7 illustrates the result.
+Hình 3-7 minh họa kết quả.
 
 Insert 18333fig0307.png
-Figure 3-7. The branch that HEAD points to moves forward with each commit.
+Hình 3-7. Nhánh mà HEAD trỏ tới di chuyển tiến lên phía trước theo từng commit.
 
-This is interesting, because now your testing branch has moved forward, but your `master` branch still points to the commit you were on when you ran `git checkout` to switch branches. Let’s switch back to the `master` branch:
+Điều này thật thú vị, bởi vì nhánh testing của bạn bây giờ đã tiển hẳn lên phía trước, nhưng nhánh `master` thì vẫn trỏ tới commit ở thời điểm khi bạn chạy lệnh `git checkout` để chuyển nhánh. Hãy cùng chuyển trở lại nhánh `master`:
 
 	$ git checkout master
 
-Figure 3-8 shows the result.
+Hình 3-8 hiển thị kết quả.
 
 Insert 18333fig0308.png
-Figure 3-8. HEAD moves to another branch on a checkout.
+Hình 3-8. HEAD chuyển sang nhánh khác khi checkout.
 
-That command did two things. It moved the HEAD pointer back to point to the `master` branch, and it reverted the files in your working directory back to the snapshot that `master` points to. This also means the changes you make from this point forward will diverge from an older version of the project. It essentially rewinds the work you’ve done in your testing branch temporarily so you can go in a different direction.
+Lệnh này vừa thực hiện hai việc. Nó di chuyển lại con trỏ về nhánh `master`, và sau đó nó phục hồi lại các tập tin trong thư mục làm việc của bạn trở lại snapshot mà `master` trỏ tới. Điều này cũng có nghĩa là các thay đổi bạn thực hiện từ thời điểm này trở đi sẽ tách ra so với phiên bản cũ hơn của dự án. Nó "tua lại" các thay đổi cần thiết mà bạn đã thực hiện trên nhánh `testing` một cách tạm thời để bạn có thể đi theo một hướng khác.
 
-Let’s make a few changes and commit again:
+Hãy cùng tạo một vài thay đổi và commit lại một lần nữa:
 
 	$ vim test.rb
 	$ git commit -a -m 'made other changes'
 
-Now your project history has diverged (see Figure 3-9). You created and switched to a branch, did some work on it, and then switched back to your main branch and did other work. Both of those changes are isolated in separate branches: you can switch back and forth between the branches and merge them together when you’re ready. And you did all that with simple `branch` and `checkout` commands.
+Bây giờ lịch sử của dự án đã bị tách ra (xem Hình 3-9). Bạn tạo mới và chuyển sang một nhánh, thực hiện một số thay đổi trên đó, và rồi chuyển ngược lại nhánh chính và tạo thêm các thay đổi khác. Cả hai sự thay đổi này bị cô lập với nhau ở hai nhánh riêng biệt: bạn có thể chuyển đi hoặc lại giữa cách nhánh và tích hợp chúng lại với nhau khi cần thiết. Và bạn đã thực hiện những việc trên một cách đơn giản với lệnh `branch` và `checkout`.
 
 Insert 18333fig0309.png
-Figure 3-9. The branch histories have diverged.
+Hình 3-9. Lịch sử các nhánh đã bị phân tách.
 
-Because a branch in Git is in actuality a simple file that contains the 40 character SHA-1 checksum of the commit it points to, branches are cheap to create and destroy. Creating a new branch is as quick and simple as writing 41 bytes to a file (40 characters and a newline).
+Bởi vì một nhánh trong Git thực tế là một tập tin đơn giản chứa một mã băm SHA-1 có độ dài 40 ký tự của commit mà nó trỏ tới, chính vì thế tạo mới cũng như hủy các nhánh đi rất đơn giản. Tạo mới một nhánh nhanh tương đương với việc ghi 41 bytes vào một tập tin (40 ký tự cộng thêm một dòng mới).
 
-This is in sharp contrast to the way most VCS tools branch, which involves copying all of the project’s files into a second directory. This can take several seconds or even minutes, depending on the size of the project, whereas in Git the process is always instantaneous. Also, because we’re recording the parents when we commit, finding a proper merge base for merging is automatically done for us and is generally very easy to do. These features help encourage developers to create and use branches often.
+Điều này đối lập rất lớn với cách mà các VCS khác phân nhánh, chính là copy toàn bộ các tập tin hiện có của dự án sang một thư mục thứ hai. Việc này có thể mất khoảng vài giây, thậm chí vài phút, phụ thuộc vào dung lượng của dự án, trong khi đó trong Git thì quá trình này luôn xảy ra ngay lập tức. Thêm một lý do nữa là, chúng ta đang lưu trữ cha của các commit, nên việc tìm kiếm gốc/cơ sở để tích hợp lại được thực hiện một cách tự động và rất dễ dàng. Những tính năng này giúp khuyến khích các lập trình viên tạo và sử dụng nhánh thường xuyên hơn.
 
-Let’s see why you should do so.
+Hãy cùng xem tại sao bạn nên làm như vậy.
 
-## Basic Branching and Merging ##
+## Cơ Bản Về Phân Nhánh và Tích Hợp ##
 
-Let’s go through a simple example of branching and merging with a workflow that you might use in the real world. You’ll follow these steps:
+Hãy cùng xem qua một ví dụ đơn giản về phân nhánh và tích hợp với một quy trình làm việc mà có thể bạn sẽ sử dụng nó vào thực tế. Bạn sẽ thực hiện theo các bước sau: 
 
-1. Do work on a web site.
-2. Create a branch for a new story you’re working on.
-3. Do some work in that branch.
+1. Làm việc trên một web site
+2. Tạo nhánh cho một câu chuyện mới mà bạn đang làm.
+3. Làm việc trên nhánh đó.
 
-At this stage, you’ll receive a call that another issue is critical and you need a hotfix. You’ll do the following:
+Đến lúc này, bạn nhận được thông báo rằng có một vấn đề nghiêm trọng cần được khắc phục ngay. Bạn sẽ làm theo các bước sau:
 
-1. Revert back to your production branch.
-2. Create a branch to add the hotfix.
-3. After it’s tested, merge the hotfix branch, and push to production.
-4. Switch back to your original story and continue working.
+1. Chuyển lại về nhánh sản xuất (production)
+2. Tạo mới một nhánh khác để khắc phục lỗi
+3. Sau khi đã kiểm tra ổn định, tích hợp nhánh đó lại và đưa vào hoạt động.
+4. Chuyển ngược lại với câu chuyện của bạn và tiếp tục làm việc.
 
-### Basic Branching ###
+### Cơ Bản về Phân Nhánh ###
 
-First, let’s say you’re working on your project and have a couple of commits already (see Figure 3-10).
+Đầu tiên, giả sử bạn đang làm việc trên một dự án đã có một số commit từ trước (xem Hình 3-10).
 
 Insert 18333fig0310.png
-Figure 3-10. A short and simple commit history.
+Hình 3-10. Một lịch sử commit ngắn và đơn giản.
 
-You’ve decided that you’re going to work on issue #53 in whatever issue-tracking system your company uses. To be clear, Git isn’t tied into any particular issue-tracking system; but because issue #53 is a focused topic that you want to work on, you’ll create a new branch in which to work. To create a branch and switch to it at the same time, you can run the `git checkout` command with the `-b` switch:
+Bạn quyết định sẽ giải quyết vấn đề số #53 sử dụng bất kỳ hệ thống giám sát vấn đề (issue-tracking) nào mà công ty bạn đang dùng. Để cho rõ ràng, Git không cung cấp kèm bất kỳ hệ thống giám sát vấn đề nào; nhưng bởi vì vấn đề số #53 là cái mà bạn sẽ tập trung vào nên bạn sẽ tạo một nhánh mới để làm việc trên đó. Để tạo một nhánh và chuyển sang nhánh đó đồng thời, bạn có thể chạy lệnh `git checkout` với tham số `-b`:
 
 	$ git checkout -b iss53
 	Switched to a new branch "iss53"
 
-This is shorthand for:
+Đây là cách sử dụng vắn tắt của:
 
 	$ git branch iss53
 	$ git checkout iss53
 
-Figure 3-11 illustrates the result.
+Hình 3-11 minh họa kết quả.
 
 Insert 18333fig0311.png
-Figure 3-11. Creating a new branch pointer.
+Hình 3-11. Tạo con trỏ nhánh mới.
 
-You work on your web site and do some commits. Doing so moves the `iss53` branch forward, because you have it checked out (that is, your HEAD is pointing to it; see Figure 3-12):
+Bạn làm việc trên đó và sau đó thực hiện một số commit. Làm như vậy sẽ khiến nhánh `iss53` di chuyển tiến lên, vì bạn đã checkout nó (hay, HEAD đang trỏ đến nó; xem Hình 3-12):
 
 	$ vim index.html
 	$ git commit -a -m 'added a new footer [issue 53]'
 
 Insert 18333fig0312.png
-Figure 3-12. The iss53 branch has moved forward with your work.
+Hình 3-12. Nhánh iss53 đã di chuyển tiến lên cùng với thay đổi của bạn.
 
-Now you get the call that there is an issue with the web site, and you need to fix it immediately. With Git, you don’t have to deploy your fix along with the `iss53` changes you’ve made, and you don’t have to put a lot of effort into reverting those changes before you can work on applying your fix to what is in production. All you have to do is switch back to your master branch.
+Bây giờ bạn nhận được thông báo rằng có một vấn đề với trang web, và bạn cần khắc phục nó ngay lập tức. Với Git, bạn không phải triển khai bản vá lỗi cùng với các thay đổi bạn đã thực hiện trên nhánh `iss53`, và bạn không phải tốn quá nhiều công sức để khôi phục lại các thay đổi đó trước khi áp dụng bản vá vào sản xuất. Tất cả những gì bạn cần phải làm là chuyển lại nhánh master.
 
-However, before you do that, note that if your working directory or staging area has uncommitted changes that conflict with the branch you’re checking out, Git won’t let you switch branches. It’s best to have a clean working state when you switch branches. There are ways to get around this (namely, stashing and commit amending) that we’ll cover later. For now, you’ve committed all your changes, so you can switch back to your master branch:
+Tuy nhiên, trước khi làm điều này, bạn nên lưu ý rằng nếu thư mục làm việc hoặc khu vực tổ chức có chứa các thay đổi chưa được commit mà xung đột với nhánh bạn đang làm việc, Git sẽ không cho phép bạn chuyển nhánh. Tốt nhất là bạn nên ở trạng thái làm việc "sạch" (đã commit hết) trước khi chuyển nhánh. Có các cách khác để khắc phục vấn đề này (đó là stashing và sửa commit) mà chúng ta sẽ bàn tới sau. Hiện tại, bạn đã commit hết các thay đổi, vì vậy bạn có thể chuyển lại nhánh master:
 
 	$ git checkout master
 	Switched to branch "master"
 
-At this point, your project working directory is exactly the way it was before you started working on issue #53, and you can concentrate on your hotfix. This is an important point to remember: Git resets your working directory to look like the snapshot of the commit that the branch you check out points to. It adds, removes, and modifies files automatically to make sure your working copy is what the branch looked like on your last commit to it.
+Tại thời điểm này, thư mục làm việc của dự án giống hệt như trước khi bạn bắt đầu giải quyết vấn đề #53, và bạn có thể tập trung vào việc sửa lỗi. Điểm quan trọng cần ghi nhớ: Git khôi phục lại thư mục làm việc của bạn để nó giống như snapshot của commit mà nhánh bạn đang làm việc trỏ tới. Nó thêm, xóa, và sửa các tập tin một cách tự động để đảm bảo rằng thư mục làm việc của bạn giống như lần commit cuối cùng.
 
-Next, you have a hotfix to make. Let’s create a hotfix branch on which to work until it’s completed (see Figure 3-13):
+Tiếp theo, bạn có mỗi lỗi cần phải sửa. Hãy tạo mỗi nhánh để làm việc này cho tới khi nó được hoàn thành (xem Hình 3-13):
 
 	$ git checkout -b hotfix
 	Switched to a new branch "hotfix"
@@ -156,9 +156,9 @@ Next, you have a hotfix to make. Let’s create a hotfix branch on which to work
 	 1 files changed, 0 insertions(+), 1 deletions(-)
 
 Insert 18333fig0313.png
-Figure 3-13. hotfix branch based back at your master branch point.
+Hình 3-13. Nhánh hotfix dựa trên nhánh master.
 
-You can run your tests, make sure the hotfix is what you want, and merge it back into your master branch to deploy to production. You do this with the `git merge` command:
+Bạn có thể chạy để kiểm tra, để chắc chắn rằng bản vá lỗi hoạt động đúng theo ý bạn muốn, và sau đó tích hợp nó lại nhánh chính để triển khai. Bạn có thể làm sử dụng lệnh `git merge` để làm việc này:
 
 	$ git checkout master
 	$ git merge hotfix
@@ -167,19 +167,19 @@ You can run your tests, make sure the hotfix is what you want, and merge it back
 	 README |    1 -
 	 1 files changed, 0 insertions(+), 1 deletions(-)
 
-You’ll notice the phrase "Fast forward" in that merge. Because the commit pointed to by the branch you merged in was directly upstream of the commit you’re on, Git moves the pointer forward. To phrase that another way, when you try to merge one commit with a commit that can be reached by following the first commit’s history, Git simplifies things by moving the pointer forward because there is no divergent work to merge together — this is called a "fast forward".
+Bạn sẽ nhận thấy rằng cụm từ "Fast forward" trong lần tích hợp đó. Bởi vì commit được trở tới bởi nhánh mà bạn tích hợp vào lại trực tiếp là upstream của commit hiện tại, vì vậy Git di chuyển con trỏ về phía trước. Nói cách khác, khi bạn cố gắng tích hợp một commit với một commit khác mà có thể truy cập được từ lịch sử của commit trước thì Git sẽ đơn giản hóa bằng cách di chuyển con trỏ về phía trước vì không có sự rẽ nhánh nào để tích hợp - đây được gọi là "fast forward".
 
-Your change is now in the snapshot of the commit pointed to by the `master` branch, and you can deploy your change (see Figure 3-14).
+Thay đổi của bạn bây giờ ở trong snapshot của commit được trỏ tới bởi nhánh `master`, và bạn có thể triển khai thay đổi này (xem Hình 3-14).
 
 Insert 18333fig0314.png
-Figure 3-14. Your master branch points to the same place as your hotfix branch after the merge.
+Hình 3-14. Nhánh master và nhánh hotfix cùng trỏ tới một điểm sau khi tích hợp.
 
-After your super-important fix is deployed, you’re ready to switch back to the work you were doing before you were interrupted. However, first you’ll delete the `hotfix` branch, because you no longer need it — the `master` branch points at the same place. You can delete it with the `-d` option to `git branch`:
+Sau khi triển khai xong bản vá lỗi quan trọng đó, bạn đã sẵn sàng để quay lại với công việc bị gián đoạn trước đó. Tuy nhiên, việc đầu tiên cần làm là xóa nhánh `hotfix` đi, vì bạn không còn cần tới nó nữa - nhánh `master` trỏ tới cùng một điểm. Bạn có thể xóa nó đi bằng cách sử dụng tham số `-d` cho lệnh `git branch`:
 
 	$ git branch -d hotfix
 	Deleted branch hotfix (3a0874c).
 
-Now you can switch back to your work-in-progress branch on issue #53 and continue working on it (see Figure 3-15):
+Bây giờ bạn đã có thể chuyển lại nhánh mà bạn đang làm việc trước đó về vấn đề #53 và tiếp tục làm việc (xem Hình 3-15):
 
 	$ git checkout iss53
 	Switched to branch "iss53"
@@ -189,13 +189,13 @@ Now you can switch back to your work-in-progress branch on issue #53 and continu
 	 1 files changed, 1 insertions(+), 0 deletions(-)
 
 Insert 18333fig0315.png
-Figure 3-15. Your iss53 branch can move forward independently.
+Hình 3-15. Nhánh iss53 có thể di chuyển về phía trước một cách độc lập.
 
-It’s worth noting here that the work you did in your `hotfix` branch is not contained in the files in your `iss53` branch. If you need to pull it in, you can merge your `master` branch into your `iss53` branch by running `git merge master`, or you can wait to integrate those changes until you decide to pull the `iss53` branch back into `master` later.
+Điều đáng chú ý ở đây là những công việc bạn đã thực hiện ở nhánh `hotfix` không bao gồm trong nhánh `iss53`. Nếu bạn muốn đưa chúng vào, bạn có thể tích hợp nhánh `master` vào nhánh `iss53` bằng cách chạy lệnh `git merge master`, hoặc bạn có thể chờ đợi đến khi bạn quyết định tích hợp nhánh `iss53` ngược trở lại nhánh `master` về sau.
 
-### Basic Merging ###
+### Cơ Bản Về Tích Hợp ###
 
-Suppose you’ve decided that your issue #53 work is complete and ready to be merged into your `master` branch. In order to do that, you’ll merge in your `iss53` branch, much like you merged in your `hotfix` branch earlier. All you have to do is check out the branch you wish to merge into and then run the `git merge` command:
+Giả sử bạn đã quyết định việc giải quyết vấn đề #53 đã hoàn thành và sẵn sàng để tích hợp vào nhánh `master`. Để làm được điều này, bạn sẽ tích hợp nhánh `iss53` lại, giống như bạn đã làm với nhánh `hotfix` trước đó. Tất cả những gì cần phải làm là chuyển sang (check out) nhánh mà bạn muốn được tích hợp vào và chạy lệnh `git merge`:
 
 	$ git checkout master
 	$ git merge iss53
@@ -203,32 +203,32 @@ Suppose you’ve decided that your issue #53 work is complete and ready to be me
 	 README |    1 +
 	 1 files changed, 1 insertions(+), 0 deletions(-)
 
-This looks a bit different than the `hotfix` merge you did earlier. In this case, your development history has diverged from some older point. Because the commit on the branch you’re on isn’t a direct ancestor of the branch you’re merging in, Git has to do some work. In this case, Git does a simple three-way merge, using the two snapshots pointed to by the branch tips and the common ancestor of the two. Figure 3-16 highlights the three snapshots that Git uses to do its merge in this case.
+Lần này có hơi khác so với lần tích hợp `hotfix` trước đó. Trong trường hợp này, lịch sử phát triển của bạn đã bị phân nhánh tại một thời điểm nào đó trước kia. Bởi vì commit trên nhánh mà bạn đang làm việc (master) không phải là "cha" trực tiếp của nhánh mà bạn đang tích hợp vào, Git phải làm một số việc. Trường hợp này, Git thực hiện một tích hợp 3-chiều, sử dụng hai snapshot được trỏ tới bởi các đầu mút của nhánh và "cha chung" của cả hai. Hình 3-16 minh họa ba snapshot mà Git sử dụng để thực hiện phép tích hợp trong trường hợp này.
 
 Insert 18333fig0316.png
-Figure 3-16. Git automatically identifies the best common-ancestor merge base for branch merging.
+Hình 3-16. Git tự động nhận dạng "cha chung" phù hợp nhất để tích hợp các nhánh lại với nhau.
 
-Instead of just moving the branch pointer forward, Git creates a new snapshot that results from this three-way merge and automatically creates a new commit that points to it (see Figure 3-17). This is referred to as a merge commit and is special in that it has more than one parent.
+Thay vì việc chỉ di chuyển con trỏ về phía trước, Git tạo một snapshot mới - được hợp thành từ lần tích hợp 3-chiều này và cũng tự tạo một commit mới trỏ tới nó (xem Hình 3-17). Nó được biết tới như là "commit tích hợp" (merge commit) và nó đặc biệt vì có nhiều hơn một cha.
 
-It’s worth pointing out that Git determines the best common ancestor to use for its merge base; this is different than CVS or Subversion (before version 1.5), where the developer doing the merge has to figure out the best merge base for themselves. This makes merging a heck of a lot easier in Git than in these other systems.
+Đáng để chỉ ra rằng Git tự quyết định cha chung phù hợp nhất để sử dụng làm cơ sở cho việc tích hợp; điểm này khác với CVS hay Subversion (các phiên bản trước 1.5), khi mà các lập trình viên phải tự xác định cơ sở phù hợp nhất để tích hợp. Điều này khiến cho việc tích hợp trong Git trở nên dễ dàng hơn rất nhiều so với các hệ quản trị phiên bản khác.
 
 Insert 18333fig0317.png
-Figure 3-17. Git automatically creates a new commit object that contains the merged work.
+Hình 3-17. Git tự động tạo đối tượng commit mới chứa đựng các thay đổi đã tích hợp.
 
-Now that your work is merged in, you have no further need for the `iss53` branch. You can delete it and then manually close the ticket in your ticket-tracking system:
+Bây giờ công việc của bạn đã được tích hợp lại với nhau, bạn không cần thiết phải giữ lại nhánh `iss53` nữa. Bạn có thể xóa nó đi và sau đó tự xóa vấn đề này trong hệ thống quản lý vấn đề của bạn:
 
 	$ git branch -d iss53
 
-### Basic Merge Conflicts ###
+### Mâu Thuẫn Khi Tích Hợp ###
 
-Occasionally, this process doesn’t go smoothly. If you changed the same part of the same file differently in the two branches you’re merging together, Git won’t be able to merge them cleanly. If your fix for issue #53 modified the same part of a file as the `hotfix`, you’ll get a merge conflict that looks something like this:
+Đôi khi, quá trình này không diễn ra một cách suôn sẻ. Nếu bạn thay đổi cùng một nội dung của cùng một tập tin ở hai nhánh khác nhau mà bạn đang muốn tích hợp vào, Git không thể tích hợp chúng một cách gọn gàng. Nếu bản vá lỗi cho vấn đề #53 cùng thay đổi một phần của một tập tin giống như nhánh `hotfix`, bạn sẽ nhận được một sự xung đột khi tiến hành tích hợp như sau:
 
 	$ git merge iss53
 	Auto-merging index.html
 	CONFLICT (content): Merge conflict in index.html
 	Automatic merge failed; fix conflicts and then commit the result.
 
-Git hasn’t automatically created a new merge commit. It has paused the process while you resolve the conflict. If you want to see which files are unmerged at any point after a merge conflict, you can run `git status`:
+Git chưa tự tạo commit tích hợp mới. Nó tạm dừng quá trình này lại cho đến khi bạn giải quyết xong xung đột. Nếu bạn muốn xem tập tin nào chưa được tích hợp tại bất kỳ thời điểm nào sau khi xung đột xảy ra, bạn có thể sử dụng lệnh `git status`:
 
 	[master*]$ git status
 	index.html: needs merge
@@ -240,7 +240,7 @@ Git hasn’t automatically created a new merge commit. It has paused the process
 	#	unmerged:   index.html
 	#
 
-Anything that has merge conflicts and hasn’t been resolved is listed as unmerged. Git adds standard conflict-resolution markers to the files that have conflicts, so you can open them manually and resolve those conflicts. Your file contains a section that looks something like this:
+Với bất kỳ xung đột nào xảy ra mà chưa được giải quyết, chúng sẽ được liệt kê là unmerged (chưa được tích hợp). Git thêm các dấu hiệu chuẩn riêng để giải quyết xung đột vào các tập tin có xảy ra xung đột, vì thế bạn có thể mở và giải quyết các xung đột đó một cách thủ công. Tập tin của bạn sẽ chứa một phần tương tự như sau:
 
 	<<<<<<< HEAD:index.html
 	<div id="footer">contact : email.support@github.com</div>
@@ -250,14 +250,13 @@ Anything that has merge conflicts and hasn’t been resolved is listed as unmerg
 	</div>
 	>>>>>>> iss53:index.html
 
-This means the version in HEAD (your master branch, because that was what you had checked out when you ran your merge command) is the top part of that block (everything above the `=======`), while the version in your `iss53` branch looks like everything in the bottom part. In order to resolve the conflict, you have to either choose one side or the other or merge the contents yourself. For instance, you might resolve this conflict by replacing the entire block with this:
+Điều này có nghĩa là phiên bản trong HEAD (nhánh master, vì nó là nhánh bạn đã check out khi chạy lệnh merge) là phần mới nhất của đoạn đó (mọi thứ phía trên `=======`), trong khi phiên bản ở nhánh `iss53` chính là phần phía dưới. Để giải quyết vấn đề này, bạn phải chọn một trong hai phần hoặc tự gộp nội dung của chúng lại. Ví dụ, có thể bạn giải quyết xung đột này bằng cách thay thế toàn bộ đoạn code đó bằng:
 
 	<div id="footer">
 	please contact us at email.support@github.com
 	</div>
 
-This resolution has a little of each section, and I’ve fully removed the `<<<<<<<`, `=======`, and `>>>>>>>` lines. After you’ve resolved each of these sections in each conflicted file, run `git add` on each file to mark it as resolved. Staging the file marks it as resolved in Git.
-If you want to use a graphical tool to resolve these issues, you can run `git mergetool`, which fires up an appropriate visual merge tool and walks you through the conflicts:
+Cách giải quyết này có chứa nội dung của cả hai phần, và tôi đã xóa bỏ hoàn toàn các dòng `<<<<<<<`, `=======`, và `>>>>>>>`. Sau khi giải quyết xong tất cả các phần này trong các tập tin bị xung đột, chạy lệnh `git add` cho từng tập tin để đánh dấu là chúng đã được giải quyết. Tổ chức chúng cùng đồng nghĩa với việc đánh dấu là đã được giải quyết trong Git. Nếu bạn muốn sử dụng một công cụ có giao diện đồ họa để giải quyết những vấn đề này, bạn có thể sử dụng `git mergetool`, Git sẽ tự động mở chương trình tương ứng và trợ giúp bạn giải quyết các xung đột: 
 
 	$ git mergetool
 	merge tool candidates: kdiff3 tkdiff xxdiff meld gvimdiff opendiff emerge vimdiff
@@ -268,11 +267,11 @@ If you want to use a graphical tool to resolve these issues, you can run `git me
 	  {remote}: modified
 	Hit return to start merge resolution tool (opendiff):
 
-If you want to use a merge tool other than the default (Git chose `opendiff` for me in this case because I ran the command on a Mac), you can see all the supported tools listed at the top after “merge tool candidates”. Type the name of the tool you’d rather use. In Chapter 7, we’ll discuss how you can change this default value for your environment.
+Nếu bạn muốn sử dụng một công cụ tích hợp khác thay vì chương trình mặc định (Git sử dụng `opendiff` cho tôi trong trường hợp này vì tôi đang sử dụng một máy tính Mac), bạn có thể xem danh sách các chương trình tương thích bằng cách chạy lệnh "merge tool candidates". Gõ tên chương trình bạn muốn sử dung. Trong Chương 7, chúng ta sẽ cùng bàn luận về việc làm thế nào để thay đổi giá trị mặc định này.
 
-After you exit the merge tool, Git asks you if the merge was successful. If you tell the script that it was, it stages the file to mark it as resolved for you.
+Sau khi thoát khỏi chương trình hỗ trợ tích hợp, Git sẽ hỏi bạn nếu tích hợp thành công. Nếu bạn trả lời đúng, nó sẽ đánh dấu tập tin đó là đã giải quyết cho bạn.
 
-You can run `git status` again to verify that all conflicts have been resolved:
+Bạn có thể chạy `git status` lại một lần nữa để xác thực rằng tất cả các xung đột đã được giải quyết:
 
 	$ git status
 	# On branch master
@@ -282,7 +281,7 @@ You can run `git status` again to verify that all conflicts have been resolved:
 	#	modified:   index.html
 	#
 
-If you’re happy with that, and you verify that everything that had conflicts has been staged, you can type `git commit` to finalize the merge commit. The commit message by default looks something like this:
+Nếu bạn hài lòng với điều này, và chắc chắn rằng tất cả các xung đột đã được tổ chức, bạn có thể chạy lệnh `git commit` để hoàn thành commit tích hợp. Thông điệp mặc định của commit có dạng như sau:
 
 	Merge branch 'iss53'
 
@@ -295,66 +294,68 @@ If you’re happy with that, and you verify that everything that had conflicts h
 	# and try again.
 	#
 
-You can modify that message with details about how you resolved the merge if you think it would be helpful to others looking at this merge in the future — why you did what you did, if it’s not obvious.
+Bạn có sửa lại nội dung này với các chi tiết về việc bạn đã giải quyết như thế nào nếu bạn cho rằng các thông tin đó sẽ có ích cho các thành viên khác sau này - tại sao bạn lại làm như vậy, nếu như chúng còn chưa rõ ràng.
 
-## Branch Management ##
+## Quản Lý Các Nhánh ##
 
-Now that you’ve created, merged, and deleted some branches, let’s look at some branch-management tools that will come in handy when you begin using branches all the time.
+Bạn đã tạo mới, tích hợp, và xóa một số nhánh, bây giờ hãy cùng xem một số công cụ giúp việc quản lý nhánh trở nên dễ dàng hơn khi tần suất sử dụng nhánh của bạn ngày càng nhiều.
 
-The `git branch` command does more than just create and delete branches. If you run it with no arguments, you get a simple listing of your current branches:
+Lệnh `git branch` thực hiện nhiều việc hơn là chỉ tạo và xóa nhánh. Nếu bạn chạy nó không có tham số, bạn sẽ có danh sách của tất cả các nhánh hiện tại:
 
 	$ git branch
 	  iss53
 	* master
 	  testing
 
-Notice the `*` character that prefixes the `master` branch: it indicates the branch that you currently have checked out. This means that if you commit at this point, the `master` branch will be moved forward with your new work. To see the last commit on each branch, you can run `git branch -v`:
+Lưu ý về  ký tự `*` đứng trước nhánh `master`: nó chỉ cho bạn thấy nhánh mà bạn đang làm việc (Checkout). Có nghĩa là nếu bạn commit ở thời điểm hiện tại, thì nhánh `master` sẽ di chuyển tiến lên phía trước với các thay đổi mới. Để xem commit mới nhất trên từng nhánh, bạn có thể chạy lệnh `git branch -v`:
 
 	$ git branch -v
 	  iss53   93b412c fix javascript issue
 	* master  7a98805 Merge branch 'iss53'
 	  testing 782fd34 add scott to the author list in the readmes
 
-Another useful option to figure out what state your branches are in is to filter this list to branches that you have or have not yet merged into the branch you’re currently on. There are useful `--merged` and `--no-merged` options available in Git for this purpose. To see which branches are already merged into the branch you’re on, you can run `git branch --merged`:
+Một lựa chọn hữu ích khác để tìm ra trạng thái của các nhánh là lọc qua các nhánh bạn đã hoặc chưa tích hợp vào nhánh hiện tại. Các lựa chọn để sử dụng cho mục đích này gồm `--merged` và `--no-merged`. Để biết nhánh nào đã được tích hợp vào nhánh hiện tại, bạn có thể sử dụng `git branch --merged`:
 
 	$ git branch --merged
 	  iss53
 	* master
 
-Because you already merged in `iss53` earlier, you see it in your list. Branches on this list without the `*` in front of them are generally fine to delete with `git branch -d`; you’ve already incorporated their work into another branch, so you’re not going to lose anything.
+Bởi vì bạn đã tích hợp nhánh `iss53` vào trước đó, bạn sẽ thấy nó ở trong danh sách này. Cách nhánh trong danh sách không có dấu `*` ở phía trước thường an toàn để xóa bằng cách sử dụng `git branch -d`; bạn đã tích hợp các thay đổi trong đó vào một nhánh khác, vì thế bạn sẽ không hề bị mất bất cứ dữ liệu gì.
 
-To see all the branches that contain work you haven’t yet merged in, you can run `git branch --no-merged`:
+Để xem cách nhánh chứa các công việc/thay đổi chưa được tích hợp vào, bạn có thể chạy lệnh `git branch --no-merged`:
 
 	$ git branch --no-merged
 	  testing
 
-This shows your other branch. Because it contains work that isn’t merged in yet, trying to delete it with `git branch -d` will fail:
+Lệnh này lại hiện thị các nhánh khác. Bởi vì chúng bao gồm các công việc mà bạn chưa tích hợp vào, xóa nó đi bằng lệnh `git branch -d` sẽ báo lỗi:
 
 	$ git branch -d testing
 	error: The branch 'testing' is not an ancestor of your current HEAD.
 	If you are sure you want to delete it, run 'git branch -D testing'.
 
-If you really do want to delete the branch and lose that work, you can force it with `-D`, as the helpful message points out.
+Nếu bạn thực sự muốn xóa nó đi và chấp nhận mất các thay đổi, bạn có thể bắt buộc bằng cách sử dụng tham số `-D`, như hướng dẫn trong thông báo trên.
 
-## Branching Workflows ##
+## Quy Trình Làm Việc Phân Nhánh ##
 
-Now that you have the basics of branching and merging down, what can or should you do with them? In this section, we’ll cover some common workflows that this lightweight branching makes possible, so you can decide if you would like to incorporate it into your own development cycle.
+Bây giờ bạn đã có được các kiến thức cơ bản về phân nhánh và tích hợp, vậy bạn có thể hay nên làm gì với chúng. Trong phần này, chúng ta sẽ đề cập tới một số quy trình làm việc phổ biến áp dụng phân nhánh, vì thế bạn có thể tự quyết định có áp dụng chúng vào quy trình làm việc riêng của bạn hay không.
 
-### Long-Running Branches ###
+### Nhánh Lâu Đời ###
 
-Because Git uses a simple three-way merge, merging from one branch into another multiple times over a long period is generally easy to do. This means you can have several branches that are always open and that you use for different stages of your development cycle; you can merge regularly from some of them into others.
+Bởi vì Git sử dụng tích hợp 3 chiều đơn giản, nên tích hợp từ nhánh này vào nhánh khác nhiều lần trong cùng một giai đoạn thường dễ dàng. Có nghĩa là bạn có thể có nhiều nhánh luôn mở và sử dụng chúng cho các giai đoạn phát triển khác nhau; bạn có thể tích hợp từ một số nhánh nào đó vào các nhánh khác một cách thường xuyên.
 
-Many Git developers have a workflow that embraces this approach, such as having only code that is entirely stable in their `master` branch — possibly only code that has been or will be released. They have another parallel branch named develop or next that they work from or use to test stability — it isn’t necessarily always stable, but whenever it gets to a stable state, it can be merged into `master`. It’s used to pull in topic branches (short-lived branches, like your earlier `iss53` branch) when they’re ready, to make sure they pass all the tests and don’t introduce bugs.
+Nhiều lập trình viên Git sử dụng quy trình làm việc dựa theo phương pháp này, chẳng hạn như chỉ chứa mã nguồn ổn định hoàn toàn ở nhánh `master` - hầu như là mã nguồn đã phát hành hoặc chuẩn bị phát hành. Họ có một nhánh song song khác có tên develop hoặc next, nơi mà họ làm việc hoặc sử dụng để kiểm tra độ ổn định - nó không nhất thiết luôn luôn phải ổn định, tuy nhiên mỗi khi nó đạt được trạng thái ổn định, nó sẽ được tích hợp vào nhánh `master`. Chúng được sử dụng với vai trò là các nhánh chủ đề (topic branch) - các nhánh có vòng đời ngắn, giống như nhánh `iss53` trước đó - để đảm bảo chúng qua được các bài kiểm tra và không gây ra lỗi.
 
-In reality, we’re talking about pointers moving up the line of commits you’re making. The stable branches are farther down the line in your commit history, and the bleeding-edge branches are farther up the history (see Figure 3-18).
+Trong thực tế, chúng ta đang nói về các con trỏ di chuyển dọc theo đường thẳng của các commit. Các nhánh ổn định hơn thường ở phía cuối của đường thẳng, còn các nhánh đang phát triển thường ở phía đầu hàng (xem Hình 3-18).
 
 Insert 18333fig0318.png
-Figure 3-18. More stable branches are generally farther down the commit history.
+Hình 3-18. Nhánh ổn định hơn thường ở phía cuối hàng trong lịch sử commit.
 
-It’s generally easier to think about them as work silos, where sets of commits graduate to a more stable silo when they’re fully tested (see Figure 3-19).
+Sẽ dễ hình dung hơn khi nghĩ về chúng như là các xi-lô, nơi mà tập hợp các commit cô đặc dần thành một xi-lô ổn định hơn khi đã được kiểm tra đầy đủ (xem Hình 3-19).
 
 Insert 18333fig0319.png
-Figure 3-19. It may be helpful to think of your branches as silos.
+Hình 3-19. Có lẽ sẽ dễ hiểu hơn khi coi các nhánh là các xi-lô.
+
+Bạn có thể tiếp tục làm theo cách này cho nhiều tầng ổn định khác nhau. Nhiều dự án lớn có nhánh `proposed` hoặc `pu` (proposed updates) được sử dụng cho các nhánh chưa đủ điều kiện để tích hợp vào `next` hoặc `master`. 
 
 You can keep doing this for several levels of stability. Some larger projects also have a `proposed` or `pu` (proposed updates) branch that has integrated branches that may not be ready to go into the `next` or `master` branch. The idea is that your branches are at various levels of stability; when they reach a more stable level, they’re merged into the branch above them.
 Again, having multiple long-running branches isn’t necessary, but it’s often helpful, especially when you’re dealing with very large or complex projects.

From 5216930c5201b35464f704aa7cffb0e6a3ff9e53 Mon Sep 17 00:00:00 2001
From: Tuan Vu <contact@tuanva.co.uk>
Date: Sat, 4 Jan 2014 02:52:56 +0000
Subject: [PATCH 037/690] update chapter 3

---
 vi/03-git-branching/01-chapter3.markdown | 34 ++++++++++++------------
 1 file changed, 17 insertions(+), 17 deletions(-)

diff --git a/vi/03-git-branching/01-chapter3.markdown b/vi/03-git-branching/01-chapter3.markdown
index 6feadfe84..d8f26deb5 100644
--- a/vi/03-git-branching/01-chapter3.markdown
+++ b/vi/03-git-branching/01-chapter3.markdown
@@ -355,39 +355,39 @@ Sẽ dễ hình dung hơn khi nghĩ về chúng như là các xi-lô, nơi mà t
 Insert 18333fig0319.png
 Hình 3-19. Có lẽ sẽ dễ hiểu hơn khi coi các nhánh là các xi-lô.
 
-Bạn có thể tiếp tục làm theo cách này cho nhiều tầng ổn định khác nhau. Nhiều dự án lớn có nhánh `proposed` hoặc `pu` (proposed updates) được sử dụng cho các nhánh chưa đủ điều kiện để tích hợp vào `next` hoặc `master`. 
+Bạn có thể tiếp tục làm theo cách này cho nhiều tầng ổn định khác nhau. Nhiều dự án lớn có nhánh `proposed` hoặc `pu` (proposed updates) được sử dụng cho các nhánh chưa đủ điều kiện để tích hợp vào `next` hoặc `master`. Ý tưởng ở đây là, các nhánh ở các tầng khác nhau của sự ổn định; khi chúng đạt tới một mức ổn định hơn nào đó, chúng sẽ được tích hợp vào tầng trên nó. 
+Tóm lại, có nhiều nhánh tồn lại lâu dài không thật sự cần thiết, nhưng nó thường rất hữu ích, đặc biệt là khi bạn làm việc với các dự án lớn và phức tạp.
 
-You can keep doing this for several levels of stability. Some larger projects also have a `proposed` or `pu` (proposed updates) branch that has integrated branches that may not be ready to go into the `next` or `master` branch. The idea is that your branches are at various levels of stability; when they reach a more stable level, they’re merged into the branch above them.
-Again, having multiple long-running branches isn’t necessary, but it’s often helpful, especially when you’re dealing with very large or complex projects.
+### Nhánh Chủ Đề ###
 
-### Topic Branches ###
+Nhánh chủ đề (topic branches) thì ngược lại, nó lại khá hữu ích cho các dự án ở bất kỳ cỡ nào. Một nhánh chủ đề là nhánh có vòng đời ngắn mà bạn tạo để phát triển một tính năng nào đó hoặc tương tự. Nó giống như một thứ gì đó mà bạn chưa từng làm với một VCS trước đây bởi vì nhìn chung nó đòi hỏi rất nhiều nỗ lực để tạo mới cũng như tích hợp các nhánh lại với nhau.
 
-Topic branches, however, are useful in projects of any size. A topic branch is a short-lived branch that you create and use for a single particular feature or related work. This is something you’ve likely never done with a VCS before because it’s generally too expensive to create and merge branches. But in Git it’s common to create, work on, merge, and delete branches several times a day.
+Như bạn đã thấy trong phần trước với các nhánh `iss53` và `hotfix` bạn đã tạo ra. Bạn thực hiện một số commit trên đó và xóa chúng đi ngay sau khi tính hợp chúng lại với nhánh chính. Kỹ thuật này cho phép bạn chuyển ngữ cảnh một cách nhanh chóng và toàn diện - vì công việc của bạn tách biệt hoàn toàn ở các xi-lô nơi mà tất cả các thay đổi ở nhánh đó chỉ liên quan đến chủ đề đó, điều này khiến cho việc xem xét lại (review) mã nguồn hoặc tương tự trở nên dễ dàng hơn rất nhiều. Bạn có thể giữ các thay đổi ở đó trong bất kỳ khoảng thời gian nào bạn muốn, có thể tính bằng phút, ngày, hoặc tháng, và sau đó tích hợp lại khi chúng đã sẵn sàng, không quan trọng thứ tự chúng được tạo ra hay làm việc.
 
-You saw this in the last section with the `iss53` and `hotfix` branches you created. You did a few commits on them and deleted them directly after merging them into your main branch. This technique allows you to context-switch quickly and completely — because your work is separated into silos where all the changes in that branch have to do with that topic, it’s easier to see what has happened during code review and such. You can keep the changes there for minutes, days, or months, and merge them in when they’re ready, regardless of the order in which they were created or worked on.
-
-Consider an example of doing some work (on `master`), branching off for an issue (`iss91`), working on it for a bit, branching off the second branch to try another way of handling the same thing (`iss91v2`), going back to your master branch and working there for a while, and then branching off there to do some work that you’re not sure is a good idea (`dumbidea` branch). Your commit history will look something like Figure 3-20.
+Hãy cùng xét một ví dụ về thực hiện một số công việc (trên nhánh `master`), tạo nhánh cho một vấn đề cần giải quyết (`iss91`), làm việc trên đó một chút, tạo một nhánh thứ hai cùng giải quyết vấn đề đó nhưng theo một cách khác (`iss91v2`), quay trở lại nhánh `master` và làm việc trong một khoảng thời gian nhất định, sau đó tạo một nhánh khác từ đó cho một ý tưởng mà bạn không chắc chắn là nó có phải là ý hay hay không (nhánh `dumbidea`). Lúc này lịch sử commit của bạn sẽ giống Hình 3-20.
 
 Insert 18333fig0320.png
-Figure 3-20. Your commit history with multiple topic branches.
+Hình 3-20. Lịch sử commit với nhiều nhánh chủ đề.
 
-Now, let’s say you decide you like the second solution to your issue best (`iss91v2`); and you showed the `dumbidea` branch to your coworkers, and it turns out to be genius. You can throw away the original `iss91` branch (losing commits C5 and C6) and merge in the other two. Your history then looks like Figure 3-21.
+Bây giờ, giả sử bạn quyết định lựa chọn cách giải quyết thứ hai (`iss91v2`); và bạn trình bày ý tưởng `dumbidea` cho các đồng nghiệp, điều mà bạn không ngờ tới rằng mọi người lại cho đó là một ý tưởng tuyệt vời. Bạn đã có thể bỏ đi nhánh ban đầu `iss91` (mất commit C5 và C6) và tích hợp hai commit còn lại. Lịch sử của bạn lúc này sẽ giống Hình 3-21.
 
 Insert 18333fig0321.png
-Figure 3-21. Your history after merging in dumbidea and iss91v2.
+Hình 3-21. Lịch sử commit sau khi tích hợp dumbidea và iss91v2.
 
-It’s important to remember when you’re doing all this that these branches are completely local. When you’re branching and merging, everything is being done only in your Git repository — no server communication is happening.
+Ghi nhớ một điều quan trọng là khi bạn làm tất cả những việc này, các nhánh hoàn toàn nằm ở máy nội bộ. Khi bạn phân nhánh và tích hợp, tất cả mọi thứ xảy ra trên kho chứa Git của bạn - không có giao tiếp tới máy chủ nào xảy ra.
 
-## Remote Branches ##
+## Nhánh Từ Xa ##
 
-Remote branches are references to the state of branches on your remote repositories. They’re local branches that you can’t move; they’re moved automatically whenever you do any network communication. Remote branches act as bookmarks to remind you where the branches on your remote repositories were the last time you connected to them.
+Nhánh từ xa là các tham chiếu tới trạng thái của các nhánh trên kho chứa từ xa/trung tâm của bạn. Chúng là các nhánh nội bộ mà bạn không thể di chuyển; chúng chỉ di chuyển một cách tự động mỗi khi bạn thực hiện bất kỳ giao tiếp nào qua mạng lưới. Nhánh từ xa hoạt động như là các bookmark (dấu) để nhắc nhở bạn các nhánh trên kho chứa trung tâm của bạn ở đâu vào lần cuối cùng bạn kết nối tới.
 
-They take the form `(remote)/(branch)`. For instance, if you wanted to see what the `master` branch on your `origin` remote looked like as of the last time you communicated with it, you would check the `origin/master` branch. If you were working on an issue with a partner and they pushed up an `iss53` branch, you might have your own local `iss53` branch; but the branch on the server would point to the commit at `origin/iss53`.
+Chúng có dạng `(remote)/(branch)`. Ví dụ, nếu bạn muốn xem nhánh `master` trên nhánh từ xa `origin` của bạn như thế nào từ lần giao tiếp cuối cùng, bạn sẽ dùng `origin/master`. Nếu bạn đang giải quyết một vấn đề với đối tác và họ đẩy dữ liệu lên nhánh `iss53`, bạn có thể có riêng nhánh `iss53` trên máy nội bộ; nhưng nhánh trên máy chủ sẽ trỏ tới commit tại `origin/iss53`.
 
-This may be a bit confusing, so let’s look at an example. Let’s say you have a Git server on your network at `git.ourcompany.com`. If you clone from this, Git automatically names it `origin` for you, pulls down all its data, creates a pointer to where its `master` branch is, and names it `origin/master` locally; and you can’t move it. Git also gives you your own `master` branch starting at the same place as origin’s `master` branch, so you have something to work from (see Figure 3-22).
+Điều này có thể hơi khó hiểu một chút, vậy hãy cùng xem một ví dụ. Giả sử bạn có một máy chủ Git trên mạng của bạn tại địa chỉ `git.ourcompany.com`. Nếu bạn tạo bản sao từ đây, Git sẽ tự động đặt tên nó là `origin` cho bạn, tải về toàn bộ dữ liệu, tạo một con trỏ tới nhánh `master` và đặt tên nội bộ cho nó là `origin/master`; và bạn không thể di chuyển nó. Git cũng cung cấp cho bạn nhánh `master` riêng, bắt đầu cùng một vị trí với `master` của origin để cho bạn có thể bắt đầu làm việc (xem Hình 3-22).
 
 Insert 18333fig0322.png
-Figure 3-22. A Git clone gives you your own master branch and origin/master pointing to origin’s master branch.
+Hình 3-22. Một bản sao Git cung cấp cho bạn nhánh master riêng và nhánh origin/master trỏ tới nhánh master của origin.
+
+
 
 If you do some work on your local master branch, and, in the meantime, someone else pushes to `git.ourcompany.com` and updates its master branch, then your histories move forward differently. Also, as long as you stay out of contact with your origin server, your `origin/master` pointer doesn’t move (see Figure 3-23).
 

From d8d9ccedb182c85766db235da446a29d68337c8c Mon Sep 17 00:00:00 2001
From: Tuan Vu <contact@tuanva.co.uk>
Date: Sun, 5 Jan 2014 04:11:24 +0000
Subject: [PATCH 038/690] [vi] Finished chapter 3

---
 vi/03-git-branching/01-chapter3.markdown | 143 +++++++++++------------
 1 file changed, 71 insertions(+), 72 deletions(-)

diff --git a/vi/03-git-branching/01-chapter3.markdown b/vi/03-git-branching/01-chapter3.markdown
index d8f26deb5..56fb8f8d0 100644
--- a/vi/03-git-branching/01-chapter3.markdown
+++ b/vi/03-git-branching/01-chapter3.markdown
@@ -387,33 +387,31 @@ Chúng có dạng `(remote)/(branch)`. Ví dụ, nếu bạn muốn xem nhánh `
 Insert 18333fig0322.png
 Hình 3-22. Một bản sao Git cung cấp cho bạn nhánh master riêng và nhánh origin/master trỏ tới nhánh master của origin.
 
-
-
-If you do some work on your local master branch, and, in the meantime, someone else pushes to `git.ourcompany.com` and updates its master branch, then your histories move forward differently. Also, as long as you stay out of contact with your origin server, your `origin/master` pointer doesn’t move (see Figure 3-23).
+Nếu bạn thực hiện một số thay đổi trên nhánh `master` nội bộ, và cùng thời điểm đó, một người nào đó đẩy lên `git.ourcompany.com` và cập nhật nhánh master của nó, thì lịch sử của bạn sẽ di chuyển về phía trước khác đi. Miễn là bạn không kết nối tới máy chủ thì con trỏ `origin/master` sẽ vẫn không đổi (xem Hình 3-23).
 
 Insert 18333fig0323.png
-Figure 3-23. Working locally and having someone push to your remote server makes each history move forward differently.
+Hình 3-23. Làm việc nội bộ và ai đó đẩy lên máy chủ khiến cho lịch sử thay đổi khác biệt nhau.
 
-To synchronize your work, you run a `git fetch origin` command. This command looks up which server origin is (in this case, it’s `git.ourcompany.com`), fetches any data from it that you don’t yet have, and updates your local database, moving your `origin/master` pointer to its new, more up-to-date position (see Figure 3-24).
+Để đồng bộ hóa các thay đổi, bạn chạy lệnh `git fetch origin`. Lệnh này sẽ tìm kiếm máy chủ nào là origin (trong trường hợp này là `git.ourcompany.com`), truy xuất toàn bộ dữ liệu mà bạn chưa có từ đó, và cập nhật cơ sở dữ liệu nội bộ của bạn, di chuyển con trỏ `origin/master` tới vị trí mới được cập nhật (xem Hình 3-24).
 
 Insert 18333fig0324.png
-Figure 3-24. The git fetch command updates your remote references.
+Hình 3-24. Lệnh git fetch cập nhật các tham chiếu từ xa.
 
-To demonstrate having multiple remote servers and what remote branches for those remote projects look like, let’s assume you have another internal Git server that is used only for development by one of your sprint teams. This server is at `git.team1.ourcompany.com`. You can add it as a new remote reference to the project you’re currently working on by running the `git remote add` command as we covered in Chapter 2. Name this remote `teamone`, which will be your shortname for that whole URL (see Figure 3-25).
+Để minh họa cho việc có nhiều máy chủ từ xa và các nhánh từ xa của các dự án thuộc các máy chủ đó, giả sử bạn có một máy chủ Git nội bộ khác sử dụng riêng cho các nhóm "thần tốc". Máy chủ này có địa chỉ là `git.team1.ourcompany.com`. Bạn có thể thêm nó như là một tham chiếu từ xa tới dự án bạn đang làm việc bằng cách chạy lệnh `git remote add` như đã giới thiệu ở Chương 2. Đặt tên cho remote đó là `teamone`, đó sẽ là tên rút gọn thay thế cho địa chỉ đầy đủ kia (xem Hình 3-25).
 
 Insert 18333fig0325.png
-Figure 3-25. Adding another server as a remote.
+Hình 3-25. Thêm một máy chủ từ xa khác.
 
-Now, you can run `git fetch teamone` to fetch everything the remote `teamone` server has that you don’t have yet. Because that server has a subset of the data your `origin` server has right now, Git fetches no data but sets a remote branch called `teamone/master` to point to the commit that `teamone` has as its `master` branch (see Figure 3-26).
+Bây giờ bạn có thể chạy lệnh `git fetch teamone` để truy xất toàn bộ nội dung mà bạn chưa có từ máy chủ `teamone`. Bởi vì máy chủ đó có chứa một tập con dữ liệu từ máy chủ `origin` đang có, Git không truy xuất dữ liệu nào cả mà thiết lập một nhánh từ xa mới là `teamone/master` để trỏ tới commit mà `teamone` đang có như là nhánh `master` (xem Hình 3-26).
 
 Insert 18333fig0326.png
-Figure 3-26. You get a reference to teamone’s master branch position locally.
+Hình 3-26. Bạn sẽ có một tham chiếu tới vị trí nội bộ của nhánh `master` của teamone.
 
-### Pushing ###
+### Đẩy Lên ###
 
-When you want to share a branch with the world, you need to push it up to a remote that you have write access to. Your local branches aren’t automatically synchronized to the remotes you write to — you have to explicitly push the branches you want to share. That way, you can use private branches for work you don’t want to share, and push up only the topic branches you want to collaborate on.
+Khi bạn muốn chia sẻ một nhánh với mọi người, bạn cẩn phải đẩy nó lên một máy chủ mà bạn có quyền ghi trên đó. Nhánh nội bộ của bạn sẽ không tự động thực hiện quá trình đồng bộ hóa - mà bạn phải tự đẩy lên cách nhánh mà bạn muốn chia sẻ. Theo cách này, bạn có thể có các nhánh riêng tư cho những công việc mà bạn không muốn chia sẻ, và chỉ đẩy lên các nhánh chủ đề mà bạn muốn mọi người cùng tham gia đóng góp.
 
-If you have a branch named `serverfix` that you want to work on with others, you can push it up the same way you pushed your first branch. Run `git push (remote) (branch)`:
+Nếu bạn có một nhánh là `serverfix` mà bạn muốn mọi người cùng cộng tác, bạn có thể đẩy nó lên theo cách mà chúng ta đã làm đối với nhánh đầu tiên. Chạy `git push (remote) (branch)`:
 
 	$ git push origin serverfix
 	Counting objects: 20, done.
@@ -423,9 +421,9 @@ If you have a branch named `serverfix` that you want to work on with others, you
 	To git@github.com:schacon/simplegit.git
 	 * [new branch]      serverfix -> serverfix
 
-This is a bit of a shortcut. Git automatically expands the `serverfix` branchname out to `refs/heads/serverfix:refs/heads/serverfix`, which means, “Take my serverfix local branch and push it to update the remote’s serverfix branch.” We’ll go over the `refs/heads/` part in detail in Chapter 9, but you can generally leave it off. You can also do `git push origin serverfix:serverfix`, which does the same thing — it says, “Take my serverfix and make it the remote’s serverfix.” You can use this format to push a local branch into a remote branch that is named differently. If you didn’t want it to be called `serverfix` on the remote, you could instead run `git push origin serverfix:awesomebranch` to push your local `serverfix` branch to the `awesomebranch` branch on the remote project.
+Đây là một cách làm tắt. Git tự động mở rộng nhánh `serverfix` thành `refs/heads/serverfix:refs/heads/serverfix`, có nghĩa là, "Hãy sử dụng nhánh nội bộ serverfix của tôi và đẩy nó lên để cập nhật nhánh serverfix trên máy chủ từ xa." Chúng ta sẽ đi sâu vào phần `refs/heads/` ở Chương 9, nhưng bạn thường có thể bỏ qua nó. Bạn cũng có thể chạy lệnh sau `git push origin serverfix:serverfix`, cách này cũng cho kết quả tương tự - nó có nghĩa là "Hãy sử dụng serverfix của tôi để tạo một serverfix trên máy chủ". Bạn có thể sử dụng định dạng này để đẩy một nhánh nội bộ lên một nhánh từ xa với một tên khác. Nếu bạn không muốn gọi nó là `serverfix` trên máy chủ, bạn có thể chạy lệnh sau `git push origin serverfix:awesomebranch` để đẩy nhánh nội bộ `serverfix` vào nhánh `awesomebranch` trên máy chủ trung tâm. 
 
-The next time one of your collaborators fetches from the server, they will get a reference to where the server’s version of `serverfix` is under the remote branch `origin/serverfix`:
+Lần tới một trong các đồng nghiệp của bạn truy xuất nó từ trên máy chủ, họ sẽ có một tham chiếu tới phiên bản trên máy chủ của `serverfix` dưới tên `origin/serverfix`:
 
 	$ git fetch origin
 	remote: Counting objects: 20, done.
@@ -435,165 +433,166 @@ The next time one of your collaborators fetches from the server, they will get a
 	From git@github.com:schacon/simplegit
 	 * [new branch]      serverfix    -> origin/serverfix
 
-It’s important to note that when you do a fetch that brings down new remote branches, you don’t automatically have local, editable copies of them. In other words, in this case, you don’t have a new `serverfix` branch — you only have an `origin/serverfix` pointer that you can’t modify.
+Điều quan trọng cần chú ý ở đây là khi bạn truy xuất dữ liệu từ máy chủ mà có kèm theo nhánh mới, Git sẽ không tự động tạo phiên bản nội bộ của nhánh đó. Nói cách khác, trong trường hợp này, bạn sẽ không có nhánh `serverfix` mới - bạn chỉ có một con trỏ tới `origin/serverfix` mà bạn không thể chỉnh sửa.
 
-To merge this work into your current working branch, you can run `git merge origin/serverfix`. If you want your own `serverfix` branch that you can work on, you can base it off your remote branch:
+Để tích hợp công việc hiện tại vào nhánh bạn đang làm việc, bạn có thể chạy `git merge origin/serverfix`. Nếu bạn muốn nhánh `serverfix` riêng để có thể làm việc trên đó, bạn có thể tách nó ra khỏi nhánh trung tâm bằng cách:
 
 	$ git checkout -b serverfix origin/serverfix
 	Branch serverfix set up to track remote branch refs/remotes/origin/serverfix.
 	Switched to a new branch "serverfix"
 
-This gives you a local branch that you can work on that starts where `origin/serverfix` is.
+Cách này sẽ tạo cho bạn một nhánh nội bộ mà bạn có thể làm việc, bắt đầu cùng một vị trí với `origin/serverfix`.
 
-### Tracking Branches ###
+### Theo Dõi Các Nhánh ###
 
-Checking out a local branch from a remote branch automatically creates what is called a _tracking branch_. Tracking branches are local branches that have a direct relationship to a remote branch. If you’re on a tracking branch and type `git push`, Git automatically knows which server and branch to push to. Also, running `git pull` while on one of these branches fetches all the remote references and then automatically merges in the corresponding remote branch.
+Check out một nhánh nội bộ từ một nhánh trung tâm tự động tạo ra một _tracking branch_. Tracking branches là các nhánh nội bộ có liên quan trực tiếp với một nhánh trung tâm. Nếu bạn đang ở trên một tracking branch và chạy `git push`, Git tự động biết nó sẽ phải đẩy lên nhánh nào, máy chủ nào. Ngoài ra, chạy `git pull` khi đang ở trên một trong những nhánh này sẽ truy xuất toàn bộ các tham chiếu từ xa và sau đó tự động tích hợp chúng với các nhánh từ xa tương ứng.
 
-When you clone a repository, it generally automatically creates a `master` branch that tracks `origin/master`. That’s why `git push` and `git pull` work out of the box with no other arguments. However, you can set up other tracking branches if you wish — ones that don’t track branches on `origin` and don’t track the `master` branch. The simple case is the example you just saw, running `git checkout -b [branch] [remotename]/[branch]`. If you have Git version 1.6.2 or later, you can also use the `--track` shorthand:
+Khi bạn tạo bản sao của một kho chứa, thông thường Git tự động tạp một nhánh `master` để theo dõi `origin/master`. Đó là lý do tại sao `git push` và `git pull` có thể chạy tốt mà không cần bất kỳ tham số nào. Tuy nhiên, bạn có thể cài đặt các tracking branch khác nếu muốn - các nhánh này không theo dõi nhánh trên `origin` cũng như `master`. Một ví dụ đơn giản giống như bạn vừa thấy: `git checkout -b [branch] [remotename]/[branch]`. Nếu bạn đang sử dụng Git phiên bản 1.6.2 trở lên, bạn có thể sử dụng `--track`:
 
 	$ git checkout --track origin/serverfix
 	Branch serverfix set up to track remote branch refs/remotes/origin/serverfix.
 	Switched to a new branch "serverfix"
 
-To set up a local branch with a different name than the remote branch, you can easily use the first version with a different local branch name:
+Để cài đặt một nhánh nội bộ sử dụng tên khác với tên mặc định trên nhánh trung tâm, bạn có thể dễ dàng sử dụng phiên bản đầu tiên với một tên nội bộ khác:
 
 	$ git checkout -b sf origin/serverfix
 	Branch sf set up to track remote branch refs/remotes/origin/serverfix.
 	Switched to a new branch "sf"
 
-Now, your local branch sf will automatically push to and pull from origin/serverfix.
+Bây giờ, nhánh nội bộ sf sẽ tự động "kéo và đẩy" từ origin/serverfix.
 
-### Deleting Remote Branches ###
+### Xóa Nhánh Trung Tâm ###
 
-Suppose you’re done with a remote branch — say, you and your collaborators are finished with a feature and have merged it into your remote’s `master` branch (or whatever branch your stable codeline is in). You can delete a remote branch using the rather obtuse syntax `git push [remotename] :[branch]`. If you want to delete your `serverfix` branch from the server, you run the following:
+Giả sử bạn và đồng nghiệp đã hoàn thành một chức năng nào đó và đã tích hợp nó vào nhánh `master` trung tâm (hoặc bất kỳ nhánh nào khác sử dụng cho việc lưu trữ các phiên bản ổn định). Bạn có thể xóa một nhánh trung tâm đi sử dụng cú pháp sau `git push [remotename] :[branch]`. Nếu bạn muốn xóa nhánh `serverfix` trên máy chủ, bạn có thể chạy lệnh sau:
 
 	$ git push origin :serverfix
 	To git@github.com:schacon/simplegit.git
 	 - [deleted]         serverfix
 
-Boom. No more branch on your server. You may want to dog-ear this page, because you’ll need that command, and you’ll likely forget the syntax. A way to remember this command is by recalling the `git push [remotename] [localbranch]:[remotebranch]` syntax that we went over a bit earlier. If you leave off the `[localbranch]` portion, then you’re basically saying, “Take nothing on my side and make it be `[remotebranch]`.”
+Vậy là đã xong, nhánh đó đã bị xóa khỏi máy chủ. Có thể bạn muốn đánh dấu trang này lại, vì bạn sẽ cần đến câu lệnh này và có thể bạn sẽ quên cú pháp của nó. Một cách để nhớ lệnh này là xem lại cú pháp chúng ta đã nhắc tới trước đó `git push [remotename] [localbranch]:[remotebranch]`. Nếu bạn bỏ qua phần `[localbranch]`, thì cơ bản bạn đang thực hiện "Không sử dụng gì từ phía nội bộ để tạo nhánh `[remotebranch]`."
 
 ## Rebasing ##
 
-In Git, there are two main ways to integrate changes from one branch into another: the `merge` and the `rebase`. In this section you’ll learn what rebasing is, how to do it, why it’s a pretty amazing tool, and in what cases you won’t want to use it.
+Trong Git, có hai cách chính để tích hợp các thay đổi từ nhánh này vào nhánh khác: đó là `merge` và `rebase`. Trong phần này bạn sẽ được tìm hiểu rebase là gì, sử dụng nó như thế nào, tại sao nó được coi là một công cụ khá tuyệt vời, và trong trường hợp nào thì không nên sử dụng nó.
 
-### The Basic Rebase ###
+### Cơ Bản về Rebase ###
 
-If you go back to an earlier example from the Merge section (see Figure 3-27), you can see that you diverged your work and made commits on two different branches.
+Nếu bạn xem lại ví dụ trước trong phần Tích Hợp (xem Hình 3-27), bạn có thể thấy rằng bạn đã phân nhánh công việc của bạn và thực hiện commit trên hai nhánh khác nhau.
 
 Insert 18333fig0327.png
-Figure 3-27. Your initial diverged commit history.
+Hình 3-17. Lần phân nhánh đầu tiên.
 
-The easiest way to integrate the branches, as we’ve already covered, is the `merge` command. It performs a three-way merge between the two latest branch snapshots (C3 and C4) and the most recent common ancestor of the two (C2), creating a new snapshot (and commit), as shown in Figure 3-28.
+Cách đơn giản nhất để tích hợp các nhánh, như chúng ta đã đề cập từ trước, đó là lệnh `merge`. Nó thực hiện tích hợp 3-chiều giữa hai snapshot mới nhất của hai nhánh (C3 và C4) và cha chung gần nhất của cả hai (C2), tạo mới một snapshot khác (và commit), như trong Hình 3-28.
 
 Insert 18333fig0328.png
-Figure 3-28. Merging a branch to integrate the diverged work history.
+Hình 3-28. Gộp nhánh lại để hợp nhất công việc bị tách ra trước đây.
 
-However, there is another way: you can take the patch of the change that was introduced in C3 and reapply it on top of C4. In Git, this is called _rebasing_. With the `rebase` command, you can take all the changes that were committed on one branch and replay them on another one.
+Tuy nhiên, còn có một cách khác: bạn có thể sử dụng bản vá của thay đổi được đưa ra ở C3 và áp dụng nó lên trên C4. Trong Git, đây được gọi là _rebasing_. Bằng cách sử dụng lệnh `rebase`, bạn có thể sử dụng tất cả các thay đổi được commit ở một nhánh và "chạy lại" (replay) chúng trên một nhánh khác.
 
-In this example, you’d run the following:
+Trong ví dụ này, bạn thực hiện như sau:
 
 	$ git checkout experiment
 	$ git rebase master
 	First, rewinding head to replay your work on top of it...
 	Applying: added staged command
 
-It works by going to the common ancestor of the two branches (the one you’re on and the one you’re rebasing onto), getting the diff introduced by each commit of the branch you’re on, saving those diffs to temporary files, resetting the current branch to the same commit as the branch you are rebasing onto, and finally applying each change in turn. Figure 3-29 illustrates this process.
+Nó thực hiện bằng cách đi tới commit cha chung của hai nhánh (nhánh bạn đang làm việc và nhánh bạn đang muốn rebase), tìm sự khác biệt trong mỗi commit của nhánh mà bạn đang làm việc, lưu lại các thay đổi đó vào một tập tin tạm thời, khôi phục lại nhánh hiện tại về cùng một commit với nhánh bạn đang rebase, và cuối cùng áp dụng lần lượt các thay đổi. Hình 3-29 minh họa toàn bộ quá trình này.
 
 Insert 18333fig0329.png
-Figure 3-29. Rebasing the change introduced in C3 onto C4.
+Hình 3-29. Quá trình rebase thay đổi ở C3 vào C4.
 
-At this point, you can go back to the master branch and do a fast-forward merge (see Figure 3-30).
+Đến lúc này, bạn có thể quay lại nhánh `master` và thực hiện fast-forward merge (xem Hình 3-30).
 
 Insert 18333fig0330.png
-Figure 3-30. Fast-forwarding the master branch.
+Hình 3-30. Di chuyển nhánh master lên phía trước.
+
+Bây giờ snapshot mà C3 trỏ tới cũng giống như snapshot được trở tới bởi C5 trong ví dụ sử dụng merge. Không có sự khác biệt nào khi so sánh kết quả của hai phương pháp này, nhưng sử dụng rebase sẽ cho chúng ta lịch sử rõ ràng hơn. Nếu bạn xem xét lịch sử của nhánh mà chúng ta rebase vào, nó giống như một đường thẳng: mọi thứ dường như xảy ra theo trình tự, thậm chí ban đầu nó diễn ra song song.
 
-Now, the snapshot pointed to by C3' is exactly the same as the one that was pointed to by C5 in the merge example. There is no difference in the end product of the integration, but rebasing makes for a cleaner history. If you examine the log of a rebased branch, it looks like a linear history: it appears that all the work happened in series, even when it originally happened in parallel.
 
-Often, you’ll do this to make sure your commits apply cleanly on a remote branch — perhaps in a project to which you’re trying to contribute but that you don’t maintain. In this case, you’d do your work in a branch and then rebase your work onto `origin/master` when you were ready to submit your patches to the main project. That way, the maintainer doesn’t have to do any integration work — just a fast-forward or a clean apply.
+Bình thường, bạn sử dụng cách này để đảm bảo rằng các commit được áp dụng một cách rõ ràng, rành mạch trên nhánh remote - có lẽ là một dự án mà bạn đang đóng góp chứ không phải duy trì nó. Trong trường hợp này, bạn thực hiện công việc trên một nhánh và sau đó rebase trở lại nhánh `origin/master` khi đã sẵn sàng. Theo cách này thì người duy trì dự án đó không phải thực hiện việc tích hợp - mà chỉ chi chuyển tiến lên phía trước (fast-forwar) hoặc đơn giản là áp dụng chúng vào.
 
-Note that the snapshot pointed to by the final commit you end up with, whether it’s the last of the rebased commits for a rebase or the final merge commit after a merge, is the same snapshot — it’s only the history that is different. Rebasing replays changes from one line of work onto another in the order they were introduced, whereas merging takes the endpoints and merges them together.
+Lưu ý rằng snapshot được trỏ tới bởi commit cuối cùng, cho dù nó là kết quả của việc rebase hay merge, thì nó vẫn giống nhau - chỉ khác nhau về các bước thực hiện mà thôi. Quá trình rebase được thực hiện bằng cách thực hiện lại các thay đổi từ nhánh này qua nhánh khác theo thứ tự chúng đã được thực hiện, trong khi đó merge lại lấy hai điểm kết thúc và gộp chúng lại với nhau.
 
-### More Interesting Rebases ###
+### Rebase Nâng Cao ###
 
-You can also have your rebase replay on something other than the rebase branch. Take a history like Figure 3-31, for example. You branched a topic branch (`server`) to add some server-side functionality to your project, and made a commit. Then, you branched off that to make the client-side changes (`client`) and committed a few times. Finally, you went back to your server branch and did a few more commits.
+Bạn cũng có thể thực hiện rebase trên một đối tượng khác mà không phải là nhánh rebase. Xem ví dụ Hình 3-31. Bạn tạo một nhánh chủ để (`server`) để thêm một số tính năng server-side vào dự án, và thực hiện một số commit. Sau đó bạn tạo một nhánh khác để thực hiện một số thay đổi cho phía client (`client`) và cũng commit vài lần. Cuối cùng, bạn quay trở lại nhánh server và thực hiện thêm một số commit nữa.
 
 Insert 18333fig0331.png
-Figure 3-31. A history with a topic branch off another topic branch.
+Hình 3-31. Nhánh chủ đề được tạo từ một nhánh chủ đề khác.
 
-Suppose you decide that you want to merge your client-side changes into your mainline for a release, but you want to hold off on the server-side changes until it’s tested further. You can take the changes on client that aren’t on server (C8 and C9) and replay them on your master branch by using the `--onto` option of `git rebase`:
+Giả sử bạn quyết định tích hợp các thay đổi phía client vào nhánh chính cho bản phát hành sắp tới, nhưng bạn vẫn muốn giữ các thay đổi server-side cho đến khi nó được kiểm tra kỹ lưỡng. Bạn có thể lấy các thay đổi ở client mà không có mặt ở server (C8 và C9) sau đó chạy lại (replay) chúng trên nhánh master bằng cách sử dụng lựa chọn `--onto` cho lệnh `git rebase`:
 
 	$ git rebase --onto master server client
 
-This basically says, “Check out the client branch, figure out the patches from the common ancestor of the `client` and `server` branches, and then replay them onto `master`.” It’s a bit complex; but the result, shown in Figure 3-32, is pretty cool.
+Lệnh này cơ bản nói rằng, "Hãy check out nhánh client, tìm ra các bản vá từ commit chung của nhánh `client` và `server`, sau đó thực thi lại vào nhánh `master`." Nó hơi phức tạp một chút nhưng kết quả như Hình 3-32 thì lại rất tuyệt.
 
 Insert 18333fig0332.png
-Figure 3-32. Rebasing a topic branch off another topic branch.
+Hình 3-32. Quá trình rebase nhánh chủ đề khỏi một nhánh chủ đề khác.
 
-Now you can fast-forward your master branch (see Figure 3-33):
+Bây giờ bạn có thể di chuyển con trỏ của nhánh master tiến lên phía trước (xem Hình 3-33):
 
 	$ git checkout master
 	$ git merge client
 
 Insert 18333fig0333.png
-Figure 3-33. Fast-forwarding your master branch to include the client branch changes.
+Hình 3-33. Di chuyển nhánh master lên phía trước để bao gồm các thay đổi của nhánh client.
 
-Let’s say you decide to pull in your server branch as well. You can rebase the server branch onto the master branch without having to check it out first by running `git rebase [basebranch] [topicbranch]` — which checks out the topic branch (in this case, `server`) for you and replays it onto the base branch (`master`):
+Giả sử rằng bạn quyết định kéo về cả nhánh trên máy chủ. Bạn có thể rebase nhánh trên máy chủ đó vào nhánh master mà không phải checkout trước bằng lệnh `git rebase [basebranch] [topicbranch]` - lệnh này sẽ checkout nhánh chủ để (trong trường hợp này là `server`) cho bạn và áp dụng lại các thay đổi vào nhánh cơ sở (base) `master`:
 
 	$ git rebase master server
 
-This replays your `server` work on top of your `master` work, as shown in Figure 3-34.
+Lệnh này sẽ thực hiện lại các thay đổi trên nhánh `server` chèn vào nhánh `master` như trong Hình 3-34.
 
 Insert 18333fig0334.png
-Figure 3-34. Rebasing your server branch on top of your master branch.
+Hình 3-34. Rebase nhánh server chèn lên nhánh master. 
 
-Then, you can fast-forward the base branch (`master`):
+Sau đó bạn có thể di chuyển con trỏ nhánh base (`master`):
 
 	$ git checkout master
 	$ git merge server
 
-You can remove the `client` and `server` branches because all the work is integrated and you don’t need them anymore, leaving your history for this entire process looking like Figure 3-35:
+Bạn có thể xóa nhánh `client` và `server` vì tất cả công việc đã được tích hợp vào master và bạn không cần đến chúng nữa, lịch sử quả toàn bộ quá trình vừa rồi giống như Hình 3-35:
 
 	$ git branch -d client
 	$ git branch -d server
 
 Insert 18333fig0335.png
-Figure 3-35. Final commit history.
+Hình 3-35. Lịch sử commit cuối cùng.
 
-### The Perils of Rebasing ###
+### Rủi Ro của Rebase ###
 
-Ahh, but the bliss of rebasing isn’t without its drawbacks, which can be summed up in a single line:
+Mặc dù rebase rất hữu ích nhưng nó cũng có không ít những mặt hạn chế, điều này có thể tổng kết bằng câu sau đây:
 
-**Do not rebase commits that you have pushed to a public repository.**
+**Không được rebase các commit mà bạn đã đẩy lên một kho chứa công khai.**
 
-If you follow that guideline, you’ll be fine. If you don’t, people will hate you, and you’ll be scorned by friends and family.
+Miễn là bạn làm theo hướng dẫn này, sẽ không có chuyện gì xảy ra. Nếu không, mọi người sẽ ghét bạn, và bạn sẽ bị bạn bè và gia đình coi thường.
 
-When you rebase stuff, you’re abandoning existing commits and creating new ones that are similar but different. If you push commits somewhere and others pull them down and base work on them, and then you rewrite those commits with `git rebase` and push them up again, your collaborators will have to re-merge their work and things will get messy when you try to pull their work back into yours.
+Khi bạn thực hiện rebase, bạn đang bỏ đi các commit đã tồn tại và tái tạo lại các commit mới tương tự nhưng thực ra khác biệt. Nếu bạn đẩy commit ở một nơi nào đó và mọi người kéo xuống máy của họ, sau đó bạn sửa lại các commit đó bằng lệnh `git rebase` và đẩy lên một lần nữa, đồng nghiệp của bạn sẽ phải tích hợp lại công việc của họ và mọi thứ sẽ rối tung lên khi bạn cố gắng kéo các thay đổi của họ ngược lại máy bạn.
 
-Let’s look at an example of how rebasing work that you’ve made public can cause problems. Suppose you clone from a central server and then do some work off that. Your commit history looks like Figure 3-36.
+Hãy cùng xem một ví dụ làm sao việc rebase công khai có thể gây sự cố. Giả sử bạn tạo bản sao từ một máy chủ trung tâm và thực hiện một số thay đổi từ đó. Lịch sử commit của bạn sẽ giống như Hình 3-36.
 
 Insert 18333fig0336.png
-Figure 3-36. Clone a repository, and base some work on it.
+Hình 3-36. Tạo bản sao một kho chứa, và base một số thay đổi vào đó.
 
-Now, someone else does more work that includes a merge, and pushes that work to the central server. You fetch them and merge the new remote branch into your work, making your history look something like Figure 3-37.
+Bây giờ, một người khác thực hiện một số thay đổi khác có kèm theo một lần tích hợp (merge), và đẩy lên máy chủ trung tâm. Bạn truy xuất chúng và tích hợp nhánh trung tâm mới đó vào của bạn, lúc này lịch sử của bạn sẽ giống như Hình 3-37.
 
 Insert 18333fig0337.png
-Figure 3-37. Fetch more commits, and merge them into your work.
+Hình 3-37. Truy xuất thêm các commit và tích hợp lại.
 
-Next, the person who pushed the merged work decides to go back and rebase their work instead; they do a `git push --force` to overwrite the history on the server. You then fetch from that server, bringing down the new commits.
+Tiếp theo, người đã đẩy tích hợp đó quyết định lại và rebase lại những thay đổi của họ; họ thực hiện `git push --force` để ghi đè lịch sử trên máy chủ. Sau đó bạn truy xuất lại dữ liệu từ máy chủ, đưa về các commit mới.
 
 Insert 18333fig0338.png
-Figure 3-38. Someone pushes rebased commits, abandoning commits you’ve based your work on.
+Hình 3-38. Một người nào đó đẩy lên các commit rebase, bỏ đi các commit có chứa thay đổi của bạn.
 
-At this point, you have to merge this work in again, even though you’ve already done so. Rebasing changes the SHA-1 hashes of these commits so to Git they look like new commits, when in fact you already have the C4 work in your history (see Figure 3-39).
+Lúc này, bạn phải tích hợp lại một lần nữa các thay đổi này, mặc dù trước đó bạn đã làm rồi. Quá trình rebase thay đổi mã băm SHA-1 của các commit này vì thế đối với Git chúng giống như các commit mới, mà thực tế thì bạn đã có C4 trong lịch sử của bạn (xem Hình 3-39).
 
 Insert 18333fig0339.png
-Figure 3-39. You merge in the same work again into a new merge commit.
+Hình 3-39. Bạn tích hợp các thay đổi tương tự lại một lần nữa vào một commit tích hợp mới.
 
-You have to merge that work in at some point so you can keep up with the other developer in the future. After you do that, your commit history will contain both the C4 and C4' commits, which have different SHA-1 hashes but introduce the same work and have the same commit message. If you run a `git log` when your history looks like this, you’ll see two commits that have the same author date and message, which will be confusing. Furthermore, if you push this history back up to the server, you’ll reintroduce all those rebased commits to the central server, which can further confuse people.
+Bạn phải tích hợp thay đổi đó để có thể theo kịp với các lập trình viên khác về sau này. Sau khi thực hiện việc này, lịch sử commit của bạn sẽ bao gồm cả hai commit C4 và C4' có mã SHA-1 khác nhau nhưng lại có cùng chung nội dung thay đổi cũng như thông điệp commit. Nếu bạn chạy lệnh `git log` trong trường hợp này bạn sẽ thấy hai commit cùng chung ngày commit và thông điệp, điều này sẽ gây khó hiểu cho bạn. Hơn nữa, nếu bạn đẩy chúng ngược lên máy chủ, bạn sẽ đưa vào một lần nữa tất cả các commit đã rebase đó và sẽ gây khó hiểu cho nhiều người khác nữa.
 
-If you treat rebasing as a way to clean up and work with commits before you push them, and if you only rebase commits that have never been available publicly, then you’ll be fine. If you rebase commits that have already been pushed publicly, and people may have based work on those commits, then you may be in for some frustrating trouble.
+Nếu bạn sử dụng rebase như là cách để dọn dẹp các commit trước khi đẩy chúng lên, và nếu như bạn chỉ rebase commit chưa bao giờ được công khai, thì sẽ không có chuyện gì xảy ra. Nếu bạn rebase các commit đã được công khai và mọi người có thể đã tích hợp (base) nó vào công việc của họ thì bạn có thể gặp phải các vấn đề thực sự khó chị.
 
-## Summary ##
+## Tổng Kết ##
 
-We’ve covered basic branching and merging in Git. You should feel comfortable creating and switching to new branches, switching between branches and merging local branches together.  You should also be able to share your branches by pushing them to a shared server, working with others on shared branches and rebasing your branches before they are shared.
+Chúng ta đã đề cập tới các khái niệm cơ bản về phân nhánh và tích hợp trong Git. Bạn nên nắm vững việc tạo mới, di chuyển giữa các nhánh và tích hợp các nhánh nội bộ lại với nhau. Bạn cũng nên có khả năng chia sẽ các nhánh bằng cách đẩy chúng lên một máy chủ trung tâm, cộng tác với các thành viên khác trên các nhánh dùng chung và rebase chúng trước khi chia sẻ.
\ No newline at end of file

From 7afe5f0b1b0c38cfd3c9ca2514ebb0934bc7942d Mon Sep 17 00:00:00 2001
From: Tuan Vu <contact@tuanva.co.uk>
Date: Sun, 5 Jan 2014 04:17:55 +0000
Subject: [PATCH 039/690] [vi] Fix typo on Chapter 2

---
 vi/02-git-basics/01-chapter2.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/vi/02-git-basics/01-chapter2.markdown b/vi/02-git-basics/01-chapter2.markdown
index 5904099a7..460b5455a 100644
--- a/vi/02-git-basics/01-chapter2.markdown
+++ b/vi/02-git-basics/01-chapter2.markdown
@@ -589,7 +589,7 @@ The lines must be formatted as follows
 
 Có thể bạn băn khoăn về sự khác nhau giữa _tác giả_ (author) và _người commit_ (committer). _Tác giả_ là người đầu tiên viết bản vá (patch), trong khi đó _người commit_ là người cuối cùng áp dụng miếng vá đó. Như vậy, nếu bạn gửi một bản vá cho một dự án và một trong các thành viên chính của dự án "áp dụng" (chấp nhận) bản vá đó, cả hai sẽ cùng được ghi nhận công trạng (credit) - bạn với vai trò là tác giả và thành viên của dự án trong vai trò người commit. Chúng ta sẽ bàn kỹ hơn một chút về sự khác nhau này trong *Chương 5*.
 
-Lựa chọn `oneline` và `formar` đặc biệt hữu ích khi sử dụng với một tham số khác của `log` là `--graph`. Khi sử dụng, tham số này sẽ thêm một biểu đồ sử dụng dựa trên các ký tự ASCII hiển thị nhánh và lịch sử tích hợp các tập tin của bạn, chúng ta có thể thấy trong dự án Grit như sau:
+Lựa chọn `oneline` và `format` đặc biệt hữu ích khi sử dụng với một tham số khác của `log` là `--graph`. Khi sử dụng, tham số này sẽ thêm một biểu đồ sử dụng dựa trên các ký tự ASCII hiển thị nhánh và lịch sử tích hợp các tập tin của bạn, chúng ta có thể thấy trong dự án Grit như sau:
 
 	$ git log --pretty=format:"%h %s" --graph
 	* 2d3acf9 ignore errors from SIGCHLD on trap

From 03b06a90f4c4a3d80f778bc781f8a84fc1909751 Mon Sep 17 00:00:00 2001
From: Tuan Vu <contact@tuanva.co.uk>
Date: Sun, 5 Jan 2014 04:24:40 +0000
Subject: [PATCH 040/690] [vi] made some changes on Chapter 3

---
 vi/03-git-branching/01-chapter3.markdown | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/vi/03-git-branching/01-chapter3.markdown b/vi/03-git-branching/01-chapter3.markdown
index 56fb8f8d0..83d9fd012 100644
--- a/vi/03-git-branching/01-chapter3.markdown
+++ b/vi/03-git-branching/01-chapter3.markdown
@@ -376,11 +376,11 @@ Hình 3-21. Lịch sử commit sau khi tích hợp dumbidea và iss91v2.
 
 Ghi nhớ một điều quan trọng là khi bạn làm tất cả những việc này, các nhánh hoàn toàn nằm ở máy nội bộ. Khi bạn phân nhánh và tích hợp, tất cả mọi thứ xảy ra trên kho chứa Git của bạn - không có giao tiếp tới máy chủ nào xảy ra.
 
-## Nhánh Từ Xa ##
+## Nhánh Remote ##
 
-Nhánh từ xa là các tham chiếu tới trạng thái của các nhánh trên kho chứa từ xa/trung tâm của bạn. Chúng là các nhánh nội bộ mà bạn không thể di chuyển; chúng chỉ di chuyển một cách tự động mỗi khi bạn thực hiện bất kỳ giao tiếp nào qua mạng lưới. Nhánh từ xa hoạt động như là các bookmark (dấu) để nhắc nhở bạn các nhánh trên kho chứa trung tâm của bạn ở đâu vào lần cuối cùng bạn kết nối tới.
+Nhánh từ xa (remote) là các tham chiếu tới trạng thái của các nhánh trên kho chứa trung tâm của bạn. Chúng là các nhánh nội bộ mà bạn không thể di chuyển; chúng chỉ di chuyển một cách tự động mỗi khi bạn thực hiện bất kỳ giao tiếp nào qua mạng lưới. Nhánh remote hoạt động như là các bookmark (dấu) để nhắc nhở bạn các nhánh trên kho chứa trung tâm của bạn ở đâu vào lần cuối cùng bạn kết nối tới.
 
-Chúng có dạng `(remote)/(branch)`. Ví dụ, nếu bạn muốn xem nhánh `master` trên nhánh từ xa `origin` của bạn như thế nào từ lần giao tiếp cuối cùng, bạn sẽ dùng `origin/master`. Nếu bạn đang giải quyết một vấn đề với đối tác và họ đẩy dữ liệu lên nhánh `iss53`, bạn có thể có riêng nhánh `iss53` trên máy nội bộ; nhưng nhánh trên máy chủ sẽ trỏ tới commit tại `origin/iss53`.
+Chúng có dạng `(remote)/(branch)`. Ví dụ, nếu bạn muốn xem nhánh `master` trên nhánh remote `origin` của bạn như thế nào từ lần giao tiếp cuối cùng, bạn sẽ dùng `origin/master`. Nếu bạn đang giải quyết một vấn đề với đối tác và họ đẩy dữ liệu lên nhánh `iss53`, bạn có thể có riêng nhánh `iss53` trên máy nội bộ; nhưng nhánh trên máy chủ sẽ trỏ tới commit tại `origin/iss53`.
 
 Điều này có thể hơi khó hiểu một chút, vậy hãy cùng xem một ví dụ. Giả sử bạn có một máy chủ Git trên mạng của bạn tại địa chỉ `git.ourcompany.com`. Nếu bạn tạo bản sao từ đây, Git sẽ tự động đặt tên nó là `origin` cho bạn, tải về toàn bộ dữ liệu, tạo một con trỏ tới nhánh `master` và đặt tên nội bộ cho nó là `origin/master`; và bạn không thể di chuyển nó. Git cũng cung cấp cho bạn nhánh `master` riêng, bắt đầu cùng một vị trí với `master` của origin để cho bạn có thể bắt đầu làm việc (xem Hình 3-22).
 

From c37a85f782048ff57c85d1c83bede3a06661e4ab Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Jean-No=C3=ABl=20Rouvignac?= <jn.rouvignac@gmail.com>
Date: Sun, 5 Jan 2014 09:17:44 +0100
Subject: [PATCH 041/690] Typo in 8.2 Git and Other Systems - Migrating to Git

"metioned" => "mentioned"
---
 az/08-git-and-other-scms/01-chapter8.markdown    | 2 +-
 de/08-git-and-other-scms/01-chapter8.markdown    | 2 +-
 en/08-git-and-other-scms/01-chapter8.markdown    | 2 +-
 es/08-git-and-other-scms/01-chapter8.markdown    | 2 +-
 no-nb/08-git-and-other-scms/01-chapter8.markdown | 2 +-
 pl/08-git-and-other-scms/01-chapter8.markdown    | 2 +-
 6 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/az/08-git-and-other-scms/01-chapter8.markdown b/az/08-git-and-other-scms/01-chapter8.markdown
index 9aaf5c4e9..2465ffaa5 100644
--- a/az/08-git-and-other-scms/01-chapter8.markdown
+++ b/az/08-git-and-other-scms/01-chapter8.markdown
@@ -602,7 +602,7 @@ The last thing you need to do is to return the current mark so it can be passed
 
 	return mark
 
-NOTE: If you are running on Windows you'll need to make sure that you add one extra step. As metioned before, Windows uses CRLF for new line characters while git fast-import expects only LF. To get around this problem and make git fast-import happy, you need to tell ruby to use LF instead of CRLF:
+NOTE: If you are running on Windows you'll need to make sure that you add one extra step. As mentioned before, Windows uses CRLF for new line characters while git fast-import expects only LF. To get around this problem and make git fast-import happy, you need to tell ruby to use LF instead of CRLF:
 
 	$stdout.binmode
 
diff --git a/de/08-git-and-other-scms/01-chapter8.markdown b/de/08-git-and-other-scms/01-chapter8.markdown
index 757762e12..f183fdd11 100644
--- a/de/08-git-and-other-scms/01-chapter8.markdown
+++ b/de/08-git-and-other-scms/01-chapter8.markdown
@@ -818,7 +818,7 @@ Das letzte, das wir jetzt noch machen müssen, ist, die gegenwärtige Marke zur
 
 	return mark
 
-<!--NOTE: If you are running on Windows you’ll need to make sure that you add one extra step. As metioned before, Windows uses CRLF for new line characters while git fast-import expects only LF. To get around this problem and make git fast-import happy, you need to tell ruby to use LF instead of CRLF:-->
+<!--NOTE: If you are running on Windows you’ll need to make sure that you add one extra step. As mentioned before, Windows uses CRLF for new line characters while git fast-import expects only LF. To get around this problem and make git fast-import happy, you need to tell ruby to use LF instead of CRLF:-->
 
 	$stdout.binmode
 
diff --git a/en/08-git-and-other-scms/01-chapter8.markdown b/en/08-git-and-other-scms/01-chapter8.markdown
index 7fddeda69..4e6671c27 100644
--- a/en/08-git-and-other-scms/01-chapter8.markdown
+++ b/en/08-git-and-other-scms/01-chapter8.markdown
@@ -601,7 +601,7 @@ The last thing you need to do is to return the current mark so it can be passed
 
 	return mark
 
-NOTE: If you are running on Windows you’ll need to make sure that you add one extra step. As metioned before, Windows uses CRLF for new line characters while git fast-import expects only LF. To get around this problem and make git fast-import happy, you need to tell ruby to use LF instead of CRLF:
+NOTE: If you are running on Windows you’ll need to make sure that you add one extra step. As mentioned before, Windows uses CRLF for new line characters while git fast-import expects only LF. To get around this problem and make git fast-import happy, you need to tell ruby to use LF instead of CRLF:
 
 	$stdout.binmode
 
diff --git a/es/08-git-and-other-scms/01-chapter8.markdown b/es/08-git-and-other-scms/01-chapter8.markdown
index 981a56d40..8df7dc775 100644
--- a/es/08-git-and-other-scms/01-chapter8.markdown
+++ b/es/08-git-and-other-scms/01-chapter8.markdown
@@ -598,7 +598,7 @@ The last thing you need to do is to return the current mark so it can be passed
 
 	return mark
 
-NOTE: If you are running on Windows you'll need to make sure that you add one extra step. As metioned before, Windows uses CRLF for new line characters while git fast-import expects only LF. To get around this problem and make git fast-import happy, you need to tell ruby to use LF instead of CRLF:
+NOTE: If you are running on Windows you'll need to make sure that you add one extra step. As mentioned before, Windows uses CRLF for new line characters while git fast-import expects only LF. To get around this problem and make git fast-import happy, you need to tell ruby to use LF instead of CRLF:
 
 	$stdout.binmode
 
diff --git a/no-nb/08-git-and-other-scms/01-chapter8.markdown b/no-nb/08-git-and-other-scms/01-chapter8.markdown
index 9aaf5c4e9..2465ffaa5 100644
--- a/no-nb/08-git-and-other-scms/01-chapter8.markdown
+++ b/no-nb/08-git-and-other-scms/01-chapter8.markdown
@@ -602,7 +602,7 @@ The last thing you need to do is to return the current mark so it can be passed
 
 	return mark
 
-NOTE: If you are running on Windows you'll need to make sure that you add one extra step. As metioned before, Windows uses CRLF for new line characters while git fast-import expects only LF. To get around this problem and make git fast-import happy, you need to tell ruby to use LF instead of CRLF:
+NOTE: If you are running on Windows you'll need to make sure that you add one extra step. As mentioned before, Windows uses CRLF for new line characters while git fast-import expects only LF. To get around this problem and make git fast-import happy, you need to tell ruby to use LF instead of CRLF:
 
 	$stdout.binmode
 
diff --git a/pl/08-git-and-other-scms/01-chapter8.markdown b/pl/08-git-and-other-scms/01-chapter8.markdown
index 90a3dcfc2..19155bca8 100644
--- a/pl/08-git-and-other-scms/01-chapter8.markdown
+++ b/pl/08-git-and-other-scms/01-chapter8.markdown
@@ -843,7 +843,7 @@ Używasz ponownie metody `export_data`, którą zdefiniowałeś wcześniej, poni
 
 UWAGA: Jeżeli pracujesz na systemie Windows, musisz upewnić się, że dodajesz jeszcze jeden krok. Jak wspomniałem wcześniej, system Windows używa znaków CRLF jak znaczników końca linii, a `git fast-import` oczekuje tylko LF. Aby obejść ten problem i uszczęśliwić `git fast-import`, musisz wskazać ruby, aby używał znaków LF zamiast CRLF:
 
-<!-- NOTE: If you are running on Windows you’ll need to make sure that you add one extra step. As metioned before, Windows uses CRLF for new line characters while git fast-import expects only LF. To get around this problem and make git fast-import happy, you need to tell ruby to use LF instead of CRLF: -->
+<!-- NOTE: If you are running on Windows you’ll need to make sure that you add one extra step. As mentioned before, Windows uses CRLF for new line characters while git fast-import expects only LF. To get around this problem and make git fast-import happy, you need to tell ruby to use LF instead of CRLF: -->
 
 	$stdout.binmode
 

From b219ebc84b18c1c44b5671e8c2281824728c138f Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Sun, 5 Jan 2014 13:37:05 +0100
Subject: [PATCH 042/690] Translated "Submodules"

---
 it/06-git-tools/01-chapter6.markdown | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/it/06-git-tools/01-chapter6.markdown b/it/06-git-tools/01-chapter6.markdown
index f83a8e306..2b1831bb9 100644
--- a/it/06-git-tools/01-chapter6.markdown
+++ b/it/06-git-tools/01-chapter6.markdown
@@ -258,4 +258,12 @@ In questo è comune usare il parametro `--left-right` con il comando `log`, che
 	> D
 	> C
 
-Con questi strumenti puoi dire facilmente a Git quale o quali commit vuoi ispezionare.
\ No newline at end of file
+Con questi strumenti puoi dire facilmente a Git quale o quali commit vuoi ispezionare.
+
+## Moduli ##
+
+Capita spesso che, mentre stai lavorando a un progetto, debba includerne un altro. Potrebbe essere una libreria sviluppata da terze parti o che tu stai sviluppando separatamente e lo stai usando in vari super-progetti. In questi casi si pone un problema comune: si vuole essere in grado di trattare i due progetti separatamente ma essere tuttavia in grado di utilizzarne uno all'interno dell'altro.
+
+Vediamo un esempio. Immagina di stare sviluppando un sito web creando dei feed Atom e, invece di scrivere da zero il codice per generare il contenuto Atom, decidi di utilizzare una libreria. Molto probabilmente dovrai includere del codice da una libreria condivisa come un’installazione di CPAN o una gem di Ruby, o copiare il sorgente nel tuo progetto. Il problema dell’includere la libreria è che è difficile personalizzarla e spesso più difficile da distribuire, perché è necessario assicurarsi che ogni client abbia a disposizione quella libreria. Il problema di includere il codice nel tuo progetto è che è difficile incorporare le modifiche eventualmente fatte nel progetto iniziale quando questo venisse aggiornato.
+
+Git risolve questo problema utilizzando i moduli. I moduli consentono di avere un repository Git come una directory di un altro repository Git, che ti permette di clonare un altro repository nel tuo progetto e mantenere le commit separate.
\ No newline at end of file

From 5ab0f2e246e641fc20ae8a777d3988a872d9fec0 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Sun, 5 Jan 2014 13:54:43 +0100
Subject: [PATCH 043/690] Translating "Starting with Submodules"

---
 it/06-git-tools/01-chapter6.markdown | 33 +++++++++++++++++++++++++++-
 1 file changed, 32 insertions(+), 1 deletion(-)

diff --git a/it/06-git-tools/01-chapter6.markdown b/it/06-git-tools/01-chapter6.markdown
index 2b1831bb9..b3dcd7f3d 100644
--- a/it/06-git-tools/01-chapter6.markdown
+++ b/it/06-git-tools/01-chapter6.markdown
@@ -266,4 +266,35 @@ Capita spesso che, mentre stai lavorando a un progetto, debba includerne un altr
 
 Vediamo un esempio. Immagina di stare sviluppando un sito web creando dei feed Atom e, invece di scrivere da zero il codice per generare il contenuto Atom, decidi di utilizzare una libreria. Molto probabilmente dovrai includere del codice da una libreria condivisa come un’installazione di CPAN o una gem di Ruby, o copiare il sorgente nel tuo progetto. Il problema dell’includere la libreria è che è difficile personalizzarla e spesso più difficile da distribuire, perché è necessario assicurarsi che ogni client abbia a disposizione quella libreria. Il problema di includere il codice nel tuo progetto è che è difficile incorporare le modifiche eventualmente fatte nel progetto iniziale quando questo venisse aggiornato.
 
-Git risolve questo problema utilizzando i moduli. I moduli consentono di avere un repository Git come una directory di un altro repository Git, che ti permette di clonare un altro repository nel tuo progetto e mantenere le commit separate.
\ No newline at end of file
+Git risolve questo problema utilizzando i moduli. I moduli consentono di avere un repository Git come una directory di un altro repository Git, che ti permette di clonare un altro repository nel tuo progetto e mantenere le commit separate.
+
+### Lavorare con i moduli ###
+
+Si supponga di voler aggiungere la libreria Rack (un’interfaccia gateway per server web in Ruby) al progetto, mantenendo le tue modifiche alla libreria e continuando a integrare le modifiche fatte a monte alla libreria. La prima cosa da fare è clonare il repository esterno nella subdirectory: aggiungi i progetti esterni come moduli col comando `git modulo aggiungono`:
+
+	$ git submodule add git://github.com/chneukirchen/rack.git rack
+	Initialized empty Git repository in /opt/subtest/rack/.git/
+	remote: Counting objects: 3181, done.
+	remote: Compressing objects: 100% (1534/1534), done.
+	remote: Total 3181 (delta 1951), reused 2623 (delta 1603)
+	Receiving objects: 100% (3181/3181), 675.42 KiB | 422 KiB/s, done.
+	Resolving deltas: 100% (1951/1951), done.
+
+Ora, all'interno del tuo progetto, hai la directory `rack` che contiene il progetto Rack. Puoi andare in questa directory, fare le tue modifiche e aggiungere il tuo repository remoto per fare la push delle tue modifiche e prendere quelle disponibili, così come incorporare le modifiche del repository originale, e molto altro. Se esegui `git status` subito dopo aver aggiunto il modulo, vedrai due cose:
+
+	$ git status
+	# On branch master
+	# Changes to be committed:
+	#   (use "git reset HEAD <file>..." to unstage)
+	#
+	#      new file:   .gitmodules
+	#      new file:   rack
+	#
+
+Prima di tutto nota il file `.gitmodules`: è un file di configurazione che memorizza la mappatura tra l’URL del progetto e la directory locale dove lo hai scaricato:
+
+	$ cat .gitmodules
+	[submodule "rack"]
+	      path = rack
+	      url = git://github.com/chneukirchen/rack.git
+

From fe8d604dc1feefad05798659be5dc8e0084216f0 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Sun, 5 Jan 2014 14:05:09 +0100
Subject: [PATCH 044/690] Translating "Starting with Submodules"

---
 it/06-git-tools/01-chapter6.markdown | 1 +
 1 file changed, 1 insertion(+)

diff --git a/it/06-git-tools/01-chapter6.markdown b/it/06-git-tools/01-chapter6.markdown
index b3dcd7f3d..1503613ed 100644
--- a/it/06-git-tools/01-chapter6.markdown
+++ b/it/06-git-tools/01-chapter6.markdown
@@ -298,3 +298,4 @@ Prima di tutto nota il file `.gitmodules`: è un file di configurazione che memo
 	      path = rack
 	      url = git://github.com/chneukirchen/rack.git
 
+Se hai più di un modulo, avrei più voci in questo file. È importante notare che anche questo file è versionato con tutti gli altri file, come il tuo `.gitignore` e viene trasferito con tutto il resto del tuo progetto. Questo è il modo in cui gli altri che clonano questo progetto sanno dove trovare i progetti dei moduli.
\ No newline at end of file

From 55ed35a4f57ebb750a6cf208b9290503336b3885 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Sun, 5 Jan 2014 16:25:13 +0100
Subject: [PATCH 045/690] Translating "Starting with Submodules"

---
 it/06-git-tools/01-chapter6.markdown | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/it/06-git-tools/01-chapter6.markdown b/it/06-git-tools/01-chapter6.markdown
index 1503613ed..d2ec49670 100644
--- a/it/06-git-tools/01-chapter6.markdown
+++ b/it/06-git-tools/01-chapter6.markdown
@@ -298,4 +298,10 @@ Prima di tutto nota il file `.gitmodules`: è un file di configurazione che memo
 	      path = rack
 	      url = git://github.com/chneukirchen/rack.git
 
-Se hai più di un modulo, avrei più voci in questo file. È importante notare che anche questo file è versionato con tutti gli altri file, come il tuo `.gitignore` e viene trasferito con tutto il resto del tuo progetto. Questo è il modo in cui gli altri che clonano questo progetto sanno dove trovare i progetti dei moduli.
\ No newline at end of file
+Se hai più di un modulo, avrei più voci in questo file. È importante notare che anche questo file è versionato con tutti gli altri file, come il tuo `.gitignore` e viene trasferito con tutto il resto del tuo progetto. Questo è il modo in cui gli altri che clonano questo progetto sanno dove trovare i progetti dei moduli.
+
+L'altro elenco in stato git uscita `` è la voce rack. Se si esegue `git diff` su questo, si vede qualcosa di interessante:
+
+Sebbene `rack` sia una directory della tua directory di lavoro, Git lo vede come un modulo e non tiene traccia del suo contenuto quando non sei in quella directory. Git invece lo memorizza come una commit particolare da quel repository. Quando committi delle modifiche in quella directory, il super-project nota che l’HEAD è cambiato e registra la commit esatta dove sei; In questo modo, quando altri clonano questo progetto, possono ricreare esattamente l'ambiente.
+
+Questo è un punto importante con i moduli: li memorizzi come la ‘commit esatta dove sono. Non puoi memorizzare un modulo su `master` o qualche altro riferimento simbolico.
\ No newline at end of file

From 72493151d21c9a3b6a0892282abcee07e6b58550 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Sun, 5 Jan 2014 16:35:13 +0100
Subject: [PATCH 046/690] Finished translating "Starting with Submodules"

Starting with "Cloning a Project with Submodules"
---
 it/06-git-tools/01-chapter6.markdown | 30 +++++++++++++++++++++++++++-
 1 file changed, 29 insertions(+), 1 deletion(-)

diff --git a/it/06-git-tools/01-chapter6.markdown b/it/06-git-tools/01-chapter6.markdown
index d2ec49670..5c63b1c13 100644
--- a/it/06-git-tools/01-chapter6.markdown
+++ b/it/06-git-tools/01-chapter6.markdown
@@ -304,4 +304,32 @@ L'altro elenco in stato git uscita `` è la voce rack. Se si esegue `git diff` s
 
 Sebbene `rack` sia una directory della tua directory di lavoro, Git lo vede come un modulo e non tiene traccia del suo contenuto quando non sei in quella directory. Git invece lo memorizza come una commit particolare da quel repository. Quando committi delle modifiche in quella directory, il super-project nota che l’HEAD è cambiato e registra la commit esatta dove sei; In questo modo, quando altri clonano questo progetto, possono ricreare esattamente l'ambiente.
 
-Questo è un punto importante con i moduli: li memorizzi come la ‘commit esatta dove sono. Non puoi memorizzare un modulo su `master` o qualche altro riferimento simbolico.
\ No newline at end of file
+Questo è un punto importante con i moduli: li memorizzi come la ‘commit esatta dove sono. Non puoi memorizzare un modulo su `master` o qualche altro riferimento simbolico.
+
+Quando committi vedi una cosa simile:
+
+	$ git commit -m 'first commit with submodule rack'
+	[master 0550271] first commit with submodule rack
+	 2 files changed, 4 insertions(+), 0 deletions(-)
+	 create mode 100644 .gitmodules
+	 create mode 160000 rack
+
+Nota il modo 160000 di ogni voce di rack. Questo è un modo speciale di Git che significa che stai memorizzando una commit per una directory piuttosto che una subdirectory o un file.
+
+Puoi trattare la directory `rack` come un progetto separato e puoi aggiornare occasionalmente il tuo super-project con un puntatore all’ultima commit del sotto-project. Tutti i comandi di Git lavorano indipendentemente nelle due directories:
+
+	$ git log -1
+	commit 0550271328a0038865aad6331e620cd7238601bb
+	Author: Scott Chacon <schacon@gmail.com>
+	Date:   Thu Apr 9 09:03:56 2009 -0700
+
+	    first commit with submodule rack
+	$ cd rack/
+	$ git log -1
+	commit 08d709f78b8c5b0fbeb7821e37fa53e69afcf433
+	Author: Christian Neukirchen <chneukirchen@gmail.com>
+	Date:   Wed Mar 25 14:49:04 2009 +0100
+
+	    Document version change
+
+### Clonare un progetto con moduli ###
\ No newline at end of file

From 38cbd27f0725cf187a22a12d00011436ca2fca28 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Sun, 5 Jan 2014 16:45:59 +0100
Subject: [PATCH 047/690] Translating "Cloning a Project with Submodules"

---
 it/06-git-tools/01-chapter6.markdown | 59 +++++++++++++++++++++++++++-
 1 file changed, 58 insertions(+), 1 deletion(-)

diff --git a/it/06-git-tools/01-chapter6.markdown b/it/06-git-tools/01-chapter6.markdown
index 5c63b1c13..6434554ba 100644
--- a/it/06-git-tools/01-chapter6.markdown
+++ b/it/06-git-tools/01-chapter6.markdown
@@ -332,4 +332,61 @@ Puoi trattare la directory `rack` come un progetto separato e puoi aggiornare oc
 
 	    Document version change
 
-### Clonare un progetto con moduli ###
\ No newline at end of file
+### Clonare un progetto con moduli ###
+
+Cloneremo ora un progetto con dei moduli. Quando ne ricevi uno, avrai una directory che contiene i moduli, ma nessun file:
+
+	$ git clone git://github.com/schacon/myproject.git
+	Initialized empty Git repository in /opt/myproject/.git/
+	remote: Counting objects: 6, done.
+	remote: Compressing objects: 100% (4/4), done.
+	remote: Total 6 (delta 0), reused 0 (delta 0)
+	Receiving objects: 100% (6/6), done.
+	$ cd myproject
+	$ ls -l
+	total 8
+	-rw-r--r--  1 schacon  admin   3 Apr  9 09:11 README
+	drwxr-xr-x  2 schacon  admin  68 Apr  9 09:11 rack
+	$ ls rack/
+	$
+
+La directory `rack` c’è, ma è vuota. Devi eseguire due comandi: `git submodule init` per inizializzare il tuo file di configurazione locale e `git submodule update` per scaricare tutti i dati del progetto e scaricare le commit opportune elencate nel tuo super-progetto:
+
+	$ git submodule init
+	Submodule 'rack' (git://github.com/chneukirchen/rack.git) registered for path 'rack'
+	$ git submodule update
+	Initialized empty Git repository in /opt/myproject/rack/.git/
+	remote: Counting objects: 3181, done.
+	remote: Compressing objects: 100% (1534/1534), done.
+	remote: Total 3181 (delta 1951), reused 2623 (delta 1603)
+	Receiving objects: 100% (3181/3181), 675.42 KiB | 173 KiB/s, done.
+	Resolving deltas: 100% (1951/1951), done.
+	Submodule path 'rack': checked out '08d709f78b8c5b0fbeb7821e37fa53e69afcf433'
+
+Ora la tua directory `rack` è nello stesso stato in cui era quando hai committal precedentemente. Se qualche altro sviluppatore facesse delle modifiche a rack e le committasse, quando tu scaricherai quel riferimento e lo integrerai nel tuo repository vedrai qualcosa di strano:
+
+	$ git merge origin/master
+	Updating 0550271..85a3eee
+	Fast forward
+	 rack |    2 +-
+	 1 files changed, 1 insertions(+), 1 deletions(-)
+	[master*]$ git status
+	# On branch master
+	# Changes not staged for commit:
+	#   (use "git add <file>..." to update what will be committed)
+	#   (use "git checkout -- <file>..." to discard changes in working directory)
+	#
+	#      modified:   rack
+	#
+
+Quello di cui hai fatto il merge è fondamentalmente un cambiamento al puntatore del tuo modulo, ma non aggiorna il codice nella directory del modulo e sembra quindi che la tua directory di lavoro sia in uno stato ‘sporco’:
+
+	$ git diff
+	diff --git a/rack b/rack
+	index 6c5e70b..08d709f 160000
+	--- a/rack
+	+++ b/rack
+	@@ -1 +1 @@
+	-Subproject commit 6c5e70b984a60b3cecd395edd5b48a7575bf58e0
+	+Subproject commit 08d709f78b8c5b0fbeb7821e37fa53e69afcf433
+

From a3c075a26ab19529105a9dcbee920ac4991c61a5 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Sun, 5 Jan 2014 16:56:22 +0100
Subject: [PATCH 048/690] Translated "Cloning a Project with Submodules"

---
 it/06-git-tools/01-chapter6.markdown | 29 ++++++++++++++++++++++++++++
 1 file changed, 29 insertions(+)

diff --git a/it/06-git-tools/01-chapter6.markdown b/it/06-git-tools/01-chapter6.markdown
index 6434554ba..414a65b6c 100644
--- a/it/06-git-tools/01-chapter6.markdown
+++ b/it/06-git-tools/01-chapter6.markdown
@@ -390,3 +390,32 @@ Quello di cui hai fatto il merge è fondamentalmente un cambiamento al puntatore
 	-Subproject commit 6c5e70b984a60b3cecd395edd5b48a7575bf58e0
 	+Subproject commit 08d709f78b8c5b0fbeb7821e37fa53e69afcf433
 
+Questo succede perché il tuo puntatore del modulo non è lo stesso della directory del modulo. Per correggerlo devi eseguire di nuovo `git submodule update` again:
+
+	$ git submodule update
+	remote: Counting objects: 5, done.
+	remote: Compressing objects: 100% (3/3), done.
+	remote: Total 3 (delta 1), reused 2 (delta 0)
+	Unpacking objects: 100% (3/3), done.
+	From git@github.com:schacon/rack
+	   08d709f..6c5e70b  master     -> origin/master
+	Submodule path 'rack': checked out '6c5e70b984a60b3cecd395edd5b48a7575bf58e0'
+
+E devi farlo ogni volta che scarichi delle modifiche al modulo nel progetto principale: è strano, ma funziona.
+
+Un problema comune si verifica quando uno sviluppatore fa delle modifiche in un modulo ma non le trasmette al server pubblico, ma committa il puntatore a questo stato quando fa la pusg del superproject. Quando altri sviluppatori provano ad eseguire `git submodule update`, il sistema del modulo non riesce a trovare la commit a cui fa riferimento perché esiste solo sul sistema del primo sviluppatore. Quando ciò accade, viene visualizzato un errore come questo:
+
+	$ git submodule update
+	fatal: reference isn’t a tree: 6c5e70b984a60b3cecd395edd5b48a7575bf58e0
+	Unable to checkout '6c5e70b984a60b3cecd395edd5ba7575bf58e0' in submodule path 'rack'
+
+Devi quindi vedere chi è stato l’ultimo a cambiare il modulo:
+
+	$ git log -1 rack
+	commit 85a3eee996800fcfa91e2119372dd4172bf76678
+	Author: Scott Chacon <schacon@gmail.com>
+	Date:   Thu Apr 9 09:19:14 2009 -0700
+
+	    added a submodule reference I will never make public. hahahahaha!
+
+e mandarmi un’email e cazziarlo.
\ No newline at end of file

From 67ff32d3c6ec1922767c321f7318856cc4689624 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Sun, 5 Jan 2014 17:01:50 +0100
Subject: [PATCH 049/690] Translated "Superprojects"

---
 it/06-git-tools/01-chapter6.markdown | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/it/06-git-tools/01-chapter6.markdown b/it/06-git-tools/01-chapter6.markdown
index 414a65b6c..e49ad1a35 100644
--- a/it/06-git-tools/01-chapter6.markdown
+++ b/it/06-git-tools/01-chapter6.markdown
@@ -418,4 +418,10 @@ Devi quindi vedere chi è stato l’ultimo a cambiare il modulo:
 
 	    added a submodule reference I will never make public. hahahahaha!
 
-e mandarmi un’email e cazziarlo.
\ No newline at end of file
+e mandarmi un’email e cazziarlo.
+
+### Super-progetto ###
+
+A volte gli sviluppatori vogliono scaricare una combinazione di subdirectory di un progetto grande, a seconda del team in cui lavorano. Questo è comune se vieni da CVS o Subversion, dove hai definito un modulo o un insieme di subdirectory e vuoi mantenere questo tipo di flusso di lavoro.
+
+Un buon modo per farlo in Git è quello di rendere ciascuna sottodirectory un repository Git separato e creare quindi un repository Git con il super-progetto che contenga più moduli. Un vantaggio di questo approccio è che puoi definire meglio i rapporti tra i progetti con tag e branch nei super-progetti.
\ No newline at end of file

From d1a449d427d6fa96d32c7b32759a869e821759f2 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Sun, 5 Jan 2014 17:54:26 +0100
Subject: [PATCH 050/690] Translated "Summary"

---
 it/06-git-tools/01-chapter6.markdown | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/it/06-git-tools/01-chapter6.markdown b/it/06-git-tools/01-chapter6.markdown
index e49ad1a35..3b1fedea9 100644
--- a/it/06-git-tools/01-chapter6.markdown
+++ b/it/06-git-tools/01-chapter6.markdown
@@ -424,4 +424,8 @@ e mandarmi un’email e cazziarlo.
 
 A volte gli sviluppatori vogliono scaricare una combinazione di subdirectory di un progetto grande, a seconda del team in cui lavorano. Questo è comune se vieni da CVS o Subversion, dove hai definito un modulo o un insieme di subdirectory e vuoi mantenere questo tipo di flusso di lavoro.
 
-Un buon modo per farlo in Git è quello di rendere ciascuna sottodirectory un repository Git separato e creare quindi un repository Git con il super-progetto che contenga più moduli. Un vantaggio di questo approccio è che puoi definire meglio i rapporti tra i progetti con tag e branch nei super-progetti.
\ No newline at end of file
+Un buon modo per farlo in Git è quello di rendere ciascuna sottodirectory un repository Git separato e creare quindi un repository Git con il super-progetto che contenga più moduli. Un vantaggio di questo approccio è che puoi definire meglio i rapporti tra i progetti con tag e branch nei super-progetti.
+
+## Sommario ##
+
+Hai visto numerosi strumenti avanzati che ti permettono di manipolare le tue commit e la tua area di staging in modo più preciso. Quando incontrassi dei problemi dovresti essere facilmente in grado di capire quale commit li ha generati, quando e chi ne è l’autore. Se desideri usare dei sotto-progetti nel tuo progetto e hai appreso alcuni modi per soddisfare tali esigenze. A questo punto dovresti essere in grado di fare in Git la maggior parte delle cose sulla riga di comando di uso quotidiano, e sentirti a tuo agio facendole.
\ No newline at end of file

From d12b40c2e3865c49fb9e4804a4d8cda923e013d3 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Sun, 5 Jan 2014 19:20:15 +0100
Subject: [PATCH 051/690] Translating "Issues with Submodules"

---
 it/06-git-tools/01-chapter6.markdown | 31 ++++++++++++++++++++++++++++
 1 file changed, 31 insertions(+)

diff --git a/it/06-git-tools/01-chapter6.markdown b/it/06-git-tools/01-chapter6.markdown
index 3b1fedea9..149fd4bb6 100644
--- a/it/06-git-tools/01-chapter6.markdown
+++ b/it/06-git-tools/01-chapter6.markdown
@@ -426,6 +426,37 @@ A volte gli sviluppatori vogliono scaricare una combinazione di subdirectory di
 
 Un buon modo per farlo in Git è quello di rendere ciascuna sottodirectory un repository Git separato e creare quindi un repository Git con il super-progetto che contenga più moduli. Un vantaggio di questo approccio è che puoi definire meglio i rapporti tra i progetti con tag e branch nei super-progetti.
 
+### Issues with Submodules ###
+
+Usare i moduli può comunque presentare qualche intoppo. Prima di tutto devi fare molta attenzione quando lavori nella directory del modulo. Quando esegui `git submodule update`, viene fatto il checkout della versione specifica del progetto, ma non del branch. Questo viene detto “avere l’HEAD separato: significa che il file HEAD punta direttamente alla commit, e non un riferimento simbolico. Il problema è che generalmente non vuoi lavorare in un ambiente separato perché è facile perdere commit, e non un riferimento simbolico. Il problema è che generalmente non vuoi lavorare in un ambiente separato perché è facile perdere le tue modifiche. Se inizi col comando `submodule update` e poi fai una commit nella directory del modulo senza aver creato prima un branch per lavorarci e quindi esegui una `git submodule update` dal super-progetto senz’aver committato nel frattempo, Git sovrascriverà le tue modifiche senza dirti nulla.  Tecnicamente non hai perso il tuo lavoro, ma non avendo nessun branch che vi punti sarà difficile da recuperare.
+
+Per evitare questo problema ti basta creare un branch quando lavori nella directory del modulo con `git checkout -b work` o qualcosa di equivalente. Quando successivamente aggiorni il modulo il tuo lavoro sarà di nuovo sovrascritto, ma avrai un puntatore per poterlo recuperare.
+
+Cambiare branch in progetti con dei moduli può essere difficile. Se crei un nuovo branch, vi aggiungi un modulo e torni a un branch che non abbia il modulo, ti ritroverai la directory del modulo non ancora tracciata:
+
+	$ git checkout -b rack
+	Switched to a new branch "rack"
+	$ git submodule add git@github.com:schacon/rack.git rack
+	Initialized empty Git repository in /opt/myproj/rack/.git/
+	...
+	Receiving objects: 100% (3184/3184), 677.42 KiB | 34 KiB/s, done.
+	Resolving deltas: 100% (1952/1952), done.
+	$ git commit -am 'added rack submodule'
+	[rack cc49a69] added rack submodule
+	 2 files changed, 4 insertions(+), 0 deletions(-)
+	 create mode 100644 .gitmodules
+	 create mode 160000 rack
+	$ git checkout master
+	Switched to branch "master"
+	$ git status
+	# On branch master
+	# Untracked files:
+	#   (use "git add <file>..." to include in what will be committed)
+	#
+	#      rack/
+
+Devi rimuoverla o spostarla e in entrambi i casi dovrai riclonarla quando torni al branch precedente e puoi quindi perdere le modifiche locali o i branch di cui non hai ancora fatto una push.
+
 ## Sommario ##
 
 Hai visto numerosi strumenti avanzati che ti permettono di manipolare le tue commit e la tua area di staging in modo più preciso. Quando incontrassi dei problemi dovresti essere facilmente in grado di capire quale commit li ha generati, quando e chi ne è l’autore. Se desideri usare dei sotto-progetti nel tuo progetto e hai appreso alcuni modi per soddisfare tali esigenze. A questo punto dovresti essere in grado di fare in Git la maggior parte delle cose sulla riga di comando di uso quotidiano, e sentirti a tuo agio facendole.
\ No newline at end of file

From f0603201f284f2ccd7d3cf26c9e67798a62e903b Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Sun, 5 Jan 2014 19:36:06 +0100
Subject: [PATCH 052/690] Translated "Issues with Submodules"

---
 it/06-git-tools/01-chapter6.markdown | 33 ++++++++++++++++++++++++++++
 1 file changed, 33 insertions(+)

diff --git a/it/06-git-tools/01-chapter6.markdown b/it/06-git-tools/01-chapter6.markdown
index 149fd4bb6..57c1f2fd7 100644
--- a/it/06-git-tools/01-chapter6.markdown
+++ b/it/06-git-tools/01-chapter6.markdown
@@ -457,6 +457,39 @@ Cambiare branch in progetti con dei moduli può essere difficile. Se crei un nuo
 
 Devi rimuoverla o spostarla e in entrambi i casi dovrai riclonarla quando torni al branch precedente e puoi quindi perdere le modifiche locali o i branch di cui non hai ancora fatto una push.
 
+L'ultima avvertimento riguarda il passaggio da subdirectory a moduli. Se stai versionando dei file tuo nel progetto e vuoi spostarli in un modulo, è necessario devi fare attenzione, altrimenti Git si arrabbierà. Supponi di avere i file di rack in una directory del tuo progetto e decidi di trasformarla in un modulo. Se elimini la directory ed esegui il comando `submodule add`, Git ti strillerà:
+
+	$ rm -Rf rack/
+	$ git submodule add git@github.com:schacon/rack.git rack
+	'rack' already exists in the index
+
+Devi prima rimuovere la directory `rack` dalla tua area di staging per poter quindi aggiungerla come modulo:
+
+	$ git rm -r rack
+	$ git submodule add git@github.com:schacon/rack.git rack
+	Initialized empty Git repository in /opt/testsub/rack/.git/
+	remote: Counting objects: 3184, done.
+	remote: Compressing objects: 100% (1465/1465), done.
+	remote: Total 3184 (delta 1952), reused 2770 (delta 1675)
+	Receiving objects: 100% (3184/3184), 677.42 KiB | 88 KiB/s, done.
+	Resolving deltas: 100% (1952/1952), done.
+
+Immagina ora di averlo fatto in un branch. Se ora torni a un branch dove quei file sono ancora nell’albero corrente piuttosto che nel modulo vedrai questo errore:
+
+	$ git checkout master
+	error: Untracked working tree file 'rack/AUTHORS' would be overwritten by merge.
+	(errore: il file 'rack/AUTHORS' non è versionato e sarà sovrascritto)
+
+Devi quindi spostare la directory del modulo `rack` prima di poter tornare al branch che non ce l’aveva:
+
+	$ mv rack /tmp/
+	$ git checkout master
+	Switched to branch "master"
+	$ ls
+	README	rack
+
+Ora, quando tornerai indietro, troverai la directory `rack` vuota. Ora puoi eseguire `git submodule update` per ripopolarla o rispostare la directory `/tmp/rack` nella directory vuota.
+
 ## Sommario ##
 
 Hai visto numerosi strumenti avanzati che ti permettono di manipolare le tue commit e la tua area di staging in modo più preciso. Quando incontrassi dei problemi dovresti essere facilmente in grado di capire quale commit li ha generati, quando e chi ne è l’autore. Se desideri usare dei sotto-progetti nel tuo progetto e hai appreso alcuni modi per soddisfare tali esigenze. A questo punto dovresti essere in grado di fare in Git la maggior parte delle cose sulla riga di comando di uso quotidiano, e sentirti a tuo agio facendole.
\ No newline at end of file

From 33b648fd1a1c1883a5b02e5856e8e34acf4776ac Mon Sep 17 00:00:00 2001
From: Petr Prikryl <prikryl@atlas.cz>
Date: Sun, 5 Jan 2014 19:42:17 +0100
Subject: [PATCH 053/690] [cs] Typos and formulation changes in Ch. 1 up to 1.3
 included.

---
 cs/01-introduction/01-chapter1.markdown | 24 ++++++++++++------------
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/cs/01-introduction/01-chapter1.markdown b/cs/01-introduction/01-chapter1.markdown
index 44fdd2521..b1b60c735 100644
--- a/cs/01-introduction/01-chapter1.markdown
+++ b/cs/01-introduction/01-chapter1.markdown
@@ -3,7 +3,7 @@
 Tato kapitola vám ve stručnosti představí systém Git. Začneme od samého začátku. Nahlédneme do historie nástrojů ke správě verzí, poté se budeme věnovat tomu, jak spustit systém Git ve vašem počítači, a nakonec se podíváme na možnosti úvodního nastavení. V této kapitole se dozvíte, k čemu Git slouží a proč byste ho měli používat. Kromě toho se také naučíte, jak Git nastavit podle svých potřeb.
 
 ## Správa verzí ##
-
+hi
 Co je to správa verzí a proč by vás měla zajímat? Správa verzí je systém, který zaznamenává změny souboru nebo sady souborů v průběhu času, a uživatel tak může kdykoli obnovit jeho/jejich konkrétní verzi (tzv. verzování). Příklady verzovaných souborů jsou v této knize ilustrovány na zdrojovém kódu softwaru, avšak ve skutečnosti lze verzování provádět téměř se všemi typy souborů v počítači.
 
 Pokud jste grafik nebo webdesigner a chcete uchovávat všechny verze obrázku nebo všechna rozložení stránky (což jistě není k zahození), je pro vás systém správy verzí (zkráceně VCS z angl. Version Control System) ideálním nástrojem. VCS umožňuje vrátit jednotlivé soubory nebo celý projekt do předchozího stavu, porovnávat změny provedené v průběhu času, zjistit, kdo naposledy upravil něco, co nyní možná způsobuje problémy, kdo vložil jakou verzi a kdy a mnoho dalšího. Používáte-li verzovací systém, většinou to také znamená, že snadno obnovíte soubory, které jste ztratili nebo v nichž byly provedeny nežádoucí změny. Všechny funkcionality verzovacího systému můžete navíc používat velice jednoduchým způsobem.
@@ -37,11 +37,11 @@ V tomto místě přicházejí ke slovu tzv. distribuované systémy správy verz
 Insert 18333fig0103.png
 Obrázek 1-3. Diagram distribuované správy verzí
 
-Mnoho z těchto systémů navíc bez větších obtíží pracuje i s několika vzdálenými repozitáři, a vy tak můžete v rámci jednoho projektu spolupracovat na různých úrovních s rozdílnými skupinami lidí. Díky tomu si můžete vytvořit několik typů pracovních postupů, což není v centralizovaných systémech (např. v hierarchických modelech) možné.
+Mnoho z těchto systémů navíc bez větších obtíží pracuje i s několika vzdálenými repozitáři, takže můžete v rámci jednoho projektu různým způsobem spolupracovat s různými skupinami lidí najednou. Můžete zavést několik typů pracovních postupů, které nejsou v centralizovaných systémech možné — jako jsou například hierarchické modely.
 
 ## Stručná historie systému Git ##
 
-Tak jako mnoho velkých věcí v lidské historii se i systém Git zrodil z kreativní destrukce a vášnivého sporu. Jádro Linuxu je software s otevřeným kódem a širokou škálou využití. V letech 1991 — 2002 bylo jádro Linuxu spravováno formou záplat a archivních souborů. V roce 2002 začal projekt vývoje linuxového jádra využívat komerční systém DVCS s názvem Bit-Keeper.
+Tak jako mnoho velkých věcí v lidské historii se i systém Git zrodil z kreativní destrukce a vášnivého sporu. Jádro Linuxu je software celkém velkého rozsahu, s otevřeným kódem. V letech 1991 — 2002 bylo jádro Linuxu spravováno formou záplat a archivních souborů. V roce 2002 začal projekt vývoje linuxového jádra využívat komerční systém DVCS s názvem BitKeeper.
 
 V roce 2005 se zhoršily vztahy mezi komunitou, která vyvíjela jádro Linuxu, a komerční společností, která vyvinula BitKeeper, a společnost přestala tento systém poskytovat zdarma. To přimělo komunitu vývojářů Linuxu (a zejména Linuse Torvaldse, tvůrce Linuxu), aby vyvinula vlastní nástroj, založený na poznatcích, které nasbírala při užívání systému BitKeeper. Mezi požadované vlastnosti systému patřily zejména:
 
@@ -55,7 +55,7 @@ Od svého vzniku v roce 2005 se Git vyvinul a vyzrál v snadno použitelný syst
 
 ## Základy systému Git ##
 
-Jak bychom tedy mohli Git charakterizovat? Odpověď na tuto otázku je velmi důležitá, protože pokud pochopíte, co je Git a na jakém principu pracuje, budete ho bezpochyby moci používat mnohem efektivněji. Při seznámení se systémem Git se pokuste zapomenout na vše, co už možná víte o jiných systémech VCS, např. Subversion nebo Perforce. Vyhnete se tak nežádoucím vlivům, které by vás mohly při používání systému Git mást. Ačkoli je uživatelské rozhraní velmi podobné, Git ukládá a zpracovává informace poněkud odlišně od ostatních systémů. Pochopení těchto rozdílů vám pomůže předejít nejasnostem, které mohou vzniknout při používání systému Git.
+Jak bychom tedy mohli Git charakterizovat? Odpověď na tuto otázku je velmi důležitá, protože pokud pochopíte, co je Git a na jakém principu pracuje, budete ho bezpochyby moci používat mnohem efektivněji. Při seznámení se systémem Git se pokuste zapomenout na vše, co už možná víte o jiných systémech VCS, např. Subversion nebo Perforce. Vyhnete se tak nežádoucím vlivům, které by vás mohly při používání systému Git mást. Ačkoli je uživatelské rozhraní velmi podobné, Git ukládá a zpracovává informace poněkud odlišně od ostatních systémů. Pochopení těchto rozdílů vám pomůže předejít nejasnostem, které mohou při používání systému Git vzniknout.
 
 ### Snímky, nikoli rozdíly ###
 
@@ -69,31 +69,31 @@ Git zpracovává data jinak. Chápe je spíše jako sadu snímků (snapshots) vl
 Insert 18333fig0105.png
 Obrázek 1-5. Git ukládá data jako snímky projektu proměnlivé v čase.
 
-Toto je důležitý rozdíl mezi systémem Git a téměř všemi ostatními systémy VCS. Git díky tomu znovu zkoumá skoro každý aspekt správy verzí, které ostatní systémy kopírovaly z předchozí generace. Git je tak z obyčejného VCS spíše povýšen na vlastní systém správy souborů s řadou skutečně výkonných nástrojů, jež stojí na jeho vrcholu. Některé přednosti, které tato metoda správy dat nabízí, si podrobně ukážeme na systému větvení v kapitole 3.
+Toto je důležitý rozdíl mezi systémem Git a téměř všemi ostatními systémy VCS. Git díky tomu znovu zkoumá skoro každý aspekt správy verzí, které ostatní systémy kopírovaly z předchozí generace. Git se podobá malému systému souborů (spíše než obyčejnému VCS) s řadou skutečně výkonných nástrojů, jež stojí na jeho vrcholu. Některé přednosti, které tato metoda správy dat nabízí, si podrobně ukážeme na systému větvení v kapitole 3.
 
 ### Téměř každá operace je lokální ###
 
 Většina operací v systému Git vyžaduje ke své činnosti pouze lokální soubory a zdroje a nejsou potřeba informace z jiných počítačů v síti. Pokud jste zvyklí pracovat se systémy CVCS, kde je většina operací poznamenána latencí sítě, patrně vás při práci v systému Git napadne, že mu bohové rychlosti dali do vínku nadpřirozené schopnosti. Protože máte celou historii projektu uloženou přímo na svém lokálním disku, probíhá většina operací takřka okamžitě.
 
-Pokud chcete například procházet historii projektu, Git kvůli tomu nemusí vyhledávat informace na serveru — načte ji jednoduše přímo z vaší lokální databáze. Znamená to, že se historie projektu zobrazí téměř neprodleně. Pokud si chcete prohlédnout změny provedené mezi aktuální verzí souboru a týmž souborem před měsícem, Git vyhledá měsíc starý soubor a provede lokální výpočet rozdílů, aniž by o to musel žádat vzdálený server nebo stahovat starší verzi souboru ze vzdáleného serveru a poté provádět lokální výpočet.
+Pokud chcete například procházet historii projektu, Git kvůli tomu nemusí vyhledávat informace na serveru — načte je jednoduše přímo z vaší lokální databáze. Znamená to, že se historie projektu zobrazí téměř hned. Pokud si chcete prohlédnout změny provedené mezi aktuální verzí souboru a týmž souborem před měsícem, Git vyhledá měsíc starý soubor a provede lokální výpočet rozdílů, aniž by o to musel žádat vzdálený server nebo stahovat starší verzi souboru ze vzdáleného serveru a poté provádět lokální výpočet.
 
-To také znamená, že je jen velmi málo operací, které nemůžete provádět offline nebo bez připojení k VPN. Jste-li v letadle nebo ve vlaku a chcete pokračovat v práci, můžete beze všeho zapisovat nové revize. Ty se odešlou ve chvíli, kdy se opět připojíte k síti. Jestliže přijedete domů a zjistíte, že VPN klient nefunguje, stále můžete pracovat. V mnoha jiných systémech je takový postup nemožný nebo přinejmenším obtížný. Například v systému Perforce toho lze bez připojení k serveru dělat jen velmi málo, v systémech Subversion a CVS můžete sice upravovat soubory, ale nemůžete zapisovat změny do databáze, neboť ta je offline. Možná to vypadá jako maličkost, ale divili byste se, jaký je to velký rozdíl.
+To také znamená, že je jen velmi málo operací, které nemůžete provádět offline nebo bez připojení k VPN. Jste-li v letadle nebo ve vlaku a chcete pokračovat v práci, můžete beze všeho zapisovat nové revize. Ty odešlete až po opětovném připojení k síti. Jestliže přijedete domů a zjistíte, že VPN klient nefunguje, stále můžete pracovat. V mnoha jiných systémech je takový postup nemožný nebo přinejmenším obtížný. Například v systému Perforce toho lze bez připojení k serveru dělat jen velmi málo, v systémech Subversion a CVS můžete sice upravovat soubory, ale nemůžete zapisovat změny do databáze, neboť ta je offline. Možná to vypadá jako maličkost, ale divili byste se, jak velký je v tom rozdíl.
 
 ### Git pracuje důsledně ###
 
-Než je v systému Git cokoli uloženo, je nejprve proveden kontrolní součet, který je potom používán k identifikaci uloženého souboru. Znamená to, že není možné změnit obsah jakéhokoli souboru nebo adresáře, aniž by o tom Git nevěděl. Tato funkce je integrována do systému Git na nejnižších úrovních a je v souladu s jeho filozofií. Nemůže tak dojít ke ztrátě informací při přenosu dat nebo k poškození souboru, aniž by to byl Git schopen zjistit.
+Než je v systému Git cokoli uloženo, je nejprve proveden kontrolní součet, který je potom používán k identifikaci uloženého souboru. Znamená to, že není možné změnit obsah jakéhokoli souboru nebo adresáře, aniž by o tom Git nevěděl. Tato funkce je integrována do systému Git na nejnižších úrovních a je nedílnou součástí jeho filozofie. Nemůže tak dojít ke ztrátě informací při přenosu dat nebo k poškození souboru, aniž by to byl Git schopen zjistit.
 
 Mechanismus, který Git k tomuto kontrolnímu součtu používá, se nazývá otisk SHA-1 (SHA-1 hash). Jedná se o řetězec o 40 hexadecimálních znacích (0–9; a–f) vypočítaný na základě obsahu souboru nebo adresářové struktury systému Git. Otisk SHA-1 může vypadat například takto:
 
 	24b9da6552252987aa493b52f8696cd6d3b00373
 
-S těmito otisky se budete setkávat ve všech úložištích systému Git, protože je používá opravdu často. Neukládá totiž soubory podle jejich názvu, ale ve své databázi podle otisku (hashe) jeho obsahu.
+S těmito otisky se budete setkávat ve všech úložištích systému Git, protože je používá opravdu často. Git nic neukládá podle názvu souboru. Místo toho používá databázi adresovatelnou hodnotou otisku, který odpovídá obsahu souboru.
 
 ### Git většinou jen přidává data ###
 
 Jednotlivé operace ve většině případů jednoduše přidávají data do Git databáze. Přimět systém, aby udělal něco, co nelze vzít zpět, nebo aby smazal jakákoli data, je velice obtížné. Stejně jako ve všech systémech VCS můžete ztratit nebo nevratně zničit změny, které ještě nebyly zapsány. Jakmile však jednou zapíšete snímek do systému Git, je téměř nemožné ho ztratit, zvlášť pokud pravidelně zálohujete databázi do jiného repozitáře.
 
-Díky tomu vás bude práce se systémem Git bavit. Budete pracovat s vědomím, že můžete experimentovat, a neriskujete přitom nevratné zničení své práce. Podrobnější informace o tom, jak Git ukládá data a jak lze obnovit zdánlivě ztracenou práci, najdete v kapitole 9 „Git pod pokličkou“.
+Díky tomu vás bude práce se systémem Git bavit. Budete pracovat s vědomím, že můžete experimentovat, a neriskujete přitom nevratné zničení své práce. Podrobnější informace o tom, jak Git ukládá data a jak lze obnovit zdánlivě ztracenou práci, najdete v kapitole 9.
 
 ### Tři stavy ###
 
@@ -104,9 +104,9 @@ Z toho vyplývá, že projekt je v systému Git rozdělen do tří hlavních č
 Insert 18333fig0106.png
 Obrázek 1-6. Pracovní adresář, oblast připravených změn a adresář Git
 
-V adresáři Git ukládá systém databázi metadat a objektů k projektu. Je to nejdůležitější část systému Git a zároveň adresář, který se zkopíruje, když klonujete repozitář z jiného počítače.
+Adresář Git (repozitář) je místo, kde Git uchovává metadata a databázi objektů vašeho projektu. Je to nejdůležitější část systému Git a zároveň adresář, který se zkopíruje, když klonujete repozitář z jiného počítače.
 
-Pracovní adresář obsahuje lokální kopii jedné verze projektu. Tyto soubory jsou staženy ze zkomprimované databáze v adresáři Git a umístěny na disk, abyste je mohli upravovat.
+Pracovní adresář obsahuje lokální kopii jedné verze projektu. Tyto soubory jsou staženy ze zkomprimované databáze v adresáři Git a umístěny na disk, kde je můžete používat nebo upravovat.
 
 Oblast připravených změn je jednoduchý soubor, většinou uložený v adresáři Git, který obsahuje informace o tom, co bude obsahovat příští revize. Soubor se někdy označuje také anglickým výrazem „index“, ale oblast připravených změn (staging area) je už dnes termín běžnější.
 

From d42c90ea3dd5059a11aa5dddb510edbc9a7b4a89 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Sun, 5 Jan 2014 22:03:32 +0100
Subject: [PATCH 054/690] Translating "Subtree Merging"

---
 it/06-git-tools/01-chapter6.markdown | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/it/06-git-tools/01-chapter6.markdown b/it/06-git-tools/01-chapter6.markdown
index 57c1f2fd7..b7ee69f7f 100644
--- a/it/06-git-tools/01-chapter6.markdown
+++ b/it/06-git-tools/01-chapter6.markdown
@@ -490,6 +490,10 @@ Devi quindi spostare la directory del modulo `rack` prima di poter tornare al br
 
 Ora, quando tornerai indietro, troverai la directory `rack` vuota. Ora puoi eseguire `git submodule update` per ripopolarla o rispostare la directory `/tmp/rack` nella directory vuota.
 
+## Subtree Merging ##
+
+Ora che hai visto quali sono le difficoltà del sistema dei moduli vediamo un’alternativa per risolvere lo stesso problema. Quando Git fa dei merge vede prima quello di cui deve fare il merge e poi decide quale sia la strategia migliore da usare. Se stai facendo il merge due branch Git userà la strategia _ricorsiva_ (*recursive* in inglese). Se stai facendo il merge di più di due branch Git userà la strategia del polpo (*octopus* in inglese). Queste strategie sono scelte automaticamente, perché la strategia ricorsiva può gestire situazioni complesse di merge a tre vie (quando ci sono per esempio più antenati), ma può gestire solamente due branch alla volta. La strategia del polpo può gestire branch multipli ma agisce con più cautela per evitare conflitti difficili da risolvere, ed è quindi scelta come strategia predefinita se stai facendo il merge di più di due branch.
+
 ## Sommario ##
 
 Hai visto numerosi strumenti avanzati che ti permettono di manipolare le tue commit e la tua area di staging in modo più preciso. Quando incontrassi dei problemi dovresti essere facilmente in grado di capire quale commit li ha generati, quando e chi ne è l’autore. Se desideri usare dei sotto-progetti nel tuo progetto e hai appreso alcuni modi per soddisfare tali esigenze. A questo punto dovresti essere in grado di fare in Git la maggior parte delle cose sulla riga di comando di uso quotidiano, e sentirti a tuo agio facendole.
\ No newline at end of file

From 1cd71971f139349a74a901bf69225344d85b4156 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Sun, 5 Jan 2014 22:11:07 +0100
Subject: [PATCH 055/690] Translating "Subtree Merging"

---
 it/06-git-tools/01-chapter6.markdown | 33 ++++++++++++++++++++++++++++
 1 file changed, 33 insertions(+)

diff --git a/it/06-git-tools/01-chapter6.markdown b/it/06-git-tools/01-chapter6.markdown
index b7ee69f7f..68318e173 100644
--- a/it/06-git-tools/01-chapter6.markdown
+++ b/it/06-git-tools/01-chapter6.markdown
@@ -494,6 +494,39 @@ Ora, quando tornerai indietro, troverai la directory `rack` vuota. Ora puoi eseg
 
 Ora che hai visto quali sono le difficoltà del sistema dei moduli vediamo un’alternativa per risolvere lo stesso problema. Quando Git fa dei merge vede prima quello di cui deve fare il merge e poi decide quale sia la strategia migliore da usare. Se stai facendo il merge due branch Git userà la strategia _ricorsiva_ (*recursive* in inglese). Se stai facendo il merge di più di due branch Git userà la strategia del polpo (*octopus* in inglese). Queste strategie sono scelte automaticamente, perché la strategia ricorsiva può gestire situazioni complesse di merge a tre vie (quando ci sono per esempio più antenati), ma può gestire solamente due branch alla volta. La strategia del polpo può gestire branch multipli ma agisce con più cautela per evitare conflitti difficili da risolvere, ed è quindi scelta come strategia predefinita se stai facendo il merge di più di due branch.
 
+Ci sono comunque altre strategie tra cui scegliere. Una di questa è il merge *subtree* e la puoi usare per risolvere i problemi dei subprogetti. Vedremo ora come includere lo stesso rack come abbiamo fatto nella sezione precedente, usando però il merge subtree.
+
+L’idea del merge subtree è che tu hai due progetti e uno di questi è mappato su una subdirectory dell’altro e viceversa. Quando specifichi il merge subtree Git è abbastanza intelligente da capire che uno è un albero dell’altro e farne il merge nel migliore dei modi: è piuttosto incredibile.
+
+Aggiungi prima l’applicazione Rack al tuo progetto e aggiungi il progetto Rack come un riferimento remoto al tuo progetto, quindi fanne il checkout in un suo branch:
+
+	$ git remote add rack_remote git@github.com:schacon/rack.git
+	$ git fetch rack_remote
+	warning: no common commits
+	remote: Counting objects: 3184, done.
+	remote: Compressing objects: 100% (1465/1465), done.
+	remote: Total 3184 (delta 1952), reused 2770 (delta 1675)
+	Receiving objects: 100% (3184/3184), 677.42 KiB | 4 KiB/s, done.
+	Resolving deltas: 100% (1952/1952), done.
+	From git@github.com:schacon/rack
+	 * [new branch]      build      -> rack_remote/build
+	 * [new branch]      master     -> rack_remote/master
+	 * [new branch]      rack-0.4   -> rack_remote/rack-0.4
+	 * [new branch]      rack-0.9   -> rack_remote/rack-0.9
+	$ git checkout -b rack_branch rack_remote/master
+	Branch rack_branch set up to track remote branch refs/remotes/rack_remote/master.
+	Switched to a new branch "rack_branch"
+
+Ora hai la root del progetto Rack nel tuo branch `rack_branch` e il tuo progetto nel branch `master`. Se scarichi prima uno e poi l’altro vedrai che avranno due progetti sorgenti:
+
+	$ ls
+	AUTHORS	       KNOWN-ISSUES   Rakefile      contrib	       lib
+	COPYING	       README         bin           example	       test
+	$ git checkout master
+	Switched to branch "master"
+	$ ls
+	README
+
 ## Sommario ##
 
 Hai visto numerosi strumenti avanzati che ti permettono di manipolare le tue commit e la tua area di staging in modo più preciso. Quando incontrassi dei problemi dovresti essere facilmente in grado di capire quale commit li ha generati, quando e chi ne è l’autore. Se desideri usare dei sotto-progetti nel tuo progetto e hai appreso alcuni modi per soddisfare tali esigenze. A questo punto dovresti essere in grado di fare in Git la maggior parte delle cose sulla riga di comando di uso quotidiano, e sentirti a tuo agio facendole.
\ No newline at end of file

From 5fe0860443c025802fffbc150764aa5225b32787 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Sun, 5 Jan 2014 22:28:20 +0100
Subject: [PATCH 056/690] Translating "Subtree Merging"

---
 it/06-git-tools/01-chapter6.markdown | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/it/06-git-tools/01-chapter6.markdown b/it/06-git-tools/01-chapter6.markdown
index 68318e173..9accc6b42 100644
--- a/it/06-git-tools/01-chapter6.markdown
+++ b/it/06-git-tools/01-chapter6.markdown
@@ -527,6 +527,10 @@ Ora hai la root del progetto Rack nel tuo branch `rack_branch` e il tuo progetto
 	$ ls
 	README
 
+Ora vuoi inviare il progetto Rack nel tuo progetto `master` come una sottodirectory e in Git puoi farlo con `git read-tree`. Conoscerai meglio `read-tree` e i suoi amici nel Capitolo 9, ma per ora sappi che legge la radice di un branch nella tua area di staging della tua directory di lavoro. Sei appena ritornato nel tuo branch `master` e hai scaricato il branch `rack` nella directory `rack` del branch `master` del tuo progetto principale:
+
+	$ git read-tree --prefix=rack/ -u rack_branch
+
 ## Sommario ##
 
 Hai visto numerosi strumenti avanzati che ti permettono di manipolare le tue commit e la tua area di staging in modo più preciso. Quando incontrassi dei problemi dovresti essere facilmente in grado di capire quale commit li ha generati, quando e chi ne è l’autore. Se desideri usare dei sotto-progetti nel tuo progetto e hai appreso alcuni modi per soddisfare tali esigenze. A questo punto dovresti essere in grado di fare in Git la maggior parte delle cose sulla riga di comando di uso quotidiano, e sentirti a tuo agio facendole.
\ No newline at end of file

From 6c06140c4990176214962c2546f81ffe680d4272 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Sun, 5 Jan 2014 22:35:45 +0100
Subject: [PATCH 057/690] Translating "Subtree Merging"

---
 it/06-git-tools/01-chapter6.markdown | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/it/06-git-tools/01-chapter6.markdown b/it/06-git-tools/01-chapter6.markdown
index 9accc6b42..c813e76e8 100644
--- a/it/06-git-tools/01-chapter6.markdown
+++ b/it/06-git-tools/01-chapter6.markdown
@@ -531,6 +531,11 @@ Ora vuoi inviare il progetto Rack nel tuo progetto `master` come una sottodirect
 
 	$ git read-tree --prefix=rack/ -u rack_branch
 
+Quando fai la commit sembra che tutti i file di Rack siano nella directory, come se li avessi copiati da un archivio. La cosa interessante è che può fare facilmente il merge da un branch all’altro, così che puoi importare gli aggiornamenti del progetto Rack passando a quel branch e facendo la pull:
+
+	$ git checkout rack_branch
+	$ git pull
+
 ## Sommario ##
 
 Hai visto numerosi strumenti avanzati che ti permettono di manipolare le tue commit e la tua area di staging in modo più preciso. Quando incontrassi dei problemi dovresti essere facilmente in grado di capire quale commit li ha generati, quando e chi ne è l’autore. Se desideri usare dei sotto-progetti nel tuo progetto e hai appreso alcuni modi per soddisfare tali esigenze. A questo punto dovresti essere in grado di fare in Git la maggior parte delle cose sulla riga di comando di uso quotidiano, e sentirti a tuo agio facendole.
\ No newline at end of file

From b894f16e45cdd77f84b2abe728003a8d343e21ee Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Sun, 5 Jan 2014 22:59:44 +0100
Subject: [PATCH 058/690] Translation completed

---
 it/06-git-tools/01-chapter6.markdown | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/it/06-git-tools/01-chapter6.markdown b/it/06-git-tools/01-chapter6.markdown
index c813e76e8..d27267b96 100644
--- a/it/06-git-tools/01-chapter6.markdown
+++ b/it/06-git-tools/01-chapter6.markdown
@@ -536,6 +536,16 @@ Quando fai la commit sembra che tutti i file di Rack siano nella directory, come
 	$ git checkout rack_branch
 	$ git pull
 
+Tutte le modifiche del progetto Rack project vengono incorporate e sono pronte per essere committate in locale. Puoi fare anche l’opposto: modificare la directory `rack` e poi fare il merge nel branch `rack_branch` per inviarlo al mantenitore o farne la push al server remoto.
+
+Per fare un confronto tra quello che hai nella directory `rack` e il codice nel branch `rack_branch` (e vedere se devi fare un merge o meno) non puoi usare il normale comando `diff`: devi usare invece `git diff-tree` con il branch con cui vuoi fare il confronto:
+
+	$ git diff-tree -p rack_branch
+
+O confrontare quello che c’è nella directory `rack` con quello che c’era nel branch `master` l’ultima volta che l’hai scaricato, col comando
+
+	$ git diff-tree -p rack_remote/master
+
 ## Sommario ##
 
 Hai visto numerosi strumenti avanzati che ti permettono di manipolare le tue commit e la tua area di staging in modo più preciso. Quando incontrassi dei problemi dovresti essere facilmente in grado di capire quale commit li ha generati, quando e chi ne è l’autore. Se desideri usare dei sotto-progetti nel tuo progetto e hai appreso alcuni modi per soddisfare tali esigenze. A questo punto dovresti essere in grado di fare in Git la maggior parte delle cose sulla riga di comando di uso quotidiano, e sentirti a tuo agio facendole.
\ No newline at end of file

From 20c7daef2b0858f029eac29cc4a6665e987a6e9e Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Mon, 6 Jan 2014 10:21:21 +0100
Subject: [PATCH 059/690] Fixing Travis highlights

because the conversion failed.
see https://travis-ci.org/progit/progit/builds/16434388
---
 it/06-git-tools/01-chapter6.markdown | 15 ++++++++++++---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/it/06-git-tools/01-chapter6.markdown b/it/06-git-tools/01-chapter6.markdown
index d27267b96..516bf8580 100644
--- a/it/06-git-tools/01-chapter6.markdown
+++ b/it/06-git-tools/01-chapter6.markdown
@@ -300,11 +300,20 @@ Prima di tutto nota il file `.gitmodules`: è un file di configurazione che memo
 
 Se hai più di un modulo, avrei più voci in questo file. È importante notare che anche questo file è versionato con tutti gli altri file, come il tuo `.gitignore` e viene trasferito con tutto il resto del tuo progetto. Questo è il modo in cui gli altri che clonano questo progetto sanno dove trovare i progetti dei moduli.
 
-L'altro elenco in stato git uscita `` è la voce rack. Se si esegue `git diff` su questo, si vede qualcosa di interessante:
+L'altro elenco in stato git uscita `git status` è la voce rack. Se si esegue `git diff` su questo, si vede qualcosa di interessante:
 
-Sebbene `rack` sia una directory della tua directory di lavoro, Git lo vede come un modulo e non tiene traccia del suo contenuto quando non sei in quella directory. Git invece lo memorizza come una commit particolare da quel repository. Quando committi delle modifiche in quella directory, il super-project nota che l’HEAD è cambiato e registra la commit esatta dove sei; In questo modo, quando altri clonano questo progetto, possono ricreare esattamente l'ambiente.
+	$ git diff --cached rack
+	diff --git a/rack b/rack
+	new file mode 160000
+	index 0000000..08d709f
+	--- /dev/null
+	+++ b/rack
+	@@ -0,0 +1 @@
+	+Subproject commit 08d709f78b8c5b0fbeb7821e37fa53e69afcf433
+
+Sebbene `rack` sia una subdirectory della tua directory di lavoro, Git lo vede come un modulo e non tiene traccia del suo contenuto quando non sei in quella directory. Git invece lo memorizza come una commit particolare da quel repository. Quando committi delle modifiche in quella directory, il super-project nota che l’HEAD è cambiato e registra la commit esatta dove sei; In questo modo, quando altri clonano questo progetto, possono ricreare esattamente l'ambiente.
 
-Questo è un punto importante con i moduli: li memorizzi come la ‘commit esatta dove sono. Non puoi memorizzare un modulo su `master` o qualche altro riferimento simbolico.
+Questo è un punto importante con i moduli: li memorizzi come la commit esatta dove sono. Non puoi memorizzare un modulo su `master` o qualche altro riferimento simbolico.
 
 Quando committi vedi una cosa simile:
 

From 1d6bb5406ea684b7f7ae1b9439254bbd07aa6dec Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Mon, 6 Jan 2014 10:35:39 +0100
Subject: [PATCH 060/690] Translated line 339

---
 it/08-git-and-other-scms/01-chapter8.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/it/08-git-and-other-scms/01-chapter8.markdown b/it/08-git-and-other-scms/01-chapter8.markdown
index 3c2023ca7..7eb703c2c 100644
--- a/it/08-git-and-other-scms/01-chapter8.markdown
+++ b/it/08-git-and-other-scms/01-chapter8.markdown
@@ -336,7 +336,7 @@ Il secondo, `git svn show-ignore`, mostra nella console le righe che devi includ
 
 	$ git svn show-ignore > .git/info/exclude
 
-That way, you don’t litter the project with `.gitignore` files. This is a good option if you’re the only Git user on a Subversion team, and your teammates don’t want `.gitignore` files in the project.
+In questo modo non riempirai il progetto con i file `.gitignore`. Questa è una buona opzione se sei l'unico utente Git in un gruppo Subversion e i tuoi compagni non vogliono i file `.gitignore` nel progetto.
 
 ### Sommario Git-Svn ###
 

From 866091ca72d10714c43bb2de7c12741e421174cb Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Mon, 6 Jan 2014 16:52:02 +0100
Subject: [PATCH 061/690] Translating "Applying a Patch with am"

---
 it/05-distributed-git/01-chapter5.markdown | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/it/05-distributed-git/01-chapter5.markdown b/it/05-distributed-git/01-chapter5.markdown
index 7e2b6a983..e1a94d448 100755
--- a/it/05-distributed-git/01-chapter5.markdown
+++ b/it/05-distributed-git/01-chapter5.markdown
@@ -603,11 +603,11 @@ Puoi usare `git apply` anche per vedere se una patch può essere applicata in ma
 
 Se non viene visualizzato alcun output, allora la patch può essere applicata in maniera pulita. Questo comando termina con un valore diverso da zero se il controllo fallisce, quindi puoi usarlo anche all'interno di uno script.
 
-#### Applying a Patch with am ####
+#### Applicare una patch con am ####
 
-If the contributor is a Git user and was good enough to use the `format-patch` command to generate their patch, then your job is easier because the patch contains author information and a commit message for you. If you can, encourage your contributors to use `format-patch` instead of `diff` to generate patches for you. You should only have to use `git apply` for legacy patches and things like that.
+Se il contributore è un utente Git ed è stato abbastanza bravo a usare il comando `format-patch` per generare la sua patch, allora il tuo lavoro è più facile perché la patch contiene le informazioni sull'autore e un messaggio di commit per te. Se ti è possibile incoraggia i tuoi collaboratori ad utilizzare `format-patch` invece di `diff` per generare le patch per te. Dovresti dover usare solo `git apply` per le patch precedenti e altre cose del genere.
 
-To apply a patch generated by `format-patch`, you use `git am`. Technically, `git am` is built to read an mbox file, which is a simple, plain-text format for storing one or more e-mail messages in one text file. It looks something like this:
+Per applicare una patch generata con `format-patch` si usa `git am`. Tecnicamente `git am` è fatto per leggere un file mbox, che ha un formato semplice di solo testo per memorizzare uno o più messaggi email in un solo file che assomiglia a questo:
 
 	From 330090432754092d704da8e76ca5c05c198e71a8 Mon Sep 17 00:00:00 2001
 	From: Jessica Smith <jessica@example.com>
@@ -616,14 +616,14 @@ To apply a patch generated by `format-patch`, you use `git am`. Technically, `gi
 
 	Limit log functionality to the first 20
 
-This is the beginning of the output of the format-patch command that you saw in the previous section. This is also a valid mbox e-mail format. If someone has e-mailed you the patch properly using git send-email, and you download that into an mbox format, then you can point git am to that mbox file, and it will start applying all the patches it sees. If you run a mail client that can save several e-mails out in mbox format, you can save entire patch series into a file and then use git am to apply them one at a time.
+Questo è l'inizio dell'output del comando 'format-patch' che hai visto nella sezione precedente, ed è anche un formato valido per mbox. Se qualcuno ti ha inviato la patch usando 'git send-email' e l'hai scaricata nel formato mbox, allora puoi puntare al file mbox da 'git am' e lui inizierà ad applicare tutte le patch che troa. Se hai un client di posta elettronica che ti permette di salvare più messaggi in un file mbox allora puoi salvare tutta una serie di patch in un singolo file e usare `git am` per applicarle tutte assieme.
 
-However, if someone uploaded a patch file generated via `format-patch` to a ticketing system or something similar, you can save the file locally and then pass that file saved on your disk to `git am` to apply it:
+Se però qualcuno ha caricato su un sistema di ticket (o qualcosa di simile) una patch generata con `format-patch`, tu puoi salvare il file localmente e passarlo a `git am` perché lo applichi:
 
 	$ git am 0001-limit-log-function.patch
 	Applying: add limit to log function
 
-You can see that it applied cleanly and automatically created the new commit for you. The author information is taken from the e-mail’s `From` and `Date` headers, and the message of the commit is taken from the `Subject` and body (before the patch) of the e-mail. For example, if this patch was applied from the mbox example I just showed, the commit generated would look something like this:
+Puoi vedere che ha applicato automaticamente e senza errori le modifiche e creato una commit per te. Le informazioni sull'autore e la data della commit vengono prese delle intestazioni dell'email (rispettivamente da `From`  e `Date`), mentre il messaggio della commit è preso dal `Subject` e dal corpo dell'email, prima della patch. Se, per esempio questa patch fosse stata applicata dall'esempio dell'mbox appena mostrato, la commit generata apparirebbe così:
 
 	$ git log --pretty=fuller -1
 	commit 6c5e70b984a60b3cecd395edd5b48a7575bf58e0

From 350a63f90a5ceccb69510c0296347089df67f40a Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Mon, 6 Jan 2014 22:17:47 +0100
Subject: [PATCH 062/690] Reviewed "Distributed Git"

---
 it/05-distributed-git/01-chapter5.markdown | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/it/05-distributed-git/01-chapter5.markdown b/it/05-distributed-git/01-chapter5.markdown
index e1a94d448..b45ec93f4 100755
--- a/it/05-distributed-git/01-chapter5.markdown
+++ b/it/05-distributed-git/01-chapter5.markdown
@@ -1,8 +1,8 @@
 # Git distribuito #
 
-Ora che avete un repository Git remoto messo a punto per tutti gli sviluppatore per condividere il proprio codice, e siete familiari con i comandi di base di Git nel lavoro in locale, andremo a vedere come utilizzare alcuni dei workflows distribuiti che Git offre.
+Ora che avete un repository Git remoto configurato per tutti gli sviluppatore per condividere il proprio codice, e usate comunemente i comandi di base di Git per il tuo lavoro in locale, vedremo come utilizzare alcuni dei flussi di lavoro offerti da Git.
 
-In questo capitolo, vedrete come lavorare con Git in un ambiente distribuito come contributore ed integratore. Imparerai come contribuire in maniera efficiente ad un progetto e rendere semplice la vita al gestore del progetto, oltre a come mantenere un progetto in maniera corretta con un certo numero di sviluppatori che contribuiscono ad esso.
+In questo capitolo, vedremo come lavorare con Git in un ambiente distribuito come contributore e integratore. Imparerai come contribuire in maniera efficiente ad un progetto e rendere la vita al gestore del progetto il più semplice possibile, ma anche come mantenere correttamente un progetto con un certo numero di sviluppatori che vi contribuiscono.
 
 ## Workflows distribuiti ##
 

From a4933d7770d4605f9f7ce0e83fcbebd3801709ff Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Tue, 7 Jan 2014 11:00:54 +0100
Subject: [PATCH 063/690] Reviewed "Distributed Git"

---
 it/05-distributed-git/01-chapter5.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/it/05-distributed-git/01-chapter5.markdown b/it/05-distributed-git/01-chapter5.markdown
index b45ec93f4..ccb4ab1c8 100755
--- a/it/05-distributed-git/01-chapter5.markdown
+++ b/it/05-distributed-git/01-chapter5.markdown
@@ -6,7 +6,7 @@ In questo capitolo, vedremo come lavorare con Git in un ambiente distribuito com
 
 ## Workflows distribuiti ##
 
-A differenza dei gestori di versione centralizzati (CVCSs), la natura distribuita di Git renderà possibile una maggiore flessibilità nel modo in cui gli sviluppatori collaborano nei progetti. Nel sistemi centralizzati, ogni sviluppatore è un nodo che lavora appoggiandosi più o meno ad un fulcro centrale. Con Git invece, ogni sviluppatore è potenzialmente sia un nodo che il fulcro stesso - infatti ogni sviluppatore può fornire del codice agli altri repository e mantenere un pubblico repository sul quale gli altri basano il proprio lavoro e verso il quale contribuiscono. Questo apre ad una vasta gamma di possibilità di workflow per il vostro progetto e/o il vostro team, quindi coprirò alcuni paradigmi che si avvantaggiano di questa flessibilità. Discuterò dei punti di forza e quelli deboli di ogni possibilità; potete usarne una sola, oppure prendere pezzi da diverse ed adattarle alle vostre necessità.
+A differenza dei gestori di versione centralizzati (CVCS), la natura distribuita di Git ti permette di essere più flessibile nel gestire il modo in cui gli sviluppatori collaborano ai progetti. Nel sistemi centralizzati, ogni sviluppatore è un nodo che lavora appoggiandosi ad un nucleo centrale più o meno ugualmente agli altri. Con Git invece, ogni sviluppatore è potenzialmente sia un nodo che un nucleo - infatti ogni sviluppatore può fornire del codice agli altri repository e mantenere un repository pubblico sul quale gli altri basino il proprio lavoro e verso il quale contribuiscano. Questo apre ad una vasta gamma di possibilità di workflow per il vostro progetto e/o il vostro team. Tratterò quindi alcuni paradigmi che sfruttano questa flessibilità. Discuterò i punti di forza e quelli deboli di ogni design. Potrai usarne uno o combinarli per adattarli alle tue necessità.
 
 ### Workflow centralizzato ###
 

From 15f2bf1b9902cd166d7c016a65e1f9242e17b4f2 Mon Sep 17 00:00:00 2001
From: "Helmut K. C. Tessarek" <tessarek@evermeet.cx>
Date: Wed, 8 Jan 2014 02:21:17 -0500
Subject: [PATCH 064/690] fixed error in the imap section

git send-email does not put the patches into an IMAP folder, but the
command git imap-send.
I've changed the command, added the output that occurs when using the
command and wrote a short sentence to make use of the previous output
used in the document. I've also added an example for SMTP config.
---
 en/05-distributed-git/01-chapter5.markdown | 23 +++++++++++++++++++---
 1 file changed, 20 insertions(+), 3 deletions(-)

diff --git a/en/05-distributed-git/01-chapter5.markdown b/en/05-distributed-git/01-chapter5.markdown
index 6bf3e1d49..36fccb013 100644
--- a/en/05-distributed-git/01-chapter5.markdown
+++ b/en/05-distributed-git/01-chapter5.markdown
@@ -532,7 +532,26 @@ First, you need to set up the imap section in your `~/.gitconfig` file. You can
 	  sslverify = false
 
 If your IMAP server doesn’t use SSL, the last two lines probably aren’t necessary, and the host value will be `imap://` instead of `imaps://`.
-When that is set up, you can use `git send-email` to place the patch series in the Drafts folder of the specified IMAP server:
+When that is set up, you can use `git imap-send` to place the patch series in the Drafts folder of the specified IMAP server:
+
+	$ cat *.patch |git imap-send
+	Resolving imap.gmail.com... ok
+	Connecting to [74.125.142.109]:993... ok
+	Logging in...
+	sending 2 messages
+	100% (2/2) done
+
+At this point, you should be able to go to your Drafts folder, change the To field to the mailing list you’re sending the patch to, possibly CC the maintainer or person responsible for that section, and send it off.
+
+You can also send the patches through an SMTP server. As before, you can set each value separately with a series of `git config` commands, or you can add them manually in the sendemail section in your `~/.gitconfig` file:
+
+	[sendemail]
+	  smtpencryption = tls
+	  smtpserver = smtp.gmail.com
+	  smtpuser = user@gmail.com
+	  smtpserverport = 587
+
+After this is done, you can use `git send-email` to send your patches:
 
 	$ git send-email *.patch
 	0001-added-limit-to-log-function.patch
@@ -559,8 +578,6 @@ Then, Git spits out a bunch of log information looking something like this for e
 
 	Result: OK
 
-At this point, you should be able to go to your Drafts folder, change the To field to the mailing list you’re sending the patch to, possibly CC the maintainer or person responsible for that section, and send it off.
-
 ### Summary ###
 
 This section has covered a number of common workflows for dealing with several very different types of Git projects you’re likely to encounter and introduced a couple of new tools to help you manage this process. Next, you’ll see how to work the other side of the coin: maintaining a Git project. You’ll learn how to be a benevolent dictator or integration manager.

From d4919746c7480b74f9e1fa0349dbf01b2293f03c Mon Sep 17 00:00:00 2001
From: rns <ruslan.shvedov@gmail.com>
Date: Thu, 9 Jan 2014 08:53:44 +0200
Subject: [PATCH 065/690] Update 01-chapter4.markdown

---
 ru/04-git-server/01-chapter4.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ru/04-git-server/01-chapter4.markdown b/ru/04-git-server/01-chapter4.markdown
index f578e94e3..825587c58 100644
--- a/ru/04-git-server/01-chapter4.markdown
+++ b/ru/04-git-server/01-chapter4.markdown
@@ -1,6 +1,6 @@
 # Git на сервере #
 
-К этому моменту вы уже должны уметь делать большую часть повседневных задач, для которых вы будете использовать Git. Однако, для совместной работы в Git'е, вам необходим удалённый репозиторий. Несмотря на то, что технически вы можете отправлять и забирать изменения непосредственно из личных репозиториев, делать это не рекомендуется. Вы легко можете испортить то, над чем работают другие, если не будете аккуратны. К тому же, вам бы наверняка хотелось, чтобы остальные имели доступ к репозиторию даже если ваш компьютер выключен, поэтому наличие более надежного репозитория обычно весьма полезно. Поэтому предпочтительный метод взаимодействия с кем-либо — это создание промежуточного репозитория, к которому вы оба будете иметь доступ, и отправка и получение изменений через него. Мы будем называть этот репозиторий "Git-сервер", но обычно размещение Git-репозитория требует очень небольшого количества ресурсов, поэтому вряд ли вам для этого будет нужен весь сервер.
+К этому моменту вы уже должны уметь решать большинство повседневных задач, для которых будете использовать Git. Однако, для совместной работы в Git'е, вам необходим удалённый репозиторий. Несмотря на то, что технически вы можете отправлять и забирать изменения непосредственно из личных репозиториев, делать это не рекомендуется. Вы легко можете испортить то, над чем работают другие, если не будете аккуратны. К тому же, вам бы наверняка хотелось, чтобы остальные имели доступ к репозиторию даже если ваш компьютер выключен, поэтому наличие более надежного репозитория обычно весьма полезно. Поэтому предпочтительный метод взаимодействия с кем-либо — это создание промежуточного репозитория, к которому вы оба будете иметь доступ, и отправка и получение изменений через него. Мы будем называть этот репозиторий "Git-сервер", но обычно размещение Git-репозитория требует очень небольшого количества ресурсов, поэтому вряд ли вам для этого будет нужен весь сервер.
 
 Запустить Git-сервер просто. Для начала вам следует выбрать протокол, который вы будете использовать для связи с сервером. Первая часть этой главы описывает доступные протоколы и их достоинства и недостатки. Следующие части освещают базовые конфигурации с использованием этих протоколов, а также настройку вашего сервера для работы с ними. Наконец, мы рассмотрим несколько вариантов готового хостинга, если вы не против разместить ваш код на чьём-то сервере и вы не хотите мучиться с настройками и поддержкой вашего собственного сервера.
 

From 7b2abbf43f94853069c5be0d01dda22ef0203eca Mon Sep 17 00:00:00 2001
From: Jean-Noel Avila <jean-noel.avila@scantech.fr>
Date: Fri, 10 Jan 2014 09:59:48 +0100
Subject: [PATCH 066/690] fix typo for git daemon export flag file

Spotted by Joseph P. SKUDLAREK. The file name is git-daemon-export-ok
instead of  git-export-daemon-ok.
---
 az/04-git-server/01-chapter4.markdown    | 2 +-
 cs/04-git-server/01-chapter4.markdown    | 2 +-
 de/04-git-server/01-chapter4.markdown    | 2 +-
 en/04-git-server/01-chapter4.markdown    | 2 +-
 es/04-git-server/01-chapter4.markdown    | 2 +-
 fr/04-git-server/01-chapter4.markdown    | 2 +-
 it/04-git-server/01-chapter4.markdown    | 2 +-
 ja/04-git-server/01-chapter4.markdown    | 2 +-
 ko/04-git-server/01-chapter4.markdown    | 2 +-
 nl/04-git-server/01-chapter4.markdown    | 2 +-
 no-nb/04-git-server/01-chapter4.markdown | 2 +-
 pl/04-git-server/01-chapter4.markdown    | 2 +-
 pt-br/04-git-server/01-chapter4.markdown | 2 +-
 ru/04-git-server/01-chapter4.markdown    | 2 +-
 zh/04-git-server/01-chapter4.markdown    | 2 +-
 15 files changed, 15 insertions(+), 15 deletions(-)

diff --git a/az/04-git-server/01-chapter4.markdown b/az/04-git-server/01-chapter4.markdown
index 8733fe40a..db9098f73 100644
--- a/az/04-git-server/01-chapter4.markdown
+++ b/az/04-git-server/01-chapter4.markdown
@@ -70,7 +70,7 @@ The negative aspect of SSH is that you can’t serve anonymous access of your re
 
 ### The Git Protocol ###
 
-Next is the Git protocol. This is a special daemon that comes packaged with Git; it listens on a dedicated port (9418) that provides a service similar to the SSH protocol, but with absolutely no authentication. In order for a repository to be served over the Git protocol, you must create the `git-export-daemon-ok` file — the daemon won’t serve a repository without that file in it — but other than that there is no security. Either the Git repository is available for everyone to clone or it isn’t. This means that there is generally no pushing over this protocol. You can enable push access; but given the lack of authentication, if you turn on push access, anyone on the internet who finds your project’s URL could push to your project. Suffice it to say that this is rare.
+Next is the Git protocol. This is a special daemon that comes packaged with Git; it listens on a dedicated port (9418) that provides a service similar to the SSH protocol, but with absolutely no authentication. In order for a repository to be served over the Git protocol, you must create the `git-deamon-export-ok` file — the daemon won’t serve a repository without that file in it — but other than that there is no security. Either the Git repository is available for everyone to clone or it isn’t. This means that there is generally no pushing over this protocol. You can enable push access; but given the lack of authentication, if you turn on push access, anyone on the internet who finds your project’s URL could push to your project. Suffice it to say that this is rare.
 
 #### The Pros ####
 
diff --git a/cs/04-git-server/01-chapter4.markdown b/cs/04-git-server/01-chapter4.markdown
index 746caa912..a6100408a 100644
--- a/cs/04-git-server/01-chapter4.markdown
+++ b/cs/04-git-server/01-chapter4.markdown
@@ -70,7 +70,7 @@ Nevýhodou protokolu SSH je, že neumožňuje anonymní přístup do repozitář
 
 ### Protokol Git ###
 
-Dalším protokolem v pořadí je protokol Git. Je to speciální démon, který je distribuován spolu se systémem Git. Naslouchá na vyhrazeném portu (9418) a poskytuje podobnou službu jako protokol SSH, avšak bez jakéhokoli ověřování. Chcete-li, aby byl repozitář obsluhován protokolem Git, musíte vytvořit soubor `git-export-daemon-ok` – démon nebude repozitář obsluhovat, dokud v něm tento soubor nebude. Žádné jiné zabezpečení k dispozici není. Repozitář Git je buď dostupný pro všechny a všichni z něj mohou klonovat, nebo dostupný není. To znamená, že se přes tento protokol nedají odesílat žádné revize. Možnost odesílání lze aktivovat, ale vzhledem k tomu, že protokol neumožňuje ověřování, aktivované odesílání znamená, že kdokoli na internetu, kdo najde URL vašeho projektu, do něj bude moci odesílat data. Tato možnost se však téměř nepoužívá.
+Dalším protokolem v pořadí je protokol Git. Je to speciální démon, který je distribuován spolu se systémem Git. Naslouchá na vyhrazeném portu (9418) a poskytuje podobnou službu jako protokol SSH, avšak bez jakéhokoli ověřování. Chcete-li, aby byl repozitář obsluhován protokolem Git, musíte vytvořit soubor `git-deamon-export-ok` – démon nebude repozitář obsluhovat, dokud v něm tento soubor nebude. Žádné jiné zabezpečení k dispozici není. Repozitář Git je buď dostupný pro všechny a všichni z něj mohou klonovat, nebo dostupný není. To znamená, že se přes tento protokol nedají odesílat žádné revize. Možnost odesílání lze aktivovat, ale vzhledem k tomu, že protokol neumožňuje ověřování, aktivované odesílání znamená, že kdokoli na internetu, kdo najde URL vašeho projektu, do něj bude moci odesílat data. Tato možnost se však téměř nepoužívá.
 
 #### Výhody ####
 
diff --git a/de/04-git-server/01-chapter4.markdown b/de/04-git-server/01-chapter4.markdown
index d78f410e4..2af95673d 100644
--- a/de/04-git-server/01-chapter4.markdown
+++ b/de/04-git-server/01-chapter4.markdown
@@ -123,7 +123,7 @@ Die negative Seite von SSH ist, dass Du Deine Repositories nicht anonym darüber
 <!--### The Git Protocol ###-->
 ### Das Git Protokoll ###
 
-<!--Next is the Git protocol. This is a special daemon that comes packaged with Git; it listens on a dedicated port (9418) that provides a service similar to the SSH protocol, but with absolutely no authentication. In order for a repository to be served over the Git protocol, you must create the `git-export-daemon-ok` file — the daemon won’t serve a repository without that file in it — but other than that there is no security. Either the Git repository is available for everyone to clone or it isn’t. This means that there is generally no pushing over this protocol. You can enable push access; but given the lack of authentication, if you turn on push access, anyone on the internet who finds your project’s URL could push to your project. Suffice it to say that this is rare.-->
+<!--Next is the Git protocol. This is a special daemon that comes packaged with Git; it listens on a dedicated port (9418) that provides a service similar to the SSH protocol, but with absolutely no authentication. In order for a repository to be served over the Git protocol, you must create the `git-deamon-export-ok` file — the daemon won’t serve a repository without that file in it — but other than that there is no security. Either the Git repository is available for everyone to clone or it isn’t. This means that there is generally no pushing over this protocol. You can enable push access; but given the lack of authentication, if you turn on push access, anyone on the internet who finds your project’s URL could push to your project. Suffice it to say that this is rare.-->
 
 Als nächstes kommt das Git Protokoll. Das ist ein spezieller Dämon, der zusammen mit Git kommt. Er horcht auf einem bestimmten Port (9418), dieser Service ist vergleichbar mit dem SSH-Protokoll, aber ohne jegliche Authentifizierung. Um ein Repository über das Git Protokoll, musst Du die `gitk-export-daemon-ok` Datei erstellen – der Dämon bietet kein Repository ohne die Datei darin an – außer dieser Datei gibt es keine Sicherheit. Entweder das Git Repository ist für jeden zum Clonen verfügbar oder halt nicht. Das bedeutet, dass dieses Protokoll generell kein push anbietet. Du kannst push-Zugriff aktivieren; aber ohne Authentifizierung, wenn Du den push-Zugriff aktivierst, kann jeder im Internet, der Deine Projekt-URL findet, zu Deinem Projekt pushen. Ausreichend zu sagen, dass das selten ist.
 
diff --git a/en/04-git-server/01-chapter4.markdown b/en/04-git-server/01-chapter4.markdown
index ec3f415a4..fda0fb87f 100644
--- a/en/04-git-server/01-chapter4.markdown
+++ b/en/04-git-server/01-chapter4.markdown
@@ -70,7 +70,7 @@ The negative aspect of SSH is that you can’t serve anonymous access of your re
 
 ### The Git Protocol ###
 
-Next is the Git protocol. This is a special daemon that comes packaged with Git; it listens on a dedicated port (9418) that provides a service similar to the SSH protocol, but with absolutely no authentication. In order for a repository to be served over the Git protocol, you must create the `git-export-daemon-ok` file — the daemon won’t serve a repository without that file in it — but other than that there is no security. Either the Git repository is available for everyone to clone or it isn’t. This means that there is generally no pushing over this protocol. You can enable push access; but given the lack of authentication, if you turn on push access, anyone on the internet who finds your project’s URL could push to your project. Suffice it to say that this is rare.
+Next is the Git protocol. This is a special daemon that comes packaged with Git; it listens on a dedicated port (9418) that provides a service similar to the SSH protocol, but with absolutely no authentication. In order for a repository to be served over the Git protocol, you must create the `git-deamon-export-ok` file — the daemon won’t serve a repository without that file in it — but other than that there is no security. Either the Git repository is available for everyone to clone or it isn’t. This means that there is generally no pushing over this protocol. You can enable push access; but given the lack of authentication, if you turn on push access, anyone on the internet who finds your project’s URL could push to your project. Suffice it to say that this is rare.
 
 #### The Pros ####
 
diff --git a/es/04-git-server/01-chapter4.markdown b/es/04-git-server/01-chapter4.markdown
index 4cc8612a3..7efaf3963 100755
--- a/es/04-git-server/01-chapter4.markdown
+++ b/es/04-git-server/01-chapter4.markdown
@@ -68,7 +68,7 @@ El aspecto negativo de SSH es su imposibilidad para dar acceso anónimo al repos
 
 ### El Protocolo Git ###
 
-El protocolo Git  es un demonio (daemon) especial, que viene incorporado con Git. Escucha por un puerto dedicado (9418), y nos da un servicio similar al del protocolo SSH; pero sin ningún tipo de autentificación. Para que un repositorio pueda exponerse a través del protocolo Git, tienes que crear en él un archivo 'git-export-daemon-ok'; sin este archivo, el demonio no hará disponible el repositorio. Pero, aparte de esto, no hay ninguna otra medida de seguridad. O el repositorio está disponible para que cualquiera lo pueda clonar, o no lo está. Lo cual significa que, normalmente, no se podrá enviar (push) a través de este protocolo. Aunque realmente si que puedes habilitar el envio, si lo haces, dada la total falta de ningún mecanismo de autentificación, cualquiera que encuentre la URL a tu proyecto en Internet, podrá enviar (push) contenidos a él. Ni que decir tiene que esto solo lo necesitarás en contadas ocasiones.
+El protocolo Git  es un demonio (daemon) especial, que viene incorporado con Git. Escucha por un puerto dedicado (9418), y nos da un servicio similar al del protocolo SSH; pero sin ningún tipo de autentificación. Para que un repositorio pueda exponerse a través del protocolo Git, tienes que crear en él un archivo 'git-deamon-export-ok'; sin este archivo, el demonio no hará disponible el repositorio. Pero, aparte de esto, no hay ninguna otra medida de seguridad. O el repositorio está disponible para que cualquiera lo pueda clonar, o no lo está. Lo cual significa que, normalmente, no se podrá enviar (push) a través de este protocolo. Aunque realmente si que puedes habilitar el envio, si lo haces, dada la total falta de ningún mecanismo de autentificación, cualquiera que encuentre la URL a tu proyecto en Internet, podrá enviar (push) contenidos a él. Ni que decir tiene que esto solo lo necesitarás en contadas ocasiones.
 
 ### Ventajas ###
 
diff --git a/fr/04-git-server/01-chapter4.markdown b/fr/04-git-server/01-chapter4.markdown
index 0ecbaf05f..723879107 100644
--- a/fr/04-git-server/01-chapter4.markdown
+++ b/fr/04-git-server/01-chapter4.markdown
@@ -109,7 +109,7 @@ Si vous souhaitez proposer de l'accès anonyme en lecture seule à vos projets,
 ### Protocole Git ###
 
 Vient ensuite le protocole Git. Celui-ci est géré par un *daemon* spécial livré avec Git. Ce *daemon* (démon, processus en arrière plan) écoute sur un port dédié (9418) et propose un service similaire au protocole SSH, mais sans aucune sécurisation.
-Pour qu'un dépôt soit publié via le protocole Git, le fichier `git-export-daemon-ok` doit exister mais mise à part cette condition sans laquelle le *daemon* refuse de publier un projet, il n'y a aucune sécurité.
+Pour qu'un dépôt soit publié via le protocole Git, le fichier `git-deamon-export-ok` doit exister mais mise à part cette condition sans laquelle le *daemon* refuse de publier un projet, il n'y a aucune sécurité.
 Soit le dépôt Git est disponible sans restriction en lecture, soit il n'est pas publié.
 Cela signifie qu'il ne permet pas de pousser des modifications.
 Vous pouvez activer la capacité à pousser mais étant donné l'absence d'authentification, n'importe qui sur Internet ayant trouvé l'URL du projet peut pousser sur le dépôt.
diff --git a/it/04-git-server/01-chapter4.markdown b/it/04-git-server/01-chapter4.markdown
index af62c8b8a..40e2c112a 100644
--- a/it/04-git-server/01-chapter4.markdown
+++ b/it/04-git-server/01-chapter4.markdown
@@ -70,7 +70,7 @@ L'aspetto negativo di SSH è che non puoi dare accesso anonimo al tuo repository
 
 ### Il Protocollo Git ###
 
-Poi c'è il protocollo Git. Questo è un demone speciale che è incluso nel pacchetto Git; è in ascolto su una porta dedicata (9418) e fornisce un servizio simile al protocollo SSH, ma assolutamente senza autenticazione. Per permettere ad un repository di essere servito tramite il protocollo Git, devi creare un file `git-export-daemon-ok` — il demone non serve il repository senza l'inserimento di questo file — altrimenti non ci sarebbe sicurezza. O il repository Git è disponibile per chiunque voglia copiarlo o altrimenti niente. Questo significa che generalmente non si invia tramite questo protocollo. Puoi abilitare l'accesso all'invio; ma data la mancanza di autenticazione, se abiliti l'accesso di scrittura, chiunque trovi su internet l'URL al progetto può inviare dati. Basti dire che questo è raro.
+Poi c'è il protocollo Git. Questo è un demone speciale che è incluso nel pacchetto Git; è in ascolto su una porta dedicata (9418) e fornisce un servizio simile al protocollo SSH, ma assolutamente senza autenticazione. Per permettere ad un repository di essere servito tramite il protocollo Git, devi creare un file `git-deamon-export-ok` — il demone non serve il repository senza l'inserimento di questo file — altrimenti non ci sarebbe sicurezza. O il repository Git è disponibile per chiunque voglia copiarlo o altrimenti niente. Questo significa che generalmente non si invia tramite questo protocollo. Puoi abilitare l'accesso all'invio; ma data la mancanza di autenticazione, se abiliti l'accesso di scrittura, chiunque trovi su internet l'URL al progetto può inviare dati. Basti dire che questo è raro.
 
 #### I Pro ####
 
diff --git a/ja/04-git-server/01-chapter4.markdown b/ja/04-git-server/01-chapter4.markdown
index 07ac3a33b..33b34b8f2 100644
--- a/ja/04-git-server/01-chapter4.markdown
+++ b/ja/04-git-server/01-chapter4.markdown
@@ -70,7 +70,7 @@ SSH の欠点は、リポジトリへの匿名アクセスを許可できない
 
 ### Git プロトコル ###
 
-次は Git プロトコルです。これは Git に標準で付属する特別なデーモンです。専用のポート (9418) をリスンし、SSH プロトコルと同様のサービスを提供しますが、認証は行いません。Git プロトコルを提供するリポジトリを準備するには、`git-export-daemon-ok` というファイルを作らなければなりません (このファイルがなければデーモンはサービスを提供しません)。ただ、このままでは一切セキュリティはありません。Git リポジトリをすべての人に開放し、クローンさせることができます。しかし、一般に、このプロトコルでプッシュさせることはありません。プッシュアクセスを認めることは可能です。しかし認証がないということは、その URL を知ってさえいればインターネット上の誰もがプロジェクトにプッシュできるということになります。これはありえない話だと言っても差し支えないでしょう。
+次は Git プロトコルです。これは Git に標準で付属する特別なデーモンです。専用のポート (9418) をリスンし、SSH プロトコルと同様のサービスを提供しますが、認証は行いません。Git プロトコルを提供するリポジトリを準備するには、`git-deamon-export-ok` というファイルを作らなければなりません (このファイルがなければデーモンはサービスを提供しません)。ただ、このままでは一切セキュリティはありません。Git リポジトリをすべての人に開放し、クローンさせることができます。しかし、一般に、このプロトコルでプッシュさせることはありません。プッシュアクセスを認めることは可能です。しかし認証がないということは、その URL を知ってさえいればインターネット上の誰もがプロジェクトにプッシュできるということになります。これはありえない話だと言っても差し支えないでしょう。
 
 #### 利点 ####
 
diff --git a/ko/04-git-server/01-chapter4.markdown b/ko/04-git-server/01-chapter4.markdown
index 043d5be67..0083ec87c 100644
--- a/ko/04-git-server/01-chapter4.markdown
+++ b/ko/04-git-server/01-chapter4.markdown
@@ -70,7 +70,7 @@ SSH의 단점은 익명으로 접근할 수 없다는 것이다. 심지어 읽
 
 ### Git 프로토콜 ###
 
-Git 프로토콜은 Git에 포함된 데몬을 사용하는 방법이다. 포트는 9418이며 SSH 프로토콜과 비슷한 서비스를 제공하지만, 인증 메커니즘이 없다. 저장소에 git-export-daemon-ok 파일을 만들면 Git 프로토콜로 서비스할 수 있지만, 보안은 없다. 이 파일이 없는 저장소는 Git 프로토콜로 서비스할 수 없다. 이 저장소는 누구나 Clone할 수 있거나 아무도 Clone할 수 없거나 둘 중의 하나만 선택할 수 있다. 그래서 이 프로토콜로는 Push 가능하게 설정할 수 없다. 엄밀히 말해서 Push할 수 있도록 설정할 수 있지만, 인증하도록 할 수 없다. 그러니까 당신이 Push할 수 있으면 이 프로젝트의 URL을 아는 사람은 누구나 Push할 수 있다. 그냥 이런 것도 있지만 잘 안 쓴다고 알고 있으면 된다.
+Git 프로토콜은 Git에 포함된 데몬을 사용하는 방법이다. 포트는 9418이며 SSH 프로토콜과 비슷한 서비스를 제공하지만, 인증 메커니즘이 없다. 저장소에 git-deamon-export-ok 파일을 만들면 Git 프로토콜로 서비스할 수 있지만, 보안은 없다. 이 파일이 없는 저장소는 Git 프로토콜로 서비스할 수 없다. 이 저장소는 누구나 Clone할 수 있거나 아무도 Clone할 수 없거나 둘 중의 하나만 선택할 수 있다. 그래서 이 프로토콜로는 Push 가능하게 설정할 수 없다. 엄밀히 말해서 Push할 수 있도록 설정할 수 있지만, 인증하도록 할 수 없다. 그러니까 당신이 Push할 수 있으면 이 프로젝트의 URL을 아는 사람은 누구나 Push할 수 있다. 그냥 이런 것도 있지만 잘 안 쓴다고 알고 있으면 된다.
 
 #### 장점 ####
 
diff --git a/nl/04-git-server/01-chapter4.markdown b/nl/04-git-server/01-chapter4.markdown
index 9d4ff89c3..47c01c78e 100644
--- a/nl/04-git-server/01-chapter4.markdown
+++ b/nl/04-git-server/01-chapter4.markdown
@@ -70,7 +70,7 @@ Het negatieve aspect van SSH is dat je er geen anonieme toegang over kunt geven.
 
 ### Het Git protocol ###
 
-Het volgende is het Git protocol. Dit is een aparte daemon, die samen met Git geleverd wordt; het luistert op een toegewezen poort (9418), dat een vergelijkbare dienst verleend als het SSH protocol, maar dan zonder enige authenticatie. Om een repository te serveren over het Git protocol, moet je het `git-export-daemon-ok` bestand aanmaken — de daemon zal een repository zonder dit bestand erin niet serveren — maar buiten dat is er geen beveiliging. Ofwel het Git repository kan door iedereen gekloond worden, of helemaal niet. Dit betekent dat over het algemeen pushen niet mogelijk is via dit protocol. Je kunt push toegang aanzetten; maar gegeven het gebrek aan toegangscontrole als je push toegang aan zet, kan iedereen die de URL van jouw project op het internet vindt, pushen naar jouw project. We volstaan met te zeggen dat dit zeldzaam is.
+Het volgende is het Git protocol. Dit is een aparte daemon, die samen met Git geleverd wordt; het luistert op een toegewezen poort (9418), dat een vergelijkbare dienst verleend als het SSH protocol, maar dan zonder enige authenticatie. Om een repository te serveren over het Git protocol, moet je het `git-deamon-export-ok` bestand aanmaken — de daemon zal een repository zonder dit bestand erin niet serveren — maar buiten dat is er geen beveiliging. Ofwel het Git repository kan door iedereen gekloond worden, of helemaal niet. Dit betekent dat over het algemeen pushen niet mogelijk is via dit protocol. Je kunt push toegang aanzetten; maar gegeven het gebrek aan toegangscontrole als je push toegang aan zet, kan iedereen die de URL van jouw project op het internet vindt, pushen naar jouw project. We volstaan met te zeggen dat dit zeldzaam is.
 
 #### De voordelen ####
 
diff --git a/no-nb/04-git-server/01-chapter4.markdown b/no-nb/04-git-server/01-chapter4.markdown
index f3172e638..29d33bd57 100644
--- a/no-nb/04-git-server/01-chapter4.markdown
+++ b/no-nb/04-git-server/01-chapter4.markdown
@@ -70,7 +70,7 @@ The negative aspect of SSH is that you can’t serve anonymous access of your re
 
 ### The Git Protocol ###
 
-Next is the Git protocol. This is a special daemon that comes packaged with Git; it listens on a dedicated port (9418) that provides a service similar to the SSH protocol, but with absolutely no authentication. In order for a repository to be served over the Git protocol, you must create the `git-export-daemon-ok` file — the daemon won’t serve a repository without that file in it — but other than that there is no security. Either the Git repository is available for everyone to clone or it isn’t. This means that there is generally no pushing over this protocol. You can enable push access; but given the lack of authentication, if you turn on push access, anyone on the internet who finds your project’s URL could push to your project. Suffice it to say that this is rare.
+Next is the Git protocol. This is a special daemon that comes packaged with Git; it listens on a dedicated port (9418) that provides a service similar to the SSH protocol, but with absolutely no authentication. In order for a repository to be served over the Git protocol, you must create the `git-deamon-export-ok` file — the daemon won’t serve a repository without that file in it — but other than that there is no security. Either the Git repository is available for everyone to clone or it isn’t. This means that there is generally no pushing over this protocol. You can enable push access; but given the lack of authentication, if you turn on push access, anyone on the internet who finds your project’s URL could push to your project. Suffice it to say that this is rare.
 
 #### The Pros ####
 
diff --git a/pl/04-git-server/01-chapter4.markdown b/pl/04-git-server/01-chapter4.markdown
index 0c2d4227c..08e95b3d7 100644
--- a/pl/04-git-server/01-chapter4.markdown
+++ b/pl/04-git-server/01-chapter4.markdown
@@ -70,7 +70,7 @@ Wadą dostępu po SSH jest to, że nie istnieje dostęp anonimowy do repozytoriu
 
 ### Protokół Git ###
 
-Następnie mamy protokół Git. To specjalny rodzaj procesu demona, który dostępny jest w pakiecie z Gitem; słucha na dedykowanym porcie (9418) i udostępnia usługi podobne do protokołu SSH, ale całkowicie bez obsługi uwierzytelnienia. Aby repozytorium mogło być udostępnione po protokole Git konieczne jest utworzenie pliku `git-export-daemon-ok` - bez niego demon nie udostępni repozytorium - ale to jedyne zabezpieczenie. Albo wszyscy mogą klonować dane repozytorium, albo nikt. Generalnie oznacza to że nie można pchać zmian po tym protokole. Można włączyć taką możliwość; ale biorąc pod uwagę brak mechanizmów uwierzytelniania, jeśli włączysz możliwość zapisu, każdy w Internecie, kto odkryje adres Twojego projektu może pchać do niego zmiany. Wystarczy powiedzieć, że nie spotyka się często takich sytuacji.
+Następnie mamy protokół Git. To specjalny rodzaj procesu demona, który dostępny jest w pakiecie z Gitem; słucha na dedykowanym porcie (9418) i udostępnia usługi podobne do protokołu SSH, ale całkowicie bez obsługi uwierzytelnienia. Aby repozytorium mogło być udostępnione po protokole Git konieczne jest utworzenie pliku `git-deamon-export-ok` - bez niego demon nie udostępni repozytorium - ale to jedyne zabezpieczenie. Albo wszyscy mogą klonować dane repozytorium, albo nikt. Generalnie oznacza to że nie można pchać zmian po tym protokole. Można włączyć taką możliwość; ale biorąc pod uwagę brak mechanizmów uwierzytelniania, jeśli włączysz możliwość zapisu, każdy w Internecie, kto odkryje adres Twojego projektu może pchać do niego zmiany. Wystarczy powiedzieć, że nie spotyka się często takich sytuacji.
 
 #### Zalety ####
 
diff --git a/pt-br/04-git-server/01-chapter4.markdown b/pt-br/04-git-server/01-chapter4.markdown
index 505ed24ff..9411c3f06 100644
--- a/pt-br/04-git-server/01-chapter4.markdown
+++ b/pt-br/04-git-server/01-chapter4.markdown
@@ -70,7 +70,7 @@ O aspecto negativo do SSH é que você não pode permitir acesso anônimo do seu
 
 ### O Protocolo Git ###
 
-O próximo é o protocolo Git. Este é um daemon especial que vem no mesmo pacote que o Git; ele escuta em uma porta dedicada (9418) que provê um serviço similar ao do protocolo SSH, mas absolutamente sem nenhuma autenticação. Para que um repositório seja disponibilizado via protocolo Git, você tem que criar o arquivo `git-export-daemon-ok` — o daemon não disponibilizará um repositório sem este arquivo dentro — mas além disso não há nenhuma segurança. Ou o repositório Git está disponível para todos clonarem ou não. Isto significa que geralmente não existe envio (push) sobre este protocolo. Você pode habilitar o acesso a envio; mas dada a falta de autenticação, se você ativar o acesso de envio, qualquer um na internet que encontre a URL do seu projeto poderia enviar (push) para o seu projeto. É suficiente dizer que isto é raro.
+O próximo é o protocolo Git. Este é um daemon especial que vem no mesmo pacote que o Git; ele escuta em uma porta dedicada (9418) que provê um serviço similar ao do protocolo SSH, mas absolutamente sem nenhuma autenticação. Para que um repositório seja disponibilizado via protocolo Git, você tem que criar o arquivo `git-deamon-export-ok` — o daemon não disponibilizará um repositório sem este arquivo dentro — mas além disso não há nenhuma segurança. Ou o repositório Git está disponível para todos clonarem ou não. Isto significa que geralmente não existe envio (push) sobre este protocolo. Você pode habilitar o acesso a envio; mas dada a falta de autenticação, se você ativar o acesso de envio, qualquer um na internet que encontre a URL do seu projeto poderia enviar (push) para o seu projeto. É suficiente dizer que isto é raro.
 
 #### Os Prós ####
 
diff --git a/ru/04-git-server/01-chapter4.markdown b/ru/04-git-server/01-chapter4.markdown
index f578e94e3..cfb52a42e 100644
--- a/ru/04-git-server/01-chapter4.markdown
+++ b/ru/04-git-server/01-chapter4.markdown
@@ -70,7 +70,7 @@ SSH имеет множество достоинств. Во-первых, вы,
 
 ### Git-протокол ###
 
-Следующий протокол — Git-протокол. Вместе с Git'ом поставляется специальный демон, который слушает порт 9418 и предоставляет сервис, схожий с протоколом ssh, но абсолютно без аутентификации. Чтобы использовать Git-протокол для репозитория, вы должны создать файл `git-export-daemon-ok`, иначе демон не будет работать с этим репозиторием, но следует помнить, что в протоколе отсутствуют средства безопасности. Соответственно, любой репозиторий в Git'е может быть либо доступен для клонирования всем, либо не доступен никому. Как следствие, обычно вы не можете отправлять изменения по этому протоколу. Вы можете открыть доступ на запись, но из-за отсутствия авторизации в этом случае кто угодно, зная URL вашего проекта, сможет его изменить. В общем, это редко используемая возможность.
+Следующий протокол — Git-протокол. Вместе с Git'ом поставляется специальный демон, который слушает порт 9418 и предоставляет сервис, схожий с протоколом ssh, но абсолютно без аутентификации. Чтобы использовать Git-протокол для репозитория, вы должны создать файл `git-deamon-export-ok`, иначе демон не будет работать с этим репозиторием, но следует помнить, что в протоколе отсутствуют средства безопасности. Соответственно, любой репозиторий в Git'е может быть либо доступен для клонирования всем, либо не доступен никому. Как следствие, обычно вы не можете отправлять изменения по этому протоколу. Вы можете открыть доступ на запись, но из-за отсутствия авторизации в этом случае кто угодно, зная URL вашего проекта, сможет его изменить. В общем, это редко используемая возможность.
 
 #### Достоинства ####
 
diff --git a/zh/04-git-server/01-chapter4.markdown b/zh/04-git-server/01-chapter4.markdown
index d938f2631..514b1a3f6 100644
--- a/zh/04-git-server/01-chapter4.markdown
+++ b/zh/04-git-server/01-chapter4.markdown
@@ -70,7 +70,7 @@ SSH 的限制在于你不能通过它实现仓库的匿名访问。即使仅为
 
 ### Git 协议 ###
 
-接下来是 Git 协议。这是一个包含在 Git 软件包中的特殊守护进程； 它会监听一个提供类似于 SSH 服务的特定端口（9418），而无需任何授权。打算支持 Git 协议的仓库，需要先创建 `git-export-daemon-ok` 文件 — 它是协议进程提供仓库服务的必要条件 — 但除此之外该服务没有什么安全措施。要么所有人都能克隆 Git 仓库，要么谁也不能。这也意味着该协议通常不能用来进行推送。你可以允许推送操作；然而由于没有授权机制，一旦允许该操作，网络上任何一个知道项目 URL 的人将都有推送权限。不用说，这是十分罕见的情况。
+接下来是 Git 协议。这是一个包含在 Git 软件包中的特殊守护进程； 它会监听一个提供类似于 SSH 服务的特定端口（9418），而无需任何授权。打算支持 Git 协议的仓库，需要先创建 `git-deamon-export-ok` 文件 — 它是协议进程提供仓库服务的必要条件 — 但除此之外该服务没有什么安全措施。要么所有人都能克隆 Git 仓库，要么谁也不能。这也意味着该协议通常不能用来进行推送。你可以允许推送操作；然而由于没有授权机制，一旦允许该操作，网络上任何一个知道项目 URL 的人将都有推送权限。不用说，这是十分罕见的情况。
 
 #### 优点 ####
 

From 491d4de84074db63233caabcd0e672bec14f7d7b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Damian=20F=C3=BCrbach?= <atrono@web.de>
Date: Fri, 10 Jan 2014 12:09:48 +0100
Subject: [PATCH 067/690] Update 01-chapter1.markdown

forget an letter
---
 de/01-introduction/01-chapter1.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/de/01-introduction/01-chapter1.markdown b/de/01-introduction/01-chapter1.markdown
index 3c95fcbb9..a86cec03a 100644
--- a/de/01-introduction/01-chapter1.markdown
+++ b/de/01-introduction/01-chapter1.markdown
@@ -54,7 +54,7 @@ Dieser Aufbau hat viele Vorteile gegenüber Lokalen Versionskontrollsystemen. Zu
 
 <!--However, this setup also has some serious downsides. The most obvious is the single point of failure that the centralized server represents. If that server goes down for an hour, then during that hour nobody can collaborate at all or save versioned changes to anything they’re working on. If the hard disk the central database is on becomes corrupted, and proper backups haven’t been kept, you lose absolutely everything—the entire history of the project except whatever single snapshots people happen to have on their local machines. Local VCS systems suffer from this same problem—whenever you have the entire history of the project in a single place, you risk losing everything.-->
 
-Allerdings hat dieser Aufbau auch einige erhebliche Nachteile. Der offensichtlichste Nachteil ist der „Single Point of Failure“, den der zentralisierte Server darstellt. Wenn dieser Server für nur eine Stunde nicht verfügbar ist, dann kann in dieser Stunde niemand in irgendeiner Form mit anderen arbeiten oder versionierte Änderungen an den Dateien speichern, an denen sie momentan arbeiten. Wenn die auf dem zentralen Server verwendete Festplatte beschädigt wird und keine Sicherheitskopien erstellt wurden, dann sind all diese Daten unwiederbringlich verloren – die komplette Historie des Projektes, abgesehen natürlich von dem jeweiligen Zustand, den Mitarbeiter gerade zufällig auf ihrem Rechner haben. Lokale Versionskontrollsysteme haben natürlich dasselbe Problem: wenn man die Historie eines Projektes an einer einzigen, zentralen Stelle verwaltet, riskiert man, sie vollständig zu verlieren, wenn irgendetwas an dieser zentralen Stelle ersthaft schief läuft.
+Allerdings hat dieser Aufbau auch einige erhebliche Nachteile. Der offensichtlichste Nachteil ist der „Single Point of Failure“, den der zentralisierte Server darstellt. Wenn dieser Server für nur eine Stunde nicht verfügbar ist, dann kann in dieser Stunde niemand in irgendeiner Form mit anderen arbeiten oder versionierte Änderungen an den Dateien speichern, an denen sie momentan arbeiten. Wenn die auf dem zentralen Server verwendete Festplatte beschädigt wird und keine Sicherheitskopien erstellt wurden, dann sind all diese Daten unwiederbringlich verloren – die komplette Historie des Projektes, abgesehen natürlich von dem jeweiligen Zustand, den Mitarbeiter gerade zufällig auf ihrem Rechner haben. Lokale Versionskontrollsysteme haben natürlich dasselbe Problem: wenn man die Historie eines Projektes an einer einzigen, zentralen Stelle verwaltet, riskiert man, sie vollständig zu verlieren, wenn irgendetwas an dieser zentralen Stelle ernsthaft schief läuft.
 
 <!--### Distributed Version Control Systems ###-->
 ### Verteilte Versionskontrollsysteme ###

From b0eb6d98b92e68f122770db97176fca76c3a0179 Mon Sep 17 00:00:00 2001
From: Jean-Noel Avila <jean-noel.avila@scantech.fr>
Date: Fri, 10 Jan 2014 12:16:51 +0100
Subject: [PATCH 068/690] Fix typo on git-daemon-export-ok

It's daemon, not deamon, dammit!
---
 az/04-git-server/01-chapter4.markdown    | 2 +-
 cs/04-git-server/01-chapter4.markdown    | 2 +-
 de/04-git-server/01-chapter4.markdown    | 4 ++--
 en/04-git-server/01-chapter4.markdown    | 2 +-
 es/04-git-server/01-chapter4.markdown    | 2 +-
 fr/04-git-server/01-chapter4.markdown    | 2 +-
 it/04-git-server/01-chapter4.markdown    | 2 +-
 ja/04-git-server/01-chapter4.markdown    | 2 +-
 ko/04-git-server/01-chapter4.markdown    | 2 +-
 nl/04-git-server/01-chapter4.markdown    | 2 +-
 no-nb/04-git-server/01-chapter4.markdown | 2 +-
 pl/04-git-server/01-chapter4.markdown    | 2 +-
 pt-br/04-git-server/01-chapter4.markdown | 2 +-
 ru/04-git-server/01-chapter4.markdown    | 2 +-
 zh/04-git-server/01-chapter4.markdown    | 2 +-
 15 files changed, 16 insertions(+), 16 deletions(-)

diff --git a/az/04-git-server/01-chapter4.markdown b/az/04-git-server/01-chapter4.markdown
index db9098f73..c631fb0f6 100644
--- a/az/04-git-server/01-chapter4.markdown
+++ b/az/04-git-server/01-chapter4.markdown
@@ -70,7 +70,7 @@ The negative aspect of SSH is that you can’t serve anonymous access of your re
 
 ### The Git Protocol ###
 
-Next is the Git protocol. This is a special daemon that comes packaged with Git; it listens on a dedicated port (9418) that provides a service similar to the SSH protocol, but with absolutely no authentication. In order for a repository to be served over the Git protocol, you must create the `git-deamon-export-ok` file — the daemon won’t serve a repository without that file in it — but other than that there is no security. Either the Git repository is available for everyone to clone or it isn’t. This means that there is generally no pushing over this protocol. You can enable push access; but given the lack of authentication, if you turn on push access, anyone on the internet who finds your project’s URL could push to your project. Suffice it to say that this is rare.
+Next is the Git protocol. This is a special daemon that comes packaged with Git; it listens on a dedicated port (9418) that provides a service similar to the SSH protocol, but with absolutely no authentication. In order for a repository to be served over the Git protocol, you must create the `git-daemon-export-ok` file — the daemon won’t serve a repository without that file in it — but other than that there is no security. Either the Git repository is available for everyone to clone or it isn’t. This means that there is generally no pushing over this protocol. You can enable push access; but given the lack of authentication, if you turn on push access, anyone on the internet who finds your project’s URL could push to your project. Suffice it to say that this is rare.
 
 #### The Pros ####
 
diff --git a/cs/04-git-server/01-chapter4.markdown b/cs/04-git-server/01-chapter4.markdown
index a6100408a..4f06a9e58 100644
--- a/cs/04-git-server/01-chapter4.markdown
+++ b/cs/04-git-server/01-chapter4.markdown
@@ -70,7 +70,7 @@ Nevýhodou protokolu SSH je, že neumožňuje anonymní přístup do repozitář
 
 ### Protokol Git ###
 
-Dalším protokolem v pořadí je protokol Git. Je to speciální démon, který je distribuován spolu se systémem Git. Naslouchá na vyhrazeném portu (9418) a poskytuje podobnou službu jako protokol SSH, avšak bez jakéhokoli ověřování. Chcete-li, aby byl repozitář obsluhován protokolem Git, musíte vytvořit soubor `git-deamon-export-ok` – démon nebude repozitář obsluhovat, dokud v něm tento soubor nebude. Žádné jiné zabezpečení k dispozici není. Repozitář Git je buď dostupný pro všechny a všichni z něj mohou klonovat, nebo dostupný není. To znamená, že se přes tento protokol nedají odesílat žádné revize. Možnost odesílání lze aktivovat, ale vzhledem k tomu, že protokol neumožňuje ověřování, aktivované odesílání znamená, že kdokoli na internetu, kdo najde URL vašeho projektu, do něj bude moci odesílat data. Tato možnost se však téměř nepoužívá.
+Dalším protokolem v pořadí je protokol Git. Je to speciální démon, který je distribuován spolu se systémem Git. Naslouchá na vyhrazeném portu (9418) a poskytuje podobnou službu jako protokol SSH, avšak bez jakéhokoli ověřování. Chcete-li, aby byl repozitář obsluhován protokolem Git, musíte vytvořit soubor `git-daemon-export-ok` – démon nebude repozitář obsluhovat, dokud v něm tento soubor nebude. Žádné jiné zabezpečení k dispozici není. Repozitář Git je buď dostupný pro všechny a všichni z něj mohou klonovat, nebo dostupný není. To znamená, že se přes tento protokol nedají odesílat žádné revize. Možnost odesílání lze aktivovat, ale vzhledem k tomu, že protokol neumožňuje ověřování, aktivované odesílání znamená, že kdokoli na internetu, kdo najde URL vašeho projektu, do něj bude moci odesílat data. Tato možnost se však téměř nepoužívá.
 
 #### Výhody ####
 
diff --git a/de/04-git-server/01-chapter4.markdown b/de/04-git-server/01-chapter4.markdown
index 2af95673d..cb95e87bb 100644
--- a/de/04-git-server/01-chapter4.markdown
+++ b/de/04-git-server/01-chapter4.markdown
@@ -123,9 +123,9 @@ Die negative Seite von SSH ist, dass Du Deine Repositories nicht anonym darüber
 <!--### The Git Protocol ###-->
 ### Das Git Protokoll ###
 
-<!--Next is the Git protocol. This is a special daemon that comes packaged with Git; it listens on a dedicated port (9418) that provides a service similar to the SSH protocol, but with absolutely no authentication. In order for a repository to be served over the Git protocol, you must create the `git-deamon-export-ok` file — the daemon won’t serve a repository without that file in it — but other than that there is no security. Either the Git repository is available for everyone to clone or it isn’t. This means that there is generally no pushing over this protocol. You can enable push access; but given the lack of authentication, if you turn on push access, anyone on the internet who finds your project’s URL could push to your project. Suffice it to say that this is rare.-->
+<!--Next is the Git protocol. This is a special daemon that comes packaged with Git; it listens on a dedicated port (9418) that provides a service similar to the SSH protocol, but with absolutely no authentication. In order for a repository to be served over the Git protocol, you must create the `git-daemon-export-ok` file — the daemon won’t serve a repository without that file in it — but other than that there is no security. Either the Git repository is available for everyone to clone or it isn’t. This means that there is generally no pushing over this protocol. You can enable push access; but given the lack of authentication, if you turn on push access, anyone on the internet who finds your project’s URL could push to your project. Suffice it to say that this is rare.-->
 
-Als nächstes kommt das Git Protokoll. Das ist ein spezieller Dämon, der zusammen mit Git kommt. Er horcht auf einem bestimmten Port (9418), dieser Service ist vergleichbar mit dem SSH-Protokoll, aber ohne jegliche Authentifizierung. Um ein Repository über das Git Protokoll, musst Du die `gitk-export-daemon-ok` Datei erstellen – der Dämon bietet kein Repository ohne die Datei darin an – außer dieser Datei gibt es keine Sicherheit. Entweder das Git Repository ist für jeden zum Clonen verfügbar oder halt nicht. Das bedeutet, dass dieses Protokoll generell kein push anbietet. Du kannst push-Zugriff aktivieren; aber ohne Authentifizierung, wenn Du den push-Zugriff aktivierst, kann jeder im Internet, der Deine Projekt-URL findet, zu Deinem Projekt pushen. Ausreichend zu sagen, dass das selten ist.
+Als nächstes kommt das Git Protokoll. Das ist ein spezieller Dämon, der zusammen mit Git kommt. Er horcht auf einem bestimmten Port (9418), dieser Service ist vergleichbar mit dem SSH-Protokoll, aber ohne jegliche Authentifizierung. Um ein Repository über das Git Protokoll, musst Du die `git-daemon-export-ok` Datei erstellen – der Dämon bietet kein Repository ohne die Datei darin an – außer dieser Datei gibt es keine Sicherheit. Entweder das Git Repository ist für jeden zum Clonen verfügbar oder halt nicht. Das bedeutet, dass dieses Protokoll generell kein push anbietet. Du kannst push-Zugriff aktivieren; aber ohne Authentifizierung, wenn Du den push-Zugriff aktivierst, kann jeder im Internet, der Deine Projekt-URL findet, zu Deinem Projekt pushen. Ausreichend zu sagen, dass das selten ist.
 
 <!--#### The Pros ####-->
 #### Die Vorteile ####
diff --git a/en/04-git-server/01-chapter4.markdown b/en/04-git-server/01-chapter4.markdown
index fda0fb87f..c0e35ec3f 100644
--- a/en/04-git-server/01-chapter4.markdown
+++ b/en/04-git-server/01-chapter4.markdown
@@ -70,7 +70,7 @@ The negative aspect of SSH is that you can’t serve anonymous access of your re
 
 ### The Git Protocol ###
 
-Next is the Git protocol. This is a special daemon that comes packaged with Git; it listens on a dedicated port (9418) that provides a service similar to the SSH protocol, but with absolutely no authentication. In order for a repository to be served over the Git protocol, you must create the `git-deamon-export-ok` file — the daemon won’t serve a repository without that file in it — but other than that there is no security. Either the Git repository is available for everyone to clone or it isn’t. This means that there is generally no pushing over this protocol. You can enable push access; but given the lack of authentication, if you turn on push access, anyone on the internet who finds your project’s URL could push to your project. Suffice it to say that this is rare.
+Next is the Git protocol. This is a special daemon that comes packaged with Git; it listens on a dedicated port (9418) that provides a service similar to the SSH protocol, but with absolutely no authentication. In order for a repository to be served over the Git protocol, you must create the `git-daemon-export-ok` file — the daemon won’t serve a repository without that file in it — but other than that there is no security. Either the Git repository is available for everyone to clone or it isn’t. This means that there is generally no pushing over this protocol. You can enable push access; but given the lack of authentication, if you turn on push access, anyone on the internet who finds your project’s URL could push to your project. Suffice it to say that this is rare.
 
 #### The Pros ####
 
diff --git a/es/04-git-server/01-chapter4.markdown b/es/04-git-server/01-chapter4.markdown
index 7efaf3963..ef8af9cf8 100755
--- a/es/04-git-server/01-chapter4.markdown
+++ b/es/04-git-server/01-chapter4.markdown
@@ -68,7 +68,7 @@ El aspecto negativo de SSH es su imposibilidad para dar acceso anónimo al repos
 
 ### El Protocolo Git ###
 
-El protocolo Git  es un demonio (daemon) especial, que viene incorporado con Git. Escucha por un puerto dedicado (9418), y nos da un servicio similar al del protocolo SSH; pero sin ningún tipo de autentificación. Para que un repositorio pueda exponerse a través del protocolo Git, tienes que crear en él un archivo 'git-deamon-export-ok'; sin este archivo, el demonio no hará disponible el repositorio. Pero, aparte de esto, no hay ninguna otra medida de seguridad. O el repositorio está disponible para que cualquiera lo pueda clonar, o no lo está. Lo cual significa que, normalmente, no se podrá enviar (push) a través de este protocolo. Aunque realmente si que puedes habilitar el envio, si lo haces, dada la total falta de ningún mecanismo de autentificación, cualquiera que encuentre la URL a tu proyecto en Internet, podrá enviar (push) contenidos a él. Ni que decir tiene que esto solo lo necesitarás en contadas ocasiones.
+El protocolo Git  es un demonio (daemon) especial, que viene incorporado con Git. Escucha por un puerto dedicado (9418), y nos da un servicio similar al del protocolo SSH; pero sin ningún tipo de autentificación. Para que un repositorio pueda exponerse a través del protocolo Git, tienes que crear en él un archivo 'git-daemon-export-ok'; sin este archivo, el demonio no hará disponible el repositorio. Pero, aparte de esto, no hay ninguna otra medida de seguridad. O el repositorio está disponible para que cualquiera lo pueda clonar, o no lo está. Lo cual significa que, normalmente, no se podrá enviar (push) a través de este protocolo. Aunque realmente si que puedes habilitar el envio, si lo haces, dada la total falta de ningún mecanismo de autentificación, cualquiera que encuentre la URL a tu proyecto en Internet, podrá enviar (push) contenidos a él. Ni que decir tiene que esto solo lo necesitarás en contadas ocasiones.
 
 ### Ventajas ###
 
diff --git a/fr/04-git-server/01-chapter4.markdown b/fr/04-git-server/01-chapter4.markdown
index 723879107..3633206d2 100644
--- a/fr/04-git-server/01-chapter4.markdown
+++ b/fr/04-git-server/01-chapter4.markdown
@@ -109,7 +109,7 @@ Si vous souhaitez proposer de l'accès anonyme en lecture seule à vos projets,
 ### Protocole Git ###
 
 Vient ensuite le protocole Git. Celui-ci est géré par un *daemon* spécial livré avec Git. Ce *daemon* (démon, processus en arrière plan) écoute sur un port dédié (9418) et propose un service similaire au protocole SSH, mais sans aucune sécurisation.
-Pour qu'un dépôt soit publié via le protocole Git, le fichier `git-deamon-export-ok` doit exister mais mise à part cette condition sans laquelle le *daemon* refuse de publier un projet, il n'y a aucune sécurité.
+Pour qu'un dépôt soit publié via le protocole Git, le fichier `git-daemon-export-ok` doit exister mais mise à part cette condition sans laquelle le *daemon* refuse de publier un projet, il n'y a aucune sécurité.
 Soit le dépôt Git est disponible sans restriction en lecture, soit il n'est pas publié.
 Cela signifie qu'il ne permet pas de pousser des modifications.
 Vous pouvez activer la capacité à pousser mais étant donné l'absence d'authentification, n'importe qui sur Internet ayant trouvé l'URL du projet peut pousser sur le dépôt.
diff --git a/it/04-git-server/01-chapter4.markdown b/it/04-git-server/01-chapter4.markdown
index 40e2c112a..ddadb66bf 100644
--- a/it/04-git-server/01-chapter4.markdown
+++ b/it/04-git-server/01-chapter4.markdown
@@ -70,7 +70,7 @@ L'aspetto negativo di SSH è che non puoi dare accesso anonimo al tuo repository
 
 ### Il Protocollo Git ###
 
-Poi c'è il protocollo Git. Questo è un demone speciale che è incluso nel pacchetto Git; è in ascolto su una porta dedicata (9418) e fornisce un servizio simile al protocollo SSH, ma assolutamente senza autenticazione. Per permettere ad un repository di essere servito tramite il protocollo Git, devi creare un file `git-deamon-export-ok` — il demone non serve il repository senza l'inserimento di questo file — altrimenti non ci sarebbe sicurezza. O il repository Git è disponibile per chiunque voglia copiarlo o altrimenti niente. Questo significa che generalmente non si invia tramite questo protocollo. Puoi abilitare l'accesso all'invio; ma data la mancanza di autenticazione, se abiliti l'accesso di scrittura, chiunque trovi su internet l'URL al progetto può inviare dati. Basti dire che questo è raro.
+Poi c'è il protocollo Git. Questo è un demone speciale che è incluso nel pacchetto Git; è in ascolto su una porta dedicata (9418) e fornisce un servizio simile al protocollo SSH, ma assolutamente senza autenticazione. Per permettere ad un repository di essere servito tramite il protocollo Git, devi creare un file `git-daemon-export-ok` — il demone non serve il repository senza l'inserimento di questo file — altrimenti non ci sarebbe sicurezza. O il repository Git è disponibile per chiunque voglia copiarlo o altrimenti niente. Questo significa che generalmente non si invia tramite questo protocollo. Puoi abilitare l'accesso all'invio; ma data la mancanza di autenticazione, se abiliti l'accesso di scrittura, chiunque trovi su internet l'URL al progetto può inviare dati. Basti dire che questo è raro.
 
 #### I Pro ####
 
diff --git a/ja/04-git-server/01-chapter4.markdown b/ja/04-git-server/01-chapter4.markdown
index 33b34b8f2..43155723e 100644
--- a/ja/04-git-server/01-chapter4.markdown
+++ b/ja/04-git-server/01-chapter4.markdown
@@ -70,7 +70,7 @@ SSH の欠点は、リポジトリへの匿名アクセスを許可できない
 
 ### Git プロトコル ###
 
-次は Git プロトコルです。これは Git に標準で付属する特別なデーモンです。専用のポート (9418) をリスンし、SSH プロトコルと同様のサービスを提供しますが、認証は行いません。Git プロトコルを提供するリポジトリを準備するには、`git-deamon-export-ok` というファイルを作らなければなりません (このファイルがなければデーモンはサービスを提供しません)。ただ、このままでは一切セキュリティはありません。Git リポジトリをすべての人に開放し、クローンさせることができます。しかし、一般に、このプロトコルでプッシュさせることはありません。プッシュアクセスを認めることは可能です。しかし認証がないということは、その URL を知ってさえいればインターネット上の誰もがプロジェクトにプッシュできるということになります。これはありえない話だと言っても差し支えないでしょう。
+次は Git プロトコルです。これは Git に標準で付属する特別なデーモンです。専用のポート (9418) をリスンし、SSH プロトコルと同様のサービスを提供しますが、認証は行いません。Git プロトコルを提供するリポジトリを準備するには、`git-daemon-export-ok` というファイルを作らなければなりません (このファイルがなければデーモンはサービスを提供しません)。ただ、このままでは一切セキュリティはありません。Git リポジトリをすべての人に開放し、クローンさせることができます。しかし、一般に、このプロトコルでプッシュさせることはありません。プッシュアクセスを認めることは可能です。しかし認証がないということは、その URL を知ってさえいればインターネット上の誰もがプロジェクトにプッシュできるということになります。これはありえない話だと言っても差し支えないでしょう。
 
 #### 利点 ####
 
diff --git a/ko/04-git-server/01-chapter4.markdown b/ko/04-git-server/01-chapter4.markdown
index 0083ec87c..8ad6b1c68 100644
--- a/ko/04-git-server/01-chapter4.markdown
+++ b/ko/04-git-server/01-chapter4.markdown
@@ -70,7 +70,7 @@ SSH의 단점은 익명으로 접근할 수 없다는 것이다. 심지어 읽
 
 ### Git 프로토콜 ###
 
-Git 프로토콜은 Git에 포함된 데몬을 사용하는 방법이다. 포트는 9418이며 SSH 프로토콜과 비슷한 서비스를 제공하지만, 인증 메커니즘이 없다. 저장소에 git-deamon-export-ok 파일을 만들면 Git 프로토콜로 서비스할 수 있지만, 보안은 없다. 이 파일이 없는 저장소는 Git 프로토콜로 서비스할 수 없다. 이 저장소는 누구나 Clone할 수 있거나 아무도 Clone할 수 없거나 둘 중의 하나만 선택할 수 있다. 그래서 이 프로토콜로는 Push 가능하게 설정할 수 없다. 엄밀히 말해서 Push할 수 있도록 설정할 수 있지만, 인증하도록 할 수 없다. 그러니까 당신이 Push할 수 있으면 이 프로젝트의 URL을 아는 사람은 누구나 Push할 수 있다. 그냥 이런 것도 있지만 잘 안 쓴다고 알고 있으면 된다.
+Git 프로토콜은 Git에 포함된 데몬을 사용하는 방법이다. 포트는 9418이며 SSH 프로토콜과 비슷한 서비스를 제공하지만, 인증 메커니즘이 없다. 저장소에 git-daemon-export-ok 파일을 만들면 Git 프로토콜로 서비스할 수 있지만, 보안은 없다. 이 파일이 없는 저장소는 Git 프로토콜로 서비스할 수 없다. 이 저장소는 누구나 Clone할 수 있거나 아무도 Clone할 수 없거나 둘 중의 하나만 선택할 수 있다. 그래서 이 프로토콜로는 Push 가능하게 설정할 수 없다. 엄밀히 말해서 Push할 수 있도록 설정할 수 있지만, 인증하도록 할 수 없다. 그러니까 당신이 Push할 수 있으면 이 프로젝트의 URL을 아는 사람은 누구나 Push할 수 있다. 그냥 이런 것도 있지만 잘 안 쓴다고 알고 있으면 된다.
 
 #### 장점 ####
 
diff --git a/nl/04-git-server/01-chapter4.markdown b/nl/04-git-server/01-chapter4.markdown
index 47c01c78e..153825c95 100644
--- a/nl/04-git-server/01-chapter4.markdown
+++ b/nl/04-git-server/01-chapter4.markdown
@@ -70,7 +70,7 @@ Het negatieve aspect van SSH is dat je er geen anonieme toegang over kunt geven.
 
 ### Het Git protocol ###
 
-Het volgende is het Git protocol. Dit is een aparte daemon, die samen met Git geleverd wordt; het luistert op een toegewezen poort (9418), dat een vergelijkbare dienst verleend als het SSH protocol, maar dan zonder enige authenticatie. Om een repository te serveren over het Git protocol, moet je het `git-deamon-export-ok` bestand aanmaken — de daemon zal een repository zonder dit bestand erin niet serveren — maar buiten dat is er geen beveiliging. Ofwel het Git repository kan door iedereen gekloond worden, of helemaal niet. Dit betekent dat over het algemeen pushen niet mogelijk is via dit protocol. Je kunt push toegang aanzetten; maar gegeven het gebrek aan toegangscontrole als je push toegang aan zet, kan iedereen die de URL van jouw project op het internet vindt, pushen naar jouw project. We volstaan met te zeggen dat dit zeldzaam is.
+Het volgende is het Git protocol. Dit is een aparte daemon, die samen met Git geleverd wordt; het luistert op een toegewezen poort (9418), dat een vergelijkbare dienst verleend als het SSH protocol, maar dan zonder enige authenticatie. Om een repository te serveren over het Git protocol, moet je het `git-daemon-export-ok` bestand aanmaken — de daemon zal een repository zonder dit bestand erin niet serveren — maar buiten dat is er geen beveiliging. Ofwel het Git repository kan door iedereen gekloond worden, of helemaal niet. Dit betekent dat over het algemeen pushen niet mogelijk is via dit protocol. Je kunt push toegang aanzetten; maar gegeven het gebrek aan toegangscontrole als je push toegang aan zet, kan iedereen die de URL van jouw project op het internet vindt, pushen naar jouw project. We volstaan met te zeggen dat dit zeldzaam is.
 
 #### De voordelen ####
 
diff --git a/no-nb/04-git-server/01-chapter4.markdown b/no-nb/04-git-server/01-chapter4.markdown
index 29d33bd57..244463a46 100644
--- a/no-nb/04-git-server/01-chapter4.markdown
+++ b/no-nb/04-git-server/01-chapter4.markdown
@@ -70,7 +70,7 @@ The negative aspect of SSH is that you can’t serve anonymous access of your re
 
 ### The Git Protocol ###
 
-Next is the Git protocol. This is a special daemon that comes packaged with Git; it listens on a dedicated port (9418) that provides a service similar to the SSH protocol, but with absolutely no authentication. In order for a repository to be served over the Git protocol, you must create the `git-deamon-export-ok` file — the daemon won’t serve a repository without that file in it — but other than that there is no security. Either the Git repository is available for everyone to clone or it isn’t. This means that there is generally no pushing over this protocol. You can enable push access; but given the lack of authentication, if you turn on push access, anyone on the internet who finds your project’s URL could push to your project. Suffice it to say that this is rare.
+Next is the Git protocol. This is a special daemon that comes packaged with Git; it listens on a dedicated port (9418) that provides a service similar to the SSH protocol, but with absolutely no authentication. In order for a repository to be served over the Git protocol, you must create the `git-daemon-export-ok` file — the daemon won’t serve a repository without that file in it — but other than that there is no security. Either the Git repository is available for everyone to clone or it isn’t. This means that there is generally no pushing over this protocol. You can enable push access; but given the lack of authentication, if you turn on push access, anyone on the internet who finds your project’s URL could push to your project. Suffice it to say that this is rare.
 
 #### The Pros ####
 
diff --git a/pl/04-git-server/01-chapter4.markdown b/pl/04-git-server/01-chapter4.markdown
index 08e95b3d7..50550ae02 100644
--- a/pl/04-git-server/01-chapter4.markdown
+++ b/pl/04-git-server/01-chapter4.markdown
@@ -70,7 +70,7 @@ Wadą dostępu po SSH jest to, że nie istnieje dostęp anonimowy do repozytoriu
 
 ### Protokół Git ###
 
-Następnie mamy protokół Git. To specjalny rodzaj procesu demona, który dostępny jest w pakiecie z Gitem; słucha na dedykowanym porcie (9418) i udostępnia usługi podobne do protokołu SSH, ale całkowicie bez obsługi uwierzytelnienia. Aby repozytorium mogło być udostępnione po protokole Git konieczne jest utworzenie pliku `git-deamon-export-ok` - bez niego demon nie udostępni repozytorium - ale to jedyne zabezpieczenie. Albo wszyscy mogą klonować dane repozytorium, albo nikt. Generalnie oznacza to że nie można pchać zmian po tym protokole. Można włączyć taką możliwość; ale biorąc pod uwagę brak mechanizmów uwierzytelniania, jeśli włączysz możliwość zapisu, każdy w Internecie, kto odkryje adres Twojego projektu może pchać do niego zmiany. Wystarczy powiedzieć, że nie spotyka się często takich sytuacji.
+Następnie mamy protokół Git. To specjalny rodzaj procesu demona, który dostępny jest w pakiecie z Gitem; słucha na dedykowanym porcie (9418) i udostępnia usługi podobne do protokołu SSH, ale całkowicie bez obsługi uwierzytelnienia. Aby repozytorium mogło być udostępnione po protokole Git konieczne jest utworzenie pliku `git-daemon-export-ok` - bez niego demon nie udostępni repozytorium - ale to jedyne zabezpieczenie. Albo wszyscy mogą klonować dane repozytorium, albo nikt. Generalnie oznacza to że nie można pchać zmian po tym protokole. Można włączyć taką możliwość; ale biorąc pod uwagę brak mechanizmów uwierzytelniania, jeśli włączysz możliwość zapisu, każdy w Internecie, kto odkryje adres Twojego projektu może pchać do niego zmiany. Wystarczy powiedzieć, że nie spotyka się często takich sytuacji.
 
 #### Zalety ####
 
diff --git a/pt-br/04-git-server/01-chapter4.markdown b/pt-br/04-git-server/01-chapter4.markdown
index 9411c3f06..abdc94532 100644
--- a/pt-br/04-git-server/01-chapter4.markdown
+++ b/pt-br/04-git-server/01-chapter4.markdown
@@ -70,7 +70,7 @@ O aspecto negativo do SSH é que você não pode permitir acesso anônimo do seu
 
 ### O Protocolo Git ###
 
-O próximo é o protocolo Git. Este é um daemon especial que vem no mesmo pacote que o Git; ele escuta em uma porta dedicada (9418) que provê um serviço similar ao do protocolo SSH, mas absolutamente sem nenhuma autenticação. Para que um repositório seja disponibilizado via protocolo Git, você tem que criar o arquivo `git-deamon-export-ok` — o daemon não disponibilizará um repositório sem este arquivo dentro — mas além disso não há nenhuma segurança. Ou o repositório Git está disponível para todos clonarem ou não. Isto significa que geralmente não existe envio (push) sobre este protocolo. Você pode habilitar o acesso a envio; mas dada a falta de autenticação, se você ativar o acesso de envio, qualquer um na internet que encontre a URL do seu projeto poderia enviar (push) para o seu projeto. É suficiente dizer que isto é raro.
+O próximo é o protocolo Git. Este é um daemon especial que vem no mesmo pacote que o Git; ele escuta em uma porta dedicada (9418) que provê um serviço similar ao do protocolo SSH, mas absolutamente sem nenhuma autenticação. Para que um repositório seja disponibilizado via protocolo Git, você tem que criar o arquivo `git-daemon-export-ok` — o daemon não disponibilizará um repositório sem este arquivo dentro — mas além disso não há nenhuma segurança. Ou o repositório Git está disponível para todos clonarem ou não. Isto significa que geralmente não existe envio (push) sobre este protocolo. Você pode habilitar o acesso a envio; mas dada a falta de autenticação, se você ativar o acesso de envio, qualquer um na internet que encontre a URL do seu projeto poderia enviar (push) para o seu projeto. É suficiente dizer que isto é raro.
 
 #### Os Prós ####
 
diff --git a/ru/04-git-server/01-chapter4.markdown b/ru/04-git-server/01-chapter4.markdown
index cfb52a42e..0c9e085f4 100644
--- a/ru/04-git-server/01-chapter4.markdown
+++ b/ru/04-git-server/01-chapter4.markdown
@@ -70,7 +70,7 @@ SSH имеет множество достоинств. Во-первых, вы,
 
 ### Git-протокол ###
 
-Следующий протокол — Git-протокол. Вместе с Git'ом поставляется специальный демон, который слушает порт 9418 и предоставляет сервис, схожий с протоколом ssh, но абсолютно без аутентификации. Чтобы использовать Git-протокол для репозитория, вы должны создать файл `git-deamon-export-ok`, иначе демон не будет работать с этим репозиторием, но следует помнить, что в протоколе отсутствуют средства безопасности. Соответственно, любой репозиторий в Git'е может быть либо доступен для клонирования всем, либо не доступен никому. Как следствие, обычно вы не можете отправлять изменения по этому протоколу. Вы можете открыть доступ на запись, но из-за отсутствия авторизации в этом случае кто угодно, зная URL вашего проекта, сможет его изменить. В общем, это редко используемая возможность.
+Следующий протокол — Git-протокол. Вместе с Git'ом поставляется специальный демон, который слушает порт 9418 и предоставляет сервис, схожий с протоколом ssh, но абсолютно без аутентификации. Чтобы использовать Git-протокол для репозитория, вы должны создать файл `git-daemon-export-ok`, иначе демон не будет работать с этим репозиторием, но следует помнить, что в протоколе отсутствуют средства безопасности. Соответственно, любой репозиторий в Git'е может быть либо доступен для клонирования всем, либо не доступен никому. Как следствие, обычно вы не можете отправлять изменения по этому протоколу. Вы можете открыть доступ на запись, но из-за отсутствия авторизации в этом случае кто угодно, зная URL вашего проекта, сможет его изменить. В общем, это редко используемая возможность.
 
 #### Достоинства ####
 
diff --git a/zh/04-git-server/01-chapter4.markdown b/zh/04-git-server/01-chapter4.markdown
index 514b1a3f6..c04b5933b 100644
--- a/zh/04-git-server/01-chapter4.markdown
+++ b/zh/04-git-server/01-chapter4.markdown
@@ -70,7 +70,7 @@ SSH 的限制在于你不能通过它实现仓库的匿名访问。即使仅为
 
 ### Git 协议 ###
 
-接下来是 Git 协议。这是一个包含在 Git 软件包中的特殊守护进程； 它会监听一个提供类似于 SSH 服务的特定端口（9418），而无需任何授权。打算支持 Git 协议的仓库，需要先创建 `git-deamon-export-ok` 文件 — 它是协议进程提供仓库服务的必要条件 — 但除此之外该服务没有什么安全措施。要么所有人都能克隆 Git 仓库，要么谁也不能。这也意味着该协议通常不能用来进行推送。你可以允许推送操作；然而由于没有授权机制，一旦允许该操作，网络上任何一个知道项目 URL 的人将都有推送权限。不用说，这是十分罕见的情况。
+接下来是 Git 协议。这是一个包含在 Git 软件包中的特殊守护进程； 它会监听一个提供类似于 SSH 服务的特定端口（9418），而无需任何授权。打算支持 Git 协议的仓库，需要先创建 `git-daemon-export-ok` 文件 — 它是协议进程提供仓库服务的必要条件 — 但除此之外该服务没有什么安全措施。要么所有人都能克隆 Git 仓库，要么谁也不能。这也意味着该协议通常不能用来进行推送。你可以允许推送操作；然而由于没有授权机制，一旦允许该操作，网络上任何一个知道项目 URL 的人将都有推送权限。不用说，这是十分罕见的情况。
 
 #### 优点 ####
 

From 28f93d9cf20983fc2ce005816a60ecd49090a3ab Mon Sep 17 00:00:00 2001
From: unknown <noel.broda@GLB7148.globant.com>
Date: Fri, 10 Jan 2014 15:21:16 -0300
Subject: [PATCH 069/690] Fix issue #612: Bad spanish translation

---
 es/03-git-branching/01-chapter3.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/es/03-git-branching/01-chapter3.markdown b/es/03-git-branching/01-chapter3.markdown
index 8d885fb89..f745f493b 100644
--- a/es/03-git-branching/01-chapter3.markdown
+++ b/es/03-git-branching/01-chapter3.markdown
@@ -257,7 +257,7 @@ Donde nos dice que la versión en HEAD (la rama 'master', la que habias activado
 	</div>
 
 Esta corrección contiene un poco de ambas partes. Y se han eliminado completamente las líneas `<<<<<<<` , `=======` y `>>>>>>>` Tras resolver todos los bloques conflictivos, has de lanzar comandos 'git add' para marcar cada archivo modificado. Marcar archivos como preparados (staging), indica a Git que sus conflictos han sido resueltos.
-Si, en lugar de resolver directamente, prefieres utilizar una herramienta gráfica. Puedes usar el comando 'git mergetool'. Esto arrancará la correspondiente herramienta de visualización y te permirá ir resolviendo conflictos con ella.
+Si en lugar de resolver directamente, prefieres utilizar una herramienta gráfica, puedes usar el comando 'git mergetool'. Esto arrancará la correspondiente herramienta de visualización y te permirá ir resolviendo conflictos con ella.
 
 	$ git mergetool
 	merge tool candidates: kdiff3 tkdiff xxdiff meld gvimdiff opendiff emerge vimdiff

From 0d7b37596f82e229ac7fda21a09078669856a1f4 Mon Sep 17 00:00:00 2001
From: Broda Noel <noel.broda@GLB7148.globant.com>
Date: Fri, 10 Jan 2014 15:49:23 -0300
Subject: [PATCH 070/690] Fix issue #611. Bad Spanish translation

---
 es/03-git-branching/01-chapter3.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/es/03-git-branching/01-chapter3.markdown b/es/03-git-branching/01-chapter3.markdown
index 8d885fb89..a4dab04b6 100644
--- a/es/03-git-branching/01-chapter3.markdown
+++ b/es/03-git-branching/01-chapter3.markdown
@@ -388,7 +388,7 @@ Esto puede ser un tanto confuso, pero intentemos aclararlo con un ejemplo.  Supo
 Insert 18333fig0322.png 
 Figura 3-22. Un clón Git te proporciona tu propia rama 'master' y otra rama 'origin/master' apuntando a la rama 'master' original.
 
-Si haces algún trabajo en tu rama 'master' local. Y, al mismo tiempo, alguna otra persona lleva (push) su trabajo al servidor 'git.ourcompany.com', actualizando la rama 'master' de allí. Te encontrarás con que ambos registros avanzan de forma diferente. Además, mientras no tengas contacto con el servidor, tu apuntador a tu rama 'origin/master' no se moverá (ver Figura 3/23).
+Si haces algún trabajo en tu rama 'master' local, y al mismo tiempo, alguna otra persona lleva (push) su trabajo al servidor 'git.ourcompany.com', actualizando la rama 'master' de allí, te encontrarás con que ambos registros avanzan de forma diferente. Además, mientras no tengas contacto con el servidor, tu apuntador a tu rama 'origin/master' no se moverá (ver Figura 3/23).
 
 Insert 18333fig0323.png 
 Figura 3-23. Trabajando localmente y que otra persona esté llevando (push) algo al servidor remoto, hace que cada registro avance de forma distinta.

From a21668220e7948e86d301ab455232d9748668be7 Mon Sep 17 00:00:00 2001
From: Krzysztof Gibas <krzysztof@gibas.pl>
Date: Sat, 11 Jan 2014 23:35:44 +0100
Subject: [PATCH 071/690] [pl] chapter 7 improvements

---
 pl/07-customizing-git/01-chapter7.markdown | 27 ++++++++++++++--------
 1 file changed, 18 insertions(+), 9 deletions(-)

diff --git a/pl/07-customizing-git/01-chapter7.markdown b/pl/07-customizing-git/01-chapter7.markdown
index 5b9e6bfa2..2476a295c 100644
--- a/pl/07-customizing-git/01-chapter7.markdown
+++ b/pl/07-customizing-git/01-chapter7.markdown
@@ -132,7 +132,7 @@ Teraz, możesz podpisywać tagi bez konieczności wskazywania za każdym razem k
 
 #### core.excludesfile ####
 
-Możesz umieścić wzorce w pliku `.gitignore` w swoim projekcie, aby Git nie śledził ich i nie próbował dodawać do przechowalni po wykonaniu komendy `git add`, jak wspomniałem już w rozdziale 2. Możesz jednak przechowywać te informacje w innym pliku, znajdującym się poza drzewem projektu, możesz wskazać Gitowi loikalizację tego pliku za pomocą ustawienia `core.excludesfile`. Po prostu ustaw ją na ścieżkę wskazującą na plik, który ma zawartość podobną do tej, którą ma `.gitignore`.
+Możesz umieścić wzorce w pliku `.gitignore` w swoim projekcie, aby Git nie śledził ich i nie próbował dodawać do przechowalni po wykonaniu komendy `git add`, jak wspomniałem już w rozdziale 2. Możesz jednak przechowywać te informacje w innym pliku, znajdującym się poza drzewem projektu, możesz wskazać Gitowi lokalizację tego pliku za pomocą ustawienia `core.excludesfile`. Po prostu ustaw ją na ścieżkę wskazującą na plik, który ma zawartość podobną do tej, którą ma `.gitignore`.
 
 <!-- You can put patterns in your project’s `.gitignore` file to have Git not see them as untracked files or try to stage them when you run `git add` on them, as discussed in Chapter 2. However, if you want another file outside of your project to hold those values or have extra values, you can tell Git where that file is with the `core.excludesfile` setting. Simply set it to the path of a file that has content similar to what a `.gitignore` file would have. -->
 
@@ -317,27 +317,36 @@ Jeżeli uruchomić tą komendę, zamiast ustawienia plików `extMerge` i `extDif
 
 <!-- ### Formatting and Whitespace ### -->
 
-Problemy związane z formatowaniem i białymi znakami są jednym z bardziej uciążliwych i wyrafinowanych problemów, które wielu deweloperów może spotkać podczas współpracy, szczególnie jeżeli korzystają z różnych systemów operacyjnych. Bardzo łatwo można wprowadzić zmiany w łatach lub innych modyfikacjach, które 
-
-Git posiada kilka opcji konfiguracyjnych, które pomagają rozwiązać te problemy.
+Problemy związane z formatowaniem i białymi znakami są jednymi z bardziej uciążliwych i wyrafinowanych, które wielu deweloperów mogą spotkać podczas pracy, szczególnie jeżeli korzystają z różnych systemów operacyjnych. Bardzo łatwo można je wprowadzić w łatach lub modyfikacjach, poprzez samoistne dodanie ich przez edytor tekstowy, lub dodanie znaku powrotu karetki na końcach linii przez programistów korzystających z systemu Windows. Git posiada kilka opcji konfiguracyjnych, które pomagają rozwiązać te problemy.
 
 <!-- Formatting and whitespace issues are some of the more frustrating and subtle problems that many developers encounter when collaborating, especially cross-platform. It’s very easy for patches or other collaborated work to introduce subtle whitespace changes because editors silently introduce them or Windows programmers add carriage returns at the end of lines they touch in cross-platform projects. Git has a few configuration options to help with these issues. -->
 
 #### core.autocrlf ####
 
-If you’re programming on Windows or using another system but working with people who are programming on Windows, you’ll probably run into line-ending issues at some point. This is because Windows uses both a carriage-return character and a linefeed character for newlines in its files, whereas Mac and Linux systems use only the linefeed character. This is a subtle but incredibly annoying fact of cross-platform work.
 
-Git can handle this by auto-converting CRLF line endings into LF when you commit, and vice versa when it checks out code onto your filesystem. You can turn on this functionality with the `core.autocrlf` setting. If you’re on a Windows machine, set it to `true` — this converts LF endings into CRLF when you check out code:
+Jeżeli programujesz na systemie Windows, lub używasz innego systemu, ale współpracujesz z osobami które programują na tym systemie, prawdopodobnie będziesz miał w pewnym momencie problemy związane ze znakami końca linii. Dzieje się tak dlatego, ponieważ system Windows używa obu znaków powrotu karetki i nowej linii w celu oznaczenia końca wiersza w swoich plikach, a tymczasem w systemach Mac i Linux użwany jest jedynie znak nowej linii. To jest subtelny, ale bardzo irytujący fakt przy współpracy na wielu platformach.
+
+<!-- If you’re programming on Windows or using another system but working with people who are programming on Windows, you’ll probably run into line-ending issues at some point. This is because Windows uses both a carriage-return character and a linefeed character for newlines in its files, whereas Mac and Linux systems use only the linefeed character. This is a subtle but incredibly annoying fact of cross-platform work. -->
+
+Git może to obsłużyć poprzez automatyczną konwersję linii CRLF na LF, gdy wykonujesz commit, i odwrotnie podczas pobierania kodu na dysk. Możesz włączyć tą funkcjonalność za pomocą ustawienia `core.autocrlf`. Jeżeli pracujesz na systemie Windows, ustaw jej wartość na `true` - zamieni to znaki LF na CRLS podczas pobierania kodu.
+
+<!-- Git can handle this by auto-converting CRLF line endings into LF when you commit, and vice versa when it checks out code onto your filesystem. You can turn on this functionality with the `core.autocrlf` setting. If you’re on a Windows machine, set it to `true` — this converts LF endings into CRLF when you check out code: -->
 
 	$ git config --global core.autocrlf true
 
-If you’re on a Linux or Mac system that uses LF line endings, then you don’t want Git to automatically convert them when you check out files; however, if a file with CRLF endings accidentally gets introduced, then you may want Git to fix it. You can tell Git to convert CRLF to LF on commit but not the other way around by setting `core.autocrlf` to input:
+Jeżeli pracujesz na systemie Linux lub Mac, który używa znaków LF oznaczających koniec wiersza, nie będziesz chciał, aby Git automatycznie konwertował je podczas pobierania kodu; jednakże, jeżeli zostanie przez pomyłkę wgrany plik z zakończeniami CRLF, możesz chcieć aby Git je poprawił. Możesz wskazać Git, aby konwertował znaki CRLF na LF podczas commita, ale nie w odwrotną stronę ustawiając `core.autocrlf` na input:
+
+<!-- If you’re on a Linux or Mac system that uses LF line endings, then you don’t want Git to automatically convert them when you check out files; however, if a file with CRLF endings accidentally gets introduced, then you may want Git to fix it. You can tell Git to convert CRLF to LF on commit but not the other way around by setting `core.autocrlf` to input: -->
 
 	$ git config --global core.autocrlf input
 
-This setup should leave you with CRLF endings in Windows checkouts but LF endings on Mac and Linux systems and in the repository.
+Takie ustawienia powinny zachować znaki CRLF na systemach Windows, oraz LF na systemach Mac i Linux, oraz w repozytorium.
+
+<!-- This setup should leave you with CRLF endings in Windows checkouts but LF endings on Mac and Linux systems and in the repository. -->
+
+Jeżeli jesteś programistą tworzącym aplikację przeznaczoną wyłącznie na systemy Windows, możesz zupełnie wyłączyć tą funkcjonalność przez ustawienie wartości false, przez co znaki powrotu karetki również będą zapisywanie w repozytorium.
 
-If you’re a Windows programmer doing a Windows-only project, then you can turn off this functionality, recording the carriage returns in the repository by setting the config value to `false`:
+<!-- If you’re a Windows programmer doing a Windows-only project, then you can turn off this functionality, recording the carriage returns in the repository by setting the config value to `false`: -->
 
 	$ git config --global core.autocrlf false
 

From 9cc46bbf390c6c762f9fe5902395510289a4349b Mon Sep 17 00:00:00 2001
From: Krzysztof Gibas <krzysztof@gibas.pl>
Date: Sat, 11 Jan 2014 23:42:15 +0100
Subject: [PATCH 072/690] =?UTF-8?q?[pl]=20s/t=C4=85=20komend=C4=99/t=C4=99?=
 =?UTF-8?q?=20komend=C4=99/?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 pl/05-distributed-git/01-chapter5.markdown    | 2 +-
 pl/06-git-tools/01-chapter6.markdown          | 2 +-
 pl/07-customizing-git/01-chapter7.markdown    | 2 +-
 pl/08-git-and-other-scms/01-chapter8.markdown | 4 ++--
 pl/09-git-internals/01-chapter9.markdown      | 2 +-
 5 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/pl/05-distributed-git/01-chapter5.markdown b/pl/05-distributed-git/01-chapter5.markdown
index 257072367..61032e009 100644
--- a/pl/05-distributed-git/01-chapter5.markdown
+++ b/pl/05-distributed-git/01-chapter5.markdown
@@ -133,7 +133,7 @@ Po pierwsze, nie chcesz wgrywać żadnych błędów związanych z poprawkami pus
     +    def command(git_cmd)XXXX
 
 
-Jeżeli uruchomisz tą komendę przed commit-em, dowiesz się czy zamierzasz wgrać zmiany które mogą zdenerwować innych programistów.
+Jeżeli uruchomisz tę komendę przed commit-em, dowiesz się czy zamierzasz wgrać zmiany które mogą zdenerwować innych programistów.
 
 <!-- If you run that command before committing, you can tell if you’re about to commit whitespace issues that may annoy other developers. -->
 
diff --git a/pl/06-git-tools/01-chapter6.markdown b/pl/06-git-tools/01-chapter6.markdown
index 0aff34822..228326762 100644
--- a/pl/06-git-tools/01-chapter6.markdown
+++ b/pl/06-git-tools/01-chapter6.markdown
@@ -1330,7 +1330,7 @@ Dzieje się tak dlatego, ponieważ wskaźnik który masz dla modułu zależnego,
 	   08d709f..6c5e70b  master     -> origin/master
 	Submodule path 'rack': checked out '6c5e70b984a60b3cecd395edd5b48a7575bf58e0'
 
-Musisz wykonywać tą komendę, za każdym razem gdy ściągniesz zmiany z modułu do swojego projektu. Trochę to dziwne, ale działa.
+Musisz wykonywać tę komendę, za każdym razem gdy ściągniesz zmiany z modułu do swojego projektu. Trochę to dziwne, ale działa.
 
 <!-- You have to do this every time you pull down a submodule change in the main project. It’s strange, but it works. -->
 
diff --git a/pl/07-customizing-git/01-chapter7.markdown b/pl/07-customizing-git/01-chapter7.markdown
index 5b9e6bfa2..7bf7b7b31 100644
--- a/pl/07-customizing-git/01-chapter7.markdown
+++ b/pl/07-customizing-git/01-chapter7.markdown
@@ -309,7 +309,7 @@ Git jest wstępnie skonfigurowany do używania wielu innych narzędzi do łącze
 
 	$ git config --global merge.tool kdiff3
 
-Jeżeli uruchomić tą komendę, zamiast ustawienia plików `extMerge` i `extDiff`, Git będzie używał KDiff3 do rozwiązywania konfliktów i standardowego narzędzia Git diff do pokazywania różnic.
+Jeżeli uruchomić tę komendę, zamiast ustawienia plików `extMerge` i `extDiff`, Git będzie używał KDiff3 do rozwiązywania konfliktów i standardowego narzędzia Git diff do pokazywania różnic.
 
 <!-- If you run this instead of setting up the `extMerge` and `extDiff` files, Git will use KDiff3 for merge resolution and the normal Git diff tool for diffs. -->
 
diff --git a/pl/08-git-and-other-scms/01-chapter8.markdown b/pl/08-git-and-other-scms/01-chapter8.markdown
index 19155bca8..b855eba7a 100644
--- a/pl/08-git-and-other-scms/01-chapter8.markdown
+++ b/pl/08-git-and-other-scms/01-chapter8.markdown
@@ -264,7 +264,7 @@ Warto to zapamiętać, że wynikiem będzie projekt w stanie, w którym nie istn
 
 <!-- This is important to remember, because the outcome is a project state that didn’t exist on either of your computers when you pushed. If the changes are incompatible but don’t conflict, you may get issues that are difficult to diagnose. This is different than using a Git server — in Git, you can fully test the state on your client system before publishing it, whereas in SVN, you can’t ever be certain that the states immediately before commit and after commit are identical. -->
 
-Powinieneś również uruchamiać tą komendę, aby pobierać zmiany z serwera Subversion, nawet jeżeli nie jesteś jeszcze gotowy do zapisania swoich. Możesz uruchomić `git svn fetch`, aby pobrać nowe dane, `git svn rebase` zrobi to samo, jednak również nałoży Twoje lokalne modyfikacje.
+Powinieneś również uruchamiać tę komendę, aby pobierać zmiany z serwera Subversion, nawet jeżeli nie jesteś jeszcze gotowy do zapisania swoich. Możesz uruchomić `git svn fetch`, aby pobrać nowe dane, `git svn rebase` zrobi to samo, jednak również nałoży Twoje lokalne modyfikacje.
 
 <!-- You should also run this command to pull in changes from the Subversion server, even if you’re not ready to commit yourself. You can run `git svn fetch` to grab the new data, but `git svn rebase` does the fetch and then updates your local commits. -->
 
@@ -477,7 +477,7 @@ W ten sposób, nie zaśmiecasz swojego projektu plikami `.gitignore`. Jest to do
 
 <!-- ### Git-Svn Summary ### -->
 
-Narzędzia dostarczane przez `git svn` są przydatne, jeżeli musisz używać serwera Subversion, lub jeżeli są inne przesłanki, które zmuszają Cię do tego. Powinieneś patrzeć na tą komendę jak na ograniczonego Gita, lub inaczej będziesz natrafiał na kłopotliwe dla innych programistów problemy. Aby napotykać ich jak najmniej, trzymaj się tych zasad:
+Narzędzia dostarczane przez `git svn` są przydatne, jeżeli musisz używać serwera Subversion, lub jeżeli są inne przesłanki, które zmuszają Cię do tego. Powinieneś patrzeć na tę komendę jak na ograniczonego Gita, lub inaczej będziesz natrafiał na kłopotliwe dla innych programistów problemy. Aby napotykać ich jak najmniej, trzymaj się tych zasad:
 
 <!-- The `git svn` tools are useful if you’re stuck with a Subversion server for now or are otherwise in a development environment that necessitates running a Subversion server. You should consider it crippled Git, however, or you’ll hit issues in translation that may confuse you and your collaborators. To stay out of trouble, try to follow these guidelines: -->
 
diff --git a/pl/09-git-internals/01-chapter9.markdown b/pl/09-git-internals/01-chapter9.markdown
index 5caebd6d1..3bdd05268 100644
--- a/pl/09-git-internals/01-chapter9.markdown
+++ b/pl/09-git-internals/01-chapter9.markdown
@@ -416,7 +416,7 @@ W Gitcie nazywane są one "referencjami" lub krócej "refs"; możesz znaleźć p
     $ find .git/refs -type f
     $
 
-Aby stworzyć nową referencję, która pomocna będzie przy zapamiętywaniu który commit jest ostatni, możesz wykonać tą prostą komendę: 
+Aby stworzyć nową referencję, która pomocna będzie przy zapamiętywaniu który commit jest ostatni, możesz wykonać tę prostą komendę: 
 
 <!-- To create a new reference that will help you remember where your latest commit is, you can technically do something as simple as this: -->
 

From ca6c022c8974b1f089f3162df9272fb69e35aa4f Mon Sep 17 00:00:00 2001
From: Broda Noel <brodanoel@gmail.com>
Date: Sat, 11 Jan 2014 20:59:05 -0300
Subject: [PATCH 073/690] Fix issue #620

---
 es/04-git-server/01-chapter4.markdown | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/es/04-git-server/01-chapter4.markdown b/es/04-git-server/01-chapter4.markdown
index ef8af9cf8..14bc87477 100755
--- a/es/04-git-server/01-chapter4.markdown
+++ b/es/04-git-server/01-chapter4.markdown
@@ -361,9 +361,9 @@ En este punto, es posible que desees cambiar a un popular programa llamado Gitos
 
 Instalar Gitosis no es precisamente sencillo. Pero tampoco demasiado complicado. Es más sencillo hacerlo si utilizas un servidor Linux --estos ejemplos se han hecho sobre un servidor Ubuntu 8.10--.
 
-Gitosis necesita de ciertas herramientas Python, por lo que la  primera tarea será instalar el paquete de herramientas Pyton. En Ubuntu viene como el paquete python-stuptools:
+Gitosis necesita de ciertas herramientas Python, por lo que la  primera tarea será instalar el paquete de herramientas Pyton. En Ubuntu viene como el paquete python-setuptools:
 
-	$ apt-get install python-setuptools
+	$ sudo apt-get install python-setuptools
 
 A continuación, has de clonar e instalar Gitosis desde el repositorio principal de su proyecto:
 

From 168dfddc091aae4f1191ff996513f36659e5a41e Mon Sep 17 00:00:00 2001
From: Changwoo Park <pismute@gmail.com>
Date: Sun, 10 Nov 2013 08:18:41 +0900
Subject: [PATCH 074/690] [ko] update fonts and thanks for pdf

---
 latex/config.yml | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/latex/config.yml b/latex/config.yml
index 4271597c8..2ed0f7939 100644
--- a/latex/config.yml
+++ b/latex/config.yml
@@ -116,9 +116,9 @@ de:
   thanks: "Dies ist die PDF-Datei des Buches „Pro Git“. Es ist lizenziert unter der „Creative Commons Attribution-Non Commercial-Share Alike“-Lizenz. Ich hoffe, es gefällt dir, ich hoffe, es hilft dir, Git zu lernen, und ich hoffe, dass du Apress und mich unterstützt, indem du ein gedrucktes Exemplar des Buches über Amazon bestellst: \\url{http://tinyurl.com/amazonprogit}"
 ko:
   langrule: "\\XeTeXlinebreakskip=0em plus 0.1em minus 0.01em\n\\XeTeXlinebreakpenalty=0"
-  font: NanumMyeongjo
+  font: NanumBarunGothic
   bold: "{* Bold}"
-  mono: NanumGothicCoding 
+  mono: NanumGothicCoding
   prechap: ""
   postchap: "장"
   presect: ""
@@ -127,7 +127,7 @@ ko:
   con: "목차"
   fig: "그림"
   tab: "표"
-  thanks: "지금 보시는 문서는 Pro Git 책에 대한 PDF 파일입니다. 본 문서는 Creative Commons 저작자표시-비영리조건-동일조건변경허락 3.0(Creative Commons Attribution-Non Commercial-Share Alike 3.0) 라이센스를 따릅니다. 여러분이 Git을 이해하는데 도움이 되기를 희망합니다. 종이로 출판된 책을 Amazon 웹사이트 \\url{http://tinyurl.com/amazonprogit} 에서 구입하여 저를 비롯한 Apress에도 도움을 주시기를 기대하겠습니다.\\newline한국어 번역은 박창우(pismute@gmail.com), 이성환(lethee@gmail.com)이 하였습니다. 오역 등의 개선 사항은 역자의 메일로 보내주시거나 한국어 번역 게시판에 \\url{https://github.com/dogfeet/progit/issues} 남겨주시기 바랍니다. 직접 개선해서 패치나 Pull Request를 보내주셔도 됩니다."
+  thanks: "지금 보시는 문서는 Pro Git 책에 대한 PDF 파일입니다. 본 문서는 Creative Commons 저작자표시-비영리조건-동일조건변경허락 3.0(Creative Commons Attribution-Non Commercial-Share Alike 3.0) 라이센스를 따릅니다. 여러분이 Git을 이해하는데 도움이 되기를 희망합니다. 종이로 출판된 책을 Amazon 웹사이트 \\url{http://tinyurl.com/amazonprogit} 에서 구입하여 저를 비롯한 Apress에도 도움을 주시기를 기대하겠습니다.\\newline한국어 번역판도 인사이트를 통해 종이로 출판됐습니다. 한국어 번역에 대한 자세한 정보는 \\url{https://github.com/progit/progit/tree/master/ko}에서 확인 바람니다."
 be:
   prechap: "Глава "
   presect: "Раздзел "

From e8d8978818ee81a3a25a88b5762d5f2576f63afe Mon Sep 17 00:00:00 2001
From: Changwoo Park <pismute@gmail.com>
Date: Sun, 10 Nov 2013 08:32:31 +0900
Subject: [PATCH 075/690] [ko] update ko/README

---
 ko/README | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/ko/README b/ko/README
index f44feb7e2..d625b729e 100644
--- a/ko/README
+++ b/ko/README
@@ -48,3 +48,9 @@ Mac에서는 먼저 Pandoc과 MacTex 패키지를 설치합니다. pdf를 빌드
 
 번역, 박창우(Changwoo Park), pismute at gmail dot com, https://github.com/pismute
 번역, 이성환(Sean Lee), lethee at gmail dot comt, https://github.com/lethee
+번역, 최용재(Yongjae choi), lnyarl at gmail dot comt, https://github.com/lnyarl
+
+종이책
+=====================
+
+[인사이트](http://www.insightbook.co.kr/)를 통해서 Pro Git 한글 번역판이 종이로도 출간됐습니다. 인사이트와 역자에게 도움을 주시기 바람니다.

From 22e4411f9ea251febf9ec1b685b38c235cde08da Mon Sep 17 00:00:00 2001
From: Changwoo Park <pismute@gmail.com>
Date: Wed, 18 Dec 2013 20:56:10 +0900
Subject: [PATCH 076/690] [ko] update translation

---
 ko/02-git-basics/01-chapter2.markdown | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/ko/02-git-basics/01-chapter2.markdown b/ko/02-git-basics/01-chapter2.markdown
index 123b17df7..88b86ca02 100644
--- a/ko/02-git-basics/01-chapter2.markdown
+++ b/ko/02-git-basics/01-chapter2.markdown
@@ -1107,9 +1107,9 @@ Git의 기초를 마치기 전에 Git을 좀 더 쉽고 편안하게 쓸 수 있
 
 ### 자동완성 ###
 
-Bash 쉘을 쓰고 있다면 멋진 자동완성(Auto-completion) 기능을 사용할 수 있다. Git의 소스코드를 다운받아 `contrib/completion` 디렉토리를 살펴보면 `git-completion.bash`라는 파일이 있다. 그 파일을 홈 디렉토리에 카피하고 `.bashrc` 파일에 아래와 같은 내용을 추가하자:
+Bash 쉘을 쓰고 있다면 멋진 자동완성(Auto-completion) 기능을 사용할 수 있다. https://github.com/git/git/blob/master/contrib/completion/git-completion.bash 에서 바로 다운받는다. 그 파일을 홈 디렉토리에 카피하고 `.bashrc` 파일에 아래와 같은 내용을 추가하자:
 
-	source ~/.git-completion.bash
+	source ~/git-completion.bash
 
 또 모든 사용자가 사용할 수 있게 설정할 수 있다. Mac 시스템이라면 이 스크립트를 `/opt/local/etc/bash_completion.d` 디렉토리에 복사하고 리눅스라면 `/etc/bash_completion.d/`에 복사한다. 이 디렉토리는 Bash가 자동완성을 지원하기 위해 사용하는 디렉토리다.
 

From 7a425995f66f9b2d9de5ae54a8c5e86c1db6457a Mon Sep 17 00:00:00 2001
From: Changwoo Park <pismute@gmail.com>
Date: Wed, 18 Dec 2013 21:00:54 +0900
Subject: [PATCH 077/690] [ko] fix typo.

---
 ko/07-customizing-git/01-chapter7.markdown | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/ko/07-customizing-git/01-chapter7.markdown b/ko/07-customizing-git/01-chapter7.markdown
index 3c4f1fe1a..e93c49a46 100644
--- a/ko/07-customizing-git/01-chapter7.markdown
+++ b/ko/07-customizing-git/01-chapter7.markdown
@@ -333,11 +333,9 @@ Git은 바이너리 파일도 diff할 수 있다. Git Attribute를 통해 Git이
 위의 명령은 아래와 같은 내용을 `.git/config` 파일에 추가한다:
 
 	[diff "word"]
-	    textconv = strings
+	    textconv = catdoc
 
-댓글: `.doc` 파일의 종류는 여러가지이다. UTF-16 인코딩을 쓰거나 "codepages" 기반(역주: 한글은 Codepage 949) 인코딩을 사용 할 수도 있다. `catdoc`으로는 유용한 정보를 아무것도 찾지 못할 수 있다.
-
-이제 Git은 확장자가 `.doc`인 파일의 스냅샷을 diff할 때 "word" 필터로 정의한 `strings` 프로그램을 사용한다. 이 프로그램은 Word 파일을 텍스트 파일로 변환해 주기 때문에 diff할 수 있다.
+이제 Git은 확장자가 `.doc`인 파일의 스냅샷을 diff할 때 "word" 필터로 정의한 `catdoc` 프로그램을 사용한다. 이 프로그램은 Word 파일을 텍스트 파일로 변환해 주기 때문에 diff할 수 있다.
 
 이 책의 *1장*을 Word 파일로 만들어서 Git에 넣고 나서 단락 하나를 수정하고 저장하는 예를 살펴보자. `git diff`를 실행하면 어디가 달려졌는지 확인할 수 있다:
 

From 93acb40f9d23330d2df89e3259b01ae4a3ec0772 Mon Sep 17 00:00:00 2001
From: Changwoo Park <pismute@gmail.com>
Date: Sat, 21 Dec 2013 07:15:27 +0900
Subject: [PATCH 078/690] [ko] fix punctuations for figure

---
 ko/01-introduction/01-chapter1.markdown    | 14 ++--
 ko/02-git-basics/01-chapter2.markdown      |  4 +-
 ko/03-git-branching/01-chapter3.markdown   | 78 +++++++++++-----------
 ko/04-git-server/01-chapter4.markdown      | 30 ++++-----
 ko/05-distributed-git/01-chapter5.markdown | 54 +++++++--------
 ko/06-git-tools/01-chapter6.markdown       |  2 +-
 ko/07-customizing-git/01-chapter7.markdown |  6 +-
 ko/09-git-internals/01-chapter9.markdown   |  8 +--
 8 files changed, 98 insertions(+), 98 deletions(-)

diff --git a/ko/01-introduction/01-chapter1.markdown b/ko/01-introduction/01-chapter1.markdown
index 0cbacd34b..a7a24715b 100644
--- a/ko/01-introduction/01-chapter1.markdown
+++ b/ko/01-introduction/01-chapter1.markdown
@@ -15,7 +15,7 @@
 이런 이유로 프로그래머들은 오래전에 로컬 VCS라는 걸 만들었다. 이 VCS는 아주 간단한 데이터베이스를 사용해서 파일의 변경 정보를 관리했다.
 
 Insert 18333fig0101.png
-그림 1-1 로컬 버전 관리 다이어그램
+그림 1-1. 로컬 버전 관리 다이어그램
 
 많이 쓰는 VCS 도구 중에 rcs라고 부르는 것이 있는데 오늘날까지도 아직 많은 회사가 사용하고 있다. Mac OS X 운영체제에서도 개발 도구를 설치하면 RCS가 함께 설치된다. RCS는 기본적으로 Patch Set(파일에서 변경되는 부분)을 관리한다. 이 Patch Set은 특별한 형식의 파일로 저장한다. 그리고 일련의 Patch Set을 적용해서 모든 파일을 특정 시점으로 되돌릴 수 있다.
 
@@ -24,7 +24,7 @@ Insert 18333fig0101.png
 프로젝트를 진행하다 보면 다른 개발자와 함께 작업해야 하는 경우가 많다. 이럴 때 생기는 문제를 해결하기 위해 CVCS(중앙집중식 VCS)가 개발됐다. CVS, Subversion, Perforce 같은 시스템은 파일을 관리하는 서버가 별도로 있고 클라이언트가 중앙 서버에서 파일을 받아서 사용(Checkout)한다. 수년 동안 이러한 시스템들이 많은 사랑을 받았다.
 
 Insert 18333fig0102.png 
-그림 1-2 중앙집중식 버전 관리(CVCS) 다이어그램
+그림 1-2. 중앙집중식 버전 관리(CVCS) 다이어그램
 
 CVCS 환경은 로컬 VCS에 비해 장점이 많다. 프로젝트에 참여한 사람이면 누가 무엇을 하고 있는지 알 수 있다. 관리자는 누가 무엇을 할 수 있는지 꼼꼼하게 관리할 수 있다. 모든 클라이언트의 로컬 데이터베이스를 관리하는 것보다 VCS 하나를 관리하기가 훨씬 쉽다.
 
@@ -35,7 +35,7 @@ CVCS 환경은 로컬 VCS에 비해 장점이 많다. 프로젝트에 참여한
 DVCS(분산 버전 관리 시스템)을 설명할 차례다. Git, Mecurial, Bazaar, Darcs 같은 DVCS에서는 클라이언트가 파일의 마지막 스냅샷을 Checkout하지 않는다. 그냥 저장소를 전부 복제한다. 서버에 문제가 생기면 이 복제물로 다시 작업을 시작할 수 있다. 클라이언트 중에서 아무거나 골라도 서버를 복원할 수 있다. 모든 Checkout은 모든 데이터를 가진 진정한 백업이다.
 
 Insert 18333fig0103.png
-그림 1-3 분산 버전 관리 시스템(DVCS) 다이어그램
+그림 1-3. 분산 버전 관리 시스템(DVCS) 다이어그램
 
 게다가 대부분의 DVCS 환경에서는 리모트 저장소가 존재한다. 리모트 저장소가 많을 수도 있다. 그래서 사람들은 동시에 다양한 그룹과 다양한 방법으로 협업할 수 있다. 계층 모델 같은 중앙집중식 시스템으로는 할 수 없는 몇 가지 워크플로우를 사용할 수 있다.
 
@@ -62,12 +62,12 @@ Git의 핵심은 뭘까? 이 질문은 Git을 이해하는데 굉장히 중요
 Subversion과 Subversion 비슷한 놈들과 Git의 가장 큰 차이점은 데이터를 다루는 방법에 있다. 큰 틀에서 봤을 때 대부분의 VCS 시스템이 관리하는 정보는 파일들의 목록이다. CVS, Subversion, Perforce, Bazaar 등의 시스템은 파일의 집합으로 정보를 관리한다. 각 파일의 변화를 그림 1-4처럼 시간순으로 관리한다.
 
 Insert 18333fig0104.png 
-그림 1-4 각 파일에 대한 변화(델타)를 저장하는 시스템들
+그림 1-4. 각 파일에 대한 변화(델타)를 저장하는 시스템들
 
 Git은 이런 식으로 데이터를 저장하지도 취급하지도 않는다. 대신 Git의 데이터는 파일 시스템의 스냅샷이라 할 수 있으며 크기가 아주 작다. Git은 커밋하거나 프로젝트의 상태를 저장할 때마다 파일이 존재하는 그 순간을 중요하게 여긴다. 파일이 달라지지 않았으면 Git은 성능을 위해서 파일을 저장하지 않는다. 단지 이전 상태의 파일에 대한 링크만 저장한다. Git은 그림 1-5처럼 동작한다.
 
 Insert 18333fig0105.png 
-그림 1-5 Git은 시간순으로 프로젝트의 스냅샷을 저장한다
+그림 1-5. Git은 시간순으로 프로젝트의 스냅샷을 저장한다
 
 이것이 Git이 다른 VCS와 구분되는 점이다. 이점 때문에 Git는 다른 시스템들이 과거로부터 답습해왔던 버전 컨트롤의 개념과 다르다는 것이고 많은 부분을 새로운 관점에서 바라본다. Git은 강력한 도구를 지원하는 작은 파일시스템이다. Git은 단순한 VCS가 아니다. 이제 3장에서 설명할 Git 브랜치를 사용하면 얻게 되는 이득이 무엇인지 설명한다.
 
@@ -102,7 +102,7 @@ Git을 사용하면 프로젝트가 심각하게 망가질 걱정 없이 매우
 이 세 가지 상태는 Git 프로젝트의 세 가지 단계와 연결돼 있다. Git 디렉토리, 워킹 디렉토리, Staging Area 이렇게 세 가지 단계를 이해하고 넘어가자.
 
 Insert 18333fig0106.png
-그림 1-6 워킹 디렉토리, Staging Area, Git 디렉토리
+그림 1-6. 워킹 디렉토리, Staging Area, Git 디렉토리
 
 Git 디렉토리는 Git이 프로젝트의 메타데이터와 객체 데이터베이스를 저장하는 곳을 말한다. Git 디렉토리가 Git의 핵심이다. 다른 컴퓨터에 있는 저장소를 Clone 할 때 Git 디렉토리가 만들어진다.
 
@@ -166,7 +166,7 @@ Mac에 Git을 쉽게 설치하는 방법은 두 가지가 있다. GUI 인스톨
 	http://code.google.com/p/git-osx-installer
 
 Insert 18333fig0107.png 
-그림 1-7 OS X Git 인스톨러
+그림 1-7. OS X Git 인스톨러
 
 MacPorts(`http://www.macports.org`)를 사용하는 방법도 있다. MacPorts가 설치돼 있으면 아래와 같이 Git을 설치한다:
 
diff --git a/ko/02-git-basics/01-chapter2.markdown b/ko/02-git-basics/01-chapter2.markdown
index 88b86ca02..9353c88e3 100644
--- a/ko/02-git-basics/01-chapter2.markdown
+++ b/ko/02-git-basics/01-chapter2.markdown
@@ -47,7 +47,7 @@ Git은 다양한 프로토콜을 지원한다. 이제까지는 `git://` 프로
 마지막 커밋 이후 아직 아무것도 수정하지 않은 상태에서 어떤 파일이 수정되면 Git은 그 즉시 파일을 *Modified* 상태로 인식한다. 그리고 이 수정한 파일을 Stage하고 *Staged* 상태인 파일을 커밋한다. 이 라이프사이클을 그림 2-1처럼 계속 반복한다.
 
 Insert 18333fig0201.png
-그림 2-1 파일의 라이프사이클
+그림 2-1. 파일의 라이프사이클
 
 ### 파일의 상태 확인하기 ###
 
@@ -669,7 +669,7 @@ The lines must be formatted as follows
 GUI 도구로 커밋 히스토리를 시각화하고 싶다면 gitk를 사용할 수 있다. gitk는 Tcl/Tk 프로그램이고 `git log` 명령을 시각화해주는 도구다. gitk는 `git log` 명령이 지원하는 필터링 옵션을 거의 모두 지원한다. 프로젝트 디렉토리에서 gitk를 실행하면 그림 2-2처럼 보일 것이다.
 
 Insert 18333fig0202.png
-그림 2-2 gitk의 히스토리
+그림 2-2. gitk의 히스토리
 
 위쪽 반을 차지하는 윈도에서는 히스토리를 그래프로 예쁘게 보여준다. 아래쪽 반을 차지하는 윈도는 diff 결과를 보여주는데 위쪽 윈도에서 선택한 커밋에 대한 diff 결과를 보여준다.
 
diff --git a/ko/03-git-branching/01-chapter3.markdown b/ko/03-git-branching/01-chapter3.markdown
index a9cc52748..9a66a6841 100644
--- a/ko/03-git-branching/01-chapter3.markdown
+++ b/ko/03-git-branching/01-chapter3.markdown
@@ -22,17 +22,17 @@ Git이 브랜치하는 과정을 이해하려면 우선 Git이 데이터를 어
 이 작업을 마치고 나면 Git 저장소에는 다섯 개의 데이터 개체가 생긴다. 각 파일에 대한 Blob 세 개, 파일과 디렉토리 구조가 들어 있는 트리 개체 하나, 메타데이터와 루트 트리를 가리키는 포인터가 담긴 커밋 개체 하나이다. 이것을 그림으로 그리면 그림 3-1과 같다.
 
 Insert 18333fig0301.png
-그림 3-1 저장소의 커밋 데이터
+그림 3-1. 저장소의 커밋 데이터
 
 다시 파일을 수정하고 커밋하면 이전 커밋이 무엇인지도 저장한다. 커밋을 두 번 더 하면 그림 3-2과 같이 저장된다.
 
 Insert 18333fig0302.png
-그림 3-2 Git 커밋의 개체 데이터
+그림 3-2. Git 커밋의 개체 데이터
 
 Git의 브랜치는 커밋 사이를 가볍게 이동할 수 있는 어떤 포인터 같은 것이다. 기본적으로 Git은 `master` 브랜치를 만든다. 최초로 커밋하면 Git은 master라는 이름의 브랜치를 만들어서 자동으로 가장 마지막 커밋을 가리키게 한다.
 
 Insert 18333fig0303.png
-그림 3-3 가장 최근 커밋 정보를 가리키는 브랜치
+그림 3-3. 가장 최근 커밋 정보를 가리키는 브랜치
 
 브랜치를 하나 새로 만들면 어떨까? 브랜치를 하나 만들어서 놀자. 다음과 같이 `git branch` 명령으로 testing 브랜치를 만든다.
 
@@ -41,12 +41,12 @@ Insert 18333fig0303.png
 새로 만든 브랜치도 지금 작업하고 있던 마지막 커밋을 가리킨다(그림 3-4).
 
 Insert 18333fig0304.png
-그림 3-4 커밋 개체를 가리키는 두 브랜치
+그림 3-4. 커밋 개체를 가리키는 두 브랜치
 
 지금 작업 중인 브랜치가 무엇인지 Git은 어떻게 파악할까? 다른 버전 관리 시스템과는 달리 Git은 'HEAD'라는 특수한 포인터가 있다. 이 포인터는 지금 작업하는 로컬 브랜치를 가리킨다. 브랜치를 새로 만들었지만, Git은 아직 master 브랜치를 가리키고 있다. `git branch` 명령은 브랜치를 만들기만 하고 브랜치를 옮기지 않는다.
 
 Insert 18333fig0305.png
-그림 3-5 HEAD는 현재 작업 중인 브랜치를 가리킴
+그림 3-5. HEAD는 현재 작업 중인 브랜치를 가리킴
 
 `git checkout` 명령으로 새로 만든 브랜치로 이동할 수 있다. testing 브랜치로 이동하려면 다음과 같이 한다:
 
@@ -55,7 +55,7 @@ Insert 18333fig0305.png
 이렇게 하면 HEAD는 testing 브랜치를 가리킨다.
 
 Insert 18333fig0306.png
-그림 3-6 HEAD는 옮겨간 다른 브랜치를 가리킨다
+그림 3-6. HEAD는 옮겨간 다른 브랜치를 가리킨다
 
 자, 이제 핵심이 보일 거다! 커밋을 새로 한 번 해보면:
 
@@ -65,7 +65,7 @@ Insert 18333fig0306.png
 결과는 그림 3-7과 같다.
 
 Insert 18333fig0307.png
-그림 3-7 HEAD가 가리키는 testing 브랜치가 새 커밋을 가리킨다
+그림 3-7. HEAD가 가리키는 testing 브랜치가 새 커밋을 가리킨다
 
 이 부분이 흥미롭다. 새로 커밋해서 testing 브랜치는 앞으로 이동했다. 하지만, `master` 브랜치는 여전히 이전 커밋을 가리킨다. `master` 브랜치로 되돌아가면:
 
@@ -74,7 +74,7 @@ Insert 18333fig0307.png
 결과는 그림 3-8과 같다.
 
 Insert 18333fig0308.png
-그림 3-8 HEAD가 Checkout한 브랜치로 이동함
+그림 3-8. HEAD가 Checkout한 브랜치로 이동함
 
 방금 실행한 명령이 한 일은 두 가지다. master 브랜치가 가리키는 커밋을 HEAD가 가리키게 하고 워킹 디렉토리의 파일도 그 시점으로 되돌려 놓았다. 앞으로 커밋을 하면 다른 브랜치의 작업들과 별개로 진행되기 때문에 testing 브랜치에서 임시로 작업하고 원래 master 브랜치로 돌아와서 하던 일을 계속할 수 있다.
 
@@ -86,7 +86,7 @@ Insert 18333fig0308.png
 프로젝트 히스토리는 분리돼 진행한다(그림 3-9). 우리는 브랜치를 하나 만들어 그 브랜치에서 일을 좀 하고, 다시 원래 브랜치로 되돌아와서 다른 일을 했다. 두 작업 내용은 서로 독립적으로 각 브랜치에 존재한다. 커밋 사이를 자유롭게 이동하다가 때가 되면 두 브랜치를 Merge한다. 간단히 `branch`와 `checkout` 명령을 써서 말이다.
 
 Insert 18333fig0309.png
-그림 3-9 브랜치 히스토리가 서로 독립적임
+그림 3-9. 브랜치 히스토리가 서로 독립적임
 
 실제로 Git의 브랜치는 어떤 한 커밋을 가리키는 40글자의 SHA-1 체크섬 파일에 불과하기 때문에 만들기도 쉽고 지우기도 쉽다. 새로 브랜치를 하나 만드는 것은 41바이트 크기의 파일을(40자와 줄 바꿈 문자) 하나 만드는 것에 불과하다.
 
@@ -114,7 +114,7 @@ Insert 18333fig0309.png
 먼저 커밋을 몇 번 했다고 가정하자.
 
 Insert 18333fig0310.png
-그림 3-10 현재 커밋 히스토리
+그림 3-10. 현재 커밋 히스토리
 
 이슈 관리 시스템에 등록된 53번 이슈를 처리한다고 하면 이 이슈에 집중할 수 있는 브랜치를 새로 하나 만든다. Git은 어떤 이슈 관리 시스템에도 종속돼 있지 않다. 브랜치를 만들면서 Checkout까지 한 번에 하려면 `git checkout` 명령에 `-b`라는 옵션을 준다.
 
@@ -129,7 +129,7 @@ Insert 18333fig0310.png
 그림 3-11은 위 명령의 결과를 나타낸다.
 
 Insert 18333fig0311.png
-그림 3-11 브랜치 포인터를 새로 만듦
+그림 3-11. 브랜치 포인터를 새로 만듦
 
 iss53 브랜치를 Checkout했기 때문에(즉, HEAD는 iss53 브랜치를 가리킨다) 뭔가 일을 하고 커밋하면 iss53 브랜치가 앞으로 진행한다:
 
@@ -137,7 +137,7 @@ iss53 브랜치를 Checkout했기 때문에(즉, HEAD는 iss53 브랜치를 가
 	$ git commit -a -m 'added a new footer [issue 53]'
 
 Insert 18333fig0312.png
-그림 3-12 진행 중인 iss53 브랜치
+그림 3-12. 진행 중인 iss53 브랜치
 
 다른 상황을 가정해보자. 만드는 사이트에 문제가 생겨서 즉시 고쳐야 한다. 버그를 해결한 Hotfix에 'iss53'이 섞이는 것을 방지하기 위해 'iss53'와 관련된 코드를 어딘가에 저장해두고 원래 운영 환경의 소스로 복구해야 한다. Git을 사용하면 이런 노력을 들일 필요 없이 그냥 master 브랜치로 옮기면 된다.
 
@@ -158,7 +158,7 @@ hotfix라는 브랜치를 만들고 새로운 이슈를 해결할 때까지 사
 	 1 files changed, 0 insertions(+), 1 deletions(-)
 
 Insert 18333fig0313.png
-그림 3-13 master 브랜치에서 갈라져 나온 hotfix 브랜치
+그림 3-13. master 브랜치에서 갈라져 나온 hotfix 브랜치
 
 운영 환경에 적용하려면 문제를 제대로 고쳤는지 테스트하고 master 브랜치에 합쳐야 한다. `git merge` 명령으로 다음과 같이 한다:
 
@@ -174,7 +174,7 @@ Merge 메시지에서 'Fast forward'가 보이는가? Merge할 브랜치가 가
 이제 hotfix는 master 브랜치에 포함됐고 운영환경에 적용할 수 있다(그림 3-14).
 
 Insert 18333fig0314.png
-그림 3-14 Merge 후 hotfix 브랜치와 같은 것을 가리키는 master 브랜치
+그림 3-14. Merge 후 hotfix 브랜치와 같은 것을 가리키는 master 브랜치
 
 문제를 급히 해결하고 master 브랜치에 적용하고 나면 다시 일하던 브랜치로 돌아가야 한다. 하지만, 그전에 필요없는 hotfix 브랜치를 삭제한다. `git branch` 명령에 `-d` 옵션을 주고 브랜치를 삭제한다.
 
@@ -191,7 +191,7 @@ Insert 18333fig0314.png
 	 1 files changed, 1 insertions(+), 0 deletions(-)
 
 Insert 18333fig0315.png
-그림 3-15 master와 별개로 진행하는 iss53 브랜치
+그림 3-15. master와 별개로 진행하는 iss53 브랜치
 
 위에서 작업한 hotfix가 iss53 브랜치에 영향을 끼치지 않는다는 점을 이해하는 것이 중요하다. `git merge master` 명령으로 master 브랜치를 iss53 브랜치에 Merge하면 iss53 브랜치에 hotfix가 적용된다. 아니면 iss53 브랜치가 master에 Merge할 수 있는 수준이 될 때까지 기다렸다가 Merge하면 hotfix와 iss53가 합쳐진다.
 
@@ -208,14 +208,14 @@ Insert 18333fig0315.png
 hotfix를 Merge했을 때와 메시지가 다르다. 현 브랜치가 가리키는 커밋이 Merge할 브랜치의 조상이 아니므로 Git은 'Fast-forward'로 Merge하지 않는다. 이러면 Git은 각 브랜치가 가리키는 커밋 두 개와 공통 조상 하나를 사용하여 3-way Merge를 한다. 그림 3-16에 이 Merge에서 사용하는 커밋 세 개가 표시된다.
 
 Insert 18333fig0316.png
-그림 3-16 Git은 Merge에 필요한 공통 커밋을 자동으로 찾음
+그림 3-16. Git은 Merge에 필요한 공통 커밋을 자동으로 찾음
 
 단순히 브랜치 포인터를 최신 커밋으로 옮기는 게 아니라 3-way Merge의 결과를 별도의 커밋으로 만들고 나서 해당 브랜치가 그 커밋을 가리키도록 이동시킨다(그림 3-17). 그래서 이런 커밋은 부모가 여러 개고 Merge 커밋이라고 부른다.
 
 Git은 Merge하는데 필요한 최적의 공통 조상을 자동으로 찾는다. 이런 기능도 Git이 다른 버전 관리 시스템보다 나은 점이다. CVS나 Subversion 같은 버전 관리 시스템은 개발자가 직접 공통 조상을 찾아서 Merge해야 한다. Git은 다른 시스템보다 Merge가 대단히 쉽다.
 
 Insert 18333fig0317.png
-그림 3-17 Git은 Merge할 때 Merge에 대한 정보가 들어 있는 커밋를 하나 만든다.
+그림 3-17. Git은 Merge할 때 Merge에 대한 정보가 들어 있는 커밋를 하나 만든다.
 
 iss53 브랜치를 master에 Merge하고 나면 더는 iss53 브랜치가 필요 없다. 다음 명령으로 브랜치를 삭제하고 이슈의 상태를 처리 완료로 표시한다:
 
@@ -350,12 +350,12 @@ Git은 꼼꼼하게 3-way Merge를 사용하기 때문에 장기간에 걸쳐서
 사실 우리가 얘기하는 것은 커밋을 가리키는 포인터에 대한 얘기다. 개발 브랜치는 공격적으로 히스토리를 만들어 나아가고 안정 브랜치는 이미 만든 히스토리를 뒤따르며 나아간다.
 
 Insert 18333fig0318.png
-그림 3-18 안정적인 브랜치일수록 커밋 히스토리가 뒤쳐진다
+그림 3-18. 안정적인 브랜치일수록 커밋 히스토리가 뒤쳐진다
 
 실험실에서 충분히 테스트하고 실전에 배치하는 과정으로 보면 이해하기 쉽다(그림 3-19).
 
 Insert 18333fig0319.png
-그림 3-19 각 브랜치를 하나의 실험실로 생각하라
+그림 3-19. 각 브랜치를 하나의 실험실로 생각하라
 
 코드를 여러 단계로 나누어 안정성을 높여가며 운영할 수 있다. 큰 규모의 프로젝트라면 proposed 혹은 pu(proposed updates)라는 이름의 브랜치를 두어 next나 master 브랜치에 아직 Merge할 준비가 되지 않은 것을 일단 Merge시킨다.
 
@@ -370,12 +370,12 @@ Insert 18333fig0319.png
 master 브랜치를 checkout한 상태에서 어떤 작업을 한다고 해보자. 한 이슈를 처리하기 위해서 iss91라는 브랜치를 만들고 해당 작업을 한다. 같은 이슈를 다른 방법으로 해결해보고 싶을 때도 있다. iss91v2라는 브랜치를 만들고 다른 방법을 시도해 본다. 확신할 수 없는 아이디어를 적용해보기 위해 다시 master 브랜치로 되돌아가서 dumbidea 브랜치를 하나 더 만든다. 지금까지 말했던 커밋 히스토리는 그림 3-20과 같다.
 
 Insert 18333fig0320.png
-그림 3-20 여러 토픽 브랜치에 대한 커밋 히스토리
+그림 3-20. 여러 토픽 브랜치에 대한 커밋 히스토리
 
 이슈를 처리했던 방법 중 두 번째 방법인 iss91v2 브랜치가 괜찮아서 적용하기로 결정을 내렸다. 그리고 아이디어를 확신할 수 없었던 dumbidea 브랜치를 같이 일하는 다른 개발자에게 보여줬더니 썩 괜찮다는 반응을 얻었다. iss91 브랜치는 (C5, C6 커밋도 함께) 버리고 다른 두 브랜치를 Merge하면 그림 3-21과 같이 된다.
 
 Insert 18333fig0321.png
-그림 3-21 dumbidea와 iss91v2 브랜치를 Merge하고 난 후의 모습
+그림 3-21. dumbidea와 iss91v2 브랜치를 Merge하고 난 후의 모습
 
 지금까지 한 작업은 전부 로컬에서만 처리한다는 것을 꼭 기억하자. 로컬 저장소에서만 브랜치를 만들고 Merge했으며 서버와 통신을 주고받는 일은 없었다.
 
@@ -388,29 +388,29 @@ Insert 18333fig0321.png
 다소 헷갈릴 수 있으니 예제를 좀 더 살펴보자. `git.ourcompany.com`이라는 Git 서버가 있고 이 서버의 저장소를 하나 Clone하면 Git은 자동으로 origin이라는 이름을 붙인다. origin으로부터 저장소 데이터를 모두 내려받고 master 브랜치를 가리키는 포인터를 만든다. 이 포인터는 origin/master라고 부르고 멋대로 조종할 수 없다. 그리고 Git은 로컬의 master 브랜치가 origin/master를 가리키게 한다. 이제 이 master 브랜치에서 작업을 시작할 수 있다.
 
 Insert 18333fig0322.png
-그림 3-22 저장소를 Clone하면 로컬 master 브랜치, 리모트 저장소의 master 브랜치를 가리키는 origin/master 브랜치가 생김
+그림 3-22. 저장소를 Clone하면 로컬 master 브랜치, 리모트 저장소의 master 브랜치를 가리키는 origin/master 브랜치가 생김
 
 로컬 저장소에서 어떤 작업을 하고 있는데 동시에 다른 팀원이 `git.ourcompany.com` 서버에 Push하고 master 브랜치를 업데이트한다. 그러면 이제 팀원 간의 히스토리는 서로 달라진다. 서버 저장소로부터 어떤 데이터도 주고받지 않아서 origin/master 포인터는 그대로다.
 
 Insert 18333fig0323.png
-그림 3-24 로컬과 서버의 커밋 히스토리는 독립적임
+그림 3-23. 로컬과 서버의 커밋 히스토리는 독립적임
 
 리모트 서버로부터 저장소 정보를 동기화하려면 `git fetch origin` 명령을 사용한다. 명령을 실행하면 우선 origin 서버의 주소 정보(이 예에서는 `git.ourcompany.com`)를 찾아서, 현재 로컬의 저장소가 갖고 있지 않은 새로운 정보가 있으면 모두 내려받고, 받은 데이터를 로컬 저장소에 업데이트하고 나서, origin/master 포인터의 위치를 최신 커밋으로 이동시킨다.
 
 Insert 18333fig0324.png
-그림 3-24 Git의 Fetch 명령은 리모트 브랜치 정보를 업데이트한다
+그림 3-24. Git의 Fetch 명령은 리모트 브랜치 정보를 업데이트한다
 
 리모트 저장소를 여러 개 운영하는 상황을 이해할 수 있도록 개발용으로 사용할 Git 저장소를 팀 내부에 하나 추가해 보자.
 
 이 저장소의 주소가 `git.team1.ourcompany.com` 이면 *2장*에서 살펴본 `git remote add` 명령으로 현재 작업 중인 프로젝트에 팀의 저장소를 추가한다. 이름을 teamone으로 짓고 긴 서버 주소 대신 사용한다.
 
 Insert 18333fig0325.png
-그림 3-25 서버를 리모트 저장소로 추가하기
+그림 3-25. 서버를 리모트 저장소로 추가하기
 
 서버를 추가하고 나면 git fetch teamone 명령으로 teamone 서버의 데이터를 내려받는다. 명령을 실행해도 teamone 서버의 데이터는 모두 origin 서버에도 있는 것들이라서 아무것도 내려받지 않는다. 하지만, 이 명령은 teamone/master 브랜치가 teamone 서버의 master 브랜치가 가리키는 커밋을 가리키게 한다.
 
 Insert 18333fig0326.png
-그림 3-26 로컬 저장소에 만들어진 teamone의 master 브랜치를 가리키는 포인터
+그림 3-26. 로컬 저장소에 만들어진 teamone의 master 브랜치를 가리키는 포인터
 
 ### Push하기 ###
 
@@ -487,12 +487,12 @@ Git에서 한 브랜치에서 다른 브랜치로 합치는 방법은 두 가지
 앞의 Merge 절에서 살펴본 예제로 다시 돌아가 보자(그림 3-27). 두 개의 나누어진 브랜치의 모습을 볼 수 있다.
 
 Insert 18333fig0327.png
-그림 3-27 두 개의 브랜치로 나누어진 커밋 히스토리
+그림 3-27. 두 개의 브랜치로 나누어진 커밋 히스토리
 
 이 두 브랜치를 합치는 가장 쉬운 방법은 앞에서 살펴본 대로 Merge 명령을 사용하는 것이다. 두 브랜치의 마지막 커밋 두 개(C3, C4)와 공통 조상(C2)을 사용하는 3-way Merge로 그림 3-28처럼 새로운 커밋을 만들어 낸다.
 
 Insert 18333fig0328.png
-그림 3-28 나뉜 브랜치를 Merge하기
+그림 3-28. 나뉜 브랜치를 Merge하기
 
 비슷한 결과를 만드는 다른 방식으로, C3에서 변경된 사항을 패치(Patch)로 만들고 이를 다시 C4에 적용시키는 방법이 있다. Git에서는 이런 방식을 _Rebase_ 라고 한다. Rebase 명령으로 한 브랜치에서 변경된 사항을 다른 브랜치에 적용할 수 있다.
 
@@ -506,12 +506,12 @@ Insert 18333fig0328.png
 실제로 일어나는 일을 설명하자면 일단 두 브랜치가 나뉘기 전인 공통 커밋으로 이동하고 나서 그 커밋부터 지금 Checkout한 브랜치가 가리키는 커밋까지 diff를 차례로 만들어 어딘가에 임시로 저장해 놓는다. Rebase할 브랜치(역주 - experiment)가 합칠 브랜치(역주 - master)가 가리키는 커밋을 가리키게 하고 아까 저장해 놓았던 변경사항을 차례대로 적용한다. 그림 3-29는 이러한 과정을 나타내고 있다.
 
 Insert 18333fig0329.png
-그림 3-29 C3의 변경사항을 C4에 적용하는 Rebase 과정
+그림 3-29. C3의 변경사항을 C4에 적용하는 Rebase 과정
 
 그리고 나서 master 브랜치를 Fast-forward 시킨다.
 
 Insert 18333fig0330.png
-그림 3-30 master 브랜치를 Fast-forward시키기
+그림 3-30. master 브랜치를 Fast-forward시키기
 
 C3'로 표시된 커밋에서의 내용은 Merge 예제에서 살펴본 C5 커밋에서의 내용과 같을 것이다. Merge이든 Rebase든 둘 다 합치는 관점에서는 서로 다를 게 없다. 하지만, Rebase가 좀 더 깨끗한 히스토리를 만든다. Rebase한 브랜치의 Log를 살펴보면 히스토리가 선형적이다. 일을 병렬로 동시에 진행해도 Rebase하고 나면 모든 작업이 차례대로 수행된 것처럼 보인다.
 
@@ -524,7 +524,7 @@ Rebase를 하든지, Merge를 하든지 최종 결과물은 같고 커밋 히스
 Rebase는 단순히 브랜치를 합치는 것만 아니라 다른 용도로도 사용할 수 있다. 그림 3-31과 같은 히스토리가 있다고 하자. server 브랜치를 만들어서 서버 기능을 추가하고 그 브랜치에서 다시 client 브랜치를 만들어 클라이언트 기능을 추가한다. 마지막으로 server 브랜치로 돌아가서 몇 가지 기능을 더 추가한다.
 
 Insert 18333fig0331.png
-그림 3-31 다른 토픽 브랜치에서 갈라져 나온 토픽 브랜치
+그림 3-31. 다른 토픽 브랜치에서 갈라져 나온 토픽 브랜치
 
 이때 테스트가 덜 된 server 브랜치는 그대로 두고 client 브랜치만 master로 합치려는 상황을 생각해보자. server와는 아무 관련이 없는 client 커밋은 C8, C9이다. 이 두 커밋을 master 브랜치에 적용하기 위해서 `--onto` 옵션을 사용하여 아래와 같은 명령을 실행한다:
 
@@ -533,7 +533,7 @@ Insert 18333fig0331.png
 이 명령은 client 브랜치를 Checkout하고 server와 client의 공통조상 이후의 패치를 만들어 master에 적용한다. 조금 복잡하긴 해도 꽤 쓸모 있다. 그림 3-32를 보자.
 
 Insert 18333fig0332.png
-그림 3-32 다른 토픽 브랜치에서 갈라져 나온 토픽 브랜치를 Rebase하기
+그림 3-32. 다른 토픽 브랜치에서 갈라져 나온 토픽 브랜치를 Rebase하기
 
 이제 master 브랜치로 돌아가서 Fast-forward 시킬 수 있다:
 
@@ -541,7 +541,7 @@ Insert 18333fig0332.png
 	$ git merge client
 
 Insert 18333fig0333.png
-그림 3-33 master 브랜치를 client 브랜치 위치로 진행 시키기
+그림 3-33. master 브랜치를 client 브랜치 위치로 진행 시키기
 
 server 브랜치의 일이 다 끝나면 `git rebase [basebranch] [topicbranch]`라는 명령으로 Checkout하지 않고 바로 server 브랜치를 master 브랜치로 rebase할 수 있다. 이 명령은 토픽(server) 브랜치를 Checkout하고 베이스(master) 브랜치에 Rebase한다:
 
@@ -550,7 +550,7 @@ server 브랜치의 일이 다 끝나면 `git rebase [basebranch] [topicbranch]`
 server 브랜치의 수정사항을 master 브랜치에 적용했다. 그 결과는 그림 3-34와 같다.
 
 Insert 18333fig0334.png
-그림 3-34 master 브랜치에 server 브랜치의 수정 사항을 적용
+그림 3-34. master 브랜치에 server 브랜치의 수정 사항을 적용
 
 그리고 나서 master 브랜치를 Fast-forward 시킨다:
 
@@ -563,7 +563,7 @@ Insert 18333fig0334.png
 	$ git branch -d server
 
 Insert 18333fig0335.png
-그림 3-35 최종 커밋 히스토리
+그림 3-35. 최종 커밋 히스토리
 
 ### Rebase의 위험성 ###
 
@@ -578,22 +578,22 @@ Rebase는 기존의 커밋을 그대로 사용하는 것이 아니라 내용은
 이미 공개 저장소에 Push한 커밋을 Rebase하면 어떤 결과가 초래되는지 예제를 통해 알아보자. 중앙 저장소에서 Clone하고 일부 수정을 하면 커밋 히스토리는 그림 3-36과 같아 진다.
 
 Insert 18333fig0336.png
-그림 3-36 저장소를 Clone하고 일부 수정함
+그림 3-36. 저장소를 Clone하고 일부 수정함
 
 이제 팀원 중 누군가 커밋, Merge하고 나서 서버에 Push 한다. 이 리모트 브랜치를 Fetch, Merge하면 그림 3-37과 같이 된다.
 
 Insert 18333fig0337.png
-그림 3-37 Fetch한 후 Merge함
+그림 3-37. Fetch한 후 Merge함
 
 그런데 Push했던 팀원은 Merge한 일을 되돌리고 다시 Rebase한다. 서버의 히스토리를 새로 덮어씌우려면 `git push --force` 명령을 사용해야 한다. 이후에 저장소에서 Fetch하고 나면 아래 그림과 같은 상태가 된다:
 
 Insert 18333fig0338.png
-그림 3-38 한 팀원이 다른 팀원이 의존하는 커밋을 없애고 Rebase한 커밋을 다시 Push함
+그림 3-38. 한 팀원이 다른 팀원이 의존하는 커밋을 없애고 Rebase한 커밋을 다시 Push함
 
 기존 커밋이 사라졌기 때문에 이미 처리한 일이라고 해도 다시 Merge해야 한다. Rebase는 커밋의 SHA-1 해시를 바꾸기 때문에 Git은 새로운 커밋으로 생각한다. 사실 C4는 이미 히스토리에 적용되어 있지만, Git은 모른다.
 
 Insert 18333fig0339.png
-그림 3-39 같은 Merge를 다시 한다
+그림 3-39. 같은 Merge를 다시 한다
 
 다른 개발자와 계속 같이 일하려면 이런 Merge도 해야만 한다. Merge하면 C4와 C4' 커밋 둘 다 히스토리에 남게 된다. 실제 내용과 메시지가 같지만 SHA-1 해시 값이 전혀 다르다. `git log`로 히스토리를 확인해보면 저자, 커밋 날짜, 메시지가 같은 커밋이 두 개 있을 것이다. 이렇게 되면 혼란스럽다. 게다가 이 히스토리를 서버에 Push하면 같은 커밋이 두 개 있기 때문에 다른 사람들도 혼란스러워한다.
 
diff --git a/ko/04-git-server/01-chapter4.markdown b/ko/04-git-server/01-chapter4.markdown
index 8ad6b1c68..2755518da 100644
--- a/ko/04-git-server/01-chapter4.markdown
+++ b/ko/04-git-server/01-chapter4.markdown
@@ -312,7 +312,7 @@ Apache를 재시작하면 아래와 같은 URL로 저장소를 Clone할 수 있
 프로젝트 저장소를 단순히 읽거나 쓰는 것에 대한 설정은 다뤘다. 이제는 웹 기반 인터페이스를 설정해보자. Git에는 GitWeb이라는 CGI 스크립트를 제공해서 쉽게 웹에서 저장소를 조회하도록 할 수 있다. `http://git.kernel.org`같은 사이트에서 GitWeb을 구경할 수 있다(그림 4-1).
 
 Insert 18333fig0401.png
-그림 4-1 Git 웹용 UI, GitWeb
+그림 4-1. Git 웹용 UI, GitWeb
 
 Git은 GitWeb을 쉽게 사용해 볼 수 있도록 서버를 잠시 띄우는 명령을 제공한다. 시스템에 `lighttpd`나 `webrick` 같은 경량 웹서버가 설치돼 있어야 이 명령을 사용할 수 있다. 리눅스에서는 `lighttpd`가 설치돼 있을 확률이 높고 프로젝트 디렉토리에서 그냥 `git instaweb`을 실행하면 바로 실행된다. Mac의 Leopard 버전은 Ruby가 미리 설치돼 있기 때문에 `webrick`이 더 낫다. lighttpd이 아니라면 아래와 같이 `--httpd` 옵션을 사용해야 한다:
 
@@ -734,17 +734,17 @@ GitHub은 이윤을 목적으로 하는 회사이기 때문에 비공개 저장
 먼저 무료 계정을 하나 만든다. 가격 정책에 대해 알려주며 가입을 시작할 수 있는 `http://github.com/plans`에 방문하여 "Sign up" 버튼을 클릭한다. 그러면 가입 페이지로 이동한다.
 
 Insert 18333fig0402.png
-그림 4-2 GitHub 가격 정책 페이지
+그림 4-2. GitHub 가격 정책 페이지
 
 아직 등록되지 않은 사용자 이름을 입력하고 e-mail 주소와 암호를 입력한다(그림 4-3).
 
 Insert 18333fig0403.png
-그림 4-3 GitHub 가입 폼
+그림 4-3. GitHub 가입 폼
 
 그리고 SSH 공개키가 있으면 바로 등록한다. SSH 키를 만드는 방법은 "바로 설정하기" 절에서 이미 설명했다. 그 공개키 파일의 내용을 복사해서 SSH 공개키 입력 박스에 붙여 넣는다. "explain ssh keys" 링크를 클릭하면 key를 생성하는 방법을 자세히 설명해준다. 주요 운영체제에서 하는 방법이 모두 설명돼 있다. "I agree, sign me up" 버튼을 클릭하면 자신만의 대쉬보드 페이지가 나타난다.
 
 Insert 18333fig0404.png
-그림 4-4 GitHub 사용자 대쉬보드
+그림 4-4. GitHub 사용자 대쉬보드
 
 그리고 저장소를 만들자.
 
@@ -753,17 +753,17 @@ Insert 18333fig0404.png
 `Your Repositories`옆에 있는 "create a new one" 링크를 클릭하면 저장소를 만드는 입력 폼을 볼 수 있다(그림 4-5).
 
 Insert 18333fig0405.png
-그림 4-5 GitHub의 저장소를 생성하는 폼
+그림 4-5. GitHub의 저장소를 생성하는 폼
 
 이 폼에 프로젝트 이름과 프로젝트 설명을 적는다. 다 적은 후에 "Create Repository" 버튼을 클릭하면 GitHub에 저장소가 생긴다.
 
 Insert 18333fig0406.png
-그림 4-6 GitHub 프로젝트 정보
+그림 4-6. GitHub 프로젝트 정보
 
 이 저장소에는 아직 코드가 없어서 GitHub은 프로젝트를 새로 만드는 방법, 이미 있는 Git 프로젝트를 Push하는 법, 공개된 Subversion 저장소에서 프로젝트를 가져오는(Import) 방법 등을 보여준다.
 
 Insert 18333fig0407.png
-그림 4-7 새 저장소를 위한 사용설명서
+그림 4-7. 새 저장소를 위한 사용설명서
 
 여기 설명하는 내용은 이미 우리가 배웠다. 프로젝트가 없을 때는 아래와 같이 프로젝트를 초기화한다:
 
@@ -779,7 +779,7 @@ Insert 18333fig0407.png
 이제 프로젝트가 GitHub에서 서비스되니 공유하고 싶은 사람에게 URL을 알려 주면 된다. URL은 `http://github.com/testinguser/iphone_project`이다. 그리고 이 저장소의 정보를 잘 살펴보면 Git URL이 두 개라는 것을 발견할 수 있다.
 
 Insert 18333fig0408.png
-그림 4-8 프로젝트의 공개 URL과 비공개 URL
+그림 4-8. 프로젝트의 공개 URL과 비공개 URL
 
 `Public Clone URL`은 말 그대로 누구나 프로젝트를 Clone할 수 있도록 모두에게 읽기 전용으로 공개하는 것이다. 이 URL을 다른 사람에 알려주거나 웹사이트 같은데 공개하는 것을 부담스러워 하지 않아도 된다.
 
@@ -790,7 +790,7 @@ Insert 18333fig0408.png
 GitHub은 공개 중인 Subversion 프로젝트를 Git 프로젝트로 만들어 준다. 사용설명서 하단에 있는 "Subversion에서 Import하기" 링크를 클릭하면 임포트 폼을 볼 수 있고 거기에 Subversion 프로젝트의 URL을 넣는다(그림 4-9).
 
 Insert 18333fig0409.png
-그림 4-9 Subversion 프로젝트를 Import하는 화면
+그림 4-9. Subversion 프로젝트를 Import하는 화면
 
 프로젝트가 비표준 방식을 사용하거나 규모가 너무 크고 비공개라면 이 기능을 사용할 수 없다. *7장*에서 수동으로 임포트하는 방법에 대해 좀 더 자세히 배운다.
 
@@ -801,17 +801,17 @@ Insert 18333fig0409.png
 프로젝트 페이지에 있는 Admin 버튼을 클릭해서 관리 페이지로 이동한다(그림 4-10).
 
 Insert 18333fig0410.png
-그림 4-10 GitHub의 프로젝트 관리 페이지
+그림 4-10. GitHub의 프로젝트 관리 페이지
 
 다른 사람에게 쓰기 권한을 주려면 “Add another collaborator” 링크를 클릭한다. 그러면 텍스트 박스가 새로 나타나는 데 거기에 사용자 이름을 입력한다. 사용자 이름을 입력하기 시작하면 자동으로 시스템에 존재하는 사용자를 찾아서 보여 준다. 원하는 사용자를 찾으면 Add 버튼을 클릭해서 그 사용자를 동료로 만든다.
 
 Insert 18333fig0411.png
-그림 4-11 프로젝트에 동료 추가하기
+그림 4-11. 프로젝트에 동료 추가하기
 
 추가한 사람은 동료 목록 박스에서 모두 확인할 수 있다(그림 4-12).
 
 Insert 18333fig0412.png 
-그림 4-12 프로젝트 동료들
+그림 4-12. 프로젝트 동료들
 
 그리고 만약 다시 혼자 작업하고 싶어지면 "revoke" 링크를 클릭하여 쫓아낸다. 쫓겨나면 더는 Push할 수 없다. 또 기존 프로젝트에 등록된 동료를 그룹으로 묶어 추가할 수도 있다.
 
@@ -820,7 +820,7 @@ Insert 18333fig0412.png
 Subversion에서 Import했거나 로컬의 프로젝트를 Push하고 나면 프로젝트 메인 페이지가 그림 4-13같이 바뀐다.
 
 Insert 18333fig0413.png
-그림 4-13 GitHub의 프로젝트 메인 페이지
+그림 4-13. GitHub의 프로젝트 메인 페이지
 
 사람들이 이 프로젝트에 방문하면 이 페이지가 제일 처음 보인다. 이 페이지는 몇 가지 탭으로 구성된다. Commits 탭은 지금까지의 커밋을 `git log` 명령을 실행시킨 것처럼 최신 것부터 보여준다. Network 탭은 프로젝트를 복제한 사람들과 기여한 사람들을 모두 보여준다. Downloads 탭에는 바이너리 파일이나 프로젝트의 태그 버전을 압축해서 올릴 수 있다. Wiki 탭은 프로젝트에 대한 정보나 문서를 쓰는 곳이다. Graphs 탭은 사람들의 활동을 그림과 통계로 보여준다. 메인 탭인 Source 탭은 프로젝트의 메인 디렉토리를 보여주고 README 파일이 있으면 자동으로 화면에 출력해 준다. 그리고 마지막 커밋 내용도 함께 보여준다.
 
@@ -833,12 +833,12 @@ Insert 18333fig0413.png
 프로젝트 페이지에 들어가서 상단의 "fork" 버튼을 클릭하여 프로젝트를 복제한다(그림 4-14) 그림 4-14의 예는 mojombo/chronic 프로젝트 페이지이다
 
 Insert 18333fig0414.png
-그림 4-14 어떤 저장소든지 "fork" 버튼을 클릭하면 Push할 수 있는 저장소를 얻을 수 있다
+그림 4-14. 어떤 저장소든지 "fork" 버튼을 클릭하면 Push할 수 있는 저장소를 얻을 수 있다
 
 클릭하는 순간, 이 프로젝트를 즉시 Fork한다(그림 4-15).
 
 Insert 18333fig0415.png
-그림 4-15 Fork한 프로젝트
+그림 4-15. Fork한 프로젝트
 
 ### GitHub 요약 ###
 
diff --git a/ko/05-distributed-git/01-chapter5.markdown b/ko/05-distributed-git/01-chapter5.markdown
index d8f7dda7c..c1ea7508a 100644
--- a/ko/05-distributed-git/01-chapter5.markdown
+++ b/ko/05-distributed-git/01-chapter5.markdown
@@ -13,7 +13,7 @@
 중앙집중식 시스템에서는 보통 중앙집중식 협업 모델이라는 한 가지 방식밖에 없다. 중앙 저장소는 딱 하나 있고 변경 사항은 모두 이 중앙 저장소에 집중된다. 개발자는 이 중앙 저장소를 중심으로 작업한다(그림 5-1).
 
 Insert 18333fig0501.png
-그림 5-1 중앙집중식 Workflow
+그림 5-1. 중앙집중식 Workflow
 
 중앙집중식에서 개발자 두 명이 중앙저장소를 Clone하고 각자 수정하는 상황을 생각해보자. 한 개발자가 자신이 한 일을 커밋하고 나서 아무 문제 없이 서버에 Push한다. 그러면 다른 개발자는 자신의 일을 커밋하고 Push하기 전에 첫 번째 개발자가 한 일을 먼저 Merge해야 한다. Merge를 해야 첫 번째 개발자가 작업한 내용을 덮어쓰지 않는다. 이런 개념은 Subversion과 같은 중앙집중식 버전 관리 시스템에서 사용하는 방식이고 Git에서도 당연히 이런 Workflow를 사용할 수 있다.
 
@@ -31,7 +31,7 @@ Git을 사용하면 리모트 저장소를 여러 개 운영할 수 있다. 다
 6. Integration-Manager는 Merge한 사항을 메인 저장소에 Push한다.
 
 Insert 18333fig0502.png
-그림 5-2 Integration-Manager Workflow
+그림 5-2. Integration-Manager Workflow
 
 이 방식은 GitHub 같은 사이트에서 주로 사용하는 방식이다. GitHub는 프로젝트를 Fork하고 수정사항을 반영하여 다시 모두에게 공개하기 좋은 구조로 되어 있다. 이 방식의 장점은 기여자와 Integration-Manager가 각자의 사정에 맞춰 프로젝트를 유지할 수 있다는 점이다. 기여자는 자신의 저장소와 브랜치에서 수정 작업을 계속해 나갈 수 있고 수정사항이 프로젝트에 반영되도록 기다릴 필요가 없다. 관리자는 여유를 가지고 기여자가 Push해 놓은 커밋을 적절한 시점에 Merge한다.
 
@@ -45,7 +45,7 @@ Insert 18333fig0502.png
 4. Dictator는 Merge한 자신의 master 브랜치를 Push하여 다른 모든 개발자가 Rebase할 수 있는 기준으로 만든다.
 
 Insert 18333fig0503.png
-그림 5-3 Benevolent dictator Workflow
+그림 5-3. Benevolent dictator Workflow
 
 이 방식이 일반적이지 않지만 깊은 계층 구조를 가지는 환경이나 규모가 큰 프로젝트에서는 매우 쓸모 있다. 프로젝트 리더가 모든 코드를 통합하기 전에 코드를 부분부분 통합하도록 여러 명의 Lieutenant에게 위임한다.
 
@@ -157,7 +157,7 @@ Jessica씨의 Push는 성공했지만, John씨의 커밋은 서버에서 거절
 Fetch하고 나면 John씨의 로컬 저장소는 그림 5-4와 같이 된다.
 
 Insert 18333fig0504.png
-그림 5-4 Fetch하고 난 John씨의 저장소
+그림 5-4. Fetch하고 난 John씨의 저장소
 
 John씨는 Jessica씨가 저장소로 Push했던 커밋과 를 로컬 저장소에 가져왔다. 하지만, Push하기 전에 Fetch한 브랜치를 Merge해야 한다:
 
@@ -169,7 +169,7 @@ John씨는 Jessica씨가 저장소로 Push했던 커밋과 를 로컬 저장소
 Merge가 잘 이루어지면 John씨의 브랜치는 그림 5-5와 같은 상태가 된다.
 
 Insert 18333fig0505.png
-그림 5-5 origin/master 브랜치를 Merge하고 난 후, John씨의 저장소
+그림 5-5. origin/master 브랜치를 Merge하고 난 후, John씨의 저장소
 
 John씨는 Merge하고 나서 자신이 작업한 코드가 제대로 동작하는지 확인한다. 그 후에 공유하는 저장소에 Push한다:
 
@@ -181,12 +181,12 @@ John씨는 Merge하고 나서 자신이 작업한 코드가 제대로 동작하
 이제 John씨의 저장소는 그림 5-6 처럼 되었다.
 
 Insert 18333fig0506.png
-그림 5-6 Push하고 난 후, John씨의 저장소
+그림 5-6. Push하고 난 후, John씨의 저장소
 
 동시에 Jessica씨는 토픽 브랜치를 하나 만든다. issue54 브랜치를 만들고 세 번에 걸쳐서 커밋한다. 아직 John씨의 커밋을 Fetch하지 않은 상황이기 때문에 그림 5-7과 같은 상황이 된다.
 
 Insert 18333fig0507.png
-그림 5-7 Jessica씨의 저장소
+그림 5-7. Jessica씨의 저장소
 
 Jessica씨는 John씨의 작업을 적용하려면 Fetch를 해야 한다:
 
@@ -199,7 +199,7 @@ Jessica씨는 John씨의 작업을 적용하려면 Fetch를 해야 한다:
 위 명령으로 John씨가 Push한 커밋을 모두 내려받는다. 그러면 Jessica씨의 저장소는 그림 5-8과 같은 상태가 된다.
 
 Insert 18333fig0508.png
-그림 5-8 John씨의 커밋을 Fetch한 후 Jessica씨의 저장소
+그림 5-8. John씨의 커밋을 Fetch한 후 Jessica씨의 저장소
 
 이제 orgin/master와 Merge할 차례다. Jessica씨는 토픽 브랜치 작업을 마치고 어떤 내용이 Merge되는지 `git log` 명령으로 확인한다:
 
@@ -236,7 +236,7 @@ origin/master, issue54 모두 master보다 Fast-forward된 브랜치이기 때
 위와 같이 Merge가 잘 되면 그림 5-9와 같은 상태가 된다.
 
 Insert 18333fig0509.png
-그림 5-9 Merge 이후 Jessica씨의 저장소
+그림 5-9. Merge 이후 Jessica씨의 저장소
 
 origin/master 브랜치가 Jessica씨의 master 브랜치로 나아갈(reachable) 수 있기 때문에 Push는 성공한다(물론 John씨가 그 사이에 Push를 하지 않았다면):
 
@@ -248,12 +248,12 @@ origin/master 브랜치가 Jessica씨의 master 브랜치로 나아갈(reachable
 두 개발자의 커밋과 Merge가 성공적으로 이루어지고 난 후의 결과는 5-10과 같다.
 
 Insert 18333fig0510.png
-그림 5-10 Jessica씨가 서버로 Push하고 난 후의 저장소
+그림 5-10. Jessica씨가 서버로 Push하고 난 후의 저장소
 
 여기서 살펴본 예제가 가장 간단한 상황이다. 토픽 브랜치에서 수정하고 로컬의 master 브랜치에 Merge한다. 작업한 내용을 프로젝트의 공유 저장소에 Push하고자 할 때에는 우선 origin/master 브랜치를 Fetch하고 Merge한다. 그리고 나서 Merge한 결과를 다시 서버로 Push한다. 이런 Workflow가 일반적이고 그림 5-11로 나타낼 수 있다.
 
 Insert 18333fig0511.png
-그림 5-11 여러 개발자가 Git을 사용하는 Workflow
+그림 5-11. 여러 개발자가 Git을 사용하는 Workflow
 
 ### 비공개 대규모 팀 ###
 
@@ -299,7 +299,7 @@ Jessica씨는 자신이 한 일을 featureA라는 브랜치로 Push했다는 이
 그럼 Jessica씨의 저장소는 그림 5-12과 같다.
 
 Insert 18333fig0512.png
-그림 5-12 Jessica씨의 저장소
+그림 5-12. Jessica씨의 저장소
 
 작업을 마치고 Push하려고 하는데 Jesie씨가 이미 일부 작업을 하고 서버에 featureBee 브랜치로 Push했다는 이메일을 보내왔다. Jessica씨는 Jesie씨의 작업을 먼저 Merge해야만 Push할 수 있다. Merge하기 위해서 우선 `git fetch`로 Fetch한다:
 
@@ -364,17 +364,17 @@ Jessica씨는 일부 수정하고, 수정한 내용을 다시 서버로 Push한
 위와 같은 작업을 마치고 나면 Jessica씨의 저장소는 그림 5-13과 같은 모습이 된다.
 
 Insert 18333fig0513.png
-그림 5-13 마지막 Push하고 난 후의 Jessica씨의 저장소
+그림 5-13. 마지막 Push하고 난 후의 Jessica씨의 저장소
 
 그럼 featureA와 featureBee 브랜치가 프로젝트의 메인 브랜치로 Merge할 준비가 되었다고 Integration-Manager에게 알려준다. Integration-Manager가 두 브랜치를 모두 Merge하고 난 후에 메인 브랜치를 Fetch하면 그림 5-14와 같은 모양이 된다.
 
 Insert 18333fig0514.png
-그림 5-14 두 브랜치가 메인 브랜치에 Merge된 후의 저장소
+그림 5-14. 두 브랜치가 메인 브랜치에 Merge된 후의 저장소
 
 수많은 팀의 작업을 동시에 진행하고 나중에 Merge하는 기능을 사용하려고 다른 버전 관리 시스템에서 Git으로 바꾸는 조직들이 많아지고 있다. 팀은 자신의 브랜치로 작업하지만, 메인 브랜치에 영향을 끼치지 않는다는 점이 Git의 장점이다. 그림 5-15는 이런 Workflow을 나타내고 있다.
 
 Insert 18333fig0515.png
-그림 5-15 대규모 팀의 Workflow
+그림 5-15. 대규모 팀의 Workflow
 
 ### 공개 소규모 팀 ###
 
@@ -434,7 +434,7 @@ request-pull 명령은 아규먼트를 두 개 입력받는다. 첫 번째 아
 그림 5-16 처럼 각 토픽은 일종의 실험실이라고 할 수 있다. 각 토픽은 서로 방해하지 않고 독립적으로 수정하고 Rebase할 수 있다:
 
 Insert 18333fig0516.png
-그림 5-16 featureB 수정작업이 끝난 직후 저장소의 모습
+그림 5-16. featureB 수정작업이 끝난 직후 저장소의 모습
 
 프로젝트 관리자가 사람들의 수정사항을 Merge하고 나서 Jessica씨의 브랜치를 Merge하려고 할 때 충돌이 날 수도 있다. 그러면 Jessica씨가 자신의 브랜치를 origin/master에 Rebase해서 충돌을 해결하고 다시 Pull Request을 보낸다:
 
@@ -445,7 +445,7 @@ Insert 18333fig0516.png
 위 명령들을 실행하고 나면 그림 5-17과 같아진다.
 
 Insert 18333fig0517.png
-그림 5-17 FeatureA에 대한 Rebase가 적용된 후의 모습
+그림 5-17. FeatureA에 대한 Rebase가 적용된 후의 모습
 
 브랜치를 Rebase해 버렸기 때문에 Push할 때 -f 옵션을 주고 강제로 기존에 서버에 있던 브랜치의 내용을 덮어 써야 한다. 아니면 새로운 브랜치를(예를 들어 featureAv2) 서버에 Push해도 된다.
 
@@ -462,7 +462,7 @@ Insert 18333fig0517.png
 수정을 마치면 관리자에게 featureBv2 브랜치를 확인해 보라고 메시지를 보낸다 (그림 5-18 참고).
 
 Insert 18333fig0518.png
-그림 5-18 featureBv2 브랜치를 커밋한 이후 저장소 모습
+그림 5-18. featureBv2 브랜치를 커밋한 이후 저장소 모습
 
 ### 대규모 공개 프로젝트 ###
 
@@ -755,23 +755,23 @@ master 브랜치가 가리키는 커밋이 토픽 브랜치의 조상이라면 
 바로 master 브랜치에 Merge하는 것이 가장 간단하다. 이 Workflow에서는 master 브랜치가 안전한 코드라고 가정한다. 토픽 브랜치를 검증하고 master 브랜치로 Merge할 때마다 토픽 브랜치를 삭제한다. 그림 5-19처럼 `ruby_client` 브랜치와 `php_client` 브랜치가 있을 때 `ruby_client` 브랜치를 master 브랜치로 Merge한 후 `php_client` 브랜치를 Merge하면 그림 5-20과 같아진다:
 
 Insert 18333fig0519.png
-그림 5-19 저장소의 두 브랜치
+그림 5-19. 저장소의 두 브랜치
 
 Insert 18333fig0520.png
-그림 5-20 Merge한 후의 저장소
+그림 5-20. Merge한 후의 저장소
 
 이 Workflow은 간단하지만, 프로젝트의 규모가 커지면 문제가 생길 수 있다.
 
 개발자가 많고 규모가 큰 프로젝트에서는 두 단계로 Merge하는 것이 좋다. 그래서 Long-Running 브랜치를 두 개로 유지해야 한다. master 브랜치는 아주 안정적인 버전을 릴리즈하기 위해서 사용한다. develop 브랜치는 새로 수정된 코드를 통합할 때 사용한다. 그리고 두 브랜치를 모두 저장소에 Push한다. 우선 develop 브랜치에 토픽 브랜치(그림 5-21)를 그림 5-22과 같이 Merge한다. 그 후에 릴리즈해도 될만한 수준이 되면 master 브랜치를 develop 브랜치까지 Fast-forward시킨다(그림 5-23).
 
 Insert 18333fig0521.png
-그림 5-21 토픽 브랜치를 Merge하기 전
+그림 5-21. 토픽 브랜치를 Merge하기 전
 
 Insert 18333fig0522.png
-그림 5-22 토픽 브랜치를 Merge한 후
+그림 5-22. 토픽 브랜치를 Merge한 후
 
 Insert 18333fig0523.png
-그림 5-23 토픽 브랜치를 릴리즈한 후
+그림 5-23. 토픽 브랜치를 릴리즈한 후
 
 이 Workflow을 사용하면 프로젝트 저장소를 Clone하고 나서 개발자가 안정 버전이 필요하면 master 브랜치를 빌드하고 안정적이지 않더라도 좀 더 최신 버전이 필요하면 develop 브랜치를 Checkout하여 빌드한다. 이 개념을 좀 더 확장해서 사용할 수 있다. 토픽 브랜치를 검증하기 위한 integrate 브랜치를 만들어 Merge하고 토픽 브랜치가 검증되면 develop 브랜치에 머지한다. 그리고 develop 브랜치에서 충분히 안정하다는 것이 증명되면 그때 master 브랜치에 Merge한다.
 
@@ -780,12 +780,12 @@ Insert 18333fig0523.png
 Git을 개발하는 프로젝트는 Long-Running의 브랜치를 4개 운영한다. 각 브랜치 이름은 master, next, pu (Proposed Updates), maint 이다. maint는 마지막으로 릴리즈한 버전을 지원하는 브랜치다. 기여자가 새로운 기능을 제안하면 관리자는 그림 5-24처럼 자신의 저장소에 토픽 브랜치를 만들어 관리한다. 그리고 토픽에 부족한 점은 없는지, 안정적인지 계속 테스트한다. 안정화되면 next로 Merge하고 저장소에 Push한다. 그러면 모두가 잘 통합됐는지 확인할 수 있다.
 
 Insert 18333fig0524.png
-그림 5-24 토픽 브랜치를 동시에 여러 개 관리하는 것은 복잡하다
+그림 5-24. 토픽 브랜치를 동시에 여러 개 관리하는 것은 복잡하다
 
 토픽 브랜치가 좀 더 개선돼야 하면 next가 아니라 pu에 Merge한다. 그 후에 충분히 검증을 마치면 pu에서 next로 옮기고 next를 기반으로 pu를 다시 만든다. next에는 아직 master에 넣기에 모자라 보이는 것들이 들어 있다. 즉 next 브랜치는 정말 가끔 Rebase하고 pu는 자주 Rebase하지만 master는 항상 Fast-forward한다(그림 5-25).
 
 Insert 18333fig0525.png
-그림 5-25 토픽 브랜치를 Long-Running 브랜치로 Merge하기
+그림 5-25. 토픽 브랜치를 Long-Running 브랜치로 Merge하기
 
 토픽 브랜치가 결국 master 브랜치로 Merge되면 저장소에서 삭제한다. 그리고 이전 릴리즈 버전에 Patch가 필요하면 maint 브랜치를 이용해 대응한다. Git을 개발하는 프로젝트를 Clone하면 브랜치가 4개 있고 각 브랜치를 이용하여 진행사항을 확인해볼 수 있다. 그래서 새로운 기능을 추가하려면 적당한 브랜치를 보고 고른다. 이 Workflow는 잘 구조화돼 있어서 코드가 새로 추가돼도 테스트하기 쉽다.
 
@@ -796,7 +796,7 @@ Insert 18333fig0525.png
 한 브랜치에서 다른 브랜치로 작업한 내용을 옮기는 또 다른 방식으로 Cherry-pick이란 것도 있다. Git의 Cherry-pick은 커밋 하나만 Rebase하는 것이다. 커밋 하나로 Patch 내용을 만들어 현재 브랜치에 적용을 하는 것이다. 토픽 브랜치에 있는 커밋중에서 하나만 고르거나 토픽 브랜치에 커밋이 하나밖에 없을 때 Rebase보다 유용하다. 그림 5-26의 예를 들어보자.
 
 Insert 18333fig0526.png
-그림 5-26 Cherry-pick을 실행하기 전의 저장소
+그림 5-26. Cherry-pick을 실행하기 전의 저장소
 
 e43a6 커밋 하나만 현재 브랜치에 적용하려면 아래와 같은 명령을 실행한다:
 
@@ -808,7 +808,7 @@ e43a6 커밋 하나만 현재 브랜치에 적용하려면 아래와 같은 명
 위 명령을 실행하면 e43a6 커밋에서 변경된 내용을 현재 브랜치에 똑같이 적용을 한다. 하지만, 변경을 적용한 시점이 다르므로 새 커밋의 SHA-1 해시 값은 달라진다. 명령을 실행하고 나면 그림 5-27과 같이 될 것이다.
 
 Insert 18333fig0527.png
-그림 5-27 Cherry-pick 방식으로 커밋 하나를 적용한 후의 저장소
+그림 5-27. Cherry-pick 방식으로 커밋 하나를 적용한 후의 저장소
 
 Rebase나 Cherry-pick 방식으로 토픽 브랜치를 합치고 나면 필요없는 토픽 브랜치나 커밋은 삭제한다.
 
diff --git a/ko/06-git-tools/01-chapter6.markdown b/ko/06-git-tools/01-chapter6.markdown
index d10b446d7..1af11f6b2 100644
--- a/ko/06-git-tools/01-chapter6.markdown
+++ b/ko/06-git-tools/01-chapter6.markdown
@@ -190,7 +190,7 @@ reflog의 일은 모두 로컬의 일이기 때문에 내 reflog가 동료의 
 범위를 표현하는 문법으로 Double Dot(..)을 많이 쓴다. Double Dot은 한쪽에는 있고 다른 쪽에는 없는 커밋이 무엇인지 Git에게 물어보는 것이다. 예들 들어 그림 6-1과 같은 커밋 히스토리가 있다고 가정하자.
 
 Insert 18333fig0601.png
-그림 6-1 범위를 설명하는 데 사용할 예제
+그림 6-1. 범위를 설명하는 데 사용할 예제
 
 experiment 브랜치의 커밋들 중에서 아직 master 브랜치에 Merge하지 않은 것만 보고 싶으면 `master..experiment`라고 사용한다. 이 표현은 "master에는 없지만, experiment에는 있는 커밋"을 의미한다. 여기에서는 설명을 쉽게 하고자 실제 조회 결과가 아니라 그림 6-1의 문자를 사용한다:
 
diff --git a/ko/07-customizing-git/01-chapter7.markdown b/ko/07-customizing-git/01-chapter7.markdown
index e93c49a46..8e363021f 100644
--- a/ko/07-customizing-git/01-chapter7.markdown
+++ b/ko/07-customizing-git/01-chapter7.markdown
@@ -190,7 +190,7 @@ Git config 파일에 이 스크립트를 모두 추가한다. 설정해야 하
 diff 결과가 터미널에 출력되는 대신 P4Merge가 실행된다. 그리고 그림 7-1처럼 그 프로그램 안에서 보여준다:
 
 Insert 18333fig0701.png
-그림 7-1 P4Merge
+그림 7-1. P4Merge
 
 브랜치를 Merge할 때 충돌이 나면 `git mergetool` 명령을 실행한다. 이 명령을 실행하면 GUI 도구로 충돌을 해결할 수 있도록 P4Merge를 실행해준다.
 
@@ -454,10 +454,10 @@ Git은 이 파일을 Checkout할 때마다 SHA 값을 삽입해준다:
 Commit/Checkout할 때 사용하는 필터를 직접 만들어 쓸 수 있다. 방향에 따라 "clean" 필터와 "smudge" 필터라고 부른다. ".gitattributes" 파일에 설정하고 파일 경로마다 다른 필터를 설정할 수 있다. Checkout할 때 파일을 처리하는 것이 "smudge" 필터이고(그림 7-2) 커밋할 때 처리하는 필터가 "clean" 필터이다. 이 필터로 할 수 있는 일은 무궁무진하다.
 
 Insert 18333fig0702.png
-그림 7-2 "smudge" 필터는 Checkout할 때 실행된다
+그림 7-2. "smudge" 필터는 Checkout할 때 실행된다
 
 Insert 18333fig0703.png
-그림 7-3 "clean" 필터는 파일을 Stage할 때 실행된다
+그림 7-3. "clean" 필터는 파일을 Stage할 때 실행된다
 
 커밋하기 전에 `indent` 프로그램으로 C 코드 전부를 필터링하지만 커밋 메시지는 단순한 예제를 보자. `*.c` 파일은 indent 필터를 사용하도록 `.gitattributes` 파일에 설정한다:
 
diff --git a/ko/09-git-internals/01-chapter9.markdown b/ko/09-git-internals/01-chapter9.markdown
index 8386c83ea..fcf02085b 100644
--- a/ko/09-git-internals/01-chapter9.markdown
+++ b/ko/09-git-internals/01-chapter9.markdown
@@ -116,7 +116,7 @@ Git은 Content-addressable 파일시스템이다. 이게 무슨 말이냐 하면
 Git이 저장하는 데이터는 대강 그림 9-1과 같다.
 
 Insert 18333fig0901.png
-그림 9-1 단순화한 Git 데이터 모델
+그림 9-1. 단순화한 Git 데이터 모델
 
 직접 Tree 개체를 만들어 보자. Git은 일반적으로 Staging Area(Index)의 상태대로 Tree 개체를 만들고 기록한다. 그래서 Tree 개체를 만들려면 우선 Staging Area에 파일을 추가해서 Index를 만들어야 한다. 우선 Plumbing 명령어 `update-index`로 `test.txt` 파일만 들어 있는 Index를 만든다. 이 명령어는 파일을 인위적으로 Staging Area에 추가하는 명령다. 아직 Staging Area에 없는 파일이기 때문에 `--add` 옵션을 꼭 줘야 한다(사실 아직 Staging Area도 설정하지 않았다). 그리고 디렉토리에 있는 파일이 아니라 데이터베이스에 있는 파일을 추가하는 것이기 때문에 `--cacheinfo` 옵션이 필요하다. 파일 모드, SHA-1 해시, 파일 이름 정보도 입력한다:
 
@@ -164,7 +164,7 @@ Staging Area를 Tree 개체로 저장할 때는 `write-tree` 명령을 사용한
 이 Tree 개체로 워킹 디렉토리를 만들면 파일 두 개와 `bak`이라는 하위 디렉토리가 생긴다. 그리고 `bak` 디렉토리 안에는 test.txt 파일의 처음 버전이 들어 있다. 그림 9-2와 같은 구조로 데이터가 저장된다.
 
 Insert 18333fig0902.png
-그림 9-2 현재 Git 데이터 구조
+그림 9-2. 현재 Git 데이터 구조
 
 ### 커밋 개체 ###
 
@@ -241,7 +241,7 @@ Insert 18333fig0902.png
 내부의 포인터를 따라가면 그림 9-3과 같은 그래프가 그려진다.
 
 Insert 18333fig0903.png
-그림 9-3 Git 저장소 내의 모든 개체
+그림 9-3. Git 저장소 내의 모든 개체
 
 ### 개체 저장소 ###
 
@@ -326,7 +326,7 @@ Git 브랜치의 역할이 바로 이거다. 브랜치는 어떤 작업들 중 
 이제 Git 데이터베이스는 그림 9-4처럼 보인다.
 
 Insert 18333fig0904.png
-그림 9-4 브랜치 레퍼런스가 추가된 Git 데이터베이스
+그림 9-4. 브랜치 레퍼런스가 추가된 Git 데이터베이스
 
 `git branch (branchname)` 명령을 실행하면 Git은 내부적으로 `update-ref` 명령을 실행한다. 입력받은 브랜치 이름과 현 브랜치의 마지막 커밋의 SHA-1 값을 가져다 `update-ref` 명령을 실행한다.
 

From b1229d67970243816611e147f276e8afd0f80ad3 Mon Sep 17 00:00:00 2001
From: Ralph Haussmann <ralph@scanmyfood.de>
Date: Sun, 12 Jan 2014 15:02:29 +0100
Subject: [PATCH 079/690] [de] Fix some incorrect comment syntax in german
 translation

- This makes it easier to use tools for automatic merge of original english
   text to german translation
---
 de/01-introduction/01-chapter1.markdown       | 26 +++---
 de/02-git-basics/01-chapter2.markdown         | 90 +++++++++----------
 de/03-git-branching/01-chapter3.markdown      | 28 +++---
 de/04-git-server/01-chapter4.markdown         | 12 +--
 de/05-distributed-git/01-chapter5.markdown    | 44 ++++-----
 de/06-git-tools/01-chapter6.markdown          | 12 +--
 de/08-git-and-other-scms/01-chapter8.markdown |  4 +-
 de/09-git-internals/01-chapter9.markdown      | 12 +--
 8 files changed, 113 insertions(+), 115 deletions(-)

diff --git a/de/01-introduction/01-chapter1.markdown b/de/01-introduction/01-chapter1.markdown
index a86cec03a..9e6febd00 100644
--- a/de/01-introduction/01-chapter1.markdown
+++ b/de/01-introduction/01-chapter1.markdown
@@ -83,11 +83,11 @@ Wie viele großartige Dinge im Leben entstand Git aus kreativem Chaos und hitzig
 
 2005 ging die Beziehung zwischen der Community, die den Linux Kernel entwickelte, und des kommerziell ausgerichteten Unternehmens, das BitKeeper entwickelte, kaputt. Die zuvor ausgesprochene Erlaubnis, BitKeeper kostenlos zu verwenden, wurde widerrufen. Dies war für die Linux Entwickler Community (und besonders für Linus Torvald, der Erfinder von Linux) der Auslöser dafür, ein eigenes Tool zu entwickeln, das auf den Erfahrungen mit BitKeeper basierte. Ziele des neuen Systems waren unter anderem:
 
-<!--*	Speed
-*	Simple design
-*	Strong support for non-linear development (thousands of parallel branches)
-*	Fully distributed
-*	Able to handle large projects like the Linux kernel efficiently (speed and data size)-->
+<!--*	Speed-->
+<!--*	Simple design-->
+<!--*	Strong support for non-linear development (thousands of parallel branches)-->
+<!--*	Fully distributed-->
+<!--*	Able to handle large projects like the Linux kernel efficiently (speed and data size)-->
 
 * Geschwindigkeit
 * Einfaches Design
@@ -206,9 +206,9 @@ Die Staging Area ist einfach eine Datei (normalerweise im Git Verzeichnis), in d
 
 Der grundlegend Git Arbeitsprozess sieht in etwa so aus:
 
-<!--1. You modify files in your working directory.
-2. You stage the files, adding snapshots of them to your staging area.
-3. You do a commit, which takes the files as they are in the staging area and stores that snapshot permanently to your Git directory.-->
+<!--1. You modify files in your working directory.-->
+<!--2. You stage the files, adding snapshots of them to your staging area.-->
+<!--3. You do a commit, which takes the files as they are in the staging area and stores that snapshot permanently to your Git directory.-->
 
 1. Du bearbeitest Dateien in Deinem Arbeitsverzeichnis.
 2. Du markierst Dateien für den nächsten Commit, indem Du Snapshots zur Staging Area hinzufügst.
@@ -330,9 +330,9 @@ Nachdem Du jetzt Git auf Deinem System installiert hast, solltest Du Deine Git K
 
 Git umfasst das Werkzeug `git config`, das Dir erlaubt, Konfigurationswerte zu verändern. Auf diese Weise kannst Du anpassen, wie Git aussieht und arbeitet. Diese Werte sind an drei verschiedenen Orten gespeichert:
 
-<!--*	`/etc/gitconfig` file: Contains values for every user on the system and all their repositories. If you pass the option` -\-system` to `git config`, it reads and writes from this file specifically.
-*	`~/.gitconfig` file: Specific to your user. You can make Git read and write to this file specifically by passing the `-\-global` option.
-*	config file in the git directory (that is, `.git/config`) of whatever repository you’re currently using: Specific to that single repository. Each level overrides values in the previous level, so values in `.git/config` trump those in `/etc/gitconfig`.-->
+<!--*	`/etc/gitconfig` file: Contains values for every user on the system and all their repositories. If you pass the option` -\-system` to `git config`, it reads and writes from this file specifically.-->
+<!--*	`~/.gitconfig` file: Specific to your user. You can make Git read and write to this file specifically by passing the `-\-global` option.-->
+<!--*	config file in the git directory (that is, `.git/config`) of whatever repository you’re currently using: Specific to that single repository. Each level overrides values in the previous level, so values in `.git/config` trump those in `/etc/gitconfig`.-->
 
 * Die Datei `/etc/gitconfig` enthält Werte, die für jeden Anwender des Systems und all ihre Projekte gelten. Wenn Du `git config` mit der Option `--system` verwendest, wird diese Datei verwendet.
 * Die Werte in der Datei `~/.gitconfig` gelten ausschließlich für Dich und all Deine Projekte. Wenn Du `git config` mit der Option `--global` verwendest, wird diese Datei verwendet.
@@ -422,8 +422,8 @@ Beispielsweise erhältst Du die Hilfeseite für den `git config` Befehl so:
 
 	$ git help config
 
-<!--These commands are nice because you can access them anywhere, even offline.
-If the manpages and this book aren’t enough and you need in-person help, you can try the `#git` or `#github` channel on the Freenode IRC server (irc.freenode.net). These channels are regularly filled with hundreds of people who are all very knowledgeable about Git and are often willing to help.-->
+<!--These commands are nice because you can access them anywhere, even offline.-->
+<!--If the manpages and this book aren’t enough and you need in-person help, you can try the `#git` or `#github` channel on the Freenode IRC server (irc.freenode.net). These channels are regularly filled with hundreds of people who are all very knowledgeable about Git and are often willing to help.-->
 
 Die „manpage“ Dokumentation ist nützlich, weil Du sie Dir jederzeit anzeigen lassen kannst, auch wenn Du offline bist. Wenn Dir die manpages und dieses Buch nicht ausreichen, kannst Du Deine Fragen auch in den Chaträumen `#git` oder `#github` auf dem Freenode IRC Server (irc.freenode.net) stellen. Diese Räume sind in der Regel sehr gut besucht. Normalerweise findet sich unter den hunderten von Anwendern, die oft sehr viel Erfahrung mit Git haben, irgendjemand, der Deine Fragen gern beantwortet.
 
diff --git a/de/02-git-basics/01-chapter2.markdown b/de/02-git-basics/01-chapter2.markdown
index 7f4598236..e9e64a7bd 100644
--- a/de/02-git-basics/01-chapter2.markdown
+++ b/de/02-git-basics/01-chapter2.markdown
@@ -227,10 +227,10 @@ Die erste Zeile weist Git an, alle Dateien zu ignorieren, die mit einem `.o` ode
 
 Folgende Regeln gelten in einer `.gitignore` Datei:
 
-<!--*	Blank lines or lines starting with `#` are ignored.
-*	Standard glob patterns work.
-*	You can end patterns with a forward slash (`/`) to specify a directory.
-*	You can negate a pattern by starting it with an exclamation point (`!`).-->
+<!--*	Blank lines or lines starting with `#` are ignored.-->
+<!--*	Standard glob patterns work.-->
+<!--*	You can end patterns with a forward slash (`/`) to specify a directory.-->
+<!--*	You can negate a pattern by starting it with an exclamation point (`!`).-->
 
 *	Leere Zeilen oder Zeilen, die mit `#` beginnen, werden ignoriert.
 *	Standard `glob` Muster funktionieren.
@@ -386,8 +386,8 @@ und `git diff --cached`, um zu sehen, was für den nächsten Commit vorgesehen i
 <!--### Committing Your Changes ###-->
 ### Einen Commit erzeugen ###
 
-<!--Now that your staging area is set up the way you want it, you can commit your changes. Remember that anything that is still unstaged — any files you have created or modified that you haven’t run `git add` on since you edited them — won’t go into this commit. They will stay as modified files on your disk.
-In this case, the last time you ran `git status`, you saw that everything was staged, so you’re ready to commit your changes. The simplest way to commit is to type `git commit`:-->
+<!--Now that your staging area is set up the way you want it, you can commit your changes. Remember that anything that is still unstaged — any files you have created or modified that you haven’t run `git add` on since you edited them — won’t go into this commit. They will stay as modified files on your disk.-->
+<!--In this case, the last time you ran `git status`, you saw that everything was staged, so you’re ready to commit your changes. The simplest way to commit is to type `git commit`:-->
 
 Nachdem Du jetzt alle Änderungen, die Du im nächsten Commit haben willst, in Deiner Staging Area gesammelt hast, kannst Du den Commit anlegen. Denke daran, dass Änderungen, die nicht in der Staging Area sind (also alle Änderungen, die Du vorgenommen hast, seit Du zuletzt `git add` ausgeführt hast), auch nicht in den Commit aufgenommen werden. Sie werden ganz einfach weiterhin als geänderte Dateien im Arbeitsverzeichnis verbleiben. In unserem Beispiel haben wir gesehen, dass alle Änderungen vorgemerkt waren, als wir zuletzt `git status` ausgeführt haben, also können wir den Commit jetzt anlegen. Das geht am einfachsten mit dem Befehl:
 
@@ -644,8 +644,8 @@ Eine sehr nützliche Option ist `-p`. Sie zeigt die Änderungen an, die in einem
 	-end
 	\ No newline at end of file
 
-<!--This option displays the same information but with a diff directly following each entry. This is very helpful for code review or to quickly browse what happened during a series of commits that a collaborator has added.
-You can also use a series of summarizing options with `git log`. For example, if you want to see some abbreviated stats for each commit, you can use the `-\-stat` option:-->
+<!--This option displays the same information but with a diff directly following each entry. This is very helpful for code review or to quickly browse what happened during a series of commits that a collaborator has added.-->
+<!--You can also use a series of summarizing options with `git log`. For example, if you want to see some abbreviated stats for each commit, you can use the `-\-stat` option:-->
 
 Diese Option zeigt also im Prinzip die gleiche Information wie zuvor, aber zusätzlich zu jedem Eintrag ein Diff. Das ist nützlich, um einen Code Review zu machen oder eben mal eine Reihe von Commits durchzuschauen, die ein Mitarbeiter angelegt hat. Außerdem gibt es verschiedene Optionen, die nützlich sind, um Dinge zusammenzufassen. Beispielsweise kannst Du eine kurze Statistik über jeden Commit mit der Option `--stat` anzeigen lassen:
 
@@ -679,8 +679,8 @@ Diese Option zeigt also im Prinzip die gleiche Information wie zuvor, aber zusä
 	 lib/simplegit.rb |   25 +++++++++++++++++++++++++
 	 3 files changed, 54 insertions(+), 0 deletions(-)
 
-<!--As you can see, the `-\-stat` option prints below each commit entry a list of modified files, how many files were changed, and how many lines in those files were added and removed. It also puts a summary of the information at the end.
-Another really useful option is `-\-pretty`. This option changes the log output to formats other than the default. A few prebuilt options are available for you to use. The `oneline` option prints each commit on a single line, which is useful if you’re looking at a lot of commits. In addition, the `short`, `full`, and `fuller` options show the output in roughly the same format but with less or more information, respectively:-->
+<!--As you can see, the `-\-stat` option prints below each commit entry a list of modified files, how many files were changed, and how many lines in those files were added and removed. It also puts a summary of the information at the end.-->
+<!--Another really useful option is `-\-pretty`. This option changes the log output to formats other than the default. A few prebuilt options are available for you to use. The `oneline` option prints each commit on a single line, which is useful if you’re looking at a lot of commits. In addition, the `short`, `full`, and `fuller` options show the output in roughly the same format but with less or more information, respectively:-->
 
 Die `--stat` Option zeigt unterhalb jedes Commits eine kurze Statistik über die jeweiligen Änderungen an: welche Dateien geändert wurden und wieviele Zeilen insgesamt hinzugefügt oder entfernt wurden. Eine weitere nützliche Option ist `--pretty`. Diese Option ändert das Format der Ausgabe und es gibt eine Anzahl mitgelieferter Formate. Das `oneline` Format listet jeden Commit in einer einzigen Zeile, was nützlich ist, wenn Du eine große Anzahl von Commits durchsuchen willst. Die `short`, `full` und `fuller` Formate zeigen die Commits in ähnlicher Form an, aber mit jeweils mehr oder weniger Informationen.
 
@@ -702,22 +702,22 @@ Eines der interessantesten Formate ist `format`, das Dir erlaubt, Dein eigenes F
 
 Tabelle 2-1 zeigt einige nützliche Optionen, die von `format` akzeptiert werden:
 
-<!--	Option	Description of Output
-	%H	Commit hash
-	%h	Abbreviated commit hash
-	%T	Tree hash
-	%t	Abbreviated tree hash
-	%P	Parent hashes
-	%p	Abbreviated parent hashes
-	%an	Author name
-	%ae	Author e-mail
-	%ad	Author date (format respects the -\-date= option)
-	%ar	Author date, relative
-	%cn	Committer name
-	%ce	Committer email
-	%cd	Committer date
-	%cr	Committer date, relative
-	%s	Subject-->
+<!--	Option	Description of Output-->
+<!--	%H	Commit hash-->
+<!--	%h	Abbreviated commit hash-->
+<!--	%T	Tree hash-->
+<!--	%t	Abbreviated tree hash-->
+<!--	%P	Parent hashes-->
+<!--	%p	Abbreviated parent hashes-->
+<!--	%an	Author name-->
+<!--	%ae	Author e-mail-->
+<!--	%ad	Author date (format respects the -\-date= option)-->
+<!--	%ar	Author date, relative-->
+<!--	%cn	Committer name-->
+<!--	%ce	Committer email-->
+<!--	%cd	Committer date-->
+<!--	%cr	Committer date, relative-->
+<!--	%s	Subject-->
 
 	Option	Beschreibung
 	%H	Commit Hash
@@ -760,17 +760,17 @@ Die `oneline` und `format` Optionen können außerdem zusammen mit einer weitere
 
 Das sind nur einige eher simple Format Optionen für die Ausgabe von `git log` – es gibt sehr viel mehr davon. Tabelle 2-2 listet diejenigen Optionen auf, die wir bisher besprochen haben, und einige weitere, die besonders nützlich sind:
 
-<!--	Option	Description
-	-p	Show the patch introduced with each commit.
-	-\-stat	Show statistics for files modified in each commit.
-	-\-shortstat	Display only the changed/insertions/deletions line from the -\-stat command.
-	-\-name-only	Show the list of files modified after the commit information.
-	-\-name-status	Show the list of files affected with added/modified/deleted information as well.
-	-\-abbrev-commit	Show only the first few characters of the SHA-1 checksum instead of all 40.
-	-\-relative-date	Display the date in a relative format (for example, “2 weeks ago”) instead of using the full date format.
-	-\-graph	Display an ASCII graph of the branch and merge history beside the log output.
-	-\-pretty	Show commits in an alternate format. Options include oneline, short, full, fuller, and format (where you specify your own format).
-	-\-oneline	A convenience option short for `-\-pretty=oneline -\-abbrev-commit`.-->
+<!--	Option	Description-->
+<!--	-p	Show the patch introduced with each commit.-->
+<!--	-\-stat	Show statistics for files modified in each commit.-->
+<!--	-\-shortstat	Display only the changed/insertions/deletions line from the -\-stat command.-->
+<!--	-\-name-only	Show the list of files modified after the commit information.-->
+<!--	-\-name-status	Show the list of files affected with added/modified/deleted information as well.-->
+<!--	-\-abbrev-commit	Show only the first few characters of the SHA-1 checksum instead of all 40.-->
+<!--	-\-relative-date	Display the date in a relative format (for example, “2 weeks ago”) instead of using the full date format.-->
+<!--	-\-graph	Display an ASCII graph of the branch and merge history beside the log output.-->
+<!--	-\-pretty	Show commits in an alternate format. Options include oneline, short, full, fuller, and format (where you specify your own format).-->
+<!--	-\-oneline	A convenience option short for `-\-pretty=oneline -\-abbrev-commit`.-->
 
 	Option	Beschreibung
 	-p	Zeigt den Patch, der einem Commit entspricht.
@@ -812,12 +812,12 @@ Eine letzte sehr nützliche Option, die von `git log` akzeptiert wird, ist ein P
 
 Tabelle 2-3 zeigt die besprochenen und einige weitere, übliche Optionen:
 
-<!--	Option	Description
-	-(n)	Show only the last n commits
-	-\-since, -\-after	Limit the commits to those made after the specified date.
-	-\-until, -\-before	Limit the commits to those made before the specified date.
-	-\-author	Only show commits in which the author entry matches the specified string.
-	-\-committer	Only show commits in which the committer entry matches the specified string.-->
+<!--	Option	Description-->
+<!--	-(n)	Show only the last n commits-->
+<!--	-\-since, -\-after	Limit the commits to those made after the specified date.-->
+<!--	-\-until, -\-before	Limit the commits to those made before the specified date.-->
+<!--	-\-author	Only show commits in which the author entry matches the specified string.-->
+<!--	-\-committer	Only show commits in which the committer entry matches the specified string.-->
 
 	Option	Beschreibung
 	-(n)	Begrenzt die Ausgabe auf die letzten n commits
@@ -981,8 +981,8 @@ Beachte, dass alles was jemals in einem Commit in Git enthalten war, fast immer
 <!--## Working with Remotes ##-->
 ## Mit externen Repositorys arbeiten ##
 
-<!--To be able to collaborate on any Git project, you need to know how to manage your remote repositories. Remote repositories are versions of your project that are hosted on the Internet or network somewhere. You can have several of them, each of which generally is either read-only or read/write for you. Collaborating with others involves managing these remote repositories and pushing and pulling data to and from them when you need to share work.
-Managing remote repositories includes knowing how to add remote repositories, remove remotes that are no longer valid, manage various remote branches and define them as being tracked or not, and more. In this section, we’ll cover these remote-management skills.-->
+<!--To be able to collaborate on any Git project, you need to know how to manage your remote repositories. Remote repositories are versions of your project that are hosted on the Internet or network somewhere. You can have several of them, each of which generally is either read-only or read/write for you. Collaborating with others involves managing these remote repositories and pushing and pulling data to and from them when you need to share work.-->
+<!--Managing remote repositories includes knowing how to add remote repositories, remove remotes that are no longer valid, manage various remote branches and define them as being tracked or not, and more. In this section, we’ll cover these remote-management skills.-->
 
 Um mit anderen via Git zusammenzuarbeiten, musst Du wissen, wie Du auf externe (engl. „remote“) Repositorys zugreifen kannst. Remote Repositorys sind Versionen Deines Projektes, die im Internet oder irgendwo in einem anderen Netzwerk gespeichert sind. Du kannst mehrere solcher Repositorys haben und Du kannst jedes davon entweder nur lesen oder lesen und schreiben. Mit anderen via Git zusammenzuarbeiten impliziert, solche Repositorys zu verwalten und Daten aus ihnen herunter- oder heraufzuladen, um Deine Arbeit für andere verfügbar zu machen. Um Remote Repositorys zu verwalten, muss man wissen, wie man sie anlegt und wieder entfernt, wenn sie nicht mehr verwendet werden, wie man externe Branches verwalten und nachverfolgen kann, und mehr. In diesem Kapitel werden wir auf diese Aufgaben eingehen.
 
diff --git a/de/03-git-branching/01-chapter3.markdown b/de/03-git-branching/01-chapter3.markdown
index c45229239..22945fc2b 100644
--- a/de/03-git-branching/01-chapter3.markdown
+++ b/de/03-git-branching/01-chapter3.markdown
@@ -27,8 +27,7 @@ Um das zu verdeutlichen, lass uns annehmen, Du hast ein Verzeichnis mit drei Dat
 	$ git add README test.rb LICENSE2
 	$ git commit -m 'initial commit of my project'
 
-<!--
-When you create the commit by running `git commit`, Git checksums each subdirectory (in this case, just the root project directory) and stores those tree objects in the Git repository. Git then creates a commit object that has the metadata and a pointer to the root project tree so it can re-create that snapshot when needed.-->
+<!--When you create the commit by running `git commit`, Git checksums each subdirectory (in this case, just the root project directory) and stores those tree objects in the Git repository. Git then creates a commit object that has the metadata and a pointer to the root project tree so it can re-create that snapshot when needed.-->
 
 Wenn Du einen Commit mit dem Kommando `git commit` erstellst, erzeugt Git für jedes Unterverzeichnis eine Prüfsumme (in diesem Fall nur für das Root-Verzeichnis) und speichert diese drei Objekte im Git Repository. Git erzeugt dann ein Commit Objekt, das die Metadaten und den Zeiger zur Wurzel des Projektbaums enthält, um bei Bedarf den Snapshot erneut erzeugen zu können.
 
@@ -140,8 +139,7 @@ Lass uns ein paar Änderungen machen und mit einem Commit festhalten:
 	$ vim test.rb
 	$ git commit -a -m 'made other changes'
 
-<!--
-Now your project history has diverged (see Figure 3-9). You created and switched to a branch, did some work on it, and then switched back to your main branch and did other work. Both of those changes are isolated in separate branches: you can switch back and forth between the branches and merge them together when you’re ready. And you did all that with simple `branch` and `checkout` commands.-->
+<!--Now your project history has diverged (see Figure 3-9). You created and switched to a branch, did some work on it, and then switched back to your main branch and did other work. Both of those changes are isolated in separate branches: you can switch back and forth between the branches and merge them together when you’re ready. And you did all that with simple `branch` and `checkout` commands.-->
 
 Nun verzweigen sich die Projektverläufe (siehe Abbildung 3-9). Du hast einen Branch erstellt und zu ihm gewechselt, hast ein bisschen gearbeitet, bist zu Deinem Haupt-Zweig zurückgekehrt und hast da was ganz anderes gemacht. Beide Arbeiten existieren vollständig unabhängig voneinander in zwei unterschiedlichen Branches. Du kannst beliebig zwischen den beiden Zweigen wechseln und sie zusammenführen, wenn Du meinst es wäre soweit. Und das alles hast Du mit simplen `branch` und `checkout`-Befehlen vollbracht.
 
@@ -169,9 +167,9 @@ Lass uns mal sehen, warum Du das machen solltest.
 
 Lass uns das Ganze an einem Beispiel durchgehen, dessen Workflow zum Thema Branching und Zusammenführen Du im echten Leben verwenden kannst. Folge einfach diesen Schritten:
 
-<!--1. Do work on a web site.
-2. Create a branch for a new story you’re working on.
-3. Do some work in that branch.-->
+<!--1. Do work on a web site.-->
+<!--2. Create a branch for a new story you’re working on.-->
+<!--3. Do some work in that branch.-->
 
 1. Arbeite an einer Webseite.
 2. Erstell einen Branch für irgendeine neue Geschichte, an der Du arbeitest.
@@ -181,10 +179,10 @@ Lass uns das Ganze an einem Beispiel durchgehen, dessen Workflow zum Thema Branc
 
 In diesem Augenblick kommt ein Anruf, dass ein kritisches Problem aufgetreten ist und sofort gelöst werden muss. Du machst folgendes:
 
-<!--1. Revert back to your production branch.
-2. Create a branch to add the hotfix.
-3. After it’s tested, merge the hotfix branch, and push to production.
-4. Switch back to your original story and continue working.-->
+<!--1. Revert back to your production branch.-->
+<!--2. Create a branch to add the hotfix.-->
+<!--3. After it’s tested, merge the hotfix branch, and push to production.-->
+<!--4. Switch back to your original story and continue working.-->
 
 1. Geh zurück zu Deinem „Produktiv“-Zweig.
 2. Erstelle eine Branch für den Hotfix.
@@ -408,8 +406,8 @@ Das heisst, die Version in HEAD (Deines 'master'-Branches, denn der wurde per 'c
 	please contact us at email.support@github.com
 	</div>
 
-<!--This resolution has a little of each section, and I’ve fully removed the `<<<<<<<`, `=======`, and `>>>>>>>` lines. After you’ve resolved each of these sections in each conflicted file, run `git add` on each file to mark it as resolved. Staging the file marks it as resolved in Git.
-If you want to use a graphical tool to resolve these issues, you can run `git mergetool`, which fires up an appropriate visual merge tool and walks you through the conflicts:-->
+<!--This resolution has a little of each section, and I’ve fully removed the `<<<<<<<`, `=======`, and `>>>>>>>` lines. After you’ve resolved each of these sections in each conflicted file, run `git add` on each file to mark it as resolved. Staging the file marks it as resolved in Git.-->
+<!--If you want to use a graphical tool to resolve these issues, you can run `git mergetool`, which fires up an appropriate visual merge tool and walks you through the conflicts:-->
 
 Diese Lösung hat von beiden Teilen etwas und ich habe die Zeilen mit `<<<<<<<`, `=======`, und `>>>>>>>` komplett gelöscht. Nachdem Du alle problematischen Bereiche, in allen durch den Konflikt betroffenen Dateien, beseitigt hast, führe einfach `git add` für alle betroffenen Dateien aus und markieren sie damit als bereinigt. Dieses 'staging' der Dateien markiert sie für Git als bereinigt.
 Wenn Du ein grafischen Tool zur Bereinigung benutzen willst, dann verwende `git mergetool`. Das welches ein passendes grafisches 'merge'-Tool startet und Dich durch die Konfliktbereiche führt:
@@ -554,8 +552,8 @@ Es ist leichter sich die verschiedenen Branches als Arbeitsdepots vorzustellen,
 Insert 18333fig0319.png
 Abbildung 3-19. Es könnte hilfreich sein, sich die Branches als Depots vorzustellen.
 
-<!--You can keep doing this for several levels of stability. Some larger projects also have a `proposed` or `pu` (proposed updates) branch that has integrated branches that may not be ready to go into the `next` or `master` branch. The idea is that your branches are at various levels of stability; when they reach a more stable level, they’re merged into the branch above them.
-Again, having multiple long-running branches isn’t necessary, but it’s often helpful, especially when you’re dealing with very large or complex projects.-->
+<!--You can keep doing this for several levels of stability. Some larger projects also have a `proposed` or `pu` (proposed updates) branch that has integrated branches that may not be ready to go into the `next` or `master` branch. The idea is that your branches are at various levels of stability; when they reach a more stable level, they’re merged into the branch above them.-->
+<!--Again, having multiple long-running branches isn’t necessary, but it’s often helpful, especially when you’re dealing with very large or complex projects.-->
 
 Das lässt sich für beliebig viele Stabilitätsabstufungen umsetzen. Manche größeren Projekte haben auch einen `proposed` (Vorgeschlagen) oder `pu` (proposed updates – vorgeschlagene Updates) Zweig mit Branches die vielleicht noch nicht bereit sind in den `next`- oder `master`-Branch integriert zu werden. Die Idee dahinter ist, dass Deine Branches verschiedene Stabilitätsabstufungen repräsentieren. Sobald sie eine stabilere Stufe erreichen, werden sie in den nächsthöheren Branch vereinigt.
 
diff --git a/de/04-git-server/01-chapter4.markdown b/de/04-git-server/01-chapter4.markdown
index cb95e87bb..80b14cd2a 100644
--- a/de/04-git-server/01-chapter4.markdown
+++ b/de/04-git-server/01-chapter4.markdown
@@ -194,8 +194,8 @@ Die Unterseite vom Servieren von Deinem Repository über HTTP ist, dass es recht
 <!--## Getting Git on a Server ##-->
 ## Git auf einen Server bekommen ##
 
-<!--In order to initially set up any Git server, you have to export an existing repository into a new bare repository — a repository that doesn’t contain a working directory. This is generally straightforward to do.
-In order to clone your repository to create a new bare repository, you run the clone command with the `-\-bare` option. By convention, bare repository directories end in `.git`, like so:-->
+<!--In order to initially set up any Git server, you have to export an existing repository into a new bare repository — a repository that doesn’t contain a working directory. This is generally straightforward to do.-->
+<!--In order to clone your repository to create a new bare repository, you run the clone command with the `-\-bare` option. By convention, bare repository directories end in `.git`, like so:-->
 
 Um zunächst einen beliebigen Git Server einzurichten, musst Du ein existierendes Repository in ein neues einfaches Repository exportieren – ein Repository, dass kein Arbeitsverzeichnis enthält. Das ist im Allgemeinen einfach zu erledigen.
 Um zunächst Dein Repository zu klonen, um ein neues einfaches Repository anzulegen, führst Du den Klonen-Befehl mit der `--bare` Option aus. Per Konvention haben einfache Repository Verzeichnisse die Endung `.git`, wie hier:
@@ -285,8 +285,8 @@ Ein anderer Weg ist, einen LDAP-Server zur Authentifizierung zu benutzen oder ei
 <!--## Generating Your SSH Public Key ##-->
 ## Generiere Deinen öffentlichen SSH-Schlüssel ##
 
-<!--That being said, many Git servers authenticate using SSH public keys. In order to provide a public key, each user in your system must generate one if they don’t already have one. This process is similar across all operating systems.
-First, you should check to make sure you don’t already have a key. By default, a user’s SSH keys are stored in that user’s `~/.ssh` directory. You can easily check to see if you have a key already by going to that directory and listing the contents:-->
+<!--That being said, many Git servers authenticate using SSH public keys. In order to provide a public key, each user in your system must generate one if they don’t already have one. This process is similar across all operating systems.-->
+<!--First, you should check to make sure you don’t already have a key. By default, a user’s SSH keys are stored in that user’s `~/.ssh` directory. You can easily check to see if you have a key already by going to that directory and listing the contents:-->
 
 Darüber hinaus benutzen viele Git-Server öffentliche SSH-Schlüssel zur Authentifizierung. Um einen öffentlichen Schlüssel bereitzustellen muss jeder Benutzer Deines Systems einen solchen Schlüssel generieren, falls sie noch keinen haben. Dieser Prozess ist bei allen Betriebssystemen ähnlich.
 Als erstes solltest Du überprüfen, ob Du nicht schon einen Schlüssel hast. Standardmäßig werden die SSH-Schlüssel der Benutzer in ihrem `~/.ssh`-Verzeichnis gespeichert. Du kannst einfach überprüfen, ob Du einen Schlüssel hast, indem Du in das Verzeichnis gehst und den Inhalt auflistest:
@@ -1130,8 +1130,8 @@ Auf dieser Seite musst Du einen Nutzernamen auswählen, der bisher im System nic
 Insert 18333fig0403.png
 Abbildung 4-3. Das Formular für die GitHub Benutzerregistrierung.
 
-<!--If you have it available, this is a good time to add your public SSH key as well. We covered how to generate a new key earlier, in the "Simple Setups" section. Take the contents of the public key of that pair, and paste it into the SSH Public Key text box. Clicking the "explain ssh keys" link takes you to detailed instructions on how to do so on all major operating systems.
-Clicking the "I agree, sign me up" button takes you to your new user dashboard (see Figure 4-4).-->
+<!--If you have it available, this is a good time to add your public SSH key as well. We covered how to generate a new key earlier, in the "Simple Setups" section. Take the contents of the public key of that pair, and paste it into the SSH Public Key text box. Clicking the "explain ssh keys" link takes you to detailed instructions on how to do so on all major operating systems.-->
+<!--Clicking the "I agree, sign me up" button takes you to your new user dashboard (see Figure 4-4).-->
 
 Wenn Du Deinen öffentlichen SSH Schlüssel zur Hand hast, kannst Du diesen auch gleich bei der Registrierung angeben. Die Vorgehensweise zum Generieren eines Schlüssels haben wir bereits im Kapitel 4.3 besprochen. Du musst den Inhalt der öffentlichen Schlüsseldatei kopieren und in das „SSH Public Key“ Formularfeld einfügen. Wenn Du auf den „explain ssh keys“ Link klickst, erhälst Du detailierte Anweisungen zum Ausführen dieses Vorgangs auf verschiedenen Betriebssystemen. Wenn Du auf den „I agree, sign me up“ Button drückst, landest Du in Deinem neuen Benutzer-Dashboard (siehe Abbildung 4-4).
 
diff --git a/de/05-distributed-git/01-chapter5.markdown b/de/05-distributed-git/01-chapter5.markdown
index 404a05c4f..b216da970 100644
--- a/de/05-distributed-git/01-chapter5.markdown
+++ b/de/05-distributed-git/01-chapter5.markdown
@@ -32,8 +32,8 @@ Bild 5-1. Zentralisierter Workflow
 
 Das heißt: wenn zwei Entwickler Code aus dem zentralen Repository abholen und beide Änderungen vornehmen, dann kann der erste Entwickler seine Änderungen ohne Probleme im zentralen Repository abliefern. Der zweite Entwickler muss sie zunächst mit den Änderungen des ersten Entwicklers zusammenführen, damit er dessen Arbeit nicht überschreibt. Dieses Konzept trifft sowohl auf Git als auch auf Subversion (und jedes andere CVCS) zu, und es funktioniert in Git perfekt.
 
-<!--If you have a small team or are already comfortable with a centralized workflow in your company or team, you can easily continue using that workflow with Git. Simply set up a single repository, and give everyone on your team push access; Git won’t let users overwrite each other. If one developer clones, makes changes, and then tries to push their changes while another developer has pushed in the meantime, the server will reject that developer’s changes. They will be told that they’re trying to push non-fast-forward changes and that they won’t be able to do so until they fetch and merge.
-This workflow is attractive to a lot of people because it’s a paradigm that many are familiar and comfortable with.-->
+<!--If you have a small team or are already comfortable with a centralized workflow in your company or team, you can easily continue using that workflow with Git. Simply set up a single repository, and give everyone on your team push access; Git won’t let users overwrite each other. If one developer clones, makes changes, and then tries to push their changes while another developer has pushed in the meantime, the server will reject that developer’s changes. They will be told that they’re trying to push non-fast-forward changes and that they won’t be able to do so until they fetch and merge.-->
+<!--This workflow is attractive to a lot of people because it’s a paradigm that many are familiar and comfortable with.-->
 
 In einem kleinen Team oder einem Team, das mit einem zentralisierten Workflow zufrieden ist, kann man diesen Workflow ohne weiteres mit Git realisieren. Man setzt einfach ein einziges Repository auf und gibt jedem im Team Schreibzugriff („push access“). Git sorgt dann dafür, dass niemand die Arbeit von anderen überschreiben kann. Wenn ein Entwickler das Repository klont, Änderungen vornimmt und dann versucht ins zentrale Repository zu pushen, obwohl jemand anders in der Zwischenzeit Änderungen gepusht hat, dann wird der Server das zurückweisen. Dem Entwickler wird dann mitgeteilt, dass er versucht hat, sogeannte „non-fast-forward“ Änderungen hochzuladen und dass er zuvor die Änderungen des anderen Entwicklers herunterladen und mit seinen zusammenführen muss. Viele Leute mögen diesen Arbeitsablauf, weil sie mit dem Paradigma bereits vertraut sind und sich damit wohl fühlen.
 
@@ -45,12 +45,12 @@ In einem kleinen Team oder einem Team, das mit einem zentralisierten Workflow zu
 
 Weil Git ermöglicht, eine Vielzahl von externen Repositories zu betreiben, ist es außerdem möglich, einen Arbeitsprozess zu gestalten, in dem jeder Entwickler Schreibzugriff auf sein eigenes öffentliches Repository hat, aber nur Lesezugriff auf die Repositories von allen anderen Beteiligten. In diesem Szenario stellt jedes Repository ein eigenes „offizielles“ Projekt dar. Um zu einem solchen distribuierten Projekt Änderungen beizusteuern, kannst Du einen eigenen, öffentlichen Klon des Projektes anlegen und Deine Änderungen dort publizieren. Anschließend kannst Du den Betreiber des Haupt-Repositories bitten, Deine Änderungen in sein Repository zu übernehmen. Er kann dann Dein Repository als ein externes Repository auf seinem Rechner einrichten, Deine Änderungen lokal testen, sie in einen seiner Branches (z.B. master) mergen und dann in sein öffentliches Repository pushen. Dieser Prozess läuft wie folgt ab (siehe Bild 5-2):
 
-<!--1. The project maintainer pushes to their public repository.
-2. A contributor clones that repository and makes changes.
-3. The contributor pushes to their own public copy.
-4. The contributor sends the maintainer an e-mail asking them to pull changes.
-5. The maintainer adds the contributor’s repo as a remote and merges locally.
-6. The maintainer pushes merged changes to the main repository.-->
+<!--1. The project maintainer pushes to their public repository.-->
+<!--2. A contributor clones that repository and makes changes.-->
+<!--3. The contributor pushes to their own public copy.-->
+<!--4. The contributor sends the maintainer an e-mail asking them to pull changes.-->
+<!--5. The maintainer adds the contributor’s repo as a remote and merges locally.-->
+<!--6. The maintainer pushes merged changes to the main repository.-->
 
 1.  Der Projekt Betreiber pusht in ein öffentliches Repository.
 2.  Ein Mitarbeiter klont das Repository und nimmt Änderungen daran vor.
@@ -75,10 +75,10 @@ Dies ist ein weit verbreiteter Arbeitsablauf wie ihn z.B. auch GitHub ermöglich
 
 Dies ist Variante eines Workflows mit zahlreichen Repositories, die normalerweise von sehr großen Projekten mit hunderten von Mitarbeitern verwendet wird. Das bekannteste Beispiel ist wahrscheinlich der Linux Kernel. In diesem Projekt sind zahlreiche Integration Manager, die „Leutnants“, für verschiedene Bereiche des Repositories zuständig. Für sämtliche Leutnants gibt es wiederum einen Integration Manager, der als der „wohlwollende Diktator“ („benevolent dictator“) bezeichnet wird. Das Repository des wohlwollenden Diktators fungiert als das Referenz-Repository aus dem alle Beteiligten ihre eigenen Repositories aktualisieren müssen. Dieser Prozess funktioniert also wie folgt (siehe Bild 5-3)
 
-<!--1. Regular developers work on their topic branch and rebase their work on top of master. The master branch is that of the dictator.
-2. Lieutenants merge the developers’ topic branches into their master branch.
-3. The dictator merges the lieutenants’ master branches into the dictator’s master branch.
-4. The dictator pushes their master to the reference repository so the other developers can rebase on it.-->
+<!--1. Regular developers work on their topic branch and rebase their work on top of master. The master branch is that of the dictator.-->
+<!--2. Lieutenants merge the developers’ topic branches into their master branch.-->
+<!--3. The dictator merges the lieutenants’ master branches into the dictator’s master branch.-->
+<!--4. The dictator pushes their master to the reference repository so the other developers can rebase on it.-->
 
 1.  Normale Entwickler arbeiten in ihren Arbeitsbranches (xxx) und rebasen (xxx) ihre Änderungen auf der Basis des Master Branches. Der Master Branch ist derjenige des Diktators.
 2.  Die Leutnants mergen die Arbeitsbranches der Entwickler in ihre Master Branches.
@@ -152,8 +152,8 @@ Wenn Du diesen Befehl ausführst, bevor Du einen Commit anlegst, warnt er dich,
 
 Versuche außerdem, Deine Änderungen in logisch zusammenhängende Einheiten zu gruppieren. Wenn möglich, versuche Commits möglichst leichtverständlich (xxx) zu gestalten: arbeite nicht ein ganzes Wochenende lang an fünf verschiedenen Problemen und committe sie dann am Montag als einen einzigen, riesigen Commit. Selbst wenn Du am Wochenende keine Commits angelegt hast, verwende die Staging Area, um Deine Änderungen auf mehrere Commits aufzuteilen, jeweils mit einer verständlichen Meldung. Wenn einige Änderungen dieselbe Datei betreffen, probiere sie mit `git add --patch` nur teilweise zur Staging Area hinzuzufügen (das werden wir in Kapitel 6 noch im Detail besprechen). Der Projekt Snapshot wird am Ende derselbe sein, ob Du nun einen einzigen großen oder mehrere kleine Commits anlegst, daher versuche, es anderen Entwickler zu erleichtern machen, Deine Änderungen zu verstehen. Auf diese Weise machst Du es auch einfacher, einzelne Änderungen später herauszunehmen oder rückgängig zu machen. Kapitel 6 beschreibt eine Reihe nützlicher Git Tricks, die hilfreich sind, um die Historie umzuschreiben oder interaktiv Dateien zur Staging Area hinzuzufügen. Verwende diese Hilfsmittel, um eine sauber und leicht verständliche Historie von Änderungen aufzubauen.
 
-<!--The last thing to keep in mind is the commit message. Getting in the habit of creating quality commit messages makes using and collaborating with Git a lot easier. As a general rule, your messages should start with a single line that’s no more than about 50 characters and that describes the changeset concisely, followed by a blank line, followed by a more detailed explanation. The Git project requires that the more detailed explanation include your motivation for the change and contrast its implementation with previous behavior — this is a good guideline to follow. It’s also a good idea to use the imperative present tense in these messages. In other words, use commands. Instead of "I added tests for" or "Adding tests for," use "Add tests for."
-Here is a template originally written by Tim Pope at tpope.net:-->
+<!--The last thing to keep in mind is the commit message. Getting in the habit of creating quality commit messages makes using and collaborating with Git a lot easier. As a general rule, your messages should start with a single line that’s no more than about 50 characters and that describes the changeset concisely, followed by a blank line, followed by a more detailed explanation. The Git project requires that the more detailed explanation include your motivation for the change and contrast its implementation with previous behavior — this is a good guideline to follow. It’s also a good idea to use the imperative present tense in these messages. In other words, use commands. Instead of "I added tests for" or "Adding tests for," use "Add tests for."-->
+<!--Here is a template originally written by Tim Pope at tpope.net:-->
 
 Ein weitere Sache, der Du ein bisschen Aufmerksamkeit schenken solltest, ist die Commit Meldung selbst. Wenn man sich angewöhnt, aussagekräftige und hochwertige Commit Meldungen zu schreiben, macht man sich selbst und anderen das Leben erheblich einfacher. Im allgemeinen sollte eine Commit Meldung mit einer einzelnen Zeile anfangen, die nicht länger als 50 Zeichen sein sollte. Dann sollte eine leere Zeile folgen und schließlich eine ausführlichere Beschreibung der Änderungen.
 
@@ -188,8 +188,8 @@ In den folgenden Beispielen hier und fast überall in diesem Buch verwende ich k
 
 Das einfachste Setup, mit dem Du zu tun haben wirst, ist ein privates Projekt mit ein oder zwei Entwicklern. Mit „privat“ meine ich, dass es „closed source“, d.h. nicht lesbar für Dritte ist. Alle beteiligten Entwickler haben Schreibzugriff auf das Repository.
 
-<!--In this environment, you can follow a workflow similar to what you might do when using Subversion or another centralized system. You still get the advantages of things like offline committing and vastly simpler branching and merging, but the workflow can be very similar; the main difference is that merges happen client-side rather than on the server at commit time.
-Let’s see what it might look like when two developers start to work together with a shared repository. The first developer, John, clones the repository, makes a change, and commits locally. (I’m replacing the protocol messages with `...` in these examples to shorten them somewhat.)-->
+<!--In this environment, you can follow a workflow similar to what you might do when using Subversion or another centralized system. You still get the advantages of things like offline committing and vastly simpler branching and merging, but the workflow can be very similar; the main difference is that merges happen client-side rather than on the server at commit time.-->
+<!--Let’s see what it might look like when two developers start to work together with a shared repository. The first developer, John, clones the repository, makes a change, and commits locally. (I’m replacing the protocol messages with `...` in these examples to shorten them somewhat.)-->
 
 In einer solchen Umgebung kann man einen ähnlichen Workflow verwenden, wie für Subversion oder ein anderes zentralisiertes System. Du hast dann immer noch Vorteile wie, dass Du offline committen kannst und dass Branching und Merging so unglaublich einfach ist. Der Hauptunterschied ist, dass Merges auf der Client Seite stattfinden und nicht, wenn man committet, auf dem Server. Schauen wir uns an, wie die Arbeit von zwei Entwicklern in einem gemeinsamen Repository abläuft. Der erste Entwickler, John, klont das Repository, nimmt eine Änderung vor und comittet auf seinem Rechner. (Wir kürzen die Beispiele etwas ab und ersetzen die hierfür irrelevanten Protokoll Meldungen mit `xxx`.)
 
@@ -765,8 +765,8 @@ Zunächst musst Du die IMAP Sektion in Deiner `~/.gitconfig` Datei ausfüllen. D
 	  port = 993
 	  sslverify = false
 
-<!--If your IMAP server doesn’t use SSL, the last two lines probably aren’t necessary, and the host value will be `imap://` instead of `imaps://`.
-When that is set up, you can use `git send-email` to place the patch series in the Drafts folder of the specified IMAP server:-->
+<!--If your IMAP server doesn’t use SSL, the last two lines probably aren’t necessary, and the host value will be `imap://` instead of `imaps://`.-->
+<!--When that is set up, you can use `git send-email` to place the patch series in the Drafts folder of the specified IMAP server:-->
 
 Wenn Dein IMAP Server kein SSL verwendet, kannst Du die letzten beiden Zeilen wahrscheinlich weglassen und der `host` dürfte mit `imap://` und nicht `imaps://` beginnen. Wenn Du diese Einstellungen konfiguriert hast, kannst Du `git send-email` verwenden, um Deine Patches in den Entwurfsordner des angegebenen IMAP Servers zu kopieren:
 
@@ -818,8 +818,8 @@ Neben dem Wissen, das Du brauchst, um zu einem bestehenden Projekt Änderungen b
 <!--### Working in Topic Branches ###-->
 ### In Topic Branches arbeiten ###
 
-<!--When you’re thinking of integrating new work, it’s generally a good idea to try it out in a topic branch — a temporary branch specifically made to try out that new work. This way, it’s easy to tweak a patch individually and leave it if it’s not working until you have time to come back to it. If you create a simple branch name based on the theme of the work you’re going to try, such as `ruby_client` or something similarly descriptive, you can easily remember it if you have to abandon it for a while and come back later. The maintainer of the Git project tends to namespace these branches as well — such as `sc/ruby_client`, where `sc` is short for the person who contributed the work.
-As you’ll remember, you can create the branch based off your master branch like this:-->
+<!--When you’re thinking of integrating new work, it’s generally a good idea to try it out in a topic branch — a temporary branch specifically made to try out that new work. This way, it’s easy to tweak a patch individually and leave it if it’s not working until you have time to come back to it. If you create a simple branch name based on the theme of the work you’re going to try, such as `ruby_client` or something similarly descriptive, you can easily remember it if you have to abandon it for a while and come back later. The maintainer of the Git project tends to namespace these branches as well — such as `sc/ruby_client`, where `sc` is short for the person who contributed the work.-->
+<!--As you’ll remember, you can create the branch based off your master branch like this:-->
 
 Wenn Du Änderungen von anderen übernehmen willst, ist normalerweise eine gute Idee, sie in einem Topic Branch auszuprobieren – d.h., einem temporären Branch, dessen Zweck nur darin besteht, die jeweiligen Änderungen auszuprobieren. Auf diese Weise ist es einfach, Patches ggf. anzupassen oder sie im Zweifelsfall im Topic Branch liegen zu lassen, wenn sie nicht funktionieren und Du im Moment nicht die Zeit hast, Dich weiter damit zu befassen. Es ist empfehlenswert, Topic Branches Namen zu geben, die gut kommunizieren, worum es sich bei den jeweiligen Änderungen dreht, wie z.B. `ruby_client` oder etwas ähnlich aussagekräftiges, das Dir hilft, Dich daran zu erinnern. Der Projekt Betreiber des Git Projektes selbst vergibt Namensräume für solche Branches – wie z.B. `sc/ruby_client`, wobei `sc` ein Kürzel für den jeweiligen Autor des Patches ist. Wie Du inzwischen weißt, kannst Du einen neuen Branch, der auf dem gegenwärtigen `master` Branch basiert, wie folgt erzeugen (xxx falsch, das stimmt nur, wenn `master` der aktuelle Branch ist xxx):
 
@@ -1117,8 +1117,8 @@ Bild 5-22. Nach dem Topic Branch Merge
 Insert 18333fig0523.png
 Bild 5-23. Nach dem Topic Branch Release
 
-<!--This way, when people clone your project’s repository, they can either check out master to build the latest stable version and keep up to date on that easily, or they can check out develop, which is the more cutting-edge stuff.
-You can also continue this concept, having an integrate branch where all the work is merged together. Then, when the codebase on that branch is stable and passes tests, you merge it into a develop branch; and when that has proven itself stable for a while, you fast-forward your master branch.-->
+<!--This way, when people clone your project’s repository, they can either check out master to build the latest stable version and keep up to date on that easily, or they can check out develop, which is the more cutting-edge stuff.-->
+<!--You can also continue this concept, having an integrate branch where all the work is merged together. Then, when the codebase on that branch is stable and passes tests, you merge it into a develop branch; and when that has proven itself stable for a while, you fast-forward your master branch.-->
 
 Auf diese Weise kann jeder, der Dein Repository klont, auf einfache Weise Deinen aktuellen `master` Branch verwenden und ihn auf neue Releases aktualisieren. Oder er kann den `develop` Branch ausprobieren, in dem sich die jeweils letzten, brandneuen Änderungen befinden. Du kannst dieses Konzept noch weiterführen, indem Du einen `integrate` Branch pflegst, in den neue Änderungen jeweils integriert werden. Sobald der Code in diesem Branch stabil zu sein scheint und alle Tests durchlaufen (xxx), übernimmst Du die Änderungen in den `develop` Branch. Und wenn sie sich für eine Weile in der Praxis als stabil erwiesen haben, fast-forwardest (xxx) Du den `master` Branch.
 
diff --git a/de/06-git-tools/01-chapter6.markdown b/de/06-git-tools/01-chapter6.markdown
index 032a2ef52..645938ee0 100644
--- a/de/06-git-tools/01-chapter6.markdown
+++ b/de/06-git-tools/01-chapter6.markdown
@@ -286,8 +286,8 @@ Dies ist nützlich, wenn Du vorhast, den `experiment` Branch zu aktualisieren, u
 
 	$ git log origin/master..HEAD
 
-<!--This command shows you any commits in your current branch that aren’t in the `master` branch on your `origin` remote. If you run a `git push` and your current branch is tracking `origin/master`, the commits listed by `git log origin/master..HEAD` are the commits that will be transferred to the server.
-You can also leave off one side of the syntax to have Git assume HEAD. For example, you can get the same results as in the previous example by typing `git log origin/master..` — Git substitutes HEAD if one side is missing.-->
+<!--This command shows you any commits in your current branch that aren’t in the `master` branch on your `origin` remote. If you run a `git push` and your current branch is tracking `origin/master`, the commits listed by `git log origin/master..HEAD` are the commits that will be transferred to the server.-->
+<!--You can also leave off one side of the syntax to have Git assume HEAD. For example, you can get the same results as in the previous example by typing `git log origin/master..` — Git substitutes HEAD if one side is missing.-->
 
 Dieser Befehl zeigt Dir alle Commits im gegenwärtigen, lokalen Branch, die noch nicht im `master` Branch des `origin` Repositories sind. D.h., der Befehl listet diejenigen Commits auf, die auf den Server transferiert würden, wenn Du `git push` benutzt und der aktuelle Branch `origin/master` trackt. Du kannst mit dieser Syntax außerdem eine Seite der beiden Punkte leer lassen. Git nimmt dann an, Du meinst an dieser Stelle HEAD. Z.B. kannst Du dieselben Commits wie im vorherigen Beispiel auch mit `git log origin/master..` anzeigen lassen. Git fügt dann HEAD auf der rechten Seite ein.
 
@@ -316,8 +316,8 @@ Damit hast Du ein sehr mächtiges System von Abfragen zur Verfügung, mit denen
 <!--#### Triple Dot ####-->
 #### Drei-Punkte Syntax ####
 
-<!--The last major range-selection syntax is the triple-dot syntax, which specifies all the commits that are reachable by either of two references but not by both of them. Look back at the example commit history in Figure 6-1.
-If you want to see what is in `master` or `experiment` but not any common references, you can run-->
+<!--The last major range-selection syntax is the triple-dot syntax, which specifies all the commits that are reachable by either of two references but not by both of them. Look back at the example commit history in Figure 6-1.-->
+<!--If you want to see what is in `master` or `experiment` but not any common references, you can run-->
 
 Die letzte wichtige Syntax, mit der man Commit Reihen spezifizieren kann, ist die Drei-Punkte Syntax, die alle Commits anzeigt, die in einer der beiden Referenzen enthalten sind, aber nicht in beiden. Schau Dir noch mal die Commit Historie in Bild 6-1- an. Wenn Du diejenigen Commits anzeigen willst, die in den `master` und `experiment` Branches, nicht aber in beiden Branches gleichzeitig  enthalten sind, dann kannst Du folgendes tun:
 
@@ -348,8 +348,8 @@ Mit diesen Hilfsmitteln kannst Du noch einfacher und genauer angeben, welche Com
 <!--## Interactive Staging ##-->
 ## Interaktives Stagen ##
 
-<!--Git comes with a couple of scripts that make some command-line tasks easier. Here, you’ll look at a few interactive commands that can help you easily craft your commits to include only certain combinations and parts of files. These tools are very helpful if you modify a bunch of files and then decide that you want those changes to be in several focused commits rather than one big messy commit. This way, you can make sure your commits are logically separate changesets and can be easily reviewed by the developers working with you.
-If you run `git add` with the `-i` or `-\-interactive` option, Git goes into an interactive shell mode, displaying something like this:-->
+<!--Git comes with a couple of scripts that make some command-line tasks easier. Here, you’ll look at a few interactive commands that can help you easily craft your commits to include only certain combinations and parts of files. These tools are very helpful if you modify a bunch of files and then decide that you want those changes to be in several focused commits rather than one big messy commit. This way, you can make sure your commits are logically separate changesets and can be easily reviewed by the developers working with you.-->
+<!--If you run `git add` with the `-i` or `-\-interactive` option, Git goes into an interactive shell mode, displaying something like this:-->
 
 Git umfasst eine Reihe von Skripten, die so manche Aufgabe auf der Kommandozeile leichter machen. Im folgenden schauen wir uns einige interaktive Befehle an, die dabei hilfreich sein können, wenn man Änderungen in vielen Dateien vorgenommen hat, aber nur einige Änderungen gezielt committen will – nicht alles auf einmal in einem riesigen Commit. Auf diese Weise kann man Commits logisch gruppieren und macht es anderen Entwicklern damit leichter, sie zu verstehen. Wenn Du `git add` mit der `-i` oder `--interactive` Option verwendest, geht Git in einen interaktiven Shell Modus, der in etwa wie folgt aussieht:
 
diff --git a/de/08-git-and-other-scms/01-chapter8.markdown b/de/08-git-and-other-scms/01-chapter8.markdown
index f183fdd11..4ae40993d 100644
--- a/de/08-git-and-other-scms/01-chapter8.markdown
+++ b/de/08-git-and-other-scms/01-chapter8.markdown
@@ -464,8 +464,8 @@ Auf diese Weise müllst Du Dein Projekt nicht mit `.gitignore`-Dateien zu. Das i
 
 Die `git svn`-Werkzeuge sind sehr nützlich, wenn Du derzeit (noch) an einen Subversion-Server gebunden bist oder Dich anderweitig in einer Entwicklungsumgebung befindest, die nicht auf einen Subversion-Server verzichten kann. Wie auch immer: Du solltest es als eine Art gestutztes Git ansehen. Anderenfalls läufst Du Gefahr, Dich und Deine Kollegen durcheinander zu bringen. Um dieses Kliff zu umschiffen, solltest Du folgende Richtlinien befolgen:
 
-<!--* Keep a linear Git history that doesn’t contain merge commits made by `git merge`. Rebase any work you do outside of your mainline branch back onto it; don’t merge it in.
-* Don’t set up and collaborate on a separate Git server. Possibly have one to speed up clones for new developers, but don’t push anything to it that doesn’t have a `git-svn-id` entry. You may even want to add a `pre-receive` hook that checks each commit message for a `git-svn-id` and rejects pushes that contain commits without it.-->
+<!--* Keep a linear Git history that doesn’t contain merge commits made by `git merge`. Rebase any work you do outside of your mainline branch back onto it; don’t merge it in.-->
+<!--* Don’t set up and collaborate on a separate Git server. Possibly have one to speed up clones for new developers, but don’t push anything to it that doesn’t have a `git-svn-id` entry. You may even want to add a `pre-receive` hook that checks each commit message for a `git-svn-id` and rejects pushes that contain commits without it.-->
 
 * Versuch, eine „geradlinige“ Git-Historie zu führen, die keine von `git merge` durchgeführten Merges enthält. Alle Arbeiten, die Du außerhalb des Hauptzweiges durchführst, solltest Du mit `rebase` in ihn aufnehmen anstatt sie zu mit `merge` zusammenzuführen.
 * Setz keinen zusätzlichen, externen Git-Server auf, mit dem Du arbeiten möchtest. Du kannst einen aufsetzen um die Klone für neue Entwickler zu beschleunigen, aber Du solltest keine Änderungen dorthin pushen, die keine `git-svn-id`-Einträge haben. Du solltest vielleicht sogar darüber nachdenken, einen `pre-receive`-Hook einzusetzen, der jede Commit-Nachricht auf eine `git-svn-id` prüft und bestimmte Pushes ablehnt, bei denen diese IDs fehlt.
diff --git a/de/09-git-internals/01-chapter9.markdown b/de/09-git-internals/01-chapter9.markdown
index e58370210..2b3f3ad99 100644
--- a/de/09-git-internals/01-chapter9.markdown
+++ b/de/09-git-internals/01-chapter9.markdown
@@ -54,8 +54,8 @@ Damit bleiben vier wichtige Einträge übrig: die Dateien `HEAD` und `index` und
 <!--## Git Objects ##-->
 ## Git Objekte ##
 
-<!--Git is a content-addressable filesystem. Great. What does that mean?
-It means that at the core of Git is a simple key-value data store. You can insert any kind of content into it, and it will give you back a key that you can use to retrieve the content again at any time. To demonstrate, you can use the plumbing command `hash-object`, which takes some data, stores it in your `.git` directory, and gives you back the key the data is stored as. First, you initialize a new Git repository and verify that there is nothing in the `objects` directory:-->
+<!--Git is a content-addressable filesystem. Great. What does that mean?-->
+<!--It means that at the core of Git is a simple key-value data store. You can insert any kind of content into it, and it will give you back a key that you can use to retrieve the content again at any time. To demonstrate, you can use the plumbing command `hash-object`, which takes some data, stores it in your `.git` directory, and gives you back the key the data is stored as. First, you initialize a new Git repository and verify that there is nothing in the `objects` directory:-->
 
 Git ist ein Dateisystem, das Inhalte addressieren kann. Prima. Aber was heißt das? Es bedeutet, dass Git im Kern nichts anderes ist als ein einfacher Key-Value-Store („Schlüssel-Wert-Speicher“). Du kannst darin jede Art von Inhalt ablegen und Git wird einen Schlüssel dafür zurückgeben, den Du dann verwenden kannst, um diesen Inhalt jederzeit nachzuschlagen. Um das auszuprobieren, kannst Du den Plumbing Befehl `hash-object` verwenden. Dieser nimmt einen Inhalt an, speichert ihn in Deinem `.git` Verzeichnis und gibt Dir den Schlüssel zurück, unter dem der Inhalt gespeichert wurde. Dazu initialisierst Du als erstes ein neues Git Repository und verifizierst, dass das `objects` Verzeichnis leer ist:
 
@@ -718,8 +718,8 @@ Außerdem ist toll, dass ein Repository jederzeit neu gepackt werden kann. Git m
 <!--## The Refspec ##-->
 ## Die Refspec ##
 
-<!--Throughout this book, you’ve used simple mappings from remote branches to local references; but they can be more complex.
-Suppose you add a remote like this:-->
+<!--Throughout this book, you’ve used simple mappings from remote branches to local references; but they can be more complex.-->
+<!--Suppose you add a remote like this:-->
 
 In diesem Buch haben wir bisher einfache Mappings von externen Branches auf lokale Referenzen verwendet. Sie können aber auch durchaus komplex sein. Nehmen wir an, Du hast ein externes Repository wie folgt definiert:
 
@@ -1194,8 +1194,8 @@ Es sieht also so aus, als sei der untere Commit derjenige, den Du verloren hast,
 	cac0cab538b970a37ea1e769cbbde608743bc96d second commit
 	fdf4fc3344e67ab068f836878b6c4951e3b15f3d first commit
 
-<!--Cool — now you have a branch named `recover-branch` that is where your `master` branch used to be, making the first two commits reachable again.
-Next, suppose your loss was for some reason not in the reflog — you can simulate that by removing `recover-branch` and deleting the reflog. Now the first two commits aren’t reachable by anything:-->
+<!--Cool — now you have a branch named `recover-branch` that is where your `master` branch used to be, making the first two commits reachable again.-->
+<!--Next, suppose your loss was for some reason not in the reflog — you can simulate that by removing `recover-branch` and deleting the reflog. Now the first two commits aren’t reachable by anything:-->
 
 Sehr gut. Du hast jetzt einen neuen Branch `recover-branch`, der diejenigen Commits enthält, die sich zuvor in Deinem `master` Branch befanden. Damit hast Du wieder Zugriff auf die beiden verloren gegangenen Commits. Als nächstes nehmen wir aber außerdem an, dass diese verlorenen Commits aus irgendeinem Grunde nicht im Reflog enthalten sind – Du kannst das z.B. simulieren, indem Du den Branch `recover-branch` und das Reflog löschst. Damit sind die beiden Commits jetzt von nirgendwo her mehr erreichbar:
 

From cdd3c9dd2faa4eac7aa8e7f343943ec9cd8444d1 Mon Sep 17 00:00:00 2001
From: Ralph Haussmann <ralph@scanmyfood.de>
Date: Sun, 12 Jan 2014 15:46:27 +0100
Subject: [PATCH 080/690] [de] Chapter 2: Merge original english updates to
 german translation and translate them

---
 de/02-git-basics/01-chapter2.markdown | 65 +++++++++++++++++++++++----
 1 file changed, 57 insertions(+), 8 deletions(-)

diff --git a/de/02-git-basics/01-chapter2.markdown b/de/02-git-basics/01-chapter2.markdown
index e9e64a7bd..518e1cd7e 100644
--- a/de/02-git-basics/01-chapter2.markdown
+++ b/de/02-git-basics/01-chapter2.markdown
@@ -245,6 +245,20 @@ Glob Muster sind vereinfachte reguläre Ausdrücke, die von der Shell verwendet
 
 Hier ist ein weiteres Beispiel für eine `.gitignore` Datei:
 
+<!--	# a comment - this is ignored-->
+<!--	# no .a files-->
+<!--	*.a-->
+<!--	# but do track lib.a, even though you're ignoring .a files above-->
+<!--	!lib.a-->
+<!--	# only ignore the root TODO file, not subdir/TODO-->
+<!--	/TODO-->
+<!--	# ignore all files in the build/ directory-->
+<!--	build/-->
+<!--	# ignore doc/notes.txt, but not doc/server/arch.txt-->
+<!--	doc/*.txt-->
+<!--	# ignore all .txt files in the doc/ directory-->
+<!--	doc/**/*.txt-->
+
 	# ein Kommentar - dieser wird ignoriert
 	# ignoriert alle Dateien, die mit .a enden
 	*.a
@@ -252,12 +266,16 @@ Hier ist ein weiteres Beispiel für eine `.gitignore` Datei:
 	!lib.a
 	# ignoriert eine TODO Datei nur im Wurzelverzeichnis, nicht aber
 	/TODO
-	# in Unterverzeichnissen
-
 	# ignoriert alle Dateien im build/ Verzeichnis
 	build/
 	# ignoriert doc/notes.txt, aber nicht doc/server/arch.txt
 	doc/*.txt
+	# ignoriert alle .txt Dateien unterhalb des doc/ Verzeichnis
+	doc/**/*.txt
+
+<!--A `**/` pattern is available in Git since version 1.8.2.-->
+
+Die Kombination `**/` wurde in der Git Version 1.8.2 eingeführt.
 
 <!--### Viewing Your Staged and Unstaged Changes ###-->
 ### Die Änderungen in der Staging Area durchsehen ###
@@ -617,11 +635,13 @@ Eine sehr nützliche Option ist `-p`. Sie zeigt die Änderungen an, die in einem
 	index a874b73..8f94139 100644
 	--- a/Rakefile
 	+++ b/Rakefile
-	@@ -5,7 +5,7 @@ require 'rake/gempackagetask'
+	@@ -5,5 +5,5 @@ require 'rake/gempackagetask'
 	 spec = Gem::Specification.new do |s|
+	     s.name      =   "simplegit"
 	-    s.version   =   "0.1.0"
 	+    s.version   =   "0.1.1"
 	     s.author    =   "Scott Chacon"
+	     s.email     =   "schacon@gee-mail.com
 
 	commit 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7
 	Author: Scott Chacon <schacon@gee-mail.com>
@@ -645,9 +665,36 @@ Eine sehr nützliche Option ist `-p`. Sie zeigt die Änderungen an, die in einem
 	\ No newline at end of file
 
 <!--This option displays the same information but with a diff directly following each entry. This is very helpful for code review or to quickly browse what happened during a series of commits that a collaborator has added.-->
+
+Diese Option zeigt also im Prinzip die gleiche Information wie zuvor, aber zusätzlich zu jedem Eintrag ein Diff. Das ist nützlich, um einen Code Review zu machen oder eben mal eine Reihe von Commits durchzuschauen, die ein Mitarbeiter angelegt hat.
+
+<!--Sometimes it's easier to review changes on the word level rather than on the line level. There is a `-\-word-diff` option available in Git, that you can append to the `git log -p` command to get word diff instead of normal line by line diff. Word diff format is quite useless when applied to source code, but it comes in handy when applied to large text files, like books or your dissertation. Here is an example:-->
+
+Manchmal ist es einfacher Änderungen an Hand der Wörter anstatt zeilenbasiert zu überprüfen. Git bietet dafür die Option `--word-diff`, welche man an den Befehl `git log -p` anhängen kann. Man weist Git damit an, einen Vergleich auf Basis der Wörter anstatt Zeile für Zeile durchzuführen. Dieser Vergleich ist ziemlich nutzlos wenn man Änderungen innerhalb von Quellcode vergleicht. Beim Vergleich von langen Textdateien zeigt er aber seine Stärke. Er bietet sich zum Beispiel für Bücher oder wissenschaftliche Texte an. Hierzu ein Beispiel:
+
+	$ git log -U1 --word-diff
+	commit ca82a6dff817ec66f44342007202690a93763949
+	Author: Scott Chacon <schacon@gee-mail.com>
+	Date:   Mon Mar 17 21:52:11 2008 -0700
+
+	    changed the version number
+
+	diff --git a/Rakefile b/Rakefile
+	index a874b73..8f94139 100644
+	--- a/Rakefile
+	+++ b/Rakefile
+	@@ -7,3 +7,3 @@ spec = Gem::Specification.new do |s|
+	    s.name      =   "simplegit"
+	    s.version   =   [-"0.1.0"-]{+"0.1.1"+}
+	    s.author    =   "Scott Chacon"
+
+<!--As you can see, there is no added and removed lines in this output as in a normal diff. Changes are shown inline instead. You can see the added word enclosed in `{+ +}` and removed one enclosed in `[- -]`. You may also want to reduce the usual three lines context in diff output to only one line, as the context is now words, not lines. You can do this with `-U1` as we did in the example above.-->
+
+Wie man in der Ausgabe sehen kann, zeigt dieser Vergleich nicht an, welche Zeilen hinzugekommen und welche entfallen sind. Stattdessen werden Änderungen innerhalb der Zeilen dargestellt. Mit der Sequenz `{+ +}` wird ein neu hinzugekommes Wort gekennzeichnet, mit `[- -]` ein Wort, welches entfernt wurde. Normalerweise zeigt Git bei einem Vergleich drei zusätzliche Zeilen ober- und unterhalb der eigentlichen Änderung an. Bei einem Textvergleich reicht meist eine zusätzliche Zeile. Man kann dies mit der Option `-U1` erreichen, so wie in dem oben gezeigten Beispiel.
+
 <!--You can also use a series of summarizing options with `git log`. For example, if you want to see some abbreviated stats for each commit, you can use the `-\-stat` option:-->
 
-Diese Option zeigt also im Prinzip die gleiche Information wie zuvor, aber zusätzlich zu jedem Eintrag ein Diff. Das ist nützlich, um einen Code Review zu machen oder eben mal eine Reihe von Commits durchzuschauen, die ein Mitarbeiter angelegt hat. Außerdem gibt es verschiedene Optionen, die nützlich sind, um Dinge zusammenzufassen. Beispielsweise kannst Du eine kurze Statistik über jeden Commit mit der Option `--stat` anzeigen lassen:
+Außerdem gibt es verschiedene Optionen, die nützlich sind, um Dinge zusammenzufassen. Beispielsweise kannst Du eine kurze Statistik über jeden Commit mit der Option `--stat` anzeigen lassen:
 
 	$ git log --stat
 	commit ca82a6dff817ec66f44342007202690a93763949
@@ -762,6 +809,7 @@ Das sind nur einige eher simple Format Optionen für die Ausgabe von `git log` 
 
 <!--	Option	Description-->
 <!--	-p	Show the patch introduced with each commit.-->
+<!--	-\-word-diff	Show the patch in a word diff format.-->
 <!--	-\-stat	Show statistics for files modified in each commit.-->
 <!--	-\-shortstat	Display only the changed/insertions/deletions line from the -\-stat command.-->
 <!--	-\-name-only	Show the list of files modified after the commit information.-->
@@ -774,6 +822,7 @@ Das sind nur einige eher simple Format Optionen für die Ausgabe von `git log` 
 
 	Option	Beschreibung
 	-p	Zeigt den Patch, der einem Commit entspricht.
+	--word-diff	Führt den Vergleich Wort für Wort, anstatt Zeile für Zeile aus.
 	--stat	Zeigt Statistiken über die in einem Commit geänderten Dateien und eingefügten/entfernten Zeilen.
 	--shortstat	Zeigt nur die Kurzstatistik über eingefügte/entfernte Zeilen aus der `--stat` Option.
 	--name-only	Zeigt die Liste der geänderte Dateien nach der Commit Information.
@@ -1363,7 +1412,7 @@ Du kannst Commits jederzeit taggen, auch lange Zeit nachdem sie angelegt wurden.
 
 Nehmen wir an, dass Du vergessen hast, Version v1.2 des Projekts zu taggen und dass dies der Commit „updated rakefile“ gewesen ist. Du kannst diesen jetzt im Nachhinein taggen, indem Du die Checksumme des Commits (oder einen Teil davon) am Ende des Befehls angibst:
 
-	$ git tag -a v1.2 9fceb02
+	$ git tag -a v1.2 -m 'version 1.2' 9fceb02
 
 <!--You can see that you’ve tagged the commit:-->
 
@@ -1435,11 +1484,11 @@ Bevor wir zum Ende dieses Grundlagenkapitels kommen, möchten wir noch einige Ti
 <!--### Auto-Completion ###-->
 ### Auto-Vervollständigung ###
 
-<!--If you use the Bash shell, Git comes with a nice auto-completion script you can enable. Download the Git source code, and look in the `contrib/completion` directory; there should be a file called `git-completion.bash`. Copy this file to your home directory, and add this to your `.bashrc` file:-->
+<!--If you use the Bash shell, Git comes with a nice auto-completion script you can enable. Download it directly from the Git source code at https://github.com/git/git/blob/master/contrib/completion/git-completion.bash . Copy this file to your home directory, and add this to your `.bashrc` file:-->
 
-Wenn Du die Bash Shell verwendest, dann kannst Du ein Skript für die Git Auto-Vervollständigung einbinden. Ein solches Skript wird mit Git zusammen ausgeliefert. Wenn Du den Git Quellcode heruntergeladen hast, findest Du im Verzeichnis `contrib/completion` die Datei `git-completion.bash`. Kopiere diese Datei in Dein Home Verzeichnis  und füge die folgende Zeile in Deine `.bashrc` Datei hinzu:
+Wenn Du die Bash Shell verwendest, dann kannst Du ein Skript für die Git Auto-Vervollständigung einbinden. Du kannst dieses Skript direkt aus den Git Quellen von https://github.com/git/git/blob/master/contrib/completion/git-completion.bash herunterladen. Kopiere diese Datei in Dein Home Verzeichnis  und füge die folgende Zeile in Deine `.bashrc` Datei hinzu:
 
-	source ~/.git-completion.bash
+	source ~/git-completion.bash
 
 <!--If you want to set up Git to automatically have Bash shell completion for all users, copy this script to the `/opt/local/etc/bash_completion.d` directory on Mac systems or to the `/etc/bash_completion.d/` directory on Linux systems. This is a directory of scripts that Bash will automatically load to provide shell completions.-->
 

From 61fa2ee87e3acb3bc80a9052ab2aa79b28c90564 Mon Sep 17 00:00:00 2001
From: Ralph Haussmann <ralph@scanmyfood.de>
Date: Sun, 12 Jan 2014 16:29:45 +0100
Subject: [PATCH 081/690] [de] Chapter 3: Merge original english updates to
 german translation and translate them

---
 de/03-git-branching/01-chapter3.markdown | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/de/03-git-branching/01-chapter3.markdown b/de/03-git-branching/01-chapter3.markdown
index 22945fc2b..484496a93 100644
--- a/de/03-git-branching/01-chapter3.markdown
+++ b/de/03-git-branching/01-chapter3.markdown
@@ -24,12 +24,12 @@ Wenn Du in Git committest, speichert Git ein sogenanntes Commit-Objekt. Dieses e
 
 Um das zu verdeutlichen, lass uns annehmen, Du hast ein Verzeichnis mit drei Dateien, die Du alle zu der Staging-Area hinzufügst und in einem Commit verpackst. Durch das Stagen der Dateien erzeugt Git für jede Datei eine Prüfsumme (der SHA-1 Hash, den wir in Kapitel 1 erwähnt haben), speichert diese Version der Datei im Git-Repository (Git referenziert auf diese als Blobs) und fügt die Prüfsumme der Staging-Area hinzu:
 
-	$ git add README test.rb LICENSE2
+	$ git add README test.rb LICENSE
 	$ git commit -m 'initial commit of my project'
 
-<!--When you create the commit by running `git commit`, Git checksums each subdirectory (in this case, just the root project directory) and stores those tree objects in the Git repository. Git then creates a commit object that has the metadata and a pointer to the root project tree so it can re-create that snapshot when needed.-->
+<!--Running `git commit` checksums all project directories and stores them as `tree` objects in the Git repository. Git then creates a `commit` object that has the metadata and a pointer to the root project `tree` object so it can re-create that snapshot when needed.-->
 
-Wenn Du einen Commit mit dem Kommando `git commit` erstellst, erzeugt Git für jedes Unterverzeichnis eine Prüfsumme (in diesem Fall nur für das Root-Verzeichnis) und speichert diese drei Objekte im Git Repository. Git erzeugt dann ein Commit Objekt, das die Metadaten und den Zeiger zur Wurzel des Projektbaums enthält, um bei Bedarf den Snapshot erneut erzeugen zu können.
+Wenn Du einen Commit mit dem Kommando `git commit` erstellst, erzeugt Git für jedes Projektverzeichnis eine Prüfsumme und speichert diese als sogenanntes `tree`-Objekt im Git Repository. Git erzeugt dann ein Commit Objekt, das die Metadaten und den Zeiger zum `tree`-Objekt des Wurzelverzeichnis enthält, um bei Bedarf den Snapshot erneut erzeugen zu können.
 
 <!--Your Git repository now contains five objects: one blob for the contents of each of your three files, one tree that lists the contents of the directory and specifies which file names are stored as which blobs, and one commit with the pointer to that root tree and all the commit metadata. Conceptually, the data in your Git repository looks something like Figure 3-1.-->
 
@@ -255,7 +255,7 @@ Zu diesem Zeitpunkt befindet sich das Arbeitsverzeichnis des Projektes in exakt
 
 Nun hast Du einen Hotfix zu erstellen. Lass uns dazu einen Hotfix-Branch erstellen, an dem Du bis zu dessen Fertigstellung arbeitest (siehe Abbildung 3-13):
 
-	$ git checkout -b 'hotfix'
+	$ git checkout -b hotfix
 	Switched to a new branch "hotfix"
 	$ vim index.html
 	$ git commit -a -m 'fixed the broken email address'
@@ -485,9 +485,9 @@ Das `*` vor dem `master`-Branch bedeutet, dass dies der gerade ausgecheckte Bran
 	* master  7a98805 Merge branch 'iss53'
 	  testing 782fd34 add scott to the author list in the readmes
 
-<!--Another useful option to figure out what state your branches are in is to filter this list to branches that you have or have not yet merged into the branch you’re currently on. The useful `-\-merged` and `-\-no-merged` options have been available in Git since version 1.5.6 for this purpose. To see which branches are already merged into the branch you’re on, you can run `git branch -\-merged`:-->
+<!--Another useful option to figure out what state your branches are in is to filter this list to branches that you have or have not yet merged into the branch you’re currently on. There are useful `-\-merged` and `-\-no-merged` options available in Git for this purpose. To see which branches are already merged into the branch you’re on, you can run `git branch -\-merged`:-->
 
-Mit einer weiteren nützlichen Option kannst Du herausfinden, in welchem Zustand Deine Branches sind: welche der Branches wurden bereits in den aktuellen Branch gemergt und welche wurden es nicht. Die Optionen heißen `--merged` und `--no-merged` und sind seit Version 1.5.6 in Git dabei. Um herauszufinden, welche Branches schon in den aktuell ausgecheckten gemergt wurden, kannst Du einfach `git branch --merged` aufrufen:
+Mit einer weiteren nützlichen Option kannst Du herausfinden, in welchem Zustand Deine Branches sind: welche der Branches wurden bereits in den aktuellen Branch gemergt und welche wurden es nicht. Für diesen Zweck gibt es in Git die Optionen `--merged` und `--no-merged`. Um herauszufinden, welche Branches schon in den aktuell ausgecheckten gemergt wurden, kannst Du einfach `git branch --merged` aufrufen:
 
 	$ git branch --merged
 	  iss53
@@ -510,7 +510,7 @@ Die Liste zeigt Dir den anderen Branch. Er enthält Arbeit, die noch nicht gemer
 
 	$ git branch -d testing
 	error: The branch 'testing' is not an ancestor of your current HEAD.
-	If you are sure you want to delete it, run `git branch -D testing`.
+	If you are sure you want to delete it, run 'git branch -D testing'.
 
 <!--If you really do want to delete the branch and lose that work, you can force it with `-D`, as the helpful message points out.-->
 
@@ -722,7 +722,7 @@ Um einen lokalen Branch mit einem anderem Namen als der Remote-Branch, kannst Du
 	Branch sf set up to track remote branch refs/remotes/origin/serverfix.
 	Switched to a new branch "sf"
 
-<!--Now, your local branch sf will automatically push to and pull from origin/serverfix.-->
+<!--Now, your local branch `sf` will automatically push to and pull from `origin/serverfix`.-->
 
 Nun wird Dein lokaler Branch `sf` automatisch push und pull auf `origin/serverfix` durchführen.
 

From 93b3ec5ead4d15f9ce3c6223c81a4d73bee7f4c1 Mon Sep 17 00:00:00 2001
From: Ralph Haussmann <ralph@scanmyfood.de>
Date: Sun, 12 Jan 2014 16:29:56 +0100
Subject: [PATCH 082/690] [de] Chapter 4: Merge original english updates to
 german translation and translate them

---
 de/04-git-server/01-chapter4.markdown | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/de/04-git-server/01-chapter4.markdown b/de/04-git-server/01-chapter4.markdown
index 80b14cd2a..79115b17e 100644
--- a/de/04-git-server/01-chapter4.markdown
+++ b/de/04-git-server/01-chapter4.markdown
@@ -47,9 +47,9 @@ Oder Du kannst das machen:
 
 	$ git clone file:///opt/git/project.git
 
-<!--Git operates slightly differently if you explicitly specify `file://` at the beginning of the URL. If you just specify the path, Git tries to use hardlinks or directly copy the files it needs. If you specify `file://`, Git fires up the processes that it normally uses to transfer data over a network which is generally a lot less efficient method of transferring the data. The main reason to specify the `file://` prefix is if you want a clean copy of the repository with extraneous references or objects left out — generally after an import from another version-control system or something similar (see Chapter 9 for maintenance tasks). We’ll use the normal path here because doing so is almost always faster.-->
+<!--Git operates slightly differently if you explicitly specify `file://` at the beginning of the URL. If you just specify the path, and the source and the destination are on the same filesystem, Git tries to hardlink the objects it needs. If they are not on the same filesystem, it will copy the objects it needs using the system's standard copying functionality. If you specify `file://`, Git fires up the processes that it normally uses to transfer data over a network which is generally a lot less efficient method of transferring the data. The main reason to specify the `file://` prefix is if you want a clean copy of the repository with extraneous references or objects left out — generally after an import from another version-control system or something similar (see Chapter 9 for maintenance tasks). We’ll use the normal path here because doing so is almost always faster.-->
 
-Git arbeitet etwas anders, wenn Du am Anfang der URL ausdrücklich `file://` angibst. Wenn Du nur den Pfad angibst, versucht Git harte Links zu benutzen oder Git kopiert direkt die benötigten Dateien. Wenn Du `file://` angibst, startet Git den Prozess, den es normalerweise zum Übertragen von Daten über ein Netzwerk verwendet, dass ist gewöhnlich eine wesentlich ineffizientere Methode zum Übertragen der Daten. Der Hauptgrund das `file://`-Präfix anzugeben ist eine saubere Kopie von dem Repository mit fremden Referenzen oder fehlenden Objekten – generell nach einem Import von einem anderen Versionskontrollsystem oder etwas ähnliches (siehe Kapitel 9 für Wartungsarbeiten). Wir benutzen hier den normalen Pfad, weil das fast immer schneller ist.
+Git arbeitet etwas anders, wenn Du am Anfang der URL ausdrücklich `file://` angibst. Wenn Du nur den Pfad angibst, und sowohl die Quelle, als auch das Ziel sich auf dem selben Dateisystem befinden, versucht Git harte Links zu benutzen. Wenn sie sich nicht auf dem selben Dateisystem befinden, kopiert Git die benötigten Objekte mit Hilfe der Standardkopierfunktion des jeweiligen Betriebssystems. Wenn Du `file://` angibst, startet Git den Prozess, den es normalerweise zum Übertragen von Daten über ein Netzwerk verwendet, dass ist gewöhnlich eine wesentlich ineffizientere Methode zum Übertragen der Daten. Der Hauptgrund das `file://`-Präfix anzugeben ist eine saubere Kopie von dem Repository mit fremden Referenzen oder fehlenden Objekten – generell nach einem Import von einem anderen Versionskontrollsystem oder etwas ähnliches (siehe Kapitel 9 für Wartungsarbeiten). Wir benutzen hier den normalen Pfad, weil das fast immer schneller ist.
 
 <!--To add a local repository to an existing Git project, you can run something like this:-->
 
@@ -137,7 +137,8 @@ Das Git Protokoll ist das schnellste verfügbare Transfer Protokoll. Wenn Du vie
 <!--#### The Cons ####-->
 #### Die Nachteile ####
 
-<!-- The downside of the Git protocol is the lack of authentication. It’s generally undesirable for the Git protocol to be the only access to your project. Generally, you’ll pair it with SSH access for the few developers who have push (write) access and have everyone else use `git://` for read-only access. It’s also probably the most difficult protocol to set up. It must run its own daemon, which is custom — we’ll look at setting one up in the “Gitosis” section of this chapter — it requires `xinetd` configuration or the like, which isn’t always a walk in the park. It also requires firewall access to port 9418, which isn’t a standard port that corporate firewalls always allow. Behind big corporate firewalls, this obscure port is commonly blocked. -->
+<!--The downside of the Git protocol is the lack of authentication. It’s generally undesirable for the Git protocol to be the only access to your project. Generally, you’ll pair it with SSH access for the few developers who have push (write) access and have everyone else use `git://` for read-only access.-->
+<!--It’s also probably the most difficult protocol to set up. It must run its own daemon, which is custom — we’ll look at setting one up in the “Gitosis” section of this chapter — it requires `xinetd` configuration or the like, which isn’t always a walk in the park. It also requires firewall access to port 9418, which isn’t a standard port that corporate firewalls always allow. Behind big corporate firewalls, this obscure port is commonly blocked.-->
 
 Die Negativseite des Git Protokoll ist das Fehlen der Authentifizierung. Es ist generell unerwünscht, dass das Git Protokoll der einzige Zugang zu dem Projekt ist. Im Allgemeinen willst Du es mit SSH-Zugriff für die Entwickler paaren, die push (Schreib) Zugriff haben und jeder andere benutzt `git://` für Nur-Lese-Zugriff.
 Es ist vielleicht auch das das schwierigste Protokoll beim Einrichten. Es muss ein eigener Dämon laufen, welcher Git-spezifisch ist – wir wollen im „Gitosis“-Abschnitt in diesem Kapitel schauen, wie man einen einrichtet – es setzt eine `xinetd`-Konfiguration oder ähnliches voraus, das ist nicht immer ein Spaziergang. Es setzt auch einen Firewall-Zugriff auf den Port 9418 voraus, das ist kein Standard-Port, den Firmen-Firewalls immer erlauben. Hinter einer großen Firmen-Firewall ist dieser unklare Port häufig gesperrt.

From 5fd6d6110b30ee8bb50ed1adad274dfcd130265a Mon Sep 17 00:00:00 2001
From: Ralph Haussmann <ralph@scanmyfood.de>
Date: Sun, 12 Jan 2014 16:52:54 +0100
Subject: [PATCH 083/690] [de] Chapter 5: Merge original english updates to
 german translation and translate them

---
 de/05-distributed-git/01-chapter5.markdown | 33 +++++++++++++++++++---
 1 file changed, 29 insertions(+), 4 deletions(-)

diff --git a/de/05-distributed-git/01-chapter5.markdown b/de/05-distributed-git/01-chapter5.markdown
index b216da970..d7d2ca314 100644
--- a/de/05-distributed-git/01-chapter5.markdown
+++ b/de/05-distributed-git/01-chapter5.markdown
@@ -330,7 +330,7 @@ Jessica hat die Arbeit in ihrem Topic Branch abgeschlossen, aber sie will wissen
 
 	    removed invalid default value
 
-<!--Now, Jessica can merge her topic work into her master branch, merge John’s work (`origin/master`) into her `master` branch, and then push back to the server again. First, she switches back to her master branch to integrate all this work:-->
+<!--Now, Jessica can merge her topic work into her `master` branch, merge John’s work (`origin/master`) into her `master` branch, and then push back to the server again. First, she switches back to her `master` branch to integrate all this work:-->
 
 Jetzt kann Jessica zunächst ihren Topic Branch `issue54` in ihren `master` Branch mergen, dann Johns Änderungen aus `origin/master` in ihren `master` Branch mergen und schließlich das Resultat auf den `origin` Server pushen. Als erstes wechselt sie zurück auf ihren `master` Branch:
 
@@ -386,7 +386,7 @@ Beide Entwickler haben jetzt einige Male committed und die Arbeit des jeweils an
 Insert 18333fig0510.png
 Bild 5-10. Jessicas Historie nachdem sie sämtliche Änderungen auf den Server gepusht hat
 
-<!--That is one of the simplest workflows. You work for a while, generally in a topic branch, and merge into your master branch when it’s ready to be integrated. When you want to share that work, you merge it into your own master branch, then fetch and merge `origin/master` if it has changed, and finally push to the `master` branch on the server. The general sequence is something like that shown in Figure 5-11.-->
+<!--That is one of the simplest workflows. You work for a while, generally in a topic branch, and merge into your `master` branch when it’s ready to be integrated. When you want to share that work, you merge it into your own `master` branch, then fetch and merge `origin/master` if it has changed, and finally push to the `master` branch on the server. The general sequence is something like that shown in Figure 5-11.-->
 
 Dies ist eine der simpelsten Workflow Varianten. Du arbeitest eine Weile, normalerweise in einem Topic Branch, und mergst in Deinen `master` Branch, wenn Du fertig bist. Wenn Du Deine Änderungen anderen zur Verfügung stellen willst, holst Du den aktuellen `origin/master` Branch, mergst Deinen `master` Branch damit und pushst das ganze zurück auf den `origin` Server. Der Ablauf sieht in etwa wie folgt aus (Bild 5-11).
 
@@ -766,9 +766,34 @@ Zunächst musst Du die IMAP Sektion in Deiner `~/.gitconfig` Datei ausfüllen. D
 	  sslverify = false
 
 <!--If your IMAP server doesn’t use SSL, the last two lines probably aren’t necessary, and the host value will be `imap://` instead of `imaps://`.-->
-<!--When that is set up, you can use `git send-email` to place the patch series in the Drafts folder of the specified IMAP server:-->
+<!--When that is set up, you can use `git imap-send` to place the patch series in the Drafts folder of the specified IMAP server:-->
 
-Wenn Dein IMAP Server kein SSL verwendet, kannst Du die letzten beiden Zeilen wahrscheinlich weglassen und der `host` dürfte mit `imap://` und nicht `imaps://` beginnen. Wenn Du diese Einstellungen konfiguriert hast, kannst Du `git send-email` verwenden, um Deine Patches in den Entwurfsordner des angegebenen IMAP Servers zu kopieren:
+Wenn Dein IMAP Server kein SSL verwendet, kannst Du die letzten beiden Zeilen wahrscheinlich weglassen und der `host` dürfte mit `imap://` und nicht `imaps://` beginnen. Wenn Du diese Einstellungen konfiguriert hast, kannst Du `git imap-send` verwenden, um Deine Patches in den Entwurfsordner des angegebenen IMAP Servers zu kopieren:
+
+	$ cat *.patch |git imap-send
+	Resolving imap.gmail.com... ok
+	Connecting to [74.125.142.109]:993... ok
+	Logging in...
+	sending 2 messages
+	100% (2/2) done
+
+<!--At this point, you should be able to go to your Drafts folder, change the To field to the mailing list you’re sending the patch to, possibly CC the maintainer or person responsible for that section, and send it off.-->
+
+Jetzt kannst Du in Deinen Entwürfe-Ordner wechseln, die Mailingliste an die Du den Patch senden möchtest im An-Feld setzen, vielleicht noch den Maintainer oder die verantwortliche Person in das CC-Feld einfügen und dann das Ganze losschicken.
+
+<!--You can also send the patches through an SMTP server. As before, you can set each value separately with a series of `git config` commands, or you can add them manually in the sendemail section in your `~/.gitconfig` file:-->
+
+Man kann Patches auch über einen SMTP-Server schicken. Wie im letzen Beispiel, kann man auch hier jeden einzelnen Wert mit einer Reihe von `git config` Kommandos setzen. Oder aber Du änderst die Sektion sendemail in Deiner `~/.gitconfig` Datei manuell:
+
+	[sendemail]
+	  smtpencryption = tls
+	  smtpserver = smtp.gmail.com
+	  smtpuser = user@gmail.com
+	  smtpserverport = 587
+
+<!--After this is done, you can use `git send-email` to send your patches:-->
+
+Nach der Änderungen kannst Du mit `git send-email` die Patches abschicken:
 
 	$ git send-email *.patch
 	0001-added-limit-to-log-function.patch

From 0b41150bebc7ca362e51010058d10e034fc41595 Mon Sep 17 00:00:00 2001
From: Ralph Haussmann <ralph@scanmyfood.de>
Date: Sun, 12 Jan 2014 17:18:45 +0100
Subject: [PATCH 084/690] [de] Chapter 6: Merge original english updates to
 german translation

---
 de/06-git-tools/01-chapter6.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/de/06-git-tools/01-chapter6.markdown b/de/06-git-tools/01-chapter6.markdown
index 645938ee0..39e8c219d 100644
--- a/de/06-git-tools/01-chapter6.markdown
+++ b/de/06-git-tools/01-chapter6.markdown
@@ -1322,7 +1322,7 @@ Dann kannst Du diesem Entwickler eine E-Mail schreiben und ihn auf seinen Fehler
 
 In manchen großen Projekten möchten die Entwickler die Arbeit in verschiedenen Verzeichnissen aufteilen, sodass das jeweilige Team in diesen Verzeichnissen arbeiten kann. Man trifft diese Vorgehensweise häufig an, wenn ein Team gerade von CVS oder Subversion nach Git gewechselt hat, im alten System ein Modul oder eine Sammlung von solchen Unterverzeichnissen gebildet hat und diesen Arbeitsablauf weiterhin verwenden möchte.
 
-<!--A good way to do this in Git is to make each of the subfolders a separate Git repository and then create superproject Git repositories that contain multiple submodules. A benefit of this approach is that you can more specifically define the relationships between the projects with tags and branches in the superprojects.-->
+<!--A good way to do this in Git is to make each of the subdirectories a separate Git repository and then create superproject Git repositories that contain multiple submodules. A benefit of this approach is that you can more specifically define the relationships between the projects with tags and branches in the superprojects.-->
 
 In Git kann man diese Vorgehensweise gut abbilden, indem man für jedes Unterverzeichnis ein neues Git Repository erzeugt. Zusätzlich kann man dann ein Superprojekt erzeugen und die ganzen Git Repositorys als Submodul hinzufügen.  Ein Vorteil dabei ist, dass man mit Hilfe von Tags und Branches im Superprojekt das Verhältnis der einzelnen Submodule zueinander festhalten kann.
 

From 6e6e3afd5c72d4727a22938dd809944c047464ac Mon Sep 17 00:00:00 2001
From: Ralph Haussmann <ralph@scanmyfood.de>
Date: Sun, 12 Jan 2014 18:04:22 +0100
Subject: [PATCH 085/690] [de] Chapter 7: Merge original english updates to
 german translation and translate them

---
 de/07-customizing-git/01-chapter7.markdown | 75 +++++++++++-----------
 1 file changed, 39 insertions(+), 36 deletions(-)

diff --git a/de/07-customizing-git/01-chapter7.markdown b/de/07-customizing-git/01-chapter7.markdown
index 74dede055..aefff281d 100644
--- a/de/07-customizing-git/01-chapter7.markdown
+++ b/de/07-customizing-git/01-chapter7.markdown
@@ -115,7 +115,7 @@ Die Einstellung `core.pager` legt fest, welche Anwendung zur Seitenanzeige benut
 
 Wenn Du dies ausführst, wird Git immer die komplette Ausgabe aller Befehle anzeigen, egal wie lange sie ist.
 
-<!--user.signingkey ####-->
+<!--#### user.signingkey ####-->
 #### user.signingkey ####
 
 <!--If you’re making signed annotated tags (as discussed in Chapter 2), setting your GPG signing key as a configuration setting makes things easier. Set your key ID like so:-->
@@ -140,9 +140,9 @@ In Kapitel 2 habe ich bereits beschrieben, wie Du mit Hilfe der projektspezifisc
 <!--#### help.autocorrect ####-->
 #### help.autocorrect ####
 
-<!--This option is available only in Git 1.6.1 and later. If you mistype a command in Git 1.6, it shows you something like this:-->
+<!--This option is available only in Git 1.6.1 and later. If you mistype a command in Git, it shows you something like this:-->
 
-Diese Option ist in Git ab Version 1.6.1 verfügbar. Wenn Du in Git 1.6 einen Befehl falsch schreibst, bekommst Du eine Meldung wie diese:
+Diese Option ist in Git ab Version 1.6.1 verfügbar. Wenn Du in Git einen Befehl falsch schreibst, bekommst Du eine Meldung wie diese:
 
 	$ git com
 	git: 'com' is not a git-command. See 'git --help'.
@@ -170,9 +170,9 @@ Wenn Du Git entsprechend konfigurierst, wird es den Großteil der Ausgaben autom
 
 	$ git config --global color.ui true
 
-<!--When that value is set, Git colors its output if the output goes to a terminal. Other possible settings are false, which never colors the output, and always, which sets colors all the time, even if you’re redirecting Git commands to a file or piping them to another command. This setting was added in Git version 1.5.5; if you have an older version, you’ll have to specify all the color settings individually.-->
+<!--When that value is set, Git colors its output if the output goes to a terminal. Other possible settings are false, which never colors the output, and always, which sets colors all the time, even if you’re redirecting Git commands to a file or piping them to another command.-->
 
-Wenn dieser Wert gesetzt wurde, benutzt Git für seine Ausgaben Farben, sofern diese zu einem Terminal geleitet werden. Weitere mögliche Einstellungen sind ‚false‘, wodurch alle Farben deaktiviert werden, sowie ‚always‘, wodurch Farben immer aktiviert sind, selbst wenn Du Git Befehle in eine Datei oder über eine Pipe zu einem anderen Befehl umleitest. Diese Option wurde in Git 1.5.5 hinzugefügt. Solltest Du eine ältere Git Version benutzen, so musst Du alle Farbeinstellungen einzeln vornehmen.
+Wenn dieser Wert gesetzt wurde, benutzt Git für seine Ausgaben Farben, sofern diese zu einem Terminal geleitet werden. Weitere mögliche Einstellungen sind ‚false‘, wodurch alle Farben deaktiviert werden, sowie ‚always‘, wodurch Farben immer aktiviert sind, selbst wenn Du Git Befehle in eine Datei oder über eine Pipe zu einem anderen Befehl umleitest.
 
 <!--You’ll rarely want `color.ui = always`. In most scenarios, if you want color codes in your redirected output, you can instead pass a `-\-color` flag to the Git command to force it to use color codes. The `color.ui = true` setting is almost always what you’ll want to use.-->
 
@@ -181,9 +181,9 @@ Du wirst selten die Einstellung `color.ui = always` benötigen. In den meisten F
 <!--#### `color.*` ####-->
 #### `color.*` ####
 
-<!--If you want to be more specific about which commands are colored and how, or you have an older version, Git provides verb-specific coloring settings. Each of these can be set to `true`, `false`, or `always`:-->
+<!--If you want to be more specific about which commands are colored and how, Git provides verb-specific coloring settings. Each of these can be set to `true`, `false`, or `always`:-->
 
-Falls Du im Detail einstellen willst, welche Befehle wie gefärbt werden, oder wenn Du eine ältere Version benutzt, dann stellt Git Verb-spezifische Farbeinstellungen zur Verfügung. Jede dieser Optionen kann auf `true`, `false`, oder `always` eingestellt werden:
+Falls Du im Detail einstellen willst, welche Befehle wie gefärbt werden, dann stellt Git Verb-spezifische Farbeinstellungen zur Verfügung. Jede dieser Optionen kann auf `true`, `false`, oder `always` eingestellt werden:
 
 	color.branch
 	color.diff
@@ -468,25 +468,33 @@ Um Git anzuweisen alle `pbxproj` Dateien als Binärdateien zu behandeln, kannst
 
 	*.pbxproj -crlf -diff
 
-<!--Now, Git won’t try to convert or fix CRLF issues; nor will it try to compute or print a diff for changes in this file when you run git show or git diff on your project. In the 1.6 series of Git, you can also use a macro that is provided that means `-crlf -diff`:-->
+<!--Now, Git won’t try to convert or fix CRLF issues; nor will it try to compute or print a diff for changes in this file when you run `git show` or `git diff` on your project. You can also use a built-in macro `binary` that means `-crlf -diff`:-->
 
-Ab jetzt wird Git nicht mehr versuchen CRLF Probleme zu lösen oder die Datei beim Commit oder Checkout zu ändern. Außerdem ermittelt Git keine Dateiunterschiede mehr und gibt diese auch nicht aus, wenn Du den Befehl ‚git show‘ oder ‚git diff‘ ausführst. Ab der Git Version 1.6 steht Dir auch ein Makro zur Verfügung, welches den Parametern `-crlf -diff` entspricht:
+Ab jetzt wird Git nicht mehr versuchen CRLF Probleme zu lösen oder die Datei beim Commit oder Checkout zu ändern. Außerdem ermittelt Git keine Dateiunterschiede mehr und gibt diese auch nicht aus, wenn Du den Befehl `git show` oder `git diff` ausführst. Alternativ gibt es auch ein integriertes Makro `binary`, welches den Parametern `-crlf -diff` entspricht:
 
 	*.pbxproj binary
 
 <!--#### Diffing Binary Files ####-->
 #### Diff bei Binärdateien ####
 
-<!--In the 1.6 series of Git, you can use the Git attributes functionality to effectively diff binary files. You do this by telling Git how to convert your binary data to a text format that can be compared via the normal diff.-->
+<!--In Git, you can use the attributes functionality to effectively diff binary files. You do this by telling Git how to convert your binary data to a text format that can be compared via the normal diff. But the question is how do you convert *binary* data to a text? The best solution is to find some tool that does conversion for your binary format to a text representation. Unfortunately, very few binary formats can be represented as human readable text (imagine trying to convert audio data to a text). If this is the case and you failed to get a text presentation of your file's contents, it's often relatively easy to get a human readable description of that content, or metadata. Metadata won't give you a full representation of your file's content, but in any case it's better than nothing.-->
 
-Mit Hilfe der Git Attribute können seit der Version 1.6, Unterschiede in binären Dateien effektiv und leicht angezeigt werden. Du kannst Git so konfigurieren, dass es automatisch Binärdateien in Textdateien umwandelt, damit sie mit einem normalen Diff verglichen werden können.
+Mit Hilfe der Git Attribute können Unterschiede in binären Dateien effektiv und leicht angezeigt werden. Du kannst Git so konfigurieren, dass es automatisch Binärdateien in Textdateien umwandelt, damit sie mit einem normalen Diff verglichen werden können. Meist stellt sich aber die Frage, wie man binäre Daten in Text konvertieren soll. Wenn man ein Werkzeug findet, welches einem diese Konvertierung abnimmt und die binäre Daten in ein Textformat umwandelt, ist dies meist die beste Lösung. Leider gibt es nur sehr wenige binäre Formate, die sich dafür eignen, dass man sie in lesbare Textformate umwandelt (Ich denke dabei zum Beispiel an Audio-Daten). Wenn dies der Fall ist und Du keine geeignete Möglichkeit gefunden hast, die Daten in lesbare Form zu wandeln, dann ist es oft relativ einfach eine entsprechende Beschreibung des eigentlichen Inhalts zu erhalten. Alternativ gibt es noch Metadaten, wobei Metadaten einem nicht ein vollständiges Abbild vom Dateiinhalt liefern können, aber in diesem Fall ist das besser als gar nichts.
+
+<!--We'll make use of the both described approaches to get usable diffs for some widely used binary formats.-->
+
+Im folgenden Abschnitt werden wir beide Möglichkeiten besprechen, wie man für weit verbreitete binäre Formate eine lesbare Form für einen Vergleich erhält.
+
+<!--Side note: There are different kinds of binary formats with a text content, which are hard to find usable converter for. In such a case you could try to extract a text from your file with the `strings` program. Some of these files may use an UTF-16 encoding or other "codepages" and `strings` won’t find anything useful in there. Your mileage may vary. However, `strings` is available on most Mac and Linux systems, so it may be a good first try to do this with many binary formats.-->
+
+Anmerkung: Es gibt verschiedene Arten von binären Formaten, welche Text beinhalten, und es ist meist sehr schwierig einen passenden Konverter zu finden. In solchen Fällen kann man sein Glück mit dem `strings`-Programm versuchen. Manche der Formate verwenden ein UTF-16 Encoding oder andere Zeichentabellen. In diesem Fall wird es mit dem Programm `strings` meist nicht funktionieren. Da `strings` jedoch auf den meisten Mac- und Linux-Systemen verfügbar ist, sollte man es durchaus auf einen Versuch ankommen lassen.
 
 <!--##### MS Word files #####-->
 ##### MS Word files #####
 
-<!--Because this is a pretty cool and not widely known feature, I’ll go over a few examples. First, you’ll use this technique to solve one of the most annoying problems known to humanity: version-controlling Word documents. Everyone knows that Word is the most horrific editor around; but, oddly, everyone uses it. If you want to version-control Word documents, you can stick them in a Git repository and commit every once in a while; but what good does that do? If you run `git diff` normally, you only see something like this:-->
+<!--First, you’ll use the described technique to solve one of the most annoying problems known to humanity: version-controlling Word documents. Everyone knows that Word is the most horrific editor around; but, oddly, everyone uses it. If you want to version-control Word documents, you can stick them in a Git repository and commit every once in a while; but what good does that do? If you run `git diff` normally, you only see something like this:-->
 
-Da das eine ziemlich praktische, aber nicht sehr bekannt Funktionalität ist, werde ich einige Beispiele besprechen. Als erstes werden wir diese Technik benutzen um eines der lästigsten Probleme der Menschheit zu lösen: Versionskontrolle von Word Dokumenten. Jeder weiß, dass Word der schrecklichste Editor der Welt ist, aber trotzdem benutzt ihn jeder. Wenn Du Word Dokumente versionieren willst, kannst Du sie in Dein Repository packen und ab und zu einen Commit durchführen. Aber wozu ist das nützlich? Wenn Du einen Vergleich mit `git diff` ausführst, erhälst Du ähnliche Ausgabe wie diese:
+Als erstes werden wir die beschriebene Technik benutzen um eines der lästigsten Probleme der Menschheit zu lösen: Versionskontrolle von Word Dokumenten. Jeder weiß, dass Word der schrecklichste Editor der Welt ist, aber trotzdem benutzt ihn jeder. Wenn Du Word Dokumente versionieren willst, kannst Du sie in Dein Repository packen und ab und zu einen Commit durchführen. Aber wozu ist das nützlich? Wenn Du einen Vergleich mit `git diff` ausführst, erhälst Du ähnliche Ausgabe wie diese:
 
 	$ git diff
 	diff --git a/chapter1.doc b/chapter1.doc
@@ -499,26 +507,22 @@ Du kannst zwei Versionen nicht direkt vergleichen, außer Du checkst sie aus und
 
 	*.doc diff=word
 
-<!--This tells Git that any file that matches this pattern (.doc) should use the "word" filter when you try to view a diff that contains changes. What is the "word" filter? You have to set it up. Here you’ll configure Git to use the `strings` program to convert Word documents into readable text files, which it will then diff properly:-->
+<!--This tells Git that any file that matches this pattern (.doc) should use the "word" filter when you try to view a diff that contains changes. What is the "word" filter? You have to set it up. Here you’ll configure Git to use the `catdoc` program, which was written specifically for extracting text from a binary MS Word documents (you can get it from `http://www.wagner.pp.ru/~vitus/software/catdoc/`), to convert Word documents into readable text files, which it will then diff properly:-->
 
-Dies weist Git an, dass auf jede Datei, die diesem Dateimuster (.doc) entspricht, der „word“ Filter angewandt werden soll, wenn Du versuchst, einen Diff mit Dateiunterschieden anzusehen. Was ist nun der „word“ Filter? Dieser muss von Dir noch konfiguriert werden. Du kannst Git so konfigurieren, dass es das `strings` Programm verwendet um Word Dokumente in lesbare Textdateien zu konvertieren. Bei jedem Diff wird Git diese Konvertierung durchführen:
+Dies weist Git an, dass auf jede Datei, die diesem Dateimuster (.doc) entspricht, der „word“ Filter angewandt werden soll, wenn Du versuchst, einen Diff mit Dateiunterschieden anzusehen. Was ist nun der „word“ Filter? Dieser muss von Dir noch konfiguriert werden. Du kannst Git so konfigurieren, dass es das `catdoc` Programm verwendet um Word Dokumente in lesbare Textdateien zu konvertieren. `catdoc` wurde speziell dafür entwickelt um lesbaren Text aus binären MS Word Dokumenten zu extrahieren (du erhälst es unter `http://www.wagner.pp.ru/~vitus/software/catdoc/`).   Bei jedem Diff wird Git diese Konvertierung durchführen:
 
-	$ git config diff.word.textconv strings
+	$ git config diff.word.textconv catdoc
 
 <!--This command adds a section to your `.git/config` that looks like this:-->
 
 Dieser Befehl fügt in der Datei `.git/config` eine Sektion mit folgendem Aufbau hinzu:
 
 	[diff "word"]
-		textconv = strings
-
-<!--Side note: There are different kinds of `.doc` files. Some use an UTF-16 encoding or other "codepages" and `strings` won’t find anything useful in there. Your mileage may vary.-->
-
-Anmerkung: Es gibt verschiedene Arten von `.doc` Dateien. Manche verwenden UTF-16 Kodierung oder andere Zeichensätze. Das führt dazu, dass `strings` nichts verwertbares findet. Probier Dein Glück.
+		textconv = catdoc
 
-<!--Now Git knows that if it tries to do a diff between two snapshots, and any of the files end in `.doc`, it should run those files through the "word" filter, which is defined as the `strings` program. This effectively makes nice text-based versions of your Word files before attempting to diff them.-->
+<!--Now Git knows that if it tries to do a diff between two snapshots, and any of the files end in `.doc`, it should run those files through the "word" filter, which is defined as the `catdoc` program. This effectively makes nice text-based versions of your Word files before attempting to diff them.-->
 
-Bei jedem Vergleich von zwei Schnappschüssen wird Git Dateien mit der Dateiendung `.doc` durch den „word“ Filter jagen, welcher durch das `strings` Programm definiert ist. Das erzeugt gut lesbare Textversionen Deiner Word Dateien, die für den Vergleich herangezogen werden.
+Bei jedem Vergleich von zwei Schnappschüssen wird Git Dateien mit der Dateiendung `.doc` durch den „word“ Filter jagen, welcher durch das `catdoc` Programm definiert ist. Das erzeugt gut lesbare Textversionen Deiner Word Dateien, die für den Vergleich herangezogen werden.
 
 <!--Here’s an example. I put Chapter 1 of this book into Git, added some text to a paragraph, and saved the document. Then, I ran `git diff` to see what changed:-->
 
@@ -529,17 +533,16 @@ Dazu ein Beispiel. Ich habe Kapitel 1 des Buches in ein Word-Dokument einfgefüg
 	index c1c8a0a..b93c9e4 100644
 	--- a/chapter1.doc
 	+++ b/chapter1.doc
-	@@ -8,7 +8,8 @@ re going to cover Version Control Systems (VCS) and Git basics
-	 re going to cover how to get it and set it up for the first time if you don
-	 t already have it on your system.
-	 In Chapter Two we will go over basic Git usage - how to use Git for the 80%
-	-s going on, modify stuff and contribute changes. If the book spontaneously
-	+s going on, modify stuff and contribute changes. If the book spontaneously
-	+Let's see if this works.
+	@@ -128,7 +128,7 @@ and data size)
+	 Since its birth in 2005, Git has evolved and matured to be easy to use
+	 and yet retain these initial qualities. It’s incredibly fast, it’s
+	 very efficient with large projects, and it has an incredible branching
+	-system for non-linear development.
+	+system for non-linear development (See Chapter 3).
 
-<!--Git successfully and succinctly tells me that I added the string "Let’s see if this works", which is correct. It’s not perfect — it adds a bunch of random stuff at the end — but it certainly works. If you can find or write a Word-to-plain-text converter that works well enough, that solution will likely be incredibly effective. However, `strings` is available on most Mac and Linux systems, so it may be a good first try to do this with many binary formats.-->
+<!--Git successfully and succinctly tells me that I added the string "(See Chapter 3)", which is correct. Works perfectly!-->
 
-Git war erfolgreich und zeigt nun kurz und bündig an, dass ich den Text „Let's see if this works“ hinzugefügt habe, was korrekt ist. Es ist nicht perfekt, es wird etwas zufälliger Kram am Ende angefügt — aber es funktioniert. Falls Du einen guten Word-nach-Text Konverter findest oder schreibst, dann ist diese Lösung wahrscheinlich äußerst effektiv. Für den Anfang sollte `strings` für die meisten Binärformate jedoch ausreichen, vor allem da es für die meisten Mac und Linux Systeme verfügbar ist.
+Git war erfolgreich und zeigt nun kurz und bündig an, dass ich den Text „(See Chapter 3)“ hinzugefügt habe, was korrekt ist. Wie du siehst, funktioniert perfekt.
 
 <!--##### OpenDocument Text files #####-->
 ##### OpenDocument Textdateien #####
@@ -815,9 +818,9 @@ Genau wie bei vielen anderen Versionskontrollsystemen gibt es auch bei Git die M
 <!--### Installing a Hook ###-->
 ### Installieren eines Hooks ###
 
-<!--The hooks are all stored in the `hooks` subdirectory of the Git directory. In most projects, that’s `.git/hooks`. By default, Git populates this directory with a bunch of example scripts, many of which are useful by themselves; but they also document the input values of each script. All the examples are written as shell scripts, with some Perl thrown in, but any properly named executable scripts will work fine — you can write them in Ruby or Python or what have you. For post-1.6 versions of Git, these example hook files end with .sample; you’ll need to rename them. For pre-1.6 versions of Git, the example files are named properly but are not executable.-->
+<!--The hooks are all stored in the `hooks` subdirectory of the Git directory. In most projects, that’s `.git/hooks`. By default, Git populates this directory with a bunch of example scripts, many of which are useful by themselves; but they also document the input values of each script. All the examples are written as shell scripts, with some Perl thrown in, but any properly named executable scripts will work fine — you can write them in Ruby or Python or what have you. These example hook files end with .sample; you’ll need to rename them.-->
 
-Sämtliche Hooks werden im `hooks` Unterverzeichnis des Git Verzeichnisses gespeichert. In den meisten Projekten wird das `.git/hooks` sein. Git installiert in dieses Verzeichnis standardmäßig Beispielskripte. Einige davon sind auch ohne Änderung nützlich und sofort einsetzbar. Zusätzlich dokumentieren diese Beispiele die Eingabewerte des jeweiligen Skripts. Alle Beispiele sind Shellskripte, die hier und da ein Paar Zeilen Perl Code enthalten. Prinzipiell sollte aber jedes ausführbare Skript funktionieren, wenn es korrekt benannt wird. Du kannst also die Skriptsprache Deiner Wahl verwenden, z.B. Ruby oder Python. Ab Version 1.6 haben die Beispieldateien die Endung .sample, sie müssen also noch umbenannt werden. In älteren Versionen sind die Beispieldateien korrekt benannt, aber dafür nicht ausführbar.
+Sämtliche Hooks werden im `hooks` Unterverzeichnis des Git Verzeichnisses gespeichert. In den meisten Projekten wird das `.git/hooks` sein. Git installiert in dieses Verzeichnis standardmäßig Beispielskripte. Einige davon sind auch ohne Änderung nützlich und sofort einsetzbar. Zusätzlich dokumentieren diese Beispiele die Eingabewerte des jeweiligen Skripts. Alle Beispiele sind Shellskripte, die hier und da ein Paar Zeilen Perl Code enthalten. Prinzipiell sollte aber jedes ausführbare Skript funktionieren, wenn es korrekt benannt wird. Du kannst also die Skriptsprache Deiner Wahl verwenden, z.B. Ruby oder Python. Die Beispieldateien haben die Endung .sample, sie müssen also nur noch umbenannt werden.
 
 <!--To enable a hook script, put a file in the `hooks` subdirectory of your Git directory that is named appropriately and is executable. From that point forward, it should be called. I’ll cover most of the major hook filenames here.-->
 
@@ -1114,9 +1117,9 @@ Ab jetzt haben alle Benutzer nur für die jeweils freigegebenen Verzeichnisse Zu
 <!--#### Enforcing Fast-Forward-Only Pushes ####-->
 #### Verweigern von Pushes, welche nicht einem Fast-Forward entsprechen ####
 
-<!--The only thing left is to enforce fast-forward-only pushes. In Git versions 1.6 or newer, you can set the `receive.denyDeletes` and `receive.denyNonFastForwards` settings. But enforcing this with a hook will work in older versions of Git, and you can modify it to do so only for certain users or whatever else you come up with later.-->
+<!--The only thing left is to enforce fast-forward-only pushes. To do so, you can simply set the `receive.denyDeletes` and `receive.denyNonFastForwards` settings. But enforcing this with a hook will also work, and you can modify it to do so only for certain users or whatever else you come up with later.-->
 
-Nun müssen wir unser System nur noch so einrichten, dass es nur Fast-Forward Push-Operationen zulässt. Ab der Version 1.6 von Git kann man dazu die `receive.denyDeletes` und `receive.denyNonFastForwards` Konfigurationsparameter verwenden. In älteren Versionen benötigt man dafür einen Hook und man kann diesen dann so konfigurieren, dass die Regeln nur für bestimmte Benutzer gelten.
+Nun müssen wir unser System nur noch so einrichten, dass es nur Fast-Forward Push-Operationen zulässt. Man verwendet dafür die `receive.denyDeletes` und `receive.denyNonFastForwards` Konfigurationsparameter. Das gleiche Ergebnis kann man aber auch über einen Hook erreichen und diesen kann man dann so konfigurieren, dass die Regeln nur für bestimmte Benutzer gelten.
 
 <!--The logic for checking this is to see if any commits are reachable from the older revision that aren’t reachable from the newer one. If there are none, then it was a fast-forward push; otherwise, you deny it:-->
 

From fb48cbc8bf061c75a5619dd4fe47a68dff1df3ba Mon Sep 17 00:00:00 2001
From: Ralph Haussmann <ralph@scanmyfood.de>
Date: Sun, 12 Jan 2014 18:07:37 +0100
Subject: [PATCH 086/690] [de] Chapter 8: Merge original english updates to
 german translation

---
 de/08-git-and-other-scms/01-chapter8.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/de/08-git-and-other-scms/01-chapter8.markdown b/de/08-git-and-other-scms/01-chapter8.markdown
index 4ae40993d..19d5fc35b 100644
--- a/de/08-git-and-other-scms/01-chapter8.markdown
+++ b/de/08-git-and-other-scms/01-chapter8.markdown
@@ -517,7 +517,7 @@ Dies erzeugt Dir die Log-Ausgabe im XML-Format — Du suchst damit nach den Auto
 
 Du kannst diese Datei dann `git svn` zur Verfügung stellen um das Tool dabei zu unterstützen, die Autoreninformationen besser zu mappen. Du kannst `git svn` ebenfalls mitteilen, dass es die Metadaten nicht einbeziehen soll, die Subversion normalerweise importiert, indem Du dem `clone` oder `init` Kommando die `--no-metadata`-Option mitgibst.
 
-	$ git-svn clone http://my-project.googlecode.com/svn/ \
+	$ git svn clone http://my-project.googlecode.com/svn/ \
 	      --authors-file=users.txt --no-metadata -s my_project
 
 <!--Now you should have a nicer Subversion import in your `my_project` directory. Instead of commits that look like this-->

From df1522a5f08dc0bda0e0d9178f55bbbf6e949e48 Mon Sep 17 00:00:00 2001
From: Ralph Haussmann <ralph@scanmyfood.de>
Date: Sun, 12 Jan 2014 18:11:03 +0100
Subject: [PATCH 087/690] [de] Chapter 9: Merge original english updates to
 german translation

---
 de/09-git-internals/01-chapter9.markdown | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/de/09-git-internals/01-chapter9.markdown b/de/09-git-internals/01-chapter9.markdown
index 2b3f3ad99..dbbaa1196 100644
--- a/de/09-git-internals/01-chapter9.markdown
+++ b/de/09-git-internals/01-chapter9.markdown
@@ -618,7 +618,7 @@ Wenn Du Dir den resultierenden Tree anschaust, findest Du den SHA-1 Hash, den di
 
 Jetzt kannst Du mit `git cat-file` sehen, wie groß das Objekt ist:
 
-	$ Du -b .git/objects/9b/c1dc421dcd51b4ac296e3e5b6e2a99cf44391e
+	$ du -b .git/objects/9b/c1dc421dcd51b4ac296e3e5b6e2a99cf44391e
 	4102	.git/objects/9b/c1dc421dcd51b4ac296e3e5b6e2a99cf44391e
 
 <!--Now, modify that file a little, and see what happens:-->
@@ -643,7 +643,7 @@ Wenn Du jetzt den Tree anschaust, der durch den Commit angelegt wurde, findest D
 
 Das Blob ist ein anderes, d.h. obwohl Du lediglich eine einzige Zeile an das Ende einer 400 Zeilen langen Datei angehängt hast, speichert Git den Inhalt jetzt als ein ganz neues Objekt:
 
-	$ Du -b .git/objects/05/408d195263d853f09dca71d55116663690c27c
+	$ du -b .git/objects/05/408d195263d853f09dca71d55116663690c27c
 	4109	.git/objects/05/408d195263d853f09dca71d55116663690c27c
 
 <!--You have two nearly identical 4K objects on your disk. Wouldn’t it be nice if Git could store one of them in full but then the second object only as the delta between it and the first?-->

From aa0ded2cb645b34ca8695c585caee87a8400afc9 Mon Sep 17 00:00:00 2001
From: Broda Noel <brodanoel@gmail.com>
Date: Sun, 12 Jan 2014 15:33:49 -0300
Subject: [PATCH 088/690] Fix broken syntax

---
 es/04-git-server/01-chapter4.markdown | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/es/04-git-server/01-chapter4.markdown b/es/04-git-server/01-chapter4.markdown
index ef8af9cf8..4ddf11685 100755
--- a/es/04-git-server/01-chapter4.markdown
+++ b/es/04-git-server/01-chapter4.markdown
@@ -404,9 +404,8 @@ Y ya estás preparado para trabajar. Si lo has configurado todo correctamente, p
 	fatal: unrecognized command 'gitosis-serve schacon@quaternion'
 	  Connection to gitserver closed.
 
-Indicandote que Gitosis te ha reconocido, pero te está hechando debido a que no estás intentando lanzar ningún comando Git. Por tanto, intentalo con un comando Git real --por ejemplo, clonar el propio repositorio de control de Gitosis 
-
-	a tu ordenador personal-- 
+Indicandote que Gitosis te ha reconocido, pero te está hechando debido a que no estás intentando lanzar ningún comando Git. Por tanto, intentalo con un comando Git real --por ejemplo, clonar el propio repositorio de control de Gitosis a tu ordenador personal-- 
+	
 	$ git clone git@gitserver:gitosis-admin.git
 
 Con ello, tendrás una carpeta denominada 'gitosis-admin', con dos partes principales dentro de ella:

From bafbd267795b9b0d4fd1fde6bb2a1c42196a4519 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Mon, 13 Jan 2014 13:53:14 -0600
Subject: [PATCH 089/690] Reviewed "Distributed Workflow"

---
 it/05-distributed-git/01-chapter5.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/it/05-distributed-git/01-chapter5.markdown b/it/05-distributed-git/01-chapter5.markdown
index ccb4ab1c8..fa7d63d8d 100755
--- a/it/05-distributed-git/01-chapter5.markdown
+++ b/it/05-distributed-git/01-chapter5.markdown
@@ -6,7 +6,7 @@ In questo capitolo, vedremo come lavorare con Git in un ambiente distribuito com
 
 ## Workflows distribuiti ##
 
-A differenza dei gestori di versione centralizzati (CVCS), la natura distribuita di Git ti permette di essere più flessibile nel gestire il modo in cui gli sviluppatori collaborano ai progetti. Nel sistemi centralizzati, ogni sviluppatore è un nodo che lavora appoggiandosi ad un nucleo centrale più o meno ugualmente agli altri. Con Git invece, ogni sviluppatore è potenzialmente sia un nodo che un nucleo - infatti ogni sviluppatore può fornire del codice agli altri repository e mantenere un repository pubblico sul quale gli altri basino il proprio lavoro e verso il quale contribuiscano. Questo apre ad una vasta gamma di possibilità di workflow per il vostro progetto e/o il vostro team. Tratterò quindi alcuni paradigmi che sfruttano questa flessibilità. Discuterò i punti di forza e quelli deboli di ogni design. Potrai usarne uno o combinarli per adattarli alle tue necessità.
+A differenza dei gestori di versione centralizzati (CVCS), la natura distribuita di Git ti permette di essere più flessibile nel gestire il modo in cui gli sviluppatori collaborano ai progetti. Nel sistemi centralizzati ogni sviluppatore è un nodo che lavora appoggiandosi ad un nucleo centrale più o meno ugualmente agli altri. Con Git, invece, ogni sviluppatore è potenzialmente sia un nodo che un nucleo: infatti ogni sviluppatore può contemporaneamente contribuire al codice di altri repository e mantenere un repository pubblico sul quale gli altri basino il proprio lavoro e verso il quale possano contribuire. Questo apre ad una vasta gamma di possibilità di workflow per il tuo progetto e/o il tuo gruppo. Tratterò quindi alcuni paradigmi che sfruttano questa flessibilità. Discuterò i punti di forza e le possibili debolezze di ogni design: potrai usarne uno o combinarli per adattarli alle tue necessità.
 
 ### Workflow centralizzato ###
 

From 87050bbeed2f5ba874904b810a8a5934255ece00 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Mon, 13 Jan 2014 14:03:33 -0600
Subject: [PATCH 090/690] Reviewed "Centralized Workflow"

---
 it/05-distributed-git/01-chapter5.markdown | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/it/05-distributed-git/01-chapter5.markdown b/it/05-distributed-git/01-chapter5.markdown
index fa7d63d8d..27595583c 100755
--- a/it/05-distributed-git/01-chapter5.markdown
+++ b/it/05-distributed-git/01-chapter5.markdown
@@ -10,15 +10,15 @@ A differenza dei gestori di versione centralizzati (CVCS), la natura distribuita
 
 ### Workflow centralizzato ###
 
-Nei sistemi centralizzati, generalmente c'è un modo solo di collaborare. Un fulcro centrale, o repository, può accettare il codice e tutti sincronizzano il lavoro con questo. Un numero di sviluppatori sono nodi - rispetto al fulcro - e restano sincronizzati rispetto ad un luogo centrale (vedi Figura 5-1).
+Nei sistemi centralizzati, generalmente c'è un solo modo per collaborare: il flusso centralizzato. Un nucleo centrale, c.d. repository, può accettare il codice e tutti sincronizzano il proprio lavoro con questo nucleo. Un numero di sviluppatori sono nodi - utenti del nucleo - e restano sincronizzati con questo nucleo centrale (vedi Figura 5-1).
 
 Insert 18333fig0501.png
 Figura 5-1. Worlflow centralizzato
 
-Questo significa che se due sviluppatori clonano dal fulcro ed entrambi fanno dei cambiamenti, il primo sviluppatore che eseguirà un push verso il fulcro non avrà problemi. Il secondo invece, dovrà unire al proprio il lavoro effettuato dal primo, prima di fare un push dei cambiamenti, per non sovrascrivere il lavoro del primo. Questo accade in Git come in Subversion (o un altro CVCS), e funziona tranquillamente in Git.
+Questo significa che se due sviluppatori clonano dal nucleo ed entrambi fanno dei cambiamenti, il primo sviluppatore che trasmetterà le proprie modifiche al nucleo non avrà problemi. Il secondo, invece, dovrà prima unire al proprio lavoro quello del primo e quindi potrà inviare i suoi cambiamenti, per non sovrascrivere il lavoro del primo. Questo accade in Git come in Subversion (o un altro CVCS), e questo modello funziona tranquillamente in Git.
 
-Se hai un piccolo team, o nella tua azienda sono già abituati ad un workflow centralizzato, puoi facilmente continuare ad utilizzare questo metodo con Git. Semplicemente crea un singolo repository, e dai ad ognuno la possibilità di effettuare un push; Git non lascerà agli utenti la possibilità di sovrascriversi l'un l'altro. Se uno sviluppatore clona, esegue dei cambiamenti, e poi prova a fare un push delle proprie modifiche dopo che un altro utente ha cambiato qualcosa, il server si rifiuterà di consentire l'operazione. L'utente sarà avvisato che sta cercando di fare un push di una copia non aggiornata, e non sarà capace di caricare le proprie modifiche finché non le unirà con quelle effettuate dagli altri.
-Questo metodo è utilizzato da tanti dato che è il paradigma che molti conoscono e a cui sono abituati.
+Se hai un piccolo gruppo, o nella tua azienda siete già abituati ad un workflow centralizzato, puoi facilmente continuare ad utilizzare questo metodo con Git. Crea un singolo repository e dai a ognuno del tuo gruppo la possibilità di effettuare una push; Git non lascerà agli utenti la possibilità di sovrascrivere il lavoro di un l'altro. Se uno sviluppatore clona, fa dei cambiamenti, e poi prova a fare una push delle proprie modifiche dopo che un altro utente abbia già inviato le proprie modifiche, il server rifiuterà le modifiche dell'ultimo. Questi sarà avvisato che sta cercando di fare la push di una copia non aggiornata e non potrà caricare le proprie modifiche finché non le unirà con quelle effettuate dagli altri.
+Molti usano questo metodo perché sono abituati a lavorare con questo paradigma.
 
 ### Workflow con manager d'integrazione ###
 

From bc3aeecedadf270a9c270fabbc85c389f6d7fc49 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Mon, 13 Jan 2014 14:12:48 -0600
Subject: [PATCH 091/690] Reviewed "Integration-Manager Workflow"

---
 it/05-distributed-git/01-chapter5.markdown | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/it/05-distributed-git/01-chapter5.markdown b/it/05-distributed-git/01-chapter5.markdown
index 27595583c..9deece6be 100755
--- a/it/05-distributed-git/01-chapter5.markdown
+++ b/it/05-distributed-git/01-chapter5.markdown
@@ -22,19 +22,19 @@ Molti usano questo metodo perché sono abituati a lavorare con questo paradigma.
 
 ### Workflow con manager d'integrazione ###
 
-Dato che Git ti consente di avere multipli repositories, è possibile avere un workflow dove ogni sviluppatore ha accesso in scrittura al proprio pubblico respository, e accesso in lettura a quello degli altri. In questo scenario spesso esiste un repository che rappresenta il progetto "ufficiale". Per contribuire an progetto di questo tipo, devi creare il tuo clone pubblico del progetto e fare un push delle tue modifiche verso il progetto e successivamente chiedere al mantenitore del progetto di fare un pull delle tue modifiche. Questi può aggiungere il tuo repository come remoto, testarlo localmente, unirlo al proprio ramo e fare un push verso il proprio repository. Il processo funziona così (vedi Figura 5-2):
+Poiché Git permette di avere repository multipli, è possibile avere un workflow dove ogni sviluppatore ha accesso in scrittura al proprio respository pubblico e accesso in lettura a quello degli altri. Questo scenario spesso prevede anche un repository classico che rappresenta il progetto "ufficiale". Per contribuire a progetti di questo tipo, devi creare il tuo clone pubblico del progetto e inviarvi (con una push) le tue modifiche e successivamente chiedere al mantenitore del progetto di fare una pull delle stesse. Questi può aggiungere il tuo repository come remoto, testarlo localmente, unirlo al proprio branch e fare una push verso il proprio repository. Il processo funziona così (vedi Figura 5-2):
 
-1.  Il mantenitore del progetto fa un push del proprio repository pubblico.
-2.  Un contributore clona il reposiory ed esegue dei cambiamenti.
-3.  Il contributore fa un push dei propri cambiamenti.
-4.  Il contributore invia al mantenitore una e-mail chiedendo di fare un pull dei cambiamenti.
+1.  Il mantenitore del progetto fa le push sul proprio repository pubblico.
+2.  Un contributore clona il reposiory ed fa delle cambiamenti.
+3.  Il contributore invia le modifiche al suo repository pubblico.
+4.  Il contributore invia al mantenitore una e-mail chiedendo di fare una pull dei cambiamenti.
 5.  Il mantenitore aggiunge il repository del contributore come remoto e fa un merge in locale dei cambiamenti.
-6.  Il mantenitore fa un push dei cambiamenti (compresi quelli aggiunti dal contributore) verso il repository principale.
+6.  Il mantenitore fa una push dei cambiamenti (compresi quelli aggiunti dal contributore) verso il repository principale.
 
 Insert 18333fig0502.png
 Figura 5-2. Workflow con manager d'integrazione
 
-Questo è un workflow comune con siti come GitHub, dove è facile eseguire un fork di un progetto e fare un push dei propri cambiamenti nel proprio fork, in modo che tutti possano accedervi. Uno dei maggiori vantaggi di questo approccio è che puoi continuare il tuo lavoro, ed il mantenitore del repository principale può eseguire un pull dei tuoi cambiamenti in qualsiasi momento. I contributori non devono aspettare che il progetto incorpori i propri camiamenti, ed ognuno può lavorare per conto suo.
+Questo è un workflow comune con siti come GitHub, dove è facile eseguire un fork di un progetto e inviare le tue modifiche al tuo fork, in modo che tutti possano accedervi. Uno dei vantaggi principali di questo approccio è che puoi continuare il tuo lavoro mentre il mantenitore del repository principale può eseguire una pull dei tuoi cambiamenti in qualsiasi momento. I contributori non devono aspettare che il progetto incorpori le modifiche: ognuno può lavorare per conto suo.
 
 ### Workflow con Dittatori e Tenenti ###
 

From 972c6da3bd91a8bee0aeaca619f7c8947d9de937 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Mon, 13 Jan 2014 14:13:34 -0600
Subject: [PATCH 092/690] Reviewed "Dictator and Lieutenants Workflow"

wrong title translation
---
 it/05-distributed-git/01-chapter5.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/it/05-distributed-git/01-chapter5.markdown b/it/05-distributed-git/01-chapter5.markdown
index 9deece6be..e1d5a196e 100755
--- a/it/05-distributed-git/01-chapter5.markdown
+++ b/it/05-distributed-git/01-chapter5.markdown
@@ -36,7 +36,7 @@ Figura 5-2. Workflow con manager d'integrazione
 
 Questo è un workflow comune con siti come GitHub, dove è facile eseguire un fork di un progetto e inviare le tue modifiche al tuo fork, in modo che tutti possano accedervi. Uno dei vantaggi principali di questo approccio è che puoi continuare il tuo lavoro mentre il mantenitore del repository principale può eseguire una pull dei tuoi cambiamenti in qualsiasi momento. I contributori non devono aspettare che il progetto incorpori le modifiche: ognuno può lavorare per conto suo.
 
-### Workflow con Dittatori e Tenenti ###
+### Workflow con Dittatore e Tenenti ###
 
 Questa è una variante del workflow con multipli repository. E' generalmente usata da grandi progetti con centinaia di collaboratori; un esempio famoso è il Kernel Linux. Molti manager d'integrazione sono in carica di certe parti del repository; sono chiamati tenenti. Tutti i tenenti hanno un manager d'integrazione conosciuto come "dittatore benevolo". Il repository del dittatore benevolo funziona come repository di riferimento dal quale tutti i collaboratori eseguono un pull. Il flusso di lavoro è il seguente (vedi Figura 5-3):
 

From 8a4117d3436fe898d71ded2c6b91a9837015569d Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Mon, 13 Jan 2014 14:14:35 -0600
Subject: [PATCH 093/690] typo

---
 it/05-distributed-git/01-chapter5.markdown | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/it/05-distributed-git/01-chapter5.markdown b/it/05-distributed-git/01-chapter5.markdown
index e1d5a196e..187ee22e4 100755
--- a/it/05-distributed-git/01-chapter5.markdown
+++ b/it/05-distributed-git/01-chapter5.markdown
@@ -22,7 +22,7 @@ Molti usano questo metodo perché sono abituati a lavorare con questo paradigma.
 
 ### Workflow con manager d'integrazione ###
 
-Poiché Git permette di avere repository multipli, è possibile avere un workflow dove ogni sviluppatore ha accesso in scrittura al proprio respository pubblico e accesso in lettura a quello degli altri. Questo scenario spesso prevede anche un repository classico che rappresenta il progetto "ufficiale". Per contribuire a progetti di questo tipo, devi creare il tuo clone pubblico del progetto e inviarvi (con una push) le tue modifiche e successivamente chiedere al mantenitore del progetto di fare una pull delle stesse. Questi può aggiungere il tuo repository come remoto, testarlo localmente, unirlo al proprio branch e fare una push verso il proprio repository. Il processo funziona così (vedi Figura 5-2):
+Poiché Git permette di avere repository multipli, è possibile avere un workflow dove ogni sviluppatore ha accesso in scrittura al proprio repository pubblico e accesso in lettura a quello degli altri. Questo scenario spesso prevede anche un repository classico che rappresenta il progetto "ufficiale". Per contribuire a progetti di questo tipo, devi creare il tuo clone pubblico del progetto e inviarvi (con una push) le tue modifiche e successivamente chiedere al mantenitore del progetto di fare una pull delle stesse. Questi può aggiungere il tuo repository come remoto, testarlo localmente, unirlo al proprio branch e fare una push verso il proprio repository. Il processo funziona così (vedi Figura 5-2):
 
 1.  Il mantenitore del progetto fa le push sul proprio repository pubblico.
 2.  Un contributore clona il reposiory ed fa delle cambiamenti.
@@ -38,7 +38,7 @@ Questo è un workflow comune con siti come GitHub, dove è facile eseguire un fo
 
 ### Workflow con Dittatore e Tenenti ###
 
-Questa è una variante del workflow con multipli repository. E' generalmente usata da grandi progetti con centinaia di collaboratori; un esempio famoso è il Kernel Linux. Molti manager d'integrazione sono in carica di certe parti del repository; sono chiamati tenenti. Tutti i tenenti hanno un manager d'integrazione conosciuto come "dittatore benevolo". Il repository del dittatore benevolo funziona come repository di riferimento dal quale tutti i collaboratori eseguono un pull. Il flusso di lavoro è il seguente (vedi Figura 5-3):
+Questa è una variante del workflow con repository multipli. È generalmente usata da grandi progetti con centinaia di collaboratori; un esempio famoso è il Kernel Linux. Molti manager d'integrazione sono in carica di certe parti del repository; sono chiamati tenenti. Tutti i tenenti hanno un manager d'integrazione conosciuto come "dittatore benevolo". Il repository del dittatore benevolo funziona come repository di riferimento dal quale tutti i collaboratori eseguono un pull. Il flusso di lavoro è il seguente (vedi Figura 5-3):
 
 1.  Normali sviluppatori lavorano nel loro ramo ed eseguono un rebase del proprio lavoro sul master. Il ramo master è quello del dittatore.
 2.  I tenenti eseguono l'unione del lavoro degli sviluppatori nel ramo master.

From 28d3d3234ad9430c1a41c9e0beea02c673f1f8e1 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Mon, 13 Jan 2014 14:24:17 -0600
Subject: [PATCH 094/690] Reviewed "Dictator and Lieutenants Workflow"

---
 it/05-distributed-git/01-chapter5.markdown | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/it/05-distributed-git/01-chapter5.markdown b/it/05-distributed-git/01-chapter5.markdown
index 187ee22e4..79c733acf 100755
--- a/it/05-distributed-git/01-chapter5.markdown
+++ b/it/05-distributed-git/01-chapter5.markdown
@@ -38,19 +38,19 @@ Questo è un workflow comune con siti come GitHub, dove è facile eseguire un fo
 
 ### Workflow con Dittatore e Tenenti ###
 
-Questa è una variante del workflow con repository multipli. È generalmente usata da grandi progetti con centinaia di collaboratori; un esempio famoso è il Kernel Linux. Molti manager d'integrazione sono in carica di certe parti del repository; sono chiamati tenenti. Tutti i tenenti hanno un manager d'integrazione conosciuto come "dittatore benevolo". Il repository del dittatore benevolo funziona come repository di riferimento dal quale tutti i collaboratori eseguono un pull. Il flusso di lavoro è il seguente (vedi Figura 5-3):
+Questa è una variante del workflow con repository multipli. Viene generalmente usata da grandi progetti con centinaia di collaboratori: un esempio famoso è il Kernel Linux. Molti manager d'integrazione sono responsabili di certe parti del repository e vengono chiamati tenenti. Tutti i tenenti hanno un manager d'integrazione conosciuto come "dittatore benevolo". Il repository del dittatore benevolo è il repository di riferimento dal quale tutti i collaboratori prendono il codice. Il flusso di lavoro è il seguente (vedi Figura 5-3):
 
-1.  Normali sviluppatori lavorano nel loro ramo ed eseguono un rebase del proprio lavoro sul master. Il ramo master è quello del dittatore.
-2.  I tenenti eseguono l'unione del lavoro degli sviluppatori nel ramo master.
-3.  Il dittatore esegue l'unione dei rami master dei tenenti nel proprio ramo master.
-4.  Il dittatore esegue un push del proprio ramo master nel repository di riferimento, cosicché gli sviluppatori possano accedervi.
+1.  Sviluppatori normali lavorano sul loro branch ed eseguono un `rebase` del proprio lavoro sul master. Il branch master è quello del dittatore.
+2.  I tenenti uniscono il lavoro degli sviluppatori nel proprio branch master.
+3.  Il dittatore esegue l'unione dei branch master dei tenenti nel proprio branch master.
+4.  Il dittatore esegue una push del proprio ramo master nel repository di riferimento, cosicché gli sviluppatori possano accedervi.
 
 Insert 18333fig0503.png
 Figura 5.3. Workflow con dittatore benevolo.
 
-Questo tipo di workflow non è comune ma può essere utile in progetti davvero grandi, o in ambienti con una stretta gerarchia, perché consente al leader del progetto (il dittatore) di delegare molto del lavoro e raccogliere vasti sottoinsiemi di codice in momenti diversi prima di integrarli.
+Questo tipo di workflow non è comune ma può essere utile in progetti molto grandi o in ambienti con una gerarchia forte, perché consente al leader del progetto (il dittatore) di delegare molto del lavoro e raccogliere vasti sottoinsiemi di codice in punti diversi prima di integrarli.
 
-Ci sono alcuni workflow comunemente utilizzati che sono possibili con un sistema distribuito come Git, ma puoi vedere che esistono molte variazioni attuabili per farlo adattare al tuo caso specifico. Ora che hai (spero) determinato quale workflow può funzionare per te, coprirò alcuni specifici esempi su come determinare i ruoli principali per realizzare differenti workflows.
+Ci sono alcuni workflow utilizzati comunemente che sono possibili con un sistema distribuito come Git, ma esistono molte possibili varianti per adattarli al tuo caso specifico. Ora che hai (spero) determinato quale combinazione di workflow possa funzionare per te, illustrerò alcuni esempi sui ruoli principali dei diversi workflow.
 
 ## Contribuire ad un Progetto ##
 

From 62618c1e7d7c9b7da6ac6e04b9c8ff0c477f22c3 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Mon, 13 Jan 2014 14:25:53 -0600
Subject: [PATCH 095/690] Reviewing "Contributing to a Project"

---
 it/05-distributed-git/01-chapter5.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/it/05-distributed-git/01-chapter5.markdown b/it/05-distributed-git/01-chapter5.markdown
index 79c733acf..d66cb073a 100755
--- a/it/05-distributed-git/01-chapter5.markdown
+++ b/it/05-distributed-git/01-chapter5.markdown
@@ -54,7 +54,7 @@ Ci sono alcuni workflow utilizzati comunemente che sono possibili con un sistema
 
 ## Contribuire ad un Progetto ##
 
-Sai quali sono i diversi worlflows, e dovresti avere chiari i fondamentali utilizzi di Git. In questa sezione, parleremo di alcuni metodi comuni per contribuire ad un progetto.
+Conosci i diversi worlflow e dovresti aver chiaro i fondamentali di Git. In questa sezione imparerai alcuni metodi comuni per contribuire a un progetto.
 
 La difficoltà maggiore nel descrivere questo processo, è che ci sono molte variazioni su come può venir fatto. Data la natura flessibile di Git, la gente può lavorare insieme in molti modi, ed è difficile descrivere come dovresti contribuire ad un progetto - ogni progetto è diverso. Alcune delle variabili coinvolte sono la quantità di contributori attivi, il workflow deciso, il tuo tipo di accesso per commit, ed eventualmente il metodo di contribuzione esterno.
 

From 73ee4ebab91efddda6369299165d37ecbf722fbb Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Mon, 13 Jan 2014 14:28:01 -0600
Subject: [PATCH 096/690] Reviewing "Contributing to a Project"

---
 it/05-distributed-git/01-chapter5.markdown | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/it/05-distributed-git/01-chapter5.markdown b/it/05-distributed-git/01-chapter5.markdown
index d66cb073a..3a05919c2 100755
--- a/it/05-distributed-git/01-chapter5.markdown
+++ b/it/05-distributed-git/01-chapter5.markdown
@@ -54,9 +54,9 @@ Ci sono alcuni workflow utilizzati comunemente che sono possibili con un sistema
 
 ## Contribuire ad un Progetto ##
 
-Conosci i diversi worlflow e dovresti aver chiaro i fondamentali di Git. In questa sezione imparerai alcuni metodi comuni per contribuire a un progetto.
+Conosci i diversi workflow e dovresti aver chiaro i fondamentali di Git. In questa sezione imparerai alcuni metodi comuni per contribuire a un progetto.
 
-La difficoltà maggiore nel descrivere questo processo, è che ci sono molte variazioni su come può venir fatto. Data la natura flessibile di Git, la gente può lavorare insieme in molti modi, ed è difficile descrivere come dovresti contribuire ad un progetto - ogni progetto è diverso. Alcune delle variabili coinvolte sono la quantità di contributori attivi, il workflow deciso, il tuo tipo di accesso per commit, ed eventualmente il metodo di contribuzione esterno.
+La difficoltà maggiore nel descrivere questo processo è che ci sono molte variazioni su come può venir fatto. Poiché Git è molto flessibile la gente può lavorare insieme in molti modi (ed effettivamente lo fa), ed è difficile descrivere come dovresti contribuire ad un progetto: ogni progetto è diverso. Alcune delle variabili coinvolte sono la quantità di contributori attivi, il workflow adottato, il tuo tipo di accesso, ed eventualmente il metodo di contribuzione esterno.
 
 La prima variabile è il numero di contributori attivi. Quando utenti attivamente contribuiscono con del codice a questo progetto, e quanto spesso? In molte situazioni avrai una manciata di sviluppatori con alcuni commits al giorno, o forse meno per dei progetti meno attivi. Per azienda o progetti davvero grandi, il numero di sviluppatori potrebbe essere nell'ordine delle migliaia, con dozzine o addirittura di centinaia di patches in arrivo ogni giorno. Questo è importante perché con più sviluppatori vai incontro a più problemi nell'applicare le modifiche in maniera pulita. I cambiamenti che fai potrebbero essere stati resi obsoleti o corrotti da altri che sono stati uniti mentre aspettavi che il tuo lavoro venisse approvato a applicato. Come si può tenere il proprio codice aggiornato e le proprie modifiche valide?
 

From 1315be1a0ea5c6d48c8acb271cae48b29d593791 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Mon, 13 Jan 2014 14:33:22 -0600
Subject: [PATCH 097/690] Reviewing "Contributing to a Project"

---
 it/05-distributed-git/01-chapter5.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/it/05-distributed-git/01-chapter5.markdown b/it/05-distributed-git/01-chapter5.markdown
index 3a05919c2..106a26f0f 100755
--- a/it/05-distributed-git/01-chapter5.markdown
+++ b/it/05-distributed-git/01-chapter5.markdown
@@ -58,7 +58,7 @@ Conosci i diversi workflow e dovresti aver chiaro i fondamentali di Git. In ques
 
 La difficoltà maggiore nel descrivere questo processo è che ci sono molte variazioni su come può venir fatto. Poiché Git è molto flessibile la gente può lavorare insieme in molti modi (ed effettivamente lo fa), ed è difficile descrivere come dovresti contribuire ad un progetto: ogni progetto è diverso. Alcune delle variabili coinvolte sono la quantità di contributori attivi, il workflow adottato, il tuo tipo di accesso, ed eventualmente il metodo di contribuzione esterno.
 
-La prima variabile è il numero di contributori attivi. Quando utenti attivamente contribuiscono con del codice a questo progetto, e quanto spesso? In molte situazioni avrai una manciata di sviluppatori con alcuni commits al giorno, o forse meno per dei progetti meno attivi. Per azienda o progetti davvero grandi, il numero di sviluppatori potrebbe essere nell'ordine delle migliaia, con dozzine o addirittura di centinaia di patches in arrivo ogni giorno. Questo è importante perché con più sviluppatori vai incontro a più problemi nell'applicare le modifiche in maniera pulita. I cambiamenti che fai potrebbero essere stati resi obsoleti o corrotti da altri che sono stati uniti mentre aspettavi che il tuo lavoro venisse approvato a applicato. Come si può tenere il proprio codice aggiornato e le proprie modifiche valide?
+La prima variabile è il numero di contributori attivi. Quando utenti  contribuiscono attivamente al progetto con del codice e quanto spesso? In molte casi avrai due o tre sviluppatori con poche commit quotidiane, o anche meno per dei progetti semi dormienti. Per azienda o progetti molto grandi, il numero di sviluppatori potrebbe essere nell'ordine delle migliaia, con dozzine o addirittura di centinaia di patches rilasciate ogni giorno. Questa è importante perché con più sviluppatori vai incontro a molti problemi nell'applicare le modifiche in maniera pulita o che queste possano essere facilmente integrate. I cambiamenti che fai potrebbero essere stati resi obsoleti o corrotti da altri che sono stati integrati mentre lavoravi o mentre aspettavi che il tuo lavoro venisse approvato o applicato. Come puoi mantenere il tuo codice aggiornato e le tue modifiche valide?
 
 La prossima variabile è il workflow in uso nel progetto. E' centralizzato, con ogni sviluppatore avente lo stesso tipo di accesso in scrittura nel repository principale? Il progetto ha un manager d'integrazione che controlla tutte le modifiche? Tutte le modifiche sono riviste da più persone ed approvate? Sei coinvolto in questo processo? E' un sistema con dei tenenti, e devi fornire a loro il tuo lavoro innanzitutto?
 

From 4bffe04dc02314e7149e497307d9f45899b8948f Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Mon, 13 Jan 2014 14:45:08 -0600
Subject: [PATCH 098/690] Reviewed "Contributing to a Project"

---
 it/05-distributed-git/01-chapter5.markdown | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/it/05-distributed-git/01-chapter5.markdown b/it/05-distributed-git/01-chapter5.markdown
index 106a26f0f..7ee8bbd16 100755
--- a/it/05-distributed-git/01-chapter5.markdown
+++ b/it/05-distributed-git/01-chapter5.markdown
@@ -60,11 +60,11 @@ La difficoltà maggiore nel descrivere questo processo è che ci sono molte vari
 
 La prima variabile è il numero di contributori attivi. Quando utenti  contribuiscono attivamente al progetto con del codice e quanto spesso? In molte casi avrai due o tre sviluppatori con poche commit quotidiane, o anche meno per dei progetti semi dormienti. Per azienda o progetti molto grandi, il numero di sviluppatori potrebbe essere nell'ordine delle migliaia, con dozzine o addirittura di centinaia di patches rilasciate ogni giorno. Questa è importante perché con più sviluppatori vai incontro a molti problemi nell'applicare le modifiche in maniera pulita o che queste possano essere facilmente integrate. I cambiamenti che fai potrebbero essere stati resi obsoleti o corrotti da altri che sono stati integrati mentre lavoravi o mentre aspettavi che il tuo lavoro venisse approvato o applicato. Come puoi mantenere il tuo codice aggiornato e le tue modifiche valide?
 
-La prossima variabile è il workflow in uso nel progetto. E' centralizzato, con ogni sviluppatore avente lo stesso tipo di accesso in scrittura nel repository principale? Il progetto ha un manager d'integrazione che controlla tutte le modifiche? Tutte le modifiche sono riviste da più persone ed approvate? Sei coinvolto in questo processo? E' un sistema con dei tenenti, e devi fornire a loro il tuo lavoro innanzitutto?
+La variabile successiva è il workflow usato nel progetto. È centralizzato, con ogni sviluppatore con lo stesso tipo di accesso in scrittura sul repository principale? Il progetto ha un manager d'integrazione che controlla tutte le modifiche? Tutte le modifiche sono riviste da più persone ed approvate? Sei coinvolto in questo processo? È un sistema con dei tenenti, e devi inviare a loro il tuo lavoro?
 
-Il problema successivo è il tuo accesso per il commit. Il workflow richiesto per poter contribuire al progetto è molto diverso a seconda del fatto che tua abbia accesso in scrittura o no. Se non hai accesso in scrittura, come viene preferito il lavoro dei contributori? Esiste qualche regola a riguardo? Quando contribuisci per volta? Quanto spesso?
+Il problema successivo riguarda i tuoi permessi per effettuare commit. Il workflow richiesto per poter contribuire al progetto è molto diverso a seconda del fatto che tua abbia accesso in scrittura o solo lettura. Se non hai accesso in scrittura, qual'è il modo preferito dal progetto per accettare il lavoro dei contributori? Esistono regole a riguardo? Quanto contribuisci? Quanto spesso?
 
-Tutte queste domande possono influire effettivamente sul progetto e sul tipo di workflow preferibile per la tua situazione. Coprirò aspetti di ognuno di questi in una serie di casi d'uso, spaziando dal semplice al complesso; dovresti essere capace di ricostruire il workflow specifico per il tuo caso basandoti sugli esempi.
+Tutte queste domande possono influire sul modo in cui contribuisci al progetto e quale tipo di workflow sia quello preferito o disponibile. Illustrerò gli aspetti di ciascuno di questi in una serie di casi d'uso, dal più semplice al più complesso: dovresti essere capace di definire il workflow specifico per il tuo caso basandoti su questi esempi.
 
 ### Linee guida per il commit ###
 

From d578f0fa9c42ec1f7afc23764c52b1dc812a9cc5 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Mon, 13 Jan 2014 14:46:22 -0600
Subject: [PATCH 099/690] Reviewing "Commit Guidelines"
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

commit è femminile
---
 it/05-distributed-git/01-chapter5.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/it/05-distributed-git/01-chapter5.markdown b/it/05-distributed-git/01-chapter5.markdown
index 7ee8bbd16..c2272898f 100755
--- a/it/05-distributed-git/01-chapter5.markdown
+++ b/it/05-distributed-git/01-chapter5.markdown
@@ -66,7 +66,7 @@ Il problema successivo riguarda i tuoi permessi per effettuare commit. Il workfl
 
 Tutte queste domande possono influire sul modo in cui contribuisci al progetto e quale tipo di workflow sia quello preferito o disponibile. Illustrerò gli aspetti di ciascuno di questi in una serie di casi d'uso, dal più semplice al più complesso: dovresti essere capace di definire il workflow specifico per il tuo caso basandoti su questi esempi.
 
-### Linee guida per il commit ###
+### Linee guida per le commit ###
 
 Prima di guardare ai casi specifici, una breve nota riguardo ai messaggi di commit. Avere una linea guida per creare commit e aderirvi rende il lavoro con Git e la collaborazione con altri molto più semplice. Il progetto Git fornisce un documento che da alcuni suggerimenti per la creazione di messaggi di commit - puoi leggerlo nel codice sorgente di Git nel file `Documentation/SubmittingPatches`.
 

From bef44856f5b5f2f4c0da838800fc20355d20e873 Mon Sep 17 00:00:00 2001
From: Christian Finnberg <christian@finnberg.net>
Date: Mon, 13 Jan 2014 23:24:43 +0200
Subject: [PATCH 100/690] Update 01-chapter5.markdown

Fixed typo.
---
 es/05-distributed-git/01-chapter5.markdown | 346 +--------------------
 1 file changed, 2 insertions(+), 344 deletions(-)

diff --git a/es/05-distributed-git/01-chapter5.markdown b/es/05-distributed-git/01-chapter5.markdown
index 2f4f74e7e..91972492e 100644
--- a/es/05-distributed-git/01-chapter5.markdown
+++ b/es/05-distributed-git/01-chapter5.markdown
@@ -1,6 +1,6 @@
 # Git en entornos distribuidos #
 
-Ahora que ya tienes un repositorio Git, configurado como punto de trabajo para compartir código entre desarrolladores. Y ahora que ya conoces los comandos básicos de Git para flujos de trabajo locales. Puedes hechar un vistazo a algunos de los flujos de trabajo distribuidos que Git permite.
+Ahora que ya tienes un repositorio Git, configurado como punto de trabajo para compartir código entre desarrolladores. Y ahora que ya conoces los comandos básicos de Git para flujos de trabajo locales. Puedes echar un vistazo a algunos de los flujos de trabajo distribuidos que Git permite.
 
 En este capítulo, verás cómo trabajar con Git en un entorno distribuido, bien como colaborador o bien como integrador. Es decir, aprenderás cómo contribuir adecuadamente a un proyecto; de la forma más efectiva posible, tanto para tí, como para quien gestione el proyecto. Y aprenderás también a gestionar proyectos en los que colaboren multiples desarrolladores.
 
@@ -545,346 +545,4 @@ Tras esto, Git escupirá una serie de información de registro, con pinta más o
 	To: jessica@example.com
 	Subject: [PATCH 1/2] added limit to log function
 	Date: Sat, 30 May 2009 13:29:15 -0700
-	Message-Id: <1243715356-61726-1-git-send-email-jessica@example.com>
-	X-Mailer: git-send-email 1.6.2.rc1.20.g8c5b.dirty
-	In-Reply-To: <y>
-	References: <y>
-
-	Result: OK
-
-En estos momentos, deberías poder ir a tu carpeta de borradores (Drafts), cambiar el destinatario (To) para apuntar a la lista de correo donde estés enviando el parche, puede que poner en copia (CC) al gestor o persona responsable, y enviar el mensaje.
-
-### Recapitulación ###
-
-En esta sección hemos visto unos cuantos de los flujos de trabajo más habituales para lidiar con distintos tipos de proyectos Git. Y hemos introducido un par de nuevas herramientas para ayudarte a gestionar estos procesos. A continuación veremos cómo trabajar en el otro lado de la moneda: manteniendo y gestionando un proyecto Git. Vas a aprender cómo ser un dictador benevolente o un gestor de integración.
-
-## Gestionando un proyecto ##
-
-Además de conocer cómo contribuir de forma efectiva a un proyecto, es posible que desees saber tambien cómo mantener uno. Lo cual implicará saber aceptar y aplicar parches generados vía `format-patch`, enviados a tí a través de correo-e; o saber integrar cambios realizados en ramas de repositorios que añadirás como remotos a tu proyecto. Tanto si gestionas un repositorio canónico, como si deseas colaborar verificando o aprobando parches, necesitas saber cómo aceptar trabajo de otros de la forma más clara para tus contribuyentes y más sostenible para tí a largo plazo.
-
-### Trabajando con Ramas Puntuales ###
-
-Cuando estás pensando en integrar nuevo trabajo, suele ser buena idea utilizar una rama puntual para cada tema concreto --una rama temporal creada específicamente para trabajar dicho tema-- De esta forma, es sencillo tratar cada parche de forma individualizada y poder "aparcar" uno concreto cuando no trabajamos en él, hasta cuando volvamos a tener tiempo para retomarlo. Si creas los nombres de ramas basandolos en el tema sobre el que vas a trabajar, por ejemplo 'ruby client' o algo así de descriptivo, podrás recordar de qué iba cada rama en caso de que la abandones por un tiempo y la retomes más tarde. La persona gestora del proyecto Git suele tender a nombrar cada rama de foma parecida --por ejemplo 'sc/ruby client', donde sc es la abreviatura para la persona que ha contribuido con ese trabajo--.
-Como recordarás, la forma de crear una rama basandola en tu rama master es:
-
-	$ git branch sc/ruby_client master
-
-O, si deseas crearla y saltar inmediatamente a ella, puedes también utilizar la opción '-b' del comando 'checkout':
-
-	$ git checkout -b sc/ruby_client master
-
-Tras esto, estarás listo para añadir tu trabajo a esa rama puntual y ver si deseas o no fusionarla luego con alguna otra de tus ramas de más largo recorrido.
-
-### Aplicar parches recibidos por correo-e ###
-
-Si vas a integrar en tu proyecto un parche recibido a través de un correo electrónico. Antes de poder evaluarlo, tendrás que incorporarlo a una de tus ramas puntuales. Tienes dos caminos para incorporar un parche recibido por correo-e: usando el comando 'git apply' o usando el comando 'git am'.
-
-#### Incorporando un parche con apply ####
-
-Si recibes un parche de alguien que lo ha generado con el comando 'git diff' o con un comando 'diff' de Unix, puedes incorporalo con el comando 'git apply'. Suponiendo que has guardado el parche en '/tmp/patch-ruby-client.patch', puedes incorporarlo con una orden tal como:
-
-	$ git apply /tmp/patch-ruby-client.patch
-
-Esto modificará los archivos en tu carpeta de trabajo. Es prácticamente idéntico a lanzar el comando 'patch -p1', aunque es más paranoico y acepta menos coincidencias aproximadas. Además, es capaz de manejar adicciones, borrados o renombrados de archivos, si vienen en formato 'git diff'. Mientras que 'patch' no puede hacerlo. Por ultimo, citar que 'git apply' sigue un modelo de "aplicar todo o abortar todo", incorporando todos los cambios o no incorporando ninguno. Mientras que 'patch' puede incorporar cambios parcialmente, dejando tu carpeta de trabajo en un estado inconsistente. 'git apply' es, de lejos, mucho más paranoico que 'patch'. Nunca creará una confirmación de cambios (commit) por tí, --tras ejecutar el comando, tendrás que preparar (stage) y confirmar (commit) manualmente todos los cambios introducidos--.
-
-Tambien puedes utilizar 'git apply' para comprobar si un parche se puede incorporar limpiamente; antes de intentar incorporarlo. Puedes lanzar el comando 'git apply --check':
-
-	$ git apply --check 0001-seeing-if-this-helps-the-gem.patch
-	error: patch failed: ticgit.gemspec:1
-	error: ticgit.gemspec: patch does not apply
-
-Si obtienes una salida vacia, el parche se podrá incorporar limpiamente. Además, este comando retorna con un status no-cero en caso de fallar la comprobación, por lo que puedes utilizarlo en scripts si lo deseas.
-
-#### Incorporando un parche con am ####
-
-Si la persona que contribuye es usuaria de Git y conoce lo suficiente como para utilizar el comando 'format-patch' al generar su parche, tendrás mucho camino recorrido al incorporarlo; ya que el parche traerá consigo información sobre el o la autora, además de un mensaje de confirmación de cambios. Si puedes, anima a tus colaboradoras a utilizar 'format-patch' en lugar de 'diff' cuando vayan a generar parches. Solo deberías utilizar 'git apply' en caso de parches antiguos y similares.
-
-Para incorporar un parche generado con 'format-patch', utilizarás el comando 'git am'. Técnicamente, 'git am' se construyó para leer un archivo de buzón de correo (mbox file), que no es más que un simple formato de texto plano para almacenar uno o varios mensajes de correo electrónico en un solo archivo de texto. Es algo parecido a esto:
-
-	From 330090432754092d704da8e76ca5c05c198e71a8 Mon Sep 17 00:00:00 2001
-	From: Jessica Smith <jessica@example.com>
-	Date: Sun, 6 Apr 2008 10:17:23 -0700
-	Subject: [PATCH 1/2] add limit to log function
-
-	Limit log functionality to the first 20Limit log functionality to the first 20Limit log functionality to the first 20
-
-Esto es el comienzo de la salida del comando format-patch visto en la sección anterior. Es también un formato válido para un mbox. Si alguien te ha enviado correctamente un parche utilizando 'git send-email', y te lo has descargado a un formato mbox; podrás indicar dicho archivo mbox al comando 'git am', y este comenzará a incorporar todos los parches que encuentre dentro. Si tienes un cliente de correo electrónico capaz de guardar varios mensajes en formato mbox, podrás guardar series completas de parches en un mismo archivo; y luego usar 'git am' para irlos incorporando secuencialmente.
-
-Sin embargo, si alguien sube su archivo de parche a un sistema de gestión de peticiones de servicio o similar; tendrás que descargartelo a un archivo local en tu disco y luego indicar ese archivo local al comando 'git am':
-
-	$ git am 0001-limit-log-function.patch
-	Applying: add limit to log function
-
-Observarás que, tras incorporarlo limpiamente, crea automáticamente una nueva confirmación de cambios (commit). La información sobre el autor o autora la recoge de las cabeceras 'From' (Remitente) y 'Date' (Fecha). Y el mensaje para la confirmación (commit) lo recoge de 'Subject' (Asunto) y del cuerpo del correo electrónico. Por ejemplo, si consideramos el parche incorporado desde el mbox del ejemplo que acabamos de mostrar; la confirmación de camios (commit) generada será algo como:
-
-	$ git log --pretty=fuller -1
-	commit 6c5e70b984a60b3cecd395edd5b48a7575bf58e0
-	Author:     Jessica Smith <jessica@example.com>
-	AuthorDate: Sun Apr 6 10:17:23 2008 -0700
-	Commit:     Scott Chacon <schacon@gmail.com>
-	CommitDate: Thu Apr 9 09:19:06 2009 -0700
-
-	   add limit to log function
-
-	   Limit log functionality to the first 20Limit log functionality to the first 20Limit log functionality to the first 20
-
-El campo 'Commit' muestra la persona que ha incorporado el parche y cuándo lo ha incorporado. El campo 'Author' muestra la persona que ha creado originalmente el parche y cuándo fue creado este.
-
-Pero también podría suceder que el parche no se pudiera incorporar limpiamente. Es posible que tu rama principal diverja demasiado respecto de la rama sobre la que se construyó el parche; o que el parche tenga dependencias respecto de algún otro parche anterior que aún no hayas incorporado. En ese caso, el proceso 'git am' fallará y te preguntará qué deseas hacer:
-
-	$ git am 0001-seeing-if-this-helps-the-gem.patch
-	Applying: seeing if this helps the gem
-	error: patch failed: ticgit.gemspec:1
-	error: ticgit.gemspec: patch does not apply
-	Patch failed at 0001.
-	When you have resolved this problem run "git am --resolved".
-	If you would prefer to skip this patch, instead run "git am --skip".
-	To restore the original branch and stop patching run "git am --abort".
-
-Este comando pondrá marcadores de conflicto en cualquier archivo con problemas, de forma similar a como lo haría una operación de fusión (merge) o de reorganización (rebase). Y resolverás los problemas de la misma manera: editar el archivo para resolver los conflictos, prepararlo (stage), y lanzar 'git am --resolved' para continuar con el siguiente parche:
-
-	$ (fix the file)
-	$ git add ticgit.gemspec
-	$ git am --resolved
-	Applying: seeing if this helps the gem
-
-Si deseas más inteligencia por parte de Git al resolver conflictos, puedes pasarle la opción '-3', para que intente una fusión a tres bandas (three-way merge). Esta opción no se usa por defecto, porque no funcionará en caso de que la confirmación de cambios en que el parche dice estar basado no esté presente en tu repositorio.  Sin embargo, si tienes dicha confirmación de cambios (commit), --si el parche está basado en una confirmación pública--, entonces la opción '-3' suele ser mucho más avispada cuando incorporas un parche conflictivo:
-
-	$ git am -3 0001-seeing-if-this-helps-the-gem.patch
-	Applying: seeing if this helps the gem
-	error: patch failed: ticgit.gemspec:1
-	error: ticgit.gemspec: patch does not apply
-	Using index info to reconstruct a base tree...
-	Falling back to patching base and 3-way merge...
-	No changes -- Patch already applied.
-
-En este caso, estamos intentando incorporar un parche que ya tenemos incorporado. Sin la opción '-3', tendríamos problemas.
-
-Al aplicar varios parches desde un mbox, puedes lanzar el comando 'am' en modo interactivo; haciendo que se detenga en cada parche y preguntandote si aplicarlo o no:
-
-	$ git am -3 -i mbox
-	Commit Body is:
-	--------------------------
-	seeing if this helps the gem
-	--------------------------
-	Apply? [y]es/[n]o/[e]dit/[v]iew patch/[a]ccept all
-
-Es una utilidad interesante si tienes tienes almacenados unos cuantos parches, porque puedes ir revisando previamente cada parche y aplicarlos selectivamente.
-
-Cuando tengas integrados y confirmados todos los parches relativos al tema puntual en que estas trabajando, puedes plantearte cómo y cuándo lo vas a integar en alguna otra rama de más largo recorrido.
-
-### Recuperando ramas remotas ###
-
-Si recibes una contribución de un usuario que ha preparado su propio repositorio, ha guardado unos cuantos cambios en este, y luego te ha enviado la URL del repositorio y el nombre de la rama remota donde se encuentran los cambios. Puedes añadir dicho repositorio como un remoto y fusionar los cambios localmente.
-
-Por ejemplo, si Jessica te envia un correo electrónico comentandote que tiene una nueva e interesante funcionalidad en la rama 'ruby-client' de su repositorio. Puedes probarla añadiendo el remoto correspondiente y recuperando localmente dicha rama.
-
-	$ git remote add jessica git://github.com/jessica/myproject.git
-	$ git fetch jessica
-	$ git checkout -b rubyclient jessica/ruby-client
-
-Si más tarde vuelva a enviarte otro correo-e avisandote de otra gran funcionalidad que ha incorporado, puedes recuperarla (fetch y checkout) directamente, porque tienes el remoto ya definido.
-
-Es muy util cuando trabajas regularmente con una persona. En cambio, si alguien tiene un solo parche para enviarte, una sola vez, puede ser más efectivo aceptarlo directamente por correo-e; en lugar de pedir a todo el mundo que tenga cada uno su propio servidor y tener nosotros que estar continuamente añadiendo y quitando remotos para cada parche. También es muy posible que no quieras tener cientos de remotos, cada uno contribuyendo tan solo con un parche o dos. De todas formas, los scripts y los servicios albergados pueden hacerte la vida más facil en esto, --todo depende de cómo desarrolles tú y de como desarrollan las personas que colaboran contigo--.
-
-Otra ventaja de esta forma de trabajar es que recibes también el histórico de confirmaciones de cambio (commits). A pesar de poder seguir teniendo los habituales problemas con la fusión, por lo menos conoces en qué punto de tu historial han basado su trabajo. Por defecto, se aplicará una genuina fusión a tres bandas, en lugar de tener que poner un '-3' y esperar que el parche haya sido generado a partir de una confirmación de cambios (commit) pública a la que tengas tú también acceso.
-
-Si no trabajas habitualmente con una persona, pero deseas recuperar de ella por esta vía, puedes indicar directamente el URL del repositorio remoto en el comando 'git pull'. Esto efectua una recuperación (pull) puntual y no conserva la URL como una referencia remota:
-
-	$ git pull git://github.com/onetimeguy/project.git
-	From git://github.com/onetimeguy/project
-	 * branch            HEAD       -> FETCH_HEAD
-	Merge made by recursive.
-
-### Revisando lo introducido ###
-
-Ahora que tienes una rama puntual con trabajo aportado por otras personas. Tienes que decidir lo que deseas hacer con él. En esta sección revisaremos un par de comandos, que te ayudarán a ver exactamente los cambios que introducirás si fusionas dicha rama puntual con tu rama principal.
-
-Suele ser util revisar todas las confirmaciones de cambios (commits) que esten es esta rama, pero no en tu rama principal. Puedes excluir de la lista las confirmaciones de tu rama principal añadiendo la opción '--not' delante del nombre de la rama. Por ejemplo, si la persona colaboradora te envia dos parches y tu creas una rama 'contrib' donde aplicar dichos parches; puedes lanzar algo como esto:
-
-	$ git log contrib --not master
-	commit 5b6235bd297351589efc4d73316f0a68d484f118
-	Author: Scott Chacon <schacon@gmail.com>
-	Date:   Fri Oct 24 09:53:59 2008 -0700
-
-	    seeing if this helps the gem
-
-	commit 7482e0d16d04bea79d0dba8988cc78df655f16a0
-	Author: Scott Chacon <schacon@gmail.com>
-	Date:   Mon Oct 22 19:38:36 2008 -0700
-
-	    updated the gemspec to hopefully work better
-
-Para ver en detalle los cambios introducidos por cada confirmación (commit), recuerda que pasando la opción '-p' al comando 'git log', obtendrás un listado extendido con las diferencias introducidas por cada confirmación.
-
-Para ver plenamente todas las diferencias y lo que sucederá realmente si fusionas esta rama puntual con otra rama, tendrás que utilizar un pequeño truco para obtener los resultados correctos. Puedes pensar en lanzar esto:
-
-	$ git diff master
-
-Este comando te dará las diferencias, pero puede ser engañoso. Si tu rama 'master' ha avanzado con respecto al momento en que se creó la rama puntual a partir de ella, puedes obtener resultados realmente extraños. Debido a que Git compara directamente las instantáneas de la última confirmación de cambios en la rama puntual donde te encuentras y en la rama 'master'. Por ejemplo, si en la rama 'master' habias añadido una línea a un archivo, la comparación directa de instantáneas te llevará a pensar que la rama puntual va a borrar dicha línea.
-
-Si 'master' es un ancestro directo de tu rama puntual, no tendrás problemas. Pero si los historiales de las dos ramas son divergentes, la comparación directa de diferencias dará la apariencia de estar añadiendo todo el material nuevo en la rama puntual y de estar borrando todo el material nuevo en la rama 'master'.
-
-Y lo que realmente querías ver eran los cambios introducidos por la rama puntual, --el trabajo que vas a introducir si la fusionas con la rama 'master'--. Lo puedes hacer indicando a Git que compare la última confirmación  de cambios en la rama puntual, con el más reciente ancestro común que tenga esta respecto de la rama 'master'.
-
-Técnicamente, lo puedes hacer descubriendo tu mismo dicho ancestro común y lanzando la comprobación de diferencias respecto de él:
-
-	$ git merge-base contrib master
-	36c7dba2c95e6bbb78dfa822519ecfec6e1ca649
-	$ git diff 36c7db
-
-Pero esto no es lo más conveniente. De ahí que Git suministre otro atajo para hacerlo: la sintaxis del triple-punto. Estando en el contexto del comando 'diff', puedes indicar tres puntos entre los nombres de las dos ramas; para comparar entre la última confirmación de cambios de la rama donde estás y la respectiva confirmación común con la otra rama:
-
-	$ git diff master...contrib
-
-Este comando mostrará únicamente el trabajo en tu actual rama puntual que haya sido introducido a partir de su ancestro común con la rama 'master'. Es una sintaxis muy util, que merece recordar.
-
-### Integrando el trabajo aportado por otros ###
-
-Cuando todo el trabajo presente en tu rama puntual esté listo para ser integrado en una rama de mayor rango, la cuestión es cómo hacerlo. Yendo aún más lejos, ?cual es el sistema de trabajo que deseas utilizar para el mantenimiento de tu proyecto? Tienes bastantes opciones, y vamos a ver algunas de ellas.
-
-#### Fusionando flujos de trabajo ####
-
-Una forma simple de trabajar es fusionandolo todo en tu rama 'master'. En este escenario, tienes una rama 'master' que contiene, principalmente, código estable. Cuando en una rama puntual tienes trabajo ya terminado o contribuciones ya verificadas de terceros, los fusionas en tu rama 'master', borras la rama puntual, y continuas trabajando en otra/s rama/s.  Si, tal y como se muestra en la Figura 5-19,  tenemos un repositorio con trabajos en dos ramas, denominadas 'ruby client' y 'php client'; y fusionamos primero la rama 'ruby client' y luego la 'php client', obtendremos un historial similar al de la Figura 5-20.
-
-Insert 18333fig0519.png
-Figura 5-19. Historial con varias ramas puntuales.
-
-Insert 18333fig0520.png
-Figura 5-20. Tras fusionar una rama puntual.
-
-Este es probablemente el flujo de trabajo más sencillo. Pero puede dar problemas cuando estás tratando con grandes repositorios o grandes proyectos.
-
-Teniendo muchos desarrolladores o proyectos muy grandes, muy posiblemente desees utilizar un ciclo con por lo menos dos fases. En este escenario, se dispone de dos ramas de largo recorrido: 'master' y 'develop'. La primera de ellas, 'master', será actualizada únicamente por los lanzamientos de código muy estable. La segunda rama, 'develop', es donde iremos integrando todo el código nuevo.  Ambas ramas se enviarán periodicamente al repositorio público. Cada vez que tengas una nueva rama puntual lista para integrar (Figura 5-21), la fusionarás en la rama 'develop'. Y  cuando marques el lanzamiento de una versión estable, avanzarás la rama 'master' hasta el punto donde la rama 'develop' se encuentre en ese momento (Figura 5-23).
-
-Insert 18333fig0521.png
-Figura 5-21. Antes de fusionar una rama puntual.
-
-Insert 18333fig0522.png
-Figura 5-22. Tras fusionar una rama puntual.
-
-Insert 18333fig0523.png
-Figura 5-23. Tras un lanzamiento puntual.
-
-De esta forma, cuando alguien clone el repositorio de tu proyecto, podrá recuperar (checkout) y mantener actualizadas tanto la última version estable como la versión con el material más avanzado; en las ramas 'master' y 'develop', respectivamente.
-Puedes continuar ampliando este concepto, disponiendo de una rama 'integrate' donde ir fusionando todo el trabajo entre sí. A continuación, cuando el código en dicha rama sea estable y pase todas las pruebas, la fusionarás con la rama 'develop'; y, cuando se demuestre que permanece estable durante un cierto tiempo, avanzarás la rama 'master' hasta ahí.
-
-#### Flujos de trabajo con grandes fusiones ####
-
-El proyecto Git tiene cuatro ramas de largo recorrido: 'master', 'next', 'pu' (proposed updates) para el trabajo nuevo, y 'maint' (maintenance) para trabajos de mantenimiento de versiones previas. A medida que vamos introduciendo nuevos trabajos de las personas colaboradoras, estos se van recolectando en ramas puntuales en el repositorio de una persona gestora; de forma similar a como se ha ido describiendo (ver Figura 5-24). En un momento dado, las funcionalidades introducidas se evaluan; comprobando si son seguras y si están preparadas para los consumidores; o si, por el contrario, necesitan dedicarles más trabajo. Las funcionalidades que resultan ser seguras y estar preparadas se fusionan (merge) en la rama 'next'; y esta es enviada (push) al repositorio público, para que cualquiera pueda probarlas.
-
-Insert 18333fig0524.png
-Figura 5-24. Gestionando complejas series de ramas puntuales paralelas con funcionalidades varias.
-
-Si las funcionalidades necesitan ser más trabajadas, se fusionan (merge) en la rama 'pu'. Y cuando las funcionalidades permanecen totalmente estables, se refusionan en la rama 'master'; componiendolas desde las funcionalidades en la rama 'next' aún sin   promocionar a 'master'.  Esto significa que 'master' prácticamente siempre avanza; 'next' se reorganiza (rebase) de vez en cuando; y 'pu' es reorganizada con más frecuencia (ver Figura 5-25).
-
-Insert 18333fig0525.png
-Figura 5-25. Fusionando aportaciones de ramas puntuales en ramas de más largo recorrido.
-
-Una rama puntual se borra del repositorio cuando, finalmente, es fusionada en la rama 'master'. El proyecto Git dispone también de una rama 'maint' que se bifurca (fork) a partir de la última versión ya lanzada; para trabajar en parches, en caso de necesitarse alguna versión intermedia de mantenimiento. Así, cuando clonas el repositorio de Git, obtienes cuatro ramas que puedes recuperar (checkout); pudiendo evaluar el proyecto en distintos estadios de desarrollo, dependiendo de cuán avanzado desees estar o cómo desees contribuir. Y así, los gestores de mantenimiento disponen de un flujo de trabajo estructurado, para ayudarles en el procesado e incorporación de nuevas contribuciones.
-
-#### Flujos de trabajo reorganizando o entresacando ####
-
-Otros gestores de mantenimiento,  al procesar el trabajo recibido de las personas colaboradoras, en lugar de fusiones (merge), suelen preferir reorganizar (rebase) o entresacar (cherry-pick) sobre su propia rama principal; obteniendo así un historial prácticamente lineal. Cuando desees integrar el trabajo que tienes en una rama puntual, te puedes situar sobre ella y lanzar el comando 'rebase'; de esta forma recompondrás los cambios encima de tu actual rama 'master' (o 'develop' o lo que corresponda). Si funciona, se realizará un avance rápido (fast-forward) en tu rama 'master', y acabarás teniendo un historial lineal en tu proyecto.
-
-El otro camino para introducir trabajo de una rama en otra, es entresacarlo. Entresacar (cherry-pick) en Git es como reorganizar (rebase) una sola confirmación de cambios (commit). Se trata de coger el parche introducido por una determinada confirmación de cambios e intentar reaplicarlo sobre la rama donde te encuentres en ese momento. Puede ser util si tienes varias confirmaciones de cambios en una rama puntual, y tan solo deseas integar una de ellas; o si tienes una única confirmación de cambios en una rama puntual, y prefieres entresacarla en lugar de reorganizar. Por ejemplo, suponiendo que tienes un proyecto parecido al ilustrado en la Figura 5-26.
-
-Insert 18333fig0526.png
-Figura 5-26. Historial de ejemplo, antes de entresacar.
-
-Si deseas integar únicamente la confirmación 'e43a6' en tu rama 'master', puedes lanzar:
-
-	$ git cherry-pick e43a6fd3e94888d76779ad79fb568ed180e5fcdf
-	Finished one cherry-pick.
-	[master]: created a0a41a9: "More friendly message when locking the index fails."
-	 3 files changed, 17 insertions(+), 3 deletions(-)
-
-Esto introduce exactamente el mismo cambio introducido por 'e43a6', pero con un nuevo valor SHA-1 de confirmación; ya que es diferente la fecha en que ha sido aplicado. Tu historial quedará tal como ilustra la Figura 5-27.
-
-Insert 18333fig0527.png
-Figura 5-27. Historial tras entresacar una confirmación de cambios de una rama puntual.
-
-Ahora, ya puedes borrar la rama puntual y descartar las confirmaciones de cambios que no deseas integrar.
-
-### Marcando tus lanzamientos de versiones ###
-
-Cuando decides dar por preparada una versión, probablemente querrás etiquetar dicho punto de algún modo; de tal forma que, más adelante, puedas volver a generar esa versión en cualquier momento. Puedes crear una nueva etiqueta tal y como se ha comentado en el capítulo 2. Si decides firmar la etiqueta como gestor de mantenimientos que eres, el proceso será algo como:
-
-	$ git tag -s v1.5 -m 'my signed 1.5 tag'
-	You need a passphrase to unlock the secret key for
-	user: "Scott Chacon <schacon@gmail.com>"
-	1024-bit DSA key, ID F721C45A, created 2009-02-09
-
-Si firmas tus etiquetas, puedes tener un problema a la hora de distribuir la clave PGP pública utilizada en la firma. Los gestores del proyeto Git ha resuelto este problema incluyendo sus claves públicas como un objeto en el repositorio, añadiendo luego una etiqueta apuntando directamente a dicho contenido. Para ello, has de seleccionar cada clave que deseas incluir, lanzando el comando 'gpg ---list-keys':
-
-	$ gpg --list-keys
-	/Users/schacon/.gnupg/pubring.gpg
-	---------------------------------
-	pub   1024D/F721C45A 2009-02-09 [expires: 2010-02-09]
-	uid                  Scott Chacon <schacon@gmail.com>
-	sub   2048g/45D02282 2009-02-09 [expires: 2010-02-09]
-
-Tras esto, puedes importar directamente la clave en la base de datos Git, exportandola y redirigiendola a través del comando 'git hash-object'. Para, de esta forma, escribir un nuevo objeto dentro de Git y obtener de vuelta la firma SHA-1 de dicho objeto.
-
-	$ gpg -a --export F721C45A | git hash-object -w --stdin
-	659ef797d181633c87ec71ac3f9ba29fe5775b92
-
-Una vez tengas el contenido de tu clave guardado en Git, puedes crear una etiquta que apunte directamente al mismo; indicando para ello el nuevo valor SHA-1 que te ha devuelto el objeto 'hash-object':
-
-	$ git tag -a maintainer-pgp-pub 659ef797d181633c87ec71ac3f9ba29fe5775b92
-
-Si lanzas el comando 'git push --tags', la etiqueta 'maintainer-pgp-pub' será compartida por todos. Cualquiera que desee verificar la autenticidad de una etiqueta, no tiene más que importar tu clave PGP, sacando el objecto directamente de la base de datos e importandolo en GPG:,
-
-	$ git show maintainer-pgp-pub | gpg --import
-
-De esta forma, pueden utilizar esa clave para verificar todas las etiquetas que firmes. Además, si incluyes instrucciones en el mensaje de etiquetado, con el comando `git show <tag>`, los usuarios podrán tener directrices específicas acerca de la verificación de etiquetas.
-
-### Generando un número de ensamblado ###
-
-Debido a que Git no dispone de una serie monótona ascendente de números para cada confirmación de cambios (commit), si deseas tener un nombre humanamente comprensible por cada confirmación, has de utilizar el comando 'git describe'. Git te dará el nombre de la etiqueta más cercana, mas el número de confirmaciones de cambios entre dicha etiqueta y la confirmación que estas describiendo, más una parte de la firma SHA-1 de la confirmación:
-
-	$ git describe master
-	v1.6.2-rc1-20-g8c5b85c
-
-De esta forma, puedes exportar una instantánea u obtener un nombre comprensible por cualquier persona. Es más, si compilas Git desde código fuente clonado desde el repositorio Git, el comando 'git --version' te dará algo parecido. Si solicitas descripción de una confirmación de cambios (commit) etiquetada directamente con su propia etiqueta particular, obtendrás dicha etiqueta como descripción.
-
-El comando 'git describe' da preferencia a las etiquetas anotativas (etiquetas creadas  con las opciones '-a' o '-s'). De esta forma las etiquetas para las versiones pueden ser creadas  usando 'git describe', asegurandose el que las confirmaciones de cambios (commit) son adecuadamente nombradas cuando se describen. Tambien puedes utilizar esta descripción para indicar lo que deseas activar (checkout) o mostrar (show); pero realmente estarás usando solamente la parte final de la firma SHA-1 abreviada, por lo que no siempre será válida. Por ejemplo, el kernel de Linux ha saltado recientemente de 8 a 10 caracteres, para asegurar la unicidad de los objetos SHA-1; dando como resultado que los nombres antiguos de 'git describe' han dejado de ser válidos.
-
-### Preparando un lanzamiento de versión ###
-
-Si quieres lanzar una nueva versión. Una de las cosas que desearas crear es un archivo con la más reciente imagen de tu código, para aquellas pobres almas que no utilizan Git. El comando para hacerlo es 'git archive':
-
-	$ git archive master --prefix='project/' | gzip > `git describe master`.tar.gz
-	$ ls *.tar.gz
-	v1.6.2-rc1-20-g8c5b85c.tar.gz
-
-Quien abra ese archivo tarball, obtendrá la más reciente imagen de tu proyecto; puesta bajo una carpeta de proyecto. También puedes crear un archivo zip de la misma manera, tan solo indicando la opción '--format=zip' al comando 'git archive':
-
-	$ git archive master --prefix='project/' --format=zip > `git describe master`.zip
-
-Así, tendrás sendos archivos tarball y zip con tu nueva versión, listos para subirlos a tu sitio web o para ser enviados por correo electrónico a tus usuarios.
-
-### El registro rápido ###
-
-Ya va siendo hora de enviar un mensaje a tu lista de correo, informando a las personas que desean conocer la marcha de tu proyecto. Una manera elegante de generar rápidamente una lista con los principales cambios añadidos a tu proyecto desde la anterior versión, es utilizando el comando 'git shortlog'. Este comando resume todas las confirmaciones de cambios (commits) en el rango que le indiques. Por ejemplo, si tu último lanzamiento de versión lo fué de la v1.0.1:
-
-	$ git shortlog --no-merges master --not v1.0.1
-	Chris Wanstrath (8):
-	      Add support for annotated tags to Grit::Tag
-	      Add packed-refs annotated tag support.
-	      Add Grit::Commit#to_patch
-	      Update version and History.txt
-	      Remove stray `puts`
-	      Make ls_tree ignore nils
-
-	Tom Preston-Werner (4):
-	      fix dates in history
-	      dynamic version method
-	      Version bump to 1.0.2
-	      Regenerated gemspec for version 1.0.2
-
-Obtendrás un claro resumen de todas las confirmaciones de cambios (commit) desde la versión v1.0.1, agrupadas por autor, y listas para ser incorporadas en un mensaje a tu lista de correo.
-
-## Recapitulación ##
-
-A estas alturas, deberías sentirte confortable tanto contribuyendo a un proyecto, como manteniendo tu propio proyecto o integrando contribuciones de otras personas. Felicidades por haber llegado a ser un desarrollador Git efectivo!. En el capítulo siguiente, aprenderás el uso de más herramientas avanzadas y algunos trucos para tratar con situaciones complejas; haciendo de tí un verdadero maestro Git.
+	Message-Id: <12437153

From e85c37f16805ca4d0c6c613cb6c16f5811176b6f Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Mon, 13 Jan 2014 16:39:22 -0600
Subject: [PATCH 101/690] Reviewed "Commit Guidelines"

---
 it/05-distributed-git/01-chapter5.markdown | 36 ++++++++++------------
 1 file changed, 17 insertions(+), 19 deletions(-)

diff --git a/it/05-distributed-git/01-chapter5.markdown b/it/05-distributed-git/01-chapter5.markdown
index c2272898f..19cb4562c 100755
--- a/it/05-distributed-git/01-chapter5.markdown
+++ b/it/05-distributed-git/01-chapter5.markdown
@@ -68,9 +68,9 @@ Tutte queste domande possono influire sul modo in cui contribuisci al progetto e
 
 ### Linee guida per le commit ###
 
-Prima di guardare ai casi specifici, una breve nota riguardo ai messaggi di commit. Avere una linea guida per creare commit e aderirvi rende il lavoro con Git e la collaborazione con altri molto più semplice. Il progetto Git fornisce un documento che da alcuni suggerimenti per la creazione di messaggi di commit - puoi leggerlo nel codice sorgente di Git nel file `Documentation/SubmittingPatches`.
+Prima di vedere i casi specifici faccio una breve nota riguardo i messaggi delle commit. Avere una linea guida per le commit e aderirvi rende il lavoro con Git e la collaborazione con altri molto più semplice. Il progetto di Git fornisce un documento che da molti suggerimenti circa le commit per da cui creare patch: puoi trovarlo nel codice sorgente di Git nel file `Documentation/SubmittingPatches`.
 
-Innanzitutto, non è il caso di inserire spazi bianchi. Git fornisce un modo semplice per cercarli - prima di un commit, esegui `git diff --check`, che identifica possibili errori riguardanti spazi bianchi e li lista per te. Qui c'è un esempio, dove ho sistituiro il colore rosso del terminale con delle lettere `X`:
+Innanzitutto non è il caso di inviare errori con degli spazi. Git fornisce un modo semplice per verificarli: esegui, prima di un commit, `git diff --check`, che identifica possibili errori riguardanti gli spazi e li elenca per te. Qui c'è un esempio in cui ho sostituiro il colore rosso del terminale con delle `X`:
 
 	$ git diff --check
 	lib/simplegit.rb:5: trailing whitespace.
@@ -80,34 +80,32 @@ Innanzitutto, non è il caso di inserire spazi bianchi. Git fornisce un modo sem
 	lib/simplegit.rb:26: trailing whitespace.
 	+    def command(git_cmd)XXXX
 
-Se esegui quel commando prima del commit, puoi vedere se stai per inserire degli spazi bianchi che potrebbero infastidire altri sviluppatori.
+Se esegui il commando prima della commit, puoi vedere se stai per committare degli spazi bianchi che potrebbero infastidire altri sviluppatori.
 
-In seguito, prova a rendere ogni commit un insieme logico di cambiamenti. Se puoi, cerca di rendere i cambiamenti "digeribili" - non scrivere codice per un intero weekend su cinque diversi problemi e poi fare un commit massivo il Lunedì. Anche se non esegui commit nel weekend, usa l'area di staging il Lunedì per suddividere il tuo lavoro in almeno un commit per problema, con un utile messaggio. Se diverse modifiche coinvolgono lo stesso file, usa `git add --patch` per aggiungere file in maniera parziale all'area di staging (spiegato nel dettaglio nel capitolo 6). Il risultato finale sarà lo stesso sia che tu faccia un commit sia che tu ne faccia cinque, finché tutti i cambiamenti sono aggiunti ad un certo punto, per cui cerca di rendere le cose più semplici ai tuoi colleghi sviluppatori quando devono controllare i tuoi cambiamenti. Questo approccio inoltre rende più semplice includere o escludere uno dei cambiamenti nel caso ti serva in seguito. Il capitolo 6 descrive una manciata di utili trucchetti di Git per riscrivere la storia ed aggiungere files all'area di staging in maniera interattiva - usa questi strumenti per mantenere una comprensibile cronologia.
+Cerca quindi di aver per ciascuna commit un insieme logico di modifiche. Se puoi, cerca di rendere i cambiamenti "digeribili": non lavorare per un intero fine settimana su cinque diversi problemi per fare poi una commit massiva il lunedì. Anche se non fai commit nel weekend, il lunedì usa l'area di staging per suddividere il tuo lavoro in almeno un commit per problema con un messaggio utile per ciascuna. Se modifiche diverse coinvolgono lo stesso file, usa `git add --patch` per aggiungere parti del file all'area di staging (trattato in dettaglio nel capitolo 6). Il risultato finale sarà lo stesso che tu faccia una o cinque commit quando queste vengano integrate in un punto, per cui cerca di rendere le cose più semplici ai tuoi colleghi sviluppatori quando devono controllare le tue modifiche. Questo approccio inoltre rende più semplice includere o escludere alcuni dei cambiamenti, nel caso ti serva successivamente. Il capitolo 6 descrive una serie di trucchi di Git utili per riscrivere la storia e aggiungere interattivamente file all'area di staging: usa questi strumenti per mantenere la cronologia pulita e comprensibile.
 
-L'ultima cosa da tenere in mente è il messaggio di commit. Prendere l'abitudine di creare messaggi di commit di qualità rende usare e collaborare tramite Git molto più semplice. Come regola generale, i tuoi messaggi dovrebbero iniziare con una singola linea di al massimo 50 caratteri che descrive il set di cambiamenti in maniera concisa, seguito da una linea bianca, ed in seguito una spiegazione dettagliata. Il progetto Git richiede che la spiegazione dettagliata includa il motivo del cambiamento ed il confronto con il comportamento precedente - questa è una buona linea guida da seguire. E' anche una buona idea usare la forma imperativa nel messaggio. In altre parole, usa dei comandi. Al posto di "Ho aggiunto dei test per" oppure "Aggiungere dei test per", usa "Aggiunti dei test per".
-Questo è un modello scritto originariamente da Tim Pope su tpope.net:
+L'ultima cosa da tenere a mente è il messaggio di commit. Prendere l'abitudine di creare messaggi di commit di qualità rende l'uso e la collaborazione tramite Git molto più semplice. Come regola generale, i tuoi messaggi dovrebbero iniziare con una sola linea di massimo 50 caratteri che descriva sinteticamente l'insieme delle modifiche seguito da una linea bianca e quindi una spiegazione dettagliata. Il progetto di Git prevede che una spiegazione molto dettagliata includa il motivo della modifica e confrontare l'implementazione committata con la precedente: questa è una buona linea guida da seguire. È una buona idea anche usare l'imperativo presente in questi messaggi. In altre parole, usa dei comandi. Al posto di "Ho aggiunto dei test per" o "Aggiungendo test per", usa "Aggiungi dei test per".
+Questo modello è stato originariamente scritto da Tim Pope su tpope.net:
 
   Breve (50 caratteri o meno) riassunto delle modifiche
 
-  Testo di spiegazione più dettagliato, se necessario. Suddividilo ogni
-  circa 72 caratteri. In alcuni contesti, la prima linea è trattata
-  come l'oggetto di un'email, ed il resto come il contenuto. La linea
-  vuota che separa il riassunto dal testo è importante (a meno che tu
-  non ometta il testo del tutto); strumenti come rebase possono andare
-  in confusione senza di essa.
+  Spiegazione più dettagliata, se necessario. Manda a capo ogni 72 caratteri 
+  circa. In alcuni contesti, la prima linea è trattata come l'oggetto di
+  un'email, ed il resto come il contenuto. La linea vuota che separa l'oggetto
+  dal testo è importante (a meno che tu non ometta il testo del tutto):
+  strumenti come rebase possono confondersi se non dovesse esserci.
 
-  Ulteriore paragrafo dopo alcune linee vuote.
+  Ulteriori paragrafi vanno dopo altre linee vuote.
 
    - Le liste puntate sono concesse
 
-   - Di solito un trattino od un asterisco viene usato come separatore,
-     preceduto da uno spazio singolo, con linee vuote tra i punti,
-     ma le convenzioni potrebbero variare in questo caso
+   - Di solito viene usato un trattino o un asterisco come separatore,
+     preceduto da uno spazio singolo, con delle linee vuote tra i punti,
+     ma le convenzioni possono essere diverse
 
-Se tutti i tuoi messaggi di commit hanno questo aspetto, le cose saranno molto più semplici per per te e gli sviluppatore con cui lavori. Il progetto Git ha dei messaggi di commit ben formattati - ti incoraggio ad eseguire `git log --no-merges` per vedere qual'è l'aspetto di una cronologia ben leggibile.
+Se tutti i tuoi messaggi di commit fossero così, per te e gli altri sviluppatori con cui lavori le cose saranno molto più semplici per te e per gli sviluppatore con cui lavori. Il progetto di Git ha dei messaggi di commit ben formattati: ti incoraggio a eseguire `git log --no-merges` per vedere qual è l'aspetto di una cronologia ben leggibile.
 
-Nei seguenti esempi, ed attraverso la maggior parte di questo libro, per brevità non formatterò i messaggi così accuratamente; invece userò l'opzione `-m` di `git commit`.
-Fa come dico, non come faccio.
+Nei esempi che seguono e nella maggior parte di questo libro, per brevità, non formatterò i messaggi accuratamente come descritto: userò invece l'opzione `-m` di `git commit`. Fa' come dico, non come faccio.
 
 ### Piccoli team privati ###
 

From 91bb38964f03435a1c2be1dc8a2eff07a685b279 Mon Sep 17 00:00:00 2001
From: "Ann + J.M" <jm@jublo.net>
Date: Wed, 15 Jan 2014 00:39:58 +0100
Subject: [PATCH 102/690] [de] Fix typos in section 6

---
 de/06-git-tools/01-chapter6.markdown | 110 +++++++++++++--------------
 1 file changed, 55 insertions(+), 55 deletions(-)

diff --git a/de/06-git-tools/01-chapter6.markdown b/de/06-git-tools/01-chapter6.markdown
index 39e8c219d..a5143a50e 100644
--- a/de/06-git-tools/01-chapter6.markdown
+++ b/de/06-git-tools/01-chapter6.markdown
@@ -695,18 +695,18 @@ Damit ist es auf einfache Art und Weise möglich, die gestashten Änderungen in
 
 <!--Many times, when working with Git, you may want to revise your commit history for some reason. One of the great things about Git is that it allows you to make decisions at the last possible moment. You can decide what files go into which commits right before you commit with the staging area, you can decide that you didn’t mean to be working on something yet with the stash command, and you can rewrite commits that already happened so they look like they happened in a different way. This can involve changing the order of the commits, changing messages or modifying files in a commit, squashing together or splitting apart commits, or removing commits entirely — all before you share your work with others.-->
 
-Beim Arbeiten mit Git kommt es häufig vor, dass man seine Commit-Historie aus irgendeinem Grund noch einmal ändern möchte. Und das Tolle an Git ist, dass es Dir die Möglichkeit bietet, Entscheidungen erst im allerletzten Moment zu treffen. Zum Beispiel bietet Dir Git mit Hilfe der Staging-Area die Möglichkeit alle Dateien zu sammeln und kurz vor einem Commit zu entscheiden, welche Daten alle in einem Commit wandern sollen. Du kannst auch Deine Dateien, die sich geändert haben, aber noch nicht ins Repository eingepflegt werden sollen, mit dem Stash-Kommando in einem Zwischenspeicher ablegen. Außerdem kannst Du bereits verfasste Commits nachträglich noch einmal ändern, sodass sich die Historie so ändert, als wäre sie ganz anders vorangeschritten. Das kann man zum Beispiel durch Änderung der Reihenfolge der Commits, durch Ändern von Commit-Nachrichten, durch Modifikationen an Dateien innerhalb eines Commits, durch Zusammenfügen zweier Commits zu einem Commit oder durch Löschen eines Commits erreichen. Und das besondere daran: Das alles bevor Du Deine Arbeit mit anderen teilst und veröffentlichst.
+Beim Arbeiten mit Git kommt es häufig vor, dass man seine Commit-Historie aus irgendeinem Grund noch einmal ändern möchte. Und das Tolle an Git ist, dass es Dir die Möglichkeit bietet, Entscheidungen erst im allerletzten Moment zu treffen. Zum Beispiel bietet Dir Git mit Hilfe der Staging-Area die Möglichkeit, alle Dateien zu sammeln und kurz vor einem Commit zu entscheiden, welche Daten alle in einen Commit wandern sollen. Du kannst auch Deine Dateien, die sich geändert haben, aber noch nicht ins Repository eingepflegt werden sollen, mit dem Stash-Kommando in einem Zwischenspeicher ablegen. Außerdem kannst Du bereits verfasste Commits nachträglich noch einmal ändern, sodass sich die Historie so ändert, als wäre sie ganz anders vorangeschritten. Das kann man zum Beispiel durch Änderung der Reihenfolge der Commits, durch Ändern von Commit-Nachrichten, durch Modifikationen an Dateien innerhalb eines Commits, durch Zusammenfügen zweier Commits zu einem Commit oder durch Löschen eines Commits erreichen. Und das Besondere daran: Das alles, bevor Du Deine Arbeit mit anderen teilst und veröffentlichst.
 
 <!--In this section, you’ll cover how to accomplish these very useful tasks so that you can make your commit history look the way you want before you share it with others.-->
 
-In diesem Kapitel werden wir die nützlichen Arbeitsschritte besprechen, die Dir helfen Deine Commit-Historie Deinen Wünschen entsprechend zu gestalten, sodass Du Dein Ergebnis danach mit anderen teilen kannst und es damit Deinem gewünschten Ergebnis entspricht.
+In diesem Kapitel werden wir die nützlichen Arbeitsschritte besprechen, die Dir helfen, Deine Commit-Historie Deinen Wünschen entsprechend zu gestalten, sodass Du Dein Ergebnis danach mit anderen teilen kannst und es damit Deinem gewünschten Ergebnis entspricht.
 
 <!--### Changing the Last Commit ###-->
 ### Ändern des letzten Commits ###
 
 <!--Changing your last commit is probably the most common rewriting of history that you’ll do. You’ll often want to do two basic things to your last commit: change the commit message, or change the snapshot you just recorded by adding, changing and removing files.-->
 
-Am häufigsten möchte man wahrscheinlich seinen letzten durchgeführten Commit noch einmal nachträglich ändern. Meist sind es zwei Dinge, die man verändern möchte: Änderung der eingegebenen Commit-Nachricht oder den eigentlich Inhalt des Schnappschusses durch Hinzufügen, Ändern oder Löschen von Dateien.
+Am häufigsten möchte man wahrscheinlich seinen letzten durchgeführten Commit noch einmal nachträglich ändern. Meist sind es zwei Dinge, die man verändern möchte: Änderung der eingegebenen Commit-Nachricht oder den eigentlichen Inhalt des Schnappschusses durch Hinzufügen, Ändern oder Löschen von Dateien.
 
 <!--If you only want to modify your last commit message, it’s very simple:-->
 
@@ -716,7 +716,7 @@ Die letzte Commit-Nachricht noch einmal zu ändern ist sehr einfach:
 
 <!--That drops you into your text editor, which has your last commit message in it, ready for you to modify the message. When you save and close the editor, the editor writes a new commit containing that message and makes it your new last commit.-->
 
-Nach Eingabe dieses Befehls wird der Texteditor mit dem Inhalt der letzten Commit-Nachricht geöffnet. Jetzt hat man Gelegenheit diesen Text zu ändern. Nach dem Speichern und Schließen des Editors, wird die Commit-Nachricht des letzten Commits entsprechend angepasst. Der alte Commit ist dadurch nicht mehr vorhanden und Du erhälst einen neuen Commit mit dem gleichen Inhalt und Deiner neuen Commit-Nachricht.
+Nach Eingabe dieses Befehls wird der Texteditor mit dem Inhalt der letzten Commit-Nachricht geöffnet. Jetzt hat man Gelegenheit diesen Text zu ändern. Nach dem Speichern und Schließen des Editors, wird die Commit-Nachricht des letzten Commits entsprechend angepasst. Der alte Commit ist dadurch nicht mehr vorhanden und Du erhältst einen neuen Commit mit dem gleichen Inhalt und Deiner neuen Commit-Nachricht.
 
 <!--If you’ve committed and then you want to change the snapshot you committed by adding or changing files, possibly because you forgot to add a newly created file when you originally committed, the process works basically the same way. You stage the changes you want by editing a file and running `git add` on it or `git rm` to a tracked file, and the subsequent `git commit -\-amend` takes your current staging area and makes it the snapshot for the new commit.-->
 
@@ -731,22 +731,22 @@ Mit dem Befehl `--amend` sollte man vorsichtig umgehen, weil mit jeder nachträg
 
 <!--To modify a commit that is farther back in your history, you must move to more complex tools. Git doesn’t have a modify-history tool, but you can use the rebase tool to rebase a series of commits onto the HEAD they were originally based on instead of moving them to another one. With the interactive rebase tool, you can then stop after each commit you want to modify and change the message, add files, or do whatever you wish. You can run rebase interactively by adding the `-i` option to `git rebase`. You must indicate how far back you want to rewrite commits by telling the command which commit to rebase onto.-->
 
-Um einen Commit, der etwas weiter in der Historie zurückliegt, zu ändern, hilft einem der Befehl `--amend` nicht weiter. Man benötigt dazu ein etwas mächtigeres und komplexeres Werkzeug. Für diese Aufgabe kann man den Rebase Befehl, den wir bereits kennengelernt haben, auf eine etwas andere Art und Weise nutzen. Anstatt den Rebase auf einen HEAD eines anderen Commits auszuführen, führt man den Rebase auf genau dem gleichen Commit aus, auf dem er bereits basiert. Dazu müssen wir nur den interaktiven Modus des Rebase-Befehls nutzen. Dieser bietet einem die Möglichkeit bei jedem Commit, der geändert werden soll, zu stoppen. Dann kann man seine Änderungen an den Dateien oder an der Commit-Nachricht entsprechend einpflegen und mit dem nächsten Commit fortfahren. Um einen interaktiven Rebase durchzuführen muss man die Option `-i` an den Befehl `git rebase` anhängen. Außerdem musst Du natürlich bestimmen, wie viele Commits Du ändern möchtest. Dazu musst Du den Commit angeben, auf welchem der Rebase basieren soll.
+Um einen Commit, der etwas weiter in der Historie zurückliegt, zu ändern, hilft einem der Befehl `--amend` nicht weiter. Man benötigt dazu ein etwas mächtigeres und komplexeres Werkzeug. Für diese Aufgabe kann man den Rebase-Befehl, den wir bereits kennengelernt haben, auf eine etwas andere Art und Weise nutzen. Anstatt den Rebase auf einen HEAD eines anderen Commits auszuführen, führt man den Rebase auf genau dem gleichen Commit aus, auf dem er bereits basiert. Dazu müssen wir nur den interaktiven Modus des Rebase-Befehls nutzen. Dieser bietet einem die Möglichkeit bei jedem Commit, der geändert werden soll, zu stoppen. Dann kann man seine Änderungen an den Dateien oder an der Commit-Nachricht entsprechend einpflegen und mit dem nächsten Commit fortfahren. Um einen interaktiven Rebase durchzuführen, muss man die Option `-i` an den Befehl `git rebase` anhängen. Außerdem musst Du natürlich bestimmen, wie viele Commits Du ändern möchtest. Dazu musst Du den Commit angeben, auf welchem der Rebase basieren soll.
 
 <!--For example, if you want to change the last three commit messages, or any of the commit messages in that group, you supply as an argument to `git rebase -i` the parent of the last commit you want to edit, which is `HEAD~2^` or `HEAD~3`. It may be easier to remember the `~3` because you’re trying to edit the last three commits; but keep in mind that you’re actually designating four commits ago, the parent of the last commit you want to edit:-->
 
-Wenn Du zum Beispiel die letzten drei, oder eine oder mehrere der letzten drei Commit-Nachrichten ändern möchtest, musst Du zusätzlich zu dem Befehl `git rebase -i` den übergeordneten Commit (also dem Commit, der in der Historie genau ein Commit zurückliegt) des letzten Commits, den Du ändern möchtest, angeben. Bei drei Commit-Nachrichten müsste das Argument also `HEAD~2^` beziehungsweise `HEAD~3` lauten. Wahrscheinlich fällt es Dir leichter das Argument `~3` zu merken, weil Du ja schließlich auf die letzten drei Einträge verweisen möchtest. Du solltest Dir aber bewusst sein, dass Du auf den viertältesten Commit verweisen musst, also dem übergeordneten Commit, den Du ändern möchtest.
+Wenn Du zum Beispiel die letzten drei, oder eine oder mehrere der letzten drei Commit-Nachrichten ändern möchtest, musst Du zusätzlich zu dem Befehl `git rebase -i` den übergeordneten Commit (also dem Commit, der in der Historie genau ein Commit zurückliegt) des letzten Commits, den Du ändern möchtest, angeben. Bei drei Commit-Nachrichten müsste das Argument also `HEAD~2^` beziehungsweise `HEAD~3` lauten. Wahrscheinlich fällt es Dir leichter das Argument `~3` zu merken, weil Du ja schließlich auf die letzten drei Einträge verweisen möchtest. Du solltest Dir aber bewusst sein, dass Du auf den viertältesten Commit verweisen musst, also den übergeordneten Commit, den Du ändern möchtest.
 
 	$ git rebase -i HEAD~3
 
 <!--Remember again that this is a rebasing command — every commit included in the range `HEAD~3..HEAD` will be rewritten, whether you change the message or not. Don’t include any commit you’ve already pushed to a central server — doing so will confuse other developers by providing an alternate version of the same change.-->
 
-Es ist wichtig, dass Du Dir bewusst bist, dass mit diesem Rebase Befehl jeder Commit im Bereich `HEAD~3..HEAD` geändert wird, unabhängig davon, ob Du die Commit-Nachricht beziehungsweise den Schnappschuss änderst oder nicht. Der Rebase-Befehl sollte nie einen Commit beinhalten, der bereits an einen zentralen Server gepusht worden ist.
-Hälst Du Dich nicht daran, werden sich andere Entwickler über Dich ärgern oder wundern, weil es jetzt eine alternative Version von der gleichen Änderung gibt.
+Es ist wichtig, dass Du Dir bewusst bist, dass mit diesem Rebase-Befehl jeder Commit im Bereich `HEAD~3..HEAD` geändert wird, unabhängig davon, ob Du die Commit-Nachricht beziehungsweise den Schnappschuss änderst oder nicht. Der Rebase-Befehl sollte nie einen Commit beinhalten, der bereits an einen zentralen Server gepusht worden ist.
+Hältst Du Dich nicht daran, werden sich andere Entwickler über Dich ärgern oder wundern, weil es jetzt eine alternative Version der gleichen Änderung gibt.
 
 <!--Running this command gives you a list of commits in your text editor that looks something like this:-->
 
-Wenn Du den Befehl ausführst, erhälst Du eine Reihe von Commits in Deinem Texteditor. Das könnte in etwa folgendermaßen aussehen:
+Wenn Du den Befehl ausführst, erhältst Du eine Reihe von Commits in Deinem Texteditor. Das könnte in etwa folgendermaßen aussehen:
 
 	pick f7f3f6d changed my name a bit
 	pick 310154e updated README formatting and added blame
@@ -765,7 +765,7 @@ Wenn Du den Befehl ausführst, erhälst Du eine Reihe von Commits in Deinem Text
 
 <!--It’s important to note that these commits are listed in the opposite order than you normally see them using the `log` command. If you run a `log`, you see something like this:-->
 
-Vielleicht ist es Dir schon aufgefallen, die Commits werden genau in der umgekehrten Reihenfolge dargestellt, wie sie der `log` Befehl ausgegeben hätte. Wenn Du also den Befehl `log` ausführst, erhält man in etwa die folgende Ausgabe:
+Vielleicht ist es Dir schon aufgefallen: die Commits werden genau in der umgekehrten Reihenfolge dargestellt, wie sie der `log` Befehl ausgegeben hätte. Wenn Du also den Befehl `log` ausführst, erhält man in etwa die folgende Ausgabe:
 
 	$ git log --pretty=format:"%h %s" HEAD~3..HEAD
 	a5f4a0d added cat-file
@@ -774,7 +774,7 @@ Vielleicht ist es Dir schon aufgefallen, die Commits werden genau in der umgekeh
 
 <!--Notice the reverse order. The interactive rebase gives you a script that it’s going to run. It will start at the commit you specify on the command line (`HEAD~3`) and replay the changes introduced in each of these commits from top to bottom. It lists the oldest at the top, rather than the newest, because that’s the first one it will replay.-->
 
-Siehst Du den Unterschied? Es ist genau die umgekehrte Reihenfolge. Ein interaktiver Rebase wird nach einem festen Schema, einer Art Skript, durchgeführt und der Texteditor zeigt Dir an, wie dieses Skript genau ablaufen wird. Der Rebase startet bei dem Commit der in der Kommandozeile angegeben wird (`HEAD~3`) und führt die Änderungen, die durch jeden Commit hinzukommen, von oben nach unten aus. Das bedeteutet, dass anstatt dem neuesten, der älteste Commit ganz oben steht, weil dieser der erste Commit ist, der bearbeitet wird.
+Siehst Du den Unterschied? Es ist genau die umgekehrte Reihenfolge. Ein interaktiver Rebase wird nach einem festen Schema, einer Art Skript, durchgeführt und der Texteditor zeigt Dir an, wie dieses Skript genau ablaufen wird. Der Rebase startet bei dem Commit, der in der Kommandozeile angegeben wird (`HEAD~3`) und führt die Änderungen, die durch jeden Commit hinzukommen, von oben nach unten aus. Das bedeutet, dass anstatt des neuesten, der älteste Commit ganz oben steht, weil dieser der erste Commit ist, der bearbeitet wird.
 
 <!--You need to edit the script so that it stops at the commit you want to edit. To do so, change the word pick to the word edit for each of the commits you want the script to stop after. For example, to modify only the third commit message, you change the file to look like this:-->
 
@@ -786,7 +786,7 @@ Du musst das Skript so anpassen, dass es an jedem Commit anhält, den Du ändern
 
 <!--When you save and exit the editor, Git rewinds you back to the last commit in that list and drops you on the command line with the following message:-->
 
-Nachdem Du das Skript gespeichert und den Editor beendet hast, setzt Git nun alle Änderungen bis zum letzten Commit der Liste zurück und zeigt danach in der Kommandozeile in etwa folgendes an:
+Nachdem Du das Skript gespeichert und den Editor beendet hast, setzt Git nun alle Änderungen bis zum letzten Commit der Liste zurück und zeigt danach in der Kommandozeile in etwa Folgendes an:
 
 	$ git rebase -i HEAD~3
 	Stopped at 7482e0d... updated the gemspec to hopefully work better
@@ -812,7 +812,7 @@ Im sich öffnenden Texteditor kannst Du jetzt die Commit-Nachricht ändern und d
 
 <!--This command will apply the other two commits automatically, and then you’re done. If you change pick to edit on more lines, you can repeat these steps for each commit you change to edit. Each time, Git will stop, let you amend the commit, and continue when you’re finished.-->
 
-Der letzte Befehl speichert die letzten beiden Commits automatisch im Repository und der Rebase ist danach abgeschlossen. Wenn Du in einer weiteren Zeile „pick“ mit „edit“ ersetzt hast, kannst Du die oben dargestellten Schritte entsprechend noch einmal ausführen. Git wird nach jedem Commit anhalten und Dir die Möglichkeit bieten, den Commit anzupassen. Danach kannst Du Git auffordern den Rebase fortzusetzen (`git rebase --continue`).
+Der letzte Befehl speichert die letzten beiden Commits automatisch im Repository und der Rebase ist danach abgeschlossen. Wenn Du in einer weiteren Zeile „pick“ mit „edit“ ersetzt hast, kannst Du die oben dargestellten Schritte entsprechend noch einmal ausführen. Git wird nach jedem Commit anhalten und Dir die Möglichkeit bieten, den Commit anzupassen. Danach kannst Du Git auffordern, den Rebase fortzusetzen (`git rebase --continue`).
 
 <!--### Reordering Commits ###-->
 ### Reihenfolge von Commits verändern ###
@@ -863,7 +863,7 @@ Wenn Du statt „pick“ oder „edit“, den Befehl „squash“ angibst, führ
 
 <!--When you save and exit the editor, Git applies all three changes and then puts you back into the editor to merge the three commit messages:-->
 
-Nach dem Speichern und Beenden des Editor, führt Git alle drei Änderungen zu einem einzelnen Commit zusammen und öffnet einen Texteditor, der alle drei Commit-Nachrichten enthält:
+Nach dem Speichern und Beenden des Editors, führt Git alle drei Änderungen zu einem einzelnen Commit zusammen und öffnet einen Texteditor, der alle drei Commit-Nachrichten enthält:
 
 
 	# This is a combination of 3 commits.
@@ -887,7 +887,7 @@ Du kannst nun die Commit-Nachricht entsprechend anpassen oder auch entsprechend
 
 <!--Splitting a commit undoes a commit and then partially stages and commits as many times as commits you want to end up with. For example, suppose you want to split the middle commit of your three commits. Instead of "updated README formatting and added blame", you want to split it into two commits: "updated README formatting" for the first, and "added blame" for the second. You can do that in the `rebase -i` script by changing the instruction on the commit you want to split to "edit":-->
 
-Man kann mit Git einen einzelnen Commit auch aufsplitten. Das bedeutet, man setzt den ursprünglichen Commit zurück, fügt dann einen Teil der Änderungen zur Staging Area hinzu und checkt das Ergebnis ein. Dies kann man unbegrenzt oft wiederholen und so einen einzelnen Commit in mehrere Commits aufteilen. Nehmen wir an, wir möchten den mittleren der beiden Commits aufteilen. Anstatt „updated README formatting and added blame“, möchten wir den Commit in folgende beiden Commits aufteilen: „updated README formatting“ soll das Thema des ersten Commits und „added blame“ soll das Thema des zweiten Commits sein. Dazu kannst Du das angezeigt Skript, welches Dir der Befehl `rebase -i` erzeugt, folgendermaßen anpassen:
+Man kann mit Git einen einzelnen Commit auch aufsplitten. Das bedeutet, man setzt den ursprünglichen Commit zurück, fügt dann einen Teil der Änderungen zur Staging Area hinzu und checkt das Ergebnis ein. Dies kann man unbegrenzt oft wiederholen und so einen einzelnen Commit in mehrere Commits aufteilen. Nehmen wir an, wir möchten den mittleren der beiden Commits aufteilen. Anstatt „updated README formatting and added blame“, möchten wir den Commit in folgende beiden Commits aufteilen: „updated README formatting“ soll das Thema des ersten Commits und „added blame“ soll das Thema des zweiten Commits sein. Dazu kannst Du das angezeigte Skript, welches Dir der Befehl `rebase -i` erzeugt, folgendermaßen anpassen:
 
 	pick f7f3f6d changed my name a bit
 	edit 310154e updated README formatting and added blame
@@ -895,7 +895,7 @@ Man kann mit Git einen einzelnen Commit auch aufsplitten. Das bedeutet, man setz
 
 <!--When you save and exit the editor, Git rewinds to the parent of the first commit in your list, applies the first commit (`f7f3f6d`), applies the second (`310154e`), and drops you to the console. There, you can do a mixed reset of that commit with `git reset HEAD^`, which effectively undoes that commit and leaves the modified files unstaged. Now you can take the changes that have been reset, and create multiple commits out of them. Simply stage and commit files until you have several commits, and run `git rebase -\-continue` when you’re done:-->
 
-Nach dem Speichern und Schließen des Editors, setzt Git die Änderungen entsprechend zurück und wendet den ersten (`f7f3f6d`) und zweiten (`310154e`) Commit an und wechselt danach zurück zur Kommandozeile. Jetzt hast Du die Möglichkeit den letzten Commit zurückzusetzen, ohne das die Änderungen im Arbeitsverzeichnis zurückgesetzt werden. Das heißt, der Commit im Repository werden gelöscht, aber Deine Änderungen im Arbeitsverzeichnis gehen nicht verloren. Um dies durchzuführen, kannst Du den Befehl `git reset HEAD^` verwenden. Jetzt kannst Du die gewünschten Änderungen für den ersten Commit zur Staging Area hinzufügen und danach einchecken. Diesen Vorgang kannst Du beliebig wiederholen, bis alle Änderungen eingecheckt sind. Wenn Du fertig bist, kannst Du den Rebase mit `git rebase --continue` fortsetzen beziehungsweise abschließen:
+Nach dem Speichern und Schließen des Editors, setzt Git die Änderungen entsprechend zurück und wendet den ersten (`f7f3f6d`) und zweiten (`310154e`) Commit an und wechselt danach zurück zur Kommandozeile. Jetzt hast Du die Möglichkeit den letzten Commit zurückzusetzen, ohne dass die Änderungen im Arbeitsverzeichnis zurückgesetzt werden. Das heißt, der Commit im Repository wird gelöscht, aber Deine Änderungen im Arbeitsverzeichnis gehen nicht verloren. Um dies durchzuführen, kannst Du den Befehl `git reset HEAD^` verwenden. Jetzt kannst Du die gewünschten Änderungen für den ersten Commit zur Staging Area hinzufügen und danach einchecken. Diesen Vorgang kannst Du beliebig wiederholen, bis alle Änderungen eingecheckt sind. Wenn Du fertig bist, kannst Du den Rebase mit `git rebase --continue` fortsetzen beziehungsweise abschließen:
 
 	$ git reset HEAD^
 	$ git add README
@@ -906,7 +906,7 @@ Nach dem Speichern und Schließen des Editors, setzt Git die Änderungen entspre
 
 <!--Git applies the last commit (`a5f4a0d`) in the script, and your history looks like this:-->
 
-Git speichert dazu den letzten Commit (`a5f4a0d`) aus dem Skript im Repository. Das Resultet sieht in etwa folgendermaßen aus:
+Git speichert dazu den letzten Commit (`a5f4a0d`) aus dem Skript im Repository. Das Resultat sieht in etwa folgendermaßen aus:
 
 	$ git log -4 --pretty=format:"%h %s"
 	1c002dd added cat-file
@@ -916,21 +916,21 @@ Git speichert dazu den letzten Commit (`a5f4a0d`) aus dem Skript im Repository.
 
 <!--Once again, this changes the SHAs of all the commits in your list, so make sure no commit shows up in that list that you’ve already pushed to a shared repository.-->
 
-Ich möchte Dich noch einmal darauf hinweisen, dass jede SHA Prüfsumme von allen Commits au der Liste geändert werden. Bitte stell also sicher, dass diese Commits in keinem öffentlichen Repository verfügbar sind.
+Ich möchte Dich noch einmal darauf hinweisen, dass jede SHA-Prüfsumme von allen Commits aus der Liste geändert werden. Bitte stell also sicher, dass diese Commits in keinem öffentlichen Repository verfügbar sind.
 
 <!--### The Nuclear Option: filter-branch ###-->
 ### Hol den Vorschlaghammer raus: filter-branch ###
 
 <!--There is another history-rewriting option that you can use if you need to rewrite a larger number of commits in some scriptable way — for instance, changing your e-mail address globally or removing a file from every commit. The command is `filter-branch`, and it can rewrite huge swaths of your history, so you probably shouldn’t use it unless your project isn’t yet public and other people haven’t based work off the commits you’re about to rewrite. However, it can be very useful. You’ll learn a few of the common uses so you can get an idea of some of the things it’s capable of.-->
 
-Es gibt noch eine weitere Möglichkeit, wie man die Historie nach seinen Wünschen anpassen kann. Diese wird oft angewandt, wenn man eine große Zahl von Commits automatisiert mit Hilfe eines Skripts anpassen will. Zum Beispiel, kann man damit die E-Mail Adresse in jedem Commit ändern oder auch eine Datei aus jedem Commit entfernen. Das Werkzeug dazu heißt `filter-branch`. Damit kann man einen riesigen Teil der Historie ändern. Man sollte diesen Befehl also nur verwenden, wenn das Projekt noch nicht weit verbreitet ist, oder andere Personen noch nicht damit begonnen haben an dem Projekt zu Arbeiten (also auf Basis der bisherigen Historie neue Branches mit Commits erstellt). Trotzdem kann dieses Werkzeug sehr nützlich sein. Ich möchte hier ein paar der Möglichkeiten dieses Werkzeugs vorstellen.
+Es gibt noch eine weitere Möglichkeit, wie man die Historie nach seinen Wünschen anpassen kann. Diese wird oft angewandt, wenn man eine große Zahl von Commits automatisiert mit Hilfe eines Skripts anpassen will. Zum Beispiel kann man damit die E-Mail-Adresse in jedem Commit ändern oder auch eine Datei aus jedem Commit entfernen. Das Werkzeug dazu heißt `filter-branch`. Damit kann man einen riesigen Teil der Historie ändern. Man sollte diesen Befehl also nur verwenden, wenn das Projekt noch nicht weit verbreitet ist, oder andere Personen noch nicht damit begonnen haben an dem Projekt zu arbeiten (also auf Basis der bisherigen Historie neue Branches mit Commits erstellt wurden). Trotzdem kann dieses Werkzeug sehr nützlich sein. Ich möchte hier ein paar der Möglichkeiten dieses Werkzeugs vorstellen.
 
 <!--#### Removing a File from Every Commit ####-->
 #### Löschen einer Datei aus jedem Commit ####
 
 <!--This occurs fairly commonly. Someone accidentally commits a huge binary file with a thoughtless `git add .`, and you want to remove it everywhere. Perhaps you accidentally committed a file that contained a password, and you want to make your project open source. `filter-branch` is the tool you probably want to use to scrub your entire history. To remove a file named passwords.txt from your entire history, you can use the `-\-tree-filter` option to `filter-branch`:-->
 
-Dieses Szenario tritt sogar relativ häufig auf. Nehmen wir einmal an, jemand fügt gedankenlos eine große binäre Datei mit `git add .` zum Repository dazu und diese soll aber in keinem der Commits enthalten sein. Oder Du hast aus Versehen eine Datei, welche ein Passwort enthält, zum Repository hinzugefügt und möchtest dieses Repository nun veröffentlichen. `filter-branch` ist dann das Werkzeug Deiner Wahl um die komplette Historie umzukrempeln. Um eine Datei mit dem Namen „passwords.txt“ aus der kompletten Historie zu löschen, kannst Du die Option `--tree-filter` verwenden:
+Dieses Szenario tritt sogar relativ häufig auf. Nehmen wir einmal an, jemand fügt gedankenlos eine große binäre Datei mit `git add .` zum Repository dazu und diese soll aber in keinem der Commits enthalten sein. Oder Du hast aus Versehen eine Datei, welche ein Passwort enthält, zum Repository hinzugefügt und möchtest dieses Repository nun veröffentlichen. `filter-branch` ist dann das Werkzeug Deiner Wahl, um die komplette Historie umzukrempeln. Um eine Datei mit dem Namen „passwords.txt“ aus der kompletten Historie zu löschen, kannst Du die Option `--tree-filter` verwenden:
 
 	$ git filter-branch --tree-filter 'rm -f passwords.txt' HEAD
 	Rewrite 6b9b3cf04e7c5686a9cb838c3f36a8cb6a0fc2bd (21/21)
@@ -964,7 +964,7 @@ Nach der Ausführung dieses Befehls ist das „trunk“ Verzeichnis das neue Arb
 
 <!--Another common case is that you forgot to run `git config` to set your name and e-mail address before you started working, or perhaps you want to open-source a project at work and change all your work e-mail addresses to your personal address. In any case, you can change e-mail addresses in multiple commits in a batch with `filter-branch` as well. You need to be careful to change only the e-mail addresses that are yours, so you use `-\-commit-filter`:-->
 
-Verflixt, es ist schon wieder passiert. Du hast vergessen den Befehl `git config` auszuführen und Deinen Namen und E-Mail Adresse zu setzen bevor Du mit der Arbeit begonnen hast. Mit `filter-branch` kann man diesen Fehler einfach beheben. Man sollte nur darauf achten, dass man nur seine eigene E-Mail Adresse ändert. Deshalb verwenden wir die Option `--commit-filter`:
+Verflixt, es ist schon wieder passiert. Du hast vergessen, den Befehl `git config` auszuführen und Deinen Namen und E-Mail-Adresse zu setzen, bevor Du mit der Arbeit begonnen hast. Mit `filter-branch` kann man diesen Fehler einfach beheben. Man sollte nur darauf achten, dass man nur seine eigene E-Mail-Adresse ändert. Deshalb verwenden wir die Option `--commit-filter`:
 
 	$ git filter-branch --commit-filter '
 	        if [ "$GIT_AUTHOR_EMAIL" = "schacon@localhost" ];
@@ -978,7 +978,7 @@ Verflixt, es ist schon wieder passiert. Du hast vergessen den Befehl `git config
 
 <!--This goes through and rewrites every commit to have your new address. Because commits contain the SHA-1 values of their parents, this command changes every commit SHA in your history, not just those that have the matching e-mail address.-->
 
-Dieser Befehl durchforstet das Repository und ersetzt in jedem Commit, dessen E-Mail Adresse des Autors „schacon@localhost“ lautet, mit der neuen E-Mail Adresse „schacon@example.com“. Zusätzlich wir der Name des Autors geändert, falls dieser nicht vorher schon „Scott Chacon“ war. Auf Grund der Architektur, dass in Git in jedem Commit die SHA1 Prüfsumme des Vorgänger Commits enthalten ist, ändert dieser Befehl jeden Commit in Deiner Historie. Die SHA1 Prüfsumme wird sich auch in allen Commits, die nicht die angegebene E-Mail Adresse enthalten, verändern.
+Dieser Befehl durchforstet das Repository und ersetzt in jedem Commit, dessen E-Mail-Adresse des Autors „schacon@localhost“ lautet, mit der neuen E-Mail Adresse „schacon@example.com“. Zusätzlich wird der Name des Autors geändert, falls dieser nicht vorher schon „Scott Chacon“ war. Auf Grund der Architektur, dass in Git in jedem Commit die SHA1 Prüfsumme des Vorgänger-Commits enthalten ist, ändert dieser Befehl jeden Commit in Deiner Historie. Die SHA1-Prüfsumme wird sich auch in allen Commits, die nicht die angegebene E-Mail-Adresse enthalten, verändern.
 
 <!--## Debugging with Git ##-->
 ## Mit Hilfe von Git debuggen ##
@@ -992,7 +992,7 @@ Git bietet auch ein paar Werkzeuge, die den Debug-Vorgang bei einem Projekt unte
 
 <!--If you track down a bug in your code and want to know when it was introduced and why, file annotation is often your best tool. It shows you what commit was the last to modify each line of any file. So, if you see that a method in your code is buggy, you can annotate the file with `git blame` to see when each line of the method was last edited and by whom. This example uses the `-L` option to limit the output to lines 12 through 22:-->
 
-Wenn Du nach einem Bug in Deinem Code suchst und gerne wissen willst, wann und warum dieser zum ersten mal auftrat, dann kann Dir das Werkzeug Datei Annotation (engl. File Annotation) sicher weiterhelfen. Es kann Dir anzeigen, in welchem Commit die jeweilige Zeile einer Datei zuletzt geändert wurde. Wenn Du also feststellst, dass eine Methode beziehungsweise eine Funktion in Deinem Code nicht mehr das gewünschte Resultat liefert, kannst Du Dir die Datei mit `git blame` genauer ansehen. Nach Aufruf des Befehls zeigt Git Dir an, welche Zeile von welcher Person als letztes geändert wurde, inklusive Datum. Das folgende Beispiel verwendet die Option `-L` um die Ausgabe auf die Zeilen 12 bis 22 einzuschränken:
+Wenn Du nach einem Bug in Deinem Code suchst und gerne wissen willst, wann und warum dieser zum ersten Mal auftrat, dann kann Dir das Werkzeug Datei-Annotation (engl. File Annotation) sicher weiterhelfen. Es kann Dir anzeigen, in welchem Commit die jeweilige Zeile einer Datei zuletzt geändert wurde. Wenn Du also feststellst, dass eine Methode beziehungsweise eine Funktion in Deinem Code nicht mehr das gewünschte Resultat liefert, kannst Du Dir die Datei mit `git blame` genauer ansehen. Nach Aufruf des Befehls zeigt Git Dir an, welche Zeile von welcher Person als letztes geändert wurde, inklusive Datum. Das folgende Beispiel verwendet die Option `-L`, um die Ausgabe auf die Zeilen 12 bis 22 einzuschränken:
 
 	$ git blame -L 12,22 simplegit.rb
 	^4832fe2 (Scott Chacon  2008-03-15 10:31:28 -0700 12)  def show(tree = 'master')
@@ -1009,11 +1009,11 @@ Wenn Du nach einem Bug in Deinem Code suchst und gerne wissen willst, wann und w
 
 <!--Notice that the first field is the partial SHA-1 of the commit that last modified that line. The next two fields are values extracted from that commit—the author name and the authored date of that commit — so you can easily see who modified that line and when. After that come the line number and the content of the file. Also note the `^4832fe2` commit lines, which designate that those lines were in this file’s original commit. That commit is when this file was first added to this project, and those lines have been unchanged since. This is a tad confusing, because now you’ve seen at least three different ways that Git uses the `^` to modify a commit SHA, but that is what it means here.-->
 
-In der ersten Spalte wird die Kurzform der SHA1 Prüfsumme des Commits angezeigt, in welchem diese Zeile zuletzt verändert wurde. Die nächsten beiden Spalten weisen auf den Autor des Commits und wann dieser verfasst wurde, hin. Auf diese Weise kannst Du leicht bestimmen, wer die jeweilige Zeile geändert hat und wann dies durchgeführt wurde. In den nächsten Spalten wird die Zeilennummer und der Inhalt der Zeile angezeigt. Die Zeilen mit der SHA1 Prüfsumme `^4832fe2` weisen darauf hin, dass diese bereits im ersten Commit vorhanden waren. Das ist also der Commit, in dem die Datei „simplegit.rb“ zum Repository hinzugefügt wurde und die Zeilen deuten damit darauf hin, dass diese bisher nie geändert wurden. Das ist für Dich wahrscheinlich ein bisschen verwirrend, denn nun kennst Du bereits drei Möglichkeiten, wie Git mit dem Zeichen `^` einer SHA1 Prüfsumme eine neue Bedeutung gibt. Aber in Zusammenhang mit  `git blame` weist das Zeichen auf den eben geschilderten Sachverhalt hin.
+In der ersten Spalte wird die Kurzform der SHA1-Prüfsumme des Commits angezeigt, in welchem diese Zeile zuletzt verändert wurde. Die nächsten beiden Spalten weisen auf den Autor des Commits und wann dieser verfasst wurde, hin. Auf diese Weise kannst Du leicht bestimmen, wer die jeweilige Zeile geändert hat und wann dies durchgeführt wurde. In den nächsten Spalten wird die Zeilennummer und der Inhalt der Zeile angezeigt. Die Zeilen mit der SHA1-Prüfsumme `^4832fe2` weisen darauf hin, dass diese bereits im ersten Commit vorhanden waren. Das ist also der Commit, in dem die Datei „simplegit.rb“ zum Repository hinzugefügt wurde und die Zeilen deuten damit darauf hin, dass diese bisher nie geändert wurden. Das ist für Dich wahrscheinlich ein bisschen verwirrend, denn nun kennst Du bereits drei Möglichkeiten, wie Git mit dem Zeichen `^` einer SHA1 Prüfsumme eine neue Bedeutung gibt. Aber in Zusammenhang mit  `git blame` weist das Zeichen auf den eben geschilderten Sachverhalt hin.
 
 <!--Another cool thing about Git is that it doesn’t track file renames explicitly. It records the snapshots and then tries to figure out what was renamed implicitly, after the fact. One of the interesting features of this is that you can ask it to figure out all sorts of code movement as well. If you pass `-C` to `git blame`, Git analyzes the file you’re annotating and tries to figure out where snippets of code within it originally came from if they were copied from elsewhere. Recently, I was refactoring a file named `GITServerHandler.m` into multiple files, one of which was `GITPackUpload.m`. By blaming `GITPackUpload.m` with the `-C` option, I could see where sections of the code originally came from:-->
 
-Eine weitere herausragende Eigenschaft von Git ist die Tatsache, dass es nicht per se das Umbenennen von Dateien verfolgt. Git speichert immer den jeweiligen Schnappschuss des Dateisystems und versucht erst danach zu bestimmen, welche Dateien umbenannt wurden. Das bietet Dir zum Beispiel die Möglichkeit herauszufinden, wie Code innerhalb des Repositorys hin und her verschoben wurde. Wenn Du also die Option `-C` an `git blame` anfügst, analysiert Git die angebene Datei und versucht herauszufinden, ob und von wo bestimmte Codezeilen herkopiert wurden. Vor kurzem habe ich ein Refactoring an einer Datei mit dem Namen `GITServerHandler.m` durchgeführt. Dabei habe ich diese Datei in mehrere Dateien aufgteilt, eine davon war `GITPackUpload.m`. Wenn ich jetzt `git blame` mit der Option `-C` auf die Datei `GITPackUpload.m` ausführe, erhalte ich eine Ausgabe mit den Codezeilen von denen das Ergebnis ursprünglich stammt:
+Eine weitere herausragende Eigenschaft von Git ist die Tatsache, dass es nicht per se das Umbenennen von Dateien verfolgt. Git speichert immer den jeweiligen Schnappschuss des Dateisystems und versucht erst danach zu bestimmen, welche Dateien umbenannt wurden. Das bietet Dir zum Beispiel die Möglichkeit herauszufinden, wie Code innerhalb des Repositorys hin und her verschoben wurde. Wenn Du also die Option `-C` an `git blame` anfügst, analysiert Git die angebene Datei und versucht herauszufinden, ob und von wo bestimmte Codezeilen herkopiert wurden. Vor kurzem habe ich ein Refactoring an einer Datei mit dem Namen `GITServerHandler.m` durchgeführt. Dabei habe ich diese Datei in mehrere Dateien aufgeteilt, eine davon war `GITPackUpload.m`. Wenn ich jetzt `git blame` mit der Option `-C` auf die Datei `GITPackUpload.m` ausführe, erhalte ich eine Ausgabe mit den Codezeilen, von denen das Ergebnis ursprünglich stammt:
 
 	$ git blame -C -L 141,153 GITPackUpload.m
 	f344f58d GITServerHandler.m (Scott 2009-01-04 141)
@@ -1032,18 +1032,18 @@ Eine weitere herausragende Eigenschaft von Git ist die Tatsache, dass es nicht p
 
 <!--This is really useful. Normally, you get as the original commit the commit where you copied the code over, because that is the first time you touched those lines in this file. Git tells you the original commit where you wrote those lines, even if it was in another file.-->
 
-Das ist enorm hilfreich. Für gewöhnlich erhälst Du damit als ursprünglichen Commit, den Commit, von welchem der Code kopiert wurde, da dies der Zeitpunkt war, bei dem diese Zeilen zum ersten mal angefasst wurden. Git zeigt Dir den ursprünglichen Commit, in dem Du die Zeilen verfasst hast, sogar an, wenn es sich dabei um eine andere Datei handelt.
+Das ist enorm hilfreich. Für gewöhnlich erhältst Du damit als ursprünglichen Commit, den Commit, von welchem der Code kopiert wurde, da dies der Zeitpunkt war, bei dem diese Zeilen zum ersten Mal angefasst wurden. Git zeigt Dir den ursprünglichen Commit, in dem Du die Zeilen verfasst hast, sogar an, wenn es sich dabei um eine andere Datei handelt.
 
 <!--### Binary Search ###-->
 ### Das Bisect Werkzeug – Binäre Suche###
 
 <!--Annotating a file helps if you know where the issue is to begin with. If you don’t know what is breaking, and there have been dozens or hundreds of commits since the last state where you know the code worked, you’ll likely turn to `git bisect` for help. The `bisect` command does a binary search through your commit history to help you identify as quickly as possible which commit introduced an issue.-->
 
-`git blame` kann Dir sehr weiterhelfen, wenn Du bereits weißt, an welcher Stelle das Problem liegt. Wenn Du aber nicht weißt, warum gewisse Dinge schief laufen, und es gibt inzwischen dutzende oder hunderte von Commits seit dem letzten funktionierenden Stand, dann solltest Du `git bisect` als Hilfestellung verwenden. Der `bisect` Befehl führt eine binäre Suche durch die Commit-Historie durch und hilft Dir auf schnelle Art und Weise die Commits zu bestimmen, die eventuell für das Problem verantwortlich sind.
+`git blame` kann Dir sehr weiterhelfen, wenn Du bereits weißt, an welcher Stelle das Problem liegt. Wenn Du aber nicht weißt, warum gewisse Dinge schief laufen, und es gibt inzwischen Dutzende oder Hunderte von Commits seit dem letzten funktionierenden Stand, dann solltest Du `git bisect` als Hilfestellung verwenden. Der `bisect` Befehl führt eine binäre Suche durch die Commit-Historie durch und hilft Dir auf schnelle Art und Weise die Commits zu bestimmen, die eventuell für das Problem verantwortlich sind.
 
 <!--Let’s say you just pushed out a release of your code to a production environment, you’re getting bug reports about something that wasn’t happening in your development environment, and you can’t imagine why the code is doing that. You go back to your code, and it turns out you can reproduce the issue, but you can’t figure out what is going wrong. You can bisect the code to find out. First you run `git bisect start` to get things going, and then you use `git bisect bad` to tell the system that the current commit you’re on is broken. Then, you must tell bisect when the last known good state was, using `git bisect good [good_commit]`:-->
 
-Nehmen wir zum Beispiel an, dass Du gerade eben Deinen Code in einer Produktivumgebung veröffentlicht hast und auf einmal bekommst Du zahlreiche Fehlerberichte über Probleme, die in Deiner Entwicklungsumgebung nicht aufgetreten sind. Du kannst Dir auch keinen Reim darauf bilden, warum der Code so reagiert. Nachdem Du Dich noch einmal näher mit Deinem Code beschäftigt hast, stellst Du fest, dass Du die Fehlerwirkung reproduzieren kannst, aber Dir ist es immer noch ein Rätsel was genau schief läuft. Wenn Du vor einem solchen Problem stehst, hilft Dir es bestimmt, wenn Du die Historie in mehrere Teile aufspaltest (engl. bisect: halbieren, zweiteilen). Als erstes startest Du mit dem Befehl `git bisect start`. Danach gibst Du mit dem Befehl `git bisect bad` an, dass der derzeit ausgecheckte Commit den Fehler aufweist. Jetzt braucht Git noch die Information, in welchem Commit das Problem noch nicht aufgetreten ist. Dazu verwendest Du den Befehl `git bisect good [good_commit]`:
+Nehmen wir zum Beispiel an, dass Du gerade eben Deinen Code in einer Produktivumgebung veröffentlicht hast und auf einmal bekommst Du zahlreiche Fehlerberichte über Probleme, die in Deiner Entwicklungsumgebung nicht aufgetreten sind. Du kannst Dir auch keinen Reim darauf bilden, warum der Code so reagiert. Nachdem Du Dich noch einmal näher mit Deinem Code beschäftigt hast, stellst Du fest, dass Du die Fehlerwirkung reproduzieren kannst, aber Dir ist es immer noch ein Rätsel, was genau schief läuft. Wenn Du vor einem solchen Problem stehst, hilft Dir es bestimmt, wenn Du die Historie in mehrere Teile aufspaltest (engl. bisect: halbieren, zweiteilen). Als erstes startest Du mit dem Befehl `git bisect start`. Danach gibst Du mit dem Befehl `git bisect bad` an, dass der derzeit ausgecheckte Commit den Fehler aufweist. Jetzt braucht Git noch die Information, in welchem Commit das Problem noch nicht aufgetreten ist. Dazu verwendest Du den Befehl `git bisect good [good_commit]`:
 
 	$ git bisect start
 	$ git bisect bad
@@ -1053,7 +1053,7 @@ Nehmen wir zum Beispiel an, dass Du gerade eben Deinen Code in einer Produktivum
 
 <!--Git figured out that about 12 commits came between the commit you marked as the last good commit (v1.0) and the current bad version, and it checked out the middle one for you. At this point, you can run your test to see if the issue exists as of this commit. If it does, then it was introduced sometime before this middle commit; if it doesn’t, then the problem was introduced sometime after the middle commit. It turns out there is no issue here, and you tell Git that by typing `git bisect good` and continue your journey:-->
 
-Nach Ausführen des letzten Befehls, zeigt Git Dir als erstes an, dass in etwa 12 Commits zwischen der letzten guten Revision (v1.0) und der aktuellen, fehlerhaften Revision liegen. Auf Basis dieser Information hat Git Dir den mittleren Commit ausgecheckt. Jetzt hast Du die Möglichkeit Deine Tests auf Basis des ausgecheckten Stands durchzuführen um herauszufinden, ob in diesem Commit der Fehler bereits bestand. Wenn der Fehler hier bereits auftritt, dann wurde er in diesem oder in einem der früheren Commits eingefügt. Wenn der Fehler hier noch nicht auftritt, dann wurde er in einem der späteren Commits eingeschleppt. In unserem Beispiel nehmen wir an, dass in diesem Commit der Fehler noch nicht bestand. Das geben wir mit dem Befehl `git bisect good` an und fahren fort:
+Nach Ausführen des letzten Befehls, zeigt Git Dir als Erstes an, dass in etwa 12 Commits zwischen der letzten guten Revision (v1.0) und der aktuellen, fehlerhaften Revision liegen. Auf Basis dieser Information hat Git Dir den mittleren Commit ausgecheckt. Jetzt hast Du die Möglichkeit Deine Tests auf Basis des ausgecheckten Stands durchzuführen, um herauszufinden, ob in diesem Commit der Fehler bereits bestand. Wenn der Fehler hier bereits auftritt, dann wurde er in diesem oder in einem der früheren Commits eingefügt. Wenn der Fehler hier noch nicht auftritt, dann wurde er in einem der späteren Commits eingeschleppt. In unserem Beispiel nehmen wir an, dass in diesem Commit der Fehler noch nicht bestand. Das geben wir mit dem Befehl `git bisect good` an und fahren fort:
 
 	$ git bisect good
 	Bisecting: 3 revisions left to test after this
@@ -1061,7 +1061,7 @@ Nach Ausführen des letzten Befehls, zeigt Git Dir als erstes an, dass in etwa 1
 
 <!--Now you’re on another commit, halfway between the one you just tested and your bad commit. You run your test again and find that this commit is broken, so you tell Git that with `git bisect bad`:-->
 
-Git hat Dir jetzt einen weiteren Commit ausgecheckt und zwar wieder den mittleren Commit zwischen dem letzten Stand im Repository und dem mittleren Commit aus der letzten Runde. Hier nehmen wir an, dass Du nach Deinen durchgeführten Tests feststellst, dass in diesem Commit der Fehler bereits vorhanden ist. Das müssen wir Git über `git bisect bad` mitteilen:
+Git hat Dir jetzt einen weiteren Commit ausgecheckt, und zwar wieder den mittleren Commit zwischen dem letzten Stand im Repository und dem mittleren Commit aus der letzten Runde. Hier nehmen wir an, dass Du nach Deinen durchgeführten Tests feststellst, dass in diesem Commit der Fehler bereits vorhanden ist. Das müssen wir Git über `git bisect bad` mitteilen:
 
 	$ git bisect bad
 	Bisecting: 1 revisions left to test after this
@@ -1069,7 +1069,7 @@ Git hat Dir jetzt einen weiteren Commit ausgecheckt und zwar wieder den mittlere
 
 <!--This commit is fine, and now Git has all the information it needs to determine where the issue was introduced. It tells you the SHA-1 of the first bad commit and show some of the commit information and which files were modified in that commit so you can figure out what happened that may have introduced this bug:-->
 
-Git checkt wieder den nächsten mittleren Commit aus und wir stellen fest, dass dieser in Ordnung ist. Ab jetzt hat Git alle notwendigen Informationen um festzustellen, in welchem Commit der Fehler eingebaut wurde. Git zeigt Dir dazu die SHA1 Prüfsumme des ersten fehlerhaften Commits an. Zusätzlich gibt es noch weitere Commit Informationen und welche Dateien in diesem Commit geändert wurden, an. Das sollte Dir nun helfen, den Fehler näher zu bestimmen:
+Git checkt wieder den nächsten mittleren Commit aus und wir stellen fest, dass dieser in Ordnung ist. Ab jetzt hat Git alle notwendigen Informationen um festzustellen, in welchem Commit der Fehler eingebaut wurde. Git zeigt Dir dazu die SHA1-Prüfsumme des ersten fehlerhaften Commits an. Zusätzlich gibt es noch weitere Commit-Informationen und welche Dateien in diesem Commit geändert wurden, an. Das sollte Dir nun helfen, den Fehler näher zu bestimmen:
 
 	$ git bisect good
 	b047b02ea83310a70fd603dc8cd7a6cd13d15c04 is first bad commit
@@ -1090,14 +1090,14 @@ Wenn Du fertig mit der Fehlersuche bist, solltest Du den Befehl `git bisect rese
 
 <!--This is a powerful tool that can help you check hundreds of commits for an introduced bug in minutes. In fact, if you have a script that will exit 0 if the project is good or non-0 if the project is bad, you can fully automate `git bisect`. First, you again tell it the scope of the bisect by providing the known bad and good commits. You can do this by listing them with the `bisect start` command if you want, listing the known bad commit first and the known good commit second:-->
 
-Wie Du vielleicht gesehen hast, ist dieser Befehl ein mächtiges Werkzeug um hunderte von Commit auf schnelle Art und Weise nach einem bestimmten Fehler zu durchsuchen. Besonders nützlich ist es, wenn Du ein Skript hast, welches mit dem Fehlercode Null beendet, wenn das Projekt in Ordnung ist und mit einem Fehlercode größer Null, wenn das Projekt Fehler enthält. Wenn Dir ein solches Skript zur Verfügung steht, kannst Du den bisher manuell durchgeführten Vorgang auch automatisieren. Wie im vorigen Beispiel musst Du Git den zuletzt fehlerfreien Commit und den fehlerhaften Commit angeben. Als verkürzte Schreibweise kannst Du an den Befehl `bisect start` den fehlerhaften und den fehlerfreien Commit angeben:
+Wie Du vielleicht gesehen hast, ist dieser Befehl ein mächtiges Werkzeug, um Hunderte von Commits auf schnelle Art und Weise nach einem bestimmten Fehler zu durchsuchen. Besonders nützlich ist es, wenn Du ein Skript hast, welches mit dem Fehlercode Null beendet, wenn das Projekt in Ordnung ist und mit einem Fehlercode größer Null, wenn das Projekt Fehler enthält. Wenn Dir ein solches Skript zur Verfügung steht, kannst Du den bisher manuell durchgeführten Vorgang auch automatisieren. Wie im vorigen Beispiel musst Du Git den zuletzt fehlerfreien Commit und den fehlerhaften Commit angeben. Als verkürzte Schreibweise kannst Du an den Befehl `bisect start` den fehlerhaften und den fehlerfreien Commit angeben:
 
 	$ git bisect start HEAD v1.0
 	$ git bisect run test-error.sh
 
 <!--Doing so automatically runs `test-error.sh` on each checked-out commit until Git finds the first broken commit. You can also run something like `make` or `make tests` or whatever you have that runs automated tests for you.-->
 
-Wenn Du die untere, genannte Zeile ausführst, führt Git automatisch nach jedem Auscheckvorgang das Skript `test-error.sh` aus und zwar solange bis es den Commit findet, der als erstes ein fehlerhaftes Ergebnis liefert. Statt einem Skript kannst Du natürlich auch `make` oder `make tests` oder eine beliebige, andere Testumgebung starten.
+Wenn Du die untere, genannte Zeile ausführst, führt Git automatisch nach jedem Auscheckvorgang das Skript `test-error.sh` aus und zwar solange bis es den Commit findet, der als erstes ein fehlerhaftes Ergebnis liefert. Statt eines Skripts kannst Du natürlich auch `make` oder `make tests` oder eine beliebige, andere Testumgebung starten.
 
 <!--## Submodules ##-->
 ## Submodule ##
@@ -1108,7 +1108,7 @@ Oft möchte man während der Arbeit an einem Projekt ein weiteres Projekt darin
 
 <!--Here’s an example. Suppose you’re developing a web site and creating Atom feeds. Instead of writing your own Atom-generating code, you decide to use a library. You’re likely to have to either include this code from a shared library like a CPAN install or Ruby gem, or copy the source code into your own project tree. The issue with including the library is that it’s difficult to customize the library in any way and often more difficult to deploy it, because you need to make sure every client has that library available. The issue with vendoring the code into your own project is that any custom changes you make are difficult to merge when upstream changes become available.-->
 
-Dazu ein Beispiel. Nehmen wir an, Du entwickelt gerade eine Webseite, die unter anderem einen Atom-Feed zur Verfügung stellen soll. Anstatt den notwendigen Code zur Auslieferung des Atom-Feeds selber zu schreiben, entscheidest Du Dich für eine geeignete Bibliothek. Dann wirst Du wahrscheinlich den Code in Dein Projekt inkludieren müssen, zum Beispiel durch eine CPAN Installation oder Ruby gem oder durch Kopieren des Quellcodes in das Arbeitsverzeichnis Deines Projekts. Das Problem beim Einbinden einer Bibliothek ist, dass es schwierig ist, diese an die eigene Bedürfnisse anzupassen. Noch schwieriger gestaltet sich dann die Veröffentlichung des Projekts, da man sicherstellen muss, dass jeder der die Software verwendet, auf die Bibliothek zugreifen kann. Wenn man die Bibliothek im eigenen Projekt projektspezifisch anpasst, hat man meist ein Problem, wenn man eine neue Version der Bibliothek einspielen will.
+Dazu ein Beispiel. Nehmen wir an, Du entwickelt gerade eine Webseite, die unter anderem einen Atom-Feed zur Verfügung stellen soll. Anstatt den notwendigen Code zur Auslieferung des Atom-Feeds selber zu schreiben, entscheidest Du Dich für eine geeignete Bibliothek. Dann wirst Du wahrscheinlich den Code in Dein Projekt inkludieren müssen, zum Beispiel durch eine CPAN-Installation oder ein Ruby-Gem oder durch Kopieren des Quellcodes in das Arbeitsverzeichnis Deines Projekts. Das Problem beim Einbinden einer Bibliothek ist, dass es schwierig ist, diese an die eigene Bedürfnisse anzupassen. Noch schwieriger gestaltet sich dann die Veröffentlichung des Projekts, da man sicherstellen muss, dass jeder der die Software verwendet, auf die Bibliothek zugreifen kann. Wenn man die Bibliothek im eigenen Projekt projektspezifisch anpasst, hat man meist ein Problem, wenn man eine neue Version der Bibliothek einspielen will.
 
 <!--Git addresses this issue using submodules. Submodules allow you to keep a Git repository as a subdirectory of another Git repository. This lets you clone another repository into your project and keep your commits separate.-->
 
@@ -1119,7 +1119,7 @@ Git löst dieses Problem mit Hilfe von Submodulen. Mit Hilfe von Submodulen kann
 
 <!--Suppose you want to add the Rack library (a Ruby web server gateway interface) to your project, possibly maintain your own changes to it, but continue to merge in upstream changes. The first thing you should do is clone the external repository into your subdirectory. You add external projects as submodules with the `git submodule add` command:-->
 
-Nehmen wir einmal an, dass Du die Rack Bibliothek (eine Ruby Gateway Schnittstelle für Webserver) zu Deinem Projekt hinzufügen willst. Dabei möchtest Du Deine eigenen Änderungen an dieser Bibliothek nachverfolgen, aber auch weiterhin Änderungen von den Rack Bibliothek-Entwicklern verwalten und zusammenmergen. Das erste was Du dazu tun musst, ist das Repository der Rack Bibliothek in ein Unterverzeichnis Deines Projekts zu klonen. Diesen Vorgang kannst Du mit Hilfe des Befehls `git submodule add` ausführen:
+Nehmen wir einmal an, dass Du die Rack-Bibliothek (eine Ruby Gateway-Schnittstelle für Webserver) zu Deinem Projekt hinzufügen willst. Dabei möchtest Du Deine eigenen Änderungen an dieser Bibliothek nachverfolgen, aber auch weiterhin Änderungen von den Rack Bibliothek-Entwicklern verwalten und zusammenmergen. Das erste was Du dazu tun musst, ist das Repository der Rack Bibliothek in ein Unterverzeichnis Deines Projekts zu klonen. Diesen Vorgang kannst Du mit Hilfe des Befehls `git submodule add` ausführen:
 
 	$ git submodule add git://github.com/chneukirchen/rack.git rack
 	Initialized empty Git repository in /opt/subtest/rack/.git/
@@ -1131,7 +1131,7 @@ Nehmen wir einmal an, dass Du die Rack Bibliothek (eine Ruby Gateway Schnittstel
 
 <!--Now you have the Rack project under a subdirectory named `rack` within your project. You can go into that subdirectory, make changes, add your own writable remote repository to push your changes into, fetch and merge from the original repository, and more. If you run `git status` right after you add the submodule, you see two things:-->
 
-Innerhalb Deines Projekts befindet sich nun im Unterverzeichnis `rack` das komplette Rack-Projekt. Man kann jetzt in diesem Verzeichnis Änderungen vornehmen und ein eigenes Remote Repository mit Schreibrechten, zu welchem man pushen kann, hinzufügen. Ebenso ist es möglich, Änderungen von den Rack Entwicklern in sein Repository zu laden und diese mit den eigenen Ergebnissen zu mergen. Im Prinzip kann man innerhalb eines Submoduls die gleichen Vorgänge, wie in einem normalen Repository ausführen. Vorher müssen wir aber noch ein paar weitere Dinge zu Submodulen besprechen. Wenn Du gleich nach dem Hinzufügen des Submoduls, den Befehl `git status` ausführst, wirst Du gleich zwei Dinge bemerken: 
+Innerhalb Deines Projekts befindet sich nun im Unterverzeichnis `rack` das komplette Rack-Projekt. Man kann jetzt in diesem Verzeichnis Änderungen vornehmen und ein eigenes Remote Repository mit Schreibrechten, zu welchem man pushen kann, hinzufügen. Ebenso ist es möglich, Änderungen von den Rack Entwicklern in sein Repository zu laden und diese mit den eigenen Ergebnissen zu mergen. Im Prinzip kann man innerhalb eines Submoduls die gleichen Vorgänge, wie in einem normalen Repository ausführen. Vorher müssen wir aber noch ein paar weitere Dinge zu Submodulen besprechen. Wenn Du gleich nach dem Hinzufügen des Submoduls, den Befehl `git status` ausführst, wirst Du gleich zwei Dinge bemerken:
 
 	$ git status
 	# On branch master
@@ -1170,15 +1170,15 @@ Die zweite Auffälligkeit bei der Ausgabe von `git status` ist der Eintrag rack.
 
 <!--Although `rack` is a subdirectory in your working directory, Git sees it as a submodule and doesn’t track its contents when you’re not in that directory. Instead, Git records it as a particular commit from that repository. When you make changes and commit in that subdirectory, the superproject notices that the HEAD there has changed and records the exact commit you’re currently working off of; that way, when others clone this project, they can re-create the environment exactly.-->
 
-Obwohl `rack` ein Unterverzeichnis in Deinem Arbeitsverzeichnis ist, erkennt Git dieses Verzeichnis als Submodul und verfolgt die Änderungen innerhalb dieses Verzeichnis nicht, wenn Git nicht innerhalb dieses Verzeichnis aufgerufen wird. Stattdessen erfässt Git welcher Commit in diesem Repository ausgecheckt ist. Wenn Du also Änderungen in diesem Unterverzeichnis durchführst und eincheckst, kann das Superprojekt erkennen, dass sich der aktuelle HEAD von diesem Projekt geändert hat. Das Superprojekt kann sich jetzt diesen Commit merken. Auf diese Art und Weise ist es möglich den kompletten Zustand des Projekts mit allen Projekten, die als Submodul hinzugefügt wurden, zu reproduzieren. In der Git Terminologie wird das Projekt, welches eines oder mehrere Submodule enthält, als Superprojekt bezeichnet.
+Obwohl `rack` ein Unterverzeichnis in Deinem Arbeitsverzeichnis ist, erkennt Git dieses Verzeichnis als Submodul und verfolgt die Änderungen innerhalb dieses Verzeichnis nicht, wenn Git nicht innerhalb dieses Verzeichnis aufgerufen wird. Stattdessen erfässt Git, welcher Commit in diesem Repository ausgecheckt ist. Wenn Du also Änderungen in diesem Unterverzeichnis durchführst und eincheckst, kann das Superprojekt erkennen, dass sich der aktuelle HEAD von diesem Projekt geändert hat. Das Superprojekt kann sich jetzt diesen Commit merken. Auf diese Art und Weise ist es möglich den kompletten Zustand des Projekts mit allen Projekten, die als Submodul hinzugefügt wurden, zu reproduzieren. In der Git Terminologie wird das Projekt, welches eines oder mehrere Submodule enthält, als Superprojekt bezeichnet.
 
 <!--This is an important point with submodules: you record them as the exact commit they’re at. You can’t record a submodule at `master` or some other symbolic reference.-->
 
-Dabei muss man sich folgender Eigenschaft bewusst sein: Git verwaltet den exakten Commit, der gerade ausgecheckt ist und nicht etwa den Branch oder eine andere Referenz. Git kann also zum Beispiel nicht speichern, dass der aktuelle Stand im Branch `master` enthalten ist. 
+Dabei muss man sich folgender Eigenschaft bewusst sein: Git verwaltet den exakten Commit, der gerade ausgecheckt ist und nicht etwa den Branch oder eine andere Referenz. Git kann also zum Beispiel nicht speichern, dass der aktuelle Stand im Branch `master` enthalten ist.
 
 <!--When you commit, you see something like this:-->
 
-Wenn Du Dein Projekt das erste mal eincheckst, erhälst Du in etwa folgende Ausgabe:
+Wenn Du Dein Projekt das erste Mal eincheckst, erhältst Du in etwa folgende Ausgabe:
 
 	$ git commit -m 'first commit with submodule rack'
 	[master 0550271] first commit with submodule rack
@@ -1188,7 +1188,7 @@ Wenn Du Dein Projekt das erste mal eincheckst, erhälst Du in etwa folgende Ausg
 
 <!--Notice the 160000 mode for the rack entry. That is a special mode in Git that basically means you’re recording a commit as a directory entry rather than a subdirectory or a file.-->
 
-Der Mode 160000, der für den rack Eintrag gilt, ist ein spezieller Mode in Git. Er bedeutet in etwa, dass man einen Commit als Verzeichnis-Eintrag in Git verwaltet und damit nicht wie normalerweise ein Verzeichnis oder eine Datei.  
+Der Mode 160000, der für den rack Eintrag gilt, ist ein spezieller Mode in Git. Er bedeutet in etwa, dass man einen Commit als Verzeichnis-Eintrag in Git verwaltet und damit nicht wie normalerweise ein Verzeichnis oder eine Datei.
 
 <!--You can treat the `rack` directory as a separate project and then update your superproject from time to time with a pointer to the latest commit in that subproject. All the Git commands work independently in the two directories:-->
 
@@ -1246,7 +1246,7 @@ Das Verzeichnis `rack` wurde zwar erzeugt, aber es ist leer. Deshalb musst Du zw
 
 <!--Now your `rack` subdirectory is at the exact state it was in when you committed earlier. If another developer makes changes to the rack code and commits, and you pull that reference down and merge it in, you get something a bit odd:-->
 
-Nach Ausführung der beiden Befehle befindet sich das Verzeichnis `rack` in genau dem gleichen Zustand, wie wir es ursprünglich eingecheckt haben. Wenn ein anderer Entwickler Änderungen am Rack Code durchführt, diese eincheckt und Du diese dann pullst und mergst, erhält man einen etwas seltsamen Zustand:  
+Nach Ausführung der beiden Befehle befindet sich das Verzeichnis `rack` in genau dem gleichen Zustand, wie wir es ursprünglich eingecheckt haben. Wenn ein anderer Entwickler Änderungen am Rack Code durchführt, diese eincheckt und Du diese dann pullst und mergst, erhält man einen etwas seltsamen Zustand:
 
 	$ git merge origin/master
 	Updating 0550271..85a3eee
@@ -1290,11 +1290,11 @@ Dieser Zustand tritt auf, weil der Zeiger auf den Commit im Submodul derzeit nic
 
 <!--You have to do this every time you pull down a submodule change in the main project. It’s strange, but it works.-->
 
-Dieser Update muss jedes mal ausgeführt werden, wenn man das Superprojekt pullt und dort ein Änderung in einem Submodul enthalten ist. Es ist vielleicht ein wenig merkwürdig, aber es funktioniert.
+Dieser Update muss jedes Mal ausgeführt werden, wenn man das Superprojekt pullt und dort ein Änderung in einem Submodul enthalten ist. Es ist vielleicht ein wenig merkwürdig, aber es funktioniert.
 
 <!--One common problem happens when a developer makes a change locally in a submodule but doesn’t push it to a public server. Then, they commit a pointer to that non-public state and push up the superproject. When other developers try to run `git submodule update`, the submodule system can’t find the commit that is referenced, because it exists only on the first developer’s system. If that happens, you see an error like this:-->
 
-Häufig tritt beim Arbeiten mit Submodulen ein Problem bei folgendem Szenario auf: Ein Entwickler führt Änderungen in einem Submodul durch, checkt diese ein, vergisst aber diese Änderungen zum zentralen Server zu pushen. Wenn dann im Superprojekt die Änderung des Submoduls ebenso eingecheckt wird und dieses dann gepusht wird, tritt ein Problem auf. Wenn jetzt andere Entwickler den neuen Stand des Superprojekts holen und den Befehl `git submodule update` ausführen, erhalten sie eine Fehlermeldung, dass der entsprechend referenzierte Commit von dem Submodul nicht gefunden werden konnte. Das passiert weil dieser Commit bei dem zweiten Entwickler noch gar nicht existiert. Wenn ein solcher Fall auftritt, erhält man in etwa folgende Fehlermeldung:  
+Häufig tritt beim Arbeiten mit Submodulen ein Problem bei folgendem Szenario auf: Ein Entwickler führt Änderungen in einem Submodul durch, checkt diese ein, vergisst aber diese Änderungen zum zentralen Server zu pushen. Wenn dann im Superprojekt die Änderung des Submoduls ebenso eingecheckt wird und dieses dann gepusht wird, tritt ein Problem auf. Wenn jetzt andere Entwickler den neuen Stand des Superprojekts holen und den Befehl `git submodule update` ausführen, erhalten sie eine Fehlermeldung, dass der entsprechend referenzierte Commit von dem Submodul nicht gefunden werden konnte. Das passiert weil dieser Commit bei dem zweiten Entwickler noch gar nicht existiert. Wenn ein solcher Fall auftritt, erhält man in etwa folgende Fehlermeldung:
 
 	$ git submodule update
 	fatal: reference isn’t a tree: 6c5e70b984a60b3cecd395edd5b48a7575bf58e0
@@ -1302,7 +1302,7 @@ Häufig tritt beim Arbeiten mit Submodulen ein Problem bei folgendem Szenario au
 
 <!--You have to see who last changed the submodule:-->
 
-Dann kann man allerdings herausfinden, wer zum letzten mal eine Änderung eingecheckt hat:
+Dann kann man allerdings herausfinden, wer zum letzten Mal eine Änderung eingecheckt hat:
 
 	$ git log -1 rack
 	commit 85a3eee996800fcfa91e2119372dd4172bf76678
@@ -1331,7 +1331,7 @@ In Git kann man diese Vorgehensweise gut abbilden, indem man für jedes Unterver
 
 <!--Using submodules isn’t without hiccups, however. First, you must be relatively careful when working in the submodule directory. When you run `git submodule update`, it checks out the specific version of the project, but not within a branch. This is called having a detached HEAD — it means the HEAD file points directly to a commit, not to a symbolic reference. The issue is that you generally don’t want to work in a detached HEAD environment, because it’s easy to lose changes. If you do an initial `submodule update`, commit in that submodule directory without creating a branch to work in, and then run `git submodule update` again from the superproject without committing in the meantime, Git will overwrite your changes without telling you.  Technically you won’t lose the work, but you won’t have a branch pointing to it, so it will be somewhat difficult to retrieve.-->
 
-Die Arbeit mit Submodulen verläuft jedoch nicht immer reibungslos. Man muss verhältnismäßig gut aufpassen, wenn man in einem Submodul-Verzeichnis arbeitet. Wenn man nämlich den Befehl `git submodule update` ausführt, checkt Git den entsprechenden Zustand des Commits aus, aber checkt dabei keinen Branch aus. Diesen Zustand nennt man auch `detached HEAD`. Das bedeutet das die Datei HEAD direkt auf einen Commit zeigt und nicht wie sonst üblich auf eine symbolische Referenz, also zum Beispiel auf einen Branch. Das Problem dabei ist, dass man normalerweise in einem solchen Zustand nicht weiterarbeiten möchte, weil es sehr leicht vorkommen kann, dass Änderungen verloren gehen. Wenn man also den Befehl `git submodule update` aufruft, dann einen Commit in dem entsprechenden Submodul-Verzeichnis ausführt, ohne davor einen Branch auszuchecken, und dann noch einmal `git submodule update` im Superprojekt aufruft, ohne dass man die Änderungen im Submodul im Superprojekt eingecheckt hat, verliert man die ganzen Änderungen, ohne das Git einen darauf vorher hinweist. Tatsächlich ist es so, dass die Änderungen nicht verloren gehen, aber es gibt keinen Branch der auf die entsprechenden Commits hinzeigt und damit kann es schwierig werden die entsprechenden Commits wiederherzustellen beziehungsweise sichtbar zu machen. 
+Die Arbeit mit Submodulen verläuft jedoch nicht immer reibungslos. Man muss verhältnismäßig gut aufpassen, wenn man in einem Submodul-Verzeichnis arbeitet. Wenn man nämlich den Befehl `git submodule update` ausführt, checkt Git den entsprechenden Zustand des Commits aus, aber checkt dabei keinen Branch aus. Diesen Zustand nennt man auch `detached HEAD`. Das bedeutet, dass die Datei HEAD direkt auf einen Commit zeigt und nicht wie sonst üblich auf eine symbolische Referenz, also zum Beispiel auf einen Branch. Das Problem dabei ist, dass man normalerweise in einem solchen Zustand nicht weiterarbeiten möchte, weil es sehr leicht vorkommen kann, dass Änderungen verloren gehen. Wenn man also den Befehl `git submodule update` aufruft, dann einen Commit in dem entsprechenden Submodul-Verzeichnis ausführt, ohne davor einen Branch auszuchecken, und dann noch einmal `git submodule update` im Superprojekt aufruft, ohne dass man die Änderungen im Submodul im Superprojekt eingecheckt hat, verliert man die ganzen Änderungen, ohne dass Git einen darauf vorher hinweist. Tatsächlich ist es so, dass die Änderungen nicht verloren gehen, aber es gibt keinen Branch, der auf die entsprechenden Commits hinzeigt, und damit kann es schwierig werden, die entsprechenden Commits wiederherzustellen beziehungsweise sichtbar zu machen.
 
 <!--To avoid this issue, create a branch when you work in a submodule directory with `git checkout -b work` or something equivalent. When you do the submodule update a second time, it will still revert your work, but at least you have a pointer to get back to.-->
 
@@ -1364,11 +1364,11 @@ Wenn ein Projekt ein Submodul enthält und man im Superprojekt zwischen einzelne
 
 <!--You have to either move it out of the way or remove it, in which case you have to clone it again when you switch back—and you may lose local changes or branches that you didn’t push up.-->
 
-In diesem Fall muss man das Verzeichnis entweder an einen anderen Ort verschieben oder löschen. Im letzteren Fall muss man aber wieder das Submodul komplett klonen, wenn man in den anderen Zweig zurückwechselt. Außerdem kann man dabei lokale Änderungen zu nichte machen oder Zweige, welche man noch nicht gepusht hat, verlieren.
+In diesem Fall muss man das Verzeichnis entweder an einen anderen Ort verschieben oder löschen. Im letzteren Fall muss man aber wieder das Submodul komplett klonen, wenn man in den anderen Zweig zurückwechselt. Außerdem kann man dabei lokale Änderungen zunichte machen oder Zweige, welche man noch nicht gepusht hat, verlieren.
 
 <!--The last main caveat that many people run into involves switching from subdirectories to submodules. If you’ve been tracking files in your project and you want to move them out into a submodule, you must be careful or Git will get angry at you. Assume that you have the rack files in a subdirectory of your project, and you want to switch it to a submodule. If you delete the subdirectory and then run `submodule add`, Git yells at you:-->
 
-Die letzte Falle in die viele Leute tappen, tritt auf, wenn man bereits vorhandene Verzeichnisse in Submodule umwandeln will. Wenn man also Dateien, die bereits von Git verwaltet werden, entfernen und in ein entsprechendes Submodul verschieben möchte, muss man vorsichtig sein. Ansonsten können schwer zu behebende Probleme mit Git auftreten. Nehmen wir zum Beispiel an, dass Du die Dateien vom Rack Projekt in ein Unterverzeichnis Deines Projekts abgelegt hast und diese jetzt aber in ein Submodul verschieben möchtest. Wenn Du das Unterverzeichnis einfach löschst und dann den Befehl `submodule add` ausführst, zeigt Dir Git folgende Fehlermeldung an:  
+Die letzte Falle, in die viele Leute tappen, tritt auf, wenn man bereits vorhandene Verzeichnisse in Submodule umwandeln will. Wenn man also Dateien, die bereits von Git verwaltet werden, entfernen und in ein entsprechendes Submodul verschieben möchte, muss man vorsichtig sein. Ansonsten können schwer zu behebende Probleme mit Git auftreten. Nehmen wir zum Beispiel an, dass Du die Dateien vom Rack Projekt in ein Unterverzeichnis Deines Projekts abgelegt hast und diese jetzt aber in ein Submodul verschieben möchtest. Wenn Du das Unterverzeichnis einfach löschst und dann den Befehl `submodule add` ausführst, zeigt Dir Git folgende Fehlermeldung an:
 
 	$ rm -Rf rack/
 	$ git submodule add git@github.com:schacon/rack.git rack
@@ -1413,19 +1413,19 @@ Wenn man dann wieder in den Zweig mit dem Submodul zurückwechseln will, erhält
 
 <!--Now that you’ve seen the difficulties of the submodule system, let’s look at an alternate way to solve the same problem. When Git merges, it looks at what it has to merge together and then chooses an appropriate merging strategy to use. If you’re merging two branches, Git uses a _recursive_ strategy. If you’re merging more than two branches, Git picks the _octopus_ strategy. These strategies are automatically chosen for you because the recursive strategy can handle complex three-way merge situations — for example, more than one common ancestor — but it can only handle merging two branches. The octopus merge can handle multiple branches but is more cautious to avoid difficult conflicts, so it’s chosen as the default strategy if you’re trying to merge more than two branches.-->
 
-Nachdem wir neben den Vor- und Nachteilen beim Arbeiten mit Submodulen kennengelernt haben, möchte ich jetzt noch eine alternative Lösung zeigen, wie man ähnliche Probleme lösen kann. Wenn Git etwas zusammenführt, also mergt, analysiert es die Teile, die es mergen muss. Auf Basis dieser Analyse entscheidet Git sich für eine geeignete Merging-Methode. Wenn man zwei Branches mergt, dann verwendet Git automatisch, die sogenannte Recursive-Strategie. Wenn man mehr als zwei Branches mergt, verwendet Git die sogenannte Octopus Strategie. Diese Strategien werden automatisch für Dich gewählt, weil die Recursive-Strategie normalerweise sehr gut geeignet ist, um einen Drei-Wege-Merge (engl. three-way merge) durchzuführen — zum Beispiel, wenn es mehr als einen gemeinsamen Vorgänger-Commit gibt — aber der Drei-Wege-Merge ist nur für das Mergen von zwei Branches geeignet. Die Octopus-Merge-Strategie kann mehrere Branches zusammenführen, aber es wird dabei vorsichtiger vorgegangen um schwierig aufzulösende Konflikte zu vermeiden. Aus diesem Grund wird diese Strategie standardmäßig verwendet, wenn man mehr als zwei Branches zusammenführen möchte. 
+Nachdem wir neben den Vor- und Nachteilen beim Arbeiten mit Submodulen kennengelernt haben, möchte ich jetzt noch eine alternative Lösung zeigen, wie man ähnliche Probleme lösen kann. Wenn Git etwas zusammenführt, also mergt, analysiert es die Teile, die es mergen muss. Auf Basis dieser Analyse entscheidet Git sich für eine geeignete Merging-Methode. Wenn man zwei Branches mergt, dann verwendet Git automatisch, die sogenannte Recursive-Strategie. Wenn man mehr als zwei Branches mergt, verwendet Git die sogenannte Octopus-Strategie. Diese Strategien werden automatisch für Dich gewählt, weil die Recursive-Strategie normalerweise sehr gut geeignet ist, um einen Drei-Wege-Merge (engl. three-way merge) durchzuführen — zum Beispiel, wenn es mehr als einen gemeinsamen Vorgänger-Commit gibt — aber der Drei-Wege-Merge ist nur für das Mergen von zwei Branches geeignet. Die Octopus-Merge-Strategie kann mehrere Branches zusammenführen, aber es wird dabei vorsichtiger vorgegangen, um schwierig aufzulösende Konflikte zu vermeiden. Aus diesem Grund wird diese Strategie standardmäßig verwendet, wenn man mehr als zwei Branches zusammenführen möchte.
 
 <!--However, there are other strategies you can choose as well. One of them is the _subtree_ merge, and you can use it to deal with the subproject issue. Here you’ll see how to do the same rack embedding as in the last section, but using subtree merges instead.-->
 
-Es gibt jedoch noch weitere Strategien die man verwenden kann. Einer dieser Strategien ist der sogenannte Subtree-Merge. Dies kann verwendet werden um unser Problem mit Unterprojekten zu lösen. Ich möchte Dir im folgenden aufzeigen, wie man das Rack-Projekt aus dem letzten Kapitel einbindet und dabei den Subree-Merge anstatt den Submodulen verwendet.
+Es gibt jedoch noch weitere Strategien, die man verwenden kann. Einer dieser Strategien ist der sogenannte Subtree-Merge. Dies kann verwendet werden, um unser Problem mit Unterprojekten zu lösen. Ich möchte Dir im folgenden aufzeigen, wie man das Rack-Projekt aus dem letzten Kapitel einbindet und dabei den Subree-Merge anstatt der Submodule verwendet.
 
 <!--The idea of the subtree merge is that you have two projects, and one of the projects maps to a subdirectory of the other one and vice versa. When you specify a subtree merge, Git is smart enough to figure out that one is a subtree of the other and merge appropriately — it’s pretty amazing.-->
 
-Das Prinzip, das hinter einem Subtree-Merge steckt, ist, dass man zwei Projekte hat und eines der Projekte wird in ein Unterverzeichnis des anderen Projekts abgebildet. Wenn man ein Subtree-Merge ausführt, ist Git schlau genug um zu erkennen, dass ein Projekt ein Abbild von einem anderen Projekt ist und es kann den Merge in geeigneter Weise durchführen — das ist wirklich sehr erstaunlich.
+Das Prinzip, das hinter einem Subtree-Merge steckt, ist, dass man zwei Projekte hat und eines der Projekte wird in ein Unterverzeichnis des anderen Projekts abgebildet. Wenn man ein Subtree-Merge ausführt, ist Git schlau genug, um zu erkennen, dass ein Projekt ein Abbild von einem anderen Projekt ist und es kann den Merge in geeigneter Weise durchführen — das ist wirklich sehr erstaunlich.
 
 <!--You first add the Rack application to your project. You add the Rack project as a remote reference in your own project and then check it out into its own branch:-->
 
-Als erstes musst Du dazu die Rack Applikation zu Deinem Projekt hinzufügen. Dazu fügst Du das Rack Projekt als neues Remote Repository in Deinem Projekt hinzu und checkst dieses in einem separaten Branch aus:
+Als erstes musst Du dazu die Rack-Applikation zu Deinem Projekt hinzufügen. Dazu fügst Du das Rack-Projekt als neues Remote Repository in Deinem Projekt hinzu und checkst dieses in einem separaten Branch aus:
 
 	$ git remote add rack_remote git@github.com:schacon/rack.git
 	$ git fetch rack_remote
@@ -1458,13 +1458,13 @@ Nach der Ausführung der drei Befehle befindet sich das Rack Projekt in Deinem B
 
 <!--You want to pull the Rack project into your `master` project as a subdirectory. You can do that in Git with `git read-tree`. You’ll learn more about `read-tree` and its friends in Chapter 9, but for now know that it reads the root tree of one branch into your current staging area and working directory. You just switched back to your `master` branch, and you pull the `rack` branch into the `rack` subdirectory of your `master` branch of your main project:-->
 
-Jetzt möchten wir das Rack Projekt in Deinen Branch `master` als Unterverzeichnis hinzufügen. Dies kann man in Git mit dem Befehl `git read-tree` durchführen. In Kapitel 9 werde ich den Befehl `read-tree` und dessen verwandten Befehle näher erläutern. Hier möchte ich nur erklären, dass der Befehl das Wurzelverzeichnis eines Branches in die aktuelle Staging Area und in das Arbeitsverzeichnis packt. Damit hast Du jetzt zu Deinem Branch `master` zurückgewechselt, den Inhalt des Branches `rack` in das Unterverzeichnis `rack` im Branch `master` Deines Projekts hinterlegt:
+Jetzt möchten wir das Rack Projekt in Deinen Branch `master` als Unterverzeichnis hinzufügen. Dies kann man in Git mit dem Befehl `git read-tree` durchführen. In Kapitel 9 werde ich den Befehl `read-tree` und dessen verwandte Befehle näher erläutern. Hier möchte ich nur erklären, dass der Befehl das Wurzelverzeichnis eines Branches in die aktuelle Staging Area und in das Arbeitsverzeichnis packt. Damit hast Du jetzt zu Deinem Branch `master` zurückgewechselt, den Inhalt des Branches `rack` in das Unterverzeichnis `rack` im Branch `master` Deines Projekts hinterlegt:
 
 	$ git read-tree --prefix=rack/ -u rack_branch
 
 <!--When you commit, it looks like you have all the Rack files under that subdirectory — as though you copied them in from a tarball. What gets interesting is that you can fairly easily merge changes from one of the branches to the other. So, if the Rack project updates, you can pull in upstream changes by switching to that branch and pulling:-->
 
-Wenn Du jetzt einen Commit ausführst, erscheint es einem so, als ob die ganzen Dateien aus dem Rack Projekt in diesem Unterverzeichnis liegen — als ob man das Projekt aus einem Tarball-Container hineinkopiert hätte. Das Besondere ist jetzt aber, dass man Änderungen zwischen den verschiedenen Branches jetzt einfach zusammenführen kann. Das beduetet, wenn das Rack Projekt aktualisiert wird, kann man sich diese Änderungen einfach holen indem man in diese Branch wechselt und dort einen Pull durchführt:   
+Wenn Du jetzt einen Commit ausführst, erscheint es einem so, als ob die ganzen Dateien aus dem Rack Projekt in diesem Unterverzeichnis liegen — als ob man das Projekt aus einem Tarball-Container hineinkopiert hätte. Das Besondere ist jetzt aber, dass man Änderungen zwischen den verschiedenen Branches jetzt einfach zusammenführen kann. Das bedeutet, wenn das Rack Projekt aktualisiert wird, kann man sich diese Änderungen einfach holen, indem man in diesen Branch wechselt und dort einen Pull durchführt:
 
 	$ git checkout rack_branch
 	$ git pull
@@ -1480,7 +1480,7 @@ Danach kann man diese Änderungen wieder in den master Branch mergen. Wenn man d
 
 <!--All the changes from your Rack project are merged in and ready to be committed locally. You can also do the opposite — make changes in the `rack` subdirectory of your master branch and then merge them into your `rack_branch` branch later to submit them to the maintainers or push them upstream.-->
 
-Die ganzen Änderungen des Rack Projekts wurden nun zusammengeführt, Du musst jetzt nur noch einen entsprechenden Commit durchführen. Man kann aber auch genau das Gegenteil machen: Man führt Änderungen im Unterverzeichnis `rack` des master Branch aus und mergt diese dann später in den Zweig `rack_branch`. Diesen kann man dann den Entwicklern des Rack Projekts zur Verfügung stellen.
+Die ganzen Änderungen des Rack Projekts wurden nun zusammengeführt, Du musst jetzt nur noch einen entsprechenden Commit durchführen. Man kann aber auch genau das Gegenteil machen: Man führt Änderungen im Unterverzeichnis `rack` des master Branches aus und mergt diese dann später in den Zweig `rack_branch`. Diesen kann man dann den Entwicklern des Rack Projekts zur Verfügung stellen.
 
 <!--To get a diff between what you have in your `rack` subdirectory and the code in your `rack_branch` branch — to see if you need to merge them — you can’t use the normal `diff` command. Instead, you must run `git diff-tree` with the branch you want to compare to:-->
 
@@ -1499,4 +1499,4 @@ Um Dein Verzeichnis `rack` mit dem letzten Stand des Branches `master` auf dem S
 
 <!--You’ve seen a number of advanced tools that allow you to manipulate your commits and staging area more precisely. When you notice issues, you should be able to easily figure out what commit introduced them, when, and by whom. If you want to use subprojects in your project, you’ve learned a few ways to accommodate those needs. At this point, you should be able to do most of the things in Git that you’ll need on the command line day to day and feel comfortable doing so.-->
 
-In diesem Kapitel hast Du viele ausgeklügelte Werzeuge kennengelernt, die es Dir ermöglichen Commits und die Staging Area nach Deinen Vorstellungen zu beeinflussen. Wenn ein Problem in Deinem Projekt auftaucht, solltest Du jetzt leicht bestimmen können, welcher Commit den Fehler verursacht hat, genauso die Information wann und von wem der Fehler begangen wurde. Wenn Du andere Projekte in Deinem Projekt verwendet möchtest, hast Du jetzt mehrere Möglichkeiten kennengelernt, wie Du dies handhaben kannst. An dieser Stelle solltest Du jetzt in der Lage sein die meisten Dinge, die Du bei der täglichen Arbeit benötigst, in der Kommandozeile durchzuführen, ohne das Dir dabei Schweißperlen auf der Stirn stehen.
+In diesem Kapitel hast Du viele ausgeklügelte Werzeuge kennengelernt, die es Dir ermöglichen Commits und die Staging Area nach Deinen Vorstellungen zu beeinflussen. Wenn ein Problem in Deinem Projekt auftaucht, solltest Du jetzt leicht bestimmen können, welcher Commit den Fehler verursacht hat, sowie wann und von wem der Fehler begangen wurde. Wenn Du andere Projekte in Deinem Projekt verwenden möchtest, hast Du jetzt mehrere Möglichkeiten kennengelernt, wie Du dies handhaben kannst. An dieser Stelle solltest Du jetzt in der Lage sein, die meisten Dinge, die Du bei der täglichen Arbeit benötigst, in der Kommandozeile durchzuführen, ohne dass Dir dabei Schweißperlen auf der Stirn stehen.

From e9bc4cb01fac71ecdf38fa39f125d92373006437 Mon Sep 17 00:00:00 2001
From: harupong <harupong@gmail.com>
Date: Wed, 15 Jan 2014 09:55:48 +0900
Subject: [PATCH 103/690] Apply 1ca5ef1 to ja

---
 ja/05-distributed-git/01-chapter5.markdown | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/ja/05-distributed-git/01-chapter5.markdown b/ja/05-distributed-git/01-chapter5.markdown
index 21d250d28..d78946f7a 100644
--- a/ja/05-distributed-git/01-chapter5.markdown
+++ b/ja/05-distributed-git/01-chapter5.markdown
@@ -171,7 +171,7 @@ John の手元に Jessica がプッシュした内容が届きましたが、さ
 マージがうまくいきました。John のコミット履歴は図 5-5 のようになります。
 
 Insert 18333fig0505.png
-図 5-5. origin/master をマージした後の John のリポジトリ
+図 5-5. `origin/master` をマージした後の John のリポジトリ
 
 自分のコードが正しく動作することを確認した John は、変更内容をサーバーにプッシュします。
 
@@ -212,7 +212,7 @@ Jessica のトピックブランチ上での作業が完了しました。プッ
 
 	    removed invalid default value
 
-Jessica はトピックブランチの内容を自分の master ブランチにマージし、同じく John の作業 (`origin/master`) も自分の `master` ブランチにマージして再び変更をサーバーにプッシュすることになります。まずは master ブランチに戻り、これまでの作業を統合できるようにします。
+Jessica はトピックブランチの内容を自分の `master` ブランチにマージし、同じく John の作業 (`origin/master`) も自分の `master` ブランチにマージして再び変更をサーバーにプッシュすることになります。まずは `master` ブランチに戻り、これまでの作業を統合できるようにします。
 
 	$ git checkout master
 	Switched to branch "master"
@@ -252,7 +252,7 @@ Insert 18333fig0509.png
 Insert 18333fig0510.png
 図 5-10. すべての変更をサーバーに書き戻した後の Jessica の履歴
 
-これがもっとも単純なワークフローです。トピックブランチでしばらく作業を進め、統合できる状態になれば自分の master ブランチにマージする。他の開発者の作業を取り込む場合は、`origin/master` を取得してもし変更があればマージする。そして最終的にそれをサーバーの `master` ブランチにプッシュする。全体的な流れは図 5-11 のようになります。
+これがもっとも単純なワークフローです。トピックブランチでしばらく作業を進め、統合できる状態になれば自分の `master` ブランチにマージする。他の開発者の作業を取り込む場合は、`origin/master` を取得してもし変更があればマージする。そして最終的にそれをサーバーの `master` ブランチにプッシュする。全体的な流れは図 5-11 のようになります。
 
 Insert 18333fig0511.png
 図 5-11. 複数開発者での Git を使ったシンプルな開発作業のイベントシーケンス

From 7c94d2639694359f416b244465509eb6f1d4d393 Mon Sep 17 00:00:00 2001
From: harupong <harupong@gmail.com>
Date: Wed, 15 Jan 2014 10:10:51 +0900
Subject: [PATCH 104/690] Apply 15f2bf1 to ja tree

---
 ja/05-distributed-git/01-chapter5.markdown | 23 +++++++++++++++++++---
 1 file changed, 20 insertions(+), 3 deletions(-)

diff --git a/ja/05-distributed-git/01-chapter5.markdown b/ja/05-distributed-git/01-chapter5.markdown
index d78946f7a..2b68260f7 100644
--- a/ja/05-distributed-git/01-chapter5.markdown
+++ b/ja/05-distributed-git/01-chapter5.markdown
@@ -528,7 +528,26 @@ Insert 18333fig0518.png
 	  port = 993
 	  sslverify = false
 
-IMAP サーバーで SSL を使っていない場合は、最後の二行はおそらく不要でしょう。そして host のところが `imaps://` ではなく `imap://` となります。ここまでの設定が終われば、`git send-email` を実行して IMAP サーバーの Drafts フォルダにパッチを置くことができるようになります。
+IMAP サーバーで SSL を使っていない場合は、最後の二行はおそらく不要でしょう。そして host のところが `imaps://` ではなく `imap://` となります。ここまでの設定が終われば、`git imap-send` を実行して IMAP サーバーの Drafts フォルダにパッチを置くことができるようになります。
+
+    $ cat *.patch |git imap-send
+    Resolving imap.gmail.com... ok
+    Connecting to [74.125.142.109]:993... ok
+    Logging in...
+    sending 2 messages
+    100% (2/2) done
+
+あとは、Drafts フォルダに移動して To フィールドをメーリングリストのアドレスに変更し (おそらく CC には担当メンテなのアドレスを入れ)、送信できるようになりました。
+
+SMTP サーバーを使ってパッチを送ることもできます。IMAP サーバー同様、設定は `git config` コマンドで順に設定してもいいですし、`~/.gitconfig` ファイルの sendmail セクションに直接入力してもかまいません。
+
+    [sendemail]
+      smtpencryption = tls
+      smtpserver = smtp.gmail.com
+      smtpuser = user@gmail.com
+      smtpserverport = 587
+
+設定が追加できたら、`git send-email` を実行してパッチを送信します。
 
 	$ git send-email *.patch
 	0001-added-limit-to-log-function.patch
@@ -555,8 +574,6 @@ Git はその後、各パッチについてこのようなログ情報をはき
 
 	Result: OK
 
-あとは、Drafts フォルダに移動して To フィールドをメーリングリストのアドレスに変更し (おそらく CC には担当メンテなのアドレスを入れ)、送信できるようになりました。
-
 ### まとめ ###
 
 このセクションでは、今後みなさんが遭遇するであろうさまざまな形式の Git プロジェクトについて、関わっていくための作業手順を説明しました。そして、その際に使える新兵器もいくつか紹介しました。次はもう一方の側、つまり Git プロジェクトを運営する側について見ていきましょう。慈悲深い独裁者、あるいは統合マネージャーとしての作業手順を説明します。

From ea953b3cbb816efac441040fbeefef310e96635f Mon Sep 17 00:00:00 2001
From: harupong <harupong@gmail.com>
Date: Wed, 15 Jan 2014 10:23:55 +0900
Subject: [PATCH 105/690] Apply 2a0a837 to ja tree

---
 ja/04-git-server/01-chapter4.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ja/04-git-server/01-chapter4.markdown b/ja/04-git-server/01-chapter4.markdown
index 43155723e..08a0f12d7 100644
--- a/ja/04-git-server/01-chapter4.markdown
+++ b/ja/04-git-server/01-chapter4.markdown
@@ -26,7 +26,7 @@ Git では、データ転送用のネットワークプロトコルとして Loc
 
 	$ git clone file:///opt/git/project.git
 
-URL の先頭に `file://` を明示するかどうかで、Git の動きは微妙に異なります。単にパスを指定した場合は、Git はハードリンクを行うか、必要に応じて直接ファイルをコピーします。`file://` を指定した場合は、Git がプロセスを立ち上げ、そのプロセスが (通常は) ネットワーク越しにデータを転送します。一般的に、直接のコピーに比べてこれは非常に非効率的です。`file://` プレフィックスをつける最も大きな理由は、(他のバージョン管理システムからインポートしたときなどにあらわれる) 関係のない参照やオブジェクトを除いたクリーンなコピーがほしいということです。本書では通常のパス表記を使用します。そのほうがたいていの場合に高速となるからです。
+URL の先頭に `file://` を明示するかどうかで、Git の動きは微妙に異なります。`file://` を明示せずパスだけを指定し、かつコピー元とコピー先が同一のファイルシステム上にある場合は、Git は必要なオブジェクトにハードリンクを張ろうとします。もし異なるファイルシステム上にある場合は、Git はシステムデフォルトのファイルコピー機能を使って必要なオブジェクトをコピーします。一方 `file://` を指定した場合は、Git がプロセスを立ち上げ、そのプロセスが (通常は) ネットワーク越しにデータを転送します。一般的に、直接のコピーに比べてこれは非常に非効率的です。`file://` プレフィックスをつける最も大きな理由は、(他のバージョン管理システムからインポートしたときなどにあらわれる) 関係のない参照やオブジェクトを除いたクリーンなコピーがほしいということです。本書では通常のパス表記を使用します。そのほうがたいていの場合に高速となるからです。
 
 ローカルのリポジトリを既存の Git プロジェクトに追加するには、このようなコマンドを実行します。
 

From af8ca93e5a3232298f0640386c4446b9ccda7bbf Mon Sep 17 00:00:00 2001
From: harupong <harupong@gmail.com>
Date: Wed, 15 Jan 2014 10:25:30 +0900
Subject: [PATCH 106/690] Apply bdef6f7 to ja tree

---
 ja/03-git-branching/01-chapter3.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ja/03-git-branching/01-chapter3.markdown b/ja/03-git-branching/01-chapter3.markdown
index 71afcde2d..1690e53b3 100644
--- a/ja/03-git-branching/01-chapter3.markdown
+++ b/ja/03-git-branching/01-chapter3.markdown
@@ -458,7 +458,7 @@ Insert 18333fig0326.png
 	Branch sf set up to track remote branch refs/remotes/origin/serverfix.
 	Switched to a new branch "sf"
 
-これで、ローカルブランチ sf が自動的に origin/serverfix を追跡するようになりました。
+これで、ローカルブランチ sf が自動的に `origin/serverfix` を追跡するようになりました。
 
 ### リモートブランチの削除 ###
 

From ccfd0e64bd63ced336c3ed25902d2d5962d700d9 Mon Sep 17 00:00:00 2001
From: "Ann + J.M" <jm@jublo.net>
Date: Wed, 15 Jan 2014 20:09:30 +0100
Subject: [PATCH 107/690] Fix wrong comma

---
 de/06-git-tools/01-chapter6.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/de/06-git-tools/01-chapter6.markdown b/de/06-git-tools/01-chapter6.markdown
index a5143a50e..bc3a7f83b 100644
--- a/de/06-git-tools/01-chapter6.markdown
+++ b/de/06-git-tools/01-chapter6.markdown
@@ -765,7 +765,7 @@ Wenn Du den Befehl ausführst, erhältst Du eine Reihe von Commits in Deinem Tex
 
 <!--It’s important to note that these commits are listed in the opposite order than you normally see them using the `log` command. If you run a `log`, you see something like this:-->
 
-Vielleicht ist es Dir schon aufgefallen: die Commits werden genau in der umgekehrten Reihenfolge dargestellt, wie sie der `log` Befehl ausgegeben hätte. Wenn Du also den Befehl `log` ausführst, erhält man in etwa die folgende Ausgabe:
+Vielleicht ist es Dir schon aufgefallen, die Commits werden genau in der umgekehrten Reihenfolge dargestellt, wie sie der `log` Befehl ausgegeben hätte. Wenn Du also den Befehl `log` ausführst, erhält man in etwa die folgende Ausgabe:
 
 	$ git log --pretty=format:"%h %s" HEAD~3..HEAD
 	a5f4a0d added cat-file

From 48bdfab00460dd63acfd03b2627966b2e7d62032 Mon Sep 17 00:00:00 2001
From: "Ann + J.M" <jm@jublo.net>
Date: Wed, 15 Jan 2014 21:39:21 +0100
Subject: [PATCH 108/690] [de] Connect compound nouns with dash, more minor
 fixes

---
 de/06-git-tools/01-chapter6.markdown | 168 +++++++++++++--------------
 1 file changed, 84 insertions(+), 84 deletions(-)

diff --git a/de/06-git-tools/01-chapter6.markdown b/de/06-git-tools/01-chapter6.markdown
index bc3a7f83b..31bcf958a 100644
--- a/de/06-git-tools/01-chapter6.markdown
+++ b/de/06-git-tools/01-chapter6.markdown
@@ -3,11 +3,11 @@
 
 <!--By now, you’ve learned most of the day-to-day commands and workflows that you need to manage or maintain a Git repository for your source code control. You’ve accomplished the basic tasks of tracking and committing files, and you’ve harnessed the power of the staging area and lightweight topic branching and merging.-->
 
-Bis hierher hast Du die meisten täglichen Kommandos und Arbeitsweisen gelernt, die Du brauchst um ein Git Repository für Deine Quellcode Kontrolle, zu benutzen. Du hast die grundlegenden Aufgaben des tracking und committing von Dateien gemeistert und Du hast von der Macht der staging area, des branching und des merging Gebrauch gemacht.
+Bis hierher hast Du die meisten täglichen Kommandos und Arbeitsweisen gelernt, die Du brauchst um ein Git-Repository für Deine Quellcode-Kontrolle, zu benutzen. Du hast die grundlegenden Aufgaben des Nachverfolgens und Eincheckens von Dateien gemeistert und Du hast von der Macht der Staging-Area, des Branching und des Mergens Gebrauch gemacht.
 
 <!--Now you’ll explore a number of very powerful things that Git can do that you may not necessarily use on a day-to-day basis but that you may need at some point.-->
 
-Als nächstes werden wir einige sehr mächtige Werkzeuge besprechen, die Dir Git zur Verfügung stellt. Du wirst zwar nicht unbedingt jeden Tag verwenden, aber mit Sicherheit an einem bestimmten Punkt gute brauchen können.
+Als Nächstes werden wir einige sehr mächtige Werkzeuge besprechen, die Dir Git zur Verfügung stellt. Du wirst zwar nicht unbedingt jeden Tag verwenden, aber mit Sicherheit an einem bestimmten Punkt gut brauchen können.
 
 <!--## Revision Selection ##-->
 ## Revision Auswahl ##
@@ -21,18 +21,18 @@ Git erlaubt Dir, Commits auf verschiedenste Art und Weise auszuwählen. Diese si
 
 <!--You can obviously refer to a commit by the SHA-1 hash that it’s given, but there are more human-friendly ways to refer to commits as well. This section outlines the various ways you can refer to a single commit.-->
 
-Du kannst offensichtlich mithilfe des SHA-1 hash einen commit auswählen, aber es gibt auch Menschen freundlichere Methoden auf ein commit zu verweisen. Dieser Bereich skizziert die verschiedenen Wege, die man gehen kann um auf ein einzelnen commit zu referenzieren.
+Du kannst offensichtlich mithilfe des SHA-1-Hashes einen Commit auswählen, aber es gibt auch menschenfreundlichere Methoden, auf einen Commit zu verweisen. Dieser Bereich skizziert die verschiedenen Wege, die man gehen kann, um sich auf ein einzelnen Commit zu beziehen.
 
 <!--### Short SHA ###-->
 ### Abgekürztes SHA ###
 
 <!--Git is smart enough to figure out what commit you meant to type if you provide the first few characters, as long as your partial SHA-1 is at least four characters long and unambiguous — that is, only one object in the current repository begins with that partial SHA-1.-->
 
-Git ist intelligent genug, den richtigen commit herauszufinden, wenn man nur die ersten paar Zeichen angibt aber nur unter der Bedingung, dass der SHA-1 hash mindestens vier Zeichen lang und einzigartig ist — das bedeutet, dass es nur ein Objekt im derzeitigen Repository gibt, das mit diesem bestimmten SHA-1 hash beginnt.
+Git ist intelligent genug, den richtigen Commit herauszufinden, wenn man nur die ersten paar Zeichen angibt, aber nur unter der Bedingung, dass der SHA-1-Hash mindestens vier Zeichen lang und einzigartig ist — das bedeutet, dass es nur ein Objekt im derzeitigen Repository gibt, das mit diesem bestimmten SHA-1-Hash beginnt.
 
 <!--For example, to see a specific commit, suppose you run a `git log` command and identify the commit where you added certain functionality:-->
 
-Um zum Beispiel einen bestimmten commit zu sehen, kann man das `git log` Kommando ausführen und den commit identifizieren in dem man eine bestimmte Funktionalität hinzugefügt hat:
+Um zum Beispiel einen bestimmten Commit zu sehen, kann man das `git log` Kommando ausführen und den Commit identifizieren, indem man eine bestimmte Funktionalität hinzugefügt hat:
 
 	$ git log
 	commit 734713bc047d87bf7eac9674765ae793478c50d3
@@ -56,7 +56,7 @@ Um zum Beispiel einen bestimmten commit zu sehen, kann man das `git log` Kommand
 
 <!--In this case, choose `1c002dd....` If you `git show` that commit, the following commands are equivalent (assuming the shorter versions are unambiguous):-->
 
-In diesem Fall wählt man `1c002dd....` wenn Du diesen commit mit `git show` anzeigen lassen willst, die folgenden Kommandos sind äquivalent (vorausgesetzt die verkürzte Version ist einzigartig):
+In diesem Fall wählt man `1c002dd....`, wenn man diesen Commit mit `git show` anzeigen lassen will, die folgenden Kommandos sind äquivalent (vorausgesetzt die verkürzte Version ist einzigartig):
 
 	$ git show 1c002dd4b536e7479fe34593e72e6c6c1819e53b
 	$ git show 1c002dd4b536e7479f
@@ -64,7 +64,7 @@ In diesem Fall wählt man `1c002dd....` wenn Du diesen commit mit `git show` anz
 
 <!--Git can figure out a short, unique abbreviation for your SHA-1 values. If you pass `-\-abbrev-commit` to the `git log` command, the output will use shorter values but keep them unique; it defaults to using seven characters but makes them longer if necessary to keep the SHA-1 unambiguous:-->
 
-Git kann auch selber eine Kurzform für Deine einzigartigen SHA-1 Werte erzeugen. Wenn Du `--abbrev-commit` dem `git log` Kommando übergibst, wird es den kürzeren Wert benutzen diesen aber einzigartig halten; die Standardeinstellung sind sieben Zeichen aber es werden automatisch mehr benutzt wenn dies nötig ist um den SHA-1 hash eindeutig zu bezeichnen.
+Git kann auch selber eine Kurzform für Deine einzigartigen SHA-1-Werte erzeugen. Wenn Du `--abbrev-commit` dem `git log` Kommando übergibst, wird es den kürzeren Wert benutzen, diesen aber einzigartig halten; die Standardeinstellung sind sieben Zeichen, aber es werden automatisch mehr benutzt, wenn dies nötig ist, um den SHA-1-Hash eindeutig zu bezeichnen.
 
 	$ git log --abbrev-commit --pretty=oneline
 	ca82a6d changed the version number
@@ -73,40 +73,40 @@ Git kann auch selber eine Kurzform für Deine einzigartigen SHA-1 Werte erzeugen
 
 <!--Generally, eight to ten characters are more than enough to be unique within a project. One of the largest Git projects, the Linux kernel, is beginning to need 12 characters out of the possible 40 to stay unique.-->
 
-Generell kann man sagen das acht bis zehn Zeichen mehr als ausreichend in einem Projekt sind, um eindeutig zu bleiben. Eines der größten Git Projekte, der Linux Kernel, fängt langsam an 12 von maximal 40 Zeichen zu nutzen um eindeutig zu bleiben.
+Generell kann man sagen, dass acht bis zehn Zeichen mehr als ausreichend in einem Projekt sind, um eindeutig zu bleiben. Eines der größten Git-Projekte, der Linux-Kernel, fängt langsam an 12 von maximal 40 Zeichen zu nutzen, um eindeutig zu bleiben.
 
 <!--### A SHORT NOTE ABOUT SHA-1 ###-->
 ### EINE KURVE NOTIZ ÜBER SHA-1 ###
 
 <!--A lot of people become concerned at some point that they will, by random happenstance, have two objects in their repository that hash to the same SHA-1 value. What then?-->
 
-Eine Menge Leute machen sich Sorgen, dass ab einem zufälligen Punkt zwei Objekte im Repository vorhanden sind, die den gleichen SHA-1 hash wert haben. Was Dann?
+Eine Menge Leute machen sich Sorgen, dass ab einem zufälligen Punkt zwei Objekte im Repository vorhanden sind, die den gleichen SHA-1-Hashwert haben. Was dann?
 
 <!--If you do happen to commit an object that hashes to the same SHA-1 value as a previous object in your repository, Git will see the previous object already in your Git database and assume it was already written. If you try to check out that object again at some point, you’ll always get the data of the first object.-->
 
-Wenn es passiert, dass bei einem commit, ein Objekt mit dem gleichen SHA-1 hash Wert im Repository vorhanden ist, wird Git sehen, dass das vorherige Objekt bereits in der Datenbank vorhanden ist und davon ausgehen, dass es bereits geschrieben wurde. Wenn Du versuchst das Objekt später wieder auszuchecken wirst Du immer die Daten des ersten Objekts bekommen.
+Wenn es passiert, dass bei einem Commit, ein Objekt mit dem gleichen SHA-1-Hashwert im Repository vorhanden ist, wird Git sehen, dass das vorherige Objekt bereits in der Datenbank vorhanden ist und davon ausgehen, dass es bereits geschrieben wurde. Wenn Du versuchst, das Objekt später wieder auszuchecken, wirst Du immer die Daten des ersten Objekts bekommen.
 
 <!--However, you should be aware of how ridiculously unlikely this scenario is. The SHA-1 digest is 20 bytes or 160 bits. The number of randomly hashed objects needed to ensure a 50% probability of a single collision is about 2^80 (the formula for determining collision probability is `p = (n(n-1)/2) * (1/2^160))`. 2^80 is 1.2 x 10^24 or 1 million billion billion. That’s 1,200 times the number of grains of sand on the earth.-->
 
-Allerdings solltest Du Dir bewusst machen wie unglaublich unwahrscheinlich dieses Szenario ist. Die Länge des SHA-1 hashs beträgt 20 bytes oder 160bits. Die Anzahl der Objekte die benötigt werden, um eine 50% Chance einer Kollision zu haben, beträgt ungefähr 2^80 (die Formel zum berechnen der Kollisionswahrscheinlichkeit lautet ‚p = (n(n-1)/2) * (1/2^160))‘. 2^80 ist somit 1.2 x 10^24 oder eine Trilliarden. Das ist 1200 mal die Anzahl der Sandkörner die es auf der Erde gibt.
+Allerdings solltest Du Dir bewusst machen, wie unglaublich unwahrscheinlich dieses Szenario ist. Die Länge des SHA-1-Hashs beträgt 20 Bytes oder 160 Bits. Die Anzahl der Objekte, die benötigt werden, um eine 50% Chance einer Kollision zu haben, beträgt ungefähr 2^80 (die Formel zum Berechnen der Kollisionswahrscheinlichkeit lautet `p = (n(n-1)/2) * (1/2^160))`. 2^80 ist somit 1.2 x 10^24 oder eine Trilliarde. Das ist 1200 Mal so viel, wie es Sandkörner auf der Erde gibt.
 
 <!--Here’s an example to give you an idea of what it would take to get a SHA-1 collision. If all 6.5 billion humans on Earth were programming, and every second, each one was producing code that was the equivalent of the entire Linux kernel history (1 million Git objects) and pushing it into one enormous Git repository, it would take 5 years until that repository contained enough objects to have a 50% probability of a single SHA-1 object collision. A higher probability exists that every member of your programming team will be attacked and killed by wolves in unrelated incidents on the same night.-->
 
-Hier ist ein Beispiel welches Dir eine Vorstellung davon geben wird was nötig ist um in SHA-1 eine Kollision zu bekommen. Wenn alle 6,5 Milliarden Menschen auf der Erde Programmieren würden und jeder jede Sekunde Code schreiben würde, der der gesamten Geschichte des Linux Kernels (1 Millionen Git Objekte) entspricht und diesen dann in ein gigantisches Git Repository übertragen würden, würde es fünf Jahre dauern bis das Repository genügend Objekte hätte um eine 50% Wahrscheinlichkeit für eine einzige SHA-1 Kollision aufzuweisen. Es ist wahrscheinlicher das jedes Mitglied Deines Programmierer Teams, unabhängig voneinander, in einer Nacht von Wölfen angegriffen und getötet wird.
+Hier ist ein Beispiel, das Dir eine Vorstellung davon gibt, was nötig ist, um in SHA-1 eine Kollision zu bekommen. Wenn alle 6,5 Milliarden Menschen auf der Erde programmieren würden und jeder jede Sekunde Code schreiben würde, der der gesamten Geschichte des Linux-Kernels (1 Million Git-Objekte) entspricht, und diesen dann in ein gigantisches Git-Repository übertragen würde, würde es fünf Jahre dauern, bis das Repository genügend Objekte hätte, um eine 50% Wahrscheinlichkeit für eine einzige SHA-1-Kollision aufzuweisen. Es ist wahrscheinlicher, dass jedes Mitglied Deines Programmierer-Teams, unabhängig voneinander, in einer Nacht von Wölfen angegriffen und getötet wird.
 
 <!--### Branch References ###-->
 ### Branch Referenzen ###
 
 <!--The most straightforward way to specify a commit requires that it have a branch reference pointed at it. Then, you can use a branch name in any Git command that expects a commit object or SHA-1 value. For instance, if you want to show the last commit object on a branch, the following commands are equivalent, assuming that the `topic1` branch points to `ca82a6d`:-->
 
-Am direktesten kannst Du einen Commit spezifizieren, wenn eine Branch Referenz direkt auf ihn zeigt. In dem Fall kannst Du in allen Git Befehlen, die ein Commit Objekt oder einen SHA-1 Wert erwarten, statt dessen den Branch Namen verwenden. Wenn Du z.B. den letzten Commit in einem Branch sehen willst, sind die folgenden Befehle äquivalent (vorausgesetzt der `topic1` Branch zeigt auf den Commit `ca82a6d`):
+Am direktesten kannst Du einen Commit spezifizieren, wenn eine Branch-Referenz direkt auf ihn zeigt. In dem Fall kannst Du in allen Git-Befehlen, die ein Commit-Objekt oder einen SHA-1-Wert erwarten, stattdessen den Branch-Namen verwenden. Wenn Du z.B. den letzten Commit in einem Branch sehen willst, sind die folgenden Befehle äquivalent (vorausgesetzt der `topic1` Branch zeigt auf den Commit `ca82a6d`):
 
 	$ git show ca82a6dff817ec66f44342007202690a93763949
 	$ git show topic1
 
 <!--If you want to see which specific SHA a branch points to, or if you want to see what any of these examples boils down to in terms of SHAs, you can use a Git plumbing tool called `rev-parse`. You can see Chapter 9 for more information about plumbing tools; basically, `rev-parse` exists for lower-level operations and isn’t designed to be used in day-to-day operations. However, it can be helpful sometimes when you need to see what’s really going on. Here you can run `rev-parse` on your branch.-->
 
-Wenn Du sehen willst, auf welchen SHA-1 Wert ein Branch zeigt, oder wie unsere Beispiele intern in SHA-1 Werte übersetzt aussähen, kannst Du den Git Plumbing Befehl `rev-parse` verwenden. In Kapitel 9 werden wir genauer auf Plumbing Befehle eingehen. Kurz gesagt ist `rev-parse` als eine Low-Level Operation gedacht und nicht dafür, im tagtäglichen Gebrauch eingesetzt zu werden. Aber es kann manchmal hilfreich sein, wenn man wissen muss, was unter der Haube vor sich geht:
+Wenn Du sehen willst, auf welchen SHA-1-Wert ein Branch zeigt, oder wie unsere Beispiele intern in SHA-1-Werte übersetzt aussähen, kannst Du den Git-Plumbing-Befehl `rev-parse` verwenden. In Kapitel 9 werden wir genauer auf Plumbing-Befehle eingehen. Kurz gesagt ist `rev-parse` als eine Low-Level-Operation gedacht und nicht dafür, im tagtäglichen Gebrauch eingesetzt zu werden. Aber es kann manchmal hilfreich sein, wenn man wissen muss, was unter der Haube vor sich geht:
 
 	$ git rev-parse topic1
 	ca82a6dff817ec66f44342007202690a93763949
@@ -116,7 +116,7 @@ Wenn Du sehen willst, auf welchen SHA-1 Wert ein Branch zeigt, oder wie unsere B
 
 <!--One of the things Git does in the background while you’re working away is keep a reflog — a log of where your HEAD and branch references have been for the last few months.-->
 
-Eine andere Sache, die während Deiner täglichen Arbeit im Hintergrund passiert ist, dass Git ein sogenanntes Reflog führt, d.h. ein Log darüber, wohin Deine HEAD und Branch Referenzen in den letzten Monaten jeweils gezeigt haben.
+Eine andere Sache, die während Deiner täglichen Arbeit im Hintergrund passiert ist, dass Git ein sogenanntes Reflog führt, d.h. ein Log darüber, wohin Deine HEAD- und Branch-Referenzen in den letzten Monaten jeweils gezeigt haben.
 
 <!--You can see your reflog by using `git reflog`:-->
 
@@ -133,7 +133,7 @@ Du kannst das Reflog mit `git reflog` anzeigen:
 
 <!--Every time your branch tip is updated for any reason, Git stores that information for you in this temporary history. And you can specify older commits with this data, as well. If you want to see the fifth prior value of the HEAD of your repository, you can use the `@{n}` reference that you see in the reflog output:-->
 
-Immer dann, wenn ein Branch in irgendeiner Weise aktualisiert wird oder Du den aktuellen Branch wechselst, speichert Git diese Information ebenso im Reflog wie Commits und anderen Informationen. Wenn Du wissen willst, welches der fünfte Wert vor dem HEAD war, kannst Du die `@{n}` Referenz angeben, die Du in Reflog Ausgabe sehen kannst:
+Immer dann, wenn ein Branch in irgendeiner Weise aktualisiert wird oder Du den aktuellen Branch wechselst, speichert Git diese Information ebenso im Reflog wie Commits und anderen Informationen. Wenn Du wissen willst, welches der fünfte Wert vor dem HEAD war, kannst Du die `@{n}` Referenz angeben, die Du in Reflog-Ausgabe sehen kannst:
 
 	$ git show HEAD@{5}
 
@@ -170,13 +170,13 @@ Um Reflog Informationen in einem Format wie in `git log` anzeigen, kannst Du `gi
 
 <!--It’s important to note that the reflog information is strictly local — it’s a log of what you’ve done in your repository. The references won’t be the same on someone else’s copy of the repository; and right after you initially clone a repository, you’ll have an empty reflog, as no activity has occurred yet in your repository. Running `git show HEAD@{2.months.ago}` will work only if you cloned the project at least two months ago — if you cloned it five minutes ago, you’ll get no results.-->
 
-Es ist wichtig zu verstehen, dass das Reflog ausschließlich lokale Daten enthält. Es ist ein Log darüber, was Du in Deinem Repository getan hast, und es ist nie dasselbe wie in einem anderen Clone des selben Repositories. Direkt nachdem Du ein Repository geklont hast, ist das Reflog leer, weil noch keine weitere Aktivität stattgefunden hat. `git show HEAD@{2.months.ago}` funktioniert nur dann, wenn das Projekt mindestens zwei Monate alt ist – wenn Du es vor fünf Minuten erst geklont hast, erhältst Du keine Ergebnisse.
+Es ist wichtig zu verstehen, dass das Reflog ausschließlich lokale Daten enthält. Es ist ein Log darüber, was Du in Deinem Repository getan hast, und es ist nie dasselbe wie in einem anderen Klon des selben Repositorys. Direkt nachdem Du ein Repository geklont hast, ist das Reflog leer, weil noch keine weitere Aktivität stattgefunden hat. `git show HEAD@{2.months.ago}` funktioniert nur dann, wenn das Projekt mindestens zwei Monate alt ist – wenn Du es vor fünf Minuten erst geklont hast, erhältst Du keine Ergebnisse.
 
 <!--### Ancestry References ###-->
 ### Vorfahren Referenzen ###
 
-<!--The other main way to specify a commit is via its ancestry. If you place a `^` at the end of a reference, Git resolves it to mean the parent of that commit.-->
-Suppose you look at the history of your project:
+<!--The other main way to specify a commit is via its ancestry. If you place a `^` at the end of a reference, Git resolves it to mean the parent of that commit.
+Suppose you look at the history of your project:-->
 
 Außerdem kann man Commits über ihre Vorfahren spezifizieren. Wenn Du ein `^` ans Ende einer Referenz setzt, schlägt Git den direkten Vorfahren dieses Commits nach. Nehmen wir an, Deine Historie sieht so aus:
 
@@ -204,7 +204,7 @@ Du kannst jetzt den vorletzten Commit mit `HEAD^` referenzieren, d.h. „den dir
 
 <!--You can also specify a number after the `^` — for example, `d921970^2` means "the second parent of d921970." This syntax is only useful for merge commits, which have more than one parent. The first parent is the branch you were on when you merged, and the second is the commit on the branch that you merged in:-->
 
-Außerdem kannst Du nach dem `^` eine Zahl angeben. Beispielsweise heißt `d921970^2`: „der zweite Vorfahr von d921970“. Diese Syntax ist allerdings nur für Merge Commits nützlich, die mehr als einen Vorfahren haben. Der erste Vorfahr ist der Branch auf dem Du Dich beim Merge befandest, der zweite ist der Commit auf dem Branch den Du gemergt hast.
+Außerdem kannst Du nach dem `^` eine Zahl angeben. Beispielsweise heißt `d921970^2`: „der zweite Vorfahr von d921970“. Diese Syntax ist allerdings nur für Merge Commits nützlich, die mehr als einen Vorfahren haben. Der erste Vorfahr ist der Branch, auf dem Du Dich beim Merge befandest, der zweite ist der Commit auf dem Branch, den Du gemergt hast.
 
 	$ git show d921970^
 	commit 1c002dd4b536e7479fe34593e72e6c6c1819e53b
@@ -222,7 +222,7 @@ Außerdem kannst Du nach dem `^` eine Zahl angeben. Beispielsweise heißt `d9219
 
 <!--The other main ancestry specification is the `~`. This also refers to the first parent, so `HEAD~` and `HEAD^` are equivalent. The difference becomes apparent when you specify a number. `HEAD~2` means "the first parent of the first parent," or "the grandparent" — it traverses the first parents the number of times you specify. For example, in the history listed earlier, `HEAD~3` would be-->
 
-Eine andere Vorfahren Spezifikation ist `~`. Dies bezieht sich ebenfalls auf den ersten Vorfahren, d.h. `HEAD~` und `HEAD^` sind äquivalent. Einen Unterschied macht es allerdings, wenn Du außerdem eine Zahl angibst. `HEAD~2` bedeutet z.B. „der Vorfahr des Vorfahren von HEAD“ oder „der n-te Vorfahr von HEAD“. Beispielsweise würde `HEAD~3` in der obigen Historie auf den folgenden Commit zeigen:
+Eine andere Vorfahren-Spezifikation ist `~`. Dies bezieht sich ebenfalls auf den ersten Vorfahren, d.h. `HEAD~` und `HEAD^` sind äquivalent. Einen Unterschied macht es allerdings, wenn Du außerdem eine Zahl angibst. `HEAD~2` bedeutet z.B. „der Vorfahr des Vorfahren von HEAD“ oder „der n-te Vorfahr von HEAD“. Beispielsweise würde `HEAD~3` in der obigen Historie auf den folgenden Commit zeigen:
 
 	$ git show HEAD~3
 	commit 1c3618887afb5fbcbea25b7c013f4e2114448b8d
@@ -251,14 +251,14 @@ Du kannst diese Schreibweisen auch kombinieren und z.B. auf den zweiten Vorfahre
 
 <!--Now that you can specify individual commits, let’s see how to specify ranges of commits. This is particularly useful for managing your branches — if you have a lot of branches, you can use range specifications to answer questions such as, "What work is on this branch that I haven’t yet merged into my main branch?"-->
 
-Nachdem Du jetzt einzelne Commits spezifizieren kannst, schauen wir uns an, wie man auf Commit Reihen zugreift. Dies ist vor allem nützlich, um Branches zu verwalten, z.B. wenn man viele Branches hat und solche Fragen beantworten will wie „Welche Änderungen befinden sich in diesem Branch, die ich noch nicht in meinen Hauptbranch gemergt habe“.
+Nachdem Du jetzt einzelne Commits spezifizieren kannst, schauen wir uns an, wie man auf Commit-Reihen zugreift. Dies ist vor allem nützlich, um Branches zu verwalten, z.B. wenn man viele Branches hat und solche Fragen beantworten will wie „Welche Änderungen befinden sich in diesem Branch, die ich noch nicht in meinen Hauptbranch gemergt habe?“.
 
 <!--#### Double Dot ####-->
-#### Zwei-Punkte Syntax ####
+#### Zwei-Punkte-Syntax ####
 
 <!--The most common range specification is the double-dot syntax. This basically asks Git to resolve a range of commits that are reachable from one commit but aren’t reachable from another. For example, say you have a commit history that looks like Figure 6-1.-->
 
-Die gängigste Weise, Commit Reihen anzugeben, ist die Zwei-Punkte Notation. Allgemein gesagt evaluiert Git eine Reihe von Commits, die von einem Commit aus erreichbar sind, nicht aber von einem anderen (xxx ??? xxx). Nehmen wir z.B. an, Du hättest eine Commit Historie wie die folgende (Bild 6-1).
+Die gängigste Weise, Commit-Reihen anzugeben, ist die Zwei-Punkte-Notation. Allgemein gesagt evaluiert Git eine Reihe von Commits, die von einem Commit aus erreichbar sind, nicht aber von einem anderen (xxx ??? xxx). Nehmen wir z.B. an, Du hättest eine Commit-Historie wie die folgende (Bild 6-1).
 
 <!--Figure 6-1. Example history for range selection.-->
 
@@ -266,7 +266,7 @@ Insert 18333fig0601.png
 
 <!--You want to see what is in your experiment branch that hasn’t yet been merged into your master branch. You can ask Git to show you a log of just those commits with `master..experiment` — that means "all commits reachable by experiment that aren’t reachable by master." For the sake of brevity and clarity in these examples, I’ll use the letters of the commit objects from the diagram in place of the actual log output in the order that they would display:-->
 
-Du willst jetzt herausfinden, welche Änderungen in Deinem `experiment` Branch sind, die noch nicht in den `master` Branch gemergt wurden. Dann kannst Du ein Log dieser Commits mit `master..experiment` anzeigen, d.h. „alle Commits, die von `experiment` aus erreichbar sind, aber nicht von `master`“. Um die folgenden Beispiele ein bisschen abzukürzen und deutlicher zu machen, verwende ich für die Commit Objekte die Buchstaben aus dem Diagramm anstelle der tatsächlichen Log Ausgabe:
+Du willst jetzt herausfinden, welche Änderungen in Deinem `experiment`-Branch sind, die noch nicht in den `master`-Branch gemergt wurden. Dann kannst Du ein Log dieser Commits mit `master..experiment` anzeigen, d.h. „alle Commits, die von `experiment` aus erreichbar sind, aber nicht von `master`“. Um die folgenden Beispiele ein bisschen abzukürzen und deutlicher zu machen, verwende ich für die Commit-Objekte die Buchstaben aus dem Diagramm anstelle der tatsächlichen Log Ausgabe:
 
 	$ git log master..experiment
 	D
@@ -282,21 +282,21 @@ Wenn Du allerdings – anders herum – diejenigen Commits anzeigen willst, die
 
 <!--This is useful if you want to keep the `experiment` branch up to date and preview what you’re about to merge in. Another very frequent use of this syntax is to see what you’re about to push to a remote:-->
 
-Dies ist nützlich, wenn Du vorhast, den `experiment` Branch zu aktualisieren, und anzeigen willst, was Du dazu mergen wirst. Oder wenn Du vorhast, in ein Remote Repository zu pushen und sehen willst, welche Commits betroffen sind:
+Dies ist nützlich, wenn Du vorhast, den `experiment`-Branch zu aktualisieren, und anzeigen willst, was Du dazu mergen wirst. Oder wenn Du vorhast, in ein Remote-Repository zu pushen und sehen willst, welche Commits betroffen sind:
 
 	$ git log origin/master..HEAD
 
 <!--This command shows you any commits in your current branch that aren’t in the `master` branch on your `origin` remote. If you run a `git push` and your current branch is tracking `origin/master`, the commits listed by `git log origin/master..HEAD` are the commits that will be transferred to the server.-->
 <!--You can also leave off one side of the syntax to have Git assume HEAD. For example, you can get the same results as in the previous example by typing `git log origin/master..` — Git substitutes HEAD if one side is missing.-->
 
-Dieser Befehl zeigt Dir alle Commits im gegenwärtigen, lokalen Branch, die noch nicht im `master` Branch des `origin` Repositories sind. D.h., der Befehl listet diejenigen Commits auf, die auf den Server transferiert würden, wenn Du `git push` benutzt und der aktuelle Branch `origin/master` trackt. Du kannst mit dieser Syntax außerdem eine Seite der beiden Punkte leer lassen. Git nimmt dann an, Du meinst an dieser Stelle HEAD. Z.B. kannst Du dieselben Commits wie im vorherigen Beispiel auch mit `git log origin/master..` anzeigen lassen. Git fügt dann HEAD auf der rechten Seite ein.
+Dieser Befehl zeigt Dir alle Commits im gegenwärtigen, lokalen Branch, die noch nicht im `master`-Branch des `origin` Repositories sind. D.h., der Befehl listet diejenigen Commits auf, die auf den Server transferiert würden, wenn Du `git push` benutzt und der aktuelle Branch `origin/master` trackt. Du kannst mit dieser Syntax außerdem eine Seite der beiden Punkte leer lassen. Git nimmt dann an, Du meinst an dieser Stelle HEAD. Z.B. kannst Du dieselben Commits wie im vorherigen Beispiel auch mit `git log origin/master..` anzeigen lassen. Git fügt dann HEAD auf der rechten Seite ein.
 
 <!--#### Multiple Points ####-->
 #### Mehrfache Punkte (xxx) ####
 
 <!--The double-dot syntax is useful as a shorthand; but perhaps you want to specify more than two branches to indicate your revision, such as seeing what commits are in any of several branches that aren’t in the branch you’re currently on. Git allows you to do this by using either the `^` character or `-\-not` before any reference from which you don’t want to see reachable commits. Thus these three commands are equivalent:-->
 
-Die Zwei-Punkte Syntax ist eine nützliche Abkürzung, aber möglicherweise willst Du mehr als nur zwei Branches angeben, um z.B. herauszufinden, welche Commits in einem beliebigen anderen Branch enthalten sind, ausgenommen in demjenigen, auf dem Du Dich gerade befindest. Dazu kannst Du in Git das `^` Zeichen oder `--not` verwenden, um Commits auszuschließen, die von den angegebenen Referenzen aus erreichbar sind. D.h., die folgenden drei Befehle sind äquivalent:
+Die Zwei-Punkte-Syntax ist eine nützliche Abkürzung, aber möglicherweise willst Du mehr als nur zwei Branches angeben, um z.B. herauszufinden, welche Commits in einem beliebigen anderen Branch enthalten sind, ausgenommen in demjenigen, auf dem Du Dich gerade befindest. Dazu kannst Du in Git das `^` Zeichen oder `--not` verwenden, um Commits auszuschließen, die von den angegebenen Referenzen aus erreichbar sind. D.h., die folgenden drei Befehle sind äquivalent:
 
 	$ git log refA..refB
 	$ git log ^refA refB
@@ -304,7 +304,7 @@ Die Zwei-Punkte Syntax ist eine nützliche Abkürzung, aber möglicherweise will
 
 <!--This is nice because with this syntax you can specify more than two references in your query, which you cannot do with the double-dot syntax. For instance, if you want to see all commits that are reachable from `refA` or `refB` but not from `refC`, you can type one of these:-->
 
-Das ist praktisch, weil Du auf diese Weise mehr als nur zwei Referenzen angeben kannst, was mit der Zwei-Punkte Notation nicht geht. Wenn Du beispielsweise alle Commits sehen willst, die von `refA` oder `refB` erreichbar sind, nicht aber von `refC`, dann kannst Du folgende (äquivalente) Befehle benutzen:
+Das ist praktisch, weil Du auf diese Weise mehr als nur zwei Referenzen angeben kannst, was mit der Zwei-Punkte-Notation nicht geht. Wenn Du beispielsweise alle Commits sehen willst, die von `refA` oder `refB` erreichbar sind, nicht aber von `refC`, dann kannst Du folgende (äquivalente) Befehle benutzen:
 
 	$ git log refA refB ^refC
 	$ git log refA refB --not refC
@@ -319,7 +319,7 @@ Damit hast Du ein sehr mächtiges System von Abfragen zur Verfügung, mit denen
 <!--The last major range-selection syntax is the triple-dot syntax, which specifies all the commits that are reachable by either of two references but not by both of them. Look back at the example commit history in Figure 6-1.-->
 <!--If you want to see what is in `master` or `experiment` but not any common references, you can run-->
 
-Die letzte wichtige Syntax, mit der man Commit Reihen spezifizieren kann, ist die Drei-Punkte Syntax, die alle Commits anzeigt, die in einer der beiden Referenzen enthalten sind, aber nicht in beiden. Schau Dir noch mal die Commit Historie in Bild 6-1- an. Wenn Du diejenigen Commits anzeigen willst, die in den `master` und `experiment` Branches, nicht aber in beiden Branches gleichzeitig  enthalten sind, dann kannst Du folgendes tun:
+Die letzte wichtige Syntax, mit der man Commit-Reihen spezifizieren kann, ist die Drei-Punkte-Syntax, die alle Commits anzeigt, die in einer der beiden Referenzen enthalten sind, aber nicht in beiden. Schau Dir noch mal die Commit Historie in Bild 6-1 an. Wenn Du diejenigen Commits anzeigen willst, die in den `master`- und `experiment`-Branches, nicht aber in beiden Branches gleichzeitig enthalten sind, dann kannst Du folgendes tun:
 
 	$ git log master...experiment
 	F
@@ -329,7 +329,7 @@ Die letzte wichtige Syntax, mit der man Commit Reihen spezifizieren kann, ist di
 
 <!--Again, this gives you normal `log` output but shows you only the commit information for those four commits, appearing in the traditional commit date ordering.-->
 
-Dies gibt Dir wiederum ein normale `log` Ausgabe, aber zeigt nur die Informationen dieser vier Commits – wie üblich sortiert nach dem Commit Datum.
+Dies gibt Dir wiederum ein normale `log` Ausgabe, aber zeigt nur die Informationen dieser vier Commits – wie üblich sortiert nach dem Commit-Datum.
 
 <!--A common switch to use with the `log` command in this case is `-\-left-right`, which shows you which side of the range each commit is in. This helps make the data more useful:-->
 
@@ -351,7 +351,7 @@ Mit diesen Hilfsmitteln kannst Du noch einfacher und genauer angeben, welche Com
 <!--Git comes with a couple of scripts that make some command-line tasks easier. Here, you’ll look at a few interactive commands that can help you easily craft your commits to include only certain combinations and parts of files. These tools are very helpful if you modify a bunch of files and then decide that you want those changes to be in several focused commits rather than one big messy commit. This way, you can make sure your commits are logically separate changesets and can be easily reviewed by the developers working with you.-->
 <!--If you run `git add` with the `-i` or `-\-interactive` option, Git goes into an interactive shell mode, displaying something like this:-->
 
-Git umfasst eine Reihe von Skripten, die so manche Aufgabe auf der Kommandozeile leichter machen. Im folgenden schauen wir uns einige interaktive Befehle an, die dabei hilfreich sein können, wenn man Änderungen in vielen Dateien vorgenommen hat, aber nur einige Änderungen gezielt committen will – nicht alles auf einmal in einem riesigen Commit. Auf diese Weise kann man Commits logisch gruppieren und macht es anderen Entwicklern damit leichter, sie zu verstehen. Wenn Du `git add` mit der `-i` oder `--interactive` Option verwendest, geht Git in einen interaktiven Shell Modus, der in etwa wie folgt aussieht:
+Git umfasst eine Reihe von Skripten, die so manche Aufgabe auf der Kommandozeile leichter machen. Im Folgenden schauen wir uns einige interaktive Befehle an, die dabei hilfreich sein können, wenn man Änderungen in vielen Dateien vorgenommen hat, aber nur einige Änderungen gezielt committen will – nicht alles auf einmal in einem riesigen Commit. Auf diese Weise kann man Commits logisch gruppieren und macht es anderen Entwicklern damit leichter, sie zu verstehen. Wenn Du `git add` mit der `-i` oder `--interactive` Option verwendest, geht Git in einen interaktiven Shell-Modus, der in etwa wie folgt aussieht:
 
 	$ git add -i
 	           staged     unstaged path
@@ -366,7 +366,7 @@ Git umfasst eine Reihe von Skripten, die so manche Aufgabe auf der Kommandozeile
 
 <!--You can see that this command shows you a much different view of your staging area — basically the same information you get with `git status` but a bit more succinct and informative. It lists the changes you’ve staged on the left and unstaged changes on the right.-->
 
-Wie Du siehst zeigt dieser Befehl eine andere Ansicht der Staging Area an – im wesentlichen also die Information, die Du auch mit `git status` erhältst, aber anders formatiert, ein bisschen kürzer (xxx succinct? xxx) und informativer. Sie listet alles Änderungen, die in der Staging Area enthalten sind, auf der linken Seite, und alle anderen Änderungen auf der rechten Seite.
+Wie Du siehst, zeigt dieser Befehl eine andere Ansicht der Staging-Area an – im Wesentlichen also die Information, die Du auch mit `git status` erhältst, aber anders formatiert, kurz und knapp, und informativer. Sie listet alle Änderungen, die in der Staging-Area enthalten sind, auf der linken Seite, und alle anderen Änderungen auf der rechten Seite.
 
 <!--After this comes a Commands section. Here you can do a number of things, including staging files, unstaging files, staging parts of files, adding untracked files, and seeing diffs of what has been staged.-->
 
@@ -377,7 +377,7 @@ Danach folgt eine Liste von Befehlen wie, u.a., Dateien ganz oder teilweise stag
 
 <!--If you type `2` or `u` at the `What now>` prompt, the script prompts you for which files you want to stage:-->
 
-Wenn Du am `What now>` Prompt `2` oder `u` eingibst, wirst Du als nächstes gefragt, welche Dateien Du stagen willst:
+Wenn Du am `What now>` Prompt `2` oder `u` eingibst, wirst Du als Nächstes gefragt, welche Dateien Du stagen willst:
 
 	What now> 2
 	           staged     unstaged path
@@ -399,7 +399,7 @@ Um z.B. die TODO und index.html Dateien zu stagen, gibst Du die jeweiligen Zahle
 
 <!--The `*` next to each file means the file is selected to be staged. If you press Enter after typing nothing at the `Update>>` prompt, Git takes anything selected and stages it for you:-->
 
-Das `*` neben den Dateinamen bedeutet, dass die Datei ausgewählt ist und zur Staging Area hinzugefügt werden wird, sobald Du (bei einem sonst leeren `Update>>` Prompt) Enter drückst:
+Das `*` neben den Dateinamen bedeutet, dass die Datei ausgewählt ist und zur Staging-Area hinzugefügt werden wird, sobald Du (bei einem sonst leeren `Update>>` Prompt) Enter drückst:
 
 	Update>>
 	updated 2 paths
@@ -415,7 +415,7 @@ Das `*` neben den Dateinamen bedeutet, dass die Datei ausgewählt ist und zur St
 
 <!--Now you can see that the TODO and index.html files are staged and the simplegit.rb file is still unstaged. If you want to unstage the TODO file at this point, you use the `3` or `r` (for revert) option:-->
 
-Du kannst sehen, dass die TODO und index.html Dateien jetzt gestaged sind, während simplegit.rb immer noch ungestaged ist. Wenn Du die TODO unstagen willst, kannst Du die Option `3` oder `r` (für revert) nutzen:
+Du kannst sehen, dass die TODO und index.html Dateien jetzt gestaget sind, während simplegit.rb immer noch ungestaget ist. Wenn Du die TODO unstagen willst, kannst Du die Option `3` oder `r` (für revert) nutzen:
 
 	*** Commands ***
 	  1: status     2: update      3: revert     4: add untracked
@@ -435,7 +435,7 @@ Du kannst sehen, dass die TODO und index.html Dateien jetzt gestaged sind, währ
 
 <!--Looking at your Git status again, you can see that you’ve unstaged the TODO file:-->
 
-Wenn Du wiederum Deinen Git status ansiehst, kannst Du sehen dass Du die TODO ungestaged hast.
+Wenn Du wiederum Deinen Git-Status ansiehst, kannst Du sehen, dass Du die TODO ungestaget hast.
 
 	*** Commands ***
 	  1: status     2: update      3: revert     4: add untracked
@@ -448,7 +448,7 @@ Wenn Du wiederum Deinen Git status ansiehst, kannst Du sehen dass Du die TODO un
 
 <!--To see the diff of what you’ve staged, you can use the `6` or `d` (for diff) command. It shows you a list of your staged files, and you can select the ones for which you would like to see the staged diff. This is much like specifying `git diff -\-cached` on the command line:-->
 
-Um einen Diff dessen zu sehen, das Du gestaged hast, kannst Du den Befehl `6` oder `d` (für diff) nutzen. Dieser zeigt Dir eine Liste der gestageden Dateien, und Du kannst diejenigen auswählen, von denen Du den gestageden Diff sehen willst. Dies ähnelt sehr dem Befehl `git diff --cached` auf der Kommandozeile.
+Um einen Diff dessen zu sehen, das Du gestaget hast, kannst Du den Befehl `6` oder `d` (für diff) nutzen. Dieser zeigt Dir eine Liste der gestageten Dateien, und Du kannst diejenigen auswählen, von denen Du den gestageten Diff sehen willst. Dies ähnelt sehr dem Befehl `git diff --cached` auf der Kommandozeile.
 
 	*** Commands ***
 	  1: status     2: update      3: revert     4: add untracked
@@ -472,14 +472,14 @@ Um einen Diff dessen zu sehen, das Du gestaged hast, kannst Du den Befehl `6` od
 
 <!--With these basic commands, you can use the interactive add mode to deal with your staging area a little more easily.-->
 
-Mit diesen grundlegenden Befehlen kannst Du den interaktiven add Modus nutzen um Dir den Umgang mit Deiner Staging area etwas zu erleichtern.
+Mit diesen grundlegenden Befehlen kannst Du den interaktiven add Modus nutzen, um Dir den Umgang mit Deiner Staging-Area etwas zu erleichtern.
 
 <!--### Staging Patches ###-->
 ### Patches stagen ###
 
 <!--It’s also possible for Git to stage certain parts of files and not the rest. For example, if you make two changes to your simplegit.rb file and want to stage one of them and not the other, doing so is very easy in Git. From the interactive prompt, type `5` or `p` (for patch). Git will ask you which files you would like to partially stage; then, for each section of the selected files, it will display hunks of the file diff and ask if you would like to stage them, one by one:-->
 
-Es ist für Git auch möglich bestimmte Teile einer Datei zu stagen und nicht den Rest. Wenn Du z. B. 2 Veränderungen an der simplegit.rb machst und eine davon stagen willst und die andere nicht, ist dies sehr einfach in Git möglich. Wähle `5` oder `p` (für patch) auf dem interactive prompt. Git wird Dich fragen welche Dateien Du teilweise stagen willst; dann wird es für jeden Abschnitt der gewählten Dateien diff hunks ausgeben und Dich jeweils einzeln fragen ob Du sie stagen willst.
+Es ist für Git auch möglich, bestimmte Teile einer Datei zu stagen und nicht den Rest. Wenn Du z.B. 2 Veränderungen an der simplegit.rb machst und eine davon stagen willst und die andere nicht, ist dies sehr einfach in Git möglich. Wähle `5` oder `p` (für patch) auf dem interaktiven Prompt. Git wird Dich fragen, welche Dateien Du teilweise stagen willst; dann wird es für jeden Abschnitt der gewählten Dateien Diff-Ausschnitte ausgeben und Dich jeweils einzeln fragen, ob Du sie stagen willst.
 
 	diff --git a/lib/simplegit.rb b/lib/simplegit.rb
 	index dd5ecc4..57399e0 100644
@@ -498,7 +498,7 @@ Es ist für Git auch möglich bestimmte Teile einer Datei zu stagen und nicht de
 
 <!--You have a lot of options at this point. Typing `?` shows a list of what you can do:-->
 
-Du hast an diesem Punkt viele Options. Tippe `?` ein um eine Liste der Möglichkeiten zu bekommen:
+Du hast an diesem Punkt viele Optionen. Tippe `?` ein, um eine Liste der Möglichkeiten zu bekommen:
 
 	Stage this hunk [y,n,a,d,/,j,J,g,e,?]? ?
 	y - stage this hunk
@@ -517,7 +517,7 @@ Du hast an diesem Punkt viele Options. Tippe `?` ein um eine Liste der Möglichk
 
 <!--Generally, you’ll type `y` or `n` if you want to stage each hunk, but staging all of them in certain files or skipping a hunk decision until later can be helpful too. If you stage one part of the file and leave another part unstaged, your status output will look like this:-->
 
-Im Allgemeinen, wirst Du `y` oder `n` nutzen wenn Du jeden Hunk stagen willst, aber alle Hunks in bestimmten Dateien zu stagen oder die Entscheidung für einen Hunk auf später zu verschieben kann auch sehr hilfreich sein. Wenn Du nur einen Teil der Datei stagest und den anderen ungestaged lässt, sieht Deine Status-Ausgabe in etwa so aus:
+Im Allgemeinen, wirst Du `y` oder `n` nutzen, wenn Du jeden Ausschnitt stagen willst, aber alle Ausschnitte in bestimmten Dateien zu stagen oder die Entscheidung für einen Ausschnitt auf später zu verschieben kann auch sehr hilfreich sein. Wenn Du nur einen Teil der Datei stagest und den anderen ungestaget lässt, sieht Deine Status-Ausgabe in etwa so aus:
 
 	What now> 1
 	           staged     unstaged path
@@ -527,11 +527,11 @@ Im Allgemeinen, wirst Du `y` oder `n` nutzen wenn Du jeden Hunk stagen willst, a
 
 <!--The status of the simplegit.rb file is interesting. It shows you that a couple of lines are staged and a couple are unstaged. You’ve partially staged this file. At this point, you can exit the interactive adding script and run `git commit` to commit the partially staged files.-->
 
-Der Status der simplegit.rb ist interessant. Er zeigt Dir, dass ein paar Zeilen gestagd und ein paar ungestaged sind. Du hast diese Datei teilweise gestaged. An dieser Stelle kannst Du das interaktive add Skript verlassen und `git commit` ausführen, um die teilweise gestageden Dateien zu commiten.
+Der Status der simplegit.rb ist interessant. Er zeigt Dir, dass ein paar Zeilen gestaget und ein paar ungestaget sind. Du hast diese Datei teilweise gestaget. An dieser Stelle kannst Du das interaktive Hinzufüge-Skript verlassen und `git commit` ausführen, um die teilweise gestageten Dateien zu commiten.
 
 <!--Finally, you don’t need to be in interactive add mode to do the partial-file staging — you can start the same script by using `git add -p` or `git add -\-patch` on the command line.-->
 
-Letztendlich musst Du nicht den interactive add Modus nutzen um Dateien teilweise zu stagen – Du kannst das gleiche Skript starten in dem Du `git add -p` oder `git add --patch` auf der Kommandozeile eingibst.
+Letztendlich musst Du nicht den interaktiven Hinzufüge-Modus nutzen, um Dateien teilweise zu stagen – Du kannst das gleiche Skript starten, indem Du `git add -p` oder `git add --patch` auf der Kommandozeile eingibst.
 
 <!--## Stashing ##-->
 ## Stashen ##
@@ -542,14 +542,14 @@ Während man an einer bestimmten Funktion eines Projekts arbeitet, ist es oft so
 
 <!--Stashing takes the dirty state of your working directory — that is, your modified tracked files and staged changes — and saves it on a stack of unfinished changes that you can reapply at any time.-->
 
-Beim Stashen werden die aus Deinem Arbeitsverzeichnis noch nicht committeten Änderungen – also Deine geänderten beobachteten Dateien und die in der Staging Area enthaltenen Dateien – in einem Stack voller unfertiger Änderungen gespeichert. Diese kannst Du dann jederzeit wieder vom Stack holen und auf Dein Arbeitsverzeichnis anwenden.
+Beim Stashen werden die aus Deinem Arbeitsverzeichnis noch nicht committeten Änderungen – also Deine geänderten beobachteten Dateien und die in der Staging-Area enthaltenen Dateien – in einem Stack voller unfertiger Änderungen gespeichert. Diese kannst Du dann jederzeit wieder vom Stack holen und auf Dein Arbeitsverzeichnis anwenden.
 
 <!--### Stashing Your Work ###-->
 ### Stash verwenden ###
 
 <!--To demonstrate, you’ll go into your project and start working on a couple of files and possibly stage one of the changes. If you run `git status`, you can see your dirty state:-->
 
-Um dies zu demonstrieren, gehst Du in Dein Projekt und beginnst an ein paar Dateien zu arbeiten und merkst ein paar dieser Änderungen in der Staging Area vor. Wenn Du den Befehl `git status` ausführst, siehst Du, dass sich einige Dateien seit dem letzen Commit verändert haben.
+Um dies zu demonstrieren, gehst Du in Dein Projekt und beginnst an ein paar Dateien zu arbeiten und merkst ein paar dieser Änderungen in der Staging-Area vor. Wenn Du den Befehl `git status` ausführst, siehst Du, dass sich einige Dateien seit dem letzen Commit verändert haben.
 
 	$ git status
 	# On branch master
@@ -566,7 +566,7 @@ Um dies zu demonstrieren, gehst Du in Dein Projekt und beginnst an ein paar Date
 
 <!--Now you want to switch branches, but you don’t want to commit what you’ve been working on yet; so you’ll stash the changes. To push a new stash onto your stack, run `git stash`:-->
 
-Jetzt kommt der Zeitpunkt an dem Du den aktuellen Branch wechseln möchtest. Allerdings willst Du den aktuellen Zustand auch nicht committen, da Deine Arbeit noch nicht ganz fertiggestellt ist. Darum legst Du Deine Änderungen jetzt in einem Stash ab. Um diesen neuen Stash auf dem Stack abzulegen, verwendest Du den Befehl `git stash`:
+Jetzt kommt der Zeitpunkt, an dem Du den aktuellen Branch wechseln möchtest. Allerdings willst Du den aktuellen Zustand auch nicht committen, da Deine Arbeit noch nicht ganz fertiggestellt ist. Darum legst Du Deine Änderungen jetzt in einem Stash ab. Um diesen neuen Stash auf dem Stack abzulegen, verwendest Du den Befehl `git stash`:
 
 	$ git stash
 	Saved working directory and index state \
@@ -576,7 +576,7 @@ Jetzt kommt der Zeitpunkt an dem Du den aktuellen Branch wechseln möchtest. All
 
 <!--Your working directory is clean:-->
 
-In Deinem Arbeitsverzeichnis befinden sich jetzt keine geänderten Dateien mehr und die Staging Area ist auch leer:
+In Deinem Arbeitsverzeichnis befinden sich jetzt keine geänderten Dateien mehr und die Staging-Area ist auch leer:
 
 	$ git status
 	# On branch master
@@ -593,7 +593,7 @@ In diesem Zustand, kannst Du in beliebig andere Branches wechseln und an etwas a
 
 <!--In this case, two stashes were done previously, so you have access to three different stashed works. You can reapply the one you just stashed by using the command shown in the help output of the original stash command: `git stash apply`. If you want to apply one of the older stashes, you can specify it by naming it, like this: `git stash apply stash@{2}`. If you don’t specify a stash, Git assumes the most recent stash and tries to apply it:-->
 
-In diesem Beispiel waren bereits zwei Stashes auf dem Stack vorhanden. Sie wurden zu einem früheren Zeitpunkt gespeichert. Dir stehen jetzt also drei verschiedene Stashes auf dem Stack zur Verfügung. Mit dem Befehl `git stash apply` kannst Du die zuletzt gestashten Änderungen in Deinem Arbeitsverzeichnis wiederherstellen. Git zeigt diesen Befehlsaufruf auch bei Ausführen des Befehls `git stash` als Hilfestellung an. Wenn Du einen der älteren Stashes auf Dein Arbeitsverzeichnis anwenden willst, kannst Du den entsprechenden Stashnamen an den Befehl anhängen: `git stash apply stash@{2}`. Wie Du bereits gesehen hast, verwendet Git die zuletzt gestashten Änderungen und versucht diese im Arbeitsverzeichnis wiederherzuellen, wenn der Stashname nicht angegeben wird:
+In diesem Beispiel waren bereits zwei Stashes auf dem Stack vorhanden. Sie wurden zu einem früheren Zeitpunkt gespeichert. Dir stehen jetzt also drei verschiedene Stashes auf dem Stack zur Verfügung. Mit dem Befehl `git stash apply` kannst Du die zuletzt gestashten Änderungen in Deinem Arbeitsverzeichnis wiederherstellen. Git zeigt diesen Befehlsaufruf auch bei Ausführen des Befehls `git stash` als Hilfestellung an. Wenn Du einen der älteren Stashes auf Dein Arbeitsverzeichnis anwenden willst, kannst Du den entsprechenden Stashnamen an den Befehl anhängen: `git stash apply stash@{2}`. Wie Du bereits gesehen hast, verwendet Git die zuletzt gestashten Änderungen und versucht diese im Arbeitsverzeichnis wiederherzustellen, wenn der Stashname nicht angegeben wird:
 
 	$ git stash apply
 	# On branch master
@@ -610,7 +610,7 @@ Wie Du sehen kannst, stellt Git die Dateien wieder her, die Du in einem Stash ge
 
 <!--The changes to your files were reapplied, but the file you staged before wasn’t restaged. To do that, you must run the `git stash apply` command with a `-\-index` option to tell the command to try to reapply the staged changes. If you had run that instead, you’d have gotten back to your original position:-->
 
-Die Änderungen an den Dateien wurden in Deinem Arbeitsverzeichnis wiederhergestellt. Allerdings ist die Datei, die beim Stashen in der Staging Area vorhanden war, nicht automatisch wieder in die Staging Area gewandert. Wenn Du die Option `--index` an den Befehl `git stash apply` anhängst, wird Git versuchen, die Dateien wieder zu stagen. Wenn Du diesen Befehl angewandt hättest, wäre Dein Arbeitsverzeichnis und Deine Staging Area im exakt gleichen Zustand, wie vor dem Stashen:
+Die Änderungen an den Dateien wurden in Deinem Arbeitsverzeichnis wiederhergestellt. Allerdings ist die Datei, die beim Stashen in der Staging-Area vorhanden war, nicht automatisch wieder in die Staging-Area gewandert. Wenn Du die Option `--index` an den Befehl `git stash apply` anhängst, wird Git versuchen, die Dateien wieder zu stagen. Wenn Du diesen Befehl angewandt hättest, wäre Dein Arbeitsverzeichnis und Deine Staging-Area im exakt gleichen Zustand, wie vor dem Stashen:
 
 	$ git stash apply --index
 	# On branch master
@@ -627,7 +627,7 @@ Die Änderungen an den Dateien wurden in Deinem Arbeitsverzeichnis wiederhergest
 
 <!--The apply option only tries to apply the stashed work — you continue to have it on your stack. To remove it, you can run `git stash drop` with the name of the stash to remove:-->
 
-Mit der Option `apply` wird nur versucht die Änderungen wiederherzustellen. Der Stash an sich bleibt weiterhin auf dem Stack vorhanden. Um diesen zu entfernen kannst Du den Befehl `git stash drop` zusammen mit dem Namen des Stashes anwenden:
+Mit der Option `apply` wird nur versucht die Änderungen wiederherzustellen. Der Stash an sich bleibt weiterhin auf dem Stack vorhanden. Um diesen zu entfernen, kannst Du den Befehl `git stash drop` zusammen mit dem Namen des Stashes anwenden:
 
 	$ git stash list
 	stash@{0}: WIP on master: 049d078 added the index file
@@ -720,11 +720,11 @@ Nach Eingabe dieses Befehls wird der Texteditor mit dem Inhalt der letzten Commi
 
 <!--If you’ve committed and then you want to change the snapshot you committed by adding or changing files, possibly because you forgot to add a newly created file when you originally committed, the process works basically the same way. You stage the changes you want by editing a file and running `git add` on it or `git rm` to a tracked file, and the subsequent `git commit -\-amend` takes your current staging area and makes it the snapshot for the new commit.-->
 
-Wenn Du Deine Änderungen bereits eingecheckt hast und den Schnappschuss nachträglich durch Hinzufügen oder Ändern von Dateien noch einmal ändern möchtest, läuft das im Prinzip auf die gleiche Art und Weise ab. Meist kommt so etwas vor, weil man vergessen hat eine neu erstellte Datei zu stagen. Wenn so etwas passiert kannst Du folgendes machen: Führe Deine gewünschte Änderungen durch Ändern oder Hinzufügen einer Datei aus und stage dieses Ergebnis mit dem Befehl `git add`. Alternativ kannst Du auch mit dem Befehl `git rm` eine Datei aus dem Repository entfernen. Wenn die Staging Area Dein gewünschtes Ergebnis enthält, führst Du einfach den Befehl  `git commit --amend` aus. Der neue Commit enthält nun die Änderungen aus dem alten Commit plus die Änderungen aus Deiner Staging Area.
+Wenn Du Deine Änderungen bereits eingecheckt hast und den Schnappschuss nachträglich durch Hinzufügen oder Ändern von Dateien noch einmal ändern möchtest, läuft das im Prinzip auf die gleiche Art und Weise ab. Meist kommt so etwas vor, weil man vergessen hat, eine neu erstellte Datei zu stagen. Wenn so etwas passiert, kannst Du Folgendes machen: Führe Deine gewünschte Änderungen durch Ändern oder Hinzufügen einer Datei aus und stage dieses Ergebnis mit dem Befehl `git add`. Alternativ kannst Du auch mit dem Befehl `git rm` eine Datei aus dem Repository entfernen. Wenn die Staging-Area Dein gewünschtes Ergebnis enthält, führst Du einfach den Befehl  `git commit --amend` aus. Der neue Commit enthält nun die Änderungen aus dem alten Commit plus die Änderungen aus Deiner Staging-Area.
 
 <!--You need to be careful with this technique because amending changes the SHA-1 of the commit. It’s like a very small rebase — don’t amend your last commit if you’ve already pushed it.-->
 
-Mit dem Befehl `--amend` sollte man vorsichtig umgehen, weil mit jeder nachträglichen Modifikation eines Commits, ändert sich auch die SHA-1 Prüfsumme. Das Ändern des letzten Commits hat ein ähnliches Verhalten wie das Durchführen eines Rebase-Befehls. Deshalb sollte man einen Commit niemals nachträglich anpassen, wenn dieser bereits veröffentlicht wurde.
+Mit dem Befehl `--amend` sollte man vorsichtig umgehen, weil sich mit jeder nachträglichen Modifikation eines Commits auch die SHA-1-Prüfsumme ändert. Das Ändern des letzten Commits hat ein ähnliches Verhalten wie das Durchführen eines Rebase-Befehls. Deshalb sollte man einen Commit niemals nachträglich anpassen, wenn dieser bereits veröffentlicht wurde.
 
 <!--### Changing Multiple Commit Messages ###-->
 ### Änderung von mehreren Commit-Nachrichten ###
@@ -855,7 +855,7 @@ Man kann mit einem interaktiven Rebase auch mehrere Commits zu einem einzelnen C
 
 <!--If, instead of "pick" or "edit", you specify "squash", Git applies both that change and the change directly before it and makes you merge the commit messages together. So, if you want to make a single commit from these three commits, you make the script look like this:-->
 
-Wenn Du statt „pick“ oder „edit“, den Befehl „squash“ angibst, führt Git beide Commits zu einem gemeinsamen Commit zusammen und bietet Dir die Möglichkeit die Commit-Nachricht ebenso entsprechend zu verheiraten. Wenn Du also aus den drei Commits einen einzelnen Commit machen willst, muss Dein Skript folgendermaßen aufgebaut sein:
+Wenn Du statt „pick“ oder „edit“, den Befehl „squash“ angibst, führt Git beide Commits zu einem gemeinsamen Commit zusammen und bietet Dir die Möglichkeit, die Commit-Nachricht ebenso entsprechend zu verheiraten. Wenn Du also aus den drei Commits einen einzelnen Commit machen willst, muss Dein Skript folgendermaßen aufgebaut sein:
 
 	pick f7f3f6d changed my name a bit
 	squash 310154e updated README formatting and added blame
@@ -887,7 +887,7 @@ Du kannst nun die Commit-Nachricht entsprechend anpassen oder auch entsprechend
 
 <!--Splitting a commit undoes a commit and then partially stages and commits as many times as commits you want to end up with. For example, suppose you want to split the middle commit of your three commits. Instead of "updated README formatting and added blame", you want to split it into two commits: "updated README formatting" for the first, and "added blame" for the second. You can do that in the `rebase -i` script by changing the instruction on the commit you want to split to "edit":-->
 
-Man kann mit Git einen einzelnen Commit auch aufsplitten. Das bedeutet, man setzt den ursprünglichen Commit zurück, fügt dann einen Teil der Änderungen zur Staging Area hinzu und checkt das Ergebnis ein. Dies kann man unbegrenzt oft wiederholen und so einen einzelnen Commit in mehrere Commits aufteilen. Nehmen wir an, wir möchten den mittleren der beiden Commits aufteilen. Anstatt „updated README formatting and added blame“, möchten wir den Commit in folgende beiden Commits aufteilen: „updated README formatting“ soll das Thema des ersten Commits und „added blame“ soll das Thema des zweiten Commits sein. Dazu kannst Du das angezeigte Skript, welches Dir der Befehl `rebase -i` erzeugt, folgendermaßen anpassen:
+Man kann mit Git einen einzelnen Commit auch aufsplitten. Das bedeutet, man setzt den ursprünglichen Commit zurück, fügt dann einen Teil der Änderungen zur Staging-Area hinzu und checkt das Ergebnis ein. Dies kann man unbegrenzt oft wiederholen und so einen einzelnen Commit in mehrere Commits aufteilen. Nehmen wir an, wir möchten den mittleren der beiden Commits aufteilen. Anstatt „updated README formatting and added blame“, möchten wir den Commit in folgende beiden Commits aufteilen: „updated README formatting“ soll das Thema des ersten Commits und „added blame“ soll das Thema des zweiten Commits sein. Dazu kannst Du das angezeigte Skript, welches Dir der Befehl `rebase -i` erzeugt, folgendermaßen anpassen:
 
 	pick f7f3f6d changed my name a bit
 	edit 310154e updated README formatting and added blame
@@ -938,18 +938,18 @@ Dieses Szenario tritt sogar relativ häufig auf. Nehmen wir einmal an, jemand f
 
 <!--The `-\-tree-filter` option runs the specified command after each checkout of the project and then recommits the results. In this case, you remove a file called passwords.txt from every snapshot, whether it exists or not. If you want to remove all accidentally committed editor backup files, you can run something like `git filter-branch -\-tree-filter "rm -f *~" HEAD`.-->
 
-Die Option `--tree-filer` führt den nachfolgenden Befehl nach jedem Auschecken eines Commits des Projekts aus und checkt danach das Ergebnis wieder ein. In diesem Beispiel, wird die Datei „passwords.txt“ aus jedem Schnappschuss entfernt, unabhängig davon, ob sie existiert oder nicht. Ein anderes Beispiel wäre es, alle Backup-Dateien eines Texteditors aus dem Repository zu löschen. Dazu kann man in etwa den Befehl `git filter-branch -\-tree-filter "rm -f *~" HEAD` ausführen.
+Die Option `--tree-filer` führt den nachfolgenden Befehl nach jedem Auschecken eines Commits des Projekts aus und checkt danach das Ergebnis wieder ein. In diesem Beispiel wird die Datei „passwords.txt“ aus jedem Schnappschuss entfernt, unabhängig davon, ob sie existiert oder nicht. Ein anderes Beispiel wäre es, alle Backup-Dateien eines Texteditors aus dem Repository zu löschen. Dazu kann man in etwa den Befehl `git filter-branch -\-tree-filter "rm -f *~" HEAD` ausführen.
 
 <!--You’ll be able to watch Git rewriting trees and commits and then move the branch pointer at the end. It’s generally a good idea to do this in a testing branch and then hard-reset your master branch after you’ve determined the outcome is what you really want. To run `filter-branch` on all your branches, you can pass `-\-all` to the command.-->
 
-Git informiert Dich über den Fortschritt dieses Vorgangs und Du siehst, wie jeder Commit angepasst wird und der Zeiger auf den Branch auf den letzten Commit gesetzt wird. Es ist empfehlenswert, diesen Befehl in einem Testzweig durchzuführen. Wenn das Ergebnis, wie gewünscht ausfällt, kann man danach den Master Branch auf diesen Testzweig setzen. Wenn man an den Befehl `filter-branch` die Option `--all` anfügt, führt Git diesen Vorgang für jeden vorhandenen Zweig aus.
+Git informiert Dich über den Fortschritt dieses Vorgangs und Du siehst, wie jeder Commit angepasst wird und der Zeiger auf den Branch auf den letzten Commit gesetzt wird. Es ist empfehlenswert, diesen Befehl in einem Testzweig durchzuführen. Wenn das Ergebnis, wie gewünscht ausfällt, kann man danach den Master-Branch auf diesen Testzweig setzen. Wenn man an den Befehl `filter-branch` die Option `--all` anfügt, führt Git diesen Vorgang für jeden vorhandenen Zweig aus.
 
 <!--#### Making a Subdirectory the New Root ####-->
 #### Aus einem Unterverzeichnis das neue Wurzelverzeichnis machen ####
 
 <!--Suppose you’ve done an import from another source control system and have subdirectories that make no sense (trunk, tags, and so on). If you want to make the `trunk` subdirectory be the new project root for every commit, `filter-branch` can help you do that, too:-->
 
-Wenn man zum Beispiel ein Projekt aus einem anderen Versionskontrollwerkzeug in Git importiert, gibt es dort oft Verzeichnisse, die in Git nicht relevant sind, zum Beispiel trunk, tags, usw.. Wenn man also das Unterverzeichnis „trunk“ das neue Wurzelverzeichnis machen will, kann man dies mit Hilfe von `filter-branch` umsetzen:
+Wenn man zum Beispiel ein Projekt aus einem anderen Versionskontrollwerkzeug in Git importiert, gibt es dort oft Verzeichnisse, die in Git nicht relevant sind, zum Beispiel trunk, tags, usw.. Wenn man also das Unterverzeichnis `trunk` das neue Wurzelverzeichnis machen will, kann man dies mit Hilfe von `filter-branch` umsetzen:
 
 	$ git filter-branch --subdirectory-filter trunk HEAD
 	Rewrite 856f0bf61e41a27326cdae8f09fe708d679f596f (12/12)
@@ -978,7 +978,7 @@ Verflixt, es ist schon wieder passiert. Du hast vergessen, den Befehl `git confi
 
 <!--This goes through and rewrites every commit to have your new address. Because commits contain the SHA-1 values of their parents, this command changes every commit SHA in your history, not just those that have the matching e-mail address.-->
 
-Dieser Befehl durchforstet das Repository und ersetzt in jedem Commit, dessen E-Mail-Adresse des Autors „schacon@localhost“ lautet, mit der neuen E-Mail Adresse „schacon@example.com“. Zusätzlich wird der Name des Autors geändert, falls dieser nicht vorher schon „Scott Chacon“ war. Auf Grund der Architektur, dass in Git in jedem Commit die SHA1 Prüfsumme des Vorgänger-Commits enthalten ist, ändert dieser Befehl jeden Commit in Deiner Historie. Die SHA1-Prüfsumme wird sich auch in allen Commits, die nicht die angegebene E-Mail-Adresse enthalten, verändern.
+Dieser Befehl durchforstet das Repository und ersetzt in jedem Commit, dessen E-Mail-Adresse des Autors „schacon@localhost“ lautet, mit der neuen E-Mail-Adresse „schacon@example.com“. Zusätzlich wird der Name des Autors geändert, falls dieser nicht vorher schon „Scott Chacon“ war. Auf Grund der Architektur, dass in Git in jedem Commit die SHA1-Prüfsumme des Vorgänger-Commits enthalten ist, ändert dieser Befehl jeden Commit in Deiner Historie. Die SHA1-Prüfsumme wird sich auch in allen Commits, die nicht die angegebene E-Mail-Adresse enthalten, verändern.
 
 <!--## Debugging with Git ##-->
 ## Mit Hilfe von Git debuggen ##
@@ -1009,11 +1009,11 @@ Wenn Du nach einem Bug in Deinem Code suchst und gerne wissen willst, wann und w
 
 <!--Notice that the first field is the partial SHA-1 of the commit that last modified that line. The next two fields are values extracted from that commit—the author name and the authored date of that commit — so you can easily see who modified that line and when. After that come the line number and the content of the file. Also note the `^4832fe2` commit lines, which designate that those lines were in this file’s original commit. That commit is when this file was first added to this project, and those lines have been unchanged since. This is a tad confusing, because now you’ve seen at least three different ways that Git uses the `^` to modify a commit SHA, but that is what it means here.-->
 
-In der ersten Spalte wird die Kurzform der SHA1-Prüfsumme des Commits angezeigt, in welchem diese Zeile zuletzt verändert wurde. Die nächsten beiden Spalten weisen auf den Autor des Commits und wann dieser verfasst wurde, hin. Auf diese Weise kannst Du leicht bestimmen, wer die jeweilige Zeile geändert hat und wann dies durchgeführt wurde. In den nächsten Spalten wird die Zeilennummer und der Inhalt der Zeile angezeigt. Die Zeilen mit der SHA1-Prüfsumme `^4832fe2` weisen darauf hin, dass diese bereits im ersten Commit vorhanden waren. Das ist also der Commit, in dem die Datei „simplegit.rb“ zum Repository hinzugefügt wurde und die Zeilen deuten damit darauf hin, dass diese bisher nie geändert wurden. Das ist für Dich wahrscheinlich ein bisschen verwirrend, denn nun kennst Du bereits drei Möglichkeiten, wie Git mit dem Zeichen `^` einer SHA1 Prüfsumme eine neue Bedeutung gibt. Aber in Zusammenhang mit  `git blame` weist das Zeichen auf den eben geschilderten Sachverhalt hin.
+In der ersten Spalte wird die Kurzform der SHA1-Prüfsumme des Commits angezeigt, in welchem diese Zeile zuletzt verändert wurde. Die nächsten beiden Spalten weisen auf den Autor des Commits und wann dieser verfasst wurde, hin. Auf diese Weise kannst Du leicht bestimmen, wer die jeweilige Zeile geändert hat und wann dies durchgeführt wurde. In den nächsten Spalten wird die Zeilennummer und der Inhalt der Zeile angezeigt. Die Zeilen mit der SHA-1-Prüfsumme `^4832fe2` weisen darauf hin, dass diese bereits im ersten Commit vorhanden waren. Das ist also der Commit, in dem die Datei „simplegit.rb“ zum Repository hinzugefügt wurde und die Zeilen deuten damit darauf hin, dass diese bisher nie geändert wurden. Das ist für Dich wahrscheinlich ein bisschen verwirrend, denn nun kennst Du bereits drei Möglichkeiten, wie Git mit dem Zeichen `^` einer SHA-Prüfsumme eine neue Bedeutung gibt. Aber in Zusammenhang mit  `git blame` weist das Zeichen auf den eben geschilderten Sachverhalt hin.
 
 <!--Another cool thing about Git is that it doesn’t track file renames explicitly. It records the snapshots and then tries to figure out what was renamed implicitly, after the fact. One of the interesting features of this is that you can ask it to figure out all sorts of code movement as well. If you pass `-C` to `git blame`, Git analyzes the file you’re annotating and tries to figure out where snippets of code within it originally came from if they were copied from elsewhere. Recently, I was refactoring a file named `GITServerHandler.m` into multiple files, one of which was `GITPackUpload.m`. By blaming `GITPackUpload.m` with the `-C` option, I could see where sections of the code originally came from:-->
 
-Eine weitere herausragende Eigenschaft von Git ist die Tatsache, dass es nicht per se das Umbenennen von Dateien verfolgt. Git speichert immer den jeweiligen Schnappschuss des Dateisystems und versucht erst danach zu bestimmen, welche Dateien umbenannt wurden. Das bietet Dir zum Beispiel die Möglichkeit herauszufinden, wie Code innerhalb des Repositorys hin und her verschoben wurde. Wenn Du also die Option `-C` an `git blame` anfügst, analysiert Git die angebene Datei und versucht herauszufinden, ob und von wo bestimmte Codezeilen herkopiert wurden. Vor kurzem habe ich ein Refactoring an einer Datei mit dem Namen `GITServerHandler.m` durchgeführt. Dabei habe ich diese Datei in mehrere Dateien aufgeteilt, eine davon war `GITPackUpload.m`. Wenn ich jetzt `git blame` mit der Option `-C` auf die Datei `GITPackUpload.m` ausführe, erhalte ich eine Ausgabe mit den Codezeilen, von denen das Ergebnis ursprünglich stammt:
+Eine weitere herausragende Eigenschaft von Git ist die Tatsache, dass es nicht per se das Umbenennen von Dateien verfolgt. Git speichert immer den jeweiligen Schnappschuss des Dateisystems und versucht erst danach zu bestimmen, welche Dateien umbenannt wurden. Das bietet Dir zum Beispiel die Möglichkeit herauszufinden, wie Code innerhalb des Repositorys hin und her verschoben wurde. Wenn Du also die Option `-C` an `git blame` anfügst, analysiert Git die angegebene Datei und versucht herauszufinden, ob und von wo bestimmte Codezeilen herkopiert wurden. Vor kurzem habe ich ein Refactoring an einer Datei mit dem Namen `GITServerHandler.m` durchgeführt. Dabei habe ich diese Datei in mehrere Dateien aufgeteilt, eine davon war `GITPackUpload.m`. Wenn ich jetzt `git blame` mit der Option `-C` auf die Datei `GITPackUpload.m` ausführe, erhalte ich eine Ausgabe mit den Codezeilen, von denen das Ergebnis ursprünglich stammt:
 
 	$ git blame -C -L 141,153 GITPackUpload.m
 	f344f58d GITServerHandler.m (Scott 2009-01-04 141)
@@ -1069,7 +1069,7 @@ Git hat Dir jetzt einen weiteren Commit ausgecheckt, und zwar wieder den mittler
 
 <!--This commit is fine, and now Git has all the information it needs to determine where the issue was introduced. It tells you the SHA-1 of the first bad commit and show some of the commit information and which files were modified in that commit so you can figure out what happened that may have introduced this bug:-->
 
-Git checkt wieder den nächsten mittleren Commit aus und wir stellen fest, dass dieser in Ordnung ist. Ab jetzt hat Git alle notwendigen Informationen um festzustellen, in welchem Commit der Fehler eingebaut wurde. Git zeigt Dir dazu die SHA1-Prüfsumme des ersten fehlerhaften Commits an. Zusätzlich gibt es noch weitere Commit-Informationen und welche Dateien in diesem Commit geändert wurden, an. Das sollte Dir nun helfen, den Fehler näher zu bestimmen:
+Git checkt wieder den nächsten mittleren Commit aus und wir stellen fest, dass dieser in Ordnung ist. Ab jetzt hat Git alle notwendigen Informationen um festzustellen, in welchem Commit der Fehler eingebaut wurde. Git zeigt Dir dazu die SHA-1-Prüfsumme des ersten fehlerhaften Commits an. Zusätzlich gibt es noch weitere Commit-Informationen und welche Dateien in diesem Commit geändert wurden, an. Das sollte Dir nun helfen, den Fehler näher zu bestimmen:
 
 	$ git bisect good
 	b047b02ea83310a70fd603dc8cd7a6cd13d15c04 is first bad commit
@@ -1108,18 +1108,18 @@ Oft möchte man während der Arbeit an einem Projekt ein weiteres Projekt darin
 
 <!--Here’s an example. Suppose you’re developing a web site and creating Atom feeds. Instead of writing your own Atom-generating code, you decide to use a library. You’re likely to have to either include this code from a shared library like a CPAN install or Ruby gem, or copy the source code into your own project tree. The issue with including the library is that it’s difficult to customize the library in any way and often more difficult to deploy it, because you need to make sure every client has that library available. The issue with vendoring the code into your own project is that any custom changes you make are difficult to merge when upstream changes become available.-->
 
-Dazu ein Beispiel. Nehmen wir an, Du entwickelt gerade eine Webseite, die unter anderem einen Atom-Feed zur Verfügung stellen soll. Anstatt den notwendigen Code zur Auslieferung des Atom-Feeds selber zu schreiben, entscheidest Du Dich für eine geeignete Bibliothek. Dann wirst Du wahrscheinlich den Code in Dein Projekt inkludieren müssen, zum Beispiel durch eine CPAN-Installation oder ein Ruby-Gem oder durch Kopieren des Quellcodes in das Arbeitsverzeichnis Deines Projekts. Das Problem beim Einbinden einer Bibliothek ist, dass es schwierig ist, diese an die eigene Bedürfnisse anzupassen. Noch schwieriger gestaltet sich dann die Veröffentlichung des Projekts, da man sicherstellen muss, dass jeder der die Software verwendet, auf die Bibliothek zugreifen kann. Wenn man die Bibliothek im eigenen Projekt projektspezifisch anpasst, hat man meist ein Problem, wenn man eine neue Version der Bibliothek einspielen will.
+Dazu ein Beispiel. Nehmen wir an, Du entwickelst gerade eine Webseite, die unter anderem einen Atom-Feed zur Verfügung stellen soll. Anstatt den notwendigen Code zur Auslieferung des Atom-Feeds selber zu schreiben, entscheidest Du Dich für eine geeignete Bibliothek. Dann wirst Du wahrscheinlich den Code in Dein Projekt einbinden müssen, zum Beispiel durch eine CPAN-Installation oder ein Ruby-Gem oder durch Kopieren des Quellcodes in das Arbeitsverzeichnis Deines Projekts. Das Problem beim Einbinden einer Bibliothek ist, dass es schwierig ist, diese an die eigene Bedürfnisse anzupassen. Noch schwieriger gestaltet sich dann die Veröffentlichung des Projekts, da man sicherstellen muss, dass jeder der die Software verwendet, auf die Bibliothek zugreifen kann. Wenn man die Bibliothek im eigenen Projekt projektspezifisch anpasst, hat man meist ein Problem, wenn man eine neue Version der Bibliothek einspielen will.
 
 <!--Git addresses this issue using submodules. Submodules allow you to keep a Git repository as a subdirectory of another Git repository. This lets you clone another repository into your project and keep your commits separate.-->
 
-Git löst dieses Problem mit Hilfe von Submodulen. Mit Hilfe von Submodulen kann man innerhalb eines Git Repositorys ein weiteres Git Repository in einem Unterverzeichnis verwalten. Daraus entsteht der Vorteil, dass man ein anderes Repository in das eigene Projekt klonen kann und die Commits der jeweiligen Projekte trennen kann.
+Git löst dieses Problem mit Hilfe von Submodulen. Mit Hilfe von Submodulen kann man innerhalb eines Git-Repositorys ein weiteres Git-Repository in einem Unterverzeichnis verwalten. Daraus entsteht der Vorteil, dass man ein anderes Repository in das eigene Projekt klonen kann und die Commits der jeweiligen Projekte trennen kann.
 
 <!--### Starting with Submodules ###-->
 ### Die ersten Schritte mit Submodulen ###
 
 <!--Suppose you want to add the Rack library (a Ruby web server gateway interface) to your project, possibly maintain your own changes to it, but continue to merge in upstream changes. The first thing you should do is clone the external repository into your subdirectory. You add external projects as submodules with the `git submodule add` command:-->
 
-Nehmen wir einmal an, dass Du die Rack-Bibliothek (eine Ruby Gateway-Schnittstelle für Webserver) zu Deinem Projekt hinzufügen willst. Dabei möchtest Du Deine eigenen Änderungen an dieser Bibliothek nachverfolgen, aber auch weiterhin Änderungen von den Rack Bibliothek-Entwicklern verwalten und zusammenmergen. Das erste was Du dazu tun musst, ist das Repository der Rack Bibliothek in ein Unterverzeichnis Deines Projekts zu klonen. Diesen Vorgang kannst Du mit Hilfe des Befehls `git submodule add` ausführen:
+Nehmen wir einmal an, dass Du die Rack-Bibliothek (eine Ruby-Gateway-Schnittstelle für Webserver) zu Deinem Projekt hinzufügen willst. Dabei möchtest Du Deine eigenen Änderungen an dieser Bibliothek nachverfolgen, aber auch weiterhin Änderungen von den Rack-Bibliothek-Entwicklern verwalten und zusammenmergen. Das erste was Du dazu tun musst, ist das Repository der Rack Bibliothek in ein Unterverzeichnis Deines Projekts zu klonen. Diesen Vorgang kannst Du mit Hilfe des Befehls `git submodule add` ausführen:
 
 	$ git submodule add git://github.com/chneukirchen/rack.git rack
 	Initialized empty Git repository in /opt/subtest/rack/.git/
@@ -1131,7 +1131,7 @@ Nehmen wir einmal an, dass Du die Rack-Bibliothek (eine Ruby Gateway-Schnittstel
 
 <!--Now you have the Rack project under a subdirectory named `rack` within your project. You can go into that subdirectory, make changes, add your own writable remote repository to push your changes into, fetch and merge from the original repository, and more. If you run `git status` right after you add the submodule, you see two things:-->
 
-Innerhalb Deines Projekts befindet sich nun im Unterverzeichnis `rack` das komplette Rack-Projekt. Man kann jetzt in diesem Verzeichnis Änderungen vornehmen und ein eigenes Remote Repository mit Schreibrechten, zu welchem man pushen kann, hinzufügen. Ebenso ist es möglich, Änderungen von den Rack Entwicklern in sein Repository zu laden und diese mit den eigenen Ergebnissen zu mergen. Im Prinzip kann man innerhalb eines Submoduls die gleichen Vorgänge, wie in einem normalen Repository ausführen. Vorher müssen wir aber noch ein paar weitere Dinge zu Submodulen besprechen. Wenn Du gleich nach dem Hinzufügen des Submoduls, den Befehl `git status` ausführst, wirst Du gleich zwei Dinge bemerken:
+Innerhalb Deines Projekts befindet sich nun im Unterverzeichnis `rack` das komplette Rack-Projekt. Man kann jetzt in diesem Verzeichnis Änderungen vornehmen und ein eigenes Remote Repository mit Schreibrechten, zu welchem man pushen kann, hinzufügen. Ebenso ist es möglich, Änderungen von den Rack-Entwicklern in sein Repository zu laden und diese mit den eigenen Ergebnissen zu mergen. Im Prinzip kann man innerhalb eines Submoduls die gleichen Vorgänge, wie in einem normalen Repository ausführen. Vorher müssen wir aber noch ein paar weitere Dinge zu Submodulen besprechen. Wenn Du gleich nach dem Hinzufügen des Submoduls, den Befehl `git status` ausführst, wirst Du gleich zwei Dinge bemerken:
 
 	$ git status
 	# On branch master
@@ -1170,7 +1170,7 @@ Die zweite Auffälligkeit bei der Ausgabe von `git status` ist der Eintrag rack.
 
 <!--Although `rack` is a subdirectory in your working directory, Git sees it as a submodule and doesn’t track its contents when you’re not in that directory. Instead, Git records it as a particular commit from that repository. When you make changes and commit in that subdirectory, the superproject notices that the HEAD there has changed and records the exact commit you’re currently working off of; that way, when others clone this project, they can re-create the environment exactly.-->
 
-Obwohl `rack` ein Unterverzeichnis in Deinem Arbeitsverzeichnis ist, erkennt Git dieses Verzeichnis als Submodul und verfolgt die Änderungen innerhalb dieses Verzeichnis nicht, wenn Git nicht innerhalb dieses Verzeichnis aufgerufen wird. Stattdessen erfässt Git, welcher Commit in diesem Repository ausgecheckt ist. Wenn Du also Änderungen in diesem Unterverzeichnis durchführst und eincheckst, kann das Superprojekt erkennen, dass sich der aktuelle HEAD von diesem Projekt geändert hat. Das Superprojekt kann sich jetzt diesen Commit merken. Auf diese Art und Weise ist es möglich den kompletten Zustand des Projekts mit allen Projekten, die als Submodul hinzugefügt wurden, zu reproduzieren. In der Git Terminologie wird das Projekt, welches eines oder mehrere Submodule enthält, als Superprojekt bezeichnet.
+Obwohl `rack` ein Unterverzeichnis in Deinem Arbeitsverzeichnis ist, erkennt Git dieses Verzeichnis als Submodul und verfolgt die Änderungen innerhalb dieses Verzeichnisses nicht, wenn Git nicht innerhalb dieses Verzeichnisses aufgerufen wird. Stattdessen erfässt Git, welcher Commit in diesem Repository ausgecheckt ist. Wenn Du also Änderungen in diesem Unterverzeichnis durchführst und eincheckst, kann das Superprojekt erkennen, dass sich der aktuelle HEAD von diesem Projekt geändert hat. Das Superprojekt kann sich jetzt diesen Commit merken. Auf diese Art und Weise ist es möglich, den kompletten Zustand des Projekts mit allen Projekten, die als Submodul hinzugefügt wurden, zu reproduzieren. In der Git-Terminologie wird das Projekt, welches eines oder mehrere Submodule enthält, als Superprojekt bezeichnet.
 
 <!--This is an important point with submodules: you record them as the exact commit they’re at. You can’t record a submodule at `master` or some other symbolic reference.-->
 
@@ -1188,11 +1188,11 @@ Wenn Du Dein Projekt das erste Mal eincheckst, erhältst Du in etwa folgende Aus
 
 <!--Notice the 160000 mode for the rack entry. That is a special mode in Git that basically means you’re recording a commit as a directory entry rather than a subdirectory or a file.-->
 
-Der Mode 160000, der für den rack Eintrag gilt, ist ein spezieller Mode in Git. Er bedeutet in etwa, dass man einen Commit als Verzeichnis-Eintrag in Git verwaltet und damit nicht wie normalerweise ein Verzeichnis oder eine Datei.
+Der Mode 160000, der für den rack-Eintrag gilt, ist ein spezieller Mode in Git. Er bedeutet in etwa, dass man einen Commit als Verzeichnis-Eintrag in Git verwaltet und damit nicht wie normalerweise ein Verzeichnis oder eine Datei.
 
 <!--You can treat the `rack` directory as a separate project and then update your superproject from time to time with a pointer to the latest commit in that subproject. All the Git commands work independently in the two directories:-->
 
-Das Verzeichnis `rack` kann man wie ein separates Projekt behandeln und verwenden. Und von Zeit zur Zeit aktualisiert man auch das Superprojekt und speichert damit die letzte Commit Id des Unterprojekts. Jedes Git Kommando arbeitet unabhängig in einem der beiden Unterverzeichnisse:
+Das Verzeichnis `rack` kann man wie ein separates Projekt behandeln und verwenden. Und von Zeit zur Zeit aktualisiert man auch das Superprojekt und speichert damit die letzte Commit-ID des Unterprojekts. Jedes Git-Kommando arbeitet unabhängig in einem der beiden Unterverzeichnisse:
 
 	$ git log -1
 	commit 0550271328a0038865aad6331e620cd7238601bb
@@ -1231,7 +1231,7 @@ Als nächstes klonen wir ein Projekt, welches ein Submodul verwendet. Wenn man e
 
 <!--The `rack` directory is there, but empty. You must run two commands: `git submodule init` to initialize your local configuration file, and `git submodule update` to fetch all the data from that project and check out the appropriate commit listed in your superproject:-->
 
-Das Verzeichnis `rack` wurde zwar erzeugt, aber es ist leer. Deshalb musst Du zwei Dinge ausführen: `git submodule init`, damit wird die Datei für die lokale Konfiguration initiailisiert. Und `git submodule update`, welches die gesamten Daten des Projekts von der im `.gitmodules` angegebenen Quelle holt und den entsprechenden Commit, welcher im Superprojekt hinterlegt ist, auscheckt:
+Das Verzeichnis `rack` wurde zwar erzeugt, aber es ist leer. Deshalb musst Du zwei Dinge ausführen: `git submodule init`, damit wird die Datei für die lokale Konfiguration initialisiert. Und `git submodule update`, welches die gesamten Daten des Projekts von der im `.gitmodules` angegebenen Quelle holt und den entsprechenden Commit, welcher im Superprojekt hinterlegt ist, auscheckt:
 
 	$ git submodule init
 	Submodule 'rack' (git://github.com/chneukirchen/rack.git) registered for path 'rack'
@@ -1246,7 +1246,7 @@ Das Verzeichnis `rack` wurde zwar erzeugt, aber es ist leer. Deshalb musst Du zw
 
 <!--Now your `rack` subdirectory is at the exact state it was in when you committed earlier. If another developer makes changes to the rack code and commits, and you pull that reference down and merge it in, you get something a bit odd:-->
 
-Nach Ausführung der beiden Befehle befindet sich das Verzeichnis `rack` in genau dem gleichen Zustand, wie wir es ursprünglich eingecheckt haben. Wenn ein anderer Entwickler Änderungen am Rack Code durchführt, diese eincheckt und Du diese dann pullst und mergst, erhält man einen etwas seltsamen Zustand:
+Nach Ausführung der beiden Befehle befindet sich das Verzeichnis `rack` in genau dem gleichen Zustand, wie wir es ursprünglich eingecheckt haben. Wenn ein anderer Entwickler Änderungen am Rack-Code durchführt, diese eincheckt und Du diese dann pullst und mergst, erhält man einen etwas seltsamen Zustand:
 
 	$ git merge origin/master
 	Updating 0550271..85a3eee
@@ -1324,14 +1324,14 @@ In manchen großen Projekten möchten die Entwickler die Arbeit in verschiedenen
 
 <!--A good way to do this in Git is to make each of the subdirectories a separate Git repository and then create superproject Git repositories that contain multiple submodules. A benefit of this approach is that you can more specifically define the relationships between the projects with tags and branches in the superprojects.-->
 
-In Git kann man diese Vorgehensweise gut abbilden, indem man für jedes Unterverzeichnis ein neues Git Repository erzeugt. Zusätzlich kann man dann ein Superprojekt erzeugen und die ganzen Git Repositorys als Submodul hinzufügen.  Ein Vorteil dabei ist, dass man mit Hilfe von Tags und Branches im Superprojekt das Verhältnis der einzelnen Submodule zueinander festhalten kann.
+In Git kann man diese Vorgehensweise gut abbilden, indem man für jedes Unterverzeichnis ein neues Git-Repository erzeugt. Zusätzlich kann man dann ein Superprojekt erzeugen und die ganzen Git-Repositorys als Submodul hinzufügen. Ein Vorteil dabei ist, dass man mit Hilfe von Tags und Branches im Superprojekt das Verhältnis der einzelnen Submodule zueinander festhalten kann.
 
 <!--### Issues with Submodules ###-->
 ### Häufige Probleme mit Submodulen ###
 
 <!--Using submodules isn’t without hiccups, however. First, you must be relatively careful when working in the submodule directory. When you run `git submodule update`, it checks out the specific version of the project, but not within a branch. This is called having a detached HEAD — it means the HEAD file points directly to a commit, not to a symbolic reference. The issue is that you generally don’t want to work in a detached HEAD environment, because it’s easy to lose changes. If you do an initial `submodule update`, commit in that submodule directory without creating a branch to work in, and then run `git submodule update` again from the superproject without committing in the meantime, Git will overwrite your changes without telling you.  Technically you won’t lose the work, but you won’t have a branch pointing to it, so it will be somewhat difficult to retrieve.-->
 
-Die Arbeit mit Submodulen verläuft jedoch nicht immer reibungslos. Man muss verhältnismäßig gut aufpassen, wenn man in einem Submodul-Verzeichnis arbeitet. Wenn man nämlich den Befehl `git submodule update` ausführt, checkt Git den entsprechenden Zustand des Commits aus, aber checkt dabei keinen Branch aus. Diesen Zustand nennt man auch `detached HEAD`. Das bedeutet, dass die Datei HEAD direkt auf einen Commit zeigt und nicht wie sonst üblich auf eine symbolische Referenz, also zum Beispiel auf einen Branch. Das Problem dabei ist, dass man normalerweise in einem solchen Zustand nicht weiterarbeiten möchte, weil es sehr leicht vorkommen kann, dass Änderungen verloren gehen. Wenn man also den Befehl `git submodule update` aufruft, dann einen Commit in dem entsprechenden Submodul-Verzeichnis ausführt, ohne davor einen Branch auszuchecken, und dann noch einmal `git submodule update` im Superprojekt aufruft, ohne dass man die Änderungen im Submodul im Superprojekt eingecheckt hat, verliert man die ganzen Änderungen, ohne dass Git einen darauf vorher hinweist. Tatsächlich ist es so, dass die Änderungen nicht verloren gehen, aber es gibt keinen Branch, der auf die entsprechenden Commits hinzeigt, und damit kann es schwierig werden, die entsprechenden Commits wiederherzustellen beziehungsweise sichtbar zu machen.
+Die Arbeit mit Submodulen verläuft jedoch nicht immer reibungslos. Man muss verhältnismäßig gut aufpassen, wenn man in einem Submodul-Verzeichnis arbeitet. Wenn man nämlich den Befehl `git submodule update` ausführt, checkt Git den entsprechenden Zustand des Commits aus, aber checkt dabei keinen Branch aus. Diesen Zustand nennt man auch `detached HEAD`. Das bedeutet, dass die Datei HEAD direkt auf einen Commit zeigt und nicht, wie sonst üblich, auf eine symbolische Referenz, also zum Beispiel auf einen Branch. Das Problem dabei ist, dass man normalerweise in einem solchen Zustand nicht weiterarbeiten möchte, weil es sehr leicht vorkommen kann, dass Änderungen verloren gehen. Wenn man also den Befehl `git submodule update` aufruft, dann einen Commit in dem entsprechenden Submodul-Verzeichnis ausführt, ohne davor einen Branch auszuchecken, und dann noch einmal `git submodule update` im Superprojekt aufruft, ohne dass man die Änderungen im Submodul im Superprojekt eingecheckt hat, verliert man die ganzen Änderungen, ohne dass Git einen darauf vorher hinweist. Tatsächlich ist es so, dass die Änderungen nicht verloren gehen, aber es gibt keinen Branch, der auf die entsprechenden Commits hinzeigt, und damit kann es schwierig werden, die entsprechenden Commits wiederherzustellen beziehungsweise sichtbar zu machen.
 
 <!--To avoid this issue, create a branch when you work in a submodule directory with `git checkout -b work` or something equivalent. When you do the submodule update a second time, it will still revert your work, but at least you have a pointer to get back to.-->
 
@@ -1368,7 +1368,7 @@ In diesem Fall muss man das Verzeichnis entweder an einen anderen Ort verschiebe
 
 <!--The last main caveat that many people run into involves switching from subdirectories to submodules. If you’ve been tracking files in your project and you want to move them out into a submodule, you must be careful or Git will get angry at you. Assume that you have the rack files in a subdirectory of your project, and you want to switch it to a submodule. If you delete the subdirectory and then run `submodule add`, Git yells at you:-->
 
-Die letzte Falle, in die viele Leute tappen, tritt auf, wenn man bereits vorhandene Verzeichnisse in Submodule umwandeln will. Wenn man also Dateien, die bereits von Git verwaltet werden, entfernen und in ein entsprechendes Submodul verschieben möchte, muss man vorsichtig sein. Ansonsten können schwer zu behebende Probleme mit Git auftreten. Nehmen wir zum Beispiel an, dass Du die Dateien vom Rack Projekt in ein Unterverzeichnis Deines Projekts abgelegt hast und diese jetzt aber in ein Submodul verschieben möchtest. Wenn Du das Unterverzeichnis einfach löschst und dann den Befehl `submodule add` ausführst, zeigt Dir Git folgende Fehlermeldung an:
+Die letzte Falle, in die viele Leute tappen, tritt auf, wenn man bereits vorhandene Verzeichnisse in Submodule umwandeln will. Wenn man also Dateien, die bereits von Git verwaltet werden, entfernen und in ein entsprechendes Submodul verschieben möchte, muss man vorsichtig sein. Ansonsten können schwer zu behebende Probleme mit Git auftreten. Nehmen wir zum Beispiel an, dass Du die Dateien vom Rack-Projekt in ein Unterverzeichnis Deines Projekts abgelegt hast und diese jetzt aber in ein Submodul verschieben möchtest. Wenn Du das Unterverzeichnis einfach löschst und dann den Befehl `submodule add` ausführst, zeigt Dir Git folgende Fehlermeldung an:
 
 	$ rm -Rf rack/
 	$ git submodule add git@github.com:schacon/rack.git rack
@@ -1376,7 +1376,7 @@ Die letzte Falle, in die viele Leute tappen, tritt auf, wenn man bereits vorhand
 
 <!--You have to unstage the `rack` directory first. Then you can add the submodule:-->
 
-Man muss dann das Verzeichnis `rack` erst aus der Staging Area entfernen. Danach kann man dann das Submodul erzeugen:
+Man muss dann das Verzeichnis `rack` erst aus der Staging-Area entfernen. Danach kann man dann das Submodul erzeugen:
 
 	$ git rm -r rack
 	$ git submodule add git@github.com:schacon/rack.git rack
@@ -1413,11 +1413,11 @@ Wenn man dann wieder in den Zweig mit dem Submodul zurückwechseln will, erhält
 
 <!--Now that you’ve seen the difficulties of the submodule system, let’s look at an alternate way to solve the same problem. When Git merges, it looks at what it has to merge together and then chooses an appropriate merging strategy to use. If you’re merging two branches, Git uses a _recursive_ strategy. If you’re merging more than two branches, Git picks the _octopus_ strategy. These strategies are automatically chosen for you because the recursive strategy can handle complex three-way merge situations — for example, more than one common ancestor — but it can only handle merging two branches. The octopus merge can handle multiple branches but is more cautious to avoid difficult conflicts, so it’s chosen as the default strategy if you’re trying to merge more than two branches.-->
 
-Nachdem wir neben den Vor- und Nachteilen beim Arbeiten mit Submodulen kennengelernt haben, möchte ich jetzt noch eine alternative Lösung zeigen, wie man ähnliche Probleme lösen kann. Wenn Git etwas zusammenführt, also mergt, analysiert es die Teile, die es mergen muss. Auf Basis dieser Analyse entscheidet Git sich für eine geeignete Merging-Methode. Wenn man zwei Branches mergt, dann verwendet Git automatisch, die sogenannte Recursive-Strategie. Wenn man mehr als zwei Branches mergt, verwendet Git die sogenannte Octopus-Strategie. Diese Strategien werden automatisch für Dich gewählt, weil die Recursive-Strategie normalerweise sehr gut geeignet ist, um einen Drei-Wege-Merge (engl. three-way merge) durchzuführen — zum Beispiel, wenn es mehr als einen gemeinsamen Vorgänger-Commit gibt — aber der Drei-Wege-Merge ist nur für das Mergen von zwei Branches geeignet. Die Octopus-Merge-Strategie kann mehrere Branches zusammenführen, aber es wird dabei vorsichtiger vorgegangen, um schwierig aufzulösende Konflikte zu vermeiden. Aus diesem Grund wird diese Strategie standardmäßig verwendet, wenn man mehr als zwei Branches zusammenführen möchte.
+Nachdem wir neben den Vor- und Nachteilen beim Arbeiten mit Submodulen kennengelernt haben, möchte ich jetzt noch eine alternative Lösung zeigen, wie man ähnliche Probleme lösen kann. Wenn Git etwas zusammenführt, also mergt, analysiert es die Teile, die es mergen muss. Auf Basis dieser Analyse entscheidet Git sich für eine geeignete Merging-Methode. Wenn man zwei Branches mergt, dann verwendet Git automatisch die sogenannte Recursive-Strategie. Wenn man mehr als zwei Branches mergt, verwendet Git die sogenannte Octopus-Strategie. Diese Strategien werden automatisch für Dich gewählt, weil die Recursive-Strategie normalerweise sehr gut geeignet ist, um einen Drei-Wege-Merge (engl. three-way merge) durchzuführen — zum Beispiel, wenn es mehr als einen gemeinsamen Vorgänger-Commit gibt — aber der Drei-Wege-Merge ist nur für das Mergen von zwei Branches geeignet. Die Octopus-Merge-Strategie kann mehrere Branches zusammenführen, aber es wird dabei vorsichtiger vorgegangen, um schwierig aufzulösende Konflikte zu vermeiden. Aus diesem Grund wird diese Strategie standardmäßig verwendet, wenn man mehr als zwei Branches zusammenführen möchte.
 
 <!--However, there are other strategies you can choose as well. One of them is the _subtree_ merge, and you can use it to deal with the subproject issue. Here you’ll see how to do the same rack embedding as in the last section, but using subtree merges instead.-->
 
-Es gibt jedoch noch weitere Strategien, die man verwenden kann. Einer dieser Strategien ist der sogenannte Subtree-Merge. Dies kann verwendet werden, um unser Problem mit Unterprojekten zu lösen. Ich möchte Dir im folgenden aufzeigen, wie man das Rack-Projekt aus dem letzten Kapitel einbindet und dabei den Subree-Merge anstatt der Submodule verwendet.
+Es gibt jedoch noch weitere Strategien, die man verwenden kann. Einer dieser Strategien ist der sogenannte Subtree-Merge. Dies kann verwendet werden, um unser Problem mit Unterprojekten zu lösen. Ich möchte Dir im Folgenden aufzeigen, wie man das Rack-Projekt aus dem letzten Kapitel einbindet und dabei den Subtree-Merge anstatt der Submodule verwendet.
 
 <!--The idea of the subtree merge is that you have two projects, and one of the projects maps to a subdirectory of the other one and vice versa. When you specify a subtree merge, Git is smart enough to figure out that one is a subtree of the other and merge appropriately — it’s pretty amazing.-->
 
@@ -1425,7 +1425,7 @@ Das Prinzip, das hinter einem Subtree-Merge steckt, ist, dass man zwei Projekte
 
 <!--You first add the Rack application to your project. You add the Rack project as a remote reference in your own project and then check it out into its own branch:-->
 
-Als erstes musst Du dazu die Rack-Applikation zu Deinem Projekt hinzufügen. Dazu fügst Du das Rack-Projekt als neues Remote Repository in Deinem Projekt hinzu und checkst dieses in einem separaten Branch aus:
+Als erstes musst Du dazu die Rack-Applikation zu Deinem Projekt hinzufügen. Dazu fügst Du das Rack-Projekt als neues Remote-Repository in Deinem Projekt hinzu und checkst dieses in einem separaten Branch aus:
 
 	$ git remote add rack_remote git@github.com:schacon/rack.git
 	$ git fetch rack_remote
@@ -1446,7 +1446,7 @@ Als erstes musst Du dazu die Rack-Applikation zu Deinem Projekt hinzufügen. Daz
 
 <!--Now you have the root of the Rack project in your `rack_branch` branch and your own project in the `master` branch. If you check out one and then the other, you can see that they have different project roots:-->
 
-Nach der Ausführung der drei Befehle befindet sich das Rack Projekt in Deinem Branch `rack_branch` und Dein eigenes Projekt liegt weiterhin im Branch `master`. Wenn man jetzt den jeweiligen Zweig auscheckt, sieht man die unterschiedlichen Inhalte im Wurzelverzeichnis:
+Nach der Ausführung der drei Befehle befindet sich das Rack-Projekt in Deinem Branch `rack_branch` und Dein eigenes Projekt liegt weiterhin im Branch `master`. Wenn man jetzt den jeweiligen Zweig auscheckt, sieht man die unterschiedlichen Inhalte im Wurzelverzeichnis:
 
 	$ ls
 	AUTHORS	       KNOWN-ISSUES   Rakefile      contrib	       lib
@@ -1458,20 +1458,20 @@ Nach der Ausführung der drei Befehle befindet sich das Rack Projekt in Deinem B
 
 <!--You want to pull the Rack project into your `master` project as a subdirectory. You can do that in Git with `git read-tree`. You’ll learn more about `read-tree` and its friends in Chapter 9, but for now know that it reads the root tree of one branch into your current staging area and working directory. You just switched back to your `master` branch, and you pull the `rack` branch into the `rack` subdirectory of your `master` branch of your main project:-->
 
-Jetzt möchten wir das Rack Projekt in Deinen Branch `master` als Unterverzeichnis hinzufügen. Dies kann man in Git mit dem Befehl `git read-tree` durchführen. In Kapitel 9 werde ich den Befehl `read-tree` und dessen verwandte Befehle näher erläutern. Hier möchte ich nur erklären, dass der Befehl das Wurzelverzeichnis eines Branches in die aktuelle Staging Area und in das Arbeitsverzeichnis packt. Damit hast Du jetzt zu Deinem Branch `master` zurückgewechselt, den Inhalt des Branches `rack` in das Unterverzeichnis `rack` im Branch `master` Deines Projekts hinterlegt:
+Jetzt möchten wir das Rack-Projekt in Deinen Branch `master` als Unterverzeichnis hinzufügen. Dies kann man in Git mit dem Befehl `git read-tree` durchführen. In Kapitel 9 werde ich den Befehl `read-tree` und dessen verwandte Befehle näher erläutern. Hier möchte ich nur erklären, dass der Befehl das Wurzelverzeichnis eines Branches in die aktuelle Staging-Area und in das Arbeitsverzeichnis packt. Damit hast Du jetzt zu Deinem Branch `master` zurückgewechselt, den Inhalt des Branches `rack` in das Unterverzeichnis `rack` im Branch `master` Deines Projekts hinterlegt:
 
 	$ git read-tree --prefix=rack/ -u rack_branch
 
 <!--When you commit, it looks like you have all the Rack files under that subdirectory — as though you copied them in from a tarball. What gets interesting is that you can fairly easily merge changes from one of the branches to the other. So, if the Rack project updates, you can pull in upstream changes by switching to that branch and pulling:-->
 
-Wenn Du jetzt einen Commit ausführst, erscheint es einem so, als ob die ganzen Dateien aus dem Rack Projekt in diesem Unterverzeichnis liegen — als ob man das Projekt aus einem Tarball-Container hineinkopiert hätte. Das Besondere ist jetzt aber, dass man Änderungen zwischen den verschiedenen Branches jetzt einfach zusammenführen kann. Das bedeutet, wenn das Rack Projekt aktualisiert wird, kann man sich diese Änderungen einfach holen, indem man in diesen Branch wechselt und dort einen Pull durchführt:
+Wenn Du jetzt einen Commit ausführst, erscheint es einem so, als ob die ganzen Dateien aus dem Rack-Projekt in diesem Unterverzeichnis liegen — als ob man das Projekt aus einem Tarball-Container hineinkopiert hätte. Das Besondere ist jetzt aber, dass man Änderungen zwischen den verschiedenen Branches jetzt einfach zusammenführen kann. Das bedeutet, wenn das Rack-Projekt aktualisiert wird, kann man sich diese Änderungen einfach holen, indem man in diesen Branch wechselt und dort einen Pull durchführt:
 
 	$ git checkout rack_branch
 	$ git pull
 
 <!--Then, you can merge those changes back into your master branch. You can use `git merge -s subtree` and it will work fine; but Git will also merge the histories together, which you probably don’t want. To pull in the changes and prepopulate the commit message, use the `-\-squash` and `-\-no-commit` options as well as the `-s subtree` strategy option:-->
 
-Danach kann man diese Änderungen wieder in den master Branch mergen. Wenn man den Befehl `git merge -s subtree` verwendet, sollte dies einwandfrei funktionieren. Allerdings wird Git bei Ausführen dieses Befehl auch die jeweilige Historie mergen, was Du wahrscheinlich nicht haben möchtest. Um nun die Änderungen zu holen und eine entsprechende Commit Nachricht vorzubereiten, hängt man einfach `--squash`, `--no-commit` und natürlich `-s subtree` als Option an:
+Danach kann man diese Änderungen wieder in den master-Branch mergen. Wenn man den Befehl `git merge -s subtree` verwendet, sollte dies einwandfrei funktionieren. Allerdings wird Git bei Ausführen dieses Befehls auch die jeweilige Historie mergen, was Du wahrscheinlich nicht haben möchtest. Um nun die Änderungen zu holen und eine entsprechende Commit-Nachricht vorzubereiten, hängt man einfach `--squash`, `--no-commit` und natürlich `-s subtree` als Option an:
 
 	$ git checkout master
 	$ git merge --squash -s subtree --no-commit rack_branch
@@ -1480,7 +1480,7 @@ Danach kann man diese Änderungen wieder in den master Branch mergen. Wenn man d
 
 <!--All the changes from your Rack project are merged in and ready to be committed locally. You can also do the opposite — make changes in the `rack` subdirectory of your master branch and then merge them into your `rack_branch` branch later to submit them to the maintainers or push them upstream.-->
 
-Die ganzen Änderungen des Rack Projekts wurden nun zusammengeführt, Du musst jetzt nur noch einen entsprechenden Commit durchführen. Man kann aber auch genau das Gegenteil machen: Man führt Änderungen im Unterverzeichnis `rack` des master Branches aus und mergt diese dann später in den Zweig `rack_branch`. Diesen kann man dann den Entwicklern des Rack Projekts zur Verfügung stellen.
+Die ganzen Änderungen des Rack-Projekts wurden nun zusammengeführt, Du musst jetzt nur noch einen entsprechenden Commit durchführen. Man kann aber auch genau das Gegenteil machen: Man führt Änderungen im Unterverzeichnis `rack` des master-Branches aus und mergt diese dann später in den Zweig `rack_branch`. Diesen kann man dann den Entwicklern des Rack-Projekts zur Verfügung stellen.
 
 <!--To get a diff between what you have in your `rack` subdirectory and the code in your `rack_branch` branch — to see if you need to merge them — you can’t use the normal `diff` command. Instead, you must run `git diff-tree` with the branch you want to compare to:-->
 
@@ -1499,4 +1499,4 @@ Um Dein Verzeichnis `rack` mit dem letzten Stand des Branches `master` auf dem S
 
 <!--You’ve seen a number of advanced tools that allow you to manipulate your commits and staging area more precisely. When you notice issues, you should be able to easily figure out what commit introduced them, when, and by whom. If you want to use subprojects in your project, you’ve learned a few ways to accommodate those needs. At this point, you should be able to do most of the things in Git that you’ll need on the command line day to day and feel comfortable doing so.-->
 
-In diesem Kapitel hast Du viele ausgeklügelte Werzeuge kennengelernt, die es Dir ermöglichen Commits und die Staging Area nach Deinen Vorstellungen zu beeinflussen. Wenn ein Problem in Deinem Projekt auftaucht, solltest Du jetzt leicht bestimmen können, welcher Commit den Fehler verursacht hat, sowie wann und von wem der Fehler begangen wurde. Wenn Du andere Projekte in Deinem Projekt verwenden möchtest, hast Du jetzt mehrere Möglichkeiten kennengelernt, wie Du dies handhaben kannst. An dieser Stelle solltest Du jetzt in der Lage sein, die meisten Dinge, die Du bei der täglichen Arbeit benötigst, in der Kommandozeile durchzuführen, ohne dass Dir dabei Schweißperlen auf der Stirn stehen.
+In diesem Kapitel hast Du viele ausgeklügelte Werzeuge kennengelernt, die es Dir ermöglichen, Commits und die Staging-Area nach Deinen Vorstellungen zu beeinflussen. Wenn ein Problem in Deinem Projekt auftaucht, solltest Du jetzt leicht bestimmen können, welcher Commit den Fehler verursacht hat, sowie wann und von wem der Fehler begangen wurde. Wenn Du andere Projekte in Deinem Projekt verwenden möchtest, hast Du jetzt mehrere Möglichkeiten kennengelernt, wie Du dies handhaben kannst. An dieser Stelle solltest Du jetzt in der Lage sein, die meisten Dinge, die Du bei der täglichen Arbeit benötigst, in der Kommandozeile durchzuführen, ohne dass Dir dabei Schweißperlen auf der Stirn stehen.

From 7cb2c85cb8492c85107af0f2b91c961136e17637 Mon Sep 17 00:00:00 2001
From: Cor <cor.takken@cgi.com>
Date: Thu, 16 Jan 2014 12:12:07 +0100
Subject: [PATCH 109/690] [nl] Language and wording corrections. Introducing
 characters from ASCII extended.

---
 nl/04-git-server/01-chapter4.markdown | 133 +++++++++++++-------------
 1 file changed, 66 insertions(+), 67 deletions(-)

diff --git a/nl/04-git-server/01-chapter4.markdown b/nl/04-git-server/01-chapter4.markdown
index f2bd2ae65..1d4757358 100644
--- a/nl/04-git-server/01-chapter4.markdown
+++ b/nl/04-git-server/01-chapter4.markdown
@@ -1,22 +1,22 @@
 # Git op de Server #
 
-Op dit punt zou je alledaagse taken waarvoor je Git zult gebruiken kunnen doen. Maar, om samen te kunnen werken in Git, zul je een remote repository moeten hebben. Technisch gezien kun je wijzigingen pushen en pullen van individuele repositories, maar dat wordt afgeraden, omdat je vrij gemakkelijk het werk waar anderen mee bezig zijn in de war kunt schoppen als je niet oppast. Daarnaast wil je dat je medewerkers bij het repository kunnen, zelfs als jouw computer van het netwerk is – het hebben van een betrouwbaar gezamenlijk repository is vaak handig. Daarom heeft het hebben van een tussenliggend repository waarin je met iemand anders samenwerkt de voorkeur, en daaruit kun je dan pushen en pullen. We zullen dit repository de `Git server` noemen, maar je zult zien dat het over het algemeen maar een klein beetje systeembronnen kost om een Git repository te verzorgen, dus je zult er zelden een complete server voor nodig hebben.
+Op dit punt zou je alledaagse taken waarvoor je Git zult gebruiken kunnen doen. Maar, om samen te kunnen werken in Git zul je een remote repository moeten hebben. Technisch gezien kun je wijzigingen pushen en pullen van individuele repositories, maar dat wordt afgeraden, omdat je vrij gemakkelijk het werk waar anderen mee bezig zijn in de war kunt schoppen als je niet oppast. Daarnaast wil je dat je medewerkers de repository kunnen bereiken, zelfs als jouw computer van het netwerk is – het hebben van een betrouwbare gezamenlijke repository is vaak handig. Daarom heeft het hebben van een tussenliggende repository waarin je met iemand anders samenwerkt de voorkeur, en daaruit pushen en pullen. We zullen deze repository de `Git server` noemen, maar je zult zien dat het over het algemeen maar een klein beetje systeembronnen kost om een Git repository te verzorgen, dus je zult er zelden een complete server voor nodig hebben.
 
-Een Git server draaien is eenvoudig. Als eerste kies je met welke protocollen je je server wilt laten communiceren. Het eerste gedeelte van dit hoofdstuk zullen we de beschikbare protocollen bespreken met de voor- en nadelen van elk. De volgende secties zullen veel voorkomende opstellingen bespreken, die van die protocollen gebruik maken hoe je je server ermee kunt opzetten. Als laatste laten we een paar servers van derden zien, als je het niet erg vindt om je code op iemands server te zetten en niet het gedoe wilt hebben van het opzetten en onderhouden van je eigen server.
+Een Git server draaien is eenvoudig. Als eerste kies je met welke protocollen je de server wilt laten communiceren. Het eerste gedeelte van dit hoofdstuk zullen we de beschikbare protocollen bespreken met de voor- en nadelen van elk. De volgende paragrafen zullen we veel voorkomende opstellingen bespreken, die van die protocollen gebruik maken en hoe je je server ermee kunt opzetten. Als laatste laten we een paar servers van derden zien, als je het niet erg vindt om je code op de server van een ander te zetten en niet het gedoe wilt hebben van het opzetten en onderhouden van je eigen server.
 
-Als je geen interesse hebt om je eigen server te draaien, dan kun je de rest overslaan en direct naar het laatste gedeelte van het hoofdstuk gaan om wat mogelijkheden van online accounts te zien en dan door te gaan naar het volgende hoofdstuk, waar we alle zaken bespreken die komen kijken bij het werken met een gedistribueerde versie beheer omgeving.
+Als je geen interesse hebt om je eigen server te draaien, dan kun je de direct naar de laatste paragraaf van dit hoofdstuk gaan om wat mogelijkheden van online accounts te zien en dan door te gaan naar het volgende hoofdstuk, waar we alle zaken bespreken die komen kijken bij het werken met een gedistribueerde versiebeheer omgeving.
 
-Een remote repository is over het algemeen een _bare repository_ (kale repository) – een Git repository dat geen werkmap heeft. Omdat het repository alleen gebruikt wordt als een samenwerkingspunt, is er geen reden om een snapshot op de schijf te hebben; alleen de Git data. Een kale repository is eenvoudigweg de inhoud van de `.git` map in je project, en niets anders.
+Een remote repository is over het algemeen een _bare repository_ (kale repository) – een Git repository dat geen werkmap heeft. Omdat de repository alleen gebruikt wordt als een samenwerkingspunt, is er geen reden om een snapshot op de schijf te hebben; alleen de Git data. Een kale repository is eenvoudigweg de inhoud van de `.git` map in je project, en niets meer.
 
 ## De Protocollen ##
 
-Git kan vier veel voorkomende netwerk protocollen gebruiken om data te transporteren: Lokaal, Beveiligde Shell (SSH), Git en HTTP. Hier laten we zien wat het zijn, en in welke omstandigheden je ze wilt gebruiken (of juist niet).
+Git kan vier veel voorkomende netwerk protocollen gebruiken om data te transporteren: Lokaal, Beveiligde Shell (SSH), Git en HTTP. Hier laten we zien wat deze zijn, en in welke omstandigheden je ze wilt gebruiken (of juist niet).
 
-Het is belangrijk om te zien dat, met uitzondering van de HTTP protocollen, ze allemaal een werkende Git versie op de server geinstalleerd moeten hebben.
+Het is belangrijk om op te merken dat, met uitzondering van de HTTP protocollen, ze allemaal een werkende Git versie op de server geïnstalleerd moeten hebben.
 
 ### Lokaal Protocol ###
 
-Het meest basale is het _lokale protocol_, waarbij het remote repository in een andere map op de schijf is. Dit wordt vaak gebruikt als iedereen in je team toegang heeft op een gedeeld bestandssyteem zoals een NFS map, of in het weinig voorkomende geval dat iedereen in dezelfde computer werkt. Het laatste zou niet ideaal zijn, want dan zouden alle repositories zich op dezelfde computer bevinden, zodat de kans op een fataal verlies veel groter wordt.
+Het meest basale is het _lokale protocol_, waarbij het remote repository in een andere map op de schijf staat. Deze opzet wordt vaak gebruikt als iedereen in het team toegang heeft op een gedeeld bestandssyteem zoals een NFS map, of in het weinig voorkomende geval dat iedereen op dezelfde computer werkt. Het laatste zou niet ideaal zijn, want dan zouden alle repositories op dezelfde computer staan, zodat de kans op een fataal verlies veel groter wordt.
 
 Als je een gedeeld bestandssyteem hebt, dan kun je clonen, pushen en pullen van een op een lokaal bestand gebaseerde repository. Om een dergelijk repository te clonen, of om er een als een remote aan een bestaand project toe te voegen, moet je het pad naar het repository als URL gebruiken. Bijvoorbeeld, om een lokaal repository te clonen, kun je zoiets als dit uitvoeren:
 
@@ -26,29 +26,29 @@ Of je kunt dit doen:
 
 	$ git clone file:///opt/git/project.git
 
-Git werkt iets anders als je explicite `file://` aan het begin van de URL zet. Als je alleen het pad specificeert, probeert Git hardlinks te gebruiken, of het kopieert de bestanden die het nodig heeft. Als je `file://` specificeert, dan start Git de processen die het normaal gebruikt om data te transporteren over een netwerk, wat over het algemeen een stuk minder efficiente methode is om data te transporteren. De reden om `file://` wel te specificeren is als je een schone kopie van de repository wilt met de extra referenties of objecten eruit gelaten – over het algemeen na een import van een ander versie beheer systeem of iets dergelijks (zie Hoofdstuk 9 voor onderhoudstaken). We zullen het normale pad hier gebruiken, omdat het bijna altijd sneller is om het zo te doen.
+Git werkt iets anders als je explicite `file://` aan het begin van de URL zet. Als je alleen het pad specificeert, probeert Git hardlinks te gebruiken, of het kopieert de bestanden die het nodig heeft. Als je `file://` specificeert, dan start Git de processen die het normaal gesproken gebruikt om data te transporteren over een netwerk, wat over het algemeen een minder efficiënte methode is om data te transporteren. De reden om `file://` wel te specificeren is als je een schone kopie van de repository wilt met de extra referenties of objecten eruit gelaten – over het algemeen na een import van een ander versiebeheer systeem of iets dergelijks (zie Hoofdstuk 9 voor onderhoudstaken). We zullen het normale pad hier gebruiken, omdat het bijna altijd sneller is om het zo te doen.
 
-Om een lokaal repository aan een bestaand Git project toe te voegen, kun je zoiets als dit uitvoeren:
+Om een lokale repository aan een bestaand Git project toe te voegen, kun je zoiets als het volgende uitvoeren:
 
 	$ git remote add local_proj /opt/git/project.git
 
-Daarna kun je pushen en pullen van dat remote alsof je over een netwerk werkt.
+Daarna kun je pushen en pullen van die remote alsof je over een netwerk werkt.
 
 #### De Voordelen ####
 
-De voordelen van bestands-gebaseerde repositories zijn dat ze eenvoudig zijn en ze maken gebruik van bestaande bestandspermissies en netwerk toegang. Als je al een gedeeld bestandssysteem hebt, waar je hele team al toegang tot heeft, dan is een repository opzetten heel gemakkelijk. Je stopt de kale repository ergens waar iedereen gedeelde toegang tot heeft, en stelt de lees- en schrijfrechten in zoals je dat bij iedere andere gedeelde map zou doen. In de volgende sectie "Git op een Server krijgen" bespreken we hoe je een kopie van een kale repository kunt exporteren voor dit doeleind.
+De voordelen van bestands-gebaseerde repositories zijn dat ze eenvoudig zijn en ze maken gebruik van bestaande bestandspermissies en netwerk toegang. Als je al een gedeeld bestandssysteem hebt, waar je hele team al toegang tot heeft, dan is een repository opzetten heel gemakkelijk. Je stopt de kale repository ergens waar iedereen gedeelde toegang tot heeft, en stelt de lees- en schrijfrechten in zoals je dat bij iedere andere gedeelde map zou doen. In de volgende paragraaf "Git op een Server Krijgen" bespreken we hoe je een kopie van een kale repository kunt exporteren voor dit doeleinde.
 
-Dit is ook een fijne optie om snel werk van een repository van iemand anders te pakken. Als jij en een collega aan hetzelfde project aan het werk zijn, en hij wil dat je iets bekijkt, dan is het uitvoeren van een commando zoals `git pull /home/john/project` vaak makkelijker dan dat hij naar een remote server moet pushen, en jij er van moet pullen.
+Dit is ook een prettige optie om snel werk van een repository van iemand anders te pakken. Als jij en een collega aan hetzelfde project werken, en hij wil dat je iets bekijkt, dan is het uitvoeren van een commando zoals `git pull /home/john/project` vaak makkelijker dan dat hij naar een remote server moet pushen, en jij er van moet pullen.
 
 #### De Nadelen ####
 
 Een van de nadelen van deze methode is dat gedeelde toegang over het algemeen moeilijker op te zetten en te bereiken is vanaf meerdere lokaties dan basaal netwerk toegang. Als je wilt pushen van je laptop als je thuis bent, dan moet je de remote schijf aankoppelen, wat moeilijk en langzaam kan zijn in vergelijking tot netwerk gebaseerde toegang.
 
-Het is ook belangrijk om te melden dat het niet noodzakelijk de snelste optie is, als je een gedeeld koppelpunt of iets dergelijks gebruikt. Een lokale repository is alleen snel als je snelle toegang tot de data hebt. Een repository op NFS is vaak langzamer dan het repository via SSH op dezelfde server, wat Git toelaat om vanaf lokale schijven te werken op ieder systeem.
+Het is ook belangrijk om te vermelden dat het niet altijd de snelste optie is, als je een gedeeld koppelpunt (mount) of iets dergelijks gebruikt. Een lokale repository is alleen snel als je snelle toegang tot de data hebt. Een repository op NFS is vaak langzamer dan een repository via SSH op dezelfde server omdat dit Git in staat stelt om op lokale schijven te werken vanaf ieder systeem.
 
 ### Het SSH Protocol ###
 
-Waarschijnlijk het meest voorkomende protocol voor Git is SSH. Dit is omdat SSH toegang tot servers in veel plaatsen al geconfigureerd is – en als dat niet het geval is, dan is het makkelijk om dat te doen. SSH is ook het enige netwerk gebaseerde protocol waarvan je makkelijk kunt lezen en naartoe kunt schrijven. De andere twee netwerk protocollen (HTTP en Git) zijn over het algemeen alleen-lezen, dus zelfs als je ze al beschikbaar hebt voor de ongeinitieerden, dan heb je nog steeds SSH nodig voor je eigen schrijftoegang. SSH is ook een geverifieerd protocol; en omdat het overal voorkomt, is het over het algemeen eenvoudig om in te stellen en te gebruiken.
+Waarschijnlijk het meest voorkomende protocol voor Git is SSH. Met als reden dat toegang met SSH tot servers in veel plaatsen al geconfigureerd is – en als dat niet het geval is, dan is het eenvoudig om dat te doen. SSH is ook het enige netwerk gebaseerde protocol waarvan je makkelijk kunt lezen en naartoe kunt schrijven. De andere twee netwerk protocollen (HTTP en Git) zijn over het algemeen alleen-lezen, dus zelfs als je ze al beschikbaar hebt voor de ongeïnitieerden, dan heb je nog steeds SSH nodig voor je eigen schrijftoegang. SSH is ook een geauthenticieerd protocol; en omdat het overal voorkomt, is het over het algemeen eenvoudig om in te stellen en te gebruiken.
 
 Om een Git repository via SSH te clonen, kun je een ssh:// URL opgeven zoals:
 
@@ -58,32 +58,32 @@ Of je geeft geen protocol op – Git gaat uit van SSH als je niet expliciet bent
 	
 	$ git clone user@server:project.git
 
-Je kunt ook de gebruiker niet opgeven, en Git neemt aan dat je de gebruiker bedoelt waarmee je op het moment bent ingelogged.
+Je kunt ook de gebruiker niet opgeven, en Git neemt aan dat je de gebruiker bedoelt waarmee je op het moment bent ingelogd.
 
 #### De Voordelen ####
 
-Er zijn vele voordelen om SSH te gebruiken. De eerste is dat je het eigenlijk wel moet gebruiken als je geverifieerde schrijftoegang op je repository via een netwerk wilt. Het tweede is dat het relatief eenvoudig in te stellen is – SSH daemons komen veel voor, veel systeembeheerders hebben er ervaring mee, en veel operating systemen zijn er mee uitgerust of hebben applicaties om ze te beheren. Daarnaast is toegang via SSH veilig – alle data transporten zijn versleuteld en geverifieerd. En als laatste is SSH efficient, zoals het Git en lokale protocol, waarbij de data zo compact mogelijk wordt gemaakt voordat het getransporteerd wordt.
+Er zijn vele voordelen om SSH te gebruiken. De eerste is dat je het eigenlijk wel moet gebruiken als je geauthenticeerde schrijftoegang op je repository via een netwerk wilt. Het tweede is dat het relatief eenvoudig in te stellen is – SSH daemons komen veel voor, veel systeembeheerders hebben er ervaring mee, en veel operating systemen zijn er mee uitgerust of hebben applicaties om ze te beheren. Daarnaast is toegang via SSH veilig – alle data transporten zijn versleuteld en geauthenticeerd. En als laatste is SSH efficiënt, net zoals het Git en lokale protocol, de data wordt zo compact mogelijk gemaakt voordat het getransporteerd wordt.
 
 #### De Nadelen ####
 
-Het negatieve aspect van SSH is dat je er geen anonieme toegang over kunt geven. Mensen moeten via SSH toegang hebben om er gebruik van te kunnen maken, zelfs als het alleen lezen is, zodat SSH toegang niet bevordelijk is voor open source projecten. Als je het alleen binnen je bedrijfsnetwerk gebruikt, dan kan SSH misschien het enige protocol zijn waar je mee in aanraking komt. Als je anonieme alleen-lezen toegang wilt toestaan tot je projecten, dan moet je SSH voor jezelf instellen om over te pushen, maar iets anders voor anderen om over te pullen.
+Het negatieve aspect van SSH is dat je er geen anonieme toegang over kunt geven. Mensen moeten via SSH toegang hebben om er gebruik van te kunnen maken, zelfs als het alleen lezen is, zodat SSH toegang niet bevordelijk is voor open source projecten. Als je het alleen binnen je bedrijfsnetwerk gebruikt, dan is SSH misschien het enige protocol waar je mee in aanraking komt. Als je anonieme alleen-lezen toegang wilt toestaan tot je projecten, dan moet je SSH voor jezelf instellen om over te pushen, maar iets anders voor anderen om over te pullen.
 
 ### Het Git Protocol ###
 
-Het volgende is het Git protocol. Dit is een aparte daemon, die samen met Git geleverd wordt; het luistert op een toegewezen poort (9418), dat een vergelijkbare dienst verleend als het SSH protocol, maar dan zonder enige verificatie. Om een repository te serveren over het Git protocol, moet je het `git-export-daemon-ok` bestand aanmaken – de daemon zal een repository zonder dit bestand erin niet serveren – maar buiten dat is er geen beveiliging. Ofwel het Git repository is er om gecloned te kunnen worden door iedereen, of het is er helemaal niet. Dit betekent dat er over het algemeen geen pushing is via dit protocol. Je kunt push toegang aanzetten; maar gegeven het gebrek aan verificatie als je push toegang aan zet, kan iedereen die de URL van jouw project op het internet vindt, pushen naar jouw project. We volstaan met te zeggen dat dit zeldzaam is.
+Het volgende is het Git protocol. Dit is een aparte daemon, die met Git meegeleverd wordt; het luistert op een toegewezen poort (9418), en verleent een vergelijkbare dienst als het SSH protocol, maar dan zonder enige authenticatie. Om een repository beschikbaar te stellen over het Git protocol, moet je het `git-export-daemon-ok` bestand aanmaken – de daemon zal een repository zonder dit bestand erin niet verspreiden – maar buiten dat is er geen beveiliging. Oftewel: de Git repository is er om gecloned te kunnen worden door iedereen, of het is er helemaal niet. Dit betekent dat er over het algemeen geen pushing is via dit protocol. Je kunt push toegang aanzetten, maar gegeven het gebrek aan authenticatie kan, als je de push toegang aan zet, iedereen die de URL van jouw project op het internet vindt, pushen naar jouw project. We volstaan met te zeggen dat dit zeldzaam is.
 
 #### De Voordelen ####
 
-Het Git protocol is het snelste dat beschikbaar is. Als je veel verkeer serveert voor een publiek project, of een zeer groot project dat geen gebruikersverificatie nodig heeft voor leestoegang, dan is het waarschijnlijk dat je een Git daemon wilt instellen om je project te serveren. Het maakt van hetzelfde data-transport mechanisme gebruik als het SSH protocol, maar dan zonder de extra belasting van versleuteling en verificatie.
+Het Git protocol is het snelste dat beschikbaar is. Als je veel verkeer verwerkt voor een publiek project, of een zeer groot project dat geen gebruikersauthenticatie nodig heeft voor leestoegang, dan is het waarschijnlijk dat je een Git daemon wilt inrichten om je project te verspreiden. Het maakt van hetzelfde data-transport mechanisme gebruik als het SSH protocol, maar dan zonder de extra belasting van versleuteling en authenticatie.
 
 #### De Nadelen ####
 
-Het nadeel van het Git protocol is het gebrek van verificatie. Het is over het algemeen onwenselijk dat het Git protocol de enige toegang tot je project is. Over het algemeen zul je het samen met SSH toegang gebruiken voor de paar ontwikkelaars die push (schrijf-)toegang hebben en de rest laat je `git://` voor alleen leestoegang gebruiken.
-Het is waarschijnlijk ook het meest ingewikkelde protocol om in te stellen. Het moet een eigen daemon hebben, die speciaal ontworpen is – we zullen er een instellen in het "Gitosis" gedeelte van dit hoofdstuk – het gebruikt `xinetd` configuratie of iets dergelijks, wat niet altijd eenvoudig is. Het heeft ook firewall toegang tot poort 9418 nodig, wat geen standaard poort is dat bedrijfsfirewalls altijd toestaan. Achter grote bedrijfsfirewalls, is deze obscure poort meestal geblokkeerd.
+Het nadeel van het Git protocol is het gebrek aan authenticatie. Het is over het algemeen onwenselijk dat het Git protocol de enige toegang tot je project is. Meestal zul je het samen met SSH toegang gebruiken voor de paar ontwikkelaars die push (schrijf-)toegang hebben en de rest laat je `git://` voor alleen leestoegang gebruiken.
+Het is waarschijnlijk ook het meest ingewikkelde protocol om in te stellen. Het moet een eigen daemon hebben, die speciaal voor die situatie ingericht is – we zullen er een instellen in het "Gitosis" gedeelte van dit hoofdstuk – het gebruikt `xinetd` configuratie of iets dergelijks, wat ook niet altijd eenvoudig is op te zetten. Het heeft ook firewall toegang tot poort 9418 nodig, wat geen standaard poort is dat in bedrijfsfirewalls is opengezet. Bij firewalls van grote bedrijven, is deze obscure poort meestal geblokkeerd.
 
 ### Het HTTP/S Protocol ###
 
-Als laatste hebben we het HTTP protocol. Het mooie aan het HTTP of HTTPS protocol is dat het simpel in te stellen is. Eigenlijk is alles wat je moet doen de kale Git repository in je HTTP document root zetten, en een specifieke `post-update` hook (haak) instellen en je bent klaar (zie hoofdstuk 7 voor details over Git hooks). Vanaf dat moment kan iedereen die toegang heeft tot de webserver waaronder je de repository gezet hebt ook je repository clonen. Om leestoegang tot je repository over HTTP toe te staan, doe je zoiets als het volgende:
+Als laatste hebben we het HTTP protocol. Het mooie aan het HTTP of HTTPS protocol is dat het simpel in te stellen is. Eigenlijk is alles wat je moet doen de kale Git repository in je HTTP document root zetten, en een specifieke `post-update` hook (haak) instellen en je bent klaar (zie hoofdstuk 7 voor details over Git hooks). Vanaf dat moment kan iedereen die toegang heeft tot de webserver waar je de repository op gezet hebt ook je repository clonen. Om leestoegang tot je repository over HTTP toe te staan, doe je zoiets als het volgende:
 
 	$ cd /var/www/htdocs/
 	$ git clone --bare /path/to/git_project gitproject.git
@@ -95,25 +95,25 @@ Dat is alles. De `post-update` hook, die standaard bij Git zit, voert het noodza
 
 	$ git clone http://example.com/gitproject.git
 
-In dit geval, gebruiken we het `/var/www/htdocs` pad wat gebruikelijk is voor Apache opstellingen, maar je kunt iedere statische webserver gebruiken – stop de kale repository in haar pad. De Git data wordt geserveerd als standaard statische bestanden (zie hoofdstuk 9 voor details over hoe het precies geserveerd wordt).
+In dit specifieke geval gebruiken we het `/var/www/htdocs` pad wat gebruikelijk is voor Apache opstellingen, maar je kunt iedere statische webserver gebruiken – stop de kale repository in haar pad. De Git data wordt geserveerd als standaard statische bestanden (zie hoofdstuk 9 voor details over hoe het precies geserveerd wordt).
 
-Het ook is mogelijk om Git over HTTP te laten pushen, alhoewel dat geen veelgebruikte techniek is en erom vraagt dat je complexe WebDAV vereisten insteld. Omdat het zelden gebruikt wordt, zullen we het niet in dit boek beschrijven. Als je geinteresseerd bent om de HTTP-push protocollen te gebruiken, dan kun je op `http://www.kernel.org/pub/software/scm/git/docs/howto/setup-git-server-over-http.txt` lezen hoe je een repository kunt maken. Een fijn ding aan Git laten pushen over HTTP is dat je iedere WebDAV server kunt gebruiken, zonder specifieke Git eigenschappen; dus je kunt deze functionaliteit gebruiken als je web-hosting provider WebDAV ondersteunt voor schrijf vernieuwingen aan je webpagina.
+Het ook is mogelijk om Git over HTTP te laten pushen, alhoewel dat geen veelgebruikte techniek is en het vraagt dat je complexe WebDAV instellingen opzet. Omdat het zelden gebruikt wordt, zullen we het niet in dit boek beschrijven. Als je geïnteresseerd bent om de HTTP-push protocollen te gebruiken, dan kun je op `http://www.kernel.org/pub/software/scm/git/docs/howto/setup-git-server-over-http.txt` lezen hoe je een repository kunt maken. Een fijn ding aan Git laten pushen over HTTP is dat je iedere WebDAV server kunt gebruiken, zonder specifieke Git funtionaliteit; dus je kunt deze functionaliteit gebruiken als je web-hosting provider WebDAV ondersteunt voor het maken van wijzigingen aan je webpagina.
 
 #### De Voordelen ####
 
-Het voordeel van het gebruik van het HTTP protocol is dat het eenvoudig in te stellen is. Een handvol benodigde commando's uitvoeren zorgt voor een eenvoudige manier om de wereld leestoegang te geven aan je Git repository. Het kost slechts een paar minuten om te doen. Het HTTP protocol is niet erg belastend voor de systeembronnen van je server. Omdat het over het algemeen een statische webserver gebruikt om alle data te serveren, een normale Apache server kan gemiddeld duizenden bestanden serveren per seconde – is het moeilijk om zelfs een kleine server te overbelasten.
+Het voordeel van het gebruik van het HTTP protocol is dat het eenvoudig in te stellen is. Een handvol benodigde commando's uitvoeren zorgt voor een eenvoudige manier om de wereld leestoegang te geven tot je Git repository. Het kost slechts een paar minuten om te doen. Het HTTP protocol is niet erg belastend voor de systeembronnen van je server. Omdat het over het algemeen een statische webserver gebruikt om alle data te verspreiden - een normale Apache server kan gemiddeld duizenden bestanden zenden per seconde - is het moeilijk om zelfs een kleine server te overbelasten.
 
-Je kunt ook je repositories alleen-lezen serveren via HTTPS, wat betekend dat je het transport kunt versleutelen; of je kunt zelfs zover gaan dat je clients een specifiek gesigneerd SSL certificaat moeten gebruiken. Als je over het algemeen zo ver gaat, dan is het makkelijker om publieke SSH sleutels te gebruiken; maar het kan een betere oplossing in jouw specifieke geval om gesigneerde SSL certificaten of andere HTTP-gebaseerde verificatie methoden te gebruiken voor alleen-lezen toegang via HTTPS.
+Je kunt ook je repositories alleen-lezen serveren via HTTPS, wat inhoudt dat je het transport kunt versleutelen; je kunt zelfs zover gaan dat je clients een specifiek gesigneerd SSL certificaat laat gebruiken. Normaal gesproken als je je deze moeite wilt getroosten, dan is het makkelijker om publieke SSH sleutels te gebruiken; maar het kan een betere oplossing in jouw specifieke geval zijn om gesigneerde SSL certificaten of andere HTTP-gebaseerde authenticatie methoden te gebruiken voor alleen-lezen toegang via HTTPS.
 
-Een ander fijn ding is dat HTTP zo'n veel voorkomend protocol is dat bedrijfsfirewalls vaak zo ingesteld zijn dat ze verkeerd via deze poort toelaten.
+Een andere prettige bijkomstigheid is dat HTTP een dusdanig veel voorkomend protocol is dat bedrijfsfirewalls vaak zo ingesteld zijn dat ze verkeer via deze poort toestaan.
 
 #### De Nadelen ####
 
-Het nadeel van je repository serveren via HTTP is dat het relatief inefficient voor de client is. Over het algemeen duurt het een stuk langer om te clonen en te fetchen van de repository, en je hebt vaak een stuk meer netwerk belasting en transport volume via HTTP dan met elk van de andere netwerk protocollen. Omdat het niet zo ingewikkeld is om alleen de data te versturen die je nodig hebt – er wordt geen dynamisch werk door de server gedaan in deze transacties – wordt vaak naar het HTTP protocol gerefereerd als zijnde een _dom_ protocol. Voor meer informatie over de verschillen in efficientie tussen het HTTP protocol en andere protocollen, zie Hoofdstuk 9.
+Het nadeel van je repository verspreiden via HTTP is dat het relatief inefficiënt voor de client is. Over het algemeen duurt het een stuk langer om te clonen en te fetchen van de repository, en je hebt vaak een veel hogere netwerk belasting en transport volume via HTTP dan met elk van de andere netwerk protocollen. Omdat het niet zo ingewikkeld is om alleen de data te versturen die je nodig hebt – er wordt geen dynamisch werk door de server gedaan in deze transacties – wordt vaak naar het HTTP protocol gerefereerd als zijnde een _dom_ protocol. Voor meer informatie over de verschillen in efficiëntie tussen het HTTP protocol en andere protocollen, zie Hoofdstuk 9.
 
 ## Git op een Server Krijgen ##
 
-Om een initiele Git server op te zetten, moet je een bestaande repository in een kale repository exporteren – een repository dat geen werkmap bevat. Dit is over het algemeen eenvoudig te doen.
+Om een initiële Git server op te zetten, moet je een bestaande repository naar een kale repository exporteren – een repository dat geen werkmap bevat. Dit is over het algemeen eenvoudig te doen.
 Om je repository te clonen met als doel het maken van een kale repository, voer je het clone commando uit met de `--bare` optie. Als vaste gewoonte eindigen de namen van kale repository mappen in `.git`, zoals:
 
 	$ git clone --bare my_project my_project.git
@@ -125,11 +125,11 @@ Dit is ongeveer gelijk aan
 
 	$ cp -Rf my_project/.git my_project.git
 
-Er zijn een paar kleine verschillen in het configuratie bestand; maar voor jouw doeleinde ligt dit dicht bij hetzelfde. Het neemt de Git repository zelf, zonder een werkmap, en maakt een map aan specifiek alleen voor dat ding.
+Er zijn een paar kleine verschillen in het configuratie bestand, maar het komt op hetzelfde neer. Het neemt de Git repository zelf, zonder een werkmap, en maakt een map aan specifiek hiervoor.
 
 ### Het Bare Repository op een Server Zetten ###
 
-Nu dat je een kale kopie van je repository hebt, is het enige dat je moet doen het op een server zetten en je protocollen instellen. Stel dat je een server ingesteld hebt, die `git.example.com` heet, waar je SSH toegang op hebt, en waar je al je Git repositories wilt opslaan onder de `/opt/git` map. Je kunt je nieuwe repository instellen door je kale repository ernaartoe te kopieeren:
+Nu je een kale kopie van je repository hebt, is het enige dat je moet doen het op een server zetten en je protocollen instellen. Stel dat je een server ingesteld hebt, die `git.example.com` heet, waar je SSH toegang op hebt, en waar je al je Git repositories wilt opslaan onder de `/opt/git` map. Je kunt je nieuwe repository beschikbaar stellen door je kale repository ernaartoe te kopieeren:
 
 	$ scp -r my_project.git user@git.example.com:/opt/git
 
@@ -137,7 +137,7 @@ Op dit punt kunnen andere gebruikers, die SSH toegang hebben tot dezelfde server
 
 	$ git clone user@git.example.com:/opt/git/my_project.git
 
-Als een gebruiker in een server SSH-ed en schrijftoegang heeft tot de `/opt/git/my_project.git` map, dan hebben ze automatisch ook push toegang. Git zal automatisch correcte groep schrijfrechten aan een repository toevoegen als je het `git init` commando met de `--shared` optie uitvoert.
+Als een gebruiker met SSH op een server inlogt en schrijftoegang heeft tot de `/opt/git/my_project.git` map, dan hebben ze automatisch ook push toegang. Git zal automatisch de correcte groep schrijfrechten aan een repository toekennen als je het `git init` commando met de `--shared` optie uitvoert.
 
 	$ ssh user@git.example.com
 	$ cd /opt/git/my_project.git
@@ -145,9 +145,9 @@ Als een gebruiker in een server SSH-ed en schrijftoegang heeft tot de `/opt/git/
 
 Je ziet hoe eenvoudig het is om een Git repository te nemen, een kale versie aan te maken, en het op een server plaatsen waar jij en je medewerkers SSH toegang tot hebben. Nu ben je klaar om aan hetzelfde project samen te werken.
 
-Het is belangrijk om te zien dat dit letterlijk alles is wat je moet doen om een bruikbare Git server te draaien waarop meerdere mensen toegang hebben – voeg alleen een paar SSH accounts toe op een server, en stop een kale repository ergens waar al die gebruikers lees- en schrijftoegang tot hebben. Je bent er klaar voor – je hebt niets anders nodig.
+Het is belangrijk om op te merken dat dit letterlijk alles is wat je moet doen om een bruikbare Git server te draaien waarop meerdere mensen toegang hebben – voeg alleen een paar SSH accounts toe op een server, en stop een kale repository ergens waar al die gebruikers lees- en schrijftoegang toe hebben. Je bent er klaar voor – je hebt niets anders nodig.
 
-In de volgende secties zul je zien hoe je meer ingewikkelde opstellingen kunt maken. Deze bespreking zal het niet hoeven aanmaken van gebruikers accounts voor elke gebruiker, publieke leestoegang tot repositories, grafische web interfaces, de Gitosis applicatie gebruiken en meer omvatten. Maar, hou in gedachten dat om samen te kunnen werken met mensen op een prive project, alles wat je _nodig_ hebt is een SSH server en een kale repository.
+In de volgende paragrafen zul je zien hoe je meer ingewikkelde opstellingen kunt maken. Deze bespreking zal het niet hoeven aanmaken van gebruikers accounts voor elke gebruiker, publieke leestoegang tot repositories, grafische web interfaces, de Gitosis applicatie gebruiken en meer omvatten. Maar, hou in gedachten dat om samen te kunnen werken met mensen op een privé project, alles wat je _nodig_ hebt is een SSH server en een kale repository.
 
 ### Kleine Opstellingen ###
 
@@ -155,20 +155,20 @@ Als je met een kleine groep bent of net begint met Git in je organisatie en slec
 
 #### SSH Toegang ####
 
-Als je reeds een server hebt waar al je ontwikkelaars SSH toegang op hebben, dan is het over het algemeen het gemakkelijkst om je eerste repository daar in te stellen, omdat je dan bijna niets hoeft te doen (zoals beschreven in de vorige sectie). Als je meer complexe toegangscontrole wilt op je repositories, dan kun je ze instellen met de normale bestandssysteem permissies van het operating systeem dat op je server draait.
+Als je reeds een server hebt waar al je ontwikkelaars SSH toegang op hebben, dan is het over het algemeen het eenvoudigste om je eerste repository daar in te stellen, omdat je dan bijna niets hoeft te doen (zoals beschreven in de vorige paragraaf). Als je meer complexe toegangscontrole wilt op je repositories, dan kun je ze instellen met de normale bestandssysteem permissies van het operating systeem dat op je server draait.
 
-Als je je repositories op een server wilt zetten, die geen accounts heeft voor iedereen in je team die je schrijftoegang wilt geven, dan moet je SSH toegang voor ze instellen. We gaan er vanuit dat je een server hebt waarmee je dit kunt doen, je reeds een SSH server geinstalleerd hebt, en dat de manier is waarop je toegang hebt tot de server.
+Als je je repositories op een server wilt zetten, die geen accounts heeft voor iedereen in je team die je schrijftoegang wilt geven, dan moet je SSH toegang voor ze instellen. We gaan er vanuit dat je een server hebt waarmee je dit kunt doen, dat je reeds een SSH server geïnstalleerd hebt, en dat de manier is waarop je toegang hebt tot de server.
 
-Er zijn een paar manieren waarop je iedereen in je team toegang kunt geven. De eerste is voor iedereen accounts aanmaken, wat rechttoe rechtaan is maar omslachtig kan zijn. Je wilt misschien niet `adduser` uitvoeren en tijdelijke wachtwoorden voor iedere gebruiker instellen.
+Er zijn een paar manieren waarop je iedereen in je team toegang kunt geven. De eerste is voor iedereen accounts aanmaken, wat rechttoe rechtaan is maar bewerkelijk kan zijn. Je wilt vermoedelijk niet `adduser` uitvoeren en tijdelijke wachtwoorden instellen voor iedere gebruiker.
 
-Een tweede methode is een 'git' gebruiker aanmaken op de machine, aan iedere gebruiker die schijftoegang moet hebben vragen of ze je een publieke SSH sleutel sturen, en die sleutel toevoegen aan het `~/.ssh/authorized_keys` bestand van je nieuwe 'git' gebruiker. Vanaf dat punt zal iedereen toegang hebben op die machine via de 'git' gebruiker. Dit tast de commit data op geen enkele manier aan – de SSH gebruiker waarmee je inlogged zal de commits die je opgeslagen hebt niet beinvloeden.
+Een tweede methode is een 'git' gebruiker aan te maken op de machine, aan iedere gebruiker die schijftoegang moet hebben vragen of ze je een publieke SSH sleutel sturen, en die sleutel toevoegen aan het `~/.ssh/authorized_keys` bestand van je nieuwe 'git' gebruiker. Vanaf dat moment zal iedereen toegang hebben op die machine via de 'git' gebruiker. Dit tast de commit data op geen enkele manier aan – de SSH gebruiker waarmee je inlogt zal de commits die je opgeslagen hebt niet beïnvloeden.
 
-Een andere manier waarop je het kunt doen is je SSH server laten verifieren vanaf een LDAP server of een andere gecentraliseerde verificatie bron, die je misschien al ingesteld hebt. Zolang iedere gebruiker een shell toegang heeft op de machine, zou ieder SSH verificatie mechanisme dat je kunt bedenken moeten werken.
+Een andere manier waarop je het kunt doen is je SSH server laten authenticeren middels een LDAP server of een andere gecentraliseerde authenticatie bron, die je misschien al ingesteld hebt. Zolang iedere gebruiker shell toegang kan krijgen op de machine, zou ieder SSH authenticatie mechanisme dat je kunt bedenken moeten werken.
 
 ## Je Publieke SSH Sleutel Genereren ##
 
-Dat gezegd hebbende, zijn er vele Git servers die verifieren met een publieke SSH sleutel. Om een publieke sleutel te hebben, zal iedere gebruiker in je systeem er een moeten genereren als ze er nog geen hebben. Dit proces is bij alle operating systemen vergelijkbaar.
-Als eerste moet je controleren dat je er niet al een hebt. Standaard staan de SSH sleutels van de gebruikers in hun eigen `~/.ssh` map. Je kunt makkelijk nagaan of je al een sleutel hebt door naar die map te gaan en de inhoud te tonen:
+Dat gezegd hebbende, zijn er vele Git servers die authenticeren met een publieke SSH sleutel. Om een publieke sleutel te hebben, zal iedere gebruiker in je systeem er een moeten genereren als ze er nog geen hebben. Dit proces is bij alle operating systemen vergelijkbaar.
+Als eerste moet je controleren dat je er niet al een hebt. Standaard staan de SSH sleutels van de gebruikers in hun eigen `~/.ssh` map. Je kunt makkelijk nagaan of je al een sleutel hebt door naar die map te gaan en de inhoud te bekijken:
 
 	$ cd ~/.ssh
 	$ ls
@@ -187,9 +187,9 @@ Je bent op zoek naar een aantal bestanden genaamd iets en iets.pub, waarbij het
 	The key fingerprint is:
 	43:c5:5b:5f:b1:f1:50:43:ad:20:a6:92:6a:1f:9a:3a schacon@agadorlaptop.local
 
-Eerst bevestigt het de lokatie waar je de sleutel wilt opslaan (`.ssh/id_rsa`), en vervolgens vraagt het tweemaal om een wachtzin, die je leeg kunt laten als je geen wachtwoord wilt intypen op het moment dat je de sleutel gebruikt.
+Eerst bevestigt het de lokatie waar je de sleutel wilt opslaan (`.ssh/id_rsa`), en vervolgens vraagt het tweemaal om een wachtwoord, die je leeg kunt laten als je geen wachtwoord wilt intypen op het moment dat je de sleutel gebruikt.
 
-Iedere gebruiker die dit doet, moet zijn sleutel sturen naar jou of degene die de Git server beheert (aangenomen dat je een SSH server gebruikt die publieke sleutels vereist). Het enige dat ze hoeven doen is de inhoud van het `.pub` bestand kopieeren en e-mailen. De publieke sleutel ziet er ongeveer zo uit:
+Iedere gebruiker die dit doet, moet zijn sleutel sturen naar jou of degene die de Git server beheert (aangenomen dat je een SSH server gebruikt die publieke sleutels vereist). Het enige dat ze hoeven doen is de inhoud van het `.pub` bestand kopiëren en e-mailen. De publieke sleutel ziet er ongeveer zo uit:
 
 	$ cat ~/.ssh/id_rsa.pub 
 	ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAklOUpkDHrfHY17SbrmTIpNLTGK9Tjom/BWDSU
@@ -203,7 +203,7 @@ Voor een uitgebreide tutorial over het aanmaken van een SSH sleutel op meerdere
 
 ## De Server Instellen ##
 
-Laten we het instellen van SSH toegang aan de server kant eens doorlopen. In dit voorbeeld zul je de `authorized_keys` methode gebruiken om je gebruikers te verifieren. We gaan er ook vanuit dat je een standaard Linux distributie gebruikt zoals Ubuntu. Als eerste creeer je een 'git' gebruiker een een `.ssh` map voor die gebruiker.
+Laten we het instellen van SSH toegang aan de server kant eens doorlopen. In dit voorbeeld zul je de `authorized_keys` methode gebruiken om je gebruikers te authenticeren. We gaan er ook vanuit dat je een standaard Linux distributie gebruikt zoals Ubuntu. Als eerste maak je een 'git' gebruiker aan en een `.ssh` map voor die gebruiker.
 
 	$ sudo adduser git
 	$ su git
@@ -220,20 +220,20 @@ Daarna moet je een aantal publieke SSH sleutels van ontwikkelaars aan het `autho
 	O7TCUSBdLQlgMVOFq1I2uPWQOkOWQAHukEOmfjy2jctxSDBQ220ymjaNsHT4kgtZg2AYYgPq
 	dAv8JggJICUvax2T9va5 gsg-keypair
 
-Je voegt ze slechts toe aan je `authorized_keys` bestand:
+Je voegt ze eenvoudigweg toe aan je `authorized_keys` bestand:
 
 	$ cat /tmp/id_rsa.john.pub >> ~/.ssh/authorized_keys
 	$ cat /tmp/id_rsa.josie.pub >> ~/.ssh/authorized_keys
 	$ cat /tmp/id_rsa.jessica.pub >> ~/.ssh/authorized_keys
 
-Nu kun je een leeg repository voor ze instellen door `git init` uit te voeren met de `--bare` optie, wat het repository initialiseert zonder een werkmap:
+Nu kun je een lege repository voor ze instellen door `git init` uit te voeren met de `--bare` optie, wat de repository initialiseert zonder een werkmap:
 
 	$ cd /opt/git
 	$ mkdir project.git
 	$ cd project.git
 	$ git --bare init
 
-Daarna kunnen John, Josie of Jessica de eerste versie van hun project in de repository pushen door het als een remote toe te voegen en naar een branch te pushen. Let op dat iemand met een shell op de machine zal moeten inloggen en een kale repository moet creeeren, iedere keer als je een project wilt toevoegen. Laten we `gitserver` als hostnaam gebruiken voor de server waar je je 'git' gebruiker en repository hebt ingesteld. Als je het intern gaat draaien, en je de DNS instelt zodat `gitserver` naar die server wijst, dan kun je de commando's vrijwel ongewijzigd gebruiken:
+Daarna kunnen John, Josie of Jessica de eerste versie van hun project in de repository pushen door het als een remote toe te voegen en naar een branch te pushen. Let op dat iemand met een shell op de machine zal moeten inloggen en een kale repository moet creëren, iedere keer als je een project wilt toevoegen. Laten we `gitserver` als hostnaam gebruiken voor de server waar je de 'git' gebruiker en repository hebt ingesteld. Als je het binnenshuis draait, en je de DNS instelt zodat `gitserver` naar die server wijst, dan kun je de commando's vrijwel ongewijzigd gebruiken:
 
 	# op Johns computer
 	$ cd myproject
@@ -243,14 +243,14 @@ Daarna kunnen John, Josie of Jessica de eerste versie van hun project in de repo
 	$ git remote add origin git@gitserver:/opt/git/project.git
 	$ git push origin master
 
-Op dat punt kunnen de anderen het clonen en wijzigingen even gemakkelijk terug pushen:
+Vanaf dat moment kunnen de anderen het clonen en wijzigingen even gemakkelijk terug pushen:
 
 	$ git clone git@gitserver:/opt/git/project.git
 	$ vim README
 	$ git commit -am 'fix for the README file'
 	$ git push origin master
 
-Met deze methode kun je snel een lees/schrijf Git server draaiend krijgen voor een handvol ontwikkelaars.
+Met deze methode kun je snel een lees/schrijf Git server draaiend krijgen voor een handjevol ontwikkelaars.
 
 Als een extra voorzorgsmaatregel kun je de 'git' gebruiker makkelijk beperken tot het doen van alleen Git activiteiten, met een gelimiteerde shell applicatie genaamd `git-shell` die bij Git geleverd wordt.
 Als je dit als login shell voor je 'git' gebruiker instelt, dan kan de 'git' gebruiker geen normale shell toegang hebben op je server. Specificeer `git-shell` in plaats van bash of csh voor je gebruikers login shell om dit te gebruiken. Om dit te doen zul je waarschijnlijk het `/etc/passwd` bestand aan moeten passen:
@@ -261,7 +261,7 @@ Aan het einde zou je een regel moeten vinden die er ongeveer zo uit ziet:
 
 	git:x:1000:1000::/home/git:/bin/sh
 
-Verander `/bin/sh` in `/usr/bin/git-shell` (of voer `which git-shell` uit om te zien waar het geinstalleerd is). De regel moet er ongeveer zo uit zien:
+Verander `/bin/sh` in `/usr/bin/git-shell` (of voer `which git-shell` uit om te zien waar het geïnstalleerd is). De regel moet er ongeveer zo uit zien:
 
 	git:x:1000:1000::/home/git:/usr/bin/git-shell
 
@@ -273,9 +273,9 @@ Nu kan de 'git' gebruiker de SSH connectie alleen gebruiken om Git repositories
 
 ## Publieke Toegang ##
 
-Wat als je anonieme leestoegang op je project wil? Misschien wil je geen intern prive project serveren, maar een open source project. Of misschien heb je een serie geautomatiseerde bouwservers of continue integratie servers die vaak wijzigen, en wil je niet doorlopend SSH sleutels hoeven genereren – je wil gewoon eenvoudige leestoegang toevoegen.
+Wat als je anonieme leestoegang op je project wil? Misschien wil je geen intern privé project beheren, maar een open source project. Of misschien heb je een aantal geautomatiseerde bouwservers of continue integratie servers die vaak wijzigen, en wil je niet doorlopend SSH sleutels hoeven genereren – je wil gewoon eenvoudige leestoegang toevoegen.
 
-Waarschijnlijk is de eenvoudigste manier voor kleinschalige opstellingen om een statische webserver in te stellen, waarbij de document root naar de plaats van je Git repositories wijst, en dan die `post-update` haak aanzetten waar we het in de eerste sectie van dit hoofdstuk over gehad hebben. Laten we eens uitgaan van het vorige voorbeeld. Stel dat je je repositories in de `/opt/git` map hebt staan, en er draait een Apache server op je machine. Nogmaals, je kunt hiervoor iedere web server gebruiken: maar als voorbeeld zullen we wat basis Apache configuraties laten zien, die je een idee kunnen geven van wat je nodig hebt.
+Waarschijnlijk is de eenvoudigste manier voor kleinschalige opstellingen om een statische webserver in te stellen, waarbij de document root naar de plaats van je Git repositories wijst, en dan de `post-update` haak aanzetten waar we het in de eerste paragraaf van dit hoofdstuk over gehad hebben. Laten we eens uitgaan van het voorgaande voorbeeld. Stel dat je je repositories in de `/opt/git` map hebt staan, en er draait een Apache server op je machine. Nogmaals, je kunt hiervoor iedere web server gebruiken: maar als voorbeeld zullen we wat basis Apache configuraties laten zien, die je een idee kunnen geven van wat je nodig hebt.
 
 Eerst moet je de haak aanzetten:
 
@@ -293,7 +293,7 @@ Wat doet deze `post-update` haak? Het ziet er ongeveer zo uit:
 
 Dit betekent dat wanneer je naar de server via SSH pushed, Git dit commando uitvoert om de benodigde bestanden voor HTTP fetching te verversen.
 
-Vervolgens moet je een VirtualHost toevoeging in je Apache configuratie aanmaken, met de document root als de hoofdmap van je Git projecten. Hier nemen we aan dat je joker DNS ingesteld hebt om `*.gitserver` door te sturen naar waar je dit alles draait:
+Vervolgens moet je een VirtualHost toevoeging in je Apache configuratie aanmaken, met de document root als de hoofdmap van je Git projecten. Hier nemen we aan dat je wildcard DNS ingesteld hebt om `*.gitserver` door te sturen naar waar je dit alles draait:
 
 	<VirtualHost *:80>
 	    ServerName git.gitserver
@@ -304,7 +304,7 @@ Vervolgens moet je een VirtualHost toevoeging in je Apache configuratie aanmaken
 	    </Directory>
 	</VirtualHost>
 
-Je zult ook de Unix gebruikers groep van de `/opt/git` mappen moeten instellen op `www-data` zodat je web server leestoegang heeft op de repositories, omdat de Apache instantie die het CGI script uitvoert (standaard) als die gebruiker draait:
+Je zult ook de Unix gebruikers groep van de `/opt/git` mappen moeten instellen op `www-data` zodat je web server leestoegang hebt op de repositories, omdat de Apache instantie die het CGI script uitvoert (standaard) als die gebruiker draait:
 
 	$ chgrp -R www-data /opt/git
 
@@ -312,11 +312,11 @@ Als je Apache herstart, dan zou je je repositories onder die map moeten kunnen c
 
 	$ git clone http://git.gitserver/project.git
 
-Op deze manier kun je HTTP-gebaseerde toegang voor ieder van je projecten voor een groot aantal gebruikers in slechts een paar minuten instellen. Een andere eenvoudige optie om publieke ongeverifieerde toegang in te stellen is een Git daemon starten, alhoewel dat vereist dat je het proces als daemon uitvoert – we beschrijven deze optie in de volgende sectie als je een voorkeur hebt voor die route.
+Op deze manier kun je HTTP-gebaseerde toegang voor elk van je projecten voor een groot aantal gebruikers in slechts een paar minuten instellen. Een andere eenvoudige optie om publieke ongeauthenticeerde toegang in te stellen is een Git daemon te starten, alhoewel dat vereist dat je het proces als daemon uitvoert – we beschrijven deze optie in de volgende paragraaf als je een voorkeur hebt voor deze variant.
 
 ## GitWeb ##
 
-Nu dat je basis lees/schrijf en alleen-lezen toegang tot je project hebt, wil je misschien een eenvoudige web-gebaseerde visualiseerder instellen. Git levert een CGI script genaamd GitWeb mee, dat veelal voor hiervoor gebruikt wordt. Je kunt GitWeb in gebruik zien bij sites zoals `http://git.kernel.org` (zie Figuur 4-1).
+Nu je basis lees/schrijf en alleen-lezen toegang tot je project hebt, wil je misschien een eenvoudige web-gebaseerde visualisatie instellen. Git levert een CGI script genaamd GitWeb mee, dat veelal voor hiervoor gebruikt wordt. Je kunt GitWeb in gebruik zien bij sites zoals `http://git.kernel.org` (zie Figuur 4-1).
 
 Insert 18333fig0401.png 
 Figuur 4-1. De GitWeb web-gebaseerde gebruikers interface.
@@ -327,11 +327,11 @@ Als je wil zien hoe GitWeb er op jouw project uitziet, dan heeft Git een command
 	[2009-02-21 10:02:21] INFO  WEBrick 1.3.1
 	[2009-02-21 10:02:21] INFO  ruby 1.8.6 (2008-03-03) [universal-darwin9.0]
 
-Dat start een HTTPD server op poort 1234 op en start automatisch een web browser op die met die pagina opent. Het is dus makkelijk voor jou. Als je klaar bent en de server wilt afsluiten, dan kun je hetzelfde commando uitvoeren met de `--stop` optie:
+Dat start een HTTPD server op poort 1234 op en start automatisch een web browser op die met die pagina opent. Het is dus makkelijk voor je. Als je klaar bent en de server wilt afsluiten, dan kun je hetzelfde commando uitvoeren met de `--stop` optie:
 
 	$ git instaweb --httpd=webrick --stop
 
-Als je de web interface doorlopend op een server wilt draaien voor je team of voor een open source project dat je serveert, dan moet je het CGI script instellen zodat het door je normale web server geserveerd wordt. Sommige Linux distributies hebben een `gitweb` pakket dat je misschien kunt installeren via `apt` of `yum`, dus misschien wil je dat eerst proberen. We zullen zeer binnenkort door een handmatige GitWeb installatie heenlopen. Eerst moet je de Git broncode pakken, waar GitWeb bij zit, en het persoonlijke CGI script genereren: 
+Als je de web interface doorlopend op een server wilt draaien voor je team of voor een open source project dat je verspreid, dan moet je het CGI script instellen zodat het door je normale web server geserveerd wordt. Sommige Linux distributies hebben een `gitweb` pakket dat je misschien kunt installeren via `apt` of `yum`, dus misschien kan je dat eerst proberen. We zullen snel door een handmatige GitWeb installatie heenlopen. Eerst moet je de Git broncode pakken waar GitWeb bij zit, en het aangepaste CGI script genereren: 
 
 	$ git clone git://git.kernel.org/pub/scm/git/git.git
 	$ cd git/
@@ -339,7 +339,7 @@ Als je de web interface doorlopend op een server wilt draaien voor je team of vo
 	        prefix=/usr gitweb/gitweb.cgi
 	$ sudo cp -Rf gitweb /var/www/
 
-Let op dat je het commando moet vertellen waar het je Git repositories kan vinden met de `GITWEB_PROJECTROOT` variabele. Nu moet je zorgen dat de Apache server CGI gebruikt voor dat script, waarvoor je een VirtualHost kunt toevoegen:
+Merk op dat je het commando moet vertellen waar het je Git repositories kan vinden met de `GITWEB_PROJECTROOT` variabele. Nu moet je zorgen dat de Apache server CGI gebruikt voor dat script, waarvoor je een VirtualHost kunt toevoegen:
 
 	<VirtualHost *:80>
 	    ServerName gitserver
@@ -354,17 +354,17 @@ Let op dat je het commando moet vertellen waar het je Git repositories kan vinde
 	    </Directory>
 	</VirtualHost>
 
-Nogmaals, GitWeb kan geserveerd worden met iedere CGI capabele web server; als je iets anders prefereert zou het niet moeilijk in te stellen moeten zijn. Op dit punt zou je in staat moeten zijn om `http://gitserver/` te bezoeken en je repositories online te zien, en kun je `http://git.gitserver` gebruiken om je repositories over HTTP te clonen en te fetchen.
+Nogmaals, GitWeb kan geserveerd worden met iedere web server die in staat is CGI te verwerken; als je iets anders prefereert zou het niet moeilijk in te stellen moeten zijn. Op dit punt zou je in staat moeten zijn om `http://gitserver/` te bezoeken en je repositories online te zien, en kun je `http://git.gitserver` gebruiken om je repositories over HTTP te clonen en te fetchen.
 
 ## Gitosis ##
 
-De publieke sleutels van alle gebruikers in een `authorized_keys` bestand bewaren voor toegang werkt slechts korte tijd goed. Als je honderden gebruikers hebt, dan is het moeizaam om dat proces te beheersen. Je moet iedere keer in de server inloggen, en er is geen toegangscontrole – iedereen in het bestand heeft lees- en schrijftoegang op ieder project.
+De publieke sleutels van alle gebruikers in een `authorized_keys` bestand bewaren voor toegang werkt slechts korte tijd goed. Als je honderden gebruikers hebt, dan is het bewerkelijk om dat proces te volgen. Je moet iedere keer in de server inloggen, en er is geen toegangscontrole – iedereen in het bestand heeft lees- en schrijftoegang op ieder project.
 
-Op dit punt wil je je misschien wenden tot een veelgebruikt software project genaamd Gitosis. Gitosis is in feite een set scripts die je helpen het `authorized_keys` bestand te beheren en eenvoudige toegangscontrole te implementeren. Het meest interessante gedeelte is dat de gebruikers interface voor deze applicatie om mensen toe te voegen en toegang te bepalen, geen web interface is maar een speciale Git repository. Je stelt de informatie in in dat project; en als je het pushed, dan herconfigureert Gitosis de server op basis van dat project, wat stoer is.
+Op dit punt wil je je misschien wenden tot een veelgebruikt software project genaamd Gitosis. Gitosis is in feite een verzameling scripts die je helpen het `authorized_keys` bestand te beheren alsmede eenvoudig toegangscontrole te implementeren. Het meest interessante gedeelte is dat de gebruikers interface voor deze applicatie om mensen toe te voegen en toegang te bepalen, geen web interface is maar een speciale Git repository. Je beheert de informatie in dat project; en als je het pushed, dan herconfigureert Gitosis de server op basis van dat project, wat best wel stoer is.
 
-Gitosis installeren is niet de makkelijkste taak ooit, maar het is ook niet te moeilijk. Het is het makkelijkst om er een Linux server voor te gebruiken – deze voorbeelden gebruiken een standaard Ubuntu 8.10 server.
+Gitosis installeren is niet de makkelijkste taak ooit, maar het is ook niet te moeilijk. Het is het makkelijkste om er een Linux server voor te gebruiken – deze voorbeelden gebruiken een standaard Ubuntu 8.10 server.
 
-Gitosis vereist wat Python applicaties, dus moet je eerst het Python setuptools pakket installeren, wat Ubuntu meelevert als python-setuptools:
+Gitosis vereist enkele Python applicaties, dus moet je eerst het Python setuptools pakket installeren, wat Ubuntu beschikbaar stelt als python-setuptools:
 
 	$ apt-get install python-setuptools
 
@@ -378,7 +378,7 @@ Daarmee worden een aantal bestanden geinstalleerd, die Gitosis zal gebruiken. Da
 
 	$ ln -s /opt/git /home/git/repositories
 
-Gitosis zal je sleutels voor je beheren, dus je moet het huidige bestand verwijderen, de sleutels later opnieuw toevoegen en Gitosis het `authorized_keys` bestand automatisch laten beheren. Voor nu verplaatsen we het `authorized_keys` bestand:
+Gitosis zal je sleutels voor je beheren, dus je moet het huidige bestand verwijderen, om de sleutels later opnieuw toe te voegen en Gitosis het `authorized_keys` bestand automatisch laten beheren. Voor nu verplaatsen we het `authorized_keys` bestand:
 
 	$ mv /home/git/.ssh/authorized_keys /home/git/.ssh/ak.bak
 
@@ -396,8 +396,7 @@ Nu wordt het tijd om Gitosis te initialiseren. Je doet dit door het `gitosis-ini
 	Initialized empty Git repository in /opt/git/gitosis-admin.git/
 	Reinitialized existing Git repository in /opt/git/gitosis-admin.git/
 
-Dit staat de gebruiker met die sleutel toe de hoofd Git repository, die de Gitosis installatie beheert, aan te passen. Daarna zul je met de hand het execute
-bit op het `post-update` script moeten instellen voor je nieuwe beheer repository.
+Dit staat de gebruiker met die sleutel toe de hoofd Git repository, die de Gitosis installatie beheert, aan te passen. Daarna zul je met de hand het execute bit op het `post-update` script moeten instellen voor je nieuwe beheer repository.
 
 	$ sudo chmod 755 /opt/git/gitosis-admin.git/hooks/post-update
 

From a5af517938a7cdda0032274960ec3af1f2d46552 Mon Sep 17 00:00:00 2001
From: Cor <cor.takken@cgi.com>
Date: Fri, 17 Jan 2014 15:03:53 +0100
Subject: [PATCH 110/690] [nl] added diacritical characters. Added (start of)
 gitolite translation.

---
 nl/04-git-server/01-chapter4.markdown | 352 +++++++++++++++++++-------
 1 file changed, 264 insertions(+), 88 deletions(-)

diff --git a/nl/04-git-server/01-chapter4.markdown b/nl/04-git-server/01-chapter4.markdown
index 1d4757358..c6bdd3c65 100644
--- a/nl/04-git-server/01-chapter4.markdown
+++ b/nl/04-git-server/01-chapter4.markdown
@@ -1,24 +1,24 @@
 # Git op de Server #
 
-Op dit punt zou je alledaagse taken waarvoor je Git zult gebruiken kunnen doen. Maar, om samen te kunnen werken in Git zul je een remote repository moeten hebben. Technisch gezien kun je wijzigingen pushen en pullen van individuele repositories, maar dat wordt afgeraden, omdat je vrij gemakkelijk het werk waar anderen mee bezig zijn in de war kunt schoppen als je niet oppast. Daarnaast wil je dat je medewerkers de repository kunnen bereiken, zelfs als jouw computer van het netwerk is – het hebben van een betrouwbare gezamenlijke repository is vaak handig. Daarom heeft het hebben van een tussenliggende repository waarin je met iemand anders samenwerkt de voorkeur, en daaruit pushen en pullen. We zullen deze repository de `Git server` noemen, maar je zult zien dat het over het algemeen maar een klein beetje systeembronnen kost om een Git repository te verzorgen, dus je zult er zelden een complete server voor nodig hebben.
+Op dit punt zou je alledaagse taken waarvoor je Git zult gebruiken kunnen doen. Maar, om samen te kunnen werken in Git zul je een remote repository moeten hebben. Technisch gezien kun je wijzigingen pushen en pullen van individuele repositories, maar dat wordt afgeraden, omdat je vrij gemakkelijk het werk waar anderen mee bezig zijn in de war kunt schoppen als je niet oppast. Daarnaast wil je dat je medewerkers de repository kunnen bereiken, zelfs als jouw computer van het netwerk is – het hebben van een betrouwbare gezamenlijke repository is vaak handig. De voorkeursmethode om met iemand samen te werken is om een tussenliggende repository in te richten waar beide partijen toegang to hebben en om daar naartoe te pushen en vandaan te pullen. We zullen deze repository de `Git server` noemen, maar je zult zien dat het over het algemeen maar een klein beetje systeembronnen kost om een Git repository te verzorgen, dus je zult er zelden een complete server voor nodig hebben.
 
-Een Git server draaien is eenvoudig. Als eerste kies je met welke protocollen je de server wilt laten communiceren. Het eerste gedeelte van dit hoofdstuk zullen we de beschikbare protocollen bespreken met de voor- en nadelen van elk. De volgende paragrafen zullen we veel voorkomende opstellingen bespreken, die van die protocollen gebruik maken en hoe je je server ermee kunt opzetten. Als laatste laten we een paar servers van derden zien, als je het niet erg vindt om je code op de server van een ander te zetten en niet het gedoe wilt hebben van het opzetten en onderhouden van je eigen server.
+Een Git server draaien is eenvoudig. Als eerste kies je met welke protocollen je de server wilt laten communiceren. Het eerste gedeelte van dit hoofdstuk zullen we de beschikbare protocollen bespreken met de voor- en nadelen van elk. De daarop volgende paragrafen zullen we een aantal veel voorkomende opstellingen bespreken die van die protocollen gebruik maken en hoe je je server ermee kunt opzetten. Als laatste laten we een paar servers van derden zien, als je het niet erg vindt om je code op de server van een ander te zetten en niet het gedoe wilt hebben van het opzetten en onderhouden van je eigen server.
 
-Als je geen interesse hebt om je eigen server te draaien, dan kun je de direct naar de laatste paragraaf van dit hoofdstuk gaan om wat mogelijkheden van online accounts te zien en dan door te gaan naar het volgende hoofdstuk, waar we alle zaken bespreken die komen kijken bij het werken met een gedistribueerde versiebeheer omgeving.
+Als je niet van plan bent om je eigen server te draaien, dan kun je de direct naar de laatste paragraaf van dit hoofdstuk gaan om wat mogelijkheden van online accounts te zien en dan door gaan naar het volgende hoofdstuk, waar we diverse zaken bespreken die komen kijken bij het werken met een gedistribueerde versiebeheer omgeving.
 
-Een remote repository is over het algemeen een _bare repository_ (kale repository) – een Git repository dat geen werkmap heeft. Omdat de repository alleen gebruikt wordt als een samenwerkingspunt, is er geen reden om een snapshot op de schijf te hebben; alleen de Git data. Een kale repository is eenvoudigweg de inhoud van de `.git` map in je project, en niets meer.
+Een remote repository is over het algemeen een _bare repository_ (kale repository) – een Git repository dat geen werkmap heeft. Omdat de repository alleen gebruikt wordt als een samenwerkingspunt, is er geen reden om een snapshot op de schijf te hebben; het is alleen de Git data. Een kale repository is eenvoudigweg de inhoud van de `.git` map in je project, en niets meer.
 
 ## De Protocollen ##
 
-Git kan vier veel voorkomende netwerk protocollen gebruiken om data te transporteren: Lokaal, Beveiligde Shell (SSH), Git en HTTP. Hier laten we zien wat deze zijn, en in welke omstandigheden je ze wilt gebruiken (of juist niet).
+Git kan vier veel voorkomende netwerk protocollen gebruiken om data te transporteren: Lokaal, Beveiligde Shell (Secure Shell, SSH), Git en HTTP. Hier bespreken we wat deze zijn, en in welke omstandigheden je ze zou willen gebruiken (of juist niet).
 
 Het is belangrijk om op te merken dat, met uitzondering van de HTTP protocollen, ze allemaal een werkende Git versie op de server geïnstalleerd moeten hebben.
 
 ### Lokaal Protocol ###
 
-Het meest basale is het _lokale protocol_, waarbij het remote repository in een andere map op de schijf staat. Deze opzet wordt vaak gebruikt als iedereen in het team toegang heeft op een gedeeld bestandssyteem zoals een NFS map, of in het weinig voorkomende geval dat iedereen op dezelfde computer werkt. Het laatste zou niet ideaal zijn, want dan zouden alle repositories op dezelfde computer staan, zodat de kans op een fataal verlies veel groter wordt.
+Het simpelste is het _Lokale protocol_, waarbij de remote repository in een andere directory op de schijf staat. Deze opzet wordt vaak gebruikt als iedereen in het team toegang heeft op een gedeeld bestandssyteem zoals een NFS mount, of in het weinig voorkomende geval dat iedereen op dezelfde computer werkt. Het laatste zou niet ideaal zijn, want dan zouden alle repositories op dezelfde computer staan, zodat een fataal verlies van gegevens veel groter wordt.
 
-Als je een gedeeld bestandssyteem hebt, dan kun je clonen, pushen en pullen van een op een lokaal bestand gebaseerde repository. Om een dergelijk repository te clonen, of om er een als een remote aan een bestaand project toe te voegen, moet je het pad naar het repository als URL gebruiken. Bijvoorbeeld, om een lokaal repository te clonen, kun je zoiets als dit uitvoeren:
+Als je een gedeeld bestandssyteem hebt, dan kun je clonen, pushen en pullen van een op een lokaal bestand aanwezige repository. Om een dergelijk repository te clonen, of om er een als een remote aan een bestaand project toe te voegen, moet je het pad naar het repository als URL gebruiken. Bijvoorbeeld, om een lokaal repository te clonen, kun je zoiets als het volgende uitvoeren:
 
 	$ git clone /opt/git/project.git
 
@@ -26,29 +26,29 @@ Of je kunt dit doen:
 
 	$ git clone file:///opt/git/project.git
 
-Git werkt iets anders als je explicite `file://` aan het begin van de URL zet. Als je alleen het pad specificeert, probeert Git hardlinks te gebruiken, of het kopieert de bestanden die het nodig heeft. Als je `file://` specificeert, dan start Git de processen die het normaal gesproken gebruikt om data te transporteren over een netwerk, wat over het algemeen een minder efficiënte methode is om data te transporteren. De reden om `file://` wel te specificeren is als je een schone kopie van de repository wilt met de extra referenties of objecten eruit gelaten – over het algemeen na een import van een ander versiebeheer systeem of iets dergelijks (zie Hoofdstuk 9 voor onderhoudstaken). We zullen het normale pad hier gebruiken, omdat het bijna altijd sneller is om het zo te doen.
+Git werkt iets anders als je explicite `file://` aan het begin van de URL zet. Als je alleen het pad specificeert, probeert Git hardlinks te gebruiken, of het kopieert de bestanden die het nodig heeft. Als je `file://` specificeert, dan start Git de processen die het normaal gesproken gebruikt om data te transporteren over een netwerk, wat over het algemeen een minder efficiënte methode is om gegevens over te dragen. De belangrijkste reden om `file://` wel te specificeren is als je een schone kopie van de repository wilt met de vreemde refenties of objecten eruit gelaten – over het algemeen na een import uit een ander versiebeheer systeem of iets dergelijks (zie Hoofdstuk 9 voor onderhoudstaken). We zullen het normale pad hier gebruiken, omdat het bijna altijd sneller is om het zo te doen.
 
-Om een lokale repository aan een bestaand Git project toe te voegen, kun je zoiets als het volgende uitvoeren:
+Om een lokale repository aan een bestaand Git project toe te voegen, kun je iets als het volgende uitvoeren:
 
 	$ git remote add local_proj /opt/git/project.git
 
-Daarna kun je pushen en pullen van die remote alsof je over een netwerk werkt.
+Daarna kun je op gelijke wijze pushen naar, en pullen van die remote als je over een netwerk zou doen.
 
 #### De Voordelen ####
 
-De voordelen van bestands-gebaseerde repositories zijn dat ze eenvoudig zijn en ze maken gebruik van bestaande bestandspermissies en netwerk toegang. Als je al een gedeeld bestandssysteem hebt, waar je hele team al toegang tot heeft, dan is een repository opzetten heel gemakkelijk. Je stopt de kale repository ergens waar iedereen gedeelde toegang tot heeft, en stelt de lees- en schrijfrechten in zoals je dat bij iedere andere gedeelde map zou doen. In de volgende paragraaf "Git op een Server Krijgen" bespreken we hoe je een kopie van een kale repository kunt exporteren voor dit doeleinde.
+De voordelen van bestands-gebaseerde repositories zijn dat ze eenvoudig zijn en ze maken gebruik van bestaande bestandspermissies en netwerk toegang. Als je al een gedeeld bestandssysteem hebt, waar het hele team al toegang toe heeft, dan is een repository opzetten heel gemakkelijk. Je stopt de kale repository ergens waar iedereen gedeelde toegang tot heeft, en stelt de lees- en schrijfrechten in zoals je dat bij iedere andere gedeelde directory zou doen. In de volgende paragraaf "Git op een Server Krijgen" bespreken we hoe je een kopie van een kale repository kunt exporteren voor dit doeleinde.
 
-Dit is ook een prettige optie om snel werk van een repository van iemand anders te pakken. Als jij en een collega aan hetzelfde project werken, en hij wil dat je iets bekijkt, dan is het uitvoeren van een commando zoals `git pull /home/john/project` vaak makkelijker dan dat hij naar een remote server moet pushen, en jij er van moet pullen.
+Dit is ook een prettige optie om snel werk uit een repository van iemand anders te pakken. Als jij en een collega aan hetzelfde project werken, en hij wil dat je iets bekijkt, dan is het uitvoeren van een commando zoals `git pull /home/john/project` vaak makkelijker dan dat hij naar een remote server moet pushen, en jij er van moet pullen.
 
 #### De Nadelen ####
 
-Een van de nadelen van deze methode is dat gedeelde toegang over het algemeen moeilijker op te zetten en te bereiken is vanaf meerdere lokaties dan basaal netwerk toegang. Als je wilt pushen van je laptop als je thuis bent, dan moet je de remote schijf aankoppelen, wat moeilijk en langzaam kan zijn in vergelijking tot netwerk gebaseerde toegang.
+Een van de nadelen van deze methode is dat gedeelde toegang over het algemeen moeilijker op te zetten en te bereiken is vanaf meerdere lokaties dan simpele netwerk toegang. Als je wilt pushen van je laptop als je thuis bent, dan moet je de remote schijf aankoppelen, wat moeilijk en langzaam kan zijn als je het vergelijkt met netwerk gebaseerde toegang.
 
-Het is ook belangrijk om te vermelden dat het niet altijd de snelste optie is, als je een gedeeld koppelpunt (mount) of iets dergelijks gebruikt. Een lokale repository is alleen snel als je snelle toegang tot de data hebt. Een repository op NFS is vaak langzamer dan een repository via SSH op dezelfde server omdat dit Git in staat stelt om op lokale schijven te werken vanaf ieder systeem.
+Het is ook belangrijk om te vermelden dat het niet altijd de snelste optie is, als je een gedeeld koppelpunt (mount) of iets dergelijks gebruikt. Een lokale repository is alleen snel als je snelle toegang tot de data hebt. Een repository op NFS is vaak langzamer dan een repository via SSH op dezelfde server omdat dit Git in staat stelt om op lokale schijven te werken op elk van de betrokken systemen.
 
 ### Het SSH Protocol ###
 
-Waarschijnlijk het meest voorkomende protocol voor Git is SSH. Met als reden dat toegang met SSH tot servers in veel plaatsen al geconfigureerd is – en als dat niet het geval is, dan is het eenvoudig om dat te doen. SSH is ook het enige netwerk gebaseerde protocol waarvan je makkelijk kunt lezen en naartoe kunt schrijven. De andere twee netwerk protocollen (HTTP en Git) zijn over het algemeen alleen-lezen, dus zelfs als je ze al beschikbaar hebt voor de ongeïnitieerden, dan heb je nog steeds SSH nodig voor je eigen schrijftoegang. SSH is ook een geauthenticieerd protocol; en omdat het overal voorkomt, is het over het algemeen eenvoudig om in te stellen en te gebruiken.
+Waarschijnlijk het meest voorkomende protocol voor Git is SSH. De reden hiervoor is dat toegang met SSH tot servers in veel plaatsen al geconfigureerd is – en als dat niet het geval is, dan is het eenvoudig om dat te doen. SSH is ook het enige netwerk gebaseerde protocol waarvan je makkelijk kunt lezen en naartoe kunt schrijven. De andere twee netwerk protocollen (HTTP en Git) zijn over het algemeen alleen-lezen, dus zelfs als je ze al beschikbaar hebt voor de ongeïnitieerde massas, dan heb je nog steeds SSH nodig voor je eigen schrijfcommandos. SSH is ook een geauthenticieerd protocol; en omdat het alom aanwezig is, is het over het algemeen eenvoudig om in te stellen en te gebruiken.
 
 Om een Git repository via SSH te clonen, kun je een ssh:// URL opgeven zoals:
 
@@ -58,19 +58,19 @@ Of je geeft geen protocol op – Git gaat uit van SSH als je niet expliciet bent
 	
 	$ git clone user@server:project.git
 
-Je kunt ook de gebruiker niet opgeven, en Git neemt aan dat je de gebruiker bedoelt waarmee je op het moment bent ingelogd.
+Je kunt ook de gebruiker weglaten, en Git gebruikt gegevens van de gebruiker waarmee je op dat moment bent ingelogd.
 
 #### De Voordelen ####
 
-Er zijn vele voordelen om SSH te gebruiken. De eerste is dat je het eigenlijk wel moet gebruiken als je geauthenticeerde schrijftoegang op je repository via een netwerk wilt. Het tweede is dat het relatief eenvoudig in te stellen is – SSH daemons komen veel voor, veel systeembeheerders hebben er ervaring mee, en veel operating systemen zijn er mee uitgerust of hebben applicaties om ze te beheren. Daarnaast is toegang via SSH veilig – alle data transporten zijn versleuteld en geauthenticeerd. En als laatste is SSH efficiënt, net zoals het Git en lokale protocol, de data wordt zo compact mogelijk gemaakt voordat het getransporteerd wordt.
+Er zijn vele voordelen om SSH te gebruiken. Ten eerste moet je het eigenlijk wel gebruiken als je geauthenticeerde schrijftoegang op je repository via een netwerk wilt. Ten tweede is het relatief eenvoudig in te stellen – SSH daemons komen veel voor, veel systeembeheerders hebben er ervaring mee, en veel operating systemen zijn er mee uitgerust of hebben applicaties om ze te beheren. Daarnaast is toegang via SSH veilig – alle data transporten zijn versleuteld en geauthenticeerd. En als laatste is SSH efficiënt, net zoals het Git en lokale protocol, de gegevens worden zo compact mogelijk gemaakt voordat het getransporteerd wordt.
 
 #### De Nadelen ####
 
-Het negatieve aspect van SSH is dat je er geen anonieme toegang over kunt geven. Mensen moeten via SSH toegang hebben om er gebruik van te kunnen maken, zelfs als het alleen lezen is, zodat SSH toegang niet bevordelijk is voor open source projecten. Als je het alleen binnen je bedrijfsnetwerk gebruikt, dan is SSH misschien het enige protocol waar je mee in aanraking komt. Als je anonieme alleen-lezen toegang wilt toestaan tot je projecten, dan moet je SSH voor jezelf instellen om over te pushen, maar iets anders voor anderen om over te pullen.
+Het negatieve aspect van SSH is dat je er geen anonieme toegang naar je repository over kunt geven. Mensen moeten via SSH toegang hebben om er gebruik van te kunnen maken, zelfs als het alleen lezen is, zodat SSH toegang niet bevordelijk is voor open source projecten. Als je het alleen binnen je bedrijfsnetwerk gebruikt, dan is SSH misschien het enige protocol waar je mee in aanraking komt. Als je anonieme alleen-lezen toegang wilt toestaan tot je projecten, dan moet je SSH voor jezelf instellen om over te pushen, maar iets anders voor anderen om over te pullen.
 
 ### Het Git Protocol ###
 
-Het volgende is het Git protocol. Dit is een aparte daemon, die met Git meegeleverd wordt; het luistert op een toegewezen poort (9418), en verleent een vergelijkbare dienst als het SSH protocol, maar dan zonder enige authenticatie. Om een repository beschikbaar te stellen over het Git protocol, moet je het `git-export-daemon-ok` bestand aanmaken – de daemon zal een repository zonder dit bestand erin niet verspreiden – maar buiten dat is er geen beveiliging. Oftewel: de Git repository is er om gecloned te kunnen worden door iedereen, of het is er helemaal niet. Dit betekent dat er over het algemeen geen pushing is via dit protocol. Je kunt push toegang aanzetten, maar gegeven het gebrek aan authenticatie kan, als je de push toegang aan zet, iedereen die de URL van jouw project op het internet vindt, pushen naar jouw project. We volstaan met te zeggen dat dit zeldzaam is.
+Het volgende is het Git protocol. Dit is een specifieke daemon, die met Git meegeleverd wordt; het luistert op een toegewezen poort (9418), en verleent een vergelijkbare dienst als het SSH protocol, maar dan zonder enige vorm van authenticatie. Om een repository beschikbaar te stellen over het Git protocol, moet je een `git-export-daemon-ok` bestand aanmaken – de daemon zal een repository zonder dit bestand erin niet verspreiden – maar daarbuiten is er geen beveiliging. De Git repository beschikbaar om gecloned te kunnen worden door iedereen, of het is het niet. Dit betekent dat er over het algemeen geen pushing is via dit protocol. Je kunt push toegang aanzetten, maar gegeven het gebrek aan authenticatie kan als je de push toegang aan zet iedereen die de URL van jouw project op het internet vindt, pushen naar jouw project. We volstaan met te zeggen dat dit zelden de bedoeling kan zijn.
 
 #### De Voordelen ####
 
@@ -79,7 +79,7 @@ Het Git protocol is het snelste dat beschikbaar is. Als je veel verkeer verwerkt
 #### De Nadelen ####
 
 Het nadeel van het Git protocol is het gebrek aan authenticatie. Het is over het algemeen onwenselijk dat het Git protocol de enige toegang tot je project is. Meestal zul je het samen met SSH toegang gebruiken voor de paar ontwikkelaars die push (schrijf-)toegang hebben en de rest laat je `git://` voor alleen leestoegang gebruiken.
-Het is waarschijnlijk ook het meest ingewikkelde protocol om in te stellen. Het moet een eigen daemon hebben, die speciaal voor die situatie ingericht is – we zullen er een instellen in het "Gitosis" gedeelte van dit hoofdstuk – het gebruikt `xinetd` configuratie of iets dergelijks, wat ook niet altijd eenvoudig is op te zetten. Het heeft ook firewall toegang tot poort 9418 nodig, wat geen standaard poort is dat in bedrijfsfirewalls is opengezet. Bij firewalls van grote bedrijven, is deze obscure poort meestal geblokkeerd.
+Het is waarschijnlijk ook het meest ingewikkelde protocol om in te richten. Het moet een eigen daemon hebben, die speciaal voor die situatie ingericht is – we zullen er een instellen in het "Gitosis" gedeelte van dit hoofdstuk – het gebruikt `xinetd` configuratie of iets vergelijkbaars, wat ook niet altijd eenvoudig is op te zetten. Daarbij is ook firewall toegang tot poort 9418 nodig, wat geen standaard poort is dat in bedrijfsfirewalls is opengezet. Bij firewalls van grote bedrijven, is deze ongebruikelijke poort meestal dichtgezet.
 
 ### Het HTTP/S Protocol ###
 
@@ -91,30 +91,30 @@ Als laatste hebben we het HTTP protocol. Het mooie aan het HTTP of HTTPS protoco
 	$ mv hooks/post-update.sample hooks/post-update
 	$ chmod a+x hooks/post-update
 
-Dat is alles. De `post-update` hook, die standaard bij Git zit, voert het noodzakelijke commando uit (`git update-server-info`) om HTTP fetching en cloning goed werkend te krijgen. Dit commando wordt uitgevoerd als je naar dit repository via SSH pushed; en dan kunnen andere mensen clonen met behulp van zoiets als
+Dat is alles. De `post-update` hook, die standaard bij Git geleverd wordt, voert het noodzakelijke commando uit (`git update-server-info`) om HTTP fetching en cloning goed werkend te krijgen en houden. Dit commando wordt uitgevoerd als je via SSH naar deze repository pushed; en andere mensen kunnen clonen met behulp van zoiets als
 
 	$ git clone http://example.com/gitproject.git
 
-In dit specifieke geval gebruiken we het `/var/www/htdocs` pad wat gebruikelijk is voor Apache opstellingen, maar je kunt iedere statische webserver gebruiken – stop de kale repository in haar pad. De Git data wordt geserveerd als standaard statische bestanden (zie hoofdstuk 9 voor details over hoe het precies geserveerd wordt).
+In dit specifieke voorbeeld gebruiken we het `/var/www/htdocs` pad wat gebruikelijk is voor Apache opstellingen, maar je kunt iedere statische webserver gebruiken – stop de kale repository in het betreffende pad. De Git data wordt geserveerd als standaard statische bestanden (zie hoofdstuk 9 voor details over hoe het precies geserveerd wordt).
 
-Het ook is mogelijk om Git over HTTP te laten pushen, alhoewel dat geen veelgebruikte techniek is en het vraagt dat je complexe WebDAV instellingen opzet. Omdat het zelden gebruikt wordt, zullen we het niet in dit boek beschrijven. Als je geïnteresseerd bent om de HTTP-push protocollen te gebruiken, dan kun je op `http://www.kernel.org/pub/software/scm/git/docs/howto/setup-git-server-over-http.txt` lezen hoe je een repository kunt maken. Een fijn ding aan Git laten pushen over HTTP is dat je iedere WebDAV server kunt gebruiken, zonder specifieke Git funtionaliteit; dus je kunt deze functionaliteit gebruiken als je web-hosting provider WebDAV ondersteunt voor het maken van wijzigingen aan je webpagina.
+Het is mogelijk om Git ook over HTTP te laten pushen, alhoewel dat geen veelgebruikte techniek is en het vraagt dat je complexe WebDAV instellingen inricht. Omdat het zelden gebruikt wordt, zullen we het niet in dit boek beschrijven. Als je geïnteresseerd bent om de HTTP-push protocollen te gebruiken, dan kun je op `http://www.kernel.org/pub/software/scm/git/docs/howto/setup-git-server-over-http.txt` lezen hoe je een repository kunt maken. Het aardige van Git laten pushen over HTTP is dat je iedere WebDAV server kunt gebruiken, zonder specifieke Git funtionaliteit, dus je kunt deze functionaliteit gebruiken als je web-hosting provider WebDAV ondersteunt voor het maken van wijzigingen aan je webpagina.
 
 #### De Voordelen ####
 
-Het voordeel van het gebruik van het HTTP protocol is dat het eenvoudig in te stellen is. Een handvol benodigde commando's uitvoeren zorgt voor een eenvoudige manier om de wereld leestoegang te geven tot je Git repository. Het kost slechts een paar minuten om te doen. Het HTTP protocol is niet erg belastend voor de systeembronnen van je server. Omdat het over het algemeen een statische webserver gebruikt om alle data te verspreiden - een normale Apache server kan gemiddeld duizenden bestanden zenden per seconde - is het moeilijk om zelfs een kleine server te overbelasten.
+Het voordeel van het gebruik van het HTTP protocol is dat het eenvoudig in te stellen is. Een handvol benodigde commando's uitvoeren is alles wat er moet gebeuren om de wereld leestoegang te geven tot je Git repository. Het neemt maar een paar minuten van je tijd. Het HTTP protocol is niet erg belastend voor de systeembronnen van je server. Omdat het over het algemeen een statische webserver gebruikt om alle data te verspreiden - een normale Apache server kan gemiddeld duizenden bestanden zenden per seconde - is het moeilijk om zelfs een kleine server te overbelasten.
 
-Je kunt ook je repositories alleen-lezen serveren via HTTPS, wat inhoudt dat je het transport kunt versleutelen; je kunt zelfs zover gaan dat je clients een specifiek gesigneerd SSL certificaat laat gebruiken. Normaal gesproken als je je deze moeite wilt getroosten, dan is het makkelijker om publieke SSH sleutels te gebruiken; maar het kan een betere oplossing in jouw specifieke geval zijn om gesigneerde SSL certificaten of andere HTTP-gebaseerde authenticatie methoden te gebruiken voor alleen-lezen toegang via HTTPS.
+Je kunt ook je repositories alleen-lezen serveren via HTTPS, wat inhoudt dat je het transport kunt versleutelen; je kunt zelfs zover gaan dat je clients een specifiek gesigneerd SSL certificaat laat gebruiken. Normaal gesproken als je je deze moeite wilt getroosten, dan is het makkelijker om publieke SSH sleutels te gebruiken; maar het kan in jouw specifieke geval een betere oplossing zijn om gesigneerde SSL certificaten of andere HTTP-gebaseerde authenticatie methoden te gebruiken voor alleen-lezen toegang via HTTPS.
 
 Een andere prettige bijkomstigheid is dat HTTP een dusdanig veel voorkomend protocol is dat bedrijfsfirewalls vaak zo ingesteld zijn dat ze verkeer via deze poort toestaan.
 
 #### De Nadelen ####
 
-Het nadeel van je repository verspreiden via HTTP is dat het relatief inefficiënt voor de client is. Over het algemeen duurt het een stuk langer om te clonen en te fetchen van de repository, en je hebt vaak een veel hogere netwerk belasting en transport volume via HTTP dan met elk van de andere netwerk protocollen. Omdat het niet zo ingewikkeld is om alleen de data te versturen die je nodig hebt – er wordt geen dynamisch werk door de server gedaan in deze transacties – wordt vaak naar het HTTP protocol gerefereerd als zijnde een _dom_ protocol. Voor meer informatie over de verschillen in efficiëntie tussen het HTTP protocol en andere protocollen, zie Hoofdstuk 9.
+Het nadeel van je repository verspreiden via HTTP is dat het relatief inefficiënt voor de client is. Over het algemeen duurt het een stuk langer om te clonen en te fetchen van de repository, en je hebt vaak een veel hogere netwerk belasting en transport volume via HTTP dan met elk van de andere netwerk protocollen. Omdat het niet zo ingewikkeld is om alleen de data te versturen die je nodig hebt – er wordt geen dynamisch werk door de server gedaan in deze uitwisselingen – wordt vaak naar het HTTP protocol gerefereerd als zijnde een _dom_ protocol. Voor meer informatie over de verschillen in efficiëntie tussen het HTTP protocol en andere protocollen, zie Hoofdstuk 9.
 
 ## Git op een Server Krijgen ##
 
-Om een initiële Git server op te zetten, moet je een bestaande repository naar een kale repository exporteren – een repository dat geen werkmap bevat. Dit is over het algemeen eenvoudig te doen.
-Om je repository te clonen met als doel het maken van een kale repository, voer je het clone commando uit met de `--bare` optie. Als vaste gewoonte eindigen de namen van kale repository mappen in `.git`, zoals:
+Om een Git server initieel op te zetten, moet je een bestaande repository naar een kale repository exporteren – een repository dat geen werkmap bevat. Dit is over het algemeen eenvoudig te doen.
+Om je repository te clonen met als doel het maken van een kale repository, voer je het clone commando uit met de `--bare` optie. Als conventie eindigen de namen van kale repository mappen met `.git`, zoals:
 
 	$ git clone --bare my_project my_project.git
 	Initialized empty Git repository in /opt/projects/my_project.git/
@@ -127,13 +127,13 @@ Dit is ongeveer gelijk aan
 
 Er zijn een paar kleine verschillen in het configuratie bestand, maar het komt op hetzelfde neer. Het neemt de Git repository zelf, zonder een werkmap, en maakt een map aan specifiek hiervoor.
 
-### Het Bare Repository op een Server Zetten ###
+### De Kale Repository op een Server Zetten ###
 
-Nu je een kale kopie van je repository hebt, is het enige dat je moet doen het op een server zetten en je protocollen instellen. Stel dat je een server ingesteld hebt, die `git.example.com` heet, waar je SSH toegang op hebt, en waar je al je Git repositories wilt opslaan onder de `/opt/git` map. Je kunt je nieuwe repository beschikbaar stellen door je kale repository ernaartoe te kopieeren:
+Nu je een kale kopie van je repository hebt, is het enige dat je moet doen het op een server zetten en je protocollen instellen. Laten we aannemen dat je een server ingericht hebt, die `git.example.com` heet, waar je SSH toegang op hebt, en waar je al je Git repositories wilt opslaan onder de `/opt/git` map. Je kunt je nieuwe repository beschikbaar stellen door je kale repository ernaartoe te kopiëren:
 
 	$ scp -r my_project.git user@git.example.com:/opt/git
 
-Op dit punt kunnen andere gebruikers, die SSH toegang hebben tot dezelfde server en lees-toegang hebben tot de `/opt/git` map, jouw repository clonen door dit uit te voeren:
+Vanaf dat moment kunnen andere gebruikers, die SSH toegang hebben tot dezelfde server en lees-toegang hebben tot de `/opt/git` map, jouw repository clonen door dit uit te voeren:
 
 	$ git clone user@git.example.com:/opt/git/my_project.git
 
@@ -143,11 +143,11 @@ Als een gebruiker met SSH op een server inlogt en schrijftoegang heeft tot de `/
 	$ cd /opt/git/my_project.git
 	$ git init --bare --shared
 
-Je ziet hoe eenvoudig het is om een Git repository te nemen, een kale versie aan te maken, en het op een server plaatsen waar jij en je medewerkers SSH toegang tot hebben. Nu ben je klaar om aan hetzelfde project samen te werken.
+Je ziet hoe eenvoudig het is om een Git repository te nemen, een kale versie aan te maken, en het op een server plaatsen waar jij en je medewerkers SSH toegang tot hebben. Nu zijn jullie klaar om aan hetzelfde project samen te werken.
 
-Het is belangrijk om op te merken dat dit letterlijk alles is wat je moet doen om een bruikbare Git server te draaien waarop meerdere mensen toegang hebben – voeg alleen een paar SSH accounts toe op een server, en stop een kale repository ergens waar al die gebruikers lees- en schrijftoegang toe hebben. Je bent er klaar voor – je hebt niets anders nodig.
+Het is belangrijk om op te merken dat dit letterlijk alles is wat je moet doen om een bruikbare Git server te draaien waarop meerdere mensen toegang hebben – maak alleen een paar accounts met SSH toegang aan op een server, en stop een kale repository ergens waar al die gebruikers lees- en schrijftoegang toe hebben. Je bent er klaar voor – je hebt niets anders nodig.
 
-In de volgende paragrafen zul je zien hoe je meer ingewikkelde opstellingen kunt maken. Deze bespreking zal het niet hoeven aanmaken van gebruikers accounts voor elke gebruiker, publieke leestoegang tot repositories, grafische web interfaces, de Gitosis applicatie gebruiken en meer omvatten. Maar, hou in gedachten dat om samen te kunnen werken met mensen op een privé project, alles wat je _nodig_ hebt is een SSH server en een kale repository.
+In de volgende paragrafen zul je zien hoe je meer ingewikkelde opstellingen kunt maken. Deze bespreking zal het niet hoeven aanmaken van gebruikers accounts voor elke gebruiker, publieke leestoegang tot repositories, grafische web interfaces, het gebruik van de Gitosis applicatie en meer omvatten. Maar, hou in gedachten dat om samen te kunnen werken met mensen op een privé project, alles wat je _nodig_ hebt een SSH server is en een kale repository.
 
 ### Kleine Opstellingen ###
 
@@ -155,27 +155,26 @@ Als je met een kleine groep bent of net begint met Git in je organisatie en slec
 
 #### SSH Toegang ####
 
-Als je reeds een server hebt waar al je ontwikkelaars SSH toegang op hebben, dan is het over het algemeen het eenvoudigste om je eerste repository daar in te stellen, omdat je dan bijna niets hoeft te doen (zoals beschreven in de vorige paragraaf). Als je meer complexe toegangscontrole wilt op je repositories, dan kun je ze instellen met de normale bestandssysteem permissies van het operating systeem dat op je server draait.
+Als je al een server hebt waar al je ontwikkelaars SSH toegang op hebben, dan is het over het algemeen het eenvoudigste om je eerste repository daar op te zetten, omdat je dan bijna niets hoeft te doen (zoals beschreven in de vorige paragraaf). Als je meer complexe toegangscontrole wilt op je repositories, dan kun je ze instellen met de normale bestandssysteem permissies van het operating systeem dat op je server draait.
 
-Als je je repositories op een server wilt zetten, die geen accounts heeft voor iedereen in je team die je schrijftoegang wilt geven, dan moet je SSH toegang voor ze instellen. We gaan er vanuit dat je een server hebt waarmee je dit kunt doen, dat je reeds een SSH server geïnstalleerd hebt, en dat de manier is waarop je toegang hebt tot de server.
+Als je je repositories op een server wilt zetten, die geen accounts heeft voor iedereen in je team die je schrijftoegang wilt geven, dan moet je SSH toegang voor ze opzetten. We gaan er vanuit dat je een server hebt waarmee je dit kunt doen, dat je reeds een SSH server geïnstalleerd hebt, en dat de manier is waarop je toegang hebt tot de server.
 
 Er zijn een paar manieren waarop je iedereen in je team toegang kunt geven. De eerste is voor iedereen accounts aanmaken, wat rechttoe rechtaan is maar bewerkelijk kan zijn. Je wilt vermoedelijk niet `adduser` uitvoeren en tijdelijke wachtwoorden instellen voor iedere gebruiker.
 
-Een tweede methode is een 'git' gebruiker aan te maken op de machine, aan iedere gebruiker die schijftoegang moet hebben vragen of ze je een publieke SSH sleutel sturen, en die sleutel toevoegen aan het `~/.ssh/authorized_keys` bestand van je nieuwe 'git' gebruiker. Vanaf dat moment zal iedereen toegang hebben op die machine via de 'git' gebruiker. Dit tast de commit data op geen enkele manier aan – de SSH gebruiker waarmee je inlogt zal de commits die je opgeslagen hebt niet beïnvloeden.
+Een tweede methode is een generieke 'git' gebruiker aan te maken op de machine, aan iedere gebruiker die schijftoegang moet hebben vragen of ze je een publieke SSH sleutel sturen, en die sleutel toevoegen aan het `~/.ssh/authorized_keys` bestand van die nieuwe 'git' gebruiker. Vanaf dat moment zal iedereen toegang hebben op die machine via de 'git' gebruiker. Dit tast de commit data op geen enkele manier aan – de SSH gebruiker waarmee je inlogt zal de commits die je opgeslagen hebt niet beïnvloeden.
 
-Een andere manier waarop je het kunt doen is je SSH server laten authenticeren middels een LDAP server of een andere gecentraliseerde authenticatie bron, die je misschien al ingesteld hebt. Zolang iedere gebruiker shell toegang kan krijgen op de machine, zou ieder SSH authenticatie mechanisme dat je kunt bedenken moeten werken.
+Een andere manier waarop je het kunt doen is je SSH server laten authenticeren middels een LDAP server of een andere gecentraliseerde authenticatie bron, die misschien al ingericht is. Zolang iedere gebruiker shell toegang kan krijgen op de machine, zou ieder SSH authenticatie mechanisme dat je kunt bedenken moeten werken.
 
 ## Je Publieke SSH Sleutel Genereren ##
 
-Dat gezegd hebbende, zijn er vele Git servers die authenticeren met een publieke SSH sleutel. Om een publieke sleutel te hebben, zal iedere gebruiker in je systeem er een moeten genereren als ze er nog geen hebben. Dit proces is bij alle operating systemen vergelijkbaar.
-Als eerste moet je controleren dat je er niet al een hebt. Standaard staan de SSH sleutels van de gebruikers in hun eigen `~/.ssh` map. Je kunt makkelijk nagaan of je al een sleutel hebt door naar die map te gaan en de inhoud te bekijken:
+Dat gezegd hebbende, zijn er vele Git servers die authenticeren met een publieke SSH sleutel. Om een publieke sleutel te hebben, zal iedere gebruiker in je systeem er een moeten genereren als ze er nog geen hebben. Dit proces is bij alle operating systemen vergelijkbaar. Als eerste moet je controleren of je er niet al een hebt. Standaard staan de SSH sleutels van de gebruikers in hun eigen `~/.ssh` map. Je kunt makkelijk nagaan of je al een sleutel hebt door naar die map te gaan en de inhoud te bekijken:
 
 	$ cd ~/.ssh
 	$ ls
 	authorized_keys2  id_dsa       known_hosts
 	config            id_dsa.pub
 
-Je bent op zoek naar een aantal bestanden genaamd iets en iets.pub, waarbij het `iets` meestal zoiets is als `id_dsa` of `id_rsa`. Het `.pub` bestand is je publieke sleutel en het andere bestand is je private sleutel. Als je deze bestanden niet hebt (of als je zelfs geen `.ssh` map hebt), dan kun je ze aanmaken door een applicatie genaamd `ssh-keygen` uit te voeren, wat meegeleverd wordt met het SSH pakket op Linux/Mac systemen en meegeleverd wordt met het MSysGit pakket op Windows:
+Je bent op zoek naar een aantal bestanden genaamd iets en iets.pub, waarbij het `iets` meestal zoiets is als `id_dsa` of `id_rsa`. Het `.pub` bestand is je publieke sleutel en het andere bestand is je private sleutel. Als je deze bestanden niet hebt (of als je zelfs geen `.ssh` map hebt), dan kun je ze aanmaken door een applicatie genaamd `ssh-keygen` uit te voeren, deze wordt met het SSH pakket op Linux/Mac systemen meegeleverd en met het MSysGit pakket op Windows:
 
 	$ ssh-keygen 
 	Generating public/private rsa key pair.
@@ -187,7 +186,7 @@ Je bent op zoek naar een aantal bestanden genaamd iets en iets.pub, waarbij het
 	The key fingerprint is:
 	43:c5:5b:5f:b1:f1:50:43:ad:20:a6:92:6a:1f:9a:3a schacon@agadorlaptop.local
 
-Eerst bevestigt het de lokatie waar je de sleutel wilt opslaan (`.ssh/id_rsa`), en vervolgens vraagt het tweemaal om een wachtwoord, die je leeg kunt laten als je geen wachtwoord wilt intypen op het moment dat je de sleutel gebruikt.
+Eerst wordt de lokatie waar je de sleutel wordt opgeslagen (`.ssh/id_rsa`) aangegeven, en vervolgens vraagt het tweemaal om een wachtwoord, die je leeg kunt laten als je geen wachtwoord wilt intypen op het moment dat je de sleutel gebruikt.
 
 Iedere gebruiker die dit doet, moet zijn sleutel sturen naar jou of degene die de Git server beheert (aangenomen dat je een SSH server gebruikt die publieke sleutels vereist). Het enige dat ze hoeven doen is de inhoud van het `.pub` bestand kopiëren en e-mailen. De publieke sleutel ziet er ongeveer zo uit:
 
@@ -199,18 +198,18 @@ Iedere gebruiker die dit doet, moet zijn sleutel sturen naar jou of degene die d
 	mZ+AW4OZPnTPI89ZPmVMLuayrD2cE86Z/il8b+gw3r3+1nKatmIkjn2so1d01QraTlMqVSsbx
 	NrRFi9wrf+M7Q== schacon@agadorlaptop.local
 
-Voor een uitgebreide tutorial over het aanmaken van een SSH sleutel op meerdere operating systemen, zie de GitHub handleiding over SSH sleutels op `http://github.com/guides/providing-your-ssh-key`.
+Voor een uitgebreide tutorial over het aanmaken van een SSH sleutel op meerdere operating systemen, verwijzen ze je naar de GitHub handleiding over SSH sleutels op `http://github.com/guides/providing-your-ssh-key`.
 
-## De Server Instellen ##
+## De Server Opzetten ##
 
-Laten we het instellen van SSH toegang aan de server kant eens doorlopen. In dit voorbeeld zul je de `authorized_keys` methode gebruiken om je gebruikers te authenticeren. We gaan er ook vanuit dat je een standaard Linux distributie gebruikt zoals Ubuntu. Als eerste maak je een 'git' gebruiker aan en een `.ssh` map voor die gebruiker.
+Laten we het opzetten van SSH toegang aan de server kant eens doorlopen. In dit voorbeeld zul je de `authorized_keys` methode gebruiken om je gebruikers te authenticeren. We gaan er ook vanuit dat je een standaard Linux distributie gebruikt zoals Ubuntu. Als eerste maak je een 'git' gebruiker aan en een `.ssh` map voor die gebruiker.
 
 	$ sudo adduser git
 	$ su git
 	$ cd
 	$ mkdir .ssh
 
-Daarna moet je een aantal publieke SSH sleutels van ontwikkelaars aan het `authorized_keys` bestand toevoegen voor die gebruiker. Laten we aannemen dat je een aantal sleutels per e-mail ontvangen hebt en ze hebt opgeslagen in tijdelijke bestanden. Nogmaals, de sleutels zien er ongeveer zo uit:
+Vervolgens moet je een aantal publieke SSH sleutels van ontwikkelaars aan het `authorized_keys` bestand toevoegen voor die gebruiker. Laten we aannemen dat je een aantal sleutels per e-mail ontvangen hebt en ze hebt opgeslagen in tijdelijke bestanden. Nogmaals, de sleutels zien er ongeveer zo uit:
 
 	$ cat /tmp/id_rsa.john.pub
 	ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCB007n/ww+ouN4gSLKssMxXnBOvf9LGt4L
@@ -233,7 +232,7 @@ Nu kun je een lege repository voor ze instellen door `git init` uit te voeren me
 	$ cd project.git
 	$ git --bare init
 
-Daarna kunnen John, Josie of Jessica de eerste versie van hun project in de repository pushen door het als een remote toe te voegen en naar een branch te pushen. Let op dat iemand met een shell op de machine zal moeten inloggen en een kale repository moet creëren, iedere keer als je een project wilt toevoegen. Laten we `gitserver` als hostnaam gebruiken voor de server waar je de 'git' gebruiker en repository hebt ingesteld. Als je het binnenshuis draait, en je de DNS instelt zodat `gitserver` naar die server wijst, dan kun je de commando's vrijwel ongewijzigd gebruiken:
+Daarna kunnen John, Josie of Jessica de eerste versie van hun project in de repository pushen door het als een remote toe te voegen en een branch te pushen. Merk op dat iemand met een shell op de machine zal moeten inloggen en een kale repository moet creëren voor elke keer dat je een project wilt toevoegen. Laten we `gitserver` als hostnaam gebruiken voor de server waar je de 'git' gebruiker en repository hebt aangemaakt. Als je het binnenshuis draait, en je de DNS instelt zodat `gitserver` naar die server wijst, dan kun je de commando's vrijwel ongewijzigd gebruiken:
 
 	# op Johns computer
 	$ cd myproject
@@ -250,7 +249,7 @@ Vanaf dat moment kunnen de anderen het clonen en wijzigingen even gemakkelijk te
 	$ git commit -am 'fix for the README file'
 	$ git push origin master
 
-Met deze methode kun je snel een lees/schrijf Git server draaiend krijgen voor een handjevol ontwikkelaars.
+Op deze manier kun je snel een lees/schrijf Git server draaiend krijgen voor een handjevol ontwikkelaars.
 
 Als een extra voorzorgsmaatregel kun je de 'git' gebruiker makkelijk beperken tot het doen van alleen Git activiteiten, met een gelimiteerde shell applicatie genaamd `git-shell` die bij Git geleverd wordt.
 Als je dit als login shell voor je 'git' gebruiker instelt, dan kan de 'git' gebruiker geen normale shell toegang hebben op je server. Specificeer `git-shell` in plaats van bash of csh voor je gebruikers login shell om dit te gebruiken. Om dit te doen zul je waarschijnlijk het `/etc/passwd` bestand aan moeten passen:
@@ -273,11 +272,11 @@ Nu kan de 'git' gebruiker de SSH connectie alleen gebruiken om Git repositories
 
 ## Publieke Toegang ##
 
-Wat als je anonieme leestoegang op je project wil? Misschien wil je geen intern privé project beheren, maar een open source project. Of misschien heb je een aantal geautomatiseerde bouwservers of continue integratie servers die vaak wijzigen, en wil je niet doorlopend SSH sleutels hoeven genereren – je wil gewoon eenvoudige leestoegang toevoegen.
+Wat als je anonieme leestoegang op je project wil? Misschien wil je geen intern privé project beheren, maar een open source project. Of misschien heb je een aantal geautomatiseerde bouwservers of continue integratie servers die vaak wisselen, en wil je niet doorlopend SSH sleutels hoeven genereren – je wil gewoon eenvoudige anonieme leestoegang toevoegen.
 
-Waarschijnlijk is de eenvoudigste manier voor kleinschalige opstellingen om een statische webserver in te stellen, waarbij de document root naar de plaats van je Git repositories wijst, en dan de `post-update` haak aanzetten waar we het in de eerste paragraaf van dit hoofdstuk over gehad hebben. Laten we eens uitgaan van het voorgaande voorbeeld. Stel dat je je repositories in de `/opt/git` map hebt staan, en er draait een Apache server op je machine. Nogmaals, je kunt hiervoor iedere web server gebruiken: maar als voorbeeld zullen we wat basis Apache configuraties laten zien, die je een idee kunnen geven van wat je nodig hebt.
+Waarschijnlijk is de eenvoudigste manier voor kleinschalige opstellingen om een statische webserver in te stellen, waarbij de document root naar de plaats van je Git repositories wijst, en dan de `post-update` haak aanzetten waar we het in de eerste paragraaf van dit hoofdstuk over gehad hebben. Laten we eens uitgaan van het voorgaande voorbeeld. Stel dat je je repositories in de `/opt/git` map hebt staan, en er draait een Apache server op je machine. Nogmaals, je kunt hiervoor iedere web server gebruiken: maar als voorbeeld zullen we wat simpele Apache configuraties laten zien, die je het idee weergeven van wat je nodig hebt.
 
-Eerst moet je de haak aanzetten:
+Eerst moet je de haak inschakelen:
 
 	$ cd project.git
 	$ mv hooks/post-update.sample hooks/post-update
@@ -285,7 +284,7 @@ Eerst moet je de haak aanzetten:
 
 Als je een lagere versie dan 1.6 van Git gebruikt, dan is het `mv` commando niet nodig – Git is recentelijk pas begonnen met de namen van de haak voorbeelden op .sample te laten eindigen.
 
-Wat doet deze `post-update` haak? Het ziet er ongeveer zo uit:
+Wat doet deze `post-update` haak? Het ziet er eigenlijk als volgt uit:
 
 	$ cat .git/hooks/post-update 
 	#!/bin/sh
@@ -293,7 +292,7 @@ Wat doet deze `post-update` haak? Het ziet er ongeveer zo uit:
 
 Dit betekent dat wanneer je naar de server via SSH pushed, Git dit commando uitvoert om de benodigde bestanden voor HTTP fetching te verversen.
 
-Vervolgens moet je een VirtualHost toevoeging in je Apache configuratie aanmaken, met de document root als de hoofdmap van je Git projecten. Hier nemen we aan dat je wildcard DNS ingesteld hebt om `*.gitserver` door te sturen naar waar je dit alles draait:
+Vervolgens moet je een VirtualHost regel in je Apache configuratie aanmaken, met de document root als de hoofdmap van je Git projecten. Hier nemen we aan dat je wildcard DNS ingesteld hebt om `*.gitserver` door te sturen naar waar je dit alles draait:
 
 	<VirtualHost *:80>
 	    ServerName git.gitserver
@@ -304,7 +303,7 @@ Vervolgens moet je een VirtualHost toevoeging in je Apache configuratie aanmaken
 	    </Directory>
 	</VirtualHost>
 
-Je zult ook de Unix gebruikers groep van de `/opt/git` mappen moeten instellen op `www-data` zodat je web server leestoegang hebt op de repositories, omdat de Apache instantie die het CGI script uitvoert (standaard) als die gebruiker draait:
+Je zult ook de Unix gebruikers groep van de `/opt/git` mappen moeten zetten op `www-data` zodat je web server leestoegang hebt op de repositories, omdat de Apache instantie het CGI script (standaard) uitvoert als die gebruiker draait:
 
 	$ chgrp -R www-data /opt/git
 
@@ -312,26 +311,26 @@ Als je Apache herstart, dan zou je je repositories onder die map moeten kunnen c
 
 	$ git clone http://git.gitserver/project.git
 
-Op deze manier kun je HTTP-gebaseerde toegang voor elk van je projecten voor een groot aantal gebruikers in slechts een paar minuten instellen. Een andere eenvoudige optie om publieke ongeauthenticeerde toegang in te stellen is een Git daemon te starten, alhoewel dat vereist dat je het proces als daemon uitvoert – we beschrijven deze optie in de volgende paragraaf als je een voorkeur hebt voor deze variant.
+Op deze manier kun je HTTP-gebaseerde toegang voor elk van je projecten voor een groot aantal gebruikers in slechts een paar minuten regelen. Een andere eenvoudige optie om publieke ongeauthenticeerde toegang in te stellen is een Git daemon te starten, alhoewel dat vereist dat je het proces als daemon uitvoert – we beschrijven deze optie in de volgende paragraaf als je een voorkeur hebt voor deze variant.
 
 ## GitWeb ##
 
-Nu je basis lees/schrijf en alleen-lezen toegang tot je project hebt, wil je misschien een eenvoudige web-gebaseerde visualisatie instellen. Git levert een CGI script genaamd GitWeb mee, dat veelal voor hiervoor gebruikt wordt. Je kunt GitWeb in gebruik zien bij sites zoals `http://git.kernel.org` (zie Figuur 4-1).
+Nu je gewone lees/schrijf en alleen-lezen toegang tot je project hebt, wil je misschien een eenvoudige web-gebaseerde visualisatie instellen. Git levert een CGI script genaamd GitWeb mee, dat normaalgesproken hiervoor gebruikt wordt. Je kunt GitWeb in actie zien bij sites zoals `http://git.kernel.org` (zie Figuur 4-1).
 
 Insert 18333fig0401.png 
 Figuur 4-1. De GitWeb web-gebaseerde gebruikers interface.
 
-Als je wil zien hoe GitWeb er op jouw project uitziet, dan heeft Git een commando waarmee je een tijdelijke instantie op kunt starten als je een lichtgewicht server op je systeem hebt zoals `lighttpd` of `webrick`. Op Linux machines is `lighttpd` vaak geinstalleerd, dus je kunt het misschien draaiend krijgen door `git instaweb` in te typen in je project map. Als je op een Mac werkt: Leopard heeft Ruby voorgeinstalleerd, dus `webrick` zou je beste gok kunnen zijn. Om `instaweb` met een server anders dan lighttpd te starten, kun je het uitvoeren met de `--httpd` optie.
+Als je wil zien hoe GitWeb er voor jouw project uitziet, dan heeft Git een commando waarmee je een tijdelijke instantie op kunt starten als je een lichtgewicht server op je systeem hebt zoals `lighttpd` of `webrick`. Op Linux machines is `lighttpd` vaak geïnstalleerd, dus je kunt het misschien draaiend krijgen door `git instaweb` in te typen in je project map. Als je op een Mac werkt: Leopard heeft Ruby voorgeïnstalleerd, dus `webrick` zou je de meeste kans geven. Om `instaweb` met een server anders dan lighttpd te starten, moet je het uitvoeren met de `--httpd` optie.
 
 	$ git instaweb --httpd=webrick
 	[2009-02-21 10:02:21] INFO  WEBrick 1.3.1
 	[2009-02-21 10:02:21] INFO  ruby 1.8.6 (2008-03-03) [universal-darwin9.0]
 
-Dat start een HTTPD server op poort 1234 op en start automatisch een web browser op die met die pagina opent. Het is dus makkelijk voor je. Als je klaar bent en de server wilt afsluiten, dan kun je hetzelfde commando uitvoeren met de `--stop` optie:
+Dat start een HTTPD server op poort 1234 op en start automatisch een web browser die op die pagina opent. Het is dus makkelijk voor je. Als je klaar bent en de server wilt afsluiten, dan kun je hetzelfde commando uitvoeren met de `--stop` optie:
 
 	$ git instaweb --httpd=webrick --stop
 
-Als je de web interface doorlopend op een server wilt draaien voor je team of voor een open source project dat je verspreid, dan moet je het CGI script instellen zodat het door je normale web server geserveerd wordt. Sommige Linux distributies hebben een `gitweb` pakket dat je misschien kunt installeren via `apt` of `yum`, dus misschien kan je dat eerst proberen. We zullen snel door een handmatige GitWeb installatie heenlopen. Eerst moet je de Git broncode pakken waar GitWeb bij zit, en het aangepaste CGI script genereren: 
+Als je de web interface doorlopend op een server wilt draaien voor je team of voor een open source project dat je verspreid, dan moet je het CGI script instellen zodat het door je normale web server geserveerd wordt. Sommige Linux distributies hebben een `gitweb` pakket dat je zou kunnen installeren via `apt` of `yum`, dus wellicht kan je dat eerst proberen. We zullen snel door een handmatige GitWeb installatie heen lopen. Eerst moet je de Git broncode pakken waar GitWeb bij zit, en het aangepaste CGI script genereren: 
 
 	$ git clone git://git.kernel.org/pub/scm/git/git.git
 	$ cd git/
@@ -354,17 +353,17 @@ Merk op dat je het commando moet vertellen waar het je Git repositories kan vind
 	    </Directory>
 	</VirtualHost>
 
-Nogmaals, GitWeb kan geserveerd worden met iedere web server die in staat is CGI te verwerken; als je iets anders prefereert zou het niet moeilijk in te stellen moeten zijn. Op dit punt zou je in staat moeten zijn om `http://gitserver/` te bezoeken en je repositories online te zien, en kun je `http://git.gitserver` gebruiken om je repositories over HTTP te clonen en te fetchen.
+Nogmaals, GitWeb kan geserveerd worden met iedere web server die in staat is CGI te verwerken. Als je iets anders prefereert zou het niet moeilijk moeten zijn dit in te stellen. Vanaf dit moment zou je in staat moeten zijn om `http://gitserver/` te bezoeken en je repositories online te zien, en kun je `http://git.gitserver` gebruiken om je repositories over HTTP te clonen en te fetchen.
 
 ## Gitosis ##
 
-De publieke sleutels van alle gebruikers in een `authorized_keys` bestand bewaren voor toegang werkt slechts korte tijd goed. Als je honderden gebruikers hebt, dan is het bewerkelijk om dat proces te volgen. Je moet iedere keer in de server inloggen, en er is geen toegangscontrole – iedereen in het bestand heeft lees- en schrijftoegang op ieder project.
+De publieke sleutels van alle gebruikers in een `authorized_keys` bestand bewaren voor toegang werkt slechts korte tijd goed. Als je honderden gebruikers hebt, dan is het te bewerkelijk om dat proces te blijven volgen. Je moet iedere keer in de server inloggen, en er is geen toegangscontrole – iedereen in het bestand heeft lees- en schrijftoegang op ieder project.
 
-Op dit punt wil je je misschien wenden tot een veelgebruikt software project genaamd Gitosis. Gitosis is in feite een verzameling scripts die je helpen het `authorized_keys` bestand te beheren alsmede eenvoudig toegangscontrole te implementeren. Het meest interessante gedeelte is dat de gebruikers interface voor deze applicatie om mensen toe te voegen en toegang te bepalen, geen web interface is maar een speciale Git repository. Je beheert de informatie in dat project; en als je het pushed, dan herconfigureert Gitosis de server op basis van dat project, wat best wel stoer is.
+Op dat moment zou je kunnen overwegen een veelgebruikt software project genaamd Gitosis te gaan gebruiken. Gitosis is in feite een verzameling scripts die je helpen het `authorized_keys` bestand te beheren alsmede eenvoudig toegangscontrole te implementeren. Het interessante hieraan is dat de gebruikers interface voor deze applicatie om mensen toe te voegen en toegang te bepalen, geen web interface is maar een speciale Git repository. Je beheert de informatie in dat project en als je het pushed, dan herconfigureert Gitosis de server op basis van dat project, wat best wel slim bedacht is.
 
-Gitosis installeren is niet de makkelijkste taak ooit, maar het is ook niet te moeilijk. Het is het makkelijkste om er een Linux server voor te gebruiken – deze voorbeelden gebruiken een standaard Ubuntu 8.10 server.
+Gitosis installeren is niet de makkelijkste taak ooit, maar het is ook niet al te moeilijk. Het is het makkelijkste om er een Linux server voor te gebruiken – deze voorbeelden gebruiken een standaard Ubuntu 8.10 server.
 
-Gitosis vereist enkele Python applicaties, dus moet je eerst het Python setuptools pakket installeren, wat Ubuntu beschikbaar stelt als python-setuptools:
+Gitosis vereist enkele Python tools, dus moet je eerst het Python setuptools pakket installeren, wat Ubuntu beschikbaar stelt als python-setuptools:
 
 	$ apt-get install python-setuptools
 
@@ -374,15 +373,15 @@ Vervolgens clone en installeer je Gitosis van de hoofdpagina van het project:
 	$ cd gitosis
 	$ sudo python setup.py install
 
-Daarmee worden een aantal bestanden geinstalleerd, die Gitosis zal gebruiken. Daarna wil Gitosis zijn repositories onder `/home/git` stoppen, wat prima is. Maar je hebt je repositories al in `/opt/git` geconfigureerd, dus in plaats van alles te herconfigureren maken we een symbolische link aan:
+Daarmee worden een aantal bestanden geïnstalleerd, die Gitosis zal gebruiken. Daarna wil Gitosis zijn repositories onder `/home/git` stoppen, wat prima is. Maar je hebt je repositories al in `/opt/git` geconfigureerd, dus in plaats van alles te herconfigureren maken we een symbolische link aan:
 
 	$ ln -s /opt/git /home/git/repositories
 
-Gitosis zal je sleutels voor je beheren, dus je moet het huidige bestand verwijderen, om de sleutels later opnieuw toe te voegen en Gitosis het `authorized_keys` bestand automatisch laten beheren. Voor nu verplaatsen we het `authorized_keys` bestand:
+Gitosis zal de sleutels voor je beheren, dus je moet het huidige bestand verwijderen, om de sleutels later opnieuw toe te voegen en Gitosis het `authorized_keys` bestand automatisch laten beheren. Voor nu verplaatsen we het `authorized_keys` bestand:
 
 	$ mv /home/git/.ssh/authorized_keys /home/git/.ssh/ak.bak
 
-Nu moet je je shell terugzetten voor de 'git' gebruiker, als je het veranderd hebt naar het `git-shell` commando. Mensen zullen nog steeds niet in staat zijn in te loggen, maar Gitosis zal dat voor je beheren. Dus, laten we deze regel veranderen in je `/etc/passwd` bestand
+Nu moet je de shell terugzetten voor de 'git' gebruiker, als je het veranderd hebt naar het `git-shell` commando. Mensen zullen nog steeds niet in staat zijn in te loggen, Gitosis zal dat voor je beheren. Dus, laten we deze regel veranderen in je `/etc/passwd` bestand
 
 	git:x:1000:1000::/home/git:/usr/bin/git-shell
 
@@ -390,17 +389,17 @@ terug naar dit:
 
 	git:x:1000:1000::/home/git:/bin/sh
 
-Nu wordt het tijd om Gitosis te initialiseren. Je doet dit door het `gitosis-init` commando met je eigen publieke sleutel uit te voeren. Als je publieke sleutel niet op de server staat zul je het daar naartoe moeten kopieeren:
+Nu wordt het tijd om Gitosis te initialiseren. Je doet dit door het `gitosis-init` commando met je eigen publieke sleutel uit te voeren. Als je publieke sleutel niet op de server staat zul je het daar naartoe moeten kopiëren:
 
 	$ sudo -H -u git gitosis-init < /tmp/id_dsa.pub
 	Initialized empty Git repository in /opt/git/gitosis-admin.git/
 	Reinitialized existing Git repository in /opt/git/gitosis-admin.git/
 
-Dit staat de gebruiker met die sleutel toe de hoofd Git repository, die de Gitosis installatie beheert, aan te passen. Daarna zul je met de hand het execute bit op het `post-update` script moeten instellen voor je nieuwe beheer repository.
+Dit staat de gebruiker met die sleutel toe de hoofd Git repository, die de Gitosis setup regelt, aan te passen. Daarna zul je met de hand het execute bit op het `post-update` script moeten aanzetten voor je nieuwe beheer repository.
 
 	$ sudo chmod 755 /opt/git/gitosis-admin.git/hooks/post-update
 
-Je bent nu klaar om te gaan. Als je alles juist hebt ingesteld, kun je nu met SSH in je server loggen als de gebruiker waarvoor je de publieke sleutel hebt toegevoegd om Gitosis te initialiseren. Je zou dan zoiets als dit moeten zien:
+Je bent nu klaar voor de start. Als je alles juist hebt ingesteld, kun je nu met SSH in je server loggen als de gebruiker waarvoor je de publieke sleutel hebt toegevoegd om Gitosis te initialiseren. Je zou dan zoiets als dit moeten zien:
 
 	$ ssh git@gitserver
 	PTY allocation request failed on channel 0
@@ -420,7 +419,7 @@ Nu heb je een map genaamd `gitosis-admin`, die twee gedeeltes heeft:
 	./keydir
 	./keydir/scott.pub
 
-Het `gitosis.conf` bestand is het beheer bestand, dat je zult gebruiken om gebruikers, repositories en permissies te specificeren. De `keydir` map is de plaats waar je de publieke sleutels opslaat van alle gebruikers die een vorm van toegang tot je repositories hebben – één bestand per gebruiker. De naam van het bestand in `keydir` (in het vorige voorbeeld, `scott.pub`) zal anders voor jou zijn – Gitosis haalt de naam uit de beschrijving aan het einde van de publieke sleutel die was geimporteerd met het `gitosis-init` script.
+Het `gitosis.conf` bestand is het beheer bestand dat je zult gebruiken om gebruikers, repositories en permissies te specificeren. De `keydir` map is de plaats waar je de publieke sleutels opslaat van alle gebruikers die een vorm van toegang tot de repositories hebben – één bestand per gebruiker. De naam van het bestand in `keydir` (in het vorige voorbeeld, `scott.pub`) zal anders zijn in jouw geval – Gitosis haalt de naam uit de beschrijving aan het einde van de publieke sleutel die was geïmporteerd met het `gitosis-init` script.
 
 Als je naar het `gitosis.conf` bestand kijkt, zou het alleen informatie over het zojuist geclonede `gitosis-admin` project mogen bevatten:
 
@@ -431,15 +430,15 @@ Als je naar het `gitosis.conf` bestand kijkt, zou het alleen informatie over het
 	writable = gitosis-admin
 	members = scott
 
-Het laat je zien dat de gebruiker 'scott' – de gebruiker met wiens publieke sleutel je Gitosis geinitialiseerd hebt – de enige is die toegang heeft tot het `gitosis-admin project.
+Het laat je zien dat de gebruiker 'scott' – de gebruiker met wiens publieke sleutel je Gitosis geïnitialiseerd hebt – de enige is die toegang heeft tot het `gitosis-admin` project.
 
-Laten we een nieuw project voor je toevoegen. Je voegt een nieuwe sectie genaamd `mobile` toe, waar je de ontwikkelaars in je mobile team neerzet, en de projecten waar deze ontwikkelaars toegang tot moeten hebben. Omdat 'scott' op het moment de enige gebruiker in het systeem is, zul je hem als enig lid toevoegen en zul je een nieuw project genaamd `iphone_project` toevoegen om mee te beginnen:
+Laten we nu een nieuw project voor je toevoegen. Je voegt een nieuwe sectie genaamd `mobile` toe, waar je de ontwikkelaars in het mobile team neerzet, en de projecten waar deze ontwikkelaars toegang tot moeten hebben. Omdat 'scott' op het moment de enige gebruiker in het systeem is, zul je hem als enig lid toevoegen en voeg je een nieuw project genaamd `iphone_project` toe om mee te beginnen:
 
 	[group mobile]
 	writable = iphone_project
 	members = scott
 
-Wanneer je wijzigingen aan het `gitosis-admin` project moet maken, moet je de veranderingen committen en terug pushen naar de server voordat ze effect hebben:
+Wanneer je wijzigingen aan het `gitosis-admin` project maakt, moet je de veranderingen committen en terug pushen naar de server voordat ze effect hebben:
 
 	$ git commit -am 'add iphone_project and mobile group'
 	[master]: created 8962da8: "changed name"
@@ -465,7 +464,7 @@ Je kunt je eerste push naar het nieuwe `iphone_project` doen door je server als
 
 Merk op dat je geen pad hoeft te specificeren (sterker nog, het wel doen zal niet werken), alleen een dubbele punt en dan de naam van het project – Gitosis zal het voor je vinden.
 
-Je wil samen met je vrienden aan dit project werken, dus je zult hun publieke sleutels weer toe moeten voegen. Maar in plaats van ze handmatig aan het `~/.ssh/authorized_keys` bestand op je server toe te voegen, voeg je ze, één sleutel per bestand, aan de `keydir` map toe. Hoe je de sleutels noemt bepaalt hoe je aan de gebruikers refereert in het `gitosis.conf` bestand. Laten we de publieke sleutels voor John, Josie en Jessica toevoegen:
+Je wil samen met je vrienden aan dit project werken, dus je zult hun publieke sleutels weer toe moeten voegen. Maar in plaats van ze handmatig aan het `~/.ssh/authorized_keys` bestand op je server toe te voegen, voeg je ze één sleutel per bestand, aan de `keydir` map toe. Hoe je de sleutels noemt bepaalt hoe je aan de gebruikers refereert in het `gitosis.conf` bestand. Laten we de publieke sleutels voor John, Josie en Jessica toevoegen:
 
 	$ cp /tmp/id_rsa.john.pub keydir/john.pub
 	$ cp /tmp/id_rsa.josie.pub keydir/josie.pub
@@ -489,7 +488,7 @@ Gitosis heeft ook eenvoudige toegangscontrole. Als je wilt dat John alleen lees
 	readonly = iphone_project
 	members = john
 
-Nu kan John het project clonen en updates krijgen, maar Gitosis zal hem niet toestaan om terug naar het project te pushen. Je kunt zoveel van deze groepen maken als je wilt, waarbij ze allen verschillende gebruikers en projecten mogen bevatten. Je kunt ook een andere groep als een van de leden specificeren (waarbij je `@` als prefix gebruikt), om alle leden automatisch over te erven:
+Nu kan John het project clonen en updates krijgen, maar Gitosis zal hem niet toestaan om terug naar het project te pushen. Je kunt zoveel van deze groepen maken als je wilt, waarbij ze alle verschillende gebruikers en projecten mogen bevatten. Je kunt ook een andere groep als een van de leden specificeren (met @ als voorvoegsel), waarmee de groepsleden automatisch worden overerfd:
 
 	[group mobile_committers]
 	members = scott josie jessica
@@ -502,21 +501,198 @@ Nu kan John het project clonen en updates krijgen, maar Gitosis zal hem niet toe
 	writable  = another_iphone_project
 	members   = @mobile_committers john
 
-Als je problemen hebt, kan het handig zijn om `loglevel=DEBUG` onder de `[gitosis] sectie te zetten. Als je je push-toegang bent verloren door een kapotte configuratie te pushen, kun je het handmatig repareren in het bestand `/home/git/.gitosis.conf` op de server – het bestand waar Gitosis zijn informatie vandaan haalt. Een push naar het project neemt het `gitosis.conf` bestand dat je zojuist gepushed hebt en stopt het daar. Als je het bestand handmatig aanpast, zal het zo blijven totdat de volgende succesvolle push gedaan wordt naar het `gitosis-admin` project. 
+Als je problemen hebt, kan het handig zijn om `loglevel=DEBUG` onder de `[gitosis]` sectie te zetten. Als je je push-toegang bent verloren door een kapotte configuratie te pushen, kun je het handmatig repareren in het bestand `/home/git/.gitosis.conf` op de server – het bestand waar Gitosis zijn informatie vandaan haalt. Een push naar het project neemt het `gitosis.conf` bestand dat je zojuist gepushed hebt en stopt het daar. Als je het bestand handmatig aanpast, zal het zo blijven totdat de volgende succesvolle push gedaan wordt naar het `gitosis-admin` project.
+
+## Gitolite ##
+
+Merk op: de laatste versie van deze paragraaf in het ProGit boek is altijd beschikbaar binnen de [gitolite documentation][gldpg]. De auteur geeft ook nederig aan dat, hoewel deze paragraaf accuraat is, het *kan* (en vaak ook *is*) gebruikt om gitolie te installeren zonder enige andere documentatie te lezen, dat het niet gegarandeerd compleet is, en het zeker niet de gehele enorme hoeveelheid documentatie kan vervangen dat meegeleverd wordt met gitolite.
+
+[gldpg]: http://github.com/sitaramc/gitolite/blob/pu/doc/progit-article.mkd
+
+Git begint erg populair te worden in het bedrijfsleven, die de neiging hebben nog wat additionele eisen te hebben op het gebied van toegangscontrole. Gitolite was oorspronkelijk gemaakt om bij het vervullen van deze eisen te helpen, maar het blijkt dat het even bruikbaar is in de wereld van de open source: het Fedora Project beheert toegang tot hun package beheer repositories (meer dan 10.000 daarvan!) met gitolite, en het is waarschijnlijk daarbij ook nog eens de grootste gitolite installatie waar dan ook.
+
+Gitolite stelt je in staat de permissies niet alleen per repository, maar ook per branch of tag naam binnen elke repository. Dus, je kunt aangeven dat bepaalde mensen (of groepen van mensen) alleen maar bepaalde "refs" (branches of tags) kunnen pushen maar niet andere.
+
+### Installatie ###
+
+Het installeren van Gitolite is zeer eenvoudig, zelfs als je de uitgebreide documentatie, dat erbij geleverd wordt, niet leest. Je hebt een account op een Unix(achtige) server hebben; verschillende Linux smaken en Solaris 10 zijn getest. Je hebt geen root toegang nodig, aangenomen dat git, perl, en een openssh compatible ssh server al zijn geïnstalleerd. In de onderstaand voorbeelden zullen we het `gitolite` account gebruiken op een host genaamd `gitserver`.
+
+Gitolite is nogal ongebruikelijk in de zin van "server" software -- toegang gaat via ssh, en elke userid op de server is in potentie een "gitolite host". Het resultaat is, dat er een idee is van "installeren" van de software zelf, en dan het "opzetten" van een gebruiker als een "gitolist host".
+
+Mensen zonder root toegang kunnen het installeren binnen hun eigen user id. Als laatste: gitlite kan geïnstalleerd worden door een script te starten *op het werkstation*, vanuit een bash-shell. (Zelfs de bash die meegeleverd wordt met msysgit volstaat, voor het geval je je dat afvroeg.)
+
+We zullen dit laatste in dit stuk beschrijven, voor de overige methoden verwijzen we je naar de documentatie.
+
+Je begint met het verkrijgen van toegang op basis van een publieke sleutel, zodat je vanaf je werkstation op de server kan inloggen zonder het intypen van je wachtwoord. De volgende methode werkt op Linux; voor andere werkstation besturingssystemen moet je dit wellicht handmatig doen. We gaan er vanuit dat je al een sleutelpaar hebt gegenereerd met `ssh-keygen`.
+
+	$ ssh-copy-id -i ~/.ssh/id_rsa gitolite@gitserver
+
+Dit zal je vragen naar een wachtwoord naar het gitolite account, en dan de publieke sleutel toegang opzetten. Dit is **absoluut noodzakelijk** voor het installatiescript, dus controleer dit om er zeker van te zijn dat je een commando kan laten lopen zonder een wachtwoord te hoeven in typen.
+
+	$ ssh gitolite@gitserver pwd
+	/home/gitolite
+
+Vervolgens, clone je Gitolite van de hoofdsite van het project en roept de "easy install" script aan (het derde argument is jouw naam zoals je deze in de resulterende gitolite-admin repository wilt laten verschijnen):
+
+	$ git clone git://github.com/sitaramc/gitolite
+	$ cd gitolite/src
+	$ ./gl-easy-install -q gitolite gitserver sitaram
+
+En dat is het! Gitolite is nu geïnstalleerdop je server, en je hebt nu een gloednieuwe repository genaamd `gitolite-admin` in de home directory van jouw werkstation. Je beheert je gitolite setup door een wijziging aan te brengen in deze reporitory en deze te pushen.
+
+Dat laatste commando produceert nogal een hoeveelheid uitvoer dat wellicht interessant is om te lezen. Ook wordt er, de eerste keer dat je het laat lopen, er een nieuwe sleutelpaar gemaakt; je moet een wachtwoord kiezen of Enter als je er geen wilt. Waarom een tweede sleutelpaar nodig is, en hoe deze wordt gebruikt, wordt uitgelegd in het "ssh troubleshooting" document dat bij Gitolite wordt meegeleverd. (Hey, de documentatie moet *ergens* goed voor zijn!)
+
+Repositories genaamd `gitolite-admin` en `testing` worden standaard op de server aangemaakt. Als je een van beide lokaal wilt clonen (van een account die SSA console toegang heeft naar het gitolite account via *authorized_keys*) type je:
+
+	$ git clone gitolite:gitolite-admin
+	$ git clone gitolite:testing
+	
+Om deze zelfde repositories te clonen van een willekeurige ander account:
+
+	$ git clone gitolite@servername:gitolite-admin
+	$ git clone gitolite@servername:testing
+
+### De Installatie Aanpassen ###
+
+Hoewel de standaard, snelle, installatie werkt voor de meeste mensen, zijn er een aantal manieren om de installatie aan te passen als dat nodig is. Als je het `-q` argument weg laat, krijg je een "verbose" installatie wijze -- gedetaileerde informatie over wat de installatie aan het doen is bij elke stap. De verbose wijze staat je ook toe om bepaalde server-side parameters aan te passen, zoals de locatie van de eigenlijke repositories, door het wijzigen van een "rc" bestand dat de server gebruikt. Dit "rc" bestand is ruimhartig van commentaar voorzien dus je zou in staat moeten zijn om elke wijziging die je nodig vindt vrij snel te maken, op te slaan en door te gaan. Dit bestand bevat ook enkele instellingen die je kunt aanpassen om de meer geavanceerde functies van gitolite aan of uit te zetten.
+
+### Config bestand en Beheer van Toegangsregels ###
+
+Op het moment dat de installatie afgerond is, schakel je over naar de `gitolite-admin` repository (staat in je HOME directory) en begin je rond te snuffelen om te zien wat je daar hebt:
+
+	$ cd ~/gitolite-admin/
+	$ ls
+	conf/  keydir/
+	$ find conf keydir -type f
+	conf/gitolite.conf
+	keydir/sitaram.pub
+	$ cat conf/gitolite.conf
+	#gitolite conf
+	# please see conf/example.conf for details on syntax and features
+
+	repo gitolite-admin
+	    RW+                 = sitaram
+
+	repo testing
+	    RW+                 = @all
+
+Merk op dat "sitaram" (het laatste argument in het `gl-easy-install` commando dat je eerder gegeven hebt) lees en schrijf rechten heeft op de `gitolite-admin` repository en een publiek sleutelbestand met dezelfde naam.
+
+De syntax van het config bestand voor gitolite is ruimhartig van documentatie voorzien in `conf/example.conf`, dus we zullen alleen wat hoofdpunten benoemen.
+
+Je kunt voor het gemak gebruikers of repositories groeperen. De groepnamen zijn vergelijkbaar met macros; als je ze definieert maakt het niet uit of het projecten of gebruikers zijn, dat onderscheid wordt pas gemaakt als je de "macro" gaat *gebruiken*.
+
+	@oss_repos      = linux perl rakudo git gitolite
+	@secret_repos   = fenestra pear
+
+	@admins         = scott     # Adams, not Chacon, sorry :)
+	@interns        = ashok     # get the spelling right, Scott!
+	@engineers      = sitaram dilbert wally alice
+	@staff          = @admins @engineers @interns
+
+Je kunt de permissies beheren op het "ref" niveau. In het volgende voorbeeld kunnen stagieres (interns) alleen maar naar de "int" branch pushen. Techneuten (engineers) kunnen naar elke branch pushen waarvan de naam begint met "eng-", en tags die beginnen met "rc" gevolgd door een getal. En de admins kunnen alles (inclusief terugdraaien) naar elke ref.
+
+	repo @oss_repos
+	    RW  int$                = @interns
+	    RW  eng-                = @engineers
+	    RW  refs/tags/rc[0-9]   = @engineers
+	    RW+                     = @admins
+
+De expressie achter de `RW` of `RW+` is een zgn. regular expression (regex) waartegen de refname (ref) die wordt gepushed wordt vergeleken. Dus we noemen het natuurlijk een "refex"! En natuurlijk kan een refex veel krachtiger zijn dan hier wordt getoond, dus ga het niet overdrijven als je niet al te goed in de perl regexen zit.
+
+Zoals je wellicht al geraden hebt, prefixed Gitolite `refs/heads/` als een syntactische handigheid als de refex niet begint met `refs/`.
+
+Een belangrijke eigenschap van de syntax van het config bestand is dat alle regels van een repository niet op één plek hoeft te staan. Je kunt al het generieke spul bij elkaar houden, zoals de regels voor alle `oss_repos` zoals ze hier boven staan, en dan op een latere plaats specifieke regels voor specifieke gevallen, zoals hier:
+
+	repo gitolite
+	    RW+                     = sitaram
+
+Deze regel wordt gewoon toegevoegd aan de set met regels voor de `gitolite` repository.
+
+Je zou je op dit punt kunnen afvragen hoe de toegangsregels eigenlijk worden toegepast, laten we dat kort behandelen.
+
+Er zijn twee niveaus van toegangsbeheer in gitolite. De eerste is op repository niveau. Als je lees (of schrijf)rechten hebt tot *enige* ref in de repository, dan heb je lees (of schrijf) rechten tot de repository.
+
+Het tweede niveau, alleen van toepassing voor "schrijf" toegang, is per branch of tag binnen een repository. De gebruikersnaam, het type toegang wat wordt gevraagd (`W` of '+'), en de refname dat wordt gewijzigd (update) zijn bekend. De toegangsregels worden gecontroleerd in volgorde van voorkomst in het config bestand, en er wordt gekeken naar een treffer voor deze combinatie (maar onthoudt dat de refname middels een regex wordt vergeleken, niet een simpele string-vergelijking). Als er een treffer is, dan slaagt de push. Als er geen treffer wordt gevonden (fallthrough) dan wordt toegang geweigerd.
+
+### Geavanceerde Toegangs Controle met "deny" regels ###
+
+Tot zover hebben we alleen permissies gezien uit het rijtje `R`, `RW` of `RW+`. Echter, gitolite kent een andere permissie: `-`, wat staat voor "deny" (ontken). Dit geeft je veel meer macht, tegen kosten van wat hogere complexiteit omdat een fallthrough nu niet de *enige* manier is waarop toegang kan worden geweigerd, wordt *de volgorde van regels belangrijk*!
+
+Stel dat, in de onderstaande situatie, we de techneuten in staat willen stellen elke branch te laten terugdraaien *behalve* master en integ. Dit is de manier om dat te doen:
+
+	    RW  master integ    = @engineers
+	    -   master integ    = @engineers
+	    RW+                 = @engineers
+
+Nogmaals, je hoeft slechts de regels van boven naar beneden af te lopen tot je een treffer hebt voor je gevraagde toegangswijze, of een afwijzing. Een push die niets terugdraait naar master of integ wordt door de eerste regel toegestaan. Een terugdraai-push naar deze refs geeft geen treffer op de eerste regel en valt door naar de tweede regel en wordt daarom geweigerd. Elke push (terugdraaiend of niet) naar refs anders dan master of integ zullen op de eerste twee regels zowiezo niet treffen en de derde regel staat dit toe.
+
+### Beperken van pushes bij gewijzigde bestanden ###
+
+Bovenop het beperken van gebruikersrechten op branches voor een gebruiker, kan je ook de rechten van gebruikers beperken op bestanden. Als voorbeeld, misschien is de Makefile (of een ander programma) niet echt bedoeld om te worden gewijzigd door iedereen, omdat een groot aantal dingen afhankelijk ervan zijn of omdat het stuk loopt als de wijzigingen niet *precies goed* gebeuren. Je kunt het gitolite duidelijk maken:
+
+    repo foo
+        RW                  =   @junior_devs @senior_devs
+
+        RW  NAME/           =   @senior_devs
+        -   NAME/Makefile   =   @junior_devs
+        RW  NAME/           =   @junior_devs
+
+Deze krachtige eigenschap is gedocumenteerd in `conf/example.conf`.
+
+### Persoonlijke branches ###
+
+Gitolite heeft ook een mogelijkheid van "persoonlijke branches" (of liever gezegd "persoonlijke branch namespace") wat erg nuttig kan zijn in een bedrijfssituatie.
+
+Veel van de code-uitwisselingen in de git-wereld verlopen via zgn. "please pull" aanvragen. In een bedrijfsomgeving echter is ongeauthoriseerde toegang taboe, en het werkstation van een ontwikkelaar kan geen authenticatie doen, dus je moet naar de centrale server pushen en iemand vragen daarvandaan te pullen.
+
+Dit zou normaalgesproken een gelijksoortige branch-brij veroorzaken als in een gecentraliseerde versiebeheersysteem, en daarbij wordt het opzetten van permissies een vervelende klus voor de administrator.
+
+Gitolite stelt je in staat een "personal" of "scratch" namespace prefix voor elke ontwikkelaar te definiëren (bijvoorbeeld `refs/personal/<devname>/*`); zie ook de "personal branches" paragraaf in `doc/3-faq-tips-etc.mkd` voor details.
+
+### "Wildcard" repositores ###
+
+Gitolite laat je repositories specificeren met wildcards (eigenlijk perl regex expressies), zoals bijvoorbeeld `assignments/s[0-9][0-9]/a[0-9][0-9]`, om maar een willekeurig voorbeeld te nemen. Dit is een *heel* krachtige eigenschap die wordt aangezet door de regel `$GL_WILDREPOS = 1;` in het rc bestand. Het laat je een nieuwe permissiewijze ("C") toe te wijzen welke gebruikers in staat stelt repositories aan te maken die voldoen aan zulke wildcards, automatisch eigenaarsschap toe te wijzen aan de gebruiker die hem heeft aangemaakt, staat deze gebruiker toe om "R" en "RW" permissies aan anderen toe te wijzen om samen te werken, etc. Deze eigenschap is beschreven in `doc/4-wildcard-repositories.mkd`.
+
+### Andere eigenschappen ###
+
+We ronden deze uiteenzetting af met een passe partout van andere eigenschappen, welke alle (en nog vele andere) tot in de kleinste detail zijn beschreven in de "faqs, tips, etc" en andere documenten.
+
+**Logging**: Gitolite logt alle succesvolle toegangspogingen. Als je wat te los bent geweest in het toekennen van terugdraai permissies (`RW+`) en een of andere nozem heeft "master" vernaggelt, is de log-file een redder in de nood in de zin van snel en eenvoudig achterhalen van de SHA die verdwenen is.
+
+**Git buiten reguliere PATH**: Een ontzettend handige eigenschap in gitolite is het ondersteunen van git buiten het regulier `$PATH` (dit komt vaker voor dan je zou denken, sommige bedrijfs omgevingen of zelfs sommige hosting providers weigeren dingen systeem-breed te installeren en je eindigt ermee dat je ze in je eigen directories zet). Normaalgesproken ben je gedwongen git aan de *client-side* op de een of andere manier te vertellen van deze niet-standaard locatie van de git binaries. Met gitolite hoe je alleen een verbose installatie te kiezen en `$GIT_PATH` in de "rc" bestanden in te vullen. Hierna geen wijzigingen aan de kant van de clients nodig :-)
+
+**Rapportage van toegangsrechten**: Nog zo'n handige eigenschap is wat er gebeurt als je gewoon met ssh naar de server gaat. Gitolite laat zien welke repositories je toegang toe hebt en welke soort toegang dat dan wel is. Hier is een voorbeeld:
+
+        hello sitaram, the gitolite version here is v1.5.4-19-ga3397d4
+        the gitolite config gives you the following access:
+             R     anu-wsd
+             R     entrans
+             R  W  git-notes
+             R  W  gitolite
+             R  W  gitolite-admin
+             R     indic_web_input
+             R     shreelipi_converter
+
+
+**Delegeringen**: Voor extreem grote installaties kan je de verantwoordelijkheid voor groepen van repositories delegeren aan verschilllende mensen en hen het beheer van die delen onafhankelijk laten regelen. Dit vermindert de werkdruk van de hoofd-beheerder, en maakt van hem minder een faalpunt. Deze eigenschap heeft zijn eigen docuentatie bestand in de `doc/` directory.
+
+**Gitweb ondersteuning**: Gitolite ondersteunt gitweb op verschillende manieren. Je kunt aangeven welke repositories zichtbaar zijn via gitweb. Je kunt de "owner" (eigenaar) en "description" (omschrijving) voor gitweb vanuit de gitolite configuratie bestanden definiëren. Gitweb heeft een mechanisme beschikbaar waarmee toegang via HTTP wordt geïmplementeerd, deze kan je het "gecompileerde" config bestand van de gitolite config file laten gebruiken, wat inhoudt dat gitweb en gitolite dezelfde toegangsregels gebruikt (voor lees toegang).
+
 
 ## Git Daemon ##
 
-Voor publieke ongeverifieerde leestoegang tot je projecten zul je het HTTP protocol achter je willen laten, en overstappen op het Git protocol. De hoofdreden is snelheid. Het Git protocol is veel efficienter en daarmee sneller dan het HTTP protocol, dus het zal je gebruikers tijd besparen.
+Voor publieke ongeauthenticeerde leestoegang tot je projecten zul je het HTTP protocol achter je willen laten, en overstappen op het Git protocol. De belangrijkste reden is snelheid. Het Git protocol is veel efficiënter en daarmee sneller dan het HTTP protocol, dus het zal je gebruikstijd besparen.
 
-Nogmaals, dit is voor ongeverifieerde alleen-lezen toegang. Als je dit op een server buiten je firewall draait, zul je het alleen moeten gebruiken voor projecten die voor de hele wereld toegankelijk moeten zijn. Als de server waarop je het draait binnen je firewall staat, zou je het kunnen gebruiken voor projecten waarbij een groot aantal mensen of computers (continue integratie of bouwservers) alleen-lezen toegang moeten hebben, waarbij je niet voor iedereen een SSH sleutel wilt toevoegen.
+Nogmaals, dit is voor ongeauthenticeerde alleen-lezen toegang. Als je dit op een server buiten je firewall draait, zul je het alleen moeten gebruiken voor projecten die voor de hele wereld toegankelijk moeten zijn. Als de server waarop je het draait binnen je firewall staat, zou je het kunnen gebruiken voor projecten waarbij een groot aantal mensen of computers (continue integratie of bouwservers) alleen-lezen toegang moeten hebben, waarbij je niet voor iedereen een SSH sleutel wilt toevoegen.
 
 In ieder geval is het Git protocol relatief eenvoudig in te stellen. Eigenlijk is het enige dat je moet doen dit commando een daemon uitvoeren:
 
 	git daemon --reuseaddr --base-path=/opt/git/ /opt/git/
 
-`--reuseaddr` staat de server toe om te herstarten zonder te wachten tot oude connecties een time out krijgen, de `--base-path` optie staat mensen toe om projecten te clonen zonder het volledige pad te specificeren, en het pad aan het einde vertelt de Git daemon waar hij moet kijken voor de te exporteren repositories. Als je een firewall draait, zul je er ook een gat in moeten maken in poort 9418 op de machine waar je dit op instelt.
+`--reuseaddr` staat de server toe om te herstarten zonder te wachten tot oude connecties een time-out krijgen, de `--base-path` optie staat mensen toe om projecten te clonen zonder het volledige pad te specificeren, en het pad aan het einde vertelt de Git daemon waar hij moet kijken voor de te exporteren repositories. Als je een firewall draait, zul je er poort 9418 open moeten zetten op de machine waar je dit op gaat doen.
 
-Je kunt dit proces op een aantal manieren daemonisern, afhankelijk van het besturingssystem waarop je draait. Op een Ubuntu machine, zul je een Upstart script gebruiken. Dus in het volgende bestand
+Je kunt dit proces op een aantal manieren daemoniseren, afhankelijk van het besturingssystem waarop je draait. Op een Ubuntu machine, zul je een Upstart script gebruiken. Dus in het volgende bestand
 
 	/etc/event.d/local-git-daemon
 
@@ -533,18 +709,18 @@ stop je dit script:
 
 Omwille van veiligheidsredenen, wordt sterk aangeraden om deze daemon uit te voeren als gebruiker met alleen-lezen toegang op de repositories – je kunt dit makkelijk doen door een gebruiker 'git-ro' aan te maken en de daemon als deze uit te voeren. Om het eenvoudig te houden voeren we het als dezelfde 'git' gebruiker uit, als waarin Gitosis draait.
 
-Als je je machine herstart, zal je Git daemon automatisch opstarten en herstarten als hij onderuit gaat. Om het te laten draaien zonder te herstarten, kun je dit uitvoeren:
+Als je de machine herstart, zal de Git daemon automatisch opstarten en herstarten als de server onderuit gaat. Om het te laten draaien zonder te herstarten, kun je dit uitvoeren:
 
 	initctl start local-git-daemon
 
-Op andere systemen zul je misschien `xinetd` willen gebruiken, een script in je `sysvinit` systeem, of iets anders – zolang je dat commando maar ge-daemoniseerd krijgt en op een of andere manier in de gaten gehouden wordt.
+Op andere systemen zul je misschien `xinetd` willen gebruiken, een script in je `sysvinit` systeem, of iets anders – zolang je dat commando maar ge-daemoniseerd krijgt en deze op een of andere manier in de gaten gehouden wordt.
 
-Vervolgens zul je je Gitosis server moeten vertellen welke repositories je ongeverifieerde Gitserver gebaseerde toegang toestaat. Als je een sectie toevoegt voor iedere repository, dan kun je die repositories specificeren waarop je je Git daemon wilt laten lezen. Als je Git protocol toegang tot je iphone project wilt toestaan, dan voeg je dit toe aan het eind van het `gitosis.conf` bestand:
+Vervolgens zul je je Gitosis server moeten vertellen welke repositories je onauthenticeerde Gitserver gebaseerde toegang toestaat. Als je een sectie toevoegt voor iedere repository, dan kun je die repositories specificeren waarop je je Git daemon wilt laten lezen. Als je Git protocol toegang tot je iphone project wilt toestaan, dan voeg je dit toe aan het eind van het `gitosis.conf` bestand:
 
 	[repo iphone_project]
 	daemon = yes
 
-Als dat gecommit en gepushed is, dan zou je draaiende daemon verzoeken moeten serveren aan iedereen die toegang heeft op poort 9418 van je server.
+Als dat gecommit en gepushed is, dan zou de draaiende daemon verzoeken moeten serveren aan iedereen die toegang heeft op poort 9418 van je server.
 
 Als je besluit om Gitosis niet te gebruiken, maar je wilt toch een Git daemon instellen, dan moet je dit op ieder project uitvoeren waarvoor je de Git daemon wilt laten serveren:
 
@@ -570,15 +746,15 @@ Als je nu het project commit en pushed, start GitWeb automatisch met het tonen v
 
 ## Hosted Git ##
 
-Als je niet door al het werk heen wilt om je eigen Git server op te zetten, heb je meerdere opties om je Git project op een externe speciale hosting pagina te laten beheren. Dit biedt een aantal voordelen: een ge-hoste pagina is over het algemeen snel in te stellen, en eenvoudig om projecten op te starten, en er komt geen server beheer en onderhoud bij kijken. Zelfs als je je eigen server intern ingesteld hebt, zul je misschien een publieke host pagina voor je open source broncode willen – dat is over het algemeen makkelijker voor de open source commune te vinden en je er mee te helpen.
+Als je niet al het werk wilt doen om je eigen Git server op te zetten, heb je meerdere opties om je Git project op een externe speciale hosting pagina te laten beheren. Dit biedt een aantal voordelen: een ge-hoste pagina is over het algemeen snel in te stellen, eenvoudig om projecten mee op te starten, en er komt geen serverbeheer en -onderhoud bij kijken. Zelfs als je je eigen server intern ingesteld hebt, zul je misschien een publieke host pagina voor je open source broncode willen – dat is over het algemeen makkelijker voor de open source commune te vinden en je er mee te helpen.
 
 Vandaag de dag heb je een enorm aantal beheer opties om uit te kiezen, elk met verschillende voor- en nadelen. Om een bijgewerkte lijst te zien, ga dan kijken op de GitHosting pagina op de hoofd Git wiki:
 
 	http://git.or.cz/gitwiki/GitHosting
 
-Omdat we ze niet allemaal kunnen behandelen, en ik toevalllig bij een ervan werk, zullen we deze sectie gebruiken om door het instellen van een account en het opzetten van een project op GitHub lopen. Dit geeft je een idee van het benodigde werk.
+Omdat we ze niet allemaal kunnen behandelen, en ik toevallig bij een ervan werk, zullen we deze paragraaf gebruiken het instellen van een account en het opzetten van een project op GitHub te doorlopen. Dit geeft je een idee van het benodigde werk.
 
-GitHub is veruit de grootste open source Git beheer pagina en het is ook een van de weinige die zowel publieke als privé beheer opties biedt, zodat je je open source en commerciele privé code in dezelfde plaats kunt bewaren. Sterker nog, we hebben GitHub gebruikt om privé samen te werken aan dit boek.
+GitHub is veruit de grootste open source Git beheer pagina en het is ook een van de weinige die zowel publieke als privé beheer opties biedt, zodat je je open source en commerciele privé code op dezelfde plaats kunt bewaren. Sterker nog, we hebben GitHub gebruikt om privé samen te werken aan dit boek.
 
 ### GitHub ###
 

From 3c88842bacda30ab45b03d31468b922283ddc3c9 Mon Sep 17 00:00:00 2001
From: Gabor Maghera <gmaghera@gmail.com>
Date: Fri, 17 Jan 2014 10:29:39 -0800
Subject: [PATCH 111/690] Update 01-chapter1.markdown

---
 hu/01-introduction/01-chapter1.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hu/01-introduction/01-chapter1.markdown b/hu/01-introduction/01-chapter1.markdown
index d05aca1fc..8bb5f20d7 100644
--- a/hu/01-introduction/01-chapter1.markdown
+++ b/hu/01-introduction/01-chapter1.markdown
@@ -8,7 +8,7 @@ Mi az a verziókövetés, és miért kellene vele törődnünk? A verziókövet
 
 Ha grafikus vagy webdizájner vagy és meg akarod tartani az összes verzióját egy képnek vagy egy weboldal tervezetnek (amit mindenképp szeretnél), egy Verziókövető Rendszer (VR) legalkalmasabb dolog a feladatra. Lehetővé teszi fájlok visszaálítást egy előző verzióra, a teljes projekt visszaállítását egy előző verzióra, változatok összehasonlítását bármely idő intervalimra, rájöhetsz miért okoz az utolsó módsításod problémát, hogyan keletkezik egy esemény és miért és így tovább. A VR használata az is jelenti ha elrontasz valamit vagy elveszne egy fájl könnyedén visszavonhatod minimális erőforrás ráfordítással.
 
-### Egyéni verziókövető rendszerk  ###
+### Egyéni verziókövető rendszerek  ###
 
 Sok ember választja verziókövető megoldásnak a fájlok különböző mappákba másolását (mappák neve egy időbélyeg ha értelmesen csinálják). Ez a legkönnyebben befogadható megoldás mert egyszerű, de hihetetlenül könnyű hibázni. Elfelejtik hogy melyik mappában vannak rossz fájlt írnak vagy írnakfelül olyat amit nem kellett volna.
 

From 870cfed1f03ebc08b3ec874a0d4ae93c99d47f5f Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Fri, 17 Jan 2014 19:53:43 -0600
Subject: [PATCH 112/690] Fixed "Hosted Git" Title

In italiano usiamo "hosting" o "host"
---
 it/04-git-server/01-chapter4.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/it/04-git-server/01-chapter4.markdown b/it/04-git-server/01-chapter4.markdown
index af62c8b8a..7855e5c8e 100644
--- a/it/04-git-server/01-chapter4.markdown
+++ b/it/04-git-server/01-chapter4.markdown
@@ -716,7 +716,7 @@ Puoi controllare quali progetti GitWeb lascia sfogliare agli utenti via browser
 
 Ora, se fai il commit ed il push del progetto, GitWeb automaticamente inizierà a mostrare il progetto iphone.
 
-## Hosted Git ##
+## Hosting Git ##
 
 Se non vuoi svolgere tutto il lavoro di configurazione di un tuo server Git, hai varie opzioni per ospitare i tuoi progetti Git su un sito esterno e dedicato. Fare questo offre un numero di vantaggi: un sito di hosting è generalmente veloce da configurare ed è facile avviare un progetto su questo, e non sono necessari spese di mantenimento o controllo del server. Se imposti e avvi il tuo server interno, puoi comunque voler utilizzare un hosting pubblico per i progetti a codice aperto — è generalmente più facile per una comunità open source trovarti ed aiutarti.
 

From 314c389e402c0a0bb952f40f7a0f99987f8939b3 Mon Sep 17 00:00:00 2001
From: "Ann + J.M" <jm@jublo.net>
Date: Wed, 15 Jan 2014 21:59:51 +0100
Subject: [PATCH 113/690] [de] Enhance section 9

---
 de/09-git-internals/01-chapter9.markdown | 302 +++++++++++------------
 1 file changed, 151 insertions(+), 151 deletions(-)

diff --git a/de/09-git-internals/01-chapter9.markdown b/de/09-git-internals/01-chapter9.markdown
index dbbaa1196..d17dafdbc 100644
--- a/de/09-git-internals/01-chapter9.markdown
+++ b/de/09-git-internals/01-chapter9.markdown
@@ -1,36 +1,36 @@
 <!--# Git Internals #-->
-# Git Internas #
+# Git Interna #
 
 <!--You may have skipped to this chapter from a previous chapter, or you may have gotten here after reading the rest of the book — in either case, this is where you’ll go over the inner workings and implementation of Git. I found that learning this information was fundamentally important to understanding how useful and powerful Git is, but others have argued to me that it can be confusing and unnecessarily complex for beginners. Thus, I’ve made this discussion the last chapter in the book so you could read it early or later in your learning process. I leave it up to you to decide.-->
 
-Möglicherweise hast Du dieses Kapitel hier direkt aufgeschlagen, vorherige Kapitel ausgelassen, oder bist hierher gelangt, nachdem Du alle vorherigen Kapitel gelesen hast. Wie auch immer, in diesem Kapitel wirst Du mit mit den internen (xxx) und der Implementation von Git befassen. Meine eigene Erfahrung damit, diese Dinge zu lernen, war dass sie unerlässlich ist, um zu verstehen, wie unheimlich mächtig und flexibel Git ist. Allerdings gibt es Leute, die der Ansicht sind, dass sie auch verwirrend und unnötig komplex für Anfänger sein könne. Deshalb habe ich mich entschieden, dieses Kapitel an das Ende des Buches zu verlegen. Du kannst es, ganz wie es Dir beliebt, früher oder später einschieben.
+Möglicherweise hast Du dieses Kapitel hier direkt aufgeschlagen, vorherige Kapitel ausgelassen, oder bist hierher gelangt, nachdem Du alle vorherigen Kapitel gelesen hast. Wie auch immer, in diesem Kapitel wirst Du mit mit der internen Funktionsweise und der Implementierung von Git befassen. Meine eigene Erfahrung ist, dass das Lernen dieser Dinge unerlässlich ist, um zu verstehen, wie unheimlich mächtig und flexibel Git ist. Allerdings gibt es Leute, die der Ansicht sind, dass sie auch verwirrend und unnötig komplex für Anfänger sein können. Deshalb habe ich mich entschieden, dieses Kapitel an das Ende des Buches zu verlegen. Du kannst es, ganz wie es Dir beliebt, früher oder später einschieben.
 
 <!--Now that you’re here, let’s get started. First, if it isn’t yet clear, Git is fundamentally a content-addressable filesystem with a VCS user interface written on top of it. You’ll learn more about what this means in a bit.-->
 
-Lass uns also loslegen. Zunächst will ich betonen, falls das bisher noch nicht klargeworden ist, dass Git im seinen Grundzügen ein Dateisystem ist, dessen Inhalte addressierbar sind (xxx content-addressable filesystem ??? xxx) und auf dem ein VCS Interface sitzt. Wir werden gleich genauer darauf eingehen, was das heißt.
+Lass uns also loslegen. Zunächst will ich betonen, falls das bisher noch nicht klargeworden ist, dass Git im seinen Grundzügen ein Dateisystem ist, dessen Inhalte addressierbar sind und auf dem ein VCS-Interface aufgesetzt ist. Wir werden gleich genauer darauf eingehen, was das heißt.
 
 <!--In the early days of Git (mostly pre 1.5), the user interface was much more complex because it emphasized this filesystem rather than a polished VCS. In the last few years, the UI has been refined until it’s as clean and easy to use as any system out there; but often, the stereotype lingers about the early Git UI that was complex and difficult to learn.-->
 
-In den frühen Tagen von Git (d.h. vor der Version 1.5.) war das Interface sehr viel komplexer, weil es diese Dateisystem Eigenschaften stark betonte – im Gegensatz zu einem ausgearbeiteten VCS. In den letzten Jahren wurde das Interface dann stückweise verbessert und verfeinert, sodass es heute so einfach verständlich und einfach zu verwenden ist, wie alle möglichen vergleichbaren Systeme, die es gibt. Allerdings besteht scheinbar weiterhin das Vorurteil, dass das Git Interface komplex und schwer zu erlernen sei.
+In den frühen Tagen von Git (d.h. vor Version 1.5) war das Interface sehr viel komplexer, weil es diese Dateisystem-Eigenschaften stark betonte – im Gegensatz zu einem ausgearbeiteten VCS. In den letzten Jahren wurde das Interface dann stückweise verbessert und verfeinert, sodass es heute so einfach verständlich und einfach zu verwenden ist, wie alle möglichen vergleichbaren Systeme, die es gibt. Allerdings besteht scheinbar weiterhin das Vorurteil, das Git-Interface sei komplex und schwer zu erlernen.
 
 <!--The content-addressable filesystem layer is amazingly cool, so I’ll cover that first in this chapter; then, you’ll learn about the transport mechanisms and the repository maintenance tasks that you may eventually have to deal with.-->
 
-Die Dateisystem Ebene ist erstaunlich cool, weshalb ich in diesem Kapitel zuerst darauf eingehen werde. Als nächstes lernst Du etwas über die Transport Mechanismen und Repository Wartungsaufgaben, mit denen Du möglicherweise irgendwann zu tun bekommen wirst.
+Die inhaltsbasiert adressierbare Dateisystem-Ebene ist erstaunlich cool, weshalb ich in diesem Kapitel zuerst darauf eingehen werde. Als Nächstes lernst Du etwas über die Transport-Mechanismen und Repository-Wartungsaufgaben, mit denen Du möglicherweise irgendwann zu tun bekommen wirst.
 
 <!--## Plumbing and Porcelain ##-->
 ## Plumbing und Porcelain ##
 
 <!--This book covers how to use Git with 30 or so verbs such as `checkout`, `branch`, `remote`, and so on. But because Git was initially a toolkit for a VCS rather than a full user-friendly VCS, it has a bunch of verbs that do low-level work and were designed to be chained together UNIX style or called from scripts. These commands are generally referred to as "plumbing" commands, and the more user-friendly commands are called "porcelain" commands.-->
 
-In diesem Buch haben wir Git besprochen, indem wir vielleicht 30 Befehle wie `checkout`, `branch`, `remote` und so weiter verwendet haben. Weil Git aber ursprünglich als ein Werkzeugkasten konzipiert war, un nicht so sehr als ein komplettes, anwenderfreundliches VCS, gibt es auch eine Reihe von Befehlen, die ihre Arbeit auf einer sehr viel grundlegenderen Ebene verrichten. Viele davon sind ursprünglich entwickelt worden, um als UNIX Befehle miteinander verkettet zu werden oder aus Scripten heraus aufgerufen zu werden. Diese Befehle werden oft als „plumbing“ (xxx) Befehle zusammengefasst, während die eher anwenderfreundlichen Befehle „porcelain“ (d.h. Porzellan) genannt werden.
+In diesem Buch haben wir Git besprochen, indem wir vielleicht 30 Befehle wie `checkout`, `branch`, `remote` und so weiter verwendet haben. Weil Git aber ursprünglich als ein Werkzeugkasten konzipiert war und nicht so sehr als ein komplettes, anwenderfreundliches VCS, gibt es auch eine Reihe von Befehlen, die ihre Arbeit auf einer sehr viel grundlegenderen Ebene verrichten. Viele davon sind ursprünglich entwickelt worden, um als UNIX-Befehle miteinander verkettet zu werden oder aus Skripten heraus aufgerufen zu werden. Diese Befehle werden oft als „plumbing“-Befehle (Klempner-Befehle) zusammengefasst, während die eher anwenderfreundlichen Befehle „porcelain“ (d.h. Porzellan) genannt werden.
 
 <!--The book’s first eight chapters deal almost exclusively with porcelain commands. But in this chapter, you’ll be dealing mostly with the lower-level plumbing commands, because they give you access to the inner workings of Git and help demonstrate how and why Git does what it does. These commands aren’t meant to be used manually on the command line, but rather to be used as building blocks for new tools and custom scripts.-->
 
-Die ersten acht Kapitel dieses Buches haben sich fast ausschließlich mit „porcelain“ Befehlen befasst. In diesem Kapitel gehen wir dagegen auf die zugrundeliegenden „plumbing“ Befehle ein, u.a. weil sie Dir den Zugriff auf Gits innere Abläufe ermöglichen, und weil sie dabei helfen, zu verstehen, warum Git tut, was es tut. Diese Befehle sind nicht unbedingt dazu bestimmt direkt (xxx on the command line xxx) ausgeführt zu werden, sondern sind als Bausteine für Werkzeuge und Scripts gemeint.
+Die ersten acht Kapitel dieses Buches haben sich fast ausschließlich mit „Porcelain“-Befehlen befasst. In diesem Kapitel gehen wir dagegen auf die zugrundeliegenden „Plumbing“-Befehle ein, u.a. weil sie Dir den Zugriff auf die inneren Abläufe von Git ermöglichen, und weil sie dabei helfen, zu verstehen, warum Git tut, was es tut. Diese Befehle sind nicht dazu gedacht, manuell in der Eingabeaufforderung ausgeführt zu werden, sondern sind als Bausteine für Werkzeuge und Skripts gemeint.
 
 <!--When you run `git init` in a new or existing directory, Git creates the `.git` directory, which is where almost everything that Git stores and manipulates is located. If you want to back up or clone your repository, copying this single directory elsewhere gives you nearly everything you need. This entire chapter basically deals with the stuff in this directory. Here’s what it looks like:-->
 
-Wenn Du `git init` in einem neuen oder bereits bestehenden Verzeichnis ausführst, erzeugt Git das `.git` Verzeichnis, das fast alle Dateien enthält, die Git intern speichert und ändert. Wenn Du eine Sicherheitskopie Deines Repositories anlegen oder es duplizieren willst, dann reicht aus, dieses Verzeichnis zu kopieren. Dieses ganze Kapitel handelt praktisch nur von den Inhalten dieses Verzeichnisses – die so aussehen:
+Wenn Du `git init` in einem neuen oder bereits bestehenden Verzeichnis ausführst, erzeugt Git das `.git`-Verzeichnis, das fast alle Dateien enthält, die Git intern speichert und ändert. Wenn Du eine Sicherheitskopie Deines Repositorys anlegen oder es duplizieren willst, dann reicht aus, dieses Verzeichnis zu kopieren. Dieses ganze Kapitel handelt praktisch nur von den Inhalten dieses Verzeichnisses – die so aussehen:
 
 	$ ls
 	HEAD
@@ -45,11 +45,11 @@ Wenn Du `git init` in einem neuen oder bereits bestehenden Verzeichnis ausführs
 
 <!--You may see some other files in there, but this is a fresh `git init` repository — it’s what you see by default. The `branches` directory isn’t used by newer Git versions, and the `description` file is only used by the GitWeb program, so don’t worry about those. The `config` file contains your project-specific configuration options, and the `info` directory keeps a global exclude file for ignored patterns that you don’t want to track in a .gitignore file. The `hooks` directory contains your client- or server-side hook scripts, which are discussed in detail in Chapter 7.-->
 
-Möglicherweise findest Du darin weitere Dateien. Obiges stammt aus einem mit `git init` neuangelegten Repository – das sind also die Standardinhalte. Der Ordner `branches` wird von neueren Git Versionen nicht mehr verwendet, und die Datei `descriptions` wird nur vom Programm GitWeb benötigt. Du kannst sie also ignorieren. Die Datei `config` enthält Deine Projekt-spezifischen Konfigurationsoptionen, und im Ordner `info` befindet sich eine Datei, die globale Dateiausschlusspatterns (xxx) enthält, die Du nicht in jeder .gitignore Datei neu spezifizieren willst. Das `hooks` Verzeichnis enthält die client- oder serverseitigen Hook Scripte, die wir in Kapitel 7 besprochen haben.
+Möglicherweise findest Du darin weitere Dateien. Obiges stammt aus einem mit `git init` neu angelegten Repository – das sind also die Standardinhalte. Der Ordner `branches` wird von neueren Git-Versionen nicht mehr verwendet, und die Datei `descriptions` wird nur vom Programm GitWeb benötigt. Du kannst sie also ignorieren. Die Datei `config` enthält Deine projekt-spezifischen Konfigurationsoptionen, und im Ordner `info` befindet sich eine Datei, die globale Dateiausschlussmuster enthält, die Du nicht in jeder .gitignore-Datei neu spezifizieren willst. Das `hooks`-Verzeichnis enthält die client- oder serverseitigen Hook-Skripte, die wir in Kapitel 7 besprochen haben.
 
 <!--This leaves four important entries: the `HEAD` and `index` files and the `objects` and `refs` directories. These are the core parts of Git. The `objects` directory stores all the content for your database, the `refs` directory stores pointers into commit objects in that data (branches), the `HEAD` file points to the branch you currently have checked out, and the `index` file is where Git stores your staging area information. You’ll now look at each of these sections in detail to see how Git operates.-->
 
-Damit bleiben vier wichtige Einträge übrig: die Dateien `HEAD` und `index` und die Verzeichnisse `objects` und `refs`. Dies sind die Kernkomponenten eines Git Repositories: Im `objects` Verzeichnis befinden sich die Inhalte der Datenbank. Das `refs` Verzeichnis enthält Referenzen auf Commit Objekte (Branches) in dieser Datenbank. Die Datei `HEAD` zeigt auf denjeningen Branch, den Du gegenwärtig ausgecheckt hast, und in der Datei `index` verwaltet Git die Informationen der Staging Area. Wir werden auf diese Elemente jetzt im einzelnen darauf eingehen, sodass Du nachvollziehen kannst, wie Git intern arbeitet.
+Damit bleiben vier wichtige Einträge übrig: die Dateien `HEAD` und `index` und die Verzeichnisse `objects` und `refs`. Dies sind die Kernkomponenten eines Git-Repositorys: Im `objects`-Verzeichnis befinden sich die Inhalte der Datenbank. Das `refs`-Verzeichnis enthält Referenzen auf Commit-Objekte (Branches) in dieser Datenbank. Die Datei `HEAD` zeigt auf denjeningen Branch, den Du gegenwärtig ausgecheckt hast, und in der Datei `index` verwaltet Git die Informationen der Staging-Area. Wir werden auf diese Elemente jetzt im einzelnen darauf eingehen, sodass Du nachvollziehen kannst, wie Git intern arbeitet.
 
 <!--## Git Objects ##-->
 ## Git Objekte ##
@@ -57,7 +57,7 @@ Damit bleiben vier wichtige Einträge übrig: die Dateien `HEAD` und `index` und
 <!--Git is a content-addressable filesystem. Great. What does that mean?-->
 <!--It means that at the core of Git is a simple key-value data store. You can insert any kind of content into it, and it will give you back a key that you can use to retrieve the content again at any time. To demonstrate, you can use the plumbing command `hash-object`, which takes some data, stores it in your `.git` directory, and gives you back the key the data is stored as. First, you initialize a new Git repository and verify that there is nothing in the `objects` directory:-->
 
-Git ist ein Dateisystem, das Inhalte addressieren kann. Prima. Aber was heißt das? Es bedeutet, dass Git im Kern nichts anderes ist als ein einfacher Key-Value-Store („Schlüssel-Wert-Speicher“). Du kannst darin jede Art von Inhalt ablegen und Git wird einen Schlüssel dafür zurückgeben, den Du dann verwenden kannst, um diesen Inhalt jederzeit nachzuschlagen. Um das auszuprobieren, kannst Du den Plumbing Befehl `hash-object` verwenden. Dieser nimmt einen Inhalt an, speichert ihn in Deinem `.git` Verzeichnis und gibt Dir den Schlüssel zurück, unter dem der Inhalt gespeichert wurde. Dazu initialisierst Du als erstes ein neues Git Repository und verifizierst, dass das `objects` Verzeichnis leer ist:
+Git ist ein Dateisystem, das Inhalte addressieren kann. Prima. Aber was heißt das? Es bedeutet, dass Git im Kern nichts anderes ist als ein einfacher Key-Value-Store („Schlüssel-Wert-Speicher“). Du kannst darin jede Art von Inhalt ablegen und Git wird einen Schlüssel dafür zurückgeben, den Du dann verwenden kannst, um diesen Inhalt jederzeit nachzuschlagen. Um das auszuprobieren, kannst Du den Plumbing-Befehl `hash-object` verwenden. Dieser nimmt einen Inhalt an, speichert ihn in Deinem `.git`-Verzeichnis und gibt Dir den Schlüssel zurück, unter dem der Inhalt gespeichert wurde. Dazu initialisierst Du als erstes ein neues Git-Repository und verifizierst, dass das `objects`-Verzeichnis leer ist:
 
 	$ mkdir test
 	$ cd test
@@ -72,32 +72,32 @@ Git ist ein Dateisystem, das Inhalte addressieren kann. Prima. Aber was heißt d
 
 <!--Git has initialized the `objects` directory and created `pack` and `info` subdirectories in it, but there are no regular files. Now, store some text in your Git database:-->
 
-Git hat also ein Verzeichnis `objects` und darin die `pack` und `info` Unterverzeichnisse angelegt, bisher aber keine weiteren Dateien. Als nächsten speichern wir einen Text in dieser Git Datenbank:
+Git hat also ein Verzeichnis `objects` und darin die Unterverzeichnisse `pack` und `info` angelegt, bisher aber keine weiteren Dateien. Als nächsten speichern wir einen Text in dieser Git-Datenbank:
 
 	$ echo 'test content' | git hash-object -w --stdin
 	d670460b4b4aece5915caf5c68d12f560a9fe3e4
 
 <!--The `-w` tells `hash-object` to store the object; otherwise, the command simply tells you what the key would be. `-\-stdin` tells the command to read the content from stdin; if you don’t specify this, `hash-object` expects the path to a file. The output from the command is a 40-character checksum hash. This is the SHA-1 hash — a checksum of the content you’re storing plus a header, which you’ll learn about in a bit. Now you can see how Git has stored your data:-->
 
-Die Option `-w` weist `git hash-object` an, das Objekt zu speichern. Andernfalls würde Dir der Befehl lediglich den Schlüssel mitteilen. `--stdin` weist den Befehl an, den Inhalt von aus der Standardeingabe zu lesen. Wenn Du diese Option weglässt, erwartet der Befehl zusätzlich einen Dateipfad. Die Ausgabe ist eine 40 Zeichen langer SHA-1 Hash, der eine Prüfsumme des gespeicherten Inhaltes darstellt (wir gehen auf diese Hashes gleich noch genauer ein). Git hat jetzt außerdem eine neue Datei in der Datenbank angelegt:
+Die Option `-w` weist `git hash-object` an, das Objekt zu speichern. Andernfalls würde Dir der Befehl lediglich den Schlüssel mitteilen. `--stdin` weist den Befehl an, den Inhalt von aus der Standardeingabe zu lesen. Wenn Du diese Option weglässt, erwartet der Befehl zusätzlich einen Dateipfad. Die Ausgabe ist eine 40 Zeichen langer SHA-1-Hash, der eine Prüfsumme des gespeicherten Inhaltes darstellt (wir gehen auf diese Hashes gleich noch genauer ein). Git hat jetzt außerdem eine neue Datei in der Datenbank angelegt:
 
 	$ find .git/objects -type f
 	.git/objects/d6/70460b4b4aece5915caf5c68d12f560a9fe3e4
 
 <!--You can see a file in the `objects` directory. This is how Git stores the content initially — as a single file per piece of content, named with the SHA-1 checksum of the content and its header. The subdirectory is named with the first 2 characters of the SHA, and the filename is the remaining 38 characters.-->
 
-D.h., im `objects` Verzeichnis befindet sich genau eine Datei. Auf diese Weise Git speichert Inhalte (xxx wieso initially? xxx): in jeweils einer Datei pro Inhalt, referenziert durch den SHA-1 Hash des Inhaltes und seines Headers (xxx Kopfdaten? xxx). Der Name des Unterverzeichnis `d6` sind die ersten zwei Zeichen des SHA-1 Hashes und der Dateiname die verbleibenden 38 Zeichen.
+Du siehst im `objects` Verzeichnis genau eine Datei. Auf diese Weise Git speichert Inhalte anfänglich: in jeweils einer Datei pro Inhalt, referenziert durch den SHA-1-Hash des Inhaltes und seiner Kopfzeile. Der Name des Unterverzeichnis `d6` sind die ersten zwei Zeichen des SHA-1-Hashes und der Dateiname die verbleibenden 38 Zeichen.
 
 <!--You can pull the content back out of Git with the `cat-file` command. This command is sort of a Swiss army knife for inspecting Git objects. Passing `-p` to it instructs the `cat-file` command to figure out the type of content and display it nicely for you:-->
 
-Mit dem Befehl `git cat-file` kannst Du den jeweiligen Inhalt nachschlagen. Dieser Befehl ist so etwas wie ein Schweizer Taschenmesser, wenn es um Objekte in der Git Datenbank geht. Wenn Du die Option `-p` übergibst, versucht `git cat-file`, die Art des Inhaltes (z.B. den Dateitypen xxx) herauszufinden und die Anzeige entsprechend lesbar zu formatieren:
+Mit dem Befehl `git cat-file` kannst Du den jeweiligen Inhalt nachschlagen. Dieser Befehl ist so etwas wie ein Schweizer Taschenmesser, wenn es um Objekte in der Git-Datenbank geht. Wenn Du die Option `-p` übergibst, versucht `git cat-file`, die Art des Inhaltes herauszufinden und die Anzeige entsprechend lesbar zu formatieren:
 
 	$ git cat-file -p d670460b4b4aece5915caf5c68d12f560a9fe3e4
 	test content
 
 <!--Now, you can add content to Git and pull it back out again. You can also do this with content in files. For example, you can do some simple version control on a file. First, create a new file and save its contents in your database:-->
 
-Auf diese Weise kannst Du also Inhalte zur Datenbank hinzufügen und von dort wieder nachschlagen. Wenn Du beispielsweise eine einzelne Datei versionskontrollieren willst, kannst Du zunächst die Datei anlegen und den Inhalt in der Datenbank speichern:
+Auf diese Weise kannst Du also Inhalte zu Git hinzufügen und von dort wieder nachschlagen. Das klappt auch mit Dateiinhalten. Wenn Du beispielsweise eine einzelne Datei versionskontrollieren willst, lege die Datei zunächst an und speichere ihren Inhalt in der Datenbank:
 
 	$ echo 'version 1' > test.txt
 	$ git hash-object -w test.txt
@@ -113,7 +113,7 @@ Dann kannst Du Änderungen vornehmen und die Datei erneut speichern:
 
 <!--Your database contains the two new versions of the file as well as the first content you stored there:-->
 
-Die Datenbank enthält jetzt zwei weitere Versionen der Datei neben dem ursprünglich gespeicherten Inhalt (xxx):
+Die Datenbank enthält jetzt zwei weitere Versionen der Datei neben dem ursprünglich gespeicherten Inhalt:
 
 	$ find .git/objects -type f
 	.git/objects/1f/7a7a472abf3dd9643fd615f6da379c4acb3e3a
@@ -138,17 +138,17 @@ Oder die zweite Version:
 
 <!--But remembering the SHA-1 key for each version of your file isn’t practical; plus, you aren’t storing the filename in your system — just the content. This object type is called a blob. You can have Git tell you the object type of any object in Git, given its SHA-1 key, with `cat-file -t`:-->
 
-Sich den SHA-1 Hash für jede Version merken zu müssen, ist allerdings nicht sonderlich praktisch. Außerdem speicherst Du nicht den Dateinamen in der Datenbank, sondern lediglich den Inhalt der Datei. Ein solcher Objekttyp wird als „Blob“ bezeichnet. Mit `git cat-file -t` kannst Du Git nach dem Typ eines Objektes in der Datenbank fragen:
+Sich den SHA-1-Hash für jede Version merken zu müssen, ist allerdings nicht sonderlich praktisch. Außerdem speicherst Du nicht den Dateinamen in der Datenbank, sondern lediglich den Inhalt der Datei. Ein solcher Objekttyp wird als „Blob“ bezeichnet. Mit `git cat-file -t` kannst Du Git nach dem Typ eines Objektes in der Datenbank fragen:
 
 	$ git cat-file -t 1f7a7a472abf3dd9643fd615f6da379c4acb3e3a
 	blob
 
 <!--### Tree Objects ###-->
-### Baum Objekte ###
+### Baum-Objekte ###
 
 <!--The next type you’ll look at is the tree object, which solves the problem of storing the filename and also allows you to store a group of files together. Git stores content in a manner similar to a UNIX filesystem, but a bit simplified. All the content is stored as tree and blob objects, with trees corresponding to UNIX directory entries and blobs corresponding more or less to inodes or file contents. A single tree object contains one or more tree entries, each of which contains a SHA-1 pointer to a blob or subtree with its associated mode, type, and filename. For example, the most recent tree in the simplegit project may look something like this:-->
 
-Als nächstes schauen wir uns den Objekttyp „Tree“ (Baum) an, der es ermöglicht, Dateinamen zu speichern und Dateien zu gruppieren. Git speichert Inhalte in einer ähnlichen Weise wie das UNIX Dateisystem, allerdings ein bisschen vereinfacht. Sie werden als Tree und Blob Objekte abgelegt, wobei die Trees mit UNIX Verzeichnis Einträgen korrespondieren und Blobs mehr oder weniger mit den inode Einträgen bzw. Datei Inhalten. Ein einzelnes Baum Objekt enthält einen oder mehrere Einträge, von denen jeder ein SHA-1 Hash ist, der wiederum einen Blob oder einen Untertree referenziert. Jeder dieser Einträge verfügt außerdem über einen Modus, Typ und Dateinamen. Beispielsweise sieht das aktuelle Tree Objekt im simplegit Projekt möglicherweise so aus:
+Als Nächstes schauen wir uns den Objekttyp „Tree“ (Baum) an, der es ermöglicht, Dateinamen zu speichern und Dateien zu gruppieren. Git speichert Inhalte in einer ähnlichen Weise wie das UNIX-Dateisystem, allerdings ein bisschen vereinfacht. Sie werden als Tree- und Blob-Objekte abgelegt, wobei die Trees mit UNIX-Verzeichnis-Einträgen korrespondieren und Blobs mehr oder weniger mit den inode-Einträgen bzw. Datei-Inhalten. Ein einzelnes Baum-Objekt enthält einen oder mehrere Einträge, von denen jeder ein SHA-1-Hash ist, der wiederum einen Blob oder einen Untertree referenziert. Jeder dieser Einträge verfügt außerdem über einen Modus, Typ und Dateinamen. Beispielsweise sieht das aktuelle Tree-Objekt im simplegit-Projekt möglicherweise so aus:
 
 	$ git cat-file -p master^{tree}
 	100644 blob a906cb2a4a904a152e80877d4088654daad0c859      README
@@ -157,7 +157,7 @@ Als nächstes schauen wir uns den Objekttyp „Tree“ (Baum) an, der es ermögl
 
 <!--The `master^{tree}` syntax specifies the tree object that is pointed to by the last commit on your `master` branch. Notice that the `lib` subdirectory isn’t a blob but a pointer to another tree:-->
 
-Die `master^{tree}` Syntax spezifiziert, dass wir an dem Tree Objekt interessiert sind, auf das der letzte Commit des `master` Branches zeigt. Beachte, dass das `lib` Unterverzeichnis nicht auf ein Blob, sondern wiederum auf einen weiteren Baum zeigt.
+Die `master^{tree}`-Syntax spezifiziert, dass wir an dem Tree-Objekt interessiert sind, auf das der letzte Commit des `master`-Branches zeigt. Beachte, dass das Unterverzeichnis `lib` nicht auf ein Blob, sondern wiederum auf einen weiteren Baum zeigt.
 
 	$ git cat-file -p 99f1a6d12cb4b6f19c8655fca46c3ecf317074e0
 	100644 blob 47c6340d6459e05787f644c2447d2595f5d3a54b      simplegit.rb
@@ -169,22 +169,22 @@ Git speichert Daten also, konzeptuell gesehen, in etwa wie in Bild 9-1 dargestel
 <!--Figure 9-1. Simple version of the Git data model.-->
 
 Insert 18333fig0901.png
-Bild 9-1. Vereinfachte Darstellung des Git Datenmodels.
+Bild 9-1. Vereinfachte Darstellung des Git-Datenmodels.
 
 <!--You can create your own tree. Git normally creates a tree by taking the state of your staging area or index and writing a tree object from it. So, to create a tree object, you first have to set up an index by staging some files. To create an index with a single entry — the first version of your test.txt file — you can use the plumbing command `update-index`. You use this command to artificially add the earlier version of the test.txt file to a new staging area. You must pass it the `-\-add` option because the file doesn’t yet exist in your staging area (you don’t even have a staging area set up yet) and `-\-cacheinfo` because the file you’re adding isn’t in your directory but is in your database. Then, you specify the mode, SHA-1, and filename:-->
 
-Du kannst auch Deine eigenen Tree Objekte anlegen. Git erzeugt Trees normalerweise, indem es die Inhalte der Staging Area nimmt und als ein Tree Objekt speichert. D.h., um ein Tree Objekt anzulegen, musst Du zunächst einen Index (d.h. eine Staging Area) erzeugen, indem Du einige Dateien hinzufügst. Um einen einzelnen Eintrag in den Index zu schreiben – z.B. die erste version der test.txt Datei – kannst Du den Plumbing Befehl `git update-index` verwenden, der eine frühere Version dieser Datei künstlich zu einer neuen Staging Area hinzufügt. Du musst ihm die `--add` Option übergeben, weil die Datei bisher noch nicht in der Staging Area enthalten ist (Du hast ja bisher noch überhaupt keine Staging Area aufgesetzt), und die `--cacheinfo` Option, weil Du eine Datei hinzufügst, die sich nicht in Deinem Arbeitsverzeichnis befindet (xxx hu? xxx), sondern in der Datenbank. Du gibst außerdem den Modus, SHA-1 Hash und den Dateinamen an:
+Du kannst auch Deine eigenen Tree-Objekte anlegen. Git erzeugt Trees normalerweise, indem es die Inhalte der Staging-Area nimmt und als ein Tree-Objekt speichert. D.h., um ein Tree-Objekt anzulegen, musst Du zunächst einen Index (d.h. eine Staging-Area) erzeugen, indem Du einige Dateien hinzufügst. Um einen einzelnen Eintrag in den Index zu schreiben – z.B. die erste version der Datei test.txt – kannst Du den Plumbing-Befehl `git update-index` verwenden, der eine frühere Version dieser Datei künstlich zu einer neuen Staging-Area hinzufügt. Du musst ihm die Option `--add` übergeben, weil die Datei bisher noch nicht in der Staging-Area enthalten ist (Du hast ja bisher noch überhaupt keine Staging-Area aufgesetzt), und die Option `--cacheinfo`, weil Du eine Datei hinzufügst, die sich nicht in Deinem Verzeichnis befindet, sondern in der Datenbank. Du gibst außerdem den Modus, SHA-1-Hash und den Dateinamen an:
 
 	$ git update-index --add --cacheinfo 100644 \
 	  83baae61804e65cc73a7201a7252750c76066a30 test.txt
 
 <!--In this case, you’re specifying a mode of `100644`, which means it’s a normal file. Other options are `100755`, which means it’s an executable file; and `120000`, which specifies a symbolic link. The mode is taken from normal UNIX modes but is much less flexible — these three modes are the only ones that are valid for files (blobs) in Git (although other modes are used for directories and submodules).-->
 
-In diesem Fall gibst Du als Modus `100644` an, was bedeutet, dass es sich um eine normale Date handelt. Eine ausführbare Datei wäre dagegen `100755` und ein symbolischer Link `120000`. Der Modus entspricht normalen UNIX Datei Modi, ist aber weniger flexibel. Die drei genannten Modi sind die einzigen, die in in Git für Dateien (blobs) verwendet werden (es gibt allerdings noch weitere Modi für Verzeichnisse und Submodule xxx).
+In diesem Fall gibst Du als Modus `100644` an, was bedeutet, dass es sich um eine normale Datei handelt. Eine ausführbare Datei wäre dagegen `100755` und ein symbolischer Link `120000`. Der Modus entspricht normalen UNIX-Datei-Modi, ist aber weniger flexibel. Die drei genannten Modi sind die einzigen, die in Git für Dateien (Blobs) verwendet werden (es gibt allerdings noch weitere Modi für Verzeichnisse und Submodule).
 
 <!--Now, you can use the `write-tree` command to write the staging area out to a tree object. No `-w` option is needed — calling `write-tree` automatically creates a tree object from the state of the index if that tree doesn’t yet exist:-->
 
-Jetzt kannst Du den Befehl `git write-tree` verwenden, um die Staging Area als Tree Objekt zu schreiben. Dazu brauchst Du die `-w` Option nicht angeben – `git write-tree` schreibt automatisch ein Tree Objekt für Einträge der Staging Area, für die es noch keinen Tree gibt:
+Jetzt kannst Du den Befehl `git write-tree` verwenden, um die Staging-Area als Tree-Objekt zu schreiben. Dazu brauchst Du die `-w` Option nicht angeben – `git write-tree` schreibt automatisch ein Tree-Objekt für Einträge der Staging-Area, für die es noch keinen Tree gibt:
 
 	$ git write-tree
 	d8329fc1cc938780ffdd9f94e0d364e0ea74f579
@@ -193,14 +193,14 @@ Jetzt kannst Du den Befehl `git write-tree` verwenden, um die Staging Area als T
 
 <!--You can also verify that this is a tree object:-->
 
-Um zu überprüfen, dass es wirklich ein Tree Objekt gibt:
+Um zu überprüfen, dass es wirklich ein Tree-Objekt gibt:
 
 	$ git cat-file -t d8329fc1cc938780ffdd9f94e0d364e0ea74f579
 	tree
 
 <!--You’ll now create a new tree with the second version of test.txt and a new file as well:-->
 
-Jetzt erzeugen wir einen neuen Tree mit der zweiten Version der test.txt Datei sowie eine neue Datei:
+Jetzt erzeugen wir einen neuen Tree mit der zweiten Version der Datei test.txt sowie eine neue Datei:
 
 	$ echo 'new file' > new.txt
 	$ git update-index test.txt
@@ -208,7 +208,7 @@ Jetzt erzeugen wir einen neuen Tree mit der zweiten Version der test.txt Datei s
 
 <!--Your staging area now has the new version of test.txt as well as the new file new.txt. Write out that tree (recording the state of the staging area or index to a tree object) and see what it looks like:-->
 
-Die Staging Area enthält jetzt eine neue Version der test.txt Datei sowie die neue Datei new.txt. Speichern wir diesen Tree (d.h. den gegenwärtigen Status der Staging Area bzw. des Index als Tree Objekt) und schauen ihn uns an:
+Die Staging-Area enthält jetzt eine neue Version der Datei test.txt sowie die neue Datei new.txt. Speichern wir diesen Tree (d.h. den gegenwärtigen Status der Staging-Area bzw. des Index als Tree-Objekt) und schauen ihn uns an:
 
 	$ git write-tree
 	0155eb4229851634a0f03eb265b69f5a2d56f341
@@ -218,7 +218,7 @@ Die Staging Area enthält jetzt eine neue Version der test.txt Datei sowie die n
 
 <!--Notice that this tree has both file entries and also that the test.txt SHA is the "version 2" SHA from earlier (`1f7a7a`). Just for fun, you’ll add the first tree as a subdirectory into this one. You can read trees into your staging area by calling `read-tree`. In this case, you can read an existing tree into your staging area as a subtree by using the `-\-prefix` option to `read-tree`:-->
 
-Beachte, dass das Tree Objekt zwei Datei Einträge hat und dass der SHA-1 Hash der test.txt Datei noch derselbe „Version 2“ Hash ist wie zuvor (`1f7a7a`). Fügen wir jetzt den ersten Tree als ein Unterverzeichnis is diesem hier ein. Du kannst einen Tree mit `git read-tree` in die Staging Area einlesen. In diesem Fall können wir einen bereits existierenden Tree als einen Untertree zur Staging Area hinzufügen, indem wir die `--prefix` Option verwenden:
+Beachte, dass das Tree-Objekt zwei Datei-Einträge hat und dass der SHA-1-Hash der Datei test.txt noch derselbe „Version 2“-Hash ist wie zuvor (`1f7a7a`). Fügen wir jetzt den ersten Tree als ein Unterverzeichnis in diesem hier ein. Du kannst einen Tree mit `git read-tree` in die Staging-Area einlesen. In diesem Fall können wir einen bereits existierenden Tree als einen Untertree zur Staging-Area hinzufügen, indem wir die Option `--prefix` verwenden:
 
 	$ git read-tree --prefix=bak d8329fc1cc938780ffdd9f94e0d364e0ea74f579
 	$ git write-tree
@@ -230,23 +230,23 @@ Beachte, dass das Tree Objekt zwei Datei Einträge hat und dass der SHA-1 Hash d
 
 <!--If you created a working directory from the new tree you just wrote, you would get the two files in the top level of the working directory and a subdirectory named `bak` that contained the first version of the test.txt file. You can think of the data that Git contains for these structures as being like Figure 9-2.-->
 
-Wenn Du ein Arbeitsverzeichnis aus diesem neuen Tree Objekt auschecken würdest, würdest Du zwei Dateien im Hauptverzeichnis und ein Unterverzeichnis mit dem Namen `bak` erhalten, in dem sich die erste Version der Datei test.txt befindet. Du kannst Dir die Daten, die Git für diese Strukturen speichert, in etwa wie in Bild 9-2 vorstellen.
+Wenn Du ein Arbeitsverzeichnis aus diesem neuen Tree-Objekt auschecken würdest, würdest Du zwei Dateien im Hauptverzeichnis und ein Unterverzeichnis mit dem Namen `bak` erhalten, in dem sich die erste Version der Datei test.txt befindet. Du kannst Dir die Daten, die Git für diese Strukturen speichert, in etwa wie in Bild 9-2 vorstellen.
 
 <!--Figure 9-2. The content structure of your current Git data.-->
 
 Insert 18333fig0902.png
-Bild 9-2. Die Datenstruktur des gegenwärtigen Git Repositories.
+Bild 9-2. Die Datenstruktur des gegenwärtigen Git-Repositorys.
 
 <!--### Commit Objects ###-->
 ### Objekte committen ###
 
 <!--You have three trees that specify the different snapshots of your project that you want to track, but the earlier problem remains: you must remember all three SHA-1 values in order to recall the snapshots. You also don’t have any information about who saved the snapshots, when they were saved, or why they were saved. This is the basic information that the commit object stores for you.-->
 
-Du hast jetzt drei Trees, die verschiedene Snapshots Deines Projektes spezifizieren (xxx), die Du nachverfolgen willst. Das ursprüngliche Problem besteht aber weiterhin: Du musst alle drei SHA-1 Hash Werte erinnern, um wieder an die Snapshots zu kommen. Ebenso fehlen Dir die Informationen darüber, wer die Snapshots gespeichert hat, wann sie gespeichert wurden und warum. Dies sind die drei Hauptinformationen, die ein Commit Objekt für uns speichert.
+Du hast jetzt drei Trees, die verschiedene Snapshots Deines Projektes spezifizieren, die Du nachverfolgen willst. Das ursprüngliche Problem besteht aber weiterhin: Du musst dir alle drei SHA-1-Hashwerte merken, um wieder an die Snapshots zu kommen. Ebenso fehlen Dir die Informationen darüber, wer die Snapshots gespeichert hat, wann sie gespeichert wurden und warum. Dies sind die drei Hauptinformationen, die ein Commit-Objekt für uns speichert.
 
 <!--To create a commit object, you call `commit-tree` and specify a single tree SHA-1 and which commit objects, if any, directly preceded it. Start with the first tree you wrote:-->
 
-Um ein Commit Objekt anzulegen, verwendest Du den Befehl `git commit-tree`, spezifizierst einen einzelnen Tree SHA-1 Hash und welche Commit Objekte (sofern vorhanden) die direkten Vorgänger sind. Fangen wir damit an, den ersten Tree, den Du angelegt hast, zu committen:
+Um ein Commit-Objekt anzulegen, verwendest Du den Befehl `git commit-tree`, spezifizierst den SHA-1-Hash eines einzelnen Trees und welche Commit-Objekte (sofern vorhanden) die direkten Vorgänger sind. Fangen wir damit an, den ersten Tree, den Du angelegt hast, zu committen:
 
 	$ echo 'first commit' | git commit-tree d8329f
 	fdf4fc3344e67ab068f836878b6c4951e3b15f3d
@@ -264,11 +264,11 @@ Du kannst diesen Commit jetzt mit `git cat-file` nachschlagen:
 
 <!--The format for a commit object is simple: it specifies the top-level tree for the snapshot of the project at that point; the author/committer information pulled from your `user.name` and `user.email` configuration settings, with the current timestamp; a blank line, and then the commit message.-->
 
-Das Format für ein Commit Objekt ist einfach: es besteht aus dem toplevel Tree für den Snapshot des Projektes zum gegebenen Zeitpunkt, die Autor und ggf. Committer Information (jeweils entsprechend Deiner `user.name` und `user.email` Konfiguration) und dem Timestamp. Dann folgen eine leere Zeile und die Commit Meldung.
+Das Format für ein Commit-Objekt ist einfach: es besteht aus dem obersten Tree für den Snapshot des Projektes zum gegebenen Zeitpunkt, die Autoren- und ggf. Committer-Information (jeweils entsprechend Deiner `user.name`- und `user.email`-Konfiguration) und dem Timestamp. Dann folgen eine leere Zeile und die Commit-Meldung.
 
 <!--Next, you’ll write the other two commit objects, each referencing the commit that came directly before it:-->
 
-Als nächstes speichern wir die beiden anderen Commit Objekte und referenzieren jeweils den vorhergehenden Commit:
+Als Nächstes speichern wir die beiden anderen Commit-Objekte und referenzieren jeweils den vorhergehenden Commit:
 
 	$ echo 'second commit' | git commit-tree 0155eb -p fdf4fc3
 	cac0cab538b970a37ea1e769cbbde608743bc96d
@@ -277,7 +277,7 @@ Als nächstes speichern wir die beiden anderen Commit Objekte und referenzieren
 
 <!--Each of the three commit objects points to one of the three snapshot trees you created. Oddly enough, you have a real Git history now that you can view with the `git log` command, if you run it on the last commit SHA-1:-->
 
-Jedes der drei Commit Objekte zeigt auf einen der drei Snapshopt Trees, die Du zuvor gespeichert hattest. Es mag Dich überraschen, aber Du hast jetzt bereits eine vollständige Git Historie, die Du mit dem `git log` inspizieren kannst, indem Du den letzten Commit SHA-1 Hash angibst:
+Jedes der drei Commit-Objekte zeigt auf einen der drei Snapshot-Trees, die Du zuvor gespeichert hattest. Es mag Dich überraschen, aber Du hast jetzt bereits eine vollständige Git-Historie, die Du mit dem `git log` inspizieren kannst, indem Du den SHA-1-Hash des letzten Commits angibst:
 
 	$ git log --stat 1a410e
 	commit 1a410efbd13591db07496601ebc7a059dd55cfe9
@@ -310,7 +310,7 @@ Jedes der drei Commit Objekte zeigt auf einen der drei Snapshopt Trees, die Du z
 
 <!--Amazing. You’ve just done the low-level operations to build up a Git history without using any of the front ends. This is essentially what Git does when you run the `git add` and `git commit` commands — it stores blobs for the files that have changed, updates the index, writes out trees, and writes commit objects that reference the top-level trees and the commits that came immediately before them. These three main Git objects — the blob, the tree, and the commit — are initially stored as separate files in your `.git/objects` directory. Here are all the objects in the example directory now, commented with what they store:-->
 
-Fantastisch, oder? Du hast jetzt sämtliche low-level Operationen durchgeführt, die eine vollständige Git Historie aufbauen, ohne aber irgendwelche Git Frontend Befehle (xxx) zu verwenden. Im wesentlichen ist das derselbe Prozess, der im Hintergrund stattfindet, wenn Du die Befehle `git add` und `git commit` ausführst. Sie speichern Blobs für die Dateien, die Du hinzugefügt oder geändert hast, aktualisieren den Index (d.h. die Staging Area), speichern Trees und legen Commit Objekte an, die die toplevel Trees und Commits referenzieren, die ihnen unmittelbar vorhergingen. Diese drei Hauptobjekte – Blob, Tree und Commit – werden zunächst als separate Dateien im `.git/objects` Verzeichnis gespeichert. Hier ist eine Liste aller Objekte, die sich in unserem Beispiel Repository jetzt in der Datenbank befinden – jeweils mit einem Kommentar darüber, was sie speichern:
+Fantastisch, oder? Du hast jetzt sämtliche Low-Level-Operationen durchgeführt, die eine vollständige Git-Historie aufbauen, ohne aber irgendwelche Frontend-Befehle von Git zu verwenden. Im Wesentlichen ist das derselbe Prozess, der im Hintergrund stattfindet, wenn Du die Befehle `git add` und `git commit` ausführst. Sie speichern Blobs für die Dateien, die Du hinzugefügt oder geändert hast, aktualisieren den Index (d.h. die Staging-Area), speichern Trees und legen Commit Objekte an, die die obersten Trees sowie die Commits referenzieren, die ihnen unmittelbar vorhergingen. Diese drei Hauptobjekte – Blob, Tree und Commit – werden zunächst als separate Dateien im Verzeichnis `.git/objects` gespeichert. Hier ist eine Liste aller Objekte, die sich in unserem Beispiel-Repository jetzt in der Datenbank befinden – jeweils mit einem Kommentar darüber, was sie speichern:
 
 	$ find .git/objects -type f
 	.git/objects/01/55eb4229851634a0f03eb265b69f5a2d56f341 # tree 2
@@ -326,19 +326,19 @@ Fantastisch, oder? Du hast jetzt sämtliche low-level Operationen durchgeführt,
 
 <!--If you follow all the internal pointers, you get an object graph something like Figure 9-3.-->
 
-Wenn man all diese Zeiger auflöst, erhält man einen Objekt Graphen wie den folgenden (Bild 9-3).
+Wenn man all diese Zeiger auflöst, erhält man einen Objekt-Graphen wie den folgenden (Bild 9-3).
 
 <!--Figure 9-3. All the objects in your Git directory.-->
 
 Insert 18333fig0903.png
-Bild 9-3. Die Objekte im Beispielrepository.
+Bild 9-3. Alle Objekte in Deinem Git-Repository.
 
 <!--### Object Storage ###-->
-### Objekt Speicher ###
+### Objekt-Speicher ###
 
 <!--I mentioned earlier that a header is stored with the content. Let’s take a minute to look at how Git stores its objects. You’ll see how to store a blob object — in this case, the string "what is up, doc?" — interactively in the Ruby scripting language. You can start up interactive Ruby mode with the `irb` command:-->
 
-Wir haben kurz erwähnt, dass zusammen mit einem Inhalt ein Header gespeichert wird. Schauen wir uns also genauer an, wie genau Git Objekte speichert. Du wirst sehen, wie ein Blob Objekt – in diesem Fall der String „what is up, doc?“ (xxx übersetzen? xxx) gespeichert wird. Dazu nuten wir den interaktiven Ruby Modus, den Du mit dem `irb` Befehl starten kannst:
+Wir haben kurz erwähnt, dass zusammen mit einem Inhalt ein Header gespeichert wird. Schauen wir uns also genauer an, wie genau Git Objekte speichert. Du wirst sehen, wie ein Blob-Objekt – in diesem Fall die Zeichenkette „what is up, doc?“ gespeichert wird. Dazu nuten wir den interaktiven Ruby-Modus, den Du mit dem `irb` Befehl starten kannst:
 
 	$ irb
 	>> content = "what is up, doc?"
@@ -346,14 +346,14 @@ Wir haben kurz erwähnt, dass zusammen mit einem Inhalt ein Header gespeichert w
 
 <!--Git constructs a header that starts with the type of the object, in this case a blob. Then, it adds a space followed by the size of the content and finally a null byte:-->
 
-Git erzeugt einen Header, der mit dem Objekt Typ beginnt, in diesem Fall ist das ein Blob. Dann folgt ein Leerzeichen, die Anzahl der Zeichen des Inhalts und schließlich ein Nullbyte.
+Git erzeugt einen Header, der mit dem Objekttyp beginnt, in diesem Fall ist das ein Blob. Dann folgt ein Leerzeichen, die Anzahl der Zeichen des Inhalts und schließlich ein Nullbyte.
 
 	>> header = "blob #{content.length}\0"
 	=> "blob 16\000"
 
 <!--Git concatenates the header and the original content and then calculates the SHA-1 checksum of that new content. You can calculate the SHA-1 value of a string in Ruby by including the SHA1 digest library with the `require` command and then calling `Digest::SHA1.hexdigest()` with the string:-->
 
-Git fügt diesen Header mit dem ursprünglichen Inhalt zusammen und kalkuliert aus dem Ergebnis die SHA-1 Prüfsumme (Hash). Du kannst einen SHA-1 Hash in Ruby berechnen, indem Du die SHA1 digest Bibliothek mit `require` einbindest und dann `Digest::SHA1.hexdigest()` mit dem String ausführst:
+Git fügt diesen Header mit dem ursprünglichen Inhalt zusammen und kalkuliert aus dem Ergebnis die SHA-1-Prüfsumme (Hash). Du kannst einen SHA-1-Hash in Ruby berechnen, indem Du die SHA1-Digest-Bibliothek mit `require` einbindest und dann `Digest::SHA1.hexdigest()` mit der Zeichenkette ausführst:
 
 	>> store = header + content
 	=> "blob 16\000what is up, doc?"
@@ -364,7 +364,7 @@ Git fügt diesen Header mit dem ursprünglichen Inhalt zusammen und kalkuliert a
 
 <!--Git compresses the new content with zlib, which you can do in Ruby with the zlib library. First, you need to require the library and then run `Zlib::Deflate.deflate()` on the content:-->
 
-Git komprimiert den neuen Inhalt (d.h. inklusive des Headers) mit zlib. In Ruby kannst Du dazu die zlib Bibliothek verwenden, indem Du wiederum zuerst die Bibliothek mit `require` einbindest und dann `Zlib::Deflate.deflate()` mit dem Inhalt aufrufst:
+Git komprimiert den neuen Inhalt (d.h. inklusive des Headers) mit zlib. In Ruby kannst Du dazu die zlib-Bibliothek verwenden, indem Du wiederum zuerst die Bibliothek mit `require` einbindest und dann `Zlib::Deflate.deflate()` mit dem Inhalt aufrufst:
 
 	>> require 'zlib'
 	=> true
@@ -386,18 +386,18 @@ Schließlich schreibst Du den zlib-komprimierten Inhalt in eine Datei auf der Fe
 
 <!--That’s it — you’ve created a valid Git blob object. All Git objects are stored the same way, just with different types — instead of the string blob, the header will begin with commit or tree. Also, although the blob content can be nearly anything, the commit and tree content are very specifically formatted.-->
 
-Das ist alles – Du hast jetzt ein valides Git Blob Objekt geschrieben. Git Objekte werden immer in dieser Weise gespeichert, lediglich mit verschiedenen Typen, d.h. anstelle des Strings „blob“ wird der Header mit „commit“ oder „tree“ anfangen. Außerdem sind Commit und Tree Inhalte auf eine sehr spezifische Weise formatiert, während Blobs beliebige Inhalte sein können.
+Das ist alles – Du hast jetzt ein valides Git-Blob-Objekt geschrieben. Git-Objekte werden immer in dieser Weise gespeichert, lediglich mit verschiedenen Typen, d.h. anstelle der Zeichenkette „blob“ wird der Header mit „commit“ oder „tree“ anfangen. Außerdem sind Commit- und Tree-Inhalte auf eine sehr spezifische Weise formatiert, während Blobs beliebige Inhalte sein können.
 
 <!--## Git References ##-->
-## Git Referenzen ##
+## Git-Referenzen ##
 
 <!--You can run something like `git log 1a410e` to look through your whole history, but you still have to remember that `1a410e` is the last commit in order to walk that history to find all those objects. You need a file in which you can store the SHA-1 value under a simple name so you can use that pointer rather than the raw SHA-1 value.-->
 
-Du kannst Befehle wie `git log 1a410e` ausführen, um die Commit Historie zu inspizieren, aber dazu musst Du Dir jeweils merken, dass `1a410e` der jeweils letzte Commit ist. Um diese SHA-1 Hashes mit einfacheren, verständlichen Namen zu referenzieren, verwendet Git weitere Dateien, in denen die Namen für Hashes gespeichert sind.
+Du kannst Befehle wie `git log 1a410e` ausführen, um die Commit-Historie zu inspizieren, aber dazu musst Du Dir jeweils merken, dass `1a410e` der jeweils letzte Commit ist. Um diese SHA-1-Hashes mit einfacheren, verständlichen Namen zu referenzieren, verwendet Git weitere Dateien, in denen die Namen für Hashes gespeichert sind.
 
 <!--In Git, these are called "references" or "refs"; you can find the files that contain the SHA-1 values in the `.git/refs` directory. In the current project, this directory contains no files, but it does contain a simple structure:-->
 
-Diese Namen werden in Git intern als „references“ oder „refs“ bezeichnet. Du kannst diese Dateien, die SHA-1 Hashes enthalten, im `.git/refs` Verzeichnis finden. In unserem gegenwärtigen Projekt enthält dieses Verzeichnis noch keine Dateien, aber eine simple Verzeichnisstruktur:
+Diese Namen werden in Git intern als „references“ oder „refs“ bezeichnet. Du kannst diese Dateien, die SHA-1-Hashes enthalten, im Verzeichnis `.git/refs` finden. In unserem gegenwärtigen Projekt enthält dieses Verzeichnis noch keine Dateien, aber eine simple Verzeichnisstruktur:
 
 	$ find .git/refs
 	.git/refs
@@ -408,13 +408,13 @@ Diese Namen werden in Git intern als „references“ oder „refs“ bezeichnet
 
 <!--To create a new reference that will help you remember where your latest commit is, you can technically do something as simple as this:-->
 
-Um jetzt eine neue Referenz anzulegen, die Dir dabei hilft, Dich zu erinnern, wo sich Dein letzten Commit befindet, könntest Du, technisch gesehen, Folgendes tun:
+Um jetzt eine neue Referenz anzulegen, die Dir dabei hilft, Dich zu erinnern, wo sich Dein letzter Commit befindet, könntest Du, technisch gesehen, Folgendes tun:
 
 	$ echo "1a410efbd13591db07496601ebc7a059dd55cfe9" > .git/refs/heads/master
 
 <!--Now, you can use the head reference you just created instead of the SHA-1 value in your Git commands:-->
 
-Jetzt kannst Du diese „head“ Referenz anstelle des SHA-1 Wertes in allen möglichen Git Befehlen verwenden:
+Jetzt kannst Du diese „head“-Referenz anstelle des SHA-1-Wertes in allen möglichen Git-Befehlen verwenden:
 
 	$ git log --pretty=oneline  master
 	1a410efbd13591db07496601ebc7a059dd55cfe9 third commit
@@ -423,13 +423,13 @@ Jetzt kannst Du diese „head“ Referenz anstelle des SHA-1 Wertes in allen mö
 
 <!--You aren’t encouraged to directly edit the reference files. Git provides a safer command to do this if you want to update a reference called `update-ref`:-->
 
-Allerdings ist es nicht empfehlenswert, die Referenz Dateien direkt zu bearbeiten. Git stellt einen sichereren Befehl dafür zur Verfügung, den Befehl `git update-ref`:
+Allerdings ist es nicht empfehlenswert, die Referenz-Dateien direkt zu bearbeiten. Git stellt einen sichereren Befehl dafür zur Verfügung, den Befehl `git update-ref`:
 
 	$ git update-ref refs/heads/master 1a410efbd13591db07496601ebc7a059dd55cfe9
 
 <!--That’s basically what a branch in Git is: a simple pointer or reference to the head of a line of work. To create a branch back at the second commit, you can do this:-->
 
-Im Prinzip ist das alles, was einen Branch in Git ausmacht: ein simpler Zeiger oder eine Referenz auf den jeweiligen Kopf (xxx head xxx) einer Serie von Commits (xxx ??? xxx). Um einen neuen Branch anzulegen, der vom zweiten Commit aus verzweigt, kannst Du folgendes tun:
+Im Prinzip ist das alles, was einen Branch in Git ausmacht: ein simpler Zeiger oder eine Referenz auf den jeweiligen Head einer Arbeitsreihe. Um einen neuen Branch anzulegen, der vom zweiten Commit aus verzweigt, kannst Du Folgendes tun:
 
 	$ git update-ref refs/heads/test cac0ca
 
@@ -443,23 +443,23 @@ Dein Branch beginnt jetzt beim zweiten Commit:
 
 <!--Now, your Git database conceptually looks something like Figure 9-4.-->
 
-Die Git Datenbank unseres Beispielrepositories ist jetzt wie folgt strukturiert:
+Die Git-Datenbank unseres Beispiel-Repositorys ist jetzt wie folgt strukturiert:
 
 <!--Figure 9-4. Git directory objects with branch head references included.-->
 
 Insert 18333fig0904.png
-Bild 9-4. Git Verzeichnis Objekte mit Branch Head Referenzen.
+Bild 9-4. Git-Verzeichnis-Objekte mit Branch-Head-Referenzen.
 
 <!--When you run commands like `git branch (branchname)`, Git basically runs that `update-ref` command to add the SHA-1 of the last commit of the branch you’re on into whatever new reference you want to create.-->
 
-Wenn Du Befehle wie `git branch (branchname)` verwendest, führt Git intern im wesentlichen den `update-ref` Befehl aus, um den SHA-1 Hash des letzten Commits des jeweils gegenwärtigen Branches mit dem gegebenen Namen zu referenzieren.
+Wenn Du Befehle wie `git branch (branchname)` verwendest, führt Git intern im Wesentlichen den Befehl `update-ref` aus, um den SHA-1-Hash des letzten Commits des jeweils gegenwärtigen Branches mit dem gegebenen Namen zu referenzieren.
 
 <!--### The HEAD ###-->
 ### Der HEAD ###
 
 <!--The question now is, when you run `git branch (branchname)`, how does Git know the SHA-1 of the last commit? The answer is the HEAD file. The HEAD file is a symbolic reference to the branch you’re currently on. By symbolic reference, I mean that unlike a normal reference, it doesn’t generally contain a SHA-1 value but rather a pointer to another reference. If you look at the file, you’ll normally see something like this:-->
 
-Die Frage ist jetzt: wenn Du `git branch (branchname)` ausführst, woher weiß Git den SHA-1 des letzten Commits? Die Antwort ist: aus der HEAD Datei. Diese Datei ist eine symbolische Referenz auf den jeweiligen Branch, auf dem Du Dich gerade befindest. Mit „symbolischer Referenz“ meine ich, dass sie (anders als eine „normale“ Referenz) keinen SHA-1 Hash enthält, sondern statt dessen auf eine andere Referenz zeigt. Wenn Du die HEAD Datei ansiehst, findest Du normalerweise etwas wie:
+Die Frage ist jetzt: Wenn Du `git branch (branchname)` ausführst, woher weiß Git den SHA-1 des letzten Commits? Die Antwort ist: aus der HEAD Datei. Diese Datei ist eine symbolische Referenz auf den jeweiligen Branch, auf dem Du Dich gerade befindest. Mit „symbolischer Referenz“ meine ich, dass sie (anders als eine „normale“ Referenz) keinen SHA-1-Hash enthält, sondern stattdessen auf eine andere Referenz zeigt. Wenn Du die Datei ansiehst, findest Du normalerweise etwas wie:
 
 	$ cat .git/HEAD
 	ref: refs/heads/master
@@ -473,11 +473,11 @@ Wenn Du jetzt `git checkout test` ausführst, wird Git die Datei aktualisieren,
 
 <!--When you run `git commit`, it creates the commit object, specifying the parent of that commit object to be whatever SHA-1 value the reference in HEAD points to.-->
 
-Wenn Du `git commit` ausführst, erzeugt Git das Commit Objekt und verwendet als Parent des Commit Objektes den jeweiligen Wert der Referenz auf die HEAD zeigt.
+Wenn Du `git commit` ausführst, erzeugt Git das Commit-Objekt und verwendet als Parent des Commit-Objektes den jeweiligen Wert der Referenz, auf die HEAD zeigt.
 
 <!--You can also manually edit this file, but again a safer command exists to do so: `symbolic-ref`. You can read the value of your HEAD via this command:-->
 
-Du kannst diese Datei manuell bearbeiten, aber es Git verfügt wiederum über einen sichereren Befehl, um das zu tun: `git symbolic-ref`. Du kannst den Wert des HEAD mit Hilfe des folgenden Befehls lesen:
+Du kannst diese Datei manuell bearbeiten, aber wiederum verfügt Git über einen sichereren Befehl, um das zu tun: `git symbolic-ref`. Du kannst den Wert des HEAD mit Hilfe des folgenden Befehls lesen:
 
 	$ git symbolic-ref HEAD
 	refs/heads/master
@@ -502,7 +502,7 @@ Du kannst den Befehl allerdings nicht verwenden, um eine Referenz außerhalb von
 
 <!--You’ve just gone over Git’s three main object types, but there is a fourth. The tag object is very much like a commit object — it contains a tagger, a date, a message, and a pointer. The main difference is that a tag object points to a commit rather than a tree. It’s like a branch reference, but it never moves — it always points to the same commit but gives it a friendlier name.-->
 
-Wir haben jetzt Gits drei Haupt Objekttypen besprochen, aber es gibt noch einen vierten. Das Tag Objekt ist dem Commit Objekt sehr ähnlich: es enthält einen Tagger (xxx), ein Datum, eine Meldung und eine Referenz auf ein anderes Objekt. Der Hauptunterschied besteht darin, dass ein Tag Objekt auf einen Commit zeigt und nicht auf einen Tree. Ein Tag ist in dieser Hinsicht also ähnlich einem Branch, aber er bewegt sich nie, sondern zeigt immer auf denselben Commit und gibt ihm damit einen netteren Namen.
+Wir haben jetzt Gits drei Haupt-Objekttypen besprochen, aber es gibt noch einen vierten. Das Tag-Objekt ist dem Commit-Objekt sehr ähnlich: es enthält den Autor des Tags, ein Datum, eine Meldung und eine Referenz auf ein anderes Objekt. Der Hauptunterschied besteht darin, dass ein Tag-Objekt auf einen Commit zeigt und nicht auf einen Tree. Ein Tag ist in dieser Hinsicht also ähnlich einem Branch, aber er bewegt sich nie, sondern zeigt immer auf denselben Commit und gibt ihm damit einen netteren Namen.
 
 <!--As discussed in Chapter 2, there are two types of tags: annotated and lightweight. You can make a lightweight tag by running something like this:-->
 
@@ -512,20 +512,20 @@ Wie wir schon in Kapitel 2 besprochen haben, gibt es zwei Typen von Tags: „ann
 
 <!--That is all a lightweight tag is — a branch that never moves. An annotated tag is more complex, however. If you create an annotated tag, Git creates a tag object and then writes a reference to point to it rather than directly to the commit. You can see this by creating an annotated tag (`-a` specifies that it’s an annotated tag):-->
 
-Das ist alles, woraus ein einfacher Tag besteht: einem Branch, der sich nie bewegt. Ein annotierter Tag ist komplexer. Wenn Du einen annotierten Tag anlegst, erzeugt Git ein Tag Objekt und speichert eine Referenz, die darauf zeigt, statt direkt auf den Commit zu zeigen. Du kannst das sehen, wenn Du einen annotierten Tag anlegst (`-a` bewirkt, dass wir einen annotierten Tag erhalten):
+Das ist alles, woraus ein einfacher Tag besteht: einem Branch, der sich nie bewegt. Ein annotierter Tag ist komplexer. Wenn Du einen annotierten Tag anlegst, erzeugt Git ein Tag-Objekt und speichert eine Referenz, die darauf zeigt, statt direkt auf den Commit zu zeigen. Du kannst das sehen, wenn Du einen annotierten Tag anlegst (`-a` bewirkt, dass wir einen annotierten Tag erhalten):
 
 	$ git tag -a v1.1 1a410efbd13591db07496601ebc7a059dd55cfe9 -m 'test tag'
 
 <!--Here’s the object SHA-1 value it created:-->
 
-Das erzeugt den folgenden Objekt SHA-1 Hash:
+Das erzeugt den folgenden Objekt SHA-1-Hash:
 
 	$ cat .git/refs/tags/v1.1
 	9585191f37f7b0fb9444f35a9bf50de191beadc2
 
 <!--Now, run the `cat-file` command on that SHA-1 value:-->
 
-Jetzt wendest Du den `git cat-file` Befehl auf diesen SHA-1 Hash an:
+Jetzt wendest Du den Befehl `git cat-file` auf diesen SHA-1-Hash an:
 
 	$ git cat-file -p 9585191f37f7b0fb9444f35a9bf50de191beadc2
 	object 1a410efbd13591db07496601ebc7a059dd55cfe9
@@ -537,13 +537,13 @@ Jetzt wendest Du den `git cat-file` Befehl auf diesen SHA-1 Hash an:
 
 <!--Notice that the object entry points to the commit SHA-1 value that you tagged. Also notice that it doesn’t need to point to a commit; you can tag any Git object. In the Git source code, for example, the maintainer has added their GPG public key as a blob object and then tagged it. You can view the public key by running-->
 
-Beachte, dass der der `object` Wert auf den commit SHA-1 zeigt, den Du getaggt hast, und dass die `tags/v1.1` Referenz nicht direkt auf den Commit zeigt, sondern auf das Tag Objekt. In Git kannst Du jedes beliebige Objekt taggen. Im Git Quellcode z.B. befindet sich der öffentliche GPG Schlüssel des Projektbetreibers als ein Blob Objekt, sowie ein Tag, der darauf zeigt. Auf diese Weise kannst den Schlüssel so anzeigen, indem Du den folgenden Befehl im Git Quellcode Repository ausführst:
+Beachte, dass der der Wert `object` auf den SHA-1 des Commits zeigt, den Du getaggt hast, und dass die `tags/v1.1` Referenz nicht direkt auf den Commit zeigt, sondern auf das Tag-Objekt. In Git kannst Du jedes beliebige Objekt taggen. Im Git-Quellcode z.B. befindet sich der öffentliche GPG-Schlüssel des Projektbetreibers als ein Blob-Objekt, sowie ein Tag, der darauf zeigt. Auf diese Weise kannst den Schlüssel so anzeigen, indem Du den folgenden Befehl im Git-Quellcode Repository ausführst:
 
 	$ git cat-file blob junio-gpg-pub
 
 <!--in the Git source code repository. The Linux kernel repository also has a non-commit-pointing tag object — the first tag created points to the initial tree of the import of the source code.-->
 
-Der Linux Kernel hat also ein Tag Objekt, das nicht auf einen Commit zeigt – der erste Tag (xxx) zeigt auf den ursprünglichen Tree mit dem Import des Quellcodes (xxx what? xxx).
+Der Linux-Kernel hat auch ein Tag-Objekt, das nicht auf einen Commit zeigt – der erste erstellte Tag zeigt auf den anfänglichen Tree des Quelltext-Imports.
 
 <!--### Remotes ###-->
 ### Externe Referenzen ###
@@ -563,7 +563,7 @@ Der dritte Referenztyp ist die externe Referenz („remote reference“). Wenn D
 
 <!--Then, you can see what the `master` branch on the `origin` remote was the last time you communicated with the server, by checking the `refs/remotes/origin/master` file:-->
 
-Dann kannst Du herausfinden, in welchem Zustand sich der `master` Branch auf dem `origin` Server zuletzt befand (d.h. als Du das letzte Mal mit ihm kommuniziert hast), indem Du die Datei `refs/remotes/origin/master` anschaust:
+Dann kannst Du herausfinden, in welchem Zustand sich der `master`-Branch auf dem `origin`-Server zuletzt befand (d.h. als Du das letzte Mal mit ihm kommuniziert hast), indem Du die Datei `refs/remotes/origin/master` anschaust:
 
 	$ cat .git/refs/remotes/origin/master
 	ca82a6dff817ec66f44342007202690a93763949
@@ -577,7 +577,7 @@ Externe Referenzen unterscheiden sich von Branches (`refs/heads`) hauptsächlich
 
 <!--Let’s go back to the objects database for your test Git repository. At this point, you have 11 objects — 4 blobs, 3 trees, 3 commits, and 1 tag:-->
 
-Kommen wir noch einmal auf die Objekt Datenbank zurück, die Du für Dein Test Git Repository angelegt hast. Im Moment müsstest Du 11 Objekte haben: 4 Blobs, 3 Trees, 3 Commits und 1 Tag:
+Kommen wir noch einmal auf die Objekt-Datenbank zurück, die Du für Dein Test-Git-Repository angelegt hast. Im Moment müsstest Du 11 Objekte haben: 4 Blobs, 3 Trees, 3 Commits und 1 Tag:
 
 	$ find .git/objects -type f
 	.git/objects/01/55eb4229851634a0f03eb265b69f5a2d56f341 # tree 2
@@ -594,7 +594,7 @@ Kommen wir noch einmal auf die Objekt Datenbank zurück, die Du für Dein Test G
 
 <!--Git compresses the contents of these files with zlib, and you’re not storing much, so all these files collectively take up only 925 bytes. You’ll add some larger content to the repository to demonstrate an interesting feature of Git. Add the repo.rb file from the Grit library you worked with earlier — this is about a 12K source code file:-->
 
-Git komprimiert die Inhalte dieser Dateien mit zlib und Du hast nicht sonderlich viele davon, sodass die Gesamtgröße der Dateien gerade mal 925 Bytes beträgt. Wir wollen ein anderes interessantes Feature von Git demonstrieren, und dazu müssen wir eine größere Datei hinzufügen, z.B. die `repo.rb` Datei aus dem Grit Repository, das Du schon verwendet hast. Diese Datei ist eine etwa 12K große Quellcode Datei:
+Git komprimiert die Inhalte dieser Dateien mit zlib und Du hast nicht sonderlich viele davon, sodass die Gesamtgröße der Dateien gerade mal 925 Bytes beträgt. Wir wollen ein anderes interessantes Feature von Git demonstrieren, und dazu müssen wir eine größere Datei hinzufügen, z.B. die `repo.rb` Datei aus der Grit-Bibliothek, die Du schon verwendet hast. Diese Datei ist eine etwa 12K große Quelltext-Datei:
 
 	$ curl https://raw.github.com/mojombo/grit/master/lib/grit/repo.rb > repo.rb
 	$ git add repo.rb
@@ -607,7 +607,7 @@ Git komprimiert die Inhalte dieser Dateien mit zlib und Du hast nicht sonderlich
 
 <!--If you look at the resulting tree, you can see the SHA-1 value your repo.rb file got for the blob object:-->
 
-Wenn Du Dir den resultierenden Tree anschaust, findest Du den SHA-1 Hash, den die Datei `repo.rb` für das Blob Objekt erhalten hat:
+Wenn Du Dir den resultierenden Tree anschaust, findest Du den SHA-1-Hash, den die Datei `repo.rb` für das Blob-Objekt erhalten hat:
 
 	$ git cat-file -p master^{tree}
 	100644 blob fa49b077972391ad58037050f2a75f74e3671e92      new.txt
@@ -623,7 +623,7 @@ Jetzt kannst Du mit `git cat-file` sehen, wie groß das Objekt ist:
 
 <!--Now, modify that file a little, and see what happens:-->
 
-Als nächste ändern wir die Datei ein bisschen, um zu sehen, was passiert:
+Als Nächstes ändern wir die Datei ein bisschen, um zu sehen, was passiert:
 
 	$ echo '# testing' >> repo.rb
 	$ git commit -am 'modified repo a bit'
@@ -652,7 +652,7 @@ Du hast jetzt zwei fast identische 12K große Objekte auf Deiner Festplatte. Wä
 
 <!--It turns out that it can. The initial format in which Git saves objects on disk is called a loose object format. However, occasionally Git packs up several of these objects into a single binary file called a packfile in order to save space and be more efficient. Git does this if you have too many loose objects around, if you run the `git gc` command manually, or if you push to a remote server. To see what happens, you can manually ask Git to pack up the objects by calling the `git gc` command:-->
 
-Tatsächlich kann Git das. Das ursprüngliche Format, in dem Git Objekte in der Datenbank speichert wird als „freies Objekt Format“ („loose object format“) bezeichnet. Hin und wieder packt Git allerdings eine Reihe solcher Objekte in eine einzige binäre Datei zusammen, um Platz zu sparen und effizienter zu arbeiten. Eine solche Datei wird als „packfile“ bezeichnet. Git tut das immer dann, wenn zu viele freie Objekte vorhanden sind, wenn Du den Befehl `git gc` manuell ausführst oder wenn Du auf einen externen Server pushst. Schauen wir uns also an, was passiert, wenn wir manuell `git gc` ausführen:
+Tatsächlich kann Git das. Das ursprüngliche Format, in dem Git Objekte in der Datenbank speichert, wird als „freies Objekt-Format“ („loose object format“) bezeichnet. Hin und wieder packt Git allerdings eine Reihe solcher Objekte in eine einzige binäre Datei zusammen, um Platz zu sparen und effizienter zu arbeiten. Eine solche Datei wird als „packfile“ bezeichnet. Git tut das immer dann, wenn zu viele freie Objekte vorhanden sind, wenn Du den Befehl `git gc` manuell ausführst oder wenn Du auf einen externen Server pushst. Schauen wir uns also an, was passiert, wenn wir manuell `git gc` ausführen:
 
 	$ git gc
 	Counting objects: 17, done.
@@ -663,7 +663,7 @@ Tatsächlich kann Git das. Das ursprüngliche Format, in dem Git Objekte in der
 
 <!--If you look in your objects directory, you’ll find that most of your objects are gone, and a new pair of files has appeared:-->
 
-Wenn Du das Objekt Verzeichnis anschaust, siehst Du, dass die meisten Objekte jetzt fehlen und dass stattdessen zwei neue Objekte aufgetaucht sind:
+Wenn Du das Objekt-Verzeichnis anschaust, siehst Du, dass die meisten Objekte jetzt fehlen und dass stattdessen zwei neue Objekte aufgetaucht sind:
 
 	$ find .git/objects -type f
 	.git/objects/71/08f7ecb345ee9d0084193f147cdad4d2998293
@@ -674,7 +674,7 @@ Wenn Du das Objekt Verzeichnis anschaust, siehst Du, dass die meisten Objekte je
 
 <!--The objects that remain are the blobs that aren’t pointed to by any commit — in this case, the "what is up, doc?" example and the "test content" example blobs you created earlier. Because you never added them to any commits, they’re considered dangling and aren’t packed up in your new packfile.-->
 
-Die verbleibenden Objekte sind diejenigen Blobs, die nicht von irgendeinem Commit referenziert werden – in diesem Fall sind das die „what is up, doc?“ und „test content“ Beispielblobs, die wir zuvor gespeichert hatten: weil wir sie nie zu irgendeinem Commit hinzugefügt haben, werden sie als „dangling“ (xxx) betrachtet und nicht im Packfile zusammengepackt.
+Die verbleibenden Objekte sind diejenigen Blobs, die nicht von irgendeinem Commit referenziert werden – in diesem Fall sind das die Beispielblobs „what is up, doc?“ und „test content“, die wir zuvor gespeichert hatten: weil wir sie nie zu irgendeinem Commit hinzugefügt haben, werden sie als „dangling“ (wörtlich: herumbaumelnd) betrachtet und nicht im Packfile zusammengepackt.
 
 <!--The other files are your new packfile and an index. The packfile is a single file containing the contents of all the objects that were removed from your filesystem. The index is a file that contains offsets into that packfile so you can quickly seek to a specific object. What is cool is that although the objects on disk before you ran the `gc` were collectively about 8K in size, the new packfile is only 4K. You’ve halved your disk usage by packing your objects.-->
 
@@ -709,7 +709,7 @@ Wie stellt Git das genau an? Wenn Git Objekte zusammen packt, sucht es nach Date
 
 <!--Here, the `9bc1d` blob, which if you remember was the first version of your repo.rb file, is referencing the `05408` blob, which was the second version of the file. The third column in the output is the size of the object’s content, so you can see that the content of `05408` takes up 12K, but that of `9bc1d` only takes up 7 bytes. What is also interesting is that the second version of the file is the one that is stored intact, whereas the original version is stored as a delta — this is because you’re most likely to need faster access to the most recent version of the file.-->
 
-Du erinnerst dich, dass der `9bc1d` Blob die erste Version der `repo.rb` Datei ist. Dieser Blob referenziert jetzt den `05408` Blob, der die zweite Version der Datei ist. Die dritte Spalte der Ausgabe ist die Größe des Objektes im Packfile. Wir können also sehen, dass `05408` 12K in Anspruch nimmt, `9bc1d` aber nur 7 Bytes. Das bedeutet also, dass die zweite Version diejenige ist, die vollständig, während die ursprüngliche, erste Version als Delta gespeichert wird! Der Grund dafür ist, dass Du höchstwahrscheinlich einen schnelleren Zugriff auf die jeweils neuesten Dateien brauchst.
+Du erinnerst dich, dass der Blob `9bc1d` die erste Version der `repo.rb`-Datei ist. Dieser Blob referenziert jetzt den  Blob`05408`, der die zweite Version der Datei ist. Die dritte Spalte der Ausgabe ist die Größe des Objektes im Packfile. Wir können also sehen, dass `05408` 12K in Anspruch nimmt, `9bc1d` aber nur 7 Bytes. Das bedeutet also, dass die zweite Version diejenige ist, die vollständig, während die ursprüngliche, erste Version als Delta gespeichert wird! Der Grund dafür ist, dass Du höchstwahrscheinlich einen schnelleren Zugriff auf die jeweils neuesten Dateien brauchst.
 
 <!--The really nice thing about this is that it can be repacked at any time. Git will occasionally repack your database automatically, always trying to save more space. You can also manually repack at any time by running `git gc` by hand.-->
 
@@ -721,13 +721,13 @@ Außerdem ist toll, dass ein Repository jederzeit neu gepackt werden kann. Git m
 <!--Throughout this book, you’ve used simple mappings from remote branches to local references; but they can be more complex.-->
 <!--Suppose you add a remote like this:-->
 
-In diesem Buch haben wir bisher einfache Mappings von externen Branches auf lokale Referenzen verwendet. Sie können aber auch durchaus komplex sein. Nehmen wir an, Du hast ein externes Repository wie folgt definiert:
+In diesem Buch haben wir bisher einfache Zuweisungen von externen Branches auf lokale Referenzen verwendet. Sie können aber auch durchaus komplex sein. Nehmen wir an, Du hast ein externes Repository wie folgt definiert:
 
 	$ git remote add origin git@github.com:schacon/simplegit-progit.git
 
 <!--It adds a section to your `.git/config` file, specifying the name of the remote (`origin`), the URL of the remote repository, and the refspec for fetching:-->
 
-Das fügt eine Sektion in Deine `.git/config` Datei hinzu, die Deinen lokalen Namen des externen Repositories (`origin`), dessen URL und die Refspec spezifiziert, mit der neue Daten heruntergeladen werden.
+Das fügt eine Sektion in Deine `.git/config`-Datei hinzu, die Deinen lokalen Namen des externen Repositorys (`origin`), dessen URL und die Refspec spezifiziert, mit der neue Daten heruntergeladen werden.
 
 	[remote "origin"]
 	       url = git@github.com:schacon/simplegit-progit.git
@@ -735,11 +735,11 @@ Das fügt eine Sektion in Deine `.git/config` Datei hinzu, die Deinen lokalen Na
 
 <!--The format of the refspec is an optional `+`, followed by `<src>:<dst>`, where `<src>` is the pattern for references on the remote side and `<dst>` is where those references will be written locally. The `+` tells Git to update the reference even if it isn’t a fast-forward.-->
 
-Das Format der Refspec besteht aus einem optionalen `+` gefolgt von `<quelle>:<ziel>`, wobei `<quelle>` ein Pattern für Referenzen auf der Remote Seite ist, und `<ziel>` angibt, wohin diese Referenzen lokal geschrieben werden. Das `+` weist Git an, die Referenz zu mergen, wenn sie nicht mit einem fast-forward aktualisiert werden kann.
+Das Format der Refspec besteht aus einem optionalen `+` gefolgt von `<quelle>:<ziel>`, wobei `<quelle>` ein Muster für Referenzen auf der Remote-Seite ist, und `<ziel>` angibt, wohin diese Referenzen lokal geschrieben werden. Das `+` weist Git an, die Referenz zu mergen, wenn sie nicht mit einem Fast-forward aktualisiert werden kann.
 
 <!--In the default case that is automatically written by a `git remote add` command, Git fetches all the references under `refs/heads/` on the server and writes them to `refs/remotes/origin/` locally. So, if there is a `master` branch on the server, you can access the log of that branch locally via-->
 
-Der Standard, der von `git remote add` automatisch eingerichtet wird, besteht darin, dass Git austomatisch alle Referenzen unter `refs/heads/` vom Server holt und sie lokal nach `refs/remotes/origin` speichert. D.h., wenn es auf dem Server einen `master` Branch gibt, kannst Du auf das Log dieses Branches wie folgt zugreifen:
+Der Standard, der von `git remote add` automatisch eingerichtet wird, besteht darin, dass Git automatisch alle Referenzen unter `refs/heads/` vom Server holt und sie lokal nach `refs/remotes/origin` speichert. D.h., wenn es auf dem Server einen `master`-Branch gibt, kannst Du auf das Log dieses Branches wie folgt zugreifen:
 
 	$ git log origin/master
 	$ git log remotes/origin/master
@@ -751,13 +751,13 @@ Diese Varianten sind allesamt äquivalent, weil Git sie jeweils zu `refs/remotes
 
 <!--If you want Git instead to pull down only the `master` branch each time, and not every other branch on the remote server, you can change the fetch line to-->
 
-Wenn Du statt dessen willst, dass Git jeweils nur den `master` Branch herunterlädt und andere Branches auf dem Server ignoriert, kannst Du die `fetch` Zeile wie folgt ändern:
+Wenn Du stattdessen willst, dass Git jeweils nur den `master`-Branch herunterlädt und andere Branches auf dem Server ignoriert, kannst Du die `fetch`-Zeile wie folgt ändern:
 
 	fetch = +refs/heads/master:refs/remotes/origin/master
 
 <!--This is just the default refspec for `git fetch` for that remote. If you want to do something one time, you can specify the refspec on the command line, too. To pull the `master` branch on the remote down to `origin/mymaster` locally, you can run-->
 
-Dies ist allerdings lediglich der Default Refspec Wert und Du kannst ihn auf der Kommandozeile jederzeit überschreiben. Z.B. um nur `master` branch vom Server lokal als `origin/mymaster` zu speichern, kannst Du folgendes ausführen:
+Dies ist allerdings lediglich der Standardwert der Refspec und Du kannst ihn auf der Kommandozeile jederzeit überschreiben. Um zum Beispiel nur den `master`-branch vom Server lokal als `origin/mymaster` zu speichern, kannst Du Folgendes ausführen:
 
 	$ git fetch origin master:refs/remotes/origin/mymaster
 
@@ -771,13 +771,13 @@ Du kannst auch mehrere Refspecs gleichzeitig spezifizieren. Z.B.:
 	 ! [rejected]        master     -> origin/mymaster  (non fast forward)
 	 * [new branch]      topic      -> origin/topic
 
-<!--In this case, the  master branch pull was rejected because it wasn’t a fast-forward reference. You can override that by specifying the `+` in front of the refspec.-->
+<!--In this case, the master branch pull was rejected because it wasn’t a fast-forward reference. You can override that by specifying the `+` in front of the refspec.-->
 
-I diesem Fall wurde ein Pull zurückgewiesen (xxx ist das nicht nur ein fetch? xxx), weil der Branch nicht mit einem simplen fast-forward aktualisiert werden konnte. Du kannst einen Merge erzwingen, indem Du der Refspec ein `+` voranstellst.
+In diesem Fall wurde ein Pull zurückgewiesen, weil der Branch nicht mit einem simplen Fast-forward aktualisiert werden konnte. Du kannst einen Merge erzwingen, indem Du der Refspec ein `+` voranstellst.
 
 <!--You can also specify multiple refspecs for fetching in your configuration file. If you want to always fetch the master and experiment branches, add two lines:-->
 
-Du kannst außerdem natürlich auch mehrere Refspecs in Deiner Konfiguration spezifizieren. Wenn Du z.B. immer die `master` und `experiment` Branches holen willst, fügst Du die folgenden Zeilen hinzu:
+Du kannst außerdem natürlich auch mehrere Refspecs in Deiner Konfiguration spezifizieren. Wenn Du z.B. immer die Branches `master` und `experiment` holen willst, fügst Du die folgenden Zeilen hinzu:
 
 	[remote "origin"]
 	       url = git@github.com:schacon/simplegit-progit.git
@@ -786,13 +786,13 @@ Du kannst außerdem natürlich auch mehrere Refspecs in Deiner Konfiguration spe
 
 <!--You can’t use partial globs in the pattern, so this would be invalid:-->
 
-Du kannst keine partiellen Glob Patterns verwenden, d.h. folgendes wäre ungültig:
+Du kannst keine partiellen Glob-Muster verwenden, d.h. Folgendes wäre ungültig:
 
 	fetch = +refs/heads/qa*:refs/remotes/origin/qa*
 
 <!--However, you can use namespacing to accomplish something like that. If you have a QA team that pushes a series of branches, and you want to get the master branch and any of the QA team’s branches but nothing else, you can use a config section like this:-->
 
-Allerdings kannst Du Namensräume verwenden, um etwas ähnliches zu erreichen. Nehmen wir an, Du hast ein QA Team, das regelmäßig verschiedene Branches pusht, und Du willst nun den master Branch und sämtliche Branches des QA Teams, aber keine anderen Branches haben. Dann kannst Du eine Config Sektion wie die folgende verwenden:
+Allerdings kannst Du Namensräume verwenden, um etwas Ähnliches zu erreichen. Nehmen wir an, Du hast ein QA-Team, das regelmäßig verschiedene Branches pusht, und Du willst nun den master-Branch und sämtliche Branches des QA-Teams, aber keine anderen Branches haben. Dann kannst Du eine Config-Sektion wie die folgende verwenden:
 
 	[remote "origin"]
 	       url = git@github.com:schacon/simplegit-progit.git
@@ -801,24 +801,24 @@ Allerdings kannst Du Namensräume verwenden, um etwas ähnliches zu erreichen. N
 
 <!--If you have a complex workflow process that has a QA team pushing branches, developers pushing branches, and integration teams pushing and collaborating on remote branches, you can namespace them easily this way.-->
 
-In einem großen Team mit einem komplexen Workflow, in dem ein QA Team, Entwickler und ein Integrations Team jeweils eigene Branches pushen, kann man auf diese Weise Branches einfach in Namensräume einteilen.
+In einem großen Team mit einem komplexen Workflow, in dem ein QA-Team, Entwickler und ein Integrations-Team jeweils eigene Branches pushen, kann man auf diese Weise Branches einfach in Namensräume einteilen.
 
 <!--### Pushing Refspecs ###-->
 ### Refspecs pushen ###
 
 <!--It’s nice that you can fetch namespaced references that way, but how does the QA team get their branches into a `qa/` namespace in the first place? You accomplish that by using refspecs to push.-->
 
-Wie aber legt das QA Team die Branches im `qa/` Namensraum ab? Das geht, indem man mit einer Refspec pusht.
+Wie aber legt das QA-Team die Branches im `qa/` Namensraum ab? Das geht, indem man mit einer Refspec pusht.
 
 <!--If the QA team wants to push their `master` branch to `qa/master` on the remote server, they can run-->
 
-Wenn das QA Team seinen `master` Branch in einem externen Repository als `qa/master` speichern will, kann es das wie folgt tun:
+Wenn das QA-Team seinen `master` Branch in einem externen Repository als `qa/master` speichern will, kann es das wie folgt tun:
 
 	$ git push origin master:refs/heads/qa/master
 
 <!--If they want Git to do that automatically each time they run `git push origin`, they can add a `push` value to their config file:-->
 
-Um Git so zu konfigurieren, dass diese Refspec jedes mal automatisch für `git push origin` verwendet wird, kann man den `push` Wert in der Config Datei setzen:
+Um Git so zu konfigurieren, dass diese Refspec jedes Mal automatisch für `git push origin` verwendet wird, kann man den `push` Wert in der Config-Datei setzen:
 
 	[remote "origin"]
 	       url = git@github.com:schacon/simplegit-progit.git
@@ -840,52 +840,52 @@ Man kann Refspecs außerdem verwenden, um Referenzen aus einem externen Reposito
 
 <!--Because the refspec is `<src>:<dst>`, by leaving off the `<src>` part, this basically says to make the topic branch on the remote nothing, which deletes it.-->
 
-Das Refspec Format ist `<quelle>:<ziel>`. Wenn man den `<ziel>` Teil weglässt, dann heißt das im obigen Beispiel, dass man den `topic` Branch auf dem `origin` Server auf „nichts“ setzt, d.h. also löscht.
+Das Refspec Format ist `<quelle>:<ziel>`. Wenn man den Teil `<ziel>` weglässt, dann heißt das im obigen Beispiel, dass man den `topic` Branch auf dem `origin` Server auf „nichts“ setzt, d.h. also löscht.
 
 <!--## Transfer Protocols ##-->
-## Transfer Protokolle ##
+## Transfer-Protokolle ##
 
 <!--Git can transfer data between two repositories in two major ways: over HTTP and via the so-called smart protocols used in the `file://`, `ssh://`, and `git://` transports. This section will quickly cover how these two main protocols operate.-->
 
-Git kann Daten zwischen zwei Repositories im wesentlichen auf zwei Arten transportieren: über HTTP und über sogenannte smarte Protokolle, die mit `file://`, `ssh://` und `git://` verwendet werden. Die folgende Sektion gibt einen kurzen Überblick über diese Protokolle und wie sie funktionieren.
+Git kann Daten zwischen zwei Repositorys im Wesentlichen auf zwei Arten transportieren: über HTTP und über sogenannte smarte Protokolle, die mit `file://`, `ssh://` und `git://` verwendet werden. Die folgende Sektion gibt einen kurzen Überblick über diese Protokolle und wie sie funktionieren.
 
 <!--### The Dumb Protocol ###-->
 ### Das dumme Protokoll ###
 
 <!--Git transport over HTTP is often referred to as the dumb protocol because it requires no Git-specific code on the server side during the transport process. The fetch process is a series of GET requests, where the client can assume the layout of the Git repository on the server. Let’s follow the `http-fetch` process for the simplegit library:-->
 
-Gits HTTP Transfer Protokoll wird oft auch als „dummes“ Protokoll bezeichnet, weil es auf der Server Seite keinen Git-spezifischen Code benötigt. Der `fetch` Prozess besteht aus einer Reihe von GET Requests, für die der Client Vorannahmen über das Layout des Git Repositories auf dem Server machen kann. Schauen wir uns den `http-fetch` Prozess der `simplegit` Bibliothek an:
+Das HTTP-Transfer-Protokoll von Git wird oft auch als „dummes“ Protokoll bezeichnet, weil es auf der Server-Seite keinen Git-spezifischen Code benötigt. Der `fetch`-Prozess besteht aus einer Reihe von GET-Requests, für die der Client Vorannahmen über das Layout des Git-Repositorys auf dem Server machen kann. Schauen wir uns den `http-fetch`-Prozess der `simplegit`-Bibliothek an:
 
 	$ git clone http://github.com/schacon/simplegit-progit.git
 
 <!--The first thing this command does is pull down the `info/refs` file. This file is written by the `update-server-info` command, which is why you need to enable that as a `post-receive` hook in order for the HTTP transport to work properly:-->
 
-Der Befehl lädt zunächst die `info/refs` Datei herunter. Diese Datei wird vom `update-server-info` Befehl geschrieben, den man als einen `post-receive` Hook einrichten muss, damit das HTTP Protokoll richtig funktionieren kann.
+Der Befehl lädt zunächst die `info/refs` Datei herunter. Diese Datei wird vom Befehl `update-server-info` geschrieben, den man als einen `post-receive`-Hook einrichten muss, damit das HTTP-Protokoll richtig funktionieren kann.
 
 	=> GET info/refs
 	ca82a6dff817ec66f44342007202690a93763949     refs/heads/master
 
 <!--Now you have a list of the remote references and SHAs. Next, you look for what the HEAD reference is so you know what to check out when you’re finished:-->
 
-Jetzt hat man eine Liste aller Referenzen und SHAs in diesem Repository. Als nächstes schaut man die HEAD Referenz nach, um zu wissen, was ausgecheckt werden muss:
+Jetzt hat man eine Liste aller Referenzen und SHAs in diesem Repository. Als nächstes schaut man die HEAD-Referenz nach, um zu wissen, was ausgecheckt werden muss:
 
 	=> GET HEAD
 	ref: refs/heads/master
 
 <!--You need to check out the `master` branch when you’ve completed the process.-->
 
-D.h., wenn wir mit dem Prozess fertig sind, wir müssen den `master` Branch auschecken.
+D.h., wenn wir mit dem Prozess fertig sind, wir müssen den `master`-Branch auschecken.
 
 <!--At this point, you’re ready to start the walking process. Because your starting point is the `ca82a6` commit object you saw in the `info/refs` file, you start by fetching that:-->
 
-Wir können jetzt loslegen. Weil wir in der `info/refs` Datei der Commit `ca82a6` angegeben ist, fangen wir damit an, dieses Objekt herunter zu laden:
+Wir können jetzt loslegen. Weil wir in der `info/refs` Datei der Commit `ca82a6` angegeben ist, fangen wir damit an, dieses Objekt herunterzuladen:
 
 	=> GET objects/ca/82a6dff817ec66f44342007202690a93763949
 	(179 bytes of binary data)
 
 <!--You get an object back — that object is in loose format on the server, and you fetched it over a static HTTP GET request. You can zlib-uncompress it, strip off the header, and look at the commit content:-->
 
-Wir erhalten also ein Objekt zurück. Dieses Objekt ist im losen Format auf dem Server gespeichert, und wir haben es über einen statischen HTTP GET Request herunter geladen. Jetzt können wir es mit zlib dekomprimieren, den Header entfernen und den Inhalt des Commits durchsehen:
+Wir erhalten also ein Objekt zurück. Dieses Objekt ist im losen Format auf dem Server gespeichert, und wir haben es über einen statischen HTTP-GET-Request herunter geladen. Jetzt können wir es mit zlib dekomprimieren, den Header entfernen und den Inhalt des Commits durchsehen:
 
 	$ git cat-file -p ca82a6dff817ec66f44342007202690a93763949
 	tree cfda3bf379e4f8dba8717dee55aab78aef7f4daf
@@ -897,21 +897,21 @@ Wir erhalten also ein Objekt zurück. Dieses Objekt ist im losen Format auf dem
 
 <!--Next, you have two more objects to retrieve — `cfda3b`, which is the tree of content that the commit we just retrieved points to; and `085bb3`, which is the parent commit:-->
 
-Als nächstes brauchen wir also zwei weitere Objekte: `cfda3b`, welches der Tree der Inhalte dieses Commits ist, und `085bb3`, den Commit Parent:
+Als Nächstes brauchen wir also zwei weitere Objekte: `cfda3b`, welches der Tree der Inhalte dieses Commits ist, und `085bb3`, den Commit-Parent:
 
 	=> GET objects/08/5bb3bcb608e1e8451d4b2432f8ecbe6306e7e7
 	(179 bytes of data)
 
 <!--That gives you your next commit object. Grab the tree object:-->
 
-Das gibt uns das nächste Commit Objekt. Versuchen wir, das Tree Objekt zu holen:
+Das gibt uns das nächste Commit-Objekt. Versuchen wir, das Tree-Objekt zu holen:
 
 	=> GET objects/cf/da3bf379e4f8dba8717dee55aab78aef7f4daf
 	(404 - Not Found)
 
 <!--Oops — it looks like that tree object isn’t in loose format on the server, so you get a 404 response back. There are a couple of reasons for this — the object could be in an alternate repository, or it could be in a packfile in this repository. Git checks for any listed alternates first:-->
 
-Huch. Es sieht so aus als ob der Tree nicht im losen Format auf dem Server gespeichert ist, weshalb wir einen 404 Response („Not found“) erhalten. Dafür kann es verschiedene Gründe geben. Das Objekt könnte in einem anderen, alternativen Repository liegen, oder es könnte sich in einem Packfile befinden. Git sucht deshalb zunächst nach alternativen Repositories:
+Huch. Es sieht so aus, als ob der Tree nicht im losen Format auf dem Server gespeichert ist, weshalb wir einer 404-Antwort („Not found“) erhalten. Dafür kann es verschiedene Gründe geben. Das Objekt könnte in einem anderen, alternativen Repository liegen, oder es könnte sich in einem Packfile befinden. Git sucht deshalb zunächst nach alternativen Repositories:
 
 	=> GET objects/info/http-alternates
 	(empty file)
@@ -921,14 +921,14 @@ Huch. Es sieht so aus als ob der Tree nicht im losen Format auf dem Server gespe
 
 <!--If this comes back with a list of alternate URLs, Git checks for loose files and packfiles there — this is a nice mechanism for projects that are forks of one another to share objects on disk. However, because no alternates are listed in this case, your object must be in a packfile. To see what packfiles are available on this server, you need to get the `objects/info/packs` file, which contains a listing of them (also generated by `update-server-info`):-->
 
-Wenn wir hier eine Liste alternativer URLs erhalten, schaut Git dort nach losen Dateien und Packfiles. Auf diese Weise können Repositories, die Forks von anderen Repositories sind, mit diesen Objekte im Dateisystem teilen. In unserem Fall sind allerdings keine Alternativen vorhanden, weshalb sich das gesuchte Objekt in einem Packfile befinden muss. Um die vorhandenen Packfiles nachzuschlagen, holt Git die `objects/info/packs` Datei, die eine entsprechende Auflistung enthält (und ebenfalls mit `update-server-info` erzeugt wird)
+Wenn wir hier eine Liste alternativer URLs erhalten, schaut Git dort nach losen Dateien und Packfiles. Auf diese Weise können Repositorys, die Forks von anderen Repositorys sind, mit diesen Objekte im Dateisystem teilen. In unserem Fall sind allerdings keine Alternativen vorhanden, weshalb sich das gesuchte Objekt in einem Packfile befinden muss. Um die vorhandenen Packfiles nachzuschlagen, holt Git die `objects/info/packs` Datei, die eine entsprechende Auflistung enthält (und ebenfalls mit `update-server-info` erzeugt wird)
 
 	=> GET objects/info/packs
 	P pack-816a9b2334da9953e530f27bcac22082a9f5b835.pack
 
 <!--There is only one packfile on the server, so your object is obviously in there, but you’ll check the index file to make sure. This is also useful if you have multiple packfiles on the server, so you can see which packfile contains the object you need:-->
 
-Es gibt nur ein einziges Packfile auf dem Server, weshalb sich unser Objekt darin befinden muss. Aber wir prüfen die Index Datei, um sicher zu sein. Gäbe es mehrere Packfiles auf dem Server, könnten wir auf diese Weise herausfinden, welches Packfile das gesuchte Objekt enthält:
+Es gibt nur ein einziges Packfile auf dem Server, weshalb sich unser Objekt darin befinden muss. Aber wir prüfen die Index-Datei, um sicher zu sein. Gäbe es mehrere Packfiles auf dem Server, könnten wir auf diese Weise herausfinden, welches Packfile das gesuchte Objekt enthält:
 
 	=> GET objects/pack/pack-816a9b2334da9953e530f27bcac22082a9f5b835.idx
 	(4k of binary data)
@@ -938,7 +938,7 @@ Es gibt nur ein einziges Packfile auf dem Server, weshalb sich unser Objekt dari
 
 <!--Now that you have the packfile index, you can see if your object is in it — because the index lists the SHAs of the objects contained in the packfile and the offsets to those objects. Your object is there, so go ahead and get the whole packfile:-->
 
-Nachdem wir jetzt den Packfile Index haben, können wir prüfen, ob sich unser Objekt darin befindet: der Index enthält eine Liste der SHA Hashes der Objekte, die sich im Packfile befinden und die jeweiligen Offsets dieser Objekte. Unser Objekt ist vorhanden, also laden wir das Packfile herunter:
+Nachdem wir jetzt den Packfile-Index haben, können wir prüfen, ob sich unser Objekt darin befindet: der Index enthält eine Liste der SHA-Hashes der Objekte, die sich im Packfile befinden und die jeweiligen Offsets dieser Objekte. Unser Objekt ist vorhanden, also laden wir das Packfile herunter:
 
 	=> GET objects/pack/pack-816a9b2334da9953e530f27bcac22082a9f5b835.pack
 	(13k of binary data)
@@ -948,7 +948,7 @@ Nachdem wir jetzt den Packfile Index haben, können wir prüfen, ob sich unser O
 
 <!--You have your tree object, so you continue walking your commits. They’re all also within the packfile you just downloaded, so you don’t have to do any more requests to your server. Git checks out a working copy of the `master` branch that was pointed to by the HEAD reference you downloaded at the beginning.-->
 
-Du hast jetzt das Tree Objekt, also kannst Du jetzt damit fortfahren, über die Commits zu iterieren. Sie sind in unserem Fall allesamt in dem Packfile enthalten, das Du gerade heruntergeladen hast.
+Du hast jetzt das Tree-Objekt, also kannst Du jetzt damit fortfahren, über die Commits zu iterieren. Sie sind in unserem Fall allesamt in dem Packfile enthalten, das Du gerade heruntergeladen hast.
 
 <!--The entire output of this process looks like this:-->
 
@@ -968,22 +968,22 @@ Die Ausgabe des ganzen Vorgangs sieht dann in etwa so aus:
 	walk a11bef06a3f659402fe7563abf99ad00de2209e6
 
 <!--### The Smart Protocol ###-->
-### Das Smart Protokoll (xxx) ###
+### Das schlaue Protokoll ###
 
 <!--The HTTP method is simple but a bit inefficient. Using smart protocols is a more common method of transferring data. These protocols have a process on the remote end that is intelligent about Git — it can read local data and figure out what the client has or needs and generate custom data for it. There are two sets of processes for transferring data: a pair for uploading data and a pair for downloading data.-->
 
-Die HTTP Methode ist simpel, aber sie ist auch ein bisschen ineffizient. Deshalb ist es üblicher, ein smartes Protokoll für den Datentransfer zu verwenden. Diese Protokolle umfassen serverseitige Prozesse, die Wissen über Git besitzen. Sie können lokale Daten lesen und herausfinden, was auf dem Client schon vorhanden ist oder fehlt und darauf zugeschnitten Daten generieren. Es gibt zwei Sets von Prozessen für den Datentransfer: ein Paar für den Upload und ein Paar für den Download von Daten.
+Die HTTP-Methode ist simpel, aber sie ist auch ein bisschen ineffizient. Deshalb ist es üblicher, ein schlaues Protokoll für den Datentransfer zu verwenden. Diese Protokolle umfassen serverseitige Prozesse, die Wissen über Git besitzen. Sie können lokale Daten lesen und herausfinden, was auf dem Client schon vorhanden ist oder fehlt und darauf zugeschnittene Daten generieren. Es gibt zwei Sets von Prozessen für den Datentransfer: ein Paar für den Upload und ein Paar für den Download von Daten.
 
 <!--#### Uploading Data ####-->
 #### Daten hochladen ####
 
 <!--To upload data to a remote process, Git uses the `send-pack` and `receive-pack` processes. The `send-pack` process runs on the client and connects to a `receive-pack` process on the remote side.-->
 
-Um Daten an einen serverseitigen Prozess zu schicken, verwendet Git die `send-pack` und `receive-pack` Prozesse. Der `send-pack` Prozess läuft auf dem Client und verbindet sich mit einem `receive-pack` Prozess auf dem Server.
+Um Daten an einen serverseitigen Prozess zu schicken, verwendet Git die Prozesse `send-pack` und `receive-pack`. Der Prozess `send-pack` läuft auf dem Client und verbindet sich mit einem `receive-pack`-Prozess auf dem Server.
 
 <!--For example, say you run `git push origin master` in your project, and `origin` is defined as a URL that uses the SSH protocol. Git fires up the `send-pack` process, which initiates a connection over SSH to your server. It tries to run a command on the remote server via an SSH call that looks something like this:-->
 
-Nehmen wir z.B. an Du führst `git push origin master` in Deinem Projekt aus und `origin` ist als eine URL mit SSH Protokoll definiert. Git startet dann einen `send-pack` Prozess, der eine SSH Verbindung zum Server initiiert. Dieser versucht, via SSH auf dem Server einen Befehl wie den folgenden auszuführen:
+Nehmen wir z.B. an, Du führst `git push origin master` in Deinem Projekt aus und `origin` ist als eine URL mit SSH-Protokoll definiert. Git startet dann einen `send-pack`-Prozess, der eine SSH-Verbindung zum Server initiiert. Dieser versucht, via SSH auf dem Server einen Befehl wie den folgenden auszuführen:
 
 	$ ssh -x git@github.com "git-receive-pack 'schacon/simplegit-progit.git'"
 	005bca82a6dff817ec66f4437202690a93763949 refs/heads/master report-status delete-refs
@@ -992,15 +992,15 @@ Nehmen wir z.B. an Du führst `git push origin master` in Deinem Projekt aus und
 
 <!--The `git-receive-pack` command immediately responds with one line for each reference it currently has — in this case, just the `master` branch and its SHA. The first line also has a list of the server’s capabilities (here, `report-status` and `delete-refs`).-->
 
-Der `git-receive-pack` Befehl antwortet dann mit jeweils einer Zeile pro Referenz, die er kennt – in diesem Fall sind das lediglich der `master` Branch und dessen SHA. Die erste Zeile listet außerdem Features, die der Server beherrscht (in unserem Fall `report-status` und `delete-refs`).
+Der `git-receive-pack`-Befehl antwortet dann mit jeweils einer Zeile pro Referenz, die er kennt – in diesem Fall sind das lediglich der `master`-Branch und dessen SHA. Die erste Zeile listet außerdem Features, die der Server beherrscht (in unserem Fall `report-status` und `delete-refs`).
 
 <!--Each line starts with a 4-byte hex value specifying how long the rest of the line is. Your first line starts with 005b, which is 91 in hex, meaning that 91 bytes remain on that line. The next line starts with 003e, which is 62, so you read the remaining 62 bytes. The next line is 0000, meaning the server is done with its references listing.-->
 
-Jede Zeile beginnt mit einem 4 Byte Hexadezimalzahl Wert, der angibt, wie lang der Rest der Zeile ist. Die erste Zeile beginnt mit 005b, d.h. dezimal 91. ALso ist der Rest der Zeile 91 Zeichen lang. Die nächste Zeile fängt mit 003e an, also dezimal 62. Die letzte Zeile ist 0000, was das Ende der Liste anzeigt.
+Jede Zeile beginnt mit einem 4 Byte Hexadezimalzahl-Wert, der angibt, wie lang der Rest der Zeile ist. Die erste Zeile beginnt mit 005b, d.h. dezimal 91. ALso ist der Rest der Zeile 91 Zeichen lang. Die nächste Zeile fängt mit 003e an, also dezimal 62. Die letzte Zeile ist 0000, was das Ende der Liste anzeigt.
 
 <!--Now that it knows the server’s state, your `send-pack` process determines what commits it has that the server doesn’t. For each reference that this push will update, the `send-pack` process tells the `receive-pack` process that information. For instance, if you’re updating the `master` branch and adding an `experiment` branch, the `send-pack` response may look something like this:-->
 
-Nachdem Dein `send-pack` Prozess jetzt den Zustand des Servers kennt, kann er als nächstes evaluieren, welche Commits lokal, aber nicht auf dem Server vorhanden sind. der `send-pack` Prozess schickt diese Information für jede Referenz, auf die sich der `push` Befehl bezieht, an den `receive-pack` Prozess. Wenn Du beispielsweise den `master` Branch aktualisierst und einen `experiment` Branch hinzufügst, dann könnte die Antwort auf `send-pack` so aussehen:
+Nachdem Dein `send-pack`-Prozess jetzt den Zustand des Servers kennt, kann er als nächstes evaluieren, welche Commits lokal, aber nicht auf dem Server vorhanden sind. der `send-pack`-Prozess schickt diese Information für jede Referenz, auf die sich der `push`-Befehl bezieht, an den `receive-pack` Prozess. Wenn Du beispielsweise den `master`-Branch aktualisierst und einen `experiment`-Branch hinzufügst, dann könnte die Antwort auf `send-pack` so aussehen:
 
 	0085ca82a6dff817ec66f44342007202690a93763949  15027957951b64cf874c3557a0f3547bd83b3ff6 refs/heads/master report-status
 	00670000000000000000000000000000000000000000 cdfdb42577e2506715f8cfeacdbabc092bf63e8d refs/heads/experiment
@@ -1008,40 +1008,40 @@ Nachdem Dein `send-pack` Prozess jetzt den Zustand des Servers kennt, kann er al
 
 <!--The SHA-1 value of all '0's means that nothing was there before — because you’re adding the experiment reference. If you were deleting a reference, you would see the opposite: all '0's on the right side.-->
 
-Der SHA-1 Wert, der nur aus Nullen besteht, heißt, dass dort zuvor nichts war: Du fügst die `experiment` Referenz ja neu hinzu. Würdest Du eine Referenz löschen, würdest Du das Gegenteil sehen: nur Nullen auf der rechten Seite (xxx hu? wo ist die rechte seite? xxx)
+Der SHA-1-Wert, der nur aus Nullen besteht, heißt, dass dort zuvor nichts war: Du fügst die `experiment`-Referenz ja neu hinzu. Würdest Du eine Referenz löschen, würdest Du das Gegenteil sehen: nur Nullen auf der rechten Seite.
 
 <!--Git sends a line for each reference you’re updating with the old SHA, the new SHA, and the reference that is being updated. The first line also has the client’s capabilities. Next, the client uploads a packfile of all the objects the server doesn’t have yet. Finally, the server responds with a success (or failure) indication:-->
 
-Pro Referenz, die Du aktualisierst, schickt Git eine Zeile mit dem alten SHA, dem neuen SHA und der jeweiligen Referenz, die aktualisiert wird. Die erste Zeile listet zudem die Server Features. Als nächstes lädt der Client ein Packfile aller Objekte hoch, die der Server noch nicht kennt. Abschließend antwortet der Server mit einer Erfolgs- oder Fehlermeldung:
+Pro Referenz, die Du aktualisierst, schickt Git eine Zeile mit dem alten SHA, dem neuen SHA und der jeweiligen Referenz, die aktualisiert wird. Die erste Zeile listet zudem die Server-Features auf. Als nächstes lädt der Client ein Packfile aller Objekte hoch, die der Server noch nicht kennt. Abschließend antwortet der Server mit einer Erfolgs- oder Fehlermeldung:
 
 	000Aunpack ok
 
 <!--#### Downloading Data ####-->
-#### Downloading Data ####
+#### Daten herunterladen ####
 
 <!--When you download data, the `fetch-pack` and `upload-pack` processes are involved. The client initiates a `fetch-pack` process that connects to an `upload-pack` process on the remote side to negotiate what data will be transferred down.-->
 
-Wenn Du Daten herunterlädst, sind daran die `fetch-pack` und `upload-pack` Prozesse beteiligt. Der Client startet einen `fetch-pack` Prozess, der sich mit einem `upload-pack` Prozess auf dem Server verbindet, um auszuhandeln, welche Daten heruntergeladen werden sollen.
+Wenn Du Daten herunterlädst, sind daran die Prozesse `fetch-pack` und `upload-pack` beteiligt. Der Client startet einen `fetch-pack`-Prozess, der sich mit einem `upload-pack`-Prozess auf dem Server verbindet, um auszuhandeln, welche Daten heruntergeladen werden sollen.
 
 <!--There are different ways to initiate the `upload-pack` process on the remote repository. You can run via SSH in the same manner as the `receive-pack` process. You can also initiate the process via the Git daemon, which listens on a server on port 9418 by default. The `fetch-pack` process sends data that looks like this to the daemon after connecting:-->
 
-Es gibt verschiedene Möglichkeiten, den `upload-pack` Prozess auf dem Server zu starten: einerseits via SSH auf die gleiche Weise wie den `receive-pack` Prozess. Und adnererseits über den Git Daemon, der standardmäßig auf dem Server auf dem Port 9418 läuft. Der `fetch-pack` Prozess schickt etwa folgendes an den Daemon:
+Es gibt verschiedene Möglichkeiten, den `upload-pack`-Prozess auf dem Server zu starten: einerseits via SSH auf die gleiche Weise wie den `receive-pack`-Prozess. Und adnererseits über den Git-Daemon, der standardmäßig auf dem Server auf dem Port 9418 läuft. Der `fetch-pack`-Prozess schickt etwa Folgendes an den Daemon:
 
 	003fgit-upload-pack schacon/simplegit-progit.git\0host=myserver.com\0
 
 <!--It starts with the 4 bytes specifying how much data is following, then the command to run followed by a null byte, and then the server’s hostname followed by a final null byte. The Git daemon checks that the command can be run and that the repository exists and has public permissions. If everything is cool, it fires up the `upload-pack` process and hands off the request to it.-->
 
-Diese Zeile beginnt wiederum mit 4 Bytes, die angeben, wieviel Daten folgen. Dann kommt der auszuführende Befehl und ein Null Byte, und schließlich der Hostname des Servers und ein weiteres Null Byte. Der Git Daemon prüft, ob der Befehl ausgeführt werden kann, das Repository existiert und Schreibzugriff erlaubt. Wenn alles stimmt, startet er den `upload-pack` Prozess und gibt den Request dorthin weiter.
+Diese Zeile beginnt wiederum mit 4 Bytes, die angeben, wieviel Daten folgen. Dann kommt der auszuführende Befehl und ein Null-Byte, und schließlich der Hostname des Servers und ein weiteres Null-Byte. Der Git-Daemon prüft, ob der Befehl ausgeführt werden kann, das Repository existiert und Schreibzugriff erlaubt. Wenn alles stimmt, startet er den `upload-pack`-Prozess und gibt den Request dorthin weiter.
 
 <!--If you’re doing the fetch over SSH, `fetch-pack` instead runs something like this:-->
 
-Wenn Du den `fetch` Befehl über SSH verwendest, führt `fetch-pack` statt dessen etwas aus wie:
+Wenn Du den `fetch`-Befehl über SSH verwendest, führt `fetch-pack` stattdessen etwas aus wie:
 
 	$ ssh -x git@github.com "git-upload-pack 'schacon/simplegit-progit.git'"
 
 <!--In either case, after `fetch-pack` connects, `upload-pack` sends back something like this:-->
 
-In beiden Fällen wird, nachdem `fetch-pack` verbunden ist, `upload-pack` eine Antwort wie die folgende zurück schicken:
+In beiden Fällen wird, nachdem `fetch-pack` verbunden ist, `upload-pack` eine Antwort wie die folgende zurückschicken:
 
 	0088ca82a6dff817ec66f44342007202690a93763949 HEAD\0multi_ack thin-pack \
 	  side-band side-band-64k ofs-delta shallow no-progress include-tag
@@ -1051,11 +1051,11 @@ In beiden Fällen wird, nachdem `fetch-pack` verbunden ist, `upload-pack` eine A
 
 <!--This is very similar to what `receive-pack` responds with, but the capabilities are different. In addition, it sends back the HEAD reference so the client knows what to check out if this is a clone.-->
 
-Die Antwort ähnelt der, mit der `receive-pack` antwortet, aber die aufgelisteten Features sind andere. Zusätzlich wird die HEAD Referenz mitgeschickt, sodass der Client weiß, was er auschecken muss, falls es sich um einen Clone handelt.
+Die Antwort ähnelt der, mit der `receive-pack` antwortet, aber die aufgelisteten Features sind andere. Zusätzlich wird die HEAD-Referenz mitgeschickt, sodass der Client weiß, was er auschecken muss, falls es sich um einen Clone handelt.
 
 <!--At this point, the `fetch-pack` process looks at what objects it has and responds with the objects that it needs by sending "want" and then the SHA it wants. It sends all the objects it already has with "have" and then the SHA. At the end of this list, it writes "done" to initiate the `upload-pack` process to begin sending the packfile of the data it needs:-->
 
-Der `fetch-pack` Prozess inspiziert jetzt die vorhandenen Objekte und antwortet mit einer Liste von Objekten, wobei er das Schlüsselwort „want“ für Objekte verwendet, die benötigt werden, und „have“ für Objekte, die bereits vorhanden sind. Am Ende der Liste folgt das Schlüsselwort „done“. Der `upload-pack` Prozess schickt dann ein Packfile mit allen benötigten Objekten:
+Der `fetch-pack`-Prozess inspiziert jetzt die vorhandenen Objekte und antwortet mit einer Liste von Objekten, wobei er das Schlüsselwort „want“ für Objekte verwendet, die benötigt werden, und „have“ für Objekte, die bereits vorhanden sind. Am Ende der Liste folgt das Schlüsselwort „done“. Der `upload-pack`-Prozess schickt dann ein Packfile mit allen benötigten Objekten:
 
 	0054want ca82a6dff817ec66f44342007202690a93763949 ofs-delta
 	0032have 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7
@@ -1064,14 +1064,14 @@ Der `fetch-pack` Prozess inspiziert jetzt die vorhandenen Objekte und antwortet
 
 <!--That is a very basic case of the transfer protocols. In more complex cases, the client supports `multi_ack` or `side-band` capabilities; but this example shows you the basic back and forth used by the smart protocol processes.-->
 
-Das ist ein sehr einfaches Beispiel. In komplexeren Fällen unterstützt der Client die `multi_ack` oder `side-band` Features. Aber obiges Beispiel verdeutlicht den grundlegenden Request-Response Zyklus der Smart Protokoll Prozesse.
+Das ist ein sehr einfaches Beispiel. In komplexeren Fällen unterstützt der Client die Features `multi_ack` oder `side-band`. Aber obiges Beispiel verdeutlicht den grundlegenden Request-Response Zyklus der Prozesse bei schlauen Protokollen.
 
 <!--## Maintenance and Data Recovery ##-->
 ## Wartung und Datenwiederherstellung ##
 
 <!--Occasionally, you may have to do some cleanup — make a repository more compact, clean up an imported repository, or recover lost work. This section will cover some of these scenarios.-->
 
-Gelegentlich will man ein bisschen aufräumen – ein Repository verdichten, ein importiertes Repository entfernen (xxx) oder verloren gegangene Daten wieder herstellen. Dieses Kapitel wird sich mit einigen derartigen Szenarien befassen.
+Gelegentlich will man ein bisschen aufräumen – ein Repository verdichten, ein importiertes Repository aufräumen oder verloren gegangene Daten wieder herstellen. Dieses Kapitel wird sich mit einigen derartigen Szenarien befassen.
 
 <!--### Maintenance ###-->
 ### Wartung ###
@@ -1088,7 +1088,7 @@ Du kannst `auto gc` wie folgt manuell ausführen:
 
 <!--Again, this generally does nothing. You must have around 7,000 loose objects or more than 50 packfiles for Git to fire up a real gc command. You can modify these limits with the `gc.auto` and `gc.autopacklimit` config settings, respectively.-->
 
-Wie schon erwähnt tut dies normalerweise gar nichts. Es müssen sich etwa 7.000 lose Objekte oder mehr als 50 Packfiles angesammelt haben, bevor Git tatsächlich die Garbage Collection startet. Du kannst diese Werte mit Hilfe der `gc.auto` bzw. `gc.autopacklimit` Konfigurationsvariablen manuell setzen.
+Wie schon erwähnt tut dies normalerweise gar nichts. Es müssen sich etwa 7.000 lose Objekte oder mehr als 50 Packfiles angesammelt haben, bevor Git tatsächlich den echten gc-Befehl startet. Du kannst diese Werte mit Hilfe der Konfigurationsvariablen `gc.auto` bzw. `gc.autopacklimit` manuell setzen.
 
 <!--The other thing `gc` will do is pack up your references into a single file. Suppose your repository contains the following branches and tags:-->
 
@@ -1102,7 +1102,7 @@ Wie schon erwähnt tut dies normalerweise gar nichts. Es müssen sich etwa 7.000
 
 <!--If you run `git gc`, you’ll no longer have these files in the `refs` directory. Git will move them for the sake of efficiency into a file named `.git/packed-refs` that looks like this:-->
 
-Nachdem Du `git gc` ausgeführt hast, werden diese Dateien um der Effizienz willen aus dem `refs` Verzeichnis entfernt und in eine Datei `.git/packed-refs` verschoben, die dann wie folgt aussieht:
+Nachdem Du `git gc` ausgeführt hast, werden diese Dateien um der Effizienz willen aus dem `refs`-Verzeichnis entfernt und in eine Datei `.git/packed-refs` verschoben, die dann wie folgt aussieht:
 
 	$ cat .git/packed-refs
 	# pack-refs with: peeled
@@ -1114,22 +1114,22 @@ Nachdem Du `git gc` ausgeführt hast, werden diese Dateien um der Effizienz will
 
 <!--If you update a reference, Git doesn’t edit this file but instead writes a new file to `refs/heads`. To get the appropriate SHA for a given reference, Git checks for that reference in the `refs` directory and then checks the `packed-refs` file as a fallback. However, if you can’t find a reference in the `refs` directory, it’s probably in your `packed-refs` file.-->
 
-Wenn Du eine Referenz bearbeitest, lässt Git diese Datei unverändert und schreibt statt dessen eine neue Datei nach `refs/heads`. Um einen SHA für eine Referenz nachzuschlagen, schaut Git zunächst im `refs` Verzeichnis und danach erst in der `packed-refs` Datei nach, falls nötig. Wenn eine Referenz also nicht im `refs` Verzeichnis liegt, befindet sie sich wahrscheinlich in `packed-refs` Datei.
+Wenn Du eine Referenz bearbeitest, lässt Git diese Datei unverändert und schreibt stattdessen eine neue Datei nach `refs/heads`. Um einen SHA für eine Referenz nachzuschlagen, schaut Git zunächst im `refs`-Verzeichnis und danach erst in der Datei `packed-refs` nach, falls nötig. Wenn eine Referenz also nicht im `refs`-Verzeichnis liegt, befindet sie sich wahrscheinlich in der Datei `packed-refs`.
 
 <!--Notice the last line of the file, which begins with a `^`. This means the tag directly above is an annotated tag and that line is the commit that the annotated tag points to.-->
 
 Beachte, dass die letzte Zeile der Datei mit `^` anfängt. Das bedeutet, dass der Tag darüber ein annotierter Tag ist und diese Zeile zeigt den Commit, auf den der annotierte Tag zeigt.
 
 <!--### Data Recovery ###-->
-### Daten Wiederherstellung ###
+### Daten-Wiederherstellung ###
 
 <!--At some point in your Git journey, you may accidentally lose a commit. Generally, this happens because you force-delete a branch that had work on it, and it turns out you wanted the branch after all; or you hard-reset a branch, thus abandoning commits that you wanted something from. Assuming this happens, how can you get your commits back?-->
 
-Irgendwann wird es vielleicht mal vorkommen, dass Du während der Arbeit mit Git einen Commit verlierst. Normalerweise passiert das, wenn Du versehentlich einen Branch löschst, an dem Du gearbeitet hattest und den Du noch brauchst. Oder Du führst `git reset --hard` aus und stellst fest, dass Du einige der Commits noch brauchst. Nehmen wir an, Du steckst in einer solchen Situation – wie kannst Du Deine Commits wieder herstellen?
+Irgendwann wird es vielleicht mal vorkommen, dass Du während der Arbeit mit Git einen Commit verlierst. Normalerweise passiert das, wenn Du versehentlich einen Branch löschst, an dem Du gearbeitet hattest und den Du noch brauchst. Oder Du führst `git reset --hard` aus und stellst fest, dass Du einige der Commits noch brauchst. Nehmen wir an, Du steckst in einer solchen Situation – wie kannst Du Deine Commits wiederherstellen?
 
 <!--Here’s an example that hard-resets the master branch in your test repository to an older commit and then recovers the lost commits. First, let’s review where your repository is at this point:-->
 
-Das folgende Beispiel setzt zuerst den `master` Branch auf einen älteren Commit zurück und stellt die verlorenen Commits dann wieder her. Zunächst schauen wir uns den gegenwärtigen Zustand des Repositories an:
+Das folgende Beispiel setzt zuerst den `master`-Branch auf einen älteren Commit zurück und stellt die verlorenen Commits dann wieder her. Zunächst schauen wir uns den gegenwärtigen Zustand des Repositories an:
 
 	$ git log --pretty=oneline
 	ab1afef80fac8e34258ff41fc1b867c702daa24b modified repo a bit
@@ -1140,7 +1140,7 @@ Das folgende Beispiel setzt zuerst den `master` Branch auf einen älteren Commit
 
 <!--Now, move the `master` branch back to the middle commit:-->
 
-Jetzt setzen wir den `master` Branch zurück auf den mittleren Commit.
+Jetzt setzen wir den `master`-Branch zurück auf den mittleren Commit.
 
 	$ git reset --hard 1a410efbd13591db07496601ebc7a059dd55cfe9
 	HEAD is now at 1a410ef third commit
@@ -1151,11 +1151,11 @@ Jetzt setzen wir den `master` Branch zurück auf den mittleren Commit.
 
 <!--You’ve effectively lost the top two commits — you have no branch from which those commits are reachable. You need to find the latest commit SHA and then add a branch that points to it. The trick is finding that latest commit SHA — it’s not like you’ve memorized it, right?-->
 
-Du hast damit die oberen beiden Commits verloren, d.h. es gibt keinen Branch mehr, von dem aus diese Commits erreichbar wären. Um sie wieder herzustellen kannst Du einen neuen Branch anlegen, der auf den SHA Hash des obersten (letzten) Commits zeigt. Der Trick besteht darin, diesen letzten Commit Hash heraus zu finden. Es ist ja nicht so, dass Du Dir jederzeit all die Hashes merken könntest, oder?
+Du hast damit die oberen beiden Commits verloren, d.h. es gibt keinen Branch mehr, von dem aus diese Commits erreichbar wären. Um sie wiederherzustellen, kannst Du einen neuen Branch anlegen, der auf den SHA-Hash des obersten (letzten) Commits zeigt. Der Trick besteht darin, diesen letzten Commit-Hash herauszufinden. Es ist ja nicht so, dass Du Dir jederzeit all die Hashes merken könntest, oder?
 
 <!--Often, the quickest way is to use a tool called `git reflog`. As you’re working, Git silently records what your HEAD is every time you change it. Each time you commit or change branches, the reflog is updated. The reflog is also updated by the `git update-ref` command, which is another reason to use it instead of just writing the SHA value to your ref files, as we covered in the "Git References" section of this chapter earlier.  You can see where you’ve been at any time by running `git reflog`:-->
 
-In der Regel ist der schnellste Weg, solche Hashes zu finden, der Befehl `git reflog`. Während Du mit Git arbeitest, macht Git im Stillen fortlaufende Notizen darüber, was HEAD ist. Jedes Mal, wenn Du einen Commit anlegst oder den Branch wechselst, wird das „Reflog“ aktualisiert. Das Reflog wird außerdem vom Befehl `git update-ref` verwendet – ein weiterer guter Grund, nicht statt dessen einfach den SHA Wert in eine Referenz Datei zu schreiben (wie wir das in der Sektion „Git Referenzen“ zuvor in diesem Kapitel besprochen haben). Du kannst also jederzeit nachschlagen, woran Du jeweils gearbeitet hast, indem Du den Befehl `git reflog` verwendest:
+In der Regel ist der schnellste Weg, solche Hashes zu finden, der Befehl `git reflog`. Während Du mit Git arbeitest, macht Git im Stillen fortlaufende Notizen darüber, was HEAD ist. Jedes Mal, wenn Du einen Commit anlegst oder den Branch wechselst, wird das „Reflog“ aktualisiert. Das Reflog wird außerdem vom Befehl `git update-ref` verwendet – ein weiterer guter Grund, nicht stattdessen einfach den SHA-Wert in eine Referenz-Datei zu schreiben (wie wir das in der Sektion „Git-Referenzen“ zuvor in diesem Kapitel besprochen haben). Du kannst also jederzeit nachschlagen, woran Du jeweils gearbeitet hast, indem Du den Befehl `git reflog` verwendest:
 
 	$ git reflog
 	1a410ef HEAD@{0}: 1a410efbd13591db07496601ebc7a059dd55cfe9: updating HEAD
@@ -1184,7 +1184,7 @@ Das zeigt also die beiden verloren gegangenen Commits an, die wir zuvor ausgeche
 
 <!--It looks like the bottom commit is the one you lost, so you can recover it by creating a new branch at that commit. For example, you can start a branch named `recover-branch` at that commit (ab1afef):-->
 
-Es sieht also so aus, als sei der untere Commit derjenige, den Du verloren hast, aber noch brauchst. Du kannst ihn jetzt wieder herstellen, indem Du einen neuen Branch erstellst, der auf diesen Commit zeigt. Beispielsweise kannst Du einen Branch `recover-branch` anlegen, der auf den Commit `ab1afef` zeigt:
+Es sieht also so aus, als sei der untere Commit derjenige, den Du verloren hast, aber noch brauchst. Du kannst ihn jetzt wiederherstellen, indem Du einen neuen Branch erstellst, der auf diesen Commit zeigt. Beispielsweise kannst Du einen Branch `recover-branch` anlegen, der auf den Commit `ab1afef` zeigt:
 
 	$ git branch recover-branch ab1afef
 	$ git log --pretty=oneline recover-branch
@@ -1197,14 +1197,14 @@ Es sieht also so aus, als sei der untere Commit derjenige, den Du verloren hast,
 <!--Cool — now you have a branch named `recover-branch` that is where your `master` branch used to be, making the first two commits reachable again.-->
 <!--Next, suppose your loss was for some reason not in the reflog — you can simulate that by removing `recover-branch` and deleting the reflog. Now the first two commits aren’t reachable by anything:-->
 
-Sehr gut. Du hast jetzt einen neuen Branch `recover-branch`, der diejenigen Commits enthält, die sich zuvor in Deinem `master` Branch befanden. Damit hast Du wieder Zugriff auf die beiden verloren gegangenen Commits. Als nächstes nehmen wir aber außerdem an, dass diese verlorenen Commits aus irgendeinem Grunde nicht im Reflog enthalten sind – Du kannst das z.B. simulieren, indem Du den Branch `recover-branch` und das Reflog löschst. Damit sind die beiden Commits jetzt von nirgendwo her mehr erreichbar:
+Sehr gut. Du hast jetzt einen neuen Branch `recover-branch`, der diejenigen Commits enthält, die sich zuvor in Deinem `master`-Branch befanden. Damit hast Du wieder Zugriff auf die beiden verloren gegangenen Commits. Als nächstes nehmen wir aber außerdem an, dass diese verlorenen Commits aus irgendeinem Grunde nicht im Reflog enthalten sind – Du kannst das z.B. simulieren, indem Du den Branch `recover-branch` und das Reflog löschst. Damit sind die beiden Commits jetzt von nirgendwo her mehr erreichbar:
 
 	$ git branch -D recover-branch
 	$ rm -Rf .git/logs/
 
 <!--Because the reflog data is kept in the `.git/logs/` directory, you effectively have no reflog. How can you recover that commit at this point? One way is to use the `git fsck` utility, which checks your database for integrity. If you run it with the `-\-full` option, it shows you all objects that aren’t pointed to by another object:-->
 
-Das Reflog wird im Verzeichnis `.git/logs/` aufbewahrt, d.h. Du hast nun faktisch kein Reflog mehr. Wie kann man einen Commit jetzt noch wieder herstellen? Eine Möglichkeit dazu ist der Befehl `git fsck`, der die Git Datenbank Integrität prüft. Wenn Du den Befehl mit der Option `--full` ausführst, zeigt er alle Objekte an, auf die nicht von einem anderen Objekt verwiesen wird:
+Das Reflog wird im Verzeichnis `.git/logs/` aufbewahrt, d.h. Du hast nun faktisch kein Reflog mehr. Wie kann man einen Commit jetzt noch wiederherstellen? Eine Möglichkeit dazu ist der Befehl `git fsck`, der die Integrität der Git-Datenbank prüft. Wenn Du den Befehl mit der Option `--full` ausführst, zeigt er alle Objekte an, auf die nicht von einem anderen Objekt verwiesen wird:
 
 	$ git fsck --full
 	dangling blob d670460b4b4aece5915caf5c68d12f560a9fe3e4
@@ -1214,26 +1214,26 @@ Das Reflog wird im Verzeichnis `.git/logs/` aufbewahrt, d.h. Du hast nun faktisc
 
 <!--In this case, you can see your missing commit after the dangling commit. You can recover it the same way, by adding a branch that points to that SHA.-->
 
-In diesem Fall findest Du den verlorenen Commit nach dem (xxx dangling xxx) Commit. Du kannst ihn dann auf die selbe Weise wieder herstellen wie zuvor, indem Du einen Branch erstellst, der auf diesen Commit Hash zeigt.
+In diesem Fall findest Du den verlorenen Commit nach den Worten „dangling commit“. Du kannst ihn dann auf dieselbe Weise wiederherstellen wie zuvor, indem Du einen Branch erstellst, der auf diesen Commit-Hash zeigt.
 
 <!--### Removing Objects ###-->
 ### Objekte entfernen ###
 
 <!--There are a lot of great things about Git, but one feature that can cause issues is the fact that a `git clone` downloads the entire history of the project, including every version of every file. This is fine if the whole thing is source code, because Git is highly optimized to compress that data efficiently. However, if someone at any point in the history of your project added a single huge file, every clone for all time will be forced to download that large file, even if it was removed from the project in the very next commit. Because it’s reachable from the history, it will always be there.-->
 
-Git ist in vielerlei Hinsicht unschlagbar, aber es gibt auch Features, die Probleme verursachen können. Ein solches Problem kann darin bestehen, dass `git clone` die vollständige Historie eines Projektes herunter lädt, d.h. jede einzelne Version jeder einzelnen Datei. Das ist eine feine Sache, solange es sich um Quellcode handelt, den Git ist darauf optimiert, diese Art von Daten effizient zu komprimieren. Wenn allerdings irgendwann einmal eine einzelne, sehr große Datei zur Versionskontrolle hinzugefügt wurde, wird jeder Clone dieses Repositories diese Datei gezwungenermaßen herunter laden müssen – auch dann, wenn die Datei inzwischen aus dem Repository entfernt würde. Weil sie über die Historie erreichbar ist, muss die Datei vorhanden sein.
+Git ist in vielerlei Hinsicht unschlagbar, aber es gibt auch Features, die Probleme verursachen können. Ein solches Problem kann darin bestehen, dass `git clone` die vollständige Historie eines Projektes herunterlädt, d.h. jede einzelne Version jeder einzelnen Datei. Das ist eine feine Sache, solange es sich um Quellcode handelt, denn Git ist darauf optimiert, diese Art von Daten effizient zu komprimieren. Wenn allerdings irgendwann einmal eine einzelne, sehr große Datei zur Versionskontrolle hinzugefügt wurde, wird jeder Clone dieses Repositorys diese Datei gezwungenermaßen herunterladen müssen – auch dann, wenn die Datei inzwischen aus dem Repository entfernt würde. Weil sie über die Historie erreichbar ist, muss die Datei vorhanden sein.
 
 <!--This can be a huge problem when you’re converting Subversion or Perforce repositories into Git. Because you don’t download the whole history in those systems, this type of addition carries few consequences. If you did an import from another system or otherwise find that your repository is much larger than it should be, here is how you can find and remove large objects.-->
 
-Hierin kann ein großes Problem bestehen, wenn Du Subversion oder Perforce Repositories nach Git konvertierst. Weil Du in diesen Systemen nicht die gesamte Historie herunter lädst, kann diese Art von (xxx addition??? hu? xxx) einige unangenehme Konsequenzen haben. Wenn Du Dein Repository aus einem anderen System importiert hast oder aus irgendeinem anderen Grunde findest, dass es sehr viel größer ist als es eigentlich sein sollte, kannst Du große Objekte wie folgt suchen und entfernen.
+Hierin kann ein großes Problem bestehen, wenn Du Subversion oder Perforce-Repositorys nach Git konvertierst. Weil Du in diesen Systemen nicht die gesamte Historie herunterlädst, kann diese Art von Hinzufügung einige unangenehme Konsequenzen haben. Wenn Du Dein Repository aus einem anderen System importiert hast oder aus irgendeinem anderen Grunde findest, dass es sehr viel größer ist, als es eigentlich sein sollte, kannst Du große Objekte wie folgt suchen und entfernen.
 
 <!--Be warned: this technique is destructive to your commit history. It rewrites every commit object downstream from the earliest tree you have to modify to remove a large file reference. If you do this immediately after an import, before anyone has started to base work on the commit, you’re fine — otherwise, you have to notify all contributors that they must rebase their work onto your new commits.-->
 
-Sei Dir allerdings bewusst, dass diese Technik die Commit Historie zerstört. Sie schreibt angefangen beim ursprünglichen Tree jedes einzelne Commit Objekt neu, um die jeweilige, große Datei zu entfernen. Wenn Du das direkt nach einem Import tust, d.h. bevor jemand angefangen hat, auf der Basis eines Commits zu arbeiten, ist das in Ordnung – andernfalls müssen alle Mitarbeiter ihre Arbeit auf Deinen Commit rebasen.
+Sei Dir allerdings bewusst, dass diese Technik die Commit-Historie zerstört. Sie schreibt angefangen beim ursprünglichen Tree jedes einzelne Commit-Objekt neu, um die jeweilige, große Datei zu entfernen. Wenn Du das direkt nach einem Import tust, d.h. bevor jemand angefangen hat, auf der Basis eines Commits zu arbeiten, ist das in Ordnung – andernfalls müssen alle Mitarbeiter ihre Arbeit auf Deinen Commit rebasen.
 
 <!--To demonstrate, you’ll add a large file into your test repository, remove it in the next commit, find it, and remove it permanently from the repository. First, add a large object to your history:-->
 
-Um das zu demonstrieren, werden wir eine große Datei zu Deinem Test Repository hinzufügen, sie dann im nächsten Commit löschen, in der Datenbank nachschlagen und sie schließlich dauerhaft aus dem Repository entfernen. Als erstes committe also eine große Datei in Dein Repository:
+Um das zu demonstrieren, werden wir eine große Datei zu Deinem Test-Repository hinzufügen, sie dann im nächsten Commit löschen, in der Datenbank nachschlagen und sie schließlich dauerhaft aus dem Repository entfernen. Als erstes committe also eine große Datei in Dein Repository:
 
 	$ curl http://kernel.org/pub/software/scm/git/git-1.6.3.1.tar.bz2 > git.tbz2
 	$ git add git.tbz2
@@ -1255,7 +1255,7 @@ Oha. Du wolltest keinen dermaßen großen Tarball in Deinem Projekt. Am besten l
 
 <!--Now, `gc` your database and see how much space you’re using:-->
 
-Jetzt lassen wir die Garbage Collection über die Datenbank laufen und sehen, wieviel Platz sie braucht:
+Jetzt lassen wir die Garbage-Collection über die Datenbank laufen und sehen, wieviel Platz sie braucht:
 
 	$ git gc
 	Counting objects: 21, done.
@@ -1266,7 +1266,7 @@ Jetzt lassen wir die Garbage Collection über die Datenbank laufen und sehen, wi
 
 <!--You can run the `count-objects` command to quickly see how much space you’re using:-->
 
-Du kannst auch den `count-objects` Befehl laufen lassen, um einen schnellen Überblick darüber zu erhalten, wieviel Platz das Repository einnimmt:
+Du kannst auch den Befehl `count-objects` laufen lassen, um einen schnellen Überblick darüber zu erhalten, wieviel Platz das Repository einnimmt:
 
 	$ git count-objects -v
 	count: 4
@@ -1279,11 +1279,11 @@ Du kannst auch den `count-objects` Befehl laufen lassen, um einen schnellen Übe
 
 <!--The `size-pack` entry is the size of your packfiles in kilobytes, so you’re using 2MB. Before the last commit, you were using closer to 2K — clearly, removing the file from the previous commit didn’t remove it from your history. Every time anyone clones this repository, they will have to clone all 2MB just to get this tiny project, because you accidentally added a big file. Let’s get rid of it.-->
 
-Der `size-pack` Eintrag zeigt die Größe der Packfiles in Kilobytes, d.h. Dein Repository braucht 2 MB. Vor dem letzten Commit lag dieser Wert eher bei 2 KB. D.h., die Datei wurde im letzten Commit eindeutig nicht aus der History entfernt. Jedes Mal, wenn jemand künftig dieses sehr kleine Repository clont, wird er die 2 MB mit herunterladen müssen – nur weil wir versehentlich diese große Datei hinzugefügt hatten. Also versuchen wir, sie endgültig los zu werden.
+Der `size-pack`-Eintrag zeigt die Größe der Packfiles in Kilobytes, d.h. Dein Repository braucht 2 MB. Vor dem letzten Commit lag dieser Wert eher bei 2 KB. D.h., die Datei wurde im letzten Commit eindeutig nicht aus der History entfernt. Jedes Mal, wenn jemand künftig dieses sehr kleine Repository clont, wird er die 2 MB mit herunterladen müssen – nur weil wir versehentlich diese große Datei hinzugefügt hatten. Also versuchen wir, sie endgültig loszuwerden.
 
 <!--First you have to find it. In this case, you already know what file it is. But suppose you didn’t; how would you identify what file or files were taking up so much space? If you run `git gc`, all the objects are in a packfile; you can identify the big objects by running another plumbing command called `git verify-pack` and sorting on the third field in the output, which is file size. You can also pipe it through the `tail` command because you’re only interested in the last few largest files:-->
 
-Zunächst mal müssen wir sie finden. In diesem Fall wissen wir bereits, um welche Datei es sich handelt. Aber nehmen wir an, wir wüssten es nicht. Wie würdest Du herausfinden, welche Datei (oder welche Dateien) so viel Platz verbrauchen? Wenn Du `git gc` laufen gelassen hast, werden sich alle Objekte in einem Packfile befinden. Du kannst dann große Objekte identifizieren, indem Du einen weiteren Plumbing Befehl, nämlich `git verify-pack` ausführst und nach dem dritten Feld der Ausgabe sortierst, d.h. der Dateigröße. Du kannst sie außerdem durch den `tail` Befehl leiten, denn Du bist ja nur an den wenigen größten Objekten interessiert:
+Zunächst mal müssen wir sie finden. In diesem Fall wissen wir bereits, um welche Datei es sich handelt. Aber nehmen wir an, wir wüssten es nicht. Wie würdest Du herausfinden, welche Datei (oder welche Dateien) so viel Platz verbrauchen? Wenn Du `git gc` laufen gelassen hast, werden sich alle Objekte in einem Packfile befinden. Du kannst dann große Objekte identifizieren, indem Du einen weiteren Plumbing-Befehl, nämlich `git verify-pack` ausführst und nach dem dritten Feld der Ausgabe sortierst, d.h. der Dateigröße. Du kannst sie außerdem durch den `tail` Befehl leiten, denn Du bist ja nur an den wenigen größten Objekten interessiert:
 
 	$ git verify-pack -v .git/objects/pack/pack-3f8c0...bb.idx | sort -k 3 -n | tail -3
 	e3f094f522629ae358806b17daf78246c27c007b blob   1486 734 4667
@@ -1292,14 +1292,14 @@ Zunächst mal müssen wir sie finden. In diesem Fall wissen wir bereits, um welc
 
 <!--The big object is at the bottom: 2MB. To find out what file it is, you’ll use the `rev-list` command, which you used briefly in Chapter 7. If you pass `-\-objects` to `rev-list`, it lists all the commit SHAs and also the blob SHAs with the file paths associated with them. You can use this to find your blob’s name:-->
 
-Das größte Objekt ist ganz klar das letzte: es ist 2 MB groß. Um herauszufinden, welche Datei das ist, kannst Du den `rev-list` Befehl verwenden, den wir in Kapitel 7 schon einmal kurz verwendet haben. Wenn Du die Optionen `--objects` und `rev-list` verwendest, werden alle Commit und Blob SHAs mit den jeweiligen Dateipfaden aufgelistet, die mit ihnen assoziiert sind. Auf diese Weise kannst Du den Namen des Blobs finden:
+Das größte Objekt ist ganz klar das letzte: es ist 2 MB groß. Um herauszufinden, welche Datei das ist, kannst Du den `rev-list` Befehl verwenden, den wir in Kapitel 7 schon einmal kurz verwendet haben. Wenn Du die Optionen `--objects` und `rev-list` verwendest, werden alle Commit- und Blob-SHAs mit den jeweiligen Dateipfaden aufgelistet, die mit ihnen assoziiert sind. Auf diese Weise kannst Du den Namen des Blobs finden:
 
 	$ git rev-list --objects --all | grep 7a9eb2fb
 	7a9eb2fba2b1811321254ac360970fc169ba2330 git.tbz2
 
 <!--Now, you need to remove this file from all trees in your past. You can easily see what commits modified this file:-->
 
-Du musst diese Datei jetzt aus allen Trees entfernen, in denen er sich befindet. Du kannst leicht herausfinden, welche Commits diese Datei verändert haben:
+Du musst diese Datei jetzt aus allen Trees entfernen, in denen sie sich befindet. Du kannst leicht herausfinden, welche Commits diese Datei verändert haben:
 
 	$ git log --pretty=oneline --branches -- git.tbz2
 	da3f30d019005479c99eb4c3406225613985a1db oops - removed large tarball
@@ -1307,7 +1307,7 @@ Du musst diese Datei jetzt aus allen Trees entfernen, in denen er sich befindet.
 
 <!--You must rewrite all the commits downstream from `6df76` to fully remove this file from your Git history. To do so, you use `filter-branch`, which you used in Chapter 6:-->
 
-Es geht also darum, alle Commits angefangen bei `6df76` neu zu schreiben, sodass der Tarball nicht mehr in Deiner Git Historie enthalten ist. Um das zu erreichen, verwendest Du den Befehl `git filter-branch`, den wir schon mal in Kapitel 6 verwendet haben:
+Es geht also darum, alle Commits angefangen bei `6df76` neu zu schreiben, sodass der Tarball nicht mehr in Deiner Git-Historie enthalten ist. Um das zu erreichen, verwendest Du den Befehl `git filter-branch`, den wir schon mal in Kapitel 6 verwendet haben:
 
 	$ git filter-branch --index-filter \
 	   'git rm --cached --ignore-unmatch git.tbz2' -- 6df7640^..
@@ -1317,7 +1317,7 @@ Es geht also darum, alle Commits angefangen bei `6df76` neu zu schreiben, sodass
 
 <!--The `-\-index-filter` option is similar to the `-\-tree-filter` option used in Chapter 6, except that instead of passing a command that modifies files checked out on disk, you’re modifying your staging area or index each time. Rather than remove a specific file with something like `rm file`, you have to remove it with `git rm -\-cached` — you must remove it from the index, not from disk. The reason to do it this way is speed — because Git doesn’t have to check out each revision to disk before running your filter, the process can be much, much faster. You can accomplish the same task with `-\-tree-filter` if you want. The `-\-ignore-unmatch` option to `git rm` tells it not to error out if the pattern you’re trying to remove isn’t there. Finally, you ask `filter-branch` to rewrite your history only from the `6df7640` commit up, because you know that is where this problem started. Otherwise, it will start from the beginning and will unnecessarily take longer.-->
 
-Die `--index-filter` Option ist ähnlich der `--tree-filter` Option aus Kapitel 6. Allerdings übergibt man in diesem Fall nicht einen Befehl, der die Dateien verändert, die sich jeweils ausgecheckt auf der Festplatte befinden. Statt dessen verändert man jeweils die Staging Area bzw. den Index. Statt eine bestimmte Datei mit z.B: `rm file` zu entfernen, müssen wir also `git rm --cached` verwenden – denn wir wollen sie aus dem Index, nicht von der Festplatte löschen. Der Grund dafür ist einfach Geschwindigkeit: Git braucht nicht jede einzelne Revision auf die Festplatte auszuchecken, um den Filter anzuwenden. Auf diese Weise läuft der ganze Prozess sehr viel schneller. Man kann dieselbe Aufgabe aber auch mit `--tree-filter` erledigen, wenn man will. Die Option `--ignore-match` weist Git an, nicht mit einer Fehlermeldung abzubrechen, wenn die Datei, die wir löschen wollen, nicht vorhanden ist. Außerdem teilen wir `filter-branch` mit, die Historie nur von dem Commit `6df7640` an umzuschreiben. Andernfalls würde der Befehl von ganz vorn beginnen und unnötig länger brauchen.
+DieOption  `--index-filter` ist ähnlich der Option `--tree-filter` aus Kapitel 6. Allerdings übergibt man in diesem Fall nicht einen Befehl, der die Dateien verändert, die sich jeweils ausgecheckt auf der Festplatte befinden. Stattdessen verändert man jeweils die Staging-Area bzw. den Index. Statt eine bestimmte Datei mit z.B: `rm file` zu entfernen, müssen wir also `git rm --cached` verwenden – denn wir wollen sie aus dem Index, nicht von der Festplatte löschen. Der Grund dafür ist einfach Geschwindigkeit: Git braucht nicht jede einzelne Revision auf die Festplatte auszuchecken, um den Filter anzuwenden. Auf diese Weise läuft der ganze Prozess sehr viel schneller. Man kann dieselbe Aufgabe aber auch mit `--tree-filter` erledigen, wenn man will. Die Option `--ignore-match` weist Git an, nicht mit einer Fehlermeldung abzubrechen, wenn die Datei, die wir löschen wollen, nicht vorhanden ist. Außerdem teilen wir `filter-branch` mit, die Historie nur von dem Commit `6df7640` an umzuschreiben. Andernfalls würde der Befehl von ganz vorn beginnen und unnötig länger brauchen.
 
 <!--Your history no longer contains a reference to that file. However, your reflog and a new set of refs that Git added when you did the `filter-branch` under `.git/refs/original` still do, so you have to remove them and then repack the database. You need to get rid of anything that has a pointer to those old commits before you repack:-->
 
@@ -1347,15 +1347,15 @@ Prüfen wir also, wieviel Platz wir damit eingespart haben:
 
 <!--The packed repository size is down to 7K, which is much better than 2MB. You can see from the size value that the big object is still in your loose objects, so it’s not gone; but it won’t be transferred on a push or subsequent clone, which is what is important. If you really wanted to, you could remove the object completely by running `git prune -\-expire`.-->
 
-Das gepackte Repository umfasst jetzt nur noch 7K – sehr viel besser als die vorherigen 2MB. Du kannst an dem Wert `size` erkennen, dass sich die große Datei selbst jetzt immer noch in Deinen loosen Objekten befindet. Aber sie wird bei einem `git push` oder anschließenden `git clone` nicht übermittelt werden – und das war unser Ziel. Wenn Du das wirklich willst, kannst Du sie jetzt vollständig und endgültig mit `git prune --expire` aus Deinem Repository löschen.
+Das gepackte Repository umfasst jetzt nur noch 7K – sehr viel besser als die vorherigen 2MB. Du kannst an dem Wert `size` erkennen, dass sich die große Datei selbst jetzt immer noch in Deinen losen Objekten befindet. Aber sie wird bei einem `git push` oder anschließenden `git clone` nicht übermittelt werden – und das war unser Ziel. Wenn Du das wirklich willst, kannst Du sie jetzt vollständig und endgültig mit `git prune --expire` aus Deinem Repository löschen.
 
 <!--## Summary ##-->
 ## Zusammenfassung ##
 
 <!--You should have a pretty good understanding of what Git does in the background and, to some degree, how it’s implemented. This chapter has covered a number of plumbing commands — commands that are lower level and simpler than the porcelain commands you’ve learned about in the rest of the book. Understanding how Git works at a lower level should make it easier to understand why it’s doing what it’s doing and also to write your own tools and helping scripts to make your specific workflow work for you.-->
 
-Du solltest jetzt ein gutes Verständnis davon haben, was Git im Hintergrund tut, und in einem gewissen Maße auch davon, wie es implementiert ist. In diesem Kapitel haben wir eine Reihe von Plumbing Befehlen besprochen, als Befehlen, die grundlegender und einfacher als die Porzellan Befehle sind, um die es im restlichen Buch ging. Dieses Verständnis sollte Dir helfen, zu verstehen, warum Git tut, was es tut – und natürlich auch dabei, Deine eigenen Werkzeuge und Hilfsskripte zu schreiben, um einen bestimmten Workflow für Dich anzupassen.
+Du solltest jetzt ein gutes Verständnis davon haben, was Git im Hintergrund tut, und in einem gewissen Maße auch davon, wie es implementiert ist. In diesem Kapitel haben wir eine Reihe von Plumbing-Befehlen besprochen, also Befehlen, die grundlegender und einfacher als die Porcelain-Befehle sind, um die es im restlichen Buch ging. Dieses Verständnis sollte Dir helfen, zu verstehen, warum Git tut, was es tut – und natürlich auch dabei, Deine eigenen Werkzeuge und Hilfsskripte zu schreiben, um einen bestimmten Arbeitsablauf für Dich anzupassen.
 
 <!--Git as a content-addressable filesystem is a very powerful tool that you can easily use as more than just a VCS. I hope you can use your newfound knowledge of Git internals to implement your own cool application of this technology and feel more comfortable using Git in more advanced ways.-->
 
-Git als ein Dateisystem, das Inhalte addressieren kann, ist ein äußerst mächtiges Werkzeug, das Du leicht als mehr als „nur“ als  (xxx) ein VCS einsetzen kannst. Ich hoffe, Du kannst Dein neugewonnenes Wissen der Git Interna nutzen, um Deine eigene tolle Anwendung dieser Technologie zu implementieren und Dich wohler damit zu fühlen, Git auch in fortgeschrittener Weise zu benutzen.
+Git als ein Dateisystem, das Inhalte addressieren kann, ist ein äußerst mächtiges Werkzeug, das Du leicht für mehr als „nur“ als VCS einsetzen kannst. Ich hoffe, Du kannst Dein neugewonnenes Wissen der Git-Interna nutzen, um Deine eigene tolle Anwendung dieser Technologie zu implementieren und Dich wohler damit zu fühlen, Git auch in fortgeschrittener Weise zu benutzen.

From 8c361261d251c6fd9500ebc01d4ea729c73b1ad1 Mon Sep 17 00:00:00 2001
From: Ralph Haussmann <ralph@scanmyfood.de>
Date: Sun, 19 Jan 2014 17:00:08 +0100
Subject: [PATCH 114/690] [de] Connect compound nouns with dash

---
 de/06-git-tools/01-chapter6.markdown | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/de/06-git-tools/01-chapter6.markdown b/de/06-git-tools/01-chapter6.markdown
index 31bcf958a..ed355aee2 100644
--- a/de/06-git-tools/01-chapter6.markdown
+++ b/de/06-git-tools/01-chapter6.markdown
@@ -95,7 +95,7 @@ Allerdings solltest Du Dir bewusst machen, wie unglaublich unwahrscheinlich dies
 Hier ist ein Beispiel, das Dir eine Vorstellung davon gibt, was nötig ist, um in SHA-1 eine Kollision zu bekommen. Wenn alle 6,5 Milliarden Menschen auf der Erde programmieren würden und jeder jede Sekunde Code schreiben würde, der der gesamten Geschichte des Linux-Kernels (1 Million Git-Objekte) entspricht, und diesen dann in ein gigantisches Git-Repository übertragen würde, würde es fünf Jahre dauern, bis das Repository genügend Objekte hätte, um eine 50% Wahrscheinlichkeit für eine einzige SHA-1-Kollision aufzuweisen. Es ist wahrscheinlicher, dass jedes Mitglied Deines Programmierer-Teams, unabhängig voneinander, in einer Nacht von Wölfen angegriffen und getötet wird.
 
 <!--### Branch References ###-->
-### Branch Referenzen ###
+### Branch-Referenzen ###
 
 <!--The most straightforward way to specify a commit requires that it have a branch reference pointed at it. Then, you can use a branch name in any Git command that expects a commit object or SHA-1 value. For instance, if you want to show the last commit object on a branch, the following commands are equivalent, assuming that the `topic1` branch points to `ca82a6d`:-->
 
@@ -274,7 +274,7 @@ Du willst jetzt herausfinden, welche Änderungen in Deinem `experiment`-Branch s
 
 <!--If, on the other hand, you want to see the opposite — all commits in `master` that aren’t in `experiment` — you can reverse the branch names. `experiment..master` shows you everything in `master` not reachable from `experiment`:-->
 
-Wenn Du allerdings – anders herum – diejenigen Commits anzeigen willst, die in `master`, aber noch nicht in `experiment` sind, kannst Du die Branch Namen umdrehen: `experiment..master` zeigt „alles in `master`, das nicht in `experiment` enthalten ist“.
+Wenn Du allerdings – anders herum – diejenigen Commits anzeigen willst, die in `master`, aber noch nicht in `experiment` sind, kannst Du die Branch-Namen umdrehen: `experiment..master` zeigt „alles in `master`, das nicht in `experiment` enthalten ist“.
 
 	$ git log experiment..master
 	F
@@ -314,7 +314,7 @@ Das ist praktisch, weil Du auf diese Weise mehr als nur zwei Referenzen angeben
 Damit hast Du ein sehr mächtiges System von Abfragen zur Verfügung, mit denen Du herausfinden kannst, was in welchen Deiner Branches enthalten ist.
 
 <!--#### Triple Dot ####-->
-#### Drei-Punkte Syntax ####
+#### Drei-Punkte-Syntax ####
 
 <!--The last major range-selection syntax is the triple-dot syntax, which specifies all the commits that are reachable by either of two references but not by both of them. Look back at the example commit history in Figure 6-1.-->
 <!--If you want to see what is in `master` or `experiment` but not any common references, you can run-->
@@ -472,7 +472,7 @@ Um einen Diff dessen zu sehen, das Du gestaget hast, kannst Du den Befehl `6` od
 
 <!--With these basic commands, you can use the interactive add mode to deal with your staging area a little more easily.-->
 
-Mit diesen grundlegenden Befehlen kannst Du den interaktiven add Modus nutzen, um Dir den Umgang mit Deiner Staging-Area etwas zu erleichtern.
+Mit diesen grundlegenden Befehlen kannst Du den interaktiven Hinzufüge-Modus nutzen, um Dir den Umgang mit Deiner Staging-Area etwas zu erleichtern.
 
 <!--### Staging Patches ###-->
 ### Patches stagen ###
@@ -895,7 +895,7 @@ Man kann mit Git einen einzelnen Commit auch aufsplitten. Das bedeutet, man setz
 
 <!--When you save and exit the editor, Git rewinds to the parent of the first commit in your list, applies the first commit (`f7f3f6d`), applies the second (`310154e`), and drops you to the console. There, you can do a mixed reset of that commit with `git reset HEAD^`, which effectively undoes that commit and leaves the modified files unstaged. Now you can take the changes that have been reset, and create multiple commits out of them. Simply stage and commit files until you have several commits, and run `git rebase -\-continue` when you’re done:-->
 
-Nach dem Speichern und Schließen des Editors, setzt Git die Änderungen entsprechend zurück und wendet den ersten (`f7f3f6d`) und zweiten (`310154e`) Commit an und wechselt danach zurück zur Kommandozeile. Jetzt hast Du die Möglichkeit den letzten Commit zurückzusetzen, ohne dass die Änderungen im Arbeitsverzeichnis zurückgesetzt werden. Das heißt, der Commit im Repository wird gelöscht, aber Deine Änderungen im Arbeitsverzeichnis gehen nicht verloren. Um dies durchzuführen, kannst Du den Befehl `git reset HEAD^` verwenden. Jetzt kannst Du die gewünschten Änderungen für den ersten Commit zur Staging Area hinzufügen und danach einchecken. Diesen Vorgang kannst Du beliebig wiederholen, bis alle Änderungen eingecheckt sind. Wenn Du fertig bist, kannst Du den Rebase mit `git rebase --continue` fortsetzen beziehungsweise abschließen:
+Nach dem Speichern und Schließen des Editors, setzt Git die Änderungen entsprechend zurück und wendet den ersten (`f7f3f6d`) und zweiten (`310154e`) Commit an und wechselt danach zurück zur Kommandozeile. Jetzt hast Du die Möglichkeit den letzten Commit zurückzusetzen, ohne dass die Änderungen im Arbeitsverzeichnis zurückgesetzt werden. Das heißt, der Commit im Repository wird gelöscht, aber Deine Änderungen im Arbeitsverzeichnis gehen nicht verloren. Um dies durchzuführen, kannst Du den Befehl `git reset HEAD^` verwenden. Jetzt kannst Du die gewünschten Änderungen für den ersten Commit zur Staging-Area hinzufügen und danach einchecken. Diesen Vorgang kannst Du beliebig wiederholen, bis alle Änderungen eingecheckt sind. Wenn Du fertig bist, kannst Du den Rebase mit `git rebase --continue` fortsetzen beziehungsweise abschließen:
 
 	$ git reset HEAD^
 	$ git add README
@@ -1131,7 +1131,7 @@ Nehmen wir einmal an, dass Du die Rack-Bibliothek (eine Ruby-Gateway-Schnittstel
 
 <!--Now you have the Rack project under a subdirectory named `rack` within your project. You can go into that subdirectory, make changes, add your own writable remote repository to push your changes into, fetch and merge from the original repository, and more. If you run `git status` right after you add the submodule, you see two things:-->
 
-Innerhalb Deines Projekts befindet sich nun im Unterverzeichnis `rack` das komplette Rack-Projekt. Man kann jetzt in diesem Verzeichnis Änderungen vornehmen und ein eigenes Remote Repository mit Schreibrechten, zu welchem man pushen kann, hinzufügen. Ebenso ist es möglich, Änderungen von den Rack-Entwicklern in sein Repository zu laden und diese mit den eigenen Ergebnissen zu mergen. Im Prinzip kann man innerhalb eines Submoduls die gleichen Vorgänge, wie in einem normalen Repository ausführen. Vorher müssen wir aber noch ein paar weitere Dinge zu Submodulen besprechen. Wenn Du gleich nach dem Hinzufügen des Submoduls, den Befehl `git status` ausführst, wirst Du gleich zwei Dinge bemerken:
+Innerhalb Deines Projekts befindet sich nun im Unterverzeichnis `rack` das komplette Rack-Projekt. Man kann jetzt in diesem Verzeichnis Änderungen vornehmen und ein eigenes Remote-Repository mit Schreibrechten, zu welchem man pushen kann, hinzufügen. Ebenso ist es möglich, Änderungen von den Rack-Entwicklern in sein Repository zu laden und diese mit den eigenen Ergebnissen zu mergen. Im Prinzip kann man innerhalb eines Submoduls die gleichen Vorgänge, wie in einem normalen Repository ausführen. Vorher müssen wir aber noch ein paar weitere Dinge zu Submodulen besprechen. Wenn Du gleich nach dem Hinzufügen des Submoduls, den Befehl `git status` ausführst, wirst Du gleich zwei Dinge bemerken:
 
 	$ git status
 	# On branch master

From a3809eadd47e8974b82c711164c9192c5a6dceb2 Mon Sep 17 00:00:00 2001
From: Ralph Haussmann <ralph@scanmyfood.de>
Date: Sun, 19 Jan 2014 17:03:43 +0100
Subject: [PATCH 115/690] [de] Use "Branch master" instead of "Master-Branch"

- master is a special term in Git terminology
- It is used in other sections in the exact same manner
---
 de/06-git-tools/01-chapter6.markdown | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/de/06-git-tools/01-chapter6.markdown b/de/06-git-tools/01-chapter6.markdown
index ed355aee2..fa81fd758 100644
--- a/de/06-git-tools/01-chapter6.markdown
+++ b/de/06-git-tools/01-chapter6.markdown
@@ -942,7 +942,7 @@ Die Option `--tree-filer` führt den nachfolgenden Befehl nach jedem Auschecken
 
 <!--You’ll be able to watch Git rewriting trees and commits and then move the branch pointer at the end. It’s generally a good idea to do this in a testing branch and then hard-reset your master branch after you’ve determined the outcome is what you really want. To run `filter-branch` on all your branches, you can pass `-\-all` to the command.-->
 
-Git informiert Dich über den Fortschritt dieses Vorgangs und Du siehst, wie jeder Commit angepasst wird und der Zeiger auf den Branch auf den letzten Commit gesetzt wird. Es ist empfehlenswert, diesen Befehl in einem Testzweig durchzuführen. Wenn das Ergebnis, wie gewünscht ausfällt, kann man danach den Master-Branch auf diesen Testzweig setzen. Wenn man an den Befehl `filter-branch` die Option `--all` anfügt, führt Git diesen Vorgang für jeden vorhandenen Zweig aus.
+Git informiert Dich über den Fortschritt dieses Vorgangs und Du siehst, wie jeder Commit angepasst wird und der Zeiger auf den Branch auf den letzten Commit gesetzt wird. Es ist empfehlenswert, diesen Befehl in einem Testzweig durchzuführen. Wenn das Ergebnis, wie gewünscht ausfällt, kann man danach den Branch master auf diesen Testzweig setzen. Wenn man an den Befehl `filter-branch` die Option `--all` anfügt, führt Git diesen Vorgang für jeden vorhandenen Zweig aus.
 
 <!--#### Making a Subdirectory the New Root ####-->
 #### Aus einem Unterverzeichnis das neue Wurzelverzeichnis machen ####
@@ -1471,7 +1471,7 @@ Wenn Du jetzt einen Commit ausführst, erscheint es einem so, als ob die ganzen
 
 <!--Then, you can merge those changes back into your master branch. You can use `git merge -s subtree` and it will work fine; but Git will also merge the histories together, which you probably don’t want. To pull in the changes and prepopulate the commit message, use the `-\-squash` and `-\-no-commit` options as well as the `-s subtree` strategy option:-->
 
-Danach kann man diese Änderungen wieder in den master-Branch mergen. Wenn man den Befehl `git merge -s subtree` verwendet, sollte dies einwandfrei funktionieren. Allerdings wird Git bei Ausführen dieses Befehls auch die jeweilige Historie mergen, was Du wahrscheinlich nicht haben möchtest. Um nun die Änderungen zu holen und eine entsprechende Commit-Nachricht vorzubereiten, hängt man einfach `--squash`, `--no-commit` und natürlich `-s subtree` als Option an:
+Danach kann man diese Änderungen wieder in den Branch master mergen. Wenn man den Befehl `git merge -s subtree` verwendet, sollte dies einwandfrei funktionieren. Allerdings wird Git bei Ausführen dieses Befehls auch die jeweilige Historie mergen, was Du wahrscheinlich nicht haben möchtest. Um nun die Änderungen zu holen und eine entsprechende Commit-Nachricht vorzubereiten, hängt man einfach `--squash`, `--no-commit` und natürlich `-s subtree` als Option an:
 
 	$ git checkout master
 	$ git merge --squash -s subtree --no-commit rack_branch
@@ -1480,7 +1480,7 @@ Danach kann man diese Änderungen wieder in den master-Branch mergen. Wenn man d
 
 <!--All the changes from your Rack project are merged in and ready to be committed locally. You can also do the opposite — make changes in the `rack` subdirectory of your master branch and then merge them into your `rack_branch` branch later to submit them to the maintainers or push them upstream.-->
 
-Die ganzen Änderungen des Rack-Projekts wurden nun zusammengeführt, Du musst jetzt nur noch einen entsprechenden Commit durchführen. Man kann aber auch genau das Gegenteil machen: Man führt Änderungen im Unterverzeichnis `rack` des master-Branches aus und mergt diese dann später in den Zweig `rack_branch`. Diesen kann man dann den Entwicklern des Rack-Projekts zur Verfügung stellen.
+Die ganzen Änderungen des Rack-Projekts wurden nun zusammengeführt, Du musst jetzt nur noch einen entsprechenden Commit durchführen. Man kann aber auch genau das Gegenteil machen: Man führt Änderungen im Unterverzeichnis `rack` des Branches master aus und mergt diese dann später in den Zweig `rack_branch`. Diesen kann man dann den Entwicklern des Rack-Projekts zur Verfügung stellen.
 
 <!--To get a diff between what you have in your `rack` subdirectory and the code in your `rack_branch` branch — to see if you need to merge them — you can’t use the normal `diff` command. Instead, you must run `git diff-tree` with the branch you want to compare to:-->
 

From db6eb4147a6b88549f695ee7a39379b8f154f76d Mon Sep 17 00:00:00 2001
From: Ralph Haussmann <ralph@scanmyfood.de>
Date: Sun, 19 Jan 2014 17:09:37 +0100
Subject: [PATCH 116/690] [de] Use correct plural Repositorys instead of
 Repositories

---
 de/06-git-tools/01-chapter6.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/de/06-git-tools/01-chapter6.markdown b/de/06-git-tools/01-chapter6.markdown
index fa81fd758..edd87d1ba 100644
--- a/de/06-git-tools/01-chapter6.markdown
+++ b/de/06-git-tools/01-chapter6.markdown
@@ -289,7 +289,7 @@ Dies ist nützlich, wenn Du vorhast, den `experiment`-Branch zu aktualisieren, u
 <!--This command shows you any commits in your current branch that aren’t in the `master` branch on your `origin` remote. If you run a `git push` and your current branch is tracking `origin/master`, the commits listed by `git log origin/master..HEAD` are the commits that will be transferred to the server.-->
 <!--You can also leave off one side of the syntax to have Git assume HEAD. For example, you can get the same results as in the previous example by typing `git log origin/master..` — Git substitutes HEAD if one side is missing.-->
 
-Dieser Befehl zeigt Dir alle Commits im gegenwärtigen, lokalen Branch, die noch nicht im `master`-Branch des `origin` Repositories sind. D.h., der Befehl listet diejenigen Commits auf, die auf den Server transferiert würden, wenn Du `git push` benutzt und der aktuelle Branch `origin/master` trackt. Du kannst mit dieser Syntax außerdem eine Seite der beiden Punkte leer lassen. Git nimmt dann an, Du meinst an dieser Stelle HEAD. Z.B. kannst Du dieselben Commits wie im vorherigen Beispiel auch mit `git log origin/master..` anzeigen lassen. Git fügt dann HEAD auf der rechten Seite ein.
+Dieser Befehl zeigt Dir alle Commits im gegenwärtigen, lokalen Branch, die noch nicht im `master`-Branch des `origin` Repositorys sind. D.h., der Befehl listet diejenigen Commits auf, die auf den Server transferiert würden, wenn Du `git push` benutzt und der aktuelle Branch `origin/master` trackt. Du kannst mit dieser Syntax außerdem eine Seite der beiden Punkte leer lassen. Git nimmt dann an, Du meinst an dieser Stelle HEAD. Z.B. kannst Du dieselben Commits wie im vorherigen Beispiel auch mit `git log origin/master..` anzeigen lassen. Git fügt dann HEAD auf der rechten Seite ein.
 
 <!--#### Multiple Points ####-->
 #### Mehrfache Punkte (xxx) ####

From 86258cf596d9bfc27fe1e2e742c156d5f124c65e Mon Sep 17 00:00:00 2001
From: Ralph Haussmann <ralph@scanmyfood.de>
Date: Sun, 19 Jan 2014 17:22:28 +0100
Subject: [PATCH 117/690] [de] Review paragraphs marked with "xxx" and fix them

---
 de/06-git-tools/01-chapter6.markdown | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/de/06-git-tools/01-chapter6.markdown b/de/06-git-tools/01-chapter6.markdown
index edd87d1ba..1362c864f 100644
--- a/de/06-git-tools/01-chapter6.markdown
+++ b/de/06-git-tools/01-chapter6.markdown
@@ -258,7 +258,7 @@ Nachdem Du jetzt einzelne Commits spezifizieren kannst, schauen wir uns an, wie
 
 <!--The most common range specification is the double-dot syntax. This basically asks Git to resolve a range of commits that are reachable from one commit but aren’t reachable from another. For example, say you have a commit history that looks like Figure 6-1.-->
 
-Die gängigste Weise, Commit-Reihen anzugeben, ist die Zwei-Punkte-Notation. Allgemein gesagt evaluiert Git eine Reihe von Commits, die von einem Commit aus erreichbar sind, nicht aber von einem anderen (xxx ??? xxx). Nehmen wir z.B. an, Du hättest eine Commit-Historie wie die folgende (Bild 6-1).
+Die gängigste Weise, Commit-Reihen anzugeben, ist die Zwei-Punkte-Notation. Allgemein gesagt liefert Git damit eine Reihe von Commits, die von dem einem Commit aus erreichbar sind, allerdings nicht von dem anderen aus. Nehmen wir z.B. an, Du hättest eine Commit-Historie wie die folgende (Bild 6-1).
 
 <!--Figure 6-1. Example history for range selection.-->
 
@@ -292,7 +292,7 @@ Dies ist nützlich, wenn Du vorhast, den `experiment`-Branch zu aktualisieren, u
 Dieser Befehl zeigt Dir alle Commits im gegenwärtigen, lokalen Branch, die noch nicht im `master`-Branch des `origin` Repositorys sind. D.h., der Befehl listet diejenigen Commits auf, die auf den Server transferiert würden, wenn Du `git push` benutzt und der aktuelle Branch `origin/master` trackt. Du kannst mit dieser Syntax außerdem eine Seite der beiden Punkte leer lassen. Git nimmt dann an, Du meinst an dieser Stelle HEAD. Z.B. kannst Du dieselben Commits wie im vorherigen Beispiel auch mit `git log origin/master..` anzeigen lassen. Git fügt dann HEAD auf der rechten Seite ein.
 
 <!--#### Multiple Points ####-->
-#### Mehrfache Punkte (xxx) ####
+#### Mehrere Bezugspunkte ####
 
 <!--The double-dot syntax is useful as a shorthand; but perhaps you want to specify more than two branches to indicate your revision, such as seeing what commits are in any of several branches that aren’t in the branch you’re currently on. Git allows you to do this by using either the `^` character or `-\-not` before any reference from which you don’t want to see reachable commits. Thus these three commands are equivalent:-->
 
@@ -373,7 +373,7 @@ Wie Du siehst, zeigt dieser Befehl eine andere Ansicht der Staging-Area an – i
 Danach folgt eine Liste von Befehlen wie, u.a., Dateien ganz oder teilweise stagen und unstagen, nicht versionskontrollierte Dateien hinzufügen, Diffs der gestageten Änderungen anzeigen etc.
 
 <!--### Staging and Unstaging Files ###-->
-### Dateien stagen und unstagen (xxx) ###
+### Hinzufügen und Enfernen von Dateien aus der Staging-Area ###
 
 <!--If you type `2` or `u` at the `What now>` prompt, the script prompts you for which files you want to stage:-->
 

From 472dbeabe6fe29cb053abf3c61193ceed028700f Mon Sep 17 00:00:00 2001
From: Ralph Haussmann <ralph@scanmyfood.de>
Date: Sun, 19 Jan 2014 17:24:32 +0100
Subject: [PATCH 118/690] [de] Numbers less than twelve are written-out

---
 de/06-git-tools/01-chapter6.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/de/06-git-tools/01-chapter6.markdown b/de/06-git-tools/01-chapter6.markdown
index 1362c864f..e5b3a555f 100644
--- a/de/06-git-tools/01-chapter6.markdown
+++ b/de/06-git-tools/01-chapter6.markdown
@@ -479,7 +479,7 @@ Mit diesen grundlegenden Befehlen kannst Du den interaktiven Hinzufüge-Modus nu
 
 <!--It’s also possible for Git to stage certain parts of files and not the rest. For example, if you make two changes to your simplegit.rb file and want to stage one of them and not the other, doing so is very easy in Git. From the interactive prompt, type `5` or `p` (for patch). Git will ask you which files you would like to partially stage; then, for each section of the selected files, it will display hunks of the file diff and ask if you would like to stage them, one by one:-->
 
-Es ist für Git auch möglich, bestimmte Teile einer Datei zu stagen und nicht den Rest. Wenn Du z.B. 2 Veränderungen an der simplegit.rb machst und eine davon stagen willst und die andere nicht, ist dies sehr einfach in Git möglich. Wähle `5` oder `p` (für patch) auf dem interaktiven Prompt. Git wird Dich fragen, welche Dateien Du teilweise stagen willst; dann wird es für jeden Abschnitt der gewählten Dateien Diff-Ausschnitte ausgeben und Dich jeweils einzeln fragen, ob Du sie stagen willst.
+Es ist für Git auch möglich, bestimmte Teile einer Datei zu stagen und nicht den Rest. Wenn Du z.B. zwei Veränderungen an der simplegit.rb machst und eine davon stagen willst und die andere nicht, ist dies sehr einfach in Git möglich. Wähle `5` oder `p` (für patch) auf dem interaktiven Prompt. Git wird Dich fragen, welche Dateien Du teilweise stagen willst; dann wird es für jeden Abschnitt der gewählten Dateien Diff-Ausschnitte ausgeben und Dich jeweils einzeln fragen, ob Du sie stagen willst.
 
 	diff --git a/lib/simplegit.rb b/lib/simplegit.rb
 	index dd5ecc4..57399e0 100644

From e64ed85756c1ce083258dcb8d8c83e85f170eeb0 Mon Sep 17 00:00:00 2001
From: Ralph Haussmann <ralph@scanmyfood.de>
Date: Sun, 19 Jan 2014 17:24:40 +0100
Subject: [PATCH 119/690] [de] Fix typo

---
 de/06-git-tools/01-chapter6.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/de/06-git-tools/01-chapter6.markdown b/de/06-git-tools/01-chapter6.markdown
index e5b3a555f..aec049519 100644
--- a/de/06-git-tools/01-chapter6.markdown
+++ b/de/06-git-tools/01-chapter6.markdown
@@ -76,7 +76,7 @@ Git kann auch selber eine Kurzform für Deine einzigartigen SHA-1-Werte erzeugen
 Generell kann man sagen, dass acht bis zehn Zeichen mehr als ausreichend in einem Projekt sind, um eindeutig zu bleiben. Eines der größten Git-Projekte, der Linux-Kernel, fängt langsam an 12 von maximal 40 Zeichen zu nutzen, um eindeutig zu bleiben.
 
 <!--### A SHORT NOTE ABOUT SHA-1 ###-->
-### EINE KURVE NOTIZ ÜBER SHA-1 ###
+### Ein kurzer Hinweis zu SHA-1 ###
 
 <!--A lot of people become concerned at some point that they will, by random happenstance, have two objects in their repository that hash to the same SHA-1 value. What then?-->
 

From f4ff8e4edcc3874470ff63044cc2158612290d1a Mon Sep 17 00:00:00 2001
From: Ralph Haussmann <ralph@scanmyfood.de>
Date: Sun, 19 Jan 2014 19:59:42 +0100
Subject: [PATCH 120/690] [de] Update status of chapter 6 and add some git
 specific terms

---
 de/README.md | 62 ++++++++++++++++++++++++++++++++++++++++++++--------
 1 file changed, 53 insertions(+), 9 deletions(-)

diff --git a/de/README.md b/de/README.md
index d9e8abcad..5d72f1653 100644
--- a/de/README.md
+++ b/de/README.md
@@ -63,6 +63,50 @@ Beispiel:
 
 * Bei englischen Nomen, die auf "y" enden, wird beim Plural nur ein einzelnes "s" angehängt (kein ies). Siehe hierzu auch http://www.duden.de/sprachwissen/sprachratgeber/crashkurs--in-25-schritten-zur-neuen-rechtschreibung
 
+#### Schreibweise von verschiedenen Git-Begriffen ####
+
+##### A - D #####
+
+* Branch (Plural: Branches)
+* Branch-Name
+* Branch-Referenz (Plural: Branch-Referenzen)
+* Commit
+* Commit-Datum
+* Commit-ID
+* Commit-Objekt (Plural: Commit-Objekte)
+* Commit-Nachricht
+* Drei-Punkte-Syntax
+
+##### E - H #####
+
+* Git-Repository
+* HEAD
+* HEAD-Referenz
+
+##### I - Q #####
+
+* der Klon (Plural: Klone)
+* Low-Level-Operation
+
+##### R - T #####
+
+* Reflog-Ausgabe
+* Remote-Repository
+* Repository (Plural: Repositorys)
+* SHA-1
+* SHA-1-Hash (Genitiv: SHA-1-Hashes)
+* SHA-1-Hashwert (Plural: SHA-1-Hashwerte) 
+* SHA-1-Prüfsumme
+* SHA-1-Wert
+* stagen (gestaget, ungestaget)
+* Staging-Area
+* Stash
+* stashen
+
+##### U - Z #####
+
+* Zwei-Punkte-Syntax
+
 ### Übersetzung von Git spezifischen Begriffen ###
 
 Wir versuchen die englischen Fachbegriffe, die in der Welt von Git existieren, zu benutzen. Zusätzlich versuchen wir aber immer, dass ein neu eingeführter Git-spezifischer Begriff, auch auf Deutsch erklärt wird.
@@ -379,63 +423,63 @@ Bitte den Status nicht aktualisieren. Dies übernimmt ein Maintainer.
 <td>Ja</td>
 <td>Nein</td>
 <td>Ja</td>
-<td bgcolor="yellow">Review notwendig</td>
+<td bgcolor="green">Ok</td>
 </tr>
 <tr>
 <td>6.1</td>
 <td>Ja</td>
 <td>Nein</td>
 <td>Ja</td>
-<td bgcolor="yellow">Review notwendig</td>
+<td bgcolor="green">Ok</td>
 </tr>
 <tr>
 <td>6.2</td>
 <td>Ja</td>
 <td>Nein</td>
 <td>Ja</td>
-<td bgcolor="yellow">Review notwendig</td>
+<td bgcolor="green">Ok</td>
 </tr>
 <tr>
 <td>6.3</td>
 <td>Ja</td>
 <td>Nein</td>
 <td>Ja</td>
-<td bgcolor="yellow">Review notwendig</td>
+<td bgcolor="green">Ok</td>
 </tr>
 <tr>
 <td>6.4</td>
 <td>Ja</td>
 <td>Nein</td>
 <td>Ja</td>
-<td bgcolor="yellow">Review notwendig</td>
+<td bgcolor="green">Ok</td>
 </tr>
 <tr>
 <td>6.5</td>
 <td>Ja</td>
 <td>Nein</td>
 <td>Ja</td>
-<td bgcolor="yellow">Review notwendig</td>
+<td bgcolor="green">Ok</td>
 </tr>
 <tr>
 <td>6.6</td>
 <td>Ja</td>
 <td>Nein</td>
 <td>Ja</td>
-<td bgcolor="yellow">Review notwendig</td>
+<td bgcolor="green">Ok</td>
 </tr>
 <tr>
 <td>6.7</td>
 <td>Nein</td>
 <td>Nein</td>
 <td>Ja</td>
-<td bgcolor="red">Übersetzung fehlt</td>
+<td bgcolor="green">Ok</td>
 </tr>
 <tr>
 <td>6.8</td>
 <td>Nein</td>
 <td>Nein</td>
 <td>Ja</td>
-<td bgcolor="red">Übersetzung fehlt</td>
+<td bgcolor="green">Ok</td>
 </tr>
 <tr>
 <td>7</td>

From 3fd7e2ac8781a0197afc128c1c1efdecb53d27be Mon Sep 17 00:00:00 2001
From: Cor <cor.takken@cgi.com>
Date: Mon, 20 Jan 2014 08:18:18 +0100
Subject: [PATCH 121/690] [nl] re-cloned local repository, copied other
 chapter4 over.

---
 nl/04-git-server/01-chapter4.markdown | 381 +++++++++++++++++++-------
 1 file changed, 278 insertions(+), 103 deletions(-)

diff --git a/nl/04-git-server/01-chapter4.markdown b/nl/04-git-server/01-chapter4.markdown
index f2bd2ae65..c6bdd3c65 100644
--- a/nl/04-git-server/01-chapter4.markdown
+++ b/nl/04-git-server/01-chapter4.markdown
@@ -1,24 +1,24 @@
 # Git op de Server #
 
-Op dit punt zou je alledaagse taken waarvoor je Git zult gebruiken kunnen doen. Maar, om samen te kunnen werken in Git, zul je een remote repository moeten hebben. Technisch gezien kun je wijzigingen pushen en pullen van individuele repositories, maar dat wordt afgeraden, omdat je vrij gemakkelijk het werk waar anderen mee bezig zijn in de war kunt schoppen als je niet oppast. Daarnaast wil je dat je medewerkers bij het repository kunnen, zelfs als jouw computer van het netwerk is – het hebben van een betrouwbaar gezamenlijk repository is vaak handig. Daarom heeft het hebben van een tussenliggend repository waarin je met iemand anders samenwerkt de voorkeur, en daaruit kun je dan pushen en pullen. We zullen dit repository de `Git server` noemen, maar je zult zien dat het over het algemeen maar een klein beetje systeembronnen kost om een Git repository te verzorgen, dus je zult er zelden een complete server voor nodig hebben.
+Op dit punt zou je alledaagse taken waarvoor je Git zult gebruiken kunnen doen. Maar, om samen te kunnen werken in Git zul je een remote repository moeten hebben. Technisch gezien kun je wijzigingen pushen en pullen van individuele repositories, maar dat wordt afgeraden, omdat je vrij gemakkelijk het werk waar anderen mee bezig zijn in de war kunt schoppen als je niet oppast. Daarnaast wil je dat je medewerkers de repository kunnen bereiken, zelfs als jouw computer van het netwerk is – het hebben van een betrouwbare gezamenlijke repository is vaak handig. De voorkeursmethode om met iemand samen te werken is om een tussenliggende repository in te richten waar beide partijen toegang to hebben en om daar naartoe te pushen en vandaan te pullen. We zullen deze repository de `Git server` noemen, maar je zult zien dat het over het algemeen maar een klein beetje systeembronnen kost om een Git repository te verzorgen, dus je zult er zelden een complete server voor nodig hebben.
 
-Een Git server draaien is eenvoudig. Als eerste kies je met welke protocollen je je server wilt laten communiceren. Het eerste gedeelte van dit hoofdstuk zullen we de beschikbare protocollen bespreken met de voor- en nadelen van elk. De volgende secties zullen veel voorkomende opstellingen bespreken, die van die protocollen gebruik maken hoe je je server ermee kunt opzetten. Als laatste laten we een paar servers van derden zien, als je het niet erg vindt om je code op iemands server te zetten en niet het gedoe wilt hebben van het opzetten en onderhouden van je eigen server.
+Een Git server draaien is eenvoudig. Als eerste kies je met welke protocollen je de server wilt laten communiceren. Het eerste gedeelte van dit hoofdstuk zullen we de beschikbare protocollen bespreken met de voor- en nadelen van elk. De daarop volgende paragrafen zullen we een aantal veel voorkomende opstellingen bespreken die van die protocollen gebruik maken en hoe je je server ermee kunt opzetten. Als laatste laten we een paar servers van derden zien, als je het niet erg vindt om je code op de server van een ander te zetten en niet het gedoe wilt hebben van het opzetten en onderhouden van je eigen server.
 
-Als je geen interesse hebt om je eigen server te draaien, dan kun je de rest overslaan en direct naar het laatste gedeelte van het hoofdstuk gaan om wat mogelijkheden van online accounts te zien en dan door te gaan naar het volgende hoofdstuk, waar we alle zaken bespreken die komen kijken bij het werken met een gedistribueerde versie beheer omgeving.
+Als je niet van plan bent om je eigen server te draaien, dan kun je de direct naar de laatste paragraaf van dit hoofdstuk gaan om wat mogelijkheden van online accounts te zien en dan door gaan naar het volgende hoofdstuk, waar we diverse zaken bespreken die komen kijken bij het werken met een gedistribueerde versiebeheer omgeving.
 
-Een remote repository is over het algemeen een _bare repository_ (kale repository) – een Git repository dat geen werkmap heeft. Omdat het repository alleen gebruikt wordt als een samenwerkingspunt, is er geen reden om een snapshot op de schijf te hebben; alleen de Git data. Een kale repository is eenvoudigweg de inhoud van de `.git` map in je project, en niets anders.
+Een remote repository is over het algemeen een _bare repository_ (kale repository) – een Git repository dat geen werkmap heeft. Omdat de repository alleen gebruikt wordt als een samenwerkingspunt, is er geen reden om een snapshot op de schijf te hebben; het is alleen de Git data. Een kale repository is eenvoudigweg de inhoud van de `.git` map in je project, en niets meer.
 
 ## De Protocollen ##
 
-Git kan vier veel voorkomende netwerk protocollen gebruiken om data te transporteren: Lokaal, Beveiligde Shell (SSH), Git en HTTP. Hier laten we zien wat het zijn, en in welke omstandigheden je ze wilt gebruiken (of juist niet).
+Git kan vier veel voorkomende netwerk protocollen gebruiken om data te transporteren: Lokaal, Beveiligde Shell (Secure Shell, SSH), Git en HTTP. Hier bespreken we wat deze zijn, en in welke omstandigheden je ze zou willen gebruiken (of juist niet).
 
-Het is belangrijk om te zien dat, met uitzondering van de HTTP protocollen, ze allemaal een werkende Git versie op de server geinstalleerd moeten hebben.
+Het is belangrijk om op te merken dat, met uitzondering van de HTTP protocollen, ze allemaal een werkende Git versie op de server geïnstalleerd moeten hebben.
 
 ### Lokaal Protocol ###
 
-Het meest basale is het _lokale protocol_, waarbij het remote repository in een andere map op de schijf is. Dit wordt vaak gebruikt als iedereen in je team toegang heeft op een gedeeld bestandssyteem zoals een NFS map, of in het weinig voorkomende geval dat iedereen in dezelfde computer werkt. Het laatste zou niet ideaal zijn, want dan zouden alle repositories zich op dezelfde computer bevinden, zodat de kans op een fataal verlies veel groter wordt.
+Het simpelste is het _Lokale protocol_, waarbij de remote repository in een andere directory op de schijf staat. Deze opzet wordt vaak gebruikt als iedereen in het team toegang heeft op een gedeeld bestandssyteem zoals een NFS mount, of in het weinig voorkomende geval dat iedereen op dezelfde computer werkt. Het laatste zou niet ideaal zijn, want dan zouden alle repositories op dezelfde computer staan, zodat een fataal verlies van gegevens veel groter wordt.
 
-Als je een gedeeld bestandssyteem hebt, dan kun je clonen, pushen en pullen van een op een lokaal bestand gebaseerde repository. Om een dergelijk repository te clonen, of om er een als een remote aan een bestaand project toe te voegen, moet je het pad naar het repository als URL gebruiken. Bijvoorbeeld, om een lokaal repository te clonen, kun je zoiets als dit uitvoeren:
+Als je een gedeeld bestandssyteem hebt, dan kun je clonen, pushen en pullen van een op een lokaal bestand aanwezige repository. Om een dergelijk repository te clonen, of om er een als een remote aan een bestaand project toe te voegen, moet je het pad naar het repository als URL gebruiken. Bijvoorbeeld, om een lokaal repository te clonen, kun je zoiets als het volgende uitvoeren:
 
 	$ git clone /opt/git/project.git
 
@@ -26,29 +26,29 @@ Of je kunt dit doen:
 
 	$ git clone file:///opt/git/project.git
 
-Git werkt iets anders als je explicite `file://` aan het begin van de URL zet. Als je alleen het pad specificeert, probeert Git hardlinks te gebruiken, of het kopieert de bestanden die het nodig heeft. Als je `file://` specificeert, dan start Git de processen die het normaal gebruikt om data te transporteren over een netwerk, wat over het algemeen een stuk minder efficiente methode is om data te transporteren. De reden om `file://` wel te specificeren is als je een schone kopie van de repository wilt met de extra referenties of objecten eruit gelaten – over het algemeen na een import van een ander versie beheer systeem of iets dergelijks (zie Hoofdstuk 9 voor onderhoudstaken). We zullen het normale pad hier gebruiken, omdat het bijna altijd sneller is om het zo te doen.
+Git werkt iets anders als je explicite `file://` aan het begin van de URL zet. Als je alleen het pad specificeert, probeert Git hardlinks te gebruiken, of het kopieert de bestanden die het nodig heeft. Als je `file://` specificeert, dan start Git de processen die het normaal gesproken gebruikt om data te transporteren over een netwerk, wat over het algemeen een minder efficiënte methode is om gegevens over te dragen. De belangrijkste reden om `file://` wel te specificeren is als je een schone kopie van de repository wilt met de vreemde refenties of objecten eruit gelaten – over het algemeen na een import uit een ander versiebeheer systeem of iets dergelijks (zie Hoofdstuk 9 voor onderhoudstaken). We zullen het normale pad hier gebruiken, omdat het bijna altijd sneller is om het zo te doen.
 
-Om een lokaal repository aan een bestaand Git project toe te voegen, kun je zoiets als dit uitvoeren:
+Om een lokale repository aan een bestaand Git project toe te voegen, kun je iets als het volgende uitvoeren:
 
 	$ git remote add local_proj /opt/git/project.git
 
-Daarna kun je pushen en pullen van dat remote alsof je over een netwerk werkt.
+Daarna kun je op gelijke wijze pushen naar, en pullen van die remote als je over een netwerk zou doen.
 
 #### De Voordelen ####
 
-De voordelen van bestands-gebaseerde repositories zijn dat ze eenvoudig zijn en ze maken gebruik van bestaande bestandspermissies en netwerk toegang. Als je al een gedeeld bestandssysteem hebt, waar je hele team al toegang tot heeft, dan is een repository opzetten heel gemakkelijk. Je stopt de kale repository ergens waar iedereen gedeelde toegang tot heeft, en stelt de lees- en schrijfrechten in zoals je dat bij iedere andere gedeelde map zou doen. In de volgende sectie "Git op een Server krijgen" bespreken we hoe je een kopie van een kale repository kunt exporteren voor dit doeleind.
+De voordelen van bestands-gebaseerde repositories zijn dat ze eenvoudig zijn en ze maken gebruik van bestaande bestandspermissies en netwerk toegang. Als je al een gedeeld bestandssysteem hebt, waar het hele team al toegang toe heeft, dan is een repository opzetten heel gemakkelijk. Je stopt de kale repository ergens waar iedereen gedeelde toegang tot heeft, en stelt de lees- en schrijfrechten in zoals je dat bij iedere andere gedeelde directory zou doen. In de volgende paragraaf "Git op een Server Krijgen" bespreken we hoe je een kopie van een kale repository kunt exporteren voor dit doeleinde.
 
-Dit is ook een fijne optie om snel werk van een repository van iemand anders te pakken. Als jij en een collega aan hetzelfde project aan het werk zijn, en hij wil dat je iets bekijkt, dan is het uitvoeren van een commando zoals `git pull /home/john/project` vaak makkelijker dan dat hij naar een remote server moet pushen, en jij er van moet pullen.
+Dit is ook een prettige optie om snel werk uit een repository van iemand anders te pakken. Als jij en een collega aan hetzelfde project werken, en hij wil dat je iets bekijkt, dan is het uitvoeren van een commando zoals `git pull /home/john/project` vaak makkelijker dan dat hij naar een remote server moet pushen, en jij er van moet pullen.
 
 #### De Nadelen ####
 
-Een van de nadelen van deze methode is dat gedeelde toegang over het algemeen moeilijker op te zetten en te bereiken is vanaf meerdere lokaties dan basaal netwerk toegang. Als je wilt pushen van je laptop als je thuis bent, dan moet je de remote schijf aankoppelen, wat moeilijk en langzaam kan zijn in vergelijking tot netwerk gebaseerde toegang.
+Een van de nadelen van deze methode is dat gedeelde toegang over het algemeen moeilijker op te zetten en te bereiken is vanaf meerdere lokaties dan simpele netwerk toegang. Als je wilt pushen van je laptop als je thuis bent, dan moet je de remote schijf aankoppelen, wat moeilijk en langzaam kan zijn als je het vergelijkt met netwerk gebaseerde toegang.
 
-Het is ook belangrijk om te melden dat het niet noodzakelijk de snelste optie is, als je een gedeeld koppelpunt of iets dergelijks gebruikt. Een lokale repository is alleen snel als je snelle toegang tot de data hebt. Een repository op NFS is vaak langzamer dan het repository via SSH op dezelfde server, wat Git toelaat om vanaf lokale schijven te werken op ieder systeem.
+Het is ook belangrijk om te vermelden dat het niet altijd de snelste optie is, als je een gedeeld koppelpunt (mount) of iets dergelijks gebruikt. Een lokale repository is alleen snel als je snelle toegang tot de data hebt. Een repository op NFS is vaak langzamer dan een repository via SSH op dezelfde server omdat dit Git in staat stelt om op lokale schijven te werken op elk van de betrokken systemen.
 
 ### Het SSH Protocol ###
 
-Waarschijnlijk het meest voorkomende protocol voor Git is SSH. Dit is omdat SSH toegang tot servers in veel plaatsen al geconfigureerd is – en als dat niet het geval is, dan is het makkelijk om dat te doen. SSH is ook het enige netwerk gebaseerde protocol waarvan je makkelijk kunt lezen en naartoe kunt schrijven. De andere twee netwerk protocollen (HTTP en Git) zijn over het algemeen alleen-lezen, dus zelfs als je ze al beschikbaar hebt voor de ongeinitieerden, dan heb je nog steeds SSH nodig voor je eigen schrijftoegang. SSH is ook een geverifieerd protocol; en omdat het overal voorkomt, is het over het algemeen eenvoudig om in te stellen en te gebruiken.
+Waarschijnlijk het meest voorkomende protocol voor Git is SSH. De reden hiervoor is dat toegang met SSH tot servers in veel plaatsen al geconfigureerd is – en als dat niet het geval is, dan is het eenvoudig om dat te doen. SSH is ook het enige netwerk gebaseerde protocol waarvan je makkelijk kunt lezen en naartoe kunt schrijven. De andere twee netwerk protocollen (HTTP en Git) zijn over het algemeen alleen-lezen, dus zelfs als je ze al beschikbaar hebt voor de ongeïnitieerde massas, dan heb je nog steeds SSH nodig voor je eigen schrijfcommandos. SSH is ook een geauthenticieerd protocol; en omdat het alom aanwezig is, is het over het algemeen eenvoudig om in te stellen en te gebruiken.
 
 Om een Git repository via SSH te clonen, kun je een ssh:// URL opgeven zoals:
 
@@ -58,32 +58,32 @@ Of je geeft geen protocol op – Git gaat uit van SSH als je niet expliciet bent
 	
 	$ git clone user@server:project.git
 
-Je kunt ook de gebruiker niet opgeven, en Git neemt aan dat je de gebruiker bedoelt waarmee je op het moment bent ingelogged.
+Je kunt ook de gebruiker weglaten, en Git gebruikt gegevens van de gebruiker waarmee je op dat moment bent ingelogd.
 
 #### De Voordelen ####
 
-Er zijn vele voordelen om SSH te gebruiken. De eerste is dat je het eigenlijk wel moet gebruiken als je geverifieerde schrijftoegang op je repository via een netwerk wilt. Het tweede is dat het relatief eenvoudig in te stellen is – SSH daemons komen veel voor, veel systeembeheerders hebben er ervaring mee, en veel operating systemen zijn er mee uitgerust of hebben applicaties om ze te beheren. Daarnaast is toegang via SSH veilig – alle data transporten zijn versleuteld en geverifieerd. En als laatste is SSH efficient, zoals het Git en lokale protocol, waarbij de data zo compact mogelijk wordt gemaakt voordat het getransporteerd wordt.
+Er zijn vele voordelen om SSH te gebruiken. Ten eerste moet je het eigenlijk wel gebruiken als je geauthenticeerde schrijftoegang op je repository via een netwerk wilt. Ten tweede is het relatief eenvoudig in te stellen – SSH daemons komen veel voor, veel systeembeheerders hebben er ervaring mee, en veel operating systemen zijn er mee uitgerust of hebben applicaties om ze te beheren. Daarnaast is toegang via SSH veilig – alle data transporten zijn versleuteld en geauthenticeerd. En als laatste is SSH efficiënt, net zoals het Git en lokale protocol, de gegevens worden zo compact mogelijk gemaakt voordat het getransporteerd wordt.
 
 #### De Nadelen ####
 
-Het negatieve aspect van SSH is dat je er geen anonieme toegang over kunt geven. Mensen moeten via SSH toegang hebben om er gebruik van te kunnen maken, zelfs als het alleen lezen is, zodat SSH toegang niet bevordelijk is voor open source projecten. Als je het alleen binnen je bedrijfsnetwerk gebruikt, dan kan SSH misschien het enige protocol zijn waar je mee in aanraking komt. Als je anonieme alleen-lezen toegang wilt toestaan tot je projecten, dan moet je SSH voor jezelf instellen om over te pushen, maar iets anders voor anderen om over te pullen.
+Het negatieve aspect van SSH is dat je er geen anonieme toegang naar je repository over kunt geven. Mensen moeten via SSH toegang hebben om er gebruik van te kunnen maken, zelfs als het alleen lezen is, zodat SSH toegang niet bevordelijk is voor open source projecten. Als je het alleen binnen je bedrijfsnetwerk gebruikt, dan is SSH misschien het enige protocol waar je mee in aanraking komt. Als je anonieme alleen-lezen toegang wilt toestaan tot je projecten, dan moet je SSH voor jezelf instellen om over te pushen, maar iets anders voor anderen om over te pullen.
 
 ### Het Git Protocol ###
 
-Het volgende is het Git protocol. Dit is een aparte daemon, die samen met Git geleverd wordt; het luistert op een toegewezen poort (9418), dat een vergelijkbare dienst verleend als het SSH protocol, maar dan zonder enige verificatie. Om een repository te serveren over het Git protocol, moet je het `git-export-daemon-ok` bestand aanmaken – de daemon zal een repository zonder dit bestand erin niet serveren – maar buiten dat is er geen beveiliging. Ofwel het Git repository is er om gecloned te kunnen worden door iedereen, of het is er helemaal niet. Dit betekent dat er over het algemeen geen pushing is via dit protocol. Je kunt push toegang aanzetten; maar gegeven het gebrek aan verificatie als je push toegang aan zet, kan iedereen die de URL van jouw project op het internet vindt, pushen naar jouw project. We volstaan met te zeggen dat dit zeldzaam is.
+Het volgende is het Git protocol. Dit is een specifieke daemon, die met Git meegeleverd wordt; het luistert op een toegewezen poort (9418), en verleent een vergelijkbare dienst als het SSH protocol, maar dan zonder enige vorm van authenticatie. Om een repository beschikbaar te stellen over het Git protocol, moet je een `git-export-daemon-ok` bestand aanmaken – de daemon zal een repository zonder dit bestand erin niet verspreiden – maar daarbuiten is er geen beveiliging. De Git repository beschikbaar om gecloned te kunnen worden door iedereen, of het is het niet. Dit betekent dat er over het algemeen geen pushing is via dit protocol. Je kunt push toegang aanzetten, maar gegeven het gebrek aan authenticatie kan als je de push toegang aan zet iedereen die de URL van jouw project op het internet vindt, pushen naar jouw project. We volstaan met te zeggen dat dit zelden de bedoeling kan zijn.
 
 #### De Voordelen ####
 
-Het Git protocol is het snelste dat beschikbaar is. Als je veel verkeer serveert voor een publiek project, of een zeer groot project dat geen gebruikersverificatie nodig heeft voor leestoegang, dan is het waarschijnlijk dat je een Git daemon wilt instellen om je project te serveren. Het maakt van hetzelfde data-transport mechanisme gebruik als het SSH protocol, maar dan zonder de extra belasting van versleuteling en verificatie.
+Het Git protocol is het snelste dat beschikbaar is. Als je veel verkeer verwerkt voor een publiek project, of een zeer groot project dat geen gebruikersauthenticatie nodig heeft voor leestoegang, dan is het waarschijnlijk dat je een Git daemon wilt inrichten om je project te verspreiden. Het maakt van hetzelfde data-transport mechanisme gebruik als het SSH protocol, maar dan zonder de extra belasting van versleuteling en authenticatie.
 
 #### De Nadelen ####
 
-Het nadeel van het Git protocol is het gebrek van verificatie. Het is over het algemeen onwenselijk dat het Git protocol de enige toegang tot je project is. Over het algemeen zul je het samen met SSH toegang gebruiken voor de paar ontwikkelaars die push (schrijf-)toegang hebben en de rest laat je `git://` voor alleen leestoegang gebruiken.
-Het is waarschijnlijk ook het meest ingewikkelde protocol om in te stellen. Het moet een eigen daemon hebben, die speciaal ontworpen is – we zullen er een instellen in het "Gitosis" gedeelte van dit hoofdstuk – het gebruikt `xinetd` configuratie of iets dergelijks, wat niet altijd eenvoudig is. Het heeft ook firewall toegang tot poort 9418 nodig, wat geen standaard poort is dat bedrijfsfirewalls altijd toestaan. Achter grote bedrijfsfirewalls, is deze obscure poort meestal geblokkeerd.
+Het nadeel van het Git protocol is het gebrek aan authenticatie. Het is over het algemeen onwenselijk dat het Git protocol de enige toegang tot je project is. Meestal zul je het samen met SSH toegang gebruiken voor de paar ontwikkelaars die push (schrijf-)toegang hebben en de rest laat je `git://` voor alleen leestoegang gebruiken.
+Het is waarschijnlijk ook het meest ingewikkelde protocol om in te richten. Het moet een eigen daemon hebben, die speciaal voor die situatie ingericht is – we zullen er een instellen in het "Gitosis" gedeelte van dit hoofdstuk – het gebruikt `xinetd` configuratie of iets vergelijkbaars, wat ook niet altijd eenvoudig is op te zetten. Daarbij is ook firewall toegang tot poort 9418 nodig, wat geen standaard poort is dat in bedrijfsfirewalls is opengezet. Bij firewalls van grote bedrijven, is deze ongebruikelijke poort meestal dichtgezet.
 
 ### Het HTTP/S Protocol ###
 
-Als laatste hebben we het HTTP protocol. Het mooie aan het HTTP of HTTPS protocol is dat het simpel in te stellen is. Eigenlijk is alles wat je moet doen de kale Git repository in je HTTP document root zetten, en een specifieke `post-update` hook (haak) instellen en je bent klaar (zie hoofdstuk 7 voor details over Git hooks). Vanaf dat moment kan iedereen die toegang heeft tot de webserver waaronder je de repository gezet hebt ook je repository clonen. Om leestoegang tot je repository over HTTP toe te staan, doe je zoiets als het volgende:
+Als laatste hebben we het HTTP protocol. Het mooie aan het HTTP of HTTPS protocol is dat het simpel in te stellen is. Eigenlijk is alles wat je moet doen de kale Git repository in je HTTP document root zetten, en een specifieke `post-update` hook (haak) instellen en je bent klaar (zie hoofdstuk 7 voor details over Git hooks). Vanaf dat moment kan iedereen die toegang heeft tot de webserver waar je de repository op gezet hebt ook je repository clonen. Om leestoegang tot je repository over HTTP toe te staan, doe je zoiets als het volgende:
 
 	$ cd /var/www/htdocs/
 	$ git clone --bare /path/to/git_project gitproject.git
@@ -91,30 +91,30 @@ Als laatste hebben we het HTTP protocol. Het mooie aan het HTTP of HTTPS protoco
 	$ mv hooks/post-update.sample hooks/post-update
 	$ chmod a+x hooks/post-update
 
-Dat is alles. De `post-update` hook, die standaard bij Git zit, voert het noodzakelijke commando uit (`git update-server-info`) om HTTP fetching en cloning goed werkend te krijgen. Dit commando wordt uitgevoerd als je naar dit repository via SSH pushed; en dan kunnen andere mensen clonen met behulp van zoiets als
+Dat is alles. De `post-update` hook, die standaard bij Git geleverd wordt, voert het noodzakelijke commando uit (`git update-server-info`) om HTTP fetching en cloning goed werkend te krijgen en houden. Dit commando wordt uitgevoerd als je via SSH naar deze repository pushed; en andere mensen kunnen clonen met behulp van zoiets als
 
 	$ git clone http://example.com/gitproject.git
 
-In dit geval, gebruiken we het `/var/www/htdocs` pad wat gebruikelijk is voor Apache opstellingen, maar je kunt iedere statische webserver gebruiken – stop de kale repository in haar pad. De Git data wordt geserveerd als standaard statische bestanden (zie hoofdstuk 9 voor details over hoe het precies geserveerd wordt).
+In dit specifieke voorbeeld gebruiken we het `/var/www/htdocs` pad wat gebruikelijk is voor Apache opstellingen, maar je kunt iedere statische webserver gebruiken – stop de kale repository in het betreffende pad. De Git data wordt geserveerd als standaard statische bestanden (zie hoofdstuk 9 voor details over hoe het precies geserveerd wordt).
 
-Het ook is mogelijk om Git over HTTP te laten pushen, alhoewel dat geen veelgebruikte techniek is en erom vraagt dat je complexe WebDAV vereisten insteld. Omdat het zelden gebruikt wordt, zullen we het niet in dit boek beschrijven. Als je geinteresseerd bent om de HTTP-push protocollen te gebruiken, dan kun je op `http://www.kernel.org/pub/software/scm/git/docs/howto/setup-git-server-over-http.txt` lezen hoe je een repository kunt maken. Een fijn ding aan Git laten pushen over HTTP is dat je iedere WebDAV server kunt gebruiken, zonder specifieke Git eigenschappen; dus je kunt deze functionaliteit gebruiken als je web-hosting provider WebDAV ondersteunt voor schrijf vernieuwingen aan je webpagina.
+Het is mogelijk om Git ook over HTTP te laten pushen, alhoewel dat geen veelgebruikte techniek is en het vraagt dat je complexe WebDAV instellingen inricht. Omdat het zelden gebruikt wordt, zullen we het niet in dit boek beschrijven. Als je geïnteresseerd bent om de HTTP-push protocollen te gebruiken, dan kun je op `http://www.kernel.org/pub/software/scm/git/docs/howto/setup-git-server-over-http.txt` lezen hoe je een repository kunt maken. Het aardige van Git laten pushen over HTTP is dat je iedere WebDAV server kunt gebruiken, zonder specifieke Git funtionaliteit, dus je kunt deze functionaliteit gebruiken als je web-hosting provider WebDAV ondersteunt voor het maken van wijzigingen aan je webpagina.
 
 #### De Voordelen ####
 
-Het voordeel van het gebruik van het HTTP protocol is dat het eenvoudig in te stellen is. Een handvol benodigde commando's uitvoeren zorgt voor een eenvoudige manier om de wereld leestoegang te geven aan je Git repository. Het kost slechts een paar minuten om te doen. Het HTTP protocol is niet erg belastend voor de systeembronnen van je server. Omdat het over het algemeen een statische webserver gebruikt om alle data te serveren, een normale Apache server kan gemiddeld duizenden bestanden serveren per seconde – is het moeilijk om zelfs een kleine server te overbelasten.
+Het voordeel van het gebruik van het HTTP protocol is dat het eenvoudig in te stellen is. Een handvol benodigde commando's uitvoeren is alles wat er moet gebeuren om de wereld leestoegang te geven tot je Git repository. Het neemt maar een paar minuten van je tijd. Het HTTP protocol is niet erg belastend voor de systeembronnen van je server. Omdat het over het algemeen een statische webserver gebruikt om alle data te verspreiden - een normale Apache server kan gemiddeld duizenden bestanden zenden per seconde - is het moeilijk om zelfs een kleine server te overbelasten.
 
-Je kunt ook je repositories alleen-lezen serveren via HTTPS, wat betekend dat je het transport kunt versleutelen; of je kunt zelfs zover gaan dat je clients een specifiek gesigneerd SSL certificaat moeten gebruiken. Als je over het algemeen zo ver gaat, dan is het makkelijker om publieke SSH sleutels te gebruiken; maar het kan een betere oplossing in jouw specifieke geval om gesigneerde SSL certificaten of andere HTTP-gebaseerde verificatie methoden te gebruiken voor alleen-lezen toegang via HTTPS.
+Je kunt ook je repositories alleen-lezen serveren via HTTPS, wat inhoudt dat je het transport kunt versleutelen; je kunt zelfs zover gaan dat je clients een specifiek gesigneerd SSL certificaat laat gebruiken. Normaal gesproken als je je deze moeite wilt getroosten, dan is het makkelijker om publieke SSH sleutels te gebruiken; maar het kan in jouw specifieke geval een betere oplossing zijn om gesigneerde SSL certificaten of andere HTTP-gebaseerde authenticatie methoden te gebruiken voor alleen-lezen toegang via HTTPS.
 
-Een ander fijn ding is dat HTTP zo'n veel voorkomend protocol is dat bedrijfsfirewalls vaak zo ingesteld zijn dat ze verkeerd via deze poort toelaten.
+Een andere prettige bijkomstigheid is dat HTTP een dusdanig veel voorkomend protocol is dat bedrijfsfirewalls vaak zo ingesteld zijn dat ze verkeer via deze poort toestaan.
 
 #### De Nadelen ####
 
-Het nadeel van je repository serveren via HTTP is dat het relatief inefficient voor de client is. Over het algemeen duurt het een stuk langer om te clonen en te fetchen van de repository, en je hebt vaak een stuk meer netwerk belasting en transport volume via HTTP dan met elk van de andere netwerk protocollen. Omdat het niet zo ingewikkeld is om alleen de data te versturen die je nodig hebt – er wordt geen dynamisch werk door de server gedaan in deze transacties – wordt vaak naar het HTTP protocol gerefereerd als zijnde een _dom_ protocol. Voor meer informatie over de verschillen in efficientie tussen het HTTP protocol en andere protocollen, zie Hoofdstuk 9.
+Het nadeel van je repository verspreiden via HTTP is dat het relatief inefficiënt voor de client is. Over het algemeen duurt het een stuk langer om te clonen en te fetchen van de repository, en je hebt vaak een veel hogere netwerk belasting en transport volume via HTTP dan met elk van de andere netwerk protocollen. Omdat het niet zo ingewikkeld is om alleen de data te versturen die je nodig hebt – er wordt geen dynamisch werk door de server gedaan in deze uitwisselingen – wordt vaak naar het HTTP protocol gerefereerd als zijnde een _dom_ protocol. Voor meer informatie over de verschillen in efficiëntie tussen het HTTP protocol en andere protocollen, zie Hoofdstuk 9.
 
 ## Git op een Server Krijgen ##
 
-Om een initiele Git server op te zetten, moet je een bestaande repository in een kale repository exporteren – een repository dat geen werkmap bevat. Dit is over het algemeen eenvoudig te doen.
-Om je repository te clonen met als doel het maken van een kale repository, voer je het clone commando uit met de `--bare` optie. Als vaste gewoonte eindigen de namen van kale repository mappen in `.git`, zoals:
+Om een Git server initieel op te zetten, moet je een bestaande repository naar een kale repository exporteren – een repository dat geen werkmap bevat. Dit is over het algemeen eenvoudig te doen.
+Om je repository te clonen met als doel het maken van een kale repository, voer je het clone commando uit met de `--bare` optie. Als conventie eindigen de namen van kale repository mappen met `.git`, zoals:
 
 	$ git clone --bare my_project my_project.git
 	Initialized empty Git repository in /opt/projects/my_project.git/
@@ -125,29 +125,29 @@ Dit is ongeveer gelijk aan
 
 	$ cp -Rf my_project/.git my_project.git
 
-Er zijn een paar kleine verschillen in het configuratie bestand; maar voor jouw doeleinde ligt dit dicht bij hetzelfde. Het neemt de Git repository zelf, zonder een werkmap, en maakt een map aan specifiek alleen voor dat ding.
+Er zijn een paar kleine verschillen in het configuratie bestand, maar het komt op hetzelfde neer. Het neemt de Git repository zelf, zonder een werkmap, en maakt een map aan specifiek hiervoor.
 
-### Het Bare Repository op een Server Zetten ###
+### De Kale Repository op een Server Zetten ###
 
-Nu dat je een kale kopie van je repository hebt, is het enige dat je moet doen het op een server zetten en je protocollen instellen. Stel dat je een server ingesteld hebt, die `git.example.com` heet, waar je SSH toegang op hebt, en waar je al je Git repositories wilt opslaan onder de `/opt/git` map. Je kunt je nieuwe repository instellen door je kale repository ernaartoe te kopieeren:
+Nu je een kale kopie van je repository hebt, is het enige dat je moet doen het op een server zetten en je protocollen instellen. Laten we aannemen dat je een server ingericht hebt, die `git.example.com` heet, waar je SSH toegang op hebt, en waar je al je Git repositories wilt opslaan onder de `/opt/git` map. Je kunt je nieuwe repository beschikbaar stellen door je kale repository ernaartoe te kopiëren:
 
 	$ scp -r my_project.git user@git.example.com:/opt/git
 
-Op dit punt kunnen andere gebruikers, die SSH toegang hebben tot dezelfde server en lees-toegang hebben tot de `/opt/git` map, jouw repository clonen door dit uit te voeren:
+Vanaf dat moment kunnen andere gebruikers, die SSH toegang hebben tot dezelfde server en lees-toegang hebben tot de `/opt/git` map, jouw repository clonen door dit uit te voeren:
 
 	$ git clone user@git.example.com:/opt/git/my_project.git
 
-Als een gebruiker in een server SSH-ed en schrijftoegang heeft tot de `/opt/git/my_project.git` map, dan hebben ze automatisch ook push toegang. Git zal automatisch correcte groep schrijfrechten aan een repository toevoegen als je het `git init` commando met de `--shared` optie uitvoert.
+Als een gebruiker met SSH op een server inlogt en schrijftoegang heeft tot de `/opt/git/my_project.git` map, dan hebben ze automatisch ook push toegang. Git zal automatisch de correcte groep schrijfrechten aan een repository toekennen als je het `git init` commando met de `--shared` optie uitvoert.
 
 	$ ssh user@git.example.com
 	$ cd /opt/git/my_project.git
 	$ git init --bare --shared
 
-Je ziet hoe eenvoudig het is om een Git repository te nemen, een kale versie aan te maken, en het op een server plaatsen waar jij en je medewerkers SSH toegang tot hebben. Nu ben je klaar om aan hetzelfde project samen te werken.
+Je ziet hoe eenvoudig het is om een Git repository te nemen, een kale versie aan te maken, en het op een server plaatsen waar jij en je medewerkers SSH toegang tot hebben. Nu zijn jullie klaar om aan hetzelfde project samen te werken.
 
-Het is belangrijk om te zien dat dit letterlijk alles is wat je moet doen om een bruikbare Git server te draaien waarop meerdere mensen toegang hebben – voeg alleen een paar SSH accounts toe op een server, en stop een kale repository ergens waar al die gebruikers lees- en schrijftoegang tot hebben. Je bent er klaar voor – je hebt niets anders nodig.
+Het is belangrijk om op te merken dat dit letterlijk alles is wat je moet doen om een bruikbare Git server te draaien waarop meerdere mensen toegang hebben – maak alleen een paar accounts met SSH toegang aan op een server, en stop een kale repository ergens waar al die gebruikers lees- en schrijftoegang toe hebben. Je bent er klaar voor – je hebt niets anders nodig.
 
-In de volgende secties zul je zien hoe je meer ingewikkelde opstellingen kunt maken. Deze bespreking zal het niet hoeven aanmaken van gebruikers accounts voor elke gebruiker, publieke leestoegang tot repositories, grafische web interfaces, de Gitosis applicatie gebruiken en meer omvatten. Maar, hou in gedachten dat om samen te kunnen werken met mensen op een prive project, alles wat je _nodig_ hebt is een SSH server en een kale repository.
+In de volgende paragrafen zul je zien hoe je meer ingewikkelde opstellingen kunt maken. Deze bespreking zal het niet hoeven aanmaken van gebruikers accounts voor elke gebruiker, publieke leestoegang tot repositories, grafische web interfaces, het gebruik van de Gitosis applicatie en meer omvatten. Maar, hou in gedachten dat om samen te kunnen werken met mensen op een privé project, alles wat je _nodig_ hebt een SSH server is en een kale repository.
 
 ### Kleine Opstellingen ###
 
@@ -155,27 +155,26 @@ Als je met een kleine groep bent of net begint met Git in je organisatie en slec
 
 #### SSH Toegang ####
 
-Als je reeds een server hebt waar al je ontwikkelaars SSH toegang op hebben, dan is het over het algemeen het gemakkelijkst om je eerste repository daar in te stellen, omdat je dan bijna niets hoeft te doen (zoals beschreven in de vorige sectie). Als je meer complexe toegangscontrole wilt op je repositories, dan kun je ze instellen met de normale bestandssysteem permissies van het operating systeem dat op je server draait.
+Als je al een server hebt waar al je ontwikkelaars SSH toegang op hebben, dan is het over het algemeen het eenvoudigste om je eerste repository daar op te zetten, omdat je dan bijna niets hoeft te doen (zoals beschreven in de vorige paragraaf). Als je meer complexe toegangscontrole wilt op je repositories, dan kun je ze instellen met de normale bestandssysteem permissies van het operating systeem dat op je server draait.
 
-Als je je repositories op een server wilt zetten, die geen accounts heeft voor iedereen in je team die je schrijftoegang wilt geven, dan moet je SSH toegang voor ze instellen. We gaan er vanuit dat je een server hebt waarmee je dit kunt doen, je reeds een SSH server geinstalleerd hebt, en dat de manier is waarop je toegang hebt tot de server.
+Als je je repositories op een server wilt zetten, die geen accounts heeft voor iedereen in je team die je schrijftoegang wilt geven, dan moet je SSH toegang voor ze opzetten. We gaan er vanuit dat je een server hebt waarmee je dit kunt doen, dat je reeds een SSH server geïnstalleerd hebt, en dat de manier is waarop je toegang hebt tot de server.
 
-Er zijn een paar manieren waarop je iedereen in je team toegang kunt geven. De eerste is voor iedereen accounts aanmaken, wat rechttoe rechtaan is maar omslachtig kan zijn. Je wilt misschien niet `adduser` uitvoeren en tijdelijke wachtwoorden voor iedere gebruiker instellen.
+Er zijn een paar manieren waarop je iedereen in je team toegang kunt geven. De eerste is voor iedereen accounts aanmaken, wat rechttoe rechtaan is maar bewerkelijk kan zijn. Je wilt vermoedelijk niet `adduser` uitvoeren en tijdelijke wachtwoorden instellen voor iedere gebruiker.
 
-Een tweede methode is een 'git' gebruiker aanmaken op de machine, aan iedere gebruiker die schijftoegang moet hebben vragen of ze je een publieke SSH sleutel sturen, en die sleutel toevoegen aan het `~/.ssh/authorized_keys` bestand van je nieuwe 'git' gebruiker. Vanaf dat punt zal iedereen toegang hebben op die machine via de 'git' gebruiker. Dit tast de commit data op geen enkele manier aan – de SSH gebruiker waarmee je inlogged zal de commits die je opgeslagen hebt niet beinvloeden.
+Een tweede methode is een generieke 'git' gebruiker aan te maken op de machine, aan iedere gebruiker die schijftoegang moet hebben vragen of ze je een publieke SSH sleutel sturen, en die sleutel toevoegen aan het `~/.ssh/authorized_keys` bestand van die nieuwe 'git' gebruiker. Vanaf dat moment zal iedereen toegang hebben op die machine via de 'git' gebruiker. Dit tast de commit data op geen enkele manier aan – de SSH gebruiker waarmee je inlogt zal de commits die je opgeslagen hebt niet beïnvloeden.
 
-Een andere manier waarop je het kunt doen is je SSH server laten verifieren vanaf een LDAP server of een andere gecentraliseerde verificatie bron, die je misschien al ingesteld hebt. Zolang iedere gebruiker een shell toegang heeft op de machine, zou ieder SSH verificatie mechanisme dat je kunt bedenken moeten werken.
+Een andere manier waarop je het kunt doen is je SSH server laten authenticeren middels een LDAP server of een andere gecentraliseerde authenticatie bron, die misschien al ingericht is. Zolang iedere gebruiker shell toegang kan krijgen op de machine, zou ieder SSH authenticatie mechanisme dat je kunt bedenken moeten werken.
 
 ## Je Publieke SSH Sleutel Genereren ##
 
-Dat gezegd hebbende, zijn er vele Git servers die verifieren met een publieke SSH sleutel. Om een publieke sleutel te hebben, zal iedere gebruiker in je systeem er een moeten genereren als ze er nog geen hebben. Dit proces is bij alle operating systemen vergelijkbaar.
-Als eerste moet je controleren dat je er niet al een hebt. Standaard staan de SSH sleutels van de gebruikers in hun eigen `~/.ssh` map. Je kunt makkelijk nagaan of je al een sleutel hebt door naar die map te gaan en de inhoud te tonen:
+Dat gezegd hebbende, zijn er vele Git servers die authenticeren met een publieke SSH sleutel. Om een publieke sleutel te hebben, zal iedere gebruiker in je systeem er een moeten genereren als ze er nog geen hebben. Dit proces is bij alle operating systemen vergelijkbaar. Als eerste moet je controleren of je er niet al een hebt. Standaard staan de SSH sleutels van de gebruikers in hun eigen `~/.ssh` map. Je kunt makkelijk nagaan of je al een sleutel hebt door naar die map te gaan en de inhoud te bekijken:
 
 	$ cd ~/.ssh
 	$ ls
 	authorized_keys2  id_dsa       known_hosts
 	config            id_dsa.pub
 
-Je bent op zoek naar een aantal bestanden genaamd iets en iets.pub, waarbij het `iets` meestal zoiets is als `id_dsa` of `id_rsa`. Het `.pub` bestand is je publieke sleutel en het andere bestand is je private sleutel. Als je deze bestanden niet hebt (of als je zelfs geen `.ssh` map hebt), dan kun je ze aanmaken door een applicatie genaamd `ssh-keygen` uit te voeren, wat meegeleverd wordt met het SSH pakket op Linux/Mac systemen en meegeleverd wordt met het MSysGit pakket op Windows:
+Je bent op zoek naar een aantal bestanden genaamd iets en iets.pub, waarbij het `iets` meestal zoiets is als `id_dsa` of `id_rsa`. Het `.pub` bestand is je publieke sleutel en het andere bestand is je private sleutel. Als je deze bestanden niet hebt (of als je zelfs geen `.ssh` map hebt), dan kun je ze aanmaken door een applicatie genaamd `ssh-keygen` uit te voeren, deze wordt met het SSH pakket op Linux/Mac systemen meegeleverd en met het MSysGit pakket op Windows:
 
 	$ ssh-keygen 
 	Generating public/private rsa key pair.
@@ -187,9 +186,9 @@ Je bent op zoek naar een aantal bestanden genaamd iets en iets.pub, waarbij het
 	The key fingerprint is:
 	43:c5:5b:5f:b1:f1:50:43:ad:20:a6:92:6a:1f:9a:3a schacon@agadorlaptop.local
 
-Eerst bevestigt het de lokatie waar je de sleutel wilt opslaan (`.ssh/id_rsa`), en vervolgens vraagt het tweemaal om een wachtzin, die je leeg kunt laten als je geen wachtwoord wilt intypen op het moment dat je de sleutel gebruikt.
+Eerst wordt de lokatie waar je de sleutel wordt opgeslagen (`.ssh/id_rsa`) aangegeven, en vervolgens vraagt het tweemaal om een wachtwoord, die je leeg kunt laten als je geen wachtwoord wilt intypen op het moment dat je de sleutel gebruikt.
 
-Iedere gebruiker die dit doet, moet zijn sleutel sturen naar jou of degene die de Git server beheert (aangenomen dat je een SSH server gebruikt die publieke sleutels vereist). Het enige dat ze hoeven doen is de inhoud van het `.pub` bestand kopieeren en e-mailen. De publieke sleutel ziet er ongeveer zo uit:
+Iedere gebruiker die dit doet, moet zijn sleutel sturen naar jou of degene die de Git server beheert (aangenomen dat je een SSH server gebruikt die publieke sleutels vereist). Het enige dat ze hoeven doen is de inhoud van het `.pub` bestand kopiëren en e-mailen. De publieke sleutel ziet er ongeveer zo uit:
 
 	$ cat ~/.ssh/id_rsa.pub 
 	ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAklOUpkDHrfHY17SbrmTIpNLTGK9Tjom/BWDSU
@@ -199,18 +198,18 @@ Iedere gebruiker die dit doet, moet zijn sleutel sturen naar jou of degene die d
 	mZ+AW4OZPnTPI89ZPmVMLuayrD2cE86Z/il8b+gw3r3+1nKatmIkjn2so1d01QraTlMqVSsbx
 	NrRFi9wrf+M7Q== schacon@agadorlaptop.local
 
-Voor een uitgebreide tutorial over het aanmaken van een SSH sleutel op meerdere operating systemen, zie de GitHub handleiding over SSH sleutels op `http://github.com/guides/providing-your-ssh-key`.
+Voor een uitgebreide tutorial over het aanmaken van een SSH sleutel op meerdere operating systemen, verwijzen ze je naar de GitHub handleiding over SSH sleutels op `http://github.com/guides/providing-your-ssh-key`.
 
-## De Server Instellen ##
+## De Server Opzetten ##
 
-Laten we het instellen van SSH toegang aan de server kant eens doorlopen. In dit voorbeeld zul je de `authorized_keys` methode gebruiken om je gebruikers te verifieren. We gaan er ook vanuit dat je een standaard Linux distributie gebruikt zoals Ubuntu. Als eerste creeer je een 'git' gebruiker een een `.ssh` map voor die gebruiker.
+Laten we het opzetten van SSH toegang aan de server kant eens doorlopen. In dit voorbeeld zul je de `authorized_keys` methode gebruiken om je gebruikers te authenticeren. We gaan er ook vanuit dat je een standaard Linux distributie gebruikt zoals Ubuntu. Als eerste maak je een 'git' gebruiker aan en een `.ssh` map voor die gebruiker.
 
 	$ sudo adduser git
 	$ su git
 	$ cd
 	$ mkdir .ssh
 
-Daarna moet je een aantal publieke SSH sleutels van ontwikkelaars aan het `authorized_keys` bestand toevoegen voor die gebruiker. Laten we aannemen dat je een aantal sleutels per e-mail ontvangen hebt en ze hebt opgeslagen in tijdelijke bestanden. Nogmaals, de sleutels zien er ongeveer zo uit:
+Vervolgens moet je een aantal publieke SSH sleutels van ontwikkelaars aan het `authorized_keys` bestand toevoegen voor die gebruiker. Laten we aannemen dat je een aantal sleutels per e-mail ontvangen hebt en ze hebt opgeslagen in tijdelijke bestanden. Nogmaals, de sleutels zien er ongeveer zo uit:
 
 	$ cat /tmp/id_rsa.john.pub
 	ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCB007n/ww+ouN4gSLKssMxXnBOvf9LGt4L
@@ -220,20 +219,20 @@ Daarna moet je een aantal publieke SSH sleutels van ontwikkelaars aan het `autho
 	O7TCUSBdLQlgMVOFq1I2uPWQOkOWQAHukEOmfjy2jctxSDBQ220ymjaNsHT4kgtZg2AYYgPq
 	dAv8JggJICUvax2T9va5 gsg-keypair
 
-Je voegt ze slechts toe aan je `authorized_keys` bestand:
+Je voegt ze eenvoudigweg toe aan je `authorized_keys` bestand:
 
 	$ cat /tmp/id_rsa.john.pub >> ~/.ssh/authorized_keys
 	$ cat /tmp/id_rsa.josie.pub >> ~/.ssh/authorized_keys
 	$ cat /tmp/id_rsa.jessica.pub >> ~/.ssh/authorized_keys
 
-Nu kun je een leeg repository voor ze instellen door `git init` uit te voeren met de `--bare` optie, wat het repository initialiseert zonder een werkmap:
+Nu kun je een lege repository voor ze instellen door `git init` uit te voeren met de `--bare` optie, wat de repository initialiseert zonder een werkmap:
 
 	$ cd /opt/git
 	$ mkdir project.git
 	$ cd project.git
 	$ git --bare init
 
-Daarna kunnen John, Josie of Jessica de eerste versie van hun project in de repository pushen door het als een remote toe te voegen en naar een branch te pushen. Let op dat iemand met een shell op de machine zal moeten inloggen en een kale repository moet creeeren, iedere keer als je een project wilt toevoegen. Laten we `gitserver` als hostnaam gebruiken voor de server waar je je 'git' gebruiker en repository hebt ingesteld. Als je het intern gaat draaien, en je de DNS instelt zodat `gitserver` naar die server wijst, dan kun je de commando's vrijwel ongewijzigd gebruiken:
+Daarna kunnen John, Josie of Jessica de eerste versie van hun project in de repository pushen door het als een remote toe te voegen en een branch te pushen. Merk op dat iemand met een shell op de machine zal moeten inloggen en een kale repository moet creëren voor elke keer dat je een project wilt toevoegen. Laten we `gitserver` als hostnaam gebruiken voor de server waar je de 'git' gebruiker en repository hebt aangemaakt. Als je het binnenshuis draait, en je de DNS instelt zodat `gitserver` naar die server wijst, dan kun je de commando's vrijwel ongewijzigd gebruiken:
 
 	# op Johns computer
 	$ cd myproject
@@ -243,14 +242,14 @@ Daarna kunnen John, Josie of Jessica de eerste versie van hun project in de repo
 	$ git remote add origin git@gitserver:/opt/git/project.git
 	$ git push origin master
 
-Op dat punt kunnen de anderen het clonen en wijzigingen even gemakkelijk terug pushen:
+Vanaf dat moment kunnen de anderen het clonen en wijzigingen even gemakkelijk terug pushen:
 
 	$ git clone git@gitserver:/opt/git/project.git
 	$ vim README
 	$ git commit -am 'fix for the README file'
 	$ git push origin master
 
-Met deze methode kun je snel een lees/schrijf Git server draaiend krijgen voor een handvol ontwikkelaars.
+Op deze manier kun je snel een lees/schrijf Git server draaiend krijgen voor een handjevol ontwikkelaars.
 
 Als een extra voorzorgsmaatregel kun je de 'git' gebruiker makkelijk beperken tot het doen van alleen Git activiteiten, met een gelimiteerde shell applicatie genaamd `git-shell` die bij Git geleverd wordt.
 Als je dit als login shell voor je 'git' gebruiker instelt, dan kan de 'git' gebruiker geen normale shell toegang hebben op je server. Specificeer `git-shell` in plaats van bash of csh voor je gebruikers login shell om dit te gebruiken. Om dit te doen zul je waarschijnlijk het `/etc/passwd` bestand aan moeten passen:
@@ -261,7 +260,7 @@ Aan het einde zou je een regel moeten vinden die er ongeveer zo uit ziet:
 
 	git:x:1000:1000::/home/git:/bin/sh
 
-Verander `/bin/sh` in `/usr/bin/git-shell` (of voer `which git-shell` uit om te zien waar het geinstalleerd is). De regel moet er ongeveer zo uit zien:
+Verander `/bin/sh` in `/usr/bin/git-shell` (of voer `which git-shell` uit om te zien waar het geïnstalleerd is). De regel moet er ongeveer zo uit zien:
 
 	git:x:1000:1000::/home/git:/usr/bin/git-shell
 
@@ -273,11 +272,11 @@ Nu kan de 'git' gebruiker de SSH connectie alleen gebruiken om Git repositories
 
 ## Publieke Toegang ##
 
-Wat als je anonieme leestoegang op je project wil? Misschien wil je geen intern prive project serveren, maar een open source project. Of misschien heb je een serie geautomatiseerde bouwservers of continue integratie servers die vaak wijzigen, en wil je niet doorlopend SSH sleutels hoeven genereren – je wil gewoon eenvoudige leestoegang toevoegen.
+Wat als je anonieme leestoegang op je project wil? Misschien wil je geen intern privé project beheren, maar een open source project. Of misschien heb je een aantal geautomatiseerde bouwservers of continue integratie servers die vaak wisselen, en wil je niet doorlopend SSH sleutels hoeven genereren – je wil gewoon eenvoudige anonieme leestoegang toevoegen.
 
-Waarschijnlijk is de eenvoudigste manier voor kleinschalige opstellingen om een statische webserver in te stellen, waarbij de document root naar de plaats van je Git repositories wijst, en dan die `post-update` haak aanzetten waar we het in de eerste sectie van dit hoofdstuk over gehad hebben. Laten we eens uitgaan van het vorige voorbeeld. Stel dat je je repositories in de `/opt/git` map hebt staan, en er draait een Apache server op je machine. Nogmaals, je kunt hiervoor iedere web server gebruiken: maar als voorbeeld zullen we wat basis Apache configuraties laten zien, die je een idee kunnen geven van wat je nodig hebt.
+Waarschijnlijk is de eenvoudigste manier voor kleinschalige opstellingen om een statische webserver in te stellen, waarbij de document root naar de plaats van je Git repositories wijst, en dan de `post-update` haak aanzetten waar we het in de eerste paragraaf van dit hoofdstuk over gehad hebben. Laten we eens uitgaan van het voorgaande voorbeeld. Stel dat je je repositories in de `/opt/git` map hebt staan, en er draait een Apache server op je machine. Nogmaals, je kunt hiervoor iedere web server gebruiken: maar als voorbeeld zullen we wat simpele Apache configuraties laten zien, die je het idee weergeven van wat je nodig hebt.
 
-Eerst moet je de haak aanzetten:
+Eerst moet je de haak inschakelen:
 
 	$ cd project.git
 	$ mv hooks/post-update.sample hooks/post-update
@@ -285,7 +284,7 @@ Eerst moet je de haak aanzetten:
 
 Als je een lagere versie dan 1.6 van Git gebruikt, dan is het `mv` commando niet nodig – Git is recentelijk pas begonnen met de namen van de haak voorbeelden op .sample te laten eindigen.
 
-Wat doet deze `post-update` haak? Het ziet er ongeveer zo uit:
+Wat doet deze `post-update` haak? Het ziet er eigenlijk als volgt uit:
 
 	$ cat .git/hooks/post-update 
 	#!/bin/sh
@@ -293,7 +292,7 @@ Wat doet deze `post-update` haak? Het ziet er ongeveer zo uit:
 
 Dit betekent dat wanneer je naar de server via SSH pushed, Git dit commando uitvoert om de benodigde bestanden voor HTTP fetching te verversen.
 
-Vervolgens moet je een VirtualHost toevoeging in je Apache configuratie aanmaken, met de document root als de hoofdmap van je Git projecten. Hier nemen we aan dat je joker DNS ingesteld hebt om `*.gitserver` door te sturen naar waar je dit alles draait:
+Vervolgens moet je een VirtualHost regel in je Apache configuratie aanmaken, met de document root als de hoofdmap van je Git projecten. Hier nemen we aan dat je wildcard DNS ingesteld hebt om `*.gitserver` door te sturen naar waar je dit alles draait:
 
 	<VirtualHost *:80>
 	    ServerName git.gitserver
@@ -304,7 +303,7 @@ Vervolgens moet je een VirtualHost toevoeging in je Apache configuratie aanmaken
 	    </Directory>
 	</VirtualHost>
 
-Je zult ook de Unix gebruikers groep van de `/opt/git` mappen moeten instellen op `www-data` zodat je web server leestoegang heeft op de repositories, omdat de Apache instantie die het CGI script uitvoert (standaard) als die gebruiker draait:
+Je zult ook de Unix gebruikers groep van de `/opt/git` mappen moeten zetten op `www-data` zodat je web server leestoegang hebt op de repositories, omdat de Apache instantie het CGI script (standaard) uitvoert als die gebruiker draait:
 
 	$ chgrp -R www-data /opt/git
 
@@ -312,26 +311,26 @@ Als je Apache herstart, dan zou je je repositories onder die map moeten kunnen c
 
 	$ git clone http://git.gitserver/project.git
 
-Op deze manier kun je HTTP-gebaseerde toegang voor ieder van je projecten voor een groot aantal gebruikers in slechts een paar minuten instellen. Een andere eenvoudige optie om publieke ongeverifieerde toegang in te stellen is een Git daemon starten, alhoewel dat vereist dat je het proces als daemon uitvoert – we beschrijven deze optie in de volgende sectie als je een voorkeur hebt voor die route.
+Op deze manier kun je HTTP-gebaseerde toegang voor elk van je projecten voor een groot aantal gebruikers in slechts een paar minuten regelen. Een andere eenvoudige optie om publieke ongeauthenticeerde toegang in te stellen is een Git daemon te starten, alhoewel dat vereist dat je het proces als daemon uitvoert – we beschrijven deze optie in de volgende paragraaf als je een voorkeur hebt voor deze variant.
 
 ## GitWeb ##
 
-Nu dat je basis lees/schrijf en alleen-lezen toegang tot je project hebt, wil je misschien een eenvoudige web-gebaseerde visualiseerder instellen. Git levert een CGI script genaamd GitWeb mee, dat veelal voor hiervoor gebruikt wordt. Je kunt GitWeb in gebruik zien bij sites zoals `http://git.kernel.org` (zie Figuur 4-1).
+Nu je gewone lees/schrijf en alleen-lezen toegang tot je project hebt, wil je misschien een eenvoudige web-gebaseerde visualisatie instellen. Git levert een CGI script genaamd GitWeb mee, dat normaalgesproken hiervoor gebruikt wordt. Je kunt GitWeb in actie zien bij sites zoals `http://git.kernel.org` (zie Figuur 4-1).
 
 Insert 18333fig0401.png 
 Figuur 4-1. De GitWeb web-gebaseerde gebruikers interface.
 
-Als je wil zien hoe GitWeb er op jouw project uitziet, dan heeft Git een commando waarmee je een tijdelijke instantie op kunt starten als je een lichtgewicht server op je systeem hebt zoals `lighttpd` of `webrick`. Op Linux machines is `lighttpd` vaak geinstalleerd, dus je kunt het misschien draaiend krijgen door `git instaweb` in te typen in je project map. Als je op een Mac werkt: Leopard heeft Ruby voorgeinstalleerd, dus `webrick` zou je beste gok kunnen zijn. Om `instaweb` met een server anders dan lighttpd te starten, kun je het uitvoeren met de `--httpd` optie.
+Als je wil zien hoe GitWeb er voor jouw project uitziet, dan heeft Git een commando waarmee je een tijdelijke instantie op kunt starten als je een lichtgewicht server op je systeem hebt zoals `lighttpd` of `webrick`. Op Linux machines is `lighttpd` vaak geïnstalleerd, dus je kunt het misschien draaiend krijgen door `git instaweb` in te typen in je project map. Als je op een Mac werkt: Leopard heeft Ruby voorgeïnstalleerd, dus `webrick` zou je de meeste kans geven. Om `instaweb` met een server anders dan lighttpd te starten, moet je het uitvoeren met de `--httpd` optie.
 
 	$ git instaweb --httpd=webrick
 	[2009-02-21 10:02:21] INFO  WEBrick 1.3.1
 	[2009-02-21 10:02:21] INFO  ruby 1.8.6 (2008-03-03) [universal-darwin9.0]
 
-Dat start een HTTPD server op poort 1234 op en start automatisch een web browser op die met die pagina opent. Het is dus makkelijk voor jou. Als je klaar bent en de server wilt afsluiten, dan kun je hetzelfde commando uitvoeren met de `--stop` optie:
+Dat start een HTTPD server op poort 1234 op en start automatisch een web browser die op die pagina opent. Het is dus makkelijk voor je. Als je klaar bent en de server wilt afsluiten, dan kun je hetzelfde commando uitvoeren met de `--stop` optie:
 
 	$ git instaweb --httpd=webrick --stop
 
-Als je de web interface doorlopend op een server wilt draaien voor je team of voor een open source project dat je serveert, dan moet je het CGI script instellen zodat het door je normale web server geserveerd wordt. Sommige Linux distributies hebben een `gitweb` pakket dat je misschien kunt installeren via `apt` of `yum`, dus misschien wil je dat eerst proberen. We zullen zeer binnenkort door een handmatige GitWeb installatie heenlopen. Eerst moet je de Git broncode pakken, waar GitWeb bij zit, en het persoonlijke CGI script genereren: 
+Als je de web interface doorlopend op een server wilt draaien voor je team of voor een open source project dat je verspreid, dan moet je het CGI script instellen zodat het door je normale web server geserveerd wordt. Sommige Linux distributies hebben een `gitweb` pakket dat je zou kunnen installeren via `apt` of `yum`, dus wellicht kan je dat eerst proberen. We zullen snel door een handmatige GitWeb installatie heen lopen. Eerst moet je de Git broncode pakken waar GitWeb bij zit, en het aangepaste CGI script genereren: 
 
 	$ git clone git://git.kernel.org/pub/scm/git/git.git
 	$ cd git/
@@ -339,7 +338,7 @@ Als je de web interface doorlopend op een server wilt draaien voor je team of vo
 	        prefix=/usr gitweb/gitweb.cgi
 	$ sudo cp -Rf gitweb /var/www/
 
-Let op dat je het commando moet vertellen waar het je Git repositories kan vinden met de `GITWEB_PROJECTROOT` variabele. Nu moet je zorgen dat de Apache server CGI gebruikt voor dat script, waarvoor je een VirtualHost kunt toevoegen:
+Merk op dat je het commando moet vertellen waar het je Git repositories kan vinden met de `GITWEB_PROJECTROOT` variabele. Nu moet je zorgen dat de Apache server CGI gebruikt voor dat script, waarvoor je een VirtualHost kunt toevoegen:
 
 	<VirtualHost *:80>
 	    ServerName gitserver
@@ -354,17 +353,17 @@ Let op dat je het commando moet vertellen waar het je Git repositories kan vinde
 	    </Directory>
 	</VirtualHost>
 
-Nogmaals, GitWeb kan geserveerd worden met iedere CGI capabele web server; als je iets anders prefereert zou het niet moeilijk in te stellen moeten zijn. Op dit punt zou je in staat moeten zijn om `http://gitserver/` te bezoeken en je repositories online te zien, en kun je `http://git.gitserver` gebruiken om je repositories over HTTP te clonen en te fetchen.
+Nogmaals, GitWeb kan geserveerd worden met iedere web server die in staat is CGI te verwerken. Als je iets anders prefereert zou het niet moeilijk moeten zijn dit in te stellen. Vanaf dit moment zou je in staat moeten zijn om `http://gitserver/` te bezoeken en je repositories online te zien, en kun je `http://git.gitserver` gebruiken om je repositories over HTTP te clonen en te fetchen.
 
 ## Gitosis ##
 
-De publieke sleutels van alle gebruikers in een `authorized_keys` bestand bewaren voor toegang werkt slechts korte tijd goed. Als je honderden gebruikers hebt, dan is het moeizaam om dat proces te beheersen. Je moet iedere keer in de server inloggen, en er is geen toegangscontrole – iedereen in het bestand heeft lees- en schrijftoegang op ieder project.
+De publieke sleutels van alle gebruikers in een `authorized_keys` bestand bewaren voor toegang werkt slechts korte tijd goed. Als je honderden gebruikers hebt, dan is het te bewerkelijk om dat proces te blijven volgen. Je moet iedere keer in de server inloggen, en er is geen toegangscontrole – iedereen in het bestand heeft lees- en schrijftoegang op ieder project.
 
-Op dit punt wil je je misschien wenden tot een veelgebruikt software project genaamd Gitosis. Gitosis is in feite een set scripts die je helpen het `authorized_keys` bestand te beheren en eenvoudige toegangscontrole te implementeren. Het meest interessante gedeelte is dat de gebruikers interface voor deze applicatie om mensen toe te voegen en toegang te bepalen, geen web interface is maar een speciale Git repository. Je stelt de informatie in in dat project; en als je het pushed, dan herconfigureert Gitosis de server op basis van dat project, wat stoer is.
+Op dat moment zou je kunnen overwegen een veelgebruikt software project genaamd Gitosis te gaan gebruiken. Gitosis is in feite een verzameling scripts die je helpen het `authorized_keys` bestand te beheren alsmede eenvoudig toegangscontrole te implementeren. Het interessante hieraan is dat de gebruikers interface voor deze applicatie om mensen toe te voegen en toegang te bepalen, geen web interface is maar een speciale Git repository. Je beheert de informatie in dat project en als je het pushed, dan herconfigureert Gitosis de server op basis van dat project, wat best wel slim bedacht is.
 
-Gitosis installeren is niet de makkelijkste taak ooit, maar het is ook niet te moeilijk. Het is het makkelijkst om er een Linux server voor te gebruiken – deze voorbeelden gebruiken een standaard Ubuntu 8.10 server.
+Gitosis installeren is niet de makkelijkste taak ooit, maar het is ook niet al te moeilijk. Het is het makkelijkste om er een Linux server voor te gebruiken – deze voorbeelden gebruiken een standaard Ubuntu 8.10 server.
 
-Gitosis vereist wat Python applicaties, dus moet je eerst het Python setuptools pakket installeren, wat Ubuntu meelevert als python-setuptools:
+Gitosis vereist enkele Python tools, dus moet je eerst het Python setuptools pakket installeren, wat Ubuntu beschikbaar stelt als python-setuptools:
 
 	$ apt-get install python-setuptools
 
@@ -374,15 +373,15 @@ Vervolgens clone en installeer je Gitosis van de hoofdpagina van het project:
 	$ cd gitosis
 	$ sudo python setup.py install
 
-Daarmee worden een aantal bestanden geinstalleerd, die Gitosis zal gebruiken. Daarna wil Gitosis zijn repositories onder `/home/git` stoppen, wat prima is. Maar je hebt je repositories al in `/opt/git` geconfigureerd, dus in plaats van alles te herconfigureren maken we een symbolische link aan:
+Daarmee worden een aantal bestanden geïnstalleerd, die Gitosis zal gebruiken. Daarna wil Gitosis zijn repositories onder `/home/git` stoppen, wat prima is. Maar je hebt je repositories al in `/opt/git` geconfigureerd, dus in plaats van alles te herconfigureren maken we een symbolische link aan:
 
 	$ ln -s /opt/git /home/git/repositories
 
-Gitosis zal je sleutels voor je beheren, dus je moet het huidige bestand verwijderen, de sleutels later opnieuw toevoegen en Gitosis het `authorized_keys` bestand automatisch laten beheren. Voor nu verplaatsen we het `authorized_keys` bestand:
+Gitosis zal de sleutels voor je beheren, dus je moet het huidige bestand verwijderen, om de sleutels later opnieuw toe te voegen en Gitosis het `authorized_keys` bestand automatisch laten beheren. Voor nu verplaatsen we het `authorized_keys` bestand:
 
 	$ mv /home/git/.ssh/authorized_keys /home/git/.ssh/ak.bak
 
-Nu moet je je shell terugzetten voor de 'git' gebruiker, als je het veranderd hebt naar het `git-shell` commando. Mensen zullen nog steeds niet in staat zijn in te loggen, maar Gitosis zal dat voor je beheren. Dus, laten we deze regel veranderen in je `/etc/passwd` bestand
+Nu moet je de shell terugzetten voor de 'git' gebruiker, als je het veranderd hebt naar het `git-shell` commando. Mensen zullen nog steeds niet in staat zijn in te loggen, Gitosis zal dat voor je beheren. Dus, laten we deze regel veranderen in je `/etc/passwd` bestand
 
 	git:x:1000:1000::/home/git:/usr/bin/git-shell
 
@@ -390,18 +389,17 @@ terug naar dit:
 
 	git:x:1000:1000::/home/git:/bin/sh
 
-Nu wordt het tijd om Gitosis te initialiseren. Je doet dit door het `gitosis-init` commando met je eigen publieke sleutel uit te voeren. Als je publieke sleutel niet op de server staat zul je het daar naartoe moeten kopieeren:
+Nu wordt het tijd om Gitosis te initialiseren. Je doet dit door het `gitosis-init` commando met je eigen publieke sleutel uit te voeren. Als je publieke sleutel niet op de server staat zul je het daar naartoe moeten kopiëren:
 
 	$ sudo -H -u git gitosis-init < /tmp/id_dsa.pub
 	Initialized empty Git repository in /opt/git/gitosis-admin.git/
 	Reinitialized existing Git repository in /opt/git/gitosis-admin.git/
 
-Dit staat de gebruiker met die sleutel toe de hoofd Git repository, die de Gitosis installatie beheert, aan te passen. Daarna zul je met de hand het execute
-bit op het `post-update` script moeten instellen voor je nieuwe beheer repository.
+Dit staat de gebruiker met die sleutel toe de hoofd Git repository, die de Gitosis setup regelt, aan te passen. Daarna zul je met de hand het execute bit op het `post-update` script moeten aanzetten voor je nieuwe beheer repository.
 
 	$ sudo chmod 755 /opt/git/gitosis-admin.git/hooks/post-update
 
-Je bent nu klaar om te gaan. Als je alles juist hebt ingesteld, kun je nu met SSH in je server loggen als de gebruiker waarvoor je de publieke sleutel hebt toegevoegd om Gitosis te initialiseren. Je zou dan zoiets als dit moeten zien:
+Je bent nu klaar voor de start. Als je alles juist hebt ingesteld, kun je nu met SSH in je server loggen als de gebruiker waarvoor je de publieke sleutel hebt toegevoegd om Gitosis te initialiseren. Je zou dan zoiets als dit moeten zien:
 
 	$ ssh git@gitserver
 	PTY allocation request failed on channel 0
@@ -421,7 +419,7 @@ Nu heb je een map genaamd `gitosis-admin`, die twee gedeeltes heeft:
 	./keydir
 	./keydir/scott.pub
 
-Het `gitosis.conf` bestand is het beheer bestand, dat je zult gebruiken om gebruikers, repositories en permissies te specificeren. De `keydir` map is de plaats waar je de publieke sleutels opslaat van alle gebruikers die een vorm van toegang tot je repositories hebben – één bestand per gebruiker. De naam van het bestand in `keydir` (in het vorige voorbeeld, `scott.pub`) zal anders voor jou zijn – Gitosis haalt de naam uit de beschrijving aan het einde van de publieke sleutel die was geimporteerd met het `gitosis-init` script.
+Het `gitosis.conf` bestand is het beheer bestand dat je zult gebruiken om gebruikers, repositories en permissies te specificeren. De `keydir` map is de plaats waar je de publieke sleutels opslaat van alle gebruikers die een vorm van toegang tot de repositories hebben – één bestand per gebruiker. De naam van het bestand in `keydir` (in het vorige voorbeeld, `scott.pub`) zal anders zijn in jouw geval – Gitosis haalt de naam uit de beschrijving aan het einde van de publieke sleutel die was geïmporteerd met het `gitosis-init` script.
 
 Als je naar het `gitosis.conf` bestand kijkt, zou het alleen informatie over het zojuist geclonede `gitosis-admin` project mogen bevatten:
 
@@ -432,15 +430,15 @@ Als je naar het `gitosis.conf` bestand kijkt, zou het alleen informatie over het
 	writable = gitosis-admin
 	members = scott
 
-Het laat je zien dat de gebruiker 'scott' – de gebruiker met wiens publieke sleutel je Gitosis geinitialiseerd hebt – de enige is die toegang heeft tot het `gitosis-admin project.
+Het laat je zien dat de gebruiker 'scott' – de gebruiker met wiens publieke sleutel je Gitosis geïnitialiseerd hebt – de enige is die toegang heeft tot het `gitosis-admin` project.
 
-Laten we een nieuw project voor je toevoegen. Je voegt een nieuwe sectie genaamd `mobile` toe, waar je de ontwikkelaars in je mobile team neerzet, en de projecten waar deze ontwikkelaars toegang tot moeten hebben. Omdat 'scott' op het moment de enige gebruiker in het systeem is, zul je hem als enig lid toevoegen en zul je een nieuw project genaamd `iphone_project` toevoegen om mee te beginnen:
+Laten we nu een nieuw project voor je toevoegen. Je voegt een nieuwe sectie genaamd `mobile` toe, waar je de ontwikkelaars in het mobile team neerzet, en de projecten waar deze ontwikkelaars toegang tot moeten hebben. Omdat 'scott' op het moment de enige gebruiker in het systeem is, zul je hem als enig lid toevoegen en voeg je een nieuw project genaamd `iphone_project` toe om mee te beginnen:
 
 	[group mobile]
 	writable = iphone_project
 	members = scott
 
-Wanneer je wijzigingen aan het `gitosis-admin` project moet maken, moet je de veranderingen committen en terug pushen naar de server voordat ze effect hebben:
+Wanneer je wijzigingen aan het `gitosis-admin` project maakt, moet je de veranderingen committen en terug pushen naar de server voordat ze effect hebben:
 
 	$ git commit -am 'add iphone_project and mobile group'
 	[master]: created 8962da8: "changed name"
@@ -466,7 +464,7 @@ Je kunt je eerste push naar het nieuwe `iphone_project` doen door je server als
 
 Merk op dat je geen pad hoeft te specificeren (sterker nog, het wel doen zal niet werken), alleen een dubbele punt en dan de naam van het project – Gitosis zal het voor je vinden.
 
-Je wil samen met je vrienden aan dit project werken, dus je zult hun publieke sleutels weer toe moeten voegen. Maar in plaats van ze handmatig aan het `~/.ssh/authorized_keys` bestand op je server toe te voegen, voeg je ze, één sleutel per bestand, aan de `keydir` map toe. Hoe je de sleutels noemt bepaalt hoe je aan de gebruikers refereert in het `gitosis.conf` bestand. Laten we de publieke sleutels voor John, Josie en Jessica toevoegen:
+Je wil samen met je vrienden aan dit project werken, dus je zult hun publieke sleutels weer toe moeten voegen. Maar in plaats van ze handmatig aan het `~/.ssh/authorized_keys` bestand op je server toe te voegen, voeg je ze één sleutel per bestand, aan de `keydir` map toe. Hoe je de sleutels noemt bepaalt hoe je aan de gebruikers refereert in het `gitosis.conf` bestand. Laten we de publieke sleutels voor John, Josie en Jessica toevoegen:
 
 	$ cp /tmp/id_rsa.john.pub keydir/john.pub
 	$ cp /tmp/id_rsa.josie.pub keydir/josie.pub
@@ -490,7 +488,7 @@ Gitosis heeft ook eenvoudige toegangscontrole. Als je wilt dat John alleen lees
 	readonly = iphone_project
 	members = john
 
-Nu kan John het project clonen en updates krijgen, maar Gitosis zal hem niet toestaan om terug naar het project te pushen. Je kunt zoveel van deze groepen maken als je wilt, waarbij ze allen verschillende gebruikers en projecten mogen bevatten. Je kunt ook een andere groep als een van de leden specificeren (waarbij je `@` als prefix gebruikt), om alle leden automatisch over te erven:
+Nu kan John het project clonen en updates krijgen, maar Gitosis zal hem niet toestaan om terug naar het project te pushen. Je kunt zoveel van deze groepen maken als je wilt, waarbij ze alle verschillende gebruikers en projecten mogen bevatten. Je kunt ook een andere groep als een van de leden specificeren (met @ als voorvoegsel), waarmee de groepsleden automatisch worden overerfd:
 
 	[group mobile_committers]
 	members = scott josie jessica
@@ -503,21 +501,198 @@ Nu kan John het project clonen en updates krijgen, maar Gitosis zal hem niet toe
 	writable  = another_iphone_project
 	members   = @mobile_committers john
 
-Als je problemen hebt, kan het handig zijn om `loglevel=DEBUG` onder de `[gitosis] sectie te zetten. Als je je push-toegang bent verloren door een kapotte configuratie te pushen, kun je het handmatig repareren in het bestand `/home/git/.gitosis.conf` op de server – het bestand waar Gitosis zijn informatie vandaan haalt. Een push naar het project neemt het `gitosis.conf` bestand dat je zojuist gepushed hebt en stopt het daar. Als je het bestand handmatig aanpast, zal het zo blijven totdat de volgende succesvolle push gedaan wordt naar het `gitosis-admin` project. 
+Als je problemen hebt, kan het handig zijn om `loglevel=DEBUG` onder de `[gitosis]` sectie te zetten. Als je je push-toegang bent verloren door een kapotte configuratie te pushen, kun je het handmatig repareren in het bestand `/home/git/.gitosis.conf` op de server – het bestand waar Gitosis zijn informatie vandaan haalt. Een push naar het project neemt het `gitosis.conf` bestand dat je zojuist gepushed hebt en stopt het daar. Als je het bestand handmatig aanpast, zal het zo blijven totdat de volgende succesvolle push gedaan wordt naar het `gitosis-admin` project.
+
+## Gitolite ##
+
+Merk op: de laatste versie van deze paragraaf in het ProGit boek is altijd beschikbaar binnen de [gitolite documentation][gldpg]. De auteur geeft ook nederig aan dat, hoewel deze paragraaf accuraat is, het *kan* (en vaak ook *is*) gebruikt om gitolie te installeren zonder enige andere documentatie te lezen, dat het niet gegarandeerd compleet is, en het zeker niet de gehele enorme hoeveelheid documentatie kan vervangen dat meegeleverd wordt met gitolite.
+
+[gldpg]: http://github.com/sitaramc/gitolite/blob/pu/doc/progit-article.mkd
+
+Git begint erg populair te worden in het bedrijfsleven, die de neiging hebben nog wat additionele eisen te hebben op het gebied van toegangscontrole. Gitolite was oorspronkelijk gemaakt om bij het vervullen van deze eisen te helpen, maar het blijkt dat het even bruikbaar is in de wereld van de open source: het Fedora Project beheert toegang tot hun package beheer repositories (meer dan 10.000 daarvan!) met gitolite, en het is waarschijnlijk daarbij ook nog eens de grootste gitolite installatie waar dan ook.
+
+Gitolite stelt je in staat de permissies niet alleen per repository, maar ook per branch of tag naam binnen elke repository. Dus, je kunt aangeven dat bepaalde mensen (of groepen van mensen) alleen maar bepaalde "refs" (branches of tags) kunnen pushen maar niet andere.
+
+### Installatie ###
+
+Het installeren van Gitolite is zeer eenvoudig, zelfs als je de uitgebreide documentatie, dat erbij geleverd wordt, niet leest. Je hebt een account op een Unix(achtige) server hebben; verschillende Linux smaken en Solaris 10 zijn getest. Je hebt geen root toegang nodig, aangenomen dat git, perl, en een openssh compatible ssh server al zijn geïnstalleerd. In de onderstaand voorbeelden zullen we het `gitolite` account gebruiken op een host genaamd `gitserver`.
+
+Gitolite is nogal ongebruikelijk in de zin van "server" software -- toegang gaat via ssh, en elke userid op de server is in potentie een "gitolite host". Het resultaat is, dat er een idee is van "installeren" van de software zelf, en dan het "opzetten" van een gebruiker als een "gitolist host".
+
+Mensen zonder root toegang kunnen het installeren binnen hun eigen user id. Als laatste: gitlite kan geïnstalleerd worden door een script te starten *op het werkstation*, vanuit een bash-shell. (Zelfs de bash die meegeleverd wordt met msysgit volstaat, voor het geval je je dat afvroeg.)
+
+We zullen dit laatste in dit stuk beschrijven, voor de overige methoden verwijzen we je naar de documentatie.
+
+Je begint met het verkrijgen van toegang op basis van een publieke sleutel, zodat je vanaf je werkstation op de server kan inloggen zonder het intypen van je wachtwoord. De volgende methode werkt op Linux; voor andere werkstation besturingssystemen moet je dit wellicht handmatig doen. We gaan er vanuit dat je al een sleutelpaar hebt gegenereerd met `ssh-keygen`.
+
+	$ ssh-copy-id -i ~/.ssh/id_rsa gitolite@gitserver
+
+Dit zal je vragen naar een wachtwoord naar het gitolite account, en dan de publieke sleutel toegang opzetten. Dit is **absoluut noodzakelijk** voor het installatiescript, dus controleer dit om er zeker van te zijn dat je een commando kan laten lopen zonder een wachtwoord te hoeven in typen.
+
+	$ ssh gitolite@gitserver pwd
+	/home/gitolite
+
+Vervolgens, clone je Gitolite van de hoofdsite van het project en roept de "easy install" script aan (het derde argument is jouw naam zoals je deze in de resulterende gitolite-admin repository wilt laten verschijnen):
+
+	$ git clone git://github.com/sitaramc/gitolite
+	$ cd gitolite/src
+	$ ./gl-easy-install -q gitolite gitserver sitaram
+
+En dat is het! Gitolite is nu geïnstalleerdop je server, en je hebt nu een gloednieuwe repository genaamd `gitolite-admin` in de home directory van jouw werkstation. Je beheert je gitolite setup door een wijziging aan te brengen in deze reporitory en deze te pushen.
+
+Dat laatste commando produceert nogal een hoeveelheid uitvoer dat wellicht interessant is om te lezen. Ook wordt er, de eerste keer dat je het laat lopen, er een nieuwe sleutelpaar gemaakt; je moet een wachtwoord kiezen of Enter als je er geen wilt. Waarom een tweede sleutelpaar nodig is, en hoe deze wordt gebruikt, wordt uitgelegd in het "ssh troubleshooting" document dat bij Gitolite wordt meegeleverd. (Hey, de documentatie moet *ergens* goed voor zijn!)
+
+Repositories genaamd `gitolite-admin` en `testing` worden standaard op de server aangemaakt. Als je een van beide lokaal wilt clonen (van een account die SSA console toegang heeft naar het gitolite account via *authorized_keys*) type je:
+
+	$ git clone gitolite:gitolite-admin
+	$ git clone gitolite:testing
+	
+Om deze zelfde repositories te clonen van een willekeurige ander account:
+
+	$ git clone gitolite@servername:gitolite-admin
+	$ git clone gitolite@servername:testing
+
+### De Installatie Aanpassen ###
+
+Hoewel de standaard, snelle, installatie werkt voor de meeste mensen, zijn er een aantal manieren om de installatie aan te passen als dat nodig is. Als je het `-q` argument weg laat, krijg je een "verbose" installatie wijze -- gedetaileerde informatie over wat de installatie aan het doen is bij elke stap. De verbose wijze staat je ook toe om bepaalde server-side parameters aan te passen, zoals de locatie van de eigenlijke repositories, door het wijzigen van een "rc" bestand dat de server gebruikt. Dit "rc" bestand is ruimhartig van commentaar voorzien dus je zou in staat moeten zijn om elke wijziging die je nodig vindt vrij snel te maken, op te slaan en door te gaan. Dit bestand bevat ook enkele instellingen die je kunt aanpassen om de meer geavanceerde functies van gitolite aan of uit te zetten.
+
+### Config bestand en Beheer van Toegangsregels ###
+
+Op het moment dat de installatie afgerond is, schakel je over naar de `gitolite-admin` repository (staat in je HOME directory) en begin je rond te snuffelen om te zien wat je daar hebt:
+
+	$ cd ~/gitolite-admin/
+	$ ls
+	conf/  keydir/
+	$ find conf keydir -type f
+	conf/gitolite.conf
+	keydir/sitaram.pub
+	$ cat conf/gitolite.conf
+	#gitolite conf
+	# please see conf/example.conf for details on syntax and features
+
+	repo gitolite-admin
+	    RW+                 = sitaram
+
+	repo testing
+	    RW+                 = @all
+
+Merk op dat "sitaram" (het laatste argument in het `gl-easy-install` commando dat je eerder gegeven hebt) lees en schrijf rechten heeft op de `gitolite-admin` repository en een publiek sleutelbestand met dezelfde naam.
+
+De syntax van het config bestand voor gitolite is ruimhartig van documentatie voorzien in `conf/example.conf`, dus we zullen alleen wat hoofdpunten benoemen.
+
+Je kunt voor het gemak gebruikers of repositories groeperen. De groepnamen zijn vergelijkbaar met macros; als je ze definieert maakt het niet uit of het projecten of gebruikers zijn, dat onderscheid wordt pas gemaakt als je de "macro" gaat *gebruiken*.
+
+	@oss_repos      = linux perl rakudo git gitolite
+	@secret_repos   = fenestra pear
+
+	@admins         = scott     # Adams, not Chacon, sorry :)
+	@interns        = ashok     # get the spelling right, Scott!
+	@engineers      = sitaram dilbert wally alice
+	@staff          = @admins @engineers @interns
+
+Je kunt de permissies beheren op het "ref" niveau. In het volgende voorbeeld kunnen stagieres (interns) alleen maar naar de "int" branch pushen. Techneuten (engineers) kunnen naar elke branch pushen waarvan de naam begint met "eng-", en tags die beginnen met "rc" gevolgd door een getal. En de admins kunnen alles (inclusief terugdraaien) naar elke ref.
+
+	repo @oss_repos
+	    RW  int$                = @interns
+	    RW  eng-                = @engineers
+	    RW  refs/tags/rc[0-9]   = @engineers
+	    RW+                     = @admins
+
+De expressie achter de `RW` of `RW+` is een zgn. regular expression (regex) waartegen de refname (ref) die wordt gepushed wordt vergeleken. Dus we noemen het natuurlijk een "refex"! En natuurlijk kan een refex veel krachtiger zijn dan hier wordt getoond, dus ga het niet overdrijven als je niet al te goed in de perl regexen zit.
+
+Zoals je wellicht al geraden hebt, prefixed Gitolite `refs/heads/` als een syntactische handigheid als de refex niet begint met `refs/`.
+
+Een belangrijke eigenschap van de syntax van het config bestand is dat alle regels van een repository niet op één plek hoeft te staan. Je kunt al het generieke spul bij elkaar houden, zoals de regels voor alle `oss_repos` zoals ze hier boven staan, en dan op een latere plaats specifieke regels voor specifieke gevallen, zoals hier:
+
+	repo gitolite
+	    RW+                     = sitaram
+
+Deze regel wordt gewoon toegevoegd aan de set met regels voor de `gitolite` repository.
+
+Je zou je op dit punt kunnen afvragen hoe de toegangsregels eigenlijk worden toegepast, laten we dat kort behandelen.
+
+Er zijn twee niveaus van toegangsbeheer in gitolite. De eerste is op repository niveau. Als je lees (of schrijf)rechten hebt tot *enige* ref in de repository, dan heb je lees (of schrijf) rechten tot de repository.
+
+Het tweede niveau, alleen van toepassing voor "schrijf" toegang, is per branch of tag binnen een repository. De gebruikersnaam, het type toegang wat wordt gevraagd (`W` of '+'), en de refname dat wordt gewijzigd (update) zijn bekend. De toegangsregels worden gecontroleerd in volgorde van voorkomst in het config bestand, en er wordt gekeken naar een treffer voor deze combinatie (maar onthoudt dat de refname middels een regex wordt vergeleken, niet een simpele string-vergelijking). Als er een treffer is, dan slaagt de push. Als er geen treffer wordt gevonden (fallthrough) dan wordt toegang geweigerd.
+
+### Geavanceerde Toegangs Controle met "deny" regels ###
+
+Tot zover hebben we alleen permissies gezien uit het rijtje `R`, `RW` of `RW+`. Echter, gitolite kent een andere permissie: `-`, wat staat voor "deny" (ontken). Dit geeft je veel meer macht, tegen kosten van wat hogere complexiteit omdat een fallthrough nu niet de *enige* manier is waarop toegang kan worden geweigerd, wordt *de volgorde van regels belangrijk*!
+
+Stel dat, in de onderstaande situatie, we de techneuten in staat willen stellen elke branch te laten terugdraaien *behalve* master en integ. Dit is de manier om dat te doen:
+
+	    RW  master integ    = @engineers
+	    -   master integ    = @engineers
+	    RW+                 = @engineers
+
+Nogmaals, je hoeft slechts de regels van boven naar beneden af te lopen tot je een treffer hebt voor je gevraagde toegangswijze, of een afwijzing. Een push die niets terugdraait naar master of integ wordt door de eerste regel toegestaan. Een terugdraai-push naar deze refs geeft geen treffer op de eerste regel en valt door naar de tweede regel en wordt daarom geweigerd. Elke push (terugdraaiend of niet) naar refs anders dan master of integ zullen op de eerste twee regels zowiezo niet treffen en de derde regel staat dit toe.
+
+### Beperken van pushes bij gewijzigde bestanden ###
+
+Bovenop het beperken van gebruikersrechten op branches voor een gebruiker, kan je ook de rechten van gebruikers beperken op bestanden. Als voorbeeld, misschien is de Makefile (of een ander programma) niet echt bedoeld om te worden gewijzigd door iedereen, omdat een groot aantal dingen afhankelijk ervan zijn of omdat het stuk loopt als de wijzigingen niet *precies goed* gebeuren. Je kunt het gitolite duidelijk maken:
+
+    repo foo
+        RW                  =   @junior_devs @senior_devs
+
+        RW  NAME/           =   @senior_devs
+        -   NAME/Makefile   =   @junior_devs
+        RW  NAME/           =   @junior_devs
+
+Deze krachtige eigenschap is gedocumenteerd in `conf/example.conf`.
+
+### Persoonlijke branches ###
+
+Gitolite heeft ook een mogelijkheid van "persoonlijke branches" (of liever gezegd "persoonlijke branch namespace") wat erg nuttig kan zijn in een bedrijfssituatie.
+
+Veel van de code-uitwisselingen in de git-wereld verlopen via zgn. "please pull" aanvragen. In een bedrijfsomgeving echter is ongeauthoriseerde toegang taboe, en het werkstation van een ontwikkelaar kan geen authenticatie doen, dus je moet naar de centrale server pushen en iemand vragen daarvandaan te pullen.
+
+Dit zou normaalgesproken een gelijksoortige branch-brij veroorzaken als in een gecentraliseerde versiebeheersysteem, en daarbij wordt het opzetten van permissies een vervelende klus voor de administrator.
+
+Gitolite stelt je in staat een "personal" of "scratch" namespace prefix voor elke ontwikkelaar te definiëren (bijvoorbeeld `refs/personal/<devname>/*`); zie ook de "personal branches" paragraaf in `doc/3-faq-tips-etc.mkd` voor details.
+
+### "Wildcard" repositores ###
+
+Gitolite laat je repositories specificeren met wildcards (eigenlijk perl regex expressies), zoals bijvoorbeeld `assignments/s[0-9][0-9]/a[0-9][0-9]`, om maar een willekeurig voorbeeld te nemen. Dit is een *heel* krachtige eigenschap die wordt aangezet door de regel `$GL_WILDREPOS = 1;` in het rc bestand. Het laat je een nieuwe permissiewijze ("C") toe te wijzen welke gebruikers in staat stelt repositories aan te maken die voldoen aan zulke wildcards, automatisch eigenaarsschap toe te wijzen aan de gebruiker die hem heeft aangemaakt, staat deze gebruiker toe om "R" en "RW" permissies aan anderen toe te wijzen om samen te werken, etc. Deze eigenschap is beschreven in `doc/4-wildcard-repositories.mkd`.
+
+### Andere eigenschappen ###
+
+We ronden deze uiteenzetting af met een passe partout van andere eigenschappen, welke alle (en nog vele andere) tot in de kleinste detail zijn beschreven in de "faqs, tips, etc" en andere documenten.
+
+**Logging**: Gitolite logt alle succesvolle toegangspogingen. Als je wat te los bent geweest in het toekennen van terugdraai permissies (`RW+`) en een of andere nozem heeft "master" vernaggelt, is de log-file een redder in de nood in de zin van snel en eenvoudig achterhalen van de SHA die verdwenen is.
+
+**Git buiten reguliere PATH**: Een ontzettend handige eigenschap in gitolite is het ondersteunen van git buiten het regulier `$PATH` (dit komt vaker voor dan je zou denken, sommige bedrijfs omgevingen of zelfs sommige hosting providers weigeren dingen systeem-breed te installeren en je eindigt ermee dat je ze in je eigen directories zet). Normaalgesproken ben je gedwongen git aan de *client-side* op de een of andere manier te vertellen van deze niet-standaard locatie van de git binaries. Met gitolite hoe je alleen een verbose installatie te kiezen en `$GIT_PATH` in de "rc" bestanden in te vullen. Hierna geen wijzigingen aan de kant van de clients nodig :-)
+
+**Rapportage van toegangsrechten**: Nog zo'n handige eigenschap is wat er gebeurt als je gewoon met ssh naar de server gaat. Gitolite laat zien welke repositories je toegang toe hebt en welke soort toegang dat dan wel is. Hier is een voorbeeld:
+
+        hello sitaram, the gitolite version here is v1.5.4-19-ga3397d4
+        the gitolite config gives you the following access:
+             R     anu-wsd
+             R     entrans
+             R  W  git-notes
+             R  W  gitolite
+             R  W  gitolite-admin
+             R     indic_web_input
+             R     shreelipi_converter
+
+
+**Delegeringen**: Voor extreem grote installaties kan je de verantwoordelijkheid voor groepen van repositories delegeren aan verschilllende mensen en hen het beheer van die delen onafhankelijk laten regelen. Dit vermindert de werkdruk van de hoofd-beheerder, en maakt van hem minder een faalpunt. Deze eigenschap heeft zijn eigen docuentatie bestand in de `doc/` directory.
+
+**Gitweb ondersteuning**: Gitolite ondersteunt gitweb op verschillende manieren. Je kunt aangeven welke repositories zichtbaar zijn via gitweb. Je kunt de "owner" (eigenaar) en "description" (omschrijving) voor gitweb vanuit de gitolite configuratie bestanden definiëren. Gitweb heeft een mechanisme beschikbaar waarmee toegang via HTTP wordt geïmplementeerd, deze kan je het "gecompileerde" config bestand van de gitolite config file laten gebruiken, wat inhoudt dat gitweb en gitolite dezelfde toegangsregels gebruikt (voor lees toegang).
+
 
 ## Git Daemon ##
 
-Voor publieke ongeverifieerde leestoegang tot je projecten zul je het HTTP protocol achter je willen laten, en overstappen op het Git protocol. De hoofdreden is snelheid. Het Git protocol is veel efficienter en daarmee sneller dan het HTTP protocol, dus het zal je gebruikers tijd besparen.
+Voor publieke ongeauthenticeerde leestoegang tot je projecten zul je het HTTP protocol achter je willen laten, en overstappen op het Git protocol. De belangrijkste reden is snelheid. Het Git protocol is veel efficiënter en daarmee sneller dan het HTTP protocol, dus het zal je gebruikstijd besparen.
 
-Nogmaals, dit is voor ongeverifieerde alleen-lezen toegang. Als je dit op een server buiten je firewall draait, zul je het alleen moeten gebruiken voor projecten die voor de hele wereld toegankelijk moeten zijn. Als de server waarop je het draait binnen je firewall staat, zou je het kunnen gebruiken voor projecten waarbij een groot aantal mensen of computers (continue integratie of bouwservers) alleen-lezen toegang moeten hebben, waarbij je niet voor iedereen een SSH sleutel wilt toevoegen.
+Nogmaals, dit is voor ongeauthenticeerde alleen-lezen toegang. Als je dit op een server buiten je firewall draait, zul je het alleen moeten gebruiken voor projecten die voor de hele wereld toegankelijk moeten zijn. Als de server waarop je het draait binnen je firewall staat, zou je het kunnen gebruiken voor projecten waarbij een groot aantal mensen of computers (continue integratie of bouwservers) alleen-lezen toegang moeten hebben, waarbij je niet voor iedereen een SSH sleutel wilt toevoegen.
 
 In ieder geval is het Git protocol relatief eenvoudig in te stellen. Eigenlijk is het enige dat je moet doen dit commando een daemon uitvoeren:
 
 	git daemon --reuseaddr --base-path=/opt/git/ /opt/git/
 
-`--reuseaddr` staat de server toe om te herstarten zonder te wachten tot oude connecties een time out krijgen, de `--base-path` optie staat mensen toe om projecten te clonen zonder het volledige pad te specificeren, en het pad aan het einde vertelt de Git daemon waar hij moet kijken voor de te exporteren repositories. Als je een firewall draait, zul je er ook een gat in moeten maken in poort 9418 op de machine waar je dit op instelt.
+`--reuseaddr` staat de server toe om te herstarten zonder te wachten tot oude connecties een time-out krijgen, de `--base-path` optie staat mensen toe om projecten te clonen zonder het volledige pad te specificeren, en het pad aan het einde vertelt de Git daemon waar hij moet kijken voor de te exporteren repositories. Als je een firewall draait, zul je er poort 9418 open moeten zetten op de machine waar je dit op gaat doen.
 
-Je kunt dit proces op een aantal manieren daemonisern, afhankelijk van het besturingssystem waarop je draait. Op een Ubuntu machine, zul je een Upstart script gebruiken. Dus in het volgende bestand
+Je kunt dit proces op een aantal manieren daemoniseren, afhankelijk van het besturingssystem waarop je draait. Op een Ubuntu machine, zul je een Upstart script gebruiken. Dus in het volgende bestand
 
 	/etc/event.d/local-git-daemon
 
@@ -534,18 +709,18 @@ stop je dit script:
 
 Omwille van veiligheidsredenen, wordt sterk aangeraden om deze daemon uit te voeren als gebruiker met alleen-lezen toegang op de repositories – je kunt dit makkelijk doen door een gebruiker 'git-ro' aan te maken en de daemon als deze uit te voeren. Om het eenvoudig te houden voeren we het als dezelfde 'git' gebruiker uit, als waarin Gitosis draait.
 
-Als je je machine herstart, zal je Git daemon automatisch opstarten en herstarten als hij onderuit gaat. Om het te laten draaien zonder te herstarten, kun je dit uitvoeren:
+Als je de machine herstart, zal de Git daemon automatisch opstarten en herstarten als de server onderuit gaat. Om het te laten draaien zonder te herstarten, kun je dit uitvoeren:
 
 	initctl start local-git-daemon
 
-Op andere systemen zul je misschien `xinetd` willen gebruiken, een script in je `sysvinit` systeem, of iets anders – zolang je dat commando maar ge-daemoniseerd krijgt en op een of andere manier in de gaten gehouden wordt.
+Op andere systemen zul je misschien `xinetd` willen gebruiken, een script in je `sysvinit` systeem, of iets anders – zolang je dat commando maar ge-daemoniseerd krijgt en deze op een of andere manier in de gaten gehouden wordt.
 
-Vervolgens zul je je Gitosis server moeten vertellen welke repositories je ongeverifieerde Gitserver gebaseerde toegang toestaat. Als je een sectie toevoegt voor iedere repository, dan kun je die repositories specificeren waarop je je Git daemon wilt laten lezen. Als je Git protocol toegang tot je iphone project wilt toestaan, dan voeg je dit toe aan het eind van het `gitosis.conf` bestand:
+Vervolgens zul je je Gitosis server moeten vertellen welke repositories je onauthenticeerde Gitserver gebaseerde toegang toestaat. Als je een sectie toevoegt voor iedere repository, dan kun je die repositories specificeren waarop je je Git daemon wilt laten lezen. Als je Git protocol toegang tot je iphone project wilt toestaan, dan voeg je dit toe aan het eind van het `gitosis.conf` bestand:
 
 	[repo iphone_project]
 	daemon = yes
 
-Als dat gecommit en gepushed is, dan zou je draaiende daemon verzoeken moeten serveren aan iedereen die toegang heeft op poort 9418 van je server.
+Als dat gecommit en gepushed is, dan zou de draaiende daemon verzoeken moeten serveren aan iedereen die toegang heeft op poort 9418 van je server.
 
 Als je besluit om Gitosis niet te gebruiken, maar je wilt toch een Git daemon instellen, dan moet je dit op ieder project uitvoeren waarvoor je de Git daemon wilt laten serveren:
 
@@ -571,15 +746,15 @@ Als je nu het project commit en pushed, start GitWeb automatisch met het tonen v
 
 ## Hosted Git ##
 
-Als je niet door al het werk heen wilt om je eigen Git server op te zetten, heb je meerdere opties om je Git project op een externe speciale hosting pagina te laten beheren. Dit biedt een aantal voordelen: een ge-hoste pagina is over het algemeen snel in te stellen, en eenvoudig om projecten op te starten, en er komt geen server beheer en onderhoud bij kijken. Zelfs als je je eigen server intern ingesteld hebt, zul je misschien een publieke host pagina voor je open source broncode willen – dat is over het algemeen makkelijker voor de open source commune te vinden en je er mee te helpen.
+Als je niet al het werk wilt doen om je eigen Git server op te zetten, heb je meerdere opties om je Git project op een externe speciale hosting pagina te laten beheren. Dit biedt een aantal voordelen: een ge-hoste pagina is over het algemeen snel in te stellen, eenvoudig om projecten mee op te starten, en er komt geen serverbeheer en -onderhoud bij kijken. Zelfs als je je eigen server intern ingesteld hebt, zul je misschien een publieke host pagina voor je open source broncode willen – dat is over het algemeen makkelijker voor de open source commune te vinden en je er mee te helpen.
 
 Vandaag de dag heb je een enorm aantal beheer opties om uit te kiezen, elk met verschillende voor- en nadelen. Om een bijgewerkte lijst te zien, ga dan kijken op de GitHosting pagina op de hoofd Git wiki:
 
 	http://git.or.cz/gitwiki/GitHosting
 
-Omdat we ze niet allemaal kunnen behandelen, en ik toevalllig bij een ervan werk, zullen we deze sectie gebruiken om door het instellen van een account en het opzetten van een project op GitHub lopen. Dit geeft je een idee van het benodigde werk.
+Omdat we ze niet allemaal kunnen behandelen, en ik toevallig bij een ervan werk, zullen we deze paragraaf gebruiken het instellen van een account en het opzetten van een project op GitHub te doorlopen. Dit geeft je een idee van het benodigde werk.
 
-GitHub is veruit de grootste open source Git beheer pagina en het is ook een van de weinige die zowel publieke als privé beheer opties biedt, zodat je je open source en commerciele privé code in dezelfde plaats kunt bewaren. Sterker nog, we hebben GitHub gebruikt om privé samen te werken aan dit boek.
+GitHub is veruit de grootste open source Git beheer pagina en het is ook een van de weinige die zowel publieke als privé beheer opties biedt, zodat je je open source en commerciele privé code op dezelfde plaats kunt bewaren. Sterker nog, we hebben GitHub gebruikt om privé samen te werken aan dit boek.
 
 ### GitHub ###
 

From acf785e6b308f26609adca7ff8d559c63525faca Mon Sep 17 00:00:00 2001
From: Cor <cor.takken@cgi.com>
Date: Mon, 20 Jan 2014 13:33:17 +0100
Subject: [PATCH 122/690] [nl] Completed translating to Dutch, repaired a false
 "link" to "Simple Setups" section (that section does not exist) and made it
 point to the section where the ssh_keygen command is used.;sK

---
 nl/04-git-server/01-chapter4.markdown | 127 +++++++++++++-------------
 1 file changed, 65 insertions(+), 62 deletions(-)

diff --git a/nl/04-git-server/01-chapter4.markdown b/nl/04-git-server/01-chapter4.markdown
index c6bdd3c65..c45b26ba6 100644
--- a/nl/04-git-server/01-chapter4.markdown
+++ b/nl/04-git-server/01-chapter4.markdown
@@ -1,6 +1,6 @@
 # Git op de Server #
 
-Op dit punt zou je alledaagse taken waarvoor je Git zult gebruiken kunnen doen. Maar, om samen te kunnen werken in Git zul je een remote repository moeten hebben. Technisch gezien kun je wijzigingen pushen en pullen van individuele repositories, maar dat wordt afgeraden, omdat je vrij gemakkelijk het werk waar anderen mee bezig zijn in de war kunt schoppen als je niet oppast. Daarnaast wil je dat je medewerkers de repository kunnen bereiken, zelfs als jouw computer van het netwerk is – het hebben van een betrouwbare gezamenlijke repository is vaak handig. De voorkeursmethode om met iemand samen te werken is om een tussenliggende repository in te richten waar beide partijen toegang to hebben en om daar naartoe te pushen en vandaan te pullen. We zullen deze repository de `Git server` noemen, maar je zult zien dat het over het algemeen maar een klein beetje systeembronnen kost om een Git repository te verzorgen, dus je zult er zelden een complete server voor nodig hebben.
+Je zou nu de alledaagse taken waarvoor je Git zult gebruiken moeten kunnen uitvoeren. Echter, om enige vorm van samenwerking te hebben in Git is een remote repository nodig. Technisch gezien kun je wijzigingen pushen en pullen van individuele repositories, maar dat wordt afgeraden omdat je vrij gemakkelijk het werk waar anderen mee bezig zijn in de war kunt schoppen als je niet oppast. Daarnaast wil je dat je medewerkers de repository kunnen bereiken, zelfs als jouw computer van het netwerk is – het hebben van een betrouwbare gezamenlijke repository is vaak handig. De voorkeursmethode om met iemand samen te werken is om een tussenliggende repository in te richten waar beide partijen toegang tot hebben en om daar naartoe te pushen en vandaan te pullen. We zullen deze repository de `Git server` noemen, maar je zult zien dat het over het algemeen maar weinig systeembronnen kost om een Git repository te verzorgen, dus je zult er zelden een complete server voor nodig hebben.
 
 Een Git server draaien is eenvoudig. Als eerste kies je met welke protocollen je de server wilt laten communiceren. Het eerste gedeelte van dit hoofdstuk zullen we de beschikbare protocollen bespreken met de voor- en nadelen van elk. De daarop volgende paragrafen zullen we een aantal veel voorkomende opstellingen bespreken die van die protocollen gebruik maken en hoe je je server ermee kunt opzetten. Als laatste laten we een paar servers van derden zien, als je het niet erg vindt om je code op de server van een ander te zetten en niet het gedoe wilt hebben van het opzetten en onderhouden van je eigen server.
 
@@ -16,7 +16,7 @@ Het is belangrijk om op te merken dat, met uitzondering van de HTTP protocollen,
 
 ### Lokaal Protocol ###
 
-Het simpelste is het _Lokale protocol_, waarbij de remote repository in een andere directory op de schijf staat. Deze opzet wordt vaak gebruikt als iedereen in het team toegang heeft op een gedeeld bestandssyteem zoals een NFS mount, of in het weinig voorkomende geval dat iedereen op dezelfde computer werkt. Het laatste zou niet ideaal zijn, want dan zouden alle repositories op dezelfde computer staan, zodat een fataal verlies van gegevens veel groter wordt.
+Het simpelste is het _Lokale protocol_, waarbij de remote repository in een andere directory op de schijf staat. Deze opzet wordt vaak gebruikt als iedereen in het team toegang heeft op een gedeeld bestandssyteem zoals een NFS mount, of in het weinig voorkomende geval dat iedereen op dezelfde computer werkt. Het laatste zou niet ideaal zijn, want dan zouden alle repositories op dezelfde computer staan, zodat de kans op een fataal verlies van gegevens veel groter wordt.
 
 Als je een gedeeld bestandssyteem hebt, dan kun je clonen, pushen en pullen van een op een lokaal bestand aanwezige repository. Om een dergelijk repository te clonen, of om er een als een remote aan een bestaand project toe te voegen, moet je het pad naar het repository als URL gebruiken. Bijvoorbeeld, om een lokaal repository te clonen, kun je zoiets als het volgende uitvoeren:
 
@@ -26,7 +26,7 @@ Of je kunt dit doen:
 
 	$ git clone file:///opt/git/project.git
 
-Git werkt iets anders als je explicite `file://` aan het begin van de URL zet. Als je alleen het pad specificeert, probeert Git hardlinks te gebruiken, of het kopieert de bestanden die het nodig heeft. Als je `file://` specificeert, dan start Git de processen die het normaal gesproken gebruikt om data te transporteren over een netwerk, wat over het algemeen een minder efficiënte methode is om gegevens over te dragen. De belangrijkste reden om `file://` wel te specificeren is als je een schone kopie van de repository wilt met de vreemde refenties of objecten eruit gelaten – over het algemeen na een import uit een ander versiebeheer systeem of iets dergelijks (zie Hoofdstuk 9 voor onderhoudstaken). We zullen het normale pad hier gebruiken, omdat het bijna altijd sneller is om het zo te doen.
+Git werkt iets anders als je explicite `file://` aan het begin van de URL zet. Als je alleen het pad specificeert, probeert Git hardlinks te gebruiken, of het kopieert de bestanden die het nodig heeft. Als je `file://` specificeert, dan start Git de processen die het normaal gesproken gebruikt om data te transporteren over een netwerk, wat over het algemeen een minder efficiënte methode is om gegevens over te dragen. De belangrijkste reden om `file://` wel te specificeren is als je een schone kopie van de repository wilt met de vreemde referenties of objecten eruit gelaten – over het algemeen na een import uit een ander versiebeheer systeem of iets dergelijks (zie Hoofdstuk 9 voor onderhoudstaken). We zullen het normale pad hier gebruiken, omdat het bijna altijd sneller is om het zo te doen.
 
 Om een lokale repository aan een bestaand Git project toe te voegen, kun je iets als het volgende uitvoeren:
 
@@ -38,7 +38,7 @@ Daarna kun je op gelijke wijze pushen naar, en pullen van die remote als je over
 
 De voordelen van bestands-gebaseerde repositories zijn dat ze eenvoudig zijn en ze maken gebruik van bestaande bestandspermissies en netwerk toegang. Als je al een gedeeld bestandssysteem hebt, waar het hele team al toegang toe heeft, dan is een repository opzetten heel gemakkelijk. Je stopt de kale repository ergens waar iedereen gedeelde toegang tot heeft, en stelt de lees- en schrijfrechten in zoals je dat bij iedere andere gedeelde directory zou doen. In de volgende paragraaf "Git op een Server Krijgen" bespreken we hoe je een kopie van een kale repository kunt exporteren voor dit doeleinde.
 
-Dit is ook een prettige optie om snel werk uit een repository van iemand anders te pakken. Als jij en een collega aan hetzelfde project werken, en hij wil dat je iets bekijkt, dan is het uitvoeren van een commando zoals `git pull /home/john/project` vaak makkelijker dan dat hij naar een remote server moet pushen, en jij er van moet pullen.
+Dit is ook een prettige optie om snel werk uit een repository van iemand anders te pakken. Als jij en een collega aan hetzelfde project werken, en hij wil dat je iets bekijkt, dan is het uitvoeren van een commando zoals `git pull /home/john/project` vaak makkelijker dan wanneer hij naar een remote server moet pushen, en jij er van moet pullen.
 
 #### De Nadelen ####
 
@@ -62,15 +62,15 @@ Je kunt ook de gebruiker weglaten, en Git gebruikt gegevens van de gebruiker waa
 
 #### De Voordelen ####
 
-Er zijn vele voordelen om SSH te gebruiken. Ten eerste moet je het eigenlijk wel gebruiken als je geauthenticeerde schrijftoegang op je repository via een netwerk wilt. Ten tweede is het relatief eenvoudig in te stellen – SSH daemons komen veel voor, veel systeembeheerders hebben er ervaring mee, en veel operating systemen zijn er mee uitgerust of hebben applicaties om ze te beheren. Daarnaast is toegang via SSH veilig – alle data transporten zijn versleuteld en geauthenticeerd. En als laatste is SSH efficiënt, net zoals het Git en lokale protocol, de gegevens worden zo compact mogelijk gemaakt voordat het getransporteerd wordt.
+Er zijn vele voordelen om SSH te gebruiken. Ten eerste moet je het eigenlijk wel gebruiken als je geauthenticeerde schrijftoegang op je repository via een netwerk wilt. Ten tweede is het relatief eenvoudig in te stellen – SSH daemons komen veel voor, veel systeembeheerders hebben er ervaring mee, en veel operating systemen zijn er mee uitgerust of hebben applicaties om ze te beheren. Daarnaast is toegang via SSH veilig – alle data transporten zijn versleuteld en geauthenticeerd. En als laatste is SSH efficiënt, net zoals bij het Git en lokale protocol worden de gegevens zo compact mogelijk gemaakt voordat het getransporteerd wordt.
 
 #### De Nadelen ####
 
-Het negatieve aspect van SSH is dat je er geen anonieme toegang naar je repository over kunt geven. Mensen moeten via SSH toegang hebben om er gebruik van te kunnen maken, zelfs als het alleen lezen is, zodat SSH toegang niet bevordelijk is voor open source projecten. Als je het alleen binnen je bedrijfsnetwerk gebruikt, dan is SSH misschien het enige protocol waar je mee in aanraking komt. Als je anonieme alleen-lezen toegang wilt toestaan tot je projecten, dan moet je SSH voor jezelf instellen om over te pushen, maar iets anders voor anderen om over te pullen.
+Het negatieve aspect van SSH is dat je er geen anonieme toegang naar je repository over kunt geven. Mensen moeten via SSH toegang hebben om er gebruik van te kunnen maken zelfs als het alleen lezen is, dit maakt dat SSH toegang niet echt bevordelijk is voor open source projecten. Als je het alleen binnen je bedrijfsnetwerk gebruikt, is SSH wellicht het enige protocol waar je mee in aanraking komt. Als je anonieme alleen-lezen toegang wilt toestaan tot je projecten, dan moet je SSH voor jezelf instellen om over te pushen, maar iets anders voor anderen om over te pullen.
 
 ### Het Git Protocol ###
 
-Het volgende is het Git protocol. Dit is een specifieke daemon, die met Git meegeleverd wordt; het luistert op een toegewezen poort (9418), en verleent een vergelijkbare dienst als het SSH protocol, maar dan zonder enige vorm van authenticatie. Om een repository beschikbaar te stellen over het Git protocol, moet je een `git-export-daemon-ok` bestand aanmaken – de daemon zal een repository zonder dit bestand erin niet verspreiden – maar daarbuiten is er geen beveiliging. De Git repository beschikbaar om gecloned te kunnen worden door iedereen, of het is het niet. Dit betekent dat er over het algemeen geen pushing is via dit protocol. Je kunt push toegang aanzetten, maar gegeven het gebrek aan authenticatie kan als je de push toegang aan zet iedereen die de URL van jouw project op het internet vindt, pushen naar jouw project. We volstaan met te zeggen dat dit zelden de bedoeling kan zijn.
+Het volgende is het Git protocol. Dit is een specifieke daemon, die met Git meegeleverd wordt. Het luistert op een toegewezen poort (9418), en verleent een vergelijkbare dienst als het SSH protocol, maar dan zonder enige vorm van authenticatie. Om een repository beschikbaar te stellen over het Git protocol, moet je een `git-export-daemon-ok` bestand aanmaken – de daemon zal een repository zonder dit bestand erin niet verspreiden – maar daarbuiten is er geen beveiliging. De Git repository is beschikbaar om gecloned te kunnen worden door iedereen, of het is het niet. Dit betekent dat er over het algemeen geen pushing is via dit protocol. Je kunt push toegang aanzetten maar gegeven het gebrek aan authenticatie kan, als je de push toegang aan zet, iedereen die de URL van jouw project op het internet vindt pushen naar jouw project. We volstaan met te zeggen dat dit zelden de bedoeling kan zijn.
 
 #### De Voordelen ####
 
@@ -79,7 +79,7 @@ Het Git protocol is het snelste dat beschikbaar is. Als je veel verkeer verwerkt
 #### De Nadelen ####
 
 Het nadeel van het Git protocol is het gebrek aan authenticatie. Het is over het algemeen onwenselijk dat het Git protocol de enige toegang tot je project is. Meestal zul je het samen met SSH toegang gebruiken voor de paar ontwikkelaars die push (schrijf-)toegang hebben en de rest laat je `git://` voor alleen leestoegang gebruiken.
-Het is waarschijnlijk ook het meest ingewikkelde protocol om in te richten. Het moet een eigen daemon hebben, die speciaal voor die situatie ingericht is – we zullen er een instellen in het "Gitosis" gedeelte van dit hoofdstuk – het gebruikt `xinetd` configuratie of iets vergelijkbaars, wat ook niet altijd eenvoudig is op te zetten. Daarbij is ook firewall toegang tot poort 9418 nodig, wat geen standaard poort is dat in bedrijfsfirewalls is opengezet. Bij firewalls van grote bedrijven, is deze ongebruikelijke poort meestal dichtgezet.
+Het is waarschijnlijk ook het meest ingewikkelde protocol om in te richten. Het moet een eigen daemon hebben, die speciaal voor die situatie ingericht is – we zullen er een instellen in de "Gitosis" paragraaf van dit hoofdstuk – het gebruikt `xinetd` configuratie of iets vergelijkbaars, wat ook niet altijd eenvoudig is op te zetten. Daarbij is ook firewall toegang tot poort 9418 nodig, wat geen standaard poort is dat in bedrijfsfirewalls is opengezet. Bij firewalls van grote bedrijven, is deze ongebruikelijke poort meestal dichtgezet.
 
 ### Het HTTP/S Protocol ###
 
@@ -91,41 +91,41 @@ Als laatste hebben we het HTTP protocol. Het mooie aan het HTTP of HTTPS protoco
 	$ mv hooks/post-update.sample hooks/post-update
 	$ chmod a+x hooks/post-update
 
-Dat is alles. De `post-update` hook, die standaard bij Git geleverd wordt, voert het noodzakelijke commando uit (`git update-server-info`) om HTTP fetching en cloning goed werkend te krijgen en houden. Dit commando wordt uitgevoerd als je via SSH naar deze repository pushed; en andere mensen kunnen clonen met behulp van zoiets als
+Dat is alles. De `post-update` hook, die standaard bij Git geleverd wordt, voert het noodzakelijke commando uit (`git update-server-info`) om HTTP fetching en cloning goed werkend te krijgen en houden. Dit commando wordt uitgevoerd als je via SSH naar deze repository pushed, en andere mensen kunnen clonen met behulp van zoiets als
 
 	$ git clone http://example.com/gitproject.git
 
 In dit specifieke voorbeeld gebruiken we het `/var/www/htdocs` pad wat gebruikelijk is voor Apache opstellingen, maar je kunt iedere statische webserver gebruiken – stop de kale repository in het betreffende pad. De Git data wordt geserveerd als standaard statische bestanden (zie hoofdstuk 9 voor details over hoe het precies geserveerd wordt).
 
-Het is mogelijk om Git ook over HTTP te laten pushen, alhoewel dat geen veelgebruikte techniek is en het vraagt dat je complexe WebDAV instellingen inricht. Omdat het zelden gebruikt wordt, zullen we het niet in dit boek beschrijven. Als je geïnteresseerd bent om de HTTP-push protocollen te gebruiken, dan kun je op `http://www.kernel.org/pub/software/scm/git/docs/howto/setup-git-server-over-http.txt` lezen hoe je een repository kunt maken. Het aardige van Git laten pushen over HTTP is dat je iedere WebDAV server kunt gebruiken, zonder specifieke Git funtionaliteit, dus je kunt deze functionaliteit gebruiken als je web-hosting provider WebDAV ondersteunt voor het maken van wijzigingen aan je webpagina.
+Het is mogelijk om Git ook over HTTP te laten pushen, alhoewel dat geen veelgebruikte techniek is en het vereist dat je complexe WebDAV instellingen inricht. Omdat het zelden gebruikt wordt, zullen we het niet in dit boek behandelen. Als je geïnteresseerd bent om de HTTP-push protocollen te gebruiken, dan kun je op `http://www.kernel.org/pub/software/scm/git/docs/howto/setup-git-server-over-http.txt` lezen hoe je een repository kunt maken. Het aardige van Git laten pushen over HTTP is dat je iedere WebDAV server kunt gebruiken zonder specifieke Git funtionaliteit, dus je kunt deze optie gebruiken als je web-hosting provider WebDAV ondersteunt voor het maken van wijzigingen aan je webpagina.
 
 #### De Voordelen ####
 
-Het voordeel van het gebruik van het HTTP protocol is dat het eenvoudig in te stellen is. Een handvol benodigde commando's uitvoeren is alles wat er moet gebeuren om de wereld leestoegang te geven tot je Git repository. Het neemt maar een paar minuten van je tijd. Het HTTP protocol is niet erg belastend voor de systeembronnen van je server. Omdat het over het algemeen een statische webserver gebruikt om alle data te verspreiden - een normale Apache server kan gemiddeld duizenden bestanden zenden per seconde - is het moeilijk om zelfs een kleine server te overbelasten.
+Het voordeel van het gebruik van het HTTP protocol is dat het eenvoudig in te stellen is. Een handvol benodigde commando's uitvoeren is alles wat er moet gebeuren om de wereld leestoegang te geven tot je Git repository. Het neemt maar een paar minuten van je tijd. Het HTTP protocol is niet erg belastend voor de systeembronnen van je server. Omdat het over het algemeen een statische webserver gebruikt om alle data te verspreiden is het moeilijk om zelfs een kleine server te overbelasten - een normale Apache server kan gemiddeld duizenden bestanden zenden per seconde.
 
-Je kunt ook je repositories alleen-lezen serveren via HTTPS, wat inhoudt dat je het transport kunt versleutelen; je kunt zelfs zover gaan dat je clients een specifiek gesigneerd SSL certificaat laat gebruiken. Normaal gesproken als je je deze moeite wilt getroosten, dan is het makkelijker om publieke SSH sleutels te gebruiken; maar het kan in jouw specifieke geval een betere oplossing zijn om gesigneerde SSL certificaten of andere HTTP-gebaseerde authenticatie methoden te gebruiken voor alleen-lezen toegang via HTTPS.
+Je kunt ook je repositories alleen-lezen serveren via HTTPS, wat inhoudt dat je het gegevenstransport kunt versleutelen; je kunt zelfs zover gaan dat je clients een specifiek gesigneerd SSL certificaat laat gebruiken. Normaal gesproken als je je deze moeite wilt getroosten, dan is het makkelijker om publieke SSH sleutels te gebruiken; maar het kan in jouw specifieke geval een betere oplossing zijn om gesigneerde SSL certificaten of andere HTTP-gebaseerde authenticatie methoden te gebruiken voor alleen-lezen toegang via HTTPS.
 
 Een andere prettige bijkomstigheid is dat HTTP een dusdanig veel voorkomend protocol is dat bedrijfsfirewalls vaak zo ingesteld zijn dat ze verkeer via deze poort toestaan.
 
 #### De Nadelen ####
 
-Het nadeel van je repository verspreiden via HTTP is dat het relatief inefficiënt voor de client is. Over het algemeen duurt het een stuk langer om te clonen en te fetchen van de repository, en je hebt vaak een veel hogere netwerk belasting en transport volume via HTTP dan met elk van de andere netwerk protocollen. Omdat het niet zo ingewikkeld is om alleen de data te versturen die je nodig hebt – er wordt geen dynamisch werk door de server gedaan in deze uitwisselingen – wordt vaak naar het HTTP protocol gerefereerd als zijnde een _dom_ protocol. Voor meer informatie over de verschillen in efficiëntie tussen het HTTP protocol en andere protocollen, zie Hoofdstuk 9.
+Het nadeel van je repository verspreiden via HTTP is dat het relatief inefficiënt voor de client is. Over het algemeen duurt het een stuk langer om te clonen en te fetchen van de repository, en je hebt vaak een veel hogere netwerk belasting en transport volume via HTTP dan met elk van de andere netwerk protocollen. Omdat het niet zo slim is om eerst te bepalen van welke gegevens het nodig is te versturen – er wordt geen dynamisch werk door de server gedaan in deze uitwisselingen – wordt vaak naar het HTTP protocol gerefereerd als het _domme_ protocol. Voor meer informatie over de verschillen in efficiëntie tussen het HTTP protocol en andere protocollen, zie Hoofdstuk 9.
 
 ## Git op een Server Krijgen ##
 
 Om een Git server initieel op te zetten, moet je een bestaande repository naar een kale repository exporteren – een repository dat geen werkmap bevat. Dit is over het algemeen eenvoudig te doen.
-Om je repository te clonen met als doel het maken van een kale repository, voer je het clone commando uit met de `--bare` optie. Als conventie eindigen de namen van kale repository mappen met `.git`, zoals:
+Om je repository te clonen met als doel het maken van een kale repository, voer je het clone commando uit met de `--bare` optie. Als conventie eindigen de namen van kale repository mappen met `.git`, zoals hier:
 
 	$ git clone --bare my_project my_project.git
 	Initialized empty Git repository in /opt/projects/my_project.git/
 
-De output van dit commando is een beetje verwarrend. Omdat `clone` eigenlijk een `git init` en dan een `git fetch` is, zien we de output van het `git init` gedeelte, wat een lege map aanmaakt. De eigenlijke object overdracht geeft geen output, maar het gebeurt wel. Nu zou je een kopie van de Git map data in je `my_project.git` map moeten hebben.
+De output van dit commando is een beetje verwarrend. Het commando `clone` is eigenlijk een `git init` en dan een `git fetch`, wat we hier zien is de output van het `git init` gedeelte wat een lege map aanmaakt. De eigenlijke object overdracht geeft geen output, maar het gebeurt wel. Nu zou je een kopie van de Git map data in je `my_project.git` map moeten hebben.
 
 Dit is ongeveer gelijk aan
 
 	$ cp -Rf my_project/.git my_project.git
 
-Er zijn een paar kleine verschillen in het configuratie bestand, maar het komt op hetzelfde neer. Het neemt de Git repository zelf, zonder een werkmap, en maakt een map aan specifiek hiervoor.
+Er zijn een paar kleine verschillen in het configuratie bestand, maar het komt op hetzelfde neer. Het neemt de Git repository zelf, zonder een werkmap, en maakt een directory specifiek hiervoor aan.
 
 ### De Kale Repository op een Server Zetten ###
 
@@ -505,25 +505,27 @@ Als je problemen hebt, kan het handig zijn om `loglevel=DEBUG` onder de `[gitosi
 
 ## Gitolite ##
 
-Merk op: de laatste versie van deze paragraaf in het ProGit boek is altijd beschikbaar binnen de [gitolite documentation][gldpg]. De auteur geeft ook nederig aan dat, hoewel deze paragraaf accuraat is, het *kan* (en vaak ook *is*) gebruikt om gitolie te installeren zonder enige andere documentatie te lezen, dat het niet gegarandeerd compleet is, en het zeker niet de gehele enorme hoeveelheid documentatie kan vervangen dat meegeleverd wordt met gitolite.
+Merk op: de laatste versie van deze paragraaf in het ProGit boek is altijd beschikbaar binnen de [gitolite documentation][gldpg]. De auteur geeft ook nederig aan dat, hoewel deze paragraaf accuraat is, het *kan* (en vaak ook *is*) worden gebruikt om gitolite te installeren zonder enige andere documentatie te lezen, maar dat je er vanuit mag gaan dat het niet compleet is, en het zeker niet de gehele enorme hoeveelheid documentatie kan vervangen dat meegeleverd wordt met gitolite.
 
 [gldpg]: http://github.com/sitaramc/gitolite/blob/pu/doc/progit-article.mkd
 
-Git begint erg populair te worden in het bedrijfsleven, die de neiging hebben nog wat additionele eisen te hebben op het gebied van toegangscontrole. Gitolite was oorspronkelijk gemaakt om bij het vervullen van deze eisen te helpen, maar het blijkt dat het even bruikbaar is in de wereld van de open source: het Fedora Project beheert toegang tot hun package beheer repositories (meer dan 10.000 daarvan!) met gitolite, en het is waarschijnlijk daarbij ook nog eens de grootste gitolite installatie waar dan ook.
+Git begint erg populair te worden in het bedrijfsleven, die de neiging heeft nog wat additionele eisen te hebben op het gebied van toegangscontrole. Gitolite was oorspronkelijk gemaakt om bij het vervullen van deze eisen te helpen, maar het blijkt dat het even bruikbaar is in de wereld van de open source: het Fedora Project beheert toegang tot hun package beheer repositories (meer dan 10.000 daarvan!) met gitolite, en het is daarbij waarschijnlijk ook nog eens de grootste gitolite installatie waar dan ook.
 
 Gitolite stelt je in staat de permissies niet alleen per repository, maar ook per branch of tag naam binnen elke repository. Dus, je kunt aangeven dat bepaalde mensen (of groepen van mensen) alleen maar bepaalde "refs" (branches of tags) kunnen pushen maar niet andere.
 
 ### Installatie ###
 
-Het installeren van Gitolite is zeer eenvoudig, zelfs als je de uitgebreide documentatie, dat erbij geleverd wordt, niet leest. Je hebt een account op een Unix(achtige) server hebben; verschillende Linux smaken en Solaris 10 zijn getest. Je hebt geen root toegang nodig, aangenomen dat git, perl, en een openssh compatible ssh server al zijn geïnstalleerd. In de onderstaand voorbeelden zullen we het `gitolite` account gebruiken op een host genaamd `gitserver`.
+Het installeren van Gitolite is zeer eenvoudig, zelfs als je de uitgebreide documentatie, dat erbij geleverd wordt, niet leest. Je hebt een account op een Unix(achtige) server nodig; verschillende Linux smaken en Solaris 10 zijn getest. Je hebt geen root toegang nodig, aangenomen dat git, perl, en een openssh compatible ssh server al zijn geïnstalleerd. In de onderstaande voorbeelden zullen we het `gitolite` account gebruiken op een host genaamd `gitserver`.
 
-Gitolite is nogal ongebruikelijk in de zin van "server" software -- toegang gaat via ssh, en elke userid op de server is in potentie een "gitolite host". Het resultaat is, dat er een idee is van "installeren" van de software zelf, en dan het "opzetten" van een gebruiker als een "gitolist host".
+Gitolite is nogal ongebruikelijk in de zin van "server" software -- toegang gaat via ssh, en elke userid op de server is in potentie een "gitolite host". Met als gevolg dat er een notie is van "installeren" van de software zelf, en dan het "opzetten" van een gebruiker als een "gitolist host".
 
-Mensen zonder root toegang kunnen het installeren binnen hun eigen user id. Als laatste: gitlite kan geïnstalleerd worden door een script te starten *op het werkstation*, vanuit een bash-shell. (Zelfs de bash die meegeleverd wordt met msysgit volstaat, voor het geval je je dat afvroeg.)
+Gitolite heeft 4 wijzen van installeren. Mensen die Fedora of Debian systemen gebruiken kunnen een RPM of DEB ophalen en deze installeren. Mensen met root toegang kunnen het handmatig installeren. Met deze twee methoden kan elke gebruiker op het systeem een "gitolite host" worden.
+
+Mensen zonder root toegang kunnen het installeren binnen hun eigen user id. En als laatste: gitlite kan geïnstalleerd worden door een script te starten *op het werkstation*, vanuit een bash-shell. (Zelfs de bash die meegeleverd wordt met msysgit volstaat, voor het geval je je dat afvroeg.)
 
 We zullen dit laatste in dit stuk beschrijven, voor de overige methoden verwijzen we je naar de documentatie.
 
-Je begint met het verkrijgen van toegang op basis van een publieke sleutel, zodat je vanaf je werkstation op de server kan inloggen zonder het intypen van je wachtwoord. De volgende methode werkt op Linux; voor andere werkstation besturingssystemen moet je dit wellicht handmatig doen. We gaan er vanuit dat je al een sleutelpaar hebt gegenereerd met `ssh-keygen`.
+Je begint met het verkrijgen van toegang naar je server op basis van een publieke sleutel, zodat je vanaf je werkstation op de server kan inloggen zonder het intypen van je wachtwoord. De volgende methode werkt op Linux; voor andere werkstation besturingssystemen moet je dit wellicht handmatig doen. We gaan er vanuit dat je al een sleutelpaar hebt gegenereerd met `ssh-keygen`.
 
 	$ ssh-copy-id -i ~/.ssh/id_rsa gitolite@gitserver
 
@@ -538,11 +540,11 @@ Vervolgens, clone je Gitolite van de hoofdsite van het project en roept de "easy
 	$ cd gitolite/src
 	$ ./gl-easy-install -q gitolite gitserver sitaram
 
-En dat is het! Gitolite is nu geïnstalleerdop je server, en je hebt nu een gloednieuwe repository genaamd `gitolite-admin` in de home directory van jouw werkstation. Je beheert je gitolite setup door een wijziging aan te brengen in deze reporitory en deze te pushen.
+En dat is het! Gitolite is nu geïnstalleerd op je server, en je hebt nu een gloednieuwe repository genaamd `gitolite-admin` in de home directory van jouw werkstation. Je beheert je gitolite setup door een wijziging aan te brengen in deze reporitory en deze te pushen.
 
-Dat laatste commando produceert nogal een hoeveelheid uitvoer dat wellicht interessant is om te lezen. Ook wordt er, de eerste keer dat je het laat lopen, er een nieuwe sleutelpaar gemaakt; je moet een wachtwoord kiezen of Enter als je er geen wilt. Waarom een tweede sleutelpaar nodig is, en hoe deze wordt gebruikt, wordt uitgelegd in het "ssh troubleshooting" document dat bij Gitolite wordt meegeleverd. (Hey, de documentatie moet *ergens* goed voor zijn!)
+Dat laatste commando produceert redelijk wat uitvoer, dat wellicht interessant is om te lezen. Ook wordt er, de eerste keer dat je het commando laat lopen, er een nieuwe sleutelpaar gemaakt; je moet een wachtwoord kiezen of Enter als je er geen wilt. Waarom een tweede sleutelpaar nodig is, en hoe deze wordt gebruikt, wordt uitgelegd in het "ssh troubleshooting" document dat bij Gitolite wordt meegeleverd. (Hey, de documentatie moet *ergens* goed voor zijn!)
 
-Repositories genaamd `gitolite-admin` en `testing` worden standaard op de server aangemaakt. Als je een van beide lokaal wilt clonen (van een account die SSA console toegang heeft naar het gitolite account via *authorized_keys*) type je:
+Repositories genaamd `gitolite-admin` en `testing` worden standaard op de server aangemaakt. Als je een van beide lokaal wilt clonen (van een account die SSH console toegang heeft naar het gitolite account via *authorized_keys*) type je:
 
 	$ git clone gitolite:gitolite-admin
 	$ git clone gitolite:testing
@@ -558,7 +560,7 @@ Hoewel de standaard, snelle, installatie werkt voor de meeste mensen, zijn er ee
 
 ### Config bestand en Beheer van Toegangsregels ###
 
-Op het moment dat de installatie afgerond is, schakel je over naar de `gitolite-admin` repository (staat in je HOME directory) en begin je rond te snuffelen om te zien wat je daar hebt:
+Zodra de installatie afgerond is, schakel je over naar de `gitolite-admin` repository (die staat in je HOME directory) en begin je rond te snuffelen om te zien wat je daar hebt:
 
 	$ cd ~/gitolite-admin/
 	$ ls
@@ -580,7 +582,7 @@ Merk op dat "sitaram" (het laatste argument in het `gl-easy-install` commando da
 
 De syntax van het config bestand voor gitolite is ruimhartig van documentatie voorzien in `conf/example.conf`, dus we zullen alleen wat hoofdpunten benoemen.
 
-Je kunt voor het gemak gebruikers of repositories groeperen. De groepnamen zijn vergelijkbaar met macros; als je ze definieert maakt het niet uit of het projecten of gebruikers zijn, dat onderscheid wordt pas gemaakt als je de "macro" gaat *gebruiken*.
+Je kunt voor het gemak gebruikers of repositories groeperen. De groepnamen zijn vergelijkbaar met macros: als je ze definieert maakt het niet uit of het projecten of gebruikers zijn. Dat onderscheid wordt pas gemaakt als je de "macro" gaat *gebruiken*.
 
 	@oss_repos      = linux perl rakudo git gitolite
 	@secret_repos   = fenestra pear
@@ -598,9 +600,9 @@ Je kunt de permissies beheren op het "ref" niveau. In het volgende voorbeeld kun
 	    RW  refs/tags/rc[0-9]   = @engineers
 	    RW+                     = @admins
 
-De expressie achter de `RW` of `RW+` is een zgn. regular expression (regex) waartegen de refname (ref) die wordt gepushed wordt vergeleken. Dus we noemen het natuurlijk een "refex"! En natuurlijk kan een refex veel krachtiger zijn dan hier wordt getoond, dus ga het niet overdrijven als je niet al te goed in de perl regexen zit.
+De expressie achter de `RW` of `RW+` is een zgn. regular expression (regex) waartegen de refname (ref) die wordt gepushed wordt vergeleken. Dus we gaan we deze uiteraard een "refex" noemen! En natuurlijk kan een refex veel krachtiger zijn dan hier wordt getoond, dus ga het niet overdrijven als je niet al te goed in de perl regexen zit.
 
-Zoals je wellicht al geraden hebt, prefixed Gitolite `refs/heads/` als een syntactische handigheid als de refex niet begint met `refs/`.
+Zoals je wellicht al geraden hebt, gebruikt Gitolite de prefix `refs/heads/` als een syntactische handigheid indien de refex niet begint met `refs/`.
 
 Een belangrijke eigenschap van de syntax van het config bestand is dat alle regels van een repository niet op één plek hoeft te staan. Je kunt al het generieke spul bij elkaar houden, zoals de regels voor alle `oss_repos` zoals ze hier boven staan, en dan op een latere plaats specifieke regels voor specifieke gevallen, zoals hier:
 
@@ -611,13 +613,13 @@ Deze regel wordt gewoon toegevoegd aan de set met regels voor de `gitolite` repo
 
 Je zou je op dit punt kunnen afvragen hoe de toegangsregels eigenlijk worden toegepast, laten we dat kort behandelen.
 
-Er zijn twee niveaus van toegangsbeheer in gitolite. De eerste is op repository niveau. Als je lees (of schrijf)rechten hebt tot *enige* ref in de repository, dan heb je lees (of schrijf) rechten tot de repository.
+Er zijn twee niveaus van toegangsbeheer in gitolite. De eerste is op repository niveau. Als je lees- of schrijfrechten hebt tot *enige* ref in de repository, dan heb je lees (of schrijf) rechten tot de repository.
 
-Het tweede niveau, alleen van toepassing voor "schrijf" toegang, is per branch of tag binnen een repository. De gebruikersnaam, het type toegang wat wordt gevraagd (`W` of '+'), en de refname dat wordt gewijzigd (update) zijn bekend. De toegangsregels worden gecontroleerd in volgorde van voorkomst in het config bestand, en er wordt gekeken naar een treffer voor deze combinatie (maar onthoudt dat de refname middels een regex wordt vergeleken, niet een simpele string-vergelijking). Als er een treffer is, dan slaagt de push. Als er geen treffer wordt gevonden (fallthrough) dan wordt toegang geweigerd.
+Het tweede niveau, alleen van toepassing voor "schrijf" toegang, is per branch of tag binnen een repository. De gebruikersnaam, het type toegang wat wordt gevraagd (`W` of '+'), en de refname dat wordt gewijzigd (geüpdate) zijn bekend. De toegangsregels worden gecontroleerd in volgorde van voorkomst in het config bestand, en er wordt gekeken naar een treffer voor deze combinatie (maar onthoudt dat de refname middels een regex wordt vergeleken, niet een simpele string-vergelijking). Als er een treffer is, dan slaagt de push. Als er geen treffer wordt gevonden (fallthrough) dan wordt toegang geweigerd.
 
 ### Geavanceerde Toegangs Controle met "deny" regels ###
 
-Tot zover hebben we alleen permissies gezien uit het rijtje `R`, `RW` of `RW+`. Echter, gitolite kent een andere permissie: `-`, wat staat voor "deny" (ontken). Dit geeft je veel meer macht, tegen kosten van wat hogere complexiteit omdat een fallthrough nu niet de *enige* manier is waarop toegang kan worden geweigerd, wordt *de volgorde van regels belangrijk*!
+Tot zover hebben we alleen permissies gezien uit het rijtje `R`, `RW` of `RW+`. Echter, gitolite kent een andere permissie: `-`, wat staat voor "deny" (ontken). Dit geeft je veel meer macht, tegen kosten van wat hogere complexiteit omdat een fallthrough nu niet de *enige* manier is waarop toegang kan worden geweigerd; nu wordt *de volgorde van regels belangrijk*!
 
 Stel dat, in de onderstaande situatie, we de techneuten in staat willen stellen elke branch te laten terugdraaien *behalve* master en integ. Dit is de manier om dat te doen:
 
@@ -658,11 +660,11 @@ Gitolite laat je repositories specificeren met wildcards (eigenlijk perl regex e
 
 We ronden deze uiteenzetting af met een passe partout van andere eigenschappen, welke alle (en nog vele andere) tot in de kleinste detail zijn beschreven in de "faqs, tips, etc" en andere documenten.
 
-**Logging**: Gitolite logt alle succesvolle toegangspogingen. Als je wat te los bent geweest in het toekennen van terugdraai permissies (`RW+`) en een of andere nozem heeft "master" vernaggelt, is de log-file een redder in de nood in de zin van snel en eenvoudig achterhalen van de SHA die verdwenen is.
+**Logging**: Gitolite logt alle succesvolle toegangspogingen. Als je wat te los bent geweest in het toekennen van terugdraai permissies (`RW+`) en een of andere bijdehand heeft "master" vernaggelt, is de log-file een redder in de nood in de zin van snel en eenvoudig achterhalen van de SHA die verdwenen is.
 
-**Git buiten reguliere PATH**: Een ontzettend handige eigenschap in gitolite is het ondersteunen van git buiten het regulier `$PATH` (dit komt vaker voor dan je zou denken, sommige bedrijfs omgevingen of zelfs sommige hosting providers weigeren dingen systeem-breed te installeren en je eindigt ermee dat je ze in je eigen directories zet). Normaalgesproken ben je gedwongen git aan de *client-side* op de een of andere manier te vertellen van deze niet-standaard locatie van de git binaries. Met gitolite hoe je alleen een verbose installatie te kiezen en `$GIT_PATH` in de "rc" bestanden in te vullen. Hierna geen wijzigingen aan de kant van de clients nodig :-)
+**Git buiten reguliere PATH**: Een ontzettend handige eigenschap in gitolite is het ondersteunen van Git buiten het regulier `$PATH` (dit komt vaker voor dan je zou denken, sommige bedrijfs omgevingen of zelfs sommige hosting providers weigeren dingen systeem-breed te installeren en je eindigt ermee dat je ze in je eigen directories zet). Normaalgesproken ben je gedwongen Git aan de *client-side* op de een of andere manier te vertellen van deze niet-standaard locatie van de git binaries. Met gitolite hoe je alleen een verbose installatie te kiezen en `$GIT_PATH` in de "rc" bestanden in te vullen. Hierna geen wijzigingen aan de kant van de clients nodig :-)
 
-**Rapportage van toegangsrechten**: Nog zo'n handige eigenschap is wat er gebeurt als je gewoon met ssh naar de server gaat. Gitolite laat zien welke repositories je toegang toe hebt en welke soort toegang dat dan wel is. Hier is een voorbeeld:
+**Rapportage van toegangsrechten**: Nog zo'n handige eigenschap is wat er gebeurt als je gewoon met ssh naar de server gaat. Gitolite laat zien welke repositories je toegang toe hebt en welke soort toegang dat dan is. Hier is een voorbeeld:
 
         hello sitaram, the gitolite version here is v1.5.4-19-ga3397d4
         the gitolite config gives you the following access:
@@ -675,14 +677,15 @@ We ronden deze uiteenzetting af met een passe partout van andere eigenschappen,
              R     shreelipi_converter
 
 
-**Delegeringen**: Voor extreem grote installaties kan je de verantwoordelijkheid voor groepen van repositories delegeren aan verschilllende mensen en hen het beheer van die delen onafhankelijk laten regelen. Dit vermindert de werkdruk van de hoofd-beheerder, en maakt van hem minder een faalpunt. Deze eigenschap heeft zijn eigen docuentatie bestand in de `doc/` directory.
+**Delegeren**: Voor extreem grote installaties kan je de verantwoordelijkheid voor groepen van repositories delegeren aan verschillende mensen en hen het beheer van die delen onafhankelijk laten regelen. Dit vermindert de werkdruk van de hoofd-beheerder, en maakt van hem minder een faalpunt. Deze eigenschap heeft zijn eigen documentatie in de `doc/` directory.
 
-**Gitweb ondersteuning**: Gitolite ondersteunt gitweb op verschillende manieren. Je kunt aangeven welke repositories zichtbaar zijn via gitweb. Je kunt de "owner" (eigenaar) en "description" (omschrijving) voor gitweb vanuit de gitolite configuratie bestanden definiëren. Gitweb heeft een mechanisme beschikbaar waarmee toegang via HTTP wordt geïmplementeerd, deze kan je het "gecompileerde" config bestand van de gitolite config file laten gebruiken, wat inhoudt dat gitweb en gitolite dezelfde toegangsregels gebruikt (voor lees toegang).
+**Gitweb ondersteuning**: Gitolite ondersteunt gitweb op verschillende manieren. Je kunt aangeven welke repositories zichtbaar zijn via gitweb. Je kunt de "owner" (eigenaar) en "description" (omschrijving) voor gitweb vanuit de gitolite configuratie bestanden definiëren. Gitweb heeft een mechanisme beschikbaar waarmee toegang via HTTP wordt geïmplementeerd, deze kan je het "gecompileerde" config bestand van de gitolite config file laten gebruiken, wat inhoudt dat gitweb en gitolite dezelfde toegangsregels gebruiken (voor lees toegang).
 
+**Mirroring**: Gitolite kan je ondersteunen bij het beheren van meerdere mirrors, en het eenvoudig daartussen overschakelen als de primaire server uitvalt.
 
 ## Git Daemon ##
 
-Voor publieke ongeauthenticeerde leestoegang tot je projecten zul je het HTTP protocol achter je willen laten, en overstappen op het Git protocol. De belangrijkste reden is snelheid. Het Git protocol is veel efficiënter en daarmee sneller dan het HTTP protocol, dus het zal je gebruikstijd besparen.
+Voor publieke ongeauthenticeerde leestoegang tot je projecten zul je het HTTP protocol achter je willen laten, en overstappen op het Git protocol. De belangrijkste reden is snelheid. Het Git protocol is veel efficiënter en daarmee sneller dan het HTTP protocol, dus het zal je gebruikers tijd besparen.
 
 Nogmaals, dit is voor ongeauthenticeerde alleen-lezen toegang. Als je dit op een server buiten je firewall draait, zul je het alleen moeten gebruiken voor projecten die voor de hele wereld toegankelijk moeten zijn. Als de server waarop je het draait binnen je firewall staat, zou je het kunnen gebruiken voor projecten waarbij een groot aantal mensen of computers (continue integratie of bouwservers) alleen-lezen toegang moeten hebben, waarbij je niet voor iedereen een SSH sleutel wilt toevoegen.
 
@@ -707,7 +710,7 @@ stop je dit script:
 	    /opt/git/
 	respawn
 
-Omwille van veiligheidsredenen, wordt sterk aangeraden om deze daemon uit te voeren als gebruiker met alleen-lezen toegang op de repositories – je kunt dit makkelijk doen door een gebruiker 'git-ro' aan te maken en de daemon als deze uit te voeren. Om het eenvoudig te houden voeren we het als dezelfde 'git' gebruiker uit, als waarin Gitosis draait.
+Omwille van veiligheidsredenen, wordt sterk aangeraden om deze daemon uit te voeren als gebruiker met alleen-lezen toegang op de repositories – je kunt dit makkelijk doen door een nieuwe gebruiker 'git-ro' aan te maken en de daemon als deze uit te voeren. Om het eenvoudig te houden voeren we het als dezelfde 'git' gebruiker uit, als waarin Gitosis draait.
 
 Als je de machine herstart, zal de Git daemon automatisch opstarten en herstarten als de server onderuit gaat. Om het te laten draaien zonder te herstarten, kun je dit uitvoeren:
 
@@ -727,7 +730,7 @@ Als je besluit om Gitosis niet te gebruiken, maar je wilt toch een Git daemon in
 	$ cd /path/to/project.git
 	$ touch git-daemon-export-ok
 
-De aanwezigheid van dat bestand vertelt Git dat het OK is om dit project zonder verificatie te serveren.
+De aanwezigheid van dat bestand vertelt Git dat het OK is om dit project zonder authenticatie te serveren.
 
 Gitosis kan ook de projecten die GitWeb toont beheren. Eerst moet je zoiets als het volgende aan het `/etc/gitweb.conf` bestand toevoegen:
 
@@ -742,40 +745,40 @@ Je kunt instellen welke projecten GitWeb gebruikers laat bladeren door een `gitw
 	daemon = yes
 	gitweb = yes
 
-Als je nu het project commit en pushed, start GitWeb automatisch met het tonen van je iphone project.
+Als je nu het project commit en pushed, begint GitWeb automatisch je iphone project te tonen.
 
 ## Hosted Git ##
 
-Als je niet al het werk wilt doen om je eigen Git server op te zetten, heb je meerdere opties om je Git project op een externe speciale hosting pagina te laten beheren. Dit biedt een aantal voordelen: een ge-hoste pagina is over het algemeen snel in te stellen, eenvoudig om projecten mee op te starten, en er komt geen serverbeheer en -onderhoud bij kijken. Zelfs als je je eigen server intern ingesteld hebt, zul je misschien een publieke host pagina voor je open source broncode willen – dat is over het algemeen makkelijker voor de open source commune te vinden en je er mee te helpen.
+Als je niet al het werk wilt doen om je eigen Git server op te zetten, heb je meerdere opties om je Git project op een externe speciale hosting pagina te laten beheren. Dit biedt een aantal voordelen: een ge-hoste pagina is over het algemeen snel in te stellen, eenvoudig om projecten mee op te starten, en er komt geen serverbeheer en -onderhoud bij kijken. Zelfs als je je eigen server intern opgezet hebt, zul je misschien een publieke host pagina voor je open source broncode willen – dat is over het algemeen makkelijker voor de open source commune te vinden en je er mee te helpen.
 
 Vandaag de dag heb je een enorm aantal beheer opties om uit te kiezen, elk met verschillende voor- en nadelen. Om een bijgewerkte lijst te zien, ga dan kijken op de GitHosting pagina op de hoofd Git wiki:
 
 	http://git.or.cz/gitwiki/GitHosting
 
-Omdat we ze niet allemaal kunnen behandelen, en ik toevallig bij een ervan werk, zullen we deze paragraaf gebruiken het instellen van een account en het opzetten van een project op GitHub te doorlopen. Dit geeft je een idee van het benodigde werk.
+Omdat we ze niet allemaal kunnen behandelen, en omdat ik toevallig bij een ervan werk, zullen we deze paragraaf gebruiken het instellen van een account en het opzetten van een project op GitHub te doorlopen. Dit geeft je een idee van het benodigde werk.
 
-GitHub is veruit de grootste open source Git beheer pagina en het is ook een van de weinige die zowel publieke als privé beheer opties biedt, zodat je je open source en commerciele privé code op dezelfde plaats kunt bewaren. Sterker nog, we hebben GitHub gebruikt om privé samen te werken aan dit boek.
+GitHub is verreweg de grootste open source Git beheer site en het is ook een van de weinige die zowel publieke als privé hosting opties biedt, zodat je je open source en commerciële privé code op dezelfde plaats kunt bewaren. Als voorbeeld: we hebben GitHub gebruikt om privé samen te werken aan dit boek.
 
 ### GitHub ###
 
-GitHub verschilt een beetje van de meeste code-beheer pagina's in de manier waarop het de projecten een naamruimte geeft. In plaats dat het primair gebaseerd is op het project, stelt GitHub gebruikers centraal. Dat betekent dat als ik mijn `grit` project op GitHub beheer, je het niet zult vinden op `github.com/grit` maar in plaats daarvan op `github.com/schacon/grit`. Er is geen generieke versie van een project, wat een project toestaat om naadloos van de ene op de andere gebruiker over te gaan als de eerste auteur het project verlaat.
+GitHub verschilt een beetje van de meeste code-beheer pagina's in de manier waarop het de projecten een benoemt. In plaats dat het primair gebaseerd is op het project, stelt GitHub gebruikers centraal. Dat betekent dat als ik mijn `grit` project op GitHub beheer, je het niet zult vinden op `github.com/grit` maar in plaats daarvan op `github.com/schacon/grit`. Er is geen allesoverheersende versie van een project, wat een project in staat stelt om naadloos van de ene op de andere gebruiker over te gaan als de eerste auteur het project verlaat.
 
-GitHub is ook een commercieel bedrijf dat geld vraagt voor accounts die privé repositories beheren, maar iedereen kan snel een gratis account krijgen om zoveel open source projecten als ze willen te beheren. We zullen er snel doorheen lopen hoe je dat doet.
+GitHub is ook een commercieel bedrijf dat geld vraagt voor accounts die privé repositories beheren, maar iedereen kan snel een gratis account krijgen om net zoveel open source projecten te beheren als ze willen. We zullen er snel doorheen lopen hoe je dat doet.
 
 ### Een Gebruikers Account Instellen ###
 
-Het eerste dat je moet doen is een gratis gebruikers account instellen. Als je de Pricing and Signup pagina op `http://github.com/plans` bezoekt en de "Sign Up" knop aanklikt op het gratis account (zie figuur 4-2), dan wordt je naar de inteken pagina gebracht.
+Het eerste dat je moet doen is een gratis gebruikers account aanvragen. Als je de Pricing and Signup pagina op `http://github.com/plans` bezoekt en de "Sign Up" knop aanklikt op het Free account (zie figuur 4-2), dan wordt je naar de inteken pagina gebracht.
 
 Insert 18333fig0402.png
-Figuur 4-2. De GitHub inteken pagina.
+Figuur 4-2. De GitHub plan pagina.
 
-Hier moet je een gebruikersnaam kiezen die nog niet bezet is in het systeem, en een e-mail adres invullen dat bij het account hoort, en een wachtwoord (zie Figuur 4-3).
+Hier moet je een gebruikersnaam kiezen die nog niet gebruikt is in het systeem, en een e-mail adres invullen dat bij het account hoort, en een wachtwoord (zie Figuur 4-3).
 
 Insert 18333fig0403.png 
 Figuur 4-3. Het GitHub gebruikers inteken formulier.
 
-Als je account beschikbaar hebt, is dit een goed moment om je publieke SSH sleutel ook toe te voegen. We hebben je eerder laten zien hoe je een nieuwe sleutel kunt genereren, in de "Eenvoudige Instellingen" sectie. Neem de inhoud van de publieke sleutel van dat paar, en plak het in het SSH publieke sleutel tekstveld. Door op de "explain ssh keys" link te klikken wordt je naar gedetaileerde instructies gebracht die je vertellen hoe dit te doen op alle veelgebruikte besturingssystemen.
-Door op de "I agree, sign me up" knop te klikken wordt je naar je nieuwe gebruikers dashboard gebracht (zie Figuur 4-4).
+Als je account beschikbaar is, is dit een goed moment om je publieke SSH sleutel ook toe te voegen. We hebben het genereren van een nieuwe sleutel eerder behandeld, in de "Je Publieke SSH Sleutel Genereren" paragraaf. Neem de inhoud van de publieke sleutel van dat paar, en plak het in het SSH publieke sleutel tekstveld. Door op de "explain ssh keys" link te klikken wordt je naar gedetaileerde instructies gebracht die je vertellen hoe dit te doen op alle veelvoorkomende besturingssystemen.
+Door op de "I agree, sign me up" knop te klikken wordt je naar het dashboard van je nieuwe gebruikers gebracht (zie Figuur 4-4).
 
 Insert 18333fig0404.png 
 Figuur 4-4. Het GitHub gebruikers dashboard.
@@ -789,7 +792,7 @@ Start door op de "create a new one" link te klikken naast Your Repositories op h
 Insert 18333fig0405.png 
 Figuur 4-5. Een nieuw repository aanmaken op GitHub.
 
-Het enige dat je eigenlijk moet doen is een projectnaam opgeven, maar je kunt ook een beschrijving toevoegen. Wanneer je dat gedaan hebt, klik dan op de "Create Repository" knop. Nu heb je een nieuw repository op GitHub (zie Figuur 4-6).
+Het enige dat je eigenlijk moet doen is een projectnaam opgeven, maar je kunt ook een beschrijving toevoegen. Wanneer je dat gedaan hebt, klik je op de "Create Repository" knop. Nu heb je een nieuw repository op GitHub (zie Figuur 4-6).
 
 Insert 18333fig0406.png 
 Figuur 4-6. GitHub project hoofd informatie.
@@ -810,14 +813,14 @@ Als je een lokaal Git repository hebt, voeg dan GitHub als remote toe en push je
 	$ git remote add origin git@github.com:testinguser/iphone_project.git
 	$ git push origin master
 
-Nu wordt je project beheerd op GitHub, en kun je de URL aan iedereen geven waarmee je je project wilt delen. In dit geval is het `http://githup.com/testinguser/iphone_project`. Je kunt aan het begin van ieder van je project pagina's zien dat je twee Git URLs hebt (zie Figuur 4-8).
+Nu wordt je project beheerd op GitHub, en kun je de URL aan iedereen geven waarmee je je project wilt delen. In dit geval is het `http://githup.com/testinguser/iphone_project`. Je kunt aan het begin van elk van je project pagina's zien dat je twee Git URLs hebt (zie Figuur 4-8).
 
 Insert 18333fig0408.png 
 Figuur 4-8. Project met een publieke URL en een privé URL.
 
-De publieke Clone URL is een publieke alleen-lezen Git URL, waarmee iedereen het project kan clonen. Deel deze URL maar gewoon uit en zet 'm op je website of wat je ook hebt.
+De Public Clone URL is een publieke alleen-lezen Git URL, waarmee iedereen het project kan clonen. Deel deze URL door 'm op je website neer te zetten of welke manier dan ook.
 
-De Your Clone URL is een lees/schrijf SSH-gebaseerde URL waar je alleen over kunt lezen of schrijven als je connectie maakt met de privé SSH sleutel die geassocieerd is met de publieke sleutel die je voor jouw gebruiker geupload hebt. Wanneer andere gebruikers deze project pagina bezoeken, zullen ze die URL niet zien – alleen de publieke.
+De Your Clone URL is een lees/schrijf SSH-gebaseerde URL waar je alleen over kunt lezen of schrijven als je connectie maakt met de privé SSH sleutel die geassocieerd is met de publieke sleutel die je voor jouw gebruiker geüpload hebt. Wanneer andere gebruikers deze project pagina bezoeken, zullen ze die URL niet zien – alleen de publieke.
 
 ### Importeren vanuit Subversion ###
 
@@ -832,12 +835,12 @@ Als je project erg groot is, niet standaard, of privé, dan zal dit process waar
 
 Laten we de rest van het team toevoegen. Als John, Josie en Jessica allemaal intekenen voor accounts op GitHub, en je wilt ze push toegang op je repository geven, kun je ze aan je project toevoegen als medewerkers. Door dat te doen zullen pushes vanaf hun publieke sleutels werken.
 
-Klik de "edit" knop aan de bovenkant van het project, of de Admin tab, om de Admin pagina te bereiken van je GitHub project (zie Figuur 4-10).
+Klik de "edit" knop of de Admin tab aan de bovenkant van het project, om de Admin pagina te bereiken van je GitHub project (zie Figuur 4-10).
 
 Insert 18333fig0410.png 
 Figuur 4-10. GitHub administratie pagina.
 
-Om een andere gebruiker schrijftoegang tot je project te geven, klik dan de "Add another collaborator" link. Er verschijnt een nieuw tekstveld, waarin je een gebruikersnaam kunt invullen. Op het moment dat je typt, komt er een hulp omhoog, waarin alle mogelijke overeenkomende gebruikersnamen staan. Als je de juiste gebruiker vind, klik dan de Add knop om die gebruiker als een medewerker aan je project toe te voegen (zie Figuur 4-11). 
+Om een andere gebruiker schrijftoegang tot je project te geven, klik dan de "Add another collaborator" link. Er verschijnt een nieuw tekstveld, waarin je een gebruikersnaam kunt invullen. Op het moment dat je typt, komt er een hulp tevoorschijn, waarin alle mogelijke overeenkomende gebruikersnamen staan. Als je de juiste gebruiker vindt, klik dan de Add knop om die gebruiker als een medewerker aan je project toe te voegen (zie Figuur 4-11). 
 
 Insert 18333fig0411.png 
 Figuur 4-11. Een medewerker aan je project toevoegen.
@@ -847,20 +850,20 @@ Als je klaar bent met medewerkers toevoegen, dan zou je een lijst met de namen m
 Insert 18333fig0412.png 
 Figuur 4-12. Een lijst met medewerkers aan je project.
 
-Als je toegang van individuen moet intrekken, dan kun je de "revoke" link klikken, en dan wordt hun push toegang ingetrokken. Voor toekomstige projecten, kun je ook de medewerker groepen kopieeren door de permissies van een bestaand project te kopieeren.
+Als je toegang van individuen moet intrekken, dan kun je de "revoke" link klikken, en dan wordt hun push toegang ingetrokken. Voor toekomstige projecten, kun je ook groepen medewerker kopiëren door de permissies van een bestaand project te kopiëren.
 
 ### Je Project ###
 
-Nadat je je project gepushed hebt, of geimporteerd vanuit Subversion, heb je een hoofd project pagina die er uitziet zoals Figuur 4-13.
+Nadat je je project gepushed hebt, of geïmporteerd vanuit Subversion, heb je een hoofd project pagina die er uitziet zoals Figuur 4-13.
 
 Insert 18333fig0413.png 
 Figuur 4-13. Een GitHub project hoofpagina.
 
-Als mensen je project bezoeken, zien ze deze pagina. Het bevat tabs naar de verschillende aspecten van je projecten. De Commits tab laat een lijst van commits in omgekeerde chronologische volgorde zien, vergelijkbaar met de output van het `git log` commando. De Network tab toont alle mensen die je project hebben geforked en bijgedragen hebben. De Downloads tab staat je toe project binaries te uploaden en naar tarballs en gezipte versies van ieder getagged punt in je project te linken. De Wiki tab voorziet in een wiki waar je documentatie kunt schrijven of andere informatie over je project. De Graphs tab heeft wat contributie visualisaties en statistieken over je project. De hoofd Source tab waarop je binnen komt toont de inhoud van de hoofdmap van je project en toont automatisch het README bestand eronder als je er een hebt. Deze tab toont ook een veld met de laatste commit informatie.
+Als mensen je project bezoeken, zien ze deze pagina. Het bevat tabs naar de verschillende aspecten van je projecten. De Commits tab laat een lijst van commits in omgekeerde chronologische volgorde zien, vergelijkbaar met de output van het `git log` commando. De Network tab toont alle mensen die je project hebben geforked en bijgedragen hebben. De Downloads tab staat je toe project binaries te uploaden en naar tarballs en gezipte versies van ieder getagged punt in je project te linken. De Wiki tab voorziet in een wiki waar je documentatie kunt schrijven of andere informatie over je project. De Graphs tab heeft wat contributie visualisaties en statistieken over je project. De hoofd Source tab waarop je binnen komt, toont de inhoud van de hoofdmap van je project en toont automatisch het README bestand eronder als je er een hebt. Deze tab toont ook een veld met de laatste commit informatie.
 
 ### Projecten Forken ###
 
-Als je aan een bestaand project waarop je geen push toegang hebt wilt bijdragen, dan moedigt GitHub het forken van een project toe. Als je op een project pagina belandt, die interessant lijkt en je wilt er een beetje op hacken, dan kun je de "fork" knop klikken aan de bovenkant van het project om GitHub dat project te laten kopieeren naar jouw gebruiker zodat je er naar kunt pushen.
+Als je aan een bestaand project waarop je geen push toegang hebt wilt bijdragen, dan moedigt GitHub het forken van een project toe. Als je op een project pagina belandt, die interessant lijkt en je wilt er een beetje op hacken, dan kun je de "fork" knop klikken aan de bovenkant van het project om GitHub dat project te laten kopiëren naar jouw gebruiker zodat je er naar kunt pushen.
 
 Op deze manier hoeven projecten zich geen zorgen te maken over het toevoegen van medewerkers om ze push toegang te geven. Mensen kunnen een project forken en ernaar pushen, en de hoofdeigenaar van het project kan die wijzigingen pullen door ze als remotes toe te voegen en hun werk te mergen.
 
@@ -882,6 +885,6 @@ Dat is alles wat we laten zien over GitHub, maar het is belangrijk om te zien ho
 
 Je hebt meerdere opties om een remote Git repository werkend te krijgen zodat je kunt samenwerken met anderen of je werk kunt delen.
 
-Je eigen server draaien geeft je veel controle en staat je toe om de server binnen je firewall te draaien, maar zo'n server vraagt over het algemeen een redelijke hoeveelheid tijd om in te stellen en te onderhouden. Als je je gegevens op een beheerde server plaatst, is het eenvoudig in te stellen en te onderhouden; maar je moet in staat zijn je code op iemand anders zijn servers te bewaren, en sommige organisaties staan dit niet toe.
+Je eigen server draaien geeft je veel controle en stelt je in staat om de server binnen je firewall te draaien, maar zo'n server vraagt over het algemeen een redelijke hoeveelheid tijd om in te stellen en te onderhouden. Als je je gegevens op een beheerde server plaatst, is het eenvoudig in te stellen en te onderhouden; maar je moet wel willen dat je code op de server van een derde opgeslagen is, en sommige organisaties staan dit niet toe.
 
 Het zou redelijk rechttoe rechtaan moeten zijn om te bepalen welke oplossing of combinatie van oplossingen van toepassing is op jou en je organisatie.

From acf71489dd1cfe8455d9ec3cb6de85f47cdacab7 Mon Sep 17 00:00:00 2001
From: Ralph Haussmann <ralph@scanmyfood.de>
Date: Mon, 20 Jan 2014 16:52:03 +0100
Subject: [PATCH 123/690] [de] Enhance section 9

---
 de/09-git-internals/01-chapter9.markdown | 134 +++++++++++------------
 1 file changed, 67 insertions(+), 67 deletions(-)

diff --git a/de/09-git-internals/01-chapter9.markdown b/de/09-git-internals/01-chapter9.markdown
index d17dafdbc..6f92c1d00 100644
--- a/de/09-git-internals/01-chapter9.markdown
+++ b/de/09-git-internals/01-chapter9.markdown
@@ -3,15 +3,15 @@
 
 <!--You may have skipped to this chapter from a previous chapter, or you may have gotten here after reading the rest of the book — in either case, this is where you’ll go over the inner workings and implementation of Git. I found that learning this information was fundamentally important to understanding how useful and powerful Git is, but others have argued to me that it can be confusing and unnecessarily complex for beginners. Thus, I’ve made this discussion the last chapter in the book so you could read it early or later in your learning process. I leave it up to you to decide.-->
 
-Möglicherweise hast Du dieses Kapitel hier direkt aufgeschlagen, vorherige Kapitel ausgelassen, oder bist hierher gelangt, nachdem Du alle vorherigen Kapitel gelesen hast. Wie auch immer, in diesem Kapitel wirst Du mit mit der internen Funktionsweise und der Implementierung von Git befassen. Meine eigene Erfahrung ist, dass das Lernen dieser Dinge unerlässlich ist, um zu verstehen, wie unheimlich mächtig und flexibel Git ist. Allerdings gibt es Leute, die der Ansicht sind, dass sie auch verwirrend und unnötig komplex für Anfänger sein können. Deshalb habe ich mich entschieden, dieses Kapitel an das Ende des Buches zu verlegen. Du kannst es, ganz wie es Dir beliebt, früher oder später einschieben.
+Möglicherweise hast Du dieses Kapitel hier direkt aufgeschlagen, vorherige Kapitel ausgelassen, oder bist hierher gelangt, nachdem Du alle vorherigen Kapitel gelesen hast. Wie auch immer, in diesem Kapitel werden wir uns mit der internen Funktionsweise und der Implementierung von Git befassen. Meine eigene Erfahrung ist, dass das Lernen dieser Dinge unerlässlich ist, um zu verstehen, wie unheimlich mächtig und flexibel Git ist. Allerdings gibt es Leute, die der Ansicht sind, dass sie auch verwirrend und unnötig komplex für Anfänger sein können. Deshalb habe ich mich entschieden, dieses Kapitel an das Ende des Buches zu verlegen. Du kannst es, ganz wie es Dir beliebt, früher oder später einschieben.
 
 <!--Now that you’re here, let’s get started. First, if it isn’t yet clear, Git is fundamentally a content-addressable filesystem with a VCS user interface written on top of it. You’ll learn more about what this means in a bit.-->
 
-Lass uns also loslegen. Zunächst will ich betonen, falls das bisher noch nicht klargeworden ist, dass Git im seinen Grundzügen ein Dateisystem ist, dessen Inhalte addressierbar sind und auf dem ein VCS-Interface aufgesetzt ist. Wir werden gleich genauer darauf eingehen, was das heißt.
+Lass uns also loslegen. Zunächst will ich betonen, falls das bisher noch nicht klargeworden ist, dass Git im seinen Grundzügen ein Dateisystem ist, dessen Inhalte addressierbar sind und auf dem eine VCS-Schnittstelle aufgesetzt ist. Wir werden gleich genauer darauf eingehen, was das heißt.
 
 <!--In the early days of Git (mostly pre 1.5), the user interface was much more complex because it emphasized this filesystem rather than a polished VCS. In the last few years, the UI has been refined until it’s as clean and easy to use as any system out there; but often, the stereotype lingers about the early Git UI that was complex and difficult to learn.-->
 
-In den frühen Tagen von Git (d.h. vor Version 1.5) war das Interface sehr viel komplexer, weil es diese Dateisystem-Eigenschaften stark betonte – im Gegensatz zu einem ausgearbeiteten VCS. In den letzten Jahren wurde das Interface dann stückweise verbessert und verfeinert, sodass es heute so einfach verständlich und einfach zu verwenden ist, wie alle möglichen vergleichbaren Systeme, die es gibt. Allerdings besteht scheinbar weiterhin das Vorurteil, das Git-Interface sei komplex und schwer zu erlernen.
+In den frühen Tagen von Git (d.h. vor Version 1.5) war die Benutzerschnittstelle sehr viel komplexer, weil es die Dateisystem-Eigenschaften stark betonte – im Gegensatz zu einem herkömmlichen VCS. In den letzten Jahren wurde die Benutzerschnittstelle dann stückweise verbessert und verfeinert, sodass es heute so einfach verständlich und einfach zu verwenden ist, wie andere vergleichbare Systeme, die auf dem Markt erhältlich sind. Allerdings besteht scheinbar weiterhin das Vorurteil, das Git-Interface sei komplex und schwer zu erlernen.
 
 <!--The content-addressable filesystem layer is amazingly cool, so I’ll cover that first in this chapter; then, you’ll learn about the transport mechanisms and the repository maintenance tasks that you may eventually have to deal with.-->
 
@@ -30,7 +30,7 @@ Die ersten acht Kapitel dieses Buches haben sich fast ausschließlich mit „Por
 
 <!--When you run `git init` in a new or existing directory, Git creates the `.git` directory, which is where almost everything that Git stores and manipulates is located. If you want to back up or clone your repository, copying this single directory elsewhere gives you nearly everything you need. This entire chapter basically deals with the stuff in this directory. Here’s what it looks like:-->
 
-Wenn Du `git init` in einem neuen oder bereits bestehenden Verzeichnis ausführst, erzeugt Git das `.git`-Verzeichnis, das fast alle Dateien enthält, die Git intern speichert und ändert. Wenn Du eine Sicherheitskopie Deines Repositorys anlegen oder es duplizieren willst, dann reicht aus, dieses Verzeichnis zu kopieren. Dieses ganze Kapitel handelt praktisch nur von den Inhalten dieses Verzeichnisses – die so aussehen:
+Wenn Du `git init` in einem neuen oder bereits bestehenden Verzeichnis ausführst, erzeugt Git das `.git`-Verzeichnis, das fast alle Dateien enthält, die Git intern speichert und ändert. Wenn Du eine Sicherheitskopie Deines Repositorys anlegen oder es duplizieren willst, dann reicht es aus, dieses Verzeichnis zu kopieren. Dieses ganze Kapitel handelt praktisch nur von den Inhalten dieses Verzeichnisses. Schauen wir es uns einmal an:
 
 	$ ls
 	HEAD
@@ -49,7 +49,7 @@ Möglicherweise findest Du darin weitere Dateien. Obiges stammt aus einem mit `g
 
 <!--This leaves four important entries: the `HEAD` and `index` files and the `objects` and `refs` directories. These are the core parts of Git. The `objects` directory stores all the content for your database, the `refs` directory stores pointers into commit objects in that data (branches), the `HEAD` file points to the branch you currently have checked out, and the `index` file is where Git stores your staging area information. You’ll now look at each of these sections in detail to see how Git operates.-->
 
-Damit bleiben vier wichtige Einträge übrig: die Dateien `HEAD` und `index` und die Verzeichnisse `objects` und `refs`. Dies sind die Kernkomponenten eines Git-Repositorys: Im `objects`-Verzeichnis befinden sich die Inhalte der Datenbank. Das `refs`-Verzeichnis enthält Referenzen auf Commit-Objekte (Branches) in dieser Datenbank. Die Datei `HEAD` zeigt auf denjeningen Branch, den Du gegenwärtig ausgecheckt hast, und in der Datei `index` verwaltet Git die Informationen der Staging-Area. Wir werden auf diese Elemente jetzt im einzelnen darauf eingehen, sodass Du nachvollziehen kannst, wie Git intern arbeitet.
+Damit bleiben vier wichtige Einträge übrig: die Dateien `HEAD` und `index` und die Verzeichnisse `objects` und `refs`. Dies sind die Kernkomponenten eines Git-Repositorys. Im `objects`-Verzeichnis befinden sich die Inhalte der Datenbank. Das `refs`-Verzeichnis enthält Referenzen auf Commit-Objekte (Branches) in dieser Datenbank. Die Datei `HEAD` zeigt auf denjeningen Branch, den Du gegenwärtig ausgecheckt hast, und in der Datei `index` verwaltet Git die Informationen der Staging-Area. Wir werden auf diese Elemente jetzt im einzelnen darauf eingehen, sodass Du nachvollziehen kannst, wie Git intern arbeitet.
 
 <!--## Git Objects ##-->
 ## Git Objekte ##
@@ -57,7 +57,7 @@ Damit bleiben vier wichtige Einträge übrig: die Dateien `HEAD` und `index` und
 <!--Git is a content-addressable filesystem. Great. What does that mean?-->
 <!--It means that at the core of Git is a simple key-value data store. You can insert any kind of content into it, and it will give you back a key that you can use to retrieve the content again at any time. To demonstrate, you can use the plumbing command `hash-object`, which takes some data, stores it in your `.git` directory, and gives you back the key the data is stored as. First, you initialize a new Git repository and verify that there is nothing in the `objects` directory:-->
 
-Git ist ein Dateisystem, das Inhalte addressieren kann. Prima. Aber was heißt das? Es bedeutet, dass Git im Kern nichts anderes ist als ein einfacher Key-Value-Store („Schlüssel-Wert-Speicher“). Du kannst darin jede Art von Inhalt ablegen und Git wird einen Schlüssel dafür zurückgeben, den Du dann verwenden kannst, um diesen Inhalt jederzeit nachzuschlagen. Um das auszuprobieren, kannst Du den Plumbing-Befehl `hash-object` verwenden. Dieser nimmt einen Inhalt an, speichert ihn in Deinem `.git`-Verzeichnis und gibt Dir den Schlüssel zurück, unter dem der Inhalt gespeichert wurde. Dazu initialisierst Du als erstes ein neues Git-Repository und verifizierst, dass das `objects`-Verzeichnis leer ist:
+Git ist ein Dateisystem, das Inhalte addressieren kann. Prima. Aber was heißt das? Es bedeutet, dass Git im Kern nichts anderes ist als ein einfacher Key-Value-Store („Schlüssel-Wert-Speicher“). Du kannst darin jede Art von Inhalt ablegen und Git wird einen Schlüssel dafür zurückgeben, den Du dann verwenden kannst, um diesen Inhalt jederzeit nachzuschlagen. Um das auszuprobieren, kannst Du den Plumbing-Befehl `hash-object` verwenden. Dieser nimmt Daten entgegen, speichert diese in Deinem `.git`-Verzeichnis und gibt Dir den Schlüssel zurück, unter dem der Inhalt gespeichert wurde. Dazu initialisierst Du als erstes ein neues Git-Repository und verifizierst, dass das `objects`-Verzeichnis leer ist:
 
 	$ mkdir test
 	$ cd test
@@ -79,25 +79,25 @@ Git hat also ein Verzeichnis `objects` und darin die Unterverzeichnisse `pack` u
 
 <!--The `-w` tells `hash-object` to store the object; otherwise, the command simply tells you what the key would be. `-\-stdin` tells the command to read the content from stdin; if you don’t specify this, `hash-object` expects the path to a file. The output from the command is a 40-character checksum hash. This is the SHA-1 hash — a checksum of the content you’re storing plus a header, which you’ll learn about in a bit. Now you can see how Git has stored your data:-->
 
-Die Option `-w` weist `git hash-object` an, das Objekt zu speichern. Andernfalls würde Dir der Befehl lediglich den Schlüssel mitteilen. `--stdin` weist den Befehl an, den Inhalt von aus der Standardeingabe zu lesen. Wenn Du diese Option weglässt, erwartet der Befehl zusätzlich einen Dateipfad. Die Ausgabe ist eine 40 Zeichen langer SHA-1-Hash, der eine Prüfsumme des gespeicherten Inhaltes darstellt (wir gehen auf diese Hashes gleich noch genauer ein). Git hat jetzt außerdem eine neue Datei in der Datenbank angelegt:
+Die Option `-w` weist `git hash-object` an, das Objekt zu speichern. Andernfalls würde Dir der Befehl lediglich den Schlüssel mitteilen. `--stdin` weist den Befehl an, den Inhalt von der Standardeingabe einzulesen. Wenn Du diese Option weglässt, erwartet der Befehl zusätzlich einen Dateipfad. Die Ausgabe ist ein 40 Zeichen langer SHA-1-Hash, der eine Prüfsumme des gespeicherten Inhaltes darstellt (wir gehen auf diese Hashes gleich noch genauer ein). Git hat jetzt außerdem eine neue Datei in der Datenbank angelegt:
 
 	$ find .git/objects -type f
 	.git/objects/d6/70460b4b4aece5915caf5c68d12f560a9fe3e4
 
 <!--You can see a file in the `objects` directory. This is how Git stores the content initially — as a single file per piece of content, named with the SHA-1 checksum of the content and its header. The subdirectory is named with the first 2 characters of the SHA, and the filename is the remaining 38 characters.-->
 
-Du siehst im `objects` Verzeichnis genau eine Datei. Auf diese Weise Git speichert Inhalte anfänglich: in jeweils einer Datei pro Inhalt, referenziert durch den SHA-1-Hash des Inhaltes und seiner Kopfzeile. Der Name des Unterverzeichnis `d6` sind die ersten zwei Zeichen des SHA-1-Hashes und der Dateiname die verbleibenden 38 Zeichen.
+Jetzt liegt im Verzeichnis `objects` genau eine Datei. Anfangs speichert Git den Inhalt auf diese Art und Weise: In jeweils einer einzelnen Datei werden die Daten gespeichert, referenziert durch den SHA-1-Hash des Inhaltes und seines Headers. Der Name des Unterverzeichnis `d6` entspricht den ersten zwei Zeichen des SHA-1-Hashes. Die verbleibenden 38 Zeichen werden als Dateiname verwendet.
 
 <!--You can pull the content back out of Git with the `cat-file` command. This command is sort of a Swiss army knife for inspecting Git objects. Passing `-p` to it instructs the `cat-file` command to figure out the type of content and display it nicely for you:-->
 
-Mit dem Befehl `git cat-file` kannst Du den jeweiligen Inhalt nachschlagen. Dieser Befehl ist so etwas wie ein Schweizer Taschenmesser, wenn es um Objekte in der Git-Datenbank geht. Wenn Du die Option `-p` übergibst, versucht `git cat-file`, die Art des Inhaltes herauszufinden und die Anzeige entsprechend lesbar zu formatieren:
+Mit dem Befehl `git cat-file` kannst Du den jeweiligen Inhalt nachschlagen. Dieser Befehl ist so etwas wie ein Schweizer Taschenmesser, wenn es um Objekte in der Git-Datenbank geht. Wenn Du die Option `-p` übergibst, versucht `git cat-file`, die Art des Inhaltes herauszufinden und lesbar darzustellen:
 
 	$ git cat-file -p d670460b4b4aece5915caf5c68d12f560a9fe3e4
 	test content
 
 <!--Now, you can add content to Git and pull it back out again. You can also do this with content in files. For example, you can do some simple version control on a file. First, create a new file and save its contents in your database:-->
 
-Auf diese Weise kannst Du also Inhalte zu Git hinzufügen und von dort wieder nachschlagen. Das klappt auch mit Dateiinhalten. Wenn Du beispielsweise eine einzelne Datei versionskontrollieren willst, lege die Datei zunächst an und speichere ihren Inhalt in der Datenbank:
+Auf diese Weise kannst Du also Inhalte zu Git hinzufügen und von dort wieder auslesen. Das klappt auch mit Dateiinhalten. Wenn Du beispielsweise eine einzelne Datei versionieren willst, legst Du dazu die Datei zunächst an und speicherst ihren Inhalt in der Datenbank:
 
 	$ echo 'version 1' > test.txt
 	$ git hash-object -w test.txt
@@ -148,7 +148,7 @@ Sich den SHA-1-Hash für jede Version merken zu müssen, ist allerdings nicht so
 
 <!--The next type you’ll look at is the tree object, which solves the problem of storing the filename and also allows you to store a group of files together. Git stores content in a manner similar to a UNIX filesystem, but a bit simplified. All the content is stored as tree and blob objects, with trees corresponding to UNIX directory entries and blobs corresponding more or less to inodes or file contents. A single tree object contains one or more tree entries, each of which contains a SHA-1 pointer to a blob or subtree with its associated mode, type, and filename. For example, the most recent tree in the simplegit project may look something like this:-->
 
-Als Nächstes schauen wir uns den Objekttyp „Tree“ (Baum) an, der es ermöglicht, Dateinamen zu speichern und Dateien zu gruppieren. Git speichert Inhalte in einer ähnlichen Weise wie das UNIX-Dateisystem, allerdings ein bisschen vereinfacht. Sie werden als Tree- und Blob-Objekte abgelegt, wobei die Trees mit UNIX-Verzeichnis-Einträgen korrespondieren und Blobs mehr oder weniger mit den inode-Einträgen bzw. Datei-Inhalten. Ein einzelnes Baum-Objekt enthält einen oder mehrere Einträge, von denen jeder ein SHA-1-Hash ist, der wiederum einen Blob oder einen Untertree referenziert. Jeder dieser Einträge verfügt außerdem über einen Modus, Typ und Dateinamen. Beispielsweise sieht das aktuelle Tree-Objekt im simplegit-Projekt möglicherweise so aus:
+Als Nächstes schauen wir uns den Objekttyp „Tree“ (Baum) an, der es ermöglicht, Dateinamen zu speichern und Dateien zu gruppieren. Git speichert Inhalte in einer ähnlichen Weise wie das UNIX-Dateisystem, allerdings ein bisschen vereinfacht. Sie werden als Tree- und Blob-Objekte abgelegt, wobei die Trees mit UNIX-Verzeichnis-Einträgen korrespondieren und Blobs mehr oder weniger mit den Inode-Einträgen bzw. Datei-Inhalten. Ein einzelnes Baum-Objekt enthält einen oder mehrere Einträge, von denen jeder ein SHA-1-Hash ist, der wiederum einen Blob oder einen Untertree referenziert. Jeder dieser Einträge verfügt außerdem über einen Modus, Typ und Dateinamen. Beispielsweise sieht das aktuelle Tree-Objekt im simplegit-Projekt möglicherweise so aus:
 
 	$ git cat-file -p master^{tree}
 	100644 blob a906cb2a4a904a152e80877d4088654daad0c859      README
@@ -157,7 +157,7 @@ Als Nächstes schauen wir uns den Objekttyp „Tree“ (Baum) an, der es ermögl
 
 <!--The `master^{tree}` syntax specifies the tree object that is pointed to by the last commit on your `master` branch. Notice that the `lib` subdirectory isn’t a blob but a pointer to another tree:-->
 
-Die `master^{tree}`-Syntax spezifiziert, dass wir an dem Tree-Objekt interessiert sind, auf das der letzte Commit des `master`-Branches zeigt. Beachte, dass das Unterverzeichnis `lib` nicht auf ein Blob, sondern wiederum auf einen weiteren Baum zeigt.
+Die `master^{tree}`-Syntax spezifiziert, dass wir an dem Tree-Objekt interessiert sind, auf das der letzte Commit des Branches `master` zeigt. Beachte, dass das Unterverzeichnis `lib` nicht auf ein Blob, sondern wiederum auf einen weiteren Baum zeigt.
 
 	$ git cat-file -p 99f1a6d12cb4b6f19c8655fca46c3ecf317074e0
 	100644 blob 47c6340d6459e05787f644c2447d2595f5d3a54b      simplegit.rb
@@ -173,7 +173,7 @@ Bild 9-1. Vereinfachte Darstellung des Git-Datenmodels.
 
 <!--You can create your own tree. Git normally creates a tree by taking the state of your staging area or index and writing a tree object from it. So, to create a tree object, you first have to set up an index by staging some files. To create an index with a single entry — the first version of your test.txt file — you can use the plumbing command `update-index`. You use this command to artificially add the earlier version of the test.txt file to a new staging area. You must pass it the `-\-add` option because the file doesn’t yet exist in your staging area (you don’t even have a staging area set up yet) and `-\-cacheinfo` because the file you’re adding isn’t in your directory but is in your database. Then, you specify the mode, SHA-1, and filename:-->
 
-Du kannst auch Deine eigenen Tree-Objekte anlegen. Git erzeugt Trees normalerweise, indem es die Inhalte der Staging-Area nimmt und als ein Tree-Objekt speichert. D.h., um ein Tree-Objekt anzulegen, musst Du zunächst einen Index (d.h. eine Staging-Area) erzeugen, indem Du einige Dateien hinzufügst. Um einen einzelnen Eintrag in den Index zu schreiben – z.B. die erste version der Datei test.txt – kannst Du den Plumbing-Befehl `git update-index` verwenden, der eine frühere Version dieser Datei künstlich zu einer neuen Staging-Area hinzufügt. Du musst ihm die Option `--add` übergeben, weil die Datei bisher noch nicht in der Staging-Area enthalten ist (Du hast ja bisher noch überhaupt keine Staging-Area aufgesetzt), und die Option `--cacheinfo`, weil Du eine Datei hinzufügst, die sich nicht in Deinem Verzeichnis befindet, sondern in der Datenbank. Du gibst außerdem den Modus, SHA-1-Hash und den Dateinamen an:
+Du kannst auch Deine eigenen Tree-Objekte anlegen. Git erzeugt Trees normalerweise, indem es die Inhalte der Staging-Area nimmt und als ein Tree-Objekt speichert. D.h., um ein Tree-Objekt anzulegen, musst Du zunächst einen Index (d.h. eine Staging-Area) aufbauen, indem Du einige Dateien hinzufügst. Um einen einzelnen Eintrag in den Index zu schreiben – z.B. die erste version der Datei test.txt – kannst Du den Plumbing-Befehl `git update-index` verwenden, der eine frühere Version dieser Datei künstlich zu einer neuen Staging-Area hinzufügt. Du musst ihm die Option `--add` übergeben, weil die Datei bisher noch nicht in der Staging-Area enthalten ist (Du hast ja bisher noch überhaupt keine Staging-Area aufgesetzt), und die Option `--cacheinfo`, weil Du eine Datei hinzufügst, die sich nicht in Deinem Verzeichnis befindet, sondern in der Datenbank. Du gibst außerdem den Modus, SHA-1-Hash und den Dateinamen an:
 
 	$ git update-index --add --cacheinfo 100644 \
 	  83baae61804e65cc73a7201a7252750c76066a30 test.txt
@@ -193,14 +193,14 @@ Jetzt kannst Du den Befehl `git write-tree` verwenden, um die Staging-Area als T
 
 <!--You can also verify that this is a tree object:-->
 
-Um zu überprüfen, dass es wirklich ein Tree-Objekt gibt:
+Um zu überprüfen, ob es sich wirklich um ein Tree-Objekt handelt:
 
 	$ git cat-file -t d8329fc1cc938780ffdd9f94e0d364e0ea74f579
 	tree
 
 <!--You’ll now create a new tree with the second version of test.txt and a new file as well:-->
 
-Jetzt erzeugen wir einen neuen Tree mit der zweiten Version der Datei test.txt sowie eine neue Datei:
+Jetzt erzeugen wir einen neuen Tree mit der zweiten Version der Datei test.txt sowie einer neuen Datei:
 
 	$ echo 'new file' > new.txt
 	$ git update-index test.txt
@@ -218,7 +218,7 @@ Die Staging-Area enthält jetzt eine neue Version der Datei test.txt sowie die n
 
 <!--Notice that this tree has both file entries and also that the test.txt SHA is the "version 2" SHA from earlier (`1f7a7a`). Just for fun, you’ll add the first tree as a subdirectory into this one. You can read trees into your staging area by calling `read-tree`. In this case, you can read an existing tree into your staging area as a subtree by using the `-\-prefix` option to `read-tree`:-->
 
-Beachte, dass das Tree-Objekt zwei Datei-Einträge hat und dass der SHA-1-Hash der Datei test.txt noch derselbe „Version 2“-Hash ist wie zuvor (`1f7a7a`). Fügen wir jetzt den ersten Tree als ein Unterverzeichnis in diesem hier ein. Du kannst einen Tree mit `git read-tree` in die Staging-Area einlesen. In diesem Fall können wir einen bereits existierenden Tree als einen Untertree zur Staging-Area hinzufügen, indem wir die Option `--prefix` verwenden:
+Beachte, dass das Tree-Objekt beide Datei-Einträge hat und dass der SHA-1-Hash der Datei test.txt noch derselbe „Version 2“-Hash ist wie zuvor (`1f7a7a`). Fügen wir jetzt den ersten Tree als ein Unterverzeichnis in diesem hier ein. Du kannst einen Tree mit `git read-tree` in die Staging-Area einlesen. In diesem Fall können wir einen bereits existierenden Tree als einen Untertree zur Staging-Area hinzufügen, indem wir die Option `--prefix` verwenden:
 
 	$ git read-tree --prefix=bak d8329fc1cc938780ffdd9f94e0d364e0ea74f579
 	$ git write-tree
@@ -242,18 +242,18 @@ Bild 9-2. Die Datenstruktur des gegenwärtigen Git-Repositorys.
 
 <!--You have three trees that specify the different snapshots of your project that you want to track, but the earlier problem remains: you must remember all three SHA-1 values in order to recall the snapshots. You also don’t have any information about who saved the snapshots, when they were saved, or why they were saved. This is the basic information that the commit object stores for you.-->
 
-Du hast jetzt drei Trees, die verschiedene Snapshots Deines Projektes spezifizieren, die Du nachverfolgen willst. Das ursprüngliche Problem besteht aber weiterhin: Du musst dir alle drei SHA-1-Hashwerte merken, um wieder an die Snapshots zu kommen. Ebenso fehlen Dir die Informationen darüber, wer die Snapshots gespeichert hat, wann sie gespeichert wurden und warum. Dies sind die drei Hauptinformationen, die ein Commit-Objekt für uns speichert.
+Du hast jetzt drei Trees, die verschiedene Snapshots Deines Projektes spezifizieren, die Du nachverfolgen willst. Das ursprüngliche Problem besteht aber weiterhin: Du musst Dir alle drei SHA-1-Hashwerte merken, um wieder an die Snapshots zu kommen. Ebenso fehlen Dir die Informationen darüber, wer die Snapshots gespeichert hat, wann sie gespeichert wurden und warum. Dies sind die drei Hauptinformationen, die ein Commit-Objekt für uns speichert.
 
 <!--To create a commit object, you call `commit-tree` and specify a single tree SHA-1 and which commit objects, if any, directly preceded it. Start with the first tree you wrote:-->
 
-Um ein Commit-Objekt anzulegen, verwendest Du den Befehl `git commit-tree`, spezifizierst den SHA-1-Hash eines einzelnen Trees und welche Commit-Objekte (sofern vorhanden) die direkten Vorgänger sind. Fangen wir damit an, den ersten Tree, den Du angelegt hast, zu committen:
+Um ein Commit-Objekt anzulegen, verwendest Du den Befehl `git commit-tree`, spezifizierst den SHA-1-Hash eines einzelnen Trees und welche Commit-Objekte (sofern vorhanden) die direkten Vorgänger sind. Fangen wir damit an, den ersten Tree, den Du angelegt hast, einzuchecken:
 
 	$ echo 'first commit' | git commit-tree d8329f
 	fdf4fc3344e67ab068f836878b6c4951e3b15f3d
 
 <!--Now you can look at your new commit object with `cat-file`:-->
 
-Du kannst diesen Commit jetzt mit `git cat-file` nachschlagen:
+Du kannst Dir dann dieses neue Commit-Objekt mit `cat-file` anschauen:
 
 	$ git cat-file -p fdf4fc3
 	tree d8329fc1cc938780ffdd9f94e0d364e0ea74f579
@@ -264,7 +264,7 @@ Du kannst diesen Commit jetzt mit `git cat-file` nachschlagen:
 
 <!--The format for a commit object is simple: it specifies the top-level tree for the snapshot of the project at that point; the author/committer information pulled from your `user.name` and `user.email` configuration settings, with the current timestamp; a blank line, and then the commit message.-->
 
-Das Format für ein Commit-Objekt ist einfach: es besteht aus dem obersten Tree für den Snapshot des Projektes zum gegebenen Zeitpunkt, die Autoren- und ggf. Committer-Information (jeweils entsprechend Deiner `user.name`- und `user.email`-Konfiguration) und dem Timestamp. Dann folgen eine leere Zeile und die Commit-Meldung.
+Das Format für ein Commit-Objekt ist einfach: es besteht aus dem obersten Tree für den Snapshot des Projektes zum gegebenen Zeitpunkt, die Autoren- und ggf. Committer-Information (jeweils entsprechend Deiner `user.name`- und `user.email`-Konfiguration) und dem aktuellen Zeitstempel. Dann folgen eine leere Zeile und die Commit-Nachricht.
 
 <!--Next, you’ll write the other two commit objects, each referencing the commit that came directly before it:-->
 
@@ -277,7 +277,7 @@ Als Nächstes speichern wir die beiden anderen Commit-Objekte und referenzieren
 
 <!--Each of the three commit objects points to one of the three snapshot trees you created. Oddly enough, you have a real Git history now that you can view with the `git log` command, if you run it on the last commit SHA-1:-->
 
-Jedes der drei Commit-Objekte zeigt auf einen der drei Snapshot-Trees, die Du zuvor gespeichert hattest. Es mag Dich überraschen, aber Du hast jetzt bereits eine vollständige Git-Historie, die Du mit dem `git log` inspizieren kannst, indem Du den SHA-1-Hash des letzten Commits angibst:
+Jedes der drei Commit-Objekte zeigt auf einen der drei Snapshot-Trees, die Du zuvor gespeichert hattest. Es mag Dich überraschen, aber Du hast jetzt bereits eine vollständige Git-Historie, die Du mit dem Befehl `git log` inspizieren kannst, indem Du den SHA-1-Hash des letzten Commits angibst:
 
 	$ git log --stat 1a410e
 	commit 1a410efbd13591db07496601ebc7a059dd55cfe9
@@ -326,7 +326,7 @@ Fantastisch, oder? Du hast jetzt sämtliche Low-Level-Operationen durchgeführt,
 
 <!--If you follow all the internal pointers, you get an object graph something like Figure 9-3.-->
 
-Wenn man all diese Zeiger auflöst, erhält man einen Objekt-Graphen wie den folgenden (Bild 9-3).
+Wenn man all diese internen Zeiger nachverfolgt, erhält man einen Objekt-Graphen wie den folgenden (Bild 9-3).
 
 <!--Figure 9-3. All the objects in your Git directory.-->
 
@@ -338,7 +338,7 @@ Bild 9-3. Alle Objekte in Deinem Git-Repository.
 
 <!--I mentioned earlier that a header is stored with the content. Let’s take a minute to look at how Git stores its objects. You’ll see how to store a blob object — in this case, the string "what is up, doc?" — interactively in the Ruby scripting language. You can start up interactive Ruby mode with the `irb` command:-->
 
-Wir haben kurz erwähnt, dass zusammen mit einem Inhalt ein Header gespeichert wird. Schauen wir uns also genauer an, wie genau Git Objekte speichert. Du wirst sehen, wie ein Blob-Objekt – in diesem Fall die Zeichenkette „what is up, doc?“ gespeichert wird. Dazu nuten wir den interaktiven Ruby-Modus, den Du mit dem `irb` Befehl starten kannst:
+Ich habe bereits erwähnt, dass zusammen mit dem jeweiligen Inhalt ein Header gespeichert wird. Schauen wir uns also genauer an, wie genau Git Objekte speichert. Du wirst sehen, wie ein Blob-Objekt – in diesem Fall die Zeichenkette „what is up, doc?“ gespeichert wird. Dazu nutzen wir den interaktiven Ruby-Modus, den Du mit dem Befehl `irb` starten kannst:
 
 	$ irb
 	>> content = "what is up, doc?"
@@ -353,7 +353,7 @@ Git erzeugt einen Header, der mit dem Objekttyp beginnt, in diesem Fall ist das
 
 <!--Git concatenates the header and the original content and then calculates the SHA-1 checksum of that new content. You can calculate the SHA-1 value of a string in Ruby by including the SHA1 digest library with the `require` command and then calling `Digest::SHA1.hexdigest()` with the string:-->
 
-Git fügt diesen Header mit dem ursprünglichen Inhalt zusammen und kalkuliert aus dem Ergebnis die SHA-1-Prüfsumme (Hash). Du kannst einen SHA-1-Hash in Ruby berechnen, indem Du die SHA1-Digest-Bibliothek mit `require` einbindest und dann `Digest::SHA1.hexdigest()` mit der Zeichenkette ausführst:
+Git fügt diesen Header mit dem ursprünglichen Inhalt zusammen und kalkuliert aus dem Ergebnis die SHA-1-Prüfsumme. Du kannst einen SHA-1-Hash in Ruby berechnen, indem Du die SHA1-Digest-Bibliothek mit `require` einbindest und dann `Digest::SHA1.hexdigest()` mit der Zeichenkette ausführst:
 
 	>> store = header + content
 	=> "blob 16\000what is up, doc?"
@@ -373,7 +373,7 @@ Git komprimiert den neuen Inhalt (d.h. inklusive des Headers) mit zlib. In Ruby
 
 <!--Finally, you’ll write your zlib-deflated content to an object on disk. You’ll determine the path of the object you want to write out (the first two characters of the SHA-1 value being the subdirectory name, and the last 38 characters being the filename within that directory). In Ruby, you can use the `FileUtils.mkdir_p()` function to create the subdirectory if it doesn’t exist. Then, open the file with `File.open()` and write out the previously zlib-compressed content to the file with a `write()` call on the resulting file handle:-->
 
-Schließlich schreibst Du den zlib-komprimierten Inhalt in eine Datei auf der Festplatte. Dazu bestimmst Du den Pfad, an den die Datei gespeichert wird (die ersten beiden Zeichen für das Unterverzeichnis und die verbleibenden 38 Zeichen für den Dateinamen). In Ruby kannst Du die Funktion `FileUtils.mkdir_p()` verwenden, um Unterverzeichnisse anzulegen, die noch nicht existieren. Dann öffnest die Datei mit `File.open()` und schreibst den komprimierten Inhalt mit `write()` in die Datei:
+Schließlich schreibst Du den zlib-komprimierten Inhalt in eine Datei auf der Festplatte. Dazu bestimmst Du den Pfad, an den die Datei gespeichert wird (die ersten beiden Zeichen für das Unterverzeichnis und die verbleibenden 38 Zeichen für den Dateinamen). In Ruby kannst Du die Funktion `FileUtils.mkdir_p()` verwenden, um Unterverzeichnisse anzulegen, die noch nicht existieren. Dann öffnest Du die Datei mit `File.open()` und schreibst den komprimierten Inhalt mit `write()` in die Datei:
 
 	>> path = '.git/objects/' + sha1[0,2] + '/' + sha1[2,38]
 	=> ".git/objects/bd/9dbf5aae1a3862dd1526723246b20206e5fc37"
@@ -386,7 +386,7 @@ Schließlich schreibst Du den zlib-komprimierten Inhalt in eine Datei auf der Fe
 
 <!--That’s it — you’ve created a valid Git blob object. All Git objects are stored the same way, just with different types — instead of the string blob, the header will begin with commit or tree. Also, although the blob content can be nearly anything, the commit and tree content are very specifically formatted.-->
 
-Das ist alles – Du hast jetzt ein valides Git-Blob-Objekt geschrieben. Git-Objekte werden immer in dieser Weise gespeichert, lediglich mit verschiedenen Typen, d.h. anstelle der Zeichenkette „blob“ wird der Header mit „commit“ oder „tree“ anfangen. Außerdem sind Commit- und Tree-Inhalte auf eine sehr spezifische Weise formatiert, während Blobs beliebige Inhalte sein können.
+Das ist alles – Du hast jetzt ein gültiges Blob-Objekt geschrieben. Git-Objekte werden immer in dieser Weise gespeichert, lediglich mit verschiedenen Typen, d.h. anstelle der Zeichenkette „blob“ wird der Header mit „commit“ oder „tree“ anfangen. Außerdem sind Commit- und Tree-Inhalte auf eine sehr spezifische Weise formatiert, während Blobs beliebige Inhalte sein können.
 
 <!--## Git References ##-->
 ## Git-Referenzen ##
@@ -397,7 +397,7 @@ Du kannst Befehle wie `git log 1a410e` ausführen, um die Commit-Historie zu ins
 
 <!--In Git, these are called "references" or "refs"; you can find the files that contain the SHA-1 values in the `.git/refs` directory. In the current project, this directory contains no files, but it does contain a simple structure:-->
 
-Diese Namen werden in Git intern als „references“ oder „refs“ bezeichnet. Du kannst diese Dateien, die SHA-1-Hashes enthalten, im Verzeichnis `.git/refs` finden. In unserem gegenwärtigen Projekt enthält dieses Verzeichnis noch keine Dateien, aber eine simple Verzeichnisstruktur:
+Diese Namen werden in Git intern als „references“ oder „refs“ (also Referenz bzw. Verweis) bezeichnet. Du kannst diese Dateien, die SHA-1-Hashes enthalten, im Verzeichnis `.git/refs` finden. In unserem gegenwärtigen Projekt enthält dieses Verzeichnis noch keine Dateien, aber eine simple Verzeichnisstruktur:
 
 	$ find .git/refs
 	.git/refs
@@ -452,14 +452,14 @@ Bild 9-4. Git-Verzeichnis-Objekte mit Branch-Head-Referenzen.
 
 <!--When you run commands like `git branch (branchname)`, Git basically runs that `update-ref` command to add the SHA-1 of the last commit of the branch you’re on into whatever new reference you want to create.-->
 
-Wenn Du Befehle wie `git branch (branchname)` verwendest, führt Git intern im Wesentlichen den Befehl `update-ref` aus, um den SHA-1-Hash des letzten Commits des jeweils gegenwärtigen Branches mit dem gegebenen Namen zu referenzieren.
+Wenn Du Befehle wie `git branch (Branch-Name)` verwendest, führt Git intern im Wesentlichen den Befehl `update-ref` aus, um den SHA-1-Hash des letzten Commits des jeweils gegenwärtigen Branches mit dem gegebenen Namen zu referenzieren.
 
 <!--### The HEAD ###-->
 ### Der HEAD ###
 
 <!--The question now is, when you run `git branch (branchname)`, how does Git know the SHA-1 of the last commit? The answer is the HEAD file. The HEAD file is a symbolic reference to the branch you’re currently on. By symbolic reference, I mean that unlike a normal reference, it doesn’t generally contain a SHA-1 value but rather a pointer to another reference. If you look at the file, you’ll normally see something like this:-->
 
-Die Frage ist jetzt: Wenn Du `git branch (branchname)` ausführst, woher weiß Git den SHA-1 des letzten Commits? Die Antwort ist: aus der HEAD Datei. Diese Datei ist eine symbolische Referenz auf den jeweiligen Branch, auf dem Du Dich gerade befindest. Mit „symbolischer Referenz“ meine ich, dass sie (anders als eine „normale“ Referenz) keinen SHA-1-Hash enthält, sondern stattdessen auf eine andere Referenz zeigt. Wenn Du die Datei ansiehst, findest Du normalerweise etwas wie:
+Die Frage ist jetzt: Wenn Du `git branch (Branch-Name)` ausführst, woher weiß Git den SHA-1 des letzten Commits? Die Antwort ist: aus der Datei HEAD. Diese Datei ist eine symbolische Referenz auf den jeweiligen Branch, auf dem Du Dich gerade befindest. Mit „symbolischer Referenz“ meine ich, dass sie (anders als eine „normale“ Referenz) keinen SHA-1-Hash enthält, sondern stattdessen auf eine andere Referenz zeigt. Wenn Du Dir die Datei ansiehst, findest Du normalerweise etwas wie:
 
 	$ cat .git/HEAD
 	ref: refs/heads/master
@@ -537,7 +537,7 @@ Jetzt wendest Du den Befehl `git cat-file` auf diesen SHA-1-Hash an:
 
 <!--Notice that the object entry points to the commit SHA-1 value that you tagged. Also notice that it doesn’t need to point to a commit; you can tag any Git object. In the Git source code, for example, the maintainer has added their GPG public key as a blob object and then tagged it. You can view the public key by running-->
 
-Beachte, dass der der Wert `object` auf den SHA-1 des Commits zeigt, den Du getaggt hast, und dass die `tags/v1.1` Referenz nicht direkt auf den Commit zeigt, sondern auf das Tag-Objekt. In Git kannst Du jedes beliebige Objekt taggen. Im Git-Quellcode z.B. befindet sich der öffentliche GPG-Schlüssel des Projektbetreibers als ein Blob-Objekt, sowie ein Tag, der darauf zeigt. Auf diese Weise kannst den Schlüssel so anzeigen, indem Du den folgenden Befehl im Git-Quellcode Repository ausführst:
+Beachte, dass der der Wert `object` auf den SHA-1 des Commits zeigt, den Du getaggt hast. Weiterhin muss der Eintrag nicht auf einen Commit zeigen. In Git kann man jedes beliebige Objekt taggen. Im Git-Quellcode befindet sich beispielweise der öffentliche GPG-Schlüssel des Projektbetreibers als ein Blob-Objekt, sowie ein Tag, der darauf zeigt. Du kannst Dir den öffentlichen Schlüssel anzeigen lassen, indem du den folgenden Befehl im Git-Quellcode-Repository ausführst:
 
 	$ git cat-file blob junio-gpg-pub
 
@@ -550,7 +550,7 @@ Der Linux-Kernel hat auch ein Tag-Objekt, das nicht auf einen Commit zeigt – d
 
 <!--The third type of reference that you’ll see is a remote reference. If you add a remote and push to it, Git stores the value you last pushed to that remote for each branch in the `refs/remotes` directory. For instance, you can add a remote called `origin` and push your `master` branch to it:-->
 
-Der dritte Referenztyp ist die externe Referenz („remote reference“). Wenn Du einen externen Server („remote“) definierst und dorthin pushst, merkt sich Git den zuletzt gepushten Commit für jeden Branch im `refs/remotes` Verzeichnis. Bespielsweise fügst Du einen externen Server `origin` hinzu und pushst Deinen `master` Branch dorthin:
+Der dritte Referenztyp ist die externe Referenz („remote reference“). Wenn Du einen externen Server („remote“) definierst und dorthin pushst, merkt sich Git den zuletzt gepushten Commit für jeden Branch im `refs/remotes` Verzeichnis. Bespielsweise fügst Du einen externen Server `origin` hinzu und pushst Deinen Branch `master` dorthin:
 
 	$ git remote add origin git@github.com:schacon/simplegit-progit.git
 	$ git push origin master
@@ -563,7 +563,7 @@ Der dritte Referenztyp ist die externe Referenz („remote reference“). Wenn D
 
 <!--Then, you can see what the `master` branch on the `origin` remote was the last time you communicated with the server, by checking the `refs/remotes/origin/master` file:-->
 
-Dann kannst Du herausfinden, in welchem Zustand sich der `master`-Branch auf dem `origin`-Server zuletzt befand (d.h. als Du das letzte Mal mit ihm kommuniziert hast), indem Du die Datei `refs/remotes/origin/master` anschaust:
+Dann kannst Du herausfinden, in welchem Zustand sich der Branch `master` auf dem Server `origin` zuletzt befand (d.h. als Du das letzte Mal mit ihm kommuniziert hast), indem Du Dir die Datei `refs/remotes/origin/master` anschaust:
 
 	$ cat .git/refs/remotes/origin/master
 	ca82a6dff817ec66f44342007202690a93763949
@@ -577,7 +577,7 @@ Externe Referenzen unterscheiden sich von Branches (`refs/heads`) hauptsächlich
 
 <!--Let’s go back to the objects database for your test Git repository. At this point, you have 11 objects — 4 blobs, 3 trees, 3 commits, and 1 tag:-->
 
-Kommen wir noch einmal auf die Objekt-Datenbank zurück, die Du für Dein Test-Git-Repository angelegt hast. Im Moment müsstest Du 11 Objekte haben: 4 Blobs, 3 Trees, 3 Commits und 1 Tag:
+Kommen wir noch einmal auf die Objekt-Datenbank zurück, die Du für Dein Test-Repository angelegt hast. Im Moment müsstest Du 11 Objekte haben: 4 Blobs, 3 Trees, 3 Commits und 1 Tag:
 
 	$ find .git/objects -type f
 	.git/objects/01/55eb4229851634a0f03eb265b69f5a2d56f341 # tree 2
@@ -674,7 +674,7 @@ Wenn Du das Objekt-Verzeichnis anschaust, siehst Du, dass die meisten Objekte je
 
 <!--The objects that remain are the blobs that aren’t pointed to by any commit — in this case, the "what is up, doc?" example and the "test content" example blobs you created earlier. Because you never added them to any commits, they’re considered dangling and aren’t packed up in your new packfile.-->
 
-Die verbleibenden Objekte sind diejenigen Blobs, die nicht von irgendeinem Commit referenziert werden – in diesem Fall sind das die Beispielblobs „what is up, doc?“ und „test content“, die wir zuvor gespeichert hatten: weil wir sie nie zu irgendeinem Commit hinzugefügt haben, werden sie als „dangling“ (wörtlich: herumbaumelnd) betrachtet und nicht im Packfile zusammengepackt.
+Die verbleibenden Objekte sind diejenigen Blobs, die nicht von irgendeinem Commit referenziert werden – in diesem Fall sind das die Beispielblobs „what is up, doc?“ und „test content“, die wir zuvor gespeichert hatten. Weil wir sie nie zu irgendeinem Commit hinzugefügt haben, werden sie als „dangling“ (wörtlich: herumbaumelnd) betrachtet und nicht im Packfile zusammengepackt.
 
 <!--The other files are your new packfile and an index. The packfile is a single file containing the contents of all the objects that were removed from your filesystem. The index is a file that contains offsets into that packfile so you can quickly seek to a specific object. What is cool is that although the objects on disk before you ran the `gc` were collectively about 8K in size, the new packfile is only 4K. You’ve halved your disk usage by packing your objects.-->
 
@@ -721,7 +721,7 @@ Außerdem ist toll, dass ein Repository jederzeit neu gepackt werden kann. Git m
 <!--Throughout this book, you’ve used simple mappings from remote branches to local references; but they can be more complex.-->
 <!--Suppose you add a remote like this:-->
 
-In diesem Buch haben wir bisher einfache Zuweisungen von externen Branches auf lokale Referenzen verwendet. Sie können aber auch durchaus komplex sein. Nehmen wir an, Du hast ein externes Repository wie folgt definiert:
+In diesem Buch haben wir bisher einfache Zuweisungen von externen Branches auf lokale Referenzen verwendet. Sie können aber auch durchaus komplex sein. Nehmen wir an, Du hast ein Remote-Repository wie folgt definiert:
 
 	$ git remote add origin git@github.com:schacon/simplegit-progit.git
 
@@ -735,11 +735,11 @@ Das fügt eine Sektion in Deine `.git/config`-Datei hinzu, die Deinen lokalen Na
 
 <!--The format of the refspec is an optional `+`, followed by `<src>:<dst>`, where `<src>` is the pattern for references on the remote side and `<dst>` is where those references will be written locally. The `+` tells Git to update the reference even if it isn’t a fast-forward.-->
 
-Das Format der Refspec besteht aus einem optionalen `+` gefolgt von `<quelle>:<ziel>`, wobei `<quelle>` ein Muster für Referenzen auf der Remote-Seite ist, und `<ziel>` angibt, wohin diese Referenzen lokal geschrieben werden. Das `+` weist Git an, die Referenz zu mergen, wenn sie nicht mit einem Fast-forward aktualisiert werden kann.
+Das Format der Refspec besteht aus einem optionalen `+` gefolgt von `<Quelle>:<Ziel>`, wobei `<Quelle>` ein Muster für Referenzen auf der Remote-Seite ist, und `<Ziel>` angibt, wohin diese Referenzen lokal geschrieben werden. Das `+` weist Git an, die Referenz zu mergen, wenn sie nicht mit einem Fast-forward aktualisiert werden kann.
 
 <!--In the default case that is automatically written by a `git remote add` command, Git fetches all the references under `refs/heads/` on the server and writes them to `refs/remotes/origin/` locally. So, if there is a `master` branch on the server, you can access the log of that branch locally via-->
 
-Der Standard, der von `git remote add` automatisch eingerichtet wird, besteht darin, dass Git automatisch alle Referenzen unter `refs/heads/` vom Server holt und sie lokal nach `refs/remotes/origin` speichert. D.h., wenn es auf dem Server einen `master`-Branch gibt, kannst Du auf das Log dieses Branches wie folgt zugreifen:
+Der Standard, der von `git remote add` automatisch eingerichtet wird, besteht darin, dass Git automatisch alle Referenzen unter `refs/heads/` vom Server holt und sie lokal nach `refs/remotes/origin` speichert. D.h., wenn es auf dem Server einen Branch `master` gibt, kannst Du auf das Log dieses Branches wie folgt zugreifen:
 
 	$ git log origin/master
 	$ git log remotes/origin/master
@@ -751,19 +751,19 @@ Diese Varianten sind allesamt äquivalent, weil Git sie jeweils zu `refs/remotes
 
 <!--If you want Git instead to pull down only the `master` branch each time, and not every other branch on the remote server, you can change the fetch line to-->
 
-Wenn Du stattdessen willst, dass Git jeweils nur den `master`-Branch herunterlädt und andere Branches auf dem Server ignoriert, kannst Du die `fetch`-Zeile wie folgt ändern:
+Wenn Du stattdessen willst, dass Git jeweils nur den Branch `master` herunterlädt und andere Branches auf dem Server ignoriert, kannst Du die `fetch`-Zeile wie folgt ändern:
 
 	fetch = +refs/heads/master:refs/remotes/origin/master
 
 <!--This is just the default refspec for `git fetch` for that remote. If you want to do something one time, you can specify the refspec on the command line, too. To pull the `master` branch on the remote down to `origin/mymaster` locally, you can run-->
 
-Dies ist allerdings lediglich der Standardwert der Refspec und Du kannst ihn auf der Kommandozeile jederzeit überschreiben. Um zum Beispiel nur den `master`-branch vom Server lokal als `origin/mymaster` zu speichern, kannst Du Folgendes ausführen:
+Dies ist allerdings lediglich der Standardwert der Refspec und Du kannst ihn auf der Kommandozeile jederzeit überschreiben. Um zum Beispiel nur den Branch `master` vom Server lokal als `origin/mymaster` zu speichern, kannst Du Folgendes ausführen:
 
 	$ git fetch origin master:refs/remotes/origin/mymaster
 
 <!--You can also specify multiple refspecs. On the command line, you can pull down several branches like so:-->
 
-Du kannst auch mehrere Refspecs gleichzeitig spezifizieren. Z.B.:
+Du kannst auch mehrere Refspecs gleichzeitig spezifizieren. Um mehrere Branches zu holen kannst du folgenden Befehl in die Kommandozeile eingeben:
 
 	$ git fetch origin master:refs/remotes/origin/mymaster \
 	   topic:refs/remotes/origin/topic
@@ -792,7 +792,7 @@ Du kannst keine partiellen Glob-Muster verwenden, d.h. Folgendes wäre ungültig
 
 <!--However, you can use namespacing to accomplish something like that. If you have a QA team that pushes a series of branches, and you want to get the master branch and any of the QA team’s branches but nothing else, you can use a config section like this:-->
 
-Allerdings kannst Du Namensräume verwenden, um etwas Ähnliches zu erreichen. Nehmen wir an, Du hast ein QA-Team, das regelmäßig verschiedene Branches pusht, und Du willst nun den master-Branch und sämtliche Branches des QA-Teams, aber keine anderen Branches haben. Dann kannst Du eine Config-Sektion wie die folgende verwenden:
+Allerdings kannst Du Namensräume verwenden, um etwas Ähnliches zu erreichen. Nehmen wir an, Du hast ein QA-Team, das regelmäßig verschiedene Branches pusht, und Du willst nun den Branch master und sämtliche Branches des QA-Teams, aber keine anderen Branches haben. Dann kannst Du eine Config-Sektion wie die folgende verwenden:
 
 	[remote "origin"]
 	       url = git@github.com:schacon/simplegit-progit.git
@@ -812,7 +812,7 @@ Wie aber legt das QA-Team die Branches im `qa/` Namensraum ab? Das geht, indem m
 
 <!--If the QA team wants to push their `master` branch to `qa/master` on the remote server, they can run-->
 
-Wenn das QA-Team seinen `master` Branch in einem externen Repository als `qa/master` speichern will, kann es das wie folgt tun:
+Wenn das QA-Team seinen Branch `master` in einem externen Repository als `qa/master` speichern will, kann es das wie folgt tun:
 
 	$ git push origin master:refs/heads/qa/master
 
@@ -827,7 +827,7 @@ Um Git so zu konfigurieren, dass diese Refspec jedes Mal automatisch für `git p
 
 <!--Again, this will cause a `git push origin` to push the local `master` branch to the remote `qa/master` branch by default.-->
 
-Auf diese Weise wird `git push origin` den lokalen Branch `master` als `qa/master` auf dem `origin` Server speichern.
+Auf diese Weise wird `git push origin` den lokalen Branch `master` als `qa/master` auf dem Server `origin` speichern.
 
 <!--### Deleting References ###-->
 ### Referenzen löschen ###
@@ -840,7 +840,7 @@ Man kann Refspecs außerdem verwenden, um Referenzen aus einem externen Reposito
 
 <!--Because the refspec is `<src>:<dst>`, by leaving off the `<src>` part, this basically says to make the topic branch on the remote nothing, which deletes it.-->
 
-Das Refspec Format ist `<quelle>:<ziel>`. Wenn man den Teil `<ziel>` weglässt, dann heißt das im obigen Beispiel, dass man den `topic` Branch auf dem `origin` Server auf „nichts“ setzt, d.h. also löscht.
+Das Refspec Format ist `<Quelle>:<Ziel>`. Wenn man den Teil `<Quelle>` weglässt, dann heißt das im obigen Beispiel, dass man den Branch `topic` auf dem Server `origin` auf „nichts“ setzt, d.h. also löscht.
 
 <!--## Transfer Protocols ##-->
 ## Transfer-Protokolle ##
@@ -854,31 +854,31 @@ Git kann Daten zwischen zwei Repositorys im Wesentlichen auf zwei Arten transpor
 
 <!--Git transport over HTTP is often referred to as the dumb protocol because it requires no Git-specific code on the server side during the transport process. The fetch process is a series of GET requests, where the client can assume the layout of the Git repository on the server. Let’s follow the `http-fetch` process for the simplegit library:-->
 
-Das HTTP-Transfer-Protokoll von Git wird oft auch als „dummes“ Protokoll bezeichnet, weil es auf der Server-Seite keinen Git-spezifischen Code benötigt. Der `fetch`-Prozess besteht aus einer Reihe von GET-Requests, für die der Client Vorannahmen über das Layout des Git-Repositorys auf dem Server machen kann. Schauen wir uns den `http-fetch`-Prozess der `simplegit`-Bibliothek an:
+Das HTTP-Transfer-Protokoll von Git wird oft auch als „dummes“ Protokoll bezeichnet, weil es auf der Server-Seite keinen Git-spezifischen Code benötigt. Der `fetch`-Prozess besteht aus einer Reihe von GET-Requests, für die der Client Vorannahmen über das Layout des Git-Repositorys auf dem Server machen kann. Schauen wir uns den `http-fetch`-Prozess der Bibliothek `simplegit` an:
 
 	$ git clone http://github.com/schacon/simplegit-progit.git
 
 <!--The first thing this command does is pull down the `info/refs` file. This file is written by the `update-server-info` command, which is why you need to enable that as a `post-receive` hook in order for the HTTP transport to work properly:-->
 
-Der Befehl lädt zunächst die `info/refs` Datei herunter. Diese Datei wird vom Befehl `update-server-info` geschrieben, den man als einen `post-receive`-Hook einrichten muss, damit das HTTP-Protokoll richtig funktionieren kann.
+Der Befehl lädt zunächst die Datei `info/refs` herunter. Diese Datei wird vom Befehl `update-server-info` geschrieben, den man als einen `post-receive`-Hook einrichten muss, damit das HTTP-Protokoll richtig funktionieren kann.
 
 	=> GET info/refs
 	ca82a6dff817ec66f44342007202690a93763949     refs/heads/master
 
 <!--Now you have a list of the remote references and SHAs. Next, you look for what the HEAD reference is so you know what to check out when you’re finished:-->
 
-Jetzt hat man eine Liste aller Referenzen und SHAs in diesem Repository. Als nächstes schaut man die HEAD-Referenz nach, um zu wissen, was ausgecheckt werden muss:
+Jetzt hat man eine Liste aller Referenzen und SHA-Prüfsummen in diesem Repository. Als nächstes schaut man die HEAD-Referenz nach, um zu wissen, was ausgecheckt werden muss:
 
 	=> GET HEAD
 	ref: refs/heads/master
 
 <!--You need to check out the `master` branch when you’ve completed the process.-->
 
-D.h., wenn wir mit dem Prozess fertig sind, wir müssen den `master`-Branch auschecken.
+D.h., wenn wir mit dem Prozess fertig sind, wir müssen den Branch `master` auschecken.
 
 <!--At this point, you’re ready to start the walking process. Because your starting point is the `ca82a6` commit object you saw in the `info/refs` file, you start by fetching that:-->
 
-Wir können jetzt loslegen. Weil wir in der `info/refs` Datei der Commit `ca82a6` angegeben ist, fangen wir damit an, dieses Objekt herunterzuladen:
+Wir können jetzt loslegen. Weil in der Datei `info/refs` der Commit `ca82a6` angegeben ist, fangen wir damit an, dieses Objekt herunterzuladen:
 
 	=> GET objects/ca/82a6dff817ec66f44342007202690a93763949
 	(179 bytes of binary data)
@@ -897,7 +897,7 @@ Wir erhalten also ein Objekt zurück. Dieses Objekt ist im losen Format auf dem
 
 <!--Next, you have two more objects to retrieve — `cfda3b`, which is the tree of content that the commit we just retrieved points to; and `085bb3`, which is the parent commit:-->
 
-Als Nächstes brauchen wir also zwei weitere Objekte: `cfda3b`, welches der Tree der Inhalte dieses Commits ist, und `085bb3`, den Commit-Parent:
+Als Nächstes brauchen wir also zwei weitere Objekte: `cfda3b`, welches der Tree der Inhalte dieses Commits ist, und `085bb3`, welches der übergeordnete Commit ist:
 
 	=> GET objects/08/5bb3bcb608e1e8451d4b2432f8ecbe6306e7e7
 	(179 bytes of data)
@@ -911,7 +911,7 @@ Das gibt uns das nächste Commit-Objekt. Versuchen wir, das Tree-Objekt zu holen
 
 <!--Oops — it looks like that tree object isn’t in loose format on the server, so you get a 404 response back. There are a couple of reasons for this — the object could be in an alternate repository, or it could be in a packfile in this repository. Git checks for any listed alternates first:-->
 
-Huch. Es sieht so aus, als ob der Tree nicht im losen Format auf dem Server gespeichert ist, weshalb wir einer 404-Antwort („Not found“) erhalten. Dafür kann es verschiedene Gründe geben. Das Objekt könnte in einem anderen, alternativen Repository liegen, oder es könnte sich in einem Packfile befinden. Git sucht deshalb zunächst nach alternativen Repositories:
+Huch. Es sieht so aus, als ob der Tree nicht im losen Format auf dem Server gespeichert ist, weshalb wir eine 404-Antwort („Not found“) erhalten. Dafür kann es verschiedene Gründe geben. Das Objekt könnte in einem anderen, alternativen Repository liegen, oder es könnte sich in einem Packfile befinden. Git sucht deshalb zunächst nach alternativen Repositories:
 
 	=> GET objects/info/http-alternates
 	(empty file)
@@ -992,7 +992,7 @@ Nehmen wir z.B. an, Du führst `git push origin master` in Deinem Projekt aus un
 
 <!--The `git-receive-pack` command immediately responds with one line for each reference it currently has — in this case, just the `master` branch and its SHA. The first line also has a list of the server’s capabilities (here, `report-status` and `delete-refs`).-->
 
-Der `git-receive-pack`-Befehl antwortet dann mit jeweils einer Zeile pro Referenz, die er kennt – in diesem Fall sind das lediglich der `master`-Branch und dessen SHA. Die erste Zeile listet außerdem Features, die der Server beherrscht (in unserem Fall `report-status` und `delete-refs`).
+Der `git-receive-pack`-Befehl antwortet dann mit jeweils einer Zeile pro Referenz, die er kennt – in diesem Fall sind das lediglich der Branch `master` und dessen SHA-Prüfsumme. Die erste Zeile listet außerdem Features, die der Server beherrscht (in unserem Fall `report-status` und `delete-refs`).
 
 <!--Each line starts with a 4-byte hex value specifying how long the rest of the line is. Your first line starts with 005b, which is 91 in hex, meaning that 91 bytes remain on that line. The next line starts with 003e, which is 62, so you read the remaining 62 bytes. The next line is 0000, meaning the server is done with its references listing.-->
 
@@ -1000,7 +1000,7 @@ Jede Zeile beginnt mit einem 4 Byte Hexadezimalzahl-Wert, der angibt, wie lang d
 
 <!--Now that it knows the server’s state, your `send-pack` process determines what commits it has that the server doesn’t. For each reference that this push will update, the `send-pack` process tells the `receive-pack` process that information. For instance, if you’re updating the `master` branch and adding an `experiment` branch, the `send-pack` response may look something like this:-->
 
-Nachdem Dein `send-pack`-Prozess jetzt den Zustand des Servers kennt, kann er als nächstes evaluieren, welche Commits lokal, aber nicht auf dem Server vorhanden sind. der `send-pack`-Prozess schickt diese Information für jede Referenz, auf die sich der `push`-Befehl bezieht, an den `receive-pack` Prozess. Wenn Du beispielsweise den `master`-Branch aktualisierst und einen `experiment`-Branch hinzufügst, dann könnte die Antwort auf `send-pack` so aussehen:
+Nachdem Dein `send-pack`-Prozess jetzt den Zustand des Servers kennt, kann er als nächstes evaluieren, welche Commits lokal, aber nicht auf dem Server vorhanden sind. der `send-pack`-Prozess schickt diese Information für jede Referenz, auf die sich der `push`-Befehl bezieht, an den `receive-pack` Prozess. Wenn Du beispielsweise den Branch `master` aktualisierst und einen Branch `experiment` hinzufügst, dann könnte die Antwort auf `send-pack` so aussehen:
 
 	0085ca82a6dff817ec66f44342007202690a93763949  15027957951b64cf874c3557a0f3547bd83b3ff6 refs/heads/master report-status
 	00670000000000000000000000000000000000000000 cdfdb42577e2506715f8cfeacdbabc092bf63e8d refs/heads/experiment
@@ -1025,7 +1025,7 @@ Wenn Du Daten herunterlädst, sind daran die Prozesse `fetch-pack` und `upload-p
 
 <!--There are different ways to initiate the `upload-pack` process on the remote repository. You can run via SSH in the same manner as the `receive-pack` process. You can also initiate the process via the Git daemon, which listens on a server on port 9418 by default. The `fetch-pack` process sends data that looks like this to the daemon after connecting:-->
 
-Es gibt verschiedene Möglichkeiten, den `upload-pack`-Prozess auf dem Server zu starten: einerseits via SSH auf die gleiche Weise wie den `receive-pack`-Prozess. Und adnererseits über den Git-Daemon, der standardmäßig auf dem Server auf dem Port 9418 läuft. Der `fetch-pack`-Prozess schickt etwa Folgendes an den Daemon:
+Es gibt verschiedene Möglichkeiten, den `upload-pack`-Prozess auf dem Server zu starten: einerseits via SSH auf die gleiche Weise wie den `receive-pack`-Prozess. Und andererseits über den Git-Daemon, der standardmäßig auf dem Server auf dem Port 9418 läuft. Der `fetch-pack`-Prozess schickt etwa Folgendes an den Daemon:
 
 	003fgit-upload-pack schacon/simplegit-progit.git\0host=myserver.com\0
 
@@ -1071,7 +1071,7 @@ Das ist ein sehr einfaches Beispiel. In komplexeren Fällen unterstützt der Cli
 
 <!--Occasionally, you may have to do some cleanup — make a repository more compact, clean up an imported repository, or recover lost work. This section will cover some of these scenarios.-->
 
-Gelegentlich will man ein bisschen aufräumen – ein Repository verdichten, ein importiertes Repository aufräumen oder verloren gegangene Daten wieder herstellen. Dieses Kapitel wird sich mit einigen derartigen Szenarien befassen.
+Gelegentlich will man ein bisschen aufräumen – ein Repository komprimieren, ein importiertes Repository aufräumen oder verloren gegangene Daten wiederherstellen. Dieses Kapitel wird sich mit einigen derartigen Szenarien befassen.
 
 <!--### Maintenance ###-->
 ### Wartung ###
@@ -1102,7 +1102,7 @@ Wie schon erwähnt tut dies normalerweise gar nichts. Es müssen sich etwa 7.000
 
 <!--If you run `git gc`, you’ll no longer have these files in the `refs` directory. Git will move them for the sake of efficiency into a file named `.git/packed-refs` that looks like this:-->
 
-Nachdem Du `git gc` ausgeführt hast, werden diese Dateien um der Effizienz willen aus dem `refs`-Verzeichnis entfernt und in eine Datei `.git/packed-refs` verschoben, die dann wie folgt aussieht:
+Nachdem Du `git gc` ausgeführt hast, werden diese Dateien um der Effizienz willen aus dem Verzeichnis `refs` entfernt und in eine Datei `.git/packed-refs` verschoben, die dann wie folgt aussieht:
 
 	$ cat .git/packed-refs
 	# pack-refs with: peeled
@@ -1114,7 +1114,7 @@ Nachdem Du `git gc` ausgeführt hast, werden diese Dateien um der Effizienz will
 
 <!--If you update a reference, Git doesn’t edit this file but instead writes a new file to `refs/heads`. To get the appropriate SHA for a given reference, Git checks for that reference in the `refs` directory and then checks the `packed-refs` file as a fallback. However, if you can’t find a reference in the `refs` directory, it’s probably in your `packed-refs` file.-->
 
-Wenn Du eine Referenz bearbeitest, lässt Git diese Datei unverändert und schreibt stattdessen eine neue Datei nach `refs/heads`. Um einen SHA für eine Referenz nachzuschlagen, schaut Git zunächst im `refs`-Verzeichnis und danach erst in der Datei `packed-refs` nach, falls nötig. Wenn eine Referenz also nicht im `refs`-Verzeichnis liegt, befindet sie sich wahrscheinlich in der Datei `packed-refs`.
+Wenn Du eine Referenz bearbeitest, lässt Git diese Datei unverändert und schreibt stattdessen eine neue Datei nach `refs/heads`. Um eine SHA-Prüfsumme für eine Referenz nachzuschlagen, schaut Git zunächst im Verzeichnis `refs` und danach erst in der Datei `packed-refs` nach, falls nötig. Wenn eine Referenz also nicht im Verzeichnis `refs` liegt, befindet sie sich wahrscheinlich in der Datei `packed-refs`.
 
 <!--Notice the last line of the file, which begins with a `^`. This means the tag directly above is an annotated tag and that line is the commit that the annotated tag points to.-->
 
@@ -1125,11 +1125,11 @@ Beachte, dass die letzte Zeile der Datei mit `^` anfängt. Das bedeutet, dass de
 
 <!--At some point in your Git journey, you may accidentally lose a commit. Generally, this happens because you force-delete a branch that had work on it, and it turns out you wanted the branch after all; or you hard-reset a branch, thus abandoning commits that you wanted something from. Assuming this happens, how can you get your commits back?-->
 
-Irgendwann wird es vielleicht mal vorkommen, dass Du während der Arbeit mit Git einen Commit verlierst. Normalerweise passiert das, wenn Du versehentlich einen Branch löschst, an dem Du gearbeitet hattest und den Du noch brauchst. Oder Du führst `git reset --hard` aus und stellst fest, dass Du einige der Commits noch brauchst. Nehmen wir an, Du steckst in einer solchen Situation – wie kannst Du Deine Commits wiederherstellen?
+Irgendwann wird es vielleicht mal vorkommen, dass Du während der Arbeit mit Git einen Commit verlierst. Normalerweise passiert das, wenn Du versehentlich einen Branch löschst, an dem Du gearbeitet hattest und den Du noch brauchst. Oder Du führst `git reset --hard` aus und stellst fest, dass Du einige der Commits noch brauchst. Nehmen wir an, Du steckst in einer solchen Situation – wie kannst Du Deine Commits dann wiederherstellen?
 
 <!--Here’s an example that hard-resets the master branch in your test repository to an older commit and then recovers the lost commits. First, let’s review where your repository is at this point:-->
 
-Das folgende Beispiel setzt zuerst den `master`-Branch auf einen älteren Commit zurück und stellt die verlorenen Commits dann wieder her. Zunächst schauen wir uns den gegenwärtigen Zustand des Repositories an:
+Das folgende Beispiel setzt zuerst den Branch `master` auf einen älteren Commit zurück und stellt die verlorenen Commits dann wieder her. Zunächst schauen wir uns den gegenwärtigen Zustand des Repositorys an:
 
 	$ git log --pretty=oneline
 	ab1afef80fac8e34258ff41fc1b867c702daa24b modified repo a bit
@@ -1140,7 +1140,7 @@ Das folgende Beispiel setzt zuerst den `master`-Branch auf einen älteren Commit
 
 <!--Now, move the `master` branch back to the middle commit:-->
 
-Jetzt setzen wir den `master`-Branch zurück auf den mittleren Commit.
+Jetzt setzen wir den Branch `master` auf den mittleren Commit zurück:
 
 	$ git reset --hard 1a410efbd13591db07496601ebc7a059dd55cfe9
 	HEAD is now at 1a410ef third commit
@@ -1163,7 +1163,7 @@ In der Regel ist der schnellste Weg, solche Hashes zu finden, der Befehl `git re
 
 <!--Here we can see the two commits that we have had checked out, however there is not much information here.  To see the same information in a much more useful way, we can run `git log -g`, which will give you a normal log output for your reflog.-->
 
-Das zeigt also die beiden verloren gegangenen Commits an, die wir zuvor ausgecheckt hatten. Allerdings zeigt es auch nicht viel mehr Information. Um das Reflog in einer anderen, etwas nützlicheren Weise anzuzeigen, kannst Du `git log -g` verwenden. Das gibt das Reflog im gewohnten Log Format aus:
+Das zeigt also die beiden verloren gegangenen Commits an, die wir zuvor ausgecheckt hatten. Allerdings zeigt es auch nicht viel mehr Information. Um das Reflog in einer anderen, etwas nützlicheren Weise anzuzeigen, kannst Du `git log -g` verwenden. Das gibt das Reflog im gewohnten Log-Format aus:
 
 	$ git log -g
 	commit 1a410efbd13591db07496601ebc7a059dd55cfe9
@@ -1197,7 +1197,7 @@ Es sieht also so aus, als sei der untere Commit derjenige, den Du verloren hast,
 <!--Cool — now you have a branch named `recover-branch` that is where your `master` branch used to be, making the first two commits reachable again.-->
 <!--Next, suppose your loss was for some reason not in the reflog — you can simulate that by removing `recover-branch` and deleting the reflog. Now the first two commits aren’t reachable by anything:-->
 
-Sehr gut. Du hast jetzt einen neuen Branch `recover-branch`, der diejenigen Commits enthält, die sich zuvor in Deinem `master`-Branch befanden. Damit hast Du wieder Zugriff auf die beiden verloren gegangenen Commits. Als nächstes nehmen wir aber außerdem an, dass diese verlorenen Commits aus irgendeinem Grunde nicht im Reflog enthalten sind – Du kannst das z.B. simulieren, indem Du den Branch `recover-branch` und das Reflog löschst. Damit sind die beiden Commits jetzt von nirgendwo her mehr erreichbar:
+Sehr gut. Du hast jetzt einen neuen Branch `recover-branch`, der diejenigen Commits enthält, die sich zuvor in Deinem Branch `master` befanden. Damit hast Du wieder Zugriff auf die beiden verloren gegangenen Commits. Als nächstes nehmen wir aber außerdem an, dass diese verlorenen Commits aus irgendeinem Grunde nicht im Reflog enthalten sind – Du kannst das z.B. simulieren, indem Du den Branch `recover-branch` und das Reflog löschst. Damit sind die beiden Commits jetzt von nirgendwo her mehr erreichbar:
 
 	$ git branch -D recover-branch
 	$ rm -Rf .git/logs/
@@ -1225,7 +1225,7 @@ Git ist in vielerlei Hinsicht unschlagbar, aber es gibt auch Features, die Probl
 
 <!--This can be a huge problem when you’re converting Subversion or Perforce repositories into Git. Because you don’t download the whole history in those systems, this type of addition carries few consequences. If you did an import from another system or otherwise find that your repository is much larger than it should be, here is how you can find and remove large objects.-->
 
-Hierin kann ein großes Problem bestehen, wenn Du Subversion oder Perforce-Repositorys nach Git konvertierst. Weil Du in diesen Systemen nicht die gesamte Historie herunterlädst, kann diese Art von Hinzufügung einige unangenehme Konsequenzen haben. Wenn Du Dein Repository aus einem anderen System importiert hast oder aus irgendeinem anderen Grunde findest, dass es sehr viel größer ist, als es eigentlich sein sollte, kannst Du große Objekte wie folgt suchen und entfernen.
+Hierin kann ein großes Problem bestehen, wenn Du Subversion- oder Perforce-Repositorys nach Git konvertierst. Weil Du in diesen Systemen nicht die gesamte Historie herunterlädst, kann diese Art von Hinzufügung einige unangenehme Konsequenzen haben. Wenn Du Dein Repository aus einem anderen System importiert hast oder aus irgendeinem anderen Grunde findest, dass es sehr viel größer ist, als es eigentlich sein sollte, kannst Du große Objekte wie folgt suchen und entfernen.
 
 <!--Be warned: this technique is destructive to your commit history. It rewrites every commit object downstream from the earliest tree you have to modify to remove a large file reference. If you do this immediately after an import, before anyone has started to base work on the commit, you’re fine — otherwise, you have to notify all contributors that they must rebase their work onto your new commits.-->
 
@@ -1233,7 +1233,7 @@ Sei Dir allerdings bewusst, dass diese Technik die Commit-Historie zerstört. Si
 
 <!--To demonstrate, you’ll add a large file into your test repository, remove it in the next commit, find it, and remove it permanently from the repository. First, add a large object to your history:-->
 
-Um das zu demonstrieren, werden wir eine große Datei zu Deinem Test-Repository hinzufügen, sie dann im nächsten Commit löschen, in der Datenbank nachschlagen und sie schließlich dauerhaft aus dem Repository entfernen. Als erstes committe also eine große Datei in Dein Repository:
+Um das zu demonstrieren, werden wir eine große Datei zu Deinem Test-Repository hinzufügen, sie dann im nächsten Commit löschen, in der Datenbank nachschlagen und sie schließlich dauerhaft aus dem Repository entfernen. Als erstes checke also eine große Datei in Dein Repository ein:
 
 	$ curl http://kernel.org/pub/software/scm/git/git-1.6.3.1.tar.bz2 > git.tbz2
 	$ git add git.tbz2
@@ -1279,7 +1279,7 @@ Du kannst auch den Befehl `count-objects` laufen lassen, um einen schnellen Übe
 
 <!--The `size-pack` entry is the size of your packfiles in kilobytes, so you’re using 2MB. Before the last commit, you were using closer to 2K — clearly, removing the file from the previous commit didn’t remove it from your history. Every time anyone clones this repository, they will have to clone all 2MB just to get this tiny project, because you accidentally added a big file. Let’s get rid of it.-->
 
-Der `size-pack`-Eintrag zeigt die Größe der Packfiles in Kilobytes, d.h. Dein Repository braucht 2 MB. Vor dem letzten Commit lag dieser Wert eher bei 2 KB. D.h., die Datei wurde im letzten Commit eindeutig nicht aus der History entfernt. Jedes Mal, wenn jemand künftig dieses sehr kleine Repository clont, wird er die 2 MB mit herunterladen müssen – nur weil wir versehentlich diese große Datei hinzugefügt hatten. Also versuchen wir, sie endgültig loszuwerden.
+Der `size-pack`-Eintrag zeigt die Größe der Packfiles in Kilobytes an, d.h. Dein Repository braucht 2 MB. Vor dem letzten Commit lag dieser Wert eher bei 2 KB. D.h., die Datei wurde im letzten Commit eindeutig nicht aus der History entfernt. Jedes Mal, wenn jemand künftig dieses sehr kleine Repository klont, wird er die 2 MB mit herunterladen müssen – nur weil wir versehentlich diese große Datei hinzugefügt hatten. Also versuchen wir, sie endgültig loszuwerden.
 
 <!--First you have to find it. In this case, you already know what file it is. But suppose you didn’t; how would you identify what file or files were taking up so much space? If you run `git gc`, all the objects are in a packfile; you can identify the big objects by running another plumbing command called `git verify-pack` and sorting on the third field in the output, which is file size. You can also pipe it through the `tail` command because you’re only interested in the last few largest files:-->
 
@@ -1317,7 +1317,7 @@ Es geht also darum, alle Commits angefangen bei `6df76` neu zu schreiben, sodass
 
 <!--The `-\-index-filter` option is similar to the `-\-tree-filter` option used in Chapter 6, except that instead of passing a command that modifies files checked out on disk, you’re modifying your staging area or index each time. Rather than remove a specific file with something like `rm file`, you have to remove it with `git rm -\-cached` — you must remove it from the index, not from disk. The reason to do it this way is speed — because Git doesn’t have to check out each revision to disk before running your filter, the process can be much, much faster. You can accomplish the same task with `-\-tree-filter` if you want. The `-\-ignore-unmatch` option to `git rm` tells it not to error out if the pattern you’re trying to remove isn’t there. Finally, you ask `filter-branch` to rewrite your history only from the `6df7640` commit up, because you know that is where this problem started. Otherwise, it will start from the beginning and will unnecessarily take longer.-->
 
-DieOption  `--index-filter` ist ähnlich der Option `--tree-filter` aus Kapitel 6. Allerdings übergibt man in diesem Fall nicht einen Befehl, der die Dateien verändert, die sich jeweils ausgecheckt auf der Festplatte befinden. Stattdessen verändert man jeweils die Staging-Area bzw. den Index. Statt eine bestimmte Datei mit z.B: `rm file` zu entfernen, müssen wir also `git rm --cached` verwenden – denn wir wollen sie aus dem Index, nicht von der Festplatte löschen. Der Grund dafür ist einfach Geschwindigkeit: Git braucht nicht jede einzelne Revision auf die Festplatte auszuchecken, um den Filter anzuwenden. Auf diese Weise läuft der ganze Prozess sehr viel schneller. Man kann dieselbe Aufgabe aber auch mit `--tree-filter` erledigen, wenn man will. Die Option `--ignore-match` weist Git an, nicht mit einer Fehlermeldung abzubrechen, wenn die Datei, die wir löschen wollen, nicht vorhanden ist. Außerdem teilen wir `filter-branch` mit, die Historie nur von dem Commit `6df7640` an umzuschreiben. Andernfalls würde der Befehl von ganz vorn beginnen und unnötig länger brauchen.
+Die Option  `--index-filter` ist ähnlich der Option `--tree-filter` aus Kapitel 6. Allerdings übergibt man in diesem Fall nicht einen Befehl, der die Dateien verändert, die sich jeweils ausgecheckt auf der Festplatte befinden. Stattdessen verändert man jeweils die Staging-Area bzw. den Index. Statt eine bestimmte Datei mit z.B: `rm file` zu entfernen, müssen wir also `git rm --cached` verwenden – denn wir wollen sie aus dem Index, nicht von der Festplatte löschen. Der Grund dafür ist einfach Geschwindigkeit: Git braucht nicht jede einzelne Revision auf die Festplatte auszuchecken, um den Filter anzuwenden. Auf diese Weise läuft der ganze Prozess sehr viel schneller. Man kann dieselbe Aufgabe aber auch mit `--tree-filter` erledigen, wenn man will. Die Option `--ignore-match` weist Git an, nicht mit einer Fehlermeldung abzubrechen, wenn die Datei, die wir löschen wollen, nicht vorhanden ist. Außerdem teilen wir `filter-branch` mit, die Historie nur von dem Commit `6df7640` an umzuschreiben. Andernfalls würde der Befehl von ganz vorn beginnen und unnötig länger brauchen.
 
 <!--Your history no longer contains a reference to that file. However, your reflog and a new set of refs that Git added when you did the `filter-branch` under `.git/refs/original` still do, so you have to remove them and then repack the database. You need to get rid of anything that has a pointer to those old commits before you repack:-->
 
@@ -1358,4 +1358,4 @@ Du solltest jetzt ein gutes Verständnis davon haben, was Git im Hintergrund tut
 
 <!--Git as a content-addressable filesystem is a very powerful tool that you can easily use as more than just a VCS. I hope you can use your newfound knowledge of Git internals to implement your own cool application of this technology and feel more comfortable using Git in more advanced ways.-->
 
-Git als ein Dateisystem, das Inhalte addressieren kann, ist ein äußerst mächtiges Werkzeug, das Du leicht für mehr als „nur“ als VCS einsetzen kannst. Ich hoffe, Du kannst Dein neugewonnenes Wissen der Git-Interna nutzen, um Deine eigene tolle Anwendung dieser Technologie zu implementieren und Dich wohler damit zu fühlen, Git auch in fortgeschrittener Weise zu benutzen.
+Git als ein Dateisystem, das Inhalte addressieren kann, ist ein äußerst mächtiges Werkzeug, das Du leicht für mehr als „nur“ als VCS einsetzen kannst. Ich hoffe, Du kannst Dein neugewonnenes Wissen der Git Interna nutzen, um Deine eigene tolle Anwendung dieser Technologie zu implementieren und Dich wohler damit zu fühlen, Git auch in fortgeschrittener Weise zu benutzen.

From cd58556a66d5edab4456447a8e00940c452d51a8 Mon Sep 17 00:00:00 2001
From: Cor <cor.takken@cgi.com>
Date: Thu, 16 Jan 2014 12:12:07 +0100
Subject: [PATCH 124/690] [nl] Language and wording corrections. Introducing
 characters from ASCII extended.

---
 nl/04-git-server/01-chapter4.markdown | 130 +++++++++++++-------------
 1 file changed, 65 insertions(+), 65 deletions(-)

diff --git a/nl/04-git-server/01-chapter4.markdown b/nl/04-git-server/01-chapter4.markdown
index 153825c95..a27d58789 100644
--- a/nl/04-git-server/01-chapter4.markdown
+++ b/nl/04-git-server/01-chapter4.markdown
@@ -1,22 +1,22 @@
 # Git op de server #
 
-Op dit punt zou je alledaagse taken waarvoor je Git zult gebruiken kunnen doen. Maar, om samen te kunnen werken in Git, zul je een remote repository moeten hebben. Technisch gezien kun je wijzigingen pushen en pullen van individuele repositories, maar dat wordt afgeraden, omdat je vrij gemakkelijk het werk waar anderen mee bezig zijn in de war kunt schoppen als je niet oppast. Daarnaast wil je dat je medewerkers bij het repository kunnen, zelfs als jouw computer van het netwerk is — het hebben van een betrouwbaar gezamenlijk repository is vaak handig. Daarom heeft het hebben van een tussenliggend repository waarin je met iemand anders samenwerkt de voorkeur, en daar kun je dan naar pushen en pullen. We zullen dit repository de "Git server" noemen; maar je zult zien dat het over het algemeen maar een klein beetje systeembronnen kost om een Git repository te verzorgen, dus je zult er zelden een complete server voor nodig hebben.
+Op dit punt zou je alledaagse taken waarvoor je Git zult gebruiken kunnen doen. Maar, om samen te kunnen werken in Git zul je een remote repository moeten hebben. Technisch gezien kun je wijzigingen pushen en pullen van individuele repositories, maar dat wordt afgeraden, omdat je vrij gemakkelijk het werk waar anderen mee bezig zijn in de war kunt schoppen als je niet oppast. Daarnaast wil je dat je medewerkers de repository kunnen bereiken, zelfs als jouw computer van het netwerk is – het hebben van een betrouwbare gezamenlijke repository is vaak handig. Daarom heeft het hebben van een tussenliggende repository waarin je met iemand anders samenwerkt de voorkeur, en daaruit pushen en pullen. We zullen deze repository de `Git server` noemen, maar je zult zien dat het over het algemeen maar een klein beetje systeembronnen kost om een Git repository te verzorgen, dus je zult er zelden een complete server voor nodig hebben.
 
-Een Git server draaien is eenvoudig. Als eerste kies je met welke protocollen je je server wilt laten communiceren. Het eerste gedeelte van dit hoofdstuk zullen we de beschikbare protocollen bespreken met de voor- en nadelen van elk. De volgende secties zullen veel voorkomende opstellingen bespreken, die van die protocollen gebruik maken en hoe je je server ermee kunt opzetten. Als laatste laten we een paar servers van derden zien, als je het niet erg vindt om je code op iemands server te zetten en niet het gedoe wilt hebben van het opzetten en onderhouden van je eigen server.
+Een Git server draaien is eenvoudig. Als eerste kies je met welke protocollen je de server wilt laten communiceren. Het eerste gedeelte van dit hoofdstuk zullen we de beschikbare protocollen bespreken met de voor- en nadelen van elk. De volgende paragrafen zullen we veel voorkomende opstellingen bespreken, die van die protocollen gebruik maken en hoe je je server ermee kunt opzetten. Als laatste laten we een paar servers van derden zien, als je het niet erg vindt om je code op de server van een ander te zetten en niet het gedoe wilt hebben van het opzetten en onderhouden van je eigen server.
 
-Als je geen interesse hebt om je eigen server te draaien, dan kun je de rest overslaan en direct naar het laatste gedeelte van het hoofdstuk gaan om wat mogelijkheden voor het instellen van online accounts te zien en dan door te gaan naar het volgende hoofdstuk, waar we alle zaken bespreken die komen kijken bij het werken met een gedistribueerde versie beheer omgeving.
+Als je geen interesse hebt om je eigen server te draaien, dan kun je de direct naar de laatste paragraaf van dit hoofdstuk gaan om wat mogelijkheden van online accounts te zien en dan door te gaan naar het volgende hoofdstuk, waar we alle zaken bespreken die komen kijken bij het werken met een gedistribueerde versiebeheer omgeving.
 
-Een remote repository is over het algemeen een _bare repository_ (kale repository) — een Git repository dat geen werkmap heeft. Omdat het repository alleen gebruikt wordt als een samenwerkingspunt, is er geen reden om een snapshot op de schijf te hebben; alleen de Git data. Een kale repository is eenvoudigweg de inhoud van de `.git` map in je project, en niets anders.
+Een remote repository is over het algemeen een _bare repository_ (kale repository) – een Git repository dat geen werkmap heeft. Omdat de repository alleen gebruikt wordt als een samenwerkingspunt, is er geen reden om een snapshot op de schijf te hebben; alleen de Git data. Een kale repository is eenvoudigweg de inhoud van de `.git` map in je project, en niets meer.
 
 ## De protocollen ##
 
-Git kan vier veel voorkomende netwerk protocollen gebruiken om data te transporteren: Lokaal, Beveiligde Shell (SSH), Git en HTTP. Hier laten we zien wat ze zijn, en in welke omstandigheden je ze wilt gebruiken (of juist niet).
+Git kan vier veel voorkomende netwerk protocollen gebruiken om data te transporteren: Lokaal, Beveiligde Shell (SSH), Git en HTTP. Hier laten we zien wat deze zijn, en in welke omstandigheden je ze wilt gebruiken (of juist niet).
 
-Het is belangrijk om te zien dat, met uitzondering van de HTTP protocollen, ze allemaal een werkende Git versie op de server geïnstalleerd moeten hebben.
+Het is belangrijk om op te merken dat, met uitzondering van de HTTP protocollen, ze allemaal een werkende Git versie op de server geïnstalleerd moeten hebben.
 
 ### Lokaal protocol ###
 
-Het meest basale is het _lokale protocol_, waarbij het remote repository in een andere map op de schijf staat. Dit wordt vaak gebruikt als iedereen in je team toegang heeft op een gedeeld bestandssysteem zoals een NFS map, of in het weinig voorkomende geval dat iedereen op dezelfde computer werkt. Het laatste zou niet ideaal zijn, want dan zouden alle repositories zich op dezelfde computer bevinden, zodat de kans op een catastrofaal verlies veel groter wordt.
+Het meest basale is het _lokale protocol_, waarbij het remote repository in een andere map op de schijf staat. Deze opzet wordt vaak gebruikt als iedereen in het team toegang heeft op een gedeeld bestandssyteem zoals een NFS map, of in het weinig voorkomende geval dat iedereen op dezelfde computer werkt. Het laatste zou niet ideaal zijn, want dan zouden alle repositories op dezelfde computer staan, zodat de kans op een fataal verlies veel groter wordt.
 
 Als je een gedeeld bestandssysteem hebt, dan kun je klonen, pushen en pullen van een op een lokaal bestand gebaseerde repository. Om een dergelijk repository te klonen, of om er een als een remote aan een bestaand project toe te voegen, moet je het pad naar het repository als URL gebruiken. Bijvoorbeeld, om een lokaal repository te klonen, kun je zoiets als dit uitvoeren:
 
@@ -26,29 +26,29 @@ Of je kunt dit doen:
 
 	$ git clone file:///opt/git/project.git
 
-Git werkt iets anders als je expliciet `file://` aan het begin van de URL zet. Als je alleen het pad specificeert, probeert Git hardlinks te gebruiken, of het kopieert de bestanden die het nodig heeft. Als je `file://` specificeert, dan start Git de processen die het normaal gebruikt om data te transporteren over een netwerk, wat over het algemeen een stuk minder efficiënte methode is om data te transporteren. De reden om `file://` wel te specificeren is als je een schone kopie van de repository wilt met de extra referenties of objecten eruit gelaten — over het algemeen na een import van een ander versie beheer systeem of iets vergelijkbaars (zie Hoofdstuk 9 voor onderhoudstaken). We zullen het normale pad hier gebruiken, omdat het bijna altijd sneller is om het zo te doen.
+Git werkt iets anders als je explicite `file://` aan het begin van de URL zet. Als je alleen het pad specificeert, probeert Git hardlinks te gebruiken, of het kopieert de bestanden die het nodig heeft. Als je `file://` specificeert, dan start Git de processen die het normaal gesproken gebruikt om data te transporteren over een netwerk, wat over het algemeen een minder efficiënte methode is om data te transporteren. De reden om `file://` wel te specificeren is als je een schone kopie van de repository wilt met de extra referenties of objecten eruit gelaten – over het algemeen na een import van een ander versiebeheer systeem of iets dergelijks (zie Hoofdstuk 9 voor onderhoudstaken). We zullen het normale pad hier gebruiken, omdat het bijna altijd sneller is om het zo te doen.
 
-Om een lokaal repository aan een bestaand Git project toe te voegen, kun je zoiets als dit uitvoeren:
+Om een lokale repository aan een bestaand Git project toe te voegen, kun je zoiets als het volgende uitvoeren:
 
 	$ git remote add local_proj /opt/git/project.git
 
-Daarna kun je pushen en pullen van dat remote alsof je over een netwerk werkt.
+Daarna kun je pushen en pullen van die remote alsof je over een netwerk werkt.
 
 #### De voordelen ####
 
-De voordelen van bestands-gebaseerde repositories zijn dat ze eenvoudig zijn en ze maken gebruik van bestaande bestandspermissies en netwerk toegang. Als je al een gedeeld bestandssysteem hebt, waar je hele team al toegang tot heeft, dan is een repository opzetten heel gemakkelijk. Je stopt de kale repository ergens waar iedereen gedeelde toegang tot heeft, en stelt de lees- en schrijfrechten in zoals je dat bij iedere andere gedeelde map zou doen. In de volgende sectie "Git op een Server krijgen" bespreken we hoe je een kopie van een kale repository kunt exporteren voor dit doeleinde.
+De voordelen van bestands-gebaseerde repositories zijn dat ze eenvoudig zijn en ze maken gebruik van bestaande bestandspermissies en netwerk toegang. Als je al een gedeeld bestandssysteem hebt, waar je hele team al toegang tot heeft, dan is een repository opzetten heel gemakkelijk. Je stopt de kale repository ergens waar iedereen gedeelde toegang tot heeft, en stelt de lees- en schrijfrechten in zoals je dat bij iedere andere gedeelde map zou doen. In de volgende paragraaf "Git op een Server Krijgen" bespreken we hoe je een kopie van een kale repository kunt exporteren voor dit doeleinde.
 
-Dit is ook een fijne optie om snel werk van een repository van iemand anders te pakken. Als jij en een collega aan hetzelfde project aan het werk zijn, en hij wil dat je iets bekijkt, dan is het uitvoeren van een commando zoals `git pull /home/john/project` vaak makkelijker dan dat hij naar een remote server moet pushen, en jij er van moet pullen.
+Dit is ook een prettige optie om snel werk van een repository van iemand anders te pakken. Als jij en een collega aan hetzelfde project werken, en hij wil dat je iets bekijkt, dan is het uitvoeren van een commando zoals `git pull /home/john/project` vaak makkelijker dan dat hij naar een remote server moet pushen, en jij er van moet pullen.
 
 #### De nadelen ####
 
 Een van de nadelen van deze methode is dat gedeelde toegang over het algemeen moeilijker op te zetten en te bereiken is vanaf meerdere locaties dan basaal netwerk toegang. Als je wilt pushen van je laptop als je thuis bent, dan moet je de remote schijf aankoppelen, wat moeilijk en langzaam kan zijn in vergelijking tot netwerk gebaseerde toegang.
 
-Het is ook belangrijk om te melden dat het niet noodzakelijk de snelste optie is, als je een gedeeld koppelpunt of iets dergelijks gebruikt. Een lokale repository is alleen snel als je snelle toegang tot de data hebt. Een repository op NFS is vaak langzamer dan het repository via SSH op dezelfde server, wat Git toelaat om vanaf lokale schijven te werken op ieder systeem.
+Het is ook belangrijk om te vermelden dat het niet altijd de snelste optie is, als je een gedeeld koppelpunt (mount) of iets dergelijks gebruikt. Een lokale repository is alleen snel als je snelle toegang tot de data hebt. Een repository op NFS is vaak langzamer dan een repository via SSH op dezelfde server omdat dit Git in staat stelt om op lokale schijven te werken vanaf ieder systeem.
 
 ### Het SSH protocol ###
 
-Waarschijnlijk het meest voorkomende protocol voor Git is SSH. Dit is omdat SSH toegang tot servers in veel plaatsen al geconfigureerd is — en als dat niet het geval is, dan is het makkelijk om dat te doen. SSH is ook het enige netwerk gebaseerde protocol waarvan je makkelijk kunt lezen en naartoe kunt schrijven. De andere twee netwerk protocollen (HTTP en Git) zijn over het algemeen alleen-lezen, dus zelfs als je ze al beschikbaar hebt voor de ongewassen massa, dan heb je nog steeds SSH nodig voor je eigen schrijftoegang. SSH is ook een geverifieerd protocol; en omdat het overal voorkomt, is het over het algemeen eenvoudig om in te stellen en te gebruiken.
+Waarschijnlijk het meest voorkomende protocol voor Git is SSH. Met als reden dat toegang met SSH tot servers in veel plaatsen al geconfigureerd is – en als dat niet het geval is, dan is het eenvoudig om dat te doen. SSH is ook het enige netwerk gebaseerde protocol waarvan je makkelijk kunt lezen en naartoe kunt schrijven. De andere twee netwerk protocollen (HTTP en Git) zijn over het algemeen alleen-lezen, dus zelfs als je ze al beschikbaar hebt voor de ongeïnitieerden, dan heb je nog steeds SSH nodig voor je eigen schrijftoegang. SSH is ook een geauthenticieerd protocol; en omdat het overal voorkomt, is het over het algemeen eenvoudig om in te stellen en te gebruiken.
 
 Om een Git repository via SSH te klonen, kun je een ssh:// URL opgeven zoals:
 
@@ -62,28 +62,28 @@ Je kunt ook de gebruiker niet opgeven, en Git neemt aan dat je de gebruiker bedo
 
 #### De voordelen ####
 
-Er zijn vele voordelen om SSH te gebruiken. De eerste is dat je het eigenlijk wel moet gebruiken als je geverifieerde schrijftoegang op je repository via een netwerk wilt. Het tweede is dat het relatief eenvoudig in te stellen is — SSH daemons komen veel voor, veel systeembeheerders hebben er ervaring mee, en veel besturingssystemen zijn er mee uitgerust of hebben applicaties om ze te beheren. Daarnaast is toegang via SSH veilig — alle data transporten zijn versleuteld en geverifieerd. En als laatste is SSH efficiënt, zoals het Git en lokale protocol, waarbij de data zo compact mogelijk wordt gemaakt voordat het getransporteerd wordt.
+Er zijn vele voordelen om SSH te gebruiken. De eerste is dat je het eigenlijk wel moet gebruiken als je geauthenticeerde schrijftoegang op je repository via een netwerk wilt. Het tweede is dat het relatief eenvoudig in te stellen is – SSH daemons komen veel voor, veel systeembeheerders hebben er ervaring mee, en veel operating systemen zijn er mee uitgerust of hebben applicaties om ze te beheren. Daarnaast is toegang via SSH veilig – alle data transporten zijn versleuteld en geauthenticeerd. En als laatste is SSH efficiënt, net zoals het Git en lokale protocol, de data wordt zo compact mogelijk gemaakt voordat het getransporteerd wordt.
 
 #### De nadelen ####
 
-Het negatieve aspect van SSH is dat je er geen anonieme toegang over kunt geven. Mensen moeten via SSH toegang hebben om er gebruik van te kunnen maken, zelfs als het alleen lezen is, zodat SSH toegang niet bevorderlijk is voor open source projecten. Als je het alleen binnen je bedrijfsnetwerk gebruikt, dan kan SSH misschien het enige protocol zijn waar je mee in aanraking komt. Als je anonieme alleen-lezen toegang wilt toestaan tot je projecten, dan moet je SSH voor jezelf instellen om over te pushen, maar iets anders voor anderen om over te pullen.
+Het negatieve aspect van SSH is dat je er geen anonieme toegang over kunt geven. Mensen moeten via SSH toegang hebben om er gebruik van te kunnen maken, zelfs als het alleen lezen is, zodat SSH toegang niet bevordelijk is voor open source projecten. Als je het alleen binnen je bedrijfsnetwerk gebruikt, dan is SSH misschien het enige protocol waar je mee in aanraking komt. Als je anonieme alleen-lezen toegang wilt toestaan tot je projecten, dan moet je SSH voor jezelf instellen om over te pushen, maar iets anders voor anderen om over te pullen.
 
 ### Het Git protocol ###
 
-Het volgende is het Git protocol. Dit is een aparte daemon, die samen met Git geleverd wordt; het luistert op een toegewezen poort (9418), dat een vergelijkbare dienst verleend als het SSH protocol, maar dan zonder enige authenticatie. Om een repository te serveren over het Git protocol, moet je het `git-daemon-export-ok` bestand aanmaken — de daemon zal een repository zonder dit bestand erin niet serveren — maar buiten dat is er geen beveiliging. Ofwel het Git repository kan door iedereen gekloond worden, of helemaal niet. Dit betekent dat over het algemeen pushen niet mogelijk is via dit protocol. Je kunt push toegang aanzetten; maar gegeven het gebrek aan toegangscontrole als je push toegang aan zet, kan iedereen die de URL van jouw project op het internet vindt, pushen naar jouw project. We volstaan met te zeggen dat dit zeldzaam is.
+Het volgende is het Git protocol. Dit is een aparte daemon, die met Git meegeleverd wordt; het luistert op een toegewezen poort (9418), en verleent een vergelijkbare dienst als het SSH protocol, maar dan zonder enige authenticatie. Om een repository beschikbaar te stellen over het Git protocol, moet je het `git-export-daemon-ok` bestand aanmaken – de daemon zal een repository zonder dit bestand erin niet verspreiden – maar buiten dat is er geen beveiliging. Oftewel: de Git repository is er om gecloned te kunnen worden door iedereen, of het is er helemaal niet. Dit betekent dat er over het algemeen geen pushing is via dit protocol. Je kunt push toegang aanzetten, maar gegeven het gebrek aan authenticatie kan, als je de push toegang aan zet, iedereen die de URL van jouw project op het internet vindt, pushen naar jouw project. We volstaan met te zeggen dat dit zeldzaam is.
 
 #### De voordelen ####
 
-Het Git protocol is het snelste dat beschikbaar is. Als je veel verkeer serveert voor een publiek project, of een zeer groot project dat geen authenticatie nodig heeft voor leestoegang, dan is het waarschijnlijk dat je een Git daemon wilt instellen om je project te serveren. Het maakt van hetzelfde data-transport mechanisme gebruik als het SSH protocol, maar dan zonder de extra belasting van versleuteling en verificatie.
+Het Git protocol is het snelste dat beschikbaar is. Als je veel verkeer verwerkt voor een publiek project, of een zeer groot project dat geen gebruikersauthenticatie nodig heeft voor leestoegang, dan is het waarschijnlijk dat je een Git daemon wilt inrichten om je project te verspreiden. Het maakt van hetzelfde data-transport mechanisme gebruik als het SSH protocol, maar dan zonder de extra belasting van versleuteling en authenticatie.
 
 #### De nadelen ####
 
-Het nadeel van het Git protocol is het gebrek van toegangscontrole. Het is over het algemeen onwenselijk dat het Git protocol de enige toegang tot je project is. Over het algemeen zul je het samen met SSH toegang gebruiken voor de paar ontwikkelaars die push (schrijf-)toegang hebben en de rest laat je `git://` voor alleen leestoegang gebruiken.
-Het is waarschijnlijk ook het meest ingewikkelde protocol om in te stellen. Het moet een eigen daemon hebben, die speciaal ontworpen is — we zullen er een instellen in het “Gitosis” gedeelte van dit hoofdstuk — het gebruikt `xinetd` configuratie of iets dergelijks, wat niet altijd eenvoudig is. Het heeft ook firewall toegang tot poort 9418 nodig, wat geen standaard poort is dat bedrijfsfirewalls altijd toestaan. Achter grote bedrijfsfirewalls, is deze obscure poort meestal geblokkeerd.
+Het nadeel van het Git protocol is het gebrek aan authenticatie. Het is over het algemeen onwenselijk dat het Git protocol de enige toegang tot je project is. Meestal zul je het samen met SSH toegang gebruiken voor de paar ontwikkelaars die push (schrijf-)toegang hebben en de rest laat je `git://` voor alleen leestoegang gebruiken.
+Het is waarschijnlijk ook het meest ingewikkelde protocol om in te stellen. Het moet een eigen daemon hebben, die speciaal voor die situatie ingericht is – we zullen er een instellen in het "Gitosis" gedeelte van dit hoofdstuk – het gebruikt `xinetd` configuratie of iets dergelijks, wat ook niet altijd eenvoudig is op te zetten. Het heeft ook firewall toegang tot poort 9418 nodig, wat geen standaard poort is dat in bedrijfsfirewalls is opengezet. Bij firewalls van grote bedrijven, is deze obscure poort meestal geblokkeerd.
 
 ### Het HTTP/S protocol ###
 
-Als laatste hebben we het HTTP protocol. Het mooie aan het HTTP of HTTPS protocol is dat het simpel in te stellen is. Eigenlijk is alles wat je moet doen de kale Git repository in je HTTP document root zetten, en een specifieke `post-update` hook (haak) instellen en je bent klaar (zie hoofdstuk 7 voor details over Git hooks). Vanaf dat moment kan iedereen die toegang heeft tot de webserver waaronder je de repository gezet hebt ook je repository klonen. Om leestoegang tot je repository over HTTP toe te staan, doe je zoiets als het volgende:
+Als laatste hebben we het HTTP protocol. Het mooie aan het HTTP of HTTPS protocol is dat het simpel in te stellen is. Eigenlijk is alles wat je moet doen de kale Git repository in je HTTP document root zetten, en een specifieke `post-update` hook (haak) instellen en je bent klaar (zie hoofdstuk 7 voor details over Git hooks). Vanaf dat moment kan iedereen die toegang heeft tot de webserver waar je de repository op gezet hebt ook je repository clonen. Om leestoegang tot je repository over HTTP toe te staan, doe je zoiets als het volgende:
 
 	$ cd /var/www/htdocs/
 	$ git clone --bare /path/to/git_project gitproject.git
@@ -95,26 +95,26 @@ Dat is alles. De `post-update` hook, die standaard bij Git zit, voert het noodza
 
 	$ git clone http://example.com/gitproject.git
 
-In dit geval, gebruiken we het `/var/www/htdocs` pad wat gebruikelijk is voor Apache opstellingen, maar je kunt iedere statische webserver gebruiken — stop de kale repository in haar pad. De Git data wordt geserveerd als standaard statische bestanden (zie hoofdstuk 9 voor details over hoe het precies geserveerd wordt).
+In dit specifieke geval gebruiken we het `/var/www/htdocs` pad wat gebruikelijk is voor Apache opstellingen, maar je kunt iedere statische webserver gebruiken – stop de kale repository in haar pad. De Git data wordt geserveerd als standaard statische bestanden (zie hoofdstuk 9 voor details over hoe het precies geserveerd wordt).
 
-Het ook is mogelijk om Git over HTTP te laten pushen, alhoewel dat geen veelgebruikte techniek is en erom vraagt dat je complexe WebDAV vereisten instelt. Omdat het zelden gebruikt wordt, zullen we het niet in dit boek beschrijven. Als je geïnteresseerd bent om de HTTP-push protocollen te gebruiken, dan kun je op `http://www.kernel.org/pub/software/scm/git/docs/howto/setup-git-server-over-http.txt` lezen hoe je een repository kunt maken. Het fijne van Git laten pushen over HTTP is dat je iedere WebDAV server kunt gebruiken, zonder specifieke Git eigenschappen; dus je kunt deze functionaliteit gebruiken als je web-hosting provider WebDAV ondersteunt voor schrijf vernieuwingen aan je webpagina.
+Het ook is mogelijk om Git over HTTP te laten pushen, alhoewel dat geen veelgebruikte techniek is en het vraagt dat je complexe WebDAV instellingen opzet. Omdat het zelden gebruikt wordt, zullen we het niet in dit boek beschrijven. Als je geïnteresseerd bent om de HTTP-push protocollen te gebruiken, dan kun je op `http://www.kernel.org/pub/software/scm/git/docs/howto/setup-git-server-over-http.txt` lezen hoe je een repository kunt maken. Een fijn ding aan Git laten pushen over HTTP is dat je iedere WebDAV server kunt gebruiken, zonder specifieke Git funtionaliteit; dus je kunt deze functionaliteit gebruiken als je web-hosting provider WebDAV ondersteunt voor het maken van wijzigingen aan je webpagina.
 
 #### De voordelen ####
 
-Het voordeel van het gebruik van het HTTP protocol is dat het eenvoudig in te stellen is. Een handvol benodigde commando's uitvoeren zorgt voor een eenvoudige manier om de wereld leestoegang te geven aan je Git repository. Het kost slechts een paar minuten om te doen. Het HTTP protocol is niet erg belastend voor de systeembronnen van je server. Omdat het over het algemeen een statische webserver gebruikt om alle data te serveren, een normale Apache server kan gemiddeld duizenden bestanden serveren per seconde — is het moeilijk om zelfs een kleine server te overbelasten.
+Het voordeel van het gebruik van het HTTP protocol is dat het eenvoudig in te stellen is. Een handvol benodigde commando's uitvoeren zorgt voor een eenvoudige manier om de wereld leestoegang te geven tot je Git repository. Het kost slechts een paar minuten om te doen. Het HTTP protocol is niet erg belastend voor de systeembronnen van je server. Omdat het over het algemeen een statische webserver gebruikt om alle data te verspreiden - een normale Apache server kan gemiddeld duizenden bestanden zenden per seconde - is het moeilijk om zelfs een kleine server te overbelasten.
 
-Je kunt ook je repositories alleen-lezen serveren via HTTPS, wat betekend dat je het transport kunt versleutelen; of je kunt zelfs zover gaan dat je clients een specifiek gesigneerd SSL certificaat moeten gebruiken. Als je over het algemeen zo ver gaat, dan is het makkelijker om publieke SSH sleutels te gebruiken; maar het kan een betere oplossing in jouw specifieke geval om gesigneerde SSL certificaten of andere HTTP-gebaseerde verificatie methoden te gebruiken voor alleen-lezen toegang via HTTPS.
+Je kunt ook je repositories alleen-lezen serveren via HTTPS, wat inhoudt dat je het transport kunt versleutelen; je kunt zelfs zover gaan dat je clients een specifiek gesigneerd SSL certificaat laat gebruiken. Normaal gesproken als je je deze moeite wilt getroosten, dan is het makkelijker om publieke SSH sleutels te gebruiken; maar het kan een betere oplossing in jouw specifieke geval zijn om gesigneerde SSL certificaten of andere HTTP-gebaseerde authenticatie methoden te gebruiken voor alleen-lezen toegang via HTTPS.
 
-Een ander fijn ding is dat HTTP zo'n veel voorkomend protocol is dat bedrijfsfirewalls vaak zo ingesteld zijn dat ze verkeer via deze poort toelaten.
+Een andere prettige bijkomstigheid is dat HTTP een dusdanig veel voorkomend protocol is dat bedrijfsfirewalls vaak zo ingesteld zijn dat ze verkeer via deze poort toestaan.
 
 #### De nadelen ####
 
-Het nadeel van je repository serveren via HTTP is dat het relatief inefficiënt voor de client is. Over het algemeen duurt het een stuk langer om te klonen en te fetchen van de repository, en je hebt vaak een stuk meer netwerk belasting en transport volume via HTTP dan met elk van de andere netwerk protocollen. Omdat het niet zo intelligent is om alleen de data te versturen die je nodig hebt — er wordt geen dynamisch werk door de server gedaan in deze transacties — wordt vaak naar het HTTP protocol gerefereerd als zijnde een _dom_ protocol. Voor meer informatie over de verschillen in efficiëntie tussen het HTTP protocol en andere protocollen, zie Hoofdstuk 9.
+Het nadeel van je repository verspreiden via HTTP is dat het relatief inefficiënt voor de client is. Over het algemeen duurt het een stuk langer om te clonen en te fetchen van de repository, en je hebt vaak een veel hogere netwerk belasting en transport volume via HTTP dan met elk van de andere netwerk protocollen. Omdat het niet zo ingewikkeld is om alleen de data te versturen die je nodig hebt – er wordt geen dynamisch werk door de server gedaan in deze transacties – wordt vaak naar het HTTP protocol gerefereerd als zijnde een _dom_ protocol. Voor meer informatie over de verschillen in efficiëntie tussen het HTTP protocol en andere protocollen, zie Hoofdstuk 9.
 
 ## Git op een server krijgen ##
 
-Om een initiële Git server op te zetten, moet je een bestaande repository in een kale repository exporteren — een repository dat geen werkmap bevat. Dit is over het algemeen eenvoudig te doen.
-Om je repository te klonen met als doel het maken van een kale repository, voer je het `clone` commando uit met de `--bare` optie. Als vaste gewoonte eindigen de namen van kale repository mappen in `.git`, zoals:
+Om een initiële Git server op te zetten, moet je een bestaande repository naar een kale repository exporteren – een repository dat geen werkmap bevat. Dit is over het algemeen eenvoudig te doen.
+Om je repository te clonen met als doel het maken van een kale repository, voer je het clone commando uit met de `--bare` optie. Als vaste gewoonte eindigen de namen van kale repository mappen in `.git`, zoals:
 
 	$ git clone --bare my_project my_project.git
 	Initialized empty Git repository in /opt/projects/my_project.git/
@@ -125,11 +125,11 @@ Dit is ongeveer gelijk aan
 
 	$ cp -Rf my_project/.git my_project.git
 
-Er zijn een paar kleine verschillen in het configuratie bestand; maar voor jouw doeleinde ligt dit dicht bij hetzelfde. Het neemt de Git repository zelf, zonder een werkmap, en maakt een map aan specifiek alleen voor dat ding.
+Er zijn een paar kleine verschillen in het configuratie bestand, maar het komt op hetzelfde neer. Het neemt de Git repository zelf, zonder een werkmap, en maakt een map aan specifiek hiervoor.
 
 ### Het bare repository op een server zetten ###
 
-Nu dat je een kale kopie van je repository hebt, is het enige dat je moet doen het op een server zetten en je protocollen instellen. Stel dat je een server ingesteld hebt, die `git.example.com` heet, waar je SSH toegang op hebt, en waar je al je Git repositories wilt opslaan onder de `/opt/git` map. Je kunt je nieuwe repository instellen door je kale repository ernaartoe te kopiëren:
+Nu je een kale kopie van je repository hebt, is het enige dat je moet doen het op een server zetten en je protocollen instellen. Stel dat je een server ingesteld hebt, die `git.example.com` heet, waar je SSH toegang op hebt, en waar je al je Git repositories wilt opslaan onder de `/opt/git` map. Je kunt je nieuwe repository beschikbaar stellen door je kale repository ernaartoe te kopieeren:
 
 	$ scp -r my_project.git user@git.example.com:/opt/git
 
@@ -137,7 +137,7 @@ Op dit punt kunnen andere gebruikers, die SSH toegang hebben tot dezelfde server
 
 	$ git clone user@git.example.com:/opt/git/my_project.git
 
-Als een gebruiker in een server SSH-ed en schrijftoegang heeft tot de `/opt/git/my_project.git` map, dan hebben ze automatisch ook push toegang. Git zal automatisch correcte groep schrijfrechten aan een repository toevoegen als je het `git init` commando met de `--shared` optie uitvoert.
+Als een gebruiker met SSH op een server inlogt en schrijftoegang heeft tot de `/opt/git/my_project.git` map, dan hebben ze automatisch ook push toegang. Git zal automatisch de correcte groep schrijfrechten aan een repository toekennen als je het `git init` commando met de `--shared` optie uitvoert.
 
 	$ ssh user@git.example.com
 	$ cd /opt/git/my_project.git
@@ -145,9 +145,9 @@ Als een gebruiker in een server SSH-ed en schrijftoegang heeft tot de `/opt/git/
 
 Je ziet hoe eenvoudig het is om een Git repository te nemen, een kale versie aan te maken, en het op een server plaatsen waar jij en je medewerkers SSH toegang tot hebben. Nu ben je klaar om aan hetzelfde project samen te werken.
 
-Het is belangrijk om te zien dat dit letterlijk alles is wat je moet doen om een bruikbare Git server te draaien waarop meerdere mensen toegang hebben — voeg alleen een paar SSH accounts toe op een server, en stop een kale repository ergens waar al die gebruikers lees- en schrijftoegang tot hebben. Je bent er klaar voor — je hebt niets anders nodig.
+Het is belangrijk om op te merken dat dit letterlijk alles is wat je moet doen om een bruikbare Git server te draaien waarop meerdere mensen toegang hebben – voeg alleen een paar SSH accounts toe op een server, en stop een kale repository ergens waar al die gebruikers lees- en schrijftoegang toe hebben. Je bent er klaar voor – je hebt niets anders nodig.
 
-In de volgende secties zul je zien hoe je meer ingewikkelde opstellingen kunt maken. Deze bespreking zal het niet hoeven aanmaken van gebruikersaccounts voor elke gebruiker omvatten, publieke leestoegang tot repositories, grafische web interfaces, de Gitosis applicatie gebruiken en meer. Maar, hou in gedachten dat om samen te kunnen werken met mensen op een privéproject, alles wat je _nodig_ hebt een SSH server en een kale repository is.
+In de volgende paragrafen zul je zien hoe je meer ingewikkelde opstellingen kunt maken. Deze bespreking zal het niet hoeven aanmaken van gebruikers accounts voor elke gebruiker, publieke leestoegang tot repositories, grafische web interfaces, de Gitosis applicatie gebruiken en meer omvatten. Maar, hou in gedachten dat om samen te kunnen werken met mensen op een privé project, alles wat je _nodig_ hebt is een SSH server en een kale repository.
 
 ### Kleine opstellingen ###
 
@@ -155,20 +155,20 @@ Als je met een kleine groep bent of net begint met Git in je organisatie en slec
 
 #### SSH toegang ####
 
-Als je reeds een server hebt waar al je ontwikkelaars SSH toegang op hebben, dan is het over het algemeen het gemakkelijkst om je eerste repository daar in te stellen, omdat je dan bijna niets hoeft te doen (zoals beschreven in de vorige sectie). Als je meer complexe toegangscontrole wilt op je repositories, dan kun je ze instellen met de normale bestandssysteem permissies van het besturingssysteem dat op je server draait.
+Als je reeds een server hebt waar al je ontwikkelaars SSH toegang op hebben, dan is het over het algemeen het eenvoudigste om je eerste repository daar in te stellen, omdat je dan bijna niets hoeft te doen (zoals beschreven in de vorige paragraaf). Als je meer complexe toegangscontrole wilt op je repositories, dan kun je ze instellen met de normale bestandssysteem permissies van het operating systeem dat op je server draait.
 
-Als je je repositories op een server wilt zetten, die geen accounts heeft voor iedereen in je team die je schrijftoegang wilt geven, dan moet je SSH toegang voor ze instellen. We gaan er vanuit dat je een server hebt waarmee je dit kunt doen, je reeds een SSH server geïnstalleerd hebt, en dat de manier is waarop je toegang hebt tot de server.
+Als je je repositories op een server wilt zetten, die geen accounts heeft voor iedereen in je team die je schrijftoegang wilt geven, dan moet je SSH toegang voor ze instellen. We gaan er vanuit dat je een server hebt waarmee je dit kunt doen, dat je reeds een SSH server geïnstalleerd hebt, en dat de manier is waarop je toegang hebt tot de server.
 
-Er zijn een paar manieren waarop je iedereen in je team toegang kunt geven. De eerste is voor iedereen accounts aanmaken, wat rechttoe rechtaan is maar omslachtig kan zijn. Je wilt misschien niet `adduser` uitvoeren en tijdelijke wachtwoorden voor iedere gebruiker instellen.
+Er zijn een paar manieren waarop je iedereen in je team toegang kunt geven. De eerste is voor iedereen accounts aanmaken, wat rechttoe rechtaan is maar bewerkelijk kan zijn. Je wilt vermoedelijk niet `adduser` uitvoeren en tijdelijke wachtwoorden instellen voor iedere gebruiker.
 
-Een tweede methode is een enkele 'git' gebruiker aanmaken op de machine, aan iedere gebruiker die schijftoegang moet hebben vragen of ze je een publieke SSH sleutel sturen, en die sleutel toevoegen aan het `~/.ssh/authorized_keys` bestand van je nieuwe 'git' gebruiker. Vanaf dat punt zal iedereen toegang hebben op die machine via de 'git' gebruiker. Dit tast de commit data op geen enkele manier aan — de SSH gebruiker waarmee je inlogd zal de commits die je opgeslagen hebt niet beïnvloeden.
+Een tweede methode is een 'git' gebruiker aan te maken op de machine, aan iedere gebruiker die schijftoegang moet hebben vragen of ze je een publieke SSH sleutel sturen, en die sleutel toevoegen aan het `~/.ssh/authorized_keys` bestand van je nieuwe 'git' gebruiker. Vanaf dat moment zal iedereen toegang hebben op die machine via de 'git' gebruiker. Dit tast de commit data op geen enkele manier aan – de SSH gebruiker waarmee je inlogt zal de commits die je opgeslagen hebt niet beïnvloeden.
 
-Een andere manier waarop je het kunt doen is je SSH server laten verifiëren vanaf een LDAP server of een andere gecentraliseerde authenticatie bron, die je misschien al ingesteld hebt. Zolang iedere gebruiker een shell toegang heeft op de machine, zou ieder SSH authenticatie mechanisme dat je kunt bedenken moeten werken.
+Een andere manier waarop je het kunt doen is je SSH server laten authenticeren middels een LDAP server of een andere gecentraliseerde authenticatie bron, die je misschien al ingesteld hebt. Zolang iedere gebruiker shell toegang kan krijgen op de machine, zou ieder SSH authenticatie mechanisme dat je kunt bedenken moeten werken.
 
 ## Je publieke SSH sleutel genereren ##
 
-Dat gezegd hebbende, zijn er vele Git servers die authenticeren met een publieke SSH sleutel. Om een publieke sleutel te hebben, zal iedere gebruiker in je systeem er een moeten genereren als ze er nog geen hebben. Dit proces is bij alle besturingssystemen vergelijkbaar.
-Als eerste moet je controleren dat je er niet al een hebt. Standaard staan de SSH sleutels van de gebruikers in hun eigen `~/.ssh` map. Je kunt makkelijk nagaan of je al een sleutel hebt door naar die map te gaan en de inhoud te tonen:
+Dat gezegd hebbende, zijn er vele Git servers die authenticeren met een publieke SSH sleutel. Om een publieke sleutel te hebben, zal iedere gebruiker in je systeem er een moeten genereren als ze er nog geen hebben. Dit proces is bij alle operating systemen vergelijkbaar.
+Als eerste moet je controleren dat je er niet al een hebt. Standaard staan de SSH sleutels van de gebruikers in hun eigen `~/.ssh` map. Je kunt makkelijk nagaan of je al een sleutel hebt door naar die map te gaan en de inhoud te bekijken:
 
 	$ cd ~/.ssh
 	$ ls
@@ -187,7 +187,7 @@ Je bent op zoek naar een aantal bestanden genaamd iets en iets.pub, waarbij het
 	The key fingerprint is:
 	43:c5:5b:5f:b1:f1:50:43:ad:20:a6:92:6a:1f:9a:3a schacon@agadorlaptop.local
 
-Eerst bevestigt het de locatie waar je de sleutel wilt opslaan (`.ssh/id_rsa`), en vervolgens vraagt het tweemaal om een wachtzin, die je leeg kunt laten als je geen wachtwoord wilt intypen op het moment dat je de sleutel gebruikt.
+Eerst bevestigt het de lokatie waar je de sleutel wilt opslaan (`.ssh/id_rsa`), en vervolgens vraagt het tweemaal om een wachtwoord, die je leeg kunt laten als je geen wachtwoord wilt intypen op het moment dat je de sleutel gebruikt.
 
 Iedere gebruiker die dit doet, moet zijn sleutel sturen naar jou of degene die de Git server beheert (aangenomen dat je een SSH server gebruikt die publieke sleutels vereist). Het enige dat ze hoeven doen is de inhoud van het `.pub` bestand kopiëren en e-mailen. De publieke sleutel ziet er ongeveer zo uit:
 
@@ -203,7 +203,7 @@ Voor een uitgebreide tutorial over het aanmaken van een SSH sleutel op meerdere
 
 ## De server instellen ##
 
-Laten we het instellen van SSH toegang aan de server kant eens doorlopen. In dit voorbeeld zul je de `authorized_keys` methode gebruiken om je gebruikers te verifiëren. We gaan er ook vanuit dat je een standaard Linux distributie gebruikt zoals Ubuntu. Als eerste creëer je een 'git' gebruiker een een `.ssh` map voor die gebruiker.
+Laten we het instellen van SSH toegang aan de server kant eens doorlopen. In dit voorbeeld zul je de `authorized_keys` methode gebruiken om je gebruikers te authenticeren. We gaan er ook vanuit dat je een standaard Linux distributie gebruikt zoals Ubuntu. Als eerste maak je een 'git' gebruiker aan en een `.ssh` map voor die gebruiker.
 
 	$ sudo adduser git
 	$ su git
@@ -220,20 +220,20 @@ Daarna moet je een aantal publieke SSH sleutels van ontwikkelaars aan het `autho
 	O7TCUSBdLQlgMVOFq1I2uPWQOkOWQAHukEOmfjy2jctxSDBQ220ymjaNsHT4kgtZg2AYYgPq
 	dAv8JggJICUvax2T9va5 gsg-keypair
 
-Je voegt ze slechts toe aan je `authorized_keys` bestand:
+Je voegt ze eenvoudigweg toe aan je `authorized_keys` bestand:
 
 	$ cat /tmp/id_rsa.john.pub >> ~/.ssh/authorized_keys
 	$ cat /tmp/id_rsa.josie.pub >> ~/.ssh/authorized_keys
 	$ cat /tmp/id_rsa.jessica.pub >> ~/.ssh/authorized_keys
 
-Nu kun je een leeg repository voor ze instellen door `git init` uit te voeren met de `--bare` optie, wat het repository initialiseert zonder een werkmap:
+Nu kun je een lege repository voor ze instellen door `git init` uit te voeren met de `--bare` optie, wat de repository initialiseert zonder een werkmap:
 
 	$ cd /opt/git
 	$ mkdir project.git
 	$ cd project.git
 	$ git --bare init
 
-Daarna kunnen John, Josie of Jessica de eerste versie van hun project in de repository pushen door het als een remote toe te voegen en naar een branch te pushen. Let op dat iemand met een shell op de machine zal moeten inloggen en een kale repository moet creëren, iedere keer als je een project wilt toevoegen. Laten we `gitserver` als hostnaam gebruiken voor de server waar je je 'git' gebruiker en repository hebt ingesteld. Als je het intern gaat draaien, en je de DNS instelt zodat `gitserver` naar die server wijst, dan kun je de commando's vrijwel ongewijzigd gebruiken:
+Daarna kunnen John, Josie of Jessica de eerste versie van hun project in de repository pushen door het als een remote toe te voegen en naar een branch te pushen. Let op dat iemand met een shell op de machine zal moeten inloggen en een kale repository moet creëren, iedere keer als je een project wilt toevoegen. Laten we `gitserver` als hostnaam gebruiken voor de server waar je de 'git' gebruiker en repository hebt ingesteld. Als je het binnenshuis draait, en je de DNS instelt zodat `gitserver` naar die server wijst, dan kun je de commando's vrijwel ongewijzigd gebruiken:
 
 	# op Johns computer
 	$ cd myproject
@@ -243,14 +243,14 @@ Daarna kunnen John, Josie of Jessica de eerste versie van hun project in de repo
 	$ git remote add origin git@gitserver:/opt/git/project.git
 	$ git push origin master
 
-Op dat punt kunnen de anderen het klonen en wijzigingen even gemakkelijk terug pushen:
+Vanaf dat moment kunnen de anderen het clonen en wijzigingen even gemakkelijk terug pushen:
 
 	$ git clone git@gitserver:/opt/git/project.git
 	$ vim README
 	$ git commit -am 'fix for the README file'
 	$ git push origin master
 
-Met deze methode kun je snel een lees/schrijf Git server draaiend krijgen voor een handvol ontwikkelaars.
+Met deze methode kun je snel een lees/schrijf Git server draaiend krijgen voor een handjevol ontwikkelaars.
 
 Als een extra voorzorgsmaatregel kun je de 'git' gebruiker makkelijk beperken tot het doen van alleen Git activiteiten, met een gelimiteerde shell applicatie genaamd `git-shell` die bij Git geleverd wordt.
 Als je dit als login shell voor je 'git' gebruiker instelt, dan kan de 'git' gebruiker geen normale shell toegang hebben op je server. Specificeer `git-shell` in plaats van bash of csh voor je gebruikers login shell om dit te gebruiken. Om dit te doen zul je waarschijnlijk het `/etc/passwd` bestand aan moeten passen:
@@ -273,9 +273,9 @@ Nu kan de 'git' gebruiker de SSH connectie alleen gebruiken om Git repositories
 
 ## Publieke toegang ##
 
-Wat als je anonieme leestoegang op je project wil? Misschien wil je geen intern privéproject serveren, maar een open source project. Of misschien heb je een serie geautomatiseerde bouwservers of continue integratie servers die vaak wijzigen, en wil je niet doorlopend SSH sleutels hoeven genereren — je wil gewoon eenvoudige leestoegang toevoegen.
+Wat als je anonieme leestoegang op je project wil? Misschien wil je geen intern privé project beheren, maar een open source project. Of misschien heb je een aantal geautomatiseerde bouwservers of continue integratie servers die vaak wijzigen, en wil je niet doorlopend SSH sleutels hoeven genereren – je wil gewoon eenvoudige leestoegang toevoegen.
 
-Waarschijnlijk is de eenvoudigste manier voor kleinschalige opstellingen om een statische webserver in te stellen, waarbij de document root naar de plaats van je Git repositories wijst, en dan die `post-update` haak aanzetten waar we het in de eerste sectie van dit hoofdstuk over gehad hebben. Laten we eens uitgaan van het vorige voorbeeld. Stel dat je je repositories in de `/opt/git` map hebt staan, en er draait een Apache server op je machine. Nogmaals, je kunt hiervoor iedere web server gebruiken: maar als voorbeeld zullen we wat basis Apache configuraties laten zien, die je een idee kunnen geven van wat je nodig hebt.
+Waarschijnlijk is de eenvoudigste manier voor kleinschalige opstellingen om een statische webserver in te stellen, waarbij de document root naar de plaats van je Git repositories wijst, en dan de `post-update` haak aanzetten waar we het in de eerste paragraaf van dit hoofdstuk over gehad hebben. Laten we eens uitgaan van het voorgaande voorbeeld. Stel dat je je repositories in de `/opt/git` map hebt staan, en er draait een Apache server op je machine. Nogmaals, je kunt hiervoor iedere web server gebruiken: maar als voorbeeld zullen we wat basis Apache configuraties laten zien, die je een idee kunnen geven van wat je nodig hebt.
 
 Eerst moet je de haak aanzetten:
 
@@ -293,7 +293,7 @@ Wat doet deze `post-update` haak? Het ziet er ongeveer zo uit:
 
 Dit betekent dat wanneer je naar de server via SSH pusht, Git dit commando uitvoert om de benodigde bestanden voor HTTP fetching te verversen.
 
-Vervolgens moet je een VirtualHost toevoeging in je Apache configuratie aanmaken, met de document root als de hoofdmap van je Git projecten. Hier nemen we aan dat je joker DNS ingesteld hebt om `*.gitserver` door te sturen naar waar je dit alles draait:
+Vervolgens moet je een VirtualHost toevoeging in je Apache configuratie aanmaken, met de document root als de hoofdmap van je Git projecten. Hier nemen we aan dat je wildcard DNS ingesteld hebt om `*.gitserver` door te sturen naar waar je dit alles draait:
 
 	<VirtualHost *:80>
 	    ServerName git.gitserver
@@ -304,7 +304,7 @@ Vervolgens moet je een VirtualHost toevoeging in je Apache configuratie aanmaken
 	    </Directory>
 	</VirtualHost>
 
-Je zult ook de Unix gebruikers groep van de `/opt/git` mappen moeten instellen op `www-data` zodat je web server leestoegang heeft op de repositories, omdat de Apache instantie die het CGI script uitvoert (standaard) als die gebruiker draait:
+Je zult ook de Unix gebruikers groep van de `/opt/git` mappen moeten instellen op `www-data` zodat je web server leestoegang hebt op de repositories, omdat de Apache instantie die het CGI script uitvoert (standaard) als die gebruiker draait:
 
 	$ chgrp -R www-data /opt/git
 
@@ -312,11 +312,11 @@ Als je Apache herstart, dan zou je je repositories onder die map moeten kunnen k
 
 	$ git clone http://git.gitserver/project.git
 
-Op deze manier kun je HTTP-gebaseerde toegang voor ieder van je projecten voor een groot aantal gebruikers in slechts een paar minuten instellen. Een andere eenvoudige optie om publieke ongeverifieerde toegang in te stellen is een Git daemon starten, alhoewel dat vereist dat je het proces als daemon uitvoert – we beschrijven deze optie in de volgende sectie als je een voorkeur hebt voor die route.
+Op deze manier kun je HTTP-gebaseerde toegang voor elk van je projecten voor een groot aantal gebruikers in slechts een paar minuten instellen. Een andere eenvoudige optie om publieke ongeauthenticeerde toegang in te stellen is een Git daemon te starten, alhoewel dat vereist dat je het proces als daemon uitvoert – we beschrijven deze optie in de volgende paragraaf als je een voorkeur hebt voor deze variant.
 
 ## GitWeb ##
 
-Nu dat je basis lees/schrijf en alleen-lezen toegang tot je project hebt, wil je misschien een eenvoudige web-gebaseerde visualiseerder instellen. Git levert een CGI script genaamd GitWeb mee, dat veelal voor hiervoor gebruikt wordt. Je kunt GitWeb in gebruik zien bij sites zoals `http://git.kernel.org` (zie Figuur 4-1).
+Nu je basis lees/schrijf en alleen-lezen toegang tot je project hebt, wil je misschien een eenvoudige web-gebaseerde visualisatie instellen. Git levert een CGI script genaamd GitWeb mee, dat veelal voor hiervoor gebruikt wordt. Je kunt GitWeb in gebruik zien bij sites zoals `http://git.kernel.org` (zie Figuur 4-1).
 
 Insert 18333fig0401.png
 Figuur 4-1. De GitWeb web-gebaseerde gebruikers interface.
@@ -327,11 +327,11 @@ Als je wil zien hoe GitWeb er op jouw project uitziet, dan heeft Git een command
 	[2009-02-21 10:02:21] INFO  WEBrick 1.3.1
 	[2009-02-21 10:02:21] INFO  ruby 1.8.6 (2008-03-03) [universal-darwin9.0]
 
-Dat start een HTTPD server op poort 1234 op en start automatisch een web browser op die met die pagina opent. Het is dus makkelijk voor jou. Als je klaar bent en de server wilt afsluiten, dan kun je hetzelfde commando uitvoeren met de `--stop` optie:
+Dat start een HTTPD server op poort 1234 op en start automatisch een web browser op die met die pagina opent. Het is dus makkelijk voor je. Als je klaar bent en de server wilt afsluiten, dan kun je hetzelfde commando uitvoeren met de `--stop` optie:
 
 	$ git instaweb --httpd=webrick --stop
 
-Als je de web interface doorlopend op een server wilt draaien voor je team of voor een open source project dat je serveert, dan moet je het CGI script instellen zodat het door je normale web server geserveerd wordt. Sommige Linux distributies hebben een `gitweb` pakket dat je misschien kunt installeren via `apt` of `yum`, dus misschien wil je dat eerst proberen. We zullen zeer vlot door een handmatige GitWeb installatie heenlopen. Eerst moet je de Git broncode pakken, waar GitWeb bij zit, en het persoonlijke CGI script genereren:
+Als je de web interface doorlopend op een server wilt draaien voor je team of voor een open source project dat je verspreid, dan moet je het CGI script instellen zodat het door je normale web server geserveerd wordt. Sommige Linux distributies hebben een `gitweb` pakket dat je misschien kunt installeren via `apt` of `yum`, dus misschien kan je dat eerst proberen. We zullen snel door een handmatige GitWeb installatie heenlopen. Eerst moet je de Git broncode pakken waar GitWeb bij zit, en het aangepaste CGI script genereren: 
 
 	$ git clone git://git.kernel.org/pub/scm/git/git.git
 	$ cd git/
@@ -339,7 +339,7 @@ Als je de web interface doorlopend op een server wilt draaien voor je team of vo
 	        prefix=/usr gitweb/gitweb.cgi
 	$ sudo cp -Rf gitweb /var/www/
 
-Let op dat je het commando moet vertellen waar het je Git repositories kan vinden met de `GITWEB_PROJECTROOT` variabele. Nu moet je zorgen dat de Apache server CGI gebruikt voor dat script, waarvoor je een VirtualHost kunt toevoegen:
+Merk op dat je het commando moet vertellen waar het je Git repositories kan vinden met de `GITWEB_PROJECTROOT` variabele. Nu moet je zorgen dat de Apache server CGI gebruikt voor dat script, waarvoor je een VirtualHost kunt toevoegen:
 
 	<VirtualHost *:80>
 	    ServerName gitserver
@@ -354,17 +354,18 @@ Let op dat je het commando moet vertellen waar het je Git repositories kan vinde
 	    </Directory>
 	</VirtualHost>
 
-Nogmaals, GitWeb kan geserveerd worden met iedere CGI capabele web server; als je iets anders prefereert zou het niet moeilijk in te stellen moeten zijn. Op dit punt zou je in staat moeten zijn om `http://gitserver/` te bezoeken en je repositories online te zien, en kun je `http://git.gitserver` gebruiken om je repositories over HTTP te klonen en te fetchen.
+Nogmaals, GitWeb kan geserveerd worden met iedere web server die in staat is CGI te verwerken; als je iets anders prefereert zou het niet moeilijk in te stellen moeten zijn. Op dit punt zou je in staat moeten zijn om `http://gitserver/` te bezoeken en je repositories online te zien, en kun je `http://git.gitserver` gebruiken om je repositories over HTTP te clonen en te fetchen.
 
 ## Gitosis ##
 
-De publieke sleutels van alle gebruikers in een `authorized_keys` bestand bewaren voor toegang werkt slechts tijdelijk goed. Als je honderden gebruikers hebt, dan is het moeizaam om dat proces te beheersen. Je moet iedere keer in de server inloggen, en er is geen toegangscontrole — iedereen in het bestand heeft lees- en schrijftoegang op ieder project.
+De publieke sleutels van alle gebruikers in een `authorized_keys` bestand bewaren voor toegang werkt slechts korte tijd goed. Als je honderden gebruikers hebt, dan is het bewerkelijk om dat proces te volgen. Je moet iedere keer in de server inloggen, en er is geen toegangscontrole – iedereen in het bestand heeft lees- en schrijftoegang op ieder project.
 
-Op dit punt wil je je misschien wenden tot een veelgebruikt software project genaamd Gitosis. Gitosis is in feite een set scripts die je helpen het `authorized_keys` bestand te beheren en eenvoudige toegangscontrole te implementeren. Het meest interessante gedeelte is dat de gebruikers interface voor deze applicatie om mensen toe te voegen en toegang te bepalen, geen web interface is maar een speciale Git repository. Je stelt de informatie in in dat project; en als je het pusht, dan herconfigureert Gitosis de server op basis van dat project, wat stoer is.
+Op dit punt wil je je misschien wenden tot een veelgebruikt software project genaamd Gitosis. Gitosis is in feite een verzameling scripts die je helpen het `authorized_keys` bestand te beheren alsmede eenvoudig toegangscontrole te implementeren. Het meest interessante gedeelte is dat de gebruikers interface voor deze applicatie om mensen toe te voegen en toegang te bepalen, geen web interface is maar een speciale Git repository. Je beheert de informatie in dat project; en als je het pushed, dan herconfigureert Gitosis de server op basis van dat project, wat best wel stoer is.
 
-Gitosis installeren is niet de makkelijkste taak ooit, maar het is ook niet te moeilijk. Het is het makkelijkst om er een Linux server voor te gebruiken — deze voorbeelden gebruiken een standaard Ubuntu 8.10 server.
+Gitosis installeren is niet de makkelijkste taak ooit, maar het is ook niet te moeilijk. Het is het makkelijkste om er een Linux server voor te gebruiken – deze voorbeelden gebruiken een standaard Ubuntu 8.10 server.
+>>>>>>> [nl] Language and wording corrections. Introducing characters from ASCII
 
-Gitosis vereist wat Python applicaties, dus moet je eerst het Python setuptools pakket installeren, wat Ubuntu meelevert als python-setuptools:
+Gitosis vereist enkele Python applicaties, dus moet je eerst het Python setuptools pakket installeren, wat Ubuntu beschikbaar stelt als python-setuptools:
 
 	$ apt-get install python-setuptools
 
@@ -378,7 +379,7 @@ Daarmee worden een aantal uitvoerbare bestanden geïnstalleerd, die Gitosis zal
 
 	$ ln -s /opt/git /home/git/repositories
 
-Gitosis zal je sleutels voor je beheren, dus je moet het huidige bestand verwijderen, de sleutels later opnieuw toevoegen en Gitosis het `authorized_keys` bestand automatisch laten beheren. Voor nu verplaatsen we het `authorized_keys` bestand:
+Gitosis zal je sleutels voor je beheren, dus je moet het huidige bestand verwijderen, om de sleutels later opnieuw toe te voegen en Gitosis het `authorized_keys` bestand automatisch laten beheren. Voor nu verplaatsen we het `authorized_keys` bestand:
 
 	$ mv /home/git/.ssh/authorized_keys /home/git/.ssh/ak.bak
 
@@ -396,8 +397,7 @@ Nu wordt het tijd om Gitosis te initialiseren. Je doet dit door het `gitosis-ini
 	Initialized empty Git repository in /opt/git/gitosis-admin.git/
 	Reinitialized existing Git repository in /opt/git/gitosis-admin.git/
 
-Dit staat de gebruiker met die sleutel toe de hoofd Git repository, die de Gitosis installatie beheert, aan te passen. Daarna zul je met de hand het execute
-bit op het `post-update` script moeten instellen voor je nieuwe beheer repository.
+Dit staat de gebruiker met die sleutel toe de hoofd Git repository, die de Gitosis installatie beheert, aan te passen. Daarna zul je met de hand het execute bit op het `post-update` script moeten instellen voor je nieuwe beheer repository.
 
 	$ sudo chmod 755 /opt/git/gitosis-admin.git/hooks/post-update
 

From 19f45e5e110736dc8c9304d1aaab8f93f28d9408 Mon Sep 17 00:00:00 2001
From: Cor <cor.takken@cgi.com>
Date: Fri, 17 Jan 2014 15:03:53 +0100
Subject: [PATCH 125/690] [nl] added diacritical characters. Added (start of)
 gitolite translation.

---
 nl/04-git-server/01-chapter4.markdown | 278 +++++++++++++-------------
 1 file changed, 136 insertions(+), 142 deletions(-)

diff --git a/nl/04-git-server/01-chapter4.markdown b/nl/04-git-server/01-chapter4.markdown
index a27d58789..9b2901a18 100644
--- a/nl/04-git-server/01-chapter4.markdown
+++ b/nl/04-git-server/01-chapter4.markdown
@@ -1,24 +1,24 @@
 # Git op de server #
 
-Op dit punt zou je alledaagse taken waarvoor je Git zult gebruiken kunnen doen. Maar, om samen te kunnen werken in Git zul je een remote repository moeten hebben. Technisch gezien kun je wijzigingen pushen en pullen van individuele repositories, maar dat wordt afgeraden, omdat je vrij gemakkelijk het werk waar anderen mee bezig zijn in de war kunt schoppen als je niet oppast. Daarnaast wil je dat je medewerkers de repository kunnen bereiken, zelfs als jouw computer van het netwerk is – het hebben van een betrouwbare gezamenlijke repository is vaak handig. Daarom heeft het hebben van een tussenliggende repository waarin je met iemand anders samenwerkt de voorkeur, en daaruit pushen en pullen. We zullen deze repository de `Git server` noemen, maar je zult zien dat het over het algemeen maar een klein beetje systeembronnen kost om een Git repository te verzorgen, dus je zult er zelden een complete server voor nodig hebben.
+Op dit punt zou je alledaagse taken waarvoor je Git zult gebruiken kunnen doen. Maar, om samen te kunnen werken in Git zul je een remote repository moeten hebben. Technisch gezien kun je wijzigingen pushen en pullen van individuele repositories, maar dat wordt afgeraden, omdat je vrij gemakkelijk het werk waar anderen mee bezig zijn in de war kunt schoppen als je niet oppast. Daarnaast wil je dat je medewerkers de repository kunnen bereiken, zelfs als jouw computer van het netwerk is – het hebben van een betrouwbare gezamenlijke repository is vaak handig. De voorkeursmethode om met iemand samen te werken is om een tussenliggende repository in te richten waar beide partijen toegang to hebben en om daar naartoe te pushen en vandaan te pullen. We zullen deze repository de `Git server` noemen, maar je zult zien dat het over het algemeen maar een klein beetje systeembronnen kost om een Git repository te verzorgen, dus je zult er zelden een complete server voor nodig hebben.
 
-Een Git server draaien is eenvoudig. Als eerste kies je met welke protocollen je de server wilt laten communiceren. Het eerste gedeelte van dit hoofdstuk zullen we de beschikbare protocollen bespreken met de voor- en nadelen van elk. De volgende paragrafen zullen we veel voorkomende opstellingen bespreken, die van die protocollen gebruik maken en hoe je je server ermee kunt opzetten. Als laatste laten we een paar servers van derden zien, als je het niet erg vindt om je code op de server van een ander te zetten en niet het gedoe wilt hebben van het opzetten en onderhouden van je eigen server.
+Een Git server draaien is eenvoudig. Als eerste kies je met welke protocollen je de server wilt laten communiceren. Het eerste gedeelte van dit hoofdstuk zullen we de beschikbare protocollen bespreken met de voor- en nadelen van elk. De daarop volgende paragrafen zullen we een aantal veel voorkomende opstellingen bespreken die van die protocollen gebruik maken en hoe je je server ermee kunt opzetten. Als laatste laten we een paar servers van derden zien, als je het niet erg vindt om je code op de server van een ander te zetten en niet het gedoe wilt hebben van het opzetten en onderhouden van je eigen server.
 
-Als je geen interesse hebt om je eigen server te draaien, dan kun je de direct naar de laatste paragraaf van dit hoofdstuk gaan om wat mogelijkheden van online accounts te zien en dan door te gaan naar het volgende hoofdstuk, waar we alle zaken bespreken die komen kijken bij het werken met een gedistribueerde versiebeheer omgeving.
+Als je niet van plan bent om je eigen server te draaien, dan kun je de direct naar de laatste paragraaf van dit hoofdstuk gaan om wat mogelijkheden van online accounts te zien en dan door gaan naar het volgende hoofdstuk, waar we diverse zaken bespreken die komen kijken bij het werken met een gedistribueerde versiebeheer omgeving.
 
-Een remote repository is over het algemeen een _bare repository_ (kale repository) – een Git repository dat geen werkmap heeft. Omdat de repository alleen gebruikt wordt als een samenwerkingspunt, is er geen reden om een snapshot op de schijf te hebben; alleen de Git data. Een kale repository is eenvoudigweg de inhoud van de `.git` map in je project, en niets meer.
+Een remote repository is over het algemeen een _bare repository_ (kale repository) – een Git repository dat geen werkmap heeft. Omdat de repository alleen gebruikt wordt als een samenwerkingspunt, is er geen reden om een snapshot op de schijf te hebben; het is alleen de Git data. Een kale repository is eenvoudigweg de inhoud van de `.git` map in je project, en niets meer.
 
 ## De protocollen ##
 
-Git kan vier veel voorkomende netwerk protocollen gebruiken om data te transporteren: Lokaal, Beveiligde Shell (SSH), Git en HTTP. Hier laten we zien wat deze zijn, en in welke omstandigheden je ze wilt gebruiken (of juist niet).
+Git kan vier veel voorkomende netwerk protocollen gebruiken om data te transporteren: Lokaal, Beveiligde Shell (Secure Shell, SSH), Git en HTTP. Hier bespreken we wat deze zijn, en in welke omstandigheden je ze zou willen gebruiken (of juist niet).
 
 Het is belangrijk om op te merken dat, met uitzondering van de HTTP protocollen, ze allemaal een werkende Git versie op de server geïnstalleerd moeten hebben.
 
 ### Lokaal protocol ###
 
-Het meest basale is het _lokale protocol_, waarbij het remote repository in een andere map op de schijf staat. Deze opzet wordt vaak gebruikt als iedereen in het team toegang heeft op een gedeeld bestandssyteem zoals een NFS map, of in het weinig voorkomende geval dat iedereen op dezelfde computer werkt. Het laatste zou niet ideaal zijn, want dan zouden alle repositories op dezelfde computer staan, zodat de kans op een fataal verlies veel groter wordt.
+Het simpelste is het _Lokale protocol_, waarbij de remote repository in een andere directory op de schijf staat. Deze opzet wordt vaak gebruikt als iedereen in het team toegang heeft op een gedeeld bestandssyteem zoals een NFS mount, of in het weinig voorkomende geval dat iedereen op dezelfde computer werkt. Het laatste zou niet ideaal zijn, want dan zouden alle repositories op dezelfde computer staan, zodat een fataal verlies van gegevens veel groter wordt.
 
-Als je een gedeeld bestandssysteem hebt, dan kun je klonen, pushen en pullen van een op een lokaal bestand gebaseerde repository. Om een dergelijk repository te klonen, of om er een als een remote aan een bestaand project toe te voegen, moet je het pad naar het repository als URL gebruiken. Bijvoorbeeld, om een lokaal repository te klonen, kun je zoiets als dit uitvoeren:
+Als je een gedeeld bestandssyteem hebt, dan kun je clonen, pushen en pullen van een op een lokaal bestand aanwezige repository. Om een dergelijk repository te clonen, of om er een als een remote aan een bestaand project toe te voegen, moet je het pad naar het repository als URL gebruiken. Bijvoorbeeld, om een lokaal repository te clonen, kun je zoiets als het volgende uitvoeren:
 
 	$ git clone /opt/git/project.git
 
@@ -26,29 +26,29 @@ Of je kunt dit doen:
 
 	$ git clone file:///opt/git/project.git
 
-Git werkt iets anders als je explicite `file://` aan het begin van de URL zet. Als je alleen het pad specificeert, probeert Git hardlinks te gebruiken, of het kopieert de bestanden die het nodig heeft. Als je `file://` specificeert, dan start Git de processen die het normaal gesproken gebruikt om data te transporteren over een netwerk, wat over het algemeen een minder efficiënte methode is om data te transporteren. De reden om `file://` wel te specificeren is als je een schone kopie van de repository wilt met de extra referenties of objecten eruit gelaten – over het algemeen na een import van een ander versiebeheer systeem of iets dergelijks (zie Hoofdstuk 9 voor onderhoudstaken). We zullen het normale pad hier gebruiken, omdat het bijna altijd sneller is om het zo te doen.
+Git werkt iets anders als je explicite `file://` aan het begin van de URL zet. Als je alleen het pad specificeert, probeert Git hardlinks te gebruiken, of het kopieert de bestanden die het nodig heeft. Als je `file://` specificeert, dan start Git de processen die het normaal gesproken gebruikt om data te transporteren over een netwerk, wat over het algemeen een minder efficiënte methode is om gegevens over te dragen. De belangrijkste reden om `file://` wel te specificeren is als je een schone kopie van de repository wilt met de vreemde refenties of objecten eruit gelaten – over het algemeen na een import uit een ander versiebeheer systeem of iets dergelijks (zie Hoofdstuk 9 voor onderhoudstaken). We zullen het normale pad hier gebruiken, omdat het bijna altijd sneller is om het zo te doen.
 
-Om een lokale repository aan een bestaand Git project toe te voegen, kun je zoiets als het volgende uitvoeren:
+Om een lokale repository aan een bestaand Git project toe te voegen, kun je iets als het volgende uitvoeren:
 
 	$ git remote add local_proj /opt/git/project.git
 
-Daarna kun je pushen en pullen van die remote alsof je over een netwerk werkt.
+Daarna kun je op gelijke wijze pushen naar, en pullen van die remote als je over een netwerk zou doen.
 
 #### De voordelen ####
 
-De voordelen van bestands-gebaseerde repositories zijn dat ze eenvoudig zijn en ze maken gebruik van bestaande bestandspermissies en netwerk toegang. Als je al een gedeeld bestandssysteem hebt, waar je hele team al toegang tot heeft, dan is een repository opzetten heel gemakkelijk. Je stopt de kale repository ergens waar iedereen gedeelde toegang tot heeft, en stelt de lees- en schrijfrechten in zoals je dat bij iedere andere gedeelde map zou doen. In de volgende paragraaf "Git op een Server Krijgen" bespreken we hoe je een kopie van een kale repository kunt exporteren voor dit doeleinde.
+De voordelen van bestands-gebaseerde repositories zijn dat ze eenvoudig zijn en ze maken gebruik van bestaande bestandspermissies en netwerk toegang. Als je al een gedeeld bestandssysteem hebt, waar het hele team al toegang toe heeft, dan is een repository opzetten heel gemakkelijk. Je stopt de kale repository ergens waar iedereen gedeelde toegang tot heeft, en stelt de lees- en schrijfrechten in zoals je dat bij iedere andere gedeelde directory zou doen. In de volgende paragraaf "Git op een Server Krijgen" bespreken we hoe je een kopie van een kale repository kunt exporteren voor dit doeleinde.
 
-Dit is ook een prettige optie om snel werk van een repository van iemand anders te pakken. Als jij en een collega aan hetzelfde project werken, en hij wil dat je iets bekijkt, dan is het uitvoeren van een commando zoals `git pull /home/john/project` vaak makkelijker dan dat hij naar een remote server moet pushen, en jij er van moet pullen.
+Dit is ook een prettige optie om snel werk uit een repository van iemand anders te pakken. Als jij en een collega aan hetzelfde project werken, en hij wil dat je iets bekijkt, dan is het uitvoeren van een commando zoals `git pull /home/john/project` vaak makkelijker dan dat hij naar een remote server moet pushen, en jij er van moet pullen.
 
 #### De nadelen ####
 
-Een van de nadelen van deze methode is dat gedeelde toegang over het algemeen moeilijker op te zetten en te bereiken is vanaf meerdere locaties dan basaal netwerk toegang. Als je wilt pushen van je laptop als je thuis bent, dan moet je de remote schijf aankoppelen, wat moeilijk en langzaam kan zijn in vergelijking tot netwerk gebaseerde toegang.
+Een van de nadelen van deze methode is dat gedeelde toegang over het algemeen moeilijker op te zetten en te bereiken is vanaf meerdere lokaties dan simpele netwerk toegang. Als je wilt pushen van je laptop als je thuis bent, dan moet je de remote schijf aankoppelen, wat moeilijk en langzaam kan zijn als je het vergelijkt met netwerk gebaseerde toegang.
 
-Het is ook belangrijk om te vermelden dat het niet altijd de snelste optie is, als je een gedeeld koppelpunt (mount) of iets dergelijks gebruikt. Een lokale repository is alleen snel als je snelle toegang tot de data hebt. Een repository op NFS is vaak langzamer dan een repository via SSH op dezelfde server omdat dit Git in staat stelt om op lokale schijven te werken vanaf ieder systeem.
+Het is ook belangrijk om te vermelden dat het niet altijd de snelste optie is, als je een gedeeld koppelpunt (mount) of iets dergelijks gebruikt. Een lokale repository is alleen snel als je snelle toegang tot de data hebt. Een repository op NFS is vaak langzamer dan een repository via SSH op dezelfde server omdat dit Git in staat stelt om op lokale schijven te werken op elk van de betrokken systemen.
 
 ### Het SSH protocol ###
 
-Waarschijnlijk het meest voorkomende protocol voor Git is SSH. Met als reden dat toegang met SSH tot servers in veel plaatsen al geconfigureerd is – en als dat niet het geval is, dan is het eenvoudig om dat te doen. SSH is ook het enige netwerk gebaseerde protocol waarvan je makkelijk kunt lezen en naartoe kunt schrijven. De andere twee netwerk protocollen (HTTP en Git) zijn over het algemeen alleen-lezen, dus zelfs als je ze al beschikbaar hebt voor de ongeïnitieerden, dan heb je nog steeds SSH nodig voor je eigen schrijftoegang. SSH is ook een geauthenticieerd protocol; en omdat het overal voorkomt, is het over het algemeen eenvoudig om in te stellen en te gebruiken.
+Waarschijnlijk het meest voorkomende protocol voor Git is SSH. De reden hiervoor is dat toegang met SSH tot servers in veel plaatsen al geconfigureerd is – en als dat niet het geval is, dan is het eenvoudig om dat te doen. SSH is ook het enige netwerk gebaseerde protocol waarvan je makkelijk kunt lezen en naartoe kunt schrijven. De andere twee netwerk protocollen (HTTP en Git) zijn over het algemeen alleen-lezen, dus zelfs als je ze al beschikbaar hebt voor de ongeïnitieerde massas, dan heb je nog steeds SSH nodig voor je eigen schrijfcommandos. SSH is ook een geauthenticieerd protocol; en omdat het alom aanwezig is, is het over het algemeen eenvoudig om in te stellen en te gebruiken.
 
 Om een Git repository via SSH te klonen, kun je een ssh:// URL opgeven zoals:
 
@@ -58,19 +58,19 @@ Of je geeft geen protocol op — Git gaat uit van SSH als je niet expliciet bent
 
 	$ git clone user@server:project.git
 
-Je kunt ook de gebruiker niet opgeven, en Git neemt aan dat je de gebruiker bedoelt waarmee je op het moment bent ingelogd.
+Je kunt ook de gebruiker weglaten, en Git gebruikt gegevens van de gebruiker waarmee je op dat moment bent ingelogd.
 
 #### De voordelen ####
 
-Er zijn vele voordelen om SSH te gebruiken. De eerste is dat je het eigenlijk wel moet gebruiken als je geauthenticeerde schrijftoegang op je repository via een netwerk wilt. Het tweede is dat het relatief eenvoudig in te stellen is – SSH daemons komen veel voor, veel systeembeheerders hebben er ervaring mee, en veel operating systemen zijn er mee uitgerust of hebben applicaties om ze te beheren. Daarnaast is toegang via SSH veilig – alle data transporten zijn versleuteld en geauthenticeerd. En als laatste is SSH efficiënt, net zoals het Git en lokale protocol, de data wordt zo compact mogelijk gemaakt voordat het getransporteerd wordt.
+Er zijn vele voordelen om SSH te gebruiken. Ten eerste moet je het eigenlijk wel gebruiken als je geauthenticeerde schrijftoegang op je repository via een netwerk wilt. Ten tweede is het relatief eenvoudig in te stellen – SSH daemons komen veel voor, veel systeembeheerders hebben er ervaring mee, en veel operating systemen zijn er mee uitgerust of hebben applicaties om ze te beheren. Daarnaast is toegang via SSH veilig – alle data transporten zijn versleuteld en geauthenticeerd. En als laatste is SSH efficiënt, net zoals het Git en lokale protocol, de gegevens worden zo compact mogelijk gemaakt voordat het getransporteerd wordt.
 
 #### De nadelen ####
 
-Het negatieve aspect van SSH is dat je er geen anonieme toegang over kunt geven. Mensen moeten via SSH toegang hebben om er gebruik van te kunnen maken, zelfs als het alleen lezen is, zodat SSH toegang niet bevordelijk is voor open source projecten. Als je het alleen binnen je bedrijfsnetwerk gebruikt, dan is SSH misschien het enige protocol waar je mee in aanraking komt. Als je anonieme alleen-lezen toegang wilt toestaan tot je projecten, dan moet je SSH voor jezelf instellen om over te pushen, maar iets anders voor anderen om over te pullen.
+Het negatieve aspect van SSH is dat je er geen anonieme toegang naar je repository over kunt geven. Mensen moeten via SSH toegang hebben om er gebruik van te kunnen maken, zelfs als het alleen lezen is, zodat SSH toegang niet bevordelijk is voor open source projecten. Als je het alleen binnen je bedrijfsnetwerk gebruikt, dan is SSH misschien het enige protocol waar je mee in aanraking komt. Als je anonieme alleen-lezen toegang wilt toestaan tot je projecten, dan moet je SSH voor jezelf instellen om over te pushen, maar iets anders voor anderen om over te pullen.
 
 ### Het Git protocol ###
 
-Het volgende is het Git protocol. Dit is een aparte daemon, die met Git meegeleverd wordt; het luistert op een toegewezen poort (9418), en verleent een vergelijkbare dienst als het SSH protocol, maar dan zonder enige authenticatie. Om een repository beschikbaar te stellen over het Git protocol, moet je het `git-export-daemon-ok` bestand aanmaken – de daemon zal een repository zonder dit bestand erin niet verspreiden – maar buiten dat is er geen beveiliging. Oftewel: de Git repository is er om gecloned te kunnen worden door iedereen, of het is er helemaal niet. Dit betekent dat er over het algemeen geen pushing is via dit protocol. Je kunt push toegang aanzetten, maar gegeven het gebrek aan authenticatie kan, als je de push toegang aan zet, iedereen die de URL van jouw project op het internet vindt, pushen naar jouw project. We volstaan met te zeggen dat dit zeldzaam is.
+Het volgende is het Git protocol. Dit is een specifieke daemon, die met Git meegeleverd wordt; het luistert op een toegewezen poort (9418), en verleent een vergelijkbare dienst als het SSH protocol, maar dan zonder enige vorm van authenticatie. Om een repository beschikbaar te stellen over het Git protocol, moet je een `git-export-daemon-ok` bestand aanmaken – de daemon zal een repository zonder dit bestand erin niet verspreiden – maar daarbuiten is er geen beveiliging. De Git repository beschikbaar om gecloned te kunnen worden door iedereen, of het is het niet. Dit betekent dat er over het algemeen geen pushing is via dit protocol. Je kunt push toegang aanzetten, maar gegeven het gebrek aan authenticatie kan als je de push toegang aan zet iedereen die de URL van jouw project op het internet vindt, pushen naar jouw project. We volstaan met te zeggen dat dit zelden de bedoeling kan zijn.
 
 #### De voordelen ####
 
@@ -79,7 +79,7 @@ Het Git protocol is het snelste dat beschikbaar is. Als je veel verkeer verwerkt
 #### De nadelen ####
 
 Het nadeel van het Git protocol is het gebrek aan authenticatie. Het is over het algemeen onwenselijk dat het Git protocol de enige toegang tot je project is. Meestal zul je het samen met SSH toegang gebruiken voor de paar ontwikkelaars die push (schrijf-)toegang hebben en de rest laat je `git://` voor alleen leestoegang gebruiken.
-Het is waarschijnlijk ook het meest ingewikkelde protocol om in te stellen. Het moet een eigen daemon hebben, die speciaal voor die situatie ingericht is – we zullen er een instellen in het "Gitosis" gedeelte van dit hoofdstuk – het gebruikt `xinetd` configuratie of iets dergelijks, wat ook niet altijd eenvoudig is op te zetten. Het heeft ook firewall toegang tot poort 9418 nodig, wat geen standaard poort is dat in bedrijfsfirewalls is opengezet. Bij firewalls van grote bedrijven, is deze obscure poort meestal geblokkeerd.
+Het is waarschijnlijk ook het meest ingewikkelde protocol om in te richten. Het moet een eigen daemon hebben, die speciaal voor die situatie ingericht is – we zullen er een instellen in het "Gitosis" gedeelte van dit hoofdstuk – het gebruikt `xinetd` configuratie of iets vergelijkbaars, wat ook niet altijd eenvoudig is op te zetten. Daarbij is ook firewall toegang tot poort 9418 nodig, wat geen standaard poort is dat in bedrijfsfirewalls is opengezet. Bij firewalls van grote bedrijven, is deze ongebruikelijke poort meestal dichtgezet.
 
 ### Het HTTP/S protocol ###
 
@@ -91,30 +91,30 @@ Als laatste hebben we het HTTP protocol. Het mooie aan het HTTP of HTTPS protoco
 	$ mv hooks/post-update.sample hooks/post-update
 	$ chmod a+x hooks/post-update
 
-Dat is alles. De `post-update` hook, die standaard bij Git zit, voert het noodzakelijke commando uit (`git update-server-info`) om HTTP fetchen en klonen goed werkend te krijgen. Dit commando wordt uitgevoerd als je naar dit repository via SSH pusht; en dan kunnen andere mensen klonen met behulp van zoiets als
+Dat is alles. De `post-update` hook, die standaard bij Git geleverd wordt, voert het noodzakelijke commando uit (`git update-server-info`) om HTTP fetching en cloning goed werkend te krijgen en houden. Dit commando wordt uitgevoerd als je via SSH naar deze repository pushed; en andere mensen kunnen clonen met behulp van zoiets als
 
 	$ git clone http://example.com/gitproject.git
 
-In dit specifieke geval gebruiken we het `/var/www/htdocs` pad wat gebruikelijk is voor Apache opstellingen, maar je kunt iedere statische webserver gebruiken – stop de kale repository in haar pad. De Git data wordt geserveerd als standaard statische bestanden (zie hoofdstuk 9 voor details over hoe het precies geserveerd wordt).
+In dit specifieke voorbeeld gebruiken we het `/var/www/htdocs` pad wat gebruikelijk is voor Apache opstellingen, maar je kunt iedere statische webserver gebruiken – stop de kale repository in het betreffende pad. De Git data wordt geserveerd als standaard statische bestanden (zie hoofdstuk 9 voor details over hoe het precies geserveerd wordt).
 
-Het ook is mogelijk om Git over HTTP te laten pushen, alhoewel dat geen veelgebruikte techniek is en het vraagt dat je complexe WebDAV instellingen opzet. Omdat het zelden gebruikt wordt, zullen we het niet in dit boek beschrijven. Als je geïnteresseerd bent om de HTTP-push protocollen te gebruiken, dan kun je op `http://www.kernel.org/pub/software/scm/git/docs/howto/setup-git-server-over-http.txt` lezen hoe je een repository kunt maken. Een fijn ding aan Git laten pushen over HTTP is dat je iedere WebDAV server kunt gebruiken, zonder specifieke Git funtionaliteit; dus je kunt deze functionaliteit gebruiken als je web-hosting provider WebDAV ondersteunt voor het maken van wijzigingen aan je webpagina.
+Het is mogelijk om Git ook over HTTP te laten pushen, alhoewel dat geen veelgebruikte techniek is en het vraagt dat je complexe WebDAV instellingen inricht. Omdat het zelden gebruikt wordt, zullen we het niet in dit boek beschrijven. Als je geïnteresseerd bent om de HTTP-push protocollen te gebruiken, dan kun je op `http://www.kernel.org/pub/software/scm/git/docs/howto/setup-git-server-over-http.txt` lezen hoe je een repository kunt maken. Het aardige van Git laten pushen over HTTP is dat je iedere WebDAV server kunt gebruiken, zonder specifieke Git funtionaliteit, dus je kunt deze functionaliteit gebruiken als je web-hosting provider WebDAV ondersteunt voor het maken van wijzigingen aan je webpagina.
 
 #### De voordelen ####
 
-Het voordeel van het gebruik van het HTTP protocol is dat het eenvoudig in te stellen is. Een handvol benodigde commando's uitvoeren zorgt voor een eenvoudige manier om de wereld leestoegang te geven tot je Git repository. Het kost slechts een paar minuten om te doen. Het HTTP protocol is niet erg belastend voor de systeembronnen van je server. Omdat het over het algemeen een statische webserver gebruikt om alle data te verspreiden - een normale Apache server kan gemiddeld duizenden bestanden zenden per seconde - is het moeilijk om zelfs een kleine server te overbelasten.
+Het voordeel van het gebruik van het HTTP protocol is dat het eenvoudig in te stellen is. Een handvol benodigde commando's uitvoeren is alles wat er moet gebeuren om de wereld leestoegang te geven tot je Git repository. Het neemt maar een paar minuten van je tijd. Het HTTP protocol is niet erg belastend voor de systeembronnen van je server. Omdat het over het algemeen een statische webserver gebruikt om alle data te verspreiden - een normale Apache server kan gemiddeld duizenden bestanden zenden per seconde - is het moeilijk om zelfs een kleine server te overbelasten.
 
-Je kunt ook je repositories alleen-lezen serveren via HTTPS, wat inhoudt dat je het transport kunt versleutelen; je kunt zelfs zover gaan dat je clients een specifiek gesigneerd SSL certificaat laat gebruiken. Normaal gesproken als je je deze moeite wilt getroosten, dan is het makkelijker om publieke SSH sleutels te gebruiken; maar het kan een betere oplossing in jouw specifieke geval zijn om gesigneerde SSL certificaten of andere HTTP-gebaseerde authenticatie methoden te gebruiken voor alleen-lezen toegang via HTTPS.
+Je kunt ook je repositories alleen-lezen serveren via HTTPS, wat inhoudt dat je het transport kunt versleutelen; je kunt zelfs zover gaan dat je clients een specifiek gesigneerd SSL certificaat laat gebruiken. Normaal gesproken als je je deze moeite wilt getroosten, dan is het makkelijker om publieke SSH sleutels te gebruiken; maar het kan in jouw specifieke geval een betere oplossing zijn om gesigneerde SSL certificaten of andere HTTP-gebaseerde authenticatie methoden te gebruiken voor alleen-lezen toegang via HTTPS.
 
 Een andere prettige bijkomstigheid is dat HTTP een dusdanig veel voorkomend protocol is dat bedrijfsfirewalls vaak zo ingesteld zijn dat ze verkeer via deze poort toestaan.
 
 #### De nadelen ####
 
-Het nadeel van je repository verspreiden via HTTP is dat het relatief inefficiënt voor de client is. Over het algemeen duurt het een stuk langer om te clonen en te fetchen van de repository, en je hebt vaak een veel hogere netwerk belasting en transport volume via HTTP dan met elk van de andere netwerk protocollen. Omdat het niet zo ingewikkeld is om alleen de data te versturen die je nodig hebt – er wordt geen dynamisch werk door de server gedaan in deze transacties – wordt vaak naar het HTTP protocol gerefereerd als zijnde een _dom_ protocol. Voor meer informatie over de verschillen in efficiëntie tussen het HTTP protocol en andere protocollen, zie Hoofdstuk 9.
+Het nadeel van je repository verspreiden via HTTP is dat het relatief inefficiënt voor de client is. Over het algemeen duurt het een stuk langer om te clonen en te fetchen van de repository, en je hebt vaak een veel hogere netwerk belasting en transport volume via HTTP dan met elk van de andere netwerk protocollen. Omdat het niet zo ingewikkeld is om alleen de data te versturen die je nodig hebt – er wordt geen dynamisch werk door de server gedaan in deze uitwisselingen – wordt vaak naar het HTTP protocol gerefereerd als zijnde een _dom_ protocol. Voor meer informatie over de verschillen in efficiëntie tussen het HTTP protocol en andere protocollen, zie Hoofdstuk 9.
 
 ## Git op een server krijgen ##
 
-Om een initiële Git server op te zetten, moet je een bestaande repository naar een kale repository exporteren – een repository dat geen werkmap bevat. Dit is over het algemeen eenvoudig te doen.
-Om je repository te clonen met als doel het maken van een kale repository, voer je het clone commando uit met de `--bare` optie. Als vaste gewoonte eindigen de namen van kale repository mappen in `.git`, zoals:
+Om een Git server initieel op te zetten, moet je een bestaande repository naar een kale repository exporteren – een repository dat geen werkmap bevat. Dit is over het algemeen eenvoudig te doen.
+Om je repository te clonen met als doel het maken van een kale repository, voer je het clone commando uit met de `--bare` optie. Als conventie eindigen de namen van kale repository mappen met `.git`, zoals:
 
 	$ git clone --bare my_project my_project.git
 	Initialized empty Git repository in /opt/projects/my_project.git/
@@ -127,13 +127,13 @@ Dit is ongeveer gelijk aan
 
 Er zijn een paar kleine verschillen in het configuratie bestand, maar het komt op hetzelfde neer. Het neemt de Git repository zelf, zonder een werkmap, en maakt een map aan specifiek hiervoor.
 
-### Het bare repository op een server zetten ###
+### De Kale Repository op een Server Zetten ###
 
-Nu je een kale kopie van je repository hebt, is het enige dat je moet doen het op een server zetten en je protocollen instellen. Stel dat je een server ingesteld hebt, die `git.example.com` heet, waar je SSH toegang op hebt, en waar je al je Git repositories wilt opslaan onder de `/opt/git` map. Je kunt je nieuwe repository beschikbaar stellen door je kale repository ernaartoe te kopieeren:
+Nu je een kale kopie van je repository hebt, is het enige dat je moet doen het op een server zetten en je protocollen instellen. Laten we aannemen dat je een server ingericht hebt, die `git.example.com` heet, waar je SSH toegang op hebt, en waar je al je Git repositories wilt opslaan onder de `/opt/git` map. Je kunt je nieuwe repository beschikbaar stellen door je kale repository ernaartoe te kopiëren:
 
 	$ scp -r my_project.git user@git.example.com:/opt/git
 
-Op dit punt kunnen andere gebruikers, die SSH toegang hebben tot dezelfde server en lees-toegang hebben tot de `/opt/git` map, jouw repository klonen door dit uit te voeren:
+Vanaf dat moment kunnen andere gebruikers, die SSH toegang hebben tot dezelfde server en lees-toegang hebben tot de `/opt/git` map, jouw repository clonen door dit uit te voeren:
 
 	$ git clone user@git.example.com:/opt/git/my_project.git
 
@@ -143,11 +143,11 @@ Als een gebruiker met SSH op een server inlogt en schrijftoegang heeft tot de `/
 	$ cd /opt/git/my_project.git
 	$ git init --bare --shared
 
-Je ziet hoe eenvoudig het is om een Git repository te nemen, een kale versie aan te maken, en het op een server plaatsen waar jij en je medewerkers SSH toegang tot hebben. Nu ben je klaar om aan hetzelfde project samen te werken.
+Je ziet hoe eenvoudig het is om een Git repository te nemen, een kale versie aan te maken, en het op een server plaatsen waar jij en je medewerkers SSH toegang tot hebben. Nu zijn jullie klaar om aan hetzelfde project samen te werken.
 
-Het is belangrijk om op te merken dat dit letterlijk alles is wat je moet doen om een bruikbare Git server te draaien waarop meerdere mensen toegang hebben – voeg alleen een paar SSH accounts toe op een server, en stop een kale repository ergens waar al die gebruikers lees- en schrijftoegang toe hebben. Je bent er klaar voor – je hebt niets anders nodig.
+Het is belangrijk om op te merken dat dit letterlijk alles is wat je moet doen om een bruikbare Git server te draaien waarop meerdere mensen toegang hebben – maak alleen een paar accounts met SSH toegang aan op een server, en stop een kale repository ergens waar al die gebruikers lees- en schrijftoegang toe hebben. Je bent er klaar voor – je hebt niets anders nodig.
 
-In de volgende paragrafen zul je zien hoe je meer ingewikkelde opstellingen kunt maken. Deze bespreking zal het niet hoeven aanmaken van gebruikers accounts voor elke gebruiker, publieke leestoegang tot repositories, grafische web interfaces, de Gitosis applicatie gebruiken en meer omvatten. Maar, hou in gedachten dat om samen te kunnen werken met mensen op een privé project, alles wat je _nodig_ hebt is een SSH server en een kale repository.
+In de volgende paragrafen zul je zien hoe je meer ingewikkelde opstellingen kunt maken. Deze bespreking zal het niet hoeven aanmaken van gebruikers accounts voor elke gebruiker, publieke leestoegang tot repositories, grafische web interfaces, het gebruik van de Gitosis applicatie en meer omvatten. Maar, hou in gedachten dat om samen te kunnen werken met mensen op een privé project, alles wat je _nodig_ hebt een SSH server is en een kale repository.
 
 ### Kleine opstellingen ###
 
@@ -155,27 +155,26 @@ Als je met een kleine groep bent of net begint met Git in je organisatie en slec
 
 #### SSH toegang ####
 
-Als je reeds een server hebt waar al je ontwikkelaars SSH toegang op hebben, dan is het over het algemeen het eenvoudigste om je eerste repository daar in te stellen, omdat je dan bijna niets hoeft te doen (zoals beschreven in de vorige paragraaf). Als je meer complexe toegangscontrole wilt op je repositories, dan kun je ze instellen met de normale bestandssysteem permissies van het operating systeem dat op je server draait.
+Als je al een server hebt waar al je ontwikkelaars SSH toegang op hebben, dan is het over het algemeen het eenvoudigste om je eerste repository daar op te zetten, omdat je dan bijna niets hoeft te doen (zoals beschreven in de vorige paragraaf). Als je meer complexe toegangscontrole wilt op je repositories, dan kun je ze instellen met de normale bestandssysteem permissies van het operating systeem dat op je server draait.
 
-Als je je repositories op een server wilt zetten, die geen accounts heeft voor iedereen in je team die je schrijftoegang wilt geven, dan moet je SSH toegang voor ze instellen. We gaan er vanuit dat je een server hebt waarmee je dit kunt doen, dat je reeds een SSH server geïnstalleerd hebt, en dat de manier is waarop je toegang hebt tot de server.
+Als je je repositories op een server wilt zetten, die geen accounts heeft voor iedereen in je team die je schrijftoegang wilt geven, dan moet je SSH toegang voor ze opzetten. We gaan er vanuit dat je een server hebt waarmee je dit kunt doen, dat je reeds een SSH server geïnstalleerd hebt, en dat de manier is waarop je toegang hebt tot de server.
 
 Er zijn een paar manieren waarop je iedereen in je team toegang kunt geven. De eerste is voor iedereen accounts aanmaken, wat rechttoe rechtaan is maar bewerkelijk kan zijn. Je wilt vermoedelijk niet `adduser` uitvoeren en tijdelijke wachtwoorden instellen voor iedere gebruiker.
 
-Een tweede methode is een 'git' gebruiker aan te maken op de machine, aan iedere gebruiker die schijftoegang moet hebben vragen of ze je een publieke SSH sleutel sturen, en die sleutel toevoegen aan het `~/.ssh/authorized_keys` bestand van je nieuwe 'git' gebruiker. Vanaf dat moment zal iedereen toegang hebben op die machine via de 'git' gebruiker. Dit tast de commit data op geen enkele manier aan – de SSH gebruiker waarmee je inlogt zal de commits die je opgeslagen hebt niet beïnvloeden.
+Een tweede methode is een generieke 'git' gebruiker aan te maken op de machine, aan iedere gebruiker die schijftoegang moet hebben vragen of ze je een publieke SSH sleutel sturen, en die sleutel toevoegen aan het `~/.ssh/authorized_keys` bestand van die nieuwe 'git' gebruiker. Vanaf dat moment zal iedereen toegang hebben op die machine via de 'git' gebruiker. Dit tast de commit data op geen enkele manier aan – de SSH gebruiker waarmee je inlogt zal de commits die je opgeslagen hebt niet beïnvloeden.
 
-Een andere manier waarop je het kunt doen is je SSH server laten authenticeren middels een LDAP server of een andere gecentraliseerde authenticatie bron, die je misschien al ingesteld hebt. Zolang iedere gebruiker shell toegang kan krijgen op de machine, zou ieder SSH authenticatie mechanisme dat je kunt bedenken moeten werken.
+Een andere manier waarop je het kunt doen is je SSH server laten authenticeren middels een LDAP server of een andere gecentraliseerde authenticatie bron, die misschien al ingericht is. Zolang iedere gebruiker shell toegang kan krijgen op de machine, zou ieder SSH authenticatie mechanisme dat je kunt bedenken moeten werken.
 
 ## Je publieke SSH sleutel genereren ##
 
-Dat gezegd hebbende, zijn er vele Git servers die authenticeren met een publieke SSH sleutel. Om een publieke sleutel te hebben, zal iedere gebruiker in je systeem er een moeten genereren als ze er nog geen hebben. Dit proces is bij alle operating systemen vergelijkbaar.
-Als eerste moet je controleren dat je er niet al een hebt. Standaard staan de SSH sleutels van de gebruikers in hun eigen `~/.ssh` map. Je kunt makkelijk nagaan of je al een sleutel hebt door naar die map te gaan en de inhoud te bekijken:
+Dat gezegd hebbende, zijn er vele Git servers die authenticeren met een publieke SSH sleutel. Om een publieke sleutel te hebben, zal iedere gebruiker in je systeem er een moeten genereren als ze er nog geen hebben. Dit proces is bij alle operating systemen vergelijkbaar. Als eerste moet je controleren of je er niet al een hebt. Standaard staan de SSH sleutels van de gebruikers in hun eigen `~/.ssh` map. Je kunt makkelijk nagaan of je al een sleutel hebt door naar die map te gaan en de inhoud te bekijken:
 
 	$ cd ~/.ssh
 	$ ls
 	authorized_keys2  id_dsa       known_hosts
 	config            id_dsa.pub
 
-Je bent op zoek naar een aantal bestanden genaamd iets en iets.pub, waarbij het `iets` meestal zoiets is als `id_dsa` of `id_rsa`. Het `.pub` bestand is je publieke sleutel en het andere bestand is je private sleutel. Als je deze bestanden niet hebt (of als je zelfs geen `.ssh` map hebt), dan kun je ze aanmaken door een applicatie genaamd `ssh-keygen` uit te voeren, wat meegeleverd wordt met het SSH pakket op Linux/Mac systemen en meegeleverd wordt met het MSysGit pakket op Windows:
+Je bent op zoek naar een aantal bestanden genaamd iets en iets.pub, waarbij het `iets` meestal zoiets is als `id_dsa` of `id_rsa`. Het `.pub` bestand is je publieke sleutel en het andere bestand is je private sleutel. Als je deze bestanden niet hebt (of als je zelfs geen `.ssh` map hebt), dan kun je ze aanmaken door een applicatie genaamd `ssh-keygen` uit te voeren, deze wordt met het SSH pakket op Linux/Mac systemen meegeleverd en met het MSysGit pakket op Windows:
 
 	$ ssh-keygen
 	Generating public/private rsa key pair.
@@ -187,7 +186,7 @@ Je bent op zoek naar een aantal bestanden genaamd iets en iets.pub, waarbij het
 	The key fingerprint is:
 	43:c5:5b:5f:b1:f1:50:43:ad:20:a6:92:6a:1f:9a:3a schacon@agadorlaptop.local
 
-Eerst bevestigt het de lokatie waar je de sleutel wilt opslaan (`.ssh/id_rsa`), en vervolgens vraagt het tweemaal om een wachtwoord, die je leeg kunt laten als je geen wachtwoord wilt intypen op het moment dat je de sleutel gebruikt.
+Eerst wordt de lokatie waar je de sleutel wordt opgeslagen (`.ssh/id_rsa`) aangegeven, en vervolgens vraagt het tweemaal om een wachtwoord, die je leeg kunt laten als je geen wachtwoord wilt intypen op het moment dat je de sleutel gebruikt.
 
 Iedere gebruiker die dit doet, moet zijn sleutel sturen naar jou of degene die de Git server beheert (aangenomen dat je een SSH server gebruikt die publieke sleutels vereist). Het enige dat ze hoeven doen is de inhoud van het `.pub` bestand kopiëren en e-mailen. De publieke sleutel ziet er ongeveer zo uit:
 
@@ -199,18 +198,18 @@ Iedere gebruiker die dit doet, moet zijn sleutel sturen naar jou of degene die d
 	mZ+AW4OZPnTPI89ZPmVMLuayrD2cE86Z/il8b+gw3r3+1nKatmIkjn2so1d01QraTlMqVSsbx
 	NrRFi9wrf+M7Q== schacon@agadorlaptop.local
 
-Voor een uitgebreide tutorial over het aanmaken van een SSH sleutel op meerdere besturingssystemen, zie de GitHub handleiding over SSH sleutels op `http://github.com/guides/providing-your-ssh-key`.
+Voor een uitgebreide tutorial over het aanmaken van een SSH sleutel op meerdere operating systemen, verwijzen ze je naar de GitHub handleiding over SSH sleutels op `http://github.com/guides/providing-your-ssh-key`.
 
-## De server instellen ##
+## De Server Opzetten ##
 
-Laten we het instellen van SSH toegang aan de server kant eens doorlopen. In dit voorbeeld zul je de `authorized_keys` methode gebruiken om je gebruikers te authenticeren. We gaan er ook vanuit dat je een standaard Linux distributie gebruikt zoals Ubuntu. Als eerste maak je een 'git' gebruiker aan en een `.ssh` map voor die gebruiker.
+Laten we het opzetten van SSH toegang aan de server kant eens doorlopen. In dit voorbeeld zul je de `authorized_keys` methode gebruiken om je gebruikers te authenticeren. We gaan er ook vanuit dat je een standaard Linux distributie gebruikt zoals Ubuntu. Als eerste maak je een 'git' gebruiker aan en een `.ssh` map voor die gebruiker.
 
 	$ sudo adduser git
 	$ su git
 	$ cd
 	$ mkdir .ssh
 
-Daarna moet je een aantal publieke SSH sleutels van ontwikkelaars aan het `authorized_keys` bestand toevoegen voor die gebruiker. Laten we aannemen dat je een aantal sleutels per e-mail ontvangen hebt en ze hebt opgeslagen in tijdelijke bestanden. Nogmaals, de sleutels zien er ongeveer zo uit:
+Vervolgens moet je een aantal publieke SSH sleutels van ontwikkelaars aan het `authorized_keys` bestand toevoegen voor die gebruiker. Laten we aannemen dat je een aantal sleutels per e-mail ontvangen hebt en ze hebt opgeslagen in tijdelijke bestanden. Nogmaals, de sleutels zien er ongeveer zo uit:
 
 	$ cat /tmp/id_rsa.john.pub
 	ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCB007n/ww+ouN4gSLKssMxXnBOvf9LGt4L
@@ -233,7 +232,7 @@ Nu kun je een lege repository voor ze instellen door `git init` uit te voeren me
 	$ cd project.git
 	$ git --bare init
 
-Daarna kunnen John, Josie of Jessica de eerste versie van hun project in de repository pushen door het als een remote toe te voegen en naar een branch te pushen. Let op dat iemand met een shell op de machine zal moeten inloggen en een kale repository moet creëren, iedere keer als je een project wilt toevoegen. Laten we `gitserver` als hostnaam gebruiken voor de server waar je de 'git' gebruiker en repository hebt ingesteld. Als je het binnenshuis draait, en je de DNS instelt zodat `gitserver` naar die server wijst, dan kun je de commando's vrijwel ongewijzigd gebruiken:
+Daarna kunnen John, Josie of Jessica de eerste versie van hun project in de repository pushen door het als een remote toe te voegen en een branch te pushen. Merk op dat iemand met een shell op de machine zal moeten inloggen en een kale repository moet creëren voor elke keer dat je een project wilt toevoegen. Laten we `gitserver` als hostnaam gebruiken voor de server waar je de 'git' gebruiker en repository hebt aangemaakt. Als je het binnenshuis draait, en je de DNS instelt zodat `gitserver` naar die server wijst, dan kun je de commando's vrijwel ongewijzigd gebruiken:
 
 	# op Johns computer
 	$ cd myproject
@@ -250,7 +249,7 @@ Vanaf dat moment kunnen de anderen het clonen en wijzigingen even gemakkelijk te
 	$ git commit -am 'fix for the README file'
 	$ git push origin master
 
-Met deze methode kun je snel een lees/schrijf Git server draaiend krijgen voor een handjevol ontwikkelaars.
+Op deze manier kun je snel een lees/schrijf Git server draaiend krijgen voor een handjevol ontwikkelaars.
 
 Als een extra voorzorgsmaatregel kun je de 'git' gebruiker makkelijk beperken tot het doen van alleen Git activiteiten, met een gelimiteerde shell applicatie genaamd `git-shell` die bij Git geleverd wordt.
 Als je dit als login shell voor je 'git' gebruiker instelt, dan kan de 'git' gebruiker geen normale shell toegang hebben op je server. Specificeer `git-shell` in plaats van bash of csh voor je gebruikers login shell om dit te gebruiken. Om dit te doen zul je waarschijnlijk het `/etc/passwd` bestand aan moeten passen:
@@ -273,11 +272,11 @@ Nu kan de 'git' gebruiker de SSH connectie alleen gebruiken om Git repositories
 
 ## Publieke toegang ##
 
-Wat als je anonieme leestoegang op je project wil? Misschien wil je geen intern privé project beheren, maar een open source project. Of misschien heb je een aantal geautomatiseerde bouwservers of continue integratie servers die vaak wijzigen, en wil je niet doorlopend SSH sleutels hoeven genereren – je wil gewoon eenvoudige leestoegang toevoegen.
+Wat als je anonieme leestoegang op je project wil? Misschien wil je geen intern privé project beheren, maar een open source project. Of misschien heb je een aantal geautomatiseerde bouwservers of continue integratie servers die vaak wisselen, en wil je niet doorlopend SSH sleutels hoeven genereren – je wil gewoon eenvoudige anonieme leestoegang toevoegen.
 
-Waarschijnlijk is de eenvoudigste manier voor kleinschalige opstellingen om een statische webserver in te stellen, waarbij de document root naar de plaats van je Git repositories wijst, en dan de `post-update` haak aanzetten waar we het in de eerste paragraaf van dit hoofdstuk over gehad hebben. Laten we eens uitgaan van het voorgaande voorbeeld. Stel dat je je repositories in de `/opt/git` map hebt staan, en er draait een Apache server op je machine. Nogmaals, je kunt hiervoor iedere web server gebruiken: maar als voorbeeld zullen we wat basis Apache configuraties laten zien, die je een idee kunnen geven van wat je nodig hebt.
+Waarschijnlijk is de eenvoudigste manier voor kleinschalige opstellingen om een statische webserver in te stellen, waarbij de document root naar de plaats van je Git repositories wijst, en dan de `post-update` haak aanzetten waar we het in de eerste paragraaf van dit hoofdstuk over gehad hebben. Laten we eens uitgaan van het voorgaande voorbeeld. Stel dat je je repositories in de `/opt/git` map hebt staan, en er draait een Apache server op je machine. Nogmaals, je kunt hiervoor iedere web server gebruiken: maar als voorbeeld zullen we wat simpele Apache configuraties laten zien, die je het idee weergeven van wat je nodig hebt.
 
-Eerst moet je de haak aanzetten:
+Eerst moet je de haak inschakelen:
 
 	$ cd project.git
 	$ mv hooks/post-update.sample hooks/post-update
@@ -285,7 +284,7 @@ Eerst moet je de haak aanzetten:
 
 Als je een lagere versie dan 1.6 van Git gebruikt, dan is het `mv` commando niet nodig — Git is recentelijk pas begonnen met de namen van de haak voorbeelden op .sample te laten eindigen.
 
-Wat doet deze `post-update` haak? Het ziet er ongeveer zo uit:
+Wat doet deze `post-update` haak? Het ziet er eigenlijk als volgt uit:
 
 	$ cat .git/hooks/post-update
 	#!/bin/sh
@@ -293,7 +292,7 @@ Wat doet deze `post-update` haak? Het ziet er ongeveer zo uit:
 
 Dit betekent dat wanneer je naar de server via SSH pusht, Git dit commando uitvoert om de benodigde bestanden voor HTTP fetching te verversen.
 
-Vervolgens moet je een VirtualHost toevoeging in je Apache configuratie aanmaken, met de document root als de hoofdmap van je Git projecten. Hier nemen we aan dat je wildcard DNS ingesteld hebt om `*.gitserver` door te sturen naar waar je dit alles draait:
+Vervolgens moet je een VirtualHost regel in je Apache configuratie aanmaken, met de document root als de hoofdmap van je Git projecten. Hier nemen we aan dat je wildcard DNS ingesteld hebt om `*.gitserver` door te sturen naar waar je dit alles draait:
 
 	<VirtualHost *:80>
 	    ServerName git.gitserver
@@ -304,7 +303,7 @@ Vervolgens moet je een VirtualHost toevoeging in je Apache configuratie aanmaken
 	    </Directory>
 	</VirtualHost>
 
-Je zult ook de Unix gebruikers groep van de `/opt/git` mappen moeten instellen op `www-data` zodat je web server leestoegang hebt op de repositories, omdat de Apache instantie die het CGI script uitvoert (standaard) als die gebruiker draait:
+Je zult ook de Unix gebruikers groep van de `/opt/git` mappen moeten zetten op `www-data` zodat je web server leestoegang hebt op de repositories, omdat de Apache instantie het CGI script (standaard) uitvoert als die gebruiker draait:
 
 	$ chgrp -R www-data /opt/git
 
@@ -312,26 +311,26 @@ Als je Apache herstart, dan zou je je repositories onder die map moeten kunnen k
 
 	$ git clone http://git.gitserver/project.git
 
-Op deze manier kun je HTTP-gebaseerde toegang voor elk van je projecten voor een groot aantal gebruikers in slechts een paar minuten instellen. Een andere eenvoudige optie om publieke ongeauthenticeerde toegang in te stellen is een Git daemon te starten, alhoewel dat vereist dat je het proces als daemon uitvoert – we beschrijven deze optie in de volgende paragraaf als je een voorkeur hebt voor deze variant.
+Op deze manier kun je HTTP-gebaseerde toegang voor elk van je projecten voor een groot aantal gebruikers in slechts een paar minuten regelen. Een andere eenvoudige optie om publieke ongeauthenticeerde toegang in te stellen is een Git daemon te starten, alhoewel dat vereist dat je het proces als daemon uitvoert – we beschrijven deze optie in de volgende paragraaf als je een voorkeur hebt voor deze variant.
 
 ## GitWeb ##
 
-Nu je basis lees/schrijf en alleen-lezen toegang tot je project hebt, wil je misschien een eenvoudige web-gebaseerde visualisatie instellen. Git levert een CGI script genaamd GitWeb mee, dat veelal voor hiervoor gebruikt wordt. Je kunt GitWeb in gebruik zien bij sites zoals `http://git.kernel.org` (zie Figuur 4-1).
+Nu je gewone lees/schrijf en alleen-lezen toegang tot je project hebt, wil je misschien een eenvoudige web-gebaseerde visualisatie instellen. Git levert een CGI script genaamd GitWeb mee, dat normaalgesproken hiervoor gebruikt wordt. Je kunt GitWeb in actie zien bij sites zoals `http://git.kernel.org` (zie Figuur 4-1).
 
 Insert 18333fig0401.png
 Figuur 4-1. De GitWeb web-gebaseerde gebruikers interface.
 
-Als je wil zien hoe GitWeb er op jouw project uitziet, dan heeft Git een commando waarmee je een tijdelijke instantie op kunt starten als je een lichtgewicht server op je systeem hebt zoals `lighttpd` of `webrick`. Op Linux machines is `lighttpd` vaak geïnstalleerd, dus je kunt het misschien draaiend krijgen door `git instaweb` in te typen in je project map. Als je op een Mac werkt: Leopard heeft Ruby voorgeïnstalleerd, dus `webrick` zou je beste gok kunnen zijn. Om `instaweb` met een server anders dan lighttpd te starten, kun je het uitvoeren met de `--httpd` optie.
+Als je wil zien hoe GitWeb er voor jouw project uitziet, dan heeft Git een commando waarmee je een tijdelijke instantie op kunt starten als je een lichtgewicht server op je systeem hebt zoals `lighttpd` of `webrick`. Op Linux machines is `lighttpd` vaak geïnstalleerd, dus je kunt het misschien draaiend krijgen door `git instaweb` in te typen in je project map. Als je op een Mac werkt: Leopard heeft Ruby voorgeïnstalleerd, dus `webrick` zou je de meeste kans geven. Om `instaweb` met een server anders dan lighttpd te starten, moet je het uitvoeren met de `--httpd` optie.
 
 	$ git instaweb --httpd=webrick
 	[2009-02-21 10:02:21] INFO  WEBrick 1.3.1
 	[2009-02-21 10:02:21] INFO  ruby 1.8.6 (2008-03-03) [universal-darwin9.0]
 
-Dat start een HTTPD server op poort 1234 op en start automatisch een web browser op die met die pagina opent. Het is dus makkelijk voor je. Als je klaar bent en de server wilt afsluiten, dan kun je hetzelfde commando uitvoeren met de `--stop` optie:
+Dat start een HTTPD server op poort 1234 op en start automatisch een web browser die op die pagina opent. Het is dus makkelijk voor je. Als je klaar bent en de server wilt afsluiten, dan kun je hetzelfde commando uitvoeren met de `--stop` optie:
 
 	$ git instaweb --httpd=webrick --stop
 
-Als je de web interface doorlopend op een server wilt draaien voor je team of voor een open source project dat je verspreid, dan moet je het CGI script instellen zodat het door je normale web server geserveerd wordt. Sommige Linux distributies hebben een `gitweb` pakket dat je misschien kunt installeren via `apt` of `yum`, dus misschien kan je dat eerst proberen. We zullen snel door een handmatige GitWeb installatie heenlopen. Eerst moet je de Git broncode pakken waar GitWeb bij zit, en het aangepaste CGI script genereren: 
+Als je de web interface doorlopend op een server wilt draaien voor je team of voor een open source project dat je verspreid, dan moet je het CGI script instellen zodat het door je normale web server geserveerd wordt. Sommige Linux distributies hebben een `gitweb` pakket dat je zou kunnen installeren via `apt` of `yum`, dus wellicht kan je dat eerst proberen. We zullen snel door een handmatige GitWeb installatie heen lopen. Eerst moet je de Git broncode pakken waar GitWeb bij zit, en het aangepaste CGI script genereren: 
 
 	$ git clone git://git.kernel.org/pub/scm/git/git.git
 	$ cd git/
@@ -354,18 +353,17 @@ Merk op dat je het commando moet vertellen waar het je Git repositories kan vind
 	    </Directory>
 	</VirtualHost>
 
-Nogmaals, GitWeb kan geserveerd worden met iedere web server die in staat is CGI te verwerken; als je iets anders prefereert zou het niet moeilijk in te stellen moeten zijn. Op dit punt zou je in staat moeten zijn om `http://gitserver/` te bezoeken en je repositories online te zien, en kun je `http://git.gitserver` gebruiken om je repositories over HTTP te clonen en te fetchen.
+Nogmaals, GitWeb kan geserveerd worden met iedere web server die in staat is CGI te verwerken. Als je iets anders prefereert zou het niet moeilijk moeten zijn dit in te stellen. Vanaf dit moment zou je in staat moeten zijn om `http://gitserver/` te bezoeken en je repositories online te zien, en kun je `http://git.gitserver` gebruiken om je repositories over HTTP te clonen en te fetchen.
 
 ## Gitosis ##
 
-De publieke sleutels van alle gebruikers in een `authorized_keys` bestand bewaren voor toegang werkt slechts korte tijd goed. Als je honderden gebruikers hebt, dan is het bewerkelijk om dat proces te volgen. Je moet iedere keer in de server inloggen, en er is geen toegangscontrole – iedereen in het bestand heeft lees- en schrijftoegang op ieder project.
+De publieke sleutels van alle gebruikers in een `authorized_keys` bestand bewaren voor toegang werkt slechts korte tijd goed. Als je honderden gebruikers hebt, dan is het te bewerkelijk om dat proces te blijven volgen. Je moet iedere keer in de server inloggen, en er is geen toegangscontrole – iedereen in het bestand heeft lees- en schrijftoegang op ieder project.
 
-Op dit punt wil je je misschien wenden tot een veelgebruikt software project genaamd Gitosis. Gitosis is in feite een verzameling scripts die je helpen het `authorized_keys` bestand te beheren alsmede eenvoudig toegangscontrole te implementeren. Het meest interessante gedeelte is dat de gebruikers interface voor deze applicatie om mensen toe te voegen en toegang te bepalen, geen web interface is maar een speciale Git repository. Je beheert de informatie in dat project; en als je het pushed, dan herconfigureert Gitosis de server op basis van dat project, wat best wel stoer is.
+Op dat moment zou je kunnen overwegen een veelgebruikt software project genaamd Gitosis te gaan gebruiken. Gitosis is in feite een verzameling scripts die je helpen het `authorized_keys` bestand te beheren alsmede eenvoudig toegangscontrole te implementeren. Het interessante hieraan is dat de gebruikers interface voor deze applicatie om mensen toe te voegen en toegang te bepalen, geen web interface is maar een speciale Git repository. Je beheert de informatie in dat project en als je het pushed, dan herconfigureert Gitosis de server op basis van dat project, wat best wel slim bedacht is.
 
-Gitosis installeren is niet de makkelijkste taak ooit, maar het is ook niet te moeilijk. Het is het makkelijkste om er een Linux server voor te gebruiken – deze voorbeelden gebruiken een standaard Ubuntu 8.10 server.
->>>>>>> [nl] Language and wording corrections. Introducing characters from ASCII
+Gitosis installeren is niet de makkelijkste taak ooit, maar het is ook niet al te moeilijk. Het is het makkelijkste om er een Linux server voor te gebruiken – deze voorbeelden gebruiken een standaard Ubuntu 8.10 server.
 
-Gitosis vereist enkele Python applicaties, dus moet je eerst het Python setuptools pakket installeren, wat Ubuntu beschikbaar stelt als python-setuptools:
+Gitosis vereist enkele Python tools, dus moet je eerst het Python setuptools pakket installeren, wat Ubuntu beschikbaar stelt als python-setuptools:
 
 	$ apt-get install python-setuptools
 
@@ -375,15 +373,15 @@ Vervolgens kloon en installeer je Gitosis van de hoofdpagina van het project:
 	$ cd gitosis
 	$ sudo python setup.py install
 
-Daarmee worden een aantal uitvoerbare bestanden geïnstalleerd, die Gitosis zal gebruiken. Daarna wil Gitosis zijn repositories onder `/home/git` stoppen, wat prima is. Maar je hebt je repositories al in `/opt/git` geconfigureerd, dus in plaats van alles te herconfigureren maken we een symbolische link aan:
+Daarmee worden een aantal bestanden geïnstalleerd, die Gitosis zal gebruiken. Daarna wil Gitosis zijn repositories onder `/home/git` stoppen, wat prima is. Maar je hebt je repositories al in `/opt/git` geconfigureerd, dus in plaats van alles te herconfigureren maken we een symbolische link aan:
 
 	$ ln -s /opt/git /home/git/repositories
 
-Gitosis zal je sleutels voor je beheren, dus je moet het huidige bestand verwijderen, om de sleutels later opnieuw toe te voegen en Gitosis het `authorized_keys` bestand automatisch laten beheren. Voor nu verplaatsen we het `authorized_keys` bestand:
+Gitosis zal de sleutels voor je beheren, dus je moet het huidige bestand verwijderen, om de sleutels later opnieuw toe te voegen en Gitosis het `authorized_keys` bestand automatisch laten beheren. Voor nu verplaatsen we het `authorized_keys` bestand:
 
 	$ mv /home/git/.ssh/authorized_keys /home/git/.ssh/ak.bak
 
-Nu moet je je shell terugzetten voor de 'git' gebruiker, als je het veranderd hebt naar het `git-shell` commando. Mensen zullen nog steeds niet in staat zijn in te loggen, maar Gitosis zal dat voor je beheren. Dus, laten we deze regel veranderen in je `/etc/passwd` bestand
+Nu moet je de shell terugzetten voor de 'git' gebruiker, als je het veranderd hebt naar het `git-shell` commando. Mensen zullen nog steeds niet in staat zijn in te loggen, Gitosis zal dat voor je beheren. Dus, laten we deze regel veranderen in je `/etc/passwd` bestand
 
 	git:x:1000:1000::/home/git:/usr/bin/git-shell
 
@@ -397,11 +395,11 @@ Nu wordt het tijd om Gitosis te initialiseren. Je doet dit door het `gitosis-ini
 	Initialized empty Git repository in /opt/git/gitosis-admin.git/
 	Reinitialized existing Git repository in /opt/git/gitosis-admin.git/
 
-Dit staat de gebruiker met die sleutel toe de hoofd Git repository, die de Gitosis installatie beheert, aan te passen. Daarna zul je met de hand het execute bit op het `post-update` script moeten instellen voor je nieuwe beheer repository.
+Dit staat de gebruiker met die sleutel toe de hoofd Git repository, die de Gitosis setup regelt, aan te passen. Daarna zul je met de hand het execute bit op het `post-update` script moeten aanzetten voor je nieuwe beheer repository.
 
 	$ sudo chmod 755 /opt/git/gitosis-admin.git/hooks/post-update
 
-Je bent nu klaar om te gaan. Als je alles juist hebt ingesteld, kun je nu met SSH in je server loggen als de gebruiker waarvoor je de publieke sleutel hebt toegevoegd om Gitosis te initialiseren. Je zou dan zoiets als dit moeten zien:
+Je bent nu klaar voor de start. Als je alles juist hebt ingesteld, kun je nu met SSH in je server loggen als de gebruiker waarvoor je de publieke sleutel hebt toegevoegd om Gitosis te initialiseren. Je zou dan zoiets als dit moeten zien:
 
 	$ ssh git@gitserver
 	PTY allocation request failed on channel 0
@@ -421,7 +419,7 @@ Nu heb je een map genaamd `gitosis-admin`, die twee hoofd gedeeltes heeft:
 	./keydir
 	./keydir/scott.pub
 
-Het `gitosis.conf` bestand is het beheer bestand, dat je zult gebruiken om gebruikers, repositories en permissies te specificeren. De `keydir` map is de plaats waar je de publieke sleutels opslaat van alle gebruikers die een vorm van toegang tot je repositories hebben — één bestand per gebruiker. De naam van het bestand in `keydir` (in het vorige voorbeeld, `scott.pub`) zal anders voor jou zijn — Gitosis haalt de naam uit de beschrijving aan het einde van de publieke sleutel die was geïmporteerd met het `gitosis-init` script.
+Het `gitosis.conf` bestand is het beheer bestand dat je zult gebruiken om gebruikers, repositories en permissies te specificeren. De `keydir` map is de plaats waar je de publieke sleutels opslaat van alle gebruikers die een vorm van toegang tot de repositories hebben – één bestand per gebruiker. De naam van het bestand in `keydir` (in het vorige voorbeeld, `scott.pub`) zal anders zijn in jouw geval – Gitosis haalt de naam uit de beschrijving aan het einde van de publieke sleutel die was geïmporteerd met het `gitosis-init` script.
 
 Als je naar het `gitosis.conf` bestand kijkt, zou het alleen informatie over het zojuist gekloonde `gitosis-admin` project mogen bevatten:
 
@@ -432,9 +430,9 @@ Als je naar het `gitosis.conf` bestand kijkt, zou het alleen informatie over het
 	writable = gitosis-admin
 	members = scott
 
-Het laat je zien dat de gebruiker 'scott' — de gebruiker met wiens publieke sleutel je Gitosis geïnitialiseerd hebt — de enige is die toegang heeft tot het `gitosis-admin` project.
+Het laat je zien dat de gebruiker 'scott' – de gebruiker met wiens publieke sleutel je Gitosis geïnitialiseerd hebt – de enige is die toegang heeft tot het `gitosis-admin` project.
 
-Laten we een nieuw project voor je toevoegen. Je voegt een nieuwe sectie genaamd `mobile` toe, waar je de ontwikkelaars in je mobile team neerzet, en de projecten waar deze ontwikkelaars toegang tot moeten hebben. Omdat 'scott' op het moment de enige gebruiker in het systeem is, zul je hem als enig lid toevoegen en zul je een nieuw project genaamd `iphone_project` toevoegen om mee te beginnen:
+Laten we nu een nieuw project voor je toevoegen. Je voegt een nieuwe sectie genaamd `mobile` toe, waar je de ontwikkelaars in het mobile team neerzet, en de projecten waar deze ontwikkelaars toegang tot moeten hebben. Omdat 'scott' op het moment de enige gebruiker in het systeem is, zul je hem als enig lid toevoegen en voeg je een nieuw project genaamd `iphone_project` toe om mee te beginnen:
 
 	[group mobile]
 	writable = iphone_project
@@ -466,7 +464,7 @@ Je kunt je eerste push naar het nieuwe `iphone_project` doen door je server als
 
 Merk op dat je geen pad hoeft te specificeren (sterker nog, het wel doen zal niet werken), alleen een dubbele punt en dan de naam van het project — Gitosis zal het voor je vinden.
 
-Je wil samen met je vrienden aan dit project werken, dus je zult hun publieke sleutels weer toe moeten voegen. Maar in plaats van ze handmatig aan het `~/.ssh/authorized_keys` bestand op je server toe te voegen, voeg je ze, één sleutel per bestand, aan de `keydir` map toe. Hoe je de sleutels noemt bepaalt hoe je aan de gebruikers refereert in het `gitosis.conf` bestand. Laten we de publieke sleutels voor John, Josie en Jessica toevoegen:
+Je wil samen met je vrienden aan dit project werken, dus je zult hun publieke sleutels weer toe moeten voegen. Maar in plaats van ze handmatig aan het `~/.ssh/authorized_keys` bestand op je server toe te voegen, voeg je ze één sleutel per bestand, aan de `keydir` map toe. Hoe je de sleutels noemt bepaalt hoe je aan de gebruikers refereert in het `gitosis.conf` bestand. Laten we de publieke sleutels voor John, Josie en Jessica toevoegen:
 
 	$ cp /tmp/id_rsa.john.pub keydir/john.pub
 	$ cp /tmp/id_rsa.josie.pub keydir/josie.pub
@@ -490,7 +488,7 @@ Gitosis heeft ook eenvoudige toegangscontrole. Als je wilt dat John alleen lees
 	readonly = iphone_project
 	members = john
 
-Nu kan John het project klonen en updates krijgen, maar Gitosis zal hem niet toestaan om terug naar het project te pushen. Je kunt zoveel van deze groepen maken als je wilt, waarbij ze allen verschillende gebruikers en projecten mogen bevatten. Je kunt ook een andere groep als een van de leden specificeren (waarbij je `@` als prefix gebruikt), om alle leden automatisch over te erven:
+Nu kan John het project clonen en updates krijgen, maar Gitosis zal hem niet toestaan om terug naar het project te pushen. Je kunt zoveel van deze groepen maken als je wilt, waarbij ze alle verschillende gebruikers en projecten mogen bevatten. Je kunt ook een andere groep als een van de leden specificeren (met @ als voorvoegsel), waarmee de groepsleden automatisch worden overerfd:
 
 	[group mobile_committers]
 	members = scott josie jessica
@@ -503,67 +501,64 @@ Nu kan John het project klonen en updates krijgen, maar Gitosis zal hem niet toe
 	writable  = another_iphone_project
 	members   = @mobile_committers john
 
-Als je problemen hebt, kan het handig zijn om `loglevel=DEBUG` onder de `[gitosis]` sectie te zetten. Als je je push-toegang bent verloren door een kapotte configuratie te pushen, kun je het handmatig repareren in het bestand `/home/git/.gitosis.conf` op de server — het bestand waar Gitosis zijn informatie vandaan haalt. Een push naar het project neemt het `gitosis.conf` bestand dat je zojuist gepusht hebt en stopt het daar. Als je het bestand handmatig aanpast, zal het zo blijven totdat de volgende succesvolle push gedaan wordt naar het `gitosis-admin` project.
+Als je problemen hebt, kan het handig zijn om `loglevel=DEBUG` onder de `[gitosis]` sectie te zetten. Als je je push-toegang bent verloren door een kapotte configuratie te pushen, kun je het handmatig repareren in het bestand `/home/git/.gitosis.conf` op de server – het bestand waar Gitosis zijn informatie vandaan haalt. Een push naar het project neemt het `gitosis.conf` bestand dat je zojuist gepushed hebt en stopt het daar. Als je het bestand handmatig aanpast, zal het zo blijven totdat de volgende succesvolle push gedaan wordt naar het `gitosis-admin` project.
 
 ## Gitolite ##
 
-Let op: de laatste versie van deze sectie van het Progit boek is altijd beschikbaar in [gitolite documentation][gldpg]. De auteur wil ook nederig vaststellen dat, ondanks dat deze sectie accuraat is, en *kan* (en vaak *is*) gebruikt worden om gitolite te installeren zonder verdere documentatie te lezen; het uit noodzaak niet compleet is, en niet de enorme hoeveelheid documentatie die bij gitolite komt kan vervangen.
+Merk op: de laatste versie van deze paragraaf in het ProGit boek is altijd beschikbaar binnen de [gitolite documentation][gldpg]. De auteur geeft ook nederig aan dat, hoewel deze paragraaf accuraat is, het *kan* (en vaak ook *is*) gebruikt om gitolie te installeren zonder enige andere documentatie te lezen, dat het niet gegarandeerd compleet is, en het zeker niet de gehele enorme hoeveelheid documentatie kan vervangen dat meegeleverd wordt met gitolite.
 
 [gldpg]: http://github.com/sitaramc/gitolite/blob/pu/doc/progit-article.mkd
 
-Git is erg populair geworden in bedrijfsomgevingen, die veelal extra eisen hebben in termen van toegangscontrole. Gitolite was oorspronkelijk gemaakt om met die eisen te helpen, maar het blijkt dat het net zo bruikbaar is in de open source wereld: het Fedora project beheert de toegang tot hun pakket beheer repositories (ongeveer 10.000 stuks!) met behulp van gitolite, en dit is waarschijnlijk ook de grootste gitolite installatie.
+Git begint erg populair te worden in het bedrijfsleven, die de neiging hebben nog wat additionele eisen te hebben op het gebied van toegangscontrole. Gitolite was oorspronkelijk gemaakt om bij het vervullen van deze eisen te helpen, maar het blijkt dat het even bruikbaar is in de wereld van de open source: het Fedora Project beheert toegang tot hun package beheer repositories (meer dan 10.000 daarvan!) met gitolite, en het is waarschijnlijk daarbij ook nog eens de grootste gitolite installatie waar dan ook.
 
-Gitolite staat je toe om de toegang niet alleen per repository te specificeren, maar ook per branch of tag binnen elk repository. Dat wil zeggen dat je in kunt stellen dat bepaalde mensen (of groepen van mensen) alleen kunnen pushen naar bepaalde "refs" (branches of tags), maar niet naar andere.
+Gitolite stelt je in staat de permissies niet alleen per repository, maar ook per branch of tag naam binnen elke repository. Dus, je kunt aangeven dat bepaalde mensen (of groepen van mensen) alleen maar bepaalde "refs" (branches of tags) kunnen pushen maar niet andere.
 
-### Installeren ###
+### Installatie ###
 
-Het installeren van Gitolite is erg eenvoudig, zelfs als je niet alle uitgebreide documentatie leest die erbij zit. Je hebt een account om een of andere Unix server nodig; diverse Linux smaken en Solaris 10 zijn getest. Je hebt geen root toegang nodig, aangenomen dat git, perl, en een met openssh verenigbare server reeds geïnstalleerd zijn. In de voorbeelden hieronder zullen we het `gitolite` account gebruiken op een host genaamd `gitserver`.
+Het installeren van Gitolite is zeer eenvoudig, zelfs als je de uitgebreide documentatie, dat erbij geleverd wordt, niet leest. Je hebt een account op een Unix(achtige) server hebben; verschillende Linux smaken en Solaris 10 zijn getest. Je hebt geen root toegang nodig, aangenomen dat git, perl, en een openssh compatible ssh server al zijn geïnstalleerd. In de onderstaand voorbeelden zullen we het `gitolite` account gebruiken op een host genaamd `gitserver`.
 
-Gitolite is wat ongebruikelijk voor wat betreft "server" software -- toegang gaat via ssh, en dus is ieder gebuikers id een potentiële "gitolite host". Bij gevolg zijn er begrippen als het "installeren" van de software, en dan het "instellen" van een gebruiker als een "gitolite host".
+Gitolite is nogal ongebruikelijk in de zin van "server" software -- toegang gaat via ssh, en elke userid op de server is in potentie een "gitolite host". Het resultaat is, dat er een idee is van "installeren" van de software zelf, en dan het "opzetten" van een gebruiker als een "gitolist host".
 
-Gitolite kan op 4 manieren geïnstalleerd worden. Mensen die Fedora of Debian systemen gebruiken, kunnen een RPM of DEB krijgen en dat installeren. Mensen met root toegang kunnen het handmatig installeren. Bij deze twee methoden kan iedere gebruiker op het systeem een "gitolite host" worden.
+Mensen zonder root toegang kunnen het installeren binnen hun eigen user id. Als laatste: gitlite kan geïnstalleerd worden door een script te starten *op het werkstation*, vanuit een bash-shell. (Zelfs de bash die meegeleverd wordt met msysgit volstaat, voor het geval je je dat afvroeg.)
 
-Mensen zonder root toegang kunnen het binnen hun eigen gebruikerid installeren. Tenslotte kan gitolite geïnstalleerd worden door het uitvoeren van een script *op het werkstation*, vanuit een bash shell. (Zelfs de bash shell die bij msysgit zit voldoet, mocht je het je afvragen).
+We zullen dit laatste in dit stuk beschrijven, voor de overige methoden verwijzen we je naar de documentatie.
 
-We zullen deze laatste methode in dit artikel beschrijven; kijk alstublieft in de documentatie voor de andere methoden.
-
-Je begint met het verkrijgen van toegang op je server op basis van een publieke sleutel, zodat je in kunt loggen vanaf je werkstation zonder een wachtwoord prompt te krijgen. De volgende methode werkt op Linux; voor andere werkstation OSsen zul je dit misschien handmatig moeten doen. We gaan er vanuit dat je reeds een sleutelpaar gegeneerd hebt met behulp van `ssh-keygen`.
+Je begint met het verkrijgen van toegang op basis van een publieke sleutel, zodat je vanaf je werkstation op de server kan inloggen zonder het intypen van je wachtwoord. De volgende methode werkt op Linux; voor andere werkstation besturingssystemen moet je dit wellicht handmatig doen. We gaan er vanuit dat je al een sleutelpaar hebt gegenereerd met `ssh-keygen`.
 
 	$ ssh-copy-id -i ~/.ssh/id_rsa gitolite@gitserver
 
-Dit zal je vragen naar het wachtwoord van het gitolite account, en dan toegang met een publieke sleutel instellen. Dit is **essentieel** voor het installatiescript, dus controleer dat je een commando kan uitvoeren zonder een wachtwoord prompt te krijgen:
+Dit zal je vragen naar een wachtwoord naar het gitolite account, en dan de publieke sleutel toegang opzetten. Dit is **absoluut noodzakelijk** voor het installatiescript, dus controleer dit om er zeker van te zijn dat je een commando kan laten lopen zonder een wachtwoord te hoeven in typen.
 
 	$ ssh gitolite@gitserver pwd
 	/home/gitolite
 
-Vervolgens kloon je Gitolite van de hoofdsite van het project en voer je het "easy install" script uit (het derde argument is de naam zoals je wilt verschijnen in het resulterende gitolite-admin repository):
+Vervolgens, clone je Gitolite van de hoofdsite van het project en roept de "easy install" script aan (het derde argument is jouw naam zoals je deze in de resulterende gitolite-admin repository wilt laten verschijnen):
 
 	$ git clone git://github.com/sitaramc/gitolite
 	$ cd gitolite/src
 	$ ./gl-easy-install -q gitolite gitserver sitaram
 
-En dan ben je klaar! Gitolite is nu geïnstalleerd op de server, en je hebt nu een splinternieuw repository genaamd `gitolite-admin` in de home directory van je werkstation. Je kunt je gitolite installatie beheren door wijzigingen te doen in dit repository en te pushen.
+En dat is het! Gitolite is nu geïnstalleerdop je server, en je hebt nu een gloednieuwe repository genaamd `gitolite-admin` in de home directory van jouw werkstation. Je beheert je gitolite setup door een wijziging aan te brengen in deze reporitory en deze te pushen.
 
-Dat laatste commando zorgt wel voor een flinke hoeveelheid uitvoer, dat interessant kan zijn om te lezen. Daarnaast wordt de eerste keer dat je dit uitvoert een nieuw sleutelpaar gegenereerd; je zult hiervoor een wachtzin moeten kiezen of enter drukken om zonder te werken. Waarom een tweede paar nodig is, en hoe het gebruikt wordt, wordt uitgelegd in het "ssh troubleshooting" document dat bij Gitolite zit. (He, de documentatie moet toch *ergens* goed voor zijn!)
+Dat laatste commando produceert nogal een hoeveelheid uitvoer dat wellicht interessant is om te lezen. Ook wordt er, de eerste keer dat je het laat lopen, er een nieuwe sleutelpaar gemaakt; je moet een wachtwoord kiezen of Enter als je er geen wilt. Waarom een tweede sleutelpaar nodig is, en hoe deze wordt gebruikt, wordt uitgelegd in het "ssh troubleshooting" document dat bij Gitolite wordt meegeleverd. (Hey, de documentatie moet *ergens* goed voor zijn!)
 
-Standaard worden de `testing` en `gitolite-admin` repositories aangemaakt. Als je een van deze lokaal wilt klonen (vanaf een account dat SSH console toegang heeft tot het gitolite account via *authorized_keys*), type:
+Repositories genaamd `gitolite-admin` en `testing` worden standaard op de server aangemaakt. Als je een van beide lokaal wilt clonen (van een account die SSA console toegang heeft naar het gitolite account via *authorized_keys*) type je:
 
 	$ git clone gitolite:gitolite-admin
 	$ git clone gitolite:testing
-
-Om dezelfde repos van ieder ander account te klonen:
+	
+Om deze zelfde repositories te clonen van een willekeurige ander account:
 
 	$ git clone gitolite@servername:gitolite-admin
 	$ git clone gitolite@servername:testing
 
+### De Installatie Aanpassen ###
 
-### De installatie aanpassen ###
-
-Hoewel de standaard, snelle, installatie voor de meeste mensen werkt, zijn er manieren om de installatie aan te passen als dat nodig is. Als je het `-q` argument weglaat, krijg je een "spraakzame" installatiemodus -- met gedetailleerde informatie van wat de installatie aan het doen is bij iedere stap. De spraakzame modus laat je ook bepaalde parameters van de server-kant instellen, zoals de locatie van de echte repositories, door een "rc" bestand dat de server gebruikt aan te passen. Dit "rc" bestand is behoorlijk van commentaar voorzien, dus je zou eenvoudig in staat moeten zijn om de wijzigingen te maken die je wilt, op te slaan, en te vervolgen. Dit bestand bevat ook instellingen die je kunt aanpassen om sommige geavanceerde opties van gitolite aan of uit te zetten.
+Hoewel de standaard, snelle, installatie werkt voor de meeste mensen, zijn er een aantal manieren om de installatie aan te passen als dat nodig is. Als je het `-q` argument weg laat, krijg je een "verbose" installatie wijze -- gedetaileerde informatie over wat de installatie aan het doen is bij elke stap. De verbose wijze staat je ook toe om bepaalde server-side parameters aan te passen, zoals de locatie van de eigenlijke repositories, door het wijzigen van een "rc" bestand dat de server gebruikt. Dit "rc" bestand is ruimhartig van commentaar voorzien dus je zou in staat moeten zijn om elke wijziging die je nodig vindt vrij snel te maken, op te slaan en door te gaan. Dit bestand bevat ook enkele instellingen die je kunt aanpassen om de meer geavanceerde functies van gitolite aan of uit te zetten.
 
-### Configuratiebestand en Toegangsregels ###
+### Config bestand en Beheer van Toegangsregels ###
 
-Als de installatie klaar is, kun je wijzigen naar het `gitolite-admin` repository (dat in je HOME directory geplaatst is) en er in rondkijken om te zien wat je hebt:
+Op het moment dat de installatie afgerond is, schakel je over naar de `gitolite-admin` repository (staat in je HOME directory) en begin je rond te snuffelen om te zien wat je daar hebt:
 
 	$ cd ~/gitolite-admin/
 	$ ls
@@ -581,11 +576,11 @@ Als de installatie klaar is, kun je wijzigen naar het `gitolite-admin` repositor
 	repo testing
 	    RW+                 = @all
 
-Let op dat "sitaram" (het laatste argument voor het `gl-easy-install` commando dat je eerder invoerde) lees- en schrijftoegang heeft op het `gitolite-admin` repository, en een publieke sleutelbestand heeft met dezelfde naam.
+Merk op dat "sitaram" (het laatste argument in het `gl-easy-install` commando dat je eerder gegeven hebt) lees en schrijf rechten heeft op de `gitolite-admin` repository en een publiek sleutelbestand met dezelfde naam.
 
-De syntax voor het gitolite configuratie bestand is ruim beschreven in `conf/example.conf`, dus daarom noemen we hier alleen de hoogtepunten.
+De syntax van het config bestand voor gitolite is ruimhartig van documentatie voorzien in `conf/example.conf`, dus we zullen alleen wat hoofdpunten benoemen.
 
-Je kunt voor het gemak gebruikers of repos groeperen. De groepnamen zijn net als macros; als je ze definieert, maakt het niet eens uit of ze projecten zijn of gebruikers; dat onderscheid wordt alleen gemaakt als je de "macro" *gebruikt*.
+Je kunt voor het gemak gebruikers of repositories groeperen. De groepnamen zijn vergelijkbaar met macros; als je ze definieert maakt het niet uit of het projecten of gebruikers zijn, dat onderscheid wordt pas gemaakt als je de "macro" gaat *gebruiken*.
 
 	@oss_repos      = linux perl rakudo git gitolite
 	@secret_repos   = fenestra pear
@@ -595,7 +590,7 @@ Je kunt voor het gemak gebruikers of repos groeperen. De groepnamen zijn net als
 	@engineers      = sitaram dilbert wally alice
 	@staff          = @admins @engineers @interns
 
-Je kunt permissies instellen op "ref" niveau. In het volgende voorbeeld mogen stagiaires alleen naar de "int" branch pushen. Engineers mogen pushen naar iedere branch waarvan de naam begint met "eng-", en tags die beginnen met "rc" gevolgd door een cijfer. En de admins mogen alles (inclusief rewind) doen op iedere ref.
+Je kunt de permissies beheren op het "ref" niveau. In het volgende voorbeeld kunnen stagieres (interns) alleen maar naar de "int" branch pushen. Techneuten (engineers) kunnen naar elke branch pushen waarvan de naam begint met "eng-", en tags die beginnen met "rc" gevolgd door een getal. En de admins kunnen alles (inclusief terugdraaien) naar elke ref.
 
 	repo @oss_repos
 	    RW  int$                = @interns
@@ -603,38 +598,38 @@ Je kunt permissies instellen op "ref" niveau. In het volgende voorbeeld mogen st
 	    RW  refs/tags/rc[0-9]   = @engineers
 	    RW+                     = @admins
 
-De expressie achter de `RW` of `RW+` is een reguliere expressie (regex), waarmee de ref naam (ref) waarnaar gepusht wordt, wordt gecontroleerd. Dus daarom noemen we het een "refex"! Natuurlijk kan een refex veel krachtiger zijn dan hier getoond wordt, dus overdrijf niet als je niet op je gemak bent met perl regexen.
+De expressie achter de `RW` of `RW+` is een zgn. regular expression (regex) waartegen de refname (ref) die wordt gepushed wordt vergeleken. Dus we noemen het natuurlijk een "refex"! En natuurlijk kan een refex veel krachtiger zijn dan hier wordt getoond, dus ga het niet overdrijven als je niet al te goed in de perl regexen zit.
 
-En, zoals je waarschijnlijk al geraden had, zet Gitolite `refs/heads/` er als een syntactisch gemak voor als de refex niet begint met `refs/`.
+Zoals je wellicht al geraden hebt, prefixed Gitolite `refs/heads/` als een syntactische handigheid als de refex niet begint met `refs/`.
 
-Een belangrijke eigenschap van de syntax van het configuratiebestand is dat niet alle regels voor een repository op een plaats moeten staan. Je kunt alle overeenkomstige dingen bij elkaar houden, zoals alle regels voor `oss_repos`  die hierboven getoond wordt, en dan specifieke regels voor specifieke gevallen verderop toevoegen, zoals:
+Een belangrijke eigenschap van de syntax van het config bestand is dat alle regels van een repository niet op één plek hoeft te staan. Je kunt al het generieke spul bij elkaar houden, zoals de regels voor alle `oss_repos` zoals ze hier boven staan, en dan op een latere plaats specifieke regels voor specifieke gevallen, zoals hier:
 
 	repo gitolite
 	    RW+                     = sitaram
 
-Die regel zal alleen maar toegevoegd worden aan de set regels voor het `gitolite` repository.
+Deze regel wordt gewoon toegevoegd aan de set met regels voor de `gitolite` repository.
 
-Op dit punt zul je je misschien afvragen hoe de toegangsregels feitelijk toegepast worden, dus laten we dat kort bespreken.
+Je zou je op dit punt kunnen afvragen hoe de toegangsregels eigenlijk worden toegepast, laten we dat kort behandelen.
 
-Er zijn twee lagen van toegang in gitolite. De eerste is op het niveau van het repository; als je lees (of schrijf) toegang hebt op *een* ref in het repository, dan heb je lees (of schrijf) toegang tot het repository.
+Er zijn twee niveaus van toegangsbeheer in gitolite. De eerste is op repository niveau. Als je lees (of schrijf)rechten hebt tot *enige* ref in de repository, dan heb je lees (of schrijf) rechten tot de repository.
 
-De tweede laag, die alleen van toepassing is op "schrijf" toegang, is per branch of tag binnen een repository. De gebruikersnaam, de toegang die geprobeerd wordt (`W` of `+`), en de refnaam die aangepast wordt zijn bekend. De toegangsregels worden nagekeken in volgorde van verschijning in het configuratiebestand, waarbij gezocht wordt naar een passende vergelijking voor deze combinatie (maar onthoudt dan de refnaam gepast wordt met een regex, niet slechts met tekst). Als een overeenkomst gevonden wordt, dan slaagt de push. Als de vergelijking er doorheen valt wordt toegang geweigerd.
+Het tweede niveau, alleen van toepassing voor "schrijf" toegang, is per branch of tag binnen een repository. De gebruikersnaam, het type toegang wat wordt gevraagd (`W` of '+'), en de refname dat wordt gewijzigd (update) zijn bekend. De toegangsregels worden gecontroleerd in volgorde van voorkomst in het config bestand, en er wordt gekeken naar een treffer voor deze combinatie (maar onthoudt dat de refname middels een regex wordt vergeleken, niet een simpele string-vergelijking). Als er een treffer is, dan slaagt de push. Als er geen treffer wordt gevonden (fallthrough) dan wordt toegang geweigerd.
 
-### Geavanceerde Toegangscontrole met "afwijzing" regels ###
+### Geavanceerde Toegangs Controle met "deny" regels ###
 
-Tot dusver hebben we alleen permissies gezien die `R`, `RW`, of `RW+` zijn. Maar, gitolite staat ook een andere permissie toe: `-`, wat voor "afwijzing" staat. Dit geeft je veel meer kracht, ten koste van wat complexiteit, omdat nu er doorheen vallen niet de *enige* manier is waarop toegang geweigerd wordt, de *volgorde van de regels doet er nu ook toe*!
+Tot zover hebben we alleen permissies gezien uit het rijtje `R`, `RW` of `RW+`. Echter, gitolite kent een andere permissie: `-`, wat staat voor "deny" (ontken). Dit geeft je veel meer macht, tegen kosten van wat hogere complexiteit omdat een fallthrough nu niet de *enige* manier is waarop toegang kan worden geweigerd, wordt *de volgorde van regels belangrijk*!
 
-Stel dat we in bovenstaande situatie willen toestaan dat engineers alle branches *behalve* master en integ mogen terugdraaien. Zo doe je dat:
+Stel dat, in de onderstaande situatie, we de techneuten in staat willen stellen elke branch te laten terugdraaien *behalve* master en integ. Dit is de manier om dat te doen:
 
 	    RW  master integ    = @engineers
 	    -   master integ    = @engineers
 	    RW+                 = @engineers
 
-Nogmaals, je volgt eenvoudig de regels vanaf de bovenkant totdat je een overeenkomst vindt voor je toegangsmodus, of een afwijzing. Een push zonder rewind op master of integ wordt toegestaan door de eerste regel. Een rewind push naar die refs komt niet overeen met de eerste regel, valt door naar de tweede, en wordt daarom afgewezen. Iedere push (rewind of non-rewind) naar refs anders dan master of integ zal sowieso niet overeenkomen met de eerste twee regels, en de derde regel staat het toe.
+Nogmaals, je hoeft slechts de regels van boven naar beneden af te lopen tot je een treffer hebt voor je gevraagde toegangswijze, of een afwijzing. Een push die niets terugdraait naar master of integ wordt door de eerste regel toegestaan. Een terugdraai-push naar deze refs geeft geen treffer op de eerste regel en valt door naar de tweede regel en wordt daarom geweigerd. Elke push (terugdraaiend of niet) naar refs anders dan master of integ zullen op de eerste twee regels zowiezo niet treffen en de derde regel staat dit toe.
 
-### Pushen beperken per gewijzigde bestanden ###
+### Beperken van pushes bij gewijzigde bestanden ###
 
-Naast het beperken van de branches waar een gebruiker wijzigingen naar kan pushen, kun je ook de bestanden die ze aan mogen raken beperken. Bijvoorbeeld, stel dat de Makefile (of een ander programma) eigenlijk niet door iedereen gewijzigd mag worden, omdat er een hoop dingen vanaf hangen of kapot gaan als de wijzigingen niet *precies goed* gedaan worden. Je kunt het gitolite vertellen:
+Bovenop het beperken van gebruikersrechten op branches voor een gebruiker, kan je ook de rechten van gebruikers beperken op bestanden. Als voorbeeld, misschien is de Makefile (of een ander programma) niet echt bedoeld om te worden gewijzigd door iedereen, omdat een groot aantal dingen afhankelijk ervan zijn of omdat het stuk loopt als de wijzigingen niet *precies goed* gebeuren. Je kunt het gitolite duidelijk maken:
 
     repo foo
         RW                  =   @junior_devs @senior_devs
@@ -645,29 +640,29 @@ Naast het beperken van de branches waar een gebruiker wijzigingen naar kan pushe
 
 Deze krachtige eigenschap is gedocumenteerd in `conf/example.conf`.
 
-### Persoonlijke Branches ###
+### Persoonlijke branches ###
 
-Gitolite heeft ook een eigenschap genaamd "persoonlijke branches" (of liever, "persoonlijke branch naamruimte (namespace)" die heel handig kan zijn in een bedrijfsomgeving.
+Gitolite heeft ook een mogelijkheid van "persoonlijke branches" (of liever gezegd "persoonlijke branch namespace") wat erg nuttig kan zijn in een bedrijfssituatie.
 
-Veel van de code uitwisseling die gedaan wordt in de git wereld gebeurd door middel van "pull alstublieft" verzoeken. In een bedrijfsomgeving echter is ongeverifieerde toegang een no-no, een werkstation van een ontwikkelaar kan geen verificatie doen, dus je zult naar de centrale server moeten pushen en iemand moeten vragen om vanaf daar te pullen.
+Veel van de code-uitwisselingen in de git-wereld verlopen via zgn. "please pull" aanvragen. In een bedrijfsomgeving echter is ongeauthoriseerde toegang taboe, en het werkstation van een ontwikkelaar kan geen authenticatie doen, dus je moet naar de centrale server pushen en iemand vragen daarvandaan te pullen.
 
-Dit zou doorgaans dezelfde branchnaam vervuiling veroorzaken als in een gecentraliseerd VCS, en het instellen van permissies hiervoor wordt een klus voor de admin.
+Dit zou normaalgesproken een gelijksoortige branch-brij veroorzaken als in een gecentraliseerde versiebeheersysteem, en daarbij wordt het opzetten van permissies een vervelende klus voor de administrator.
 
-Gitolite staat je toe een "personal" of "scratch" naamruimte prefix voor iedere ontwikkelaar te definiëren (bijvoorbeeld, `refs/personal/<devname>/*`); zie de "personal branches" sectie in `doc/3-faq-tips-etc.mkd` voor details.
+Gitolite stelt je in staat een "personal" of "scratch" namespace prefix voor elke ontwikkelaar te definiëren (bijvoorbeeld `refs/personal/<devname>/*`); zie ook de "personal branches" paragraaf in `doc/3-faq-tips-etc.mkd` voor details.
 
-### "Wildcard" repositories ###
+### "Wildcard" repositores ###
 
-Gitolite staat je toe om repositories met wildcards (eigenlijk perl regexen) te specificeren, zoals bijvoorbeeld `assignments/s[0-9][0-9]/a[0-9][0-9]`, als willekeurig voorbeeld. Dit is een *zeer* krachtige eigenschap, dat aan gezet moet worden door `$GL_WILDREPOS = 1;` in het rc bestand in te stellen. Het staat je toe om een nieuwe permissie modus ("C") toe te wijzen, die gebruikers toestaat om repositories op basis van die wildcards aan te maken, waarbij automatisch eigendom toegewezen wordt aan de gebruiker die het aangemaakt heeft, hem/haar toestaat R en RW permissies aan andere gebruikers uit te delen om samen te werken etc. Deze eigenschap is gedocumenteerd in `doc/4-wildcard-repositories.mkd`.
+Gitolite laat je repositories specificeren met wildcards (eigenlijk perl regex expressies), zoals bijvoorbeeld `assignments/s[0-9][0-9]/a[0-9][0-9]`, om maar een willekeurig voorbeeld te nemen. Dit is een *heel* krachtige eigenschap die wordt aangezet door de regel `$GL_WILDREPOS = 1;` in het rc bestand. Het laat je een nieuwe permissiewijze ("C") toe te wijzen welke gebruikers in staat stelt repositories aan te maken die voldoen aan zulke wildcards, automatisch eigenaarsschap toe te wijzen aan de gebruiker die hem heeft aangemaakt, staat deze gebruiker toe om "R" en "RW" permissies aan anderen toe te wijzen om samen te werken, etc. Deze eigenschap is beschreven in `doc/4-wildcard-repositories.mkd`.
 
-### Andere Eigenschappen ###
+### Andere eigenschappen ###
 
-We ronden deze bespreking af met een voorproefje van andere eigenschappen, die allemaal en nog vele meer, gedetailleerd zijn beschreven in de "faqs, tips, etc" en andere documenten.
+We ronden deze uiteenzetting af met een passe partout van andere eigenschappen, welke alle (en nog vele andere) tot in de kleinste detail zijn beschreven in de "faqs, tips, etc" en andere documenten.
 
-**Logging**: Gitolite legt alle succesvolle toegangen vast. Als je wat rustiger bent over het geven van rewind toegang aan andere mensen (`RW+`) en een of ander joch heeft "master" opgeblazen, dan is het logbestand je redder, in termen van het eenvoudig en snel vinden van het SHA dat kapot is gegaan.
+**Logging**: Gitolite logt alle succesvolle toegangspogingen. Als je wat te los bent geweest in het toekennen van terugdraai permissies (`RW+`) en een of andere nozem heeft "master" vernaggelt, is de log-file een redder in de nood in de zin van snel en eenvoudig achterhalen van de SHA die verdwenen is.
 
-**Git buiten normaal PATH**: Een extreem bruikbare gemakseigenschap in gitolite is ondersteuning voor een git installatie buiten het normale `$PATH` (dit komt vaker voor dan je denkt; sommige bedrijfsomgevingen of zelfs sommige hosting providers weigeren dingen systeembreed te installeren en je eindigt uiteindelijk met het installeren in je eigen home mappen). Normaal gesproken wordt je geforceerd om de *gebruikerskant* git op een of andere manier bewust te maken van deze niet-standaard locatie van de git bestanden. Met gitolite, kies je slechts een spraakzame installatie en stelt `$GIT_PATH` in in de "rc" bestanden. Voor de rest zijn er daarna geen wijzigingen meer nodig aan de gebruikerskant :-)
+**Git buiten reguliere PATH**: Een ontzettend handige eigenschap in gitolite is het ondersteunen van git buiten het regulier `$PATH` (dit komt vaker voor dan je zou denken, sommige bedrijfs omgevingen of zelfs sommige hosting providers weigeren dingen systeem-breed te installeren en je eindigt ermee dat je ze in je eigen directories zet). Normaalgesproken ben je gedwongen git aan de *client-side* op de een of andere manier te vertellen van deze niet-standaard locatie van de git binaries. Met gitolite hoe je alleen een verbose installatie te kiezen en `$GIT_PATH` in de "rc" bestanden in te vullen. Hierna geen wijzigingen aan de kant van de clients nodig :-)
 
-**Toegangsrapportage**: Een andere handige eigenschap is wat er gebeurd als je probeert met SSH naar de server te gaan. Gitolite toont je welke repos je toegang tot hebt, en welke toegang dat is. Hier is een voorbeeld:
+**Rapportage van toegangsrechten**: Nog zo'n handige eigenschap is wat er gebeurt als je gewoon met ssh naar de server gaat. Gitolite laat zien welke repositories je toegang toe hebt en welke soort toegang dat dan wel is. Hier is een voorbeeld:
 
         hello sitaram, the gitolite version here is v1.5.4-19-ga3397d4
         the gitolite config gives you the following access:
@@ -679,25 +674,24 @@ We ronden deze bespreking af met een voorproefje van andere eigenschappen, die a
              R     indic_web_input
              R     shreelipi_converter
 
-**Delegatie**: Voor hele grote installaties, kun je verantwoordelijkheden voor groepen of repositories delegeren aan diverse personen, en ze die onderdelen onafhankelijk laten beheren. Dit beperkt de belasting op de hoofd beheerder, en maakt hem minder een flessenhals. Deze eigenschap heeft zijn eigen documentatiebestand in de `doc/` map.
+**Delegeren**: Voor extreem grote installaties kan je de verantwoordelijkheid voor groepen van repositories delegeren aan verschilllende mensen en hen het beheer van die delen onafhankelijk laten regelen. Dit vermindert de werkdruk van de hoofd-beheerder, en maakt van hem minder een faalpunt. Deze eigenschap heeft zijn eigen docuentatie bestand in de `doc/` directory.
 
-**Gitweb ondersteuning**: Gitolite ondersteund gitweb op meerdere manieren. Je kunt specificeren welke repos zichtbaar zijn via gitweb. Je kunt de "eigenaar" en "omschrijving" voor gitweb instellen in het gitolite configuratiebestand. Gitweb heeft een mechanisme voor je om toegangscontrole gebaseerd op HTTP verificatie te implementeren, dus je kunt het het "samengestelde" configuratiebestand laten gebruiken dat gitolite produceert, wat betekend dat dezelfde toegangsregels (voor leestoegang) van toepassing zijn op gitweb en gitolite.
+**Gitweb ondersteuning**: Gitolite ondersteunt gitweb op verschillende manieren. Je kunt aangeven welke repositories zichtbaar zijn via gitweb. Je kunt de "owner" (eigenaar) en "description" (omschrijving) voor gitweb vanuit de gitolite configuratie bestanden definiëren. Gitweb heeft een mechanisme beschikbaar waarmee toegang via HTTP wordt geïmplementeerd, deze kan je het "gecompileerde" config bestand van de gitolite config file laten gebruiken, wat inhoudt dat gitweb en gitolite dezelfde toegangsregels gebruikt (voor lees toegang).
 
-**Spiegeling**: Gitolite kan je helpen met het onderhouden van meerdere spiegels, en er makkelijk tussen wisselen als de hoofdserver plat gaat.
 
 ## Git daemon ##
 
-Voor publieke ongeverifieerde leestoegang tot je projecten zul je het HTTP protocol achter je willen laten, en overstappen op het Git protocol. De hoofdreden is snelheid. Het Git protocol is veel efficiënter en daarmee sneller dan het HTTP protocol, dus het zal je gebruikers tijd besparen.
+Voor publieke ongeauthenticeerde leestoegang tot je projecten zul je het HTTP protocol achter je willen laten, en overstappen op het Git protocol. De belangrijkste reden is snelheid. Het Git protocol is veel efficiënter en daarmee sneller dan het HTTP protocol, dus het zal je gebruikstijd besparen.
 
-Nogmaals, dit is voor ongeverifieerde alleen-lezen toegang. Als je dit op een server buiten je firewall draait, zul je het alleen moeten gebruiken voor projecten die voor de hele wereld toegankelijk moeten zijn. Als de server waarop je het draait binnen je firewall staat, zou je het kunnen gebruiken voor projecten waarbij een groot aantal mensen of computers (continue integratie of bouwservers) alleen-lezen toegang moeten hebben, waarbij je niet voor iedereen een SSH sleutel wilt toevoegen.
+Nogmaals, dit is voor ongeauthenticeerde alleen-lezen toegang. Als je dit op een server buiten je firewall draait, zul je het alleen moeten gebruiken voor projecten die voor de hele wereld toegankelijk moeten zijn. Als de server waarop je het draait binnen je firewall staat, zou je het kunnen gebruiken voor projecten waarbij een groot aantal mensen of computers (continue integratie of bouwservers) alleen-lezen toegang moeten hebben, waarbij je niet voor iedereen een SSH sleutel wilt toevoegen.
 
 In ieder geval is het Git protocol relatief eenvoudig in te stellen. Eigenlijk is het enige dat je moet doen dit commando op een daemon manier uitvoeren:
 
 	git daemon --reuseaddr --base-path=/opt/git/ /opt/git/
 
-`--reuseaddr` staat de server toe om te herstarten zonder te wachten tot oude connecties een time out krijgen, de `--base-path` optie staat mensen toe om projecten te klonen zonder het volledige pad te specificeren, en het pad aan het einde vertelt de Git daemon waar hij moet kijken voor de te exporteren repositories. Als je een firewall draait, zul je er ook een gat in moeten maken op poort 9418 op de machine waar je dit op instelt.
+`--reuseaddr` staat de server toe om te herstarten zonder te wachten tot oude connecties een time-out krijgen, de `--base-path` optie staat mensen toe om projecten te clonen zonder het volledige pad te specificeren, en het pad aan het einde vertelt de Git daemon waar hij moet kijken voor de te exporteren repositories. Als je een firewall draait, zul je er poort 9418 open moeten zetten op de machine waar je dit op gaat doen.
 
-Je kunt dit proces op een aantal manieren daemoniseren, afhankelijk van het besturingssysteem waarop je draait. Op een Ubuntu machine, zul je een Upstart script gebruiken. Dus in het volgende bestand
+Je kunt dit proces op een aantal manieren daemoniseren, afhankelijk van het besturingssystem waarop je draait. Op een Ubuntu machine, zul je een Upstart script gebruiken. Dus in het volgende bestand
 
 	/etc/event.d/local-git-daemon
 
@@ -714,18 +708,18 @@ stop je dit script:
 
 Omwille van veiligheidsredenen, wordt sterk aangeraden om deze daemon uit te voeren als gebruiker met alleen-lezen toegang op de repositories — je kunt dit makkelijk doen door een gebruiker 'git-ro' aan te maken en de daemon als deze uit te voeren. Om het eenvoudig te houden voeren we het als dezelfde 'git' gebruiker uit, als waarin Gitosis draait.
 
-Als je je machine herstart, zal je Git daemon automatisch opstarten en herstarten als hij onderuit gaat. Om het te laten draaien zonder te herstarten, kun je dit uitvoeren:
+Als je de machine herstart, zal de Git daemon automatisch opstarten en herstarten als de server onderuit gaat. Om het te laten draaien zonder te herstarten, kun je dit uitvoeren:
 
 	initctl start local-git-daemon
 
-Op andere systemen zul je misschien `xinetd` willen gebruiken, een script in je `sysvinit` systeem, of iets anders — zolang je dat commando maar ge-daemoniseerd krijgt en op een of andere manier in de gaten gehouden wordt.
+Op andere systemen zul je misschien `xinetd` willen gebruiken, een script in je `sysvinit` systeem, of iets anders – zolang je dat commando maar ge-daemoniseerd krijgt en deze op een of andere manier in de gaten gehouden wordt.
 
-Vervolgens zul je je Gitosis server moeten vertellen welke repositories je ongeverifieerde Gitserver gebaseerde toegang toestaat. Als je een sectie toevoegt voor iedere repository, dan kun je die repositories specificeren waarop je je Git daemon wilt laten lezen. Als je Git protocol toegang tot je iphone project wilt toestaan, dan voeg je dit toe aan het eind van het `gitosis.conf` bestand:
+Vervolgens zul je je Gitosis server moeten vertellen welke repositories je onauthenticeerde Gitserver gebaseerde toegang toestaat. Als je een sectie toevoegt voor iedere repository, dan kun je die repositories specificeren waarop je je Git daemon wilt laten lezen. Als je Git protocol toegang tot je iphone project wilt toestaan, dan voeg je dit toe aan het eind van het `gitosis.conf` bestand:
 
 	[repo iphone_project]
 	daemon = yes
 
-Als dat gecommit en gepusht is, dan zou je draaiende daemon verzoeken moeten serveren aan iedereen die toegang heeft op poort 9418 van je server.
+Als dat gecommit en gepushed is, dan zou de draaiende daemon verzoeken moeten serveren aan iedereen die toegang heeft op poort 9418 van je server.
 
 Als je besluit om Gitosis niet te gebruiken, maar je wilt toch een Git daemon instellen, dan moet je dit op ieder project uitvoeren waarvoor je de Git daemon wilt laten serveren:
 
@@ -751,15 +745,15 @@ Als je nu het project commit en pusht, start GitWeb automatisch met het tonen va
 
 ## Hosted Git ##
 
-Als je niet door al het werk heen wilt om je eigen Git server op te zetten, heb je meerdere opties om je Git project op een externe speciale hosting pagina te laten beheren. Dit biedt een aantal voordelen: een ge-hoste pagina is over het algemeen snel in te stellen, en eenvoudig om projecten op te starten, en er komt geen server beheer en onderhoud bij kijken. Zelfs als je je eigen server intern ingesteld hebt, zul je misschien een publieke host pagina voor je open source broncode willen — dat is over het algemeen makkelijker voor de open source gemeenschap te vinden en je er mee te helpen.
+Als je niet al het werk wilt doen om je eigen Git server op te zetten, heb je meerdere opties om je Git project op een externe speciale hosting pagina te laten beheren. Dit biedt een aantal voordelen: een ge-hoste pagina is over het algemeen snel in te stellen, eenvoudig om projecten mee op te starten, en er komt geen serverbeheer en -onderhoud bij kijken. Zelfs als je je eigen server intern ingesteld hebt, zul je misschien een publieke host pagina voor je open source broncode willen – dat is over het algemeen makkelijker voor de open source commune te vinden en je er mee te helpen.
 
 Vandaag de dag heb je een enorm aantal beheer opties om uit te kiezen, elk met verschillende voor- en nadelen. Om een recente lijst te zien, ga dan kijken op de volgende pagina :
 
 	https://git.wiki.kernel.org/index.php/GitHosting
 
-Omdat we ze niet allemaal kunnen behandelen, en ik toevallig bij een ervan werk, zullen we deze sectie gebruiken om door het instellen van een account en het opzetten van een project op GitHub lopen. Dit geeft je een idee van het benodigde werk.
+Omdat we ze niet allemaal kunnen behandelen, en ik toevallig bij een ervan werk, zullen we deze paragraaf gebruiken het instellen van een account en het opzetten van een project op GitHub te doorlopen. Dit geeft je een idee van het benodigde werk.
 
-GitHub is veruit de grootste open source Git beheer pagina en het is ook een van de weinige die zowel publieke als privé beheer opties biedt, zodat je je open source en commerciële privé code in dezelfde plaats kunt bewaren. Sterker nog, we hebben GitHub gebruikt om privé samen te werken aan dit boek.
+GitHub is veruit de grootste open source Git beheer pagina en het is ook een van de weinige die zowel publieke als privé beheer opties biedt, zodat je je open source en commerciele privé code op dezelfde plaats kunt bewaren. Sterker nog, we hebben GitHub gebruikt om privé samen te werken aan dit boek.
 
 ### GitHub ###
 

From f9a5a81ea1da72dfa309a46ff8e65666351ad120 Mon Sep 17 00:00:00 2001
From: Cor <cor.takken@cgi.com>
Date: Mon, 20 Jan 2014 13:33:17 +0100
Subject: [PATCH 126/690] [nl] Completed translating to Dutch, repaired a false
 "link" to "Simple Setups" section (that section does not exist) and made it
 point to the section where the ssh_keygen command is used.;sK

---
 nl/04-git-server/01-chapter4.markdown | 125 +++++++++++++-------------
 1 file changed, 64 insertions(+), 61 deletions(-)

diff --git a/nl/04-git-server/01-chapter4.markdown b/nl/04-git-server/01-chapter4.markdown
index 9b2901a18..b05646106 100644
--- a/nl/04-git-server/01-chapter4.markdown
+++ b/nl/04-git-server/01-chapter4.markdown
@@ -1,6 +1,6 @@
 # Git op de server #
 
-Op dit punt zou je alledaagse taken waarvoor je Git zult gebruiken kunnen doen. Maar, om samen te kunnen werken in Git zul je een remote repository moeten hebben. Technisch gezien kun je wijzigingen pushen en pullen van individuele repositories, maar dat wordt afgeraden, omdat je vrij gemakkelijk het werk waar anderen mee bezig zijn in de war kunt schoppen als je niet oppast. Daarnaast wil je dat je medewerkers de repository kunnen bereiken, zelfs als jouw computer van het netwerk is – het hebben van een betrouwbare gezamenlijke repository is vaak handig. De voorkeursmethode om met iemand samen te werken is om een tussenliggende repository in te richten waar beide partijen toegang to hebben en om daar naartoe te pushen en vandaan te pullen. We zullen deze repository de `Git server` noemen, maar je zult zien dat het over het algemeen maar een klein beetje systeembronnen kost om een Git repository te verzorgen, dus je zult er zelden een complete server voor nodig hebben.
+Je zou nu de alledaagse taken waarvoor je Git zult gebruiken moeten kunnen uitvoeren. Echter, om enige vorm van samenwerking te hebben in Git is een remote repository nodig. Technisch gezien kun je wijzigingen pushen en pullen van individuele repositories, maar dat wordt afgeraden omdat je vrij gemakkelijk het werk waar anderen mee bezig zijn in de war kunt schoppen als je niet oppast. Daarnaast wil je dat je medewerkers de repository kunnen bereiken, zelfs als jouw computer van het netwerk is – het hebben van een betrouwbare gezamenlijke repository is vaak handig. De voorkeursmethode om met iemand samen te werken is om een tussenliggende repository in te richten waar beide partijen toegang tot hebben en om daar naartoe te pushen en vandaan te pullen. We zullen deze repository de `Git server` noemen, maar je zult zien dat het over het algemeen maar weinig systeembronnen kost om een Git repository te verzorgen, dus je zult er zelden een complete server voor nodig hebben.
 
 Een Git server draaien is eenvoudig. Als eerste kies je met welke protocollen je de server wilt laten communiceren. Het eerste gedeelte van dit hoofdstuk zullen we de beschikbare protocollen bespreken met de voor- en nadelen van elk. De daarop volgende paragrafen zullen we een aantal veel voorkomende opstellingen bespreken die van die protocollen gebruik maken en hoe je je server ermee kunt opzetten. Als laatste laten we een paar servers van derden zien, als je het niet erg vindt om je code op de server van een ander te zetten en niet het gedoe wilt hebben van het opzetten en onderhouden van je eigen server.
 
@@ -16,7 +16,7 @@ Het is belangrijk om op te merken dat, met uitzondering van de HTTP protocollen,
 
 ### Lokaal protocol ###
 
-Het simpelste is het _Lokale protocol_, waarbij de remote repository in een andere directory op de schijf staat. Deze opzet wordt vaak gebruikt als iedereen in het team toegang heeft op een gedeeld bestandssyteem zoals een NFS mount, of in het weinig voorkomende geval dat iedereen op dezelfde computer werkt. Het laatste zou niet ideaal zijn, want dan zouden alle repositories op dezelfde computer staan, zodat een fataal verlies van gegevens veel groter wordt.
+Het simpelste is het _Lokale protocol_, waarbij de remote repository in een andere directory op de schijf staat. Deze opzet wordt vaak gebruikt als iedereen in het team toegang heeft op een gedeeld bestandssyteem zoals een NFS mount, of in het weinig voorkomende geval dat iedereen op dezelfde computer werkt. Het laatste zou niet ideaal zijn, want dan zouden alle repositories op dezelfde computer staan, zodat de kans op een fataal verlies van gegevens veel groter wordt.
 
 Als je een gedeeld bestandssyteem hebt, dan kun je clonen, pushen en pullen van een op een lokaal bestand aanwezige repository. Om een dergelijk repository te clonen, of om er een als een remote aan een bestaand project toe te voegen, moet je het pad naar het repository als URL gebruiken. Bijvoorbeeld, om een lokaal repository te clonen, kun je zoiets als het volgende uitvoeren:
 
@@ -26,7 +26,7 @@ Of je kunt dit doen:
 
 	$ git clone file:///opt/git/project.git
 
-Git werkt iets anders als je explicite `file://` aan het begin van de URL zet. Als je alleen het pad specificeert, probeert Git hardlinks te gebruiken, of het kopieert de bestanden die het nodig heeft. Als je `file://` specificeert, dan start Git de processen die het normaal gesproken gebruikt om data te transporteren over een netwerk, wat over het algemeen een minder efficiënte methode is om gegevens over te dragen. De belangrijkste reden om `file://` wel te specificeren is als je een schone kopie van de repository wilt met de vreemde refenties of objecten eruit gelaten – over het algemeen na een import uit een ander versiebeheer systeem of iets dergelijks (zie Hoofdstuk 9 voor onderhoudstaken). We zullen het normale pad hier gebruiken, omdat het bijna altijd sneller is om het zo te doen.
+Git werkt iets anders als je explicite `file://` aan het begin van de URL zet. Als je alleen het pad specificeert, probeert Git hardlinks te gebruiken, of het kopieert de bestanden die het nodig heeft. Als je `file://` specificeert, dan start Git de processen die het normaal gesproken gebruikt om data te transporteren over een netwerk, wat over het algemeen een minder efficiënte methode is om gegevens over te dragen. De belangrijkste reden om `file://` wel te specificeren is als je een schone kopie van de repository wilt met de vreemde referenties of objecten eruit gelaten – over het algemeen na een import uit een ander versiebeheer systeem of iets dergelijks (zie Hoofdstuk 9 voor onderhoudstaken). We zullen het normale pad hier gebruiken, omdat het bijna altijd sneller is om het zo te doen.
 
 Om een lokale repository aan een bestaand Git project toe te voegen, kun je iets als het volgende uitvoeren:
 
@@ -38,7 +38,7 @@ Daarna kun je op gelijke wijze pushen naar, en pullen van die remote als je over
 
 De voordelen van bestands-gebaseerde repositories zijn dat ze eenvoudig zijn en ze maken gebruik van bestaande bestandspermissies en netwerk toegang. Als je al een gedeeld bestandssysteem hebt, waar het hele team al toegang toe heeft, dan is een repository opzetten heel gemakkelijk. Je stopt de kale repository ergens waar iedereen gedeelde toegang tot heeft, en stelt de lees- en schrijfrechten in zoals je dat bij iedere andere gedeelde directory zou doen. In de volgende paragraaf "Git op een Server Krijgen" bespreken we hoe je een kopie van een kale repository kunt exporteren voor dit doeleinde.
 
-Dit is ook een prettige optie om snel werk uit een repository van iemand anders te pakken. Als jij en een collega aan hetzelfde project werken, en hij wil dat je iets bekijkt, dan is het uitvoeren van een commando zoals `git pull /home/john/project` vaak makkelijker dan dat hij naar een remote server moet pushen, en jij er van moet pullen.
+Dit is ook een prettige optie om snel werk uit een repository van iemand anders te pakken. Als jij en een collega aan hetzelfde project werken, en hij wil dat je iets bekijkt, dan is het uitvoeren van een commando zoals `git pull /home/john/project` vaak makkelijker dan wanneer hij naar een remote server moet pushen, en jij er van moet pullen.
 
 #### De nadelen ####
 
@@ -62,15 +62,15 @@ Je kunt ook de gebruiker weglaten, en Git gebruikt gegevens van de gebruiker waa
 
 #### De voordelen ####
 
-Er zijn vele voordelen om SSH te gebruiken. Ten eerste moet je het eigenlijk wel gebruiken als je geauthenticeerde schrijftoegang op je repository via een netwerk wilt. Ten tweede is het relatief eenvoudig in te stellen – SSH daemons komen veel voor, veel systeembeheerders hebben er ervaring mee, en veel operating systemen zijn er mee uitgerust of hebben applicaties om ze te beheren. Daarnaast is toegang via SSH veilig – alle data transporten zijn versleuteld en geauthenticeerd. En als laatste is SSH efficiënt, net zoals het Git en lokale protocol, de gegevens worden zo compact mogelijk gemaakt voordat het getransporteerd wordt.
+Er zijn vele voordelen om SSH te gebruiken. Ten eerste moet je het eigenlijk wel gebruiken als je geauthenticeerde schrijftoegang op je repository via een netwerk wilt. Ten tweede is het relatief eenvoudig in te stellen – SSH daemons komen veel voor, veel systeembeheerders hebben er ervaring mee, en veel operating systemen zijn er mee uitgerust of hebben applicaties om ze te beheren. Daarnaast is toegang via SSH veilig – alle data transporten zijn versleuteld en geauthenticeerd. En als laatste is SSH efficiënt, net zoals bij het Git en lokale protocol worden de gegevens zo compact mogelijk gemaakt voordat het getransporteerd wordt.
 
 #### De nadelen ####
 
-Het negatieve aspect van SSH is dat je er geen anonieme toegang naar je repository over kunt geven. Mensen moeten via SSH toegang hebben om er gebruik van te kunnen maken, zelfs als het alleen lezen is, zodat SSH toegang niet bevordelijk is voor open source projecten. Als je het alleen binnen je bedrijfsnetwerk gebruikt, dan is SSH misschien het enige protocol waar je mee in aanraking komt. Als je anonieme alleen-lezen toegang wilt toestaan tot je projecten, dan moet je SSH voor jezelf instellen om over te pushen, maar iets anders voor anderen om over te pullen.
+Het negatieve aspect van SSH is dat je er geen anonieme toegang naar je repository over kunt geven. Mensen moeten via SSH toegang hebben om er gebruik van te kunnen maken zelfs als het alleen lezen is, dit maakt dat SSH toegang niet echt bevordelijk is voor open source projecten. Als je het alleen binnen je bedrijfsnetwerk gebruikt, is SSH wellicht het enige protocol waar je mee in aanraking komt. Als je anonieme alleen-lezen toegang wilt toestaan tot je projecten, dan moet je SSH voor jezelf instellen om over te pushen, maar iets anders voor anderen om over te pullen.
 
 ### Het Git protocol ###
 
-Het volgende is het Git protocol. Dit is een specifieke daemon, die met Git meegeleverd wordt; het luistert op een toegewezen poort (9418), en verleent een vergelijkbare dienst als het SSH protocol, maar dan zonder enige vorm van authenticatie. Om een repository beschikbaar te stellen over het Git protocol, moet je een `git-export-daemon-ok` bestand aanmaken – de daemon zal een repository zonder dit bestand erin niet verspreiden – maar daarbuiten is er geen beveiliging. De Git repository beschikbaar om gecloned te kunnen worden door iedereen, of het is het niet. Dit betekent dat er over het algemeen geen pushing is via dit protocol. Je kunt push toegang aanzetten, maar gegeven het gebrek aan authenticatie kan als je de push toegang aan zet iedereen die de URL van jouw project op het internet vindt, pushen naar jouw project. We volstaan met te zeggen dat dit zelden de bedoeling kan zijn.
+Het volgende is het Git protocol. Dit is een specifieke daemon, die met Git meegeleverd wordt. Het luistert op een toegewezen poort (9418), en verleent een vergelijkbare dienst als het SSH protocol, maar dan zonder enige vorm van authenticatie. Om een repository beschikbaar te stellen over het Git protocol, moet je een `git-export-daemon-ok` bestand aanmaken – de daemon zal een repository zonder dit bestand erin niet verspreiden – maar daarbuiten is er geen beveiliging. De Git repository is beschikbaar om gecloned te kunnen worden door iedereen, of het is het niet. Dit betekent dat er over het algemeen geen pushing is via dit protocol. Je kunt push toegang aanzetten maar gegeven het gebrek aan authenticatie kan, als je de push toegang aan zet, iedereen die de URL van jouw project op het internet vindt pushen naar jouw project. We volstaan met te zeggen dat dit zelden de bedoeling kan zijn.
 
 #### De voordelen ####
 
@@ -79,7 +79,7 @@ Het Git protocol is het snelste dat beschikbaar is. Als je veel verkeer verwerkt
 #### De nadelen ####
 
 Het nadeel van het Git protocol is het gebrek aan authenticatie. Het is over het algemeen onwenselijk dat het Git protocol de enige toegang tot je project is. Meestal zul je het samen met SSH toegang gebruiken voor de paar ontwikkelaars die push (schrijf-)toegang hebben en de rest laat je `git://` voor alleen leestoegang gebruiken.
-Het is waarschijnlijk ook het meest ingewikkelde protocol om in te richten. Het moet een eigen daemon hebben, die speciaal voor die situatie ingericht is – we zullen er een instellen in het "Gitosis" gedeelte van dit hoofdstuk – het gebruikt `xinetd` configuratie of iets vergelijkbaars, wat ook niet altijd eenvoudig is op te zetten. Daarbij is ook firewall toegang tot poort 9418 nodig, wat geen standaard poort is dat in bedrijfsfirewalls is opengezet. Bij firewalls van grote bedrijven, is deze ongebruikelijke poort meestal dichtgezet.
+Het is waarschijnlijk ook het meest ingewikkelde protocol om in te richten. Het moet een eigen daemon hebben, die speciaal voor die situatie ingericht is – we zullen er een instellen in de "Gitosis" paragraaf van dit hoofdstuk – het gebruikt `xinetd` configuratie of iets vergelijkbaars, wat ook niet altijd eenvoudig is op te zetten. Daarbij is ook firewall toegang tot poort 9418 nodig, wat geen standaard poort is dat in bedrijfsfirewalls is opengezet. Bij firewalls van grote bedrijven, is deze ongebruikelijke poort meestal dichtgezet.
 
 ### Het HTTP/S protocol ###
 
@@ -91,41 +91,41 @@ Als laatste hebben we het HTTP protocol. Het mooie aan het HTTP of HTTPS protoco
 	$ mv hooks/post-update.sample hooks/post-update
 	$ chmod a+x hooks/post-update
 
-Dat is alles. De `post-update` hook, die standaard bij Git geleverd wordt, voert het noodzakelijke commando uit (`git update-server-info`) om HTTP fetching en cloning goed werkend te krijgen en houden. Dit commando wordt uitgevoerd als je via SSH naar deze repository pushed; en andere mensen kunnen clonen met behulp van zoiets als
+Dat is alles. De `post-update` hook, die standaard bij Git geleverd wordt, voert het noodzakelijke commando uit (`git update-server-info`) om HTTP fetching en cloning goed werkend te krijgen en houden. Dit commando wordt uitgevoerd als je via SSH naar deze repository pushed, en andere mensen kunnen clonen met behulp van zoiets als
 
 	$ git clone http://example.com/gitproject.git
 
 In dit specifieke voorbeeld gebruiken we het `/var/www/htdocs` pad wat gebruikelijk is voor Apache opstellingen, maar je kunt iedere statische webserver gebruiken – stop de kale repository in het betreffende pad. De Git data wordt geserveerd als standaard statische bestanden (zie hoofdstuk 9 voor details over hoe het precies geserveerd wordt).
 
-Het is mogelijk om Git ook over HTTP te laten pushen, alhoewel dat geen veelgebruikte techniek is en het vraagt dat je complexe WebDAV instellingen inricht. Omdat het zelden gebruikt wordt, zullen we het niet in dit boek beschrijven. Als je geïnteresseerd bent om de HTTP-push protocollen te gebruiken, dan kun je op `http://www.kernel.org/pub/software/scm/git/docs/howto/setup-git-server-over-http.txt` lezen hoe je een repository kunt maken. Het aardige van Git laten pushen over HTTP is dat je iedere WebDAV server kunt gebruiken, zonder specifieke Git funtionaliteit, dus je kunt deze functionaliteit gebruiken als je web-hosting provider WebDAV ondersteunt voor het maken van wijzigingen aan je webpagina.
+Het is mogelijk om Git ook over HTTP te laten pushen, alhoewel dat geen veelgebruikte techniek is en het vereist dat je complexe WebDAV instellingen inricht. Omdat het zelden gebruikt wordt, zullen we het niet in dit boek behandelen. Als je geïnteresseerd bent om de HTTP-push protocollen te gebruiken, dan kun je op `http://www.kernel.org/pub/software/scm/git/docs/howto/setup-git-server-over-http.txt` lezen hoe je een repository kunt maken. Het aardige van Git laten pushen over HTTP is dat je iedere WebDAV server kunt gebruiken zonder specifieke Git funtionaliteit, dus je kunt deze optie gebruiken als je web-hosting provider WebDAV ondersteunt voor het maken van wijzigingen aan je webpagina.
 
 #### De voordelen ####
 
-Het voordeel van het gebruik van het HTTP protocol is dat het eenvoudig in te stellen is. Een handvol benodigde commando's uitvoeren is alles wat er moet gebeuren om de wereld leestoegang te geven tot je Git repository. Het neemt maar een paar minuten van je tijd. Het HTTP protocol is niet erg belastend voor de systeembronnen van je server. Omdat het over het algemeen een statische webserver gebruikt om alle data te verspreiden - een normale Apache server kan gemiddeld duizenden bestanden zenden per seconde - is het moeilijk om zelfs een kleine server te overbelasten.
+Het voordeel van het gebruik van het HTTP protocol is dat het eenvoudig in te stellen is. Een handvol benodigde commando's uitvoeren is alles wat er moet gebeuren om de wereld leestoegang te geven tot je Git repository. Het neemt maar een paar minuten van je tijd. Het HTTP protocol is niet erg belastend voor de systeembronnen van je server. Omdat het over het algemeen een statische webserver gebruikt om alle data te verspreiden is het moeilijk om zelfs een kleine server te overbelasten - een normale Apache server kan gemiddeld duizenden bestanden zenden per seconde.
 
-Je kunt ook je repositories alleen-lezen serveren via HTTPS, wat inhoudt dat je het transport kunt versleutelen; je kunt zelfs zover gaan dat je clients een specifiek gesigneerd SSL certificaat laat gebruiken. Normaal gesproken als je je deze moeite wilt getroosten, dan is het makkelijker om publieke SSH sleutels te gebruiken; maar het kan in jouw specifieke geval een betere oplossing zijn om gesigneerde SSL certificaten of andere HTTP-gebaseerde authenticatie methoden te gebruiken voor alleen-lezen toegang via HTTPS.
+Je kunt ook je repositories alleen-lezen serveren via HTTPS, wat inhoudt dat je het gegevenstransport kunt versleutelen; je kunt zelfs zover gaan dat je clients een specifiek gesigneerd SSL certificaat laat gebruiken. Normaal gesproken als je je deze moeite wilt getroosten, dan is het makkelijker om publieke SSH sleutels te gebruiken; maar het kan in jouw specifieke geval een betere oplossing zijn om gesigneerde SSL certificaten of andere HTTP-gebaseerde authenticatie methoden te gebruiken voor alleen-lezen toegang via HTTPS.
 
 Een andere prettige bijkomstigheid is dat HTTP een dusdanig veel voorkomend protocol is dat bedrijfsfirewalls vaak zo ingesteld zijn dat ze verkeer via deze poort toestaan.
 
 #### De nadelen ####
 
-Het nadeel van je repository verspreiden via HTTP is dat het relatief inefficiënt voor de client is. Over het algemeen duurt het een stuk langer om te clonen en te fetchen van de repository, en je hebt vaak een veel hogere netwerk belasting en transport volume via HTTP dan met elk van de andere netwerk protocollen. Omdat het niet zo ingewikkeld is om alleen de data te versturen die je nodig hebt – er wordt geen dynamisch werk door de server gedaan in deze uitwisselingen – wordt vaak naar het HTTP protocol gerefereerd als zijnde een _dom_ protocol. Voor meer informatie over de verschillen in efficiëntie tussen het HTTP protocol en andere protocollen, zie Hoofdstuk 9.
+Het nadeel van je repository verspreiden via HTTP is dat het relatief inefficiënt voor de client is. Over het algemeen duurt het een stuk langer om te clonen en te fetchen van de repository, en je hebt vaak een veel hogere netwerk belasting en transport volume via HTTP dan met elk van de andere netwerk protocollen. Omdat het niet zo slim is om eerst te bepalen van welke gegevens het nodig is te versturen – er wordt geen dynamisch werk door de server gedaan in deze uitwisselingen – wordt vaak naar het HTTP protocol gerefereerd als het _domme_ protocol. Voor meer informatie over de verschillen in efficiëntie tussen het HTTP protocol en andere protocollen, zie Hoofdstuk 9.
 
 ## Git op een server krijgen ##
 
 Om een Git server initieel op te zetten, moet je een bestaande repository naar een kale repository exporteren – een repository dat geen werkmap bevat. Dit is over het algemeen eenvoudig te doen.
-Om je repository te clonen met als doel het maken van een kale repository, voer je het clone commando uit met de `--bare` optie. Als conventie eindigen de namen van kale repository mappen met `.git`, zoals:
+Om je repository te clonen met als doel het maken van een kale repository, voer je het clone commando uit met de `--bare` optie. Als conventie eindigen de namen van kale repository mappen met `.git`, zoals hier:
 
 	$ git clone --bare my_project my_project.git
 	Initialized empty Git repository in /opt/projects/my_project.git/
 
-De uitvoer van dit commando is een beetje verwarrend. Omdat `clone` eigenlijk een `git init` en dan een `git fetch` is, zien we de uitvoer van het `git init` gedeelte, wat een lege map aanmaakt. De eigenlijke object overdracht geeft geen output, maar het gebeurt wel. Nu zou je een kopie van de Git map data in je `my_project.git` map moeten hebben.
+De output van dit commando is een beetje verwarrend. Het commando `clone` is eigenlijk een `git init` en dan een `git fetch`, wat we hier zien is de output van het `git init` gedeelte wat een lege map aanmaakt. De eigenlijke object overdracht geeft geen output, maar het gebeurt wel. Nu zou je een kopie van de Git map data in je `my_project.git` map moeten hebben.
 
 Dit is ongeveer gelijk aan
 
 	$ cp -Rf my_project/.git my_project.git
 
-Er zijn een paar kleine verschillen in het configuratie bestand, maar het komt op hetzelfde neer. Het neemt de Git repository zelf, zonder een werkmap, en maakt een map aan specifiek hiervoor.
+Er zijn een paar kleine verschillen in het configuratie bestand, maar het komt op hetzelfde neer. Het neemt de Git repository zelf, zonder een werkmap, en maakt een directory specifiek hiervoor aan.
 
 ### De Kale Repository op een Server Zetten ###
 
@@ -505,25 +505,27 @@ Als je problemen hebt, kan het handig zijn om `loglevel=DEBUG` onder de `[gitosi
 
 ## Gitolite ##
 
-Merk op: de laatste versie van deze paragraaf in het ProGit boek is altijd beschikbaar binnen de [gitolite documentation][gldpg]. De auteur geeft ook nederig aan dat, hoewel deze paragraaf accuraat is, het *kan* (en vaak ook *is*) gebruikt om gitolie te installeren zonder enige andere documentatie te lezen, dat het niet gegarandeerd compleet is, en het zeker niet de gehele enorme hoeveelheid documentatie kan vervangen dat meegeleverd wordt met gitolite.
+Merk op: de laatste versie van deze paragraaf in het ProGit boek is altijd beschikbaar binnen de [gitolite documentation][gldpg]. De auteur geeft ook nederig aan dat, hoewel deze paragraaf accuraat is, het *kan* (en vaak ook *is*) worden gebruikt om gitolite te installeren zonder enige andere documentatie te lezen, maar dat je er vanuit mag gaan dat het niet compleet is, en het zeker niet de gehele enorme hoeveelheid documentatie kan vervangen dat meegeleverd wordt met gitolite.
 
 [gldpg]: http://github.com/sitaramc/gitolite/blob/pu/doc/progit-article.mkd
 
-Git begint erg populair te worden in het bedrijfsleven, die de neiging hebben nog wat additionele eisen te hebben op het gebied van toegangscontrole. Gitolite was oorspronkelijk gemaakt om bij het vervullen van deze eisen te helpen, maar het blijkt dat het even bruikbaar is in de wereld van de open source: het Fedora Project beheert toegang tot hun package beheer repositories (meer dan 10.000 daarvan!) met gitolite, en het is waarschijnlijk daarbij ook nog eens de grootste gitolite installatie waar dan ook.
+Git begint erg populair te worden in het bedrijfsleven, die de neiging heeft nog wat additionele eisen te hebben op het gebied van toegangscontrole. Gitolite was oorspronkelijk gemaakt om bij het vervullen van deze eisen te helpen, maar het blijkt dat het even bruikbaar is in de wereld van de open source: het Fedora Project beheert toegang tot hun package beheer repositories (meer dan 10.000 daarvan!) met gitolite, en het is daarbij waarschijnlijk ook nog eens de grootste gitolite installatie waar dan ook.
 
 Gitolite stelt je in staat de permissies niet alleen per repository, maar ook per branch of tag naam binnen elke repository. Dus, je kunt aangeven dat bepaalde mensen (of groepen van mensen) alleen maar bepaalde "refs" (branches of tags) kunnen pushen maar niet andere.
 
 ### Installatie ###
 
-Het installeren van Gitolite is zeer eenvoudig, zelfs als je de uitgebreide documentatie, dat erbij geleverd wordt, niet leest. Je hebt een account op een Unix(achtige) server hebben; verschillende Linux smaken en Solaris 10 zijn getest. Je hebt geen root toegang nodig, aangenomen dat git, perl, en een openssh compatible ssh server al zijn geïnstalleerd. In de onderstaand voorbeelden zullen we het `gitolite` account gebruiken op een host genaamd `gitserver`.
+Het installeren van Gitolite is zeer eenvoudig, zelfs als je de uitgebreide documentatie, dat erbij geleverd wordt, niet leest. Je hebt een account op een Unix(achtige) server nodig; verschillende Linux smaken en Solaris 10 zijn getest. Je hebt geen root toegang nodig, aangenomen dat git, perl, en een openssh compatible ssh server al zijn geïnstalleerd. In de onderstaande voorbeelden zullen we het `gitolite` account gebruiken op een host genaamd `gitserver`.
 
-Gitolite is nogal ongebruikelijk in de zin van "server" software -- toegang gaat via ssh, en elke userid op de server is in potentie een "gitolite host". Het resultaat is, dat er een idee is van "installeren" van de software zelf, en dan het "opzetten" van een gebruiker als een "gitolist host".
+Gitolite is nogal ongebruikelijk in de zin van "server" software -- toegang gaat via ssh, en elke userid op de server is in potentie een "gitolite host". Met als gevolg dat er een notie is van "installeren" van de software zelf, en dan het "opzetten" van een gebruiker als een "gitolist host".
 
-Mensen zonder root toegang kunnen het installeren binnen hun eigen user id. Als laatste: gitlite kan geïnstalleerd worden door een script te starten *op het werkstation*, vanuit een bash-shell. (Zelfs de bash die meegeleverd wordt met msysgit volstaat, voor het geval je je dat afvroeg.)
+Gitolite heeft 4 wijzen van installeren. Mensen die Fedora of Debian systemen gebruiken kunnen een RPM of DEB ophalen en deze installeren. Mensen met root toegang kunnen het handmatig installeren. Met deze twee methoden kan elke gebruiker op het systeem een "gitolite host" worden.
+
+Mensen zonder root toegang kunnen het installeren binnen hun eigen user id. En als laatste: gitlite kan geïnstalleerd worden door een script te starten *op het werkstation*, vanuit een bash-shell. (Zelfs de bash die meegeleverd wordt met msysgit volstaat, voor het geval je je dat afvroeg.)
 
 We zullen dit laatste in dit stuk beschrijven, voor de overige methoden verwijzen we je naar de documentatie.
 
-Je begint met het verkrijgen van toegang op basis van een publieke sleutel, zodat je vanaf je werkstation op de server kan inloggen zonder het intypen van je wachtwoord. De volgende methode werkt op Linux; voor andere werkstation besturingssystemen moet je dit wellicht handmatig doen. We gaan er vanuit dat je al een sleutelpaar hebt gegenereerd met `ssh-keygen`.
+Je begint met het verkrijgen van toegang naar je server op basis van een publieke sleutel, zodat je vanaf je werkstation op de server kan inloggen zonder het intypen van je wachtwoord. De volgende methode werkt op Linux; voor andere werkstation besturingssystemen moet je dit wellicht handmatig doen. We gaan er vanuit dat je al een sleutelpaar hebt gegenereerd met `ssh-keygen`.
 
 	$ ssh-copy-id -i ~/.ssh/id_rsa gitolite@gitserver
 
@@ -538,11 +540,11 @@ Vervolgens, clone je Gitolite van de hoofdsite van het project en roept de "easy
 	$ cd gitolite/src
 	$ ./gl-easy-install -q gitolite gitserver sitaram
 
-En dat is het! Gitolite is nu geïnstalleerdop je server, en je hebt nu een gloednieuwe repository genaamd `gitolite-admin` in de home directory van jouw werkstation. Je beheert je gitolite setup door een wijziging aan te brengen in deze reporitory en deze te pushen.
+En dat is het! Gitolite is nu geïnstalleerd op je server, en je hebt nu een gloednieuwe repository genaamd `gitolite-admin` in de home directory van jouw werkstation. Je beheert je gitolite setup door een wijziging aan te brengen in deze reporitory en deze te pushen.
 
-Dat laatste commando produceert nogal een hoeveelheid uitvoer dat wellicht interessant is om te lezen. Ook wordt er, de eerste keer dat je het laat lopen, er een nieuwe sleutelpaar gemaakt; je moet een wachtwoord kiezen of Enter als je er geen wilt. Waarom een tweede sleutelpaar nodig is, en hoe deze wordt gebruikt, wordt uitgelegd in het "ssh troubleshooting" document dat bij Gitolite wordt meegeleverd. (Hey, de documentatie moet *ergens* goed voor zijn!)
+Dat laatste commando produceert redelijk wat uitvoer, dat wellicht interessant is om te lezen. Ook wordt er, de eerste keer dat je het commando laat lopen, er een nieuwe sleutelpaar gemaakt; je moet een wachtwoord kiezen of Enter als je er geen wilt. Waarom een tweede sleutelpaar nodig is, en hoe deze wordt gebruikt, wordt uitgelegd in het "ssh troubleshooting" document dat bij Gitolite wordt meegeleverd. (Hey, de documentatie moet *ergens* goed voor zijn!)
 
-Repositories genaamd `gitolite-admin` en `testing` worden standaard op de server aangemaakt. Als je een van beide lokaal wilt clonen (van een account die SSA console toegang heeft naar het gitolite account via *authorized_keys*) type je:
+Repositories genaamd `gitolite-admin` en `testing` worden standaard op de server aangemaakt. Als je een van beide lokaal wilt clonen (van een account die SSH console toegang heeft naar het gitolite account via *authorized_keys*) type je:
 
 	$ git clone gitolite:gitolite-admin
 	$ git clone gitolite:testing
@@ -558,7 +560,7 @@ Hoewel de standaard, snelle, installatie werkt voor de meeste mensen, zijn er ee
 
 ### Config bestand en Beheer van Toegangsregels ###
 
-Op het moment dat de installatie afgerond is, schakel je over naar de `gitolite-admin` repository (staat in je HOME directory) en begin je rond te snuffelen om te zien wat je daar hebt:
+Zodra de installatie afgerond is, schakel je over naar de `gitolite-admin` repository (die staat in je HOME directory) en begin je rond te snuffelen om te zien wat je daar hebt:
 
 	$ cd ~/gitolite-admin/
 	$ ls
@@ -580,7 +582,7 @@ Merk op dat "sitaram" (het laatste argument in het `gl-easy-install` commando da
 
 De syntax van het config bestand voor gitolite is ruimhartig van documentatie voorzien in `conf/example.conf`, dus we zullen alleen wat hoofdpunten benoemen.
 
-Je kunt voor het gemak gebruikers of repositories groeperen. De groepnamen zijn vergelijkbaar met macros; als je ze definieert maakt het niet uit of het projecten of gebruikers zijn, dat onderscheid wordt pas gemaakt als je de "macro" gaat *gebruiken*.
+Je kunt voor het gemak gebruikers of repositories groeperen. De groepnamen zijn vergelijkbaar met macros: als je ze definieert maakt het niet uit of het projecten of gebruikers zijn. Dat onderscheid wordt pas gemaakt als je de "macro" gaat *gebruiken*.
 
 	@oss_repos      = linux perl rakudo git gitolite
 	@secret_repos   = fenestra pear
@@ -598,9 +600,9 @@ Je kunt de permissies beheren op het "ref" niveau. In het volgende voorbeeld kun
 	    RW  refs/tags/rc[0-9]   = @engineers
 	    RW+                     = @admins
 
-De expressie achter de `RW` of `RW+` is een zgn. regular expression (regex) waartegen de refname (ref) die wordt gepushed wordt vergeleken. Dus we noemen het natuurlijk een "refex"! En natuurlijk kan een refex veel krachtiger zijn dan hier wordt getoond, dus ga het niet overdrijven als je niet al te goed in de perl regexen zit.
+De expressie achter de `RW` of `RW+` is een zgn. regular expression (regex) waartegen de refname (ref) die wordt gepushed wordt vergeleken. Dus we gaan we deze uiteraard een "refex" noemen! En natuurlijk kan een refex veel krachtiger zijn dan hier wordt getoond, dus ga het niet overdrijven als je niet al te goed in de perl regexen zit.
 
-Zoals je wellicht al geraden hebt, prefixed Gitolite `refs/heads/` als een syntactische handigheid als de refex niet begint met `refs/`.
+Zoals je wellicht al geraden hebt, gebruikt Gitolite de prefix `refs/heads/` als een syntactische handigheid indien de refex niet begint met `refs/`.
 
 Een belangrijke eigenschap van de syntax van het config bestand is dat alle regels van een repository niet op één plek hoeft te staan. Je kunt al het generieke spul bij elkaar houden, zoals de regels voor alle `oss_repos` zoals ze hier boven staan, en dan op een latere plaats specifieke regels voor specifieke gevallen, zoals hier:
 
@@ -611,13 +613,13 @@ Deze regel wordt gewoon toegevoegd aan de set met regels voor de `gitolite` repo
 
 Je zou je op dit punt kunnen afvragen hoe de toegangsregels eigenlijk worden toegepast, laten we dat kort behandelen.
 
-Er zijn twee niveaus van toegangsbeheer in gitolite. De eerste is op repository niveau. Als je lees (of schrijf)rechten hebt tot *enige* ref in de repository, dan heb je lees (of schrijf) rechten tot de repository.
+Er zijn twee niveaus van toegangsbeheer in gitolite. De eerste is op repository niveau. Als je lees- of schrijfrechten hebt tot *enige* ref in de repository, dan heb je lees (of schrijf) rechten tot de repository.
 
-Het tweede niveau, alleen van toepassing voor "schrijf" toegang, is per branch of tag binnen een repository. De gebruikersnaam, het type toegang wat wordt gevraagd (`W` of '+'), en de refname dat wordt gewijzigd (update) zijn bekend. De toegangsregels worden gecontroleerd in volgorde van voorkomst in het config bestand, en er wordt gekeken naar een treffer voor deze combinatie (maar onthoudt dat de refname middels een regex wordt vergeleken, niet een simpele string-vergelijking). Als er een treffer is, dan slaagt de push. Als er geen treffer wordt gevonden (fallthrough) dan wordt toegang geweigerd.
+Het tweede niveau, alleen van toepassing voor "schrijf" toegang, is per branch of tag binnen een repository. De gebruikersnaam, het type toegang wat wordt gevraagd (`W` of '+'), en de refname dat wordt gewijzigd (geüpdate) zijn bekend. De toegangsregels worden gecontroleerd in volgorde van voorkomst in het config bestand, en er wordt gekeken naar een treffer voor deze combinatie (maar onthoudt dat de refname middels een regex wordt vergeleken, niet een simpele string-vergelijking). Als er een treffer is, dan slaagt de push. Als er geen treffer wordt gevonden (fallthrough) dan wordt toegang geweigerd.
 
 ### Geavanceerde Toegangs Controle met "deny" regels ###
 
-Tot zover hebben we alleen permissies gezien uit het rijtje `R`, `RW` of `RW+`. Echter, gitolite kent een andere permissie: `-`, wat staat voor "deny" (ontken). Dit geeft je veel meer macht, tegen kosten van wat hogere complexiteit omdat een fallthrough nu niet de *enige* manier is waarop toegang kan worden geweigerd, wordt *de volgorde van regels belangrijk*!
+Tot zover hebben we alleen permissies gezien uit het rijtje `R`, `RW` of `RW+`. Echter, gitolite kent een andere permissie: `-`, wat staat voor "deny" (ontken). Dit geeft je veel meer macht, tegen kosten van wat hogere complexiteit omdat een fallthrough nu niet de *enige* manier is waarop toegang kan worden geweigerd; nu wordt *de volgorde van regels belangrijk*!
 
 Stel dat, in de onderstaande situatie, we de techneuten in staat willen stellen elke branch te laten terugdraaien *behalve* master en integ. Dit is de manier om dat te doen:
 
@@ -658,11 +660,11 @@ Gitolite laat je repositories specificeren met wildcards (eigenlijk perl regex e
 
 We ronden deze uiteenzetting af met een passe partout van andere eigenschappen, welke alle (en nog vele andere) tot in de kleinste detail zijn beschreven in de "faqs, tips, etc" en andere documenten.
 
-**Logging**: Gitolite logt alle succesvolle toegangspogingen. Als je wat te los bent geweest in het toekennen van terugdraai permissies (`RW+`) en een of andere nozem heeft "master" vernaggelt, is de log-file een redder in de nood in de zin van snel en eenvoudig achterhalen van de SHA die verdwenen is.
+**Logging**: Gitolite logt alle succesvolle toegangspogingen. Als je wat te los bent geweest in het toekennen van terugdraai permissies (`RW+`) en een of andere bijdehand heeft "master" vernaggelt, is de log-file een redder in de nood in de zin van snel en eenvoudig achterhalen van de SHA die verdwenen is.
 
-**Git buiten reguliere PATH**: Een ontzettend handige eigenschap in gitolite is het ondersteunen van git buiten het regulier `$PATH` (dit komt vaker voor dan je zou denken, sommige bedrijfs omgevingen of zelfs sommige hosting providers weigeren dingen systeem-breed te installeren en je eindigt ermee dat je ze in je eigen directories zet). Normaalgesproken ben je gedwongen git aan de *client-side* op de een of andere manier te vertellen van deze niet-standaard locatie van de git binaries. Met gitolite hoe je alleen een verbose installatie te kiezen en `$GIT_PATH` in de "rc" bestanden in te vullen. Hierna geen wijzigingen aan de kant van de clients nodig :-)
+**Git buiten reguliere PATH**: Een ontzettend handige eigenschap in gitolite is het ondersteunen van Git buiten het regulier `$PATH` (dit komt vaker voor dan je zou denken, sommige bedrijfs omgevingen of zelfs sommige hosting providers weigeren dingen systeem-breed te installeren en je eindigt ermee dat je ze in je eigen directories zet). Normaalgesproken ben je gedwongen Git aan de *client-side* op de een of andere manier te vertellen van deze niet-standaard locatie van de git binaries. Met gitolite hoe je alleen een verbose installatie te kiezen en `$GIT_PATH` in de "rc" bestanden in te vullen. Hierna geen wijzigingen aan de kant van de clients nodig :-)
 
-**Rapportage van toegangsrechten**: Nog zo'n handige eigenschap is wat er gebeurt als je gewoon met ssh naar de server gaat. Gitolite laat zien welke repositories je toegang toe hebt en welke soort toegang dat dan wel is. Hier is een voorbeeld:
+**Rapportage van toegangsrechten**: Nog zo'n handige eigenschap is wat er gebeurt als je gewoon met ssh naar de server gaat. Gitolite laat zien welke repositories je toegang toe hebt en welke soort toegang dat dan is. Hier is een voorbeeld:
 
         hello sitaram, the gitolite version here is v1.5.4-19-ga3397d4
         the gitolite config gives you the following access:
@@ -674,14 +676,15 @@ We ronden deze uiteenzetting af met een passe partout van andere eigenschappen,
              R     indic_web_input
              R     shreelipi_converter
 
-**Delegeren**: Voor extreem grote installaties kan je de verantwoordelijkheid voor groepen van repositories delegeren aan verschilllende mensen en hen het beheer van die delen onafhankelijk laten regelen. Dit vermindert de werkdruk van de hoofd-beheerder, en maakt van hem minder een faalpunt. Deze eigenschap heeft zijn eigen docuentatie bestand in de `doc/` directory.
+**Delegeren**: Voor extreem grote installaties kan je de verantwoordelijkheid voor groepen van repositories delegeren aan verschillende mensen en hen het beheer van die delen onafhankelijk laten regelen. Dit vermindert de werkdruk van de hoofd-beheerder, en maakt van hem minder een faalpunt. Deze eigenschap heeft zijn eigen documentatie in de `doc/` directory.
 
-**Gitweb ondersteuning**: Gitolite ondersteunt gitweb op verschillende manieren. Je kunt aangeven welke repositories zichtbaar zijn via gitweb. Je kunt de "owner" (eigenaar) en "description" (omschrijving) voor gitweb vanuit de gitolite configuratie bestanden definiëren. Gitweb heeft een mechanisme beschikbaar waarmee toegang via HTTP wordt geïmplementeerd, deze kan je het "gecompileerde" config bestand van de gitolite config file laten gebruiken, wat inhoudt dat gitweb en gitolite dezelfde toegangsregels gebruikt (voor lees toegang).
+**Gitweb ondersteuning**: Gitolite ondersteunt gitweb op verschillende manieren. Je kunt aangeven welke repositories zichtbaar zijn via gitweb. Je kunt de "owner" (eigenaar) en "description" (omschrijving) voor gitweb vanuit de gitolite configuratie bestanden definiëren. Gitweb heeft een mechanisme beschikbaar waarmee toegang via HTTP wordt geïmplementeerd, deze kan je het "gecompileerde" config bestand van de gitolite config file laten gebruiken, wat inhoudt dat gitweb en gitolite dezelfde toegangsregels gebruiken (voor lees toegang).
 
+**Mirroring**: Gitolite kan je ondersteunen bij het beheren van meerdere mirrors, en het eenvoudig daartussen overschakelen als de primaire server uitvalt.
 
 ## Git daemon ##
 
-Voor publieke ongeauthenticeerde leestoegang tot je projecten zul je het HTTP protocol achter je willen laten, en overstappen op het Git protocol. De belangrijkste reden is snelheid. Het Git protocol is veel efficiënter en daarmee sneller dan het HTTP protocol, dus het zal je gebruikstijd besparen.
+Voor publieke ongeauthenticeerde leestoegang tot je projecten zul je het HTTP protocol achter je willen laten, en overstappen op het Git protocol. De belangrijkste reden is snelheid. Het Git protocol is veel efficiënter en daarmee sneller dan het HTTP protocol, dus het zal je gebruikers tijd besparen.
 
 Nogmaals, dit is voor ongeauthenticeerde alleen-lezen toegang. Als je dit op een server buiten je firewall draait, zul je het alleen moeten gebruiken voor projecten die voor de hele wereld toegankelijk moeten zijn. Als de server waarop je het draait binnen je firewall staat, zou je het kunnen gebruiken voor projecten waarbij een groot aantal mensen of computers (continue integratie of bouwservers) alleen-lezen toegang moeten hebben, waarbij je niet voor iedereen een SSH sleutel wilt toevoegen.
 
@@ -706,7 +709,7 @@ stop je dit script:
 	    /opt/git/
 	respawn
 
-Omwille van veiligheidsredenen, wordt sterk aangeraden om deze daemon uit te voeren als gebruiker met alleen-lezen toegang op de repositories — je kunt dit makkelijk doen door een gebruiker 'git-ro' aan te maken en de daemon als deze uit te voeren. Om het eenvoudig te houden voeren we het als dezelfde 'git' gebruiker uit, als waarin Gitosis draait.
+Omwille van veiligheidsredenen, wordt sterk aangeraden om deze daemon uit te voeren als gebruiker met alleen-lezen toegang op de repositories – je kunt dit makkelijk doen door een nieuwe gebruiker 'git-ro' aan te maken en de daemon als deze uit te voeren. Om het eenvoudig te houden voeren we het als dezelfde 'git' gebruiker uit, als waarin Gitosis draait.
 
 Als je de machine herstart, zal de Git daemon automatisch opstarten en herstarten als de server onderuit gaat. Om het te laten draaien zonder te herstarten, kun je dit uitvoeren:
 
@@ -726,7 +729,7 @@ Als je besluit om Gitosis niet te gebruiken, maar je wilt toch een Git daemon in
 	$ cd /path/to/project.git
 	$ touch git-daemon-export-ok
 
-De aanwezigheid van dat bestand vertelt Git dat het OK is om dit project zonder verificatie te serveren.
+De aanwezigheid van dat bestand vertelt Git dat het OK is om dit project zonder authenticatie te serveren.
 
 Gitosis kan ook de projecten die GitWeb toont beheren. Eerst moet je zoiets als het volgende aan het `/etc/gitweb.conf` bestand toevoegen:
 
@@ -741,40 +744,40 @@ Je kunt instellen welke projecten GitWeb gebruikers laat bladeren door een `gitw
 	daemon = yes
 	gitweb = yes
 
-Als je nu het project commit en pusht, start GitWeb automatisch met het tonen van je iphone project.
+Als je nu het project commit en pushed, begint GitWeb automatisch je iphone project te tonen.
 
 ## Hosted Git ##
 
-Als je niet al het werk wilt doen om je eigen Git server op te zetten, heb je meerdere opties om je Git project op een externe speciale hosting pagina te laten beheren. Dit biedt een aantal voordelen: een ge-hoste pagina is over het algemeen snel in te stellen, eenvoudig om projecten mee op te starten, en er komt geen serverbeheer en -onderhoud bij kijken. Zelfs als je je eigen server intern ingesteld hebt, zul je misschien een publieke host pagina voor je open source broncode willen – dat is over het algemeen makkelijker voor de open source commune te vinden en je er mee te helpen.
+Als je niet al het werk wilt doen om je eigen Git server op te zetten, heb je meerdere opties om je Git project op een externe speciale hosting pagina te laten beheren. Dit biedt een aantal voordelen: een ge-hoste pagina is over het algemeen snel in te stellen, eenvoudig om projecten mee op te starten, en er komt geen serverbeheer en -onderhoud bij kijken. Zelfs als je je eigen server intern opgezet hebt, zul je misschien een publieke host pagina voor je open source broncode willen – dat is over het algemeen makkelijker voor de open source commune te vinden en je er mee te helpen.
 
 Vandaag de dag heb je een enorm aantal beheer opties om uit te kiezen, elk met verschillende voor- en nadelen. Om een recente lijst te zien, ga dan kijken op de volgende pagina :
 
 	https://git.wiki.kernel.org/index.php/GitHosting
 
-Omdat we ze niet allemaal kunnen behandelen, en ik toevallig bij een ervan werk, zullen we deze paragraaf gebruiken het instellen van een account en het opzetten van een project op GitHub te doorlopen. Dit geeft je een idee van het benodigde werk.
+Omdat we ze niet allemaal kunnen behandelen, en omdat ik toevallig bij een ervan werk, zullen we deze paragraaf gebruiken het instellen van een account en het opzetten van een project op GitHub te doorlopen. Dit geeft je een idee van het benodigde werk.
 
-GitHub is veruit de grootste open source Git beheer pagina en het is ook een van de weinige die zowel publieke als privé beheer opties biedt, zodat je je open source en commerciele privé code op dezelfde plaats kunt bewaren. Sterker nog, we hebben GitHub gebruikt om privé samen te werken aan dit boek.
+GitHub is verreweg de grootste open source Git beheer site en het is ook een van de weinige die zowel publieke als privé hosting opties biedt, zodat je je open source en commerciële privé code op dezelfde plaats kunt bewaren. Als voorbeeld: we hebben GitHub gebruikt om privé samen te werken aan dit boek.
 
 ### GitHub ###
 
-GitHub verschilt een beetje van de meeste code-beheer pagina's in de manier waarop het de projecten een naamruimte geeft. In plaats dat het primair gebaseerd is op het project, stelt GitHub gebruikers centraal. Dat betekent dat als ik mijn `grit` project op GitHub beheer, je het niet zult vinden op `github.com/grit` maar in plaats daarvan op `github.com/schacon/grit`. Er is geen generieke versie van een project, wat een project toestaat om naadloos van de ene op de andere gebruiker over te gaan als de eerste auteur het project verlaat.
+GitHub verschilt een beetje van de meeste code-beheer pagina's in de manier waarop het de projecten een benoemt. In plaats dat het primair gebaseerd is op het project, stelt GitHub gebruikers centraal. Dat betekent dat als ik mijn `grit` project op GitHub beheer, je het niet zult vinden op `github.com/grit` maar in plaats daarvan op `github.com/schacon/grit`. Er is geen allesoverheersende versie van een project, wat een project in staat stelt om naadloos van de ene op de andere gebruiker over te gaan als de eerste auteur het project verlaat.
 
-GitHub is ook een commercieel bedrijf dat geld vraagt voor accounts die privé repositories beheren, maar iedereen kan snel een gratis account krijgen om zoveel open source projecten als ze willen te beheren. We zullen er snel doorheen lopen hoe je dat doet.
+GitHub is ook een commercieel bedrijf dat geld vraagt voor accounts die privé repositories beheren, maar iedereen kan snel een gratis account krijgen om net zoveel open source projecten te beheren als ze willen. We zullen er snel doorheen lopen hoe je dat doet.
 
 ### Een gebruikersaccount instellen ###
 
-Het eerste dat je moet doen is een gratis gebruikersaccount instellen. Als je de Pricing and Signup pagina op `http://github.com/plans` bezoekt en de "Sign Up" knop aanklikt op het gratis account (zie figuur 4-2), dan wordt je naar de inteken pagina gebracht.
+Het eerste dat je moet doen is een gratis gebruikers account aanvragen. Als je de Pricing and Signup pagina op `http://github.com/plans` bezoekt en de "Sign Up" knop aanklikt op het Free account (zie figuur 4-2), dan wordt je naar de inteken pagina gebracht.
 
 Insert 18333fig0402.png
-Figuur 4-2. De GitHub inteken pagina.
+Figuur 4-2. De GitHub plan pagina.
 
-Hier moet je een gebruikersnaam kiezen die nog niet bezet is in het systeem, en een e-mail adres invullen dat bij het account hoort, en een wachtwoord (zie Figuur 4-3).
+Hier moet je een gebruikersnaam kiezen die nog niet gebruikt is in het systeem, en een e-mail adres invullen dat bij het account hoort, en een wachtwoord (zie Figuur 4-3).
 
 Insert 18333fig0403.png
 Figuur 4-3. Het GitHub gebruikers inteken formulier.
 
-Als je het beschikbaar hebt, is dit een goed moment om je publieke SSH sleutel ook toe te voegen. We hebben je eerder laten zien hoe je een nieuwe sleutel kunt genereren, in de "Eenvoudige Instellingen" sectie. Neem de inhoud van de publieke sleutel van dat paar, en plak het in het SSH publieke sleutel tekstveld. Door op de "explain ssh keys" link te klikken wordt je naar gedetailleerde instructies gebracht die je vertellen hoe dit te doen op alle veelgebruikte besturingssystemen.
-Door op de "I agree, sign me up" knop te klikken wordt je naar je nieuwe gebruikers dashboard gebracht (zie Figuur 4-4).
+Als je account beschikbaar is, is dit een goed moment om je publieke SSH sleutel ook toe te voegen. We hebben het genereren van een nieuwe sleutel eerder behandeld, in de "Je Publieke SSH Sleutel Genereren" paragraaf. Neem de inhoud van de publieke sleutel van dat paar, en plak het in het SSH publieke sleutel tekstveld. Door op de "explain ssh keys" link te klikken wordt je naar gedetaileerde instructies gebracht die je vertellen hoe dit te doen op alle veelvoorkomende besturingssystemen.
+Door op de "I agree, sign me up" knop te klikken wordt je naar het dashboard van je nieuwe gebruikers gebracht (zie Figuur 4-4).
 
 Insert 18333fig0404.png
 Figuur 4-4. Het GitHub gebruikers dashboard.
@@ -788,7 +791,7 @@ Start door op de "create a new one" link te klikken naast Your Repositories op h
 Insert 18333fig0405.png
 Figuur 4-5. Een nieuw repository aanmaken op GitHub.
 
-Het enige dat je eigenlijk moet doen is een projectnaam opgeven, maar je kunt ook een beschrijving toevoegen. Wanneer je dat gedaan hebt, klik dan op de "Create Repository" knop. Nu heb je een nieuw repository op GitHub (zie Figuur 4-6).
+Het enige dat je eigenlijk moet doen is een projectnaam opgeven, maar je kunt ook een beschrijving toevoegen. Wanneer je dat gedaan hebt, klik je op de "Create Repository" knop. Nu heb je een nieuw repository op GitHub (zie Figuur 4-6).
 
 Insert 18333fig0406.png
 Figuur 4-6. GitHub project hoofd informatie.
@@ -809,14 +812,14 @@ Als je een lokaal Git repository hebt, voeg dan GitHub als remote toe en push je
 	$ git remote add origin git@github.com:testinguser/iphone_project.git
 	$ git push origin master
 
-Nu wordt je project beheerd op GitHub, en kun je de URL aan iedereen geven waarmee je je project wilt delen. In dit geval is het `http://githup.com/testinguser/iphone_project`. Je kunt aan het begin van ieder van je project pagina's zien dat je twee Git URLs hebt (zie Figuur 4-8).
+Nu wordt je project beheerd op GitHub, en kun je de URL aan iedereen geven waarmee je je project wilt delen. In dit geval is het `http://githup.com/testinguser/iphone_project`. Je kunt aan het begin van elk van je project pagina's zien dat je twee Git URLs hebt (zie Figuur 4-8).
 
 Insert 18333fig0408.png
 Figuur 4-8. Project met een publieke URL en een privé URL.
 
-De publieke Clone URL is een publieke alleen-lezen Git URL, waarmee iedereen het project kan klonen. Deel deze URL maar gewoon uit en zet 'm op je website of wat je ook hebt.
+De Public Clone URL is een publieke alleen-lezen Git URL, waarmee iedereen het project kan clonen. Deel deze URL door 'm op je website neer te zetten of welke manier dan ook.
 
-De Your Clone URL is een lees/schrijf SSH-gebaseerde URL waar je alleen over kunt lezen of schrijven als je connectie maakt met de privé SSH sleutel die geassocieerd is met de publieke sleutel die je voor jouw gebruiker geüpload hebt. Wanneer andere gebruikers deze project pagina bezoeken, zullen ze die URL niet zien — alleen de publieke.
+De Your Clone URL is een lees/schrijf SSH-gebaseerde URL waar je alleen over kunt lezen of schrijven als je connectie maakt met de privé SSH sleutel die geassocieerd is met de publieke sleutel die je voor jouw gebruiker geüpload hebt. Wanneer andere gebruikers deze project pagina bezoeken, zullen ze die URL niet zien – alleen de publieke.
 
 ### Importeren vanuit Subversion ###
 
@@ -831,12 +834,12 @@ Als je project erg groot is, niet standaard, of privé, dan zal dit proces waars
 
 Laten we de rest van het team toevoegen. Als John, Josie en Jessica allemaal intekenen voor accounts op GitHub, en je wilt ze push toegang op je repository geven, kun je ze aan je project toevoegen als medewerkers. Door dat te doen zullen pushes vanaf hun publieke sleutels werken.
 
-Klik de "edit" knop aan de bovenkant van het project, of de Admin tab, om de Admin pagina te bereiken van je GitHub project (zie Figuur 4-10).
+Klik de "edit" knop of de Admin tab aan de bovenkant van het project, om de Admin pagina te bereiken van je GitHub project (zie Figuur 4-10).
 
 Insert 18333fig0410.png
 Figuur 4-10. GitHub administratie pagina.
 
-Om een andere gebruiker schrijftoegang tot je project te geven, klik dan de "Add another collaborator" link. Er verschijnt een nieuw tekstveld, waarin je een gebruikersnaam kunt invullen. Op het moment dat je typt, komt er een hulp omhoog, waarin alle mogelijke overeenkomende gebruikersnamen staan. Als je de juiste gebruiker vind, klik dan de Add knop om die gebruiker als een medewerker aan je project toe te voegen (zie Figuur 4-11).
+Om een andere gebruiker schrijftoegang tot je project te geven, klik dan de "Add another collaborator" link. Er verschijnt een nieuw tekstveld, waarin je een gebruikersnaam kunt invullen. Op het moment dat je typt, komt er een hulp tevoorschijn, waarin alle mogelijke overeenkomende gebruikersnamen staan. Als je de juiste gebruiker vindt, klik dan de Add knop om die gebruiker als een medewerker aan je project toe te voegen (zie Figuur 4-11). 
 
 Insert 18333fig0411.png
 Figuur 4-11. Een medewerker aan je project toevoegen.
@@ -846,16 +849,16 @@ Als je klaar bent met medewerkers toevoegen, dan zou je een lijst met de namen m
 Insert 18333fig0412.png
 Figuur 4-12. Een lijst met medewerkers aan je project.
 
-Als je toegang van individuen moet intrekken, dan kun je de "revoke" link klikken, en dan wordt hun push toegang ingetrokken. Voor toekomstige projecten, kun je ook de medewerker groepen kopiëren door de permissies van een bestaand project te kopiëren.
+Als je toegang van individuen moet intrekken, dan kun je de "revoke" link klikken, en dan wordt hun push toegang ingetrokken. Voor toekomstige projecten, kun je ook groepen medewerker kopiëren door de permissies van een bestaand project te kopiëren.
 
 ### Je project ###
 
-Nadat je je project gepusht hebt, of geïmporteerd vanuit Subversion, heb je een hoofd project pagina die er uitziet zoals Figuur 4-13.
+Nadat je je project gepushed hebt, of geïmporteerd vanuit Subversion, heb je een hoofd project pagina die er uitziet zoals Figuur 4-13.
 
 Insert 18333fig0413.png
 Figuur 4-13. Een GitHub project hoofdpagina.
 
-Als mensen je project bezoeken, zien ze deze pagina. Het bevat tabs naar de verschillende aspecten van je projecten. De Commits tab laat een lijst van commits in omgekeerde chronologische volgorde zien, vergelijkbaar met de output van het `git log` commando. De Network tab toont alle mensen die je project hebben geforked en bijgedragen hebben. De Downloads tab staat je toe project binaries te uploaden en naar tarballs en gezipte versies van ieder getagged punt in je project te linken. De Wiki tab voorziet in een wiki waar je documentatie kunt schrijven of andere informatie over je project. De Graphs tab heeft wat contributie visualisaties en statistieken over je project. De hoofd Source tab waarop je binnen komt toont de inhoud van de hoofdmap van je project en toont automatisch het README bestand eronder als je er een hebt. Deze tab toont ook een veld met de laatste commit informatie.
+Als mensen je project bezoeken, zien ze deze pagina. Het bevat tabs naar de verschillende aspecten van je projecten. De Commits tab laat een lijst van commits in omgekeerde chronologische volgorde zien, vergelijkbaar met de output van het `git log` commando. De Network tab toont alle mensen die je project hebben geforked en bijgedragen hebben. De Downloads tab staat je toe project binaries te uploaden en naar tarballs en gezipte versies van ieder getagged punt in je project te linken. De Wiki tab voorziet in een wiki waar je documentatie kunt schrijven of andere informatie over je project. De Graphs tab heeft wat contributie visualisaties en statistieken over je project. De hoofd Source tab waarop je binnen komt, toont de inhoud van de hoofdmap van je project en toont automatisch het README bestand eronder als je er een hebt. Deze tab toont ook een veld met de laatste commit informatie.
 
 ### Projecten forken ###
 
@@ -881,6 +884,6 @@ Dat is alles wat we laten zien over GitHub, maar het is belangrijk om te zien ho
 
 Je hebt meerdere opties om een remote Git repository werkend te krijgen zodat je kunt samenwerken met anderen of je werk kunt delen.
 
-Je eigen server draaien geeft je veel controle en staat je toe om de server binnen je firewall te draaien, maar zo'n server vraagt over het algemeen een redelijke hoeveelheid tijd om in te stellen en te onderhouden. Als je je gegevens op een beheerde server plaatst, is het eenvoudig in te stellen en te onderhouden; maar je moet in staat zijn je code op iemand anders zijn servers te bewaren, en sommige organisaties staan dit niet toe.
+Je eigen server draaien geeft je veel controle en stelt je in staat om de server binnen je firewall te draaien, maar zo'n server vraagt over het algemeen een redelijke hoeveelheid tijd om in te stellen en te onderhouden. Als je je gegevens op een beheerde server plaatst, is het eenvoudig in te stellen en te onderhouden; maar je moet wel willen dat je code op de server van een derde opgeslagen is, en sommige organisaties staan dit niet toe.
 
 Het zou redelijk rechttoe rechtaan moeten zijn om te bepalen welke oplossing of combinatie van oplossingen van toepassing is op jou en je organisatie.

From 96d030d23684ce1c859370e55922eb36ea955f62 Mon Sep 17 00:00:00 2001
From: Cor <cor.takken@cgi.com>
Date: Tue, 21 Jan 2014 09:48:13 +0100
Subject: [PATCH 127/690] [nl] Revised earlier Dutch translation

Modified certain sentences and wordchoises to be (hopefully) more
consistent with actual use of jargon in Dutch.
---
 nl/01-introduction/01-chapter1.markdown | 96 ++++++++++++-------------
 1 file changed, 48 insertions(+), 48 deletions(-)

diff --git a/nl/01-introduction/01-chapter1.markdown b/nl/01-introduction/01-chapter1.markdown
index fc13ff83a..34f5eaab6 100644
--- a/nl/01-introduction/01-chapter1.markdown
+++ b/nl/01-introduction/01-chapter1.markdown
@@ -4,58 +4,58 @@ Dit hoofdstuk legt uit je hoe je aan de slag kunt gaan met Git.  We zullen bij h
 
 ## Het wat en waarom van versiebeheer ##
 
-Wat is versiebeheer? En wat heeft dat met jou te maken? Versiebeheer is een systeem dat veranderingen in een bestand of groep van bestanden over de tijd bijhoudt. Zodat je later specifieke versies kan opvragen. In de voorbeelden in dit boek is het broncode van computersoftware waarvan de versies beheerd worden maar je kan het eigenlijk met zo goed als elk soort bestand op een computer doen.
+Wat is versiebeheer? En wat heeft dat met jou te maken? Versiebeheer is een systeem dat veranderingen in een bestand of groep van bestanden over de tijd bijhoudt, zodat je later specifieke versies kan opvragen. In de voorbeelden in dit boek is het broncode van computersoftware waarvan de versies beheerd worden maar je kan het eigenlijk met zo goed als elk soort bestand op een computer doen.
 
-Als je een grafisch ontwerper bent of websites maakt en elke versie van een afbeelding of opmaak wilt bewaren (wat je zeker zou willen), is het verstandig een versiebeheersysteem (Version Control System in het Engels, afgekort tot VCS) te gebruiken. Als je dat gebruikt kan je eerdere versies van bestanden of hele project terughalen, veranderingen tussen twee momententen in tijd bekijken, zien wie het laatst iets aangepast heeft, wie een probleen heeft veroorzaakt en wanneer en nog veel meer. Een VCS gebruiken betekent meestal ook dat je de situatie gemakkelijk terug kan draaien als je een fout maakt of bestanden kwijtraakt. Daarbij komt nog dat dit allemaal heel weinig extra belasting met zich mee brengt.
+Als je een grafisch ontwerper bent of websites maakt en elke versie van een afbeelding of opmaak wilt bewaren (wat je vrijwel zeker zult willen), is het verstandig een versiebeheersysteem (Version Control System in het Engels, afgekort tot VCS) te gebruiken. Als je dat gebruikt kan je eerdere versies van bestanden of hele project terughalen, veranderingen tussen twee momententen in tijd bekijken, zien wie het laatst iets aangepast heeft dat een probleem zou kunnen veroorzaken, wie een probleen heeft veroorzaakt en wanneer en nog veel meer. Een VCS gebruiken betekent meestal ook dat je de situatie gemakkelijk terug kan draaien als je een fout maakt of bestanden kwijtraakt. Daarbij komt nog dat dit allemaal heel weinig extra belasting met zich mee brengt.
 
 ### Lokale versiebeheersystemen ###
 
-Veel mensen hebben hun eigen versiebeheer methode: ze kopiëren bestanden naar een andere map (en als ze slim zijn, geven ze die map ook een datum). Deze methode wordt veel gebruikt omdat het zo simpel is, maar het is ook ongelofelijk foutgevoelig. Het is makkelijk te vergeten in welke map je zit en naar het verkeerde bestand te schrijven, of over bestanden heen te kopiëren waar je dat niet wilde.
+Veel mensen hebben hun eigen versiebeheer methode: ze kopiëren bestanden naar een andere map (en als ze slim zijn, geven ze die map ook een datum). Deze methode wordt veel gebruikt omdat het zo simpel is, maar het is ook ongelofelijk foutgevoelig. Het is makkelijk te vergeten in welke map je zit en naar het verkeerde bestand te schrijven, of onbedoeld over bestanden heen te kopiëren.
 
-Om met dit probleem om te gaan hebben programmeurs lang geleden lokale VCSen ontwikkeld die een simpele database hadden om alle veranderingen aan bestanden te beheren (zie Figuur 1-1).
+Om met dit probleem om te gaan hebben programmeurs lang geleden lokale VCSen ontwikkeld die een simpele database gebruikten om alle veranderingen aan bestanden te beheren (zie Figuur 1-1).
 
 Insert 18333fig0101.png 
 Figuur 1-1. Een diagram van een lokaal versiebeheersysteem.
 
-Een populair gereedschap voor VCS was een systeem genaamd rcs, wat vandaag de dag nog steeds met veel computers wordt mee geleverd. Zelfs het populaire besturingssysteem Mac OS X heeft rcs, als je de Developer Tools installeert. Dit gereedschap werkt in principe door verzamelingen van ‘patches’ (de verschillen tussen bestanden) van de opvolgende bestandsversies in een speciaal formaat op de harde schijf op te slaan; zo kan je teruggaan naar hoe een bestand er uitzag op ieder willekeurig moment in tijd, door alle patches bij elkaar op te tellen.
+Een populair gereedschap voor VCS was een systeem genaamd rcs, wat vandaag de dag nog steeds met veel computers wordt mee geleverd. Zelfs het populaire besturingssysteem Mac OS X heeft rcs als je de Developer Tools installeert. Dit gereedschap werkt in principe door verzamelingen van ‘patches’ (de verschillen tussen bestanden) van de opvolgende bestandsversies in een speciaal formaat op de harde schijf op te slaan. Zo kan je teruggaan naar hoe een bestand er uitzag op ieder willekeurig moment in tijd, door alle patches bij elkaar op te tellen.
 
 ### Gecentraliseerde versiebeheersystemen ###
 
-Het volgende grote probleem waar mensen tegenaan lopen is dat ze samen moeten werken met ontwikkelaars op andere computers. Om dit probleem op te lossen ontwikkelde men Gecentraliseerde Versiebeheersystemen (CVCSen). Deze systemen, zoals CVS, Subversion en Perforce, hebben één centrale server waarop alle versies van de bestanden staan en een aantal clients die de bestanden daar van halen (‘check out’, in het Engels). Vele jaren was dit de standaard voor versiebeheer (zie Figuur 1-2).
+De volgende belangrijke uitdaging waar mensen tegenaan lopen is dat ze samen moeten werken met ontwikkelaars op andere computers. Om deze uitdaging te overkomen ontwikkelde men Gecentraliseerde Versiebeheersystemen (CVCSen). Deze systemen, zoals CVS, Subversion en Perforce, hebben één centrale server waarop alle versies van de bestanden staan en een aantal clients die de bestanden daar van halen (‘check out’, in het Engels). Vele jaren was dit de standaard voor versiebeheer (zie Figuur 1-2).
 
 Insert 18333fig0102.png 
 Figuur 1-2. Een diagram van een gecentraliseerd versiebeheersysteem.
 
-Deze manier van versiebeheer biedt veel voordelen, vooral als je het vergelijkt met lokale VCSen. Bijvoorbeeld, iedereen weet tot op zekere hoogte wat de overige project-medewerkers aan het doen zijn. Beheerders hebben precieze controle over wie wat kan doen; en het is veel eenvoudiger om een CVCS te beheren dan te moeten werken met lokale databases voor elke client.
+Deze manier van versiebeheer biedt veel voordelen, vooral als je het vergelijkt met lokale VCSen. Bijvoorbeeld, iedereen weet tot op zekere hoogte wat de overige project-medewerkers aan het doen zijn. Beheerders hebben een hoge mate van controle over wie wat kan doen, en het is veel eenvoudiger om een CVCS te beheren dan te moeten werken met lokale databases op elke client.
 
 Maar helaas, deze methode heeft ook behoorlijke nadelen. De duidelijkste is de ‘single point of failure’: als de centrale server plat gaat en een uur later weer terug online komt kan niemand in dat uur samenwerken of versies bewaren van de dingen waar ze aan werken. Als de harde schrijf waar de centrale database op staat corrupt raakt en er geen backups van zijn verlies je echt alles — de hele geschiedenis van het project, behalve de momentopnames die mensen op hun eigen computers hebben staan. Lokale VCSen hebben hetzelfde probleem — als je de hele geschiedenis van het project op één enkele plaats bewaart, loop je ook kans alles te verliezen.
 
 ### Gedistribueerde versiebeheersystemen ###
 
-En hier verschijnen Gedistribueerde versiebeheersystemen (DVCSen) ten tonele. In een DVCS (zoals Git, Mercurial, Bazaar en Darcs) downloaden clients niet alleen de laatste momentopnames van de bestanden. De hele geschiedenis (de ‘repository’) wordt gekopiëerd. Dus als een server neergaat en deze systemen werkten via die server samen dan kan de repository van elke willekeurige client terug worden gekopiëerd naar de server om deze te herstellen. Elke checkout is dus eigenlijk een complete backup van alle data (zie Figuur 1-3).
+En hier verschijnen Gedistribueerde versiebeheersystemen (DVCSen) ten tonele. In een DVCS (zoals Git, Mercurial, Bazaar en Darcs) downloaden clients niet simpelweg de laatste momentopnames van de bestanden. De hele geschiedenis (de ‘repository’) wordt gekopiëerd. Dus als een server neergaat en deze systemen werkten via die server samen dan kan de repository van elke willekeurige client terug worden gekopiëerd naar de server om deze te herstellen. Elke checkout is dus eigenlijk een complete backup van alle data (zie Figuur 1-3).
 
 Insert 18333fig0103.png 
 Figuur 1-3. Diagram van een gedistribueerd versiebeheersysteem
 
 Bovendien werken veel van deze systemen behoorlijk goed met meerdere (niet-lokale) repositories tegelijk zodat je met verschillende groepen mensen op verschillende manieren tegelijk aan hetzelfde project kan werken. Hierdoor kan je verschillende werkprocessen (‘workflows’) opzetten die niet mogelijk waren geweest met gecentraliseerde systemen zoals hiërarchische modellen. 
 
-## Een kleine geschiedenis van Git ##
+## Een kort historisch overzicht van Git ##
 
-Zoals zoveel goede dingen in het leven begon Git met een beetje creatieve destructie en een hoogoplopende controverse. De Linuxkernel is een open source softwareproject met een behoorlijk groot draagvlak. In het kader van het onderhoud van de Linuxkernel (1991–2002), werden aanpassingen aan de software voornamelijk verspreid via patches en gearchiveerde bestanden. In 2002 veranderde dat want vanaf dat jaar begon het project het gesloten DVCS genaamd BitKeeper te gebruiken.
+Zoals zoveel goede dingen in het leven begon Git met een beetje creatieve destructie en een hoogoplopende controverse. De Linuxkernel is een open source softwareproject met een behoorlijk groot toepassingsgebied. In het kader van het onderhoud van de Linuxkernel (1991–2002), werden aanpassingen aan de software voornamelijk verspreid via patches en gearchiveerde bestanden. In 2002 veranderde dat want vanaf dat jaar begon het project een gesloten DVCS genaamd BitKeeper te gebruiken.
 
-In 2005 viel de relatie tussen de gemeenschap die de Linuxkernel ontwikkelde en het commerciële bedrijf dat BitKeeper maakte uiteen. Het programma kon niet langer meer gratis worden gebruikt. Dit was de aanleiding voor de gemeenschap (en Linus Torvalds, de maker van Linux, in het bijzonder) om hun eigen gereedschap te ontwikkelen. Gebaseerd op de ervaring die opgedaan was toen ze nog BitKeeper gebruikten. Een paar van de doelen die ze hadden voor het nieuwe systeem waren als volgt:
+In 2005 viel de relatie tussen de gemeenschap die de Linuxkernel ontwikkelde en het commerciële bedrijf dat BitKeeper maakte uiteen, en het programma kon niet langer meer gratis worden gebruikt. Dit was de aanleiding voor de gemeenschap (en Linus Torvalds, de maker van Linux, in het bijzonder) om hun eigen gereedschap te ontwikkelen. Gebaseerd op de ervaring die opgedaan was toen ze nog BitKeeper gebruikten. Een paar van de doelen die ze hadden voor het nieuwe systeem waren als volgt:
 
 *	Snelheid
 *	Eenvoudig ontwerp
-*	Goede ondersteuning voor niet-lineaire ontwikkeling (duizenden aparte takken tegelijk)
+*	Goede ondersteuning voor niet-lineaire ontwikkeling (duizenden parallelle takken (branches) )
 *	Volledig gedistribueerd
 *	In staat om efficiënt om te gaan met grote projecten als de Linuxkernel (voor wat betreft snelheid maar ook opslagruimte)
 
-Sinds het ontstaan in 2005 is Git gegroeid tot zijn huidige vorm: het is eenvoudig te gebruiken en heeft toch die oorspronkelijke eigenschappen behouden. Het is ongelofelijk snel, enorm efficiënt met grote projecten en zijn systeem voor aparte takken (‘branches’) van niet-lineaire ontwikkeling is ongeëvenaard (zie Hoofdstuk 3).
+Sinds het ontstaan in 2005 is Git gegroeid tot zijn huidige vorm: het is eenvoudig te gebruiken en heeft toch die oorspronkelijke eigenschappen behouden. Het is ongelofelijk snel, enorm efficiënt met grote projecten en een ongeëvenaard systeem van branches voor het ondersteunen van niet-lineaire ontwikkeling (zie Hoofdstuk 3).
 
 ## De basis van Git ##
 
-Dus, wat is Git in een notendop? Dit is een belangrijk deelhoofdstuk, omdat het waarschijnlijk een stuk makkelijker wordt om Git effectief te gebruiken als je goed begrijpt wat Git is en hoe het werkt. Probeer te vergeten wat je al weet over andere VCSen zoals Subversion en Perforce als je Git aan het leren bent; zo kan je verwarring door de subtiele verschillen voorkomen. Git gaat op een hele andere manier met informatie om dan die andere systemen, ook al lijken de verschillende commando’s behoorlijk op elkaar. Als je die verschillen begrijpt, kan je voorkomen dat je verward raakt als je Git gebruikt.
+Dus, wat is Git in een notendop? Dit is een belangrijke paragraaf, omdat het waarschijnlijk een stuk makkelijker wordt om Git effectief te gebruiken als je goed begrijpt wat Git is en hoe het werkt. Probeer te vergeten wat je al weet over andere VCSen zoals Subversion en Perforce als je Git aan het leren bent; zo kan je verwarring door de subtiele verschillen voorkomen. Git gaat op een hele andere manier met informatie om dan die andere systemen, ook al lijken de verschillende commando’s behoorlijk op elkaar. Als je die verschillen begrijpt, kan je voorkomen dat je verward raakt als je Git gebruikt.
 
 ### Momentopnames in plaats van verschillen ###
 
@@ -64,69 +64,69 @@ Een groot verschil tussen Git en elke andere VCS (inclusief Subversion en consoo
 Insert 18333fig0104.png 
 Figuur 1-4. Andere systemen bewaren data meestal als veranderingen aan een basisversie van elk bestand.
 
-Git ziet en bewaart zijn data heel anders. De kijk van Git op zijn data kan worden uitgelegd als een reeks momentopnames van een miniatuurbestandsysteem. Elke keer dat je ‘commit’ - de status van van je project in Git opslaat - neemt het een soort van foto van hoe al je bestanden er op dat moment uitzien en slaat een verwijzing naar die momentopname op. Voor efficiëntie slaat Git ongewijzigde bestanden niet elke keer opnieuw op — alleen een verwijzing naar het eerdere identieke bestand dat het eerder al opgeslagen had. In Figuur 1-5 kan je zie hoe Git ongeveer over zijn data denkt.
+Git ziet en bewaart zijn data heel anders. De kijk van Git op zijn data kan worden uitgelegd als een reeks momentopnames (snapshots) van een miniatuurbestandsysteem. Elke keer dat je ‘commit’ - de status van van je project in Git opslaat - neemt het een soort van foto van hoe al je bestanden er op dat moment uitzien en slaat een verwijzing naar die snapshot op. Voor efficiëntie slaat Git ongewijzigde bestanden niet elke keer opnieuw op — alleen een verwijzing naar het eerdere identieke bestand dat het eerder al opgeslagen had. In Figuur 1-5 kan je zie hoe Git ongeveer over zijn data denkt.
 
 Insert 18333fig0105.png 
 Figuur 1-5. Git bewaart data als momentopnames van het project.
 
-Dat is een belangrijk verschil tussen Git en bijna alle overige VCSen. Hierdoor vindt Git bijna elk onderdeel van versiebeheer opnieuw uit, terwijl de meeste andere systemen het allemaal gewoon overnemen van de eerdere generaties. Hierdoor is Git meer een soort miniatuurbestandssysteem met een paar ongelooflijk krachtige gereedschappen, in plaats van niets meer dan een VCS. We zullen een paar van de voordelen die je krijgt als je op die manier over data denkt gaan onderzoeken, als we ‘branching’ (gesplitste ontwikkeling) toelichten in Hoofdstuk 3.
+Dat is een belangrijk verschil tussen Git en bijna alle overige VCSen. Hierdoor vindt Git bijna elk onderdeel van versiebeheer opnieuw uit, terwijl de meeste andere systemen het van hebben overgenomen van eerdere generaties. Dit maakt Git meer een soort miniatuurbestandssysteem met een paar ongelooflijk krachtige gereedschappen, in plaats van niets meer dan een VCS. We zullen een paar van de voordelen die je krijgt als je op die manier over data denkt gaan onderzoeken, als we ‘branching’ (gesplitste ontwikkeling) toelichten in Hoofdstuk 3.
 
 ### Bijna alles is lokaal ###
 
-De meeste handelingen in Git werken alleen op lokale bestanden en bronnen. Normaal gesproken is geen informatie nodig van een andere computer in je netwerk. Als je gewoon bent aan een CVCS, waar de meeste handelingen vertraagd worden door het netwerk, lijkt Git een geschenk van de snelheidsgoden. Omdat je de hele geschiedenis van het project op je lokale harde schijf hebt staan, lijken de meeste acties geen tijd in beslag te nemen.
+De meeste handelingen in Git werken alleen op lokale bestanden en bronnen. Normaal gesproken is geen informatie nodig van een andere computer in je netwerk. Als je gewend bent aan een CVCS, waar de meeste handelingen vertraagd worden door het netwerk, lijkt Git door de goden begiftigd met de gave van ongelofelijke snelheid. Omdat je de hele geschiedenis van het project op je lokale harde schijf hebt staan, lijken de meeste acties geen tijd in beslag te nemen.
 
-Een voorbeeld: Git hoeft niet aan een of andere server de geschiedenis van je project te vragen als je de die wilt doorbladeren – het leest simpelweg jouw lokale database. Dat betekent dat je de geschiedenis bijna direct te zien krijgt. Als je de veranderingen wilt zien tussen de huidige versie van een bestand en de versie van een maand geleden kan Git het bestand van een maand geleden opzoeken, en de lokale verschillen berekenen, in plaats van aan een niet-lokale server te moeten vragen om het te doen, of de oudere versie van het bestand ophalen om het lokaal te doen.
+Een voorbeeld: Git hoeft niet aan een of andere server de geschiedenis van je project te vragen als je de die wilt doorbladeren – het leest simpelweg jouw lokale database. Dat betekent dat je de geschiedenis van het project bijna direct te zien krijgt. Als je de veranderingen wilt zien tussen de huidige versie van een bestand en de versie van een maand geleden kan Git het bestand van een maand geleden opzoeken, en de lokale verschillen berekenen, in plaats van aan een niet-lokale server te moeten vragen om het te doen, of de oudere versie van het bestand ophalen van een server om het lokaal te doen.
 
-Dit betekent dat er maar heel weinig is dat je niet kunt doen als je offline bent of zonder VPN zit. Als je in een vliegtuig of trein zit, en je wilt nog even een beetje werken, kun je vrolijk doorgaan met commits maken tot je een netwerkverbinding krijgt, zodat je je werk kunt uploaden. Als je naar huis gaat en je VPN client niet aan de praat kunt krijgen dan kun je nog steeds doorwerken. Bij veel andere systemen is dat of onmogelijk of zeer onaangenaam. Als je bijvoorbeeld Perforce gebruikt kun je niet zo veel doen als je niet verbonden bent met de server. Met Subversion en CVS kun je bestanden bewerken maar je kunt geen commits maken voor je database (omdat die offline is). Dat lijkt misschien niet zo belangrijk maar je zult nog versteld staan wat een verschil het kan maken.
+Dit betekent dat er maar heel weinig is dat je niet kunt doen als je offline bent of zonder VPN zit. Als je in een vliegtuig of trein zit, en je wilt nog even wat werken, kan je vrolijk doorgaan met commits maken tot je een netwerkverbinding krijgt, zodat je je werk kunt uploaden. Als je naar huis gaat en je VPN client niet aan de praat krijgt kan je nog steeds doorwerken. Bij veel andere systemen is dat of onmogelijk of zeer onaangenaam. Als je bijvoorbeeld Perforce gebruikt kun je niet zo veel doen als je niet verbonden bent met de server. Met Subversion en CVS kun je bestanden bewerken maar je kunt geen commits maken naar je database (omdat die offline is). Dat lijkt misschien niet zo belangrijk maar je zult nog versteld staan wat een verschil het kan maken.
 
 ### Git is integer ###
 
-Git maakt een controlegetal (‘checksum’) van alles voordat het wordt opgeslagen en er wordt later naar die data verwezen met dit controlegetal. Dat betekent dat het onmogelijk is om de inhoud van een bestand of map te veranderen zonder dat Git er vanaf weet. Deze functionaliteit is ingebouwd in het diepste deel van Git en staat centraal in zijn filosofie. Je kunt geen informatie kwijtraken als het wordt verstuurd en bestanden kunnen niet corrupt raken zonder dat Git het weet.
+Git maakt een controlegetal (‘checksum’) van alles voordat het wordt opgeslagen en er wordt later met dat controlegetal ernaar verwezen. Dat betekent dat het onmogelijk is om de inhoud van een bestand of map te veranderen zonder dat Git er vanaf weet. Deze functionaliteit is ingebouwd in het diepste deel van Git en staat centraal in zijn filosofie. Je kunt geen informatie kwijtraken als het wordt verstuurd en bestanden kunnen niet corrupt raken zonder dat Git het bemerkt.
 
 Het mechanisme dat Git gebruikt voor deze controlegetallen heet een SHA-1-hash. Dat is een tekenreeks van 40 karakters lang, bestaande uit hexadecimale tekens (0–9 en a–f) en wordt berekend uit de inhoud van een bestand of mapstructuur in Git. Een SHA-1-hash ziet er ongeveer zo uit:
 
 	24b9da6552252987aa493b52f8696cd6d3b00373
 
-Je zult deze hashtekenreeksen overal tegenkomen omdat Git er zoveel gebruik van maakt. Sterker nog, Git bewaart data niet onder hun bestandsnaam maar in de database van Git onder de hash van de inhoud.
+Je zult deze hashtekenreeksen overal tegenkomen omdat Git er zoveel gebruik van maakt. Sterker nog, Git bewaart data niet onder hun bestandsnaam maar in de database van Git met de hash van de inhoud als sleutel.
 
 ### Git voegt normaal gesproken alleen data toe ###
 
-Wanneer je iets doet in Git is de kans groot dat het alleen maar data aan de database van Git toevoegt. Het is erg moeilijk om het systeem iets te laten doen dat je niet ongedaan kan maken of de data uit te laten wissen op wat voor manier dan ook. Zoals met elke VCS kun je veranderingen verliezen of verhaspelen waar je nog geen momentopname van hebt gemaakt; maar als je dat eenmaal hebt gedaan, is het erg moeilijk om die data te verliezen, zeker als je je lokale database regelmatig uploadt (‘push’) naar een andere repository.
+Wanneer je iets doet in Git is de kans groot dat deze acties alleen maar data aan de database van Git toevoegen. Het is erg moeilijk om het systeem iets te laten doen dat je niet ongedaan kan maken of de gegevens te laten wissen op wat voor manier dan ook. Zoals met elke VCS kun je veranderingen verliezen of verhaspelen als deze nog niet hebt gecommit; maar als je dat eenmaal hebt gedaan, is het erg moeilijk om die data te verliezen, zeker als je je lokale database regelmatig uploadt (‘push’) naar een andere repository.
 
 Je zult nog veel plezier van Git hebben omdat je weet dat je kunt experimenteren zonder het gevaar te lopen jezelf behoorlijk in de nesten te werken. Zie Hoofdstuk 9 voor een iets diepgaandere uitleg over hoe Git zijn data bewaart en hoe je de data die verloren lijkt kunt terughalen.
 
 ### De drie toestanden ###
 
-Let nu goed op. Dit is het belangrijkste dat je over Git moet weten als je wilt dat de rest van het leerproces goed verloopt. Git heeft drie hoofdtoestanden waarin je bestanden zich kunnen bevinden: gecommit (‘commited’), aangepast (‘modified’) en voorbereid voor een commit (‘staged’). Gecommit betekent dat alle data al veilig opgeslagen is in je lokale database. Aangepast betekent dat je je bestand hebt veranderd maar dat je nog geen nieuwe momentopname in je database hebt. Voorbereid betekent dat je al hebt aangegeven dat je de huidige versie van het aangepaste bestand in je volgende momentopname toevoegt.
+Let nu goed op. Dit is het belangrijkste dat je over Git moet weten als je wilt dat de rest van het leerproces gladjes verloopt. Git heeft drie hoofdtoestanden waarin je bestanden zich kunnen bevinden: gecommit (‘commited’), aangepast (‘modified’) en voorbereid voor een commit (‘staged’). Committed houdt in dat alle data al veilig opgeslagen is in je lokale database. Modified betekent dat je je bestand hebt veranderd maar dat je nog niet naar je database gecommit hebt. Staged betekent dat je al hebt aangegeven dat je de huidige versie van het aangepaste bestand in je volgende commit meegenomen moet worden.
 
-Dit brengt ons tot de drie hoofdonderdelen van een Gitproject: de Gitmap, de werkmap, en de wachtrij voor een commit (‘staging area’)
+Dit brengt ons tot de drie hoofdonderdelen van een Gitproject: de Git directory, de werk directory, en de wachtrij voor een commit (‘staging area’)
 
 Insert 18333fig0106.png 
-Figuur 1-6. Werkmap, wachtrij en Gitmap
+Figuur 1-6. Werk directory, wachtrij en Git directory
 
-De Gitmap is waar Git de metadata en objectdatabase van je project opslaat. Dit is het belangrijkste deel van Git. Deze map wordt gekopiëerd wanneer je een repository kloont vanaf een andere computer.
+De Git directory is waar Git de metadata en objectdatabase van je project opslaat. Dit is het belangrijkste deel van Git. Deze directort wordt gekopiëerd wanneer je een repository kloont vanaf een andere computer.
 
-De werkmap is een kopie van een bepaalde versie van het project (een ‘checkout’). Deze bestanden worden uit de gecomprimeerde database in de Gitmap gehaald en op de harde schijf geplaatst waar jij ze kunt gebruiken of bewerken.
+De werk direcotry is een kopie van een bepaalde versie van het project (een ‘checkout’). Deze bestanden worden uit de gecomprimeerde database in de Git directory gehaald en op de harde schijf geplaatst waar jij ze kunt gebruiken of bewerken.
 
-De wachtrij is een simpel bestand, dat zich in het algemeen in je Gitmap bevindt, waar informatie opgeslagen wordt over wat in de volgende commit meegaat. Het wordt soms de index genoemd, maar tegenwoordig wordt het de wachtrij (staging area) genoemd.
+De wachtrij is een simpel bestand, dat zich normaalgesproken in je Git directory bevindt, waar informatie opgeslagen wordt over wat in de volgende commit meegaat. Het wordt soms de index genoemd, maar tegenwoordig wordt het de wachtrij (staging area) genoemd.
 
 De algemene manier van werken met Git gaat ongeveer zo:
 
-1.	Je bewerkt bestanden in je werkmap.
-2.	Je bereidt de bestanden voor, waardoor momentopnames worden toegevoegd aan de wachtrij.
-3.	Je maakt een commit. Een commit neemt alle momentopnames van de wachtrij en die permanent bewaard in je Gitmap.
+1.	Je bewerkt bestanden in je werk directory.
+2.	Je bereidt de bestanden voor (staged), waardoor momentopnames worden toegevoegd aan de wachtrij.
+3.	Je maakt een commit. Een commit neemt alle momentopnames van de wachtrij en bewaart die voorgoed in je Git directory.
 
-Als een bepaalde versie van een bestand in de Gitmap staat, wordt het beschouwd als gecommit. Als het is aangepast, maar wel aan de wachtrij is toegevoegd, is het voorbereid. En als het veranderd is sinds het gekopiëerd werd, maar niet voorbereid is, is het aangepast. In Hoofdstuk 2 leer je meer over deze toestanden en hoe je er voordeel van kunt hebben, maar ook hoe je de wachtrij compleet over kunt slaan.
+Als een bepaalde versie van een bestand in de Git directory staat, wordt het beschouwd als gecommit. Als het is aangepast, maar wel aan de wachtrij is toegevoegd, is het staged. En als het veranderd is sinds het gekopiëerd werd, maar niet staged is, is het aangepast. In Hoofdstuk 2 leer je meer over deze toestanden en hoe je er je voordeel mee kunt doen, maar ook hoe je de wachtrij compleet over kunt slaan.
 
 ## Git installeren ##
 
-Laten we eens een beetje Git gebruiken. Je kunt natuurlijk niet meteen beginnen — je moet het eerst installeren. Er zijn een aantal manieren om eraan te komen; de belangrijkste twee zijn installeren vanaf broncode of een bestaand pakket voor jouw platform gebruiken.
+Laten we eens een wat Git gebruiken. Je kunt natuurlijk niet meteen beginnen — je moet het eerst installeren. Er zijn een aantal manieren om eraan te komen; de belangrijkste twee zijn installeren vanaf broncode of een bestaand pakket voor jouw platform gebruiken.
 
-### Installeren vanaf de bron ###
+### Installeren vanaf de broncode ###
 
-Als het mogelijk is, is het meestal handig om Git vanaf de broncode te installeren, omdat je dan altijd de nieuwste versie hebt. Elke versie van Git brengt meestal goede verbeteringen aan de gebruikersinterface met zich mee, dus de laatste versie is vaak de beste manier als je het gewoon bent software vanaf de broncode te compileren. Vaak hebben Linuxdistributies behoorlijk oude pakketen - tenzij je een hele up-to-date distro hebt of ‘backports’ (verbeteringen van een nieuwe versie op een oudere versie toepassen) gebruikt - is installeren vanaf broncode misschien wel de beste manier voor jou.
+Als het mogelijk is, is het meestal nuttig om Git vanaf de broncode te installeren, omdat je dan altijd de recentste versie hebt. Elke versie van Git brengt meestal nuttige verbeteringen aan de gebruikersinterface met zich mee, dus de laatste versie is vaak de beste manier als je het gewend bent software vanaf de broncode te compileren. Vaak hebben Linuxdistributies behoorlijk oude pakketen - tenzij je een hele up-to-date distro hebt of ‘backports’ (verbeteringen van een nieuwe versie op een oudere versie toepassen) gebruikt - is installeren vanaf broncode misschien wel de beste manier voor jou.
 
-Om Git te installeren heb je een aantal bibliotheken (‘libraries’) nodig: curl, zlib, openssl, expat, en libiconv. Als je bijvoorbeeld op een systeem werkt dat yum heeft (zoals Fedora) of apt-get (zoals systemen gebaseerd op Debian), kun je één van de volgende commando's gebruiken om alle bibliotheken waar Git van afhangt te installeren:
+Om Git te installeren heb je een aantal bibliotheken (‘libraries’) nodig waar Git van afhankelijk is: curl, zlib, openssl, expat, en libiconv. Als je bijvoorbeeld op een systeem werkt dat yum heeft (zoals Fedora) of apt-get (zoals systemen gebaseerd op Debian), kun je één van de volgende commando's gebruiken om alle bibliotheken waar Git van afhankelijk is te installeren:
 
 	$ yum install curl-devel expat-devel gettext-devel \
 	  openssl-devel zlib-devel
@@ -145,13 +145,13 @@ Daarna compileren en installeren:
 	$ make prefix=/usr/local all
 	$ sudo make prefix=/usr/local install
 
-Als dat allemaal klaar is, kun je de nieuwste versie van Git uit Git ophalen met dit commando:
+Als dat allemaal klaar is, kun je de ook nieuwste versie van Git met Git ophalen met dit commando:
 
 	$ git clone git://git.kernel.org/pub/scm/git/git.git
 	
 ### Op Linux installeren ###
 
-Als je direct de uitvoerbare bestanden van Git op Linux wilt installeren, kun je dat normaal doen via het standaard pakketbeheersysteem dat meegeleverd is met je distributie. Als je Fedora gebruikt kun je yum gebruiken:
+Als je direct de uitvoerbare bestanden van Git op Linux wilt installeren, kun je dat over het algemeen doen via het standaard pakketbeheersysteem dat meegeleverd is met je distributie. Als je Fedora gebruikt kun je yum gebruiken:
 
 	$ yum install git-core
 
@@ -168,7 +168,7 @@ Er zijn twee makkelijke manieren om Git op een Mac te installeren. De simpelste
 Insert 18333fig0107.png 
 Figuur 1-7. Gitinstallatieprogramma voor OS X.
 
-De andere veelgebruikte manier is om Git via MacPorts (`http://www.macports.org`) te installeren. Als je MacPorts hebt, kun je Git installeren met
+De andere veelgebruikte manier is om Git via MacPorts (`http://www.macports.org`) te installeren. Als je MacPorts geïnstalleerd hebt, kun je Git installeren met
 
 	$ sudo port install git-core +svn +doc +bash_completion +gitweb
 
@@ -184,24 +184,24 @@ Nadat het geïnstalleerd is, kun je Git zowel vanaf de commandprompt gebruiken (
 
 ## Git klaarmaken voor eerste gebruik ##
 
-Nu je Git op je computer hebt staan, is het handig dat je een paar dingen doet om je Gitomgeving aan je voorkeuren aan te passen. Je hoeft deze instellingen normaliter maar één keer te doen. Ze blijven hetzelfde als je een nieuwe versie van Git installeert. Je kunt ze op elk moment weer veranderen door de commando’s opnieuw uit te voeren.
+Nu je Git op je computer hebt staan, is het handig dat je een paar dingen doet om je Gitomgeving aan je voorkeuren aan te passen. Je hoeft deze instellingen normaliter maar één keer te doen, ze blijven hetzelfde als je een nieuwe versie van Git installeert. Je kunt ze op elk moment weer veranderen door de commando’s opnieuw uit te voeren.
 
 Git bevat standaard een stuk gereedschap genaamd `git config`, waarmee je de configuratie-eigenschappen kunt bekijken en veranderen, die alle aspecten van het uiterlijk en gedrag van Git regelen. Deze eigenschappen kunnen op drie verschillende plaatsen worden bewaard:
 
 *	Het bestand `/etc/gitconfig`: Bevat eigenschappen voor elk account op de computer en al hun repositories. Als je de optie `--system` meegeeft aan `git config`, zal het dit de configuratiegegevens in dit bestand lezen of  veranderen. 
 *	Het bestand `~/.gitconfig`: Eigenschappen voor jouw account. Je kunt Git dit bestand laten gebruiken door de optie `--global` mee te geven.
-*	Het configuratiebestand in de Gitmap (dus `.git/config`) van het repository dat je op het moment gebruikt: Specifiek voor dat ene repository. Elk niveau is belangrijker dan het voorgaande, dus waarden in `.git/config` zullen worden gebruikt in plaats van die in `/etc/gitconfig`.
+*	Het configuratiebestand in de Gitmap (dus `.git/config`) van het repository dat je op het moment gebruikt: Specifiek voor die ene repository. Elk niveau neemt voorrang boven het voorgaande, dus waarden die in `.git/config` zijn gebruikt zullen worden gebruikt in plaats van die in `/etc/gitconfig`.
 
-Op systemen met Windows zoekt Git in de `$HOME` map naar het `.gitconfig`-bestand (`C:\Documents and Settings\$USER` voor de meesten). Het kijkt ook nog naar `/etc/gitconfig`, maar dan op de plek waar je MSys hebt staan, wat de plek is waar je Git op je Windowscomputer geïnstalleerd hebt.
+Op systemen met Windows zoekt Git in de `$HOME` directory naar het `.gitconfig`-bestand (`C:\Documents and Settings\$USER` voor de meesten). Het kijkt ook nog naar `/etc/gitconfig`, maar dan op de plek waar je MSys hebt staan, wat de plek is waar je Git op je Windowscomputer geïnstalleerd hebt.
 
 ### Jouw identiteit ###
 
 Het eerste wat je zou moeten doen nadat je Git geïnstalleerd hebt, is je gebruikersnaam en e-mail addres opgeven. Dat is belangrijk, omdat elke commit in Git deze informatie gebruikt, en het onveranderlijk ingebed zit in de commits die je ronddeelt:
 
-	$ git config --global user.name "Scott Chacon"
-	$ git config --global user.email schacon@gmail.com
+	$ git config --global user.name "John Doe"
+	$ git config --global user.email johndoe@example.com
 
-Nogmaals, dit hoef je maar één keer te doen als je de `--global` optie eraan plakt, omdat Git die informatie zal gebruiken voor alles wat je doet op dat systeem. Als je een andere naam of e-mail wilt gebruiken voor specifieke projecten, kun je het commando uitvoeren zonder de `--global` optie als je in de map van dat project zit.
+Nogmaals, dit hoef je maar één keer te doen als je de `--global` optie erbij opgeeft, omdat Git die informatie zal gebruiken voor alles wat je doet op dat systeem. Als je een andere naam of e-mail wilt gebruiken voor specifieke projecten, kun je het commando uitvoeren zonder de `--global` optie als je in de directory van dat project zit.
 
 ### Je tekstverwerker ###
 
@@ -215,11 +215,11 @@ En andere bruikbare optie die je misschien wel wilt instellen is het standaard d
 
 	$ git config --global merge.tool vimdiff
 
-Git accepteert kdiff3, tkdiff, meld, xxdiff, emerge, vimdiff, gvimdiff, ecmerge en opendiff als geldige samenvoegingsgereedschappen. Je kunt ook een ander programma gebruiken; zie Hoofdstuk 7 voor meer informatie daarover.
+Git accepteert kdiff3, tkdiff, meld, xxdiff, emerge, vimdiff, gvimdiff, ecmerge en opendiff als geldige samenvoegingsgereedschappen. Je kunt ook een ander programma gebruiken, zie Hoofdstuk 7 voor meer informatie daarover.
 
 ### Je instellingen bekijken ###
 
-Als je je instellingen wilt zien, kan je `git config --list` gebruiken voor een lijstje met alle instellingen die Git vanaf de huidige map kan vinden:
+Als je je instellingen wilt zien, kan je het `git config --list` commando gebruiken voor een lijstje met alle instellingen die Git vanaf de huidige locatie kan vinden:
 
 	$ git config --list
 	user.name=Scott Chacon
@@ -249,7 +249,7 @@ Bijvoorbeeld, je kunt de gebruikershandleiding voor het commando `git config` kr
 
 	$ git help config
 
-Deze commando's zijn fijn omdat je ze overal kunt opvragen, zelfs als je offline bent.
+Deze commando's zijn prettig omdat je ze overal kunt opvragen, zelfs als je offline bent.
 Als de gebruiksaanwijzing en dit boek niet genoeg zijn en je persoonlijke hulp nodig hebt, kan je de kanalen `#git` of `#github` (beiden Engelstalig) op het Freenode IRC netwerk (irc.freenode.net) proberen. Deze kanalen zijn regelmatig gevuld met honderden mensen die allemaal zeer ervaren zijn met Git en vaak bereidwillig om te helpen.
 
 ## Samenvatting ##

From a2cf37ba7b8d72a459fc27178f5c138fa1d79508 Mon Sep 17 00:00:00 2001
From: Cor <cor.takken@cgi.com>
Date: Tue, 21 Jan 2014 09:48:13 +0100
Subject: [PATCH 128/690] [nl] Revised earlier Dutch translation

Modified certain sentences and wordchoises to be (hopefully) more
consistent with actual use of jargon in Dutch.
---
 nl/01-introduction/01-chapter1.markdown | 92 ++++++++++++-------------
 1 file changed, 46 insertions(+), 46 deletions(-)

diff --git a/nl/01-introduction/01-chapter1.markdown b/nl/01-introduction/01-chapter1.markdown
index 0288809df..d64f59909 100644
--- a/nl/01-introduction/01-chapter1.markdown
+++ b/nl/01-introduction/01-chapter1.markdown
@@ -4,58 +4,58 @@ Dit hoofdstuk legt uit je hoe je aan de slag kunt gaan met Git.  We zullen bij h
 
 ## Het wat en waarom van versiebeheer ##
 
-Wat is versiebeheer? En wat heeft dat met jou te maken? Versiebeheer is een systeem dat veranderingen in een bestand of groep van bestanden over de tijd bijhoudt. Zodat je later specifieke versies kan opvragen. In de voorbeelden in dit boek is het broncode van computersoftware waarvan de versies beheerd worden maar je kan het eigenlijk met zo goed als elk soort bestand op een computer doen.
+Wat is versiebeheer? En wat heeft dat met jou te maken? Versiebeheer is een systeem dat veranderingen in een bestand of groep van bestanden over de tijd bijhoudt, zodat je later specifieke versies kan opvragen. In de voorbeelden in dit boek is het broncode van computersoftware waarvan de versies beheerd worden maar je kan het eigenlijk met zo goed als elk soort bestand op een computer doen.
 
-Als je een grafisch ontwerper bent of websites maakt en elke versie van een afbeelding of opmaak wilt bewaren (wat je zeker zou willen), is het verstandig een versiebeheersysteem (Version Control System in het Engels, afgekort tot VCS) te gebruiken. Als je dat gebruikt kan je eerdere versies van bestanden of hele project terughalen, veranderingen tussen twee momenten in tijd bekijken, zien wie het laatst iets aangepast heeft, wie een probleem heeft veroorzaakt en wanneer en nog veel meer. Een VCS gebruiken betekent meestal ook dat je de situatie gemakkelijk terug kan draaien als je een fout maakt of bestanden kwijtraakt. Daarbij komt nog dat dit allemaal heel weinig extra belasting met zich mee brengt.
+Als je een grafisch ontwerper bent of websites maakt en elke versie van een afbeelding of opmaak wilt bewaren (wat je vrijwel zeker zult willen), is het verstandig een versiebeheersysteem (Version Control System in het Engels, afgekort tot VCS) te gebruiken. Als je dat gebruikt kan je eerdere versies van bestanden of hele project terughalen, veranderingen tussen twee momententen in tijd bekijken, zien wie het laatst iets aangepast heeft dat een probleem zou kunnen veroorzaken, wie een probleen heeft veroorzaakt en wanneer en nog veel meer. Een VCS gebruiken betekent meestal ook dat je de situatie gemakkelijk terug kan draaien als je een fout maakt of bestanden kwijtraakt. Daarbij komt nog dat dit allemaal heel weinig extra belasting met zich mee brengt.
 
 ### Lokale versiebeheersystemen ###
 
-Veel mensen hebben hun eigen versiebeheer methode: ze kopiëren bestanden naar een andere map (en als ze slim zijn, geven ze die map ook een datum). Deze methode wordt veel gebruikt omdat het zo simpel is, maar het is ook ongelofelijk foutgevoelig. Het is makkelijk te vergeten in welke map je zit en naar het verkeerde bestand te schrijven, of over bestanden heen te kopiëren waar je dat niet wilde.
+Veel mensen hebben hun eigen versiebeheer methode: ze kopiëren bestanden naar een andere map (en als ze slim zijn, geven ze die map ook een datum). Deze methode wordt veel gebruikt omdat het zo simpel is, maar het is ook ongelofelijk foutgevoelig. Het is makkelijk te vergeten in welke map je zit en naar het verkeerde bestand te schrijven, of onbedoeld over bestanden heen te kopiëren.
 
-Om met dit probleem om te gaan hebben programmeurs lang geleden lokale VCSen ontwikkeld die een simpele database hadden om alle veranderingen aan bestanden te beheren (zie Figuur 1-1).
+Om met dit probleem om te gaan hebben programmeurs lang geleden lokale VCSen ontwikkeld die een simpele database gebruikten om alle veranderingen aan bestanden te beheren (zie Figuur 1-1).
 
 Insert 18333fig0101.png
 Figuur 1-1. Een diagram van een lokaal versiebeheersysteem.
 
-Een populair gereedschap voor VCS was een systeem genaamd rcs, wat vandaag de dag nog steeds met veel computers wordt mee geleverd. Zelfs het populaire besturingssysteem Mac OS X heeft rcs, als je de Developer Tools installeert. Dit gereedschap werkt in principe door verzamelingen van ‘patches’ (de verschillen tussen bestanden) van de opvolgende bestandsversies in een speciaal formaat op de harde schijf op te slaan; zo kan je teruggaan naar hoe een bestand er uitzag op ieder willekeurig moment in tijd, door alle patches bij elkaar op te tellen.
+Een populair gereedschap voor VCS was een systeem genaamd rcs, wat vandaag de dag nog steeds met veel computers wordt mee geleverd. Zelfs het populaire besturingssysteem Mac OS X heeft rcs als je de Developer Tools installeert. Dit gereedschap werkt in principe door verzamelingen van ‘patches’ (de verschillen tussen bestanden) van de opvolgende bestandsversies in een speciaal formaat op de harde schijf op te slaan. Zo kan je teruggaan naar hoe een bestand er uitzag op ieder willekeurig moment in tijd, door alle patches bij elkaar op te tellen.
 
 ### Gecentraliseerde versiebeheersystemen ###
 
-Het volgende grote probleem waar mensen tegenaan lopen is dat ze samen moeten werken met ontwikkelaars op andere computers. Om dit probleem op te lossen ontwikkelde men Gecentraliseerde Versiebeheersystemen (CVCSen). Deze systemen, zoals CVS, Subversion en Perforce, hebben één centrale server waarop alle versies van de bestanden staan en een aantal clients die de bestanden daar van halen (‘check out’, in het Engels). Vele jaren was dit de standaard voor versiebeheer (zie Figuur 1-2).
+De volgende belangrijke uitdaging waar mensen tegenaan lopen is dat ze samen moeten werken met ontwikkelaars op andere computers. Om deze uitdaging te overkomen ontwikkelde men Gecentraliseerde Versiebeheersystemen (CVCSen). Deze systemen, zoals CVS, Subversion en Perforce, hebben één centrale server waarop alle versies van de bestanden staan en een aantal clients die de bestanden daar van halen (‘check out’, in het Engels). Vele jaren was dit de standaard voor versiebeheer (zie Figuur 1-2).
 
 Insert 18333fig0102.png
 Figuur 1-2. Een diagram van een gecentraliseerd versiebeheersysteem.
 
-Deze manier van versiebeheer biedt veel voordelen, vooral als je het vergelijkt met lokale VCSen. Bijvoorbeeld, iedereen weet tot op zekere hoogte wat de overige project-medewerkers aan het doen zijn. Beheerders hebben precieze controle over wie wat kan doen; en het is veel eenvoudiger om een CVCS te beheren dan te moeten werken met lokale databases voor elke client.
+Deze manier van versiebeheer biedt veel voordelen, vooral als je het vergelijkt met lokale VCSen. Bijvoorbeeld, iedereen weet tot op zekere hoogte wat de overige project-medewerkers aan het doen zijn. Beheerders hebben een hoge mate van controle over wie wat kan doen, en het is veel eenvoudiger om een CVCS te beheren dan te moeten werken met lokale databases op elke client.
 
 Maar helaas, deze methode heeft ook behoorlijke nadelen. De duidelijkste is de ‘single point of failure’: als de centrale server plat gaat en een uur later weer terug online komt kan niemand in dat uur samenwerken of versies bewaren van de dingen waar ze aan werken. Als de harde schrijf waar de centrale database op staat corrupt raakt en er geen backups van zijn verlies je echt alles — de hele geschiedenis van het project, behalve de momentopnames die mensen op hun eigen computers hebben staan. Lokale VCSen hebben hetzelfde probleem — als je de hele geschiedenis van het project op één enkele plaats bewaart, loop je ook kans alles te verliezen.
 
 ### Gedistribueerde versiebeheersystemen ###
 
-En hier verschijnen Gedistribueerde versiebeheersystemen (DVCSen) ten tonele. In een DVCS (zoals Git, Mercurial, Bazaar en Darcs) downloaden clients niet alleen de laatste momentopnames van de bestanden. De hele geschiedenis (de ‘repository’) wordt gekopieerd. Dus als een server neergaat en deze systemen werkten via die server samen dan kan de repository van elke willekeurige client terug worden gekopieerd naar de server om deze te herstellen. Elke checkout is dus eigenlijk een complete backup van alle data (zie Figuur 1-3).
+En hier verschijnen Gedistribueerde versiebeheersystemen (DVCSen) ten tonele. In een DVCS (zoals Git, Mercurial, Bazaar en Darcs) downloaden clients niet simpelweg de laatste momentopnames van de bestanden. De hele geschiedenis (de ‘repository’) wordt gekopiëerd. Dus als een server neergaat en deze systemen werkten via die server samen dan kan de repository van elke willekeurige client terug worden gekopiëerd naar de server om deze te herstellen. Elke checkout is dus eigenlijk een complete backup van alle data (zie Figuur 1-3).
 
 Insert 18333fig0103.png
 Figuur 1-3. Diagram van een gedistribueerd versiebeheersysteem
 
 Bovendien werken veel van deze systemen behoorlijk goed met meerdere (niet-lokale) repositories tegelijk zodat je met verschillende groepen mensen op verschillende manieren tegelijk aan hetzelfde project kan werken. Hierdoor kan je verschillende werkprocessen (‘workflows’) opzetten die niet mogelijk waren geweest met gecentraliseerde systemen zoals hiërarchische modellen.
 
-## Een kleine geschiedenis van Git ##
+## Een kort historisch overzicht van Git ##
 
-Zoals zoveel goede dingen in het leven begon Git met een beetje creatieve destructie en een hoogoplopende controverse. De Linuxkernel is een open source softwareproject met een behoorlijk groot draagvlak. In het kader van het onderhoud van de Linuxkernel (1991–2002), werden aanpassingen aan de software voornamelijk verspreid via patches en gearchiveerde bestanden. In 2002 veranderde dat want vanaf dat jaar begon het project het gesloten DVCS genaamd BitKeeper te gebruiken.
+Zoals zoveel goede dingen in het leven begon Git met een beetje creatieve destructie en een hoogoplopende controverse. De Linuxkernel is een open source softwareproject met een behoorlijk groot toepassingsgebied. In het kader van het onderhoud van de Linuxkernel (1991–2002), werden aanpassingen aan de software voornamelijk verspreid via patches en gearchiveerde bestanden. In 2002 veranderde dat want vanaf dat jaar begon het project een gesloten DVCS genaamd BitKeeper te gebruiken.
 
-In 2005 viel de relatie tussen de gemeenschap die de Linuxkernel ontwikkelde en het commerciële bedrijf dat BitKeeper maakte uiteen. Het programma kon niet langer meer gratis worden gebruikt. Dit was de aanleiding voor de gemeenschap (en Linus Torvalds, de maker van Linux, in het bijzonder) om hun eigen gereedschap te ontwikkelen. Gebaseerd op de ervaring die opgedaan was toen ze nog BitKeeper gebruikten. Een paar van de doelen die ze hadden voor het nieuwe systeem waren als volgt:
+In 2005 viel de relatie tussen de gemeenschap die de Linuxkernel ontwikkelde en het commerciële bedrijf dat BitKeeper maakte uiteen, en het programma kon niet langer meer gratis worden gebruikt. Dit was de aanleiding voor de gemeenschap (en Linus Torvalds, de maker van Linux, in het bijzonder) om hun eigen gereedschap te ontwikkelen. Gebaseerd op de ervaring die opgedaan was toen ze nog BitKeeper gebruikten. Een paar van de doelen die ze hadden voor het nieuwe systeem waren als volgt:
 
 *	Snelheid
 *	Eenvoudig ontwerp
-*	Goede ondersteuning voor niet-lineaire ontwikkeling (duizenden aparte takken tegelijk)
+*	Goede ondersteuning voor niet-lineaire ontwikkeling (duizenden parallelle takken (branches) )
 *	Volledig gedistribueerd
 *	In staat om efficiënt om te gaan met grote projecten als de Linuxkernel (voor wat betreft snelheid maar ook opslagruimte)
 
-Sinds het ontstaan in 2005 is Git gegroeid tot zijn huidige vorm: het is eenvoudig te gebruiken en heeft toch die oorspronkelijke eigenschappen behouden. Het is ongelofelijk snel, enorm efficiënt met grote projecten en zijn systeem voor aparte takken (‘branches’) van niet-lineaire ontwikkeling is ongeëvenaard (zie Hoofdstuk 3).
+Sinds het ontstaan in 2005 is Git gegroeid tot zijn huidige vorm: het is eenvoudig te gebruiken en heeft toch die oorspronkelijke eigenschappen behouden. Het is ongelofelijk snel, enorm efficiënt met grote projecten en een ongeëvenaard systeem van branches voor het ondersteunen van niet-lineaire ontwikkeling (zie Hoofdstuk 3).
 
 ## De basis van Git ##
 
-Dus, wat is Git in een notendop? Dit is een belangrijk deelhoofdstuk, omdat het waarschijnlijk een stuk makkelijker wordt om Git effectief te gebruiken als je goed begrijpt wat Git is en hoe het werkt. Probeer te vergeten wat je al weet over andere VCSen zoals Subversion en Perforce als je Git aan het leren bent; zo kan je verwarring door de subtiele verschillen voorkomen. Git gaat op een hele andere manier met informatie om dan die andere systemen, ook al lijken de verschillende commando’s behoorlijk op elkaar. Als je die verschillen begrijpt, kan je voorkomen dat je verward raakt als je Git gebruikt.
+Dus, wat is Git in een notendop? Dit is een belangrijke paragraaf, omdat het waarschijnlijk een stuk makkelijker wordt om Git effectief te gebruiken als je goed begrijpt wat Git is en hoe het werkt. Probeer te vergeten wat je al weet over andere VCSen zoals Subversion en Perforce als je Git aan het leren bent; zo kan je verwarring door de subtiele verschillen voorkomen. Git gaat op een hele andere manier met informatie om dan die andere systemen, ook al lijken de verschillende commando’s behoorlijk op elkaar. Als je die verschillen begrijpt, kan je voorkomen dat je verward raakt als je Git gebruikt.
 
 ### Momentopnames in plaats van verschillen ###
 
@@ -64,69 +64,69 @@ Een groot verschil tussen Git en elke andere VCS (inclusief Subversion en consoo
 Insert 18333fig0104.png
 Figuur 1-4. Andere systemen bewaren data meestal als veranderingen aan een basisversie van elk bestand.
 
-Git ziet en bewaart zijn data heel anders. De kijk van Git op zijn data kan worden uitgelegd als een reeks momentopnames van een miniatuurbestandssysteem. Elke keer dat je ‘commit’ - de status van van je project in Git opslaat - neemt het een soort van foto van hoe al je bestanden er op dat moment uitzien en slaat een verwijzing naar die momentopname op. Voor efficiëntie slaat Git ongewijzigde bestanden niet elke keer opnieuw op — alleen een verwijzing naar het eerdere identieke bestand dat het eerder al opgeslagen had. In Figuur 1-5 kan je zie hoe Git ongeveer over zijn data denkt.
+Git ziet en bewaart zijn data heel anders. De kijk van Git op zijn data kan worden uitgelegd als een reeks momentopnames (snapshots) van een miniatuurbestandsysteem. Elke keer dat je ‘commit’ - de status van van je project in Git opslaat - neemt het een soort van foto van hoe al je bestanden er op dat moment uitzien en slaat een verwijzing naar die snapshot op. Voor efficiëntie slaat Git ongewijzigde bestanden niet elke keer opnieuw op — alleen een verwijzing naar het eerdere identieke bestand dat het eerder al opgeslagen had. In Figuur 1-5 kan je zie hoe Git ongeveer over zijn data denkt.
 
 Insert 18333fig0105.png
 Figuur 1-5. Git bewaart data als momentopnames van het project.
 
-Dat is een belangrijk verschil tussen Git en bijna alle overige VCSen. Hierdoor vindt Git bijna elk onderdeel van versiebeheer opnieuw uit, terwijl de meeste andere systemen het allemaal gewoon overnemen van de eerdere generaties. Hierdoor is Git meer een soort miniatuurbestandssysteem met een paar ongelooflijk krachtige gereedschappen, in plaats van niets meer dan een VCS. We zullen een paar van de voordelen die je krijgt als je op die manier over data denkt gaan onderzoeken, als we ‘branching’ (gesplitste ontwikkeling) toelichten in Hoofdstuk 3.
+Dat is een belangrijk verschil tussen Git en bijna alle overige VCSen. Hierdoor vindt Git bijna elk onderdeel van versiebeheer opnieuw uit, terwijl de meeste andere systemen het van hebben overgenomen van eerdere generaties. Dit maakt Git meer een soort miniatuurbestandssysteem met een paar ongelooflijk krachtige gereedschappen, in plaats van niets meer dan een VCS. We zullen een paar van de voordelen die je krijgt als je op die manier over data denkt gaan onderzoeken, als we ‘branching’ (gesplitste ontwikkeling) toelichten in Hoofdstuk 3.
 
 ### Bijna alles is lokaal ###
 
-De meeste handelingen in Git werken alleen op lokale bestanden en bronnen. Normaal gesproken is geen informatie nodig van een andere computer in je netwerk. Als je gewoon bent aan een CVCS, waar de meeste handelingen vertraagd worden door het netwerk, lijkt Git een geschenk van de snelheidsgoden. Omdat je de hele geschiedenis van het project op je lokale harde schijf hebt staan, lijken de meeste acties geen tijd in beslag te nemen.
+De meeste handelingen in Git werken alleen op lokale bestanden en bronnen. Normaal gesproken is geen informatie nodig van een andere computer in je netwerk. Als je gewend bent aan een CVCS, waar de meeste handelingen vertraagd worden door het netwerk, lijkt Git door de goden begiftigd met de gave van ongelofelijke snelheid. Omdat je de hele geschiedenis van het project op je lokale harde schijf hebt staan, lijken de meeste acties geen tijd in beslag te nemen.
 
-Een voorbeeld: Git hoeft niet aan een of andere server de geschiedenis van je project te vragen als je de die wilt doorbladeren – het leest simpelweg jouw lokale database. Dat betekent dat je de geschiedenis bijna direct te zien krijgt. Als je de veranderingen wilt zien tussen de huidige versie van een bestand en de versie van een maand geleden kan Git het bestand van een maand geleden opzoeken, en de lokale verschillen berekenen, in plaats van aan een niet-lokale server te moeten vragen om het te doen, of de oudere versie van het bestand ophalen om het lokaal te doen.
+Een voorbeeld: Git hoeft niet aan een of andere server de geschiedenis van je project te vragen als je de die wilt doorbladeren – het leest simpelweg jouw lokale database. Dat betekent dat je de geschiedenis van het project bijna direct te zien krijgt. Als je de veranderingen wilt zien tussen de huidige versie van een bestand en de versie van een maand geleden kan Git het bestand van een maand geleden opzoeken, en de lokale verschillen berekenen, in plaats van aan een niet-lokale server te moeten vragen om het te doen, of de oudere versie van het bestand ophalen van een server om het lokaal te doen.
 
-Dit betekent dat er maar heel weinig is dat je niet kunt doen als je offline bent of zonder VPN zit. Als je in een vliegtuig of trein zit, en je wilt nog even een beetje werken, kun je vrolijk doorgaan met commits maken tot je een netwerkverbinding krijgt, zodat je je werk kunt uploaden. Als je naar huis gaat en je VPN client niet aan de praat kunt krijgen dan kun je nog steeds doorwerken. Bij veel andere systemen is dat of onmogelijk of zeer onaangenaam. Als je bijvoorbeeld Perforce gebruikt kun je niet zo veel doen als je niet verbonden bent met de server. Met Subversion en CVS kun je bestanden bewerken maar je kunt geen commits maken voor je database (omdat die offline is). Dat lijkt misschien niet zo belangrijk maar je zult nog versteld staan wat een verschil het kan maken.
+Dit betekent dat er maar heel weinig is dat je niet kunt doen als je offline bent of zonder VPN zit. Als je in een vliegtuig of trein zit, en je wilt nog even wat werken, kan je vrolijk doorgaan met commits maken tot je een netwerkverbinding krijgt, zodat je je werk kunt uploaden. Als je naar huis gaat en je VPN client niet aan de praat krijgt kan je nog steeds doorwerken. Bij veel andere systemen is dat of onmogelijk of zeer onaangenaam. Als je bijvoorbeeld Perforce gebruikt kun je niet zo veel doen als je niet verbonden bent met de server. Met Subversion en CVS kun je bestanden bewerken maar je kunt geen commits maken naar je database (omdat die offline is). Dat lijkt misschien niet zo belangrijk maar je zult nog versteld staan wat een verschil het kan maken.
 
 ### Git is integer ###
 
-Git maakt een controlegetal (‘checksum’) van alles voordat het wordt opgeslagen en er wordt later naar die data verwezen met dit controlegetal. Dat betekent dat het onmogelijk is om de inhoud van een bestand of map te veranderen zonder dat Git er vanaf weet. Deze functionaliteit is ingebouwd in het diepste deel van Git en staat centraal in zijn filosofie. Je kunt geen informatie kwijtraken als het wordt verstuurd en bestanden kunnen niet corrupt raken zonder dat Git het weet.
+Git maakt een controlegetal (‘checksum’) van alles voordat het wordt opgeslagen en er wordt later met dat controlegetal ernaar verwezen. Dat betekent dat het onmogelijk is om de inhoud van een bestand of map te veranderen zonder dat Git er vanaf weet. Deze functionaliteit is ingebouwd in het diepste deel van Git en staat centraal in zijn filosofie. Je kunt geen informatie kwijtraken als het wordt verstuurd en bestanden kunnen niet corrupt raken zonder dat Git het bemerkt.
 
 Het mechanisme dat Git gebruikt voor deze controlegetallen heet een SHA-1-hash. Dat is een tekenreeks van 40 karakters lang, bestaande uit hexadecimale tekens (0–9 en a–f) en wordt berekend uit de inhoud van een bestand of mappenstructuur in Git. Een SHA-1-hash ziet er ongeveer zo uit:
 
 	24b9da6552252987aa493b52f8696cd6d3b00373
 
-Je zult deze hashtekenreeksen overal tegenkomen omdat Git er zoveel gebruik van maakt. Sterker nog, Git bewaart data niet onder hun bestandsnaam maar in de database van Git onder de hash van de inhoud.
+Je zult deze hashtekenreeksen overal tegenkomen omdat Git er zoveel gebruik van maakt. Sterker nog, Git bewaart data niet onder hun bestandsnaam maar in de database van Git met de hash van de inhoud als sleutel.
 
 ### Git voegt normaal gesproken alleen data toe ###
 
-Wanneer je iets doet in Git is de kans groot dat het alleen maar data aan de database van Git toevoegt. Het is erg moeilijk om het systeem iets te laten doen dat je niet ongedaan kan maken of de data uit te laten wissen op wat voor manier dan ook. Zoals met elke VCS kun je veranderingen verliezen of verhaspelen waar je nog geen momentopname van hebt gemaakt; maar als je dat eenmaal hebt gedaan, is het erg moeilijk om die data te verliezen, zeker als je je lokale database regelmatig uploadt (‘push’) naar een andere repository.
+Wanneer je iets doet in Git is de kans groot dat deze acties alleen maar data aan de database van Git toevoegen. Het is erg moeilijk om het systeem iets te laten doen dat je niet ongedaan kan maken of de gegevens te laten wissen op wat voor manier dan ook. Zoals met elke VCS kun je veranderingen verliezen of verhaspelen als deze nog niet hebt gecommit; maar als je dat eenmaal hebt gedaan, is het erg moeilijk om die data te verliezen, zeker als je je lokale database regelmatig uploadt (‘push’) naar een andere repository.
 
 Je zult nog veel plezier van Git hebben omdat je weet dat je kunt experimenteren zonder het gevaar te lopen jezelf behoorlijk in de nesten te werken. Zie Hoofdstuk 9 voor een iets diepgaandere uitleg over hoe Git zijn data bewaart en hoe je de data die verloren lijkt kunt terughalen.
 
 ### De drie toestanden ###
 
-Let nu goed op. Dit is het belangrijkste dat je over Git moet weten als je wilt dat de rest van het leerproces goed verloopt. Git heeft drie hoofdtoestanden waarin je bestanden zich kunnen bevinden: gecommit (‘commited’), aangepast (‘modified’) en voorbereid voor een commit (‘staged’). Gecommit betekent dat alle data al veilig opgeslagen is in je lokale database. Aangepast betekent dat je je bestand hebt veranderd maar dat je nog geen nieuwe momentopname in je database hebt. Voorbereid betekent dat je al hebt aangegeven dat je de huidige versie van het aangepaste bestand in je volgende momentopname toevoegt.
+Let nu goed op. Dit is het belangrijkste dat je over Git moet weten als je wilt dat de rest van het leerproces gladjes verloopt. Git heeft drie hoofdtoestanden waarin je bestanden zich kunnen bevinden: gecommit (‘commited’), aangepast (‘modified’) en voorbereid voor een commit (‘staged’). Committed houdt in dat alle data al veilig opgeslagen is in je lokale database. Modified betekent dat je je bestand hebt veranderd maar dat je nog niet naar je database gecommit hebt. Staged betekent dat je al hebt aangegeven dat je de huidige versie van het aangepaste bestand in je volgende commit meegenomen moet worden.
 
-Dit brengt ons tot de drie hoofdonderdelen van een Gitproject: de Gitmap, de werkmap, en de wachtrij voor een commit (‘staging area’)
+Dit brengt ons tot de drie hoofdonderdelen van een Gitproject: de Git directory, de werk directory, en de wachtrij voor een commit (‘staging area’)
 
-Insert 18333fig0106.png
-Figuur 1-6. Werkmap, wachtrij en Gitmap
+Insert 18333fig0106.png 
+Figuur 1-6. Werk directory, wachtrij en Git directory
 
-De Gitmap is waar Git de metadata en objectdatabase van je project opslaat. Dit is het belangrijkste deel van Git. Deze map wordt gekopieerd wanneer je een repository kloont vanaf een andere computer.
+De Git directory is waar Git de metadata en objectdatabase van je project opslaat. Dit is het belangrijkste deel van Git. Deze directort wordt gekopiëerd wanneer je een repository kloont vanaf een andere computer.
 
-De werkmap is een kopie van een bepaalde versie van het project (een ‘checkout’). Deze bestanden worden uit de gecomprimeerde database in de Gitmap gehaald en op de harde schijf geplaatst waar jij ze kunt gebruiken of bewerken.
+De werk direcotry is een kopie van een bepaalde versie van het project (een ‘checkout’). Deze bestanden worden uit de gecomprimeerde database in de Git directory gehaald en op de harde schijf geplaatst waar jij ze kunt gebruiken of bewerken.
 
-De wachtrij is een simpel bestand, dat zich in het algemeen in je Gitmap bevindt, waar informatie opgeslagen wordt over wat in de volgende commit meegaat. Het wordt soms de index genoemd, maar tegenwoordig wordt het de wachtrij (staging area) genoemd.
+De wachtrij is een simpel bestand, dat zich normaalgesproken in je Git directory bevindt, waar informatie opgeslagen wordt over wat in de volgende commit meegaat. Het wordt soms de index genoemd, maar tegenwoordig wordt het de wachtrij (staging area) genoemd.
 
 De algemene manier van werken met Git gaat ongeveer zo:
 
-1. Je bewerkt bestanden in je werkmap.
-2. Je bereidt de bestanden voor, waardoor momentopnames worden toegevoegd aan de wachtrij.
-3. Je maakt een commit. Een commit neemt alle momentopnames van de wachtrij en die permanent bewaard in je Gitmap.
+1.	Je bewerkt bestanden in je werk directory.
+2.	Je bereidt de bestanden voor (staged), waardoor momentopnames worden toegevoegd aan de wachtrij.
+3.	Je maakt een commit. Een commit neemt alle momentopnames van de wachtrij en bewaart die voorgoed in je Git directory.
 
-Als een bepaalde versie van een bestand in de Gitmap staat, wordt het beschouwd als gecommit. Als het is aangepast, maar wel aan de wachtrij is toegevoegd, is het voorbereid. En als het veranderd is sinds het gekopieerd werd, maar niet voorbereid is, is het aangepast. In Hoofdstuk 2 leer je meer over deze toestanden en hoe je er voordeel van kunt hebben, maar ook hoe je de wachtrij compleet over kunt slaan.
+Als een bepaalde versie van een bestand in de Git directory staat, wordt het beschouwd als gecommit. Als het is aangepast, maar wel aan de wachtrij is toegevoegd, is het staged. En als het veranderd is sinds het gekopiëerd werd, maar niet staged is, is het aangepast. In Hoofdstuk 2 leer je meer over deze toestanden en hoe je er je voordeel mee kunt doen, maar ook hoe je de wachtrij compleet over kunt slaan.
 
 ## Git installeren ##
 
-Laten we eens een beetje Git gebruiken. Je kunt natuurlijk niet meteen beginnen — je moet het eerst installeren. Er zijn een aantal manieren om eraan te komen; de belangrijkste twee zijn installeren vanaf broncode of een bestaand pakket voor jouw platform gebruiken.
+Laten we eens een wat Git gebruiken. Je kunt natuurlijk niet meteen beginnen — je moet het eerst installeren. Er zijn een aantal manieren om eraan te komen; de belangrijkste twee zijn installeren vanaf broncode of een bestaand pakket voor jouw platform gebruiken.
 
 ### Installeren vanaf de broncode ###
 
-Als het mogelijk is, is het meestal handig om Git vanaf de broncode te installeren, omdat je dan altijd de nieuwste versie hebt. Elke versie van Git brengt meestal goede verbeteringen aan de gebruikersinterface met zich mee, dus de laatste versie is vaak de beste manier als je het gewoon bent software vanaf de broncode te compileren. Vaak hebben Linuxdistributies behoorlijk oude pakketten - tenzij je een hele up-to-date distro hebt of ‘backports’ (verbeteringen van een nieuwe versie op een oudere versie toepassen) gebruikt - is installeren vanaf broncode misschien wel de beste manier voor jou.
+Als het mogelijk is, is het meestal nuttig om Git vanaf de broncode te installeren, omdat je dan altijd de recentste versie hebt. Elke versie van Git brengt meestal nuttige verbeteringen aan de gebruikersinterface met zich mee, dus de laatste versie is vaak de beste manier als je het gewend bent software vanaf de broncode te compileren. Vaak hebben Linuxdistributies behoorlijk oude pakketen - tenzij je een hele up-to-date distro hebt of ‘backports’ (verbeteringen van een nieuwe versie op een oudere versie toepassen) gebruikt - is installeren vanaf broncode misschien wel de beste manier voor jou.
 
-Om Git te installeren heb je een aantal bibliotheken (‘libraries’) nodig: curl, zlib, openssl, expat, en libiconv. Als je bijvoorbeeld op een systeem werkt dat yum heeft (zoals Fedora) of apt-get (zoals systemen gebaseerd op Debian), kun je één van de volgende commando's gebruiken om alle bibliotheken waar Git van afhangt te installeren:
+Om Git te installeren heb je een aantal bibliotheken (‘libraries’) nodig waar Git van afhankelijk is: curl, zlib, openssl, expat, en libiconv. Als je bijvoorbeeld op een systeem werkt dat yum heeft (zoals Fedora) of apt-get (zoals systemen gebaseerd op Debian), kun je één van de volgende commando's gebruiken om alle bibliotheken waar Git van afhankelijk is te installeren:
 
 	$ yum install curl-devel expat-devel gettext-devel \
 	  openssl-devel zlib-devel
@@ -145,13 +145,13 @@ Daarna compileren en installeren:
 	$ make prefix=/usr/local all
 	$ sudo make prefix=/usr/local install
 
-Als dat allemaal klaar is, kun je de nieuwste versie van Git uit Git ophalen met dit commando:
+Als dat allemaal klaar is, kun je de ook nieuwste versie van Git met Git ophalen met dit commando:
 
 	$ git clone git://git.kernel.org/pub/scm/git/git.git
 
 ### Op Linux installeren ###
 
-Als je direct de uitvoerbare bestanden van Git op Linux wilt installeren, kun je dat normaal doen via het standaard pakketbeheersysteem dat meegeleverd is met je distributie. Als je Fedora gebruikt kun je yum gebruiken:
+Als je direct de uitvoerbare bestanden van Git op Linux wilt installeren, kun je dat over het algemeen doen via het standaard pakketbeheersysteem dat meegeleverd is met je distributie. Als je Fedora gebruikt kun je yum gebruiken:
 
 	$ yum install git-core
 
@@ -168,7 +168,7 @@ Er zijn twee makkelijke manieren om Git op een Mac te installeren. De simpelste
 Insert 18333fig0107.png
 Figuur 1-7. Gitinstallatieprogramma voor OS X.
 
-De andere veelgebruikte manier is om Git via MacPorts (`http://www.macports.org`) te installeren. Als je MacPorts hebt, kun je Git installeren met
+De andere veelgebruikte manier is om Git via MacPorts (`http://www.macports.org`) te installeren. Als je MacPorts geïnstalleerd hebt, kun je Git installeren met
 
 	$ sudo port install git-core +svn +doc +bash_completion +gitweb
 
@@ -186,15 +186,15 @@ Opmerking voor Windows gebruikers: je zou Git moeten gebruiken met de msysGit sh
 
 ## Git klaarmaken voor eerste gebruik ##
 
-Nu je Git op je computer hebt staan, is het handig dat je een paar dingen doet om je Gitomgeving aan je voorkeuren aan te passen. Je hoeft deze instellingen normaliter maar één keer te doen. Ze blijven hetzelfde als je een nieuwe versie van Git installeert. Je kunt ze op elk moment weer veranderen door de commando’s opnieuw uit te voeren.
+Nu je Git op je computer hebt staan, is het handig dat je een paar dingen doet om je Gitomgeving aan je voorkeuren aan te passen. Je hoeft deze instellingen normaliter maar één keer te doen, ze blijven hetzelfde als je een nieuwe versie van Git installeert. Je kunt ze op elk moment weer veranderen door de commando’s opnieuw uit te voeren.
 
 Git bevat standaard een stuk gereedschap genaamd `git config`, waarmee je de configuratie-eigenschappen kunt bekijken en veranderen, die alle aspecten van het uiterlijk en gedrag van Git regelen. Deze eigenschappen kunnen op drie verschillende plaatsen worden bewaard:
 
 *	Het bestand `/etc/gitconfig`: Bevat eigenschappen voor elk account op de computer en al hun repositories. Als je de optie `--system` meegeeft aan `git config`, zal het de configuratiegegevens in dit bestand lezen of veranderen.
 *	Het bestand `~/.gitconfig`: Eigenschappen voor jouw account. Je kunt Git dit bestand laten gebruiken door de optie `--global` mee te geven.
-*	Het configuratiebestand in de Gitmap (dus `.git/config`) van het repository dat je op het moment gebruikt: Specifiek voor dat ene repository. Elk niveau is belangrijker dan het voorgaande, dus waarden in `.git/config` zullen worden gebruikt in plaats van die in `/etc/gitconfig`.
+*	Het configuratiebestand in de Gitmap (dus `.git/config`) van het repository dat je op het moment gebruikt: Specifiek voor die ene repository. Elk niveau neemt voorrang boven het voorgaande, dus waarden die in `.git/config` zijn gebruikt zullen worden gebruikt in plaats van die in `/etc/gitconfig`.
 
-Op systemen met Windows zoekt Git naar het `.gitconfig` bestand in de `$HOME` map (`%USERPROFILE%` in een Windows omgeving), welke `C:\Documents and Settings\$USER` is of `C:\Users\$USER` voor de meeste mensen, afhankelijk van de versie (`$USER` is `%USERNAME%` in een Windows omgeving). Het kijkt ook nog naar `/etc/gitconfig`, maar dan op de plek waar je MSys hebt staan, wat de plek is waar je Git op je Windowscomputer geïnstalleerd hebt.
+Op systemen met Windows zoekt Git in de `$HOME` directory naar het `.gitconfig`-bestand (`C:\Documents and Settings\$USER` voor de meesten). Het kijkt ook nog naar `/etc/gitconfig`, maar dan op de plek waar je MSys hebt staan, wat de plek is waar je Git op je Windowscomputer geïnstalleerd hebt.
 
 ### Jouw identiteit ###
 
@@ -203,7 +203,7 @@ Het eerste wat je zou moeten doen nadat je Git geïnstalleerd hebt, is je gebrui
 	$ git config --global user.name "John Doe"
 	$ git config --global user.email johndoe@example.com
 
-Nogmaals, dit hoef je maar één keer te doen als je de `--global` optie meegeeft, omdat Git die informatie zal gebruiken voor alles wat je doet op dat systeem. Als je een andere naam of e-mail wilt gebruiken voor specifieke projecten, kun je het commando uitvoeren zonder de `--global` optie als je in de map van dat project zit.
+Nogmaals, dit hoef je maar één keer te doen als je de `--global` optie erbij opgeeft, omdat Git die informatie zal gebruiken voor alles wat je doet op dat systeem. Als je een andere naam of e-mail wilt gebruiken voor specifieke projecten, kun je het commando uitvoeren zonder de `--global` optie als je in de directory van dat project zit.
 
 ### Je tekstverwerker ###
 
@@ -217,11 +217,11 @@ En andere bruikbare optie die je misschien wel wilt instellen is het standaard d
 
 	$ git config --global merge.tool vimdiff
 
-Git accepteert kdiff3, tkdiff, meld, xxdiff, emerge, vimdiff, gvimdiff, ecmerge en opendiff als geldige samenvoegingsgereedschappen. Je kunt ook een ander programma gebruiken; zie Hoofdstuk 7 voor meer informatie daarover.
+Git accepteert kdiff3, tkdiff, meld, xxdiff, emerge, vimdiff, gvimdiff, ecmerge en opendiff als geldige samenvoegingsgereedschappen. Je kunt ook een ander programma gebruiken, zie Hoofdstuk 7 voor meer informatie daarover.
 
 ### Je instellingen bekijken ###
 
-Als je je instellingen wilt zien, kan je `git config --list` gebruiken voor een lijstje met alle instellingen die Git vanaf de huidige map kan vinden:
+Als je je instellingen wilt zien, kan je het `git config --list` commando gebruiken voor een lijstje met alle instellingen die Git vanaf de huidige locatie kan vinden:
 
 	$ git config --list
 	user.name=Scott Chacon
@@ -251,7 +251,7 @@ Bijvoorbeeld, je kunt de gebruikershandleiding voor het commando `git config` kr
 
 	$ git help config
 
-Deze commando's zijn fijn omdat je ze overal kunt opvragen, zelfs als je offline bent.
+Deze commando's zijn prettig omdat je ze overal kunt opvragen, zelfs als je offline bent.
 Als de gebruiksaanwijzing en dit boek niet genoeg zijn en je persoonlijke hulp nodig hebt, kan je de kanalen `#git` of `#github` (beiden Engelstalig) op het Freenode IRC netwerk (irc.freenode.net) proberen. Deze kanalen zijn regelmatig gevuld met honderden mensen die allemaal zeer ervaren zijn met Git en vaak bereidwillig om te helpen.
 
 ## Samenvatting ##

From 3a76fc712f608eb566dfaafccaa4cb372cec28ad Mon Sep 17 00:00:00 2001
From: "J.M" <jm@jublo.net>
Date: Tue, 21 Jan 2014 18:27:00 +0100
Subject: [PATCH 129/690] [de] Update localization summary in README

---
 de/README.md | 36 ++++++++++++++++++------------------
 1 file changed, 18 insertions(+), 18 deletions(-)

diff --git a/de/README.md b/de/README.md
index 5d72f1653..2f13c8319 100644
--- a/de/README.md
+++ b/de/README.md
@@ -13,26 +13,26 @@ In diesem Projekt kannst Du Dich nun austoben und Deinen Beitrag zur Übersetzun
 Beispielhaftes Vorgehen:
 
 	git clone git@github.com:deinname/progit.git
-	
+
 	# Trage das deutsche Repository ebenso als Remote ein
 	git remote add progit-de git@github.com:progit-de/progit.git
-	
+
 	# Lokalen Branch anlegen und daran arbeiten
 	git checkout -b Chapter71
 	git commit -m "[de] Fix headings in chapter 7.1"
-	
+
 	# Wenn Deine Arbeit in sich abgeschlossen ist, kannst Du die Ergebnisse pushen.
 	# Vor einem Push solltest Du allerdings prüfen, ob sich zwischenzeitlich
 	# das Repository git@github.com:progit-de/progit.git aktualisiert hat.
 	git fetch progit-de
-	
-	# Falls es sich aktualisiert hat, führe einen Rebase aus und 
+
+	# Falls es sich aktualisiert hat, führe einen Rebase aus und
 	# behebe die ggf. aufgetretenden Konflikte
 	git rebase progit-de/next
-	
+
 	# Pushe Deine Ergebnisse in Dein Github Repository
 	git push origin
-	
+
 Informiere uns jetzt mit einem Pull Request unter Github, dass Dein Branch fertiggestellt und bereit zum mergen ist.
 
 Wir werden dann Dein Ergebnis prüfen bzw. ein weiterer Helfer wird Dein Ergebnis reviewen. Das kann dazu führen, dass Du Deine Übersetzung noch überarbeiten musst. Siehe das Review als positive Hilfestellung damit das Ergebnis insgesamt besser wird und nimm die Kritik nicht negativ auf. Danach werden wir Deine Arbeit übernehmen und schließlich in den Hauptzweig unter progit/progit einpflegen.
@@ -44,7 +44,7 @@ Die Commit Nachrichten beginnen mit einem vorangestellten [de], dann ein Leerzei
 Beispiel:
 
 	[de] Remove comment for Figure 7-1 because it is shown on git-scm.com
-	
+
 	- Bla bla blub
 
 ## Vorgaben für das Übersetzen ##
@@ -95,7 +95,7 @@ Beispiel:
 * Repository (Plural: Repositorys)
 * SHA-1
 * SHA-1-Hash (Genitiv: SHA-1-Hashes)
-* SHA-1-Hashwert (Plural: SHA-1-Hashwerte) 
+* SHA-1-Hashwert (Plural: SHA-1-Hashwerte)
 * SHA-1-Prüfsumme
 * SHA-1-Wert
 * stagen (gestaget, ungestaget)
@@ -556,63 +556,63 @@ Bitte den Status nicht aktualisieren. Dies übernimmt ein Maintainer.
 <td>Ja</td>
 <td>Nein</td>
 <td>Ja</td>
-<td bgcolor="yellow">Review notwendig</td>
+<td bgcolor="green">Ok</td>
 </tr>
 <tr>
 <td>9.1</td>
 <td>Ja</td>
 <td>Nein</td>
 <td>Ja</td>
-<td bgcolor="yellow">Review notwendig</td>
+<td bgcolor="green">Ok</td>
 </tr>
 <tr>
 <td>9.2</td>
 <td>Ja</td>
 <td>Nein</td>
 <td>Ja</td>
-<td bgcolor="yellow">Review notwendig</td>
+<td bgcolor="green">Ok</td>
 </tr>
 <tr>
 <td>9.3</td>
 <td>Ja</td>
 <td>Nein</td>
 <td>Ja</td>
-<td bgcolor="yellow">Review notwendig</td>
+<td bgcolor="green">Ok</td>
 </tr>
 <tr>
 <td>9.4</td>
 <td>Teilweise</td>
 <td>Nein</td>
 <td>Ja</td>
-<td bgcolor="yellow">Review notwendig</td>
+<td bgcolor="green">Ok</td>
 </tr>
 <tr>
 <td>9.5</td>
 <td>Ja</td>
 <td>Nein</td>
 <td>Ja</td>
-<td bgcolor="yellow">Review notwendig</td>
+<td bgcolor="green">Ok</td>
 </tr>
 <tr>
 <td>9.6</td>
 <td>Ja</td>
 <td>Nein</td>
 <td>Ja</td>
-<td bgcolor="yellow">Review notwendig</td>
+<td bgcolor="green">Ok</td>
 </tr>
 <tr>
 <td>9.7</td>
 <td>Ja</td>
 <td>Nein</td>
 <td>Ja</td>
-<td bgcolor="yellow">Review notwendig</td>
+<td bgcolor="green">Ok</td>
 </tr>
 <tr>
 <td>9.8</td>
 <td>Ja</td>
 <td>Nein</td>
 <td>Ja</td>
-<td bgcolor="yellow">Review notwendig</td>
+<td bgcolor="green">Ok</td>
 </tr>
 <tr>
 <td>Index of Commands</td>

From 4665f774ee823f809d0d6108334fe2e7e5ca4025 Mon Sep 17 00:00:00 2001
From: Broda Noel <brodanoel@gmail.com>
Date: Wed, 22 Jan 2014 17:04:23 -0300
Subject: [PATCH 130/690] [es] Fixed semantics errors

---
 es/05-distributed-git/01-chapter5.markdown | 350 ++++++++++++++++++++-
 1 file changed, 346 insertions(+), 4 deletions(-)

diff --git a/es/05-distributed-git/01-chapter5.markdown b/es/05-distributed-git/01-chapter5.markdown
index 91972492e..083205c9a 100644
--- a/es/05-distributed-git/01-chapter5.markdown
+++ b/es/05-distributed-git/01-chapter5.markdown
@@ -27,7 +27,7 @@ Al permitir multiples repositorios remotos, en Git es posible tener un flujo de
 1. La persona gestora del proyecto envia (push) a su repositorio público (repositorio principal).
 2. Una persona que desea contribuir, clona dicho repositorio y hace algunos cambios.
 3. La persona colaboradora envia (push) a su propia copia pública.
-4. Esta persona colaboradora envia a la gestora un correo-e solicitándole recupere e integre los cambios.
+4. Esta persona colaboradora envia a la gestora un correo electronico solicitándole recupere e integre los cambios.
 5. La gestora añade como remoto el repositorio de la colaboradora y fusiona (merge) los cambios localmente.
 6. La gestora envia (push) los cambios fusionados al repositorio principal.
 
@@ -299,7 +299,7 @@ Quedando su repositorio como se muestra en la Figura 5-12
 Insert 18333fig0512.png
 Figura 5-12. Historial inicial de Jessica.
 
-Cuando está preparada para enviar (push) su trabajo, recibe un correo-e de Josie de que ha puesto en el servidor una rama denominada 'featureBee', con algo de trabajo. Jessica necesita fusionar (merge) dichos cambios con los suyos antes de poder enviarlos al servidor. Por tanto, recupera (fetch) los cambios de Josie:
+Cuando está preparada para enviar (push) su trabajo, recibe un correo electronico de Josie de que ha puesto en el servidor una rama denominada 'featureBee', con algo de trabajo. Jessica necesita fusionar (merge) dichos cambios con los suyos antes de poder enviarlos al servidor. Por tanto, recupera (fetch) los cambios de Josie:
 
 	$ git fetch origin
 	...
@@ -323,7 +323,7 @@ Pero hay un pequeño problema, necesita enviar el trabajo fusionado en su rama '
 
 Esto es lo que se denomina un _refspec_. Puedes ver el Capítulo 9 para una discusión más detallada acerca de los _refspecs_ de Git y los distintos usos que puedes darles.
 
-A continuación, John envia un correo-e a jessica comentandole que ha enviado algunos cambios a la rama 'featureA' y pidiendole que los verifique. Ella lanza un 'git fetch' para recuperar dichos cambios:
+A continuación, John envia un correo electronico a jessica comentandole que ha enviado algunos cambios a la rama 'featureA' y pidiendole que los verifique. Ella lanza un 'git fetch' para recuperar dichos cambios:
 
 	$ git fetch origin
 	...
@@ -545,4 +545,346 @@ Tras esto, Git escupirá una serie de información de registro, con pinta más o
 	To: jessica@example.com
 	Subject: [PATCH 1/2] added limit to log function
 	Date: Sat, 30 May 2009 13:29:15 -0700
-	Message-Id: <12437153
+	Message-Id: <1243715356-61726-1-git-send-email-jessica@example.com>
+	X-Mailer: git-send-email 1.6.2.rc1.20.g8c5b.dirty
+	In-Reply-To: <y>
+	References: <y>
+
+	Result: OK
+
+En estos momentos, deberías poder ir a tu carpeta de borradores (Drafts), cambiar el destinatario (To) para apuntar a la lista de correo donde estés enviando el parche, puede que poner en copia (CC) al gestor o persona responsable, y enviar el mensaje.
+
+### Recapitulación ###
+
+En esta sección hemos visto unos cuantos de los flujos de trabajo más habituales para lidiar con distintos tipos de proyectos Git. Y hemos introducido un par de nuevas herramientas para ayudarte a gestionar estos procesos. A continuación veremos cómo trabajar en el otro lado de la moneda: manteniendo y gestionando un proyecto Git. Vas a aprender cómo ser un dictador benevolente o un gestor de integración.
+
+## Gestionando un proyecto ##
+
+Además de conocer cómo contribuir de forma efectiva a un proyecto, es posible que desees saber tambien cómo mantener uno. Lo cual implicará saber aceptar y aplicar parches generados vía `format-patch`, enviados a tí a través de correo electronico; o saber integrar cambios realizados en ramas de repositorios que añadirás como remotos a tu proyecto. Tanto si gestionas un repositorio canónico, como si deseas colaborar verificando o aprobando parches, necesitas saber cómo aceptar trabajo de otros de la forma más clara para tus contribuyentes y más sostenible para tí a largo plazo.
+
+### Trabajando con Ramas Puntuales ###
+
+Cuando estás pensando en integrar nuevo trabajo, suele ser buena idea utilizar una rama puntual para cada tema concreto --una rama temporal creada específicamente para trabajar dicho tema-- De esta forma, es sencillo tratar cada parche de forma individualizada y poder "aparcar" uno concreto cuando no trabajamos en él, hasta cuando volvamos a tener tiempo para retomarlo. Si creas los nombres de ramas basandolos en el tema sobre el que vas a trabajar, por ejemplo 'ruby client' o algo así de descriptivo, podrás recordar de qué iba cada rama en caso de que la abandones por un tiempo y la retomes más tarde. La persona gestora del proyecto Git suele tender a nombrar cada rama de foma parecida --por ejemplo 'sc/ruby client', donde sc es la abreviatura para la persona que ha contribuido con ese trabajo--.
+Como recordarás, la forma de crear una rama basandola en tu rama master es:
+
+	$ git branch sc/ruby_client master
+
+O, si deseas crearla y saltar inmediatamente a ella, puedes también utilizar la opción '-b' del comando 'checkout':
+
+	$ git checkout -b sc/ruby_client master
+
+Tras esto, estarás listo para añadir tu trabajo a esa rama puntual y ver si deseas o no fusionarla luego con alguna otra de tus ramas de más largo recorrido.
+
+### Aplicar parches recibidos por correo electronico ###
+
+Si vas a integrar en tu proyecto un parche recibido a través de un correo electrónico. Antes de poder evaluarlo, tendrás que incorporarlo a una de tus ramas puntuales. Tienes dos caminos para incorporar un parche recibido por correo electronico: usando el comando 'git apply' o usando el comando 'git am'.
+
+#### Incorporando un parche con apply ####
+
+Si recibes un parche de alguien que lo ha generado con el comando 'git diff' o con un comando 'diff' de Unix, puedes incorporalo con el comando 'git apply'. Suponiendo que has guardado el parche en '/tmp/patch-ruby-client.patch', puedes incorporarlo con una orden tal como:
+
+	$ git apply /tmp/patch-ruby-client.patch
+
+Esto modificará los archivos en tu carpeta de trabajo. Es prácticamente idéntico a lanzar el comando 'patch -p1', aunque es más paranoico y acepta menos coincidencias aproximadas. Además, es capaz de manejar adicciones, borrados o renombrados de archivos, si vienen en formato 'git diff'. Mientras que 'patch' no puede hacerlo. Por ultimo, citar que 'git apply' sigue un modelo de "aplicar todo o abortar todo", incorporando todos los cambios o no incorporando ninguno. Mientras que 'patch' puede incorporar cambios parcialmente, dejando tu carpeta de trabajo en un estado inconsistente. 'git apply' es, de lejos, mucho más paranoico que 'patch'. Nunca creará una confirmación de cambios (commit) por tí, --tras ejecutar el comando, tendrás que preparar (stage) y confirmar (commit) manualmente todos los cambios introducidos--.
+
+Tambien puedes utilizar 'git apply' para comprobar si un parche se puede incorporar limpiamente; antes de intentar incorporarlo. Puedes lanzar el comando 'git apply --check':
+
+	$ git apply --check 0001-seeing-if-this-helps-the-gem.patch
+	error: patch failed: ticgit.gemspec:1
+	error: ticgit.gemspec: patch does not apply
+
+Si obtienes una salida vacia, el parche se podrá incorporar limpiamente. Además, este comando retorna con un status no-cero en caso de fallar la comprobación, por lo que puedes utilizarlo en scripts si lo deseas.
+
+#### Incorporando un parche con am ####
+
+Si la persona que contribuye es usuaria de Git y conoce lo suficiente como para utilizar el comando 'format-patch' al generar su parche, tendrás mucho camino recorrido al incorporarlo; ya que el parche traerá consigo información sobre el o la autora, además de un mensaje de confirmación de cambios. Si puedes, anima a tus colaboradoras a utilizar 'format-patch' en lugar de 'diff' cuando vayan a generar parches. Solo deberías utilizar 'git apply' en caso de parches antiguos y similares.
+
+Para incorporar un parche generado con 'format-patch', utilizarás el comando 'git am'. Técnicamente, 'git am' se construyó para leer un archivo de buzón de correo (mbox file), que no es más que un simple formato de texto plano para almacenar uno o varios mensajes de correo electrónico en un solo archivo de texto. Es algo parecido a esto:
+
+	From 330090432754092d704da8e76ca5c05c198e71a8 Mon Sep 17 00:00:00 2001
+	From: Jessica Smith <jessica@example.com>
+	Date: Sun, 6 Apr 2008 10:17:23 -0700
+	Subject: [PATCH 1/2] add limit to log function
+
+	Limit log functionality to the first 20Limit log functionality to the first 20Limit log functionality to the first 20
+
+Esto es el comienzo de la salida del comando format-patch visto en la sección anterior. Es también un formato válido para un mbox. Si alguien te ha enviado correctamente un parche utilizando 'git send-email', y te lo has descargado a un formato mbox; podrás indicar dicho archivo mbox al comando 'git am', y este comenzará a incorporar todos los parches que encuentre dentro. Si tienes un cliente de correo electrónico capaz de guardar varios mensajes en formato mbox, podrás guardar series completas de parches en un mismo archivo; y luego usar 'git am' para irlos incorporando secuencialmente.
+
+Sin embargo, si alguien sube su archivo de parche a un sistema de gestión de peticiones de servicio o similar; tendrás que descargartelo a un archivo local en tu disco y luego indicar ese archivo local al comando 'git am':
+
+	$ git am 0001-limit-log-function.patch
+	Applying: add limit to log function
+
+Observarás que, tras incorporarlo limpiamente, crea automáticamente una nueva confirmación de cambios (commit). La información sobre el autor o autora la recoge de las cabeceras 'From' (Remitente) y 'Date' (Fecha). Y el mensaje para la confirmación (commit) lo recoge de 'Subject' (Asunto) y del cuerpo del correo electrónico. Por ejemplo, si consideramos el parche incorporado desde el mbox del ejemplo que acabamos de mostrar; la confirmación de camios (commit) generada será algo como:
+
+	$ git log --pretty=fuller -1
+	commit 6c5e70b984a60b3cecd395edd5b48a7575bf58e0
+	Author:     Jessica Smith <jessica@example.com>
+	AuthorDate: Sun Apr 6 10:17:23 2008 -0700
+	Commit:     Scott Chacon <schacon@gmail.com>
+	CommitDate: Thu Apr 9 09:19:06 2009 -0700
+
+	   add limit to log function
+
+	   Limit log functionality to the first 20Limit log functionality to the first 20Limit log functionality to the first 20
+
+El campo 'Commit' muestra la persona que ha incorporado el parche y cuándo lo ha incorporado. El campo 'Author' muestra la persona que ha creado originalmente el parche y cuándo fue creado este.
+
+Pero también podría suceder que el parche no se pudiera incorporar limpiamente. Es posible que tu rama principal diverja demasiado respecto de la rama sobre la que se construyó el parche; o que el parche tenga dependencias respecto de algún otro parche anterior que aún no hayas incorporado. En ese caso, el proceso 'git am' fallará y te preguntará qué deseas hacer:
+
+	$ git am 0001-seeing-if-this-helps-the-gem.patch
+	Applying: seeing if this helps the gem
+	error: patch failed: ticgit.gemspec:1
+	error: ticgit.gemspec: patch does not apply
+	Patch failed at 0001.
+	When you have resolved this problem run "git am --resolved".
+	If you would prefer to skip this patch, instead run "git am --skip".
+	To restore the original branch and stop patching run "git am --abort".
+
+Este comando pondrá marcadores de conflicto en cualquier archivo con problemas, de forma similar a como lo haría una operación de fusión (merge) o de reorganización (rebase). Y resolverás los problemas de la misma manera: editar el archivo para resolver los conflictos, prepararlo (stage), y lanzar 'git am --resolved' para continuar con el siguiente parche:
+
+	$ (fix the file)
+	$ git add ticgit.gemspec
+	$ git am --resolved
+	Applying: seeing if this helps the gem
+
+Si deseas más inteligencia por parte de Git al resolver conflictos, puedes pasarle la opción '-3', para que intente una fusión a tres bandas (three-way merge). Esta opción no se usa por defecto, porque no funcionará en caso de que la confirmación de cambios en que el parche dice estar basado no esté presente en tu repositorio.  Sin embargo, si tienes dicha confirmación de cambios (commit), --si el parche está basado en una confirmación pública--, entonces la opción '-3' suele ser mucho más avispada cuando incorporas un parche conflictivo:
+
+	$ git am -3 0001-seeing-if-this-helps-the-gem.patch
+	Applying: seeing if this helps the gem
+	error: patch failed: ticgit.gemspec:1
+	error: ticgit.gemspec: patch does not apply
+	Using index info to reconstruct a base tree...
+	Falling back to patching base and 3-way merge...
+	No changes -- Patch already applied.
+
+En este caso, estamos intentando incorporar un parche que ya tenemos incorporado. Sin la opción '-3', tendríamos problemas.
+
+Al aplicar varios parches desde un mbox, puedes lanzar el comando 'am' en modo interactivo; haciendo que se detenga en cada parche y preguntandote si aplicarlo o no:
+
+	$ git am -3 -i mbox
+	Commit Body is:
+	--------------------------
+	seeing if this helps the gem
+	--------------------------
+	Apply? [y]es/[n]o/[e]dit/[v]iew patch/[a]ccept all
+
+Es una utilidad interesante si tienes tienes almacenados unos cuantos parches, porque puedes ir revisando previamente cada parche y aplicarlos selectivamente.
+
+Cuando tengas integrados y confirmados todos los parches relativos al tema puntual en que estas trabajando, puedes plantearte cómo y cuándo lo vas a integar en alguna otra rama de más largo recorrido.
+
+### Recuperando ramas remotas ###
+
+Si recibes una contribución de un usuario que ha preparado su propio repositorio, ha guardado unos cuantos cambios en este, y luego te ha enviado la URL del repositorio y el nombre de la rama remota donde se encuentran los cambios. Puedes añadir dicho repositorio como un remoto y fusionar los cambios localmente.
+
+Por ejemplo, si Jessica te envia un correo electrónico comentandote que tiene una nueva e interesante funcionalidad en la rama 'ruby-client' de su repositorio. Puedes probarla añadiendo el remoto correspondiente y recuperando localmente dicha rama.
+
+	$ git remote add jessica git://github.com/jessica/myproject.git
+	$ git fetch jessica
+	$ git checkout -b rubyclient jessica/ruby-client
+
+Si más tarde vuelva a enviarte otro correo electronico avisandote de otra gran funcionalidad que ha incorporado, puedes recuperarla (fetch y checkout) directamente, porque tienes el remoto ya definido.
+
+Es muy util cuando trabajas regularmente con una persona. En cambio, si alguien tiene un solo parche para enviarte, una sola vez, puede ser más efectivo aceptarlo directamente por correo electronico; en lugar de pedir a todo el mundo que tenga cada uno su propio servidor y tener nosotros que estar continuamente añadiendo y quitando remotos para cada parche. También es muy posible que no quieras tener cientos de remotos, cada uno contribuyendo tan solo con un parche o dos. De todas formas, los scripts y los servicios albergados pueden hacerte la vida más facil en esto, --todo depende de cómo desarrolles tú y de como desarrollan las personas que colaboran contigo--.
+
+Otra ventaja de esta forma de trabajar es que recibes también el histórico de confirmaciones de cambio (commits). A pesar de poder seguir teniendo los habituales problemas con la fusión, por lo menos conoces en qué punto de tu historial han basado su trabajo. Por defecto, se aplicará una genuina fusión a tres bandas, en lugar de tener que poner un '-3' y esperar que el parche haya sido generado a partir de una confirmación de cambios (commit) pública a la que tengas tú también acceso.
+
+Si no trabajas habitualmente con una persona, pero deseas recuperar de ella por esta vía, puedes indicar directamente el URL del repositorio remoto en el comando 'git pull'. Esto efectua una recuperación (pull) puntual y no conserva la URL como una referencia remota:
+
+	$ git pull git://github.com/onetimeguy/project.git
+	From git://github.com/onetimeguy/project
+	 * branch            HEAD       -> FETCH_HEAD
+	Merge made by recursive.
+
+### Revisando lo introducido ###
+
+Ahora que tienes una rama puntual con trabajo aportado por otras personas. Tienes que decidir lo que deseas hacer con él. En esta sección revisaremos un par de comandos, que te ayudarán a ver exactamente los cambios que introducirás si fusionas dicha rama puntual con tu rama principal.
+
+Suele ser util revisar todas las confirmaciones de cambios (commits) que esten es esta rama, pero no en tu rama principal. Puedes excluir de la lista las confirmaciones de tu rama principal añadiendo la opción '--not' delante del nombre de la rama. Por ejemplo, si la persona colaboradora te envia dos parches y tu creas una rama 'contrib' donde aplicar dichos parches; puedes lanzar algo como esto:
+
+	$ git log contrib --not master
+	commit 5b6235bd297351589efc4d73316f0a68d484f118
+	Author: Scott Chacon <schacon@gmail.com>
+	Date:   Fri Oct 24 09:53:59 2008 -0700
+
+	    seeing if this helps the gem
+
+	commit 7482e0d16d04bea79d0dba8988cc78df655f16a0
+	Author: Scott Chacon <schacon@gmail.com>
+	Date:   Mon Oct 22 19:38:36 2008 -0700
+
+	    updated the gemspec to hopefully work better
+
+Para ver en detalle los cambios introducidos por cada confirmación (commit), recuerda que pasando la opción '-p' al comando 'git log', obtendrás un listado extendido con las diferencias introducidas por cada confirmación.
+
+Para ver plenamente todas las diferencias y lo que sucederá realmente si fusionas esta rama puntual con otra rama, tendrás que utilizar un pequeño truco para obtener los resultados correctos. Puedes pensar en lanzar esto:
+
+	$ git diff master
+
+Este comando te dará las diferencias, pero puede ser engañoso. Si tu rama 'master' ha avanzado con respecto al momento en que se creó la rama puntual a partir de ella, puedes obtener resultados realmente extraños. Debido a que Git compara directamente las instantáneas de la última confirmación de cambios en la rama puntual donde te encuentras y en la rama 'master'. Por ejemplo, si en la rama 'master' habias añadido una línea a un archivo, la comparación directa de instantáneas te llevará a pensar que la rama puntual va a borrar dicha línea.
+
+Si 'master' es un ancestro directo de tu rama puntual, no tendrás problemas. Pero si los historiales de las dos ramas son divergentes, la comparación directa de diferencias dará la apariencia de estar añadiendo todo el material nuevo en la rama puntual y de estar borrando todo el material nuevo en la rama 'master'.
+
+Y lo que realmente querías ver eran los cambios introducidos por la rama puntual, --el trabajo que vas a introducir si la fusionas con la rama 'master'--. Lo puedes hacer indicando a Git que compare la última confirmación  de cambios en la rama puntual, con el más reciente ancestro común que tenga esta respecto de la rama 'master'.
+
+Técnicamente, lo puedes hacer descubriendo tu mismo dicho ancestro común y lanzando la comprobación de diferencias respecto de él:
+
+	$ git merge-base contrib master
+	36c7dba2c95e6bbb78dfa822519ecfec6e1ca649
+	$ git diff 36c7db
+
+Pero esto no es lo más conveniente. De ahí que Git suministre otro atajo para hacerlo: la sintaxis del triple-punto. Estando en el contexto del comando 'diff', puedes indicar tres puntos entre los nombres de las dos ramas; para comparar entre la última confirmación de cambios de la rama donde estás y la respectiva confirmación común con la otra rama:
+
+	$ git diff master...contrib
+
+Este comando mostrará únicamente el trabajo en tu actual rama puntual que haya sido introducido a partir de su ancestro común con la rama 'master'. Es una sintaxis muy util, que merece recordar.
+
+### Integrando el trabajo aportado por otros ###
+
+Cuando todo el trabajo presente en tu rama puntual esté listo para ser integrado en una rama de mayor rango, la cuestión es cómo hacerlo. Yendo aún más lejos, ?cual es el sistema de trabajo que deseas utilizar para el mantenimiento de tu proyecto? Tienes bastantes opciones, y vamos a ver algunas de ellas.
+
+#### Fusionando flujos de trabajo ####
+
+Una forma simple de trabajar es fusionandolo todo en tu rama 'master'. En este escenario, tienes una rama 'master' que contiene, principalmente, código estable. Cuando en una rama puntual tienes trabajo ya terminado o contribuciones ya verificadas de terceros, los fusionas en tu rama 'master', borras la rama puntual, y continuas trabajando en otra/s rama/s.  Si, tal y como se muestra en la Figura 5-19,  tenemos un repositorio con trabajos en dos ramas, denominadas 'ruby client' y 'php client'; y fusionamos primero la rama 'ruby client' y luego la 'php client', obtendremos un historial similar al de la Figura 5-20.
+
+Insert 18333fig0519.png
+Figura 5-19. Historial con varias ramas puntuales.
+
+Insert 18333fig0520.png
+Figura 5-20. Tras fusionar una rama puntual.
+
+Este es probablemente el flujo de trabajo más sencillo. Pero puede dar problemas cuando estás tratando con grandes repositorios o grandes proyectos.
+
+Teniendo muchos desarrolladores o proyectos muy grandes, muy posiblemente desees utilizar un ciclo con por lo menos dos fases. En este escenario, se dispone de dos ramas de largo recorrido: 'master' y 'develop'. La primera de ellas, 'master', será actualizada únicamente por los lanzamientos de código muy estable. La segunda rama, 'develop', es donde iremos integrando todo el código nuevo.  Ambas ramas se enviarán periodicamente al repositorio público. Cada vez que tengas una nueva rama puntual lista para integrar (Figura 5-21), la fusionarás en la rama 'develop'. Y  cuando marques el lanzamiento de una versión estable, avanzarás la rama 'master' hasta el punto donde la rama 'develop' se encuentre en ese momento (Figura 5-23).
+
+Insert 18333fig0521.png
+Figura 5-21. Antes de fusionar una rama puntual.
+
+Insert 18333fig0522.png
+Figura 5-22. Tras fusionar una rama puntual.
+
+Insert 18333fig0523.png
+Figura 5-23. Tras un lanzamiento puntual.
+
+De esta forma, cuando alguien clone el repositorio de tu proyecto, podrá recuperar (checkout) y mantener actualizadas tanto la última version estable como la versión con el material más avanzado; en las ramas 'master' y 'develop', respectivamente.
+Puedes continuar ampliando este concepto, disponiendo de una rama 'integrate' donde ir fusionando todo el trabajo entre sí. A continuación, cuando el código en dicha rama sea estable y pase todas las pruebas, la fusionarás con la rama 'develop'; y, cuando se demuestre que permanece estable durante un cierto tiempo, avanzarás la rama 'master' hasta ahí.
+
+#### Flujos de trabajo con grandes fusiones ####
+
+El proyecto Git tiene cuatro ramas de largo recorrido: 'master', 'next', 'pu' (proposed updates) para el trabajo nuevo, y 'maint' (maintenance) para trabajos de mantenimiento de versiones previas. A medida que vamos introduciendo nuevos trabajos de las personas colaboradoras, estos se van recolectando en ramas puntuales en el repositorio de una persona gestora; de forma similar a como se ha ido describiendo (ver Figura 5-24). En un momento dado, las funcionalidades introducidas se evaluan; comprobando si son seguras y si están preparadas para los consumidores; o si, por el contrario, necesitan dedicarles más trabajo. Las funcionalidades que resultan ser seguras y estar preparadas se fusionan (merge) en la rama 'next'; y esta es enviada (push) al repositorio público, para que cualquiera pueda probarlas.
+
+Insert 18333fig0524.png
+Figura 5-24. Gestionando complejas series de ramas puntuales paralelas con funcionalidades varias.
+
+Si las funcionalidades necesitan ser más trabajadas, se fusionan (merge) en la rama 'pu'. Y cuando las funcionalidades permanecen totalmente estables, se refusionan en la rama 'master'; componiendolas desde las funcionalidades en la rama 'next' aún sin   promocionar a 'master'.  Esto significa que 'master' prácticamente siempre avanza; 'next' se reorganiza (rebase) de vez en cuando; y 'pu' es reorganizada con más frecuencia (ver Figura 5-25).
+
+Insert 18333fig0525.png
+Figura 5-25. Fusionando aportaciones de ramas puntuales en ramas de más largo recorrido.
+
+Una rama puntual se borra del repositorio cuando, finalmente, es fusionada en la rama 'master'. El proyecto Git dispone también de una rama 'maint' que se bifurca (fork) a partir de la última versión ya lanzada; para trabajar en parches, en caso de necesitarse alguna versión intermedia de mantenimiento. Así, cuando clonas el repositorio de Git, obtienes cuatro ramas que puedes recuperar (checkout); pudiendo evaluar el proyecto en distintos estadios de desarrollo, dependiendo de cuán avanzado desees estar o cómo desees contribuir. Y así, los gestores de mantenimiento disponen de un flujo de trabajo estructurado, para ayudarles en el procesado e incorporación de nuevas contribuciones.
+
+#### Flujos de trabajo reorganizando o entresacando ####
+
+Otros gestores de mantenimiento,  al procesar el trabajo recibido de las personas colaboradoras, en lugar de fusiones (merge), suelen preferir reorganizar (rebase) o entresacar (cherry-pick) sobre su propia rama principal; obteniendo así un historial prácticamente lineal. Cuando desees integrar el trabajo que tienes en una rama puntual, te puedes situar sobre ella y lanzar el comando 'rebase'; de esta forma recompondrás los cambios encima de tu actual rama 'master' (o 'develop' o lo que corresponda). Si funciona, se realizará un avance rápido (fast-forward) en tu rama 'master', y acabarás teniendo un historial lineal en tu proyecto.
+
+El otro camino para introducir trabajo de una rama en otra, es entresacarlo. Entresacar (cherry-pick) en Git es como reorganizar (rebase) una sola confirmación de cambios (commit). Se trata de coger el parche introducido por una determinada confirmación de cambios e intentar reaplicarlo sobre la rama donde te encuentres en ese momento. Puede ser util si tienes varias confirmaciones de cambios en una rama puntual, y tan solo deseas integar una de ellas; o si tienes una única confirmación de cambios en una rama puntual, y prefieres entresacarla en lugar de reorganizar. Por ejemplo, suponiendo que tienes un proyecto parecido al ilustrado en la Figura 5-26.
+
+Insert 18333fig0526.png
+Figura 5-26. Historial de ejemplo, antes de entresacar.
+
+Si deseas integar únicamente la confirmación 'e43a6' en tu rama 'master', puedes lanzar:
+
+	$ git cherry-pick e43a6fd3e94888d76779ad79fb568ed180e5fcdf
+	Finished one cherry-pick.
+	[master]: created a0a41a9: "More friendly message when locking the index fails."
+	 3 files changed, 17 insertions(+), 3 deletions(-)
+
+Esto introduce exactamente el mismo cambio introducido por 'e43a6', pero con un nuevo valor SHA-1 de confirmación; ya que es diferente la fecha en que ha sido aplicado. Tu historial quedará tal como ilustra la Figura 5-27.
+
+Insert 18333fig0527.png
+Figura 5-27. Historial tras entresacar una confirmación de cambios de una rama puntual.
+
+Ahora, ya puedes borrar la rama puntual y descartar las confirmaciones de cambios que no deseas integrar.
+
+### Marcando tus lanzamientos de versiones ###
+
+Cuando decides dar por preparada una versión, probablemente querrás etiquetar dicho punto de algún modo; de tal forma que, más adelante, puedas volver a generar esa versión en cualquier momento. Puedes crear una nueva etiqueta tal y como se ha comentado en el capítulo 2. Si decides firmar la etiqueta como gestor de mantenimientos que eres, el proceso será algo como:
+
+	$ git tag -s v1.5 -m 'my signed 1.5 tag'
+	You need a passphrase to unlock the secret key for
+	user: "Scott Chacon <schacon@gmail.com>"
+	1024-bit DSA key, ID F721C45A, created 2009-02-09
+
+Si firmas tus etiquetas, puedes tener un problema a la hora de distribuir la clave PGP pública utilizada en la firma. Los gestores del proyeto Git ha resuelto este problema incluyendo sus claves públicas como un objeto en el repositorio, añadiendo luego una etiqueta apuntando directamente a dicho contenido. Para ello, has de seleccionar cada clave que deseas incluir, lanzando el comando 'gpg ---list-keys':
+
+	$ gpg --list-keys
+	/Users/schacon/.gnupg/pubring.gpg
+	---------------------------------
+	pub   1024D/F721C45A 2009-02-09 [expires: 2010-02-09]
+	uid                  Scott Chacon <schacon@gmail.com>
+	sub   2048g/45D02282 2009-02-09 [expires: 2010-02-09]
+
+Tras esto, puedes importar directamente la clave en la base de datos Git, exportandola y redirigiendola a través del comando 'git hash-object'. Para, de esta forma, escribir un nuevo objeto dentro de Git y obtener de vuelta la firma SHA-1 de dicho objeto.
+
+	$ gpg -a --export F721C45A | git hash-object -w --stdin
+	659ef797d181633c87ec71ac3f9ba29fe5775b92
+
+Una vez tengas el contenido de tu clave guardado en Git, puedes crear una etiquta que apunte directamente al mismo; indicando para ello el nuevo valor SHA-1 que te ha devuelto el objeto 'hash-object':
+
+	$ git tag -a maintainer-pgp-pub 659ef797d181633c87ec71ac3f9ba29fe5775b92
+
+Si lanzas el comando 'git push --tags', la etiqueta 'maintainer-pgp-pub' será compartida por todos. Cualquiera que desee verificar la autenticidad de una etiqueta, no tiene más que importar tu clave PGP, sacando el objecto directamente de la base de datos e importandolo en GPG:,
+
+	$ git show maintainer-pgp-pub | gpg --import
+
+De esta forma, pueden utilizar esa clave para verificar todas las etiquetas que firmes. Además, si incluyes instrucciones en el mensaje de etiquetado, con el comando `git show <tag>`, los usuarios podrán tener directrices específicas acerca de la verificación de etiquetas.
+
+### Generando un número de ensamblado ###
+
+Debido a que Git no dispone de una serie monótona ascendente de números para cada confirmación de cambios (commit), si deseas tener un nombre humanamente comprensible por cada confirmación, has de utilizar el comando 'git describe'. Git te dará el nombre de la etiqueta más cercana, mas el número de confirmaciones de cambios entre dicha etiqueta y la confirmación que estas describiendo, más una parte de la firma SHA-1 de la confirmación:
+
+	$ git describe master
+	v1.6.2-rc1-20-g8c5b85c
+
+De esta forma, puedes exportar una instantánea u obtener un nombre comprensible por cualquier persona. Es más, si compilas Git desde código fuente clonado desde el repositorio Git, el comando 'git --version' te dará algo parecido. Si solicitas descripción de una confirmación de cambios (commit) etiquetada directamente con su propia etiqueta particular, obtendrás dicha etiqueta como descripción.
+
+El comando 'git describe' da preferencia a las etiquetas anotativas (etiquetas creadas  con las opciones '-a' o '-s'). De esta forma las etiquetas para las versiones pueden ser creadas  usando 'git describe', asegurandose el que las confirmaciones de cambios (commit) son adecuadamente nombradas cuando se describen. Tambien puedes utilizar esta descripción para indicar lo que deseas activar (checkout) o mostrar (show); pero realmente estarás usando solamente la parte final de la firma SHA-1 abreviada, por lo que no siempre será válida. Por ejemplo, el kernel de Linux ha saltado recientemente de 8 a 10 caracteres, para asegurar la unicidad de los objetos SHA-1; dando como resultado que los nombres antiguos de 'git describe' han dejado de ser válidos.
+
+### Preparando un lanzamiento de versión ###
+
+Si quieres lanzar una nueva versión. Una de las cosas que desearas crear es un archivo con la más reciente imagen de tu código, para aquellas pobres almas que no utilizan Git. El comando para hacerlo es 'git archive':
+
+	$ git archive master --prefix='project/' | gzip > `git describe master`.tar.gz
+	$ ls *.tar.gz
+	v1.6.2-rc1-20-g8c5b85c.tar.gz
+
+Quien abra ese archivo tarball, obtendrá la más reciente imagen de tu proyecto; puesta bajo una carpeta de proyecto. También puedes crear un archivo zip de la misma manera, tan solo indicando la opción '--format=zip' al comando 'git archive':
+
+	$ git archive master --prefix='project/' --format=zip > `git describe master`.zip
+
+Así, tendrás sendos archivos tarball y zip con tu nueva versión, listos para subirlos a tu sitio web o para ser enviados por correo electrónico a tus usuarios.
+
+### El registro rápido ###
+
+Ya va siendo hora de enviar un mensaje a tu lista de correo, informando a las personas que desean conocer la marcha de tu proyecto. Una manera elegante de generar rápidamente una lista con los principales cambios añadidos a tu proyecto desde la anterior versión, es utilizando el comando 'git shortlog'. Este comando resume todas las confirmaciones de cambios (commits) en el rango que le indiques. Por ejemplo, si tu último lanzamiento de versión lo fué de la v1.0.1:
+
+	$ git shortlog --no-merges master --not v1.0.1
+	Chris Wanstrath (8):
+	      Add support for annotated tags to Grit::Tag
+	      Add packed-refs annotated tag support.
+	      Add Grit::Commit#to_patch
+	      Update version and History.txt
+	      Remove stray `puts`
+	      Make ls_tree ignore nils
+
+	Tom Preston-Werner (4):
+	      fix dates in history
+	      dynamic version method
+	      Version bump to 1.0.2
+	      Regenerated gemspec for version 1.0.2
+
+Obtendrás un claro resumen de todas las confirmaciones de cambios (commit) desde la versión v1.0.1, agrupadas por autor, y listas para ser incorporadas en un mensaje a tu lista de correo.
+
+## Recapitulación ##
+
+A estas alturas, deberías sentirte confortable tanto contribuyendo a un proyecto, como manteniendo tu propio proyecto o integrando contribuciones de otras personas. Felicidades por haber llegado a ser un desarrollador Git efectivo!. En el capítulo siguiente, aprenderás el uso de más herramientas avanzadas y algunos trucos para tratar con situaciones complejas; haciendo de tí un verdadero maestro Git.

From c51d3b7e0f81fe98ad980a9e1b8832a6a274cca0 Mon Sep 17 00:00:00 2001
From: Wojciech Krawczyk <wojtekk@gmail.com>
Date: Sun, 26 Jan 2014 17:43:23 +0100
Subject: [PATCH 131/690] Fix misspellings

---
 pl/05-distributed-git/01-chapter5.markdown | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/pl/05-distributed-git/01-chapter5.markdown b/pl/05-distributed-git/01-chapter5.markdown
index 61032e009..fd5408ae4 100644
--- a/pl/05-distributed-git/01-chapter5.markdown
+++ b/pl/05-distributed-git/01-chapter5.markdown
@@ -377,15 +377,15 @@ Figure 5-11. Sekwencja zdarzeń dla prostego przepływu zmian między programist
 
 ### Prywatne zarządzane zespoły ###
 
-W tym scenariuszu, zobaczysz jak działa współpraca w większych prywatnych grupach. Nauczysz się jak pracować w środowisku w którym małe grupy współpracują ze sobą nad funkcjonalnościami, a następnie stworzone przez nich zmiany są integrowane przez inną osobą.
+W tym scenariuszu, zobaczysz jak działa współpraca w większych prywatnych grupach. Nauczysz się jak pracować w środowisku w którym małe grupy współpracują ze sobą nad funkcjonalnościami, a następnie stworzone przez nich zmiany są integrowane przez inną osobę.
 
 <!-- In this next scenario, you’ll look at contributor roles in a larger private group. You’ll learn how to work in an environment where small groups collaborate on features and then those team-based contributions are integrated by another party. -->
 
-Załóżmy że John i Jessica wspólnie pracują nad jedną funkcjonalnością, a Jessica i Josie nad drugą. W taj sytuacji, organizacja używa przepływu pracy z osobą integrującą zmiany, w której wyniki pracy poszczególnych grup są integrowane przez wyznaczone osoby, a gałąź `master` może być jedynie przez nie aktualizowana. W tym scenariuszu, cała praca wykonywana jest w osobnych gałęziach zespołów, a następnie zaciągana przez osoby integrujące.
+Załóżmy że John i Jessica wspólnie pracują nad jedną funkcjonalnością, a Jessica i Josie nad drugą. W tej sytuacji, organizacja używa przepływu pracy z osobą integrującą zmiany, w której wyniki pracy poszczególnych grup są integrowane przez wyznaczone osoby, a gałąź `master` może być jedynie przez nie aktualizowana. W tym scenariuszu, cała praca wykonywana jest w osobnych gałęziach zespołów, a następnie zaciągana przez osoby integrujące.
 
 <!-- Let’s say that John and Jessica are working together on one feature, while Jessica and Josie are working on a second. In this case, the company is using a type of integration-manager workflow where the work of the individual groups is integrated only by certain engineers, and the `master` branch of the main repo can be updated only by those engineers. In this scenario, all work is done in team-based branches and pulled together by the integrators later. -->
 
-Prześledźmy sposób pracy Jessici w czasie gdy pracuje ona nad obiema funkcjonalnościami, współpracując jednocześnie z dwoma niezależnymi programistami. Zakładając że ma już ona sklonowane repozytorium, rozpoczyna pracę nad funkcjonalnością `featureA`. Tworzy nową gałąź dla niej i wprowadza w niej zmiany:
+Prześledźmy sposób pracy Jessici w czasie gdy pracuje ona nad obiema funkcjonalnościami, współpracując jednocześnie z dwoma niezależnymi programistami. Zakładając że ma już sklonowane repozytorium, rozpoczyna pracę nad funkcjonalnością `featureA`. Tworzy nową gałąź dla niej i wprowadza w niej zmiany:
 
 <!-- Let’s follow Jessica’s workflow as she works on her two features, collaborating in parallel with two different developers in this environment. Assuming she already has her repository cloned, she decides to work on `featureA` first. She creates a new branch for the feature and does some work on it there: -->
 

From 3f404d1f1c475070b223db66f790372b3ae9a7ec Mon Sep 17 00:00:00 2001
From: Zhenye YU <riccoyu@gmail.com>
Date: Tue, 28 Jan 2014 15:25:34 +0800
Subject: [PATCH 132/690] [zh] Change font of pdf format to 'WenQuanYi Micro
 Hei', which looks better

---
 latex/config.yml | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/latex/config.yml b/latex/config.yml
index 2ed0f7939..33d11a1e7 100644
--- a/latex/config.yml
+++ b/latex/config.yml
@@ -15,9 +15,9 @@ default:
   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}"
 zh:
   langrule: "\\XeTeXlinebreakskip=0em plus 0.1em minus 0.01em\n\\XeTeXlinebreakpenalty=0"
-  font: AR PL UMing CN
-  bold: AR PL UKai CN
-  mono: AR PL UKai CN
+  font: WenQuanYi Micro Hei
+  bold: WenQuanYi Micro Hei Mono
+  mono: WenQuanYi Micro Hei Mono
   prechap: "第"
   postchap: "章"
   presect: ""

From 3da5f7c481fe4d59c9487762833a4c4c06e5bb7b Mon Sep 17 00:00:00 2001
From: Cor <git@cpt1.demon.nl>
Date: Wed, 29 Jan 2014 09:23:50 +0100
Subject: [PATCH 133/690] [nl] Retranslate chapter 03

Reshuffle wording and sentences. Replace some Babelfish type translations
with more sensible translations. Introduce diacritics to enhance clarity.
---
 nl/03-git-branching/01-chapter3.markdown | 262 +++++++++++------------
 1 file changed, 131 insertions(+), 131 deletions(-)

diff --git a/nl/03-git-branching/01-chapter3.markdown b/nl/03-git-branching/01-chapter3.markdown
index c850eb23a..78dc75ca0 100644
--- a/nl/03-git-branching/01-chapter3.markdown
+++ b/nl/03-git-branching/01-chapter3.markdown
@@ -1,38 +1,38 @@
 # Branchen in Git #
 
-Bijna elk versiebeheersysteem ondersteunt een bepaalde vorm van branchen. Branchen komt erop neer dat je een tak afsplitst van de grote lijn van de ontwikkeling en daar verder mee werkt zonder de hoofdlijn te vervuilen. Bij veel VCS'en gaat dat nogal moeizaam, en eisen vaak van je dat je een nieuwe kopie maakt van de map waar je bronbestanden in staan, wat lang kan duren voor grote projecten.
+Bijna elk versiebeheersysteem ondersteunt een bepaalde vorm van branchen. Branchen komt erop neer dat je een tak afsplitst van de hoofd ontwikkellijn en daar verder mee gaat werken zonder aan de hoofdlijn te komen. Bij veel VCS'en is dat nogal een duur proces, vaak wordt er een nieuwe kopie gemaakt van de directory waar je broncode in staan, wat lang kan duren voor grote projecten.
 
-Sommige mensen verwijzen naar het branch model in Git als de "killer eigenschap", en het maakt Git zeker apart in de VCS gemeenschap. Waarom is het zo bijzonder? De manier waarop Git branched is ongelooflijk lichtgewicht, waardoor branch operaties vrijwel instant zijn en het wisselen tussen de branches over het algemeen net zo snel. In tegenstelling to vele andere VCS's, moedigt Git een werkwijze aan die vaak branched en merged, zelfs meerdere keren per dag. Deze eigenschap begrijpen en beheersen geeft je een krachtig en uniek gereedschap en kan letterlijk de manier waarop je ontwikkelt veranderen.
+Sommige mensen verwijzen naar het branch model in Git als de "killer eigenschap", en het onderscheidt Git zeker in de VCS gemeenschap. Waarom maakt het zo bijzonder? De manier waarop Git branched is ongelooflijk lichtgewicht, waardoor branch operaties vrijwel instant zijn en het wisselen tussen de branches over het algemeen net zo snel. In tegenstelling to vele andere VCS's, moedigt Git juist een werkwijze aan die vaak branched en merged, zelfs meerdere keren per dag. Deze eigenschap begrijpen en de techniek beheersen geeft je een krachtig en uniek gereedschap en kan letterlijk de manier waarop je ontwikkelt veranderen.
 
 ## Wat een branch is ##
 
-Om de manier waarop Git branched echt te begrijpen, moeten we een stap terug doen en onderzoeken hoe Git zijn gegevens opslaat. Zoals je je kunt herinneren van Hoofdstuk 1, slaat Git zijn gegevens niet op als een reeks van sets met wijzigingen of delta's, maar in plaats daarvan als een serie snapshots.
+Om de manier waarop Git branched echt te begrijpen, moeten we een stap terug doen en onderzoeken hoe Git zijn gegevens opslaat. Zoals je misschien herinnert van Hoofdstuk 1, slaat Git zijn gegevens niet op als een reeks van wijzigingen of delta's, maar in plaats daarvan als een serie snapshots.
 
-Als je in Git commit, dan slaat Git een commit object op dat een verwijzing bevat naar het snapshot van de inhoud die je gestaged hebt, de auteur en bericht metagegevens, en nul of meer verwijzingen naar de commit of commits die de directe ouders van deze commit waren: nul ouders voor de eerste commit, één ouder voor een normale commit, en meerdere ouders voor een commit die resulteert uit een samenvoeging of twee of meer branches.
+Als je in Git commit, dan slaat Git een commit object op dat een verwijzing bevat naar het snapshot van de inhoud die je gestaged hebt, de auteur en bericht metagegevens, en nul of meer verwijzingen naar de commit of commits die de directe ouders van deze commit waren: nul ouders voor de eerste commit, één ouder voor een normale commit, en meerdere ouders voor een commit die het resultaat is van een merge van twee of meer branches.
 
-Om dit te visualiseren, laten we aannemen dat je een map hebt die drie bestanden bevat, en je staged ze allemaal en commit. Door de bestanden te stagen krijgen ze allen een checksum (de SHA-1 hash die we in Hoofdstuk 1 noemden), bewaart die versie van het bestand in het Git repository (Git verwijst ernaar als blobs), en voegt die checksum toe aan het stage gebied:
+Om dit te visualiseren, gaan we aannemen dat je een directory hebt met drie bestanden, en je staged en commit ze allemaal. Door de bestanden te stagen krijgen ze allemaal een checksum (de SHA-1 hash waar we het in Hoofdstuk 1 over hadden), bewaart die versie van het bestand in het Git repository (Git noemt ze blobs), en voegt die checksum toe aan het stage gebied:
 
 	$ git add README test.rb LICENSE
 	$ git commit -m 'initial commit of my project'
 
-Als je de commit aanmaakt door `git commit` uit te voeren, zal Git iedere submap van een checksum voorzien (in dit geval, alleen de hoofdmap); en die drie objecten in het Git repository opslaan. Daarna creëert Git een commit object dat de metagegevens bevat en een verwijzing naar de hoofd project boom zodat het het snapshot kan namaken als dat nodig is.
+Als je de commit aanmaakt door `git commit` uit te voeren zal Git iedere project directory van een checksum voorzien en slaat ze als boomstructuur (`tree`) objecten in de Git repository op. Daarna creëert Git een `commit` object dat de metagegevens bevat en een verwijzing naar de hoofd project `tree`-object zodat Git deze snapshot kan opnieuw kan maken als dat nodig is.
 
-Je Git repository bevat nu vijf objecten: een blob voor de inhoud van ieder van je drie bestanden, een boom dat de inhoud van de map weergeeft en specificeert welke bestandsnamen opgeslagen zijn als welke blobs, en een commit met de verwijzing naar die hoofd boom en alle commit metagegevens. Conceptueel zien de gegevens in je Git repository eruit zoals in Figuur 3-1.
+Je Git repository bevat nu vijf objecten: een blob voor de inhoud van ieder van de drie bestanden, een tree die de inhoud van de directory weergeeft en specificeert welke bestandsnamen opgeslagen zijn als welke blobs, en een commit met de verwijzing naar die hoofd tree en alle commit metagegevens. Conceptueel zien de gegevens in je Git repository eruit zoals in Figuur 3-1.
 
 Insert 18333fig0301.png
-Figuur 3-1. Enkele commit repository gegevens.
+Figuur 3-1. Repository gegevens van een enkele commit.
 
-Als je wat wijzigingen doet en nogmaals commit, dan slaat de volgende commit een verwijzing op naar de commit die er direct aan vooraf ging. Na nog eens twee commits, zal je historie er misschien uit zien als Figuur 3-2.
+Als je wat wijzigingen maakt en nogmaals commit, dan slaat de volgende commit een verwijzing op naar de commit die er direct aan vooraf ging. Na nog eens twee commits, zal je historie er ongeveer uit zien als Figuur 3-2.
 
 Insert 18333fig0302.png
 Figuur 3-2. Git object gegevens voor meerdere commits.
 
-Een branch in Git is simpelweg een lichtgewicht verplaatsbare verwijzing naar een van deze commits. De standaard branch naam in Git is master. Als je initieel commits maakt, dan wordt je een master branch gegeven die wijst naar de laatste commit die je gemaakt hebt. Iedere keer als je commit, beweegt het automatisch vooruit.
+Een branch in Git is simpelweg een lichtgewicht verplaatsbare verwijzing naar een van deze commits. De standaard branch naam in Git is master. Als je initieel commits maakt, dan krijg je een `master` branch die wijst naar de laatste commit die je gemaakt hebt. Iedere keer als je commit, beweegt het automatisch vooruit.
 
 Insert 18333fig0303.png
 Figuur 3-3. Branch wijzend in de commit gegevens historie.
 
-Wat gebeurt er als je een nieuwe branch maakt? Wel, door dat te doen wordt een nieuwe verwijzing aangemaakt voor jou om te verplaatsen. Laten we zeggen dat je een nieuwe branch genaamd testing maakt. Je doet dit met het `git branch` commando:
+Wat gebeurt er als je een nieuwe branch maakt? Door dat te doen wordt een nieuwe verwijzing voor jou aangemaakt die je dan kunt verplaatsen. Laten we zeggen dat je een nieuwe branch genaamd testing maakt. Je doet dit met het `git branch` commando:
 
 	$ git branch testing
 
@@ -41,12 +41,12 @@ Dit maakt een nieuwe verwijzing naar dezelfde commit waar je nu op zit (zie Figu
 Insert 18333fig0304.png
 Figuur 3-4. Meerdere branches wijzend naar de commit gegevens historie.
 
-Hoe weet Git op welke branch je nu zit? Het houdt een speciale verwijzing bij genaamd HEAD. Let op dat dit heel anders is dan het concept van HEAD in andere VCS's waar je misschien gewend aan bent, zoals bijvoorbeeld Subversion of CVS. In Git, is dit een verwijzing naar de lokale branch waar je nu op zit. In dit geval, zit je nog steeds op master. Het git branch commando heeft alleen een nieuwe branch aangemaakt — het is nog niet omgeschakeld naar die branch (zie Figuur 3-5).
+Hoe weet Git op welke branch je nu zit? Het houdt een speciale verwijzing bij genaamd HEAD. Let op dat dit heel anders is dan het concept van HEAD in andere VCS's waar je misschien gewend aan bent, zoals bijvoorbeeld Subversion of CVS. In Git, is dit een verwijzing naar de lokale branch waar je nu op zit. In dit geval, zit je nog steeds op master. Het git branch commando heeft alleen een nieuwe branch aangemaakt — het is nog niet overgeschakeld naar die branch (zie Figuur 3-5).
 
 Insert 18333fig0305.png
 Figuur 3-5. HEAD bestand wijzend naar de branch waar je op zit.
 
-Om te schakelen naar een bestaande branch, voer je het `git checkout` commando uit. Laten we eens omschakelen naar de nieuwe testing branch:
+Om over te schakelen naar een bestaande branch, voer je het `git checkout` commando uit. Laten we eens overschakelen naar de nieuwe testing branch:
 
 	$ git checkout testing
 
@@ -65,7 +65,7 @@ Figuur 3-7 toont het resultaat.
 Insert 18333fig0307.png
 Figuur 3-7. De branch waar HEAD naar wijst gaat vooruit met iedere commit.
 
-Dit is interessant, omdat je testing branch nu vooruit is gegaan, maar je master branch nog steeds wijst naar de commit waar je op was toen je `git checkout` uitvoerde om om te schakelen. Laten we eens terugschakelen naar de master branch:
+Dit is interessant, omdat je testing branch nu vooruit is gegaan, maar je master branch nog steeds wijst naar de commit waar je op was toen je `git checkout` uitvoerde voor het overschakelen. Laten we eens terugschakelen naar de `master` branch:
 
 	$ git checkout master
 
@@ -74,21 +74,21 @@ Figuur 3-8 toont het resultaat.
 Insert 18333fig0308.png
 Figuur 3-8. HEAD verschuift naar een andere branch bij een checkout.
 
-Dat commando deed twee dingen. Het verplaatste de HEAD verwijzing terug naar de master branch, en het draaide de bestanden in je werkmap terug naar het snapshot waar master naar wijst. Dit betekent ook dat de wijzigingen die je vanaf dit punt maakt zullen afwijken van een oudere versie van het project. Het betekent in essentie dat het het werk dat je in je testing branch hebt gedaan tijdelijk terugdraait zodat je in een andere richting kunt gaan.
+Dat commando heeft twee dingen gedaan. Het verplaatste de HEAD verwijzing terug naar de `master` branch, en het draaide de bestanden in je werkdirectory terug naar het snapshot waar die `master` naar wijst. Dit betekent ook dat de wijzigingen die je vanaf dit punt maakt uiteen zullen gaan lopen met een oudere versie van het project. In essentie betekent dat het werk dat je in je testing branch hebt gedaan tijdelijk wordt teruggedraait, zodat je een andere richting op kunt gaan.
 
-Laten we een paar wijzigingen doen en nog eens committen:
+Laten we een paar wijzigingen maken en nog eens committen:
 
 	$ vim test.rb
 	$ git commit -a -m 'made other changes'
 
-Nu is je project historie afgeweken (zie Figuur 3-9). Je hebt een branch gemaakt en bent er naartoe omgeschakeld, hebt er wat werk op gedaan, en bent toen teruggeschakeld naar je hoofd branch en hebt nog ander werk gedaan. Beide van die veranderingen zijn geïsoleerd van elkaar in aparte branches: je kunt heen en weer schakelen tussen de branches en ze samenvoegen als je klaar bent. En je hebt dat alles gedaan met eenvoudige `branch` en `checkout` commando's.
+Nu is je project historie uiteen gelopen (zie Figuur 3-9). Je hebt een branch gemaakt en bent er naartoe overgeschakeld, hebt er wat werk op gedaan, en bent toen teruggeschakeld naar je hoofd branch en hebt nog wat ander werk gedaan. Al die veranderingen zijn geïsoleerd van elkaar in aparte branches: je kunt heen en weer schakelen tussen de branches en ze mergen als je klaar bent. En je hebt dat alles gedaan met eenvoudige `branch` en `checkout` commando's.
 
 Insert 18333fig0309.png
-Figuur 3-9. De branch histories zijn uiteen gegaan.
+Figuur 3-9. De branch histories zijn uiteen gaan lopen.
 
-Omdat een branch in Git in feite een eenvoudig bestand is dat de 40 karakter lange SHA-1 checksum van de commit bevat waar het naar wijst, zijn branches goedkoop om te maken en weg te gooien. Een nieuwe branch aanmaken is zo makkelijk en eenvoudig als 41 bytes naar een bestand schrijven (40 karakters en een harde return).
+Omdat een branch in Git in feite een eenvoudig bestand is dat de 40 karakter lange SHA-1 checksum van de commit bevat waar het naar wijst, zijn branches goedkoop om te maken en weer weg te gooien. Een nieuwe branch aanmaken is zo snel en eenvoudig als 41 bytes naar een bestand schrijven (40 karakters en een harde return).
 
-Dit is in scherp contrast met de manier waarop de meeste VCS applicaties branchen, wat inhoud dat alle project bestanden naar een tweede map gekopieerd worden. Dit kan enkele seconden of zelfs minuten duren, afhankelijk van de grootte van het project, en daarentegen is het in Git altijd meteen klaar. En omdat we de ouders opslaan terwijl we committen, wordt het vinden van een goed punt als basis voor het samenvoegen automatisch voor ons gedaan en is over het algemeen eenvoudig om te doen. Deze eigenschappen helpen ontwikkelaars aan te moedigen om branches vaak aan te maken en te gebruiken.
+Dit is in scherp contrast met de wijze waarop de meeste VCS applicaties branchen, wat vaak het kopiëren van alle project bestanden naar een tweede map inhoudt. Dit kan enkele seconden of zelfs minuten duren, afhankelijk van de grootte van het project, daarentegen is het in Git altijd vrijwel meteen klaar. En omdat we de ouders opslaan terwijl we committen, wordt het vinden van een goed punt dat kan dienen als basis voor het mergen automatisch voor ons gedaan en is dat over het algemeen eenvoudig om te doen. Deze eigenschappen helpen ontwikkelaars met vertrouwen branches vaak aan te maken en te gebruiken.
 
 Laten we eens kijken waarom je dat zou moeten doen.
 
@@ -114,7 +114,7 @@ Als eerste, laten we zeggen dat je aan je project werkt en al een paar commits h
 Insert 18333fig0310.png
 Figuur 3-10. Een korte en eenvoudige commit historie.
 
-Je hebt besloten dan je gaat werken aan probleem #53 in wat voor probleem beheersysteem je bedrijf ook gebruikt. Om duidelijk te zijn, Git is niet verbonden een een probleem beheersysteem in het bijzonder; maar omdat probleem #53 een beperkt onderwerp is waar je aan werkt, zul je een nieuwe branch aanmaken waarin je gaat werken. Om een branch aan te maken en er meteen naartoe te schakelen, kun je het `git checkout` commando uitvoeren met de `-b` optie:
+Je hebt besloten dan je gaat werken aan probleem #53 in wat voor systeem je bedrijf ook gebruikt om problemen te registreren. Voor de duidelijkheid: Git is niet verbonden met een probleem beheersysteem in het bijzonder, maar omdat probleem #53 een specifiek onderwerp is waar je aan wilt werken, zul je een nieuwe branch aanmaken waarin je gaat werken. Om een branch aan te maken en er meteen naartoe te schakelen, kun je het `git checkout` commando uitvoeren met de `-b` optie:
 
 	$ git checkout -b iss53
 	Switched to a new branch "iss53"
@@ -137,16 +137,16 @@ Je doet wat werk aan je web site en doet wat commits. Door dat te doen beweegt d
 Insert 18333fig0312.png
 Figuur 3-12. De iss53 branch is vooruit gegaan met je werk.
 
-Nu krijg je het telefoontje dan er een probleem is met de web site, en je moet het meteen repareren. Met Git hoef je je reparatie niet meteen uit te leveren samen met de `iss53` wijzigingen die je gedaan hebt, en je hoeft ook niet veel moeite te stoppen in het terugdraaien van die wijzigingen voordat je kunt werken aan het toepassen van je reparatie in productie. Het enige dat je moet doen in terugschakelen naar je master branch.
+Nu krijg je het telefoontje dan er een probleem is met de web site, en je moet het meteen repareren. Met Git hoef je de reparatie niet tegelijk uit te leveren met de `iss53` wijzigingen die je gemaakt hebt, en je hoeft ook niet veel moeite te doen om die wijzigingen terug te draaien voordat je kunt werken aan het toepassen van je reparatie in productie. Het enige wat je moet doen in terugschakelen naar je master branch.
 
-Maar, voordat je dat doet, let dan op dat als je werkmap of staging gebied wijzigingen bevat die nog niet gecommit zijn en conflicteren met de branch die je gaat uitchecken, dan laat Git je niet omschakelen. Het is het beste om een schone werk status te hebben als je tussen branches gaat schakelen. Er zijn altijd manieren om hier omheen te gaan (te weten, stashen en commit ammending). die we later gaan behandelen. Voor nu, heb je al je wijzigingen gecommit, zodat je terug kunt schakelen naar je master branch:
+Maar voordat je dat doet, let op dat als je werk directory of staging gebied wijzigingen bevat die nog niet gecommit zijn en conflicteren met de branch die je gaat uitchecken, Git je niet toestaat om te schakelen. Het is het beste om een schone werk status te hebben als je tussen branches gaat schakelen. Er zijn manieren om hier mee om te gaan (te weten, stashen en commit ammending) die we later gaan behandelen. Voor nu heb je alle wijzigingen gecommit, zodat je terug kunt schakelen naar je master branch:
 
 	$ git checkout master
 	Switched to branch "master"
 
-Op dit punt, is je project werkmap precies zoals het was voordat je begon te werken aan probleem #53, en je kunt je concentreren op je snelle reparatie. Dit is een belangrijk punt om te onthouden: Git herstelt je werkmap zodat die eruit ziet als het snapshot van de commit waar de branch die je uitchecked naar wijst. Het voegt toe, verwijdert en wijzigt bestanden automatisch om er zeker van te zijn dat je werkkopie eruit ziet zoals de branch eruit zag toen je er voor het laatst op committe.
+Hierna, is je project werk directory precies zoals het was voordat je begon te werken aan probleem #53, en je kunt je concentreren op je snelle reparatie. Dit is een belangrijk punt om te onthouden: Git herstelt je werk directory zodanig dat deze eruit ziet als het snapshot van de commit waar de branch die je uitchecked naar wijst. Het voegt automatisch bestanden toe, verwijdert en wijzigt ze om er zeker van te zijn dat je werkkopie eruit ziet zoals de branch eruit zag toen je er voor het laatst op committe.
 
-Vervolgens heb je een snelle reparatie te doen. Laten we een reparatie branch maken om op te werken totdat het af is (zie Figuur 3-13):
+Vervolgens heb je een snelle reparatie (hotfix) te doen. Laten we een reparatie branch maken om op te werken totdat het af is (zie Figuur 3-13):
 
 	$ git checkout -b hotfix
 	Switched to a new branch "hotfix"
@@ -158,7 +158,7 @@ Vervolgens heb je een snelle reparatie te doen. Laten we een reparatie branch ma
 Insert 18333fig0313.png
 Figuur 3-13. snelle reparatie branch gebaseerd op de tip van je master branch.
 
-Je kunt je tests draaien, er zeker van zijn dat de reparatie is wat je wil, en het samenvoegen met je master branch om het naar productie uit te rollen. Je doet dit met het `git merge` commando:
+Je kunt je tests draaien, je erzelf van verzekeren dat de reparatie is wat je wil, en het mergen in je master branch en het naar productie uitrollen. Je doet dit met het `git merge` commando:
 
 	$ git checkout master
 	$ git merge hotfix
@@ -167,14 +167,14 @@ Je kunt je tests draaien, er zeker van zijn dat de reparatie is wat je wil, en h
 	 README |    1 -
 	 1 files changed, 0 insertions(+), 1 deletions(-)
 
-Je zult de uitdrukking "Fast forward" zien in die samenvoeging. Omdat de commit van de branch waar je mee samenvoegde direct stroomopwaarts was van de commit waar je op zit, zal Git de verwijzing vooruit zetten. Om dat op een andere manier te zeggen, als je een commit probeert samen te voegen met een commit die bereikt kan worden door de historie van eerste commit te volgen, zal Git de dingen vereenvoudigen door de verwijzing vooruit te verplaatsen omdat er geen afwijkend werk is om samen te voegen — dit wordt een "fast forward" genoemd.
+Je zult de uitdrukking "Fast forward" zien in die merge. Omdat de commit van de branch waar je mee samenvoegde direct stroomopwaarts was van de commit waar je op zit, zal Git de verwijzing vooruit verplaatsen. Om het op een andere manier te zeggen, als je een commit probeert te mergen met een commit die bereikt kan worden door de historie van eerste commit te volgen, zal Git de dingen vereenvoudigen door de verwijzing vooruit te verplaatsen omdat er geen afwijkend werk is om rte mergen; dit wordt een "fast forward" genoemd.
 
-Je wijziging is nu in het snapshot van de commit waar de `master` branch naar wijst, en je kunt je wijziging uitrollen (zie Figuur 3-14).
+Je wijziging zit nu in het snapshot van de commit waar de `master` branch naar wijst, en je kunt je wijziging uitrollen (zie Figuur 3-14).
 
 Insert 18333fig0314.png
 Figuur 3-14. Je master branch wijst naar dezelfde plek als de snelle reparatie branch na de wijziging.
 
-Nadat je super-belangrijke reparatie uitgerold is, ben je klaar om terug te schakelen naar het werk dat je deed voordat je onderbroken werd. Maar, eerst zul je de snelle reparatie branch verwijderen, omdat je die niet langer nodig hebt — de `master` branch wijst naar dezelfde plek. Je kunt het verwijderen met de `-d` optie op `git branch`:
+Nadat je super-belangrijke reparatie uitgerold is, ben je klaar om terug te schakelen naar het werk dat je deed voordat je onderbroken werd. Maar, eerst zul je de snelle reparatie branch verwijderen, omdat je die niet langer nodig hebt: de `master` branch wijst naar dezelfde plek. Je kunt het verwijderen met de `-d` optie op `git branch`:
 
 	$ git branch -d hotfix
 	Deleted branch hotfix (3a0874c).
@@ -191,11 +191,11 @@ Nu kun je terugschakelen naar je werk in uitvoering branch voor probleem #53 en
 Insert 18333fig0315.png
 Figuur 3-15. Je iss53 branch kan onafhankelijk vooruit bewegen.
 
-Het is interessant om hier op te merken dat het werk dat je in je snelle reparatie branch gedaan hebt, niet zit in de bestanden van je `iss53` branch. Als je dat binnen moet halen, dan kun je je `master` branch in je `iss53` branch samenvoegen door `git merge master` uit te voeren, of je kunt wachten met die wijzigingen te integreren totdat je beslist om je `iss53` branch later in je `master` binnen te halen.
+Het is nuttig om hier op te merken dat het werk dat je in je snelle reparatie branch gedaan hebt, niet in de bestanden van je `iss53` branch zit. Als je dat binnen moet halen, dan kun je de `master` branch in de `iss53` branch merge door `git merge master` uit te voeren, of je kunt wachten met die wijzigingen te integreren tot het moment dat je het besluit neemt de `iss53` branch in de `master` te trekken.
 
 ### Eenvoudig samenvoegen ###
 
-Stel dat je besloten hebt dat je probleem #53 werk compleet is en klaar bent om samen te gaan voegen in je `master` branch. Om dat te doen, zul je je `iss53` branch samenvoegen zoals je je snelle reparatie branch eerder hebt samengevoegd. Het enige dat je hoeft te doen is de branch uit te checken waar je in wenst samen te voegen en dan het `git merge` commando uit te voeren:
+Stel dat je besloten hebt dat je probleem #53 werk gereed is en klaar bent om het te mergen in de `master` branch. Om dat te doen, zul je je `iss53` branch mergen zoals je die snelle reparatie branch eerder hebt gemerged. Het enige dat je hoeft te doen is de branch uit te checken waar je in wenst te mergen en dan het `git merge` commando uit te voeren:
 
 	$ git checkout master
 	$ git merge iss53
@@ -203,32 +203,32 @@ Stel dat je besloten hebt dat je probleem #53 werk compleet is en klaar bent om
 	 README |    1 +
 	 1 files changed, 1 insertions(+), 0 deletions(-)
 
-Dit ziet er iets anders uit dan de snelle reparatie samenvoeging die je eerder deed. In dit geval is je ontwikkelingshistorie afgeweken van een ouder punt. Omdat de commit op de branch waar je op zit geen directe voorouder is van de branch waar je in samenvoegt, moet Git wat werk doen. In dit geval, doet Git een eenvoudige drieweg samenvoeging, gebruikmakend van de twee snapshots waarnaar gewezen wordt door de branch punten en de gezamenlijke voorouder van die twee. Figuur 3-16 markeert de drie snapshots die Git gebruikt om zijn samenvoeging in dit geval te doen.
+Dit ziet er iets anders uit dan de snelle reparatie merge die je eerder deed. In dit geval is je ontwikkelingshistorie afgeweken van een eerder punt. Omdat de commit op de branch waar je op zit geen directe voorouder is van de branch waar je in merged, moet Git wat werk doen. In dit geval, doet Git een eenvoudige drieweg merge, gebruikmakend van de twee snapshots waarnaar gewezen wordt door de branch punten en de gezamenlijke voorouder van die twee. Figuur 3-16 markeert de drie snapshots die Git gebruikt om de merge te doen in dit geval te doen.
 
 Insert 18333fig0316.png
-Figuur 3-16. Git identificeert automatisch de beste gezamenlijke voorouder als samenvoegingsbasis voor het samenvoegen van de branches.
+Figuur 3-16. Git identificeert automatisch de beste gezamenlijke voorouder als basis voor het mergen van de branches.
 
-In plaats van de branch verwijzing vooruit te bewegen, maakt Git een nieuw snapshot dat resulteert uit deze drieweg samenvoeging en maakt automatisch een nieuwe commit die daar naar wijst (zie Figuur 3-17). Dit wordt een samenvoegingscommit genoemd, en is bijzonder in dat het meer dan één ouder heeft.
+In plaats van de branch verwijzing vooruit te verplaatsen, maakt Git een nieuw snapshot dat resulteert uit deze drieweg merge en maakt automatisch een nieuwe commit die daar naar wijst (zie Figuur 3-17). Dit wordt een mergecommit genoemd, en is bijzonder in die zin dat het meer dan één ouder heeft.
 
-Het is de moeite om te vertellen dat Git de beste gezamenlijke voorouder bepaalt om te gebruiken als samenvoeg basis; dit is anders dan CVS of Subversion (voor versie 1.5), waarbij de ontwikkelaar die de samenvoeging deed zelf de beste samenvoeg basis moest uitzoeken. Dit zorgt er voor dat samenvoegen in Git een serieus stuk eenvoudiger is dan in deze andere systemen.
+Het is belangrijk om erop te wijzen dat Git de beste gezamenlijke voorouder bepaalt om te gebruiken als merge basis; dit is anders dan CVS of Subversion (voor versie 1.5), waar het de ontwikkelaar die de merge doet degene is die de beste merge basis moest uitzoeken. Dit maakt het mergen in Git een behoorlijk stuk eenvoudiger dan in deze andere systemen.
 
 Insert 18333fig0317.png
 Figuur 3-17. Git maakt automatisch een nieuw commit object aan die het samengevoegde werk bevat.
 
-Nu dat je werk samengevoegd is, heb je geen verdere noodzaak voor de `iss53` branch. Je kunt het verwijderen en dan handmatig het ticket in je ticket-volg systeem sluiten:
+Nu dat je werk gemerged is, is er geen verdere noodzaak meer voor de `iss53` branch. Je kunt het verwijderen en daarna handmatig de ticket in het ticket-volg systeem sluiten:
 
 	$ git branch -d iss53
 
-### Eenvoudige samenvoeg conflicten ###
+### Eenvoudige merge conflicten ###
 
-Soms, gaat dit proces niet soepel. Als je hetzelfde gedeelte van hetzelfde bestand anders hebt gewijzigd in twee branches die je samenvoegt, dan zal Git niet in staat zijn om ze netjes samen te voegen. Als je reparatie voor probleem #53 hetzelfde gedeelte van een bestand heeft aangepast als de snelle reparatie, dan krijg je een samenvoeg conflict dat er ongeveer zo uit ziet:
+Af en toe verloopt dit proces niet soepel. Als je hetzelfde gedeelte van hetzelfde bestand anders hebt gewijzigd in twee branches die je merged, dan zal Git niet in staat zijn om ze netjes te mergen. Als je reparatie voor probleem #53 hetzelfde gedeelte van een bestand heeft gewijzigd als de snelle reparatie, dan krijg je een merge conflict dat er ongeveer zo uit ziet:
 
 	$ git merge iss53
 	Auto-merging index.html
 	CONFLICT (content): Merge conflict in index.html
 	Automatic merge failed; fix conflicts and then commit the result.
 
-Git heeft niet automatisch een nieuwe samenvoeg commit gemaakt. Het heeft het proces gestopt totdat jij het conflict oplost. Als je wilt zien welke bestanden nog niet zijn samengevoegd op ieder punt na een samenvoeg conflict, dan kun je `git status` uitvoeren:
+Git heeft niet automatisch een nieuwe merge commit gemaakt. Het heeft het proces gestopt zodat jij het conflict kan oplossen. Als je wilt zien welke bestanden nog niet zijn gemerged op ieder punt na een merge conflict, dan kun je `git status` uitvoeren:
 
 	[master*]$ git status
 	index.html: needs merge
@@ -240,7 +240,7 @@ Git heeft niet automatisch een nieuwe samenvoeg commit gemaakt. Het heeft het pr
 	#	unmerged:   index.html
 	#
 
-Alles dat samenvoeg conflicten heeft en dat nog niet is opgelost wordt getoond als niet-samengevoegd. Git voegt standaard conflict-oplossings markeringen toe aan de bestanden die conflicten hebben, zodat je ze handmatig kunt openen en die conflicten kunt oplossen. Je bestand bevat een sectie die er ongeveer zo uit ziet:
+Alles wat merge conflicten heeft en wat nog niet is opgelost wordt getoond als unmerged. Git voegt standaard conflict-oplossings markeringen toe aan de bestanden die conflicten hebben, zodat je ze handmatig kunt openen en die conflicten kunt oplossen. Je bestand bevat een gedeelte die er zo ongeveer uit ziet:
 
 	<<<<<<< HEAD:index.html
 	<div id="footer">contact : email.support@github.com</div>
@@ -250,14 +250,14 @@ Alles dat samenvoeg conflicten heeft en dat nog niet is opgelost wordt getoond a
 	</div>
 	>>>>>>> iss53:index.html
 
-Dit betekend dat de versie in HEAD (jouw master branch, omdat dat hetgene was dat je uitgechecked had toen je je samenvoeg commando uitvoerde) is het bovenste gedeelte van dat blok (alles boven de `======`), terwijl de versie in je `iss53` branch eruit ziet zoals alles in het onderste gedeelte. Om het conflict op te lossen, moet je één van de twee gedeeltes kiezen of de inhoud zelf samenvoegen. Bijvoorbeeld, je zou dit conflict op kunnen lossen door het hele blok met dit te vervangen:
+Dit betekent dat de versie in HEAD (jouw master branch, omdat dat degene was dat je uitgechecked had toen je het merge commando uitvoerde) is het bovenste gedeelte van dat blok (alles boven de `======`), terwijl de versie in je `iss53` branch eruit ziet zoals alles in het onderste gedeelte. Om het conflict op te lossen, moet je één van de twee gedeeltes kiezen of de inhoud zelf mergen. Je zou bijvoorbeeld dit conflict op kunnen lossen door het hele blok met dit te vervangen:
 
 	<div id="footer">
 	please contact us at email.support@github.com
 	</div>
 
-Deze oplossing bevat een stukje uit elke sectie, en ik heb de `<<<<<<<`, `=======`, en `>>>>>>>` regels volledig verwijderd. Nadat je elk van deze secties opgelost hebt in elk conflicterend bestand, voer dan `git add` uit op ieder bestand om het als opgelost te markeren. Het bestand stagen markeert het als opgelost in Git.
-Als je een grafische applicatie wil gebruiken om deze problemen op te lossen, kun je `git mergetool` uitvoeren, wat een toepasselijk visuele samenvoeg applicatie opstart en je door de conflicten heen loopt:
+Deze oplossing bevat een stukje uit beide secties, en ik heb de `<<<<<<<`, `=======`, en `>>>>>>>` regels volledig verwijderd. Nadat je elk van deze secties opgelost hebt in elk conflicterend bestand, voer dan `git add` uit voor ieder bestand om het als opgelost te markeren. Het bestand stagen markeert het als opgelost in Git.
+Als je een grafische applicatie wil gebruiken om deze problemen op te lossen, kun je `git mergetool` uitvoeren, wat een toepasselijk grafische merge applicatie opstart dat je door de conflicten heen leidt:
 
 	$ git mergetool
 	merge tool candidates: kdiff3 tkdiff xxdiff meld gvimdiff opendiff emerge vimdiff
@@ -268,9 +268,9 @@ Als je een grafische applicatie wil gebruiken om deze problemen op te lossen, ku
 	  {remote}: modified
 	Hit return to start merge resolution tool (opendiff):
 
-Als je een ander samenvoeg applicatie wil gebruiken dan de standaard (Git koos `opendiff` voor me in dit geval, omdat ik het commando uitvoerde op een Mac), dan kun je alle ondersteunde applicaties zien aan de top na "merge tool candidates". Type de naam van de applicatie die je liever gebruikt. In Hoofdstuk 7 zullen we bespreken hoe je deze standaard waarde voor je omgeving kunt wijzigen.
+Als je een ander merge applicatie wil gebruiken dan de standaard (Git koos `opendiff` voor me in dit geval, omdat ik het commando uitvoerde op een Mac), dan kun je alle ondersteunde applicaties opgenoemd zien na "merge tool candidates". Type de naam van de applicatie die je liever gebruikt. In Hoofdstuk 7 zullen we bespreken hoe je deze standaard waarde voor jouw omgeving kunt wijzigen.
 
-Nadat je de samenvoeg applicatie afsluit, vraagt Git je of de samenvoeging succesvol was. Als je het script vertelt dat dat zo is, dan staged het het bestand om het voor je als opgelost te markeren.
+Nadat je de merge applicatie afsluit, vraagt Git je of de merge succesvol was. Als je het script vertelt dat dit het geval is, dan staged dit script het bestand voor je om het als opgelost te markeren.
 
 Je kunt `git status` nogmaals uitvoeren om er zeker van te zijn dat alle conflicten opgelost zijn:
 
@@ -282,7 +282,7 @@ Je kunt `git status` nogmaals uitvoeren om er zeker van te zijn dat alle conflic
 	#	modified:   index.html
 	#
 
-Als je daar blij mee bent, en je controleert dat alles waar conflicten in zaten gestaged zijn, dan kun je `git commit` typen om de samenvoeg commit af te ronden. Het commit bericht ziet er standaard ongeveer zo uit:
+Als je het daar mee eens bent, en je gecontroleerd hebt dat alles waar conflicten in zat gestaged is, dan kun je `git commit` typen om de merge commit af te ronden. Het commit bericht ziet er standaard ongeveer zo uit:
 
 	Merge branch 'iss53'
 
@@ -295,36 +295,36 @@ Als je daar blij mee bent, en je controleert dat alles waar conflicten in zaten
 	# and try again.
 	#
 
-Je kunt dat bericht aanpassen met details over hoe je het conflict opgelost hebt, als je denkt dat dat behulpzaam zou zijn voor anderen die in de toekomst naar deze samenvoeging kijken — waarom je deed wat je deed, als dat niet vanzelfsprekend is.
+Je kunt dat bericht aanpassen met details over hoe je het conflict opgelost hebt, als je denkt dat dat behulpzaam zal zijn voor anderen die in de toekomst naar deze samenvoeging kijken; waarom je heb je gedaan wat je gedaan hebt, als dat niet vanzelfsprekend is.
 
 ## Branch beheer ##
 
-Nu heb je wat branches aangemaakt, samengevoegd, en verwijderd. Laten we eens kijken naar wat branch beheer applicaties die handig zijn als je begint met het doorlopend gebruik van branches.
+Nu heb je wat branches aangemaakt, gemerged, en verwijderd. Laten we eens kijken naar wat branch beheer toepassingen die handig zijn als je vaker branches gaat gebruiken.
 
-Het `git branch` commando doet meer dan alleen branches aanmaken en verwijderen. Als je het zonder argumenten uitvoert, dan krijg je een eenvoudige uitvoer van je huidige branches:
+Het `git branch` commando doet meer dan alleen branches aanmaken en verwijderen. Als je het zonder argumenten uitvoert, dan krijg je een eenvoudige lijst van de huidige branches:
 
 	$ git branch
 	  iss53
 	* master
 	  testing
 
-Neem notie van het `*` karakter dat vooraf gaat aan de `master` branch: het geeft de branch aan die je op dit moment uitgechecked hebt. Dit betekent dat als je op dit punt commit, de `master` branch vooruit zal gaan met je nieuwe werk. Om de laatste commit op iedere branch te zien, kun je `git branch -v` uitvoeren:
+Merk op dat het `*` karakter vooraf gaat aan de `master` branch: het geeft de branch aan dat je op dit moment uitgechecked hebt. Dit betekent dat als je op dit punt commit, de `master` branch vooruit zal gaan met je nieuwe werk. Om de laatste commit op iedere branch te zien, kun je `git branch -v` uitvoeren:
 
 	$ git branch -v
 	  iss53   93b412c fix javascript issue
 	* master  7a98805 Merge branch 'iss53'
 	  testing 782fd34 add scott to the author list in the readmes
 
-Een andere handige optie om uit te vogelen in welke staat je branches zijn, is om deze lijst te filteren op branches die je wel of nog niet samengevoegd hebt in de branch waar je nu op zit. De handige `--merged` en `--no-merged` opties zijn voor dit doel beschikbaar in Git sinds versie 1.5.6. Om te zien welke branches al samengevoegd zijn in de branch waar je nu op zit, kun je `git branch --merged` uitvoeren:
+Een andere handige optie om uit te vogelen in welke staat je branches zijn, is om deze lijst te filteren op branches die je wel of nog niet gemerged hebt in de branch waar je nu op zit. De handige `--merged` en `--no-merged` opties zijn voor dit doel beschikbaar in Git. Om te zien welke branches al gemerged zijn in de branch waar je nu op zit, kun je `git branch --merged` uitvoeren:
 
 
 	$ git branch --merged
 	  iss53
 	* master
 
-Omdat je `iss53` al eerder hebt samengevoegd, zie je het terug in je lijst. Branches op deze lijst zonder de `*` ervoor zijn over het algemeen geschikt om te verwijderen met `git branch -d`: je hebt hun werk al in een andere branch zitten, dus je zult niets kwijtraken.
+Omdat je `iss53` al eerder hebt gemerged, zie je het terug in je lijst. Branches op deze lijst zonder de `*` ervoor zijn over het algemeen zonder problemen te verwijderen met `git branch -d`: je hebt hun werk al in een andere branch zitten, dus je zult niets kwijtraken.
 
-Om alle branches te zien die werk bevatten dat je nog niet samengevoegd hebt, kun je `git branch --no-merged` uitvoeren:
+Om alle branches te zien die werk bevatten dat je nog niet gemerged hebt, kun je `git branch --no-merged` uitvoeren:
 
 	$ git branch --no-merged
 	  testing
@@ -335,85 +335,85 @@ Dit toont je andere branch. Omdat het werk bevat dat nog niet samengevoegd is, z
 	error: The branch 'testing' is not an ancestor of your current HEAD.
 	If you are sure you want to delete it, run 'git branch -D testing'.
 
-Als je de branch echt wilt verwijderen en dat werk wilt verliezen, dan kun je het forceren met `-D`, zoals het behulpzame bericht verteld.
+Als je de branch echt wilt verwijderen en dat werk wilt verliezen, dan kun je het forceren met `-D`, zoals het behulpzame bericht je al meldt.
 
 ## Branch werkwijzen ##
 
-Nu dat je de basis van het branchen en samenvoegen onder de knie hebt, wat kan of zou je met ze kunnen doen? In dit gedeelte gaan we over een aantal veel voorkomende werkwijzen die deze lichtgewicht branches mogelijk maken, zodat je kunt beslissen of dat je ze wilt integreren in je ontwikkel cyclus.
+Nu dat je de basis van het branchen en samenvoegen onder de knie hebt, wat kan of zou je met ze kunnen doen? In deze paragraaf gaan we een aantal veel voorkomende werkwijzen die deze lichtgewicht branches mogelijk maken behandelen, zodat je kunt besluiten of je ze wilt toepassen in jouw ontwikkel cyclus.
 
 ### Lang-lopende branches ###
 
-Omdat Git gebruik maakt van een eenvoudige drieweg samenvoeging, is het meerdere keren samenvoegen vanuit een branch met een andere over een langere periode over het algemeen eenvoudig om te doen. Dit betekent dat je meerdere branches kunt hebben, die altijd open staan en die je voor verschillende delen van je ontwikkel cyclus gebruikt; je kunt regelmatig samenvoegen van een aantal ervan in de anderen.
+Omdat Git gebruik maakt van een eenvoudige drieweg merge, is het meerdere keren mergen vanuit een branch in een andere gedurende een langere periode over het algemeen eenvoudig te doen. Dit betekent dat je meerdere branches kunt hebben, die altijd open staan en die je voor verschillende delen van je ontwikkel cyclus gebruikt; je kunt regelmatig een aantal mergen in andere.
 
-Veel Git ontwikkelaars hebben een werkwijze die deze aanpak omarmd, zoals het hebben van alleen volledig stabiele code in hun `master` branch — waarschijnlijk alleen code die is of zal worden vrijgegeven. Ze hebben een andere parallelle branch genaamd develop of next waarop ze werken of die ze gebruiken om stabiliteit te testen — het is niet noodzakelijk altijd stabiel, maar zodra het naar een stabiele status gaat, kan het worden samengevoegd in `master`. Het wordt gebruikt om onderwerp branches (branches met een korte levensduur, zoals jou eerdere `iss53` branch) binnen te halen, zodra die klaar zijn, om er zeker van te zijn dat ze voor alle testen slagen en geen fouten introduceren.
+Veel Git ontwikkelaars hebben een werkwijze die deze aanpak omarmt, zoals het hebben van alleen volledig stabiele code in hun `master` branch — waarschijnlijk alleen code die is of zal worden vrijgegeven. Ze hebben een andere parallelle branch "develop" of "next" genaamd waarop ze werken of die ze gebruiken om stabiliteit te testen — het is niet noodzakelijk altijd stabiel, maar zodra het in een stabiele status verkeert, kan het worden gemerged in `master`. Het wordt gebruikt om topic branches (branches met een korte levensduur, zoals jou eerdere `iss53` branch) te pullen zodra die klaar zijn, om er zich ervan te verzekeren dat alle testen slagen en er geen fouten worden geïntroduceerd.
 
-In werkelijkheid praten we over verwijzingen die zich verplaatsen over de lijn van de commits die je maakt. De stabiele branches zijn verder naar achter in je commit historie, en de splinternieuwe branches zijn verder naar voren in de historie (zie Figuur 3-18).
+In essentie praten we over verwijzingen die zich verplaatsen over de lijn van de commits die je maakt. De stabiele branches zijn verder naar achter in je commit historie, en de splinternieuwe branches zijn verder naar voren in de historie (zie Figuur 3-18).
 
 Insert 18333fig0318.png
-Figuur 3-18. Meer stabiele branches zijn vaak verder naar achter in de commit historie.
+Figuur 3-18. Meer stabiele branches zijn over het algemeen verder naar achter in de commit historie.
 
-Ze zijn over het algemeen makkelijker voor te stellen als werk silo's, waar sets van commits slagen naar een meer stabiele silo als ze volledig getest zijn (zie Figuur 3-19).
+Ze zijn misschien makkelijker voor te stellen als werk silo's, waar sets van commits stapsgewijs naar een meer stabiele silo worden gepromoveerd als ze volledig getest zijn (zie Figuur 3-19).
 
 Insert 18333fig0319.png
 Figuur 3-19. Het kan handig zijn om je branches voor te stellen als silo's.
 
-Je kunt dit doen voor meerdere niveaus van stabiliteit. Sommige grotere projecten hebben ook een `proposed` of `pu` (proposed updates) branch die branches geïntegreerd heeft die wellicht nog niet klaar zijn om in de `next` of `master` branch te gaan. Het idee is dat je branches op verschillende niveaus van stabiliteit zitten; zodra ze een stabiel niveau bereiken, worden ze in de branch boven hun samengevoegd.
-Nogmaals, het hebben van langlopende branches is niet noodzakelijk, maar het helpt vaak wel, in het bijzonder als je moet omgaan met zeer grote of complexe projecten.
+Je kunt dit blijven doen voor elk niveaus van toegenomen stabiliteit. Sommige grotere projecten hebben ook een `proposed` of `pu` (proposed updates) branch die branches geïntegreerd heeft die wellicht nog niet klaar zijn om in de `next` of `master` branch te gaan. Het idee erachter is dat de branches op verschillende niveaus van stabiliteit zitten. Zodra ze een meer stabiel niveau bereiken, worden ze in de branch boven hun gemerged.
+Nogmaals, het hebben van langlopende branches is niet noodzakelijk maar het helpt vaak wel, in het bijzonder als je te maken hebt met zeer grote of complexe projecten.
 
-### Onderwerp branches ###
+### Topic branches ###
 
-Maar, onderwerp branches zijn bruikbaar in projecten van iedere grootte. Een onderwerp branch is een kortlopende branch die je maakt en gebruikt om een enkele eigenschap of gerelateerd werk in te doen. Dit is iets wat je waarschijnlijk nooit van tevoren met een VCS gedaan hebt, omdat het over het algemeen te duur is om branches aan te maken en samen te voegen. Maar in Git komt het vaak voor om branches aan te maken, op te werken, en te verwijderen meerdere keren per dag.
+Topic branches zijn nuttig in projecten van elke grootte. Een topic branch is een kortlopende branch die je maakt en gebruikt om een specifieke functie te realiseren of daaraan gerelateerd werk te doen. Dit is iets wat je waarschijnlijk nooit eerder met een VCS gedaan hebt, omdat het over het algemeen te duur is om branches aan te maken en te mergen. Maar in Git is het niet ongebruikelijk om meerdere keren per dag branches aan te maken, daarop te werken, en ze te verwijderen.
 
-Je zag dit in het laatste gedeelte met de `iss53` en `hotfix` branches die je gemaakt had. Je hebt een aantal commits op ze gedaan en ze meteen verwijderd zodra je ze samengevoegd had in je hoofd branch. Deze techniek staat je toe om snel en volledig van context te veranderen — omdat je werk is gescheiden in silo's waar alle wijzigingen in die branch met dat onderwerp te maken hebben, is het makkelijker te zien wat er is gebeurd tijdens een code review en dergelijke. Je kunt de wijzigingen daar minuten, dagen of maanden bewaren, en ze samenvoegen als je er klaar voor bent, ongeacht in de volgorde waarin ze gemaakt of aan gewerkt zijn.
+Je zag dit in de vorige paragraaf met de `iss53` en `hotfix` branches die je gemaakt had. Je hebt een aantal commits op ze gedaan en ze meteen verwijderd zodra je ze gemerged had in je hoofd branch. Deze techniek staat je toe om snel en volledig van context te veranderen — omdat je werk is onderverdeeld in silo's waar alle wijzigingen te maken hebben met het onderwerp van die branch, is het makkelijker te zien wat er is gebeurd tijdens een code review en dergelijke. Je kunt de wijzigingen daar minuten, dagen of maanden bewaren, en ze mergen als ze er klaar voor zijn, ongeacht de volgorde waarin ze gemaakt of aan gewerkt zijn.
 
-Neem als voorbeeld een situatie waarbij wat werk gedaan wordt (op `master`), gebranched wordt voor een probleem (`iss91`), waar een beetje aan gewerkt wordt, gebranched wordt vanaf de tweede branch om op een andere manier te proberen hetzelfde op te lossen (`iss91v2`) terug te gaan naar je master branch en daar een tijdje te werken, en dan vanaf daar branchen om wat werk te doen waarvan je niet zeker weet of het wel een goed idee is (`dumbidea` branch). Je commit historie zal er uit zien als Figuur 3-20.
+Neem als voorbeeld een situatie waarbij wat werk gedaan wordt (op `master`), er wordt een branche gemaakt voor een probleem (`iss91`) daar wordt wat aan gewerkt, er wordt een tweede branch gemaakt om op een andere manier te proberen hetzelfde op te lossen (`iss91v2`); even teruggaan naar de master branch om daar een tijdje te werken, en dan vanaf daar branchen om wat werk te doen waarvan je niet zeker weet of het wel een goed idee is (`dumbidea` branch). Je commit historie zal er uit zien als Figuur 3-20.
 
 Insert 18333fig0320.png
-Figuur 3-20. Je commit geschiedenis met meerdere onderwerp branches.
+Figuur 3-20. Je commit geschiedenis met meerdere topic branches.
 
-Nu, laten we zeggen dat je beslist dat je de tweede oplossing voor je probleem het beste vindt (`iss91v2`); en je hebt de `dumbidea` branch aan je collega's laten zien, en het blijkt geniaal te zijn. Je kunt dan de originele `iss91` weggooien (waarbij je commits C5 en C6 verliest), en de andere twee samenvoegen. Je historie ziet er dan uit als Figuur 3-21).
+Laten we zeggen dat je besluit dat je de tweede oplossing voor je probleem het beste vindt (`iss91v2`), en je hebt de `dumbidea` branch aan je collega's laten zien en het blijkt geniaal te zijn. Je kunt dan de oorspronkelijke `iss91` weggooien (waardoor je commits C5 en C6 kwijt raakt), en de andere twee mergen. Je historie ziet er dan uit als Figuur 3-21).
 
 Insert 18333fig0321.png
 Figuur 3-21. Je historie na het samenvoegen van dumbidea en iss91v2.
 
-Het is belangrijk om te onthouden dat wanneer je dit alles doet, deze branches volledig lokaal zijn. Als je aan het branchen of samenvoegen bent, dan wordt alles gedaan in jouw Git repository — dus er gebeurt geen server communicatie.
+Het is belangrijk om te beseffen dat tijdens al deze handelingen, al deze branches volledig lokaal zijn. Als je aan het branchen of mergen bent, dan wordt alles alleen in jouw Git repository gedaan, dus er vindt geen server communicatie plaats.
 
 ## Remote branches ##
 
-Remote branches zijn referenties naar de staat van de branches op je remote repositories. Ze zijn lokale branches die jij niet kunt verplaatsen; ze worden automatisch verplaatst zodra je wat netwerk communicatie doet. Remote branches gedragen zich als boekenleggers om je eraan te helpen herinneren waar de branches op je remote repositories waren de laatste keer dat je met ze in contact was.
+Remote branches zijn referenties naar de staat van de branches op remote repositories. Ze zijn lokale branches die jij niet kunt verplaatsen; ze worden automatisch verplaatst zodra je er netwerk communicatie plaatsvindt. Remote branches gedragen zich als boekenleggers om je eraan te helpen herinneren wat de staat van de branches was op je remote repositories toen je voor het laatst met ze in contact was.
 
-Ze hebben de vorm `(remote)/(branch)`. Bijvoorbeeld, als je wil zien hoe de `master` branch op je `origin` er uit zag vanaf de laatste dat je er mee gecommuniceerd hebt, dan zou je de `origin/master` branch bekijken. Als je aan het werk bent aan een probleem met een partner en zij hebben een `iss53` branch teruggezet, dan zou je je eigen lokale `iss53` kunnen hebben; maar de branch op de server zou wijzen naar de commit op `origin/iss53`.
+Ze hebben de vorm `(remote)/(branch)`. Bijvoorbeeld, als je wil zien hoe de `master` branch op je `origin` de laatste keer dat je er mee communiceerde er uit zag, dan zal je de `origin/master` branch moeten bekijken. Als je aan het werk bent met een probleem samen met een partner en zij heeft een `iss53` branch gepushed, kan je je eigen lokale `iss53` hebben, maar de branch op de server zou wijzen naar de commit op `origin/iss53`.
 
-Dit kan wat verwarrend zijn, dus laten we eens naar een voorbeeld kijken. Stel dat je een Git server op je netwerk hebt op `git.ourcompany.com`. Als je hiervan kloont dan wordt die automatisch `origin` voor je genoemd, Git haalt al zijn gegevens binnen, maakt een verwijzing naar waar zijn `master` branch is, en noemt dat lokaal `origin/master`; en je kunt het niet verplaatsen. Git geeft je ook je eigen `master` branch, beginnend op dezelfde plaats als de `master` branch van origin, zodat je iets hebt om vanaf te werken (zie Figuur 3-22).
+Dit is wat verwarrend, dus laten we eens naar een voorbeeld kijken. Stel dat je een Git server op je netwerk hebt op `git.ourcompany.com`. Als je hiervan kloont dan wordt die automatisch `origin` voor je genoemd, Git haalt alle gegevens binnen, maakt een verwijzing naar waar de `master` branch is en noemt dat lokaal `origin/master`, en deze kan je niet verplaatsen. Git geeft je ook een eigen `master` branch, beginnend op dezelfde plaats als de `master` branch van origin, zodat je iets hebt om vanaf te werken (zie Figuur 3-22).
 
 Insert 18333fig0322.png
-Figuur 3-22. Een Git clone geeft je je eigen master branch en origin/master wijzend naar de master branch van origin.
+Figuur 3-22. Een Git clone geeft je een eigen master branch en origin/master wijzend naar de master branch van origin.
 
-Als je wat werk doet op je lokale master branch, en in de tussentijd zet iemand anders iets terug naar `git.ourcompany.com` en vernieuwt die master branch, dan zijn jullie histories verschillend vooruit geschoven. En, zolang je geen contact hebt met je origin server, zal je `origin/master` verwijzing niet verplaatsen (zie Figuur 3-23).
+Als je wat werk doet op je lokale master branch, en in de tussentijd pushed iemand anders iets naar `git.ourcompany.com` en daarmee die master branch vernieuwd, dan zijn jullie histories verschillend vooruit geschoven. En, zolang je geen contact hebt met de origin server, zal jouw `origin/master` verwijzing niet verplaatsen (zie Figuur 3-23).
 
 Insert 18333fig0323.png
-Figuur 3-23. Lokaal werken terwijl iemand anders naar je remote server terugzet laat iedere historie anders vooruit gaan.
+Figuur 3-23. Lokaal werken terwijl iemand anders naar je remote server pushed laat elke historie anders vooruit gaan.
 
-Om je werk te synchroniseren, voer je een `git fetch origin` commando uit. Dit commando bekijkt welke server origin is (in dit geval is het `git.ourcompany.com`), haalt gegevens er vanaf die je nog niet hebt, en vernieuwt je lokale gegevensbank, waarbij je `origin/master` verwijzing naar zijn nieuwere positie verplaatst wordt (zie Figuur 3-24).
+Om je werk te synchroniseren, voer je een `git fetch origin` commando uit. Dit commando bekijkt welke op server origin is (in dit geval is het `git.ourcompany.com`), haalt gegevens er vanaf die je nog niet hebt en vernieuwt je lokale database, waarbij je `origin/master` verwijzing naar zijn nieuwe positie verplaatst wordt (zie Figuur 3-24).
 
 Insert 18333fig0324.png
 Figuur 3-24. Het git fetch commando vernieuwt je remote referenties.
 
-Om het hebben van meerdere remote servers te demonstreren en hoe remote branches voor die remote projecten er uit zien, laten we eens aannemen dat je nog een interne Git server hebt, die alleen wordt gebruikt voor ontwikkeling gedaan door een van je sprint teams. Deze server bevindt zich op `git.team1.ourcompany.com`. Je kunt het als een nieuwe remote referentie toevoegen aan het project waar je nu aan werkt door het `git remote add` commando uit te voeren, zoals we behandeld hebben in Hoofdstuk 2. Noem deze remote `teamone`, wat je afkorting voor die hele URL wordt (zie Figuur 3-25).
+Om het hebben van meerdere remote servers te tonen en hoe remote branches voor die remote projecten er uit zien, zullen we aannemen dat je nog een interne Git server hebt die alleen wordt gebruikt voor ontwikkeling gedaan door een van je sprint teams. Deze server bevindt zich op `git.team1.ourcompany.com`. Je kunt het als een nieuwe remote referentie toevoegen aan het project waar je nu aan werkt door het `git remote add` commando uit te voeren, zoals we behandeld hebben in Hoofdstuk 2. Noem deze remote `teamone`, wat jouw afkorting voor die hele URL wordt (zie Figuur 3-25).
 
 Insert 18333fig0325.png
 Figuur 3-25. Een andere server als een remote toevoegen.
 
-Nu kun je `git fetch teamone` uitvoeren om alles op te halen dat de `teamone` server heeft en jij nog niet. Omdat server een subset is van de gegevens die je `origin` server op dit moment heeft, haalt Git geen gegevens maar stelt een remote branch genaamd `teamone/master` in om te wijzen naar de commit die `teamone` heeft naar zijn `master` branch (zie Figuur 3-26).
+Nu kun je `git fetch teamone` uitvoeren om alles op te halen dat wat de `teamone` remote server heeft en jij nog niet. Omdat die server een subset heeft van de gegevens die jouw `origin` server op dit moment heeft, haalt Git geen gegevens maar maakt een remote branch genaamd `teamone/master` aan en laat die wijzen naar de commit die `teamone` heeft als zijn `master` branch (zie Figuur 3-26).
 
 Insert 18333fig0326.png
-Figuur 3-26. Je krijgt lokaal een referentie naar de positie van teamone's master branch.
+Figuur 3-26. Je krijgt lokaal een referentie naar de master branch positie van teamone.
 
-### Terugzetten ###
+### Pushen ###
 
-Als je een branch wil delen met de wereld, dan moet je het naar een remote terugzetten waar je schrijftoegang op hebt. Je lokale branches worden niet automatisch gesynchroniseerd met de remotes waar je naar schrijft — je moet de branches die je wilt delen expliciet terugzetten. Op die manier, kun je privé branches gebruiken voor werk dat je niet wil delen, en alleen de onderwerp branches terugzetten waar je op wilt samenwerken.
+Als je een branch wil delen met de rest van de wereld, dan moet je het naar een remote terugzetten waar je schrijftoegang op hebt. Je lokale branches worden niet automatisch gesynchroniseerd met de remotes waar je naar schrijft, je moet de branches die je wilt delen uitdrukkelijk pushen. Op die manier kun je privé branches gebruiken voor het werk dat je niet wil delen, en alleen die topic branches pushen waar je op wilt samenwerken.
 
-Als je een branch genaamd `serverfix` hebt, waar je met anderen aan wilt werken, dan kun je die terugzetten op dezelfde manier waarop je je eerste branch hebt teruggezet. Voer `git push (remote) (branch)` uit:
+Als je een branch genaamd `serverfix` hebt waar je met anderen aan wilt werken, dan kun je die op dezelfde manier pushen als waarop je dat voor de eerste branch hebt gedaan. Voer `git push (remote) (branch)` uit:
 
 	$ git push origin serverfix
 	Counting objects: 20, done.
@@ -423,9 +423,9 @@ Als je een branch genaamd `serverfix` hebt, waar je met anderen aan wilt werken,
 	To git@github.com:schacon/simplegit.git
 	 * [new branch]      serverfix -> serverfix
 
-Dit is een beetje kort door de bocht. Git zal de `serverfix` branchnaam automatisch expanderen naar `refs/heads/serverfix:refs/heads/serverfix`, wat betekent "Neem mijn lokale serverfix branch en zet dat terug om de serverfix branch van de remote te vernieuwen.". We zullen in detail over het `refs/heads` gedeelte gaan hebben in Hoofdstuk 9, maar je kunt het over het algemeen weglaten. Je kun ook `git push origin serverfix:serverfix` doen, wat hetzelfde doet — het zegt, "Neem mijn serverfix en maak het de serverfix van de remote." Je kunt dit formaat gebruiken om een lokale branch terug te zetten naar een remote branch die anders heet. Als je niet wil dat het `serverfix` heet aan de remote kant, kun je in plaats daarvan `git push origin serverfix:awesomebranch` gebruiken om je lokale `serverfix` branch naar de `awesomebranch` op het remote project terug te zetten.
+Dit is een verkorte manier. Git zal de `serverfix` branchnaam automatisch expanderen naar `refs/heads/serverfix:refs/heads/serverfix`, wat staat voor "Neem mijn lokale serverfix branch en push die om de serverfix branch van de remote te vernieuwen.". We zullen het `refs/heads` gedeelte gedetaileerd behandelen in Hoofdstuk 9, maar je kunt het normaalgesproken weglaten. Je kun ook `git push origin serverfix:serverfix` doen, wat hetzelfde doet. Dit staat voor "Neem mijn serverfix en maak het de serverfix van de remote." Je kunt dit formaat gebruiken om een lokale branch te pushen naar een remote branch die anders heet. Als je niet wil dat het `serverfix` heet aan de remote kant, kan je in plaats daarvan `git push origin serverfix:awesomebranch` gebruiken om je lokale `serverfix` branch naar de `awesomebranch` op het remote project te pushen.
 
-De volgende keer dat één van je medewerkers van de server fetched, zullen ze een referentie krijgen naar waar de servers versie van `serverfix` is onder de remote branch `origin/serverfix`:
+De volgende keer dat één van je medewerkers van de server fetched zal deze een referentie krijgen naar de versie van `serverfix` op de server, onder de remote branch `origin/serverfix`:
 
 	$ git fetch origin
 	remote: Counting objects: 20, done.
@@ -435,61 +435,61 @@ De volgende keer dat één van je medewerkers van de server fetched, zullen ze e
 	From git@github.com:schacon/simplegit
 	 * [new branch]      serverfix    -> origin/serverfix
 
-Het is belangrijk om op te merken dat als je een fetch doet die nieuwe remote branches ophaalt, je niet automatisch lokale, aanpasbare kopieën daarvan hebt. In andere woorden, in dit geval heb je geen nieuwe `serverfix` branch — je hebt alleen een `origin/serverfix` verwijzing die je niet kunt aanpassen.
+Het is belangrijk om op te merken dat als je een fetch doet die nieuwe remote branches ophaalt, je niet automatisch lokale aanpasbare kopieën daarvan hebt. In andere woorden, in dit geval heb je geen nieuwe `serverfix` branch, je hebt alleen een `origin/serverfix` verwijzing die je niet kunt aanpassen.
 
-Om dit werk in je huidige werk branch samen te voegen, kun je `git merge origin/serverfix` uitvoeren. Als je je eigen `serverfix` branch wilt waar je op kunt werken, dan kun je deze vanaf je remote branch baseren:
+Om dit werk in je huidige werk branch te mergen, kun je `git merge origin/serverfix` uitvoeren. Als je een eigen `serverfix` branch wilt waar je op kunt werken, dan kun je deze op je remote branch baseren:
 
 	$ git checkout -b serverfix origin/serverfix
 	Branch serverfix set up to track remote branch refs/remotes/origin/serverfix.
 	Switched to a new branch "serverfix"
 
-Dit geeft je een lokale branch waar je op kunt werken, die begint met waar `origin/serverfix` is.
+Dit maakt een lokale branch aan waar je op kunt werken, die begint met waar `origin/serverfix` is.
 
-### Volg branches ###
+### Tracking branches ###
 
-Een lokale branch uitchecken van een remote branch creëert automatisch een zogenaamde _volg branch_ (_tracking branch_). Volg branches zijn lokale branches die een directe releatie met een remote branch hebben. Als je op een volg branch zit en git push typt, dat weet Git automatisch naar welke server en branch hij moet terugzetten. En, terwijl je op een van die branches zit zal het uitvoeren van `git pull` alle remote referenties ophalen en ze automatisch in de corresponderende remote branch samenvoegen.
+Een lokale branch uitchecken van een remote branch creëert automatisch een zogenaamde _volg branch_ (_tracking branch_). Tracking branches zijn lokale branches die een directe releatie met een remote branch hebben. Als je op een tracking branch zit en `git push` typt, dat weet Git automatisch naar welke server en branch hij moet pushen. En, als je op een van die branches zit zal het uitvoeren van `git pull` alle remote referenties ophalen en automatisch naar de corresponderende remote branch mergen.
 
-Als je een repository kloont, zal het over het algemeen automatisch een `master` branch aanmaken, die `origin/master` volgt. Daarom werken `git push` en `git pull` zo uit het doosje, zonder verdere argumenten. Maar, kun je kunt ook andere volg branches instellen als je dat wilt — anderen die niet branches volgen op `origin` en niet de `master` branch volgen. Het eenvoudige geval is het voorbeeld dat je zojuist zag, `git checkout -b [branch] [remotenaam]/[branch]` uitvoeren. Als je Git versie 1.6.2 of nieuwer hebt, kun je ook de `--track` afkorting gebruiken:
+Als je een repository kloont, zal het over het algemeen automatisch een `master` branch aanmaken, die `origin/master` tracked. Daarom werken `git push` en `git pull` zo uit het doosje, zonder verdere argumenten. Maar je kan ook andere tracking branches instellen als je dat wilt, andere die niet branches volgen op `origin` en niet de `master` branch tracken. Een eenvoudig voorbeeld is wat je zojuist gezien hebt: `git checkout -b [branch] [remotenaam]/[branch]` uitvoeren. Als je Git versie 1.6.2 of nieuwer hebt, kun je ook de `--track` afkorting gebruiken:
 
 	$ git checkout --track origin/serverfix
 	Branch serverfix set up to track remote branch refs/remotes/origin/serverfix.
 	Switched to a new branch "serverfix"
 
-Om een lokale branch in te stellen met een andere naam dan de remote branch, kun je eenvoudig de eerste versie met een andere lokale branch naam gebruiken:
+Om een lokale branch te maken met een andere naam dan de remote branch, kun je simpelweg de eerste variant met een andere lokale branch naam gebruiken:
 
 	$ git checkout -b sf origin/serverfix
 	Branch sf set up to track remote branch refs/remotes/origin/serverfix.
 	Switched to a new branch "sf"
 
-Nu zal je lokale sf branch automatisch halen en terugzetten van origin/serverfix.
+Nu zal je lokale `sf` branch automatisch pullen en pushen van origin/serverfix.
 
 ### Remote branches verwijderen ###
 
-Stel dat je klaar bent met een remote branch — stel dat jij en je medewerkers klaar zijn met een eigenschap en het hebben samengevoegd in je `master` branch van je remote (of welke branch je stabiele codelijn ook in zit). Dan kun je een remote branch verwijderen door de nogal stompzinnige syntax `git push [remotenaam] :[branch]` te gebruiken. Als je je `serverfix` branch van de server wilt verwijderen, dan voer je het volgende uit:
+Stel dat je klaar bent met een remote branch, stel dat jij en je medewerkers klaar zijn met een feature en het hebben gemerged in de `master` branch van de remote (of welke branch je stabiele code ook in zit). Dan kun je een remote branch verwijderen door de nogal botte syntax `git push [remotenaam] :[branch]` te gebruiken. Als je de `serverfix` branch van de server wilt verwijderen, dan voer je het volgende uit:
 
 	$ git push origin :serverfix
 	To git@github.com:schacon/simplegit.git
 	 - [deleted]         serverfix
 
-Boem. Geen branch meer op je server. Je zult deze pagina wel een ezelsoor willen geven, omdat je dat commando nodig hebt, en je het waarschijnlijk zult vergeten. Een manier om dit commando te onthouden is door de `git push [remotenaam] [lokalebranch]:[remotebranch]` syntax te onthouden die we iets eerder behandeld hebben. Als je het `[lokalebranch]` gedeelte weglaat, dan zeg je in feite, "Neem iets willekeurigs aan mijn kant en maak dat de `[remotebranch]`."
+Boem. Geen branch meer op je server. Je zult deze pagina wel een ezelsoortje willen geven, omdat je dat commando nodig gaat hebben en het waarschijnlijk zult vergeten. Een manier om dit commando te onthouden is door de `git push [remotenaam] [lokalebranch]:[remotebranch]` syntax te onthouden die we kortgeleden behandeld hebben. Als je het `[lokalebranch]` gedeelte weglaat dan zeg je in feite, "Neem niets aan mijn kant en maak dat de `[remotebranch]`."
 
 ## Rebasen ##
 
-In Git zijn er twee hoofdmanieren om wijzigingen te integreren van één branch in een andere: de `samenvoeging` en de `rebase`. In dit gedeelte zul je leren wat rebasen is, hoe je het moet doen, waarom het een zeer bijzondere toepassing is, en in welke gevallen je het niet wilt gebruiken.
+In Git zijn er twee hoofdmanieren om wijzigingen te integreren van de ene branch in een andere: de `merge` en de `rebase`. In deze paragraaf zul je leren wat rebasen is, hoe je dat moet doen, waarom het een zeer bijzondere toepassing is en in welke gevallen je het niet wilt gebruiken.
 
-### De eenvoudige rebase ###
+### De simpele rebase ###
 
-Als je teruggaat naar een eerder voorbeeld van de Samenvoegen sectie (zie Figuur 3-27), dan kun je zien dat je werk is afgeweken en dat je commits hebt gedaan op de twee verschillende branches.
+Als je het eerdere voorbeeld van de Merge-paragraaf erop terugslaat (zie Figuur 3-27), dan zul je zien dat je werk is uiteengelopen en dat je commits hebt gedaan op de twee verschillende branches.
 
 Insert 18333fig0327.png
-Figuur 3-27. Je initiële afgeweken historie.
+Figuur 3-27. Je initiële uiteengelopen historie.
 
-De eenvoudigste weg om de branches te integreren, zoals we al hebben besproken, is het `samenvoeg` commando. Het voert een drieweg samenvoeging uit tussen de twee laatste snapshots van de branches (C3 en C4), en de meest recente gezamenlijke voorouder van die twee (C2), creëert een nieuw snapshot (en commit), zoals getoond in Figuur 3-28.
+De simpelste manier om de branches te integreren, zoals we al hebben besproken, is het `merge` commando. Het voert een drieweg merge uit tussen de twee laatste snapshots van de branches (C3 en C4), en de meest recente gezamenlijke voorouder van die twee (C2), en maakt een nieuw snapshot (en commit) zoals getoond in Figuur 3-28.
 
 Insert 18333fig0328.png
-Figuur 3-28. Een branch samenvoegen om de afgeweken werk historie te integreren.
+Figuur 3-28. Een branch merge om de uiteengelopen werk histories te integreren.
 
-Maar, er is een andere manier: je kunt de patch van de wijziging die werd geïntroduceerd in C3 pakken en die opnieuw toepassen bovenop C4. In Git, wordt dit _rebasen_ genoemd. Met het `rebase` commando, kun je alle wijzigingen pakken die zijn gecommit op een branch, en ze opnieuw afspelen op een andere.
+Maar, er is nog een manier: je kunt de patch van de wijziging die werd geïntroduceerd in C3 pakken en die opnieuw toepassen op C4. In Git, wordt dit _rebasen_ genoemd. Met het `rebase` commando kan je alle wijzigingen pakken die zijn gecommit op de ene branch, en ze opnieuw afspelen op een andere.
 
 In dit voorbeeld, zou je het volgende uitvoeren:
 
@@ -498,37 +498,37 @@ In dit voorbeeld, zou je het volgende uitvoeren:
 	First, rewinding head to replay your work on top of it...
 	Applying: added staged command
 
-Het werkt door naar de gezamenlijke voorouder van de twee branches te gaan (degene waar je op zit en degene waar je naar rebased), de verschillen pakken die geïntroduceerd is bij iedere commit op de branch waar je op zit, die diffs in tijdelijke bestanden bewaren, de huidige branch terugzetten naar dezelfde commit als de branch waar je op rebased, en uiteindelijk iedere wijziging om de beurt toepassen, Figuur 3-29 toont dit proces.
+Het gebeurt door naar de gezamenlijke voorouder van de twee branches te gaan (degene waar je op zit en degene waar je op rebased), de diff te nemen die geïntroduceerd is voor elke losse commit op de branch waar je op zit, die diffs in tijdelijke bestanden te bewaren, de huidige branch terug te zetten naar dezelfde commit als de branch waar je op rebased, en uiteindelijk elke diff om de beurt toe te passen, Figuur 3-29 toont dit proces.
 
 Insert 18333fig0329.png
 Figuur 3-29. De wijzigingen die geïntroduceerd zijn in C3 rebasen op C4.
 
-Op dit punt kun je terug gaan naar de master branch en een fast-forward samenvoeging doen (zie Figuur 3-30).
+Hierna kan je terug gaan naar de master branch en een fast-forward merge doen (zie Figuur 3-30).
 
 Insert 18333fig0330.png
 Figuur 3-30. De master branch Fast-forwarden.
 
-Nu is het snapshot waar C3' naar wijst precies hetzelfde als degene waar C5 naar wees in het samenvoeg voorbeeld. Er zit geen verschil in het eindproduct van de integratie, maar rebasen zorgt voor een schonere historie. Als je de log van een gerebasete branch bekijkt, ziet het eruit als een lineaire historie: het lijkt alsof al het werk in serie is gebeurt, zelfs als het in werkelijkheid in parallel gedaan is.
+Nu is het snapshot waar C3' naar wijst precies dezelfde als degene waar C5 naar wees in het merge voorbeeld. Er zit geen verschil in het eindresultaat van de integratie, maar rebasen zorgt voor een duidelijkere historie. Als je de log van een gerebasdte branch bekijkt, ziet het eruit als een lineaire historie: het lijkt alsof al het werk in serie is gebeurt, zelfs wanneer het in werkelijkheid in parallel gedaan is.
 
-Vaak zul je dit doen om er zeker van te zijn dat je commits netjes aansluiten op een remote branch — misschien in een project waar je op probeert bij te dragen, maar dat je niet onderhoudt. In dit geval zou je je werk in een branch doen en dan je werk rebasen op `origin/master` als je klaar ben om je patches in te sturen naar het hoofd project. Op die manier hoeft de beheerder geen integratie werk te doen — gewoon een fast-forward of een schone toepassing.
+Vaak zal je dit doen om er zeker van te zijn dat je commits netjes toegepast kunnen worden op een remote branch, misschien in een project waar je aan probeert bij te dragen, maar dat je niet beheert. In dit geval zou je het werk in een branch uitvoeren en dan je werk rebasen op `origin/master` als je klaar ben om je patches in te sturen naar het hoofd project. Op die manier hoeft de beheerder geen integratie werk te doen maar gewoon een fast-forward of een gewone apply.
 
-Let op het snapshot waar de laatste commit naar wijst waar je mee eindigt, of het de laatste van de gerebasete commits voor een rebase is, of de laatste samenvoeg commit na een samenvoeging, het is hetzelfde snapshot — alleen de historie is verschillend. Rebasen speelt veranderingen van een werklijn opnieuw af op een andere in de volgorde waarin ze geïntroduceerd waren, en samenvoegen pakt de eindpunten en voegt die samen.
+Merk op dat de snapshot waar de laatste commit op het eind naar wijst, of het de laatste van de gerebasete commits voor een rebase is of de laatste merge commit na een merge, detzelfde snapshot is; alleen de historie is verschillend. Rebasen speelt veranderingen van een werklijn opnieuw af op een andere, in de volgorde waarin ze gemaakt zijn, terwijl mergen de eindresultaten pakt en die samenvoegt.
 
 ### Interessantere rebases ###
 
-Je kunt je rebase ook opnieuw laten afspelen op iets anders dan de rebase branch. Pak een historie zoals in Figuur 3-31, bijvoorbeeld. Je hebt een onderwerp branch afgesplitst (`server`) om wat server-kant functionaliteit toe te voegen aan je project, en toen een commit gedaan. Daarna, heb je daar vanaf gebranched om de client-kant wijzigingen te doen (`client`) en een paar keer gecommit. Als laatste, ben je teruggegaan naar je server branch en hebt nog een paar commits gedaan.
+Je kunt je rebase ook opnieuw laten afspelen op iets anders dan de rebase branch. Pak een historie zoals in Figuur 3-31, bijvoorbeeld. Je hebt een topic branch afgesplitst (`server`) om wat server-kant functionaliteit toe te voegen aan je project en toen een gecommit. Daarna heb je daar vanaf gebranched om de client-kant wijzigingen te doen (`client`) en een paar keer gecommit. Als laatste, ben je teruggegaan naar je server branch en hebt nog een paar commits gedaan.
 
 Insert 18333fig0331.png
-Figuur 3-31. Een historie met een onderwerp branch vanaf een andere onderwerp branch.
+Figuur 3-31. Een historie met een topic branch vanaf een andere topic branch.
 
-Stel dat je beslist dat je je client-kant wijzigingen wilt samenvoegen in je hoofdlijn voor een vrijgave, maar je wilt de server-kant wijzigingen nog laten wachten totdat het verder getest is. Je kunt de wijzigingen van client pakken, die nog niet op server zitten (C8 en C9) en die opnieuw afspelen op je master branch door de `--onto` optie te gebruiken van `git rebase`:
+Stel dat je beslist dat je de client-kant wijzigingen wilt mergen in je hoofdlijn voor een release, maar je wilt de server-kant wijzigingen nog laten wachten totdat het verder getest is. Je kunt de wijzigingen van client pakken, die nog niet op server zitten (C8 en C9) en die opnieuw afspelen op je master branch door de `--onto` optie te gebruiken van `git rebase`:
 
 	$ git rebase --onto master server client
 
-Dit zegt in feite, "Check de client branch uit, vogel de patches van de gezamenlijke voorouder van de `client` en de `server` branches uit, en speel die opnieuw af op `master`." Het is een beetje complex; maar het resultaat, getoond in Figuur 3-32, is erg vet.
+Dit zegt in feite, "Check de client branch uit, verzamel de patches van de gezamenlijke voorouder van de `client` en de `server` branches, en speel die opnieuw af op `master`." Het is een beetje ingewikkeld, maar het resultaat, getoond in Figuur 3-32, is erg prettig.
 
 Insert 18333fig0332.png
-Figuur 3-32. Een onderwerp branch rebasen vanaf een andere onderwerp branch.
+Figuur 3-32. Een topic branch rebasen vanaf een andere topic branch.
 
 Nu kun je een fast-forward doen van je master branch (zie Figuur 3-33):
 
@@ -538,21 +538,21 @@ Nu kun je een fast-forward doen van je master branch (zie Figuur 3-33):
 Insert 18333fig0333.png
 Figuur 3-33. Je master branch fast-forwarden om de client branch wijzigingen mee te nemen.
 
-Stel dat je beslist om je server branch ook binnen te halen. Je kunt de server branch rebasen op de master branch zonder het eerst te moeten uitchecken door `git rebase [basisbranch] [onderwerpbranch]` uit te voeren — wat de onderwerp branch uitchecked (in dit geval, `server`) voor je en het opnieuw afspeelt om de basis branch (`master`):
+Stel dat je besluit om de server branch ook te pullen. Je kunt de server branch rebasen op de master branch zonder het eerst te hoeven uitchecken door `git rebase [basisbranch] [topicbranch]` uit te voeren, wat de topic branch voor je uitchecked (in dit geval, `server`) en het opnieuw afspeelt om de basis branch (`master`):
 
 	$ git rebase master server
 
-Dit speelt je `server` werk opnieuw af bovenop je `master` werk, zoals getoond in Figuur 3-34.
+Dit speelt het `server` werk opnieuw af op het `master` werk, zoals getoond in Figuur 3-34.
 
 Insert 18333fig0334.png
-Figuur 3-34. Je server branch bovenop je master branch rebasen.
+Figuur 3-34. Je server branch op je master branch rebasen.
 
-Daarna, kun je de basis branch (`master`) fast-forwarden:
+Daarna kan je de basis branch (`master`) fast-forwarden:
 
 	$ git checkout master
 	$ git merge server
 
-Je kunt de `client` en `server` branches verwijderen, omdat al het werk geïntegreerd is en je ze niet meer nodig hebt, waarbij je historie voor het hele proces er uit ziet zoals Figuur 3-35:
+Je kunt de `client` en `server` branches verwijderen, omdat al het werk geïntegreerd is en je ze niet meer nodig hebt, en de historie voor het hele proces ziet eruit zoals in Figuur 3-35:
 
 	$ git branch -d client
 	$ git branch -d server
@@ -562,38 +562,38 @@ Figuur 3-35. Uiteindelijke commit historie.
 
 ### De gevaren van rebasen ###
 
-Ahh, maar de zegen van rebasen is niet zonder nadelen, wat samengevat kan worden in een enkele regel:
+Ahh, maar de zegeningen van rebasen zijn niet geheel zonder nadelen, samengevat in één enkele regel:
 
-**Rebase geen commits die je teruggezet hebt naar een publiek repository.**
+**Rebase geen commits die je gepushed hebt naar een publiek repository.**
 
-Als je die richtlijn volgt, dan gebeurt je niets. Als je dat niet doet, zullen mensen je haten, en je zult door vrienden en familie uitgehoond worden.
+Als je die richtlijn volgt, dan zal je niets overkomen. Als je dat niet doet, zullen mensen je haten en je zult door vrienden en familie uitgehoond worden.
 
-Als je spullen rebaset, laat je bestaande commits achter en maak je nieuwe aan die vergelijkbaar zijn maar anders. Als je commits ergens naartoe zet en andere halen ze binnen en baseren daar werk op, en vervolgens herschrijf je die commits met `git rebase` en zet ze opnieuw terug, dan zullen je medewerkers hun werk opnieuw moeten samenvoegen en zullen de dingen vervelend worden als je hun werk probeert binnen te halen in het jouwe.
+Als je spullen rebaset, zet je bestaande commits buitenspel en maak je nieuwe aan die vergelijkbaar zijn maar anders. Als je commits ergens pushed en andere pullen deze en baseren daar werk op, en vervolgens herschrijf je die commits met `git rebase` en pushed deze weer, dan zullen je medewerkers hun werk opnieuw moeten mergen en zal de boel erg vervelend worden als je hun werk probeert te pullen in het jouwe.
 
-Laten we eens kijken naar een voorbeeld of hoe werk rebasen dat je publiekelijk gemaakt hebt problemen kan veroorzaken. Stel dat je van een centrale server kloont en dan daar wat werk vanaf doet. Je commit historie ziet er uit als Figuur 3-36.
+Laten we eens kijken naar een voorbeeld hoe werk rebasen dat je publiek gemaakt hebt problemen kan veroorzaken. Stel dat je van een centrale server kloont en dan daar wat werk aan doet. Je commit historie ziet er uit als Figuur 3-36.
 
 Insert 18333fig0336.png
-Figuur 3-36. Kloon een repository, en baseer wat werk daarop.
+Figuur 3-36. Kloon een repository, en doe wat werk daarop.
 
-Nu, doet iemand anders wat meer werk dat een samenvoeging bevat, en zet dat werk terug naar de centrale server. Je pakt dat en voegt de nieuwe remote branch in jouw werk, zodat je historie er uit ziet zoals Figuur 3-37.
+Nu doet iemand anders wat meer werk dat een merge bevat, en pushed dat werk naar de centrale server. Je fetched dat en merged de nieuwe remote branch in jouw werk, zodat je historie er uit ziet zoals Figuur 3-37.
 
 Insert 18333fig0337.png
-Figuur 3-37. Haal meer commits op, en voeg ze samen in je werk.
+Figuur 3-37. Haal meer commits op, en merge ze in je werk.
 
-Daarna, beslist de persoon die het werk teruggezet heeft om terug te gaan en hun werk in plaats daarvan te rebasen; ze voeren een `git push --force` uit om de historie op de server te herschrijven. Je haalt dan van die server op, waarbij je de nieuwe commits omlaag haalt.
+Daarna, beslist de persoon die het werk gepushed heeft om terug te gaan en hun werk te gaan rebasen; ze voeren een `git push --force` uit om de historie op de server te herschrijven. Je pulled daarna van die server, waarbij je de nieuwe commits binnen krijgt.
 
 Insert 18333fig0338.png
-Figuur 3-38. Iemand zet gerebasete commits terug, daarbij commits achterlatend waar jij werk op gebaseerd hebt.
+Figuur 3-38. Iemand pushed gerebasete commits, daarbij commits buitenspel zettend waar jij werk op gebaseerd hebt.
 
-Op dit punt, moet je dit werk opnieuw samenvoegen, alhoewel je dat al gedaan hebt. Rebasen verandert de SHA-1 hashes van deze commits, dus voor Git zien ze er uit als nieuwe commits, terwijl je in feite al het C4 werk in je historie hebt (zie Figuur 3-39).
+Nu moet je dit werk opnieuw mergeen, hoewel je dat al gedaan hebt. Rebasen verandert de SHA-1 hashes van deze commits, dus voor Git zien ze er uit als nieuwe commits, terwijl je in feite het C4 werk al in je historie hebt (zie Figuur 3-39).
 
 Insert 18333fig0339.png
-Figuur 3-39. Je voegt hetzelfde werk opnieuw samen in een nieuwe samenvoegingscommit.
+Figuur 3-39. Je merge hetzelfde werk opnieuw in een nieuwe merge commit.
 
-Je moet dat werk op een bepaald punt samenvoegen, zodat je bij kunt blijven met de andere ontwikkelaar in de toekomst. Nadat je dat doet, zal je history zowel de C4 als de C4' commits bevatten, die verschillende SHA-1 hashes hebben, maar hetzelfde werk introduceren en hetzelfde commit bericht hebben. Als je een `git log` uitvoert als je historie er zo uitziet, dan zul je twee commits zien die dezelfde auteur en bericht hebben, wat verwarrend zal zijn. Daarnaast, als je deze historie terugzet naar de server, dan zul je al die gerebasete commits opnieuw introduceren op de centrale server, wat mensen nog meer kan verwarren.
+Je moet dat werk op een bepaald punt mergen, zodat je in de toekomst bij kunt blijven met de andere ontwikkelaar. Nadat je dat gedaan hebt, zal je history zowel de C4 als de C4' commits bevatten, die verschillende SHA-1 hashes hebben, maar die hetzelfde werk introduceren en dezelfde commit bericht hebben. Als je een `git log` uitvoert als je historie er zo uitziet, dan zul je twee commits zien die dezelfde auteur, datum en bericht hebben, wat verwarring geeft. Daarnaast zal je, als je deze historie pushed naar de server, al die gerebasete commits opnieuw introduceren op de centrale server, wat mensen nog meer kan verwarren.
 
-Als je rebasen behandelt als een manier om op te ruimen en met commits werkt voordat je ze terugzet, en als je alleen commits rebaset die nog nooit publiekelijk beschikbaar zijn geweest, dan zal alles in orde zijn. Als je commits rebaset die al publiekelijk teruggezet zijn, en mensen kunnen werk gebaseerd hebben op die commits, dan bereid je maar voor op wat frustrerende problemen.
+Als je rebasen behandelt als een manier om commits op te ruimen ze bewerken voordat je ze pushed, en als je alleen commits rebaset die nog nooit publiekelijk beschikbaar zijn geweest, dan zal er niets aan de hand zijn. Als je commits rebaset die al publiekelijk gepushed zijn, en mensen kunnen werk gebaseerd hebben op die commits, bereid je dan maar voor op een aantal frustrerende problemen.
 
 ## Samenvatting ##
 
-We hebben de basis van branchen en samenvoegen in Git behandeld. Je moet je op je gemak voelen met het maken en omschakelen naar nieuwe branches, schakelen tussen branches, en lokale branches samen te voegen. Je zou in staat moeten zijn om je branches te delen door ze naar een gedeelde server terug te zetten, met anderen op gedeelde branches samen te werken en je branches te rebasen voordat ze gedeeld zijn.
+We hebben de basis van branchen en mergen in Git behandeld. Je zou je op je gemak moeten voelen met het maken en omschakelen naar nieuwe branches, omschakelen tussen branches, en lokale branches te mergen. Je zou in staat moeten zijn om je branches te delen door ze naar een gedeelde server te pushen, met anderen op gedeelde branches samen te werken en je branches te rebasen voordat ze gedeeld zijn.

From abf31985675d451704cc852c0e8be8485a7c8e9c Mon Sep 17 00:00:00 2001
From: Matt Deacalion Stevens <matt@dirtymonkey.co.uk>
Date: Wed, 29 Jan 2014 18:04:09 +0000
Subject: [PATCH 134/690] Update command line output in Chapter 2

The command line output in the examples is from an older version of Git
(1.7.*) and is slightly inconsistent with the latest version.
---
 en/02-git-basics/01-chapter2.markdown | 297 +++++++++++++-------------
 1 file changed, 152 insertions(+), 145 deletions(-)

diff --git a/en/02-git-basics/01-chapter2.markdown b/en/02-git-basics/01-chapter2.markdown
index bbf48f64d..57d2103a7 100644
--- a/en/02-git-basics/01-chapter2.markdown
+++ b/en/02-git-basics/01-chapter2.markdown
@@ -54,8 +54,8 @@ Figure 2-1. The lifecycle of the status of your files.
 The main tool you use to determine which files are in which state is the `git status` command. If you run this command directly after a clone, you should see something like this:
 
 	$ git status
-	# On branch master
-	nothing to commit (working directory clean)
+	On branch master
+	nothing to commit, working directory clean
 
 This means you have a clean working directory — in other words, no tracked files are modified. Git also doesn’t see any untracked files, or they would be listed here. Finally, the command tells you which branch you’re on. For now, that is always `master`, which is the default; you won’t worry about it here. The next chapter will go over branches and references in detail.
 
@@ -63,11 +63,12 @@ Let’s say you add a new file to your project, a simple `README` file. If the f
 
 	$ vim README
 	$ git status
-	# On branch master
-	# Untracked files:
-	#   (use "git add <file>..." to include in what will be committed)
-	#
-	#	README
+	On branch master
+	Untracked files:
+	  (use "git add <file>..." to include in what will be committed)
+	
+	        README
+
 	nothing added to commit but untracked files present (use "git add" to track)
 
 You can see that your new `README` file is untracked, because it’s under the “Untracked files” heading in your status output. Untracked basically means that Git sees a file you didn’t have in the previous snapshot (commit); Git won’t start including it in your commit snapshots until you explicitly tell it to do so. It does this so you don’t accidentally begin including generated binary files or other files that you did not mean to include. You do want to start including README, so let’s start tracking the file.
@@ -81,12 +82,12 @@ In order to begin tracking a new file, you use the command `git add`. To begin t
 If you run your status command again, you can see that your `README` file is now tracked and staged:
 
 	$ git status
-	# On branch master
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#	new file:   README
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        new file:   README
+	
 
 You can tell that it’s staged because it’s under the “Changes to be committed” heading. If you commit at this point, the version of the file at the time you ran `git add` is what will be in the historical snapshot. You may recall that when you ran `git init` earlier, you then ran `git add (files)` — that was to begin tracking files in your directory. The `git add` command takes a path name for either a file or a directory; if it’s a directory, the command adds all the files in that directory recursively.
 
@@ -95,58 +96,60 @@ You can tell that it’s staged because it’s under the “Changes to be commit
 Let’s change a file that was already tracked. If you change a previously tracked file called `benchmarks.rb` and then run your `status` command again, you get something that looks like this:
 
 	$ git status
-	# On branch master
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#	new file:   README
-	#
-	# Changes not staged for commit:
-	#   (use "git add <file>..." to update what will be committed)
-	#
-	#	modified:   benchmarks.rb
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        new file:   README
+
+	Changes not staged for commit:
+	  (use "git add <file>..." to update what will be committed)
+	  (use "git checkout -- <file>..." to discard changes in working directory)
+	
+	        modified:   benchmarks.rb
+	
 
 The `benchmarks.rb` file appears under a section named “Changes not staged for commit” — which means that a file that is tracked has been modified in the working directory but not yet staged. To stage it, you run the `git add` command (it’s a multipurpose command — you use it to begin tracking new files, to stage files, and to do other things like marking merge-conflicted files as resolved). Let’s run `git add` now to stage the `benchmarks.rb` file, and then run `git status` again:
 
 	$ git add benchmarks.rb
 	$ git status
-	# On branch master
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#	new file:   README
-	#	modified:   benchmarks.rb
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        new file:   README
+	        modified:   benchmarks.rb
+	
 
 Both files are staged and will go into your next commit. At this point, suppose you remember one little change that you want to make in `benchmarks.rb` before you commit it. You open it again and make that change, and you’re ready to commit. However, let’s run `git status` one more time:
 
 	$ vim benchmarks.rb
 	$ git status
-	# On branch master
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#	new file:   README
-	#	modified:   benchmarks.rb
-	#
-	# Changes not staged for commit:
-	#   (use "git add <file>..." to update what will be committed)
-	#
-	#	modified:   benchmarks.rb
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        new file:   README
+	        modified:   benchmarks.rb
+	
+	Changes not staged for commit:
+	  (use "git add <file>..." to update what will be committed)
+	  (use "git checkout -- <file>..." to discard changes in working directory)
+	
+	        modified:   benchmarks.rb
+	
 
 What the heck? Now `benchmarks.rb` is listed as both staged and unstaged. How is that possible? It turns out that Git stages a file exactly as it is when you run the `git add` command. If you commit now, the version of `benchmarks.rb` as it was when you last ran the `git add` command is how it will go into the commit, not the version of the file as it looks in your working directory when you run `git commit`. If you modify a file after you run `git add`, you have to run `git add` again to stage the latest version of the file:
 
 	$ git add benchmarks.rb
 	$ git status
-	# On branch master
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#	new file:   README
-	#	modified:   benchmarks.rb
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        new file:   README
+	        modified:   benchmarks.rb
+	
 
 ### Ignoring Files ###
 
@@ -192,17 +195,18 @@ If the `git status` command is too vague for you — you want to know exactly wh
 Let’s say you edit and stage the `README` file again and then edit the `benchmarks.rb` file without staging it. If you run your `status` command, you once again see something like this:
 
 	$ git status
-	# On branch master
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#	new file:   README
-	#
-	# Changes not staged for commit:
-	#   (use "git add <file>..." to update what will be committed)
-	#
-	#	modified:   benchmarks.rb
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        new file:   README
+	
+	Changes not staged for commit:
+	  (use "git add <file>..." to update what will be committed)
+	  (use "git checkout -- <file>..." to discard changes in working directory)
+	
+	        modified:   benchmarks.rb
+	
 
 To see what you’ve changed but not yet staged, type `git diff` with no other arguments:
 
@@ -247,16 +251,18 @@ For another example, if you stage the `benchmarks.rb` file and then edit it, you
 	$ git add benchmarks.rb
 	$ echo '# test line' >> benchmarks.rb
 	$ git status
-	# On branch master
-	#
-	# Changes to be committed:
-	#
-	#	modified:   benchmarks.rb
-	#
-	# Changes not staged for commit:
-	#
-	#	modified:   benchmarks.rb
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        modified:   benchmarks.rb
+	
+	Changes not staged for commit:
+	  (use "git add <file>..." to update what will be committed)
+	  (use "git checkout -- <file>..." to discard changes in working directory)
+	
+	        modified:   benchmarks.rb
+	
 
 Now you can use `git diff` to see what is still unstaged
 
@@ -305,10 +311,9 @@ The editor displays the following text (this example is a Vim screen):
 	# with '#' will be ignored, and an empty message aborts the commit.
 	# On branch master
 	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
 	#       new file:   README
 	#       modified:   benchmarks.rb
+	#
 	~
 	~
 	~
@@ -319,8 +324,8 @@ You can see that the default commit message contains the latest output of the `g
 Alternatively, you can type your commit message inline with the `commit` command by specifying it after a `-m` flag, like this:
 
 	$ git commit -m "Story 182: Fix benchmarks for speed"
-	[master]: created 463dc4f: "Fix benchmarks for speed"
-	 2 files changed, 3 insertions(+), 0 deletions(-)
+	[master 463dc4f] Fix benchmarks for speed
+	 2 files changed, 3 insertions(+)
 	 create mode 100644 README
 
 Now you’ve created your first commit! You can see that the commit has given you some output about itself: which branch you committed to (`master`), what SHA-1 checksum the commit has (`463dc4f`), how many files were changed, and statistics about lines added and removed in the commit.
@@ -332,15 +337,17 @@ Remember that the commit records the snapshot you set up in your staging area. A
 Although it can be amazingly useful for crafting commits exactly how you want them, the staging area is sometimes a bit more complex than you need in your workflow. If you want to skip the staging area, Git provides a simple shortcut. Providing the `-a` option to the `git commit` command makes Git automatically stage every file that is already tracked before doing the commit, letting you skip the `git add` part:
 
 	$ git status
-	# On branch master
-	#
-	# Changes not staged for commit:
-	#
-	#	modified:   benchmarks.rb
-	#
+	On branch master
+	Changes not staged for commit:
+	  (use "git add <file>..." to update what will be committed)
+	  (use "git checkout -- <file>..." to discard changes in working directory)
+	
+	        modified:   benchmarks.rb
+	
+	no changes added to commit (use "git add" and/or "git commit -a")
 	$ git commit -a -m 'added new benchmarks'
 	[master 83e38c7] added new benchmarks
-	 1 files changed, 5 insertions(+), 0 deletions(-)
+	 1 files changed, 5 insertions(+)
 
 Notice how you don’t have to run `git add` on the `benchmarks.rb` file in this case before you commit.
 
@@ -352,26 +359,26 @@ If you simply remove the file from your working directory, it shows up under the
 
 	$ rm grit.gemspec
 	$ git status
-	# On branch master
-	#
-	# Changes not staged for commit:
-	#   (use "git add/rm <file>..." to update what will be committed)
-	#
-	#       deleted:    grit.gemspec
-	#
+	On branch master
+	Changes not staged for commit:
+	  (use "git add/rm <file>..." to update what will be committed)
+	  (use "git checkout -- <file>..." to discard changes in working directory)
+	
+	        deleted:    grit.gemspec
+	
+	no changes added to commit (use "git add" and/or "git commit -a")
 
 Then, if you run `git rm`, it stages the file’s removal:
 
 	$ git rm grit.gemspec
 	rm 'grit.gemspec'
 	$ git status
-	# On branch master
-	#
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#       deleted:    grit.gemspec
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        deleted:    grit.gemspec
+	
 
 The next time you commit, the file will be gone and no longer tracked. If you modified the file and added it to the index already, you must force the removal with the `-f` option. This is a safety feature to prevent accidental removal of data that hasn’t yet been recorded in a snapshot and that can’t be recovered from Git.
 
@@ -401,14 +408,12 @@ and it works fine. In fact, if you run something like this and look at the statu
 
 	$ git mv README.txt README
 	$ git status
-	# On branch master
-	# Your branch is ahead of 'origin/master' by 1 commit.
-	#
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#       renamed:    README.txt -> README
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        renamed:    README.txt -> README
+	
 
 However, this is equivalent to running something like this:
 
@@ -525,7 +530,7 @@ You can also use a series of summarizing options with `git log`. For example, if
 	    changed the version number
 
 	 Rakefile |    2 +-
-	 1 files changed, 1 insertions(+), 1 deletions(-)
+	 1 file changed, 1 insertion(+), 1 deletion(-)
 
 	commit 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7
 	Author: Scott Chacon <schacon@gee-mail.com>
@@ -534,7 +539,7 @@ You can also use a series of summarizing options with `git log`. For example, if
 	    removed unnecessary test code
 
 	 lib/simplegit.rb |    5 -----
-	 1 files changed, 0 insertions(+), 5 deletions(-)
+	 1 file changed, 5 deletions(-)
 
 	commit a11bef06a3f659402fe7563abf99ad00de2209e6
 	Author: Scott Chacon <schacon@gee-mail.com>
@@ -545,7 +550,7 @@ You can also use a series of summarizing options with `git log`. For example, if
 	 README           |    6 ++++++
 	 Rakefile         |   23 +++++++++++++++++++++++
 	 lib/simplegit.rb |   25 +++++++++++++++++++++++++
-	 3 files changed, 54 insertions(+), 0 deletions(-)
+	 3 files changed, 54 insertions(+)
 
 As you can see, the `--stat` option prints below each commit entry a list of modified files, how many files were changed, and how many lines in those files were added and removed. It also puts a summary of the information at the end.
 Another really useful option is `--pretty`. This option changes the log output to formats other than the default. A few prebuilt options are available for you to use. The `oneline` option prints each commit on a single line, which is useful if you’re looking at a lot of commits. In addition, the `short`, `full`, and `fuller` options show the output in roughly the same format but with less or more information, respectively:
@@ -700,31 +705,32 @@ The next two sections demonstrate how to wrangle your staging area and working d
 
 	$ git add .
 	$ git status
-	# On branch master
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#       modified:   README.txt
-	#       modified:   benchmarks.rb
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        modified:   README.txt
+	        modified:   benchmarks.rb
+	
 
 Right below the “Changes to be committed” text, it says "use `git reset HEAD <file>...` to unstage". So, let’s use that advice to unstage the `benchmarks.rb` file:
 
 	$ git reset HEAD benchmarks.rb
-	benchmarks.rb: locally modified
+	Unstaged changes after reset:
+	M       benchmarks.rb
 	$ git status
-	# On branch master
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#       modified:   README.txt
-	#
-	# Changes not staged for commit:
-	#   (use "git add <file>..." to update what will be committed)
-	#   (use "git checkout -- <file>..." to discard changes in working directory)
-	#
-	#       modified:   benchmarks.rb
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        modified:   README.txt
+	
+	Changes not staged for commit:
+	  (use "git add <file>..." to update what will be committed)
+	  (use "git checkout -- <file>..." to discard changes in working directory)
+	
+	        modified:   benchmarks.rb
+	
 
 The command is a bit strange, but it works. The `benchmarks.rb` file is modified but once again unstaged.
 
@@ -732,23 +738,23 @@ The command is a bit strange, but it works. The `benchmarks.rb` file is modified
 
 What if you realize that you don’t want to keep your changes to the `benchmarks.rb` file? How can you easily unmodify it — revert it back to what it looked like when you last committed (or initially cloned, or however you got it into your working directory)? Luckily, `git status` tells you how to do that, too. In the last example output, the unstaged area looks like this:
 
-	# Changes not staged for commit:
-	#   (use "git add <file>..." to update what will be committed)
-	#   (use "git checkout -- <file>..." to discard changes in working directory)
-	#
-	#       modified:   benchmarks.rb
-	#
+	Changes not staged for commit:
+	  (use "git add <file>..." to update what will be committed)
+	  (use "git checkout -- <file>..." to discard changes in working directory)
+	
+	        modified:   benchmarks.rb
+	
 
 It tells you pretty explicitly how to discard the changes you’ve made (at least, the newer versions of Git, 1.6.1 and later, do this — if you have an older version, we highly recommend upgrading it to get some of these nicer usability features). Let’s do what it says:
 
 	$ git checkout -- benchmarks.rb
 	$ git status
-	# On branch master
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#       modified:   README.txt
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        modified:   README.txt
+	
 
 You can see that the changes have been reverted. You should also realize that this is a dangerous command: any changes you made to that file are gone — you just copied another file over it. Don’t ever use this command unless you absolutely know that you don’t want the file. If you just need to get it out of the way, we’ll go over stashing and branching in the next chapter; these are generally better ways to go.
 
@@ -764,12 +770,12 @@ Managing remote repositories includes knowing how to add remote repositories, re
 To see which remote servers you have configured, you can run the `git remote` command. It lists the shortnames of each remote handle you’ve specified. If you’ve cloned your repository, you should at least see *origin* — that is the default name Git gives to the server you cloned from:
 
 	$ git clone git://github.com/schacon/ticgit.git
-	Initialized empty Git repository in /private/tmp/ticgit/.git/
-	remote: Counting objects: 595, done.
-	remote: Compressing objects: 100% (269/269), done.
-	remote: Total 595 (delta 255), reused 589 (delta 253)
-	Receiving objects: 100% (595/595), 73.31 KiB | 1 KiB/s, done.
-	Resolving deltas: 100% (255/255), done.
+	Cloning into 'ticgit'...
+	remote: Reusing existing pack: 1857, done.
+	remote: Total 1857 (delta 0), reused 0 (delta 0)
+	Receiving objects: 100% (1857/1857), 374.35 KiB | 193.00 KiB/s, done.
+	Resolving deltas: 100% (772/772), done.
+	Checking connectivity... done.
 	$ cd ticgit
 	$ git remote
 	origin
@@ -940,6 +946,7 @@ You can see the tag data along with the commit that was tagged by using the `git
 	Date:   Mon Feb 9 14:45:11 2009 -0800
 
 	my version 1.4
+
 	commit 15027957951b64cf874c3557a0f3547bd83b3ff6
 	Merge: 4a447f7... a6b4c97...
 	Author: Scott Chacon <schacon@gee-mail.com>

From 1d1ce116c69cda792844bf9eac6907a326ca5b09 Mon Sep 17 00:00:00 2001
From: cor <git@cpt1.demon.nl>
Date: Sun, 26 Jan 2014 14:24:56 +0100
Subject: [PATCH 135/690] [nl] Retranslate chapter 05, first phase

Replace strange character sequences with actual diacritics and hyphens.
---
 nl/05-distributed-git/01-chapter5.markdown | 336 +++++++++++----------
 1 file changed, 177 insertions(+), 159 deletions(-)

diff --git a/nl/05-distributed-git/01-chapter5.markdown b/nl/05-distributed-git/01-chapter5.markdown
index 1bfb363f2..cee8e7138 100644
--- a/nl/05-distributed-git/01-chapter5.markdown
+++ b/nl/05-distributed-git/01-chapter5.markdown
@@ -1,76 +1,76 @@
 # Gedistribueerd Git #
 
-Nu dat je een remote Git repository hebt ingesteld als een punt waar alle ontwikkelaars hun code kunnen delen, en je bekend bent met fundamentele Git commando's in een lokale werkwijze, zul je kijken hoe je een paar gedistribueerde werkwijzen kunt gebruiken die Git je toestaat.
+Nu dat je een remote Git repository hebt ingesteld als een plaats waar alle ontwikkelaars hun code kunnen delen, en je bekend bent met fundamentele Git commando's in een lokale werkwijze, zul je hier zien hoe je een paar gedistribueerde werkwijzen kunt gebruiken die je met Git kunt bereiken.
 
-In dit hoofdstuk zul je zien hoe je met Git kunt werken in een gedistribueerde omgeving als een bijdrager en als een integrator. Dat wil zeggen, je zult leren hoe je succesvol code kunt bijdragen aan een project en hoe je het zo makkelijk mogelijk maakt voor jou en de onderhouder van het project, en ook hoe je een project succesvol kunt onderhouden waarbij een aantal ontwikkelaars bijdragen.
+In dit hoofdstuk zul je zien hoe je met Git kunt werken in een gedistribueerde omgeving als een bijdrager (contributor) en als een integrator. Dat wil zeggen, je zult leren hoe je succesvol code kunt bijdragen aan een project en hoe je het zo makkelijk mogelijk maakt voor jou en de onderhouder van het project, en ook hoe je een project succesvol kunt onderhouden waarbij een aantal ontwikkelaars bijdragen.
 
 ## Gedistribueerde werkwijzen ##
 
-In tegenstelling tot gecentraliseerde versiebeheersystemen (CVCS), staat de gedistribueerde aard van Git je toe om veel flexibeler te zijn in de manier waarop ontwikkelaars bijdragen in projecten. Bij gecentraliseerde systemen is iedere ontwikkelaar een knooppunt dat min of meer gelijkwaardig werkt op een centraal punt. In Git is iedere ontwikkelaar zowel een knoop als een centraal punt – dat wil zeggen, iedere ontwikkelaar kan zowel code bijdragen aan andere repositories, als ook een publiek repository onderhouden waarop andere ontwikkelaars hun werk baseren en waaraan zij kunnen bijdragen. Dit stelt je project en of je team in staat om een enorm aantal werkwijzen er op na te houden, dus ik zal een aantal veel voorkomende manieren behandelen die gebruik maken van deze flexibiliteit. Ik zal de sterke en mogelijke zwakke punten van ieder ontwerp behandelen; je kunt er een kiezen om te gebruiken, of je kunt van iedere wijze een paar eigenschappen pakken en mengen.
+In tegenstelling tot gecentraliseerde versiebeheersystemen (CVCSen), stelt de gedistribueerde aard van Git je in staat om veel flexibeler te zijn in de manier waarop ontwikkelaars samenwerken in projecten. Bij gecentraliseerde systemen is iedere ontwikkelaar een knooppunt dat min of meer gelijkwaardig werkt op een centraal punt. In Git is iedere ontwikkelaar zowel een knooppunt als een spil - dat wil zeggen, iedere ontwikkelaar kan zowel code bijdragen aan andere repositories, als ook een publiek repository beheren waarop andere ontwikkelaars hun werk baseren en waaraan zij kunnen bijdragen. Dit stelt je project en/of je team in staat om een enorm aantal werkwijzen er op na te houden, dus ik zal een aantal veel voorkomende manieren behandelen die gebruik maken van deze flexibiliteit. Ik zal de sterke en mogelijke zwakke punten van ieder ontwerp behandelen; je kunt er een kiezen om te gebruiken, of je kunt van iedere wijze een paar eigenschappen overnemen en mengen.
 
 ### Gecentraliseerde werkwijze ###
 
-In gecentraliseerde systemen is er over het algemeen een enkel samenwerkingsmodel – de gecentraliseerde werkwijze. Eén centraal punt, of repository, kan code aanvaarden, en iedereen synchroniseert zijn werk daarmee. Een aantal ontwikkelaars zijn knopen – gebruikers van dat centrale punt – en synchroniseren met die plaats (zie Figuur 5-1).
+In gecentraliseerde systemen is er over het algemeen een enkel samenwerkingsmodel - de gecentraliseerde werkwijze. E�n centraal punt, of repository, kan code aanvaarden, en iedereen synchroniseert zijn werk daarmee. Een aantal ontwikkelaars zijn knopen - gebruikers van dat centrale punt - en synchroniseren met die plaats (zie Figuur 5-1).
 
 Insert 18333fig0501.png
 Figuur 5-1. Gecentraliseerde Werkwijze.
 
-Dit betekent dat als twee ontwikkelaars klonen van het gecentraliseerde punt en beide wijzigingen doen, de eerste ontwikkelaar zijn wijzigingen terug kan zetten zonder problemen. De tweede ontwikkelaar zal het werk van de eerste in het zijne moeten samenvoegen voordat hij het zijne kan terugzetten, om zo niet het werk van de eerste te overschrijven. Dit concept werkt zo in Git zoals het ook werkt in Subversion (of ieder ander CVCS), en dit model werkt perfect in Git.
+Dit betekent dat als twee ontwikkelaars klonen van het gecentraliseerde punt en beide wijzigingen doen, de eerste ontwikkelaar zijn wijzigingen terug kan zetten zonder problemen. De tweede ontwikkelaar zal het werk van de eerste in het zijne moeten samenvoegen voordat hij het zijne kan terugzetten, om zo niet het werk van de eerste te overschrijven. Dit concept werkt in Git zoals het ook werkt in Subversion (of ieder ander CVCS), en dit model werkt prima in Git.
 
-Als je een klein team hebt, of al vertrouwd bent met een gecentraliseerde werkwijze in je bedrijf of team, dan kun je eenvoudig doorgaan met het gebruiken van die werkwijze met Git. Stel eenvoudigweg een enkel repository in, en geef iedereen in je team terugzettoegang; Git zal gebruikers niet toestaan om elkaars wijzigingen te overschrijven. Als een ontwikkelaar kloont, wijzigingen maakt, en dan probeert zijn wijzigingen terug te zetten terwijl een andere ontwikkelaar de zijne in de tussentijd heeft teruggezet, dan zal de server de wijzigingen van die ontwikkelaar weigeren. "Non-fast-forward-wijzigingen" kunnen niet teruggezet worden alvorens de conflicten worden opgelost.
-Deze werkwijze is voor een hoop mensen aantrekkelijk omdat het een wijze is waarmee veel mensen bekend zijn en zich op hun gemak bij voelen.
+Als je een klein team hebt, of al vertrouwd bent met een gecentraliseerde werkwijze in je bedrijf of team, dan kun je eenvoudig doorgaan met het gebruiken van die werkwijze met Git. Stel eenvoudigweg een enkele repository in, en geef iedereen in je team  push-toegang; Git zal gebruikers niet toestaan om elkaars wijzigingen te overschrijven. Als een ontwikkelaar kloont, wijzigingen maakt, en dan probeert zijn wijzigingen terug te zetten terwijl een andere ontwikkelaar de zijne in de tussentijd heeft teruggezet, dan zal de server de wijzigingen van die ontwikkelaar weigeren. Ze zullen verteld worden dat ze een "non-fast-forward-wijziging" proberen te pushen en dat ze dat niet wordt toegestaan totdat ze hebben gefetched en gemerged.
+Deze werkwijze is voor een hoop mensen aantrekkelijk omdat het er een is waarmee veel mensen bekend zijn en zich op hun gemak bij voelen.
 
 ### Integratie-manager werkwijze ###
 
-Omdat Git je toestaat om meerdere remote repositories te hebben, is het mogelijk om een werkwijze te hebben waarbij iedere ontwikkelaar schrijftoegang heeft tot zijn eigen publieke repository en leestoegang op de andere. Dit scenario heeft vaak een gezagdragend repository dat het "officiële" project voorstelt. Om bij te kunnen dragen tot dat project, maak je je eigen publieke kloon van het project en zet je wijzigingen daarin terug. Daarna stuur je een verzoek naar de eigenaar van het hoofdproject om jouw wijzigingen binnen te halen. Hij kan je repository toevoegen als een remote, je wijzigingen lokaal testen, ze in zijn branch samenvoegen, en naar zijn repository terugzetten. Het proces werkt als volgt (zie Figuur 5-2):
+Omdat Git je toestaat om meerdere remote repositories te hebben, is het mogelijk om een werkwijze te hebben waarbij iedere ontwikkelaar schrijftoegang heeft tot zijn eigen publieke repository en leestoegang op de andere. Dit scenario heeft vaak een gezagdragend (canonical) repository dat het "offici�le" project voorstelt. Om bij te kunnen dragen tot dat project, maak je je eigen publieke kloon van het project en zet je wijzigingen daarin terug. Daarna stuur je een verzoek naar de eigenaar van het hoofdproject om jouw wijzigingen binnen te halen (pull request). Hij kan je repository toevoegen als een remote, je wijzigingen lokaal testen, ze in zijn branch mergen, en naar zijn repository terugzetten. Het proces werkt als volgt (zie Figuur 5-2):
 
-1. De projecteigenaar zet terug naar zijn eigen repository.
-2. Een bijdrager kloont dat repository en maakt wijzigingen.
-3. De bijdrager zet terug naar zijn eigen publieke kopie.
-4. De bijdrager stuurt de eigenaar een e-mail met de vraag om de wijzigingen binnen te halen.
-5. De eigenaar voegt het repo van de bijdrager toe als een remote en voegt lokaal samen.
-6. De eigenaar zet samengevoegde wijzigingen terug in het hoofdrepository.
+1. De projecteigenaar pushed naar de publieke repository.
+2. Een bijdrager kloont die repository en maakt wijzigingen.
+3. De bijdrager pushed naar zijn eigen publieke kopie.
+4. De bijdrager stuurt de eigenaar een e-mail met de vraag om de wijzigingen binnen te halen (pull request).
+5. De eigenaar voegt de repo van de bijdrager toe als een remote en merged lokaal.
+6. De eigenaar pushed de gemergde wijzigingen terug in de hoofdrepository.
 
 Insert 18333fig0502.png
 Figuur 5-2. Integratie-manager werkwijze.
 
-Dit is een veel voorkomende werkwijze bij websites zoals GitHub, waarbij het eenvoudig is om een project af te splitsen en je wijzigingen terug te zetten in jouw afgesplitste project zodat iedereen ze kan zien. Een van de grote voordelen van deze aanpak is dat je door kunt gaan met werken, en de eigenaar van het hoofdrepository jouw wijzigingen op ieder moment binnen kan halen. Bijdragers hoeven niet te wachten tot het project hun bijdragen invoegt – iedere partij kan op hun eigen tempo werken.
+Dit is een veel voorkomende werkwijze bij websites zoals GitHub, waarbij het eenvoudig is om een project af te splitsen (fork) en je wijzigingen terug te zetten in jouw afgesplitste project waar iedereen ze kan zien. Een van de grote voordelen van deze aanpak is dat je door kunt gaan met werken, en de eigenaar van de hoofdrepository jouw wijzigingen op ieder moment binnen kan halen. Bijdragers hoeven niet te wachten tot het project hun bijdragen invoegt - iedere partij kan op zijn eigen tempo werken.
 
 ### Dictator en luitenanten werkwijze ###
 
-Dit is een variant op de multi-repository werkwijze. Het wordt over het algemeen gebruikt bij enorme projecten met honderden bijdragers; een bekend voorbeeld is de Linux-kernel. Een aantal integrators geven de leiding over bepaalde delen van het repository; zij worden luitenanten genoemd. Alle luitenanten hebben één integrator die bekend staat als de welwillende dictator. Het repository van de welwillende dictator dient als het referentierepository vanwaar alle bijdragers dienen binnen te halen. Het proces werkt als volgt (zie Figuur 5-3):
+Dit is een variant op de multi-repository werkwijze. Het wordt over het algemeen gebruikt bij enorme grote projecten met honderden bijdragers; een bekend voorbeeld is de Linux-kernel. Een aantal integrators geven de leiding over bepaalde delen van het repository, zij worden luitenanten genoemd. Alle luitenanten hebben ��n integrator die bekend staat als de welwillende dictator. De repository van de welwillende dictator dient als het referentierepository vanwaar alle bijdragers dienen binnen te halen. Het proces werkt als volgt (zie Figuur 5-3):
 
-1. Reguliere ontwikkelaars werken op hun eigen onderwerp branch en rebasen hun werk op de hoofdbranch. De hoofdbranch is die van de dictator.
-2. Luitenanten voegen de onderwerp branches van de ontwikkelaars samen in hun hoofdbranch.
-3. De dictator voegt de hoofdbranches van de luitenanten samen in de "dictatorhoofdbranch".
-4. De dictator zet zijn hoofdbranch terug naar het referentierepository zodat de andere ontwikkelaars kunnen rebasen.
+1. Reguliere ontwikkelaars werken op hun eigen onderwerp (topic) branch en rebasen hun werk op de master. De masterbranch is die van de dictator.
+2. Luitenanten mergen de topic branches van de ontwikkelaars in hun masterbranch.
+3. De dictator merged de masterbranches van de luitenanten in de masterbranch van de dictator.
+4. De dictator pushed zijn masterbranch terug naar het referentierepository zodat de andere ontwikkelaars kunnen rebasen.
 
 Insert 18333fig0503.png
 Figuur 5-3. Welwillende-dictatorwerkwijze.
 
-Deze manier van werken komt niet vaak voor, maar kan handig zijn in hele grote projecten of in zeer hierarchische omgevingen, omdat het de projectleider (de dictator) toestaat om het meeste werk te delegeren en grote subsets van code te verzamelen op meerdere punten alvorens ze te integreren.
+Deze manier van werken is niet gewoon, maar kan handig zijn in hele grote projecten of in zeer hi�rarchische omgevingen, omdat het de projectleider (de dictator) in staat stelt om het meeste werk te delegeren en grote subsets van code te verzamelen op meerdere punten alvorens ze te integreren.
 
-Dit zijn veel voorkomende werkwijzen die mogelijk zijn met een gedistribueerd systeem als Git, maar je kunt zien dat er veel variaties mogelijk zijn die passen bij jouw specifieke werkwijze. Nu dat je (naar ik hoop) in staat bent om te bepalen welke werkwijze combinatie voor jou werkt, zal ik wat specifiekere voorbeelden behandelen over hoe je de hoofd rollen kunt vervullen, die in de verschillende werkwijzen voorkomen.
+Dit zijn veel voorkomende werkwijzen die mogelijk zijn met een gedistribueerd systeem als Git, maar je kunt zien dat er veel variaties mogelijk zijn om ze te laten passen bij jouw specifieke werkwijze. Nu dat je (naar ik hoop) in staat bent om te bepalen welke combinatie van werkwijzen voor jou werkt, zal ik wat specifiekere voorbeelden behandelen over hoe je de belangrijkste rollen kunt vervullen, die in de verschillende werkwijzen voorkomen.
 
 ## Bijdragen aan een project ##
 
-Je weet wat de verschillende werkwijzen zijn, en je zou een goed beeld moeten hebben van fundamenteel Git gebruik. In dit gedeelte zul je leren over een aantal voorkomende patronen voor het bijdragen aan een project.
+Je weet wat de verschillende werkwijzen zijn, en je zou het fundamentele gebruik van Git in de vingers moeten hebben. In dit gedeelte zul je leren over een aantal voorkomende patronen voor het bijdragen aan een project.
 
-De grote moeilijkheid bij het beschrijven van dit proces is dat er een enorm aantal variaties mogelijk zijn in hoe het gebeurd. Om dat Git erg flexibel is, kunnen en zullen mensen op vele manieren samenwerken, en het is lastig om te beschrijven hoe je zou moeten bijdragen aan een project – ieder project is een beetje anders. Een aantal van de betrokken variabelen zijn actieve bijdrage grootte, gekozen werkwijze, je commit toegang, een mogelijk de externe bijdrage methode.
+De grote moeilijkheid bij het beschrijven van dit proces is dat er een enorm aantal variaties mogelijk zijn in hoe het gebeurt. Om dat Git erg flexibel is, kunnen en zullen mensen op vele manieren samenwerken, en het is lastig om te beschrijven hoe je zou moeten bijdragen aan een project - ieder project is een beetje anders. Een aantal van de betrokken variabelen zijn de grote van actieve bijdragen, gekozen werkwijze, je commit toegang, een mogelijk de manier waarop externe bijdragen worden gedaan.
 
-De eerste variabele is de actieve bijdrage grootte. Hoeveel gebruikers dragen actief code bij aan dit project, en hoe vaak? In veel gevallen zul je twee of drie ontwikkelaars met een paar commits per dag hebben, of misschien minder voor wat slaperige projecten. Voor zeer grote bedrijven of projecten kan het aantal ontwikkelaars in de duizenden zijn, met tientallen of zelfs honderden patches die iedere dag binnenkomen. Dit is belangrijk omdat met meer en meer ontwikkelaars, je meer en meer problemen tegenkomt met het zeker zijn dat code netjes toegepast kan worden of eenvoudig samengevoegd kan worden. Wijzigingen die je toevoegt kunnen verouderd of zwaar beschadigd raken door werk dat samengevoegd is terwijl je er aan het werken was of terwijl je wijzigingen in de wacht stonden voor goedkeuring of toepassing. Hoe kun je je code consequent bij de tijd en je patches geldig houden?
+De eerste variabele is de grootte van actieve bijdrage. Hoeveel gebruikers dragen actief code bij aan dit project, en hoe vaak? In veel gevallen zul je twee of drie ontwikkelaars met een paar commits per dag hebben, of misschien minder voor wat meer slapende projecten. Voor zeer grote bedrijven of projecten kan het aantal ontwikkelaars in de duizenden lopen, met tientallen of zelfs honderden patches die iedere dag binnenkomen. Dit is belangrijk omdat met meer en meer ontwikkelaars, je meer en meer problemen tegenkomt met het zeker zijn dat code netjes gepatched of eenvoudig gemerged kan worden. Wijzigingen die je indient kunnen verouderd of zwaar beschadigd raken door werk dat gemerged is terwijl je er aan het werken was of terwijl je wijzigingen in de wacht stonden voor goedkeuring of toepassing. Hoe kun je je code consequent bij de tijd en je patches geldig houden?
 
-De volgende variabele is de gebruikte werkwijze in je project. Is het gecentraliseerd, waarbij iedere ontwikkelaar gelijkwaardige schrijftoegang heeft tot de hoofd codebasis? Heeft het project een eigenaar of integrator die alle patches nakijkt? Zijn alle patches gereviewed en goedgekeurd? Ben jij betrokken bij dat proces? Is er een luitenanten systeem in werking, en moet je je werk eerst bij hen inleveren?
+De volgende variabele is de gebruikte werkwijze in het project. Is het gecentraliseerd, waarbij iedere ontwikkelaar gelijkwaardige schrijftoegang heeft tot de hoofd codebasis? Heeft het project een eigenaar of integrator die alle patches controleert? Worden alle patches gereviewed en goedgekeurd? Ben jij betrokken bij dat proces? Is er een luitenanten systeem neergezet, en moet je je werk eerst bij hen inleveren?
 
-Het volgende probleem is je commit toegang. De benodigde werkwijze om bij te dragen aan een project is heel verschillend als je wel schrijftoegang hebt tot het project dan als je dat niet hebt. Als je geen schrijftoegang hebt, wat heeft het project dan als voorkeur om bijdragen te ontvangen? Heeft het wel een beleid? Hoeveel werk draag je per keer bij? Hoe vaak draag je bij?
+Het volgende probleem is je commit toegang. De benodigde werkwijze om bij te dragen aan een project is heel verschillend als je schrijftoegang hebt tot het project dan wanneer je dat niet hebt. Als je geen schrijftoegang hebt, wat heeft de voorkeur van het project om bijdragen te ontvangen? Is er wel een beleid? Hoeveel werk draag je per keer bij? Hoe vaak draag je bij?
 
-Al deze vragen kunnen van invloed zijn op hoe je effectief bijdraagt aan een project en welke werkwijzen de voorkeur hebben of die beschikbaar zijn voor je. Ik zal van ieder van deze aspecten wat behandelen in een aantal gevallen, waarbij ik van eenvoudig tot complex zal gaan; je zou in staat moeten zijn om de specifieke werkwijzen die je in de praktijk hebt te kunnen construeren vanuit deze voorbeelden.
+Al deze vragen kunnen van invloed zijn op hoe je effectief bijdraagt aan een project en welke werkwijzen de voorkeur hebben of die beschikbaar zijn voor je. Ik zal een aantal van deze aspecten behandelen in een aantal voorbeelden, waarbij ik van eenvoudig tot complex zal gaan; je zou in staat moeten zijn om de specifieke werkwijzen die je in de praktijk hebt te kunnen herleiden vanuit deze voorbeelden.
 
 ### Commit richtlijnen ###
 
-Voordat je gaat kijken naar de specifieke gebruiksscenario's, volgt hier een kort stukje over commit berichten. Het hebben van een goede richtlijn voor het maken commits en je daar aan houden maakt het werken met Git en samenwerken met anderen een stuk makkelijker. Het Git project levert een document waarin een aantal tips staan voor het maken van commits van waar je patches uit kunt indienen – je kunt het lezen in de Git broncode in het `Documentation/SubmittingPatches` bestand.
+Voordat je gaat kijken naar de specifieke gebruiksscenario's, volgt hier een kort stukje over commit berichten. Het hebben van een goede richtlijn voor het maken commits en je daar aan houden maakt het werken met Git en samenwerken met anderen een stuk makkelijker. Het Git project levert een document waarin een aantal goede tips staan voor het maken van commits waaruit je patches kunt indienen - je kunt het lezen in de Git broncode in het `Documentation/SubmittingPatches` bestand.
 
-Als eerste wil je geen witruimte fouten indienen. Git geeft je een eenvoudige manier om hierop te controleren – voordat je commit, voer `git diff --check` uit, wat mogelijke witruimte fouten identificeert en ze voor je afdrukt. Hier is een voorbeeld, waarbij ik een rode terminal kleur hebt vervangen door `X`en:
+Als eerste wil je geen witruimte fouten indienen. Git geeft je een eenvoudige manier om hierop te controleren - voordat je commit, voer `git diff --check` uit, wat mogelijke witruimte fouten identificeert en ze voor je afdrukt. Hier is een voorbeeld, waarbij ik een rode terminal kleur hebt vervangen door `X`en:
 
 	$ git diff --check
 	lib/simplegit.rb:5: trailing whitespace.
@@ -80,39 +80,40 @@ Als eerste wil je geen witruimte fouten indienen. Git geeft je een eenvoudige ma
 	lib/simplegit.rb:26: trailing whitespace.
 	+    def command(git_cmd)XXXX
 
-Als je dat commando uitvoert alvorens te committen, kun je al zien of je op het punt staat witruimte problemen te committen die andere ontwikkelaars boos kunnen maken.
+Als je dat commando uitvoert alvorens te committen, kun je al zien of je op het punt staat witruimte problemen te committen die waaraan andere ontwikkelaars zich zullen ergeren.
 
-Daarna, probeer om iedere van commit een logische set wijzigingen te maken. Probeer, als het je lukt, om je wijzigingen verteerbaar te maken – ga niet het hele weekend zitten coderen op vijf verschillende problemen om dat vervolgens op maandag als een gigantische commit in te dienen. Zelfs als je gedurende het weekend niet commit, gebruik dan het staging gebied op maandag om je werk in ten minste één commit per probleem op te splitsen, met een bruikbaar bericht per commit. Als een paar van de wijzigingen één bestand veranderen, probeer dan `git add --patch` te gebruiken om bestanden gedeeltelijk te stagen (wordt in detail behandeld in Hoofdstuk 6). Het snapshot van het project is gelijk of je nu één commit doet of vijf, zolang alle wijzigingen maar toegevoegd zijn op een bepaald punt, dus probeer om het je mede-ontwikkelaars makkelijk te maken als ze je wijzigingen moeten bekijken. Deze aanpak maakt het ook makkelijker om één wijziging op te halen of terug te draaien, mocht dat later nodig zijn. Hoofdstuk 6 beschrijft een aantal handige Git trucs om geschiedenis te herschrijven en bestanden interactief te stagen – gebruik deze applicaties om te helpen een schone en begrijpelijke historie op te bouwen.
+Probeer vervolgens om van elke commit een logische set wijzigingen te maken. Probeer, als het je lukt, om je wijzigingen verteerbaar te maken - ga niet het hele weekend zitten coderen op vijf verschillende problemen om dat vervolgens op maandag als een gigantische commit in te dienen. Zelfs als je gedurende het weekend niet commit, gebruik dan het staging gebied op maandag om je werk in ten minste ��n commit per probleem op te splitsen, met een bruikbaar bericht per commit. Als een paar van de wijzigingen ��n bestand veranderen, probeer dan `git add --patch` te gebruiken om bestanden gedeeltelijk te stagen (wordt in detail behandeld in Hoofdstuk 6). De laatste snapshot van het project is gelijk of je nu ��n commit doet of vijf, zolang alle wijzigingen op een gegeven momment maar toegevoegd zijn, dus probeer om het je mede-ontwikkelaars makkelijk te maken als ze je wijzigingen moeten bekijken. Deze aanpak maakt het ook makkelijker om ��n wijziging te pullen of terug te draaien, mocht dat later nodig zijn. Hoofdstuk 6 beschrijft een aantal handige Git trucs om geschiedenis te herschrijven en bestanden interactief te stagen - gebruik deze gereedschappen een schone en begrijpelijke historie te helpen op te bouwen.
 
-Het laatste ding om in gedachten te houden is het commit bericht. Als je er een gewoonte van maakt om een goede kwaliteit commit berichten aan te maken, dan maakt dat het gebruik van en samenwerken in Git een stuk eenvoudiger. Als een algemene regel, zouden je berichten moeten beginnen met een enkele regel, die niet langer is dan 50 karakters en die de set wijzigingen beknopt omschrijft, gevolgd door een lege regel. Daarna volgt de meer gedetailleerde uitleg. Het Git project vereist dat de meer gedetailleerde omschrijving ook je motivatie voor de verandering bevat, en de nieuwe implementatie tegen het oude gedrag afzet – dit is een goede richtlijn om te volgen. Het is ook een goed idee om de gebiedende wijs te gebruiken in deze berichten. Met andere woorden, gebruik commando's. In plaats van "Ik heb testen toegevoegd voor" of "Testen toegevoegd voor" gebruik je "Voeg testen toe voor".
+Het laatste om in gedachten te houden is het commit bericht. Als je er een gewoonte van maakt om een goede kwaliteit commit berichten aan te maken, dan maakt dat het gebruik van en samenwerken in Git een stuk eenvoudiger. In het algemeen, zouden je berichten moeten beginnen met een enkele regel, die niet langer is dan 50 karakters en die de wijzigingen beknopt omschrijft, gevolgd door een lege regel en daarna een meer gedetailleerde uitleg. Het Git project vereist dat de meer gedetailleerde omschrijving ook je motivatie voor de verandering bevat, en de nieuwe implementatie tegen het oude gedrag afzet. Dit is een goede richtlijn om te volgen. Het is ook een goed idee om de gebiedende wijs te gebruiken in deze berichten. Met andere woorden, gebruik commando's. In plaats van "Ik heb testen toegevoegd voor" of "Testen toegevoegd voor" gebruik je "Voeg testen toe voor".
 Hier is een sjabloon dat origineel geschreven is door Tim Pope op tpope.net:
 
 	Kort (50 karakters of minder) samenvatting van wijzigingen
 
-	Gedetailleerdere tekst uitleg, als nodig. Laat het in ongeveer 72
-	karakters afbreken. In sommige contexten, wordt de eerste regel
-	behandeld als het onderwerp van een email en de rest als inhoud.
-	De lege regel die de samenvatting scheidt van de inhoud is van
-	kritiek belang (tenzij je de inhoud helemaal weglaat); applicaties
-	zoals rebase kunnen in de war raken als je ze samenvoegt.
+	Gedetailleerdere beschrijvende tekst, indien nodig. Laat het na 
+	ongeveer 72 karakters afbreken. In sommige contexten, wordt de 
+	eerste regel behandeld als het onderwerp van een email en de rest
+	als inhoud. De lege regel die de samenvatting scheidt van de 
+	inhoud is essentieel (tenzij je de inhoud helemaal weglaat); 
+	applicaties zoals rebase kunnen in de war raken als je ze 
+	samenvoegt.
 
 	Vervolg paragrafen komen na lege regels.
 
 	 - Aandachtspunten zijn ook goed.
 
-	 - Typisch wordt een streepje of sterretje gebruikt als punt, voorafgegaan
-	   door een enkele spatie, met ertussen lege regels, maar de conventies
-	   variëren hierin.
+	 - Typisch wordt een streepje of sterretje gebruikt als "bullet",
+	   voorafgegaan door een enkele spatie, met ertussen lege regels,
+	   maar de conventies vari�ren hierin.
 
-Als al je commit berichten er zo uit zien, dan zullen de dingen een stuk eenvoudiger zijn voor jou en de ontwikkelaars waar je mee werkt. Het Git project heeft goed geformatteerde commit berichten – ik raad je aan om `git log --no-merges` uit te voeren om te zien hoe een goed geformatteerde project-commit historie eruit ziet.
+Als al je commit berichten er zo uit zien, dan zullen de dingen een stuk eenvoudiger zijn voor jou en de ontwikkelaars waar je mee samenwerkt. Het Git project heeft goed geformatteerde commit berichten - ik raad je aan om `git log --no-merges` uit te voeren om te zien hoe een goed geformatteerde project-commit historie eruit ziet.
 
 In de volgende voorbeelden, en verder door de rest van dit boek, zal ik omwille van bondigheid de berichten niet zo netjes als dit formatteren; in plaats daarvan gebruik ik de `-m` optie voor `git commit`. Doe wat ik zeg, niet wat ik doe.
 
 ### Besloten klein team ###
 
-De eenvoudigste opzet die je waarschijnlijk zult tegenkomen is een besloten project met één of twee andere ontwikkelaars. Met besloten bedoel ik gesloten broncode – zonder leestoegang voor de buitenwereld. Jij en de andere ontwikkelaars hebben allemaal terugzet toegang op het repository.
+De eenvoudigste opzet die je waarschijnlijk zult tegenkomen is een besloten project met ��n of twee andere ontwikkelaars. Met besloten bedoel ik gesloten broncode - zonder leestoegang voor de buitenwereld. Jij en de andere ontwikkelaars hebben allemaal push toegang op het repository.
 
-In deze omgeving kun je een werkwijze aanhouden die vergelijkbaar is met wat je zou doen als je Subversion of een andere gecentraliseerd systeem zou gebruiken. Je hebt nog steeds de voordelen van zaken als offline committen en veel eenvoudiger branchen en samenvoegen, maar de werkwijze kan erg vergelijkbaar zijn; het grote verschil is dat het samenvoegen aan de client-kant gebeurt tijdens het committen in plaats van aan de server-kant.
+In deze omgeving kun je een werkwijze aanhouden die vergelijkbaar is met wat je zou doen als je Subversion of een andere gecentraliseerd systeem zou gebruiken. Je hebt nog steeds de voordelen van zaken als offline committen en veel eenvoudiger branchen en mergen, maar de werkwijze kan erg vergelijkbaar zijn. Het grote verschil is dat het mergen aan de client-kant gebeurt tijdens het committen in plaats van aan de server-kant.
 Laten we eens kijken hoe het er uit zou kunnen zien als twee ontwikkelaars samen beginnen te werken met een gedeelde repository. De eerste ontwikkelaar, John, kloont de repository, maakt een wijziging, en commit lokaal. (Ik vervang de protocol berichten met `...` in deze voorbeelden om ze iets in te korten.)
 
 	# John's Machine
@@ -125,7 +126,7 @@ Laten we eens kijken hoe het er uit zou kunnen zien als twee ontwikkelaars samen
 	[master 738ee87] removed invalid default value
 	 1 files changed, 1 insertions(+), 1 deletions(-)
 
-De tweede ontwikkelaar, Jessica, doet hetzelfde – kloont de repository en commit een wijziging:
+De tweede ontwikkelaar, Jessica, doet hetzelfde - kloont de repository en commit een wijziging:
 
 	# Jessica's Machine
 	$ git clone jessica@githost:simplegit.git
@@ -137,7 +138,7 @@ De tweede ontwikkelaar, Jessica, doet hetzelfde – kloont de repository en comm
 	[master fbff5bc] add reset task
 	 1 files changed, 1 insertions(+), 0 deletions(-)
 
-Nu zet Jessica haar werk terug op de server:
+Nu pushed Jessica haar werk naar de server:
 
 	# Jessica's Machine
 	$ git push origin master
@@ -145,7 +146,7 @@ Nu zet Jessica haar werk terug op de server:
 	To jessica@githost:simplegit.git
 	   1edee6b..fbff5bc  master -> master
 
-John probeert ook zijn werk terug te zetten:
+John probeert ook zijn werk te pushen:
 
 	# John's Machine
 	$ git push origin master
@@ -153,31 +154,31 @@ John probeert ook zijn werk terug te zetten:
 	 ! [rejected]        master -> master (non-fast forward)
 	error: failed to push some refs to 'john@githost:simplegit.git'
 
-John mag niet terugzetten omdat Jessica in de tussentijd teruggezet heeft. Dit is in het bijzonder belangrijk om te begrijpen als je gewoon bent aan Subversion, omdat het je zal opvallen dat de twee ontwikkelaars niet hetzelfde bestand hebben aangepast. Alhoewel Subversion automatisch zo'n samenvoeging op de server doet, als verschillende bestanden zijn aangepast, moet je in Git de commits lokaal samenvoegen. John moet Jessica's wijzigingen ophalen en ze samenvoegen voor hij terug mag zetten:
+John mag niet terugzetten omdat Jessica in de tussentijd gepushed heeft. Dit is belangrijk om te begrijpen als je gewoon bent aan Subversion, omdat het je zal opvallen dat de twee ontwikkelaars niet hetzelfde bestand hebben aangepast. Waar Subversion automatisch zo'n merge op de server doet, als verschillende bestanden zijn aangepast, moet je in Git de commits lokaal mergen. John moet Jessica's wijzigingen ophalen (fetch) en ze mergen voor hij mag pushen:
 
 	$ git fetch origin
 	...
 	From john@githost:simplegit
 	 + 049d078...fbff5bc master     -> origin/master
 
-Op dit punt ziet John's lokale repository er ongeveer uit zoals Figuur 5-4.
+Hierna ziet John's lokale repository er ongeveer uit zoals Figuur 5-4.
 
 Insert 18333fig0504.png
-Figuur 5-4. John’s initiële repository.
+Figuur 5-4. John's initi�le repository.
 
-John heeft een referentie naar de wijzigingen die Jessica teruggezet heeft, maar hij moet ze samenvoegen met zijn eigen werk voordat hij het terug mag zetten:
+John heeft een referentie naar de wijzigingen die Jessica gepushed heeft, maar hij moet ze mergen met zijn eigen werk voordat hij het mag pushen:
 
 	$ git merge origin/master
 	Merge made by recursive.
 	 TODO |    1 +
 	 1 files changed, 1 insertions(+), 0 deletions(-)
 
-Het samenvoegen gaat soepel – de commit historie van John ziet er nu uit als Figuur 5-5.
+Het samenvoegen gaat soepeltjes - de commit historie van John ziet er nu uit als Figuur 5-5.
 
 Insert 18333fig0505.png
-Figuur 5-5. John’s repository na het samenvoegen van origin/master.
+Figuur 5-5. John's repository na het samenvoegen van origin/master.
 
-Nu kan John zijn code testen om er zeker van te zijn dat het nog steeds goed werkt, en dan kan hij zijn nieuwe samengevoegde werk terugzetten op de server:
+Nu kan John zijn code testen om er zeker van te zijn dat het nog steeds goed werkt, en dan kan hij zijn nieuwe samengevoegde werk pushen naar de server:
 
 	$ git push origin master
 	...
@@ -187,12 +188,12 @@ Nu kan John zijn code testen om er zeker van te zijn dat het nog steeds goed wer
 Tenslotte ziet John's commit historie eruit als Figuur 5-6.
 
 Insert 18333fig0506.png
-Figuur 5-6. John’s historie na teruggezet te hebben op de origin van de server.
+Figuur 5-6. John's historie na gepushed te hebben naar de origin van de server.
 
-In de tussentijd heeft Jessica gewerkt op een onderwerp branch. Ze heeft een onderwerp branch genaamd `issue54` aangemaakt en daar drie commits op gedaan. Ze heeft John's wijzigingen nog niet opgehaald, dus haar commit historie ziet er uit als Figuur 5-7.
+In de tussentijd heeft Jessica gewerkt op een topic branch. Ze heeft een topic branch genaamd `issue54` aangemaakt en daar drie commits op gedaan. Ze heeft John's wijzigingen nog niet opgehaald, dus haar commit historie ziet er uit als Figuur 5-7.
 
 Insert 18333fig0507.png
-Figuur 5-7. Jessica’s initiële commit historie.
+Figuur 5-7. Jessica's initi�le commit historie.
 
 Jessica wil met John synchroniseren, dus ze haalt de wijzigingen op:
 
@@ -202,12 +203,12 @@ Jessica wil met John synchroniseren, dus ze haalt de wijzigingen op:
 	From jessica@githost:simplegit
 	   fbff5bc..72bbc59  master     -> origin/master
 
-Dit haalt het werk op dat John in de tussentijd teruggezet heeft. Jessica's historie ziet er nu uit als Figuur 5-8.
+Dit haalt het werk op dat John in de tussentijd gepushed heeft. Jessica's historie ziet er nu uit als Figuur 5-8.
 
 Insert 18333fig0508.png
-Figuur 5-8. Jessica’s historie na het ophalen van John's wijzigingen.
+Figuur 5-8. Jessica's historie na het ophalen van John's wijzigingen.
 
-Jessica denkt dat haar onderwerp branch nu klaar is, maar ze wil weten wat ze in haar werk moet samenvoegen zodat ze terug kan zetten. Ze voert `git log` uit om dat uit te zoeken:
+Jessica denkt dat haar topic branch nu klaar is, maar ze wil weten wat ze in haar werk moet mergen zodat ze kan pushen. Ze voert `git log` uit om dat uit te zoeken:
 
 	$ git log --no-merges origin/master ^issue54
 	commit 738ee872852dfaa9d6634e0dea7a324040193016
@@ -216,13 +217,13 @@ Jessica denkt dat haar onderwerp branch nu klaar is, maar ze wil weten wat ze in
 
 	    removed invalid default value
 
-Nu kan Jessica het werk van haar onderwerp samenvoegen in haar master branch, John's werk (`origin/master`) in haar `master` branch samenvoegen, en dat naar de server terugzetten. Eerst schakelt ze terug naar haar master branch om al dit werk te integreren:
+Nu kan Jessica het werk van haar onderwerp mergen in haar `master` branch, John's werk (`origin/master`) in haar `master` branch mergen, en dan naar de server pushen. Eerst schakelt ze terug naar haar `master` branch om al dit werk te integreren:
 
 	$ git checkout master
 	Switched to branch "master"
 	Your branch is behind 'origin/master' by 2 commits, and can be fast-forwarded.
 
-Ze kan of `origin/master` of `issue54` als eerste samenvoegen – ze zijn beide stroomopwaarts dus de volgorde maakt niet uit. De snapshot aan het einde zou gelijk moeten zijn ongeacht welke volgorde ze kiest; alleen de geschiedenis zal iets verschillen. Ze kiest ervoor om `issue54` eerst samen te voegen:
+Ze kan of `origin/master` of `issue54` als eerste samenvoegen - ze zijn beide stroomopwaarts dus de volgorde maakt niet uit. Op het eind zou de snapshot gelijk moeten zijn ongeacht welke volgorde ze kiest; alleen de geschiedenis zal iets verschillen. Ze kiest ervoor om `issue54` eerst samen te voegen:
 
 	$ git merge issue54
 	Updating fbff5bc..4af4298
@@ -231,7 +232,7 @@ Ze kan of `origin/master` of `issue54` als eerste samenvoegen – ze zijn beide
 	 lib/simplegit.rb |    6 +++++-
 	 2 files changed, 6 insertions(+), 1 deletions(-)
 
-Er doen zich geen problemen voor; zoals je kunt zien was het een eenvoudige fast-forward. Nu voegt Jessica John's werk in (`origin/master`):
+Er doen zich geen problemen voor, zoals je kunt zien was het een eenvoudige fast-forward. Nu merged Jessica John's werk (`origin/master`):
 
 	$ git merge origin/master
 	Auto-merging lib/simplegit.rb
@@ -239,35 +240,35 @@ Er doen zich geen problemen voor; zoals je kunt zien was het een eenvoudige fast
 	 lib/simplegit.rb |    2 +-
 	 1 files changed, 1 insertions(+), 1 deletions(-)
 
-Alles voegt netjes samen, en Jessica's historie ziet er uit als Figuur 5-9.
+Alles merged netjes, en Jessica's historie ziet er uit als Figuur 5-9.
 
 Insert 18333fig0509.png
-Figuur 5-9. Jessica’s historie na het samenvoegen van John’s wijzigingen.
+Figuur 5-9. Jessica's historie na het mergen van John's wijzigingen.
 
-Nu is `origin/master` bereikbaar vanuit Jessica's `master` branch, dus ze zou in staat moeten zijn om succesvol terug te kunnen zetten (er vanuit gegaan dat John in de tussentijd niets teruggezet heeft):
+Nu is `origin/master` bereikbaar vanuit Jessica's `master` branch, dus ze zou in staat moeten zijn om succesvol te pushen (even aangenomen dat John in de tussentijd niets gepushed heeft):
 
 	$ git push origin master
 	...
 	To jessica@githost:simplegit.git
 	   72bbc59..8059c15  master -> master
 
-Iedere ontwikkelaar heeft een paar keer gecommit en elkaars werk succesvol samengevoegd; zie Figuur 5-10.
+Iedere ontwikkelaar heeft een paar keer gecommit en elkaars werk succesvol samengevoegd, zie Figuur 5-10.
 
 Insert 18333fig0510.png
-Figuur 5-10. Jessica’s historie na alle wijzigingen teruggezet te hebben op de server.
+Figuur 5-10. Jessica's historie na alle wijzigingen teruggezet te hebben op de server.
 
-Dat is één van de eenvoudigste werkwijzen. Je werkt een tijdje, over het algemeen in een onderwerp branch, en voegt samen in je master branch als het klaar is om te worden geïntegreerd. Als je dat werk wilt delen, dan voeg je het samen in je eigen master branch, en vervolgens haal je `origin/master` op en voegt het samen als het gewijzigd is, en als laatste zet je terug op de `master` branch op de server. De algemene volgorde is zoiets als die getoond in Figuur 5-11.
+Dit is ��n van de eenvoudigste werkwijzen. Je werkt een tijdje, over het algemeen in een topic branch, en merged in je `master` branch als het klaar is om te worden ge�ntegreerd. Als je dat werk wilt delen, dan merge je het in je eigen `master` branch, en vervolgens fetch je `origin/master` en merge je deze als het gewijzigd is, en als laatste push je deze naar de `master` branch op de server. De algemene volgorde is zoiets als die getoond in Figuur 5-11.
 
 Insert 18333fig0511.png
 Figuur 5-11. Algemene volgorde van gebeurtenissen voor een eenvoudige multi-ontwikkelaar Git werkwijze.
 
 ### Besloten aangestuurd team ###
 
-In het volgende scenario zul je kijken naar de rol van de bijdragers in een grotere besloten groep. Je zult leren hoe te werken in een omgeving waar kleine groepen samenwerken aan functies, waarna die team-gebaseerde bijdragen worden geïntegreerd door een andere partij.
+In het volgende scenario zul je kijken naar de rol van de bijdragers in een grotere besloten groep. Je zult leren hoe te werken in een omgeving waar kleine groepen samenwerken aan functies, waarna die team-gebaseerde bijdragen worden ge�ntegreerd door een andere partij.
 
-Stel dat John en Jessica samen werken aan een functie, terwijl Jessica en Josie aan een tweede aan het werken zijn. In dit geval gebruikt het bedrijf een integratie-manager achtige werkwijze, waarbij het werk van de individuele groepen alleen wordt geïntegreerd door bepaalde ingenieurs, en de `master` branch van het hoofd repo alleen kan worden vernieuwd door die ingenieurs. In dit scenario, wordt al het werk gedaan in team-gebaseerde branches en later door de integrators samengevoegd.
+Stel dat John en Jessica samen werken aan een functie, terwijl Jessica en Josie aan een tweede aan het werken zijn. In dit geval gebruikt het bedrijf een integratie-manager achtige werkwijze, waarbij het werk van de individuele groepen alleen wordt ge�ntegreerd door bepaalde ontwikkelaars, en de `master` branch van het hoofd repo alleen kan worden vernieuwd door die ontwikkelaars. In dit scenario wordt al het werk gedaan in team-gebaseerde branches en later door de integrators samengevoegd.
 
-Laten we Jessica's werkwijze volgen terwijl ze aan haar twee functies werkt, in parallel met twee verschillend ontwikkelaars in deze omgeving. Aangenomen dat ze haar repository al gekloond heeft, besluit ze als eerste te werken aan `featureA`. Ze maakt een nieuwe branch aan voor de functie en doet daar wat werk:
+Laten we Jessica's werkwijze volgen terwijl ze aan haar twee functies werkt, in parallel met twee verschillende ontwikkelaars in deze omgeving. We nemen even aand dat ze haar repository al gekloond heeft, en dat ze besloten heeft als eerste te werken aan `featureA`. Ze maakt een nieuwe branch aan voor de functie en doet daar wat werk:
 
 	# Jessica's Machine
 	$ git checkout -b featureA
@@ -277,14 +278,14 @@ Laten we Jessica's werkwijze volgen terwijl ze aan haar twee functies werkt, in
 	[featureA 3300904] add limit to log function
 	 1 files changed, 1 insertions(+), 1 deletions(-)
 
-Op dit punt, moet ze haar werk delen met John, dus ze zet haar commits op de `featureA` branch terug naar de server. Jessica heeft geen terugzet toegang op de `master` branch – alleen de integratoren hebben dat – dus ze moet naar een andere branch terugzetten om samen te kunnen werken met John:
+Op dit punt, moet ze haar werk delen met John, dus ze pushed haar commits naar de `featureA` branch op de server. Jessica heeft geen push toegang op de `master` branch - alleen de integratoren hebben dat - dus ze moet naar een andere branch pushen om samen te kunnen werken met John:
 
 	$ git push origin featureA
 	...
 	To jessica@githost:simplegit.git
 	 * [new branch]      featureA -> featureA
 
-Jessica e-mailt John om hem te zeggen dat ze wat werk teruggezet heeft in een branch genaamd `featureA` en dat hij er nu naar kan kijken. Terwijl ze op terugkoppeling van John wacht, besluit Jessica te beginnen met het werken aan `featureB` met Josie. Om te beginnen start ze een nieuwe functie branch, gebaseerd op de `master` branch van de server:
+Jessica mailt John om hem te zeggen dat ze wat werk gepushed heeft in een branch genaamd `featureA` en dat hij er nu naar kan kijken. Terwijl ze op terugkoppeling van John wacht, besluit Jessica te beginnen met het werken aan `featureB` met Josie. Om te beginnen start ze een nieuwe functie branch, gebaseerd op de `master` branch van de server:
 
 	# Jessica's Machine
 	$ git fetch origin
@@ -305,16 +306,16 @@ Nu doet Jessica een paar commits op de `featureB` branch:
 Jessica's repository ziet eruit als Figuur 5-12.
 
 Insert 18333fig0512.png
-Figuur 5-12. Jessica’s initiële commit historie.
+Figuur 5-12. Jessica's initi�le commit historie.
 
-Ze is klaar om haar werk terug te zetten, maar ze krijgt een e-mail van Josie dat een branch met wat initieel werk erin al teruggezet is naar de server als `featureBee`. Jessica moet die wijzigingen eerst samenvoegen met haar eigen voordat ze terug kan zetten naar de server. Ze kan dan Josie's wijzigingen ophalen met `git fetch`:
+Ze is klaar om haar werk te pushen, maar ze krijgt een mail van Josie dat een branch met wat initieel werk erin al gepushed is naar de server in de `featureBee` branch. Jessica moet die wijzigingen eerst mergen met die van haar voordat ze kan pushen naar de server. Ze kan dan Josie's wijzigingen ophalen met `git fetch`:
 
 	$ git fetch origin
 	...
 	From jessica@githost:simplegit
 	 * [new branch]      featureBee -> origin/featureBee
 
-Jessica kan dit nu samenvoegen in haar werk met `git merge`:
+Jessica kan dit nu mergen in het werk wat zij gedaan heeft met `git merge`:
 
 	$ git merge origin/featureBee
 	Auto-merging lib/simplegit.rb
@@ -322,16 +323,16 @@ Jessica kan dit nu samenvoegen in haar werk met `git merge`:
 	 lib/simplegit.rb |    4 ++++
 	 1 files changed, 4 insertions(+), 0 deletions(-)
 
-Er is wel een klein probleem – ze moet het samengevoegde werk in haar `featureB` branch naar de `featureBee` branch op de server zetten. Ze kan dat doen door de lokale branch te specificeren aan het `git push` commando, gevolgd door een dubbele punt (:), gevolgd door de remote branch:
+Er is wel een klein probleempje - ze moet het gemergde werk in haar `featureB` branch naar de `featureBee` branch op de server zetten. Ze kan dat doen door de lokale branch te specificeren aan het `git push` commando, gevolgd door een dubbele punt (:), gevolgd door de remote branch:
 
 	$ git push origin featureB:featureBee
 	...
 	To jessica@githost:simplegit.git
 	   fba9af8..cd685d1  featureB -> featureBee
 
-Dit wordt een _refspec_ genoemd. Zie Hoofdstuk 9 voor een gedetailleerdere discussie van Git refspecs en de verschillende dingen die je met ze kan doen.
+Dit wordt een _refspec_ genoemd. Zie Hoofdstuk 9 voor een gedetailleerdere behandeling van Git refspecs en de verschillende dingen die je daarmee kan doen.
 
-Vervolgens e-mailt John naar Jessica om te zeggen dat hij wat wijzigingen naar de `featureA` branch teruggezet heeft, en om haar te vragen die te verifiëren. Ze voert een `git fetch` uit om die wijzigingen op te halen:
+Vervolgens mailt John naar Jessica om te zeggen dat hij wat wijzigingen naar de `featureA` branch gepushed heeft, en om haar te vragen die te verifi�ren. Ze voert een `git fetch` uit om die wijzigingen op te halen:
 
 	$ git fetch origin
 	...
@@ -347,7 +348,7 @@ Daarna kan ze zien wat er veranderd is met `git log`:
 
 	    changed log output to 30 from 25
 
-Uiteindelijk voegt ze John's werk in haar eigen `featureA` branch:
+Uiteindelijk merged ze John's werk in haar eigen `featureA` branch:
 
 	$ git checkout featureA
 	Switched to branch "featureA"
@@ -357,7 +358,7 @@ Uiteindelijk voegt ze John's werk in haar eigen `featureA` branch:
 	 lib/simplegit.rb |   10 +++++++++-
 	1 files changed, 9 insertions(+), 1 deletions(-)
 
-Jessica wil iets fijnstellen, dus doet ze nog een commit en zet dit terug naar de server:
+Jessica wil iets kleins wijzigen, dus doet ze nog een commit en pushed dit naar de server:
 
 	$ git commit -am 'small tweak'
 	[featureA ed774b3] small tweak
@@ -370,24 +371,24 @@ Jessica wil iets fijnstellen, dus doet ze nog een commit en zet dit terug naar d
 Jessica's commit historie ziet er nu uit zoals Figuur 5-13.
 
 Insert 18333fig0513.png
-Figuur 5-13. Jessica’s historie na het committen op een functie branch.
+Figuur 5-13. Jessica's historie na het committen op een functie branch.
 
-Jessica, Josie en John informeren de integrators nu dat de `featureA` en `featureBee` branches op de server klaar zijn voor integratie in de hoofdlijn. Nadat ze die branches in de hoofdlijn geïntegreerd hebben, zal een fetch de nieuwe samenvoeg commits ophalen, waardoor de commit historie er uit ziet zoals Figuur 5-14.
+Jessica, Josie en John informeren de integrators nu dat de `featureA` en `featureBee` branches op de server klaar zijn voor integratie in de hoofdlijn. Nadat zij die branches in de hoofdlijn ge�ntegreerd hebben, zal een fetch de nieuwe merge commits ophalen, waardoor de commit historie er uit ziet zoals Figuur 5-14.
 
 
 Insert 18333fig0514.png
-Figuur 5-14. Jessica’s historie na het samenvoegen van allebei haar onderwerp branches.
+Figuur 5-14. Jessica's historie na het samenvoegen van allebei haar onderwerp branches.
 
-Veel groepen schakelen om naar Git voor deze mogelijkheid om meerdere teams in parallel te kunnen laten werken, waarbij de verschillende lijnen van werk laat in het proces samengevoegd worden. De mogelijkheid van kleinere subgroepen of een team om samen te werken via remote branches zonder het betrekken of dwarsliggen van het hele team is een enorm voordeel van Git. De volgorde van de werkwijze die je hier zag is ongeveer zoals Figuur 5-15.
+Veel groepen schakelen om naar Git juist vanwege de mogelijkheid om meerdere teams in parallel te kunnen laten werken, waarbij de verschillende lijnen van werk laat in het proces gemerged worden. De mogelijkheid van kleinere subgroepen of een team om samen te werken via remote branches zonder het hele team erin te betrekken of te hinderen is een enorm voordeel van Git. De volgorde van de werkwijze die je hier zag is ongeveer zoals Figuur 5-15.
 
 Insert 18333fig0515.png
-Figuur 5-15. Basale volgorde van de werkwijze van dit aangestuurde team.
+Figuur 5-15. Eenvoudige volgorde in de werkwijze van dit aangestuurde team.
 
-### Klein publiek project ###
+### Klein openbaar project ###
 
-Het bijdragen aan publieke projecten gaat wat anders. Omdat je niet de toestemming hebt om de branches van het project te vernieuwen, moet je het werk op een andere manier naar de beheerders krijgen. Dit eerste voorbeeld beschrijft het bijdragen via afsplitsen op Git hosts die eenvoudig afsplitsen ondersteunen. De repo.or.cz en GitHub hosting sites ondersteunen dit allebei, en veel project beheerders verwachten deze soort bijdrage. Het volgende deel behandelt projecten die de voorkeur hebben aan bijgedragen patches via e-mail.
+Het bijdragen aan openbare, of publieke, projecten gaat op een iets andere manier. Omdat je niet de toestemming hebt om de branches van het project te updaten, moet je het werk op een andere manier naar de beheerders krijgen. Dit eerste voorbeeld beschrijft het bijdragen via afsplitsen (forken) op Git hosts, die het makkelijk maken om te forken. De repo.or.cz en GitHub hosting sites ondersteunen dit beiden, en veel project beheerders verwachten deze manier van bijdragen. De volgende paragraaf behandelt projecten die de voorkeur hebben om bijdragen in de vorm van patches via e-mail te ontvangen.
 
-Eerst wil je waarschijnlijk het hoofdrepository klonen, een onderwerp branch maken voor de patch of patch serie die je van plan bent bij te dragen, en je werk daarop doen. De volgorde ziet er in basis zo uit:
+Eerst zal je waarschijnlijk de hoofdrepository klonen, een topic branch maken voor de patch of reeks patches die je van plan bent bij te dragen, en je werk daarop doen. De werkwijze ziet er zo uit:
 
 	$ git clone (url)
 	$ cd project
@@ -397,19 +398,19 @@ Eerst wil je waarschijnlijk het hoofdrepository klonen, een onderwerp branch mak
 	$ (work)
 	$ git commit
 
-Je wil misschien de `rebase -i` optie gebruiken om je werk in één enkele commit samen te persen, of het werk in de commits herschikken om de patch eenvoudiger te kunnen laten reviewen door de beheerders – zie Hoofdstuk 6 voor meer informatie over het interactief rebasen.
+Je wil misschien de `rebase -i` optie gebruiken om je werk in ��n enkele commit samen te persen (squash), of het werk in de commits herschikken om de patch eenvoudiger te kunnen laten reviewen door de beheerders - zie Hoofdstuk 6 voor meer informatie over het interactief rebasen.
 
-Als je werk op de branch af is, en je klaar bent om het bij te dragen aan de beheerders, ga dan naar de originele project pagina en klik op de "Fork" knop, waarmee je een eigen schrijfbare fork van het project maakt. Je moet dit dan in een nieuwe repository URL toevoegen als een tweede remote, in dit geval `myfork` genaamd:
+Als je werk op de branch af is, en je klaar bent om het over te dragen aan de beheerders, ga je naar de originele project pagina en klik op de "Fork" knop, hiermee maak je een eigen schrijfbare fork van het project. Je moet dit dan in een nieuwe repository URL toevoegen als een tweede remote, in dit geval `myfork` genaamd:
 
 	$ git remote add myfork (url)
 
-Je moet je werk hier naar terugzetten. Het is het makkelijkst om de remote branch waar je op zit te werken terug te zetten naar je repository, in plaats van het samenvoegen in je master branch en die terug te zetten. De reden is dat als het werk niet wordt geaccepteerd of ge-cherry picked, je je master branch niet hoeft terug te draaien. Als de beheerders je werk samenvoegen, rebasen of cherry picken, dan krijg je het uiteindelijk toch terug door hun repository binnen te halen:
+Je moet je werk hier naar pushen. Het is het makkelijkst om de remote branch waar je op zit te werken te pushen naar je repository, in plaats van het samenvoegen in je master branch en die terug te zetten. De reden hiervan is, dat als het werk niet wordt geaccepteerd of alleen ge-cherry picked, je jouw master branch niet hoeft terug te draaien. Als de beheerders je werk mergen, rebasen of cherry picken, dan krijg je het uiteindelijk toch terug door hun repository te pullen:
 
 	$ git push myfork featureA
 
-Als jouw werk teruggezet is naar je fork, dan moet je de beheerder waarschuwen. Dit wordt vaak een pull request (haal binnen verzoek) genoemd, en je kunt het of via de website genereren – GitHub heeft een "pull request" knop die de beheerder automatisch een bericht stuurt – of het `git request-pull` commando uitvoeren en de uitvoer handmatig naar de beheerder e-mailen.
+Als jouw werk gepushed is naar jouw fork, dan moet je de beheerder een seintje geven. Dit wordt vaak een pull request (haal-binnen-verzoek) genoemd, en je kunt het via de website genereren - GitHub heeft een "pull request" knop die de beheerder automatisch een bericht stuurt - of het `git request-pull` commando uitvoeren en de uitvoer handmatig naar de projectbeheerder mailen.
 
-Het `request-pull` commando accepteert de basis branch waarin je je onderwerp branch binnen gehaald wil hebben, en de URL van het Git repository waarvan je ze wil laten halen, en voert een samenvatting uit van alle wijzigingen die je binnengehaald wenst te hebben. Bijvoorbeeld, als Jessica John een pull request wil sturen, en ze heeft twee commits gedaan op de onderwerp branch die ze zojuist teruggezet heeft, dan kan ze dit uitvoeren:
+Het `request-pull` commando neemt de branch waarin je je topic branch gepulled wil hebben, en de URL van de Git repository waar je ze uit wil laten pullen, en maakt een samenvatting van alle wijzigingen die je gepulled wenst te hebben. Bijvoorbeeld, als Jessica John een pull request wil sturen, en ze heeft twee commits gedaan op de topic branch die ze zojuist gepushed heeft, dan kan ze dit uitvoeren:
 
 	$ git request-pull origin/master myfork
 	The following changes since commit 1edee6b1d61823a2de3b09c160d7080b8d1b3a40:
@@ -427,9 +428,9 @@ Het `request-pull` commando accepteert de basis branch waarin je je onderwerp br
 	 lib/simplegit.rb |   10 +++++++++-
 	 1 files changed, 9 insertions(+), 1 deletions(-)
 
-De uitvoer kan naar de beheerder gestuurd worden – het verteld ze waar het werk vanaf gebranched is, vat de commits samen, en verteld waar ze dit werk vandaan kunnen halen.
+De uitvoer kan naar de beheerder gestuurd worden: het verteld ze waar het werk vanaf gebranched is, vat de commits samen, en verteld waar vandaan ze dit werk kunnen pullen.
 
-Bij een project waarvan je niet de beheerder bent, is het over het algemeen eenvoudiger om een branch zoals `master` altijd de `origin/master` te laten volgen, en je werk te doen in onderwerp branches die je eenvoudig weg kunt gooien als ze geweigerd worden. Als je je werk thema's gescheiden hebt in onderwerp branches maakt dat het ook eenvoudiger voor jou om je werk te rebasen als de punt van het hoof repository in de tussentijd verschoven is en je commits niet langer netjes toegepast kunnen worden. Bijvoorbeeld, als je een tweede onderwerp wil bijdragen aan een project, ga dan niet verder werken op de onderwerp branch die je zojuist teruggezet hebt – begin opnieuw vanaf de `master` branch van het hoofd repository:
+Bij een project waarvan je niet de beheerder bent, is het over het algemeen eenvoudiger om een branch zoals `master` altijd de `origin/master` te laten volgen, en je werk te doen in topic branches die je eenvoudig weg kunt gooien als ze geweigerd worden. Als je je werkthema's gescheiden houdt in topic branches maakt dat het ook eenvoudiger voor jou om je werk te rebasen als de punt van het hoofd repository in de tussentijd verschoven is en je commits niet langer netjes toegepast kunnen worden. Bijvoorbeeld, als je een tweede onderwerp wil bijdragen aan een project, ga dan niet verder werken op de topic branch die je zojuist gepushed hebt - begin opnieuw vanaf de `master` branch van het hoofd repository:
 
 	$ git checkout -b featureB origin/master
 	$ (work)
@@ -438,25 +439,25 @@ Bij een project waarvan je niet de beheerder bent, is het over het algemeen eenv
 	$ (email maintainer)
 	$ git fetch origin
 
-Nu zijn al je onderwerpen opgeslagen in een silo – vergelijkbaar met een patch rij – die je kunt herschrijven, rebasen en wijzigen zonder dat de onderwerpen elkaar in de weg zitten of afhankelijk zijn zoals in Figuur 5-16.
+Nu zijn al je onderwerpen opgeslagen in een silo - vergelijkbaar met een patch rij - die je kunt herschrijven, rebasen en wijzigen zonder dat de onderwerpen elkaar be�nvloeden of van elkaar afhankelijk zijn zoals in Figuur 5-16.
 
 Insert 18333fig0516.png
-Figuur 5-16. Initiële commit historie met werk van featureB.
+Figuur 5-16. Initi�le commit historie met werk van featureB.
 
-Stel dat de project beheerder een berg andere patches binnengehaald heeft en je eerste branch geprobeerd heeft, maar dat die niet langer netjes samenvoegt. In dit geval kun je proberen die branch te rebasen op de punt van `origin/master`, de conflicten proberen op te lossen voor de beheerder, en dan je wijzigingen opnieuw aanbieden:
+Stel dat de project beheerder een berg andere patches binnengehaald heeft en je eerste branch geprobeerd heeft, maar dat die niet langer netjes merged. In dat geval kun je proberen die branch te rebasen op de punt van `origin/master`, de conflicten op te lossen voor de beheerder, en dan je wijzigingen opnieuw aanbieden:
 
 	$ git checkout featureA
 	$ git rebase origin/master
-	$ git push –f myfork featureA
+	$ git push -f myfork featureA
 
 Dit herschrijft je geschiedenis zodat die eruit ziet als in Figuur 5-17.
 
 Insert 18333fig0517.png
 Figuur 5-17. Commit historie na werk van featureA.
 
-Omdat je de branch gerebased hebt, moet je de `-f` specificeren met je push commando om in staat te zijn de `featureA` branch op de server te vervangen met een commit die er geen afstammeling van is. Een alternatief zou zijn dit nieuwe werk naar een andere branch op de server terug te zetten (misschien `featureAv2` genaamd).
+Omdat je de branch gerebased hebt, moet je de `-f` specificeren met je push commando om in staat te zijn de `featureA` branch op de server te vervangen met een commit die er geen afstammeling van is. Een alternatief zou zijn dit nieuwe werk naar een andere branch op de server te pushen (misschien `featureAv2` genaamd).
 
-Laten we eens kijken naar nog een mogelijk scenario: de beheerder heeft je werk bekeken in je tweede branch en vind het concept goed, maar zou willen dat je een implementatie detail veranderd. Je zult deze kans ook gebruiken om het werk dat gebaseerd is van de huidige `master` branch van het project af te halen. Je begint een nieuwe branch gebaseerd op de huidige `origin/master` branch, perst de `featureB` wijzigingen hier samen, lost conflicten op, doet de implementatie wijziging, en zet dat terug als een nieuwe branch:
+Laten we eens kijken naar nog een mogelijk scenario: de beheerder heeft je werk bekeken in je tweede branch en vind het concept goed, maar zou willen dat je een implementatie detail verandert. Je zult deze gelegenheid ook gebruiken om het werk te baeren op de huidige `master` branch van het project. Je begint een nieuwe branch gebaseerd op de huidige `origin/master` branch, squashed de `featureB` wijzigingen er naartoe, lost conflicten op, doet de implementatie wijziging, en zet dat terug als een nieuwe branch:
 
 	$ git checkout -b featureBv2 origin/master
 	$ git merge --no-commit --squash featureB
@@ -464,18 +465,18 @@ Laten we eens kijken naar nog een mogelijk scenario: de beheerder heeft je werk
 	$ git commit
 	$ git push myfork featureBv2
 
-De `--squash` optie pakt al het werk op de samengevoegde branch en perst dat samen in één non-merge commit bovenop de branch waar je op zit. De `--no-commit` optie verteld Git dat hij niet automatisch een commit moet vastleggen. Dit staat je toe om alle wijzigingen van een andere branch te introduceren en dan meer wijzigingen te doen, alvorens de commit vast te leggen.
+De `--squash` optie pakt al het werk op de gemergde branch en perst dat samen in ��n non-merge commit bovenop de branch waar je op zit. De `--no-commit` optie vertelt Git dat hij niet automatisch een commit moet doen. Dit stelt je in staat om alle wijzigingen van een andere branch te introduceren en dan meer wijzigingen te doen, alvorens de nieuwe commit te doen.
 
 Nu kun je de beheerder een bericht sturen dat je de gevraagde wijzigingen gemaakt hebt en dat ze die wijzigingen kunnen vinden in je `featureBv2` branch (zie Figuur 5-18).
 
 Insert 18333fig0518.png
 Figuur 5-18. Commit historie na het featureBv2 werk.
 
-### Publiek groot project ###
+### Openbaar groot project ###
 
-Veel grote projecten hebben procedures voor het accepteren van patches vastgelegd – je zult de specifieke regels voor ieder project moeten bekijken, omdat ze zullen verschillen. Maar, veel grote projecten accepteren patches via ontwikkelaar maillijsten, dus ik zal zo'n voorbeeld nu laten zien.
+Veel grote projecten hebben vastgestelde procedures voor het accepteren van patches - je zult de specifieke regels voor ieder project goed moeten bekijken, omdat ze zullen verschillen. Maar, veel grote projecten accepteren patches via ontwikkelaar maillijsten, dus ik zal zo'n voorbeeld nu laten zien.
 
-De werkwijze is vergelijkbaar met het vorige geval – je maakt onderwerp branches voor iedere patch waar je aan werkt. Het verschil is hoe je die indient bij het project. In plaats van het project te forken en naar je eigen schrijfbare versie terug te zetten, genereer je e-mail versies van iedere commit serie en e-mailt die naar de ontwikkelaar maillijst:
+De werkwijze is vergelijkbaar met het vorige geval - je maakt topic branches voor iedere patch waar je aan werkt. Het verschil is hoe je die aanlevert bij het project. In plaats van het project te forken en naar je eigen schrijfbare versie te pushen, genereer je e-mail versies van iedere commit serie en mailt die naar de ontwikkelaar maillijst:
 
 	$ git checkout -b topicA
 	$ (work)
@@ -483,13 +484,13 @@ De werkwijze is vergelijkbaar met het vorige geval – je maakt onderwerp branch
 	$ (work)
 	$ git commit
 
-Nu heb je twee commits die je wil sturen naar de maillijst. Je gebruikt `git format-patch` om de mbox-geformatteerde bestanden te genereren, die je kunt e-mailen naar de lijst – het vormt ieder commit om naar een e-mail bericht met de eerste regel van het commit bericht als de onderwerp regel, en de rest van het bericht plus de patch die de commit introduceert als de inhoud. Het fijne hieraan is dat het toepassen van een patch uit een e-mail die gegenereerd is met `format-patch` alle commit informatie goed behoudt, zoals je in het volgende gedeelte meer zult zien als je deze commits toepast:
+Nu heb je twee commits die je wil sturen naar de maillijst. Je gebruikt `git format-patch` om de mbox-geformatteerde bestanden te genereren, die je kunt e-mailen naar de lijst. Dit vormt iedere commit om naar een e-mail bericht met de eerste regel van het commit bericht als de onderwerp regel, en de rest van het bericht plus de patch die door de commit wordt ge�ntroduceerd als de inhoud. Het prettige hieraan is dat het toepassen van een patch uit een mail die gegenereerd is met `format-patch` alle commit informatie goed behoudt, zoals je in de volgende paragraaf meer zult zien als je deze commits toepast:
 
 	$ git format-patch -M origin/master
 	0001-add-limit-to-log-function.patch
 	0002-changed-log-output-to-30-from-25.patch
 
-Het `format-patch` commando voert de namen uit van de patch bestanden die het maakt. De `-M` optie verteld Git te kijken naar hernoemingen. De bestanden komen er uiteindelijk zo uit te zien:
+Het `format-patch` commando drukt de namen af van de patch bestanden die het maakt. De `-M` optie vertelt Git te kijken naar hernoemingen. De bestanden komen er uiteindelijk zo uit te zien:
 
 	$ cat 0001-add-limit-to-log-function.patch
 	From 330090432754092d704da8e76ca5c05c198e71a8 Mon Sep 17 00:00:00 2001
@@ -519,11 +520,11 @@ Het `format-patch` commando voert de namen uit van de patch bestanden die het ma
 	--
 	1.6.2.rc1.20.g8c5b.dirty
 
-Je kunt deze patch bestanden ook aanpassen om meer informatie voor de maillijst toe te voegen, die je niet in het commit bericht wil laten zien. Als je tekst toevoegt tussen de `---` regel en het begin van de patch (de `lib/simplegit.rb` regel), dan kunnen ontwikkelaars dit lezen; maar tijdens het toepassen van de patch wordt dit weggelaten.
+Je kunt deze patch bestanden ook aanpassen om meer informatie voor de maillijst toe te voegen, die je niet in het commit bericht wil laten verschijnen. Als je tekst toevoegt tussen de `---` regel en het begin van de patch (de `lib/simplegit.rb` regel), dan kunnen ontwikkelaars dit lezen, maar tijdens het toepassen van de patch wordt dit weggelaten.
 
-Om dit te e-mailen naar een maillijst, kun je het bestand in je e-mail applicatie plakken of het sturen via een commandoregel programma. Het plakken van de tekst veroorzaakt vaak formaat problemen, in het bijzonder bij "slimmere" clients die geen harde returns en andere witruimte juist behouden. Gelukkig levert Git een applicatie die je helpt om juist geformatteerde patches via IMAP te versturen, wat makkelijker voor je kan zijn. Ik zal demonstreren hoe je een patch via Gmail stuurt, wat de e-mail applicatie is die ik gebruik; je kunt gedetailleerde instructies voor een aantal mail programma's vinden aan het eind van het voornoemde `Documentation/SubmittingPatches` bestand in de Git broncode.
+Om dit te mailen naar een maillijst, kun je het bestand in je mail applicatie plakken of het sturen via een commandoregel programma. Het plakken van de tekst veroorzaakt vaak formaterings problemen, in het bijzonder bij "slimmere" clients die geen newlines en andere witruimte juist behouden. Gelukkig levert Git een gereedschap die je helpt om juist geformatteerde patches via IMAP te versturen, wat makkelijker voor je kan zijn. Ik zal zal je laten zien hoe je een patch via Gmail stuurt, wat de mail applicatie is die ik gebruik. Je kunt gedetailleerde instructies voor een aantal mail programma's vinden aan het eind van het voornoemde `Documentation/SubmittingPatches` bestand in de Git broncode.
 
-Eerst moet je de imap sectie in je `~/.gitconfig` bestand instellen. Je kunt iedere waarde apart instellen met een serie `git config` commando's, of je kunt ze handmatig toevoegen; maar aan het einde moet je config bestand er ongeveer zo uitzien:
+Eerst moet je de imap sectie in je `~/.gitconfig` bestand instellen. Je kunt iedere waarde apart instellen met een serie `git config` commando's, of je kunt ze handmatig toevoegen; maar op het eind moet je config bestand er ongeveer zo uitzien:
 
 	[imap]
 	  folder = "[Gmail]/Drafts"
@@ -534,7 +535,26 @@ Eerst moet je de imap sectie in je `~/.gitconfig` bestand instellen. Je kunt ied
 	  sslverify = false
 
 Als je IMAP server geen SSL gebruikt, zijn de laatste twee regels waarschijnlijk niet nodig, en de waarde voor host zal `imap://` zijn in plaats van `imaps://`.
-Als dat ingesteld is, kun je `git send-email` gebruiken om de patch serie in de Drafts map van de gespecificeerde IMAP server te zetten:
+Als dat ingesteld is, kun je `git send-email` gebruiken om de patch reeks in de Drafts map van de gespecificeerde IMAP server te zetten:
+
+	$ cat *.patch |git imap-send
+	Resolving imap.gmail.com... ok
+	Connecting to [74.125.142.109]:993... ok
+	Logging in...
+	sending 2 messages
+	100% (2/2) done
+
+Nu kan je naar je Drafts folder gaan, het To veld te wijzigen naar de maillijst waar je de patch naartoe stuurt en mogelijk de beheerder of verantwoordelijke voor dat deel in de CC zetten en dan versturen.
+
+Je kunt de patches ook via een SMTP server sturen. Zoals eerder kan je elke waarde apart instellen met een serie `git config` commando's, of je kunt ze handmatig in de sendmail sectie in je `~/.gitconfig` bestand zetten:
+
+	[sendemail]
+	  smtpencryption = tls
+	  smtpserver = smtp.gmail.com
+	  smtpuser = user@gmail.com
+	  smtpserverport = 587
+
+Als dit gebeurt is, kan je `git send-email` gebruiken om je patches te sturen:
 
 	$ git send-email *.patch
 	0001-added-limit-to-log-function.patch
@@ -544,7 +564,7 @@ Als dat ingesteld is, kun je `git send-email` gebruiken om de patch serie in de
 	Who should the emails be sent to? jessica@example.com
 	Message-ID to be used as In-Reply-To for the first email? y
 
-Dan spuugt Git een berg log informatie uit, die er zoiets als dit uitziet, voor iedere patch die je stuurt:
+Dan spuuwt Git een bergje log-informatie uit voor iedere patch die je stuurt, en dat ziet er ongeveer zo uit:
 
 	(mbox) Adding cc: Jessica Smith <jessica@example.com> from
 	  \line 'From: Jessica Smith <jessica@example.com>'
@@ -561,19 +581,17 @@ Dan spuugt Git een berg log informatie uit, die er zoiets als dit uitziet, voor
 
 	Result: OK
 
-Op dit punt zou je in staat moeten zijn om naar je Drafts map te gaan, het To veld te wijzigen in de maillijst waarnaar je de patch stuurt, misschien de beheerder of verantwoordelijke persoon voor dat gebied op de CC te zetten, en het weg te sturen.
-
 ### Samenvatting ###
 
-Dit gedeelte heeft een aantal vaak voorkomende werkwijzen behandeld, om om te gaan met een aantal zeer verschillende typen Git projecten die je waarschijnlijk zult tegen komen en een aantal nieuwe programma's geïntroduceerd, die je helpen om dit proces te beheren. Vervolgens zul je zien hoe je aan de andere kant van de medaille werkt: een Git project beheren. Je zult leren hoe een welwillende dictator of integratie manager te zijn.
+In dit hoofdstuk is een aantal veel voorkomende werkwijzen behandeld, die je kunt gebruiken om te kunnen werken in een aantal zeer verschillende typen Git projecten die je misschien zult tegenkomen en een aantal nieuwe gereedschappen ge�ntroduceerd, die je helpen om dit proces te beheren. Wat hierna volgt zal je laten zien hoe je aan de andere kant van de medaille werkt: een Git project beheren. Je zult leren hoe een welwillende dictator of integratie manager te zijn.
 
-## Projectonderhoud ##
+## Het beheren van een project ##
 
-Naast weten hoe effectief bij te dragen aan een project, moet je waarschijnlijk ook weten hoe je deze onderhoud. Dit kan bestaan uit het accepteren en toepassen van patches gegenereerd via 'format-patch' die naar jou gemaild zijn, of het integreren van veranderingen in de remote branches voor repositories die je hebt toegevoegd als remotes aan je project. Of je nu een canonieke repository onderhoud, of wilt bijdragen door het controleren of goedkeuren van patches, je moet weten hoe werk te aanvaarden op een manier die het duidelijkst is voor andere medewerkers en duurzaam door jou op de lange termijn.
+Naast weten hoe effectief bij te dragen aan een project, moet je waarschijnlijk ook moeten weten hoe je er een beheert. Dit kan bestaan uit het accepteren en toepassen van patches die met `format-patch` gemaakt en naar je gemaild zijn, of het integreren van wijzigingen in de remote branches van repositories die je hebt toegevoegd als remotes van je project. Of je nu een canonieke repository beheert, of wilt bijdragen door het controleren of goedkeuren van patches, je moet weten hoe werk te ontvangen op een dusdanige manier die het duidelijkst is voor andere bijdragers en voor jou op langere termijn vol te houden.
 
-### Werken in onderwerp branches ###
+### Werken in topic branches ###
 
-Als je overweegt om nieuw werk te integreren, is het normaliter een goed idee om het uit te proberen in een onderwerp branch – een tijdelijke branch, speciaal gemaakt om dat nieuwe werk te proberen. Op deze manier is het handig om een patch individueel af te stemmen en het weg te laten als het niet werkt, totdat je tijd hebt om er op terug te komen. Als je een eenvoudige branchnaam maakt, gebaseerd op het thema van het werk dat je gaat proberen, bijvoorbeeld `ruby_client` of zoiets beschrijvends, dan kun je het makkelijk onthouden als je het voor een tijdje moet achterlaten en er later op terug moet komen. De beheerder van het Git project heeft de neiging om deze branches ook van een naamruimte te voorzien – zoals `sc/ruby_client`, waarbij `sc` een afkorting is van de persoon die het werk heeft bijgedragen.
+Als je overweegt om nieuw werk te integreren, is het over het algemeen een goed idee om het uit te proberen in een topic branch - een tijdelijke branch, speciaal gemaakt om dat nieuwe werk uit te proberen. Op deze manier is het handig om een patch individueel te behandelen en het even opzij te zetten als het niet werkt, totdat je tijd hebt om er op terug te komen. Als je een eenvoudige branchnaam maakt, gebaseerd op het onderwerp van het werk dat je aan het proberen bent, bijvoorbeeld `ruby_client` of zoiets beschrijvends, dan is het makkelijk om te herinneren als je het voor een tijdje moet achterlaten en er later op terug komt. De beheerder van het Git project heeft de neiging om deze branches ook van een naamsruimte (namespace) te voorzien - zoals `sc/ruby_client`, waarbij `sc` een afkorting is van de persoon die het werk heeft bijgedragen.
 Zoals je je zult herinneren, kun je de branch gebaseerd op je master branch zo maken:
 
 	$ git branch sc/ruby_client master
@@ -582,11 +600,11 @@ Of, als je er ook meteen naar wilt omschakelen, kun je de `checkout -b` optie ge
 
 	$ git checkout -b sc/ruby_client master
 
-Nu ben je klaar om je bijgedragen werk in deze onderwerp branch toe te voegen, en te bepalen of je het wilt samenvoegen in je lange termijn branches.
+Nu ben je klaar om het bijgedragen werk in deze topic branch toe te voegen, en te bepalen of je het wilt mergen in je meer permanente branches.
 
 ### Patches uit e-mail toepassen ###
 
-Als je een patch per e-mail ontvangt, die je moet integreren in je project, moet je de patch in je onderwerp branch toepassen om het te evalueren. Er zijn twee manieren om een ge-emailde patch toe te passen: met `git apply` of met `git am`.
+Als je een patch per e-mail ontvangt, die je moet integreren in je project, moet je de patch in je onderwerp branch toepassen om het te evalueren. Er zijn twee manieren om een ge-mailde patch toe te passen: met `git apply` of met `git am`.
 
 #### Een patch toepassen met apply ####
 
@@ -594,21 +612,21 @@ Als je de patch ontvangen hebt van iemand die het gegenereerd heeft met de `git
 
 	$ git apply /tmp/patch-ruby-client.patch
 
-Dit wijzigt de bestanden in je werkmap. Het is vrijwel gelijk aan het uitvoeren van een `patch -p1` commando om de patch toe te passen, alhoewel het meer paranoïde is en minder wazige paren dan patch. Het handelt ook bestandstoevoegingen af, verwijderingen, en hernoemingen als ze beschreven staan in het `git diff` formaat, wat `patch` niet doet. Als laatste is `git apply` een "pas alles toe of laat alles weg" model, waarbij alles of niets wordt toegepast, waarbij `patch` gedeeltelijke patches kan toepassen, zodat je werkmap in een vreemde status achterblijft. `git apply` is over het algemeen meer paranoïde dan `patch`. Het zal geen commit voor je aanmaken – na het uitgevoerd te hebben, moet je de geïntroduceerde wijzigingen handmatig stagen en committen.
+Dit wijzigt de bestanden in je werk directory. Het is vrijwel gelijk aan het uitvoeren van een `patch -p1` commando om de patch toe te passen, alhoewel het meer parano�de is en minder fuzzy matches accepteert dan patch. Het handelt ook bestandstoevoegingen af, -verwijderingen, en hernoemingen als ze beschreven staan in het `git diff` formaat, wat `patch` niet doet. Als laatste volgt `git apply` een "pas alles toe of laat alles weg" model, waarbij alles of niets wordt toegepast, en `patch` gedeeltelijke patches kan toepassen, waardoor je werk directory in een vreemde status achterblijft. `git apply` is over het algemeen meer parano�de dan `patch`. Het zal geen commit voor je aanmaken - na het uitgevoerd te zijn, je moet de ge�ntroduceerde wijzigingen handmatig stagen en committen.
 
-Je kunt ook git apply gebruiken om te zien of een patch netjes toepast, voordat je het echt toepast – je kunt `git apply --check` uitvoeren met de patch:
+Je kunt ook git apply gebruiken om te zien of een patch netjes wordt toepast voordat je het echt toepast - je kunt `git apply --check` uitvoeren met de patch:
 
 	$ git apply --check 0001-seeing-if-this-helps-the-gem.patch
 	error: patch failed: ticgit.gemspec:1
 	error: ticgit.gemspec: patch does not apply
 
-Als er geen uitvoer is, dan zou de patch netjes toe moeten passen. Dit commando eindigt ook met een status niet gelijk aan nul als de controle faalt, zodat je het kunt gebruiken in scripts als je dat wilt.
+Als er geen uitvoer is, dan zou de patch netjes moeten passen. Dit commando eindigt ook met een niet-nul status als de controle faalt, zodat je het kunt gebruiken in scripts als je dat wilt.
 
 #### Een patch met am toepassen ####
 
-Als de bijdrager een Git gebruiker is en zo goed was om het `format-patch` commando te gebruiken om hun patch te genereren, dan is je werk eenvoudiger omdat de patch auteur informatie en een commit bericht voor je bevat. Als je kunt, moedig je bijdragers aan om `format-patch` te gebruiken in plaats van `diff` om patches te genereren voor je. Je zou alleen `git apply` hoeven te gebruiken voor oude patches en dat soort dingen.
+Als de bijdrager een Git gebruiker is en zo vriendelijk was om het `format-patch` commando te gebruiken om hun patch te genereren, dan is je werk eenvoudiger omdat de patch de auteur informatie en een commit bericht voor je bevat. Als je kunt, moedig je bijdragers aan om `format-patch` te gebruiken in plaats van `diff` om patches te genereren voor je. Je zou alleen `git apply` hoeven te gebruiken voor oude patches en dat soort dingen.
 
-Om een patch gegenereerd met `format-patch` toe te passen, gebruik je `git am`. Technisch is `git am` gemaakt om een mbox bestand te lezen, dat een eenvoudig gewone tekst formaat of is om één of meer e-mail berichten in een tekst bestand op te slaan. Het ziet er zoiets als dit uit:
+Om een patch gegenereerd met `format-patch` toe te passen, gebruik je `git am`. Technisch is `git am` gemaakt om een mbox bestand te lezen, dat een eenvoudig gewone platte tekstformaat is om ��n of meer e-mail berichten in een tekst bestand op te slaan. Het ziet er ongeveer zo uit:
 
 	From 330090432754092d704da8e76ca5c05c198e71a8 Mon Sep 17 00:00:00 2001
 	From: Jessica Smith <jessica@example.com>
@@ -617,14 +635,14 @@ Om een patch gegenereerd met `format-patch` toe te passen, gebruik je `git am`.
 
 	Limit log functionality to the first 20
 
-Dit is het begin van de uitvoer van het format-patch commando dat je gezien hebt in het vorige gedeelte. Dit is ook een geldig mbox e-mail formaat. Als iemand jou de patch goed gemaild heeft door gebruik te maken van git send-email, en je download dat in een mbox formaat, dan kun je git am naar dat mbox bestand wijzen, en het zal beginnen met alle patches die het ziet toe te passen. Als je een mail client uitvoert die meerdere e-mails kan opslaan in mbox formaat, dan kun je hele patch series in een bestand opslaan en dan git am gebruiken om ze stuk voor stuk toe te passen.
+Dit is het begin van de uitvoer van het format-patch commando dat je gezien hebt in de vorige paragraaf. Dit is ook een geldig mbox e-mail formaat. Als iemand jou de patch correct gemaild heeft door gebruik te maken van git send-email en je downloadt dat in een mbox formaat, dan kan je het git am naar dat mbox bestand verwijzen, en het zal beginnen met alle patches die het ziet toe te passen. Als je een mail client gebruikt die meerdere e-mails kan opslaan in mbox formaat, dan kun je hele patch series in een bestand opslaan en dan git am gebruiken om ze een voor een toe te passen.
 
-Maar, als iemand een patch bestand heeft ge-upload die gegenereerd is met `format-patch` naar een ticket systeem of zoiets, kun je het bestand lokaal opslaan en dan dat bestand dat bewaard is op je schijf aan `git am` geven om het toe te passen:
+Maar, als iemand een patch bestand heeft ge-upload die gegenereerd is met `format-patch` naar een ticket systeem of zoiets, kun je het bestand lokaal opslaan en dan dat opgeslagen bestand aan `git am` doorgeven om het toe te passen:
 
 	$ git am 0001-limit-log-function.patch
 	Applying: add limit to log function
 
-Je kunt zien dat het netjes is toegepast, en automatisch een nieuwe commit voor je heeft aangemaakt. De auteur informatie wordt gehaald uit het `From` en `Date` veld in de kop, en het bericht van de commit wordt gehaald uit de `Subject` en inhoud (voor de patch van de e-mail. Bijvoorbeeld, als deze patch was toegepast van het mbox voorbeeld dat ik zojuist getoond heb, dan zou de gegenereerde commit er ongeveer zo uit zien:
+Je kunt zien dat het netjes is toegepast, en automatisch een nieuwe commit voor je heeft aangemaakt. De auteursinformatie wordt gehaald uit de `From` en `Date` velden in de kop, en het bericht van de commit wordt gehaald uit de `Subject` en inhoud (voor de patch) van het mail bericht. Bijvoorbeeld, als deze patch was toegepast van het mbox voorbeeld dat ik zojuist getoond heb, dan zou de gegenereerde commit er ongeveer zo uit zien:
 
 	$ git log --pretty=fuller -1
 	commit 6c5e70b984a60b3cecd395edd5b48a7575bf58e0
@@ -637,9 +655,9 @@ Je kunt zien dat het netjes is toegepast, en automatisch een nieuwe commit voor
 
 	   Limit log functionality to the first 20
 
-De `Commit` informatie laat de persoon die de patch toepaste en de tijd waarop het was toegepast zien. De `Author` informatie is het individueel die de patch origineel gemaakt heeft en wanneer het origineel gemaakt is.
+De `Commit` informatie laat de persoon die de patch toepaste en de tijd waarop het is toegepast zien. De `Author` informatie het individu die de patch oorspronkelijk gemaakt heeft en wanneer het gemaakt is.
 
-Maar, het is mogelijk dat de patch niet netjes toepast. Misschien is je hoofdbranch te ver afgeweken van de branch waarop de patch gebouwd is, of hangt de patch van een andere patch af, die je nog niet hebt toegepast. In dat geval zal het `git am` proces falen en je vragen wat je wilt doen:
+Maar het is mogelijk dat de patch niet netjes toegepast kan worden. Misschien is je hoofdbranch te ver afgeweken van de branch waarop de patch gebouwd is, of is de patch van een andere patch, die je nog niet hebt toegepast, afhankelijk. In dat geval zal het `git am` proces falen en je vragen wat je wilt doen:
 
 	$ git am 0001-seeing-if-this-helps-the-gem.patch
 	Applying: seeing if this helps the gem
@@ -650,14 +668,14 @@ Maar, het is mogelijk dat de patch niet netjes toepast. Misschien is je hoofdbra
 	If you would prefer to skip this patch, instead run "git am --skip".
 	To restore the original branch and stop patching run "git am --abort".
 
-Dit commando stopt conflict markeringen in alle bestanden waar het problemen mee heeft, net zoals een conflicterende samenvoeging of rebase operatie. Je lost dit probleem in een vergelijkbare manier op – wijzig het bestand om het conflict op te lossen, stage het bestand, en voer dan `git am --resolved` uit om door te gaan met de volgende patch:
+Dit commando stopt conflict markeringen in alle bestanden waar het problemen mee heeft, net zoals een conflicterende merge of rebase operatie. Je lost dit probleem op een vergelijkbare manier op - wijzig het bestand om het conflict op te lossen, stage het bestand, en voer dan `git am --resolved` uit om door te gaan met de volgende patch:
 
 	$ (fix the file)
 	$ git add ticgit.gemspec
 	$ git am --resolved
 	Applying: seeing if this helps the gem
 
-Als je wil dat Git een beetje meer intelligent probeert om het conflict op te lossen, kun je een `-3` optie eraan meegeven, wat zorgt dat Git een drieweg samenvoeging probeert. Deze optie staat standaard niet aan, omdat het niet werkt als de commit waarvan de patch zegt dat het op gebaseerd is niet in je repository zit. Als je die commit wel hebt – als de patch gebaseerd was op een publieke commit – dan is de `-3` over het algemeen veel slimmer in het toepassen van een conflicterende patch:
+Als je wil dat Git een beetje meer intelligentie toepast om het conflict op te lossen, kun je een `-3` optie eraan meegeven, wat ervoor zorgt dat Git een driewegs-merge probeert. Deze optie staat standaard niet aan, omdat het niet werkt als de commit waarvan de patch zegt dat het op gebaseerd is niet in je repository zit. Als je die commit wel hebt - als de patch gebaseerd was op een publieke commit - dan is de `-3` over het algemeen veel slimmer in het toepassen van een conflicterende patch:
 
 	$ git am -3 0001-seeing-if-this-helps-the-gem.patch
 	Applying: seeing if this helps the gem
@@ -667,7 +685,7 @@ Als je wil dat Git een beetje meer intelligent probeert om het conflict op te lo
 	Falling back to patching base and 3-way merge...
 	No changes -- Patch already applied.
 
-In dit geval, probeerde ik een patch toe te passen die ik reeds toegepast had. Zonder de `-3` optie ziet het eruit als een conflict.
+In dit geval, probeerde ik een patch toe te passen die ik al eerder toegepast had. Zonder de `-3` optie ziet het eruit als een conflict.
 
 Als je een aantal patches van een mbox toepast, kun je ook het `am` commando in een interactieve modus uitvoeren, wat bij iedere patch die het vind stopt en je vraagt of je het wilt toepassen:
 
@@ -678,36 +696,36 @@ Als je een aantal patches van een mbox toepast, kun je ook het `am` commando in
 	--------------------------
 	Apply? [y]es/[n]o/[e]dit/[v]iew patch/[a]ccept all
 
-Dit is fijn als je een aantal patches bewaard hebt, omdat je de patch eerst kunt zien als je je niet kunt herinneren wat het is, of de patch niet wilt toepassen als je het al gedaan hebt.
+Dit is prettig als je een aantal patches bewaard hebt, omdat je de patch eerst kunt zien als je je niet kunt herinneren wat het is, of de patch niet wilt toepassen als je dat al gedaan hebt.
 
-Als alle patches voor je onderwerp branch zijn toegepast en gecommit zijn op je branch, kun je kiezen of en hoe ze te integreren in een langer lopende branch.
+Als alle patches voor je topic branch zijn toegepast en gecommit zijn op je branch, kun je kiezen of en hoe ze te integreren in een branch met een langere looptijd.
 
-### Remote branches bekijken ###
+### Remote branches uitchecken ###
 
-Als je bijdrage van een Git gebruiker komt, die zijn eigen repository ingesteld heeft, een aantal patches daarin teruggezet heeft, en jou de URL naar de repository gestuurd heeft en de naam van de remote branch waarin de wijzigingen zitten, dan kun je ze toevoegen als een remote en de samenvoegingen lokaal doen.
+Als je bijdrage van een Git gebruiker komt, die zijn eigen repository opgezet heeft, een aantal patches daarin gepushed heeft, en jou de URL naar de repository gestuurd heeft en de naam van de remote branch waarin de wijzigingen zitten, kan je ze toevoegen als een remote en het mergen lokaal doen.
 
-Bijvoorbeeld, als Jessica je een e-mail stuurt waarin staat dat ze een mooie nieuw eigenschap in de `ruby-client` branch van haar repository heeft, kun je het testen door de remote toe te voegen en die branch lokaal te bekijken:
+Bijvoorbeeld, als Jessica je een e-mail stuurt waarin staat dat ze een mooie nieuw feature in de `ruby-client` branch van haar repository heeft, kun je het testen door de remote toe te voegen en die branch lokaal te bekijken:
 
 	$ git remote add jessica git://github.com/jessica/myproject.git
 	$ git fetch jessica
 	$ git checkout -b rubyclient jessica/ruby-client
 
-Als ze je later opnieuw e-mailt met een andere branch die een andere mooie eigenschap bevat, dan kun je die ophalen en bekijken omdat je de remote al ingesteld hebt.
+Als ze je later opnieuw e-mailt met een andere branch die een andere mooie feature bevat, dan kun je die ophalen en bekijken omdat je de remote al ingesteld hebt.
 
-Dit is erg handig als je consistent met een persoon werkt. Als iemand een enkele patch eens in de zoveel tijd bij te dragen heeft, dan is het accepteren per e-mail misschien minder tijdrovend dan eisen dat iedereen hun eigen server moet draaien en doorlopend remotes toevoegen en verwijderen om een paar patches te krijgen. Je zult waarschijnlijk ook honderden remotes hebben, elk voor iemand die maar een patch of twee bijdraagt. Maar, scripts en gehoste diensten maken dit misschien makkelijker – het hangt veel af van hoe jij ontwikkeld en hoe je bijdragers ontwikkelen.
+Dit is meest nuttig als je vaak met een persoon werkt. Als iemand een enkele patch eens in de zoveel tijd bij te dragen heeft, dan is het accepteren per e-mail misschien minder tijdrovend dan eisen dat iedereen hun eigen server moet draaien en doorlopend remotes toevoegen en verwijderen om een paar patches te krijgen. Je zult waarschijnlijk ook niet honderden remotes willen hebben, elk voor iemand die maar een patch of twee bijdraagt. Aan de andere kant, scripts en gehoste diensten maken dit misschien makkelijker - het hangt veel af van hoe jij ontwikkelt en hoe je bijdragers ontwikkelen.
 
-Het andere voordeel van deze aanpak is dat je de historie van de commits ook krijgt. Alhoewel je misschien geldige samenvoeg problemen hebt, weet je waar in je historie hun werk is gebaseerd; een goede drieweg samenvoeging is de standaard in plaats van een `-3` te moeten meegeven en hopen dat de patch gegenereerd was van een publieke commit waar je toegang toe hebt.
+Het andere voordeel van deze aanpak is dat je de historie van de commits ook krijgt. Alhoewel je misschien terechte merge problemen hebt, weet je op welk punt in de historie hun werk is gebaseerd; een echte drieweg merge is de standaard in plaats van een `-3` te moeten meegeven en hopen dat de patch gegenereerd was van een publieke commit waar je toegang toe hebt.
 
-Als je niet consistent met een persoon werkt, maar toch op deze manier van hen wilt ophalen, dan kun je de URL van het remote repository geven aan het `git pull` commando. Dit haalt eenmalig  op en bewaart de URL niet als een remote referentie:
+Als je maar af en toe met een persoon werkt, maar toch op deze manier van hen wilt pullen, dan kun je de URL van de remote repository geven aan het `git pull` commando. Dit haalt eenmalig  op en bewaart de URL niet als een remote referentie:
 
 	$ git pull git://github.com/onetimeguy/project.git
 	From git://github.com/onetimeguy/project
 	 * branch            HEAD       -> FETCH_HEAD
 	Merge made by recursive.
 
-### Bepalen wat geïntroduceerd wordt ###
+### Bepalen wat ge�ntroduceerd wordt ###
 
-Nu heb je een onderwerp branch dat bijgedragen werk bevat. Op dit punt kun je bepalen wat je er mee wilt doen. Deze sectie bezoekt een paar commando's opnieuw zodat je kunt zien hoe je ze kunt gebruiken om precies te reviewen wat je zult introduceren als je dit samenvoegt in je hoofd branch.
+Je hebt een topic branch dat bijgedragen werk bevat. Nu kan je bepalen wat je er mee wilt doen. Deze paragraaf bekijkt een paar commando's opnieuw om te laten zien hoe je ze kunt gebruiken om precies te reviewen wat je zult introduceren als je dit merged in je hoofd branch.
 
 Het is vaak behulpzaam om een review te krijgen van alle commits die in deze branch zitten, maar die niet in je master branch zitten. Je kunt commits weglaten in de master branch door de `--not` optie mee te geven voor de branch naam. Bijvoorbeeld, als je bijdrager je twee patches stuurt en je wil een branch genaamd `contrib` maken en die patches daar toepassen, dan kun je dit uitvoeren:
 
@@ -724,7 +742,7 @@ Het is vaak behulpzaam om een review te krijgen van alle commits die in deze bra
 
 	    updated the gemspec to hopefully work better
 
-Om te zien welke wijzigingen iedere commit introduceert, onthoud dan dat je de `-p` optie kunt meegeven aan `git log` en dan zal het de diff geïntroduceerd bij iedere commit weergeven.
+Om te zien welke wijzigingen iedere commit introduceert, onthoud dan dat je de `-p` optie kunt meegeven aan `git log` en dan zal het de diff ge�ntroduceerd bij iedere commit weergeven.
 
 Om een volledige diff te zien van wat zou gebeuren als je deze onderwerp branch samenvoegt met een andere branch, zul je misschien een vreemde truc moeten toepassen om de juiste resultaten te krijgen. Je zult misschien denken om dit uit te voeren:
 
@@ -734,7 +752,7 @@ Dit commando geeft je een diff, maar het zou misleidend kunnen zijn. Als je `mas
 
 Als `master` een directe afstammeling is van je onderwerp branch, is dit geen probleem; maar als de twee histories uit elkaar zijn gegaan, zal de diff eruit zien alsof je alle nieuwe spullen in je onderwerp branch toevoegt en al het unieke weghaalt in de `master` branch.
 
-Wat je echt wil zien zijn de wijzigingen die in de onderwerp branch zijn toegevoegd – het werk dat je zult introduceren als je deze branch met master samenvoegt. Je doet dat door Git de laatste commit op je onderwerp branch te laten vergelijken met de eerste gezamenlijke voorouder die het heeft met de master branch.
+Wat je echt wil zien zijn de wijzigingen die in de onderwerp branch zijn toegevoegd - het werk dat je zult introduceren als je deze branch met master samenvoegt. Je doet dat door Git de laatste commit op je onderwerp branch te laten vergelijken met de eerste gezamenlijke voorouder die het heeft met de master branch.
 
 Technisch, kun je dat doen door de gezamenlijke voorouder expliciet uit te zoeken en dan daar je diff op uit te voeren:
 
@@ -746,11 +764,11 @@ Maar, dat is niet handig, dus levert Git een andere korte manier om hetzelfde te
 
 	$ git diff master...contrib
 
-Dit commando toont je alleen het werk dat je huidige onderwerp branch heeft geïntroduceerd sinds zijn gezamenlijke voorouder met master. Dat is een erg handige syntax om te onthouden.
+Dit commando toont je alleen het werk dat je huidige onderwerp branch heeft ge�ntroduceerd sinds zijn gezamenlijke voorouder met master. Dat is een erg handige syntax om te onthouden.
 
 ### Bijgedragen werk integreren ###
 
-Als al het werk in je onderwerp branch klaar is om te worden geïntegreerd in een meer hoofdlijn branch, dan is de vraag hoe het te doen. En daarna, welke algemene werkwijze wil je gebruiken om je project te onderhouden? Je hebt een aantal keuzes, dus ik zal er een paar behandelen.
+Als al het werk in je onderwerp branch klaar is om te worden ge�ntegreerd in een meer hoofdlijn branch, dan is de vraag hoe het te doen. En daarna, welke algemene werkwijze wil je gebruiken om je project te onderhouden? Je hebt een aantal keuzes, dus ik zal er een paar behandelen.
 
 #### Samenvoeg werkwijzen ####
 
@@ -764,7 +782,7 @@ Figuur 5-20. Na het samenvoegen van een onderwerp branch.
 
 Dat is waarschijnlijk de eenvoudigste werkwijze, maar het is problematisch als je werkt met grotere repositories of projecten.
 
-Als je meer ontwikkelaars hebt, of een groter project, dan zul je waarschijnlijk een minstens twee fasen samenvoeg cyclus willen gebruiken. In dit scenario, heb je twee langlopende branches, `master` en `develop`, waarin je bepaald dat `master` alleen vernieuwd wordt als een zeer stabiele vrijgave gedaan wordt en alle nieuwe code geïntegreerd is in de `develop` branch. Je zet beide branches regelmatig terug naar het publieke repository. Iedere keer als je een nieuw onderwerp branch hebt om samen te voegen (Figuur 5-21), voeg je het in `develop` (Figuur 5-22); daarna, als je een tag maakt van een vrijgave, dan doe je een fast-forward van `master` naar waar de nu stabiele `develop` branch is (Figuur 5-23).
+Als je meer ontwikkelaars hebt, of een groter project, dan zul je waarschijnlijk een minstens twee fasen samenvoeg cyclus willen gebruiken. In dit scenario, heb je twee langlopende branches, `master` en `develop`, waarin je bepaald dat `master` alleen vernieuwd wordt als een zeer stabiele vrijgave gedaan wordt en alle nieuwe code ge�ntegreerd is in de `develop` branch. Je zet beide branches regelmatig terug naar het publieke repository. Iedere keer als je een nieuw onderwerp branch hebt om samen te voegen (Figuur 5-21), voeg je het in `develop` (Figuur 5-22); daarna, als je een tag maakt van een vrijgave, dan doe je een fast-forward van `master` naar waar de nu stabiele `develop` branch is (Figuur 5-23).
 
 Insert 18333fig0521.png
 Figuur 5-21. Voor een samenvoeging van een onderwerp branch.
@@ -780,7 +798,7 @@ Je kunt dit concept ook doortrekken, waarbij je een integratie branch hebt waar
 
 #### Werkwijzen met grote samenvoegingen ####
 
-Het Git project heeft vier langlopende branches: `master`, `next`, en `pu` (proposed updates, voorgestelde vernieuwingen), en `maint` voor onderhoudswerk. Als nieuw werk wordt geïntroduceerd door bijdragers, wordt het samengeraapt in onderwerp branches in het repository van de beheerder op een manier gelijk aan wat ik omschreven heb (zie Figuur 5-24). Op dit punt, worden de onderwerpen geëvalueerd om te bepalen of ze veilig zijn en klaar voor consumptie of dat ze nog wat werk nodig hebben. Als ze veilig zijn, worden ze in `next` samengevoegd, en wordt die branch teruggezet zodat iedereen de onderwerpen geïntegreerd kan proberen.
+Het Git project heeft vier langlopende branches: `master`, `next`, en `pu` (proposed updates, voorgestelde vernieuwingen), en `maint` voor onderhoudswerk. Als nieuw werk wordt ge�ntroduceerd door bijdragers, wordt het samengeraapt in onderwerp branches in het repository van de beheerder op een manier gelijk aan wat ik omschreven heb (zie Figuur 5-24). Op dit punt, worden de onderwerpen ge�valueerd om te bepalen of ze veilig zijn en klaar voor consumptie of dat ze nog wat werk nodig hebben. Als ze veilig zijn, worden ze in `next` samengevoegd, en wordt die branch teruggezet zodat iedereen de onderwerpen ge�ntegreerd kan proberen.
 
 Insert 18333fig0524.png
 Figuur 5-24. Een complexe serie van parallelle bijgedragen onderwerp branches beheren.
@@ -796,7 +814,7 @@ Als een onderwerp branch uiteindelijk is samengevoegd in `master`, dan wordt het
 
 Andere beheerders geven de voorkeur aan rebasen of bijgedragen werk te cherry picken bovenop hun master branch, in plaats van het er in samen te voegen, om een lineaire historie te behouden. Als je werk in een onderwerp branch hebt en hebt besloten dat je het wil integreren, dan ga je naar die branch en voert het rebase commando uit om de wijzigingen bovenop je huidige master branch te bouwen (of `develop`, enzovoorts). Als dat goed werkt, dan kun je je `master` branch fast-forwarden, en dan eindig je met een lineaire project historie.
 
-De andere manier om geïntroduceerd werk van de ene naar de andere branch te verplaatsen is om het te cherry picken. Een cherry-pick in Git is een soort rebase voor een enkele commit. Het pakt de patch die was geïntroduceerd in een commit en probeert die opnieuw toe te passen op de branch waar je nu op zit. Dit is handig als je een aantal commits op een onderwerp branch hebt en je er slechts één van wilt integreren, of als je alleen één commit op een onderwerp branch hebt en er de voorkeur aan geeft om het te cherry-picken in plaats van rebase uit te voeren. Bijvoorbeeld, stel dat je een project hebt dat eruit ziet als Figuur 5-26.
+De andere manier om ge�ntroduceerd werk van de ene naar de andere branch te verplaatsen is om het te cherry picken. Een cherry-pick in Git is een soort rebase voor een enkele commit. Het pakt de patch die was ge�ntroduceerd in een commit en probeert die opnieuw toe te passen op de branch waar je nu op zit. Dit is handig als je een aantal commits op een onderwerp branch hebt en je er slechts ��n van wilt integreren, of als je alleen ��n commit op een onderwerp branch hebt en er de voorkeur aan geeft om het te cherry-picken in plaats van rebase uit te voeren. Bijvoorbeeld, stel dat je een project hebt dat eruit ziet als Figuur 5-26.
 
 Insert 18333fig0526.png
 Figuur 5-26. Voorbeeld historie voor een cherry pick.
@@ -808,7 +826,7 @@ Als je commit `e43a6` in je master branch wil halen, dan kun je dit uitvoeren
 	[master]: created a0a41a9: "More friendly message when locking the index fails."
 	 3 files changed, 17 insertions(+), 3 deletions(-)
 
-Dit haalt dezelfde wijziging binnen als geïntroduceerd in `e43a6`, maar je krijgt een nieuwe SHA-1 waarde, omdat de gegevens op een andere manier toegepast zijn. Nu ziet je historie eruit als Figuur 5-27.
+Dit haalt dezelfde wijziging binnen als ge�ntroduceerd in `e43a6`, maar je krijgt een nieuwe SHA-1 waarde, omdat de gegevens op een andere manier toegepast zijn. Nu ziet je historie eruit als Figuur 5-27.
 
 Insert 18333fig0527.png
 Figuur 5-27. Historie na het cherry-picken van een commit op een onderwerp branch.
@@ -842,11 +860,11 @@ Nu dat je de inhoud van je sleutel in Git hebt, kun je een tag aanmaken die dire
 
 	$ git tag -a maintainer-pgp-pub 659ef797d181633c87ec71ac3f9ba29fe5775b92
 
-Als je `git push --tags` uitvoert, zal de `maintainer-pgp-pub` tag met iedereen gedeeld worden. Als iemand een tag wil verifiëren, dan kunnen ze je PGP sleutel direct importeren door de blob direct uit de gegevensbank te halen en het in GPG te importeren:
+Als je `git push --tags` uitvoert, zal de `maintainer-pgp-pub` tag met iedereen gedeeld worden. Als iemand een tag wil verifi�ren, dan kunnen ze je PGP sleutel direct importeren door de blob direct uit de gegevensbank te halen en het in GPG te importeren:
 
 	$ git show maintainer-pgp-pub | gpg --import
 
-Ze kunnen die sleutel gebruiken om als je gesigneerde tags te verifiëren. Als je de instructies in het tag bericht zet, dan zal `git show <tag>` je eindgebruikers meer specifieke instructies geven over tag verificatie.
+Ze kunnen die sleutel gebruiken om als je gesigneerde tags te verifi�ren. Als je de instructies in het tag bericht zet, dan zal `git show <tag>` je eindgebruikers meer specifieke instructies geven over tag verificatie.
 
 ### Een bouw nummer genereren ###
 
@@ -857,7 +875,7 @@ Omdat Git geen monotone oplopende nummers heeft zoals 'v123' of iets gelijkwaard
 
 Op deze manier kun je een snapshot of bouw exporteren en het vernoemen naar iets dat begrijpelijk is voor mensen. In feite, als je Git vanaf broncode bouwt, gekloond van het Git repository, geeft `git --version` je iets dat er zo uitziet. Als je een commit omschrijft die je direct getagged wil hebben, dat geeft het je de tag naam.
 
-Het `git describe` commando heeft de voorkeur voor beschreven tags (tags gecreëerd met de `-a` of `-s` vlag), dus vrijgave tags zouden op deze manier aangemaakt moeten worden als je `git describe` gebruikt, om er zeker van te zijn dat de commit juist benoemd wordt als het omschreven wordt. Je kunt deze tekst gebruiken als het doel van een checkout of show commando, alhoewel het afhangt van de verkorte SHA-1 waarde aan het einde, dus het zou niet voor altijd geldig kunnen zijn. Bijvoorbeeld, de Linux kernel sprong recentelijk van 8 naar 10 karakters om er zeker van de zijn dat de SHA-1 uniek zijn, zodat oudere `git describe` commando's ongeldig werden.
+Het `git describe` commando heeft de voorkeur voor beschreven tags (tags gecre�erd met de `-a` of `-s` vlag), dus vrijgave tags zouden op deze manier aangemaakt moeten worden als je `git describe` gebruikt, om er zeker van te zijn dat de commit juist benoemd wordt als het omschreven wordt. Je kunt deze tekst gebruiken als het doel van een checkout of show commando, alhoewel het afhangt van de verkorte SHA-1 waarde aan het einde, dus het zou niet voor altijd geldig kunnen zijn. Bijvoorbeeld, de Linux kernel sprong recentelijk van 8 naar 10 karakters om er zeker van de zijn dat de SHA-1 uniek zijn, zodat oudere `git describe` commando's ongeldig werden.
 
 ### Een vrijgave voorbereiden ###
 

From 6b57e66b40545eb3f062fa8500f7ef6e7c7b1954 Mon Sep 17 00:00:00 2001
From: cor <git@cpt1.demon.nl>
Date: Wed, 29 Jan 2014 20:43:14 +0100
Subject: [PATCH 136/690] [nl] Retranslate chapter.

	Reword and remove a number of Babelfishes in the text.
	Introduce diacritics.
---
 nl/05-distributed-git/01-chapter5.markdown | 188 ++++++++++-----------
 1 file changed, 94 insertions(+), 94 deletions(-)

diff --git a/nl/05-distributed-git/01-chapter5.markdown b/nl/05-distributed-git/01-chapter5.markdown
index cee8e7138..d84874a81 100644
--- a/nl/05-distributed-git/01-chapter5.markdown
+++ b/nl/05-distributed-git/01-chapter5.markdown
@@ -386,9 +386,9 @@ Figuur 5-15. Eenvoudige volgorde in de werkwijze van dit aangestuurde team.
 
 ### Klein openbaar project ###
 
-Het bijdragen aan openbare, of publieke, projecten gaat op een iets andere manier. Omdat je niet de toestemming hebt om de branches van het project te updaten, moet je het werk op een andere manier naar de beheerders krijgen. Dit eerste voorbeeld beschrijft het bijdragen via afsplitsen (forken) op Git hosts, die het makkelijk maken om te forken. De repo.or.cz en GitHub hosting sites ondersteunen dit beiden, en veel project beheerders verwachten deze manier van bijdragen. De volgende paragraaf behandelt projecten die de voorkeur hebben om bijdragen in de vorm van patches via e-mail te ontvangen.
+Het bijdragen aan openbare, of publieke, projecten gaat op een iets andere manier. Omdat je niet de toestemming hebt om de branches van het project rechtstreeks te updaten, moet je het werk op een andere manier naar de beheerders krijgen. Dit eerste voorbeeld beschrijft het bijdragen via afsplitsen (forken) op Git hosts die het eenvoudig aanmaken van forks ondersteunen. De repo.or.cz en GitHub hosting sites ondersteunen dit beide, en veel project beheerders verwachten deze manier van bijdragen. De volgende paragraaf behandelt projecten die de voorkeur hebben om bijdragen in de vorm van patches via e-mail te ontvangen.
 
-Eerst zal je waarschijnlijk de hoofdrepository klonen, een topic branch maken voor de patch of reeks patches die je van plan bent bij te dragen, en je werk daarop doen. De werkwijze ziet er zo uit:
+Eerst zal je waarschijnlijk de hoofdrepository klonen, een topic branch maken voor de patch of reeks patches die je van plan bent bij te dragen, en je werk daarop doen. De te volgen stappen zien er zo uit:
 
 	$ git clone (url)
 	$ cd project
@@ -398,19 +398,19 @@ Eerst zal je waarschijnlijk de hoofdrepository klonen, een topic branch maken vo
 	$ (work)
 	$ git commit
 
-Je wil misschien de `rebase -i` optie gebruiken om je werk in ��n enkele commit samen te persen (squash), of het werk in de commits herschikken om de patch eenvoudiger te kunnen laten reviewen door de beheerders - zie Hoofdstuk 6 voor meer informatie over het interactief rebasen.
+Je kunt eventueel besluiten `rebase -i` te gebruiken om je werk in ��n enkele commit samen te persen (squash), of het werk in de commits te herschikken om de patch eenvoudiger te kunnen laten reviewen door de beheerders - zie Hoofdstuk 6 voor meer informatie over het interactief rebasen.
 
-Als je werk op de branch af is, en je klaar bent om het over te dragen aan de beheerders, ga je naar de originele project pagina en klik op de "Fork" knop, hiermee maak je een eigen schrijfbare fork van het project. Je moet dit dan in een nieuwe repository URL toevoegen als een tweede remote, in dit geval `myfork` genaamd:
+Als je werk op de branch af is, en je klaar bent om het over te dragen aan de beheerders, ga je naar de originele project pagina en klik op de "Fork" knop. Hiermee maak je een eigen overschrijfbare fork van het project. Je moet de URL van deze nieuwe repository URL toevoegen als een tweede remote, in dit geval `myfork` genaamd:
 
 	$ git remote add myfork (url)
 
-Je moet je werk hier naar pushen. Het is het makkelijkst om de remote branch waar je op zit te werken te pushen naar je repository, in plaats van het samenvoegen in je master branch en die terug te zetten. De reden hiervan is, dat als het werk niet wordt geaccepteerd of alleen ge-cherry picked, je jouw master branch niet hoeft terug te draaien. Als de beheerders je werk mergen, rebasen of cherry picken, dan krijg je het uiteindelijk toch terug door hun repository te pullen:
+Je moet je werk daar naartoe pushen. Het is het makkelijkst om de remote branch waar je op zit te werken te pushen naar je repository, in plaats van het samenvoegen in je master branch en die te pushen. De reden hiervan is, dat als het werk niet wordt geaccepteerd of alleen ge-cherry picked (deels overgenomen), je jouw master branch niet hoeft terug te draaien. Als de beheerders je werk mergen, rebasen of cherry picken, dan krijg je het uiteindelijk toch binnen door hun repository te pullen:
 
 	$ git push myfork featureA
 
-Als jouw werk gepushed is naar jouw fork, dan moet je de beheerder een seintje geven. Dit wordt vaak een pull request (haal-binnen-verzoek) genoemd, en je kunt het via de website genereren - GitHub heeft een "pull request" knop die de beheerder automatisch een bericht stuurt - of het `git request-pull` commando uitvoeren en de uitvoer handmatig naar de projectbeheerder mailen.
+Als jouw werk gepushed is naar jouw fork, dan moet je de beheerder inlichten. Dit wordt een pull request (haal-binnen-verzoek) genoemd, en je kunt deze via de website genereren - GitHub heeft een "pull request" knop die de beheerder automatisch een bericht stuurt - of het `git request-pull` commando uitvoeren en de uitvoer handmatig naar de projectbeheerder mailen.
 
-Het `request-pull` commando neemt de branch waarin je je topic branch gepulled wil hebben, en de URL van de Git repository waar je ze uit wil laten pullen, en maakt een samenvatting van alle wijzigingen die je gepulled wenst te hebben. Bijvoorbeeld, als Jessica John een pull request wil sturen, en ze heeft twee commits gedaan op de topic branch die ze zojuist gepushed heeft, dan kan ze dit uitvoeren:
+Het `request-pull` commando neemt de basis branch waarin je de topic branch gepulled wil hebben, en de URL van de Git repository waar je ze uit wil laten pullen, en maakt een samenvatting van alle wijzigingen die je gepulled wenst te hebben. Bijvoorbeeld, als Jessica John een pull request wil sturen, en ze heeft twee commits gedaan op de topic branch die ze zojuist gepushed heeft, dan kan ze dit uitvoeren:
 
 	$ git request-pull origin/master myfork
 	The following changes since commit 1edee6b1d61823a2de3b09c160d7080b8d1b3a40:
@@ -428,9 +428,9 @@ Het `request-pull` commando neemt de branch waarin je je topic branch gepulled w
 	 lib/simplegit.rb |   10 +++++++++-
 	 1 files changed, 9 insertions(+), 1 deletions(-)
 
-De uitvoer kan naar de beheerder gestuurd worden: het verteld ze waar het werk vanaf gebranched is, vat de commits samen, en verteld waar vandaan ze dit werk kunnen pullen.
+De uitvoer kan naar de beheerders gestuurd worden: het verteld ze waar het werk vanaf gebranched is, vat de commits samen en verteld waar vandaan ze dit werk kunnen pullen.
 
-Bij een project waarvan je niet de beheerder bent, is het over het algemeen eenvoudiger om een branch zoals `master` altijd de `origin/master` te laten volgen, en je werk te doen in topic branches die je eenvoudig weg kunt gooien als ze geweigerd worden. Als je je werkthema's gescheiden houdt in topic branches maakt dat het ook eenvoudiger voor jou om je werk te rebasen als de punt van het hoofd repository in de tussentijd verschoven is en je commits niet langer netjes toegepast kunnen worden. Bijvoorbeeld, als je een tweede onderwerp wil bijdragen aan een project, ga dan niet verder werken op de topic branch die je zojuist gepushed hebt - begin opnieuw vanaf de `master` branch van het hoofd repository:
+Bij een project waarvan je niet de beheerder bent, is het over het algemeen eenvoudiger om een branch zoals `master` altijd de `origin/master` te laten volgen, en je werk te doen in topic branches die je eenvoudig weg kunt gooien als ze geweigerd worden. Als je je werkthema's gescheiden houdt in topic branches maakt dat het ook eenvoudiger voor jou om je werk te rebasen als de punt van het hoofd repository in de tussentijd verschoven is en je commits niet langer netjes toegepast kunnen worden. Bijvoorbeeld, als je een tweede onderwerp wilt bijdragen aan een project, ga dan niet verder werken op de topic branch die je zojuist gepushed hebt - begin opnieuw vanaf de `master` branch van het hoofd repository:
 
 	$ git checkout -b featureB origin/master
 	$ (work)
@@ -439,12 +439,12 @@ Bij een project waarvan je niet de beheerder bent, is het over het algemeen eenv
 	$ (email maintainer)
 	$ git fetch origin
 
-Nu zijn al je onderwerpen opgeslagen in een silo - vergelijkbaar met een patch rij - die je kunt herschrijven, rebasen en wijzigen zonder dat de onderwerpen elkaar be�nvloeden of van elkaar afhankelijk zijn zoals in Figuur 5-16.
+Nu zijn al je onderwerpen opgeslagen in een silo - vergelijkbaar met een patch reeks (queue) - die je kunt herschrijven, rebasen en wijzigen zonder dat de onderwerpen elkaar be�nvloeden of van elkaar afhankelijk zijn zoals in Figuur 5-16.
 
 Insert 18333fig0516.png
 Figuur 5-16. Initi�le commit historie met werk van featureB.
 
-Stel dat de project beheerder een berg andere patches binnengehaald heeft en je eerste branch geprobeerd heeft, maar dat die niet langer netjes merged. In dat geval kun je proberen die branch te rebasen op de punt van `origin/master`, de conflicten op te lossen voor de beheerder, en dan je wijzigingen opnieuw aanbieden:
+Stel dat de project beheerder een verzameling andere patches binnengehaald heeft en jouw eerste branch geprobeerd heeft, maar dat die niet meer netjes merged. In dat geval kun je proberen die branch te rebasen op de punt van `origin/master`, de conflicten op te lossen voor de beheerder, en dan je wijzigingen opnieuw aanbieden:
 
 	$ git checkout featureA
 	$ git rebase origin/master
@@ -457,7 +457,7 @@ Figuur 5-17. Commit historie na werk van featureA.
 
 Omdat je de branch gerebased hebt, moet je de `-f` specificeren met je push commando om in staat te zijn de `featureA` branch op de server te vervangen met een commit die er geen afstammeling van is. Een alternatief zou zijn dit nieuwe werk naar een andere branch op de server te pushen (misschien `featureAv2` genaamd).
 
-Laten we eens kijken naar nog een mogelijk scenario: de beheerder heeft je werk bekeken in je tweede branch en vind het concept goed, maar zou willen dat je een implementatie detail verandert. Je zult deze gelegenheid ook gebruiken om het werk te baeren op de huidige `master` branch van het project. Je begint een nieuwe branch gebaseerd op de huidige `origin/master` branch, squashed de `featureB` wijzigingen er naartoe, lost conflicten op, doet de implementatie wijziging, en zet dat terug als een nieuwe branch:
+Laten we eens kijken naar nog een mogelijk scenario: de beheerder heeft je werk bekeken in je tweede branch en vind het concept goed, maar zou willen dat je een implementatie detail verandert. Je moet deze gelegenheid meteen gebruiken om het werk te baseren op de huidige `master` branch van het project. Je begint een nieuwe branch gebaseerd op de huidige `origin/master` branch, squashed de `featureB` wijzigingen er naartoe, lost conflicten op, doet de implementatie wijziging en pushed deze terug als een nieuwe branch:
 
 	$ git checkout -b featureBv2 origin/master
 	$ git merge --no-commit --squash featureB
@@ -474,9 +474,9 @@ Figuur 5-18. Commit historie na het featureBv2 werk.
 
 ### Openbaar groot project ###
 
-Veel grote projecten hebben vastgestelde procedures voor het accepteren van patches - je zult de specifieke regels voor ieder project goed moeten bekijken, omdat ze zullen verschillen. Maar, veel grote projecten accepteren patches via ontwikkelaar maillijsten, dus ik zal zo'n voorbeeld nu laten zien.
+Veel grote projecten hebben vastgestelde procedures voor het accepteren van patches - je zult de specifieke regels voor ieder project goed moeten bekijken, omdat ze verschillend zullen zijn. Veel grote projecten accepteren patches veelal via ontwikkelaar maillijsten, daarom zal ik zo'n voorbeeld nu laten zien.
 
-De werkwijze is vergelijkbaar met het vorige geval - je maakt topic branches voor iedere patch waar je aan werkt. Het verschil is hoe je die aanlevert bij het project. In plaats van het project te forken en naar je eigen schrijfbare versie te pushen, genereer je e-mail versies van iedere commit serie en mailt die naar de ontwikkelaar maillijst:
+De werkwijze is vergelijkbaar met het vorige geval - je maakt topic branches voor iedere patch waar je aan werkt. Het verschil is hoe je die aanlevert bij het project. In plaats van het project te forken en naar je eigen schrijfbare versie te pushen, genereer je e-mail versies van iedere reeks commits en mailt die naar de ontwikkelaar maillijst:
 
 	$ git checkout -b topicA
 	$ (work)
@@ -484,7 +484,7 @@ De werkwijze is vergelijkbaar met het vorige geval - je maakt topic branches voo
 	$ (work)
 	$ git commit
 
-Nu heb je twee commits die je wil sturen naar de maillijst. Je gebruikt `git format-patch` om de mbox-geformatteerde bestanden te genereren, die je kunt e-mailen naar de lijst. Dit vormt iedere commit om naar een e-mail bericht met de eerste regel van het commit bericht als de onderwerp regel, en de rest van het bericht plus de patch die door de commit wordt ge�ntroduceerd als de inhoud. Het prettige hieraan is dat het toepassen van een patch uit een mail die gegenereerd is met `format-patch` alle commit informatie goed behoudt, zoals je in de volgende paragraaf meer zult zien als je deze commits toepast:
+Nu heb je twee commits die je wil sturen naar de maillijst. Je gebruikt `git format-patch` om de mbox-geformatteerde bestanden te genereren die je kunt mailen naar de lijst. Dit vormt iedere commit om naar een e-mail bericht met de eerste regel van het commit bericht als de onderwerp regel, en de rest van het bericht plus de patch die door de commit wordt ge�ntroduceerd als de inhoud. Het prettige hieraan is dat met het toepassen van een patch uit een mail die gegenereerd is met `format-patch` alle commit informatie blijft behouden. In de volgende paragraaf zal je hiervan meer zien, als je deze commits gaat toepassen:
 
 	$ git format-patch -M origin/master
 	0001-add-limit-to-log-function.patch
@@ -520,11 +520,11 @@ Het `format-patch` commando drukt de namen af van de patch bestanden die het maa
 	--
 	1.6.2.rc1.20.g8c5b.dirty
 
-Je kunt deze patch bestanden ook aanpassen om meer informatie voor de maillijst toe te voegen, die je niet in het commit bericht wil laten verschijnen. Als je tekst toevoegt tussen de `---` regel en het begin van de patch (de `lib/simplegit.rb` regel), dan kunnen ontwikkelaars dit lezen, maar tijdens het toepassen van de patch wordt dit weggelaten.
+Je kunt deze patch bestanden ook aanpassen om meer informatie, die je niet in het commit bericht wil laten verschijnen, voor de maillijst toe te voegen . Als je tekst toevoegt tussen de `---` regel en het begin van de patch (de `lib/simplegit.rb` regel), dan kunnen ontwikkelaars dit lezen, maar tijdens het toepassen van de patch wordt dit weggelaten.
 
-Om dit te mailen naar een maillijst, kun je het bestand in je mail applicatie plakken of het sturen via een commandoregel programma. Het plakken van de tekst veroorzaakt vaak formaterings problemen, in het bijzonder bij "slimmere" clients die geen newlines en andere witruimte juist behouden. Gelukkig levert Git een gereedschap die je helpt om juist geformatteerde patches via IMAP te versturen, wat makkelijker voor je kan zijn. Ik zal zal je laten zien hoe je een patch via Gmail stuurt, wat de mail applicatie is die ik gebruik. Je kunt gedetailleerde instructies voor een aantal mail programma's vinden aan het eind van het voornoemde `Documentation/SubmittingPatches` bestand in de Git broncode.
+Om dit te mailen naar een maillijst, kun je het bestand in je mail applicatie plakken of het sturen via een commandoregel programma. Het plakken van de tekst veroorzaakt vaak formaterings problemen, in het bijzonder bij "slimmere" clients die de newlines en andere witruimte niet juist behouden. Gelukkig levert Git een gereedschap die je helpt om juist geformatteerde patches via IMAP te versturen, wat het alweer een stuk makkelijker voor je maakt. Ik zal zal je laten zien hoe je een patch via Gmail stuurt, wat de mail applicatie is die ik toevallig gebruik. Je kunt gedetailleerde instructies voor een aantal mail programma's vinden aan het eind van het voornoemde `Documentation/SubmittingPatches` bestand in de Git broncode.
 
-Eerst moet je de imap sectie in je `~/.gitconfig` bestand instellen. Je kunt iedere waarde apart instellen met een serie `git config` commando's, of je kunt ze handmatig toevoegen; maar op het eind moet je config bestand er ongeveer zo uitzien:
+Eerst moet je de imap sectie in je `~/.gitconfig` bestand instellen. Je kunt iedere waarde apart instellen met een serie `git config` commando's, of je kunt ze handmatig toevoegen, maar uiteindelijk moet je config bestand er ongeveer zo uitzien:
 
 	[imap]
 	  folder = "[Gmail]/Drafts"
@@ -544,7 +544,7 @@ Als dat ingesteld is, kun je `git send-email` gebruiken om de patch reeks in de
 	sending 2 messages
 	100% (2/2) done
 
-Nu kan je naar je Drafts folder gaan, het To veld te wijzigen naar de maillijst waar je de patch naartoe stuurt en mogelijk de beheerder of verantwoordelijke voor dat deel in de CC zetten en dan versturen.
+Nu kan je naar die Drafts folder gaan, het To veld te wijzigen naar de maillijst waar je de patch naartoe stuurt en misschien de beheerder of verantwoordelijke voor dat deel in de CC zetten en dan versturen.
 
 Je kunt de patches ook via een SMTP server sturen. Zoals eerder kan je elke waarde apart instellen met een serie `git config` commando's, of je kunt ze handmatig in de sendmail sectie in je `~/.gitconfig` bestand zetten:
 
@@ -554,7 +554,7 @@ Je kunt de patches ook via een SMTP server sturen. Zoals eerder kan je elke waar
 	  smtpuser = user@gmail.com
 	  smtpserverport = 587
 
-Als dit gebeurt is, kan je `git send-email` gebruiken om je patches te sturen:
+Als dit gebeurd is, kan je `git send-email` gebruiken om je patches te sturen:
 
 	$ git send-email *.patch
 	0001-added-limit-to-log-function.patch
@@ -564,7 +564,7 @@ Als dit gebeurt is, kan je `git send-email` gebruiken om je patches te sturen:
 	Who should the emails be sent to? jessica@example.com
 	Message-ID to be used as In-Reply-To for the first email? y
 
-Dan spuuwt Git een bergje log-informatie uit voor iedere patch die je stuurt, en dat ziet er ongeveer zo uit:
+Dan spuuwt Git een bergje log-informatie uit voor elke patch die je stuurt, wat er ongeveer zo uitziet:
 
 	(mbox) Adding cc: Jessica Smith <jessica@example.com> from
 	  \line 'From: Jessica Smith <jessica@example.com>'
@@ -583,15 +583,15 @@ Dan spuuwt Git een bergje log-informatie uit voor iedere patch die je stuurt, en
 
 ### Samenvatting ###
 
-In dit hoofdstuk is een aantal veel voorkomende werkwijzen behandeld, die je kunt gebruiken om te kunnen werken in een aantal zeer verschillende typen Git projecten die je misschien zult tegenkomen en een aantal nieuwe gereedschappen ge�ntroduceerd, die je helpen om dit proces te beheren. Wat hierna volgt zal je laten zien hoe je aan de andere kant van de medaille werkt: een Git project beheren. Je zult leren hoe een welwillende dictator of integratie manager te zijn.
+In dit hoofdstuk is een aantal veel voorkomende werkwijzen behandeld, die je kunt gebruiken om te kunnen werken in een aantal zeer verschillende typen Git projecten die je misschien zult tegenkomen, en een aantal nieuwe gereedschappen ge�ntroduceerd die je helpen om dit proces te beheren. Wat hierna volgt zal je laten zien hoe je aan de andere kant van de tafel werkt: een Git project beheren. Je zult leren hoe een welwillende dictator of integratie manager te zijn.
 
 ## Het beheren van een project ##
 
-Naast weten hoe effectief bij te dragen aan een project, moet je waarschijnlijk ook moeten weten hoe je er een beheert. Dit kan bestaan uit het accepteren en toepassen van patches die met `format-patch` gemaakt en naar je gemaild zijn, of het integreren van wijzigingen in de remote branches van repositories die je hebt toegevoegd als remotes van je project. Of je nu een canonieke repository beheert, of wilt bijdragen door het controleren of goedkeuren van patches, je moet weten hoe werk te ontvangen op een dusdanige manier die het duidelijkst is voor andere bijdragers en voor jou op langere termijn vol te houden.
+Naast weten hoe effectief bij te dragen aan een project, moet je waarschijnlijk ook moeten weten hoe je er een beheert. Dit kan bestaan uit het accepteren en toepassen van patches die met `format-patch` gemaakt en naar je gemaild zijn, of het integreren van wijzigingen in de remote branches van repositories die je hebt toegevoegd als remotes van je project. Of je nu een canonieke repository beheert, of wilt bijdragen door het controleren of goedkeuren van patches, je moet weten hoe werk te ontvangen op een zodanige manier die het duidelijkst is voor andere bijdragers en voor jou op langere termijn vol te houden.
 
 ### Werken in topic branches ###
 
-Als je overweegt om nieuw werk te integreren, is het over het algemeen een goed idee om het uit te proberen in een topic branch - een tijdelijke branch, speciaal gemaakt om dat nieuwe werk uit te proberen. Op deze manier is het handig om een patch individueel te behandelen en het even opzij te zetten als het niet werkt, totdat je tijd hebt om er op terug te komen. Als je een eenvoudige branchnaam maakt, gebaseerd op het onderwerp van het werk dat je aan het proberen bent, bijvoorbeeld `ruby_client` of zoiets beschrijvends, dan is het makkelijk om te herinneren als je het voor een tijdje moet achterlaten en er later op terug komt. De beheerder van het Git project heeft de neiging om deze branches ook van een naamsruimte (namespace) te voorzien - zoals `sc/ruby_client`, waarbij `sc` een afkorting is van de persoon die het werk heeft bijgedragen.
+Als je overweegt om nieuw werk te integreren, is het over het algemeen een goed idee om het uit te proberen in een topic branch - een tijdelijke branch, speciaal gemaakt om dat nieuwe werk uit te proberen. Op deze manier is het handig om een patch individueel te behandelen en het even opzij te zetten als het niet werkt, totdat je tijd hebt om er op terug te komen. Als je een eenvoudige branchnaam maakt, gebaseerd op het onderwerp van het werk dat je aan het proberen bent, bijvoorbeeld `ruby_client` of zoiets beschrijvends, dan is het makkelijk om te herinneren als je het voor een tijdje opzij moet leggen en er later op terug komt. De beheerder van het Git project heeft de neiging om deze branches ook van een naamsruimte (namespace) te voorzien - zoals `sc/ruby_client`, waarbij `sc` een afkorting is van de persoon die het werk heeft bijgedragen.
 Zoals je je zult herinneren, kun je de branch gebaseerd op je master branch zo maken:
 
 	$ git branch sc/ruby_client master
@@ -604,7 +604,7 @@ Nu ben je klaar om het bijgedragen werk in deze topic branch toe te voegen, en t
 
 ### Patches uit e-mail toepassen ###
 
-Als je een patch per e-mail ontvangt, die je moet integreren in je project, moet je de patch in je onderwerp branch toepassen om het te evalueren. Er zijn twee manieren om een ge-mailde patch toe te passen: met `git apply` of met `git am`.
+Als je een patch per e-mail ontvangt, en je moet die integreren in je project, moet je de patch in je topic branch toepassen om het te evalueren. Er zijn twee manieren om een ge-mailde patch toe te passen: met `git apply` of met `git am`.
 
 #### Een patch toepassen met apply ####
 
@@ -612,21 +612,21 @@ Als je de patch ontvangen hebt van iemand die het gegenereerd heeft met de `git
 
 	$ git apply /tmp/patch-ruby-client.patch
 
-Dit wijzigt de bestanden in je werk directory. Het is vrijwel gelijk aan het uitvoeren van een `patch -p1` commando om de patch toe te passen, alhoewel het meer parano�de is en minder fuzzy matches accepteert dan patch. Het handelt ook bestandstoevoegingen af, -verwijderingen, en hernoemingen als ze beschreven staan in het `git diff` formaat, wat `patch` niet doet. Als laatste volgt `git apply` een "pas alles toe of laat alles weg" model, waarbij alles of niets wordt toegepast, en `patch` gedeeltelijke patches kan toepassen, waardoor je werk directory in een vreemde status achterblijft. `git apply` is over het algemeen meer parano�de dan `patch`. Het zal geen commit voor je aanmaken - na het uitgevoerd te zijn, je moet de ge�ntroduceerde wijzigingen handmatig stagen en committen.
+Dit wijzigt de bestanden in je werk directory. Het is vrijwel gelijk aan het uitvoeren van een `patch -p1` commando om de patch toe te passen, alhoewel het meer parano�de is en minder "fuzzy matches" accepteert dan patch. Het handelt ook bestandstoevoegingen af, -verwijderingen, en hernoemingen als ze beschreven staan in het `git diff` formaat, wat `patch` niet doet. Als laatste volgt `git apply` een "pas alles toe of laat alles weg" model waarbij alles of niets wordt toegepast. Dit in tegenstelling tot `patch` die gedeeltelijke patches kan toepassen, waardoor je werk directory in een vreemde status achterblijft. Over het algemeen is `git apply` meer parano�de dan `patch`. Het zal geen commit voor je aanmaken; na het uitvoeren moet je de ge�ntroduceerde wijzigingen handmatig stagen en committen.
 
-Je kunt ook git apply gebruiken om te zien of een patch netjes wordt toepast voordat je het echt toepast - je kunt `git apply --check` uitvoeren met de patch:
+Je kunt ook git apply gebruiken om te zien of een patch netjes kan worden toepast voordat je het echt doet; je kunt `git apply --check` uitvoeren met de patch:
 
 	$ git apply --check 0001-seeing-if-this-helps-the-gem.patch
 	error: patch failed: ticgit.gemspec:1
 	error: ticgit.gemspec: patch does not apply
 
-Als er geen uitvoer is, dan zou de patch netjes moeten passen. Dit commando eindigt ook met een niet-nul status als de controle faalt, zodat je het kunt gebruiken in scripts als je dat wilt.
+Als er geen uitvoer is, dan zou de patch netjes moeten passen. Dit commando retourneert ook een niet-nul status als de controle faalt, zodat je het kunt gebruiken in scripts als je dat zou willen.
 
 #### Een patch met am toepassen ####
 
-Als de bijdrager een Git gebruiker is en zo vriendelijk was om het `format-patch` commando te gebruiken om hun patch te genereren, dan is je werk eenvoudiger omdat de patch de auteur informatie en een commit bericht voor je bevat. Als je kunt, moedig je bijdragers aan om `format-patch` te gebruiken in plaats van `diff` om patches te genereren voor je. Je zou alleen `git apply` hoeven te gebruiken voor oude patches en dat soort dingen.
+Als de bijdrager een Git gebruiker is en zo vriendelijk is geweest om het `format-patch` commando te gebruiken om de patch te genereren, dan is je werk eenvoudiger omdat de patch de auteur informatie en een commit bericht voor je bevat. Als het enigzins kan, probeer dan je bijdragers aan te moedigen om `format-patch` te gebruiken in plaats van `diff` om patches te genereren voor je. Je zou alleen `git apply` willen hoeven te gebruiken voor oude patches en dat soort dingen.
 
-Om een patch gegenereerd met `format-patch` toe te passen, gebruik je `git am`. Technisch is `git am` gemaakt om een mbox bestand te lezen, dat een eenvoudig gewone platte tekstformaat is om ��n of meer e-mail berichten in een tekst bestand op te slaan. Het ziet er ongeveer zo uit:
+Om een patch gegenereerd met `format-patch` toe te passen, gebruik je `git am`. Technisch is `git am` gemaakt om een mbox bestand te lezen, dat een eenvoudig gewone platte tekstformaat is om ��n of meer e-mail berichten in een tekstbestand op te slaan. Het ziet er ongeveer zo uit:
 
 	From 330090432754092d704da8e76ca5c05c198e71a8 Mon Sep 17 00:00:00 2001
 	From: Jessica Smith <jessica@example.com>
@@ -635,14 +635,14 @@ Om een patch gegenereerd met `format-patch` toe te passen, gebruik je `git am`.
 
 	Limit log functionality to the first 20
 
-Dit is het begin van de uitvoer van het format-patch commando dat je gezien hebt in de vorige paragraaf. Dit is ook een geldig mbox e-mail formaat. Als iemand jou de patch correct gemaild heeft door gebruik te maken van git send-email en je downloadt dat in een mbox formaat, dan kan je het git am naar dat mbox bestand verwijzen, en het zal beginnen met alle patches die het ziet toe te passen. Als je een mail client gebruikt die meerdere e-mails kan opslaan in mbox formaat, dan kun je hele patch series in een bestand opslaan en dan git am gebruiken om ze een voor een toe te passen.
+Dit is het begin van de uitvoer van het format-patch commando dat je gezien hebt in de vorige paragraaf. Dit is ook een geldig mbox e-mail formaat. Als iemand jou de patch correct gemaild heeft door gebruik te maken van git send-email en je downloadt dat in een mbox formaat, dan kan je het git am naar dat mbox bestand verwijzen, en het zal beginnen met alle patches die het tegenkomt toe te passen. Als je een mail client gebruikt die meerdere e-mails kan opslaan in mbox formaat, dan kun je hele reeksen patches in een bestand opslaan en dan git am gebruiken om ze ��n voor ��n toe te passen.
 
-Maar, als iemand een patch bestand heeft ge-upload die gegenereerd is met `format-patch` naar een ticket systeem of zoiets, kun je het bestand lokaal opslaan en dan dat opgeslagen bestand aan `git am` doorgeven om het toe te passen:
+Maar, als iemand een patch bestand heeft ge�pload die gegenereerd is met `format-patch` naar een ticket systeem of zoiets, kun je het bestand lokaal opslaan en dan dat opgeslagen bestand aan `git am` doorgeven om het toe te passen:
 
 	$ git am 0001-limit-log-function.patch
 	Applying: add limit to log function
 
-Je kunt zien dat het netjes is toegepast, en automatisch een nieuwe commit voor je heeft aangemaakt. De auteursinformatie wordt gehaald uit de `From` en `Date` velden in de kop, en het bericht van de commit wordt gehaald uit de `Subject` en inhoud (voor de patch) van het mail bericht. Bijvoorbeeld, als deze patch was toegepast van het mbox voorbeeld dat ik zojuist getoond heb, dan zou de gegenereerde commit er ongeveer zo uit zien:
+Je ziet dat het netjes is toegepast, en automatisch een nieuwe commit voor je heeft aangemaakt. De auteursinformatie wordt gehaald uit de `From` en `Date` velden in de kop, en het bericht van de commit wordt gehaald uit de `Subject` en de inhoud (voor de patch) uit het mailbericht zelf. Bijvoorbeeld, als deze patch was toegepast van het mbox voorbeeld dat ik zojuist getoond heb, dan zou de gegenereerde commit er ongeveer zo uit zien:
 
 	$ git log --pretty=fuller -1
 	commit 6c5e70b984a60b3cecd395edd5b48a7575bf58e0
@@ -655,9 +655,9 @@ Je kunt zien dat het netjes is toegepast, en automatisch een nieuwe commit voor
 
 	   Limit log functionality to the first 20
 
-De `Commit` informatie laat de persoon die de patch toepaste en de tijd waarop het is toegepast zien. De `Author` informatie het individu die de patch oorspronkelijk gemaakt heeft en wanneer het gemaakt is.
+De `Commit` informatie toont de persoon die de patch toepaste en de tijd waarop het is toegepast. De `Author` informatie de persoon die de patch oorspronkelijk gemaakt heeft en wanneer het gemaakt is.
 
-Maar het is mogelijk dat de patch niet netjes toegepast kan worden. Misschien is je hoofdbranch te ver afgeweken van de branch waarop de patch gebouwd is, of is de patch van een andere patch, die je nog niet hebt toegepast, afhankelijk. In dat geval zal het `git am` proces falen en je vragen wat je wilt doen:
+Maar het is mogelijk dat de patch niet netjes toegepast kan worden. Misschien is jouw hoofdbranch te ver afgeweken van de branch waarop de patch gebouwd is, of is de patch afhankelijk van een andere patch, die je nog niet hebt toegepast. In dat geval zal het `git am` proces falen en je vragen wat je wilt doen:
 
 	$ git am 0001-seeing-if-this-helps-the-gem.patch
 	Applying: seeing if this helps the gem
@@ -668,14 +668,14 @@ Maar het is mogelijk dat de patch niet netjes toegepast kan worden. Misschien is
 	If you would prefer to skip this patch, instead run "git am --skip".
 	To restore the original branch and stop patching run "git am --abort".
 
-Dit commando stopt conflict markeringen in alle bestanden waar het problemen mee heeft, net zoals een conflicterende merge of rebase operatie. Je lost dit probleem op een vergelijkbare manier op - wijzig het bestand om het conflict op te lossen, stage het bestand, en voer dan `git am --resolved` uit om door te gaan met de volgende patch:
+Dit commando zet conflict markeringen in alle bestanden waar het problemen mee heeft, net zoals een conflicterende merge of rebase operatie. Je lost dit probleem op een vergelijkbare manier op: wijzig het bestand om het conflict op te lossen, stage het bestand en voer dan `git am --resolved` uit om door te gaan met de volgende patch:
 
 	$ (fix the file)
 	$ git add ticgit.gemspec
 	$ git am --resolved
 	Applying: seeing if this helps the gem
 
-Als je wil dat Git een beetje meer intelligentie toepast om het conflict op te lossen, kun je een `-3` optie eraan meegeven, wat ervoor zorgt dat Git een driewegs-merge probeert. Deze optie staat standaard niet aan, omdat het niet werkt als de commit waarvan de patch zegt dat het op gebaseerd is niet in je repository zit. Als je die commit wel hebt - als de patch gebaseerd was op een publieke commit - dan is de `-3` over het algemeen veel slimmer in het toepassen van een conflicterende patch:
+Als je wil dat Git iets meer intelligentie toepast om het conflict op te lossen, kun je een `-3` optie eraan meegeven, dit zorgt ervoor dat Git een driewegs-merge probeert. Deze optie staat standaard niet aan omdat het niet werkt als de commit waarvan de patch zegt dat het op gebaseerd is niet in je repository zit. Als je die commit wel hebt - als de patch gebaseerd was op een publieke commit - dan is de `-3` over het algemeen veel slimmer in het toepassen van een conflicterende patch:
 
 	$ git am -3 0001-seeing-if-this-helps-the-gem.patch
 	Applying: seeing if this helps the gem
@@ -696,23 +696,23 @@ Als je een aantal patches van een mbox toepast, kun je ook het `am` commando in
 	--------------------------
 	Apply? [y]es/[n]o/[e]dit/[v]iew patch/[a]ccept all
 
-Dit is prettig als je een aantal patches bewaard hebt, omdat je de patch eerst kunt zien als je je niet kunt herinneren wat het is, of de patch niet wilt toepassen als je dat al gedaan hebt.
+Dit is prettig als je een aantal patches bewaard hebt, omdat je de patch eerst kunt zien als je je niet kunt herinneren wat het is, of de patch niet wilt toepassen omdat je dat al eerder gedaan hebt.
 
-Als alle patches voor je topic branch zijn toegepast en gecommit zijn op je branch, kun je kiezen of en hoe ze te integreren in een branch met een langere looptijd.
+Als alle patches voor je topic branch zijn toegepast en gecommit zijn op je branch, kan je besluiten of en hoe ze te integreren in een branch met een langere looptijd.
 
 ### Remote branches uitchecken ###
 
-Als je bijdrage van een Git gebruiker komt, die zijn eigen repository opgezet heeft, een aantal patches daarin gepushed heeft, en jou de URL naar de repository gestuurd heeft en de naam van de remote branch waarin de wijzigingen zitten, kan je ze toevoegen als een remote en het mergen lokaal doen.
+Als je bijdrage van een Git gebruiker komt die zijn eigen repository opgezet heeft, een aantal patches daarin gepushed heeft, en jou de URL naar de repository gestuurd heeft en de naam van de remote branch waarin de wijzigingen zitten, kan je ze toevoegen als een remote en het mergen lokaal doen.
 
-Bijvoorbeeld, als Jessica je een e-mail stuurt waarin staat dat ze een mooie nieuw feature in de `ruby-client` branch van haar repository heeft, kun je het testen door de remote toe te voegen en die branch lokaal te bekijken:
+Bijvoorbeeld, als Jessica je een e-mail stuurt waarin staat dat ze een prachtig mooie nieuwe feature in de `ruby-client` branch van haar repository heeft, kun je deze testen door de remote toe te voegen en die branch lokaal te bekijken:
 
 	$ git remote add jessica git://github.com/jessica/myproject.git
 	$ git fetch jessica
 	$ git checkout -b rubyclient jessica/ruby-client
 
-Als ze je later opnieuw e-mailt met een andere branch die een andere mooie feature bevat, dan kun je die ophalen en bekijken omdat je de remote al ingesteld hebt.
+Als ze je later opnieuw mailt met een andere branch die weer een andere mooie feature bevat, dan kun je die ophalen en bekijken omdat je de remote al ingesteld hebt.
 
-Dit is meest nuttig als je vaak met een persoon werkt. Als iemand een enkele patch eens in de zoveel tijd bij te dragen heeft, dan is het accepteren per e-mail misschien minder tijdrovend dan eisen dat iedereen hun eigen server moet draaien en doorlopend remotes toevoegen en verwijderen om een paar patches te krijgen. Je zult waarschijnlijk ook niet honderden remotes willen hebben, elk voor iemand die maar een patch of twee bijdraagt. Aan de andere kant, scripts en gehoste diensten maken dit misschien makkelijker - het hangt veel af van hoe jij ontwikkelt en hoe je bijdragers ontwikkelen.
+Dit is meest practisch als je vaak met een persoon werkt. Als iemand een enkele patch eens in de zoveel tijd bij te dragen heeft, dan is het accepteren per mail misschien minder tijdrovend dan te eisen dat iedereen hun eigen server moet beheren, en daarna voortdurend remotes te moeten toevoegen en verwijderen voor die paar patches. Je zult daarbij waarschijnlijk ook niet honderden remotes willen hebben, elk voor iemand die maar een patch of twee bijdraagt. Aan de andere kant, scripts en gehoste diensten maken het wellicht eenvoudiger; het hangt sterk af van de manier waarop ontwikkelt en hoe je bijdragers ontwikkelen.
 
 Het andere voordeel van deze aanpak is dat je de historie van de commits ook krijgt. Alhoewel je misschien terechte merge problemen hebt, weet je op welk punt in de historie hun werk is gebaseerd; een echte drieweg merge is de standaard in plaats van een `-3` te moeten meegeven en hopen dat de patch gegenereerd was van een publieke commit waar je toegang toe hebt.
 
@@ -725,9 +725,9 @@ Als je maar af en toe met een persoon werkt, maar toch op deze manier van hen wi
 
 ### Bepalen wat ge�ntroduceerd wordt ###
 
-Je hebt een topic branch dat bijgedragen werk bevat. Nu kan je bepalen wat je er mee wilt doen. Deze paragraaf bekijkt een paar commando's opnieuw om te laten zien hoe je ze kunt gebruiken om precies te reviewen wat je zult introduceren als je dit merged in je hoofd branch.
+Je hebt een topic branch dat bijgedragen werk bevat. Nu kan je bepalen wat je er mee wilt doen. Deze paragraaf bekijkt een paar commando's nogmaals om te laten zien hoe je ze kunt gebruiken om precies te reviewen wat je zult introduceren als je dit merged in je hoofd branch.
 
-Het is vaak behulpzaam om een review te krijgen van alle commits die in deze branch zitten, maar die niet in je master branch zitten. Je kunt commits weglaten in de master branch door de `--not` optie mee te geven voor de branch naam. Bijvoorbeeld, als je bijdrager je twee patches stuurt en je wil een branch genaamd `contrib` maken en die patches daar toepassen, dan kun je dit uitvoeren:
+Het is vaak handig om een review te krijgen van alle commits die in deze branch zitten, maar die niet in je master branch zitten. Je kunt commits weglaten die al in de master branch zitten door de `--not` optie mee te geven voor de branch naam. Bijvoorbeeld, als je bijdrager je twee patches stuurt, je hebt een branch genaamd `contrib` gemaakt en hebt die patches daar toegepast, dan kun je dit uitvoeren:
 
 	$ git log contrib --not master
 	commit 5b6235bd297351589efc4d73316f0a68d484f118
@@ -742,107 +742,107 @@ Het is vaak behulpzaam om een review te krijgen van alle commits die in deze bra
 
 	    updated the gemspec to hopefully work better
 
-Om te zien welke wijzigingen iedere commit introduceert, onthoud dan dat je de `-p` optie kunt meegeven aan `git log` en dan zal het de diff ge�ntroduceerd bij iedere commit weergeven.
+Om te zien welke wijzigingen door iedere commit worden ge�ntroduceert, onthoud dan dat je de `-p` optie kunt meegeven aan `git log` en dan zal het de diff weergeven die bij iedere commit wordt ge�ntroduceerd.
 
-Om een volledige diff te zien van wat zou gebeuren als je deze onderwerp branch samenvoegt met een andere branch, zul je misschien een vreemde truc moeten toepassen om de juiste resultaten te krijgen. Je zult misschien denken om dit uit te voeren:
+Om een volledige diff te zien van wat zou gebeuren als je deze topic branch merged met een andere branch, zul je misschien een vreemde truc moeten toepassen om de juiste resultaten te krijgen. Je zult misschien denken om dit uit te voeren:
 
 	$ git diff master
 
-Dit commando geeft je een diff, maar het zou misleidend kunnen zijn. Als je `master` branch vooruit geschoven is sinds je de onderwerp branch er vanaf hebt gebaseerd, dan zul je ogenschijnlijk vreemde resultaten krijgen. Bijvoorbeeld, als je een regel in een bestand hebt toegevoegd op de `master` branch, dan zal een directe vergelijking van de snapshots eruit zien alsof de onderwerp branch die regel gaat verwijderen.
+Dit commando geeft je een diff, maar het kan misleidend zijn. Als je `master` branch vooruit geschoven is sinds je de topic branch er vanaf hebt gemaakt, dan zul je ogenschijnlijk vreemde resultaten krijgen. Dit gebeurt omdat Git de snapshots van de laatste commit op de topic branch waar je op zit vergelijkt met het laatste snapshot van de `master` branch. Bijvoorbeeld, als je een regel in een bestand hebt toegevoegd op de `master` branch, dan zal een directe vergelijking van de snapshots eruit zien alsof de topic branch die regel gaat verwijderen.
 
-Als `master` een directe afstammeling is van je onderwerp branch, is dit geen probleem; maar als de twee histories uit elkaar zijn gegaan, zal de diff eruit zien alsof je alle nieuwe spullen in je onderwerp branch toevoegt en al het unieke weghaalt in de `master` branch.
+Als `master` een directe voorganger is van je topic branch is dit geen probleem, maar als de twee histories uit elkaar zijn gegaan, zal de diff eruit zien alsof je alle nieuwe spullen in je topic branch toevoegt en al hetgeen wat alleen in de `master` branch staat weghaalt.
 
-Wat je echt wil zien zijn de wijzigingen die in de onderwerp branch zijn toegevoegd - het werk dat je zult introduceren als je deze branch met master samenvoegt. Je doet dat door Git de laatste commit op je onderwerp branch te laten vergelijken met de eerste gezamenlijke voorouder die het heeft met de master branch.
+Wat je eigenlijk had willen zien zijn de wijzigingen die in de topic branch zijn toegevoegd: het werk dat je zult introduceren als je deze branch met master merged. Je doet dat door Git de laatste commit op je topic branch te laten vergelijken met de eerste gezamenlijke voorouder die het heeft met de master branch.
 
-Technisch, kun je dat doen door de gezamenlijke voorouder expliciet uit te zoeken en dan daar je diff op uit te voeren:
+Technisch, kun je dat doen door de gezamenlijke voorouder op te zoeken en dan daar je diff op uit te voeren:
 
 	$ git merge-base contrib master
 	36c7dba2c95e6bbb78dfa822519ecfec6e1ca649
 	$ git diff 36c7db
 
-Maar, dat is niet handig, dus levert Git een andere korte manier om hetzelfde te doen: de driedubbele punt syntax. In de context van het `diff` commando, kun je drie punten achter een andere branch zetten, om een `diff` te doen tussen de laatste commit van de branch waar je op zit en zijn gezamenlijke voorouder met een andere branch:
+Maar, dat is niet handig, dus levert Git een andere verkorte manier om hetzelfde te doen: de driedubbele punt syntax. In de context van het `diff` commando, kun je drie punten achter een andere branch zetten om een `diff` te doen tussen de laatste commit van de branch waar je op zit en de gezamenlijke voorouder met een andere branch:
 
 	$ git diff master...contrib
 
-Dit commando toont je alleen het werk dat je huidige onderwerp branch heeft ge�ntroduceerd sinds zijn gezamenlijke voorouder met master. Dat is een erg handige syntax om te onthouden.
+Dit commando laat alleen het werk zien dat je huidige topic branch heeft ge�ntroduceerd sinds de gezamenlijke voorouder met master. Dat is een erg handige syntax om te onthouden.
 
 ### Bijgedragen werk integreren ###
 
-Als al het werk in je onderwerp branch klaar is om te worden ge�ntegreerd in een meer hoofdlijn branch, dan is de vraag hoe het te doen. En daarna, welke algemene werkwijze wil je gebruiken om je project te onderhouden? Je hebt een aantal keuzes, dus ik zal er een paar behandelen.
+Als al het werk in je onderwerp branch klaar is om te worden ge�ntegreerd in een hogere branch, dan is de vraag hoe het te doen. En daarnaast, welke werkwijze wil je gebruiken om je project te beheren? Je hebt een aantal keuzes, dus ik zal er een paar behandelen.
 
-#### Samenvoeg werkwijzen ####
+#### Merge werkwijzen ####
 
-Een eenvoudige werkwijze voegt je werk in je `master` branch. In dit scenario, heb je een `master` branch die in feite stabiele code bevat. Als je werk in een onderwerp branch hebt dat jij gedaan hebt, of dat iemand anders heeft bijgedragen en jij hebt nagekeken, dan voeg je het in je master branch, verwijderd de onderwerp branch en vervolgt het proces. Als we een repository hebben met werk in twee branches genaamd `ruby_client` en `php_client`, dat eruit ziet zoals Figuur 5-19 en voegen `ruby_client` eerst in en vervolgens `php_client`, dan zal je historie er uit gaan zien zoals in Figuur 5-20.
+Een eenvoudige werkwijze merged je werk in de `master` branch. In dit scenario, heb je een `master` branch die feitelijk de stabiele code bevat. Als je werk in een topic branch hebt waaraan je gewerkt hebt, of dat iemand anders heeft bijgedragen en wat je hebt nagekeken, dan merge je het in de master branch, verwijdert de topic branch en vervolgt het proces. Als we een repository hebben met werk in twee branches genaamd `ruby_client` en `php_client`, wat eruit ziet zoals Figuur 5-19 en mergen eerst `ruby_client` en daarna `php_client`, dan zal je historie er uit gaan zien zoals in Figuur 5-20.
 
 Insert 18333fig0519.png
-Figuur 5-19. Historie met een aantal onderwerp branches.
+Figuur 5-19. Historie met een aantal topic branches.
 
 Insert 18333fig0520.png
-Figuur 5-20. Na het samenvoegen van een onderwerp branch.
+Figuur 5-20. Na het mergen van een topic branch.
 
-Dat is waarschijnlijk de eenvoudigste werkwijze, maar het is problematisch als je werkt met grotere repositories of projecten.
+Dat is waarschijnlijk de eenvoudigste werkwijze, maar het wordt problematisch als je werkt met grotere repositories of projecten.
 
-Als je meer ontwikkelaars hebt, of een groter project, dan zul je waarschijnlijk een minstens twee fasen samenvoeg cyclus willen gebruiken. In dit scenario, heb je twee langlopende branches, `master` en `develop`, waarin je bepaald dat `master` alleen vernieuwd wordt als een zeer stabiele vrijgave gedaan wordt en alle nieuwe code ge�ntegreerd is in de `develop` branch. Je zet beide branches regelmatig terug naar het publieke repository. Iedere keer als je een nieuw onderwerp branch hebt om samen te voegen (Figuur 5-21), voeg je het in `develop` (Figuur 5-22); daarna, als je een tag maakt van een vrijgave, dan doe je een fast-forward van `master` naar waar de nu stabiele `develop` branch is (Figuur 5-23).
+Als je meer ontwikkelaars hebt of een groter project, dan zul je waarschijnlijk minstens een twee-fasen merge cyclus willen toepassen. In dat geval heb je twee langlopende branches, `master` en `develop`, waarbij je bepaalt dat `master` alleen vernieuwd wordt als een zeer stabiele release is gemaakt en alle nieuwe code ge�ntegreerd is in de `develop` branch. Je pushed beide branches op regelmatige basis naar de publieke repository. Iedere keer als je een nieuw topic branch hebt om te mergen (Figuur 5-21), merge je het in `develop` (Figuur 5-22). En als je een tag gemaakt heb van een release, doe je een fast-forward van `master` naar waar de nu stabiele `develop` branch is (Figuur 5-23).
 
 Insert 18333fig0521.png
-Figuur 5-21. Voor een samenvoeging van een onderwerp branch.
+Figuur 5-21. Voor een merge van een topic branch.
 
 Insert 18333fig0522.png
-Figuur 5-22. Na een samenvoeging van een onderwerp branch.
+Figuur 5-22. Na een merge van een topic branch.
 
 Insert 18333fig0523.png
-Figuur 5-23. Na een vrijgave van een onderwerp branch.
+Figuur 5-23. Na een release van een topic branch.
 
-Als mensen het repository van je project op deze manier klonen, dan kunnen ze of master uit checken om de laatste stabiele versie te bouwen en die eenvoudig te kunnen bijhouden of ze kunnen develop uit checken, wat het nieuwere spul bevat.
-Je kunt dit concept ook doortrekken, waarbij je een integratie branch hebt waar al het werk samengevoegd wordt. Als de codebasis op die branch stabiel is en voor de testen slaagt, dan voeg je het in een develop branch; en als dat zichzelf een poosje stabiel heeft bewezen, dan fast-forward je je master branch.
+Op deze manier, als mensen de repository van je project klonen, dan kunnen ze kiezen om master uit checken en daarmee de laatste stabiele versie te bouwen en die eenvoudig up-to-date kunnen houden, of ze kunnen develop uit checken waar het nieuwere materiaal in staat.
+Je kunt dit concept ook verder doorvoeren, waarbij je een integratie branch hebt waar al het werk gemerged wordt. Als de codebasis op die branch stabiel is en de alle tests daar slagen, dan merge je het in een develop branch. Pas als het daar een periode stabiel is gebleken, dan fast-forward je de master branch.
 
-#### Werkwijzen met grote samenvoegingen ####
+#### Werkwijzen met grote merges ####
 
-Het Git project heeft vier langlopende branches: `master`, `next`, en `pu` (proposed updates, voorgestelde vernieuwingen), en `maint` voor onderhoudswerk. Als nieuw werk wordt ge�ntroduceerd door bijdragers, wordt het samengeraapt in onderwerp branches in het repository van de beheerder op een manier gelijk aan wat ik omschreven heb (zie Figuur 5-24). Op dit punt, worden de onderwerpen ge�valueerd om te bepalen of ze veilig zijn en klaar voor consumptie of dat ze nog wat werk nodig hebben. Als ze veilig zijn, worden ze in `next` samengevoegd, en wordt die branch teruggezet zodat iedereen de onderwerpen ge�ntegreerd kan proberen.
+Het Git project heeft vier langlopende branches: `master`, `next`, en `pu` (proposed updates, voorgestelde vernieuwingen) voor nieuw spul, en `maint` voor onderhoudswerk. Als nieuw werk wordt ge�ntroduceerd door bijdragers, wordt het samengeraapt in topic branches in de repository van de beheerder op een manier die lijkt op wat ik omschreven heb (zie Figuur 5-24). Hier worden de topics ge�valueerd om te bepalen of ze veilig zijn en klaar voor verdere verwerking of dat ze nog wat werk nodig hebben. Als ze veilig zijn, worden ze in `next` gemerged, en wordt die branch gepushed zodat iedereen de ge�ntegreerde topics kan uitproberen.
 
 Insert 18333fig0524.png
-Figuur 5-24. Een complexe serie van parallelle bijgedragen onderwerp branches beheren.
+Figuur 5-24. Een complexe serie van parallel bijgedragen topic branches beheren.
 
-Als de onderwerpen nog werk nodig hebben, dan worden ze in plaats daarvan samengevoegd in `pu`. Als bepaald wordt dat ze helemaal stabiel zijn, dan worden de onderwerpen opnieuw samengevoegd in `master` en worden dan herbouwd van de onderwerpen die in `next` waren, maar nog niet geslaagd waren voor `master`. Dit betekend dat `master` vrijwel altijd vooruit beweegt, `next` eens in de zoveel tijd gerebased wordt, en `pu` nog vaker gerebased wordt (zie Figuur 5-25).
+Als de topics nog werk nodig hebben, dan worden ze in plaats daarvan gemerged in `pu`. Zodra vastgesteld is dat ze helemaal stabiel zijn, dan worden de topics opnieuw gemerged in `master` en worden dan herbouwd van de topics die in `next` waren, maar nog niet gepromoveerd waren naar `master`. Dit betekent dat `master` vrijwel altijd vooruit beweegt, `next` eens in de zoveel tijd gerebased wordt, en `pu` nog vaker gerebased wordt (zie Figuur 5-25).
 
 Insert 18333fig0525.png
-Figuur 5-25. Bijgedragen onderwerp branches samenvoegen in langlopende integratie branches.
+Figuur 5-25. Bijgedragen topic branches mergen in langlopende integratie branches.
 
-Als een onderwerp branch uiteindelijk is samengevoegd in `master`, dan wordt het verwijderd van het repository. Het Git project heeft ook een `main` branch, die geforked is van de laatste vrijgave om teruggewerkte patches te leveren in het geval een onderhoudsvrijgave benodigd is. Dus, als je het Git repository kloont, dan heb je vier branches die je kunt uitchecken om het project in verschillende stadia van ontwikkeling te evalueren, afhankelijk van hoe nieuw je alles wilt hebben of hoe je wil bijdragen; en de beheerder heeft een gestructureerde werkwijze om ze te helpen nieuwe bijdragen aan de tand te voelen.
+Als een onderwerp branch uiteindelijk is gemerged in `master`, dan wordt het verwijderd van het repository. Het Git project heeft ook een `main` branch, die geforked is van de laatste release om teruggewerkte (backported) patches te leveren in het geval dat een onderhoudsrelease nodig is. Dus als je de Git repository kloont, dan heb je vier branches die je kunt uitchecken om het project in verschillende stadia van ontwikkeling te evalueren, afhankelijk van hoe nieuw je alles wilt hebben of hoe je wil bijdragen. En de beheerders hebben een gestructureerde werkwijze om ze te helpen nieuwe bijdragen aan de tand te voelen.
 
 #### Rebasen en cherry pick werkwijzen ####
 
-Andere beheerders geven de voorkeur aan rebasen of bijgedragen werk te cherry picken bovenop hun master branch, in plaats van het er in samen te voegen, om een lineaire historie te behouden. Als je werk in een onderwerp branch hebt en hebt besloten dat je het wil integreren, dan ga je naar die branch en voert het rebase commando uit om de wijzigingen bovenop je huidige master branch te bouwen (of `develop`, enzovoorts). Als dat goed werkt, dan kun je je `master` branch fast-forwarden, en dan eindig je met een lineaire project historie.
+Andere beheerders geven de voorkeur aan rebasen of bijgedragen werk te cherry picken naar hun master branch in plaats van ze erin te mergen, om een vrijwel lineaire historie te behouden. Als je werk in een topic branch hebt en hebt besloten dat je het wil integreren, dan ga je naar die branch en voert het rebase commando uit om de wijzigingen op je huidige master branch te baseren (of `develop`, enzovoorts). Als dat goed werkt, dan kun je de `master` branch fast-forwarden, en eindig je met een lineaire project historie.
 
-De andere manier om ge�ntroduceerd werk van de ene naar de andere branch te verplaatsen is om het te cherry picken. Een cherry-pick in Git is een soort rebase voor een enkele commit. Het pakt de patch die was ge�ntroduceerd in een commit en probeert die opnieuw toe te passen op de branch waar je nu op zit. Dit is handig als je een aantal commits op een onderwerp branch hebt en je er slechts ��n van wilt integreren, of als je alleen ��n commit op een onderwerp branch hebt en er de voorkeur aan geeft om het te cherry-picken in plaats van rebase uit te voeren. Bijvoorbeeld, stel dat je een project hebt dat eruit ziet als Figuur 5-26.
+De andere manier om ge�ntroduceerd werk van de ene naar de andere branch te verplaatsen is om het te cherry picken. Een cherry-pick in Git is een soort rebase voor een enkele commit. Het pakt de patch die was ge�ntroduceerd in een commit en probeert die weer toe te passen op de branch waar je nu op zit. Dit is handig als je een aantal commits op een topic branch hebt en je er slechts ��n van wilt integreren, of als je alleen ��n commit op een topic branch hebt en er de voorkeur aan geeft om het te cherry-picken in plaats van rebase uit te voeren. Bijvoorbeeld, stel dat je een project hebt dat eruit ziet als Figuur 5-26.
 
 Insert 18333fig0526.png
 Figuur 5-26. Voorbeeld historie voor een cherry pick.
 
-Als je commit `e43a6` in je master branch wil halen, dan kun je dit uitvoeren
+Als je commit `e43a6` in je master branch wilt pullen, dan kun je dit uitvoeren
 
 	$ git cherry-pick e43a6fd3e94888d76779ad79fb568ed180e5fcdf
 	Finished one cherry-pick.
 	[master]: created a0a41a9: "More friendly message when locking the index fails."
 	 3 files changed, 17 insertions(+), 3 deletions(-)
 
-Dit haalt dezelfde wijziging binnen als ge�ntroduceerd in `e43a6`, maar je krijgt een nieuwe SHA-1 waarde, omdat de gegevens op een andere manier toegepast zijn. Nu ziet je historie eruit als Figuur 5-27.
+Dit pulled dezelfde wijziging zoals ge�ntroduceerd in `e43a6`, maar je krijgt een nieuwe SHA-1 waarde, omdat de gegevens op een andere manier toegepast zijn. Nu ziet je historie eruit als Figuur 5-27.
 
 Insert 18333fig0527.png
-Figuur 5-27. Historie na het cherry-picken van een commit op een onderwerp branch.
+Figuur 5-27. Historie na het cherry-picken van een commit op een topic branch.
 
-Nu kun je je onderwerp branch verwijderen en de commits die je niet wou binnenhalen weggooien.
+Nu kun je de topic branch verwijderen en de commits die je niet wilde pullen weggooien.
 
-### Je vrijgaven taggen ###
+### Je releases taggen ###
 
-Als je hebt besloten om een vrijgave te doen, zul je waarschijnlijk een tag willen aanmaken zodat je die vrijgave op ieder punt in de toekomst kunt namaken. Je kunt een nieuwe tag maken zoals ik heb beschreven in Hoofdstuk 2. Als je besluit om de tag als de beheerder te signeren, dan ziet het taggen er misschien zo uit:
+Als je hebt besloten om een release te maken, zul je waarschijnlijk een tag willen aanmaken zodat je die release op elk moment in de toekomst kunt namaken. Je kunt een nieuwe tag maken zoals ik heb beschreven in Hoofdstuk 2. Als je besluit om de tag als de beheerder te signeren, dan ziet het taggen er misschien zo uit:
 
 	$ git tag -s v1.5 -m 'my signed 1.5 tag'
 	You need a passphrase to unlock the secret key for
 	user: "Scott Chacon <schacon@gmail.com>"
 	1024-bit DSA key, ID F721C45A, created 2009-02-09
 
-Als je je tags signeert, dan heb je misschien een problem om de publieke PGP sleutel te distribueren, die gebruikt is om de tags te signeren. De beheerder van het Git project heeft dit probleem opgelost door hun publieke sleutel als een blob in het repository mee te nemen en dan een tag toe te voegen die direct naar die inhoud wijst. Om dit te doen kun je uitvinden welke sleutel je wilt door `gpg --list-keys` uit te voeren:
+Als je tags signeert, dan heb je misschien een problem om de publieke PGP sleutel, die gebruikt is om de tags te signeren, te distribueren. De beheerder van het Git project heeft dit probleem opgelost door hun publieke sleutel als een blob in het repository mee te nemen en een tag te maken die direct naar die inhoud wijst. Om dit te doen kun je uitvinden welke sleutel je wilt door `gpg --list-keys` uit te voeren:
 
 	$ gpg --list-keys
 	/Users/schacon/.gnupg/pubring.gpg
@@ -851,7 +851,7 @@ Als je je tags signeert, dan heb je misschien een problem om de publieke PGP sle
 	uid                  Scott Chacon <schacon@gmail.com>
 	sub   2048g/45D02282 2009-02-09 [expires: 2010-02-09]
 
-Daarna kun je de sleutel direct in de Git gegevensbank importeren, door het te exporteren en om te leiden door `git hash-object`, wat een nieuwe blob schrijft in Git met die inhoud en je de SHA-1 van de blob teruggeeft:
+Daarna kun je de sleutel direct in de Git database importeren, door het te exporteren en te "pipen" naar `git hash-object`, wat een nieuwe blob schrijft in Git met die inhoud en je de SHA-1 van de blob teruggeeft:
 
 	$ gpg -a --export F721C45A | git hash-object -w --stdin
 	659ef797d181633c87ec71ac3f9ba29fe5775b92
@@ -860,40 +860,40 @@ Nu dat je de inhoud van je sleutel in Git hebt, kun je een tag aanmaken die dire
 
 	$ git tag -a maintainer-pgp-pub 659ef797d181633c87ec71ac3f9ba29fe5775b92
 
-Als je `git push --tags` uitvoert, zal de `maintainer-pgp-pub` tag met iedereen gedeeld worden. Als iemand een tag wil verifi�ren, dan kunnen ze je PGP sleutel direct importeren door de blob direct uit de gegevensbank te halen en het in GPG te importeren:
+Als je `git push --tags` uitvoert, zal de `maintainer-pgp-pub` tag met iedereen gedeeld worden. Als iemand een tag wil verifi�ren, dan kunnen ze jouw PGP sleutel direct importeren door de blob direct uit de database te halen en het in GPG te importeren:
 
 	$ git show maintainer-pgp-pub | gpg --import
 
-Ze kunnen die sleutel gebruiken om als je gesigneerde tags te verifi�ren. Als je de instructies in het tag bericht zet, dan zal `git show <tag>` je eindgebruikers meer specifieke instructies geven over tag verificatie.
+Ze kunnen die sleutel gebruiken om al je gesigneerde tags te verifi�ren. Als je instructies in het tag bericht zet, dan zal `git show <tag>` je eindgebruikers meer specifieke instructies geven over tag verificatie.
 
 ### Een bouw nummer genereren ###
 
-Omdat Git geen monotone oplopende nummers heeft zoals 'v123' of iets gelijkwaardigs om bij iedere commit mee te gaan, zul je als je een voor mensen leesbare naam wilt hebben bij een commit, `git describe` kunnen uitvoeren op die commit. Git geeft je de naam van de dichtstbijzijnde tag met het aantal commits bovenop die dag en een gedeeltelijke SHA-1 waarde van de commit die je omschrijft:
+Omdat Git geen monotone oplopende nummers heeft zoals 'v123' of iets gelijkwaardigs om bij iedere commit mee te worden genomen, en je een voor mensen leesbare naam wilt hebben bij een commit, kan je `git describe` uitvoeren op die commit. Git geeft je de naam van de dichtstbijzijnde tag met het aantal commits achter die tag en een gedeeltelijke SHA-1 waarde van de commit die je omschrijft:
 
 	$ git describe master
 	v1.6.2-rc1-20-g8c5b85c
 
-Op deze manier kun je een snapshot of bouw exporteren en het vernoemen naar iets dat begrijpelijk is voor mensen. In feite, als je Git vanaf broncode bouwt, gekloond van het Git repository, geeft `git --version` je iets dat er zo uitziet. Als je een commit omschrijft die je direct getagged wil hebben, dat geeft het je de tag naam.
+Op deze manier kun je een snapshot of "build" exporteren en het vernoemen naar iets dat begrijpelijk is voor mensen. Sterker nog: als je Git, gekloond van het Git repository, vanaf broncode bouwt geeft `git --version` je iets dat er zo uitziet. Als je een commit omschrijft die je direct getagged hebt, dan krijg je de tag naam.
 
-Het `git describe` commando heeft de voorkeur voor beschreven tags (tags gecre�erd met de `-a` of `-s` vlag), dus vrijgave tags zouden op deze manier aangemaakt moeten worden als je `git describe` gebruikt, om er zeker van te zijn dat de commit juist benoemd wordt als het omschreven wordt. Je kunt deze tekst gebruiken als het doel van een checkout of show commando, alhoewel het afhangt van de verkorte SHA-1 waarde aan het einde, dus het zou niet voor altijd geldig kunnen zijn. Bijvoorbeeld, de Linux kernel sprong recentelijk van 8 naar 10 karakters om er zeker van de zijn dat de SHA-1 uniek zijn, zodat oudere `git describe` commando's ongeldig werden.
+Het `git describe` commando geeft beschreven tags de voorkeur (tags gecre�erd met de `-a` of `-s` vlag), dus release tags moeten op deze manier aangemaakt worden als je `git describe` gebruikt, om er zeker van te zijn dat de commit juist benoemd wordt als het omschreven wordt. Je kunt deze tekst ook gebruiken als het doel van een checkout of show commando, alhoewel het afhankelijk is van de verkorte SHA-1 waarde aan het einde, dus het zou niet eeuwig geldig kunnen zijn. Bijvoorbeeld, de Linux kernel sprong recentelijk van 8 naar 10 karakters om er zeker van de zijn dat de SHA-1 uniek zijn, oudere `git describe` commando's werden daardoor ongeldig.
 
-### Een vrijgave voorbereiden ###
+### Een release voorbereiden ###
 
-Nu wil je een bouw vrijgeven. Een van de dingen die je wilt doen is een archief maken van het laatste snapshot van je code voor die arme zielen die geen Git gebruiken. Het commando om dit te doen is `git archive`:
+Nu wil je een build vrijgeven. Een van de dingen die je wilt doen is een archief maken van de laatste snapshot van je code voor de arme stumperds die geen Git gebruiken. Het commando om dit te doen is `git archive`:
 
 	$ git archive master --prefix='project/' | gzip > `git describe master`.tar.gz
 	$ ls *.tar.gz
 	v1.6.2-rc1-20-g8c5b85c.tar.gz
 
-Als iemand die tarball opent, dan krijgen ze ze laatste snapshot van je project onder een project map. Je kunt op vrijwel dezelfde manier ook een zip archief maken, maar dan door de `format=zip` optie mee te geven aan `git archive`:
+Als iemand die tarball opent, dan krijgen ze de laatste snapshot van je project onder een project directory. Je kunt op vrijwel dezelfde manier ook een zip archief maken, maar dan door de `format=zip` optie mee te geven aan `git archive`:
 
 	$ git archive master --prefix='project/' --format=zip > `git describe master`.zip
 
-Je hebt nu een fijne tarball en een zip archief van je project vrijgave, die je kunt uploaden naar je website of naar mensen kunt e-mailen.
+Je hebt nu een mooie tarball en een zip archief van je project release, die je kunt uploaden naar je website of naar mensen kunt e-mailen.
 
-### Het shortlog ###
+### De shortlog ###
 
-Het is tijd geworden om je maillijst van mensen die willen weten wat er gebeurt in je project te e-mailen. Een fijne manier om een soort van veranderingslog te krijgen van wat er is toegevoegd in je project sinds je laatste vrijgave of e-mail is om het `git shortlog` commando te gebruiken. Het vat alle commits samen in de reeks die je het geeft; bijvoorbeeld, het volgende geeft je een samenvatting van alle commits sinds je vorige vrijgave, als je laatste vrijgave v1.0.1 heette:
+De tijd is gekomen om de maillijst met mensen die willen weten wat er gebeurt in je project te mailen. Een prettige manier om een soort van wijzigingsverslag te krijgen van wat er is toegevoegd in je project sinds je laatste release of e-mail is om het `git shortlog` commando te gebruiken. Het vat alle commits samen binnen de grenswaarden die je het geeft. Bijvoorbeeld het volgende geeft je een samenvatting van alle commits sinds je vorige release, als je laatste release v1.0.1 heette:
 
 	$ git shortlog --no-merges master --not v1.0.1
 	Chris Wanstrath (8):
@@ -910,8 +910,8 @@ Het is tijd geworden om je maillijst van mensen die willen weten wat er gebeurt
 	      Version bump to 1.0.2
 	      Regenerated gemspec for version 1.0.2
 
-Je krijgt een schone samenvatting van alle commits sinds v1.0.1, gegroepeerd op auteur, die je naar je lijst kunt e-mailen.
+Je krijgt een opgeschoonde samenvatting van alle commits sinds v1.0.1, gegroepeerd op auteur, die je naar de lijst kunt e-mailen.
 
 ## Samenvatting ##
 
-Je moet je vrij gemakkelijk voelen om aan een project bij te kunnen dragen in Git, als ook om je eigen project te beheren of de bijdragen van andere gebruikers te integreren. Gefeliciteerd met het worden van een effectieve Git ontwikkelaar! In het volgende hoofdstuk zul je krachtigere applicaties en trucs leren voor het omgaan met complexe situaties, die je een echte Git meester zullen maken.
+Je zou je nu redelijk op je gemak moeten voelen om aan een project bij te dragen met Git, maar ook om je eigen project te beheren of de bijdragen van andere gebruikers te integreren. Gefeliciteerd met het worden van een effectieve Git ontwikkelaar! In het volgende hoofdstuk zul je nog krachtigere tools en trucs leren voor het omgaan met complexe situaties, die je een echte Git meester zullen maken.

From b8d3ef3ce77bc9e967bc1f5c3894594683863649 Mon Sep 17 00:00:00 2001
From: Matt Deacalion Stevens <matt@dirtymonkey.co.uk>
Date: Thu, 30 Jan 2014 01:25:41 -0700
Subject: [PATCH 137/690] Update command line output in Chapter 3.2

The command line output in the examples is from an older version of Git
(1.7.*) and is slightly inconsistent with the latest version.
---
 en/03-git-branching/01-chapter3.markdown | 92 +++++++++++++-----------
 1 file changed, 50 insertions(+), 42 deletions(-)

diff --git a/en/03-git-branching/01-chapter3.markdown b/en/03-git-branching/01-chapter3.markdown
index bf0028744..754006b6c 100644
--- a/en/03-git-branching/01-chapter3.markdown
+++ b/en/03-git-branching/01-chapter3.markdown
@@ -117,7 +117,7 @@ Figure 3-10. A short and simple commit history.
 You’ve decided that you’re going to work on issue #53 in whatever issue-tracking system your company uses. To be clear, Git isn’t tied into any particular issue-tracking system; but because issue #53 is a focused topic that you want to work on, you’ll create a new branch in which to work. To create a branch and switch to it at the same time, you can run the `git checkout` command with the `-b` switch:
 
 	$ git checkout -b iss53
-	Switched to a new branch "iss53"
+	Switched to a new branch 'iss53'
 
 This is shorthand for:
 
@@ -142,18 +142,18 @@ Now you get the call that there is an issue with the web site, and you need to f
 However, before you do that, note that if your working directory or staging area has uncommitted changes that conflict with the branch you’re checking out, Git won’t let you switch branches. It’s best to have a clean working state when you switch branches. There are ways to get around this (namely, stashing and commit amending) that we’ll cover later. For now, you’ve committed all your changes, so you can switch back to your master branch:
 
 	$ git checkout master
-	Switched to branch "master"
+	Switched to branch 'master'
 
 At this point, your project working directory is exactly the way it was before you started working on issue #53, and you can concentrate on your hotfix. This is an important point to remember: Git resets your working directory to look like the snapshot of the commit that the branch you check out points to. It adds, removes, and modifies files automatically to make sure your working copy is what the branch looked like on your last commit to it.
 
 Next, you have a hotfix to make. Let’s create a hotfix branch on which to work until it’s completed (see Figure 3-13):
 
 	$ git checkout -b hotfix
-	Switched to a new branch "hotfix"
+	Switched to a new branch 'hotfix'
 	$ vim index.html
 	$ git commit -a -m 'fixed the broken email address'
-	[hotfix]: created 3a0874c: "fixed the broken email address"
-	 1 files changed, 0 insertions(+), 1 deletions(-)
+	[hotfix 3a0874c] fixed the broken email address
+	 1 files changed, 1 deletion(-)
 
 Insert 18333fig0313.png
 Figure 3-13. hotfix branch based back at your master branch point.
@@ -163,11 +163,11 @@ You can run your tests, make sure the hotfix is what you want, and merge it back
 	$ git checkout master
 	$ git merge hotfix
 	Updating f42c576..3a0874c
-	Fast forward
-	 README |    1 -
-	 1 files changed, 0 insertions(+), 1 deletions(-)
+	Fast-forward
+	 README | 1 -
+	 1 file changed, 1 deletion(-)
 
-You’ll notice the phrase "Fast forward" in that merge. Because the commit pointed to by the branch you merged in was directly upstream of the commit you’re on, Git moves the pointer forward. To phrase that another way, when you try to merge one commit with a commit that can be reached by following the first commit’s history, Git simplifies things by moving the pointer forward because there is no divergent work to merge together — this is called a "fast forward".
+You’ll notice the phrase "Fast-forward" in that merge. Because the commit pointed to by the branch you merged in was directly upstream of the commit you’re on, Git moves the pointer forward. To phrase that another way, when you try to merge one commit with a commit that can be reached by following the first commit’s history, Git simplifies things by moving the pointer forward because there is no divergent work to merge together — this is called a "fast forward".
 
 Your change is now in the snapshot of the commit pointed to by the `master` branch, and you can deploy your change (see Figure 3-14).
 
@@ -177,16 +177,16 @@ Figure 3-14. Your master branch points to the same place as your hotfix branch a
 After your super-important fix is deployed, you’re ready to switch back to the work you were doing before you were interrupted. However, first you’ll delete the `hotfix` branch, because you no longer need it — the `master` branch points at the same place. You can delete it with the `-d` option to `git branch`:
 
 	$ git branch -d hotfix
-	Deleted branch hotfix (3a0874c).
+	Deleted branch hotfix (was 3a0874c).
 
 Now you can switch back to your work-in-progress branch on issue #53 and continue working on it (see Figure 3-15):
 
 	$ git checkout iss53
-	Switched to branch "iss53"
+	Switched to branch 'iss53'
 	$ vim index.html
 	$ git commit -a -m 'finished the new footer [issue 53]'
-	[iss53]: created ad82d7a: "finished the new footer [issue 53]"
-	 1 files changed, 1 insertions(+), 0 deletions(-)
+	[iss53 ad82d7a] finished the new footer [issue 53]
+	 1 file changed, 1 insertion(+)
 
 Insert 18333fig0315.png
 Figure 3-15. Your iss53 branch can move forward independently.
@@ -199,9 +199,10 @@ Suppose you’ve decided that your issue #53 work is complete and ready to be me
 
 	$ git checkout master
 	$ git merge iss53
-	Merge made by recursive.
-	 README |    1 +
-	 1 files changed, 1 insertions(+), 0 deletions(-)
+	Auto-merging README
+	Merge made by the 'recursive' strategy.
+	 README | 1 +
+	 1 file changed, 1 insertion(+)
 
 This looks a bit different than the `hotfix` merge you did earlier. In this case, your development history has diverged from some older point. Because the commit on the branch you’re on isn’t a direct ancestor of the branch you’re merging in, Git has to do some work. In this case, Git does a simple three-way merge, using the two snapshots pointed to by the branch tips and the common ancestor of the two. Figure 3-16 highlights the three snapshots that Git uses to do its merge in this case.
 
@@ -230,25 +231,27 @@ Occasionally, this process doesn’t go smoothly. If you changed the same part o
 
 Git hasn’t automatically created a new merge commit. It has paused the process while you resolve the conflict. If you want to see which files are unmerged at any point after a merge conflict, you can run `git status`:
 
-	[master*]$ git status
-	index.html: needs merge
-	# On branch master
-	# Changes not staged for commit:
-	#   (use "git add <file>..." to update what will be committed)
-	#   (use "git checkout -- <file>..." to discard changes in working directory)
-	#
-	#	unmerged:   index.html
-	#
+	$ git status
+	On branch master
+	You have unmerged paths.
+	  (fix conflicts and run "git commit")
+	
+	Unmerged paths:
+	  (use "git add <file>..." to mark resolution)
+	
+	        both modified:      index.html
+	
+	no changes added to commit (use "git add" and/or "git commit -a")
 
 Anything that has merge conflicts and hasn’t been resolved is listed as unmerged. Git adds standard conflict-resolution markers to the files that have conflicts, so you can open them manually and resolve those conflicts. Your file contains a section that looks something like this:
 
-	<<<<<<< HEAD:index.html
+	<<<<<<< HEAD
 	<div id="footer">contact : email.support@github.com</div>
 	=======
 	<div id="footer">
 	  please contact us at support@github.com
 	</div>
-	>>>>>>> iss53:index.html
+	>>>>>>> iss53
 
 This means the version in HEAD (your master branch, because that was what you had checked out when you ran your merge command) is the top part of that block (everything above the `=======`), while the version in your `iss53` branch looks like everything in the bottom part. In order to resolve the conflict, you have to either choose one side or the other or merge the contents yourself. For instance, you might resolve this conflict by replacing the entire block with this:
 
@@ -260,12 +263,17 @@ This resolution has a little of each section, and I’ve fully removed the `<<<<
 If you want to use a graphical tool to resolve these issues, you can run `git mergetool`, which fires up an appropriate visual merge tool and walks you through the conflicts:
 
 	$ git mergetool
-	merge tool candidates: kdiff3 tkdiff xxdiff meld gvimdiff opendiff emerge vimdiff
-	Merging the files: index.html
+
+	This message is displayed because 'merge.tool' is not configured.
+	See 'git mergetool --tool-help' or 'git help config' for more details.
+	'git mergetool' will now attempt to use one of the following tools:
+	opendiff kdiff3 tkdiff xxdiff meld tortoisemerge gvimdiff diffuse diffmerge ecmerge p4merge araxis bc3 codecompare vimdiff emerge
+	Merging:
+	index.html
 
 	Normal merge conflict for 'index.html':
-	  {local}: modified
-	  {remote}: modified
+	  {local}: modified file
+	  {remote}: modified file
 	Hit return to start merge resolution tool (opendiff):
 
 If you want to use a merge tool other than the default (Git chose `opendiff` for me in this case because I ran the command on a Mac), you can see all the supported tools listed at the top after “merge tool candidates”. Type the name of the tool you’d rather use. In Chapter 7, we’ll discuss how you can change this default value for your environment.
@@ -275,12 +283,12 @@ After you exit the merge tool, Git asks you if the merge was successful. If you
 You can run `git status` again to verify that all conflicts have been resolved:
 
 	$ git status
-	# On branch master
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#	modified:   index.html
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        modified:   index.html
+	
 
 If you’re happy with that, and you verify that everything that had conflicts has been staged, you can type `git commit` to finalize the merge commit. The commit message by default looks something like this:
 
@@ -289,9 +297,9 @@ If you’re happy with that, and you verify that everything that had conflicts h
 	Conflicts:
 	  index.html
 	#
-	# It looks like you may be committing a MERGE.
+	# It looks like you may be committing a merge.
 	# If this is not correct, please remove the file
-	# .git/MERGE_HEAD
+	#       .git/MERGE_HEAD
 	# and try again.
 	#
 
@@ -440,7 +448,7 @@ To merge this work into your current working branch, you can run `git merge orig
 
 	$ git checkout -b serverfix origin/serverfix
 	Branch serverfix set up to track remote branch refs/remotes/origin/serverfix.
-	Switched to a new branch "serverfix"
+	Switched to a new branch 'serverfix'
 
 This gives you a local branch that you can work on that starts where `origin/serverfix` is.
 
@@ -452,13 +460,13 @@ When you clone a repository, it generally automatically creates a `master` branc
 
 	$ git checkout --track origin/serverfix
 	Branch serverfix set up to track remote branch refs/remotes/origin/serverfix.
-	Switched to a new branch "serverfix"
+	Switched to a new branch 'serverfix'
 
 To set up a local branch with a different name than the remote branch, you can easily use the first version with a different local branch name:
 
 	$ git checkout -b sf origin/serverfix
 	Branch sf set up to track remote branch refs/remotes/origin/serverfix.
-	Switched to a new branch "sf"
+	Switched to a new branch 'sf'
 
 Now, your local branch `sf` will automatically push to and pull from `origin/serverfix`.
 

From d88a43da71fb28dba9a7ae623a94d8c8baa06565 Mon Sep 17 00:00:00 2001
From: Matt Deacalion Stevens <matt@dirtymonkey.co.uk>
Date: Thu, 30 Jan 2014 01:36:22 -0700
Subject: [PATCH 138/690] Update command line output in Chapter 3.3

The command line output in the examples is from an older version of Git
(1.7.*) and is slightly inconsistent with the latest version.
---
 en/03-git-branching/01-chapter3.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/en/03-git-branching/01-chapter3.markdown b/en/03-git-branching/01-chapter3.markdown
index 754006b6c..484d957ec 100644
--- a/en/03-git-branching/01-chapter3.markdown
+++ b/en/03-git-branching/01-chapter3.markdown
@@ -339,7 +339,7 @@ To see all the branches that contain work you haven’t yet merged in, you can r
 This shows your other branch. Because it contains work that isn’t merged in yet, trying to delete it with `git branch -d` will fail:
 
 	$ git branch -d testing
-	error: The branch 'testing' is not an ancestor of your current HEAD.
+	error: The branch 'testing' is not fully merged.
 	If you are sure you want to delete it, run 'git branch -D testing'.
 
 If you really do want to delete the branch and lose that work, you can force it with `-D`, as the helpful message points out.

From 37d443f64a7862c04099f0fb4efe4f78214983c7 Mon Sep 17 00:00:00 2001
From: Matt Deacalion Stevens <matt@dirtymonkey.co.uk>
Date: Thu, 30 Jan 2014 01:45:54 -0700
Subject: [PATCH 139/690] Update command line output in Chapter 3.5

The command line output in the examples is from an older version of Git
(1.7.*) and is slightly inconsistent with the latest version.
---
 en/03-git-branching/01-chapter3.markdown | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/en/03-git-branching/01-chapter3.markdown b/en/03-git-branching/01-chapter3.markdown
index 484d957ec..e8294da74 100644
--- a/en/03-git-branching/01-chapter3.markdown
+++ b/en/03-git-branching/01-chapter3.markdown
@@ -447,7 +447,7 @@ It’s important to note that when you do a fetch that brings down new remote br
 To merge this work into your current working branch, you can run `git merge origin/serverfix`. If you want your own `serverfix` branch that you can work on, you can base it off your remote branch:
 
 	$ git checkout -b serverfix origin/serverfix
-	Branch serverfix set up to track remote branch refs/remotes/origin/serverfix.
+	Branch serverfix set up to track remote branch serverfix from origin.
 	Switched to a new branch 'serverfix'
 
 This gives you a local branch that you can work on that starts where `origin/serverfix` is.
@@ -459,13 +459,13 @@ Checking out a local branch from a remote branch automatically creates what is c
 When you clone a repository, it generally automatically creates a `master` branch that tracks `origin/master`. That’s why `git push` and `git pull` work out of the box with no other arguments. However, you can set up other tracking branches if you wish — ones that don’t track branches on `origin` and don’t track the `master` branch. The simple case is the example you just saw, running `git checkout -b [branch] [remotename]/[branch]`. If you have Git version 1.6.2 or later, you can also use the `--track` shorthand:
 
 	$ git checkout --track origin/serverfix
-	Branch serverfix set up to track remote branch refs/remotes/origin/serverfix.
+	Branch serverfix set up to track remote branch serverfix from origin.
 	Switched to a new branch 'serverfix'
 
 To set up a local branch with a different name than the remote branch, you can easily use the first version with a different local branch name:
 
 	$ git checkout -b sf origin/serverfix
-	Branch sf set up to track remote branch refs/remotes/origin/serverfix.
+	Branch sf set up to track remote branch serverfix from origin.
 	Switched to a new branch 'sf'
 
 Now, your local branch `sf` will automatically push to and pull from `origin/serverfix`.

From 1f4e6e2052093fa15d2fe64a4360485a6da66f37 Mon Sep 17 00:00:00 2001
From: Zack <kbaniszack@users.noreply.github.com>
Date: Thu, 30 Jan 2014 16:58:52 +0100
Subject: [PATCH 140/690] [fr] Update 01-chapter2.markdown

Change "le liste" to "la liste"
---
 fr/02-git-basics/01-chapter2.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fr/02-git-basics/01-chapter2.markdown b/fr/02-git-basics/01-chapter2.markdown
index 8f1fe37c6..1ed5f012e 100644
--- a/fr/02-git-basics/01-chapter2.markdown
+++ b/fr/02-git-basics/01-chapter2.markdown
@@ -1000,7 +1000,7 @@ Si vous lancez cette commande avec un nom court particulier, tel que `origin`, v
 	    ticgit
 
 
-Cela donne le liste des URL pour le dépôt distant ainsi que la liste des branches distantes suivies.
+Cela donne la liste des URL pour le dépôt distant ainsi que la liste des branches distantes suivies.
 Cette commande vous informe que si vous êtes sur la branche `master` et si vous lancez `git pull`, il va automatiquement fusionner la branche `master` du dépôt distant après avoir récupéré toutes les références sur le serveur distant.
 Cela donne aussi la liste des autres références qu'il aura tirées.
 

From bfc5f0ab83b5f6c36492cdcc48c007838fe513bf Mon Sep 17 00:00:00 2001
From: Cor <git@cpt1.demon.nl>
Date: Fri, 31 Jan 2014 08:30:31 +0100
Subject: [PATCH 141/690] [nl] Repair the mangled diacritics.

---
 nl/05-distributed-git/01-chapter5.markdown | 82 +++++++++++-----------
 1 file changed, 41 insertions(+), 41 deletions(-)

diff --git a/nl/05-distributed-git/01-chapter5.markdown b/nl/05-distributed-git/01-chapter5.markdown
index d84874a81..25c320dc3 100644
--- a/nl/05-distributed-git/01-chapter5.markdown
+++ b/nl/05-distributed-git/01-chapter5.markdown
@@ -10,7 +10,7 @@ In tegenstelling tot gecentraliseerde versiebeheersystemen (CVCSen), stelt de ge
 
 ### Gecentraliseerde werkwijze ###
 
-In gecentraliseerde systemen is er over het algemeen een enkel samenwerkingsmodel - de gecentraliseerde werkwijze. E�n centraal punt, of repository, kan code aanvaarden, en iedereen synchroniseert zijn werk daarmee. Een aantal ontwikkelaars zijn knopen - gebruikers van dat centrale punt - en synchroniseren met die plaats (zie Figuur 5-1).
+In gecentraliseerde systemen is er over het algemeen een enkel samenwerkingsmodel - de gecentraliseerde werkwijze. Eén centraal punt, of repository, kan code aanvaarden, en iedereen synchroniseert zijn werk daarmee. Een aantal ontwikkelaars zijn knopen - gebruikers van dat centrale punt - en synchroniseren met die plaats (zie Figuur 5-1).
 
 Insert 18333fig0501.png
 Figuur 5-1. Gecentraliseerde Werkwijze.
@@ -22,7 +22,7 @@ Deze werkwijze is voor een hoop mensen aantrekkelijk omdat het er een is waarmee
 
 ### Integratie-manager werkwijze ###
 
-Omdat Git je toestaat om meerdere remote repositories te hebben, is het mogelijk om een werkwijze te hebben waarbij iedere ontwikkelaar schrijftoegang heeft tot zijn eigen publieke repository en leestoegang op de andere. Dit scenario heeft vaak een gezagdragend (canonical) repository dat het "offici�le" project voorstelt. Om bij te kunnen dragen tot dat project, maak je je eigen publieke kloon van het project en zet je wijzigingen daarin terug. Daarna stuur je een verzoek naar de eigenaar van het hoofdproject om jouw wijzigingen binnen te halen (pull request). Hij kan je repository toevoegen als een remote, je wijzigingen lokaal testen, ze in zijn branch mergen, en naar zijn repository terugzetten. Het proces werkt als volgt (zie Figuur 5-2):
+Omdat Git je toestaat om meerdere remote repositories te hebben, is het mogelijk om een werkwijze te hebben waarbij iedere ontwikkelaar schrijftoegang heeft tot zijn eigen publieke repository en leestoegang op de andere. Dit scenario heeft vaak een gezagdragend (canonical) repository dat het "officiële" project voorstelt. Om bij te kunnen dragen tot dat project, maak je je eigen publieke kloon van het project en zet je wijzigingen daarin terug. Daarna stuur je een verzoek naar de eigenaar van het hoofdproject om jouw wijzigingen binnen te halen (pull request). Hij kan je repository toevoegen als een remote, je wijzigingen lokaal testen, ze in zijn branch mergen, en naar zijn repository terugzetten. Het proces werkt als volgt (zie Figuur 5-2):
 
 1. De projecteigenaar pushed naar de publieke repository.
 2. Een bijdrager kloont die repository en maakt wijzigingen.
@@ -38,7 +38,7 @@ Dit is een veel voorkomende werkwijze bij websites zoals GitHub, waarbij het een
 
 ### Dictator en luitenanten werkwijze ###
 
-Dit is een variant op de multi-repository werkwijze. Het wordt over het algemeen gebruikt bij enorme grote projecten met honderden bijdragers; een bekend voorbeeld is de Linux-kernel. Een aantal integrators geven de leiding over bepaalde delen van het repository, zij worden luitenanten genoemd. Alle luitenanten hebben ��n integrator die bekend staat als de welwillende dictator. De repository van de welwillende dictator dient als het referentierepository vanwaar alle bijdragers dienen binnen te halen. Het proces werkt als volgt (zie Figuur 5-3):
+Dit is een variant op de multi-repository werkwijze. Het wordt over het algemeen gebruikt bij enorme grote projecten met honderden bijdragers; een bekend voorbeeld is de Linux-kernel. Een aantal integrators geven de leiding over bepaalde delen van het repository, zij worden luitenanten genoemd. Alle luitenanten hebben één integrator die bekend staat als de welwillende dictator. De repository van de welwillende dictator dient als het referentierepository vanwaar alle bijdragers dienen binnen te halen. Het proces werkt als volgt (zie Figuur 5-3):
 
 1. Reguliere ontwikkelaars werken op hun eigen onderwerp (topic) branch en rebasen hun werk op de master. De masterbranch is die van de dictator.
 2. Luitenanten mergen de topic branches van de ontwikkelaars in hun masterbranch.
@@ -48,7 +48,7 @@ Dit is een variant op de multi-repository werkwijze. Het wordt over het algemeen
 Insert 18333fig0503.png
 Figuur 5-3. Welwillende-dictatorwerkwijze.
 
-Deze manier van werken is niet gewoon, maar kan handig zijn in hele grote projecten of in zeer hi�rarchische omgevingen, omdat het de projectleider (de dictator) in staat stelt om het meeste werk te delegeren en grote subsets van code te verzamelen op meerdere punten alvorens ze te integreren.
+Deze manier van werken is niet gewoon, maar kan handig zijn in hele grote projecten of in zeer hiërarchische omgevingen, omdat het de projectleider (de dictator) in staat stelt om het meeste werk te delegeren en grote subsets van code te verzamelen op meerdere punten alvorens ze te integreren.
 
 Dit zijn veel voorkomende werkwijzen die mogelijk zijn met een gedistribueerd systeem als Git, maar je kunt zien dat er veel variaties mogelijk zijn om ze te laten passen bij jouw specifieke werkwijze. Nu dat je (naar ik hoop) in staat bent om te bepalen welke combinatie van werkwijzen voor jou werkt, zal ik wat specifiekere voorbeelden behandelen over hoe je de belangrijkste rollen kunt vervullen, die in de verschillende werkwijzen voorkomen.
 
@@ -82,7 +82,7 @@ Als eerste wil je geen witruimte fouten indienen. Git geeft je een eenvoudige ma
 
 Als je dat commando uitvoert alvorens te committen, kun je al zien of je op het punt staat witruimte problemen te committen die waaraan andere ontwikkelaars zich zullen ergeren.
 
-Probeer vervolgens om van elke commit een logische set wijzigingen te maken. Probeer, als het je lukt, om je wijzigingen verteerbaar te maken - ga niet het hele weekend zitten coderen op vijf verschillende problemen om dat vervolgens op maandag als een gigantische commit in te dienen. Zelfs als je gedurende het weekend niet commit, gebruik dan het staging gebied op maandag om je werk in ten minste ��n commit per probleem op te splitsen, met een bruikbaar bericht per commit. Als een paar van de wijzigingen ��n bestand veranderen, probeer dan `git add --patch` te gebruiken om bestanden gedeeltelijk te stagen (wordt in detail behandeld in Hoofdstuk 6). De laatste snapshot van het project is gelijk of je nu ��n commit doet of vijf, zolang alle wijzigingen op een gegeven momment maar toegevoegd zijn, dus probeer om het je mede-ontwikkelaars makkelijk te maken als ze je wijzigingen moeten bekijken. Deze aanpak maakt het ook makkelijker om ��n wijziging te pullen of terug te draaien, mocht dat later nodig zijn. Hoofdstuk 6 beschrijft een aantal handige Git trucs om geschiedenis te herschrijven en bestanden interactief te stagen - gebruik deze gereedschappen een schone en begrijpelijke historie te helpen op te bouwen.
+Probeer vervolgens om van elke commit een logische set wijzigingen te maken. Probeer, als het je lukt, om je wijzigingen verteerbaar te maken - ga niet het hele weekend zitten coderen op vijf verschillende problemen om dat vervolgens op maandag als een gigantische commit in te dienen. Zelfs als je gedurende het weekend niet commit, gebruik dan het staging gebied op maandag om je werk in ten minste één commit per probleem op te splitsen, met een bruikbaar bericht per commit. Als een paar van de wijzigingen één bestand veranderen, probeer dan `git add --patch` te gebruiken om bestanden gedeeltelijk te stagen (wordt in detail behandeld in Hoofdstuk 6). De laatste snapshot van het project is gelijk of je nu één commit doet of vijf, zolang alle wijzigingen op een gegeven momment maar toegevoegd zijn, dus probeer om het je mede-ontwikkelaars makkelijk te maken als ze je wijzigingen moeten bekijken. Deze aanpak maakt het ook makkelijker om één wijziging te pullen of terug te draaien, mocht dat later nodig zijn. Hoofdstuk 6 beschrijft een aantal handige Git trucs om geschiedenis te herschrijven en bestanden interactief te stagen - gebruik deze gereedschappen een schone en begrijpelijke historie te helpen op te bouwen.
 
 Het laatste om in gedachten te houden is het commit bericht. Als je er een gewoonte van maakt om een goede kwaliteit commit berichten aan te maken, dan maakt dat het gebruik van en samenwerken in Git een stuk eenvoudiger. In het algemeen, zouden je berichten moeten beginnen met een enkele regel, die niet langer is dan 50 karakters en die de wijzigingen beknopt omschrijft, gevolgd door een lege regel en daarna een meer gedetailleerde uitleg. Het Git project vereist dat de meer gedetailleerde omschrijving ook je motivatie voor de verandering bevat, en de nieuwe implementatie tegen het oude gedrag afzet. Dit is een goede richtlijn om te volgen. Het is ook een goed idee om de gebiedende wijs te gebruiken in deze berichten. Met andere woorden, gebruik commando's. In plaats van "Ik heb testen toegevoegd voor" of "Testen toegevoegd voor" gebruik je "Voeg testen toe voor".
 Hier is een sjabloon dat origineel geschreven is door Tim Pope op tpope.net:
@@ -103,7 +103,7 @@ Hier is een sjabloon dat origineel geschreven is door Tim Pope op tpope.net:
 
 	 - Typisch wordt een streepje of sterretje gebruikt als "bullet",
 	   voorafgegaan door een enkele spatie, met ertussen lege regels,
-	   maar de conventies vari�ren hierin.
+	   maar de conventies variëren hierin.
 
 Als al je commit berichten er zo uit zien, dan zullen de dingen een stuk eenvoudiger zijn voor jou en de ontwikkelaars waar je mee samenwerkt. Het Git project heeft goed geformatteerde commit berichten - ik raad je aan om `git log --no-merges` uit te voeren om te zien hoe een goed geformatteerde project-commit historie eruit ziet.
 
@@ -111,7 +111,7 @@ In de volgende voorbeelden, en verder door de rest van dit boek, zal ik omwille
 
 ### Besloten klein team ###
 
-De eenvoudigste opzet die je waarschijnlijk zult tegenkomen is een besloten project met ��n of twee andere ontwikkelaars. Met besloten bedoel ik gesloten broncode - zonder leestoegang voor de buitenwereld. Jij en de andere ontwikkelaars hebben allemaal push toegang op het repository.
+De eenvoudigste opzet die je waarschijnlijk zult tegenkomen is een besloten project met één of twee andere ontwikkelaars. Met besloten bedoel ik gesloten broncode - zonder leestoegang voor de buitenwereld. Jij en de andere ontwikkelaars hebben allemaal push toegang op het repository.
 
 In deze omgeving kun je een werkwijze aanhouden die vergelijkbaar is met wat je zou doen als je Subversion of een andere gecentraliseerd systeem zou gebruiken. Je hebt nog steeds de voordelen van zaken als offline committen en veel eenvoudiger branchen en mergen, maar de werkwijze kan erg vergelijkbaar zijn. Het grote verschil is dat het mergen aan de client-kant gebeurt tijdens het committen in plaats van aan de server-kant.
 Laten we eens kijken hoe het er uit zou kunnen zien als twee ontwikkelaars samen beginnen te werken met een gedeelde repository. De eerste ontwikkelaar, John, kloont de repository, maakt een wijziging, en commit lokaal. (Ik vervang de protocol berichten met `...` in deze voorbeelden om ze iets in te korten.)
@@ -154,7 +154,7 @@ John probeert ook zijn werk te pushen:
 	 ! [rejected]        master -> master (non-fast forward)
 	error: failed to push some refs to 'john@githost:simplegit.git'
 
-John mag niet terugzetten omdat Jessica in de tussentijd gepushed heeft. Dit is belangrijk om te begrijpen als je gewoon bent aan Subversion, omdat het je zal opvallen dat de twee ontwikkelaars niet hetzelfde bestand hebben aangepast. Waar Subversion automatisch zo'n merge op de server doet, als verschillende bestanden zijn aangepast, moet je in Git de commits lokaal mergen. John moet Jessica's wijzigingen ophalen (fetch) en ze mergen voor hij mag pushen:
+John mag niet pushen omdat Jessica in de tussentijd gepushed heeft. Dit is belangrijk om te begrijpen als je gewend bent aan Subversion, omdat het je zal opvallen dat de twee ontwikkelaars niet hetzelfde bestand hebben aangepast. Waar Subversion automatisch zo'n merge op de server doet, als verschillende bestanden zijn aangepast, moet je in Git de commits lokaal mergen. John moet Jessica's wijzigingen ophalen (fetch) en ze mergen voor hij mag pushen:
 
 	$ git fetch origin
 	...
@@ -164,7 +164,7 @@ John mag niet terugzetten omdat Jessica in de tussentijd gepushed heeft. Dit is
 Hierna ziet John's lokale repository er ongeveer uit zoals Figuur 5-4.
 
 Insert 18333fig0504.png
-Figuur 5-4. John's initi�le repository.
+Figuur 5-4. John's initiële repository.
 
 John heeft een referentie naar de wijzigingen die Jessica gepushed heeft, maar hij moet ze mergen met zijn eigen werk voordat hij het mag pushen:
 
@@ -173,12 +173,12 @@ John heeft een referentie naar de wijzigingen die Jessica gepushed heeft, maar h
 	 TODO |    1 +
 	 1 files changed, 1 insertions(+), 0 deletions(-)
 
-Het samenvoegen gaat soepeltjes - de commit historie van John ziet er nu uit als Figuur 5-5.
+Het mergen gaat soepeltjes - de commit historie van John ziet er nu uit als Figuur 5-5.
 
 Insert 18333fig0505.png
-Figuur 5-5. John's repository na het samenvoegen van origin/master.
+Figuur 5-5. John's repository na het mergen van origin/master.
 
-Nu kan John zijn code testen om er zeker van te zijn dat het nog steeds goed werkt, en dan kan hij zijn nieuwe samengevoegde werk pushen naar de server:
+Nu kan John zijn code testen om er zeker van te zijn dat het nog steeds goed werkt, en dan kan hij zijn nieuwe gemergede werk pushen naar de server:
 
 	$ git push origin master
 	...
@@ -193,7 +193,7 @@ Figuur 5-6. John's historie na gepushed te hebben naar de origin van de server.
 In de tussentijd heeft Jessica gewerkt op een topic branch. Ze heeft een topic branch genaamd `issue54` aangemaakt en daar drie commits op gedaan. Ze heeft John's wijzigingen nog niet opgehaald, dus haar commit historie ziet er uit als Figuur 5-7.
 
 Insert 18333fig0507.png
-Figuur 5-7. Jessica's initi�le commit historie.
+Figuur 5-7. Jessica's initiële commit historie.
 
 Jessica wil met John synchroniseren, dus ze haalt de wijzigingen op:
 
@@ -257,16 +257,16 @@ Iedere ontwikkelaar heeft een paar keer gecommit en elkaars werk succesvol samen
 Insert 18333fig0510.png
 Figuur 5-10. Jessica's historie na alle wijzigingen teruggezet te hebben op de server.
 
-Dit is ��n van de eenvoudigste werkwijzen. Je werkt een tijdje, over het algemeen in een topic branch, en merged in je `master` branch als het klaar is om te worden ge�ntegreerd. Als je dat werk wilt delen, dan merge je het in je eigen `master` branch, en vervolgens fetch je `origin/master` en merge je deze als het gewijzigd is, en als laatste push je deze naar de `master` branch op de server. De algemene volgorde is zoiets als die getoond in Figuur 5-11.
+Dit is één van de eenvoudigste werkwijzen. Je werkt een tijdje, over het algemeen in een topic branch, en merged in je `master` branch als het klaar is om te worden geïntegreerd. Als je dat werk wilt delen, dan merge je het in je eigen `master` branch, en vervolgens fetch je `origin/master` en merge je deze als het gewijzigd is, en als laatste push je deze naar de `master` branch op de server. De algemene volgorde is zoiets als die getoond in Figuur 5-11.
 
 Insert 18333fig0511.png
 Figuur 5-11. Algemene volgorde van gebeurtenissen voor een eenvoudige multi-ontwikkelaar Git werkwijze.
 
 ### Besloten aangestuurd team ###
 
-In het volgende scenario zul je kijken naar de rol van de bijdragers in een grotere besloten groep. Je zult leren hoe te werken in een omgeving waar kleine groepen samenwerken aan functies, waarna die team-gebaseerde bijdragen worden ge�ntegreerd door een andere partij.
+In het volgende scenario zul je kijken naar de rol van de bijdragers in een grotere besloten groep. Je zult leren hoe te werken in een omgeving waar kleine groepen samenwerken aan functies, waarna die team-gebaseerde bijdragen worden ge�ntegreerd door een andere partij.
 
-Stel dat John en Jessica samen werken aan een functie, terwijl Jessica en Josie aan een tweede aan het werken zijn. In dit geval gebruikt het bedrijf een integratie-manager achtige werkwijze, waarbij het werk van de individuele groepen alleen wordt ge�ntegreerd door bepaalde ontwikkelaars, en de `master` branch van het hoofd repo alleen kan worden vernieuwd door die ontwikkelaars. In dit scenario wordt al het werk gedaan in team-gebaseerde branches en later door de integrators samengevoegd.
+Stel dat John en Jessica samen werken aan een functie, terwijl Jessica en Josie aan een tweede aan het werken zijn. In dit geval gebruikt het bedrijf een integratie-manager achtige werkwijze, waarbij het werk van de individuele groepen alleen wordt geïntegreerd door bepaalde ontwikkelaars, en de `master` branch van het hoofd repo alleen kan worden vernieuwd door die ontwikkelaars. In dit scenario wordt al het werk gedaan in team-gebaseerde branches en later door de integrators samengevoegd.
 
 Laten we Jessica's werkwijze volgen terwijl ze aan haar twee functies werkt, in parallel met twee verschillende ontwikkelaars in deze omgeving. We nemen even aand dat ze haar repository al gekloond heeft, en dat ze besloten heeft als eerste te werken aan `featureA`. Ze maakt een nieuwe branch aan voor de functie en doet daar wat werk:
 
@@ -306,7 +306,7 @@ Nu doet Jessica een paar commits op de `featureB` branch:
 Jessica's repository ziet eruit als Figuur 5-12.
 
 Insert 18333fig0512.png
-Figuur 5-12. Jessica's initi�le commit historie.
+Figuur 5-12. Jessica's initiële commit historie.
 
 Ze is klaar om haar werk te pushen, maar ze krijgt een mail van Josie dat een branch met wat initieel werk erin al gepushed is naar de server in de `featureBee` branch. Jessica moet die wijzigingen eerst mergen met die van haar voordat ze kan pushen naar de server. Ze kan dan Josie's wijzigingen ophalen met `git fetch`:
 
@@ -332,7 +332,7 @@ Er is wel een klein probleempje - ze moet het gemergde werk in haar `featureB` b
 
 Dit wordt een _refspec_ genoemd. Zie Hoofdstuk 9 voor een gedetailleerdere behandeling van Git refspecs en de verschillende dingen die je daarmee kan doen.
 
-Vervolgens mailt John naar Jessica om te zeggen dat hij wat wijzigingen naar de `featureA` branch gepushed heeft, en om haar te vragen die te verifi�ren. Ze voert een `git fetch` uit om die wijzigingen op te halen:
+Vervolgens mailt John naar Jessica om te zeggen dat hij wat wijzigingen naar de `featureA` branch gepushed heeft, en om haar te vragen die te verifiëren. Ze voert een `git fetch` uit om die wijzigingen op te halen:
 
 	$ git fetch origin
 	...
@@ -373,7 +373,7 @@ Jessica's commit historie ziet er nu uit zoals Figuur 5-13.
 Insert 18333fig0513.png
 Figuur 5-13. Jessica's historie na het committen op een functie branch.
 
-Jessica, Josie en John informeren de integrators nu dat de `featureA` en `featureBee` branches op de server klaar zijn voor integratie in de hoofdlijn. Nadat zij die branches in de hoofdlijn ge�ntegreerd hebben, zal een fetch de nieuwe merge commits ophalen, waardoor de commit historie er uit ziet zoals Figuur 5-14.
+Jessica, Josie en John informeren de integrators nu dat de `featureA` en `featureBee` branches op de server klaar zijn voor integratie in de hoofdlijn. Nadat zij die branches in de hoofdlijn ge�ntegreerd hebben, zal een fetch de nieuwe merge commits ophalen, waardoor de commit historie er uit ziet zoals Figuur 5-14.
 
 
 Insert 18333fig0514.png
@@ -398,7 +398,7 @@ Eerst zal je waarschijnlijk de hoofdrepository klonen, een topic branch maken vo
 	$ (work)
 	$ git commit
 
-Je kunt eventueel besluiten `rebase -i` te gebruiken om je werk in ��n enkele commit samen te persen (squash), of het werk in de commits te herschikken om de patch eenvoudiger te kunnen laten reviewen door de beheerders - zie Hoofdstuk 6 voor meer informatie over het interactief rebasen.
+Je kunt eventueel besluiten `rebase -i` te gebruiken om je werk in één enkele commit samen te persen (squash), of het werk in de commits te herschikken om de patch eenvoudiger te kunnen laten reviewen door de beheerders - zie Hoofdstuk 6 voor meer informatie over het interactief rebasen.
 
 Als je werk op de branch af is, en je klaar bent om het over te dragen aan de beheerders, ga je naar de originele project pagina en klik op de "Fork" knop. Hiermee maak je een eigen overschrijfbare fork van het project. Je moet de URL van deze nieuwe repository URL toevoegen als een tweede remote, in dit geval `myfork` genaamd:
 
@@ -439,10 +439,10 @@ Bij een project waarvan je niet de beheerder bent, is het over het algemeen eenv
 	$ (email maintainer)
 	$ git fetch origin
 
-Nu zijn al je onderwerpen opgeslagen in een silo - vergelijkbaar met een patch reeks (queue) - die je kunt herschrijven, rebasen en wijzigen zonder dat de onderwerpen elkaar be�nvloeden of van elkaar afhankelijk zijn zoals in Figuur 5-16.
+Nu zijn al je onderwerpen opgeslagen in een silo - vergelijkbaar met een patch reeks (queue) - die je kunt herschrijven, rebasen en wijzigen zonder dat de onderwerpen elkaar be�nvloeden of van elkaar afhankelijk zijn zoals in Figuur 5-16.
 
 Insert 18333fig0516.png
-Figuur 5-16. Initi�le commit historie met werk van featureB.
+Figuur 5-16. Initiële commit historie met werk van featureB.
 
 Stel dat de project beheerder een verzameling andere patches binnengehaald heeft en jouw eerste branch geprobeerd heeft, maar dat die niet meer netjes merged. In dat geval kun je proberen die branch te rebasen op de punt van `origin/master`, de conflicten op te lossen voor de beheerder, en dan je wijzigingen opnieuw aanbieden:
 
@@ -465,7 +465,7 @@ Laten we eens kijken naar nog een mogelijk scenario: de beheerder heeft je werk
 	$ git commit
 	$ git push myfork featureBv2
 
-De `--squash` optie pakt al het werk op de gemergde branch en perst dat samen in ��n non-merge commit bovenop de branch waar je op zit. De `--no-commit` optie vertelt Git dat hij niet automatisch een commit moet doen. Dit stelt je in staat om alle wijzigingen van een andere branch te introduceren en dan meer wijzigingen te doen, alvorens de nieuwe commit te doen.
+De `--squash` optie pakt al het werk op de gemergde branch en perst dat samen in één non-merge commit bovenop de branch waar je op zit. De `--no-commit` optie vertelt Git dat hij niet automatisch een commit moet doen. Dit stelt je in staat om alle wijzigingen van een andere branch te introduceren en dan meer wijzigingen te doen, alvorens de nieuwe commit te doen.
 
 Nu kun je de beheerder een bericht sturen dat je de gevraagde wijzigingen gemaakt hebt en dat ze die wijzigingen kunnen vinden in je `featureBv2` branch (zie Figuur 5-18).
 
@@ -484,7 +484,7 @@ De werkwijze is vergelijkbaar met het vorige geval - je maakt topic branches voo
 	$ (work)
 	$ git commit
 
-Nu heb je twee commits die je wil sturen naar de maillijst. Je gebruikt `git format-patch` om de mbox-geformatteerde bestanden te genereren die je kunt mailen naar de lijst. Dit vormt iedere commit om naar een e-mail bericht met de eerste regel van het commit bericht als de onderwerp regel, en de rest van het bericht plus de patch die door de commit wordt ge�ntroduceerd als de inhoud. Het prettige hieraan is dat met het toepassen van een patch uit een mail die gegenereerd is met `format-patch` alle commit informatie blijft behouden. In de volgende paragraaf zal je hiervan meer zien, als je deze commits gaat toepassen:
+Nu heb je twee commits die je wil sturen naar de maillijst. Je gebruikt `git format-patch` om de mbox-geformatteerde bestanden te genereren die je kunt mailen naar de lijst. Dit vormt iedere commit om naar een e-mail bericht met de eerste regel van het commit bericht als de onderwerp regel, en de rest van het bericht plus de patch die door de commit wordt ge�ntroduceerd als de inhoud. Het prettige hieraan is dat met het toepassen van een patch uit een mail die gegenereerd is met `format-patch` alle commit informatie blijft behouden. In de volgende paragraaf zal je hiervan meer zien, als je deze commits gaat toepassen:
 
 	$ git format-patch -M origin/master
 	0001-add-limit-to-log-function.patch
@@ -583,7 +583,7 @@ Dan spuuwt Git een bergje log-informatie uit voor elke patch die je stuurt, wat
 
 ### Samenvatting ###
 
-In dit hoofdstuk is een aantal veel voorkomende werkwijzen behandeld, die je kunt gebruiken om te kunnen werken in een aantal zeer verschillende typen Git projecten die je misschien zult tegenkomen, en een aantal nieuwe gereedschappen ge�ntroduceerd die je helpen om dit proces te beheren. Wat hierna volgt zal je laten zien hoe je aan de andere kant van de tafel werkt: een Git project beheren. Je zult leren hoe een welwillende dictator of integratie manager te zijn.
+In dit hoofdstuk is een aantal veel voorkomende werkwijzen behandeld, die je kunt gebruiken om te kunnen werken in een aantal zeer verschillende typen Git projecten die je misschien zult tegenkomen, en een aantal nieuwe gereedschappen geïntroduceerd die je helpen om dit proces te beheren. Wat hierna volgt zal je laten zien hoe je aan de andere kant van de tafel werkt: een Git project beheren. Je zult leren hoe een welwillende dictator of integratie manager te zijn.
 
 ## Het beheren van een project ##
 
@@ -612,7 +612,7 @@ Als je de patch ontvangen hebt van iemand die het gegenereerd heeft met de `git
 
 	$ git apply /tmp/patch-ruby-client.patch
 
-Dit wijzigt de bestanden in je werk directory. Het is vrijwel gelijk aan het uitvoeren van een `patch -p1` commando om de patch toe te passen, alhoewel het meer parano�de is en minder "fuzzy matches" accepteert dan patch. Het handelt ook bestandstoevoegingen af, -verwijderingen, en hernoemingen als ze beschreven staan in het `git diff` formaat, wat `patch` niet doet. Als laatste volgt `git apply` een "pas alles toe of laat alles weg" model waarbij alles of niets wordt toegepast. Dit in tegenstelling tot `patch` die gedeeltelijke patches kan toepassen, waardoor je werk directory in een vreemde status achterblijft. Over het algemeen is `git apply` meer parano�de dan `patch`. Het zal geen commit voor je aanmaken; na het uitvoeren moet je de ge�ntroduceerde wijzigingen handmatig stagen en committen.
+Dit wijzigt de bestanden in je werk directory. Het is vrijwel gelijk aan het uitvoeren van een `patch -p1` commando om de patch toe te passen, alhoewel het meer paranoïde is en minder "fuzzy matches" accepteert dan patch. Het handelt ook bestandstoevoegingen af, -verwijderingen, en hernoemingen als ze beschreven staan in het `git diff` formaat, wat `patch` niet doet. Als laatste volgt `git apply` een "pas alles toe of laat alles weg" model waarbij alles of niets wordt toegepast. Dit in tegenstelling tot `patch` die gedeeltelijke patches kan toepassen, waardoor je werk directory in een vreemde status achterblijft. Over het algemeen is `git apply` meer paranoïde dan `patch`. Het zal geen commit voor je aanmaken; na het uitvoeren moet je de geïntroduceerde wijzigingen handmatig stagen en committen.
 
 Je kunt ook git apply gebruiken om te zien of een patch netjes kan worden toepast voordat je het echt doet; je kunt `git apply --check` uitvoeren met de patch:
 
@@ -626,7 +626,7 @@ Als er geen uitvoer is, dan zou de patch netjes moeten passen. Dit commando reto
 
 Als de bijdrager een Git gebruiker is en zo vriendelijk is geweest om het `format-patch` commando te gebruiken om de patch te genereren, dan is je werk eenvoudiger omdat de patch de auteur informatie en een commit bericht voor je bevat. Als het enigzins kan, probeer dan je bijdragers aan te moedigen om `format-patch` te gebruiken in plaats van `diff` om patches te genereren voor je. Je zou alleen `git apply` willen hoeven te gebruiken voor oude patches en dat soort dingen.
 
-Om een patch gegenereerd met `format-patch` toe te passen, gebruik je `git am`. Technisch is `git am` gemaakt om een mbox bestand te lezen, dat een eenvoudig gewone platte tekstformaat is om ��n of meer e-mail berichten in een tekstbestand op te slaan. Het ziet er ongeveer zo uit:
+Om een patch gegenereerd met `format-patch` toe te passen, gebruik je `git am`. Technisch is `git am` gemaakt om een mbox bestand te lezen, dat een eenvoudig gewone platte tekstformaat is om één of meer e-mail berichten in een tekstbestand op te slaan. Het ziet er ongeveer zo uit:
 
 	From 330090432754092d704da8e76ca5c05c198e71a8 Mon Sep 17 00:00:00 2001
 	From: Jessica Smith <jessica@example.com>
@@ -635,9 +635,9 @@ Om een patch gegenereerd met `format-patch` toe te passen, gebruik je `git am`.
 
 	Limit log functionality to the first 20
 
-Dit is het begin van de uitvoer van het format-patch commando dat je gezien hebt in de vorige paragraaf. Dit is ook een geldig mbox e-mail formaat. Als iemand jou de patch correct gemaild heeft door gebruik te maken van git send-email en je downloadt dat in een mbox formaat, dan kan je het git am naar dat mbox bestand verwijzen, en het zal beginnen met alle patches die het tegenkomt toe te passen. Als je een mail client gebruikt die meerdere e-mails kan opslaan in mbox formaat, dan kun je hele reeksen patches in een bestand opslaan en dan git am gebruiken om ze ��n voor ��n toe te passen.
+Dit is het begin van de uitvoer van het format-patch commando dat je gezien hebt in de vorige paragraaf. Dit is ook een geldig mbox e-mail formaat. Als iemand jou de patch correct gemaild heeft door gebruik te maken van git send-email en je downloadt dat in een mbox formaat, dan kan je het git am naar dat mbox bestand verwijzen, en het zal beginnen met alle patches die het tegenkomt toe te passen. Als je een mail client gebruikt die meerdere e-mails kan opslaan in mbox formaat, dan kun je hele reeksen patches in een bestand opslaan en dan git am gebruiken om ze één voor één toe te passen.
 
-Maar, als iemand een patch bestand heeft ge�pload die gegenereerd is met `format-patch` naar een ticket systeem of zoiets, kun je het bestand lokaal opslaan en dan dat opgeslagen bestand aan `git am` doorgeven om het toe te passen:
+Maar, als iemand een patch bestand heeft ge�pload die gegenereerd is met `format-patch` naar een ticket systeem of zoiets, kun je het bestand lokaal opslaan en dan dat opgeslagen bestand aan `git am` doorgeven om het toe te passen:
 
 	$ git am 0001-limit-log-function.patch
 	Applying: add limit to log function
@@ -723,7 +723,7 @@ Als je maar af en toe met een persoon werkt, maar toch op deze manier van hen wi
 	 * branch            HEAD       -> FETCH_HEAD
 	Merge made by recursive.
 
-### Bepalen wat ge�ntroduceerd wordt ###
+### Bepalen wat geïntroduceerd wordt ###
 
 Je hebt een topic branch dat bijgedragen werk bevat. Nu kan je bepalen wat je er mee wilt doen. Deze paragraaf bekijkt een paar commando's nogmaals om te laten zien hoe je ze kunt gebruiken om precies te reviewen wat je zult introduceren als je dit merged in je hoofd branch.
 
@@ -742,7 +742,7 @@ Het is vaak handig om een review te krijgen van alle commits die in deze branch
 
 	    updated the gemspec to hopefully work better
 
-Om te zien welke wijzigingen door iedere commit worden ge�ntroduceert, onthoud dan dat je de `-p` optie kunt meegeven aan `git log` en dan zal het de diff weergeven die bij iedere commit wordt ge�ntroduceerd.
+Om te zien welke wijzigingen door iedere commit worden geïntroduceerd, onthoud dan dat je de `-p` optie kunt meegeven aan `git log` en dan zal het de diff weergeven die bij iedere commit wordt geïntroduceerd.
 
 Om een volledige diff te zien van wat zou gebeuren als je deze topic branch merged met een andere branch, zul je misschien een vreemde truc moeten toepassen om de juiste resultaten te krijgen. Je zult misschien denken om dit uit te voeren:
 
@@ -764,11 +764,11 @@ Maar, dat is niet handig, dus levert Git een andere verkorte manier om hetzelfde
 
 	$ git diff master...contrib
 
-Dit commando laat alleen het werk zien dat je huidige topic branch heeft ge�ntroduceerd sinds de gezamenlijke voorouder met master. Dat is een erg handige syntax om te onthouden.
+Dit commando laat alleen het werk zien dat je huidige topic branch heeft ge�ntroduceerd sinds de gezamenlijke voorouder met master. Dat is een erg handige syntax om te onthouden.
 
 ### Bijgedragen werk integreren ###
 
-Als al het werk in je onderwerp branch klaar is om te worden ge�ntegreerd in een hogere branch, dan is de vraag hoe het te doen. En daarnaast, welke werkwijze wil je gebruiken om je project te beheren? Je hebt een aantal keuzes, dus ik zal er een paar behandelen.
+Als al het werk in je onderwerp branch klaar is om te worden geïntegreerd in een hogere branch, dan is de vraag hoe het te doen. En daarbij, welke werkwijze wil je gebruiken om je project te beheren? Je hebt een aantal keuzes, dus ik zal er een paar behandelen.
 
 #### Merge werkwijzen ####
 
@@ -782,7 +782,7 @@ Figuur 5-20. Na het mergen van een topic branch.
 
 Dat is waarschijnlijk de eenvoudigste werkwijze, maar het wordt problematisch als je werkt met grotere repositories of projecten.
 
-Als je meer ontwikkelaars hebt of een groter project, dan zul je waarschijnlijk minstens een twee-fasen merge cyclus willen toepassen. In dat geval heb je twee langlopende branches, `master` en `develop`, waarbij je bepaalt dat `master` alleen vernieuwd wordt als een zeer stabiele release is gemaakt en alle nieuwe code ge�ntegreerd is in de `develop` branch. Je pushed beide branches op regelmatige basis naar de publieke repository. Iedere keer als je een nieuw topic branch hebt om te mergen (Figuur 5-21), merge je het in `develop` (Figuur 5-22). En als je een tag gemaakt heb van een release, doe je een fast-forward van `master` naar waar de nu stabiele `develop` branch is (Figuur 5-23).
+Als je meer ontwikkelaars hebt of een groter project, dan zul je waarschijnlijk minstens een twee-fasen merge cyclus willen toepassen. In dat geval heb je twee langlopende branches, `master` en `develop`, waarbij je bepaalt dat `master` alleen vernieuwd wordt als een zeer stabiele release is gemaakt en alle nieuwe code geïntegreerd is in de `develop` branch. Je pushed beide branches op regelmatige basis naar de publieke repository. Iedere keer als je een nieuw topic branch hebt om te mergen (Figuur 5-21), merge je het in `develop` (Figuur 5-22). En als je een tag gemaakt heb van een release, doe je een fast-forward van `master` naar waar de nu stabiele `develop` branch is (Figuur 5-23).
 
 Insert 18333fig0521.png
 Figuur 5-21. Voor een merge van een topic branch.
@@ -798,7 +798,7 @@ Je kunt dit concept ook verder doorvoeren, waarbij je een integratie branch hebt
 
 #### Werkwijzen met grote merges ####
 
-Het Git project heeft vier langlopende branches: `master`, `next`, en `pu` (proposed updates, voorgestelde vernieuwingen) voor nieuw spul, en `maint` voor onderhoudswerk. Als nieuw werk wordt ge�ntroduceerd door bijdragers, wordt het samengeraapt in topic branches in de repository van de beheerder op een manier die lijkt op wat ik omschreven heb (zie Figuur 5-24). Hier worden de topics ge�valueerd om te bepalen of ze veilig zijn en klaar voor verdere verwerking of dat ze nog wat werk nodig hebben. Als ze veilig zijn, worden ze in `next` gemerged, en wordt die branch gepushed zodat iedereen de ge�ntegreerde topics kan uitproberen.
+Het Git project heeft vier langlopende branches: `master`, `next`, en `pu` (proposed updates, voorgestelde vernieuwingen) voor nieuw spul, en `maint` voor onderhoudswerk. Als nieuw werk wordt geïntroduceerd door bijdragers, wordt het samengeraapt in topic branches in de repository van de beheerder op een manier die lijkt op wat ik omschreven heb (zie Figuur 5-24). Hier worden de topics geëvalueerd om te bepalen of ze veilig zijn en klaar voor verdere verwerking of dat ze nog wat werk nodig hebben. Als ze veilig zijn, worden ze in `next` gemerged, en wordt die branch gepushed zodat iedereen de geïntegreerde topics kan uitproberen.
 
 Insert 18333fig0524.png
 Figuur 5-24. Een complexe serie van parallel bijgedragen topic branches beheren.
@@ -814,7 +814,7 @@ Als een onderwerp branch uiteindelijk is gemerged in `master`, dan wordt het ver
 
 Andere beheerders geven de voorkeur aan rebasen of bijgedragen werk te cherry picken naar hun master branch in plaats van ze erin te mergen, om een vrijwel lineaire historie te behouden. Als je werk in een topic branch hebt en hebt besloten dat je het wil integreren, dan ga je naar die branch en voert het rebase commando uit om de wijzigingen op je huidige master branch te baseren (of `develop`, enzovoorts). Als dat goed werkt, dan kun je de `master` branch fast-forwarden, en eindig je met een lineaire project historie.
 
-De andere manier om ge�ntroduceerd werk van de ene naar de andere branch te verplaatsen is om het te cherry picken. Een cherry-pick in Git is een soort rebase voor een enkele commit. Het pakt de patch die was ge�ntroduceerd in een commit en probeert die weer toe te passen op de branch waar je nu op zit. Dit is handig als je een aantal commits op een topic branch hebt en je er slechts ��n van wilt integreren, of als je alleen ��n commit op een topic branch hebt en er de voorkeur aan geeft om het te cherry-picken in plaats van rebase uit te voeren. Bijvoorbeeld, stel dat je een project hebt dat eruit ziet als Figuur 5-26.
+De andere manier om geïntroduceerd werk van de ene naar de andere branch te verplaatsen is om het te cherry picken. Een cherry-pick in Git is een soort rebase voor een enkele commit. Het pakt de patch die was geïntroduceerd in een commit en probeert die weer toe te passen op de branch waar je nu op zit. Dit is handig als je een aantal commits op een topic branch hebt en je er slechts één van wilt integreren, of als je alleen één commit op een topic branch hebt en er de voorkeur aan geeft om het te cherry-picken in plaats van rebase uit te voeren. Bijvoorbeeld, stel dat je een project hebt dat eruit ziet als Figuur 5-26.
 
 Insert 18333fig0526.png
 Figuur 5-26. Voorbeeld historie voor een cherry pick.
@@ -826,7 +826,7 @@ Als je commit `e43a6` in je master branch wilt pullen, dan kun je dit uitvoeren
 	[master]: created a0a41a9: "More friendly message when locking the index fails."
 	 3 files changed, 17 insertions(+), 3 deletions(-)
 
-Dit pulled dezelfde wijziging zoals ge�ntroduceerd in `e43a6`, maar je krijgt een nieuwe SHA-1 waarde, omdat de gegevens op een andere manier toegepast zijn. Nu ziet je historie eruit als Figuur 5-27.
+Dit pulled dezelfde wijziging zoals geïntroduceerd in `e43a6`, maar je krijgt een nieuwe SHA-1 waarde, omdat de gegevens op een andere manier toegepast zijn. Nu ziet je historie eruit als Figuur 5-27.
 
 Insert 18333fig0527.png
 Figuur 5-27. Historie na het cherry-picken van een commit op een topic branch.
@@ -860,11 +860,11 @@ Nu dat je de inhoud van je sleutel in Git hebt, kun je een tag aanmaken die dire
 
 	$ git tag -a maintainer-pgp-pub 659ef797d181633c87ec71ac3f9ba29fe5775b92
 
-Als je `git push --tags` uitvoert, zal de `maintainer-pgp-pub` tag met iedereen gedeeld worden. Als iemand een tag wil verifi�ren, dan kunnen ze jouw PGP sleutel direct importeren door de blob direct uit de database te halen en het in GPG te importeren:
+Als je `git push --tags` uitvoert, zal de `maintainer-pgp-pub` tag met iedereen gedeeld worden. Als iemand een tag wil verifiëren, dan kunnen ze jouw PGP sleutel direct importeren door de blob direct uit de database te halen en het in GPG te importeren:
 
 	$ git show maintainer-pgp-pub | gpg --import
 
-Ze kunnen die sleutel gebruiken om al je gesigneerde tags te verifi�ren. Als je instructies in het tag bericht zet, dan zal `git show <tag>` je eindgebruikers meer specifieke instructies geven over tag verificatie.
+Ze kunnen die sleutel gebruiken om al je gesigneerde tags te verifiëren. Als je instructies in het tag bericht zet, dan zal `git show <tag>` je eindgebruikers meer specifieke instructies geven over tag verificatie.
 
 ### Een bouw nummer genereren ###
 
@@ -875,7 +875,7 @@ Omdat Git geen monotone oplopende nummers heeft zoals 'v123' of iets gelijkwaard
 
 Op deze manier kun je een snapshot of "build" exporteren en het vernoemen naar iets dat begrijpelijk is voor mensen. Sterker nog: als je Git, gekloond van het Git repository, vanaf broncode bouwt geeft `git --version` je iets dat er zo uitziet. Als je een commit omschrijft die je direct getagged hebt, dan krijg je de tag naam.
 
-Het `git describe` commando geeft beschreven tags de voorkeur (tags gecre�erd met de `-a` of `-s` vlag), dus release tags moeten op deze manier aangemaakt worden als je `git describe` gebruikt, om er zeker van te zijn dat de commit juist benoemd wordt als het omschreven wordt. Je kunt deze tekst ook gebruiken als het doel van een checkout of show commando, alhoewel het afhankelijk is van de verkorte SHA-1 waarde aan het einde, dus het zou niet eeuwig geldig kunnen zijn. Bijvoorbeeld, de Linux kernel sprong recentelijk van 8 naar 10 karakters om er zeker van de zijn dat de SHA-1 uniek zijn, oudere `git describe` commando's werden daardoor ongeldig.
+Het `git describe` commando geeft beschreven tags de voorkeur (tags gemaakt met de `-a` of `-s` vlag), dus release tags moeten op deze manier aangemaakt worden als je `git describe` gebruikt, om er zeker van te zijn dat de commit juist benoemd wordt als het omschreven wordt. Je kunt deze tekst ook gebruiken als het doel van een checkout of show commando, alhoewel het afhankelijk is van de verkorte SHA-1 waarde aan het einde, dus het zou niet eeuwig geldig kunnen zijn. Bijvoorbeeld, de Linux kernel sprong recentelijk van 8 naar 10 karakters om er zeker van de zijn dat de SHA-1 uniek zijn, oudere `git describe` commando's werden daardoor ongeldig.
 
 ### Een release voorbereiden ###
 
@@ -914,4 +914,4 @@ Je krijgt een opgeschoonde samenvatting van alle commits sinds v1.0.1, gegroepee
 
 ## Samenvatting ##
 
-Je zou je nu redelijk op je gemak moeten voelen om aan een project bij te dragen met Git, maar ook om je eigen project te beheren of de bijdragen van andere gebruikers te integreren. Gefeliciteerd met het worden van een effectieve Git ontwikkelaar! In het volgende hoofdstuk zul je nog krachtigere tools en trucs leren voor het omgaan met complexe situaties, die je een echte Git meester zullen maken.
+Je zou je nu redelijk op je gemak moeten voelen om aan een project bij te dragen met Git, maar ook om je eigen project te beheren of de bijdragen van andere gebruikers te integreren. Gefeliciteerd, je bent nu een effectieve Git ontwikkelaar! In het volgende hoofdstuk zul je nog krachtigere tools en trucs leren voor het omgaan met complexe situaties, die je een echte Git meester zullen maken.

From b5bb8388ee856dbf34c4e276cd3d3d82ecd2a932 Mon Sep 17 00:00:00 2001
From: Matt Deacalion Stevens <matt@dirtymonkey.co.uk>
Date: Thu, 30 Jan 2014 02:00:00 +0000
Subject: [PATCH 142/690] Update command line output in Chapter 4.2

The command line output in the examples is from an older version of Git
(1.7.*) and is slightly inconsistent with the latest version.
---
 en/04-git-server/01-chapter4.markdown | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/en/04-git-server/01-chapter4.markdown b/en/04-git-server/01-chapter4.markdown
index c0e35ec3f..7a57171f6 100644
--- a/en/04-git-server/01-chapter4.markdown
+++ b/en/04-git-server/01-chapter4.markdown
@@ -117,7 +117,8 @@ In order to initially set up any Git server, you have to export an existing repo
 In order to clone your repository to create a new bare repository, you run the clone command with the `--bare` option. By convention, bare repository directories end in `.git`, like so:
 
 	$ git clone --bare my_project my_project.git
-	Initialized empty Git repository in /opt/projects/my_project.git/
+	Cloning into bare repository 'my_project.git'...
+	done.
 
 The output for this command is a little confusing. Since `clone` is basically a `git init` then a `git fetch`, we see some output from the `git init` part, which creates an empty directory. The actual object transfer gives no output, but it does happen. You should now have a copy of the Git directory data in your `my_project.git` directory.
 

From de84431607fe66fe3cb42ff30b2dd01d61e4f495 Mon Sep 17 00:00:00 2001
From: Matt Deacalion Stevens <matt@dirtymonkey.co.uk>
Date: Thu, 30 Jan 2014 02:00:00 +0000
Subject: [PATCH 143/690] Update command line output in Chapter 4.5

The command line output in the examples is from an older version of Git
(1.7.*) and is slightly inconsistent with the latest version.
---
 en/04-git-server/01-chapter4.markdown | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/en/04-git-server/01-chapter4.markdown b/en/04-git-server/01-chapter4.markdown
index 7a57171f6..52651cff7 100644
--- a/en/04-git-server/01-chapter4.markdown
+++ b/en/04-git-server/01-chapter4.markdown
@@ -288,6 +288,13 @@ What does this `post-update` hook do? It looks basically like this:
 
 	$ cat .git/hooks/post-update
 	#!/bin/sh
+	#
+	# An example hook script to prepare a packed repository for use over
+	# dumb transports.
+	#
+	# To enable this hook, rename this file to "post-update".
+	#
+	
 	exec git-update-server-info
 
 This means that when you push to the server via SSH, Git will run this command to update the files needed for HTTP fetching.

From 4a0e143e25dbd0ec108080431b0dee00d440e8c0 Mon Sep 17 00:00:00 2001
From: Matt Deacalion Stevens <matt@dirtymonkey.co.uk>
Date: Thu, 30 Jan 2014 02:00:00 +0000
Subject: [PATCH 144/690] Update command line output in Chapter 4.7

The command line output in the examples is from an older version of Git
(1.7.*) and Gitosis. Both being slightly inconsistent with the latest
versions.
---
 en/04-git-server/01-chapter4.markdown | 32 +++++++++++++--------------
 1 file changed, 16 insertions(+), 16 deletions(-)

diff --git a/en/04-git-server/01-chapter4.markdown b/en/04-git-server/01-chapter4.markdown
index 52651cff7..9f5c9a0ed 100644
--- a/en/04-git-server/01-chapter4.markdown
+++ b/en/04-git-server/01-chapter4.markdown
@@ -410,7 +410,7 @@ You’re ready to roll. If you’re set up correctly, you can try to SSH into yo
 
 	$ ssh git@gitserver
 	PTY allocation request failed on channel 0
-	fatal: unrecognized command 'gitosis-serve schacon@quaternion'
+	ERROR:gitosis.serve.main:Need SSH_ORIGINAL_COMMAND in environment.
 	  Connection to gitserver closed.
 
 That means Gitosis recognized you but shut you out because you’re not trying to do any Git commands. So, let’s do an actual Git command — you’ll clone the Gitosis control repository:
@@ -434,28 +434,28 @@ If you look at the `gitosis.conf` file, it should only specify information about
 	[gitosis]
 
 	[group gitosis-admin]
-	writable = gitosis-admin
 	members = scott
+	writable = gitosis-admin
 
 It shows you that the 'scott' user — the user with whose public key you initialized Gitosis — is the only one who has access to the `gitosis-admin` project.
 
 Now, let’s add a new project for you. You’ll add a new section called `mobile` where you’ll list the developers on your mobile team and projects that those developers need access to. Because 'scott' is the only user in the system right now, you’ll add him as the only member, and you’ll create a new project called `iphone_project` to start on:
 
 	[group mobile]
-	writable = iphone_project
 	members = scott
+	writable = iphone_project
 
 Whenever you make changes to the `gitosis-admin` project, you have to commit the changes and push them back up to the server in order for them to take effect:
 
 	$ git commit -am 'add iphone_project and mobile group'
-	[master]: created 8962da8: "changed name"
-	 1 files changed, 4 insertions(+), 0 deletions(-)
-	$ git push
+	[master 8962da8] add iphone_project and mobile group
+	 1 file changed, 4 insertions(+)
+	$ git push origin master
 	Counting objects: 5, done.
-	Compressing objects: 100% (2/2), done.
-	Writing objects: 100% (3/3), 272 bytes, done.
-	Total 3 (delta 1), reused 0 (delta 0)
-	To git@gitserver:/opt/git/gitosis-admin.git
+	Compressing objects: 100% (3/3), done.
+	Writing objects: 100% (3/3), 272 bytes | 0 bytes/s, done.
+	Total 3 (delta 0), reused 0 (delta 0)
+	To git@gitserver:gitosis-admin.git
 	   fb27aec..8962da8  master -> master
 
 You can make your first push to the new `iphone_project` project by adding your server as a remote to your local version of the project and pushing. You no longer have to manually create a bare repository for new projects on the server — Gitosis creates them automatically when it sees the first push:
@@ -464,7 +464,7 @@ You can make your first push to the new `iphone_project` project by adding your
 	$ git push origin master
 	Initialized empty Git repository in /opt/git/iphone_project.git/
 	Counting objects: 3, done.
-	Writing objects: 100% (3/3), 230 bytes, done.
+	Writing objects: 100% (3/3), 230 bytes | 0 bytes/s, done.
 	Total 3 (delta 0), reused 0 (delta 0)
 	To git@gitserver:iphone_project.git
 	 * [new branch]      master -> master
@@ -480,20 +480,20 @@ You want to work on this project with your friends, so you’ll have to re-add t
 Now you can add them all to your 'mobile' team so they have read and write access to `iphone_project`:
 
 	[group mobile]
-	writable = iphone_project
 	members = scott john josie jessica
+	writable = iphone_project
 
 After you commit and push that change, all four users will be able to read from and write to that project.
 
 Gitosis has simple access controls as well. If you want John to have only read access to this project, you can do this instead:
 
 	[group mobile]
-	writable = iphone_project
 	members = scott josie jessica
+	writable = iphone_project
 
 	[group mobile_ro]
-	readonly = iphone_project
 	members = john
+	readonly = iphone_project
 
 Now John can clone the project and get updates, but Gitosis won’t allow him to push back up to the project. You can create as many of these groups as you want, each containing different users and projects. You can also specify another group as one of the members (using `@` as prefix), to inherit all of its members automatically:
 
@@ -501,12 +501,12 @@ Now John can clone the project and get updates, but Gitosis won’t allow him to
 	members = scott josie jessica
 
 	[group mobile]
-	writable  = iphone_project
 	members   = @mobile_committers
+	writable  = iphone_project
 
 	[group mobile_2]
-	writable  = another_iphone_project
 	members   = @mobile_committers john
+	writable  = another_iphone_project
 
 If you have any issues, it may be useful to add `loglevel=DEBUG` under the `[gitosis]` section. If you’ve lost push access by pushing a messed-up configuration, you can manually fix the file on the server under `/home/git/.gitosis.conf` — the file from which Gitosis reads its info. A push to the project takes the `gitosis.conf` file you just pushed up and sticks it there. If you edit that file manually, it remains like that until the next successful push to the `gitosis-admin` project.
 

From 4946e881565e33eba1c9e1bf1a4fffd6f10f4420 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?P=C3=A9ter=20Kalicz?= <kaliczp@gmail.com>
Date: Sat, 1 Feb 2014 23:26:05 +0100
Subject: [PATCH 145/690] Tiny spelling correction

---
 hu/01-introduction/01-chapter1.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hu/01-introduction/01-chapter1.markdown b/hu/01-introduction/01-chapter1.markdown
index 8bb5f20d7..c3cef723a 100644
--- a/hu/01-introduction/01-chapter1.markdown
+++ b/hu/01-introduction/01-chapter1.markdown
@@ -32,7 +32,7 @@ Ugyanakkor ez az összeállításnak van néhány komoly hátránya. A legnyílv
 
 ### Elosztott verziókövető rendszerek ###
 
-Ekkor jöttek az Elosztott Verziókövető Rendszerek (EVR). Az EVR-ekben, mint a Git, a Mercurical, a Bazaar vagy a Dracs, a kliensek nem csak a legutolsó állapotot kérik le, hanem a teljes repositorit. Ekéépen ha a szerver megáll, amin eddig folyt az együttműködés, bármelyik kliens repositoriból vissza állítható a teljes adatbázis. Minden adat lekrés tényleg teljes mentésnek felel meg (Lásd 1-3 ábra).
+Ekkor jöttek az Elosztott Verziókövető Rendszerek (EVR). Az EVR-ekben, mint a Git, a Mercurical, a Bazaar vagy a Dracs, a kliensek nem csak a legutolsó állapotot kérik le, hanem a teljes repositorit. Ekéépen ha a szerver megáll, amin eddig folyt az együttműködés, bármelyik kliens repositoriból vissza állítható a teljes adatbázis. Minden adat lekérés tényleg teljes mentésnek felel meg (Lásd 1-3 ábra).
 
 Insert 18333fig0103.png
 1-3 ábra. Elosztott verziókövetés sematikus ábrája.

From 4f40e142fe95a76406fc3297693fdee0bdd1237a Mon Sep 17 00:00:00 2001
From: Yue Lin Ho <b8732003@student.nsysu.edu.tw>
Date: Sun, 2 Feb 2014 16:57:35 +0800
Subject: [PATCH 146/690] [zh-tw] Synchronize with En version

---
 zh-tw/01-introduction/01-chapter1.markdown    |  24 +-
 zh-tw/02-git-basics/01-chapter2.markdown      | 383 ++++++++++--------
 zh-tw/06-git-tools/01-chapter6.markdown       |  28 +-
 zh-tw/07-customizing-git/01-chapter7.markdown | 115 ++++--
 .../01-chapter8.markdown                      |  24 +-
 zh-tw/09-git-internals/01-chapter9.markdown   |  60 +--
 6 files changed, 365 insertions(+), 269 deletions(-)

diff --git a/zh-tw/01-introduction/01-chapter1.markdown b/zh-tw/01-introduction/01-chapter1.markdown
index 93abf46a6..bbd0e2701 100644
--- a/zh-tw/01-introduction/01-chapter1.markdown
+++ b/zh-tw/01-introduction/01-chapter1.markdown
@@ -1,14 +1,11 @@
 # 開始 #
 
-
 本章介紹Git的相關知識。 先從講解一些版本控制工具的背景知識開始，然後試著在讀者的系統將Git跑起來，最後則是設定它。 在本章結束後，讀者應瞭解為什麼Git如 此流行、為什麼讀者應該利用它、以及完成使用它的準備工作。
 
 ## 關於版本控制 ##
 
-
 什麼是版本控制？ 以及為什麼讀者會在意它？ 版本控制是一個能夠記錄一個或一組檔案在某一段時間的變更，使得讀者以後能取回特定版本的系統。 在本書的範例中，讀者會學到如何對軟體的原始碼做版本控制。 即使實際上讀者幾乎可以針對電腦上任意型態的檔案做版本控制。
 
-
 若讀者是繪圖或網頁設計師且想要記錄每一版影像或版面配置（這也通常是讀者想要做的），採用版本控制系統（VCS）做這件事是非常明智的。 它允許讀者將檔案復原到原本的狀態、將整個專案復原到先前的狀態、比對某一段時間的修改、查看最後是誰在哪個時間點做了錯誤的修改導致問題發生，等。 使用版本控制系統一般也意謂著若讀者做了一些傻事或者遺失檔案，讀者能很容易地回復到原先的狀態。 更進一步，僅需付出很小的代價即可得到這些優點。
 
 ### 本地端版本控制 ###
@@ -17,17 +14,16 @@
 
 為了解決這問題，程式設計師在很久以前開發了本地端的版本控制系統，具備簡單的資料庫，用來記載檔案的所有變更記錄（參考圖1-1）。
 
-Insert 18333fig0101.png 
+Insert 18333fig0101.png
 圖1-1. 本地端版本控制流程圖。
 
 這種版本控制工具中最流行的是rcs，目前仍存在於許多電腦。 即使是流行的Mac OS X作業系統，都會在讀者安裝開發工具時安裝rcs命令。 此工具基本上以特殊的格式記錄修補集合（patch set，即檔案從一個版本變更到另一個版本所需資訊），並儲存於磁碟上。 它就可以藉由套用各修補集合産生各時間點的檔案內容。
 
 ### 集中式版本控制系統 ###
 
-
 接下來人們遇到的主要問題是需要在多種其它系統上的開發協同作業。 為了解決此問題，集中式版本控制系統(Centralized Version Control Systems，簡稱CVCSs)被發展出來。 此系統，如：CVS、Subversion及Perforce皆具備單一伺服器，記錄所有版本的檔案，且有多個客戶端從伺服器從伺服器取出檔案。 在多年後，這已經是版本控制系統的標準（參考圖1-2）。
 
-Insert 18333fig0102.png 
+Insert 18333fig0102.png
 圖1-2. 集中式版本控制系統
 
 這樣的配置提供了很多優點，特別是相較於本地端的版本控制系統來說。 例如：每個人皆能得知其它人對此專案做了些什麼修改有一定程度的瞭解。 管理員可調整存取權限，限制各使用者能做的事。 而且維護集中式版本控制系統也比維護散落在各使用者端的資料庫來的容易。
@@ -38,7 +34,7 @@ Insert 18333fig0102.png
 
 這就是分散式版本控制系統(Distributed Version Control Systems, 簡稱DVCSs)被引入的原因。 在分散式版本控制系統，諸如：Git、Mercurial、Bazaar、Darcs。 客戶端不只是取出最後一版的檔案，而是完整複製整個儲存庫。 即使是整個系統賴以運作的電腦損毀，皆可將任何一個客戶端先前複製的資料還原到伺服器。 每一次的取出動作實際上就是完整備份整個儲存庫。（參考圖1-3）
 
-Insert 18333fig0103.png 
+Insert 18333fig0103.png
 圖1-3. 分散式版本控制系統
 
 更進一步來說，許多這類型的系統皆能同時與數個遠端的機器同時運作。 因此讀者能同時與許多不同群組的人們協同開發同一個專案。 這允許讀者設定多種集中式系統做不到的工作流程，如：階層式模式。
@@ -65,12 +61,12 @@ Insert 18333fig0103.png
 
 Git與其它版本控制系統（包含Subversion以及與它相關的）的差別是如何處理資料的方式。 一般來說，大部份其它系統記錄資訊是一連串檔案更動的內容。 如圖1-4所示。 這些系統（CVS、Subversion、Perforce、Bazaar等等）儲存一組基本的檔案以及對應這些檔案隨時間遞增的更動資料。
 
-Insert 18333fig0104.png 
+Insert 18333fig0104.png
 圖1-4. 其它系統傾向儲存每個檔案更動的資料。
 
 Git並不以此種方式儲存資料。 而是將其視為小型檔案系統的一組快照(Snapshot)。 每一次讀者提交更新時、或者儲存目前專案的狀態到Git時。 基本上它為當時的資料做一組快照並記錄參考到該快照的參考點。 為了講求效率，只要檔案沒有變更，Git不會再度儲存該檔案，而是記錄到前一次的相同檔案的連結。 Git的工作方式如圖1-5所示。
 
-Insert 18333fig0105.png 
+Insert 18333fig0105.png
 圖1-5. Git儲存每次專案更新時的快照。
 
 這是Git與所有其它版本控制系統最重要的區別。 它完全顛覆傳統版本控制的作法。 這使用Git更像一個上層具備更強大工具的小型檔案系統，而不只是版本控制系統。 我們將會在第三章介紹分支時，提到採用此種作法的優點。
@@ -105,7 +101,7 @@ Git用來計算查核碼的機制稱為SHA-1雜湊法。 它由40個十六進制
 
 這帶領我們到Git專案的三個主要區域：Git目錄、工作目錄(working directory)以及暫存區域(staging area)。
 
-Insert 18333fig0106.png 
+Insert 18333fig0106.png
 圖1-6. 工作目錄、暫存區域及git目錄。
 
 Git目錄是Git用來儲存讀者的專案的元數據及物件資料庫。 這是Git最重要的部份，而且它是當讀者從其它電腦複製儲存庫時會複製過來的。
@@ -141,7 +137,7 @@ Git目錄是Git用來儲存讀者的專案的元數據及物件資料庫。 這
 當讀者安裝所有必要的程式庫，讀者可到Git的網站取得最新版本：
 
 	http://git-scm.com/download
-	
+
 接著，編譯及安裝：
 
 	$ tar -zxf git-1.6.0.5.tar.gz
@@ -152,7 +148,7 @@ Git目錄是Git用來儲存讀者的專案的元數據及物件資料庫。 這
 在這些工作完成後，讀者也可以使用Git取得Git的更新版：
 
 	$ git clone git://git.kernel.org/pub/scm/git/git.git
-	
+
 ### 在Linux系統安裝 ###
 
 若讀者想使用二進位安裝程式安裝Git到Linux，一般來說讀者可經由發行套件提供的套件管理工具完成此工作。 若讀者使用Fedora，可使用`yum`：
@@ -169,7 +165,7 @@ Git目錄是Git用來儲存讀者的專案的元數據及物件資料庫。 這
 
 	http://code.google.com/p/git-osx-installer
 
-Insert 18333fig0107.png 
+Insert 18333fig0107.png
 圖1-7. Git OS X 安裝程式。
 
 藉由MacPorts安裝Git是另一種主要的方法。 若讀者已安裝MacPorts，使用下列命令安裝Git
@@ -214,7 +210,7 @@ Git附帶名為`git config`的工具，允許讀者取得及設定組態參數
 現在讀者的識別資料已設定完畢，讀者可設定預設的文書編輯器，當Git需要讀者輸入訊息時會叫用它。 預設情況下，Git會使用系統預設的編輯器，一般來說是Vi或Vim。 若讀者想指定不同的編輯器，例如：Emacs。可執行下列指令：
 
 	$ git config --global core.editor emacs
-	
+
 ### 指定合併工具 ###
 
 另外一個對讀者來說有用的選項是設定解決合併失敗時，讀者慣用的合併工具。 假設讀者想使用vimdiff：
diff --git a/zh-tw/02-git-basics/01-chapter2.markdown b/zh-tw/02-git-basics/01-chapter2.markdown
index 5bf05a15c..d05734c1c 100644
--- a/zh-tw/02-git-basics/01-chapter2.markdown
+++ b/zh-tw/02-git-basics/01-chapter2.markdown
@@ -46,7 +46,7 @@ Git提供很多種協定給讀者使用。 上一個範例採用 `git://` 協定
 
 只要讀者編輯任何已被追蹤的檔案。 Git將它們視為被更動的，因為讀者將它們改成與最後一次提交不同。 讀者暫存這些已更動檔案並提供所有被暫存的更新， 並重複此週期。 此生命週期如圖2-1所示。
 
-Insert 18333fig0201.png 
+Insert 18333fig0201.png
 圖2-1. 檔案狀態的生命週期。
 
 ### 檢視檔案的狀態 ###
@@ -54,8 +54,8 @@ Insert 18333fig0201.png
 主要給讀者用來檢視檔案的狀態是 git status 命令。 若讀者在複製完複本後馬上執行此命令，會看到如下的文字：
 
 	$ git status
-	# On branch master
-	nothing to commit (working directory clean)
+	On branch master
+	nothing to commit, working directory clean
 
 這意謂著讀者有一份乾淨的工作目錄（換句話說，沒有未被追蹤或已被修改的檔案）。 Git未看到任何未被追蹤的檔案，否則會將它們列出。 最後，這個命令告訴讀者目前在哪一個分支。 到目前為止，一直都是master，這是預設的。 目前讀者不用考慮它。 下一個章節會詳細介紹分支。
 
@@ -63,11 +63,12 @@ Insert 18333fig0201.png
 
 	$ vim README
 	$ git status
-	# On branch master
-	# Untracked files:
-	#   (use "git add <file>..." to include in what will be committed)
-	#
-	#	README
+	On branch master
+	Untracked files:
+	  (use "git add <file>..." to include in what will be committed)
+	
+	        README
+
 	nothing added to commit but untracked files present (use "git add" to track)
 
 讀者可看到新增的`README`尚未被追蹤，因為它被列在輸出訊息的 Untracked files 下方。 除非讀者明確指定要將該檔案加入提交的快照，Git不會主動將它加入。 這樣就不會突然地將一些二進位格式的檔案或其它讀者並不想加入的檔案含入。 讀者的確是要新增 `README` 檔案，因此讓我們開始追蹤該檔案。
@@ -81,12 +82,12 @@ Insert 18333fig0201.png
 若讀者再度檢查目前狀態，可看到`README`檔案已被列入追蹤並且已被暫存：
 
 	$ git status
-	# On branch master
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#	new file:   README
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        new file:   README
+	
 
 因為它被放在Changes to be commited文字下方，讀者可得知它已被暫存起來。 若讀者此時提交更新，剛才執行`git add`加進來的檔案就會被記錄在歷史的快照。 讀者可能可回想一下先前執行`git init`後也有執行過`git add`，開始追蹤目錄內的檔案。 `git add`命令可接受檔名或者目錄名。 若是目錄名，會遞迴將整個目錄下所有檔案及子目錄都加進來。
 
@@ -95,58 +96,60 @@ Insert 18333fig0201.png
 讓我們修改已被追蹤的檔案。 若讀者修改先前已被追蹤的檔案，名為`benchmarks.rb`，並檢查目前儲存庫的狀態。 讀者會看到類似以下文字：
 
 	$ git status
-	# On branch master
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#	new file:   README
-	#
-	# Changes not staged for commit:
-	#   (use "git add <file>..." to update what will be committed)
-	#
-	#	modified:   benchmarks.rb
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        new file:   README
+
+	Changes not staged for commit:
+	  (use "git add <file>..." to update what will be committed)
+	  (use "git checkout -- <file>..." to discard changes in working directory)
+	
+	        modified:   benchmarks.rb
+	
 
 `benchmarks.rb`檔案出現在 “Changes not staged for commit” 下方，代表著這個檔案已被追蹤，而且位於工作目錄的該檔案已被修改，但尚未暫存。 要暫存該檔案，可執行`git add`命令（這是一個多重用途的指令）。現在，讀者使用 `git add` 將`benchmarks.rb`檔案暫存起來，並再度執行`git status`：
 
 	$ git add benchmarks.rb
 	$ git status
-	# On branch master
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#	new file:   README
-	#	modified:   benchmarks.rb
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        new file:   README
+	        modified:   benchmarks.rb
+	
 
 這兩個檔案目前都被暫存起來，而且會進入下一次的提交。 假設讀者記得仍需要對`benchmarks.rb`做一點修改後才要提交，可再度開啟並編輯該檔案。 然而，當我們再度執行`git status`：
 
-	$ vim benchmarks.rb 
+	$ vim benchmarks.rb
 	$ git status
-	# On branch master
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#	new file:   README
-	#	modified:   benchmarks.rb
-	#
-	# Changes not staged for commit:
-	#   (use "git add <file>..." to update what will be committed)
-	#
-	#	modified:   benchmarks.rb
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        new file:   README
+	        modified:   benchmarks.rb
+	
+	Changes not staged for commit:
+	  (use "git add <file>..." to update what will be committed)
+	  (use "git checkout -- <file>..." to discard changes in working directory)
+	
+	        modified:   benchmarks.rb
+	
 
 到底發生了什麼事？ 現在`benchmarks.rb`同時被列在已被暫存及未被暫存。 這怎麼可能？ 這表示Git的確在讀者執行`git add`命令後，將檔案暫存起來。 若讀者現在提交更新，最近一次執行`git add`命令時暫存的`benchmarks.rb`會被提交。 若讀者在`git add`後修改檔案，需要再度執行`git add`將最新版的檔案暫存起來：
 
 	$ git add benchmarks.rb
 	$ git status
-	# On branch master
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#	new file:   README
-	#	modified:   benchmarks.rb
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        new file:   README
+	        modified:   benchmarks.rb
+	
 
 ### 忽略某些檔案 ###
 
@@ -167,7 +170,6 @@ Insert 18333fig0201.png
 
 Glob pattern就像是shell使用的簡化版正規運算式。 星號（`*`）匹配零個或多個字元；`[abc]`匹配中括弧內的任一字元（此例為`a`、`b`、`c`）；問號（`?`）匹配單一個字元；中括孤內的字以連字符連接（如：`[0-9]`），用來匹配任何符合該範圍的字（此例為0到9）。
 
-
 以下是另一個`.gitignore`的範例檔案：
 
 	# 註解，會被忽略。
@@ -181,6 +183,10 @@ Glob pattern就像是shell使用的簡化版正規運算式。 星號（`*`）
 	build/
 	# 忽略doc/notes.txt但不包含doc/server/arch.txt
 	doc/*.txt
+	# ignore all .txt files in the doc/ directory
+	doc/**/*.txt
+
+A `**/` pattern is available in Git since version 1.8.2.
 
 ### 檢視已暫存及尚未暫存的更動 ###
 
@@ -189,17 +195,18 @@ Glob pattern就像是shell使用的簡化版正規運算式。 星號（`*`）
 假設讀者編輯並暫存`README`，接者修改`benchmarks.rb`檔案，卻未暫存。 若讀者檢視目前的狀況，會看到類似下方文字：
 
 	$ git status
-	# On branch master
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#	new file:   README
-	#
-	# Changes not staged for commit:
-	#   (use "git add <file>..." to update what will be committed)
-	#
-	#	modified:   benchmarks.rb
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        new file:   README
+	
+	Changes not staged for commit:
+	  (use "git add <file>..." to update what will be committed)
+	  (use "git checkout -- <file>..." to discard changes in working directory)
+	
+	        modified:   benchmarks.rb
+	
 
 想瞭解尚未暫存的修改，執行`git diff`，不用帶任何參數：
 
@@ -244,20 +251,22 @@ Glob pattern就像是shell使用的簡化版正規運算式。 星號（`*`）
 	$ git add benchmarks.rb
 	$ echo '# test line' >> benchmarks.rb
 	$ git status
-	# On branch master
-	#
-	# Changes to be committed:
-	#
-	#	modified:   benchmarks.rb
-	#
-	# Changes not staged for commit:
-	#
-	#	modified:   benchmarks.rb
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        modified:   benchmarks.rb
+	
+	Changes not staged for commit:
+	  (use "git add <file>..." to update what will be committed)
+	  (use "git checkout -- <file>..." to discard changes in working directory)
+	
+	        modified:   benchmarks.rb
+	
 
 現在讀者可使用`git diff`檢視哪些部份尚未被暫存：
 
-	$ git diff 
+	$ git diff
 	diff --git a/benchmarks.rb b/benchmarks.rb
 	index e445e28..86b2f7c 100644
 	--- a/benchmarks.rb
@@ -265,7 +274,7 @@ Glob pattern就像是shell使用的簡化版正規運算式。 星號（`*`）
 	@@ -127,3 +127,4 @@ end
 	 main()
 
-	 ##pp Grit::GitRuby.cache_client.stats 
+	 ##pp Grit::GitRuby.cache_client.stats
 	+# test line
 
 以及使用`git diff --cached`檢視目前已暫存的變更：
@@ -282,7 +291,7 @@ Glob pattern就像是shell使用的簡化版正規運算式。 星號（`*`）
 	+        run_code(x, 'commits 1') do
 	+          git.commits.size
 	+        end
-	+              
+	+
 	        run_code(x, 'commits 2') do
 	          log = git.commits('master', 15)
 	          log.size
@@ -302,10 +311,9 @@ Glob pattern就像是shell使用的簡化版正規運算式。 星號（`*`）
 	# with '#' will be ignored, and an empty message aborts the commit.
 	# On branch master
 	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
 	#       new file:   README
-	#       modified:   benchmarks.rb 
+	#       modified:   benchmarks.rb
+	#
 	~
 	~
 	~
@@ -316,8 +324,8 @@ Glob pattern就像是shell使用的簡化版正規運算式。 星號（`*`）
 另一種方式則是在commit命令後方以`-m`參數指定提交訊息，如下：
 
 	$ git commit -m "Story 182: Fix benchmarks for speed"
-	[master]: created 463dc4f: "Fix benchmarks for speed"
-	 2 files changed, 3 insertions(+), 0 deletions(-)
+	[master 463dc4f] Fix benchmarks for speed
+	 2 files changed, 3 insertions(+)
 	 create mode 100644 README
 
 現在讀者已建立第一個提交！ 讀者可從輸出的訊息看到此提交、放到哪個分支（`master`）、SHA-1查核碼（`463dc4f`）、有多少檔案被更動，以及統計此提交有多少列被新增及移除。
@@ -329,15 +337,17 @@ Glob pattern就像是shell使用的簡化版正規運算式。 星號（`*`）
 雖然優秀好用的暫存區域能很有技巧且精確的提交讀者想記錄的資訊，有時候暫存區域也比讀者實際需要的工作流程繁瑣。 若讀者想跳過暫存區域，Git提供了簡易的使用方式。 在`git commit`命令後方加上`-a`參數，Git自動將所有已被追蹤且被修改的檔案送到暫存區域並開始提交程序，讓讀者略過`git add`的步驟：
 
 	$ git status
-	# On branch master
-	#
-	# Changes not staged for commit:
-	#
-	#	modified:   benchmarks.rb
-	#
+	On branch master
+	Changes not staged for commit:
+	  (use "git add <file>..." to update what will be committed)
+	  (use "git checkout -- <file>..." to discard changes in working directory)
+	
+	        modified:   benchmarks.rb
+	
+	no changes added to commit (use "git add" and/or "git commit -a")
 	$ git commit -a -m 'added new benchmarks'
 	[master 83e38c7] added new benchmarks
-	 1 files changed, 5 insertions(+), 0 deletions(-)
+	 1 files changed, 5 insertions(+)
 
 留意本次的提交之前，讀者並不需要執行`git add`將`benchmarks.rb`檔案加入。
 
@@ -349,26 +359,26 @@ Glob pattern就像是shell使用的簡化版正規運算式。 星號（`*`）
 
 	$ rm grit.gemspec
 	$ git status
-	# On branch master
-	#
-	# Changes not staged for commit:
-	#   (use "git add/rm <file>..." to update what will be committed)
-	#
-	#       deleted:    grit.gemspec
-	#
+	On branch master
+	Changes not staged for commit:
+	  (use "git add/rm <file>..." to update what will be committed)
+	  (use "git checkout -- <file>..." to discard changes in working directory)
+	
+	        deleted:    grit.gemspec
+	
+	no changes added to commit (use "git add" and/or "git commit -a")
 
 接著，若執行`git rm`，則會將暫存區域內的該檔案移除：
 
 	$ git rm grit.gemspec
 	rm 'grit.gemspec'
 	$ git status
-	# On branch master
-	#
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#       deleted:    grit.gemspec
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        deleted:    grit.gemspec
+	
 
 下一次提交時，該檔案將會消失而且不再被追蹤。 若已更動過該檔案且將它記錄到暫存區域。 必須使用`-f`參數才能將它強制移除。 這是為了避免已被記錄的快照意外被移除且再也無法使用Git復原。
 
@@ -398,14 +408,12 @@ Git並不像其它檔案控制系統一樣，明確地追蹤檔案的移動。 
 
 	$ git mv README.txt README
 	$ git status
-	# On branch master
-	# Your branch is ahead of 'origin/master' by 1 commit.
-	#
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#       renamed:    README.txt -> README
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        renamed:    README.txt -> README
+	
 
 不過，這就相當於執行下列命令：
 
@@ -450,7 +458,7 @@ Git會在背後判斷檔案是否被更名，因此不管是用上述方法還
 
 最常用的選項之一為 `-p`，用來顯示每個更新之間差別的內容。 另外還可以加上 `-2` 參數，限制為只輸出最後兩個更新。
 
-	$ git log –p -2
+	$ git log -p -2
 	commit ca82a6dff817ec66f44342007202690a93763949
 	Author: Scott Chacon <schacon@gee-mail.com>
 	Date:   Mon Mar 17 21:52:11 2008 -0700
@@ -461,11 +469,13 @@ Git會在背後判斷檔案是否被更名，因此不管是用上述方法還
 	index a874b73..8f94139 100644
 	--- a/Rakefile
 	+++ b/Rakefile
-	@@ -5,7 +5,7 @@ require 'rake/gempackagetask'
+	@@ -5,5 +5,5 @@ require 'rake/gempackagetask'
 	 spec = Gem::Specification.new do |s|
+	     s.name      =   "simplegit"
 	-    s.version   =   "0.1.0"
 	+    s.version   =   "0.1.1"
 	     s.author    =   "Scott Chacon"
+	     s.email     =   "schacon@gee-mail.com
 
 	commit 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7
 	Author: Scott Chacon <schacon@gee-mail.com>
@@ -489,9 +499,30 @@ Git會在背後判斷檔案是否被更名，因此不管是用上述方法還
 	\ No newline at end of file
 
 這個選項除了顯示相同的資訊外，還另外附上每個更新的差異。 這對於重新檢視或者快速的瀏覽協同工作伙伴新增的更新非常有幫助。
+
+Sometimes it's easier to review changes on the word level rather than on the line level. There is a `--word-diff` option available in Git, that you can append to the `git log -p` command to get word diff instead of normal line by line diff. Word diff format is quite useless when applied to source code, but it comes in handy when applied to large text files, like books or your dissertation. Here is an example:
+
+	$ git log -U1 --word-diff
+	commit ca82a6dff817ec66f44342007202690a93763949
+	Author: Scott Chacon <schacon@gee-mail.com>
+	Date:   Mon Mar 17 21:52:11 2008 -0700
+
+	    changed the version number
+
+	diff --git a/Rakefile b/Rakefile
+	index a874b73..8f94139 100644
+	--- a/Rakefile
+	+++ b/Rakefile
+	@@ -7,3 +7,3 @@ spec = Gem::Specification.new do |s|
+	    s.name      =   "simplegit"
+	    s.version   =   [-"0.1.0"-]{+"0.1.1"+}
+	    s.author    =   "Scott Chacon"
+
+As you can see, there is no added and removed lines in this output as in a normal diff. Changes are shown inline instead. You can see the added word enclosed in `{+ +}` and removed one enclosed in `[- -]`. You may also want to reduce the usual three lines context in diff output to only one line, as the context is now words, not lines. You can do this with `-U1` as we did in the example above.
+
 另外也可以使用`git log`提供的一系統摘要選項。 例如：若想檢視每個更新的簡略統計資訊，可使用 `--stat` 選項：
 
-	$ git log --stat 
+	$ git log --stat
 	commit ca82a6dff817ec66f44342007202690a93763949
 	Author: Scott Chacon <schacon@gee-mail.com>
 	Date:   Mon Mar 17 21:52:11 2008 -0700
@@ -499,7 +530,7 @@ Git會在背後判斷檔案是否被更名，因此不管是用上述方法還
 	    changed the version number
 
 	 Rakefile |    2 +-
-	 1 files changed, 1 insertions(+), 1 deletions(-)
+	 1 file changed, 1 insertion(+), 1 deletion(-)
 
 	commit 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7
 	Author: Scott Chacon <schacon@gee-mail.com>
@@ -508,7 +539,7 @@ Git會在背後判斷檔案是否被更名，因此不管是用上述方法還
 	    removed unnecessary test code
 
 	 lib/simplegit.rb |    5 -----
-	 1 files changed, 0 insertions(+), 5 deletions(-)
+	 1 file changed, 5 deletions(-)
 
 	commit a11bef06a3f659402fe7563abf99ad00de2209e6
 	Author: Scott Chacon <schacon@gee-mail.com>
@@ -519,7 +550,7 @@ Git會在背後判斷檔案是否被更名，因此不管是用上述方法還
 	 README           |    6 ++++++
 	 Rakefile         |   23 +++++++++++++++++++++++
 	 lib/simplegit.rb |   25 +++++++++++++++++++++++++
-	 3 files changed, 54 insertions(+), 0 deletions(-)
+	 3 files changed, 54 insertions(+)
 
 如以上所示，`--stat`選項在每個更新項目的下方列出被更動的檔案、有多少檔案被更動，以及有多行列被加入或移出該檔案。 也會在最後印出摘要的訊息。
 其它實用的選項是 `--pretty`。 這個選項改變原本預設輸出的格式。 有數個內建的選項供讀者選用。 其中 `oneline` 選項將每一個更新印到單獨一行，對於檢視很多更新時很有用。 更進一步，`short`、`full`、`fuller` 選項輸出的格式大致相同，但會少一些或者多一些資訊。
@@ -538,6 +569,11 @@ Git會在背後判斷檔案是否被更名，因此不管是用上述方法還
 
 表格2-1列出一些 `format` 支援的選項。
 
+<!-- Attention to translators: this is a table declaration.
+The lines must be formatted as follows
+<TAB><First column text><TAB><Second column text>
+-->
+
 	選項	選項的說明
 	%H	該更新的SHA1雜湊值
 	%h	該更新的簡短SHA1雜湊值
@@ -562,17 +598,22 @@ Git會在背後判斷檔案是否被更名，因此不管是用上述方法還
 	$ git log --pretty=format:"%h %s" --graph
 	* 2d3acf9 ignore errors from SIGCHLD on trap
 	*  5e3ee11 Merge branch 'master' of git://github.com/dustin/grit
-	|\  
+	|\
 	| * 420eac9 Added a method for getting the current branch.
 	* | 30e367c timeout code and tests
 	* | 5a09431 add timeout protection to grit
 	* | e1193f8 support for heads with slashes in them
-	|/  
+	|/
 	* d6016bc require time for xmlschema
 	*  11d191e Merge branch 'defunkt' into local
 
 這些只是一些簡單的 `git log` 的選項，還有許多其它的。 表格2-2列出目前我們涵蓋的及一些可能有用的格式選項，以及它們如何更動 `log` 命令的輸出格式。
 
+<!-- Attention to translators: this is a table declaration.
+The lines must be formatted as follows
+<TAB><First column text><TAB><Second column text>
+-->
+
 	選項	選項的說明
 	-p	顯示每個更新與上一個的差異。
 	--stat	顯示每個更新更動的檔案的統計及摘要資訊。
@@ -600,6 +641,11 @@ Git會在背後判斷檔案是否被更名，因此不管是用上述方法還
 
 在表格2-3，我們列出這些選項以及少數其它常見選項以供參考。
 
+<!-- Attention to translators: this is a table declaration.
+The lines must be formatted as follows
+<TAB><First column text><TAB><Second column text>
+-->
+
 	選項	選項的說明文字
 	-(n)	僅顯示最後 n 個更新
 	--since, --after	列出特定日期後的更新。
@@ -624,7 +670,7 @@ Git 原始碼的更新歷史接近二萬筆更新，本命令顯示符合條件
 
 若讀者較偏向使用圖形界面檢視歷史，或與會想看一下隨著 Git 發佈的，名為 `gitk` 的 Tcl/Tk 程式。 Gitk 基本上就是 `git log` 的圖形界面版本，而且幾乎接受所有 `git log` 支援的過濾用選項。 若在專案所在目錄下執行 gitk 命令，將會看到如圖2-2的畫面。
 
-Insert 18333fig0202.png 
+Insert 18333fig0202.png
 圖2-2。 gitk檢視歷史程式。
 
 在上圖中可看到視窗的上半部顯示相當棒的更新歷史圖。 視窗下半部則顯示當時被點選的更新引入的變更。
@@ -647,7 +693,7 @@ Insert 18333fig0202.png
 
 	$ git commit -m 'initial commit'
 	$ git add forgotten_file
-	$ git commit --amend 
+	$ git commit --amend
 
 這些命令的僅僅會提交一個更新，第二個被提交的更新會取代第一個。
 
@@ -657,31 +703,32 @@ Insert 18333fig0202.png
 
 	$ git add .
 	$ git status
-	# On branch master
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#       modified:   README.txt
-	#       modified:   benchmarks.rb
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        modified:   README.txt
+	        modified:   benchmarks.rb
+	
 
 在 “Changes to be commited” 文字下方，註明著使用 “`git reset HEAD <file>...`，將 file 移出暫存區”。 因此，讓我們依循該建議將 `benchmarks.rb` 檔案移出暫存區：
 
-	$ git reset HEAD benchmarks.rb 
-	benchmarks.rb: locally modified
+	$ git reset HEAD benchmarks.rb
+	Unstaged changes after reset:
+	M       benchmarks.rb
 	$ git status
-	# On branch master
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#       modified:   README.txt
-	#
-	# Changes not staged for commit:
-	#   (use "git add <file>..." to update what will be committed)
-	#   (use "git checkout -- <file>..." to discard changes in working directory)
-	#
-	#       modified:   benchmarks.rb
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        modified:   README.txt
+	
+	Changes not staged for commit:
+	  (use "git add <file>..." to update what will be committed)
+	  (use "git checkout -- <file>..." to discard changes in working directory)
+	
+	        modified:   benchmarks.rb
+	
 
 這個命令看起來有點奇怪，不過它的確可行。 `benchmarks.rb` 檔案被移出暫存區了。
 
@@ -689,23 +736,23 @@ Insert 18333fig0202.png
 
 若讀者發現其者並不需要保留 `benchmarks.rb` 檔案被更動部份，應該如何做才能很容易的復原為最後一次提交的狀態（或者最被複製儲存庫時、或放到工作目錄時的版本）？ 很幸運的，`git status` 同樣也告訴讀者如何做。 在最近一次檢視狀態時，暫存區看起來應如下所示：
 
-	# Changes not staged for commit:
-	#   (use "git add <file>..." to update what will be committed)
-	#   (use "git checkout -- <file>..." to discard changes in working directory)
-	#
-	#       modified:   benchmarks.rb
-	#
+	Changes not staged for commit:
+	  (use "git add <file>..." to update what will be committed)
+	  (use "git checkout -- <file>..." to discard changes in working directory)
+	
+	        modified:   benchmarks.rb
+	
 
 在這訊息中已很明確的說明如何拋棄所做的修改（至少需升級為 Git 1.6.1或更新版本。 若讀者使用的是舊版，強烈建議升級，以取得更好用的功能。） 讓我們依據命令執行：
 
 	$ git checkout -- benchmarks.rb
 	$ git status
-	# On branch master
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#       modified:   README.txt
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        modified:   README.txt
+	
 
 在上述文字可看到該變更已被復原。 讀者應該瞭解這是危險的命令，任何對該檔案做的修改將不復存在，就好像複製別的檔案將它覆蓋。 除非很清楚真的不需要該檔案，絕不要使用此檔案。 若需要將這些修改排除，我們在下一章節會介紹備份及分支。 一般來說會比此方法來的好。
 
@@ -721,20 +768,21 @@ Insert 18333fig0202.png
 欲瞭解目前已加進來的遠端儲存庫，可執行 `git remote` 命令。 它會列出當初加入遠端儲存庫時指定的名稱。 若目前所在儲存庫是從其它儲存庫複製過來的，至少應該看到 *origin*，也就是 Git 複製儲存庫時預設名字：
 
 	$ git clone git://github.com/schacon/ticgit.git
-	Initialized empty Git repository in /private/tmp/ticgit/.git/
-	remote: Counting objects: 595, done.
-	remote: Compressing objects: 100% (269/269), done.
-	remote: Total 595 (delta 255), reused 589 (delta 253)
-	Receiving objects: 100% (595/595), 73.31 KiB | 1 KiB/s, done.
-	Resolving deltas: 100% (255/255), done.
+	Cloning into 'ticgit'...
+	remote: Reusing existing pack: 1857, done.
+	remote: Total 1857 (delta 0), reused 0 (delta 0)
+	Receiving objects: 100% (1857/1857), 374.35 KiB | 193.00 KiB/s, done.
+	Resolving deltas: 100% (772/772), done.
+	Checking connectivity... done.
 	$ cd ticgit
-	$ git remote 
+	$ git remote
 	origin
 
 也可以再加上 `-v` 參數，將會在名稱後方顯示其URL：
 
 	$ git remote -v
-	origin	git://github.com/schacon/ticgit.git
+	origin  git://github.com/schacon/ticgit.git (fetch)
+	origin  git://github.com/schacon/ticgit.git (push)
 
 若有一個以上遠端儲存庫，此命令會全部列出。 例如：我的 Grit 儲存庫包含以下遠端儲存庫。
 
@@ -898,6 +946,7 @@ Git使用兩大類的標籤：輕量級(lightweight)和含附註(annotated)。
 	Date:   Mon Feb 9 14:45:11 2009 -0800
 
 	my version 1.4
+
 	commit 15027957951b64cf874c3557a0f3547bd83b3ff6
 	Merge: 4a447f7... a6b4c97...
 	Author: Scott Chacon <schacon@gee-mail.com>
@@ -1008,7 +1057,7 @@ Git使用兩大類的標籤：輕量級(lightweight)和含附註(annotated)。
 
 你可以看到標籤已經補上：
 
-	$ git tag 
+	$ git tag
 	v0.1
 	v1.2
 	v1.3
@@ -1057,7 +1106,6 @@ Git使用兩大類的標籤：輕量級(lightweight)和含附註(annotated)。
 
 現在，當其他使用者clone或pull你的儲存庫時，他們也同時會取得所有你的標籤。
 
-
 ## 提示和技巧 ##
 
 在結束Git基礎這個章節前，我們將介紹有一些將會使你的Git使用經驗更簡單、方便和親切的提示和技巧。或許很多人從未運用過這些技巧，我們也不會假設你在本書的後續章節會使用它們。但你也許會想知道如何使用它們。
@@ -1066,7 +1114,7 @@ Git使用兩大類的標籤：輕量級(lightweight)和含附註(annotated)。
 
 如果你用的是 Bash shell，你可以啟動Git本身寫好的自動補齊腳本。下載Git原始碼，切到`contrib/completion`目錄；可以看到檔案名為`git-completion.bash`。將它複製到你的家目錄，並加入以下指令到你的`.bashrc`檔案裡：
 
-	source ~/.git-completion.bash
+	source ~/git-completion.bash
 
 如果你想為所有使用者都自動設置Bash shell的補齊功能，在Mac系統上將這個腳本複製到`/opt/local/etc/bash_completion.d`目錄，若你使用Linux系統複製到 `/etc/bash_completion.d/`目錄。這兩個目錄中的脚本，都會在 Bash 啟動時自動載入。
 
@@ -1086,7 +1134,6 @@ Git使用兩大類的標籤：輕量級(lightweight)和含附註(annotated)。
 
 這是個好用的小技巧，或許可以省下許多輸入和查文件的時間
 
-
 ### Git 命令別名 ###
 
 如果僅輸入命令的部份字元，Git並不會幫你推論出你想要下的完整命令。如果你想偷懶，不想輸入Git命令的所有字元，你可以輕易地利用`git config`設定別名(alias)。你也許會想要設定以下這幾個範例：
@@ -1112,7 +1159,7 @@ Git使用兩大類的標籤：輕量級(lightweight)和含附註(annotated)。
 	$ git config --global alias.last 'log -1 HEAD'
 
 如此一來，將可更簡單地看到最新的提交訊息：
-	
+
 	$ git last
 	commit 66938dae3329c7aebe598c2246a8e6af90d04646
 	Author: Josh Goebel <dreamer3@example.com>
@@ -1128,4 +1175,4 @@ Git使用兩大類的標籤：輕量級(lightweight)和含附註(annotated)。
 
 ## 總結 ##
 
-至此，讀者已具備所有Git的本地端操作，包括：創建和副本儲存庫、建立修改、暫存和提交這些修改，以及檢視在儲存庫中所有修改歷史。接下來，我們將觸及Git的殺手級特性，也就是他的分支模型。
\ No newline at end of file
+至此，讀者已具備所有Git的本地端操作，包括：創建和副本儲存庫、建立修改、暫存和提交這些修改，以及檢視在儲存庫中所有修改歷史。接下來，我們將觸及Git的殺手級特性，也就是他的分支模型。
diff --git a/zh-tw/06-git-tools/01-chapter6.markdown b/zh-tw/06-git-tools/01-chapter6.markdown
index c5e1f5f26..392cc7b5b 100644
--- a/zh-tw/06-git-tools/01-chapter6.markdown
+++ b/zh-tw/06-git-tools/01-chapter6.markdown
@@ -79,7 +79,7 @@ Git 可以為你的 SHA-1 值生成出簡短且唯一的縮寫。如果你傳遞
 
 在你工作的同時，Git 在後臺的工作之一就是保存一份引用日誌(reflog)——一份記錄最近幾個月你的 HEAD 和分支引用的日誌。 
 
-你可以使用 `git reflog` 來查看引用日誌： 
+你可以使用 `git reflog` 來查看引用日誌：
 
 	$ git reflog
 	734713b... HEAD@{0}: commit: fixed refs handling, added gc auto, updated
@@ -100,12 +100,12 @@ Git 可以為你的 SHA-1 值生成出簡短且唯一的縮寫。如果你傳遞
 
 它就會顯示昨天分支的頂端在哪。這項技術只對還在你引用日誌裡的資料有用，所以不能用來查看比幾個月前還早的提交。 
 
-想要看類似於 `git log` 輸出格式的引用日誌資訊，你可以執行 `git log -g`： 
+想要看類似於 `git log` 輸出格式的引用日誌資訊，你可以執行 `git log -g`：
 
 	$ git log -g master
 	commit 734713bc047d87bf7eac9674765ae793478c50d3
 	Reflog: master@{0} (Scott Chacon <schacon@gmail.com>)
-	Reflog message: commit: fixed refs handling, added gc auto, updated 
+	Reflog message: commit: fixed refs handling, added gc auto, updated
 	Author: Scott Chacon <schacon@gmail.com>
 	Date:   Fri Jan 2 18:32:33 2009 -0800
 
@@ -128,10 +128,10 @@ Git 可以為你的 SHA-1 值生成出簡短且唯一的縮寫。如果你傳遞
 	$ git log --pretty=format:'%h %s' --graph
 	* 734713b fixed refs handling, added gc auto, updated tests
 	*   d921970 Merge commit 'phedders/rdocs'
-	|\  
+	|\
 	| * 35cfb2b Some rdoc changes
 	* | 1c002dd added some blame and merge stuff
-	|/  
+	|/
 	* 1c36188 ignore *.gem
 	* 9b29157 add open3_detach to gemspec file list
 
@@ -189,7 +189,7 @@ Git 可以為你的 SHA-1 值生成出簡短且唯一的縮寫。如果你傳遞
 
 最常用的指明範圍的方法是雙點的語法。這種語法主要是讓 Git 區分出可從一個分支中獲得而不能從另一個分支中獲得的提交。例如，假設你有類似於圖 6-1 的提交歷史。 
 
-Insert 18333fig0601.png 
+Insert 18333fig0601.png
 Figure 6-1. 範圍選擇的提交歷史實例
 
 你想要查看你的試驗分支(experiment)上哪些沒有被提交到主分支，那麼你就可以使用 `master..experiment` 來讓 Git 顯示這些提交的日誌——這句話的意思是「所有可從 experiment 分支中獲得而不能從 master 分支中獲得的提交」。為了使例子簡單明瞭，我使用了圖示中提交物件的字母，來代替它們在實際的日誌輸出裏的顯示順序： 
@@ -263,7 +263,7 @@ Git 提供了很多腳本來輔助某些命令列任務。這裡，你將看到
 	*** Commands ***
 	  1: status     2: update      3: revert     4: add untracked
 	  5: patch      6: diff        7: quit       8: help
-	What now> 
+	What now>
 
 你會看到這個命令以一個完全不同的視圖顯示了你的暫存區——主要是你通過 `git status` 得到的那些資訊但是稍微簡潔但資訊更加豐富一些。它在左側列出了你暫存的變更，在右側列出了未被暫存的變更。 
 
@@ -291,7 +291,7 @@ Git 提供了很多腳本來輔助某些命令列任務。這裡，你將看到
 
 每個檔旁邊的 `*` 表示選中的檔將被暫存。如果你在 update>> 提示後直接敲入 Enter，Git會替你把所有選中的內容暫存： 
 
-	Update>> 
+	Update>>
 	updated 2 paths
 
 	*** Commands ***
@@ -373,7 +373,7 @@ Git 提供了很多腳本來輔助某些命令列任務。這裡，你將看到
 	   end
 
 	   def blame(path)
-	Stage this hunk [y,n,a,d,/,j,J,g,e,?]? 
+	Stage this hunk [y,n,a,d,/,j,J,g,e,?]?
 
 此處你有很多選擇。輸入 `?` 可以顯示清單： 
 
@@ -737,7 +737,7 @@ Git 也提供了一些工具來幫助你 debug 專案中遇到的問題。由於
 
 如果你在追查程式碼中的 bug，想要知道這是什麼時候、為什麼被引進來的，檔案標注會是你的最佳工具。它會顯示檔案中對每一行進行修改的最近一次提交。因此，如果你發現自己程式碼中的一個 method 有 bug，你可以用 `git blame` 來標注該檔案，查看那個 method 的每一行分別是由誰在哪一天修改的。下面這個例子使用了 `-L` 選項來限制輸出範圍在第12至22行：
 
-	$ git blame -L 12,22 simplegit.rb 
+	$ git blame -L 12,22 simplegit.rb
 	^4832fe2 (Scott Chacon  2008-03-15 10:31:28 -0700 12)  def show(tree = 'master')
 	^4832fe2 (Scott Chacon  2008-03-15 10:31:28 -0700 13)   command("git show #{tree}")
 	^4832fe2 (Scott Chacon  2008-03-15 10:31:28 -0700 14)  end
@@ -745,7 +745,7 @@ Git 也提供了一些工具來幫助你 debug 專案中遇到的問題。由於
 	9f6560e4 (Scott Chacon  2008-03-17 21:52:20 -0700 16)  def log(tree = 'master')
 	79eaf55d (Scott Chacon  2008-04-06 10:15:08 -0700 17)   command("git log #{tree}")
 	9f6560e4 (Scott Chacon  2008-03-17 21:52:20 -0700 18)  end
-	9f6560e4 (Scott Chacon  2008-03-17 21:52:20 -0700 19) 
+	9f6560e4 (Scott Chacon  2008-03-17 21:52:20 -0700 19)
 	42cf2861 (Magnus Chacon 2008-04-13 10:45:01 -0700 20)  def blame(path)
 	42cf2861 (Magnus Chacon 2008-04-13 10:45:01 -0700 21)   command("git blame #{path}")
 	42cf2861 (Magnus Chacon 2008-04-13 10:45:01 -0700 22)  end
@@ -754,8 +754,8 @@ Git 也提供了一些工具來幫助你 debug 專案中遇到的問題。由於
 
 另一件很酷的事情是，Git 並不會明確地記錄對檔案所做的重命名(rename)動作。它會記錄快照，然後根據實際狀況嘗試找出隱藏在背後的重命名動作。這其中有一個很有意思的特性，就是你可以讓它找出所有的程式碼移動。如果你在 `git blame` 後加上 `-C`，Git 會分析你所標注的檔案，然後嘗試找出其中代碼片段的原始出處，如果它是從其他地方拷貝過來的話。最近，我在對 `GITServerHandler.m` 這個檔案做程式碼重構(code refactoring)，將它分解為多個檔案，其中一個是 `GITPackUpload.m`。通過對 `GITPackUpload.m` 執行帶 `-C` 參數的 blame 命令，我可以看到程式碼片段的原始出處： 
 
-	$ git blame -C -L 141,153 GITPackUpload.m 
-	f344f58d GITServerHandler.m (Scott 2009-01-04 141) 
+	$ git blame -C -L 141,153 GITPackUpload.m
+	f344f58d GITServerHandler.m (Scott 2009-01-04 141)
 	f344f58d GITServerHandler.m (Scott 2009-01-04 142) - (void) gatherObjectShasFromC
 	f344f58d GITServerHandler.m (Scott 2009-01-04 143) {
 	70befddd GITServerHandler.m (Scott 2009-03-22 144)         //NSLog(@"GATHER COMMI
@@ -852,7 +852,7 @@ Git 通過子模組處理這個問題。子模組允許你將一個 Git 倉庫
 
 首先你注意到有一個 `.gitmodules` 文件。這是一個設定檔，保存了專案 URL 和你拉取到的本地子目錄 
 
-	$ cat .gitmodules 
+	$ cat .gitmodules
 	[submodule "rack"]
 	      path = rack
 	      url = git://github.com/chneukirchen/rack.git
diff --git a/zh-tw/07-customizing-git/01-chapter7.markdown b/zh-tw/07-customizing-git/01-chapter7.markdown
index 31eadc0c5..8be51aab4 100644
--- a/zh-tw/07-customizing-git/01-chapter7.markdown
+++ b/zh-tw/07-customizing-git/01-chapter7.markdown
@@ -129,7 +129,7 @@ Git 會按照你的需要，自動為大部分的輸出加上顏色。你能明
 
 除此之外，以上每個選項都有子選項，可以被用來覆蓋其父設置，以達到為輸出的各個部分著色的目的。例如，要讓 diff 輸出的改變資訊 (meta information) 以粗體、藍色前景和黑色背景的形式顯示，你可以執行： 
 
-	$ git config --global color.diff.meta “blue black bold”
+	$ git config --global color.diff.meta "blue black bold"
 
 你能設置的顏色值如下：normal、black、red、green、yellow、blue、magenta、cyan、white。正如以上例子設置的粗體屬性，想要設置字體屬性的話，你的選擇有：bold、dim、ul、blink、reverse。 
 
@@ -157,13 +157,13 @@ diff 包裝腳本首先確定傳遞過來7個參數，隨後把其中2個傳遞
 
 由於你僅僅需要 `old-file` 和 `new-file` 參數，用 diff 包裝腳本來傳遞它們吧。 
 
-	$ cat /usr/local/bin/extDiff 
+	$ cat /usr/local/bin/extDiff
 	#!/bin/sh
 	[ $# -eq 7 ] && /usr/local/bin/extMerge "$2" "$5"
 
 你還需要確認一下這兩個腳本是可執行的： 
 
-	$ sudo chmod +x /usr/local/bin/extMerge 
+	$ sudo chmod +x /usr/local/bin/extMerge
 	$ sudo chmod +x /usr/local/bin/extDiff
 
 現在來設定使用你自訂的比較和合併工具吧。這需要許多自訂設置：`merge.tool` 通知 Git 使用哪個合併工具；`mergetool.*.cmd` 規定命令如何執行；`mergetool.trustExitCode` 會通知 Git 該程式的退出碼(exit code)是否指示合併操作成功；`diff.external` 通知 Git 用什麼命令做比較。因此，你可以執行以下4條配置命令： 
@@ -185,12 +185,12 @@ diff 包裝腳本首先確定傳遞過來7個參數，隨後把其中2個傳遞
 	  external = extDiff
 
 設置完畢後，如果你像這樣執行 diff 命令： 
-	
+
 	$ git diff 32d1776b1^ 32d1776b1
 
 不同於在命令列得到 diff 命令的輸出，Git 觸發了剛剛設置的 P4Merge，它看起來像圖7-1這樣： 
 
-Insert 18333fig0701.png 
+Insert 18333fig0701.png
 Figure 7-1. P4Merge.
 
 當你設法合併兩個分支，結果卻有衝突時，執行 `git mergetool`，Git 會啟用 P4Merge 讓你通過圖形介面來解決衝突。 
@@ -198,7 +198,7 @@ Figure 7-1. P4Merge.
 設置包裝腳本的好處是你能簡單地改變 diff 和 merge 工具，例如把 `extDiff` 和 `extMerge` 改成 KDiff3，要做的僅僅是編輯 `extMerge` 指令檔： 
 
 	$ cat /usr/local/bin/extMerge
-	#!/bin/sh	
+	#!/bin/sh
 	/Applications/kdiff3.app/Contents/MacOS/kdiff3 $*
 
 現在 Git 會使用 KDiff3 來做比較、合併和解決衝突。 
@@ -260,8 +260,7 @@ Git 伺服器端的配置選項並不多，但仍有一些有趣的選項值得
 
 #### receive.fsckObjects ####
 
-Git 預設情況下不會在推送期間檢查所有物件的一致性。Git 雖然會檢查確認每個物件仍然符合它的 SHA-1 checksum，
-所指向的物件也都是有效的，但是預設 Git 不會在每次推送時都做這種檢查。對於 Git 來說，倉庫或推送的檔越大，這個操作代價就相對越高，每次推送會消耗更多時間。如果想讓 Git 在每次推送時都檢查物件一致性，可以設定 `receive.fsckObjects` 為 true 來強迫它這麼做： 
+Git 預設情況下不會在推送期間檢查所有物件的一致性。Git 雖然會檢查確認每個物件仍然符合它的 SHA-1 checksum，所指向的物件也都是有效的，但是預設 Git 不會在每次推送時都做這種檢查。對於 Git 來說，倉庫或推送的檔越大，這個操作代價就相對越高，每次推送會消耗更多時間。如果想讓 Git 在每次推送時都檢查物件一致性，可以設定 `receive.fsckObjects` 為 true 來強迫它這麼做： 
 
 	$ git config --system receive.fsckObjects true
 
@@ -312,9 +311,11 @@ To tell Git to treat all `pbxproj` files as binary data, add the following line
 
 在 Git 1.6 及以上版本中，你能利用 Git 屬性來有效地比較二進位檔案。可以設置 Git 把二進位資料轉換成文本格式，然後用一般 diff 來做比較。 
 
+##### MS Word files #####
+
 這個特性很酷，而且鮮為人知，因此我會結合實例來講解。首先，你將使用這項技術來解決最令人頭疼的問題之一：對 Word 文檔進行版本控制。每個人都知道 Word 是最可怕的編輯器，奇怪的是，每個人都在使用它。如果想對 Word 文件進行版本控制，你可以把檔案加入到 Git 倉庫中，每次修改後提交即可。但這樣做有什麼好處？如果你像平常一樣執行 `git diff` 命令，你只能得到如下的結果： 
 
-	$ git diff 
+	$ git diff
 	diff --git a/chapter1.doc b/chapter1.doc
 	index 88839c4..4afcb7c 100644
 	Binary files a/chapter1.doc and b/chapter1.doc differ
@@ -336,15 +337,67 @@ To tell Git to treat all `pbxproj` files as binary data, add the following line
 	index c1c8a0a..b93c9e4 100644
 	--- a/chapter1.doc
 	+++ b/chapter1.doc
-	@@ -8,7 +8,8 @@ re going to cover Version Control Systems (VCS) and Git basics
-	 re going to cover how to get it and set it up for the first time if you don
-	 t already have it on your system.
-	 In Chapter Two we will go over basic Git usage - how to use Git for the 80% 
-	-s going on, modify stuff and contribute changes. If the book spontaneously 
-	+s going on, modify stuff and contribute changes. If the book spontaneously 
-	+Let's see if this works.
+	@@ -128,7 +128,7 @@ and data size)
+	 Since its birth in 2005, Git has evolved and matured to be easy to use
+	 and yet retain these initial qualities. It’s incredibly fast, it’s
+	 very efficient with large projects, and it has an incredible branching
+	-system for non-linear development.
+	+system for non-linear development (See Chapter 3).
+
+Git 成功且簡潔地顯示出我增加的文字 ”(See Chapter 3)”。雖然有些瑕疵 -- 在末尾顯示了一些隨機的內容 -- 但確實可以比較了。如果你能找到或自己寫個 Word 到純文字的轉換器的話，效果可能會更好。不過因為 `strings` 可以在大部分 Mac 和 Linux 系統上運行，所以在初次嘗試對各種二進位格式檔進行類似的處理，它是個不錯的選擇。 
+
+##### OpenDocument Text files #####
+
+The same approach that we used for MS Word files (`*.doc`) can be used for OpenDocument Text files (`*.odt`) created by OpenOffice.org.
+
+Add the following line to your `.gitattributes` file:
+
+	*.odt diff=odt
+
+Now set up the `odt` diff filter in `.git/config`:
+
+	[diff "odt"]
+		binary = true
+		textconv = /usr/local/bin/odt-to-txt
 
-Git 成功且簡潔地顯示出我增加的文字 ”Let’s see if this works”。雖然有些瑕疵 -- 在末尾顯示了一些隨機的內容 -- 但確實可以比較了。如果你能找到或自己寫個 Word 到純文字的轉換器的話，效果可能會更好。不過因為 `strings` 可以在大部分 Mac 和 Linux 系統上運行，所以在初次嘗試對各種二進位格式檔進行類似的處理，它是個不錯的選擇。 
+OpenDocument files are actually zip’ped directories containing multiple files (the content in an XML format, stylesheets, images, etc.). We’ll need to write a script to extract the content and return it as plain text. Create a file `/usr/local/bin/odt-to-txt` (you are free to put it into a different directory) with the following content:
+
+	#! /usr/bin/env perl
+	# Simplistic OpenDocument Text (.odt) to plain text converter.
+	# Author: Philipp Kempgen
+
+	if (! defined($ARGV[0])) {
+		print STDERR "No filename given!\n";
+		print STDERR "Usage: $0 filename\n";
+		exit 1;
+	}
+
+	my $content = '';
+	open my $fh, '-|', 'unzip', '-qq', '-p', $ARGV[0], 'content.xml' or die $!;
+	{
+		local $/ = undef;  # slurp mode
+		$content = <$fh>;
+	}
+	close $fh;
+	$_ = $content;
+	s/<text:span\b[^>]*>//g;           # remove spans
+	s/<text:h\b[^>]*>/\n\n*****  /g;   # headers
+	s/<text:list-item\b[^>]*>\s*<text:p\b[^>]*>/\n    --  /g;  # list items
+	s/<text:list\b[^>]*>/\n\n/g;       # lists
+	s/<text:p\b[^>]*>/\n  /g;          # paragraphs
+	s/<[^>]+>//g;                      # remove all XML tags
+	s/\n{2,}/\n\n/g;                   # remove multiple blank lines
+	s/\A\n+//;                         # remove leading blank lines
+	print "\n", $_, "\n\n";
+
+And make it executable
+
+	chmod +x /usr/local/bin/odt-to-txt
+
+Now `git diff` will be able to tell you what changed in `.odt` files.
+
+
+##### Image files #####
 
 你還能用這個方法解決另一個有趣的問題：比較影像檔。方法之一是對 JPEG 檔執行一個篩檢程式，把 EXIF 資訊捉取出來 — EXIF 資訊是記錄在大部分圖像格式裏面的 metadata。如果你下載並安裝了 `exiftool` 程式，可以用它把圖檔的 metadata 轉換成文本，於是至少 diff 可以用文字呈現的方式向你展示發生了哪些修改： 
 
@@ -360,7 +413,7 @@ Git 成功且簡潔地顯示出我增加的文字 ”Let’s see if this works
 	@@ -1,12 +1,12 @@
 	 ExifTool Version Number         : 7.74
 	-File Size                       : 70 kB
-	-File Modification Date/Time     : 2009:04:21 07:02:45-07:00
+	-File Modification Date/Time     : 2009:04:17 10:12:35-07:00
 	+File Size                       : 94 kB
 	+File Modification Date/Time     : 2009:04:21 07:02:43-07:00
 	 File Type                       : PNG
@@ -385,19 +438,19 @@ Git 成功且簡潔地顯示出我增加的文字 ”Let’s see if this works
 
 下次 check out 這個檔案的時候，Git 注入了 blob 的 SHA 值： 
 
-	$ rm text.txt
-	$ git checkout -- text.txt
-	$ cat test.txt 
+	$ rm test.txt
+	$ git checkout -- test.txt
+	$ cat test.txt
 	$Id: 42812b7653c7b88933f8a9d6cad0ca16714b9bb3 $
 
 然而，這個結果的用處有限。如果你在 CVS 或 Subversion 中用過關鍵字替換，你可以包含一個日期值 -- 而這個 SHA 值沒什麼幫助，因為它相當地隨機，也無法區分某個 SHA 跟另一個 SHA 比起來是比較新或是比較舊。
 
 因此，你可以撰寫自己的篩檢程式，在提交或 checkout 文件時替換關鍵字。有兩種篩檢程式，”clean” 和 ”smudge”。在 `.gitattributes` 檔中，你能對特定的路徑設置一個篩檢程式，然後設置處理檔案的腳本，這些腳本會在檔案 check out 前（”smudge”，見圖 7-2）和提交前（”clean”，見圖7-3）被執行。這些篩檢程式能夠做各種有趣的事。 
 
-Insert 18333fig0702.png 
+Insert 18333fig0702.png
 Figure 7-2. “smudge” filter 在 checkout 時執行
 
-Insert 18333fig0703.png 
+Insert 18333fig0703.png
 Figure 7-3. “clean” filter 在檔案被 staged 的時候執行
 
 這裡舉一個簡單的例子：在提交前，用 indent（縮進）程式過濾所有C原始程式碼。在 `.gitattributes` 檔中設置 ”indent” 篩檢程式過濾 `*.c` 文件： 
@@ -679,7 +732,7 @@ A simple way to get the commit message from a commit when you have the SHA-1 val
 	      access[$user].each do |access_path|
 	        if !access_path || # user has access to everything
 	          (path.index(access_path) == 0) # access to this path
-	          has_file_access = true 
+	          has_file_access = true
 	        end
 	      end
 	      if !has_file_access
@@ -687,7 +740,7 @@ A simple way to get the commit message from a commit when you have the SHA-1 val
 	        exit 1
 	      end
 	    end
-	  end  
+	  end
 	end
 
 	check_directory_perms
@@ -702,7 +755,7 @@ A simple way to get the commit message from a commit when you have the SHA-1 val
 
 檢查的邏輯是看看是否有任何的提交在舊版本(revision)裡能找到、但在新版本裡卻找不到。如果沒有，那這是一次純 fast-forward 的推送；如果有，那我們拒絕此次推送： 
 
-	# enforces fast-forward only pushes 
+	# enforces fast-forward only pushes
 	def check_fast_forward
 	  missed_refs = `git rev-list #{$newrev}..#{$oldrev}`
 	  missed_ref_count = missed_refs.split("\n").size
@@ -722,9 +775,9 @@ A simple way to get the commit message from a commit when you have the SHA-1 val
 	Writing objects: 100% (3/3), 323 bytes, done.
 	Total 3 (delta 1), reused 0 (delta 0)
 	Unpacking objects: 100% (3/3), done.
-	Enforcing Policies... 
+	Enforcing Policies...
 	(refs/heads/master) (8338c5) (c5b616)
-	[POLICY] Cannot push a non-fast-forward reference
+	[POLICY] Cannot push a non fast-forward reference
 	error: hooks/update exited with error code 1
 	error: hook declined to update refs/heads/master
 	To git@gitserver:project.git
@@ -733,8 +786,8 @@ A simple way to get the commit message from a commit when you have the SHA-1 val
 
 這裡有幾個有趣的資訊。首先，我們可以看到掛鉤執行的起點： 
 
-	Enforcing Policies... 
-	(refs/heads/master) (fb8c72) (c56860)
+	Enforcing Policies...
+	(refs/heads/master) (8338c5) (c5b616)
 
 注意這是你在 update 腳本一開頭的地方印出到標準輸出的東西。所有從腳本印出到 stdout 的東西都會發送到用戶端，這點很重要。 
 
@@ -860,7 +913,7 @@ A simple way to get the commit message from a commit when you have the SHA-1 val
 	target_shas.each do |sha|
 	  remote_refs.each do |remote_ref|
 	    shas_pushed = `git rev-list ^#{sha}^@ refs/remotes/#{remote_ref}`
-	    if shas_pushed.split(“\n”).include?(sha)
+	    if shas_pushed.split("\n").include?(sha)
 	      puts "[POLICY] Commit #{sha} has already been pushed to #{remote_ref}"
 	      exit 1
 	    end
diff --git a/zh-tw/08-git-and-other-scms/01-chapter8.markdown b/zh-tw/08-git-and-other-scms/01-chapter8.markdown
index f781e3201..32bcd7acb 100644
--- a/zh-tw/08-git-and-other-scms/01-chapter8.markdown
+++ b/zh-tw/08-git-and-other-scms/01-chapter8.markdown
@@ -29,14 +29,14 @@ Git 中所有 Subversion 橋接命令的基礎是 `git svn` 。所有的命令
 
 然後，允許所有用戶修改 revprop —— 簡單的做法是添加一個總是以 0 作為傳回值的 pre-revprop-change 腳本： 
 
-	$ cat /tmp/test-svn/hooks/pre-revprop-change 
+	$ cat /tmp/test-svn/hooks/pre-revprop-change
 	#!/bin/sh
 	exit 0;
 	$ chmod +x /tmp/test-svn/hooks/pre-revprop-change
 
 現在可以呼叫 `svnsync init`，參數加目標倉庫，再加來源倉庫，就可以把該專案同步到本地了： 
 
-	$ svnsync init file:///tmp/test-svn http://progit-example.googlecode.com/svn/ 
+	$ svnsync init file:///tmp/test-svn http://progit-example.googlecode.com/svn/
 
 這將建立進行同步所需的屬性(property)。可以通過執行以下命令來 clone 程式碼：
 
@@ -282,7 +282,7 @@ Git 通過搜尋提交歷史中 Subversion 分支的頭部(tip)來決定 dcommit
 
 	------------------------------------------------------------------------
 	r85 | schacon | 2009-05-02 16:00:09 -0700 (Sat, 02 May 2009) | 2 lines
-	
+
 	updated the changelog
 
 關於 `git svn log` ，有兩點需要注意。首先，它可以離線工作，不像 `svn log 命令`，需要向 Subversion 伺服器索取資料。其次，它僅僅顯示已經提交到 Subversion 伺服器上的 commit。在本地尚未 dcommit 的 Git 資料不會出現在這裡；其他人向 Subversion 伺服器新提交的資料也不會顯示。等於說是顯示了最近已知 Subversion 伺服器上的狀態。 
@@ -291,19 +291,19 @@ Git 通過搜尋提交歷史中 Subversion 分支的頭部(tip)來決定 dcommit
 
 類似 `git svn log` 命令模擬了 `svn log` 命令的離線操作，`svn annotate` 的等效命令是 `git svn blame [檔案名]`。其輸出如下： 
 
-	$ git svn blame README.txt 
+	$ git svn blame README.txt
 	 2   temporal Protocol Buffers - Google's data interchange format
 	 2   temporal Copyright 2008 Google Inc.
 	 2   temporal http://code.google.com/apis/protocolbuffers/
-	 2   temporal 
+	 2   temporal
 	22   temporal C++ Installation - Unix
 	22   temporal =======================
-	 2   temporal 
+	 2   temporal
 	79    schacon Committing in git-svn.
-	78    schacon 
+	78    schacon
 	 2   temporal To build and install the C++ Protocol Buffer runtime and the Protocol
 	 2   temporal Buffer compiler (protoc) execute the following:
-	 2   temporal 
+	 2   temporal
 
 同樣，它不顯示本地的 Git 提交以及 Subversion 上後來更新的內容。
 
@@ -370,7 +370,7 @@ Git 通過搜尋提交歷史中 Subversion 分支的頭部(tip)來決定 dcommit
 
 為 `git svn` 提供該檔可以讓它更精確的映射作者資料。你還可以在 `clone` 或者 `init` 後面添加 `--no-metadata` 來阻止 `git svn` 包含那些 Subversion 的附加資訊。這樣 `import` 命令就變成了：
 
-	$ git-svn clone http://my-project.googlecode.com/svn/ \
+	$ git svn clone http://my-project.googlecode.com/svn/ \
 	      --authors-file=users.txt --no-metadata -s my_project
 
 現在 `my_project` 目錄下導入的 Subversion 應該比原來整潔多了。原來的 commit 看上去是這樣： 
@@ -383,7 +383,6 @@ Git 通過搜尋提交歷史中 Subversion 分支的頭部(tip)來決定 dcommit
 
 	    git-svn-id: https://my-project.googlecode.com/svn/trunk@94 4c93b258-373f-11de-
 	    be05-5f7a86268029
-
 現在是這樣： 
 
 	commit 03a8785f44c8ea5cdb0e8834b7c8e6c469be2ff2
@@ -411,6 +410,7 @@ Git 通過搜尋提交歷史中 Subversion 分支的頭部(tip)來決定 dcommit
 現在所有的舊分支都變成真正的 Git 分支，所有的舊標籤也變成真正的 Git 標籤。最後一項工作就是把新建的 Git 伺服器添加為遠端伺服器並且向它推送。為了讓所有的分支和標籤都得到上傳，我們使用這條命令： 
 
 	$ git push origin --all
+	$ git push origin --tags
 
 所有的分支和標籤現在都應該整齊乾淨的躺在新的 Git 伺服器裡了。 
 
@@ -510,7 +510,7 @@ Git 通過搜尋提交歷史中 Subversion 分支的頭部(tip)來決定 dcommit
 	    next if File.file?(dir)
 
 	    # move into the target directory
-	    Dir.chdir(dir) do 
+	    Dir.chdir(dir) do
 	      last_mark = print_export(dir, last_mark)
 	    end
 	  end
@@ -605,7 +605,7 @@ Git 通過搜尋提交歷史中 Subversion 分支的頭部(tip)來決定 dcommit
 
 搞定了。現在執行該腳本，你將得到如下內容： 
 
-	$ ruby import.rb /opt/import_from 
+	$ ruby import.rb /opt/import_from
 	commit refs/heads/master
 	mark :1
 	committer Scott Chacon <schacon@geemail.com> 1230883200 -0700
diff --git a/zh-tw/09-git-internals/01-chapter9.markdown b/zh-tw/09-git-internals/01-chapter9.markdown
index f10253059..1da300664 100644
--- a/zh-tw/09-git-internals/01-chapter9.markdown
+++ b/zh-tw/09-git-internals/01-chapter9.markdown
@@ -16,7 +16,7 @@
 
 當你在一個新目錄或已有目錄內執行 `git init` 時，Git 會創建一個 `.git` 目錄，幾乎所有 Git 儲存和操作的內容都位於該目錄下。如果你要備份或複製一個倉庫，基本上將這一目錄拷貝至其他地方就可以了。本章基本上都討論該目錄下的內容。該目錄結構如下： 
 
-	$ ls 
+	$ ls
 	HEAD
 	branches/
 	config
@@ -54,7 +54,7 @@ Git 初始化了 `objects 目錄`，同時在該目錄下創建了 `pack` 和 `i
 
 參數 `-w` 指示 `hash-object` 命令儲存 (資料) 物件，若不指定這個參數該命令僅僅回傳鍵值。`--stdin` 指定從標準輸入裝置 (stdin) 來讀取內容，若不指定這個參數，`hash-object` 就需要指定一個要儲存的檔案路徑。該命令輸出長度為 40 個字元的校驗和(checksum hash)。這是個 SHA-1 雜湊值──其值為要儲存的資料加上你馬上會瞭解到的一種頭資訊(header)的校驗和。現在可以查看到 Git 已經儲存了資料： 
 
-	$ find .git/objects -type f 
+	$ find .git/objects -type f
 	.git/objects/d6/70460b4b4aece5915caf5c68d12f560a9fe3e4
 
 可以在 `objects` 目錄下看到一個檔。這便是 Git 儲存資料內容的方式──為每份內容生成一個檔，取得該內容與頭資訊的 SHA-1 校驗和，創建以該校驗和前兩個字元為名稱的子目錄，並以 (校驗和) 剩下 38 個字元為檔命名 (保存至子目錄下)。 
@@ -67,32 +67,32 @@ Git 初始化了 `objects 目錄`，同時在該目錄下創建了 `pack` 和 `i
 可以往 Git 中添加更多內容並取回了。也可以直接添加檔案。比方說可以對一個檔進行簡單的版本控制。首先，創建一個新檔，並把檔案內容儲存到資料庫中：
 
 	$ echo 'version 1' > test.txt
-	$ git hash-object -w test.txt 
+	$ git hash-object -w test.txt
 	83baae61804e65cc73a7201a7252750c76066a30
 
 接著往該檔中寫入一些新內容並再次保存： 
 
 	$ echo 'version 2' > test.txt
-	$ git hash-object -w test.txt 
+	$ git hash-object -w test.txt
 	1f7a7a472abf3dd9643fd615f6da379c4acb3e3a
 
 資料庫中已經將檔案的兩個新版本連同一開始的內容保存下來了： 
 
-	$ find .git/objects -type f 
+	$ find .git/objects -type f
 	.git/objects/1f/7a7a472abf3dd9643fd615f6da379c4acb3e3a
 	.git/objects/83/baae61804e65cc73a7201a7252750c76066a30
 	.git/objects/d6/70460b4b4aece5915caf5c68d12f560a9fe3e4
 
 再將檔案修復到第一個版本： 
 
-	$ git cat-file -p 83baae61804e65cc73a7201a7252750c76066a30 > test.txt 
-	$ cat test.txt 
+	$ git cat-file -p 83baae61804e65cc73a7201a7252750c76066a30 > test.txt
+	$ cat test.txt
 	version 1
 
 或恢復到第二個版本： 
 
-	$ git cat-file -p 1f7a7a472abf3dd9643fd615f6da379c4acb3e3a > test.txt 
-	$ cat test.txt 
+	$ git cat-file -p 1f7a7a472abf3dd9643fd615f6da379c4acb3e3a > test.txt
+	$ cat test.txt
 	version 2
 
 需要記住的是幾個版本的檔 SHA-1 值可能與實際的值不同，其次，儲存的並不是檔案名而僅僅是檔案內容。這種物件類型稱為 blob 。通過傳遞 SHA-1 值給 `cat-file -t` 命令可以讓 Git 返回任何物件的類型： 
@@ -116,7 +116,7 @@ Git 初始化了 `objects 目錄`，同時在該目錄下創建了 `pack` 和 `i
 
 從概念上來講，Git 保存的資料如圖 9-1 所示。 
 
-Insert 18333fig0901.png 
+Insert 18333fig0901.png
 Figure 9-1. Git 物件模型的簡化版
 
 你可以自己創建 tree 。通常 Git 根據你的暫存區域或 index 來創建並寫入一個 tree 。因此要創建一個 tree 物件的話首先要通過將一些檔暫存從而創建一個 index 。可以使用 plumbing 命令 `update-index` 為一個單獨檔 ── test.txt 檔的第一個版本 ──　創建一個 index。通過該命令人工地將 test.txt 檔的首個版本加入到了一個新的暫存區域中。由於該檔原先並不在暫存區域中 (甚至就連暫存區域也還沒被創建出來呢)，必須傳入 `--add` 參數；由於要添加的檔並不在目前的目錄下而是在資料庫中，必須傳入 `--cacheinfo` 參數。同時指定檔案模式，SHA-1 值和檔案名：
@@ -141,8 +141,8 @@ Figure 9-1. Git 物件模型的簡化版
 再根據 test.txt 的第二個版本以及一個新檔創建一個新 tree 物件： 
 
 	$ echo 'new file' > new.txt
-	$ git update-index test.txt 
-	$ git update-index --add new.txt 
+	$ git update-index test.txt
+	$ git update-index --add new.txt
 
 這時暫存區域中包含了 test.txt 的新版本及一個新檔 new.txt 。創建 (寫) 該 tree 物件 (將暫存區域或 index 狀態寫入到一個 tree 物件)，然後瞧瞧它的樣子： 
 
@@ -164,7 +164,7 @@ Figure 9-1. Git 物件模型的簡化版
 
 如果從剛寫入的新 tree 物件創建一個工作目錄，將得到位於工作目錄頂級的兩個檔和一個名為 `bak` 的子目錄，該子目錄包含了 test.txt 檔的第一個版本。可以將 Git 用來包含這些內容的資料想像成如圖 9-2 所示的樣子。 
 
-Insert 18333fig0902.png 
+Insert 18333fig0902.png
 Figure 9-2. 當前 Git 資料的內容結構 
 
 ### Commit 物件 ###
@@ -241,7 +241,7 @@ commit 物件格式很簡單：指明了該時間點專案快照的頂層樹物
 
 如果你按照以上描述進行了操作，可以得到如圖 9-3 所示的物件圖。 
 
-Insert 18333fig0903.png 
+Insert 18333fig0903.png
 Figure 9-3. Git 目錄下的所有物件
 
 ### 物件儲存 ###
@@ -326,7 +326,7 @@ Git 用 zlib 對資料內容進行壓縮，在 Ruby 中可以用 zlib 程式庫
 
 現在，你的 Git 資料庫應該看起來像圖 9-4 一樣。 
 
-Insert 18333fig0904.png 
+Insert 18333fig0904.png
 Figure 9-4. 包含分支引用的 Git 目錄物件 
 
 每當你執行 `git branch (分支名稱)` 這樣的命令，Git 基本上就是執行 `update-ref` 命令，把你現在所在分支中最後一次提交的 SHA-1 值，添加到你要創建的分支的引用。 
@@ -335,12 +335,12 @@ Figure 9-4. 包含分支引用的 Git 目錄物件
 
 現在的問題是，當你執行 `git branch (分支名稱)` 這條命令的時候，Git 怎麼知道最後一次提交的 SHA-1 值呢？答案就是 HEAD 檔。HEAD 檔是一個指向你當前所在分支的引用識別字。這樣的引用識別字——它看起來並不像一個普通的引用——其實並不包含 SHA-1 值，而是一個指向另外一個引用的指標。如果你看一下這個檔，通常你將會看到這樣的內容： 
 
-	$ cat .git/HEAD 
+	$ cat .git/HEAD
 	ref: refs/heads/master
 
 如果你執行 `git checkout test`，Git 就會更新這個檔，看起來像這樣： 
 
-	$ cat .git/HEAD 
+	$ cat .git/HEAD
 	ref: refs/heads/test
 
 當你再執行 `git commit` 命令，它就創建了一個 commit 物件，把這個 commit 物件的父級設置為 HEAD 指向的引用的 SHA-1 值。 
@@ -353,7 +353,7 @@ Figure 9-4. 包含分支引用的 Git 目錄物件
 你也可以設置 HEAD 的值： 
 
 	$ git symbolic-ref HEAD refs/heads/test
-	$ cat .git/HEAD 
+	$ cat .git/HEAD
 	ref: refs/heads/test
 
 但是你不能設置成 refs 以外的形式： 
@@ -375,7 +375,7 @@ Figure 9-4. 包含分支引用的 Git 目錄物件
 
 這是所創建物件的 SHA-1 值：
 
-	$ cat .git/refs/tags/v1.1 
+	$ cat .git/refs/tags/v1.1
 	9585191f37f7b0fb9444f35a9bf50de191beadc2
 
 現在你可以執行 `cat-file` 命令檢查這個 SHA-1 值： 
@@ -409,7 +409,7 @@ Git 原始程式碼裡的公開金鑰. Linux kernel 也有一個不是指向 com
 
 然後查看 `refs/remotes/origin/master` 這個檔，你就會發現 `origin` remote 中的 `master` 分支就是你最後一次和伺服器的通信。 
 
-	$ cat .git/refs/remotes/origin/master 
+	$ cat .git/refs/remotes/origin/master
 	ca82a6dff817ec66f44342007202690a93763949
 
 Remote references 和分支(`refs/heads` references)的主要區別在於他們是不能被 check out 的。Git 把他們當作是標記了這些分支在伺服器上最後狀態的一種書簽。 
@@ -433,8 +433,8 @@ Remote references 和分支(`refs/heads` references)的主要區別在於他們
 
 Git 用 zlib 壓縮檔案內容，因此這些檔並沒有佔用太多空間，所有檔加起來總共僅用了 925 位元組。接下去你將添加一些大檔以演示 Git 的一個很有意思的功能。將你之前用到過的 Grit 庫中的 repo.rb 檔加進去 ── 這個原始程式碼檔大小約為 12K： 
 
-	$ curl http://github.com/mojombo/grit/raw/master/lib/grit/repo.rb > repo.rb
-	$ git add repo.rb 
+	$ curl https://raw.github.com/mojombo/grit/master/lib/grit/repo.rb > repo.rb
+	$ git add repo.rb
 	$ git commit -m 'added repo.rb'
 	[master 484a592] added repo.rb
 	 3 files changed, 459 insertions(+), 2 deletions(-)
@@ -451,8 +451,8 @@ Git 用 zlib 壓縮檔案內容，因此這些檔並沒有佔用太多空間，
 
 然後可以用 `git cat-file` 命令查看這個物件有多大： 
 
-	$ git cat-file -s 9bc1dc421dcd51b4ac296e3e5b6e2a99cf44391e
-	12898
+	$ du -b .git/objects/9b/c1dc421dcd51b4ac296e3e5b6e2a99cf44391e
+	4102	.git/objects/9b/c1dc421dcd51b4ac296e3e5b6e2a99cf44391e
 
 稍微修改一下些檔，看會發生些什麼： 
 
@@ -470,8 +470,8 @@ Git 用 zlib 壓縮檔案內容，因此這些檔並沒有佔用太多空間，
 
 blob 物件與之前的已經不同了。這說明雖然只是往一個 400 行的檔最後加入了一行內容，Git 卻用一個全新的物件來保存新的檔案內容： 
 
-	$ git cat-file -s 05408d195263d853f09dca71d55116663690c27c
-	12908
+	$ du -b .git/objects/05/408d195263d853f09dca71d55116663690c27c
+	4109	.git/objects/05/408d195263d853f09dca71d55116663690c27c
 
 你的磁片上有了兩個幾乎完全相同的 12K 的物件。如果 Git 只完整保存其中一個，並保存另一個物件的差異內容，豈不更好？ 
 
@@ -784,8 +784,8 @@ Git 會不定時地自動執行稱為「auto gc」的命令。大部分情況下
 
 這時如果執行 `git gc`, `refs` 下的所有檔都會消失。Git 會將這些檔挪到 `.git/packed-refs` 檔中去以提高效率，該檔是這個樣子的： 
 
-	$ cat .git/packed-refs 
-	# pack-refs with: peeled 
+	$ cat .git/packed-refs
+	# pack-refs with: peeled
 	cac0cab538b970a37ea1e769cbbde608743bc96d refs/heads/experiment
 	ab1afef80fac8e34258ff41fc1b867c702daa24b refs/heads/master
 	cac0cab538b970a37ea1e769cbbde608743bc96d refs/tags/v1.0
@@ -858,7 +858,7 @@ Git 會不定時地自動執行稱為「auto gc」的命令。大部分情況下
 酷！這樣有了一個跟原來 `master` 一樣的 `recover-branch` 分支，最新的兩個 commit 又找回來了。 
 接著，假設引起 commit 丟失的原因並沒有記錄在 reflog 中 ── 可以通過刪除 `recover-branch` 和 reflog 來類比這種情況。這樣最新的兩個 commit 不會被任何東西引用到： 
 
-	$ git branch –D recover-branch
+	$ git branch -D recover-branch
 	$ rm -Rf .git/logs/
 
 因為 reflog 資料是保存在 `.git/logs/` 目錄下的，這樣就沒有 reflog 了。現在要怎樣恢復 commit 呢？辦法之一是使用 `git fsck` 工具，該工具會檢查倉庫的資料完整性。如果指定 `--full` 選項，該命令顯示所有未被其他物件引用 (指向) 的所有物件： 
@@ -890,7 +890,7 @@ Git 有許多過人之處，不過有一個功能有時卻會帶來問題：`git
 
 喔，你並不想往專案中加進一個這麼大的 tar 包。最後還是去掉它： 
 
-	$ git rm git.tbz2 
+	$ git rm git.tbz2
 	rm 'git.tbz2'
 	$ git commit -m 'oops - removed large tarball'
 	[master da3f30d] oops - removed large tarball

From 7db428809dc29eae70eaa6b67ddc692189de2523 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Sun, 2 Feb 2014 20:17:44 -0600
Subject: [PATCH 147/690] Reviewing "Private Small Team"

---
 it/05-distributed-git/01-chapter5.markdown | 26 +++++++++++-----------
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/it/05-distributed-git/01-chapter5.markdown b/it/05-distributed-git/01-chapter5.markdown
index 19cb4562c..0f12e0670 100755
--- a/it/05-distributed-git/01-chapter5.markdown
+++ b/it/05-distributed-git/01-chapter5.markdown
@@ -107,12 +107,12 @@ Se tutti i tuoi messaggi di commit fossero così, per te e gli altri sviluppator
 
 Nei esempi che seguono e nella maggior parte di questo libro, per brevità, non formatterò i messaggi accuratamente come descritto: userò invece l'opzione `-m` di `git commit`. Fa' come dico, non come faccio.
 
-### Piccoli team privati ###
+### Piccoli gruppi privati ###
 
-La configurazione più semplice e facile da incontrare è il progetto privato con uno o due sviluppatori. Con privato, intendo codice a sorgente chiuso - non accessibile dal resto del mondo. Tu e gli altri sviluppatori avete tutti accesso per il push verso il repository.
+La configurazione più semplice che è più facile che incontrerai è quella del progetto privato con uno o due sviluppatori. Con privato intendo codice a sorgente chiuso: non accessibile al resto del mondo. Tu e gli altri sviluppatori avete accesso in scrittura al repository.
 
-In questo ambiente, puoi utilizzare un workflow simile a quello che magari stai già usando con Subversion od un altro sistema centralizzato. Hai ancora i vantaggi (ad esempio) di poter eseguire commit da offline e la creazione di rami (ed unione degli stessi) molto più semplici, ma il workflow può restare simile; la differenza principale è che, nel momento del commit, l'unione avviene nel tuo repository piuttosto che in quello sul server.
-Vediamo come potrebbe essere la situazione quando due sviluppatori iniziano a lavorare insieme con un repository condiviso. Il primo sviluppatore, John, clona in repository, fa dei cambiamenti ed esegue il commit localmente. (Sostituisco il messaggio di protocollo con `...` in questi esempi per brevità.)
+Con questa configurazione, puoi utilizzare un workflow simile a quello che magari stai già usando con Subversion o un altro sistema centralizzato. Hai comunque i vantaggi (ad esempio) di poter eseguire commit da offline e la creazione di rami (ed unione degli stessi) molto più semplici, ma il workflow può restare simile; la differenza principale è che, nel momento del commit, l'unione avviene nel tuo repository piuttosto che in quello sul server.
+Vediamo come potrebbe essere la situazione quando due sviluppatori iniziano a lavorare insieme con un repository condiviso. Il primo sviluppatore, John, clona in repository, fa dei cambiamenti ed esegue il commit localmente. (In questi esempi sostituirò, per brevità, il messaggio del protocollo con `...`)
 
 	# Computer di John
 	$ git clone john@githost:simplegit.git
@@ -124,7 +124,7 @@ Vediamo come potrebbe essere la situazione quando due sviluppatori iniziano a la
 	[master 738ee87] rimosso valore di default non valido
 	 1 files changed, 1 insertions(+), 1 deletions(-)
 
-Il secondo sviluppatore, Jessica, fa la stessa cosa - clona il repository ed esegue dei cambiamenti:
+Il secondo sviluppatore, Jessica, fa la stessa cosa - clona il repository e committa le modifiche:
 
 	# Computer di Jessica
 	$ git clone jessica@githost:simplegit.git
@@ -136,7 +136,7 @@ Il secondo sviluppatore, Jessica, fa la stessa cosa - clona il repository ed ese
 	[master fbff5bc] aggiunto il processo di reset
 	 1 files changed, 1 insertions(+), 0 deletions(-)
 
-Ora, Jessica esegue un push del suo lavoro nel server:
+Ora, Jessica invia il suo lavoro al server con una push:
 
 	# Computer di Jessica
 	$ git push origin master
@@ -144,7 +144,7 @@ Ora, Jessica esegue un push del suo lavoro nel server:
 	To jessica@githost:simplegit.git
 	   1edee6b..fbff5bc  master -> master
 
-Anche John cerca di eseguire un push:
+Anche John cerca di eseguire una push:
 
 	# Computer di John
 	$ git push origin master
@@ -152,7 +152,7 @@ Anche John cerca di eseguire un push:
 	 ! [rejected]        master -> master (non-fast forward)
 	error: failed to push some refs to 'john@githost:simplegit.git'
 
-A John non è consentito eseguire un push perché Jessica ha fatto lo stesso nel frattempo. Questo è particolarmente importante se sei abituato a Subversion, perché avrai notato che i due sviluppatori non hanno modificato lo stesso file. Anche se Subversion automaticamente esegue questa unione nel server se differenti file sono stati modificati, in Git devi unire i cambiamenti localmente. John deve recuperare i cambiamenti di Jessica ed unirli ai suoi prima di poter eseguire il push:
+A John non è permesso fare un push perché nel frattempo lo ha già fatto Jessica. Questo è particolarmente importante se sei abituato a Subversion, perché vedrai che i due sviluppatori non hanno modificato lo stesso file. Sebbene Subversion unisca automaticamente sul server queste commit se i file modificati sono diversi, in Git sei tu che devi farlo localmente. John deve quindi scaricare le modifiche di Jessica e unirle alle sue prima di poter fare una push:
 
 	$ git fetch origin
 	...
@@ -164,29 +164,29 @@ A questo punto, il repository locale di John somiglia a quello di figura 5-4.
 Insert 18333fig0504.png
 Figura 5-4. Il repository iniziale di John.
 
-John ha a disposizione i cambiamenti che Jessica ha eseguito, ma deve unirli ai suoi prima di avere la possibilità di eseguire un push:
+John sa quali sono le modifiche di Jessica, ma deve unirle alle sue prima poter fare una push:
 
 	$ git merge origin/master
 	Merge made by recursive.
 	 TODO |    1 +
 	 1 files changed, 1 insertions(+), 0 deletions(-)
 
-L'unione fila liscia - ora la cronologia dei commit di John sarà come quella di Figura 5-5.
+L'unione fila liscia e ora la cronologia delle commit di John sarà come quella di Figura 5-5.
 
 Insert 18333fig0505.png
 Figura 5-5. Il repository di John dopo aver unito origin/master.
 
-Ora, John può testare il suo codice per essere sicuro che funzioni anche correttamente e può eseguire il push del tutto verso il server:
+John ora può testare il suo codice per essere sicuro che continui a funzionare correttamente e può quindi eseguire la push del tutto sul server:
 
 	$ git push origin master
 	...
 	To john@githost:simplegit.git
 	   fbff5bc..72bbc59  master -> master
 
-Infine, la cronologia dei commit di John somiglierà a quella di figura 5-6.
+La cronologia dei commit di John somiglierà quindi a quella di figura 5-6.
 
 Insert 18333fig0506.png
-Figura 5-6. La cronologia di John dopo avere eseguito il push verso il server.
+Figura 5-6. La cronologia di John dopo avere eseguito la push verso il server.
 
 Nel frattempo, Jessica sta lavorando su un altro ramo. Ha creato un ramo chiamato `problema54` ed ha eseguito tre commit su quel ramo. Non ha ancora recuperato i cambiamenti di John, per cui la sua cronologia di commit è quella di Figura 5-7.
 

From 6302a8995f4875763023b006a8af766c24e04bc2 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Sun, 2 Feb 2014 20:20:30 -0600
Subject: [PATCH 148/690] Reviewing "Private Small Team"

---
 it/05-distributed-git/01-chapter5.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/it/05-distributed-git/01-chapter5.markdown b/it/05-distributed-git/01-chapter5.markdown
index 0f12e0670..a678c5d34 100755
--- a/it/05-distributed-git/01-chapter5.markdown
+++ b/it/05-distributed-git/01-chapter5.markdown
@@ -188,7 +188,7 @@ La cronologia dei commit di John somiglierà quindi a quella di figura 5-6.
 Insert 18333fig0506.png
 Figura 5-6. La cronologia di John dopo avere eseguito la push verso il server.
 
-Nel frattempo, Jessica sta lavorando su un altro ramo. Ha creato un ramo chiamato `problema54` ed ha eseguito tre commit su quel ramo. Non ha ancora recuperato i cambiamenti di John, per cui la sua cronologia di commit è quella di Figura 5-7.
+Jessica nel frattempo sta lavorando a un altro ramo. Ha creato un branch chiamato `problema54` e ha eseguito tre commit su quel branch. Poiché non ha ancora recuperato le modifiche di John la sua cronologia è quella della Figura 5-7.
 
 Insert 18333fig0507.png
 Figura 5-7. La cronologia iniziale di Jessica.

From e342ad89628b185f1ef1e3396b0c03cde36cd87e Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Sun, 2 Feb 2014 20:27:59 -0600
Subject: [PATCH 149/690] Reviewing "Private Small Team"

---
 it/05-distributed-git/01-chapter5.markdown | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/it/05-distributed-git/01-chapter5.markdown b/it/05-distributed-git/01-chapter5.markdown
index a678c5d34..7ba146e47 100755
--- a/it/05-distributed-git/01-chapter5.markdown
+++ b/it/05-distributed-git/01-chapter5.markdown
@@ -193,7 +193,7 @@ Jessica nel frattempo sta lavorando a un altro ramo. Ha creato un branch chiamat
 Insert 18333fig0507.png
 Figura 5-7. La cronologia iniziale di Jessica.
 
-Jessica vuole sincronizzarsi con John, così recupera:
+Jessica vuole sincronizzarsi con John, quindi esegue:
 
 	# Computer di Jessica
 	$ git fetch origin
@@ -201,12 +201,12 @@ Jessica vuole sincronizzarsi con John, così recupera:
 	From jessica@githost:simplegit
 	   fbff5bc..72bbc59  master     -> origin/master
 
-Questo recupera il lavoro che John ha eseguito nel frattempo. La cronologia di Jessica ora è quella di Figura 5-8.
+Con cui recupera il lavoro che nel frattempo John ha eseguito. La cronologia di Jessica ora è quella di Figura 5-8.
 
 Insert 18333fig0508.png
 Figura 5-8. La cronologia di Jessica dopo aver recuperato i cambiamenti di John.
 
-Jessica pensa che il suo ramo sia pronto, però vuole sapere con cosa deve unire il suo lavoro prima di eseguire il push. Esegue `git log` per scoprirlo:
+Jessica pensa che il suo ramo sia pronto, però vuole sapere con cosa deve unire il suo lavoro prima di eseguire la push. Esegue quindi `git log` per scoprirlo:
 
 	$ git log --no-merges origin/master ^problema54
 	commit 738ee872852dfaa9d6634e0dea7a324040193016

From f53c5b716b14aacda42385a91d2b61f8241c5472 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Sun, 2 Feb 2014 21:01:37 -0600
Subject: [PATCH 150/690] Reviewing "Private Small Team"

---
 it/05-distributed-git/01-chapter5.markdown | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/it/05-distributed-git/01-chapter5.markdown b/it/05-distributed-git/01-chapter5.markdown
index 7ba146e47..3cb60305b 100755
--- a/it/05-distributed-git/01-chapter5.markdown
+++ b/it/05-distributed-git/01-chapter5.markdown
@@ -215,13 +215,13 @@ Jessica pensa che il suo ramo sia pronto, però vuole sapere con cosa deve unire
 
 	    rimosso valore di default non valido
 
-Ora, Jessica può unire il suo lavoro al ramo master, unire il lavoro di John (`origin/master`) nel suo ramo `master`, e poi eseguire il push verso il server di nuovo. Per prima cosa, torna nel suo ramo master per integrare il suo lavoro:
+Ora, Jessica può unire il lavoro del suo branch nel suo master, quindi le modifiche di John (`origin/master`) nel suo branch `master`, e ritrasmettere il tutto al server con una push. Per prima cosa torna al suo branch master per integrare il lavoro svolto nell'altro branch:
 
 	$ git checkout master
 	Switched to branch "master"
 	Your branch is behind 'origin/master' by 2 commits, and can be fast-forwarded.
 
-Può unire sia `origin/master` che `problema54` per primo - sono entrambi a monte, per cui l'ordine non conta. Il risultato finale sarà lo stesso a prescindere dall'ordine scelto; solo la cronologia sarà leggermente differente. Lei sceglie di unire `problema54` per primo:
+Può decidere di unire prima `origin/master` o `problema54`: entrambi sono flussi principali, per cui non conta l'ordine. Il risultato finale sarà lo stesso a prescindere dall'ordine scelto, ma la cronologia sarà leggermente differente. Lei sceglie di fare il merge prima di `problema54`:
 
 	$ git merge problema54
 	Updating fbff5bc..4af4298
@@ -230,7 +230,7 @@ Può unire sia `origin/master` che `problema54` per primo - sono entrambi a mont
 	 lib/simplegit.rb |    6 +++++-
 	 2 files changed, 6 insertions(+), 1 deletions(-)
 
-Non ci sono problemi; come puoi vederem è stato tutto semplice. Ora Jessica unisce il lavoro di John (`origin/master`):
+Non ci sono stati problemi: come puoi vedere tutto è stato molto semplice. Quindi Jessica unisce il lavoro di John (`origin/master`):
 
 	$ git merge origin/master
 	Auto-merging lib/simplegit.rb

From c1c856b3e9df1306fd3b9fd361d2229d91b4bbd9 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Sun, 2 Feb 2014 21:08:07 -0600
Subject: [PATCH 151/690] Reviewing "Private Small Team"

---
 it/05-distributed-git/01-chapter5.markdown | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/it/05-distributed-git/01-chapter5.markdown b/it/05-distributed-git/01-chapter5.markdown
index 3cb60305b..ad62b3e65 100755
--- a/it/05-distributed-git/01-chapter5.markdown
+++ b/it/05-distributed-git/01-chapter5.markdown
@@ -243,14 +243,14 @@ Tutto viene unito correttamente, e la cronologia di Jessica è come quella di Fi
 Insert 18333fig0509.png
 Figura 5-9. La cronologia di Jessica dopo aver unito i cambiamenti di John.
 
-Ora `origin/master` è raggiungibile dal ramo `master` di Jessica, cosicché lei sia capace di eseguire dei push successivamente (assumento che John non abbia fatto lo stesso nel frattempo):
+Ora `origin/master` è raggiungibile dal ramo `master` di Jessica, cosicché lei sia capace di eseguire delle push con successo (supponendo che John non abbia fatto altre push nel frattempo):
 
 	$ git push origin master
 	...
 	To jessica@githost:simplegit.git
 	   72bbc59..8059c15  master -> master
 
-Ogni sviluppatore ha eseguito alcuni commit ed unito il proprio lavoro con quello di altri con successo; vedi Figura 5-10.
+Ogni sviluppatore ha eseguito alcune commit ed unito con successo il proprio lavoro con quello degli altri; vedi Figura 5-10.
 
 Insert 18333fig0510.png
 Figura 5-10. La cronologia di Jessica dopo aver eseguito il push dei cambiamenti verso il server.

From 81a2a1fde1c99681a8f6cae7691f74076e7d45c2 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Sun, 2 Feb 2014 21:19:06 -0600
Subject: [PATCH 152/690] Reviewed "Private Small Team"

---
 it/05-distributed-git/01-chapter5.markdown | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/it/05-distributed-git/01-chapter5.markdown b/it/05-distributed-git/01-chapter5.markdown
index ad62b3e65..3524f807a 100755
--- a/it/05-distributed-git/01-chapter5.markdown
+++ b/it/05-distributed-git/01-chapter5.markdown
@@ -255,10 +255,10 @@ Ogni sviluppatore ha eseguito alcune commit ed unito con successo il proprio lav
 Insert 18333fig0510.png
 Figura 5-10. La cronologia di Jessica dopo aver eseguito il push dei cambiamenti verso il server.
 
-Questo è uno dei workflow più semplici. Lavori per un pò, generalmente in un ramo, ed unisci il tutto al ramo master questo è pronto ad essere integrato. Quando vuoi condividere il tuo lavoro, uniscilo al tuo ramo master, poi recupera ed unisci `origin/master` se è cambiato, ed infine esegui il push verso il ramo `master` nel server. La sequenza è simile a quella di Figura 5-11.
+Questo è uno dei workflow più semplici. Lavori per un po', generalmente in un branch, ed unisci il tutto al branch master quando è pronto per essere integrato. Quando vuoi condividere questo lavoro lo unisci al tuo branch master e poi scarichi ed unisci `origin/master`, se è cambiato, e infine esegui la push verso il branch `master` nel server. La sequenza è simile a quella in Figura 5-11.
 
 Insert 18333fig0511.png
-Figura 5-11. La sequenza generale di eventi per un semplice workflow con Git a più sviluppatori.
+Figura 5-11. La sequenza generale di eventi per un workflow semplice con Git a più sviluppatori.
 
 ### Team privato con manager ###
 

From 23c4b8e03610d461f93328b915a5f4c69fc243a2 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Sun, 2 Feb 2014 21:41:21 -0600
Subject: [PATCH 153/690] Reviewing "Private Managed Team"

---
 it/05-distributed-git/01-chapter5.markdown | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/it/05-distributed-git/01-chapter5.markdown b/it/05-distributed-git/01-chapter5.markdown
index 3524f807a..e7b7bac44 100755
--- a/it/05-distributed-git/01-chapter5.markdown
+++ b/it/05-distributed-git/01-chapter5.markdown
@@ -262,9 +262,9 @@ Figura 5-11. La sequenza generale di eventi per un workflow semplice con Git a p
 
 ### Team privato con manager ###
 
-In questo prossimo scenario, scoprirai ai ruoli di un contributore in un gruppo privato più grande. Imparerai come lavorare in un ambiente dove piccoli gruppi collaborano a delle funzionalità e poi queste contribuzioni sono integrate da un altro componente.
+In questo scenario, scoprirai i ruoli di contributore in un gruppo privato più grande. Imparerai come lavorare in un ambiente dove gruppi piccoli collaborano a delle funzionalità e poi queste contribuzioni sono integrate da un altra persona.
 
-Supponiamo che John e Jessica stiano lavorando insieme su una funzionalità, mentre Jessica e Josie si stanno concentrando su una seconda. In questo caso, l'azienda sta usando un workflow con manager d'integrazione dove il lavoro di ogni gruppo è integrato solo da certi ingegneri, ed il ramo `master` del repository principale può essere aggiornato solo dai suddetti ingegneri. In questo scenario, tutto il lavoro è eseguito sui rami suddivisi per team, ed unito dagli integratori in seguito.
+Supponiamo che John e Jessica stiano lavorando insieme a una funzionalità, mentre Jessica e Josie si stiano concentrando a una seconda. In questo caso l'azienda sta usando un workflow con manager d'integrazione dove il lavoro di ogni gruppo è integrato solo da alcuni ingegneri, ed il branch `master` del repository principale può essere aggiornato solo da questi. In questo scenario, tutto il lavoro è eseguito sui rami suddivisi per team, e unito successivamente dagli integratori.
 
 Seguiamo il workflow di Jessica mentre lavora sulle due funzionalità, collaborando parallelamente con due diversi sviluppatori in questo ambiente. Assumendo che lei abbia già clonato il suo repository, decide di lavorare su `funzionalitaA` per prima. Crea un nuovo ramo per la funzionalità ed esegue del lavoro su di esso.
 

From 8a76f5e5a71994639fa4bcdb8ab54fad50dee2a9 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Sun, 2 Feb 2014 21:50:30 -0600
Subject: [PATCH 154/690] Reviewing "Private Managed Team"

---
 it/05-distributed-git/01-chapter5.markdown | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/it/05-distributed-git/01-chapter5.markdown b/it/05-distributed-git/01-chapter5.markdown
index e7b7bac44..4ce2ad9da 100755
--- a/it/05-distributed-git/01-chapter5.markdown
+++ b/it/05-distributed-git/01-chapter5.markdown
@@ -266,7 +266,7 @@ In questo scenario, scoprirai i ruoli di contributore in un gruppo privato più
 
 Supponiamo che John e Jessica stiano lavorando insieme a una funzionalità, mentre Jessica e Josie si stiano concentrando a una seconda. In questo caso l'azienda sta usando un workflow con manager d'integrazione dove il lavoro di ogni gruppo è integrato solo da alcuni ingegneri, ed il branch `master` del repository principale può essere aggiornato solo da questi. In questo scenario, tutto il lavoro è eseguito sui rami suddivisi per team, e unito successivamente dagli integratori.
 
-Seguiamo il workflow di Jessica mentre lavora sulle due funzionalità, collaborando parallelamente con due diversi sviluppatori in questo ambiente. Assumendo che lei abbia già clonato il suo repository, decide di lavorare su `funzionalitaA` per prima. Crea un nuovo ramo per la funzionalità ed esegue del lavoro su di esso.
+Seguiamo il workflow di Jessica mentre lavora sulle due funzionalità, collaborando parallelamente con due diversi sviluppatori in questo ambiente. Assumendo che lei abbia già clonato il suo repository, decide di lavorare prima alla `funzionalitaA`. Crea un nuovo branch per la funzionalità e ci lavora.
 
 	# Computer di Jessica
 	$ git checkout -b featureA
@@ -276,7 +276,7 @@ Seguiamo il workflow di Jessica mentre lavora sulle due funzionalità, collabora
 	[featureA 3300904] aggiunto il limite alla funzione di log
 	 1 files changed, 1 insertions(+), 1 deletions(-)
 
-A questo punto, lei ha bisogno di condividere il suo lavoro con John, così lei esegue il push del ramo `funzionalitaA` sul server. Jessica non ha accesso per il push al ramo `master` - solo gli integratori ce l'hanno - perciò deve eseguire il push verso un altro ramo per poter collaborare con John:
+A questo punto lei deve condividere il suo lavoro con John, così fa la push sul server del branch `funzionalitaA`. Poiché Jessica non ha permessi per fare la push sul ramo `master` (solo gli integratori ce l'hanno) deve perciò eseguire la push su un altro branch per poter collaborare con John:
 
 	$ git push origin funzionalitaA
 	...

From deb848b17345c681069856165bc53d6796a1d02f Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Sun, 2 Feb 2014 22:47:45 -0600
Subject: [PATCH 155/690] Reviewing "Private Managed Team"

---
 it/05-distributed-git/01-chapter5.markdown | 11 +++++------
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/it/05-distributed-git/01-chapter5.markdown b/it/05-distributed-git/01-chapter5.markdown
index 4ce2ad9da..fbf85893c 100755
--- a/it/05-distributed-git/01-chapter5.markdown
+++ b/it/05-distributed-git/01-chapter5.markdown
@@ -283,14 +283,14 @@ A questo punto lei deve condividere il suo lavoro con John, così fa la push sul
 	To jessica@githost:simplegit.git
 	 * [new branch]      featureA -> featureA
 
-Jessica manda una e-mail a John dicendogli che ha eseguito il push del suo lavoro in un ramo chiamato `funzioanlitaA` e lui può dargli un'occhiata. Mentre aspetta una risposta da John, Jessica decide di iniziare a lavorare su `funzionalitaB` con Josie. Per iniziare, crea un nuovo ramo basandosi sul ramo `master` del server:
+Jessica manda una e-mail a John dicendogli che fatto la push del suo lavoro su un branch chiamato `funzioanlitaA` chiedendogli se lui può dargli un'occhiata. Mentre aspetta una risposta da John, Jessica decide di iniziare a lavorare su `funzionalitaB` con Josie. Per iniziare, crea un nuovo branch basandosi sul branch `master` del server:
 
   # Computer di Jessica
 	$ git fetch origin
 	$ git checkout -b featureB origin/master
 	Switched to a new branch "featureB"
 
-Ora, Jessica esegue un paio di commit sul ramo `funzionalitaB`:
+Quindi Jessica esegue un paio di commit sul branch `funzionalitaB`:
 
 	$ vim lib/simplegit.rb
 	$ git commit -am 'resa la funzione ls-tree ricorsiva'
@@ -304,10 +304,9 @@ Ora, Jessica esegue un paio di commit sul ramo `funzionalitaB`:
 Il repository di Jessica è come quello di Figura 5-12.
 
 Insert 18333fig0512.png
-Figura 5.12. La cronologia iniziale dei commit di Jessica
-Figure 5-12. Jessica’s initial commit history.
+Figura 5.12. La cronologia iniziale delle commit di Jessica
 
-Lei è pronta ad eseguire un push del proprio lavoro, ma riceve una e-mail da Josie la quale dice che una parte del lavoro era già stato messo nel server nel ramo chiamato `funzionalitaBee`. Jessica innanzitutto deve unire questi cambiamenti ai suoi prima di poter eseguire il push verso il server. Può recuperare il lavoro di Josie usando `git fetch`:
+Quando è pronta a eseguire una push del proprio lavoro riceve una e-mail da Josie che le dice che una parte del lavoro era già stato caricato sul server nel branch chiamato `funzionalitaBee`. Jessica deve unire prima le modifiche al server alle sue per poter fare la push verso il server. Può recuperare il lavoro di Josie usando `git fetch`:
 
 	$ git fetch origin
 	...
@@ -322,7 +321,7 @@ Jessica ora può unire il suo lavoro a quello di Josie con `git merge`:
 	 lib/simplegit.rb |    4 ++++
 	 1 files changed, 4 insertions(+), 0 deletions(-)
 
-C'è un problema - deve eseguire il push del suo ramo `funzionalitaB` verso il ramo `funzionalitaBee` nel server. Può farlo specificando il ramo locale seguito dal simbolo dei due punti (:) seguito a sua volta dal nome del ramo remoto destinazione del comando `git push`:
+C'è un piccolo problema: deve fare la push del suo branch `funzionalitaB` sul branch `funzionalitaBee` del server. Può farlo specificando il branch locale seguito da due punti (:) seguito a sua volta dal nome del branch remoto di destinazione al comando `git push`:
 
 	$ git push origin funzionalitaB:funzionalitaBee
 	...

From 9e6e9422ded5e9ea3c1a94445f5e797488d7fe55 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Sun, 2 Feb 2014 22:53:03 -0600
Subject: [PATCH 156/690] Reviewing "Private Managed Team"

---
 it/05-distributed-git/01-chapter5.markdown | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/it/05-distributed-git/01-chapter5.markdown b/it/05-distributed-git/01-chapter5.markdown
index fbf85893c..f3342b8d4 100755
--- a/it/05-distributed-git/01-chapter5.markdown
+++ b/it/05-distributed-git/01-chapter5.markdown
@@ -328,25 +328,25 @@ C'è un piccolo problema: deve fare la push del suo branch `funzionalitaB` sul b
 	To jessica@githost:simplegit.git
 	   fba9af8..cd685d1  featureB -> featureBee
 
-Questo è chiamato _refSpec_. Vedi il capitolo 9 per una discussione più dettagliata sui refspec di Git ed altre cose che puoi fare con loro.
+Questo è detto _refSpec_. Vedi il capitolo 9 per una discussione più dettagliata sui refspec di Git e cosa ci puoi fare.
 
-Ora John manda una mail a Jessica dicendo che ha eseguito il push di alcuni cambiamenti sul ramo `funzionalitaA` e le chiede di controllarli. Lei esegue `git fetch` per recuperare questi cambiamenti:
+John manda una mail a Jessica dicendole che ha fatto la push di alcune modifiche sul branch `funzionalitaA` e le chiede di controllarle. Lei esegue `git fetch` per scaricarle:
 
 	$ git fetch origin
 	...
 	From jessica@githost:simplegit
 	   3300904..aad881d  featureA   -> origin/featureA
 
-Ora, lei può vedere cos'è stato cambiato con `git log`:
+E può vederle con `git log`:
 
 	$ git log origin/funzionalitaA ^funzionalitaA
 	commit aad881d154acdaeb2b6b18ea0e827ed8a6d671e6
 	Author: John Smith <jsmith@example.com>
 	Date:   Fri May 29 19:57:33 2009 -0700
 
-	    cambianto l'output del log da 30 a 25
+	    cambiato l'output del log da 25 a 30
 
-Finalmente, unisce il lavoro di John al suo sul ramo `funzionalitaA`:
+Infine unisce il lavoro di John al suo nel branch `funzionalitaA`:
 
 	$ git checkout funzionalitaA
 	Switched to branch "funzionalitaA"

From 5d789600a8aa6dffee5a67410caf3c38b8c4727b Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Sun, 2 Feb 2014 23:05:46 -0600
Subject: [PATCH 157/690] Reviewed "Private Managed Team"

---
 it/05-distributed-git/01-chapter5.markdown | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/it/05-distributed-git/01-chapter5.markdown b/it/05-distributed-git/01-chapter5.markdown
index f3342b8d4..5775605be 100755
--- a/it/05-distributed-git/01-chapter5.markdown
+++ b/it/05-distributed-git/01-chapter5.markdown
@@ -356,7 +356,7 @@ Infine unisce il lavoro di John al suo nel branch `funzionalitaA`:
 	 lib/simplegit.rb |   10 +++++++++-
 	1 files changed, 9 insertions(+), 1 deletions(-)
 
-Jessica vuole aggiustare qualcosa, così esegue un altro commit ed un push verso il server:
+Jessica vuole aggiustare qualcosa e fa un'altro commit ed una push verso il server:
 
 	$ git commit -am 'leggero aggiustamento'
 	[featureA ed774b3] leggero aggiustamento
@@ -366,17 +366,17 @@ Jessica vuole aggiustare qualcosa, così esegue un altro commit ed un push verso
 	To jessica@githost:simplegit.git
 	   3300904..ed774b3  featureA -> featureA
 
-Ora la cronologia dei commit di Jessica sarà come quella di Figura 5-13.
+La cronologia delle commit di Jessica ora sarà come quella della Figura 5-13.
 
 Insert 18333fig0513.png
-Figura 5-13. La cronologia di Jessica dopo aver eseguito il commit sul ramo.
+Figura 5-13. La cronologia di Jessica dopo aver eseguito la commit sul branch.
 
-Jessica, Josie e John informano gli integratori che i rami `funzionalitaA` e `funzionalitaB` sono sul server e pronti per l'integrazione nel ramo `master`. Dopo l'integrazione di questi rami nel `master`, un recupero del ramo principale aggiungerà anche i nuovi commit, rendendo la cronologia dei commit come quella di figura 5.14.
+Jessica, Josie e John informano gli integratori che i rami `funzionalitaA` e `funzionalitaB` che sono sul server sono pronti per l'integrazione nel `master`. Dopo l'integrazione di questi branch nel `master`, una fetch scaricherà tutte queste nuove commit, rendendo la cronologia delle commit come quella della Figura 5.14.
 
 Insert 18333fig0514.png
 Figura 5.14. La cronologia di Jessica dopo aver unito entrambi i rami.
 
-Molti gruppi migrano verso Git per la sua capacità di avere più team a lavorarare in parallelo, unendo le differenti linee di lavoro alla fine del processo. L'abilità di piccoli sotto gruppi di una squadra di collaborare tramite rami remoti senza necessariamente dover coinvolgere o ostacolare l'intero team è un grande beneficio di Git. La sequenza per il workflow che hai appena visto è rappresentata dalla Figura 5-15.
+Molti gruppi migrano a Git per la sua capacità di avere gruppi che lavorino in parallelo, unendo le differenti righe di lavoro alla fine del processo. La possibilità che piccoli sottogruppi del team possano collaborare con branch remoti senza dover necessariamente coinvolgere o ostacolare l'intero team è un grande beneficio di Git. La sequenza del workflow che hai appena visto è rappresentata nella Figura 5-15.
 
 Insert 18333fig0515.png
 Figura 5-15. Sequenza base di questo workflow con team separati.

From 6ca9042c139e16af7422bb24d5eb5373d69b6378 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Sun, 2 Feb 2014 23:10:47 -0600
Subject: [PATCH 158/690] Reviewing "Public Small Project"

---
 it/05-distributed-git/01-chapter5.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/it/05-distributed-git/01-chapter5.markdown b/it/05-distributed-git/01-chapter5.markdown
index 5775605be..a21356ba6 100755
--- a/it/05-distributed-git/01-chapter5.markdown
+++ b/it/05-distributed-git/01-chapter5.markdown
@@ -383,7 +383,7 @@ Figura 5-15. Sequenza base di questo workflow con team separati.
 
 ### Piccolo progetto pubblico ###
 
-Contribuire ad un progetto pubblico è leggermente differente. Dato che non hai il permesso di aggiornare direttamente i rami del progetto, devi far avere il tuo lavoro ai mantenitori in qualche altro modo. Questo esempio descrive la contribuzione via fork su host Git che lo supportano in maniera semplice. I siti repo.or.cz e GitHub lo supportano, e molti altri mantenitori di progetti si aspettano questo tipo di contribuzione. La prossima sezione si occupa di progetti che preferiscono accettare patch via e-mail
+Contribuire ad un progetto pubblico è leggermente differente. Poiché non hai il permesso di aggiornare direttamente i rami del progetto, devi far avere il tuo lavoro ai mantenitori in qualche altro modo. Questo primo esempio descrive come contribuire con i fork su host Git che lo supportano in maniera semplice. I siti di repo.or.cz e GitHub lo supportano, e molti mantenitori di progetti si aspettano questo tipo di contribuzione. La sezione successiva tratta i progetti che preferiscono ricevere le patch per e-mail
 
 Innanzitutto, probabilemnte dovrai clonare il repository principale, creare un ramo per le modifiche che hai in programma di fare, e fare li il tuo lavoro. La sequenza è grosso modo questa:
 

From f26f3cc0297ee4939da9fcdc3b62ac0891e3febb Mon Sep 17 00:00:00 2001
From: harupong <harupong@gmail.com>
Date: Mon, 3 Feb 2014 14:39:17 +0900
Subject: [PATCH 159/690] [ja] Apply #573 (bdef6f7) to ja tree

---
 ja/03-git-branching/01-chapter3.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ja/03-git-branching/01-chapter3.markdown b/ja/03-git-branching/01-chapter3.markdown
index 1690e53b3..e674e1d5f 100644
--- a/ja/03-git-branching/01-chapter3.markdown
+++ b/ja/03-git-branching/01-chapter3.markdown
@@ -458,7 +458,7 @@ Insert 18333fig0326.png
 	Branch sf set up to track remote branch refs/remotes/origin/serverfix.
 	Switched to a new branch "sf"
 
-これで、ローカルブランチ sf が自動的に `origin/serverfix` を追跡するようになりました。
+これで、ローカルブランチ `sf` が自動的に `origin/serverfix` を追跡するようになりました。
 
 ### リモートブランチの削除 ###
 

From 617eb401bf743add90c82f392e2ba655b4b6a3ba Mon Sep 17 00:00:00 2001
From: Cor <git@cpt1.demon.nl>
Date: Mon, 3 Feb 2014 10:36:54 +0100
Subject: [PATCH 160/690] [nl] Retranslate, remove Babelfishes and use
 diacritical characters.

---
 nl/07-customizing-git/01-chapter7.markdown | 419 ++++++++++++---------
 1 file changed, 241 insertions(+), 178 deletions(-)

diff --git a/nl/07-customizing-git/01-chapter7.markdown b/nl/07-customizing-git/01-chapter7.markdown
index 0d7a9c7a4..22fbee5e2 100644
--- a/nl/07-customizing-git/01-chapter7.markdown
+++ b/nl/07-customizing-git/01-chapter7.markdown
@@ -1,25 +1,25 @@
 # Git op maat maken #
 
-Tot zover heb ik de fundamentele werking van Git behandeld, en hoe het te gebruiken, en ik heb een aantal tools geïntroduceerd die Git levert om je het makkelijk en efficiënt te laten gebruiken. In dit hoofdstuk zal ik wat operaties doorlopen die je kunt gebruiken om Git op een persoonlijker manier te laten werken door een aantal belangrijke configuratie-instellingen te introduceren en het hakensysteem. Met deze gereedschappen is het makkelijk om Git precies te laten werken op de manier zoals jij, je bedrijf, of je groep het graag wil.
+Tot zover heb ik de fundamentele werking van Git behandeld en hoe het te gebruiken, en ik heb een aantal tools geïntroduceerd die Git levert om je het makkelijk en efficiënt te laten gebruiken. In dit hoofdstuk zal ik wat operaties doorlopen die je kunt gebruiken om Git op een maat gemaakte manier te laten werken door een aantal belangrijke configuratie-instellingen te introduceren en het inhaak-systeem (hooks). Met deze gereedschappen is het makkelijk om Git precies te laten werken op de manier zoals jij, je bedrijf, of je groep het nodig hebben.
 
 ## Git configuratie ##
 
-Zoals je kort in Hoofdstuk 1 gezien hebt, kun je Git configuratie instellingen specificeren met het `git config` commando. Een van de eerste dingen die je deed wat je naam en e-mail adres instellen:
+Zoals je kort in Hoofdstuk 1 gezien hebt, kun je Git configuratie instellingen specificeren met het `git config` commando. Een van de eerste dingen die je deed was je naam en e-mail adres instellen:
 
 	$ git config --global user.name "John Doe"
 	$ git config --global user.email johndoe@example.com
 
-Nu zul je een paar van de meer interessante opties leren, die je op deze manier kunt instellen om je Git op maat te maken.
+Hierna zal je een paar van de meer interessante opties leren, die je op vergelijkbare manier kunt instellen om je Git op maat te maken.
 
-Je zag wat eenvoudige Git configuratie details in het eerste hoofdstuk, maar ik zal ze hier nog eens snel laten zien. Git gebruikt een aantal configuratie bestanden om het niet-standaard gedrag dat je wil te bepalen. De eerste plaats waar Git kijkt voor deze waarden is in een `/etc/gitconfig` bestand, wat de waarden bevat voor alle gebruikers op het systeem en al hun repositories. Als je de optie `--system` aan `git config` meegeeft, leest en schrijft het specifiek naar dit bestand.
+Je zag al wat eenvoudige Git configuratie details in het eerste hoofdstuk, en die zal ik hier snel nog eens laten zien. Git gebruikt een aantal configuratie bestanden om het niet-standaard gedrag dat je wilt te bepalen. De eerste plek waar Git kijkt voor deze waarden is in een `/etc/gitconfig` bestand, deze bevat de waarden voor alle gebruikers op het systeem en al hun repositories. Als je de optie `--system` aan `git config` meegeeft, leest en schrijft Git naar dit bestand.
 
-De volgende plaats waar Git kijkt is het `~/.gitconfig` bestand, wat specifiek is voor iedere gebruiker. Je kunt er voor zorgen dat Git naar dit bestand leest en schrijft door de `--global` optie mee te geven.
+De volgende plaats waar Git kijkt is het `~/.gitconfig` bestand, wat specifiek is voor elke gebruiker. Je kunt er voor zorgen dat Git naar dit bestand leest en schrijft door de `--global` optie mee te geven.
 
-Als laatste kijkt Git naar configuratie waarden in het config bestand in de Git map (`.git/config`) of welk repository dat je op dat moment gebruikt. Deze waarden zijn specifiek voor dat ene repository. Ieder niveau overschrijft de waarden in het vorige niveau, dus waarden in `.git/config` gaan boven die in `/etc/gitconfig`, bijvoorbeeld. Je kunt die waarden ook instellen door het bestand handmatig aan te passen en de correcte syntax in te voegen, maar het is over het algemeen makkelijk m het `git config` commando uit te voeren.
+Als laatste kijkt Git naar configuratie waarden in het config bestand in de Git directory (`.git/config`) van de repository dat op dat moment gebruikt wordt. Deze waarden zijn specifiek voor die ene repository. Ieder niveau overschrijft de waarden in het vorig, dus waarden in `.git/config` gaan voor op die in `/etc/gitconfig` bijvoorbeeld. Je kunt die waarden ook instellen door het bestand handmatig aan te passen en de correcte syntax te gebruiken, maar het is gewoon eenvoudiger het `git config` commando uit te voeren.
 
 ### Basis client configuratie ###
 
-De configuratie opties die herkent worden door Git vallen binnen twee categorieën: de client kant en de server kant. De meerderheid van de opties zijn voor de client kant – de configuratie van je persoonlijke voorkeuren. Alhoewel er massa's opties beschikbaar zijn, zal ik alleen een paar behandelen die ofwel veelgebruikt zijn of je werkwijze significant kunnen beïnvloeden. Veel opties zijn alleen bruikbaar in randgevallen waar ik hier niet naar kijk. Als je een lijst van alle opties wil zien, die jou versie van Git herkent kun je dit uitvoeren
+De configuratie opties die herkend worden door Git vallen in twee categorieën: de cliënt kant en de server kant. De meerderheid van de opties zijn voor de cliënt kant: de configuratie van je persoonlijke voorkeuren. Alhoewel er massa's opties beschikbaar zijn, zal ik er maar een paar behandelen die ofwel veelgebruikt zijn ofwel je werkwijze significant kunnen beïnvloeden. Veel opties zijn alleen van toepassing in randgevallen, die ik nu niet zal behandelen. Als je een lijst van alle opties wilt zien, die door jouw versie van Git worden herkend kan je dit uitvoeren
 
 	$ git config --help
 
@@ -27,15 +27,15 @@ De gebruikershandleiding voor `git config` toont alle beschikbare opties in groo
 
 #### core.editor ####
 
-Standaard zal Git de standaard tekst editor gebruiken, die je hebt ingesteld of anders terugvallen op de Vi editor om je commit en tag boodschappen te maken of te wijzigen. Om die instelling naar iets anders om te zetten, kun je de `core.editor` instelling gebruiken:
+Standaard zal Git de tekst editor gebruiken die je zelf ingesteld als standaard en anders valt Git terug op de Vi editor om je commit en tag boodschappen te maken of te wijzigen. Om die instelling naar iets anders om te zetten, kun je de `core.editor` instelling gebruiken:
 
 	$ git config --global core.editor emacs
 
-Zonder dat het uitmaakt wat je als je standaard shell editor waarde ingesteld hebt, zal Git Emacs starten om boodschappen aan te passen.
+Nu maakt het niet uit wat je als je standaard shell editor waarde ingesteld hebt, en zal Git Emacs starten om boodschappen aan te passen.
 
 #### commit.template ####
 
-Als je dit als een pad instelt dat naar een bestand op je systeem wijst, zal Git dat bestand als de standaard boodschap gebruiken als je commit. Bijvoorbeeld, stel dat je een sjabloon bestand aanmaakt als `$HOME/.gitmessage.txt` die er zo uitziet:
+Als je hier het een pad instelt dat naar een bestand op je systeem wijst, zal Git dat bestand als de standaard boodschap gebruiken bij elke commit. Bijvoorbeeld, stel dat je een sjabloon bestand aanmaakt als `$HOME/.gitmessage.txt` die er zo uitziet:
 
 	onderwerp regel
 
@@ -43,12 +43,12 @@ Als je dit als een pad instelt dat naar een bestand op je systeem wijst, zal Git
 
 	[ticket: X]
 
-Om Git te vertellen dat het dit moet gebruiken als standaard boodschap dat in je editor moet verschijnen als je `git commit` uitvoert, stel je de `commit.template` configuratie waarde in:
+Om Git te vertellen dat het dit moet gebruiken als standaard boodschap dat in de editor moet verschijnen als je `git commit` uitvoert, stel je de `commit.template` configuratie waarde in:
 
 	$ git config --global commit.template $HOME/.gitmessage.txt
 	$ git commit
 
-Daarna zal je editor zoiets als dit openen als je standaard commit boodschap als je commit:
+Daarna zal je editor zoiets als dit openen als je standaard commit boodschap bij een commit:
 
 	onderwerp regel
 
@@ -67,29 +67,29 @@ Daarna zal je editor zoiets als dit openen als je standaard commit boodschap als
 	~
 	".git/COMMIT_EDITMSG" 14L, 297C
 
-Als je een beleid hebt voor commit boodschappen, dan vergroot het plaatsen van een sjabloon voor dat beleid op je systeem en het configureren ervan voor Git om het als standaard te gebruiken de kans dat dat beleid met regelmaat gevolgd wordt.
+Als je een beleid hebt voor commit boodschappen, dan vergroot het plaatsen van een sjabloon op je systeem en het configureren ervan als standaard te gebruiken binnen Git de kans dat het beleid ook daadwerkelijk wordt gevolgd.
 
 #### core.pager ####
 
-De instelling voor 'core.pager' bepaald welke pagineer applicatie gebruikt wordt door Git om de uitvoer van `log` en `diff` weer te geven. Je kunt het instellen als `more` of als je favoriete pagineerder (standaard is het `less`), of je kunt het uit zetten door het als een lege tekst in te stellen:
+De instelling voor 'core.pager' bepaalt welke pagineer tool gebruikt wordt door Git om de uitvoer van bijvoorbeeld `log` en `diff` weer te geven. Je kunt het instellen als `more` of als je favoriete pagineer tool (standaard is het `less`), of je kunt het uitzetten door het als een lege tekst in te stellen:
 
 	$ git config --global core.pager ''
 
-Als je dat uitvoert, zal Git de gehele uitvoer van alle commando's pagineren, hoe lang het ook is.
+Als je dat uitvoert zal Git de gehele tekst van alle commando's ononderbroken tonen, ongeacht de lengte van die uitvoer.
 
 #### user.signingkey ####
 
-Als je gebruik maakt van ondertekende tags (zoals besproken in Hoofdstuk 2), dan maakt het instellen van je GPG signeer sleutel als configuratie instelling het leven eenvoudiger. Stel je sleutel ID zo in:
+Als je gebruik maakt van ondertekende tags (zoals besproken in Hoofdstuk 2), dan maakt het instellen van een GPG signeersleutel als configuratie instelling je leven een stuk eenvoudiger. Stel je sleutel ID zo in:
 
 	$ git config --global user.signingkey <gpg-key-id>
 
-Nu kun je je tags signeren zonder steeds je sleutel op te hoeven geven bij het `git tag` commando:
+Nu kun je tags signeren zonder steeds je sleutel op te hoeven geven bij het `git tag` commando:
 
 	$ git tag -s <tag-name>
 
 #### core.excludesfile ####
 
-Je kunt patronen in het `.gitignore` bestand van je project zetten zodat Git ze niet ziet als ongevolgde bestanden of ze niet zal proberen te stagen als je `git add` op ze uitvoert, zoals besproken in Hoofdstuk 2. Maar als je wilt dat een ander bestand buiten je project die waarden of extra waarden bevat, kun je Git vertellen met de `core.excludesfile` vertellen waar dat bestand is. Stel het eenvoudigweg in als een pad naar een bestand dat een inhoud heeft dat vergelijkbaar is met wat een `.gitignore` bestand zou hebben.
+Je kunt patronen in het `.gitignore` bestand van je project zetten zodat Git ze niet ziet als untracked bestanden en niet zal proberen ze te stagen als je `git add` op ze uitvoert, zoals besproken in Hoofdstuk 2. Maar als je wilt dat een ander bestand buiten je project die waarden of additionele waarden bevat, kan je Git vertellen met de `core.excludesfile` waarde waar dat bestand is. Stel het eenvoudigweg in als een pad naar een bestand met een inhoud dat vergelijkbaar is met wat een `.gitignore` bestand zou hebben.
 
 #### help.autocorrect ####
 
@@ -105,67 +105,67 @@ Als je `het.autocorrect` op 1 instelt, zal Git automatisch het commando uitvoere
 
 ### Kleuren in Git ###
 
-Git kan zijn uitvoer in je terminal kleuren, wat je kan helpen om de uitvoer snel en eenvoudig visueel te begrijpen. Een aantal opties kan je helpen om de kleuren naar je voorkeur in te stellen.
+Git kan zijn uitvoer op de terminal in kleur tonen, wat kan helpen om de uitvoer snel en eenvoudig visueel te interpreteren. Een aantal opties kan helpen om de kleuren naar jouw voorkeur in te stellen.
 
 #### color.ui ####
 
-Git zal automatisch het meeste van zijn uitvoer kleuren als je het vraagt. Je kunt erg specifiek zijn in wat je gekleurd wil en hoe; maar om alle standaard kleuren in de terminal aan te zetten, stel dan `color.ui` in op true:
+Git zal automatisch het meeste van zijn uitvoer in kleur tonen als je het vraagt. Je kunt erg specifiek zijn in wat je gekleurd wilt hebben en hoe. Maar om alle standaard kleuren in de terminal aan te zetten, stel dan `color.ui` in op true:
 
 	$ git config --global color.ui true
 
-Als deze waarde ingesteld is, zal Git zijn uitvoer kleuren zodra deze naar een terminal gaat. Andere mogelijke opties zijn false, wat de uitvoer nooit kleurt, en always, wat de kleuren altijd weergeeft, zelfs als je Git commando's omleidt naar een bestand of naar een ander commando doorsluist. Deze instelling is toegevoegd in Git 1.5; als je een oudere versie hebt, zul je alle kleuren instellingen individueel in moeten stellen.
+Als deze waarde ingesteld is, zal Git zijn uitvoer in kleur tonen zodra deze naar een terminal gaat. Andere mogelijke opties zijn false wat de uitvoer nooit kleurt, en always, wat de kleuren altijd weergeeft zelfs als je Git commando's uitvoert naar een bestand of deze naar een ander commando doorsluist (piping).
 
-Je zult zelden `color.ui = always` willen. In de meeste scenario's, als je kleuren in je omgeleide uitvoer wil, kun je een `--color` vlag aan het Git commando meegeven om het te forceren kleuren te gebruiken. De `color.ui = true` instelling is vrijwel altijd hetgene je wil gebruiken.
+Je zult zelden `color.ui = always` willen. In de meeste scenario's, als je kleuren in je omgeleide uitvoer wil, kan je een `--color` vlag aan het Git commando meegeven om het te forceren kleuren te gebruiken. De `color.ui = true` instelling is degene die je vrijwel altijd wilt gebruiken.
 
 #### `color.*` ####
 
-Als je meer specifiek wil zijn welke commando's gekleurd moeten zijn en hoe, of je hebt een oudere versie, dan voorziet Git in woord specifieke kleuren instellingen. Ieder van deze kan worden ingesteld op `true`, `false` of `always`:
+Als je meer specifiek wil zijn welke commando's gekleurd moeten zijn en hoe, dan voorziet Git in woordspecifieke kleuren instellingen. Elk van deze kan worden ingesteld op `true`, `false` of `always`:
 
 	color.branch
 	color.diff
 	color.interactive
 	color.status
 
-Daarnaast heeft ieder van deze ook sub-instellingen die je kunt gebruiken om specifieke kleuren in te stellen voor delen van de uitvoer, als je iedere kleur wilt overschrijven. Bijvoorbeeld, om de meta informatie in je diff uitvoer in blauwe voorgrond, zwarte achtergrond en vetgedrukt in te stellen, kun je dit uitvoeren
+Daarnaast heeft elk van deze ook sub-instellingen die je kunt gebruiken om specifieke kleuren in te stellen voor delen van de uitvoer, als je iedere kleur wilt overschrijven. Bijvoorbeeld, om de meta-informatie in je diff uitvoer in blauwe voorgrond, zwarte achtergrond en vetgedrukt in te stellen, kun je dit uitvoeren
 
 	$ git config --global color.diff.meta “blue black bold”
 
-Je kunt de kleur instellen op ieder van de volgende waarden: normal, black, red, green, yellow, blue, magenta, cyan, of white. Als je een attribuut wil hebben, zoals vetgedrukt in het vorige voorbeeld, kun je kiezen uit bold, dim, ul, blink en reverse.
+Je kunt de kleur instellen op een van de volgende waarden: ’normal’, ’black’, ’red’, ’green’, ’yellow’, ’blue’, ’magenta’, ’cyan’, of ’white’. Als je een attribuut wil hebben, zoals vetgedrukt in het vorige voorbeeld, kun je kiezen uit ’bold’, ’dim’, ’ul’, ’blink’ en ’reverse’.
 
-Zie de manpage van `git config` voor alle sub-instellingen die je kunt instellen, als je dat wil.
+Zie de manpage van `git config` voor alle sub-instellingen die je kunt instellen, als je dat wilt.
 
 ### Externe merge en diff tools ###
 
-Alhoewel Git een interne implementatie van diff heeft, die je tot nog toe gebruikte, kun je in plaats daarvan een extern tool instellen. Je kunt ook een grafisch samenvoeg conflict-oplossings tool instellen, in plaats van handmatig de conflicten op te moeten lossen. Ik zal nu demonstreren hoe je het Perforce Visuele Samenvoeg Tool (P4Merge) in moet stellen, om je diff en samenvoeg oplossingen te doen, omdat het een fijn grafisch tool is en omdat het gratis is.
+Alhoewel Git een interne implementatie van diff heeft, die heb je tot nu toe gebruikt, kan je in plaats daarvan een extern tool instellen. Je kunt ook een grafisch merge conflict-oplossings tool instellen, in plaats van handmatig de conflicten op te moeten lossen. Ik zal nu demonstreren hoe je het Perforce Visuele Merge Tool (P4Merge) in moet stellen, om je diff en merge oplossingen te doen, omdat het een fijn grafisch tool is en omdat het gratis is.
 
-P4Merge werkt op alle grote platformen als je dit wil proberen, dus je zou het moeten kunnen doen. Ik zal in de voorbeelden paden gebruiken die op Mac en Linux systemen werken; voor Windows moet je `/usr/local/bin` veranderen in een pad naar een uitvoerbaar bestand in je omgeving.
+P4Merge werkt op alle grote platformen als je dit wil proberen, dus je zou het moeten kunnen doen. Ik zal in de voorbeelden paden gebruiken die op Mac en Linux systemen werken; voor Windows moet je `/usr/local/bin` veranderen in een pad naar een uitvoerbaar bestand op jouw machine.
 
 Je kunt P4Merge hier downloaden:
 
 	http://www.perforce.com/perforce/downloads/component.html
 
-Om te beginnen zul je externe wrapper scripts instellen om je commando's uit te voeren. Ik zal het Mac pad gebruiken voor de applicatie; in andere systemen zal het moeten wijzen naar waar de `p4merge` binary geïnstalleerd is. Stel een samenvoeg wrapper script in, genaamd `extMerge`, die je applicatie met alle meegegeven argumenten aanroept:
+Om te beginnen ga je externe wrapper scripts instellen om de commando's uit te voeren. Ik zal het Mac pad gebruiken voor de applicatie; in andere systemen zal het moeten wijzen naar waar de `p4merge` binary geïnstalleerd is. Stel een merge wrapper script in, genaamd `extMerge`, die jouw applicatie met alle meegegeven argumenten aanroept:
 
 	$ cat /usr/local/bin/extMerge
 	#!/bin/sh
 	/Applications/p4merge.app/Contents/MacOS/p4merge $*
 
-De diff wrapper controleert dat er zeker zeven argumenten meegegeven zijn, en geeft twee ervan aan je samenvoeg script. Standaard geeft Git de volgende argumenten aan het diff programma mee:
+De diff wrapper controleert dat er precies zeven argumenten meegegeven zijn, en geeft twee ervan aan het merge script. Standaard geeft Git de volgende argumenten aan het diff programma mee:
 
-	path old-file old-hex old-mode new-file new-hex new-mode
+	pad oud-bestand oude-hex oude-modus nieuwe-bestand nieuwe-hex nieuwe-modus
 
-Omdat je alleen de `oude-bestand` en `nieuwe-bestand` argumenten wil, zul je het wrapper script gebruiken om degenen door te geven die je wil.
+Omdat je alleen de `oude-bestand` en `nieuwe-bestand` argumenten wilt, zul je het wrapper script gebruiken om de juiste parameters door te geven.
 
 	$ cat /usr/local/bin/extDiff
 	#!/bin/sh
 	[ $# -eq 7 ] && /usr/local/bin/extMerge "$2" "$5"
 
-Je moet er ook zeker van zijn dat deze tools uitvoerbaar zijn:
+Je moet er ook zeker van zijn dat deze scripts uitvoerbaar zijn:
 
 	$ sudo chmod +x /usr/local/bin/extMerge
 	$ sudo chmod +x /usr/local/bin/extDiff
 
-Nu kun je je config bestand instellen dat het je eigengemaakte samenvoeg en diff tools gebruikt. Dit wordt gedaan met een aantal eigen instellingen: `merge.tool` om Git te vertellen welke strategie hij moet gebruiken, `mergetool.*.cmd` om te specificeren hoe het het commando moet uitvoeren, `mergetool.trustExitCode` om Git te vertellen of de exit code van dat programma een succesvolle samenvoeging betekent of niet, en `diff.external` om Git te vertellen welk commando het moet uitvoeren voor diffs. Dus, je kunt of vier configuratie commando's uitvoeren
+Nu kun je het config bestand instellen om de zelfgemaakte merge en diff tools te gebruiken. Dit wordt gedaan met een aantal instellingen: `merge.tool` om Git te vertellen welke strategie hij moet gebruiken, `mergetool.*.cmd` om te specificeren hoe het commando moet worden uitgevoerd, `mergetool.trustExitCode` om Git te vertellen of de exit code van dat programma een succesvolle merge betekent of niet, en `diff.external` om Git te vertellen welk commando het moet uitvoeren voor diffs. Dus, je kunt de vier configuratie commando's uitvoeren
 
 	$ git config --global merge.tool extMerge
 	$ git config --global mergetool.extMerge.cmd \
@@ -183,26 +183,26 @@ of je kunt je `~/.gitconfig` bestand aanpassen en deze regels toevoegen:
 	[diff]
 	  external = extDiff
 
-Nadat dit alles ingesteld is, zul je als je diff commando's zoals deze uitvoert:
+Nadat dit alles ingesteld is, kan je diff commando's zoals deze uitvoeren:
 
 	$ git diff 32d1776b1^ 32d1776b1
 
-in plaat van de uitvoer van diff op de commando regel, een instantie van P4Merge gestart door Git krijgen, wat er uitziet zoals in Figuur 7-1.
+in plaats van de uitvoer van diff op de commando regel, wordt een instantie van P4Merge gestart door Git, en dat ziet er ongeveer uit als in Figuur 7-1.
 
 Insert 18333fig0701.png
 Figuur 7-1. P4Merge.
 
-Als je twee branches probeert samen te voegen en je krijgt conflicten, dan kun je het `git mergetool` commando uitvoeren; het start P4Merge op om je het conflict op te laten lossen met behulp van dat GUI tool.
+Als je twee branches probeert te mergen en je krijgt vervolgens merge conflicten, kan je het `git mergetool` commando uitvoeren. P4Merge wordt dan opgestart om je het conflict op te laten lossen met behulp van dat GUI tool.
 
-Het aardige van deze wrapper opstelling is dat je je diff en merge tools eenvoudig aan kunt passen. Bijvoorbeeld, om je `extDiff` en `extMerge` tools in te stellen dat ze in plaats daarvan het KDiff3 tool uitvoeren, is het enige dat je moet doen je `extMerge` bestand aanpassen:
+Het aardige van deze wrapper opstelling is dat je de diff en merge tools eenvoudig aan kunt passen. Bijvoorbeeld, om je `extDiff` en `extMerge` tools in te stellen dat ze bijvoorbeeld het KDiff3 tool uitvoeren, is het enige dat je moet doen het `extMerge` bestand aanpassen:
 
 	$ cat /usr/local/bin/extMerge
 	#!/bin/sh
 	/Applications/kdiff3.app/Contents/MacOS/kdiff3 $*
 
-Nu zal Git het KDiff3 tool gebruiken voor het tonen van diff en het oplossen van samenvoeg conflicten.
+Nu zal Git het KDiff3 tool gebruiken voor het tonen van diff en het oplossen van merge conflicten.
 
-Git is al ingesteld om een aantal andere conflict-oplossings tools te gebruiken zonder dat je de cmd configuratie in hoeft te stellen. Je kunt je merge tool op kdiff3 instellen, of opendiff, tkdiff, meld, xxdiff, emerge, vimdiff of gvimdiff. Als je niet geïnteresseerd bent in het gebruik van KDiff3 als diff, maar het liever alleen wilt gebruiken voor conflict oplossing, en het kdiff3 commando zit in je pad, dan kun je dit uitvoeren
+Git is al ingesteld om een aantal andere mergeconflict-oplossings tools te gebruiken zonder dat je de cmd configuratie op hoeft te zetten. Je kunt je merge tool op kdiff3 instellen, opendiff, tkdiff, meld, xxdiff, emerge, vimdiff of gvimdiff. Als je niet geïnteresseerd bent in het gebruik van KDiff3 als diff, maar het liever alleen wilt gebruiken voor conflict oplossing en het kdiff3 commando zit in je pad, dan kun je dit uitvoeren
 
 	$ git config --global merge.tool kdiff3
 
@@ -210,40 +210,40 @@ Als je dit uitvoert in plaats van de `extMerge` en `extDiff` bestanden in te ste
 
 ### Opmaak en witruimten ###
 
-Problemen met opmaak en witruimten zijn één van de veelvoorkomende frustrerende en subtiele problemen die veel ontwikkelaars tegenkomen bij het samenwerken, in het bijzonder over verschillende platformen. Het is heel eenvoudig voor patches en ander werk om subtiele witruimte veranderingen te introduceren, omdat editors ze stil introduceren of omdat Windows programmeurs harde returns aan het eind van de regels toevoegen die ze aanraken in gekruiste platformprojecten. Git heeft een aantal configuratie opties om met deze problemen te helpen.
+Problemen met opmaak en witruimten zijn één van de veelvoorkomende frustrerende en subtiele problemen die veel ontwikkelaars tegenkomen bij het samenwerken, in het bijzonder over verschillende platformen. Het is heel eenvoudig voor patches en ander werk om subtiele witruimte veranderingen te introduceren, omdat editors ze stiekum introduceren of omdat Windows programmeurs carriage returns aan het eind van de regels toevoegen van bestanden die ze bewerken in gemengde platformprojecten. Git heeft een aantal configuratie opties om met deze problemen te helpen.
 
 #### core.autocrlf ####
 
-Als je op Windows programmeert, of een ander systeem gebruikt maar samenwerkt met mensen die op Windows werken, zul je vroeg of laat waarschijnlijk tegen regeleinde problemen aanlopen. Dat komt omdat Windows zowel een harde return als ook een linefeed karakter gebruikt voor regeleindes in zijn bestanden, waar Mac en Linux systemen alleen het linefeed karakter gebruiken. Dit is een subtiel maar verschrikkelijk irritant feit van het werken met gekruiste platformen.
+Als je op Windows programmeert, of een ander systeem gebruikt maar samenwerkt met mensen die op Windows werken, zal je op enig moment tegen regeleinde problemen aanlopen. Dat komt omdat Windows zowel een carriage-return als een linefeed karakter gebruikt voor regeleindes in zijn bestanden, terwijl Mac en Linux systemen alleen het linefeed karakter gebruiken. Dit is een subtiel maar verschrikkelijk irritant feit van het werken met gemengde platformen.
 
-Git kan hiermee omgaan door CRLF regeleinden automatisch om te zetten naar LF zodra je commit, en vice versa op het moment dat je code uitchecked op je systeem. Je kunt deze functionaliteit aanzetten met de `core.autocrlf` instelling. Als je op een Windows machine zit, stel het dan in op `true` – dit veranderd LF regeleinden in CRLF zodra je code uitchecked:
+Git kan hiermee omgaan door CRLF regeleinden automatisch om te zetten naar LF zodra je commit, en vice versa op het moment dat je code uitchecked op je systeem. Je kunt deze functionaliteit aanzetten met de `core.autocrlf` instelling. Als je op een Windows machine zit, stel het dan in op `true` – dit verandert LF regeleinden in CRLF zodra je code uitchecked:
 
 	$ git config --global core.autocrlf true
 
-Als je op een Linux of Mac systeem zit dat LF regeleinden gebruikt, dan wil je niet dat Git ze automatisch veranderd op het moment dat Git bestanden uitchecked; maar als een bestand met CRLF regeleinden onverhoopt toch geïntroduceerd wordt, dan wil je misschien dat Git dit repareert. Je kunt Git vertellen dat je wilt dat hij CRLF in LF veranderd tijdens het committen, maar niet de andere kant op door het instellen van `core.autocrlf` op input:
+Als je op een Linux of Mac systeem werkt (dat LF regeleinden gebruikt) dan wil je niet dat Git ze automatisch verandert op het moment dat Git bestanden uitchecked. Maar als een bestand met CRLF regeleinden onverhoopt toch geïntroduceerd wordt, dan wil je waarschijnlijk dat Git dit repareert. Je kunt Git vertellen dat je wilt dat hij CRLF in LF veranderd tijdens het committen, maar niet de andere kant op door het instellen van `core.autocrlf` op input:
 
 	$ git config --global core.autocrlf input
 
-Deze instelling zal CRLF regeleinden in Windows checkouts gebruiken, en LF einden in Mac en Linux systemen en in het repository moeten laten.
+Deze instelling zal CRLF regeleinden in Windows checkouts gebruiken, en LF regeleinden in Mac en Linux systemen en in de repository.
 
-Als je een Windows programmeur bent, die een alleen-Windows project doet, dan kun je deze functionaliteit uitzetten, waarmee de harde returns in het repository opgeslagen worden door de configuratie waarde op `false` te zetten:
+Als je een Windows programmeur bent die aan een project voor alleen Windows werkt dan kun je deze functionaliteit uitzetten, waardoor de carriage-returns in de repository worden opgeslagen door de configuratie waarde op `false` te zetten:
 
 	$ git config --global core.autocrlf false
 
 #### core.whitespace ####
 
-Git is vooraf ingesteld om een aantal witruimte problemen te detecteren en te repareren. Het kan op vier veelvoorkomende witruimte problemen letten – twee staan er standaard aan en kunnen uitgezet worden, en twee staan er standaard niet aan, maar kunnen aangezet worden.
+Git is standaard ingesteld om een aantal witruimte problemen te detecteren en te repareren. Het kan op vier veelvoorkomende witruimte problemen letten – twee staan er standaard aan en kunnen uitgezet worden, en twee staan standaard uit, maar kunnen aangezet worden.
 
-De twee die standaard aan staan zijn `trailing-space`, wat kijkt of er spaties aan het eind van een regel staan, en `space-before-tab`, wat kijkt of er spaties voor tabs staan aan het begin van een regel.
+De twee die standaard aan staan zijn `trailing-space`, waarmee wordt gekeken of er spaties aan het eind van een regel staan, en `space-before-tab`, wat kijkt of er spaties voor tabs staan aan het begin van een regel.
 
-De twee die standaard uit staan, maar aangezet kunnen worden, zijn `indent-with-non-tab`, wat kijkt naar regels die met acht of meer spaties beginnen in plaats van tabs, en `cr-at-eol`, wat Git verteld dat harde returns aan het eind van een regel OK zijn.
+De twee die standaard uit staan maar aangezet kunnen worden, zijn `indent-with-non-tab` die kijkt naar regels die met acht of meer spaties beginnen in plaats van tabs, en `cr-at-eol`, wat Git vertelt dat carriage-returns aan het eind van een regel geaccepteerd mogen worden.
 
-Je kunt Git vertellen welke van deze je aan wil zetten door `core.whitespace` naar de waardes in te stellen die je aan of uit wil, gescheiden door komma's. Je kunt waarden uitzetten door ze weg te laten uit de instelling tekst of door een `-` vooraf te laten gaan aan de waarde. Bijvoorbeeld, als je alles aan wil behalve `cr-ar-eol`, dan kun je dit doen:
+Je kunt Git vertellen welke van deze je aan wilt zetten door `core.whitespace` de waardes te geven die je aan of uit wilt zetten, gescheiden door komma's. Je kunt waarden uitzetten door ze weg te laten uit de instelling tekst of door een `-` vooraf te laten gaan aan de waarde. Bijvoorbeeld, als je alles aan wil behalve `cr-ar-eol`, dan kan je dit doen:
 
 	$ git config --global core.whitespace \
 	    trailing-space,space-before-tab,indent-with-non-tab
 
-Git zal deze problemen detecteren zodra je een `git diff` commando uitvoert en ze proberen te kleuren zodat je ze kunt repareren alvorens te committen. Het zal deze waarden ook gebruiken om je te helpen met patches toe te passen met `git apply`. Als je patches gaat toepassen, kun je Git vragen om je te waarschuwen als hij patches toepast waarin deze specifieke witruimte problemen zitten:
+Git zal deze problemen detecteren zodra je een `git diff` commando uitvoert en ze proberen in te kleuren zodat je ze kunt repareren voordat je ze commit. Het zal deze waarden ook gebruiken om je te helpen met patches toe te passen met `git apply`. Als je patches gaat toepassen, kan je Git vragen om je te waarschuwen als hij patches toepast waarin deze specifieke witruimte-problemen zitten:
 
 	$ git apply --whitespace=warn <patch>
 
@@ -251,104 +251,168 @@ Of je kunt Git vragen om automatisch deze problemen te repareren alvorens de pat
 
 	$ git apply --whitespace=fix <patch>
 
-Deze opties zijn ook op de git rebase optie van toepassing. Als je witruimte problemen gecommit hebt maar ze nog niet stroomopwaarts gepusht hebt, kun je een `rebase` uitvoeren met de `--whitespace=fix` optie uitvoeren om Git automatisch witruimte problemen te laten repareren zodra het de patches herschrijft.
+Deze opties zijn ook op het `git rebase` commando van toepassing. Als je witruimte problemen gecommit hebt maar ze nog niet stroomopwaarts gepushed hebt, kun je een `rebase` uitvoeren met de `--whitespace=fix` optie om Git automatisch witruimte problemen te laten repareren zodra het de patches herschrijft.
 
 ### Server configuratie ###
 
-Er zijn lang niet zoveel configuratie opties beschikbaar voor de server kant van Git, maar er zijn er een paar interessante bij waar je misschien notie van wil hebben.
+Er zijn lang niet zoveel configuratie opties beschikbaar voor de server kant van Git, maar er zijn er een paar interessante bij waar je misschien op gewezen wilt worden.
 
 #### receive.fsckObjects ####
 
-Standaard zal Git niet alle objecten die hij ontvangt gedurende een push op consistentie controleren. Alhoewel Git kan controleren of ieder object nog steeds bij zijn SHA-1 checksum past en naar geldige objecten wijst, doet hij dat niet standaard bij iedere push. Dit is een relatief dure operatie en kan veel tijd kosten voor iedere push, afhankelijk van de grootte van het repository of de push. Als je wil dat Git ieder object op consistentie controleert bij iedere push, dan kun je hem dwingen door `receive.fsckObjects` op true te zetten:
+Standaard zal Git niet alle objecten die hij ontvangt bij een push op consistentie controleren. Alhoewel Git kan controleren of ieder object nog steeds bij zijn SHA-1 checksum past en naar geldige objecten wijst, doet hij dat niet standaard bij iedere push. Het is een relatief dure operatie en kan veel extra tijd kosten bij iedere push, afhankelijk van de grootte van het repository of de push. Als je wilt dat Git ieder object op consistentie controleert bij elke push, dan kun je dit afdwingen door `receive.fsckObjects` op true te zetten:
 
 	$ git config --system receive.fsckObjects true
 
-Nu zal Git de integriteit van je repository controleren voor iedere push geaccepteerd wordt, om er zeker van te zijn dat kapotte clients geen corrupte gegevens introduceren.
+Nu zal Git de integriteit van je repository controleren voordat een push geaccepteerd wordt, om er zeker van te zijn dat defecte clients geen corrupte gegevens introduceren.
 
 #### receive.denyNonFastForwards ####
 
-Als je commits rebased die je al gepusht hebt en dan nog eens pusht, of op een andere manier een commit probeert te pushen naar een remote branch die niet de commit bevat waarnaar de remote branch op het moment wijst, dan wordt dat afgewezen. Dit is over het algemeen een goed beleid; maar in het geval van de rebase, kun je besluiten dat je weet waar je mee bezig bent en kun je de remote branch geforceerd vernieuwen door een `-f` vlag met je push commando mee te geven.
+Als je commits rebased die je al gepushed hebt en dan nog eens pushed, of op een andere manier een commit probeert te pushen naar een remote branch die niet de commit bevat waarnaar de remote branch op dat moment wijst, dan wordt dat afgewezen. Dit is in het algemeen goed beleid, maar in het geval van de rebase kan je besluiten dat je weet waar je mee bezig bent en kan je de remote branch geforceerd vernieuwen door een `-f` vlag met je push commando mee te geven.
 
 Om de mogelijkheid van het geforceerd vernieuwen van remote branches naar niet fast-forward referenties uit te schakelen, stel je `receive.denyNonFastForwards` in:
 
 	$ git config --system receive.denyNonFastForwards true
 
-Een andere manier waarop je dit kunt doen is het instellen van ontvangst haken op de server, wat we zo meteen gaan behandelen. Die aanpak staat je toe meer complexe dingen te doen, zoals het weigeren van niet fast-forwards aan een bepaalde set gebruikers.
+Een andere manier waarop je dit kunt doen is het instellen van ontvangst haken op de server wat we zo meteen gaan behandelen. Die aanpak stelt je in staat meer complexe dingen te doen, zoals het weigeren van niet fast-forwards aan een bepaalde groep gebruikers.
 
 #### receive.denyDeletes ####
 
-Een van de wegen om een `denyNonFastForwards` beleid heen is dat de gebruiker de branch verwijderd en het dan opnieuw terug pusht met de nieuwe referentie. In nieuwere versies van Git (beginnend bij versie 1.6.1), kun je `receive.denyDeletes` op true zetten:
+Een van de manieren waarop een gebruiker het `denyNonFastForwards` beleid kan omzeilen is dat hij de branch verwijdert en het dan opnieuw terug pushed met een nieuwe referentie. In nieuwere versies van Git (beginnend bij versie 1.6.1), kun je `receive.denyDeletes` op true zetten:
 
 	$ git config --system receive.denyDeletes true
 
-Dit weigert branch en tag verwijdering door middel van een push over de hele breedte – geen enkele gebruiker mag het meer. Om remote branches te verwijderen, moet je de ref bestanden handmatig verwijderen van de server. Er zijn ook interessantere manieren om dit te doen op een per gebruiker basis door middel van ACL's, zoals je zult leren aan het eind van dit hoofdstuk.
+Dit zal systeembreed branch en tag verwijdering door middel van een push weigeren; geen enkele gebruiker mag het meer. Om remote branches te verwijderen, moet je de ref bestanden handmatig verwijderen van de server. Er zijn ook interessantere manieren om dit per gebruiker af te dwingen door middel van ACL's, zoals je zult leren aan het eind van dit hoofdstuk.
 
 ## Git attributen ##
 
-Een aantal van deze instellingen kan ook gedaan worden voor een pad, zodat Git die instellingen alleen toepast om een submap of subset van bestanden. Deze pad-specifieke instellingen worden Git attributen genoemd en worden in een `.gitattribute` bestand in een van je mappen (normaliter in de hoofdmap van je project) of in het `.git/attributes` bestand als je niet wilt dat het attributes bestand gecommit wordt met je project.
+Een aantal van deze instellingen kan ook gedaan worden voor een pad, zodat Git die instellingen alleen toepast voor een subdirectory of subset van bestanden. Deze pad-specifieke instellingen worden Git attributen genoemd en worden in een `.gitattribute` bestand in een van je directories (normaliter in de hoofddirectory van je project) of in het `.git/info/attributes` bestand als je niet wilt dat het attributes bestand gecommit wordt met je project.
 
-Door attributes te gebruiken kun je dingen doen als het specificeren van aparte samenvoeg strategieën voor individuele bestanden of mappen in je project, Git vertellen hoe hij niet-tekst bestanden kan diff'en, of Git inhoud laten filteren voordat je het in- of uitchecked van Git. In deze sectie zul je iets leren over de attributen die je kun instellen op de paden in je Git project en een paar voorbeelden zien hoe je deze eigenschap in de praktijk gebruikt.
+Door attributen te gebruiken kun je dingen doen als het specificeren van aparte merge strategieën voor individuele bestanden of directories in je project, Git vertellen hoe hij niet-tekst bestanden kan diff'en, of Git inhoud laten filteren voordat je het in- of uitchecked van Git. In deze paragraaf zal je iets leren over de attributen die je kun instellen op de paden in je Git project en een paar voorbeelden zien hoe je deze eigenschap in de praktijk gebruikt.
 
 ### Binaire bestanden ###
 
-Een stoere truc waarvoor je Git attributen kunt gebruiken is het vertellen aan Git welke bestanden binair zijn (in die gevallen waarin hij het niet zelf kan uitvinden) en Git dan speciale instructies geven hoe die bestanden te behandelen. Bijvoorbeeld, sommige tekstbestanden worden gegenereerd en zijn niet te diff'en, of sommige binaire bestanden kunnen wel gediff'ed worden – je zult zien hoe je Git verteld welke soort het is.
+Een leuke truc waarvoor je Git attributen kunt gebruiken is het vertellen aan Git welke bestanden binair zijn (in die gevallen waarin hij het niet zelf kan ontdekken) en Git dan speciale instructies geven hoe die bestanden te behandelen. Bijvoorbeeld, sommige tekstbestanden worden gegenereerd en zijn niet te diff'en, of sommige binaire bestanden kunnen wel gediff'ed worden – je zult zien hoe je Git vertelt welke soort het is.
 
 #### Binaire bestanden identificeren ####
 
-Sommige bestanden zien eruit als tekstbestanden, maar moeten toch behandeld worden als binaire gegevens. Bijvoorbeeld, Xcode projecten op de Mac bevatten een bestand dat eindigt in `.pbxproj`, wat eigenlijk een JSON (platte tekst javascript gegevens formaat) gegevensset is, dat geschreven wordt naar de schijf door de IDE, waarin je bouw instellingen opgeslagen zijn enzovoorts. Alhoewel het technisch een tekstbestand is, omdat het volledig ASCII is, zul je het niet als zodanig willen behandelen omdat het eigenlijk een lichtgewicht gegevensbank is – je kunt de inhoud niet samenvoegen als twee mensen het gewijzigd hebben, en diffs zijn over het algemeen niet behulpzaam. Het bestand is bedoeld om geconsumeerd te worden door een machine. In essentie wil je het behandelen als een binair bestand.
+Sommige bestanden zien eruit als tekstbestanden, maar moeten toch behandeld worden als binaire gegevens. Bijvoorbeeld, Xcode projecten op de Mac bevatten een bestand dat eindigt in `.pbxproj`, wat eigenlijk een JSON (javascript gegevens in platte tekst formaat) gegevensset is, dat geschreven wordt naar de schijf door de IDE en waarin je bouw instellingen enzovoorts opgeslagen zijn. Alhoewel het technisch gezien een tekstbestand is, omdat het volledig ASCII is, zul je het niet als zodanig willen behandelen omdat het eigenlijk een lichtgewicht gegevensbank is – je kunt de inhoud niet samenvoegen als twee mensen het gewijzigd hebben, en diffs zijn over het algemeen niet behulpzaam. Het bestand is bedoeld om gebruikt te worden door een machine. In essentie wil je het behandelen als een binair bestand.
 
 Om Git te vertellen dat hij alle `pbxproj` bestanden als binaire gegevens moet behandelen, voeg je de volgende regel toe aan je `.gitattributes` bestand:
 
 	*.pbxproj -crlf -diff
 
-Nu zal Git niet proberen om CRLF problemen te veranderen of te repareren; noch zal het proberen een diff te berekenen of te tonen voor de veranderingen in dit bestand als je git show of git diff uitvoert op je project. In de 1.6 serie van Git, kun je ook een macro gebruiken die meegeleverd wordt, en die `-crlf -diff` betekend:
+Nu zal Git niet proberen om CRLF problemen te corrigeren of repareren; noch zal het proberen een diff te berekenen of te tonen voor de veranderingen in dit bestand als je `git show` of `git diff` uitvoert op je project. In de 1.6 serie van Git, kun je ook het ingebouwde macro `binary` gebruiken die `-crlf -diff` betekend:
 
 	*.pbxproj binary
 
 #### Binaire bestanden diff'en ####
 
-In de 1.6 serie van Git, kun je de functionaliteit van Git attributen gebruiken om binaire bestanden effectief te diff'en. Je doet dit door Git te vertellen hoe het binaire gegevens naar tekst formaat moet omzetten, die dan via de normale diff vergeleken kan worden.
+In Git kan je de functionaliteit van Git attributen gebruiken om binaire bestanden uiteindelijk toch te diff'en. Je doet dit door Git te vertellen hoe het de binaire gegevens naar tekst formaat moet omzetten, die dan via de normale diff vergeleken kan worden. Maar de vraag is hoe je de *binaire* gegevens naar tekst omzet. De beste oplossing is om een tool t vinden die deze conversie van binair naar tekstformaat voor je doet. Helaas kunnen weinig binaire formaten als mens-leesbaar formaat gerepresenteerd worden (probeer maar eens de gegevens van een geluidsfragment om te zetten naar tekst). Als dit het geval is en je bent er niet in geslaagd om een tekst-representatie te krijgen van de inhoud van het bestand is het vaak relatief eenvoudig om een menselijk leesbare omschrijving van de inhoud, of metadata te verkrijgen. Metadata geeft je niet een volledige representatie van de inhoud van het bestand, maar het is in elk geval beter dan niets.
+
+We gaan beide beschreven varianten gebruiken om bruikbare diff's te krijgen voor vaakgebruikte binaire formaten.
+
+Even terzijde: Er zijn verscheidene binaire formaten met een tekstinhoud waar moeilijk een bruikbare converter voor te vinden is. In die gevallen kan je proberen een tekst uit het bestand extraheren met het `strings` programma. Sommige van deze bestanden zouden een UTF-16 encoding of andere "codepages" kunnen gebruiken en `strings` kan dan niets bruikbaars in die bestanden vinden. Resultaten in het verleden geven geen garantie voor de toekomst. Echter `strings` wordt geleverd bij de meeste Mac en Linux systemen, dus het zou een goede eerste kandidaat zijn om dit te proberen bij veel binaire formaten.
+
+#### MS Word bestanden ####
+
+Ten eerste zullen we de beschreven techniek gebruiken om een van de meest ergerlijke problemen in de menselijke geschiedenis op te lossen: Word documenten versioneren. Iedereen weet dat Word een van de ergste editors verkrijgbaar is, maar vreemd genoeg: iedereen gebruikt het. Als je Word documenten in versie beheer wilt krijgen, kan je ze in een Git repostiory gooien en om de zoveel tijd een commit uitvoeren, maar wat voor nut heeft dit? Als je `git diff` uitvoert, zou je iets als dit zien:
 
-Omdat dit een erg stoer en weinig gebruikte eigenschap is, zal ik een paar voorbeelden laten zien. Eerst zul je deze techniek gebruiken om een van de meest irritante problemen van deze mensheid op te lossen: Word documenten versie beheren. Iedereen weet dat Word een van de meest erge editors is die er te vinden is; maar, vreemd genoeg, gebruikt iedereen het. Als je Word documenten wil beheren, kun je ze in een Git repository stoppen en eens in de zoveel tijd committen; maar waar is dat goed voor? Als je `git diff` op een normale manier uitvoert, zie je alleen zoiets als dit:
 
 	$ git diff
 	diff --git a/chapter1.doc b/chapter1.doc
 	index 88839c4..4afcb7c 100644
 	Binary files a/chapter1.doc and b/chapter1.doc differ
 
-Je kunt twee versies niet direct vergelijken, tenzij je ze uitchecked en ze handmatig doorloopt, toch? Het blijkt dat je dit redelijk goed kunt doen door Git attributen te gebruiken. Stop de volgende regel in je `.gitattributes` bestand:
+Je kunt niet direct twee versies vergelijken tenzij je ze uitchecked en handmatig doorneemt, toch? Maar het blijkt dat je dit toch redelijk goed met Git attributen kunt doen. Zet de volgende regel in je `.gitattributes` bestand:
 
 	*.doc diff=word
 
-Dit verteld Git dat ieder bestand dat dit patroon past (.doc) het "word" filter zou moeten gebruiken als je een diff probeert te bekijken, die veranderingen bevat. Wat is het "word" filter? Je zult het moeten instellen. Hier zul je Git configureren om het `strings` programma te gebruiken om Word documenten in leesbare tekstbestanden om te vormen, die het dan fatsoenlijk kan diff'en:
+Dit vertelt Git dat allel bestanden die in het patroon (.doc) passen het "word" filter moeten gebruiken als je een diff probeert te bekijken die wijzigingen bevat. Wat is dat "word" filter eigenlijk? Je moet het zelf opzetten. Hier ga je Git configureren om het `catdoc` programma te gebruiken, die specifiek geschreven is om tekst uit binaire MS Word documenten te extraheren (je kunt het krijgen op `http://www.wagner.pp.ru/~vitus/software/catdoc/`), om Word documenten in leesbare tekstbestanden te converteren, en die vervolgens juist diff'en:
+
+	$ git config diff.word.textconv catdoc
+
+Dit commando voegt een sectie toe aan je `.git/config`, wat er ongeveer zo uitziet:
 
-	$ git config diff.word.textconv strings
+	[diff "word"]
+		textconv = catdoc
 
-Nu weet Git dat als het een diff probeert te doen tussen twee snapshots, en een van de bestanden eindigt in `.doc`, dan zou het deze bestanden door het "word" filter moeten halen, wat is gedefinieerd als het `strings` programma. Dit maakt effectief twee tekst-gebaseerde versies van je Word bestanden, alvorens ze proberen te diff'en.
+Nu weet Git dat wanneer het probeert een diff uit te voeren tussen twee snapshots, en bestandsname eindigen op `.doc` dat het deze bestanden door de "word" filter moet halen, die gedefinieerd is als het `catdoc` programma. Effectief maakt het twee gewone tekst-gebaseerde versies van je Word bestanden vooraleer te proberen ze met diff te vergelijken.
 
-Hier is een voorbeeld. Ik heb Hoofdstuk 1 van dit boek in Git gestopt, wat tekst aan een paragraaf toegevoegd, en het document bewaard. Daarna heb ik `git diff` uitgevoerd om te zien wat er gewijzigd is:
+Hier is een voorbeeld. Ik heb hoofdstuk 1 van dit boek in Git gezet, wat tekst in een paragraaf toegevoegd en daarna het document gesaved. Daarna voerde ik `git diff` uit om te zien wat er gewijzigd was:
 
 	$ git diff
 	diff --git a/chapter1.doc b/chapter1.doc
 	index c1c8a0a..b93c9e4 100644
 	--- a/chapter1.doc
 	+++ b/chapter1.doc
-	@@ -8,7 +8,8 @@ re going to cover Version Control Systems (VCS) and Git basics
-	 re going to cover how to get it and set it up for the first time if you don
-	 t already have it on your system.
-	 In Chapter Two we will go over basic Git usage - how to use Git for the 80%
-	-s going on, modify stuff and contribute changes. If the book spontaneously
-	+s going on, modify stuff and contribute changes. If the book spontaneously
-	+Let's see if this works.
+	@@ -128,7 +128,7 @@ and data size)
+	 Since its birth in 2005, Git has evolved and matured to be easy to use
+	 and yet retain these initial qualities. It’s incredibly fast, it’s
+	 very efficient with large projects, and it has an incredible branching
+	-system for non-linear development.
+	+system for non-linear development (See Chapter 3).
+
+Git vertelt me succesvol en kort en bondig dat ik de tekst "(See Chapter 3)" heb toegevoegd, wat juist is. Werkt perfect!
+
+##### OpenDocument tekst bestanden #####
+
+Dezelfde aanpak die we hebben gebruikt vooro MS Word bestanden (`*.doc`) kan worden gebruikt bij OpenDocument Tekst bestanden (`*.odt`) wat gemaakt is door OpenOffice.org.
+
+Voeg de volgende regel toe aan je `.gitattributes` bestand:
+
+	*.odt diff=odt
 
-Git verteld me succesvol en beknopt dat ik de tekst "Let's see if this works" heb toegevoegd, wat correct is. Het is niet perfect – het voegt een serie willekeurig spul aan het einde toe – maar het werkt wel. Als je een Word-naar-gewone-tekst omvormer kunt vinden of schrijven die goed genoeg werkt, dan zal die oplossing waarschijnlijk zeer effectief zijn. Maar, `strings` is op de meeste Mac en Linux machines beschikbaar, dus dit kan een goede eerste poging zijn om dit te gebruiken bij andere binaire formaten.
+Zet nu het `odt` diff filter op in `.git/config`:
 
-Een ander interessant probleem dat je hiermee kunt oplossen in het diff'en van beeldbestanden. Een manier om dit te doen is JPEG bestanden door een filter te halen dat hun EXIF informatie eruit peutert – metadata die wordt opgeslagen met de meeste beeldbestanden. Als je het `exiftool` programma download en installeert, kun je het gebruiken om je plaatjes naar tekst over de metadata om te zetten, zodat de diff op z'n minst een tekstuele representatie van eventuele wijzigingen laat zien:
+	[diff "odt"]
+		binary = true
+		textconv = /usr/local/bin/odt-to-txt
+
+OpenDocument bestanden zijn eigenlijk gezipte directories met daarin meerdere bestanden (de inhoud ervan in een XML formaat, stylesheets, plaatjes, etc.). Ze zullen een script moeten schrijven om de inhoud te extraheren en dit terug te geven als platte tekst. Maak een bestand `/usr/local/bin/odt-to-txt` (het staat je vrij om dit in een andere directory neer te zetten) met de volgende inhoud:
+
+	#! /usr/bin/env perl
+	# Simplistic OpenDocument Text (.odt) to plain text converter.
+	# Author: Philipp Kempgen
+
+	if (! defined($ARGV[0])) {
+		print STDERR "No filename given!\n";
+		print STDERR "Usage: $0 filename\n";
+		exit 1;
+	}
+
+	my $content = '';
+	open my $fh, '-|', 'unzip', '-qq', '-p', $ARGV[0], 'content.xml' or die $!;
+	{
+		local $/ = undef;  # slurp mode
+		$content = <$fh>;
+	}
+	close $fh;
+	$_ = $content;
+	s/<text:span\b[^>]*>//g;           # remove spans
+	s/<text:h\b[^>]*>/\n\n*****  /g;   # headers
+	s/<text:list-item\b[^>]*>\s*<text:p\b[^>]*>/\n    --  /g;  # list items
+	s/<text:list\b[^>]*>/\n\n/g;       # lists
+	s/<text:p\b[^>]*>/\n  /g;          # paragraphs
+	s/<[^>]+>//g;                      # remove all XML tags
+	s/\n{2,}/\n\n/g;                   # remove multiple blank lines
+	s/\A\n+//;                         # remove leading blank lines
+	print "\n", $_, "\n\n";
+
+En maak het uitvoerbaar
+
+	chmod +x /usr/local/bin/odt-to-txt
+
+Nu zal `git diff` je kunnen vertellen wat er gewijzigd is in `.odt` bestanden.
+
+
+##### Beeldbestanden #####
+
+Een ander interessant probleem dat je hiermee kunt oplossen is het diff'en van beeldbestanden. Een manier om dit te doen is PNG bestanden door een filter te halen dat de EXIF informatie eruit peutert; dat is metadata die wordt opgeslagen bij de meeste beeldbestand formaten. Als je het `exiftool` programma download en installeert, kan je dit gebruiken om je plaatjes naar tekst over de metadata om te zetten, zodat de diff op z'n minst een tekstuele representatie van eventuele wijzigingen laat zien:
 
 	$ echo '*.png diff=exif' >> .gitattributes
 	$ git config diff.exif.textconv exiftool
 
-Als je een plaatje in je project veranderd en `git diff` uitvoert, dan zie je zoiets als dit:
+Als je een plaatje in je project verandert en `git diff` uitvoert, dan zie je zoiets als dit:
 
 	diff --git a/image.png b/image.png
 	index 88839c4..4afcb7c 100644
@@ -373,9 +437,9 @@ Je kunt eenvoudig zien dat zowel de bestandsgrootte als de beeld dimensies gewij
 
 ### Keyword expansie ###
 
-Keyword expansie zoals in SVN of CVS wordt vaak gevraagd door ontwikkelaars, die gewend zijn aan die systemen. Het grote probleem in Git is dat je een bestand niet mag wijzigen met informatie over de commit, nadat je het gecommit hebt, omdat Git eerst de checksum van het bestand maakt. Maar, je kunt tekst in een bestand injecteren zodra het uitgechecked wordt en opnieuw verwijderen voordat het aan een commit toegevoegd wordt. Met Git attributen zijn er twee manieren om dit te doen.
+Keyword expansie zoals in SVN of CVS gebruikt wordt, wordt vaak gevraagd door ontwikkelaars die gewend zijn aan die systemen. Het grote probleem in Git is dat je een bestand niet mag wijzigen met informatie over de commit nadat je het gecommit hebt, omdat Git eerst de checksum van het bestand maakt. Maar, je kunt tekst in een bestand injecteren zodra het uitgechecked wordt en dit weer verwijderen voordat het aan een commit toegevoegd wordt. Met Git attributen zijn er twee manieren om dit te doen.
 
-Als eerste kun je de SHA-1 checksum van een blob automatisch in een `$Id$` veld in het bestand stoppen. Als je dit attribuut op een bestand of serie bestanden insteld, dan zal Git de volgende keer dat je die branch uitchecked dat veld vervangen met de SHA-1 van de blob. Het is belangrijk om op te merken dat het niet de SHA van de commit is, maar van de blob zelf:
+Als eerste kun je de SHA-1 checksum van een blob automatisch in een `$Id$` veld in het bestand stoppen. Als je dit attribuut in een bestand of aantal bestanden zet, dan zal Git de volgende keer dat je die branch uitchecked dat veld vervangen met de SHA-1 van de blob. Het is belangrijk om op te merken dat het niet de SHA van de commit is, maar van de blob zelf:
 
 	$ echo '*.txt ident' >> .gitattributes
 	$ echo '$Id$' > test.txt
@@ -387,9 +451,9 @@ De volgende keer dat je dit bestand uitchecked, injecteert Git de SHA van de blo
 	$ cat test.txt
 	$Id: 42812b7653c7b88933f8a9d6cad0ca16714b9bb3 $
 
-Maar, het resultaat is slechts beperkt bruikbaar. Als je sleutelwoord vervanging in CVS of Subversion gebruikt hebt, kun je een tijdstempel toevoegen – de SHA is niet zo bruikbaar, omdat het vrij willekeurig is en je kunt niet zeggen of een SHA ouder of nieuwer is dan een andere.
+Maar, het resultaat heeft slechts een beperkt nut. Als je sleutelwoord vervanging (keyword substitution) in CVS of Subversion gebruikt hebt, kun je een datumstempel toevoegen – de SHA is niet zo bruikbaar, omdat het vrij willekeurig is en je kunt niet zeggen of de ene SHA ouder of nieuwer is dan de andere.
 
-Het blijkt dat je je eigen filters voor het doen van vervanging bij commit/checkout kunt schrijven. Dit zijn de "clean" en "smudge" filters. In het `.gitattributes` bestand, kun je een filter op bepaalde paden instellen en dan scripts instellen die bestanden bewerkt vlak voordat ze gecommit worden ("clean", zie Figuur 7-2) en vlak voordat ze uitgechecked worden ("smudge", zie Figuur 7-3). De filters kunnen ingesteld worden zodat ze allerlei leuke dingen doen.
+Je kunt echter je eigen filters voor het doen van vervanging bij commit/checkout schrijven. Dit zijn de "kuis" ("clean") en "besmeer" ("smudge") filters. In het `.gitattributes` bestand kan je een filter op bepaalde paden instellen en dan scripts instellen die bestanden bewerkt vlak voordat ze uitgechecked worden ("smudge", zie Figuur 7-2) en vlak voordat ze gecommit worden ("clean", zie Figuur 7-3). De filters kunnen ingesteld worden om allerlei leuke dingen doen.
 
 Insert 18333fig0702.png
 Figuur 7-2. Het “smudge” filter wordt bij checkout uitgevoerd.
@@ -397,7 +461,7 @@ Figuur 7-2. Het “smudge” filter wordt bij checkout uitgevoerd.
 Insert 18333fig0703.png
 Figuur 7-3. Het “clean” filter wordt uitgevoerd zodra bestanden worden gestaged.
 
-De originele commit boodschap voor deze functionaliteit geeft een eenvoudig voorbeeld hoe je al je C broncode door het `indent` programma kunt halen alvorens te committen. Je kunt het instellen door het filter attribuut in je `.gitattributes` bestand te veranderen zodat `*.c` bestanden door de "indent" filter gehaald worden:
+De originele commit boodschap van deze functionaliteit geeft een eenvoudig voorbeeld hoe je al je C broncode door het `indent` programma kunt laten bewerken alvorens te committen. Je kunt het instellen door het filter attribuut in je `.gitattributes` bestand te zetten zodat `*.c` bestanden door de "indent" filter gehaald worden:
 
 	*.c     filter=indent
 
@@ -406,26 +470,26 @@ Vervolgens vertel je Git wat het "indent" filter doet bij smudge en clean:
 	$ git config --global filter.indent.clean indent
 	$ git config --global filter.indent.smudge cat
 
-In dit geval zal Git, als je bestanden commit die op `*.c` passen, ze door het indent programma halen alvorens ze te committen, en ze door het `cat` programma halen alvorens ze op de schijf uit te checken. Het `cat` programma is eigenlijk een no-op: het spuugt dezelfde gegevens uit als dat het inneemt. Deze combinatie zal effectief alle C broncode bestanden door `indent` filteren alvorens te committen.
+In dit geval zal Git, als je bestanden commit die op `*.c` passen, ze door het indent programma halen alvorens ze te committen, en ze door het `cat` programma halen alvorens ze op de schijf uit te checken. Het `cat` programma is eigenlijk een no-op: het geeft de gegevens onveranderd door. Deze combinatie zal effectief alle C broncode bestanden door `indent` filteren alvorens te committen.
 
-Een ander interessant voorbeeld is `$Date$` sleutelwoord expansie, in RCS stijl. Om dit goed te doen, moet je een klein script hebben dat een bestandsnaam pakt, de laatste commit datum voor dit project uitvogelt, en de datum in een bestand toevoegt. Hier volgt een klein Ruby script dat dat doet:
+Een ander interessant voorbeeld is `$Date$` sleutelwoord expansie, in RCS stijl. Om dit goed te doen, moet je een klein script hebben dat een bestandsnaam pakt, de laatste commit datum voor dit project opzoekt, en de datum in een bestand toevoegt. Hier volgt een klein Ruby script dat dat doet:
 
 	#! /usr/bin/env ruby
 	data = STDIN.read
 	last_date = `git log --pretty=format:"%ad" -1`
 	puts data.gsub('$Date$', '$Date: ' + last_date.to_s + '$')
 
-Het enige dat het script doet is de laatste commit datum uit het `git log` commando halen, het in iedere `$Date$` tekst stoppen die het in stdin ziet, en de resultaten afdrukken – het moet eenvoudig te doen zijn in welke taal je je ook thuisvoelt. Je kunt dit bestand `expand_date` noemen en het in je pad stoppen. Nu moet je een filter in Git instellen (noem het `dater`), en het vertellen je `expand_date` filter te gebruiken om de bestanden tijdens checkout te 'smudgen'. Je zult een Perl expressie gebruiken om dat op te ruimen tijdens een commit:
+Het enige dat het script doet is de laatste commit datum uit het `git log` commando halen, het in iedere `$Date$` tekst stoppen die het in stdin ziet, en de resultaten afdrukken – het moet eenvoudig te copieren zijn in welke taal je het beste thuisbent. Je kunt dit bestand `expand_date` noemen en het in je pad stoppen. Nu moet je een filter in Git instellen (noem het `dater`), en het vertellen jouw `expand_date` filter te gebruiken om de bestanden tijdens checkout te 'besmeren'. Je zult een Perl expressie gebruiken om dat op te ruimen tijdens een commit:
 
 	$ git config filter.dater.smudge expand_date
 	$ git config filter.dater.clean 'perl -pe "s/\\\$Date[^\\\$]*\\\$/\\\$Date\\\$/"'
 
-Dit Perl stukje haalt alles weg dat het in en `$Date$` tekst ziet, om terug te komen vanwaar je gekomen bent. Nu je filter klaar is, kun je het testen door een bestand aan te maken met je `$Date$` sleutelwoord en dan een Git attribuut voor dat bestand in te stellen, die het nieuwe filter gebruikt.
+Dit stukje Perl haalt alles weg dat het in en `$Date$` tekst ziet, om weer op het uitgangspunt uit te komen. Nu je filter klaar is, kun je het testen door een bestand aan te maken met het `$Date$` sleutelwoord en dan een Git attribuut voor dat bestand in te stellen, die het nieuwe filter gebruikt.
 
 	$ echo '# $Date$' > date_test.txt
 	$ echo 'date*.txt filter=dater' >> .gitattributes
 
-Als je die veranderingen commit en het bestand opnieuw uitchecked, zul je zien dat het sleutelwoord vervangen is:
+Als je die veranderingen commit en het bestand opnieuw uitchecked, zul je zien dat het sleutelwoord correct vervangen is:
 
 	$ git add date_test.txt .gitattributes
 	$ git commit -m "Testing date expansion in Git"
@@ -434,7 +498,7 @@ Als je die veranderingen commit en het bestand opnieuw uitchecked, zul je zien d
 	$ cat date_test.txt
 	# $Date: Tue Apr 21 07:26:52 2009 -0700$
 
-Je kunt wel zien hoe krachtig deze techniek is voor gebruik in eigengemaakte toepassingen. Je moet wel voorzichtig zijn, om dat het `.gitattributes` bestand ook gecommit wordt en meegestuurd wordt met het project, maar het filter (in dit geval `dater`) niet; dus het zal niet overal werken. Als je deze filters ontwerpt, zouden ze in staat moeten zijn om netjes te falen en het project nog steeds goed te laten werken.
+Je ziet hier hoe krachtig deze techniek is voor gebruik in eigengemaakte toepassingen. Je moet wel voorzichtig zijn, om dat het `.gitattributes` bestand ook gecommit wordt en meegestuurd wordt met het project, maar het filter (in dit geval `dater`) niet; dus het zal niet overal werken. Als je deze filters ontwerpt, zouden ze in staat moeten zijn om netjes te falen en het project nog steeds goed te laten werken.
 
 ### Je repository exporteren ###
 
@@ -442,9 +506,9 @@ De Git attribute gegevens staan je ook toe om interessante dingen te doen als je
 
 #### export-ignore ####
 
-Je kunt Git vertellen dat sommige bestanden of mappen niet geëxporteerd moeten worden als een archief gegenereerd wordt. Als er een submap of bestand is waarvan je niet wil dat het wordt meegenomen in je archief bestand, maar dat je wel in je project ingechecked wil hebben, dan kun je die bestanden bepalen met behulp van het `export-ignore` attribuut.
+Je kunt Git vertellen dat sommige bestanden of directories niet geëxporteerd moeten worden als een archief gegenereerd wordt. Als er een subdirectory of bestand is waarvan je niet wil dat het wordt meegenomen in je archief bestand, maar dat je wel in je project ingechecked wil hebben, dan kun je die bestanden bepalen met behulp van het `export-ignore` attribuut.
 
-Bijvoorbeeld, stel dat je wat testbestanden in een `test/` submap hebt, en dat het geen zin heeft om die in de tarball export van je project mee te nemen. Je kunt dan de volgende regel in je Git attributes bestand toevoegen:
+Bijvoorbeeld, stel dat je wat testbestanden in een `test/` submap hebt, en dat het geen zin heeft om die in de tarball export van je project mee te nemen. Dan kan je de volgende regel in je Git attributes bestand toevoegen:
 
 	test/ export-ignore
 
@@ -452,101 +516,101 @@ Als je nu git archive uitvoert om een tarball van je project te maken, zal die m
 
 #### export-subst ####
 
-Iets anders dat je kunt doen met je archieven is eenvoudige sleutelwoord vervanging. Git staat je toe om de tekst `$Format:$` in ieder bestand met ieder van de `--pretty=format` formaat afkortingen te zetten, waarvan je er al veel zag in Hoofdstuk 2. Bijvoorbeeld, als je een bestand genaamd `LAST_COMMIT` wilt meenemen in je project, en de laatste commit datum was hierin automatisch geïnjecteerd toen `git archive` bezig was, kun je het bestand als volgt instellen:
+Iets anders dat je kunt doen met je archieven is eenvoudige sleutelwoord vervanging. Git staat je toe om de tekst `$Format:$` met een van de `--pretty=format` formaat afkortingen in één of meer bestanden te zetten,. Voorbeelden van die formaatafkortingen zag je al in Hoofdstuk 2. Bijvoorbeeld, als je een bestand genaamd `LAST_COMMIT` wilt meenemen in je project, waarin de laatste commit datum automatisch wordt geïnjecteerd als `git archive` loopt, kun je het bestand als volgt instellen:
 
 	$ echo 'Last commit date: $Format:%cd$' > LAST_COMMIT
 	$ echo "LAST_COMMIT export-subst" >> .gitattributes
 	$ git add LAST_COMMIT .gitattributes
 	$ git commit -am 'adding LAST_COMMIT file for archives'
 
-Als je `git archive` uitvoert, zal de inhoud van dat bestand als mensen het archief bestand openen er zo uit zien:
+Als je `git archive` uitvoert, zal de inhoud van dat bestand, als mensen het archief bestand openen, er zo uit zien:
 
 	$ cat LAST_COMMIT
 	Last commit date: $Format:Tue Apr 21 08:38:48 2009 -0700$
 
-### Samenvoeg strategieën ###
+### Merge strategieën ###
 
-Je kunt Git attributen ook gebruiken om Git te vertellen dat het verschillende samenvoeg strategieën moet gebruiken voor specifieke bestanden in je project. Een erg handige optie is Git te vertellen dat het niet moet proberen bepaalde bestanden samen te voegen als ze conflicten hebben, maar jouw versie moeten gebruiken in plaats van andermans versie.
+Je kunt Git attributen ook gebruiken om Git te vertellen dat het verschillende merge strategieën moet gebruiken voor specifieke bestanden in je project. Een erg handige optie is Git te vertellen dat het niet moet proberen bepaalde bestanden te mergen als ze conflicten hebben, maar jouw versie moeten gebruiken in plaats van die van de ander.
 
-Dit is handig als een branch in je project af is geweken of gespecialiseerd is, maar je in staat wil zijn om veranderingen daarvan terug samen te voegen, en je wilt bepaalde bestanden negeren. Stel dat je een gegevensbank instellingen bestand hebt dat database.xml heet en dat in twee branches verschillend is, en je wilt in je andere branch samenvoegen zonder het gegevensbank bestand te verprutsen. Je kunt dan een attribuut als volgt instellen:
+Dit is handig als een branch in je project af is geweken of gespecialiseerd is, je wel in staat wilt zijn om veranderingen daarvan te mergen, maar je wilt bepaalde bestanden negeren. Stel dat je een database instellingen bestand hebt dat database.xml heet en dat in twee branches verschillend is, en je wilt de andere branch mergen zonder jouw database bestand te verprutsen. Je kunt dan een attribuut als volgt instellen:
 
 	database.xml merge=ours
 
-Als je in de andere branch samenvoegt, dan zul je in plaats van samenvoeg conflicten met je database.xml bestand zoiets als dit zien:
+Als je in de andere branch merged, dan zul je in plaats van merge conflicten met je database.xml bestand zoiets als dit zien:
 
 	$ git merge topic
 	Auto-merging database.xml
 	Merge made by recursive.
 
-In dit geval blijft database.xml staan op welke versie je origineel ook had.
+In dit geval blijft database.xml staan op de versie die je origineel al had.
 
-## Git haken ##
+## Git haken (hooks) ##
 
-Zoals vele andere Versie Beheer Systemen, heeft Git een manier om eigengemaakte scripts op te starten wanneer bepaalde belangrijke acties voorkomen. Er zijn twee groepen van dit soort haken: aan de client kant en aan de server kant. De haken aan de client kant zijn voor client operaties zoals committen en samenvoegen. De haken voor de server kant zijn voor Git server operaties zoals het ontvangen van gepushte commits. Je kunt deze haken om allerlei redenen gebruiken, en je zult hier over een aantal ervan leren.
+Zoals vele andere Versie Beheer Systemen, heeft Git een manier om eigengemaakte scripts op te starten wanneer bepaalde belangrijke acties plaatsvinden. Er zijn twee groepen van dit soort hooks: aan de client kant en aan de server kant. De hooks aan de client kant zijn voor client operaties zoals committen en mergen. De hooks voor de server kant zijn voor Git server operaties zoals het ontvangen van gepushte commits. Je kunt deze hooks om allerlei redenen gebruiken, en je zult hier over een aantal ervan leren.
 
-### Een haak installeren ###
+### Een hook installeren ###
 
-De haken worden allemaal opgeslagen in de `hooks` submap van de Git map. In de meeste projecten is dat `.git/hooks`. Standaard voorziet Git deze map van een aantal voorbeeld scripts, waarvan de meeste al bruikbaar zijn; maar ze documenteren ook de invoer waarden van ieder script. Alle scripts zijn als shell script geschreven, met hier en daar wat Perl, maar iedere executable met de juiste naam zal prima werken – je kunt ze in Ruby of Python of wat je wil schrijven. Voor Git versies later dan 1.6, eindigen deze haak bestanden met .sample; je zult ze van naam moeten veranderen. Voor eerdere versies van Git, zijn de scripts al van de juiste naam voorzien, maar je moet ze nog uitvoerbaar maken.
+De hooks zijn allemaal opgeslagen in de `hooks` subdirectory van de Git directory. In de meeste projecten is dat `.git/hooks`. Standaard voorziet Git deze map van een aantal voorbeeld scripts, waarvan de meeste op zich al bruikbaar zijn, maar ze documenteren ook de invoer waarden van elke script. Alle scripts zijn als shell script geschreven met hier en daar wat Perl, maar iedere executable met de juiste naam zal prima werken – je kunt ze in Ruby of Python of wat je wilt schrijven. De namen van de scripts eindigen op .sample; je zult ze van naam moeten veranderen.
 
-Om een haak script aan te zetten, stop je een bestand met de juiste naam en dat uitvoerbaar is in de `hooks` map van je Git map. Vanaf dat punt zou het aangeroepen moeten worden. Ik zal de meestgebruikte haak bestandsnamen hier behandelen.
+Om een hook script aan te zetten, zet je een bestand met de juiste naam en dat uitvoerbaar is in de `hooks` subdirectory van je Git directory. Vanaf dat moment zou het aangeroepen moeten worden. Ik zal de meestgebruikte hook bestandsnamen hier behandelen.
 
-### Client-kant haken ###
+### Hooks aan de client-kant ###
 
-Er zijn veel client-kant haken. Deze sectie verdeeld ze in commit-werkwijze haken, e-mail-werkwijze scripts, en de rest van de client-kant scripts
+Er zijn veel hooks aan de client-kant. Deze paragraaf verdeelt ze in commit-werkwijze hooks, e-mail-werkwijze scripts, en de rest van de client-kant scripts
 
 #### Commit-werkwijze haken ####
 
-De eerste vier haken hebben te maken met het commit proces. De `pre-commit` haak wordt eerst uitgevoerd, nog voor je een commit boodschap intypt. Het wordt gebruikt om het snapshot dat op het punt staat gecommit te worden te inspecteren, om te zien of je iets bent vergeten, om er zeker van te zijn dat tests uitgevoerd worden, of om te onderzoeken wat je wilt in de code. Deze haak met een waarde anders dan nul afsluiten breekt de commit af, alhoewel je 'm kunt omzeilen met `git commit --no-verify`. Je kunt dingen doen als op code stijl controleren (voer lint of iets dergelijks uit), op aanhangende spaties controleren (de standaard haak doet dat), of om de juiste documentatie op nieuwe functies te controleren.
+De eerste vier hooks hebben te maken met het commit proces. De `pre-commit` hook wordt eerst uitgevoerd, nog voor je een commit boodschap intypt. Het wordt gebruikt om het snapshot dat op het punt staat gecommit te worden te inspecteren, om te zien of je iets bent vergeten, om er zeker van te zijn dat tests uitgevoerd worden of om wat je maar wilt te onderzoeken in de code. Als deze hook met een exit-waarde anders dan nul eindigt breekt de commit af, alhoewel je dit kunt omzeilen met `git commit --no-verify`. Je kunt dingen doen als op code stijl controleren (door lint of iets dergelijks uit te voeren), op 'trailing whitespaces' te controleren (de standaard hook doet dat), of om de juiste documentatie op nieuwe methodes te controleren.
 
-De `prepare-commit-msg` haak wordt uitgevoerd voordat de commit boodschap editor gestart wordt, maar nadat de standaard boodschap aangemaakt is. Het stelt je in staat om de standaard boodschap aan te passen voordat de commit auteur het ziet. Deze haak accepteert een aantal opties: het pad naar het bestand dat de huidige commit boodschap bevat, het type van de commit, en de SHA-1 van de commit als het een verbeterde commit betreft. Deze haak is voor normale commits niet zo bruikbaar; maar, het is goed voor commits waarbij de standaard boodschap automatisch gegenereerd wordt, zoals sjabloon commit boodschappen, samenvoeg commits, gesquashte commits en verbeterde commits. Je mag het samen met een commit sjabloon gebruiken om informatie in te voegen.
+De `prepare-commit-msg` hook wordt uitgevoerd voordat de commit boodschap editor gestart wordt, maar nadat de standaard boodschap aangemaakt is. Het stelt je in staat om de standaard boodschap aan te passen voordat de commit auteur het ziet. Deze hook accepteert een aantal opties: het pad naar het bestand dat de huidige commit boodschap bevat, het type van de commit, en de SHA-1 van de commit als het een verbeterde (amended) commit betreft. Deze hook is voor normale commits niet zo bruikbaar, maar het is juist bruikbaar voor commits waarbij de standaard boodschap automatisch gegenereerd wordt, zoals sjabloon commit boodschappen, merge commits, gesquashte commits en amended commits. Je kan het samen met een commit sjabloon gebruiken om informatie programmatisch in te voegen.
 
-De `commit-msg` hook accepteert één parameter, wat weer het pad naar een tijdelijk bestand is dat de huidige commit boodschap bevat. Als dit script eindigt met een waarde anders dan nul, dan zal Git het commit proces afbreken, dus je kunt het gebruiken om je project-status of de commit boodschap te valideren alvorens een commit toe te staan. In het laatste gedeelte van dit hoofdstuk, zal ik deze haak demonstreren om te controleren of je commit boodschap aan een bepaald patroon voldoet.
+De `commit-msg` hook accepteert één parameter, wat weer het pad naar een tijdelijk bestand is dat de huidige commit boodschap bevat. Als dit script eindigt met een waarde anders dan nul, dan zal Git het commit proces afbreken, je kunt deze gebruiken om je project-status of de commit boodschap te valideren alvorens een commit toe te staan. In het laatste gedeelte van dit hoofdstuk, zal ik deze hook demonstreren hoe te controleren dat de commit boodschap aan een bepaald patroon voldoet.
 
-Nadat het hele commit proces afgerond is, zal de `post-commit` haak uitgevoerd worden. Het accepteert geen parameters, maar je kunt de laatste commit eenvoudig ophalen door `git log -1 HEAD` uit te voeren. Over het algemeen wordt dit script gebruikt om notificaties of iets dergelijks uit te sturen.
+Nadat het hele commit proces afgerond is, zal de `post-commit` hook uitgevoerd worden. Het accepteert geen parameters, maar je kunt de laatste commit eenvoudig ophalen door `git log -1 HEAD` uit te voeren. Over het algemeen wordt dit script gebruikt om notificaties of iets dergelijks uit te sturen.
 
-De commit-werkwijze client-kant scripts kunnen gebruikt worden in vrijwel iedere werkwijze. Ze worden vaak gebruikt om een bepaald beleid af te dwingen, maar het is belangrijk om te weten dat deze scripts niet overgedragen worden bij het klonen. Je kunt beleid afdwingen op de server kant om pushes of commits te weigeren, die niet voldoen aan een bepaald beleid, maar het is aan de ontwikkelaar om deze scripts aan de client kant te gebruiken. Dus, deze scripts zijn er om ontwikkelaars te helpen, en ze moeten door hen ingesteld en onderhouden worden, alhoewel ze aangepast of omzeilt kunnen worden op ieder tijdstip.
+De commit-werkwijze scripts aan de client-kant kunnen gebruikt worden in vrijwel iedere werkwijze. Ze worden vaak gebruikt om een bepaald beleid af te dwingen, maar het is belangrijk om op te merken dat deze scripts niet overgedragen worden bij het klonen. Je kunt beleid afdwingen aan de server kant door pushes of commits te weigeren die niet voldoen aan een bepaald beleid, maar het is aan de ontwikkelaar om deze scripts aan de client kant te gebruiken. Dus, deze scripts zijn er om ontwikkelaars te helpen en ze moeten door hen ingesteld en onderhouden worden, alhoewel ze door hen op elk moment aangepast of omzeild kunnen worden.
 
-#### E-mail werkwijze haken ####
+#### E-mail werkwijze hooks ####
 
-Je kunt drie client kant haken instellen voor een e-mail gebaseerde werkwijze. Ze worden allemaal aangeroepen door het `git am` commando, dus als je dat commando niet gebruikt in je werkwijze, dan kun je veilig doorgaan naar de volgende sectie. Als je patches aanneemt via e-mail, die door `git format-patch` geprepareerd zijn, dan zullen sommige van deze behulpzaam zijn voor je.
+Je kunt drie client-kant hooks instellen voor een e-mail gebaseerde werkwijze. Ze worden allemaal aangeroepen door het `git am` commando dus als je dat commando niet gebruikt in je werkwijze, dan kun je gerust doorgaan naar de volgende paragraaf. Als je patches aanneemt via e-mail die door `git format-patch` geprepareerd zijn, dan zullen sommige van deze scripts nuttig zijn voor je.
 
-De eerste haak die uitgevoerd wordt is `applypatch-msg`. Het accepteert een enkel argument: de naam van het tijdelijke bestand dat de voorgestelde commit boodschap bevat. Git breekt de patch als dit script met een waarde ongelijk aan nul eindigt. Je kunt dit gebruiken om er zeker van te zijn dat een commit boodschap juist geformatteerd is, of om de boodschap te normaliseren door het script de boodschap aan te laten passen.
+De eerste hook die uitgevoerd wordt is `applypatch-msg`. Het accepteert één enkel argument: de naam van het tijdelijke bestand dat de voorgedragen commit boodschap bevat. Git breekt de patch als dit script met een waarde ongelijk aan nul eindigt. Je kunt dit gebruiken om je ervan te verzekeren dat een commit boodschap juist geformatteerd is, of om de boodschap te normaliseren door het script de boodschap aan te laten passen.
 
-De volgende haak die wordt uitgevoerd tijdens het toepassen van patches via `git am` is `pre-applypatch`. Dit neemt geen argumenten aan en wordt uitgevoerd nadat de patch is toegepast, zodat je het kunt gebruiken om het snapshot te inspecteren alvorens de commit te doen. Je kunt tests uitvoeren of de werkmap op een andere manier inspecteren met behulp van dit script. Als er iets mist of één van de tests faalt, dan zal eindigen met niet nul het `git am` script afbreken zonder de patch te committen.
+De volgende hook die wordt uitgevoerd tijdens het toepassen van patches via `git am` is `pre-applypatch`. Dit neemt geen argumenten aan en wordt uitgevoerd nadat de patch is toegepast, zodat je het kunt gebruiken om het snapshot te inspecteren alvorens de commit te doen. Je kunt tests uitvoeren of de werkmap op een andere manier inspecteren met behulp van dit script. Als er iets mist of één van de tests faalt, dan zal eindigen met niet nul het `git am` script afbreken zonder de patch te committen.
 
-De laatste haak die uitgevoerd wordt tijdens een `git am` operatie is de `post-applypatch`. Je kunt dat gebruiken om een groep te notificeren of de auteur van de patch die je zojuist gepulled hebt. Je kunt het patch proces niet stoppen met behulp van dit script.
+De laatste hook die uitgevoerd wordt tijdens een `git am` operatie is de `post-applypatch`. Je kunt dat gebruiken om een groep te notificeren of de auteur van de patch die je zojuist gepulled hebt. Je kunt het patch proces niet stoppen met behulp van dit script.
 
-#### Andere client haken ####
+#### Andere client hooks ####
 
-De `pre-rebase` haak wordt uitgevoerd voordat je ook maar iets rebased, en kan het proces afbreken door met een waarde anders dan nul te eindigen. Je kunt deze haak gebruiken om tegen te gaan dat commits die al gepusht zijn gerebased worden. De voorbeeld `pre-rebase` haak die Git installeert doet dit, alhoewel deze er vanuit gaat dat next de naam is van de branch die je publiceert. Je zult dat waarschijnlijk moeten veranderen in de naam van je stabiele gepubliceerde branch.
+De `pre-rebase` hook wordt uitgevoerd voordat je ook maar iets rebased, en kan het proces afbreken door met een waarde anders dan nul te eindigen. Je kunt deze hook gebruiken om te voorkomen dat commits die al gepushed zijn gerebased worden. De voorbeeld `pre-rebase` hook die Git installeert doet dit, alhoewel deze er vanuit gaat dat "next" de naam is van de branch die je publiceert. Je zult dat waarschijnlijk moeten veranderen in de naam van je stabiele gepubliceerde branch.
 
-Nadat je een succesvolle `git checkout` uitgevoerd hebt, wordt de `post-checkout` haak uitgevoerd; je kunt het gebruiken om je werkmap goed in te stellen voor je project omgeving. Dit kan het invoegen van grote binaire bestanden die je niet in versie beheer wil hebben betekenen, of het automatisch genereren van documentatie, of iets in die geest.
+Nadat je een succesvolle `git checkout` uitgevoerd hebt, wordt de `post-checkout` hook uitgevoerd; je kunt het gebruiken om je werkdiorectory goed in te stellen voor je project omgeving. Dit kan het invoegen van grote binaire bestanden die je niet in versie beheer wil hebben inhouden, of het automatisch genereren van documentatie of iets in die geest.
 
-Als laatste wordt de `post-merge` haak uitgevoerd na een succesvol `merge` commando. Je kunt het gebruiken om gegevens in de boom die Git niet kan volgen terug te zetten, bijvoorbeeld permissie gegevens. Ook kan deze haak gebruikt worden om de aanwezigheid van bestanden buiten de controle van Git te controleren, die je misschien in je boom gekopieerd wil hebben zodra hij veranderd.
+Als laatste wordt de `post-merge` hook uitgevoerd na een succesvolle `merge` commando. Je kunt deze gebruiken om gegevens in de werkstructuur terug te zetten die Git niet kan ophalen, bijvoorbeeld permissie gegevens. Ook kan deze hook gebruikt worden om bestanden, die buiten het beheer van Git liggen, in je werkstructuur gekopieerd te krijgen zodra deze veranderd.
 
-### Server-kant haken ###
+### Hooks aan de server-kant ###
 
-Naast de client-kant haken, kun je als systeem administrator ook een paar belangrijke server-kant haken gebruiken om vrijwel ieder beleid op je project af te dwingen. Deze scripts worden voor en na de pushes op de server uitgevoerd. De pre haken kunnen met een ander getal dan nul eindigen om de push te weigeren en een foutmelding naar de client te sturen; je kunt een push beleid instellen dat zo complex is als je zelf wenst.
+Naast de hooks aan de client-kant, kun je als systeem beheerder ook een paar belangrijke hooks aan de server-kant gebruiken om vrijwel elk beleid op het project af te dwingen. Deze scripts worden voor en na de pushes op de server uitgevoerd. De pre hooks kunnen met een getal anders dan nul laten eindigen om de push te weigeren en een foutmelding naar de client te sturen; je kunt een push beleid instellen dat zo complex is als je zelf wenst.
 
 #### pre-receive en post-receive ####
 
-Het eerste script dat uitgevoerd wordt tijdens het afhandelen van een push van een client is `pre-receive`. Het aanvaardt een lijst van referenties die worden gepusht op stdin; als het eindigt met een andere waarde dan nul, worden ze allen geweigerd. Je kunt deze haak gebruiken om dingen te doen als valideren dat geen van de vernieuwde referenties een non-fast-forward is; of om te controleren dat de gebruiker die de push doet ook creatie, verwijder, of push toegang of toegang om vernieuwingen te pushen naar alle bestanden die ze proberen aan te passen met de push.
+Het eerste script dat uitgevoerd wordt tijdens het afhandelen van een push van een client is `pre-receive`. Het aanvaardt een lijst van referenties die worden gepusht van stdin; als het eindigt met een andere waarde dan nul, worden ze geen van allen geaccepteerd. Je kunt deze hook gebruiken om dingen te doen als valideren dat geen van de vernieuwde referenties een non-fast-forward is, of om te controleren dat de gebruiker die de push uitvoert creatie, verwijder, of push toegang heeft, of toegang om wijzigingen te pushen voor alle bestanden die ze proberen aan te passen met de push.
 
-De `post-receive` haak wordt uitgevoerd nadat het hele proces afgerond is, en hij kan gebruikt worden om andere services te vernieuwen of gebruikers te notificeren. Het aanvaardt dezelfde gegevens op stdin als de `pre-receive` haak. Voorbeelden zijn een e-mail sturen naar een lijst, een continue integratie server notificeren, of het vernieuwen van een ticket-volg systeem – je kunt zelfs de commit boodschappen doorlopen om te zien of er nog tickets zijn die moeten worden geopend, aangepast of afgesloten moeten worden. Dit script kan het push proces niet stoppen, maar de client verbreekt de connectie niet totdat het afgerond is; dus ben voorzichtig als je iets probeert te doen dat een lange tijd in beslag neemt.
+De `post-receive` hook wordt uitgevoerd nadat het hele proces afgerond is, en het kan gebruikt worden om andere services te vernieuwen of gebruikers te notificeren. Het aanvaardt dezelfde stdin gegevens als de `pre-receive` hook. Voorbeelden zijn een e-mail sturen naar een lijst, een continue integratie server notificeren of het vernieuwen van een ticket-volg systeem. Je kunt zelfs de commit boodschappen doorlopen om te zien of er nog tickets zijn die moeten worden geopend, aangepast of afgesloten worden. Dit script kan het push proces niet stoppen, maar de client verbreekt de connectie niet totdat het afgerond is, wees dus een voorzichtig als je iets probeert te doen dat een lange tijd in beslag neemt.
 
 #### update ####
 
-Het update script is vergelijkbaar met het `pre-receive` script, behalve dan dat het uitgevoerd wordt voor iedere branch die de pusher probeert te vernieuwen. Als de pusher naar meerdere branches probeert te pushen, wordt `pre-receive` slechts één keer uitgevoerd, maar `update` bij iedere branch waar ze naar pushen. In plaats van stdin te lezen, aanvaardt dit script drie argumenten: de naam van de referentie (branch), de SHA-1 waar die referentie naar wees voor de push, en de SHA-1 die de gebruiker probeert te pushen. Als het update script met een andere waarde dan nul eindigt, wordt alleen die referentie geweigerd; andere referenties kunnen nog steeds vernieuwd worden.
+Het update script is vergelijkbaar met het `pre-receive` script, behalve dat het uitgevoerd wordt voor iedere branch die de pusher probeert te vernieuwen. Als de pusher naar meerdere branches probeert te pushen wordt `pre-receive` slechts één keer uitgevoerd, daarentegen loopt `update` bij iedere branch waar ze naar pushen. In plaats van stdin te lezen, aanvaardt dit script drie argumenten: de naam van de referentie (branch), de SHA-1 waar die referentie naar wees vóór de push, en de SHA-1 die de gebruiker probeert te pushen. Als het update script met een andere waarde dan nul eindigt, wordt alleen die referentie geweigerd; andere referenties kunnen nog steeds vernieuwd worden.
 
 ## Een voorbeeld van Git-afgedwongen beleid ##
 
-In dit gedeelte zul je gebruiken wat je geleerd hebt om een Git werkwijze vast te leggen, die controleert op een eigengemaakt commit boodschap formaat, afdwingt om alleen fast-forward pushes te accepteren, en alleen bepaalde gebruikers toestaat om bepaalde submappen te wijzigen in een project. Je zult client scripts maken die de ontwikkelaar helpen er achter te komen of hun push geweigerd zal worden, en server scripts die het beleid afdwingen.
+In deze paragraaf ga je gebruiken wat je geleerd hebt om een Git werkwijze te maken, die controleert op een niet standaard commit boodschap formaat, afdwingt om alleen fast-forward pushes te accepteren en alleen bepaalde gebruikers toestaat om bepaalde subdirectories te wijzigen in een project. Je zult client scripts maken die de ontwikkelaar helpen te ontdekken of hun push geweigerd zal worden en server scripts die het beleid afdwingen.
 
-Ik heb Ruby gebruikt om ze te schrijven, zowel omdat het mijn voorkeur script taal is en omdat ik vind dat het de meest pseudo code uitziende taal is van de scripttalen; dus je zou in staat moeten zijn om de code redelijk te kunnen volgen zelfs als je geen Ruby gebruikt. Maar, iedere taal zal prima werken. Alle voorbeeld haak scripts die met Git meegeleverd worden zijn Perl of Bash scripts, dus je kunt ook genoeg voorbeelden van haken in die talen zijn door naar de voorbeelden te kijken.
+Ik heb Ruby gebruikt om ze te schrijven, zowel omdat het mijn voorkeur script taal is als omdat ik vind dat het de meest pseudo code uitziende taal is van de scripttalen; dus je zou in staat moeten zijn om de code redelijk te kunnen volgen zelfs als je geen Ruby gebruikt. Maar elke taal zou prima werken. Alle voorbeeld hook scripts die met Git meegeleverd worden zijn Perl of Bash scripts, dus je kunt ook genoeg voorbeelden van hooks in die talen vinden door naar die bestanden te kijken.
 
-### Server-kant haak ###
+### Server-kant hook ###
 
-Al het werk aan de server kant zal in het update bestand in je haken map gaan. Het update bestand zal eens per gepushte branch uitgevoerd worden en aanvaardt de referentie waarnaar gepusht wordt, de oude revisie waar die branch was, en de nieuwe gepushte revisie. Je hebt ook toegang tot de gebruiker die de push doet, als de push via SSH gedaan wordt. Als je iedereen hebt toegestaan om connectie te maken als één gebruiker (zoals "git") via publieke sleutel authenticatie, dan moet je misschien die gebruiker een shell wrapper geven die bepaalt welke gebruiker er connectie maakt op basis van de publieke sleutel, en een omgevingsvariabele instelt met daarin die gebruiker. Hier ga ik er vanuit dat de gebruiker in de `$USER` omgevingsvariabele staat, dus begint je update script met het verzamelen van alle gegevens die het nodig heeft:
+Al het werk aan de server kant zal in het update bestand in je hooks directory gaan. Het update bestand zal eens per gepushte branch uitgevoerd worden en aanvaardt de referentie waarnaar gepusht wordt, de oude revisie waar die branch was en de nieuwe gepushte revisie. Je hebt ook toegang tot de gebruiker die de push doet als de push via SSH gedaan wordt. Als je iedereen hebt toegestaan om connectie te maken als één gebruiker (zoals "git") via publieke sleutel authenticatie, dan moet je wellicht die gebruiker een shell wrapper geven die bepaalt welke gebruiker er connectie maakt op basis van de publieke sleutel, en dan een omgevingsvariabele instellen waarin die gebruiker wordt gespecificeerd. Ik ga er vanuit dat de gebruiker in de `$USER` omgevingsvariabele staat, dus begint je update script met het verzamelen van alle gegevens die het nodig heeft:
 
 	#!/usr/bin/env ruby
 
@@ -557,13 +621,13 @@ Al het werk aan de server kant zal in het update bestand in je haken map gaan. H
 
 	puts "Enforcing Policies... \n(#{$refname}) (#{$oldrev[0,6]}) (#{$newrev[0,6]})"
 
-Ja, ik gebruik een globale variabele. Veroordeel me niet – het is makkelijker om het op deze manier te laten zien.
+Ja, ik gebruik globale variabelen. Veroordeel me niet – het is makkelijker om het op deze manier te laten zien.
 
 #### Een specifiek commit-bericht formaat afdwingen ####
 
-Je eerste uitdaging is afdwingen dat ieder commit bericht moet voldoen aan een specifiek formaat. Om maar een doel te hebben, gaan we er vanuit dat ieder bericht een stuk tekst bevat dat eruit ziet asl "ref: 1234", omdat je wil dat iedere commit gekoppeld is aan een werkonderdeel in je ticket systeem. Je moet kijken naar iedere commit die gepusht wordt, zien dat die tekst in de commit boodschap zit, en als de tekst niet in één van de commits zit, met niet nul eindigen zodat de push geweigerd wordt.
+Je eerste uitdaging is afdwingen dat elke commit bericht moet voldoen aan een specifiek formaat. Laten we zeggen dat ieder bericht een stuk tekst moet bevatten dat eruit ziet als "ref: 1234", omdat je wilt dat iedere commit gekoppeld is aan een werkonderdeel in je ticket systeem. Je moet dus kijken naar iedere commit die gepusht wordt, zien of die tekst in de commit boodschap zit en als de tekst in één van de commits ontbreekt, met niet nul eindigen zodat de push geweigerd wordt.
 
-Je kunt de lijst met alle SHA-1 waarden van alle commits die gepusht worden verkrijgen door de `$newrev` en `$oldrev` waarden te pakken en ze aan een Git sanitaire voorzieningen commando genaamd `git rev-list` te geven. Dit is eigenlijk het `git log` commando, maar standaard voert het alleen de SHA-1 waarden uit en geen andere informatie. Dus, om een lijst te krijgen van alle commit SHA's die worden geïntroduceerd tussen één commit SHA en een andere, kun je zoiets als dit uitvoeren:
+Je kunt de lijst met alle SHA-1 waarden van alle commits die gepusht worden verkrijgen door de `$newrev` en `$oldrev` waarden te pakken en ze aan een Git sanitaire-voorzieningen (plumbing) commando genaamd `git rev-list` te geven. Dit is min of meer het `git log` commando, maar standaard voert het alleen de SHA-1 waarden uit en geen andere informatie. Dus, om een lijst te krijgen van alle commit SHA's die worden geïntroduceerd tussen één commit SHA en een andere, kun je zoiets als dit uitvoeren:
 
 	$ git rev-list 538c33..d14fc7
 	d14fc7c847ab946ec39590d87783c69b031bdfb7
@@ -572,9 +636,9 @@ Je kunt de lijst met alle SHA-1 waarden van alle commits die gepusht worden verk
 	dfa04c9ef3d5197182f13fb5b9b1fb7717d2222a
 	17716ec0f1ff5c77eff40b7fe912f9f6cfd0e475
 
-Je kunt die uitvoer pakken, door ieder van die commit SHA's heen lopen, de boodschap daarvan pakken, en die boodschap testen tegen een reguliere expressie die op een bepaald patroon zoekt.
+Je kunt die uitvoer pakken, door elk van die commit SHA's heen lopen, de boodschap daarvan pakken en die boodschap testen tegen een reguliere expressie die op een bepaald patroon zoekt.
 
-Je moet uit zien te vinden hoe je de commit boodschap kunt krijgen van alle te testen commits. Om de rauwe commit gegevens te krijgen, kun je een andere sanitaire voorzieningen commando genaamd `git cat-file` gebruiken. Ik zal al deze sanitaire voorzieningen commando's behandelen in detail in Hoofdstuk 9; maar voor nu is dit wat het commando je geeft:
+Je moet uit zien te vinden hoe je de commit boodschap kunt krijgen van alle te testen commits. Om de echte commit gegevens te krijgen, kun je een andere sanitaire-voorzieningen commando genaamd `git cat-file` gebruiken. Ik zal al deze sanitaire-voorzieningen commando's in detail behandelen in Hoofdstuk 9, maar voor nu is dit wat het commando je geeft:
 
 	$ git cat-file commit ca82a6
 	tree cfda3bf379e4f8dba8717dee55aab78aef7f4daf
@@ -589,11 +653,11 @@ Een simpele manier om de commit boodschap te krijgen van een commit waarvan je d
 	$ git cat-file commit ca82a6 | sed '1,/^$/d'
 	changed the version number
 
-Je kunt die spreuk gebruiken om de commit boodschap te pakken van iedere commit die probeert te worden gepusht en eindigen als je ziet dat er iets is wat niet past. Om het script te eindigen en de push te weigeren, eindig je met niet nul. De hele methode ziet er zo uit:
+Je kunt die toverspreuk gebruiken om de commit boodschap te pakken van iedere commit die geprobeerd wordt te pushen en eindigen als je ziet dat er iets is wat niet past. Om het script te eindigen en de push te weigeren, eindig je met niet nul. De hele methode ziet er zo uit:
 
 	$regex = /\[ref: (\d+)\]/
 
-	# afgedwongen eigen commit bericht formaat
+	# eigen commit bericht formaat afgedwongen
 	def check_message_format
 	  missed_revs = `git rev-list #{$oldrev}..#{$newrev}`.split("\n")
 	  missed_revs.each do |rev|
@@ -606,15 +670,15 @@ Je kunt die spreuk gebruiken om de commit boodschap te pakken van iedere commit
 	end
 	check_message_format
 
-Door dat in je `update` script te stoppen, zal het updates weigeren die commits bevatten die berichten hebben die niet aan je regel voldoen.
+Door dat in je `update` script te stoppen, zal het updates weigeren die commits bevatten die berichten hebben die niet aan jouw regel voldoen.
 
 #### Een gebruiker-gebaseerd ACL systeem afdwingen ####
 
-Stel dat je een mechanisme wil toevoegen dat gebruik maakt van een toegangscontrole lijst (ACL) die specificeert welke gebruikers zijn toegestaan om wijzigingen te pushen naar welke delen van je project. Sommige mensen hebben volledige toegang, en andere hebben alleen toegang om wijzigingen te pushen naar bepaalde submappen of specifieke bestanden. Om dit af te dwingen zul je die regels schrijven in een bestand genaamd `acl` dat in je bare Git repository op de server leeft. Je zult de `update` haak naar die regels laten kijken, zien welke bestanden worden geïntroduceerd voor alle commits die gepusht worden, en bepalen of de gebruiker die de push doet toegang heeft om al die bestanden te wijzigen.
+Stel dat je een mechanisme wil toevoegen dat gebruik maakt van een toegangscontrole lijst (ACL) die specificeert welke gebruikers zijn toegestaan om wijzigingen te pushen naar bepaalde delen van je project. Sommige mensen hebben volledige toegang, en anderen hebben alleen toestemming om wijzigingen te pushen naar bepaalde subdirectories of specifieke bestanden. Om dit af te dwingen zul je die regels schrijven in een bestand genaamd `acl` dat in je bare Git repository op de server zit. Je zult de `update` hook naar die regels laten kijken, zien welke bestanden worden geïntroduceerd voor elke commit die gepusht wordt en bepalen of de gebruiker die de push doet toestemming heeft om al die bestanden te wijzigen.
 
-Het eerste dat je zult doen is je ACL schrijven. Hier zul je een formaat gebruiken dat erg lijkt op het CVS ACL mechanisme: het gebruikt een serie regels, waarbij het eerste veld `avail` of `unavail` is, het volgende veld een komma gescheiden lijst van de gebruikers is waarvoor de regel geldt, en het laatste veld het pad is waarvoor de regel geldt (leeg betekent open toegang). Alle velden worden gescheiden door een pipe (`|`) karakter.
+Het eerste dat je zult doen is de ACL schrijven. Hier zul je een formaat gebruiken wat erg lijkt op het CVS ACL mechanisme: het gebruikt een serie regels, waarbij het eerste veld `avail` of `unavail` is, het volgende veld een komma gescheiden lijst van de gebruikers is waarvoor de regel geldt en het laatste veld het pad is waarvoor deze regel geldt (leeg betekent open toegang). Alle velden worden gescheiden door een pipe (`|`) karakter.
 
-In dit geval heb je een aantal administrators, een aantal documentatie schrijvers met toegang tot de `doc` map, en één ontwikkelaar die alleen toegang heeft tot de `lib` en `test` mappen, en je ACL bestand ziet er zo uit:
+In dit geval heb je een aantal beheerders, een aantal documentatie schrijvers met toegang tot de `doc` map, en één ontwikkelaar die alleen toegang heeft tot de `lib` en `test` mappen, en je ACL bestand ziet er zo uit:
 
 	avail|nickh,pjhyett,defunkt,tpw
 	avail|usinclair,cdickens,ebronte|doc
@@ -638,7 +702,7 @@ Je begint met het lezen van deze gegevens in een structuur die je kunt gebruiken
 	  access
 	end
 
-Op het ACL bestand dat je eerder bekeken hebt, zal deze `get_acl_access_data` methode een gegevens structuur teruggeven die er zo uit ziet:
+Gegeven het ACL bestand dat je eerder bekeken hebt, zal deze `get_acl_access_data` methode een gegevensstructuur opleveren die er als volgt uit ziet:
 
 	{"defunkt"=>[nil],
 	 "tpw"=>[nil],
@@ -649,22 +713,22 @@ Op het ACL bestand dat je eerder bekeken hebt, zal deze `get_acl_access_data` me
 	 "usinclair"=>["doc"],
 	 "ebronte"=>["doc"]}
 
-Nu dat je de rechten bepaald hebt, moet je bepalen welke paden de commits die gepusht worden hebben aangepast, zodat je er zeker van kunt zijn dat de gebruiker die de push doet daar ook toegang tot heeft.
+Nu je de rechten bepaald hebt, moet je bepalen welke paden de commits die gepusht worden hebben aangepast, zodat je kunt controleren dat de gebruiker die de push doet daar ook toegang tot heeft.
 
-Je kunt eenvoudig zien welke bestanden gewijzigd zijn in een enkele commit met de `--name-only` optie op het `git log` commando (dat kort genoemd wordt in Hoofdstuk 2):
+Je kunt eenvoudig zien welke bestanden gewijzigd zijn in een enkele commit met de `--name-only` optie op het `git log` commando (kort besproken in Hoofdstuk 2):
 
 	$ git log -1 --name-only --pretty=format:'' 9f585d
 
 	README
 	lib/test.rb
 
-Als je gebruik maakt van de ACL structuur die wordt teruggegeven door de `get_acl_access_data` methode en dat controleert met de bestanden in elk van de commits, dan kun je bepalen of de gebruiker toegang heeft om al hun commits te pushen:
+Als je gebruik maakt van de ACL structuur die wordt teruggegeven door de `get_acl_access_data` methode en dat gebruikt met de bestanden in elk van de commits, dan kun je bepalen of de gebruiker toegang heeft om al hun commits te pushen:
 
-	# staat alleen bepaalde gebruikers toe om bepaalde submappen in een project te wijzigen
+	# staat alleen bepaalde gebruikers toe om bepaalde subdirectories in een project te wijzigen
 	def check_directory_perms
 	  access = get_acl_access_data('acl')
 
-	  # zie of iemand iets probeert te pushen dat ze niet mogen
+	  # kijk of iemand iets probeert te pushen waar ze niet bij mogen komen
 	  new_commits = `git rev-list #{$oldrev}..#{$newrev}`.split("\n")
 	  new_commits.each do |rev|
 	    files_modified = `git log -1 --name-only --pretty=format:'' #{rev}`.split("\n")
@@ -687,17 +751,17 @@ Als je gebruik maakt van de ACL structuur die wordt teruggegeven door de `get_ac
 
 	check_directory_perms
 
-Het meeste daarvan zou makkelijk te volgen moeten zijn. Je krijgt een lijst met commits die gepusht worden naar je server met `git rev-list`. Daarna vind je, voor iedere commit, de bestanden die aangepast worden en stelt vast of de gebruiker die pusht toegang heeft tot alle paden die worden aangepast. Een Ruby-isme dat wellicht niet duidelijk is is `path.index(access_path) == 0`, wat waar is als het pad begint met `access_path` – dit zorgt ervoor dat `access_path` niet slechts in één van de toegestane paden zit, maar dat een toegestaan pad begint met ieder aangeraakt pad.
+Het meeste daarvan zou makkelijk te volgen moeten zijn. Je krijgt een lijst met commits die gepusht worden naar je server met `git rev-list`. Daarna vind je, voor iedere commit de bestanden die aangepast worden en stelt vast of de gebruiker die pusht toegang heeft tot alle paden die worden aangepast. Een Ruby-isme dat wellicht niet duidelijk is, is `path.index(access_path) == 0`, wat waar is als het pad begint met `access_path` – dit zorgt ervoor dat `access_path` niet slechts in één van de toegestane paden zit, maar dat het voorkomt in alle toegestane paden.
 
-Nu kunnen je gebruikers geen commits pushen met slechte berichten of met aangepaste bestanden buiten hun toegewezen paden.
+Nu kunnen je gebruikers geen commits pushen met slecht vormgegeven berichten of met aangepaste bestanden buiten hun toegewezen paden.
 
 #### Fast-forward-only pushes afdwingen ####
 
-Het enige overgebleven ding om af te dwingen is fast-forward-only pushes. In Git versie 1.6 of nieuwer, kun je de `receive.denyDeletes` en `receive.denyNonFastForwards` instellingen aanpassen. Maar dit afdwingen met behulp van een haak werkt ook in oudere versies van Git, en je kunt het aanpassen zodat het alleen gebeurd bij bepaalde gebruikers of wat je later ook verzint.
+Het laatste om af te dwingen is fast-forward-only pushes. Om dit te regelen, kan je simpelweg de `receive.denyDeletes` en `receive.denyNonFastForwards` instellingen aanpassen. Maar dit afdwingen met behulp van een hook werkt ook, en je kunt het aanpassen zodat het alleen gebeurt bij bepaalde gebruikers of om elke reden die je later bedenkt.
 
-De logica om dit te controleren is zien of iedere commit die bereikbaar is vanuit de oudere revisie, niet bereikbaar is vanuit de nieuwere. Als er geen zijn, dan was het een fast-forward push; anders weiger je het:
+De logica om dit te controleren, is zien of er een commit is die bereikbaar is vanuit de oudere revisie, maar niet bereikbaar is vanuit de nieuwere. Als er geen zijn dan was het een fast-forward push, anders weiger je het:
 
-	# dwingt fast-forward only pushes af
+	# dwingt fast-forward-only pushes af
 	def check_fast_forward
 	  missed_refs = `git rev-list #{$newrev}..#{$oldrev}`
 	  missed_ref_count = missed_refs.split("\n").size
@@ -709,7 +773,7 @@ De logica om dit te controleren is zien of iedere commit die bereikbaar is vanui
 
 	check_fast_forward
 
-Alles is ingesteld. Als je `chmod u+x .git/hooks/update` uitvoert, wat het bestand is waarin je al deze code gestopt hebt, en dan probeert te pushen naar een non-fast-forwarded referentie, krijg je zoiets als dit:
+Alles is ingesteld. Als je `chmod u+x .git/hooks/update` uitvoert, wat het bestand is waarin je al deze code gestopt hebt, en dan probeert een non-fast-forwarded referentie te pushen  krijg je zoiets als dit:
 
 
 	$ git push -f origin master
@@ -727,12 +791,12 @@ Alles is ingesteld. Als je `chmod u+x .git/hooks/update` uitvoert, wat het besta
 	 ! [remote rejected] master -> master (hook declined)
 	error: failed to push some refs to 'git@gitserver:project.git'
 
-Er zijn hier een aantal interessante dingen. Ten eerste, zie je dit als de haak start met uitvoeren.
+Er zijn hier een aantal interessante dingen. Ten eerste, zie je dit als de hook start met uitvoeren.
 
 	Enforcing Policies...
 	(refs/heads/master) (fb8c72) (c56860)
 
-Zie dat je dat afgedrukt hebt naar stdout aan het begin van je update script. Het is belangrijk om te zien dat alles dat je script naar stdout uitvoert, naar de client overgebracht wordt.
+Merk op dat je dat afgedrukt hebt naar stdout aan het begin van je update script. Het is belangrijk om te zien dat alles dat je script naar stdout uitvoert, naar de client overgebracht wordt.
 
 Het volgende dat je op zal vallen is de foutmelding.
 
@@ -740,15 +804,15 @@ Het volgende dat je op zal vallen is de foutmelding.
 	error: hooks/update exited with error code 1
 	error: hook declined to update refs/heads/master
 
-De eerste regel was door jou afgedrukt, de andere twee waren Git die je vertelde dat het update script met niet nul eindigde en dat dat hetgeen is dat je push weigerde. Als laatste heb je dit:
+De eerste regel was door jou afgedrukt, de andere twee komen van Git die je vertelt dat het update script met niet nul geëindigd is en dat die degene is die je push weigerde. Tot slot heb je dit:
 
 	To git@gitserver:project.git
 	 ! [remote rejected] master -> master (hook declined)
 	error: failed to push some refs to 'git@gitserver:project.git'
 
-Je zult een remote weiger bericht zien voor iedere referentie die je haak weigerde, en het verteld je dat het specifiek was geweigerd omdat het een haak fout was.
+Je zult een remote weiger bericht zien voor elke referentie die door de hook wordt geweigerd, en het vertelt je dat het specifiek was geweigerd wegens een hook fout.
 
-Daarnaast zul je een foutmelding zien dat je uitvoert als de ref marker niet in één van je commits zit.
+Daarnaast zal je een foutmelding zien als in één van je commits de ref-marker ontbreekt.
 
 	[POLICY] Your message is not formatted correctly
 
@@ -757,15 +821,15 @@ Of als iemand een bestand probeert aan te passen waar ze geen toegang tot hebben
 
 	[POLICY] You do not have access to push to lib/test.rb
 
-Dat is alles. Vanaf nu, zolang als het `update` script aanwezig en uitvoerbaar is, zal je repository nooit teruggedraaid worden en zal nooit een commit bericht zonder je patroon erin bevatten, en je gebruikers zullen ingeperkt zijn.
+Dat is alles. Vanaf nu, zolang als het `update` script aanwezig en uitvoerbaar is, zal je repository nooit teruggedraaid worden en zal nooit een commit bericht bevattenb waar je patroon niet in zit, en je gebruikers zullen in hun bewegingsruimte beperkt zijn.
 
-### Client-kant haken ###
+### Hooks aan de client-kant ###
 
-Het nadeel hiervan is het zeuren dat geheid zal gebeuren zodra de commits van je gebruikers geweigerd worden. Het feit dat hun zorgzaam vervaardigde werk geweigerd wordt op het laatste moment kan enorm frustrerend en verwarrend zijn: daarnaast, zullen ze hun geschiedenis moeten aanpassen om het te corrigeren, wat niet altijd voor de mensen met een zwak hart is.
+Het nadeel van deze aanpak is het zeuren dat geheid zal beginnen zodra de commits van je gebruikers geweigerd worden. Het feit dat hun zorgzaam vervaardigde werk op het laatste moment pas geweigerd wordt kan enorm frustrerend en verwarrend zijn en daarnaast zullen ze hun geschiedenis moeten aanpassen om het te corrigeren, wat niet altijd geschikt is voor de wat angstiger aangelegde mensen.
 
-Het antwoord op dit dilemma is een aantal client-kant haken te leveren, die gebruikers kunnen toepassen om hen te waarschuwen dat ze iets doen dat de server waarschijnlijk gaat weigeren. Op die manier kunnen ze alle problemen corrigeren voordat ze gaan committen en voordat die problemen moeilijk te herstellen zijn. Omdat haken niet overgebracht worden bij het klonen van een project, moet je deze scripts op een andere manier distribueren en je gebruikers ze dan in hun `.git/hooks` map laten zetten en ze uitvoerbaar maken. Je kunt deze haken in je project of in een apart project distribueren, maar er is geen manier om ze automatisch in te laten stellen.
+Het antwoord op dit dilemma is een aantal client-kant hooks te leveren, die gebruikers kunnen gebruiken om hen te waarschuwen dat ze iets doen dat de server waarschijnlijk gaat weigeren. Op die manier kunnen ze alle problemen corrigeren voordat ze gaan committen en voordat die problemen lastiger te herstellen zijn. Omdat haken niet overgebracht worden bij het klonen van een project, moet je deze scripts op een andere manier distribueren en je gebruikers ze in hun `.git/hooks` map laten zetten en ze uitvoerbaar maken. Je kunt deze hooks in je project of in een apart project distribueren, maar er is geen manier om ze automatisch in te laten stellen.
 
-Om te beginnen zou je je commit boodschap moeten controleren, vlak voordat iedere commit opgeslagen wordt, zodat je weet dat de server je wijzigingen niet gaat weigeren omdat de commit boodschap een verkeerd formaat heeft. Om dit te doen, kun je de `commit-msg` haak toevoegen. Als je dat de commit boodschap laat lezen uit het bestand dat als eerste argument opgegeven wordt, en dat vergelijkt met het patroon, dan kun je Git forceren om de commit af te breken als er geen overeenkomst is:
+Om te beginnen zou je de commit boodschap moeten controleren vlak voordat iedere commit opgeslagen wordt, zodat je weet dat de server je wijzigingen niet gaat weigeren omdat de commit boodschap een verkeerd formaat heeft. Om dit te doen, kun je de `commit-msg` hook toevoegen. Als je dat de commit boodschap laat lezen uit het bestand dat als eerste argument opgegeven wordt, en dat vergelijkt met het patroon dan kun je Git dwingen om de commit af te breken als het niet juist is:
 
 	#!/usr/bin/env ruby
 	message_file = ARGV[0]
@@ -778,18 +842,18 @@ Om te beginnen zou je je commit boodschap moeten controleren, vlak voordat ieder
 	  exit 1
 	end
 
-Als dat script op z'n plaats staat (in `.git/hooks/commit-msg`) en uitvoerbaar is, en je commit met een verkeerd formaat bericht, dan zie je dit:
+Als dat script op z'n plaats staat (in `.git/hooks/commit-msg`), uitvoerbaar is en je commit met een verkeerd geformateerd bericht, dan zie je dit:
 
 	$ git commit -am 'test'
 	[POLICY] Your message is not formatted correctly
 
-In dat geval was er geen commit afgerond. Maar, als je bericht het juiste patroon bevat, dan staat Git je toe te committen:
+In dat geval is er geen commit gedaan. Maar als je bericht het juiste patroon bevat, dan staat Git je toe te committen:
 
 	$ git commit -am 'test [ref: 132]'
 	[master e05c914] test [ref: 132]
 	 1 files changed, 1 insertions(+), 0 deletions(-)
 
-Vervolgens wil je er zeker van zijn dat je geen bestanden buiten je ACL scope aanpast. Als de `.git` map van je project een kopie van het ACL bestand bevat dat je eerder gebruikte, dan zal het volgende `pre-commit` script die beperkingen op je toepassen:
+Vervolgens wil je er zeker van zijn dat je geen bestanden buiten je ACL scope aanpast. Als de `.git` directory van je project een kopie van het ACL bestand bevat dat je eerder gebruikte, dan zal het volgende `pre-commit` script die beperkingen voor je controleren:
 
 	#!/usr/bin/env ruby
 
@@ -818,7 +882,7 @@ Vervolgens wil je er zeker van zijn dat je geen bestanden buiten je ACL scope aa
 
 	check_directory_perms
 
-Dit is ongeveer hetzelfde script als aan de server kant, maar met twee belangrijke verschillen. Als eerste staat het ACL bestand op een andere plek, omdat dit script vanuit je werkmap draait, niet vanuit je Git map. Je moet het pad naar het ACL bestand wijzigen van dit
+Dit is bijna hetzelfde script als aan de server kant, maar met twee belangrijke verschillen. Als eerste staat het ACL bestand op een andere plek, omdat dit script vanuit je werkdirectory draait, en niet vanuit je Git directory. Je moet het pad naar het ACL bestand wijzigen van dit
 
 	access = get_acl_access_data('acl')
 
@@ -826,7 +890,7 @@ in dit:
 
 	access = get_acl_access_data('.git/acl')
 
-Het andere belangrijke verschil is de manier waarop je een lijst krijgt met bestanden die je gewijzigd hebt. Omdat de server kant methode naar de log van commits kijkt, en op dit punt je commit nog niet opgeslagen is, moet je je bestandslijst in plaats daarvan uit het stage gebied halen. In plaats van
+Het andere belangrijke verschil is de manier waarop je een lijst krijgt met bestanden die gewijzigd is. Omdat de server kant methode naar de log van commits kijkt en nu je commit nog niet opgeslagen is, moet je de bestandslijst in plaats daarvan uit het stage gebied halen. In plaats van
 
 	files_modified = `git log -1 --name-only --pretty=format:'' #{ref}`
 
@@ -834,14 +898,13 @@ moet je dit gebruiken
 
 	files_modified = `git diff-index --cached --name-only HEAD`
 
-Maar dat zijn de enige twee verschillen – voor de rest werkt het script op dezelfde manier. Een instinker is dat het van je verwacht dat je lokaal werkt als dezelfde gebruiker die pusht naar de remote machine. Als dat verschillend is, moet je de `$user` variabele handmatig instellen.
-
-Het laatste ding dat je moet doen is controleren dat je niet non-fast-forward referenties probeert te pushen, maar dat komt minder voor. Om een referentie te krijgen dat geen fast-forward is, moet je voorbij een commit rebasen die je al gepusht hebt, of een andere lokale branch naar dezelfde remote branch proberen te pushen.
+Maar dat zijn de enige twee verschillen, verder werkt het script op dezelfde manier. Een voorwaarde is dat het van je verlangt dat je lokaal werkt als dezelfde gebruiker die pushed naar de remote machine. Als dat anders is, moet je de `$user` variabele handmatig instellen.
 
-Omdat de server je zal vertellen dat je geen non-fast-forward push kunt doen, en de haak de push tegenhoudt, is het enige ongelukkige ding dat je kunt proberen te vangen het rebasen van commits die je al gepusht hebt.
+Het laatste wat je moet doen is het controleren dat je niet probeert non-fast-forward referenties te pushen, maar dat komt minder voor. Om een referentie te krijgen dat non-fast-forward is, moet je voorbij een commit rebasen die je al gepusht hebt, of een andere lokale branch naar dezelfde remote branch proberen te pushen.
 
+Omdat de server je zal vertellen dat je geen non-fast-forward push kunt doen, en de hook de push tegenhoudt, is het enige ding wat je kunt proberen af te vangen het abusievelijk rebasen van commits die je al gepusht hebt.
 
-Hier is een voorbeeld pre-rebase script dat daarop controleert. Het haalt een lijst met alle commits die je op het punt staat te herschrijven, en controleert of ze al op een bepaalde manier bestaan in één van je remote referenties. Als het er een ziet die bereikbaar is vanuit een van je remote referenties, dan stopt het de rebase:
+Hier is een voorbeeld pre-rebase script dat daarop controleert. Het haalt een lijst met alle commits die je op het punt staat te herschrijven, en controleert of ze al ergens bestaan in één van je remote referenties. Als het er een ziet die bereikbaar is vanuit een van je remote referenties, dan stopt het de rebase:
 
 	#!/usr/bin/env ruby
 
@@ -865,14 +928,14 @@ Hier is een voorbeeld pre-rebase script dat daarop controleert. Het haalt een li
 	  end
 	end
 
-Dit script gebruikt een syntax dat niet behandeld is in de Revisie Selectie sectie van Hoofdstuk 6. Je krijgt een lijst van commits die al gepusht zijn door dit uit te voeren:
+Dit script gebruikt een syntax dat niet behandeld is in de Revisie Selectie paragraaf van Hoofdstuk 6. Je krijgt een lijst van commits die al gepusht zijn door dit uit te voeren:
 
 	git rev-list ^#{sha}^@ refs/remotes/#{remote_ref}
 
-De `SHA^@` syntax wordt vervangen door alle ouders van die commit. Je bent aan het kijken naar iedere commit die bereikbaar is vanuit de laatste commit op de remote en die niet bereikbaar is vanuit elke ouder van de SHA's die je probeert te pushen – wat betekend dat het een fast-forward is.
+De `SHA^@` syntax wordt vervangen door alle ouders van die commit. Je bent op zoek naar een commit die bereikbaar is vanuit de laatste commit op de remote en die niet bereikbaar is vanuit enige ouder van alle SHA's die je probeert te pushen – wat inhoudt dat het een fast-forward is.
 
-Het grote nadeel van deze aanpak is dat het erg traag kan zijn en vaak onnodig is – als je de push niet probeert te forceren met de `-f` optie, dan zal de server je proberen te waarschuwen en de push niet accepteren. Maar, het is een aardige oefening en kan je in theorie helpen om een rebase te omzeilen die je later zult moeten herstellen.
+Het grote nadeel van deze aanpak is dat het erg traag kan zijn en vaak onnodig is, als je de push niet probeert te forceren met de `-f` optie, dan zal de server je al waarschuwen en de push niet accepteren. Maar, het is een aardige oefening en kan je in theorie helpen om een rebase te voorkomen die je later zult moeten herstellen.
 
 ## Samenvatting ##
 
-Je hebt nu de meeste manieren behandeld waarin je je Git client en server aan kunt passen om aan jouw werkwijze en projecten te voldoen. Je hebt over alle soorten configuratie instellingen geleerd, bestands-gebaseerde attributen, en gebeurtenis haken, en je hebt een voorbeeld server met een afgedwongen beleid gebouwd. Je zou nu in staat moeten zijn om Git bijna iedere werkwijze die je kunt verzinnen te laten doen.
+Je hebt nu de meeste manieren behandeld waarin je jouw Git client en server aan kunt passen om aan jouw werkwijze en projecten te voldoen. Je hebt allerhande configuratie instellingen geleerd, bestands-gebaseerde attributen, en gebeurtenis hooks (event hooks) en je hebt een voorbeeld gemaakt van een server die beleid afdwingt. Je zou nu in staat moeten zijn om Git bijna iedere werkwijze die je kunt verzinnen te laten doen.

From b909bfdff73d7c7ef21c6b3499038bb5e0eb3f7d Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Mon, 3 Feb 2014 10:18:03 -0600
Subject: [PATCH 161/690] Reviewing "Public Small Project"

---
 it/05-distributed-git/01-chapter5.markdown | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/it/05-distributed-git/01-chapter5.markdown b/it/05-distributed-git/01-chapter5.markdown
index a21356ba6..64f713342 100755
--- a/it/05-distributed-git/01-chapter5.markdown
+++ b/it/05-distributed-git/01-chapter5.markdown
@@ -385,7 +385,7 @@ Figura 5-15. Sequenza base di questo workflow con team separati.
 
 Contribuire ad un progetto pubblico è leggermente differente. Poiché non hai il permesso di aggiornare direttamente i rami del progetto, devi far avere il tuo lavoro ai mantenitori in qualche altro modo. Questo primo esempio descrive come contribuire con i fork su host Git che lo supportano in maniera semplice. I siti di repo.or.cz e GitHub lo supportano, e molti mantenitori di progetti si aspettano questo tipo di contribuzione. La sezione successiva tratta i progetti che preferiscono ricevere le patch per e-mail
 
-Innanzitutto, probabilemnte dovrai clonare il repository principale, creare un ramo per le modifiche che hai in programma di fare, e fare li il tuo lavoro. La sequenza è grosso modo questa:
+Per iniziare probabilemnte dovrai clonare il repository principale, creare un branch per le modifiche che programmi di fare, quindi lavorarci. La sequenza è grosso modo questa:
 
 	$ git clone (url)
 	$ cd project
@@ -395,13 +395,13 @@ Innanzitutto, probabilemnte dovrai clonare il repository principale, creare un r
 	$ (lavoro)
 	$ git commit
 
-Potresti voler usare `rebase -i` per ridurre il tuo lavoro ad un singolo commit, o riorganizzare il lavoro nei commit per rendere le modifiche semplice da controllare per il mantenitore - vedi il Capitolo 6 per altre informazioni sul rebasing interattivo.
+Potresti voler usare `rebase -i` per ridurre il tuo lavoro a una singola commit, o riorganizzare il lavoro delle commit per facilitare il lavoro di revisione dei mantenitori - vedi il Capitolo 6 per altre informazioni sul rebase interattivo.
 
-Quando il tuo lavoro sul ramo è completato e sei pronto per farlo avere ai mantenitori, vai alla pagina principale del progetto e clicca sul link "Fork", creando una tua copia scrivibile del progetto. Dovrai poi aggiungere questo nuovo URL di repository come secondo URL remoto, in questo caso chiamato `miofork`:
+Quando il lavoro sul tuo branch è completato e sei pronto per condividerlo con i mantenitori, vai alla pagina principale del progetto e clicca sul pulsante "Fork", creando la tua copia modificabile del progetto. Dovrai quindi aggiungere l'URL di questo nuovo repository come un secondo remoto, chiamato in questo caso `miofork`:
 
 	$ git remote add miofork (url)
 
-Dovrai eseguire un push del tuo lavoro verso esso. E' più semplice eseguire il push del ramo su cui stai lavorando piuttosto che unirlo al ramo master ed eseguire il push di quest'ultimo. La ragione è che se il tuo lavoro non è accettato, oppure lo è solo in parte, non dovrai tornare indietro nei commit sul tuo ramo master. Se i mantenitori uniscono, eseguono un rebase, o prendono pezzi dal tuo lavoro, riuscirai in ogni caso a recuperarlo eseguendo un pull dal loro repository:
+E dovrai eseguire una push del tuo lavoro verso il nuovo repository. È più semplice fare la push del branch a cui stai lavorando piuttosto che unirlo al tuo master e fare la push di quest'ultimo. La ragione è che se il tuo lavoro non verrà accettato, oppure lo sarà solo in parte, non dovrai ripristinare il tuo master. Se i mantenitori uniscono, fanno un rebase, o prendono pezzi dal tuo lavoro col cherry-pick, otterrai il nuovo master alla prossima pull dal loro repository:
 
 	$ git push myfork funzionalitaA
 

From 7d348e209fb5d07259bc72602e465dafba76cfee Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Mon, 3 Feb 2014 10:54:00 -0600
Subject: [PATCH 162/690] Reviewing "Public Small Project"

---
 it/05-distributed-git/01-chapter5.markdown | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/it/05-distributed-git/01-chapter5.markdown b/it/05-distributed-git/01-chapter5.markdown
index 64f713342..75f37dca7 100755
--- a/it/05-distributed-git/01-chapter5.markdown
+++ b/it/05-distributed-git/01-chapter5.markdown
@@ -405,9 +405,9 @@ E dovrai eseguire una push del tuo lavoro verso il nuovo repository. È più sem
 
 	$ git push myfork funzionalitaA
 
-Quando hai eseguito il push del tuo lavoro verso il tuo fork, devi farlo sapere al mantenitore. Questo passaggio è chiamato spesso richiesta di pull (pull request), e puoi farlo sia tramite il sito - GitHub ha un pulsante "pull request" che automaticamente notifica al mantenitore - o eseguire il comando `git request-pull` ed inviare l'output il mantenitore manualmente.
+Quando avrai eseguito la push del tuo lavoro sul tuo fork, devi avvisare i mantenitori. Questo passaggio viene spesso definito "richiesta di pull" (pull request), e puoi farlo tramite lo stesso sito - GitHub ha un pulsante "pull request" che automaticamente notifica i mantenitori - o eseguire il comando `git request-pull` e inviare manualmente via email l'output ai mantenitori.
 
-Il comando `request-pull` riceve come parametri il ramo base sul quale vuoi far applicare le modifiche ed l'URL del repository Git da cui vuoi estrarle, ed in output fornisce un riassunto di tutte queste modifiche. Per esempio, se Jessica volesse inviare a John una richiesta di pull, e lei ha eseguito due commit sul ramo di cui ha appena effettuato il push, può eseguire questo:
+Il comando `request-pull` riceve come parametri il branch di base sul quale vuoi far applicare le modifiche e l'URL del repository Git da cui vuoi che le prendano, e produce il sommario di tutte queste modifiche in output. Se, per esempio, Jessica volesse inviare a John una richiesta di pull, e avesse eseguito due commit sul branch di cui ha appena effettuato il push, può eseguire questo:
 
 	$ git request-pull origin/master miofork
 	The following changes since commit 1edee6b1d61823a2de3b09c160d7080b8d1b3a40:
@@ -425,9 +425,9 @@ Il comando `request-pull` riceve come parametri il ramo base sul quale vuoi far
 	 lib/simplegit.rb |   10 +++++++++-
 	 1 files changed, 9 insertions(+), 1 deletions(-)
 
-L'output può essere inviato al mantenitore. Esso riporta da dove è stato creato il nuovo ramo, un riassunto dei commit e dice da dove si può eseguire il pull.
+L'output può essere inviato ai mantenitori: riporta da dove è stato creato il nuovo branch, un riassunto delle commit e da dove si possono scaricare.
 
-Su un progetto dove non sei il mantenitore, è generalmente comune avere un ramo come `master` sempre collegato a `origin/master` ed eseguire il tuo lavoro su rami che puoi eliminare nel caso non venissero accettati. Avere il lavoro suddiviso in rami inoltre rende semplice per te eseguire il rebase del tuo lavoro se è stato modificato il repository principale ed i tuoi commit non possono venire applicati in maniera pulita. Per esempio, se vuoi aggiungere un secondo argomento di lavoro ad un progetto, non continuare a lavorare sul ramo di cui hai appena fatto il push - creane un altro partendo dal ramo `master` del repository:
+In un progetto dove non sei il mantenitore normalmente è comodo avere un branch come `master` sempre collegato a `origin/master` e lavorare su altri branch che puoi eliminare nel caso non venissero accettati. Suddividere il lavoro in branch ti rende più semplice ribasare il tuo lavoro se il repository principale è stato modificato e le tue commit non possono venire applicate in maniera pulita. Se per esempio vuoi aggiungere un'altra caratteristica al progetto, invece di continuare a lavorare sul branch di cui hai appena fatto la push, creane un altro partendo dal `master` del repository:
 
 	$ git checkout -b funzionalitaB origin/master
 	$ (lavoro)

From 1679be770e7a70a40f445ced669b2e52ac9f9431 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Mon, 3 Feb 2014 11:01:19 -0600
Subject: [PATCH 163/690] Reviewing "Public Small Project"

---
 it/05-distributed-git/01-chapter5.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/it/05-distributed-git/01-chapter5.markdown b/it/05-distributed-git/01-chapter5.markdown
index 75f37dca7..720824037 100755
--- a/it/05-distributed-git/01-chapter5.markdown
+++ b/it/05-distributed-git/01-chapter5.markdown
@@ -427,7 +427,7 @@ Il comando `request-pull` riceve come parametri il branch di base sul quale vuoi
 
 L'output può essere inviato ai mantenitori: riporta da dove è stato creato il nuovo branch, un riassunto delle commit e da dove si possono scaricare.
 
-In un progetto dove non sei il mantenitore normalmente è comodo avere un branch come `master` sempre collegato a `origin/master` e lavorare su altri branch che puoi eliminare nel caso non venissero accettati. Suddividere il lavoro in branch ti rende più semplice ribasare il tuo lavoro se il repository principale è stato modificato e le tue commit non possono venire applicate in maniera pulita. Se per esempio vuoi aggiungere un'altra caratteristica al progetto, invece di continuare a lavorare sul branch di cui hai appena fatto la push, creane un altro partendo dal `master` del repository:
+In un progetto dove non sei il mantenitore normalmente è comodo avere un branch come `master` sempre collegato a `origin/master` e lavorare su altri branch che puoi eliminare nel caso non venissero accettati. Suddividere il lavoro in branch per argomento ti rende più semplice ribasare il tuo lavoro se il repository principale è stato modificato e le tue commit non possono venire applicate in maniera pulita. Se per esempio vuoi aggiungere un'altra caratteristica al progetto, invece di continuare a lavorare sul branch di cui hai appena fatto la push, creane un altro partendo dal `master` del repository:
 
 	$ git checkout -b funzionalitaB origin/master
 	$ (lavoro)

From 04b2d6d444b72524f59d82145e0a6af891fc92d7 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Mon, 3 Feb 2014 11:05:23 -0600
Subject: [PATCH 164/690] Reviewing "Public Small Project"

---
 it/05-distributed-git/01-chapter5.markdown | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/it/05-distributed-git/01-chapter5.markdown b/it/05-distributed-git/01-chapter5.markdown
index 720824037..0e32465cb 100755
--- a/it/05-distributed-git/01-chapter5.markdown
+++ b/it/05-distributed-git/01-chapter5.markdown
@@ -436,10 +436,10 @@ In un progetto dove non sei il mantenitore normalmente è comodo avere un branch
 	$ (email al mantenitore)
 	$ git fetch origin
 
-Ora, ognuno dei tuoi lavori è separato, simile ad una coda di modifiche. Puoi riscrivere, modificare o effettuare un rebase, senza che i rami interferiscano o dipendano l'uno dall'altro, come in Figura 5-16.
+Ora ognuno dei tuoi lavori è separato come in una coda di modifiche che puoi riscrivere, ribasare e modificare senza che gli argomenti interferiscano o dipendano dagli altri, come in Figura 5-16.
 
 Insert 18333fig0516.png
-Figura 5-16. Conologia iniziale dei commit con del lavoro su funzionalitaB.
+Figura 5-16. Conologia iniziale col lavoro su funzionalitaB.
 
 Diciamo che il mantenitore del progetto ha eseguito il pull, una manciata di altre modifiche e provato il tuo primo ramo ma non riesce più ad applicare tali modifiche in maniera pulita. In questo caso, puoi provare ad effettuare un rebase di quel ramo basandoti sul nuovo `origin/master`, risolvere i conflitti e poi inviare di nuovo i tuoi cambiamenti:
 

From 536812c9979886f0c51b8a1055f0ee9849366bb3 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Mon, 3 Feb 2014 11:08:21 -0600
Subject: [PATCH 165/690] Reviewing "Public Small Project"

---
 it/05-distributed-git/01-chapter5.markdown | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/it/05-distributed-git/01-chapter5.markdown b/it/05-distributed-git/01-chapter5.markdown
index 0e32465cb..9f275c97d 100755
--- a/it/05-distributed-git/01-chapter5.markdown
+++ b/it/05-distributed-git/01-chapter5.markdown
@@ -441,16 +441,16 @@ Ora ognuno dei tuoi lavori è separato come in una coda di modifiche che puoi ri
 Insert 18333fig0516.png
 Figura 5-16. Conologia iniziale col lavoro su funzionalitaB.
 
-Diciamo che il mantenitore del progetto ha eseguito il pull, una manciata di altre modifiche e provato il tuo primo ramo ma non riesce più ad applicare tali modifiche in maniera pulita. In questo caso, puoi provare ad effettuare un rebase di quel ramo basandoti sul nuovo `origin/master`, risolvere i conflitti e poi inviare di nuovo i tuoi cambiamenti:
+Supponiamo che il mantenitore del progetto ha inserito una manciata di altre modifiche e provato il tuo primo branch ma non riesce più ad applicare tali modifiche in maniera pulita. In questo caso puoi provare a ribasare il nuovo `origin/master` su quel branch, risolvere i conflitti per poi inviare di nuovo le tue modifiche:
 
 	$ git checkout funzionalitaA
 	$ git rebase origin/master
 	$ git push –f miofork featureA
 
-Questo riscrive la tua cronologia per farla diventare come quella di Figura 5-17.
+Questo riscrive la tua cronologia per essere come quella di Figura 5-17.
 
 Insert 18333fig0517.png
-Fgiura 5-17. La cronologia dei commit dopo il lavoro su funzionalitaA.
+Fgiura 5-17. La cronologia ddopo il lavoro su funzionalitaA.
 
 Dato che hai eseguito un rebase del ramo, devi specificare l'opzione `-f` per eseguire un push, per poter sostituire il ramo `funzionalitaA` sul server con un commit che non discende da esso. Un'alternativa potrebbe essere un push di questo nuovo lavoro verso un diverso branch sul server (chiamato ad esempio `funzionalitaAv2`).
 

From 723b8342ec217f4d8bfc24125d12e39578071bd8 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Mon, 3 Feb 2014 11:23:03 -0600
Subject: [PATCH 166/690] Revied "Public Small Project"

---
 it/05-distributed-git/01-chapter5.markdown | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/it/05-distributed-git/01-chapter5.markdown b/it/05-distributed-git/01-chapter5.markdown
index 9f275c97d..f637601a7 100755
--- a/it/05-distributed-git/01-chapter5.markdown
+++ b/it/05-distributed-git/01-chapter5.markdown
@@ -452,9 +452,9 @@ Questo riscrive la tua cronologia per essere come quella di Figura 5-17.
 Insert 18333fig0517.png
 Fgiura 5-17. La cronologia ddopo il lavoro su funzionalitaA.
 
-Dato che hai eseguito un rebase del ramo, devi specificare l'opzione `-f` per eseguire un push, per poter sostituire il ramo `funzionalitaA` sul server con un commit che non discende da esso. Un'alternativa potrebbe essere un push di questo nuovo lavoro verso un diverso branch sul server (chiamato ad esempio `funzionalitaAv2`).
+Poiché hai eseguito un rebase del branch, per poter sostituire il branch `funzionalitaA` sul server con una commit che non discenda dallo stesso, devi usare l'opzione `-f` perché la push funzioni. Un'alternativa sarebbe fare una push di questo nuovo lavoro su un branch diverso (chiamato per esempio `funzionalitaAv2`).
 
-Diamo un'occhiata ad un possibile scenario: il mantenitore ha guardato al tuo lavoro in un secondo ramo, e gradisce il concetto ma vorrebbe che tu cambiassi dei dettagli dell'implementazione. Potresti inoltre cogliere questa opportunità per basarti sul ramo `master` corrente. Crei un nuovo ramo basato sul corrente `origin/master`, sposti i cambiamenti di `funzionalitaB` qui, risolvi i conflitti, cambi l'implementazione, e poi esegui il push come un nuovo ramo:
+Diamo un'occhiata a un altro scenario possibile: il mantenitore ha visto tuo lavoro nel secondo branch e gli piace il concetto ma vorrebbe che tu cambiassi un dettaglio dell'implementazione. Potresti cogliere l'occasione per ribasarti sul `master` corrente. Crea un nuovo branch basato sull'`origin/master` attuale, sposta lì le modifiche di `funzionalitaB`, risolvi gli eventuali conflitti, fai la modifica all'implementazione ed esegui la push del tutto su un nuovo branch:
 
 	$ git checkout -b funzionalitaBv2 origin/master
 	$ git merge --no-commit --squash funzionalitaB
@@ -462,12 +462,12 @@ Diamo un'occhiata ad un possibile scenario: il mantenitore ha guardato al tuo la
 	$ git commit
 	$ git push miofork funzionalitaBv2
 
-L'opzione `--squash` prende tutto il lavoro nel ramo da unire e lo aggiunge come un singolo commit al ramo in cui sei. L'opzione `no-commit` dice a Git di non eseguire automaticamente il commit. Questo ti consente di aggiungere i cambiamenti da un altro ramo e poi eseguire altre modifiche prima di effettuare il nuovo commit.
+L'opzione `--squash` prende tutto il lavoro dal branch da unire e lo aggiunge come una singola commit nel branch dove sei. L'opzione `--no-commit` dice a Git di non fare la commit automaticamente. Questo ti permette di aggiungere le modifiche di un altro branch e fare ulteriori modifiche prima di effettuare la nuovo commit.
 
-Ora puoi inviare al mantenitore un messaggio dicendo che hai effettuato i cambiamenti richiesti e che può trovare nel ramo `funzionalitaBv2` (vedi Figura 5-18).
+Ora puoi avvisare i mantenitori che hai effettuato le modifiche richieste e che possono trovarle nel branch `funzionalitaBv2` (vedi Figura 5-18).
 
 Insert 18333fig0518.png
-Figura 5-18. La cronologia dei commit dopo il lavoro su funzionalitaBv2.
+Figura 5-18. La cronologia dopo il lavoro su funzionalitaBv2.
 
 ### Grande Progetto Pubblico ###
 

From 8b13b617aa354ac2327b3befe84a0594d2930374 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Mon, 3 Feb 2014 12:02:01 -0600
Subject: [PATCH 167/690] Reviewing "Public Large Project"

---
 it/05-distributed-git/01-chapter5.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/it/05-distributed-git/01-chapter5.markdown b/it/05-distributed-git/01-chapter5.markdown
index f637601a7..76c08d2e2 100755
--- a/it/05-distributed-git/01-chapter5.markdown
+++ b/it/05-distributed-git/01-chapter5.markdown
@@ -471,7 +471,7 @@ Figura 5-18. La cronologia dopo il lavoro su funzionalitaBv2.
 
 ### Grande Progetto Pubblico ###
 
-Molti grandi progetti hanno definito delle procedure da seguire per poter inviare delle patch. Avrai bisogno di leggere le specifiche regole di ogni progetto, perchè queste potranno differire tra loro. Tuttavia, molti grandi progetti pubblici accettano patch tramite una mailing list degli sviluppatori, quindi tratterò ora un esempio di questo genere.
+Molti grandi progetti hanno definito delle procedure per l'invio delle patch: dovrai leggere le specifiche di ciascun progetto, perchè saranno diverse. Tuttavia molti grandi progetti pubblici accettano patch tramite la mailing list degli sviluppatori, quindi tratterò ora questo caso.
 
 Il flusso di lavoro è simile ai casi precedenti: crei un ramo per ognuna delle modifiche sulle quali intendi lavorare. La differenza sta in come invii tali modifiche al progetto. Invece di fare un tuo fork del progetto e di inviare le tue modifiche ad esso tramite push, crei una versione e-mail di ognuno dei commit e l invii tramite posta elettronica alla mailing list degli sviluppatori:
 

From 5fd61afef7fd1b0b09e2a27ac89445b8799579b8 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Mon, 3 Feb 2014 12:03:57 -0600
Subject: [PATCH 168/690] Reviewing "Public Large Project"

---
 it/05-distributed-git/01-chapter5.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/it/05-distributed-git/01-chapter5.markdown b/it/05-distributed-git/01-chapter5.markdown
index 76c08d2e2..8d209b772 100755
--- a/it/05-distributed-git/01-chapter5.markdown
+++ b/it/05-distributed-git/01-chapter5.markdown
@@ -473,7 +473,7 @@ Figura 5-18. La cronologia dopo il lavoro su funzionalitaBv2.
 
 Molti grandi progetti hanno definito delle procedure per l'invio delle patch: dovrai leggere le specifiche di ciascun progetto, perchè saranno diverse. Tuttavia molti grandi progetti pubblici accettano patch tramite la mailing list degli sviluppatori, quindi tratterò ora questo caso.
 
-Il flusso di lavoro è simile ai casi precedenti: crei un ramo per ognuna delle modifiche sulle quali intendi lavorare. La differenza sta in come invii tali modifiche al progetto. Invece di fare un tuo fork del progetto e di inviare le tue modifiche ad esso tramite push, crei una versione e-mail di ognuno dei commit e l invii tramite posta elettronica alla mailing list degli sviluppatori:
+Il flusso di lavoro è simile al caso precedente: crei un branch per ognuna delle modifiche sulle quali intendi lavorare. La differenza sta nel modo in cui invii tali modifiche al progetto. Invece di fare un tuo fork del progetto e di inviare le tue modifiche con una push, crei una versione e-mail di ogni commit e invii il tutto per email alla mailing list degli sviluppatori:
 
 	$ git checkout -b topicA
 	$ (work)

From 5bfefdba259324bc348f8ff99ceef1cbb249e2cf Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Mon, 3 Feb 2014 12:19:53 -0600
Subject: [PATCH 169/690] Reviewing "Public Large Project"

---
 it/05-distributed-git/01-chapter5.markdown | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/it/05-distributed-git/01-chapter5.markdown b/it/05-distributed-git/01-chapter5.markdown
index 8d209b772..0ccc3ab3e 100755
--- a/it/05-distributed-git/01-chapter5.markdown
+++ b/it/05-distributed-git/01-chapter5.markdown
@@ -481,13 +481,13 @@ Il flusso di lavoro è simile al caso precedente: crei un branch per ognuna dell
 	$ (work)
 	$ git commit
 
-Ora hai due commit che vuoi inviare alla mailing list. Usi `git format-patch` per generare un file formato mbox che puoi inviare via e-mail alla mailing list. Il comando `git format-patch` trasforma ogni commit in un messaggio email il cui oggetto è formato dalla prima linea del messaggio del commit e il cui contenuto è il rimanente testo del commit più la patch delle modifiche. La cosa bella di tutto ciò è che applicando i commit da un'email si conservano tutte le informazioni in essi contenute in maniera appropriata, come vedrai meglio nella prossima sezione:
+Ora hai due commit che vuoi inviare alla mailing list. Usi `git format-patch` per generare un file formato mbox che possa inviare via e-mail alla lista: questo trasforma ogni commit in un messaggio email il cui oggetto è la prima linea del messaggio della commit e il contenuto è dato dal resto del messaggio della commit più la patch delle modifiche. La cosa bella di tutto ciò è che, applicando le commit da un'email, vengono mantenute le informazioni delle commit, come vedrai meglio nella prossima sezione:
 
 	$ git format-patch -M origin/master
 	0001-add-limit-to-log-function.patch
 	0002-changed-log-output-to-30-from-25.patch
 
-Il comando `format-patch` visualizza i nomi dei file patch che vengono creati. Il parametro `-M` indica a Git di tener traccia dei file rinominati. I file infine hanno questo aspetto:
+Il comando `format-patch` visualizza i nomi dei file delle patch che crea. Il parametro `-M` indica a Git di tener traccia dei file rinominati. I file alla fine avranno questo aspetto:
 
 	$ cat 0001-add-limit-to-log-function.patch
 	From 330090432754092d704da8e76ca5c05c198e71a8 Mon Sep 17 00:00:00 2001
@@ -517,7 +517,7 @@ Il comando `format-patch` visualizza i nomi dei file patch che vengono creati. I
 	--
 	1.6.2.rc1.20.g8c5b.dirty
 
-Puoi anche modificare questi file patch per aggiungere maggiori informazioni per la mailing list che non vuoi vengano visualizzate all'interno del messaggio del commit. Se aggiungi del testo tra le righe contrassegnate da `---` e l'inizio della patch (ad esempio la riga `lib/simplegit.rb`), gli sviluppatori possono leggerlo ma esso verrà escluso dal messaggio del commit con il quale la patch verrà applicata.
+Puoi anche modificare questi file per aggiungere maggiori informazioni per la mailing list che però non vuoi che vengano visualizzate all'interno del messaggio della commit. Se aggiungi del testo tra la riga con `---` e l'inizio della patch (ad esempio la riga `lib/simplegit.rb`), gli sviluppatori potranno leggerlo ma verrà escluso dal messaggio della commit una volta che la patch sarà applicata.
 
 Per inviare le patch alla mailing list, puoi copiare ed incollare il file nel tuo programma di posta o inviare il tutto tramite un programma a linea di comando. Incollando il testo spesso si hanno dei problemi di formattazione, sopratutto con client di posta "intelligenti" che non preservano i caratteri di acapo e altri caratteri di spaziatura. Fortunatamente, Git fornisce uno strumento per aiutarti ad inviare le patch in modo corretto tramite IMAP, il che potrebbe risultare più semplice. Ti mostrerò come inviare una patch via Gmail, che è il client di posta che utilizzo io; puoi trovare le istruzioni dettagliate per diversi client di posta alla fine del documento `Documention/SubmittingPatches` presente nel codice sorgente di Git.
 

From 757615a88d18f259021d6a4f2ab22466f9f364e2 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Mon, 3 Feb 2014 14:01:05 -0600
Subject: [PATCH 170/690] Reviewed "Public Large Project"

---
 it/05-distributed-git/01-chapter5.markdown | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/it/05-distributed-git/01-chapter5.markdown b/it/05-distributed-git/01-chapter5.markdown
index 0ccc3ab3e..ffedbe393 100755
--- a/it/05-distributed-git/01-chapter5.markdown
+++ b/it/05-distributed-git/01-chapter5.markdown
@@ -519,9 +519,9 @@ Il comando `format-patch` visualizza i nomi dei file delle patch che crea. Il pa
 
 Puoi anche modificare questi file per aggiungere maggiori informazioni per la mailing list che però non vuoi che vengano visualizzate all'interno del messaggio della commit. Se aggiungi del testo tra la riga con `---` e l'inizio della patch (ad esempio la riga `lib/simplegit.rb`), gli sviluppatori potranno leggerlo ma verrà escluso dal messaggio della commit una volta che la patch sarà applicata.
 
-Per inviare le patch alla mailing list, puoi copiare ed incollare il file nel tuo programma di posta o inviare il tutto tramite un programma a linea di comando. Incollando il testo spesso si hanno dei problemi di formattazione, sopratutto con client di posta "intelligenti" che non preservano i caratteri di acapo e altri caratteri di spaziatura. Fortunatamente, Git fornisce uno strumento per aiutarti ad inviare le patch in modo corretto tramite IMAP, il che potrebbe risultare più semplice. Ti mostrerò come inviare una patch via Gmail, che è il client di posta che utilizzo io; puoi trovare le istruzioni dettagliate per diversi client di posta alla fine del documento `Documention/SubmittingPatches` presente nel codice sorgente di Git.
+Per inviare le patch alla mailing list, puoi copiare ed incollare il file nel tuo programma di posta o inviare il tutto dalla riga di comando. Incollare il testo è spesso causa di problemi di formattazione, sopratutto con i client di posta "intelligenti" che non mantengono correttamente i caratteri di a-capo e altri caratteri di spaziatura. Fortunatamente Git fornisce uno strumento che ti aiuta a inviare correttamente le patch tramite IMAP, che potrebbe facilitarti il compito. Ti mostrerò come mandare una patch con Gmail perché è il client di posta che utilizzo, ma troverai istruzioni dettagliate per molti client di posta alla fine del documento `Documention/SubmittingPatches`, che trovi nel codice sorgente di Git.
 
-Prima di tutto, devi configurare la sezione imap nel tuo file `~/.gitconfig`. Puoi settare ogni valore separatamente con una serie di comandi `git config` o aggiungerli manualmente al suo interno tramite un editor di testo. Alla fine il tuo file di configurazione dovrebbe essere più o meno così:
+Prima di tutto devi configurare la sezione imap nel tuo file `~/.gitconfig`. Puoi configurare ogni parametro separatamente con una serie di comandi `git config` o scriverli direttamente con un editor di testo. Alla fine il tuo file di configurazione dovrebbe comunque essere più o meno così:
 
 	[imap]
 	  folder = "[Gmail]/Drafts"
@@ -531,7 +531,7 @@ Prima di tutto, devi configurare la sezione imap nel tuo file `~/.gitconfig`. Pu
 	  port = 993
 	  sslverify = false
 
-Se il tuo server IMAP non usa SSL, le ultime due righe probabilmente non ti saranno necessarie e il valore del campo host sarà `imap://` anzichè `imaps://`. Quando tutto ciò è configurato, puoi usare `git send-email` per inviare la serie di patch alla cartella "Bozze" del tuo server IMAP:
+Se il tuo server IMAP non usa SSL, probabilmente le ultime due righe non ti saranno necessarie e il valore del campo host sarà `imap://` invece di `imaps://`. Quando avrai configurato tutto, potrai usare `git send-email` per inviare la serie di patch alla cartella "Bozze" del tuo server IMAP:
 
 	$ git send-email *.patch
 	0001-added-limit-to-log-function.patch
@@ -541,7 +541,7 @@ Se il tuo server IMAP non usa SSL, le ultime due righe probabilmente non ti sara
 	Who should the emails be sent to? jessica@example.com
 	Message-ID to be used as In-Reply-To for the first email? y
 
-Poi, Git produce alcune informazioni di log che figureranno più o meno così per ogni patch che stai inviando:
+Per ciascuna patch che stai per inviare, Git produce alcune informazioni di log che appariranno più o meno così:
 
 	(mbox) Adding cc: Jessica Smith <jessica@example.com> from
 	  \line 'From: Jessica Smith <jessica@example.com>'
@@ -558,7 +558,7 @@ Poi, Git produce alcune informazioni di log che figureranno più o meno così pe
 
 	Result: OK
 
-A questo punto, dovresti essere in grado di andare nella tua cartella delle bozze, cambiare il campo "A:" con la mailing list alla quale vuoi inviare la patch, aggiungere in copia il mantenitore del progetto o la persona responsabile per quella determinata sezione ed inviare il codice.
+A questo punto, dovresti essere in grado di andare nella cartella bozze del tuo account, inserire nel campo "A:" la mailing list alla quale vuoi inviare la patch, magari aggiungendo in copia il mantenitore del progetto o la persona responsabile per quella determinata sezione e manda l'email.
 
 ### Sommario ###
 

From e00b315fdd17693af57b08b375a8f71a6a340838 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Mon, 3 Feb 2014 14:11:53 -0600
Subject: [PATCH 171/690] typo

---
 it/05-distributed-git/01-chapter5.markdown | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/it/05-distributed-git/01-chapter5.markdown b/it/05-distributed-git/01-chapter5.markdown
index ffedbe393..83227cd10 100755
--- a/it/05-distributed-git/01-chapter5.markdown
+++ b/it/05-distributed-git/01-chapter5.markdown
@@ -52,7 +52,7 @@ Questo tipo di workflow non è comune ma può essere utile in progetti molto gra
 
 Ci sono alcuni workflow utilizzati comunemente che sono possibili con un sistema distribuito come Git, ma esistono molte possibili varianti per adattarli al tuo caso specifico. Ora che hai (spero) determinato quale combinazione di workflow possa funzionare per te, illustrerò alcuni esempi sui ruoli principali dei diversi workflow.
 
-## Contribuire ad un Progetto ##
+## Contribuire a un Progetto ##
 
 Conosci i diversi workflow e dovresti aver chiaro i fondamentali di Git. In questa sezione imparerai alcuni metodi comuni per contribuire a un progetto.
 
@@ -562,7 +562,7 @@ A questo punto, dovresti essere in grado di andare nella cartella bozze del tuo
 
 ### Sommario ###
 
-Questa sezione ha coperto un certo numero di workflow comuni che è facile incontrare quando si ha a che fare con tipi diversi di progetti Git e ha introdotto un paio di nuovi strumenti che ti possono aiutare a gestire questo processo. Ora, vedrai come si lavora con l'altra faccia della medaglia: mantenere un progetto Git. Imparerai ad essere un dittatore benevolo o integration manager.
+Questa sezione ha trattato alcuni workflow comuni che è facile incontrare quando si ha a che fare con progetti Git diversi e ha introdotto un paio di strumenti nuovi per aiutarti a gestire questo processo. Vedremo ora l'altra faccia della medaglia: mantenere un progetto Git. Imparerai ad essere un dittatore benevolo (_benevolent dictator_) o un manager d'integrazione (_integration manager_).
 
 ## Mantenere un Progetto ##
 

From 7601fbfc4b9c232528dac078b3eb50c388f00e62 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Mon, 3 Feb 2014 14:31:40 -0600
Subject: [PATCH 172/690] Reviewed "Maintaining a Project"

---
 it/05-distributed-git/01-chapter5.markdown | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/it/05-distributed-git/01-chapter5.markdown b/it/05-distributed-git/01-chapter5.markdown
index 83227cd10..4f004224f 100755
--- a/it/05-distributed-git/01-chapter5.markdown
+++ b/it/05-distributed-git/01-chapter5.markdown
@@ -531,7 +531,8 @@ Prima di tutto devi configurare la sezione imap nel tuo file `~/.gitconfig`. Puo
 	  port = 993
 	  sslverify = false
 
-Se il tuo server IMAP non usa SSL, probabilmente le ultime due righe non ti saranno necessarie e il valore del campo host sarà `imap://` invece di `imaps://`. Quando avrai configurato tutto, potrai usare `git send-email` per inviare la serie di patch alla cartella "Bozze" del tuo server IMAP:
+Se il tuo server IMAP non usa SSL, probabilmente le ultime due righe non ti saranno necessarie e il valore del campo host sarà `imap://` invece di `imaps://`.
+Quando avrai configurato tutto, potrai usare `git send-email` per inviare la serie di patch alla cartella "Bozze" del tuo server IMAP:
 
 	$ git send-email *.patch
 	0001-added-limit-to-log-function.patch
@@ -566,7 +567,7 @@ Questa sezione ha trattato alcuni workflow comuni che è facile incontrare quand
 
 ## Mantenere un Progetto ##
 
-Oltre a sapere come contribuire ad un progetto in maniera effettiva, dovrai probabilmente sapere anche come mantenerne uno. Ciò consiste nell'accettare ed applicare le patch generate usando il comando `format-patch` e ricevute tramite e-mail oppure nell'integrare cambiamenti in rami dei repository che hai impostato come remote del tuo progetto. Sia che tu mantenga un repository o che tu voglia contribuire nel verificare le patch, devi sapere come eseguire il tuo compito in maniera chiara per gli altri contributori del progetto e sostenibile per te nel lungo periodo.
+Oltre a sapere come contribuire ad un progetto in maniera effettiva, dovrai probabilmente sapere anche come mantenerne uno. Ciò consiste nell'accettare ed applicare le patch generate con il comando `format-patch` e ricevute tramite e-mail oppure nell'integrare le modifiche dei branch remoti che hai definito nel tuo progetto come remoti. Sia che mantenga un repository o che voglia contribuire verificando o approvando le patch, devi sapere come svolgere il tuo compito in modo che sia chiaro per gli altri contributori del progetto e sostenibile per te nel lungo periodo.
 
 ### Lavorare sui Topic Branches ###
 

From 5e44433921c2e95fe0cd8b8f142477bb2c405f28 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Mon, 3 Feb 2014 16:57:19 -0600
Subject: [PATCH 173/690] Reviewed "Working in Topic Branches"

---
 it/05-distributed-git/01-chapter5.markdown | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/it/05-distributed-git/01-chapter5.markdown b/it/05-distributed-git/01-chapter5.markdown
index 4f004224f..bf2e1c11e 100755
--- a/it/05-distributed-git/01-chapter5.markdown
+++ b/it/05-distributed-git/01-chapter5.markdown
@@ -569,17 +569,17 @@ Questa sezione ha trattato alcuni workflow comuni che è facile incontrare quand
 
 Oltre a sapere come contribuire ad un progetto in maniera effettiva, dovrai probabilmente sapere anche come mantenerne uno. Ciò consiste nell'accettare ed applicare le patch generate con il comando `format-patch` e ricevute tramite e-mail oppure nell'integrare le modifiche dei branch remoti che hai definito nel tuo progetto come remoti. Sia che mantenga un repository o che voglia contribuire verificando o approvando le patch, devi sapere come svolgere il tuo compito in modo che sia chiaro per gli altri contributori del progetto e sostenibile per te nel lungo periodo.
 
-### Lavorare sui Topic Branches ###
+### Lavorare coi branch per argomento ###
 
-Quando pensi di integrare un nuovo lavoro, è generalmente una buona idea quella di provarlo in un "topic branch", ovvero un ramo temporaneo creato specificatamente per provare le modifiche introdotte dalla patch. In questo modo è semplice modificare la singola patch e, se questa non funziona, lasciarla intalterata fino a quando non avrai il tempo di tornarci nuovamente. Se crei un ramo con un nome semplice basato sull'argomento della patch, ad esempio `ruby_client`, ti sarà poi facile individuarlo nel caso tu debba lasciare temporaneamente il lavoro sulla patch per tornarci più avanti. Il mantenitore del progetto Git  usa dare uno spazio dei nomi a questi rami, come ad esempio `sc/ruby_client`, dove `sc` sono le iniziali della persona che ha contribuito al lavoro. Come ricorderai, puoi creare un ramo partendo dal tuo ramo master con questi comandi:
+Quando pensi di integrare un nuovo lavoro generalmente è una buona idea provarlo in un branch per argomento: un branch temporaneo, creato specificatamente per provare le modifiche dalla patch. In questo modo è semplice verificare la singola patch e, se questa non funziona, lasciarla intalterata fino a quando non avrai il tempo di ritornarci. Se crei un branch col nome dell'argomento della patch che proverai, per esempio `ruby_client` o qualcosa ugualmente descrittiva, ti sarà facile individuarlo nel caso tu debba temporaneamente lasciare il lavoro sulla patch per ritornarci più avanti. Il mantenitore del progetto Git  usa dare uno gerarchia ai nomi di questi branch: come `sc/ruby_client`, dove `sc` sono le iniziali della persona che ha realizzato la patch. Come ricorderai, puoi creare un branch partendo dal tuo master così:
 
 	$ git branch sc/ruby_client master
 
-Oppure, se vuoi anche passare al nuovo ramo immediatamente, puoi usare il comando `checkout -b`:
+E, se vuoi passare immediatamente al nuovo branch, puoi usare il comando `checkout -b`:
 
 	$ git checkout -b sc/ruby_client master
 
-Ora sei pronto per aggiungere il lavoro a questo ramo e determinare se vuoi unirlo a uno dei rami del tuo progetto.
+Ora sei pronto per aggiungere il lavoro a questo branch e decidere se vuoi unirlo a uno dei branch principali del tuo progetto.
 
 ### Applicare le patch da un'e-mail ###
 

From 5eaab104fff752b0728bc8f96342b1699e3e2a54 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Mon, 3 Feb 2014 17:00:11 -0600
Subject: [PATCH 174/690] Reviewed "Applying Patches from E-mail"

---
 it/05-distributed-git/01-chapter5.markdown | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/it/05-distributed-git/01-chapter5.markdown b/it/05-distributed-git/01-chapter5.markdown
index bf2e1c11e..6b8335f8f 100755
--- a/it/05-distributed-git/01-chapter5.markdown
+++ b/it/05-distributed-git/01-chapter5.markdown
@@ -571,7 +571,8 @@ Oltre a sapere come contribuire ad un progetto in maniera effettiva, dovrai prob
 
 ### Lavorare coi branch per argomento ###
 
-Quando pensi di integrare un nuovo lavoro generalmente è una buona idea provarlo in un branch per argomento: un branch temporaneo, creato specificatamente per provare le modifiche dalla patch. In questo modo è semplice verificare la singola patch e, se questa non funziona, lasciarla intalterata fino a quando non avrai il tempo di ritornarci. Se crei un branch col nome dell'argomento della patch che proverai, per esempio `ruby_client` o qualcosa ugualmente descrittiva, ti sarà facile individuarlo nel caso tu debba temporaneamente lasciare il lavoro sulla patch per ritornarci più avanti. Il mantenitore del progetto Git  usa dare uno gerarchia ai nomi di questi branch: come `sc/ruby_client`, dove `sc` sono le iniziali della persona che ha realizzato la patch. Come ricorderai, puoi creare un branch partendo dal tuo master così:
+Quando pensi di integrare un nuovo lavoro generalmente è una buona idea provarlo in un branch per argomento: un branch temporaneo, creato specificatamente per provare le modifiche dalla patch. In questo modo è semplice verificare la singola patch e, se questa non funziona, lasciarla intalterata fino a quando non avrai il tempo di ritornarci. Se crei un branch col nome dell'argomento della patch che proverai, per esempio `ruby_client` o qualcosa ugualmente descrittiva, ti sarà facile individuarlo nel caso tu debba temporaneamente lasciare il lavoro sulla patch per ritornarci più avanti. Il mantenitore del progetto Git  usa dare uno gerarchia ai nomi di questi branch: come `sc/ruby_client`, dove `sc` sono le iniziali della persona che ha realizzato la patch.
+Come ricorderai, puoi creare un branch partendo dal tuo master così:
 
 	$ git branch sc/ruby_client master
 
@@ -583,7 +584,7 @@ Ora sei pronto per aggiungere il lavoro a questo branch e decidere se vuoi unirl
 
 ### Applicare le patch da un'e-mail ###
 
-Se ricevi via e-mail le patch che vuoi integrare nel tuo progetto, devi applicarle ognuna al relativo `topic branch` per poterle provare. Ci sono due modi per applicare una patch ricevuta via email: con `git apply` oppure con `git am`.
+Se ricevi le patch via e-mail e le vuoi integrarle nel tuo progetto, devi prima applicarle per poterle giudicare. Ci sono due modi per applicare una patch ricevuta via email: con `git apply` o con `git am`.
 
 #### Applicare una patch con apply ####
 

From f3a4e29190524b74ee6d8cb58577e42b1b2edff5 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Mon, 3 Feb 2014 17:07:50 -0600
Subject: [PATCH 175/690] Reviewed "Applying a Patch with apply"

---
 it/05-distributed-git/01-chapter5.markdown | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/it/05-distributed-git/01-chapter5.markdown b/it/05-distributed-git/01-chapter5.markdown
index 6b8335f8f..31b1c5ff9 100755
--- a/it/05-distributed-git/01-chapter5.markdown
+++ b/it/05-distributed-git/01-chapter5.markdown
@@ -588,19 +588,19 @@ Se ricevi le patch via e-mail e le vuoi integrarle nel tuo progetto, devi prima
 
 #### Applicare una patch con apply ####
 
-Se hai ricevuto la patch da qualcuno che l'ha generata usando il comando `git diff` o un qualsiasi comando Unix `diff`, puoi applicarla usando `git apply`. Se per esempio la patch è stata salvata in `/tmp/patch-ruby-client.patch`, puoi applicarla con il seguente comando:
+Se hai ricevuto la patch da qualcuno che l'ha generata usando il comando `git diff` o un qualsiasi comando Unix `diff`, puoi applicarla usando `git apply`. Se hai salvato la patch in `/tmp/patch-ruby-client.patch`, puoi applicarla così:
 
 	$ git apply /tmp/patch-ruby-client.patch
 
-Ciò modifica i file nella tua directory corrente. E' quasi uguale ad eseguire il comando `patch -p1` per applicare la patch, anche se questo comando è più paranoico e accetta meno corrispondenze di patch. Esso gestisce anche l'aggiunta, la rimozione e il cambio del nome dei file se ciò è descritto nel formato di `git diff`, cosa che il comando `patch` non fa. Infine, `git apply` segue il modello "applica tutto o rigetta tutto" dove vengono applicato tutte le modifiche oppure nessuna, mentre `patch` può applicarle anche solo parzialmente, lasciando la tua directory corrente in uno stato intermedio. `git apply` è in generale più paranoico di `patch`. Non creerà  un commit per te: una volta eseguito, devi effettuare lo stage e il commit dei file manualmente.
+Ciò modifica i file nella tua directory corrente. E' quasi uguale ad eseguire il comando `patch -p1` per applicare la patch, anche se questo comando è più paranoico e accetta meno corrispondenze di patch. Gstisce anche l'aggiunta, la rimozione e il cambio del nome dei file se ciò è descritto nel formato di `git diff`, cose che non fa `patch`. Infine `git apply` segue il modello "applica tutto o rigetta tutto" per cui o vengono applicato tutte le modifiche oppure nessuna, mentre `patch` può anche applicarne solo alcune, lasciando la tua directory corrente in uno stato intermedio. `git apply` è in generale molto più paranoico di `patch`. Non creerà una commit per te: una volta eseguito devi eseguire manualmente lo stage delle modifiche e farne la commit.
 
-Puoi usare `git apply` anche per vedere se una patch può essere applicata in maniera pulita prima di applicarla veramente. Puoi eseguire `git apply --check` sulla patch:
+Puoi anche usare `git apply` per verificare se una patch può essere applicata in maniera pulita, prima di applicarla veramente eseguendo `git apply --check` sulla patch:
 
 	$ git apply --check 0001-seeing-if-this-helps-the-gem.patch
 	error: patch failed: ticgit.gemspec:1
 	error: ticgit.gemspec: patch does not apply
 
-Se non viene visualizzato alcun output, allora la patch può essere applicata in maniera pulita. Questo comando termina con un valore diverso da zero se il controllo fallisce, quindi puoi usarlo anche all'interno di uno script.
+Se non viene visualizzato alcun output, allora la patch può essere applicata in maniera pulita. Questo comando restituisce un valore diverso da zero se la verifica fallisce, quindi puoi usarlo anche in uno script.
 
 #### Applicare una patch con am ####
 

From fe57416ccde30dd8503879c6f8f53376fe43b528 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Mon, 3 Feb 2014 17:44:40 -0600
Subject: [PATCH 176/690] Reviewing "Applying a Patch with am"

100% reviewed existing translation
---
 it/05-distributed-git/01-chapter5.markdown | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/it/05-distributed-git/01-chapter5.markdown b/it/05-distributed-git/01-chapter5.markdown
index 31b1c5ff9..e0ca7b48d 100755
--- a/it/05-distributed-git/01-chapter5.markdown
+++ b/it/05-distributed-git/01-chapter5.markdown
@@ -604,9 +604,9 @@ Se non viene visualizzato alcun output, allora la patch può essere applicata in
 
 #### Applicare una patch con am ####
 
-Se il contributore è un utente Git ed è stato abbastanza bravo a usare il comando `format-patch` per generare la sua patch, allora il tuo lavoro è più facile perché la patch contiene le informazioni sull'autore e un messaggio di commit per te. Se ti è possibile incoraggia i tuoi collaboratori ad utilizzare `format-patch` invece di `diff` per generare le patch per te. Dovresti dover usare solo `git apply` per le patch precedenti e altre cose del genere.
+Se il contributore è un utente Git ed è stato abbastanza bravo a usare il comando `format-patch` per generare la sua patch, allora il tuo lavoro sarà più facile perché la patch già contiene le informazioni sull'autore e un messaggio di commit. Se pouoi, per generare le patch per te, incoraggia i tuoi collaboratori ad utilizzare `format-patch` invece di `diff`. Dovresti dover usare solo `git apply` per le patch precedenti e altre cose del genere.
 
-Per applicare una patch generata con `format-patch` si usa `git am`. Tecnicamente `git am` è fatto per leggere un file mbox, che ha un formato semplice di solo testo per memorizzare uno o più messaggi email in un solo file che assomiglia a questo:
+Per applicare una patch generata con `format-patch`, userai `git am`. Tecnicamente `git am` è fatto per leggere un file mbox, che è un file piatto di puro testo per memorizzare uno o più messaggi email in un solo file. Assomiglia a questo:
 
 	From 330090432754092d704da8e76ca5c05c198e71a8 Mon Sep 17 00:00:00 2001
 	From: Jessica Smith <jessica@example.com>
@@ -615,14 +615,14 @@ Per applicare una patch generata con `format-patch` si usa `git am`. Tecnicament
 
 	Limit log functionality to the first 20
 
-Questo è l'inizio dell'output del comando 'format-patch' che hai visto nella sezione precedente, ed è anche un formato valido per mbox. Se qualcuno ti ha inviato la patch usando 'git send-email' e l'hai scaricata nel formato mbox, allora puoi puntare al file mbox da 'git am' e lui inizierà ad applicare tutte le patch che troa. Se hai un client di posta elettronica che ti permette di salvare più messaggi in un file mbox allora puoi salvare tutta una serie di patch in un singolo file e usare `git am` per applicarle tutte assieme.
+Questo è l'inizio dell'output del comando 'format-patch' che hai visto nella sezione precedente, ma è anche un formato valido per mbox per le email. Se qualcuno ti ha inviato la patch usando 'git send-email' e l'hai scaricata nel formato mbox, allora puoi selezionare il file mbox in 'git am' che inizierà ad applicare tutte le patch che trovi. Se hai un client di posta elettronica che ti permette di salvare più messaggi in un file mbox allora puoi salvare tutta una serie di patch in un singolo file e usare `git am` per applicarle tutte assieme.
 
-Se però qualcuno ha caricato su un sistema di ticket (o qualcosa di simile) una patch generata con `format-patch`, tu puoi salvare il file localmente e passarlo a `git am` perché lo applichi:
+Se invece qualcuno ha caricato una patch generata con `format-patch` su un sistema di ticket e tracciamento, puoi salvare localmente il file e passarlo a `git am` perché lo applichi:
 
 	$ git am 0001-limit-log-function.patch
 	Applying: add limit to log function
 
-Puoi vedere che ha applicato automaticamente e senza errori le modifiche e creato una commit per te. Le informazioni sull'autore e la data della commit vengono prese delle intestazioni dell'email (rispettivamente da `From`  e `Date`), mentre il messaggio della commit è preso dal `Subject` e dal corpo dell'email, prima della patch. Se, per esempio questa patch fosse stata applicata dall'esempio dell'mbox appena mostrato, la commit generata apparirebbe così:
+Puoi vedere che ha applicato senza errori le modifiche e ha creato automaticamente una nuova commit per te. Le informazioni sull'autore e la data della commit vengono prese delle intestazioni `From`  e `Date` dell'email, mentre il messaggio della commit è preso dal `Subject` e dal corpo dell'email che precede la patch. Se questa patch fosse stata applicata dall'esempio dell'mbox appena mostrato, la commit generata apparirebbe così:
 
 	$ git log --pretty=fuller -1
 	commit 6c5e70b984a60b3cecd395edd5b48a7575bf58e0

From 2d9194f47e06d56b0bd48893185072239b92fd5d Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Mon, 3 Feb 2014 18:07:33 -0600
Subject: [PATCH 177/690] Translating "Applying a Patch with am"

---
 it/05-distributed-git/01-chapter5.markdown | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/it/05-distributed-git/01-chapter5.markdown b/it/05-distributed-git/01-chapter5.markdown
index e0ca7b48d..1dbe6ca3f 100755
--- a/it/05-distributed-git/01-chapter5.markdown
+++ b/it/05-distributed-git/01-chapter5.markdown
@@ -635,9 +635,9 @@ Puoi vedere che ha applicato senza errori le modifiche e ha creato automaticamen
 
 	   Limit log functionality to the first 20
 
-The `Commit` information indicates the person who applied the patch and the time it was applied. The `Author` information is the individual who originally created the patch and when it was originally created.
+`Commit` indica chi ha applicato la patch e `CommitDate` quando. `Author` chi ha creato la patch originariamente e quando.
 
-But it’s possible that the patch won’t apply cleanly. Perhaps your main branch has diverged too far from the branch the patch was built from, or the patch depends on another patch you haven’t applied yet. In that case, the `git am` process will fail and ask you what you want to do:
+Ma è possibile che la patch non sia applicabile correttamente. Il tuo branch principale potrebbe essere cambiato troppo rispetto al branch da cui deriva la patch o che la patch dipenda da altre che non hai ancora applicato. In questo caso il processo di `git am` fallirà e ti chiederà cosa voglia fareprocess will fail and ask you what you want to do:
 
 	$ git am 0001-seeing-if-this-helps-the-gem.patch
 	Applying: seeing if this helps the gem

From 6f645b60eca503e48eb4e71c760141aded86593d Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Mon, 3 Feb 2014 18:21:47 -0600
Subject: [PATCH 178/690] Translated "Applying a Patch with am"

---
 it/05-distributed-git/01-chapter5.markdown | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/it/05-distributed-git/01-chapter5.markdown b/it/05-distributed-git/01-chapter5.markdown
index 1dbe6ca3f..5d8ff1c17 100755
--- a/it/05-distributed-git/01-chapter5.markdown
+++ b/it/05-distributed-git/01-chapter5.markdown
@@ -648,14 +648,14 @@ Ma è possibile che la patch non sia applicabile correttamente. Il tuo branch pr
 	If you would prefer to skip this patch, instead run "git am --skip".
 	To restore the original branch and stop patching run "git am --abort".
 
-This command puts conflict markers in any files it has issues with, much like a conflicted merge or rebase operation. You solve this issue much the same way — edit the file to resolve the conflict, stage the new file, and then run `git am --resolved` to continue to the next patch:
+Questo comando aggiunge dei marcatori di conflicco in ciascun file che presenti un problema, similmente a quanto avviene nelle operazioni di merge o rebase. E tu risolverai il problema allo stesso modo: modifica il file per risolvere il conflitto, mettilo nello stage ed esegui `git am --resolved` per continuare con la patch successiva:
 
 	$ (fix the file)
 	$ git add ticgit.gemspec
 	$ git am --resolved
 	Applying: seeing if this helps the gem
 
-If you want Git to try a bit more intelligently to resolve the conflict, you can pass a `-3` option to it, which makes Git attempt a three-way merge. This option isn’t on by default because it doesn’t work if the commit the patch says it was based on isn’t in your repository. If you do have that commit — if the patch was based on a public commit — then the `-3` option is generally much smarter about applying a conflicting patch:
+Se vuoi che Git provi a risolvere i conflitti più intelligentemente, puoi passargli l'opzione `-3`, e Git proverà a eseguire un merge a 3-vie. Quest'opzione non è attiva di default perché non funziona se la patch si basa su una commit che non hai nel tuo repository. Se invece hai quella commit (ovvero se la patch è basata su una commit pubblica) allora generalmente l'opzione `-3` è più intelligente nell'applicare una patch con conflitti:
 
 	$ git am -3 0001-seeing-if-this-helps-the-gem.patch
 	Applying: seeing if this helps the gem
@@ -665,9 +665,9 @@ If you want Git to try a bit more intelligently to resolve the conflict, you can
 	Falling back to patching base and 3-way merge...
 	No changes -- Patch already applied.
 
-In this case, I was trying to apply a patch I had already applied. Without the `-3` option, it looks like a conflict.
+In questo caso sto cercando di applicare una patch che ho già applicato. Senza l'opzione `-3` sembrerebbe che ci sia un conflitto.
 
-If you’re applying a number of patches from an mbox, you can also run the `am` command in interactive mode, which stops at each patch it finds and asks if you want to apply it:
+Se stai applicando una serie di patch da un file mbox puoi eseguire il comando `am` anche in modalità interattiva, che si ferma ogni volta che incontra una patch per chiederti se vuoi applicarla:
 
 	$ git am -3 -i mbox
 	Commit Body is:
@@ -676,9 +676,9 @@ If you’re applying a number of patches from an mbox, you can also run the `am`
 	--------------------------
 	Apply? [y]es/[n]o/[e]dit/[v]iew patch/[a]ccept all
 
-This is nice if you have a number of patches saved, because you can view the patch first if you don’t remember what it is, or not apply the patch if you’ve already done so.
+Questo è utile se hai una serie di patch salvate, perché se non ti ricordi cosa sia puoi rivedere la patch, o non applicarla se l'hai già applicata.
 
-When all the patches for your topic are applied and committed into your branch, you can choose whether and how to integrate them into a longer-running branch.
+Quando tutte la patch per l'orgomento sono state applicate e committate nel tuo branch, puoi decidere se e come integrarle in un branch principale.
 
 ### Checking Out Remote Branches ###
 

From 166150105afaadc590b3b7d681fae2ce21662fd1 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Mon, 3 Feb 2014 18:31:34 -0600
Subject: [PATCH 179/690] Translating "Checking Out Remote Branches"

---
 it/05-distributed-git/01-chapter5.markdown | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/it/05-distributed-git/01-chapter5.markdown b/it/05-distributed-git/01-chapter5.markdown
index 5d8ff1c17..65dec88b3 100755
--- a/it/05-distributed-git/01-chapter5.markdown
+++ b/it/05-distributed-git/01-chapter5.markdown
@@ -680,19 +680,19 @@ Questo è utile se hai una serie di patch salvate, perché se non ti ricordi cos
 
 Quando tutte la patch per l'orgomento sono state applicate e committate nel tuo branch, puoi decidere se e come integrarle in un branch principale.
 
-### Checking Out Remote Branches ###
+### Scaricare branch remoti ###
 
-If your contribution came from a Git user who set up their own repository, pushed a number of changes into it, and then sent you the URL to the repository and the name of the remote branch the changes are in, you can add them as a remote and do merges locally.
+Se la contribuzione viene da un utente Git che ha un proprio repository su cui ha pubblicato una serie di modifiche e ti ha mandato l'indirizzo del repository e il nome del branch remoto in cui sono le stesse, puoi aggiungerlo come remoto e unirle localmente.
 
-For instance, if Jessica sends you an e-mail saying that she has a great new feature in the `ruby-client` branch of her repository, you can test it by adding the remote and checking out that branch locally:
+Se, per esempio, Jessica ti invia un'email dicendoti che nel branch `ruby-client` del suo repository ha sviluppato un'interessante funzionalità, tu puoi testarla aggiungendo il branch remoto e scaricarlo come uno localmente:
 
 	$ git remote add jessica git://github.com/jessica/myproject.git
 	$ git fetch jessica
 	$ git checkout -b rubyclient jessica/ruby-client
 
-If she e-mails you again later with another branch containing another great feature, you can fetch and check out because you already have the remote setup.
+Se successivamente t'invia un'altra email con un altro branch che contenga un'altra funzionalità interessante tu puoi scaricarla più velocemente perché hai già configurato il repository remoto.
 
-This is most useful if you’re working with a person consistently. If someone only has a single patch to contribute once in a while, then accepting it over e-mail may be less time consuming than requiring everyone to run their own server and having to continually add and remove remotes to get a few patches. You’re also unlikely to want to have hundreds of remotes, each for someone who contributes only a patch or two. However, scripts and hosted services may make this easier — it depends largely on how you develop and how your contributors develop.
+Questa configurazione è molto utile se lavori molto con una persona. Se qualcuno produce una sola patch di tanto in tanto può essere più rapido accettarle per email, invece di chiedere a tutti di avere un proprio server pubblico e aggiungere in continuazione dei repository remoti per poche modifiche. Allo stesso tempo non vorrai centinaia di repository remoti per qualcuno che contribuisce solo con una patch o due. In ogni caso degli script o servizi di hostin possono rendere il tutto più semplice e principalmente dipende da come sviluppate tu e i tuoi contributori.
 
 The other advantage of this approach is that you get the history of the commits as well. Although you may have legitimate merge issues, you know where in your history their work is based; a proper three-way merge is the default rather than having to supply a `-3` and hope the patch was generated off a public commit to which you have access.
 

From db040e1d249065ad6b9301a1611664e8875d7fab Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Mon, 3 Feb 2014 18:36:13 -0600
Subject: [PATCH 180/690] Translated "Checking Out Remote Branches"

---
 it/05-distributed-git/01-chapter5.markdown | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/it/05-distributed-git/01-chapter5.markdown b/it/05-distributed-git/01-chapter5.markdown
index 65dec88b3..08b42cb2c 100755
--- a/it/05-distributed-git/01-chapter5.markdown
+++ b/it/05-distributed-git/01-chapter5.markdown
@@ -694,9 +694,9 @@ Se successivamente t'invia un'altra email con un altro branch che contenga un'al
 
 Questa configurazione è molto utile se lavori molto con una persona. Se qualcuno produce una sola patch di tanto in tanto può essere più rapido accettarle per email, invece di chiedere a tutti di avere un proprio server pubblico e aggiungere in continuazione dei repository remoti per poche modifiche. Allo stesso tempo non vorrai centinaia di repository remoti per qualcuno che contribuisce solo con una patch o due. In ogni caso degli script o servizi di hostin possono rendere il tutto più semplice e principalmente dipende da come sviluppate tu e i tuoi contributori.
 
-The other advantage of this approach is that you get the history of the commits as well. Although you may have legitimate merge issues, you know where in your history their work is based; a proper three-way merge is the default rather than having to supply a `-3` and hope the patch was generated off a public commit to which you have access.
+L'altro vantaggio di questo approccio è che in aggiunta ricevi la cronologia delle commit. Sebbene tu possa avere problemi coi merge saprai su quale parte della tua cronologia si basi il lavoro dei contributori, il merge a 3-vie è il default e non richiede di specificare l'opzione `-3` e la patch potrebbe essere generata da una commit pubblica a cui tu abbia accesso.
 
-If you aren’t working with a person consistently but still want to pull from them in this way, you can provide the URL of the remote repository to the `git pull` command. This does a one-time pull and doesn’t save the URL as a remote reference:
+Se non lavori spesso con una persona ma vuoi comunque prendere le modifiche in questo modo puoi sempre passare l'URL del repository remoto al comando `git pull`. Questo farà una pull una tantum senza salvare l'URL come un riferimento remoto:
 
 	$ git pull git://github.com/onetimeguy/project.git
 	From git://github.com/onetimeguy/project

From df1dfb053ecf326e35be0b3ae93cb17e88cc9ee7 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Mon, 3 Feb 2014 18:57:56 -0600
Subject: [PATCH 181/690] Translating "Determining What Is Introduced"

---
 it/05-distributed-git/01-chapter5.markdown | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/it/05-distributed-git/01-chapter5.markdown b/it/05-distributed-git/01-chapter5.markdown
index 08b42cb2c..22daae6e7 100755
--- a/it/05-distributed-git/01-chapter5.markdown
+++ b/it/05-distributed-git/01-chapter5.markdown
@@ -703,11 +703,11 @@ Se non lavori spesso con una persona ma vuoi comunque prendere le modifiche in q
 	 * branch            HEAD       -> FETCH_HEAD
 	Merge made by recursive.
 
-### Determining What Is Introduced ###
+### Determinare cos'è stato introdotto ###
 
-Now you have a topic branch that contains contributed work. At this point, you can determine what you’d like to do with it. This section revisits a couple of commands so you can see how you can use them to review exactly what you’ll be introducing if you merge this into your main branch.
+Hai un branch che contiene il lavoro di un contributore. A questo punto puoi decidere cosa farne. Questa sezione rivisita un paio di comandi così che tu possa vedere come usarli per revisionare con precisione cosa introdurrai se unissi queste modifiche al tuo branch principale.
 
-It’s often helpful to get a review of all the commits that are in this branch but that aren’t in your master branch. You can exclude commits in the master branch by adding the `--not` option before the branch name. For example, if your contributor sends you two patches and you create a branch called `contrib` and applied those patches there, you can run this:
+Spesso è utile revisionare le commit del branch che non sono ancora nel tuo master. Puoi escludere le commit di un branch aggiungendo l'opzione `--not` prima del nome del branch. Se un tuo contributore ti manda due patch e tu crei un branch chiamato `contrib` dove applichi le patch, puoi eseguire:
 
 	$ git log contrib --not master
 	commit 5b6235bd297351589efc4d73316f0a68d484f118
@@ -722,17 +722,17 @@ It’s often helpful to get a review of all the commits that are in this branch
 
 	    updated the gemspec to hopefully work better
 
-To see what changes each commit introduces, remember that you can pass the `-p` option to `git log` and it will append the diff introduced to each commit.
+Ricorda che puoi passare l'opzione `-p` a `git log` per vedere le modifiche di ciascuna commit, così che all'output aggiungerà le differenze introdotte da ciascuna commit.
 
-To see a full diff of what would happen if you were to merge this topic branch with another branch, you may have to use a weird trick to get the correct results. You may think to run this:
+Per vedere tutte le differenze che verrebbero applicate se unissi il branch attuale con un altro dovrai usare un trucchetto per vedere il risultato corretto. Potresti pensare di usare:
 
 	$ git diff master
 
-This command gives you a diff, but it may be misleading. If your `master` branch has moved forward since you created the topic branch from it, then you’ll get seemingly strange results. This happens because Git directly compares the snapshots of the last commit of the topic branch you’re on and the snapshot of the last commit on the `master` branch. For example, if you’ve added a line in a file on the `master` branch, a direct comparison of the snapshots will look like the topic branch is going to remove that line.
+Ed effettivamente questo comando esegue una differenza, ma può essere causa di errori. Se il tuo branch `master` si fosse spostato in avanti rispetto a quando hai creato il branch vedrai risultati strani. Questo succede perché Git confronta direttamente l'istantanea ('snapshots') dell'ultima commit del branch con l'istantanea dell'ultima commit di `master`. Se, per esempio, hai aggiunto una riga in un file su `master` branch, un confronto diretto delle istantanee sembrerà indicare che il branch rimuova quella riga.
 
-If `master` is a direct ancestor of your topic branch, this isn’t a problem; but if the two histories have diverged, the diff will look like you’re adding all the new stuff in your topic branch and removing everything unique to the `master` branch.
+Se `master` è un antenato diretto del branch allora non sarà un problema, ma se le due cronologie si sono biforcate ti apparirà che stai aggiungendo tutte le cose nuove del tuo branch e rimuovendo tutto ciò che è solo in `master`.
 
-What you really want to see are the changes added to the topic branch — the work you’ll introduce if you merge this branch with master. You do that by having Git compare the last commit on your topic branch with the first common ancestor it has with the master branch.
+Quello che vuoi realmente vedere sono le modifiche aggiunte nel branch: il lavoro che effettivamente introdurrai se le unissi al master. Potrai ottenerlo facendo si che Git confronti l'ultima commit del branch col primo antenato comune con il branch master.
 
 Technically, you can do that by explicitly figuring out the common ancestor and then running your diff on it:
 

From d53299c9c2affb0cdd521f612ee39ece2cc3a8ba Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Mon, 3 Feb 2014 19:06:21 -0600
Subject: [PATCH 182/690] Translated "Determining What Is Introduced"

---
 it/05-distributed-git/01-chapter5.markdown | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/it/05-distributed-git/01-chapter5.markdown b/it/05-distributed-git/01-chapter5.markdown
index 22daae6e7..681e85183 100755
--- a/it/05-distributed-git/01-chapter5.markdown
+++ b/it/05-distributed-git/01-chapter5.markdown
@@ -734,17 +734,17 @@ Se `master` è un antenato diretto del branch allora non sarà un problema, ma s
 
 Quello che vuoi realmente vedere sono le modifiche aggiunte nel branch: il lavoro che effettivamente introdurrai se le unissi al master. Potrai ottenerlo facendo si che Git confronti l'ultima commit del branch col primo antenato comune con il branch master.
 
-Technically, you can do that by explicitly figuring out the common ancestor and then running your diff on it:
+Tecnicamente puoi farlo tu scoprendo l'antenato comune ed eseguendo quindi la diff:
 
 	$ git merge-base contrib master
 	36c7dba2c95e6bbb78dfa822519ecfec6e1ca649
 	$ git diff 36c7db
 
-However, that isn’t convenient, so Git provides another shorthand for doing the same thing: the triple-dot syntax. In the context of the `diff` command, you can put three periods after another branch to do a `diff` between the last commit of the branch you’re on and its common ancestor with another branch:
+Questo però è scomodo e Git fornisce un modo più veloce per farlo: i tre punti. Nel contesto del comando `diff`, puoi usare tre punti dopo il nome di un branch per eseguire una `diff` tra l'ultima commit del branch in cui sei e l'antenato comune con un altro branch:
 
 	$ git diff master...contrib
 
-This command shows you only the work your current topic branch has introduced since its common ancestor with master. That is a very useful syntax to remember.
+Questo comando ti mostra solo le modifiche introdotte dal branch attuale a partire dall'antenato comune con master. Questa sintassi è molto utile da ricordare.
 
 ### Integrating Contributed Work ###
 

From d4ba71becb8dd543518866dd4028bde8323d77f3 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Mon, 3 Feb 2014 19:10:03 -0600
Subject: [PATCH 183/690] Translated "Integrating Contributed Work"

---
 it/05-distributed-git/01-chapter5.markdown | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/it/05-distributed-git/01-chapter5.markdown b/it/05-distributed-git/01-chapter5.markdown
index 681e85183..7ff3b27a9 100755
--- a/it/05-distributed-git/01-chapter5.markdown
+++ b/it/05-distributed-git/01-chapter5.markdown
@@ -746,9 +746,9 @@ Questo però è scomodo e Git fornisce un modo più veloce per farlo: i tre punt
 
 Questo comando ti mostra solo le modifiche introdotte dal branch attuale a partire dall'antenato comune con master. Questa sintassi è molto utile da ricordare.
 
-### Integrating Contributed Work ###
+### Integrare il lavoro dei contributori ###
 
-When all the work in your topic branch is ready to be integrated into a more mainline branch, the question is how to do it. Furthermore, what overall workflow do you want to use to maintain your project? You have a number of choices, so I’ll cover a few of them.
+Quando tutto il lavoro del tuo branch è pronto per essere integrato in un branch principale nasce il prblema di come farlo. Inoltre, quale workflow vuoi usare per mantenere il tuo progetto? Hai una serie di scelte e ne tratterò alcune.
 
 #### Merging Workflows ####
 

From 1152a4fe85972db2f206dfb5d15fc52a0daf76de Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Mon, 3 Feb 2014 19:28:30 -0600
Subject: [PATCH 184/690] Translating "Merging Workflows"

---
 it/05-distributed-git/01-chapter5.markdown | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/it/05-distributed-git/01-chapter5.markdown b/it/05-distributed-git/01-chapter5.markdown
index 7ff3b27a9..c252105c9 100755
--- a/it/05-distributed-git/01-chapter5.markdown
+++ b/it/05-distributed-git/01-chapter5.markdown
@@ -750,17 +750,17 @@ Questo comando ti mostra solo le modifiche introdotte dal branch attuale a parti
 
 Quando tutto il lavoro del tuo branch è pronto per essere integrato in un branch principale nasce il prblema di come farlo. Inoltre, quale workflow vuoi usare per mantenere il tuo progetto? Hai una serie di scelte e ne tratterò alcune.
 
-#### Merging Workflows ####
+#### I workflow per il merge ####
 
-One simple workflow merges your work into your `master` branch. In this scenario, you have a `master` branch that contains basically stable code. When you have work in a topic branch that you’ve done or that someone has contributed and you’ve verified, you merge it into your master branch, delete the topic branch, and then continue the process.  If we have a repository with work in two branches named `ruby_client` and `php_client` that looks like Figure 5-19 and merge `ruby_client` first and then `php_client` next, then your history will end up looking like Figure 5-20.
+Un workflow semplice unisce le modifiche nel branch `master`. In questo scenario hai un `master` che contiene del codice stabile. Quando hai del lavoro in un branch secondario che sia tuo o di un contributore e di cui tu abbia già verificato il buon funzionamento, lo unisci al master, cancelli il branch e così via. Se abbiamo un repository che abbia delle modifiche in due branch chiamati `ruby_client` e `php_client` questo apparirà come in Figura 5-19 e se unissimo prima `ruby_client` e poi `php_client` allora la nostra cronologia apparirà come quella in Figura 5-20.
 
 Insert 18333fig0519.png
-Figure 5-19. History with several topic branches.
+Figure 5-19. Cronologia con branch multipli.
 
 Insert 18333fig0520.png
-Figure 5-20. After a topic branch merge.
+Figure 5-20. Dopo l'unione dei branch.
 
-That is probably the simplest workflow, but it’s problematic if you’re dealing with larger repositories or projects.
+Probabilmente questo è il workflow più semplice, ma è anche problematico se stai lavorando con repository o progetti grandi.
 
 If you have more developers or a larger project, you’ll probably want to use at least a two-phase merge cycle. In this scenario, you have two long-running branches, `master` and `develop`, in which you determine that `master` is updated only when a very stable release is cut and all new code is integrated into the `develop` branch. You regularly push both of these branches to the public repository. Each time you have a new topic branch to merge in (Figure 5-21), you merge it into `develop` (Figure 5-22); then, when you tag a release, you fast-forward `master` to wherever the now-stable `develop` branch is (Figure 5-23).
 

From f8bdcf5c9d586d5f77522aa6873d2874971be54a Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Mon, 3 Feb 2014 19:38:14 -0600
Subject: [PATCH 185/690] Transled "Merging Workflows"

---
 it/05-distributed-git/01-chapter5.markdown | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/it/05-distributed-git/01-chapter5.markdown b/it/05-distributed-git/01-chapter5.markdown
index c252105c9..4c62c8575 100755
--- a/it/05-distributed-git/01-chapter5.markdown
+++ b/it/05-distributed-git/01-chapter5.markdown
@@ -762,19 +762,19 @@ Figure 5-20. Dopo l'unione dei branch.
 
 Probabilmente questo è il workflow più semplice, ma è anche problematico se stai lavorando con repository o progetti grandi.
 
-If you have more developers or a larger project, you’ll probably want to use at least a two-phase merge cycle. In this scenario, you have two long-running branches, `master` and `develop`, in which you determine that `master` is updated only when a very stable release is cut and all new code is integrated into the `develop` branch. You regularly push both of these branches to the public repository. Each time you have a new topic branch to merge in (Figure 5-21), you merge it into `develop` (Figure 5-22); then, when you tag a release, you fast-forward `master` to wherever the now-stable `develop` branch is (Figure 5-23).
+Se hai più sviluppatori o lavori in un progetto grande, probabilmente vorrai usare un ciclo d'unione a due fasi. In questo scenario hai due branch principali, `master` e `develop`, e hai deciso che `master` viene aggiornato esclusivamente con un rilascio molto stabile e tutto il codice nuovo viene integrato nel branch `develop`. Condividi regolarmente entrambi i branch su un repository pubblico e ogni volta che hai un nuovo branch da integrare (Figura 5-21) lo fai in `develop` (Figura 5-22), quindi taggi il rilascio e fai un `fast-forward` di `master` al punto in cui `develop` è stabile (Figura 5-23).
 
 Insert 18333fig0521.png
-Figure 5-21. Before a topic branch merge.
+Figure 5-21. Prima dell'unione del branch.
 
 Insert 18333fig0522.png
-Figure 5-22. After a topic branch merge.
+Figure 5-22. Dopo l'unione del branch.
 
 Insert 18333fig0523.png
-Figure 5-23. After a topic branch release.
+Figure 5-23. Dopo il rilascio di un branch.
 
-This way, when people clone your project’s repository, they can either check out master to build the latest stable version and keep up to date on that easily, or they can check out develop, which is the more cutting-edge stuff.
-You can also continue this concept, having an integrate branch where all the work is merged together. Then, when the codebase on that branch is stable and passes tests, you merge it into a develop branch; and when that has proven itself stable for a while, you fast-forward your master branch.
+In questo modo quando qualcuno clona il repository del tuo progetto, questi può scaricare il master per avere l'ultima versione stabile e tenersi aggiornato, o scaricare la versione di sviluppo che contiene le ultime cose.
+Puoi estendere questo concetto avendo un branch in cui integri tutto il nuovo lavoro. Quando il codice di questo branch è stabile e ha passato tutti i test lo unisci al branch di sviluppo e quando questo ha dimostrato di essere stabile per un po', fai un `fast-forward` del tuo master.
 
 #### Large-Merging Workflows ####
 

From 098b6d7b96e3395c0c493fb162c42237eecc1eb2 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Mon, 3 Feb 2014 19:40:09 -0600
Subject: [PATCH 186/690] Translated all "Figure"

---
 it/05-distributed-git/01-chapter5.markdown | 28 +++++++++++-----------
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/it/05-distributed-git/01-chapter5.markdown b/it/05-distributed-git/01-chapter5.markdown
index 4c62c8575..619c5540e 100755
--- a/it/05-distributed-git/01-chapter5.markdown
+++ b/it/05-distributed-git/01-chapter5.markdown
@@ -755,38 +755,38 @@ Quando tutto il lavoro del tuo branch è pronto per essere integrato in un branc
 Un workflow semplice unisce le modifiche nel branch `master`. In questo scenario hai un `master` che contiene del codice stabile. Quando hai del lavoro in un branch secondario che sia tuo o di un contributore e di cui tu abbia già verificato il buon funzionamento, lo unisci al master, cancelli il branch e così via. Se abbiamo un repository che abbia delle modifiche in due branch chiamati `ruby_client` e `php_client` questo apparirà come in Figura 5-19 e se unissimo prima `ruby_client` e poi `php_client` allora la nostra cronologia apparirà come quella in Figura 5-20.
 
 Insert 18333fig0519.png
-Figure 5-19. Cronologia con branch multipli.
+Figura 5-19. Cronologia con branch multipli.
 
 Insert 18333fig0520.png
-Figure 5-20. Dopo l'unione dei branch.
+Figura 5-20. Dopo l'unione dei branch.
 
 Probabilmente questo è il workflow più semplice, ma è anche problematico se stai lavorando con repository o progetti grandi.
 
 Se hai più sviluppatori o lavori in un progetto grande, probabilmente vorrai usare un ciclo d'unione a due fasi. In questo scenario hai due branch principali, `master` e `develop`, e hai deciso che `master` viene aggiornato esclusivamente con un rilascio molto stabile e tutto il codice nuovo viene integrato nel branch `develop`. Condividi regolarmente entrambi i branch su un repository pubblico e ogni volta che hai un nuovo branch da integrare (Figura 5-21) lo fai in `develop` (Figura 5-22), quindi taggi il rilascio e fai un `fast-forward` di `master` al punto in cui `develop` è stabile (Figura 5-23).
 
 Insert 18333fig0521.png
-Figure 5-21. Prima dell'unione del branch.
+Figura 5-21. Prima dell'unione del branch.
 
 Insert 18333fig0522.png
-Figure 5-22. Dopo l'unione del branch.
+Figura 5-22. Dopo l'unione del branch.
 
 Insert 18333fig0523.png
-Figure 5-23. Dopo il rilascio di un branch.
+Figura 5-23. Dopo il rilascio di un branch.
 
 In questo modo quando qualcuno clona il repository del tuo progetto, questi può scaricare il master per avere l'ultima versione stabile e tenersi aggiornato, o scaricare la versione di sviluppo che contiene le ultime cose.
 Puoi estendere questo concetto avendo un branch in cui integri tutto il nuovo lavoro. Quando il codice di questo branch è stabile e ha passato tutti i test lo unisci al branch di sviluppo e quando questo ha dimostrato di essere stabile per un po', fai un `fast-forward` del tuo master.
 
 #### Large-Merging Workflows ####
 
-The Git project has four long-running branches: `master`, `next`, and `pu` (proposed updates) for new work, and `maint` for maintenance backports. When new work is introduced by contributors, it’s collected into topic branches in the maintainer’s repository in a manner similar to what I’ve described (see Figure 5-24). At this point, the topics are evaluated to determine whether they’re safe and ready for consumption or whether they need more work. If they’re safe, they’re merged into `next`, and that branch is pushed up so everyone can try the topics integrated together.
+The Git project has four long-running branches: `master`, `next`, and `pu` (proposed updates) for new work, and `maint` for maintenance backports. When new work is introduced by contributors, it’s collected into topic branches in the maintainer’s repository in a manner similar to what I’ve described (see Figura 5-24). At this point, the topics are evaluated to determine whether they’re safe and ready for consumption or whether they need more work. If they’re safe, they’re merged into `next`, and that branch is pushed up so everyone can try the topics integrated together.
 
 Insert 18333fig0524.png
-Figure 5-24. Managing a complex series of parallel contributed topic branches.
+Figura 5-24. Managing a complex series of parallel contributed topic branches.
 
-If the topics still need work, they’re merged into `pu` instead. When it’s determined that they’re totally stable, the topics are re-merged into `master` and are then rebuilt from the topics that were in `next` but didn’t yet graduate to `master`. This means `master` almost always moves forward, `next` is rebased occasionally, and `pu` is rebased even more often (see Figure 5-25).
+If the topics still need work, they’re merged into `pu` instead. When it’s determined that they’re totally stable, the topics are re-merged into `master` and are then rebuilt from the topics that were in `next` but didn’t yet graduate to `master`. This means `master` almost always moves forward, `next` is rebased occasionally, and `pu` is rebased even more often (see Figura 5-25).
 
 Insert 18333fig0525.png
-Figure 5-25. Merging contributed topic branches into long-term integration branches.
+Figura 5-25. Merging contributed topic branches into long-term integration branches.
 
 When a topic branch has finally been merged into `master`, it’s removed from the repository. The Git project also has a `maint` branch that is forked off from the last release to provide backported patches in case a maintenance release is required. Thus, when you clone the Git repository, you have four branches that you can check out to evaluate the project in different stages of development, depending on how cutting edge you want to be or how you want to contribute; and the maintainer has a structured workflow to help them vet new contributions.
 
@@ -794,10 +794,10 @@ When a topic branch has finally been merged into `master`, it’s removed from t
 
 Other maintainers prefer to rebase or cherry-pick contributed work on top of their master branch, rather than merging it in, to keep a mostly linear history. When you have work in a topic branch and have determined that you want to integrate it, you move to that branch and run the rebase command to rebuild the changes on top of your current master (or `develop`, and so on) branch. If that works well, you can fast-forward your `master` branch, and you’ll end up with a linear project history.
 
-The other way to move introduced work from one branch to another is to cherry-pick it. A cherry-pick in Git is like a rebase for a single commit. It takes the patch that was introduced in a commit and tries to reapply it on the branch you’re currently on. This is useful if you have a number of commits on a topic branch and you want to integrate only one of them, or if you only have one commit on a topic branch and you’d prefer to cherry-pick it rather than run rebase. For example, suppose you have a project that looks like Figure 5-26.
+The other way to move introduced work from one branch to another is to cherry-pick it. A cherry-pick in Git is like a rebase for a single commit. It takes the patch that was introduced in a commit and tries to reapply it on the branch you’re currently on. This is useful if you have a number of commits on a topic branch and you want to integrate only one of them, or if you only have one commit on a topic branch and you’d prefer to cherry-pick it rather than run rebase. For example, suppose you have a project that looks like Figura 5-26.
 
 Insert 18333fig0526.png
-Figure 5-26. Example history before a cherry pick.
+Figura 5-26. Example history before a cherry pick.
 
 If you want to pull commit `e43a6` into your master branch, you can run
 
@@ -806,10 +806,10 @@ If you want to pull commit `e43a6` into your master branch, you can run
 	[master]: created a0a41a9: "More friendly message when locking the index fails."
 	 3 files changed, 17 insertions(+), 3 deletions(-)
 
-This pulls the same change introduced in `e43a6`, but you get a new commit SHA-1 value, because the date applied is different. Now your history looks like Figure 5-27.
+This pulls the same change introduced in `e43a6`, but you get a new commit SHA-1 value, because the date applied is different. Now your history looks like Figura 5-27.
 
 Insert 18333fig0527.png
-Figure 5-27. History after cherry-picking a commit on a topic branch.
+Figura 5-27. History after cherry-picking a commit on a topic branch.
 
 Now you can remove your topic branch and drop the commits you didn’t want to pull in.
 
@@ -822,7 +822,7 @@ When you’ve decided to cut a release, you’ll probably want to drop a tag so
 	user: "Scott Chacon <schacon@gmail.com>"
 	1024-bit DSA key, ID F721C45A, created 2009-02-09
 
-If you do sign your tags, you may have the problem of distributing the public PGP key used to sign your tags. The maintainer of the Git project has solved this issue by including their public key as a blob in the repository and then adding a tag that points directly to that content. To do this, you can figure out which key you want by running `gpg --list-keys`:
+If you do sign your tags, you may have the problem of distributing the public PGP key used to sign your tags. The maintainer of the Git project has solved this issue by including their public key as a blob in the repository and then adding a tag that points directly to that content. To do this, you can Figura out which key you want by running `gpg --list-keys`:
 
 	$ gpg --list-keys
 	/Users/schacon/.gnupg/pubring.gpg

From 5db8b20df5ba2f9714de0c37cb9a02265dde2b9a Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Mon, 3 Feb 2014 19:58:02 -0600
Subject: [PATCH 187/690] Translated "Large-Merging Workflows"

---
 it/05-distributed-git/01-chapter5.markdown | 26 +++++++++++-----------
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/it/05-distributed-git/01-chapter5.markdown b/it/05-distributed-git/01-chapter5.markdown
index 619c5540e..3d159afc8 100755
--- a/it/05-distributed-git/01-chapter5.markdown
+++ b/it/05-distributed-git/01-chapter5.markdown
@@ -752,43 +752,43 @@ Quando tutto il lavoro del tuo branch è pronto per essere integrato in un branc
 
 #### I workflow per il merge ####
 
-Un workflow semplice unisce le modifiche nel branch `master`. In questo scenario hai un `master` che contiene del codice stabile. Quando hai del lavoro in un branch secondario che sia tuo o di un contributore e di cui tu abbia già verificato il buon funzionamento, lo unisci al master, cancelli il branch e così via. Se abbiamo un repository che abbia delle modifiche in due branch chiamati `ruby_client` e `php_client` questo apparirà come in Figura 5-19 e se unissimo prima `ruby_client` e poi `php_client` allora la nostra cronologia apparirà come quella in Figura 5-20.
+Un workflow semplice unisce le modifiche nel branch `master`. In questo scenario hai un `master` che contiene del codice stabile. Quando hai del lavoro in un branch funzionale che sia tuo o di un contributore e di cui tu abbia già verificato il buon funzionamento, lo unisci al master, cancelli il branch e così via. Se abbiamo un repository che abbia delle modifiche in due branch  funzionali chiamati `ruby_client` e `php_client` questo apparirà come in Figura 5-19 e se unissimo prima `ruby_client` e poi `php_client` allora la nostra cronologia apparirà come quella in Figura 5-20.
 
 Insert 18333fig0519.png
-Figura 5-19. Cronologia con branch multipli.
+Figura 5-19. Cronologia con branch funzionali multipli.
 
 Insert 18333fig0520.png
-Figura 5-20. Dopo l'unione dei branch.
+Figura 5-20. Dopo l'unione dei branch funzionali.
 
 Probabilmente questo è il workflow più semplice, ma è anche problematico se stai lavorando con repository o progetti grandi.
 
-Se hai più sviluppatori o lavori in un progetto grande, probabilmente vorrai usare un ciclo d'unione a due fasi. In questo scenario hai due branch principali, `master` e `develop`, e hai deciso che `master` viene aggiornato esclusivamente con un rilascio molto stabile e tutto il codice nuovo viene integrato nel branch `develop`. Condividi regolarmente entrambi i branch su un repository pubblico e ogni volta che hai un nuovo branch da integrare (Figura 5-21) lo fai in `develop` (Figura 5-22), quindi taggi il rilascio e fai un `fast-forward` di `master` al punto in cui `develop` è stabile (Figura 5-23).
+Se hai più sviluppatori o lavori in un progetto grande, probabilmente vorrai usare un ciclo d'unione a due fasi. In questo scenario hai due branch principali, `master` e `develop`, e hai deciso che `master` viene aggiornato esclusivamente con un rilascio molto stabile e tutto il codice nuovo viene integrato nel branch `develop`. Condividi regolarmente entrambi i branch su un repository pubblico e ogni volta che hai un nuovo branch funzionale da integrare (Figura 5-21) lo fai in `develop` (Figura 5-22), quindi taggi il rilascio e fai un `fast-forward` di `master` al punto in cui `develop` è stabile (Figura 5-23).
 
 Insert 18333fig0521.png
-Figura 5-21. Prima dell'unione del branch.
+Figura 5-21. Prima dell'unione del branch funzionale.
 
 Insert 18333fig0522.png
-Figura 5-22. Dopo l'unione del branch.
+Figura 5-22. Dopo l'unione del branch funzionale.
 
 Insert 18333fig0523.png
-Figura 5-23. Dopo il rilascio di un branch.
+Figura 5-23. Dopo il rilascio di un branch funzionale.
 
 In questo modo quando qualcuno clona il repository del tuo progetto, questi può scaricare il master per avere l'ultima versione stabile e tenersi aggiornato, o scaricare la versione di sviluppo che contiene le ultime cose.
 Puoi estendere questo concetto avendo un branch in cui integri tutto il nuovo lavoro. Quando il codice di questo branch è stabile e ha passato tutti i test lo unisci al branch di sviluppo e quando questo ha dimostrato di essere stabile per un po', fai un `fast-forward` del tuo master.
 
-#### Large-Merging Workflows ####
+#### Workflow per unioni grandi ####
 
-The Git project has four long-running branches: `master`, `next`, and `pu` (proposed updates) for new work, and `maint` for maintenance backports. When new work is introduced by contributors, it’s collected into topic branches in the maintainer’s repository in a manner similar to what I’ve described (see Figura 5-24). At this point, the topics are evaluated to determine whether they’re safe and ready for consumption or whether they need more work. If they’re safe, they’re merged into `next`, and that branch is pushed up so everyone can try the topics integrated together.
+Il progetto Git ha quattro branch principali: `master`, `next`, e `pu` (aggiornamenti suggeriti - `proposed updates`) per il nuovo lavoro, e `maint` per la manutenzione dei backport. Quando un contributore introduce una modifica, questa viene raccolta nei branch funzionali del repository del mantenitore in modo simile a quanto ho già descritto (vedi Figura 5-24). A questo punto le modifiche vengono valutate per deteminare se sono sicure e pronte per essere utilizzate o se hanno bisogno di ulteriore lavoro. Se sono sicure vengono unite in `next` e questo branch viene condiviso perché chiunque possa provarle tutte assieme.
 
 Insert 18333fig0524.png
-Figura 5-24. Managing a complex series of parallel contributed topic branches.
+Figura 5-24. Gestire una serie complessa di branch funzionali paralleli.
 
-If the topics still need work, they’re merged into `pu` instead. When it’s determined that they’re totally stable, the topics are re-merged into `master` and are then rebuilt from the topics that were in `next` but didn’t yet graduate to `master`. This means `master` almost always moves forward, `next` is rebased occasionally, and `pu` is rebased even more often (see Figura 5-25).
+Se la funzione ha bisogno di ulteriori modifiche viene unita invece in `pu` e quando viene ritenuta realmente stabile viene unita di nuovo su `master` e viene ricostruita dal codice che era in `next`, ma non è ancora promossa su `master`. Questo significa che `master` va quasi sempre avanti, `next` raramente è ribasato e `pu` viene ribasato molto spesso (see Figura 5-25).
 
 Insert 18333fig0525.png
-Figura 5-25. Merging contributed topic branches into long-term integration branches.
+Figura 5-25. Unire branch di contribuzione nei branch principali.
 
-When a topic branch has finally been merged into `master`, it’s removed from the repository. The Git project also has a `maint` branch that is forked off from the last release to provide backported patches in case a maintenance release is required. Thus, when you clone the Git repository, you have four branches that you can check out to evaluate the project in different stages of development, depending on how cutting edge you want to be or how you want to contribute; and the maintainer has a structured workflow to help them vet new contributions.
+Quando un branch funzionale viene finalmente unito in `master` viene anche rimosso dal repository. Il progetto Git ha anche un branch `maint` che è un fork dell'ultima release per fornire patch a versioni precedenti nel caso sia necessaria un rilascio di manutenzione. Quindi, quando cloni il repository di Git puoi usare quattro branch per valutare il progetto in stadi diversi dello sviluppo, a seconda che tu voglia le ultime funzionalità o voglia contribuire, e il mantenitore ha strutturato il workflow in modo da favorire nuove contribuzioni.
 
 #### Rebasing and Cherry Picking Workflows ####
 

From 45a1c5bf9a6da23d7f7ae9c747c8be123c497ce6 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Mon, 3 Feb 2014 20:07:22 -0600
Subject: [PATCH 188/690] Translating "Rebasing and Cherry Picking Workflows"

---
 it/05-distributed-git/01-chapter5.markdown | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/it/05-distributed-git/01-chapter5.markdown b/it/05-distributed-git/01-chapter5.markdown
index 3d159afc8..36f94446d 100755
--- a/it/05-distributed-git/01-chapter5.markdown
+++ b/it/05-distributed-git/01-chapter5.markdown
@@ -40,7 +40,7 @@ Questo è un workflow comune con siti come GitHub, dove è facile eseguire un fo
 
 Questa è una variante del workflow con repository multipli. Viene generalmente usata da grandi progetti con centinaia di collaboratori: un esempio famoso è il Kernel Linux. Molti manager d'integrazione sono responsabili di certe parti del repository e vengono chiamati tenenti. Tutti i tenenti hanno un manager d'integrazione conosciuto come "dittatore benevolo". Il repository del dittatore benevolo è il repository di riferimento dal quale tutti i collaboratori prendono il codice. Il flusso di lavoro è il seguente (vedi Figura 5-3):
 
-1.  Sviluppatori normali lavorano sul loro branch ed eseguono un `rebase` del proprio lavoro sul master. Il branch master è quello del dittatore.
+1.  Sviluppatori normali lavorano sul loro branch ed eseguono un _rebase_ del proprio lavoro sul master. Il branch master è quello del dittatore.
 2.  I tenenti uniscono il lavoro degli sviluppatori nel proprio branch master.
 3.  Il dittatore esegue l'unione dei branch master dei tenenti nel proprio branch master.
 4.  Il dittatore esegue una push del proprio ramo master nel repository di riferimento, cosicché gli sviluppatori possano accedervi.
@@ -774,7 +774,7 @@ Insert 18333fig0523.png
 Figura 5-23. Dopo il rilascio di un branch funzionale.
 
 In questo modo quando qualcuno clona il repository del tuo progetto, questi può scaricare il master per avere l'ultima versione stabile e tenersi aggiornato, o scaricare la versione di sviluppo che contiene le ultime cose.
-Puoi estendere questo concetto avendo un branch in cui integri tutto il nuovo lavoro. Quando il codice di questo branch è stabile e ha passato tutti i test lo unisci al branch di sviluppo e quando questo ha dimostrato di essere stabile per un po', fai un `fast-forward` del tuo master.
+Puoi estendere questo concetto avendo un branch in cui integri tutto il nuovo lavoro. Quando il codice di questo branch è stabile e ha passato tutti i test lo unisci al branch di sviluppo e quando questo ha dimostrato di essere stabile per un po', fai un _fast-forward_ del tuo master.
 
 #### Workflow per unioni grandi ####
 
@@ -790,9 +790,9 @@ Figura 5-25. Unire branch di contribuzione nei branch principali.
 
 Quando un branch funzionale viene finalmente unito in `master` viene anche rimosso dal repository. Il progetto Git ha anche un branch `maint` che è un fork dell'ultima release per fornire patch a versioni precedenti nel caso sia necessaria un rilascio di manutenzione. Quindi, quando cloni il repository di Git puoi usare quattro branch per valutare il progetto in stadi diversi dello sviluppo, a seconda che tu voglia le ultime funzionalità o voglia contribuire, e il mantenitore ha strutturato il workflow in modo da favorire nuove contribuzioni.
 
-#### Rebasing and Cherry Picking Workflows ####
+#### Workflow per il rebase e lo _cherry pick_ ####
 
-Other maintainers prefer to rebase or cherry-pick contributed work on top of their master branch, rather than merging it in, to keep a mostly linear history. When you have work in a topic branch and have determined that you want to integrate it, you move to that branch and run the rebase command to rebuild the changes on top of your current master (or `develop`, and so on) branch. If that works well, you can fast-forward your `master` branch, and you’ll end up with a linear project history.
+Altri mantenitori preferiscono ribasare o usare lo _cherry-pick_ aggiungere i contributi nel loro branch master, piuttosto che unirli, per mantenere una cronologia il più lineare possibile. Quando hai delle modifiche in un branch funzionale e hai deciso che vuoi integrarle, ti sposti su quel branch ed esegui il comando _rebase_ per replicare le modifiche del tuo master attuale (o `develop` e così via). Se queste funzionano, allora fai un _fast-forward_ del tuo `master` e ti ritroverai con un progetto dalla cronologia lineare.
 
 The other way to move introduced work from one branch to another is to cherry-pick it. A cherry-pick in Git is like a rebase for a single commit. It takes the patch that was introduced in a commit and tries to reapply it on the branch you’re currently on. This is useful if you have a number of commits on a topic branch and you want to integrate only one of them, or if you only have one commit on a topic branch and you’d prefer to cherry-pick it rather than run rebase. For example, suppose you have a project that looks like Figura 5-26.
 

From fa1e6daa07cf859dc9068cf9a79ff4acaf19f939 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Mon, 3 Feb 2014 20:13:48 -0600
Subject: [PATCH 189/690] Translated "Rebasing and Cherry Picking Workflows"

---
 it/05-distributed-git/01-chapter5.markdown | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/it/05-distributed-git/01-chapter5.markdown b/it/05-distributed-git/01-chapter5.markdown
index 36f94446d..c69f91cb6 100755
--- a/it/05-distributed-git/01-chapter5.markdown
+++ b/it/05-distributed-git/01-chapter5.markdown
@@ -794,24 +794,24 @@ Quando un branch funzionale viene finalmente unito in `master` viene anche rimos
 
 Altri mantenitori preferiscono ribasare o usare lo _cherry-pick_ aggiungere i contributi nel loro branch master, piuttosto che unirli, per mantenere una cronologia il più lineare possibile. Quando hai delle modifiche in un branch funzionale e hai deciso che vuoi integrarle, ti sposti su quel branch ed esegui il comando _rebase_ per replicare le modifiche del tuo master attuale (o `develop` e così via). Se queste funzionano, allora fai un _fast-forward_ del tuo `master` e ti ritroverai con un progetto dalla cronologia lineare.
 
-The other way to move introduced work from one branch to another is to cherry-pick it. A cherry-pick in Git is like a rebase for a single commit. It takes the patch that was introduced in a commit and tries to reapply it on the branch you’re currently on. This is useful if you have a number of commits on a topic branch and you want to integrate only one of them, or if you only have one commit on a topic branch and you’d prefer to cherry-pick it rather than run rebase. For example, suppose you have a project that looks like Figura 5-26.
+L'altro modo per spostare il lavoro dei contributori da un branch all'altro è di usare lo _cherry-pick_. Lo _cherry-pick_ in Git è come una rebase per una commit singola. Prende la patch introdotta nella commit e prova a riapplicarla sul branch dove sei. Questo è utile se hai molte commit in un branch funzionale e vuoi integrarne solo alcune o se hai un'unica commit in un branch funzionale e preferisci usare lo `cherry-pick` piuttosto che ribasare. Immagina di avere un progetto che sembri quello di Figura 5-26.
 
 Insert 18333fig0526.png
-Figura 5-26. Example history before a cherry pick.
+Figura 5-26. Cronologia prima dello _cherry pick_.
 
-If you want to pull commit `e43a6` into your master branch, you can run
+Se vuoi introdurre la commit `e43a6` nel tuo master puoi eseguire
 
 	$ git cherry-pick e43a6fd3e94888d76779ad79fb568ed180e5fcdf
 	Finished one cherry-pick.
 	[master]: created a0a41a9: "More friendly message when locking the index fails."
 	 3 files changed, 17 insertions(+), 3 deletions(-)
 
-This pulls the same change introduced in `e43a6`, but you get a new commit SHA-1 value, because the date applied is different. Now your history looks like Figura 5-27.
+Che replica le stesse modifiche introdotte in `e43a6`, ma produce una nuova commit con un suo SHA-1 differente perché le date sono diverse. La tua cronologia ora assomiglia a quella in Figura 5-27.
 
 Insert 18333fig0527.png
-Figura 5-27. History after cherry-picking a commit on a topic branch.
+Figura 5-27. Cronologia dopo lo _cherry-picking_ dal branch funzionale.
 
-Now you can remove your topic branch and drop the commits you didn’t want to pull in.
+Puoi ora eliminare il branch funzionale e cancellare le commit che non vuoi integrare.
 
 ### Tagging Your Releases ###
 

From f8de5f5929aea6bc1e5b880af52bdeb8063d9754 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Mon, 3 Feb 2014 20:26:16 -0600
Subject: [PATCH 190/690] Translated "Tagging Your Releases"

---
 it/05-distributed-git/01-chapter5.markdown | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/it/05-distributed-git/01-chapter5.markdown b/it/05-distributed-git/01-chapter5.markdown
index c69f91cb6..bf8ed6595 100755
--- a/it/05-distributed-git/01-chapter5.markdown
+++ b/it/05-distributed-git/01-chapter5.markdown
@@ -813,16 +813,16 @@ Figura 5-27. Cronologia dopo lo _cherry-picking_ dal branch funzionale.
 
 Puoi ora eliminare il branch funzionale e cancellare le commit che non vuoi integrare.
 
-### Tagging Your Releases ###
+### Tagga i tuoi rilasci ###
 
-When you’ve decided to cut a release, you’ll probably want to drop a tag so you can re-create that release at any point going forward. You can create a new tag as I discussed in Chapter 2. If you decide to sign the tag as the maintainer, the tagging may look something like this:
+Quando hai deciso di eseguire un rilascio probabilmente vorrai anche taggarla, così che tu possa ricrearla in qualsiasi momento nel futuro. Puoi aggiungere un nuovo tag come discusso nel Capitolo 2. Se vuoi firmare il tag in quanto mantenitore, il tag potrebbe apparire come il seguente:
 
 	$ git tag -s v1.5 -m 'my signed 1.5 tag'
 	You need a passphrase to unlock the secret key for
 	user: "Scott Chacon <schacon@gmail.com>"
 	1024-bit DSA key, ID F721C45A, created 2009-02-09
 
-If you do sign your tags, you may have the problem of distributing the public PGP key used to sign your tags. The maintainer of the Git project has solved this issue by including their public key as a blob in the repository and then adding a tag that points directly to that content. To do this, you can Figura out which key you want by running `gpg --list-keys`:
+Se firmi il tuo tag potresti avere il problema di distribuire la chiave PGP usata per firmarlo. Il mantenitore del progetto Git lo ha risolto includendo le chiavi dei mantenitori come un blob sul repository e aggiungendo quindi un tag che vi punti direttamente. Per farlo dovrai identificare la chiave che vuoi esportare eseguendo `gpg --list-keys`:
 
 	$ gpg --list-keys
 	/Users/schacon/.gnupg/pubring.gpg
@@ -831,20 +831,20 @@ If you do sign your tags, you may have the problem of distributing the public PG
 	uid                  Scott Chacon <schacon@gmail.com>
 	sub   2048g/45D02282 2009-02-09 [expires: 2010-02-09]
 
-Then, you can directly import the key into the Git database by exporting it and piping that through `git hash-object`, which writes a new blob with those contents into Git and gives you back the SHA-1 of the blob:
+Potrai quindi importare la chiave direttamente nel database di Git esportandola e mettendola in pipe con `git hash-object`, che scrive in Git un nuovo blob con il suo contenuto e ti restituisce l'hash SHA-1:
 
 	$ gpg -a --export F721C45A | git hash-object -w --stdin
 	659ef797d181633c87ec71ac3f9ba29fe5775b92
 
-Now that you have the contents of your key in Git, you can create a tag that points directly to it by specifying the new SHA-1 value that the `hash-object` command gave you:
+Ora che hai importato il contenuto della tua chiave in Git puoi creare un tag che vi punti direttamente, specificando l'SHA-1 appena ottenuto:
 
 	$ git tag -a maintainer-pgp-pub 659ef797d181633c87ec71ac3f9ba29fe5775b92
 
-If you run `git push --tags`, the `maintainer-pgp-pub` tag will be shared with everyone. If anyone wants to verify a tag, they can directly import your PGP key by pulling the blob directly out of the database and importing it into GPG:
+Se esegui `git push --tags` verrà condiviso con tutti il tag `maintainer-pgp-pub`. Se qualcuno volesse verificare il tag potrà farlo importando la tua chiave PGP scaricando il blob dal database e importandolo in GPG:
 
 	$ git show maintainer-pgp-pub | gpg --import
 
-They can use that key to verify all your signed tags. Also, if you include instructions in the tag message, running `git show <tag>` will let you give the end user more specific instructions about tag verification.
+Può quindi usare la chiave per verificare tutti i tag che hai firmato. Inoltre, se aggiungi delle istruzioni nel messaggio del tag, eseguendo `git show <tag>` darai all'utente finale maggiori informazioni specifiche su come verificare il tag.
 
 ### Generating a Build Number ###
 

From 5dd8e6b2b9cfe2d4f62499b3cc9ccc47cc036bb3 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Mon, 3 Feb 2014 20:46:34 -0600
Subject: [PATCH 191/690] Translated "Preparing a Release"

---
 it/05-distributed-git/01-chapter5.markdown | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/it/05-distributed-git/01-chapter5.markdown b/it/05-distributed-git/01-chapter5.markdown
index bf8ed6595..15c992b42 100755
--- a/it/05-distributed-git/01-chapter5.markdown
+++ b/it/05-distributed-git/01-chapter5.markdown
@@ -846,30 +846,30 @@ Se esegui `git push --tags` verrà condiviso con tutti il tag `maintainer-pgp-pu
 
 Può quindi usare la chiave per verificare tutti i tag che hai firmato. Inoltre, se aggiungi delle istruzioni nel messaggio del tag, eseguendo `git show <tag>` darai all'utente finale maggiori informazioni specifiche su come verificare il tag.
 
-### Generating a Build Number ###
+### Generare un numero di build ###
 
-Because Git doesn’t have monotonically increasing numbers like 'v123' or the equivalent to go with each commit, if you want to have a human-readable name to go with a commit, you can run `git describe` on that commit. Git gives you the name of the nearest tag with the number of commits on top of that tag and a partial SHA-1 value of the commit you’re describing:
+Poiché Git non usa una numerazione incrementale come 'v123' o un equivalente associato a ciascuna commit, se vuoi un nome per una commit che sia intellegibile, puoi usare il comando `git describe` su quella commit. Git restituirà il nome del tag più vicino assieme al numero di commit successivi e una parte dell'SHA-1 della commit che vuoi descrivere:
 
 	$ git describe master
 	v1.6.2-rc1-20-g8c5b85c
 
-This way, you can export a snapshot or build and name it something understandable to people. In fact, if you build Git from source code cloned from the Git repository, `git --version` gives you something that looks like this. If you’re describing a commit that you have directly tagged, it gives you the tag name.
+In questo modo puoi esportare un'istantanea o una build  echiamarla in modo che le persone possano capire. Se infatti fai una build di Git dai sorgenti clonati dal repository di Git repository, `git --version` ti restituirà qualcosa che gli assomigli. Se vuoi descrivere una commit che hai taggato, Git ti darà il nome del tag.
 
-The `git describe` command favors annotated tags (tags created with the `-a` or `-s` flag), so release tags should be created this way if you’re using `git describe`, to ensure the commit is named properly when described. You can also use this string as the target of a checkout or show command, although it relies on the abbreviated SHA-1 value at the end, so it may not be valid forever. For instance, the Linux kernel recently jumped from 8 to 10 characters to ensure SHA-1 object uniqueness, so older `git describe` output names were invalidated.
+Il comando `git describe` predilige i tag annotati (i tags creati con`-a` o `-s`) e quindi i tag dei rilasci dovrebbero essere creati in questo modo se usi `git describe`, per assicurarsi che le commit vengano denominate correttamente quando vengono descritte. Puoi usare questa stringa per i comandi `checkout` o `show`, sebbene il basarsi sull'SHA-1 abbreviato potrebbe renderla non valida per sempre. Per esempio, recentemente il kernel di Linux è passato recentemente da 8 a 10 caratteri per garantire l'unicità degli SHA-1 abbreviati, e quindi gli output precedenti di `git describe` non sono più validi.
 
-### Preparing a Release ###
+### Pronti per il rilascio ###
 
-Now you want to release a build. One of the things you’ll want to do is create an archive of the latest snapshot of your code for those poor souls who don’t use Git. The command to do this is `git archive`:
+Vuoi ora rilasciare una build. Una delle cose che vorrai fare sarà creare un archivio con l'ultima istantanea del tuo codice per quelle anime dannate che non usano Git. Il comando è `git archive`:
 
 	$ git archive master --prefix='project/' | gzip > `git describe master`.tar.gz
 	$ ls *.tar.gz
 	v1.6.2-rc1-20-g8c5b85c.tar.gz
 
-If someone opens that tarball, they get the latest snapshot of your project under a project directory. You can also create a zip archive in much the same way, but by passing the `--format=zip` option to `git archive`:
+Quando qualcuno aprirà questo  tarball, troverà l'ultima versione del tuo progetto nella directory `project`. Allo stesso modo puoi creare un archivio zip passando l'opzione `--format=zip` a `git archive`:
 
 	$ git archive master --prefix='project/' --format=zip > `git describe master`.zip
 
-You now have a nice tarball and a zip archive of your project release that you can upload to your website or e-mail to people.
+Ora hai un tarball e uno zip del rilascio del tuo progetto che puoi caricare sul tuo sito o inviare per email.
 
 ### The Shortlog ###
 

From 5e9e42a3388bbb797337ef1911c2999940e0a970 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Mon, 3 Feb 2014 22:27:42 -0600
Subject: [PATCH 192/690] Translated "The Shortlog"

---
 it/05-distributed-git/01-chapter5.markdown | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/it/05-distributed-git/01-chapter5.markdown b/it/05-distributed-git/01-chapter5.markdown
index 15c992b42..e40f43d4b 100755
--- a/it/05-distributed-git/01-chapter5.markdown
+++ b/it/05-distributed-git/01-chapter5.markdown
@@ -871,9 +871,9 @@ Quando qualcuno aprirà questo  tarball, troverà l'ultima versione del tuo prog
 
 Ora hai un tarball e uno zip del rilascio del tuo progetto che puoi caricare sul tuo sito o inviare per email.
 
-### The Shortlog ###
+### Lo Shortlog ###
 
-It’s time to e-mail your mailing list of people who want to know what’s happening in your project. A nice way of quickly getting a sort of changelog of what has been added to your project since your last release or e-mail is to use the `git shortlog` command. It summarizes all the commits in the range you give it; for example, the following gives you a summary of all the commits since your last release, if your last release was named v1.0.1:
+È il momento di inviare un'email alla lista di persone che vogliono sapere cosa succede nel tuo progetto. Un modo piacevole per produrre una specie di changelog delle modifiche dall'ultimo rilascio o dall'ultima email è usando il comando `git shortlog`, che riassume tutte le commit nell'intervallo dato. L'esempio seguente produce il sommario di tutte le commit dall'ultimo rilascio, assumento che lo abbia chiamato v1.0.1:
 
 	$ git shortlog --no-merges master --not v1.0.1
 	Chris Wanstrath (8):
@@ -890,7 +890,7 @@ It’s time to e-mail your mailing list of people who want to know what’s happ
 	      Version bump to 1.0.2
 	      Regenerated gemspec for version 1.0.2
 
-You get a clean summary of all the commits since v1.0.1, grouped by author, that you can e-mail to your list.
+Ottieni un sommario pulito di tutte le commit dalla v1.0.1, raggruppate per autore che puoi quindi inviare per email alla tua lista.
 
 ## Summary ##
 

From 5e0dd343b39107e30779b597ab5cd531aa4dea73 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Mon, 3 Feb 2014 22:31:13 -0600
Subject: [PATCH 193/690] Complete translation of chapter 5

---
 it/05-distributed-git/01-chapter5.markdown | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/it/05-distributed-git/01-chapter5.markdown b/it/05-distributed-git/01-chapter5.markdown
index e40f43d4b..adb3990f0 100755
--- a/it/05-distributed-git/01-chapter5.markdown
+++ b/it/05-distributed-git/01-chapter5.markdown
@@ -892,6 +892,6 @@ Ora hai un tarball e uno zip del rilascio del tuo progetto che puoi caricare sul
 
 Ottieni un sommario pulito di tutte le commit dalla v1.0.1, raggruppate per autore che puoi quindi inviare per email alla tua lista.
 
-## Summary ##
+## Sommario ##
 
-You should feel fairly comfortable contributing to a project in Git as well as maintaining your own project or integrating other users’ contributions. Congratulations on being an effective Git developer! In the next chapter, you’ll learn more powerful tools and tips for dealing with complex situations, which will truly make you a Git master.
+Dovresti sentirti ora a tuo agio nel contribuire a progetti Git, tanto quanto mantenere il tuo progetto o integrare i contributi di altri utenti. Congratulazione per essere un vero sviluppatore Git! Nel prossimo capitolo imparerai alcuni strumenti molto potenti e suggerimenti per affrontare situazione complesse che ti faranno diventare un maestro di Git.

From a57637487ca01d898cba5bbac356226d86b2be43 Mon Sep 17 00:00:00 2001
From: cor <git@cpt1.demon.nl>
Date: Tue, 4 Feb 2014 20:35:03 +0100
Subject: [PATCH 194/690] [nl] Retranslate chapter 06, clarify some of the
 sentences and remove Babelfishes.

---
 nl/06-git-tools/01-chapter6.markdown | 314 ++++++++++++++-------------
 1 file changed, 165 insertions(+), 149 deletions(-)

diff --git a/nl/06-git-tools/01-chapter6.markdown b/nl/06-git-tools/01-chapter6.markdown
index e0e619490..9dbbf4cca 100644
--- a/nl/06-git-tools/01-chapter6.markdown
+++ b/nl/06-git-tools/01-chapter6.markdown
@@ -1,20 +1,20 @@
 # Git tools #
 
-Nu heb je de meeste commando's en werkwijzen geleerd die je dagelijks nodig hebt om een Git repository voor je broncode te beheren en te onderhouden. Je hebt de basistaken van het tracken en committen van bestanden uitgevoerd, en je hebt de kracht van de staging area en lichtgewicht topic branching en mergen in handen.
+Nu heb je de meeste commando's en werkwijzen geleerd die je dagelijks nodig hebt om een Git repository voor je broncode te beheren en te onderhouden. Je hebt de basistaken van het tracken en committen van bestanden onder de knie, en je hebt de kracht van de staging area en lichtgewicht topic branching en mergen in de vingers.
 
-Nu ga je een aantal zeer krachtige dingen verkennen die Git kan, die je niet per se dagelijks gebruikt, maar die je op een bepaald punt toch nodig kunt hebben.
+Nu ga je een aantal zeer krachtige dingen verkennen die Git kan, die je niet per se dagelijks gebruikt, maar die je op een bepaald moment toch nodig kunt gaan hebben.
 
 ## Revisie selectie ##
 
-Git staat je toe om specifieke commits of een serie commits op meerdere manieren te specificeren. Ze zijn niet per se voor de hand liggend, maar behulpzaam om te weten.
+Git stelt je in staat om specifieke commits of een serie commits op diverse manieren te specificeren. Ze zijn niet per se voor de hand liggend, maar behulpzaam om te weten.
 
 ### Enkele revisies ###
 
-Natuurlijk kun je naar een commit refereren door de SHA-1 hash die het toegekend is, maar er zijn ook meer mensvriendelijke manieren om naar een commit te refereren. Deze sectie laat de diverse manieren zien waarop je naar een enkele commit kunt refereren.
+Natuurlijk kun je naar een commit refereren door de SHA-1 hash die het toegekend is, maar er zijn ook meer mensvriendelijke manieren om naar een commit te refereren. In deze paragraaf worden diverse manieren getoond waarop je naar een enkele commit kunt refereren.
 
 ### Korte SHA ###
 
-Git is slim genoeg om uit te vinden welke commit je bedoelde te typen als je de eerste karakters opgeeft, zolang je gedeeltelijke SHA-1 minstens vier karakters lang en ondubbelzinnig is – dat wil zeggen dat slechts één object in de huidige repository begint met die gedeeltelijke SHA-1.
+Git is slim genoeg om uit te vinden welke commit je bedoelde te typen als je het de eerste karakters geeft, zolang je gedeeltelijke SHA-1 minstens vier karakters lang en ondubbelzinnig is; dat wil zeggen dat slechts één object in de huidige repository begint met die gedeeltelijke SHA-1.
 
 Bijvoorbeeld, stel dat je om een specifieke commit te zien een `git log` commando uitvoert en de commit identificeert waarin je een bepaalde functionaliteit hebt toegevoegd:
 
@@ -38,13 +38,13 @@ Bijvoorbeeld, stel dat je om een specifieke commit te zien een `git log` command
 
 	    added some blame and merge stuff
 
-In dit geval, kies `1c002dd...`. Als je op die commit `git show` uitvoert, dan zijn de volgende commando's equivalent (aangenomen dat de kortere versies ondubbelzinnig zijn):
+In dit geval, kiezen we `1c002dd....`. Als je op die commit `git show` uitvoert, dan zijn de volgende commando's gelijkwaardig (aangenomen dat de kortere versies ondubbelzinnig zijn):
 
 	$ git show 1c002dd4b536e7479fe34593e72e6c6c1819e53b
 	$ git show 1c002dd4b536e7479f
 	$ git show 1c002d
 
-Git kan een korte unieke afkorting voor je SHA-1 waardes uitvinden. Als je `--abbrev-commit` meegeeft aan het `git log` commando, dan zal de output kortere waarden gebruiken maar ze uniek houden; het gebruikt standaard zeven karakters, maar maakt ze langer om de SHA-1 ondubbelzinnig te houden:
+Git kan met een korte unieke afkorting voor je SHA-1 waarde uit de voeten. Als je `--abbrev-commit` meegeeft aan het `git log` commando, dan zal de output kortere waarden gebruiken maar ze uniek houden; het gebruikt standaard zeven karakters maar maakt ze langer indien nodig om de SHA-1 ondubbelzinnig te houden:
 
 	$ git log --abbrev-commit --pretty=oneline
 	ca82a6d changed the version number
@@ -53,15 +53,15 @@ Git kan een korte unieke afkorting voor je SHA-1 waardes uitvinden. Als je `--ab
 
 Over het algemeen zijn acht tot tien karakters meer dan voldoende om binnen een project uniek te zijn. Een van de grootste Git projecten, de Linux kernel, begint 12 karakters van de mogelijke 40 nodig te hebben om uniek te blijven.
 
-### Een korte notitie over SHA-1 ###
+### EEN KORTE NOTITIE OVER SHA-1 ###
 
-Veel mensen zijn bezorgd geworden dat ze op een bepaald punt, door random toeval, twee objecten in hun repository hebben die naar dezelfde SHA-1 waarde hashen. Wat dan?
+Veel mensen beginnen bezorgd te raken dat ze op een bepaald moment door puur toeval, twee objecten in hun repository hebben die naar dezelfde SHA-1 waarde hashen. Wat dan?
 
-Mocht je een object committen dat hashed naar dezelfde SHA-1 waarde als een vorig object in je repository, dan zal Git het vorige reeds aanwezige object in je Git database zien en aannemen dat het al geschreven was. Als je dat object opnieuw probeert uit te checken op een bepaald punt, dan zul je altijd de gegevens van het eerste object krijgen.
+Mocht je een object committen dat hashed naar dezelfde SHA-1 waarde als een vorig object in je repository, dan zal Git het vorige reeds aanwezige object in je Git database zien en aannemen dat het al geschreven was. Als je dat object opnieuw probeert uit te checken op een bepaald moment, dan zul je altijd de gegevens van het eerste object krijgen.
 
-Maar, je moet je bewust zijn hoe belachelijk onwaarschijnlijk dit scenario is. De SHA-1 waarde is 20 bytes of 160 bits. Het aantal benodigde random gehashte objecten om een 50% waarschijnlijkheid van een enkele botsing te garanderen is ongeveer 2^80 (de formule om botsingswaarschijnlijkheid te bepalen is `p = (n(n-1)/2) * (1/2^160)`). 2^80 is 1.2 x 10^24 of 1 miljoen miljard miljard. Dat is 1.200 keer het aantal zandkorrels op de aarde.
+Maar, je moet je bewust zijn hoe vreselijk onwaarschijnlijk dit scenario is. De SHA-1 waarde is 20 bytes, of 160 bits. Het aantal benodigde random gehashte objecten om een 50% waarschijnlijkheid van een botsing te garanderen is ongeveer 2^80 (de formule om botsingswaarschijnlijkheid te bepalen is `p = (n(n-1)/2) * (1/2^160)`). 2^80 is 1.2 x 10^24 of 1 miljoen miljard miljard. Dat is 1.200 keer het aantal zandkorrels op de aarde.
 
-Hier is een voorbeeld om je een idee te geven wat er voor nodig is om een SHA-1 botsing te krijgen. Als alle 6.5 miljard mensen op aarde zouden gaan programmeren, en iedere seconde zou iedereen code genereren die gelijk was aan de hele Linux kernel-geschiedenis (1 miljoen Git objecten) en dat in één gigantische Git repository pushen, dan zou het vijf jaar duren voordat die repository genoeg objecten zou bevatten om een 50% waarschijnlijkheid van één enkele SHA-1 object botsing te krijgen. Er bestaat een grotere kans dat ieder lid van je programmeerteam zal worden aangevallen en worden gedood door wolven in ongerelateerde incidenten op dezelfde avond.
+Hier is een voorbeeld om je een idee te geven wat er voor nodig is om een SHA-1 botsing te krijgen. Als alle 6.5 miljard mensen op aarde zouden programmeren, en iedere seconde zou ieder van hen code genereren die gelijk was aan de hele Linux kernel-geschiedenis (1 miljoen Git objecten) en dat in één gigantische Git repository pushen, dan zou het vijf jaar duren voordat die repository genoeg objecten zou bevatten om een 50% waarschijnlijkheid van één enkele SHA-1 object botsing te krijgen. Er bestaat een grotere kans dat elk lid van je programmeerteam zal worden aangevallen en gedood door wolven in ongerelateerde incidenten op dezelfde avond.
 
 ### Branch referenties ###
 
@@ -70,14 +70,14 @@ De meest eenvoudige manier om een commit te specificeren heeft als voorwaarde da
 	$ git show ca82a6dff817ec66f44342007202690a93763949
 	$ git show topic1
 
-Als je wil zien naar welke specifieke SHA een branch wijst, of als je wil zien wat ieder van deze voorbeelden in termen van SHA's voorstellen, dan kun je een Git onderwatertool genaamd `rev-parse` gebruiken. Je kunt in Hoofdstuk 9 kijken voor meer informatie over onderwatertools; eigenlijk bestaat `rev-parse` voor low-level operaties en is niet ontworpen om in dagelijkse operaties gebruikt te worden. Maar, het kan behulpzaam zijn op momenten dat je moet zien wat er echt aan de hand is. Hier kun je `rev-parse` uitvoeren op je branch.
+Als je wil zien naar welke specifieke SHA een branch wijst, of als je wil zien wat ieder van deze voorbeelden in termen van SHA's voorstellen, dan kun je een Git sanitaire voorzieningen (plumbin) tool genaamd `rev-parse` gebruiken. Je kunt in Hoofdstuk 9 kijken voor meer informatie over plumbingtools, eigenlijk is `rev-parse` er voor low-level operaties en is niet ontworpen voor dagelijks gebruik. Maar het kan behulpzaam zijn op momenten dat je moet zien wat er echt aan de hand is. Hier kun je `rev-parse` uitvoeren op je branch.
 
 	$ git rev-parse topic1
 	ca82a6dff817ec66f44342007202690a93763949
 
-### RefLog afkortingen ###
+### RefLog verkorte namen ###
 
-Een van de dingen die Git in de achtergrond doet terwijl jij zit te werken is een reflog bijhouden – een log waar je HEAD en branchreferenties zijn gebleven in de laatste paar maanden.
+Een van de dingen die Git in de achtergrond doet terwijl jij zit te werken is een reflog bijhouden: een log waar de staat van HEAD en branchreferenties in de laatste paar maanden in is vastgelegd.
 
 Je kunt je reflog zien door `git reflog` te gebruiken:
 
@@ -90,7 +90,7 @@ Je kunt je reflog zien door `git reflog` te gebruiken:
 	1c36188... HEAD@{5}: rebase -i (squash): updating HEAD
 	7e05da5... HEAD@{6}: rebase -i (pick): updating HEAD
 
-Iedere keer als de punt van je branch om een of andere reden is gewijzigd, dan bewaart Git die informatie voor je in deze tijdelijke geschiedenis. En je kunt ook oudere commits hiermee specificeren. Als je de vijfde voorgaande waarde van de HEAD van je repository wil zien, dan kun je de `@{n}` referentie gebruiken, die je in de reflog output kunt zien:
+Iedere keer als de punt van je branch om een of andere reden is gewijzigd, dan bewaart Git die informatie voor je in deze tijdelijke geschiedenis. En je kunt ook oudere commits met deze gegevens specificeren. Als je de vijfde voorgaande waarde van de HEAD van je repository wilt zien, dan kun je de `@{n}` referentie gebruiken, die je in de reflog output kunt zien:
 
 	$ git show HEAD@{5}
 
@@ -100,7 +100,7 @@ Je kunt deze syntax ook gebruiken om te zien waar een branch een bepaalde hoevee
 
 Dat laat je zien waar de punt van de branch gisteren was. Deze techniek werkt alleen voor gegevens die nog steeds in je reflog staan, dus je kunt het niet gebruiken om te kijken naar commits die ouder zijn dan een paar maanden.
 
-Om reflog informatie te zien, die in hetzelfde formaat gezet is als de `git log` output, kun je `git log -g` uitvoeren:
+Om reflog informatie te zien, in hetzelfde formaat als de `git log` output, kun je `git log -g` uitvoeren:
 
 	$ git log -g master
 	commit 734713bc047d87bf7eac9674765ae793478c50d3
@@ -119,11 +119,11 @@ Om reflog informatie te zien, die in hetzelfde formaat gezet is als de `git log`
 
 	    Merge commit 'phedders/rdocs'
 
-Het is belangrijk om te zien dat deze informatie strikt lokaal is – het is een log van wat jij hebt gedaan in jouw repository. De referenties zullen niet hetzelfde zijn in iemand anders zijn kopie van de repository; en meteen nadat je een eerste kloon van een repository hebt gemaakt, heb je een lege reflog, omdat er nog geen activiteit is geweest in je repository. `git show HEAD@{2.months.ago}` uitvoeren werkt alleen als je het project minstens twee maanden geleden gekloond hebt – als je het vijf minuten geleden gekloond hebt, krijg je geen resultaten.
+Het is belangrijk om te zien dat deze informatie strikt lokaal is, het is een log van wat je hebt gedaan in jouw repository. De referenties zullen niet hetzelfde zijn in de kopie van de repository die iemand anders gemaakt heeft, en meteen nadat je een eerste kloon van een repository hebt gemaakt heb je een lege reflog, omdat er nog geen activiteit is geweest in je repository. `git show HEAD@{2.months.ago}` uitvoeren werkt alleen als je het project minstens twee maanden geleden gekloond hebt, als je het vijf minuten geleden gekloond hebt krijg je geen resultaten.
 
 ### Voorouder referenties ###
 
-De andere veelgebruikte manier om een commit te specificeren is via zijn voorouder. Als je een `^` aan het einde van een referentie zet, zal Git hieruit herleiden dat het de ouder van de commit betekent.
+De andere veelgebruikte manier om een commit te specificeren is via zijn voorouders. Als je een `^` aan het einde van een referentie zet zal Git hieruit herleiden dat het de ouder van die commit betekent.
 Stel dat je naar de geschiedenis van je project kijkt:
 
 	$ git log --pretty=format:'%h %s' --graph
@@ -146,7 +146,7 @@ Dan zie je de vorige commit door `HEAD^` te specificeren, wat "de ouder van HEAD
 
 	    Merge commit 'phedders/rdocs'
 
-Je kunt ook een nummer na de `^` zetten – bijvoorbeeld, `d921970^2` betekent "de tweede ouder van d921970." Deze syntax is alleen bruikbaar voor merge commits, die meer dan één ouder hebben. De eerste ouder is de branch waar jij op was toen je merge-te, en de andere is de commit op de branch die je ingemerged hebt:
+Je kunt ook een getal na de `^` zetten, bijvoorbeeld `d921970^2` betekent "de tweede ouder van d921970." Deze syntax is alleen bruikbaar voor merge commits, die meer dan één ouder hebben. De eerste ouder is de branch waar jij op was toen je mergede, en de andere is de commit op de branch die je gemerged hebt:
 
 	$ git show d921970^
 	commit 1c002dd4b536e7479fe34593e72e6c6c1819e53b
@@ -162,7 +162,7 @@ Je kunt ook een nummer na de `^` zetten – bijvoorbeeld, `d921970^2` betekent "
 
 	    Some rdoc changes
 
-De andere manier om ouders mee te specificeren is de `~`. Dit refereert ook naar de eerste ouder, dus `HEAD~` en `HEAD^` zijn gelijk. Het verschil wordt duidelijk als je een nummer specificeert. `HEAD~2` betekent "de eerste ouder van de eerste ouder", of "de grootouder" – het bewandelt de eerste ouders het aantal keren dat je specificeert. Bijvoorbeeld, in de geschiedenis die eerder getoond werd, zou `HEAD~3` zijn
+De andere manier om voorouders mee te specificeren is de `~`. Dit refereert ook naar de eerste ouder, dus `HEAD~` en `HEAD^` zijn gelijk. Het verschil wordt pas duidelijk als je een getal specificeert. `HEAD~2` betekent "de eerste ouder van de eerste ouder", of "de grootouder", het doorloopt de eerste ouders het aantal keren dat je specificeert. Bijvoorbeeld, in de geschiedenis die eerder getoond werd, zou `HEAD~3` het volgende resultaat geven
 
 	$ git show HEAD~3
 	commit 1c3618887afb5fbcbea25b7c013f4e2114448b8d
@@ -171,7 +171,7 @@ De andere manier om ouders mee te specificeren is de `~`. Dit refereert ook naar
 
 	    ignore *.gem
 
-Dit kan ook geschreven worden als `HEAD^^^`, wat nogmaals de eerste ouder van de eerste ouder van de eerste ouder is:
+Dit kan ook geschreven worden als `HEAD^^^` wat, nogmaals, de eerste ouder van de eerste ouder van de eerste ouder is:
 
 	$ git show HEAD^^^
 	commit 1c3618887afb5fbcbea25b7c013f4e2114448b8d
@@ -180,26 +180,26 @@ Dit kan ook geschreven worden als `HEAD^^^`, wat nogmaals de eerste ouder van de
 
 	    ignore *.gem
 
-Je kunt deze syntaxen combineren – je kunt de tweede ouder van de vorige reference krijgen (aangenomen dat het een merge commit was) door `HEAD~3^2` te gebruiken, enzovoort.
+Je kunt deze syntaxen combineren: je kunt de tweede ouder van de vorige referentie krijgen (aangenomen dat het een merge commit was) door `HEAD~3^2` te gebruiken, enzovoort.
 
 ### Commit reeksen ###
 
-Nu dat je individuele commits kunt specificeren, laten we zien hoe je reeksen van commits kunt specificeren. Dit is erg bruikbaar om je branches te beheren – als je veel branches hebt, kun je reeks specificaties gebruiken om vragen te beantwoorden zoals, "Wat voor werk zit er op deze branch dat ik nog niet in mijn hoofdbranch heb?"
+Nu je individuele commits kunt specificeren, laten we zien hoe je reeksen van commits kunt specificeren. Dit is vooral erg bruikbaar bij het beheren van je branches; als je veel branches hebt, kan je reeks-specificaties gebruiken om vragen te beantwoorden als: "Wat voor werk zit er op deze branch dat ik nog niet in mijn hoofdbranch heb?"
 
-#### Dubbele punt ####
+#### Dubbel-punt ####
 
-De meest voorkomende reeks specificatie is de dubbele punt syntax. Dit vraagt Git een reeks commits op te zoeken, die bereikbaar zijn van één commit maar niet vanuit een ander. Bijvoorbeeld, stel dat je een commitgeschiedenis hebt die eruit ziet zoals in Figuur 6-1.
+De meest voorkomende reeks specificatie is de dubbel-punt syntax. Dit vraagt Git een reeks commits op te zoeken, die bereikbaar zijn van de ene commit maar niet vanuit een ander. Bijvoorbeeld, stel dat je een commit-geschiedenis hebt die eruit ziet zoals in Figuur 6-1.
 
 Insert 18333fig0601.png
-Figuur 6-1. Voorbeeldgeschiedenis voor reeksselectie.
+Figuur 6-1. Voorbeeldgeschiedenis voor reeks-selectie.
 
-Je wilt zien wat er in je experimentele branch zit dat nog niet in je hoofdbranch gemerged is. Je kunt Git vragen om je een log te tonen van alleen die commits met `master..experiment` – wat betekent "alle commits die bereikbaar zijn door experiment, die niet bereikbaar zijn door master". Om de voorbeelden kort en duidelijk te houden zal ik de letters van de commitobjecten in het diagram gebruiken in plaats van de echte log output, in de volgorde waarin ze getoond zouden worden:
+Je wilt zien wat er in je experimentele branch zit dat nog niet in je hoofdbranch gemerged is. Je kunt Git vragen om je een log te tonen van alleen die commits met `master..experiment`, wat zoveel betekent als "alle commits die bereikbaar zijn voor experiment, die niet bereikbaar zijn voor master". Om de voorbeelden kort en duidelijk te houden zal ik de letters van de commitobjecten in het diagram gebruiken in plaats van de echte log output, in de volgorde waarin ze getoond zouden worden:
 
 	$ git log master..experiment
 	D
 	C
 
-Als je aan de andere kant het tegenovergestelde wilt zien – alle commits in `master` die niet bereikbaar zijn in `experiment` – dan kun je de branchnamen omdraaien. `experiment..master` toont je alles in `master` wat niet bereikbaar is in `experiment`:
+Als je echter het tegenovergestelde wilt zien: alle commits in `master` die niet bereikbaar zijn in `experiment`, dan moet je de branchnamen omdraaien. `experiment..master` toont je alles in `master` wat niet bereikbaar is vanuit `experiment`:
 
 	$ git log experiment..master
 	F
@@ -209,23 +209,23 @@ Dit is handig als je de `experiment` branch up to date wilt houden en vast wilt
 
 	$ git log origin/master..HEAD
 
-Dit commando toont je alle commits in je huidige branch, die niet in de `master` branch op je `origin` remote zitten. Als je een `git push` uitvoert, en je huidige branch volgt de `origin/master`, dan zijn de commits die getoond worden door `git log origin/master..HEAD` de commits die verstuurd zullen worden naar de server.
-Je kunt ook één kant van de syntax weglaten en Git de HEAD laten aannemen. Bijvoorbeeld, je krijgt dezelfde resultaten als in het vorige voorbeeld door `git log origin/master..` te typen – Git vult HEAD in als er een kant mist.
+Dit commando toont je alle commits in je huidige branch, die niet in de `master` branch op je remote `origin` zitten. Als je een `git push` uitvoert, en je huidige branch volgt de `origin/master`, dan zijn de commits die getoond worden door `git log origin/master..HEAD` de commits die verstuurd zullen worden naar de server.
+Je kunt ook één kant van de syntax weglaten om Git de HEAD laten aannemen. Bijvoorbeeld, je krijgt dezelfde resultaten als in het vorige voorbeeld door `git log origin/master..` te typen; Git vult HEAD in als er één kant ontbreekt.
 
 #### Meerdere punten ####
 
-De dubbele punt is makkelijk als een afkorting; maar misschien wil je meer dan twee branches specificeren om je revisie aan te geven, zoals zien welke commits in één van een serie branches zit, die nog niet in de branch zit waar je nu op zit. Git laat je dit doen door of het `^` karakter te gebruiken, of `--not` voor iedere referentie waarvan je de bereikbare commits niet wilt zien. Dus deze drie commando's zijn gelijk:
+De syntax met de dubbel-punt is makkelijk als een afkorting, maar misschien wil je meer dan twee branches specificeren om je revisie aan te geven, zoals het zien welke commits in één van een serie branches zit, die nog niet in de branch zit waar je nu op zit. Git laat je dit doen door of het `^` karakter te gebruiken, of `--not` voor iedere referentie waarvan je de bereikbare commits niet wilt zien. Dus deze drie commando's zijn gelijk:
 
 	$ git log refA..refB
 	$ git log ^refA refB
 	$ git log refB --not refA
 
-Dit is fijn omdat met deze syntax je meer dan twee referenties in je vraag kunt specificeren, wat je niet met de dubbele put syntax kan. Bijvoorbeeld, als je alle commits wilt zien die bereikbaar zijn vanuit `refA` of `refB`, maar niet vanuit `refC`, dan kun je één van deze intypen:
+Dit is prettig omdat met deze syntax je meer dan twee referenties in je vraag kunt specificeren, wat je niet met de dubbel punt syntax kan. Bijvoorbeeld, als je alle commits wilt zien die bereikbaar zijn vanuit `refA` of `refB`, maar niet vanuit `refC`, dan kun je één van deze intypen:
 
 	$ git log refA refB ^refC
 	$ git log refA refB --not refC
 
-Dit zorgt voor een erg krachtig revisie vraagsysteem dat je zou moeten helpen om uit te zoeken wat in je branches zit.
+Dit zorgt voor een erg krachtig revisie vraagsysteem dat je kan helpen om uit te zoeken wat in je branches zit.
 
 #### Drievoudige punt ####
 
@@ -238,7 +238,7 @@ Als je wilt zien wat in je `master` of in je `experiment` zit, maar geen gedeeld
 	D
 	C
 
-Nogmaals, dit geeft je normale `log` output, maar toont je alleen de commitinformatie voor die vier commits, getoond in de traditionele committijdstip volgorde.
+Nogmaals, dit geeft je normale `log` output, maar toont je alleen de commit-informatie voor deze vier commits, getoond in de traditionele volgorde van committijdstip.
 
 Een veelgebruikte optie bij het `log` command in dit geval is `--left-right`, wat je laat zien aan welke kant van de reeks elke commit zit. Dit helpt de data bruikbaarder te maken:
 
@@ -252,8 +252,8 @@ Met deze tools, kun je Git eenvoudiger laten weten welke commit of commits je wi
 
 ## Interactief stagen ##
 
-Bij Git zitten een aantal scripts, die sommige commandline taken makkelijker maken. Hier zul je een aantal interactieve commando's zien, die je kunnen helpen om je commits zo te maken dat ze alleen bepaalde combinaties en delen van bestanden bevatten. Deze tools zijn erg bruikbaar als je een serie bestanden aanpast en dan besluit dat je deze veranderingen in een aantal gefocuste commits wilt hebben in plaats van een rommelige commit. Op deze manier ben je er zeker van dat je commits logische aparte wijzigingensets zijn en makkelijk gereviewed kunnen worden door je mede-ontwikkelaars.
-Als je `git add` uitvoert met de `-i` of `--interactive` optie, dan gaat Git over in de interactieve shell modus, waarbij zoiets als dit getoond wordt:
+Bij Git zitten een aantal scripts, die sommige commandline taken makkelijker maken. Hier zul je een aantal interactieve commando's zien, die je kunnen helpen om je commits zo te maken dat ze alleen bepaalde combinaties en delen van bestanden bevatten. Deze tools zijn erg nuttig als je een serie bestanden aanpast en dan besluit dat je deze veranderingen in een aantal gefocuste commits wilt hebben in plaats van één grote rommelige commit. Op deze manier ben je er zeker van dat je commits logische aparte wijzigingensets zijn en makkelijk gereviewed kunnen worden door je mede-ontwikkelaars.
+Als je `git add` uitvoert met de `-i` of `--interactive` optie, dan schakelt Git over naar een interactieve shell modus, waarbij zoiets als dit getoond wordt:
 
 	$ git add -i
 	           staged     unstaged path
@@ -266,9 +266,9 @@ Als je `git add` uitvoert met de `-i` of `--interactive` optie, dan gaat Git ove
 	  5: patch      6: diff        7: quit       8: help
 	What now>
 
-Je kunt zien dat dit commando je een heel andere view van je staging area geeft – eigenlijk dezelfde informatie die je krijgt met het `git status` commando, maar dan compacter en meer informatief. Het toont links de wijzigingen die je gestaged hebt, en de niet gestagede wijzigingen rechts.
+Je kunt zien dat dit commando je een heel andere kijk op je staging area geeft: eigenlijk dezelfde informatie die je krijgt met het `git status` commando, maar dan compacter en meer informatief. Het toont links de wijzigingen die je gestaged hebt, en de niet gestagede wijzigingen rechts.
 
-Hierna volgt een commandosectie. Hier kun je een aantal dingen mee doen, inclusief bestanden stagen, bestanden unstagen, delen van bestanden stagen, ongevolgde bestanden toevoegen, en diffs zien van wat gestaged is.
+Hierna volgt een commando-sectie. Hier kun je een aantal dingen doen, staging bestanden toevoegen, bestanden unstagen, delen van bestanden stagen, ongevolgde bestanden toevoegen, en diffs zien van wat gestaged is.
 
 ### Bestanden stagen en unstagen ###
 
@@ -281,7 +281,7 @@ Als je `2` of `u` op de `What now>` prompt typt, dan vraagt het script welke bes
 	  3:    unchanged        +5/-1 lib/simplegit.rb
 	Update>>
 
-Om de TODO en index.html bestanden te stagen, kun je de nummers typen:
+Om de TODO en index.html bestanden te stagen, kun je de getallen typen:
 
 	Update>> 1,2
 	           staged     unstaged path
@@ -290,7 +290,7 @@ Om de TODO en index.html bestanden te stagen, kun je de nummers typen:
 	  3:    unchanged        +5/-1 lib/simplegit.rb
 	Update>>
 
-De `*` naast ieder bestand betekent dat het bestand geselecteerd staat om gestaged te worden. Als je Enter indrukt na niets getypt te hebben op de `Update>>` prompt, dan zal Git alles wat geselecteerd staat pakken en voor je stagen:
+De `*` naast ieder bestand geeft aan dat het bestand geselecteerd staat om gestaged te worden. Als je Enter indrukt na niets getypt te hebben op de `Update>>` prompt, dan zal Git alles wat geselecteerd staat pakken en voor je stagen:
 
 	Update>>
 	updated 2 paths
@@ -322,7 +322,7 @@ Nu kun je zien dat de TODO en index.html bestanden gestaged zijn, en het simpleg
 	Revert>> [enter]
 	reverted one path
 
-Nogmaals kijkend naar je Git status, kun je zien dat je het TODO bestand unstaged hebt:
+Als je nu nog eens naar je Git status kijkt, kun je zien dat je het TODO bestand ge-unstaged hebt:
 
 	*** Commands ***
 	  1: status     2: update      3: revert     4: add untracked
@@ -333,7 +333,7 @@ Nogmaals kijkend naar je Git status, kun je zien dat je het TODO bestand unstage
 	  2:        +1/-1      nothing index.html
 	  3:    unchanged        +5/-1 lib/simplegit.rb
 
-Om de diff te zien van wat je gestaged hebt, kun je het `6` of `d` (voor diff) commando gebruiken. Het toont je een lijst van je gestagede bestanden, en je kunt degenen selecteren waarvan je de gestagede diff wilt zien. Dit is vergelijkbaar met het specificeren van `git diff --cached` op de commando regel:
+Om de diff te zien van wat je gestaged hebt, kun je het `6` of `d` (voor diff) commando gebruiken. Het toont je een lijst van je gestagede bestanden, en je kunt diegenen selecteren waarvan je de gestagede diff wilt zien. Dit is vergelijkbaar met het specificeren van `git diff --cached` op de commando regel:
 
 	*** Commands ***
 	  1: status     2: update      3: revert     4: add untracked
@@ -355,11 +355,11 @@ Om de diff te zien van wat je gestaged hebt, kun je het `6` of `d` (voor diff) c
 
 	 <script type="text/javascript">
 
-Met deze basiscommando's kun je de interactieve toevoegmodus gebruiken om een beetje makkelijker met je staging area om te gaan.
+Met deze basiscommando's kun je de interactieve toevoegmodus gebruiken om een iets makkelijker manier met je staging area om te gaan.
 
 ### Patches stagen ###
 
-Het is ook mogelijk met Git om bepaalde delen van bestanden te stagen en de rest niet. Bijvoorbeeld, als je twee wijzigingen maakt in je simplegit.rb bestand en één van die twee wilt stagen en de andere niet, dan is dat eenvoudig in Git. Vanaf de interactieve prompt, type `5` of `p` (voor patch). Git zal je vragen welke bestanden je deels wilt stagen; dan, voor iedere sectie van de geselecteerde bestanden, zal het stukken van de bestandsdiff tonen en je vragen of je ze wilt stagen, één voor één:
+Het is met Git ook mogelijk om bepaalde delen van bestanden te stagen en de rest niet. Bijvoorbeeld, als je twee wijzigingen maakt in je simplegit.rb bestand en één van die twee wilt stagen en de andere niet, dan is dat eenvoudig in Git. Vanaf de interactieve prompt, type `5` of `p` (voor patch). Git zal je vragen welke bestanden je deels wilt stagen en daarna, voor iedere sectie van de geselecteerde bestanden, zal het stukken van de bestandsdiff tonen en je vragen of je ze wilt stagen, één voor één:
 
 	diff --git a/lib/simplegit.rb b/lib/simplegit.rb
 	index dd5ecc4..57399e0 100644
@@ -376,7 +376,7 @@ Het is ook mogelijk met Git om bepaalde delen van bestanden te stagen en de rest
 	   def blame(path)
 	Stage this hunk [y,n,a,d,/,j,J,g,e,?]?
 
-Op dit punt heb je veel opties. Door `?` te typen krijg je een lijst met wat je kunt doen:
+Hier heb je erg veel opties. Door `?` te typen krijg je een lijst met wat je kunt doen:
 
 	Stage this hunk [y,n,a,d,/,j,J,g,e,?]? ?
 	y - stage this hunk
@@ -393,7 +393,7 @@ Op dit punt heb je veel opties. Door `?` te typen krijg je een lijst met wat je
 	e - manually edit the current hunk
 	? - print help
 
-Over het algemeen zul je `y` of `n` typen als je ieder stuk wilt stagen, maar ze allemaal ineens stagen voor bepaalde bestanden, of een beslissen een stuk over te slaan tot later kan ook behulpzaam zijn. Als je een gedeelte van het bestand wilt stagen en een ander gedeelte unstaged wilt laten, dan zal je status output er zo uitzien:
+Over het algemeen zul je `y` of `n` typen als je ieder stuk wilt stagen, maar voor bepaalde bestanden ze allemaal ineens te stagen, of voor een bepaald stuk de beslissing uit te stellen kan ook behulpzaam zijn. Als je een gedeelte van het bestand wilt stagen en een ander gedeelte unstaged wilt laten, dan zal je status output er zo uitzien:
 
 	What now> 1
 	           staged     unstaged path
@@ -401,19 +401,19 @@ Over het algemeen zul je `y` of `n` typen als je ieder stuk wilt stagen, maar ze
 	  2:        +1/-1      nothing index.html
 	  3:        +1/-1        +4/-0 lib/simplegit.rb
 
-De status van het simplegit.rb bestand is interessant. Het laat zien dat een paar regels gestaged zijn, en een paar niet. Je hebt dit bestand deels gestaged. Op dit punt kun je het interactieve toevoeg script verlaten en het `git commit` commando uitvoeren om de gedeeltelijk gestagede bestanden te committen.
+De status van het simplegit.rb bestand is interessant. Het laat zien dat een paar regels gestaged zijn, en een paar niet. Je hebt dit bestand deels gestaged. Nu kan je het interactieve toevoeg script verlaten en het `git commit` commando uitvoeren om de gedeeltelijk gestagede bestanden te committen.
 
-Tot slot hoef je niet in de interactieve toevoeg modus te zijn om het gedeeltelijke bestands-stagen te doen – je kunt hetzelfde script starten door `git add -p` of `git add --patch` op de commando regel te gebruiken.
+Tot slot hoef je niet in de interactieve toevoeg modus te zijn om het gedeeltelijke bestands-stagen te doen, je kunt hetzelfde script starten door `git add -p` of `git add --patch` op de commando regel te gebruiken.
 
 ## Stashen ##
 
-Vaak, als je aan een deel van je project hebt zitten werken, zijn de dingen in een rommelige staat en wil je van branch veranderen om aan wat anders te werken. Het probleem is dat je geen halfklaar werk wilt committen, alleen maar om later verder te kunnen gaan op dit punt. Het antwoord op dit probleem is het `git stash` commando.
+Vaak als je aan een deel van je project hebt zitten werken, zijn de dingen in een rommelige staat en wil je van branch veranderen om aan iets anders te werken. Het probleem is dat je geen halfklaar werk wilt committen, alleen maar om later verder te kunnen gaan vanaf hetzelfde punt. Het antwoord op dit probleem is het `git stash` commando.
 
-Stashen pakt de vervuilde status van je werkmap – dat wil zeggen, je gewijzigde gevolgde bestanden en gestagede wijzigingen – en bewaard het op een stapel onafgemaakte wijzigingen, die je op ieder tijdstip opnieuw kunt toepassen.
+Stashen pakt de vervuilde status van je werkdirectory, dat wil zeggen: je gewijzigde tracked bestanden en gestagede wijzigingen, en bewaart het op een stapel onafgemaakte wijzigingen die je op ieder tijdstip opnieuw kunt toepassen.
 
 ### Je werk stashen ###
 
-Ter demonstratie, ga je in je project en begint met werken aan een paar bestanden en misschien stage je een van de wijzigingen. Als je `git status` uitvoert, kun je je vervuilde status zien:
+Ter demonstratie, ga je project in en begint met werken aan een paar bestanden en misschien stage je een van de wijzigingen. Als je `git status` uitvoert, kun je de vervuilde status zien:
 
 	$ git status
 	# On branch master
@@ -428,7 +428,7 @@ Ter demonstratie, ga je in je project en begint met werken aan een paar bestande
 	#      modified:   lib/simplegit.rb
 	#
 
-Nu wil je van branch veranderen, maar je wilt hetgeen je aan hebt zitten werken nog niet committen; dus ga je de wijzigingen stashen. Om een nieuwe stash op je stapel te duwen, voer dan `git stash` uit:
+Nu wil je van branch veranderen, maar je wilt hetgeen je aan hebt zitten werken nog niet committen, dus ga je de wijzigingen stashen. Om een nieuwe stash op je stapel te duwen, voer je `git stash` uit:
 
 	$ git stash
 	Saved working directory and index state \
@@ -436,20 +436,20 @@ Nu wil je van branch veranderen, maar je wilt hetgeen je aan hebt zitten werken
 	HEAD is now at 049d078 added the index file
 	(To restore them type "git stash apply")
 
-Je werkmap is schoon:
+Je werkdirectory is schoon:
 
 	$ git status
 	# On branch master
 	nothing to commit (working directory clean)
 
-Op dit punt kun je makkelijk van branch wisselen en ergens anders werken; je wijzigingen worden opgeslagen op je stapel. Om te zien welke stashes je opgeslagen hebt, kun je `git stash list` gebruiken:
+Op dit punt kun je makkelijk van branch wisselen en ergens anders aan werken, je wijzigingen zijn opgeslagen op je stapel. Om te zien welke stashes je opgeslagen hebt, kun je `git stash list` gebruiken:
 
 	$ git stash list
 	stash@{0}: WIP on master: 049d078 added the index file
 	stash@{1}: WIP on master: c264051... Revert "added file_size"
 	stash@{2}: WIP on master: 21d80a5... added number to log
 
-In dit geval waren er twee stashes al eerder opgeslagen, dus heb je toegang tot drie verschillende gestashete werken. Je kunt degene die je zojuist gestashed hebt opnieuw toepassen, door het commando uit te voeren dat in de help output van het originele stash commando stond: `git stash apply`. Als je een van de oudere stashes wilt toepassen, dan kun je die specificeren door hem te noemen, zoals hier: `git apply stash stash@{2}`. Als je geen stash specificeert, gaat Git uit van de meest recente stash en probeert die toe te passen:
+In dit geval waren er twee stashes al eerder opgeslagen, dus heb je toegang tot drie verschillende gestashede werken. Je kunt degene die je zojuist gestashed hebt opnieuw toepassen, door het commando uit te voeren dat in de help output van het originele stash commando stond: `git stash apply`. Als je een van de oudere stashes wilt toepassen, dan kun je die specificeren door hem te benoemen, zoals hier: `git apply stash stash@{2}`. Als je geen stash specificeert, neemt Git aan dat je de meest recente stash bedoelt en probeert die toe te passen:
 
 	$ git stash apply
 	# On branch master
@@ -460,9 +460,9 @@ In dit geval waren er twee stashes al eerder opgeslagen, dus heb je toegang tot
 	#      modified:   lib/simplegit.rb
 	#
 
-Je kunt zien dat Git opnieuw de bestanden wijzigt, die je uncommitte toen je de stash opsloeg. In dit geval had je een schone werkmap toen je de stash probeerde toe te passen, en probeerde je hem op dezelfde branch toe te passen als waar je hem van opgeslagen hebt; maar het hebben van een schone werkmap en toepassen op dezelfde branch zijn niet noodzakelijk om een stash succesvol toe te kunnen passen. Je kunt een stash op één branch opslaan, later naar een andere branch wisselen, en daar opnieuw de wijzigingen toe proberen te passen. Je kunt ook gewijzigde en uncommitted bestanden in je werkmap hebben wanneer je een stash probeert toe te passen – Git geeft je merge conflicten als iets niet meer netjes toe te passen is.
+Je kunt zien dat Git opnieuw de bestanden wijzigt die je uncommitte toen je de stash opsloeg. In dit geval had je een schone werkdirectory toen je de stash probeerde toe te passen, en dat je probeerde deze op dezelfde branch toe te passen als waar je hem van opgeslagen hebt. Maar het hebben van een schone werkdirectory en het toepassen op dezelfde branch zijn niet noodzakelijk om een stash succesvol toe te kunnen passen. Je kunt een stash op één branch opslaan, later naar een andere branch omschakelen, en daar opnieuw de wijzigingen toe proberen te passen. Je kunt ook gewijzigde en uncommitted bestanden in je werkdirectory hebben wanneer je een stash probeert toe te passen, Git geeft merge conflicten aan als iets niet meer netjes toe te passen is.
 
-De wijzigingen aan je bestanden zijn opnieuw toegepast, maar het bestand dat je eerder gestaged had, is niet opnieuw gestaged. Om dat te doen moet je het `git stash apply` commando met de `--index` optie uitvoeren om het commando te vertellen de gestagede wijzigingen opnieuw toe te passen. Als je dat had uitgevoerd, dan zou je weer op je originele vertrekpunt zijn uitgekomen:
+De wijzigingen aan je bestanden zijn opnieuw toegepast, maar het bestand dat je eerder gestaged had, is niet opnieuw gestaged. Om dat te doen moet je het `git stash apply` commando met de `--index` optie uitvoeren om het commando te vertellen de gestagede wijzigingen opnieuw proberen toe te passen. Als je dat had uitgevoerd, dan zou je weer op je originele uitgangspunt zijn uitgekomen:
 
 	$ git stash apply --index
 	# On branch master
@@ -477,7 +477,7 @@ De wijzigingen aan je bestanden zijn opnieuw toegepast, maar het bestand dat je
 	#      modified:   lib/simplegit.rb
 	#
 
-De apply optie probeert alleen het gestashete werk toe te passen – je blijft het op je stapel behouden. Om het te verwijderen, kun je `git stash drop` uitvoeren, met de naam van de stash die je wilt verwijderen:
+De apply optie probeert alleen het gestashete werk toe te passen, je blijft het op je stapel behouden. Om het te verwijderen kun je `git stash drop` uitvoeren, met de naam van de stash die je wilt verwijderen:
 
 	$ git stash list
 	stash@{0}: WIP on master: 049d078 added the index file
@@ -486,11 +486,27 @@ De apply optie probeert alleen het gestashete werk toe te passen – je blijft h
 	$ git stash drop stash@{0}
 	Dropped stash@{0} (364e91f3f268f0900bc3ee613f9f733e82aaed43)
 
-Je kunt ook `git stash pop` uitvoeren om de stash toe te passen en hem onmiddellijk van je stapel te verwijderen.
+Je kunt ook `git stash pop` uitvoeren om de stash toe te passen en deze direct van je stapel te verwijderen.
+### Een stash ont-toepassen ###
+
+In sommige situaties zou het kunnen voorkomen dat je gestashde wijzigingen wilt toepassen, wat werk doen en dan de wijzigingen die van de stash waren gekomen ont-toepassen. Git heeft niet zoiets als een `stash unapply` commando, maar het is mogelijk om het effect te bereiken door simpelweg de patch op te halen die bij een stash hoort, en deze in zijn achteruit toe te passen:
+
+    $ git stash show -p stash@{0} | git apply -R
+
+Nogmaals: als je geen stash specificeert gaat Git van de meest recente stash uit:
+
+    $ git stash show -p | git apply -R
+
+Wellicht wil je een alias maken en effectief een `stash-unapply` commando aan je git toevoegen. Als voorbeeld:
+
+    $ git config --global alias.stash-unapply '!git stash show -p | git apply -R'
+    $ git stash
+    $ #... work work work
+    $ git stash-unapply
 
 ### Een branch van een stash maken ###
 
-Als je wat werk stashet, het een poosje laat rusten, en dan doorwerkt op de branch waarvan je het werk gestashet hebt, dan kun je een probleem krijgen met het werk weer toe te passen. Als het toepassen een bestand probeert te wijzigen dat je sindsdien gewijzigd hebt, krijg je een merge conflict en zul je het moeten oplossen. Als je een eenvoudiger manier wilt hebben om je gestashete wijzigingen opnieuw te testen, kun je `git stash branch` uitvoeren, wat een nieuwe branch voor je zal aanmaken, de commit waar je op zat toen je het werk stashte weer uitchecken, je werk opnieuw toepassen en dan de stash droppen als het succesvol is toegepast:
+Als je wat werk stashed, het daar poosje laat liggen, en doorwerkt op de branch waarvan je het werk gestashed hebt, dan kun je een probleem krijgen met het werk opnieuw toe te passen. Als het toepassen een bestand probeert te wijzigen dat je sindsdien gewijzigd hebt krijg je een merge conflict en zul je dat moeten proberen oplossen. Als je een eenvoudiger manier wilt hebben om je gestashde wijzigingen opnieuw te testen, kun je `git stash branch` uitvoeren. Dit zal een nieuwe branch voor je aanmaken, de commit waar je op zat toen je het werk stashte uitchecken, je werk opnieuw toepassen en dan de stash droppen als het succesvol is toegepast:
 
 	$ git stash branch testchanges
 	Switched to a new branch "testchanges"
@@ -507,37 +523,37 @@ Als je wat werk stashet, het een poosje laat rusten, en dan doorwerkt op de bran
 	#
 	Dropped refs/stash@{0} (f0dfc4d5dc332d1cee34a634182e168c4efc3359)
 
-Dit is een fijne korte route om gestashed werk eenvoudig terug te halen en aan te werken in een nieuwe branch.
+Dit is een prettige manier om gestashed werk eenvoudig terug te halen en eraan te werken in een nieuwe branch.
 
 ## Geschiedenis herschrijven ##
 
-Vaak zul je, als je met Git werkt, je commit geschiedenis om een of andere reden willen aanpassen. Eén van de mooie dingen van Git is dat het je toelaat om beslissingen op het laatste moment te kunnen maken. Je kunt bepalen welke bestanden in welke commits gaan vlak voordat je commit op het staging area, je kunt beslissen dat je niet aan iets bedoelde te werken met het stash commando en je kunt commits herschrijven ook al zijn ze reeds gebeurd, zodat het lijkt alsof ze op een andere manier gebeurd zijn. Dit kan bijvoorbeeld de volgorde van de commits zijn, berichten of bestanden wijzigen, commits samenvoegen of opsplitsen, of complete commits weghalen – dat alles voordat je je werk met anderen deelt.
+Vaak zal je, als je met Git werkt, je commit geschiedenis om een of andere reden willen aanpassen. Eén van de mooie dingen van Git is dat het je in staat stelt om beslissingen op het allerlaatste moment te maken. Je kunt bepalen welke bestanden in welke commits gaan vlak voordat je commit gebruik makende van de staging area, je kunt besluiten dat je toch nog niet aan iets had willen werken met het stash commando en je kunt commits herschrijven ook al zijn ze al gebeurd, waardoor het lijkt alsof ze op een andere manier gebeurd zijn. Dit kan bijvoorbeeld de volgorde van de commits zijn, berichten of bestanden in een commit wijzigen, commits samenvoegen (squashen) of opsplitsen, of complete commits weghalen. En dat allemaal voordat je jouw werk met anderen deelt.
 
-In deze sectie zul je leren hoe je deze handige taken doet, zodat je je commit geschiedenis er uit kunt laten zien zoals jij dat wilt, voordat je hem met anderen deelt.
+In deze paragraaf zal je leren hoe je deze handige taken uitvoert, zodat je je commit geschiedenis er uit kunt laten zien zoals jij dat wilt, voordat je het met anderen deelt.
 
 ### De laatste commit veranderen ###
 
-De laatste commit veranderen is waarschijnlijk de meest voorkomende geschiedenis wijziging die je wilt doen. Vaak wil je twee basale dingen aan je laatste commit wijzigen: het commit bericht, of het snapshot dat je zojuist opgeslagen hebt wijzigen door het toevoegen, wijzigen of weghalen van bestanden.
+De laatste commit veranderen is waarschijnlijk de meest voorkomende geschiedenis wijziging die je zult doen. Vaak wil je twee basale dingen aan je laatste commit wijzigen: het commit bericht, of de snapshot dat je zojuist opgeslagen hebt wijzigen door het toevoegen, wijzigen of weghalen van bestanden.
 
 Als je alleen je laatste commit bericht wilt wijzigen, dan is dat heel eenvoudig:
 
 	$ git commit --amend
 
-Dat plaatst je in je teksteditor, met je laatste commit bericht erin, klaar voor jou om je bericht te wijzigen. Als je de editor opslaat en sluit, dan schrijft de editor een nieuwe commit met dat bericht en maakt dat je laatste commit.
+Dat plaatst je in de teksteditor met je laatste commit bericht erin, klaar voor je om het bericht te wijzigen. Als je opslaat en de editor sluit, dan schrijft de editor een nieuwe commit met dat bericht en maakt dat je laatste commit.
 
-Als je hebt gecommit en je wilt het snapshot dat je gecommit hebt wijzigen, door het toevoegen of wijzigen van bestanden, misschien omdat je vergeten was een nieuw bestand toe te voegen toen je committe, werkt het proces ongeveer op dezelfde manier. Je staged de wijzigingen die je wilt door een bestand te wijzigen en `git add` er op uit te voeren, of `git rm` op een gevolgd bestand, en de daaropvolgende `git commit --amend` pakt je huidige staging area en maakt dat het snapshot voor de nieuwe commit.
+Als je hebt gecommit en daarna wil je het snapshot dat je gecommit hebt wijzigen, door het toevoegen of wijzigen van bestanden, misschien omdat je vergeten was een nieuw bestand toe te voegen toen je committe, gaat het proces vergelijkbaar. Je staged de wijzigingen die je wilt door een bestand te wijzigen en `git add` er op uit te voeren, of `git rm` op een gevolgd bestand, en de daaropvolgende `git commit --amend` pakt je huidige staging area en maakt dat het snapshot voor de nieuwe commit.
 
-Je moet oppassen met deze techniek, omdat het amenden de SHA-1 van de commit wijzigt. Het is vergelijkbaar met een kleine rebase – niet je laatste commit wijzigen als je die al gepusht hebt.
+Je moet wel oppassen met deze techniek, omdat het amenden de SHA-1 van de commit wijzigt. Het is vergelijkbaar met een kleine rebase: niet je laatste commit wijzigen als je die al gepusht hebt.
 
 ### Meerdere commit berichten wijzigen ###
 
-Om een commit te wijzigen die verder terug in je geschiedenis zit, moet je naar complexere tools gaan. Git heeft geen geschiedenis-wijzig tool, maar je kunt het rebase tool gebruiken om een serie commits op de HEAD waarvan ze origineel gebaseerd waren te rebasen, in plaats van ze naar een andere te verhuizen. Met het interactieve rebase tool, kun je dan na iedere commit die je wilt wijzigen stoppen en het bericht wijzigen, bestanden toevoegen, of doen wat je ook maar wilt. Je kunt rebase interactief uitvoeren door de `-i` optie aan `git rebase` toe te voegen. Je moet aangeven hoe ver terug je commits wilt herschrijven door het commando te vertellen op welke commit het moet rebasen.
+Om een commit te wijzigen die verder terug in je geschiedenis zit, moet je meer complexe tools gebruiken. Git heeft geen geschiedenis-wijzig tool, maar je kunt het rebase tool gebruiken om een serie commits op de HEAD te rebasen waarop ze origineel gebaseerd, in plaats van ze naar een andere te verhuizen. Met het interactieve rebase tool kun je dan na iedere commit die je wilt wijzigen stoppen en het bericht wijzigen, bestanden toevoegen, of doen wat je ook maar wilt. Je kunt rebase interactief uitvoeren door de `-i` optie aan `git rebase` toe te voegen. Je moet aangeven hoe ver terug je commits wilt herschrijven door het commando te vertellen op welke commit het moet rebasen.
 
 Bijvoorbeeld, als je de laatste drie commit berichten wilt veranderen, of een van de commit berichten in die groep, dan geef je de ouder van de laatste commit die je wilt wijzigen mee als argument aan `git rebase -i`, wat `HEAD~2^` of `HEAD~3` is. Het kan makkelijker zijn om de `~3` te onthouden, omdat je de laatste drie commits probeert te wijzigen; maar houd in gedachten dat je eigenlijk vier commits terug aangeeft; de ouder van de laatste commit die je wilt veranderen:
 
 	$ git rebase -i HEAD~3
 
-Onthoud ook dat dit een rebase commando is – iedere commit in de serie `HEAD~3..HEAD` zal worden herschreven, of je het bericht wijzigt of niet. Voeg geen commit toe die je al naar een centrale server gepusht hebt – als je dit doet breng je andere gebruikers in de war door ze een alternatieve versie van dezelfde wijziging te geven.
+Onthoud, nogmaals, dat dit een rebase commando is; iedere commit in de reeks `HEAD~3..HEAD` zal worden herschreven, of je het bericht wijzigt of niet. Voeg geen commit toe die je al naar een centrale server gepushed hebt; als je dit doet breng je andere gebruikers in de war omdat je ze een alternatieve versie van dezelfde wijziging te geeft.
 
 Dit commando uitvoeren geeft je een lijst met commits in je tekst editor die er ongeveer zo uit ziet:
 
@@ -556,22 +572,22 @@ Dit commando uitvoeren geeft je een lijst met commits in je tekst editor die er
 	# However, if you remove everything, the rebase will be aborted.
 	#
 
-Het is belangrijk om te zien dat deze commits in de omgekeerde volgorde getoond worden dan wanneer je ze normaliter ziet als je het `log` commando gebruikt. Als je een `log` uitvoert, zie je zoiets als dit:
+Het is belangrijk om op te merken dat deze commits in de tegengestelde volgorde getoond worden dan hoe je ze normaliter ziet als je het `log` commando gebruikt. Als je een `log` uitvoert, zie je zoiets als dit:
 
 	$ git log --pretty=format:"%h %s" HEAD~3..HEAD
 	a5f4a0d added cat-file
 	310154e updated README formatting and added blame
 	f7f3f6d changed my name a bit
 
-Zie de omgekeerde volgorde. De interactieve rebase geeft je een script dat het gaat uitvoeren. Het zal beginnen met de commit die je specificeert op de commando regel (`HEAD~3`), en de wijzigingen in ieder van deze commits opnieuw afspelen van boven naar beneden. Het toont de oudste aan de bovenkant, in plaats van de nieuwste, omdat dat de eerste is die het zal afspelen.
+Merk de omgekeerde volgorde op. De interactieve rebase geeft je een script dat het gaat uitvoeren. Het zal beginnen met de commit die je specificeert op de commando regel (`HEAD~3`) en de wijzigingen in elk van deze commits van voor naar achter opnieuw afspelen. Het toont de oudste het eerst in plaats van de nieuwste, omdat dat deze de eerste is die zal worden afgespeeld.
 
-Je moet het script wijzigen zodat het stopt bij de commit die je wilt wijzigen. Om dat te doen moet je het woord pick veranderen in het woord edit voor ieder van de commits waarbij je het script wilt laten stoppen. Bijvoorbeeld, om alleen het derde commit bericht te wijzigen, verander je het bestand zodat het er zo uitziet:
+Je moet het script op zodanige manier wijzigen dat het stopt bij de commit die je wilt wijzigen. Om dat te doen moet je het woord "pick" veranderen in het woord "edit" voor elke commit waarbij je het script wilt laten stoppen. Bijvoorbeeld, om alleen het derde commit bericht te wijzigen verander je het bestand zodat het er zo uitziet:
 
 	edit f7f3f6d changed my name a bit
 	pick 310154e updated README formatting and added blame
 	pick a5f4a0d added cat-file
 
-Als je de editor opslaat en sluit, plaatst Git je terug in de laatste commit van die lijst en zet je op de commando regel met de volgende boodschap:
+Als je dit opslaat en de editor sluit, spoelt Git terug naar de laatste commit van die lijst en zet je op de commando regel met de volgende boodschap:
 
 	$ git rebase -i HEAD~3
 	Stopped at 7482e0d... updated the gemspec to hopefully work better
@@ -587,15 +603,15 @@ Deze instructies vertellen je precies wat je moet doen. Type
 
 	$ git commit --amend
 
-Wijzig het commit bericht, en verlaat de editor. Voer daarna dit uit
+Wijzig het commit bericht en verlaat de editor. Voer vervolgens dit uit
 
 	$ git rebase --continue
 
-Dit commando zal de andere twee commits automatisch toepassen, en dan ben je klaar. Als je pick in edit veranderd op meerdere regels, dan kun je deze stappen herhalen voor iedere commit die je in edit veranderd hebt. Iedere keer zal Git stoppen, je de commit laten amenden, en verder gaan waar je gewijzigd bent.
+Dit commando zal de andere twee commits automatisch toepassen, en je bent klaar. Als je "pick" op meerdere regels in "edit" verandert, dan kan je deze stappen herhalen voor iedere commit die je in "edit" veranderd hebt. Elke keer zal Git stoppen, je de commit laten wijzigen en verder gaan als je klaar bent.
 
-### Commits rangschikken ###
+### Commits opnieuw rangschikken ###
 
-Je kunt een interactieve rebase ook gebruiken om commits te rangschikken of volledig te verwijderen. Als je de "added cat-file" commit wilt verwijderen en de volgorde waarin de andere twee commits zijn geïntroduceerd wilt veranderen, dan kun je het rebase script van dit
+Je kunt een interactieve rebase ook gebruiken om commits opnieuw te rangschikken of zijn geheel te verwijderen. Als je de "added cat-file" commit wilt verwijderen en de volgorde waarin de andere twee commits zijn geïntroduceerd wilt veranderen, dan kun je het rebase script van dit
 
 	pick f7f3f6d changed my name a bit
 	pick 310154e updated README formatting and added blame
@@ -606,11 +622,11 @@ veranderen in dit:
 	pick 310154e updated README formatting and added blame
 	pick f7f3f6d changed my name a bit
 
-Als je de editor opslaat en sluit, zal Git je branch terugzetten naar de ouder van deze commits, eerst `310154e` en dan `f7f3f6d` toepassen, en dan stoppen. Effectief verander je de volgorde van die commits en verwijder je de "added cat-file" commit in zijn geheel.
+Als je dan opslaat en de editor sluit, zal Git je branch terugzetten naar de ouder van deze commits, eerst `310154e` en dan `f7f3f6d` toepassen, en dan stoppen. Effectief verander je de volgorde van die commits en verwijder je de "added cat-file" commit volledig.
 
-### Een commit squashen ###
+### Een commit samenpersen (squashing) ###
 
-Het is ook mogelijk een serie commits te pakken en ze in één enkele commit te squashen met het interactieve rebase tool. Het script stopt behulpzame instructies in het rebase bericht:
+Het is ook mogelijk een serie commits te pakken en ze in één enkele commit samen te persen (squash) met het interactieve rebase tool. Het script stopt behulpzame instructies in het rebase bericht:
 
 	#
 	# Commands:
@@ -622,13 +638,13 @@ Het is ook mogelijk een serie commits te pakken en ze in één enkele commit te
 	# However, if you remove everything, the rebase will be aborted.
 	#
 
-Als je, in plaats van "pick" of "edit", "squash" specificeert zal Git zowel die verandering als de verandering die er direct aan vooraf gaat toepassen, en je dwingen om de merge berichten samen te voegen. Dus als je een enkele commit van deze drie commits wil maken, laat je het script er zo uit zien:
+Als je in plaats van "pick" of "edit", "squash" specificeert zal Git zowel die verandering als de verandering die er direct aan vooraf gaat toepassen, en je dwingen om de commit berichten samen te voegen. Dus als je een enkele commit van deze drie commits wil maken, laat je het script er zo uit zien:
 
 	pick f7f3f6d changed my name a bit
 	squash 310154e updated README formatting and added blame
 	squash a5f4a0d added cat-file
 
-Als je de editor opslaat en sluit, zal Git alledrie de veranderingen toepassen en je terug in de editor brengen om de drie commit berichten samen te voegen:
+Als je de editor opslaat en sluit, zal Git alle drie wijzigingen toepassen en je terug in de editor brengen om de drie commit berichten samen te voegen:
 
 	# This is a combination of 3 commits.
 	# The first commit's message is:
@@ -642,17 +658,17 @@ Als je de editor opslaat en sluit, zal Git alledrie de veranderingen toepassen e
 
 	added cat-file
 
-Als je dat opslaat, heb je een enkele commit die de veranderingen van alledrie de vorige commits introduceert.
+Als je dat opslaat, heb je een enkele commit die de veranderingen van alle drie vorige commits introduceert.
 
 ### Een commit splitsen ###
 
-Een commit opsplitsen zal een commit ongedaan maken, en dan zo vaak als het aantal commits waar je mee wilt eindigen gedeeltelijk stagen en committen. Bijvoorbeeld, stel dat je de middelste van je drie commits wilt splitsen. In plaats van "updated README formatting and added blame", wil je het splitsen in twee commits: "updated README formatting" als eerste, en "added blame" als tweede. Je kunt dat doen in het `rebase -i` script door de instructie van de commit die je wilt splitsen te veranderen in "edit":
+Een commit opsplitsen zal een commit ongedaan maken, en dan net zo vaak gedeeltelijk stagen en committen als het aantal commits waar je mee wilt eindigen. Bijvoorbeeld, stel dat je de middelste van je drie commits wilt splitsen. In plaats van "updated README formatting and added blame" wil je het splitsen in twee commits: "updated README formatting" als eerste, en "added blame" als tweede. Je kunt dat doen in het `rebase -i` script door de instructie van de commit die je wilt splitsen te veranderen in "edit":
 
 	pick f7f3f6d changed my name a bit
 	edit 310154e updated README formatting and added blame
 	pick a5f4a0d added cat-file
 
-Als het script je dan op de commando regel zet, reset je die commit, neemt de wijzigingen die zijn gereset, en maakt daar meerdere commits van.Als je de editor opslaat en sluit, zal Git teruggaan naar de ouder van de eerste commit in je lijst, de eerste commit toepassen (`f7f3f6d`), de tweede commit toepassen (`310154e`), en je op de console plaatsen. Dan kun je een gemengde reset van die commit doen met `git reset HEAD^`, wat effectief die commit ongedaan maakt en de gewijzigde bestanden unstaged laat. Nu kun je bestanden stagen en committen totdat je meerdere commits hebt, en `git rebase --continue` uitvoeren zodra je klaar bent:
+Als je opslaat en de editor verlaat, spoelt Git terug naar de parent van de eerste commit in de lijst, past de eerste commit toe (`f7f3f6d`), past de tweede te (`310154e`), en zet je dan in de console. Daar kan je een gemengde reset doen van die commit met `git reset HEAD^` , wat effectief de commit terugdraait en de gewijzigde bestanden unstaged laat. Nu kan je de wijzigingen die gereset zijn nemen en er meerdere commits van maken. Eenvoudigweg bestanden stagen en committen tot je meerdere commits hebt, en `git rebase --continue` uitvoeren zodra je klaar bent:
 
 	$ git reset HEAD^
 	$ git add README
@@ -669,37 +685,37 @@ Git zal de laatste commit (`a5f4a0d`) in het script toepassen, en je geschiedeni
 	35cfb2b updated README formatting
 	f3cc40e changed my name a bit
 
-Nogmaals, dit veranderd alle SHA's van alle commits in je lijst, dus zorg er voor dat er geen commit in die lijst zit die je al naar een gedeeld repository gepusht hebt.
+Nogmaals, dit veranderd alle SHA's van alle commits in de lijst, dus zorg er voor dat er geen commit in die lijst zit die je al naar een gedeeld repository gepushed hebt.
 
 ### De nucleaire optie: filter-branch ###
 
-Er is nog een geschiedenis-herschrijvende optie, die je kunt gebruiken als je een groter aantal commits moet herschrijven in een scriptbare manier – bijvoorbeeld, het globaal veranderen van je e-mail adres of een bestand uit iedere commit verwijderen. Het commando heet `filter-branch`, en het kan grote gedeelten van je geschiedenis herschrijven, dus je moet het niet gebruiken tenzij je project nog niet publiekelijk is gemaakt en andere mensen nog geen werk hebben gebaseerd op jouw commits, die je op het punt staat te herschrijven. Maar het kan heel handig zijn. Je zult een paar gebruikelijke toepassingen leren zodat je een idee kunt krijgen van de mogelijkheden.
+Er is nog een geschiedenis-herschrijvende optie, die je kunt gebruiken als je een groter aantal commits moet herschrijven in een scriptbare manier. Bijvoorbeeld, het globaal veranderen van je e-mail adres of een bestand uit iedere commit verwijderen. Het commando heet `filter-branch` en het kan grote gedeelten van je geschiedenis herschrijven, dus je moet het niet gebruiken tenzij je project nog niet publiekelijk is gemaakt, en andere mensen nog geen werk hebben gebaseerd op jouw commits die je op het punt staat te herschrijven. Maar het kan heel handig zijn. Je zult een paar gebruikelijke toepassingen leren zodat je een idee kunt krijgen waar het toe in staat is.
 
 #### Een bestand uit iedere commit verwijderen ####
 
-Dit gebeurd vrij vaak. Iemand voegt per ongeluk een enorm binair bestand toe met een gedachteloze `git add .`, en je wilt het overal weghalen. Misschien heb je per ongeluk een bestand toegevoegd dat een wachtwoord bevat, en wil je je project open source maken. `filter-branch` is het tool dat je waarschijnlijk wil gebruiken om je hele geschiedenis schoon te vegen. Om een bestand genaamd passwords.txt uit je hele geschiedenis weg te halen, kun je de `--tree-filter` optie toevoegen aan `filter-branch`:
+Dit gebeurt vrij regelmatig. Iemand voegt per ongeluk een enorm binair bestand toe met een achteloze `git add .`, en je wilt het overal weghalen. Misschien heb je per ongeluk een bestand dat een wachtwoord bevat gecommit, en je wilt dat project open source maken. `filter-branch` is het tool dat je waarschijnlijk wilt gebruiken om je hele geschiedenis schoon te poetsen. Om een bestand genaamd passwords.txt uit je hele geschiedenis weg te halen, kun je de `--tree-filter` optie toevoegen aan `filter-branch`:
 
 	$ git filter-branch --tree-filter 'rm -f passwords.txt' HEAD
 	Rewrite 6b9b3cf04e7c5686a9cb838c3f36a8cb6a0fc2bd (21/21)
 	Ref 'refs/heads/master' was rewritten
 
-De `--tree-filter` optie voert het gegeven commando uit na iedere checkout van het project, en commit de resultaten weer. In dit geval, verwijder je een bestand genaamd passwords.txt van iedere snapshot, of het bestaat of niet. Als je alle per ongeluk toegevoegde editor backup bestanden wilt verwijderen, kun je zoiets als dit uitvoeren `git filter-branch --tree-filter "find * -type f -name '*~' -delete" HEAD`.
+De `--tree-filter` optie voert het gegeven commando uit na elke checkout van het project, en commit de resultaten weer. In dit geval verwijder je een bestand genaamd passwords.txt van elke snapshot, of het bestaat of niet. Als je alle per ongeluk toegevoegde editor backup bestanden wilt verwijderen, kun je bijvoorbeeld dit uitvoeren `git filter-branch --tree-filter "find * -type f -name '*~' -delete" HEAD`.
 
-Je kunt Git bomen en commits zien herschrijven en de branch wijzer aan het einde zien verplaatsen. Het is over het algemeen een goed idee om dit in een test branch te doen, en dan je master branch te hard-resetten nadat je gecontroleerd hebt dat de uitkomst echt zo is als je wil. Om `filter-branch` op al je branches uit te voeren, kun je `--all` aan het commando meegeven.
+Je zult Git bomen en commits zien herschrijven en dan de branch wijzer naar het einde zien verplaatsen. Het is over het algemeen een goed idee om dit in een test branch te doen, en dan je master branch te hard-resetten nadat je gecontroleerd hebt dat de uitkomst echt is als je het wilt hebben. Om `filter-branch` op al je branches uit te voeren, kun je `--all` aan het commando meegeven.
 
-#### Een subdirectory het nieuwe beginpunt maken ####
+#### Een subdirectory de nieuwe root maken ####
 
-Stel dat je een import vanuit een ander versiebeheersysteem hebt gedaan, en subdirectories hebt die geen zin maken (trunk, tags enzovoort). Als je de `trunk` subdirectory het nieuwe beginpunt van het project wilt maken voor iedere commit, dan kan `filter-branch` je daar ook mee helpen:
+Stel dat je een import vanuit een ander versiebeheersysteem hebt gedaan, en subdirectories hebt die niet zinnig zijn (trunk, tags enzovoort). Als je de `trunk` subdirectory de nieuwe root van het project wilt maken voor iedere commit, kan `filter-branch` je daar ook mee helpen:
 
 	$ git filter-branch --subdirectory-filter trunk HEAD
 	Rewrite 856f0bf61e41a27326cdae8f09fe708d679f596f (12/12)
 	Ref 'refs/heads/master' was rewritten
 
-Nu is je nieuwe project wat het was in de `trunk` subdirectory. Git zal ook automatisch commits verwijderen, die geen effect hadden op de subdirectory.
+Nu is de nieuwe project root wat het elke keer was in de `trunk` subdirectory. Git zal ook automatisch commits verwijderen die geen effect hadden op de subdirectory.
 
 #### E-mail adressen globaal veranderen ####
 
-Een ander veel voorkomend geval is dat je vergeten bent om `git config` uit te voeren om je naam en e-mail adres in te stellen voordat je bent begonnen met werken, of misschien wil je een project op het werk open source maken en al je werk e-mail adressen veranderen naar je privé adres. In ieder geval kun je e-mail adressen in meerdere commits ook ineens veranderen met `filter-branch`. Je moet wel oppassen om alleen de e-mail adressen aan te passen, die van jou zijn, dus gebruik je `--commit-filter`:
+Een ander veel voorkomend geval is dat je vergeten bent om `git config` uit te voeren om je naam en e-mail adres in te stellen voordat je bent begonnen met werken, of misschien wil je een project op het werk open source maken en al je werk e-mail adressen veranderen naar je persoonlijke adres. Je kunt zowiezo je e-mail adressen in meerdere commits ook in een keer veranderen met `filter-branch`. Je moet wel oppassen dat je alleen die e-mail adressen aan past die van jou zijn, dus gebruik je `--commit-filter`:
 
 	$ git filter-branch --commit-filter '
 	        if [ "$GIT_AUTHOR_EMAIL" = "schacon@localhost" ];
@@ -711,15 +727,15 @@ Een ander veel voorkomend geval is dat je vergeten bent om `git config` uit te v
 	                git commit-tree "$@";
 	        fi' HEAD
 
-Dit gaat door en herschrijft iedere commit zodat het jouw nieuwe adres bevat. Om dat commits de SHA-1 waarde van hun ouders bevatten, zal dit commando iedere commit SHA in jouw geschiedenis veranderen, niet alleen degenen die het passende e-mailadres bevatten.
+Dit gaat werkt alle commits door en herschrijft ze zodat het jouw nieuwe adres bevat. Om dat commits de SHA-1 waarde van hun ouders bevatten, zal dit commando iedere commit SHA in jouw geschiedenis veranderen, niet alleen diegene die het gezochte e-mailadres bevatten.
 
 ## Debuggen met Git ##
 
-Git levert ook een paar tools om je problemen te helpen debuggen in je projecten. Omdat Git is ontworpen te werken met bijna ieder type project, zijn deze tools erg generiek, maar ze kunnen je vaak helpen op een bug of veroorzaker te jagen als de dingen verkeerd gaan.
+Git levert ook een paar tools om je problemen te helpen debuggen in je projecten. Omdat Git is ontworpen te werken met bijna elk type project zijn deze tools erg generiek, maar ze kunnen je vaak helpen een bug of schuldige te vinden als de dingen verkeerd gaan.
 
 ### Bestandsannotatie ###
 
-Als je een bug in je code traceert en wilt weten wanneer het was geïntroduceerd en waarom, dan is bestandsannotatie vaak je beste tool. Het toont je welke commit de laatste was die iedere regel in een bestand wijzigde. Dus, als je ziet dat een functie in je code bugs bevat, dan kun je het bestand annoteren met `git blame` om te zien wanneer iedere regel van de functie voor het laatst aangepast was, en door wie. Dit voorbeeld gebruikt de `-L` optie om de output te limiteren van regel 12 tot 22:
+Als je een bug in je code traceert en wilt weten wanneer het was geïntroduceerd en waarom, dan is bestandsannotatie vaak je beste tool. Het toont je welke commit de laatste was een willekeurige regel in een bestand wijzigde. Dus als je ziet dat een methode in je code bugs bevat, dan kun je het bestand annoteren met `git blame` om te zien wanneer een regel van de methode voor het laatst aangepast was en door wie. Dit voorbeeld gebruikt de `-L` optie om de output te beperken tot regel 12 tot en met 22:
 
 	$ git blame -L 12,22 simplegit.rb
 	^4832fe2 (Scott Chacon  2008-03-15 10:31:28 -0700 12)  def show(tree = 'master')
@@ -734,9 +750,9 @@ Als je een bug in je code traceert en wilt weten wanneer het was geïntroduceerd
 	42cf2861 (Magnus Chacon 2008-04-13 10:45:01 -0700 21)   command("git blame #{path}")
 	42cf2861 (Magnus Chacon 2008-04-13 10:45:01 -0700 22)  end
 
-Zie dat het eerste veld de gedeeltelijke SHA-1 van de commit is, die als laatste die regel aangepast heeft. De volgende twee velden zijn waarden, die gehaald zijn uit die commit – de naam van de auteur en de datum van die commit – zodat je makkelijk kunt zien wie wanneer die regel aangepast heeft. Daarna komt het regelnummer en de inhoud van dat bestand. Let op de `^4832fe2` commit regels, die aangeven dat die regels in de eerste commit van dat bestand zaten. Die commit is gedaan toen dit bestand als eerste is toegevoegd aan dit project, en die regels zijn sindsdien ongewijzigd gebleven. Dat is een beetje verwarrend, want nu heb je minstens drie manieren gezien waarop Git het `^` symbool gebruikt om een SHA van een commit aan te passen, maar dat is wat het hier betekent.
+Merk op dat het eerste veld de gedeeltelijke SHA-1 van de commit is, die als laatste die regel gewijzigd heeft. De volgende twee velden zijn waarden die gehaald zijn uit die commit: de naam van de auteur en de datum van die commit, zodat je makkelijk kunt zien wie die regel aangepast heeft en wanneer. Daarna komt het regelnummer en de inhoud van dat bestand. Let ook op de `^4832fe2` commit regels, die aangeven dat die regels in de allereerste commit van dat bestand zaten. Die commit is gedaan toen dit bestand voor het eerst was toegevoegd aan dit project, en die regels zijn sindsdien ongewijzigd gebleven. Dit is een wat verwarrend, want nu heb je minstens drie manieren gezien waarop Git het `^` symbool gebruikt om een SHA van een commit aan te passen, maar dit is wat het hier betekent.
 
-Een ander stoer ding van Git is dat het geen naamswijzigingen van bestanden expliciet bijhoudt. Het neemt de snapshots op en probeert impliciet uit te vogelen wat er hernoemd was, nadat het gebeurd is. Een van de interessantste eigenschappen hiervan is dat je ook het kunt vragen om allerlei soorten code verplaatsingen uit te vogelen. Als je `-C` aan `git blame` meegeeft, zal Git het bestand dat je annoteert analyseren en proberen uit te vinden waar stukjes code erin oorspronkelijk vandaan kwamen als ze ergens vandaan gekopieerd zijn. Recentelijk was ik een bestand genaamd `GITServerHandler.m` aan het refactoreren naar meerdere bestanden, waarvan er een `GITPackUpload.m` heette. Door `GITPackUpload.m` te blamen met de `-C` optie, kon ik zien waar delen van de code oorspronkelijk vandaan kwamen:
+Een ander gave ding van Git is dat het geen naamswijzigingen van bestanden expliciet bijhoudt. Het slaat de snapshots op en probeert dan impliciet uit te vogelen dat er iets hernoemd is, nadat het gebeurd is. Een van de interessante eigenschappen hiervan is dat je Git ook kunt vragen om allerlei soorten code verplaatsingen uit te vogelen. Als je `-C` aan `git blame` meegeeft, zal Git het bestand dat je annoteert analyseren en proberen uit te vinden waar stukjes code daarin oorspronkelijk vandaan kwamen als ze ergens vandaan gekopieerd zijn. Recentelijk was ik een bestand genaamd `GITServerHandler.m` aan het refactoreren naar meerdere bestanden, waarvan `GITPackUpload.m` er een was. Door `GITPackUpload.m` te blamen met de `-C` optie, kon ik zien waar delen van de code oorspronkelijk vandaan kwamen:
 
 	$ git blame -C -L 141,153 GITPackUpload.m
 	f344f58d GITServerHandler.m (Scott 2009-01-04 141)
@@ -753,13 +769,13 @@ Een ander stoer ding van Git is dat het geen naamswijzigingen van bestanden expl
 	56ef2caf GITServerHandler.m (Scott 2009-01-05 152)                 [refDict setOb
 	56ef2caf GITServerHandler.m (Scott 2009-01-05 153)
 
-Dit is heel handig. Normaal krijg je als de originele commit de commit waar je de code overheen gekopieerd hebt, omdat dat de eerste keer is dat je die regels aangeraakt hebt in dit bestand. Git verteld je de originele commit waarin je deze regels geschreven hebt, zelfs als dat in een ander bestand is.
+Dit is echt heel handig. Normaal krijg je als de originele commit de commit waar je de code overheen gekopieerd hebt, omdat dat de eerste keer is dat je die regels aangeraakt hebt in dit bestand. Git vertelt je de originele commit waarin je deze regels geschreven hebt, zelfs als dat in een ander bestand was.
 
 ### Binair zoeken ###
 
-Een bestand annoteren helpt als je eenmaal weet waar het probleem zit. Als je niet weet wat er kapot is, en er zijn vele dozijnen of honderden commits geweest sinds de laatste staat waarvan je weet dat de code werkte, dan zul je waarschijnlijk bij `git bisect` aankloppen voor hulp. Het `bisect` commando zoekt binair door je commitgeschiedenis om je zo snel als mogelijk te helpen identificeren welke commit het issue introduceerde.
+Een bestand annoteren helpt als je al weet waar het probleem zit. Als je niet weet waar de fout zit en er zijn dozijnen of honderden commits geweest sinds de laatste staat waarvan je weet dat de code werkte, dan zal je waarschijnlijk bij `git bisect` aankloppen voor hulp. Het `bisect` commando zoekt binair door je commit-geschiedenis om je zo snel als mogelijk te helpen identificeren welke commit het issue introduceerde.
 
-Stel dat je zojuist een release van je code naar een productie omgeving gepusht hebt, en je krijgt bug rapporten terug dat er iets gebeurd dat niet in je development omgeving gebeurde en je kunt je niet voorstellen waarom de code dat aan het doen is. Je gaat terug naar je code, en het blijkt dat je het probleem kunt reproduceren, maar je kunt niet zien wat er verkeerd gaat. Je kunt de code bisecten om het uit te vinden. Als eerste voer je `git bisect start` uit om aan de gang te gaan, en dan gebruik je `git bisect bad` om het systeem te vertellen dat de huidige commit kapot is. Dan moet je bisect vertellen wanneer de laatste goede status was, door `git bisect good [goede_commit]` te gebruiken:
+Stel dat je zojuist een release van je code naar een productie omgeving gepushed hebt, en je krijgt bug rapporten dat er iets gebeurt wat niet in je development omgeving gebeurde en je kunt je niet voorstellen waarom de code dat aan het doen is. Je gaat terug naar je code, en het blijkt dat je het probleem kunt reproduceren maar je kunt niet zien wat er verkeerd gaat. Je kunt de code uitpluizen (bisecten) om het uit te vinden. Als eerste voer je `git bisect start` uit om aan de boel op te starten, en dan gebruik je `git bisect bad` om het systeem te vertellen dat de huidige commit kapot is. Dan moet je bisect vertellen wanneer de laatste goede status was met `git bisect good [goede_commit]`:
 
 	$ git bisect start
 	$ git bisect bad
@@ -767,7 +783,7 @@ Stel dat je zojuist een release van je code naar een productie omgeving gepusht
 	Bisecting: 6 revisions left to test after this
 	[ecb6e1bc347ccecc5f9350d878ce677feb13d3b2] error handling on repo
 
-Git heeft gezien dat er ongeveer 12 commits gekomen zijn tussen de commit die je als laatste goede commit gemarkeerd hebt (v1.0) en de huidige slechte versie, en het heeft de middelste uitgechecked voor je. Op dit punt kun je je test uitvoeren om te zien of het probleem op deze commit ook aanwezig is. Als dat zo is, dan was het probleem ergens voor deze middelste commit geïntroduceerd; zo niet, dan is het probleem na deze commit geïntroduceerd. Het blijkt dat hier geen probleem is, dus je kunt Git dat vertellen door `git bisect good` te typen en je reis te vervolgen:
+Git heeft gezien dat er ongeveer 12 commits gekomen zijn tussen de commit die je als laatste goede commit gemarkeerd hebt (v1.0) en de huidige slechte versie, en het heeft de middelste voor je uitgechecked. Op dit punt kun je je test uitvoeren om te zien of het probleem op deze commit ook aanwezig is. Als dat zo is, dan was het probleem ergens voor deze middelste commit geïntroduceerd, zo niet dan is het probleem na deze commit geïntroduceerd. Het blijkt dat hier geen probleem is, dus je kunt Git dat vertellen door `git bisect good` te typen en je reis te vervolgen:
 
 	$ git bisect good
 	Bisecting: 3 revisions left to test after this
@@ -779,7 +795,7 @@ Nu zit je op een andere commit, halverwege degene die je zojuist getest hebt en
 	Bisecting: 1 revisions left to test after this
 	[f71ce38690acf49c1f3c9bea38e09d82a5ce6014] drop exceptions table
 
-Deze commit is in orde, en nu heeft Git alle informatie die het nodig heeft om vast te stellen wanneer het probleem was geïntroduceerd. Het verteld je de SHA-1 van de eerste slechte commit en toont een stukje commit informatie en welke bestanden aangepast waren in die commit, zodat je er achter kunt komen wat deze bug geïntroduceerd kan hebben:
+Deze commit is in orde, en nu heeft Git alle informatie die het nodig heeft om vast te stellen wanneer het probleem was geïntroduceerd. Het vertelt je de SHA-1 van de eerste slechte commit en toont een stukje commit informatie en welke bestanden aangepast waren in die commit, zodat je er achter kunt komen wat deze bug geïntroduceerd kan hebben:
 
 	$ git bisect good
 	b047b02ea83310a70fd603dc8cd7a6cd13d15c04 is first bad commit
@@ -792,28 +808,28 @@ Deze commit is in orde, en nu heeft Git alle informatie die het nodig heeft om v
 	:040000 040000 40ee3e7821b895e52c1695092db9bdc4c61d1730
 	f24d3c6ebcfc639b1a3814550e62d60b8e68a8e4 M  config
 
-Als je klaar bent, zou je `git bisect reset` moeten uitvoeren om je HEAD terug te zetten naar het punt waar je was toen je startte, of anders eindig je in een vreemde status:
+Als je klaar bent, moet je `git bisect reset` uitvoeren om je HEAD terug te zetten naar het punt waar je was toen je startte, anders eindig je in een vreemde status:
 
 	$ git bisect reset
 
-Dit is een krachtige tool, die je kan helpen om honderden commits te doorzoeken naar een fout in enkele minuten. In feite kun je `git bisect` volledig automatiseren als je een script hebt dat met 0 eindigt als het project in orde is, en niet-0 als het project slecht is. Eerst vertel je het de scope van de bisect door het de goede en slechte commits te geven, die je weet. Je kunt dit doen door ze te tonen met het `bisect start` commando als je dat wil, waarbij je de slechte commit eerst en de laatst bekende goede commit als tweede geeft:
+Dit is een krachtige tool, die je kan helpen om in enkele minuten honderden commits te doorzoeken op zoek naar een fout. Sterker nog, als je een script hebt die eindigt met 0 als het project goed is of niet-0 als het fout is, kan je `git bisect` volledig automatiseren. Eerst vertel je het de scope van de bisect door het de goede en slechte commits te geven. Als je wilt kan dit doen door ze te tonen met het `bisect start` commando, waarbij je de slechte commit eerst en de laatst bekende goede commit als tweede geeft:
 
 	$ git bisect start HEAD v1.0
 	$ git bisect run test-error.sh
 
-Door het zo te doen wordt `test-error.sh` uitgevoerd bij iedere commit die uitgechecked wordt, totdat Git de eerste kapotte commit vindt. Je kunt ook zoiets als `make` of `make tests` uitvoeren, of wat je ook hebt dat automatische tests voor je uitvoert.
+Door het zo te doen wordt `test-error.sh` uitgevoerd bij elke commit die uitgechecked wordt, totdat Git de eerste kapotte commit vindt. Je kunt ook iets als `make` of `make tests` uitvoeren, of wat je ook hebt dat automatische tests voor je uitvoert.
 
 ## Submodules ##
 
-Het gebeurt vaak dat terwijl je zit te werken aan het ene project, je een ander project er binnenin nodig hebt. Bijvoorbeeld een library die een derde partij ontwikkeld heeft, of die je apart aan het ontwikkelen bent en gebruikt in meerdere projecten. Een veel voorkomend probleem komt in deze scenario's naar voren: je wilt de twee projecten apart behandelen, maar de ene binnen de andere kunnen gebruiken.
+Het komt vaak voor dat terwijl je zit te werken aan het ene project, je een ander project daarbinnen nodig hebt. Bijvoorbeeld een library die een derde partij ontwikkeld heeft, of die je separaat aan het ontwikkelen bent en gebruikt in meerdere projecten. Een veel voorkomend probleem komt in deze scenario's naar voren: je wilt de twee projecten apart behandelen, maar de ene binnen de andere kunnen gebruiken.
 
-Hier is een voorbeeld. Stel dat je een website aan het ontwikkelen bent en Atom feeds aan het maken bent. In plaats van je eigen Atom feedcode te schrijven, besluit je een library te gebruiken. Je zult deze code waarschijnlijk moeten includen van een gedeelde library zoals een CPAN installatie of een Ruby gem, of de broncode kopiëren naar je eigen projectboom. Het probleem met de library includen is dat het lastig is om de library op enige manier aan te passen, en vaak is het lastiger om het uit te rollen, omdat je zeker moet zijn dat iedere klant die library beschikbaar heeft. Het probleem van de broncode in je project stoppen is dat alle aanpassingen die je maakt lastig te mergen zijn op het moment dat stroomopwaarts veranderingen beschikbaar komen.
+Hier is een voorbeeld. Stel dat je een website aan het ontwikkelen bent en Atom feeds aan het maken bent. In plaats van je eigen Atom-genererende code te schrijven, besluit je een library te gebruiken. Je zult deze code waarschijnlijk moeten includen van een gedeelde library zoals een CPAN installatie of een Ruby gem, of de broncode kopiëren naar je eigen projectboom. Het probleem met de library includen is dat het lastig is om de library op enige manier aan te passen, en vaak nog lastiger is om het uit te rollen omdat je zeker moet zijn dat iedere client die library beschikbaar heeft. Het probleem van de broncode in je project stoppen is dat alle aanpassingen die je maakt lastig te mergen zijn op het moment dat stroomopwaarts veranderingen beschikbaar komen.
 
-Git pakt dit probleem aan door submodules te gebruiken. Submodules geven je de mogelijkheid om een Git repository als een subdirectory van een ander Git repository te gebruiken. Dit staat je toe een ander repository in je project te klonen en je commits gescheiden te houden.
+Git pakt dit probleem aan door submodules te gebruiken. Submodules geven je de mogelijkheid om een Git repository als een subdirectory van een ander Git repository te gebruiken. Dit stelt je in staat staat een ander repository in je project te klonen en je commits gescheiden te houden.
 
 ### Beginnen met submodules ###
 
-Stel dat je de Rack library (een Ruby web server gateway interface) wilt toevoegen aan je project, misschien je eigen veranderingen eraan wilt onderhouden, maar ook veranderingen van stroomopwaarts wilt mergen. Het eerste dat je zou moeten doen is het externe repository klonen in jouw submap. Je voegt externe projecten als submodules toe door middel van het `git submodule add` commando:
+Stel dat je de Rack library (een Ruby web server gateway interface) wilt toevoegen aan je project, misschien je eigen veranderingen eraan wilt onderhouden, maar ook veranderingen van stroomopwaarts wilt mergen. Het eerste dat je zou moeten doen is de externe repository klonen in jouw subdirectory. Je voegt externe projecten als submodules toe door middel van het `git submodule add` commando:
 
 	$ git submodule add git://github.com/chneukirchen/rack.git rack
 	Initialized empty Git repository in /opt/subtest/rack/.git/
@@ -823,7 +839,7 @@ Stel dat je de Rack library (een Ruby web server gateway interface) wilt toevoeg
 	Receiving objects: 100% (3181/3181), 675.42 KiB | 422 KiB/s, done.
 	Resolving deltas: 100% (1951/1951), done.
 
-Nu heb je het Rack project onder een submap genaamd `rack` binnen je project. Je kunt in die submap gaan, wijzigingen maken, je eigen schrijfbare remote repository waar je veranderingen in kunt pushen toevoegen, vanuit het originele repository fetchen en mergen, en meer. Als je `git status` uitvoert vlak nadat je de submodule toevoegd, zou je twee dingen moeten zien:
+Nu heb je het Rack project in je eigen project onder een subdirectory genaamd `rack`. Je kunt in die subdirectory gaan, wijzigingen maken, je eigen schrijfbare remote repository  toevoegen waar je veranderingen in kunt pushen, vanuit de originele repository fetchen en mergen, en zo meer. Als je `git status` uitvoert vlak nadat je de submodule toevoegt, zou je twee dingen moeten zien:
 
 	$ git status
 	# On branch master
@@ -834,14 +850,14 @@ Nu heb je het Rack project onder een submap genaamd `rack` binnen je project. Je
 	#      new file:   rack
 	#
 
-Eerst zie je het `.gitmodules` bestand. Dit is een configuratie bestand dat de mapping opslaat tussen de URL van het project en de locale submap waarin je het binnen gepulled hebt:
+Eerst zie je het `.gitmodules` bestand. Dit is een configuratie bestand dat de mapping opslaat tussen de URL van het project en de locale subdirectory waarin je het gepulled hebt:
 
 	$ cat .gitmodules
 	[submodule "rack"]
 	      path = rack
 	      url = git://github.com/chneukirchen/rack.git
 
-Als je meerdere submodules hebt, zul je meerdere vermeldingen hebben in dit bestand. Het is belangrijk om te zien dat dit bestand net als je andere bestanden ook onder versiebeheer staat, zoals je `.gitignore` bestand. Het wordt gepusht en gepulled samen met de rest van je project. Op deze manier weten andere mensen die je project klonen waar ze de submodule projecten vandaan moeten halen.
+Als je meerdere submodules hebt, zal je meerdere vermeldingen hebben in dit bestand. Het is belangrijk om op te merken dat dit bestand net als je andere bestanden ook onder versiebeheer staat, zoals het `.gitignore` bestand. Het wordt samen met de rest van het project gepusht en gepulled. Op deze manier weten andere mensen die je project klonen waar ze de submodule projecten vandaan moeten halen.
 
 De andere vermelding in de `git status` output is de rack regel. Als je `git diff` daarop uitvoert zul je iets interessants zien:
 
@@ -854,7 +870,7 @@ De andere vermelding in de `git status` output is de rack regel. Als je `git dif
 	@@ -0,0 +1 @@
 	+Subproject commit 08d709f78b8c5b0fbeb7821e37fa53e69afcf433
 
-Alhoewel `rack` een submap in je werkmap is, ziet Git het als een submodule en zal de inhoud niet volgen als je niet in die map staat. In plaats daarvan slaat Git het als een aparte commit op van dat repository. Als je wijzigingen maakt en in die submap een commit doet, zal het superproject zien dat de HEAD daarin is veranderd en de exacte commit opslaan waarvan je op dat moment zit te werken; op die manier zullen anderen die dit project klonen de omgeving exact kunnen reproduceren.
+Hoewel `rack` een subdirectory in je werkdirectory is, ziet Git het als een submodule en zal de inhoud niet tracken als je niet in die directory staat. In plaats daarvan slaat Git het als een aparte commit op van dat repository. Als je wijzigingen maakt en in die subdirectory een commit doet, zal het superproject zien dat de HEAD daar is veranderd en de exacte commit opslaan waarvan je op dat moment zit te werken; op die manier zullen anderen die dit project klonen de omgeving exact kunnen reproduceren.
 
 Dit is een belangrijk punt met submodules: je slaat ze op als de exacte commit waar ze op staan. Je kunt een submodule niet opslaan als `master` of een andere symbolische referentie.
 
@@ -866,9 +882,9 @@ Als je commit, zou je zoiets als dit moeten zien:
 	 create mode 100644 .gitmodules
 	 create mode 160000 rack
 
-Zie de 160000 modus voor de rack vermelding. Dat is een speciale modus binnen Git, die in feite betekent dat je een commit als een map vermelding opslaat in plaats van als een submap of een bestand.
+Zie de 160000 modus voor de rack vermelding. Dat is een speciale modus binnen Git, die in feite betekent dat je een commit als een directory vermelding opslaat in plaats van als een subdirectory of een bestand.
 
-Je kunt de `rack` map als een apart project behandelen en je superproject van tijd tot tijd vernieuwen met een pointer naar de laatste commit in dat subproject. Alle Git commando's werken onafhankelijk in de twee mappen:
+Je kunt de `rack` directory als een apart project behandelen en je superproject van tijd tot tijd vernieuwen met een pointer naar de laatste commit in dat subproject. Alle Git commando's werken onafhankelijk in de twee directories:
 
 	$ git log -1
 	commit 0550271328a0038865aad6331e620cd7238601bb
@@ -886,7 +902,7 @@ Je kunt de `rack` map als een apart project behandelen en je superproject van ti
 
 ### Een project met submodules klonen ###
 
-Hier zul je een project met een submodule erin klonen. Als je zo'n project ontvangt, krijg je de mappen die submodules bevatten, maar nog niet meteen de bestanden:
+Hier zul je een project met een submodule erin klonen. Als je zo'n project ontvangt, krijg je de directories die submodules bevatten, maar nog niet de bestanden:
 
 	$ git clone git://github.com/schacon/myproject.git
 	Initialized empty Git repository in /opt/myproject/.git/
@@ -902,7 +918,7 @@ Hier zul je een project met een submodule erin klonen. Als je zo'n project ontva
 	$ ls rack/
 	$
 
-De `rack` map is er, maar hij is leeg. Je moet twee commando's uitvoeren: `git submodule init` om je locale configuratie bestand te initialiseren, en `git submodule update` om alle data van dat project te fetchen en de juiste commit die in je superproject staat uit te checken:
+De `rack` directory is er, maar hij is leeg. Je moet twee commando's uitvoeren: `git submodule init` om je locale configuratie bestand te initialiseren, en `git submodule update` om alle data van dat project te fetchen en de juiste commit die in je superproject staat uit te checken:
 
 	$ git submodule init
 	Submodule 'rack' (git://github.com/chneukirchen/rack.git) registered for path 'rack'
@@ -915,7 +931,7 @@ De `rack` map is er, maar hij is leeg. Je moet twee commando's uitvoeren: `git s
 	Resolving deltas: 100% (1951/1951), done.
 	Submodule path 'rack': checked out '08d709f78b8c5b0fbeb7821e37fa53e69afcf433'
 
-Nu is je `rack` submap in exact dezelfde status is als het was toen je het eerder gecommit had. Als een andere developer wijzigingen doet op de rack code en commit, en je pulled die referentie en merged de code, dan krijg je iets dat een beetje vreemd is:
+Nu is je `rack` subdirectory in exact dezelfde staat als het was toen je het eerder gecommit had. Als een andere developer wijzigingen doet op de rack code en commit, en je pulled die referentie en merged de code, dan krijg je iets dat een beetje vreemd is:
 
 	$ git merge origin/master
 	Updating 0550271..85a3eee
@@ -931,7 +947,7 @@ Nu is je `rack` submap in exact dezelfde status is als het was toen je het eerde
 	#      modified:   rack
 	#
 
-Je hebt iets ingemerged dat eigenlijk een wijziging is op de pointer naar je submodule; maar de code in de submodule map niet vernieuwd, dus het lijkt erop dat je een vieze status hebt in je werkmap:
+Je hebt iets gemerged dat eigenlijk een wijziging is op de pointer naar je submodule; maar de code in de submodule directory niet vernieuwd, dus het lijkt erop dat je een vieze status hebt in je werkdirectory:
 
 	$ git diff
 	diff --git a/rack b/rack
@@ -942,7 +958,7 @@ Je hebt iets ingemerged dat eigenlijk een wijziging is op de pointer naar je sub
 	-Subproject commit 6c5e70b984a60b3cecd395edd5b48a7575bf58e0
 	+Subproject commit 08d709f78b8c5b0fbeb7821e37fa53e69afcf433
 
-Dit is het geval omdat de pointer die je hebt voor de submodule niet is wat eigenlijk in de submodule map zit. Om dit te repareren moet je `git submodule update` opnieuw uitvoeren:
+Dit is het omdat de pointer die je hebt voor de submodule niet is wat eigenlijk in de submodule directory zit. Om dit te repareren moet je `git submodule update` opnieuw uitvoeren:
 
 	$ git submodule update
 	remote: Counting objects: 5, done.
@@ -955,13 +971,13 @@ Dit is het geval omdat de pointer die je hebt voor de submodule niet is wat eige
 
 Je moet dit iedere keer dat je een submodule wijziging pulled in het hoofdproject. Het is vreemd, maar het werkt.
 
-Er probleem doet zich voor als een developer een locale wijziging in en submodule doet en die niet naar een publieke server pusht. Dan, zullen ze een pointer naar de niet-publieke status committen en naar het superproject pushen. Als andere developers dan `git submodule update` proberen uit te voeren, dan zal het submodule systeem de commit die gerefereerd wordt niet kunnen vinden, omdat het alleen op het systeem van de eerste developer bestaat. Als dat gebeurd, zul je een foutmelding als deze zien:
+Eén bekend probleem doet zich voor als een developer een locale wijziging in en submodule doet maar die niet naar een publieke server pushed. Dan committen ze een pointer naar de niet-publieke status en pushen deze naar het superproject. Als andere developers dan `git submodule update` proberen uit te voeren, dan zal het submodule systeem de commit die gerefereerd wordt niet kunnen vinden omdat het alleen op het systeem van de eerste developer bestaat. Als dat gebeurd, zul je een foutmelding als deze zien:
 
 	$ git submodule update
 	fatal: reference isn’t a tree: 6c5e70b984a60b3cecd395edd5b48a7575bf58e0
 	Unable to checkout '6c5e70b984a60b3cecd395edd5ba7575bf58e0' in submodule path 'rack'
 
-Je moet dan zien wie als laatste de submodule veranderd heeft:
+Je moet dan bekijken wie als laatste de submodule veranderd heeft:
 
 	$ git log -1 rack
 	commit 85a3eee996800fcfa91e2119372dd4172bf76678
@@ -970,21 +986,21 @@ Je moet dan zien wie als laatste de submodule veranderd heeft:
 
 	    added a submodule reference I will never make public. hahahahaha!
 
-Dan stuur je een e-mail naar die man en schreeuwt tegen hem.
+Dan stuur je een e-mail naar die jongen en gaat boos zijn tegen hem.
 
 ### Superprojecten ###
 
-Soms willen developers een combinatie van de submappen van een groot project hebben, afhankelijk van het team waarin ze zitten. Dit komt vaak voor als je van CVS of Subversion af komt, waar je een module of verzameling submappen gedefinieerd hebt, en je wilt deze manier van werken behouden.
+Soms willen developers een combinatie van subdirectories van een groot project hebben, afhankelijk van het team waarin ze zitten. Dit komt vaak voor als je van CVS of Subversion af komt, waar je een module of verzameling subdirectory gedefinieerd hebt en je wilt deze manier van werken behouden.
 
-Een goeie manier om dit in Git te doen is om ieder van de submappen een aparte Git repository te maken en dan superproject Git repositories te maken die meerdere submodules kunnen bevatten. Een voordeel van deze aanpak is dat je meer specifiek kunt definiëren wat de relaties tussen de projecten zijn met behulp van tags en branches in de superprojects.
+Een goeie manier om dit in Git te doen is om elk van de subdirectories een aparte Git repository te maken en dan superproject Git repositories te maken die meerdere submodules kunnen bevatten. Een voordeel van deze aanpak is dat je meer specifiek kunt definiëren wat de relaties tussen de projecten zijn met behulp van tags en branches in de superprojects.
 
 ### Problemen met submodules ###
 
-Submodules gebruiken is echter niet zonder gevaar. Ten eerste moet je relatief voorzichtig zijn met het werken in een submap. Als je `git submodule update` uitvoert, zal het de specifieke versie van het project uitchecken, maar niet binnen een branch. Dit wordt een afgekoppelde HEAD genoemd – het betekent dat het HEAD bestand direct naar een commit wijst, en niet naar een symbolische referentie. Het probleem is dat je over het algemeen niet wilt werken in een afgekoppelde head omgeving, omdat het makkelijk is om veranderingen te verliezen. Als je een initiële `submodule update` doet, in die submodule map commit zonder een branch te maken om in te werken, an dan nogmaals `git submodule update` uitvoert in het superproject zonder in de tussentijd te committen, dan zal Git je veranderingen overschrijven zonder het je te vertellen. Technisch gezien ben je het werk niet kwijt, maar je zult geen branch hebben die er naar wijst, dus het zal lastig zijn om het terug te halen.
+Submodules gebruiken is echter niet zonder probleempjes. Ten eerste moet je relatief voorzichtig zijn met het werken in een subdirectory. Als je `git submodule update` uitvoert, zal het de specifieke versie van het project uitchecken, maar niet binnen een branch. Dit wordt een afgekoppelde (detached) HEAD genoemd – het houdt in dat het HEAD bestand direct naar een commit wijst en niet naar een symbolische referentie. Het probleem is dat je over het algemeen niet wilt werken in een detached HEAD omgeving, omdat het eenvoudig is om wijzigingen te verliezen. Als je een initiële `submodule update` doet, in die submodule directory commit zonder een branch te maken om in te werken en dan nogmaals `git submodule update` uitvoert in het superproject zonder in de tussentijd te committen, dan zal Git je wijzigingen overschrijven zonder het je te vertellen. Technisch gezien ben je het werk niet kwijt, maar je zult geen branch hebben die er naar wijst, dus het zal lastig zijn om het terug te halen.
 
-Om dit probleem te vermijden, creëer je een branch zodra je in een submodule map werkt met behulp van `git checkout -b work` of iets gelijkwaardigs. Als je de tweede keer de submodule update doet, zal het nog steeds je werk terugdraaien, maar je heb er tenminste een pointer van om naar terug te keren.
+Om dit probleem te vermijden creëer je een branch zodra je in een submodule directory werkt met behulp van `git checkout -b work` of iets dergelijks. Als je de tweede keer de submodule update doet, zal het nog steeds je werk terugdraaien maar je heb tenminste een pointer om naar terug te keren.
 
-Van branches wisselen die submodules bevatten kan ook lastig zijn. Als je een nieuwe branch aanmaakt, daar een submodule toevoegt, en dat terug wisselt naar een branch zonder die submodule, zul je nog steeds de submodule map als een ongevolgde submap hebben:
+Van branches wisselen die submodules bevatten kan ook lastig zijn. Als je een nieuwe branch aanmaakt, daar een submodule toevoegt en dat terug wisselt naar een branch zonder die submodule, zul je nog steeds de submodule directory als een untracked subdirectory hebben:
 
 	$ git checkout -b rack
 	Switched to a new branch "rack"
@@ -1007,15 +1023,15 @@ Van branches wisselen die submodules bevatten kan ook lastig zijn. Als je een ni
 	#
 	#      rack/
 
-Je moet hem verplaatsen of verwijderen, waarna je hem opnieuw moet klonen als je terug wisselt – en je loopt kans om locale wijzigingen of branches te verliezen die je niet omhoog gepusht hebt.
+Je moet hem verplaatsen of verwijderen, in welk geval je hem opnieuw moet klonen als je terug wisselt. Daarbij loop je kans om locale wijzigingen of branches te verliezen die je niet gepusht hebt.
 
-De laatste grote valkuil waar veel mensen in lopen heeft te maken met het wisselen van submappen naar submodules. Als je bestanden in je project aan het volgen bent, en je wilt ze in een submodule verplaatsen, dan moet je voorzichtig zijn of anders zal Git boos op je worden. Stel dat je de rack bestanden in een submap van je project hebt, en je wilt die naar een submodule wijzigen. Als je de submap weggooit en dan `submodule add` uitvoerd, begint Git naar je te schreeuwen:
+De laatste grote valkuil waar veel mensen in lopen heeft te maken met het wisselen van subdirectories naar submodules. Als je bestanden in je project tracked en je wilt ze naar een submodule verplaatsen, dan moet je voorzichtig zijn of zal Git boos op je worden. Stel dat je de rack bestanden in een subdirectory van je project hebt, en je wilt die naar een submodule wijzigen. Als je de subdirectory weggooit en dan `submodule add` uitvoert, begint Git naar je te schreeuwen:
 
 	$ rm -Rf rack/
 	$ git submodule add git@github.com:schacon/rack.git rack
 	'rack' already exists in the index
 
-Je moet de `rack` submap eerst unstagen. Dan kun je de submodule toevoegen:
+Je moet de `rack` subdirectory eerst unstagen. Dan kun je de submodule toevoegen:
 
 	$ git rm -r rack
 	$ git submodule add git@github.com:schacon/rack.git rack
@@ -1026,12 +1042,12 @@ Je moet de `rack` submap eerst unstagen. Dan kun je de submodule toevoegen:
 	Receiving objects: 100% (3184/3184), 677.42 KiB | 88 KiB/s, done.
 	Resolving deltas: 100% (1952/1952), done.
 
-Stel dat je dat in een branch gedaan had. Als je probeert terug te wisselen naar een branch waar die bestanden nog in de echte boom zitten in plaats van in een submodule – dan krijg je deze foutmelding:
+Stel nu dat je dat in een branch gedaan had. Als je probeert terug te wisselen naar een branch waar die bestanden nog in de echte boom zitten in plaats van in een submodule – dan krijg je deze foutmelding:
 
 	$ git checkout master
 	error: Untracked working tree file 'rack/AUTHORS' would be overwritten by merge.
 
-Je moet de `rack` submodule map verplaatsen voordat je naar een branch kunt wisselen die hem nog niet heeft:
+Je moet de `rack` submodule directory uit de weg halen voordat je naar een branch kunt wisselen die hem nog niet heeft:
 
 	$ mv rack /tmp/
 	$ git checkout master
@@ -1039,17 +1055,17 @@ Je moet de `rack` submodule map verplaatsen voordat je naar een branch kunt wiss
 	$ ls
 	README	rack
 
-Als je dan terug wisselt krijg je een lege `rack` map. Je kunt dan nogmaals `git submodule update` uitvoeren om nog eens te klonen, of je kunt je `/tmp/rack` map terug zetten in de lege map.
+Als je dan terug wisselt krijg je een lege `rack` directory. Je kunt dan nogmaals `git submodule update` uitvoeren om nog eens te klonen, of je kunt je `/tmp/rack` directory terug zetten in de lege directory.
 
 ## Subboom mergen ##
 
-Nu je de moeilijkheden van het submodulesysteem hebt gezien, laten we eens kijken naar een alternatieve manier om hetzelfde probleem aan te pakken. Zodra Git merge't, kijkt het naar wat het samen moet mergen en kiest dan een toepasselijke mergestrategie om te gebruiken. Als je twee branches aan het mergen bent, zal Git een _recursive_ strategie gebruiken. Als je meer dan twee branches aan het mergen bent, zal Git de _octopus_ strategie kiezen. Deze strategieën worden automatisch voor je gekozen, omdat de recursieve strategie complexe drie-weg merge situaties kan behandelen – bijvoorbeeld, meer dan één gezamenlijke voorouder – maar het kan slechts twee branches behandelen. De octopus merge kan meerdere branches behandelen, maar is voorzichtiger om moeilijke conflicten te vermijden, dus is het gekozen als de standaard strategie als je meer dan twee branches probeert te mergen.
+Nu je de moeilijkheden van het submodulesysteem hebt gezien, laten we eens kijken naar een alternatieve manier om hetzelfde probleem aan te pakken. Zodra Git merged, kijkt het naar wat het moet mergen en kiest dan een toepasselijke mergestrategie om te gebruiken. Als je twee branches aan het mergen bent zal Git een _recursive_ strategie gebruiken. Als je meer dan twee branches aan het mergen bent zal Git de _octopus_ strategie kiezen. Deze strategieën worden automatisch voor je gekozen omdat de recursieve strategie complexe drie-weg merge situaties aan kan; bijvoorbeeld meer dan één gezamenlijke voorouder, maar het kan het alleen mergen van twee branches aan. De octopus merge kan meerdere branches verwerken, maar is voorzichtiger om moeilijke conflicten te vermijden, dus is het gekozen als de standaard strategie als je meer dan twee branches probeert te mergen.
 
-Maar er zijn meerdere strategieën die je ook kunt kiezen. Eén ervan is de _subtree_ merge, en je kunt het gebruiken om met het subproject probleem om te gaan. Hier zul je zien hoe je dezelfde rack inbedding kunt doen als in de laatste sectie, maar in plaats daarvan subboommerges te gebruiken.
+Maar er zijn andere strategieën die je ook kunt kiezen. Eén ervan is de _subtree_ merge, en je kunt deze gebruiken om het subproject probleem aan te gaan. Hier zul je zien hoe je dezelfde rack inbedding kunt doen als in de laatste paragraaf, maar in plaats daarvan subboommerges gebruiken.
 
-Het idee van de subboommerge is dat je twee projecten hebt, en één van de projecten wijst naar de submap van de andere en vice versa. Als je een subboommerge specificeerd, dan is Git slim genoeg om uit te vogelen dat de ene een subboom van de andere is en toepasselijk te mergen – het is erg verbazingwekkend.
+Het idee van de subboommerge is dat je twee projecten hebt, en één van de projecten wijst naar de subdirectory van de andere en omgekeerd. Als je een subboommerge specificeert, dan is Git slim genoeg om uit te vogelen dat de ene een subboom van de andere is en vervolgens juist te mergen, het is nogal verbazingwekkend.
 
-Eerst voeg je de Rack applicatie toe aan je project. Dan voeg je het Rack project toe als een remote reference in je eigen project en checked het dan uit in zijn eigen branch:
+Eerst voeg je de Rack applicatie toe aan je project. Voeg het Rack project toe als een remote reference in je eigen project en check het dan uit in zijn eigen branch:
 
 	$ git remote add rack_remote git@github.com:schacon/rack.git
 	$ git fetch rack_remote
@@ -1068,7 +1084,7 @@ Eerst voeg je de Rack applicatie toe aan je project. Dan voeg je het Rack projec
 	Branch rack_branch set up to track remote branch refs/remotes/rack_remote/master.
 	Switched to a new branch "rack_branch"
 
-Nu heb je de wortel van het Rack project in je `rack_branch` branch en je eigen project in de `master` branch. Als je één uitchecked en dan de andere, kun je zien dat ze verschillende project wortels hebben:
+Nu heb je de root van het Rack project in je `rack_branch` branch en je eigen project in de `master` branch. Als je één uitchecked en dan de andere, kun je zien dat ze verschillende project roots hebben:
 
 	$ ls
 	AUTHORS	       KNOWN-ISSUES   Rakefile      contrib	       lib
@@ -1078,32 +1094,32 @@ Nu heb je de wortel van het Rack project in je `rack_branch` branch en je eigen
 	$ ls
 	README
 
-Je wilt het Rack project in je `master` project pullen als een submap. Je kunt dat in Git doen met `git read-tree`. Je zult meer over `read-tree` en zijn vrienden leren in Hoofdstuk 9, maar weet voor nu dat het de wortel boom van een branch in je huidige staging area en werkmap leest. Je hebt zojuist teruggewisseld naar je `master` branch, en je pulled de `rack` branch in de `rack` submap van je `master` branch in je hoofdproject:
+Je gaat nu het Rack project in je `master` project pullen als een subdirectory. Je kunt dat in Git doen met `git read-tree`. Je zult meer over `read-tree` en zijn vriendjes leren in Hoofdstuk 9, maar weet voor nu dat het de roottree van een branch in je huidige staging area en werkdirectory leest. Je hebt zojuist teruggewisseld naar je `master` branch, en je pulled de `rack` branch in de `rack` subdirectory van de `master` branch van je hoofdproject:
 
 	$ git read-tree --prefix=rack/ -u rack_branch
 
-Als je commit, ziet het eruit alsof je alle Rack bestanden in die submap hebt – alsof je ze uit een tarball gekopieerd hebt. Wat interessant is is dat je vrij makkelijk veranderingen van één branch in de andere kunt mergen. Dus als het Rack project vernieuwd kun je alle stroomopwaartse wijzigingen binnenhalen door naar die branch te wisselen en te pullen:
+Als je commit, ziet het eruit alsof alle Rack bestanden in die subdirectory staan; alsof je ze uit een tarball gekopieerd hebt. Waar het interessant wordt is dat je vrij makkelijk veranderingen van één branch in de andere kunt mergen. Dus als het Rack project update kan je alle wijzigingen van stroomopwaartse binnenhalen door naar die branch te wisselen en te pullen:
 
 	$ git checkout rack_branch
 	$ git pull
 
-Dan kun je die veranderingen in je master branch mergen. Je kunt `git merge -s subtree` gebruiken en het zal prima werken; maar Git zal ook de geschiedenissen samenvoegen, wat je waarschijnlijk niet wilt. Om de veranderingen binnen te halen en het commit bericht te vullen, gebruik dan de `--squash` en `--no-commit` opties samen met de `-s subtree` strategie optie:
+Dan kun je die veranderingen terug in je master branch mergen. Je kunt `git merge -s subtree` gebruiken en het zal prima werken, maar Git zal ook de geschiedenissen mergen, en dat wil je waarschijnlijk niet. Om de veranderingen binnen te halen en het commit bericht voor te vullen, gebruik je de `--squash` en `--no-commit` opties samen met de `-s subtree` strategie optie:
 
 	$ git checkout master
 	$ git merge --squash -s subtree --no-commit rack_branch
 	Squash commit -- not updating HEAD
 	Automatic merge went well; stopped before committing as requested
 
-Alle wijzigingen van je Rack project worden ingemerged en zijn klaar om lokaal gecommit te worden. Je kunt ook het tegenovergestelde doen – veranderingen doen in de `rack` submap van je master branch en dan die later in je `rack_branch` branch mergen om ze naar de eigenaren te sturen of ze stroomopwaarts te pushen.
+Alle wijzigingen van het Rack project worden gemerged en zijn klaar om lokaal gecommit te worden. Je kunt ook het tegenovergestelde doen: veranderingen doen in de `rack` subdirectory van de master branch en die later in je `rack_branch` branch mergen om ze naar de beheerders te sturen of ze stroomopwaarts te pushen.
 
-Om een diff te krijgen tussen wat je in je `rack` submap hebt en de code in je `rack_branch` branch – om te zien of je ze moet mergen – kun je niet het gebruikelijke `diff` commando toepassen. In plaats daarvan moet je `git diff-tree` uitvoeren met de branch waarmee je wilt vergelijken:
+Om een diff te krijgen tussen wat je in de `rack` subdirectory hebt en de code in je `rack_branch` branch (om te zien of je ze moet mergen) kan je niet het gebruikelijke `diff` commando toepassen. In plaats daarvan moet je `git diff-tree` uitvoeren met de branch waarmee je wilt vergelijken:
 
 	$ git diff-tree -p rack_branch
 
-Of, om te vergelijken met wat in je `rack` submap zit met wat in de `master` branch op de server zat de laatste keer dat je gefetched hebt, kun je dit uitvoeren:
+Of om te vergelijken met wat in je `rack` subdirectory zit met wat in de `master` branch op de server zat toen je de laatste keer fetchde, kan je dit uitvoeren:
 
 	$ git diff-tree -p rack_remote/master
 
 ## Samenvatting ##
 
-Je hebt een aantal geavanceerde tools gezien, die je toestaan je commits en je staging area meer exact te manipuleren. Als je problemen signaleert kun je vrij eenvoudig uitvinden welke commit deze geïntroduceerd heeft, wanneer ze geïntroduceerd zijn en door wie. Als je subprojecten in je project wilt gebruiken, heb je een paar manieren geleerd hoe je die kunt accommoderen. Op dit punt zou je in staat moeten zijn om het meeste van de dingen in Git te kunnen doen die je dagelijks op de commandline moet doen, en je er op je gemak bij moeten voelen.
+Je hebt een aantal geavanceerde tools gezien, die je in staat stellen je commits en staging area heel exact te manipuleren. Als je problemen signaleert kun je vrij eenvoudig uitvinden welke commit deze geïntroduceerd heeft, wanneer ze geïntroduceerd zijn en door wie. Als je subprojecten in je project wilt gebruiken, heb je een paar manieren geleerd hoe je die een plaats kunt geven. Op dit punt zou je in staat moeten zijn om de meeste dingen in Git te kunnen doen die je dagelijks op de commandline moet doen, en je erbij op je gemak te voelen.

From 7b9819ba26fd07cf33a8a8b27104e919ac9933e9 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Tue, 4 Feb 2014 10:20:39 -0600
Subject: [PATCH 195/690] Reviewed "About Version Control"

---
 it/01-introduction/01-chapter1.markdown | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/it/01-introduction/01-chapter1.markdown b/it/01-introduction/01-chapter1.markdown
index 17c55c7a7..f9ae0f6a9 100644
--- a/it/01-introduction/01-chapter1.markdown
+++ b/it/01-introduction/01-chapter1.markdown
@@ -1,12 +1,12 @@
 # Per Iniziare #
 
-Questo capitolo spiegherà come iniziare ad usare Git.  Inizieremo con una introduzione sugli strumenti di controllo della versione,  per poi passare a come far funzionare Git sul proprio sistema  ed infine come configurarlo per lavorarci.  Alla fine di questo capitolo, dovresti capire a cosa serve Git, perché lo dovresti usare ed essere pronto ad usarlo.
+Questo capitolo spiegherà come iniziare ad usare Git. Inizieremo con una introduzione sugli strumenti per il controllo delle versioni,  per poi passare a come far funzionare Git sul proprio sistema e quindi come configurarlo per lavorarci. Alla fine di questo capitolo, dovresti capire a cosa serve Git, perché dovresti usarlo e dovresti essere pronto ad usarlo.
 
 ## Il Controllo di Versione ##
 
-Cos'è il controllo di versione, e perché dovresti usarlo? Il controllo di versione è un sistema che registra i cambiamenti ad un file o ad una serie di file nel tempo, così da poter richiamare una versione specifica successivamente. Per gli esempi in questo libro, useremo i file del codice sorgente di un software per controllarne la versione, anche se in realtà si può fare con quasi ogni tipo di file sul computer.
+Cos'è il controllo di versione, e perché dovresti usarlo? Il controllo di versione è un sistema che registra, nel tempo, i cambiamenti ad un file o ad una serie di file, così da poter richiamare una specifica versione in un secondo momento. Sebbene gli esempi di questo libro usino i sorgenti di un software per controllarne la versione, qualsiasi file di un computer può essere posto sotto controllo di versione.
 
-Se sei un grafico o un webdesigner e vuoi tenere tutte le versioni di un'immagine o di un layout (e sicuramente lo vorrai fare), un Version Control System (VCS) è una cosa saggia da usare. Ti permette di ripristinare i file ad uno stato precedente, ripristinare l'intero progetto ad uno stato precedente, comparare i cambiamenti nel tempo, vedere chi ha modificato cosa che può aver causato un problema, chi ha introdotto un problema e quando, e altro ancora. Usare un VCS, in generale, significa che se si fanno dei pasticci o si perdono dei file, si possono facilmente ripristinare. In aggiunta, si ottiene tutto questo con un piccolo dispendio di risorse.
+Se sei un grafico o un webdesigner e vuoi tenere tutte le versioni di un'immagine o di un layout (e sicuramente lo vorrai fare), sarebbe saggio usare un Sistema per il Controllo di Versione (_Version Control System_ - VCS). Un VCS ti permette di ripristinare i file ad una versione precedente, ripristinare l'intero progetto a uno stato precedente, revisionare le modifiche fatte nel tempo, vedere chi ha cambiato qualcosa che può aver causato un problema, chi ha introdotto un problema e quando, e molto altro ancora. Usare un VCS significa anche che se fai un pasticcio o perdi qualche file, puoi facilmente recuperare la situazione. E ottieni tutto questo con poca fatica.
 
 ### Sistema di Controllo di Versione Locale ###
 

From e65902aebe96cb967e5706ec03f21216d1629f5a Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Tue, 4 Feb 2014 10:28:37 -0600
Subject: [PATCH 196/690] Reviewed "Local Version Control Systems"

---
 it/01-introduction/01-chapter1.markdown | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/it/01-introduction/01-chapter1.markdown b/it/01-introduction/01-chapter1.markdown
index f9ae0f6a9..f1c06f1e0 100644
--- a/it/01-introduction/01-chapter1.markdown
+++ b/it/01-introduction/01-chapter1.markdown
@@ -10,14 +10,14 @@ Se sei un grafico o un webdesigner e vuoi tenere tutte le versioni di un'immagin
 
 ### Sistema di Controllo di Versione Locale ###
 
-Il metodo di controllo di versione scelto da molte persone è di copiare i file in un'altra directory (magari una directory denominata con la data, se sono furbi). Questo approccio è molto comune perché è molto semplice, ma è anche incredibilmente soggetto ad errori. É facile dimenticarsi la directory in cui ci si trova e accidentalmente scrivere sul file sbagliato o copiare i file che non si intendevano copiare.
+Molte persone gestiscono le diverse versioni copiando i file in un'altra directory (magari una directory denominata con la data, se sono furbi). Questo approccio è molto comune perché è molto semplice, ma è anche incredibilmente soggetto ad errori. É facile dimenticare in quale directory sei e modificare il file sbagliato o copiare dei file che non intendevi copiare.
 
-Per far fronte a questo problema, i programmatori svilupparono VCS locali che avevano un semplice database che manteneva tutti i cambiamenti dei file sotto controllo di revisione (vedi Figura 1-1).
+Per far fronte a questo problema, i programmatori svilupparono VCS locali che avevano un database semplice che manteneva tutti i cambiamenti dei file sotto controllo di revisione (vedi Figura 1-1).
 
 Insert 18333fig0101.png 
-Figura 1-1. Diagramma di controllo di versione locale.
+Figura 1-1. Diagramma di controllo di un sistema locale.
 
-Uno dei più popolari strumenti VCS era un sistema chiamato rcs, che è ancora oggi distribuito con alcuni computer. Anche il popolare sistema operativo Mac OS X include il comando rcs quando si installano gli Strumenti di Sviluppo. Semplicemente questo strumento funziona mantenendo una serie di patch (che sono le differenze fra i file) da un cambiamento ad un altro in un formato specifico sul disco; esso può poi ricreare qualsiasi file come se fosse quel file in un determinato momento aggiungendo tutte le patch.
+Uno dei più popolari strumenti VCS era un sistema chiamato rcs, che è ancora oggi distribuito con molti computer. Anche il popolare sistema operativo Mac OS X include il comando rcs quando si installano gli Strumenti di Sviluppo. Questo strumento funziona salvando sul disco una serie di patch (ovvero le differenze tra i file) tra una versione e l'altra, in un formato specifico; può quindi ricreare lo stato di qualsiasi file in qualsiasi momento determinato momento, aggiungendo le varie patch.
 
 ### Sistemi di Controllo di Versione Centralizzati ###
 

From d369fb57163f03ba59c60b32632054368317ae46 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Tue, 4 Feb 2014 10:38:01 -0600
Subject: [PATCH 197/690] Reviewed "Centralized Version Control Systems"

---
 it/01-introduction/01-chapter1.markdown | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/it/01-introduction/01-chapter1.markdown b/it/01-introduction/01-chapter1.markdown
index f1c06f1e0..319852f75 100644
--- a/it/01-introduction/01-chapter1.markdown
+++ b/it/01-introduction/01-chapter1.markdown
@@ -21,14 +21,14 @@ Uno dei più popolari strumenti VCS era un sistema chiamato rcs, che è ancora o
 
 ### Sistemi di Controllo di Versione Centralizzati ###
 
-Il problema successivo in cui incorsero le persone è che queste hanno bisogno di collaborare con altri sviluppatori su altri sistemi. Per far fronte a questo problema, vennero sviluppati sistemi di controllo di versione centralizzati (Centralized Version Control Systems, CVCS). Questi sistemi, come CVS, Subversion e Perforce, hanno un singolo server che contiene tutte le versioni dei file e un numero di utenti che controllano i file dalla centrale. Per alcuni anni, questo fu lo standard per il controllo di versione (vedi Figura 1-2).
+Successivamente queste persone dovettero affrontare il problema del collaborare con altri sviluppatori su altri sistemi. Per far fronte a questo problema, vennero sviluppati sistemi di controllo di versione centralizzati (_Centralized Version Control Systems_ - CVCS). Questi sistemi, come CVS, Subversion e Perforce, hanno un unico server che contiene tutte le versioni dei file e un numero di utenti che scaricano i file dal server centrale. Questo è stato lo standard del controllo di versione per molti anni (vedi Figura 1-2).
 
 Insert 18333fig0102.png 
 Figura 1-2. Diagramma controllo di versione centralizzato.
 
-Questa impostazione offre molti vantaggi, specialmente rispetto ai VCS locali.  Per esempio, chiunque sa, ad un certo livello, cosa stia facendo un'altra persona nel progetto. Gli amministratori hanno un controllo preciso su chi può fare cosa; ed è molto più facile amministrare un tale CVCS che un database locale su ogni client.
+Questa impostazione offre molti vantaggi, specialmente rispetto ai VCS locali.  Per esempio, chiunque sa, con una certa approssimazione, cosa stia facendo un'altra persona del progetto. Gli amministratori hanno un controllo preciso su chi può fare cosa, ed è molto più facile amministrare un CVCS che un database locale su ogni client.
 
-Tuttavia, questa configurazione ha alcuni gravi lati negativi. La più ovvia è il singolo punto di fallimento che il server centralizzato rappresenta. Se questo va giù per un'ora, durante questo periodo nessuno può collaborare o salvare le modifiche di versione di qualsiasi cosa su cui sta lavorando. Se il disco rigido del database centrale si danneggia, e non sono state effettuate copie di backup, perdi assolutamente tutto - tutta la storia del progetto, ad eccezione di singoli snapshot (istantanee) fatte dalle persone sulla loro macchina locale. Anche i sistemi locali di VCS soffrono di questo problema - ogni volta che si ha tutta la storia del progetto in un unico posto, si rischia di perdere tutto.
+Questa configurazione ha tuttavia alcune gravi controindicazioni. La più ovvia è che il server centralizzato rappresenta il singolo punto di rottura del sistema. Se questo va giù per un'ora, in quel periodo nessuno può collaborare o salvare una nuova versione di qualsiasi cosa su cui sta lavorando. Se il disco rigido del database centrale si danneggia, e non ci sono i backup, perdi assolutamente tutto: tutta la storia del progetto ad eccezione dei singoli snapshot (istantanee) che le persone possono avere in locale sulle loro macchine. Anche i sistemi locali di VCS soffrono di questo problema: ogni volta che tutta la storia del progetto è in un unico posto, si rischia di perdere tutto.
 
 ### Sistemi di Controllo di Versione Distribuiti ###
 

From d551e195f099faf79569bd5020f1c01814e3c8fd Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Tue, 4 Feb 2014 12:39:26 -0600
Subject: [PATCH 198/690] Reviewing "Git Basics"

Reviewed:
Git Basics
Snapshots, Not Differences
---
 it/01-introduction/01-chapter1.markdown | 20 ++++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/it/01-introduction/01-chapter1.markdown b/it/01-introduction/01-chapter1.markdown
index 319852f75..87a35e12c 100644
--- a/it/01-introduction/01-chapter1.markdown
+++ b/it/01-introduction/01-chapter1.markdown
@@ -32,44 +32,44 @@ Questa configurazione ha tuttavia alcune gravi controindicazioni. La più ovvia
 
 ### Sistemi di Controllo di Versione Distribuiti ###
 
-E qui entrano in gioco i Sistemi di Controllo di Versione Distribuiti (Distributed Version Control Systems o DVCS). In un DVCS (come Git, Mercurial, Bazaar o Darcs), i client non solo controllano il recente snapshot dei file: essi fanno una copia completa del repository. In tal modo, se si blocca un server ed i sistemi interagiscono tramite un DVCS, un qualsiasi repository di client può essere copiato sul server e quindi ripristinarlo. Ogni checkout, in realtà, è un backup completo di tutti i dati (vedi Figura 1-3).
+E qui entrano in gioco i Sistemi di Controllo di Versione Distribuiti (_Distributed Version Control Systems_ - DVCS). In un DVCS (come Git, Mercurial, Bazaar o Darcs), i client non solo controllano lo _snapshot_ più recente dei file, ma fanno una copia completa del repository. In questo modo se un server morisse e i sistemi interagiscono tramite il DVCS, il repository di un qualsiasi client può essere copiato sul server per ripristinarlo. Ogni checkout è un backup completo di tutti i dati (vedi Figura 1-3).
 
 Insert 18333fig0103.png 
-Figura 1-3. Diagramma controllo di versione distribuito.
+Figura 1-3. Diagramma del controllo di versione distribuito.
 
 Inoltre, molti di questi sistemi trattano bene l'avere più repository remoti su cui poter lavorare, così puoi collaborare con gruppi differenti di persone in modi differenti, simultaneamente sullo stesso progetto. Questo ti permette di impostare diversi tipi di flussi di lavoro che non sono possibili in sistemi centralizzati, come i modelli gerarchici.
 
 ## Una Breve Storia di Git ##
 
-Come per molte grandi cose nella vita, Git è iniziato con un po' di distruzione creativa e polemiche di fuoco. Il kernel di Linux è un progetto software open source di portata abbastanza ampia. Per la manutenzione del kernel Linux, per diverso tempo (1991-2002), le modifiche al software venivano passate sotto forma di patch e file d'archivio. Nel 2002, il progetto del kernel di Linux iniziò ad utilizzare un sistema proprietario chiamato DVCS BitKeeper.
+Come per molte grandi cose della vita, Git è nato con un po' di distruzione creativa e polemiche infuocate. Il kernel di Linux è un progetto software open source di grande portata abbastanza. Per buona parte del tempo (1991-2002) della manutenzione del kernel Linux le modifiche al software venivano passate sotto forma di patch e file compressi. Nel 2002, il progetto del kernel Linux iniziò ad utilizzare un sistema DVCS proprietario chiamato BitKeeper.
 
-Nel 2005, il rapporto tra la comunità che ha sviluppato il kernel Linux e la società commerciale che ha sviluppato BitKeeper si ruppe, e l'uso gratuito di questo strumento fu revocato. Ciò ha indotto la comunità di sviluppo di Linux (e in particolare Linus Torvalds, il creatore di Linux) a sviluppare il proprio strumento, basandosi su alcune delle lezioni apprese durante l'utilizzo di BitKeeper. Alcuni degli obiettivi del nuovo sistema sono i seguenti:
+Nel 2005 il rapporto tra la comunità che sviluppa il kernel Linux e la società commerciale che aveva sviluppato BitKeeper si ruppe, e fu revocato l'uso gratuito di BitKeeper. Ciò indusse la comunità di sviluppo di Linux (e in particolare Linus Torvalds, il creatore di Linux) a sviluppare uno strumento proprio, basandosi su alcune delle lezioni apprese durante l'utilizzo di BitKeeper. Alcuni degli obiettivi del nuovo sistema erano i seguenti:
 
 *	Velocità
 *	Design semplice
-*	Forte supporto allo sviluppo non-lineare (migliaia di rami paralleli)
+*	Ottimo supporto allo sviluppo non-lineare (migliaia di rami paralleli)
 *	Completamente distribuito
 *	Capacità di gestire, in modo efficiente (velocità e dimensione dei dati), grandi progetti come il kernel Linux
 
-Fin dalla sua nascita nel 2005, Git si è evoluto e maturato per essere facile da usare e tuttora mantiene le sue qualità iniziali. E' incredibilmente veloce, è molto efficiente con grandi progetti, ed ha un incredibile sistema di ramificazioni, per lo sviluppo non lineare (Vedi Capitolo 3).
+Fin dalla sua nascita nel 2005 Git si è evoluto e maturato per essere facile da usare e tuttora mantiene le sue qualità iniziali. È incredibilmente veloce, è molto efficiente con progetti grandi e ha un incredibile sistema di ramificazioni, per lo sviluppo non lineare (Vedi Capitolo 3).
 
 ## Basi di Git ##
 
-Quindi, cos'è Git in poche parole? Questa è una sezione importante da assorbire, perché se comprendi che cosa è Git e gli elementi fondamentali di come funziona, allora probabilmente, sarà molto più facile per te usare Git efficacemente. Mentre impari Git, cerca di liberare la mente dalle cose che eventualmente conosci su altri VCS, come Subversion e Perforce; ciò ti aiuterà ad evitare di far confusione utilizzando lo strumento. Git immagazzina e tratta le informazioni in modo diverso dagli altri sistemi, anche se l'interfaccia utente è abbastanza simile; comprendere queste differenze aiuta a prevenire di sentirsi confusi, mentre lo si usa.
+Quindi, cos'è Git in poche parole? Questa è una sezione importante da comprendere, perché se capisci che cos'è Git e gli elementi fondamentali di come funziona, allora sarà probabilmente molto più facile per te usare efficacemente Git. Mentre impari Git, cerca di liberare la tua mente dalle cose che eventualmente già conosci di altri VCS come Subversion e Perforce; ciò ti aiuterà a evitare di far confusione utilizzando lo strumento. Git immagazzina e tratta le informazioni in modo molto diverso dagli altri sistemi, anche se l'interfaccia utente è abbastanza simile; comprendere queste differenze aiuta a prevenire di sentirsi confusi mentre lo si usa.
 
 ### Istantanee, non Differenze ###
 
-La principale differenza tra Git e gli altri VCS (Subversion e compagnia), è il modo in cui Git considera i suoi dati. Concettualmente, la maggior parte degli altri sistemi salvano l'informazione come una lista di cambiamenti  apportati ai file. Questi sistemi (CVS, Subversion, Perforce, Bazaar e così via), considerano le informazioni che essi mantengono come un insieme di file, con le relative modifiche fatte ai file, nel tempo, come illustrato in Figura 1-4.
+La principale differenza tra Git e gli altri VCS (inclusi Subversion e compagni), è come Git considera i suoi dati. Concettualmente la maggior parte degli altri sistemi salvano l'informazione come una lista di modifiche ai file. Questi sistemi (CVS, Subversion, Perforce, Bazaar e così via), considerano le informazioni che mantengono come un insieme di file, con le relative modifiche fatte ai file nel tempo, come illustrato in Figura 1-4.
 
 Insert 18333fig0104.png 
 Figura 1-4. Gli altri sistemi tendono ad immagazzinare i dati come cambiamenti alla versione base di ogni file.
 
-Git non considera i dati in questo modo né li immagazzina in questo modo. Invece, Git considera i propri dati più come una serie di istantanee (snapshot) di un mini filesystem.  Ogni volta che si fa un commit, o si salva lo stato del proprio progetto in Git, esso fondamentalmente fa un'immagine di tutti i file in quel momento, salvando un riferimento allo snapshot. Per essere efficiente, se alcuni file non sono cambiati, Git non li immagazzina nuovamente — semplicemente crea un collegamento agli stessi file, già immagazzinati, della versione precedente. Git considera i propri dati più come in Figura 1-5.
+Git non considera i dati né li registra in questo modo. Git considera i propri dati più come una serie di istantanee (_snapshot_) di un mini filesystem.  Ogni volta che committi, o salvi lo stato del tuo progetto in Git, fondamentalmente lui fa un'immagine di tutti i file in quel momento, salvando un riferimento allo _snapshot_. Per essere efficiente, se alcuni file non sono cambiati, Git non li risalva, ma crea semplicemente un collegamento al file precedente già salvato. Git considera i propri dati più come in Figura 1-5.
 
 Insert 18333fig0105.png 
 Figura 1-5.  Git immagazzina i dati come snapshot del progetto nel tempo.
 
-Questa è una distinzione importante tra Git e gli altri VCS. Git riconsidera tutti gli aspetti del controllo di versione mentre la maggior parte degli altri sistemi copiano dalle precedenti generazioni. Questo fa di Git più un qualche cosa di simile ad un mini filesystem con alcuni incredibili e potenti strumenti costruiti su di esso, invece che un semplice VCS. Esploreremo alcuni benefici che potrai avere immaginando i tuoi dati in questo modo quando vedremo le ramificazioni con Git nel Capitolo 3.
+Questa è una distinzione importante tra Git e pressocché tutti gli altri VCS. Git riconsidera quasi tutti gli aspetti del controllo di versione che la maggior parte degli altri sistemi ha copiato dalle generazioni precedenti. Questo rende Git più simile a un mini filesystem con a dispoizione strumenti incredibilmente potenti che un semplice VCS. Esploreremo alcuni benefici che ottieni pensando in questo modo ai tuoi dati vedremo le ramificazioni (i _branch_) in Git nel Capitolo 3.
 
 ### Quasi Tutte le Operazioni Sono Locali ###
 

From 9435a5f7753756aa5fa2d1d95474cf37ebe5c124 Mon Sep 17 00:00:00 2001
From: rinopo <rino@setenv.net>
Date: Wed, 5 Feb 2014 21:53:32 +0900
Subject: [PATCH 199/690] [ja] Remove unnecessary translator's note

A public key is public by nature. No need to worry about sending it over email.
---
 ja/04-git-server/01-chapter4.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ja/04-git-server/01-chapter4.markdown b/ja/04-git-server/01-chapter4.markdown
index 08a0f12d7..3eedd344b 100644
--- a/ja/04-git-server/01-chapter4.markdown
+++ b/ja/04-git-server/01-chapter4.markdown
@@ -186,7 +186,7 @@ Git サーバーを立ち上げるには、既存のリポジトリをエクス
 
 まず、鍵の保存先 (`.ssh/id_rsa`) を指定し、それからパスフレーズを二回入力するよう求められます。鍵を使うときにパスフレーズを入力したくない場合は、パスフレーズを空のままにしておきます。
 
-さて、次に各ユーザーは自分の公開鍵をあなた (あるいは Git サーバーの管理者である誰か) に送らなければなりません (ここでは、すでに公開鍵認証を使用するように SSH サーバーが設定済みであると仮定します)。公開鍵を送るには、`.pub` ファイルの中身をコピーしてメールで送ります (訳注: メールなんかで送っていいの? とツッコミたいところだ……)。公開鍵は、このようなファイルになります。
+さて、次に各ユーザーは自分の公開鍵をあなた (あるいは Git サーバーの管理者である誰か) に送らなければなりません (ここでは、すでに公開鍵認証を使用するように SSH サーバーが設定済みであると仮定します)。公開鍵を送るには、`.pub` ファイルの中身をコピーしてメールで送ります。公開鍵は、このようなファイルになります。
 
 	$ cat ~/.ssh/id_rsa.pub
 	ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAklOUpkDHrfHY17SbrmTIpNLTGK9Tjom/BWDSU

From a5e4c7d6c5c5188a3ee5160f2a624cb14ad2f763 Mon Sep 17 00:00:00 2001
From: Cor <git@cpt1.demon.nl>
Date: Wed, 5 Feb 2014 15:11:31 +0100
Subject: [PATCH 200/690] [nl] Retranslate chapter08. Remove Babelfishes and
 clarify text.

---
 nl/08-git-and-other-scms/01-chapter8.markdown | 198 +++++++++---------
 1 file changed, 101 insertions(+), 97 deletions(-)

diff --git a/nl/08-git-and-other-scms/01-chapter8.markdown b/nl/08-git-and-other-scms/01-chapter8.markdown
index 17549bcc7..ab319ad42 100644
--- a/nl/08-git-and-other-scms/01-chapter8.markdown
+++ b/nl/08-git-and-other-scms/01-chapter8.markdown
@@ -1,33 +1,33 @@
 # Git en andere systemen #
 
-Het is geen perfecte wereld. Meestal kun je niet meteen ieder project waar je mee in aanraking komt omzetten naar Git. Soms zit je vast op een project dat een ander VCS gebruikte, en vaak is dat systeem Subversion. In het eerste gedeelte van dit hoofdstuk zul je leren over `git svn`, het bidirectionele Subversion poort tool in Git.
+Het is geen perfecte wereld. Meestal kun je niet meteen elk project waar je mee in aanraking komt omzetten naar Git. Soms zit je vast op een project dat een ander VCS gebruikt, en vaak is dat systeem Subversion. In het eerste gedeelte van dit hoofdstuk zul je leren over `git svn`, het bidirectionele Subversion poort tool van Git.
 
-Op een bepaald punt zul je je bestaande project willen omzetten naar Git. Het tweede gedeelte van dit hoofdstuk beschrijft hoe je je project naar Git kunt migreren: eerst uit Subversion, dan vanuit Perforce, en als laatste via een eigen import script voor een niet standaard import geval.
+Op een gegeven moment zal je een bestaande project willen omzetten naar Git. Het tweede gedeelte van dit hoofdstuk beschrijft hoe je projecten naar Git kunt migreren: eerst uit Subversion, dan vanuit Perforce, en als laatste via een eigen import script voor een niet standaard import geval.
 
 ## Git en Subversion ##
 
-Op het moment maken het merendeel van open source ontwikkelprojecten en een groot aantal bedrijfsprojecten gebruik van Subversion om hun broncode te beheren. Het is het meest populaire open source VCS en bestaat al bijna tien jaar. Het lijkt in veel manieren op CVS, wat daarvoor de grootste speler was in de code-beheer wereld.
+Op het moment maakt het merendeel van open source ontwikkelprojecten en een groot aantal bedrijfsprojecten gebruik van Subversion om hun broncode te beheren. Het is het populairste open source VCS en bestaat al bijna tien jaar. Het lijkt ook in veel aspecten op CVS, wat daarvoor de grootste speler was in de code-beheer wereld.
 
-Een van de beste eigenschappen van Git is een bidirectionele brug naar Subversion genaamd `git svn`. Dit tool staat je toe om Git als een volwaardige gebruiker van een Subversion server te gebruiken, zodat je alle lokale eigenschappen van Git kunt gebruiken en daarna naar een Subversion server kunt pushen alsof je Subversion lokaal gebruikt. Dit betekent dat je lokaal kunt branchen en mergen, het staging gebied gebruiken, kunt rebasen en cherry-picken enzovoorts, terwijl je medewerkers verder kunnen werken op hun duistere en ouderwetse manieren. Het is een goede manier om Git in de bedrijfsomgeving binnen te sluipen en je mede-ontwikkelaars te helpen efficiënter te worden terwijl je lobbiet om de infrastructuur veranderd te krijgen zodat Git volledig gesupport wordt. De Subversion brug is de poort drug naar de DCVS wereld.
+Een van de beste features van Git is een bidirectionele brug naar Subversion genaamd `git svn`. Dit tool staat je toe om Git als een volwaardige client van een Subversion server te gebruiken, zodat je alle lokale eigenschappen van Git kunt gebruiken en daarna naar een Subversion server kunt pushen alsof je Subversion lokaal gebruikt. Dit houdt in dat je lokaal kunt branchen en mergen, het staging gebied gebruiken, kunt rebasen en cherry-picken enzovoorts, terwijl je medewerkers verder werken met hun duistere en ouderwetse middelen. Het is een goede manier om Git in de bedrijfsomgeving binnen te smokkelen en je mede-ontwikkelaars te helpen efficiënter te worden terwijl jij lobbiet om de infrastructuur te veranderen om Git volledig gesupport te krijgen. De Subversion brug is het overbruggings medicijn naar de DCVS wereld.
 
 ### git svn ###
 
 Het basiscommando in Git voor alle Subversion brugcommando's is `git svn`. Je laat dit aan alles vooraf gaan. Je hebt best een aantal commando's nodig, dus je zult de meeste leren terwijl we door een aantal werkwijzen lopen.
 
-Het is belangrijk om te zien dat terwijl je `git svn` gebruikt, je aan het communiceren bent met Subversion, wat een systeem is dat veel minder uitgekiend is dat Git. Alhoewel je eenvoudig lokaal kunt branchen en mergen, is het over het algemeen het beste om je geschiedenis zo lineair als mogelijk te houden door je werk te rebasen en te vermijden dingen te doen zoals simultaan communiceren met een Git remote repository.
+Het is belangrijk om op te merken dat terwijl je `git svn` gebruikt je aan het communiceren bent met Subversion, wat een systeem is dat veel minder vergevorderd is dan Git. Alhoewel jij eenvoudig lokaal kunt branchen en mergen, is het over het algemeen het beste om je geschiedenis zo lineair als mogelijk te houden door je werk te rebasen en te vermijden dingen te doen zoals simultaan communiceren met een Git remote repository.
 
-Herschrijf je geschiedenis niet om daarna nogmaals te pushen, en ga niet tegelijkertijd een parallel Git repository ernaast gebruiken om met mede Git ontwikkelaars samen te werken. Subversion kan slechts één lineaire geschiedenis hebben, en het in de war brengen is heel eenvoudig. Als je met een team aan het werk bent en sommigen maken gebruik van Subversion en anderen van Git, zorg dan dat iedereen de SVN server gebruikt om samen te werken – het maakt je leven een stuk eenvoudiger.
+Herschrijf je geschiedenis niet om daarna nogmaals te pushen, en ga niet Git repository ernaast gebruiken om tegelijkertijd met mede Git ontwikkelaars samen te werken. Subversion kan slechts één lineaire geschiedenis hebben, en het is heel eenvoudig om het in de war brengen. Als je met een team aan het werk bent en sommigen maken gebruik van Subversion en anderen van Git, zorg dan dat iedereen de SVN server gebruikt om samen te werken; het maakt je leven een stuk eenvoudiger.
 
 ### Instellen ###
 
-Om deze functionaliteit te demonstreren heb je een typisch SVN repository nodig waarop je schrijftoegang hebt. Als je deze voorbeelden wilt kopiëren, zul je een schrijfbare kopie moeten maken van mijn test repository. Om dat eenvoudig te kunnen doen, kun je een tool gebruiken genaamd `svnsync` dat bij de meer recente versies van Subversion geleverd wordt – het zou minstens bij versie 1.4 moeten zitten. Voor deze tests heb ik een nieuw Subversion repository op Google code gemaakt wat een gedeeltelijke kopie is van het `protobuf` project, wat een tool is dat gestructureerde data voor netwerk transmissie codeert.
+Om deze functionaliteit te demonstreren heb je een normale SVN repository nodig waarop je schrijftoegang hebt. Als je deze voorbeelden wilt kopiëren, zul je een schrijfbare kopie moeten maken van mijn test repository. Om dat eenvoudig te kunnen doen, kun je een tool genaamd `svnsync` gebruiken dat bij de meer recente versies van Subversion geleverd wordt; het zou minstens bij versie 1.4 moeten zitten. Voor deze tests heb ik een nieuw Subversion repository op Google code gemaakt wat een gedeeltelijke kopie is van het `protobuf` project, wat een tool is dat gestructureerde data voor netwerk transmissie encodeert.
 
-Om het te volgen zul je eerst een nieuw lokaal Subversion repository moeten maken:
+Om het te volgen zal je eerst een nieuw lokaal Subversion repository moeten maken:
 
 	$ mkdir /tmp/test-svn
 	$ svnadmin create /tmp/test-svn
 
-Daarna sta je alle gebruikers toe om revprops te wijzigen – de makkelijke manier is om een pre-revprop-change script toe te voegen dat altijd met 0 afsluit:
+Daarna sta je alle gebruikers toe om revprops te wijzigen; de makkelijke manier is om een pre-revprop-change script toe te voegen dat altijd met 0 afsluit:
 
 	$ cat /tmp/test-svn/hooks/pre-revprop-change
 	#!/bin/sh
@@ -38,7 +38,7 @@ Je kunt dit project nu syncen naar je lokale machine door `svnsync init` aan te
 
 	$ svnsync init file:///tmp/test-svn http://progit-example.googlecode.com/svn/
 
-Dit stelt de eigenschappen in om de sync uit te voeren. Je kunt de code dan klonen door dit uit te voeren
+Dit stelt de eigenschappen in om de sync uit te voeren. Je kunt de code daarna klonen door dit uit te voeren
 
 	$ svnsync sync file:///tmp/test-svn
 	Committed revision 1.
@@ -48,11 +48,11 @@ Dit stelt de eigenschappen in om de sync uit te voeren. Je kunt de code dan klon
 	Committed revision 3.
 	...
 
-Alhoewel deze operatie maar een paar minuten in beslag neemt, zal het kopiëren van het originele repository naar een ander remote repository in plaat van een lokale meer dan een uur duren, terwijl er minder dan 100 commits in zitten. Subversion moet één revisie per keer klonen en dan terug pushen in een ander repository – het is belachelijk inefficiënt, maar het is de enige makkelijke manier om dit te doen.
+Alhoewel deze operatie maar een paar minuten in beslag neemt, zal het kopiëren van het originele repository naar een ander remote repository in plaats van een lokale meer dan een uur duren, zelfs al zitten er maar minder dan 100 commits in. Subversion moet één revisie per keer klonen en dan terug pushen in een ander repository. Het is belachelijk inefficiënt, maar het is de enige makkelijke manier om dit te doen.
 
 ### Beginnen ###
 
-Nu dat je een Subversion repository hebt met schrijftoegang, kun je door een typische werkwijze gaan. Je begint met het `git svn clone` commando, wat een volledig Subversion repository in een lokaal Git repository kloont. Onthoud dat als je van een echt beheerd Subversion repository importeert, je de `file:///tmp/test-svn` hier moet vervangen door de URL van je Subversion repository:
+Nu je een Subversion repository hebt met schrijftoegang, kun je door een typische werkwijze gaan. Je begint met het `git svn clone` commando, wat een volledig Subversion repository in een lokaal Git repository kloont. Onthoud dat als je van een echt beheerd Subversion repository importeert, je de `file:///tmp/test-svn` moet vervangen door de URL van jouw Subversion repository:
 
 	$ git svn clone file:///tmp/test-svn -T trunk -b branches -t tags
 	Initialized empty Git repository in /Users/schacon/projects/testsvnsync/svn/.git/
@@ -70,13 +70,13 @@ Nu dat je een Subversion repository hebt met schrijftoegang, kun je door een typ
 	Checked out HEAD:
 	 file:///tmp/test-svn/branches/my-calc-branch r76
 
-Dit voert het equivalent uit van twee commando's – `git svn init` gevolgd door `git svn fetch` – op de URL die je aanlevert. Het kan een tijdje duren. Het testproject heeft slechts 75 commits en de hoeveelheid code is niet zo groot, dus het neemt maar een paar minuten in beslag. Maar, Git moet iedere versie uitchecken, één voor één, en ze individueel committen. Voor een project met honderdduizenden commits kan dit letterlijk uren of zelfs dagen duren om af te ronden.
+Dit voert het equivalent uit van twee commando's: `git svn init` gevolgd door `git svn fetch`, op de URL die je aan hebt gegeven. Het kan een tijdje duren. Het testproject heeft slechts 75 commits en de hoeveelheid code is niet zo groot, dus het neemt maar een paar minuten in beslag. Maar Git moet iedere versie uitchecken, één voor één, en ze individueel committen. Voor een project met honderdduizenden commits kan dit letterlijk uren of zelfs dagen duren om af te ronden.
 
-Het `-T trunk -b branches -t tags` gedeelte verteld Git dat dit Subversion repository de basale branch en tag conventie volgt. Als je je trunk, branches of tags anders noemt, kun je deze opties veranderen. Omdat dit zo gewoon is, kun je dit hele gedeelte vervangen door `-s`, wat standaard indeling betekend en al die opties impliceert. Het volgende commando is gelijkwaardig:
+Het `-T trunk -b branches -t tags` gedeelte vertelt Git dat binnen deze Subversion repository de basale branch en tag conventie gevolgd wordt. Als je trunk, branches of tags anders noemt, kun je deze opties aanpassen. Omdat dit zo gewoon is, kun je dit hele gedeelte vervangen door `-s`, wat standaard indeling betekent en al die opties impliceert. Het volgende commando is gelijkwaardig:
 
 	$ git svn clone file:///tmp/test-svn -s
 
-Op dit punt zou je een geldig Git repository moeten hebben, dat je branches en tags geïmporteerd heeft:
+Nu zou je een geldig Git repository moeten hebben, dat je branches en tags geïmporteerd heeft:
 
 	$ git branch -a
 	* master
@@ -87,7 +87,7 @@ Op dit punt zou je een geldig Git repository moeten hebben, dat je branches en t
 	  tags/release-2.0.2rc1
 	  trunk
 
-Het is belangrijk om te zien hoe dit tool je remote references een andere naamruimte toebedeeld. Als je een normaal Git repository kloont, krijg je alle branches op die remote server lokaal beschikbaar in de vorm van `origin/[branch]` – volgens de naamruimte van de remote. Maar, `git svn` gaat er vanuit dan je niet meerdere remotes hebt en bewaard al zijn referentie punten om de remote server zonder naamruimte. Je kunt het Git loodgieters commando `show-ref` gebruiken om naar al je volledige referentie namen te kijken:
+Het is belangrijk om te zien dat dit tool je remote references een andere naamruimte heeft toebedeeld. Als je normaal een Git repository kloont, krijg je alle branches op die remote server lokaal beschikbaar in de vorm van `origin/[branch]`, waarbij de naamruimte de naam van de remote gebruikt. Maar, `git svn` gaat er vanuit dat je niet meerdere remotes hebt en bewaart alle referentie naar punten op de remote server zonder naamruimte. Je kunt het Git plumbing commando `show-ref` gebruiken om al je volledige referentie namen te zien:
 
 	$ git show-ref
 	1cbd4904d9982f386d87f88fce1c24ad7c0f0471 refs/heads/master
@@ -98,7 +98,7 @@ Het is belangrijk om te zien hoe dit tool je remote references een andere naamru
 	1c4cb508144c513ff1214c3488abe66dcb92916f refs/remotes/tags/release-2.0.2rc1
 	1cbd4904d9982f386d87f88fce1c24ad7c0f0471 refs/remotes/trunk
 
-Een normaal Git repository ziet er meer zo uit:
+Een normale Git repository ziet er meer zo uit:
 
 	$ git show-ref
 	83e38c7a0af325a9722f2fdc56b10188806d83a1 refs/heads/master
@@ -106,19 +106,19 @@ Een normaal Git repository ziet er meer zo uit:
 	0a30dd3b0c795b80212ae723640d4e5d48cabdff refs/remotes/origin/master
 	25812380387fdd55f916652be4881c6f11600d6f refs/remotes/origin/testing
 
-Je kunt twee remote servers hebben: een genaamd `gitserver` met een master branch; en een andere genaamd `origin` met twee branches, `master` en `testing`.
+Hier zijn er twee remote servers: een genaamd `gitserver` met een `master` branch, en een andere genaamd `origin` met twee branches, `master` en `testing`.
 
-Zie hoe in het voorbeeld van geïmporteerde remote referenties van `git svn`, de tags toegevoegd zijn als remote branches, niet als echte Git tags. Je Subversion import ziet eruit alsof het een remote heeft dat tags heet waaronder branches zitten.
+Zie hoe in het voorbeeld van met `git svn` geïmporteerde remote referenties de tags toegevoegd zijn als remote branches, niet als echte Git tags. De Subversion import ziet eruit alsof het een remote heeft dat tags heet waaronder branches zitten.
 
 ### Terug naar Subversion committen ###
 
-Nu dat je een werkend repository hebt, kun je wat werken aan het project en je commits stroomopwaarts pushen, waarbij je Git effectief als een SVN gebruiker toepast. Als je een van de bestanden aanpast en het commit, heb je een commit dat lokaal in Git bestaat, die niet op de Subversion server bestaat:
+Nu dat je een werkende repository hebt, kun je wat werken aan het project en je commits stroomopwaarts pushen, waarbij je Git effectief als een SVN client gebruikt. Als je een van de bestanden aanpast en het commit, heb je een lokale commit in Git, deze bestaat niet op de Subversion server:
 
 	$ git commit -am 'Adding git-svn instructions to the README'
 	[master 97031e5] Adding git-svn instructions to the README
 	 1 files changed, 1 insertions(+), 1 deletions(-)
 
-Vervolgens moet je je verandering stroomopwaarts pushen. Zie hoe dit de manier veranderd waarop je met Subversion werkt  – je kunt een paar commits offline doen en ze dan ineens naar de Subversion server pushen. Om naar een Subversion server te pushen, voer je het `git svn dcommit` commando uit:
+Vervolgens moet je de verandering stroomopwaarts pushen. Zie hoe dit de manier verandert waarop je met Subversion werkt: je kunt een paar commits offline doen en ze dan in één blok naar de Subversion server pushen. Om naar een Subversion server te pushen, voer je het `git svn dcommit` commando uit:
 
 	$ git svn dcommit
 	Committing to file:///tmp/test-svn/trunk ...
@@ -129,7 +129,7 @@ Vervolgens moet je je verandering stroomopwaarts pushen. Zie hoe dit de manier v
 	No changes between current HEAD and refs/remotes/trunk
 	Resetting to the latest refs/remotes/trunk
 
-Dit neemt alle commits die je gedaan hebt bovenop de Subversion server code, doet voor elk een Subversion commit, en herschrijft je lokale Git commit zodat het een unieke identificatie heeft. Dit is belangrijk omdat het betekend dan alle SHA-1 checksums voor je commits veranderen. Deels is het voor de reden dat het werken met Git-gebaseerde remote versies van je projecten tegelijk met een Subversion server geen goed idee is. Als je kijkt naar de laatste commit, kun je het nieuwe `git-svn-id` zien dat is toegevoegd:
+Dit neemt alle commits die je gedaan hebt op de Subversion server code, doet voor elk een Subversion commit, en herschrijft je lokale Git commit zodat het een unieke identificatie heeft. Dit is belangrijk omdat het betekent dat alle SHA-1 checksums voor je commits gaan veranderen. Dit is een van de redenen dat het werken met Git-gebaseerde remote versies van je projecten in parallel met een Subversion server geen goed idee is. Als je kijkt naar de laatste commit, kun je het nieuwe `git-svn-id` zien dat is toegevoegd:
 
 	$ git log -1
 	commit 938b1a547c2cc92033b74d32030e86468294a5c8
@@ -140,11 +140,11 @@ Dit neemt alle commits die je gedaan hebt bovenop de Subversion server code, doe
 
 	    git-svn-id: file:///tmp/test-svn/trunk@79 4c93b258-373f-11de-be05-5f7a86268029
 
-Zie dat de SHA checksum die origineel begon met `97031e5` toen je committe, nu begint met `938b1a5`. Als je wilt pushen naar zowel een Git server als een Subversion server, moet je eerst naar de Subversion server pushen (`dcommit`), omdat die actie je commit data veranderd.
+Merk op dat de SHA checksum die origineel begon met `97031e5` toen je committe, nu begint met `938b1a5`. Als je wilt pushen naar zowel een Git server als een Subversion server, moet je eerst naar de Subversion server pushen (`dcommit`) omdat die actie je commit data verandert.
 
-### Nieuwe veranderingen pullen ###
+### Nieuwe wijzigingen pullen ###
 
-Als je met andere developers samenwerkt, dan zal op een bepaald punt een van jullie willen pushen en de ander zal een conflicterende wijziging willen pushen. Die wijziging zal worden geweigerd totdat je hun werk merged. In `git svn` ziet het er zo uit:
+Als je met andere developers samenwerkt, dan zal op een bepaald moment één van jullie willen pushen en een ander zal wijziging willen pushen die conflicteert. Die wijziging zal worden geweigerd totdat je hun werk gemerged hebt. In `git svn` ziet het er zo uit:
 
 	$ git svn dcommit
 	Committing to file:///tmp/test-svn/trunk ...
@@ -152,7 +152,7 @@ Als je met andere developers samenwerkt, dan zal op een bepaald punt een van jul
 	out-of-date: resource out of date; try updating at /Users/schacon/libexec/git-\
 	core/git-svn line 482
 
-Om deze situatie op te lossen, kun je `git svn rebase` uitvoeren, wat alle wijzigingen op de server die je nog niet hebt pulled, en al het werk dat je hebt bovenop wat op de server staat rebased:
+Om deze situatie op te lossen moet je `git svn rebase` uitvoeren wat alle wijzigingen op de server die je nog niet hebt pulled, en daarna al het werk dat je hebt bovenop wat op de server staat rebased:
 
 	$ git svn rebase
 	       M      README.txt
@@ -160,7 +160,7 @@ Om deze situatie op te lossen, kun je `git svn rebase` uitvoeren, wat alle wijzi
 	First, rewinding head to replay your work on top of it...
 	Applying: first user change
 
-Nu dat al jouw werk bovenop hetgeen wat op de Subversion server staat gebracht is, kun je succesvol `dcommit` doen:
+Nu is al jouw werk bovenop hetgeen wat op de Subversion server staat gebracht, en kan je een succesvolle `dcommit` doen:
 
 	$ git svn dcommit
 	Committing to file:///tmp/test-svn/trunk ...
@@ -171,7 +171,7 @@ Nu dat al jouw werk bovenop hetgeen wat op de Subversion server staat gebracht i
 	No changes between current HEAD and refs/remotes/trunk
 	Resetting to the latest refs/remotes/trunk
 
-Het is belangrijk te onthouden dat `git svn` je dit alleen laat doen als de wijzigingen conflicteren, in tegenstelling tot Git dat je vereist om eerst al het stroomopwaartse werk dat je nog niet lokaal hebt te mergen voordat je kunt pushen. Als iemand anders een verandering naar een bestand pusht en daarna push jij een verandering op een ander bestand, dan zal je `dcommit` prima werken:
+Het is belangrijk te onthouden dat in tegenstelling tot Git, die van je verlangt dat je werk van stroomopwaarts wat je nog niet lokaal hebt staan merged voordat je mag pushen, `git svn` je dit alleen laat doen als de wijzigingen conflicteren. Als iemand anders een verandering naar een bestand pushed en daarna push jij een verandering op een ander bestand, dan zal het `commit` commando prima werken:
 
 	$ git svn dcommit
 	Committing to file:///tmp/test-svn/trunk ...
@@ -188,9 +188,9 @@ Het is belangrijk te onthouden dat `git svn` je dit alleen laat doen als de wijz
 	First, rewinding head to replay your work on top of it...
 	Nothing to do.
 
-Dit is belangrijk om te onthouden, want de uitkomst is een project status die niet bestond op een van jullie computers toen je pushte. Als de veranderingen incompatibel zijn, maar niet conflicteren, dan kun je problemen krijgen die lastig te diagnosticeren zijn. Het is anders dan een Git server gebruiken – in Git kun je de status volledig op je gebruikerssysteem testen voordat je het publiceert, waarbij in SVN je nooit zeker kunt zijn dat de statussen vlak voor je commit en na je commit gelijk zijn.
+Dit is belangrijk om te onthouden, want de uitkomst is een project status die niet bestond op één van jullie beider computers toen je pushte. Als de veranderingen incompatibel zijn maar niet conflicteren, dan kun je problemen krijgen die lastig te diagnosticeren zijn. Het is anders dan een Git server gebruiken; in Git kun je de status volledig op je gebruikerssysteem testen voordat je het publiceert, terwijl je met SVN je nooit zeker kunt zijn dat de statussen vlak voor je commit en na je commit gelijk zijn.
 
-Je zou dit commando ook moeten uitvoeren om wijzigingen te pullen van de Subversion server, zelfs als je niet klaar bent om te committen. Je kunt `git svn fetch` uitvoeren om de nieuwe data te pakken, maar `git svn rebase` doet de fetch en vernieuwd je lokale commits.
+Je moet dit commando ook moeten uitvoeren om wijzigingen te pullen van de Subversion server, ook als je zelf nog niet klaar bent om te committen. Je kunt `git svn fetch` uitvoeren om de nieuwe data te pakken, maar `git svn rebase` doet de fetch en vernieuwt je lokale commits.
 
 	$ git svn rebase
 	       M      generate_descriptor_proto.sh
@@ -198,13 +198,13 @@ Je zou dit commando ook moeten uitvoeren om wijzigingen te pullen van de Subvers
 	First, rewinding head to replay your work on top of it...
 	Fast-forwarded master to refs/remotes/trunk.
 
-Eens in de zoveel tijd `git svn rebase` uitvoeren zorgt er voor dat je code altijd up to date is. Je moet er wel zeker van zijn dat je werkmap schoon is als je dit uitvoert. Als je lokale wijzigingen hebt, moet je of eerst je werk stashen, of tijdelijk committen voordat je `git svn rebase` uitvoert – anders zal het commando stoppen als het ziet dat de rebase zal resulteren in een mergeconflict.
+Regelmatig `git svn rebase` uitvoeren zorgt er voor dat je code altijd up to date is. Je moet er wel zeker van zijn dat je werkdirectory schoon is voor je dit uitvoert. Als je lokale wijzigingen hebt, moet je of eerst je werk stashen, of tijdelijk committen voordat je `git svn rebase` uitvoert; anders zal het commando stoppen als het ziet dat de rebase zal resulteren in een mergeconflict.
 
 ### Git branch problemen ###
 
-Als je je op je gemak voelt met een Git manier van werken, zul je waarschijnlijk onderwerp branches gaan maken, er werk op doen, en ze dan inmergen. Als je naar een Subversion server pusht via git svn, wil je misschien je werk iedere keer in een enkele branch rebasen in plaats van de branches samen mergen. De reden om rebasen te prefereren is dat Subversion een lineaire geschiedenis heeft, en niet omgaat met merges op de manier zoals Git dat doet, dus git svn volgt alleen de eerste ouder op het moment dat de snapshots naar Subversion commits omgezet worden.
+Als je op je gemak bent met een Git werkwijze, zul je waarschijnlijk topic branches gaan maken, er werk op doen en ze dan mergen. Als je naar een Subversion server pusht via git svn, zou je kunnen overwegen je werk iedere keer op een enkele branch rebasen in plaats van de branches samen mergen. De reden om rebasen te prefereren is dat Subversion een lineaire geschiedenis heeft, en niet met merges omgaat op de manier zoals Git dat doet, dus git svn volgt alleen de eerste ouder op het moment dat de snapshots naar Subversion commits omgezet worden.
 
-Stel dat je geschiedenis er zoals volgt uitziet: je hebt een `experiment` branch gemaakt, twee commits gedaan, en ze dan terug in `master` gemerged. Als je dan `dcommit` zie je output zoals dit:
+Stel dat je geschiedenis er zoals volgt uitziet: je hebt een `experiment` branch gemaakt, twee commits gedaan en ze dan terug in `master` gemerged. Als je dan `dcommit` zie je output zoals dit:
 
 	$ git svn dcommit
 	Committing to file:///tmp/test-svn/trunk ...
@@ -225,9 +225,9 @@ Stel dat je geschiedenis er zoals volgt uitziet: je hebt een `experiment` branch
 	No changes between current HEAD and refs/remotes/trunk
 	Resetting to the latest refs/remotes/trunk
 
-Het uitvoeren van `dcommit` op een branch met gemergede historie werkt prima, behalve wanneer je naar je Git project historie kijkt, het geen van beide commits die je op de `experiment` branch gedaan hebt herschreven heeft – in plaats daarvan verschijnen al die wijzigingen in de SVN versie van de enkele merge commit.
+Het uitvoeren van `dcommit` op een branch met gemergede historie werkt prima, maar wanneer je naar je Git project historie kijkt zie je dat geen van beide commits die je op de `experiment` branch gedaan hebt herschreven is. In plaats daarvan verschijnen al die wijzigingen in de SVN versie van de enkele merge commit.
 
-Als iemand anders dat werk kloont, is alles wat ze zien de merge commit met al het werk erin gesquashed; ze zien niet de commit data met waar het vandaan kwam of wanneer het was gecommit.
+Als iemand anders dat werk kloont, is alles wat ze zien de merge commit met al het werk erin gesquashed; ze zien niet de commit gegevens met waar het vandaan kwam of wanneer het was gecommit.
 
 ### Subversion branchen ###
 
@@ -246,27 +246,27 @@ Om een nieuwe branch te maken in Subversion, voer je `git svn branch [branchnaam
 	Successfully followed parent
 	r89 = 9b6fe0b90c5c9adf9165f700897518dbc54a7cbf (opera)
 
-Dit doet het equivalent van het `svn copy trunk branches/opera` commando in Subversion en werkt op de Subversion server. Het is belangrijk om te zien dat het je niet uitchecked in die branch; als je op dit punt commit, dan zal die commit in de `trunk` op de server gaan, niet in `opera`.
+Dit doet hetzelfde als het `svn copy trunk branches/opera` commando in Subversion en wordt op de Subversion server uitegevoerd. Het is belangrijk om op te merken dat het je niet uitchecked in die branch; als je op dit punt commit, dan zal die commit naar de `trunk` op de server gaan en niet in `opera`.
 
 ### Actieve branches wisselen ###
 
-Git zoekt uit naar welke branch je de commits heen gaan door te kijken naar de punt van ieder van je Subversion branches in je geschiedenis – je zou er slechts één moeten hebben, en het zou de laatste moeten zijn met een `git-svn-id` in je huidige branch historie.
+Git zoekt uit naar welke branch de dcommits horen te gaan door te kijken naar de punt van elk van je Subversion branches in je geschiedenis; je zou er slechts één moeten hebben, en het zou de laatste moeten zijn met een `git-svn-id` in je huidige branch historie.
 
-Als je tegelijk wilt werken op meer dan één branch, dan kun je lokale branches instellen om de `dcommit` naar specifieke Subversion branches te doen door ze te starten bij de geïmporteerde Subversion commit voor die branch. Als je een `opera` branch wilt hebben waar je apart op kunt werken, kun je dit uitvoeren
+Als je wilt werken op meer dan één branch, dan kun je lokale branches instellen om de `dcommit` naar specifieke Subversion branches te doen door ze te starten bij de geïmporteerde Subversion commit voor die branch. Als je een `opera` branch wilt hebben waar je apart op kunt werken, kun je dit uitvoeren
 
 	$ git branch opera remotes/opera
 
-Als je je `opera` branch nu in `trunk` (jouw `master` branch) wilt mergen, kun je dit doen met een normale `git merge`. Maar je moet een beschrijvend commit bericht meegeven (via `-m`), of de merge zal "Merge branch opera" bevatten in plaats van iets bruikbaars.
+Als je de `opera` branch nu in `trunk` (jouw `master` branch) wilt mergen, kan je dit doen met een normale `git merge`. Maar je moet een beschrijvend commit bericht meegeven (via `-m`), omdat de merge anders "Merge branch opera" zal bevatten in plaats van iets bruikbaars.
 
-Onthoud dat, alhoewel je `git merge` gebruikt voor deze operatie, en de merge waarschijnlijk veel makkelijker gaat dan het in Subversion zou gaan (omdat Git automatisch de merge basis voor je zal detecteren), dit geen normale Git merge commit is. Je moet deze data terug pushen naar een Subversion server die geen commit aan kan die meer dan één ouder volgt; dus, nadat je het omhoog gepusht hebt, zal het eruit zien als een enkele commit waarbij al het werk van een andere branch erin gesquashed zit als een enkele commit. Nadat je een branch in een andere gemerged hebt, kun je niet eenvoudig terug gaan en op die branch verder werken, zoals je dat normaal kunt in Git. Het `dcommit` commando dat je uitvoert, wist alle informatie die kan vertellen welke branch erin gemerged was, dus opvolgende merge-basis berekeningen zullen fout gaan – de `dcommit` zal je `git merge` resultaat eruit laten zien alsof je `git merge --squash` uitgevoerd hebt. Helaas is er geen manier om deze situatie te vermijden – Subversion kan deze informatie niet opslaan, dus je zult altijd gelimiteerd zijn door zijn beperkingen zolang als je het als server gebruikt. Om problemen te vermijden, zou je de lokale branch moeten verwijderen (in dit geval `opera`), nadat je hem in trunk gemerged hebt.
+Onthoud dat alhoewel je `git merge` gebruikt voor deze operatie, en de merge waarschijnlijk veel makkelijker gaat dan het in Subversion zou gaan (omdat Git automatisch de merge basis voor je zal detecteren), dit geen normale Git merge commit is. Je moet deze data terug pushen naar een Subversion server die geen commit aan kan die meer dan één ouder volgt; dus nadat je het gepusht hebt, zal het eruit zien als een enkele commit waarbij al het werk van een andere branch erin gesquashed zit onder één enkele commit. Nadat je een branch in een andere gemerged hebt, kan je niet eenvoudig terug gaan en op die branch verder werken zoals je dat normaal in Git zou doen. Het `dcommit` commando dat je uitvoert wist alle informatie die kan vertellen welke branch erin gemerged was, dus opvolgende merge-basis berekeningen zullen fout gaan. De `dcommit` zal je `git merge` resultaat eruit laten zien alsof je `git merge --squash` uitgevoerd hebt. Helaas is er geen manier om deze situatie te vermijden: Subversion kan deze informatie niet opslaan, dus je zult altijd gelimiteerd zijn door zijn beperkingen zolang als je het als server gebruikt. Om problemen te vermijden zou je de lokale branch moeten verwijderen (in dit geval `opera`), nadat je hem in trunk gemerged hebt.
 
 ### Subversion commando's ###
 
-De `git svn` toolset levert een aantal commando's mee om de overgang naar Git te vergemakkelijken, door sommige functionaliteit te leveren, die vergelijkbaar is met wat je in Subversion had. Hier zijn een paar commando's die je geven wat Subversion voorheen deed.
+De `git svn` toolset levert een aantal commando's om de overgang naar Git te vergemakkelijken, door sommige functionaliteit te leveren die vergelijkbaar is met wat je in Subversion had. Hier zijn een paar commando's die je geven wat Subversion voorheen deed.
 
 #### SVN achtige historie ####
 
-Als je gewend bent aan Subversion en je wil je historie in SVN achtige output zien, kun je `git svn log` uitvoeren om je commit historie in SVN formattering te zien:
+Als je gewend bent aan Subversion en je wil de historie in SVN achtige output zien, kun je `git svn log` uitvoeren om je commit historie in SVN formattering te zien:
 
 	$ git svn log
 	------------------------------------------------------------------------
@@ -284,7 +284,7 @@ Als je gewend bent aan Subversion en je wil je historie in SVN achtige output zi
 
 	updated the changelog
 
-Je moet twee belangrijke zaken weten over `git svn log`. Ten eerste, het werkt offline en niet zoals het echte `svn log` commando wat de Subversion server vraagt om de data. Ten tweede, het toont je alleen commits die zijn gecommit naar de Subversion server. Lokale Git commits, die je nog niet ge-dcommit hebt worden niet getoond; een ook commits die mensen gedaan hebben in de tussentijd naar de Subversion server. Het is meer zoiets als de laatst bekende status van de commits op de Subversion server.
+Je moet twee belangrijke zaken onthouden over `git svn log`. Ten eerste: het werkt offline en niet zoals het echte `svn log` commando dat de Subversion server vraagt om de data. Ten tweede: het toont je alleen commits die zijn gecommit naar de Subversion server. Lokale Git commits, die je nog niet ge-dcommit hebt worden niet getoond; een ook commits die mensen gedaan hebben in de tussentijd naar de Subversion server. Het is meer de laatst bekende status van de commits op de Subversion server.
 
 #### SVN annotatie ####
 
@@ -304,7 +304,7 @@ Zoals het `git svn log` commando het `svn log` commando offline simuleert, kun j
 	 2   temporal Buffer compiler (protoc) execute the following:
 	 2   temporal
 
-Nogmaals, het toont geen commits die je lokaal in Git gedaan hebt, of die in de tussentijd naar Subversion gepusht zijn.
+Nogmaals, het toont geen commits die je lokaal in Git gedaan hebt of die in de tussentijd naar Subversion gepusht zijn.
 
 #### SVN server informatie ####
 
@@ -326,9 +326,9 @@ Dit is vergelijkbaar met `blame` en `log` in dat het offline draait en alleen up
 
 #### Negeren wat Subversion negeert ####
 
-Als je een Subversion repository kloont, die ergens `svn:ignore` eigenschappen gezet heeft, dan zul je waarschijnlijk overeenkomende `.gitignore` bestanden in willen stellen zo dat je niet per ongeluk bestanden commit die je niet had moeten committen. `git svn` heeft twee commando's die met dit probleem helpen. De eerste is `git svn create-ignore`, wat automatisch `.gitignore` bestanden voor je genereert zodat je volgende commit ze niet kan bevatten.
+Als je een Subversion repository kloont die ergens `svn:ignore` eigenschappen bevat, dan zul je waarschijnlijk overeenkomstige `.gitignore` bestanden in willen richten zodat je niet per ongeluk bestanden commit die niet hadden gemogen. `git svn` heeft twee commando's die met dit probleem helpen. De eerste is `git svn create-ignore` wat automatisch `.gitignore` bestanden voor je genereert zodat je het bij je volgende commit kan gebruiken.
 
-Het tweede commando is `git svn show-ignore`, want op stdout de regels afdrukt die je in een `.gitignore` bestand moet stoppen zodat je de output in het exclude bestand van je project kunt stoppen:
+Het tweede commando is `git svn show-ignore` wat op stdout de regels afdrukt die je in een `.gitignore` bestand moet stoppen zodat je de output in het exclude bestand van je project kunt stoppen:
 
 	$ git svn show-ignore > .git/info/exclude
 
@@ -336,43 +336,43 @@ Op die manier vervuil je het project niet met `.gitignore` bestanden. Dit is een
 
 ### Git-Svn samenvatting ###
 
-De `git svn` tools zijn bruikbaar als je voorlopig vast zit aan een Subversion server, of op een andere manier in een ontwikkelomgeving zit waar het draaien van een Subversion server noodzakelijk is. Je moet het echter beschouwen als een kreupele Git, of anders loop je tegen problemen in de vertaling aan, die jou en je medewerkers in verwarring kunnen brengen. Om uit de problemen te blijven moet je deze regels volgen:
+De `git svn` tools zijn nuttig als je voorlopig vast zit aan een Subversion server, of op een andere manier in een ontwikkelomgeving zit waar het draaien van een Subversion server noodzakelijk is. Je moet het echter beschouwen als een kreupele Git, anders loop je tegen problemen in de vertaling aan, die jou en je medewerkers in verwarring kunnen brengen. Om uit de problemen te blijven moet je deze regels volgen:
 
-* Houdt een lineaire Git historie aan, die geen merge commits bevat die gedaan zijn door `git merge`. Rebase al het werk dat je buiten je hoofd branch doet er terug in; niet erin mergen.
-* Geen aparte Git server instellen en daar op samenwerken. Je kunt er een hebben om klonen voor nieuwe developers te versnellen, maar push er niets terug in dat geen `git-svn-id` vermelding heeft. Je zou zelfs een `pre-receive` haak kunnen toevoegen, die ieder commit bericht na kijkt op een `git-svn-id` en pushes weigert die commits zonder bevatten.
+* Houdt een lineaire Git historie aan die geen merge commits bevat die gedaan zijn door `git merge`. Rebase al het werk dat je buiten je hoofd branch doet daarop; niet erin mergen.
+* Geen aparte Git server inrichten en daar op samenwerken. Je kunt er een hebben om het maken van kloons voor nieuwe developers te versnellen, maar push er niets terug in dat geen `git-svn-id` vermelding heeft. Je zou zelfs een `pre-receive` hook kunnen toevoegen, die elk commit bericht controleert op een `git-svn-id` en pushes weigert die commits zonder bevatten.
 
-Als je deze regels volgt, dan kan werken met een Subversion server meer dragelijk zijn. Maar, als het mogelijk is om over te gaan naar een echte Git server, dan kan dat je team een hoop meer toevoegen.
+Als je deze regels volgt dan kan werken met een Subversion server dragelijker zijn. Maar als het mogelijk is om over te gaan naar een echte Git server, dan kan dat je team een hoop meer profijt geven.
 
 ## Naar Git migreren ##
 
-Als je een bestaande hoeveelheid broncode in een ander VCS hebt, maar je hebt besloten om Git te gaan gebruiken dan moet je je project op een of andere manier migreren. Deze sectie behandelt een aantal importeerders voor veel voorkomende systemen, die bij Git zitten en demonstreert daarna hoe je je eigen importeerder kunt ontwikkelen.
+Als je een bestaande hoeveelheid broncode in een ander VCS hebt, en je hebt besloten om Git te gaan gebruiken dan moet je het project op een of andere manier migreren. Deze paragraaf behandelt een aantal importeerders die bij Git worden geleverd voor veel voorkomende systemen, en demonstreert daarna hoe je je eigen importeerder kunt ontwikkelen.
 
 ### Importeren ###
 
-Je zult leren hoe je data uit twee van de grotere professioneel gebruikte SCM systemen kunt importeren – Subversion en Perforce –  omdat zij op dit moment de grootste hoeveelheid gebruikers hebben waarvan ik op dit moment hoor dat ze willen wisselen, en omdat er tools van hoge kwaliteit voor beide systemen meegeleverd worden met Git.
+Je zult leren hoe je data uit twee van de grotere professioneel gebruikte SCM systemen kunt importeren, Subversion en Perforce. Dit omdat zij op dit moment de grootste gebruikersgroep hebben waarvan ik op dit moment hoor dat ze willen wisselen, en omdat er tools van hoge kwaliteit voor beide systemen meegeleverd worden met Git.
 
 ### Subversion ###
 
-Als je de vorige sectie over het gebruik van `git svn` leest, kun je die instructies eenvoudig gebruiken om een `git svn clone` te doen op een repository; daarna stop je met het gebruik van de Subversion server, pusht naar de nieuwe Git server, en ga die gebruiken. Als je de historie wil hebben, kun je dat zo snel als dat je van de server kunt pullen voor elkaar krijgen (wat een tijdje kan duren).
+Als je de vorige paragraaf over het gebruik van `git svn` heb gelezen, kun je die instructies eenvoudig gebruiken om een `git svn clone` te doen op een repository. Daarna stop je met het gebruik van de Subversion server, pushed naar de nieuwe Git server, en gaat die gebruiken. Als je de historie wilt hebben kan dat zo snel als dat je van de server kunt pullen voor elkaar krijgen (dat echter even duren).
 
-Maar, de import is niet perfect; en omdat het zo lang zal duren, kun je het maar beter goed doen. Het eerste probleem is informatie over de auteurs. In Subversion heeft iedere persoon die commit een gebruikersaccount op het systeem, wat wordt opgenomen in de commit informatie. De voorbeelden in de voorgaande sectie toen `schacon` op bepaalde plaatsen zoals de `blame` output en bij `git svn log`. Als je dit beter wil transleren naar Git auteur data, dan heb je een translatie nodig van de Subversion gebruikers naar de Git auteurs. Maak een bestand genaamd `users.txt`, die deze translatie in dit formaat heeft:
+Maar de import is niet perfect; en omdat het zo lang zal duren kan je het maar beter goed doen. Het eerste probleem is informatie over de auteurs. In Subversion heeft iedere persoon die commit een gebruikersaccount op het systeem, wat wordt opgenomen in de commit informatie. De voorbeelden in de voorgaande paragraaf laten `schacon` zien op bepaalde plaatsen zoals de `blame` output en bij `git svn log`. Als je dit naar betere Git auteur data wilt vertalen, dan heb je een vertaling nodig van de Subversion gebruikers naar de Git auteurs. Maak een bestand genaamd `users.txt` die deze vertaling in dit formaat heeft:
 
 	schacon = Scott Chacon <schacon@geemail.com>
 	selse = Someo Nelse <selse@geemail.com>
 
-Om een lijst te krijgen van de auteurnamen, die SVN gebruikt kun je dit uitvoeren:
+Om een lijst te krijgen van de auteurnamen die SVN gebruikt kun je dit uitvoeren:
 
 	$ svn log ^/ --xml | grep -P "^<author" | sort -u | \
 	      perl -pe 's/<author>(.*?)<\/author>/$1 = /' > users.txt
 
-Daarmee krijg je de log output in XML formaat – je kunt hierin zoeken naar de auteurs, een lijst met unieke vermeldingen creëren en dan de XML eruit halen. (Dit werkt natuurlijk alleen op een machine waarop `grep`, `sort` en `Perl` geïnstalleerd is.) Daarna stuur je die output naar je users.txt bestand zodat je de gelijkwaardige Git gebruiker data naast iedere vermelding kunt zetten.
+Daarmee krijg je de log output in XML formaat, je kunt hierin zoeken naar de auteurs, eenn lijst met unieke vermeldingen creëren en dan de XML eruit verwijderen. (Dit werkt uiteraard alleen op een machine waarop `grep`, `sort` en `Perl` geïnstalleerd is.) Daarna stuur je die output naar je users.txt bestand zodat je de overeenkomstige Git gebruiker data naast iedere vermelding kunt zetten.
 
-Je kunt dit bestand meegeven aan `git svn` om het te helpen de auteur data accurater te transleren. Je kunt `git svn` ook vertellen dat het niet de metadata moet toevoegen die Subversion normaal importeert, door de `--no-metadata` optie mee te geven aan het `clone` of `init` commando. Dit laat je `import` commando er zo uit zien:
+Je kunt dit bestand meegeven aan `git svn` om het te helpen de auteur data juist te vertalen. Je kunt `git svn` ook vertellen dat het niet de metadata moet toevoegen die Subversion normaal importeert, door de `--no-metadata` optie mee te geven aan het `clone` of `init` commando. Dit laat je `import` commando er zo uit zien:
 
 	$ git-svn clone http://my-project.googlecode.com/svn/ \
 	      --authors-file=users.txt --no-metadata -s my_project
 
-Nu zou je een betere Subversion import moeten hebben in je `my_project` map. In plaats van commits die er zo uit zien
+Nu zou je een betere Subversion import moeten hebben in je `my_project` directory. In plaats van commits die er zo uit zien
 
 	commit 37efa680e8473b615de980fa935944215428a35a
 	Author: schacon <schacon@4c93b258-373f-11de-be05-5f7a86268029>
@@ -392,34 +392,38 @@ zien ze er zo uit:
 
 Niet alleen het auteur veld ziet er beter uit, maar het `git-svn-id` is ook niet meer aanwezig.
 
-Je moet nog een beetje `post-import` opruiming doen. Je moet nog de vreemde referenties die `git svn` ingesteld heeft opruimen, bijvoorbeeld. Als eerste verplaats je de tags zodat het echte tags worden, in plaats van vreemde remote branches, en dan verplaats je de rest van de branches zodat ze lokaal worden.
+Je moet nog een beetje `post-import` schoonmaak doen. Je moet nog de vreemde referenties die `git svn` ingesteld heeft opruimen bijvoorbeeld. Als eerste verplaats je de tags zodat het echte tags worden in plaats van vreemde remote branches, en dan verplaats je de rest van de branches zodat ze lokaal worden.
 
-Om de tags goede Git tags te laten worden, voer dit uit
+Om de tags goede Git tags te laten worden, voer je dit uit
 
-	$ cp -Rf .git/refs/remotes/tags/* .git/refs/tags/
-	$ rm -Rf .git/refs/remotes/tags
+	$ git for-each-ref refs/remotes/tags | cut -d / -f 4- | grep -v @ | while read tagname; do git tag "$tagname" "tags/$tagname"; git branch -r -d "tags/$tagname"; done
 
-Dit neemt de referenties die remote branches waren en met `tag/` begonnen, en maakt er echte (lichtgewicht) tags van.
+Dit neemt de referenties die remote branches waren en met `tag/` beginnen, en maakt er echte (lichtgewicht) tags van.
 
 Daarna verplaats je de rest van de referenties onder `refs/remotes` zodat het lokale branches worden:
 
-	$ cp -Rf .git/refs/remotes/* .git/refs/heads/
-	$ rm -Rf .git/refs/remotes
+	$ git for-each-ref refs/remotes | cut -d / -f 3- | grep -v @ | while read branchname; do git branch "$branchname" "refs/remotes/$branchname"; git branch -r -d "$branchname"; done
 
-Nu zijn alle oude branches echte Git branches, en alle oude tags echte Git tags. Het laatste ding dan je moet doen is je nieuwe Git server als een remote toevoegen en er naar pushen. Omdat je al jouw branches en tags omhoog wil laten gaan, kun je dit uitvoeren:
+Nu zijn alle oude branches echte Git branches, en alle oude tags echte Git tags. Het laatste wat je moet doen is je nieuwe Git server als een remote toevoegen en er naar pushen. Hier is een voorbeeld van hoe je de server als een remote toevoegt:
+
+	$ git remote add origin git@my-git-server:myrepository.git
+
+
+Omdat je al jouw branches en tags naar de server wilt laten gaan, kun je dit uitvoeren:
 
 	$ git push origin --all
+	$ git push origin --tags
 
-Al je branches en tags zouden op je Git server moeten staan in een fijne schone import.
+Al je branches en tags zouden op je Git server moeten staan in een mooie schone import.
 
 ### Perforce ###
 
-Het volgende systeem waar je naar gaat kijken om vanuit te importeren is Perforce. Er zit een Perforce importeerder bij de Git distributie, maar alleen in het `contrib` gedeelte van de broncode – het is niet standaard beschikbaar zoals `git svn`. Om het uit te voeren, moet je de Git broncode pakken, die je van git.kernel.org kunt downloaden:
+Het volgende systeem waar je naar gaat kijken om vanuit te importeren is Perforce. Er zit ook een Perforce importeerder bij de Git distributie. Als je een Git versie van voor 1.7.11 hebt, zit deze alleen in het `contrib` gedeelte van de broncode. In dat geval, moet je de Git broncode ophalen, die je van git.kernel.org kunt downloaden:
 
 	$ git clone git://git.kernel.org/pub/scm/git/git.git
 	$ cd git/contrib/fast-import
 
-In deze `fast-import` map, zou je een uitvoerbaar Python script genaamd `git-p4` moeten vinden. Je moet Python en het `p4` tool geïnstalleerd hebben op je machine om deze import te laten werken. Als voorbeeld ga je het Jam project van de Perforce Public Depot importeren. Om je gebruiker in te stellen, moet je de P$PORT omgevingsvariabele laten wijzen naar het Perforce depot:
+In deze `fast-import` directory, zou je een uitvoerbaar Python script genaamd `git-p4` moeten vinden. Je moet Python en het `p4` tool geïnstalleerd hebben op je machine om deze import te laten werken. Als voorbeeld ga je het Jam project van de Perforce Public Depot importeren. Om je client in te stellen, moet je de P$PORT omgevingsvariabele laten wijzen naar het Perforce depot:
 
 	$ export P4PORT=public.perforce.com:1666
 
@@ -431,7 +435,7 @@ Voer het `git-p4-clone` commando uit om het Jam project van de Perforce server t
 	Import destination: refs/remotes/p4/master
 	Importing revision 4409 (100%)
 
-Als je naar de `/opt/p4import` map gaat en `git log` uitvoert, kun je je geïmporteerde werk zien:
+Als je naar de `/opt/p4import` directory gaat en `git log` uitvoert, kun je je geïmporteerde werk zien:
 
 	$ git log -2
 	commit 1fd4ec126171790efd2db83548b85b1bbbc07dc2
@@ -453,7 +457,7 @@ Als je naar de `/opt/p4import` map gaat en `git log` uitvoert, kun je je geïmpo
 
 	    [git-p4: depot-paths = "//public/jam/src/": change = 3108]
 
-Je kunt de `git-p4` identificator in iedere commit zien. Het is fijn om die identificator daar te bewaren, voor het geval je later naar het Perforce wijzigingsnummer moet refereren. Maar, als je de identificator wilt verwijderen, is nu het geschikte moment om dat te doen – voordat je begint met werken op de nieuwe repository. Je kunt `git filter-branch` gebruiken om de identificatie tekst en masse te verwijderen:
+Je kunt de `git-p4` identificator in iedere commit zien. Het is prima om die identificator daar te bewaren, voor het geval je later naar het Perforce wijzigingsnummer moet refereren. Maar, als je de identificator wilt verwijderen is nu het geschikte moment om dat te doen, voordat je begint met werken op de nieuwe repository. Je kunt `git filter-branch` gebruiken om de identificatie tekst en masse te verwijderen:
 
 	$ git filter-branch --msg-filter '
 	        sed -e "/^\[git-p4:/d"
@@ -461,7 +465,7 @@ Je kunt de `git-p4` identificator in iedere commit zien. Het is fijn om die iden
 	Rewrite 1fd4ec126171790efd2db83548b85b1bbbc07dc2 (123/123)
 	Ref 'refs/heads/master' was rewritten
 
-Als je `git log` uitvoert, kun je zien dat alle SHA-1 checksums voor de commits gewijzigd zijn, maar de `git-p4` teksten staan niet langer in de commit berichten:
+Als je `git log` uitvoert, zal je zien dat alle SHA-1 checksums voor de commits gewijzigd zijn, maar de `git-p4` teksten staan niet langer in de commit berichten:
 
 	$ git log -2
 	commit 10a16d60cffca14d454a15c6164378f4082bc5b0
@@ -479,13 +483,13 @@ Als je `git log` uitvoert, kun je zien dat alle SHA-1 checksums voor de commits
 
 	    Update derived jamgram.c
 
-Je import is nu klaar om naar je nieuwe Git server gepusht te worden.
+Je import is nu klaar om naar je nieuwe Git server gepushed te worden.
 
 ### Een eigen importeerder ###
 
-Als het door jou gebruikte systeem niet Subversion of Perforce is, zou je online voor een importeerder moeten zoeken – er zijn importeerders van goede kwaliteit beschikbaar voor CVS, Clear Case, Visual Source Safe, en zelfs een map met archieven. Als geen van deze tools voor jou geschikt is, je hebt een zeldzamer tool, of je hebt om een andere reden een eigen import proces nodig, dan zou je `git fast-import` moeten gebruiken. Dit commando leest eenvoudige instructies van stdin om specifieke Git data te schrijven. Het is veel eenvoudiger om op deze manier Git objecten te maken, dan de rauwe Git commando's uit te voeren, of om te proberen de rauwe objecten te schrijven (zie hoofdstuk 9 voor meer informatie). Op deze manier kun je een import script schrijven dat de noodzakelijke data uit het systeem leest dat je aan het importeren bent en rechttoe rechtaan instructies op stdout afdrukt. Je kunt dit programma dan uitvoeren en de output door `git fast-import` sluizen.
+Als het door jou gebruikte systeem niet Subversion of Perforce is, zou je online voor een importeerder moeten zoeken. Er zijn importeerders van goede kwaliteit beschikbaar voor CVS, Clear Case, Visual Source Safe, en zelfs een directory met archieven. Als geen van deze tools voor jou geschikt is, je hebt een zeldzame tool of je hebt om een andere reden een eigen import proces nodig, dan zou je `git fast-import` moeten gebruiken. Dit commando leest eenvoudige instructies van stdin om specifieke Git data te schrijven. Het is veel eenvoudiger om op deze manier Git objecten te maken dan de kale Git commando's uit te voeren, of om te proberen de kale objecten te schrijven (zie hoofdstuk 9 voor meer informatie). Op deze manier kun je een import script schrijven dat de noodzakelijke data uit het systeem leest dat je aan het importeren bent en rechtstreeks instructies op stdout afdrukt. Je kunt dit programma dan uitvoeren en de output door `git fast-import` sluizen (pipen).
 
-Voor een snelle demonstratie zul je een eenvoudige importeerder schrijven. Stel dat je in current werkt, waarbij je je project eens in de zoveel tijd backup'ed door de map te kopiëren naar een backup map die gelabeld is met de tijd `back_YYYY_MM_DD`, en je wil dit in Git importeren. Je mappenstructuur ziet er zo uit:
+Voor een korte demonstratie ga je een eenvoudige importeerder schrijven. Stel dat je in current werkt, waarbij je eens in de zoveel tijd een backup maakt door de projectdirectory te kopiëren naar een backup directory die gelabeld is met de tijd `back_YYYY_MM_DD`, en je wil dit in Git importeren. Je directory-structuur ziet er zo uit:
 
 	$ ls /opt/import_from
 	back_2009_01_02
@@ -494,11 +498,11 @@ Voor een snelle demonstratie zul je een eenvoudige importeerder schrijven. Stel
 	back_2009_02_03
 	current
 
-Om naar een Git map te importeren, moet je bekijken hoe Git zijn data opslaat. Je kunt je misschien herinneren dat Git in fundament een gelinkte lijst is met commit objecten die naar een snapshot van inhoud wijzen. Het enige dat je hoeft te doen, is `fast-import` vertellen wat de inhoud snapshots zijn, welke commit data er naar wijst en de volgorde waarin ze moeten staan. Je strategie bestaat uit het doorlopen van de snapshots en commits te creëren met de inhoud van iedere map, waarbij je iedere commit terug linkt met de vorige.
+Om naar een Git directory te importeren, moet je naslaan hoe Git zijn data opslaat. Je kunt je misschien herinneren dat Git eigenlijk een gelinkte lijst is met commit objecten die naar een snapshot van inhoud wijzen. Het enige dat je hoeft te doen, is `fast-import` vertellen wat de inhoud snapshots zijn, welke commit data er naar wijst en de volgorde waarin ze moeten staan. Je strategie zal bestaan uit het doorlopen van de snapshots en commits te creëren met de inhoud van iedere directory, waarbij je iedere commit terug linkt met de vorige.
 
-Zoals je dat gedaan hebt in de "Een Voorbeeld van Git Afgedwongen Beleid" sectie van Hoofdstuk 7, gaan we dit in Ruby schrijven, omdat ik daar over het algemeen mee werk en het is relatief eenvoudig te lezen. Je kunt dit voorbeeld vrij eenvoudig schrijven in alles waar je bekend mee bent – het hoeft alleen de juiste informatie naar stdout te schrijven. En dat betekent dat als je op Windows werkt, je erg voorzichtig moet zijn om geen carriage returns te introduceren aan het einde van je regels – git fast-import is erg kieskeurig in de manier waarop hij slechts line feeds (LF) wil hebben en niet de cariage return line feeds (CRLF), die Windows gebruikt.
+Zoals je dat ook gedaan hebt in de "Een Voorbeeld van Git-Afgedwongen Beleid" paragraaf van Hoofdstuk 7 gaan we dit in Ruby schrijven, omdat ik daar over normaalgesproken mee werk en het relatief eenvoudig is te lezen. Je kunt dit voorbeeld vrij eenvoudig schrijven in alles waar je bekend mee bent, het hoeft alleen de juiste informatie naar stdout te schrijven. En dat betekent dat als je op Windows werkt je erg voorzichtig moet zijn om geen carriage returns te introduceren aan het einde van je regels. Want git fast-import is erg kieskeurig wat dat betreft: hij wil slechts line feeds (LF) hebben en niet de cariage return line feeds (CRLF) die Windows gebruikt.
 
-Om te beginnen ga je naar de doelmap en identificeer je iedere submap, waarvan elk een snapshot is dat je als commit wil importeren. Dan ga je in iedere submap en print de noodzakelijke commando's om ze te exporteren. Je basis hoofdlus ziet er zo uit:
+Om te beginnen ga je naar de doeldirectory en identificeert iedere subdirectory waarvan elk een snapshot is dat je als commit wil importeren. Dan ga je in iedere subdirectort en print de noodzakelijke commando's om ze te exporteren. Je basis hoofdlus ziet er zo uit:
 
 	last_mark = nil
 
@@ -514,11 +518,11 @@ Om te beginnen ga je naar de doelmap en identificeer je iedere submap, waarvan e
 	  end
 	end
 
-Je voert `print_export` uit binnen iedere map, wat het manifest en het merk van de vorige snapshot neemt, en het manifest en merk van deze terug geeft; op die manier kun je ze goed linken. "Mark" is de `fast-import` term voor een identificator die je aan een commit geeft; terwijl je commits maakt, geef je ze een merk die je kunt gebruiken om vanuit andere commits naar te linken. Dus, het eerste wat je moet doen in je `print_export` functie is een merk genereren van de mapnaam:
+Je voert `print_export` uit binnen iedere directory wat het manifest en het kenmerk van de vorige snapshot neemt, en het manifest en kenmerk van de huidige retourneert; op die manier kun je ze goed linken. "Mark" is de `fast-import` term voor een identificator die je aan een commit geeft; terwijl je commits maakt geef je ze een kenmerk ("Mark") die je kunt gebruiken om vanuit andere commits naar te linken. Dus, het eerste wat je moet doen in je `print_export` functie is een kenmerk genereren van de directortnaam:
 
 	mark = convert_dir_to_mark(dir)
 
-Je zult dit doen door een lijst van mappen te creëren en de index waarde als merk te gebruiken, omdat een merk een geheel getal moet zijn. Je functie ziet er zo uit:
+Je zult dit doen door een lijst van directories te maken en de index waarde als kenmerk te gebruiken omdat een kenmerk een geheel getal moet zijn. Je functie ziet er zo uit:
 
 	$marks = []
 	def convert_dir_to_mark(dir)
@@ -528,7 +532,7 @@ Je zult dit doen door een lijst van mappen te creëren en de index waarde als me
 	  ($marks.index(dir) + 1).to_s
 	end
 
-Nu dat je een geheel getal hebt als voorstelling van je commit, moet je een datum hebben voor de commit metadata. Omdat de datum is uitgedrukt in de naam van de map, zul je het daar uit moeten halen. De volgende regel in het `print_export` bestand is
+Nu dat je een geheel getal hebt als representatie van de commit, moet je een datum hebben voor de commit metadata. Omdat de datum is uitgedrukt in de naam van de directory, haal je het daar uit. De volgende regel in het `print_export` bestand is
 
 	date = convert_dir_to_date(dir)
 
@@ -544,11 +548,11 @@ waarbij `convert_dir_to_date` als volgt gedefinieerd is
 	  end
 	end
 
-Dat geeft een geheel getal terug als waarde voor de datum van iedere map. Het laatste stukje meta-informatie dat je voor iedere commit nodig hebt is de committer data, wat je in een globale variabele stopt:
+Dat geeft een geheel getal terug als waarde voor de datum van iedere directory. Het laatste stukje meta-informatie dat je voor iedere commit nodig hebt zijn de gegevens van de committer, die je in een globale variabele stopt:
 
 	$author = 'Scott Chacon <schacon@example.com>'
 
-Nu ben je klaar om te beginnen met de commit data af te drukken voor je importeerder. De initiële informatie stelt dat je een commit object definieert en op welke branch het zit, gevolgd door het merk dat je gegenereerd hebt, de committer informatie en het commit bericht, en de vorige commit, als die er is. De code ziet er zo uit:
+Nu ben je klaar om te beginnen met de commit data af te drukken voor je importeerder. De initiële informatie vraagt van je dat je een commit object definieert en op welke branch het zit, gevolgd door het kenmerk dat je gegenereerd hebt, de committer gegevens en het commit bericht en de vorige commit, als die er is. De code ziet er zo uit:
 
 	# print the import information
 	puts 'commit refs/heads/master'
@@ -557,18 +561,18 @@ Nu ben je klaar om te beginnen met de commit data af te drukken voor je importee
 	export_data('imported from ' + dir)
 	puts 'from :' + last_mark if last_mark
 
-Je stelt de tijdzone (-0700) hardgecodeerd in omdat dat eenvoudig is. Als je vanuit een ander systeem importeert, moet je de tijdzone als een compensatiewaarde specificeren.
+Je stelt de tijdzone (-0700) hardgecodeerd in omdat dat zo gemakkelijk is. Als je vanuit een ander systeem importeert, moet je de tijdzone als een compensatiewaarde (offset) specificeren.
 Het commit bericht moet uitgedrukt worden in een speciaal formaat:
 
 	data (size)\n(contents)
 
-Het formaat bestaat uit de woorddata, de grootte van de data die gelezen moet worden, een newline, en als laatste de data. Omdat je hetzelfde formaat nodig hebt om later de bestandsinhoud te specificeren, zul je een hulpfunctie creëren, `export_data`:
+Het formaat bestaat uit het woord data, de grootte van de gegevens die gelezen moeten worden, een newline en als laatste de gegevens. Omdat je hetzelfde formaat nodig hebt om later de bestandsinhoud te specificeren, zul je een hulpfunctie creëren, `export_data`:
 
 	def export_data(string)
 	  print "data #{string.size}\n#{string}"
 	end
 
-Het enige dat nog gespecificeerd moet worden is de bestandsinhoud voor ieder snapshot. Dit is makkelijk, omdat je ze allemaal in een map hebt – je kunt het `deleteall` commando afdruken, gevolgd door de inhoud van ieder bestand in de map. Git zal dan ieder snapshot op de juiste manier opslaan:
+Het enige dat nog gespecificeerd moet worden is de bestandsinhoud voor ieder snapshot. Dit is eenvoudig, omdat je ze allemaal in een directory hebt, je kunt het `deleteall` commando afdruken, gevolgd door de inhoud van ieder bestand in de directory. Git zal dan elk snapshot op de juiste manier opslaan:
 
 	puts 'deleteall'
 	Dir.glob("**/*").each do |file|
@@ -576,7 +580,7 @@ Het enige dat nog gespecificeerd moet worden is de bestandsinhoud voor ieder sna
 	  inline_data(file)
 	end
 
-Let op: Omdat veel systemen over hun revisie als veranderingen van de ene naar de andere commit denken, kan fast-import ook commando's aan waarbij bij iedere commit is gespecificeerd welke bestanden zijn toegevoegd, verwijderd, of aangepast en wat de nieuwe inhouden zijn. Je kunt de verschillen tussen snapshots berekenen en alleen deze data geven, maar om het zo te doen is complexer – je kunt net zo goed Git alle data geven en hem het uit laten zoeken. Als dit beter geschikt is voor jouw data, bekijk dan de `fast-import` man pagina voor details over hoe je jouw data op deze manier kunt aanleveren.
+Let op: Omdat veel systemen over hun revisie zien als veranderingen van de ene naar de andere commit, kan fast-import ook commando's aan waar bij iedere commit is gespecificeerd welke bestanden zijn toegevoegd, verwijderd, of aangepast en wat de nieuwe inhoud is. Je kunt de verschillen tussen snapshots berekenen en alleen deze data geven, maar om het zo te doen is complexer, Je kunt net zo goed Git alle data geven en hem het uit laten zoeken. Als dit beter geschikt is voor jouw situatie, bekijk dan de `fast-import` man pagina voor details over hoe je jouw gegevens op deze manier kunt aanleveren.
 
 Het formaat om de nieuwe bestandsinhoud te tonen of een aangepast bestand met de nieuwe inhoud te specificeren is als volgt:
 
@@ -584,7 +588,7 @@ Het formaat om de nieuwe bestandsinhoud te tonen of een aangepast bestand met de
 	data (size)
 	(file contents)
 
-Hierbij is 644 de modus (als je uitvoerbare bestanden hebt, moet je dit detecteren en in plaats daarvan 755 specificeren), en inline verteld dat je de inhoud onmiddellijk na deze regel toont. Je `inline_data` functie ziet er zo uit:
+Hierbij is 644 de modus (als je uitvoerbare bestanden hebt, moet je dit detecteren en in plaats daarvan 755 specificeren), en inline geeft aan dat je de inhoud onmiddelijk na deze regel toont. Je `inline_data` functie ziet er zo uit:
 
 	def inline_data(file, code = 'M', mode = '644')
 	  content = File.read(file)
@@ -592,17 +596,17 @@ Hierbij is 644 de modus (als je uitvoerbare bestanden hebt, moet je dit detecter
 	  export_data(content)
 	end
 
-Je hergebruikt de `export_data` data functie, die je eerder gedefinieerd hebt, omdat het hetzelfde is als de manier waarop je je commit bericht data gespecificeerd hebt.
+Je hergebruikt de `export_data` data functie die je eerder gedefinieerd hebt, omdat dezelfde manier gebruikt wordt als waarmee je de commit bericht data gespecificeerd hebt.
 
-Het laatste wat je moet doen is het huidige merk teruggeven, zodat het meegegeven kan worden aan de volgende iteratie:
+Het laatste wat je moet doen is het huidige kenmerk teruggeven, zodat het meegegeven kan worden aan de volgende iteratie:
 
 	return mark
 
-Let op: Als je op Windows werkt, moet je er zeker van zijn dat je nog één extra stap toevoegt. Zoals voorheen gemeld is, gebruikt Windows CRLF als new line karakters, terwijl git fast-import alleen LF verwacht. Om om dit probleem heen te werken en git fast-import blij te maken, moet je ruby vertellen om LF in plaats van CRLF te gebruiken:
+LET OP: Als je op Windows werkt moet je er zeker van zijn dat je nog één extra stap toevoegt. Zoals eerder gemeld is gebruikt Windows CRLF als new line karakters, terwijl git fast-import alleen LF verwacht. Om dit probleem te omzeilen en git fast-import blij te maken, moet je ruby vertellen om LF in plaats van CRLF te gebruiken:
 
 	$stdout.binmode
 
-Dat is alles. Als je dit script uitvoert, zul je inhoud krijgen die er ongeveer zo uit ziet:
+Dat is alles. Als je dit script uitvoert, zal je inhoud krijgen die er ongeveer zo uit ziet:
 
 	$ ruby import.rb /opt/import_from
 	commit refs/heads/master
@@ -627,7 +631,7 @@ Dat is alles. Als je dit script uitvoert, zul je inhoud krijgen die er ongeveer
 	new version one
 	(...)
 
-Om de importeerder uit te voeren, sluis je deze uitvoer door `git fast-import` terwijl je in de Git map staat waar je naar toe wilt importeren. Je kunt een nieuwe map aanmaken en er dan `git init` in uitvoeren als startpunt, en dan kun je je script uitvoeren:
+Om de importeerder uit te voeren, sluis je deze uitvoer door `git fast-import` terwijl je in de Git directory staat waar je naar toe wilt importeren. Je kunt een nieuwe directory aanmaken en er dan `git init` in uitvoeren als startpunt, en dan kun je het script uitvoeren:
 
 	$ git init
 	Initialized empty Git repository in /opt/import_to/.git/
@@ -656,7 +660,7 @@ Om de importeerder uit te voeren, sluis je deze uitvoer door `git fast-import` t
 	pack_report: pack_mapped              =       1356 /       1356
 	---------------------------------------------------------------------
 
-Zoals je kunt zien geeft het je een berg statistieken over wat het heeft bereikt, als het succesvol heeft kunnen afronden. In dit geval heb je in totaal 18 objecten geïmporteerd, voor 5 commits in 1 branch. Nu kun je `git log` uitvoeren en je nieuwe historie zien:
+Zoals je kunt zien geeft het je een berg statistieken over wat het heeft bereikt, als het succesvol heeft kunnen afronden. In dit geval heb je in totaal 18 objecten geïmporteerd, voor 5 commits naar 1 branch. Nu kun je `git log` uitvoeren en je nieuwe historie zien:
 
 	$ git log -2
 	commit 10bfe7d22ce15ee25b60a824c8982157ca593d41
@@ -671,7 +675,7 @@ Zoals je kunt zien geeft het je een berg statistieken over wat het heeft bereikt
 
 	    imported from back_2009_02_03
 
-Hier heb je 't – een fijne, schone Git repository. Het is belangrijk om te zien dat nog niks uitgechecked is – je hebt om te beginnen geen bestanden in je werkmap. Om ze te krijgen moet je je branch resetten tot het punt waar `master` nu is:
+Hier heb je 't, een mooie, schone Git repository. Het is belangrijk om te op te merken dat nog niks uitgechecked is, je hebt om te beginnen geen bestanden in je werkdirectory. Om ze te krijgen moet je de branch resetten tot het punt waar `master` nu is:
 
 	$ ls
 	$ git reset --hard master
@@ -679,8 +683,8 @@ Hier heb je 't – een fijne, schone Git repository. Het is belangrijk om te zie
 	$ ls
 	file.rb  lib
 
-Je kunt nog veel meer doen met het `fast-import` tool – verschillende bestandsmodi behandelen, binaire gegevens, meerdere branches en merges, tags, voortgangsindicatoren, en meer. Een aantal voorbeelden voor complexe scenario's zijn voorhanden in de `contrib/fast-import` map van de Git broncode; een van de betere is het `git-p4` script dat ik zojuist behandeld heb.
+Je kunt nog veel meer doen met het `fast-import` tool: verschillende bestandsmodi verwerken, binaire gegevens, meerdere branches en mergen, tags, voortgangsindicatoren, enzovoorts. Een aantal voorbeelden voor complexe scenario's zijn voorhanden in de `contrib/fast-import` directory van de Git broncode, een van de betere is het `git-p4` script dat ik zojuist behandeld heb.
 
 ## Samenvatting ##
 
-Je zou je op je gemak moeten voelen om Git met Subversion te gebruiken, of bijna ieder bestaand repository te importeren in een Git versie zonder gegevens te verliezen. Het volgende hoofdstuk zal het rauwe binnenwerk van Git behandelen, zodat je iedere byte in elkaar kunt zetten, als dat nodig is.
+Je zou je op je gemak moeten voelen om Git met Subversion te gebruiken, of bijna ieder bestaand repository te importeren in een Git versie zonder gegevens te verliezen. Het volgende hoofdstuk zal het ruwe binnenwerk van Git behandelen, zodat je iedere byte in elkaar kunt zetten, als dat nodig zou zijn.

From bc1f09bf839d0478b053d456cabe19232c1bdb34 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Wed, 5 Feb 2014 16:58:51 -0600
Subject: [PATCH 201/690] Reviewing "Git basics"

---
 it/01-introduction/01-chapter1.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/it/01-introduction/01-chapter1.markdown b/it/01-introduction/01-chapter1.markdown
index 87a35e12c..f8ef6e32e 100644
--- a/it/01-introduction/01-chapter1.markdown
+++ b/it/01-introduction/01-chapter1.markdown
@@ -73,7 +73,7 @@ Questa è una distinzione importante tra Git e pressocché tutti gli altri VCS.
 
 ### Quasi Tutte le Operazioni Sono Locali ###
 
-La maggior parte delle operazioni in Git, necessitano solo di file e risorse locali per operare — generalmente non occorrono informazioni da altri computer nella rete. Se eri abituato ad un CVCS, in cui la maggior parte delle operazioni erano soggette alle latenze di rete, questo aspetto di Git ti farà pensare che gli dei della velocità abbiano benedetto Git con poteri soprannaturali. Giacché l'intera storia del progetto sta qui, sul proprio disco locale, le operazioni sembrano quasi istantanee.
+La maggior parte delle operazioni in Git, necessitano solo di file e risorse locali per operare — generalmente non occorrono informazioni da altri computer della rete. Se sei abituato ad un CVCS in cui la maggior parte delle operazioni sono soggette alle latenze di rete, questo aspetto di Git ti farà pensare che gli Dei della velocità abbiano benedetto Git con poteri soprannaturali. Poiché hai l'intera storia del progetto sul tuo disco locale, molte operazioni sembrano quasi istantanee.
 
 Per esempio, per scorrere la storia di un progetto, Git non ha bisogno di connettersi al server per scaricarla e per poi visualizzarla — la legge direttamente dal database locale. Questo significa che puoi vedere la storia del progetto quasi istantaneamente. Se vuoi vedere i cambiamenti introdotti tra la versione corrente di un file e la versione di un mese fa, Git può consultare il file di un mese fa e calcolare localmente le differenze, invece di richiedere di farlo ad un server remoto o di estrarre una precedente versione del file dal server remoto, per poi farlo in locale.
 

From 0fe52504c38cd983a883966b1bd9380421df009e Mon Sep 17 00:00:00 2001
From: Yue Lin Ho <b8732003@student.nsysu.edu.tw>
Date: Fri, 7 Feb 2014 13:22:34 +0800
Subject: [PATCH 202/690] [zh-tw] Synchronize with En version

---
 zh-tw/01-introduction/01-chapter1.markdown       |  8 ++++----
 zh-tw/07-customizing-git/01-chapter7.markdown    | 12 ++++++------
 zh-tw/08-git-and-other-scms/01-chapter8.markdown | 14 ++++++++------
 zh-tw/09-git-internals/01-chapter9.markdown      |  7 +++----
 4 files changed, 21 insertions(+), 20 deletions(-)

diff --git a/zh-tw/01-introduction/01-chapter1.markdown b/zh-tw/01-introduction/01-chapter1.markdown
index bbd0e2701..2c581fec5 100644
--- a/zh-tw/01-introduction/01-chapter1.markdown
+++ b/zh-tw/01-introduction/01-chapter1.markdown
@@ -132,16 +132,16 @@ Git目錄是Git用來儲存讀者的專案的元數據及物件資料庫。 這
 	  openssl-devel zlib-devel
 
 	$ apt-get install libcurl4-gnutls-dev libexpat1-dev gettext \
-	  libz-dev
-	
+	  libz-dev libssl-dev
+
 當讀者安裝所有必要的程式庫，讀者可到Git的網站取得最新版本：
 
 	http://git-scm.com/download
 
 接著，編譯及安裝：
 
-	$ tar -zxf git-1.6.0.5.tar.gz
-	$ cd git-1.6.0.5
+	$ tar -zxf git-1.7.2.2.tar.gz
+	$ cd git-1.7.2.2
 	$ make prefix=/usr/local all
 	$ sudo make prefix=/usr/local install
 
diff --git a/zh-tw/07-customizing-git/01-chapter7.markdown b/zh-tw/07-customizing-git/01-chapter7.markdown
index 8be51aab4..4c85c396e 100644
--- a/zh-tw/07-customizing-git/01-chapter7.markdown
+++ b/zh-tw/07-customizing-git/01-chapter7.markdown
@@ -1,6 +1,5 @@
 # Git 客製化 #
 
-So far, I’ve covered the basics of how Git works and how to use it, and I’ve introduced a number of tools that Git provides to help you use it easily and efficiently. In this chapter, I’ll go through some operations that you can use to make Git operate in a more customized fashion by introducing several important configuration settings and the hooks system. With these tools, it’s easy to get Git to work exactly the way you, your company, or your group needs it to.
 到目前為止，我闡述了 Git 基本的運作機制和使用方式，介紹了 Git 提供的許多工具來幫助你簡單且有效地使用它。在本章，我將會介紹 Git 的一些重要的組態設定(configuration)和鉤子(hooks)機制以滿足自訂的要求。通過這些工具，它能夠更容易地使 Git 按照你、你的公司或團隊所需要的方式去運作。 
 
 ## Git 配置 ##
@@ -298,7 +297,6 @@ Git 預設情況下不會在推送期間檢查所有物件的一致性。Git 雖
 
 某些檔案看起來像是文字檔，但其實是看做為二進位資料。例如，在 Mac 上的 Xcode 專案含有一個以 `.pbxproj` 結尾的檔，它是由記錄設置項的 IDE 寫到磁碟的 JSON 資料集（純文字 javascript 資料類型）。雖然技術上看它是由 ASCII 字元組成的文字檔，但是你並不想這麼看它，因為它確實是一個輕量級資料庫 — 如果有兩個人改變了它，你沒辦法合併它們，diff 通常也幫不上忙，只有機器才能進行識別和操作，於是，你想把它當成二進位檔案。 
 
-To tell Git to treat all `pbxproj` files as binary data, add the following line to your `.gitattributes` file:
 讓 Git 把所有 `pbxproj` 檔當成二進位檔案，在 `.gitattributes` 文件中加上下面這行： 
 
 	*.pbxproj -crlf -diff
@@ -326,7 +324,12 @@ To tell Git to treat all `pbxproj` files as binary data, add the following line
 
 當你要看比較結果時，如果檔副檔名是 ”doc”，Git 會使用 ”word” 篩檢程式(filter)。什麼是 ”word” 篩檢程式呢？你必須設置它。下面你將設定 Git 使用 `strings` 程式，把 Word 文檔轉換成可讀的文字檔，之後再進行比較： 
 
-	$ git config diff.word.textconv strings
+	$ git config diff.word.textconv catdoc
+
+This command adds a section to your `.git/config` that looks like this:
+
+	[diff "word"]
+		textconv = catdoc
 
 現在 Git 知道了，如果它要在在兩個快照之間做比較，而其中任何一個檔檔名是以 `.doc` 結尾，它應該要對這些檔執行 ”word” 篩檢程式，也就是定義為執行 `strings` 程式。這樣就可以在比較前把 Word 檔轉換成文字檔。 
 
@@ -522,7 +525,6 @@ Git 屬性在將專案匯出歸檔(archive)時也能發揮作用。
 
 ### 合併策略 ###
 
-You can also use Git attributes to tell Git to use different merge strategies for specific files in your project. One very useful option is to tell Git to not try to merge specific files when they have conflicts, but rather to use your side of the merge over someone else’s.
 通過 Git 屬性，還能對專案中的特定檔案使用不同的合併策略。一個非常有用的選項就是，當一些特定檔案發生衝突，Git 不會嘗試合併他們，而使用你這邊的來覆蓋別人的。 
 
 如果專案的一個分支有歧義或比較特別，但你想從該分支合併，而且需要忽略其中某些檔，這樣的合併策略是有用的。例如，你有一個資料庫設置檔 database.xml，在兩個分支中他們是不同的，你想合併一個分支到另一個，而不弄亂該資料庫檔，可以設置屬性如下： 
@@ -641,7 +643,6 @@ update 腳本和 `pre-receive` 腳本十分類似，除了它會為推送者更
 
 	changed the version number
 
-A simple way to get the commit message from a commit when you have the SHA-1 value is to go to the first blank line and take everything after that. You can do so with the `sed` command on Unix systems:
 通過 SHA-1 值獲得提交內容中的提交資訊的一個簡單辦法是找到提交的第一個空白行，然後取出它之後的所有內容。可以使用 Unix 系統的 `sed` 命令來實現這個效果： 
 
 	$ git cat-file commit ca82a6 | sed '1,/^$/d'
@@ -924,7 +925,6 @@ A simple way to get the commit message from a commit when you have the SHA-1 val
 
 	git rev-list ^#{sha}^@ refs/remotes/#{remote_ref}
 
-The `SHA^@` syntax resolves to all the parents of that commit. You’re looking for any commit that is reachable from the last commit on the remote and that isn’t reachable from any parent of any of the SHAs you’re trying to push up — meaning it’s a fast-forward.
 `SHA^@` 語法解析該次提交的所有祖先。我們尋找任何一個提交，這個提交可以從遠端最後一次提交衍變獲得(reachable)，但從我們嘗試推送的任何一個提交的 SHA 值的任何一個祖先都無法衍變獲得——也就是 fast-forward 的內容。
 
 這個解決方案的缺點在於它可能會很慢而且通常是沒有必要的——只要不用 -f 來強制推送，伺服器會自動給出警告並且拒絕推送內容。然而，這是個不錯的練習，而且理論上能幫助用戶避免一個將來不得不回頭修改的衍合操作。
diff --git a/zh-tw/08-git-and-other-scms/01-chapter8.markdown b/zh-tw/08-git-and-other-scms/01-chapter8.markdown
index 32bcd7acb..150d7f5bd 100644
--- a/zh-tw/08-git-and-other-scms/01-chapter8.markdown
+++ b/zh-tw/08-git-and-other-scms/01-chapter8.markdown
@@ -144,7 +144,6 @@ Git 中所有 Subversion 橋接命令的基礎是 `git svn` 。所有的命令
 
 ### 拉取最新進展 ###
 
-If you’re working with other developers, then at some point one of you will push, and then the other one will try to push a change that conflicts. That change will be rejected until you merge in their work. In `git svn`, it looks like this:
 如果要與其他開發者協作，總有那麼一天你推送完畢之後，其他人發現他們推送自己修改的時候（與你推送的內容）產生衝突。這些修改在你合併之前將一直被拒絕。在 `git svn` 裡這種情況像這樣： 
 
 	$ git svn dcommit
@@ -397,18 +396,20 @@ Git 通過搜尋提交歷史中 Subversion 分支的頭部(tip)來決定 dcommit
 
 要把標籤變成合適的 Git 標籤，執行 
 
-	$ cp -Rf .git/refs/remotes/tags/* .git/refs/tags/
-	$ rm -Rf .git/refs/remotes/tags
+	$ git for-each-ref refs/remotes/tags | cut -d / -f 4- | grep -v @ | while read tagname; do git tag "$tagname" "tags/$tagname"; git branch -r -d "tags/$tagname"; done
 
 該命令將原本以 `tag/` 開頭的遠端分支的索引變成真正的 (lightweight) 標籤。 
 
 接下來，把 `refs/remotes` 下面剩下的索引(reference)變成本地分支： 
 
-	$ cp -Rf .git/refs/remotes/* .git/refs/heads/
-	$ rm -Rf .git/refs/remotes
+	$ git for-each-ref refs/remotes | cut -d / -f 3- | grep -v @ | while read branchname; do git branch "$branchname" "refs/remotes/$branchname"; git branch -r -d "$branchname"; done
 
 現在所有的舊分支都變成真正的 Git 分支，所有的舊標籤也變成真正的 Git 標籤。最後一項工作就是把新建的 Git 伺服器添加為遠端伺服器並且向它推送。為了讓所有的分支和標籤都得到上傳，我們使用這條命令： 
 
+	$ git remote add origin git@my-git-server:myrepository.git
+
+Because you want all your branches and tags to go up, you can now run this:
+
 	$ git push origin --all
 	$ git push origin --tags
 
@@ -559,7 +560,8 @@ Git 通過搜尋提交歷史中 Subversion 分支的頭部(tip)來決定 dcommit
 	export_data('imported from ' + dir)
 	puts 'from :' + last_mark if last_mark
 
-為了簡化，時區寫死(hardcode)為（-0700）。如果是從其他版本控制系統導入，則必須以變數的形式指明時區。提交訊息必須以特定格式給出： 
+為了簡化，時區寫死(hardcode)為（-0700）。如果是從其他版本控制系統導入，則必須以變數的形式指明時區。
+提交訊息必須以特定格式給出： 
 
 	data (size)\n(contents)
 
diff --git a/zh-tw/09-git-internals/01-chapter9.markdown b/zh-tw/09-git-internals/01-chapter9.markdown
index 1da300664..864290411 100644
--- a/zh-tw/09-git-internals/01-chapter9.markdown
+++ b/zh-tw/09-git-internals/01-chapter9.markdown
@@ -495,8 +495,7 @@ blob 物件與之前的已經不同了。這說明雖然只是往一個 400 行
 
 仍保留著的幾個物件是未被任何 commit 引用的 blob ── 在此例中是你之前創建的 “what is up, doc?” 和 “test content” 這兩個示例 blob。你從沒將他們添加至任何 commit，所以 Git 認為它們是懸而未決的，不會將它們打包進 packfile 。 
 
-The other files are your new packfile and an index. The packfile is a single file containing the contents of all the objects that were removed from your filesystem. The index is a file that contains offsets into that packfile so you can quickly seek to a specific object. What is cool is that although the objects on disk before you ran the `gc` were collectively about 12K in size, the new packfile is only 6K. You’ve halved your disk usage by packing your objects.
-剩下的檔是新創建的 packfile 以及一個索引。packfile 檔包含了剛才從檔案系統中移除的所有物件。索引檔包含了 packfile 的偏移資訊(offset)，這樣就可以快速定位任意一個指定物件。有意思的是執行 `gc` 命令前磁片上的物件大小約為 12K ，而這個新生成的 packfile 僅為 6K 大小。通過打包物件減少了一半磁片使用空間。 
+剩下的檔是新創建的 packfile 以及一個索引。packfile 檔包含了剛才從檔案系統中移除的所有物件。索引檔包含了 packfile 的偏移資訊(offset)，這樣就可以快速定位任意一個指定物件。有意思的是執行 `gc` 命令前磁片上的物件大小約為 8K ，而這個新生成的 packfile 僅為 4K 大小。通過打包物件減少了一半磁片使用空間。 
 
 Git 是如何做到這點的？Git 打包物件時，會查找命名及尺寸相近的檔，並只保存檔案不同版本之間的差異內容。可以查看一下 packfile ，觀察它是如何節省空間的。`git verify-pack` 命令用於顯示已打包的內容： 
 
@@ -529,7 +528,8 @@ Git 是如何做到這點的？Git 打包物件時，會查找命名及尺寸相
 
 ## The Refspec ##
 
-這本書讀到這裡，你已經使用過一些簡單的遠端分支到本地引用的映射方式了，這種映射可以更為複雜。假設你像這樣添加了一項遠端倉庫： 
+這本書讀到這裡，你已經使用過一些簡單的遠端分支到本地引用的映射方式了，這種映射可以更為複雜。
+假設你像這樣添加了一項遠端倉庫： 
 
 	$ git remote add origin git@github.com:schacon/simplegit-progit.git
 
@@ -547,7 +547,6 @@ Refspec 的格式是一個可選的 `+` 號，接著是 `<src>:<dst>` 的格式
 	$ git log remotes/origin/master
 	$ git log refs/remotes/origin/master
 
-They’re all equivalent, because Git expands each of them to `refs/remotes/origin/master`.
 它們的作用都是相同的，因為 Git 把它們都擴展成 `refs/remotes/origin/master`. 
 
 如果你想讓 Git 每次只拉取遠端的 `master` 分支，而不是遠端的所有分支，你可以把 fetch 這一行修改成這樣： 

From ff723976db4b0e868b8ae77cad5d896d240b8b27 Mon Sep 17 00:00:00 2001
From: Yue Lin Ho <b8732003@student.nsysu.edu.tw>
Date: Fri, 7 Feb 2014 16:15:53 +0800
Subject: [PATCH 203/690] [zh-tw] Update Chapter 2

---
 zh-tw/02-git-basics/01-chapter2.markdown | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/zh-tw/02-git-basics/01-chapter2.markdown b/zh-tw/02-git-basics/01-chapter2.markdown
index d05734c1c..adb1f177c 100644
--- a/zh-tw/02-git-basics/01-chapter2.markdown
+++ b/zh-tw/02-git-basics/01-chapter2.markdown
@@ -616,6 +616,7 @@ The lines must be formatted as follows
 
 	選項	選項的說明
 	-p	顯示每個更新與上一個的差異。
+	--word-diff	使用 word diff 格式顯示 patch 內容。
 	--stat	顯示每個更新更動的檔案的統計及摘要資訊。
 	--shortstat	僅顯示--stat提供的的訊息中關於更動、插入、刪除的文字。
 	--name-only	在更新的訊息後方顯示更動的檔案列表。
@@ -624,6 +625,7 @@ The lines must be formatted as follows
 	--relative-date	以相對於目前時間方式顯示日期（例如：“2 weeks ago”），而不是完整的日期格式。
 	--graph	以 ASCII 在 log 輸出旁邊畫出分支的分歧及合併。
 	--pretty	以其它格式顯示更新。 可用的選項包含oneline、short、full、fuller及可自訂格式的format。
+	--oneline	`--pretty=oneline --abbrev-commit` 的簡短用法。
 
 ### 限制 log 的輸出範圍 ###
 

From 518a77a1e4b45a40699bfbc6a3e76f8a98884b8d Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Fri, 7 Feb 2014 17:02:51 -0600
Subject: [PATCH 204/690] Reviewing "Git Basics"

---
 it/01-introduction/01-chapter1.markdown | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/it/01-introduction/01-chapter1.markdown b/it/01-introduction/01-chapter1.markdown
index f8ef6e32e..993e836d6 100644
--- a/it/01-introduction/01-chapter1.markdown
+++ b/it/01-introduction/01-chapter1.markdown
@@ -97,18 +97,18 @@ Questo rende l'uso di Git un piacere perché sappiamo che possiamo sperimentare
 
 ### I Tre Stati ###
 
-Ora, presta attenzione. Questa è la prima cosa da ricordare su Git se si vuole affrontare al meglio il processo di apprendimento. Git ha tre stati principali, in cui possono risiedere i file: committed, modified e staged. Committed significa che il file è immagazzinato al sicuro, nel database locale. Modified significa che il file è stato modificato, ma non è stato ancora eseguito il commit nel proprio database. Staged significa che un file modificato nella versione corrente, è stato contrassegnato per essere inserito nello snapshot, al commit successivo.
+Ora, presta attenzione. La prima cosa da ricordare sempre di Git se vuoi affrontare al meglio il processo di apprendimento. I tuoi file in Git possono essere in tre stati: _committed_ (committati), _modified_ (modificati) e _staged_ (in stage). Committato significa che il file è al sicuro nel database locale. Modificato significa che il file è stato modificato, ma non è ancora stato committato nel database. In stage significa che hai contrassegnato un file, modificato nella versione corrente, perché venga inserito nello snapshot alla prossima commit.
 
-Questo ci conduce alle tre sezioni principali di un progetto Git: la directory di Git, la directory di lavoro e l'area di stage.
+Questo ci porta alle tre sezioni principali di un progetto Git: la directory di Git, la directory di lavoro e l'area di stage.
 
 Insert 18333fig0106.png 
 Figura 1-6. Directory di lavoro, area di stage e directory di Git.
 
-La directory di Git è il luogo dove Git salva i metadati ed il database degli oggetti di un progetto. Questa è la parte più importante di Git, ed è ciò che viene copiato quando si clona un repository da un altro computer.
+La directory di Git è dove Git salva i metadati e il database degli oggetti del tuo progetto. Questa è la parte più importante di Git, ed è ciò che viene copiato quando si clona un repository da un altro computer.
 
-La directory di lavoro è un singolo checkout di una versione del progetto. Questi file sono estratti dal database compresso, nella directory di Git, e posizionati nel disco per essere usati o modificati.
+La directory di lavoro è un checkout di una versione specifica del progetto. Questi file vengono estratti dal database compresso nella directory di Git, e salvati sul disco per essere usati o modificati.
 
-L'area di stage è un semplice file, generalmente contenuto nella directory di Git, contenente le informazioni riguardanti il commit successivo. Qualche volta viene indicato come l'indice, ma sta diventando d'uso comune riferirsi ad essa, come all'area di stage (sosta, ndt).
+L'area di stage è un file, contenuto generalmente nella directory di Git, con tutte le informazioni riguardanti la tua prossima commit. A volte viene indicato anche come 'indice', ma lo standard è definirlo come 'area di stage' (area di sosta, ndt).
 
 Il flusso base di lavoro in Git, funziona come segue:
 

From ea90cfc8fedab3baa5cbc81c15f976854174a1f1 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Fri, 7 Feb 2014 17:15:53 -0600
Subject: [PATCH 205/690] [it] reviewed "Git Basics"

---
 it/01-introduction/01-chapter1.markdown | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/it/01-introduction/01-chapter1.markdown b/it/01-introduction/01-chapter1.markdown
index 993e836d6..819a1bcee 100644
--- a/it/01-introduction/01-chapter1.markdown
+++ b/it/01-introduction/01-chapter1.markdown
@@ -110,13 +110,13 @@ La directory di lavoro è un checkout di una versione specifica del progetto. Qu
 
 L'area di stage è un file, contenuto generalmente nella directory di Git, con tutte le informazioni riguardanti la tua prossima commit. A volte viene indicato anche come 'indice', ma lo standard è definirlo come 'area di stage' (area di sosta, ndt).
 
-Il flusso base di lavoro in Git, funziona come segue:
+Il flusso di lavoro (_workflow_) di base in Git funziona così:
 
-1. Modifica i file nella directory di lavoro
-2. Esegui l'operazione di stage dei file, per aggiungere i relativi snapshot all'area di stage
-3. Esegui il commit, per immagazzinare permanentemente nella directory di Git, lo snapshot relativo, una volta presi i file nell'area di stage
+1. Modifica i file nella tua directory di lavoro
+2. Fanno lo stage, aggiungendone le istantanee all'area di stage
+3. Committa, che salva i file nell'area di stage in un'istantanea (_snapshot_) permanente nella tua directory di Git.
 
-Se una versione particolare di un file è nella directory git, sarà considerata già affidata. Se il file è stato modificato, ma è stato aggiunto all'area di staging, è in sosta. E se è stato modificato da quando è stata controllato, ma non è stato messo in sosta, sarà modificato.  Nel Capitolo 2, imparerai di più su questi stati e come trarne vantaggio da essi o saltare interamente la parte di staging.
+Se una particolare versione di un file è nella directory git, viene considerata già committata. Se il file è stato modificato, ma è stato aggiunto all'area di staging, è _in stage_. E se è stato modificato da quando è stata estratto, ma non è _in stage_, è modificato.  Nel Capitolo 2, imparerai di più su questi stati e come trarne vantaggio o saltare la parte di staging.
 
 ## Installare Git ##
 

From 19689c83033fee3a70b1468995c350b8889c620d Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Fri, 7 Feb 2014 17:28:34 -0600
Subject: [PATCH 206/690] [it] Reviewed "Installing Git"

---
 it/01-introduction/01-chapter1.markdown | 28 ++++++++++++-------------
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/it/01-introduction/01-chapter1.markdown b/it/01-introduction/01-chapter1.markdown
index 819a1bcee..47f544509 100644
--- a/it/01-introduction/01-chapter1.markdown
+++ b/it/01-introduction/01-chapter1.markdown
@@ -120,13 +120,13 @@ Se una particolare versione di un file è nella directory git, viene considerata
 
 ## Installare Git ##
 
-Incominciamo ad usare un po' di Git! Per prima cosa — occorre installarlo. Puoi ottenere Git in diversi modi; i due principali sono: installarlo dai sorgenti o installarlo da un pacchetto pre-esistente per la tua piattaforma.
+Incominciamo ad usare un po' di Git! Per prima cosa devi installarlo. Puoi ottenere Git in diversi modi; i principali due sono: installarlo dai sorgenti o installarlo da un pacchetto pre-esistente per la tua piattaforma.
 
 ### Installare da Sorgenti ###
 
-Se puoi, è generalmente vantaggioso installare Git dai sorgenti, perché così puoi usare la versione più recente. Ogni versione di Git, tende ad includere utili miglioramenti all'interfaccia utente, quindi, avere l'ultima versione disponibile è spesso la scelta migliore, se hai familiarità con la compilazione dei sorgenti. Inoltre capita anche, che molte distribuzioni Linux contengano pacchetti molto vecchi; perciò, se non stai usando una distro aggiornata o dei backport, l'installazione da sorgente può essere la cosa migliore da fare.
+Se puoi, generalmente è vantaggioso installare Git dai sorgenti perché avrai la versione più recente. Ogni versione di Git tende ad includere utili miglioramenti all'interfaccia utente e avere quindi l'ultima versione disponibile è spesso la scelta migliore, se hai familiarità con la compilazione dei sorgenti. Inoltre capita anche, che molte distribuzioni Linux usino pacchetti molto vecchi; perciò, se non stai usando una distro aggiornata o dei backport, l'installazione da sorgente può essere la cosa migliore da fare.
 
-Per installare Git, hai bisogno delle seguenti librerie, da cui dipende Git: curl, zlib, openssl, expat e libiconv. Per esempio, se sei su un sistema che usa yum (come in Fedora), o apt-get (come nei sistemi Debian), puoi usare uno dei seguenti comandi per installare tutte le dipendenze:
+Per installare Git, hai bisogno delle librerie da cui dipende Git che sono: curl, zlib, openssl, expat e libiconv. Per esempio, se sei su un sistema che usa yum (come Fedora), o apt-get (come nei sistemi Debian), puoi usare uno dei seguenti comandi per installare tutte le dipendenze:
 
 	$ yum install curl-devel expat-devel gettext-devel \
 	  openssl-devel zlib-devel
@@ -140,18 +140,18 @@ Quando avrai tutte le dipendenze necessarie, puoi proseguire ed andare a recuper
 	
 Poi, compilalo ed installalo:
 
-	$ tar -zxf git-1.6.0.5.tar.gz
-	$ cd git-1.6.0.5
+	$ tar -zxf git-1.7.2.2.tar.gz
+	$ cd git-1.7.2.2
 	$ make prefix=/usr/local all
 	$ sudo make prefix=/usr/local install
 
-Dopo aver fatto questo, puoi ottenere Git da Git stesso per gli aggiornamenti:
+Dopo aver fatto questo, puoi scaricare gli aggiornamenti di Git con lo stesso Git:
 
 	$ git clone git://git.kernel.org/pub/scm/git/git.git
 	
 ### Installare su Linux ###
 
-Se vuoi installare Git su Linux, tramite una installazione da binario, generalmente, puoi farlo con lo strumento base di amministrazione-dei-pacchetti della tua distribuzione. Se sei su Fedora, puoi usare yum:
+Se vuoi installare Git su Linux, tramite una installazione da binario, generalmente puoi farlo con lo strumento base di amministrazione dei pacchetti della tua distribuzione. Se usi Fedora, puoi usare yum:
 
 	$ yum install git-core
 
@@ -161,28 +161,28 @@ O se sei su una distribuzione basata su Debian, come Ubuntu, prova apt-get:
 
 ### Installazione su Mac ###
 
-Ci sono due metodi per installare Git su Mac. Il più semplice è usare l'installatore grafico di Git, che puoi scaricare dalla pagina di Google Code (vedi Figura 1-7):
+Ci sono due metodi per installare Git su Mac. Il più semplice è usare l'installer grafico di Git, che puoi scaricare dalla pagina di Google Code (vedi Figura 1-7):
 
 	http://code.google.com/p/git-osx-installer
 
 Insert 18333fig0107.png 
-Figura 1-7. Installatore di Git per SO X.
+Figura 1-7. Installer di Git per OS X.
 
-L'altro metodo è installare Git via MacPorts (`http://www.macports.org`). Se hai MacPorts installato, installa Git con:
+L'altro metodo è installare Git con MacPorts (`http://www.macports.org`). Se hai MacPorts installato puoi farlo con:
 
 	$ sudo port install git-core +svn +doc +bash_completion +gitweb
 
-Non ti occorre aggiungere tutti i pacchetti, ma evidentemente vorrai includere +svn, nel caso tu debba usare Git con i repository di Subversion (vedi Capitolo 8).
+Non ti occorre aggiungere tutti i pacchetti extra, ma probabilmente vorrai includere +svn, nel caso tu debba usare Git con i repository di Subversion (vedi Capitolo 8).
 
 ### Installare su Windows ###
 
-Installare Git su Windows è davvero facile. Il progetto msysGit ha una delle procedure di installazione tra le più facili. Semplicemente scarica l'installatore eseguibile dalla pagina di GitHub, e lancialo:
+Installare Git su Windows è davvero facile. Il progetto msysGit ha una delle procedure di installazione più facili. Semplicemente scarica l'eseguibile dalla pagina di GitHub e lancialo:
 
 	http://msysgit.github.com/
 
-Una volta installato, hai a disposizione sia la versione da riga di comando (incluso un client SSH che sarà utile, in seguito) sia l'interfaccia grafica (GUI) standard.
+Una volta installato avrai a disposizione sia la versione da riga di comando (incluso un client SSH ti servirà in seguito) sia l'interfaccia grafica (_GUI_) standard.
 
-Nota sull'uso su Windows: dovresti usare Git con la shell msysGit fornita (stile Unix), permette di usare complesse linee di comando date in questo libro. Se hai bisogno, per qualche ragione, di usare la shell nativa di Windows / la console a linea di comando, devi usare le doppie virgolette invece delle virgolette semplici (per i parametri con che contengono spazi) e devi virgolettare i parametri che terminano con l'accento circonflesso (^) se questi sono al termine della linea, poiché esso è un simbolo di proseguimento in Windows.
+Nota sull'uso su Windows: dovresti usare Git con la shell msysGit fornita (stile Unix) perché permette di usare le complesse linee di comando di questo libro. Se hai bisogno, per qualche ragione, di usare la shell nativa di Windows / la console a linea di comando, devi usare le doppie virgolette invece delle virgolette semplici (per i parametri con che contengono spazi) e devi virgolettare i parametri che terminano con l'accento circonflesso (^) se questi sono al termine della linea, poiché in Windows è uno dei simboli di proseguimento.
 
 ## Prima Configurazione di Git ##
 

From 983851b5df5b8a72037817ca2011033b2e3464f9 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Fri, 7 Feb 2014 17:56:46 -0600
Subject: [PATCH 207/690] Reviewed "First-Time Git Setup"

---
 it/01-introduction/01-chapter1.markdown | 28 ++++++++++++-------------
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/it/01-introduction/01-chapter1.markdown b/it/01-introduction/01-chapter1.markdown
index 47f544509..e81825dab 100644
--- a/it/01-introduction/01-chapter1.markdown
+++ b/it/01-introduction/01-chapter1.markdown
@@ -186,38 +186,38 @@ Nota sull'uso su Windows: dovresti usare Git con la shell msysGit fornita (stile
 
 ## Prima Configurazione di Git ##
 
-Ora che hai Git sul tuo sistema, vorrai fare un paio di cose per personalizzare l'ambiente di Git. Ti occorre farle solo una volta; esse rimangono invariate anche dopo un aggiornamento. Comunque, puoi cambiarle, in ogni momento, eseguendo di nuovo questi comandi.
+Ora che hai Git sul tuo sistema vorrai fare un paio di cose per personalizzare l'ambiente di Git. Devi farle solo una volta: rimarrano invariate anche dopo un aggiornamento. Puoi comunque cambiarle in ogni momento, rieseguendo i comandi.
 
-Git è rilasciato con uno strumento che si chiama git config che ti permetterà di ottenere ed impostare le variabili di configurazione che controllano ogni aspetto delle operazioni e del look di Git. Queste variabili possono essere salvate in tre posti differenti:
+Git viene con uno strumento che si chiama 'git config' che ti permetterà d'impostare e conoscere le variabili di configurazione che controllano ogni aspetto di come appare Git e come opera. Queste variabili possono essere salvate in tre posti differenti:
 
-*	file `/etc/gitconfig`: Contiene i valori per ogni utente sul sistema e per tutti i loro repository. Se si passa l'opzione` --system` a `git config`, lui legge e scrive da questo specifico file. 
-*	file `~/.gitconfig`: Specifico per il tuo utente. Puoi far leggere e scrivere a Git questo file passando l'opzione `--global`. 
-*	file di configurazione nella directory git (che è `.git/config`) di ogni repository che si sta usando. Specifico per ogni singolo repository. Ogni livello sovrascrive i valori del livello precedente, così i valori in `.git/config` vincono su quelli in `/etc/gitconfig`.
+*	`/etc/gitconfig`: Contiene i valori per ogni utente sul sistema e per tutti i loro repository. Se passi l'opzione` --system` a `git config`, lui legge e scrive da questo file specifico. 
+*	`~/.gitconfig`: Specifico per il tuo utente. Puoi far leggere e scrivere a Git questo file passando l'opzione `--global`. 
+*	file di configurazione nella directory git (cioè `.git/config`) di qualsiasi repository che si stia usando. È Specifico di quel singolo repository. Ogni livello sovrascrive i valori del precedente, così che i valori in `.git/config` vincono su quelli in `/etc/gitconfig`.
 
-Sui sistemi Windows, Git cerca il file `.gitconfig` nella directory `$HOME` (`C:\Documents and Settings\$USER` per la maggior parte delle persone). Inoltre per quanto riguarda /etc/gitconfig, sarà relativo alla radice di MSys, che dipende da dove si vorrà installare Git sul sistema Windows quando si lancia l'installazione.
+Su Windows Git cerca il file `.gitconfig` nella directory `$HOME` (`%USERPROFILE%` in Windows), che per la maggior parte delle persone è `C:\Documents and Settings\$USER` o `C:\Users\$USER`, dipendendo dalla versione (`$USER` è `%USERNAME%` in Windows). Controlla comunque anche /etc/gitconfig, sebbene sia relativo alla root di MSys, che è dove hai deciso di installare Git in Windows quando si lancia l'installazione.
 
-### La Propria Identità ###
+### La tua Identità ###
 
-La prima cosa che occorrerebbe fare, quando si installa Git, è impostare il proprio nome utente e indirizzo e-mail. Ciò è importante, perché ogni commit di Git usa queste informazioni, che vengono incapsulate nei commit che si fanno:
+La prima cosa che occorrerebbe fare quando installi Git è impostare il tuo nome utente e il tuo indirizzo e-mail. Questo è importante perché ogni commit di Git usa queste informazioni che vengono incapsulate nelle tue commit:
 
 	$ git config --global user.name "John Doe"
 	$ git config --global user.email johndoe@example.com
 
-Di nuovo, passando l'opzione `--global`, occorre fare ciò solo una volta, dopo di che Git userà sempre queste informazioni, per qualsiasi operazione fatta sul sistema. Se si vuole sovrascriverle con un nome o una e-mail per progetti specifici, basta eseguire il comando senza l'opzione `--global`, quando si è in uno di quei progetti.
+Con l'opzione `--global` dovrai farlo solo una volta, dopo di che Git userà sempre queste informazioni per qualsiasi operazione fatta sul sistema. Se vuoi sovrascriverle con un nome o una e-mail diversi per progetti specifici potrai eseguire il comando senza l'opzione `--global`stando in uno di quei progetti.
 
-### Il Proprio Editor ###
+### Il tuo Editor ###
 
-Ora che è configurata la propria identità, si può configurare l'editor di testo predefinito, da usare quando Git avrà bisogno di inserire un messaggio. Per impostazione predefinita, Git usa l'editor di testo predefinito del sistema, che generalmente è Vi o Vim. Se vuoi usare un editor di testo differente, come Emacs, puoi fare come segue:
+Ora che hai configurato la tua identità, puoi configurare il tuo editor di testo predefinito, che verrà usato quando Git avrà bisogno che scriva un messaggio. Per impostazione predefinita Git usa l'editor di testo predefinito del sistema, che generalmente è Vi o Vim. Se vuoi usarne uno diverso, come Emacs, potrai eseguire:
 
 	$ git config --global core.editor emacs
 	
-### Il Proprio Diff ###
+### Il tuo Diff ###
 
-Un'altra utile opzione, che si potrebbe voler configurare, è lo strumento diff, predefinito, da usare per risolvere i conflitti di merge (fusione, ndt). Per usare vimdiff:
+Un'altra opzione utile che potresti voler configurare, è lo strumento diff predefinito, da usare per risolvere i conflitti di _merge_ (unione, ndt). Per usare vimdiff, potrai eseguire:
 
 	$ git config --global merge.tool vimdiff
 
-Git accetta kdeff3, tkdiff, meld, xxdiff, emerge, vimdiff, gvimdiff, ecmerge e opendiff, come strumenti validi di merge. E' anche possibile impostare uno strumento personalizzato; vedere il Capitolo 7, per maggiori informazioni su come farlo.
+Git accetta kdeff3, tkdiff, meld, xxdiff, emerge, vimdiff, gvimdiff, ecmerge e opendiff, come strumenti di merge validi. Puoi anche definire uno personalizzato: vedi il Capitolo 7 per maggiori informazioni su come farlo.
 
 ### Controllare le Impostazioni ###
 

From 4bd2cc09640aa08eef5e92b1b6171b3301032b3a Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Fri, 7 Feb 2014 21:36:28 -0600
Subject: [PATCH 208/690] [it] fully reviewed chapter 1

---
 it/01-introduction/01-chapter1.markdown | 22 +++++++++++-----------
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/it/01-introduction/01-chapter1.markdown b/it/01-introduction/01-chapter1.markdown
index e81825dab..2806f937b 100644
--- a/it/01-introduction/01-chapter1.markdown
+++ b/it/01-introduction/01-chapter1.markdown
@@ -219,9 +219,9 @@ Un'altra opzione utile che potresti voler configurare, è lo strumento diff pred
 
 Git accetta kdeff3, tkdiff, meld, xxdiff, emerge, vimdiff, gvimdiff, ecmerge e opendiff, come strumenti di merge validi. Puoi anche definire uno personalizzato: vedi il Capitolo 7 per maggiori informazioni su come farlo.
 
-### Controllare le Impostazioni ###
+### Controlla le tue impostazioni ###
 
-Per controllare le proprie impostazioni, si può usare il comando `git config --list`, che elenca tutte le impostazioni di Git, fatte fino a questo punto:
+Per controllare le tue impostazioni puoi usare il comando `git config --list` che elenca tutte le impostazioni attuali di Git:
 
 	$ git config --list
 	user.name=Scott Chacon
@@ -232,28 +232,28 @@ Per controllare le proprie impostazioni, si può usare il comando `git config --
 	color.diff=auto
 	...
 
-La stessa chiave può comparire più volte, perché Git legge la stessa chiave da file differenti (`/etc/gitconfig` e `~/.gitconfig`, per esempio). In questo caso, Git usa l'ultimo valore per ogni chiave unica che vede.
+Potresti vedere più volte la stessa chiave perché Git legge la stessa chiave da file differenti (`/etc/gitconfig` e `~/.gitconfig`, per esempio). In questo caso, Git usa l'ultimo valore per ogni chiave unica che trova.
 
-Per controllare quale sia il valore di una chiave, ritenuto da Git usare, `git config {key}`:
+Puoi anche controllare quale sia il valore di una chiave specifica digitando `git config {key}`:
 
 	$ git config user.name
 	Scott Chacon
 
-## Ottenere Aiuto ##
+## Ottieni aiuto ##
 
-Se dovessi avere bisogno di aiuto durante l'uso di Git, ci sono tre modi per vedere le pagine del manuale di aiuto per ogni comando di Git:
+Se dovessi avere bisogno di aiuto durante l'uso di Git, ci sono tre modi per vedere le pagine del manuale (_manpage_) per ogni comando di Git:
 
 	$ git help <verb>
 	$ git <verb> --help
 	$ man git-<verb>
 
-Per esempio, puoi avere la pagina del manuale di aiuto, per il comando config, lanciando
+Per esempio, puoi consultare la pagina del manuale per il comando config digitanto
 
 	$ git help config
 
-Questi comandi sono utili, perché puoi accedere ad essi da ogni dove, anche se sei offline.
-Se il manuale e questo libro non sono sufficienti e hai bisogno di un aiuto più diretto da una persona, puoi provare i canali `#git` o `#github`, sul server IRC di Freenode (irc.freenode.com). Questi canali sono regolarmente frequentati da centinaia di persone che conoscono molto bene Git e saranno davvero felici di aiutarti.
+Questi comandi sono utili perché puoi accedervi dappertutto, anche quando sei offline.
+Se il manuale e questo libro non fossero sufficienti e avessi bisogno dell'aiuto di una persona, puoi provare i canali `#git` o `#github` sul server IRC di Freenode (irc.freenode.com). Questi canali sono frequentati regolarmente da centinaia di persone che conoscono molto bene Git e spesso sono disponibili per dare una mano.
 
-## Riassunto ##
+## Sommario ##
 
-Dovresti avere le basi per capire cos'è Git e come è differente dai CVCS che puoi aver usato. Dovresti anche avere una versione funzionante di Git sul tuo sistema che è configurata con la tua personale identità. É ora tempo di imparare qualcosa delle basi di Git.
+Dovresti avere le basi per capire cos'è Git e com'è diverso dai CVCS che potresti aver usato. Dovresti avere già una versione funzionante di Git sul tuo sistema che è configurata con i tuoi dati. È ora tempo di imparare alcune delle basi di Git.

From ca2be767172a6bec1face662692646a5a3524430 Mon Sep 17 00:00:00 2001
From: Dan Croak <dan@thoughtbot.com>
Date: Sat, 8 Feb 2014 01:32:16 -0800
Subject: [PATCH 209/690] Use GitHub endpoint for Gitosis

Fixes:

    git clone git://eagain.net/gitosis.git
    Cloning into 'gitosis'...
    fatal: unable to connect to eagain.net:
    eagain.net[0: 192.237.217.227]: errno=Connection refused
    eagain.net[1: 2001:4800:7813:516:fa64:3a5d:ff04:7851]: errno=Network is
      unreachable
---
 az/04-git-server/01-chapter4.markdown    | 2 +-
 cs/04-git-server/01-chapter4.markdown    | 2 +-
 de/04-git-server/01-chapter4.markdown    | 2 +-
 en/04-git-server/01-chapter4.markdown    | 2 +-
 es/04-git-server/01-chapter4.markdown    | 2 +-
 es/omegat-Benzirpi.tmx                   | 4 ++--
 fr/04-git-server/01-chapter4.markdown    | 2 +-
 it/04-git-server/01-chapter4.markdown    | 2 +-
 ja/04-git-server/01-chapter4.markdown    | 2 +-
 ko/04-git-server/01-chapter4.markdown    | 2 +-
 nl/04-git-server/01-chapter4.markdown    | 2 +-
 no-nb/04-git-server/01-chapter4.markdown | 2 +-
 pl/04-git-server/01-chapter4.markdown    | 2 +-
 pt-br/04-git-server/01-chapter4.markdown | 2 +-
 ru/04-git-server/01-chapter4.markdown    | 2 +-
 zh/04-git-server/01-chapter4.markdown    | 2 +-
 16 files changed, 17 insertions(+), 17 deletions(-)

diff --git a/az/04-git-server/01-chapter4.markdown b/az/04-git-server/01-chapter4.markdown
index c631fb0f6..1e4df37b1 100644
--- a/az/04-git-server/01-chapter4.markdown
+++ b/az/04-git-server/01-chapter4.markdown
@@ -369,7 +369,7 @@ Gitosis requires some Python tools, so first you have to install the Python setu
 
 Next, you clone and install Gitosis from the project’s main site:
 
-	$ git clone git://eagain.net/gitosis.git
+	$ git clone https://github.com/tv42/gitosis.git
 	$ cd gitosis
 	$ sudo python setup.py install
 
diff --git a/cs/04-git-server/01-chapter4.markdown b/cs/04-git-server/01-chapter4.markdown
index 4f06a9e58..890884cc4 100644
--- a/cs/04-git-server/01-chapter4.markdown
+++ b/cs/04-git-server/01-chapter4.markdown
@@ -370,7 +370,7 @@ Gitosis vyžaduje některé nástroje v jazyce Python, a proto první, co musít
 
 Dále naklonujte a nainstalujte Gitosis z hlavní stránky projektu:
 
-	$ git clone git://eagain.net/gitosis.git
+	$ git clone https://github.com/tv42/gitosis.git
 	$ cd gitosis
 	$ sudo python setup.py install
 
diff --git a/de/04-git-server/01-chapter4.markdown b/de/04-git-server/01-chapter4.markdown
index 79115b17e..fc7d2b8eb 100644
--- a/de/04-git-server/01-chapter4.markdown
+++ b/de/04-git-server/01-chapter4.markdown
@@ -570,7 +570,7 @@ Gitosis setzt einige Python Werkzeuge voraus. Deshalb solltest Du zuerst das Pyt
 
 Danach klonst Du Gitosis von der offiziellen Projektseite und installierst es:
 
-	$ git clone git://eagain.net/gitosis.git
+	$ git clone https://github.com/tv42/gitosis.git
 	$ cd gitosis
 	$ sudo python setup.py install
 
diff --git a/en/04-git-server/01-chapter4.markdown b/en/04-git-server/01-chapter4.markdown
index 9f5c9a0ed..f81c12918 100644
--- a/en/04-git-server/01-chapter4.markdown
+++ b/en/04-git-server/01-chapter4.markdown
@@ -376,7 +376,7 @@ Gitosis requires some Python tools, so first you have to install the Python setu
 
 Next, you clone and install Gitosis from the project’s main site:
 
-	$ git clone git://eagain.net/gitosis.git
+	$ git clone https://github.com/tv42/gitosis.git
 	$ cd gitosis
 	$ sudo python setup.py install
 
diff --git a/es/04-git-server/01-chapter4.markdown b/es/04-git-server/01-chapter4.markdown
index 9eabe281d..81597c804 100755
--- a/es/04-git-server/01-chapter4.markdown
+++ b/es/04-git-server/01-chapter4.markdown
@@ -367,7 +367,7 @@ Gitosis necesita de ciertas herramientas Python, por lo que la  primera tarea se
 
 A continuación, has de clonar e instalar Gitosis desde el repositorio principal de su proyecto:
 
-	$ git clone git://eagain.net/gitosis.git
+	$ git clone https://github.com/tv42/gitosis.git
 	$ cd gitosis
 	$ sudo python setup.py install
 
diff --git a/es/omegat-Benzirpi.tmx b/es/omegat-Benzirpi.tmx
index f2e101c15..f789972d9 100644
--- a/es/omegat-Benzirpi.tmx
+++ b/es/omegat-Benzirpi.tmx
@@ -7133,12 +7133,12 @@ Figura 5-2.</seg>
     </tu>
     <tu>
       <tuv lang="EN">
-        <seg>$ git clone git://eagain.net/gitosis.git
+        <seg>$ git clone https://github.com/tv42/gitosis.git
 	$ cd gitosis
 	$ sudo python setup.py install</seg>
       </tuv>
       <tuv lang="ES">
-        <seg>$ git clone git://eagain.net/gitosis.git
+        <seg>$ git clone https://github.com/tv42/gitosis.git
 	$ cd gitosis
 	$ sudo python setup.py install</seg>
       </tuv>
diff --git a/fr/04-git-server/01-chapter4.markdown b/fr/04-git-server/01-chapter4.markdown
index 3633206d2..698952413 100644
--- a/fr/04-git-server/01-chapter4.markdown
+++ b/fr/04-git-server/01-chapter4.markdown
@@ -514,7 +514,7 @@ Il faut donc installer le paquet Python setuptools qu'Ubuntu fournit en tant que
 
 Ensuite, il faut cloner et installer Gitosis à partir du site principal du projet :
 
-	$ git clone git://eagain.net/gitosis.git
+	$ git clone https://github.com/tv42/gitosis.git
 	$ cd gitosis
 	$ sudo python setup.py install
 
diff --git a/it/04-git-server/01-chapter4.markdown b/it/04-git-server/01-chapter4.markdown
index 92e07362b..56a46cd8c 100644
--- a/it/04-git-server/01-chapter4.markdown
+++ b/it/04-git-server/01-chapter4.markdown
@@ -368,7 +368,7 @@ Gitosis richiede alcuni strumenti Python, così prima devi installare il pacchet
 
 Poi, puoi clonare ed installare Gitosis dal progetto principale:
 
-	$ git clone git://eagain.net/gitosis.git
+	$ git clone https://github.com/tv42/gitosis.git
 	$ cd gitosis
 	$ sudo python setup.py install
 
diff --git a/ja/04-git-server/01-chapter4.markdown b/ja/04-git-server/01-chapter4.markdown
index 3eedd344b..fb6cd1022 100644
--- a/ja/04-git-server/01-chapter4.markdown
+++ b/ja/04-git-server/01-chapter4.markdown
@@ -365,7 +365,7 @@ Gitosis は Python のツールを使います。まずは Python の setuptools
 
 次に、プロジェクトのメインサイトから Gitosis をクローンしてインストールします。
 
-	$ git clone git://eagain.net/gitosis.git
+	$ git clone https://github.com/tv42/gitosis.git
 	$ cd gitosis
 	$ sudo python setup.py install
 
diff --git a/ko/04-git-server/01-chapter4.markdown b/ko/04-git-server/01-chapter4.markdown
index 2755518da..bf2a34771 100644
--- a/ko/04-git-server/01-chapter4.markdown
+++ b/ko/04-git-server/01-chapter4.markdown
@@ -363,7 +363,7 @@ Gitosis는 Python이 필요하기 때문에 먼저 Python setuptools 패키지
 
 그리고 Gitosis 프로젝트 사이트에서 Gitosis를 Clone한 후 설치한다:
 
-	$ git clone git://eagain.net/gitosis.git
+	$ git clone https://github.com/tv42/gitosis.git
 	$ cd gitosis
 	$ sudo python setup.py install
 
diff --git a/nl/04-git-server/01-chapter4.markdown b/nl/04-git-server/01-chapter4.markdown
index b05646106..27f3105f7 100644
--- a/nl/04-git-server/01-chapter4.markdown
+++ b/nl/04-git-server/01-chapter4.markdown
@@ -369,7 +369,7 @@ Gitosis vereist enkele Python tools, dus moet je eerst het Python setuptools pak
 
 Vervolgens kloon en installeer je Gitosis van de hoofdpagina van het project:
 
-	$ git clone git://eagain.net/gitosis.git
+	$ git clone https://github.com/tv42/gitosis.git
 	$ cd gitosis
 	$ sudo python setup.py install
 
diff --git a/no-nb/04-git-server/01-chapter4.markdown b/no-nb/04-git-server/01-chapter4.markdown
index 244463a46..4c9639ff6 100644
--- a/no-nb/04-git-server/01-chapter4.markdown
+++ b/no-nb/04-git-server/01-chapter4.markdown
@@ -369,7 +369,7 @@ Gitosis requires some Python tools, so first you have to install the Python setu
 
 Next, you clone and install Gitosis from the project’s main site:
 
-	$ git clone git://eagain.net/gitosis.git
+	$ git clone https://github.com/tv42/gitosis.git
 	$ cd gitosis
 	$ sudo python setup.py install
 
diff --git a/pl/04-git-server/01-chapter4.markdown b/pl/04-git-server/01-chapter4.markdown
index 50550ae02..90b545c36 100644
--- a/pl/04-git-server/01-chapter4.markdown
+++ b/pl/04-git-server/01-chapter4.markdown
@@ -369,7 +369,7 @@ Gitosis wymaga pewnych pakietów Pythona, więc najpierw trzeba uruchomić pakie
 
 Następnie musisz skopiować oraz zainstalować pakiet Gitosis z głównej strony projektu:
 
-	$ git clone git://eagain.net/gitosis.git
+	$ git clone https://github.com/tv42/gitosis.git
 	$ cd gitosis
 	$ sudo python setup.py install
 
diff --git a/pt-br/04-git-server/01-chapter4.markdown b/pt-br/04-git-server/01-chapter4.markdown
index abdc94532..c97feb3ae 100644
--- a/pt-br/04-git-server/01-chapter4.markdown
+++ b/pt-br/04-git-server/01-chapter4.markdown
@@ -367,7 +367,7 @@ Gitosis requer algumas ferramentas Python, então antes de tudo você precisa in
 
 Depois, você clona e instala Gitosis do site principal do projeto:
 
-    $ git clone git://eagain.net/gitosis.git
+    $ git clone https://github.com/tv42/gitosis.git
     $ cd gitosis
     $ sudo python setup.py install
 
diff --git a/ru/04-git-server/01-chapter4.markdown b/ru/04-git-server/01-chapter4.markdown
index db26a87a7..92d11d939 100644
--- a/ru/04-git-server/01-chapter4.markdown
+++ b/ru/04-git-server/01-chapter4.markdown
@@ -368,7 +368,7 @@ Gitosis'у нужны некоторые инструменты для Python'а
 
 Затем вы клонируете и устанавливаете Gitosis с главного сайта проекта:
 
-	$ git clone git://eagain.net/gitosis.git
+	$ git clone https://github.com/tv42/gitosis.git
 	$ cd gitosis
 	$ sudo python setup.py install
 
diff --git a/zh/04-git-server/01-chapter4.markdown b/zh/04-git-server/01-chapter4.markdown
index c04b5933b..4df2c0ce2 100644
--- a/zh/04-git-server/01-chapter4.markdown
+++ b/zh/04-git-server/01-chapter4.markdown
@@ -366,7 +366,7 @@ Gitosis 的工作依赖于某些 Python 工具，所以首先要安装 Python 
 
 接下来，从 Gitosis 项目主页克隆并安装：
 
-	$ git clone git://eagain.net/gitosis.git
+	$ git clone https://github.com/tv42/gitosis.git
 	$ cd gitosis
 	$ sudo python setup.py install
 

From 36fba2837896bd016a8b7d945e3f3e45849d650c Mon Sep 17 00:00:00 2001
From: anaran <adrian.aichner@gmail.com>
Date: Sat, 8 Feb 2014 12:39:21 +0100
Subject: [PATCH 210/690] Update 01-chapter3.markdown

Replace `Revert` with `Switch` to avoid triggering an incorrect association with git-revert.
---
 en/03-git-branching/01-chapter3.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/en/03-git-branching/01-chapter3.markdown b/en/03-git-branching/01-chapter3.markdown
index e8294da74..6dd13bc27 100644
--- a/en/03-git-branching/01-chapter3.markdown
+++ b/en/03-git-branching/01-chapter3.markdown
@@ -102,7 +102,7 @@ Let’s go through a simple example of branching and merging with a workflow tha
 
 At this stage, you’ll receive a call that another issue is critical and you need a hotfix. You’ll do the following:
 
-1. Revert back to your production branch.
+1. Switch back to your production branch.
 2. Create a branch to add the hotfix.
 3. After it’s tested, merge the hotfix branch, and push to production.
 4. Switch back to your original story and continue working.

From 041b7ffd95396dbf68b0ba292a468f0c5640263c Mon Sep 17 00:00:00 2001
From: cor <git@cpt1.demon.nl>
Date: Mon, 10 Feb 2014 21:30:13 +0100
Subject: [PATCH 211/690] [nl] Chapter01: review and restructure sentences and
 wording

    add note to other translators, remove a number of typos and restructure
    some sentences.
---
 nl/01-introduction/01-chapter1.markdown | 125 +++++++++++++-----------
 1 file changed, 69 insertions(+), 56 deletions(-)

diff --git a/nl/01-introduction/01-chapter1.markdown b/nl/01-introduction/01-chapter1.markdown
index d64f59909..c423008e7 100644
--- a/nl/01-introduction/01-chapter1.markdown
+++ b/nl/01-introduction/01-chapter1.markdown
@@ -1,12 +1,25 @@
+<!-- Attentie heren en dames vertalers.
+
+Ik zou het volgende willen voorstellen:
+Er zijn bepaalde termen die voor de gemiddelde Nederlandse computer gebruiker veel beter klinken (of bekender voorkomen) als de orginele Engelse term. In het begin zullen deze termen niet vaak voorkomen, maar in de meer diepgaandere hoofdstukken komen deze steeds meer voor. Termen als "Committen", "Mergen" en "Applyen" klinken beter dan "Plegen" of "Toepassen", "Samenvoegen" en "Toepassen" (wat bovendien slecht valt te onderscheiden van de commit-toepassing). De mensen die dit boek lezen zijn, naar mijn bescheiden inschatting, al redelijk op de hoogte van versiebeheer en passen (zie ik in de praktijk) deze termen al toe. Een nieuwe terminologie introduceren lijkt me dan ook niet noodzakelijk.
+Verder blijven er altijd kreten over als "directory", wat vertaald zou kunnen worden als "map", maar bij het Engelse werkwoord to map, krijgen we dan weer het probleem: hoe dit weer te vertalen. Daarom zou ik willen voorstellen om deze basis-termen toch onvertaald te laten.
+Twijfelgevallen zullen altijd blijven zoals de term "file", daarvan wordt in de praktijk zowel de term file als bestand gebruikt. Ik denk dat we hier moeten kijken hoe het in de context past. 
+Maar ook een term als "tool" en (ik zit zelf nog op een mooie Nederlandse term te broeden) "plumbing", hierbij stel ik voor om eenmalig een Nederlandse vertaling te geven, tussen haakjes de Engelse term te geven en in het vervolg de Engelse term te gebruiken. Wederom is de context hier belangrijk.
+
+Let wel: ik wil niemand tot iets verplichten, maar ik denk dat we moeten streven naar een zo duidelijk mogelijke en best bij de praktijk aansluitende vertaling moeten proberen te maken.
+
+Veel succes en plezier bij het vertalen...
+
+-->
 # Aan de slag #
 
-Dit hoofdstuk legt uit je hoe je aan de slag kunt gaan met Git.  We zullen bij het begin beginnen: je krijgt een beetje achtergrondinformatie over versiebeheersystemen, daarna een korte uitleg hoe je Git werkend kan krijgen op je computer en hoe je het kan instellen zodat je ermee aan het werk kunt.  Aan het einde van dit hoofdstuk zou je moeten kunnen begrijpen waarom Git er is, waarom je het nodig hebt en zul je helemaal klaar zijn om er mee aan de slag te gaan.
+In dit hoofdstuk wordt uitgelegd hoe je aan de slag kunt gaan met Git. We zullen bij het begin beginnen door wat achtergrondinformatie over versiebeheersystemen te geven, daarna een korte uitleg hoe je Git werkend kan krijgen op je computer en sluiten af door uit te leggen hoe je Git kan instellen zodat je ermee aan het werk kunt.  Aan het einde van dit hoofdstuk zou je moeten kunnen begrijpen waarom Git er is, waarom je het zou moeten gebruiken en zal je helemaal klaar zijn om er mee aan de slag te gaan.
 
 ## Het wat en waarom van versiebeheer ##
 
-Wat is versiebeheer? En wat heeft dat met jou te maken? Versiebeheer is een systeem dat veranderingen in een bestand of groep van bestanden over de tijd bijhoudt, zodat je later specifieke versies kan opvragen. In de voorbeelden in dit boek is het broncode van computersoftware waarvan de versies beheerd worden maar je kan het eigenlijk met zo goed als elk soort bestand op een computer doen.
+Wat is versiebeheer, en wat heeft dat met jou te maken? Versiebeheer is het systeem waarbij veranderingen in een bestand of groep van bestanden over de tijd wordt bijgehouden, zodat je later specifieke versies kan opvragen. In de voorbeelden in dit boek is het broncode van computersoftware waarvan de versies beheerd worden maar in principe kan elk soort bestand op een computer aan versiebeheer worden onderworpen.
 
-Als je een grafisch ontwerper bent of websites maakt en elke versie van een afbeelding of opmaak wilt bewaren (wat je vrijwel zeker zult willen), is het verstandig een versiebeheersysteem (Version Control System in het Engels, afgekort tot VCS) te gebruiken. Als je dat gebruikt kan je eerdere versies van bestanden of hele project terughalen, veranderingen tussen twee momententen in tijd bekijken, zien wie het laatst iets aangepast heeft dat een probleem zou kunnen veroorzaken, wie een probleen heeft veroorzaakt en wanneer en nog veel meer. Een VCS gebruiken betekent meestal ook dat je de situatie gemakkelijk terug kan draaien als je een fout maakt of bestanden kwijtraakt. Daarbij komt nog dat dit allemaal heel weinig extra belasting met zich mee brengt.
+Als je een grafisch ontwerper bent of websites ontwerpt en elke versie van een afbeelding of opmaak wilt bewaren (wat je vrijwel zeker zult willen), is het verstandig een versiebeheersysteem (Version Control System in het Engels, afgekort tot VCS) te gebruiken. Als je dat gebruikt kan je eerdere versies van bestanden of het hele project terughalen, wijzigingen tussen twee momententen in tijd bekijken, zien wie het laatst iets aangepast heeft wat een probleem zou kunnen veroorzaken, wie een probleen heeft veroorzaakt en wanneer en nog veel meer. Een VCS gebruiken betekent meestal ook dat je de situatie gemakkelijk terug kan draaien als je een fout maakt of bestanden kwijtraakt. Daarbij komt nog dat dit allemaal heel weinig extra belasting met zich mee brengt.
 
 ### Lokale versiebeheersystemen ###
 
@@ -17,114 +30,114 @@ Om met dit probleem om te gaan hebben programmeurs lang geleden lokale VCSen ont
 Insert 18333fig0101.png
 Figuur 1-1. Een diagram van een lokaal versiebeheersysteem.
 
-Een populair gereedschap voor VCS was een systeem genaamd rcs, wat vandaag de dag nog steeds met veel computers wordt mee geleverd. Zelfs het populaire besturingssysteem Mac OS X heeft rcs als je de Developer Tools installeert. Dit gereedschap werkt in principe door verzamelingen van ‘patches’ (de verschillen tussen bestanden) van de opvolgende bestandsversies in een speciaal formaat op de harde schijf op te slaan. Zo kan je teruggaan naar hoe een bestand er uitzag op ieder willekeurig moment in tijd, door alle patches bij elkaar op te tellen.
+Een populair gereedschap voor VCS was een systeem genaamd rcs, wat vandaag de dag nog steeds met veel computers wordt mee geleverd. Zelfs het populaire besturingssysteem Mac OS X heeft rcs als je de Developer Tools installeert. Dit gereedschap werkt in principe door verzamelingen van ‘patches’ (de verschillen tussen bestanden) van de opvolgende bestandsversies in een speciaal formaat op de harde schijf op te slaan. Zo kan je een bestand reproduceren bestand zoals deze er uitzag op enig moment in tijd door alle patches bij elkaar op te tellen.
 
 ### Gecentraliseerde versiebeheersystemen ###
 
-De volgende belangrijke uitdaging waar mensen tegenaan lopen is dat ze samen moeten werken met ontwikkelaars op andere computers. Om deze uitdaging te overkomen ontwikkelde men Gecentraliseerde Versiebeheersystemen (CVCSen). Deze systemen, zoals CVS, Subversion en Perforce, hebben één centrale server waarop alle versies van de bestanden staan en een aantal clients die de bestanden daar van halen (‘check out’, in het Engels). Vele jaren was dit de standaard voor versiebeheer (zie Figuur 1-2).
+De volgende belangrijke uitdaging waar mensen tegenaan lopen is dat ze samen moeten werken met ontwikkelaars op andere computers. Om deze uitdaging te aan te gaan ontwikkelde men Gecentraliseerde Versiebeheersystemen (Centralized Version Control Systems, afgekort CVCSs). Deze systemen, zoals CVS, Subversion en Perforce, hebben één centrale server waarop alle versies van de bestanden staan en een aantal clients die de bestanden daar van ophalen (‘check out’). Vele jaren was dit de standaard voor versiebeheer (zie Figuur 1-2).
 
 Insert 18333fig0102.png
 Figuur 1-2. Een diagram van een gecentraliseerd versiebeheersysteem.
 
-Deze manier van versiebeheer biedt veel voordelen, vooral als je het vergelijkt met lokale VCSen. Bijvoorbeeld, iedereen weet tot op zekere hoogte wat de overige project-medewerkers aan het doen zijn. Beheerders hebben een hoge mate van controle over wie wat kan doen, en het is veel eenvoudiger om een CVCS te beheren dan te moeten werken met lokale databases op elke client.
+Deze manier van versiebeheer biedt veel voordelen, zeker ten opzichte van lokale VCSen. Bijvoorbeeld weet iedereen, tot op zekere hoogte, wat de overige project-medewerkers aan het doen zijn. Beheerders hebben een hoge mate van controle over wie wat kan doen, en het is veel eenvoudiger om een CVCS te beheren dan te moeten werken met lokale databases op elke client.
 
-Maar helaas, deze methode heeft ook behoorlijke nadelen. De duidelijkste is de ‘single point of failure’: als de centrale server plat gaat en een uur later weer terug online komt kan niemand in dat uur samenwerken of versies bewaren van de dingen waar ze aan werken. Als de harde schrijf waar de centrale database op staat corrupt raakt en er geen backups van zijn verlies je echt alles — de hele geschiedenis van het project, behalve de momentopnames die mensen op hun eigen computers hebben staan. Lokale VCSen hebben hetzelfde probleem — als je de hele geschiedenis van het project op één enkele plaats bewaart, loop je ook kans alles te verliezen.
+Maar helaas, deze methode heeft ook behoorlijke nadelen. De duidelijkste is de ‘single point of failure’: als de centrale server plat gaat en een uur later weer terug online komt kan niemand in dat uur samenwerken of versies bewaren van de dingen waar ze aan werken. Als de harde schrijf waar de centrale database op staat corrupt raakt en er geen backups van zijn verlies je echt alles; de hele geschiedenis van het project, behalve de momentopnames die mensen op hun eigen computers hebben staan. Lokale VCSen hebben hetzelfde probleem: als je de hele geschiedenis van het project op één enkele plaats bewaart, loop je ook kans alles te verliezen.
 
 ### Gedistribueerde versiebeheersystemen ###
 
-En hier verschijnen Gedistribueerde versiebeheersystemen (DVCSen) ten tonele. In een DVCS (zoals Git, Mercurial, Bazaar en Darcs) downloaden clients niet simpelweg de laatste momentopnames van de bestanden. De hele geschiedenis (de ‘repository’) wordt gekopiëerd. Dus als een server neergaat en deze systemen werkten via die server samen dan kan de repository van elke willekeurige client terug worden gekopiëerd naar de server om deze te herstellen. Elke checkout is dus eigenlijk een complete backup van alle data (zie Figuur 1-3).
+En hier verschijnen Gedistribueerde versiebeheersystemen (Distributed Version Control Systems, DVCSs) ten tonele. In een DVCS (zoals Git, Mercurial, Bazaar en Darcs) downloaden clients niet simpelweg de laatste momentopnames van de bestanden: de hele opslagplaats (de ‘repository’) wordt gekopiëerd. Dus als een server neergaat en deze systemen werkten via die server samen dan kan de repository van elke willekeurige client terug worden gekopiëerd naar de server om deze te herstellen. Elke checkout is dus in feite een complete backup van alle data (zie Figuur 1-3).
 
 Insert 18333fig0103.png
 Figuur 1-3. Diagram van een gedistribueerd versiebeheersysteem
 
-Bovendien werken veel van deze systemen behoorlijk goed met meerdere (niet-lokale) repositories tegelijk zodat je met verschillende groepen mensen op verschillende manieren tegelijk aan hetzelfde project kan werken. Hierdoor kan je verschillende werkprocessen (‘workflows’) opzetten die niet mogelijk waren geweest met gecentraliseerde systemen zoals hiërarchische modellen.
+Bovendien kunnen veel van deze systemen behoorlijk goed omgaan met meerdere (niet-lokale) repositories tegelijk, zodat je met verschillende groepen mensen op verschillende manieren tegelijk aan hetzelfde project kan werken. Hierdoor kan je verschillende werkprocessen (‘workflows’) opzetten die niet mogelijk waren geweest met gecentraliseerde systemen zoals hiërarchische modellen.
 
 ## Een kort historisch overzicht van Git ##
 
-Zoals zoveel goede dingen in het leven begon Git met een beetje creatieve destructie en een hoogoplopende controverse. De Linuxkernel is een open source softwareproject met een behoorlijk groot toepassingsgebied. In het kader van het onderhoud van de Linuxkernel (1991–2002), werden aanpassingen aan de software voornamelijk verspreid via patches en gearchiveerde bestanden. In 2002 veranderde dat want vanaf dat jaar begon het project een gesloten DVCS genaamd BitKeeper te gebruiken.
+Zoals zoveel goede dingen in het leven begon Git met een beetje creatieve destructie en een hoogoplopende controverse. De Linux kernel is een open source softwareproject met een behoorlijk grote omvang. Voor een lange tijd tijdens het onderhoud van de Linux kernel (1991–2002), werden aanpassingen aan de software voornamelijk verspreid via patches en gearchiveerde bestanden. In 2002 begon het project een gesloten DVCS genaamd BitKeeper te gebruiken.
 
-In 2005 viel de relatie tussen de gemeenschap die de Linuxkernel ontwikkelde en het commerciële bedrijf dat BitKeeper maakte uiteen, en het programma kon niet langer meer gratis worden gebruikt. Dit was de aanleiding voor de gemeenschap (en Linus Torvalds, de maker van Linux, in het bijzonder) om hun eigen gereedschap te ontwikkelen. Gebaseerd op de ervaring die opgedaan was toen ze nog BitKeeper gebruikten. Een paar van de doelen die ze hadden voor het nieuwe systeem waren als volgt:
+In 2005 viel de relatie tussen de gemeenschap die de Linux kernel ontwikkelde en het commerciële bedrijf dat BitKeeper maakte uiteen, en het programma mocht niet langer meer gratis worden gebruikt. Dit was de aanleiding voor de gemeenschap (en Linus Torvalds, de maker van Linux, in het bijzonder) om hun eigen gereedschap te ontwikkelen, gebaseerd op de ervaring die opgedaan was toen ze nog BitKeeper gebruikten. Een paar van de doelen die ze hadden voor het nieuwe systeem waren als volgt:
 
 *	Snelheid
 *	Eenvoudig ontwerp
 *	Goede ondersteuning voor niet-lineaire ontwikkeling (duizenden parallelle takken (branches) )
 *	Volledig gedistribueerd
-*	In staat om efficiënt om te gaan met grote projecten als de Linuxkernel (voor wat betreft snelheid maar ook opslagruimte)
+*	In staat om efficiënt om te gaan met grote projecten als de Linux kernel (voor wat betreft snelheid maar ook opslagruimte)
 
 Sinds het ontstaan in 2005 is Git gegroeid tot zijn huidige vorm: het is eenvoudig te gebruiken en heeft toch die oorspronkelijke eigenschappen behouden. Het is ongelofelijk snel, enorm efficiënt met grote projecten en een ongeëvenaard systeem van branches voor het ondersteunen van niet-lineaire ontwikkeling (zie Hoofdstuk 3).
 
 ## De basis van Git ##
 
-Dus, wat is Git in een notendop? Dit is een belangrijke paragraaf, omdat het waarschijnlijk een stuk makkelijker wordt om Git effectief te gebruiken als je goed begrijpt wat Git is en hoe het werkt. Probeer te vergeten wat je al weet over andere VCSen zoals Subversion en Perforce als je Git aan het leren bent; zo kan je verwarring door de subtiele verschillen voorkomen. Git gaat op een hele andere manier met informatie om dan die andere systemen, ook al lijken de verschillende commando’s behoorlijk op elkaar. Als je die verschillen begrijpt, kan je voorkomen dat je verward raakt als je Git gebruikt.
+Dus, wat is Git in een notendop? Dit is een belangrijke paragraaf om in je op te nemen, omdat als je goed begrijpt wat Git is en de fundamenten van de interne werking begrijpt, het waarschijnlijk een stuk makkelijker wordt om Git effectief te gebruiken. Probeer, als je Git aan het leren bent, te vergeten wat je al weet over andere VCSen zoals Subversion en Perforce; zo kan je verwarring bij gebruik door de subtiele verschillen voorkomen. Git gaat op een hele andere manier met informatie om dan die andere systemen, ook al lijken de verschillende commando’s behoorlijk op elkaar. Als je die verschillen begrijpt, kan je voorkomen dat je verward raakt als je Git gebruikt.
 
 ### Momentopnames in plaats van verschillen ###
 
-Een groot verschil tussen Git en elke andere VCS (inclusief Subversion en consoorten) is hoe Git denkt over zijn data. Conceptueel bewaren de meeste andere systemen informatie als een lijst van veranderingen per bestand. Deze systemen (CVS, Subversion, Perforce, Bazaar, enzovoort) zien de informatie die ze bewaren als een aantal bestanden en de veranderingen die aan die bestanden zijn aangebracht over de tijd, zoals geïllustreerd in Figuur 1-4.
+Een groot verschil tussen Git en elke andere VCS (inclusief Subversion en consorten) is hoe Git denkt over zijn data. Conceptueel bewaren de meeste andere systemen informatie als een lijst van veranderingen per bestand. Deze systemen (CVS, Subversion, Perforce, Bazaar, enzovoort) zien de informatie die ze bewaren als een aantal bestanden en de veranderingen die aan die bestanden zijn aangebracht over de tijd, zoals geïllustreerd in Figuur 1-4.
 
 Insert 18333fig0104.png
 Figuur 1-4. Andere systemen bewaren data meestal als veranderingen aan een basisversie van elk bestand.
 
-Git ziet en bewaart zijn data heel anders. De kijk van Git op zijn data kan worden uitgelegd als een reeks momentopnames (snapshots) van een miniatuurbestandsysteem. Elke keer dat je ‘commit’ - de status van van je project in Git opslaat - neemt het een soort van foto van hoe al je bestanden er op dat moment uitzien en slaat een verwijzing naar die snapshot op. Voor efficiëntie slaat Git ongewijzigde bestanden niet elke keer opnieuw op — alleen een verwijzing naar het eerdere identieke bestand dat het eerder al opgeslagen had. In Figuur 1-5 kan je zie hoe Git ongeveer over zijn data denkt.
+Git ziet en bewaart zijn data heel anders. De kijk van Git op zijn data kan worden uitgelegd als een reeks momentopnames (snapshots) van een miniatuurbestandsysteem. Elke keer dat je ‘commit’ (de status van van je project in Git opslaat) neemt het een soort van foto van hoe al je bestanden er op dat moment uitzien en slaat een verwijzing naar die foto op. Voor efficiëntie slaat Git ongewijzigde bestanden niet elke keer opnieuw op, alleen een verwijzing naar het eerdere identieke bestand dat het eerder al opgeslagen had. In Figuur 1-5 kan je zie hoe Git ongeveer over zijn data denkt.
 
 Insert 18333fig0105.png
 Figuur 1-5. Git bewaart data als momentopnames van het project.
 
-Dat is een belangrijk verschil tussen Git en bijna alle overige VCSen. Hierdoor vindt Git bijna elk onderdeel van versiebeheer opnieuw uit, terwijl de meeste andere systemen het van hebben overgenomen van eerdere generaties. Dit maakt Git meer een soort miniatuurbestandssysteem met een paar ongelooflijk krachtige gereedschappen, in plaats van niets meer dan een VCS. We zullen een paar van de voordelen die je krijgt als je op die manier over data denkt gaan onderzoeken, als we ‘branching’ (gesplitste ontwikkeling) toelichten in Hoofdstuk 3.
+Dat is een belangrijk onderscheid tussen Git en bijna alle overige VCSen. Hierdoor moet Git bijna elk aspect van versiebeheer heroverwegen, terwijl de meeste andere systemen het van hebben overgenomen van voorgaande generaties. Dit maakt Git meer een soort mini-bestandssysteem met een paar ongelooflijk krachtige gereedschappen, in plaats van niets meer of minder dan een VCS. We zullen een paar van de voordelen die je krijgt als je op die manier over data denkt gaan onderzoeken, als we ‘branching’ (gesplitste ontwikkeling) toelichten in Hoofdstuk 3.
 
 ### Bijna alles is lokaal ###
 
-De meeste handelingen in Git werken alleen op lokale bestanden en bronnen. Normaal gesproken is geen informatie nodig van een andere computer in je netwerk. Als je gewend bent aan een CVCS, waar de meeste handelingen vertraagd worden door het netwerk, lijkt Git door de goden begiftigd met de gave van ongelofelijke snelheid. Omdat je de hele geschiedenis van het project op je lokale harde schijf hebt staan, lijken de meeste acties geen tijd in beslag te nemen.
+De meeste handelingen in Git hebben alleen lokale bestanden en hulpmiddelen nodig. Normaalgesproken is geen informatie nodig van een andere computer in je netwerk. Als je gewend bent aan een CVCS, waar de meeste handelingen vertraagd worden door het netwerk, lijkt Git door de goden van snelheid begenadigd met onwereldse krachten. Omdat je de hele geschiedenis van het project op je lokale harde schijf hebt staan, lijken de meeste acties geen tijd in beslag te nemen.
 
-Een voorbeeld: Git hoeft niet aan een of andere server de geschiedenis van je project te vragen als je de die wilt doorbladeren – het leest simpelweg jouw lokale database. Dat betekent dat je de geschiedenis van het project bijna direct te zien krijgt. Als je de veranderingen wilt zien tussen de huidige versie van een bestand en de versie van een maand geleden kan Git het bestand van een maand geleden opzoeken, en de lokale verschillen berekenen, in plaats van aan een niet-lokale server te moeten vragen om het te doen, of de oudere versie van het bestand ophalen van een server om het lokaal te doen.
+Een voorbeeld: om de geschiedenis van je project te doorlopen hoeft Git niet bij een of andere server de geschiedenis van je project op te vragen; het leest simpelweg jouw lokale database. Dat betekent dat je de geschiedenis van het project bijna direct te zien krijgt. Als je de veranderingen wilt zien tussen de huidige versie van een bestand en de versie van een maand geleden kan Git het bestand van een maand geleden opzoeken en lokaal de verschillen berekenen, in plaats van aan een niet-lokale server te moeten vragen om het te doen, of de oudere versie van het bestand ophalen van een server om het vervolgens lokaal te doen.
 
-Dit betekent dat er maar heel weinig is dat je niet kunt doen als je offline bent of zonder VPN zit. Als je in een vliegtuig of trein zit, en je wilt nog even wat werken, kan je vrolijk doorgaan met commits maken tot je een netwerkverbinding krijgt, zodat je je werk kunt uploaden. Als je naar huis gaat en je VPN client niet aan de praat krijgt kan je nog steeds doorwerken. Bij veel andere systemen is dat of onmogelijk of zeer onaangenaam. Als je bijvoorbeeld Perforce gebruikt kun je niet zo veel doen als je niet verbonden bent met de server. Met Subversion en CVS kun je bestanden bewerken maar je kunt geen commits maken naar je database (omdat die offline is). Dat lijkt misschien niet zo belangrijk maar je zult nog versteld staan wat een verschil het kan maken.
+Dit betekent dat er maar heel weinig is dat je niet kunt doen als je offline bent of zonder VPN zit. Als je in een vliegtuig of trein zit en je wilt nog even wat werken, kan je vrolijk doorgaan met commits maken tot je een netwerkverbinding hebt zodat je dat werk kunt uploaden. Als je naar huis gaat en je VPN client niet aan de praat krijgt kan je nog steeds doorwerken. Bij veel andere systemen is dat onmogelijk of zeer onaangenaam. Als je bijvoorbeeld Perforce gebruikt kun je niet zo veel doen als je niet verbonden bent met de server. Met Subversion en CVS kun je bestanden bewerken maar je kunt geen commits maken naar je database (omdat die offline is). Dat lijkt misschien niet zo belangrijk maar je zult nog versteld staan wat een verschil het kan maken.
 
-### Git is integer ###
+### Git heeft integriteit ###
 
-Git maakt een controlegetal (‘checksum’) van alles voordat het wordt opgeslagen en er wordt later met dat controlegetal ernaar verwezen. Dat betekent dat het onmogelijk is om de inhoud van een bestand of map te veranderen zonder dat Git er vanaf weet. Deze functionaliteit is ingebouwd in het diepste deel van Git en staat centraal in zijn filosofie. Je kunt geen informatie kwijtraken als het wordt verstuurd en bestanden kunnen niet corrupt raken zonder dat Git het bemerkt.
+Alles in Git krijgt een controlegetal (‘checksum’) voordat het wordt opgeslagen en er wordt later met dat controlegetal ernaar gerefereerd. Dat betekent dat het onmogelijk is om de inhoud van een bestand of map te veranderen zonder dat Git er weet van heeft. Deze functionaliteit is in het diepste deel van Git ingebouwd en staat centraal in zijn filosofie. Je kunt geen informatie kwijtraken als het wordt verstuurd en bestanden kunnen niet corrupt raken zonder dat Git het kan opmerken.
 
-Het mechanisme dat Git gebruikt voor deze controlegetallen heet een SHA-1-hash. Dat is een tekenreeks van 40 karakters lang, bestaande uit hexadecimale tekens (0–9 en a–f) en wordt berekend uit de inhoud van een bestand of mappenstructuur in Git. Een SHA-1-hash ziet er ongeveer zo uit:
+Het mechanisme dat Git gebruikt voor deze controlegetallen heet een SHA-1-hash. Dat is een tekenreeks van 40 karakters lang, bestaande uit hexadecimale tekens (0–9 en a–f) en wordt berekend uit de inhoud van een bestand of directory-structuur in Git. Een SHA-1-hash ziet er ongeveer zo uit:
 
 	24b9da6552252987aa493b52f8696cd6d3b00373
 
-Je zult deze hashtekenreeksen overal tegenkomen omdat Git er zoveel gebruik van maakt. Sterker nog, Git bewaart data niet onder hun bestandsnaam maar in de database van Git met de hash van de inhoud als sleutel.
+Je zult deze hashwaarden overal tegenkomen omdat Git er zoveel gebruik van maakt. Sterker nog, Git bewaart alles niet onder een bestandsnaam maar in de database van Git met de hash van de inhoud als sleutel.
 
 ### Git voegt normaal gesproken alleen data toe ###
 
-Wanneer je iets doet in Git is de kans groot dat deze acties alleen maar data aan de database van Git toevoegen. Het is erg moeilijk om het systeem iets te laten doen dat je niet ongedaan kan maken of de gegevens te laten wissen op wat voor manier dan ook. Zoals met elke VCS kun je veranderingen verliezen of verhaspelen als deze nog niet hebt gecommit; maar als je dat eenmaal hebt gedaan, is het erg moeilijk om die data te verliezen, zeker als je je lokale database regelmatig uploadt (‘push’) naar een andere repository.
+Bijna alles wat je in Git doet, leidt tot toevoeging van data in de Git database. Het is erg moeilijk om het systeem iets te laten doen wat je niet ongedaan kan maken of het de gegevens te laten wissen op wat voor manier dan ook. Zoals met elke VCS kun je veranderingen verliezen of verhaspelen als deze nog niet hebt gecommit; maar als je dat eenmaal hebt gedaan, is het erg moeilijk om die data te verliezen, zeker als je de lokale database regelmatig uploadt (‘push’) naar een andere repository.
 
-Je zult nog veel plezier van Git hebben omdat je weet dat je kunt experimenteren zonder het gevaar te lopen jezelf behoorlijk in de nesten te werken. Zie Hoofdstuk 9 voor een iets diepgaandere uitleg over hoe Git zijn data bewaart en hoe je de data die verloren lijkt kunt terughalen.
+Dit maakt het gebruik van Git zo plezierig omdat je weet dat je kunt experimenteren zonder het gevaar te lopen jezelf behoorlijk in de nesten te werken. Zie Hoofdstuk 9 voor een iets diepgaandere uitleg over hoe Git zijn data bewaart en hoe je de data die verloren lijkt kunt terughalen.
 
 ### De drie toestanden ###
 
-Let nu goed op. Dit is het belangrijkste dat je over Git moet weten als je wilt dat de rest van het leerproces gladjes verloopt. Git heeft drie hoofdtoestanden waarin je bestanden zich kunnen bevinden: gecommit (‘commited’), aangepast (‘modified’) en voorbereid voor een commit (‘staged’). Committed houdt in dat alle data al veilig opgeslagen is in je lokale database. Modified betekent dat je je bestand hebt veranderd maar dat je nog niet naar je database gecommit hebt. Staged betekent dat je al hebt aangegeven dat je de huidige versie van het aangepaste bestand in je volgende commit meegenomen moet worden.
+Let nu goed op. Dit is het belangrijkste dat je over Git moet weten als je wilt dat de rest van het leerproces gladjes verloopt. Git heeft drie hoofdtoestanden waarin bestanden zich kunnen bevinden: gecommit (‘commited’), aangepast (‘modified’) en voorbereid voor een commit (‘staged’). Committed houdt in dat alle data veilig opgeslagen is in je lokale database. Modified betekent dat je het bestand hebt gewijzigd maar dat je nog niet naar je database gecommit hebt. Staged betekent dat je al hebt aangegeven dat je de huidige versie van het aangepaste bestand in je volgende commit meegenomen moet worden.
 
 Dit brengt ons tot de drie hoofdonderdelen van een Gitproject: de Git directory, de werk directory, en de wachtrij voor een commit (‘staging area’)
 
 Insert 18333fig0106.png 
 Figuur 1-6. Werk directory, wachtrij en Git directory
 
-De Git directory is waar Git de metadata en objectdatabase van je project opslaat. Dit is het belangrijkste deel van Git. Deze directort wordt gekopiëerd wanneer je een repository kloont vanaf een andere computer.
+De Git directory is waar Git de metadata en objectdatabase van je project opslaat. Dit is het belangrijkste deel van Git. Deze directory wordt gekopiëerd wanneer je een repository kloont vanaf een andere computer.
 
-De werk direcotry is een kopie van een bepaalde versie van het project (een ‘checkout’). Deze bestanden worden uit de gecomprimeerde database in de Git directory gehaald en op de harde schijf geplaatst waar jij ze kunt gebruiken of bewerken.
+De werk directory is een checkout van een bepaalde versie van het project. Deze bestanden worden uit de gecomprimeerde database in de Git directory gehaald en op de harde schijf geplaatst waar jij ze kunt gebruiken of bewerken.
 
-De wachtrij is een simpel bestand, dat zich normaalgesproken in je Git directory bevindt, waar informatie opgeslagen wordt over wat in de volgende commit meegaat. Het wordt soms de index genoemd, maar tegenwoordig wordt het de wachtrij (staging area) genoemd.
+De wachtrij is een simpel bestand, dat zich normaalgesproken in je Git directory bevindt, waar informatie opgeslagen wordt over wat in de volgende commit meegaat. Het wordt soms de index genoemd, maar tegenwoordig wordt het de staging area genoemd.
 
-De algemene manier van werken met Git gaat ongeveer zo:
+De algemene workflow met Git gaat ongeveer zo:
 
-1.	Je bewerkt bestanden in je werk directory.
-2.	Je bereidt de bestanden voor (staged), waardoor momentopnames worden toegevoegd aan de wachtrij.
-3.	Je maakt een commit. Een commit neemt alle momentopnames van de wachtrij en bewaart die voorgoed in je Git directory.
+1. Je bewerkt bestanden in je werk directory.
+2. Je bereidt de bestanden voor (staged), waardoor momentopnames (snapshots) worden toegevoegd aan de staging area.
+3. Je maakt een commit. Een commit neemt alle snapshots van de staging area en bewaart die voorgoed in je Git directory.
 
-Als een bepaalde versie van een bestand in de Git directory staat, wordt het beschouwd als gecommit. Als het is aangepast, maar wel aan de wachtrij is toegevoegd, is het staged. En als het veranderd is sinds het gekopiëerd werd, maar niet staged is, is het aangepast. In Hoofdstuk 2 leer je meer over deze toestanden en hoe je er je voordeel mee kunt doen, maar ook hoe je de wachtrij compleet over kunt slaan.
+Als een bepaalde versie van een bestand in de Git directory staat, wordt het beschouwd als gecommit. Als het is aangepast, maar wel aan de staging area is toegevoegd, is het staged. En als het veranderd is sinds het was uitgechecked maar niet staged is, is het aangepast. In Hoofdstuk 2 leer je meer over deze toestanden en hoe je er je voordeel mee kunt doen, maar ook hoe je de staging area compleet over kunt slaan.
 
 ## Git installeren ##
 
-Laten we eens een wat Git gebruiken. Je kunt natuurlijk niet meteen beginnen — je moet het eerst installeren. Er zijn een aantal manieren om eraan te komen; de belangrijkste twee zijn installeren vanaf broncode of een bestaand pakket voor jouw platform gebruiken.
+Laten we Git eens beginnen te gebruiken. Je kunt natuurlijk niet meteen beginnen, je moet het eerst installeren. Er zijn een aantal manieren om eraan te komen; de belangrijkste twee zijn installeren vanaf broncode of een bestaand pakket voor jouw platform gebruiken.
 
 ### Installeren vanaf de broncode ###
 
-Als het mogelijk is, is het meestal nuttig om Git vanaf de broncode te installeren, omdat je dan altijd de recentste versie hebt. Elke versie van Git brengt meestal nuttige verbeteringen aan de gebruikersinterface met zich mee, dus de laatste versie is vaak de beste manier als je het gewend bent software vanaf de broncode te compileren. Vaak hebben Linuxdistributies behoorlijk oude pakketen - tenzij je een hele up-to-date distro hebt of ‘backports’ (verbeteringen van een nieuwe versie op een oudere versie toepassen) gebruikt - is installeren vanaf broncode misschien wel de beste manier voor jou.
+Als het mogelijk is, is het meestal nuttig om Git vanaf de broncode te installeren, omdat je dan de meest recente versie krijgt. Elke versie van Git brengt meestal nuttige verbeteringen aan de gebruikersinterface met zich mee, dus de laatste versie is vaak de beste manier als je het gewend bent software vanaf de broncode te compileren. Vaak hebben Linuxdistributies behoorlijk oude pakketen, dus tenzij je een hele up-to-date distro hebt of ‘backports’ (verbeteringen van een nieuwe versie op een oudere versie toepassen) gebruikt, is installeren vanaf broncode misschien wel het beste voor je.
 
 Om Git te installeren heb je een aantal bibliotheken (‘libraries’) nodig waar Git van afhankelijk is: curl, zlib, openssl, expat, en libiconv. Als je bijvoorbeeld op een systeem werkt dat yum heeft (zoals Fedora) of apt-get (zoals systemen gebaseerd op Debian), kun je één van de volgende commando's gebruiken om alle bibliotheken waar Git van afhankelijk is te installeren:
 
@@ -134,7 +147,7 @@ Om Git te installeren heb je een aantal bibliotheken (‘libraries’) nodig waa
 	$ apt-get install libcurl4-gnutls-dev libexpat1-dev gettext \
 	  libz-dev
 
-Als je alle afhankelijkheden hebt, kun je de laatste momentopname van Git vanaf de officiële website downloaden:
+Als je alle benodigde afhankelijkheden hebt, kun je de laatste snapshot van Git vanaf de officiële website downloaden:
 
 	http://git-scm.com/download
 
@@ -172,33 +185,33 @@ De andere veelgebruikte manier is om Git via MacPorts (`http://www.macports.org`
 
 	$ sudo port install git-core +svn +doc +bash_completion +gitweb
 
-Je hoeft niet al die extra’s toe te voegen, maar je wilt waarschijnlijk +svn erbij hebben voor het geval je ooit onder Git met Subversion repositories moet omgaan (zie Hoofdstuk 8).
+Je hoeft niet alle extra’s toe te voegen, maar je wilt waarschijnlijk +svn erbij hebben voor het geval je ooit Git moet gebruiken met Subversion repositories (zie Hoofdstuk 8).
 
 ### Op Windows installeren ###
 
-Git op Windows installeren is erg eenvoudig. Het msysGit project heeft één van de eenvoudiger installatieprocedures. Je hoeft alleen maar het installatieprogramma te downloaden van GitHub, en het uit te voeren:
+Git op Windows installeren is erg eenvoudig. Het msysGit project heeft één van de eenvoudigere installatieprocedures. Je hoeft alleen maar het installatieprogramma te downloaden van GitHub, en het uit te voeren:
 
 	http://msysgit.github.com/
 
-Nadat het geïnstalleerd is, kun je Git zowel vanaf de commandprompt gebruiken (waar ook een SSH client bijzit die later nog van pas zal komen) als via de standaard GUI.
+Nadat het geïnstalleerd is, kun je Git zowel vanaf de commando-regel gebruiken (waar ook een SSH client bijzit die later nog van pas zal komen) als via de standaard GUI.
 
-Opmerking voor Windows gebruikers: je zou Git moeten gebruiken met de msysGit shell (Unix stijl), dit staat je toe de complexe commando's gegeven in dit boek te gebruiken. Als je om een of andere reden de Windows shell / commandprompt moet gebruiken, moet je dubbele quotes gebruiken in plaats van enkele quotes (voor parameters met spaties ertussen) en je moet quotes gebruiken bij parameters die eindigen met een circumflex (^) als ze achteraan de lijn staan, omdat dit een voortzettingssymbool is in Windows.
+Opmerking voor Windows gebruikers: je zou Git moeten gebruiken met de meegeleverde msysGit shell (Unix stijl), dit staat je toe de complexe commando's gegeven in dit boek te gebruiken. Als je om een of andere reden de Windows shell / commando-regel moet gebruiken, moet je dubbele quotes gebruiken in plaats van enkele quotes (voor parameters met spaties ertussen) en je moet quotes gebruiken bij parameters die eindigen met een circumflex (^) als ze als laatste op de regel staan, omdat dit een voortzettingssymbool is in Windows.
 
 ## Git klaarmaken voor eerste gebruik ##
 
-Nu je Git op je computer hebt staan, is het handig dat je een paar dingen doet om je Gitomgeving aan je voorkeuren aan te passen. Je hoeft deze instellingen normaliter maar één keer te doen, ze blijven hetzelfde als je een nieuwe versie van Git installeert. Je kunt ze op elk moment weer veranderen door de commando’s opnieuw uit te voeren.
+Nu je Git op je computer hebt staan, is het handig dat je een paar dingen doet om je Gitomgeving aan je voorkeuren aan te passen. Je hoeft deze instellingen normaliter maar één keer te doen, ze blijven hetzelfde als je een nieuwe versie van Git installeert. Je kunt ze ook op elk moment weer veranderen door de commando’s opnieuw uit te voeren.
 
 Git bevat standaard een stuk gereedschap genaamd `git config`, waarmee je de configuratie-eigenschappen kunt bekijken en veranderen, die alle aspecten van het uiterlijk en gedrag van Git regelen. Deze eigenschappen kunnen op drie verschillende plaatsen worden bewaard:
 
-*	Het bestand `/etc/gitconfig`: Bevat eigenschappen voor elk account op de computer en al hun repositories. Als je de optie `--system` meegeeft aan `git config`, zal het de configuratiegegevens in dit bestand lezen of veranderen.
-*	Het bestand `~/.gitconfig`: Eigenschappen voor jouw account. Je kunt Git dit bestand laten gebruiken door de optie `--global` mee te geven.
-*	Het configuratiebestand in de Gitmap (dus `.git/config`) van het repository dat je op het moment gebruikt: Specifiek voor die ene repository. Elk niveau neemt voorrang boven het voorgaande, dus waarden die in `.git/config` zijn gebruikt zullen worden gebruikt in plaats van die in `/etc/gitconfig`.
+*	Het bestand `/etc/gitconfig`: Bevat eigenschappen voor elk account op de computer en al hun repositories. Als je de optie `--system` meegeeft aan `git config`, zal het de configuratiegegevens in dit bestand lezen en schrijven.
+*	Het bestand `~/.gitconfig`: Eigenschappen voor jouw account. Je kunt Git dit bestand laten lezen en schrijven door de optie `--global` mee te geven.
+*	Het configuratiebestand in de Gitdirectory (dus `.git/config`) van de repository dat je op het moment gebruikt: Specifiek voor die ene repository. Elk niveau neemt voorrang boven het voorgaande, dus waarden die in `.git/config` zijn gebruikt zullen worden gebruikt in plaats van die in `/etc/gitconfig`.
 
-Op systemen met Windows zoekt Git in de `$HOME` directory naar het `.gitconfig`-bestand (`C:\Documents and Settings\$USER` voor de meesten). Het kijkt ook nog naar `/etc/gitconfig`, maar dan op de plek waar je MSys hebt staan, wat de plek is waar je Git op je Windowscomputer geïnstalleerd hebt.
+Op systemen met Windows zoekt Git naar het `.gitconfig`-bestand in de `$HOME` directory (`%USERPROFILE%` in een Windows omgeving) wat zich vertaalt in `C:\Documents and Settings\$USER` of `C:\Users\$USER` voor de meesten, afhankelijk van de versie (`$USER` is `%USERNAME%` in Windows omgevingen). Het zoekt ook nog steeds naar `/etc/gitconfig`, maar dan gerelateerd aan de plek waar je MSys hebt staan, en dat is de plek is waar je Git op je Windowscomputer geïnstalleerd hebt.
 
 ### Jouw identiteit ###
 
-Het eerste wat je zou moeten doen nadat je Git geïnstalleerd hebt, is je gebruikersnaam en e-mail adres opgeven. Dat is belangrijk, omdat elke commit in Git deze informatie gebruikt, en het onveranderlijk ingebed zit in de commits die je ronddeelt:
+Het eerste wat je zou moeten doen nadat je Git geïnstalleerd hebt, is je gebruikersnaam en e-mail adres opgeven. Dat is belangrijk omdat elke commit in Git deze informatie gebruikt, en het onveranderlijk ingebed zit in de commits die je ronddeelt:
 
 	$ git config --global user.name "John Doe"
 	$ git config --global user.email johndoe@example.com
@@ -207,21 +220,21 @@ Nogmaals, dit hoef je maar één keer te doen als je de `--global` optie erbij o
 
 ### Je tekstverwerker ###
 
-Nu Git weet wie je bent, kun je de tekstverwerker instellen die gebruikt zal worden als Git je een bericht in wilt laten typen. Normaliter gebruikt Git de standaardtekstverwerker van je systeem wat meestal Vi of Vim is. Als je een andere tekstverwerker wilt gebruiken, zoals Emacs, kun je het volgende doen:
+Nu Git weet wie je bent, kun je de standaard tekstverwerker instellen die gebruikt zal worden als Git je een bericht in wil laten typen. Normaliter gebruikt Git de standaardtekstverwerker van je systeem, wat meestal Vi of Vim is. Als je een andere tekstverwerker wilt gebruiken, zoals Emacs, kun je het volgende doen:
 
 	$ git config --global core.editor emacs
 
 ### Je diffprogramma ###
 
-En andere bruikbare optie die je misschien wel wilt instellen is het standaard diffprogramma om samenvoegingsconflicten op te lossen. Stel dat je vimdiff wilt gebruiken:
+En andere nuttige optie die je misschien wel wilt instellen is het standaard diffprogramma om mergeconflicten op te lossen. Stel dat je vimdiff wilt gebruiken:
 
 	$ git config --global merge.tool vimdiff
 
-Git accepteert kdiff3, tkdiff, meld, xxdiff, emerge, vimdiff, gvimdiff, ecmerge en opendiff als geldige samenvoegingsgereedschappen. Je kunt ook een ander programma gebruiken, zie Hoofdstuk 7 voor meer informatie daarover.
+Git accepteert kdiff3, tkdiff, meld, xxdiff, emerge, vimdiff, gvimdiff, ecmerge en opendiff als geldige merge tools. Je kunt ook een ander programma gebruiken, zie Hoofdstuk 7 voor meer informatie daarover.
 
-### Je instellingen bekijken ###
+### Je instellingen controleren ###
 
-Als je je instellingen wilt zien, kan je het `git config --list` commando gebruiken voor een lijstje met alle instellingen die Git vanaf de huidige locatie kan vinden:
+Als je je instellingen wilt controleren, kan je het `git config --list` commando gebruiken voor een lijst met alle instellingen die Git vanaf die locatie kan vinden:
 
 	$ git config --list
 	user.name=Scott Chacon
@@ -241,19 +254,19 @@ Je kan ook bekijken wat Git als instelling heeft bij een specifieke sleutel door
 
 ## Hulp krijgen ##
 
-Als je ooit hulp nodig hebt terwijl je Git gebruikt, hier zijn drie manieren om de gebruiksaanwijzing (manpage) voor elk Git commando te krijgen:
+Als je ooit hulp nodig hebt terwijl je Git gebruikt, zijn er drie manieren om de gebruiksaanwijzing (manpage) voor elk Git commando te krijgen:
 
 	$ git help <actie>
 	$ git <actie> --help
 	$ man git-<actie>
 
-Bijvoorbeeld, je kunt de gebruikershandleiding voor het commando `git config` krijgen door het volgende te typen:
+Bijvoorbeeld, je kunt de gebruikershandleiding voor het config commando krijgen door het volgende te typen:
 
 	$ git help config
 
 Deze commando's zijn prettig omdat je ze overal kunt opvragen, zelfs als je offline bent.
-Als de gebruiksaanwijzing en dit boek niet genoeg zijn en je persoonlijke hulp nodig hebt, kan je de kanalen `#git` of `#github` (beiden Engelstalig) op het Freenode IRC netwerk (irc.freenode.net) proberen. Deze kanalen zijn regelmatig gevuld met honderden mensen die allemaal zeer ervaren zijn met Git en vaak bereidwillig om te helpen.
+Als de manpage en dit boek niet genoeg zijn en je persoonlijke hulp nodig hebt, kan je de kanalen `#git` of `#github` (beiden Engelstalig) op het Freenode IRC netwerk (irc.freenode.net) proberen. In deze kanalen zijn regelmatig honderden mensen aangemeld die allemaal zeer ervaren zijn met Git en vaak bereidwillig om te helpen.
 
 ## Samenvatting ##
 
-Je zou nu een beetje een idee moeten hebben van wat Git is en op wat voor manieren het verschilt van het versiebeheersysteem dat je misschien eerder gebruikte. Je zou nu ook een werkende versie van Git op je systeem moeten hebben dat is ingesteld met jouw identiteit. Nu is het tijd om de grondbeginselen van Git te gaan leren.
+Je zou nu een beetje een idee moeten hebben wat Git is en op welke manieren het verschilt van het versiebeheersysteem dat je misschien eerder gebruikte. Je zou nu ook een werkende versie van Git op je systeem moeten hebben dat is ingesteld met jouw identiteit. Nu is het tijd om een aantal andere grondbeginselen van Git te gaan leren.

From 8b91b023567ef175c84049853b09161e29c2c561 Mon Sep 17 00:00:00 2001
From: Yue Lin Ho <b8732003@student.nsysu.edu.tw>
Date: Tue, 11 Feb 2014 17:05:05 +0800
Subject: [PATCH 212/690] [de] Synchronize with En version

---
 de/01-introduction/01-chapter1.markdown  |   4 +-
 de/02-git-basics/01-chapter2.markdown    | 297 ++++++++++++-----------
 de/03-git-branching/01-chapter3.markdown |  94 +++----
 de/04-git-server/01-chapter4.markdown    |  42 ++--
 4 files changed, 230 insertions(+), 207 deletions(-)

diff --git a/de/01-introduction/01-chapter1.markdown b/de/01-introduction/01-chapter1.markdown
index 9e6febd00..a7d675858 100644
--- a/de/01-introduction/01-chapter1.markdown
+++ b/de/01-introduction/01-chapter1.markdown
@@ -252,8 +252,8 @@ Nachdem Du die genannten Bibliotheken installiert hast, besorge Dir die aktuelle
 
 Danach kannst Du dann Git kompilieren und installieren:
 
-	$ tar -zxf git-1.6.0.5.tar.gz
-	$ cd git-1.6.0.5
+	$ tar -zxf git-1.7.2.2.tar.gz
+	$ cd git-1.7.2.2
 	$ make prefix=/usr/local all
 	$ sudo make prefix=/usr/local install
 
diff --git a/de/02-git-basics/01-chapter2.markdown b/de/02-git-basics/01-chapter2.markdown
index 518e1cd7e..525e6382b 100644
--- a/de/02-git-basics/01-chapter2.markdown
+++ b/de/02-git-basics/01-chapter2.markdown
@@ -92,8 +92,8 @@ Bild 2-1. Zyklus der Grundzustände Deiner Dateien
 Das wichtigste Hilfsmittel, um den Zustand zu überprüfen, in dem sich die Dateien in Deinem Repository gerade befinden, ist der Befehl `git status`. Wenn Du diesen Befehl unmittelbar nach dem Klonen eines Repositorys ausführst, sollte er folgende Ausgabe liefern:
 
 	$ git status
-	# On branch master
-	nothing to commit (working directory clean)
+	On branch master
+	nothing to commit, working directory clean
 
 <!--This means you have a clean working directory — in other words, no tracked files are modified. Git also doesn’t see any untracked files, or they would be listed here. Finally, the command tells you which branch you’re on. For now, that is always `master`, which is the default; you won’t worry about it here. The next chapter will go over branches and references in detail.-->
 
@@ -105,11 +105,12 @@ Sagen wir Du fügst eine neue `README` Datei zu Deinem Projekt hinzu. Wenn die D
 
 	$ vim README
 	$ git status
-	# On branch master
-	# Untracked files:
-	#   (use "git add <file>..." to include in what will be committed)
-	#
-	#	README
+	On branch master
+	Untracked files:
+	  (use "git add <file>..." to include in what will be committed)
+	
+	        README
+
 	nothing added to commit but untracked files present (use "git add" to track)
 
 <!--You can see that your new `README` file is untracked, because it’s under the “Untracked files” heading in your status output. Untracked basically means that Git sees a file you didn’t have in the previous snapshot (commit); Git won’t start including it in your commit snapshots until you explicitly tell it to do so. It does this so you don’t accidentally begin including generated binary files or other files that you did not mean to include. You do want to start including README, so let’s start tracking the file.-->
@@ -130,12 +131,12 @@ Um eine neue Datei zur Versionskontrolle hinzuzufügen, verwendest Du den Befehl
 Wenn Du den `git status` Befehl erneut ausführst, siehst Du, dass sich Deine `README` Datei jetzt unter Versionskontrolle befindet und für den nächsten Commit vorgemerkt ist (gestaged ist):
 
 	$ git status
-	# On branch master
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#	new file:   README
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        new file:   README
+	
 
 <!--You can tell that it’s staged because it’s under the “Changes to be committed” heading. If you commit at this point, the version of the file at the time you ran `git add` is what will be in the historical snapshot. You may recall that when you ran `git init` earlier, you then ran `git add (files)` — that was to begin tracking files in your directory. The `git add` command takes a path name for either a file or a directory; if it’s a directory, the command adds all the files in that directory recursively.-->
 
@@ -149,17 +150,18 @@ Dass die Datei für den nächsten Commit vorgemerkt ist, siehst Du daran, dass s
 Wenn Du eine bereits versionierte Datei `benchmarks.rb` änderst und den `git status` Befehl ausführst, erhältst Du folgendes:
 
 	$ git status
-	# On branch master
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#	new file:   README
-	#
-	# Changes not staged for commit:
-	#   (use "git add <file>..." to update what will be committed)
-	#
-	#	modified:   benchmarks.rb
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        new file:   README
+
+	Changes not staged for commit:
+	  (use "git add <file>..." to update what will be committed)
+	  (use "git checkout -- <file>..." to discard changes in working directory)
+	
+	        modified:   benchmarks.rb
+	
 
 <!--The `benchmarks.rb` file appears under a section named “Changes not staged for commit” — which means that a file that is tracked has been modified in the working directory but not yet staged. To stage it, you run the `git add` command (it’s a multipurpose command — you use it to begin tracking new files, to stage files, and to do other things like marking merge-conflicted files as resolved). Let’s run `git add` now to stage the `benchmarks.rb` file, and then run `git status` again:-->
 
@@ -167,13 +169,13 @@ Die Datei `benchmarks.rb` erscheint in der Sektion „Changes not staged for com
 
 	$ git add benchmarks.rb
 	$ git status
-	# On branch master
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#	new file:   README
-	#	modified:   benchmarks.rb
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        new file:   README
+	        modified:   benchmarks.rb
+	
 
 <!--Both files are staged and will go into your next commit. At this point, suppose you remember one little change that you want to make in `benchmarks.rb` before you commit it. You open it again and make that change, and you’re ready to commit. However, let’s run `git status` one more time:-->
 
@@ -181,18 +183,19 @@ Beide Dateien sind nun für den nächsten Commit vorgemerkt. Nehmen wir an, Du w
 
 	$ vim benchmarks.rb
 	$ git status
-	# On branch master
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#	new file:   README
-	#	modified:   benchmarks.rb
-	#
-	# Changes not staged for commit:
-	#   (use "git add <file>..." to update what will be committed)
-	#
-	#	modified:   benchmarks.rb
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        new file:   README
+	        modified:   benchmarks.rb
+	
+	Changes not staged for commit:
+	  (use "git add <file>..." to update what will be committed)
+	  (use "git checkout -- <file>..." to discard changes in working directory)
+	
+	        modified:   benchmarks.rb
+	
 
 <!--What the heck? Now `benchmarks.rb` is listed as both staged and unstaged. How is that possible? It turns out that Git stages a file exactly as it is when you run the `git add` command. If you commit now, the version of `benchmarks.rb` as it was when you last ran the `git add` command is how it will go into the commit, not the version of the file as it looks in your working directory when you run `git commit`. If you modify a file after you run `git add`, you have to run `git add` again to stage the latest version of the file:-->
 
@@ -200,13 +203,13 @@ Huch, was ist das? Jetzt wird `benchmarks.rb` sowohl in der Staging Area als auc
 
 	$ git add benchmarks.rb
 	$ git status
-	# On branch master
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#	new file:   README
-	#	modified:   benchmarks.rb
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        new file:   README
+	        modified:   benchmarks.rb
+	
 
 <!--### Ignoring Files ###-->
 ### Dateien ignorieren ###
@@ -289,17 +292,18 @@ Wenn Dir die Ausgabe des Befehl `git status` nicht aussagekräftig genug ist, we
 Nehmen wir an, Du hast die Datei `README` geändert und für einen Commit in der Staging Area vorgemerkt. Dann änderst Du außerdem die Datei `benchmarks.rb`, fügst sie aber noch nicht zur Staging Area hinzu. Wenn Du den `git status` Befehl dann ausführst, zeigt er Dir in etwa Folgendes an:
 
 	$ git status
-	# On branch master
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#	new file:   README
-	#
-	# Changes not staged for commit:
-	#   (use "git add <file>..." to update what will be committed)
-	#
-	#	modified:   benchmarks.rb
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        new file:   README
+	
+	Changes not staged for commit:
+	  (use "git add <file>..." to update what will be committed)
+	  (use "git checkout -- <file>..." to discard changes in working directory)
+	
+	        modified:   benchmarks.rb
+	
 
 <!--To see what you’ve changed but not yet staged, type `git diff` with no other arguments:-->
 
@@ -354,16 +358,18 @@ Ein anderes Beispiel: Wenn Du Änderungen an der Datei `benchmarks.rb` bereits z
 	$ git add benchmarks.rb
 	$ echo '# test line' >> benchmarks.rb
 	$ git status
-	# On branch master
-	#
-	# Changes to be committed:
-	#
-	#	modified:   benchmarks.rb
-	#
-	# Changes not staged for commit:
-	#
-	#	modified:   benchmarks.rb
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        modified:   benchmarks.rb
+	
+	Changes not staged for commit:
+	  (use "git add <file>..." to update what will be committed)
+	  (use "git checkout -- <file>..." to discard changes in working directory)
+	
+	        modified:   benchmarks.rb
+	
 
 <!--Now you can use `git diff` to see what is still unstaged-->
 
@@ -423,10 +429,9 @@ Der Editor zeigt in etwa folgenden Text an (dies ist ein Beispiel mit vim):
 	# with '#' will be ignored, and an empty message aborts the commit.
 	# On branch master
 	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
 	#       new file:   README
 	#       modified:   benchmarks.rb
+	#
 	~
 	~
 	~
@@ -441,8 +446,8 @@ Du siehst, dass die vorausgefüllte Commit Meldung die Ausgabe des letzten `git
 Alternativ kannst Du die Commit Meldung direkt mit dem Befehl `git commit` angeben, indem Du die Option `-m` wie folgt verwendest:
 
 	$ git commit -m "Story 182: Fix benchmarks for speed"
-	[master]: created 463dc4f: "Fix benchmarks for speed"
-	 2 files changed, 3 insertions(+), 0 deletions(-)
+	[master 463dc4f] Fix benchmarks for speed
+	 2 files changed, 3 insertions(+)
 	 create mode 100644 README
 
 <!--Now you’ve created your first commit! You can see that the commit has given you some output about itself: which branch you committed to (`master`), what SHA-1 checksum the commit has (`463dc4f`), how many files were changed, and statistics about lines added and removed in the commit.-->
@@ -461,15 +466,17 @@ Denke daran, dass jeder neue Commit denjenigen Snapshot aufzeichnet, den Du in d
 Obwohl die Staging Area unglaublich nützlich ist, um genau diejenigen Commits anzulegen, die Du in Deiner Projekt Historie haben willst, ist sie manchmal auch ein bisschen umständlich. Git stellt Dir deshalb eine Alternative zur Verfügung, mit der Du die Staging Area überspringen kannst. Wenn Du den Befehl `git commit` mit der Option `-a` ausführst, übernimmt Git automatisch alle Änderungen an dejenigen Dateien, die sich bereits unter Versionskontrolle befinden, in den Commit – sodass Du auf diese Weise den Schritt `git add` weglassen kannst:
 
 	$ git status
-	# On branch master
-	#
-	# Changes not staged for commit:
-	#
-	#	modified:   benchmarks.rb
-	#
+	On branch master
+	Changes not staged for commit:
+	  (use "git add <file>..." to update what will be committed)
+	  (use "git checkout -- <file>..." to discard changes in working directory)
+	
+	        modified:   benchmarks.rb
+	
+	no changes added to commit (use "git add" and/or "git commit -a")
 	$ git commit -a -m 'added new benchmarks'
 	[master 83e38c7] added new benchmarks
-	 1 files changed, 5 insertions(+), 0 deletions(-)
+	 1 files changed, 5 insertions(+)
 
 <!--Notice how you don’t have to run `git add` on the `benchmarks.rb` file in this case before you commit.-->
 
@@ -488,13 +495,14 @@ Wenn Du einfach nur eine Datei aus dem Arbeitsverzeichnis löschst, wird sie in
 
 	$ rm grit.gemspec
 	$ git status
-	# On branch master
-	#
-	# Changes not staged for commit:
-	#   (use "git add/rm <file>..." to update what will be committed)
-	#
-	#       deleted:    grit.gemspec
-	#
+	On branch master
+	Changes not staged for commit:
+	  (use "git add/rm <file>..." to update what will be committed)
+	  (use "git checkout -- <file>..." to discard changes in working directory)
+	
+	        deleted:    grit.gemspec
+	
+	no changes added to commit (use "git add" and/or "git commit -a")
 
 <!--Then, if you run `git rm`, it stages the file’s removal:-->
 
@@ -503,13 +511,12 @@ Wenn Du jetzt `git rm` ausführst, wird diese Änderung für den nächsten Commi
 	$ git rm grit.gemspec
 	rm 'grit.gemspec'
 	$ git status
-	# On branch master
-	#
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#       deleted:    grit.gemspec
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        deleted:    grit.gemspec
+	
 
 <!--The next time you commit, the file will be gone and no longer tracked. If you modified the file and added it to the index already, you must force the removal with the `-f` option. This is a safety feature to prevent accidental removal of data that hasn’t yet been recorded in a snapshot and that can’t be recovered from Git.-->
 
@@ -556,14 +563,12 @@ Das funktioniert einwandfrei. Wenn Du diesen Befehl ausführst und danach den `g
 
 	$ git mv README.txt README
 	$ git status
-	# On branch master
-	# Your branch is ahead of 'origin/master' by 1 commit.
-	#
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#       renamed:    README.txt -> README
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        renamed:    README.txt -> README
+	
 
 <!--However, this is equivalent to running something like this:-->
 Allerdings kannst Du genauso folgendes tun:
@@ -704,7 +709,7 @@ Außerdem gibt es verschiedene Optionen, die nützlich sind, um Dinge zusammenzu
 	    changed the version number
 
 	 Rakefile |    2 +-
-	 1 files changed, 1 insertions(+), 1 deletions(-)
+	 1 file changed, 1 insertion(+), 1 deletion(-)
 
 	commit 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7
 	Author: Scott Chacon <schacon@gee-mail.com>
@@ -713,7 +718,7 @@ Außerdem gibt es verschiedene Optionen, die nützlich sind, um Dinge zusammenzu
 	    removed unnecessary test code
 
 	 lib/simplegit.rb |    5 -----
-	 1 files changed, 0 insertions(+), 5 deletions(-)
+	 1 file changed, 5 deletions(-)
 
 	commit a11bef06a3f659402fe7563abf99ad00de2209e6
 	Author: Scott Chacon <schacon@gee-mail.com>
@@ -724,7 +729,7 @@ Außerdem gibt es verschiedene Optionen, die nützlich sind, um Dinge zusammenzu
 	 README           |    6 ++++++
 	 Rakefile         |   23 +++++++++++++++++++++++
 	 lib/simplegit.rb |   25 +++++++++++++++++++++++++
-	 3 files changed, 54 insertions(+), 0 deletions(-)
+	 3 files changed, 54 insertions(+)
 
 <!--As you can see, the `-\-stat` option prints below each commit entry a list of modified files, how many files were changed, and how many lines in those files were added and removed. It also puts a summary of the information at the end.-->
 <!--Another really useful option is `-\-pretty`. This option changes the log output to formats other than the default. A few prebuilt options are available for you to use. The `oneline` option prints each commit on a single line, which is useful if you’re looking at a lot of commits. In addition, the `short`, `full`, and `fuller` options show the output in roughly the same format but with less or more information, respectively:-->
@@ -960,33 +965,34 @@ Die nächsten zwei Abschnitte gehen darauf ein, wie Du Änderungen in der Stagin
 
 	$ git add .
 	$ git status
-	# On branch master
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#       modified:   README.txt
-	#       modified:   benchmarks.rb
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        modified:   README.txt
+	        modified:   benchmarks.rb
+	
 
 <!--Right below the “Changes to be committed” text, it says "use `git reset HEAD <file>...` to unstage". So, let’s use that advice to unstage the `benchmarks.rb` file:-->
 
 Direkt unter der Zeile „Changes to be committed“ findest Du den Hinweis „use `git reset HEAD <file>...` to unstage“, d.h. „aus der Staging Area zu entfernen“. Wir verwenden nun also diesen Befehl, um die Änderungen an der Datei `benchmarks.rb` aus der Staging Area zu nehmen:
 
 	$ git reset HEAD benchmarks.rb
-	benchmarks.rb: locally modified
+	Unstaged changes after reset:
+	M       benchmarks.rb
 	$ git status
-	# On branch master
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#       modified:   README.txt
-	#
-	# Changes not staged for commit:
-	#   (use "git add <file>..." to update what will be committed)
-	#   (use "git checkout -- <file>..." to discard changes in working directory)
-	#
-	#       modified:   benchmarks.rb
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        modified:   README.txt
+	
+	Changes not staged for commit:
+	  (use "git add <file>..." to update what will be committed)
+	  (use "git checkout -- <file>..." to discard changes in working directory)
+	
+	        modified:   benchmarks.rb
+	
 
 <!--The command is a bit strange, but it works. The `benchmarks.rb` file is modified but once again unstaged.-->
 
@@ -999,12 +1005,12 @@ Der Befehl liest sich zunächst vielleicht etwas merkwürdig, aber wie Du siehst
 
 Was aber, wenn Du die Änderungen an der Datei `benchmarks.rb` überhaupt nicht beibehalten willst? D.h., wenn Du sie in den Zustand zurückversetzen willst, in dem sie sich befand, als Du den letzten Commit angelegt hast (oder das Repository geklont hast). Das ist einfach, und glücklicherweise zeigt der `git status` Befehl ebenfalls bereits einen Hinweis dafür an. Die obige Ausgabe enthält den folgenden Text:
 
-	# Changes not staged for commit:
-	#   (use "git add <file>..." to update what will be committed)
-	#   (use "git checkout -- <file>..." to discard changes in working directory)
-	#
-	#       modified:   benchmarks.rb
-	#
+	Changes not staged for commit:
+	  (use "git add <file>..." to update what will be committed)
+	  (use "git checkout -- <file>..." to discard changes in working directory)
+	
+	        modified:   benchmarks.rb
+	
 
 <!--It tells you pretty explicitly how to discard the changes you’ve made (at least, the newer versions of Git, 1.6.1 and later, do this — if you have an older version, we highly recommend upgrading it to get some of these nicer usability features). Let’s do what it says:-->
 
@@ -1012,12 +1018,12 @@ Das sagt ziemlich klar, was wir zu tun haben um die Änderungen an der Datei zu
 
 	$ git checkout -- benchmarks.rb
 	$ git status
-	# On branch master
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#       modified:   README.txt
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        modified:   README.txt
+	
 
 <!--You can see that the changes have been reverted. You should also realize that this is a dangerous command: any changes you made to that file are gone — you just copied another file over it. Don’t ever use this command unless you absolutely know that you don’t want the file. If you just need to get it out of the way, we’ll go over stashing and branching in the next chapter; these are generally better ways to go.-->
 
@@ -1043,12 +1049,12 @@ Um mit anderen via Git zusammenzuarbeiten, musst Du wissen, wie Du auf externe (
 Der `git remote` Befehl zeigt Dir an, welche externen Server Du für Dein Projekt lokal konfiguriert hast, und listet die Kurzbezeichnungen für diese Remote Repository auf. Wenn Du ein Repository geklont hast, solltest Du mindestens `origin` sehen – welches der Standardname ist, den Git für denjenigen Server vergibt, von dem Du geklont hast:
 
 	$ git clone git://github.com/schacon/ticgit.git
-	Initialized empty Git repository in /private/tmp/ticgit/.git/
-	remote: Counting objects: 595, done.
-	remote: Compressing objects: 100% (269/269), done.
-	remote: Total 595 (delta 255), reused 589 (delta 253)
-	Receiving objects: 100% (595/595), 73.31 KiB | 1 KiB/s, done.
-	Resolving deltas: 100% (255/255), done.
+	Cloning into 'ticgit'...
+	remote: Reusing existing pack: 1857, done.
+	remote: Total 1857 (delta 0), reused 0 (delta 0)
+	Receiving objects: 100% (1857/1857), 374.35 KiB | 193.00 KiB/s, done.
+	Resolving deltas: 100% (772/772), done.
+	Checking connectivity... done.
 	$ cd ticgit
 	$ git remote
 	origin
@@ -1282,6 +1288,7 @@ Die Option `-m` gibt dabei wiederum die Meldung an, die zum Tag hinzugefügt wir
 	Date:   Mon Feb 9 14:45:11 2009 -0800
 
 	my version 1.4
+
 	commit 15027957951b64cf874c3557a0f3547bd83b3ff6
 	Merge: 4a447f7... a6b4c97...
 	Author: Scott Chacon <schacon@gee-mail.com>
diff --git a/de/03-git-branching/01-chapter3.markdown b/de/03-git-branching/01-chapter3.markdown
index 484496a93..81fea42ec 100644
--- a/de/03-git-branching/01-chapter3.markdown
+++ b/de/03-git-branching/01-chapter3.markdown
@@ -206,7 +206,7 @@ Abbildung 3-10. Eine kurze, einfache Commit-Historie
 Du hast Dich dafür entschieden an dem Issue #53, des Issue-Trackers XY, zu arbeiten. Um eines klarzustellen, Git ist an kein Issue-Tracking-System gebunden. Da der Issue #53 allerdings ein Schwerpunktthema betrifft, wirst Du einen neuen Branch erstellen um daran zu arbeiten. Um in einem Arbeitsschritt einen neuen Branch zu erstellen und zu aktivieren kannst Du das Kommando `git checkout` mit der Option `-b` verwenden:
 
 	$ git checkout -b iss53
-	Switched to a new branch "iss53"
+	Switched to a new branch 'iss53'
 
 <!--This is shorthand for:-->
 
@@ -245,7 +245,7 @@ Nun bekommst Du einen Anruf, in dem Dir mitgeteilt wird, dass es ein Problem mit
 Beachte jedoch, dass Dich Git den Branch nur wechseln lässt, wenn bisherige Änderungen in Deinem Arbeitsverzeichnis oder Deiner Staging-Area nicht in Konflikt mit dem Zweig stehen, zu dem Du nun wechseln möchtest. Am besten es liegt ein sauberer Status vor wenn man den Branch wechselt. Wir werden uns später mit Wegen befassen, dieses Verhalten zu umgehen (namentlich „Stashing“ und „Commit Ammending“). Vorerst aber hast Du Deine Änderungen bereits comitted, sodass Du zu Deinem MASTER-Branch zurückwechseln kannst.
 
 	$ git checkout master
-	Switched to branch "master"
+	Switched to branch 'master'
 
 <!--At this point, your project working directory is exactly the way it was before you started working on issue #53, and you can concentrate on your hotfix. This is an important point to remember: Git resets your working directory to look like the snapshot of the commit that the branch you check out points to. It adds, removes, and modifies files automatically to make sure your working copy is what the branch looked like on your last commit to it.-->
 
@@ -256,11 +256,11 @@ Zu diesem Zeitpunkt befindet sich das Arbeitsverzeichnis des Projektes in exakt
 Nun hast Du einen Hotfix zu erstellen. Lass uns dazu einen Hotfix-Branch erstellen, an dem Du bis zu dessen Fertigstellung arbeitest (siehe Abbildung 3-13):
 
 	$ git checkout -b hotfix
-	Switched to a new branch "hotfix"
+	Switched to a new branch 'hotfix'
 	$ vim index.html
 	$ git commit -a -m 'fixed the broken email address'
-	[hotfix]: created 3a0874c: "fixed the broken email address"
-	 1 files changed, 0 insertions(+), 1 deletions(-)
+	[hotfix 3a0874c] fixed the broken email address
+	 1 files changed, 1 deletion(-)
 
 <!--Figure 3-13. hotfix branch based back at your master branch point.-->
 
@@ -274,9 +274,9 @@ Mach Deine Tests, stell sicher das sich der Hotfix verhält wie erwartet und fü
 	$ git checkout master
 	$ git merge hotfix
 	Updating f42c576..3a0874c
-	Fast forward
-	 README |    1 -
-	 1 files changed, 0 insertions(+), 1 deletions(-)
+	Fast-forward
+	 README | 1 -
+	 1 file changed, 1 deletion(-)
 
 <!--You’ll notice the phrase "Fast forward" in that merge. Because the commit pointed to by the branch you merged in was directly upstream of the commit you’re on, Git moves the pointer forward. To phrase that another way, when you try to merge one commit with a commit that can be reached by following the first commit’s history, Git simplifies things by moving the pointer forward because there is no divergent work to merge together — this is called a "fast forward".-->
 
@@ -296,18 +296,18 @@ Abbildung 3-14. Der Master-Branch zeigt nach der Zusammenführung auf den gleich
 Nachdem Dein superwichtiger Hotfix veröffentlicht wurde, kannst Du Dich wieder Deiner ursprünglichen Arbeit zuwenden. Vorher wird sich allerdings des nun nutzlosen Hotfix-Zweiges entledigt, schließlich zeigt der Master-Branch ebenfalls auf die aktuelle Version. Du kannst ihn mit der `-d`-Option von `git branch` entfernen:
 
 	$ git branch -d hotfix
-	Deleted branch hotfix (3a0874c).
+	Deleted branch hotfix (was 3a0874c).
 
 <!--Now you can switch back to your work-in-progress branch on issue #53 and continue working on it (see Figure 3-15):-->
 
 Nun kannst Du zu Deinem Issue #53-Branch zurückwechseln und mit Deiner Arbeit fortfahren (Abbildung 3-15):
 
 	$ git checkout iss53
-	Switched to branch "iss53"
+	Switched to branch 'iss53'
 	$ vim index.html
 	$ git commit -a -m 'finished the new footer [issue 53]'
-	[iss53]: created ad82d7a: "finished the new footer [issue 53]"
-	 1 files changed, 1 insertions(+), 0 deletions(-)
+	[iss53 ad82d7a] finished the new footer [issue 53]
+	 1 file changed, 1 insertion(+)
 
 <!--Figure 3-15. Your iss53 branch can move forward independently.-->
 
@@ -328,9 +328,10 @@ Angenommen Du entscheidest dich, dass Deine Arbeit an issue #53 getan ist und Du
 
 	$ git checkout master
 	$ git merge iss53
-	Merge made by recursive.
-	 README |    1 +
-	 1 files changed, 1 insertions(+), 0 deletions(-)
+	Auto-merging README
+	Merge made by the 'recursive' strategy.
+	 README | 1 +
+	 1 file changed, 1 insertion(+)
 
 <!--This looks a bit different than the `hotfix` merge you did earlier. In this case, your development history has diverged from some older point. Because the commit on the branch you’re on isn’t a direct ancestor of the branch you’re merging in, Git has to do some work. In this case, Git does a simple three-way merge, using the two snapshots pointed to by the branch tips and the common ancestor of the two. Figure 3-16 highlights the three snapshots that Git uses to do its merge in this case.-->
 
@@ -376,27 +377,29 @@ Gelegentlich verläuft der Prozess nicht ganz so glatt. Wenn Du an den selben St
 
 Git hat hier keinen 'merge commit' erstellt. Es hat den Prozess gestoppt, damit Du den Konflikt beseitigen kannst. Wenn Du sehen willst, welche Dateien 'unmerged' aufgrund eines 'merge' Konflikts sind, benutze einfach `git status`:
 
-	[master*]$ git status
-	index.html: needs merge
-	# On branch master
-	# Changes not staged for commit:
-	#   (use "git add <file>..." to update what will be committed)
-	#   (use "git checkout -- <file>..." to discard changes in working directory)
-	#
-	#	unmerged:   index.html
-	#
+	$ git status
+	On branch master
+	You have unmerged paths.
+	  (fix conflicts and run "git commit")
+	
+	Unmerged paths:
+	  (use "git add <file>..." to mark resolution)
+	
+	        both modified:      index.html
+	
+	no changes added to commit (use "git add" and/or "git commit -a")
 
 <!--Anything that has merge conflicts and hasn’t been resolved is listed as unmerged. Git adds standard conflict-resolution markers to the files that have conflicts, so you can open them manually and resolve those conflicts. Your file contains a section that looks something like this:-->
 
 Alles, was einen 'merge' Konflikt aufweist und nicht gelöst werden konnte, wird als 'unmerged' aufgeführt. Git fügt den betroffenen Dateien Standard-Konfliktlösungsmarker hinzu, sodass Du diese öffnen und den Konflikt manuell lösen kannst. Deine Datei enthält einen Bereich, der so aussehen könnte:
 
-	<<<<<<< HEAD:index.html
+	<<<<<<< HEAD
 	<div id="footer">contact : email.support@github.com</div>
 	=======
 	<div id="footer">
 	  please contact us at support@github.com
 	</div>
-	>>>>>>> iss53:index.html
+	>>>>>>> iss53
 
 <!--This means the version in HEAD (your master branch, because that was what you had checked out when you ran your merge command) is the top part of that block (everything above the `=======`), while the version in your `iss53` branch looks like everything in the bottom part. In order to resolve the conflict, you have to either choose one side or the other or merge the contents yourself. For instance, you might resolve this conflict by replacing the entire block with this:-->
 
@@ -413,12 +416,17 @@ Diese Lösung hat von beiden Teilen etwas und ich habe die Zeilen mit `<<<<<<<`,
 Wenn Du ein grafischen Tool zur Bereinigung benutzen willst, dann verwende `git mergetool`. Das welches ein passendes grafisches 'merge'-Tool startet und Dich durch die Konfliktbereiche führt:
 
 	$ git mergetool
-	merge tool candidates: kdiff3 tkdiff xxdiff meld gvimdiff opendiff emerge vimdiff
-	Merging the files: index.html
+
+	This message is displayed because 'merge.tool' is not configured.
+	See 'git mergetool --tool-help' or 'git help config' for more details.
+	'git mergetool' will now attempt to use one of the following tools:
+	opendiff kdiff3 tkdiff xxdiff meld tortoisemerge gvimdiff diffuse diffmerge ecmerge p4merge araxis bc3 codecompare vimdiff emerge
+	Merging:
+	index.html
 
 	Normal merge conflict for 'index.html':
-	  {local}: modified
-	  {remote}: modified
+	  {local}: modified file
+	  {remote}: modified file
 	Hit return to start merge resolution tool (opendiff):
 
 <!--If you want to use a merge tool other than the default (Git chose `opendiff` for me in this case because I ran the command on a Mac), you can see all the supported tools listed at the top after “merge tool candidates”. Type the name of the tool you’d rather use. In Chapter 7, we’ll discuss how you can change this default value for your environment.-->
@@ -434,12 +442,12 @@ Wenn Du das 'merge' Werkzeug beendest, fragt Dich Git, ob das Zusammenführen er
 Du kannst `git status` erneut ausführen, um zu sehen, ob alle Konflikte gelöst sind:
 
 	$ git status
-	# On branch master
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#	modified:   index.html
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        modified:   index.html
+	
 
 <!--If you’re happy with that, and you verify that everything that had conflicts has been staged, you can type `git commit` to finalize the merge commit. The commit message by default looks something like this:-->
 
@@ -450,9 +458,9 @@ Wenn Du zufrieden bist und Du geprüft hast, dass alle Konflikte beseitigt wurde
 	Conflicts:
 	  index.html
 	#
-	# It looks like you may be committing a MERGE.
+	# It looks like you may be committing a merge.
 	# If this is not correct, please remove the file
-	# .git/MERGE_HEAD
+	#       .git/MERGE_HEAD
 	# and try again.
 	#
 
@@ -509,7 +517,7 @@ Um alle Branches zu sehen, welche noch nicht gemergte Änderungen enthalten, kan
 Die Liste zeigt Dir den anderen Branch. Er enthält Arbeit, die noch nicht gemergt wurde. Der Versuch, den Branch mit `git branch -d` zu löschen schlägt fehl:
 
 	$ git branch -d testing
-	error: The branch 'testing' is not an ancestor of your current HEAD.
+	error: The branch 'testing' is not fully merged.
 	If you are sure you want to delete it, run 'git branch -D testing'.
 
 <!--If you really do want to delete the branch and lose that work, you can force it with `-D`, as the helpful message points out.-->
@@ -711,16 +719,16 @@ Das Auschecken eines lokalen Branches von einem Remote-Branch erzeugt automatisc
 Wenn Du ein Repository klonst, wird automatisch ein `master`-Branch erzeugt, welcher `origin/master` verfolgt. Deshalb können `git push` und `git pull` ohne weitere Argumente aufgerufen werden. Du kannst natürlich auch eigene Tracking-Branches erzeugen – welche die nicht Zweige auf `origin` und dessen `master`-Branch verfolgen. Der einfachste Fall ist das bereits gesehene Beispiel in welchem Du `git checkout -b [branch] [remotename]/[branch]` ausführst. Mit der Git-Version 1.6.2 oder später kannst Du auch die `--track`-Kurzvariante nutzen:
 
 	$ git checkout --track origin/serverfix
-	Branch serverfix set up to track remote branch refs/remotes/origin/serverfix.
-	Switched to a new branch "serverfix"
+	Branch serverfix set up to track remote branch serverfix from origin.
+	Switched to a new branch 'serverfix'
 
 <!--To set up a local branch with a different name than the remote branch, you can easily use the first version with a different local branch name:-->
 
 Um einen lokalen Branch mit einem anderem Namen als der Remote-Branch, kannst Du einfach die erste Varianten mit einem neuen lokalen Branch-Namen:
 
 	$ git checkout -b sf origin/serverfix
-	Branch sf set up to track remote branch refs/remotes/origin/serverfix.
-	Switched to a new branch "sf"
+	Branch sf set up to track remote branch serverfix from origin.
+	Switched to a new branch 'sf'
 
 <!--Now, your local branch `sf` will automatically push to and pull from `origin/serverfix`.-->
 
diff --git a/de/04-git-server/01-chapter4.markdown b/de/04-git-server/01-chapter4.markdown
index 79115b17e..a5e1ab4b9 100644
--- a/de/04-git-server/01-chapter4.markdown
+++ b/de/04-git-server/01-chapter4.markdown
@@ -202,7 +202,8 @@ Um zunächst einen beliebigen Git Server einzurichten, musst Du ein existierende
 Um zunächst Dein Repository zu klonen, um ein neues einfaches Repository anzulegen, führst Du den Klonen-Befehl mit der `--bare` Option aus. Per Konvention haben einfache Repository Verzeichnisse die Endung `.git`, wie hier:
 
 	$ git clone --bare my_project my_project.git
-	Initialized empty Git repository in /opt/projects/my_project.git/
+	Cloning into bare repository 'my_project.git'...
+	done.
 
 <!--The output for this command is a little confusing. Since `clone` is basically a `git init` then a `git fetch`, we see some output from the `git init` part, which creates an empty directory. The actual object transfer gives no output, but it does happen. You should now have a copy of the Git directory data in your `my_project.git` directory.-->
 
@@ -453,6 +454,13 @@ Welche Aufgabe hat der `post-update` Hook? Er enthält in etwa folgendes:
 
 	$ cat .git/hooks/post-update
 	#!/bin/sh
+	#
+	# An example hook script to prepare a packed repository for use over
+	# dumb transports.
+	#
+	# To enable this hook, rename this file to "post-update".
+	#
+	
 	exec git-update-server-info
 
 <!--This means that when you push to the server via SSH, Git will run this command to update the files needed for HTTP fetching.-->
@@ -618,7 +626,7 @@ Jetzt kann es losgehen. Wenn Du alles richtig eingerichtet hast, kannst Du jetzt
 
 	$ ssh git@gitserver
 	PTY allocation request failed on channel 0
-	fatal: unrecognized command 'gitosis-serve schacon@quaternion'
+	ERROR:gitosis.serve.main:Need SSH_ORIGINAL_COMMAND in environment.
 	  Connection to gitserver closed.
 
 <!--That means Gitosis recognized you but shut you out because you’re not trying to do any Git commands. So, let’s do an actual Git command — you’ll clone the Gitosis control repository:-->
@@ -650,8 +658,8 @@ Wenn Du Dir die Datei `gitosis.conf` anschaust, sollten lediglich Daten für das
 	[gitosis]
 
 	[group gitosis-admin]
-	writable = gitosis-admin
 	members = scott
+	writable = gitosis-admin
 
 <!--It shows you that the 'scott' user — the user with whose public key you initialized Gitosis — is the only one who has access to the `gitosis-admin` project.-->
 
@@ -662,22 +670,22 @@ In dieser Datei wird Dir angezeigt, dass nur der Benutzer ‚scott‘ — das is
 Lass uns jetzt für Dich ein neues Projekt hinzufügen. Dazu fügen wir eine neue Sektion mit dem Namen `mobile` hinzu, in der wir alle Teammitglieder aus dem „Mobile“-Team und alle Repositorys, die von Ihnen benötigt werden, auflisten. Da ‚scott‘ bisher der einzige Benutzer im System ist, werden wir ihn als einziges Teammitglied hinzufügen. Das erste von uns erzeugte Projekt mit dem wir anfangen, nennt sich `iphone_project`:
 
 	[group mobile]
-	writable = iphone_project
 	members = scott
+	writable = iphone_project
 
 <!--Whenever you make changes to the `gitosis-admin` project, you have to commit the changes and push them back up to the server in order for them to take effect:-->
 
 Immer wenn Du Änderungen im Projekt `gitosis-admin` durchführst, musst Du diese Änderungen auch einchecken und auf den Server pushen, damit diese auch eine Wirkung zeigen:
 
 	$ git commit -am 'add iphone_project and mobile group'
-	[master]: created 8962da8: "changed name"
-	 1 files changed, 4 insertions(+), 0 deletions(-)
-	$ git push
+	[master 8962da8] add iphone_project and mobile group
+	 1 file changed, 4 insertions(+)
+	$ git push origin master
 	Counting objects: 5, done.
-	Compressing objects: 100% (2/2), done.
-	Writing objects: 100% (3/3), 272 bytes, done.
-	Total 3 (delta 1), reused 0 (delta 0)
-	To git@gitserver:/opt/git/gitosis-admin.git
+	Compressing objects: 100% (3/3), done.
+	Writing objects: 100% (3/3), 272 bytes | 0 bytes/s, done.
+	Total 3 (delta 0), reused 0 (delta 0)
+	To git@gitserver:gitosis-admin.git
 	   fb27aec..8962da8  master -> master
 
 <!--You can make your first push to the new `iphone_project` project by adding your server as a remote to your local version of the project and pushing. You no longer have to manually create a bare repository for new projects on the server — Gitosis creates them automatically when it sees the first push:-->
@@ -688,7 +696,7 @@ Du kannst Deinen ersten Push für das neue Projekt `iphone_project` ausführen,
 	$ git push origin master
 	Initialized empty Git repository in /opt/git/iphone_project.git/
 	Counting objects: 3, done.
-	Writing objects: 100% (3/3), 230 bytes, done.
+	Writing objects: 100% (3/3), 230 bytes | 0 bytes/s, done.
 	Total 3 (delta 0), reused 0 (delta 0)
 	To git@gitserver:iphone_project.git
 	 * [new branch]      master -> master
@@ -710,8 +718,8 @@ Da Du an diesem Projekt nicht alleine, sondern mit Deinen Freunden, arbeiten wil
 Damit diese Personen Lese- und Schreibzugriff auf das Projekt `iphone_project` haben, musst Du sie dem ‚mobile‘-Team hinzufügen:
 
 	[group mobile]
-	writable = iphone_project
 	members = scott john josie jessica
+	writable = iphone_project
 
 <!--After you commit and push that change, all four users will be able to read from and write to that project.-->
 
@@ -722,12 +730,12 @@ Nachdem Du diese Änderung commitet und gepusht hast, können alle vier Benutzer
 Mit Gitosis kann man auch einfache Zugriffsberechtigungen setzen. Wenn John nur Lesezugriff zum Projekt haben soll, dann kannst Du stattdessen folgendes angeben:
 
 	[group mobile]
-	writable = iphone_project
 	members = scott josie jessica
+	writable = iphone_project
 
 	[group mobile_ro]
-	readonly = iphone_project
 	members = john
+	readonly = iphone_project
 
 <!--Now John can clone the project and get updates, but Gitosis won’t allow him to push back up to the project. You can create as many of these groups as you want, each containing different users and projects. You can also specify another group as one of the members (using `@` as prefix), to inherit all of its members automatically:-->
 
@@ -737,12 +745,12 @@ Mit dieser Konfiguration kann John das Projekt klonen und kann neue Stände heru
 	members = scott josie jessica
 
 	[group mobile]
-	writable  = iphone_project
 	members   = @mobile_committers
+	writable  = iphone_project
 
 	[group mobile_2]
-	writable  = another_iphone_project
 	members   = @mobile_committers john
+	writable  = another_iphone_project
 
 <!--If you have any issues, it may be useful to add `loglevel=DEBUG` under the `[gitosis]` section. If you’ve lost push access by pushing a messed-up configuration, you can manually fix the file on the server under `/home/git/.gitosis.conf` — the file from which Gitosis reads its info. A push to the project takes the `gitosis.conf` file you just pushed up and sticks it there. If you edit that file manually, it remains like that until the next successful push to the `gitosis-admin` project.-->
 

From e41f7188e128974d160a2f58671760d4d5113082 Mon Sep 17 00:00:00 2001
From: Yue Lin Ho <b8732003@student.nsysu.edu.tw>
Date: Tue, 11 Feb 2014 17:05:48 +0800
Subject: [PATCH 213/690] Synchronize with de version

---
 en/09-git-internals/01-chapter9.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/en/09-git-internals/01-chapter9.markdown b/en/09-git-internals/01-chapter9.markdown
index 125d8524f..71d41a932 100644
--- a/en/09-git-internals/01-chapter9.markdown
+++ b/en/09-git-internals/01-chapter9.markdown
@@ -456,7 +456,7 @@ You can then check how big is that object on your disk:
 
 Now, modify that file a little, and see what happens:
 
-	$ echo '# testing' >> repo.rb 
+	$ echo '# testing' >> repo.rb
 	$ git commit -am 'modified repo a bit'
 	[master ab1afef] modified repo a bit
 	 1 files changed, 1 insertions(+), 0 deletions(-)

From 3033b7b2a3fbe84885ee82e38cd7f40ef9b0e053 Mon Sep 17 00:00:00 2001
From: Cor <git@cpt1.demon.nl>
Date: Tue, 11 Feb 2014 11:57:37 +0100
Subject: [PATCH 214/690] [nl] Chapter09 Retranslate and resequence

    Retranslated the chapter and resequenced the sentences so they sound
    less Dunglish.
---
 nl/09-git-internals/01-chapter9.markdown | 284 +++++++++++------------
 1 file changed, 142 insertions(+), 142 deletions(-)

diff --git a/nl/09-git-internals/01-chapter9.markdown b/nl/09-git-internals/01-chapter9.markdown
index c73cbd7c1..7727ea3cf 100644
--- a/nl/09-git-internals/01-chapter9.markdown
+++ b/nl/09-git-internals/01-chapter9.markdown
@@ -1,20 +1,20 @@
 # Het binnenwerk van Git #
 
-Je zult misschien naar dit hoofdstuk gesprongen zijn vanuit een vorig hoofdstuk, of je zult hier gekomen zijn nadat je de rest van het boek gelezen hebt – in ieder geval, zal hier het binnenwerk en implementatie van Git behandeld worden. Ik heb gemerkt dat het leren van deze informatie van fundamenteel belang is om te begrijpen hoe bruikbaar en krachtig Git is, maar anderen hebben daar tegenin gebracht dat het erg verwarrend en onnodig complex kan zijn voor beginners. Daarom heb ik deze beschrijving het laatste hoofdstuk gemaakt in het boek, zodat je het vroeg of later kunt lezen in je leerproces. Ik laat het aan jou over om dat te beslissen.
+Je zult misschien naar dit hoofdstuk gesprongen zijn vanuit een eerdere hoofdstuk, of je zult hier gekomen zijn nadat je de rest van het boek gelezen hebt; hoe dan ook zal hier het binnenwerk en implementatie van Git behandeld worden. Ik heb gemerkt dat het leren van deze informatie van fundamenteel belang is om te begrijpen hoe bruikbaar en krachtig Git is, maar anderen hebben daar tegenin gebracht dat het erg verwarrend en onnodig complex kan zijn voor beginners. Daarom heb ik deze beschrijving het laatste hoofdstuk gemaakt in het boek, zodat je het vroeg of later in je leerproces kunt lezen. Ik laat het aan jou over om dat te beslissen.
 
-Laten we beginnen, nu je hier bent. Als eerste, mocht het nog niet duidelijk zijn, is Git eigenlijk een inhouds-toegankelijk bestandssysteem met een gebruikersinterface voor versiebeheer er bovenop geschreven. Je zult over een poosje meer leren over wat dit betekent.
+Nu je hier bent, laten we beginnen. Ten eerste, mocht het nog niet duidelijk zijn, is Git eigenlijk een inhouds-adresseerbaar bestandssysteem met een gebruikersinterface voor versiebeheer er bovenop geschreven. Je zult over een poosje meer leren over wat dit betekent.
 
-In de eerste dagen van Git (het merendeel pre 1.5), wat de gebruikersinterface veel complexer, omdat het de nadruk legde op dit bestandssysteem in plaats van op een gepolijst VCS. De laatste paar jaren is de interface verfijnd totdat het zo netjes en eenvoudig te gebruiken is als ieder systeem dat er bestaat; maar vaak blijft het stereotype hangen over de vroegere Gitinterface, die complex was en moeilijk te leren.
+In de eerste dagen van Git (het merendeel pre 1.5), was de gebruikersinterface veel complexer, omdat het de nadruk legde op dit bestandssysteem in plaats van op een gepolijst VCS. De laatste paar jaren is de interface verfijnd totdat het zo netjes en eenvoudig te gebruiken is als een willekeurig ander systeem; maar vaak blijft het stereotype hangen van de vroegere Gitinterface die complex was en moeilijk te leren.
 
-Deze laag met het inhouds-toegankelijke bestandssysteem is ongelofelijk gaaf, dus dat behandel ik dat als eerste dit hoofdstuk; daarna leer je over de transportmechanismen en het onderhouden van je repository's, iets waar je uiteindelijk te maken mee kunt krijgen.
+Deze laag met het inhouds-toegankelijke bestandssysteem is ongelofelijk gaaf, dus dat behandel ik dat als eerste dit hoofdstuk; daarna leer je over de transportmechanismen en het onderhouden van je repository's, iets waar je uiteindelijk mee te maken kunt krijgen.
 
-## Sanitaire inrichtingen en porselein ##
+## Sanitaire voorzieningen en porselein ##
 
-Dit boek behandeld Git met ongeveer 30 werkwoorden zoals `checkout`, `branch`, `remote` enzovoorts. Maar omdat Git in eerste instantie een toolkit voor een VCS was, in plaats van een volledig gebruiksvriendelijk VCS, heeft het een berg werkwoorden die laag-bij-de-gronds werk doen en ontworpen waren om samengevoegd te worden zoals in UNIX gebruikelijk is, of vanuit scripts aangeroepen te worden. Naar deze commando's wordt over het algemeen als "plumbing" (sanitaire voorzieningen) commando's verwezen, en de meer gebruiksvriendelijke commando's worden "porcelain" (porselein) commando's genoemd.
+In dit boek wordt Git met ongeveer 30 werkwoorden zoals `checkout`, `branch`, `remote` enzovoorts behandeld. Maar omdat Git in eerste instantie een toolkit voor een VCS was, in plaats van een volledig gebruiksvriendelijk VCS, heeft het een berg werkwoorden die laag-bij-de-gronds werk doen en ontworpen waren om gebruikt te worden zoals in UNIX gebruikelijk is, of vanuit scripts aangeroepen te worden. Naar deze commando's wordt over het algemeen als "plumbing" (sanitaire voorzieningen) commando's gerefereerd, en de meer gebruiksvriendelijke commando's worden "porcelain" (porselein) commando's genoemd.
 
-De eerste acht hoofdstukken van het boek behandelen bijna alleen porseleincommando's. Maar in dit hoofdstuk zul je het meest op het laagste niveau van de sanitaire voorzieningen om te gaan. Zij geven je toegang tot de diepste delen van Git, en demonstreren hoe en waarom Git doet wat het doet. Deze commando's zijn niet bedoeld voor normaal gebruik op de commandoregel, maar meer om als bouwstenen voor nieuwe tools en scripts gebruikt te worden.
+De eerste acht hoofdstukken van het boek behandelen bijna alleen porselein commando's. Maar in dit hoofdstuk zul je het meest op het laagste niveau van de plumbing commando's om te gaan. Zij geven je toegang tot het binnenwerk van Git, en laten zien hoe en waarom Git doet wat het doet. Deze commando's zijn niet bedoeld voor normaal gebruik op de commandoregel, maar meer om als bouwstenen voor nieuwe tools en scripts gebruikt te worden.
 
-Als je `git init` uitvoert in een nieuwe of bestaande map, zal Git de map `.git` aanmaken, wat de plek is waar Git bijna alles opslaat en manipuleert. Als je een backup of kopie van je repository wilt maken, dan hoef je alleen maar die map te kopiëren, en je hebt bijna alles wat je nodig hebt. Dit hele hoofdstuk gaat in essentie over de inhoud van deze map. Hier zie je hoe het eruit ziet:
+Als je `git init` uitvoert in een nieuwe of bestaande directory, zal Git de directory `.git` aanmaken, wat de plek is waar bijna alles is wordt bewaard wat Git opslaat en manipuleert. Als je een backup of kopie van je repository wilt maken, dan hoef je alleen maar die directory te kopiëren, en je hebt bijna alles wat je nodig hebt. Dit hele hoofdstuk gaat in essentie over de inhoud van deze directory. Hier zie je hoe het eruit ziet:
 
 	$ ls
 	HEAD
@@ -27,14 +27,14 @@ Als je `git init` uitvoert in een nieuwe of bestaande map, zal Git de map `.git`
 	objects/
 	refs/
 
-Je kunt een paar andere bestanden zien, maar dit is een verse `git init` repository – dit is wat je standaard ziet. De `branches` map wordt niet gebruikt door nieuwere Git versies, en het `description` bestand wordt alleen gebruikt door het programma GitWeb, dus je hoeft je daar niet druk over te maken. Het bestand `config` bevat je project-specifieke configuratieopties, en de `info` map bevat een bestand met bestandsnaampatronen die je niet wilt volgen, maar ook niet wilt opnemen in een .gitignore bestand. De map `hooks` bevat scripts die aan bepaalde acties zijn “gehaakt” van gebruikers- en serverkant, die in detail beschreven zijn in Hoofdstuk 6.
+Je kunt een paar andere bestanden zien, maar dit is een verse `git init` repository; dit is wat je standaard ziet. De `branches` directory wordt niet gebruikt door nieuwere Git versies, en het `description` bestand wordt alleen gebruikt door het programma GitWeb, dus je hoeft je daar geen zorgen over te maken. Het bestand `config` bevat je project-specifieke configuratieopties, en de `info` directory bevat een bestand met bestandsnaampatronen die je niet wilt volgen, maar niet wilt opnemen in een .gitignore bestand. De directory `hooks` bevat scripts die aan bepaalde acties zijn “gehaakt” aan client- en serverkant, die in detail beschreven zijn in Hoofdstuk 7.
 
-Dit laat vier belangrijke vermeldingen over: de bestanden `HEAD` en `index`, en de mappen `objects` en `refs`. Dit zijn de kernbestandsdelen van Git. De map `objects` bewaart alle inhoud van je databank, de map `refs` bevat verwijzingen (branches) naar commitobjecten in die databank, het bestand `HEAD` wijst naar de branch die je op dit moment uitgechecked hebt, en het bestand `index` is waar Git de informatie van je wachtrij opslaat. Je gaat nu in detail naar elk van deze secties kijken om te zien hoe Git werkt.
+Dit laat vier belangrijke vermeldingen over: de bestanden `HEAD` en `index`, en de directories `objects` en `refs`. Dit zijn de kernbestandsdelen van Git. De directory `objects` bevat alle inhoud van je databank, de directory `refs` bevat verwijzingen naar commitobjecten (branches) in die databank, het bestand `HEAD` wijst naar de branch die je op dit moment uitgechecked hebt, en het bestand `index` is waar Git de informatie van je wachtrij (staging area) opslaat. Je gaat nu in detail naar elk van deze onderdelen kijken om te zien hoe Git werkt.
 
 ## Git objecten ##
 
-Git is een inhouds-adresseerbaar bestandssysteem. Mooi. Wat betekend dat?
-Het betekend dat in de kern van Git een eenvoudige sleutel-waarde gegevens opslag zit. Je kunt er ieder soort inhoud in stoppen, en het zal je een sleutel geven die je kunt gebruiken om de inhoud op ieder moment terug te krijgen. Om te demonstreren, kun je het sanitaire voorzieningen commando `hash-object` gebruiken, die wat gegevens aanneemt, het in je `.git` map opslaat, en je de sleutel teruggeeft waarmee de gegevens zijn opgeslagen. Als eerste initialiseer je een nieuw Git repository en verifieer je dat er niets in de `objects` map staat:
+Git is een inhouds-adresseerbaar bestandssysteem. Mooi. Wat betekent dat?
+Het betekent dat in de kern van Git een eenvoudige sleutel-waarde gegevensopslag zit. Je kunt er elk soort inhoud in stoppen, en het zal je een sleutel geven die je kunt gebruiken om de inhoud op ieder moment terug te krijgen. Om te demonstreren kan je het plumbing commando `hash-object` gebruiken die wat gegevens aanneemt, het in je `.git` directory opslaat, en je de sleutel teruggeeft waarmee de gegevens zijn opgeslagen. Als eerste initialiseer je een nieuw Git repository en verifieer je dat er niets in de `objects` directory staat:
 
 	$ mkdir test
 	$ cd test
@@ -47,24 +47,24 @@ Het betekend dat in de kern van Git een eenvoudige sleutel-waarde gegevens opsla
 	$ find .git/objects -type f
 	$
 
-Git heeft de `objects` map geïnitialiseerd en de `pack` en `info` submappen erin aangemaakt, maar er zijn geen reguliere bestanden. Nu sla je wat tekst in je Git databank op:
+Git heeft de `objects` directory geïnitialiseerd en de `pack` en `info` subdirectories erin aangemaakt, maar er zijn geen reguliere bestanden. Nu sla je wat tekst in je Git databank op:
 
 	$ echo 'test content' | git hash-object -w --stdin
 	d670460b4b4aece5915caf5c68d12f560a9fe3e4
 
-De `-w` verteld `hash-object` dat het object opgeslagen moet worden; anders zal het commando je alleen vertellen wat de sleutel zou zijn. `--stdin` verteld het commando dat het moet lezen van stdin; als je dit niet specificeert verwatch `hash-object` een pad naar een bestand. De uitvoer van het commando is een hash checksum van 40 karakters. Dit is de SHA-1 hash – een checksum van de inhoud die je opslaat plus een kop, waarover je zo meteen meer zult leren. Nu kun je zien hoe Git je gegevens opgeslagen heeft:
+De `-w` vertelt `hash-object` dat het object opgeslagen moet worden; anders zal het commando je alleen vertellen wat de sleutel zou zijn. Met `--stdin` vertel je het commando dat het de inhoud moet lezen van stdin; als je dit niet specificeert verwacht `hash-object` een pad naar een bestand. De uitvoer van het commando is een hash checksum van 40 karakters. Dit is de SHA-1 hash: een checksum van de inhoud die je opslaat plus een kop, waarover je zo meteen meer zult leren. Nu kun je zien hoe Git je gegevens opgeslagen heeft:
 
 	$ find .git/objects -type f
 	.git/objects/d6/70460b4b4aece5915caf5c68d12f560a9fe3e4
 
-Je kunt een bestand in de `objects` map zien. Dit is hoe Git de inhoud initieel opslaat – as een enkel bestand per stuk inhoud, vernoemd naar de SHA-1 checksum van de inhoud en z'n kop. De submap is vernoemd naar de eerste 2 karakters van de SHA, het het bestandsnaam zijn de overige 38 karakters.
+Je kunt een bestand in de `objects` directory zien. Dit is hoe Git de inhoud initieel opslaat: als een enkel bestand per stuk inhoud, vernoemd naar de SHA-1 checksum van de inhoud en z'n kop. De subdirectory is vernoemd naar de eerste 2 karakters van de SHA, en de bestandsnaam is de overige 38 karakters.
 
-Je kunt de inhoud terug uit Git halen met het `cat-file` commando. Dit commando is een soort Zwitsers zakmes om Git objecten mee te inspecteren. Door de `-p` optie mee te geven, instrueer je het `cat-file` commando om uit te zoeken van het type van de inhoud is en om het netjes aan je te tonen:
+Je kunt de inhoud terug uit Git halen met het `cat-file` commando. Dit commando is een soort Zwitsers zakmes om Git objecten mee te inspecteren. Door de `-p` optie mee te geven, instrueer je het `cat-file` commando om uit te zoeken wat het type van de inhoud is en om het netjes aan je te tonen:
 
 	$ git cat-file -p d670460b4b4aece5915caf5c68d12f560a9fe3e4
 	test content
 
-Nu kun je inhoud aan Git toevoegen, en het er weer uit halen. Je kunt dit ook doen met inhoud in bestanden. Bijvoorbeeld, je kunt wat eenvoudig versie beheer op een bestand doen. Als eerste maak je een nieuw bestand en slaat de inhoud op in je databank:
+Nu kun je inhoud aan Git toevoegen en het er weer uit halen. Je kunt dit ook doen met de inhoud van bestanden. Bijvoorbeeld, je kunt wat eenvoudig versie beheer op een bestand doen. Als eerste maak je een nieuw bestand en slaat de inhoud op in je databank:
 
 	$ echo 'version 1' > test.txt
 	$ git hash-object -w test.txt
@@ -95,21 +95,21 @@ of de tweede versie:
 	$ cat test.txt
 	version 2
 
-Maar de SHA-1 sleutel voor iedere versie van je bestand onthouden is niet erg praktisch; plus, je bewaard de bestandsnaam niet in je systeem – alleen de inhoud. Dit objecttype heet een blob. Je kunt Git jou het objecttype van ieder object in Git laten vertellen, gegeven de SHA-1 sleutel, met `cat-file -t`:
+Maar de SHA-1 sleutel voor iedere versie van je bestand onthouden is niet erg praktisch; plus je bewaart de bestandsnaam niet in je systeem, alleen de inhoud. Dit objecttype heet een blob. Je kunt Git het objecttype van ieder object in Git laten vertellen, gegeven de SHA-1 sleutel, met `cat-file -t`:
 
 	$ git cat-file -t 1f7a7a472abf3dd9643fd615f6da379c4acb3e3a
 	blob
 
-### Boom objecten ###
+### Boom (tree) objecten ###
 
-Het volgende type waar je naar gaat kijken is het boom object, wat het probleem van het opslaan van de bestandsnaam oplost en het je ook mogelijk maakt om een groep bestanden samen op te slaan. Git slaat inhoud op in dezelfde wijze als een UNIX bestandssysteem, maar dan wat vereenvoudigd. Alle inhoud wordt opgeslagen als boom- en blob-objecten, waarbij bomen corresponderen met UNIX map vermeldingen en blobs min of meer corresponderen aan inodes of bestandsinhoud. Een enkel boomobject bevat één of meer boom vermeldingen, waarvan ieder een SHA-1 point naar een blob of subboom bevat met zijn geassocieerde mode, type en bestandsnaam. Bijvoorbeeld, de meest recente boom in het simplegit project zou er zo uit kunnen zien:
+Het volgende type waar je naar gaat kijken is het tree object, wat het probleem van het opslaan van de bestandsnaam oplost en het ook mogelijk maakt om een groep bestanden gezamenlijk op te slaan. Git bewaart inhoud op vergelijkbare wijze als een UNIX bestandssysteem, maar dan wat vereenvoudigd. Alle inhoud wordt opgeslagen als tree- en blob-objecten, waarbij trees corresponderen met UNIX directory vermeldingen en blobs min of meer corresponderen aan inodes of bestandsinhoud. Een enkel treeobject bevat één of meer tree vermeldingen, waarvan ieder een SHA-1 pointer naar een blob of subtree bevat met zijn geassocieerde mode, type en bestandsnaam. Bijvoorbeeld, de meest recente tree in het simplegit project zou er zo uit kunnen zien:
 
 	$ git cat-file -p master^{tree}
 	100644 blob a906cb2a4a904a152e80877d4088654daad0c859      README
 	100644 blob 8f94139338f9404f26296befa88755fc2598c289      Rakefile
 	040000 tree 99f1a6d12cb4b6f19c8655fca46c3ecf317074e0      lib
 
-De `master^{tree}` syntax specificeert het boom object waarnaar gewezen wordt door de laatste commit op je `master` branch. Zie dat de `lib` submap geen blob is, maar een pointer naar een andere boom:
+De `master^{tree}` syntax specificeert het tree object waarnaar gewezen wordt door de laatste commit op je `master` branch. Merk op dat de `lib` subdirectory geen blob is, maar een pointer naar een andere tree:
 
 	$ git cat-file -p 99f1a6d12cb4b6f19c8655fca46c3ecf317074e0
 	100644 blob 47c6340d6459e05787f644c2447d2595f5d3a54b      simplegit.rb
@@ -119,32 +119,32 @@ Conceptueel zijn de gegevens die Git opslaat zoiets als in Figuur 9-1.
 Insert 18333fig0901.png
 Figuur 9-1. Eenvoudige versie van het Git data model.
 
-Je kunt je eigen boom maken. Normaal gesproken maakt Git een boom door de status van je staging gebied of index te pakken en daar een boom object mee te schrijven. Dus, om een boomobject te maken moet je eerst een index instellen door een paar bestanden te stagen. Om een index te maken met een enkele vermelding – de eerste versie van je test.txt bestand – kun je het sanitaire voorzieningen commando `update-index` gebruiken. Je gebruikt dit commando om kunstmatig de eerdere versie van het test.txt bestand toe te voegen aan een nieuw staging gebied. Je moet het de `--add` optie meegeven, omdat het bestand nog niet bestaat in je staging gebied (je hebt zelfs nog geen staging gebied ingesteld) en `--cacheinfo` omdat het bestand dat je toevoegt niet in je map staat, maar wel in je databank. Daarna specificeer je de mode, SHA-1 en bestandsnaam:
+Je kunt je eigen tree maken. Normaal gesproken maakt Git een tree door de status van je staging gebied of index te pakken en daar een tree object mee te schrijven. Dus, om een treeobject te maken moet je eerst een index opzetten door een paar bestanden te stagen. Om een index te maken met een enkele vermelding, de eerste versie van je test.txt bestand, kun je het plumbing commando `update-index` gebruiken. Je gebruikt dit commando om kunstmatig de eerdere versie van het test.txt bestand toe te voegen aan een nieuw staging gebied. Je moet het de `--add` optie meegeven omdat het bestand nog niet bestaat in je staging gebied (je hebt zelfs nog geen staging gebied ingesteld) en `--cacheinfo` omdat het bestand dat je toevoegt niet in je directory staat maar in je databank. Daarna specificeer je de modus, SHA-1 en bestandsnaam:
 
 	$ git update-index --add --cacheinfo 100644 \
 	  83baae61804e65cc73a7201a7252750c76066a30 test.txt
 
-In dit geval specificeer je een mode van `100644`, wat betekend dat het een normaal bestand is. Andere opties zijn `100755`, wat betekend dat het een uitvoerbaar bestand is; en `120000`, wat een symbolische link specificeert. De mode is genomen van normale UNIX modes, maar is veel minder flexibel – deze drie modi zijn de enigen die geldig zijn voor bestanden (blobs) in Git (alhoewel andere modi worden gebruikt voor mappen en submodules).
+In dit geval specificeer je een modus `100644`, wat aangeeft dat het een normaal bestand is. Andere opties zijn `100755`, wat aangeeft dat het een uitvoerbaar bestand is, en `120000` wat een symbolische link specificeert. De modus is afgekeken van normale UNIX modi, maar is veel minder flexibel; deze drie modi zijn de enige die geldig zijn voor bestanden (blobs) in Git (alhoewel andere modi worden gebruikt voor directories en submodules).
 
-Nu kun je het `write-tree` commando gebruiken om het staging gebied naar een boomobject te schrijven. Er is geen `-w` optie nodig – `write-tree` aanroepen zorgt er automatisch voor dat een boomobject gecreëerd wordt van de status van de index als die boom nog niet bestaat:
+Nu kun je het `write-tree` commando gebruiken om het staging area naar een treeobject te schrijven. Er is geen `-w` optie nodig, `write-tree` aanroepen zorgt er automatisch voor dat een treeobject gecreëerd wordt van de status van de index als die tree nog niet bestaat:
 
 	$ git write-tree
 	d8329fc1cc938780ffdd9f94e0d364e0ea74f579
 	$ git cat-file -p d8329fc1cc938780ffdd9f94e0d364e0ea74f579
 	100644 blob 83baae61804e65cc73a7201a7252750c76066a30      test.txt
 
-Je kunt ook verifiëren dat dit een boomobject is:
+Je kunt ook verifiëren dat dit een treeobject is:
 
 	$ git cat-file -t d8329fc1cc938780ffdd9f94e0d364e0ea74f579
 	tree
 
-Je zult nu een nieuwe boom aanmaken met de tweede versie van het test.txt bestand en ook een nieuw bestand:
+Je gaat nu een nieuwe tree aanmaken met de tweede versie van het test.txt bestand en ook een nieuw bestand:
 
 	$ echo 'new file' > new.txt
 	$ git update-index test.txt
 	$ git update-index --add new.txt
 
-Je staging gebied heeft nu een nieuwe versie van test.txt, als ook het nieuwe new.txt bestand. Schrijf de boom (sla de status van het staging gebied of index op als boom object) en kijk hoe het er uit ziet:
+Je staging area heeft nu een nieuwe versie van test.txt, als ook het nieuwe new.txt bestand. Schrijf de tree (wat de status van het staging area of index opslaat als tree object) en kijk hoe het er uit ziet:
 
 	$ git write-tree
 	0155eb4229851634a0f03eb265b69f5a2d56f341
@@ -152,7 +152,7 @@ Je staging gebied heeft nu een nieuwe versie van test.txt, als ook het nieuwe ne
 	100644 blob fa49b077972391ad58037050f2a75f74e3671e92      new.txt
 	100644 blob 1f7a7a472abf3dd9643fd615f6da379c4acb3e3a      test.txt
 
-Zie dat deze boom beide bestandsvermeldingen bevat en ook dat de SHA van test.txt dezelfde "versie 2" SHA is als eerder (`1f7a7a`). Je zult nu voor de lol de eerste boom als een subboom toevoegen aan deze. Je kunt bomen in je staging gebied lezen door `read-tree` aan te roepen. In dit geval kun je een bestaande boom in je staging gebied lezen als een subboom met de `--prefix` optie aan `read-tree`:
+Merk op dat deze tree beide bestandsvermeldingen bevat en ook dat de SHA van test.txt de "versie 2" SHA is van eerder (`1f7a7a`). Je gaat nu voor de lol de eerste tree als een subtree toevoegen aan deze. Je kunt trees in je staging area lezen door `read-tree` aan te roepen. In dit geval kun je een bestaande tree in je staging area lezen als een subtree met de `--prefix` optie aan `read-tree`:
 
 	$ git read-tree --prefix=bak d8329fc1cc938780ffdd9f94e0d364e0ea74f579
 	$ git write-tree
@@ -162,16 +162,16 @@ Zie dat deze boom beide bestandsvermeldingen bevat en ook dat de SHA van test.tx
 	100644 blob fa49b077972391ad58037050f2a75f74e3671e92      new.txt
 	100644 blob 1f7a7a472abf3dd9643fd615f6da379c4acb3e3a      test.txt
 
-Als je een werkmap zou maken van de nieuwe boom die je zojuist geschreven hebt, zou je de twee bestanden in het bovenste niveau van de werkmap krijgen en een submap genaamd `bak` die de eerste versie van het test.txt bestand bevatte. Je kunt over de gegevens die Git bevat voor deze structuren denken zoals getoond in Figuur 9-2.
+Als je een werkdirectory zou maken van de nieuwe tree die je zojuist geschreven hebt, zou je de twee bestanden in het hoogste niveau van de werkdirectory krijgen en een subdirectory genaamd `bak` die de eerste versie van het test.txt bestand bevat. Je kunt de gegevens die Git bevat voor deze structuren zien zoals getoond in Figuur 9-2.
 
 Insert 18333fig0902.png
 Figuur 9-2. De inhoud structuur van je huidige Git gegevens.
 
 ### Commit objecten ###
 
-Je hebt drie bomen die de verschillende snapshots specificeren die je wilt volgen, maar het eerdere probleem blijft: je moet alledrie de SHA-1 waarden onthouden om de snapshots weer op te halen. Je hebt ook geen informatie over wie de snapshots opgeslagen heeft, wanneer ze opgeslagen zijn, of waarom ze opgeslagen zijn. Dit is de basale informatie die het commit object voor je opslaat.
+Je hebt drie trees die de verschillende snapshots specificeren die je wilt volgen, maar het eerdere probleem blijft: je moet alledrie SHA-1 waarden onthouden om de snapshots weer op te halen. Je hebt ook geen informatie over wie de snapshots opgeslagen heeft, wanneer ze opgeslagen zijn of waarom ze opgeslagen zijn. Dit is de basale informatie die het commit object voor je bevat.
 
-Om een commit object te creëren moet je `commit-tree` aanroepen en één boom SHA-1 specificeren en welke commit objecten, als er die zijn, er direct aan vooraf gingen. Start met de eerste boom, die je geschreven hebt:
+Om een commit object te creëren moet je `commit-tree` aanroepen en één tree SHA-1 specificeren en welke commit objecten, als er die zijn, er direct aan vooraf gingen. Begin met de eerste tree die je geschreven hebt:
 
 	$ echo 'first commit' | git commit-tree d8329f
 	fdf4fc3344e67ab068f836878b6c4951e3b15f3d
@@ -185,16 +185,16 @@ Nu kun je je nieuwe commit object bekijken met `cat-file`:
 
 	first commit
 
-Het formaat van een commit object is simpel: het specificeert de bovenste boom voor het snapshot van het project op dat punt; de auteur/committer informatie die uit je `user.name` en `user.email` configuratie instellingen gehaald is, met de huidige tijd; een lege regel, en dan de commit boodschap.
+Het formaat van een commit object is simpel: het specificeert de hoogste tree voor de snapshot van het project op dat punt, de auteur/committer informatie die uit de `user.name` en `user.email` configuratie instellingen gehaald is, met de huidige tijd, een lege regel en dan de commit boodschap.
 
-Nu zul je de twee andere commit objecten schrijven, waarbij ze elk het commit object dat er direct voor komt refereren:
+Nu ga je de twee andere commit objecten schrijven, waarbij ze elk naar het commit object dat er direct voor komt verwijzen:
 
 	$ echo 'second commit' | git commit-tree 0155eb -p fdf4fc3
 	cac0cab538b970a37ea1e769cbbde608743bc96d
 	$ echo 'third commit'  | git commit-tree 3c4e9c -p cac0cab
 	1a410efbd13591db07496601ebc7a059dd55cfe9
 
-Ieder van de drie commit objecten wijst naar één van de drie snapshots die je gemaakt hebt. Vreemd genoeg heb je nu een echte Git historie, die je kunt bekijken met het `git log` commando, als je dat op de SHA-1 van de laatste commit uitvoert:
+Ieder van de drie commit objecten wijst naar één van de drie snapshots die je gemaakt hebt. Grappig genoeg heb je nu een echte Git historie die je kunt bekijken met het `git log` commando, als je dat op de SHA-1 van de laatste commit uitvoert:
 
 	$ git log --stat 1a410e
 	commit 1a410efbd13591db07496601ebc7a059dd55cfe9
@@ -225,7 +225,7 @@ Ieder van de drie commit objecten wijst naar één van de drie snapshots die je
 	 test.txt |    1 +
 	 1 files changed, 1 insertions(+), 0 deletions(-)
 
-Verbazingwekkend. Je hebt zojuist de lagere operaties uitgevoerd om een Git history op te bouwen, zonder één van de front ends te gebruiken. Dit is in essentie wat Git doet als je de `git add` en `git commit` commando's uitvoert – het slaat de blobs voor de gewijzigde bestanden op, ververst de index, schrijft de bomen weg, en schrijft commit objecten die de bovenste bomen en commits refereren die vlak voor ze kwamen. Deze drie hoofd Git-objecten – de blob, de boom en de commit – worden in eerste instantie als aparte bestanden opgeslagen in je `.git/objects` map. Hier zijn alle objecten die nu in de voorbeeld map staan, voorzien van commentaar met wat ze bevatten:
+Verbazingwekkend. Je hebt zojuist de lagere operaties uitgevoerd om een Git history op te bouwen, zonder één van de front ends te gebruiken. Dit is in essentie wat Git doet als je de `git add` en `git commit` commando's uitvoert: het slaat de blobs voor de gewijzigde bestanden op, ververst de index, schrijft de trees weg, en schrijft commit objecten die de bovenste trees en commits refereren die vlak voor ze kwamen. Deze drie hoofd Git-objecten – de blob, de tree en de commit – worden in eerste instantie als aparte bestanden opgeslagen in je `.git/objects` directory. Hier zijn alle objecten die nu in de voorbeeld directory staan, voorzien van commentaar met wat ze bevatten:
 
 	$ find .git/objects -type f
 	.git/objects/01/55eb4229851634a0f03eb265b69f5a2d56f341 # tree 2
@@ -242,22 +242,22 @@ Verbazingwekkend. Je hebt zojuist de lagere operaties uitgevoerd om een Git hist
 Als je alle interne verwijzingen volgt, krijg je een object-graaf die er uitzien zoals Figuur 9-3.
 
 Insert 18333fig0903.png
-Figuur 9-3. Alle objecten in je Git map.
+Figuur 9-3. Alle objecten in je Git directory.
 
 ### Object opslag ###
 
-Ik vertelde eerder dat er een kop wordt opgeslagen bij de inhoud. Laten we eens een minuutje kijken naar hoe Git zijn objecten opslaat. Je zult zien hoe je interactief een blob object opslaat – in dit geval de tekst "what is up, doc?" – in de Ruby scripttaal. Je kunt de interactieve Ruby modus starten met het `irb` commando:
+Ik vertelde eerder dat er een kop wordt opgeslagen bij de inhoud. Laten we eens even kijken naar hoe Git zijn objecten opslaat. Je zult zien hoe je interactief een blob object opslaat, in dit geval de tekst "what is up, doc?", in de Ruby scripttaal. Je kunt de interactieve Ruby modus starten met het `irb` commando:
 
 	$ irb
 	>> content = "what is up, doc?"
 	=> "what is up, doc?"
 
-Git construeert een kop, die begint met het type van het object, in dit geval een blob. Daarna voegt het een spatie toe, gevolgd door de grootte van de inhoud en als laatste een null byte:
+Git stelt een kop samen die begint met het type van het object, in dit geval een blob. Daarna voegt het een spatie toe, gevolgd door de grootte van de inhoud en als laatste een null byte:
 
 	>> header = "blob #{content.length}\0"
 	=> "blob 16\000"
 
-Git voegt de kop en de originele inhoud samen, en berekent vervolgens de SHA-1 checksum van die nieuwe inhoud. Je kunt de SHA-1 waarde van een regel tekst in Ruby berekenen door de SHA1 verwerkingsbibliotheek op te nemen met het `require` commando en dan `Digest::SHA1.hexdigest()` aan te roepen met de tekst:
+Git voegt de kop en de originele inhoud samen en berekent vervolgens de SHA-1 checksum van die nieuwe inhoud. Je kunt de SHA-1 waarde van een regel tekst in Ruby berekenen door de SHA1 verwerkingsbibliotheek op te nemen met het `require` commando en dan `Digest::SHA1.hexdigest()` aan te roepen met de tekst:
 
 	>> store = header + content
 	=> "blob 16\000what is up, doc?"
@@ -273,7 +273,7 @@ Git comprimeert de nieuwe inhoud met zlib, wat je in Ruby kunt doen met de zlib
 	>> zlib_content = Zlib::Deflate.deflate(store)
 	=> "x\234K\312\311OR04c(\317H,Q\310,V(-\320QH\311O\266\a\000_\034\a\235"
 
-Als laatste schrijf je je zlib-gecomprimeerde inhoud naar een object op de schijf. Je zult het pad van het object dat je wilt wegschrijven moeten bepalen (de eerste twee karakters van de SHA-1 waarde zijn de submap naam, en de laatste 38 karakters zijn de bestandsnaam in die map). In Ruby kun je de `FileUtils.mkdir_p()` functie gebruiken om de submap aan te maken als hij nog niet bestaat. Daarna open je het bestand met `File.open()` en schrijft de eerder met zlib gecomprimeerde inhoud in het bestand met een aanroep van `write()` op het resulterende bestands-aangrijpingspunt.
+Als laatste schrijf je de zlib-gecomprimeerde inhoud naar een object op de schijf. Je bepaalt het pad van het object dat je wilt wegschrijven (de eerste twee karakters van de SHA-1 waarde zijn de subdirectory naam, en de laatste 38 karakters zijn de bestandsnaam in die directory). In Ruby kun je de `FileUtils.mkdir_p()` functie gebruiken om de subdirectory aan te maken als hij nog niet bestaat. Daarna open je het bestand met `File.open()` en schrijft de eerder met zlib gecomprimeerde inhoud in het bestand met een aanroep van `write()` op het resulterende bestands-aangrijpingspunt (file handle).
 
 	>> path = '.git/objects/' + sha1[0,2] + '/' + sha1[2,38]
 	=> ".git/objects/bd/9dbf5aae1a3862dd1526723246b20206e5fc37"
@@ -284,13 +284,13 @@ Als laatste schrijf je je zlib-gecomprimeerde inhoud naar een object op de schij
 	>> File.open(path, 'w') { |f| f.write zlib_content }
 	=> 32
 
-Dat is het – je hebt nu een geldig Git blob object aangemaakt. Alle Git objecten zijn op dezelfde manier opgeslagen, alleen de types verschillen – in plaats van de tekst blob, zal de kop beginnen met commit of tree. En alhoewel de blob inhoud vrijwel alles kan zijn, hebben de commit en boom inhoud een zeer specifiek formaat.
+Dat is alles: je hebt nu een geldig Git blob object aangemaakt. Alle Git objecten zijn op dezelfde manier opgeslagen, alleen de types verschillen. In plaats van de tekst blob, zal de kop beginnen met commit of tree. En alhoewel de blob inhoud vrijwel alles kan zijn, hebben de commit en tree inhoud een zeer specifiek formaat.
 
 ## Git referenties ##
 
-Je kunt zoiets als `git log 1a410e` uitvoeren om door je hele geschiedenis te kijken, maar je moet nog steeds onthouden dat `1a410e` de laatste commit is om die geschiedenis te doorlopen en alle objecten te vinden. Je hebt een bestand nodig waarin je de SHA-1 waarde als een eenvoudige naam kunt opslaan, zodat je die als wijzer kunt gebruiken in plaats van de rauwe SHA-1 waarde.
+Je kunt zoiets als `git log 1a410e` uitvoeren om door je hele geschiedenis te kijken, maar je moet nog steeds onthouden dat `1a410e` de laatste commit is om die geschiedenis te doorlopen en alle objecten te vinden. Je hebt een bestand nodig waarin je de SHA-1 waarde als een eenvoudige naam kunt opslaan, zodat je die als wijzer kunt gebruiken in plaats van de kale SHA-1 waarde.
 
-In Git worden deze "referenties" of "refs" genoemd; je kunt de bestanden die de SHA-1 waarden bevatten vinden in de `.git/refs` map. In het huidige project bevat deze map geen bestanden, maar het bevat wel een eenvoudige structuur:
+In Git worden deze "referenties" of "refs" genoemd; je kunt de bestanden die de SHA-1 waarden bevatten vinden in de `.git/refs` directory. In het huidige project bevat deze directory geen bestanden, maar het bevat wel een eenvoudige structuur:
 
 	$ find .git/refs
 	.git/refs
@@ -299,18 +299,18 @@ In Git worden deze "referenties" of "refs" genoemd; je kunt de bestanden die de
 	$ find .git/refs -type f
 	$
 
-Om een nieuwe referentie aan te maken, die je zal helpen herinneren waar je laatste commit is, kun je technisch zoiets eenvoudigs als dit doen:
+Om een nieuwe referentie aan te maken,die je zal helpen herinneren waar je laatste commit is, kun je technisch zoiets eenvoudigs als dit doen:
 
 	$ echo "1a410efbd13591db07496601ebc7a059dd55cfe9" > .git/refs/heads/master
 
-Nu kun je de head referentie, die je zojuist hebt aangemaakt, gebruiken in je Git commando's, in plaats van de SHA-1 waarde:
+Nu kan je de head referentie die je zojuist hebt aangemaakt gebruiken in je Git commando's, in plaats van de SHA-1 waarde:
 
 	$ git log --pretty=oneline  master
 	1a410efbd13591db07496601ebc7a059dd55cfe9 third commit
 	cac0cab538b970a37ea1e769cbbde608743bc96d second commit
 	fdf4fc3344e67ab068f836878b6c4951e3b15f3d first commit
 
-Je wordt niet aangemoedigd om de referentie bestanden direct aan te passen. Git levert een veiliger commando mee om dit te doen als je een referentie wilt aanpassen, genaamd `update-ref`:
+Het wordt niet aangeraden om de referentie bestanden direct aan te passen. Git levert een veiliger commando mee om dit te doen als je een referentie wilt aanpassen, genaamd `update-ref`:
 
 	$ git update-ref refs/heads/master 1a410efbd13591db07496601ebc7a059dd55cfe9
 
@@ -318,7 +318,7 @@ Dat is eigenlijk wat een branch in Git is: een eenvoudige wijzer of referentie n
 
 	$ git update-ref refs/heads/test cac0ca
 
-Je branch zal alleen werk bevatten vanaf die commit en verder:
+Je branch zal alleen werk bevatten vanaf die commit en eerder:
 
 	$ git log --pretty=oneline test
 	cac0cab538b970a37ea1e769cbbde608743bc96d second commit
@@ -327,13 +327,13 @@ Je branch zal alleen werk bevatten vanaf die commit en verder:
 Nu ziet je Git gegevensbank er conceptueel ongeveer uit zoals in Figuur 9-4.
 
 Insert 18333fig0904.png
-Figuur 9-4. Git map objecten met branch head referenties erbij.
+Figuur 9-4. Git directory objecten met branch head referenties erbij.
 
-Als je commando's zoals `git branch (branchnaam)` uitvoert, voert Git eigenlijk dat `update-ref` commando uit om de SHA-1 van de laatste commit van de branch waarop je zit, toe te voegen aan welke referentie je ook wil maken.
+Als je commando's zoals `git branch (branchnaam)` uitvoert, voert Git eigenlijk dat `update-ref` commando uit om de SHA-1 van de laatste commit van de branch waarop je zit toe te voegen aan welke referentie je ook wil maken.
 
 ### De HEAD ###
 
-De vraag is nu, als je `git branch (branchnaam)` uitvoert, hoe weet Git de SHA-1 van de laatste commit? Het antwoord is het HEAD bestand. Het HEAD bestand is een symbolische referentie naar de branch waar je momenteel op zit. Met symbolische referentie bedoel ik dat, in tegenstelling tot een normale referentie, het over het algemeen geen SHA-1 waarde bevat maar een pointer naar een andere referentie. Als je naar het bestand kijkt, zul je normaal gesproken zoiets als dit zien:
+De vraag is nu: als je `git branch (branchnaam)` uitvoert, hoe weet Git de SHA-1 van de laatste commit? Het antwoord is het HEAD bestand. Het HEAD bestand is een symbolische referentie naar de branch waar je momenteel op zit. Met symbolische referentie bedoel ik dat, in tegenstelling tot een normale referentie, het over het algemeen geen SHA-1 waarde bevat maar een verwijzing naar een andere referentie. Als je naar het bestand kijkt, zul je normaal gesproken zoiets als dit zien:
 
 	$ cat .git/HEAD
 	ref: refs/heads/master
@@ -343,7 +343,7 @@ Als je `git checkout test` uitvoert, zal Git het bestand vernieuwen zodat het er
 	$ cat .git/HEAD
 	ref: refs/heads/test
 
-Als je `git commit` uitvoert, wordt het commit object gecreëerd, waarbij de ouder van dat commit object gezet wordt naar welke SHA-1 waarde de referentie in HEAD ook wijst.
+Als je `git commit` uitvoert wordt het commit object gecreëerd, waarbij de ouder van die commit object gezet wordt op de SHA-1 waarde van de referentie waar de HEAD op dat moment naar verwijst.
 
 Je kunt dit bestand ook handmatig aanpassen, maar ook daar bestaat weer een veiliger commando voor: `symbolic-ref`. Je kunt de waarde van je HEAD lezen via dit commando:
 
@@ -363,13 +363,13 @@ Je kunt geen symbolische referentie instellen die buiten de refs stijl valt:
 
 ### Tags ###
 
-Je bent zojuist door drie hoofdobject types van Git gegaan, maar er bestaat een vierde. Het tag object komt veel overeen met een commit object – het bevat een tagger, een datum, een bericht, en een pointer. Het grootste verschil is dat een tag object naar een commit wijst in plaats van een boom. Het is vergelijkbaar met een branch referentie, maar het beweegt nooit – het zal altijd naar dezelfde commit wijzen, maar geeft het een vriendelijker naam.
+We hebben zojuist de drie hoofdobject types van Git behandeld, maar er bestaat een vierde. Het tag object lijkt erg op een commit object: het bevat een tagger, een datum, een bericht en een pointer. Het grootste verschil is dat een tag object naar een commit wijst in plaats van een tree. Het is vergelijkbaar met een branch referentie, maar het beweegt nooit. Het zal altijd naar dezelfde commit wijzen, maar geeft het een vriendelijker naam.
 
 Zoals besproken in hoofdstuk 2, zijn er twee soorten tags: beschreven en lichtgewicht. Je kunt een lichtgewicht tag maken door zoiets als dit uit te voeren:
 
 	$ git update-ref refs/tags/v1.0 cac0cab538b970a37ea1e769cbbde608743bc96d
 
-Dat is wat een lichtgewicht tag is – een branch die nooit beweegt. Een beschreven tag is echter complexer. Als je een beschreven tag aanmaakt, creëert Git een tag object en schrijft een referentie die daar naar wijst, in plaats van direct naar de commit. Je kunt dit zien door een beschreven tag aan te maken (`-a` specificeert dat het een beschreven tag is):
+Dat is wat een lichtgewicht tag is: een branch die nooit beweegt. Een beschreven tag is echter ingewikkelder. Als je een beschreven tag aanmaakt, creëert Git een tag object en schrijft een referentie die daar naar wijst in plaats van direct naar de commit. Je kunt dit zien door een beschreven tag aan te maken (`-a` specificeert dat het een beschreven tag is):
 
 	$ git tag -a v1.1 1a410efbd13591db07496601ebc7a059dd55cfe9 –m 'test tag'
 
@@ -388,15 +388,15 @@ Voer nu het `cat-file` commando uit op die SHA-1 waarde:
 
 	test tag
 
-Zie dat de object regel wijst naar de SHA-1 waarde die je getagged hebt. Zie ook dat het niet naar een commit hoeft te wijzen: je kunt ieder Git object een tag geven. In de Git broncode bijvoorbeeld, heeft de maintainer zijn publieke GPG sleutel als een blob object toegevoegd en het een tag gegeven. Je kunt de publieke sleutel bekijken door dit uit te voeren
+Merk op dat de object regel wijst naar de SHA-1 waarde die je getagged hebt. Merk ook op dat het niet naar een commit hoeft te wijzen; je kunt ieder Git object een tag geven. In de Git broncode bijvoorbeeld, heeft de maintainer zijn publieke GPG sleutel als een blob object toegevoegd en het een tag gegeven. Je kunt de publieke sleutel bekijken door dit uit te voeren
 
 	$ git cat-file blob junio-gpg-pub
 
-in de Git broncode. De Linux kernel heeft ook een non-commit-wijzend tag object – het eerste tag object wijst naar de eerste tree van de import van de broncode.
+in de Git broncode. De Linux kernel heeft ook een non-commit-verwijzend tag object – het eerste tag object wijst naar de eerste tree van de import van de broncode.
 
 ### Remotes ###
 
-Het derde soort referentie dat je zult zien is een remote referentie. Als je een remote toevoegt en er naar pusht, slaat Git de laatste waarde van iedere branch op die je gepusht hebt naar die remote in de `refs/remotes` map. Bijvoorbeeld, je kunt een remote genaamd `origin` toevoegen en je master branch hier naar pushen:
+Het derde soort referentie dat je zult zien is een remote referentie. Als je een remote toevoegt en er naar pushed, slaat Git de laatste waarde van iedere branch op die je gepushed hebt naar die remote in de `refs/remotes` directory. Bijvoorbeeld, je kunt een remote genaamd `origin` toevoegen en je master branch hier naar pushen:
 
 	$ git remote add origin git@github.com:schacon/simplegit-progit.git
 	$ git push origin master
@@ -416,7 +416,7 @@ Remote referenties verschillen hoofdzakelijk van branches (`refs/heads` referent
 
 ## Packfiles ##
 
-Laten we eens terug gaan naar de object-databank van je test Git repository. Op dit punt heb je 11 objecten – 4 blobs, 3 bomen, 3 commits en 1 tag:
+Laten we eens terug gaan naar de object-databank van je test Git repository. Op dit punt heb je 11 objecten – 4 blobs, 3 trees, 3 commits en 1 tag:
 
 	$ find .git/objects -type f
 	.git/objects/01/55eb4229851634a0f03eb265b69f5a2d56f341 # tree 2
@@ -431,7 +431,7 @@ Laten we eens terug gaan naar de object-databank van je test Git repository. Op
 	.git/objects/fa/49b077972391ad58037050f2a75f74e3671e92 # new.txt
 	.git/objects/fd/f4fc3344e67ab068f836878b6c4951e3b15f3d # commit 1
 
-Git comprimeert de inhoud van deze bestanden met zlib, en je slaat maar weinig op, dus nemen deze bestanden samen maar 925 bytes in beslag. Je zult nu wat grotere inhoud toevoegen aan het repository om een interessante eigenschap van Git te demonstreren. Voeg het repo.rb bestand toe van de Grit bibliotheek waaraan je eerder gewerkt hebt – dit is een broncode bestand van ongeveer 12K groot:
+Git comprimeert de inhoud van deze bestanden met zlib en je slaat maar weinig op, dus nemen deze bestanden samen maar 925 bytes in beslag. Je zult nu wat grotere inhoud toevoegen aan het repository om een interessante eigenschap van Git te demonstreren. Voeg het repo.rb bestand toe van de Grit bibliotheek waaraan je eerder gewerkt hebt, dit is een broncode bestand van ongeveer 12K groot:
 
 	$ curl http://github.com/mojombo/grit/raw/master/lib/grit/repo.rb > repo.rb
 	$ git add repo.rb
@@ -442,40 +442,40 @@ Git comprimeert de inhoud van deze bestanden met zlib, en je slaat maar weinig o
 	 create mode 100644 repo.rb
 	 rewrite test.txt (100%)
 
-Als je naar de resulterende boom kijkt, kun je zien welke SHA-1 waarde je repo.rb gekregen heeft voor het blob object:
+Als je naar de resulterende tree kijkt, kun je zien welke SHA-1 waarde repo.rb gekregen heeft voor het blob object:
 
 	$ git cat-file -p master^{tree}
 	100644 blob fa49b077972391ad58037050f2a75f74e3671e92      new.txt
 	100644 blob 9bc1dc421dcd51b4ac296e3e5b6e2a99cf44391e      repo.rb
 	100644 blob e3f094f522629ae358806b17daf78246c27c007b      test.txt
 
-Je kunt dan het `git cat-file` commando gebruiken om te zien hoe groot dat object is:
+Dan controleer je hoe groot het object is op jouw schijf:
 
-	$ git cat-file -s 9bc1dc421dcd51b4ac296e3e5b6e2a99cf44391e
-	12898
+	$ du -b .git/objects/9b/c1dc421dcd51b4ac296e3e5b6e2a99cf44391e
+	4102	.git/objects/9b/c1dc421dcd51b4ac296e3e5b6e2a99cf44391e
 
-Pas het bestand nu eens een beetje aan, en kijk wat er gebeurd:
+Pas het bestand nu eens een beetje aan, en kijk wat er gebeurt:
 
 	$ echo '# testing' >> repo.rb
 	$ git commit -am 'modified repo a bit'
 	[master ab1afef] modified repo a bit
 	 1 files changed, 1 insertions(+), 0 deletions(-)
 
-Bekijk de boom die door de commit gemaakt is, en je zult iets interessants zien:
+Bekijk de tree die door de commit gemaakt is, en je zult iets interessants zien:
 
 	$ git cat-file -p master^{tree}
 	100644 blob fa49b077972391ad58037050f2a75f74e3671e92      new.txt
 	100644 blob 05408d195263d853f09dca71d55116663690c27c      repo.rb
 	100644 blob e3f094f522629ae358806b17daf78246c27c007b      test.txt
 
-De blob is nu een andere blob, wat betekent dat alhoewel je slechts een enkele regel aan het eind van een bestand van 400 regels toegevoegd hebt, Git die nieuwe inhoud als een compleet nieuw object opgeslagen heeft:
+De blob is nu een andere blob, wat betekent dat, alhoewel je slechts een enkele regel aan het eind van een bestand van 400 regels toegevoegd hebt, Git die nieuwe inhoud als een compleet nieuw object opgeslagen heeft:
 
-	$ git cat-file -s 05408d195263d853f09dca71d55116663690c27c
-	12908
+	$ du -b .git/objects/05/408d195263d853f09dca71d55116663690c27c
+	4109	.git/objects/05/408d195263d853f09dca71d55116663690c27c
 
-Je hebt nu twee vrijwel identieke 12K grote objecten op je harde schijf. Zou het niet fijn zijn als Git één van de twee volledig op kon slaan, en het tweede object slechts als delta tussen die en de eerste?
+Je hebt nu twee vrijwel identieke 12K grote objecten op je harde schijf. Zou het niet prettig zijn als Git één van de twee volledig op kon slaan, en het tweede object slechts als delta tussen die en de eerste?
 
-Het blijkt dat dat kan. Het initiële formaat waarin Git objecten opslaat op de harde schijf wordt een los object formaat genoemd. Maar, eens in de zoveel tijd pakt Git een aantal van die objecten in een enkel binair bestand wat een packfile genoemd wordt, om wat ruimte te besparen en efficiënter te zijn. Git doet dit als je teveel losse objecten rond hebt slingeren, als je het `git gc` commando handmatig uitvoert, of als je naar een remote server pusht. Om te zien wat er gebeurd, kun je Git handmatig vragen om de objecten in te pakken met het `git gc` commando:
+Dat kan dus. Het initiële formaat waarin Git objecten opslaat op de harde schijf wordt een los ('loose') object formaat genoemd. Maar, eens in de zoveel tijd pakt Git een aantal van die objecten samen in een enkel binair bestand wat een packfile genoemd wordt, om ruimte te besparen en efficiënter te zijn. Git doet dit als je teveel losse objecten rond hebt slingeren als je het `git gc` commando handmatig uitvoert, of als je naar een remote server pushed. Om te zien wat er gebeurt, kun je Git handmatig vragen om de objecten in te pakken met het `git gc` commando:
 
 	$ git gc
 	Counting objects: 17, done.
@@ -484,7 +484,7 @@ Het blijkt dat dat kan. Het initiële formaat waarin Git objecten opslaat op de
 	Writing objects: 100% (17/17), done.
 	Total 17 (delta 1), reused 10 (delta 0)
 
-Als je in je objecten map kijkt, zul je zien dat de meeste objecten verdwenen zijn, en er een aantal nieuwe bestanden verschenen zijn:
+Als je in je objecten directory kijkt, zul je zien dat de meeste objecten verdwenen zijn, en er een aantal nieuwe bestanden verschenen zijn:
 
 	$ find .git/objects -type f
 	.git/objects/71/08f7ecb345ee9d0084193f147cdad4d2998293
@@ -493,11 +493,11 @@ Als je in je objecten map kijkt, zul je zien dat de meeste objecten verdwenen zi
 	.git/objects/pack/pack-7a16e4488ae40c7d2bc56ea2bd43e25212a66c45.idx
 	.git/objects/pack/pack-7a16e4488ae40c7d2bc56ea2bd43e25212a66c45.pack
 
-De objecten die overgebleven zijn, zijn de blobs waarnaar geen enkel commit wijst – in dit geval zijn het de "what is up, doc?" en de "test content" voorbeeld-blobs die je eerder aangemaakt hebt. Omdat je ze nooit aan een commit toegevoegd hebt, worden ze beschouwd als 'rondslingerend' en worden ze niet in je nieuwe packfile ingepakt.
+De objecten die overgebleven zijn, zijn de blobs waarnaar geen enkel commit wijst; in dit geval zijn het de "what is up, doc?" en de "test content" voorbeeld-blobs die je eerder aangemaakt hebt. Omdat je ze nooit aan een commit toegevoegd hebt, worden ze beschouwd als rondslingerend ('dangling') en niet in je nieuwe packfile ingepakt.
 
-De andere bestanden zijn je nieuwe packfile en een index. De packfile is een enkel bestand dat de inhoud bevat van alle objecten die van je bestandssysteem verwijderd zijn. De index is een bestand dat offsets binnen de packfile bevat, zodat je snel naar een specifiek object kunt zoeken. Wat cool is, is dat alhoewel de objecten op de harde schijf voordat je `gc` aanriep samen zo'n 12K groot waren, is de nieuwe packfile slechts 6K. Je hebt je schijfgebruik gehalveerd door je bestanden in te pakken.
+De andere bestanden zijn het nieuwe packbestand en een index. Het packbestand is een enkel bestand dat de inhoud bevat van alle objecten die van je bestandssysteem verwijderd zijn. De index is een bestand dat offsets binnen de packfile bevat, zodat je snel naar een specifiek object kunt zoeken. Wat stoer is, is dat waar de objecten op de harde schijf voordat je `gc` aanriep samen zo'n 8K groot waren, de nieuwe packfile slechts 4K groot is. Je hebt je schijfgebruik gehalveerd door je bestanden in te pakken.
 
-Hoe doet Git dit? Als Git objecten inpakt, zoekt het naar bestanden die gelijk genaamd en in grootte zijn, en slaat slechts de delta's van één versie van het bestand naar de volgende op. Je kunt in de packfile kijken en zien wat Git gedaan heeft om ruimte te besparen. Het `git verify-pack` sanitaire voorzieningen commando stelt je in staat om te zien wat er ingepakt is:
+Hoe doet Git dit? Als Git objecten inpakt, zoekt het naar bestanden die qua naam en grootte gelijk zijn, en slaat slechts de delta's van de ene versie van het bestand naar de volgende op. Je kunt in de packfile kijken en zien wat Git gedaan heeft om ruimte te besparen. Het `git verify-pack` plumbing commando stelt je in staat om te zien wat er ingepakt is:
 
 	$ git verify-pack -v \
 	  .git/objects/pack/pack-7a16e4488ae40c7d2bc56ea2bd43e25212a66c45.idx
@@ -522,26 +522,26 @@ Hoe doet Git dit? Als Git objecten inpakt, zoekt het naar bestanden die gelijk g
 	chain length = 1: 1 object
 	pack-7a16e4488ae40c7d2bc56ea2bd43e25212a66c45.pack: ok
 
-Hier refereert de `9bc1d` blob, wat als je je dat herinnert de eerste versie is van je repo.rb bestand, aan de `05408` blob, wat de tweede versie was van het bestand. De derde kolom in de uitvoer is e grootte van het object in het pakket, zodat je kunt zien dat `05408` 12K van het bestand in beslag neemt maar dat `9bc1d` slechts 7 bytes in beslag neemt. Wat ook interessant is, is dat de tweede versie van het bestand degene is die intact opgeslagen wordt, terwijl de originele versie als delta opgeslagen wordt – dit is zo gedaan omdat het waarschijnlijker is dat je snellere toegang nodig hebt tot de meest recente versie van het bestand.
+Hier refereert de `9bc1d` blob wat, als je dat nog kunt herinneren, de eerste versie is van je repo.rb bestand, aan de `05408` blob, wat de tweede versie was van het bestand. De derde kolom in de uitvoer is de grootte van het object in het pakket, zodat je kunt zien dat `05408` 12K van het bestand in beslag neemt maar dat `9bc1d` slechts 7 bytes in beslag neemt. Wat ook interessant is, is dat de tweede versie van het bestand degene is die intact opgeslagen wordt, terwijl de originele versie als delta opgeslagen wordt. Dit is zo gedaan omdat het aannemelijk is dat je snellere toegang nodig hebt tot de meest recente versie van het bestand.
 
-Het fijnste van dit alles is, is dat het op ieder gewenst moment opnieuw ingepakt kan worden. Git zal op z'n tijd je databank automatisch opnieuw inpakken, waarmee het altijd meer ruimte wil besparen. Je kunt ook handmatig opnieuw inpakken op ieder tijdstip, door `git gc` met de hand uit te voeren.
+Het echt prettige van dit alles is, dat het op ieder gewenst moment opnieuw ingepakt kan worden. Git zal op gezette tijden je databank automatisch opnieuw inpakken, waarmee het altijd meer ruimte wil besparen. Je kunt ook handmatig opnieuw inpakken op elk gewenst tijdstip, door `git gc` met de hand uit te voeren.
 
 ## De refspec ##
 
-Door dit boek heen heb je eenvoudige verwijzingen van remote branches naar lokale referenties gebruikt; maar ze kunnen complexer zijn.
+Door dit boek heen heb je eenvoudige verwijzingen van remote branches naar lokale referenties gebruikt, maar ze kunnen ingewikkelder zijn.
 Stel dat je een remote zoals dit toevoegt:
 
 	$ git remote add origin git@github.com:schacon/simplegit-progit.git
 
-Dit voegt een sectie aan je `.git/config` bestand toe, wat de naam van de remote (`origin`) specificeert, de URL van de remote repository, en de refspec die nodig is om te fetchen:
+Dit voegt een sectie toe aan je `.git/config` bestand, met de naam van de remote (`origin`), de URL van de remote repository, en de refspec die nodig is om te fetchen:
 
 	[remote "origin"]
 	       url = git@github.com:schacon/simplegit-progit.git
 	       fetch = +refs/heads/*:refs/remotes/origin/*
 
-Het formaat van de refspec is een optionele `+`, gevolgd door `<src>:<dst>`, waarbij `<src>` het patroon voor referenties aan de remote kant is, en `<dst>` is de locatie waar die referenties lokaal geschreven worden. De `+` verteld Git om de referentie zelfs te vernieuwen als het geen fast-forward is.
+Het formaat van de refspec is een optionele `+`, gevolgd door `<src>:<dst>`, waarbij `<src>` het patroon voor referenties aan de remote kant is, en `<dst>` is de locatie waar die referenties lokaal geschreven zullen worden. De `+` vertelt Git om de referentie zelfs te vernieuwen als het geen fast-forward is.
 
-In het standaard geval dat automatisch geschreven wordt door een `git remote add` commando, haalt Git alle referenties onder `refs/heads/` van de server en schrijft ze lokaal naar `refs/remotes/origin/`. Dus als er een `master` branch op de server bestaat, kun je de log van die branch lokaal benaderen via
+In het standaard geval dat automatisch geschreven wordt door een `git remote add` commando, haalt Git alle referenties onder `refs/heads/` van de server op en schrijft ze lokaal naar `refs/remotes/origin/`. Dus als er een `master` branch op de server bestaat, kun je de log van die branch lokaal benaderen via
 
 	$ git log origin/master
 	$ git log remotes/origin/master
@@ -553,7 +553,7 @@ Als je wilt dat Git alleen de `master` branch pulled, en niet alle andere branch
 
 	fetch = +refs/heads/master:refs/remotes/origin/master
 
-Dit is alleen de standaard refspec voor `git fetch` voor die remote. Als je iets alleen eenmalig wilt doen, kun je de refspec ook op de commandoregel specificeren. Om de `master` branch op de remote naar de lokale `origin/mymaster` te pullen, kun je dit uitvoeren
+Dit is alleen de standaard refspec voor `git fetch` voor die remote. Als je iets echt eenmalig wilt doen, kun je de refspec ook op de commandoregel specificeren. Om de `master` branch op de remote naar de lokale `origin/mymaster` te pullen, kun je dit uitvoeren
 
 	$ git fetch origin master:refs/remotes/origin/mymaster
 
@@ -565,9 +565,9 @@ Je kunt ook meerdere refspecs specificeren. Met de commandoregel kun je meerdere
 	 ! [rejected]        master     -> origin/mymaster  (non fast forward)
 	 * [new branch]      topic      -> origin/topic
 
-In dit geval wordt de pull van de master branch geweigerd, omdat het geen fast-forward referentie is. Je kunt dat teniet doen door de `+` voor de refspec te zetten.
+In dit geval werd de pull van de master branch geweigerd, omdat het geen fast-forward referentie is. Je kunt dat teniet doen door de `+` voor de refspec te zetten.
 
-Je kun ook meerdere refspecs voor het fetchen specificeren in je configuratie bestand. Als je altijd de master en experiment branches wilt fetchen, voeg dan twee regels toe:
+Je kun ook meerdere refspecs voor het fetchen specificeren in je configuratie bestand. Als je altijd de master en experiment branches wilt fetchen, voeg je twee regels toe:
 
 	[remote "origin"]
 	       url = git@github.com:schacon/simplegit-progit.git
@@ -578,18 +578,18 @@ Je kunt geen gedeeltelijke globs in het patroon gebruiken, dus het volgende zou
 
 	fetch = +refs/heads/qa*:refs/remotes/origin/qa*
 
-Maar je kunt wel naamruimtes gebruiken om zoiets voor elkaar te krijgen. Als je een QA team hebt dat naar een serie branches pusht, en je wilt de master branch en alle QA team branches hebben, maar niets anders, kun je een configuratie sectie zoals dit gebruiken:
+Maar je kunt wel naamruimtes ('namespaces') gebruiken om zoiets voor elkaar te krijgen. Als je een QA team hebt dat naar een serie branches pushed, en je wilt de master branch en alle QA team branches hebben, maar niets anders, kun je een configuratie sectie zoals dit gebruiken:
 
 	[remote "origin"]
 	       url = git@github.com:schacon/simplegit-progit.git
 	       fetch = +refs/heads/master:refs/remotes/origin/master
 	       fetch = +refs/heads/qa/*:refs/remotes/origin/qa/*
 
-Als je een ingewikkeld werkproces hebt waarbij het QA team branches pusht, ontwikkelaars branches pushen, en integratie teams pushen en samenwerken op remote branches, kun je ze op deze manier eenvoudig in naamruimten stoppen.
+Als je een ingewikkelde workflow hebt waarbij het QA team branches pushed, ontwikkelaars branches pushen, en integratie teams op remote branches pushen en samenwerken, kun je ze op deze manier eenvoudig in namespaces onderverdelen.
 
 ### Refspecs pushen ###
 
-Het is fijn dat je op die manier referenties in naamruimten kunt fetchen, maar hoe krijgt het QA team in de eerste plaats al hun branches in een `qa/` naamruimte? Je krijgt dat voor elkaar door refspecs te gebruiken om mee te pushen.
+Het is prettig dat je op die manier referenties met namespaces kunt fetchen, maar hoe krijgt het QA team om te beginnen al hun branches in een `qa/` namespace? Je krijgt dat voor elkaar door refspecs te gebruiken voor het pushen.
 
 Als het QA team hun `master` branch naar `qa/master` op de remote server wil pushen, kunnen ze dit uitvoeren
 
@@ -610,35 +610,35 @@ Je kunt de refspec ook gebruiken om referenties te verwijderen van de remote ser
 
 	$ git push origin :topic
 
-Omdat de refspec `<src>:<dst>` is, verteld het weglaten van het `<src>` gedeelte in feite dat de onderwerp branch op de remote niks is, wat het verwijderd.
+Omdat de refspec `<src>:<dst>` is wordt, door het weglaten van het `<src>` gedeelte, in feite verteld dat de onderwerp branch op de remote niets is, waardoor het verwijderd wordt.
 
 ## Overdracht protocollen ##
 
-Git kan gegevens tussen twee repositories hoofdzakelijk overdragen op twee manieren: via HTTP en via de zogenaamde slimme protocollen die in de `file://`, `ssh://` en `git://` overdrachten gebruikt worden. Deze sectie zal laten zien hoe deze hoofdprotocollen werken.
+Git draagt gegevens tussen twee repositories hoofdzakelijk op twee manieren over: via HTTP en via de zogenaamde slimme protocollen die in de `file://`, `ssh://` en `git://` overdrachten gebruikt worden. Deze paragraaf zal laten zien hoe deze hoofdprotocollen werken.
 
 ### Het domme Protocol ###
 
-Naar Git overdracht over HTTP wordt vaak gerefereerd als het domme protocol, omdat het geen Git-specifieke code vereist op de server gedurende het overdrachtsproces. Het fetch proces is een reeks van GET verzoeken, waarbij de client de opmaak van het Git repository van de server kan overnemen. Laten we het `http-fetch` proces eens volgen voor de simplegit bibliotheek:
+Naar Git-overdracht via HTTP wordt vaak gerefereerd als het domme protocol, omdat het geen Git-specifieke code vereist op de server tijdens het overdrachtsproces. Het fetch proces is een reeks van GET verzoeken, waarbij de client de indeling van het Git repository van de server kent. Laten we het `http-fetch` proces eens volgen voor de simplegit bibliotheek:
 
 	$ git clone http://github.com/schacon/simplegit-progit.git
 
-Het eerste wat dit commando doet is het `info/refs` bestand pullen. Dit bestand wordt geschreven door het `update-server-info` commando, en dat is de reden waarom je dat als een `post-recieve` haak in moet stellen voordat de HTTP overdracht naar behoren werkt:
+Het eerste wat dit commando doet is het `info/refs` bestand pullen. Dit bestand wordt geschreven door het `update-server-info` commando, en dat is de reden waarom je dat als een `post-recieve` hook in moet stellen voordat de HTTP overdracht naar behoren werkt:
 
 	=> GET info/refs
 	ca82a6dff817ec66f44342007202690a93763949     refs/heads/master
 
-Nu heb je een lijst met de remote referenties en SHA's. Daarna kijk je naar wat de HEAD referentie is, zodat je weet wat je uit moet checken zodra je klaar bent:
+Nu heb je een lijst met de remote referenties en SHA's. Daarna kijk je naar de waarde van de HEAD referentie, zodat je weet wat je uit moet checken zodra je klaar bent:
 
 	=> GET HEAD
 	ref: refs/heads/master
 
 Je moet de `master` branch uitchecken zodra je het proces afgerond hebt.
-Op dit punt ben je klaar om het doorloop proces te starten. Omdat je startpunt het `ca82a6` commit object is dat je in het `info/refs` bestand zag, begin je met dit op te halen:
+Op dit punt ben je klaar om het proces doorlopen te starten. Omdat je startpunt het `ca82a6` commit object is dat je in het `info/refs` bestand zag, begin je met dit op te halen:
 
 	=> GET objects/ca/82a6dff817ec66f44342007202690a93763949
 	(179 bytes of binary data)
 
-Je krijgt een object terug – dat object staat in los formaat op de server, en je hebt het gehaald door een statisch HTTP GET verzoek. Je kunt het met zlib decomprimeren, de kop eraf halen, en naar de commit inhoud kijken:
+Je krijgt een object terug, dat object staat in los formaat op de server, en je hebt het gehaald met een statisch HTTP GET verzoek. Je kunt het met zlib decomprimeren, de kop eraf halen en naar de commit inhoud kijken:
 
 	$ git cat-file -p ca82a6dff817ec66f44342007202690a93763949
 	tree cfda3bf379e4f8dba8717dee55aab78aef7f4daf
@@ -648,37 +648,37 @@ Je krijgt een object terug – dat object staat in los formaat op de server, en
 
 	changed the version number
 
-Daarna heb je nog twee objecten op te halen – `cfda3b`, wat de boom is met inhoud waar de commit die je zojuist hebt opgehaald naar wijst; en `085bb3`, wat de ouder commit is:
+Daarna heb je nog twee objecten op te halen: `cfda3b`, wat de tree is met inhoud waar de commit die je zojuist hebt opgehaald naar wijst, en `085bb3`, wat de ouder commit is:
 
 	=> GET objects/08/5bb3bcb608e1e8451d4b2432f8ecbe6306e7e7
 	(179 bytes of data)
 
-Dat geeft je je volgende commit object. Pak het boom object:
+Dat geeft je het volgende commit object. Pak het tree object:
 
 	=> GET objects/cf/da3bf379e4f8dba8717dee55aab78aef7f4daf
 	(404 - Not Found)
 
-Oops – het ziet ernaar uit dat dat boom object niet in het losse formaat op de server bestaat, dus krijg je een 404 antwoord. Er zijn hiervoor een aantal redenen – het object kan in een ander repository staat, of het kan in een packfile in dit repository staat. Git gaat eerst naar de genoemde alternatieven kijken:
+Oeps, het ziet ernaar uit dat die tree object niet in het losse formaat op de server bestaat, dus krijg je een 404 antwoord. Er zijn hiervoor een aantal redenen: het object kan in een ander repository staat, of het kan in een packfile in dit repository staan. Git gaat eerst naar de benoemde alternatieven kijken:
 
 	=> GET objects/info/http-alternates
 	(empty file)
 
-Als dit een lijst met alternatieve URL's bevat, zal Git daar voor losse bestanden en packfiles gaan kijken – dit is een fijn mechanisme voor projecten die forks zijn van een ander zodat ze objecten kunnen delen op de schijf. Maar, omdat er in dit geval geen alternatieven vermeld staan, moet je object in een packfile zitten. Om te zien welke packfiles beschikbaar zijn op deze server, moet je het `objects/info/packs` bestand halen, wat een lijst hiervan bevat (ook gegenereerd door `update-server-info`):
+Als dit een lijst met alternatieve URL's bevat, zal Git daar voor losse bestanden en packfiles gaan kijken. Dit is een prettig mechanisme voor projecten die forks zijn van een ander zodat ze objecten kunnen delen op de schijf. Maar omdat er in dit geval geen alternatieven vermeld staan, moet het object in een packfile zitten. Om te zien welke packfiles beschikbaar zijn op deze server moet je het `objects/info/packs` bestand ophalen, wat een lijst hiervan bevat (ook gegenereerd door `update-server-info`):
 
 	=> GET objects/info/packs
 	P pack-816a9b2334da9953e530f27bcac22082a9f5b835.pack
 
-Er is slechts één packfile op de server, dus je object zit daar natuurlijk in, maar je bekijkt het index bestand om het zeker te weten. Dit is ook handig als je meerdere packfiles op de server hebt, zodat je kunt zien welke packfile het object dat je nodig hebt bevat:
+Er is slechts één packfile op de server dus dat object zit daar natuurlijk in, maar je controleert het index bestand om het zeker te weten. Dit is ook handig als je meerdere packfiles op de server hebt, zodat je kunt zien welke packfile het object dat je nodig hebt bevat:
 
 	=> GET objects/pack/pack-816a9b2334da9953e530f27bcac22082a9f5b835.idx
 	(4k of binary data)
 
-Nu dat je de packfile index hebt, kun je zien of je object hier in zit – omdat de index de SHA's van de objecten in de packfile toont en de offset naar die objecten. Je object is aanwezig, dus ga ervoor en haal de hele packfile op:
+Nu je de packfile index hebt kun je zien of het object hier in zit; omdat de index de SHA's van de objecten in de packfile toont en de offsets naar die objecten. Het gezochte object is aanwezig, dus gaat verder en haalt de hele packfile op:
 
 	=> GET objects/pack/pack-816a9b2334da9953e530f27bcac22082a9f5b835.pack
 	(13k of binary data)
 
-Je hebt je boom object, dus je kunt verder gaan met het doorlopen van je commits. Ze zitten ook allemaal in de packfile die je zojuist gedownload hebt, dus je hoeft geen verzoeken meer te doen aan je server. Git checked een werkkopie uit van de `master` branch waarnaar gewezen werd door de HEAD referentie, die je aan het begin gedownload hebt.
+Je hebt de tree object te pakken, dus je kunt verder gaan met het doorlopen van de commits. Ze zitten ook allemaal in de packfile die je zojuist gedownload hebt, dus je hoeft geen verzoeken meer te doen aan je server. Git checked een werkkopie uit van de `master` branch waarnaar gewezen werd door de HEAD referentie, die je aan het begin gedownload hebt.
 
 Het gehele uitvoer van dit proces ziet er zo uit:
 
@@ -697,46 +697,46 @@ Het gehele uitvoer van dit proces ziet er zo uit:
 
 ### Het slimme protocol ###
 
-De HTTP methode is eenvoudig, maar een beetje inefficiënt. Slimme protocollen gebruiken is een meer gebruikte manier van gegevensoverdracht. Deze protocollen hebben een proces aan de remote kant dat bewust is van Git – het kan lokale gegevens lezen en uitvinden wat de client heeft, of nodig heeft en hier eigen gegevens voor genereren. Er zijn twee sets processen voor gegevensoverdracht: een paar voor het uploaden van gegevens, en een paar voor het downloaden van gegevens.
+De HTTP methode is eenvoudig, maar een beetje inefficiënt. Slimme protocollen gebruiken is een meer gebruikelijke manier van gegevensoverdracht. Deze protocollen hebben een proces aan de remote kant dat bewust is van Git: het kan lokale gegevens lezen en uitvinden wat de client heeft of nodig heeft en hier specifieke gegevens voor genereren. Er zijn twee paar processen voor gegevensoverdracht: één paar voor het uploaden van gegevens en één paar voor het downloaden van gegevens.
 
 #### Gegevens uploaden ####
 
 Om gegevens te uploaden naar een remote proces, gebruikt Git de `send-pack` en `receive-pack` processen. Het `send-pack` proces draait op de client en maakt contact met een `receive-pack` proces aan de remote kant.
 
-Bijvoorbeeld, stel dat je `git push origin master` uitvoert in je project, en `origin` is gedefinieerd als een URL dat het SSH protocol gebruikt. Git start het `send-pack` proces, wat een verbinding initieert, via SSH, naar je server. Het probeert een commando op de remote server uit te voeren met behulp van een SSH aanroep die er ongeveer zo uit ziet:
+Bijvoorbeeld, stel dat je `git push origin master` uitvoert in je project en `origin` is gedefinieerd als een URL dat het SSH protocol gebruikt. Git start het `send-pack` proces, wat een SSH verbinding initieert naar de server. Het probeert een commando op de remote server uit te voeren met behulp van een SSH aanroep die er ongeveer zo uit ziet:
 
 	$ ssh -x git@github.com "git-receive-pack 'schacon/simplegit-progit.git'"
 	005bca82a6dff817ec66f4437202690a93763949 refs/heads/master report-status delete-refs
 	003e085bb3bcb608e1e84b2432f8ecbe6306e7e7 refs/heads/topic
 	0000
 
-Het `git-receive-pack` commando antwoord onmiddellijk met één regel voor iedere referentie die het momenteel heeft – in dit geval alleen de `master` branch en zijn SHA. De eerste regel bevat ook een lijst van de mogelijkheden van de server (in dit geval, `report-status` en `delete-refs`).
+Het `git-receive-pack` commando antwoordt onmiddellijk met één regel voor iedere referentie die het momenteel heeft; in dit geval alleen de `master` branch en zijn SHA. De eerste regel bevat ook een lijst van de mogelijkheden van de server (hier: `report-status` en `delete-refs`).
 
-Iedere regel begint met een hexadecimale waarde van 4 bytes, die specificeert hoe lang de rest van de regel is. Je eerste regel begint met 005b, wat 91 in hex is, wat betekend dat er nog 91 bytes over zijn op deze regel. De volgende regel begint met 003e, wat 62 is, zodat je de overgebleven 62 bytes leest. De volgende regel is 0000, wat betekent dat de server klaar is met het tonen van zijn referenties.
+Iedere regel begint met een hexadecimale waarde van 4 bytes, die specificeert hoe lang de rest van de regel is. Je eerste regel begint met 005b, wat 91 in hex is, wat betekent dat er nog 91 bytes over zijn op deze regel. De volgende regel begint met 003e, wat 62 is, waarna je de overgebleven 62 bytes leest. De volgende regel is 0000, wat betekent dat de server klaar is met het tonen van zijn referenties.
 
-Nu dat het de status van de server weet, bepaalt je `send-pack` proces welke commits dat het heeft, die de server nog niet heeft. Voor iedere referentie die deze push zal vernieuwen, verteld het `send-pack` het `receive-pack` proces die informatie. Bijvoorbeeld, als je de `master` branch vernieuwt en een `experiment` branch toevoegt, zou het `send-pack` antwoord er zo uit kunnen zien:
+Nu de status van de server bekend is, bepaalt het `send-pack` proces welke commits het heeft die de server nog niet heeft. Voor iedere referentie die deze push zal vernieuwen, geeft het `send-pack` die informatie aan het `receive-pack` door. Bijvoorbeeld, als je de `master` branch vernieuwt en een `experiment` branch toevoegt, zou het `send-pack` antwoord er zo uit kunnen zien:
 
 	0085ca82a6dff817ec66f44342007202690a93763949  15027957951b64cf874c3557a0f3547bd83b3ff6 refs/heads/master report-status
 	00670000000000000000000000000000000000000000 cdfdb42577e2506715f8cfeacdbabc092bf63e8d refs/heads/experiment
 	0000
 
-Een SHA-1 waarde met alleen '0' betekent dat er nog niets was – omdat je de experiment referentie toevoegt. Als je een referentie aan het verwijderen was, zou je het tegenovergestelde zien: allemaal '0' aan de rechterkant.
+Een SHA-1 waarde met alleen '0' betekent dat er nog niets was; omdat je de experiment referentie toevoegt. Als je een referentie aan het verwijderen was, zou je het tegenovergestelde zien: allemaal '0'en aan de rechterkant.
 
-Git stuurt een regel voor iedere referentie die je vernieuwt, met de oude SHA, de nieuwe SHA en de referentie die vernieuwd wordt. De eerste regel bevat ook de mogelijkheden van de client. Vervolgens upload de client een packfile met alle objecten die de server nog niet heeft. Als laatste antwoord de server met een succes (of mislukking) indicatie:
+Git stuurt een regel voor iedere referentie die je vernieuwt met de oude SHA, de nieuwe SHA en de referentie die vernieuwd wordt. De eerste regel bevat ook de mogelijkheden van de client. Vervolgens uploadt de client een packfile met alle objecten die de server nog niet heeft. Als laatste antwoordt de server met een indicatie van succes (of mislukking):
 
 	000Aunpack ok
 
 #### Gegevens downloaden ####
 
-Op het moment dat je gegevens download zijn de `fetch-pack` en `upload-pack` processen betrokken. De client start een `fetch-pack` proces dat verbinding maakt met een `upload-pack` proces aan de remote kant om te onderhandelen welke gegevens gestuurd moeten worden.
+Zodra je gegevens downloadt zijn de `fetch-pack` en `upload-pack` processen erbij betrokken. De client start een `fetch-pack` proces dat verbinding maakt met een `upload-pack` proces aan de remote kant om te onderhandelen welke gegevens opgehaald moeten worden.
 
-Er zijn verschillende manieren om het `upload-pack` proces op de remote repository te starten. Je kunt het uitvoeren via SSH, op dezelfde manier als het `receive-pack` proces. Je kunt het proces ook starten via de Git daemon, die standaard op poort 9418 luistert. Het `fetch-pack` proces stuurt gegevens, die er zo uitzien voor de daemon na het maken van de verbinding:
+Er zijn verschillende manieren om het `upload-pack` proces op de remote repository te starten. Je kunt het uitvoeren via SSH, zoals bij het `receive-pack` proces. Je kunt het proces ook starten via de Git daemon, die standaard op poort 9418 luistert. Het `fetch-pack` proces stuurt gegevens, naar de daemon na het maken van de verbinding die er zo uitzien:
 
 	003fgit-upload-pack schacon/simplegit-progit.git\0host=myserver.com\0
 
-Het begint met de 4 bytes die specificeren hoeveel gegevens er volgen, daarna het commando gevolgd door een null byte, en dan de hostname van de server gevolgd door een laatste null byte. De Git daemon bekijkt of dat commando uitgevoerd kan worden, dat het repository bestaat en dat het publieke permissies heeft. Als alles OK is, dan start het het `upload-pack` proces en geeft hier het verzoek aan door.
+Het begint met de 4 bytes die specificeren hoeveel gegevens er volgen, daarna het commando gevolgd door een null byte, en dan de hostname van de server gevolgd door een laatste null byte. De Git daemon bekijkt of dat commando uitgevoerd kan worden, dat de repository bestaat en dat het publieke permissies heeft. Als alles OK is, dan start het het `upload-pack` proces en geeft het verzoek hier aan door.
 
-Als je de fetch via SSH dper, voert het `fetch-pack` in plaats daarvan zoiets als dit uit:
+Als je de fetch via SSH doet, voert het `fetch-pack` in plaats daarvan zoiets als dit uit:
 
 	$ ssh -x git@github.com "git-upload-pack 'schacon/simplegit-progit.git'"
 
@@ -748,24 +748,24 @@ In beide gevallen stuurt `upload-pack`, nadat `fetch-pack` verbinding gemaakt he
 	003e085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7 refs/heads/topic
 	0000
 
-Dit komt erg overeen met waarmee `receive-pack` antwoord, maar de mogelijkheden zijn verschillend. Daarnaast stuurt het de HEAD referentie zodat de client weet wat er uitgechecked moet worden als dit een kloon is.
+Dit komt erg overeen met hoe `receive-pack` antwoordt, maar de mogelijkheden zijn verschillend. Daarnaast stuurt het de HEAD referentie zodat de client weet wat er uitgechecked moet worden als dit een kloon is.
 
-Op dit punt kijkt het `fetch-pack` proces naar welk objecten dat het heeft en antwoord met de objecten die het nodig heeft door "want" te sturen, gevolgd door de SHA die het wil. Het stuurt al de objecten die het al heeft met "have" en dan de SHA. Aan het einde van deze lijst, schrijft het "done" om het `upload-pack` proces te starten met het sturen van de packfile van de gegevens die het nodig heeft:
+Op dit punt kijkt het `fetch-pack` proces naar welke objecten het heeft en antwoordt met de objecten die het nodig heeft door "want" te sturen, gevolgd door de SHA die het wil hebben. Het stuurt al de objecten die het al heeft met "have" en dan de SHA. Aan het einde van deze lijst schrijft het "done" om het `upload-pack` proces te laten beginnen met het sturen van de packfile met de gegevens die het nodig heeft:
 
 	0054want ca82a6dff817ec66f44342007202690a93763949 ofs-delta
 	0032have 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7
 	0000
 	0009done
 
-Dat is een basaal geval van de overdrachtsprotocollen. In meer complexe gevallen ondersteunt de client `multi_ack` of `side-band` mogelijkheden; maar dit voorbeeld toont je de basale heen en weer gang die gebruikt wordt door de slimme protocol processen.
+Dat is een basaal geval van de overdrachtsprotocollen. In meer complexe gevallen ondersteunt de client `multi_ack` of `side-band` mogelijkheden; maar dit voorbeeld toont je het basale over en weer dat gebruikt wordt door de slimme protocol processen.
 
 ## Onderhoud en het herstellen van gegevens ##
 
-Soms moet je wat opruimen – een repository compacter maken, een geïmporteerd repository opruimen, of verloren werk terughalen. Deze sectie zal deze scenario's doorlopen.
+Soms moet je wat opruimen: een repository compacter maken, een geïmporteerd repository opruimen of verloren werk terughalen. Deze paragraaf zal deze scenario's behandelen.
 
 ### Onderhoud ###
 
-Soms voert Git automatisch een commando genaamd "auto gc" uit. Het merendeel van de tijd doet dit commando niets. Maar, als je teveel losse objecten (objecten die niet in een packfile zitten) of teveel packfiles hebt, dan lanceert Git een volledig `git gc` commando. Het `gc` staat voor garbage collect (afval ophalen), en het commando doet een aantal zaken: het haalt alle losse objecten op en stopt ze in packfiles, het voegt packfiles samen in één grote packfile, en het verwijderd objecten die niet bereikbaar zijn vanuit een commit en die een paar maanden oud zijn.
+Geregeld voert Git automatisch een commando genaamd "auto gc" uit. Het merendeel van de tijd doet dit commando niets. Maar, als je teveel losse objecten (objecten die niet in een packfile zitten) of teveel packfiles hebt, lanceert Git een uitgebreid `git gc` commando. Het `gc` staat voor garbage collect (afval ophalen), en het commando doet een aantal zaken: het haalt alle losse objecten op en stopt ze in packfiles, het voegt packfiles samen in één grote packfile, en het verwijdert objecten die niet bereikbaar zijn vanuit een commit en een paar maanden oud zijn.
 
 Je kunt auto gc als volgt handmatig uitvoeren:
 
@@ -773,7 +773,7 @@ Je kunt auto gc als volgt handmatig uitvoeren:
 
 Nogmaals, over het algemeen doet dit commando niets. Je moet ongeveer 7.000 losse objecten of meer dan 50 packfiles hebben voordat Git een echt gc commando start. Je kunt deze grenzen respectievelijk met de `gc.auto` en `gc.autopacklimit` configuratie instellingen aanpassen.
 
-Het andere ding dat `gc` zal doen is je referenties in een enkel bestand inpakken. Stel dat je repository de volgende branches en tags bevat:
+Het andere dat `gc` zal doen is je referenties in een enkel bestand inpakken. Stel dat je repository de volgende branches en tags bevat:
 
 	$ find .git/refs -type f
 	.git/refs/heads/experiment
@@ -781,7 +781,7 @@ Het andere ding dat `gc` zal doen is je referenties in een enkel bestand inpakke
 	.git/refs/tags/v1.0
 	.git/refs/tags/v1.1
 
-Als je `git gc` uitvoert, zul je deze bestanden niet langer in de `refs` map hebben. Git zal ze omwille van efficiëntie in een bestand genaamd `.git/packed-refs` stoppen, dat er zo uitziet:
+Als je `git gc` uitvoert, zul je deze bestanden niet langer in de `refs` directory hebben. Git zal ze omwille van efficiëntie in een bestand genaamd `.git/packed-refs` stoppen, dat er zo uitziet:
 
 	$ cat .git/packed-refs
 	# pack-refs with: peeled
@@ -791,13 +791,13 @@ Als je `git gc` uitvoert, zul je deze bestanden niet langer in de `refs` map heb
 	9585191f37f7b0fb9444f35a9bf50de191beadc2 refs/tags/v1.1
 	^1a410efbd13591db07496601ebc7a059dd55cfe9
 
-Als je een referentie vernieuwt, zal Git dit bestand niet aanpassen maar een nieuw bestand in `refs/heads` schrijven. Om de juiste SHA voor een gegeven referentie te krijgen, kijkt Git voor die referentie in de `refs` map en kijkt in het `packed-res` bestand als terugval optie. Hoe dan ook, als je een referentie niet in de `refs` map kunt vinden, zit het waarschijnlijk in je `packed-refs` bestand.
+Als je een referentie vernieuwt, zal Git dit bestand niet aanpassen maar een nieuw bestand in `refs/heads` schrijven. Om de juiste SHA voor een gegeven referentie te krijgen, kijkt Git voor die referentie in de `refs` directory en kijkt in het `packed-res` bestand als terugval optie. Hoe dan ook, als je een referentie niet in de `refs` directory kunt vinden zit het waarschijnlijk in je `packed-refs` bestand.
 
-Let op de laatste regel van het bestand, die begint met een `^`. Dit betekent dat de tag die er direct boven staat een beschreven tag is, en dat die regel e commit is waar de beschreven tag naar wijst.
+Let op de laatste regel van het bestand, die begint met een `^`. Dit betekent dat de tag die er direct boven staat een beschreven tag is, en dat die regel de commit is waar de beschreven tag naar wijst.
 
 ### Gegevens herstellen ###
 
-Op een bepaald punt in je reis met Git, kun je per ongeluk wel eens een commit verliezen. Over het algemeen gebeurd dit omdat je een branch force-delete, waar werk op zat, en het blijkt dat je de branch uit eindelijk toch wou hebben; of je hard-reset een branch, waarmee je commits achterlaat waar je iets van wou hebben. Stel dat dit gebeurd, hoe kun je dan je commits terug halen?
+Op een bepaald punt in je reis met Git, is het mogelijk dat je per ongeluk eens een commit verliest. Over het algemeen gebeurt dit omdat je een branch waar werk op zat geforceerd verwijdert, en het blijkt dat je de branch achteraf toch had willen houden. Of je hard-reset een branch, waarmee je commits achterlaat waar je iets van wilde hebben. Stel dat dit gebeurt, hoe kun je dan je commits terug halen?
 
 Hier is een voorbeeld dat een hard-reset doet naar een oudere commit op de master branch in je test repository, en de verloren commits terug haalt. Laten we eerst eens bekijken waar je repository op dit punt staat:
 
@@ -817,15 +817,15 @@ Nu verplaats je de `master` branch terug naar de middelste commit:
 	cac0cab538b970a37ea1e769cbbde608743bc96d second commit
 	fdf4fc3344e67ab068f836878b6c4951e3b15f3d first commit
 
-Je bent nu effectief de twee bovenste commits kwijt – je hebt geen branch vanwaar deze commits bereikbaar zijn. Je moet de laatste commit SHA vinden en dan een branch toevoegen die daar naar wijst. De truc is om de laatste commit SHA te vinden – het is toch niet alsof je die onthouden hebt, toch?
+Je bent nu effectief de twee bovenste commits kwijt: je hebt geen branch van waaruit deze commits bereikbaar zijn. Je moet de laatste commit SHA vinden en dan een branch toevoegen die daar naar wijst. De truuk is om de laatste commit SHA te vinden, het is toch niet waarschijnlijk dat je die onthouden hebt, toch?
 
-Vaak is de snelste manier een tool genaamd `git reflog` te gebruiken. Terwijl je werkt slaat Git stilletjes op wat je HEAD is, iedere keer als je die wijzigt. Iedere keer dat je commit, of van branch veranderd wordt de reflog vernieuwd. Het reflog wordt ook vernieuwd door het `git update-ref` commando, wat nog een reden is om het te gebruiken in plaats van gewoon de SHA's naar je ref bestanden te schrijven, zoals we beschreven hebben in de "Git References" sectie eerder in dit hoofdstuk. Je kunt op ieder moment zien waar je geweest bent, door `git reflog` uit te voeren.
+Vaak is de snelste manier een tool genaamd `git reflog` te gebruiken. Terwijl je werkt slaat Git stilletjes op wat je HEAD is, iedere keer als je die wijzigt. Elke keer als je commit, of van branch verandert wordt de reflog vernieuwd. Het reflog wordt ook vernieuwd door het `git update-ref` commando, wat nog een reden is om het te gebruiken in plaats van gewoon de SHA's naar je ref bestanden te schrijven, zoals we beschreven hebben in de "Git Referenties" paragraaf eerder in dit hoofdstuk. Je kunt op ieder moment zien waar je geweest bent, door `git reflog` uit te voeren.
 
 	$ git reflog
 	1a410ef HEAD@{0}: 1a410efbd13591db07496601ebc7a059dd55cfe9: updating HEAD
 	ab1afef HEAD@{1}: ab1afef80fac8e34258ff41fc1b867c702daa24b: updating HEAD
 
-Hier kunnen we de twee commits zien die we uitgechecked hadden, maar er is niet veel informatie aanwezig. Om dezelfde informatie op een veel bruikbaarder manier kunnen we `git log -g` uitvoeren, wat je een normale log uitvoer geeft voor je reflog.
+Hier kunnen we de twee commits zien die we uitgechecked hadden, maar er is hier niet veel informatie aanwezig. Om dezelfde informatie op een veel bruikbaarder manier te zien kunnen we `git log -g` uitvoeren, wat je een normale log uitvoer geeft voor je reflog.
 
 	$ git log -g
 	commit 1a410efbd13591db07496601ebc7a059dd55cfe9
@@ -854,13 +854,13 @@ Het ziet er naar uit dat de onderste commit degene is die je kwijt bent geraakt,
 	cac0cab538b970a37ea1e769cbbde608743bc96d second commit
 	fdf4fc3344e67ab068f836878b6c4951e3b15f3d first commit
 
-Vet – nu heb je een branch genaamd `recover-branch` die staat op het punt waar je `master` branch was, waarmee de eerste twee commits weer bereikbaar zijn.
-Vervolgens, stel dat je verloren commit om een of andere reden niet in de reflog stond – je kunt dat simuleren door `recover-branch` te verwijderen en het reflog te wissen. Nu zijn de eerste twee commits niet meer bereikbaar door wat dan ook:
+Vet – nu heb je een branch genaamd `recover-branch` die staat op het punt waar je `master` branch eerder was, waarmee de eerste twee commits weer bereikbaar zijn.
+Vervolgens, stel dat je verloren commit om een of andere reden niet in de reflog stond; je kunt dat simuleren door `recover-branch` te verwijderen en het reflog te wissen. Nu zijn de eerste twee commits nergens meer mee te bereiken:
 
 	$ git branch –D recover-branch
 	$ rm -Rf .git/logs/
 
-Omdat de reflog gegevens bewaard worden in de `.git/logs/` map, heb je effectief geen reflog. Hoe kun je die commit op dat punt herstellen? Één manier is om gebruik te maken van het `git fsck` tool, wat de integriteit van je gegevensbank controleert. Als je het met de `--full` optie uitvoert, dan toont het je alle objecten waarnaar niet gewezen wordt door een ander object:
+Omdat de reflog gegevens bewaard worden in de `.git/logs/` directory, heb je nu effectief geen reflog meer. Hoe kun je die commit op dat punt herstellen? Één manier is om gebruik te maken van het `git fsck` tool, wat de integriteit van je gegevensbank controleert. Als je het met de `--full` optie uitvoert, dan toont het je alle objecten waarnaar niet gewezen wordt door een ander object:
 
 	$ git fsck --full
 	dangling blob d670460b4b4aece5915caf5c68d12f560a9fe3e4
@@ -868,17 +868,17 @@ Omdat de reflog gegevens bewaard worden in de `.git/logs/` map, heb je effectief
 	dangling tree aea790b9a58f6cf6f2804eeac9f0abbe9631e4c9
 	dangling blob 7108f7ecb345ee9d0084193f147cdad4d2998293
 
-In dit geval, kun je je vermiste commit zien na de hangende commit. Je kunt het op dezelfde manier herstellen, door een branch toe te voegen die naar die SHA wijst.
+In dit geval, kun je de vermiste commit zien na de hangende ('dangling') commit. Je kunt het op dezelfde manier herstellen, door een branch te maken die naar die SHA wijst.
 
 ### Objecten verwijderen ###
 
-Er zijn een hoop geweldige dingen aan Git, maar één eigenschap die problemen kan geven is het feit dat `git clone` de hele historie van het project download, inclusief alle versies van alle bestanden. Dat is geen probleem als het hele ding broncode is, omdat Git zeer geoptimaliseerd is om die gegevens optimaal te comprimeren. Maar, als iemand op een bepaald punt in de geschiedenis een enkel enorm bestand heeft toegevoegd, zal iedere kloon voor altijd gedwongen worden om dat grote bestand te downloaden, zelfs als het uit het project was verwijderd in de volgende commit. Omdat het bereikbaar is vanuit de geschiedenis, zal het er altijd zijn.
+Er zijn een hoop geweldige dingen aan Git, maar één eigenschap die problemen kan geven is het feit dat `git clone` de hele historie van het project download, inclusief alle versies van alle bestanden. Dat is geen probleem als het hele project broncode is, omdat Git zeer geoptimaliseerd is om die gegevens optimaal te comprimeren. Maar, als iemand op een bepaald punt in de geschiedenis een enorm bestand heeft toegevoegd, zal iedere kloon voor altijd gedwongen worden om dat grote bestand te downloaden, zelfs als het uit het project was verwijderd in de eerstvolgende commit. Omdat het bereikbaar is vanuit de geschiedenis, zal het er altijd zijn.
 
-Dit kan een groot probleem zijn als je Subversion of Perforce repositories omzet naar Git. Omdat je niet de hele geschiedenis download in die systemen, zal dit soort toevoeging een paar gevolgen met zich meebrengen. Als je een import vanuit een ander systeem deed, of om een andere reden vindt dat je repository veel groter is dan het zou moeten zijn, kun je hier zien hoe je grote objecten kunt vinden en verwijderen.
+Dit kan een groot probleem zijn als je Subversion of Perforce repositories converteert naar Git. Omdat je niet de hele geschiedenis download in die systemen, zal dit soort toevoeging een paar consequenties met zich meebrengen. Als je een import vanuit een ander systeem deed, of om een andere reden vindt dat je repository veel groter is dan het zou moeten zijn, kun je hier zien hoe je grote objecten kunt vinden en verwijderen.
 
-Let op: deze techniek is verwoestend voor je commit geschiedenis. Het herschrijft ieder commit object stroomafwaarts vanaf de eerste boom die je moet aanpassen om een referentie naar een groot bestand te verwijderen. Als je dit meteen na een import doet, voordat iemand werk is gaan baseren op de commit, dan is er niets aan de hand – anders moet je alle bijdragers waarschuwen dat ze hun werk op je nieuwe commits moeten rebasen.
+Let op: deze techniek is destructief voor je commit geschiedenis. Het herschrijft ieder commit object stroomafwaarts vanaf de eerste tree die je moet aanpassen om een referentie naar een groot bestand te verwijderen. Als je dit meteen na een import doet, voordat iemand werk is gaan baseren op de commit, dan is er niets aan de hand; anders moet je alle bijdragers waarschuwen dat ze hun werk op je nieuwe commits moeten rebasen.
 
-Om het te demonstreren, voeg je een groot bestand in je test repository toe, verwijderd het in de volgende commit, vindt het, en verwijderd het permanent uit het repository. Als eerste, voeg je een groot object toe aan je geschiedenis:
+Om het te demonstreren, voeg je een groot bestand in je test repository toe, verwijdert het in de volgende commit, vindt het, en verwijdert het daarna permanent uit de repository. Als eerste, voeg je een groot object toe aan je geschiedenis:
 
 	$ curl http://kernel.org/pub/software/scm/git/git-1.6.3.1.tar.bz2 > git.tbz2
 	$ git add git.tbz2
@@ -887,7 +887,7 @@ Om het te demonstreren, voeg je een groot bestand in je test repository toe, ver
 	 1 files changed, 0 insertions(+), 0 deletions(-)
 	 create mode 100644 git.tbz2
 
-Oops — je wou geen enorme tarball toevoegen aan je project. Laten we er snel vanaf zien te komen:
+Oeps — je wilde geen enorme tarball toevoegen aan je project. Laten we het maar snel verwijderen:
 
 	$ git rm git.tbz2
 	rm 'git.tbz2'
@@ -916,27 +916,27 @@ Je kunt het `count-objects` commando gebruiken om snel te zien hoeveel ruimte je
 	prune-packable: 0
 	garbage: 0
 
-Op de `size-pack` regel staat de grootte van je packfiles in kilobytes, dus je gebruikt 2Mb. Voor de laatste commit gebruikte je bijna 2K – dus het is duidelijk dat het verwijderen van het bestand uit de vorige commit, het niet uit je geschiedenis verwijderd heeft. Iedere keer als iemand dit repository kloont, zullen ze de volle 2Mb moeten klonen alleen maar om dit kleine project te krijgen, omdat jij per ongeluk een groot bestand toegevoegd hebt. Laten we het kwijtraken.
+Op de `size-pack` regel staat de grootte van je packfiles in kilobytes, dus je gebruikt 2Mb. Voor de laatste commit gebruikte je bijna 2K; het is duidelijk dat het verwijderen van het bestand uit de vorige commit, het niet uit je geschiedenis verwijderd heeft. Iedere keer als iemand dit repository kloont, zullen ze de volle 2Mb moeten klonen alleen maar om dit kleine project te krijgen, omdat jij per ongeluk een groot bestand toegevoegd hebt. Laten we het kwijtraken.
 
-Eerst moet je het vinden. In dit geval weet je al welk bestand het is. Maar stel dat je het niet wist; hoe zou je kunnen vinden welk bestand of bestanden zoveel ruimte in beslag nemen? Als je `git gc` uitvoert zitten alle objecten in een packfile; je kunt de grote bestanden identificeren door een ander sanitaire voorzieningen commando genaamd `git verify-pack` uit te voeren en te sorteren op het derde veld in de uitvoer, wat de bestandsgrootte is. Je kunt het ook door het `tail` commando leiden omdat je alleen geïnteresseerd bent in het laatste paar grote bestanden.
+Eerst moet je het vinden. In dit geval weet je al welk bestand het is. Maar stel dat je het niet wist; hoe zou je kunnen vinden welk bestand of bestanden zoveel ruimte in beslag nemen? Als je `git gc` uitvoert zitten alle objecten in een packfile; je kunt de grote bestanden identificeren door een ander plumbing commando genaamd `git verify-pack` uit te voeren en te sorteren op het derde veld in de uitvoer, wat de bestandsgrootte is. Je kunt het ook door het `tail` commando leiden omdat je alleen geïnteresseerd bent in het laatste paar grote bestanden.
 
 	$ git verify-pack -v .git/objects/pack/pack-3f8c0...bb.idx | sort -k 3 -n | tail -3
 	e3f094f522629ae358806b17daf78246c27c007b blob   1486 734 4667
 	05408d195263d853f09dca71d55116663690c27c blob   12908 3478 1189
 	7a9eb2fba2b1811321254ac360970fc169ba2330 blob   2056716 2056872 5401
 
-Het grote object staat aan het einde: 2 Mb. Om uit te vinden welk bestand het is, zul je het `rev-list` commando gebruiken, wat je kort gebruikt hebt in Hoofdstuk 7. Als je `--objects` meegeeft aan `ref-list`, toont het alle commit SHA's en ook de blob SHA's met de bestandspaden die er aan geassocieerd zijn. Je kunt dit gebruiken om de naam van je blob te vinden:
+Het grote object staat aan het einde: 2 Mb. Om uit te vinden welk bestand het is, zul je het `rev-list` commando gebruiken, wat je eventjes gebruikt hebt in Hoofdstuk 7. Als je `--objects` meegeeft aan `ref-list`, toont het alle commit SHA's en ook de blob SHA's met de bestandspaden die er mee geassocieerd zijn. Je kunt dit gebruiken om de naam van je blob te vinden:
 
 	$ git rev-list --objects --all | grep 7a9eb2fb
 	7a9eb2fba2b1811321254ac360970fc169ba2330 git.tbz2
 
-Nu moet je dit bestand verwijderen van alle bomen in je verleden. Je kunt eenvoudig zien welke commits dit bestand aangepast hebben:
+Nu moet je dit bestand verwijderen uit alle trees in je verleden. Je kunt eenvoudig zien welke commits dit bestand aangepast hebben:
 
 	$ git log --pretty=oneline --branches -- git.tbz2
 	da3f30d019005479c99eb4c3406225613985a1db oops - removed large tarball
 	6df764092f3e7c8f5f94cbe08ee5cf42e92a0289 added git tarball
 
-Je moet alle commits die stroomafwaarts van `6df76` liggen om dit bestand volledig uit je Git geschiedenis te verwijderen. Omdat te doen gebuik je `filter-branch`, wat je in Hoofdstuk 6 gebruikt hebt:
+Je moet alle commits die stroomafwaarts van `6df76` liggen herschrijven om dit bestand volledig uit je Git geschiedenis te verwijderen. Omdat te doen gebuik je `filter-branch`, wat je in Hoofdstuk 6 gebruikt hebt:
 
 	$ git filter-branch --index-filter \
 	   'git rm --cached --ignore-unmatch git.tbz2' -- 6df7640^..
@@ -944,9 +944,9 @@ Je moet alle commits die stroomafwaarts van `6df76` liggen om dit bestand volled
 	Rewrite da3f30d019005479c99eb4c3406225613985a1db (2/2)
 	Ref 'refs/heads/master' was rewritten
 
-De `--index-filter` optie is vergelijkbaar met de `--tree-filter` optie, die gebruikt is in Hoofdstuk 6, behalve dan dat in plaats van het doorgeven van een commando dat bestanden aanpast die uitgechecked staan op je schijf, pas je je staging gebied of index iedere keer aan. In plaats van een specifiek bestand steeds te verwijderen met zoiets als `rm file`, moet je het met `git rm --cached` verwijderen – je moet het uit de index verwijderen, niet van de schijf. Reden om het zo te doen is snelheid – omdat Git niet iedere versie hoeft uit te checken op je schijf voordat het je filter uitvoert, kan het proces vele, vele malen sneller gaan. Je kunt dezelfde taak uitvoeren met `--tree-filter` als je dat wil. De `--ignore-unmatch` optie op `git rm` verteld het niet te stoppen op een fout als het patroon dat je probeert te verwijderen niet aanwezig is. Als laatste zul je `filter-branch` vragen om je geschiedenis alleen vanaf de `6df7640` commit te herschrijven, omdat je weet dat dat de plaats is waar het probleem begon. Anders start het vanaf het begin en duurt het onnodig langer.
+De `--index-filter` optie is vergelijkbaar met de `--tree-filter` optie, die gebruikt is in Hoofdstuk 6, met het verschil dat in plaats van het doorgeven van een commando dat bestanden aanpast die uitgechecked staan op je schijf, je het staging area of index iedere keer aanpast. In plaats van een specifiek bestand steeds te verwijderen met zoiets als `rm file`, moet je het met `git rm --cached` verwijderen; je moet het uit de index verwijderen, niet van de schijf. Reden om het zo te doen is snelheid: omdat Git niet iedere versie hoeft uit te checken op je schijf voordat het je filter uitvoert, kan het proces vele, vele malen sneller gaan. Je kunt dezelfde taak uitvoeren met `--tree-filter` als je dat wilt. De `--ignore-unmatch` optie op `git rm` vertelt het niet te stoppen op een fout als het patroon dat je probeert te verwijderen niet aanwezig is. Als laatste zal je `filter-branch` vragen om je geschiedenis alleen vanaf de `6df7640` commit te herschrijven, omdat je weet dat dat de plaats is waar het probleem begon. Anders start het vanaf het begin en duurt het onnodig langer.
 
-Je geschiedenis zal niet langer een referentie bevatten naar dat bestand. Maar, je reflog en een nieuwe set refs die Git toevoegde toen je de `filter-branch` deed onder `.git/refs/original` bevatten het nog steeds, dus je moet die ook verwijderen en je gegevensbank opnieuw inpakken. Je moet alles dat een pointer naar die oude commits bevat kwijtraken voordat je opnieuw inpakt:
+Je geschiedenis zal niet langer een referentie bevatten naar dat bestand. Maar, je reflog en een nieuwe set refs die Git toevoegde toen je de `filter-branch` deed onder `.git/refs/original` bevatten het nog steeds, dus je moet die ook verwijderen en je gegevensbank opnieuw inpakken. Je moet alles wat een pointer naar die oude commits bevat kwijtraken voordat je opnieuw inpakt:
 
 	$ rm -Rf .git/refs/original
 	$ rm -Rf .git/logs/
@@ -968,10 +968,10 @@ Laten we eens zien hoeveel ruimte je bespaard hebt.
 	prune-packable: 0
 	garbage: 0
 
-De grootte van je ingepakte repository is omlaag gegaan naar 7 K, wat veel beter is dan 2 Mb. Je kunt aan de waarde van size zien dat het grootte object nog steeds in je losse bestanden staat, dus het is niet weg; maar het zal niet meer overgedragen worden bij een push of opvolgende kloon, wat het belangrijkste is. Als je het echt zou willen, kun je het object volledig verwijderen door `git prune --expire` uit te voeren.
+De grootte van je ingepakte repository is omlaag gegaan naar 7 K, wat veel beter is dan 2 Mb. Je kunt aan de waarde van size zien dat het grote object nog steeds in je losse bestanden staat, dus het is niet weg; maar het zal niet meer overgedragen worden bij een push of opvolgende kloon, wat het belangrijkste is. Als je het echt zou willen, kun je het object volledig verwijderen door `git prune --expire` uit te voeren.
 
 ## Samenvatting ##
 
-Je moet een goed begrip hebben van wat Git op de achtergrond doet en, tot een bepaalde hoogte, hoe het in elkaar gezet is. Dit hoofdstuk heeft een aantal sanitaire voorzieningen commando's beslagen – commando's die op een lager niveau zitten en eenvoudige zijn dan de porselein commando's waarover je in de rest van het boek geleerd hebt. Begrijpen hoe Git op een lager niveau werkt zou het makkelijker moeten maken om te begrijpen waarom het doet wat het doet en ook om je eigen applicaties te schrijven en hulp scripts om jouw specifieke werkwijze voor je te laten werken.
+Je moet een goed begrip hebben van wat Git op de achtergrond doet en, tot een bepaalde hoogte, hoe het in elkaar gezet is. Dit hoofdstuk heeft een aantal plumbing commando's besproken – commando's die op een lager niveau zitten en eenvoudige zijn dan de porcelain commando's waarover je in de rest van het boek geleerd hebt. Begrijpen hoe Git op een lager niveau werkt zou het makkelijker moeten maken om te begrijpen waarom het doet wat het doet en ook om je eigen applicaties te schrijven en hulp scripts om jouw specifieke werkwijze voor je te laten werken.
 
-Git is als een inhouds-toegankelijk bestandssysteem een zeer krachtig tool dat je eenvoudig als meer dan alleen een VCS kunt gebruiken. Ik hoop dat je je nieuwe kennis van de werking van Git kunt gebruiken om je eigen coole applicatie te bouwen met deze technologie en je op je gemak voelt bij het gebruik van Git op meer geavanceerde manieren.
+Git is als een inhouds-toegankelijk bestandssysteem een zeer krachtig tool dat je eenvoudig als meer dan alleen een VCS kunt gebruiken. Ik hoop dat je deze nieuwe kennis van de werking van Git kunt gebruiken om je eigen coole applicatie te bouwen met deze technologie en dat je je prettig voelt bij het gebruik van Git op meer geavanceerde manieren.

From 91600a1d3856be3688f65681551112d6f129071d Mon Sep 17 00:00:00 2001
From: Jiri Engelthaler <engycz@gmail.com>
Date: Tue, 11 Feb 2014 18:07:46 +0100
Subject: [PATCH 215/690] According to commit a0228ae there should be C3', not
 C3 also in other languages.

---
 cs/03-git-branching/01-chapter3.markdown | 2 +-
 es/03-git-branching/01-chapter3.markdown | 2 +-
 mk/03-git-branching/01-chapter3.markdown | 2 +-
 pl/03-git-branching/01-chapter3.markdown | 2 +-
 vi/03-git-branching/01-chapter3.markdown | 4 ++--
 5 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/cs/03-git-branching/01-chapter3.markdown b/cs/03-git-branching/01-chapter3.markdown
index 8d5275ffe..808bcb086 100644
--- a/cs/03-git-branching/01-chapter3.markdown
+++ b/cs/03-git-branching/01-chapter3.markdown
@@ -507,7 +507,7 @@ Nyní můžete přejít zpět na hlavní větev a provést sloučení „rychle
 Insert 18333fig0330.png
 Obrázek 3-30. „Rychle vpřed“ po hlavní větvi
 
-Snímek, na který nyní ukazuje revize C3, je zcela totožný se snímkem, na který v příkladu v části o slučování ukazovala C5. V koncových produktech integrace není žádný rozdíl, výsledkem přeskládání je však čistší historie. Pokud si prohlížíte log přeskládané větve, vypadá jako lineární historie – zdá se, jako by veškerá práce probíhala v jedné linii, ačkoli původně byla paralelní.
+Snímek, na který nyní ukazuje revize C3', je zcela totožný se snímkem, na který v příkladu v části o slučování ukazovala C5. V koncových produktech integrace není žádný rozdíl, výsledkem přeskládání je však čistší historie. Pokud si prohlížíte log přeskládané větve, vypadá jako lineární historie – zdá se, jako by veškerá práce probíhala v jedné linii, ačkoli původně byla paralelní.
 
 Tuto metodu budete často používat v situaci, kdy chcete mít jistotu, že byly vaše revize čistě aplikovány na vzdálenou větev – např. v projektu, do nějž chcete přidat příspěvek, který ale nespravujete. V takovém případě budete pracovat ve své větvi, a až budete mít připraveny záplaty k odeslání do hlavního projektu, přeskládáte svou práci na větev `origin/master`. Správce v tomto případě nemusí provádět žádnou integraci, provede pouze posun „rychle vpřed“ nebo čistou aplikaci.
 
diff --git a/es/03-git-branching/01-chapter3.markdown b/es/03-git-branching/01-chapter3.markdown
index e26766275..bb63d84a4 100644
--- a/es/03-git-branching/01-chapter3.markdown
+++ b/es/03-git-branching/01-chapter3.markdown
@@ -507,7 +507,7 @@ En este momento, puedes volver a la rama 'master' y hacer una fusión con avance
 Insert 18333fig0330.png 
 Figura 3-30. Avance rápido de la rama 'master'.
 
-Así, la instantánea apuntada por C3 aquí es exactamente la misma apuntada por C5 en el ejemplo de la fusión. No hay ninguna diferencia en el resultado final de la integración, pero el haberla hecho reorganizando nos deja un registro más claro. Si examinas el registro de una rama reorganizada, este aparece siempre como un registro lineal: como si todo el trabajo se hubiera realizado en series, aunque realmente se haya hecho en paralelo.
+Así, la instantánea apuntada por C3' aquí es exactamente la misma apuntada por C5 en el ejemplo de la fusión. No hay ninguna diferencia en el resultado final de la integración, pero el haberla hecho reorganizando nos deja un registro más claro. Si examinas el registro de una rama reorganizada, este aparece siempre como un registro lineal: como si todo el trabajo se hubiera realizado en series, aunque realmente se haya hecho en paralelo.
 
 Habitualmente, optarás por esta vía cuando quieras estar seguro de que tus confirmaciones de cambio (commits) se pueden aplicar limpiamente sobre una rama remota; posiblemente, en un proyecto donde estés intentando colaborar, pero lleves tu el mantenimiento. En casos como esos, puedes trabajar sobre una rama y luego reorgainzar lo realizado en la rama 'origin/master' cuando lo tengas todo listo para enviarlo al proyecto principal. De esta forma, la persona que mantiene el proyecto no necesitará hacer ninguna integración con tu trabajo; le bastará con un avance rápido o una incorporación limpia.
 
diff --git a/mk/03-git-branching/01-chapter3.markdown b/mk/03-git-branching/01-chapter3.markdown
index 23dac7fcc..da5f17cf6 100644
--- a/mk/03-git-branching/01-chapter3.markdown
+++ b/mk/03-git-branching/01-chapter3.markdown
@@ -507,7 +507,7 @@ At this point, you can go back to the master branch and do a fast-forward merge
 Insert 18333fig0330.png 
 Figure 3-30. Fast-forwarding the master branch.
 
-Now, the snapshot pointed to by C3 is exactly the same as the one that was pointed to by C5 in the merge example. There is no difference in the end product of the integration, but rebasing makes for a cleaner history. If you examine the log of a rebased branch, it looks like a linear history: it appears that all the work happened in series, even when it originally happened in parallel.
+Now, the snapshot pointed to by C3' is exactly the same as the one that was pointed to by C5 in the merge example. There is no difference in the end product of the integration, but rebasing makes for a cleaner history. If you examine the log of a rebased branch, it looks like a linear history: it appears that all the work happened in series, even when it originally happened in parallel.
 
 Often, you’ll do this to make sure your commits apply cleanly on a remote branch — perhaps in a project to which you’re trying to contribute but that you don’t maintain. In this case, you’d do your work in a branch and then rebase your work onto `origin/master` when you were ready to submit your patches to the main project. That way, the maintainer doesn’t have to do any integration work — just a fast-forward or a clean apply.
 
diff --git a/pl/03-git-branching/01-chapter3.markdown b/pl/03-git-branching/01-chapter3.markdown
index d0538f3aa..db73ebf01 100644
--- a/pl/03-git-branching/01-chapter3.markdown
+++ b/pl/03-git-branching/01-chapter3.markdown
@@ -507,7 +507,7 @@ W tym momencie możesz wrócić do gałęzi `master` i scalić zmiany wykonując
 Insert 18333fig0330.png 
 Figure 3-30. Przesunięcie gałęzi master po operacji zmiany bazy.
 
-Teraz migawka wskazywana przez C3 jest dokładnie taka sama jak ta, na którą wskazuje C5 w przykładzie ze scalaniem. Nie ma różnicy w produkcie końcowym integracji. Zmiana bazy tworzy jednak czystszą historię. Jeśli przejrzysz historię gałęzi po operacji `rebase`, wygląda ona na liniową: wygląda jakby cała praca była wykonywana stopniowo, nawet jeśli oryginalnie odbywała się równolegle.
+Teraz migawka wskazywana przez C3' jest dokładnie taka sama jak ta, na którą wskazuje C5 w przykładzie ze scalaniem. Nie ma różnicy w produkcie końcowym integracji. Zmiana bazy tworzy jednak czystszą historię. Jeśli przejrzysz historię gałęzi po operacji `rebase`, wygląda ona na liniową: wygląda jakby cała praca była wykonywana stopniowo, nawet jeśli oryginalnie odbywała się równolegle.
 
 Warto korzystać z tej funkcji, by mieć pewność, że rewizje zaaplikują się w bezproblemowy sposób do zdalnej gałęzi - być może w projekcie w którym próbujesz się udzielać, a którym nie zarządzasz. W takim wypadku będziesz wykonywał swoją pracę we własnej gałęzi, a następnie zmieniał jej bazę na `origin/master`, jak tylko będziesz gotowy do przesłania własnych poprawek do głównego projektu. W ten sposób osoba utrzymująca projekt nie będzie musiała dodatkowo wykonywać integracji - jedynie prostolinijne scalenie lub czyste zastosowanie zmian.
 
diff --git a/vi/03-git-branching/01-chapter3.markdown b/vi/03-git-branching/01-chapter3.markdown
index 83d9fd012..bfbb364b1 100644
--- a/vi/03-git-branching/01-chapter3.markdown
+++ b/vi/03-git-branching/01-chapter3.markdown
@@ -506,7 +506,7 @@ Hình 3-29. Quá trình rebase thay đổi ở C3 vào C4.
 Insert 18333fig0330.png
 Hình 3-30. Di chuyển nhánh master lên phía trước.
 
-Bây giờ snapshot mà C3 trỏ tới cũng giống như snapshot được trở tới bởi C5 trong ví dụ sử dụng merge. Không có sự khác biệt nào khi so sánh kết quả của hai phương pháp này, nhưng sử dụng rebase sẽ cho chúng ta lịch sử rõ ràng hơn. Nếu bạn xem xét lịch sử của nhánh mà chúng ta rebase vào, nó giống như một đường thẳng: mọi thứ dường như xảy ra theo trình tự, thậm chí ban đầu nó diễn ra song song.
+Bây giờ snapshot mà C3' trỏ tới cũng giống như snapshot được trở tới bởi C5 trong ví dụ sử dụng merge. Không có sự khác biệt nào khi so sánh kết quả của hai phương pháp này, nhưng sử dụng rebase sẽ cho chúng ta lịch sử rõ ràng hơn. Nếu bạn xem xét lịch sử của nhánh mà chúng ta rebase vào, nó giống như một đường thẳng: mọi thứ dường như xảy ra theo trình tự, thậm chí ban đầu nó diễn ra song song.
 
 
 Bình thường, bạn sử dụng cách này để đảm bảo rằng các commit được áp dụng một cách rõ ràng, rành mạch trên nhánh remote - có lẽ là một dự án mà bạn đang đóng góp chứ không phải duy trì nó. Trong trường hợp này, bạn thực hiện công việc trên một nhánh và sau đó rebase trở lại nhánh `origin/master` khi đã sẵn sàng. Theo cách này thì người duy trì dự án đó không phải thực hiện việc tích hợp - mà chỉ chi chuyển tiến lên phía trước (fast-forwar) hoặc đơn giản là áp dụng chúng vào.
@@ -595,4 +595,4 @@ Nếu bạn sử dụng rebase như là cách để dọn dẹp các commit trư
 
 ## Tổng Kết ##
 
-Chúng ta đã đề cập tới các khái niệm cơ bản về phân nhánh và tích hợp trong Git. Bạn nên nắm vững việc tạo mới, di chuyển giữa các nhánh và tích hợp các nhánh nội bộ lại với nhau. Bạn cũng nên có khả năng chia sẽ các nhánh bằng cách đẩy chúng lên một máy chủ trung tâm, cộng tác với các thành viên khác trên các nhánh dùng chung và rebase chúng trước khi chia sẻ.
\ No newline at end of file
+Chúng ta đã đề cập tới các khái niệm cơ bản về phân nhánh và tích hợp trong Git. Bạn nên nắm vững việc tạo mới, di chuyển giữa các nhánh và tích hợp các nhánh nội bộ lại với nhau. Bạn cũng nên có khả năng chia sẽ các nhánh bằng cách đẩy chúng lên một máy chủ trung tâm, cộng tác với các thành viên khác trên các nhánh dùng chung và rebase chúng trước khi chia sẻ.

From 2a5c6e4dd44f7294cac88b85e457fc6899babe11 Mon Sep 17 00:00:00 2001
From: Jiri Engelthaler <engycz@gmail.com>
Date: Tue, 11 Feb 2014 18:56:27 +0100
Subject: [PATCH 216/690] Some changes to czech version - same double part of
 sentence, changed inflections of 'syntax' word, 280->2^80

---
 cs/02-git-basics/01-chapter2.markdown      |  2 +-
 cs/05-distributed-git/01-chapter5.markdown |  4 ++--
 cs/06-git-tools/01-chapter6.markdown       | 18 +++++++++---------
 cs/07-customizing-git/01-chapter7.markdown |  4 ++--
 4 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/cs/02-git-basics/01-chapter2.markdown b/cs/02-git-basics/01-chapter2.markdown
index 82ffcc030..b8b37c4c0 100644
--- a/cs/02-git-basics/01-chapter2.markdown
+++ b/cs/02-git-basics/01-chapter2.markdown
@@ -221,7 +221,7 @@ Chcete-li vidět, co jste změnili, avšak ještě nepřipravili k zapsání, za
 
 Tento příkaz srovná obsah vašeho pracovního adresáře a oblasti připravených změn. Výsledek vám ukáže provedené změny, které jste dosud nepřipravili k zapsání.
 
-Chcete-li vidět, co jste připravili a co bude součástí příští revize, použijte a co bude součástí příští revize, použijte příkaz `git diff --cached`. (Ve verzích Git 1.6.1 a novějších můžete použít také příkaz `git diff --staged`, který se možná snáze pamatuje.) Tento příkaz srovná připravené změny s poslední revizí:
+Chcete-li vidět, co jste připravili a co bude součástí příští revize, použijte příkaz `git diff --cached`. (Ve verzích Git 1.6.1 a novějších můžete použít také příkaz `git diff --staged`, který se možná snáze pamatuje.) Tento příkaz srovná připravené změny s poslední revizí:
 
 	$ git diff --cached
 	diff --git a/README b/README
diff --git a/cs/05-distributed-git/01-chapter5.markdown b/cs/05-distributed-git/01-chapter5.markdown
index b4be707b8..e046c1f2d 100644
--- a/cs/05-distributed-git/01-chapter5.markdown
+++ b/cs/05-distributed-git/01-chapter5.markdown
@@ -740,11 +740,11 @@ Můžete tedy explicitně najít společného předka obou větví a spustit na
 	36c7dba2c95e6bbb78dfa822519ecfec6e1ca649
 	$ git diff 36c7db
 
-To však není příliš pohodlný způsob, a proto Git nabízí jinou možnost, jak lze provést stejnou věc: trojtečkovou syntax. V kontextu příkazu `diff` můžete vložit tři tečky za druhou větev – získáte výpis `diff` mezi poslední revizí větve, na níž se nacházíte, a společným předkem s druhou větví:
+To však není příliš pohodlný způsob, a proto Git nabízí jinou možnost, jak lze provést stejnou věc: trojtečkovou syntaxi. V kontextu příkazu `diff` můžete vložit tři tečky za druhou větev – získáte výpis `diff` mezi poslední revizí větve, na níž se nacházíte, a společným předkem s druhou větví:
 
 	$ git diff master...contrib
 
-Tento příkaz zobrazí pouze práci, která byla ve vaší aktuální tematické větvi provedena od chvíle, kdy se oddělila od hlavní větve. Určitě uděláte dobře, pokud si tuto syntax zapamatujete.
+Tento příkaz zobrazí pouze práci, která byla ve vaší aktuální tematické větvi provedena od chvíle, kdy se oddělila od hlavní větve. Určitě uděláte dobře, pokud si tuto syntaxi zapamatujete.
 
 ### Integrace příspěvků ###
 
diff --git a/cs/06-git-tools/01-chapter6.markdown b/cs/06-git-tools/01-chapter6.markdown
index 55eaa1bd3..33cb6cc95 100644
--- a/cs/06-git-tools/01-chapter6.markdown
+++ b/cs/06-git-tools/01-chapter6.markdown
@@ -59,7 +59,7 @@ Někteří uživatelé bývají zmateni, že mohou mít v repozitáři – shodo
 
 Pokud náhodou zapíšete objekt, který má stejnou hodnotu SHA-1 otisku jako předchozí objekt ve vašem repozitáři, Git už uvidí předchozí objekt v databázi Git a bude předpokládat, že už byl zapsán. Pokud se někdy v budoucnosti pokusíte znovu provést checkout tohoto objektu, vždy dostanete data prvního objektu.
 
-Měli bychom však také říci, jak moc je nepravděpodobné, že taková situace nastane. Otisk SHA-1 má 20 bytů, neboli 160 bitů. Počet objektů s náhodným otiskem, které bychom potřebovali k 50% pravděpodobnosti, že nastane jediná kolize, je asi 280 (vzorec k určení pravděpodobnosti kolize je `p = (n(n-1)/2) * (1/2^160))`. 2^80 je 1,2 * 10^24, neboli 1 milion miliard miliard. To je 1200násobek počtu všech zrnek písku na celé Zemi.
+Měli bychom však také říci, jak moc je nepravděpodobné, že taková situace nastane. Otisk SHA-1 má 20 bytů, neboli 160 bitů. Počet objektů s náhodným otiskem, které bychom potřebovali k 50% pravděpodobnosti, že nastane jediná kolize, je asi 2^80 (vzorec k určení pravděpodobnosti kolize je `p = (n(n-1)/2) * (1/2^160))`. 2^80 je 1,2 * 10^24, neboli 1 milion miliard miliard. To je 1200násobek počtu všech zrnek písku na celé Zemi.
 
 Abyste si udělali představu, jak je nepravděpodobné, že dojde ke kolizi hodnot SHA-1, připojujeme jeden malý příklad. Kdyby 6,5 miliardy lidí na zemi programovalo a každý by každou sekundu vytvořil kód odpovídající celé historii linuxového jádra (1 milion objektů Git) a odesílal ho do jednoho obřího repozitáře Git, trvalo by 5 let, než by repozitář obsahoval dost objektů na to, aby existovala 50% pravděpodobnost, že dojde ke kolizi jediného objektu SHA-1. To už je pravděpodobnější, že všichni členové vašeho programovacího týmu budou během jedné noci v navzájem nesouvisejících incidentech napadeni a zabiti smečkou vlků.
 
@@ -94,7 +94,7 @@ Pokaždé, když je z nějakého důvodu aktualizován vrchol větve, Git tuto i
 
 	$ git show HEAD@{5}
 
-Tuto syntax můžete použít také k zobrazení pozice, na níž se větev nacházela před určitou dobou. Chcete-li například zjistit, kde byla vaše větev `master` včera (yesterday), můžete zadat příkaz:
+Tuto syntaxi můžete použít také k zobrazení pozice, na níž se větev nacházela před určitou dobou. Chcete-li například zjistit, kde byla vaše větev `master` včera (yesterday), můžete zadat příkaz:
 
 	$ git show master@{yesterday}
 
@@ -146,7 +146,7 @@ Zobrazit předchozí revizi pak můžete pomocí `HEAD^`, což doslova znamená
 
 	    Merge commit 'phedders/rdocs'
 
-Za znakem `^` můžete zadat také číslo, např. `d921970^2` označuje „druhého rodiče revize d921970“. Tato syntax má význam pouze u revizí vzniklých sloučením, které mají více než jednoho rodiče. První rodič je větev, na níž jste se během začlenění nacházeli, druhým rodičem je větev, kterou jste začleňovali:
+Za znakem `^` můžete zadat také číslo, např. `d921970^2` označuje „druhého rodiče revize d921970“. Tato syntaxe má význam pouze u revizí vzniklých sloučením, které mají více než jednoho rodiče. První rodič je větev, na níž jste se během začlenění nacházeli, druhým rodičem je větev, kterou jste začleňovali:
 
 	$ git show d921970^
 	commit 1c002dd4b536e7479fe34593e72e6c6c1819e53b
@@ -188,7 +188,7 @@ Nyní, když umíte určit jednotlivé revize, podíváme se, jak lze určovat c
 
 #### Dvě tečky ####
 
-Nejčastěji se při označení intervalu používá dvojtečková syntax. Pomocí ní systému Git v podstatě říkáte, aby uvažoval celý interval revizí, které jsou dostupné z jedné revize, ale nejsou dostupné z jiné. Předpokládejme tedy, že máte historii revizí jako na obrázku 6-1.
+Nejčastěji se při označení intervalu používá dvojtečková syntaxe. Pomocí ní systému Git v podstatě říkáte, aby uvažoval celý interval revizí, které jsou dostupné z jedné revize, ale nejsou dostupné z jiné. Předpokládejme tedy, že máte historii revizí jako na obrázku 6-1.
 
 Insert 18333fig0601.png
 Obrázek 6-1. Příklad historie revizí pro výběr intervalu
@@ -205,7 +205,7 @@ A samozřejmě si můžete nechat zobrazit i pravý opak, všechny revize ve vě
 	F
 	E
 
-Tento log využijete, pokud chcete udržovat větev `experiment` stále aktuální a zjistit, co hodláte začlenit. Tato syntax se velmi často používá také ke zjištění, co hodláte odeslat do vzdálené větve:
+Tento log využijete, pokud chcete udržovat větev `experiment` stále aktuální a zjistit, co hodláte začlenit. Tato syntaxe se velmi často používá také ke zjištění, co hodláte odeslat do vzdálené větve:
 
 	$ git log origin/master..HEAD
 
@@ -214,13 +214,13 @@ Jednu stranu intervalu můžete zcela vynechat, Git na její místo automaticky
 
 #### Několik bodů ####
 
-Dvojtečková syntax je užitečná jako zkrácený výraz. Možná ale budete chtít k označení revize určit více než dvě větve, např. až budete chtít zjistit, které revize jsou obsaženy ve všech ostatních větvích a zároveň nejsou obsaženy ve větvi, na níž se právě nacházíte. V systému Git to můžete provést buď zadáním znaku `^` nebo parametru `--not` před referencí, jejíž dostupné revize si nepřejete zobrazit. Tyto tři příkazy jsou tedy ekvivalentní:
+Dvojtečková syntaxe je užitečná jako zkrácený výraz. Možná ale budete chtít k označení revize určit více než dvě větve, např. až budete chtít zjistit, které revize jsou obsaženy ve všech ostatních větvích a zároveň nejsou obsaženy ve větvi, na níž se právě nacházíte. V systému Git to můžete provést buď zadáním znaku `^` nebo parametru `--not` před referencí, jejíž dostupné revize si nepřejete zobrazit. Tyto tři příkazy jsou tedy ekvivalentní:
 
 	$ git log refA..refB
 	$ git log ^refA refB
 	$ git log refB --not refA
 
-Tato syntax je užitečná zejména proto, že pomocí ní můžete zadat více než dvě reference, což není pomocí dvojtečkové syntaxe možné. Pokud chcete zobrazit například všechny revize, které jsou dostupné ve větvi `refA` nebo `refB`, ale nikoli ve větvi `refC`, zadejte jeden z následujících příkazů:
+Tato syntaxe je užitečná zejména proto, že pomocí ní můžete zadat více než dvě reference, což není pomocí dvojtečkové syntaxe možné. Pokud chcete zobrazit například všechny revize, které jsou dostupné ve větvi `refA` nebo `refB`, ale nikoli ve větvi `refC`, zadejte jeden z následujících příkazů:
 
 	$ git log refA refB ^refC
 	$ git log refA refB --not refC
@@ -229,7 +229,7 @@ Tím máte v rukou velmi efektivní systém vyhledávání revizí, který vám
 
 #### Tři tečky ####
 
-Poslední významnou syntaxí k určení intervalu je trojtečková syntax, která vybere všechny revize dostupné ve dvou referencích, ale ne v obou zároveň. Podívejme se ještě jednou na příklad historie revizí na obrázku 6-1.
+Poslední významnou syntaxí k určení intervalu je trojtečková syntaxe, která vybere všechny revize dostupné ve dvou referencích, ale ne v obou zároveň. Podívejme se ještě jednou na příklad historie revizí na obrázku 6-1.
 Chcete-li zjistit, co je ve větvi `master` nebo `experiment`, ale nechcete vidět jejich společné reference, zadejte příkaz:
 
 	$ git log master...experiment
@@ -1014,7 +1014,7 @@ Dobrým způsobem, jak to v systému Git provést, je učinit ze všech podslož
 
 ### Problémy se submoduly ###
 
-Používání submodulů se však vždy neobejde bez zádrhelů. Zaprvé je třeba, abyste si v adresáři submodulu počínali opatrně. Spustíte-li příkaz `git submodule update`, provedete tím checkout konkrétní verze projektu, avšak nikoli v rámci větve. Říká se tomu oddělená hlava (detached head) – znamená to, že soubor HEAD ukazuje přímo na revizi, ne na symbolickou referenci. Problém je, že většinou nechcete pracovat v prostředí oddělené hlavy, protože tu velmi snadno přijdete o provedené změny. Jestliže nejprve spustíte příkaz `submodule update`, zapíšete v adresáři tohoto submodulu revizi, aniž byste na tuto práci vytvořili novou větev, a poté ze superprojektu znovu spustíte příkaz `git submodule update`, aniž byste mezitím zapisovali revize, Git vaše revize bez varování přepíše. Technicky vzato práci neztratíte, ale nebude žádná větev, která by na ni ukazovala, a tak bude poněkud obtížené získat práci zpět.
+Používání submodulů se však vždy neobejde bez zádrhelů. Zaprvé je třeba, abyste si v adresáři submodulu počínali opatrně. Spustíte-li příkaz `git submodule update`, provedete tím checkout konkrétní verze projektu, avšak nikoli v rámci větve. Říká se tomu oddělená hlava (detached head) – znamená to, že soubor HEAD ukazuje přímo na revizi, ne na symbolickou referenci. Problém je, že většinou nechcete pracovat v prostředí oddělené hlavy, protože byste tak velmi snadno mohli přijít o provedené změny. Jestliže nejprve spustíte příkaz `submodule update`, zapíšete v adresáři tohoto submodulu revizi, aniž byste na tuto práci vytvořili novou větev, a poté ze superprojektu znovu spustíte příkaz `git submodule update`, aniž byste mezitím zapisovali revize, Git vaše revize bez varování přepíše. Technicky vzato práci neztratíte, ale nebude žádná větev, která by na ni ukazovala, a tak bude poněkud obtížené získat práci zpět.
 
 Aby ve vašem projektu k tomuto problému nedošlo, vytvořte během práce v adresáři submodulu příkazem `git checkout -b work` nebo podobným novou větev. Až budete podruhé provádět příkaz submodule update, i tentokrát sice vrátí vaši práci, ale přinejmenším budete mít ukazatel, k němuž se budete moci vrátit.
 
diff --git a/cs/07-customizing-git/01-chapter7.markdown b/cs/07-customizing-git/01-chapter7.markdown
index ad1bb57d0..54d0ca3a5 100644
--- a/cs/07-customizing-git/01-chapter7.markdown
+++ b/cs/07-customizing-git/01-chapter7.markdown
@@ -924,11 +924,11 @@ Jako příklad uvedeme skript pre-rebase, který bude toto pravidlo kontrolovat.
 	  end
 	end
 
-Tento skript používá syntax, které jsme se v části Výběr revize v kapitole 6 nevěnovali. Seznam revizí, které už byly odeslány, získáte takto:
+Tento skript používá syntaxi, které jsme se v části Výběr revize v kapitole 6 nevěnovali. Seznam revizí, které už byly odeslány, získáte takto:
 
 	git rev-list ^#{sha}^@ refs/remotes/#{remote_ref}
 
-Syntax `SHA^@` se vztahuje na všechny rodiče této revize. Vyhledáváte všechny revize, které jsou dostupné z poslední revize na vzdáleném serveru a nejsou dostupné z žádného rodiče jakékoli hodnoty SHA, kterou se pokoušíte odeslat. Tímto způsobem lze označit odeslání „rychle vpřed“.
+Syntaxe `SHA^@` se vztahuje na všechny rodiče této revize. Vyhledáváte všechny revize, které jsou dostupné z poslední revize na vzdáleném serveru a nejsou dostupné z žádného rodiče jakékoli hodnoty SHA, kterou se pokoušíte odeslat. Tímto způsobem lze označit odeslání „rychle vpřed“.
 
 Největší nevýhodou tohoto postupu je, že může být velmi pomalý a není vždy nutný. Pokud se nesnažíte vynutit si odeslání parametrem `-f`, server vás sám upozorní a odesílané revize nepřijme. Skript je však zajímavým cvičením a teoreticky vám může pomoci předejít nutnosti vracet se v historii a přeskládávat revize kvůli opravě chyby.
 

From e076aae4e88dfa60a706cb014486e6b236c8b3bb Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Wed, 12 Feb 2014 23:11:25 -0600
Subject: [PATCH 217/690] [it] reviewed translation chapter2

---
 it/02-git-basics/01-chapter2.markdown | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/it/02-git-basics/01-chapter2.markdown b/it/02-git-basics/01-chapter2.markdown
index 25de9ca5e..6c2b29368 100644
--- a/it/02-git-basics/01-chapter2.markdown
+++ b/it/02-git-basics/01-chapter2.markdown
@@ -1,26 +1,26 @@
 # Basi di Git #
 
-Se puoi leggere solo un capitolo per capire l'uso di Git, questo fa per te.  Questo capitolo illustra tutti i comandi base per fare la stragrande maggioranza delle cose impiegando al meglio il tuo tempo con Git. Alla fine del capitolo, dovresti essere in grado di configurare ed inizializzare un repository, avviare e fermare il tracciamento dei file e mettere in stage o eseguire il commit dei cambiamenti. Vedremo come impostare Git per ignorare certi file o pattern di file, come correggere gli errori velocemente e facilmente, come navigare nella storia del tuo progetto e vedere i cambiamenti tra i vari commit e come fare il push ed il pull da repository remoti.
+Se puoi leggere un solo capitolo per imparare Git, leggi questo.  Questo capitolo illustra tutti i comandi base di cui hai bisogno per la stragrande maggioranza delle cose che farai con Git. Alla fine del capitolo sarai in grado di configurare e creare un repository, iniziare e interrompere il tracciamento dei file e mettere in stage e committare le modifiche. Vedremo come impostare Git per ignorare certi file o pattern, come annullare velocemente e facilmente gli errori, come navigare la cronologia del tuo progetto e vedere le modifiche tra le varie commit e come fare il push ed il pull da repository remoti.
 
-## Ottenere un Repository Git ##
+## Repository Git ##
 
-Puoi creare un progetto Git usando due approcci principali. Il primo prende un progetto esistente o una directory e la importa in Git. Il secondo clona un repository Git esistente da un altro server.
+Puoi creare un progetto Git principalmente con due approcci. Il primo prende un progetto esistente o una directory e la importa in Git. Il secondo clona un repository Git esistente, su un altro server.
 
-### Inizializzare un Repository in una Directory Esistente ###
+### Creare un repository in una directory preesistente ###
 
-Se stai iniziando a tracciare un progetto esistente con Git, devi posizionarti nella directory del progetto e digitare:
+Se vuoi iniziare a tenere traccia con Git di un progetto esistente, devi andare nella directory del progetto e digitare:
 
 	$ git init
 
-Questo creerà una nuova sottodirectory chiamata .git che conterrà tutti i file necessari per il repository — uno scheletro del repository Git. A questo punto, niente del tuo progetto è già tracciato. (Vedi il Capitolo 9 per avere maggiori informazioni esatte sui file che sono contenuti nella directory `.git` che hai appena creato.)
+Questo creerà una nuova sottodirectory chiamata .git che conterrà tutti i file necessari per il tuo repository: una struttura del repository Git. A questo punto non è ancora stato tracciato niente del tuo progetto. (Vedi il *Capitolo 9* per sapere quali file sono contenuti nella directory `.git` che hai appena creato.)
 
-Se vuoi iniziare a tracciare i file esistenti (al contrario di una directory vuota), dovresti iniziare a monitorare questi file eseguendo un commit iniziale. Lo puoi fare con pochi comandi che specificano quali file vuoi controllare, seguiti da un commit: 
+Se vuoi iniziare a tracciare i file esistenti (a differenza di una directory vuota), dovresti iniziare a monitorare questi file con una commit iniziale. Lo puoi fare con pochi comandi `git add`, che specificano quali file vuoi tracciare, seguiti da un commit: 
 
 	$ git add *.c
 	$ git add README
 	$ git commit -m 'initial project version'
 
-Vedremo in seguito velocemente cosa fanno questi comandi. A questo punto hai un repository Git con dei file tracciati ed un commit iniziale.
+Tra un minuto vedremo cosa fanno questi comandi. A questo punto hai un repository Git con dei file tracciati e una commit iniziale.
 
 ### Clonare un Repository Esistente ###
 

From 31c0a17a0869ac302c47505a577e04b10a3c0ce8 Mon Sep 17 00:00:00 2001
From: cor <git@cpt1.demon.nl>
Date: Fri, 14 Feb 2014 21:17:52 +0100
Subject: [PATCH 218/690] [nl] Chapter 02. Review, include new command output
 and add header.

   Reviewed translations and made them more consistent and in line with
   the recommendations of the Dutch language institute.
   Added a header to that effect to the file.
   Included the new modified command output.
---
 nl/02-git-basics/01-chapter2.markdown | 530 ++++++++++++++------------
 1 file changed, 293 insertions(+), 237 deletions(-)

diff --git a/nl/02-git-basics/01-chapter2.markdown b/nl/02-git-basics/01-chapter2.markdown
index 4871c86a3..48f865390 100644
--- a/nl/02-git-basics/01-chapter2.markdown
+++ b/nl/02-git-basics/01-chapter2.markdown
@@ -1,20 +1,35 @@
+<!-- Attentie heren en dames vertalers.
+
+Ik zou het volgende willen voorstellen:
+Er zijn bepaalde termen die voor de gemiddelde Nederlandse computer gebruiker veel beter klinken (of bekender voorkomen) als de orginele Engelse term. In het begin zullen deze termen niet vaak voorkomen, maar in de meer diepgaandere hoofdstukken komen deze steeds meer voor. Termen als "Committen", "Mergen" en "Applyen" klinken beter dan "Plegen" of "Toepassen", "Samenvoegen" en "Toepassen" (wat bovendien slecht valt te onderscheiden van de commit-toepassing). De mensen die dit boek lezen zijn, naar mijn bescheiden inschatting, al redelijk op de hoogte van versiebeheer en passen (zie ik in de praktijk) deze termen al toe. Een nieuwe terminologie introduceren lijkt me dan ook niet noodzakelijk.
+Verder blijven er altijd kreten over als "directory", wat vertaald zou kunnen worden als "map", maar bij het Engelse werkwoord to map, krijgen we dan weer het probleem: hoe dit weer te vertalen. Daarom zou ik willen voorstellen om deze basis-termen toch onvertaald te laten.
+Twijfelgevallen zullen altijd blijven zoals de term "file", daarvan wordt in de praktijk zowel de term file als bestand gebruikt. Ik denk dat we hier moeten kijken hoe het in de context past. 
+Maar ook een term als "tool" en (ik zit zelf nog op een mooie Nederlandse term te broeden) "plumbing", hierbij stel ik voor om eenmalig een Nederlandse vertaling te geven, tussen haakjes de Engelse term te geven en in het vervolg de Engelse term te gebruiken. Wederom is de context hier belangrijk.
+
+Verder stel ik ook voor om de regels op https://onzetaal.nl/taaladvies zoveel mogelijk te volgen. Bijvoorbeeld de regels omtrent het spellen van Engelse werkwoorden die in het Nederlands gebruikt worden.
+
+Let wel: ik wil niemand tot iets verplichten, maar ik denk dat we moeten streven naar een zo duidelijk mogelijke en best bij de praktijk aansluitende vertaling moeten proberen te maken.
+
+Veel succes en plezier bij het vertalen...
+
+-->
 # De basis van Git #
 
-Als je slechts één hoofdstuk kunt lezen om met Git aan de slag te gaan, dan is dit het. Dit hoofdstuk behandelt elk van de basiscommando's, die je nodig hebt om het leeuwendeel van de dingen te doen waarmee je uiteindelijk je tijd met Git zult doorbrengen. Als je dit hoofdstuk doorgenomen hebt, zul je een archief (repository) kunnen configureren en initialiseren, bestanden beginnen en stoppen te volgen en veranderingen te ‘stagen’ en ‘committen’. We laten ook zien hoe je Git kunt instellen zodat het bepaalde bestanden en bestandspatronen negeert, hoe je vergissingen snel en gemakkelijk ongedaan kunt maken, hoe je de geschiedenis van je project kan doorlopen en wijzigingen tussen commits kunt zien, en hoe je kunt pushen en pullen van en naar andere repositories.
+Als je slechts één hoofdstuk kunt lezen om met Git aan de slag te gaan, dan is deze het. In dit hoofdstuk worden alle basiscommando's behandeld, die je nodig hebben om het leeuwendeel van de dingen te doen waarmee je uiteindelijk je tijd met Git zult doorbrengen. Als je dit hoofdstuk doorgenomen hebt, zul je een repository kunnen configureren en initialiseren, bestanden beginnen en stoppen te volgen en veranderingen te ‘stagen’ en ‘committen’. We laten ook zien hoe je Git kunt instellen zodat het bepaalde bestanden en bestandspatronen negeert, hoe je vergissingen snel en gemakkelijk ongedaan kunt maken, hoe je de geschiedenis van je project kan doorlopen en wijzigingen tussen commits kunt zien, en hoe je kunt pushen en pullen van en naar repositories.
 
 ## Een Git repository verkrijgen ##
 
-Je kunt op twee manieren een Git project verkrijgen. De eerste maakt gebruik van een bestaand project of map en importeert dit in Git. De tweede maakt een kloon (clone) van een bestaande Git repository op een andere server.
+Je kunt op twee manieren een Git project verkrijgen. De eerste maakt gebruik van een bestaand project of directory en importeert dit in Git. De tweede maakt een kloon (clone) van een bestaande Git repository op een andere server.
 
-### Een repository initialiseren in een bestaande map ###
+### Een repository initialiseren in een bestaande directory ###
 
-Als je een bestaand project in Git wilt volgen (track), dan moet je naar de projectmap gaan en het volgende typen
+Als je een bestaand project in Git wilt volgen (tracken), dan moet je naar de projectdirectory gaan en het volgende typen
 
 	$ git init
 
-Dit maakt een nieuwe submap aan genaamd `.git`, die alle noodzakelijke repository bestanden bevat — een Git repository skelet. Op dit punt wordt nog niets in je project gevolgd. (Zie Hoofdstuk 9 voor meer informatie over welke bestanden er precies in de `.git` map staan, die je zojuist gemaakt hebt.)
+Dit maakt een nieuwe subdirectory met de naam `.git` aan, die alle noodzakelijke repository bestanden bevat, een Git repository raamwerk. Op dit moment wordt nog niets in je project gevolgd. (Zie *Hoofdstuk 9* voor meer informatie over welke bestanden er precies in de `.git` directory staan, die je zojuist gemaakt hebt.)
 
-Als je de versies van bestaande bestanden wilt gaan beheren (in plaats van een lege map), dan zul je waarschijnlijk die bestanden beginnen te volgen en een eerste commit willen doen. Dit kun je bereiken door een paar git add commando's die de te volgen bestanden specificeren, gevolgd door een commit:
+Als je de versies van bestaande bestanden wilt gaan beheren (in plaats van een lege directory), dan zul je die bestanden moeten beginnen te tracken en een eerste commit doen. Dit kun je bereiken door een paar `git add` commando's waarin je de te volgen bestanden specificeert, gevolgd door een commit:
 
 	$ git add *.c
 	$ git add README
@@ -22,44 +37,44 @@ Als je de versies van bestaande bestanden wilt gaan beheren (in plaats van een l
 
 We zullen zodadelijk beschrijven wat deze commando's doen. Op dit punt heb je een Git repository met gevolgde (tracked) bestanden en een initiële commit.
 
-### Een bestaand repository klonen ###
+### Een bestaand repository clonen ###
 
-Als je een kopie wilt van een bestaande Git repository — bijvoorbeeld een project waaraan je wilt bijdragen — dan is `git clone` het commando wat je nodig hebt. Als je bekend bent met andere versie-beheersystemen zoals Subversion, dan valt je op dat het commando `clone` is en niet `checkout`. Dit is een belangrijk verschil — Git ontvangt een kopie van bijna alle data die de server heeft. Iedere versie van ieder bestand van de hele geschiedenis van een project wordt binnengehaald als je `git clone` doet. In feite kun je, als je disk kapot gaat, iedere kloon van iedere client gebruiken om de server terug in de status te brengen op het moment van klonen (al zou je wel wat hooks en dergelijke verliezen, maar alle versies van alle bestanden zouden er zijn — zie *Hoofdstuk 4* voor meer informatie).
+Als je een kopie wilt van een bestaande Git repository, bijvoorbeeld een project waaraan je wilt bijdragen, dan is `git clone` het commando dat je nodig hebt. Als je bekend bent met andere versie-beheersystemen zoals Subversion, dan zal het je opvallen dat het commando `clone` is en niet `checkout`. Dit is een belangrijk verschil: Git ontvangt een kopie van bijna alle gegevens die de server heeft. Elke versie van ieder bestand in de hele geschiedenis van een project wordt binnengehaald als je `git clone` doet. In feite kun je als de schijf van de server kapot gaat, een clone van een willekeurige client gebruiken om de server terug in de status te brengen op het moment van clonen (al zou je wel wat hooks aan de kant van de server en dergelijke verliezen, maar alle versies van alle bestanden zullen er zijn; zie *Hoofdstuk 4* voor meer informatie).
 
-Je kloont een repository met `git clone [url]`. Bijvoorbeeld, als je de Ruby Git bibliotheek genaamd Grit wilt klonen, kun je dit als volgt doen:
+Je cloned een repository met `git clone [url]`. Bijvoorbeeld, als je de Ruby Git bibliotheek genaamd Grit wilt clonen, kun je dit als volgt doen:
 
 	$ git clone git://github.com/schacon/grit.git
 
-Dat maakt een map genaamd `grit` aan, initialiseert hierin een `.git` map, haalt alle data voor dat repository binnen, en doet een checkout van een werkkopie van de laatste versie. Als je in de nieuwe `grit` map gaat, zul je de project bestanden vinden, klaar om gebruikt of aan gewerkt te worden. Als je de repository in een map met een andere naam dan grit wilt klonen, dan kun je dit met het volgende commando specificeren:
+Dat maakt een directory genaamd `grit` aan, initialiseert hierin een `.git` directory, haalt alle data voor die repository binnen en doet een checkout van een werkkopie van de laatste versie. Als je in de nieuwe `grit` directory gaat kijken zal je de project bestanden vinden, klaar om gebruikt of aan gewerkt te worden. Als je de repository in een directory met een andere naam dan grit wilt clonen, dan kun je dit met het volgende commando specificeren:
 
 	$ git clone git://github.com/schacon/grit.git mygrit
 
-Dat commando doet hetzelfde als het vorige, maar dan heet de doelmap `mygrit`.
+Dat commando doet hetzelfde als het vorige, maar dan heet de doeldirectory `mygrit`.
 
-Git heeft een aantal verschillende transport protocollen die je kunt gebruiken. Het vorige voorbeeld maakt gebruik van het `git://` protocol, maar je kunt ook `http(s)://` of `gebruiker@server:/pad.git` tegenkomen, dat het SSH transport protocol gebruikt. *Hoofdstuk 4* zal alle beschikbare opties introduceren die de server kan gebruiken om je Git repository aan te kunnen, met daarbij de voors en tegens van elk.
+Git heeft een aantal verschillende transport protocollen die je kunt gebruiken. Het vorige voorbeeld maakt gebruik van het `git://` protocol, maar je kunt ook `http(s)://` of `gebruiker@server:/pad.git` tegenkomen, dat het SSH transport protocol gebruikt. *Hoofdstuk 4* zal alle beschikbare opties introduceren die de server kan inrichten om je toegang tot de Git repositories te geven, met daarbij de voors en tegens van elk.
 
 ## Wijzigingen aan het repository vastleggen ##
 
-Je hebt een bonafide Git repository en een checkout of werkkopie van de bestanden voor dat project. Je moet wat wijzigingen maken en deze committen in je repository, iedere keer zodra het project een status bereikt die je wilt vastleggen.
+Je hebt een eersteklas Git repository en een checkout of werkkopie van de bestanden binnen dat project. Als je wijzigingen maakt dan moet je deze committen in je repository op elk momend dat het project een status bereikt die je wilt vastleggen.
 
-Onthoud dat ieder bestand in je werkmap in twee statussen kan verkeren: *gevolgd (tracked)* of *niet gevolgd (untracked)*. *Gevolgde* bestanden zijn bestanden die in het laatste snapshot zaten; ze kunnen *ongewijzigd*, *gewijzigd* of *staged zijn*. *Niet gevolgde* bestanden zijn al het andere - ieder bestand in je werkmap dat niet in je laatste snapshot en niet in je staging gebied zit. Als je voor het eerst een repository kloont, zullen al je bestanden gevolgd en ongewijzigd zijn, omdat je ze zojuist ge-checkout en niet gewijzigd hebt.
+Onthoud dat elk bestand in je werkdirectory in een van twee statussen kan verkeren: *gevolgd (tracked)* of *niet gevolgd (untracked)*. *Tracked* bestanden zijn bestanden die in het laatste snapshot zaten; ze kunnen *ongewijzigd (unmodified)*, *gewijzigd (modified)* of *staged* zijn. *untracked* bestanden zijn al het andere; elk bestand in je werkdirectory dat niet in je laatste snapshot en niet in je staging area zit. Als je een repository voor het eerst cloned, zullen alle bestanden tracked en unmodified zijn, omdat je ze zojuist uitgechecked hebt en nog niets gewijzigd hebt.
 
-Zodra je bestanden wijzigt, ziet Git ze als gewijzigd omdat je ze veranderd hebt sinds je laatste commit. Je *staged* deze gewijzigde bestanden en commit al je ge-stagede wijzigingen, en de cyclus herhaalt zichzelf. Deze cyclus wordt in Figuur 2-1 geïllustreerd.
+Zodra je bestanden wijzigt, ziet Git ze als modified omdat je ze veranderd hebt sinds je laatste commit. Je *staged* deze gewijzigde bestanden en commit al je gestagede wijzigingen, en de cyclus begint weer van voor af aan. Deze cyclus wordt in Figuur 2-1 geïllustreerd.
 
 Insert 18333fig0201.png
 Figuur 2-1. De levenscyclus van de status van je bestanden.
 
 ### De status van je bestanden controleren ###
 
-Het hoofdcommando dat je zult gebruiken om te bepalen welk bestand zich in welke status bevindt is `git status`. Als je dit commando direct na het klonen uitvoert, dan zul je zoiets als het volgende zien:
+Het commando dat je voornamelijk zult gebruiken om te bepalen welk bestand zich in welke status bevindt is `git status`. Als je dit commando direct na het clonen uitvoert, dan zal je zoiets als het volgende zien:
 
 	$ git status
 	# On branch master
 	nothing to commit (working directory clean)
 
-Dit betekent dat je een schone werkmap hebt — met andere woorden, er zijn geen gevolgde en gewijzigde bestanden. Git ziet ook geen ongevolgde bestanden, anders zouden ze hier getoond worden. Als laatste vertelt het commando op welke tak (branch) je nu zit. Voor nu is dit altijd `master`, dat is de standaard; maak je je hier nog niet druk om. Het volgende hoofdstuk gaat in detail over takken en referenties.
+Dit betekent dat je een schone werkdirectory hebt, met andere woorden er zijn geen untracked bestanden die gewijzigd zijn. Git ziet ook geen untracked bestanden, anders zouden ze hier getoond worden. Als laatste vertelt het commando op welke tak (branch) je nu zit. Voor nu is dit altijd `master`, dat is de standaard; besteed daar voor nu nog geen aandacht aan. In het volgende hoofdstuk wordt gedetaileerd ingegaan op branches en referenties.
 
-Stel dat je een nieuw bestand toevoegt aan je project, een simpel README bestand. Als het bestand voorheen nog niet bestond, en je doet `git status`, dan zul je je ongevolgde bestand zo zien:
+Stel dat je een nieuw bestand toevoegt aan je project, een simpel README bestand. Als het bestand voorheen nog niet bestond, en je doet `git status`, dan zul je het niet getrackte bestand op deze manier zien:
 
 	$ vim README
 	$ git status
@@ -70,15 +85,15 @@ Stel dat je een nieuw bestand toevoegt aan je project, een simpel README bestand
 	#	README
 	nothing added to commit but untracked files present (use "git add" to track)
 
-Je kunt zien dat je nieuwe README bestand ongevolgd is, omdat het onder de “Untracked files” kop staat in je status output. Ongevolgd betekent eigenlijk dat Git een bestand ziet dat je niet in het vorige snapshot (commit) had; Git zal het niet in je commit snapshots toevoegen totdat jij haar er expliciet om vraagt. Ze doet dit zodat jij niet per ongeluk gegenereerde binaire bestanden toevoegt, of andere bestanden die je niet wou toevoegen. Je wilt dit README bestand wel toevoegen, dus laten we het gaan volgen.
+Je kunt zien dat het nieuwe README bestand untrackt is, omdat het onder de “Untracked files” kop staat in je status output. Untrackt betekent eigenlijk dat Git een bestand ziet dat je niet in het vorige snapshot (commit) had; Git zal het niet in je commit snapshots toevoegen totdat jij dit expliciet aangeeft. Dit wordt zo gedaan zodat je niet per ongeluk gegenereerde binaire bestanden toevoegt, of andere bestanden die je niet wilt toevoegen. Je wilt dit README bestand wel meenemen, dus laten we het gaan tracken.
 
 ### Nieuwe bestanden volgen (tracking) ###
 
-Om een nieuw bestand te beginnen te volgen, gebruik je het commando `git add`. Om de README te volgen, kun je dit uitvoeren:
+Om een nieuw bestand te beginnen te tracken, gebruik je het commando `git add`. Om de README te tracken, voer je dit uit:
 
 	$ git add README
 
-Als je je status commando nogmaals uitvoert, zie je dat je README bestand nu gevolgd en ge-staged is:
+Als je het status commando nogmaals uitvoert, zie je dat je README bestand nu getrackt en ge-staged is:
 
 	$ git status
 	# On branch master
@@ -88,26 +103,27 @@ Als je je status commando nogmaals uitvoert, zie je dat je README bestand nu gev
 	#	new file:   README
 	#
 
-Je kunt zien dat het ge-staged is, omdat het onder de kop “Changes to be committed” staat. Als je op dit punt een commit doet, zal de versie van het bestand zoals het wat ten tijde van je `git add` commando in de historische snapshot toegevoegd worden. Je zult je misschien herinneren dat, toen je `git init` eerder uitvoerde, je daarna `git add` (bestanden) uitvoerde — dat was om bestanden in je map te beginnen te volgen. Het `git add` commando neemt een padnaam voor een bestand of een map; als het een map is, dan voegt het commando alle bestanden in die map recursief toe.
+Je kunt zien dat het gestaged is, omdat het onder de kop “Changes to be committed” staat. Als je nu een commit doet, zal de versie van het bestand zoals het was ten tijde van je `git add` commando in de historische snapshot toegevoegd worden. Je zult je misschien herinneren dat, toen je `git init` eerder uitvoerde, je daarna `git add (bestanden)` uitvoerde; dat was om bestanden in je directory te beginnen te tracken. Het `git add` commando beschouwt een padnaam als een bestand of een directory. Als de padnaam een directory is, dan voegt het commando alle bestanden in die directory recursief toe.
 
 ### Gewijzigde bestanden stagen ###
 
-Laten we een gevolgd bestand wijzigen. Als je een voorheen gewijzigd bestand genaamd `benchmarks.rb` wijzigt, en dan je `status` commando nog eens uitvoert, krijg je iets dat er zo uitziet:
+Laten we een getrackte bestand wijzigen. Als je een reeds getrackt bestand genaamd `benchmarks.rb` wijzigt, en dan je `status` commando nog eens uitvoert, krijg je iets dat er zo uitziet:
 
 	$ git status
-	# On branch master
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#	new file:   README
-	#
-	# Changes not staged for commit:
-	#   (use "git add <file>..." to update what will be committed)
-	#
-	#	modified:   benchmarks.rb
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        new file:   README
 
-Het `benchmarks.rb` bestand verschijnt onder een sectie genaamd “Changes not staged for commit” — wat betekent dat een bestand dat gevolgd wordt gewijzigd is in de werkmap, maar nog niet ge-staged. Om het te stagen, voer je het `git add` commando uit (het is een veelzijdig commando — je gebruikt het om bestanden te volgen, om bestanden te stagen, en andere dingen zoals een bestand met een mergeconflict als opgelost te markeren). Laten we `git add` nu uitvoeren om het `benchmarks.rb` bestand nu te stagen, en dan nog eens `git status` uitvoeren:
+	Changes not staged for commit:
+	  (use "git add <file>..." to update what will be committed)
+	  (use "git checkout -- <file>..." to discard changes in working directory)
+	
+	        modified:   benchmarks.rb
+	
+
+Het `benchmarks.rb` bestand verschijnt onder een sectie genaamd “Changes not staged for commit”, wat inhoudt dat een bestand dat wordt getrackt is gewijzigd in de werkdirectory, maar nog niet is gestaged. Om het te stagen, voer je het `git add` commando uit (het is een veelzijdig commando: je gebruikt het om bestanden te laten tracken, om bestanden te stagen, en om andere dingen zoals een bestand met een mergeconflict als opgelost te markeren). Laten we nu `git add` uitvoeren om het `benchmarks.rb` bestand te stagen, en dan nog eens `git status` uitvoeren:
 
 	$ git add benchmarks.rb
 	$ git status
@@ -119,24 +135,25 @@ Het `benchmarks.rb` bestand verschijnt onder een sectie genaamd “Changes not s
 	#	modified:   benchmarks.rb
 	#
 
-Beide bestanden zijn ge-staged en zullen in je volgende commit gaan. Stel dat je je op dit punt herinnert dat je een kleine wijziging in `benchmarks.rb` wil maken voor je volgende commit. Je kunt het opnieuw openen en die wijziging maken, en dan ben je klaar voor de commit. Maar, laten we `git status` nog een keer uitvoeren:
+Beide bestanden zijn gestaged en zullen met je volgende commit meegaan. Stel nu dat je je herinnert dat je nog een kleine wijziging in `benchmarks.rb` wilt maken voordat je het commit. Je kunt het opnieuw openen en die wijziging maken, en dan ben je klaar voor de commit. Alhoewel, laten we `git status` nog een keer uitvoeren:
 
 	$ vim benchmarks.rb
 	$ git status
-	# On branch master
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#	new file:   README
-	#	modified:   benchmarks.rb
-	#
-	# Changes not staged for commit:
-	#   (use "git add <file>..." to update what will be committed)
-	#
-	#	modified:   benchmarks.rb
-	#
-
-Hé! Nu staat `benchmarks.rb` zowel bij de staged en unstaged. Hoe kan dat? Het blijkt dat Git een bestand staged precies zoals het is wanneer je het `git add` commando uitvoert. Als je nu commit, dan zal de versie van benchmarks.rb zoals het was toen je voor 't laatst `git add` uitvoerde worden toegevoegd in de commit, en niet de versie van het bestand zoals ie eruit ziet in je map wanneer je git commit uitvoert. Als je een bestand wijzigt nadat je `git add` uitvoert, dan moet je `git add` nogmaals uitvoeren om de laatste versie van het bestand te stagen:
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        new file:   README
+	        modified:   benchmarks.rb
+	
+	Changes not staged for commit:
+	  (use "git add <file>..." to update what will be committed)
+	  (use "git checkout -- <file>..." to discard changes in working directory)
+	
+	        modified:   benchmarks.rb
+	
+
+Asjemenou?! Nu staat `benchmarks.rb` zowel bij de staged en unstaged genoemd. Hoe is dat mogelijk? Het blijkt dat Git een bestand precies zoals het is staged wanneer je het `git add` commando uitvoert. Als je nu commit, dan zal de versie van `benchmarks.rb` zoals het was toen je voor 't laatst `git add` uitvoerde worden toegevoegd in de commit, en niet de versie van het bestand zoals het eruit ziet in je werkdirectory toen je `git commit` uitvoerde. Als je een bestand wijzigt nadat je `git add` uitvoert, dan moet je `git add` nogmaals uitvoeren om de laatste versie van het bestand te stagen:
 
 	$ git add benchmarks.rb
 	$ git status
@@ -150,22 +167,22 @@ Hé! Nu staat `benchmarks.rb` zowel bij de staged en unstaged. Hoe kan dat? Het
 
 ### Bestanden negeren ###
 
-Vaak zul je een klasse bestanden hebben waarvan je niet wilt dat Git deze automatisch toevoegt of zelfs maar als ongevolgd toont. Dit zijn doorgaans automatisch gegenereerde bestanden zoals logbestanden of bestanden die geproduceerd worden door je bouwsysteem. In die gevallen kun je een bestand genaamd `.gitignore` maken, waarin patronen staan die die bestanden passen. Hier is een voorbeeld van een `.gitignore` bestand:
+Vaak zul je een klasse bestanden hebben waarvan je niet wilt dat Git deze automatisch toevoegt of zelfs maar als untracked toont. Dit zijn doorgaans automatisch gegenereerde bestanden zoals logbestanden of bestanden die geproduceerd worden door je bouwsysteem. In die gevallen kun je een bestand genaamd `.gitignore` maken, waarin patronen staan die die bestanden passen. Hier is een voorbeeld van een `.gitignore` bestand:
 
 	$ cat .gitignore
 	*.[oa]
 	*~
 
-De eerste regel verteld Git om ieder bestand dat eindigt op een `.o` of `.a` — *object* en *archief* bestanden die het product kunnen zijn van het bouwen van je code. De tweede regel vertelt Git dat ze alle bestanden die eindigen op een tilde (`~`), wat gebruikt wordt door editors zoals Emacs om tijdelijke bestanden te markeren, mag negeren. Je mag ook `log`, `tmp` of een `pid` map toevoegen, automatisch gegenereerde documentatie, enzovoort. Een `.gitignore` bestand aanmaken voordat je gaat beginnen is over 't algemeen een goed idee, zodat je niet per ongeluk bestanden commit die je echt niet in je repository wilt hebben.
+De eerste regel vertelt Git om ieder bestand te negeren waarvan de naam eindigt op een `.o` of `.a` (*object* en *archief* bestanden die het product kunnen zijn van het bouwen van je code). De tweede regel vertelt Git dat ze alle bestanden die eindigen op een tilde (`~`), wat gebruikt wordt door editors zoals Emacs om tijdelijke bestanden aan te geven, moet negeren. Je mag ook `log`, `tmp` of een `pid` directory toevoegen, automatisch gegenereerde documentatie, enzovoort. Een `.gitignore` bestand aanmaken voordat je gaat beginnen is over 't algemeen een goed idee, zodat je niet per ongeluk bestanden commit die je echt niet in je repository wilt hebben.
 
 De regels voor patronen die je in het `.gitignore` bestand kunt zetten zijn als volgt:
 
 *	Lege regels of regels die beginnen met een `#` worden genegeerd.
-*	Standaard expansie patronen werken.
-*	Je mag patronen laten eindigen op een schuine streep (`/`) om een map te specificeren.
+*	Standaard expansie (glob) patronen werken.
+*	Je mag patronen laten eindigen op een schuine streep (`/`) om een directory te specificeren.
 *	Je mag een patroon ontkennend maken door het te laten beginnen met een uitroepteken (`!`).
 
-Expansie (`glob`) patronen zijn vereenvoudigde reguliere expressies die shell omgevingen gebruiken. Een asterisk (`*`) komt overeen met nul of meer karakters; `[abc]` komt overeen met ieder karakter dat tussen de blokhaken staat (in dit geval a, b of c); een vraagteken (`?`) komt overeen met een enkel karakter, en blokhaken waar tussen karakters staan die gescheiden zijn door een streepje (`[0-9]`) komen overeen met ieder karakter wat tussen die karakters zit (in dit geval 0 tot en met 9).
+Expansie (`glob`) patronen zijn vereenvoudigde reguliere expressies die in shell omgevingen gebruikt worden. Een asterisk (`*`) komt overeen met nul of meer karakters, `[abc]` komt overeen met ieder karakter dat tussen de blokhaken staat (in dit geval `a`, `b` of `c`), een vraagteken (`?`) komt overeen met een enkel karakter en blokhaken waartussen karakters staan die gescheiden zijn door een streepje (`[0-9]`) komen overeen met ieder karakter wat tussen die karakters zit (in dit geval 0 tot en met 9).
 
 Hier is nog een voorbeeld van een `.gitignore` bestand:
 
@@ -181,24 +198,27 @@ Hier is nog een voorbeeld van een `.gitignore` bestand:
 	# ignore doc/notes.txt, but not doc/server/arch.txt
 	doc/*.txt
 
+Een `**/` patroon is sinds versie 1.8.2 beschikbaar in Git.
+
 ### Je staged en unstaged wijzigingen zien ###
 
-Als het `git status` commando te vaag is voor je — je wilt precies weten wat je veranderd hebt, niet alleen welke bestanden veranderd zijn — dan kun je het `git diff` commando gebruiken. We zullen `git diff` later in meer detail bespreken; maar je zult het het meest gebruiken om deze twee vragen te beantwoorden: Wat heb je veranderd maar nog niet gestaged? En wat heb je gestaged en sta je op het punt te committen? Alhoewel `git status` deze vragen heel algemeen beantwoordt, laat `git diff` je de exacte toegevoegde en verwijderde regels zien — de patch, als het ware.
+Als het `git status` commando te vaag is voor je, je wilt precies weten wat je veranderd hebt en niet alleen welke bestanden veranderd zijn, dan kun je het `git diff` commando gebruiken. We zullen `git diff` later in meer detail bespreken, maar je zult dit commando het meest gebruiken om deze twee vragen te beantwoorden: Wat heb je veranderd maar nog niet gestaged? En wat heb je gestaged en sta je op het punt te committen? Waar `git status` deze vragen heel algemeen beantwoordt, laat `git diff` je de exacte toegevoegde en verwijderde regels zien, de patch, als het ware.
 
 Stel dat je het `README` bestand opnieuw verandert en staged, en dan het `benchmarks.rb` bestand verandert zonder het te stagen. Als je je `status` commando uitvoert, dan zie je nogmaals zoiets als dit:
 
 	$ git status
-	# On branch master
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#	new file:   README
-	#
-	# Changes not staged for commit:
-	#   (use "git add <file>..." to update what will be committed)
-	#
-	#	modified:   benchmarks.rb
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        new file:   README
+	
+	Changes not staged for commit:
+	  (use "git add <file>..." to update what will be committed)
+	  (use "git checkout -- <file>..." to discard changes in working directory)
+	
+	        modified:   benchmarks.rb
+	
 
 Om te zien wat je gewijzigd maar nog niet gestaged hebt, typ `git diff` in zonder verdere argumenten:
 
@@ -219,7 +239,7 @@ Om te zien wat je gewijzigd maar nog niet gestaged hebt, typ `git diff` in zonde
 	           log = git.commits('master', 15)
 	           log.size
 
-Dat commando vergelijkt wat er in je werkmap zit met wat er in je staging gebied zit. Het resultaat laat je zien welke wijzigingen je gedaan hebt, die je nog niet gestaged hebt.
+Dat commando vergelijkt wat er in je werkdirectory zit met wat er in je staging area zit. Het resultaat laat je zien welke wijzigingen je gedaan hebt, die je nog niet gestaged hebt.
 
 Als je wilt zien wat je gestaged hebt en in je volgende commit zal zitten, dan kun je `git diff –-cached` gebruiken. (In Git versie 1.6.1 en nieuwer kun je ook `git diff --staged` gebruiken, wat misschien beter te onthouden is.) Dit commando vergelijkt je staged wijzigingen met je laatste commit:
 
@@ -236,23 +256,25 @@ Als je wilt zien wat je gestaged hebt en in je volgende commit zal zitten, dan k
 	+
 	+Grit is a Ruby library for extracting information from a Git repository
 
-Het is belangrijk om te zien dat `git diff` zelf niet alle wijzigingen sinds je laatste commit laat zien — alleen wijzigingen die nog niet gestaged zijn. Dit kan verwarrend zijn, omdat als je al je wijzigingen gestaged hebt, `git diff` geen output zal geven.
+Het is belangrijk om te zien dat `git diff` zelf niet alle wijzigingen sinds je laatste commit laat zien, alleen wijzigingen die nog niet gestaged zijn. Dit kan verwarrend zijn, omdat als je al je wijzigingen gestaged hebt, `git diff` geen output zal geven.
 
-Nog een voorbeeld. Als je het `benchmarks.rb` bestand staged, en vervolgens verandert, dan kun je `git diff` gebruiken om de wijzigingen in het bestand te zien dat gestaged is en de wijzigingen die niet gestaged zijn:
+Nog een voorbeeld. Als je het `benchmarks.rb` bestand staged en vervolgens verandert, dan kun je `git diff` gebruiken om de wijzigingen in het bestand te zien dat gestaged is en de wijzigingen die niet gestaged zijn:
 
 	$ git add benchmarks.rb
 	$ echo '# test line' >> benchmarks.rb
 	$ git status
-	# On branch master
-	#
-	# Changes to be committed:
-	#
-	#	modified:   benchmarks.rb
-	#
-	# Changes not staged for commit:
-	#
-	#	modified:   benchmarks.rb
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        modified:   benchmarks.rb
+	
+	Changes not staged for commit:
+	  (use "git add <file>..." to update what will be committed)
+	  (use "git checkout -- <file>..." to discard changes in working directory)
+	
+	        modified:   benchmarks.rb
+	
 
 Nu kun je `git diff` gebruiken om te zien wat nog niet gestaged is
 
@@ -288,12 +310,12 @@ en `git diff --cached` om te zien wat je tot nog toe gestaged hebt:
 
 ### Je wijzigingen committen ###
 
-Nu dat je staging gebied ingesteld is op de manier zoals jij het wilt, kun je je wijzigingen committen. Onthoud dat alles wat niet gestaged is — ieder bestand dat je gemaakt of gewijzigd hebt en waarop je nog geen `git add` op uitgevoerd hebt — niet in deze commit mee zal gaan. Ze zullen als gewijzigde bestanden op je disk blijven staan.
+Nu je staging area gevuld is zoals jij het wilt, kun je de wijzigingen committen. Onthoud dat alles wat niet gestaged is, dus ieder bestand dat je gemaakt of gewijzigd hebt en waarop je nog geen `git add` uitgevoerd hebt, niet in deze commit mee zal gaan. Ze zullen als gewijzigde bestanden op je schijf blijven staan.
 In dit geval zag je de laatste keer dat je `git status` uitvoerde, dat alles gestaged was. Dus je bent er klaar voor om je wijzigingen te committen. De makkelijkste manier om te committen is om `git commit` in te typen:
 
 	$ git commit
 
-Dit start de door jou gekozen editor op. (Dit wordt bepaald door de `$EDITOR` omgevingsvariabele in je shell — meestal vim of emacs, alhoewel je dit kunt instellen op welke je ook wilt gebruiken met het `git config --global core.editor` commando zoals je in *Hoofdstuk 1* gezien hebt).
+Dit start de door jou gekozen editor op. (Dit wordt bepaald door de `$EDITOR` omgevingsvariabele in je shell, meestal vim of emacs, alhoewel je dit kunt instellen op welke editor je wilt gebruiken met het `git config --global core.editor` commando zoals je in *Hoofdstuk 1* gezien hebt).
 
 De editor laat de volgende tekst zien (dit voorbeeld is een Vim scherm):
 
@@ -301,60 +323,62 @@ De editor laat de volgende tekst zien (dit voorbeeld is een Vim scherm):
 	# with '#' will be ignored, and an empty message aborts the commit.
 	# On branch master
 	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
 	#       new file:   README
 	#       modified:   benchmarks.rb
+	#
 	~
 	~
 	~
 	".git/COMMIT_EDITMSG" 10L, 283C
 
-Je kunt zien dat de standaard commit boodschap de laatste output van het `git status` commando in commentaar bevat en een lege regel bovenaan. Je kunt deze commentaren verwijderen en je eigen commit boodschap intypen, of je kunt ze laten staan om je eraan te helpen herinneren wat je aan het committen bent. (Om een meer expliciete herinnering van je wijzigingen te zien kun je de `-v` optie meegeven aan `git commit`. Als je dit doet zet git de diff van je verandering in je editor zodat je precies kunt zien wat je gedaan hebt.) Als je de editor verlaat, creëert Git je commit boodschap (zonder de commentaren of de diff).
+Je kunt zien dat de standaard commit boodschap de laatste output van het `git status` commando als commentaar bevat en een lege regel bovenaan. Je kunt deze commentaren verwijderen en je eigen commit boodschap intypen, of je kunt ze laten staan om je eraan te helpen herinneren wat je aan het committen bent. (Om een meer expliciete herinnering van je wijzigingen te zien kun je de `-v` optie meegeven aan `git commit`. Als je dit doet zet Git de diff van je veranderingen in je editor zodat je precies kunt zien wat je gedaan hebt.) Als je de editor verlaat, creëert Git je commit boodschap (zonder de commentaren of de diff).
 
-Als alternatief kun je je commit boodschap met het `commit` commando meegeven door hem achter de `-m` optie te specificeren, zoals hier:
+Als alternatief kun je de commit boodschap met het `commit` commando meegeven door hem achter de `-m` optie te specificeren, zoals hier:
 
 	$ git commit -m "Story 182: Fix benchmarks for speed"
-	[master]: created 463dc4f: "Fix benchmarks for speed"
-	 2 files changed, 3 insertions(+), 0 deletions(-)
+	[master 463dc4f] Fix benchmarks for speed
+	 2 files changed, 3 insertions(+)
 	 create mode 100644 README
 
 Nu heb je je eerste commit gemaakt! Je kunt zien dat de commit je wat output over zichzelf heeft gegeven: op welke branch je gecommit hebt (`master`), welke SHA-1 checksum de commit heeft (`463dc4f`), hoeveel bestanden er veranderd zijn, en statistieken over toegevoegde en verwijderde regels in de commit.
 
-Onthoud dat de commit de snapshot, die je in je staging gebied ingesteld hebt, opslaat. Alles wat je niet gestaged hebt staat daar nog steeds gewijzigd; je kunt een volgende commit doen om het aan je geschiedenis toe te voegen. Iedere keer dat je een commit doet, leg je een snapshot van je project vast dat je later terug kunt draaien of mee kunt vergelijken.
+Onthoud dat de commit de snapshot, die je in je staging area ingesteld hebt, opslaat. Alles wat je niet gestaged hebt staat nog steeds gewijzigd; je kunt een volgende commit doen om het aan je geschiedenis toe te voegen. Iedere keer dat je een commit doet, leg je een snapshot van je project vast dat je later terug kunt draaien of mee kunt vergelijken.
 
-### Het staging gebied overslaan ###
+### De staging area overslaan ###
 
-Alhoewel het ontzettend makkelijk kan zijn om commits precies zoals je wilt te maken, is het staging gebied soms iets ingewikkelder dan je in je manier van werken nodig hebt. Als je het staging gebied wilt overslaan, dan biedt Git een makkelijke route binnendoor. Door de `-a` optie aan het `git commit` commando mee te geven, zal Git automatisch ieder bestand dat al getracked wordt voor de commit stagen, zodat je het `git add` gedeelte kunt overslaan:
+Alhoewel het ontzettend makkelijk kan zijn om commits precies zoals je wilt te maken, is de staging area soms iets ingewikkelder dan je in je workflow nodig hebt. Als je de staging area wilt overslaan, dan kan je met Git makkelijk de route inkorten. Door de `-a` optie aan het `git commit` commando mee te geven zal Git automatisch ieder bestand dat al getrackt wordt voor de commit stagen, zodat je het `git add` gedeelte kunt overslaan:
 
 	$ git status
-	# On branch master
-	#
-	# Changes not staged for commit:
-	#
-	#	modified:   benchmarks.rb
-	#
+	On branch master
+	Changes not staged for commit:
+	  (use "git add <file>..." to update what will be committed)
+	  (use "git checkout -- <file>..." to discard changes in working directory)
+	
+	        modified:   benchmarks.rb
+	
+	no changes added to commit (use "git add" and/or "git commit -a")
 	$ git commit -a -m 'added new benchmarks'
 	[master 83e38c7] added new benchmarks
-	 1 files changed, 5 insertions(+), 0 deletions(-)
+	 1 files changed, 5 insertions(+)
 
-Let op dat je nu geen `git add` op het `benchmarks.rb` bestand hoeft te doen voordat je commit.
+Merk op dat je nu geen `git add` op het `benchmarks.rb` bestand hoeft te doen voordat je commit.
 
 ### Bestanden verwijderen ###
 
-Om een bestand van Git te verwijderen, moet je het van de tracked bestanden verwijderen (om precies te zijn, verwijderen van je staging gebied) en dan een commit doen. Het `git rm` commando doet dat, en verwijdert het bestand ook van je werkmap zodat je het de volgende keer niet als een untracked bestand ziet.
+Om een bestand van Git te verwijderen, moet je het van de getrackte bestanden verwijderen (of om precies te zijn: verwijderen van je staging area) en dan een commit doen. Het `git rm` commando doet dat, en verwijdert het bestand ook van je werkdirectory zodat je het de volgende keer niet als een untrackt bestand ziet.
 
-Als je het bestand simpelweg verwijdert uit je werkmap, zal het te zien zijn onder het “Changes not staged for commit” (dat wil zeggen, _unstaged_) gedeelte van je `git status` output:
+Als je het bestand simpelweg verwijdert uit je werkdirectory, zal het te zien zijn onder het “Changes not staged for commit” (dat wil zeggen, _unstaged_) gedeelte van je `git status` output:
 
 	$ rm grit.gemspec
 	$ git status
-	# On branch master
-	#
-	# Changes not staged for commit:
-	#   (use "git add/rm <file>..." to update what will be committed)
-	#
-	#       deleted:    grit.gemspec
-	#
+	On branch master
+	Changes not staged for commit:
+	  (use "git add/rm <file>..." to update what will be committed)
+	  (use "git checkout -- <file>..." to discard changes in working directory)
+	
+	        deleted:    grit.gemspec
+	
+	no changes added to commit (use "git add" and/or "git commit -a")
 
 Als je daarna `git rm` uitvoert, zal de verwijdering van het bestand gestaged worden:
 
@@ -369,25 +393,25 @@ Als je daarna `git rm` uitvoert, zal de verwijdering van het bestand gestaged wo
 	#       deleted:    grit.gemspec
 	#
 
-Als je de volgende keer een commit doet, zal het bestand verdwenen zijn en niet meer getracked worden. Als je het bestand veranderd hebt en al aan de index toegevoegd hebt, dan zul je de verwijdering moeten forceren met de `-f` optie. Dit is een veiligheidsmaatregel om te voorkomen dat je per ongeluk data die nog niet in een snapshot zit, en dus niet teruggehaald kan worden uit Git, weggooit.
+Als je de volgende keer een commit doet, zal het bestand verdwenen zijn en niet meer getrackt worden. Als je het bestand veranderd hebt en al aan de index toegevoegd, dan zul je de verwijdering moeten forceren met de `-f` optie. Dit is een veiligheidsmaatregel om te voorkomen dat je per ongeluk data die nog niet in een snapshot zit, en dus niet teruggehaald kan worden uit Git, weggooit.
 
-Een ander handigheidje wat je misschien wilt doen is het bestand in je werkmap houden, maar van je staging gebied verwijderen. Met andere woorden, je wilt het bestand misschien op je harde schijf bewaren, maar niet dat Git het bestand nog tracked. Dit is erg handig als je iets vergeten bent aan je `.gitignore` bestand toe te voegen, en het per ongeluk toegevoegd hebt. Zoals een groot logbestand, of een serie `.a` gecompileerde bestanden. Gebruik de `--cached` optie om dit te doen:
+Een ander handigheidje wat je misschien wilt gebruiken is het bestand in je werkdirectory houden, maar van je staging area verwijderen. Met andere woorden, je wilt het bestand misschien op je harde schijf bewaren, maar niet dat Git het bestand nog trackt. Dit is erg handig als je iets vergeten bent aan je `.gitignore` bestand toe te voegen, en het per ongeluk toegevoegd hebt. Zoals een groot logbestand, of een serie `.a` gecompileerde bestanden. Gebruik de `--cached` optie om dit te doen:
 
 	$ git rm --cached readme.txt
 
-Je kunt bestanden, mappen en bestandspatronen aan het `git rm` commando meegeven. Dat betekent dat je zoiets als dit kunt doen
+Je kunt bestanden, directories en bestandspatronen aan het `git rm` commando meegeven. Dat betekent dat je zoiets als dit kunt doen
 
 	$ git rm log/\*.log
 
-Let op de backslash (`\`) voor de `*`. Dit is nodig omdat Git zijn eigen bestandsnaam expansie doet, naast die van je shell. In de Windows systeemconsole moet de backslash worden weggelaten. Dit commando verwijdert alle bestanden die de `.log` extensie hebben in de `log/` map. Of, je kunt zoiets als dit doen:
+Let op de backslash (`\`) voor de `*`. Dit is nodig omdat Git zijn eigen bestandsnaam expansie doet, naast die van je shell. In de Windows systeemconsole moet de backslash worden weggelaten. Dit commando verwijdert alle bestanden die de `.log` extensie hebben in de `log/` directory. Of, je kunt zoiets als dit doen:
 
 	$ git rm \*~
 
-Dit commando verwijderd alle bestanden die eindigen met `~`.
+Dit commando verwijdert alle bestanden die eindigen met `~`.
 
 ### Bestanden verplaatsen ###
 
-Anders dan vele andere VCS systemen, traceert Git niet expliciet verplaatsingen van bestanden. Als je een bestand een nieuwe naam geeft in Git, is er geen metadata opgeslagen in Git die vertelt dat je het bestand hernoemd hebt. Maar, Git is slim genoeg om dit alsnog te zien — we zullen bestandsverplaatsing detectie wat later behandelen.
+Anders dan vele andere VCS systemen, traceert Git niet expliciet verplaatsingen van bestanden. Als je een bestand een nieuwe naam geeft in Git, is er geen metadata opgeslagen in Git die vertelt dat je het bestand hernoemd hebt. Maar Git is slim genoeg om dit alsnog te zien, we zullen bestandsverplaatsing detectie wat later behandelen.
 
 Het is daarom een beetje verwarrend dat Git een `mv` commando heeft. Als je een bestand wilt hernoemen in Git, kun je zoiets als dit doen
 
@@ -397,26 +421,24 @@ en dat werkt prima. Sterker nog, als je zoiets als dit uitvoert en naar de statu
 
 	$ git mv README.txt README
 	$ git status
-	# On branch master
-	# Your branch is ahead of 'origin/master' by 1 commit.
-	#
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#       renamed:    README.txt -> README
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        renamed:    README.txt -> README
+	
 
-Maar, dat is gelijk aan het volgende uitvoeren:
+Maar dat is gelijk aan het uitvoeren van het volgende:
 
 	$ mv README.txt README
 	$ git rm README.txt
 	$ git add README
 
-Git komt er impliciet achter dat het om een hernoemd bestand gaat, dus het maakt niet uit of je een bestand op deze manier hernoemt of met het `mv` commando. Het enige echte verschil is dat het `mv` commando slechts één commando is in plaats van drie. En belangrijker nog is dat je iedere applicatie kunt gebruiken om een bestand te hernoemen, en de add/rm later kunt afhandelen, voordat je commit.
+Git komt er impliciet achter dat het om een hernoemd bestand gaat, dus het maakt niet uit of je een bestand op deze manier hernoemt of met het `mv` commando. Het enige echte verschil is dat het `mv` commando slechts één commando is in plaats van drie. En belangrijker nog is dat je iedere applicatie kunt gebruiken om een bestand te hernoemen, en de add/rm later kunt afhandelen voordat je commit.
 
 ## De commit geschiedenis bekijken ##
 
-Nadat je een aantal commits gecreëerd hebt, of als je een repository met een bestaande commit geschiedenis gekloond hebt, zul je waarschijnlijk terug willen zien wat er gebeurd is. Het meest basale en krachtige tool om dit te doen is het `git log` commando.
+Nadat je een aantal commits gemaakt hebt, of als je een repository met een bestaande commit geschiedenis gecloned hebt, zul je waarschijnlijk terug willen zien wat er gebeurd is. Het meest basale en krachtige tool om dit te doen is het `git log` commando.
 
 Deze voorbeelden maken gebruik van een eenvoudig project genaamd simplegit dat ik vaak voor demonstraties gebruikt. Om het project op te halen, voer dit uit
 
@@ -443,7 +465,7 @@ Als je `git log` in dit project uitvoert, zou je output moeten krijgen die er on
 
 	    first commit
 
-Zonder argumenten toont `git log` de commits die gedaan zijn in dat repository, in omgekeerde chronologische volgorde. Dat wil zeggen, de meest recente commits worden als eerste getoond. Zoals je kunt zien, toont dit commando iedere commit met zijn SHA-1 checksum, de naam van de auteur en zijn e-mail, de datum van opslaan, en de commit boodschap.
+Zonder argumenten toont `git log` de commits die gedaan zijn in die repository, in omgekeerde chronologische volgorde. Dat wil zeggen: de meest recente commits worden als eerste getoond. Zoals je kunt zien, toont dit commando iedere commit met zijn SHA-1 checksum, de naam van de auteur en zijn e-mail, de datum van opslaan, en de commit boodschap.
 
 Een gigantisch aantal en variëteit aan opties zijn beschikbaar voor het `git log` commando om je precies te laten zien waar je naar op zoek bent. Hier laten we je de meest gebruikte opties zien.
 
@@ -487,7 +509,28 @@ Een van de meest behulpzame opties is `-p`, wat de diff laat zien van de dingen
 	-end
 	\ No newline at end of file
 
-Deze optie toont dezelfde informatie, maar dan met een diff volgend op ieder item. Dit is erg handig voor een code review, of om snel te zien wat er tijdens een serie commits gebeurd is die een medewerker toegevoegd heeft.
+Deze optie toont dezelfde informatie, maar dan met een diff volgend op ieder item. Dit is erg handig voor een code review, of om snel te zien wat er tijdens een reeks commits gebeurd is die een medewerker toegevoegd heeft.
+
+Soms is het handiger om wijzigingen na te kijken op woordniveau in plaats van op regelniveau. Er is een `--word-diff` optie beschikbaar in Git, die je aan het `git log -p` commando kan toevoegen om een woord diff te krijgen inplaats van de reguliere regel voor regel diff. Woord diff formaat is nogal nutteloos als het wordt toegepast op broncode, maar is erg handig als het wordt toegepast op grote tekstbestanden, zoals boeken of een dissertatie. Hier is een voorbeeld.
+
+	$ git log -U1 --word-diff
+	commit ca82a6dff817ec66f44342007202690a93763949
+	Author: Scott Chacon <schacon@gee-mail.com>
+	Date:   Mon Mar 17 21:52:11 2008 -0700
+
+	    changed the version number
+
+	diff --git a/Rakefile b/Rakefile
+	index a874b73..8f94139 100644
+	--- a/Rakefile
+	+++ b/Rakefile
+	@@ -7,3 +7,3 @@ spec = Gem::Specification.new do |s|
+	    s.name      =   "simplegit"
+	    s.version   =   [-"0.1.0"-]{+"0.1.1"+}
+	    s.author    =   "Scott Chacon"
+
+Zoals je kunt zien zijn er geen toegevoegde of verwijderde regels in deze uitvoer zoals in een normale diff. Wijzigingen worden daarentegen binnen de regel getoond. Je kunt het toegevoegde woord zien binnen een `{+ +}` en verwijderde binnen een `[- -]`. Je kunt ook kiezen om de gebruikelijke 3 regels context in de diff uitvoer tot één regel te verminderen, omdat de context nu woorden is, en geen regels. Je kunt dit doen met `-U1` zoals hierboven in het voorbeeld.
+
 Je kunt ook een serie samenvattende opties met `git log` gebruiken. Bijvoorbeeld, als je wat verkorte statistieken bij iedere commit wilt zien, kun je de `--stat` optie gebruiken:
 
 	$ git log --stat
@@ -498,7 +541,7 @@ Je kunt ook een serie samenvattende opties met `git log` gebruiken. Bijvoorbeeld
 	    changed the version number
 
 	 Rakefile |    2 +-
-	 1 files changed, 1 insertions(+), 1 deletions(-)
+	 1 file changed, 1 insertion(+), 1 deletion(-)
 
 	commit 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7
 	Author: Scott Chacon <schacon@gee-mail.com>
@@ -507,7 +550,7 @@ Je kunt ook een serie samenvattende opties met `git log` gebruiken. Bijvoorbeeld
 	    removed unnecessary test code
 
 	 lib/simplegit.rb |    5 -----
-	 1 files changed, 0 insertions(+), 5 deletions(-)
+	 1 file changed, 5 deletions(-)
 
 	commit a11bef06a3f659402fe7563abf99ad00de2209e6
 	Author: Scott Chacon <schacon@gee-mail.com>
@@ -518,17 +561,17 @@ Je kunt ook een serie samenvattende opties met `git log` gebruiken. Bijvoorbeeld
 	 README           |    6 ++++++
 	 Rakefile         |   23 +++++++++++++++++++++++
 	 lib/simplegit.rb |   25 +++++++++++++++++++++++++
-	 3 files changed, 54 insertions(+), 0 deletions(-)
+	 3 files changed, 54 insertions(+)
 
 Zoals je ziet, drukt de `--stat` optie onder iedere commit een lijst gewijzigde bestanden af, hoeveel bestanden gewijzigd zijn, en hoeveel regels in die bestanden zijn toegevoegd en verwijderd. Het toont ook een samenvatting van de informatie aan het einde.
-Een andere handige optie is `--pretty`. Deze optie veranderd de log output naar een ander formaat dan de standaard. Er zijn al een paar voorgebouwde opties voor je beschikbaar. De `oneline` optie drukt iedere commit op een enkele regel af, wat handig is als je naar een hoop commits kijkt. Daarnaast tonen de `short`, `full` en `fuller` optie de output in grofweg hetzelfde formaat, maar met minder of meer informatie, respectievelijk:
+Een andere handige optie is `--pretty`. Deze optie verandert de log output naar een ander formaat dan de standaard. Er zijn al een paar voorgebouwde opties voor je beschikbaar. De `oneline` optie drukt iedere commit op een eigen regel af, wat handig is als je naar een hoop commits kijkt. Daarnaast tonen de `short`, `full` en `fuller` opties de output in grofweg hetzelfde formaat, maar met minder of meer informatie, respectievelijk:
 
 	$ git log --pretty=oneline
 	ca82a6dff817ec66f44342007202690a93763949 changed the version number
 	085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7 removed unnecessary test code
 	a11bef06a3f659402fe7563abf99ad00de2209e6 first commit
 
-De meest interessante optie is `format`, waarmee je je eigen log formaat kunt specificeren. Dit is in het bijzonder handig als je output aan het genereren bent voor automatische verwerking — omdat je expliciet het formaat kan specificeren, weet je dat het niet zal veranderen bij volgende versies van Git:
+De meest interessante optie is `format`, waarmee je je eigen log uitvoer formaat kunt specificeren. Dit is in het bijzonder handig als je output aan het genereren bent voor automatische verwerking; omdat je expliciet het formaat kan specificeren, weet je dat het niet zal veranderen bij volgende versies van Git:
 
 	$ git log --pretty=format:"%h - %an, %ar : %s"
 	ca82a6d - Scott Chacon, 11 months ago : changed the version number
@@ -536,6 +579,10 @@ De meest interessante optie is `format`, waarmee je je eigen log formaat kunt sp
 	a11bef0 - Scott Chacon, 11 months ago : first commit
 
 Tabel 2-1 toont een aantal handige opties die aan format gegeven kunnen worden.
+<!-- Attention to translators: this is a table declaration.
+The lines must be formatted as follows
+<TAB><First column text><TAB><Second column text>
+-->
 
 	Optie	Omschrijving van de Output
 	%H	Commit hash
@@ -554,7 +601,7 @@ Tabel 2-1 toont een aantal handige opties die aan format gegeven kunnen worden.
 	%cr	Committer datum, relatief
 	%s	Onderwerp
 
-Je zult je misschien afvragen wat het verschil is tussen _author_ en _committer_. De _auteur_ is de persoon die het werk oorspronkelijk geschreven heeft, en de _committer_ is de persoon die het werk als laatste toegevoegd heeft. Dus als je een patch naar een project stuurt en een van de kernleden voegt de patch toe, dan krijgen jullie beiden de eer — jij als de auteur en het kernlid als de committer. We gaan hier wat verder op in in *Hoofdstuk 5*.
+Je zult je misschien afvragen wat het verschil is tussen _author_ en _committer_. De _author_ is de persoon die de patch oorspronkelijk geschreven heeft, en de _committer_ is de persoon die de patch als laatste heeft toegepast. Dus als je een patch naar een project stuurt en een van de kernleden past de patch toe, dan krijgen jullie beiden de eer, jij als de auteur en het kernlid als de committer. We gaan hier wat verder op in in *Hoofdstuk 5*.
 
 De `oneline` en `format` opties zijn erg handig in combinatie met een andere `log` optie genaamd `--graph`. Deze optie maakt een mooie ASCII grafiek waarin je branch en merge geschiedenis getoond worden, die we kunnen zien in onze kopie van het Grit project repository:
 
@@ -570,11 +617,17 @@ De `oneline` en `format` opties zijn erg handig in combinatie met een andere `lo
 	* d6016bc require time for xmlschema
 	*  11d191e Merge branch 'defunkt' into local
 
-Dat zijn slechts een paar simpele output formaat opties voor `git log` — er zijn er nog veel meer. Tabel 2-2 toont de opties waarover we het tot nog toe gehad hebben, en wat veel voorkomende formaat opties die je misschien handig vindt, samen met hoe ze de output van het log commando veranderen.
+Dat zijn slechts een paar simpele output formaat opties voor `git log`; er zijn er nog veel meer. Tabel 2-2 toont de opties waarover we het tot nog toe gehad hebben, en wat veel voorkomende formaat opties die je misschien handig vindt, samen met hoe ze de output van het `log` commando veranderen.
+
+<!-- Attention to translators: this is a table declaration.
+The lines must be formatted as follows
+<TAB><First column text><TAB><Second column text>
+-->
 
 	Optie	Omschrijving
 	-p	Toon de patch geïntroduceerd bij iedere commit.
-	--stat	Toon statistieken voor gewijzigde bestanden in iedere commit.
+	--word-diff	Toon de patch in een woord diff formaat.
+	--stat	Toon statistieken voor gewijzigde bestanden per commit.
 	--shortstat	Toon alleen de gewijzigde/ingevoegde/verwijderde regel van het --stat commando.
 	--name-only	Toon de lijst van bestanden die gewijzigd zijn na de commit informatie.
 	--name-status	Toon ook de lijst van bestanden die beïnvloed zijn door de toegevoegde/gewijzigde/verwijderde informatie.
@@ -582,20 +635,21 @@ Dat zijn slechts een paar simpele output formaat opties voor `git log` — er zi
 	--relative-date	Toon de datum in een relatief formaat (bijvoorbeeld, "2 weken geleden"), in plaats van het volledige datum formaat.
 	--graph		Toon een ASCII grafiek van de branch en merge geschiedenis naast de log output.
 	--pretty	Toon commits in een alternatief formaat. De opties bevatten oneline, short, full, fuller, en format (waarbij je je eigen formaat specificeert).
+	--oneline	Een gemaks-optie, staat voor `--pretty=oneline --abbrev-commit`.
 
 ### Log output limiteren ###
 
-Naast het formatteren van de output, heeft `git log` nog een aantal bruikbare limiterende opties — dat wil zeggen, opties die je een subset van de commits tonen. Je hebt zo'n optie al gezien — de `-2` optie, die slechts de laatste twee commits laat zien. In feite kun je `-<n>` doen, waarbij `n` ieder heel getal is wat de laatste `n` commits laat zien. In feite zul je deze vorm weinig gebruiken, omdat Git standaard alle output door een pager (pagineer applicatie) stuurt zodat je slechts één pagina log output per keer ziet.
+Naast het formatteren van de output, heeft `git log` nog een aantal bruikbare limiterende opties; dat wil zeggen, opties die je een subset van de commits tonen. Je hebt zo'n optie al gezien: de `-2` optie, die slechts de laatste twee commits laat zien. Sterker nog: je kunt `-<n>` doen, waarbij `n` een heel getal is om de laatste `n` commits te laten zien. In feite zul je deze vorm weinig gebruiken, omdat Git standaard alle output door een pager (pagineer applicatie) stuurt zodat je de log-uitvoer pagina voor pagina ziet.
 
-Maar, de tijd limiterende opties zoals `--since` en `--until` zijn erg handig. Dit commando bijvoorbeeld, geeft een lijst met commits die gedaan zijn gedurende de laatste twee weken:
+Dat gezegd hebbende, zijn de tijd limiterende opties zoals `--since` en `--until` erg handig. Dit commando bijvoorbeeld, geeft een lijst met commits die gedaan zijn gedurende de laatste twee weken:
 
 	$ git log --since=2.weeks
 
-Dit commando werkt met veel formaten — je kunt een specifieke datum kiezen ("2008-01-15”) of een relatieve datum zoals "2 jaar 1 dag en 3 minuten geleden".
+Dit commando werkt met veel formaten: je kunt een specifieke datum kiezen ("2008-01-15”) of een relatieve datum zoals "2 jaar 1 dag en 3 minuten geleden".
 
 Je kunt ook de lijst met commits filteren op bepaalde criteria. De `--author` optie laat je filteren op een specifieke auteur, en de `--grep` optie laat je op bepaalde zoekwoorden filteren in de commit boodschappen. (Let op dat als je zowel auteur als grep opties wilt specificeren, je `--all-match` moet toevoegen of anders zal het commando ook commits met één van de twee criteria selecteren.)
 
-De laatste echt handige optie om aan `git log` als filter mee te geven is een pad. Als je een map of bestandsnaam opgeeft, kun je de log output limiteren tot commits die een verandering introduceren op die bestanden. Dit is altijd de laatste optie en wordt over het algemeen vooraf gegaan door dubbele streepjes (`--`) om de paden van de opties te scheiden.
+De laatste echt handige optie om aan `git log` als filter mee te geven is een pad. Als je een directory of bestandsnaam opgeeft, kun je de log output limiteren tot commits die een verandering introduceren op die bestanden. Dit is altijd de laatste optie en wordt over het algemeen vooraf gegaan door dubbele streepjes (`--`) om de paden van de opties te scheiden.
 
 In Tabel 2-3 laten we deze en een paar andere veel voorkomende opties zien als referentie.
 
@@ -621,16 +675,16 @@ Van de bijna 20.000 commits in de Git broncode historie, laat dit commando de 6
 
 ### Een grafische interface gebruiken om de historie te visualiseren ###
 
-Als je een meer grafische applicatie wilt gebruiken om je commit historie te visualiseren, wil je misschien een kijkje nemen naar het Tcl/Tk programma genaamd `gitk` dat met Git meegeleverd wordt. Gitk is eigenlijk een visuele `git log`, en het accepteert bijna alle filter opties die `git log` ook accepteert. Als je `gitk` in op de commandoregel in je project typt, zou je zoiets als in Figuur 2-2 moeten zien.
+Als je een meer grafische applicatie wilt gebruiken om je commit historie te visualiseren, wil je misschien een kijkje nemen naar het Tcl/Tk programma genaamd `gitk` dat met Git meegeleverd wordt. Gitk is eigenlijk een visuele `git log` tool, en het accepteert bijna alle filter opties die `git log` ook accepteert. Als je `gitk` in op de commandoregel in je project typt, zou je zoiets als in Figuur 2-2 moeten zien.
 
 Insert 18333fig0202.png
 Figuur 2-2. De gitk historie visualiseerder.
 
-Je kunt de commit historie in de bovenste helft van het scherm zien, samen met een afkomst graaf. De diff in de onderste helft van het scherm laat je de veranderingen zien die bij iedere commit die je aanklikt geïntroduceerd zijn.
+Je kunt de commit historie in de bovenste helft van het scherm zien, samen met een afkomst graaf. De diff in de onderste helft van het scherm laat je de veranderingen zien die geïntroduceerd zijn bij iedere commit die je aanklikt.
 
 ## Dingen ongedaan maken ##
 
-Op enig moment wil je misschien iets ongedaan maken. Hier zullen we een aantal basis toepassingen laten zien om veranderingen die je gemaakt hebt weer ongedaan te maken. Let op, je kunt niet altijd het ongedaan maken weer ongedaan maken. Dit is één van de weinige gedeeltes in Git waarbij je werk kwijt kunt raken als je het verkeerd doet.
+Op enig moment wil je misschien iets ongedaan maken. Hier zullen we een aantal basis tools laten zien om veranderingen die je gemaakt hebt weer ongedaan te maken. Maar pas op, je kunt niet altijd het ongedaan maken weer ongedaan maken. Dit is één van de weinige gedeeltes in Git waarbij je werk kwijt kunt raken als je het verkeerd doet.
 
 ### Je laatste commit veranderen ###
 
@@ -638,94 +692,95 @@ Een van de veel voorkomende acties die ongedaan gemaakt moeten worden vinden pla
 
 	$ git commit --amend
 
-Dit commando neemt je staging gebied en gebruikt dit voor de commit. Als je geen veranderingen sinds je laatste commit hebt gedaan (bijvoorbeeld, je voert dit commando meteen na je laatste commit uit), dan zal je snapshot er precies hetzelfde uitzien en zal je commit boodschap het enige zijn dat je verandert.
+Dit commando neemt je staging area en gebruikt dit voor de commit. Als je geen veranderingen sinds je laatste commit hebt gedaan (bijvoorbeeld, je voert dit commando meteen na je laatste commit uit), dan zal je snapshot er precies hetzelfde uitzien en zal je commit boodschap het enige zijn dat je verandert.
 
 Dezelfde commit-boodschap editor start op, maar deze bevat meteen de boodschap van je vorige commit. Je kunt de boodschap net als andere keren aanpassen, maar het overschrijft je vorige commit.
 
 Bijvoorbeeld, als je commit en je dan realiseert dat je vergeten bent de veranderingen in een bestand dat je wou toevoegen in deze commit te stagen, dan kun je zoiets als dit doen:
 
 	$ git commit -m 'initial commit'
-	$ git add forgotten_file
+	$ git add vergeten_bestand
 	$ git commit --amend
 
-Alledrie van deze commando's eindigen met één commit — de tweede commit vervangt de resultaten van de eerste.
+Na deze drie commando's eindig je met één commit; de tweede commit vervangt de resultaten van de eerste.
 
 ### Een staged bestand unstagen ###
 
-De volgende twee paragrafen laten zien hoe je je staging gebied en veranderingen in je werkmappen aanpakt. Het fijne gedeelte is dat het commando dat je gebruikt om de status van die gebieden te bepalen, je ook herinnert hoe je de veranderingen eraan ongedaan kunt maken. Bijvoorbeeld, stel dat je twee bestanden gewijzigd hebt en je wilt ze committen als twee aparte veranderingen, maar je typt per ongeluk `git add *` en staged ze allebei. Hoe kun je één van de twee nu unstagen? Het `git status` commando herinnert je eraan:
+De volgende twee paragrafen laten zien hoe je de staging area en veranderingen in je werkdirectories aanpakt. Het prettige hier is dat het commando dat je gebruikt om de status van die gebieden te bepalen, je er ook aan herinnert hoe je de veranderingen eraan weer ongedaan kunt maken. Bijvoorbeeld, stel dat je twee bestanden gewijzigd hebt en je wilt ze committen als twee aparte veranderingen, maar je typt per ongeluk `git add *` en staged ze allebei. Hoe kun je één van de twee nu unstagen? Het `git status` commando herinnert je eraan:
 
 	$ git add .
 	$ git status
-	# On branch master
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#       modified:   README.txt
-	#       modified:   benchmarks.rb
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        modified:   README.txt
+	        modified:   benchmarks.rb
+	
 
-Recht onder de "Changes to be committed" tekst, staat dat je `git reset HEAD <bestand>...` moet gebruiken om te unstagen. Laten we dat advies volgen om het `benchmarks.rb` bestand te unstagen:
+Direct onder de "Changes to be committed" tekst, staat dat je `git reset HEAD <file>...` moet gebruiken om te unstagen. Laten we dat advies volgen om het `benchmarks.rb` bestand te unstagen:
 
 	$ git reset HEAD benchmarks.rb
-	benchmarks.rb: locally modified
+	Unstaged changes after reset:
+	M       benchmarks.rb
 	$ git status
-	# On branch master
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#       modified:   README.txt
-	#
-	# Changes not staged for commit:
-	#   (use "git add <file>..." to update what will be committed)
-	#   (use "git checkout -- <file>..." to discard changes in working directory)
-	#
-	#       modified:   benchmarks.rb
-	#
-
-Het commando is een beetje vreemd, maar het werkt. Het benchmarks.rb bestand is gewijzigd maar weer ge-unstaged.
-
-### Een gewijzigd bestand ongedaan maken ###
-
-Wat als je je realiseert dat je je wijzigingen aan het `benchmarks.rb` bestand niet wilt behouden? Hoe kun je dit makkelijk ongedaan maken — terug brengen in de staat waarin het was toen je voor het laatst gecommit hebt (of initieel gekloond, of hoe je het ook in je werkmap gekregen hebt)? Gelukkig vertelt `git status` je ook hoe je dat moet doen. In de laatste voorbeeld output, ziet het unstaged gebied er zo uit:
-
-	# Changes not staged for commit:
-	#   (use "git add <file>..." to update what will be committed)
-	#   (use "git checkout -- <file>..." to discard changes in working directory)
-	#
-	#       modified:   benchmarks.rb
-	#
-
-Het vertelt je behoorlijk expliciet hoe je je veranderingen moet weggooien (tenminste, de nieuwere versies van Git, 1.6.1 of nieuwer, doen dit — als je een oudere versie hebt, raden we je ten zeerste aan om het te upgraden zodat je een aantal van deze fijne bruikbaarheidsopties krijgt). Laten we eens doen wat er staat:
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        modified:   README.txt
+	
+	Changes not staged for commit:
+	  (use "git add <file>..." to update what will be committed)
+	  (use "git checkout -- <file>..." to discard changes in working directory)
+	
+	        modified:   benchmarks.rb
+	
+
+Het commando is een beetje vreemd, maar het werkt. Het benchmarks.rb bestand is gewijzigd maar weer geunstaged.
+
+### Een gewijzigd bestand weer ongewijzigd maken ###
+
+Wat als je je realiseert dat je de wijzigingen aan het `benchmarks.rb` bestand niet wilt behouden? Hoe kun je dit makkelijk ongedaan maken; terug brengen in de staat waarin het was toen je voor het laatst gecommit hebt (of initieel gecloned, of hoe je het ook in je werkdirectory gekregen hebt)? Gelukkig vertelt `git status` je ook hoe je dat moet doen. In de laatste voorbeeld output, ziet het unstaged gebied er zo uit:
+
+	Changes not staged for commit:
+	  (use "git add <file>..." to update what will be committed)
+	  (use "git checkout -- <file>..." to discard changes in working directory)
+	
+	        modified:   benchmarks.rb
+	
+
+Het vertelt je behoorlijk expliciet hoe je je veranderingen moet weggooien (tenminste, de nieuwere versies van Git, 1.6.1 of nieuwer, doen dit. Als je een oudere versie hebt, raden we je ten zeerste aan om het te upgraden zodat je een aantal van deze fijne bruikbaarheidsopties krijgt). Laten we eens doen wat er staat:
 
 	$ git checkout -- benchmarks.rb
 	$ git status
-	# On branch master
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#       modified:   README.txt
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        modified:   README.txt
+	
 
-Je kunt zien dat de veranderingen teruggedraaid zijn. Je moet je ook realiseren dat dit een gevaarlijk commando is: alle veranderingen die je aan dat bestand gedaan hebt zijn weg — je hebt er zojuist een ander bestand overheen gezet. Gebruik dit commando dan ook nooit, tenzij je heel zeker weet dat je het bestand niet wilt. Als je het alleen maar uit de weg wilt hebben, gebruik dan branching of stashing wat we behandelen in het volgende hoofdstuk; dit zijn vaak de betere opties.
+Je kunt zien dat de veranderingen teruggedraaid zijn. Je moet je ook beseffen dat dit een gevaarlijk commando is: alle veranderingen die je aan dat bestand gedaan hebt zijn weg; je hebt er zojuist een ander bestand overheen gezet. Gebruik dit commando dan ook nooit, tenzij je heel zeker weet dat je het bestand niet wilt. Als je het alleen maar uit de weg wilt hebben, gebruik dan branching of stashing wat we behandelen in het volgende hoofdstuk; dit zijn vaak de betere opties.
 
 Onthoud, alles dat in Git gecommit is kan bijna altijd weer hersteld worden. Zelfs commits die op reeds verwijderde branches gedaan zijn, of commits die zijn overschreven door een `--amend` commit, kunnen weer hersteld worden (zie *Hoofdstuk 9* voor data herstel). Maar, alles wat je verliest dat nog nooit was gecommit is waarschijnlijk voor altijd verloren.
 
 ## Werken met remotes ##
 
-Om samen te kunnen werken op ieder Git project, moet je weten hoe je je remote repositories moet beheren. Remote repositories zijn versies van je project, die worden beheerd op het Internet of ergens op een netwerk. Je kunt er meerdere hebben, waarvan ieder ofwel alleen leesbaar, of lees- en schrijfbaar is voor jou. Samenwerken met anderen houdt in dat je deze remote repositories kunt beheren en data kunt pushen en pullen op het moment dat je werk moet delen.
-Remote repositories beheren houdt ook in hoe je ze moet toevoegen, ongeldige repositories moet verwijderen, meerdere remote branches moet beheren en ze als tracked of niet kunt definiëren, en meer. In deze sectie zullen we deze remote-beheer vaardigheden behandelen.
+Om samen te kunnen werken op eender welke Git project, moet je weten hoe je de remote repositories moet beheren. Remote repositories zijn versies van je project, die worden beheerd op het Internet of ergens op een netwerk. Je kunt er meerdere hebben, waarvan over het algemeen ieder ofwel alleen leesbaar, of lees- en schrijfbaar is voor jou. Samenwerken met anderen houdt in dat je deze remote repositories kunt beheren en data kunt pushen en pullen op het moment dat je werk moet delen.
+Remote repositories beheren houdt ook in weten hoe je ze moet toevoegen, ongeldige repositories moet verwijderen, meerdere remote branches moet beheren en ze als tracked of niet kunt definiëren, en meer. In deze sectie zullen we deze remote-beheer vaardigheden behandelen.
 
 ### Laat je remotes zien ###
 
-Om te zien welke remote servers je geconfigureerd hebt, kun je het `git remote` commando uitvoeren. Het laat de verkorte namen van iedere remote alias zien die je gespecificeerd hebt. Als je je repository gekloond hebt, dan zul je op z'n minst de *origin* zien — dat is de standaard naam die Git aan de server geeft waarvan je gekloond hebt:
+Om te zien welke remote servers je geconfigureerd hebt, kun je het `git remote` commando uitvoeren. Het laat de verkorte namen van iedere remote alias zien die je gespecificeerd hebt. Als je de repository gecloned hebt, dan zul je op z'n minst de *origin* zien; dat is de standaard naam die Git aan de server geeft waarvan je gecloned hebt:
 
 	$ git clone git://github.com/schacon/ticgit.git
-	Initialized empty Git repository in /private/tmp/ticgit/.git/
-	remote: Counting objects: 595, done.
-	remote: Compressing objects: 100% (269/269), done.
-	remote: Total 595 (delta 255), reused 589 (delta 253)
-	Receiving objects: 100% (595/595), 73.31 KiB | 1 KiB/s, done.
-	Resolving deltas: 100% (255/255), done.
+	Cloning into 'ticgit'...
+	remote: Reusing existing pack: 1857, done.
+	remote: Total 1857 (delta 0), reused 0 (delta 0)
+	Receiving objects: 100% (1857/1857), 374.35 KiB | 193.00 KiB/s, done.
+	Resolving deltas: 100% (772/772), done.
+	Checking connectivity... done.
 	$ cd ticgit
 	$ git remote
 	origin
@@ -733,7 +788,8 @@ Om te zien welke remote servers je geconfigureerd hebt, kun je het `git remote`
 Je kunt ook `-v` specificeren, wat je de URL laat zien die Git bij de verkorte naam heeft opgeslagen om naar geëxpandeerd te worden:
 
 	$ git remote -v
-	origin	git://github.com/schacon/ticgit.git
+	origin  git://github.com/schacon/ticgit.git (fetch)
+	origin  git://github.com/schacon/ticgit.git (push)
 
 Als je meer dan één remote hebt, dan laat het commando ze allemaal zien. Bijvoorbeeld, mijn Grit repository ziet er ongeveer zo uit.
 
@@ -745,11 +801,11 @@ Als je meer dan één remote hebt, dan laat het commando ze allemaal zien. Bijvo
 	koke      git://github.com/koke/grit.git
 	origin    git@github.com:mojombo/grit.git
 
-Dit betekent dat we vrij gemakkelijk de bijdragen van ieder van deze gebruikers naar binnen kunnen pullen. Let op dat alleen de origin een SSH URL is, dus dat is de enige waar ik naartoe kan pushen (we laten het waarom zien in *Hoofdstuk 4*).
+Dit betekent dat we vrij gemakkelijk de bijdragen van ieder van deze gebruikers naar binnen kunnen pullen. Maar merk ook op dat alleen de origin een SSH URL is, dus dat is de enige waar ik naartoe kan pushen (we laten in *Hoofdstuk 4* zien waarom dat zo is).
 
 ### Remote repositories toevoegen ###
 
-Ik heb het toevoegen van remote repositories al genoemd en getoond in vorige secties, maar hier toon ik het expliciet. Om een nieuw Git remote repository als een makkelijk te refereren alias toe te voegen, voer `git remote add [verkorte naam] [url]` uit:
+Ik heb het toevoegen van remote repositories al genoemd en getoond in vorige paragrafen, maar hier toon ik expliciet hoe dat gedaan wordt. Om een nieuw Git remote repository als een makkelijk te refereren alias toe te voegen, voer je `git remote add [verkorte naam] [url]` uit:
 
 	$ git remote
 	origin
@@ -758,7 +814,7 @@ Ik heb het toevoegen van remote repositories al genoemd en getoond in vorige sec
 	origin	git://github.com/schacon/ticgit.git
 	pb	git://github.com/paulboone/ticgit.git
 
-Nu kun je de naam pb in de shell gebruiken in plaats van de hele URL. Bijvoorbeeld, als je alle informatie die Paul wel, maar jij niet in je repository wilt fetchen, dan kun je git fetch pb uitvoeren:
+Nu kun je de naam pb op de commandoregel gebruiken in plaats van de hele URL. Bijvoorbeeld, als je alle informatie die Paul wel, maar jij niet in je repository wilt fetchen, dan kun je git fetch pb uitvoeren:
 
 	$ git fetch pb
 	remote: Counting objects: 58, done.
@@ -769,7 +825,7 @@ Nu kun je de naam pb in de shell gebruiken in plaats van de hele URL. Bijvoorbee
 	 * [new branch]      master     -> pb/master
 	 * [new branch]      ticgit     -> pb/ticgit
 
-Paul zijn master branch is lokaal toegankelijk als `pb/master` — je kunt het in een van jouw branches mergen, of je kunt een lokale branch uitchecken op dat punt als je het wil zien.
+Paul zijn master branch is lokaal toegankelijk als `pb/master`; je kunt het in een van jouw branches mergen, of je kunt een lokale branch uitchecken op dat punt als je het wil zien.
 
 ### Van je remotes fetchen en pullen ###
 
@@ -777,19 +833,19 @@ Zoals je zojuist gezien hebt, kun je om data van je remote projecten te halen di
 
 	$ git fetch [remote-name]
 
-Het commando gaat naar het remote project en haalt alle data van dat remote project dat jij nog niet hebt. Nadat je dit gedaan hebt, zou je references (referenties) naar alle branches van dat remote moeten hebben, die je op ieder tijdstip kunt mergen en bekijken. (We zullen zien wat branches precies zijn, en hoe je ze moet gebruiken in meer detail in *Hoofdstuk 3*.)
+Het commando gaat naar het remote project en haalt alle data van dat remote project dat jij nog niet hebt. Nadat je dit gedaan hebt, zou je references (referenties) naar alle branches van dat remote moeten hebben, die je op ieder tijdstip kunt mergen en bekijken. (We zullen in meer detail zien wat branches precies zijn, en hoe je ze moet gebruiken in *Hoofdstuk 3*.)
 
-Als je een repository kloont, voegt dat commando dat remote repository automatisch toe onder de naam *origin*. Dus `git fetch origin` fetched (haalt) ieder nieuw werk dat gepusht is naar die server sinds je gekloond hebt (of voor het laatst ge-fetched hebt). Het is belangrijk om te weten dat het fetch commando de data naar je locale repository haalt — het merged niet automatisch met je werk of verandert waar je momenteel aan zit te werken. Je kunt het handmatig in je werk mergen als je er klaar voor bent.
+Als je een repository cloned, voegt dat commando die remote repository automatisch toe onder de naam *origin*. Dus `git fetch origin` fetcht (haalt) ieder nieuw werk dat gepusht is naar die server sinds je gecloned hebt (of voor het laatst gefetcht hebt). Het is belangrijk om te weten dat het fetch commando de data naar je locale repository haalt; het merged niet automatisch met je werk of verandert waar je momenteel aan zit te werken. Je moet het handmatig in je werk mergen wanneer je er klaar voor bent.
 
-Als je een branch geconfigureerd hebt om een remote branch te tracken (volgen) (zie de volgende sectie en *Hoofdstuk 3* voor meer informatie), dan kun je het `git pull` commando gebruiken om automatisch een remote branch te fetchen en mergen in je huidige branch. Dit kan makkelijker of meer comfortabel zijn voor je werkwijze; en standaard stelt het `git clone` commando je lokale master branch zo in dat het de remote master branch van de server waarvan je gekloond hebt volgt (aangenomen dat de remote een master branch heeft). Over het algemeen zal een `git pull` dat van de server waarvan je origineel gekloond hebt halen en proberen het automatisch in de code waar je op dat moment aan zit te werken te mergen.
+Als je een branch geconfigureerd hebt om een remote branch te volgen (tracken) (zie de volgende paragraaf en *Hoofdstuk 3* voor meer informatie), dan kun je het `git pull` commando gebruiken om automatisch een remote branch te fetchen en mergen in je huidige branch. Dit kan makkelijker of meer comfortabele workflow zijn voor je; en standaard stelt het `git clone` commando je lokale master branch zo in dat het de remote master branch van de server waarvan je gecloned hebt volgt (aangenomen dat de remote een master branch heeft). Over het algemeen zal een `git pull` dat van de server waarvan je origineel gecloned hebt halen en proberen het automatisch in de code waar je op dat moment aan zit te werken te mergen.
 
-### Je remotes pushen ###
+### Naar je remotes pushen ###
 
-Wanneer je je project op een punt krijgt dat je het wilt delen, dan moet je het stroomopwaarts pushen. Het commando hiervoor is simpel: `git push [remote-name] [branch-name]`. Als je je master branch naar je `origin` server wilt pushen (nogmaals, over het algemeen zet klonen beide namen automatisch goed voor je), dan kun je dit uitvoeren om je werk terug op de server te pushen:
+Wanneer je jouw project op een punt hebt dat je het wilt delen, dan moet je het stroomopwaarts pushen. Het commando hiervoor is simpel: `git push [remote-name] [branch-name]`. Als je de master branch naar je `origin` server wilt pushen (nogmaals, over het algemeen zet clonen beide namen automatisch goed voor je), dan kun je dit uitvoeren om je werk terug op de server te pushen:
 
 	$ git push origin master
 
-Dit commando werkt alleen als je gekloond hebt van een server waarop je schrijfrechten hebt, en als niemand in de tussentijd gepusht heeft. Als jij en iemand anders op hetzelfde tijdstip gekloond hebben en zij pushen stroomopwaarts en dan jij, dan zal je push terecht geweigerd worden. Je zult eerst hun werk moeten pullen en in jouw werk verwerken voordat je toegestaan wordt te pushen. Zie *Hoofdstuk 3* voor meer gedetailleerde informatie over hoe je naar remote servers moet pushen.
+Dit commando werkt alleen als je gecloned hebt van een server waarop je schrijfrechten hebt, en als niemand in de tussentijd gepusht heeft. Als jij en iemand anders op hetzelfde tijdstip gecloned hebben en zij pushen eerder stroomopwaarts dan jij, dan zal je push terecht geweigerd worden. Je zult eerst hun werk moeten pullen en in jouw werk verwerken voordat je toegestaan wordt te pushen. Zie *Hoofdstuk 3* voor meer gedetailleerde informatie over hoe je naar remote servers moet pushen.
 
 ### Een remote inspecteren ###
 
@@ -804,9 +860,9 @@ Als je meer informatie over een bepaalde remote wilt zien, kun je het `git remot
 	    master
 	    ticgit
 
-Het toont de URL voor de remote repository, samen met de tracking branch informatie. Het commando vertelt je behulpzaam dat als je op de master branch zit, en je voert `git pull` uit, dan zal het automatisch de master branch op de remote mergen nadat het alle remote references opgehaald heeft. Het toont ook alle remote referenties die het gepulled heeft.
+Het toont de URL voor de remote repository samen met de tracking branch informatie. Het commando vertelt je behulpzaam dat als je op de master branch zit en je voert `git pull` uit, dat Git dan automatisch de master branch van de remote zal mergen nadat het alle remote references opgehaald heeft. Het toont ook alle remote referenties die het gepulled heeft.
 
-Dat is een eenvoudig voorbeeld dat je vaak tegenkomt. Als je Git meer intensief gebruikt, zul je veel meer informatie van `git remote show` krijgen:
+Dat is een eenvoudig voorbeeld dat je vaak zult tegenkomen. Als je Git echter intensiever gebruikt, zul je veel meer informatie van `git remote show` krijgen:
 
 	$ git remote show origin
 	* remote origin
@@ -841,19 +897,19 @@ Als je een referentie wilt hernoemen, dan kun je in nieuwere versie van Git `git
 	origin
 	paul
 
-Het is de moeite om te melden dat dit ook je remote branch naam verandert. Wat voorheen gerefereerd werd als `pb/master` is nu `paul/master`.
+Het is de moeite waard om te melden dat dit ook je remote branch naam verandert. Wat voorheen gerefereerd werd als `pb/master` is nu `paul/master`.
 
-Als je om een of andere reden een referentie wilt verwijderen — je hebt de server verplaatst of je gebruikt een bepaalde spiegel niet meer, of een medewerker doet niet meer mee — dan kun je `git remote rm` gebruiken:
+Als je om een of andere reden een referentie wilt verwijderen, je hebt de server verplaatst of je gebruikt een bepaalde mirror niet meer, of een medewerker doet niet meer mee, dan kun je `git remote rm` gebruiken:
 
 	$ git remote rm paul
 	$ git remote
 	origin
 
-## Labelen ##
+## Labelen (Taggen) ##
 
-Zoals de meeste VCS'en, heeft git de mogelijkheid om specifieke punten in de history als belangrijk te taggen (labelen). Over het algemeen gebruiken mensen deze functionaliteit om versie punten te markeren (v1.0, en verder). In deze sectie zul je leren hoe de beschikbare tags te tonen, hoe nieuwe tags te creëren, en wat de verschillende typen tags zijn.
+Zoals de meeste VCS'en, heeft git de mogelijkheid om specifieke punten in de history als belangrijk te labelen (taggen). Over het algemeen gebruiken mensen deze functionaliteit om versie punten te markeren (`v1.0`, en zo). In deze paragraaf zul je leren hoe de beschikbare tags te tonen, hoe nieuwe tags te creëren, en wat de verschillende typen tags zijn.
 
-### Je tags laten zien ###
+### Jouw tags laten zien ###
 
 De beschikbare tags in Git laten zien is rechttoe rechtaan. Type gewoon `git tag`:
 
@@ -861,7 +917,7 @@ De beschikbare tags in Git laten zien is rechttoe rechtaan. Type gewoon `git tag
 	v0.1
 	v1.3
 
-Dit commando toont de tags in alfabetische volgorde; de volgorde waarin ze verschijnen heeft geen echt belang.
+Dit commando toont de tags in alfabetische volgorde; de volgorde waarin ze verschijnen heeft geen echte betekenis.
 
 Je kunt ook zoeken op tags met een bepaald patroon. De Git bron repository, bijvoorbeeld, bevat meer dan 240 tags. Als je alleen geïnteresseerd bent om naar de 1.4.2 serie te kijken, kun je dit uitvoeren:
 
@@ -873,11 +929,11 @@ Je kunt ook zoeken op tags met een bepaald patroon. De Git bron repository, bijv
 
 ### Tags creëren ###
 
-Git gebruikt twee soorten tags: lightweight (lichtgewicht) en annotated (beschreven). Een lichtgewicht tag komt overeen met een branch die niet verandert — het is slechts een wijzer naar een specifieke commit. Beschreven tags daarentegen, zijn als volwaardige objecten in de Git database opgeslagen. Ze worden gechecksummed, bevatten de naam van de tagger, e-mail en datum, hebben een tag boodschap, en kunnen gesigneerd en geverifieerd worden met GNU Privacy Guard (GPG). Het wordt over het algemeen aangeraden om beschreven tags te maken zodat je deze informatie hebt; maar als je een tijdelijke tag wilt of om een of andere reden de andere informatie niet wilt houden, dan zijn er ook lichtgewicht tags.
+Git gebruikt twee soorten tags: lichtgewicht (lightweight) en beschreven (annotated). Een lightweight tag komt overeen met een branch die niet verandert: het is slechts een wijzer naar een specifieke commit. Annotated tags daarentegen, zijn als volwaardige objecten in de Git database opgeslagen. Ze worden gechecksummed, bevatten de naam van de tagger, e-mail en datum, hebben een tag boodschap, en kunnen gesigneerd en geverifieerd worden met GNU Privacy Guard (GPG). Het wordt over het algemeen aangeraden om annotated tags te maken zodat je deze informatie hebt; maar als je een tijdelijke tag wilt of om een of andere reden de andere informatie niet wilt houden, dan zijn er ook lichtgewicht tags.
 
-### Beschreven tags ###
+### Annotated tags ###
 
-Een beschreven tag in Git maken is eenvoudig. Het makkelijkst is om de `-a` optie te specificeren als je het `tag` commando uitvoert:
+Een annotated tag in Git maken is eenvoudig. Het makkelijkst is om de `-a` optie te specificeren als je het `tag` commando uitvoert:
 
 	$ git tag -a v1.4 -m 'my version 1.4'
 	$ git tag
@@ -937,9 +993,9 @@ Als je `git show` op die tag uitvoert, dan kun je jouw GPG handtekening eraan va
 
 Verderop zul je leren hoe je ondertekende tags kunt verifiëren.
 
-### Lichtgewicht tags ###
+### Lightweight tags ###
 
-Een andere manier om een tag te committen is met behulp van een lichtgewicht tag. Dit is in principe de commit checksum in een bestand opgeslagen — er wordt geen andere informatie bijgehouden. Om een lichtgewicht tag te maken voeg je niet de `-a`, `-s` of de `-m` optie toe:
+Een andere manier om een tag te committen is met behulp van een lightweight tag. Dit is in principe de commit checksum in een bestand opgeslagen; er wordt geen andere informatie bijgehouden. Om een lightweight tag te maken voeg je niet de `-a`, `-s` noch de `-m` optie toe:
 
 	$ git tag v1.4-lw
 	$ git tag
@@ -985,7 +1041,7 @@ Als je de publieke sleutel van degene die getekend heeft niet hebt, dan krijg je
 
 ### Later taggen ###
 
-Je kunt ook commits taggen nadat je verder gegaan bent. Stel dat je commit historie er zo uitziet:
+Je kunt ook commits taggen waar je al voorbij bent. Stel dat je commit historie er zo uitziet:
 
 	$ git log --pretty=oneline
 	15027957951b64cf874c3557a0f3547bd83b3ff6 Merge branch 'experiment'
@@ -999,7 +1055,7 @@ Je kunt ook commits taggen nadat je verder gegaan bent. Stel dat je commit histo
 	964f16d36dfccde844893cac5b347e7b3d44abbc commit the todo
 	8a5cbc430f1a9c3d00faaeffd07798508422908a updated readme
 
-Nu, stel dat je vergeten bent het project op v1.2 te taggen, daar waar de "updated rakefile" commit was. Je kunt dit nadien toevoegen. Om die commit te taggen, specificeer je de commit boodschap (of een gedeelte daarvan) aan het einde van het commando:
+Stel nu dat je vergeten bent het project op v1.2 te taggen, daar waar de "updated rakefile" commit was. Je kunt dit nadien toevoegen. Om die commit te taggen, specificeer je de commit boodschap (of een gedeelte daarvan) aan het einde van het commando:
 
 	$ git tag -a v1.2 9fceb02
 
@@ -1038,7 +1094,7 @@ Standaard zal het `git push` commando geen tags naar remote servers versturen. J
 	To git@github.com:schacon/simplegit.git
 	* [new tag]         v1.5 -> v1.5
 
-Als je veel tags hebt die je ineens wilt pushen, kun je ook de `--tags` optie aan het `git push` commando toevoegen. Dit zal al je tags, die nog niet op de remote server zijn, in een keer er naartoe sturen.
+Als je veel tags hebt die je ineens wilt pushen, kun je ook de `--tags` optie aan het `git push` commando toevoegen. Dit zal al je tags, die nog niet op de remote server zijn, in één keer er naartoe sturen.
 
 	$ git push origin --tags
 	Counting objects: 50, done.
@@ -1052,7 +1108,7 @@ Als je veel tags hebt die je ineens wilt pushen, kun je ook de `--tags` optie aa
 	 * [new tag]         v1.4-lw -> v1.4-lw
 	 * [new tag]         v1.5 -> v1.5
 
-Als nu iemand anders van jouw repository kloont of pulled, dan zullen zij al jouw tags ook krijgen.
+Als nu iemand anders van jouw repository cloned of pulled, dan zullen zij al jouw tags ook krijgen.
 
 ## Tips en trucs ##
 
@@ -1060,22 +1116,22 @@ Voordat we dit hoofdstuk over de basis van Git afsluiten laten we je nog wat kle
 
 ### Auto-aanvulling ###
 
-Als je de Bash shell gebruikt, heeft Git een fijn auto-aanvulling script dat je aan kunt zetten. Download de Git broncode, en kijk in de `contrib/completion` map; daar zou een bestand genaamd `git-completion.bash` moeten staan. Kopieer dit bestand naar je home map, en voeg dit aan je `.bashrc` bestand toe:
+Als je de Bash shell gebruikt, heeft Git een prettige auto-aanvulling script dat je aan kunt zetten. Download het direct van de Git broncode op https://github.com/git/git/blob/master/contrib/completion/git-completion.bash. Kopieer dit bestand naar je home directory, en voeg dit aan je `.bashrc` bestand toe:
 
 	source ~/.git-completion.bash
 
-Als je Git wilt instellen dat het automatische Bash shell aanvulling heeft voor alle gebruikers, kopieer dit script dan naar de `/opt/local/etc/bash_completion.d` map op Mac systemen, of naar de `/etc/bash_completion.d/` map op Linux systemen. Dit is een map met scripts dat Bash automatisch zal laden om shell aanvullingen aan te bieden.
+Als je Git wilt instellen dat het automatische Bash shell aanvulling heeft voor alle gebruikers, kopieer dit script dan naar de `/opt/local/etc/bash_completion.d` directory op Mac systemen, of naar de `/etc/bash_completion.d/` directory op Linux systemen. Dit is een directory met scripts dat Bash automatisch zal laden om shell aanvullingen aan te bieden.
 
 Als je Windows gebruikt met Git Bash, wat de standaard is als je Git op Windows installeert met msysGit, dan zou auto-aanvulling voorgeconfigureerd moeten zijn.
 
-Druk de Tab toets als je een Git commando aan het typen bent, en het zou een set suggesties voor je moeten teruggeven:
+Druk de Tab toets als je een Git commando aan het typen bent, en het zou een lijstje suggesties voor je moeten teruggeven:
 
 	$ git co<tab><tab>
 	commit config
 
-In dit geval zal git co en dan de Tab toets twee keer indrukken git commit en config voorstellen. `m<tab>` toevoegen, vult `git commit` automatisch aan.
+In dit geval zal git co en dan de Tab toets twee keer indrukken git commit en config voorstellen. Als je daarna `m<tab>` toevoegt, wordt het automatisch tot `git commit` gecompleteerd.
 
-Dit werkt ook met opties, wat waarschijnlijk meer bruikbaar is. Bijvoorbeeld, als je een `git log` commando uitvoert en je niet meer kunt herinneren wat een van de opties is, dan kun je beginnen met het te typen en Tab indrukken om te zien wat er past:
+Dit werkt ook met opties, wat nog bruikbaarder is. Bijvoorbeeld, als je een `git log` commando uitvoert en je een van de opties niet meer kunt herinneren, dan kun je beginnen met het te typen en Tab indrukken om te zien wat er past:
 
 	$ git log --s<tab>
 	--shortstat  --since=  --src-prefix=  --stat   --summary
@@ -1084,16 +1140,16 @@ Dat is een erg handig trucje en zal je misschien wat tijd en documentatie lezen
 
 ### Git aliassen ###
 
-Git zal geen commando's raden als je het gedeeltelijk intypt. Als je niet de hele tekst van ieder Git commando wilt intypen, kun je gemakkelijk een alias voor ieder commando configureren door `git config` te gebruiken. Hier zijn een aantal voorbeelden die je misschien wilt instellen:
+Git zal geen commando's afleiden uit wat gedeeltelijk intypt. Als je niet de hele tekst van ieder Git commando wilt intypen, kun je gemakkelijk een alias voor ieder commando configureren door `git config` te gebruiken. Hier zijn een aantal voorbeelden die je misschien wilt instellen:
 
 	$ git config --global alias.co checkout
 	$ git config --global alias.br branch
 	$ git config --global alias.ci commit
 	$ git config --global alias.st status
 
-Dit betekent dat je, bijvoorbeeld, in plaats van `git commit` je alleen `git ci` hoeft in te typen. Als je verder gaat met Git, zul je waarschijnlijk andere commando's ook vaker gaan gebruiken; in dat geval, schroom je niet om nieuwe aliassen te maken.
+Dit betekent dat je, bijvoorbeeld, in plaats van `git commit` je alleen `git ci` hoeft in te typen. Als je verder gaat met Git, zul je waarschijnlijk andere commando's ook vaker gaan gebruiken; in dat geval: schroom niet om nieuwe aliassen te maken.
 
-Deze techniek kan ook makkelijk zijn om commando's te maken waarvan je vindt dat ze moeten bestaan. Bijvoorbeeld, om het bruikbaarheidsprobleem wat je met het unstagen van een bestand hebt op te lossen, kun je je eigen unstage alias aan Git toevoegen:
+Deze techniek kan ook makkelijk zijn om commando's te maken waarvan je vindt dat ze zouden moeten bestaan. Bijvoorbeeld, om het bruikbaarheidsprobleem wat je met het unstagen van een bestand tegenkwam op te lossen, kun je jouw eigen unstage alias aan Git toevoegen:
 
 	$ git config --global alias.unstage 'reset HEAD --'
 
@@ -1102,7 +1158,7 @@ Dit maakt de volgende twee commando's equivalent:
 	$ git unstage fileA
 	$ git reset HEAD fileA
 
-Het lijkt wat helderder. Het is ook gebruikelijk om een `last` commando toe te voegen:
+Het lijkt wat duidelijker. Het is ook gebruikelijk om een `last` commando toe te voegen:
 
 	$ git config --global alias.last 'log -1 HEAD'
 
@@ -1117,10 +1173,10 @@ Op deze manier kun je de laatste commit makkelijk zien:
 
 	    Signed-off-by: Scott Chacon <schacon@example.com>
 
-Zoals je kunt zien, vervangt Git eenvoudigweg het nieuwe commando met waarvoor je het gealiassed hebt. Maar, misschien wil je een extern commando uitvoeren, in plaats van een Git subcommando. In dat geval begin je het commando met een `!` karakter. Dit is handig als je je eigen applicaties maakt die met een Git repository werken. We kunnen dit demonstreren door `git visual` een `gitk` te laten uitvoeren:
+Zoals je kunt zien, vervangt Git eenvoudigweg het nieuwe commando met hetgeen waarvoor je het gealiassed hebt. Maar, misschien wil je een extern commando uitvoeren, in plaats van een Git subcommando. In dat geval begin je het commando met een `!` karakter. Dit is handig als je je eigen applicaties maakt die met een Git repository werken. We kunnen dit demonstreren door `git visual` een `gitk` te laten uitvoeren:
 
 	$ git config --global alias.visual '!gitk'
 
 ## Samenvatting ##
 
-Op dit punt kun je alle basis locale Git operaties doen – een repository creëren of klonen, wijzigingen maken, de wijzigingen stagen en committen, en de historie bekijken van alle veranderingen die de repository ondergaan heeft. Als volgende gaan we Gits beste optie bekijken: het branching model.
+Op dit punt kun je alle basis locale Git operaties doen: een repository creëren of clonen, wijzigingen maken, de wijzigingen stagen en committen en de historie bekijken van alle veranderingen die de repository ondergaan heeft. Als volgende gaan we de beste eigenschap van Git bekijken: het branching model.

From e9fcfae7a6bfb26c8b0fd287134a3d71ac95cb79 Mon Sep 17 00:00:00 2001
From: JLuc <jluc@no-log.org>
Date: Fri, 14 Feb 2014 21:38:59 +0100
Subject: [PATCH 219/690] accord avec "la plupart"
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

cf http://fr.wiktionary.org/wiki/plupart#Note sauf archaïsme, le verbe est au pluriel
---
 fr/01-introduction/01-chapter1.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fr/01-introduction/01-chapter1.markdown b/fr/01-introduction/01-chapter1.markdown
index 73cb6bee2..fbc0ef1ad 100644
--- a/fr/01-introduction/01-chapter1.markdown
+++ b/fr/01-introduction/01-chapter1.markdown
@@ -118,7 +118,7 @@ Nous explorerons les bénéfices qu'il y a à penser les données de cette mani
 
 ### Presque toutes les opérations sont locales ###
 
-La plupart des opérations de Git ne nécessite que des fichiers et ressources locaux — généralement aucune information venant d'un autre ordinateur du réseau n'est nécessaire.
+La plupart des opérations de Git ne nécessitent que des fichiers et ressources locaux — généralement aucune information venant d'un autre ordinateur du réseau n'est nécessaire.
 Si vous êtes habitué à un CVCS où toutes les opérations sont ralenties par la latence des échanges réseau, cet aspect de Git vous fera penser que les dieux de la vitesse ont octroyé leurs pouvoirs à Git.
 Comme vous disposez de l'historique complet du projet localement sur votre disque dur, la plupart des opérations semblent instantanées.
 

From f7d948183ea03ec1d8595eb5ebd85ca3297a4824 Mon Sep 17 00:00:00 2001
From: cor <git@cpt1.demon.nl>
Date: Fri, 14 Feb 2014 21:17:52 +0100
Subject: [PATCH 220/690] [nl] Chapter 02. Review, include new command output
 and add header.

   Reviewed translations and made them more consistent and in line with
   the recommendations of the Dutch language institute.
   Added a header to that effect to the file.
   Included the new modified command output.
---
 nl/02-git-basics/01-chapter2.markdown | 530 ++++++++++++++------------
 1 file changed, 293 insertions(+), 237 deletions(-)

diff --git a/nl/02-git-basics/01-chapter2.markdown b/nl/02-git-basics/01-chapter2.markdown
index 4871c86a3..48f865390 100644
--- a/nl/02-git-basics/01-chapter2.markdown
+++ b/nl/02-git-basics/01-chapter2.markdown
@@ -1,20 +1,35 @@
+<!-- Attentie heren en dames vertalers.
+
+Ik zou het volgende willen voorstellen:
+Er zijn bepaalde termen die voor de gemiddelde Nederlandse computer gebruiker veel beter klinken (of bekender voorkomen) als de orginele Engelse term. In het begin zullen deze termen niet vaak voorkomen, maar in de meer diepgaandere hoofdstukken komen deze steeds meer voor. Termen als "Committen", "Mergen" en "Applyen" klinken beter dan "Plegen" of "Toepassen", "Samenvoegen" en "Toepassen" (wat bovendien slecht valt te onderscheiden van de commit-toepassing). De mensen die dit boek lezen zijn, naar mijn bescheiden inschatting, al redelijk op de hoogte van versiebeheer en passen (zie ik in de praktijk) deze termen al toe. Een nieuwe terminologie introduceren lijkt me dan ook niet noodzakelijk.
+Verder blijven er altijd kreten over als "directory", wat vertaald zou kunnen worden als "map", maar bij het Engelse werkwoord to map, krijgen we dan weer het probleem: hoe dit weer te vertalen. Daarom zou ik willen voorstellen om deze basis-termen toch onvertaald te laten.
+Twijfelgevallen zullen altijd blijven zoals de term "file", daarvan wordt in de praktijk zowel de term file als bestand gebruikt. Ik denk dat we hier moeten kijken hoe het in de context past. 
+Maar ook een term als "tool" en (ik zit zelf nog op een mooie Nederlandse term te broeden) "plumbing", hierbij stel ik voor om eenmalig een Nederlandse vertaling te geven, tussen haakjes de Engelse term te geven en in het vervolg de Engelse term te gebruiken. Wederom is de context hier belangrijk.
+
+Verder stel ik ook voor om de regels op https://onzetaal.nl/taaladvies zoveel mogelijk te volgen. Bijvoorbeeld de regels omtrent het spellen van Engelse werkwoorden die in het Nederlands gebruikt worden.
+
+Let wel: ik wil niemand tot iets verplichten, maar ik denk dat we moeten streven naar een zo duidelijk mogelijke en best bij de praktijk aansluitende vertaling moeten proberen te maken.
+
+Veel succes en plezier bij het vertalen...
+
+-->
 # De basis van Git #
 
-Als je slechts één hoofdstuk kunt lezen om met Git aan de slag te gaan, dan is dit het. Dit hoofdstuk behandelt elk van de basiscommando's, die je nodig hebt om het leeuwendeel van de dingen te doen waarmee je uiteindelijk je tijd met Git zult doorbrengen. Als je dit hoofdstuk doorgenomen hebt, zul je een archief (repository) kunnen configureren en initialiseren, bestanden beginnen en stoppen te volgen en veranderingen te ‘stagen’ en ‘committen’. We laten ook zien hoe je Git kunt instellen zodat het bepaalde bestanden en bestandspatronen negeert, hoe je vergissingen snel en gemakkelijk ongedaan kunt maken, hoe je de geschiedenis van je project kan doorlopen en wijzigingen tussen commits kunt zien, en hoe je kunt pushen en pullen van en naar andere repositories.
+Als je slechts één hoofdstuk kunt lezen om met Git aan de slag te gaan, dan is deze het. In dit hoofdstuk worden alle basiscommando's behandeld, die je nodig hebben om het leeuwendeel van de dingen te doen waarmee je uiteindelijk je tijd met Git zult doorbrengen. Als je dit hoofdstuk doorgenomen hebt, zul je een repository kunnen configureren en initialiseren, bestanden beginnen en stoppen te volgen en veranderingen te ‘stagen’ en ‘committen’. We laten ook zien hoe je Git kunt instellen zodat het bepaalde bestanden en bestandspatronen negeert, hoe je vergissingen snel en gemakkelijk ongedaan kunt maken, hoe je de geschiedenis van je project kan doorlopen en wijzigingen tussen commits kunt zien, en hoe je kunt pushen en pullen van en naar repositories.
 
 ## Een Git repository verkrijgen ##
 
-Je kunt op twee manieren een Git project verkrijgen. De eerste maakt gebruik van een bestaand project of map en importeert dit in Git. De tweede maakt een kloon (clone) van een bestaande Git repository op een andere server.
+Je kunt op twee manieren een Git project verkrijgen. De eerste maakt gebruik van een bestaand project of directory en importeert dit in Git. De tweede maakt een kloon (clone) van een bestaande Git repository op een andere server.
 
-### Een repository initialiseren in een bestaande map ###
+### Een repository initialiseren in een bestaande directory ###
 
-Als je een bestaand project in Git wilt volgen (track), dan moet je naar de projectmap gaan en het volgende typen
+Als je een bestaand project in Git wilt volgen (tracken), dan moet je naar de projectdirectory gaan en het volgende typen
 
 	$ git init
 
-Dit maakt een nieuwe submap aan genaamd `.git`, die alle noodzakelijke repository bestanden bevat — een Git repository skelet. Op dit punt wordt nog niets in je project gevolgd. (Zie Hoofdstuk 9 voor meer informatie over welke bestanden er precies in de `.git` map staan, die je zojuist gemaakt hebt.)
+Dit maakt een nieuwe subdirectory met de naam `.git` aan, die alle noodzakelijke repository bestanden bevat, een Git repository raamwerk. Op dit moment wordt nog niets in je project gevolgd. (Zie *Hoofdstuk 9* voor meer informatie over welke bestanden er precies in de `.git` directory staan, die je zojuist gemaakt hebt.)
 
-Als je de versies van bestaande bestanden wilt gaan beheren (in plaats van een lege map), dan zul je waarschijnlijk die bestanden beginnen te volgen en een eerste commit willen doen. Dit kun je bereiken door een paar git add commando's die de te volgen bestanden specificeren, gevolgd door een commit:
+Als je de versies van bestaande bestanden wilt gaan beheren (in plaats van een lege directory), dan zul je die bestanden moeten beginnen te tracken en een eerste commit doen. Dit kun je bereiken door een paar `git add` commando's waarin je de te volgen bestanden specificeert, gevolgd door een commit:
 
 	$ git add *.c
 	$ git add README
@@ -22,44 +37,44 @@ Als je de versies van bestaande bestanden wilt gaan beheren (in plaats van een l
 
 We zullen zodadelijk beschrijven wat deze commando's doen. Op dit punt heb je een Git repository met gevolgde (tracked) bestanden en een initiële commit.
 
-### Een bestaand repository klonen ###
+### Een bestaand repository clonen ###
 
-Als je een kopie wilt van een bestaande Git repository — bijvoorbeeld een project waaraan je wilt bijdragen — dan is `git clone` het commando wat je nodig hebt. Als je bekend bent met andere versie-beheersystemen zoals Subversion, dan valt je op dat het commando `clone` is en niet `checkout`. Dit is een belangrijk verschil — Git ontvangt een kopie van bijna alle data die de server heeft. Iedere versie van ieder bestand van de hele geschiedenis van een project wordt binnengehaald als je `git clone` doet. In feite kun je, als je disk kapot gaat, iedere kloon van iedere client gebruiken om de server terug in de status te brengen op het moment van klonen (al zou je wel wat hooks en dergelijke verliezen, maar alle versies van alle bestanden zouden er zijn — zie *Hoofdstuk 4* voor meer informatie).
+Als je een kopie wilt van een bestaande Git repository, bijvoorbeeld een project waaraan je wilt bijdragen, dan is `git clone` het commando dat je nodig hebt. Als je bekend bent met andere versie-beheersystemen zoals Subversion, dan zal het je opvallen dat het commando `clone` is en niet `checkout`. Dit is een belangrijk verschil: Git ontvangt een kopie van bijna alle gegevens die de server heeft. Elke versie van ieder bestand in de hele geschiedenis van een project wordt binnengehaald als je `git clone` doet. In feite kun je als de schijf van de server kapot gaat, een clone van een willekeurige client gebruiken om de server terug in de status te brengen op het moment van clonen (al zou je wel wat hooks aan de kant van de server en dergelijke verliezen, maar alle versies van alle bestanden zullen er zijn; zie *Hoofdstuk 4* voor meer informatie).
 
-Je kloont een repository met `git clone [url]`. Bijvoorbeeld, als je de Ruby Git bibliotheek genaamd Grit wilt klonen, kun je dit als volgt doen:
+Je cloned een repository met `git clone [url]`. Bijvoorbeeld, als je de Ruby Git bibliotheek genaamd Grit wilt clonen, kun je dit als volgt doen:
 
 	$ git clone git://github.com/schacon/grit.git
 
-Dat maakt een map genaamd `grit` aan, initialiseert hierin een `.git` map, haalt alle data voor dat repository binnen, en doet een checkout van een werkkopie van de laatste versie. Als je in de nieuwe `grit` map gaat, zul je de project bestanden vinden, klaar om gebruikt of aan gewerkt te worden. Als je de repository in een map met een andere naam dan grit wilt klonen, dan kun je dit met het volgende commando specificeren:
+Dat maakt een directory genaamd `grit` aan, initialiseert hierin een `.git` directory, haalt alle data voor die repository binnen en doet een checkout van een werkkopie van de laatste versie. Als je in de nieuwe `grit` directory gaat kijken zal je de project bestanden vinden, klaar om gebruikt of aan gewerkt te worden. Als je de repository in een directory met een andere naam dan grit wilt clonen, dan kun je dit met het volgende commando specificeren:
 
 	$ git clone git://github.com/schacon/grit.git mygrit
 
-Dat commando doet hetzelfde als het vorige, maar dan heet de doelmap `mygrit`.
+Dat commando doet hetzelfde als het vorige, maar dan heet de doeldirectory `mygrit`.
 
-Git heeft een aantal verschillende transport protocollen die je kunt gebruiken. Het vorige voorbeeld maakt gebruik van het `git://` protocol, maar je kunt ook `http(s)://` of `gebruiker@server:/pad.git` tegenkomen, dat het SSH transport protocol gebruikt. *Hoofdstuk 4* zal alle beschikbare opties introduceren die de server kan gebruiken om je Git repository aan te kunnen, met daarbij de voors en tegens van elk.
+Git heeft een aantal verschillende transport protocollen die je kunt gebruiken. Het vorige voorbeeld maakt gebruik van het `git://` protocol, maar je kunt ook `http(s)://` of `gebruiker@server:/pad.git` tegenkomen, dat het SSH transport protocol gebruikt. *Hoofdstuk 4* zal alle beschikbare opties introduceren die de server kan inrichten om je toegang tot de Git repositories te geven, met daarbij de voors en tegens van elk.
 
 ## Wijzigingen aan het repository vastleggen ##
 
-Je hebt een bonafide Git repository en een checkout of werkkopie van de bestanden voor dat project. Je moet wat wijzigingen maken en deze committen in je repository, iedere keer zodra het project een status bereikt die je wilt vastleggen.
+Je hebt een eersteklas Git repository en een checkout of werkkopie van de bestanden binnen dat project. Als je wijzigingen maakt dan moet je deze committen in je repository op elk momend dat het project een status bereikt die je wilt vastleggen.
 
-Onthoud dat ieder bestand in je werkmap in twee statussen kan verkeren: *gevolgd (tracked)* of *niet gevolgd (untracked)*. *Gevolgde* bestanden zijn bestanden die in het laatste snapshot zaten; ze kunnen *ongewijzigd*, *gewijzigd* of *staged zijn*. *Niet gevolgde* bestanden zijn al het andere - ieder bestand in je werkmap dat niet in je laatste snapshot en niet in je staging gebied zit. Als je voor het eerst een repository kloont, zullen al je bestanden gevolgd en ongewijzigd zijn, omdat je ze zojuist ge-checkout en niet gewijzigd hebt.
+Onthoud dat elk bestand in je werkdirectory in een van twee statussen kan verkeren: *gevolgd (tracked)* of *niet gevolgd (untracked)*. *Tracked* bestanden zijn bestanden die in het laatste snapshot zaten; ze kunnen *ongewijzigd (unmodified)*, *gewijzigd (modified)* of *staged* zijn. *untracked* bestanden zijn al het andere; elk bestand in je werkdirectory dat niet in je laatste snapshot en niet in je staging area zit. Als je een repository voor het eerst cloned, zullen alle bestanden tracked en unmodified zijn, omdat je ze zojuist uitgechecked hebt en nog niets gewijzigd hebt.
 
-Zodra je bestanden wijzigt, ziet Git ze als gewijzigd omdat je ze veranderd hebt sinds je laatste commit. Je *staged* deze gewijzigde bestanden en commit al je ge-stagede wijzigingen, en de cyclus herhaalt zichzelf. Deze cyclus wordt in Figuur 2-1 geïllustreerd.
+Zodra je bestanden wijzigt, ziet Git ze als modified omdat je ze veranderd hebt sinds je laatste commit. Je *staged* deze gewijzigde bestanden en commit al je gestagede wijzigingen, en de cyclus begint weer van voor af aan. Deze cyclus wordt in Figuur 2-1 geïllustreerd.
 
 Insert 18333fig0201.png
 Figuur 2-1. De levenscyclus van de status van je bestanden.
 
 ### De status van je bestanden controleren ###
 
-Het hoofdcommando dat je zult gebruiken om te bepalen welk bestand zich in welke status bevindt is `git status`. Als je dit commando direct na het klonen uitvoert, dan zul je zoiets als het volgende zien:
+Het commando dat je voornamelijk zult gebruiken om te bepalen welk bestand zich in welke status bevindt is `git status`. Als je dit commando direct na het clonen uitvoert, dan zal je zoiets als het volgende zien:
 
 	$ git status
 	# On branch master
 	nothing to commit (working directory clean)
 
-Dit betekent dat je een schone werkmap hebt — met andere woorden, er zijn geen gevolgde en gewijzigde bestanden. Git ziet ook geen ongevolgde bestanden, anders zouden ze hier getoond worden. Als laatste vertelt het commando op welke tak (branch) je nu zit. Voor nu is dit altijd `master`, dat is de standaard; maak je je hier nog niet druk om. Het volgende hoofdstuk gaat in detail over takken en referenties.
+Dit betekent dat je een schone werkdirectory hebt, met andere woorden er zijn geen untracked bestanden die gewijzigd zijn. Git ziet ook geen untracked bestanden, anders zouden ze hier getoond worden. Als laatste vertelt het commando op welke tak (branch) je nu zit. Voor nu is dit altijd `master`, dat is de standaard; besteed daar voor nu nog geen aandacht aan. In het volgende hoofdstuk wordt gedetaileerd ingegaan op branches en referenties.
 
-Stel dat je een nieuw bestand toevoegt aan je project, een simpel README bestand. Als het bestand voorheen nog niet bestond, en je doet `git status`, dan zul je je ongevolgde bestand zo zien:
+Stel dat je een nieuw bestand toevoegt aan je project, een simpel README bestand. Als het bestand voorheen nog niet bestond, en je doet `git status`, dan zul je het niet getrackte bestand op deze manier zien:
 
 	$ vim README
 	$ git status
@@ -70,15 +85,15 @@ Stel dat je een nieuw bestand toevoegt aan je project, een simpel README bestand
 	#	README
 	nothing added to commit but untracked files present (use "git add" to track)
 
-Je kunt zien dat je nieuwe README bestand ongevolgd is, omdat het onder de “Untracked files” kop staat in je status output. Ongevolgd betekent eigenlijk dat Git een bestand ziet dat je niet in het vorige snapshot (commit) had; Git zal het niet in je commit snapshots toevoegen totdat jij haar er expliciet om vraagt. Ze doet dit zodat jij niet per ongeluk gegenereerde binaire bestanden toevoegt, of andere bestanden die je niet wou toevoegen. Je wilt dit README bestand wel toevoegen, dus laten we het gaan volgen.
+Je kunt zien dat het nieuwe README bestand untrackt is, omdat het onder de “Untracked files” kop staat in je status output. Untrackt betekent eigenlijk dat Git een bestand ziet dat je niet in het vorige snapshot (commit) had; Git zal het niet in je commit snapshots toevoegen totdat jij dit expliciet aangeeft. Dit wordt zo gedaan zodat je niet per ongeluk gegenereerde binaire bestanden toevoegt, of andere bestanden die je niet wilt toevoegen. Je wilt dit README bestand wel meenemen, dus laten we het gaan tracken.
 
 ### Nieuwe bestanden volgen (tracking) ###
 
-Om een nieuw bestand te beginnen te volgen, gebruik je het commando `git add`. Om de README te volgen, kun je dit uitvoeren:
+Om een nieuw bestand te beginnen te tracken, gebruik je het commando `git add`. Om de README te tracken, voer je dit uit:
 
 	$ git add README
 
-Als je je status commando nogmaals uitvoert, zie je dat je README bestand nu gevolgd en ge-staged is:
+Als je het status commando nogmaals uitvoert, zie je dat je README bestand nu getrackt en ge-staged is:
 
 	$ git status
 	# On branch master
@@ -88,26 +103,27 @@ Als je je status commando nogmaals uitvoert, zie je dat je README bestand nu gev
 	#	new file:   README
 	#
 
-Je kunt zien dat het ge-staged is, omdat het onder de kop “Changes to be committed” staat. Als je op dit punt een commit doet, zal de versie van het bestand zoals het wat ten tijde van je `git add` commando in de historische snapshot toegevoegd worden. Je zult je misschien herinneren dat, toen je `git init` eerder uitvoerde, je daarna `git add` (bestanden) uitvoerde — dat was om bestanden in je map te beginnen te volgen. Het `git add` commando neemt een padnaam voor een bestand of een map; als het een map is, dan voegt het commando alle bestanden in die map recursief toe.
+Je kunt zien dat het gestaged is, omdat het onder de kop “Changes to be committed” staat. Als je nu een commit doet, zal de versie van het bestand zoals het was ten tijde van je `git add` commando in de historische snapshot toegevoegd worden. Je zult je misschien herinneren dat, toen je `git init` eerder uitvoerde, je daarna `git add (bestanden)` uitvoerde; dat was om bestanden in je directory te beginnen te tracken. Het `git add` commando beschouwt een padnaam als een bestand of een directory. Als de padnaam een directory is, dan voegt het commando alle bestanden in die directory recursief toe.
 
 ### Gewijzigde bestanden stagen ###
 
-Laten we een gevolgd bestand wijzigen. Als je een voorheen gewijzigd bestand genaamd `benchmarks.rb` wijzigt, en dan je `status` commando nog eens uitvoert, krijg je iets dat er zo uitziet:
+Laten we een getrackte bestand wijzigen. Als je een reeds getrackt bestand genaamd `benchmarks.rb` wijzigt, en dan je `status` commando nog eens uitvoert, krijg je iets dat er zo uitziet:
 
 	$ git status
-	# On branch master
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#	new file:   README
-	#
-	# Changes not staged for commit:
-	#   (use "git add <file>..." to update what will be committed)
-	#
-	#	modified:   benchmarks.rb
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        new file:   README
 
-Het `benchmarks.rb` bestand verschijnt onder een sectie genaamd “Changes not staged for commit” — wat betekent dat een bestand dat gevolgd wordt gewijzigd is in de werkmap, maar nog niet ge-staged. Om het te stagen, voer je het `git add` commando uit (het is een veelzijdig commando — je gebruikt het om bestanden te volgen, om bestanden te stagen, en andere dingen zoals een bestand met een mergeconflict als opgelost te markeren). Laten we `git add` nu uitvoeren om het `benchmarks.rb` bestand nu te stagen, en dan nog eens `git status` uitvoeren:
+	Changes not staged for commit:
+	  (use "git add <file>..." to update what will be committed)
+	  (use "git checkout -- <file>..." to discard changes in working directory)
+	
+	        modified:   benchmarks.rb
+	
+
+Het `benchmarks.rb` bestand verschijnt onder een sectie genaamd “Changes not staged for commit”, wat inhoudt dat een bestand dat wordt getrackt is gewijzigd in de werkdirectory, maar nog niet is gestaged. Om het te stagen, voer je het `git add` commando uit (het is een veelzijdig commando: je gebruikt het om bestanden te laten tracken, om bestanden te stagen, en om andere dingen zoals een bestand met een mergeconflict als opgelost te markeren). Laten we nu `git add` uitvoeren om het `benchmarks.rb` bestand te stagen, en dan nog eens `git status` uitvoeren:
 
 	$ git add benchmarks.rb
 	$ git status
@@ -119,24 +135,25 @@ Het `benchmarks.rb` bestand verschijnt onder een sectie genaamd “Changes not s
 	#	modified:   benchmarks.rb
 	#
 
-Beide bestanden zijn ge-staged en zullen in je volgende commit gaan. Stel dat je je op dit punt herinnert dat je een kleine wijziging in `benchmarks.rb` wil maken voor je volgende commit. Je kunt het opnieuw openen en die wijziging maken, en dan ben je klaar voor de commit. Maar, laten we `git status` nog een keer uitvoeren:
+Beide bestanden zijn gestaged en zullen met je volgende commit meegaan. Stel nu dat je je herinnert dat je nog een kleine wijziging in `benchmarks.rb` wilt maken voordat je het commit. Je kunt het opnieuw openen en die wijziging maken, en dan ben je klaar voor de commit. Alhoewel, laten we `git status` nog een keer uitvoeren:
 
 	$ vim benchmarks.rb
 	$ git status
-	# On branch master
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#	new file:   README
-	#	modified:   benchmarks.rb
-	#
-	# Changes not staged for commit:
-	#   (use "git add <file>..." to update what will be committed)
-	#
-	#	modified:   benchmarks.rb
-	#
-
-Hé! Nu staat `benchmarks.rb` zowel bij de staged en unstaged. Hoe kan dat? Het blijkt dat Git een bestand staged precies zoals het is wanneer je het `git add` commando uitvoert. Als je nu commit, dan zal de versie van benchmarks.rb zoals het was toen je voor 't laatst `git add` uitvoerde worden toegevoegd in de commit, en niet de versie van het bestand zoals ie eruit ziet in je map wanneer je git commit uitvoert. Als je een bestand wijzigt nadat je `git add` uitvoert, dan moet je `git add` nogmaals uitvoeren om de laatste versie van het bestand te stagen:
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        new file:   README
+	        modified:   benchmarks.rb
+	
+	Changes not staged for commit:
+	  (use "git add <file>..." to update what will be committed)
+	  (use "git checkout -- <file>..." to discard changes in working directory)
+	
+	        modified:   benchmarks.rb
+	
+
+Asjemenou?! Nu staat `benchmarks.rb` zowel bij de staged en unstaged genoemd. Hoe is dat mogelijk? Het blijkt dat Git een bestand precies zoals het is staged wanneer je het `git add` commando uitvoert. Als je nu commit, dan zal de versie van `benchmarks.rb` zoals het was toen je voor 't laatst `git add` uitvoerde worden toegevoegd in de commit, en niet de versie van het bestand zoals het eruit ziet in je werkdirectory toen je `git commit` uitvoerde. Als je een bestand wijzigt nadat je `git add` uitvoert, dan moet je `git add` nogmaals uitvoeren om de laatste versie van het bestand te stagen:
 
 	$ git add benchmarks.rb
 	$ git status
@@ -150,22 +167,22 @@ Hé! Nu staat `benchmarks.rb` zowel bij de staged en unstaged. Hoe kan dat? Het
 
 ### Bestanden negeren ###
 
-Vaak zul je een klasse bestanden hebben waarvan je niet wilt dat Git deze automatisch toevoegt of zelfs maar als ongevolgd toont. Dit zijn doorgaans automatisch gegenereerde bestanden zoals logbestanden of bestanden die geproduceerd worden door je bouwsysteem. In die gevallen kun je een bestand genaamd `.gitignore` maken, waarin patronen staan die die bestanden passen. Hier is een voorbeeld van een `.gitignore` bestand:
+Vaak zul je een klasse bestanden hebben waarvan je niet wilt dat Git deze automatisch toevoegt of zelfs maar als untracked toont. Dit zijn doorgaans automatisch gegenereerde bestanden zoals logbestanden of bestanden die geproduceerd worden door je bouwsysteem. In die gevallen kun je een bestand genaamd `.gitignore` maken, waarin patronen staan die die bestanden passen. Hier is een voorbeeld van een `.gitignore` bestand:
 
 	$ cat .gitignore
 	*.[oa]
 	*~
 
-De eerste regel verteld Git om ieder bestand dat eindigt op een `.o` of `.a` — *object* en *archief* bestanden die het product kunnen zijn van het bouwen van je code. De tweede regel vertelt Git dat ze alle bestanden die eindigen op een tilde (`~`), wat gebruikt wordt door editors zoals Emacs om tijdelijke bestanden te markeren, mag negeren. Je mag ook `log`, `tmp` of een `pid` map toevoegen, automatisch gegenereerde documentatie, enzovoort. Een `.gitignore` bestand aanmaken voordat je gaat beginnen is over 't algemeen een goed idee, zodat je niet per ongeluk bestanden commit die je echt niet in je repository wilt hebben.
+De eerste regel vertelt Git om ieder bestand te negeren waarvan de naam eindigt op een `.o` of `.a` (*object* en *archief* bestanden die het product kunnen zijn van het bouwen van je code). De tweede regel vertelt Git dat ze alle bestanden die eindigen op een tilde (`~`), wat gebruikt wordt door editors zoals Emacs om tijdelijke bestanden aan te geven, moet negeren. Je mag ook `log`, `tmp` of een `pid` directory toevoegen, automatisch gegenereerde documentatie, enzovoort. Een `.gitignore` bestand aanmaken voordat je gaat beginnen is over 't algemeen een goed idee, zodat je niet per ongeluk bestanden commit die je echt niet in je repository wilt hebben.
 
 De regels voor patronen die je in het `.gitignore` bestand kunt zetten zijn als volgt:
 
 *	Lege regels of regels die beginnen met een `#` worden genegeerd.
-*	Standaard expansie patronen werken.
-*	Je mag patronen laten eindigen op een schuine streep (`/`) om een map te specificeren.
+*	Standaard expansie (glob) patronen werken.
+*	Je mag patronen laten eindigen op een schuine streep (`/`) om een directory te specificeren.
 *	Je mag een patroon ontkennend maken door het te laten beginnen met een uitroepteken (`!`).
 
-Expansie (`glob`) patronen zijn vereenvoudigde reguliere expressies die shell omgevingen gebruiken. Een asterisk (`*`) komt overeen met nul of meer karakters; `[abc]` komt overeen met ieder karakter dat tussen de blokhaken staat (in dit geval a, b of c); een vraagteken (`?`) komt overeen met een enkel karakter, en blokhaken waar tussen karakters staan die gescheiden zijn door een streepje (`[0-9]`) komen overeen met ieder karakter wat tussen die karakters zit (in dit geval 0 tot en met 9).
+Expansie (`glob`) patronen zijn vereenvoudigde reguliere expressies die in shell omgevingen gebruikt worden. Een asterisk (`*`) komt overeen met nul of meer karakters, `[abc]` komt overeen met ieder karakter dat tussen de blokhaken staat (in dit geval `a`, `b` of `c`), een vraagteken (`?`) komt overeen met een enkel karakter en blokhaken waartussen karakters staan die gescheiden zijn door een streepje (`[0-9]`) komen overeen met ieder karakter wat tussen die karakters zit (in dit geval 0 tot en met 9).
 
 Hier is nog een voorbeeld van een `.gitignore` bestand:
 
@@ -181,24 +198,27 @@ Hier is nog een voorbeeld van een `.gitignore` bestand:
 	# ignore doc/notes.txt, but not doc/server/arch.txt
 	doc/*.txt
 
+Een `**/` patroon is sinds versie 1.8.2 beschikbaar in Git.
+
 ### Je staged en unstaged wijzigingen zien ###
 
-Als het `git status` commando te vaag is voor je — je wilt precies weten wat je veranderd hebt, niet alleen welke bestanden veranderd zijn — dan kun je het `git diff` commando gebruiken. We zullen `git diff` later in meer detail bespreken; maar je zult het het meest gebruiken om deze twee vragen te beantwoorden: Wat heb je veranderd maar nog niet gestaged? En wat heb je gestaged en sta je op het punt te committen? Alhoewel `git status` deze vragen heel algemeen beantwoordt, laat `git diff` je de exacte toegevoegde en verwijderde regels zien — de patch, als het ware.
+Als het `git status` commando te vaag is voor je, je wilt precies weten wat je veranderd hebt en niet alleen welke bestanden veranderd zijn, dan kun je het `git diff` commando gebruiken. We zullen `git diff` later in meer detail bespreken, maar je zult dit commando het meest gebruiken om deze twee vragen te beantwoorden: Wat heb je veranderd maar nog niet gestaged? En wat heb je gestaged en sta je op het punt te committen? Waar `git status` deze vragen heel algemeen beantwoordt, laat `git diff` je de exacte toegevoegde en verwijderde regels zien, de patch, als het ware.
 
 Stel dat je het `README` bestand opnieuw verandert en staged, en dan het `benchmarks.rb` bestand verandert zonder het te stagen. Als je je `status` commando uitvoert, dan zie je nogmaals zoiets als dit:
 
 	$ git status
-	# On branch master
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#	new file:   README
-	#
-	# Changes not staged for commit:
-	#   (use "git add <file>..." to update what will be committed)
-	#
-	#	modified:   benchmarks.rb
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        new file:   README
+	
+	Changes not staged for commit:
+	  (use "git add <file>..." to update what will be committed)
+	  (use "git checkout -- <file>..." to discard changes in working directory)
+	
+	        modified:   benchmarks.rb
+	
 
 Om te zien wat je gewijzigd maar nog niet gestaged hebt, typ `git diff` in zonder verdere argumenten:
 
@@ -219,7 +239,7 @@ Om te zien wat je gewijzigd maar nog niet gestaged hebt, typ `git diff` in zonde
 	           log = git.commits('master', 15)
 	           log.size
 
-Dat commando vergelijkt wat er in je werkmap zit met wat er in je staging gebied zit. Het resultaat laat je zien welke wijzigingen je gedaan hebt, die je nog niet gestaged hebt.
+Dat commando vergelijkt wat er in je werkdirectory zit met wat er in je staging area zit. Het resultaat laat je zien welke wijzigingen je gedaan hebt, die je nog niet gestaged hebt.
 
 Als je wilt zien wat je gestaged hebt en in je volgende commit zal zitten, dan kun je `git diff –-cached` gebruiken. (In Git versie 1.6.1 en nieuwer kun je ook `git diff --staged` gebruiken, wat misschien beter te onthouden is.) Dit commando vergelijkt je staged wijzigingen met je laatste commit:
 
@@ -236,23 +256,25 @@ Als je wilt zien wat je gestaged hebt en in je volgende commit zal zitten, dan k
 	+
 	+Grit is a Ruby library for extracting information from a Git repository
 
-Het is belangrijk om te zien dat `git diff` zelf niet alle wijzigingen sinds je laatste commit laat zien — alleen wijzigingen die nog niet gestaged zijn. Dit kan verwarrend zijn, omdat als je al je wijzigingen gestaged hebt, `git diff` geen output zal geven.
+Het is belangrijk om te zien dat `git diff` zelf niet alle wijzigingen sinds je laatste commit laat zien, alleen wijzigingen die nog niet gestaged zijn. Dit kan verwarrend zijn, omdat als je al je wijzigingen gestaged hebt, `git diff` geen output zal geven.
 
-Nog een voorbeeld. Als je het `benchmarks.rb` bestand staged, en vervolgens verandert, dan kun je `git diff` gebruiken om de wijzigingen in het bestand te zien dat gestaged is en de wijzigingen die niet gestaged zijn:
+Nog een voorbeeld. Als je het `benchmarks.rb` bestand staged en vervolgens verandert, dan kun je `git diff` gebruiken om de wijzigingen in het bestand te zien dat gestaged is en de wijzigingen die niet gestaged zijn:
 
 	$ git add benchmarks.rb
 	$ echo '# test line' >> benchmarks.rb
 	$ git status
-	# On branch master
-	#
-	# Changes to be committed:
-	#
-	#	modified:   benchmarks.rb
-	#
-	# Changes not staged for commit:
-	#
-	#	modified:   benchmarks.rb
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        modified:   benchmarks.rb
+	
+	Changes not staged for commit:
+	  (use "git add <file>..." to update what will be committed)
+	  (use "git checkout -- <file>..." to discard changes in working directory)
+	
+	        modified:   benchmarks.rb
+	
 
 Nu kun je `git diff` gebruiken om te zien wat nog niet gestaged is
 
@@ -288,12 +310,12 @@ en `git diff --cached` om te zien wat je tot nog toe gestaged hebt:
 
 ### Je wijzigingen committen ###
 
-Nu dat je staging gebied ingesteld is op de manier zoals jij het wilt, kun je je wijzigingen committen. Onthoud dat alles wat niet gestaged is — ieder bestand dat je gemaakt of gewijzigd hebt en waarop je nog geen `git add` op uitgevoerd hebt — niet in deze commit mee zal gaan. Ze zullen als gewijzigde bestanden op je disk blijven staan.
+Nu je staging area gevuld is zoals jij het wilt, kun je de wijzigingen committen. Onthoud dat alles wat niet gestaged is, dus ieder bestand dat je gemaakt of gewijzigd hebt en waarop je nog geen `git add` uitgevoerd hebt, niet in deze commit mee zal gaan. Ze zullen als gewijzigde bestanden op je schijf blijven staan.
 In dit geval zag je de laatste keer dat je `git status` uitvoerde, dat alles gestaged was. Dus je bent er klaar voor om je wijzigingen te committen. De makkelijkste manier om te committen is om `git commit` in te typen:
 
 	$ git commit
 
-Dit start de door jou gekozen editor op. (Dit wordt bepaald door de `$EDITOR` omgevingsvariabele in je shell — meestal vim of emacs, alhoewel je dit kunt instellen op welke je ook wilt gebruiken met het `git config --global core.editor` commando zoals je in *Hoofdstuk 1* gezien hebt).
+Dit start de door jou gekozen editor op. (Dit wordt bepaald door de `$EDITOR` omgevingsvariabele in je shell, meestal vim of emacs, alhoewel je dit kunt instellen op welke editor je wilt gebruiken met het `git config --global core.editor` commando zoals je in *Hoofdstuk 1* gezien hebt).
 
 De editor laat de volgende tekst zien (dit voorbeeld is een Vim scherm):
 
@@ -301,60 +323,62 @@ De editor laat de volgende tekst zien (dit voorbeeld is een Vim scherm):
 	# with '#' will be ignored, and an empty message aborts the commit.
 	# On branch master
 	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
 	#       new file:   README
 	#       modified:   benchmarks.rb
+	#
 	~
 	~
 	~
 	".git/COMMIT_EDITMSG" 10L, 283C
 
-Je kunt zien dat de standaard commit boodschap de laatste output van het `git status` commando in commentaar bevat en een lege regel bovenaan. Je kunt deze commentaren verwijderen en je eigen commit boodschap intypen, of je kunt ze laten staan om je eraan te helpen herinneren wat je aan het committen bent. (Om een meer expliciete herinnering van je wijzigingen te zien kun je de `-v` optie meegeven aan `git commit`. Als je dit doet zet git de diff van je verandering in je editor zodat je precies kunt zien wat je gedaan hebt.) Als je de editor verlaat, creëert Git je commit boodschap (zonder de commentaren of de diff).
+Je kunt zien dat de standaard commit boodschap de laatste output van het `git status` commando als commentaar bevat en een lege regel bovenaan. Je kunt deze commentaren verwijderen en je eigen commit boodschap intypen, of je kunt ze laten staan om je eraan te helpen herinneren wat je aan het committen bent. (Om een meer expliciete herinnering van je wijzigingen te zien kun je de `-v` optie meegeven aan `git commit`. Als je dit doet zet Git de diff van je veranderingen in je editor zodat je precies kunt zien wat je gedaan hebt.) Als je de editor verlaat, creëert Git je commit boodschap (zonder de commentaren of de diff).
 
-Als alternatief kun je je commit boodschap met het `commit` commando meegeven door hem achter de `-m` optie te specificeren, zoals hier:
+Als alternatief kun je de commit boodschap met het `commit` commando meegeven door hem achter de `-m` optie te specificeren, zoals hier:
 
 	$ git commit -m "Story 182: Fix benchmarks for speed"
-	[master]: created 463dc4f: "Fix benchmarks for speed"
-	 2 files changed, 3 insertions(+), 0 deletions(-)
+	[master 463dc4f] Fix benchmarks for speed
+	 2 files changed, 3 insertions(+)
 	 create mode 100644 README
 
 Nu heb je je eerste commit gemaakt! Je kunt zien dat de commit je wat output over zichzelf heeft gegeven: op welke branch je gecommit hebt (`master`), welke SHA-1 checksum de commit heeft (`463dc4f`), hoeveel bestanden er veranderd zijn, en statistieken over toegevoegde en verwijderde regels in de commit.
 
-Onthoud dat de commit de snapshot, die je in je staging gebied ingesteld hebt, opslaat. Alles wat je niet gestaged hebt staat daar nog steeds gewijzigd; je kunt een volgende commit doen om het aan je geschiedenis toe te voegen. Iedere keer dat je een commit doet, leg je een snapshot van je project vast dat je later terug kunt draaien of mee kunt vergelijken.
+Onthoud dat de commit de snapshot, die je in je staging area ingesteld hebt, opslaat. Alles wat je niet gestaged hebt staat nog steeds gewijzigd; je kunt een volgende commit doen om het aan je geschiedenis toe te voegen. Iedere keer dat je een commit doet, leg je een snapshot van je project vast dat je later terug kunt draaien of mee kunt vergelijken.
 
-### Het staging gebied overslaan ###
+### De staging area overslaan ###
 
-Alhoewel het ontzettend makkelijk kan zijn om commits precies zoals je wilt te maken, is het staging gebied soms iets ingewikkelder dan je in je manier van werken nodig hebt. Als je het staging gebied wilt overslaan, dan biedt Git een makkelijke route binnendoor. Door de `-a` optie aan het `git commit` commando mee te geven, zal Git automatisch ieder bestand dat al getracked wordt voor de commit stagen, zodat je het `git add` gedeelte kunt overslaan:
+Alhoewel het ontzettend makkelijk kan zijn om commits precies zoals je wilt te maken, is de staging area soms iets ingewikkelder dan je in je workflow nodig hebt. Als je de staging area wilt overslaan, dan kan je met Git makkelijk de route inkorten. Door de `-a` optie aan het `git commit` commando mee te geven zal Git automatisch ieder bestand dat al getrackt wordt voor de commit stagen, zodat je het `git add` gedeelte kunt overslaan:
 
 	$ git status
-	# On branch master
-	#
-	# Changes not staged for commit:
-	#
-	#	modified:   benchmarks.rb
-	#
+	On branch master
+	Changes not staged for commit:
+	  (use "git add <file>..." to update what will be committed)
+	  (use "git checkout -- <file>..." to discard changes in working directory)
+	
+	        modified:   benchmarks.rb
+	
+	no changes added to commit (use "git add" and/or "git commit -a")
 	$ git commit -a -m 'added new benchmarks'
 	[master 83e38c7] added new benchmarks
-	 1 files changed, 5 insertions(+), 0 deletions(-)
+	 1 files changed, 5 insertions(+)
 
-Let op dat je nu geen `git add` op het `benchmarks.rb` bestand hoeft te doen voordat je commit.
+Merk op dat je nu geen `git add` op het `benchmarks.rb` bestand hoeft te doen voordat je commit.
 
 ### Bestanden verwijderen ###
 
-Om een bestand van Git te verwijderen, moet je het van de tracked bestanden verwijderen (om precies te zijn, verwijderen van je staging gebied) en dan een commit doen. Het `git rm` commando doet dat, en verwijdert het bestand ook van je werkmap zodat je het de volgende keer niet als een untracked bestand ziet.
+Om een bestand van Git te verwijderen, moet je het van de getrackte bestanden verwijderen (of om precies te zijn: verwijderen van je staging area) en dan een commit doen. Het `git rm` commando doet dat, en verwijdert het bestand ook van je werkdirectory zodat je het de volgende keer niet als een untrackt bestand ziet.
 
-Als je het bestand simpelweg verwijdert uit je werkmap, zal het te zien zijn onder het “Changes not staged for commit” (dat wil zeggen, _unstaged_) gedeelte van je `git status` output:
+Als je het bestand simpelweg verwijdert uit je werkdirectory, zal het te zien zijn onder het “Changes not staged for commit” (dat wil zeggen, _unstaged_) gedeelte van je `git status` output:
 
 	$ rm grit.gemspec
 	$ git status
-	# On branch master
-	#
-	# Changes not staged for commit:
-	#   (use "git add/rm <file>..." to update what will be committed)
-	#
-	#       deleted:    grit.gemspec
-	#
+	On branch master
+	Changes not staged for commit:
+	  (use "git add/rm <file>..." to update what will be committed)
+	  (use "git checkout -- <file>..." to discard changes in working directory)
+	
+	        deleted:    grit.gemspec
+	
+	no changes added to commit (use "git add" and/or "git commit -a")
 
 Als je daarna `git rm` uitvoert, zal de verwijdering van het bestand gestaged worden:
 
@@ -369,25 +393,25 @@ Als je daarna `git rm` uitvoert, zal de verwijdering van het bestand gestaged wo
 	#       deleted:    grit.gemspec
 	#
 
-Als je de volgende keer een commit doet, zal het bestand verdwenen zijn en niet meer getracked worden. Als je het bestand veranderd hebt en al aan de index toegevoegd hebt, dan zul je de verwijdering moeten forceren met de `-f` optie. Dit is een veiligheidsmaatregel om te voorkomen dat je per ongeluk data die nog niet in een snapshot zit, en dus niet teruggehaald kan worden uit Git, weggooit.
+Als je de volgende keer een commit doet, zal het bestand verdwenen zijn en niet meer getrackt worden. Als je het bestand veranderd hebt en al aan de index toegevoegd, dan zul je de verwijdering moeten forceren met de `-f` optie. Dit is een veiligheidsmaatregel om te voorkomen dat je per ongeluk data die nog niet in een snapshot zit, en dus niet teruggehaald kan worden uit Git, weggooit.
 
-Een ander handigheidje wat je misschien wilt doen is het bestand in je werkmap houden, maar van je staging gebied verwijderen. Met andere woorden, je wilt het bestand misschien op je harde schijf bewaren, maar niet dat Git het bestand nog tracked. Dit is erg handig als je iets vergeten bent aan je `.gitignore` bestand toe te voegen, en het per ongeluk toegevoegd hebt. Zoals een groot logbestand, of een serie `.a` gecompileerde bestanden. Gebruik de `--cached` optie om dit te doen:
+Een ander handigheidje wat je misschien wilt gebruiken is het bestand in je werkdirectory houden, maar van je staging area verwijderen. Met andere woorden, je wilt het bestand misschien op je harde schijf bewaren, maar niet dat Git het bestand nog trackt. Dit is erg handig als je iets vergeten bent aan je `.gitignore` bestand toe te voegen, en het per ongeluk toegevoegd hebt. Zoals een groot logbestand, of een serie `.a` gecompileerde bestanden. Gebruik de `--cached` optie om dit te doen:
 
 	$ git rm --cached readme.txt
 
-Je kunt bestanden, mappen en bestandspatronen aan het `git rm` commando meegeven. Dat betekent dat je zoiets als dit kunt doen
+Je kunt bestanden, directories en bestandspatronen aan het `git rm` commando meegeven. Dat betekent dat je zoiets als dit kunt doen
 
 	$ git rm log/\*.log
 
-Let op de backslash (`\`) voor de `*`. Dit is nodig omdat Git zijn eigen bestandsnaam expansie doet, naast die van je shell. In de Windows systeemconsole moet de backslash worden weggelaten. Dit commando verwijdert alle bestanden die de `.log` extensie hebben in de `log/` map. Of, je kunt zoiets als dit doen:
+Let op de backslash (`\`) voor de `*`. Dit is nodig omdat Git zijn eigen bestandsnaam expansie doet, naast die van je shell. In de Windows systeemconsole moet de backslash worden weggelaten. Dit commando verwijdert alle bestanden die de `.log` extensie hebben in de `log/` directory. Of, je kunt zoiets als dit doen:
 
 	$ git rm \*~
 
-Dit commando verwijderd alle bestanden die eindigen met `~`.
+Dit commando verwijdert alle bestanden die eindigen met `~`.
 
 ### Bestanden verplaatsen ###
 
-Anders dan vele andere VCS systemen, traceert Git niet expliciet verplaatsingen van bestanden. Als je een bestand een nieuwe naam geeft in Git, is er geen metadata opgeslagen in Git die vertelt dat je het bestand hernoemd hebt. Maar, Git is slim genoeg om dit alsnog te zien — we zullen bestandsverplaatsing detectie wat later behandelen.
+Anders dan vele andere VCS systemen, traceert Git niet expliciet verplaatsingen van bestanden. Als je een bestand een nieuwe naam geeft in Git, is er geen metadata opgeslagen in Git die vertelt dat je het bestand hernoemd hebt. Maar Git is slim genoeg om dit alsnog te zien, we zullen bestandsverplaatsing detectie wat later behandelen.
 
 Het is daarom een beetje verwarrend dat Git een `mv` commando heeft. Als je een bestand wilt hernoemen in Git, kun je zoiets als dit doen
 
@@ -397,26 +421,24 @@ en dat werkt prima. Sterker nog, als je zoiets als dit uitvoert en naar de statu
 
 	$ git mv README.txt README
 	$ git status
-	# On branch master
-	# Your branch is ahead of 'origin/master' by 1 commit.
-	#
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#       renamed:    README.txt -> README
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        renamed:    README.txt -> README
+	
 
-Maar, dat is gelijk aan het volgende uitvoeren:
+Maar dat is gelijk aan het uitvoeren van het volgende:
 
 	$ mv README.txt README
 	$ git rm README.txt
 	$ git add README
 
-Git komt er impliciet achter dat het om een hernoemd bestand gaat, dus het maakt niet uit of je een bestand op deze manier hernoemt of met het `mv` commando. Het enige echte verschil is dat het `mv` commando slechts één commando is in plaats van drie. En belangrijker nog is dat je iedere applicatie kunt gebruiken om een bestand te hernoemen, en de add/rm later kunt afhandelen, voordat je commit.
+Git komt er impliciet achter dat het om een hernoemd bestand gaat, dus het maakt niet uit of je een bestand op deze manier hernoemt of met het `mv` commando. Het enige echte verschil is dat het `mv` commando slechts één commando is in plaats van drie. En belangrijker nog is dat je iedere applicatie kunt gebruiken om een bestand te hernoemen, en de add/rm later kunt afhandelen voordat je commit.
 
 ## De commit geschiedenis bekijken ##
 
-Nadat je een aantal commits gecreëerd hebt, of als je een repository met een bestaande commit geschiedenis gekloond hebt, zul je waarschijnlijk terug willen zien wat er gebeurd is. Het meest basale en krachtige tool om dit te doen is het `git log` commando.
+Nadat je een aantal commits gemaakt hebt, of als je een repository met een bestaande commit geschiedenis gecloned hebt, zul je waarschijnlijk terug willen zien wat er gebeurd is. Het meest basale en krachtige tool om dit te doen is het `git log` commando.
 
 Deze voorbeelden maken gebruik van een eenvoudig project genaamd simplegit dat ik vaak voor demonstraties gebruikt. Om het project op te halen, voer dit uit
 
@@ -443,7 +465,7 @@ Als je `git log` in dit project uitvoert, zou je output moeten krijgen die er on
 
 	    first commit
 
-Zonder argumenten toont `git log` de commits die gedaan zijn in dat repository, in omgekeerde chronologische volgorde. Dat wil zeggen, de meest recente commits worden als eerste getoond. Zoals je kunt zien, toont dit commando iedere commit met zijn SHA-1 checksum, de naam van de auteur en zijn e-mail, de datum van opslaan, en de commit boodschap.
+Zonder argumenten toont `git log` de commits die gedaan zijn in die repository, in omgekeerde chronologische volgorde. Dat wil zeggen: de meest recente commits worden als eerste getoond. Zoals je kunt zien, toont dit commando iedere commit met zijn SHA-1 checksum, de naam van de auteur en zijn e-mail, de datum van opslaan, en de commit boodschap.
 
 Een gigantisch aantal en variëteit aan opties zijn beschikbaar voor het `git log` commando om je precies te laten zien waar je naar op zoek bent. Hier laten we je de meest gebruikte opties zien.
 
@@ -487,7 +509,28 @@ Een van de meest behulpzame opties is `-p`, wat de diff laat zien van de dingen
 	-end
 	\ No newline at end of file
 
-Deze optie toont dezelfde informatie, maar dan met een diff volgend op ieder item. Dit is erg handig voor een code review, of om snel te zien wat er tijdens een serie commits gebeurd is die een medewerker toegevoegd heeft.
+Deze optie toont dezelfde informatie, maar dan met een diff volgend op ieder item. Dit is erg handig voor een code review, of om snel te zien wat er tijdens een reeks commits gebeurd is die een medewerker toegevoegd heeft.
+
+Soms is het handiger om wijzigingen na te kijken op woordniveau in plaats van op regelniveau. Er is een `--word-diff` optie beschikbaar in Git, die je aan het `git log -p` commando kan toevoegen om een woord diff te krijgen inplaats van de reguliere regel voor regel diff. Woord diff formaat is nogal nutteloos als het wordt toegepast op broncode, maar is erg handig als het wordt toegepast op grote tekstbestanden, zoals boeken of een dissertatie. Hier is een voorbeeld.
+
+	$ git log -U1 --word-diff
+	commit ca82a6dff817ec66f44342007202690a93763949
+	Author: Scott Chacon <schacon@gee-mail.com>
+	Date:   Mon Mar 17 21:52:11 2008 -0700
+
+	    changed the version number
+
+	diff --git a/Rakefile b/Rakefile
+	index a874b73..8f94139 100644
+	--- a/Rakefile
+	+++ b/Rakefile
+	@@ -7,3 +7,3 @@ spec = Gem::Specification.new do |s|
+	    s.name      =   "simplegit"
+	    s.version   =   [-"0.1.0"-]{+"0.1.1"+}
+	    s.author    =   "Scott Chacon"
+
+Zoals je kunt zien zijn er geen toegevoegde of verwijderde regels in deze uitvoer zoals in een normale diff. Wijzigingen worden daarentegen binnen de regel getoond. Je kunt het toegevoegde woord zien binnen een `{+ +}` en verwijderde binnen een `[- -]`. Je kunt ook kiezen om de gebruikelijke 3 regels context in de diff uitvoer tot één regel te verminderen, omdat de context nu woorden is, en geen regels. Je kunt dit doen met `-U1` zoals hierboven in het voorbeeld.
+
 Je kunt ook een serie samenvattende opties met `git log` gebruiken. Bijvoorbeeld, als je wat verkorte statistieken bij iedere commit wilt zien, kun je de `--stat` optie gebruiken:
 
 	$ git log --stat
@@ -498,7 +541,7 @@ Je kunt ook een serie samenvattende opties met `git log` gebruiken. Bijvoorbeeld
 	    changed the version number
 
 	 Rakefile |    2 +-
-	 1 files changed, 1 insertions(+), 1 deletions(-)
+	 1 file changed, 1 insertion(+), 1 deletion(-)
 
 	commit 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7
 	Author: Scott Chacon <schacon@gee-mail.com>
@@ -507,7 +550,7 @@ Je kunt ook een serie samenvattende opties met `git log` gebruiken. Bijvoorbeeld
 	    removed unnecessary test code
 
 	 lib/simplegit.rb |    5 -----
-	 1 files changed, 0 insertions(+), 5 deletions(-)
+	 1 file changed, 5 deletions(-)
 
 	commit a11bef06a3f659402fe7563abf99ad00de2209e6
 	Author: Scott Chacon <schacon@gee-mail.com>
@@ -518,17 +561,17 @@ Je kunt ook een serie samenvattende opties met `git log` gebruiken. Bijvoorbeeld
 	 README           |    6 ++++++
 	 Rakefile         |   23 +++++++++++++++++++++++
 	 lib/simplegit.rb |   25 +++++++++++++++++++++++++
-	 3 files changed, 54 insertions(+), 0 deletions(-)
+	 3 files changed, 54 insertions(+)
 
 Zoals je ziet, drukt de `--stat` optie onder iedere commit een lijst gewijzigde bestanden af, hoeveel bestanden gewijzigd zijn, en hoeveel regels in die bestanden zijn toegevoegd en verwijderd. Het toont ook een samenvatting van de informatie aan het einde.
-Een andere handige optie is `--pretty`. Deze optie veranderd de log output naar een ander formaat dan de standaard. Er zijn al een paar voorgebouwde opties voor je beschikbaar. De `oneline` optie drukt iedere commit op een enkele regel af, wat handig is als je naar een hoop commits kijkt. Daarnaast tonen de `short`, `full` en `fuller` optie de output in grofweg hetzelfde formaat, maar met minder of meer informatie, respectievelijk:
+Een andere handige optie is `--pretty`. Deze optie verandert de log output naar een ander formaat dan de standaard. Er zijn al een paar voorgebouwde opties voor je beschikbaar. De `oneline` optie drukt iedere commit op een eigen regel af, wat handig is als je naar een hoop commits kijkt. Daarnaast tonen de `short`, `full` en `fuller` opties de output in grofweg hetzelfde formaat, maar met minder of meer informatie, respectievelijk:
 
 	$ git log --pretty=oneline
 	ca82a6dff817ec66f44342007202690a93763949 changed the version number
 	085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7 removed unnecessary test code
 	a11bef06a3f659402fe7563abf99ad00de2209e6 first commit
 
-De meest interessante optie is `format`, waarmee je je eigen log formaat kunt specificeren. Dit is in het bijzonder handig als je output aan het genereren bent voor automatische verwerking — omdat je expliciet het formaat kan specificeren, weet je dat het niet zal veranderen bij volgende versies van Git:
+De meest interessante optie is `format`, waarmee je je eigen log uitvoer formaat kunt specificeren. Dit is in het bijzonder handig als je output aan het genereren bent voor automatische verwerking; omdat je expliciet het formaat kan specificeren, weet je dat het niet zal veranderen bij volgende versies van Git:
 
 	$ git log --pretty=format:"%h - %an, %ar : %s"
 	ca82a6d - Scott Chacon, 11 months ago : changed the version number
@@ -536,6 +579,10 @@ De meest interessante optie is `format`, waarmee je je eigen log formaat kunt sp
 	a11bef0 - Scott Chacon, 11 months ago : first commit
 
 Tabel 2-1 toont een aantal handige opties die aan format gegeven kunnen worden.
+<!-- Attention to translators: this is a table declaration.
+The lines must be formatted as follows
+<TAB><First column text><TAB><Second column text>
+-->
 
 	Optie	Omschrijving van de Output
 	%H	Commit hash
@@ -554,7 +601,7 @@ Tabel 2-1 toont een aantal handige opties die aan format gegeven kunnen worden.
 	%cr	Committer datum, relatief
 	%s	Onderwerp
 
-Je zult je misschien afvragen wat het verschil is tussen _author_ en _committer_. De _auteur_ is de persoon die het werk oorspronkelijk geschreven heeft, en de _committer_ is de persoon die het werk als laatste toegevoegd heeft. Dus als je een patch naar een project stuurt en een van de kernleden voegt de patch toe, dan krijgen jullie beiden de eer — jij als de auteur en het kernlid als de committer. We gaan hier wat verder op in in *Hoofdstuk 5*.
+Je zult je misschien afvragen wat het verschil is tussen _author_ en _committer_. De _author_ is de persoon die de patch oorspronkelijk geschreven heeft, en de _committer_ is de persoon die de patch als laatste heeft toegepast. Dus als je een patch naar een project stuurt en een van de kernleden past de patch toe, dan krijgen jullie beiden de eer, jij als de auteur en het kernlid als de committer. We gaan hier wat verder op in in *Hoofdstuk 5*.
 
 De `oneline` en `format` opties zijn erg handig in combinatie met een andere `log` optie genaamd `--graph`. Deze optie maakt een mooie ASCII grafiek waarin je branch en merge geschiedenis getoond worden, die we kunnen zien in onze kopie van het Grit project repository:
 
@@ -570,11 +617,17 @@ De `oneline` en `format` opties zijn erg handig in combinatie met een andere `lo
 	* d6016bc require time for xmlschema
 	*  11d191e Merge branch 'defunkt' into local
 
-Dat zijn slechts een paar simpele output formaat opties voor `git log` — er zijn er nog veel meer. Tabel 2-2 toont de opties waarover we het tot nog toe gehad hebben, en wat veel voorkomende formaat opties die je misschien handig vindt, samen met hoe ze de output van het log commando veranderen.
+Dat zijn slechts een paar simpele output formaat opties voor `git log`; er zijn er nog veel meer. Tabel 2-2 toont de opties waarover we het tot nog toe gehad hebben, en wat veel voorkomende formaat opties die je misschien handig vindt, samen met hoe ze de output van het `log` commando veranderen.
+
+<!-- Attention to translators: this is a table declaration.
+The lines must be formatted as follows
+<TAB><First column text><TAB><Second column text>
+-->
 
 	Optie	Omschrijving
 	-p	Toon de patch geïntroduceerd bij iedere commit.
-	--stat	Toon statistieken voor gewijzigde bestanden in iedere commit.
+	--word-diff	Toon de patch in een woord diff formaat.
+	--stat	Toon statistieken voor gewijzigde bestanden per commit.
 	--shortstat	Toon alleen de gewijzigde/ingevoegde/verwijderde regel van het --stat commando.
 	--name-only	Toon de lijst van bestanden die gewijzigd zijn na de commit informatie.
 	--name-status	Toon ook de lijst van bestanden die beïnvloed zijn door de toegevoegde/gewijzigde/verwijderde informatie.
@@ -582,20 +635,21 @@ Dat zijn slechts een paar simpele output formaat opties voor `git log` — er zi
 	--relative-date	Toon de datum in een relatief formaat (bijvoorbeeld, "2 weken geleden"), in plaats van het volledige datum formaat.
 	--graph		Toon een ASCII grafiek van de branch en merge geschiedenis naast de log output.
 	--pretty	Toon commits in een alternatief formaat. De opties bevatten oneline, short, full, fuller, en format (waarbij je je eigen formaat specificeert).
+	--oneline	Een gemaks-optie, staat voor `--pretty=oneline --abbrev-commit`.
 
 ### Log output limiteren ###
 
-Naast het formatteren van de output, heeft `git log` nog een aantal bruikbare limiterende opties — dat wil zeggen, opties die je een subset van de commits tonen. Je hebt zo'n optie al gezien — de `-2` optie, die slechts de laatste twee commits laat zien. In feite kun je `-<n>` doen, waarbij `n` ieder heel getal is wat de laatste `n` commits laat zien. In feite zul je deze vorm weinig gebruiken, omdat Git standaard alle output door een pager (pagineer applicatie) stuurt zodat je slechts één pagina log output per keer ziet.
+Naast het formatteren van de output, heeft `git log` nog een aantal bruikbare limiterende opties; dat wil zeggen, opties die je een subset van de commits tonen. Je hebt zo'n optie al gezien: de `-2` optie, die slechts de laatste twee commits laat zien. Sterker nog: je kunt `-<n>` doen, waarbij `n` een heel getal is om de laatste `n` commits te laten zien. In feite zul je deze vorm weinig gebruiken, omdat Git standaard alle output door een pager (pagineer applicatie) stuurt zodat je de log-uitvoer pagina voor pagina ziet.
 
-Maar, de tijd limiterende opties zoals `--since` en `--until` zijn erg handig. Dit commando bijvoorbeeld, geeft een lijst met commits die gedaan zijn gedurende de laatste twee weken:
+Dat gezegd hebbende, zijn de tijd limiterende opties zoals `--since` en `--until` erg handig. Dit commando bijvoorbeeld, geeft een lijst met commits die gedaan zijn gedurende de laatste twee weken:
 
 	$ git log --since=2.weeks
 
-Dit commando werkt met veel formaten — je kunt een specifieke datum kiezen ("2008-01-15”) of een relatieve datum zoals "2 jaar 1 dag en 3 minuten geleden".
+Dit commando werkt met veel formaten: je kunt een specifieke datum kiezen ("2008-01-15”) of een relatieve datum zoals "2 jaar 1 dag en 3 minuten geleden".
 
 Je kunt ook de lijst met commits filteren op bepaalde criteria. De `--author` optie laat je filteren op een specifieke auteur, en de `--grep` optie laat je op bepaalde zoekwoorden filteren in de commit boodschappen. (Let op dat als je zowel auteur als grep opties wilt specificeren, je `--all-match` moet toevoegen of anders zal het commando ook commits met één van de twee criteria selecteren.)
 
-De laatste echt handige optie om aan `git log` als filter mee te geven is een pad. Als je een map of bestandsnaam opgeeft, kun je de log output limiteren tot commits die een verandering introduceren op die bestanden. Dit is altijd de laatste optie en wordt over het algemeen vooraf gegaan door dubbele streepjes (`--`) om de paden van de opties te scheiden.
+De laatste echt handige optie om aan `git log` als filter mee te geven is een pad. Als je een directory of bestandsnaam opgeeft, kun je de log output limiteren tot commits die een verandering introduceren op die bestanden. Dit is altijd de laatste optie en wordt over het algemeen vooraf gegaan door dubbele streepjes (`--`) om de paden van de opties te scheiden.
 
 In Tabel 2-3 laten we deze en een paar andere veel voorkomende opties zien als referentie.
 
@@ -621,16 +675,16 @@ Van de bijna 20.000 commits in de Git broncode historie, laat dit commando de 6
 
 ### Een grafische interface gebruiken om de historie te visualiseren ###
 
-Als je een meer grafische applicatie wilt gebruiken om je commit historie te visualiseren, wil je misschien een kijkje nemen naar het Tcl/Tk programma genaamd `gitk` dat met Git meegeleverd wordt. Gitk is eigenlijk een visuele `git log`, en het accepteert bijna alle filter opties die `git log` ook accepteert. Als je `gitk` in op de commandoregel in je project typt, zou je zoiets als in Figuur 2-2 moeten zien.
+Als je een meer grafische applicatie wilt gebruiken om je commit historie te visualiseren, wil je misschien een kijkje nemen naar het Tcl/Tk programma genaamd `gitk` dat met Git meegeleverd wordt. Gitk is eigenlijk een visuele `git log` tool, en het accepteert bijna alle filter opties die `git log` ook accepteert. Als je `gitk` in op de commandoregel in je project typt, zou je zoiets als in Figuur 2-2 moeten zien.
 
 Insert 18333fig0202.png
 Figuur 2-2. De gitk historie visualiseerder.
 
-Je kunt de commit historie in de bovenste helft van het scherm zien, samen met een afkomst graaf. De diff in de onderste helft van het scherm laat je de veranderingen zien die bij iedere commit die je aanklikt geïntroduceerd zijn.
+Je kunt de commit historie in de bovenste helft van het scherm zien, samen met een afkomst graaf. De diff in de onderste helft van het scherm laat je de veranderingen zien die geïntroduceerd zijn bij iedere commit die je aanklikt.
 
 ## Dingen ongedaan maken ##
 
-Op enig moment wil je misschien iets ongedaan maken. Hier zullen we een aantal basis toepassingen laten zien om veranderingen die je gemaakt hebt weer ongedaan te maken. Let op, je kunt niet altijd het ongedaan maken weer ongedaan maken. Dit is één van de weinige gedeeltes in Git waarbij je werk kwijt kunt raken als je het verkeerd doet.
+Op enig moment wil je misschien iets ongedaan maken. Hier zullen we een aantal basis tools laten zien om veranderingen die je gemaakt hebt weer ongedaan te maken. Maar pas op, je kunt niet altijd het ongedaan maken weer ongedaan maken. Dit is één van de weinige gedeeltes in Git waarbij je werk kwijt kunt raken als je het verkeerd doet.
 
 ### Je laatste commit veranderen ###
 
@@ -638,94 +692,95 @@ Een van de veel voorkomende acties die ongedaan gemaakt moeten worden vinden pla
 
 	$ git commit --amend
 
-Dit commando neemt je staging gebied en gebruikt dit voor de commit. Als je geen veranderingen sinds je laatste commit hebt gedaan (bijvoorbeeld, je voert dit commando meteen na je laatste commit uit), dan zal je snapshot er precies hetzelfde uitzien en zal je commit boodschap het enige zijn dat je verandert.
+Dit commando neemt je staging area en gebruikt dit voor de commit. Als je geen veranderingen sinds je laatste commit hebt gedaan (bijvoorbeeld, je voert dit commando meteen na je laatste commit uit), dan zal je snapshot er precies hetzelfde uitzien en zal je commit boodschap het enige zijn dat je verandert.
 
 Dezelfde commit-boodschap editor start op, maar deze bevat meteen de boodschap van je vorige commit. Je kunt de boodschap net als andere keren aanpassen, maar het overschrijft je vorige commit.
 
 Bijvoorbeeld, als je commit en je dan realiseert dat je vergeten bent de veranderingen in een bestand dat je wou toevoegen in deze commit te stagen, dan kun je zoiets als dit doen:
 
 	$ git commit -m 'initial commit'
-	$ git add forgotten_file
+	$ git add vergeten_bestand
 	$ git commit --amend
 
-Alledrie van deze commando's eindigen met één commit — de tweede commit vervangt de resultaten van de eerste.
+Na deze drie commando's eindig je met één commit; de tweede commit vervangt de resultaten van de eerste.
 
 ### Een staged bestand unstagen ###
 
-De volgende twee paragrafen laten zien hoe je je staging gebied en veranderingen in je werkmappen aanpakt. Het fijne gedeelte is dat het commando dat je gebruikt om de status van die gebieden te bepalen, je ook herinnert hoe je de veranderingen eraan ongedaan kunt maken. Bijvoorbeeld, stel dat je twee bestanden gewijzigd hebt en je wilt ze committen als twee aparte veranderingen, maar je typt per ongeluk `git add *` en staged ze allebei. Hoe kun je één van de twee nu unstagen? Het `git status` commando herinnert je eraan:
+De volgende twee paragrafen laten zien hoe je de staging area en veranderingen in je werkdirectories aanpakt. Het prettige hier is dat het commando dat je gebruikt om de status van die gebieden te bepalen, je er ook aan herinnert hoe je de veranderingen eraan weer ongedaan kunt maken. Bijvoorbeeld, stel dat je twee bestanden gewijzigd hebt en je wilt ze committen als twee aparte veranderingen, maar je typt per ongeluk `git add *` en staged ze allebei. Hoe kun je één van de twee nu unstagen? Het `git status` commando herinnert je eraan:
 
 	$ git add .
 	$ git status
-	# On branch master
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#       modified:   README.txt
-	#       modified:   benchmarks.rb
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        modified:   README.txt
+	        modified:   benchmarks.rb
+	
 
-Recht onder de "Changes to be committed" tekst, staat dat je `git reset HEAD <bestand>...` moet gebruiken om te unstagen. Laten we dat advies volgen om het `benchmarks.rb` bestand te unstagen:
+Direct onder de "Changes to be committed" tekst, staat dat je `git reset HEAD <file>...` moet gebruiken om te unstagen. Laten we dat advies volgen om het `benchmarks.rb` bestand te unstagen:
 
 	$ git reset HEAD benchmarks.rb
-	benchmarks.rb: locally modified
+	Unstaged changes after reset:
+	M       benchmarks.rb
 	$ git status
-	# On branch master
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#       modified:   README.txt
-	#
-	# Changes not staged for commit:
-	#   (use "git add <file>..." to update what will be committed)
-	#   (use "git checkout -- <file>..." to discard changes in working directory)
-	#
-	#       modified:   benchmarks.rb
-	#
-
-Het commando is een beetje vreemd, maar het werkt. Het benchmarks.rb bestand is gewijzigd maar weer ge-unstaged.
-
-### Een gewijzigd bestand ongedaan maken ###
-
-Wat als je je realiseert dat je je wijzigingen aan het `benchmarks.rb` bestand niet wilt behouden? Hoe kun je dit makkelijk ongedaan maken — terug brengen in de staat waarin het was toen je voor het laatst gecommit hebt (of initieel gekloond, of hoe je het ook in je werkmap gekregen hebt)? Gelukkig vertelt `git status` je ook hoe je dat moet doen. In de laatste voorbeeld output, ziet het unstaged gebied er zo uit:
-
-	# Changes not staged for commit:
-	#   (use "git add <file>..." to update what will be committed)
-	#   (use "git checkout -- <file>..." to discard changes in working directory)
-	#
-	#       modified:   benchmarks.rb
-	#
-
-Het vertelt je behoorlijk expliciet hoe je je veranderingen moet weggooien (tenminste, de nieuwere versies van Git, 1.6.1 of nieuwer, doen dit — als je een oudere versie hebt, raden we je ten zeerste aan om het te upgraden zodat je een aantal van deze fijne bruikbaarheidsopties krijgt). Laten we eens doen wat er staat:
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        modified:   README.txt
+	
+	Changes not staged for commit:
+	  (use "git add <file>..." to update what will be committed)
+	  (use "git checkout -- <file>..." to discard changes in working directory)
+	
+	        modified:   benchmarks.rb
+	
+
+Het commando is een beetje vreemd, maar het werkt. Het benchmarks.rb bestand is gewijzigd maar weer geunstaged.
+
+### Een gewijzigd bestand weer ongewijzigd maken ###
+
+Wat als je je realiseert dat je de wijzigingen aan het `benchmarks.rb` bestand niet wilt behouden? Hoe kun je dit makkelijk ongedaan maken; terug brengen in de staat waarin het was toen je voor het laatst gecommit hebt (of initieel gecloned, of hoe je het ook in je werkdirectory gekregen hebt)? Gelukkig vertelt `git status` je ook hoe je dat moet doen. In de laatste voorbeeld output, ziet het unstaged gebied er zo uit:
+
+	Changes not staged for commit:
+	  (use "git add <file>..." to update what will be committed)
+	  (use "git checkout -- <file>..." to discard changes in working directory)
+	
+	        modified:   benchmarks.rb
+	
+
+Het vertelt je behoorlijk expliciet hoe je je veranderingen moet weggooien (tenminste, de nieuwere versies van Git, 1.6.1 of nieuwer, doen dit. Als je een oudere versie hebt, raden we je ten zeerste aan om het te upgraden zodat je een aantal van deze fijne bruikbaarheidsopties krijgt). Laten we eens doen wat er staat:
 
 	$ git checkout -- benchmarks.rb
 	$ git status
-	# On branch master
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#       modified:   README.txt
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        modified:   README.txt
+	
 
-Je kunt zien dat de veranderingen teruggedraaid zijn. Je moet je ook realiseren dat dit een gevaarlijk commando is: alle veranderingen die je aan dat bestand gedaan hebt zijn weg — je hebt er zojuist een ander bestand overheen gezet. Gebruik dit commando dan ook nooit, tenzij je heel zeker weet dat je het bestand niet wilt. Als je het alleen maar uit de weg wilt hebben, gebruik dan branching of stashing wat we behandelen in het volgende hoofdstuk; dit zijn vaak de betere opties.
+Je kunt zien dat de veranderingen teruggedraaid zijn. Je moet je ook beseffen dat dit een gevaarlijk commando is: alle veranderingen die je aan dat bestand gedaan hebt zijn weg; je hebt er zojuist een ander bestand overheen gezet. Gebruik dit commando dan ook nooit, tenzij je heel zeker weet dat je het bestand niet wilt. Als je het alleen maar uit de weg wilt hebben, gebruik dan branching of stashing wat we behandelen in het volgende hoofdstuk; dit zijn vaak de betere opties.
 
 Onthoud, alles dat in Git gecommit is kan bijna altijd weer hersteld worden. Zelfs commits die op reeds verwijderde branches gedaan zijn, of commits die zijn overschreven door een `--amend` commit, kunnen weer hersteld worden (zie *Hoofdstuk 9* voor data herstel). Maar, alles wat je verliest dat nog nooit was gecommit is waarschijnlijk voor altijd verloren.
 
 ## Werken met remotes ##
 
-Om samen te kunnen werken op ieder Git project, moet je weten hoe je je remote repositories moet beheren. Remote repositories zijn versies van je project, die worden beheerd op het Internet of ergens op een netwerk. Je kunt er meerdere hebben, waarvan ieder ofwel alleen leesbaar, of lees- en schrijfbaar is voor jou. Samenwerken met anderen houdt in dat je deze remote repositories kunt beheren en data kunt pushen en pullen op het moment dat je werk moet delen.
-Remote repositories beheren houdt ook in hoe je ze moet toevoegen, ongeldige repositories moet verwijderen, meerdere remote branches moet beheren en ze als tracked of niet kunt definiëren, en meer. In deze sectie zullen we deze remote-beheer vaardigheden behandelen.
+Om samen te kunnen werken op eender welke Git project, moet je weten hoe je de remote repositories moet beheren. Remote repositories zijn versies van je project, die worden beheerd op het Internet of ergens op een netwerk. Je kunt er meerdere hebben, waarvan over het algemeen ieder ofwel alleen leesbaar, of lees- en schrijfbaar is voor jou. Samenwerken met anderen houdt in dat je deze remote repositories kunt beheren en data kunt pushen en pullen op het moment dat je werk moet delen.
+Remote repositories beheren houdt ook in weten hoe je ze moet toevoegen, ongeldige repositories moet verwijderen, meerdere remote branches moet beheren en ze als tracked of niet kunt definiëren, en meer. In deze sectie zullen we deze remote-beheer vaardigheden behandelen.
 
 ### Laat je remotes zien ###
 
-Om te zien welke remote servers je geconfigureerd hebt, kun je het `git remote` commando uitvoeren. Het laat de verkorte namen van iedere remote alias zien die je gespecificeerd hebt. Als je je repository gekloond hebt, dan zul je op z'n minst de *origin* zien — dat is de standaard naam die Git aan de server geeft waarvan je gekloond hebt:
+Om te zien welke remote servers je geconfigureerd hebt, kun je het `git remote` commando uitvoeren. Het laat de verkorte namen van iedere remote alias zien die je gespecificeerd hebt. Als je de repository gecloned hebt, dan zul je op z'n minst de *origin* zien; dat is de standaard naam die Git aan de server geeft waarvan je gecloned hebt:
 
 	$ git clone git://github.com/schacon/ticgit.git
-	Initialized empty Git repository in /private/tmp/ticgit/.git/
-	remote: Counting objects: 595, done.
-	remote: Compressing objects: 100% (269/269), done.
-	remote: Total 595 (delta 255), reused 589 (delta 253)
-	Receiving objects: 100% (595/595), 73.31 KiB | 1 KiB/s, done.
-	Resolving deltas: 100% (255/255), done.
+	Cloning into 'ticgit'...
+	remote: Reusing existing pack: 1857, done.
+	remote: Total 1857 (delta 0), reused 0 (delta 0)
+	Receiving objects: 100% (1857/1857), 374.35 KiB | 193.00 KiB/s, done.
+	Resolving deltas: 100% (772/772), done.
+	Checking connectivity... done.
 	$ cd ticgit
 	$ git remote
 	origin
@@ -733,7 +788,8 @@ Om te zien welke remote servers je geconfigureerd hebt, kun je het `git remote`
 Je kunt ook `-v` specificeren, wat je de URL laat zien die Git bij de verkorte naam heeft opgeslagen om naar geëxpandeerd te worden:
 
 	$ git remote -v
-	origin	git://github.com/schacon/ticgit.git
+	origin  git://github.com/schacon/ticgit.git (fetch)
+	origin  git://github.com/schacon/ticgit.git (push)
 
 Als je meer dan één remote hebt, dan laat het commando ze allemaal zien. Bijvoorbeeld, mijn Grit repository ziet er ongeveer zo uit.
 
@@ -745,11 +801,11 @@ Als je meer dan één remote hebt, dan laat het commando ze allemaal zien. Bijvo
 	koke      git://github.com/koke/grit.git
 	origin    git@github.com:mojombo/grit.git
 
-Dit betekent dat we vrij gemakkelijk de bijdragen van ieder van deze gebruikers naar binnen kunnen pullen. Let op dat alleen de origin een SSH URL is, dus dat is de enige waar ik naartoe kan pushen (we laten het waarom zien in *Hoofdstuk 4*).
+Dit betekent dat we vrij gemakkelijk de bijdragen van ieder van deze gebruikers naar binnen kunnen pullen. Maar merk ook op dat alleen de origin een SSH URL is, dus dat is de enige waar ik naartoe kan pushen (we laten in *Hoofdstuk 4* zien waarom dat zo is).
 
 ### Remote repositories toevoegen ###
 
-Ik heb het toevoegen van remote repositories al genoemd en getoond in vorige secties, maar hier toon ik het expliciet. Om een nieuw Git remote repository als een makkelijk te refereren alias toe te voegen, voer `git remote add [verkorte naam] [url]` uit:
+Ik heb het toevoegen van remote repositories al genoemd en getoond in vorige paragrafen, maar hier toon ik expliciet hoe dat gedaan wordt. Om een nieuw Git remote repository als een makkelijk te refereren alias toe te voegen, voer je `git remote add [verkorte naam] [url]` uit:
 
 	$ git remote
 	origin
@@ -758,7 +814,7 @@ Ik heb het toevoegen van remote repositories al genoemd en getoond in vorige sec
 	origin	git://github.com/schacon/ticgit.git
 	pb	git://github.com/paulboone/ticgit.git
 
-Nu kun je de naam pb in de shell gebruiken in plaats van de hele URL. Bijvoorbeeld, als je alle informatie die Paul wel, maar jij niet in je repository wilt fetchen, dan kun je git fetch pb uitvoeren:
+Nu kun je de naam pb op de commandoregel gebruiken in plaats van de hele URL. Bijvoorbeeld, als je alle informatie die Paul wel, maar jij niet in je repository wilt fetchen, dan kun je git fetch pb uitvoeren:
 
 	$ git fetch pb
 	remote: Counting objects: 58, done.
@@ -769,7 +825,7 @@ Nu kun je de naam pb in de shell gebruiken in plaats van de hele URL. Bijvoorbee
 	 * [new branch]      master     -> pb/master
 	 * [new branch]      ticgit     -> pb/ticgit
 
-Paul zijn master branch is lokaal toegankelijk als `pb/master` — je kunt het in een van jouw branches mergen, of je kunt een lokale branch uitchecken op dat punt als je het wil zien.
+Paul zijn master branch is lokaal toegankelijk als `pb/master`; je kunt het in een van jouw branches mergen, of je kunt een lokale branch uitchecken op dat punt als je het wil zien.
 
 ### Van je remotes fetchen en pullen ###
 
@@ -777,19 +833,19 @@ Zoals je zojuist gezien hebt, kun je om data van je remote projecten te halen di
 
 	$ git fetch [remote-name]
 
-Het commando gaat naar het remote project en haalt alle data van dat remote project dat jij nog niet hebt. Nadat je dit gedaan hebt, zou je references (referenties) naar alle branches van dat remote moeten hebben, die je op ieder tijdstip kunt mergen en bekijken. (We zullen zien wat branches precies zijn, en hoe je ze moet gebruiken in meer detail in *Hoofdstuk 3*.)
+Het commando gaat naar het remote project en haalt alle data van dat remote project dat jij nog niet hebt. Nadat je dit gedaan hebt, zou je references (referenties) naar alle branches van dat remote moeten hebben, die je op ieder tijdstip kunt mergen en bekijken. (We zullen in meer detail zien wat branches precies zijn, en hoe je ze moet gebruiken in *Hoofdstuk 3*.)
 
-Als je een repository kloont, voegt dat commando dat remote repository automatisch toe onder de naam *origin*. Dus `git fetch origin` fetched (haalt) ieder nieuw werk dat gepusht is naar die server sinds je gekloond hebt (of voor het laatst ge-fetched hebt). Het is belangrijk om te weten dat het fetch commando de data naar je locale repository haalt — het merged niet automatisch met je werk of verandert waar je momenteel aan zit te werken. Je kunt het handmatig in je werk mergen als je er klaar voor bent.
+Als je een repository cloned, voegt dat commando die remote repository automatisch toe onder de naam *origin*. Dus `git fetch origin` fetcht (haalt) ieder nieuw werk dat gepusht is naar die server sinds je gecloned hebt (of voor het laatst gefetcht hebt). Het is belangrijk om te weten dat het fetch commando de data naar je locale repository haalt; het merged niet automatisch met je werk of verandert waar je momenteel aan zit te werken. Je moet het handmatig in je werk mergen wanneer je er klaar voor bent.
 
-Als je een branch geconfigureerd hebt om een remote branch te tracken (volgen) (zie de volgende sectie en *Hoofdstuk 3* voor meer informatie), dan kun je het `git pull` commando gebruiken om automatisch een remote branch te fetchen en mergen in je huidige branch. Dit kan makkelijker of meer comfortabel zijn voor je werkwijze; en standaard stelt het `git clone` commando je lokale master branch zo in dat het de remote master branch van de server waarvan je gekloond hebt volgt (aangenomen dat de remote een master branch heeft). Over het algemeen zal een `git pull` dat van de server waarvan je origineel gekloond hebt halen en proberen het automatisch in de code waar je op dat moment aan zit te werken te mergen.
+Als je een branch geconfigureerd hebt om een remote branch te volgen (tracken) (zie de volgende paragraaf en *Hoofdstuk 3* voor meer informatie), dan kun je het `git pull` commando gebruiken om automatisch een remote branch te fetchen en mergen in je huidige branch. Dit kan makkelijker of meer comfortabele workflow zijn voor je; en standaard stelt het `git clone` commando je lokale master branch zo in dat het de remote master branch van de server waarvan je gecloned hebt volgt (aangenomen dat de remote een master branch heeft). Over het algemeen zal een `git pull` dat van de server waarvan je origineel gecloned hebt halen en proberen het automatisch in de code waar je op dat moment aan zit te werken te mergen.
 
-### Je remotes pushen ###
+### Naar je remotes pushen ###
 
-Wanneer je je project op een punt krijgt dat je het wilt delen, dan moet je het stroomopwaarts pushen. Het commando hiervoor is simpel: `git push [remote-name] [branch-name]`. Als je je master branch naar je `origin` server wilt pushen (nogmaals, over het algemeen zet klonen beide namen automatisch goed voor je), dan kun je dit uitvoeren om je werk terug op de server te pushen:
+Wanneer je jouw project op een punt hebt dat je het wilt delen, dan moet je het stroomopwaarts pushen. Het commando hiervoor is simpel: `git push [remote-name] [branch-name]`. Als je de master branch naar je `origin` server wilt pushen (nogmaals, over het algemeen zet clonen beide namen automatisch goed voor je), dan kun je dit uitvoeren om je werk terug op de server te pushen:
 
 	$ git push origin master
 
-Dit commando werkt alleen als je gekloond hebt van een server waarop je schrijfrechten hebt, en als niemand in de tussentijd gepusht heeft. Als jij en iemand anders op hetzelfde tijdstip gekloond hebben en zij pushen stroomopwaarts en dan jij, dan zal je push terecht geweigerd worden. Je zult eerst hun werk moeten pullen en in jouw werk verwerken voordat je toegestaan wordt te pushen. Zie *Hoofdstuk 3* voor meer gedetailleerde informatie over hoe je naar remote servers moet pushen.
+Dit commando werkt alleen als je gecloned hebt van een server waarop je schrijfrechten hebt, en als niemand in de tussentijd gepusht heeft. Als jij en iemand anders op hetzelfde tijdstip gecloned hebben en zij pushen eerder stroomopwaarts dan jij, dan zal je push terecht geweigerd worden. Je zult eerst hun werk moeten pullen en in jouw werk verwerken voordat je toegestaan wordt te pushen. Zie *Hoofdstuk 3* voor meer gedetailleerde informatie over hoe je naar remote servers moet pushen.
 
 ### Een remote inspecteren ###
 
@@ -804,9 +860,9 @@ Als je meer informatie over een bepaalde remote wilt zien, kun je het `git remot
 	    master
 	    ticgit
 
-Het toont de URL voor de remote repository, samen met de tracking branch informatie. Het commando vertelt je behulpzaam dat als je op de master branch zit, en je voert `git pull` uit, dan zal het automatisch de master branch op de remote mergen nadat het alle remote references opgehaald heeft. Het toont ook alle remote referenties die het gepulled heeft.
+Het toont de URL voor de remote repository samen met de tracking branch informatie. Het commando vertelt je behulpzaam dat als je op de master branch zit en je voert `git pull` uit, dat Git dan automatisch de master branch van de remote zal mergen nadat het alle remote references opgehaald heeft. Het toont ook alle remote referenties die het gepulled heeft.
 
-Dat is een eenvoudig voorbeeld dat je vaak tegenkomt. Als je Git meer intensief gebruikt, zul je veel meer informatie van `git remote show` krijgen:
+Dat is een eenvoudig voorbeeld dat je vaak zult tegenkomen. Als je Git echter intensiever gebruikt, zul je veel meer informatie van `git remote show` krijgen:
 
 	$ git remote show origin
 	* remote origin
@@ -841,19 +897,19 @@ Als je een referentie wilt hernoemen, dan kun je in nieuwere versie van Git `git
 	origin
 	paul
 
-Het is de moeite om te melden dat dit ook je remote branch naam verandert. Wat voorheen gerefereerd werd als `pb/master` is nu `paul/master`.
+Het is de moeite waard om te melden dat dit ook je remote branch naam verandert. Wat voorheen gerefereerd werd als `pb/master` is nu `paul/master`.
 
-Als je om een of andere reden een referentie wilt verwijderen — je hebt de server verplaatst of je gebruikt een bepaalde spiegel niet meer, of een medewerker doet niet meer mee — dan kun je `git remote rm` gebruiken:
+Als je om een of andere reden een referentie wilt verwijderen, je hebt de server verplaatst of je gebruikt een bepaalde mirror niet meer, of een medewerker doet niet meer mee, dan kun je `git remote rm` gebruiken:
 
 	$ git remote rm paul
 	$ git remote
 	origin
 
-## Labelen ##
+## Labelen (Taggen) ##
 
-Zoals de meeste VCS'en, heeft git de mogelijkheid om specifieke punten in de history als belangrijk te taggen (labelen). Over het algemeen gebruiken mensen deze functionaliteit om versie punten te markeren (v1.0, en verder). In deze sectie zul je leren hoe de beschikbare tags te tonen, hoe nieuwe tags te creëren, en wat de verschillende typen tags zijn.
+Zoals de meeste VCS'en, heeft git de mogelijkheid om specifieke punten in de history als belangrijk te labelen (taggen). Over het algemeen gebruiken mensen deze functionaliteit om versie punten te markeren (`v1.0`, en zo). In deze paragraaf zul je leren hoe de beschikbare tags te tonen, hoe nieuwe tags te creëren, en wat de verschillende typen tags zijn.
 
-### Je tags laten zien ###
+### Jouw tags laten zien ###
 
 De beschikbare tags in Git laten zien is rechttoe rechtaan. Type gewoon `git tag`:
 
@@ -861,7 +917,7 @@ De beschikbare tags in Git laten zien is rechttoe rechtaan. Type gewoon `git tag
 	v0.1
 	v1.3
 
-Dit commando toont de tags in alfabetische volgorde; de volgorde waarin ze verschijnen heeft geen echt belang.
+Dit commando toont de tags in alfabetische volgorde; de volgorde waarin ze verschijnen heeft geen echte betekenis.
 
 Je kunt ook zoeken op tags met een bepaald patroon. De Git bron repository, bijvoorbeeld, bevat meer dan 240 tags. Als je alleen geïnteresseerd bent om naar de 1.4.2 serie te kijken, kun je dit uitvoeren:
 
@@ -873,11 +929,11 @@ Je kunt ook zoeken op tags met een bepaald patroon. De Git bron repository, bijv
 
 ### Tags creëren ###
 
-Git gebruikt twee soorten tags: lightweight (lichtgewicht) en annotated (beschreven). Een lichtgewicht tag komt overeen met een branch die niet verandert — het is slechts een wijzer naar een specifieke commit. Beschreven tags daarentegen, zijn als volwaardige objecten in de Git database opgeslagen. Ze worden gechecksummed, bevatten de naam van de tagger, e-mail en datum, hebben een tag boodschap, en kunnen gesigneerd en geverifieerd worden met GNU Privacy Guard (GPG). Het wordt over het algemeen aangeraden om beschreven tags te maken zodat je deze informatie hebt; maar als je een tijdelijke tag wilt of om een of andere reden de andere informatie niet wilt houden, dan zijn er ook lichtgewicht tags.
+Git gebruikt twee soorten tags: lichtgewicht (lightweight) en beschreven (annotated). Een lightweight tag komt overeen met een branch die niet verandert: het is slechts een wijzer naar een specifieke commit. Annotated tags daarentegen, zijn als volwaardige objecten in de Git database opgeslagen. Ze worden gechecksummed, bevatten de naam van de tagger, e-mail en datum, hebben een tag boodschap, en kunnen gesigneerd en geverifieerd worden met GNU Privacy Guard (GPG). Het wordt over het algemeen aangeraden om annotated tags te maken zodat je deze informatie hebt; maar als je een tijdelijke tag wilt of om een of andere reden de andere informatie niet wilt houden, dan zijn er ook lichtgewicht tags.
 
-### Beschreven tags ###
+### Annotated tags ###
 
-Een beschreven tag in Git maken is eenvoudig. Het makkelijkst is om de `-a` optie te specificeren als je het `tag` commando uitvoert:
+Een annotated tag in Git maken is eenvoudig. Het makkelijkst is om de `-a` optie te specificeren als je het `tag` commando uitvoert:
 
 	$ git tag -a v1.4 -m 'my version 1.4'
 	$ git tag
@@ -937,9 +993,9 @@ Als je `git show` op die tag uitvoert, dan kun je jouw GPG handtekening eraan va
 
 Verderop zul je leren hoe je ondertekende tags kunt verifiëren.
 
-### Lichtgewicht tags ###
+### Lightweight tags ###
 
-Een andere manier om een tag te committen is met behulp van een lichtgewicht tag. Dit is in principe de commit checksum in een bestand opgeslagen — er wordt geen andere informatie bijgehouden. Om een lichtgewicht tag te maken voeg je niet de `-a`, `-s` of de `-m` optie toe:
+Een andere manier om een tag te committen is met behulp van een lightweight tag. Dit is in principe de commit checksum in een bestand opgeslagen; er wordt geen andere informatie bijgehouden. Om een lightweight tag te maken voeg je niet de `-a`, `-s` noch de `-m` optie toe:
 
 	$ git tag v1.4-lw
 	$ git tag
@@ -985,7 +1041,7 @@ Als je de publieke sleutel van degene die getekend heeft niet hebt, dan krijg je
 
 ### Later taggen ###
 
-Je kunt ook commits taggen nadat je verder gegaan bent. Stel dat je commit historie er zo uitziet:
+Je kunt ook commits taggen waar je al voorbij bent. Stel dat je commit historie er zo uitziet:
 
 	$ git log --pretty=oneline
 	15027957951b64cf874c3557a0f3547bd83b3ff6 Merge branch 'experiment'
@@ -999,7 +1055,7 @@ Je kunt ook commits taggen nadat je verder gegaan bent. Stel dat je commit histo
 	964f16d36dfccde844893cac5b347e7b3d44abbc commit the todo
 	8a5cbc430f1a9c3d00faaeffd07798508422908a updated readme
 
-Nu, stel dat je vergeten bent het project op v1.2 te taggen, daar waar de "updated rakefile" commit was. Je kunt dit nadien toevoegen. Om die commit te taggen, specificeer je de commit boodschap (of een gedeelte daarvan) aan het einde van het commando:
+Stel nu dat je vergeten bent het project op v1.2 te taggen, daar waar de "updated rakefile" commit was. Je kunt dit nadien toevoegen. Om die commit te taggen, specificeer je de commit boodschap (of een gedeelte daarvan) aan het einde van het commando:
 
 	$ git tag -a v1.2 9fceb02
 
@@ -1038,7 +1094,7 @@ Standaard zal het `git push` commando geen tags naar remote servers versturen. J
 	To git@github.com:schacon/simplegit.git
 	* [new tag]         v1.5 -> v1.5
 
-Als je veel tags hebt die je ineens wilt pushen, kun je ook de `--tags` optie aan het `git push` commando toevoegen. Dit zal al je tags, die nog niet op de remote server zijn, in een keer er naartoe sturen.
+Als je veel tags hebt die je ineens wilt pushen, kun je ook de `--tags` optie aan het `git push` commando toevoegen. Dit zal al je tags, die nog niet op de remote server zijn, in één keer er naartoe sturen.
 
 	$ git push origin --tags
 	Counting objects: 50, done.
@@ -1052,7 +1108,7 @@ Als je veel tags hebt die je ineens wilt pushen, kun je ook de `--tags` optie aa
 	 * [new tag]         v1.4-lw -> v1.4-lw
 	 * [new tag]         v1.5 -> v1.5
 
-Als nu iemand anders van jouw repository kloont of pulled, dan zullen zij al jouw tags ook krijgen.
+Als nu iemand anders van jouw repository cloned of pulled, dan zullen zij al jouw tags ook krijgen.
 
 ## Tips en trucs ##
 
@@ -1060,22 +1116,22 @@ Voordat we dit hoofdstuk over de basis van Git afsluiten laten we je nog wat kle
 
 ### Auto-aanvulling ###
 
-Als je de Bash shell gebruikt, heeft Git een fijn auto-aanvulling script dat je aan kunt zetten. Download de Git broncode, en kijk in de `contrib/completion` map; daar zou een bestand genaamd `git-completion.bash` moeten staan. Kopieer dit bestand naar je home map, en voeg dit aan je `.bashrc` bestand toe:
+Als je de Bash shell gebruikt, heeft Git een prettige auto-aanvulling script dat je aan kunt zetten. Download het direct van de Git broncode op https://github.com/git/git/blob/master/contrib/completion/git-completion.bash. Kopieer dit bestand naar je home directory, en voeg dit aan je `.bashrc` bestand toe:
 
 	source ~/.git-completion.bash
 
-Als je Git wilt instellen dat het automatische Bash shell aanvulling heeft voor alle gebruikers, kopieer dit script dan naar de `/opt/local/etc/bash_completion.d` map op Mac systemen, of naar de `/etc/bash_completion.d/` map op Linux systemen. Dit is een map met scripts dat Bash automatisch zal laden om shell aanvullingen aan te bieden.
+Als je Git wilt instellen dat het automatische Bash shell aanvulling heeft voor alle gebruikers, kopieer dit script dan naar de `/opt/local/etc/bash_completion.d` directory op Mac systemen, of naar de `/etc/bash_completion.d/` directory op Linux systemen. Dit is een directory met scripts dat Bash automatisch zal laden om shell aanvullingen aan te bieden.
 
 Als je Windows gebruikt met Git Bash, wat de standaard is als je Git op Windows installeert met msysGit, dan zou auto-aanvulling voorgeconfigureerd moeten zijn.
 
-Druk de Tab toets als je een Git commando aan het typen bent, en het zou een set suggesties voor je moeten teruggeven:
+Druk de Tab toets als je een Git commando aan het typen bent, en het zou een lijstje suggesties voor je moeten teruggeven:
 
 	$ git co<tab><tab>
 	commit config
 
-In dit geval zal git co en dan de Tab toets twee keer indrukken git commit en config voorstellen. `m<tab>` toevoegen, vult `git commit` automatisch aan.
+In dit geval zal git co en dan de Tab toets twee keer indrukken git commit en config voorstellen. Als je daarna `m<tab>` toevoegt, wordt het automatisch tot `git commit` gecompleteerd.
 
-Dit werkt ook met opties, wat waarschijnlijk meer bruikbaar is. Bijvoorbeeld, als je een `git log` commando uitvoert en je niet meer kunt herinneren wat een van de opties is, dan kun je beginnen met het te typen en Tab indrukken om te zien wat er past:
+Dit werkt ook met opties, wat nog bruikbaarder is. Bijvoorbeeld, als je een `git log` commando uitvoert en je een van de opties niet meer kunt herinneren, dan kun je beginnen met het te typen en Tab indrukken om te zien wat er past:
 
 	$ git log --s<tab>
 	--shortstat  --since=  --src-prefix=  --stat   --summary
@@ -1084,16 +1140,16 @@ Dat is een erg handig trucje en zal je misschien wat tijd en documentatie lezen
 
 ### Git aliassen ###
 
-Git zal geen commando's raden als je het gedeeltelijk intypt. Als je niet de hele tekst van ieder Git commando wilt intypen, kun je gemakkelijk een alias voor ieder commando configureren door `git config` te gebruiken. Hier zijn een aantal voorbeelden die je misschien wilt instellen:
+Git zal geen commando's afleiden uit wat gedeeltelijk intypt. Als je niet de hele tekst van ieder Git commando wilt intypen, kun je gemakkelijk een alias voor ieder commando configureren door `git config` te gebruiken. Hier zijn een aantal voorbeelden die je misschien wilt instellen:
 
 	$ git config --global alias.co checkout
 	$ git config --global alias.br branch
 	$ git config --global alias.ci commit
 	$ git config --global alias.st status
 
-Dit betekent dat je, bijvoorbeeld, in plaats van `git commit` je alleen `git ci` hoeft in te typen. Als je verder gaat met Git, zul je waarschijnlijk andere commando's ook vaker gaan gebruiken; in dat geval, schroom je niet om nieuwe aliassen te maken.
+Dit betekent dat je, bijvoorbeeld, in plaats van `git commit` je alleen `git ci` hoeft in te typen. Als je verder gaat met Git, zul je waarschijnlijk andere commando's ook vaker gaan gebruiken; in dat geval: schroom niet om nieuwe aliassen te maken.
 
-Deze techniek kan ook makkelijk zijn om commando's te maken waarvan je vindt dat ze moeten bestaan. Bijvoorbeeld, om het bruikbaarheidsprobleem wat je met het unstagen van een bestand hebt op te lossen, kun je je eigen unstage alias aan Git toevoegen:
+Deze techniek kan ook makkelijk zijn om commando's te maken waarvan je vindt dat ze zouden moeten bestaan. Bijvoorbeeld, om het bruikbaarheidsprobleem wat je met het unstagen van een bestand tegenkwam op te lossen, kun je jouw eigen unstage alias aan Git toevoegen:
 
 	$ git config --global alias.unstage 'reset HEAD --'
 
@@ -1102,7 +1158,7 @@ Dit maakt de volgende twee commando's equivalent:
 	$ git unstage fileA
 	$ git reset HEAD fileA
 
-Het lijkt wat helderder. Het is ook gebruikelijk om een `last` commando toe te voegen:
+Het lijkt wat duidelijker. Het is ook gebruikelijk om een `last` commando toe te voegen:
 
 	$ git config --global alias.last 'log -1 HEAD'
 
@@ -1117,10 +1173,10 @@ Op deze manier kun je de laatste commit makkelijk zien:
 
 	    Signed-off-by: Scott Chacon <schacon@example.com>
 
-Zoals je kunt zien, vervangt Git eenvoudigweg het nieuwe commando met waarvoor je het gealiassed hebt. Maar, misschien wil je een extern commando uitvoeren, in plaats van een Git subcommando. In dat geval begin je het commando met een `!` karakter. Dit is handig als je je eigen applicaties maakt die met een Git repository werken. We kunnen dit demonstreren door `git visual` een `gitk` te laten uitvoeren:
+Zoals je kunt zien, vervangt Git eenvoudigweg het nieuwe commando met hetgeen waarvoor je het gealiassed hebt. Maar, misschien wil je een extern commando uitvoeren, in plaats van een Git subcommando. In dat geval begin je het commando met een `!` karakter. Dit is handig als je je eigen applicaties maakt die met een Git repository werken. We kunnen dit demonstreren door `git visual` een `gitk` te laten uitvoeren:
 
 	$ git config --global alias.visual '!gitk'
 
 ## Samenvatting ##
 
-Op dit punt kun je alle basis locale Git operaties doen – een repository creëren of klonen, wijzigingen maken, de wijzigingen stagen en committen, en de historie bekijken van alle veranderingen die de repository ondergaan heeft. Als volgende gaan we Gits beste optie bekijken: het branching model.
+Op dit punt kun je alle basis locale Git operaties doen: een repository creëren of clonen, wijzigingen maken, de wijzigingen stagen en committen en de historie bekijken van alle veranderingen die de repository ondergaan heeft. Als volgende gaan we de beste eigenschap van Git bekijken: het branching model.

From b8ab397df0c319b07ddb104ee6d92ee33729bcfc Mon Sep 17 00:00:00 2001
From: cor <git@cpt1.demon.nl>
Date: Sat, 15 Feb 2014 11:57:58 +0100
Subject: [PATCH 221/690] [nl] Chapter 02. More commands straightened

     On second viewing there were more commands to be corrected.
---
 nl/02-git-basics/01-chapter2.markdown | 85 ++++++++++++++-------------
 1 file changed, 45 insertions(+), 40 deletions(-)

diff --git a/nl/02-git-basics/01-chapter2.markdown b/nl/02-git-basics/01-chapter2.markdown
index 48f865390..2e9bb5c5a 100644
--- a/nl/02-git-basics/01-chapter2.markdown
+++ b/nl/02-git-basics/01-chapter2.markdown
@@ -2,7 +2,7 @@
 
 Ik zou het volgende willen voorstellen:
 Er zijn bepaalde termen die voor de gemiddelde Nederlandse computer gebruiker veel beter klinken (of bekender voorkomen) als de orginele Engelse term. In het begin zullen deze termen niet vaak voorkomen, maar in de meer diepgaandere hoofdstukken komen deze steeds meer voor. Termen als "Committen", "Mergen" en "Applyen" klinken beter dan "Plegen" of "Toepassen", "Samenvoegen" en "Toepassen" (wat bovendien slecht valt te onderscheiden van de commit-toepassing). De mensen die dit boek lezen zijn, naar mijn bescheiden inschatting, al redelijk op de hoogte van versiebeheer en passen (zie ik in de praktijk) deze termen al toe. Een nieuwe terminologie introduceren lijkt me dan ook niet noodzakelijk.
-Verder blijven er altijd kreten over als "directory", wat vertaald zou kunnen worden als "map", maar bij het Engelse werkwoord to map, krijgen we dan weer het probleem: hoe dit weer te vertalen. Daarom zou ik willen voorstellen om deze basis-termen toch onvertaald te laten.
+Verder blijven er altijd kreten over als "directory", wat vertaald zou kunnen worden als "map", maar bij het Engelse werkwoord to map krijgen we dan weer het probleem: hoe dit weer te vertalen? Daarom zou ik willen voorstellen om deze basis-termen toch onvertaald te laten.
 Twijfelgevallen zullen altijd blijven zoals de term "file", daarvan wordt in de praktijk zowel de term file als bestand gebruikt. Ik denk dat we hier moeten kijken hoe het in de context past. 
 Maar ook een term als "tool" en (ik zit zelf nog op een mooie Nederlandse term te broeden) "plumbing", hierbij stel ik voor om eenmalig een Nederlandse vertaling te geven, tussen haakjes de Engelse term te geven en in het vervolg de Engelse term te gebruiken. Wederom is de context hier belangrijk.
 
@@ -55,7 +55,7 @@ Git heeft een aantal verschillende transport protocollen die je kunt gebruiken.
 
 ## Wijzigingen aan het repository vastleggen ##
 
-Je hebt een eersteklas Git repository en een checkout of werkkopie van de bestanden binnen dat project. Als je wijzigingen maakt dan moet je deze committen in je repository op elk momend dat het project een status bereikt die je wilt vastleggen.
+Je hebt een eersteklas Git repository en een checkout of werkkopie van de bestanden binnen dat project. Als je wijzigingen maakt dan moet je deze committen in je repository op elk moment dat het project een status bereikt die je wilt vastleggen.
 
 Onthoud dat elk bestand in je werkdirectory in een van twee statussen kan verkeren: *gevolgd (tracked)* of *niet gevolgd (untracked)*. *Tracked* bestanden zijn bestanden die in het laatste snapshot zaten; ze kunnen *ongewijzigd (unmodified)*, *gewijzigd (modified)* of *staged* zijn. *untracked* bestanden zijn al het andere; elk bestand in je werkdirectory dat niet in je laatste snapshot en niet in je staging area zit. Als je een repository voor het eerst cloned, zullen alle bestanden tracked en unmodified zijn, omdat je ze zojuist uitgechecked hebt en nog niets gewijzigd hebt.
 
@@ -78,11 +78,12 @@ Stel dat je een nieuw bestand toevoegt aan je project, een simpel README bestand
 
 	$ vim README
 	$ git status
-	# On branch master
-	# Untracked files:
-	#   (use "git add <file>..." to include in what will be committed)
-	#
-	#	README
+	On branch master
+	Untracked files:
+	  (use "git add <file>..." to include in what will be committed)
+	
+	        README
+
 	nothing added to commit but untracked files present (use "git add" to track)
 
 Je kunt zien dat het nieuwe README bestand untrackt is, omdat het onder de “Untracked files” kop staat in je status output. Untrackt betekent eigenlijk dat Git een bestand ziet dat je niet in het vorige snapshot (commit) had; Git zal het niet in je commit snapshots toevoegen totdat jij dit expliciet aangeeft. Dit wordt zo gedaan zodat je niet per ongeluk gegenereerde binaire bestanden toevoegt, of andere bestanden die je niet wilt toevoegen. Je wilt dit README bestand wel meenemen, dus laten we het gaan tracken.
@@ -96,12 +97,12 @@ Om een nieuw bestand te beginnen te tracken, gebruik je het commando `git add`.
 Als je het status commando nogmaals uitvoert, zie je dat je README bestand nu getrackt en ge-staged is:
 
 	$ git status
-	# On branch master
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#	new file:   README
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        new file:   README
+	
 
 Je kunt zien dat het gestaged is, omdat het onder de kop “Changes to be committed” staat. Als je nu een commit doet, zal de versie van het bestand zoals het was ten tijde van je `git add` commando in de historische snapshot toegevoegd worden. Je zult je misschien herinneren dat, toen je `git init` eerder uitvoerde, je daarna `git add (bestanden)` uitvoerde; dat was om bestanden in je directory te beginnen te tracken. Het `git add` commando beschouwt een padnaam als een bestand of een directory. Als de padnaam een directory is, dan voegt het commando alle bestanden in die directory recursief toe.
 
@@ -127,13 +128,13 @@ Het `benchmarks.rb` bestand verschijnt onder een sectie genaamd “Changes not s
 
 	$ git add benchmarks.rb
 	$ git status
-	# On branch master
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#	new file:   README
-	#	modified:   benchmarks.rb
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        new file:   README
+	        modified:   benchmarks.rb
+	
 
 Beide bestanden zijn gestaged en zullen met je volgende commit meegaan. Stel nu dat je je herinnert dat je nog een kleine wijziging in `benchmarks.rb` wilt maken voordat je het commit. Je kunt het opnieuw openen en die wijziging maken, en dan ben je klaar voor de commit. Alhoewel, laten we `git status` nog een keer uitvoeren:
 
@@ -157,13 +158,13 @@ Asjemenou?! Nu staat `benchmarks.rb` zowel bij de staged en unstaged genoemd. Ho
 
 	$ git add benchmarks.rb
 	$ git status
-	# On branch master
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#	new file:   README
-	#	modified:   benchmarks.rb
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        new file:   README
+	        modified:   benchmarks.rb
+	
 
 ### Bestanden negeren ###
 
@@ -186,16 +187,16 @@ Expansie (`glob`) patronen zijn vereenvoudigde reguliere expressies die in shell
 
 Hier is nog een voorbeeld van een `.gitignore` bestand:
 
-	# a comment – this is ignored
-	# no .a files
+	# een commentaar – dit wordt genegeerd
+	# geen .a files
 	*.a
-	# but do track lib.a, even though you're ignoring .a files above
+	# maar track lib.a wel, ook al negeer je hierboven .a files
 	!lib.a
-	# only ignore the root TODO file, not subdir/TODO
+	# negeer alleen de file TODO in de root, niet de subdirectory /TODO
 	/TODO
-	# ignore all files in the build/ directory
+	# negeer alle bestanden in de build/ directory
 	build/
-	# ignore doc/notes.txt, but not doc/server/arch.txt
+	# negeer doc/notes.txt, maar niet doc/server/arch.txt
 	doc/*.txt
 
 Een `**/` patroon is sinds versie 1.8.2 beschikbaar in Git.
@@ -385,13 +386,12 @@ Als je daarna `git rm` uitvoert, zal de verwijdering van het bestand gestaged wo
 	$ git rm grit.gemspec
 	rm 'grit.gemspec'
 	$ git status
-	# On branch master
-	#
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#       deleted:    grit.gemspec
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        deleted:    grit.gemspec
+	
 
 Als je de volgende keer een commit doet, zal het bestand verdwenen zijn en niet meer getrackt worden. Als je het bestand veranderd hebt en al aan de index toegevoegd, dan zul je de verwijdering moeten forceren met de `-f` optie. Dit is een veiligheidsmaatregel om te voorkomen dat je per ongeluk data die nog niet in een snapshot zit, en dus niet teruggehaald kan worden uit Git, weggooit.
 
@@ -653,6 +653,11 @@ De laatste echt handige optie om aan `git log` als filter mee te geven is een pa
 
 In Tabel 2-3 laten we deze en een paar andere veel voorkomende opties zien als referentie.
 
+<!-- Attention to translators: this is a table declaration.
+The lines must be formatted as follows
+<TAB><First column text><TAB><Second column text>
+-->
+
 	Optie	Omschrijving
 	-(n)	Laat alleen de laatste n commits zien
 	--since, --after	Limiteer de commits tot degenen na de gegeven datum.

From 455bd902287c4eb6eee0cb2fed30d7a5d2c2bee8 Mon Sep 17 00:00:00 2001
From: cor <git@cpt1.demon.nl>
Date: Sat, 15 Feb 2014 12:47:11 +0100
Subject: [PATCH 222/690] [nl] Chapter 02 Move the comment after first text.

    Aparently the Maruku test checks whether there is any HTML
    comment at the start (which is equally formed as the comment
    given in the English text concerning keeping the tabs unmodified.

    At this point it is not clear to me what this Maruku check consists
    of.
---
 nl/02-git-basics/01-chapter2.markdown | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/nl/02-git-basics/01-chapter2.markdown b/nl/02-git-basics/01-chapter2.markdown
index 2e9bb5c5a..4626bdf0e 100644
--- a/nl/02-git-basics/01-chapter2.markdown
+++ b/nl/02-git-basics/01-chapter2.markdown
@@ -1,3 +1,5 @@
+# De basis van Git #
+
 <!-- Attentie heren en dames vertalers.
 
 Ik zou het volgende willen voorstellen:
@@ -13,7 +15,6 @@ Let wel: ik wil niemand tot iets verplichten, maar ik denk dat we moeten streven
 Veel succes en plezier bij het vertalen...
 
 -->
-# De basis van Git #
 
 Als je slechts één hoofdstuk kunt lezen om met Git aan de slag te gaan, dan is deze het. In dit hoofdstuk worden alle basiscommando's behandeld, die je nodig hebben om het leeuwendeel van de dingen te doen waarmee je uiteindelijk je tijd met Git zult doorbrengen. Als je dit hoofdstuk doorgenomen hebt, zul je een repository kunnen configureren en initialiseren, bestanden beginnen en stoppen te volgen en veranderingen te ‘stagen’ en ‘committen’. We laten ook zien hoe je Git kunt instellen zodat het bepaalde bestanden en bestandspatronen negeert, hoe je vergissingen snel en gemakkelijk ongedaan kunt maken, hoe je de geschiedenis van je project kan doorlopen en wijzigingen tussen commits kunt zien, en hoe je kunt pushen en pullen van en naar repositories.
 

From 15b817362a288fde80039fda186999248f29f73d Mon Sep 17 00:00:00 2001
From: cor <git@cpt1.demon.nl>
Date: Sat, 15 Feb 2014 12:55:21 +0100
Subject: [PATCH 223/690] [nl] Chapter 02 Try to get past Maruku test

---
 nl/02-git-basics/01-chapter2.markdown | 43 +++++++++++++++++++--------
 1 file changed, 31 insertions(+), 12 deletions(-)

diff --git a/nl/02-git-basics/01-chapter2.markdown b/nl/02-git-basics/01-chapter2.markdown
index 4626bdf0e..e6c210d69 100644
--- a/nl/02-git-basics/01-chapter2.markdown
+++ b/nl/02-git-basics/01-chapter2.markdown
@@ -1,20 +1,39 @@
-# De basis van Git #
-
 <!-- Attentie heren en dames vertalers.
-
 Ik zou het volgende willen voorstellen:
-Er zijn bepaalde termen die voor de gemiddelde Nederlandse computer gebruiker veel beter klinken (of bekender voorkomen) als de orginele Engelse term. In het begin zullen deze termen niet vaak voorkomen, maar in de meer diepgaandere hoofdstukken komen deze steeds meer voor. Termen als "Committen", "Mergen" en "Applyen" klinken beter dan "Plegen" of "Toepassen", "Samenvoegen" en "Toepassen" (wat bovendien slecht valt te onderscheiden van de commit-toepassing). De mensen die dit boek lezen zijn, naar mijn bescheiden inschatting, al redelijk op de hoogte van versiebeheer en passen (zie ik in de praktijk) deze termen al toe. Een nieuwe terminologie introduceren lijkt me dan ook niet noodzakelijk.
-Verder blijven er altijd kreten over als "directory", wat vertaald zou kunnen worden als "map", maar bij het Engelse werkwoord to map krijgen we dan weer het probleem: hoe dit weer te vertalen? Daarom zou ik willen voorstellen om deze basis-termen toch onvertaald te laten.
-Twijfelgevallen zullen altijd blijven zoals de term "file", daarvan wordt in de praktijk zowel de term file als bestand gebruikt. Ik denk dat we hier moeten kijken hoe het in de context past. 
-Maar ook een term als "tool" en (ik zit zelf nog op een mooie Nederlandse term te broeden) "plumbing", hierbij stel ik voor om eenmalig een Nederlandse vertaling te geven, tussen haakjes de Engelse term te geven en in het vervolg de Engelse term te gebruiken. Wederom is de context hier belangrijk.
-
-Verder stel ik ook voor om de regels op https://onzetaal.nl/taaladvies zoveel mogelijk te volgen. Bijvoorbeeld de regels omtrent het spellen van Engelse werkwoorden die in het Nederlands gebruikt worden.
-
-Let wel: ik wil niemand tot iets verplichten, maar ik denk dat we moeten streven naar een zo duidelijk mogelijke en best bij de praktijk aansluitende vertaling moeten proberen te maken.
+Er zijn bepaalde termen die voor de gemiddelde Nederlandse computer gebruiker 
+veel beter klinken (of bekender voorkomen) als de orginele Engelse term. In het
+begin zullen deze termen niet vaak voorkomen, maar in de meer diepgaandere 
+hoofdstukken komen deze steeds meer voor. Termen als "Committen", "Mergen" 
+en "Applyen" klinken beter dan "Plegen" of "Toepassen", "Samenvoegen" en 
+"Toepassen" (wat bovendien slecht valt te onderscheiden van de 
+commit-toepassing). De mensen die dit boek lezen zijn, naar mijn bescheiden 
+inschatting, al redelijk op de hoogte van versiebeheer en passen (zie ik in 
+de praktijk) deze termen al toe. Een nieuwe terminologie introduceren lijkt 
+me dan ook niet noodzakelijk.
+Verder blijven er altijd kreten over als "directory", wat vertaald zou kunnen 
+worden als "map", maar bij het Engelse werkwoord to map krijgen we dan weer het
+probleem: hoe dit weer te vertalen? Daarom zou ik willen voorstellen om deze 
+basis-termen toch onvertaald te laten.
+
+Twijfelgevallen zullen altijd blijven zoals de term "file", daarvan wordt in de
+praktijk zowel de term file als bestand gebruikt. Ik denk dat we hier moeten 
+kijken hoe het in de context past. 
+Maar ook een term als "tool" en (ik zit zelf nog op een mooie Nederlandse term
+te broeden) "plumbing", hierbij stel ik voor om eenmalig een Nederlandse 
+vertaling te geven, tussen haakjes de Engelse term te geven en in het vervolg
+de Engelse term te gebruiken. Wederom is de context hier belangrijk.
+
+Verder stel ik ook voor om de regels op https://onzetaal.nl/taaladvies zoveel
+mogelijk te volgen. Bijvoorbeeld de regels omtrent het spellen van Engelse 
+werkwoorden die in het Nederlands gebruikt worden.
+
+Let wel: ik wil niemand tot iets verplichten, maar ik denk dat we moeten 
+streven naar een zo duidelijk mogelijke en best bij de praktijk aansluitende
+vertaling moeten proberen te maken.
 
 Veel succes en plezier bij het vertalen...
-
 -->
+# De basis van Git #
 
 Als je slechts één hoofdstuk kunt lezen om met Git aan de slag te gaan, dan is deze het. In dit hoofdstuk worden alle basiscommando's behandeld, die je nodig hebben om het leeuwendeel van de dingen te doen waarmee je uiteindelijk je tijd met Git zult doorbrengen. Als je dit hoofdstuk doorgenomen hebt, zul je een repository kunnen configureren en initialiseren, bestanden beginnen en stoppen te volgen en veranderingen te ‘stagen’ en ‘committen’. We laten ook zien hoe je Git kunt instellen zodat het bepaalde bestanden en bestandspatronen negeert, hoe je vergissingen snel en gemakkelijk ongedaan kunt maken, hoe je de geschiedenis van je project kan doorlopen en wijzigingen tussen commits kunt zien, en hoe je kunt pushen en pullen van en naar repositories.
 

From ba70a238ee735926170cab45103fc738b55cf68d Mon Sep 17 00:00:00 2001
From: cor <git@cpt1.demon.nl>
Date: Sat, 15 Feb 2014 13:00:49 +0100
Subject: [PATCH 224/690] [nl] Chapter 01 Try to beat Maruku test

---
 nl/01-introduction/01-chapter1.markdown | 38 +++++++++++++++++++------
 1 file changed, 30 insertions(+), 8 deletions(-)

diff --git a/nl/01-introduction/01-chapter1.markdown b/nl/01-introduction/01-chapter1.markdown
index c423008e7..b7eca8b91 100644
--- a/nl/01-introduction/01-chapter1.markdown
+++ b/nl/01-introduction/01-chapter1.markdown
@@ -1,15 +1,37 @@
 <!-- Attentie heren en dames vertalers.
-
 Ik zou het volgende willen voorstellen:
-Er zijn bepaalde termen die voor de gemiddelde Nederlandse computer gebruiker veel beter klinken (of bekender voorkomen) als de orginele Engelse term. In het begin zullen deze termen niet vaak voorkomen, maar in de meer diepgaandere hoofdstukken komen deze steeds meer voor. Termen als "Committen", "Mergen" en "Applyen" klinken beter dan "Plegen" of "Toepassen", "Samenvoegen" en "Toepassen" (wat bovendien slecht valt te onderscheiden van de commit-toepassing). De mensen die dit boek lezen zijn, naar mijn bescheiden inschatting, al redelijk op de hoogte van versiebeheer en passen (zie ik in de praktijk) deze termen al toe. Een nieuwe terminologie introduceren lijkt me dan ook niet noodzakelijk.
-Verder blijven er altijd kreten over als "directory", wat vertaald zou kunnen worden als "map", maar bij het Engelse werkwoord to map, krijgen we dan weer het probleem: hoe dit weer te vertalen. Daarom zou ik willen voorstellen om deze basis-termen toch onvertaald te laten.
-Twijfelgevallen zullen altijd blijven zoals de term "file", daarvan wordt in de praktijk zowel de term file als bestand gebruikt. Ik denk dat we hier moeten kijken hoe het in de context past. 
-Maar ook een term als "tool" en (ik zit zelf nog op een mooie Nederlandse term te broeden) "plumbing", hierbij stel ik voor om eenmalig een Nederlandse vertaling te geven, tussen haakjes de Engelse term te geven en in het vervolg de Engelse term te gebruiken. Wederom is de context hier belangrijk.
-
-Let wel: ik wil niemand tot iets verplichten, maar ik denk dat we moeten streven naar een zo duidelijk mogelijke en best bij de praktijk aansluitende vertaling moeten proberen te maken.
+Er zijn bepaalde termen die voor de gemiddelde Nederlandse computer gebruiker 
+veel beter klinken (of bekender voorkomen) als de orginele Engelse term. In het
+begin zullen deze termen niet vaak voorkomen, maar in de meer diepgaandere 
+hoofdstukken komen deze steeds meer voor. Termen als "Committen", "Mergen" 
+en "Applyen" klinken beter dan "Plegen" of "Toepassen", "Samenvoegen" en 
+"Toepassen" (wat bovendien slecht valt te onderscheiden van de 
+commit-toepassing). De mensen die dit boek lezen zijn, naar mijn bescheiden 
+inschatting, al redelijk op de hoogte van versiebeheer en passen (zie ik in 
+de praktijk) deze termen al toe. Een nieuwe terminologie introduceren lijkt 
+me dan ook niet noodzakelijk.
+Verder blijven er altijd kreten over als "directory", wat vertaald zou kunnen 
+worden als "map", maar bij het Engelse werkwoord to map krijgen we dan weer het
+probleem: hoe dit weer te vertalen? Daarom zou ik willen voorstellen om deze 
+basis-termen toch onvertaald te laten.
+
+Twijfelgevallen zullen altijd blijven zoals de term "file", daarvan wordt in de
+praktijk zowel de term file als bestand gebruikt. Ik denk dat we hier moeten 
+kijken hoe het in de context past. 
+Maar ook een term als "tool" en (ik zit zelf nog op een mooie Nederlandse term
+te broeden) "plumbing", hierbij stel ik voor om eenmalig een Nederlandse 
+vertaling te geven, tussen haakjes de Engelse term te geven en in het vervolg
+de Engelse term te gebruiken. Wederom is de context hier belangrijk.
+
+Verder stel ik ook voor om de regels op https://onzetaal.nl/taaladvies zoveel
+mogelijk te volgen. Bijvoorbeeld de regels omtrent het spellen van Engelse 
+werkwoorden die in het Nederlands gebruikt worden.
+
+Let wel: ik wil niemand tot iets verplichten, maar ik denk dat we moeten 
+streven naar een zo duidelijk mogelijke en best bij de praktijk aansluitende
+vertaling moeten proberen te maken.
 
 Veel succes en plezier bij het vertalen...
-
 -->
 # Aan de slag #
 

From 6c0fd74c8b7931183c8e848e7a82896c69c3b75a Mon Sep 17 00:00:00 2001
From: cor <git@cpt1.demon.nl>
Date: Sat, 15 Feb 2014 13:10:53 +0100
Subject: [PATCH 225/690] [nl] Chapter01 Add additional enter to avoid failing
 on Maruku test

---
 nl/01-introduction/01-chapter1.markdown | 1 +
 1 file changed, 1 insertion(+)

diff --git a/nl/01-introduction/01-chapter1.markdown b/nl/01-introduction/01-chapter1.markdown
index b7eca8b91..7b8906914 100644
--- a/nl/01-introduction/01-chapter1.markdown
+++ b/nl/01-introduction/01-chapter1.markdown
@@ -292,3 +292,4 @@ Als de manpage en dit boek niet genoeg zijn en je persoonlijke hulp nodig hebt,
 ## Samenvatting ##
 
 Je zou nu een beetje een idee moeten hebben wat Git is en op welke manieren het verschilt van het versiebeheersysteem dat je misschien eerder gebruikte. Je zou nu ook een werkende versie van Git op je systeem moeten hebben dat is ingesteld met jouw identiteit. Nu is het tijd om een aantal andere grondbeginselen van Git te gaan leren.
+

From 0fd163a7d34cbbf28d56eafc8a5087ab2d92aa2b Mon Sep 17 00:00:00 2001
From: cor <git@cpt1.demon.nl>
Date: Sat, 15 Feb 2014 13:16:08 +0100
Subject: [PATCH 226/690] [nl] Chapter 02 Try to pass Maruku test

---
 nl/02-git-basics/01-chapter2.markdown | 1 +
 1 file changed, 1 insertion(+)

diff --git a/nl/02-git-basics/01-chapter2.markdown b/nl/02-git-basics/01-chapter2.markdown
index e6c210d69..7592861c2 100644
--- a/nl/02-git-basics/01-chapter2.markdown
+++ b/nl/02-git-basics/01-chapter2.markdown
@@ -599,6 +599,7 @@ De meest interessante optie is `format`, waarmee je je eigen log uitvoer formaat
 	a11bef0 - Scott Chacon, 11 months ago : first commit
 
 Tabel 2-1 toont een aantal handige opties die aan format gegeven kunnen worden.
+
 <!-- Attention to translators: this is a table declaration.
 The lines must be formatted as follows
 <TAB><First column text><TAB><Second column text>

From 9b03675e2817a53dcf282bf8c8023e16e77fabb8 Mon Sep 17 00:00:00 2001
From: cor <git@cpt1.demon.nl>
Date: Sat, 15 Feb 2014 16:11:30 +0100
Subject: [PATCH 227/690] [nl][en] Add request to revisit section and
 retranslate

    For the English document I added a request to revisit a section
    as comment.
    Retranslate Dutch and revisitted the Gitolite sections.
---
 en/04-git-server/01-chapter4.markdown |   5 +
 nl/04-git-server/01-chapter4.markdown | 284 ++++++++++++++------------
 2 files changed, 153 insertions(+), 136 deletions(-)

diff --git a/en/04-git-server/01-chapter4.markdown b/en/04-git-server/01-chapter4.markdown
index f81c12918..622648798 100644
--- a/en/04-git-server/01-chapter4.markdown
+++ b/en/04-git-server/01-chapter4.markdown
@@ -120,6 +120,11 @@ In order to clone your repository to create a new bare repository, you run the c
 	Cloning into bare repository 'my_project.git'...
 	done.
 
+<!-- This next part doesn't fit the actual output as shown, the confusing part
+     of the output is no longer shown in the command output. I would like to asks
+     the original author to modify the text.
+-->
+
 The output for this command is a little confusing. Since `clone` is basically a `git init` then a `git fetch`, we see some output from the `git init` part, which creates an empty directory. The actual object transfer gives no output, but it does happen. You should now have a copy of the Git directory data in your `my_project.git` directory.
 
 This is roughly equivalent to something like
diff --git a/nl/04-git-server/01-chapter4.markdown b/nl/04-git-server/01-chapter4.markdown
index 27f3105f7..d87310e71 100644
--- a/nl/04-git-server/01-chapter4.markdown
+++ b/nl/04-git-server/01-chapter4.markdown
@@ -1,12 +1,47 @@
+<!-- Attentie heren en dames vertalers.
+Ik zou het volgende willen voorstellen:
+Er zijn bepaalde termen die voor de gemiddelde Nederlandse computer gebruiker 
+veel beter klinken (of bekender voorkomen) als de orginele Engelse term. In het
+begin zullen deze termen niet vaak voorkomen, maar in de meer diepgaandere 
+hoofdstukken komen deze steeds meer voor. Termen als "Committen", "Mergen" 
+en "Applyen" klinken beter dan "Plegen" of "Toepassen", "Samenvoegen" en 
+"Toepassen" (wat bovendien slecht valt te onderscheiden van de 
+commit-toepassing). De mensen die dit boek lezen zijn, naar mijn bescheiden 
+inschatting, al redelijk op de hoogte van versiebeheer en passen (zie ik in 
+de praktijk) deze termen al toe. Een nieuwe terminologie introduceren lijkt 
+me dan ook niet noodzakelijk.
+Verder blijven er altijd kreten over als "directory", wat vertaald zou kunnen 
+worden als "map", maar bij het Engelse werkwoord to map krijgen we dan weer het
+probleem: hoe dit weer te vertalen? Daarom zou ik willen voorstellen om deze 
+basis-termen toch onvertaald te laten.
+
+Twijfelgevallen zullen altijd blijven zoals de term "file", daarvan wordt in de
+praktijk zowel de term file als bestand gebruikt. Ik denk dat we hier moeten 
+kijken hoe het in de context past. 
+Maar ook een term als "tool" en (ik zit zelf nog op een mooie Nederlandse term
+te broeden) "plumbing", hierbij stel ik voor om eenmalig een Nederlandse 
+vertaling te geven, tussen haakjes de Engelse term te geven en in het vervolg
+de Engelse term te gebruiken. Wederom is de context hier belangrijk.
+
+Verder stel ik ook voor om de regels op https://onzetaal.nl/taaladvies zoveel
+mogelijk te volgen. Bijvoorbeeld de regels omtrent het spellen van Engelse 
+werkwoorden die in het Nederlands gebruikt worden.
+
+Let wel: ik wil niemand tot iets verplichten, maar ik denk dat we moeten 
+streven naar een zo duidelijk mogelijke en best bij de praktijk aansluitende
+vertaling moeten proberen te maken.
+
+Veel succes en plezier bij het vertalen...
+-->
 # Git op de server #
 
-Je zou nu de alledaagse taken waarvoor je Git zult gebruiken moeten kunnen uitvoeren. Echter, om enige vorm van samenwerking te hebben in Git is een remote repository nodig. Technisch gezien kun je wijzigingen pushen en pullen van individuele repositories, maar dat wordt afgeraden omdat je vrij gemakkelijk het werk waar anderen mee bezig zijn in de war kunt schoppen als je niet oppast. Daarnaast wil je dat je medewerkers de repository kunnen bereiken, zelfs als jouw computer van het netwerk is – het hebben van een betrouwbare gezamenlijke repository is vaak handig. De voorkeursmethode om met iemand samen te werken is om een tussenliggende repository in te richten waar beide partijen toegang tot hebben en om daar naartoe te pushen en vandaan te pullen. We zullen deze repository de `Git server` noemen, maar je zult zien dat het over het algemeen maar weinig systeembronnen kost om een Git repository te verzorgen, dus je zult er zelden een complete server voor nodig hebben.
+Je zou nu de alledaagse taken waarvoor je Git zult gebruiken moeten kunnen uitvoeren. Echter, om enige vorm van samenwerking te hebben in Git is een remote Git repository nodig. Technisch gezien kun je wijzigingen pushen en pullen van individuele repositories, maar dat wordt afgeraden omdat je vrij gemakkelijk het werk waar anderen mee bezig zijn in de war kunt schoppen als je niet oppast. Daarnaast wil je dat je medewerkers de repository kunnen bereiken, zelfs als jouw computer van het netwerk is; het hebben van een betrouwbare gezamenlijke repository is vaak handig. De voorkeursmethode om met iemand samen te werken is om een tussenliggende repository in te richten waar beide partijen toegang tot hebben en om daar naartoe te pushen en vandaan te pullen. We zullen deze repository de "Git server" noemen, maar je zult zien dat het over het algemeen maar weinig systeembronnen kost om een Git repository te verzorgen, dus je zult er zelden een complete server voor nodig hebben.
 
-Een Git server draaien is eenvoudig. Als eerste kies je met welke protocollen je de server wilt laten communiceren. Het eerste gedeelte van dit hoofdstuk zullen we de beschikbare protocollen bespreken met de voor- en nadelen van elk. De daarop volgende paragrafen zullen we een aantal veel voorkomende opstellingen bespreken die van die protocollen gebruik maken en hoe je je server ermee kunt opzetten. Als laatste laten we een paar servers van derden zien, als je het niet erg vindt om je code op de server van een ander te zetten en niet het gedoe wilt hebben van het opzetten en onderhouden van je eigen server.
+Een Git server draaien is eenvoudig. Als eerste kies je met welke protocollen je de server wilt laten communiceren. In het eerste gedeelte van dit hoofdstuk zullen we de beschikbare protocollen bespreken met de voor- en nadelen van elk. De daarop volgende paragrafen zullen we een aantal veel voorkomende opstellingen bespreken die van die protocollen gebruik maken en hoe je je server ermee kunt opzetten. Als laatste laten we een paar servers van derden zien, als je het niet erg vindt om je code op de server van een ander te zetten en niet het gedoe wilt hebben van het opzetten en onderhouden van je eigen server.
 
 Als je niet van plan bent om je eigen server te draaien, dan kun je de direct naar de laatste paragraaf van dit hoofdstuk gaan om wat mogelijkheden van online accounts te zien en dan door gaan naar het volgende hoofdstuk, waar we diverse zaken bespreken die komen kijken bij het werken met een gedistribueerde versiebeheer omgeving.
 
-Een remote repository is over het algemeen een _bare repository_ (kale repository) – een Git repository dat geen werkmap heeft. Omdat de repository alleen gebruikt wordt als een samenwerkingspunt, is er geen reden om een snapshot op de schijf te hebben; het is alleen de Git data. Een kale repository is eenvoudigweg de inhoud van de `.git` map in je project, en niets meer.
+Een remote repository is over het algemeen een _bare repository_ (kale repository): een Git repository dat geen werkmap heeft. Omdat de repository alleen gebruikt wordt als een samenwerkingspunt, is er geen reden om een snapshot op de schijf te hebben; het is alleen de Git data. Een kale repository is eenvoudigweg de inhoud van de `.git` directory in je project, en niets meer.
 
 ## De protocollen ##
 
@@ -26,7 +61,7 @@ Of je kunt dit doen:
 
 	$ git clone file:///opt/git/project.git
 
-Git werkt iets anders als je explicite `file://` aan het begin van de URL zet. Als je alleen het pad specificeert, probeert Git hardlinks te gebruiken, of het kopieert de bestanden die het nodig heeft. Als je `file://` specificeert, dan start Git de processen die het normaal gesproken gebruikt om data te transporteren over een netwerk, wat over het algemeen een minder efficiënte methode is om gegevens over te dragen. De belangrijkste reden om `file://` wel te specificeren is als je een schone kopie van de repository wilt met de vreemde referenties of objecten eruit gelaten – over het algemeen na een import uit een ander versiebeheer systeem of iets dergelijks (zie Hoofdstuk 9 voor onderhoudstaken). We zullen het normale pad hier gebruiken, omdat het bijna altijd sneller is om het zo te doen.
+Git werkt iets anders als je expliciet `file://` aan het begin van de URL zet. Als je alleen het pad specificeert, probeert Git hardlinks te gebruiken naar de bestanden die het nodig heeft. Als ze niet op hetzelfde bestandssysteem staan zal Git de objecten die het nodig heeft kopiëren, gebruikmakend van het standaard kopieer mechanisme van het besturingssysteem. Als je `file://` specificeert, dan start Git de processen die het normaal gesproken gebruikt om data te transporteren over een netwerk, wat over het algemeen een minder efficiënte methode is om gegevens over te dragen. De belangrijkste reden om `file://` wel te specificeren is als je een schone kopie van de repository wilt met de vreemde referenties of objecten eruit gelaten; over het algemeen na een import uit een ander versiebeheer systeem of iets dergelijks (zie Hoofdstuk 9 voor onderhoudstaken). We zullen het normale pad hier gebruiken, omdat het bijna altijd sneller is om het zo te doen.
 
 Om een lokale repository aan een bestaand Git project toe te voegen, kun je iets als het volgende uitvoeren:
 
@@ -36,33 +71,33 @@ Daarna kun je op gelijke wijze pushen naar, en pullen van die remote als je over
 
 #### De voordelen ####
 
-De voordelen van bestands-gebaseerde repositories zijn dat ze eenvoudig zijn en ze maken gebruik van bestaande bestandspermissies en netwerk toegang. Als je al een gedeeld bestandssysteem hebt, waar het hele team al toegang toe heeft, dan is een repository opzetten heel gemakkelijk. Je stopt de kale repository ergens waar iedereen gedeelde toegang tot heeft, en stelt de lees- en schrijfrechten in zoals je dat bij iedere andere gedeelde directory zou doen. In de volgende paragraaf "Git op een Server Krijgen" bespreken we hoe je een kopie van een kale repository kunt exporteren voor dit doeleinde.
+De voordelen van bestands-gebaseerde repositories zijn dat ze eenvoudig zijn en ze maken gebruik van bestaande bestandspermissies en netwerk toegang. Als je al een gedeeld bestandssysteem hebt waar het hele team al toegang toe heeft, dan is een repository opzetten heel gemakkelijk. Je stopt de kale repository ergens waar iedereen gedeelde toegang tot heeft, en stelt de lees- en schrijfrechten in zoals je dat bij iedere andere gedeelde directory zou doen. In de volgende paragraaf "Git op een Server Krijgen" bespreken we hoe je een kopie van een kale repository kunt exporteren voor dit doeleinde.
 
 Dit is ook een prettige optie om snel werk uit een repository van iemand anders te pakken. Als jij en een collega aan hetzelfde project werken, en hij wil dat je iets bekijkt, dan is het uitvoeren van een commando zoals `git pull /home/john/project` vaak makkelijker dan wanneer hij naar een remote server moet pushen, en jij er van moet pullen.
 
 #### De nadelen ####
 
-Een van de nadelen van deze methode is dat gedeelde toegang over het algemeen moeilijker op te zetten en te bereiken is vanaf meerdere lokaties dan simpele netwerk toegang. Als je wilt pushen van je laptop als je thuis bent, dan moet je de remote schijf aankoppelen, wat moeilijk en langzaam kan zijn als je het vergelijkt met netwerk gebaseerde toegang.
+Één van de nadelen van deze methode is dat gedeelde toegang over het algemeen moeilijker op te zetten en te bereiken is vanaf meerdere lokaties dan simpele netwerk toegang. Als je wilt pushen van je laptop als je thuis bent, dan moet je de remote schijf aankoppelen, wat moeilijk en langzaam kan zijn in vergelijking met met netwerk gebaseerde toegang.
 
-Het is ook belangrijk om te vermelden dat het niet altijd de snelste optie is, als je een gedeeld koppelpunt (mount) of iets dergelijks gebruikt. Een lokale repository is alleen snel als je snelle toegang tot de data hebt. Een repository op NFS is vaak langzamer dan een repository via SSH op dezelfde server omdat dit Git in staat stelt om op lokale schijven te werken op elk van de betrokken systemen.
+Het is ook belangrijk om te vermelden dat het niet altijd de snelste optie is als je een gedeeld koppelpunt (mount) of iets dergelijks gebruikt. Een lokale repository is alleen snel als je snelle toegang tot de data hebt. Een repository op NFS is vaak langzamer dan een repository via SSH op dezelfde server omdat dit Git in staat stelt om op lokale schijven te werken op elk van de betrokken systemen.
 
 ### Het SSH protocol ###
 
-Waarschijnlijk het meest voorkomende protocol voor Git is SSH. De reden hiervoor is dat toegang met SSH tot servers in veel plaatsen al geconfigureerd is – en als dat niet het geval is, dan is het eenvoudig om dat te doen. SSH is ook het enige netwerk gebaseerde protocol waarvan je makkelijk kunt lezen en naartoe kunt schrijven. De andere twee netwerk protocollen (HTTP en Git) zijn over het algemeen alleen-lezen, dus zelfs als je ze al beschikbaar hebt voor de ongeïnitieerde massas, dan heb je nog steeds SSH nodig voor je eigen schrijfcommandos. SSH is ook een geauthenticieerd protocol; en omdat het alom aanwezig is, is het over het algemeen eenvoudig om in te stellen en te gebruiken.
+Waarschijnlijk het meest voorkomende protocol voor Git is SSH. De reden hiervoor is dat toegang met SSH tot servers in veel plaatsen al geconfigureerd is; en als dat niet het geval is, dan is het eenvoudig om dat te doen. SSH is ook het enige netwerk gebaseerde protocol waarvan je makkelijk kunt lezen en naartoe kunt schrijven. De andere twee netwerk protocollen (HTTP en Git) zijn over het algemeen alleen-lezen, dus zelfs als je ze al beschikbaar hebt voor de ongeïnitieerde massa, dan heb je nog steeds SSH nodig voor je eigen schrijfcommandos. SSH is ook een geauthenticieerd protocol; en omdat het alom aanwezig is, is het over het algemeen eenvoudig om in te stellen en te gebruiken.
 
-Om een Git repository via SSH te klonen, kun je een ssh:// URL opgeven zoals:
+Om een Git repository via SSH te clonen, kun je een ssh:// URL opgeven zoals:
 
 	$ git clone ssh://user@server/project.git
 
-Of je geeft geen protocol op — Git gaat uit van SSH als je niet expliciet bent:
+Of je gebruikt de kortere scp-achtige syntax voor het SSH protocol:
 
 	$ git clone user@server:project.git
 
-Je kunt ook de gebruiker weglaten, en Git gebruikt gegevens van de gebruiker waarmee je op dat moment bent ingelogd.
+Je kunt ook de gebruiker weglaten, en Git gebruikt de gegevens van de gebruiker waarmee je op dat moment bent ingelogd.
 
 #### De voordelen ####
 
-Er zijn vele voordelen om SSH te gebruiken. Ten eerste moet je het eigenlijk wel gebruiken als je geauthenticeerde schrijftoegang op je repository via een netwerk wilt. Ten tweede is het relatief eenvoudig in te stellen – SSH daemons komen veel voor, veel systeembeheerders hebben er ervaring mee, en veel operating systemen zijn er mee uitgerust of hebben applicaties om ze te beheren. Daarnaast is toegang via SSH veilig – alle data transporten zijn versleuteld en geauthenticeerd. En als laatste is SSH efficiënt, net zoals bij het Git en lokale protocol worden de gegevens zo compact mogelijk gemaakt voordat het getransporteerd wordt.
+Er zijn vele voordelen om SSH te gebruiken. Ten eerste moet je het eigenlijk wel gebruiken als je geauthenticeerde schrijftoegang op je repository via een netwerk wilt. Ten tweede is het relatief eenvoudig in te stellen: SSH daemons komen veel voor, veel systeembeheerders hebben er ervaring mee, en veel operating systemen zijn er mee uitgerust of hebben applicaties om ze te beheren. Daarnaast is toegang via SSH veilig: alle data transporten zijn versleuteld en geauthenticeerd. En als laatste is SSH efficiënt, net zoals bij het Git en lokale protocol worden de gegevens zo compact mogelijk gemaakt voordat het getransporteerd wordt.
 
 #### De nadelen ####
 
@@ -91,19 +126,19 @@ Als laatste hebben we het HTTP protocol. Het mooie aan het HTTP of HTTPS protoco
 	$ mv hooks/post-update.sample hooks/post-update
 	$ chmod a+x hooks/post-update
 
-Dat is alles. De `post-update` hook, die standaard bij Git geleverd wordt, voert het noodzakelijke commando uit (`git update-server-info`) om HTTP fetching en cloning goed werkend te krijgen en houden. Dit commando wordt uitgevoerd als je via SSH naar deze repository pushed, en andere mensen kunnen clonen met behulp van zoiets als
+Dat is alles. De `post-update` hook, die standaard bij Git geleverd wordt, voert het noodzakelijke commando (`git update-server-info`) uit om HTTP fetching en cloning goed werkend te krijgen en houden. Dit commando wordt uitgevoerd als je via SSH naar deze repository pusht, en andere mensen kunnen clonen met behulp van zoiets als
 
 	$ git clone http://example.com/gitproject.git
 
-In dit specifieke voorbeeld gebruiken we het `/var/www/htdocs` pad wat gebruikelijk is voor Apache opstellingen, maar je kunt iedere statische webserver gebruiken – stop de kale repository in het betreffende pad. De Git data wordt geserveerd als standaard statische bestanden (zie hoofdstuk 9 voor details over hoe het precies geserveerd wordt).
+In dit specifieke voorbeeld gebruiken we het `/var/www/htdocs` pad wat gebruikelijk is voor Apache opstellingen, maar je kunt iedere statische webserver gebruiken – gewoon de kale repository in het betreffende pad neerzetten. De Git data wordt geserveerd als standaard statische bestanden (zie hoofdstuk 9 voor details over hoe het precies geserveerd wordt).
 
-Het is mogelijk om Git ook over HTTP te laten pushen, alhoewel dat geen veelgebruikte techniek is en het vereist dat je complexe WebDAV instellingen inricht. Omdat het zelden gebruikt wordt, zullen we het niet in dit boek behandelen. Als je geïnteresseerd bent om de HTTP-push protocollen te gebruiken, dan kun je op `http://www.kernel.org/pub/software/scm/git/docs/howto/setup-git-server-over-http.txt` lezen hoe je een repository kunt maken. Het aardige van Git laten pushen over HTTP is dat je iedere WebDAV server kunt gebruiken zonder specifieke Git funtionaliteit, dus je kunt deze optie gebruiken als je web-hosting provider WebDAV ondersteunt voor het maken van wijzigingen aan je webpagina.
+Het is mogelijk om Git ook over HTTP te laten pushen, alhoewel dat geen veelgebruikte techniek is en het vereist dat je complexe WebDAV instellingen inricht. Omdat het zelden gebruikt wordt, zullen we het niet in dit boek behandelen. Als je geïnteresseerd bent om de HTTP-push protocollen te gebruiken, dan kun je op `http://www.kernel.org/pub/software/scm/git/docs/howto/setup-git-server-over-http.txt` lezen hoe je een repository kunt maken. Het aardige van Git laten pushen over HTTP is dat je iedere WebDAV server kunt gebruiken zonder specifieke Git funtionaliteit. Dus je kunt deze optie gebruiken als je web-hosting provider WebDAV ondersteunt voor het maken van wijzigingen aan je webpagina.
 
 #### De voordelen ####
 
 Het voordeel van het gebruik van het HTTP protocol is dat het eenvoudig in te stellen is. Een handvol benodigde commando's uitvoeren is alles wat er moet gebeuren om de wereld leestoegang te geven tot je Git repository. Het neemt maar een paar minuten van je tijd. Het HTTP protocol is niet erg belastend voor de systeembronnen van je server. Omdat het over het algemeen een statische webserver gebruikt om alle data te verspreiden is het moeilijk om zelfs een kleine server te overbelasten - een normale Apache server kan gemiddeld duizenden bestanden zenden per seconde.
 
-Je kunt ook je repositories alleen-lezen serveren via HTTPS, wat inhoudt dat je het gegevenstransport kunt versleutelen; je kunt zelfs zover gaan dat je clients een specifiek gesigneerd SSL certificaat laat gebruiken. Normaal gesproken als je je deze moeite wilt getroosten, dan is het makkelijker om publieke SSH sleutels te gebruiken; maar het kan in jouw specifieke geval een betere oplossing zijn om gesigneerde SSL certificaten of andere HTTP-gebaseerde authenticatie methoden te gebruiken voor alleen-lezen toegang via HTTPS.
+Je kunt ook je repositories alleen-lezen serveren via HTTPS, wat inhoudt dat je het gegevenstransport kunt versleutelen. Je kunt zelfs zover gaan dat je clients een specifiek gesigneerd SSL certificaat laat gebruiken. Normaal gesproken als je je deze moeite wilt getroosten, dan is het makkelijker om publieke SSH sleutels te gebruiken; maar het kan in jouw specifieke geval een betere oplossing zijn om gesigneerde SSL certificaten of andere HTTP-gebaseerde authenticatie methoden te gebruiken voor alleen-lezen toegang via HTTPS.
 
 Een andere prettige bijkomstigheid is dat HTTP een dusdanig veel voorkomend protocol is dat bedrijfsfirewalls vaak zo ingesteld zijn dat ze verkeer via deze poort toestaan.
 
@@ -114,30 +149,31 @@ Het nadeel van je repository verspreiden via HTTP is dat het relatief inefficië
 ## Git op een server krijgen ##
 
 Om een Git server initieel op te zetten, moet je een bestaande repository naar een kale repository exporteren – een repository dat geen werkmap bevat. Dit is over het algemeen eenvoudig te doen.
-Om je repository te clonen met als doel het maken van een kale repository, voer je het clone commando uit met de `--bare` optie. Als conventie eindigen de namen van kale repository mappen met `.git`, zoals hier:
+Om je repository te clonen met als doel het maken van een kale repository, voer je het clone commando uit met de `--bare` optie. Als conventie eindigen de namen van kale repository directories met `.git`, zoals hier:
 
 	$ git clone --bare my_project my_project.git
-	Initialized empty Git repository in /opt/projects/my_project.git/
+	Cloning into bare repository 'my_project.git'...
+	done.
 
-De output van dit commando is een beetje verwarrend. Het commando `clone` is eigenlijk een `git init` en dan een `git fetch`, wat we hier zien is de output van het `git init` gedeelte wat een lege map aanmaakt. De eigenlijke object overdracht geeft geen output, maar het gebeurt wel. Nu zou je een kopie van de Git map data in je `my_project.git` map moeten hebben.
+De output van dit commando is een beetje verwarrend. Het commando `clone` is eigenlijk een `git init` en dan een `git fetch`, wat we hier zien is de output van het `git init` gedeelte wat een lege directory aanmaakt. De eigenlijke object overdracht geeft geen output, maar het gebeurt wel. Nu zou je een kopie van de Git directory data in je `my_project.git` directory moeten hebben.
 
-Dit is ongeveer gelijk aan
+Dit is grofweg gelijk aan dit
 
 	$ cp -Rf my_project/.git my_project.git
 
-Er zijn een paar kleine verschillen in het configuratie bestand, maar het komt op hetzelfde neer. Het neemt de Git repository zelf, zonder een werkmap, en maakt een directory specifiek hiervoor aan.
+Er zijn een paar kleine verschillen in het configuratie bestand, maar het komt op hetzelfde neer. Het neemt de Git repository zelf, zonder een werkdirectory, en maakt een directory specifiek hiervoor aan.
 
 ### De Kale Repository op een Server Zetten ###
 
-Nu je een kale kopie van je repository hebt, is het enige dat je moet doen het op een server zetten en je protocollen instellen. Laten we aannemen dat je een server ingericht hebt, die `git.example.com` heet, waar je SSH toegang op hebt, en waar je al je Git repositories wilt opslaan onder de `/opt/git` map. Je kunt je nieuwe repository beschikbaar stellen door je kale repository ernaartoe te kopiëren:
+Nu je een kale kopie van je repository hebt, is het enige dat je moet doen het op een server zetten en je protocollen instellen. Laten we aannemen dat je een server ingericht hebt die `git.example.com` heet, waar je SSH toegang op hebt, en waar je al je Git repositories wilt opslaan onder de `/opt/git` directory. Je kunt je nieuwe repository beschikbaar stellen door je kale repository ernaartoe te kopiëren:
 
 	$ scp -r my_project.git user@git.example.com:/opt/git
 
-Vanaf dat moment kunnen andere gebruikers, die SSH toegang hebben tot dezelfde server en lees-toegang hebben tot de `/opt/git` map, jouw repository clonen door dit uit te voeren:
+Vanaf dat moment kunnen andere gebruikers, die SSH toegang hebben tot dezelfde server en lees-toegang hebben tot de `/opt/git` directory, jouw repository clonen door dit uit te voeren:
 
 	$ git clone user@git.example.com:/opt/git/my_project.git
 
-Als een gebruiker met SSH op een server inlogt en schrijftoegang heeft tot de `/opt/git/my_project.git` map, dan hebben ze automatisch ook push toegang. Git zal automatisch de correcte groep schrijfrechten aan een repository toekennen als je het `git init` commando met de `--shared` optie uitvoert.
+Als een gebruiker met SSH op een server inlogt en schrijftoegang heeft tot de `/opt/git/my_project.git` directory, dan hebben ze automatisch ook push toegang. Git zal automatisch de correcte groep schrijfrechten aan een repository toekennen als je het `git init` commando met de `--shared` optie uitvoert.
 
 	$ ssh user@git.example.com
 	$ cd /opt/git/my_project.git
@@ -145,7 +181,7 @@ Als een gebruiker met SSH op een server inlogt en schrijftoegang heeft tot de `/
 
 Je ziet hoe eenvoudig het is om een Git repository te nemen, een kale versie aan te maken, en het op een server plaatsen waar jij en je medewerkers SSH toegang tot hebben. Nu zijn jullie klaar om aan hetzelfde project samen te werken.
 
-Het is belangrijk om op te merken dat dit letterlijk alles is wat je moet doen om een bruikbare Git server te draaien waarop meerdere mensen toegang hebben – maak alleen een paar accounts met SSH toegang aan op een server, en stop een kale repository ergens waar al die gebruikers lees- en schrijftoegang toe hebben. Je bent er klaar voor – je hebt niets anders nodig.
+Het is belangrijk om op te merken dat dit letterlijk alles is wat je moet doen om een bruikbare Git server te draaien waarop meerdere mensen toegang hebben: maak alleen een paar accounts met SSH toegang aan op een server, en stop een kale repository ergens waar al die gebruikers lees- en schrijftoegang toe hebben. Je bent er klaar voor – je hebt niets anders nodig.
 
 In de volgende paragrafen zul je zien hoe je meer ingewikkelde opstellingen kunt maken. Deze bespreking zal het niet hoeven aanmaken van gebruikers accounts voor elke gebruiker, publieke leestoegang tot repositories, grafische web interfaces, het gebruik van de Gitosis applicatie en meer omvatten. Maar, hou in gedachten dat om samen te kunnen werken met mensen op een privé project, alles wat je _nodig_ hebt een SSH server is en een kale repository.
 
@@ -161,20 +197,20 @@ Als je je repositories op een server wilt zetten, die geen accounts heeft voor i
 
 Er zijn een paar manieren waarop je iedereen in je team toegang kunt geven. De eerste is voor iedereen accounts aanmaken, wat rechttoe rechtaan is maar bewerkelijk kan zijn. Je wilt vermoedelijk niet `adduser` uitvoeren en tijdelijke wachtwoorden instellen voor iedere gebruiker.
 
-Een tweede methode is een generieke 'git' gebruiker aan te maken op de machine, aan iedere gebruiker die schijftoegang moet hebben vragen of ze je een publieke SSH sleutel sturen, en die sleutel toevoegen aan het `~/.ssh/authorized_keys` bestand van die nieuwe 'git' gebruiker. Vanaf dat moment zal iedereen toegang hebben op die machine via de 'git' gebruiker. Dit tast de commit data op geen enkele manier aan – de SSH gebruiker waarmee je inlogt zal de commits die je opgeslagen hebt niet beïnvloeden.
+Een tweede methode is een enkele 'git' gebruiker aan te maken op de machine, aan iedere gebruiker die schijftoegang moet hebben vragen of ze je een publieke SSH sleutel sturen, en die sleutel toevoegen aan het `~/.ssh/authorized_keys` bestand van die nieuwe 'git' gebruiker. Vanaf dat moment zal iedereen toegang hebben op die machine via de 'git' gebruiker. Dit tast de commit data op geen enkele manier aan – de SSH gebruiker waarmee je inlogt zal de commits die je opgeslagen hebt niet beïnvloeden.
 
 Een andere manier waarop je het kunt doen is je SSH server laten authenticeren middels een LDAP server of een andere gecentraliseerde authenticatie bron, die misschien al ingericht is. Zolang iedere gebruiker shell toegang kan krijgen op de machine, zou ieder SSH authenticatie mechanisme dat je kunt bedenken moeten werken.
 
 ## Je publieke SSH sleutel genereren ##
 
-Dat gezegd hebbende, zijn er vele Git servers die authenticeren met een publieke SSH sleutel. Om een publieke sleutel te hebben, zal iedere gebruiker in je systeem er een moeten genereren als ze er nog geen hebben. Dit proces is bij alle operating systemen vergelijkbaar. Als eerste moet je controleren of je er niet al een hebt. Standaard staan de SSH sleutels van de gebruikers in hun eigen `~/.ssh` map. Je kunt makkelijk nagaan of je al een sleutel hebt door naar die map te gaan en de inhoud te bekijken:
+Dat gezegd hebbende, zijn er vele Git servers die authenticeren met een publieke SSH sleutel. Om een publieke sleutel te kunnen aanleveren, zal iedere gebruiker in je systeem er een moeten genereren als ze er nog geen hebben. Dit proces is bij alle operating systemen vergelijkbaar. Als eerste moet je controleren of je er niet al een hebt. Standaard staan de SSH sleutels van de gebruikers in hun eigen `~/.ssh` directory. Je kunt makkelijk nagaan of je al een sleutel hebt door naar die directory te gaan en de inhoud te bekijken:
 
 	$ cd ~/.ssh
 	$ ls
 	authorized_keys2  id_dsa       known_hosts
 	config            id_dsa.pub
 
-Je bent op zoek naar een aantal bestanden genaamd iets en iets.pub, waarbij het `iets` meestal zoiets is als `id_dsa` of `id_rsa`. Het `.pub` bestand is je publieke sleutel en het andere bestand is je private sleutel. Als je deze bestanden niet hebt (of als je zelfs geen `.ssh` map hebt), dan kun je ze aanmaken door een applicatie genaamd `ssh-keygen` uit te voeren, deze wordt met het SSH pakket op Linux/Mac systemen meegeleverd en met het MSysGit pakket op Windows:
+Je bent op zoek naar een aantal bestanden genaamd iets en iets.pub, waarbij het iets meestal zoiets is als `id_dsa` of `id_rsa`. Het `.pub` bestand is je publieke sleutel en het andere bestand is je private sleutel. Als je deze bestanden niet hebt (of als je zelfs geen `.ssh` directory hebt), dan kun je ze aanmaken door een applicatie genaamd `ssh-keygen` uit te voeren, deze wordt met het SSH pakket op Linux/Mac systemen meegeleverd en met het MSysGit pakket op Windows:
 
 	$ ssh-keygen
 	Generating public/private rsa key pair.
@@ -198,11 +234,11 @@ Iedere gebruiker die dit doet, moet zijn sleutel sturen naar jou of degene die d
 	mZ+AW4OZPnTPI89ZPmVMLuayrD2cE86Z/il8b+gw3r3+1nKatmIkjn2so1d01QraTlMqVSsbx
 	NrRFi9wrf+M7Q== schacon@agadorlaptop.local
 
-Voor een uitgebreide tutorial over het aanmaken van een SSH sleutel op meerdere operating systemen, verwijzen ze je naar de GitHub handleiding over SSH sleutels op `http://github.com/guides/providing-your-ssh-key`.
+Voor een uitgebreidere tutorial over het aanmaken van een SSH sleutel op meerdere operating systemen, verwijzen we je naar de GitHub handleiding over SSH sleutels op `http://github.com/guides/providing-your-ssh-key`.
 
 ## De Server Opzetten ##
 
-Laten we het opzetten van SSH toegang aan de server kant eens doorlopen. In dit voorbeeld zul je de `authorized_keys` methode gebruiken om je gebruikers te authenticeren. We gaan er ook vanuit dat je een standaard Linux distributie gebruikt zoals Ubuntu. Als eerste maak je een 'git' gebruiker aan en een `.ssh` map voor die gebruiker.
+Laten we het opzetten van SSH toegang aan de server kant eens doorlopen. In dit voorbeeld zul je de `authorized_keys` methode gebruiken om je gebruikers te authenticeren. We gaan er ook vanuit dat je een standaard Linux distributie gebruikt zoals Ubuntu. Als eerste maak je een 'git' gebruiker aan en een `.ssh` directory voor die gebruiker.
 
 	$ sudo adduser git
 	$ su git
@@ -251,7 +287,7 @@ Vanaf dat moment kunnen de anderen het clonen en wijzigingen even gemakkelijk te
 
 Op deze manier kun je snel een lees/schrijf Git server draaiend krijgen voor een handjevol ontwikkelaars.
 
-Als een extra voorzorgsmaatregel kun je de 'git' gebruiker makkelijk beperken tot het doen van alleen Git activiteiten, met een gelimiteerde shell applicatie genaamd `git-shell` die bij Git geleverd wordt.
+Als een extra voorzorgsmaatregel kun je de 'git' gebruiker makkelijk beperken tot het doen van alleen Git activiteiten, met een gelimiteerde shell tool genaamd `git-shell` die bij Git geleverd wordt.
 Als je dit als login shell voor je 'git' gebruiker instelt, dan kan de 'git' gebruiker geen normale shell toegang hebben op je server. Specificeer `git-shell` in plaats van bash of csh voor je gebruikers login shell om dit te gebruiken. Om dit te doen zul je waarschijnlijk het `/etc/passwd` bestand aan moeten passen:
 
 	$ sudo vim /etc/passwd
@@ -274,7 +310,7 @@ Nu kan de 'git' gebruiker de SSH connectie alleen gebruiken om Git repositories
 
 Wat als je anonieme leestoegang op je project wil? Misschien wil je geen intern privé project beheren, maar een open source project. Of misschien heb je een aantal geautomatiseerde bouwservers of continue integratie servers die vaak wisselen, en wil je niet doorlopend SSH sleutels hoeven genereren – je wil gewoon eenvoudige anonieme leestoegang toevoegen.
 
-Waarschijnlijk is de eenvoudigste manier voor kleinschalige opstellingen om een statische webserver in te stellen, waarbij de document root naar de plaats van je Git repositories wijst, en dan de `post-update` haak aanzetten waar we het in de eerste paragraaf van dit hoofdstuk over gehad hebben. Laten we eens uitgaan van het voorgaande voorbeeld. Stel dat je je repositories in de `/opt/git` map hebt staan, en er draait een Apache server op je machine. Nogmaals, je kunt hiervoor iedere web server gebruiken: maar als voorbeeld zullen we wat simpele Apache configuraties laten zien, die je het idee weergeven van wat je nodig hebt.
+Waarschijnlijk is de eenvoudigste manier voor kleinschalige opstellingen om een statische webserver in te stellen, waarbij de document root naar de plaats van je Git repositories wijst, en dan de `post-update` hook aanzetten waar we het in de eerste paragraaf van dit hoofdstuk over gehad hebben. Laten we eens uitgaan van het voorgaande voorbeeld. Stel dat je je repositories in de `/opt/git` directory hebt staan, en er draait een Apache server op je machine. Nogmaals, je kunt hiervoor iedere web server gebruiken: maar als voorbeeld zullen we wat simpele Apache configuraties laten zien, die je het idee weergeven van wat je nodig hebt.
 
 Eerst moet je de haak inschakelen:
 
@@ -282,17 +318,22 @@ Eerst moet je de haak inschakelen:
 	$ mv hooks/post-update.sample hooks/post-update
 	$ chmod a+x hooks/post-update
 
-Als je een lagere versie dan 1.6 van Git gebruikt, dan is het `mv` commando niet nodig — Git is recentelijk pas begonnen met de namen van de haak voorbeelden op .sample te laten eindigen.
-
 Wat doet deze `post-update` haak? Het ziet er eigenlijk als volgt uit:
 
 	$ cat .git/hooks/post-update
 	#!/bin/sh
+	#
+	# An example hook script to prepare a packed repository for use over
+	# dumb transports.
+	#
+	# To enable this hook, rename this file to "post-update".
+	#
+	
 	exec git-update-server-info
 
 Dit betekent dat wanneer je naar de server via SSH pusht, Git dit commando uitvoert om de benodigde bestanden voor HTTP fetching te verversen.
 
-Vervolgens moet je een VirtualHost regel in je Apache configuratie aanmaken, met de document root als de hoofdmap van je Git projecten. Hier nemen we aan dat je wildcard DNS ingesteld hebt om `*.gitserver` door te sturen naar waar je dit alles draait:
+Vervolgens moet je een VirtualHost regel in je Apache configuratie aanmaken, met de document root als de hoofddirectory van je Git projecten. Hier nemen we aan dat je wildcard DNS ingesteld hebt om `*.gitserver` door te sturen naar de machine waar je dit alles draait:
 
 	<VirtualHost *:80>
 	    ServerName git.gitserver
@@ -303,11 +344,11 @@ Vervolgens moet je een VirtualHost regel in je Apache configuratie aanmaken, met
 	    </Directory>
 	</VirtualHost>
 
-Je zult ook de Unix gebruikers groep van de `/opt/git` mappen moeten zetten op `www-data` zodat je web server leestoegang hebt op de repositories, omdat de Apache instantie het CGI script (standaard) uitvoert als die gebruiker draait:
+Je zult ook de Unix gebruikers groep van de `/opt/git` directories moeten zetten op `www-data` zodat je web server leestoegang hebt op de repositories, omdat de Apache instantie het CGI script (standaard) uitvoert als die gebruiker draait:
 
 	$ chgrp -R www-data /opt/git
 
-Als je Apache herstart, dan zou je je repositories onder die map moeten kunnen klonen door de URL van je project te specificeren:
+Als je Apache herstart, dan zou je je repositories onder die directory moeten kunnen clonen door de URL van je project te specificeren:
 
 	$ git clone http://git.gitserver/project.git
 
@@ -320,7 +361,7 @@ Nu je gewone lees/schrijf en alleen-lezen toegang tot je project hebt, wil je mi
 Insert 18333fig0401.png
 Figuur 4-1. De GitWeb web-gebaseerde gebruikers interface.
 
-Als je wil zien hoe GitWeb er voor jouw project uitziet, dan heeft Git een commando waarmee je een tijdelijke instantie op kunt starten als je een lichtgewicht server op je systeem hebt zoals `lighttpd` of `webrick`. Op Linux machines is `lighttpd` vaak geïnstalleerd, dus je kunt het misschien draaiend krijgen door `git instaweb` in te typen in je project map. Als je op een Mac werkt: Leopard heeft Ruby voorgeïnstalleerd, dus `webrick` zou je de meeste kans geven. Om `instaweb` met een server anders dan lighttpd te starten, moet je het uitvoeren met de `--httpd` optie.
+Als je wil zien hoe GitWeb er voor jouw project uitziet, dan heeft Git een commando waarmee je een tijdelijke instantie op kunt starten als je een lichtgewicht server op je systeem hebt zoals `lighttpd` of `webrick`. Op Linux machines is `lighttpd` vaak geïnstalleerd, dus je kunt het misschien draaiend krijgen door `git instaweb` in te typen in je project directory. Als je op een Mac werkt: Leopard heeft Ruby voorgeïnstalleerd, dus `webrick` zou je de meeste kans geven. Om `instaweb` met een server anders dan lighttpd te starten, moet je het uitvoeren met de `--httpd` optie.
 
 	$ git instaweb --httpd=webrick
 	[2009-02-21 10:02:21] INFO  WEBrick 1.3.1
@@ -359,7 +400,7 @@ Nogmaals, GitWeb kan geserveerd worden met iedere web server die in staat is CGI
 
 De publieke sleutels van alle gebruikers in een `authorized_keys` bestand bewaren voor toegang werkt slechts korte tijd goed. Als je honderden gebruikers hebt, dan is het te bewerkelijk om dat proces te blijven volgen. Je moet iedere keer in de server inloggen, en er is geen toegangscontrole – iedereen in het bestand heeft lees- en schrijftoegang op ieder project.
 
-Op dat moment zou je kunnen overwegen een veelgebruikt software project genaamd Gitosis te gaan gebruiken. Gitosis is in feite een verzameling scripts die je helpen het `authorized_keys` bestand te beheren alsmede eenvoudig toegangscontrole te implementeren. Het interessante hieraan is dat de gebruikers interface voor deze applicatie om mensen toe te voegen en toegang te bepalen, geen web interface is maar een speciale Git repository. Je beheert de informatie in dat project en als je het pushed, dan herconfigureert Gitosis de server op basis van dat project, wat best wel slim bedacht is.
+Op dat moment zou je kunnen overwegen een veelgebruikt software project genaamd Gitosis te gaan gebruiken. Gitosis is in feite een verzameling scripts die je helpen het `authorized_keys` bestand te beheren alsmede eenvoudig toegangscontrole te implementeren. Het interessante hieraan is dat de gebruikers interface voor deze applicatie om mensen toe te voegen en toegang te bepalen, geen web interface is maar een speciale Git repository. Je beheert de informatie in dat project en als je het pusht, dan herconfigureert Gitosis de server op basis van dat project, wat best wel slim bedacht is.
 
 Gitosis installeren is niet de makkelijkste taak ooit, maar het is ook niet al te moeilijk. Het is het makkelijkste om er een Linux server voor te gebruiken – deze voorbeelden gebruiken een standaard Ubuntu 8.10 server.
 
@@ -373,7 +414,7 @@ Vervolgens kloon en installeer je Gitosis van de hoofdpagina van het project:
 	$ cd gitosis
 	$ sudo python setup.py install
 
-Daarmee worden een aantal bestanden geïnstalleerd, die Gitosis zal gebruiken. Daarna wil Gitosis zijn repositories onder `/home/git` stoppen, wat prima is. Maar je hebt je repositories al in `/opt/git` geconfigureerd, dus in plaats van alles te herconfigureren maken we een symbolische link aan:
+Daarmee worden een aantal executables geïnstalleerd, die Gitosis zal gebruiken. Daarna wil Gitosis zijn repositories onder `/home/git` stoppen, wat prima is. Maar je hebt je repositories al in `/opt/git` geconfigureerd, dus in plaats van alles te herconfigureren maken we een symbolische link aan:
 
 	$ ln -s /opt/git /home/git/repositories
 
@@ -395,7 +436,7 @@ Nu wordt het tijd om Gitosis te initialiseren. Je doet dit door het `gitosis-ini
 	Initialized empty Git repository in /opt/git/gitosis-admin.git/
 	Reinitialized existing Git repository in /opt/git/gitosis-admin.git/
 
-Dit staat de gebruiker met die sleutel toe de hoofd Git repository, die de Gitosis setup regelt, aan te passen. Daarna zul je met de hand het execute bit op het `post-update` script moeten aanzetten voor je nieuwe beheer repository.
+Dit staat de gebruiker met die sleutel toe de hoofd Git repository die de Gitosis setup regelt, aan te passen. Daarna zul je met de hand het execute bit op het `post-update` script moeten aanzetten voor je nieuwe beheer repository.
 
 	$ sudo chmod 755 /opt/git/gitosis-admin.git/hooks/post-update
 
@@ -403,15 +444,15 @@ Je bent nu klaar voor de start. Als je alles juist hebt ingesteld, kun je nu met
 
 	$ ssh git@gitserver
 	PTY allocation request failed on channel 0
-	fatal: unrecognized command 'gitosis-serve schacon@quaternion'
+	ERROR:gitosis.serve.main:Need SSH_ORIGINAL_COMMAND in environment.
 	  Connection to gitserver closed.
 
-Dat betekent dat Gitosis je herkend heeft, maar je buitensluit omdat je geen Git commando's aan het doen bent. Dus, laten we een echt Git commando doen — je gaat de Gitosis beheer repository klonen:
+Dat betekent dat Gitosis je herkend heeft, maar je buitensluit omdat je geen Git commando's aan het doen bent. Dus, laten we een echt Git commando doen; je gaat de Gitosis beheer repository clonen:
 
 	# op je locale computer
 	$ git clone git@gitserver:gitosis-admin.git
 
-Nu heb je een map genaamd `gitosis-admin`, die twee hoofd gedeeltes heeft:
+Nu heb je een directory genaamd `gitosis-admin`, die twee hoofd gedeeltes heeft:
 
 	$ cd gitosis-admin
 	$ find .
@@ -419,7 +460,7 @@ Nu heb je een map genaamd `gitosis-admin`, die twee hoofd gedeeltes heeft:
 	./keydir
 	./keydir/scott.pub
 
-Het `gitosis.conf` bestand is het beheer bestand dat je zult gebruiken om gebruikers, repositories en permissies te specificeren. De `keydir` map is de plaats waar je de publieke sleutels opslaat van alle gebruikers die een vorm van toegang tot de repositories hebben – één bestand per gebruiker. De naam van het bestand in `keydir` (in het vorige voorbeeld, `scott.pub`) zal anders zijn in jouw geval – Gitosis haalt de naam uit de beschrijving aan het einde van de publieke sleutel die was geïmporteerd met het `gitosis-init` script.
+Het `gitosis.conf` bestand is het beheer bestand dat je zult gebruiken om gebruikers, repositories en permissies te specificeren. De `keydir` directory is de plaats waar je de publieke sleutels opslaat van alle gebruikers die een vorm van toegang tot de repositories hebben – één bestand per gebruiker. De naam van het bestand in `keydir` (in het vorige voorbeeld, `scott.pub`) zal anders zijn in jouw geval – Gitosis haalt de naam uit de beschrijving aan het einde van de publieke sleutel die was geïmporteerd met het `gitosis-init` script.
 
 Als je naar het `gitosis.conf` bestand kijkt, zou het alleen informatie over het zojuist gekloonde `gitosis-admin` project mogen bevatten:
 
@@ -441,14 +482,14 @@ Laten we nu een nieuw project voor je toevoegen. Je voegt een nieuwe sectie gena
 Wanneer je wijzigingen aan het `gitosis-admin` project maakt, moet je de veranderingen committen en terug pushen naar de server voordat ze effect hebben:
 
 	$ git commit -am 'add iphone_project and mobile group'
-	[master]: created 8962da8: "changed name"
-	 1 files changed, 4 insertions(+), 0 deletions(-)
-	$ git push
+	[master 8962da8] add iphone_project and mobile group
+	 1 file changed, 4 insertions(+)
+	$ git push origin master
 	Counting objects: 5, done.
-	Compressing objects: 100% (2/2), done.
-	Writing objects: 100% (3/3), 272 bytes, done.
-	Total 3 (delta 1), reused 0 (delta 0)
-	To git@gitserver:/opt/git/gitosis-admin.git
+	Compressing objects: 100% (3/3), done.
+	Writing objects: 100% (3/3), 272 bytes | 0 bytes/s, done.
+	Total 3 (delta 0), reused 0 (delta 0)
+	To git@gitserver:gitosis-admin.git
 	   fb27aec..8962da8  master -> master
 
 Je kunt je eerste push naar het nieuwe `iphone_project` doen door je server als een remote aan je locale versie van je project toe te voegen en te pushen. Je hoeft geen bare repositories handmatig meer te maken voor nieuwe projecten op de server — Gitosis maakt ze automatisch als het de eerste push ziet:
@@ -457,14 +498,14 @@ Je kunt je eerste push naar het nieuwe `iphone_project` doen door je server als
 	$ git push origin master
 	Initialized empty Git repository in /opt/git/iphone_project.git/
 	Counting objects: 3, done.
-	Writing objects: 100% (3/3), 230 bytes, done.
+	Writing objects: 100% (3/3), 230 bytes | 0 bytes/s, done.
 	Total 3 (delta 0), reused 0 (delta 0)
 	To git@gitserver:iphone_project.git
 	 * [new branch]      master -> master
 
 Merk op dat je geen pad hoeft te specificeren (sterker nog, het wel doen zal niet werken), alleen een dubbele punt en dan de naam van het project — Gitosis zal het voor je vinden.
 
-Je wil samen met je vrienden aan dit project werken, dus je zult hun publieke sleutels weer toe moeten voegen. Maar in plaats van ze handmatig aan het `~/.ssh/authorized_keys` bestand op je server toe te voegen, voeg je ze één sleutel per bestand, aan de `keydir` map toe. Hoe je de sleutels noemt bepaalt hoe je aan de gebruikers refereert in het `gitosis.conf` bestand. Laten we de publieke sleutels voor John, Josie en Jessica toevoegen:
+Je wil samen met je vrienden aan dit project werken, dus je zult hun publieke sleutels weer toe moeten voegen. Maar in plaats van ze handmatig aan het `~/.ssh/authorized_keys` bestand op je server toe te voegen, voeg je ze één sleutel per bestand, aan de `keydir` directory toe. Hoe je de sleutels noemt bepaalt hoe je aan de gebruikers refereert in het `gitosis.conf` bestand. Laten we de publieke sleutels voor John, Josie en Jessica toevoegen:
 
 	$ cp /tmp/id_rsa.john.pub keydir/john.pub
 	$ cp /tmp/id_rsa.josie.pub keydir/josie.pub
@@ -501,94 +542,71 @@ Nu kan John het project clonen en updates krijgen, maar Gitosis zal hem niet toe
 	writable  = another_iphone_project
 	members   = @mobile_committers john
 
-Als je problemen hebt, kan het handig zijn om `loglevel=DEBUG` onder de `[gitosis]` sectie te zetten. Als je je push-toegang bent verloren door een kapotte configuratie te pushen, kun je het handmatig repareren in het bestand `/home/git/.gitosis.conf` op de server – het bestand waar Gitosis zijn informatie vandaan haalt. Een push naar het project neemt het `gitosis.conf` bestand dat je zojuist gepushed hebt en stopt het daar. Als je het bestand handmatig aanpast, zal het zo blijven totdat de volgende succesvolle push gedaan wordt naar het `gitosis-admin` project.
+Als je problemen hebt, kan het handig zijn om `loglevel=DEBUG` onder de `[gitosis]` sectie te zetten. Als je je push-toegang bent verloren door een kapotte configuratie te pushen, kun je het handmatig repareren in het bestand `/home/git/.gitosis.conf` op de server – het bestand waar Gitosis zijn informatie vandaan haalt. Een push naar het project neemt het `gitosis.conf` bestand dat je zojuist gepusht hebt en stopt het daar. Als je het bestand handmatig aanpast, zal het zo blijven totdat de volgende succesvolle push gedaan wordt naar het `gitosis-admin` project.
 
 ## Gitolite ##
 
-Merk op: de laatste versie van deze paragraaf in het ProGit boek is altijd beschikbaar binnen de [gitolite documentation][gldpg]. De auteur geeft ook nederig aan dat, hoewel deze paragraaf accuraat is, het *kan* (en vaak ook *is*) worden gebruikt om gitolite te installeren zonder enige andere documentatie te lezen, maar dat je er vanuit mag gaan dat het niet compleet is, en het zeker niet de gehele enorme hoeveelheid documentatie kan vervangen dat meegeleverd wordt met gitolite.
+Deze paragraaf fungeerrt als een snelle introductie tot Gitolite, en geeft korte installatie en setup instructies. Het kan echter niet de enoreme hoeveelheid [documentatie][gltoc] vervangen waar Gitolite mee wordt geleverd. Er kunnen ook af en toe wijzigingen in deze paragraaf worden gemaakt, dus je kunt wellicht ook [hier][gldpg] kijken voor de laatste versie.
 
-[gldpg]: http://github.com/sitaramc/gitolite/blob/pu/doc/progit-article.mkd
+[gldpg]: http://sitaramc.github.com/Gitolite/progit.html
+[gltoc]: http://sitaramc.github.com/Gitolite/master-toc.html
 
-Git begint erg populair te worden in het bedrijfsleven, die de neiging heeft nog wat additionele eisen te hebben op het gebied van toegangscontrole. Gitolite was oorspronkelijk gemaakt om bij het vervullen van deze eisen te helpen, maar het blijkt dat het even bruikbaar is in de wereld van de open source: het Fedora Project beheert toegang tot hun package beheer repositories (meer dan 10.000 daarvan!) met gitolite, en het is daarbij waarschijnlijk ook nog eens de grootste gitolite installatie waar dan ook.
+Gitolite is een autorisatie-laag boven op Git, waar op ` sshd` of `httpd` wordt vertrouwd voor authenticatie. (Recapitulatie: authenticatie is het identificeren wie de gebruiker is, autoriseren is het besluiten of hetgeen wat deze gebruiker probeert te doen toegestaan is).
 
 Gitolite stelt je in staat de permissies niet alleen per repository, maar ook per branch of tag naam binnen elke repository. Dus, je kunt aangeven dat bepaalde mensen (of groepen van mensen) alleen maar bepaalde "refs" (branches of tags) kunnen pushen maar niet andere.
 
 ### Installatie ###
 
-Het installeren van Gitolite is zeer eenvoudig, zelfs als je de uitgebreide documentatie, dat erbij geleverd wordt, niet leest. Je hebt een account op een Unix(achtige) server nodig; verschillende Linux smaken en Solaris 10 zijn getest. Je hebt geen root toegang nodig, aangenomen dat git, perl, en een openssh compatible ssh server al zijn geïnstalleerd. In de onderstaande voorbeelden zullen we het `gitolite` account gebruiken op een host genaamd `gitserver`.
-
-Gitolite is nogal ongebruikelijk in de zin van "server" software -- toegang gaat via ssh, en elke userid op de server is in potentie een "gitolite host". Met als gevolg dat er een notie is van "installeren" van de software zelf, en dan het "opzetten" van een gebruiker als een "gitolist host".
-
-Gitolite heeft 4 wijzen van installeren. Mensen die Fedora of Debian systemen gebruiken kunnen een RPM of DEB ophalen en deze installeren. Mensen met root toegang kunnen het handmatig installeren. Met deze twee methoden kan elke gebruiker op het systeem een "gitolite host" worden.
-
-Mensen zonder root toegang kunnen het installeren binnen hun eigen user id. En als laatste: gitlite kan geïnstalleerd worden door een script te starten *op het werkstation*, vanuit een bash-shell. (Zelfs de bash die meegeleverd wordt met msysgit volstaat, voor het geval je je dat afvroeg.)
-
-We zullen dit laatste in dit stuk beschrijven, voor de overige methoden verwijzen we je naar de documentatie.
-
-Je begint met het verkrijgen van toegang naar je server op basis van een publieke sleutel, zodat je vanaf je werkstation op de server kan inloggen zonder het intypen van je wachtwoord. De volgende methode werkt op Linux; voor andere werkstation besturingssystemen moet je dit wellicht handmatig doen. We gaan er vanuit dat je al een sleutelpaar hebt gegenereerd met `ssh-keygen`.
-
-	$ ssh-copy-id -i ~/.ssh/id_rsa gitolite@gitserver
+Het installeren van Gitolite is zeer eenvoudig, zelfs als je de uitgebreide documentatie, dat erbij geleverd wordt, niet leest. Je hebt een account op een Unix(achtige) server nodig. Je hebt geen root toegang nodig, aangenomen dat Git, perl, en een OpenSSH compatible SSH server al zijn geïnstalleerd. In de onderstaande voorbeelden zullen we het `git` account gebruiken op een host genaamd `gitserver`.
 
-Dit zal je vragen naar een wachtwoord naar het gitolite account, en dan de publieke sleutel toegang opzetten. Dit is **absoluut noodzakelijk** voor het installatiescript, dus controleer dit om er zeker van te zijn dat je een commando kan laten lopen zonder een wachtwoord te hoeven in typen.
+Gitolite is nogal ongebruikelijk in de zin van "server" software - toegang gaat via SSH, en elke userid op de server is in potentie een "Gitolite host". We zullen de eenvoudigste installatie methode beschrijven in dit artikel. Voor de overige methodes verwijzen we je naar de documentatie.
 
-	$ ssh gitolite@gitserver pwd
-	/home/gitolite
+Om te beginnen: maak een gebruiker genaamd `git` aan op je server en log met deze gebruiker in. Kopieer je SSH publieke sleutel (een bestand genaamd `~/.ssh/id_rsa.pub` als je een gewone `ssh-keygen` met alle standaardwaarden gedaan hebt) van je werkstation, en hernoem deze naar `<jouwnaam>.pub` (we zullen `scott.pub` gebruiken in onze voorbeelden). En voer dan deze commando's  uit:
 
-Vervolgens, clone je Gitolite van de hoofdsite van het project en roept de "easy install" script aan (het derde argument is jouw naam zoals je deze in de resulterende gitolite-admin repository wilt laten verschijnen):
+	$ git clone git://github.com/sitaramc/Gitolite
+	$ Gitolite/install -ln
+	    # assumes $HOME/bin exists and is in your $PATH
+	$ Gitolite setup -pk $HOME/scott.public
 
-	$ git clone git://github.com/sitaramc/gitolite
-	$ cd gitolite/src
-	$ ./gl-easy-install -q gitolite gitserver sitaram
+Dat laatste commando maakt een nieuwe Git repostory genaamd `Gitolite-admin` op de server aan.
 
-En dat is het! Gitolite is nu geïnstalleerd op je server, en je hebt nu een gloednieuwe repository genaamd `gitolite-admin` in de home directory van jouw werkstation. Je beheert je gitolite setup door een wijziging aan te brengen in deze reporitory en deze te pushen.
-
-Dat laatste commando produceert redelijk wat uitvoer, dat wellicht interessant is om te lezen. Ook wordt er, de eerste keer dat je het commando laat lopen, er een nieuwe sleutelpaar gemaakt; je moet een wachtwoord kiezen of Enter als je er geen wilt. Waarom een tweede sleutelpaar nodig is, en hoe deze wordt gebruikt, wordt uitgelegd in het "ssh troubleshooting" document dat bij Gitolite wordt meegeleverd. (Hey, de documentatie moet *ergens* goed voor zijn!)
-
-Repositories genaamd `gitolite-admin` en `testing` worden standaard op de server aangemaakt. Als je een van beide lokaal wilt clonen (van een account die SSH console toegang heeft naar het gitolite account via *authorized_keys*) type je:
-
-	$ git clone gitolite:gitolite-admin
-	$ git clone gitolite:testing
-	
-Om deze zelfde repositories te clonen van een willekeurige ander account:
-
-	$ git clone gitolite@servername:gitolite-admin
-	$ git clone gitolite@servername:testing
+Als laatste, terug op jouw werkstation, voer je het commando `git clone git@gitserver:Gitolite-admin` uit. En klaar is Kees! Gitolite is nu geinstalleerd op de server, en jij hebt nu een gloednieuwe repository genaamd `Gitolite-admin` op jouw werkstation. Jij beheert je Gitolite opstelling door veranderingen in deze repository te maken en die te pushen.
 
 ### De Installatie Aanpassen ###
 
-Hoewel de standaard, snelle, installatie werkt voor de meeste mensen, zijn er een aantal manieren om de installatie aan te passen als dat nodig is. Als je het `-q` argument weg laat, krijg je een "verbose" installatie wijze -- gedetaileerde informatie over wat de installatie aan het doen is bij elke stap. De verbose wijze staat je ook toe om bepaalde server-side parameters aan te passen, zoals de locatie van de eigenlijke repositories, door het wijzigen van een "rc" bestand dat de server gebruikt. Dit "rc" bestand is ruimhartig van commentaar voorzien dus je zou in staat moeten zijn om elke wijziging die je nodig vindt vrij snel te maken, op te slaan en door te gaan. Dit bestand bevat ook enkele instellingen die je kunt aanpassen om de meer geavanceerde functies van gitolite aan of uit te zetten.
+Hoewel de standaard, snelle, installatie werkt voor de meeste mensen, zijn er een aantal manieren om de installatie aan te passen als dat nodig is. Sommige wijzigingen kunnen simpleweg gemaakt worden door het rc bestand te wijzigen, maar als dat niet volstaat is er documentatie over het aanpassen van Gitolite beschikbaar.
 
 ### Config bestand en Beheer van Toegangsregels ###
 
-Zodra de installatie afgerond is, schakel je over naar de `gitolite-admin` repository (die staat in je HOME directory) en begin je rond te snuffelen om te zien wat je daar hebt:
+Zodra de installatie afgerond is, schakel je over naar de `Gitolite-admin` repository die je zojuist op je werkstation gemaakt hebt, en begin je rond te snuffelen om te zien wat je daar hebt:
 
-	$ cd ~/gitolite-admin/
+	$ cd ~/Gitolite-admin/
 	$ ls
 	conf/  keydir/
 	$ find conf keydir -type f
-	conf/gitolite.conf
-	keydir/sitaram.pub
-	$ cat conf/gitolite.conf
-	#gitolite conf
-	# please see conf/example.conf for details on syntax and features
+	conf/Gitolite.conf
+	keydir/scott.pub
+	$ cat conf/Gitolite.conf
 
-	repo gitolite-admin
-	    RW+                 = sitaram
+	repo Gitolite-admin
+	    RW+                 = scott
 
 	repo testing
 	    RW+                 = @all
 
-Merk op dat "sitaram" (het laatste argument in het `gl-easy-install` commando dat je eerder gegeven hebt) lees en schrijf rechten heeft op de `gitolite-admin` repository en een publiek sleutelbestand met dezelfde naam.
+Merk op dat "scott" (de naam van de pubkey in het `Gitolite setup` commando dat je eerder gebruikt hebt) lees- en schrijfrechten heeft op de `Gitolite-admin` repository en een publiek sleutelbestand met dezelfde naam.
 
-De syntax van het config bestand voor gitolite is ruimhartig van documentatie voorzien in `conf/example.conf`, dus we zullen alleen wat hoofdpunten benoemen.
+Gebruikers toevoegen is eenvoudig. Om een gebruiker genaamd "alice" toe te voegen, verkrijg haar publieke sleutel, noem deze `alice.pub`, en zet deze in de `keyir` directory van de clone van de `Gitolite-admin` repositroy die je zojuist op je werkstation gemaakt hebt. Voeg de wijziging toe, commit en push de wijziging en de gebruiker is toegevoegd.
+
+De syntax van het config bestand voor Gitolite is ruimhartig van documentatie voorzien in, dus we zullen ons beperken tot wat hoofdpunten.
 
 Je kunt voor het gemak gebruikers of repositories groeperen. De groepnamen zijn vergelijkbaar met macros: als je ze definieert maakt het niet uit of het projecten of gebruikers zijn. Dat onderscheid wordt pas gemaakt als je de "macro" gaat *gebruiken*.
 
-	@oss_repos      = linux perl rakudo git gitolite
+	@oss_repos      = linux perl rakudo git Gitolite
 	@secret_repos   = fenestra pear
 
-	@admins         = scott     # Adams, not Chacon, sorry :)
-	@interns        = ashok     # get the spelling right, Scott!
+	@admins         = scott
+	@interns        = ashok
 	@engineers      = sitaram dilbert wally alice
 	@staff          = @admins @engineers @interns
 
@@ -600,26 +618,26 @@ Je kunt de permissies beheren op het "ref" niveau. In het volgende voorbeeld kun
 	    RW  refs/tags/rc[0-9]   = @engineers
 	    RW+                     = @admins
 
-De expressie achter de `RW` of `RW+` is een zgn. regular expression (regex) waartegen de refname (ref) die wordt gepushed wordt vergeleken. Dus we gaan we deze uiteraard een "refex" noemen! En natuurlijk kan een refex veel krachtiger zijn dan hier wordt getoond, dus ga het niet overdrijven als je niet al te goed in de perl regexen zit.
+De expressie achter de `RW` of `RW+` is een zgn. regular expression (regex) waartegen de refname (ref) die wordt gepusht wordt vergeleken. Dus we gaan we deze uiteraard een "refex" noemen! En natuurlijk kan een refex veel krachtiger zijn dan hier wordt getoond, dus ga het niet overdrijven als je niet al te goed in de Perl regexen zit.
 
 Zoals je wellicht al geraden hebt, gebruikt Gitolite de prefix `refs/heads/` als een syntactische handigheid indien de refex niet begint met `refs/`.
 
 Een belangrijke eigenschap van de syntax van het config bestand is dat alle regels van een repository niet op één plek hoeft te staan. Je kunt al het generieke spul bij elkaar houden, zoals de regels voor alle `oss_repos` zoals ze hier boven staan, en dan op een latere plaats specifieke regels voor specifieke gevallen, zoals hier:
 
-	repo gitolite
+	repo Gitolite
 	    RW+                     = sitaram
 
-Deze regel wordt gewoon toegevoegd aan de set met regels voor de `gitolite` repository.
+Deze regel wordt gewoon toegevoegd aan de set met regels voor de `Gitolite` repository.
 
 Je zou je op dit punt kunnen afvragen hoe de toegangsregels eigenlijk worden toegepast, laten we dat kort behandelen.
 
-Er zijn twee niveaus van toegangsbeheer in gitolite. De eerste is op repository niveau. Als je lees- of schrijfrechten hebt tot *enige* ref in de repository, dan heb je lees (of schrijf) rechten tot de repository.
+Er zijn twee niveaus van toegangsbeheer in Gitolite. De eerste is op repository niveau. Als je lees- of schrijfrechten hebt tot *enige* ref in de repository, dan heb je lees (of schrijf)rechten tot de repository. Dit is de enige toegangsbeheer dat Gitosis had.
 
 Het tweede niveau, alleen van toepassing voor "schrijf" toegang, is per branch of tag binnen een repository. De gebruikersnaam, het type toegang wat wordt gevraagd (`W` of '+'), en de refname dat wordt gewijzigd (geüpdate) zijn bekend. De toegangsregels worden gecontroleerd in volgorde van voorkomst in het config bestand, en er wordt gekeken naar een treffer voor deze combinatie (maar onthoudt dat de refname middels een regex wordt vergeleken, niet een simpele string-vergelijking). Als er een treffer is, dan slaagt de push. Als er geen treffer wordt gevonden (fallthrough) dan wordt toegang geweigerd.
 
 ### Geavanceerde Toegangs Controle met "deny" regels ###
 
-Tot zover hebben we alleen permissies gezien uit het rijtje `R`, `RW` of `RW+`. Echter, gitolite kent een andere permissie: `-`, wat staat voor "deny" (ontken). Dit geeft je veel meer macht, tegen kosten van wat hogere complexiteit omdat een fallthrough nu niet de *enige* manier is waarop toegang kan worden geweigerd; nu wordt *de volgorde van regels belangrijk*!
+Tot zover hebben we alleen permissies gezien uit het rijtje `R`, `RW` of `RW+`. Echter, Gitolite kent een andere permissie: `-`, wat staat voor "deny" (ontken). Dit geeft je veel meer macht, tegen kosten van wat hogere complexiteit omdat een fallthrough nu niet de *enige* manier is waarop toegang kan worden geweigerd; nu wordt *de volgorde van regels belangrijk*!
 
 Stel dat, in de onderstaande situatie, we de techneuten in staat willen stellen elke branch te laten terugdraaien *behalve* master en integ. Dit is de manier om dat te doen:
 
@@ -631,43 +649,39 @@ Nogmaals, je hoeft slechts de regels van boven naar beneden af te lopen tot je e
 
 ### Beperken van pushes bij gewijzigde bestanden ###
 
-Bovenop het beperken van gebruikersrechten op branches voor een gebruiker, kan je ook de rechten van gebruikers beperken op bestanden. Als voorbeeld, misschien is de Makefile (of een ander programma) niet echt bedoeld om te worden gewijzigd door iedereen, omdat een groot aantal dingen afhankelijk ervan zijn of omdat het stuk loopt als de wijzigingen niet *precies goed* gebeuren. Je kunt het gitolite duidelijk maken:
+Bovenop het beperken van pushrechten op branches voor een gebruiker, kan je ook de rechten van gebruikers beperken op bestanden. Als voorbeeld, misschien is de Makefile (of een ander programma) niet echt bedoeld om door iedereen te worden gewijzigd, omdat een groot aantal dingen afhankelijk ervan zijn of omdat het stuk loopt als de wijzigingen niet *precies goed* gebeuren. Je kunt het Gitolite duidelijk maken:
 
     repo foo
-        RW                  =   @junior_devs @senior_devs
+        RW                      =   @junior_devs @senior_devs
 
-        RW  NAME/           =   @senior_devs
-        -   NAME/Makefile   =   @junior_devs
-        RW  NAME/           =   @junior_devs
+        -   VREF/NAME/Makefile  =   @junior_devs
 
-Deze krachtige eigenschap is gedocumenteerd in `conf/example.conf`.
+Gebruikers die migreren van de oudere versie van Gitolite moeten opmerken dat er een significant verschil in het gedrag wat betreft deze eigenschap; zie de migratiegids voor meer details.
 
 ### Persoonlijke branches ###
 
 Gitolite heeft ook een mogelijkheid van "persoonlijke branches" (of liever gezegd "persoonlijke branch namespace") wat erg nuttig kan zijn in een bedrijfssituatie.
 
-Veel van de code-uitwisselingen in de git-wereld verlopen via zgn. "please pull" aanvragen. In een bedrijfsomgeving echter is ongeauthoriseerde toegang taboe, en het werkstation van een ontwikkelaar kan geen authenticatie doen, dus je moet naar de centrale server pushen en iemand vragen daarvandaan te pullen.
+Veel van de code-uitwisselingen in de Git-wereld verlopen via zgn. "please pull" aanvragen. In een bedrijfsomgeving echter is ongeauthoriseerde toegang taboe, en het werkstation van een ontwikkelaar kan geen authenticatie doen, dus je moet naar de centrale server pushen en iemand vragen daarvandaan te pullen.
 
 Dit zou normaalgesproken een gelijksoortige branch-brij veroorzaken als in een gecentraliseerde versiebeheersysteem, en daarbij wordt het opzetten van permissies een vervelende klus voor de administrator.
 
-Gitolite stelt je in staat een "personal" of "scratch" namespace prefix voor elke ontwikkelaar te definiëren (bijvoorbeeld `refs/personal/<devname>/*`); zie ook de "personal branches" paragraaf in `doc/3-faq-tips-etc.mkd` voor details.
+Gitolite stelt je in staat een "personal" of "scratch" namespace prefix voor elke ontwikkelaar te definiëren (bijvoorbeeld `refs/personal/<devname>/*`); we verwijzen naar de documentatie voor details.
 
 ### "Wildcard" repositores ###
 
-Gitolite laat je repositories specificeren met wildcards (eigenlijk perl regex expressies), zoals bijvoorbeeld `assignments/s[0-9][0-9]/a[0-9][0-9]`, om maar een willekeurig voorbeeld te nemen. Dit is een *heel* krachtige eigenschap die wordt aangezet door de regel `$GL_WILDREPOS = 1;` in het rc bestand. Het laat je een nieuwe permissiewijze ("C") toe te wijzen welke gebruikers in staat stelt repositories aan te maken die voldoen aan zulke wildcards, automatisch eigenaarsschap toe te wijzen aan de gebruiker die hem heeft aangemaakt, staat deze gebruiker toe om "R" en "RW" permissies aan anderen toe te wijzen om samen te werken, etc. Deze eigenschap is beschreven in `doc/4-wildcard-repositories.mkd`.
+Gitolite laat je repositories specificeren met wildcards (eigenlijk Perl regex expressies), zoals bijvoorbeeld `assignments/s[0-9][0-9]/a[0-9][0-9]`, om maar een willekeurig voorbeeld te nemen. Dit stelt je in staat om een nieuwe permissie modus (`C`) toe te wijzen die gebruikers in staat stelt repositories te maken op basis van zulk wildcards, automatisch eigenaarschap toe te wijzen aan de gebruiker die hem heeft aangemaakt, staat deze gebruiker toe om "R" en "RW" permissies aan anderen toe te wijzen om samen te werken, etc. Nogmaals: zie de documentatie voor meer details.
 
 ### Andere eigenschappen ###
 
-We ronden deze uiteenzetting af met een passe partout van andere eigenschappen, welke alle (en nog vele andere) tot in de kleinste detail zijn beschreven in de "faqs, tips, etc" en andere documenten.
+We ronden deze uiteenzetting af met een passe partout van andere eigenschappen, welke alle (en nog vele andere) tot in de kleinste detail zijn beschreven in de documentatie.
 
 **Logging**: Gitolite logt alle succesvolle toegangspogingen. Als je wat te los bent geweest in het toekennen van terugdraai permissies (`RW+`) en een of andere bijdehand heeft "master" vernaggelt, is de log-file een redder in de nood in de zin van snel en eenvoudig achterhalen van de SHA die verdwenen is.
 
-**Git buiten reguliere PATH**: Een ontzettend handige eigenschap in gitolite is het ondersteunen van Git buiten het regulier `$PATH` (dit komt vaker voor dan je zou denken, sommige bedrijfs omgevingen of zelfs sommige hosting providers weigeren dingen systeem-breed te installeren en je eindigt ermee dat je ze in je eigen directories zet). Normaalgesproken ben je gedwongen Git aan de *client-side* op de een of andere manier te vertellen van deze niet-standaard locatie van de git binaries. Met gitolite hoe je alleen een verbose installatie te kiezen en `$GIT_PATH` in de "rc" bestanden in te vullen. Hierna geen wijzigingen aan de kant van de clients nodig :-)
-
 **Rapportage van toegangsrechten**: Nog zo'n handige eigenschap is wat er gebeurt als je gewoon met ssh naar de server gaat. Gitolite laat zien welke repositories je toegang toe hebt en welke soort toegang dat dan is. Hier is een voorbeeld:
 
-        hello sitaram, the gitolite version here is v1.5.4-19-ga3397d4
-        the gitolite config gives you the following access:
+        hello scott, this is git@git running gitolite3 v3.01-18-g9609868 on git 1.7.4.4
+
              R     anu-wsd
              R     entrans
              R  W  git-notes
@@ -676,9 +690,7 @@ We ronden deze uiteenzetting af met een passe partout van andere eigenschappen,
              R     indic_web_input
              R     shreelipi_converter
 
-**Delegeren**: Voor extreem grote installaties kan je de verantwoordelijkheid voor groepen van repositories delegeren aan verschillende mensen en hen het beheer van die delen onafhankelijk laten regelen. Dit vermindert de werkdruk van de hoofd-beheerder, en maakt van hem minder een faalpunt. Deze eigenschap heeft zijn eigen documentatie in de `doc/` directory.
-
-**Gitweb ondersteuning**: Gitolite ondersteunt gitweb op verschillende manieren. Je kunt aangeven welke repositories zichtbaar zijn via gitweb. Je kunt de "owner" (eigenaar) en "description" (omschrijving) voor gitweb vanuit de gitolite configuratie bestanden definiëren. Gitweb heeft een mechanisme beschikbaar waarmee toegang via HTTP wordt geïmplementeerd, deze kan je het "gecompileerde" config bestand van de gitolite config file laten gebruiken, wat inhoudt dat gitweb en gitolite dezelfde toegangsregels gebruiken (voor lees toegang).
+**Delegeren**: Voor extreem grote installaties kan je de verantwoordelijkheid voor groepen van repositories delegeren aan verschillende mensen en hen het beheer van die delen onafhankelijk laten regelen. Dit vermindert de werkdruk van de hoofd-beheerder, en maakt van hem minder een faalpunt. 
 
 **Mirroring**: Gitolite kan je ondersteunen bij het beheren van meerdere mirrors, en het eenvoudig daartussen overschakelen als de primaire server uitvalt.
 
@@ -722,7 +734,7 @@ Vervolgens zul je je Gitosis server moeten vertellen welke repositories je onaut
 	[repo iphone_project]
 	daemon = yes
 
-Als dat gecommit en gepushed is, dan zou de draaiende daemon verzoeken moeten serveren aan iedereen die toegang heeft op poort 9418 van je server.
+Als dat gecommit en gepusht is, dan zou de draaiende daemon verzoeken moeten serveren aan iedereen die toegang heeft op poort 9418 van je server.
 
 Als je besluit om Gitosis niet te gebruiken, maar je wilt toch een Git daemon instellen, dan moet je dit op ieder project uitvoeren waarvoor je de Git daemon wilt laten serveren:
 
@@ -744,9 +756,9 @@ Je kunt instellen welke projecten GitWeb gebruikers laat bladeren door een `gitw
 	daemon = yes
 	gitweb = yes
 
-Als je nu het project commit en pushed, begint GitWeb automatisch je iphone project te tonen.
+Als je nu het project commit en pusht, begint GitWeb automatisch je `iphone_project` te tonen.
 
-## Hosted Git ##
+## Gehoste Git ##
 
 Als je niet al het werk wilt doen om je eigen Git server op te zetten, heb je meerdere opties om je Git project op een externe speciale hosting pagina te laten beheren. Dit biedt een aantal voordelen: een ge-hoste pagina is over het algemeen snel in te stellen, eenvoudig om projecten mee op te starten, en er komt geen serverbeheer en -onderhoud bij kijken. Zelfs als je je eigen server intern opgezet hebt, zul je misschien een publieke host pagina voor je open source broncode willen – dat is over het algemeen makkelijker voor de open source commune te vinden en je er mee te helpen.
 
@@ -812,7 +824,7 @@ Als je een lokaal Git repository hebt, voeg dan GitHub als remote toe en push je
 	$ git remote add origin git@github.com:testinguser/iphone_project.git
 	$ git push origin master
 
-Nu wordt je project beheerd op GitHub, en kun je de URL aan iedereen geven waarmee je je project wilt delen. In dit geval is het `http://githup.com/testinguser/iphone_project`. Je kunt aan het begin van elk van je project pagina's zien dat je twee Git URLs hebt (zie Figuur 4-8).
+Nu wordt je project gehost op GitHub, en kun je de URL aan iedereen geven waarmee je je project wilt delen. In dit geval is het `http://githup.com/testinguser/iphone_project`. Je kunt aan het begin van elk van je project pagina's zien dat je twee Git URLs hebt (zie Figuur 4-8).
 
 Insert 18333fig0408.png
 Figuur 4-8. Project met een publieke URL en een privé URL.
@@ -853,18 +865,18 @@ Als je toegang van individuen moet intrekken, dan kun je de "revoke" link klikke
 
 ### Je project ###
 
-Nadat je je project gepushed hebt, of geïmporteerd vanuit Subversion, heb je een hoofd project pagina die er uitziet zoals Figuur 4-13.
+Nadat je je project gepusht hebt, of geïmporteerd vanuit Subversion, heb je een hoofd project pagina die er uitziet zoals Figuur 4-13.
 
 Insert 18333fig0413.png
 Figuur 4-13. Een GitHub project hoofdpagina.
 
-Als mensen je project bezoeken, zien ze deze pagina. Het bevat tabs naar de verschillende aspecten van je projecten. De Commits tab laat een lijst van commits in omgekeerde chronologische volgorde zien, vergelijkbaar met de output van het `git log` commando. De Network tab toont alle mensen die je project hebben geforked en bijgedragen hebben. De Downloads tab staat je toe project binaries te uploaden en naar tarballs en gezipte versies van ieder getagged punt in je project te linken. De Wiki tab voorziet in een wiki waar je documentatie kunt schrijven of andere informatie over je project. De Graphs tab heeft wat contributie visualisaties en statistieken over je project. De hoofd Source tab waarop je binnen komt, toont de inhoud van de hoofdmap van je project en toont automatisch het README bestand eronder als je er een hebt. Deze tab toont ook een veld met de laatste commit informatie.
+Als mensen je project bezoeken, zien ze deze pagina. Het bevat tabs naar de verschillende aspecten van je projecten. De Commits tab laat een lijst van commits in omgekeerde chronologische volgorde zien, vergelijkbaar met de output van het `git log` commando. De Network tab toont alle mensen die je project hebben geforked en bijgedragen hebben. De Downloads tab staat je toe project binaries te uploaden en naar tarballs en gezipte versies van ieder getagged punt in je project te linken. De Wiki tab voorziet in een wiki waar je documentatie kunt schrijven of andere informatie over je project. De Graphs tab heeft wat contributie visualisaties en statistieken over je project. De hoofd Source tab waarop je binnen komt, toont de inhoud van de hoofddirectory van je project en toont automatisch het README bestand eronder als je er een hebt. Deze tab toont ook een veld met de laatste commit informatie.
 
 ### Projecten forken ###
 
-Als je aan een bestaand project waarop je geen push toegang hebt wilt bijdragen, dan moedigt GitHub het forken van een project toe. Als je op een project pagina belandt, die interessant lijkt en je wilt er een beetje op hacken, dan kun je de "fork" knop klikken aan de bovenkant van het project om GitHub dat project te laten kopiëren naar jouw gebruiker zodat je er naar kunt pushen.
+Als je aan een bestaand project waarop je geen push toegang hebt wilt bijdragen, dan moedigt GitHub het forken van een project toe. Als je op een project pagina belandt die interessant lijkt en je wilt er een beetje op hacken, dan kun je de "fork" knop klikken aan de bovenkant van het project om GitHub dat project te laten kopiëren naar jouw gebruiker zodat je er naar kunt pushen.
 
-Op deze manier hoeven projecten zich geen zorgen te maken over het toevoegen van medewerkers om ze push toegang te geven. Mensen kunnen een project forken en ernaar pushen, en de hoofdeigenaar van het project kan die wijzigingen pullen door ze als remotes toe te voegen en hun werk te mergen.
+Op deze manier hoeven projecten zich geen zorgen te maken over het toevoegen van medewerkers om ze push toegang te geven. Mensen kunnen een project forken en ernaar pushen, en de hoofdbeheerder van het project kan die wijzigingen pullen door ze als remotes toe te voegen en hun werk te mergen.
 
 Om een project te forken, bezoek dan de project pagina (in dit geval, mojombo/chronic) en klik de "fork" knop aan de bovenkant (zie Figuur 4-14).
 

From cc729707a2fbf8300fc3790858800f1985b2e814 Mon Sep 17 00:00:00 2001
From: cor <git@cpt1.demon.nl>
Date: Sat, 15 Feb 2014 16:19:44 +0100
Subject: [PATCH 228/690] [nl] Chapter04 Start trying to beat Maruku test...

---
 nl/04-git-server/01-chapter4.markdown | 1 +
 1 file changed, 1 insertion(+)

diff --git a/nl/04-git-server/01-chapter4.markdown b/nl/04-git-server/01-chapter4.markdown
index d87310e71..6f5891a9e 100644
--- a/nl/04-git-server/01-chapter4.markdown
+++ b/nl/04-git-server/01-chapter4.markdown
@@ -1,3 +1,4 @@
+
 <!-- Attentie heren en dames vertalers.
 Ik zou het volgende willen voorstellen:
 Er zijn bepaalde termen die voor de gemiddelde Nederlandse computer gebruiker 

From 9bb32f5881c3577ac74d4c5a5e4706ffde6f9bff Mon Sep 17 00:00:00 2001
From: Jean-Noel Avila <jn.avila@free.fr>
Date: Sat, 15 Feb 2014 22:38:41 +0100
Subject: [PATCH 229/690] Fix concatenation of file contents with 2 CR

The markdown files may not end with a '\n'. This would lead to
concatenating the last line of a previous file with the first line of
the next one.
---
 Rakefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Rakefile b/Rakefile
index 8e8f9eac3..45fb7c16c 100644
--- a/Rakefile
+++ b/Rakefile
@@ -212,7 +212,7 @@ def test_lang(lang, out)
   end
   begin
     mark = (source_files.map{|mk_filename| File.open(mk_filename, 'r'){
-                |mk| mk.read.encode("UTF-8")}}).join('')
+                |mk| mk.read.encode("UTF-8")}}).join('\n\n')
     require 'maruku'
     code = Maruku.new(mark, :on_error => :raise, :error_stream => StderrDecorator.new(out))
   rescue

From 26062b667f45e0de6ea95464eecc6c04562c403a Mon Sep 17 00:00:00 2001
From: Jean-Noel Avila <jn.avila@free.fr>
Date: Sat, 15 Feb 2014 22:50:08 +0100
Subject: [PATCH 230/690] fix Ci testing

The concatenation of files is still not correct. Fix it.
---
 Rakefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Rakefile b/Rakefile
index 607be5cd2..3f017b42b 100644
--- a/Rakefile
+++ b/Rakefile
@@ -212,7 +212,7 @@ def test_lang(lang, out)
   end
   begin
     mark = (source_files.map{|mk_filename| File.open(mk_filename, 'r'){
-                |mk| mk.read.encode("UTF-8")}}).join('\n\n')
+                |mk| mk.read.encode("UTF-8")}}).join("\n\n")
     require 'maruku'
     code = Maruku.new(mark, :on_error => :raise, :error_stream => StderrDecorator.new(out))
   rescue

From 5c00b3586d1195496d19379feb1944e6127fbbeb Mon Sep 17 00:00:00 2001
From: Jean-Noel Avila <jn.avila@free.fr>
Date: Sat, 15 Feb 2014 23:03:57 +0100
Subject: [PATCH 231/690] Fix test in case of non-parallel run

All the tested languages must be mapped to their test result.
---
 Rakefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Rakefile b/Rakefile
index 3f017b42b..d5d31dd16 100644
--- a/Rakefile
+++ b/Rakefile
@@ -264,7 +264,7 @@ namespace :ci do
       end
       langs -= excluded_langs
     end
-    errors = langs.each do |lang|
+    errors = langs.map do |lang|
       print "processing #{lang} "
       error_code=test_lang(lang, $out)
       if error_code

From a6283fa157a657a982c2e41505154fc81e5dbc5e Mon Sep 17 00:00:00 2001
From: harupong <harupong@gmail.com>
Date: Mon, 3 Feb 2014 09:43:49 +0900
Subject: [PATCH 232/690] [ja] Apply #648 to ja tree

---
 ja/03-git-branching/01-chapter3.markdown | 100 ++++++++++++-----------
 1 file changed, 54 insertions(+), 46 deletions(-)

diff --git a/ja/03-git-branching/01-chapter3.markdown b/ja/03-git-branching/01-chapter3.markdown
index e674e1d5f..240042ab2 100644
--- a/ja/03-git-branching/01-chapter3.markdown
+++ b/ja/03-git-branching/01-chapter3.markdown
@@ -117,7 +117,7 @@ Insert 18333fig0310.png
 ここで、あなたの勤務先で使っている何らかの問題追跡システムに登録されている問題番号 53 への対応を始めることにしました。念のために言っておくと、Git は何かの問題追跡システムと連動しているわけではありません。しかし、今回の作業はこの問題番号 53 に対応するものであるため、作業用に新しいブランチを作成します。ブランチの作成と新しいブランチへの切り替えを同時に行うには、`git checkout` コマンドに `-b` スイッチをつけて実行します。
 
 	$ git checkout -b iss53
-	Switched to a new branch "iss53"
+	Switched to a new branch 'iss53'
 
 これは、次のコマンドのショートカットです。
 
@@ -142,18 +142,18 @@ Insert 18333fig0312.png
 しかしその前に注意すべき点があります。作業ディレクトリやステージングエリアに未コミットの変更が残っている場合、それがもしチェックアウト先のブランチと衝突する内容ならブランチの切り替えはできません。ブランチを切り替える際には、クリーンな状態にしておくのが一番です。これを回避する方法もあります (stash およびコミットの amend という処理です) が、また後ほど説明します。今回はすべての変更をコミットし終えているので、master ブランチに戻ることができます。
 
 	$ git checkout master
-	Switched to branch "master"
+	Switched to branch 'master'
 
 作業ディレクトリは問題番号 53 の対応を始める前とまったく同じ状態に戻りました。これで、緊急の問題対応に集中できます。ここで覚えておくべき重要な点は、Git が作業ディレクトリの状態をリセットし、チェックアウトしたブランチが指すコミットの時と同じ状態にするということです。そのブランチにおける直近のコミットと同じ状態にするため、ファイルの追加・削除・変更を自動的に行います。
 
 次に、緊急の問題対応を行います。緊急作業用に hotfix ブランチを作成し、作業をそこで進めるようにしましょう (図 3-13 を参照ください)。
 
 	$ git checkout -b hotfix
-	Switched to a new branch "hotfix"
+	Switched to a new branch 'hotfix'
 	$ vim index.html
 	$ git commit -a -m 'fixed the broken email address'
-	[hotfix]: created 3a0874c: "fixed the broken email address"
-	 1 files changed, 0 insertions(+), 1 deletions(-)
+	[hotfix 3a0874c] fixed the broken email address
+	 1 files changed, 1 deletion(-)
 
 Insert 18333fig0313.png
 図 3-13. master ブランチから新たに作成した hotfix ブランチ
@@ -163,11 +163,11 @@ Insert 18333fig0313.png
 	$ git checkout master
 	$ git merge hotfix
 	Updating f42c576..3a0874c
-	Fast forward
-	 README |    1 -
-	 1 files changed, 0 insertions(+), 1 deletions(-)
+	Fast-forward
+	 README | 1 -
+	 1 file changed, 1 deletion(-)
 
-このマージ処理で "Fast forward" というフレーズが登場したのにお気づきでしょうか。マージ先のブランチが指すコミットがマージ元のコミットの直接の親であるため、Git がポインタを前に進めたのです。言い換えると、あるコミットに対してコミット履歴上で直接到達できる別のコミットをマージしようとした場合、Git は単にポインタを前に進めるだけで済ませます。マージ対象が分岐しているわけではないからです。この処理のことを "fast forward" と言います。
+このマージ処理で "Fast-forward" というフレーズが登場したのにお気づきでしょうか。マージ先のブランチが指すコミットがマージ元のコミットの直接の親であるため、Git がポインタを前に進めたのです。言い換えると、あるコミットに対してコミット履歴上で直接到達できる別のコミットをマージしようとした場合、Git は単にポインタを前に進めるだけで済ませます。マージ対象が分岐しているわけではないからです。この処理のことを "fast forward" と言います。
 
 変更した内容が、これで `master` ブランチの指すスナップショットに反映されました。これで変更をリリースできます (図 3-14 を参照ください)。
 
@@ -177,16 +177,16 @@ Insert 18333fig0314.png
 超重要な修正作業が終わったので、横やりが入る前にしていた作業に戻ることができます。しかしその前に、まずは `hotfix` ブランチを削除しておきましょう。`master` ブランチが同じ場所を指しているので、もはやこのブランチは不要だからです。削除するには `git branch` で `-d` オプションを指定します。
 
 	$ git branch -d hotfix
-	Deleted branch hotfix (3a0874c).
+	Deleted branch hotfix (was 3a0874c).
 
 では、先ほどまで問題番号 53 の対応をしていたブランチに戻り、作業を続けましょう (図 3-15 を参照ください)。
 
 	$ git checkout iss53
-	Switched to branch "iss53"
+	Switched to branch 'iss53'
 	$ vim index.html
 	$ git commit -a -m 'finished the new footer [issue 53]'
-	[iss53]: created ad82d7a: "finished the new footer [issue 53]"
-	 1 files changed, 1 insertions(+), 0 deletions(-)
+	[iss53 ad82d7a] finished the new footer [issue 53]
+	 1 file changed, 1 insertion(+)
 
 Insert 18333fig0315.png
 図 3-15. iss53 ブランチは独立して進めることができる
@@ -199,9 +199,10 @@ Insert 18333fig0315.png
 
 	$ git checkout master
 	$ git merge iss53
-	Merge made by recursive.
-	 README |    1 +
-	 1 files changed, 1 insertions(+), 0 deletions(-)
+	Auto-merging README
+	Merge made by the 'recursive' strategy.
+	 README | 1 +
+	 1 file changed, 1 insertion(+)
 
 先ほどの `hotfix` のマージとはちょっとちがう感じですね。今回の場合、開発の歴史が過去のとある時点で分岐しています。マージ先のコミットがマージ元のコミットの直系の先祖ではないため、Git 側でちょっとした処理が必要だったのです。ここでは、各ブランチが指すふたつのスナップショットとそれらの共通の先祖との間で三方向のマージを行いました。図 3-16 に、今回のマージで使用した三つのスナップショットを示します。
 
@@ -230,25 +231,27 @@ Insert 18333fig0317.png
 
 Git は新たなマージコミットを自動的には作成しませんでした。コンフリクトを解決するまで、処理は中断されます。コンフリクトが発生してマージできなかったのがどのファイルなのかを知るには `git status` を実行します。
 
-	[master*]$ git status
-	index.html: needs merge
-	# On branch master
-	# Changes not staged for commit:
-	#   (use "git add <file>..." to update what will be committed)
-	#   (use "git checkout -- <file>..." to discard changes in working directory)
-	#
-	#	unmerged:   index.html
-	#
+	$ git status
+	On branch master
+	You have unmerged paths.
+	  (fix conflicts and run "git commit")
+	
+	Unmerged paths:
+	  (use "git add <file>..." to mark resolution)
+	
+	        both modified:      index.html
+	
+	no changes added to commit (use "git add" and/or "git commit -a")
 
 コンフリクトが発生してまだ解決されていないものについては unmerged として表示されます。Git は、標準的なコンフリクトマーカーをファイルに追加するので、ファイルを開いてそれを解決することにします。コンフリクトが発生したファイルの中には、このような部分が含まれています。
 
-	<<<<<<< HEAD:index.html
+	<<<<<<< HEAD
 	<div id="footer">contact : email.support@github.com</div>
 	=======
 	<div id="footer">
 	  please contact us at support@github.com
 	</div>
-	>>>>>>> iss53:index.html
+	>>>>>>> iss53
 
 これは、HEAD (merge コマンドを実行したときにチェックアウトしていたブランチなので、ここでは master となります) の内容が上の部分 (`=======` の上にある内容)、そして `iss53` ブランチの内容が下の部分であるということです。コンフリクトを解決するには、どちらを採用するかをあなたが判断することになります。たとえば、ひとつの解決法としてブロック全体を次のように書き換えます。
 
@@ -259,12 +262,17 @@ Git は新たなマージコミットを自動的には作成しませんでし
 このような解決を各部分に対して行い、`<<<<<<<` や `=======` そして `>>>>>>>` の行をすべて除去します。そしてすべてのコンフリクトを解決したら、各ファイルに対して `git add` を実行して解決済みであることを通知します。ファイルをステージすると、Git はコンフリクトが解決されたと見なします。コンフリクトの解決をグラフィカルに行いたい場合は `git mergetool` を実行します。これは、適切なビジュアルマージツールを立ち上げてコンフリクトの解消を行います。
 
 	$ git mergetool
-	merge tool candidates: kdiff3 tkdiff xxdiff meld gvimdiff opendiff emerge vimdiff
-	Merging the files: index.html
+
+	This message is displayed because 'merge.tool' is not configured.
+	See 'git mergetool --tool-help' or 'git help config' for more details.
+	'git mergetool' will now attempt to use one of the following tools:
+	opendiff kdiff3 tkdiff xxdiff meld tortoisemerge gvimdiff diffuse diffmerge ecmerge p4merge araxis bc3 codecompare vimdiff emerge
+	Merging:
+	index.html
 
 	Normal merge conflict for 'index.html':
-	  {local}: modified
-	  {remote}: modified
+	  {local}: modified file
+	  {remote}: modified file
 	Hit return to start merge resolution tool (opendiff):
 
 デフォルトのツール (Git は `opendiff` を選びました。私がこのコマンドを Mac で実行したからです) 以外のマージツールを使いたい場合は、“merge tool candidates”にあるツール一覧を見ましょう。そして、使いたいツールの名前を打ち込みます。第 7 章で、環境にあわせてこのデフォルトを変更する方法を説明します。
@@ -274,12 +282,12 @@ Git は新たなマージコミットを自動的には作成しませんでし
 再び `git status` を実行すると、すべてのコンフリクトが解決したことを確認できます。
 
 	$ git status
-	# On branch master
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#	modified:   index.html
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        modified:   index.html
+	
 
 結果に満足し、すべてのコンフリクトがステージされていることが確認できたら、`git commit` を実行してマージコミットを完了させます。デフォルトのコミットメッセージは、このようになります。
 
@@ -288,9 +296,9 @@ Git は新たなマージコミットを自動的には作成しませんでし
 	Conflicts:
 	  index.html
 	#
-	# It looks like you may be committing a MERGE.
+	# It looks like you may be committing a merge.
 	# If this is not correct, please remove the file
-	# .git/MERGE_HEAD
+	#       .git/MERGE_HEAD
 	# and try again.
 	#
 
@@ -330,7 +338,7 @@ Git は新たなマージコミットを自動的には作成しませんでし
 先ほどのブランチとは別のブランチが表示されます。まだマージしていない作業が残っているので、このブランチを `git branch -d` で削除しようとしても失敗します。
 
 	$ git branch -d testing
-	error: The branch 'testing' is not an ancestor of your current HEAD.
+	error: The branch 'testing' is not fully merged.
 	If you are sure you want to delete it, run 'git branch -D testing'.
 
 本当にそのブランチを消してしまってよいのなら `-D` で強制的に消すこともできます。……と、親切なメッセージで教えてくれていますね。
@@ -437,8 +445,8 @@ Insert 18333fig0326.png
 この作業を現在の作業ブランチにマージするには、`git merge origin/serverfix` を実行します。ローカル環境に `serverfix` ブランチを作ってそこで作業を進めたい場合は、リモートブランチからそれを作成します。
 
 	$ git checkout -b serverfix origin/serverfix
-	Branch serverfix set up to track remote branch refs/remotes/origin/serverfix.
-	Switched to a new branch "serverfix"
+	Branch serverfix set up to track remote branch serverfix from origin.
+	Switched to a new branch 'serverfix'
 
 これで、`origin/serverfix` が指す先から作業を開始するためのローカルブランチができあがりました。
 
@@ -449,14 +457,14 @@ Insert 18333fig0326.png
 あるリポジトリをクローンしたら、自動的に `master` ブランチを作成し、`origin/master` を追跡するようになります。これが、`git push` や `git pull` が引数なしでもうまく動作する理由です。しかし、必要に応じてそれ以外の追跡ブランチを作成し、`origin` 以外にあるブランチや `master` 以外のブランチを追跡させることも可能です。シンプルな方法としては、`git checkout -b [branch] [remotename]/[branch]` を実行します。Git バージョン 1.6.2 以降では、より簡単に `--track` を使うことができます。
 
 	$ git checkout --track origin/serverfix
-	Branch serverfix set up to track remote branch refs/remotes/origin/serverfix.
-	Switched to a new branch "serverfix"
+	Branch serverfix set up to track remote branch serverfix from origin.
+	Switched to a new branch 'serverfix'
 
 ローカルブランチをリモートブランチと違う名前にしたい場合は、最初に紹介した方法でローカルブランチに別の名前を指定します。
 
 	$ git checkout -b sf origin/serverfix
-	Branch sf set up to track remote branch refs/remotes/origin/serverfix.
-	Switched to a new branch "sf"
+	Branch sf set up to track remote branch serverfix from origin.
+	Switched to a new branch 'sf'
 
 これで、ローカルブランチ `sf` が自動的に `origin/serverfix` を追跡するようになりました。
 

From b92bae54094994ce6534210a1176348481fcb267 Mon Sep 17 00:00:00 2001
From: harupong <harupong@gmail.com>
Date: Mon, 3 Feb 2014 10:09:54 +0900
Subject: [PATCH 233/690] [ja] Apply #645 to ja tree

---
 ja/02-git-basics/01-chapter2.markdown | 297 +++++++++++++-------------
 1 file changed, 152 insertions(+), 145 deletions(-)

diff --git a/ja/02-git-basics/01-chapter2.markdown b/ja/02-git-basics/01-chapter2.markdown
index 2018b9eb8..4200b6c66 100755
--- a/ja/02-git-basics/01-chapter2.markdown
+++ b/ja/02-git-basics/01-chapter2.markdown
@@ -54,8 +54,8 @@ Insert 18333fig0201.png
 どのファイルがどの状態にあるのかを知るために主に使うツールが `git status` コマンドです。このコマンドをクローン直後に実行すると、このような結果となるでしょう。
 
 	$ git status
-	# On branch master
-	nothing to commit (working directory clean)
+	On branch master
+	nothing to commit, working directory clean
 
 これは、クリーンな作業コピーである (つまり、追跡されているファイルの中に変更されているものがない) ことを意味します。また、追跡されていないファイルも存在しません (もし追跡されていないファイルがあれば、Git はそれを表示します)。最後に、このコマンドを実行するとあなたが今どのブランチにいるのかを知ることができます。現時点では常に `master` となります。これはデフォルトであり、ここでは特に気にする必要はありません。ブランチについては次の章で詳しく説明します。
 
@@ -63,11 +63,12 @@ Insert 18333fig0201.png
 
 	$ vim README
 	$ git status
-	# On branch master
-	# Untracked files:
-	#   (use "git add <file>..." to include in what will be committed)
-	#
-	#	README
+	On branch master
+	Untracked files:
+	  (use "git add <file>..." to include in what will be committed)
+	
+	        README
+
 	nothing added to commit but untracked files present (use "git add" to track)
 
 出力結果の “Untracked files” 欄に `README` ファイルがあることから、このファイルが追跡されていないということがわかります。これは、Git が「前回のスナップショット (コミット) にはこのファイルが存在しなかった」とみなしたということです。明示的に指示しない限り、Git はコミット時にこのファイルを含めることはありません。自動生成されたバイナリファイルなど、コミットしたくないファイルを間違えてコミットしてしまう心配はないということです。今回は README をコミットに含めたいわけですから、まずファイルを追跡対象に含めるようにしましょう。
@@ -81,12 +82,12 @@ Insert 18333fig0201.png
 再び status コマンドを実行すると、`README` ファイルが追跡対象となり、ステージされていることがわかるでしょう。
 
 	$ git status
-	# On branch master
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#	new file:   README
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        new file:   README
+	
 
 ステージされていると判断できるのは、“Changes to be committed” 欄に表示されているからです。ここでコミットを行うと、`git add` した時点の状態のファイルがスナップショットとして歴史に書き込まれます。先ほど `git init` をしたときに、ディレクトリ内のファイルを追跡するためにその後 `git add (ファイル)` としたことを思い出すことでしょう。`git add` コマンドには、ファイルあるいはディレクトリのパスを指定します。ディレクトリを指定した場合は、そのディレクトリ以下にあるすべてのファイルを再帰的に追加します。
 
@@ -95,58 +96,60 @@ Insert 18333fig0201.png
 すでに追跡対象となっているファイルを変更してみましょう。たとえば、すでに追跡対象となっているファイル `benchmarks.rb` を変更して `status` コマンドを実行すると、結果はこのようになります。
 
 	$ git status
-	# On branch master
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#	new file:   README
-	#
-	# Changes not staged for commit:
-	#   (use "git add <file>..." to update what will be committed)
-	#
-	#	modified:   benchmarks.rb
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        new file:   README
+
+	Changes not staged for commit:
+	  (use "git add <file>..." to update what will be committed)
+	  (use "git checkout -- <file>..." to discard changes in working directory)
+	
+	        modified:   benchmarks.rb
+	
 
 `benchmarks.rb` ファイルは “Changes not staged for commit” という欄に表示されます。これは、追跡対象のファイルが作業ディレクトリ内で変更されたけれどもまだステージされていないという意味です。ステージするには `git add` コマンドを実行します (このコマンドにはいろんな意味合いがあり、新しいファイルの追跡開始・ファイルのステージング・マージ時に衝突が発生したファイルに対する「解決済み」マーク付けなどで使用します)。では、`git add` で `benchmarks.rb` をステージしてもういちど `git status` を実行してみましょう。
 
 	$ git add benchmarks.rb
 	$ git status
-	# On branch master
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#	new file:   README
-	#	modified:   benchmarks.rb
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        new file:   README
+	        modified:   benchmarks.rb
+	
 
 両方のファイルがステージされました。これで、次回のコミットに両方のファイルが含まれるようになります。ここで、さらに `benchmarks.rb` にちょっとした変更を加えてからコミットしたくなったとしましょう。ファイルを開いて変更を終え、コミットの準備が整いました。しかし、`git status` を実行してみると何か変です。
 
 	$ vim benchmarks.rb
 	$ git status
-	# On branch master
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#	new file:   README
-	#	modified:   benchmarks.rb
-	#
-	# Changes not staged for commit:
-	#   (use "git add <file>..." to update what will be committed)
-	#
-	#	modified:   benchmarks.rb
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        new file:   README
+	        modified:   benchmarks.rb
+	
+	Changes not staged for commit:
+	  (use "git add <file>..." to update what will be committed)
+	  (use "git checkout -- <file>..." to discard changes in working directory)
+	
+	        modified:   benchmarks.rb
+	
 
 これはどういうことでしょう? `benchmarks.rb` が、ステージされているほうにもステージされていないほうにも登場しています。こんなことってありえるんでしょうか? 要するに、Git は「`git add` コマンドを実行した時点の状態のファイル」をステージするということです。ここでコミットをすると、実際にコミットされるのは `git add` を実行した時点の `benchmarks.rb` であり、`git commit` した時点の作業ディレクトリにある内容とは違うものになります。`git add` した後にファイルを変更した場合に、最新版のファイルをステージしなおすにはもう一度 `git add` を実行します。
 
 	$ git add benchmarks.rb
 	$ git status
-	# On branch master
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#	new file:   README
-	#	modified:   benchmarks.rb
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        new file:   README
+	        modified:   benchmarks.rb
+	
 
 ### ファイルの無視 ###
 
@@ -192,17 +195,18 @@ glob パターンとは、シェルで用いる簡易正規表現のようなも
 先ほどの続きで、ふたたび `README` ファイルを編集してステージし、一方 `benchmarks.rb` ファイルは編集だけしてステージしない状態にあると仮定しましょう。ここで `status` コマンドを実行すると、次のような結果となります。
 
 	$ git status
-	# On branch master
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#	new file:   README
-	#
-	# Changes not staged for commit:
-	#   (use "git add <file>..." to update what will be committed)
-	#
-	#	modified:   benchmarks.rb
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        new file:   README
+	
+	Changes not staged for commit:
+	  (use "git add <file>..." to update what will be committed)
+	  (use "git checkout -- <file>..." to discard changes in working directory)
+	
+	        modified:   benchmarks.rb
+	
 
 変更したけれどもまだステージしていない内容を見るには、引数なしで `git diff` を実行します。
 
@@ -247,16 +251,18 @@ glob パターンとは、シェルで用いる簡易正規表現のようなも
 	$ git add benchmarks.rb
 	$ echo '# test line' >> benchmarks.rb
 	$ git status
-	# On branch master
-	#
-	# Changes to be committed:
-	#
-	#	modified:   benchmarks.rb
-	#
-	# Changes not staged for commit:
-	#
-	#	modified:   benchmarks.rb
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        modified:   benchmarks.rb
+	
+	Changes not staged for commit:
+	  (use "git add <file>..." to update what will be committed)
+	  (use "git checkout -- <file>..." to discard changes in working directory)
+	
+	        modified:   benchmarks.rb
+	
 
 ここで `git diff` を使うと、まだステージされていない内容を知ることができます。
 
@@ -304,10 +310,9 @@ glob パターンとは、シェルで用いる簡易正規表現のようなも
 	# with '#' will be ignored, and an empty message aborts the commit.
 	# On branch master
 	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
 	#       new file:   README
 	#       modified:   benchmarks.rb
+	#
 	~
 	~
 	~
@@ -318,8 +323,8 @@ glob パターンとは、シェルで用いる簡易正規表現のようなも
 あるいは、コミットメッセージをインラインで記述することもできます。その場合は、`commit` コマンドの後で `-m` フラグに続けて次のように記述します。
 
 	$ git commit -m "Story 182: Fix benchmarks for speed"
-	[master]: created 463dc4f: "Fix benchmarks for speed"
-	 2 files changed, 3 insertions(+), 0 deletions(-)
+	[master 463dc4f] Fix benchmarks for speed
+	 2 files changed, 3 insertions(+)
 	 create mode 100644 README
 
 これではじめてのコミットができました! 今回のコミットについて、「どのブランチにコミットしたのか (`master`)」「そのコミットの SHA-1 チェックサム (`463dc4f`)」「変更されたファイルの数」「そのコミットで追加されたり削除されたりした行数」といった情報が表示されているのがわかるでしょう。
@@ -331,15 +336,17 @@ glob パターンとは、シェルで用いる簡易正規表現のようなも
 コミットの内容を思い通りに作り上げることができるという点でステージングエリアは非常に便利なのですが、普段の作業においては必要以上に複雑に感じられることもあるでしょう。ステージングエリアを省略したい場合のために、Git ではシンプルなショートカットを用意しています。`git commit` コマンドに `-a` オプションを指定すると、追跡対象となっているファイルを自動的にステージしてからコミットを行います。つまり `git add` を省略できるというわけです。
 
 	$ git status
-	# On branch master
-	#
-	# Changes not staged for commit:
-	#
-	#	modified:   benchmarks.rb
-	#
+	On branch master
+	Changes not staged for commit:
+	  (use "git add <file>..." to update what will be committed)
+	  (use "git checkout -- <file>..." to discard changes in working directory)
+	
+	        modified:   benchmarks.rb
+	
+	no changes added to commit (use "git add" and/or "git commit -a")
 	$ git commit -a -m 'added new benchmarks'
 	[master 83e38c7] added new benchmarks
-	 1 files changed, 5 insertions(+), 0 deletions(-)
+	 1 files changed, 5 insertions(+)
 
 この場合、コミットする前に `benchmarks.rb` を `git add` する必要がないことに注意しましょう。
 
@@ -351,26 +358,26 @@ glob パターンとは、シェルで用いる簡易正規表現のようなも
 
 	$ rm grit.gemspec
 	$ git status
-	# On branch master
-	#
-	# Changes not staged for commit:
-	#   (use "git add/rm <file>..." to update what will be committed)
-	#
-	#       deleted:    grit.gemspec
-	#
+	On branch master
+	Changes not staged for commit:
+	  (use "git add/rm <file>..." to update what will be committed)
+	  (use "git checkout -- <file>..." to discard changes in working directory)
+	
+	        deleted:    grit.gemspec
+	
+	no changes added to commit (use "git add" and/or "git commit -a")
 
 `git rm` を実行すると、ファイルの削除がステージされます。
 
 	$ git rm grit.gemspec
 	rm 'grit.gemspec'
 	$ git status
-	# On branch master
-	#
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#       deleted:    grit.gemspec
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        deleted:    grit.gemspec
+	
 
 次にコミットするときにファイルが削除され、追跡対象外となります。変更したファイルをすでにステージしている場合は、`-f` オプションで強制的に削除しなければなりません。まだスナップショットに記録されていないファイルを誤って削除してしまうと Git で復旧することができなくなってしまうので、それを防ぐための安全装置です。
 
@@ -400,14 +407,12 @@ glob パターンとは、シェルで用いる簡易正規表現のようなも
 
 	$ git mv README.txt README
 	$ git status
-	# On branch master
-	# Your branch is ahead of 'origin/master' by 1 commit.
-	#
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#       renamed:    README.txt -> README
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        renamed:    README.txt -> README
+	
 
 しかし、実際のところこれは、次のようなコマンドを実行するのと同じ意味となります。
 
@@ -524,7 +529,7 @@ Git はこれが暗黙的なファイル名の変更であると理解するの
 	    changed the version number
 
 	 Rakefile |    2 +-
-	 1 files changed, 1 insertions(+), 1 deletions(-)
+	 1 file changed, 1 insertion(+), 1 deletion(-)
 
 	commit 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7
 	Author: Scott Chacon <schacon@gee-mail.com>
@@ -533,7 +538,7 @@ Git はこれが暗黙的なファイル名の変更であると理解するの
 	    removed unnecessary test code
 
 	 lib/simplegit.rb |    5 -----
-	 1 files changed, 0 insertions(+), 5 deletions(-)
+	 1 file changed, 5 deletions(-)
 
 	commit a11bef06a3f659402fe7563abf99ad00de2209e6
 	Author: Scott Chacon <schacon@gee-mail.com>
@@ -544,7 +549,7 @@ Git はこれが暗黙的なファイル名の変更であると理解するの
 	 README           |    6 ++++++
 	 Rakefile         |   23 +++++++++++++++++++++++
 	 lib/simplegit.rb |   25 +++++++++++++++++++++++++
-	 3 files changed, 54 insertions(+), 0 deletions(-)
+	 3 files changed, 54 insertions(+)
 
 ごらんの通り `--stat` オプションは、各コミットエントリに続けて変更されたファイルの一覧と変更されたファイルの数、追加・削除された行数が表示されます。また、それらの情報のまとめを最後に出力します。もうひとつの便利なオプションが `--pretty` です。これは、ログをデフォルトの書式以外で出力します。あらかじめ用意されているいくつかのオプションを指定することができます。`oneline` オプションは、各コミットを一行で出力します。これは、大量のコミットを見る場合に便利です。さらに `short` や `full` そして `fuller` といったオプションもあり、これは標準とほぼ同じ書式だけれども情報量がそれぞれ少なめあるいは多めになります。
 
@@ -698,31 +703,32 @@ Insert 18333fig0202.png
 
 	$ git add .
 	$ git status
-	# On branch master
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#       modified:   README.txt
-	#       modified:   benchmarks.rb
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        modified:   README.txt
+	        modified:   benchmarks.rb
+	
 
 “Changes to be committed” の直後に、"use `git reset HEAD <file>...` to unstage" と書かれています。では、アドバイスに従って `benchmarks.rb` ファイルのステージを解除してみましょう。
 
 	$ git reset HEAD benchmarks.rb
-	benchmarks.rb: locally modified
+	Unstaged changes after reset:
+	M       benchmarks.rb
 	$ git status
-	# On branch master
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#       modified:   README.txt
-	#
-	# Changes not staged for commit:
-	#   (use "git add <file>..." to update what will be committed)
-	#   (use "git checkout -- <file>..." to discard changes in working directory)
-	#
-	#       modified:   benchmarks.rb
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        modified:   README.txt
+	
+	Changes not staged for commit:
+	  (use "git add <file>..." to update what will be committed)
+	  (use "git checkout -- <file>..." to discard changes in working directory)
+	
+	        modified:   benchmarks.rb
+	
 
 ちょっと奇妙に見えるコマンドですが、きちんと動作します。`benchmarks.rb` ファイルは、変更されたもののステージされていない状態に戻りました。
 
@@ -730,23 +736,23 @@ Insert 18333fig0202.png
 
 `benchmarks.rb` に加えた変更が、実は不要なものだったとしたらどうしますか? 変更を取り消す (直近のコミット時点の状態、あるいは最初にクローンしたり最初に作業ディレクトリに取得したときの状態に戻す) 最も簡単な方法は? 幸いなことに、またもや `git status` がその方法を教えてくれます。先ほどの例の出力結果で、ステージされていないファイル一覧の部分を見てみましょう。
 
-	# Changes not staged for commit:
-	#   (use "git add <file>..." to update what will be committed)
-	#   (use "git checkout -- <file>..." to discard changes in working directory)
-	#
-	#       modified:   benchmarks.rb
-	#
+	Changes not staged for commit:
+	  (use "git add <file>..." to update what will be committed)
+	  (use "git checkout -- <file>..." to discard changes in working directory)
+	
+	        modified:   benchmarks.rb
+	
 
 とても明確に、変更を取り消す方法が書かれています (少なくとも、バージョン 1.6.1 以降の新しい Git ではこのようになります。もし古いバージョンを使用しているのなら、アップグレードしてこのすばらしい機能を活用することをおすすめします)。ではそのとおりにしてみましょう。
 
 	$ git checkout -- benchmarks.rb
 	$ git status
-	# On branch master
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#       modified:   README.txt
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        modified:   README.txt
+	
 
 変更が取り消されたことがわかります。また、これが危険なコマンドであることも知っておかねばなりません。あなたがファイルに加えた変更はすべて消えてしまいます。変更した内容を、別のファイルで上書きしたのと同じことになります。そのファイルが不要であることが確実にわかっているとき以外は、このコマンドを使わないようにしましょう。単にファイルを片付けたいだけなら、次の章で説明する stash やブランチを調べてみましょう。一般にこちらのほうがおすすめの方法です。
 
@@ -761,12 +767,12 @@ Git を使ったプロジェクトで共同作業を進めていくには、リ
 今までにどのリモートサーバーを設定したのかを知るには `git remote` コマンドを実行します。これは、今までに設定したリモートハンドルの名前を一覧表示します。リポジトリをクローンしたのなら、少なくとも *origin* という名前が見えるはずです。これは、クローン元のサーバーに対して Git がデフォルトでつける名前です。
 
 	$ git clone git://github.com/schacon/ticgit.git
-	Initialized empty Git repository in /private/tmp/ticgit/.git/
-	remote: Counting objects: 595, done.
-	remote: Compressing objects: 100% (269/269), done.
-	remote: Total 595 (delta 255), reused 589 (delta 253)
-	Receiving objects: 100% (595/595), 73.31 KiB | 1 KiB/s, done.
-	Resolving deltas: 100% (255/255), done.
+	Cloning into 'ticgit'...
+	remote: Reusing existing pack: 1857, done.
+	remote: Total 1857 (delta 0), reused 0 (delta 0)
+	Receiving objects: 100% (1857/1857), 374.35 KiB | 193.00 KiB/s, done.
+	Resolving deltas: 100% (772/772), done.
+	Checking connectivity... done.
 	$ cd ticgit
 	$ git remote
 	origin
@@ -937,6 +943,7 @@ Git では、注釈付きのタグをシンプルな方法で作成できます
 	Date:   Mon Feb 9 14:45:11 2009 -0800
 
 	my version 1.4
+
 	commit 15027957951b64cf874c3557a0f3547bd83b3ff6
 	Merge: 4a447f7... a6b4c97...
 	Author: Scott Chacon <schacon@gee-mail.com>

From 5dd2d5ebe4ea805a4a79d71814c7699ff88f2e8a Mon Sep 17 00:00:00 2001
From: harupong <harupong@gmail.com>
Date: Tue, 4 Feb 2014 09:55:52 +0900
Subject: [PATCH 234/690] [ja] Apply #651 to ja tree

---
 ja/04-git-server/01-chapter4.markdown | 42 ++++++++++++++++-----------
 1 file changed, 25 insertions(+), 17 deletions(-)

diff --git a/ja/04-git-server/01-chapter4.markdown b/ja/04-git-server/01-chapter4.markdown
index fb6cd1022..7adf46c80 100644
--- a/ja/04-git-server/01-chapter4.markdown
+++ b/ja/04-git-server/01-chapter4.markdown
@@ -115,7 +115,8 @@ HTTP によるリポジトリの提供の問題点は、クライアント側か
 Git サーバーを立ち上げるには、既存のリポジトリをエクスポートして新たなベアリポジトリ (作業ディレクトリを持たないリポジトリ) を作らなければなりません。これは簡単にできます。リポジトリをクローンして新たにベアリポジトリを作成するには、clone コマンドでオプション `--bare` を指定します。慣例により、ベアリポジトリのディレクトリ名の最後は `.git` とすることになっています。
 
 	$ git clone --bare my_project my_project.git
-	Initialized empty Git repository in /opt/projects/my_project.git/
+    Cloning into bare repository 'my_project.git'...
+    done.
 
 このコマンドを実行したときの出力はちょっとわかりにくいかもしれません。`clone` は基本的に `git init` をしてから `git fetch` をするのと同じことなので、`git init` の部分の出力も見ることになります。そのメッセージは「空のディレクトリを作成しました」というものです。実際にどんなオブジェクトの転送が行われたのかは何も表示されませんが、きちんと転送は行われています。これで、`my_project.git` ディレクトリに Git リポジトリのデータができあがりました。
 
@@ -284,6 +285,13 @@ Git サーバーを立ち上げるには、既存のリポジトリをエクス
 
 	$ cat .git/hooks/post-update
 	#!/bin/sh
+    #
+    # An example hook script to prepare a packed repository for use over
+    # dumb transports.
+    #
+    # To enable this hook, rename this file to "post-update".
+    #
+    
 	exec git-update-server-info
 
 SSH 経由でサーバーへのプッシュが行われると、Git はこのコマンドを実行し、HTTP 経由での取得に必要なファイルを更新します。
@@ -399,7 +407,7 @@ Gitosis は鍵の管理も行うので、まず現在の鍵ファイルを削除
 
 	$ ssh git@gitserver
 	PTY allocation request failed on channel 0
-	fatal: unrecognized command 'gitosis-serve schacon@quaternion'
+    ERROR:gitosis.serve.main:Need SSH_ORIGINAL_COMMAND in environment.
 	  Connection to gitserver closed.
 
 これは「何も Git のコマンドを実行していないので、接続を拒否した」というメッセージです。では、実際に何か Git のコマンドを実行してみましょう。Gitosis 管理リポジトリをクローンします。
@@ -423,28 +431,28 @@ Gitosis は鍵の管理も行うので、まず現在の鍵ファイルを削除
 	[gitosis]
 
 	[group gitosis-admin]
-	writable = gitosis-admin
 	members = scott
+	writable = gitosis-admin
 
 これは、'scott' ユーザー（Gitosis の初期化時に公開鍵を指定したユーザー）だけが `gitosis-admin` プロジェクトにアクセスできるという意味です。
 
 では、新しいプロジェクトを追加してみましょう。`mobile` という新しいセクションを作成し、モバイルチームのメンバーとモバイルチームがアクセスするプロジェクトを書き入れます。今のところ存在するユーザーは 'scott' だけなので、とりあえずは彼をメンバーとして追加します。そして、新しいプロジェクト `iphone_project` を作ることにしましょう。
 
 	[group mobile]
-	writable = iphone_project
 	members = scott
+	writable = iphone_project
 
 `gitosis-admin` プロジェクトに手を入れたら、それをコミットしてサーバーにプッシュしないと変更が反映されません。
 
 	$ git commit -am 'add iphone_project and mobile group'
-	[master]: created 8962da8: "changed name"
-	 1 files changed, 4 insertions(+), 0 deletions(-)
-	$ git push
+    [master 8962da8] add iphone_project and mobile group
+     1 file changed, 4 insertions(+)
+    $ git push origin master
 	Counting objects: 5, done.
-	Compressing objects: 100% (2/2), done.
-	Writing objects: 100% (3/3), 272 bytes, done.
-	Total 3 (delta 1), reused 0 (delta 0)
-	To git@gitserver:/opt/git/gitosis-admin.git
+    Compressing objects: 100% (3/3), done.
+    Writing objects: 100% (3/3), 272 bytes | 0 bytes/s, done.
+    Total 3 (delta 0), reused 0 (delta 0)
+    To git@gitserver:gitosis-admin.git
 	   fb27aec..8962da8  master -> master
 
 新しい `iphone_project` プロジェクトにプッシュするには、ローカル側のプロジェクトに、このサーバーをリモートとして追加します。サーバー側でわざわざベアリポジトリを作る必要はありません。先ほどプッシュした地点で、Gitosis が自動的にベアリポジトリの作成を済ませています。
@@ -453,7 +461,7 @@ Gitosis は鍵の管理も行うので、まず現在の鍵ファイルを削除
 	$ git push origin master
 	Initialized empty Git repository in /opt/git/iphone_project.git/
 	Counting objects: 3, done.
-	Writing objects: 100% (3/3), 230 bytes, done.
+    Writing objects: 100% (3/3), 230 bytes | 0 bytes/s, done.
 	Total 3 (delta 0), reused 0 (delta 0)
 	To git@gitserver:iphone_project.git
 	 * [new branch]      master -> master
@@ -469,20 +477,20 @@ Gitosis は鍵の管理も行うので、まず現在の鍵ファイルを削除
 そして彼らを 'mobile' チームに追加し、`iphone_project` を読み書きできるようにします。
 
 	[group mobile]
-	writable = iphone_project
 	members = scott john josie jessica
+	writable = iphone_project
 
 この変更をコミットしてプッシュすると、この四人のユーザーがプロジェクトへの読み書きをできるようになります。
 
 Gitosis にはシンプルなアクセス制御機能もあります。John には読み込み専用のアクセス権を設定したいという場合は、このようにします。
 
 	[group mobile]
-	writable = iphone_project
 	members = scott josie jessica
+	writable = iphone_project
 
 	[group mobile_ro]
-	readonly = iphone_project
 	members = john
+	readonly = iphone_project
 
 John はプロジェクトをクローンして変更内容を受け取れます。しかし、手元での変更をプッシュしようとすると Gitosis に拒否されます。このようにして好きなだけのグループを作成し、それぞれに個別のユーザーとプロジェクトを含めることができます。また、グループのメンバーとして別のグループを指定し (その場合は先頭に `@` をつけます)、メンバーを自動的に継承することもできます。
 
@@ -490,12 +498,12 @@ John はプロジェクトをクローンして変更内容を受け取れます
 	members = scott josie jessica
 
 	[group mobile]
-	writable  = iphone_project
 	members   = @mobile_committers
+	writable  = iphone_project
 
 	[group mobile_2]
-	writable  = another_iphone_project
 	members   = @mobile_committers john
+	writable  = another_iphone_project
 
 何か問題が発生した場合には、`[gitosis]` セクションの下に `loglevel=DEBUG` を書いておくと便利です。設定ミスでプッシュ権限を奪われてしまった場合は、サーバー上の `/home/git/.gitosis.conf` を直接編集して元に戻します。Gitosis は、このファイルから情報を読み取っています。`gitosis.conf` ファイルへの変更がプッシュされてきたときに、その内容をこのファイルに書き出します。このファイルを手動で変更しても、次に `gitosis-admin` プロジェクトへのプッシュが成功した時点でその内容が書き換えられることになります。
 

From aa1385eb7e27aa0d7f54f0dcbc0628294794f239 Mon Sep 17 00:00:00 2001
From: Yue Lin Ho <b8732003@student.nsysu.edu.tw>
Date: Mon, 17 Feb 2014 15:59:43 +0800
Subject: [PATCH 235/690] [zh] Synchronize with en version

Some lines are modified in chapter 4.
The modifications refer to the commit 39663b43.
(gitolite section reworked for gitolite v3)
---
 zh/01-introduction/01-chapter1.markdown       |  41 +-
 zh/02-git-basics/01-chapter2.markdown         | 359 ++++++++++--------
 zh/03-git-branching/01-chapter3.markdown      | 178 ++++-----
 zh/04-git-server/01-chapter4.markdown         | 174 ++++-----
 zh/05-distributed-git/01-chapter5.markdown    | 127 ++++---
 zh/06-git-tools/01-chapter6.markdown          |  38 +-
 zh/07-customizing-git/01-chapter7.markdown    | 238 +++++++-----
 zh/08-git-and-other-scms/01-chapter8.markdown |  32 +-
 zh/09-git-internals/01-chapter9.markdown      |  10 +-
 9 files changed, 657 insertions(+), 540 deletions(-)

diff --git a/zh/01-introduction/01-chapter1.markdown b/zh/01-introduction/01-chapter1.markdown
index fa5808e2e..3219ccaf2 100644
--- a/zh/01-introduction/01-chapter1.markdown
+++ b/zh/01-introduction/01-chapter1.markdown
@@ -14,7 +14,7 @@
 
 为了解决这个问题，人们很久以前就开发了许多种本地版本控制系统，大多都是采用某种简单的数据库来记录文件的历次更新差异（见图 1-1）。
 
-Insert 18333fig0101.png 
+Insert 18333fig0101.png
 图 1-1. 本地版本控制系统
 
 其中最流行的一种叫做 rcs，现今许多计算机系统上都还看得到它的踪影。甚至在流行的 Mac OS X 系统上安装了开发者工具包之后，也可以使用 rcs 命令。它的工作原理基本上就是保存并管理文件补丁（patch）。文件补丁是一种特定格式的文本文件，记录着对应文件修订前后的内容变化。所以，根据每次修订后的补丁，rcs 可以通过不断打补丁，计算出各个版本的文件内容。
@@ -23,7 +23,7 @@ Insert 18333fig0101.png
 
 接下来人们又遇到一个问题，如何让在不同系统上的开发者协同工作？于是，集中化的版本控制系统（ Centralized Version Control Systems，简称 CVCS ）应运而生。这类系统，诸如 CVS，Subversion 以及 Perforce 等，都有一个单一的集中管理的服务器，保存所有文件的修订版本，而协同工作的人们都通过客户端连到这台服务器，取出最新的文件或者提交更新。多年以来，这已成为版本控制系统的标准做法（见图 1-2）。
 
-Insert 18333fig0102.png 
+Insert 18333fig0102.png
 图 1-2. 集中化的版本控制系统
 
 这种做法带来了许多好处，特别是相较于老式的本地 VCS 来说。现在，每个人都可以在一定程度上看到项目中的其他人正在做些什么。而管理员也可以轻松掌控每个开发者的权限，并且管理一个 CVCS 要远比在各个客户端上维护本地数据库来得轻松容易。
@@ -34,7 +34,7 @@ Insert 18333fig0102.png
 
 于是分布式版本控制系统（ Distributed Version Control System，简称 DVCS ）面世了。在这类系统中，像 Git，Mercurial，Bazaar 以及 Darcs 等，客户端并不只提取最新版本的文件快照，而是把代码仓库完整地镜像下来。这么一来，任何一处协同工作用的服务器发生故障，事后都可以用任何一个镜像出来的本地仓库恢复。因为每一次的提取操作，实际上都是一次对代码仓库的完整备份（见图 1-3）。
 
-Insert 18333fig0103.png 
+Insert 18333fig0103.png
 图 1-3. 分布式版本控制系统
 
 更进一步，许多这类系统都可以指定和若干不同的远端代码仓库进行交互。籍此，你就可以在同一个项目中，分别和不同工作小组的人相互协作。你可以根据需要设定不同的协作流程，比如层次模型式的工作流，而这在以前的集中式系统中是无法实现的。
@@ -45,11 +45,11 @@ Insert 18333fig0103.png
 
 到了 2005 年，开发 BitKeeper 的商业公司同 Linux 内核开源社区的合作关系结束，他们收回了免费使用 BitKeeper 的权力。这就迫使 Linux 开源社区（特别是 Linux 的缔造者 Linus Torvalds ）不得不吸取教训，只有开发一套属于自己的版本控制系统才不至于重蹈覆辙。他们对新的系统制订了若干目标：
 
-* 速度
-* 简单的设计
-* 对非线性开发模式的强力支持（允许上千个并行开发的分支）
-* 完全分布式
-* 有能力高效管理类似 Linux 内核一样的超大规模项目（速度和数据量）
+*	速度
+*	简单的设计
+*	对非线性开发模式的强力支持（允许上千个并行开发的分支）
+*	完全分布式
+*	有能力高效管理类似 Linux 内核一样的超大规模项目（速度和数据量）
 
 自诞生于 2005 年以来，Git 日臻成熟完善，在高度易用的同时，仍然保留着初期设定的目标。它的速度飞快，极其适合管理大项目，它还有着令人难以置信的非线性分支管理系统（见第三章），可以应付各种复杂的项目开发需求。
 
@@ -61,12 +61,12 @@ Insert 18333fig0103.png
 
 Git 和其他版本控制系统的主要差别在于，Git 只关心文件数据的整体是否发生变化，而大多数其他系统则只关心文件内容的具体差异。这类系统（CVS，Subversion，Perforce，Bazaar 等等）每次记录有哪些文件作了更新，以及都更新了哪些行的什么内容，请看图 1-4。
 
-Insert 18333fig0104.png 
+Insert 18333fig0104.png
 图 1-4. 其他系统在每个版本中记录着各个文件的具体差异
 
 Git 并不保存这些前后变化的差异数据。实际上，Git 更像是把变化的文件作快照后，记录在一个微型的文件系统中。每次提交更新时，它会纵览一遍所有文件的指纹信息并对文件作一快照，然后保存一个指向这次快照的索引。为提高性能，若文件没有变化，Git 不会再次保存，而只对上次保存的快照作一链接。Git 的工作方式就像图 1-5 所示。
 
-Insert 18333fig0105.png 
+Insert 18333fig0105.png
 图 1-5. Git 保存每次更新时的文件快照
 
 这是 Git 同其他系统的重要区别。它完全颠覆了传统版本控制的套路，并对各个环节的实现方式作了新的设计。Git 更像是个小型的文件系统，但它同时还提供了许多以此为基础的超强工具，而不只是一个简单的 VCS。稍后在第三章讨论 Git 分支管理的时候，我们会再看看这样的设计究竟会带来哪些好处。
@@ -101,7 +101,7 @@ Git 的工作完全依赖于这类指纹字串，所以你会经常看到这样
 
 由此我们看到 Git 管理项目时，文件流转的三个工作区域：Git 的工作目录，暂存区域，以及本地仓库。
 
-Insert 18333fig0106.png 
+Insert 18333fig0106.png
 图 1-6. 工作目录，暂存区域，以及本地仓库
 
 每个项目都有一个 Git 目录（译注：如果 `git clone` 出来的话，就是其中 `.git` 的目录；如果 `git clone --bare` 的话，新建的目录本身就是 Git 目录。），它是 Git 用来保存元数据和对象数据库的地方。该目录非常重要，每次克隆镜像仓库的时候，实际拷贝的就是这个目录里面的数据。
@@ -133,7 +133,7 @@ Git 的工作需要调用 curl，zlib，openssl，expat，libiconv 等库的代
 
 	$ apt-get install libcurl4-gnutls-dev libexpat1-dev gettext \
 	  libz-dev libssl-dev
-	
+
 之后，从下面的 Git 官方站点下载最新版本源代码：
 
 	http://git-scm.com/download
@@ -148,7 +148,7 @@ Git 的工作需要调用 curl，zlib，openssl，expat，libiconv 等库的代
 现在已经可以用 `git` 命令了，用 `git` 把 Git 项目仓库克隆到本地，以便日后随时更新：
 
 	$ git clone git://git.kernel.org/pub/scm/git/git.git
-	
+
 ### 在 Linux 上安装 ###
 
 如果要在 Linux 上安装预编译好的 Git 二进制安装包，可以直接用系统提供的包管理工具。在 Fedora 上用 yum 安装：
@@ -165,7 +165,7 @@ Git 的工作需要调用 curl，zlib，openssl，expat，libiconv 等库的代
 
 	http://code.google.com/p/git-osx-installer
 
-Insert 18333fig0107.png 
+Insert 18333fig0107.png
 图 1-7. Git OS X 安装工具
 
 另一种是通过 MacPorts (`http://www.macports.org`) 安装。如果已经装好了 MacPorts，用下面的命令安装 Git：
@@ -182,15 +182,17 @@ Insert 18333fig0107.png
 
 完成安装之后，就可以使用命令行的 `git` 工具（已经自带了 ssh 客户端）了，另外还有一个图形界面的 Git 项目管理工具。
 
+Note on Windows usage: you should use Git with the provided msysGit shell (Unix style), it allows to use the complex lines of command given in this book. If you need, for some reason, to use the native Windows shell / command line console, you have to use double quotes instead of simple quotes (for parameters with spaces in them) and you must quote the parameters ending with the circumflex accent (^) if they are last on the line, as it is a continuation symbol in Windows.
+
 ## 初次运行 Git 前的配置 ##
 
 一般在新的系统上，我们都需要先配置下自己的 Git 工作环境。配置工作只需一次，以后升级时还会沿用现在的配置。当然，如果需要，你随时可以用相同的命令修改已有的配置。
 
 Git 提供了一个叫做 git config 的工具（译注：实际是 `git-config` 命令，只不过可以通过 `git` 加一个名字来呼叫此命令。），专门用来配置或读取相应的工作环境变量。而正是由这些环境变量，决定了 Git 在各个环节的具体工作方式和行为。这些变量可以存放在以下三个不同的地方：
 
-* `/etc/gitconfig` 文件：系统中对所有用户都普遍适用的配置。若使用 `git config` 时用 ` --system` 选项，读写的就是这个文件。
-* `~/.gitconfig` 文件：用户目录下的配置文件只适用于该用户。若使用 `git config` 时用 ` --global` 选项，读写的就是这个文件。
-* 当前项目的 git 目录中的配置文件（也就是工作目录中的 `.git/config` 文件）：这里的配置仅仅针对当前项目有效。每一个级别的配置都会覆盖上层的相同配置，所以 `.git/config` 里的配置会覆盖 `/etc/gitconfig` 中的同名变量。
+*	`/etc/gitconfig` 文件：系统中对所有用户都普遍适用的配置。若使用 `git config` 时用 ` --system` 选项，读写的就是这个文件。
+*	`~/.gitconfig` 文件：用户目录下的配置文件只适用于该用户。若使用 `git config` 时用 ` --global` 选项，读写的就是这个文件。
+*	当前项目的 git 目录中的配置文件（也就是工作目录中的 `.git/config` 文件）：这里的配置仅仅针对当前项目有效。每一个级别的配置都会覆盖上层的相同配置，所以 `.git/config` 里的配置会覆盖 `/etc/gitconfig` 中的同名变量。
 
 在 Windows 系统上，Git 会找寻用户主目录下的 `.gitconfig` 文件。主目录即 `$HOME` 变量指定的目录，一般都是 `C:\Documents and Settings\$USER`。此外，Git 还会尝试找寻 `/etc/gitconfig` 文件，只不过看当初 Git 装在什么目录，就以此作为根目录来定位。
 
@@ -208,7 +210,7 @@ Git 提供了一个叫做 git config 的工具（译注：实际是 `git-config`
 接下来要设置的是默认使用的文本编辑器。Git 需要你输入一些额外消息的时候，会自动调用一个外部文本编辑器给你用。默认会使用操作系统指定的默认编辑器，一般可能会是 Vi 或者 Vim。如果你有其他偏好，比如 Emacs 的话，可以重新设置：
 
 	$ git config --global core.editor emacs
-	
+
 ### 差异分析工具 ###
 
 还有一个比较常用的是，在解决合并冲突时使用哪种差异分析工具。比如要改用 vimdiff 的话：
@@ -249,7 +251,8 @@ Git 可以理解 kdiff3，tkdiff，meld，xxdiff，emerge，vimdiff，gvimdiff
 
 	$ git help config
 
-我们随时都可以浏览这些帮助信息而无需连网。不过，要是你觉得还不够，可以到 Frenode IRC 服务器（irc.freenode.net）上的 `#git` 或 `#github` 频道寻求他人帮助。这两个频道上总有着上百号人，大多都有着丰富的 git 知识，并且乐于助人。
+我们随时都可以浏览这些帮助信息而无需连网。
+不过，要是你觉得还不够，可以到 Frenode IRC 服务器（irc.freenode.net）上的 `#git` 或 `#github` 频道寻求他人帮助。这两个频道上总有着上百号人，大多都有着丰富的 git 知识，并且乐于助人。
 
 ## 小结 ##
 
diff --git a/zh/02-git-basics/01-chapter2.markdown b/zh/02-git-basics/01-chapter2.markdown
index af475bb2b..b59978ecc 100644
--- a/zh/02-git-basics/01-chapter2.markdown
+++ b/zh/02-git-basics/01-chapter2.markdown
@@ -54,8 +54,8 @@ Insert 18333fig0201.png
 要确定哪些文件当前处于什么状态，可以用 `git status` 命令。如果在克隆仓库之后立即执行此命令，会看到类似这样的输出：
 
 	$ git status
-	# On branch master
-	nothing to commit (working directory clean)
+	On branch master
+	nothing to commit, working directory clean
 
 这说明你现在的工作目录相当干净。换句话说，所有已跟踪文件在上次提交后都未被更改过。此外，上面的信息还表明，当前目录下没有出现任何处于未跟踪的新文件，否则 Git 会在这里列出来。最后，该命令还显示了当前所在的分支是 `master`，这是默认的分支名称，实际是可以修改的，现在先不用考虑。下一章我们就会详细讨论分支和引用。
 
@@ -63,11 +63,12 @@ Insert 18333fig0201.png
 
 	$ vim README
 	$ git status
-	# On branch master
-	# Untracked files:
-	#   (use "git add <file>..." to include in what will be committed)
-	#
-	#	README
+	On branch master
+	Untracked files:
+	  (use "git add <file>..." to include in what will be committed)
+	
+	        README
+
 	nothing added to commit but untracked files present (use "git add" to track)
 
 在状态报告中可以看到新建的`README`文件出现在“Untracked files”下面。未跟踪的文件意味着Git在之前的快照（提交）中没有这些文件；Git 不会自动将之纳入跟踪范围，除非你明明白白地告诉它“我需要跟踪该文件”，因而不用担心把临时文件什么的也归入版本管理。不过现在的例子中，我们确实想要跟踪管理 README 这个文件。
@@ -81,12 +82,12 @@ Insert 18333fig0201.png
 此时再运行 `git status` 命令，会看到 README 文件已被跟踪，并处于暂存状态：
 
 	$ git status
-	# On branch master
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#	new file:   README
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        new file:   README
+	
 
 只要在 “Changes to be committed” 这行下面的，就说明是已暂存状态。如果此时提交，那么该文件此时此刻的版本将被留存在历史记录中。你可能会想起之前我们使用 `git init` 后就运行了 `git add` 命令，开始跟踪当前目录下的文件。在 `git add` 后面可以指明要跟踪的文件或目录路径。如果是目录的话，就说明要递归跟踪该目录下的所有文件。（译注：其实 `git add` 的潜台词就是把目标文件快照放入暂存区域，也就是 add file into staged area，同时未曾跟踪过的文件标记为需要跟踪。这样就好理解后续 add 操作的实际意义了。）
 
@@ -95,58 +96,60 @@ Insert 18333fig0201.png
 现在我们修改下之前已跟踪过的文件 `benchmarks.rb`，然后再次运行 `status` 命令，会看到这样的状态报告：
 
 	$ git status
-	# On branch master
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#	new file:   README
-	#
-	# Changes not staged for commit:
-	#   (use "git add <file>..." to update what will be committed)
-	#
-	#	modified:   benchmarks.rb
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        new file:   README
+
+	Changes not staged for commit:
+	  (use "git add <file>..." to update what will be committed)
+	  (use "git checkout -- <file>..." to discard changes in working directory)
+	
+	        modified:   benchmarks.rb
+	
 
 文件 `benchmarks.rb` 出现在 “Changes not staged for commit” 这行下面，说明已跟踪文件的内容发生了变化，但还没有放到暂存区。要暂存这次更新，需要运行 `git add` 命令（这是个多功能命令，根据目标文件的状态不同，此命令的效果也不同：可以用它开始跟踪新文件，或者把已跟踪的文件放到暂存区，还能用于合并时把有冲突的文件标记为已解决状态等）。现在让我们运行 `git add` 将 benchmarks.rb 放到暂存区，然后再看看 `git status` 的输出：
 
 	$ git add benchmarks.rb
 	$ git status
-	# On branch master
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#	new file:   README
-	#	modified:   benchmarks.rb
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        new file:   README
+	        modified:   benchmarks.rb
+	
 
 现在两个文件都已暂存，下次提交时就会一并记录到仓库。假设此时，你想要在 `benchmarks.rb` 里再加条注释，重新编辑存盘后，准备好提交。不过且慢，再运行 `git status` 看看：
 
-	$ vim benchmarks.rb 
+	$ vim benchmarks.rb
 	$ git status
-	# On branch master
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#	new file:   README
-	#	modified:   benchmarks.rb
-	#
-	# Changes not staged for commit:
-	#   (use "git add <file>..." to update what will be committed)
-	#
-	#	modified:   benchmarks.rb
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        new file:   README
+	        modified:   benchmarks.rb
+	
+	Changes not staged for commit:
+	  (use "git add <file>..." to update what will be committed)
+	  (use "git checkout -- <file>..." to discard changes in working directory)
+	
+	        modified:   benchmarks.rb
+	
 
 怎么回事？ `benchmarks.rb` 文件出现了两次！一次算未暂存，一次算已暂存，这怎么可能呢？好吧，实际上 Git 只不过暂存了你运行 `git add` 命令时的版本，如果现在提交，那么提交的是添加注释前的版本，而非当前工作目录中的版本。所以，运行了 `git add` 之后又作了修订的文件，需要重新运行 `git add` 把最新版本重新暂存起来：
 
 	$ git add benchmarks.rb
 	$ git status
-	# On branch master
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#	new file:   README
-	#	modified:   benchmarks.rb
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        new file:   README
+	        modified:   benchmarks.rb
+	
 
 ### 忽略某些文件 ###
 
@@ -180,6 +183,10 @@ Insert 18333fig0201.png
 	build/
 	# 会忽略 doc/notes.txt 但不包括 doc/server/arch.txt
 	doc/*.txt
+	# ignore all .txt files in the doc/ directory
+	doc/**/*.txt
+
+A `**/` pattern is available in Git since version 1.8.2.
 
 ### 查看已暂存和未暂存的更新 ###
 
@@ -188,17 +195,18 @@ Insert 18333fig0201.png
 假如再次修改 `README` 文件后暂存，然后编辑 `benchmarks.rb` 文件后先别暂存，运行 `status` 命令将会看到：
 
 	$ git status
-	# On branch master
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#	new file:   README
-	#
-	# Changes not staged for commit:
-	#   (use "git add <file>..." to update what will be committed)
-	#
-	#	modified:   benchmarks.rb
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        new file:   README
+	
+	Changes not staged for commit:
+	  (use "git add <file>..." to update what will be committed)
+	  (use "git checkout -- <file>..." to discard changes in working directory)
+	
+	        modified:   benchmarks.rb
+	
 
 要查看尚未暂存的文件更新了哪些部分，不加参数直接输入 `git diff`：
 
@@ -243,16 +251,18 @@ Insert 18333fig0201.png
 	$ git add benchmarks.rb
 	$ echo '# test line' >> benchmarks.rb
 	$ git status
-	# On branch master
-	#
-	# Changes to be committed:
-	#
-	#	modified:   benchmarks.rb
-	#
-	# Changes not staged for commit:
-	#
-	#	modified:   benchmarks.rb
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        modified:   benchmarks.rb
+	
+	Changes not staged for commit:
+	  (use "git add <file>..." to update what will be committed)
+	  (use "git checkout -- <file>..." to discard changes in working directory)
+	
+	        modified:   benchmarks.rb
+	
 
 现在运行 `git diff` 看暂存前后的变化：
 
@@ -263,7 +273,7 @@ Insert 18333fig0201.png
 	+++ b/benchmarks.rb
 	@@ -127,3 +127,4 @@ end
 	 main()
-	 
+
 	 ##pp Grit::GitRuby.cache_client.stats
 	+# test line
 
@@ -300,10 +310,9 @@ Insert 18333fig0201.png
 	# with '#' will be ignored, and an empty message aborts the commit.
 	# On branch master
 	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
 	#       new file:   README
 	#       modified:   benchmarks.rb
+	#
 	~
 	~
 	~
@@ -314,8 +323,8 @@ Insert 18333fig0201.png
 另外也可以用 -m 参数后跟提交说明的方式，在一行命令中提交更新：
 
 	$ git commit -m "Story 182: Fix benchmarks for speed"
-	[master]: created 463dc4f: "Fix benchmarks for speed"
-	 2 files changed, 3 insertions(+), 0 deletions(-)
+	[master 463dc4f] Fix benchmarks for speed
+	 2 files changed, 3 insertions(+)
 	 create mode 100644 README
 
 好，现在你已经创建了第一个提交！可以看到，提交后它会告诉你，当前是在哪个分支（master）提交的，本次提交的完整 SHA-1 校验和是什么（`463dc4f`），以及在本次提交中，有多少文件修订过，多少行添改和删改过。
@@ -327,15 +336,17 @@ Insert 18333fig0201.png
 尽管使用暂存区域的方式可以精心准备要提交的细节，但有时候这么做略显繁琐。Git 提供了一个跳过使用暂存区域的方式，只要在提交的时候，给 `git commit` 加上 `-a` 选项，Git 就会自动把所有已经跟踪过的文件暂存起来一并提交，从而跳过 `git add` 步骤：
 
 	$ git status
-	# On branch master
-	#
-	# Changes not staged for commit:
-	#
-	#	modified:   benchmarks.rb
-	#
+	On branch master
+	Changes not staged for commit:
+	  (use "git add <file>..." to update what will be committed)
+	  (use "git checkout -- <file>..." to discard changes in working directory)
+	
+	        modified:   benchmarks.rb
+	
+	no changes added to commit (use "git add" and/or "git commit -a")
 	$ git commit -a -m 'added new benchmarks'
 	[master 83e38c7] added new benchmarks
-	 1 files changed, 5 insertions(+), 0 deletions(-)
+	 1 files changed, 5 insertions(+)
 
 看到了吗？提交之前不再需要 `git add` 文件 benchmarks.rb 了。
 
@@ -347,26 +358,26 @@ Insert 18333fig0201.png
 
 	$ rm grit.gemspec
 	$ git status
-	# On branch master
-	#
-	# Changes not staged for commit:
-	#   (use "git add/rm <file>..." to update what will be committed)
-	#
-	#       deleted:    grit.gemspec
-	#
+	On branch master
+	Changes not staged for commit:
+	  (use "git add/rm <file>..." to update what will be committed)
+	  (use "git checkout -- <file>..." to discard changes in working directory)
+	
+	        deleted:    grit.gemspec
+	
+	no changes added to commit (use "git add" and/or "git commit -a")
 
 然后再运行 `git rm` 记录此次移除文件的操作：
 
 	$ git rm grit.gemspec
 	rm 'grit.gemspec'
 	$ git status
-	# On branch master
-	#
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#       deleted:    grit.gemspec
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        deleted:    grit.gemspec
+	
 
 最后提交的时候，该文件就不再纳入版本管理了。如果删除之前修改过并且已经放到暂存区域的话，则必须要用强制删除选项 `-f`（译注：即 force 的首字母），以防误删除文件后丢失修改的内容。
 
@@ -396,14 +407,12 @@ Insert 18333fig0201.png
 
 	$ git mv README.txt README
 	$ git status
-	# On branch master
-	# Your branch is ahead of 'origin/master' by 1 commit.
-	#
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#       renamed:    README.txt -> README
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        renamed:    README.txt -> README
+	
 
 其实，运行 `git mv` 就相当于运行了下面三条命令：
 
@@ -459,11 +468,13 @@ Insert 18333fig0201.png
 	index a874b73..8f94139 100644
 	--- a/Rakefile
 	+++ b/Rakefile
-	@@ -5,7 +5,7 @@ require 'rake/gempackagetask'
+	@@ -5,5 +5,5 @@ require 'rake/gempackagetask'
 	 spec = Gem::Specification.new do |s|
+	     s.name      =   "simplegit"
 	-    s.version   =   "0.1.0"
 	+    s.version   =   "0.1.1"
 	     s.author    =   "Scott Chacon"
+	     s.email     =   "schacon@gee-mail.com
 
 	commit 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7
 	Author: Scott Chacon <schacon@gee-mail.com>
@@ -486,9 +497,31 @@ Insert 18333fig0201.png
 	-end
 	\ No newline at end of file
 
+This option displays the same information but with a diff directly following each entry. This is very helpful for code review or to quickly browse what happened during a series of commits that a collaborator has added.
+
+Sometimes it's easier to review changes on the word level rather than on the line level. There is a `--word-diff` option available in Git, that you can append to the `git log -p` command to get word diff instead of normal line by line diff. Word diff format is quite useless when applied to source code, but it comes in handy when applied to large text files, like books or your dissertation. Here is an example:
+
+	$ git log -U1 --word-diff
+	commit ca82a6dff817ec66f44342007202690a93763949
+	Author: Scott Chacon <schacon@gee-mail.com>
+	Date:   Mon Mar 17 21:52:11 2008 -0700
+
+	    changed the version number
+
+	diff --git a/Rakefile b/Rakefile
+	index a874b73..8f94139 100644
+	--- a/Rakefile
+	+++ b/Rakefile
+	@@ -7,3 +7,3 @@ spec = Gem::Specification.new do |s|
+	    s.name      =   "simplegit"
+	    s.version   =   [-"0.1.0"-]{+"0.1.1"+}
+	    s.author    =   "Scott Chacon"
+
+As you can see, there is no added and removed lines in this output as in a normal diff. Changes are shown inline instead. You can see the added word enclosed in `{+ +}` and removed one enclosed in `[- -]`. You may also want to reduce the usual three lines context in diff output to only one line, as the context is now words, not lines. You can do this with `-U1` as we did in the example above.
+
 在做代码审查，或者要快速浏览其他协作者提交的更新都作了哪些改动时，就可以用这个选项。此外，还有许多摘要选项可以用，比如 `--stat`，仅显示简要的增改行数统计：
 
-	$ git log --stat 
+	$ git log --stat
 	commit ca82a6dff817ec66f44342007202690a93763949
 	Author: Scott Chacon <schacon@gee-mail.com>
 	Date:   Mon Mar 17 21:52:11 2008 -0700
@@ -496,7 +529,7 @@ Insert 18333fig0201.png
 	    changed the version number
 
 	 Rakefile |    2 +-
-	 1 files changed, 1 insertions(+), 1 deletions(-)
+	 1 file changed, 1 insertion(+), 1 deletion(-)
 
 	commit 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7
 	Author: Scott Chacon <schacon@gee-mail.com>
@@ -505,7 +538,7 @@ Insert 18333fig0201.png
 	    removed unnecessary test code
 
 	 lib/simplegit.rb |    5 -----
-	 1 files changed, 0 insertions(+), 5 deletions(-)
+	 1 file changed, 5 deletions(-)
 
 	commit a11bef06a3f659402fe7563abf99ad00de2209e6
 	Author: Scott Chacon <schacon@gee-mail.com>
@@ -516,9 +549,10 @@ Insert 18333fig0201.png
 	 README           |    6 ++++++
 	 Rakefile         |   23 +++++++++++++++++++++++
 	 lib/simplegit.rb |   25 +++++++++++++++++++++++++
-	 3 files changed, 54 insertions(+), 0 deletions(-)
+	 3 files changed, 54 insertions(+)
 
-每个提交都列出了修改过的文件，以及其中添加和移除的行数，并在最后列出所有增减行数小计。还有个常用的 `--pretty` 选项，可以指定使用完全不同于默认格式的方式展示提交历史。比如用 `oneline` 将每个提交放在一行显示，这在提交数很大时非常有用。另外还有 `short`，`full` 和 `fuller` 可以用，展示的信息或多或少有些不同，请自己动手实践一下看看效果如何。
+每个提交都列出了修改过的文件，以及其中添加和移除的行数，并在最后列出所有增减行数小计。
+还有个常用的 `--pretty` 选项，可以指定使用完全不同于默认格式的方式展示提交历史。比如用 `oneline` 将每个提交放在一行显示，这在提交数很大时非常有用。另外还有 `short`，`full` 和 `fuller` 可以用，展示的信息或多或少有些不同，请自己动手实践一下看看效果如何。
 
 	$ git log --pretty=oneline
 	ca82a6dff817ec66f44342007202690a93763949 changed the version number
@@ -534,6 +568,11 @@ Insert 18333fig0201.png
 
 表 2-1 列出了常用的格式占位符写法及其代表的意义。
 
+<!-- Attention to translators: this is a table declaration.
+The lines must be formatted as follows
+<TAB><First column text><TAB><Second column text>
+-->
+
 	选项	 说明
 	%H	提交对象（commit）的完整哈希字串
 	%h	提交对象的简短哈希字串
@@ -569,8 +608,14 @@ Insert 18333fig0201.png
 
 以上只是简单介绍了一些 `git log` 命令支持的选项。表 2-2 还列出了一些其他常用的选项及其释义。
 
+<!-- Attention to translators: this is a table declaration.
+The lines must be formatted as follows
+<TAB><First column text><TAB><Second column text>
+-->
+
 	选项	说明
 	-p	按补丁格式显示每个更新之间的差异。
+	--word-diff	按 word diff 格式显示差异。
 	--stat	显示每次更新的文件修改统计信息。
 	--shortstat	只显示 --stat 中最后的行数修改添加移除统计。
 	--name-only	仅在提交信息后显示已修改的文件清单。
@@ -579,6 +624,7 @@ Insert 18333fig0201.png
 	--relative-date	使用较短的相对时间显示（比如，“2 weeks ago”）。
 	--graph	显示 ASCII 图形表示的分支合并历史。
 	--pretty	使用其他格式显示历史提交信息。可用的选项包括 oneline，short，full，fuller 和 format（后跟指定格式）。
+	--oneline	`--pretty=oneline --abbrev-commit` 的简化用法。
 
 ### 限制输出长度 ###
 
@@ -596,6 +642,11 @@ Insert 18333fig0201.png
 
 表 2-3 还列出了其他常用的类似选项。
 
+<!-- Attention to translators: this is a table declaration.
+The lines must be formatted as follows
+<TAB><First column text><TAB><Second column text>
+-->
+
 	选项	说明
 	-(n)	仅显示最近的 n 条提交
 	--since, --after	仅显示指定时间之后的提交。
@@ -653,31 +704,32 @@ Insert 18333fig0202.png
 
 	$ git add .
 	$ git status
-	# On branch master
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#       modified:   README.txt
-	#       modified:   benchmarks.rb
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        modified:   README.txt
+	        modified:   benchmarks.rb
+	
 
 就在 “Changes to be committed” 下面，括号中有提示，可以使用 `git reset HEAD <file>...` 的方式取消暂存。好吧，我们来试试取消暂存 benchmarks.rb 文件：
 
 	$ git reset HEAD benchmarks.rb
-	benchmarks.rb: locally modified
+	Unstaged changes after reset:
+	M       benchmarks.rb
 	$ git status
-	# On branch master
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#       modified:   README.txt
-	#
-	# Changes not staged for commit:
-	#   (use "git add <file>..." to update what will be committed)
-	#   (use "git checkout -- <file>..." to discard changes in working directory)
-	#
-	#       modified:   benchmarks.rb
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        modified:   README.txt
+	
+	Changes not staged for commit:
+	  (use "git add <file>..." to update what will be committed)
+	  (use "git checkout -- <file>..." to discard changes in working directory)
+	
+	        modified:   benchmarks.rb
+	
 
 这条命令看起来有些古怪，先别管，能用就行。现在 benchmarks.rb 文件又回到了之前已修改未暂存的状态。
 
@@ -685,23 +737,23 @@ Insert 18333fig0202.png
 
 如果觉得刚才对 benchmarks.rb 的修改完全没有必要，该如何取消修改，回到之前的状态（也就是修改之前的版本）呢？`git status` 同样提示了具体的撤消方法，接着上面的例子，现在未暂存区域看起来像这样：
 
-	# Changes not staged for commit:
-	#   (use "git add <file>..." to update what will be committed)
-	#   (use "git checkout -- <file>..." to discard changes in working directory)
-	#
-	#       modified:   benchmarks.rb
-	#
+	Changes not staged for commit:
+	  (use "git add <file>..." to update what will be committed)
+	  (use "git checkout -- <file>..." to discard changes in working directory)
+	
+	        modified:   benchmarks.rb
+	
 
 在第二个括号中，我们看到了抛弃文件修改的命令（至少在 Git 1.6.1 以及更高版本中会这样提示，如果你还在用老版本，我们强烈建议你升级，以获取最佳的用户体验），让我们试试看：
 
 	$ git checkout -- benchmarks.rb
 	$ git status
-	# On branch master
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#       modified:   README.txt
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        modified:   README.txt
+	
 
 可以看到，该文件已经恢复到修改前的版本。你可能已经意识到了，这条命令有些危险，所有对文件的修改都没有了，因为我们刚刚把之前版本的文件复制过来重写了此文件。所以在用这条命令前，请务必确定真的不再需要保留刚才的修改。如果只是想回退版本，同时保留刚才的修改以便将来继续工作，可以用下章介绍的 stashing 和分支来处理，应该会更好些。
 
@@ -709,19 +761,20 @@ Insert 18333fig0202.png
 
 ## 远程仓库的使用 ##
 
-要参与任何一个 Git 项目的协作，必须要了解该如何管理远程仓库。远程仓库是指托管在网络上的项目仓库，可能会有好多个，其中有些你只能读，另外有些可以写。同他人协作开发某个项目时，需要管理这些远程仓库，以便推送或拉取数据，分享各自的工作进展。管理远程仓库的工作，包括添加远程库，移除废弃的远程库，管理各式远程库分支，定义是否跟踪这些分支，等等。本节我们将详细讨论远程库的管理和使用。
+要参与任何一个 Git 项目的协作，必须要了解该如何管理远程仓库。远程仓库是指托管在网络上的项目仓库，可能会有好多个，其中有些你只能读，另外有些可以写。同他人协作开发某个项目时，需要管理这些远程仓库，以便推送或拉取数据，分享各自的工作进展。
+管理远程仓库的工作，包括添加远程库，移除废弃的远程库，管理各式远程库分支，定义是否跟踪这些分支，等等。本节我们将详细讨论远程库的管理和使用。
 
 ### 查看当前的远程库 ###
 
 要查看当前配置有哪些远程仓库，可以用 `git remote` 命令，它会列出每个远程库的简短名字。在克隆完某个项目后，至少可以看到一个名为 origin 的远程库，Git 默认使用这个名字来标识你所克隆的原始仓库：
 
 	$ git clone git://github.com/schacon/ticgit.git
-	Initialized empty Git repository in /private/tmp/ticgit/.git/
-	remote: Counting objects: 595, done.
-	remote: Compressing objects: 100% (269/269), done.
-	remote: Total 595 (delta 255), reused 589 (delta 253)
-	Receiving objects: 100% (595/595), 73.31 KiB | 1 KiB/s, done.
-	Resolving deltas: 100% (255/255), done.
+	Cloning into 'ticgit'...
+	remote: Reusing existing pack: 1857, done.
+	remote: Total 1857 (delta 0), reused 0 (delta 0)
+	Receiving objects: 100% (1857/1857), 374.35 KiB | 193.00 KiB/s, done.
+	Resolving deltas: 100% (772/772), done.
+	Checking connectivity... done.
 	$ cd ticgit
 	$ git remote
 	origin
@@ -729,7 +782,8 @@ Insert 18333fig0202.png
 也可以加上 `-v` 选项（译注：此为 `--verbose` 的简写，取首字母），显示对应的克隆地址：
 
 	$ git remote -v
-	origin	git://github.com/schacon/ticgit.git
+	origin  git://github.com/schacon/ticgit.git (fetch)
+	origin  git://github.com/schacon/ticgit.git (push)
 
 如果有多个远程仓库，此命令将全部列出。比如在我的 Grit 项目中，可以看到：
 
@@ -891,6 +945,7 @@ Git 使用的标签有两种类型：轻量级的（lightweight）和含附注
 	Date:   Mon Feb 9 14:45:11 2009 -0800
 
 	my version 1.4
+
 	commit 15027957951b64cf874c3557a0f3547bd83b3ff6
 	Merge: 4a447f7... a6b4c97...
 	Author: Scott Chacon <schacon@gee-mail.com>
diff --git a/zh/03-git-branching/01-chapter3.markdown b/zh/03-git-branching/01-chapter3.markdown
index aacd93361..643c697cc 100644
--- a/zh/03-git-branching/01-chapter3.markdown
+++ b/zh/03-git-branching/01-chapter3.markdown
@@ -19,17 +19,17 @@
 
 现在，Git 仓库中有五个对象：三个表示文件快照内容的 blob 对象；一个记录着目录树内容及其中各个文件对应 blob 对象索引的 tree 对象；以及一个包含指向 tree 对象（根目录）的索引和其他提交信息元数据的 commit 对象。概念上来说，仓库中的各个对象保存的数据和相互关系看起来如图 3-1 所示：
 
-Insert 18333fig0301.png 
+Insert 18333fig0301.png
 图 3-1. 单个提交对象在仓库中的数据结构
 
 作些修改后再次提交，那么这次的提交对象会包含一个指向上次提交对象的指针（译注：即下图中的 parent 对象）。两次提交后，仓库历史会变成图 3-2 的样子：
 
-Insert 18333fig0302.png 
+Insert 18333fig0302.png
 图 3-2. 多个提交对象之间的链接关系
 
 现在来谈分支。Git 中的分支，其实本质上仅仅是个指向 commit 对象的可变指针。Git 会使用 master 作为分支的默认名字。在若干次提交后，你其实已经有了一个指向最后一次提交对象的 master 分支，它在每次提交的时候都会自动向前移动。
 
-Insert 18333fig0303.png 
+Insert 18333fig0303.png
 图 3-3. 分支其实就是从某个提交对象往回看的历史
 
 那么，Git 又是如何创建一个新的分支的呢？答案很简单，创建一个新的分支指针。比如新建一个 testing 分支，可以使用 `git branch` 命令：
@@ -38,12 +38,12 @@ Insert 18333fig0303.png
 
 这会在当前 commit 对象上新建一个分支指针（见图 3-4）。
 
-Insert 18333fig0304.png 
+Insert 18333fig0304.png
 图 3-4. 多个分支指向提交数据的历史
 
 那么，Git 是如何知道你当前在哪个分支上工作的呢？其实答案也很简单，它保存着一个名为 HEAD 的特别指针。请注意它和你熟知的许多其他版本控制系统（比如 Subversion 或 CVS）里的 HEAD 概念大不相同。在 Git 中，它是一个指向你正在工作中的本地分支的指针（译注：将 HEAD 想象为当前分支的别名。）。运行 `git branch` 命令，仅仅是建立了一个新的分支，但不会自动切换到这个分支中去，所以在这个例子中，我们依然还在 master 分支里工作（参考图 3-5）。
 
-Insert 18333fig0305.png 
+Insert 18333fig0305.png
 图 3-5. HEAD 指向当前所在的分支
 
 要切换到其他分支，可以执行 `git checkout` 命令。我们现在转换到新建的 testing 分支：
@@ -52,7 +52,7 @@ Insert 18333fig0305.png
 
 这样 HEAD 就指向了 testing 分支（见图3-6）。
 
-Insert 18333fig0306.png 
+Insert 18333fig0306.png
 图 3-6. HEAD 在你转换分支时指向新的分支
 
 这样的实现方式会给我们带来什么好处呢？好吧，现在不妨再提交一次：
@@ -62,7 +62,7 @@ Insert 18333fig0306.png
 
 图 3-7 展示了提交后的结果。
 
-Insert 18333fig0307.png 
+Insert 18333fig0307.png
 图 3-7. 每次提交后 HEAD 随着分支一起向前移动
 
 非常有趣，现在 testing 分支向前移动了一格，而 master 分支仍然指向原先 `git checkout` 时所在的 commit 对象。现在我们回到 master 分支看看：
@@ -71,7 +71,7 @@ Insert 18333fig0307.png
 
 图 3-8 显示了结果。
 
-Insert 18333fig0308.png 
+Insert 18333fig0308.png
 图 3-8. HEAD 在一次 checkout 之后移动到了另一个分支
 
 这条命令做了两件事。它把 HEAD 指针移回到 master 分支，并把工作目录中的文件换成了 master 分支所指向的快照内容。也就是说，现在开始所做的改动，将始于本项目中一个较老的版本。它的主要作用是将 testing 分支里作出的修改暂时取消，这样你就可以向另一个方向进行开发。
@@ -83,7 +83,7 @@ Insert 18333fig0308.png
 
 现在我们的项目提交历史产生了分叉（如图 3-9 所示），因为刚才我们创建了一个分支，转换到其中进行了一些工作，然后又回到原来的主分支进行了另外一些工作。这些改变分别孤立在不同的分支里：我们可以在不同分支里反复切换，并在时机成熟时把它们合并到一起。而所有这些工作，仅仅需要 `branch` 和 `checkout` 这两条命令就可以完成。
 
-Insert 18333fig0309.png 
+Insert 18333fig0309.png
 图 3-9. 不同流向的分支历史
 
 由于 Git 中的分支实际上仅是一个包含所指对象校验和（40 个字符长度 SHA-1 字串）的文件，所以创建和销毁一个分支就变得非常廉价。说白了，新建一个分支就是向一个文件写入 41 个字节（外加一个换行符）那么简单，当然也就很快了。
@@ -111,13 +111,13 @@ Insert 18333fig0309.png
 
 首先，我们假设你正在项目中愉快地工作，并且已经提交了几次更新（见图 3-10）。
 
-Insert 18333fig0310.png 
+Insert 18333fig0310.png
 图 3-10. 一个简短的提交历史
 
 现在，你决定要修补问题追踪系统上的 #53 问题。顺带说明下，Git 并不同任何特定的问题追踪系统打交道。这里为了说明要解决的问题，才把新建的分支取名为 iss53。要新建并切换到该分支，运行 `git checkout` 并加上 `-b` 参数：
 
 	$ git checkout -b iss53
-	Switched to a new branch "iss53"
+	Switched to a new branch 'iss53'
 
 这相当于执行下面这两条命令：
 
@@ -126,7 +126,7 @@ Insert 18333fig0310.png
 
 图 3-11 示意该命令的执行结果。
 
-Insert 18333fig0311.png 
+Insert 18333fig0311.png
 图 3-11. 创建了一个新分支的指针
 
 接着你开始尝试修复问题，在提交了若干次更新后，`iss53` 分支的指针也会随着向前推进，因为它就是当前分支（换句话说，当前的 `HEAD` 指针正指向 `iss53`，见图 3-12）：
@@ -134,7 +134,7 @@ Insert 18333fig0311.png
 	$ vim index.html
 	$ git commit -a -m 'added a new footer [issue 53]'
 
-Insert 18333fig0312.png 
+Insert 18333fig0312.png
 图 3-12. iss53 分支随工作进展向前推进
 
 现在你就接到了那个网站问题的紧急电话，需要马上修补。有了 Git ，我们就不需要同时发布这个补丁和 `iss53` 里作出的修改，也不需要在创建和发布该补丁到服务器之前花费大力气来复原这些修改。唯一需要的仅仅是切换回 `master` 分支。
@@ -142,20 +142,20 @@ Insert 18333fig0312.png
 不过在此之前，留心你的暂存区或者工作目录里，那些还没有提交的修改，它会和你即将检出的分支产生冲突从而阻止 Git 为你切换分支。切换分支的时候最好保持一个清洁的工作区域。稍后会介绍几个绕过这种问题的办法（分别叫做 stashing 和 commit amending）。目前已经提交了所有的修改，所以接下来可以正常转换到 `master` 分支：
 
 	$ git checkout master
-	Switched to branch "master"
+	Switched to branch 'master'
 
 此时工作目录中的内容和你在解决问题 #53 之前一模一样，你可以集中精力进行紧急修补。这一点值得牢记：Git 会把工作目录的内容恢复为检出某分支时它所指向的那个提交对象的快照。它会自动添加、删除和修改文件以确保目录的内容和你当时提交时完全一样。
 
 接下来，你得进行紧急修补。我们创建一个紧急修补分支 `hotfix` 来开展工作，直到搞定（见图 3-13）：
 
-	$ git checkout -b 'hotfix'
-	Switched to a new branch "hotfix"
+	$ git checkout -b hotfix
+	Switched to a new branch 'hotfix'
 	$ vim index.html
 	$ git commit -a -m 'fixed the broken email address'
-	[hotfix]: created 3a0874c: "fixed the broken email address"
-	 1 files changed, 0 insertions(+), 1 deletions(-)
+	[hotfix 3a0874c] fixed the broken email address
+	 1 files changed, 1 deletion(-)
 
-Insert 18333fig0313.png 
+Insert 18333fig0313.png
 图 3-13. hotfix 分支是从 master 分支所在点分化出来的
 
 有必要作些测试，确保修补是成功的，然后回到 `master` 分支并把它合并进来，然后发布到生产服务器。用 `git merge` 命令来进行合并：
@@ -163,32 +163,32 @@ Insert 18333fig0313.png
 	$ git checkout master
 	$ git merge hotfix
 	Updating f42c576..3a0874c
-	Fast forward
-	 README |    1 -
-	 1 files changed, 0 insertions(+), 1 deletions(-)
+	Fast-forward
+	 README | 1 -
+	 1 file changed, 1 deletion(-)
 
 请注意，合并时出现了“Fast forward”的提示。由于当前 `master` 分支所在的提交对象是要并入的 `hotfix` 分支的直接上游，Git 只需把 `master` 分支指针直接右移。换句话说，如果顺着一个分支走下去可以到达另一个分支的话，那么 Git 在合并两者时，只会简单地把指针右移，因为这种单线的历史分支不存在任何需要解决的分歧，所以这种合并过程可以称为快进（Fast forward）。
 
 现在最新的修改已经在当前 `master` 分支所指向的提交对象中了，可以部署到生产服务器上去了（见图 3-14）。
 
-Insert 18333fig0314.png 
+Insert 18333fig0314.png
 图 3-14. 合并之后，master 分支和 hotfix 分支指向同一位置。
 
 在那个超级重要的修补发布以后，你想要回到被打扰之前的工作。由于当前 `hotfix` 分支和 `master` 都指向相同的提交对象，所以 `hotfix` 已经完成了历史使命，可以删掉了。使用 `git branch` 的 `-d` 选项执行删除操作：
 
 	$ git branch -d hotfix
-	Deleted branch hotfix (3a0874c).
+	Deleted branch hotfix (was 3a0874c).
 
 现在回到之前未完成的 #53 问题修复分支上继续工作（图 3-15）：
 
 	$ git checkout iss53
-	Switched to branch "iss53"
+	Switched to branch 'iss53'
 	$ vim index.html
 	$ git commit -a -m 'finished the new footer [issue 53]'
-	[iss53]: created ad82d7a: "finished the new footer [issue 53]"
-	 1 files changed, 1 insertions(+), 0 deletions(-)
+	[iss53 ad82d7a] finished the new footer [issue 53]
+	 1 file changed, 1 insertion(+)
 
-Insert 18333fig0315.png 
+Insert 18333fig0315.png
 图 3-15. iss53 分支可以不受影响继续推进。
 
 值得注意的是之前 `hotfix` 分支的修改内容尚未包含到 `iss53` 中来。如果需要纳入此次修补，可以用 `git merge master` 把 master 分支合并到 `iss53`；或者等 `iss53` 完成之后，再将 `iss53` 分支中的更新并入 `master`。
@@ -199,20 +199,21 @@ Insert 18333fig0315.png
 
 	$ git checkout master
 	$ git merge iss53
-	Merge made by recursive.
-	 README |    1 +
-	 1 files changed, 1 insertions(+), 0 deletions(-)
+	Auto-merging README
+	Merge made by the 'recursive' strategy.
+	 README | 1 +
+	 1 file changed, 1 insertion(+)
 
 请注意，这次合并操作的底层实现，并不同于之前 `hotfix` 的并入方式。因为这次你的开发历史是从更早的地方开始分叉的。由于当前 `master` 分支所指向的提交对象（C4）并不是 `iss53` 分支的直接祖先，Git 不得不进行一些额外处理。就此例而言，Git 会用两个分支的末端（C4 和 C5）以及它们的共同祖先（C2）进行一次简单的三方合并计算。图 3-16 用红框标出了 Git 用于合并的三个提交对象：
 
-Insert 18333fig0316.png 
+Insert 18333fig0316.png
 图 3-16. Git 为分支合并自动识别出最佳的同源合并点。
 
 这次，Git 没有简单地把分支指针右移，而是对三方合并后的结果重新做一个新的快照，并自动创建一个指向它的提交对象（C6）（见图 3-17）。这个提交对象比较特殊，它有两个祖先（C4 和 C5）。
 
 值得一提的是 Git 可以自己裁决哪个共同祖先才是最佳合并基础；这和 CVS 或 Subversion（1.5 以后的版本）不同，它们需要开发者手工指定合并基础。所以此特性让 Git 的合并操作比其他系统都要简单不少。
 
-Insert 18333fig0317.png 
+Insert 18333fig0317.png
 图 3-17. Git 自动创建了一个包含了合并结果的提交对象。
 
 既然之前的工作成果已经合并到 `master` 了，那么 `iss53` 也就没用了。你可以就此删除它，并在问题追踪系统里关闭该问题。
@@ -230,25 +231,27 @@ Insert 18333fig0317.png
 
 Git 作了合并，但没有提交，它会停下来等你解决冲突。要看看哪些文件在合并时发生冲突，可以用 `git status` 查阅：
 
-	[master*]$ git status
-	index.html: needs merge
-	# On branch master
-	# Changes not staged for commit:
-	#   (use "git add <file>..." to update what will be committed)
-	#   (use "git checkout -- <file>..." to discard changes in working directory)
-	#
-	#	unmerged:   index.html
-	#
+	$ git status
+	On branch master
+	You have unmerged paths.
+	  (fix conflicts and run "git commit")
+	
+	Unmerged paths:
+	  (use "git add <file>..." to mark resolution)
+	
+	        both modified:      index.html
+	
+	no changes added to commit (use "git add" and/or "git commit -a")
 
 任何包含未解决冲突的文件都会以未合并（unmerged）的状态列出。Git 会在有冲突的文件里加入标准的冲突解决标记，可以通过它们来手工定位并解决这些冲突。可以看到此文件包含类似下面这样的部分：
 
-	<<<<<<< HEAD:index.html
+	<<<<<<< HEAD
 	<div id="footer">contact : email.support@github.com</div>
 	=======
 	<div id="footer">
 	  please contact us at support@github.com
 	</div>
-	>>>>>>> iss53:index.html
+	>>>>>>> iss53
 
 可以看到 `=======` 隔开的上半部分，是 `HEAD`（即 `master` 分支，在运行 `merge` 命令时所切换到的分支）中的内容，下半部分是在 `iss53` 分支中的内容。解决冲突的办法无非是二者选其一或者由你亲自整合到一起。比如你可以通过把这段内容替换为下面这样来解决：
 
@@ -259,12 +262,17 @@ Git 作了合并，但没有提交，它会停下来等你解决冲突。要看
 这个解决方案各采纳了两个分支中的一部分内容，而且我还删除了 `<<<<<<<`，`=======` 和 `>>>>>>>` 这些行。在解决了所有文件里的所有冲突后，运行 `git add` 将把它们标记为已解决状态（译注：实际上就是来一次快照保存到暂存区域。）。因为一旦暂存，就表示冲突已经解决。如果你想用一个有图形界面的工具来解决这些问题，不妨运行 `git mergetool`，它会调用一个可视化的合并工具并引导你解决所有冲突：
 
 	$ git mergetool
-	merge tool candidates: kdiff3 tkdiff xxdiff meld gvimdiff opendiff emerge vimdiff
-	Merging the files: index.html
+
+	This message is displayed because 'merge.tool' is not configured.
+	See 'git mergetool --tool-help' or 'git help config' for more details.
+	'git mergetool' will now attempt to use one of the following tools:
+	opendiff kdiff3 tkdiff xxdiff meld tortoisemerge gvimdiff diffuse diffmerge ecmerge p4merge araxis bc3 codecompare vimdiff emerge
+	Merging:
+	index.html
 
 	Normal merge conflict for 'index.html':
-	  {local}: modified
-	  {remote}: modified
+	  {local}: modified file
+	  {remote}: modified file
 	Hit return to start merge resolution tool (opendiff):
 
 如果不想用默认的合并工具（Git 为我默认选择了 `opendiff`，因为我在 Mac 上运行了该命令），你可以在上方"merge tool candidates"里找到可用的合并工具列表，输入你想用的工具名。我们将在第七章讨论怎样改变环境中的默认值。
@@ -274,12 +282,12 @@ Git 作了合并，但没有提交，它会停下来等你解决冲突。要看
 再运行一次 `git status` 来确认所有冲突都已解决：
 
 	$ git status
-	# On branch master
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#	modified:   index.html
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        modified:   index.html
+	
 
 如果觉得满意了，并且确认所有冲突都已解决，也就是进入了暂存区，就可以用 `git commit` 来完成这次合并提交。提交的记录差不多是这样：
 
@@ -288,9 +296,9 @@ Git 作了合并，但没有提交，它会停下来等你解决冲突。要看
 	Conflicts:
 	  index.html
 	#
-	# It looks like you may be committing a MERGE.
+	# It looks like you may be committing a merge.
 	# If this is not correct, please remove the file
-	# .git/MERGE_HEAD
+	#       .git/MERGE_HEAD
 	# and try again.
 	#
 
@@ -330,7 +338,7 @@ Git 作了合并，但没有提交，它会停下来等你解决冲突。要看
 它会显示还未合并进来的分支。由于这些分支中还包含着尚未合并进来的工作成果，所以简单地用 `git branch -d` 删除该分支会提示错误，因为那样做会丢失数据：
 
 	$ git branch -d testing
-	error: The branch 'testing' is not an ancestor of your current HEAD.
+	error: The branch 'testing' is not fully merged.
 	If you are sure you want to delete it, run 'git branch -D testing'.
 
 不过，如果你确实想要删除该分支上的改动，可以用大写的删除选项 `-D` 强制执行，就像上面提示信息中给出的那样。
@@ -347,12 +355,12 @@ Git 作了合并，但没有提交，它会停下来等你解决冲突。要看
 
 本质上我们刚才谈论的，是随着提交对象不断右移的指针。稳定分支的指针总是在提交历史中落后一大截，而前沿分支总是比较靠前（见图 3-18）。
 
-Insert 18333fig0318.png 
+Insert 18333fig0318.png
 图 3-18. 稳定分支总是比较老旧。
 
 或者把它们想象成工作流水线，或许更好理解一些，经过测试的提交对象集合被遴选到更稳定的流水线（见图 3-19）。
 
-Insert 18333fig0319.png 
+Insert 18333fig0319.png
 图 3-19. 想象成流水线可能会容易点。
 
 你可以用这招维护不同层次的稳定性。某些大项目还会有个 `proposed`（建议）或 `pu`（proposed updates，建议更新）分支，它包含着那些可能还没有成熟到进入 `next` 或 `master` 的内容。这么做的目的是拥有不同层次的稳定性：当这些分支进入到更稳定的水平时，再把它们合并到更高层分支中去。再次说明下，使用多个长期分支的做法并非必需，不过一般来说，对于特大型项目或特复杂的项目，这么做确实更容易管理。
@@ -365,12 +373,12 @@ Insert 18333fig0319.png
 
 现在我们来看一个实际的例子。请看图 3-20，由下往上，起先我们在 `master` 工作到 C1，然后开始一个新分支 `iss91` 尝试修复 91 号缺陷，提交到 C6 的时候，又冒出一个解决该问题的新办法，于是从之前 C4 的地方又分出一个分支 `iss91v2`，干到 C8 的时候，又回到主干 `master` 中提交了 C9 和 C10，再回到 `iss91v2` 继续工作，提交 C11，接着，又冒出个不太确定的想法，从 `master` 的最新提交 C10 处开了个新的分支 `dumbidea` 做些试验。
 
-Insert 18333fig0320.png 
+Insert 18333fig0320.png
 图 3-20. 拥有多个特性分支的提交历史。
 
 现在，假定两件事情：我们最终决定使用第二个解决方案，即 `iss91v2` 中的办法；另外，我们把 `dumbidea` 分支拿给同事们看了以后，发现它竟然是个天才之作。所以接下来，我们准备抛弃原来的 `iss91` 分支（实际上会丢弃 C5 和 C6），直接在主干中并入另外两个分支。最终的提交历史将变成图 3-21 这样：
 
-Insert 18333fig0321.png 
+Insert 18333fig0321.png
 图 3-21. 合并了 dumbidea 和 iss91v2 后的分支历史。
 
 请务必牢记这些分支全部都是本地分支，这一点很重要。当你在使用分支及合并的时候，一切都是在你自己的 Git 仓库中进行的 — 完全不涉及与服务器的交互。
@@ -383,27 +391,27 @@ Insert 18333fig0321.png
 
 可能有点乱，我们不妨举例说明。假设你们团队有个地址为 `git.ourcompany.com` 的 Git 服务器。如果你从这里克隆，Git 会自动为你将此远程仓库命名为 `origin`，并下载其中所有的数据，建立一个指向它的 `master` 分支的指针，在本地命名为 `origin/master`，但你无法在本地更改其数据。接着，Git 建立一个属于你自己的本地 `master` 分支，始于 `origin` 上 `master` 分支相同的位置，你可以就此开始工作（见图 3-22）：
 
-Insert 18333fig0322.png 
+Insert 18333fig0322.png
 图 3-22. 一次 Git 克隆会建立你自己的本地分支 master 和远程分支 origin/master，并且将它们都指向 `origin` 上的 `master` 分支。
 
 如果你在本地 `master` 分支做了些改动，与此同时，其他人向 `git.ourcompany.com` 推送了他们的更新，那么服务器上的 `master` 分支就会向前推进，而于此同时，你在本地的提交历史正朝向不同方向发展。不过只要你不和服务器通讯，你的 `origin/master` 指针仍然保持原位不会移动（见图 3-23）。
 
-Insert 18333fig0323.png 
+Insert 18333fig0323.png
 图 3-23. 在本地工作的同时有人向远程仓库推送内容会让提交历史开始分流。
 
 可以运行 `git fetch origin` 来同步远程服务器上的数据到本地。该命令首先找到 `origin` 是哪个服务器（本例为 `git.ourcompany.com`），从上面获取你尚未拥有的数据，更新你本地的数据库，然后把 `origin/master` 的指针移到它最新的位置上（见图 3-24）。
 
-Insert 18333fig0324.png 
+Insert 18333fig0324.png
 图 3-24. git fetch 命令会更新 remote 索引。
 
 为了演示拥有多个远程分支（在不同的远程服务器上）的项目是如何工作的，我们假设你还有另一个仅供你的敏捷开发小组使用的内部服务器 `git.team1.ourcompany.com`。可以用第二章中提到的 `git remote add` 命令把它加为当前项目的远程分支之一。我们把它命名为 `teamone`，以便代替完整的 Git URL 以方便使用（见图 3-25）。
 
-Insert 18333fig0325.png 
+Insert 18333fig0325.png
 图 3-25. 把另一个服务器加为远程仓库
 
 现在你可以用 `git fetch teamone` 来获取小组服务器上你还没有的数据了。由于当前该服务器上的内容是你 `origin` 服务器上的子集，Git 不会下载任何数据，而只是简单地创建一个名为 `teamone/master` 的远程分支，指向 `teamone` 服务器上 `master` 分支所在的提交对象 `31b8e`（见图 3-26）。
 
-Insert 18333fig0326.png 
+Insert 18333fig0326.png
 图 3-26. 你在本地有了一个指向 teamone 服务器上 master 分支的索引。
 
 ### 推送本地分支 ###
@@ -437,8 +445,8 @@ Insert 18333fig0326.png
 如果要把该远程分支的内容合并到当前分支，可以运行 `git merge origin/serverfix`。如果想要一份自己的 `serverfix` 来开发，可以在远程分支的基础上分化出一个新的分支来：
 
 	$ git checkout -b serverfix origin/serverfix
-	Branch serverfix set up to track remote branch refs/remotes/origin/serverfix.
-	Switched to a new branch "serverfix"
+	Branch serverfix set up to track remote branch serverfix from origin.
+	Switched to a new branch 'serverfix'
 
 这会切换到新建的 `serverfix` 本地分支，其内容同远程分支 `origin/serverfix` 一致，这样你就可以在里面继续开发了。
 
@@ -449,14 +457,14 @@ Insert 18333fig0326.png
 在克隆仓库时，Git 通常会自动创建一个名为 `master` 的分支来跟踪 `origin/master`。这正是 `git push` 和 `git pull` 一开始就能正常工作的原因。当然，你可以随心所欲地设定为其它跟踪分支，比如 `origin` 上除了 `master` 之外的其它分支。刚才我们已经看到了这样的一个例子：`git checkout -b [分支名] [远程名]/[分支名]`。如果你有 1.6.2 以上版本的 Git，还可以用 `--track` 选项简化：
 
 	$ git checkout --track origin/serverfix
-	Branch serverfix set up to track remote branch refs/remotes/origin/serverfix.
-	Switched to a new branch "serverfix"
+	Branch serverfix set up to track remote branch serverfix from origin.
+	Switched to a new branch 'serverfix'
 
 要为本地分支设定不同于远程分支的名字，只需在第一个版本的命令里换个名字：
 
 	$ git checkout -b sf origin/serverfix
-	Branch sf set up to track remote branch refs/remotes/origin/serverfix.
-	Switched to a new branch "sf"
+	Branch sf set up to track remote branch serverfix from origin.
+	Switched to a new branch 'sf'
 
 现在你的本地分支 `sf` 会自动将推送和抓取数据的位置定位到 `origin/serverfix` 了。
 
@@ -478,12 +486,12 @@ Insert 18333fig0326.png
 
 请回顾之前有关合并的一节（见图 3-27），你会看到开发进程分叉到两个不同分支，又各自提交了更新。
 
-Insert 18333fig0327.png 
+Insert 18333fig0327.png
 图 3-27. 最初分叉的提交历史。
 
 之前介绍过，最容易的整合分支的方法是 `merge` 命令，它会把两个分支最新的快照（C3 和 C4）以及二者最新的共同祖先（C2）进行三方合并，合并的结果是产生一个新的提交对象（C5）。如图 3-28 所示：
 
-Insert 18333fig0328.png 
+Insert 18333fig0328.png
 图 3-28. 通过合并一个分支来整合分叉了的历史。
 
 其实，还有另外一个选择：你可以把在 C3 里产生的变化补丁在 C4 的基础上重新打一遍。在 Git 里，这种操作叫做_衍合（rebase）_。有了 `rebase` 命令，就可以把在一个分支里提交的改变移到另一个分支里重放一遍。
@@ -497,12 +505,12 @@ Insert 18333fig0328.png
 
 它的原理是回到两个分支最近的共同祖先，根据当前分支（也就是要进行衍合的分支 `experiment`）后续的历次提交对象（这里只有一个 C3），生成一系列文件补丁，然后以基底分支（也就是主干分支 `master`）最后一个提交对象（C4）为新的出发点，逐个应用之前准备好的补丁文件，最后会生成一个新的合并提交对象（C3'），从而改写 `experiment` 的提交历史，使它成为 `master` 分支的直接下游，如图 3-29 所示：
 
-Insert 18333fig0329.png 
+Insert 18333fig0329.png
 图 3-29. 把 C3 里产生的改变到 C4 上重演一遍。
 
 现在回到 `master` 分支，进行一次快进合并（见图 3-30）：
 
-Insert 18333fig0330.png 
+Insert 18333fig0330.png
 图 3-30. master 分支的快进。
 
 现在的 C3' 对应的快照，其实和普通的三方合并，即上个例子中的 C5 对应的快照内容一模一样了。虽然最后整合得到的结果没有任何区别，但衍合能产生一个更为整洁的提交历史。如果视察一个衍合过的分支的历史记录，看起来会更清楚：仿佛所有修改都是在一根线上先后进行的，尽管实际上它们原本是同时并行发生的。
@@ -515,7 +523,7 @@ Insert 18333fig0330.png
 
 衍合也可以放到其他分支进行，并不一定非得根据分化之前的分支。以图 3-31 的历史为例，我们为了给服务器端代码添加一些功能而创建了特性分支 `server`，然后提交 C3 和 C4。然后又从 C3 的地方再增加一个 `client` 分支来对客户端代码进行一些相应修改，所以提交了 C8 和 C9。最后，又回到 `server` 分支提交了 C10。
 
-Insert 18333fig0331.png 
+Insert 18333fig0331.png
 图 3-31. 从一个特性分支里再分出一个特性分支的历史。
 
 假设在接下来的一次软件发布中，我们决定先把客户端的修改并到主线中，而暂缓并入服务端软件的修改（因为还需要进一步测试）。这个时候，我们就可以把基于 `server` 分支而非 `master` 分支的改变（即 C8 和 C9），跳过 `server` 直接放到 `master` 分支中重演一遍，但这需要用 `git rebase` 的 `--onto` 选项指定新的基底分支 `master`：
@@ -524,7 +532,7 @@ Insert 18333fig0331.png
 
 这好比在说：“取出 `client` 分支，找出 `client` 分支和 `server` 分支的共同祖先之后的变化，然后把它们在 `master` 上重演一遍”。是不是有点复杂？不过它的结果如图 3-32 所示，非常酷（译注：虽然 `client` 里的 C8, C9 在 C3 之后，但这仅表明时间上的先后，而非在 C3 修改的基础上进一步改动，因为 `server` 和 `client` 这两个分支对应的代码应该是两套文件，虽然这么说不是很严格，但应理解为在 C3 时间点之后，对另外的文件所做的 C8，C9 修改，放到主干重演。）：
 
-Insert 18333fig0332.png 
+Insert 18333fig0332.png
 图 3-32. 将特性分支上的另一个特性分支衍合到其他分支。
 
 现在可以快进 `master` 分支了（见图 3-33）：
@@ -532,7 +540,7 @@ Insert 18333fig0332.png
 	$ git checkout master
 	$ git merge client
 
-Insert 18333fig0333.png 
+Insert 18333fig0333.png
 图 3-33. 快进 master 分支，使之包含 client 分支的变化。
 
 现在我们决定把 `server` 分支的变化也包含进来。我们可以直接把 `server` 分支衍合到 `master`，而不用手工切换到 `server` 分支后再执行衍合操作 — `git rebase [主分支] [特性分支]` 命令会先取出特性分支 `server`，然后在主分支 `master` 上重演：
@@ -541,7 +549,7 @@ Insert 18333fig0333.png
 
 于是，`server` 的进度应用到 `master` 的基础上，如图 3-34 所示：
 
-Insert 18333fig0334.png 
+Insert 18333fig0334.png
 图 3-34. 在 master 分支上衍合 server 分支。
 
 然后就可以快进主干分支 `master` 了：
@@ -554,7 +562,7 @@ Insert 18333fig0334.png
 	$ git branch -d client
 	$ git branch -d server
 
-Insert 18333fig0335.png 
+Insert 18333fig0335.png
 图 3-35. 最终的提交历史
 
 ### 衍合的风险 ###
@@ -569,22 +577,22 @@ Insert 18333fig0335.png
 
 下面我们用一个实际例子来说明为什么公开的衍合会带来问题。假设你从一个中央服务器克隆然后在它的基础上搞了一些开发，提交历史类似图 3-36 所示：
 
-Insert 18333fig0336.png 
+Insert 18333fig0336.png
 图 3-36. 克隆一个仓库，在其基础上工作一番。
 
 现在，某人在 C1 的基础上做了些改变，并合并他自己的分支得到结果 C6，推送到中央服务器。当你抓取并合并这些数据到你本地的开发分支中后，会得到合并结果 C7，历史提交会变成图 3-37 这样：
 
-Insert 18333fig0337.png 
+Insert 18333fig0337.png
 图 3-37. 抓取他人提交，并入自己主干。
 
 接下来，那个推送 C6 上来的人决定用衍合取代之前的合并操作；继而又用 `git push --force` 覆盖了服务器上的历史，得到 C4'。而之后当你再从服务器上下载最新提交后，会得到：
 
-Insert 18333fig0338.png 
+Insert 18333fig0338.png
 图 3-38. 有人推送了衍合后得到的 C4'，丢弃了你作为开发基础的 C4 和 C6。
 
 下载更新后需要合并，但此时衍合产生的提交对象 C4' 的 SHA-1 校验值和之前 C4 完全不同，所以 Git 会把它们当作新的提交对象处理，而实际上此刻你的提交历史 C7 中早已经包含了 C4 的修改内容，于是合并操作会把 C7 和 C4' 合并为 C8（见图 3-39）:
 
-Insert 18333fig0339.png 
+Insert 18333fig0339.png
 图 3-39. 你把相同的内容又合并了一遍，生成一个新的提交 C8。
 
 C8 这一步的合并是迟早会发生的，因为只有这样你才能和其他协作者提交的内容保持同步。而在 C8 之后，你的提交历史里就会同时包含 C4 和 C4'，两者有着不同的 SHA-1 校验值，如果用 `git log` 查看历史，会看到两个提交拥有相同的作者日期与说明，令人费解。而更糟的是，当你把这样的历史推送到服务器后，会再次把这些衍合后的提交引入到中央服务器，进一步困扰其他人（译注：这个例子中，出问题的责任方是那个发布了 C6 后又用衍合发布 C4' 的人，其他人会因此反馈双重历史到共享主干，从而混淆大家的视听。）。
diff --git a/zh/04-git-server/01-chapter4.markdown b/zh/04-git-server/01-chapter4.markdown
index 4df2c0ce2..ae751aeef 100644
--- a/zh/04-git-server/01-chapter4.markdown
+++ b/zh/04-git-server/01-chapter4.markdown
@@ -55,7 +55,7 @@ Git 使用的传输协议中最常见的可能就是 SSH 了。这是因为大
 	$ git clone ssh://user@server/project.git
 
 或者不指明某个协议 — 这时 Git 会默认使用 SSH ：
-	
+
 	$ git clone user@server:project.git
 
 如果不指明用户，Git 会默认使用当前登录的用户名连接服务器。 
@@ -78,7 +78,8 @@ Git 协议是现存最快的传输协议。如果你在提供一个有很大访
 
 #### 缺点 ####
 
-Git 协议消极的一面是缺少授权机制。用 Git 协议作为访问项目的唯一方法通常是不可取的。一般的做法是，同时提供 SSH 接口，让几个开发者拥有推送（写）权限，其他人通过 `git://` 拥有只读权限。Git 协议可能也是最难架设的协议。它要求有单独的守护进程，需要定制 — 我们将在本章的 “Gitosis” 一节详细介绍它的架设 — 需要设定 `xinetd` 或类似的程序，而这些工作就没那么轻松了。该协议还要求防火墙开放 9418 端口，而企业级防火墙一般不允许对这个非标准端口的访问。大型企业级防火墙通常会封锁这个少见的端口。
+Git 协议消极的一面是缺少授权机制。用 Git 协议作为访问项目的唯一方法通常是不可取的。一般的做法是，同时提供 SSH 接口，让几个开发者拥有推送（写）权限，其他人通过 `git://` 拥有只读权限。
+Git 协议可能也是最难架设的协议。它要求有单独的守护进程，需要定制 — 我们将在本章的 “Gitosis” 一节详细介绍它的架设 — 需要设定 `xinetd` 或类似的程序，而这些工作就没那么轻松了。该协议还要求防火墙开放 9418 端口，而企业级防火墙一般不允许对这个非标准端口的访问。大型企业级防火墙通常会封锁这个少见的端口。
 
 ### HTTP/S 协议 ###
 
@@ -115,7 +116,8 @@ HTTP 协议的消极面在于，相对来说客户端效率更低。克隆或者
 开始架设 Git 服务器前，需要先把现有仓库导出为裸仓库 — 即一个不包含当前工作目录的仓库。做法直截了当，克隆时用 `--bare` 选项即可。裸仓库的目录名一般以 `.git` 结尾，像这样：
 
 	$ git clone --bare my_project my_project.git
-	Initialized empty Git repository in /opt/projects/my_project.git/
+	Cloning into bare repository 'my_project.git'...
+	done.
 
 该命令的输出或许会让人有些不解。其实 `clone` 操作基本上相当于 `git init` 加 `git fetch`，所以这里出现的其实是 `git init` 的输出，先由它建立一个空目录，而之后传输数据对象的操作并无任何输出，只是悄悄在幕后执行。现在 `my_project.git` 目录中已经有了一份 Git 目录数据的副本。
 
@@ -165,7 +167,8 @@ HTTP 协议的消极面在于，相对来说客户端效率更低。克隆或者
 
 ## 生成 SSH 公钥 ##
 
-大多数 Git 服务器都会选择使用 SSH 公钥来进行授权。系统中的每个用户都必须提供一个公钥用于授权，没有的话就要生成一个。生成公钥的过程在所有操作系统上都差不多。首先先确认一下是否已经有一个公钥了。SSH 公钥默认储存在账户的主目录下的 `~/.ssh` 目录。进去看看：
+大多数 Git 服务器都会选择使用 SSH 公钥来进行授权。系统中的每个用户都必须提供一个公钥用于授权，没有的话就要生成一个。生成公钥的过程在所有操作系统上都差不多。
+首先先确认一下是否已经有一个公钥了。SSH 公钥默认储存在账户的主目录下的 `~/.ssh` 目录。进去看看：
 
 	$ cd ~/.ssh
 	$ ls
@@ -174,11 +177,11 @@ HTTP 协议的消极面在于，相对来说客户端效率更低。克隆或者
 
 关键是看有没有用 `something` 和 `something.pub` 来命名的一对文件，这个 `something` 通常就是 `id_dsa` 或 `id_rsa`。有 `.pub` 后缀的文件就是公钥，另一个文件则是密钥。假如没有这些文件，或者干脆连 `.ssh` 目录都没有，可以用 `ssh-keygen` 来创建。该程序在 Linux/Mac 系统上由 SSH 包提供，而在 Windows 上则包含在 MSysGit 包里：
 
-	$ ssh-keygen 
+	$ ssh-keygen
 	Generating public/private rsa key pair.
-	Enter file in which to save the key (/Users/schacon/.ssh/id_rsa): 
-	Enter passphrase (empty for no passphrase): 
-	Enter same passphrase again: 
+	Enter file in which to save the key (/Users/schacon/.ssh/id_rsa):
+	Enter passphrase (empty for no passphrase):
+	Enter same passphrase again:
 	Your identification has been saved in /Users/schacon/.ssh/id_rsa.
 	Your public key has been saved in /Users/schacon/.ssh/id_rsa.pub.
 	The key fingerprint is:
@@ -188,7 +191,7 @@ HTTP 协议的消极面在于，相对来说客户端效率更低。克隆或者
 
 现在，所有做过这一步的用户都得把它们的公钥给你或者 Git 服务器的管理员（假设 SSH 服务被设定为使用公钥机制）。他们只需要复制 `.pub` 文件的内容然后发邮件给管理员。公钥的样子大致如下：
 
-	$ cat ~/.ssh/id_rsa.pub 
+	$ cat ~/.ssh/id_rsa.pub
 	ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAklOUpkDHrfHY17SbrmTIpNLTGK9Tjom/BWDSU
 	GPl+nafzlHDTYW7hdI4yZ5ew18JH4JW9jbhUFrviQzM7xlELEVf4h9lFX5QVkbPppSwg0cda3
 	Pbv7kOdJ/MTyBlWXFCR+HAo3FXRitBqxiX1nKhXpHAZsMciLq8V6RjsNAQwdsdMFvSlVK/7XA
@@ -243,6 +246,7 @@ HTTP 协议的消极面在于，相对来说客户端效率更低。克隆或者
 这样，其他人的克隆和推送也一样变得很简单：
 
 	$ git clone git@gitserver:/opt/git/project.git
+	$ cd project
 	$ vim README
 	$ git commit -am 'fix for the README file'
 	$ git push origin master
@@ -279,12 +283,17 @@ HTTP 协议的消极面在于，相对来说客户端效率更低。克隆或者
 	$ mv hooks/post-update.sample hooks/post-update
 	$ chmod a+x hooks/post-update
 
-如果用的是 Git 1.6 之前的版本，则可以省略 `mv` 命令 — Git 是从较晚的版本才开始在挂钩实例的结尾添加 .sample 后缀名的。
-
 `post-update` 挂钩是做什么的呢？其内容大致如下：
 
-	$ cat .git/hooks/post-update 
+	$ cat .git/hooks/post-update
 	#!/bin/sh
+	#
+	# An example hook script to prepare a packed repository for use over
+	# dumb transports.
+	#
+	# To enable this hook, rename this file to "post-update".
+	#
+	
 	exec git-update-server-info
 
 意思是当通过 SSH 向服务器推送时，Git 将运行这个 `git-update-server-info` 命令来更新匿名 HTTP 访问获取数据时所需要的文件。
@@ -314,7 +323,7 @@ HTTP 协议的消极面在于，相对来说客户端效率更低。克隆或者
 
 现在我们的项目已经有了可读可写和只读的连接方式，不过如果能有一个简单的 web 界面访问就更好了。Git 自带一个叫做 GitWeb 的 CGI 脚本，运行效果可以到 `http://git.kernel.org` 这样的站点体验下（见图 4-1）。
 
-Insert 18333fig0401.png 
+Insert 18333fig0401.png
 Figure 4-1. 基于网页的 GitWeb 用户界面
 
 如果想看看自己项目的效果，不妨用 Git 自带的一个命令，可以使用类似 `lighttpd` 或 `webrick` 这样轻量级的服务器启动一个临时进程。如果是在 Linux 主机上，通常都预装了 `lighttpd` ，可以到项目目录中键入 `git instaweb` 来启动。如果用的是 Mac ，Leopard 预装了 Ruby，所以 `webrick` 应该是最好的选择。如果要用 lighttpd 以外的程序来启动 `git instaweb`，可以通过 `--httpd` 选项指定：
@@ -332,7 +341,7 @@ Figure 4-1. 基于网页的 GitWeb 用户界面
 	$ git clone git://git.kernel.org/pub/scm/git/git.git
 	$ cd git/
 	$ make GITWEB_PROJECTROOT="/opt/git" \
-	        prefix=/usr gitweb/gitweb.cgi
+	        prefix=/usr gitweb
 	$ sudo cp -Rf gitweb /var/www/
 
 注意，通过指定 `GITWEB_PROJECTROOT` 变量告诉编译命令 Git 仓库的位置。然后，设置 Apache 以 CGI 方式运行该脚本，添加一个 VirtualHost 配置：
@@ -400,7 +409,7 @@ Gitosis 将会帮我们管理用户公钥，所以先把当前控制文件改名
 
 	$ ssh git@gitserver
 	PTY allocation request failed on channel 0
-	fatal: unrecognized command 'gitosis-serve schacon@quaternion'
+	ERROR:gitosis.serve.main:Need SSH_ORIGINAL_COMMAND in environment.
 	  Connection to gitserver closed.
 
 说明 Gitosis 认出了该用户的身份，但由于没有运行任何 Git 命令，所以它切断了连接。那么，现在运行一个实际的 Git 命令 — 克隆 Gitosis 的控制仓库：
@@ -420,32 +429,32 @@ Gitosis 将会帮我们管理用户公钥，所以先把当前控制文件改名
 
 看一下 `gitosis.conf` 文件的内容，它应该只包含与刚刚克隆的 `gitosis-admin` 相关的信息：
 
-	$ cat gitosis.conf 
+	$ cat gitosis.conf
 	[gitosis]
 
 	[group gitosis-admin]
-	writable = gitosis-admin
 	members = scott
+	writable = gitosis-admin
 
 它显示用户 `scott` — 初始化 Gitosis 公钥的拥有者 — 是唯一能管理 `gitosis-admin` 项目的人。
 
 现在我们来添加一个新项目。为此我们要建立一个名为 `mobile` 的新段落，在其中罗列手机开发团队的开发者，以及他们拥有写权限的项目。由于 'scott' 是系统中的唯一用户，我们把他设为唯一用户，并允许他读写名为 `iphone_project` 的新项目：
 
 	[group mobile]
-	writable = iphone_project
 	members = scott
+	writable = iphone_project
 
 修改完之后，提交 `gitosis-admin` 里的改动，并推送到服务器使其生效：
 
 	$ git commit -am 'add iphone_project and mobile group'
-	[master]: created 8962da8: "changed name"
-	 1 files changed, 4 insertions(+), 0 deletions(-)
-	$ git push
+	[master 8962da8] add iphone_project and mobile group
+	 1 file changed, 4 insertions(+)
+	$ git push origin master
 	Counting objects: 5, done.
-	Compressing objects: 100% (2/2), done.
-	Writing objects: 100% (3/3), 272 bytes, done.
-	Total 3 (delta 1), reused 0 (delta 0)
-	To git@gitserver:/opt/git/gitosis-admin.git
+	Compressing objects: 100% (3/3), done.
+	Writing objects: 100% (3/3), 272 bytes | 0 bytes/s, done.
+	Total 3 (delta 0), reused 0 (delta 0)
+	To git@gitserver:gitosis-admin.git
 	   fb27aec..8962da8  master -> master
 
 在新工程 `iphone_project` 里首次推送数据到服务器前，得先设定该服务器地址为远程仓库。但你不用事先到服务器上手工创建该项目的裸仓库— Gitosis 会在第一次遇到推送时自动创建：
@@ -454,7 +463,7 @@ Gitosis 将会帮我们管理用户公钥，所以先把当前控制文件改名
 	$ git push origin master
 	Initialized empty Git repository in /opt/git/iphone_project.git/
 	Counting objects: 3, done.
-	Writing objects: 100% (3/3), 230 bytes, done.
+	Writing objects: 100% (3/3), 230 bytes | 0 bytes/s, done.
 	Total 3 (delta 0), reused 0 (delta 0)
 	To git@gitserver:iphone_project.git
 	 * [new branch]      master -> master
@@ -470,20 +479,20 @@ Gitosis 将会帮我们管理用户公钥，所以先把当前控制文件改名
 然后把他们都加进 'mobile' 团队，让他们对 `iphone_project` 具有读写权限：
 
 	[group mobile]
-	writable = iphone_project
 	members = scott john josie jessica
+	writable = iphone_project
 
 如果你提交并推送这个修改，四个用户将同时具有该项目的读写权限。
 
 Gitosis 也具有简单的访问控制功能。如果想让 John 只有读权限，可以这样做：
 
 	[group mobile]
-	writable = iphone_project
 	members = scott josie jessica
+	writable = iphone_project
 
 	[group mobile_ro]
-	readonly = iphone_project
 	members = john
+	readonly = iphone_project
 
 现在 John 可以克隆和获取更新，但 Gitosis 不会允许他向项目推送任何内容。像这样的组可以随意创建，多少不限，每个都可以包含若干不同的用户和项目。甚至还可以指定某个组为成员之一（在组名前加上 `@` 前缀），自动继承该组的成员：
 
@@ -491,70 +500,46 @@ Gitosis 也具有简单的访问控制功能。如果想让 John 只有读权限
 	members = scott josie jessica
 
 	[group mobile]
-	writable  = iphone_project
 	members   = @mobile_committers
+	writable  = iphone_project
 
 	[group mobile_2]
-	writable  = another_iphone_project
 	members   = @mobile_committers john
+	writable  = another_iphone_project
 
 如果遇到意外问题，试试看把 `loglevel=DEBUG` 加到 `[gitosis]` 的段落（译注：把日志设置为调试级别，记录更详细的运行信息。）。如果一不小心搞错了配置，失去了推送权限，也可以手工修改服务器上的 `/home/git/.gitosis.conf` 文件 — Gitosis 实际是从该文件读取信息的。它在得到推送数据时，会把新的 `gitosis.conf` 存到该路径上。所以如果你手工编辑该文件的话，它会一直保持到下次向 `gitosis-admin` 推送新版本的配置内容为止。
 
 ## Gitolite ##
 
-注：本书此段落的最新拷贝始终存在于[gitolite documentation][gldpg].  作者谦虚地表示，尽管这个段落是精确的，可以（已经）用于安装gitolite而不用阅读其他的文档，但仍有必要不完整，并且不能完全替代随gitolite自带的大量文档。
+This section serves as a quick introduction to Gitolite, and provides basic installation and setup instructions.  不能完全替代随 gitolite 自带的大量文档。 There may also be occasional changes to this section itself, so you may also want to look at the latest version [here][gldpg].
 
 [gldpg]: http://sitaramc.github.com/gitolite/progit.html
+[gltoc]: http://sitaramc.github.com/gitolite/master-toc.html
 
-Git已经变成了非常流行的写作环境，并倾向于为了访问控制而增加额外的需求。Gitolite用于帮助这些需求而创建，但它变成了对开源世界同样有用的东西：Fedora项目使用gitolite控制访问他们的包管理仓库 (超过 10,000个包！) , 而且这也可能是最大的gitolite装置。
+Gitolite is an authorization layer on top of Git, relying on `sshd` or `httpd` for authentication.  (Recap: authentication is identifying who the user is, authorization is deciding if he is allowed to do what he is attempting to).
 
 Gitolite 允许你定义访问许可而不只作用于仓库，而同样于仓库中的每个branch和tag name。你可以定义确切的人 (或一组人) 只能push特定的 "refs" (或者branches或者tags)而不是其他人。
 
 ### 安装 ###
 
-安装 Gitolite非常简单, 你甚至不用读自带的那一大堆文档。你需要一个unix服务器上的账户；许多linux变种和solaris 10都已经试过了。你不需要root访问，假设git，perl，和一个openssh兼容的ssh服务器已经装好了。在下面的例子里，我们会用 `gitolite` 账户在 `gitserver`上.
-
-Gitolite 是不同于 "server" 的软件 -- 通过ssh访问, 而且每个在服务器上的userid都是一个潜在的 "gitolite host". 因此,  "安装" 这个软件的概念意味着安装它自身, 然后"设置" 一个用户作为 "gitolite host".
-
-Gitolite 有4种安装方法。用 Fedora 或 Debian 的人可以获取一个 RPM或者 DEB安装。有root权限的人可以手动安装。在这两种方法中，任意系统上的用户变成一个 "gitolite host"。
-
-没有 root访问权限的人可以安装在他们自己的 userid 下面。最后，gitolite可以用一个“工作站上”的脚本在bash shell安装。(如果你想的话甚至msysgit带的bash就可以。)
-
-我们要描述这个最后一个方法；其他方法请看文档。
-
-首先你要获取一个访问服务器的公钥，你可以从你自己的工作站部属密码访问服务器。下面的方法在linux上管用；其他的工作站系统你可以手动做这些事。我们假设你已经用'ssh-keygen'生成了一对密钥。
-
-	$ ssh-copy-id -i ~/.ssh/id_rsa gitolite@gitserver
-
-这会要你 gitolite账户的密码，然后设置公钥访问。这个对安装脚本非常 **重要**，所以试一下保证你可以不输密码：
+安装 Gitolite非常简单, 你甚至不用读自带的那一大堆文档。你需要一个unix服务器上的账户；许多linux变种和solaris 10都已经试过了。你不需要root访问，假设git，perl，和一个openssh兼容的ssh服务器已经装好了。在下面的例子里，我们会用 `git` 账户在 `gitserver`上.
 
-	$ ssh gitolite@gitserver pwd
-	/home/gitolite
+Gitolite 是不同于 "server" 的软件 -- 通过ssh访问, 而且每个在服务器上的userid都是一个潜在的 "gitolite host". We will describe the simplest install method in this article; for the other methods please see the documentation.
 
-接下俩，你 clone Gitolite从项目的主目录运行 "easy install" 脚本 (第三个参数是你的作为 gitolite-admin仓库用户的名字):
+To begin, create a user called `git` on your server and login to this user.  Copy your SSH public key (a file called `~/.ssh/id_rsa.pub` if you did a plain `ssh-keygen` with all the defaults) from your workstation, renaming it to `<yourname>.pub` (we'll use `scott.pub` in our examples).  Then run these commands:
 
 	$ git clone git://github.com/sitaramc/gitolite
-	$ cd gitolite/src
-	$ ./gl-easy-install -q gitolite gitserver sitaram
+	$ gitolite/install -ln
+	    # assumes $HOME/bin exists and is in your $PATH
+	$ gitolite setup -pk $HOME/scott.pub
 
-然后就完成了！Gitolite已经在服务器上装好了，现在你有一个全新的仓库叫做 `gitolite-admin` 在你工作站的 home目录。你管理你的 gitolite 安装通过改变这个项目和push。
-
-最后的命令产生大量的输出，你可能想读一下。而且你第一次运行的时候会产生一对新密钥；你会选择密码或者什么都不输。为什么需要第二个密钥对以及怎么用在Gitolite带的 "ssh troubleshooting" 文件里解释了。 (文档肯定有点什么用！)
-
-叫做 `gitolite-admin` 和 `testing` 的仓库默认创建在服务器上。如果你想在本地 clone这些 (从一个有ssh控制台 gitolite通过 *authorized_keys*访问的用户)，输入：
-
-	$ git clone gitolite:gitolite-admin
-	$ git clone gitolite:testing
-	
-clone 这些同样的仓库从任意其他账户：
-
-	$ git clone gitolite@servername:gitolite-admin
-	$ git clone gitolite@servername:testing
+That last command creates new Git repository called `gitolite-admin` on the server.
 
+Finally, back on your workstation, run `git clone git@gitserver:gitolite-admin`. And you’re done!  Gitolite has now been installed on the server, and you now have a brand new repository called `gitolite-admin` in your workstation.  You administer your Gitolite setup by making changes to this repository and pushing.
 
 ### 定制安装 ###
 
-默认快速安装对大多数人都管用，还有一些定制安装方法如果你用的上的话。如果你不用 `-q` 参数，则用 "罗嗦" 模式安装 -- 详细信息关于安装的每一步都在做什么。 罗嗦模式也允许你改变服务器端参数，诸如实际仓库的位置，通过编辑服务器使用的 "rc" 文件。这个 "rc" 有好多注释让你编辑的时候变得非常简单，保存退出。这个文件也包括了许多设置你能改变来启用或者禁用一些gitolite的高级功能。
+默认快速安装对大多数人都管用，还有一些定制安装方法如果你用的上的话。Some changes can be made simply by editing the rc file, but if that is not sufficient, there’s documentation on customising Gitolite.
 
 ### 配置文件和访问规则 ###
 
@@ -565,18 +550,18 @@ clone 这些同样的仓库从任意其他账户：
 	conf/  keydir/
 	$ find conf keydir -type f
 	conf/gitolite.conf
-	keydir/sitaram.pub
+	keydir/scott.pub
 	$ cat conf/gitolite.conf
-	#gitolite conf
-	# please see conf/example.conf for details on syntax and features
 
 	repo gitolite-admin
-	    RW+                 = sitaram
+	    RW+                 = scott
 
 	repo testing
 	    RW+                 = @all
 
-注意 "sitaram" ( 之前用`gl-easy-install` 命令时候的最后一个参数) 有读写权限而且在 `gitolite-admin` 仓库里有一个同名的公钥文件。
+注意 "scott" ( 之前用`gl-setup` 命令时候的 pubkey 名稱) 有读写权限而且在 `gitolite-admin` 仓库里有一个同名的公钥文件。
+
+Adding users is easy.  To add a user called "alice", obtain her public key, name it `alice.pub`, and put it in the `keydir` directory of the clone of the `gitolite-admin` repo you just made on your workstation.  Add, commit, and push the change, and the user has been added.
 
 gitolite配置文件的语法在 `conf/example.conf`里，我们只会提到一些主要的。
 
@@ -585,8 +570,8 @@ gitolite配置文件的语法在 `conf/example.conf`里，我们只会提到一
 	@oss_repos      = linux perl rakudo git gitolite
 	@secret_repos   = fenestra pear
 
-	@admins         = scott     # Adams, not Chacon, sorry :)
-	@interns        = ashok     # get the spelling right, Scott!
+	@admins         = scott
+	@interns        = ashok
 	@engineers      = sitaram dilbert wally alice
 	@staff          = @admins @engineers @interns
 
@@ -632,11 +617,9 @@ gitolite配置文件的语法在 `conf/example.conf`里，我们只会提到一
 此外限制用户 push改变到哪条branch的，你也可以限制哪个文件他们可以碰的到。比如, 可能 Makefile (或者其他哪些程序) 真的不能被任何人做任何改动，因为好多东西都靠着它呢，或者如果某些改变刚好不对就会崩溃。你可以告诉 gitolite:
 
     repo foo
-        RW                  =   @junior_devs @senior_devs
+        RW                      =   @junior_devs @senior_devs
 
-        RW  NAME/           =   @senior_devs
-        -   NAME/Makefile   =   @junior_devs
-        RW  NAME/           =   @junior_devs
+        -   VREF/NAME/Makefile  =   @junior_devs
 
 这是一个强力的公能写在 `conf/example.conf`里。
 
@@ -660,12 +643,10 @@ Gitolite 允许你定义带通配符的仓库 (其实还是 perl正则式), 比
 
 **记录**: Gitolite 记录所有成功的访问。如果你太放松给了别人 rewind许可 (`RW+`) 和其他孩子弄没了 "master"， 记录文件会救你的命，如果其他简单快速的找到SHA都不管用。
 
-**Git在通常路径外**: 一个在gitolite里的超级有用的简单功能是支持git安装在通常的 `$PATH`之外 (这个比你想象的还要寻常；一些合作环境或者甚至一些主机提供商拒绝安装系统范围外的东西你只能放在自己的目录里)。通常，你被强迫用 *客户端* 用某种方法找到git 为这个非标准的位置。使用 gitolite，只要选择絮叨安装设置 `$GIT_PATH`在 "rc" 文件里。不用改变客户端然后 :-)。
-
 **访问权报告**: 另一个方便的功能是你尝试用ssh连接到服务器的时候发生了什么。Gitolite告诉你哪个 repos你访问过，那个访问可能是什么。这里是例子：
 
-        hello sitaram, the gitolite version here is v1.5.4-19-ga3397d4
-        the gitolite config gives you the following access:
+        hello scott, this is git@git running gitolite3 v3.01-18-g9609868 on git 1.7.4.4
+
              R     anu-wsd
              R     entrans
              R  W  git-notes
@@ -676,8 +657,6 @@ Gitolite 允许你定义带通配符的仓库 (其实还是 perl正则式), 比
 
 **委托**：真正的大安装，你可以把责任委托给一组仓库给不同的人然后让他们独立管理那些部分。这个减少了主管理者的负担，让他瓶颈更小。这个功能在他自己的文档目录里的 `doc/`下面。
 
-**Gitweb 支持**： Gitolite支持 gitweb以几种方式。你可以定义哪个仓库在gitweb可见。你能设置 "拥有者" 和 "描述" gitweb 从 gitolite配置文件里。Gitweb 有一个机制给你来实现基于http认证的访问控制，你能让它用 gitolite产生的 "编译过" 的配置文件，意思是同样的访问规则 (为读访问) 用于 gitweb和 gitolite.
-
 **镜像**: Gitolite可以帮助你维护多个镜像，如果主服务器挂掉的话在他们之间很容易切换。
 
 ## Git 守护进程 ##
@@ -771,12 +750,13 @@ Insert 18333fig0402.png
 
 选择一个系统中尚未使用的用户名，提供一个与之相关联的电邮地址，并输入密码（见图 4-3）：
 
-Insert 18333fig0403.png 
+Insert 18333fig0403.png
 图 4-3. GitHub 用户注册表单
 
-如果方便，现在就可以提供你的 SSH 公钥。我们在前文的"小型安装" 一节介绍过生成新公钥的方法。把新生成的公钥复制粘贴到 SSH Public Key 文本框中即可。要是对生成公钥的步骤不太清楚，也可以点击 "explain ssh keys" 链接，会显示各个主流操作系统上完成该步骤的介绍。点击 "I agree，sign me up" 按钮完成用户注册，并转到该用户的 dashboard 页面（见图 4-4）:
+如果方便，现在就可以提供你的 SSH 公钥。我们在前文的"小型安装" 一节介绍过生成新公钥的方法。把新生成的公钥复制粘贴到 SSH Public Key 文本框中即可。要是对生成公钥的步骤不太清楚，也可以点击 "explain ssh keys" 链接，会显示各个主流操作系统上完成该步骤的介绍。
+点击 "I agree，sign me up" 按钮完成用户注册，并转到该用户的 dashboard 页面（见图 4-4）:
 
-Insert 18333fig0404.png 
+Insert 18333fig0404.png
 图 4-4. GitHub 的用户面板
 
 接下来就可以建立新仓库了。
@@ -785,17 +765,17 @@ Insert 18333fig0404.png
 
 点击用户面板上仓库旁边的 "create a new one" 链接，显示 Create a New Repository 的表单（见图 4-5）：
 
-Insert 18333fig0405.png 
+Insert 18333fig0405.png
 图 4-5. 在 GitHub 上建立新仓库
 
 当然，项目名称是必不可少的，此外也可以适当描述一下项目的情况或者给出官方站点的地址。然后点击 "Create Repository" 按钮，新仓库就建立起来了（见图 4-6）：
 
-Insert 18333fig0406.png 
+Insert 18333fig0406.png
 图 4-6. GitHub 上各个项目的概要信息
 
 由于尚未提交代码，点击项目地址后 GitHub 会显示一个简要的指南，告诉你如何新建一个项目并推送上来，如何从现有项目推送，以及如何从一个公共的 Subversion 仓库导入项目（见图 4-7）：
 
-Insert 18333fig0407.png 
+Insert 18333fig0407.png
 图 4-7. 新仓库指南
 
 该指南和本书前文介绍的类似，对于新的项目，需要先在本地初始化为 Git 项目，添加要管理的文件并作首次提交：
@@ -811,7 +791,7 @@ Insert 18333fig0407.png
 
 现在该项目就托管在 GitHub 上了。你可以把它的 URL 分享给每位对此项目感兴趣的人。本例的 URL 是 `http://github.com/testinguser/iphone_project`。而在项目页面的摘要部分，你会发现有两个 Git URL 地址（见图 4-8）：
 
-Insert 18333fig0408.png 
+Insert 18333fig0408.png
 图 4-8. 项目摘要中的公共 URL 和私有 URL
 
 Public Clone URL 是一个公开的，只读的 Git URL，任何人都可以通过它克隆该项目。可以随意散播这个 URL，比如发布到个人网站之类的地方等等。
@@ -822,7 +802,7 @@ Your Clone URL 是一个基于 SSH 协议的可读可写 URL，只有使用与
 
 如果想把某个公共 Subversion 项目导入 Git，GitHub 可以帮忙。在指南的最后有一个指向导入 Subversion 页面的链接。点击它会看到一个表单，包含有关导入流程的信息以及一个用来粘贴公共 Subversion 项目连接的文本框（见图 4-9）：
 
-Insert 18333fig0409.png 
+Insert 18333fig0409.png
 图 4-9. Subversion 导入界面
 
 如果项目很大，采用非标准结构，或者是私有的，那就无法借助该工具实现导入。到第 7 章，我们会介绍如何手工导入复杂工程的具体方法。
@@ -833,7 +813,7 @@ Insert 18333fig0409.png
 
 点击项目页面上方的 "edit" 按钮或者顶部的 Admin 标签，进入该项目的管理页面（见图 4-10）：
 
-Insert 18333fig0410.png 
+Insert 18333fig0410.png
 图 4-10. GitHub 的项目管理页面
 
 为了给另一个用户添加项目的写权限，点击 "Add another collaborator" 链接，出现一个用于输入用户名的表单。在输入的同时，它会自动跳出一个符合条件的候选名单。找到正确用户名之后，点 Add 按钮，把该用户设为项目协作者（见图 4-11）：
@@ -843,7 +823,7 @@ Insert 18333fig0411.png
 
 添加完协作者之后，就可以在 Repository Collaborators 区域看到他们的名单（见图 4-12）：
 
-Insert 18333fig0412.png 
+Insert 18333fig0412.png
 图 4-12. 项目协作者名单
 
 如果要取消某人的访问权，点击 "revoke" 即可取消他的推送权限。对于将来的项目，你可以从现有项目复制协作者名单，或者直接借用协作者群组。
@@ -852,7 +832,7 @@ Insert 18333fig0412.png
 
 在推送或从 Subversion 导入项目之后，你会看到一个类似图 4-13 的项目主页：
 
-Insert 18333fig0413.png 
+Insert 18333fig0413.png
 图 4-13. GitHub 上的项目主页
 
 别人访问你的项目时看到的就是这个页面。它有若干导航标签，Commits 标签用于显示提交历史，最新的提交位于最上方，这和 `git log` 命令的输出类似。Network 标签展示所有派生了该项目并做出贡献的用户的关系图谱。Downloads 标签允许你上传项目的二进制文件，提供下载该项目各个版本的 tar/zip 包。Wiki 标签提供了一个用于撰写文档或其他项目相关信息的 wiki 站点。Graphs 标签包含了一些可视化的项目信息与数据。默认打开的 Source 标签页面，则列出了该项目的目录结构和概要信息，并在下方自动展示 README 文件的内容（如果该文件存在的话），此外还会显示最近一次提交的相关信息。
@@ -865,12 +845,12 @@ Insert 18333fig0413.png
 
 要派生一个项目，到原始项目的页面（本例中是 mojombo/chronic）点击 "fork" 按钮（见图 4-14）：
 
-Insert 18333fig0414.png 
+Insert 18333fig0414.png
 图 4-14. 点击 "fork" 按钮获得任意项目的可写副本
 
 几秒钟之后，你将进入新建的项目页面，会显示该项目派生自哪一个项目（见图 4-15）：
 
-Insert 18333fig0415.png 
+Insert 18333fig0415.png
 图 4-15. 派生后得到的项目副本
 
 ### GitHub 小结 ###
diff --git a/zh/05-distributed-git/01-chapter5.markdown b/zh/05-distributed-git/01-chapter5.markdown
index 2f022503e..772774948 100644
--- a/zh/05-distributed-git/01-chapter5.markdown
+++ b/zh/05-distributed-git/01-chapter5.markdown
@@ -12,12 +12,13 @@
 
 通常，集中式工作流程使用的都是单点协作模型。一个存放代码仓库的中心服务器，可以接受所有开发者提交的代码。所有的开发者都是普通的节点，作为中心集线器的消费者，平时的工作就是和中心仓库同步数据（见图 5-1）。
 
-Insert 18333fig0501.png 
+Insert 18333fig0501.png
 图 5-1. 集中式工作流
 
 如果两个开发者从中心仓库克隆代码下来，同时作了一些修订，那么只有第一个开发者可以顺利地把数据推送到共享服务器。第二个开发者在提交他的修订之前，必须先下载合并服务器上的数据，解决冲突之后才能推送数据到共享服务器上。在 Git 中这么用也决无问题，这就好比是在用 Subversion（或其他 CVCS）一样，可以很好地工作。
 
-如果你的团队不是很大，或者大家都已经习惯了使用集中式工作流程，完全可以采用这种简单的模式。只需要配置好一台中心服务器，并给每个人推送数据的权限，就可以开展工作了。但如果提交代码时有冲突， Git 根本就不会让用户覆盖他人代码，它直接驳回第二个人的提交操作。这就等于告诉提交者，你所作的修订无法通过快近（fast-forward）来合并，你必须先拉取最新数据下来，手工解决冲突合并后，才能继续推送新的提交。绝大多数人都熟悉和了解这种模式的工作方式，所以使用也非常广泛。
+如果你的团队不是很大，或者大家都已经习惯了使用集中式工作流程，完全可以采用这种简单的模式。只需要配置好一台中心服务器，并给每个人推送数据的权限，就可以开展工作了。但如果提交代码时有冲突， Git 根本就不会让用户覆盖他人代码，它直接驳回第二个人的提交操作。这就等于告诉提交者，你所作的修订无法通过快近（fast-forward）来合并，你必须先拉取最新数据下来，手工解决冲突合并后，才能继续推送新的提交。
+绝大多数人都熟悉和了解这种模式的工作方式，所以使用也非常广泛。
 
 ### 集成管理员工作流 ###
 
@@ -30,7 +31,7 @@ Insert 18333fig0501.png
 5. 维护者在自己本地的 integration manger 仓库中，将贡献者的仓库加为远程仓库，合并更新并做测试。
 6. 维护者将合并后的更新推送到主仓库 blessed repository。
 
-Insert 18333fig0502.png 
+Insert 18333fig0502.png
 图 5-2. 集成管理员工作流
 
 在 GitHub 网站上使用得最多的就是这种工作流。人们可以复制（fork 亦即克隆）某个项目到自己的列表中，成为自己的公共仓库。随后将自己的更新提交到这个仓库，所有人都可以看到你的每次更新。这么做最主要的优点在于，你可以按照自己的节奏继续工作，而不必等待维护者处理你提交的更新；而维护者也可以按照自己的节奏，任何时候都可以过来处理接纳你的贡献。
@@ -44,7 +45,7 @@ Insert 18333fig0502.png
 3. 司令官（dictator）将所有副官的 master 分支并入自己的 master 分支。
 4. 司令官（dictator）将集成后的 master 分支推送到共享仓库 blessed repository 中，以便所有其他开发者以此为基础进行衍合。
 
-Insert 18333fig0503.png  
+Insert 18333fig0503.png
 图 5-3. 司令官与副官工作流
 
 这种工作流程并不常用，只有当项目极为庞杂，或者需要多级别管理时，才会体现出优势。利用这种方式，项目总负责人（即司令官）可以把大量分散的集成工作委托给不同的小组负责人分别处理，最后再统筹起来，如此各人的职责清晰明确，也不易出错（译注：此乃分而治之）。
@@ -83,7 +84,8 @@ Insert 18333fig0503.png
 
 接下来，请将每次提交限定于完成一次逻辑功能。并且可能的话，适当地分解为多次小更新，以便每次小型提交都更易于理解。请不要在周末穷追猛打一次性解决五个问题，而最后拖到周一再提交。就算是这样也请尽可能利用暂存区域，将之前的改动分解为每次修复一个问题，再分别提交和加注说明。如果针对两个问题改动的是同一个文件，可以试试看 `git add --patch` 的方式将部分内容置入暂存区域（我们会在第六章再详细介绍）。无论是五次小提交还是混杂在一起的大提交，最终分支末端的项目快照应该还是一样的，但分解开来之后，更便于其他开发者复阅。这么做也方便自己将来取消某个特定问题的修复。我们将在第六章介绍一些重写提交历史，同暂存区域交互的技巧和工具，以便最终得到一个干净有意义，且易于理解的提交历史。
 
-最后需要谨记的是提交说明的撰写。写得好可以让大家协作起来更轻松。一般来说，提交说明最好限制在一行以内，50 个字符以下，简明扼要地描述更新内容，空开一行后，再展开详细注解。Git 项目本身需要开发者撰写详尽注解，包括本次修订的因由，以及前后不同实现之间的比较，我们也该借鉴这种做法。另外，提交说明应该用祈使现在式语态，比如，不要说成 “I added tests for” 或 “Adding tests for” 而应该用 “Add tests for”。下面是来自 tpope.net 的 Tim Pope 原创的提交说明格式模版，供参考：
+最后需要谨记的是提交说明的撰写。写得好可以让大家协作起来更轻松。一般来说，提交说明最好限制在一行以内，50 个字符以下，简明扼要地描述更新内容，空开一行后，再展开详细注解。Git 项目本身需要开发者撰写详尽注解，包括本次修订的因由，以及前后不同实现之间的比较，我们也该借鉴这种做法。另外，提交说明应该用祈使现在式语态，比如，不要说成 “I added tests for” 或 “Adding tests for” 而应该用 “Add tests for”。
+下面是来自 tpope.net 的 Tim Pope 原创的提交说明格式模版，供参考：
 
 	本次更新的简要描述（50 个字符以内）
 
@@ -91,7 +93,7 @@ Insert 18333fig0503.png
 	某些情况下，第一行的简要描述将用作邮件标题，其余部分作为邮件正文。
 	其间的空行是必要的，以区分两者（当然没有正文另当别论）。
 	如果并在一起，rebase 这样的工具就可能会迷惑。
-	
+
 	另起空行后，再进一步补充其他说明。
 
 	 - 可以使用这样的条目列举式。
@@ -107,14 +109,15 @@ Insert 18333fig0503.png
 
 我们从最简单的情况开始，一个私有项目，与你一起协作的还有另外一到两位开发者。这里说私有，是指源代码不公开，其他人无法访问项目仓库。而你和其他开发者则都具有推送数据到仓库的权限。
 
-这种情况下，你们可以用 Subversion 或其他集中式版本控制系统类似的工作流来协作。你仍然可以得到 Git 带来的其他好处：离线提交，快速分支与合并等等，但工作流程还是差不多的。主要区别在于，合并操作发生在客户端而非服务器上。让我们来看看，两个开发者一起使用同一个共享仓库，会发生些什么。第一个人，John，克隆了仓库，作了些更新，在本地提交。（下面的例子中省略了常规提示，用 `...` 代替以节约版面。）
+这种情况下，你们可以用 Subversion 或其他集中式版本控制系统类似的工作流来协作。你仍然可以得到 Git 带来的其他好处：离线提交，快速分支与合并等等，但工作流程还是差不多的。主要区别在于，合并操作发生在客户端而非服务器上。
+让我们来看看，两个开发者一起使用同一个共享仓库，会发生些什么。第一个人，John，克隆了仓库，作了些更新，在本地提交。（下面的例子中省略了常规提示，用 `...` 代替以节约版面。）
 
 	# John's Machine
 	$ git clone john@githost:simplegit.git
 	Initialized empty Git repository in /home/john/simplegit/.git/
 	...
 	$ cd simplegit/
-	$ vim lib/simplegit.rb 
+	$ vim lib/simplegit.rb
 	$ git commit -am 'removed invalid default value'
 	[master 738ee87] removed invalid default value
 	 1 files changed, 1 insertions(+), 1 deletions(-)
@@ -126,7 +129,7 @@ Insert 18333fig0503.png
 	Initialized empty Git repository in /home/jessica/simplegit/.git/
 	...
 	$ cd simplegit/
-	$ vim TODO 
+	$ vim TODO
 	$ git commit -am 'add reset task'
 	[master fbff5bc] add reset task
 	 1 files changed, 1 insertions(+), 0 deletions(-)
@@ -156,7 +159,7 @@ John 的推送操作被驳回，因为 Jessica 已经推送了新的数据上去
 
 此刻，John 的本地仓库如图 5-4 所示：
 
-Insert 18333fig0504.png 
+Insert 18333fig0504.png
 图 5-4. John 的仓库历史
 
 虽然 John 下载了 Jessica 推送到服务器的最近更新（fbff5），但目前只是 `origin/master` 指针指向它，而当前的本地分支 `master` 仍然指向自己的更新（738ee），所以需要先把她的提交合并过来，才能继续推送数据：
@@ -168,7 +171,7 @@ Insert 18333fig0504.png
 
 还好，合并过程非常顺利，没有冲突，现在 John 的提交历史如图 5-5 所示：
 
-Insert 18333fig0505.png 
+Insert 18333fig0505.png
 图 5-5. 合并 origin/master 后 John 的仓库历史
 
 现在，John 应该再测试一下代码是否仍然正常工作，然后将合并结果（72bbc）推送到服务器上：
@@ -180,12 +183,12 @@ Insert 18333fig0505.png
 
 最终，John 的提交历史变为图 5-6 所示：
 
-Insert 18333fig0506.png 
+Insert 18333fig0506.png
 图 5-6. 推送后 John 的仓库历史
 
 而在这段时间，Jessica 已经开始在另一个特性分支工作了。她创建了 `issue54` 并提交了三次更新。她还没有下载 John 提交的合并结果，所以提交历史如图 5-7 所示：
 
-Insert 18333fig0507.png 
+Insert 18333fig0507.png
 图 5-7. Jessica 的提交历史
 
 Jessica 想要先和服务器上的数据同步，所以先下载数据：
@@ -198,7 +201,7 @@ Jessica 想要先和服务器上的数据同步，所以先下载数据：
 
 于是 Jessica 的本地仓库历史多出了 John 的两次提交（738ee 和 72bbc），如图 5-8 所示：
 
-Insert 18333fig0508.png 
+Insert 18333fig0508.png
 图 5-8. 获取 John 的更新之后 Jessica 的提交历史
 
 此时，Jessica 在特性分支上的工作已经完成，但她想在推送数据之前，先确认下要并进来的数据究竟是什么，于是运行 `git log` 查看：
@@ -235,7 +238,7 @@ Insert 18333fig0508.png
 
 所有的合并都非常干净。现在 Jessica 的提交历史如图 5-9 所示：
 
-Insert 18333fig0509.png 
+Insert 18333fig0509.png
 图 5-9. 合并 John 的更新后 Jessica 的提交历史
 
 现在 Jessica 已经可以在自己的 `master` 分支中访问 `origin/master` 的最新改动了，所以她应该可以成功推送最后的合并结果到服务器上（假设 John 此时没再推送新数据上来）：
@@ -247,12 +250,12 @@ Insert 18333fig0509.png
 
 至此，每个开发者都提交了若干次，且成功合并了对方的工作成果，最新的提交历史如图 5-10 所示：
 
-Insert 18333fig0510.png 
+Insert 18333fig0510.png
 图 5-10. Jessica 推送数据后的提交历史
 
 以上就是最简单的协作方式之一：先在自己的特性分支中工作一段时间，完成后合并到自己的 `master` 分支；然后下载合并 `origin/master` 上的更新（如果有的话），再推回远程服务器。一般的协作流程如图 5-11 所示：
 
-Insert 18333fig0511.png 
+Insert 18333fig0511.png
 图 5-11. 多用户共享仓库协作方式的一般工作流程时序
 
 ### 私有团队间协作 ###
@@ -298,7 +301,7 @@ Jessica 发邮件给 John 让他上来看看 `featureA` 分支上的进展。在
 
 现在 Jessica 的更新历史如图 5-12 所示：
 
-Insert 18333fig0512.png 
+Insert 18333fig0512.png
 图 5-12. Jessica 的更新历史
 
 Jessica 正准备推送自己的进展上去，却收到 Josie 的来信，说是她已经将自己的工作推到服务器上的 `featureBee` 分支了。这样，Jessica 就必须先将 Josie 的代码合并到自己本地分支中，才能再一起推送回服务器。她用 `git fetch` 下载 Josie 的最新代码：
@@ -354,26 +357,26 @@ Jessica 正准备推送自己的进展上去，却收到 Josie 的来信，说
 Jessica 稍做一番修整后同步到服务器：
 
 	$ git commit -am 'small tweak'
-	[featureA ed774b3] small tweak
+	[featureA 774b3ed] small tweak
 	 1 files changed, 1 insertions(+), 1 deletions(-)
 	$ git push origin featureA
 	...
 	To jessica@githost:simplegit.git
-	   3300904..ed774b3  featureA -> featureA
+	   3300904..774b3ed  featureA -> featureA
 
 现在的 Jessica 提交历史如图 5-13 所示：
 
-Insert 18333fig0513.png 
+Insert 18333fig0513.png
 图 5-13. 在特性分支中提交更新后的提交历史
 
 现在，Jessica，Josie 和 John 通知集成管理员服务器上的 `featureA` 及 `featureBee` 分支已经准备好，可以并入主线了。在管理员完成集成工作后，主分支上便多出一个新的合并提交（5399e），用 fetch 命令更新到本地后，提交历史如图 5-14 所示：
 
-Insert 18333fig0514.png 
+Insert 18333fig0514.png
 图 5-14. 合并特性分支后的 Jessica 提交历史
 
 许多开发小组改用 Git 就是因为它允许多个小组间并行工作，而在稍后恰当时机再行合并。通过共享远程分支的方式，无需干扰整体项目代码便可以开展工作，因此使用 Git 的小型团队间协作可以变得非常灵活自由。以上工作流程的时序如图 5-15 所示：
 
-Insert 18333fig0515.png 
+Insert 18333fig0515.png
 图 5-15. 团队间协作工作流程基本时序
 
 ### 公开的小型项目 ###
@@ -433,7 +436,7 @@ Insert 18333fig0515.png
 
 现在，A、B 两个特性分支各不相扰，如同竹筒里的两颗豆子，队列中的两个补丁，你随时都可以分别从头写过，或者衍合，或者修改，而不用担心特性代码的交叉混杂。如图 5-16 所示：
 
-Insert 18333fig0516.png 
+Insert 18333fig0516.png
 图 5-16. featureB 以后的提交历史
 
 假设项目管理员接纳了许多别人提交的补丁后，准备要采纳你提交的第一个分支，却发现因为代码基准不一致，合并工作无法正确干净地完成。这就需要你再次衍合到最新的 `origin/master`，解决相关冲突，然后重新提交你的修改：
@@ -444,7 +447,7 @@ Insert 18333fig0516.png
 
 自然，这会重写提交历史，如图 5-17 所示：
 
-Insert 18333fig0517.png 
+Insert 18333fig0517.png
 图 5-17. featureA 重新衍合后的提交历史
 
 注意，此时推送分支必须使用 `-f` 选项（译注：表示 force，不作检查强制重写）替换远程已有的 `featureA` 分支，因为新的 commit 并非原来的后续更新。当然你也可以直接推送到另一个新的分支上去，比如称作 `featureAv2`。
@@ -461,7 +464,7 @@ Insert 18333fig0517.png
 
 好了，现在可以请管理员抓取 `featureBv2` 上的最新代码了，如图 5-18 所示：
 
-Insert 18333fig0518.png 
+Insert 18333fig0518.png
 图 5-18. featureBv2 之后的提交历史
 
 ### 公开的大型项目 ###
@@ -484,7 +487,7 @@ Insert 18333fig0518.png
 
 `format-patch` 命令依次创建补丁文件，并输出文件名。上面的 `-M` 选项允许 Git 检查是否有对文件重命名的提交。我们来看看补丁文件的内容：
 
-	$ cat 0001-add-limit-to-log-function.patch 
+	$ cat 0001-add-limit-to-log-function.patch
 	From 330090432754092d704da8e76ca5c05c198e71a8 Mon Sep 17 00:00:00 2001
 	From: Jessica Smith <jessica@example.com>
 	Date: Sun, 6 Apr 2008 10:17:23 -0700
@@ -509,7 +512,7 @@ Insert 18333fig0518.png
 	   end
 
 	   def ls_tree(treeish = 'master')
-	-- 
+	--
 	1.6.2.rc1.20.g8c5b.dirty
 
 如果有额外信息需要补充，但又不想放在提交消息中说明，可以编辑这些补丁文件，在第一个 `---` 行之前添加说明，但不要修改下面的补丁正文，比如例子中的 `Limit log functionality to the first 20` 部分。这样，其它开发者能阅读，但在采纳补丁时不会将此合并进来。
@@ -526,19 +529,39 @@ Insert 18333fig0518.png
 	  port = 993
 	  sslverify = false
 
-如果你的 IMAP 服务器没有启用 SSL，就无需配置最后那两行，并且 host 应该以 `imap://` 开头而不再是有 `s` 的 `imaps://`。保存配置文件后，就能用 `git send-email` 命令把补丁作为邮件依次发送到指定的 IMAP 服务器上的文件夹中（译注：这里就是 Gmail 的 `[Gmail]/Drafts` 文件夹。但如果你的语言设置不是英文，此处的文件夹 Drafts 字样会变为对应的语言。）：
+如果你的 IMAP 服务器没有启用 SSL，就无需配置最后那两行，并且 host 应该以 `imap://` 开头而不再是有 `s` 的 `imaps://`。
+保存配置文件后，就能用 `git send-email` 命令把补丁作为邮件依次发送到指定的 IMAP 服务器上的文件夹中（译注：这里就是 Gmail 的 `[Gmail]/Drafts` 文件夹。但如果你的语言设置不是英文，此处的文件夹 Drafts 字样会变为对应的语言。）：
+
+	$ cat *.patch |git imap-send
+	Resolving imap.gmail.com... ok
+	Connecting to [74.125.142.109]:993... ok
+	Logging in...
+	sending 2 messages
+	100% (2/2) done
+
+At this point, you should be able to go to your Drafts folder, change the To field to the mailing list you’re sending the patch to, possibly CC the maintainer or person responsible for that section, and send it off.
+
+You can also send the patches through an SMTP server. As before, you can set each value separately with a series of `git config` commands, or you can add them manually in the sendemail section in your `~/.gitconfig` file:
+
+	[sendemail]
+	  smtpencryption = tls
+	  smtpserver = smtp.gmail.com
+	  smtpuser = user@gmail.com
+	  smtpserverport = 587
+
+After this is done, you can use `git send-email` to send your patches:
 
 	$ git send-email *.patch
 	0001-added-limit-to-log-function.patch
 	0002-changed-log-output-to-30-from-25.patch
-	Who should the emails appear to be from? [Jessica Smith <jessica@example.com>] 
+	Who should the emails appear to be from? [Jessica Smith <jessica@example.com>]
 	Emails will be sent from: Jessica Smith <jessica@example.com>
 	Who should the emails be sent to? jessica@example.com
 	Message-ID to be used as In-Reply-To for the first email? y
 
 接下来，Git 会根据每个补丁依次输出类似下面的日志：
 
-	(mbox) Adding cc: Jessica Smith <jessica@example.com> from 
+	(mbox) Adding cc: Jessica Smith <jessica@example.com> from
 	  \line 'From: Jessica Smith <jessica@example.com>'
 	OK. Log says:
 	Sendmail: /usr/sbin/sendmail -i jessica@example.com
@@ -553,8 +576,6 @@ Insert 18333fig0518.png
 
 	Result: OK
 
-最后，到 Gmail 上打开 Drafts 文件夹，编辑这些邮件，修改收件人地址为邮件列表地址，另外给要抄送的人也加到 Cc 列表中，最后发送。
-
 ### 小结 ###
 
 本节主要介绍了常见 Git 项目协作的工作流程，还有一些帮助处理这些工作的命令和工具。接下来我们要看看如何维护 Git 项目，并成为一个合格的项目管理员，或是集成经理。
@@ -565,13 +586,14 @@ Insert 18333fig0518.png
 
 ### 使用特性分支进行工作 ###
 
-如果想要集成新的代码进来，最好局限在特性分支上做。临时的特性分支可以让你随意尝试，进退自如。比如碰上无法正常工作的补丁，可以先搁在那边，直到有时间仔细核查修复为止。创建的分支可以用相关的主题关键字命名，比如 `ruby_client` 或者其它类似的描述性词语，以帮助将来回忆。Git 项目本身还时常把分支名称分置于不同命名空间下，比如 `sc/ruby_client` 就说明这是 `sc` 这个人贡献的。现在从当前主干分支为基础，新建临时分支：
+如果想要集成新的代码进来，最好局限在特性分支上做。临时的特性分支可以让你随意尝试，进退自如。比如碰上无法正常工作的补丁，可以先搁在那边，直到有时间仔细核查修复为止。创建的分支可以用相关的主题关键字命名，比如 `ruby_client` 或者其它类似的描述性词语，以帮助将来回忆。Git 项目本身还时常把分支名称分置于不同命名空间下，比如 `sc/ruby_client` 就说明这是 `sc` 这个人贡献的。
+现在从当前主干分支为基础，新建临时分支：
 
-    $ git branch sc/ruby_client master
+	$ git branch sc/ruby_client master
 
 另外，如果你希望立即转到分支上去工作，可以用 `checkout -b`：
 
-    $ git checkout -b sc/ruby_client master
+	$ git checkout -b sc/ruby_client master
 
 好了，现在已经准备妥当，可以试着将别人贡献的代码合并进来了。之后评估一下有没有问题，最后再决定是不是真的要并入主干。
 
@@ -589,7 +611,7 @@ Insert 18333fig0518.png
 
 在实际打补丁之前，可以先用 `git apply --check` 查看补丁是否能够干净顺利地应用到当前分支中：
 
-	$ git apply --check 0001-seeing-if-this-helps-the-gem.patch 
+	$ git apply --check 0001-seeing-if-this-helps-the-gem.patch
 	error: patch failed: ticgit.gemspec:1
 	error: ticgit.gemspec: patch does not apply
 
@@ -612,7 +634,7 @@ Insert 18333fig0518.png
 
 如果贡献者将 `format-patch` 生成的补丁文件上传到类似 Request Ticket 一样的任务处理系统，那么可以先下载到本地，继而使用 `git am` 应用该补丁：
 
-	$ git am 0001-limit-log-function.patch 
+	$ git am 0001-limit-log-function.patch
 	Applying: add limit to log function
 
 你会看到它被干净地应用到本地分支，并自动创建了新的提交对象。作者信息取自邮件头 `From` 和 `Date`，提交消息则取自 `Subject` 以及正文中补丁之前的内容。来看具体实例，采纳之前展示的那个 mbox 电邮补丁后，最新的提交对象为：
@@ -632,7 +654,7 @@ Insert 18333fig0518.png
 
 有时，我们也会遇到打不上补丁的情况。这多半是因为主干分支和补丁的基础分支相差太远，但也可能是因为某些依赖补丁还未应用。这种情况下，`git am` 会报错并询问该怎么做：
 
-	$ git am 0001-seeing-if-this-helps-the-gem.patch 
+	$ git am 0001-seeing-if-this-helps-the-gem.patch
 	Applying: seeing if this helps the gem
 	error: patch failed: ticgit.gemspec:1
 	error: ticgit.gemspec: patch does not apply
@@ -644,13 +666,13 @@ Insert 18333fig0518.png
 Git 会在有冲突的文件里加入冲突解决标记，这同合并或衍合操作一样。解决的办法也一样，先编辑文件消除冲突，然后暂存文件，最后运行 `git am --resolved` 提交修正结果：
 
 	$ (fix the file)
-	$ git add ticgit.gemspec 
+	$ git add ticgit.gemspec
 	$ git am --resolved
 	Applying: seeing if this helps the gem
 
 如果想让 Git 更智能地处理冲突，可以用 `-3` 选项进行三方合并。如果当前分支未包含该补丁的基础代码或其祖先，那么三方合并就会失败，所以该选项默认为关闭状态。一般来说，如果该补丁是基于某个公开的提交制作而成的话，你总是可以通过同步来获取这个共同祖先，所以用三方合并选项可以解决很多麻烦：
 
-	$ git am -3 0001-seeing-if-this-helps-the-gem.patch 
+	$ git am -3 0001-seeing-if-this-helps-the-gem.patch
 	Applying: seeing if this helps the gem
 	error: patch failed: ticgit.gemspec:1
 	error: ticgit.gemspec: patch does not apply
@@ -667,7 +689,7 @@ Git 会在有冲突的文件里加入冲突解决标记，这同合并或衍合
 	--------------------------
 	seeing if this helps the gem
 	--------------------------
-	Apply? [y]es/[n]o/[e]dit/[v]iew patch/[a]ccept all 
+	Apply? [y]es/[n]o/[e]dit/[v]iew patch/[a]ccept all
 
 在多个补丁要打的情况下，这是个非常好的办法，一方面可以预览下补丁内容，同时也可以有选择性的接纳或跳过某些补丁。
 
@@ -731,7 +753,7 @@ Git 会在有冲突的文件里加入冲突解决标记，这同合并或衍合
 
 	$ git merge-base contrib master
 	36c7dba2c95e6bbb78dfa822519ecfec6e1ca649
-	$ git diff 36c7db 
+	$ git diff 36c7db
 
 但这么做很麻烦，所以 Git 提供了便捷的 `...` 语法。对于 `diff` 命令，可以把 `...` 加在原始分支（拥有共同祖先）和当前分支之间：
 
@@ -747,7 +769,7 @@ Git 会在有冲突的文件里加入冲突解决标记，这同合并或衍合
 
 一般最简单的情形，是在 `master` 分支中维护稳定代码，然后在特性分支上开发新功能，或是审核测试别人贡献的代码，接着将它并入主干，最后删除这个特性分支，如此反复。来看示例，假设当前代码库中有两个分支，分别为 `ruby_client` 和 `php_client`，如图 5-19 所示。然后先把 `ruby_client` 合并进主干，再合并 `php_client`，最后的提交历史如图 5-20 所示。
 
-Insert 18333fig0519.png 
+Insert 18333fig0519.png
 图 5-19. 多个特性分支
 
 Insert 18333fig0520.png
@@ -757,27 +779,28 @@ Insert 18333fig0520.png
 
 对于大型项目，至少需要维护两个长期分支 `master` 和 `develop`。新代码（图 5-21 中的 `ruby_client`）将首先并入 `develop` 分支（图 5-22 中的 `C8`），经过一个阶段，确认 `develop` 中的代码已稳定到可发行时，再将 `master` 分支快进到稳定点（图 5-23 中的 `C8`）。而平时这两个分支都会被推送到公开的代码库。
 
-Insert 18333fig0521.png 
+Insert 18333fig0521.png
 图 5-21. 特性分支合并前
 
-Insert 18333fig0522.png 
+Insert 18333fig0522.png
 图 5-22. 特性分支合并后
 
-Insert 18333fig0523.png 
+Insert 18333fig0523.png
 图 5-23. 特性分支发布后
 
-这样，在人们克隆仓库时就有两种选择：既可检出最新稳定版本，确保正常使用；也能检出开发版本，试用最前沿的新特性。你也可以扩展这个概念，先将所有新代码合并到临时特性分支，等到该分支稳定下来并通过测试后，再并入 `develop` 分支。然后，让时间检验一切，如果这些代码确实可以正常工作相当长一段时间，那就有理由相信它已经足够稳定，可以放心并入主干分支发布。
+这样，在人们克隆仓库时就有两种选择：既可检出最新稳定版本，确保正常使用；也能检出开发版本，试用最前沿的新特性。
+你也可以扩展这个概念，先将所有新代码合并到临时特性分支，等到该分支稳定下来并通过测试后，再并入 `develop` 分支。然后，让时间检验一切，如果这些代码确实可以正常工作相当长一段时间，那就有理由相信它已经足够稳定，可以放心并入主干分支发布。
 
 #### 大项目的合并流程 ####
 
 Git 项目本身有四个长期分支：用于发布的 `master` 分支、用于合并基本稳定特性的 `next` 分支、用于合并仍需改进特性的 `pu` 分支（pu 是 proposed updates 的缩写），以及用于除错维护的 `maint` 分支（maint 取自 maintenance）。维护者可以按照之前介绍的方法，将贡献者的代码引入为不同的特性分支（如图 5-24 所示），然后测试评估，看哪些特性能稳定工作，哪些还需改进。稳定的特性可以并入 `next` 分支，然后再推送到公共仓库，以供其他人试用。
 
-Insert 18333fig0524.png 
+Insert 18333fig0524.png
 图 5-24. 管理复杂的并行贡献
 
 仍需改进的特性可以先并入 `pu` 分支。直到它们完全稳定后再并入 `master`。同时一并检查下 `next` 分支，将足够稳定的特性也并入 `master`。所以一般来说，`master` 始终是在快进，`next` 偶尔做下衍合，而 `pu` 则是频繁衍合，如图 5-25 所示：
 
-Insert 18333fig0525.png 
+Insert 18333fig0525.png
 图 5-25. 将特性并入长期分支
 
 并入 `master` 后的特性分支，已经无需保留分支索引，放心删除好了。Git 项目还有一个 `maint` 分支，它是以最近一次发行版为基础分化而来的，用于维护除错补丁。所以克隆 Git 项目仓库后会得到这四个分支，通过检出不同分支可以了解各自进展，或是试用前沿特性，或是贡献代码。而维护者则通过管理这些分支，逐步有序地并入第三方贡献。
@@ -788,7 +811,7 @@ Insert 18333fig0525.png
 
 另一个引入代码的方法是挑拣。挑拣类似于针对某次特定提交的衍合。它首先提取某次提交的补丁，然后试着应用在当前分支上。如果某个特性分支上有多个commits，但你只想引入其中之一就可以使用这种方法。也可能仅仅是因为你喜欢用挑拣，讨厌衍合。假设你有一个类似图 5-26 的工程。
 
-Insert 18333fig0526.png 
+Insert 18333fig0526.png
 图 5-26. 挑拣（cherry-pick）之前的历史 
 
 如果你希望拉取`e43a6`到你的主干分支，可以这样：
@@ -800,7 +823,7 @@ Insert 18333fig0526.png
 
 这将会引入`e43a6`的代码，但是会得到不同的SHA-1值，因为应用日期不同。现在你的历史看起来像图 5-27.
 
-Insert 18333fig0527.png 
+Insert 18333fig0527.png
 图 5-27. 挑拣（cherry-pick）之后的历史
 
 现在，你可以删除这个特性分支并丢弃你不想引入的那些commit。
diff --git a/zh/06-git-tools/01-chapter6.markdown b/zh/06-git-tools/01-chapter6.markdown
index a3bc97a41..078a4ac05 100644
--- a/zh/06-git-tools/01-chapter6.markdown
+++ b/zh/06-git-tools/01-chapter6.markdown
@@ -53,8 +53,6 @@ Git 可以为你的 SHA-1 值生成出简短且唯一的缩写。如果你传递
 
 通常在一个项目中，使用八到十个字符来避免 SHA-1 歧义已经足够了。最大的 Git 项目之一，Linux 内核，目前也只需要最长 40 个字符中的 12 个字符来保持唯一性。
 
-
-
 ### 关于 SHA-1 的简短说明 ###
 
 许多人可能会担心一个问题：在随机的偶然情况下，在他们的仓库里会出现两个具有相同 SHA-1 值的对象。那会怎么样呢？
@@ -65,7 +63,6 @@ Git 可以为你的 SHA-1 值生成出简短且唯一的缩写。如果你传递
 
 现在举例说一下怎样才能产生一次 SHA-1 冲突。如果地球上 65 亿的人类都在编程，每人每秒都在产生等价于整个 Linux 内核历史（一百万个 Git 对象）的代码，并将之提交到一个巨大的 Git 仓库里面，那将花费 5 年的时间才会产生足够的对象，使其拥有 50% 的概率产生一次 SHA-1 对象冲突。这要比你编程团队的成员同一个晚上在互不相干的意外中被狼袭击并杀死的机率还要小。
 
-
 ### 分支引用 ###
 
 指明一次提交的最直接的方法要求有一个指向它的分支引用。这样，你就可以在任何需要一个提交对象或者 SHA-1 值的 Git 命令中使用该分支名称了。如果你想要显示一个分支的最后一次提交的对象，例如假设 `topic1` 分支指向 `ca82a6d`，那么下面的命令是等价的：
@@ -108,7 +105,7 @@ Git 可以为你的 SHA-1 值生成出简短且唯一的缩写。如果你传递
 	$ git log -g master
 	commit 734713bc047d87bf7eac9674765ae793478c50d3
 	Reflog: master@{0} (Scott Chacon <schacon@gmail.com>)
-	Reflog message: commit: fixed refs handling, added gc auto, updated 
+	Reflog message: commit: fixed refs handling, added gc auto, updated
 	Author: Scott Chacon <schacon@gmail.com>
 	Date:   Fri Jan 2 18:32:33 2009 -0800
 
@@ -132,10 +129,10 @@ Git 可以为你的 SHA-1 值生成出简短且唯一的缩写。如果你传递
 	$ git log --pretty=format:'%h %s' --graph
 	* 734713b fixed refs handling, added gc auto, updated tests
 	*   d921970 Merge commit 'phedders/rdocs'
-	|\  
+	|\
 	| * 35cfb2b Some rdoc changes
 	* | 1c002dd added some blame and merge stuff
-	|/  
+	|/
 	* 1c36188 ignore *.gem
 	* 9b29157 add open3_detach to gemspec file list
 
@@ -193,7 +190,7 @@ Git 可以为你的 SHA-1 值生成出简短且唯一的缩写。如果你传递
 
 最常用的指明范围的方法是双点的语法。这种语法主要是让 Git 区分出可从一个分支中获得而不能从另一个分支中获得的提交。例如，假设你有类似于图 6-1 的提交历史。
 
-Insert 18333fig0601.png 
+Insert 18333fig0601.png
 图 6-1. 范围选择的提交历史实例
 
 你想要查看你的试验分支上哪些没有被提交到主分支，那么你就可以使用 `master..experiment` 来让 Git 显示这些提交的日志——这句话的意思是“所有可从experiment分支中获得而不能从master分支中获得的提交”。为了使例子简单明了，我使用了图标中提交对象的字母来代替真实日志的输出，所以会显示：
@@ -253,7 +250,6 @@ Insert 18333fig0601.png
 
 有了以上工具，让Git知道你要察看哪些提交就容易得多了。
 
-
 ## 交互式暂存 ##
 
 Git提供了很多脚本来辅助某些命令行任务。这里，你将看到一些交互式命令，它们帮助你方便地构建只包含特定组合和部分文件的提交。在你修改了一大批文件然后决定将这些变更分布在几个各有侧重的提交而不是单个又大又乱的提交时，这些工具非常有用。用这种方法，你可以确保你的提交在逻辑上划分为相应的变更集，以便于供和你一起工作的开发者审阅。如果你运行`git add`时加上`-i`或者`--interactive`选项，Git就进入了一个交互式的shell模式，显示一些类似于下面的信息：
@@ -267,7 +263,7 @@ Git提供了很多脚本来辅助某些命令行任务。这里，你将看到
 	*** Commands ***
 	  1: status     2: update      3: revert     4: add untracked
 	  5: patch      6: diff        7: quit       8: help
-	What now> 
+	What now>
 
 你会看到这个命令以一个完全不同的视图显示了你的暂存区——主要是你通过`git status`得到的那些信息但是稍微简洁但信息更加丰富一些。它在左侧列出了你暂存的变更，在右侧列出了未被暂存的变更。
 
@@ -295,7 +291,7 @@ Git提供了很多脚本来辅助某些命令行任务。这里，你将看到
 
 每个文件旁边的`*`表示选中的文件将被暂存。如果你在`update>>`提示后直接敲入回车，Git会替你把所有选中的内容暂存：
 
-	Update>> 
+	Update>>
 	updated 2 paths
 
 	*** Commands ***
@@ -377,7 +373,7 @@ Git提供了很多脚本来辅助某些命令行任务。这里，你将看到
 	   end
 
 	   def blame(path)
-	Stage this hunk [y,n,a,d,/,j,J,g,e,?]? 
+	Stage this hunk [y,n,a,d,/,j,J,g,e,?]?
 
 此处你有很多选择。输入`?`可以显示列表：
 
@@ -508,7 +504,6 @@ apply 选项只尝试应用储藏的工作——储藏的内容仍然在栈上
     $ #... work work work
     $ git stash-unapply
 
-
 ### 从储藏中创建分支 ###
 
 如果你储藏了一些工作，暂时不去理会，然后继续在你储藏工作的分支上工作，你在重新应用工作时可能会碰到一些问题。如果尝试应用的变更是针对一个你那之后修改过的文件，你会碰到一个归并冲突并且必须去化解它。如果你想用更方便的方法来重新检验你储藏的变更，你可以运行 `git stash branch`，这会创建一个新的分支，检出你储藏工作时的所处的提交，重新应用你的工作，如果成功，将会丢弃储藏。
@@ -540,7 +535,6 @@ apply 选项只尝试应用储藏的工作——储藏的内容仍然在栈上
 
 改变最近一次提交也许是最常见的重写历史的行为。对于你的最近一次提交，你经常想做两件基本事情：改变提交说明，或者改变你刚刚通过增加，改变，删除而记录的快照。
 
-
 如果你只想修改最近一次提交说明，这非常简单：
 
 	$ git commit --amend
@@ -561,7 +555,6 @@ apply 选项只尝试应用储藏的工作——储藏的内容仍然在栈上
 
 再次提醒这是一个衍合命令——`HEAD~3..HEAD`范围内的每一次提交都会被重写，无论你是否修改说明。不要涵盖你已经推送到中心服务器的提交——这么做会使其他开发者产生混乱，因为你提供了同样变更的不同版本。
 
-
 运行这个命令会为你的文本编辑器提供一个提交列表，看起来像下面这样
 
 	pick f7f3f6d changed my name a bit
@@ -702,7 +695,6 @@ Git在脚本中应用了最后一次提交（`a5f4a0d`），你的历史看起
 
 这个经常发生。有些人不经思考使用`git add .`，意外地提交了一个巨大的二进制文件，你想将它从所有地方删除。也许你不小心提交了一个包含密码的文件，而你想让你的项目开源。`filter-branch`大概会是你用来清理整个历史的工具。要从整个历史中删除一个名叫password.txt的文件，你可以在`filter-branch`上使用`--tree-filter`选项：
 
-
 	$ git filter-branch --tree-filter 'rm -f passwords.txt' HEAD
 	Rewrite 6b9b3cf04e7c5686a9cb838c3f36a8cb6a0fc2bd (21/21)
 	Ref 'refs/heads/master' was rewritten
@@ -725,7 +717,6 @@ Git在脚本中应用了最后一次提交（`a5f4a0d`），你的历史看起
 
 另一个常见的案例是你在开始时忘了运行`git config`来设置你的姓名和电子邮件地址，也许你想开源一个项目，把你所有的工作电子邮件地址修改为个人地址。无论哪种情况你都可以用`filter-branch`来更换多次提交里的电子邮件地址。你必须小心一些，只改变属于你的电子邮件地址，所以你使用`--commit-filter`：
 
-
 	$ git filter-branch --commit-filter '
 	        if [ "$GIT_AUTHOR_EMAIL" = "schacon@localhost" ];
 	        then
@@ -746,7 +737,7 @@ Git 同样提供了一些工具来帮助你调试项目中遇到的问题。由
 
 如果你在追踪代码中的缺陷想知道这是什么时候为什么被引进来的，文件标注会是你的最佳工具。它会显示文件中对每一行进行修改的最近一次提交。因此，如果你发现自己代码中的一个方法存在缺陷，你可以用`git blame`来标注文件，查看那个方法的每一行分别是由谁在哪一天修改的。下面这个例子使用了`-L`选项来限制输出范围在第12至22行：
 
-	$ git blame -L 12,22 simplegit.rb 
+	$ git blame -L 12,22 simplegit.rb
 	^4832fe2 (Scott Chacon  2008-03-15 10:31:28 -0700 12)  def show(tree = 'master')
 	^4832fe2 (Scott Chacon  2008-03-15 10:31:28 -0700 13)   command("git show #{tree}")
 	^4832fe2 (Scott Chacon  2008-03-15 10:31:28 -0700 14)  end
@@ -754,7 +745,7 @@ Git 同样提供了一些工具来帮助你调试项目中遇到的问题。由
 	9f6560e4 (Scott Chacon  2008-03-17 21:52:20 -0700 16)  def log(tree = 'master')
 	79eaf55d (Scott Chacon  2008-04-06 10:15:08 -0700 17)   command("git log #{tree}")
 	9f6560e4 (Scott Chacon  2008-03-17 21:52:20 -0700 18)  end
-	9f6560e4 (Scott Chacon  2008-03-17 21:52:20 -0700 19) 
+	9f6560e4 (Scott Chacon  2008-03-17 21:52:20 -0700 19)
 	42cf2861 (Magnus Chacon 2008-04-13 10:45:01 -0700 20)  def blame(path)
 	42cf2861 (Magnus Chacon 2008-04-13 10:45:01 -0700 21)   command("git blame #{path}")
 	42cf2861 (Magnus Chacon 2008-04-13 10:45:01 -0700 22)  end
@@ -763,8 +754,8 @@ Git 同样提供了一些工具来帮助你调试项目中遇到的问题。由
 
 另一件很酷的事情是在 Git 中你不需要显式地记录文件的重命名。它会记录快照然后根据现实尝试找出隐式的重命名动作。这其中有一个很有意思的特性就是你可以让它找出所有的代码移动。如果你在`git blame`后加上`-C`，Git会分析你在标注的文件然后尝试找出其中代码片段的原始出处，如果它是从其他地方拷贝过来的话。最近，我在将一个名叫`GITServerHandler.m`的文件分解到多个文件中，其中一个是`GITPackUpload.m`。通过对`GITPackUpload.m`执行带`-C`参数的blame命令，我可以看到代码块的原始出处：
 
-	$ git blame -C -L 141,153 GITPackUpload.m 
-	f344f58d GITServerHandler.m (Scott 2009-01-04 141) 
+	$ git blame -C -L 141,153 GITPackUpload.m
+	f344f58d GITServerHandler.m (Scott 2009-01-04 141)
 	f344f58d GITServerHandler.m (Scott 2009-01-04 142) - (void) gatherObjectShasFromC
 	f344f58d GITServerHandler.m (Scott 2009-01-04 143) {
 	70befddd GITServerHandler.m (Scott 2009-03-22 144)         //NSLog(@"GATHER COMMI
@@ -832,7 +823,6 @@ Git 发现在你标记为正常的提交(v1.0)和当前的错误版本之间有
 
 经常有这样的事情，当你在一个项目上工作时，你需要在其中使用另外一个项目。也许它是一个第三方开发的库或者是你独立开发和并在多个父项目中使用的。这个场景下一个常见的问题产生了：你想将两个项目单独处理但是又需要在其中一个中使用另外一个。
 
-
 这里有一个例子。假设你在开发一个网站，为之创建Atom源。你不想编写一个自己的Atom生成代码，而是决定使用一个库。你可能不得不像CPAN install或者Ruby gem一样包含来自共享库的代码，或者将代码拷贝到你的项目树中。如果采用包含库的办法，那么不管用什么办法都很难去定制这个库，部署它就更加困难了，因为你必须确保每个客户都拥有那个库。把代码包含到你自己的项目中带来的问题是，当上游被修改时，任何你进行的定制化的修改都很难归并。
 
 Git 通过子模块处理这个问题。子模块允许你将一个 Git 仓库当作另外一个Git仓库的子目录。这允许你克隆另外一个仓库到你的项目中并且保持你的提交相对独立。
@@ -862,7 +852,7 @@ Git 通过子模块处理这个问题。子模块允许你将一个 Git 仓库
 
 首先你注意到有一个`.gitmodules`文件。这是一个配置文件，保存了项目 URL 和你拉取到的本地子目录
 
-	$ cat .gitmodules 
+	$ cat .gitmodules
 	[submodule "rack"]
 	      path = rack
 	      url = git://github.com/chneukirchen/rack.git
@@ -1000,7 +990,6 @@ Git 通过子模块处理这个问题。子模块允许你将一个 Git 仓库
 
 ### 上层项目 ###
 
-
 有时候，开发者想按照他们的分组获取一个大项目的子目录的子集。如果你是从 CVS 或者 Subversion 迁移过来的话这个很常见，在那些系统中你已经定义了一个模块或者子目录的集合，而你想延续这种类型的工作流程。
 
 在 Git 中实现这个的一个好办法是你将每一个子目录都做成独立的 Git 仓库，然后创建一个上层项目的 Git 仓库包含多个子模块。这个办法的一个优势是你可以在上层项目中通过标签和分支更为明确地定义项目之间的关系。
@@ -1038,7 +1027,6 @@ Git 通过子模块处理这个问题。子模块允许你将一个 Git 仓库
 
 最后一个需要引起注意的是关于从子目录切换到子模块的。如果你已经跟踪了你项目中的一些文件但是想把它们移到子模块去，你必须非常小心，否则Git会生你的气。假设你的项目中有一个子目录里放了 rack 的文件，然后你想将它转换为子模块。如果你删除子目录然后运行`submodule add`，Git会向你大吼：
 
-
 	$ rm -Rf rack/
 	$ git submodule add git@github.com:schacon/rack.git rack
 	'rack' already exists in the index
@@ -1077,7 +1065,6 @@ Git 通过子模块处理这个问题。子模块允许你将一个 Git 仓库
 
 子树归并的思想是你拥有两个工程，其中一个项目映射到另外一个项目的子目录中，反过来也一样。当你指定一个子树归并，Git可以聪明地探知其中一个是另外一个的子树从而实现正确的归并——这相当神奇。
 
-
 首先你将 Rack 应用加入到项目中。你将 Rack 项目当作你项目中的一个远程引用，然后将它检出到它自身的分支：
 
 	$ git remote add rack_remote git@github.com:schacon/rack.git
@@ -1109,7 +1096,6 @@ Git 通过子模块处理这个问题。子模块允许你将一个 Git 仓库
 
 要将 Rack 项目当作子目录拉取到你的`master`项目中。你可以在 Git 中用`git read-tree`来实现。你会在第9章学到更多与`read-tree`和它的朋友相关的东西，当前你会知道它读取一个分支的根目录树到当前的暂存区和工作目录。你只要切换回你的`master`分支，然后拉取`rack_branch`到你主项目的`master`分支的`rack`子目录：
 
-
 	$ git read-tree --prefix=rack/ -u rack_branch
 
 当你提交的时候，看起来就像你在那个子目录下拥有Rack的文件——就像你从一个tarball里拷贝的一样。有意思的是你可以比较容易地归并其中一个分支的变更到另外一个。因此，如果 Rack 项目更新了，你可以通过切换到那个分支并执行拉取来获得上游的变更：
diff --git a/zh/07-customizing-git/01-chapter7.markdown b/zh/07-customizing-git/01-chapter7.markdown
index 092312c18..e2d361fed 100644
--- a/zh/07-customizing-git/01-chapter7.markdown
+++ b/zh/07-customizing-git/01-chapter7.markdown
@@ -156,13 +156,13 @@ diff包装脚本首先确定传递过来7个参数，随后把其中2个传递
 
 由于你仅仅需要`old-file`和`new-file`参数，用diff包装脚本来传递它们吧。
 
-	$ cat /usr/local/bin/extDiff 
+	$ cat /usr/local/bin/extDiff
 	#!/bin/sh
 	[ $# -eq 7 ] && /usr/local/bin/extMerge "$2" "$5"
 
 确认这两个脚本是可执行的：
 
-	$ sudo chmod +x /usr/local/bin/extMerge 
+	$ sudo chmod +x /usr/local/bin/extMerge
 	$ sudo chmod +x /usr/local/bin/extDiff
 
 现在来配置使用你自定义的比较和合并工具吧。这需要许多自定义设置：`merge.tool`通知 Git 使用哪个合并工具；`mergetool.*.cmd`规定命令运行的方式；`mergetool.trustExitCode`会通知 Git 程序的退出是否指示合并操作成功；`diff.external`通知 Git 用什么命令做比较。因此，你能运行以下4条配置命令：
@@ -184,12 +184,12 @@ diff包装脚本首先确定传递过来7个参数，随后把其中2个传递
 	  external = extDiff
 
 设置完毕后，运行diff命令：
-	
+
 	$ git diff 32d1776b1^ 32d1776b1
 
 命令行居然没有发现diff命令的输出，其实，Git 调用了刚刚设置的P4Merge，它看起来像图7-1这样：
 
-Insert 18333fig0701.png 
+Insert 18333fig0701.png
 Figure 7-1. P4Merge.
 
 当你设法合并两个分支，结果却有冲突时，运行`git mergetool`，Git 会调用P4Merge让你通过图形界面来解决冲突。
@@ -197,7 +197,7 @@ Figure 7-1. P4Merge.
 设置包装脚本的好处是你能简单地改变diff和merge工具，例如把`extDiff`和`extMerge`改成KDiff3，要做的仅仅是编辑`extMerge`脚本文件：
 
 	$ cat /usr/local/bin/extMerge
-	#!/bin/sh	
+	#!/bin/sh
 	/Applications/kdiff3.app/Contents/MacOS/kdiff3 $*
 
 现在 Git 会使用KDiff3来做比较、合并和解决冲突。
@@ -271,7 +271,7 @@ Git默认情况下不会在推送期间检查所有对象的一致性。虽然
 
 要禁用这样的强制更新功能，可以设置`receive.denyNonFastForwards`：
 
-    $ git config --system receive.denyNonFastForwards true
+	$ git config --system receive.denyNonFastForwards true
 
 稍后你会看到，用服务器端的接收钩子也能达到同样的目的。这个方法可以做更细致的控制，例如：禁用特定的用户做强制更新。
 
@@ -279,7 +279,7 @@ Git默认情况下不会在推送期间检查所有对象的一致性。虽然
 
 规避`denyNonFastForwards`策略的方法之一就是用户删除分支，然后推回新的引用。在更新的 Git 版本中（从1.6.1版本开始），把`receive.denyDeletes`设置为true：
 
-    $ git config --system receive.denyDeletes true
+	$ git config --system receive.denyDeletes true
 
 这样会在推送过程中阻止删除分支和标签 — 没有用户能够这么做。要删除远程分支，必须从服务器手动删除引用文件。通过用户访问控制列表也能这么做，在本章结尾将会介绍这些有趣的方式。
 
@@ -299,75 +299,137 @@ Git默认情况下不会在推送期间检查所有对象的一致性。虽然
 
 让 Git 把所有`pbxproj`文件当成二进制文件，在`.gitattributes`文件中设置如下：
 
-    *.pbxproj -crlf -diff
+	*.pbxproj -crlf -diff
 
 现在，Git 会尝试转换和修正CRLF（回车换行）问题，也不会当你在项目中运行git show或git diff时，比较不同的内容。在Git 1.6及之后的版本中，可以用一个宏代替`-crlf -diff`：
 
-    *.pbxproj binary
+	*.pbxproj binary
 
 #### 比较二进制文件 ####
 
-在Git 1.6及以上版本中，你能利用 Git 属性来有效地比较二进制文件。可以设置 Git 把二进制数据转换成文本格式，用通常的diff来比较。
+在 Git 中，你能利用 Git 属性来有效地比较二进制文件。可以设置 Git 把二进制数据转换成文本格式，用通常的diff来比较。
+
+We'll make use of the both described approaches to get usable diffs for some widely used binary formats.
+
+Side note: There are different kinds of binary formats with a text content, which are hard to find usable converter for. In such a case you could try to extract a text from your file with the `strings` program. Some of these files may use an UTF-16 encoding or other "codepages" and `strings` won’t find anything useful in there. Your mileage may vary. However, `strings` is available on most Mac and Linux systems, so it may be a good first try to do this with many binary formats.
+
+##### MS Word files #####
 
 这个特性很酷，而且鲜为人知，因此我会结合实例来讲解。首先，要解决的是最令人头疼的问题：对Word文档进行版本控制。很多人对Word文档又恨又爱，如果想对其进行版本控制，你可以把文件加入到 Git 库中，每次修改后提交即可。但这样做没有一点实际意义，因为运行`git diff`命令后，你只能得到如下的结果：
 
-    $ git diff
-    diff --git a/chapter1.doc b/chapter1.doc
-    index 88839c4..4afcb7c 100644
-    Binary files a/chapter1.doc and b/chapter1.doc differ
+	$ git diff
+	diff --git a/chapter1.doc b/chapter1.doc
+	index 88839c4..4afcb7c 100644
+	Binary files a/chapter1.doc and b/chapter1.doc differ
 
 你不能直接比较两个不同版本的Word文件，除非进行手动扫描，不是吗？ Git 属性能很好地解决此问题，把下面的行加到`.gitattributes`文件：
 
-    *.doc diff=word
+	*.doc diff=word
 
 当你要看比较结果时，如果文件扩展名是"doc"，Git 调用"word"过滤器。什么是"word"过滤器呢？其实就是 Git 使用`strings` 程序，把Word文档转换成可读的文本文件，之后再进行比较：
 
-    $ git config diff.word.textconv strings
+	$ git config diff.word.textconv catdoc
+
+This command adds a section to your `.git/config` that looks like this:
+
+	[diff "word"]
+		textconv = catdoc
 
 现在如果在两个快照之间比较以`.doc`结尾的文件，Git 对这些文件运用"word"过滤器，在比较前把Word文件转换成文本文件。
 
 下面展示了一个实例，我把此书的第一章纳入 Git 管理，在一个段落中加入了一些文本后保存，之后运行`git diff`命令，得到结果如下：
 
-    $ git diff
-    diff --git a/chapter1.doc b/chapter1.doc
-    index c1c8a0a..b93c9e4 100644
-    --- a/chapter1.doc
-    +++ b/chapter1.doc
-    @@ -8,7 +8,8 @@ re going to cover Version Control Systems (VCS) and Git basics
-     re going to cover how to get it and set it up for the first time if you don
-     t already have it on your system.
-     In Chapter Two we will go over basic Git usage - how to use Git for the 80%
-    -s going on, modify stuff and contribute changes. If the book spontaneously
-    +s going on, modify stuff and contribute changes. If the book spontaneously
-    +Let's see if this works.
+	$ git diff
+	diff --git a/chapter1.doc b/chapter1.doc
+	index c1c8a0a..b93c9e4 100644
+	--- a/chapter1.doc
+	+++ b/chapter1.doc
+	@@ -128,7 +128,7 @@ and data size)
+	 Since its birth in 2005, Git has evolved and matured to be easy to use
+	 and yet retain these initial qualities. It’s incredibly fast, it’s
+	 very efficient with large projects, and it has an incredible branching
+	-system for non-linear development.
+	+system for non-linear development (See Chapter 3).
 
 Git 成功且简洁地显示出我增加的文本"Let’s see if this works"。虽然有些瑕疵，在末尾显示了一些随机的内容，但确实可以比较了。如果你能找到或自己写个Word到纯文本的转换器的话，效果可能会更好。 `strings`可以在大部分Mac和Linux系统上运行，所以它是处理二进制格式的第一选择。
 
+##### OpenDocument Text files #####
+
+The same approach that we used for MS Word files (`*.doc`) can be used for OpenDocument Text files (`*.odt`) created by OpenOffice.org.
+
+Add the following line to your `.gitattributes` file:
+
+	*.odt diff=odt
+
+Now set up the `odt` diff filter in `.git/config`:
+
+	[diff "odt"]
+		binary = true
+		textconv = /usr/local/bin/odt-to-txt
+
+OpenDocument files are actually zip’ped directories containing multiple files (the content in an XML format, stylesheets, images, etc.). We’ll need to write a script to extract the content and return it as plain text. Create a file `/usr/local/bin/odt-to-txt` (you are free to put it into a different directory) with the following content:
+
+	#! /usr/bin/env perl
+	# Simplistic OpenDocument Text (.odt) to plain text converter.
+	# Author: Philipp Kempgen
+
+	if (! defined($ARGV[0])) {
+		print STDERR "No filename given!\n";
+		print STDERR "Usage: $0 filename\n";
+		exit 1;
+	}
+
+	my $content = '';
+	open my $fh, '-|', 'unzip', '-qq', '-p', $ARGV[0], 'content.xml' or die $!;
+	{
+		local $/ = undef;  # slurp mode
+		$content = <$fh>;
+	}
+	close $fh;
+	$_ = $content;
+	s/<text:span\b[^>]*>//g;           # remove spans
+	s/<text:h\b[^>]*>/\n\n*****  /g;   # headers
+	s/<text:list-item\b[^>]*>\s*<text:p\b[^>]*>/\n    --  /g;  # list items
+	s/<text:list\b[^>]*>/\n\n/g;       # lists
+	s/<text:p\b[^>]*>/\n  /g;          # paragraphs
+	s/<[^>]+>//g;                      # remove all XML tags
+	s/\n{2,}/\n\n/g;                   # remove multiple blank lines
+	s/\A\n+//;                         # remove leading blank lines
+	print "\n", $_, "\n\n";
+
+And make it executable
+
+	chmod +x /usr/local/bin/odt-to-txt
+
+Now `git diff` will be able to tell you what changed in `.odt` files.
+
+##### Image files #####
+
 你还能用这个方法比较图像文件。当比较时，对JPEG文件运用一个过滤器，它能提炼出EXIF信息 — 大部分图像格式使用的元数据。如果你下载并安装了`exiftool`程序，可以用它参照元数据把图像转换成文本。比较的不同结果将会用文本向你展示：
 
-    $ echo '*.png diff=exif' >> .gitattributes
-    $ git config diff.exif.textconv exiftool
+	$ echo '*.png diff=exif' >> .gitattributes
+	$ git config diff.exif.textconv exiftool
 
 如果在项目中替换了一个图像文件，运行`git diff`命令的结果如下：
 
-    diff --git a/image.png b/image.png
-    index 88839c4..4afcb7c 100644
-    --- a/image.png
-    +++ b/image.png
-    @@ -1,12 +1,12 @@
-     ExifTool Version Number         : 7.74
-    -File Size                       : 70 kB
-    -File Modification Date/Time     : 2009:04:21 07:02:45-07:00
-    +File Size                       : 94 kB
-    +File Modification Date/Time     : 2009:04:21 07:02:43-07:00
-     File Type                       : PNG
-     MIME Type                       : image/png
-    -Image Width                     : 1058
-    -Image Height                    : 889
-    +Image Width                     : 1056
-    +Image Height                    : 827
-     Bit Depth                       : 8
-     Color Type                      : RGB with Alpha
+	diff --git a/image.png b/image.png
+	index 88839c4..4afcb7c 100644
+	--- a/image.png
+	+++ b/image.png
+	@@ -1,12 +1,12 @@
+	 ExifTool Version Number         : 7.74
+	-File Size                       : 70 kB
+	-File Modification Date/Time     : 2009:04:17 10:12:35-07:00
+	+File Size                       : 94 kB
+	+File Modification Date/Time     : 2009:04:21 07:02:43-07:00
+	 File Type                       : PNG
+	 MIME Type                       : image/png
+	-Image Width                     : 1058
+	-Image Height                    : 889
+	+Image Width                     : 1056
+	+Image Height                    : 827
+	 Bit Depth                       : 8
+	 Color Type                      : RGB with Alpha
 
 你会发现文件的尺寸大小发生了改变。
 
@@ -377,15 +439,15 @@ Git 成功且简洁地显示出我增加的文本"Let’s see if this works"。
 
 首先，你能够把blob的SHA-1校验和自动注入文件的`$Id$`字段。如果在一个或多个文件上设置了此字段，当下次你签出分支的时候，Git 用blob的SHA-1值替换那个字段。注意，这不是提交对象的SHA校验和，而是blob本身的校验和：
 
-    $ echo '*.txt ident' >> .gitattributes
-    $ echo '$Id$' > test.txt
+	$ echo '*.txt ident' >> .gitattributes
+	$ echo '$Id$' > test.txt
 
 下次签出文件时，Git 入了blob的SHA值：
 
-    $ rm text.txt
-    $ git checkout -- text.txt
-    $ cat test.txt
-    $Id: 42812b7653c7b88933f8a9d6cad0ca16714b9bb3 $
+	$ rm test.txt
+	$ git checkout -- test.txt
+	$ cat test.txt
+	$Id: 42812b7653c7b88933f8a9d6cad0ca16714b9bb3 $
 
 然而，这样的显示结果没有多大的实际意义。这个SHA的值相当地随机，无法区分日期的前后，所以，如果你在CVS或Subversion中用过关键字替换，一定会包含一个日期值。
 
@@ -399,40 +461,40 @@ Insert 18333fig0703.png
 
 这里举一个简单的例子：在暂存前，用`indent`（缩进）程序过滤所有C源代码。在`.gitattributes`文件中设置"indent"过滤器过滤`*.c`文件：
 
-    *.c     filter=indent
+	*.c     filter=indent
 
 然后，通过以下配置，让 Git 知道"indent"过滤器在遇到"smudge"和"clean"时分别该做什么：
 
-    $ git config --global filter.indent.clean indent
-    $ git config --global filter.indent.smudge cat
+	$ git config --global filter.indent.clean indent
+	$ git config --global filter.indent.smudge cat
 
 于是，当你暂存`*.c`文件时，`indent`程序会被触发，在把它们签出之前，`cat`程序会被触发。但`cat`程序在这里没什么实际作用。这样的组合，使C源代码在暂存前被`indent`程序过滤，非常有效。
 
 另一个例子是类似RCS的`$Date$`关键字扩展。为了演示，需要一个小脚本，接受文件名参数，得到项目的最新提交日期，最后把日期写入该文件。下面用Ruby脚本来实现：
 
-    #! /usr/bin/env ruby
-    data = STDIN.read
-    last_date = `git log --pretty=format:"%ad" -1`
-    puts data.gsub('$Date$', '$Date: ' + last_date.to_s + '$')
+	#! /usr/bin/env ruby
+	data = STDIN.read
+	last_date = `git log --pretty=format:"%ad" -1`
+	puts data.gsub('$Date$', '$Date: ' + last_date.to_s + '$')
 
 该脚本从`git log`命令中得到最新提交日期，找到文件中的所有`$Date$`字符串，最后把该日期填充到`$Date$`字符串中 — 此脚本很简单，你可以选择你喜欢的编程语言来实现。把该脚本命名为`expand_date`，放到正确的路径中，之后需要在 Git 中设置一个过滤器（`dater`），让它在签出文件时调用`expand_date`，在暂存文件时用Perl清除之：
 
-    $ git config filter.dater.smudge expand_date
-    $ git config filter.dater.clean 'perl -pe "s/\\\$Date[^\\\$]*\\\$/\\\$Date\\\$/"'
+	$ git config filter.dater.smudge expand_date
+	$ git config filter.dater.clean 'perl -pe "s/\\\$Date[^\\\$]*\\\$/\\\$Date\\\$/"'
 
 这个Perl小程序会删除`$Date$`字符串里多余的字符，恢复`$Date$`原貌。到目前为止，你的过滤器已经设置完毕，可以开始测试了。打开一个文件，在文件中输入`$Date$`关键字，然后设置 Git 属性：
 
-    $ echo '# $Date$' > date_test.txt
-    $ echo 'date*.txt filter=dater' >> .gitattributes
+	$ echo '# $Date$' > date_test.txt
+	$ echo 'date*.txt filter=dater' >> .gitattributes
 
 如果暂存该文件，之后再签出，你会发现关键字被替换了：
 
-    $ git add date_test.txt .gitattributes
-    $ git commit -m "Testing date expansion in Git"
-    $ rm date_test.txt
-    $ git checkout date_test.txt
-    $ cat date_test.txt
-    # $Date: Tue Apr 21 07:26:52 2009 -0700$
+	$ git add date_test.txt .gitattributes
+	$ git commit -m "Testing date expansion in Git"
+	$ rm date_test.txt
+	$ git checkout date_test.txt
+	$ cat date_test.txt
+	# $Date: Tue Apr 21 07:26:52 2009 -0700$
 
 虽说这项技术对自定义应用来说很有用，但还是要小心，因为`.gitattributes`文件会随着项目一起提交，而过滤器（例如：`dater`）不会，所以，过滤器不会在所有地方都生效。当你在设计这些过滤器时要注意，即使它们无法正常工作，也要让整个项目运作下去。
 
@@ -446,7 +508,7 @@ Git属性在导出项目归档时也能发挥作用。
 
 例如，在`test/`子目录中有一些测试文件，在项目的压缩包中包含他们是没有意义的。因此，可以增加下面这行到 Git 属性文件中：
 
-    test/ export-ignore
+	test/ export-ignore
 
 现在，当运行git archive来创建项目的压缩包时，那个目录不会在归档中出现。
 
@@ -454,15 +516,15 @@ Git属性在导出项目归档时也能发挥作用。
 
 还能对归档做一些简单的关键字替换。在第2章中已经可以看到，可以以`--pretty=format`形式的简码在任何文件中放入`$Format:$` 字符串。例如，如果想在项目中包含一个叫作`LAST_COMMIT`的文件，当运行`git archive`时，最后提交日期自动地注入进该文件，可以这样设置：
 
-    $ echo 'Last commit date: $Format:%cd$' > LAST_COMMIT
-    $ echo "LAST_COMMIT export-subst" >> .gitattributes
-    $ git add LAST_COMMIT .gitattributes
-    $ git commit -am 'adding LAST_COMMIT file for archives'
+	$ echo 'Last commit date: $Format:%cd$' > LAST_COMMIT
+	$ echo "LAST_COMMIT export-subst" >> .gitattributes
+	$ git add LAST_COMMIT .gitattributes
+	$ git commit -am 'adding LAST_COMMIT file for archives'
 
 运行`git archive`后，打开该文件，会发现其内容如下：
 
-    $ cat LAST_COMMIT
-    Last commit date: $Format:Tue Apr 21 08:38:48 2009 -0700$
+	$ cat LAST_COMMIT
+	Last commit date: $Format:Tue Apr 21 08:38:48 2009 -0700$
 
 ### 合并策略 ###
 
@@ -470,13 +532,13 @@ Git属性在导出项目归档时也能发挥作用。
 
 如果项目的一个分支有歧义或比较特别，但你想从该分支合并，而且需要忽略其中某些文件，这样的合并策略是有用的。例如，你有一个数据库设置文件database.xml，在2个分支中他们是不同的，你想合并一个分支到另一个，而不弄乱该数据库文件，可以设置属性如下：
 
-    database.xml merge=ours
+	database.xml merge=ours
 
 如果合并到另一个分支，database.xml文件不会有合并冲突，显示如下：
 
-    $ git merge topic
-    Auto-merging database.xml
-    Merge made by recursive.
+	$ git merge topic
+	Auto-merging database.xml
+	Merge made by recursive.
 
 这样，database.xml会保持原样。
 
@@ -682,7 +744,7 @@ update 脚本和 `pre-receive` 脚本十分类似。不同之处在于它会为
 	        exit 1
 	      end
 	    end
-	  end  
+	  end
 	end
 
 	check_directory_perms
@@ -717,9 +779,9 @@ update 脚本和 `pre-receive` 脚本十分类似。不同之处在于它会为
 	Writing objects: 100% (3/3), 323 bytes, done.
 	Total 3 (delta 1), reused 0 (delta 0)
 	Unpacking objects: 100% (3/3), done.
-	Enforcing Policies... 
+	Enforcing Policies...
 	(refs/heads/master) (8338c5) (c5b616)
-	[POLICY] Cannot push a non-fast-forward reference
+	[POLICY] Cannot push a non fast-forward reference
 	error: hooks/update exited with error code 1
 	error: hook declined to update refs/heads/master
 	To git@gitserver:project.git
@@ -728,8 +790,8 @@ update 脚本和 `pre-receive` 脚本十分类似。不同之处在于它会为
 
 这里有几个有趣的信息。首先，我们可以看到挂钩运行的起点：
 
-	Enforcing Policies... 
-	(refs/heads/master) (fb8c72) (c56860)
+	Enforcing Policies...
+	(refs/heads/master) (8338c5) (c5b616)
 
 注意这是从 update 脚本开头输出到标准你输出的。所有从脚本输出的提示都会发送到客户端，这点很重要。
 
@@ -855,7 +917,7 @@ update 脚本和 `pre-receive` 脚本十分类似。不同之处在于它会为
 	target_shas.each do |sha|
 	  remote_refs.each do |remote_ref|
 	    shas_pushed = `git rev-list ^#{sha}^@ refs/remotes/#{remote_ref}`
-	    if shas_pushed.split(“\n”).include?(sha)
+	    if shas_pushed.split("\n").include?(sha)
 	      puts "[POLICY] Commit #{sha} has already been pushed to #{remote_ref}"
 	      exit 1
 	    end
diff --git a/zh/08-git-and-other-scms/01-chapter8.markdown b/zh/08-git-and-other-scms/01-chapter8.markdown
index 34fa376f6..1aae0d2a3 100644
--- a/zh/08-git-and-other-scms/01-chapter8.markdown
+++ b/zh/08-git-and-other-scms/01-chapter8.markdown
@@ -29,14 +29,14 @@ Git 中所有 Subversion 桥接命令的基础是 `git svn` 。所有的命令
 
 然后，允许所有用户修改 revprop —— 简单的做法是添加一个总是以 0 作为返回值的 pre-revprop-change 脚本：
 
-	$ cat /tmp/test-svn/hooks/pre-revprop-change 
+	$ cat /tmp/test-svn/hooks/pre-revprop-change
 	#!/bin/sh
 	exit 0;
 	$ chmod +x /tmp/test-svn/hooks/pre-revprop-change
 
 现在可以调用 `svnsync init` 加目标仓库，再加源仓库的格式来把该项目同步到本地了：
 
-	$ svnsync init file:///tmp/test-svn http://progit-example.googlecode.com/svn/ 
+	$ svnsync init file:///tmp/test-svn http://progit-example.googlecode.com/svn/
 
 这将建立进行同步所需的属性。可以通过运行以下命令来克隆代码：
 
@@ -281,7 +281,7 @@ Git 通过搜寻提交历史中 Subversion 分支的头部来决定 dcommit 的
 
 	------------------------------------------------------------------------
 	r85 | schacon | 2009-05-02 16:00:09 -0700 (Sat, 02 May 2009) | 2 lines
-	
+
 	updated the changelog
 
 关于 `git svn log` ，有两点需要注意。首先，它可以离线工作，不像 `svn log` 命令，需要向 Subversion 服务器索取数据。其次，它仅仅显示已经提交到 Subversion 服务器上的 commit。在本地尚未 dcommit 的 Git 数据不会出现在这里；其他人向 Subversion 服务器新提交的数据也不会显示。等于说是显示了最近已知 Subversion 服务器上的状态。
@@ -290,19 +290,19 @@ Git 通过搜寻提交历史中 Subversion 分支的头部来决定 dcommit 的
 
 类似 `git svn log` 对 `git log` 的模拟，`svn annotate` 的等效命令是 `git svn blame [文件名]`。其输出如下：
 
-	$ git svn blame README.txt 
+	$ git svn blame README.txt
 	 2   temporal Protocol Buffers - Google's data interchange format
 	 2   temporal Copyright 2008 Google Inc.
 	 2   temporal http://code.google.com/apis/protocolbuffers/
-	 2   temporal 
+	 2   temporal
 	22   temporal C++ Installation - Unix
 	22   temporal =======================
-	 2   temporal 
+	 2   temporal
 	79    schacon Committing in git-svn.
-	78    schacon 
+	78    schacon
 	 2   temporal To build and install the C++ Protocol Buffer runtime and the Protocol
 	 2   temporal Buffer compiler (protoc) execute the following:
-	 2   temporal 
+	 2   temporal
 
 同样，它不显示本地的 Git 提交以及 Subversion 上后来更新的内容。
 
@@ -369,7 +369,7 @@ Git 通过搜寻提交历史中 Subversion 分支的头部来决定 dcommit 的
 
 为 `git svn` 提供该文件可以然它更精确的映射作者数据。你还可以在 `clone` 或者 `init`后面添加 `--no-metadata` 来阻止 `git svn` 包含那些 Subversion 的附加信息。这样 `import` 命令就变成了：
 
-	$ git-svn clone http://my-project.googlecode.com/svn/ \
+	$ git svn clone http://my-project.googlecode.com/svn/ \
 	      --authors-file=users.txt --no-metadata -s my_project
 
 现在 `my_project` 目录下导入的 Subversion 应该比原来整洁多了。原来的 commit 看上去是这样：
@@ -396,15 +396,13 @@ Git 通过搜寻提交历史中 Subversion 分支的头部来决定 dcommit 的
 
 要把标签变成合适的 Git 标签，运行
 
-	$ cp -Rf .git/refs/remotes/tags/* .git/refs/tags/
-	$ rm -Rf .git/refs/remotes/tags
+	$ git for-each-ref refs/remotes/tags | cut -d / -f 4- | grep -v @ | while read tagname; do git tag "$tagname" "tags/$tagname"; git branch -r -d "tags/$tagname"; done
 
 该命令将原本以 `tag/` 开头的远程分支的索引变成真正的（轻巧的）标签。
 
 接下来，把 `refs/remotes` 下面剩下的索引变成本地分支：
 
-	$ cp -Rf .git/refs/remotes/* .git/refs/heads/
-	$ rm -Rf .git/refs/remotes
+	$ git for-each-ref refs/remotes | cut -d / -f 3- | grep -v @ | while read branchname; do git branch "$branchname" "refs/remotes/$branchname"; git branch -r -d "$branchname"; done
 
 现在所有的旧分支都变成真正的 Git 分支，所有的旧标签也变成真正的 Git 标签。最后一项工作就是把新建的 Git 服务器添加为远程服务器并且向它推送。下面是新增远程服务器的例子：
 
@@ -413,6 +411,7 @@ Git 通过搜寻提交历史中 Subversion 分支的头部来决定 dcommit 的
 为了让所有的分支和标签都得到上传，我们使用这条命令：
 
 	$ git push origin --all
+	$ git push origin --tags
 
 所有的分支和标签现在都应该整齐干净的躺在新的 Git 服务器里了。
 
@@ -512,7 +511,7 @@ Git 通过搜寻提交历史中 Subversion 分支的头部来决定 dcommit 的
 	    next if File.file?(dir)
 
 	    # 进入目标目录
-	    Dir.chdir(dir) do 
+	    Dir.chdir(dir) do
 	      last_mark = print_export(dir, last_mark)
 	    end
 	  end
@@ -575,7 +574,8 @@ Git 通过搜寻提交历史中 Subversion 分支的头部来决定 dcommit 的
 唯一剩下的就是每一个快照的内容了。这简单的很，因为它们分别处于一个目录——你可以输出 `deleeall` 命令，随后是目录中每个文件的内容。Git 会正确的记录每一个快照：
 
 	puts 'deleteall'
-	Dir.glob("**/*").each do |file| next if !File.file?(file)
+	Dir.glob("**/*").each do |file|
+	  next if !File.file?(file)
 	  inline_data(file)
 	end
 
@@ -607,7 +607,7 @@ Git 通过搜寻提交历史中 Subversion 分支的头部来决定 dcommit 的
 
 搞定了。现在运行该脚本，你将得到如下内容：
 
-	$ ruby import.rb /opt/import_from 
+	$ ruby import.rb /opt/import_from
 	commit refs/heads/master
 	mark :1
 	committer Scott Chacon <schacon@geemail.com> 1230883200 -0700
diff --git a/zh/09-git-internals/01-chapter9.markdown b/zh/09-git-internals/01-chapter9.markdown
index 2f1b11229..e112727ef 100644
--- a/zh/09-git-internals/01-chapter9.markdown
+++ b/zh/09-git-internals/01-chapter9.markdown
@@ -326,7 +326,7 @@ Git 用 zlib 对数据内容进行压缩，在 Ruby 中可以用 zlib 库来实
 
 现在，你的 Git 数据库应该看起来像图 9-4 一样。
 
-Insert 18333fig0904.png 
+Insert 18333fig0904.png
 图 9-4. 包含分支引用的 Git 目录对象
 
 每当你执行 `git branch (分支名称)` 这样的命令，Git 基本上就是执行 `update-ref` 命令，把你现在所在分支中最后一次提交的 SHA-1 值，添加到你要创建的分支的引用。
@@ -451,8 +451,8 @@ Git 用 zlib 压缩文件内容，因此这些文件并没有占用太多空间
 
 然后可以用 `git cat-file` 命令查看这个对象有多大：
 
-	$ git cat-file -s 9bc1dc421dcd51b4ac296e3e5b6e2a99cf44391e
-	12898
+	$ du -b .git/objects/9b/c1dc421dcd51b4ac296e3e5b6e2a99cf44391e
+	4102	.git/objects/9b/c1dc421dcd51b4ac296e3e5b6e2a99cf44391e
 
 稍微修改一下些文件，看会发生些什么：
 
@@ -470,8 +470,8 @@ Git 用 zlib 压缩文件内容，因此这些文件并没有占用太多空间
 
 blob 对象与之前的已经不同了。这说明虽然只是往一个 400 行的文件最后加入了一行内容，Git 却用一个全新的对象来保存新的文件内容：
 
-	$ git cat-file -s 05408d195263d853f09dca71d55116663690c27c
-	12908
+	$ du -b .git/objects/05/408d195263d853f09dca71d55116663690c27c
+	4109	.git/objects/05/408d195263d853f09dca71d55116663690c27c
 
 你的磁盘上有了两个几乎完全相同的 12K 的对象。如果 Git 只完整保存其中一个，并保存另一个对象的差异内容，岂不更好？
 

From a753033793125f1c6b971d0c1a1e2bc77c56396d Mon Sep 17 00:00:00 2001
From: Cor <git@cpt1.demon.nl>
Date: Mon, 17 Feb 2014 13:59:46 +0100
Subject: [PATCH 236/690] [nl] Chapter03 first part of review

---
 nl/03-git-branching/01-chapter3.markdown | 47 +++++++++++++++---------
 1 file changed, 30 insertions(+), 17 deletions(-)

diff --git a/nl/03-git-branching/01-chapter3.markdown b/nl/03-git-branching/01-chapter3.markdown
index 78dc75ca0..7adb409d0 100644
--- a/nl/03-git-branching/01-chapter3.markdown
+++ b/nl/03-git-branching/01-chapter3.markdown
@@ -1,23 +1,36 @@
+<!-- Attentie heren en dames vertalers.
+
+Ik zou het volgende willen voorstellen:
+Er zijn bepaalde termen die voor de gemiddelde Nederlandse computer gebruiker veel beter klinken (of bekender voorkomen) als de orginele Engelse term. In het begin zullen deze termen niet vaak voorkomen, maar in de meer diepgaandere hoofdstukken komen deze steeds meer voor. Termen als "Committen", "Mergen" en "Applyen" klinken beter dan "Plegen" of "Toepassen", "Samenvoegen" en "Toepassen" (wat bovendien slecht valt te onderscheiden van de commit-toepassing). De mensen die dit boek lezen zijn, naar mijn bescheiden inschatting, al redelijk op de hoogte van versiebeheer en passen (zie ik in de praktijk) deze termen al toe. Een nieuwe terminologie introduceren lijkt me dan ook niet noodzakelijk.
+Verder blijven er altijd kreten over als "directory", wat vertaald zou kunnen worden als "map", maar bij het Engelse werkwoord to map, krijgen we dan weer het probleem: hoe dit weer te vertalen. Daarom zou ik willen voorstellen om deze basis-termen toch onvertaald te laten.
+Twijfelgevallen zullen altijd blijven zoals de term "file", daarvan wordt in de praktijk zowel de term file als bestand gebruikt. Ik denk dat we hier moeten kijken hoe het in de context past. 
+Maar ook een term als "tool" en (ik zit zelf nog op een mooie Nederlandse term te broeden) "plumbing", hierbij stel ik voor om eenmalig een Nederlandse vertaling te geven, tussen haakjes de Engelse term te geven en in het vervolg de Engelse term te gebruiken. Wederom is de context hier belangrijk.
+
+Let wel: ik wil niemand tot iets verplichten, maar ik denk dat we moeten streven naar een zo duidelijk mogelijke en best bij de praktijk aansluitende vertaling moeten proberen te maken.
+
+Veel succes en plezier bij het vertalen...
+
+-->
 # Branchen in Git #
 
 Bijna elk versiebeheersysteem ondersteunt een bepaalde vorm van branchen. Branchen komt erop neer dat je een tak afsplitst van de hoofd ontwikkellijn en daar verder mee gaat werken zonder aan de hoofdlijn te komen. Bij veel VCS'en is dat nogal een duur proces, vaak wordt er een nieuwe kopie gemaakt van de directory waar je broncode in staan, wat lang kan duren voor grote projecten.
 
-Sommige mensen verwijzen naar het branch model in Git als de "killer eigenschap", en het onderscheidt Git zeker in de VCS gemeenschap. Waarom maakt het zo bijzonder? De manier waarop Git branched is ongelooflijk lichtgewicht, waardoor branch operaties vrijwel instant zijn en het wisselen tussen de branches over het algemeen net zo snel. In tegenstelling to vele andere VCS's, moedigt Git juist een werkwijze aan die vaak branched en merged, zelfs meerdere keren per dag. Deze eigenschap begrijpen en de techniek beheersen geeft je een krachtig en uniek gereedschap en kan letterlijk de manier waarop je ontwikkelt veranderen.
+Sommige mensen verwijzen naar het branch model in Git als de "killer eigenschap", en het onderscheidt Git zeker in de VCS gemeenschap. Waarom is het zo bijzonder? De manier waarop Git brancht is ongelooflijk lichtgewicht, waardoor branch operaties vrijwel instant zijn en het wisselen tussen de branches over het algemeen net zo snel. In tegenstelling to vele andere VCS's, moedigt Git juist een workflow aan waarbij vaak gebranched en gemerged wordt, zelfs meerdere keren per dag. Deze eigenschap begrijpen en de techniek beheersen geeft je een krachtig en uniek gereedschap en kan letterlijk de manier waarop je ontwikkelt veranderen.
 
 ## Wat een branch is ##
 
-Om de manier waarop Git branched echt te begrijpen, moeten we een stap terug doen en onderzoeken hoe Git zijn gegevens opslaat. Zoals je misschien herinnert van Hoofdstuk 1, slaat Git zijn gegevens niet op als een reeks van wijzigingen of delta's, maar in plaats daarvan als een serie snapshots.
+Om de manier waarop Git brancht echt te begrijpen, moeten we een stap terug doen en onderzoeken hoe Git zijn gegevens opslaat. Zoals je misschien herinnert van Hoofdstuk 1, slaat Git zijn gegevens niet op als een reeks van wijzigingen of delta's, maar in plaats daarvan als een serie snapshots.
 
 Als je in Git commit, dan slaat Git een commit object op dat een verwijzing bevat naar het snapshot van de inhoud die je gestaged hebt, de auteur en bericht metagegevens, en nul of meer verwijzingen naar de commit of commits die de directe ouders van deze commit waren: nul ouders voor de eerste commit, één ouder voor een normale commit, en meerdere ouders voor een commit die het resultaat is van een merge van twee of meer branches.
 
-Om dit te visualiseren, gaan we aannemen dat je een directory hebt met drie bestanden, en je staged en commit ze allemaal. Door de bestanden te stagen krijgen ze allemaal een checksum (de SHA-1 hash waar we het in Hoofdstuk 1 over hadden), bewaart die versie van het bestand in het Git repository (Git noemt ze blobs), en voegt die checksum toe aan het stage gebied:
+Om dit te visualiseren, gaan we aannemen dat je een directory hebt met drie bestanden, en je staged en commit ze allemaal. Door de bestanden te stagen krijgen ze allemaal een checksum (de SHA-1 hash waar we het in Hoofdstuk 1 over hadden), bewaart die versie van het bestand in het Git repository (Git noemt ze blobs), en voegt die checksum toe aan de staging area:
 
 	$ git add README test.rb LICENSE
 	$ git commit -m 'initial commit of my project'
 
-Als je de commit aanmaakt door `git commit` uit te voeren zal Git iedere project directory van een checksum voorzien en slaat ze als boomstructuur (`tree`) objecten in de Git repository op. Daarna creëert Git een `commit` object dat de metagegevens bevat en een verwijzing naar de hoofd project `tree`-object zodat Git deze snapshot kan opnieuw kan maken als dat nodig is.
+Als je de commit aanmaakt door `git commit` uit te voeren zal Git iedere project directory van een checksum voorzien en slaat ze als boomstructuur (`tree`) objecten in de Git repository op. Daarna creëert Git een `commit` object dat de metagegevens bevat en een verwijzing naar de hoofd project `tree`-object zodat Git deze snapshot kan opnieuw kan oproepen als dat nodig is.
 
-Je Git repository bevat nu vijf objecten: een blob voor de inhoud van ieder van de drie bestanden, een tree die de inhoud van de directory weergeeft en specificeert welke bestandsnamen opgeslagen zijn als welke blobs, en een commit met de verwijzing naar die hoofd tree en alle commit metagegevens. Conceptueel zien de gegevens in je Git repository eruit zoals in Figuur 3-1.
+Je Git repository bevat nu vijf objecten: een blob voor de inhoud van ieder van de drie bestanden, een tree die de inhoud van de directory weergeeft en specificeert welke bestandsnamen opgeslagen zijn als welke blobs, en een commit met de verwijzing naar die hoofd-tree en alle commit metagegevens. Conceptueel zien de gegevens in je Git repository eruit zoals in Figuur 3-1.
 
 Insert 18333fig0301.png
 Figuur 3-1. Repository gegevens van een enkele commit.
@@ -41,7 +54,7 @@ Dit maakt een nieuwe verwijzing naar dezelfde commit waar je nu op zit (zie Figu
 Insert 18333fig0304.png
 Figuur 3-4. Meerdere branches wijzend naar de commit gegevens historie.
 
-Hoe weet Git op welke branch je nu zit? Het houdt een speciale verwijzing bij genaamd HEAD. Let op dat dit heel anders is dan het concept van HEAD in andere VCS's waar je misschien gewend aan bent, zoals bijvoorbeeld Subversion of CVS. In Git, is dit een verwijzing naar de lokale branch waar je nu op zit. In dit geval, zit je nog steeds op master. Het git branch commando heeft alleen een nieuwe branch aangemaakt — het is nog niet overgeschakeld naar die branch (zie Figuur 3-5).
+Hoe weet Git op welke branch je nu zit? Het houdt een speciale verwijzing bij genaamd HEAD. Let op dat dit heel anders is dan het concept van HEAD in andere VCS's waar je misschien gewend aan bent, zoals Subversion of CVS. In Git is dit een verwijzing naar de lokale branch waar je nu op zit. In dit geval zit je nog steeds op master. Het git branch commando heeft alleen een nieuwe branch aangemaakt, we zijn nog niet overgeschakeld naar die branch (zie Figuur 3-5).
 
 Insert 18333fig0305.png
 Figuur 3-5. HEAD bestand wijzend naar de branch waar je op zit.
@@ -74,27 +87,27 @@ Figuur 3-8 toont het resultaat.
 Insert 18333fig0308.png
 Figuur 3-8. HEAD verschuift naar een andere branch bij een checkout.
 
-Dat commando heeft twee dingen gedaan. Het verplaatste de HEAD verwijzing terug naar de `master` branch, en het draaide de bestanden in je werkdirectory terug naar het snapshot waar die `master` naar wijst. Dit betekent ook dat de wijzigingen die je vanaf dit punt maakt uiteen zullen gaan lopen met een oudere versie van het project. In essentie betekent dat het werk dat je in je testing branch hebt gedaan tijdelijk wordt teruggedraait, zodat je een andere richting op kunt gaan.
+Dat commando heeft twee dingen gedaan. Het verplaatste de HEAD verwijzing terug naar de `master` branch, en het draaide de bestanden in je werkdirectory terug naar het snapshot waar die `master` naar wijst. Dit betekent ook dat de wijzigingen die je vanaf dit punt maakt uiteen zullen gaan lopen met een oudere versie van het project. In essentie betekent dat het werk dat je in je testing branch hebt gedaan tijdelijk wordt teruggedraaid, zodat je een andere richting op kunt gaan.
 
 Laten we een paar wijzigingen maken en nog eens committen:
 
 	$ vim test.rb
 	$ git commit -a -m 'made other changes'
 
-Nu is je project historie uiteen gelopen (zie Figuur 3-9). Je hebt een branch gemaakt en bent er naartoe overgeschakeld, hebt er wat werk op gedaan, en bent toen teruggeschakeld naar je hoofd branch en hebt nog wat ander werk gedaan. Al die veranderingen zijn geïsoleerd van elkaar in aparte branches: je kunt heen en weer schakelen tussen de branches en ze mergen als je klaar bent. En je hebt dat alles gedaan met eenvoudige `branch` en `checkout` commando's.
+Nu is je project historie uiteen gelopen (zie Figuur 3-9). Je hebt een branch gemaakt en bent er naartoe overgeschakeld, hebt er wat werk op gedaan, en bent toen teruggeschakeld naar je hoofd-branch en hebt nog wat ander werk gedaan. Al die veranderingen zijn geïsoleerd van elkaar in aparte branches: je kunt heen en weer schakelen tussen de branches en ze mergen als je klaar bent. En je hebt dat alles gedaan met eenvoudige `branch` en `checkout` commando's.
 
 Insert 18333fig0309.png
 Figuur 3-9. De branch histories zijn uiteen gaan lopen.
 
 Omdat een branch in Git in feite een eenvoudig bestand is dat de 40 karakter lange SHA-1 checksum van de commit bevat waar het naar wijst, zijn branches goedkoop om te maken en weer weg te gooien. Een nieuwe branch aanmaken is zo snel en eenvoudig als 41 bytes naar een bestand schrijven (40 karakters en een harde return).
 
-Dit is in scherp contrast met de wijze waarop de meeste VCS applicaties branchen, wat vaak het kopiëren van alle project bestanden naar een tweede map inhoudt. Dit kan enkele seconden of zelfs minuten duren, afhankelijk van de grootte van het project, daarentegen is het in Git altijd vrijwel meteen klaar. En omdat we de ouders opslaan terwijl we committen, wordt het vinden van een goed punt dat kan dienen als basis voor het mergen automatisch voor ons gedaan en is dat over het algemeen eenvoudig om te doen. Deze eigenschappen helpen ontwikkelaars met vertrouwen branches vaak aan te maken en te gebruiken.
+Dit is in scherp contrast met de wijze waarop de meeste VCS applicaties branchen, wat vaak het kopiëren van alle project bestanden naar een tweede map inhoudt. Dit kan enkele seconden of zelfs minuten duren, afhankelijk van de grootte van het project, daarentegen is het in Git altijd vrijwel meteen klaar. En omdat we de ouders opslaan terwijl we committen, wordt het vinden van een goed punt dat kan dienen als basis voor het mergen automatisch voor ons gedaan en is dat over het algemeen eenvoudig om te doen. Deze eigenschappen helpen ontwikkelaars aan te moedigen vaak branches aan te maken en te gebruiken.
 
 Laten we eens kijken waarom je dat zou moeten doen.
 
 ## Eenvoudig branchen en mergen ##
 
-Laten we eens door een eenvoudig voorbeeld van branchen en mergen stappen met een werkwijze die je zou kunnen gebruiken in de echte wereld. Je zult deze stappen volgen:
+Laten we eens door een eenvoudig voorbeeld van branchen en mergen stappen met een workflow die je zou kunnen gebruiken in de echte wereld. Je zult deze stappen volgen:
 
 1. Werken aan een website.
 2. Een branch aanmaken voor een nieuw verhaal waar je aan werkt.
@@ -102,9 +115,9 @@ Laten we eens door een eenvoudig voorbeeld van branchen en mergen stappen met ee
 
 Dan ontvang je een telefoontje dat je een ander probleem direct moet repareren. Je zult het volgende doen:
 
-1. Terugdraaien naar je productie branch.
+1. Terugschakelen naar je productie branch.
 2. Een branch aanmaken om de snelle reparatie toe te voegen.
-3. Nadat het getest is, de snelle reparatie branch samenvoegen, en dat naar productie terugzetten.
+3. Nadat het getest is de snelle reparatie branch mergen, en dat naar productie terugzetten.
 4. Terugschakelen naar je originele verhaal en doorgaan met werken.
 
 ### Eenvoudig branchen ###
@@ -114,7 +127,7 @@ Als eerste, laten we zeggen dat je aan je project werkt en al een paar commits h
 Insert 18333fig0310.png
 Figuur 3-10. Een korte en eenvoudige commit historie.
 
-Je hebt besloten dan je gaat werken aan probleem #53 in wat voor systeem je bedrijf ook gebruikt om problemen te registreren. Voor de duidelijkheid: Git is niet verbonden met een probleem beheersysteem in het bijzonder, maar omdat probleem #53 een specifiek onderwerp is waar je aan wilt werken, zul je een nieuwe branch aanmaken waarin je gaat werken. Om een branch aan te maken en er meteen naartoe te schakelen, kun je het `git checkout` commando uitvoeren met de `-b` optie:
+Je hebt besloten dan je gaat werken aan probleem #53 in wat voor systeem je bedrijf ook gebruikt om problemen te registreren. Voor de duidelijkheid: Git is niet verbonden met een probleem beheersysteem in het bijzonder. En omdat probleem #53 een specifiek onderwerp is waar je aan gaat werken, maak je een nieuwe branch aan waarin je aan de slag gaat. Om een branch aan te maken en er meteen naartoe te schakelen, kun je het `git checkout` commando uitvoeren met de `-b` optie:
 
 	$ git checkout -b iss53
 	Switched to a new branch "iss53"
@@ -139,7 +152,7 @@ Figuur 3-12. De iss53 branch is vooruit gegaan met je werk.
 
 Nu krijg je het telefoontje dan er een probleem is met de web site, en je moet het meteen repareren. Met Git hoef je de reparatie niet tegelijk uit te leveren met de `iss53` wijzigingen die je gemaakt hebt, en je hoeft ook niet veel moeite te doen om die wijzigingen terug te draaien voordat je kunt werken aan het toepassen van je reparatie in productie. Het enige wat je moet doen in terugschakelen naar je master branch.
 
-Maar voordat je dat doet, let op dat als je werk directory of staging gebied wijzigingen bevat die nog niet gecommit zijn en conflicteren met de branch die je gaat uitchecken, Git je niet toestaat om te schakelen. Het is het beste om een schone werk status te hebben als je tussen branches gaat schakelen. Er zijn manieren om hier mee om te gaan (te weten, stashen en commit ammending) die we later gaan behandelen. Voor nu heb je alle wijzigingen gecommit, zodat je terug kunt schakelen naar je master branch:
+Maar voordat je dat doet, let op dat als je werk directory of staging area wijzigingen bevat die nog niet gecommit zijn en conflicteren met de branch die je gaat uitchecken, Git je niet laat om te schakelen. Het beste is  om een schone werk status te hebben als je tussen branches gaat schakelen. Er zijn manieren om hier mee om te gaan (te weten, stashen en commit ammending) die we later gaan behandelen. Voor nu heb je alle wijzigingen gecommit, zodat je terug kunt schakelen naar je master branch:
 
 	$ git checkout master
 	Switched to branch "master"
@@ -337,15 +350,15 @@ Dit toont je andere branch. Omdat het werk bevat dat nog niet samengevoegd is, z
 
 Als je de branch echt wilt verwijderen en dat werk wilt verliezen, dan kun je het forceren met `-D`, zoals het behulpzame bericht je al meldt.
 
-## Branch werkwijzen ##
+## Branch workflows ##
 
-Nu dat je de basis van het branchen en samenvoegen onder de knie hebt, wat kan of zou je met ze kunnen doen? In deze paragraaf gaan we een aantal veel voorkomende werkwijzen die deze lichtgewicht branches mogelijk maken behandelen, zodat je kunt besluiten of je ze wilt toepassen in jouw ontwikkel cyclus.
+Nu dat je de basis van het branchen en samenvoegen onder de knie hebt, wat kan of zou je met ze kunnen doen? In deze paragraaf gaan we een aantal veel voorkomende workflows die deze lichtgewicht branches mogelijk maken behandelen, zodat je kunt besluiten of je ze wilt toepassen in jouw ontwikkel cyclus.
 
 ### Lang-lopende branches ###
 
 Omdat Git gebruik maakt van een eenvoudige drieweg merge, is het meerdere keren mergen vanuit een branch in een andere gedurende een langere periode over het algemeen eenvoudig te doen. Dit betekent dat je meerdere branches kunt hebben, die altijd open staan en die je voor verschillende delen van je ontwikkel cyclus gebruikt; je kunt regelmatig een aantal mergen in andere.
 
-Veel Git ontwikkelaars hebben een werkwijze die deze aanpak omarmt, zoals het hebben van alleen volledig stabiele code in hun `master` branch — waarschijnlijk alleen code die is of zal worden vrijgegeven. Ze hebben een andere parallelle branch "develop" of "next" genaamd waarop ze werken of die ze gebruiken om stabiliteit te testen — het is niet noodzakelijk altijd stabiel, maar zodra het in een stabiele status verkeert, kan het worden gemerged in `master`. Het wordt gebruikt om topic branches (branches met een korte levensduur, zoals jou eerdere `iss53` branch) te pullen zodra die klaar zijn, om er zich ervan te verzekeren dat alle testen slagen en er geen fouten worden geïntroduceerd.
+Veel Git ontwikkelaars hebben een workflow die deze aanpak omarmt, zoals het hebben van alleen volledig stabiele code in hun `master` branch — waarschijnlijk alleen code die is of zal worden vrijgegeven. Ze hebben een andere parallelle branch "develop" of "next" genaamd waarop ze werken of die ze gebruiken om stabiliteit te testen — het is niet noodzakelijk altijd stabiel, maar zodra het in een stabiele status verkeert, kan het worden gemerged in `master`. Het wordt gebruikt om topic branches (branches met een korte levensduur, zoals jou eerdere `iss53` branch) te pullen zodra die klaar zijn, om er zich ervan te verzekeren dat alle testen slagen en er geen fouten worden geïntroduceerd.
 
 In essentie praten we over verwijzingen die zich verplaatsen over de lijn van de commits die je maakt. De stabiele branches zijn verder naar achter in je commit historie, en de splinternieuwe branches zijn verder naar voren in de historie (zie Figuur 3-18).
 

From 33820f55ce9e90e62dd61be3b00bcc60ecb787af Mon Sep 17 00:00:00 2001
From: cor <git@cpt1.demon.nl>
Date: Mon, 17 Feb 2014 21:30:28 +0100
Subject: [PATCH 237/690] [nl] Chapter 05 - Remove yet more typos

   Reviewed contents against the en version and removed language errors.
   Also clarified some sentences. Finally: corrected hexadecimal
   characters (especially diacritics).
---
 nl/05-distributed-git/01-chapter5.markdown | 253 ++++++++++++---------
 1 file changed, 144 insertions(+), 109 deletions(-)

diff --git a/nl/05-distributed-git/01-chapter5.markdown b/nl/05-distributed-git/01-chapter5.markdown
index 25c320dc3..6ce3eb1ac 100644
--- a/nl/05-distributed-git/01-chapter5.markdown
+++ b/nl/05-distributed-git/01-chapter5.markdown
@@ -1,70 +1,105 @@
+<!-- Attentie heren en dames vertalers.
+Ik zou het volgende willen voorstellen:
+Er zijn bepaalde termen die voor de gemiddelde Nederlandse computer gebruiker 
+veel beter klinken (of bekender voorkomen) als de orginele Engelse term. In het
+begin zullen deze termen niet vaak voorkomen, maar in de meer diepgaandere 
+hoofdstukken komen deze steeds meer voor. Termen als "Committen", "Mergen" 
+en "Applyen" klinken beter dan "Plegen" of "Toepassen", "Samenvoegen" en 
+"Toepassen" (wat bovendien slecht valt te onderscheiden van de 
+commit-toepassing). De mensen die dit boek lezen zijn, naar mijn bescheiden 
+inschatting, al redelijk op de hoogte van versiebeheer en passen (zie ik in 
+de praktijk) deze termen al toe. Een nieuwe terminologie introduceren lijkt 
+me dan ook niet noodzakelijk.
+Verder blijven er altijd kreten over als "directory", wat vertaald zou kunnen 
+worden als "map", maar bij het Engelse werkwoord to map krijgen we dan weer het
+probleem: hoe dit weer te vertalen? Daarom zou ik willen voorstellen om deze 
+basis-termen toch onvertaald te laten.
+
+Twijfelgevallen zullen altijd blijven zoals de term "file", daarvan wordt in de
+praktijk zowel de term file als bestand gebruikt. Ik denk dat we hier moeten 
+kijken hoe het in de context past. 
+Maar ook een term als "tool" en (ik zit zelf nog op een mooie Nederlandse term
+te broeden) "plumbing", hierbij stel ik voor om eenmalig een Nederlandse 
+vertaling te geven, tussen haakjes de Engelse term te geven en in het vervolg
+de Engelse term te gebruiken. Wederom is de context hier belangrijk.
+
+Verder stel ik ook voor om de regels op https://onzetaal.nl/taaladvies zoveel
+mogelijk te volgen. Bijvoorbeeld de regels omtrent het spellen van Engelse 
+werkwoorden die in het Nederlands gebruikt worden.
+
+Let wel: ik wil niemand tot iets verplichten, maar ik denk dat we moeten 
+streven naar een zo duidelijk mogelijke en best bij de praktijk aansluitende
+vertaling moeten proberen te maken.
+
+Veel succes en plezier bij het vertalen...
+-->
 # Gedistribueerd Git #
 
-Nu dat je een remote Git repository hebt ingesteld als een plaats waar alle ontwikkelaars hun code kunnen delen, en je bekend bent met fundamentele Git commando's in een lokale werkwijze, zul je hier zien hoe je een paar gedistribueerde werkwijzen kunt gebruiken die je met Git kunt bereiken.
+Nu je een remote Git repository hebt ingesteld als een plaats waar alle ontwikkelaars hun code kunnen delen, en je bekend bent met fundamentele Git commando's in een lokale workflow, zul je hier zien hoe je een paar gedistribueerde workflows kunt gebruiken die je met Git kunt bereiken.
 
 In dit hoofdstuk zul je zien hoe je met Git kunt werken in een gedistribueerde omgeving als een bijdrager (contributor) en als een integrator. Dat wil zeggen, je zult leren hoe je succesvol code kunt bijdragen aan een project en hoe je het zo makkelijk mogelijk maakt voor jou en de onderhouder van het project, en ook hoe je een project succesvol kunt onderhouden waarbij een aantal ontwikkelaars bijdragen.
 
-## Gedistribueerde werkwijzen ##
+## Gedistribueerde workflows ##
 
-In tegenstelling tot gecentraliseerde versiebeheersystemen (CVCSen), stelt de gedistribueerde aard van Git je in staat om veel flexibeler te zijn in de manier waarop ontwikkelaars samenwerken in projecten. Bij gecentraliseerde systemen is iedere ontwikkelaar een knooppunt dat min of meer gelijkwaardig werkt op een centraal punt. In Git is iedere ontwikkelaar zowel een knooppunt als een spil - dat wil zeggen, iedere ontwikkelaar kan zowel code bijdragen aan andere repositories, als ook een publiek repository beheren waarop andere ontwikkelaars hun werk baseren en waaraan zij kunnen bijdragen. Dit stelt je project en/of je team in staat om een enorm aantal werkwijzen er op na te houden, dus ik zal een aantal veel voorkomende manieren behandelen die gebruik maken van deze flexibiliteit. Ik zal de sterke en mogelijke zwakke punten van ieder ontwerp behandelen; je kunt er een kiezen om te gebruiken, of je kunt van iedere wijze een paar eigenschappen overnemen en mengen.
+In tegenstelling tot gecentraliseerde versiebeheersystemen (CVCSen), stelt de gedistribueerde aard van Git je in staat om veel flexibeler te zijn in de manier waarop ontwikkelaars samenwerken in projecten. Bij gecentraliseerde systemen is iedere ontwikkelaar een knooppunt dat min of meer gelijkwaardig werkt op een centraal punt. In Git is iedere ontwikkelaar zowel een knooppunt als een spil - dat wil zeggen, iedere ontwikkelaar kan zowel code bijdragen aan andere repositories, als ook een publiek repository beheren waarop andere ontwikkelaars hun werk baseren en waaraan zij kunnen bijdragen. Dit stelt je project en/of je team in staat om een enorm aantal workflows er op na te houden, dus ik zal een aantal veel voorkomende manieren behandelen die gebruik maken van deze flexibiliteit. Ik zal de sterke en mogelijke zwakke punten van ieder ontwerp behandelen; je kunt er een kiezen om te gebruiken, of je kunt van iedere wijze een paar eigenschappen overnemen en mengen.
 
-### Gecentraliseerde werkwijze ###
+### Gecentraliseerde workflow ###
 
-In gecentraliseerde systemen is er over het algemeen een enkel samenwerkingsmodel - de gecentraliseerde werkwijze. Eén centraal punt, of repository, kan code aanvaarden, en iedereen synchroniseert zijn werk daarmee. Een aantal ontwikkelaars zijn knopen - gebruikers van dat centrale punt - en synchroniseren met die plaats (zie Figuur 5-1).
+In gecentraliseerde systemen is er over het algemeen een enkel samenwerkingsmodel - de gecentraliseerde workflow. Één centraal punt, of repository, kan code aanvaarden, en iedereen synchroniseert zijn werk daarmee. Een aantal ontwikkelaars zijn knopen - gebruikers van dat centrale punt - en synchroniseren met die plaats (zie Figuur 5-1).
 
 Insert 18333fig0501.png
-Figuur 5-1. Gecentraliseerde Werkwijze.
+Figuur 5-1. Gecentraliseerde workflow.
 
-Dit betekent dat als twee ontwikkelaars klonen van het gecentraliseerde punt en beide wijzigingen doen, de eerste ontwikkelaar zijn wijzigingen terug kan zetten zonder problemen. De tweede ontwikkelaar zal het werk van de eerste in het zijne moeten samenvoegen voordat hij het zijne kan terugzetten, om zo niet het werk van de eerste te overschrijven. Dit concept werkt in Git zoals het ook werkt in Subversion (of ieder ander CVCS), en dit model werkt prima in Git.
+Dit betekent dat als twee ontwikkelaars clonen van het gecentraliseerde punt en beiden wijzigingen doen, de eerste ontwikkelaar zijn wijzigingen zonder problemen kan pushen. De tweede ontwikkelaar zal het werk van de eerste in het zijne moeten mergen voordat hij het zijne kan pushen, om zo niet het werk van de eerste te overschrijven. Dit concept werkt in Git zoals het ook werkt in Subversion (of ieder ander CVCS), en dit model werkt prima in Git.
 
-Als je een klein team hebt, of al vertrouwd bent met een gecentraliseerde werkwijze in je bedrijf of team, dan kun je eenvoudig doorgaan met het gebruiken van die werkwijze met Git. Stel eenvoudigweg een enkele repository in, en geef iedereen in je team  push-toegang; Git zal gebruikers niet toestaan om elkaars wijzigingen te overschrijven. Als een ontwikkelaar kloont, wijzigingen maakt, en dan probeert zijn wijzigingen terug te zetten terwijl een andere ontwikkelaar de zijne in de tussentijd heeft teruggezet, dan zal de server de wijzigingen van die ontwikkelaar weigeren. Ze zullen verteld worden dat ze een "non-fast-forward-wijziging" proberen te pushen en dat ze dat niet wordt toegestaan totdat ze hebben gefetched en gemerged.
-Deze werkwijze is voor een hoop mensen aantrekkelijk omdat het er een is waarmee veel mensen bekend zijn en zich op hun gemak bij voelen.
+Als je een klein team hebt, of al vertrouwd bent met een gecentraliseerde workflow in je bedrijf of team, dan kun je eenvoudig doorgaan met het gebruiken van die workflow met Git. Stel eenvoudigweg een enkele repository in, en geef iedereen in je team  push-toegang; Git zal gebruikers niet toestaan om elkaars wijzigingen te overschrijven. Als een ontwikkelaar cloned, wijzigingen maakt, en dan probeert zijn wijzigingen te pushen terwijl een andere ontwikkelaar de zijne in de tussentijd heeft gepusht, dan zal de server de wijzigingen van die ontwikkelaar weigeren. Ze zullen verteld worden dat ze een "non-fast-forward-wijziging" proberen te pushen en dat ze dat niet wordt toegestaan totdat ze hebben gefetched en gemerged.
+Deze workflow is voor een hoop mensen aantrekkelijk omdat het er een is waarmee veel mensen bekend zijn en zich op hun gemak bij voelen.
 
-### Integratie-manager werkwijze ###
+### Integratie-manager workflow ###
 
-Omdat Git je toestaat om meerdere remote repositories te hebben, is het mogelijk om een werkwijze te hebben waarbij iedere ontwikkelaar schrijftoegang heeft tot zijn eigen publieke repository en leestoegang op de andere. Dit scenario heeft vaak een gezagdragend (canonical) repository dat het "officiële" project voorstelt. Om bij te kunnen dragen tot dat project, maak je je eigen publieke kloon van het project en zet je wijzigingen daarin terug. Daarna stuur je een verzoek naar de eigenaar van het hoofdproject om jouw wijzigingen binnen te halen (pull request). Hij kan je repository toevoegen als een remote, je wijzigingen lokaal testen, ze in zijn branch mergen, en naar zijn repository terugzetten. Het proces werkt als volgt (zie Figuur 5-2):
+Omdat Git je toestaat om meerdere remote repositories te hebben, is het mogelijk om een workflow te hebben waarbij iedere ontwikkelaar schrijftoegang heeft tot zijn eigen publieke repository en leestoegang op de andere. Dit scenario heeft vaak een gezagdragend (canonical) repository dat het "officiële" project voorstelt. Om bij te kunnen dragen tot dat project, maak je je eigen publieke clone van het project en pusht je wijzigingen daarin terug. Daarna stuur je een verzoek naar de eigenaar van het hoofdproject om jouw wijzigingen binnen te halen (pull request). Hij kan je repository toevoegen als een remote, je wijzigingen lokaal testen, ze in zijn branch mergen, en dan naar zijn repository pushen. Het proces werkt als volgt (zie Figuur 5-2):
 
-1. De projecteigenaar pushed naar de publieke repository.
-2. Een bijdrager kloont die repository en maakt wijzigingen.
-3. De bijdrager pushed naar zijn eigen publieke kopie.
+1. De projecteigenaar pusht naar de publieke repository.
+2. Een bijdrager cloned die repository en maakt wijzigingen.
+3. De bijdrager pusht naar zijn eigen publieke kopie.
 4. De bijdrager stuurt de eigenaar een e-mail met de vraag om de wijzigingen binnen te halen (pull request).
 5. De eigenaar voegt de repo van de bijdrager toe als een remote en merged lokaal.
-6. De eigenaar pushed de gemergde wijzigingen terug in de hoofdrepository.
+6. De eigenaar pusht de gemergde wijzigingen terug in de hoofdrepository.
 
 Insert 18333fig0502.png
-Figuur 5-2. Integratie-manager werkwijze.
+Figuur 5-2. Integratie-manager workflow.
 
-Dit is een veel voorkomende werkwijze bij websites zoals GitHub, waarbij het eenvoudig is om een project af te splitsen (fork) en je wijzigingen terug te zetten in jouw afgesplitste project waar iedereen ze kan zien. Een van de grote voordelen van deze aanpak is dat je door kunt gaan met werken, en de eigenaar van de hoofdrepository jouw wijzigingen op ieder moment binnen kan halen. Bijdragers hoeven niet te wachten tot het project hun bijdragen invoegt - iedere partij kan op zijn eigen tempo werken.
+Dit is een veel voorkomende workflow bij websites zoals GitHub, waarbij het eenvoudig is om een project af te splitsen (fork) en je wijzigingen te pushen in jouw afgesplitste project waar iedereen ze kan zien. Een van de grote voordelen van deze aanpak is dat je door kunt gaan met werken, en de eigenaar van de hoofdrepository jouw wijzigingen op ieder moment kan pullen. Bijdragers hoeven niet te wachten tot het project hun bijdragen invoegt - iedere partij kan op zijn eigen tempo werken.
 
-### Dictator en luitenanten werkwijze ###
+### Dictator en luitenanten workflow ###
 
-Dit is een variant op de multi-repository werkwijze. Het wordt over het algemeen gebruikt bij enorme grote projecten met honderden bijdragers; een bekend voorbeeld is de Linux-kernel. Een aantal integrators geven de leiding over bepaalde delen van het repository, zij worden luitenanten genoemd. Alle luitenanten hebben één integrator die bekend staat als de welwillende dictator. De repository van de welwillende dictator dient als het referentierepository vanwaar alle bijdragers dienen binnen te halen. Het proces werkt als volgt (zie Figuur 5-3):
+Dit is een variant op de multi-repository workflow. Het wordt over het algemeen gebruikt bij enorme grote projecten met honderden bijdragers; een bekend voorbeeld is de Linux-kernel. Een aantal integrators geven de leiding over bepaalde delen van de repository, zij worden luitenanten genoemd. Alle luitenanten hebben één integrator die bekend staat als de welwillende dictator. De repository van de welwillende dictator dient als het referentierepository vanwaar alle bijdragers dienen binnen te halen. Het proces werkt als volgt (zie Figuur 5-3):
 
 1. Reguliere ontwikkelaars werken op hun eigen onderwerp (topic) branch en rebasen hun werk op de master. De masterbranch is die van de dictator.
 2. Luitenanten mergen de topic branches van de ontwikkelaars in hun masterbranch.
 3. De dictator merged de masterbranches van de luitenanten in de masterbranch van de dictator.
-4. De dictator pushed zijn masterbranch terug naar het referentierepository zodat de andere ontwikkelaars kunnen rebasen.
+4. De dictator pusht zijn masterbranch terug naar het referentierepository zodat de andere ontwikkelaars kunnen rebasen.
 
 Insert 18333fig0503.png
 Figuur 5-3. Welwillende-dictatorwerkwijze.
 
 Deze manier van werken is niet gewoon, maar kan handig zijn in hele grote projecten of in zeer hiërarchische omgevingen, omdat het de projectleider (de dictator) in staat stelt om het meeste werk te delegeren en grote subsets van code te verzamelen op meerdere punten alvorens ze te integreren.
 
-Dit zijn veel voorkomende werkwijzen die mogelijk zijn met een gedistribueerd systeem als Git, maar je kunt zien dat er veel variaties mogelijk zijn om ze te laten passen bij jouw specifieke werkwijze. Nu dat je (naar ik hoop) in staat bent om te bepalen welke combinatie van werkwijzen voor jou werkt, zal ik wat specifiekere voorbeelden behandelen over hoe je de belangrijkste rollen kunt vervullen, die in de verschillende werkwijzen voorkomen.
+Dit zijn veel voorkomende workflows die mogelijk zijn met een gedistribueerd systeem als Git, maar je kunt zien dat er veel variaties mogelijk zijn om ze te laten passen bij jouw specifieke workflow. Nu dat je (naar ik hoop) in staat bent om te bepalen welke combinatie van workflows voor jou werkt, zal ik wat specifiekere voorbeelden behandelen hoe je de belangrijkste rollen kunt vervullen die in de verschillende workflows voorkomen.
 
 ## Bijdragen aan een project ##
 
-Je weet wat de verschillende werkwijzen zijn, en je zou het fundamentele gebruik van Git in de vingers moeten hebben. In dit gedeelte zul je leren over een aantal voorkomende patronen voor het bijdragen aan een project.
+Je weet wat de verschillende workflows zijn, en je zou het fundamentele gebruik van Git in de vingers moeten hebben. In dit gedeelte zul je leren over een aantal voorkomende patronen voor het bijdragen aan een project.
 
-De grote moeilijkheid bij het beschrijven van dit proces is dat er een enorm aantal variaties mogelijk zijn in hoe het gebeurt. Om dat Git erg flexibel is, kunnen en zullen mensen op vele manieren samenwerken, en het is lastig om te beschrijven hoe je zou moeten bijdragen aan een project - ieder project is een beetje anders. Een aantal van de betrokken variabelen zijn de grote van actieve bijdragen, gekozen werkwijze, je commit toegang, een mogelijk de manier waarop externe bijdragen worden gedaan.
+De grote moeilijkheid bij het beschrijven van dit proces is dat er een enorm aantal variaties mogelijk zijn in hoe het gebeurt. Om dat Git erg flexibel is, kunnen en zullen mensen op vele manieren samenwerken, en het is lastig om te beschrijven hoe je zou moeten bijdragen aan een project - ieder project is een beetje anders. Een aantal van de betrokken variabelen zijn de grote van actieve bijdragen, gekozen workflow, je commit toegang, en mogelijk de manier waarop externe bijdragen worden gedaan.
 
-De eerste variabele is de grootte van actieve bijdrage. Hoeveel gebruikers dragen actief code bij aan dit project, en hoe vaak? In veel gevallen zul je twee of drie ontwikkelaars met een paar commits per dag hebben, of misschien minder voor wat meer slapende projecten. Voor zeer grote bedrijven of projecten kan het aantal ontwikkelaars in de duizenden lopen, met tientallen of zelfs honderden patches die iedere dag binnenkomen. Dit is belangrijk omdat met meer en meer ontwikkelaars, je meer en meer problemen tegenkomt met het zeker zijn dat code netjes gepatched of eenvoudig gemerged kan worden. Wijzigingen die je indient kunnen verouderd of zwaar beschadigd raken door werk dat gemerged is terwijl je er aan het werken was of terwijl je wijzigingen in de wacht stonden voor goedkeuring of toepassing. Hoe kun je je code consequent bij de tijd en je patches geldig houden?
+De eerste variabele is de grootte van actieve bijdrage. Hoeveel gebruikers dragen actief code bij aan dit project, en hoe vaak? In veel gevallen zal je twee of drie ontwikkelaars met een paar commits per dag hebben, of misschien minder voor wat meer slapende projecten. Voor zeer grote bedrijven of projecten kan het aantal ontwikkelaars in de duizenden lopen, met tientallen of zelfs honderden patches die iedere dag binnenkomen. Dit is belangrijk omdat met meer en meer ontwikkelaars, je meer en meer problemen tegenkomt bij het je verzekeren dat code netjes gepatched of eenvoudig gemerged kan worden. Wijzigingen die je indient kunnen verouderd of zwaar beschadigd raken door werk dat gemerged is terwijl je ermee aan het werken was, of terwijl je wijzigingen in de wacht stonden voor goedkeuring of toepassing. Hoe kun je jouw code consequent bij de tijd en je patches geldig houden?
 
-De volgende variabele is de gebruikte werkwijze in het project. Is het gecentraliseerd, waarbij iedere ontwikkelaar gelijkwaardige schrijftoegang heeft tot de hoofd codebasis? Heeft het project een eigenaar of integrator die alle patches controleert? Worden alle patches gereviewed en goedgekeurd? Ben jij betrokken bij dat proces? Is er een luitenanten systeem neergezet, en moet je je werk eerst bij hen inleveren?
+De volgende variabele is de gebruikte workflow in het project. Is het gecentraliseerd, waarbij iedere ontwikkelaar gelijkwaardige schrijftoegang heeft tot de hoofd codebasis? Heeft het project een eigenaar of integrator die alle patches controleert? Worden alle patches gereviewed en goedgekeurd? Ben jij betrokken bij dat proces? Is er een luitenanten systeem neergezet, en moet je je werk eerst bij hen inleveren?
 
-Het volgende probleem is je commit toegang. De benodigde werkwijze om bij te dragen aan een project is heel verschillend als je schrijftoegang hebt tot het project dan wanneer je dat niet hebt. Als je geen schrijftoegang hebt, wat heeft de voorkeur van het project om bijdragen te ontvangen? Is er wel een beleid? Hoeveel werk draag je per keer bij? Hoe vaak draag je bij?
+Het volgende probleem is je commit toegang. De benodigde workflow om bij te dragen aan een project is heel verschillend als je schrijftoegang hebt tot het project dan wanneer je dat niet hebt. Als je geen schrijftoegang hebt, wat is de voorkeur van het project om bijdragen te ontvangen? Is er überhaupt een beleid? Hoeveel werk draag je per keer bij? Hoe vaak draag je bij?
 
-Al deze vragen kunnen van invloed zijn op hoe je effectief bijdraagt aan een project en welke werkwijzen de voorkeur hebben of die beschikbaar zijn voor je. Ik zal een aantal van deze aspecten behandelen in een aantal voorbeelden, waarbij ik van eenvoudig tot complex zal gaan; je zou in staat moeten zijn om de specifieke werkwijzen die je in de praktijk hebt te kunnen herleiden vanuit deze voorbeelden.
+Al deze vragen kunnen van invloed zijn op hoe je effectief bijdraagt aan een project en welke workflows de voorkeur hebben of die beschikbaar zijn voor je. Ik zal een aantal van deze aspecten behandelen in een aantal voorbeelden, waarbij ik van eenvoudig tot complex zal gaan. Je zou in staat moeten zijn om de specifieke workflows die je in jouw praktijk nodig hebt te kunnen herleiden vanuit deze voorbeelden.
 
 ### Commit richtlijnen ###
 
@@ -80,11 +115,11 @@ Als eerste wil je geen witruimte fouten indienen. Git geeft je een eenvoudige ma
 	lib/simplegit.rb:26: trailing whitespace.
 	+    def command(git_cmd)XXXX
 
-Als je dat commando uitvoert alvorens te committen, kun je al zien of je op het punt staat witruimte problemen te committen die waaraan andere ontwikkelaars zich zullen ergeren.
+Als je dat commando uitvoert alvorens te committen, kun je al zien of je op het punt staat witruimte problemen te committen waaraan andere ontwikkelaars zich zullen ergeren.
 
-Probeer vervolgens om van elke commit een logische set wijzigingen te maken. Probeer, als het je lukt, om je wijzigingen verteerbaar te maken - ga niet het hele weekend zitten coderen op vijf verschillende problemen om dat vervolgens op maandag als een gigantische commit in te dienen. Zelfs als je gedurende het weekend niet commit, gebruik dan het staging gebied op maandag om je werk in ten minste één commit per probleem op te splitsen, met een bruikbaar bericht per commit. Als een paar van de wijzigingen één bestand veranderen, probeer dan `git add --patch` te gebruiken om bestanden gedeeltelijk te stagen (wordt in detail behandeld in Hoofdstuk 6). De laatste snapshot van het project is gelijk of je nu één commit doet of vijf, zolang alle wijzigingen op een gegeven momment maar toegevoegd zijn, dus probeer om het je mede-ontwikkelaars makkelijk te maken als ze je wijzigingen moeten bekijken. Deze aanpak maakt het ook makkelijker om één wijziging te pullen of terug te draaien, mocht dat later nodig zijn. Hoofdstuk 6 beschrijft een aantal handige Git trucs om geschiedenis te herschrijven en bestanden interactief te stagen - gebruik deze gereedschappen een schone en begrijpelijke historie te helpen op te bouwen.
+Probeer vervolgens om van elke commit een logische set wijzigingen te maken. Probeer, als het je lukt, om je wijzigingen verteerbaar te maken - ga niet het hele weekend zitten coderen op vijf verschillende problemen om dat vervolgens op maandag als een gigantische commit in te dienen. Zelfs als je gedurende het weekend niet commit, gebruik dan het staging gebied op maandag om je werk in ten minste één commit per probleem op te splitsen, met een bruikbaar bericht per commit. Als een paar van de wijzigingen één bestand veranderen, probeer dan `git add --patch` te gebruiken om bestanden gedeeltelijk te stagen (wordt in detail behandeld in Hoofdstuk 6). De snapshot aan de kop van het project is gelijk of je nu één commit doet of vijf, zolang alle wijzigingen op een gegeven moment maar toegevoegd zijn, dus probeer om het je mede-ontwikkelaars makkelijk te maken als ze je wijzigingen moeten bekijken. Deze aanpak maakt het ook makkelijker om één wijziging eruit te selecteren of terug te draaien, mocht dat later nodig zijn. Hoofdstuk 6 beschrijft een aantal handige Git trucs om geschiedenis te herschrijven en bestanden interactief te stagen - gebruik deze gereedschappen als hulp om een schone en begrijpelijke historie op te bouwen.
 
-Het laatste om in gedachten te houden is het commit bericht. Als je er een gewoonte van maakt om een goede kwaliteit commit berichten aan te maken, dan maakt dat het gebruik van en samenwerken in Git een stuk eenvoudiger. In het algemeen, zouden je berichten moeten beginnen met een enkele regel, die niet langer is dan 50 karakters en die de wijzigingen beknopt omschrijft, gevolgd door een lege regel en daarna een meer gedetailleerde uitleg. Het Git project vereist dat de meer gedetailleerde omschrijving ook je motivatie voor de verandering bevat, en de nieuwe implementatie tegen het oude gedrag afzet. Dit is een goede richtlijn om te volgen. Het is ook een goed idee om de gebiedende wijs te gebruiken in deze berichten. Met andere woorden, gebruik commando's. In plaats van "Ik heb testen toegevoegd voor" of "Testen toegevoegd voor" gebruik je "Voeg testen toe voor".
+Het laatste om in gedachten te houden is het commit bericht. Als je er een gewoonte van maakt om een goede kwaliteit commit berichten aan te maken, dan maakt dat het gebruik van en samenwerken in Git een stuk eenvoudiger. In het algemeen zouden je berichten moeten beginnen met een enkele regel die niet langer is dan 50 karakters en die de wijzigingen beknopt omschrijft, gevolgd door een lege regel en daarna een meer gedetailleerde uitleg. Het Git project vereist dat de meer gedetailleerde omschrijving ook je motivatie voor de verandering bevat, en de nieuwe implementatie tegen het oude gedrag afzet. Dit is een goede richtlijn om te volgen. Het is ook een goed idee om de gebiedende wijs te gebruiken in deze berichten. Met andere woorden, gebruik commando's. In plaats van "Ik heb testen toegevoegd voor" of "Testen toegevoegd voor" gebruik je "Voeg testen toe voor".
 Hier is een sjabloon dat origineel geschreven is door Tim Pope op tpope.net:
 
 	Kort (50 karakters of minder) samenvatting van wijzigingen
@@ -111,10 +146,10 @@ In de volgende voorbeelden, en verder door de rest van dit boek, zal ik omwille
 
 ### Besloten klein team ###
 
-De eenvoudigste opzet die je waarschijnlijk zult tegenkomen is een besloten project met één of twee andere ontwikkelaars. Met besloten bedoel ik gesloten broncode - zonder leestoegang voor de buitenwereld. Jij en de andere ontwikkelaars hebben allemaal push toegang op het repository.
+De eenvoudigste opzet die je waarschijnlijk zult tegenkomen is een besloten project met één of twee andere ontwikkelaars. Met besloten bedoel ik gesloten broncode - zonder leestoegang voor de buitenwereld. Jij en de andere ontwikkelaars hebben allemaal push toegang op de repository.
 
-In deze omgeving kun je een werkwijze aanhouden die vergelijkbaar is met wat je zou doen als je Subversion of een andere gecentraliseerd systeem zou gebruiken. Je hebt nog steeds de voordelen van zaken als offline committen en veel eenvoudiger branchen en mergen, maar de werkwijze kan erg vergelijkbaar zijn. Het grote verschil is dat het mergen aan de client-kant gebeurt tijdens het committen in plaats van aan de server-kant.
-Laten we eens kijken hoe het er uit zou kunnen zien als twee ontwikkelaars samen beginnen te werken met een gedeelde repository. De eerste ontwikkelaar, John, kloont de repository, maakt een wijziging, en commit lokaal. (Ik vervang de protocol berichten met `...` in deze voorbeelden om ze iets in te korten.)
+In deze omgeving kan je een workflow aanhouden die vergelijkbaar is met wat je zou doen als je Subversion of een andere gecentraliseerd systeem zou gebruiken. Je hebt nog steeds de voordelen van zaken als offline committen en veel eenvoudiger branchen en mergen, maar de workflow kan erg vergelijkbaar zijn. Het grootste verschil is dat het mergen aan de client-kant gebeurt tijdens het committen in plaats van aan de server-kant.
+Laten we eens kijken hoe het er uit zou kunnen zien als twee ontwikkelaars samen beginnen te werken met een gedeelde repository. De eerste ontwikkelaar, John, cloned de repository, maakt een wijziging, en commit lokaal. (Ik vervang de protocol berichten met `...` in deze voorbeelden om ze iets in te korten.)
 
 	# John's Machine
 	$ git clone john@githost:simplegit.git
@@ -126,7 +161,7 @@ Laten we eens kijken hoe het er uit zou kunnen zien als twee ontwikkelaars samen
 	[master 738ee87] removed invalid default value
 	 1 files changed, 1 insertions(+), 1 deletions(-)
 
-De tweede ontwikkelaar, Jessica, doet hetzelfde - kloont de repository en commit een wijziging:
+De tweede ontwikkelaar, Jessica, doet hetzelfde - cloned de repository en commit een wijziging:
 
 	# Jessica's Machine
 	$ git clone jessica@githost:simplegit.git
@@ -138,7 +173,7 @@ De tweede ontwikkelaar, Jessica, doet hetzelfde - kloont de repository en commit
 	[master fbff5bc] add reset task
 	 1 files changed, 1 insertions(+), 0 deletions(-)
 
-Nu pushed Jessica haar werk naar de server:
+Nu pusht Jessica haar werk naar de server:
 
 	# Jessica's Machine
 	$ git push origin master
@@ -154,7 +189,7 @@ John probeert ook zijn werk te pushen:
 	 ! [rejected]        master -> master (non-fast forward)
 	error: failed to push some refs to 'john@githost:simplegit.git'
 
-John mag niet pushen omdat Jessica in de tussentijd gepushed heeft. Dit is belangrijk om te begrijpen als je gewend bent aan Subversion, omdat het je zal opvallen dat de twee ontwikkelaars niet hetzelfde bestand hebben aangepast. Waar Subversion automatisch zo'n merge op de server doet, als verschillende bestanden zijn aangepast, moet je in Git de commits lokaal mergen. John moet Jessica's wijzigingen ophalen (fetch) en ze mergen voor hij mag pushen:
+John mag niet pushen omdat Jessica in de tussentijd gepusht heeft. Dit is belangrijk om te begrijpen als je gewend bent aan Subversion, omdat het je zal opvallen dat de twee ontwikkelaars niet hetzelfde bestand hebben aangepast. Waar Subversion automatisch zo'n merge op de server doet als verschillende bestanden zijn aangepast, moet je in Git de commits lokaal mergen. John moet Jessica's wijzigingen ophalen (fetch) en ze mergen voor hij mag pushen:
 
 	$ git fetch origin
 	...
@@ -166,7 +201,7 @@ Hierna ziet John's lokale repository er ongeveer uit zoals Figuur 5-4.
 Insert 18333fig0504.png
 Figuur 5-4. John's initiële repository.
 
-John heeft een referentie naar de wijzigingen die Jessica gepushed heeft, maar hij moet ze mergen met zijn eigen werk voordat hij het mag pushen:
+John heeft een referentie naar de wijzigingen die Jessica gepusht heeft, maar hij moet ze mergen met zijn eigen werk voordat hij het mag pushen:
 
 	$ git merge origin/master
 	Merge made by recursive.
@@ -176,9 +211,9 @@ John heeft een referentie naar de wijzigingen die Jessica gepushed heeft, maar h
 Het mergen gaat soepeltjes - de commit historie van John ziet er nu uit als Figuur 5-5.
 
 Insert 18333fig0505.png
-Figuur 5-5. John's repository na het mergen van origin/master.
+Figuur 5-5. John's repository na het mergen van `origin/master`.
 
-Nu kan John zijn code testen om er zeker van te zijn dat het nog steeds goed werkt, en dan kan hij zijn nieuwe gemergede werk pushen naar de server:
+Nu kan John zijn code testen om er zeker van te zijn dat alles nog steeds goed werkt, en dan kan hij zijn nieuwe gemergede werk pushen naar de server:
 
 	$ git push origin master
 	...
@@ -188,7 +223,7 @@ Nu kan John zijn code testen om er zeker van te zijn dat het nog steeds goed wer
 Tenslotte ziet John's commit historie eruit als Figuur 5-6.
 
 Insert 18333fig0506.png
-Figuur 5-6. John's historie na gepushed te hebben naar de origin van de server.
+Figuur 5-6. John's historie na gepusht te hebben naar de origin server.
 
 In de tussentijd heeft Jessica gewerkt op een topic branch. Ze heeft een topic branch genaamd `issue54` aangemaakt en daar drie commits op gedaan. Ze heeft John's wijzigingen nog niet opgehaald, dus haar commit historie ziet er uit als Figuur 5-7.
 
@@ -203,10 +238,10 @@ Jessica wil met John synchroniseren, dus ze haalt de wijzigingen op:
 	From jessica@githost:simplegit
 	   fbff5bc..72bbc59  master     -> origin/master
 
-Dit haalt het werk op dat John in de tussentijd gepushed heeft. Jessica's historie ziet er nu uit als Figuur 5-8.
+Dit haalt het werk op dat John in de tussentijd gepusht heeft. Jessica's historie ziet er nu uit als Figuur 5-8.
 
 Insert 18333fig0508.png
-Figuur 5-8. Jessica's historie na het ophalen van John's wijzigingen.
+Figuur 5-8. Jessica's historie na het fetchen van John's wijzigingen.
 
 Jessica denkt dat haar topic branch nu klaar is, maar ze wil weten wat ze in haar werk moet mergen zodat ze kan pushen. Ze voert `git log` uit om dat uit te zoeken:
 
@@ -223,7 +258,7 @@ Nu kan Jessica het werk van haar onderwerp mergen in haar `master` branch, John'
 	Switched to branch "master"
 	Your branch is behind 'origin/master' by 2 commits, and can be fast-forwarded.
 
-Ze kan of `origin/master` of `issue54` als eerste samenvoegen - ze zijn beide stroomopwaarts dus de volgorde maakt niet uit. Op het eind zou de snapshot gelijk moeten zijn ongeacht welke volgorde ze kiest; alleen de geschiedenis zal iets verschillen. Ze kiest ervoor om `issue54` eerst samen te voegen:
+Ze kan `origin/master` of `issue54` als eerste mergen - ze zijn beide stroomopwaarts dus de volgorde maakt niet uit. Uiteindelijk zou de snapshot gelijk moeten zijn ongeacht welke volgorde ze kiest; alleen de geschiedenis zal iets verschillen. Ze kiest ervoor om `issue54` eerst samen te voegen:
 
 	$ git merge issue54
 	Updating fbff5bc..4af4298
@@ -245,7 +280,7 @@ Alles merged netjes, en Jessica's historie ziet er uit als Figuur 5-9.
 Insert 18333fig0509.png
 Figuur 5-9. Jessica's historie na het mergen van John's wijzigingen.
 
-Nu is `origin/master` bereikbaar vanuit Jessica's `master` branch, dus ze zou in staat moeten zijn om succesvol te pushen (even aangenomen dat John in de tussentijd niets gepushed heeft):
+Nu is `origin/master` bereikbaar vanuit Jessica's `master` branch, dus ze zou in staat moeten zijn om succesvol te pushen (even aangenomen dat John in de tussentijd niets gepusht heeft):
 
 	$ git push origin master
 	...
@@ -257,18 +292,18 @@ Iedere ontwikkelaar heeft een paar keer gecommit en elkaars werk succesvol samen
 Insert 18333fig0510.png
 Figuur 5-10. Jessica's historie na alle wijzigingen teruggezet te hebben op de server.
 
-Dit is één van de eenvoudigste werkwijzen. Je werkt een tijdje, over het algemeen in een topic branch, en merged in je `master` branch als het klaar is om te worden geïntegreerd. Als je dat werk wilt delen, dan merge je het in je eigen `master` branch, en vervolgens fetch je `origin/master` en merge je deze als het gewijzigd is, en als laatste push je deze naar de `master` branch op de server. De algemene volgorde is zoiets als die getoond in Figuur 5-11.
+Dit is één van de eenvoudigste workflows. Je werkt een tijdje, over het algemeen in een topic branch, en merged dit in je `master` branch als het klaar is om te worden geïntegreerd. Als je dat werk wilt delen, dan merge je het in je eigen `master` branch, en vervolgens fetch je `origin/master` en merge je deze als het gewijzigd is, en als laatste push je deze naar de `master` branch op de server. De algemene volgorde is zoiets als die getoond in Figuur 5-11.
 
 Insert 18333fig0511.png
-Figuur 5-11. Algemene volgorde van gebeurtenissen voor een eenvoudige multi-ontwikkelaar Git werkwijze.
+Figuur 5-11. Algemene volgorde van gebeurtenissen voor een eenvoudige multi-ontwikkelaar Git workflow.
 
 ### Besloten aangestuurd team ###
 
-In het volgende scenario zul je kijken naar de rol van de bijdragers in een grotere besloten groep. Je zult leren hoe te werken in een omgeving waar kleine groepen samenwerken aan functies, waarna die team-gebaseerde bijdragen worden ge�ntegreerd door een andere partij.
+In het volgende scenario zul je kijken naar de rol van de bijdragers in een grotere besloten groep. Je zult leren hoe te werken in een omgeving waar kleine groepen samenwerken aan functies, waarna die team-gebaseerde bijdragen worden geïntegreerd door een andere partij.
 
-Stel dat John en Jessica samen werken aan een functie, terwijl Jessica en Josie aan een tweede aan het werken zijn. In dit geval gebruikt het bedrijf een integratie-manager achtige werkwijze, waarbij het werk van de individuele groepen alleen wordt geïntegreerd door bepaalde ontwikkelaars, en de `master` branch van het hoofd repo alleen kan worden vernieuwd door die ontwikkelaars. In dit scenario wordt al het werk gedaan in team-gebaseerde branches en later door de integrators samengevoegd.
+Stel dat John en Jessica samen werken aan een functie, terwijl Jessica en Josie aan een tweede aan het werken zijn. In dit geval gebruikt het bedrijf een integratie-manager achtige workflow, waarbij het werk van de individuele groepen alleen wordt geïntegreerd door bepaalde ontwikkelaars, en de `master` branch van het hoofd repo alleen kan worden vernieuwd door die ontwikkelaars. In dit scenario wordt al het werk gedaan in team-gebaseerde branches en later door de integrators samengevoegd.
 
-Laten we Jessica's werkwijze volgen terwijl ze aan haar twee functies werkt, in parallel met twee verschillende ontwikkelaars in deze omgeving. We nemen even aand dat ze haar repository al gekloond heeft, en dat ze besloten heeft als eerste te werken aan `featureA`. Ze maakt een nieuwe branch aan voor de functie en doet daar wat werk:
+Laten we Jessica's workflow volgen terwijl ze aan haar twee features werkt, in parallel met twee verschillende ontwikkelaars in deze omgeving. We nemen even aan dat ze haar repository al gecloned heeft, en dat ze besloten heeft als eerste te werken aan `featureA`. Ze maakt een nieuwe branch aan voor de functie en doet daar wat werk:
 
 	# Jessica's Machine
 	$ git checkout -b featureA
@@ -278,14 +313,14 @@ Laten we Jessica's werkwijze volgen terwijl ze aan haar twee functies werkt, in
 	[featureA 3300904] add limit to log function
 	 1 files changed, 1 insertions(+), 1 deletions(-)
 
-Op dit punt, moet ze haar werk delen met John, dus ze pushed haar commits naar de `featureA` branch op de server. Jessica heeft geen push toegang op de `master` branch - alleen de integratoren hebben dat - dus ze moet naar een andere branch pushen om samen te kunnen werken met John:
+Op dit punt, moet ze haar werk delen met John, dus ze pusht haar commits naar de `featureA` branch op de server. Jessica heeft geen push toegang op de `master` branch - alleen de integratoren hebben dat - dus ze moet naar een andere branch pushen om samen te kunnen werken met John:
 
 	$ git push origin featureA
 	...
 	To jessica@githost:simplegit.git
 	 * [new branch]      featureA -> featureA
 
-Jessica mailt John om hem te zeggen dat ze wat werk gepushed heeft in een branch genaamd `featureA` en dat hij er nu naar kan kijken. Terwijl ze op terugkoppeling van John wacht, besluit Jessica te beginnen met het werken aan `featureB` met Josie. Om te beginnen start ze een nieuwe functie branch, gebaseerd op de `master` branch van de server:
+Jessica mailt John om hem te zeggen dat ze wat werk gepusht heeft in een branch genaamd `featureA` en dat hij er nu naar kan kijken. Terwijl ze op terugkoppeling van John wacht, besluit Jessica te beginnen met het werken aan `featureB` met Josie. Om te beginnen start ze een nieuwe functie branch, gebaseerd op de `master` branch van de server:
 
 	# Jessica's Machine
 	$ git fetch origin
@@ -308,7 +343,7 @@ Jessica's repository ziet eruit als Figuur 5-12.
 Insert 18333fig0512.png
 Figuur 5-12. Jessica's initiële commit historie.
 
-Ze is klaar om haar werk te pushen, maar ze krijgt een mail van Josie dat een branch met wat initieel werk erin al gepushed is naar de server in de `featureBee` branch. Jessica moet die wijzigingen eerst mergen met die van haar voordat ze kan pushen naar de server. Ze kan dan Josie's wijzigingen ophalen met `git fetch`:
+Ze is klaar om haar werk te pushen, maar ze krijgt een mail van Josie dat een branch met wat initieel werk erin al gepusht is naar de server in de `featureBee` branch. Jessica moet die wijzigingen eerst mergen met die van haar voordat ze kan pushen naar de server. Ze kan dan Josie's wijzigingen ophalen met `git fetch`:
 
 	$ git fetch origin
 	...
@@ -323,7 +358,7 @@ Jessica kan dit nu mergen in het werk wat zij gedaan heeft met `git merge`:
 	 lib/simplegit.rb |    4 ++++
 	 1 files changed, 4 insertions(+), 0 deletions(-)
 
-Er is wel een klein probleempje - ze moet het gemergde werk in haar `featureB` branch naar de `featureBee` branch op de server zetten. Ze kan dat doen door de lokale branch te specificeren aan het `git push` commando, gevolgd door een dubbele punt (:), gevolgd door de remote branch:
+Er is wel een klein probleempje - ze moet het gemergde werk in haar `featureB` branch naar de `featureBee` branch op de server zetten. Ze kan dat doen door de lokale branch door te geven aan het `git push` commando, gevolgd door een dubbele punt (:), gevolgd door de remote branch:
 
 	$ git push origin featureB:featureBee
 	...
@@ -332,7 +367,7 @@ Er is wel een klein probleempje - ze moet het gemergde werk in haar `featureB` b
 
 Dit wordt een _refspec_ genoemd. Zie Hoofdstuk 9 voor een gedetailleerdere behandeling van Git refspecs en de verschillende dingen die je daarmee kan doen.
 
-Vervolgens mailt John naar Jessica om te zeggen dat hij wat wijzigingen naar de `featureA` branch gepushed heeft, en om haar te vragen die te verifiëren. Ze voert een `git fetch` uit om die wijzigingen op te halen:
+Vervolgens mailt John naar Jessica om te zeggen dat hij wat wijzigingen naar de `featureA` branch gepusht heeft, en om haar te vragen die te verifiëren. Ze voert een `git fetch` uit om die wijzigingen op te halen:
 
 	$ git fetch origin
 	...
@@ -358,7 +393,7 @@ Uiteindelijk merged ze John's werk in haar eigen `featureA` branch:
 	 lib/simplegit.rb |   10 +++++++++-
 	1 files changed, 9 insertions(+), 1 deletions(-)
 
-Jessica wil iets kleins wijzigen, dus doet ze nog een commit en pushed dit naar de server:
+Jessica wil iets kleins wijzigen, dus doet ze nog een commit en pusht dit naar de server:
 
 	$ git commit -am 'small tweak'
 	[featureA ed774b3] small tweak
@@ -371,24 +406,24 @@ Jessica wil iets kleins wijzigen, dus doet ze nog een commit en pushed dit naar
 Jessica's commit historie ziet er nu uit zoals Figuur 5-13.
 
 Insert 18333fig0513.png
-Figuur 5-13. Jessica's historie na het committen op een functie branch.
+Figuur 5-13. Jessica's historie na het committen op een feature branch.
 
-Jessica, Josie en John informeren de integrators nu dat de `featureA` en `featureBee` branches op de server klaar zijn voor integratie in de hoofdlijn. Nadat zij die branches in de hoofdlijn ge�ntegreerd hebben, zal een fetch de nieuwe merge commits ophalen, waardoor de commit historie er uit ziet zoals Figuur 5-14.
+Jessica, Josie en John informeren de integrators nu dat de `featureA` en `featureBee` branches op de server klaar zijn voor integratie in de hoofdlijn. Nadat zij die branches in de hoofdlijn geïntegreerd hebben, zal een fetch de nieuwe merge commits ophalen, waardoor de commit historie er uit ziet zoals Figuur 5-14.
 
 
 Insert 18333fig0514.png
-Figuur 5-14. Jessica's historie na het samenvoegen van allebei haar onderwerp branches.
+Figuur 5-14. Jessica's historie na het mergen van allebei haar onderwerp branches.
 
-Veel groepen schakelen om naar Git juist vanwege de mogelijkheid om meerdere teams in parallel te kunnen laten werken, waarbij de verschillende lijnen van werk laat in het proces gemerged worden. De mogelijkheid van kleinere subgroepen of een team om samen te werken via remote branches zonder het hele team erin te betrekken of te hinderen is een enorm voordeel van Git. De volgorde van de werkwijze die je hier zag is ongeveer zoals Figuur 5-15.
+Veel groepen schakelen om naar Git juist vanwege de mogelijkheid om meerdere teams in parallel te kunnen laten werken, waarbij de verschillende lijnen van werk laat in het proces gemerged worden. De mogelijkheid van kleinere subgroepen of een team om samen te werken via remote branches zonder het hele team erin te betrekken of te hinderen is een enorm voordeel van Git. De volgorde van de workflow die je hier zag is ongeveer zoals Figuur 5-15.
 
 Insert 18333fig0515.png
-Figuur 5-15. Eenvoudige volgorde in de werkwijze van dit aangestuurde team.
+Figuur 5-15. Eenvoudige volgorde in de workflow van dit aangestuurde team.
 
 ### Klein openbaar project ###
 
 Het bijdragen aan openbare, of publieke, projecten gaat op een iets andere manier. Omdat je niet de toestemming hebt om de branches van het project rechtstreeks te updaten, moet je het werk op een andere manier naar de beheerders krijgen. Dit eerste voorbeeld beschrijft het bijdragen via afsplitsen (forken) op Git hosts die het eenvoudig aanmaken van forks ondersteunen. De repo.or.cz en GitHub hosting sites ondersteunen dit beide, en veel project beheerders verwachten deze manier van bijdragen. De volgende paragraaf behandelt projecten die de voorkeur hebben om bijdragen in de vorm van patches via e-mail te ontvangen.
 
-Eerst zal je waarschijnlijk de hoofdrepository klonen, een topic branch maken voor de patch of reeks patches die je van plan bent bij te dragen, en je werk daarop doen. De te volgen stappen zien er zo uit:
+Eerst zal je waarschijnlijk de hoofdrepository clonen, een topic branch maken voor de patch of reeks patches die je van plan bent bij te dragen, en je werk daarop doen. De te volgen stappen zien er zo uit:
 
 	$ git clone (url)
 	$ cd project
@@ -404,13 +439,13 @@ Als je werk op de branch af is, en je klaar bent om het over te dragen aan de be
 
 	$ git remote add myfork (url)
 
-Je moet je werk daar naartoe pushen. Het is het makkelijkst om de remote branch waar je op zit te werken te pushen naar je repository, in plaats van het samenvoegen in je master branch en die te pushen. De reden hiervan is, dat als het werk niet wordt geaccepteerd of alleen ge-cherry picked (deels overgenomen), je jouw master branch niet hoeft terug te draaien. Als de beheerders je werk mergen, rebasen of cherry picken, dan krijg je het uiteindelijk toch binnen door hun repository te pullen:
+Je wilt je werk daar naartoe pushen. Het is het makkelijkst om de remote branch waar je op zit te werken te pushen naar je repository, in plaats van het te mergen in je master branch en die te pushen. De reden hiervan is, dat als het werk niet wordt geaccepteerd of alleen ge-cherry picked (deels overgenomen), je jouw master branch niet hoeft terug te draaien. Als de beheerders je werk mergen, rebasen of cherry picken, dan krijg je het uiteindelijk toch binnen door hun repository te pullen:
 
 	$ git push myfork featureA
 
-Als jouw werk gepushed is naar jouw fork, dan moet je de beheerder inlichten. Dit wordt een pull request (haal-binnen-verzoek) genoemd, en je kunt deze via de website genereren - GitHub heeft een "pull request" knop die de beheerder automatisch een bericht stuurt - of het `git request-pull` commando uitvoeren en de uitvoer handmatig naar de projectbeheerder mailen.
+Als jouw werk gepusht is naar jouw fork, dan moet je de beheerder inlichten. Dit wordt een pull request (haal-binnen-verzoek) genoemd, en je kunt deze via de website genereren - GitHub heeft een "pull request" knop die de beheerder automatisch een bericht stuurt - of het `git request-pull` commando uitvoeren en de uitvoer handmatig naar de projectbeheerder mailen.
 
-Het `request-pull` commando neemt de basis branch waarin je de topic branch gepulled wil hebben, en de URL van de Git repository waar je ze uit wil laten pullen, en maakt een samenvatting van alle wijzigingen die je gepulled wenst te hebben. Bijvoorbeeld, als Jessica John een pull request wil sturen, en ze heeft twee commits gedaan op de topic branch die ze zojuist gepushed heeft, dan kan ze dit uitvoeren:
+Het `request-pull` commando neemt de basis branch waarin je de topic branch gepulled wil hebben, en de URL van de Git repository waar je ze uit wil laten pullen, en maakt een samenvatting van alle wijzigingen die je gepulled wenst te hebben. Bijvoorbeeld, als Jessica John een pull request wil sturen, en ze heeft twee commits gedaan op de topic branch die ze zojuist gepusht heeft, dan kan ze dit uitvoeren:
 
 	$ git request-pull origin/master myfork
 	The following changes since commit 1edee6b1d61823a2de3b09c160d7080b8d1b3a40:
@@ -428,9 +463,9 @@ Het `request-pull` commando neemt de basis branch waarin je de topic branch gepu
 	 lib/simplegit.rb |   10 +++++++++-
 	 1 files changed, 9 insertions(+), 1 deletions(-)
 
-De uitvoer kan naar de beheerders gestuurd worden: het verteld ze waar het werk vanaf gebranched is, vat de commits samen en verteld waar vandaan ze dit werk kunnen pullen.
+De uitvoer kan naar de beheerders gestuurd worden: het vertelt ze waar het werk vanaf gebranched is, vat de commits samen en vertelt waar vandaan ze dit werk kunnen pullen.
 
-Bij een project waarvan je niet de beheerder bent, is het over het algemeen eenvoudiger om een branch zoals `master` altijd de `origin/master` te laten volgen, en je werk te doen in topic branches die je eenvoudig weg kunt gooien als ze geweigerd worden. Als je je werkthema's gescheiden houdt in topic branches maakt dat het ook eenvoudiger voor jou om je werk te rebasen als de punt van het hoofd repository in de tussentijd verschoven is en je commits niet langer netjes toegepast kunnen worden. Bijvoorbeeld, als je een tweede onderwerp wilt bijdragen aan een project, ga dan niet verder werken op de topic branch die je zojuist gepushed hebt - begin opnieuw vanaf de `master` branch van het hoofd repository:
+Bij een project waarvan je niet de beheerder bent, is het over het algemeen eenvoudiger om een branch zoals `master` altijd de `origin/master` te laten tracken, en je werk te doen in topic branches die je eenvoudig weg kunt gooien als ze geweigerd worden. Als je je werkthema's gescheiden houdt in topic branches maakt dat het ook eenvoudiger voor jou om je werk te rebasen als de punt van de hoofd-repository in de tussentijd verschoven is en je commits niet langer netjes toegepast kunnen worden. Bijvoorbeeld, als je een tweede onderwerp wilt bijdragen aan een project, ga dan niet verder werken op de topic branch die je zojuist gepusht hebt - begin opnieuw vanaf de `master` branch van het hoofd repository:
 
 	$ git checkout -b featureB origin/master
 	$ (work)
@@ -439,12 +474,12 @@ Bij een project waarvan je niet de beheerder bent, is het over het algemeen eenv
 	$ (email maintainer)
 	$ git fetch origin
 
-Nu zijn al je onderwerpen opgeslagen in een silo - vergelijkbaar met een patch reeks (queue) - die je kunt herschrijven, rebasen en wijzigen zonder dat de onderwerpen elkaar be�nvloeden of van elkaar afhankelijk zijn zoals in Figuur 5-16.
+Nu zijn al je onderwerpen opgeslagen in een silo - vergelijkbaar met een patch reeks (queue) - die je kunt herschrijven, rebasen en wijzigen zonder dat de onderwerpen elkaar beïnvloeden of van elkaar afhankelijk zijn zoals in Figuur 5-16.
 
 Insert 18333fig0516.png
 Figuur 5-16. Initiële commit historie met werk van featureB.
 
-Stel dat de project beheerder een verzameling andere patches binnengehaald heeft en jouw eerste branch geprobeerd heeft, maar dat die niet meer netjes merged. In dat geval kun je proberen die branch te rebasen op de punt van `origin/master`, de conflicten op te lossen voor de beheerder, en dan je wijzigingen opnieuw aanbieden:
+Stel dat de project-beheerder een verzameling andere patches binnengehaald heeft en jouw eerste branch geprobeerd heeft, maar dat die niet meer netjes merged. In dat geval kun je proberen die branch te rebasen op `origin/master`, de conflicten op te lossen voor de beheerder, en dan je wijzigingen opnieuw aanbieden:
 
 	$ git checkout featureA
 	$ git rebase origin/master
@@ -457,7 +492,7 @@ Figuur 5-17. Commit historie na werk van featureA.
 
 Omdat je de branch gerebased hebt, moet je de `-f` specificeren met je push commando om in staat te zijn de `featureA` branch op de server te vervangen met een commit die er geen afstammeling van is. Een alternatief zou zijn dit nieuwe werk naar een andere branch op de server te pushen (misschien `featureAv2` genaamd).
 
-Laten we eens kijken naar nog een mogelijk scenario: de beheerder heeft je werk bekeken in je tweede branch en vind het concept goed, maar zou willen dat je een implementatie detail verandert. Je moet deze gelegenheid meteen gebruiken om het werk te baseren op de huidige `master` branch van het project. Je begint een nieuwe branch gebaseerd op de huidige `origin/master` branch, squashed de `featureB` wijzigingen er naartoe, lost conflicten op, doet de implementatie wijziging en pushed deze terug als een nieuwe branch:
+Laten we eens kijken naar nog een mogelijk scenario: de beheerder heeft je werk bekeken in je tweede branch en vind het concept goed, maar zou willen dat je een implementatie detail verandert. Je moet deze gelegenheid meteen gebruiken om het werk te baseren op de huidige `master` branch van het project. Je begint een nieuwe branch gebaseerd op de huidige `origin/master` branch, squashed de `featureB` wijzigingen er naartoe, lost conflicten op, doet de implementatie wijziging en pusht deze terug als een nieuwe branch:
 
 	$ git checkout -b featureBv2 origin/master
 	$ git merge --no-commit --squash featureB
@@ -467,16 +502,16 @@ Laten we eens kijken naar nog een mogelijk scenario: de beheerder heeft je werk
 
 De `--squash` optie pakt al het werk op de gemergde branch en perst dat samen in één non-merge commit bovenop de branch waar je op zit. De `--no-commit` optie vertelt Git dat hij niet automatisch een commit moet doen. Dit stelt je in staat om alle wijzigingen van een andere branch te introduceren en dan meer wijzigingen te doen, alvorens de nieuwe commit te doen.
 
-Nu kun je de beheerder een bericht sturen dat je de gevraagde wijzigingen gemaakt hebt en dat ze die wijzigingen kunnen vinden in je `featureBv2` branch (zie Figuur 5-18).
+Je kunt de beheerder nu een bericht sturen dat je de gevraagde wijzigingen gemaakt hebt en dat ze die wijzigingen kunnen vinden in je `featureBv2` branch (zie Figuur 5-18).
 
 Insert 18333fig0518.png
 Figuur 5-18. Commit historie na het featureBv2 werk.
 
 ### Openbaar groot project ###
 
-Veel grote projecten hebben vastgestelde procedures voor het accepteren van patches - je zult de specifieke regels voor ieder project goed moeten bekijken, omdat ze verschillend zullen zijn. Veel grote projecten accepteren patches veelal via ontwikkelaar maillijsten, daarom zal ik zo'n voorbeeld nu laten zien.
+Veel grote projecten hebben vastgestelde procedures voor het accepteren van patches - je zult de specifieke regels voor ieder project goed moeten bekijken, omdat ze verschillend zullen zijn. Veel grote projecten accepteren patches veelal via ontwikkelaar-maillijsten, daarom zal ik zo'n voorbeeld nu laten zien.
 
-De werkwijze is vergelijkbaar met het vorige geval - je maakt topic branches voor iedere patch waar je aan werkt. Het verschil is hoe je die aanlevert bij het project. In plaats van het project te forken en naar je eigen schrijfbare versie te pushen, genereer je e-mail versies van iedere reeks commits en mailt die naar de ontwikkelaar maillijst:
+De workflow is vergelijkbaar met het vorige geval - je maakt topic branches voor iedere patch waar je aan werkt. Het verschil is hoe je die aanlevert bij het project. In plaats van het project te forken en naar je eigen schrijfbare versie te pushen, genereer je e-mail versies van iedere reeks commits en mailt die naar de ontwikkelaar-maillijst:
 
 	$ git checkout -b topicA
 	$ (work)
@@ -484,7 +519,7 @@ De werkwijze is vergelijkbaar met het vorige geval - je maakt topic branches voo
 	$ (work)
 	$ git commit
 
-Nu heb je twee commits die je wil sturen naar de maillijst. Je gebruikt `git format-patch` om de mbox-geformatteerde bestanden te genereren die je kunt mailen naar de lijst. Dit vormt iedere commit om naar een e-mail bericht met de eerste regel van het commit bericht als de onderwerp regel, en de rest van het bericht plus de patch die door de commit wordt ge�ntroduceerd als de inhoud. Het prettige hieraan is dat met het toepassen van een patch uit een mail die gegenereerd is met `format-patch` alle commit informatie blijft behouden. In de volgende paragraaf zal je hiervan meer zien, als je deze commits gaat toepassen:
+Nu heb je twee commits die je wil sturen naar de maillijst. Je gebruikt `git format-patch` om de mbox-geformatteerde bestanden te genereren die je kunt mailen naar de lijst. Dit vormt iedere commit om naar een e-mail bericht met de eerste regel van het commit bericht als het onderwerp, en de rest van het bericht plus de patch die door de commit wordt geïntroduceerd als de inhoud. Het prettige hieraan is dat met het toepassen van een patch uit een mail die gegenereerd is met `format-patch` alle commit informatie blijft behouden. In de volgende paragraaf zal je hiervan meer zien, als je deze commits gaat toepassen:
 
 	$ git format-patch -M origin/master
 	0001-add-limit-to-log-function.patch
@@ -520,9 +555,9 @@ Het `format-patch` commando drukt de namen af van de patch bestanden die het maa
 	--
 	1.6.2.rc1.20.g8c5b.dirty
 
-Je kunt deze patch bestanden ook aanpassen om meer informatie, die je niet in het commit bericht wil laten verschijnen, voor de maillijst toe te voegen . Als je tekst toevoegt tussen de `---` regel en het begin van de patch (de `lib/simplegit.rb` regel), dan kunnen ontwikkelaars dit lezen, maar tijdens het toepassen van de patch wordt dit weggelaten.
+Je kunt deze patch bestanden ook aanpassen om meer informatie, die je niet in het commit bericht wilt laten verschijnen, voor de maillijst toe te voegen . Als je tekst toevoegt tussen de `---` regel en het begin van de patch (de `lib/simplegit.rb` regel), dan kunnen ontwikkelaars dit lezen, maar tijdens het toepassen van de patch wordt dit weggelaten.
 
-Om dit te mailen naar een maillijst, kun je het bestand in je mail applicatie plakken of het sturen via een commandoregel programma. Het plakken van de tekst veroorzaakt vaak formaterings problemen, in het bijzonder bij "slimmere" clients die de newlines en andere witruimte niet juist behouden. Gelukkig levert Git een gereedschap die je helpt om juist geformatteerde patches via IMAP te versturen, wat het alweer een stuk makkelijker voor je maakt. Ik zal zal je laten zien hoe je een patch via Gmail stuurt, wat de mail applicatie is die ik toevallig gebruik. Je kunt gedetailleerde instructies voor een aantal mail programma's vinden aan het eind van het voornoemde `Documentation/SubmittingPatches` bestand in de Git broncode.
+Om dit te mailen naar een maillijst, kan je het bestand in je mail-applicatie plakken of het sturen via een commandoregel programma. Het plakken van de tekst veroorzaakt vaak formaterings problemen, in het bijzonder bij "slimmere" clients die de newlines en andere witruimte niet juist behouden. Gelukkig levert Git een gereedschap die je helpt om juist geformatteerde patches via IMAP te versturen, wat het alweer een stuk makkelijker voor je maakt. Ik zal zal je laten zien hoe je een patch via Gmail stuurt, wat de mail-applicatie is die ik toevallig gebruik. Je kunt gedetailleerde instructies voor een aantal mail programma's vinden aan het eind van het voornoemde `Documentation/SubmittingPatches` bestand in de Git broncode.
 
 Eerst moet je de imap sectie in je `~/.gitconfig` bestand instellen. Je kunt iedere waarde apart instellen met een serie `git config` commando's, of je kunt ze handmatig toevoegen, maar uiteindelijk moet je config bestand er ongeveer zo uitzien:
 
@@ -544,7 +579,7 @@ Als dat ingesteld is, kun je `git send-email` gebruiken om de patch reeks in de
 	sending 2 messages
 	100% (2/2) done
 
-Nu kan je naar die Drafts folder gaan, het To veld te wijzigen naar de maillijst waar je de patch naartoe stuurt en misschien de beheerder of verantwoordelijke voor dat deel in de CC zetten en dan versturen.
+Nu kan je naar jouw Drafts folder gaan, het To veld wijzigen naar de maillijst waar je de patch naartoe stuurt en misschien de beheerder of verantwoordelijke voor dat deel in de CC zetten en dan versturen.
 
 Je kunt de patches ook via een SMTP server sturen. Zoals eerder kan je elke waarde apart instellen met een serie `git config` commando's, of je kunt ze handmatig in de sendmail sectie in je `~/.gitconfig` bestand zetten:
 
@@ -554,7 +589,7 @@ Je kunt de patches ook via een SMTP server sturen. Zoals eerder kan je elke waar
 	  smtpuser = user@gmail.com
 	  smtpserverport = 587
 
-Als dit gebeurd is, kan je `git send-email` gebruiken om je patches te sturen:
+Als dit gedaan is, kan je `git send-email` gebruiken om je patches te sturen:
 
 	$ git send-email *.patch
 	0001-added-limit-to-log-function.patch
@@ -583,7 +618,7 @@ Dan spuuwt Git een bergje log-informatie uit voor elke patch die je stuurt, wat
 
 ### Samenvatting ###
 
-In dit hoofdstuk is een aantal veel voorkomende werkwijzen behandeld, die je kunt gebruiken om te kunnen werken in een aantal zeer verschillende typen Git projecten die je misschien zult tegenkomen, en een aantal nieuwe gereedschappen geïntroduceerd die je helpen om dit proces te beheren. Wat hierna volgt zal je laten zien hoe je aan de andere kant van de tafel werkt: een Git project beheren. Je zult leren hoe een welwillende dictator of integratie manager te zijn.
+In dit hoofdstuk is een aantal veel voorkomende workflows behandeld, die je kunt gebruiken om te kunnen werken in een aantal zeer verschillende typen Git projecten die je misschien zult tegenkomen. En er zijn een aantal nieuwe gereedschappen geïntroduceerd die je helpen om dit proces te beheren. Wat hierna volgt zal je laten zien hoe je aan de andere kant van de tafel werkt: een Git project beheren. Je zult leren hoe een welwillende dictator of integratie manager te zijn.
 
 ## Het beheren van een project ##
 
@@ -591,7 +626,7 @@ Naast weten hoe effectief bij te dragen aan een project, moet je waarschijnlijk
 
 ### Werken in topic branches ###
 
-Als je overweegt om nieuw werk te integreren, is het over het algemeen een goed idee om het uit te proberen in een topic branch - een tijdelijke branch, speciaal gemaakt om dat nieuwe werk uit te proberen. Op deze manier is het handig om een patch individueel te behandelen en het even opzij te zetten als het niet werkt, totdat je tijd hebt om er op terug te komen. Als je een eenvoudige branchnaam maakt, gebaseerd op het onderwerp van het werk dat je aan het proberen bent, bijvoorbeeld `ruby_client` of zoiets beschrijvends, dan is het makkelijk om te herinneren als je het voor een tijdje opzij moet leggen en er later op terug komt. De beheerder van het Git project heeft de neiging om deze branches ook van een naamsruimte (namespace) te voorzien - zoals `sc/ruby_client`, waarbij `sc` een afkorting is van de persoon die het werk heeft bijgedragen.
+Als je overweegt om nieuw werk te integreren, is het over het algemeen een goed idee om het uit te proberen in een topic branch - een tijdelijke branch, speciaal gemaakt om dat nieuwe werk uit te proberen. Op deze manier is het handig om een patch individueel te behandelen en het even opzij te zetten als het niet werkt, totdat je tijd hebt om er op terug te komen. Als je een eenvoudige branchnaam maakt, gebaseerd op het onderwerp van het werk dat je aan het proberen bent, bijvoorbeeld `ruby_client` of zoiets beschrijvends, dan is het makkelijk om te herinneren als je het voor een tijdje opzij legt en er later op terug komt. De beheerder van het Git project heeft de neiging om deze branches ook van een naamsruimte (namespace) te voorzien - zoals `sc/ruby_client`, waarbij `sc` een afkorting is van de persoon die het werk heeft bijgedragen.
 Zoals je je zult herinneren, kun je de branch gebaseerd op je master branch zo maken:
 
 	$ git branch sc/ruby_client master
@@ -604,7 +639,7 @@ Nu ben je klaar om het bijgedragen werk in deze topic branch toe te voegen, en t
 
 ### Patches uit e-mail toepassen ###
 
-Als je een patch per e-mail ontvangt, en je moet die integreren in je project, moet je de patch in je topic branch toepassen om het te evalueren. Er zijn twee manieren om een ge-mailde patch toe te passen: met `git apply` of met `git am`.
+Als je een patch per e-mail ontvangt, en je moet die integreren in je project, moet je de patch in je topic branch toepassen om het te evalueren. Er zijn twee manieren om een gemailde patch toe te passen: met `git apply` of met `git am`.
 
 #### Een patch toepassen met apply ####
 
@@ -612,7 +647,7 @@ Als je de patch ontvangen hebt van iemand die het gegenereerd heeft met de `git
 
 	$ git apply /tmp/patch-ruby-client.patch
 
-Dit wijzigt de bestanden in je werk directory. Het is vrijwel gelijk aan het uitvoeren van een `patch -p1` commando om de patch toe te passen, alhoewel het meer paranoïde is en minder "fuzzy matches" accepteert dan patch. Het handelt ook bestandstoevoegingen af, -verwijderingen, en hernoemingen als ze beschreven staan in het `git diff` formaat, wat `patch` niet doet. Als laatste volgt `git apply` een "pas alles toe of laat alles weg" model waarbij alles of niets wordt toegepast. Dit in tegenstelling tot `patch` die gedeeltelijke patches kan toepassen, waardoor je werk directory in een vreemde status achterblijft. Over het algemeen is `git apply` meer paranoïde dan `patch`. Het zal geen commit voor je aanmaken; na het uitvoeren moet je de geïntroduceerde wijzigingen handmatig stagen en committen.
+Dit wijzigt de bestanden in je werk directory. Het is vrijwel gelijk aan het uitvoeren van een `patch -p1` commando om de patch toe te passen, alhoewel het meer paranoïde is en minder "fuzzy matches" accepteert dan patch. Het handelt ook het toevoegen, verwijderen, en hernoemen van bestanden af als ze beschreven staan in het `git diff` formaat, wat `patch` niet doet. Als laatste volgt `git apply` een "pas alles toe of laat alles weg" model waarbij alles of niets wordt toegepast. Dit in tegenstelling tot `patch` die gedeeltelijke patches kan toepassen, waardoor je werkdirectory in een vreemde status achterblijft. Over het algemeen is `git apply` meer paranoïde dan `patch`. Het zal geen commit voor je aanmaken: na het uitvoeren moet je de geïntroduceerde wijzigingen handmatig stagen en committen.
 
 Je kunt ook git apply gebruiken om te zien of een patch netjes kan worden toepast voordat je het echt doet; je kunt `git apply --check` uitvoeren met de patch:
 
@@ -637,7 +672,7 @@ Om een patch gegenereerd met `format-patch` toe te passen, gebruik je `git am`.
 
 Dit is het begin van de uitvoer van het format-patch commando dat je gezien hebt in de vorige paragraaf. Dit is ook een geldig mbox e-mail formaat. Als iemand jou de patch correct gemaild heeft door gebruik te maken van git send-email en je downloadt dat in een mbox formaat, dan kan je het git am naar dat mbox bestand verwijzen, en het zal beginnen met alle patches die het tegenkomt toe te passen. Als je een mail client gebruikt die meerdere e-mails kan opslaan in mbox formaat, dan kun je hele reeksen patches in een bestand opslaan en dan git am gebruiken om ze één voor één toe te passen.
 
-Maar, als iemand een patch bestand heeft ge�pload die gegenereerd is met `format-patch` naar een ticket systeem of zoiets, kun je het bestand lokaal opslaan en dan dat opgeslagen bestand aan `git am` doorgeven om het toe te passen:
+Maar, als iemand een patch bestand heeft geüpload die gegenereerd is met `format-patch` naar een ticket systeem of zoiets, kun je het bestand lokaal opslaan en dan dat opgeslagen bestand aan `git am` doorgeven om het te applyen:
 
 	$ git am 0001-limit-log-function.patch
 	Applying: add limit to log function
@@ -655,7 +690,7 @@ Je ziet dat het netjes is toegepast, en automatisch een nieuwe commit voor je he
 
 	   Limit log functionality to the first 20
 
-De `Commit` informatie toont de persoon die de patch toepaste en de tijd waarop het is toegepast. De `Author` informatie de persoon die de patch oorspronkelijk gemaakt heeft en wanneer het gemaakt is.
+De `Commit` informatie toont de persoon die de patch toegepast heeft en de tijd waarop het is toegepast. De `Author` informatie de persoon die de patch oorspronkelijk gemaakt heeft en wanneer het gemaakt is.
 
 Maar het is mogelijk dat de patch niet netjes toegepast kan worden. Misschien is jouw hoofdbranch te ver afgeweken van de branch waarop de patch gebouwd is, of is de patch afhankelijk van een andere patch, die je nog niet hebt toegepast. In dat geval zal het `git am` proces falen en je vragen wat je wilt doen:
 
@@ -675,7 +710,7 @@ Dit commando zet conflict markeringen in alle bestanden waar het problemen mee h
 	$ git am --resolved
 	Applying: seeing if this helps the gem
 
-Als je wil dat Git iets meer intelligentie toepast om het conflict op te lossen, kun je een `-3` optie eraan meegeven, dit zorgt ervoor dat Git een driewegs-merge probeert. Deze optie staat standaard niet aan omdat het niet werkt als de commit waarvan de patch zegt dat het op gebaseerd is niet in je repository zit. Als je die commit wel hebt - als de patch gebaseerd was op een publieke commit - dan is de `-3` over het algemeen veel slimmer in het toepassen van een conflicterende patch:
+Als je wilt dat Git iets meer intelligentie toepast om het conflict op te lossen, kun je een `-3` optie eraan meegeven, dit zorgt ervoor dat Git een driewegs-merge probeert. Deze optie staat standaard niet aan omdat het niet werkt als de commit waarvan de patch zegt dat het op gebaseerd is niet in je repository zit. Als je die commit wel hebt - als de patch gebaseerd was op een publieke commit - dan is de `-3` over het algemeen veel slimmer in het toepassen van een conflicterende patch:
 
 	$ git am -3 0001-seeing-if-this-helps-the-gem.patch
 	Applying: seeing if this helps the gem
@@ -685,9 +720,9 @@ Als je wil dat Git iets meer intelligentie toepast om het conflict op te lossen,
 	Falling back to patching base and 3-way merge...
 	No changes -- Patch already applied.
 
-In dit geval, probeerde ik een patch toe te passen die ik al eerder toegepast had. Zonder de `-3` optie ziet het eruit als een conflict.
+In dit geval, probeerde ik een patch te applyen die ik al eerder toegepast had. Zonder de `-3` optie ziet het eruit als een conflict.
 
-Als je een aantal patches van een mbox toepast, kun je ook het `am` commando in een interactieve modus uitvoeren, wat bij iedere patch die het vind stopt en je vraagt of je het wilt toepassen:
+Als je een aantal patches van een mbox toepast, kun je ook het `am` commando in een interactieve modus uitvoeren, wat bij iedere patch die het vind stopt en je vraagt of je het wilt applyen:
 
 	$ git am -3 -i mbox
 	Commit Body is:
@@ -696,13 +731,13 @@ Als je een aantal patches van een mbox toepast, kun je ook het `am` commando in
 	--------------------------
 	Apply? [y]es/[n]o/[e]dit/[v]iew patch/[a]ccept all
 
-Dit is prettig als je een aantal patches bewaard hebt, omdat je de patch eerst kunt zien als je je niet kunt herinneren wat het is, of de patch niet wilt toepassen omdat je dat al eerder gedaan hebt.
+Dit is prettig als je een aantal patches bewaard hebt, omdat je de patch eerst kunt zien als je niet kunt herinneren wat het is, of de patch niet wilt toepassen omdat je dat al eerder gedaan hebt.
 
 Als alle patches voor je topic branch zijn toegepast en gecommit zijn op je branch, kan je besluiten of en hoe ze te integreren in een branch met een langere looptijd.
 
 ### Remote branches uitchecken ###
 
-Als je bijdrage van een Git gebruiker komt die zijn eigen repository opgezet heeft, een aantal patches daarin gepushed heeft, en jou de URL naar de repository gestuurd heeft en de naam van de remote branch waarin de wijzigingen zitten, kan je ze toevoegen als een remote en het mergen lokaal doen.
+Als je bijdrage van een Git gebruiker komt die zijn eigen repository opgezet heeft, een aantal patches daarin gepusht heeft, en jou de URL naar de repository gestuurd heeft en de naam van de remote branch waarin de wijzigingen zitten, kan je ze toevoegen als een remote en het mergen lokaal doen.
 
 Bijvoorbeeld, als Jessica je een e-mail stuurt waarin staat dat ze een prachtig mooie nieuwe feature in de `ruby-client` branch van haar repository heeft, kun je deze testen door de remote toe te voegen en die branch lokaal te bekijken:
 
@@ -716,7 +751,7 @@ Dit is meest practisch als je vaak met een persoon werkt. Als iemand een enkele
 
 Het andere voordeel van deze aanpak is dat je de historie van de commits ook krijgt. Alhoewel je misschien terechte merge problemen hebt, weet je op welk punt in de historie hun werk is gebaseerd; een echte drieweg merge is de standaard in plaats van een `-3` te moeten meegeven en hopen dat de patch gegenereerd was van een publieke commit waar je toegang toe hebt.
 
-Als je maar af en toe met een persoon werkt, maar toch op deze manier van hen wilt pullen, dan kun je de URL van de remote repository geven aan het `git pull` commando. Dit haalt eenmalig  op en bewaart de URL niet als een remote referentie:
+Als je maar af en toe met een persoon werkt, maar toch op deze manier van hen wilt pullen, dan kun je de URL van de remote repository geven aan het `git pull` commando. Dit doet een eenmalig pull en bewaart de URL niet als een remote referentie:
 
 	$ git pull git://github.com/onetimeguy/project.git
 	From git://github.com/onetimeguy/project
@@ -725,7 +760,7 @@ Als je maar af en toe met een persoon werkt, maar toch op deze manier van hen wi
 
 ### Bepalen wat geïntroduceerd wordt ###
 
-Je hebt een topic branch dat bijgedragen werk bevat. Nu kan je bepalen wat je er mee wilt doen. Deze paragraaf bekijkt een paar commando's nogmaals om te laten zien hoe je ze kunt gebruiken om precies te reviewen wat je zult introduceren als je dit merged in je hoofd branch.
+Je hebt een topic branch dat bijgedragen werk bevat. Nu kan je besluiten wat je er mee wilt doen. Deze paragraaf behandelt een paar commando's nogmaals om te laten zien hoe je ze kunt gebruiken om precies te reviewen wat je zult introduceren als je dit merged in je hoofd branch.
 
 Het is vaak handig om een review te krijgen van alle commits die in deze branch zitten, maar die niet in je master branch zitten. Je kunt commits weglaten die al in de master branch zitten door de `--not` optie mee te geven voor de branch naam. Bijvoorbeeld, als je bijdrager je twee patches stuurt, je hebt een branch genaamd `contrib` gemaakt en hebt die patches daar toegepast, dan kun je dit uitvoeren:
 
@@ -742,7 +777,7 @@ Het is vaak handig om een review te krijgen van alle commits die in deze branch
 
 	    updated the gemspec to hopefully work better
 
-Om te zien welke wijzigingen door iedere commit worden geïntroduceerd, onthoud dan dat je de `-p` optie kunt meegeven aan `git log` en dan zal het de diff weergeven die bij iedere commit wordt geïntroduceerd.
+Om te zien welke wijzigingen door een commit worden geïntroduceerd, onthoud dan dat je de `-p` optie kunt meegeven aan `git log` en dan zal het de geïntroduceerde diff erachter plakken bij iedere commit.
 
 Om een volledige diff te zien van wat zou gebeuren als je deze topic branch merged met een andere branch, zul je misschien een vreemde truc moeten toepassen om de juiste resultaten te krijgen. Je zult misschien denken om dit uit te voeren:
 
@@ -764,15 +799,15 @@ Maar, dat is niet handig, dus levert Git een andere verkorte manier om hetzelfde
 
 	$ git diff master...contrib
 
-Dit commando laat alleen het werk zien dat je huidige topic branch heeft ge�ntroduceerd sinds de gezamenlijke voorouder met master. Dat is een erg handige syntax om te onthouden.
+Dit commando laat alleen het werk zien dat je huidige topic branch heeft geïntroduceerd sinds de gezamenlijke voorouder met master. Dat is een erg handige syntax om te onthouden.
 
 ### Bijgedragen werk integreren ###
 
-Als al het werk in je onderwerp branch klaar is om te worden geïntegreerd in een hogere branch, dan is de vraag hoe het te doen. En daarbij, welke werkwijze wil je gebruiken om je project te beheren? Je hebt een aantal keuzes, dus ik zal er een paar behandelen.
+Als al het werk in je onderwerp branch klaar is om te worden geïntegreerd in een hogere branch, dan is de vraag hoe het te doen. En daarbij, welke workflow wil je gebruiken om je project te beheren? Je hebt een aantal keuzes, dus ik zal er een paar behandelen.
 
-#### Merge werkwijzen ####
+#### Mergende workflows ####
 
-Een eenvoudige werkwijze merged je werk in de `master` branch. In dit scenario, heb je een `master` branch die feitelijk de stabiele code bevat. Als je werk in een topic branch hebt waaraan je gewerkt hebt, of dat iemand anders heeft bijgedragen en wat je hebt nagekeken, dan merge je het in de master branch, verwijdert de topic branch en vervolgt het proces. Als we een repository hebben met werk in twee branches genaamd `ruby_client` en `php_client`, wat eruit ziet zoals Figuur 5-19 en mergen eerst `ruby_client` en daarna `php_client`, dan zal je historie er uit gaan zien zoals in Figuur 5-20.
+Een eenvoudige workflow merged je werk in de `master` branch. In dit scenario heb je een `master` branch die feitelijk de stabiele code bevat. Als je werk in een topic branch hebt waaraan je gewerkt hebt, of dat iemand anders heeft bijgedragen en je hebt dat nagekeken, dan merge je het in de master branch, verwijdert de topic branch en vervolgt het proces. Als we een repository hebben met werk in twee branches genaamd `ruby_client` en `php_client`, wat eruit ziet zoals Figuur 5-19 en mergen eerst `ruby_client` en daarna `php_client`, dan zal je historie er uit gaan zien zoals in Figuur 5-20.
 
 Insert 18333fig0519.png
 Figuur 5-19. Historie met een aantal topic branches.
@@ -780,9 +815,9 @@ Figuur 5-19. Historie met een aantal topic branches.
 Insert 18333fig0520.png
 Figuur 5-20. Na het mergen van een topic branch.
 
-Dat is waarschijnlijk de eenvoudigste werkwijze, maar het wordt problematisch als je werkt met grotere repositories of projecten.
+Dat is waarschijnlijk de eenvoudigste workflow, maar het wordt problematisch als je werkt met grotere repositories of projecten.
 
-Als je meer ontwikkelaars hebt of een groter project, dan zul je waarschijnlijk minstens een twee-fasen merge cyclus willen toepassen. In dat geval heb je twee langlopende branches, `master` en `develop`, waarbij je bepaalt dat `master` alleen vernieuwd wordt als een zeer stabiele release is gemaakt en alle nieuwe code geïntegreerd is in de `develop` branch. Je pushed beide branches op regelmatige basis naar de publieke repository. Iedere keer als je een nieuw topic branch hebt om te mergen (Figuur 5-21), merge je het in `develop` (Figuur 5-22). En als je een tag gemaakt heb van een release, doe je een fast-forward van `master` naar waar de nu stabiele `develop` branch is (Figuur 5-23).
+Als je meer ontwikkelaars hebt of een groter project, dan zul je waarschijnlijk minstens een twee-fasen merge cyclus willen toepassen. In dat geval heb je twee langlopende branches, `master` en `develop`, waarbij je bepaalt dat `master` alleen vernieuwd wordt als een zeer stabiele release is gemaakt en alle nieuwe code geïntegreerd is in de `develop` branch. Je pusht beide branches op regelmatige basis naar de publieke repository. Iedere keer als je een nieuw topic branch hebt om te mergen (Figuur 5-21), merge je het in `develop` (Figuur 5-22). En als je een tag gemaakt heb van een release, doe je een fast-forward van `master` naar waar de nu stabiele `develop` branch is (Figuur 5-23).
 
 Insert 18333fig0521.png
 Figuur 5-21. Voor een merge van een topic branch.
@@ -793,12 +828,12 @@ Figuur 5-22. Na een merge van een topic branch.
 Insert 18333fig0523.png
 Figuur 5-23. Na een release van een topic branch.
 
-Op deze manier, als mensen de repository van je project klonen, dan kunnen ze kiezen om master uit checken en daarmee de laatste stabiele versie te bouwen en die eenvoudig up-to-date kunnen houden, of ze kunnen develop uit checken waar het nieuwere materiaal in staat.
+Op deze manier, als mensen de repository van je project clonen, dan kunnen ze kiezen om master uit checken en daarmee de laatste stabiele versie te bouwen en die eenvoudig up-to-date te houden, of ze kunnen develop uit checken waar het nieuwere materiaal in staat.
 Je kunt dit concept ook verder doorvoeren, waarbij je een integratie branch hebt waar al het werk gemerged wordt. Als de codebasis op die branch stabiel is en de alle tests daar slagen, dan merge je het in een develop branch. Pas als het daar een periode stabiel is gebleken, dan fast-forward je de master branch.
 
-#### Werkwijzen met grote merges ####
+#### workflows met grote merges ####
 
-Het Git project heeft vier langlopende branches: `master`, `next`, en `pu` (proposed updates, voorgestelde vernieuwingen) voor nieuw spul, en `maint` voor onderhoudswerk. Als nieuw werk wordt geïntroduceerd door bijdragers, wordt het samengeraapt in topic branches in de repository van de beheerder op een manier die lijkt op wat ik omschreven heb (zie Figuur 5-24). Hier worden de topics geëvalueerd om te bepalen of ze veilig zijn en klaar voor verdere verwerking of dat ze nog wat werk nodig hebben. Als ze veilig zijn, worden ze in `next` gemerged, en wordt die branch gepushed zodat iedereen de geïntegreerde topics kan uitproberen.
+Het Git project heeft vier langlopende branches: `master`, `next`, en `pu` (proposed updates, voorgestelde vernieuwingen) voor nieuw spul, en `maint` voor onderhoudswerk (maintenance backports). Als nieuw werk wordt geïntroduceerd door bijdragers, wordt het samengeraapt in topic branches in de repository van de beheerder op een manier die lijkt op wat ik omschreven heb (zie Figuur 5-24). Hier worden de topics geëvalueerd om te bepalen of ze veilig zijn en klaar voor verdere verwerking of dat ze nog wat werk nodig hebben. Als ze veilig zijn, worden ze in `next` gemerged, en wordt die branch gepusht zodat iedereen de geïntegreerde topics kan uitproberen.
 
 Insert 18333fig0524.png
 Figuur 5-24. Een complexe serie van parallel bijgedragen topic branches beheren.
@@ -808,9 +843,9 @@ Als de topics nog werk nodig hebben, dan worden ze in plaats daarvan gemerged in
 Insert 18333fig0525.png
 Figuur 5-25. Bijgedragen topic branches mergen in langlopende integratie branches.
 
-Als een onderwerp branch uiteindelijk is gemerged in `master`, dan wordt het verwijderd van het repository. Het Git project heeft ook een `main` branch, die geforked is van de laatste release om teruggewerkte (backported) patches te leveren in het geval dat een onderhoudsrelease nodig is. Dus als je de Git repository kloont, dan heb je vier branches die je kunt uitchecken om het project in verschillende stadia van ontwikkeling te evalueren, afhankelijk van hoe nieuw je alles wilt hebben of hoe je wil bijdragen. En de beheerders hebben een gestructureerde werkwijze om ze te helpen nieuwe bijdragen aan de tand te voelen.
+Als een onderwerp branch uiteindelijk is gemerged in `master`, dan wordt het verwijderd van de repository. Het Git project heeft ook een `maint` branch, die geforked is van de laatste release om teruggewerkte (backported) patches te leveren in het geval dat een onderhoudsrelease nodig is. Dus als je de Git repository cloned, dan heb je vier branches die je kunt uitchecken om het project in verschillende stadia van ontwikkeling te evalueren, afhankelijk van hoe nieuw je alles wilt hebben of hoe je wil bijdragen. En de beheerders hebben een gestructureerde workflow om ze te helpen nieuwe bijdragen aan de tand te voelen.
 
-#### Rebasen en cherry pick werkwijzen ####
+#### Rebasende en cherry pick workflows ####
 
 Andere beheerders geven de voorkeur aan rebasen of bijgedragen werk te cherry picken naar hun master branch in plaats van ze erin te mergen, om een vrijwel lineaire historie te behouden. Als je werk in een topic branch hebt en hebt besloten dat je het wil integreren, dan ga je naar die branch en voert het rebase commando uit om de wijzigingen op je huidige master branch te baseren (of `develop`, enzovoorts). Als dat goed werkt, dan kun je de `master` branch fast-forwarden, en eindig je met een lineaire project historie.
 
@@ -835,14 +870,14 @@ Nu kun je de topic branch verwijderen en de commits die je niet wilde pullen weg
 
 ### Je releases taggen ###
 
-Als je hebt besloten om een release te maken, zul je waarschijnlijk een tag willen aanmaken zodat je die release op elk moment in de toekomst kunt namaken. Je kunt een nieuwe tag maken zoals ik heb beschreven in Hoofdstuk 2. Als je besluit om de tag als de beheerder te signeren, dan ziet het taggen er misschien zo uit:
+Als je hebt besloten om een release te maken, zul je waarschijnlijk een tag willen aanmaken zodat je die release op elk moment in de toekomst opnieuw kunt maken. Je kunt een nieuwe tag maken zoals ik heb beschreven in Hoofdstuk 2. Als je besluit om de tag als de beheerder te signeren, dan ziet het taggen er misschien zo uit:
 
 	$ git tag -s v1.5 -m 'my signed 1.5 tag'
 	You need a passphrase to unlock the secret key for
 	user: "Scott Chacon <schacon@gmail.com>"
 	1024-bit DSA key, ID F721C45A, created 2009-02-09
 
-Als je tags signeert, dan heb je misschien een problem om de publieke PGP sleutel, die gebruikt is om de tags te signeren, te distribueren. De beheerder van het Git project heeft dit probleem opgelost door hun publieke sleutel als een blob in het repository mee te nemen en een tag te maken die direct naar die inhoud wijst. Om dit te doen kun je uitvinden welke sleutel je wilt door `gpg --list-keys` uit te voeren:
+Als je tags signeert, dan heb je misschien een problem om de publieke PGP sleutel, die gebruikt is om de tags te signeren, te distribueren. De beheerder van het Git project heeft dit probleem opgelost door hun publieke sleutel als een blob in de repository mee te nemen en een tag te maken die direct naar die inhoud wijst. Om dit te doen kun je uitvinden welke sleutel je wilt door `gpg --list-keys` uit te voeren:
 
 	$ gpg --list-keys
 	/Users/schacon/.gnupg/pubring.gpg
@@ -856,7 +891,7 @@ Daarna kun je de sleutel direct in de Git database importeren, door het te expor
 	$ gpg -a --export F721C45A | git hash-object -w --stdin
 	659ef797d181633c87ec71ac3f9ba29fe5775b92
 
-Nu dat je de inhoud van je sleutel in Git hebt, kun je een tag aanmaken die direct daar naar wijst door de nieuw SHA-1 waarde die het `hash-object` commando je gaf te specificeren:
+Nu je de inhoud van je sleutel in Git hebt, kun je een tag aanmaken die direct daar naar wijst door de nieuw SHA-1 waarde die het `hash-object` commando je gaf te specificeren:
 
 	$ git tag -a maintainer-pgp-pub 659ef797d181633c87ec71ac3f9ba29fe5775b92
 
@@ -868,14 +903,14 @@ Ze kunnen die sleutel gebruiken om al je gesigneerde tags te verifiëren. Als je
 
 ### Een bouw nummer genereren ###
 
-Omdat Git geen monotone oplopende nummers heeft zoals 'v123' of iets gelijkwaardigs om bij iedere commit mee te worden genomen, en je een voor mensen leesbare naam wilt hebben bij een commit, kan je `git describe` uitvoeren op die commit. Git geeft je de naam van de dichtstbijzijnde tag met het aantal commits achter die tag en een gedeeltelijke SHA-1 waarde van de commit die je omschrijft:
+Omdat Git geen monotoon oplopende nummers heeft zoals 'v123' of iets gelijkwaardigs om bij iedere commit mee te worden genomen, en je een voor mensen leesbare naam wilt hebben bij een commit, kan je `git describe` uitvoeren op die commit. Git geeft je de naam van de dichtstbijzijnde tag met het aantal commits achter die tag en een gedeeltelijke SHA-1 waarde van de commit die je omschrijft:
 
 	$ git describe master
 	v1.6.2-rc1-20-g8c5b85c
 
-Op deze manier kun je een snapshot of "build" exporteren en het vernoemen naar iets dat begrijpelijk is voor mensen. Sterker nog: als je Git, gekloond van het Git repository, vanaf broncode bouwt geeft `git --version` je iets dat er zo uitziet. Als je een commit omschrijft die je direct getagged hebt, dan krijg je de tag naam.
+Op deze manier kun je een snapshot of "build" exporteren en het vernoemen naar iets dat begrijpelijk is voor mensen. Sterker nog: als je Git, gecloned van het Git repository, vanaf broncode gebouwd hebt geeft `git --version` je iets dat er zo uitziet. Als je een commit omschrijft die je direct getagged hebt, dan krijg je de tag naam.
 
-Het `git describe` commando geeft beschreven tags de voorkeur (tags gemaakt met de `-a` of `-s` vlag), dus release tags moeten op deze manier aangemaakt worden als je `git describe` gebruikt, om er zeker van te zijn dat de commit juist benoemd wordt als het omschreven wordt. Je kunt deze tekst ook gebruiken als het doel van een checkout of show commando, alhoewel het afhankelijk is van de verkorte SHA-1 waarde aan het einde, dus het zou niet eeuwig geldig kunnen zijn. Bijvoorbeeld, de Linux kernel sprong recentelijk van 8 naar 10 karakters om er zeker van de zijn dat de SHA-1 uniek zijn, oudere `git describe` commando's werden daardoor ongeldig.
+Het `git describe` commando geeft beschreven tags de voorkeur (tags gemaakt met de `-a` of `-s` vlag), dus release tags moeten op deze manier aangemaakt worden als je `git describe` gebruikt, om er zeker van te zijn dat de commit juist benoemd wordt als het omschreven wordt. Je kunt deze tekst ook gebruiken als het doel van een checkout of show commando, alhoewel het afhankelijk is van de verkorte SHA-1 waarde aan het einde, dus het zou niet eeuwig geldig kunnen zijn. Bijvoorbeeld, de Linux kernel sprong recentelijk van 8 naar 10 karakters om er zeker van de zijn dat de SHA-1 uniek zijn, oudere `git describe` commando uitvoernamen werden daardoor ongeldig.
 
 ### Een release voorbereiden ###
 
@@ -914,4 +949,4 @@ Je krijgt een opgeschoonde samenvatting van alle commits sinds v1.0.1, gegroepee
 
 ## Samenvatting ##
 
-Je zou je nu redelijk op je gemak moeten voelen om aan een project bij te dragen met Git, maar ook om je eigen project te beheren of de bijdragen van andere gebruikers te integreren. Gefeliciteerd, je bent nu een effectieve Git ontwikkelaar! In het volgende hoofdstuk zul je nog krachtigere tools en trucs leren voor het omgaan met complexe situaties, die je een echte Git meester zullen maken.
+Je zou je nu redelijk op je gemak moeten voelen om aan een project bij te dragen met Git, maar ook om je eigen project te beheren of de bijdragen van andere gebruikers te integreren. Gefeliciteerd, je bent nu een effectieve Git ontwikkelaar! In het volgende hoofdstuk vindt je nog krachtigere tools en tips om met complexe situaties om te gaan, waarmee je een echte Git meester zullen worden.

From c418e2ea78e789b5299a80352ad8fc2e1fc4461a Mon Sep 17 00:00:00 2001
From: Cor <git@cpt1.demon.nl>
Date: Tue, 18 Feb 2014 10:06:34 +0100
Subject: [PATCH 238/690] [nl] Chapter 03 - Review and retranslate where
 necessary

    Retranslated chapter 03, brought command output in line with en
    version.
    Also corrected English base document to bring text in line
    with actual output shown.
---
 en/03-git-branching/01-chapter3.markdown |   2 +-
 nl/03-git-branching/01-chapter3.markdown | 277 +++++++++++++----------
 2 files changed, 154 insertions(+), 125 deletions(-)

diff --git a/en/03-git-branching/01-chapter3.markdown b/en/03-git-branching/01-chapter3.markdown
index 6dd13bc27..0ab31e938 100644
--- a/en/03-git-branching/01-chapter3.markdown
+++ b/en/03-git-branching/01-chapter3.markdown
@@ -276,7 +276,7 @@ If you want to use a graphical tool to resolve these issues, you can run `git me
 	  {remote}: modified file
 	Hit return to start merge resolution tool (opendiff):
 
-If you want to use a merge tool other than the default (Git chose `opendiff` for me in this case because I ran the command on a Mac), you can see all the supported tools listed at the top after “merge tool candidates”. Type the name of the tool you’d rather use. In Chapter 7, we’ll discuss how you can change this default value for your environment.
+If you want to use a merge tool other than the default (Git chose `opendiff` for me in this case because I ran the command on a Mac), you can see all the supported tools listed at the top after “... one of the following tools:”. Type the name of the tool you’d rather use. In Chapter 7, we’ll discuss how you can change this default value for your environment.
 
 After you exit the merge tool, Git asks you if the merge was successful. If you tell the script that it was, it stages the file to mark it as resolved for you.
 
diff --git a/nl/03-git-branching/01-chapter3.markdown b/nl/03-git-branching/01-chapter3.markdown
index 7adb409d0..76fcb44e1 100644
--- a/nl/03-git-branching/01-chapter3.markdown
+++ b/nl/03-git-branching/01-chapter3.markdown
@@ -1,34 +1,56 @@
 <!-- Attentie heren en dames vertalers.
-
 Ik zou het volgende willen voorstellen:
-Er zijn bepaalde termen die voor de gemiddelde Nederlandse computer gebruiker veel beter klinken (of bekender voorkomen) als de orginele Engelse term. In het begin zullen deze termen niet vaak voorkomen, maar in de meer diepgaandere hoofdstukken komen deze steeds meer voor. Termen als "Committen", "Mergen" en "Applyen" klinken beter dan "Plegen" of "Toepassen", "Samenvoegen" en "Toepassen" (wat bovendien slecht valt te onderscheiden van de commit-toepassing). De mensen die dit boek lezen zijn, naar mijn bescheiden inschatting, al redelijk op de hoogte van versiebeheer en passen (zie ik in de praktijk) deze termen al toe. Een nieuwe terminologie introduceren lijkt me dan ook niet noodzakelijk.
-Verder blijven er altijd kreten over als "directory", wat vertaald zou kunnen worden als "map", maar bij het Engelse werkwoord to map, krijgen we dan weer het probleem: hoe dit weer te vertalen. Daarom zou ik willen voorstellen om deze basis-termen toch onvertaald te laten.
-Twijfelgevallen zullen altijd blijven zoals de term "file", daarvan wordt in de praktijk zowel de term file als bestand gebruikt. Ik denk dat we hier moeten kijken hoe het in de context past. 
-Maar ook een term als "tool" en (ik zit zelf nog op een mooie Nederlandse term te broeden) "plumbing", hierbij stel ik voor om eenmalig een Nederlandse vertaling te geven, tussen haakjes de Engelse term te geven en in het vervolg de Engelse term te gebruiken. Wederom is de context hier belangrijk.
-
-Let wel: ik wil niemand tot iets verplichten, maar ik denk dat we moeten streven naar een zo duidelijk mogelijke en best bij de praktijk aansluitende vertaling moeten proberen te maken.
+Er zijn bepaalde termen die voor de gemiddelde Nederlandse computer gebruiker 
+veel beter klinken (of bekender voorkomen) als de orginele Engelse term. In het
+begin zullen deze termen niet vaak voorkomen, maar in de meer diepgaandere 
+hoofdstukken komen deze steeds meer voor. Termen als "Committen", "Mergen" 
+en "Applyen" klinken beter dan "Plegen" of "Toepassen", "Samenvoegen" en 
+"Toepassen" (wat bovendien slecht valt te onderscheiden van de 
+commit-toepassing). De mensen die dit boek lezen zijn, naar mijn bescheiden 
+inschatting, al redelijk op de hoogte van versiebeheer en passen (zie ik in 
+de praktijk) deze termen al toe. Een nieuwe terminologie introduceren lijkt 
+me dan ook niet noodzakelijk.
+Verder blijven er altijd kreten over als "directory", wat vertaald zou kunnen 
+worden als "map", maar bij het Engelse werkwoord to map krijgen we dan weer het
+probleem: hoe dit weer te vertalen? Daarom zou ik willen voorstellen om deze 
+basis-termen toch onvertaald te laten.
+
+Twijfelgevallen zullen altijd blijven zoals de term "file", daarvan wordt in de
+praktijk zowel de term file als bestand gebruikt. Ik denk dat we hier moeten 
+kijken hoe het in de context past. 
+Maar ook een term als "tool" en (ik zit zelf nog op een mooie Nederlandse term
+te broeden) "plumbing", hierbij stel ik voor om eenmalig een Nederlandse 
+vertaling te geven, tussen haakjes de Engelse term te geven en in het vervolg
+de Engelse term te gebruiken. Wederom is de context hier belangrijk.
+
+Verder stel ik ook voor om de regels op https://onzetaal.nl/taaladvies zoveel
+mogelijk te volgen. Bijvoorbeeld de regels omtrent het spellen van Engelse 
+werkwoorden die in het Nederlands gebruikt worden.
+
+Let wel: ik wil niemand tot iets verplichten, maar ik denk dat we moeten 
+streven naar een zo duidelijk mogelijke en best bij de praktijk aansluitende
+vertaling moeten proberen te maken.
 
 Veel succes en plezier bij het vertalen...
-
 -->
 # Branchen in Git #
 
 Bijna elk versiebeheersysteem ondersteunt een bepaalde vorm van branchen. Branchen komt erop neer dat je een tak afsplitst van de hoofd ontwikkellijn en daar verder mee gaat werken zonder aan de hoofdlijn te komen. Bij veel VCS'en is dat nogal een duur proces, vaak wordt er een nieuwe kopie gemaakt van de directory waar je broncode in staan, wat lang kan duren voor grote projecten.
 
-Sommige mensen verwijzen naar het branch model in Git als de "killer eigenschap", en het onderscheidt Git zeker in de VCS gemeenschap. Waarom is het zo bijzonder? De manier waarop Git brancht is ongelooflijk lichtgewicht, waardoor branch operaties vrijwel instant zijn en het wisselen tussen de branches over het algemeen net zo snel. In tegenstelling to vele andere VCS's, moedigt Git juist een workflow aan waarbij vaak gebranched en gemerged wordt, zelfs meerdere keren per dag. Deze eigenschap begrijpen en de techniek beheersen geeft je een krachtig en uniek gereedschap en kan letterlijk de manier waarop je ontwikkelt veranderen.
+Sommige mensen verwijzen naar het branch model in Git als de "killer eigenschap", en het onderscheidt Git zeker in de VCS gemeenschap. Waarom is het zo bijzonder? De manier waarop Git brancht is ongelooflijk lichtgewicht, waardoor branch operaties vrijwel instant zijn en het wisselen tussen de branches over het algemeen net zo snel. In tegenstelling to vele andere VCS's, moedigt Git juist een workflow aan waarbij vaak gebrancht en gemerged wordt, zelfs meerdere keren per dag. Deze eigenschap begrijpen en de techniek beheersen geeft je een krachtig en uniek gereedschap en kan letterlijk de manier waarop je ontwikkelt veranderen.
 
-## Wat een branch is ##
+## Wat is een branch ##
 
 Om de manier waarop Git brancht echt te begrijpen, moeten we een stap terug doen en onderzoeken hoe Git zijn gegevens opslaat. Zoals je misschien herinnert van Hoofdstuk 1, slaat Git zijn gegevens niet op als een reeks van wijzigingen of delta's, maar in plaats daarvan als een serie snapshots.
 
 Als je in Git commit, dan slaat Git een commit object op dat een verwijzing bevat naar het snapshot van de inhoud die je gestaged hebt, de auteur en bericht metagegevens, en nul of meer verwijzingen naar de commit of commits die de directe ouders van deze commit waren: nul ouders voor de eerste commit, één ouder voor een normale commit, en meerdere ouders voor een commit die het resultaat is van een merge van twee of meer branches.
 
-Om dit te visualiseren, gaan we aannemen dat je een directory hebt met drie bestanden, en je staged en commit ze allemaal. Door de bestanden te stagen krijgen ze allemaal een checksum (de SHA-1 hash waar we het in Hoofdstuk 1 over hadden), bewaart die versie van het bestand in het Git repository (Git noemt ze blobs), en voegt die checksum toe aan de staging area:
+Om dit te visualiseren, gaan we aannemen dat je een directory hebt met drie bestanden, en je staged en commit ze allemaal. Je gaat de bestanden stagen waardoor ze allemaal een checksum krijgen (de SHA-1 hash waar we het in Hoofdstuk 1 over hadden), bewaart die versie van het bestand in het Git repository (Git noemt ze blobs), en voegt die checksum toe aan de staging area:
 
 	$ git add README test.rb LICENSE
 	$ git commit -m 'initial commit of my project'
 
-Als je de commit aanmaakt door `git commit` uit te voeren zal Git iedere project directory van een checksum voorzien en slaat ze als boomstructuur (`tree`) objecten in de Git repository op. Daarna creëert Git een `commit` object dat de metagegevens bevat en een verwijzing naar de hoofd project `tree`-object zodat Git deze snapshot kan opnieuw kan oproepen als dat nodig is.
+Als je de commit aanmaakt door `git commit` uit te voeren zal Git iedere directory in het project van een checksum voorzien en slaat ze als boomstructuur (`tree`) objecten in de Git repository op. Daarna creëert Git een `commit` object dat de metagegevens bevat en een verwijzing naar de hoofd `tree`-object van het project zodat Git deze snapshot kan opnieuw kan oproepen als dat nodig is.
 
 Je Git repository bevat nu vijf objecten: een blob voor de inhoud van ieder van de drie bestanden, een tree die de inhoud van de directory weergeeft en specificeert welke bestandsnamen opgeslagen zijn als welke blobs, en een commit met de verwijzing naar die hoofd-tree en alle commit metagegevens. Conceptueel zien de gegevens in je Git repository eruit zoals in Figuur 3-1.
 
@@ -45,7 +67,7 @@ Een branch in Git is simpelweg een lichtgewicht verplaatsbare verwijzing naar ee
 Insert 18333fig0303.png
 Figuur 3-3. Branch wijzend in de commit gegevens historie.
 
-Wat gebeurt er als je een nieuwe branch maakt? Door dat te doen wordt een nieuwe verwijzing voor jou aangemaakt die je dan kunt verplaatsen. Laten we zeggen dat je een nieuwe branch genaamd testing maakt. Je doet dit met het `git branch` commando:
+Wat gebeurt er als je een nieuwe branch maakt? Door dat te doen wordt een nieuwe verwijzing voor je aangemaakt die je dan kunt verplaatsen. Laten we zeggen dat je een nieuwe branch genaamd testing maakt. Je doet dit met het `git branch` commando:
 
 	$ git branch testing
 
@@ -54,7 +76,7 @@ Dit maakt een nieuwe verwijzing naar dezelfde commit waar je nu op zit (zie Figu
 Insert 18333fig0304.png
 Figuur 3-4. Meerdere branches wijzend naar de commit gegevens historie.
 
-Hoe weet Git op welke branch je nu zit? Het houdt een speciale verwijzing bij genaamd HEAD. Let op dat dit heel anders is dan het concept van HEAD in andere VCS's waar je misschien gewend aan bent, zoals Subversion of CVS. In Git is dit een verwijzing naar de lokale branch waar je nu op zit. In dit geval zit je nog steeds op master. Het git branch commando heeft alleen een nieuwe branch aangemaakt, we zijn nog niet overgeschakeld naar die branch (zie Figuur 3-5).
+Hoe weet Git op welke branch je nu zit? Het houdt een speciale verwijzing bij genaamd HEAD. Let op dat dit heel anders is dan het concept van HEAD in andere VCS's waar je misschien gewend aan bent, zoals Subversion of CVS. In Git is dit een verwijzing naar de lokale branch waar je nu op zit. In dit geval zit je nog steeds op master. Het git branch commando heeft alleen een nieuwe branch aangemaakt - we zijn nog niet overgeschakeld naar die branch (zie Figuur 3-5).
 
 Insert 18333fig0305.png
 Figuur 3-5. HEAD bestand wijzend naar de branch waar je op zit.
@@ -87,7 +109,7 @@ Figuur 3-8 toont het resultaat.
 Insert 18333fig0308.png
 Figuur 3-8. HEAD verschuift naar een andere branch bij een checkout.
 
-Dat commando heeft twee dingen gedaan. Het verplaatste de HEAD verwijzing terug naar de `master` branch, en het draaide de bestanden in je werkdirectory terug naar het snapshot waar die `master` naar wijst. Dit betekent ook dat de wijzigingen die je vanaf dit punt maakt uiteen zullen gaan lopen met een oudere versie van het project. In essentie betekent dat het werk dat je in je testing branch hebt gedaan tijdelijk wordt teruggedraaid, zodat je een andere richting op kunt gaan.
+Dat commando heeft twee dingen gedaan. Het verplaatste de HEAD verwijzing terug naar de `master` branch, en het draaide de bestanden in je werkdirectory terug naar de snapshot waar die `master` naar wijst. Dit betekent ook dat de wijzigingen die je vanaf dit punt maakt uiteen zullen gaan lopen met een oudere versie van het project. In essentie betekent het dat het werk dat je in je testing branch hebt gedaan tijdelijk wordt teruggedraaid, zodat je een andere richting op kunt gaan.
 
 Laten we een paar wijzigingen maken en nog eens committen:
 
@@ -101,7 +123,7 @@ Figuur 3-9. De branch histories zijn uiteen gaan lopen.
 
 Omdat een branch in Git in feite een eenvoudig bestand is dat de 40 karakter lange SHA-1 checksum van de commit bevat waar het naar wijst, zijn branches goedkoop om te maken en weer weg te gooien. Een nieuwe branch aanmaken is zo snel en eenvoudig als 41 bytes naar een bestand schrijven (40 karakters en een harde return).
 
-Dit is in scherp contrast met de wijze waarop de meeste VCS applicaties branchen, wat vaak het kopiëren van alle project bestanden naar een tweede map inhoudt. Dit kan enkele seconden of zelfs minuten duren, afhankelijk van de grootte van het project, daarentegen is het in Git altijd vrijwel meteen klaar. En omdat we de ouders opslaan terwijl we committen, wordt het vinden van een goed punt dat kan dienen als basis voor het mergen automatisch voor ons gedaan en is dat over het algemeen eenvoudig om te doen. Deze eigenschappen helpen ontwikkelaars aan te moedigen vaak branches aan te maken en te gebruiken.
+Dit is in scherp contrast met de wijze waarop de meeste VCS applicaties branchen, wat vaak het kopiëren van alle project bestanden naar een tweede map inhoudt. Dit kan enkele seconden of zelfs minuten duren, afhankelijk van de grootte van het project, daarentegen is het in Git altijd vrijwel meteen klaar. En omdat we de ouders opslaan terwijl we committen, wordt het vinden van een goed punt dat kan dienen als basis voor het mergen automatisch voor ons gedaan en is dat over het algemeen eenvoudig om te doen. Deze eigenschappen moedigen ontwikkelaars aan om vaak branches aan te maken en te gebruiken.
 
 Laten we eens kijken waarom je dat zou moeten doen.
 
@@ -122,15 +144,15 @@ Dan ontvang je een telefoontje dat je een ander probleem direct moet repareren.
 
 ### Eenvoudig branchen ###
 
-Als eerste, laten we zeggen dat je aan je project werkt en al een paar commits hebt (zie Figuur 3-10).
+Als eerste, laten we zeggen dat je aan je project werkt en al een paar commits hebt staan (zie Figuur 3-10).
 
 Insert 18333fig0310.png
 Figuur 3-10. Een korte en eenvoudige commit historie.
 
-Je hebt besloten dan je gaat werken aan probleem #53 in wat voor systeem je bedrijf ook gebruikt om problemen te registreren. Voor de duidelijkheid: Git is niet verbonden met een probleem beheersysteem in het bijzonder. En omdat probleem #53 een specifiek onderwerp is waar je aan gaat werken, maak je een nieuwe branch aan waarin je aan de slag gaat. Om een branch aan te maken en er meteen naartoe te schakelen, kun je het `git checkout` commando uitvoeren met de `-b` optie:
+Je hebt besloten dan je gaat werken aan probleem #53 in wat voor systeem je bedrijf ook gebruikt om problemen te registreren. Voor de duidelijkheid: Git is niet verbonden met een specifiek probleem beheersysteem. Omdat probleem #53 een onderwerp is waar je gericht aan gaat werken, maak je een nieuwe branch aan waarin je aan de slag gaat. Om een branch aan te maken en er meteen naartoe te schakelen, kun je het `git checkout` commando uitvoeren met de `-b` optie:
 
 	$ git checkout -b iss53
-	Switched to a new branch "iss53"
+	Switched to a new branch 'iss53'
 
 Dit is een afkorting voor:
 
@@ -152,7 +174,7 @@ Figuur 3-12. De iss53 branch is vooruit gegaan met je werk.
 
 Nu krijg je het telefoontje dan er een probleem is met de web site, en je moet het meteen repareren. Met Git hoef je de reparatie niet tegelijk uit te leveren met de `iss53` wijzigingen die je gemaakt hebt, en je hoeft ook niet veel moeite te doen om die wijzigingen terug te draaien voordat je kunt werken aan het toepassen van je reparatie in productie. Het enige wat je moet doen in terugschakelen naar je master branch.
 
-Maar voordat je dat doet, let op dat als je werk directory of staging area wijzigingen bevat die nog niet gecommit zijn en conflicteren met de branch die je gaat uitchecken, Git je niet laat om te schakelen. Het beste is  om een schone werk status te hebben als je tussen branches gaat schakelen. Er zijn manieren om hier mee om te gaan (te weten, stashen en commit ammending) die we later gaan behandelen. Voor nu heb je alle wijzigingen gecommit, zodat je terug kunt schakelen naar je master branch:
+Maar voordat je dat doet, merk op dat als je werk directory of staging area wijzigingen bevat die nog niet gecommit zijn en conflicteren met de branch die je gaat uitchecken, Git je niet laat om te schakelen. Het beste is om een schone werk status te hebben als je tussen branches gaat schakelen. Er zijn manieren om hier mee om te gaan (te weten, stashen en commit ammending) die we later gaan behandelen. Voor nu heb je alle wijzigingen gecommit, zodat je terug kunt schakelen naar je master branch:
 
 	$ git checkout master
 	Switched to branch "master"
@@ -162,32 +184,32 @@ Hierna, is je project werk directory precies zoals het was voordat je begon te w
 Vervolgens heb je een snelle reparatie (hotfix) te doen. Laten we een reparatie branch maken om op te werken totdat het af is (zie Figuur 3-13):
 
 	$ git checkout -b hotfix
-	Switched to a new branch "hotfix"
+	Switched to a new branch 'hotfix'
 	$ vim index.html
 	$ git commit -a -m 'fixed the broken email address'
-	[hotfix]: created 3a0874c: "fixed the broken email address"
-	 1 files changed, 0 insertions(+), 1 deletions(-)
+	[hotfix 3a0874c] fixed the broken email address
+	 1 files changed, 1 deletion(-)
 
 Insert 18333fig0313.png
-Figuur 3-13. snelle reparatie branch gebaseerd op de tip van je master branch.
+Figuur 3-13. snelle reparatie branch gebaseerd op de positie van je master branch.
 
 Je kunt je tests draaien, je erzelf van verzekeren dat de reparatie is wat je wil, en het mergen in je master branch en het naar productie uitrollen. Je doet dit met het `git merge` commando:
 
 	$ git checkout master
 	$ git merge hotfix
 	Updating f42c576..3a0874c
-	Fast forward
-	 README |    1 -
-	 1 files changed, 0 insertions(+), 1 deletions(-)
+	Fast-forward
+	 README | 1 -
+	 1 file changed, 1 deletion(-)
 
-Je zult de uitdrukking "Fast forward" zien in die merge. Omdat de commit van de branch waar je mee samenvoegde direct stroomopwaarts was van de commit waar je op zit, zal Git de verwijzing vooruit verplaatsen. Om het op een andere manier te zeggen, als je een commit probeert te mergen met een commit die bereikt kan worden door de historie van eerste commit te volgen, zal Git de dingen vereenvoudigen door de verwijzing vooruit te verplaatsen omdat er geen afwijkend werk is om rte mergen; dit wordt een "fast forward" genoemd.
+Je zult de uitdrukking "Fast forward" zien in die merge. Omdat de commit van de branch waar je mee mergede direct stroomopwaarts is van de commit waar je op zit, zal Git de verwijzing vooruit verplaatsen. Om het op een andere manier te zeggen, als je een commit probeert te mergen met een commit die bereikt kan worden door de historie van eerste commit te volgen, zal Git de dingen vereenvoudigen door de verwijzing vooruit te verplaatsen omdat er geen afwijkend werk is om rte mergen; dit wordt een "fast forward" genoemd.
 
 Je wijziging zit nu in het snapshot van de commit waar de `master` branch naar wijst, en je kunt je wijziging uitrollen (zie Figuur 3-14).
 
 Insert 18333fig0314.png
-Figuur 3-14. Je master branch wijst naar dezelfde plek als de snelle reparatie branch na de wijziging.
+Figuur 3-14. Je master branch wijst na de merge naar dezelfde plek als de hotfix branch.
 
-Nadat je super-belangrijke reparatie uitgerold is, ben je klaar om terug te schakelen naar het werk dat je deed voordat je onderbroken werd. Maar, eerst zul je de snelle reparatie branch verwijderen, omdat je die niet langer nodig hebt: de `master` branch wijst naar dezelfde plek. Je kunt het verwijderen met de `-d` optie op `git branch`:
+Nadat je super-belangrijke reparatie uitgerold is, ben je klaar om terug te schakelen naar het werk dat je deed voordat je onderbroken werd. Maar, eerst ga je de hotfix branch verwijderen, omdat je die niet langer nodig hebt - de `master` branch wijst naar dezelfde plek. Je kunt het verwijderen met de `-d` optie op `git branch`:
 
 	$ git branch -d hotfix
 	Deleted branch hotfix (3a0874c).
@@ -195,38 +217,39 @@ Nadat je super-belangrijke reparatie uitgerold is, ben je klaar om terug te scha
 Nu kun je terugschakelen naar je werk in uitvoering branch voor probleem #53 en doorgaan met daar aan te werken (zie Figuur 3-15):
 
 	$ git checkout iss53
-	Switched to branch "iss53"
+	Switched to branch 'iss53'
 	$ vim index.html
 	$ git commit -a -m 'finished the new footer [issue 53]'
-	[iss53]: created ad82d7a: "finished the new footer [issue 53]"
-	 1 files changed, 1 insertions(+), 0 deletions(-)
+	[iss53 ad82d7a] finished the new footer [issue 53]
+	 1 file changed, 1 insertion(+)
 
 Insert 18333fig0315.png
 Figuur 3-15. Je iss53 branch kan onafhankelijk vooruit bewegen.
 
-Het is nuttig om hier op te merken dat het werk dat je in je snelle reparatie branch gedaan hebt, niet in de bestanden van je `iss53` branch zit. Als je dat binnen moet halen, dan kun je de `master` branch in de `iss53` branch merge door `git merge master` uit te voeren, of je kunt wachten met die wijzigingen te integreren tot het moment dat je het besluit neemt de `iss53` branch in de `master` te trekken.
+Het is nuttig om hier op te merken dat het werk dat je in de hotfix branch gedaan hebt, niet in de bestanden van je `iss53` branch zit. Als je dat binnen moet halen, dan kun je de `master` branch in de `iss53` branch mergen door `git merge master` uit te voeren, of je kunt wachten met die wijzigingen te integreren tot het moment dat je het besluit neemt de `iss53` branch in de `master` te trekken.
 
 ### Eenvoudig samenvoegen ###
 
-Stel dat je besloten hebt dat je probleem #53 werk gereed is en klaar bent om het te mergen in de `master` branch. Om dat te doen, zul je je `iss53` branch mergen zoals je die snelle reparatie branch eerder hebt gemerged. Het enige dat je hoeft te doen is de branch uit te checken waar je in wenst te mergen en dan het `git merge` commando uit te voeren:
+Stel dat je besloten hebt dat je probleem #53 werk gereed is en klaar bent om het te mergen in de `master` branch. Om dat te doen, zul je de `iss53` branch mergen zoals je die hotfix branch eerder hebt gemerged. Het enige dat je hoeft te doen is de branch uit te checken waar je in wenst te mergen en dan het `git merge` commando uit te voeren:
 
 	$ git checkout master
 	$ git merge iss53
-	Merge made by recursive.
-	 README |    1 +
-	 1 files changed, 1 insertions(+), 0 deletions(-)
+	Auto-merging README
+	Merge made by the 'recursive' strategy.
+	 README | 1 +
+	 1 file changed, 1 insertion(+)
 
-Dit ziet er iets anders uit dan de snelle reparatie merge die je eerder deed. In dit geval is je ontwikkelingshistorie afgeweken van een eerder punt. Omdat de commit op de branch waar je op zit geen directe voorouder is van de branch waar je in merged, moet Git wat werk doen. In dit geval, doet Git een eenvoudige drieweg merge, gebruikmakend van de twee snapshots waarnaar gewezen wordt door de branch punten en de gezamenlijke voorouder van die twee. Figuur 3-16 markeert de drie snapshots die Git gebruikt om de merge te doen in dit geval te doen.
+Dit ziet er iets anders uit dan de `hotfix` merge die je eerder gedaan hebt. In dit geval is je ontwikkelhistorie afgeweken van een eerder punt. Omdat de commit op de branch waar je op zit geen directe voorouder is van de branch waar je in merged, moet Git wat werk doen. In dit geval, doet Git een eenvoudige drieweg merge, gebruikmakend van de twee snapshots waarnaar gewezen wordt door de uiteinden van de branch en de gezamenlijke voorouder van die twee. Figuur 3-16 markeert de drie snapshots die Git gebruikt om de merge te doen in dit geval te doen.
 
 Insert 18333fig0316.png
-Figuur 3-16. Git identificeert automatisch de beste gezamenlijke voorouder als basis voor het mergen van de branches.
+Figuur 3-16. Git identificeert automatisch de meest geschikte gezamenlijke voorouder als basis voor het mergen van de branches.
 
-In plaats van de branch verwijzing vooruit te verplaatsen, maakt Git een nieuw snapshot dat resulteert uit deze drieweg merge en maakt automatisch een nieuwe commit die daar naar wijst (zie Figuur 3-17). Dit wordt een mergecommit genoemd, en is bijzonder in die zin dat het meer dan één ouder heeft.
+In plaats van de branch verwijzing vooruit te verplaatsen, maakt Git een nieuw snapshot dat het resultaat is van deze drieweg merge en maakt automatisch een nieuwe commit die daar naar wijst (zie Figuur 3-17). Dit wordt een merge-commit genoemd, en is bijzonder in die zin dat het meer dan één ouder heeft.
 
-Het is belangrijk om erop te wijzen dat Git de beste gezamenlijke voorouder bepaalt om te gebruiken als merge basis; dit is anders dan CVS of Subversion (voor versie 1.5), waar het de ontwikkelaar die de merge doet degene is die de beste merge basis moest uitzoeken. Dit maakt het mergen in Git een behoorlijk stuk eenvoudiger dan in deze andere systemen.
+Het is belangrijk om erop te wijzen dat Git de meest geschikte gezamenlijke voorouder bepaalt om te gebruiken als merge basis; dit is anders dan CVS of Subversion (voor versie 1.5), waar het de ontwikkelaar die de merge doet ook degene is die de beste merge basis moest uitzoeken. Dit maakt het mergen in Git een behoorlijk stuk eenvoudiger in vergelijking met deze andere systemen.
 
 Insert 18333fig0317.png
-Figuur 3-17. Git maakt automatisch een nieuw commit object aan die het samengevoegde werk bevat.
+Figuur 3-17. Git maakt automatisch een nieuw commit object aan die het gemergede werk bevat.
 
 Nu dat je werk gemerged is, is er geen verdere noodzaak meer voor de `iss53` branch. Je kunt het verwijderen en daarna handmatig de ticket in het ticket-volg systeem sluiten:
 
@@ -234,34 +257,36 @@ Nu dat je werk gemerged is, is er geen verdere noodzaak meer voor de `iss53` bra
 
 ### Eenvoudige merge conflicten ###
 
-Af en toe verloopt dit proces niet soepel. Als je hetzelfde gedeelte van hetzelfde bestand anders hebt gewijzigd in twee branches die je merged, dan zal Git niet in staat zijn om ze netjes te mergen. Als je reparatie voor probleem #53 hetzelfde gedeelte van een bestand heeft gewijzigd als de snelle reparatie, dan krijg je een merge conflict dat er ongeveer zo uit ziet:
+Af en toe verloopt dit proces niet zo soepel. Als je hetzelfde gedeelte van hetzelfde bestand op een andere manier hebt gewijzigd in twee branches die je merged, dan zal Git niet in staat zijn om ze netjes te mergen. Als je reparatie voor probleem #53 hetzelfde gedeelte van een bestand heeft gewijzigd als de `hotfix`, dan krijg je een merge conflict dat er ongeveer zo uit ziet:
 
 	$ git merge iss53
 	Auto-merging index.html
 	CONFLICT (content): Merge conflict in index.html
 	Automatic merge failed; fix conflicts and then commit the result.
 
-Git heeft niet automatisch een nieuwe merge commit gemaakt. Het heeft het proces gestopt zodat jij het conflict kan oplossen. Als je wilt zien welke bestanden nog niet zijn gemerged op ieder punt na een merge conflict, dan kun je `git status` uitvoeren:
-
-	[master*]$ git status
-	index.html: needs merge
-	# On branch master
-	# Changes not staged for commit:
-	#   (use "git add <file>..." to update what will be committed)
-	#   (use "git checkout -- <file>..." to discard changes in working directory)
-	#
-	#	unmerged:   index.html
-	#
-
-Alles wat merge conflicten heeft en wat nog niet is opgelost wordt getoond als unmerged. Git voegt standaard conflict-oplossings markeringen toe aan de bestanden die conflicten hebben, zodat je ze handmatig kunt openen en die conflicten kunt oplossen. Je bestand bevat een gedeelte die er zo ongeveer uit ziet:
+Git heeft geen nieuwe merge commit gemaakt. Het heeft het proces gepauzeerd zolang jij het conflict aan het oplossen bent. Als je wilt zien welke bestanden nog niet zijn gemerged op enig punt na een merge conflict, dan kun je `git status` uitvoeren:
 
-	<<<<<<< HEAD:index.html
+	$ git status
+	On branch master
+	You have unmerged paths.
+	  (fix conflicts and run "git commit")
+	
+	Unmerged paths:
+	  (use "git add <file>..." to mark resolution)
+	
+	        both modified:      index.html
+	
+	no changes added to commit (use "git add" and/or "git commit -a")
+
+Alles wat merge conflicten heeft en wat nog niet is opgelost wordt getoond als unmerged. Git voegt standaard conflict-oplossings markeringen toe aan de bestanden die conflicten hebben, zodat je ze handmatig kunt openen en die conflicten kunt oplossen. Je bestand bevat een sectie die er zo ongeveer uit ziet:
+
+	<<<<<<< HEAD
 	<div id="footer">contact : email.support@github.com</div>
 	=======
 	<div id="footer">
 	  please contact us at support@github.com
 	</div>
-	>>>>>>> iss53:index.html
+	>>>>>>> iss53
 
 Dit betekent dat de versie in HEAD (jouw master branch, omdat dat degene was dat je uitgechecked had toen je het merge commando uitvoerde) is het bovenste gedeelte van dat blok (alles boven de `======`), terwijl de versie in je `iss53` branch eruit ziet zoals alles in het onderste gedeelte. Om het conflict op te lossen, moet je één van de twee gedeeltes kiezen of de inhoud zelf mergen. Je zou bijvoorbeeld dit conflict op kunnen lossen door het hele blok met dit te vervangen:
 
@@ -269,32 +294,36 @@ Dit betekent dat de versie in HEAD (jouw master branch, omdat dat degene was dat
 	please contact us at email.support@github.com
 	</div>
 
-Deze oplossing bevat een stukje uit beide secties, en ik heb de `<<<<<<<`, `=======`, en `>>>>>>>` regels volledig verwijderd. Nadat je elk van deze secties opgelost hebt in elk conflicterend bestand, voer dan `git add` uit voor ieder bestand om het als opgelost te markeren. Het bestand stagen markeert het als opgelost in Git.
+Deze oplossing bevat een stukje uit beide secties, en ik heb de `<<<<<<<`, `=======`, en `>>>>>>>` regels volledig verwijderd. Nadat je elk van deze secties opgelost hebt in elk conflicterend bestand, voer dan `git add` uit voor elk van die bestanden om het als opgelost te markeren. Het bestand stagen markeert het als opgelost in Git.
 Als je een grafische applicatie wil gebruiken om deze problemen op te lossen, kun je `git mergetool` uitvoeren, wat een toepasselijk grafische merge applicatie opstart dat je door de conflicten heen leidt:
 
 	$ git mergetool
-	merge tool candidates: kdiff3 tkdiff xxdiff meld gvimdiff opendiff emerge vimdiff
-	Merging the files: index.html
+
+	This message is displayed because 'merge.tool' is not configured.
+	See 'git mergetool --tool-help' or 'git help config' for more details.
+	'git mergetool' will now attempt to use one of the following tools:
+	opendiff kdiff3 tkdiff xxdiff meld tortoisemerge gvimdiff diffuse diffmerge ecmerge p4merge araxis bc3 codecompare vimdiff emerge
+	Merging:
+	index.html
 
 	Normal merge conflict for 'index.html':
-	  {local}: modified
-	  {remote}: modified
+	  {local}: modified file
+	  {remote}: modified file
 	Hit return to start merge resolution tool (opendiff):
 
-Als je een ander merge applicatie wil gebruiken dan de standaard (Git koos `opendiff` voor me in dit geval, omdat ik het commando uitvoerde op een Mac), dan kun je alle ondersteunde applicaties opgenoemd zien na "merge tool candidates". Type de naam van de applicatie die je liever gebruikt. In Hoofdstuk 7 zullen we bespreken hoe je deze standaard waarde voor jouw omgeving kunt wijzigen.
+Als je een andere dan de standaard merge tool wilt gebruiken (Git koos `opendiff` voor me in dit geval, omdat ik het commando uitvoerde op een Mac), dan kun je alle ondersteunde applicaties opgenoemd zien na "... one of the following tools:". Type de naam van de applicatie die je liever gebruikt. In Hoofdstuk 7 zullen we bespreken hoe je deze standaard waarde voor jouw omgeving kunt wijzigen.
 
 Nadat je de merge applicatie afsluit, vraagt Git je of de merge succesvol was. Als je het script vertelt dat dit het geval is, dan staged dit script het bestand voor je om het als opgelost te markeren.
 
 Je kunt `git status` nogmaals uitvoeren om er zeker van te zijn dat alle conflicten opgelost zijn:
 
 	$ git status
-	# On branch master
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#	modified:   index.html
-	#
-
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        modified:   index.html
+	
 Als je het daar mee eens bent, en je gecontroleerd hebt dat alles waar conflicten in zat gestaged is, dan kun je `git commit` typen om de merge commit af te ronden. Het commit bericht ziet er standaard ongeveer zo uit:
 
 	Merge branch 'iss53'
@@ -308,7 +337,7 @@ Als je het daar mee eens bent, en je gecontroleerd hebt dat alles waar conflicte
 	# and try again.
 	#
 
-Je kunt dat bericht aanpassen met details over hoe je het conflict opgelost hebt, als je denkt dat dat behulpzaam zal zijn voor anderen die in de toekomst naar deze samenvoeging kijken; waarom je heb je gedaan wat je gedaan hebt, als dat niet vanzelfsprekend is.
+Je kunt dat bericht aanpassen met details over hoe je het conflict opgelost hebt, als je denkt dat dat behulpzaam zal zijn voor anderen die in de toekomst naar deze merge kijken - waarom je hebt gedaan wat je gedaan hebt, als dat niet vanzelfsprekend is.
 
 ## Branch beheer ##
 
@@ -328,14 +357,14 @@ Merk op dat het `*` karakter vooraf gaat aan de `master` branch: het geeft de br
 	* master  7a98805 Merge branch 'iss53'
 	  testing 782fd34 add scott to the author list in the readmes
 
-Een andere handige optie om uit te vogelen in welke staat je branches zijn, is om deze lijst te filteren op branches die je wel of nog niet gemerged hebt in de branch waar je nu op zit. De handige `--merged` en `--no-merged` opties zijn voor dit doel beschikbaar in Git. Om te zien welke branches al gemerged zijn in de branch waar je nu op zit, kun je `git branch --merged` uitvoeren:
+Een andere handige optie om uit te vinden in welke staat je branches zijn, is om deze lijst te filteren op branches die je wel of nog niet gemerged hebt in de branch waar je nu op zit. De handige `--merged` en `--no-merged` opties zijn voor dit doel beschikbaar in Git. Om te zien welke branches al gemerged zijn in de branch waar je nu op zit, kun je `git branch --merged` uitvoeren:
 
 
 	$ git branch --merged
 	  iss53
 	* master
 
-Omdat je `iss53` al eerder hebt gemerged, zie je het terug in je lijst. Branches op deze lijst zonder de `*` ervoor zijn over het algemeen zonder problemen te verwijderen met `git branch -d`: je hebt hun werk al in een andere branch zitten, dus je zult niets kwijtraken.
+Omdat je `iss53` al eerder hebt gemerged, zie je het terug in je lijst. Branches op deze lijst zonder de `*` ervoor zijn over het algemeen zonder problemen te verwijderen met `git branch -d`; je hebt hun werk al in een andere branch zitten, dus je zult niets kwijtraken.
 
 Om alle branches te zien die werk bevatten dat je nog niet gemerged hebt, kun je `git branch --no-merged` uitvoeren:
 
@@ -352,15 +381,15 @@ Als je de branch echt wilt verwijderen en dat werk wilt verliezen, dan kun je he
 
 ## Branch workflows ##
 
-Nu dat je de basis van het branchen en samenvoegen onder de knie hebt, wat kan of zou je met ze kunnen doen? In deze paragraaf gaan we een aantal veel voorkomende workflows die deze lichtgewicht branches mogelijk maken behandelen, zodat je kunt besluiten of je ze wilt toepassen in jouw ontwikkel cyclus.
+Nu je de basis van het branchen en mergen onder de knie hebt, wat kan of zou je daarmee kunnen doen? In deze paragraaf gaan we een aantal veel voorkomende workflows die deze lichtgewicht branches mogelijk maken behandelen, zodat je kunt besluiten of je ze wilt toepassen in je eigen ontwikkel cyclus.
 
 ### Lang-lopende branches ###
 
-Omdat Git gebruik maakt van een eenvoudige drieweg merge, is het meerdere keren mergen vanuit een branch in een andere gedurende een langere periode over het algemeen eenvoudig te doen. Dit betekent dat je meerdere branches kunt hebben, die altijd open staan en die je voor verschillende delen van je ontwikkel cyclus gebruikt; je kunt regelmatig een aantal mergen in andere.
+Omdat Git gebruik maakt van een eenvoudige drieweg merge, is het meerdere keren mergen vanuit een branch in een andere gedurende een langere periode over het algemeen eenvoudig te doen. Dit betekent dat je meerdere branches kunt hebben, die altijd open staan en die je voor verschillende delen van je ontwikkel cyclus gebruikt; je kunt regelmatig vanuit een aantal mergen in andere.
 
-Veel Git ontwikkelaars hebben een workflow die deze aanpak omarmt, zoals het hebben van alleen volledig stabiele code in hun `master` branch — waarschijnlijk alleen code die is of zal worden vrijgegeven. Ze hebben een andere parallelle branch "develop" of "next" genaamd waarop ze werken of die ze gebruiken om stabiliteit te testen — het is niet noodzakelijk altijd stabiel, maar zodra het in een stabiele status verkeert, kan het worden gemerged in `master`. Het wordt gebruikt om topic branches (branches met een korte levensduur, zoals jou eerdere `iss53` branch) te pullen zodra die klaar zijn, om er zich ervan te verzekeren dat alle testen slagen en er geen fouten worden geïntroduceerd.
+Veel Git ontwikkelaars hebben een workflow die deze aanpak omarmt, zoals het hebben van alleen volledig stabiele code in hun `master` branch — mogelijk alleen code die is of zal worden vrijgegeven. Ze hebben een andere parallelle branch "develop" of "next" genaamd waarop ze werken of die ze gebruiken om stabiliteit te testen — het is niet noodzakelijkerwijs altijd stabiel, maar zodra het in een stabiele status verkeert, kan het worden gemerged in `master`. Deze wordt gebruikt om topic branches (branches met een korte levensduur, zoals jou eerdere `iss53` branch) te pullen zodra die klaar zijn, om er zich ervan te overtuigen dat alle testen slagen en er geen fouten worden geïntroduceerd.
 
-In essentie praten we over verwijzingen die zich verplaatsen over de lijn van de commits die je maakt. De stabiele branches zijn verder naar achter in je commit historie, en de splinternieuwe branches zijn verder naar voren in de historie (zie Figuur 3-18).
+Feitelijk praten we over verwijzingen die worden verplaatst over de lijn van de commits die je maakt. De stabiele branches zijn verder naar achterop in je commit historie, en de splinternieuwe branches zijn verder naar voren in de historie (zie Figuur 3-18).
 
 Insert 18333fig0318.png
 Figuur 3-18. Meer stabiele branches zijn over het algemeen verder naar achter in de commit historie.
@@ -370,44 +399,44 @@ Ze zijn misschien makkelijker voor te stellen als werk silo's, waar sets van com
 Insert 18333fig0319.png
 Figuur 3-19. Het kan handig zijn om je branches voor te stellen als silo's.
 
-Je kunt dit blijven doen voor elk niveaus van toegenomen stabiliteit. Sommige grotere projecten hebben ook een `proposed` of `pu` (proposed updates) branch die branches geïntegreerd heeft die wellicht nog niet klaar zijn om in de `next` of `master` branch te gaan. Het idee erachter is dat de branches op verschillende niveaus van stabiliteit zitten. Zodra ze een meer stabiel niveau bereiken, worden ze in de branch boven hun gemerged.
-Nogmaals, het hebben van langlopende branches is niet noodzakelijk maar het helpt vaak wel, in het bijzonder als je te maken hebt met zeer grote of complexe projecten.
+Je kunt dit blijven doen voor elk niveau van stabiliteit. Sommige grotere projecten hebben ook een `proposed` of `pu` (proposed updates) branch die branches geïntegreerd heeft die wellicht nog niet klaar zijn om in de `next` of `master` branch te gaan. Het idee erachter is dat de branches op verschillende niveaus van stabiliteit zitten. Zodra ze een meer stabiel niveau bereiken, worden ze in de branch boven hen gemerged.
+Nogmaals, het hebben van langlopende branches is niet noodzakelijk, maar het helpt vaak wel; in het bijzonder als je te maken hebt met zeer grote of complexe projecten.
 
 ### Topic branches ###
 
 Topic branches zijn nuttig in projecten van elke grootte. Een topic branch is een kortlopende branch die je maakt en gebruikt om een specifieke functie te realiseren of daaraan gerelateerd werk te doen. Dit is iets wat je waarschijnlijk nooit eerder met een VCS gedaan hebt, omdat het over het algemeen te duur is om branches aan te maken en te mergen. Maar in Git is het niet ongebruikelijk om meerdere keren per dag branches aan te maken, daarop te werken, en ze te verwijderen.
 
-Je zag dit in de vorige paragraaf met de `iss53` en `hotfix` branches die je gemaakt had. Je hebt een aantal commits op ze gedaan en ze meteen verwijderd zodra je ze gemerged had in je hoofd branch. Deze techniek staat je toe om snel en volledig van context te veranderen — omdat je werk is onderverdeeld in silo's waar alle wijzigingen te maken hebben met het onderwerp van die branch, is het makkelijker te zien wat er is gebeurd tijdens een code review en dergelijke. Je kunt de wijzigingen daar minuten, dagen of maanden bewaren, en ze mergen als ze er klaar voor zijn, ongeacht de volgorde waarin ze gemaakt of aan gewerkt zijn.
+Je zag dit in de vorige paragraaf met de `iss53` en `hotfix` branches die je gemaakt had. Je hebt een aantal commits op ze gedaan en ze meteen verwijderd nadat je ze gemerged had in je hoofd branch. Deze techniek stelt je in staat om snel en volledig van context te veranderen — omdat je werk is onderverdeeld in silo's waar alle wijzigingen in die branch te maken hebben met dat onderwerp, is het makkelijker te zien wat er is gebeurd tijdens een code review en dergelijke. Je kunt de wijzigingen daar minuten-, dagen- of maandenlang bewaren, en ze mergen als ze er klaar voor zijn, ongeacht de volgorde waarin ze gemaakt of aan gewerkt zijn.
 
-Neem als voorbeeld een situatie waarbij wat werk gedaan wordt (op `master`), er wordt een branche gemaakt voor een probleem (`iss91`) daar wordt wat aan gewerkt, er wordt een tweede branch gemaakt om op een andere manier te proberen hetzelfde op te lossen (`iss91v2`); even teruggaan naar de master branch om daar een tijdje te werken, en dan vanaf daar branchen om wat werk te doen waarvan je niet zeker weet of het wel een goed idee is (`dumbidea` branch). Je commit historie zal er uit zien als Figuur 3-20.
+Neem als voorbeeld een situatie waarbij wat werk gedaan wordt (op `master`), er wordt een branche gemaakt voor een probleem (`iss91`) en daar wordt wat aan gewerkt, er wordt een tweede branch gemaakt om op een andere manier te proberen hetzelfde op te lossen (`iss91v2`); weer even wordt teruggegaan naar de master branch om daar een tijdje te werken, en dan vanaf daar wordt gebrancht om wat werk te doen waarvan je niet zeker weet of het wel zo'n slim idee is (`dumbidea` branch). Je commit historie zal er uit zien als Figuur 3-20.
 
 Insert 18333fig0320.png
 Figuur 3-20. Je commit geschiedenis met meerdere topic branches.
 
-Laten we zeggen dat je besluit dat je de tweede oplossing voor je probleem het beste vindt (`iss91v2`), en je hebt de `dumbidea` branch aan je collega's laten zien en het blijkt geniaal te zijn. Je kunt dan de oorspronkelijke `iss91` weggooien (waardoor je commits C5 en C6 kwijt raakt), en de andere twee mergen. Je historie ziet er dan uit als Figuur 3-21).
+Laten we zeggen dat je besluit dat je de tweede oplossing voor je probleem het beste vindt (`iss91v2`), en je hebt de `dumbidea` branch aan je collega's laten zien en het blijkt geniaal te zijn. Je kunt dan de oorspronkelijke `iss91` weggooien (waardoor je commits C5 en C6 kwijt raakt), en de andere twee mergen. Je historie ziet er dan uit als Figuur 3-21.
 
 Insert 18333fig0321.png
-Figuur 3-21. Je historie na het samenvoegen van dumbidea en iss91v2.
+Figuur 3-21. Je historie na het mergen van dumbidea en iss91v2.
 
-Het is belangrijk om te beseffen dat tijdens al deze handelingen, al deze branches volledig lokaal zijn. Als je aan het branchen of mergen bent, dan wordt alles alleen in jouw Git repository gedaan, dus er vindt geen server communicatie plaats.
+Het is belangrijk om te beseffen dat tijdens al deze handelingen, al deze branches volledig lokaal zijn. Als je aan het branchen of mergen bent, dan wordt alles alleen in jouw Git repository gedaan - dus er vindt geen server communicatie plaats.
 
 ## Remote branches ##
 
 Remote branches zijn referenties naar de staat van de branches op remote repositories. Ze zijn lokale branches die jij niet kunt verplaatsen; ze worden automatisch verplaatst zodra je er netwerk communicatie plaatsvindt. Remote branches gedragen zich als boekenleggers om je eraan te helpen herinneren wat de staat van de branches was op je remote repositories toen je voor het laatst met ze in contact was.
 
-Ze hebben de vorm `(remote)/(branch)`. Bijvoorbeeld, als je wil zien hoe de `master` branch op je `origin` de laatste keer dat je er mee communiceerde er uit zag, dan zal je de `origin/master` branch moeten bekijken. Als je aan het werk bent met een probleem samen met een partner en zij heeft een `iss53` branch gepushed, kan je je eigen lokale `iss53` hebben, maar de branch op de server zou wijzen naar de commit op `origin/iss53`.
+Ze hebben de vorm `(remote)/(branch)`. Bijvoorbeeld, als je wil zien hoe de `master` branch op je `origin` de laatste keer dat je er mee communiceerde er uit zag, dan zal je de `origin/master` branch moeten bekijken. Als je samen met een partner aan het werk bent met een probleem en zij heeft een `iss53` branch gepushed, zou je je een eigen lokale `iss53` kunnen hebben, maar de branch op de server zal wijzen naar de commit op `origin/iss53`.
 
-Dit is wat verwarrend, dus laten we eens naar een voorbeeld kijken. Stel dat je een Git server op je netwerk hebt op `git.ourcompany.com`. Als je hiervan kloont dan wordt die automatisch `origin` voor je genoemd, Git haalt alle gegevens binnen, maakt een verwijzing naar waar de `master` branch is en noemt dat lokaal `origin/master`, en deze kan je niet verplaatsen. Git geeft je ook een eigen `master` branch, beginnend op dezelfde plaats als de `master` branch van origin, zodat je iets hebt om vanaf te werken (zie Figuur 3-22).
+Dit kan wat verwarrend zijn, dus laten we eens naar een voorbeeld kijken. Stel dat je een Git server op je netwerk hebt op `git.ourcompany.com`. Als je hiervan cloned dan wordt die door Git automatisch `origin` voor je genoemd, Git haalt alle gegevens binnen, maakt een verwijzing naar waar de `master` branch is en noemt dat lokaal `origin/master`, en deze kan je niet verplaatsen. Git geeft je ook een eigen `master` branch, beginnend op dezelfde plaats als de `master` branch van origin, zodat je iets hebt om vanaf te werken (zie Figuur 3-22).
 
 Insert 18333fig0322.png
 Figuur 3-22. Een Git clone geeft je een eigen master branch en origin/master wijzend naar de master branch van origin.
 
-Als je wat werk doet op je lokale master branch, en in de tussentijd pushed iemand anders iets naar `git.ourcompany.com` en daarmee die master branch vernieuwd, dan zijn jullie histories verschillend vooruit geschoven. En, zolang je geen contact hebt met de origin server, zal jouw `origin/master` verwijzing niet verplaatsen (zie Figuur 3-23).
+Als je wat werk doet op je lokale master branch, en in de tussentijd pusht iemand anders iets naar `git.ourcompany.com` waardoor die master branch wordt vernieuwd, dan zijn jullie histories verschillend vooruit geschoven. En zolang je geen contact hebt met de origin server, zal jouw `origin/master` verwijzing niet verplaatsen (zie Figuur 3-23).
 
 Insert 18333fig0323.png
-Figuur 3-23. Lokaal werken terwijl iemand anders naar je remote server pushed laat elke historie anders vooruit gaan.
+Figuur 3-23. Lokaal werken terwijl iemand anders naar je remote server pusht laat elke historie anders vooruit gaan.
 
-Om je werk te synchroniseren, voer je een `git fetch origin` commando uit. Dit commando bekijkt welke op server origin is (in dit geval is het `git.ourcompany.com`), haalt gegevens er vanaf die je nog niet hebt en vernieuwt je lokale database, waarbij je `origin/master` verwijzing naar zijn nieuwe positie verplaatst wordt (zie Figuur 3-24).
+Om je werk te synchroniseren, voer je een `git fetch origin` commando uit. Dit commando bekijkt welke server origin is (in dit geval is het `git.ourcompany.com`), haalt gegevens er vanaf die je nog niet hebt en vernieuwt je lokale database, waarbij je `origin/master` verwijzing naar zijn nieuwe positie verplaatst wordt die meer up-to-date is (zie Figuur 3-24).
 
 Insert 18333fig0324.png
 Figuur 3-24. Het git fetch commando vernieuwt je remote referenties.
@@ -417,14 +446,14 @@ Om het hebben van meerdere remote servers te tonen en hoe remote branches voor d
 Insert 18333fig0325.png
 Figuur 3-25. Een andere server als een remote toevoegen.
 
-Nu kun je `git fetch teamone` uitvoeren om alles op te halen dat wat de `teamone` remote server heeft en jij nog niet. Omdat die server een subset heeft van de gegevens die jouw `origin` server op dit moment heeft, haalt Git geen gegevens maar maakt een remote branch genaamd `teamone/master` aan en laat die wijzen naar de commit die `teamone` heeft als zijn `master` branch (zie Figuur 3-26).
+Nu kun je `git fetch teamone` uitvoeren om alles op te halen dat wat de `teamone` remote server heeft en jij nog niet. Omdat die server een subset heeft van de gegevens die jouw `origin` server op dit moment heeft, haalt Git geen gegevens op maar maakt een remote branch genaamd `teamone/master` aan en laat die wijzen naar de commit die `teamone` heeft als zijn `master` branch (zie Figuur 3-26).
 
 Insert 18333fig0326.png
 Figuur 3-26. Je krijgt lokaal een referentie naar de master branch positie van teamone.
 
 ### Pushen ###
 
-Als je een branch wil delen met de rest van de wereld, dan moet je het naar een remote terugzetten waar je schrijftoegang op hebt. Je lokale branches worden niet automatisch gesynchroniseerd met de remotes waar je naar schrijft, je moet de branches die je wilt delen uitdrukkelijk pushen. Op die manier kun je privé branches gebruiken voor het werk dat je niet wil delen, en alleen die topic branches pushen waar je op wilt samenwerken.
+Als je een branch wil delen met de rest van de wereld, dan moet je het naar een remote terugzetten waar je schrijftoegang op hebt. Je lokale branches worden niet automatisch gesynchroniseerd met de remotes waar je naar schrijft - je moet de branches die je wilt delen uitdrukkelijk pushen. Op die manier kun je privé branches gebruiken voor het werk dat je niet wil delen, en alleen die topic branches pushen waar je op wilt samenwerken.
 
 Als je een branch genaamd `serverfix` hebt waar je met anderen aan wilt werken, dan kun je die op dezelfde manier pushen als waarop je dat voor de eerste branch hebt gedaan. Voer `git push (remote) (branch)` uit:
 
@@ -436,7 +465,7 @@ Als je een branch genaamd `serverfix` hebt waar je met anderen aan wilt werken,
 	To git@github.com:schacon/simplegit.git
 	 * [new branch]      serverfix -> serverfix
 
-Dit is een verkorte manier. Git zal de `serverfix` branchnaam automatisch expanderen naar `refs/heads/serverfix:refs/heads/serverfix`, wat staat voor "Neem mijn lokale serverfix branch en push die om de serverfix branch van de remote te vernieuwen.". We zullen het `refs/heads` gedeelte gedetaileerd behandelen in Hoofdstuk 9, maar je kunt het normaalgesproken weglaten. Je kun ook `git push origin serverfix:serverfix` doen, wat hetzelfde doet. Dit staat voor "Neem mijn serverfix en maak het de serverfix van de remote." Je kunt dit formaat gebruiken om een lokale branch te pushen naar een remote branch die anders heet. Als je niet wil dat het `serverfix` heet aan de remote kant, kan je in plaats daarvan `git push origin serverfix:awesomebranch` gebruiken om je lokale `serverfix` branch naar de `awesomebranch` op het remote project te pushen.
+Dit is een beetje de bocht afsnijden. Git zal de `serverfix` branchnaam automatisch expanderen naar `refs/heads/serverfix:refs/heads/serverfix`, wat staat voor "Neem mijn lokale serverfix branch en push die om de serverfix branch van de remote te vernieuwen.". We zullen het `refs/heads` gedeelte gedetaileerd behandelen in Hoofdstuk 9, maar je kunt het normaalgesproken weglaten. Je kun ook `git push origin serverfix:serverfix` doen, wat hetzelfde doet. Dit staat voor "Neem mijn serverfix en maak het de serverfix van de remote." Je kunt dit formaat gebruiken om een lokale branch te pushen naar een remote branch die anders heet. Als je niet wil dat het `serverfix` heet aan de remote kant, kan je in plaats daarvan `git push origin serverfix:awesomebranch` gebruiken om je lokale `serverfix` branch naar de `awesomebranch` op het remote project te pushen.
 
 De volgende keer dat één van je medewerkers van de server fetched zal deze een referentie krijgen naar de versie van `serverfix` op de server, onder de remote branch `origin/serverfix`:
 
@@ -448,37 +477,37 @@ De volgende keer dat één van je medewerkers van de server fetched zal deze een
 	From git@github.com:schacon/simplegit
 	 * [new branch]      serverfix    -> origin/serverfix
 
-Het is belangrijk om op te merken dat als je een fetch doet die nieuwe remote branches ophaalt, je niet automatisch lokale aanpasbare kopieën daarvan hebt. In andere woorden, in dit geval heb je geen nieuwe `serverfix` branch, je hebt alleen een `origin/serverfix` verwijzing die je niet kunt aanpassen.
+Het is belangrijk om op te merken dat wanneer je een fetch doet die nieuwe remote branches ophaalt, je niet automatisch lokale aanpasbare kopieën daarvan hebt. In andere woorden, in dit geval heb je geen nieuwe `serverfix` branch - je hebt alleen een `origin/serverfix` verwijzing die je niet kunt aanpassen.
 
 Om dit werk in je huidige werk branch te mergen, kun je `git merge origin/serverfix` uitvoeren. Als je een eigen `serverfix` branch wilt waar je op kunt werken, dan kun je deze op je remote branch baseren:
 
 	$ git checkout -b serverfix origin/serverfix
-	Branch serverfix set up to track remote branch refs/remotes/origin/serverfix.
-	Switched to a new branch "serverfix"
+	Branch serverfix set up to track remote branch serverfix from origin.
+	Switched to a new branch 'serverfix'
 
 Dit maakt een lokale branch aan waar je op kunt werken, die begint met waar `origin/serverfix` is.
 
 ### Tracking branches ###
 
-Een lokale branch uitchecken van een remote branch creëert automatisch een zogenaamde _volg branch_ (_tracking branch_). Tracking branches zijn lokale branches die een directe releatie met een remote branch hebben. Als je op een tracking branch zit en `git push` typt, dat weet Git automatisch naar welke server en branch hij moet pushen. En, als je op een van die branches zit zal het uitvoeren van `git pull` alle remote referenties ophalen en automatisch naar de corresponderende remote branch mergen.
+Een lokale branch uitchecken van een remote branch creëert automatisch een zogenaamde _volg branch_ (_tracking branch_). Tracking branches zijn lokale branches die een directe releatie met een remote branch hebben. Als je op een tracking branch zit en `git push` typt, dat weet Git automatisch naar welke server en branch hij moet pushen. En, als je op een van die branches zit zal het uitvoeren van `git pull` alle remote referenties ophalen en automatisch de corresponderende remote branch erin mergen.
 
-Als je een repository kloont, zal het over het algemeen automatisch een `master` branch aanmaken, die `origin/master` tracked. Daarom werken `git push` en `git pull` zo uit het doosje, zonder verdere argumenten. Maar je kan ook andere tracking branches instellen als je dat wilt, andere die niet branches volgen op `origin` en niet de `master` branch tracken. Een eenvoudig voorbeeld is wat je zojuist gezien hebt: `git checkout -b [branch] [remotenaam]/[branch]` uitvoeren. Als je Git versie 1.6.2 of nieuwer hebt, kun je ook de `--track` afkorting gebruiken:
+Als je een repository cloned, zal het over het algemeen automatisch een `master` branch aanmaken die `origin/master` tracked. Daarom werken `git push` en `git pull` zo uit het doosje, zonder verdere argumenten. Maar je kan ook andere tracking branches aanmaken als je dat wilt, andere die niet branches tracken op `origin` en niet de `master` branch tracken. Een eenvoudig voorbeeld is wat je zojuist gezien hebt: `git checkout -b [branch] [remotenaam]/[branch]` uitvoeren. Als je Git versie 1.6.2 of nieuwer hebt, kun je ook de `--track` afkorting gebruiken:
 
 	$ git checkout --track origin/serverfix
-	Branch serverfix set up to track remote branch refs/remotes/origin/serverfix.
-	Switched to a new branch "serverfix"
+	Branch serverfix set up to track remote branch serverfix from origin.
+	Switched to a new branch 'serverfix'
 
 Om een lokale branch te maken met een andere naam dan de remote branch, kun je simpelweg de eerste variant met een andere lokale branch naam gebruiken:
 
 	$ git checkout -b sf origin/serverfix
-	Branch sf set up to track remote branch refs/remotes/origin/serverfix.
-	Switched to a new branch "sf"
+	Branch sf set up to track remote branch serverfix from origin.
+	Switched to a new branch 'sf'
 
 Nu zal je lokale `sf` branch automatisch pullen en pushen van origin/serverfix.
 
 ### Remote branches verwijderen ###
 
-Stel dat je klaar bent met een remote branch, stel dat jij en je medewerkers klaar zijn met een feature en het hebben gemerged in de `master` branch van de remote (of welke branch je stabiele code ook in zit). Dan kun je een remote branch verwijderen door de nogal botte syntax `git push [remotenaam] :[branch]` te gebruiken. Als je de `serverfix` branch van de server wilt verwijderen, dan voer je het volgende uit:
+Stel dat je klaar bent met een remote branch - zeg maar, jij en je medewerkers zijn klaar met een feature en het hebben gemerged in de `master` branch van de remote (of welke branch jullie stabiele code ook in zit). Dan kun je een remote branch verwijderen door de nogal botte syntax `git push [remotenaam] :[branch]` te gebruiken. Als je de `serverfix` branch van de server wilt verwijderen, dan voer je het volgende uit:
 
 	$ git push origin :serverfix
 	To git@github.com:schacon/simplegit.git
@@ -488,7 +517,7 @@ Boem. Geen branch meer op je server. Je zult deze pagina wel een ezelsoortje wil
 
 ## Rebasen ##
 
-In Git zijn er twee hoofdmanieren om wijzigingen te integreren van de ene branch in een andere: de `merge` en de `rebase`. In deze paragraaf zul je leren wat rebasen is, hoe je dat moet doen, waarom het een zeer bijzondere toepassing is en in welke gevallen je het niet wilt gebruiken.
+In Git zijn er twee hoofdmanieren om wijzigingen te integreren van de ene branch in een andere: de `merge` en de `rebase`. In deze paragraaf ga je leren wat rebasen is, hoe je dat moet doen, waarom het een zeer bijzondere stukje gereedschap is en in welke gevallen je het niet wilt gebruiken.
 
 ### De simpele rebase ###
 
@@ -500,7 +529,7 @@ Figuur 3-27. Je initiële uiteengelopen historie.
 De simpelste manier om de branches te integreren, zoals we al hebben besproken, is het `merge` commando. Het voert een drieweg merge uit tussen de twee laatste snapshots van de branches (C3 en C4), en de meest recente gezamenlijke voorouder van die twee (C2), en maakt een nieuw snapshot (en commit) zoals getoond in Figuur 3-28.
 
 Insert 18333fig0328.png
-Figuur 3-28. Een branch merge om de uiteengelopen werk histories te integreren.
+Figuur 3-28. Een branch mergen om de uiteengelopen werk histories te integreren.
 
 Maar, er is nog een manier: je kunt de patch van de wijziging die werd geïntroduceerd in C3 pakken en die opnieuw toepassen op C4. In Git, wordt dit _rebasen_ genoemd. Met het `rebase` commando kan je alle wijzigingen pakken die zijn gecommit op de ene branch, en ze opnieuw afspelen op een andere.
 
@@ -511,7 +540,7 @@ In dit voorbeeld, zou je het volgende uitvoeren:
 	First, rewinding head to replay your work on top of it...
 	Applying: added staged command
 
-Het gebeurt door naar de gezamenlijke voorouder van de twee branches te gaan (degene waar je op zit en degene waar je op rebased), de diff te nemen die geïntroduceerd is voor elke losse commit op de branch waar je op zit, die diffs in tijdelijke bestanden te bewaren, de huidige branch terug te zetten naar dezelfde commit als de branch waar je op rebased, en uiteindelijk elke diff om de beurt toe te passen, Figuur 3-29 toont dit proces.
+Het gebeurt door naar de gezamenlijke voorouder van de twee branches te gaan (degene waar je op zit en degene waar je op rebased), de diff te nemen die geïntroduceerd is voor elke losse commit op de branch waar je op zit, die diffs in tijdelijke bestanden te bewaren, de huidige branch terug te zetten naar dezelfde commit als de branch waar je op rebased, en uiteindelijk elke diff om de beurt te applyen, Figuur 3-29 toont dit proces.
 
 Insert 18333fig0329.png
 Figuur 3-29. De wijzigingen die geïntroduceerd zijn in C3 rebasen op C4.
@@ -521,11 +550,11 @@ Hierna kan je terug gaan naar de master branch en een fast-forward merge doen (z
 Insert 18333fig0330.png
 Figuur 3-30. De master branch Fast-forwarden.
 
-Nu is het snapshot waar C3' naar wijst precies dezelfde als degene waar C5 naar wees in het merge voorbeeld. Er zit geen verschil in het eindresultaat van de integratie, maar rebasen zorgt voor een duidelijkere historie. Als je de log van een gerebasdte branch bekijkt, ziet het eruit als een lineaire historie: het lijkt alsof al het werk in serie is gebeurt, zelfs wanneer het in werkelijkheid in parallel gedaan is.
+Nu is het snapshot waar C3' naar wijst precies dezelfde als degene waar C5 naar wees in het merge voorbeeld. Er zit geen verschil in het eindresultaat van de integratie, maar rebasen zorgt voor een duidelijkere historie. Als je de log van een branch die gerebased is bekijkt, ziet het eruit als een lineaire historie: het lijkt alsof al het werk in serie heeft plaatsgevonden, zelfs wanneer het in werkelijkheid parallel eraan gedaan is.
 
-Vaak zal je dit doen om er zeker van te zijn dat je commits netjes toegepast kunnen worden op een remote branch, misschien in een project waar je aan probeert bij te dragen, maar dat je niet beheert. In dit geval zou je het werk in een branch uitvoeren en dan je werk rebasen op `origin/master` als je klaar ben om je patches in te sturen naar het hoofd project. Op die manier hoeft de beheerder geen integratie werk te doen maar gewoon een fast-forward of een gewone apply.
+Vaak zal je dit doen om er zeker van te zijn dat je commits netjes toegepast kunnen worden op een remote branch - misschien in een project waar je aan probeert bij te dragen, maar dat je niet beheert. In dit geval zou je het werk in een branch uitvoeren en dan je werk rebasen op `origin/master` als je klaar ben om je patches in te sturen naar het hoofd project. Op die manier hoeft de beheerder geen integratie werk te doen - gewoon een fast-forward of een schone apply.
 
-Merk op dat de snapshot waar de laatste commit op het eind naar wijst, of het de laatste van de gerebasete commits voor een rebase is of de laatste merge commit na een merge, detzelfde snapshot is; alleen de historie is verschillend. Rebasen speelt veranderingen van een werklijn opnieuw af op een andere, in de volgorde waarin ze gemaakt zijn, terwijl mergen de eindresultaten pakt en die samenvoegt.
+Merk op dat de snapshot waar de laatste commit op het eind naar wijst, of het de laatste van de gerebasede commits voor een rebase is of de laatste merge commit na een merge, detzelfde snapshot is - alleen de historie is verschillend. Rebasen speelt veranderingen van een werklijn opnieuw af op een andere, in de volgorde waarin ze gemaakt zijn, terwijl mergen de eindresultaten pakt en die samenvoegt.
 
 ### Interessantere rebases ###
 
@@ -534,7 +563,7 @@ Je kunt je rebase ook opnieuw laten afspelen op iets anders dan de rebase branch
 Insert 18333fig0331.png
 Figuur 3-31. Een historie met een topic branch vanaf een andere topic branch.
 
-Stel dat je beslist dat je de client-kant wijzigingen wilt mergen in je hoofdlijn voor een release, maar je wilt de server-kant wijzigingen nog laten wachten totdat het verder getest is. Je kunt de wijzigingen van client pakken, die nog niet op server zitten (C8 en C9) en die opnieuw afspelen op je master branch door de `--onto` optie te gebruiken van `git rebase`:
+Stel nu, je besluit dat je de client-kant wijzigingen wilt mergen in je hoofdlijn voor een release, maar je wilt de server-kant wijzigingen nog vasthouden totdat het verder getest is. Je kunt de wijzigingen van client pakken, die nog niet op server zitten (C8 en C9) en die opnieuw afspelen op je master branch door de `--onto` optie te gebruiken van `git rebase`:
 
 	$ git rebase --onto master server client
 
@@ -551,7 +580,7 @@ Nu kun je een fast-forward doen van je master branch (zie Figuur 3-33):
 Insert 18333fig0333.png
 Figuur 3-33. Je master branch fast-forwarden om de client branch wijzigingen mee te nemen.
 
-Stel dat je besluit om de server branch ook te pullen. Je kunt de server branch rebasen op de master branch zonder het eerst te hoeven uitchecken door `git rebase [basisbranch] [topicbranch]` uit te voeren, wat de topic branch voor je uitchecked (in dit geval, `server`) en het opnieuw afspeelt om de basis branch (`master`):
+Stel dat je besluit om de server branch ook te pullen. Je kunt de server branch rebasen op de master branch zonder het eerst te hoeven uitchecken door `git rebase [basisbranch] [topicbranch]` uit te voeren - wat de topic branch voor je uitcheckt (in dit geval, `server`) en het opnieuw afspeelt om de basis branch (`master`):
 
 	$ git rebase master server
 
@@ -577,35 +606,35 @@ Figuur 3-35. Uiteindelijke commit historie.
 
 Ahh, maar de zegeningen van rebasen zijn niet geheel zonder nadelen, samengevat in één enkele regel:
 
-**Rebase geen commits die je gepushed hebt naar een publiek repository.**
+**Rebase geen commits die je gepusht hebt naar een publiek repository.**
 
-Als je die richtlijn volgt, dan zal je niets overkomen. Als je dat niet doet, zullen mensen je haten en je zult door vrienden en familie uitgehoond worden.
+Als je die richtlijn volgt, kan je weinig gebeuren. Als je dat niet doet, zullen mensen je haten en je zult door vrienden en familie uitgehoond worden.
 
-Als je spullen rebaset, zet je bestaande commits buitenspel en maak je nieuwe aan die vergelijkbaar zijn maar anders. Als je commits ergens pushed en andere pullen deze en baseren daar werk op, en vervolgens herschrijf je die commits met `git rebase` en pushed deze weer, dan zullen je medewerkers hun werk opnieuw moeten mergen en zal de boel erg vervelend worden als je hun werk probeert te pullen in het jouwe.
+Als je spullen rebased, zet je bestaande commits buitenspel en maak je nieuwe aan die vergelijkbaar zijn maar anders. Als je commits ergens pusht en andere pullen deze en baseren daar werk op, en vervolgens herschrijf je die commits met `git rebase` en pusht deze weer, dan zullen je medewerkers hun werk opnieuw moeten mergen en zal het allemaal erg vervelend worden als je hun werk probeert te pullen in het jouwe.
 
-Laten we eens kijken naar een voorbeeld hoe werk rebasen dat je publiek gemaakt hebt problemen kan veroorzaken. Stel dat je van een centrale server kloont en dan daar wat werk aan doet. Je commit historie ziet er uit als Figuur 3-36.
+Laten we eens kijken naar een voorbeeld hoe werk rebasen dat je publiek gemaakt hebt problemen kan veroorzaken. Stel dat je van een centrale server cloned en dan daar wat werk aan doet. Je commit historie ziet er uit als Figuur 3-36.
 
 Insert 18333fig0336.png
-Figuur 3-36. Kloon een repository, en doe wat werk daarop.
+Figuur 3-36. Clone een repository, en doe wat werk daarop.
 
-Nu doet iemand anders wat meer werk dat een merge bevat, en pushed dat werk naar de centrale server. Je fetched dat en merged de nieuwe remote branch in jouw werk, zodat je historie er uit ziet zoals Figuur 3-37.
+Nu doet iemand anders wat meer werk wat een merge bevat, en pusht dat werk naar de centrale server. Je fetcht dat en merged de nieuwe remote branch in jouw werk, zodat je historie er uit ziet zoals Figuur 3-37.
 
 Insert 18333fig0337.png
 Figuur 3-37. Haal meer commits op, en merge ze in je werk.
 
-Daarna, beslist de persoon die het werk gepushed heeft om terug te gaan en hun werk te gaan rebasen; ze voeren een `git push --force` uit om de historie op de server te herschrijven. Je pulled daarna van die server, waarbij je de nieuwe commits binnen krijgt.
+Daarna, beslist de persoon die het werk gepusht heeft om erop terug te komen en in plaats daarvan zijn werk te gaan rebasen; hij voeren een `git push --force` uit om de historie op de server te herschrijven. Je pulled daarna van die server, waarbij je de nieuwe commits binnen krijgt.
 
 Insert 18333fig0338.png
-Figuur 3-38. Iemand pushed gerebasete commits, daarbij commits buitenspel zettend waar jij werk op gebaseerd hebt.
+Figuur 3-38. Iemand pusht gerebasede commits, daarbij commits buitenspel zettend waar jij werk op gebaseerd hebt.
 
-Nu moet je dit werk opnieuw mergeen, hoewel je dat al gedaan hebt. Rebasen verandert de SHA-1 hashes van deze commits, dus voor Git zien ze er uit als nieuwe commits, terwijl je in feite het C4 werk al in je historie hebt (zie Figuur 3-39).
+Nu moet je dit werk opnieuw mergen, terwijl je dat al gedaan hebt. Rebasen verandert de SHA-1 hashes van deze commits, dus voor Git zien ze er uit als nieuwe commits, terwijl je in feite het C4 werk al in je historie hebt (zie Figuur 3-39).
 
 Insert 18333fig0339.png
-Figuur 3-39. Je merge hetzelfde werk opnieuw in een nieuwe merge commit.
+Figuur 3-39. Je merget hetzelfde werk opnieuw in een nieuwe merge commit.
 
-Je moet dat werk op een bepaald punt mergen, zodat je in de toekomst bij kunt blijven met de andere ontwikkelaar. Nadat je dat gedaan hebt, zal je history zowel de C4 als de C4' commits bevatten, die verschillende SHA-1 hashes hebben, maar die hetzelfde werk introduceren en dezelfde commit bericht hebben. Als je een `git log` uitvoert als je historie er zo uitziet, dan zul je twee commits zien die dezelfde auteur, datum en bericht hebben, wat verwarring geeft. Daarnaast zal je, als je deze historie pushed naar de server, al die gerebasete commits opnieuw introduceren op de centrale server, wat mensen nog meer kan verwarren.
+Je moet dat werk op een gegeven moment mergen, zodat je in de toekomst bij kunt blijven met de andere ontwikkelaar. Nadat je dat gedaan hebt, zal je history zowel de C4 als de C4' commits bevatten, die verschillende SHA-1 hashes hebben, maar die hetzelfde werk introduceren en hetzelfde commit bericht hebben. Wanneer je een `git log` uitvoert als je historie er zo uitziet, dan zul je twee commits zien die dezelfde auteur, datum en bericht hebben, wat alleen maar verwarring geeft. Daarnaast zal je, als je deze historie pusht naar de server, al die gerebasede commits opnieuw introduceren op de centrale server, wat mensen nog meer kan verwarren.
 
-Als je rebasen behandelt als een manier om commits op te ruimen ze bewerken voordat je ze pushed, en als je alleen commits rebaset die nog nooit publiekelijk beschikbaar zijn geweest, dan zal er niets aan de hand zijn. Als je commits rebaset die al publiekelijk gepushed zijn, en mensen kunnen werk gebaseerd hebben op die commits, bereid je dan maar voor op een aantal frustrerende problemen.
+Als je rebasen behandelt als een manier om commits op te ruimen en ze te bewerken voordat je ze pusht, en als je alleen commits rebaset die nog nooit publiekelijk beschikbaar zijn geweest, dan zal er niets aan de hand zijn. Als je commits rebaset die al publiekelijk gepusht zijn, en mensen kunnen werk gebaseerd hebben op die commits, bereid je dan maar voor op een aantal frustrerende problemen.
 
 ## Samenvatting ##
 

From 44936fd310fa33f7da16529fb782d0c817d0f06a Mon Sep 17 00:00:00 2001
From: Cor <git@cpt1.demon.nl>
Date: Thu, 20 Feb 2014 12:55:31 +0100
Subject: [PATCH 239/690] [en] Chapter 06 Correct quotes and make suggestions
 for adjustments

---
 en/06-git-tools/01-chapter6.markdown | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/en/06-git-tools/01-chapter6.markdown b/en/06-git-tools/01-chapter6.markdown
index 3eef10757..36459d56e 100644
--- a/en/06-git-tools/01-chapter6.markdown
+++ b/en/06-git-tools/01-chapter6.markdown
@@ -59,7 +59,7 @@ A lot of people become concerned at some point that they will, by random happens
 
 If you do happen to commit an object that hashes to the same SHA-1 value as a previous object in your repository, Git will see the previous object already in your Git database and assume it was already written. If you try to check out that object again at some point, you’ll always get the data of the first object.
 
-However, you should be aware of how ridiculously unlikely this scenario is. The SHA-1 digest is 20 bytes or 160 bits. The number of randomly hashed objects needed to ensure a 50% probability of a single collision is about 2^80 (the formula for determining collision probability is `p = (n(n-1)/2) * (1/2^160))`. 2^80 is 1.2 x 10^24 or 1 million billion billion. That’s 1,200 times the number of grains of sand on the earth.
+However, you should be aware of how ridiculously unlikely this scenario is. The SHA-1 digest is 20 bytes or 160 bits. The number of randomly hashed objects needed to ensure a 50% probability of a single collision is about 2^80 (the formula for determining collision probability is `p = (n(n-1)/2) * (1/2^160)`). 2^80 is 1.2 x 10^24 or 1 million billion billion. That’s 1,200 times the number of grains of sand on the earth.
 
 Here’s an example to give you an idea of what it would take to get a SHA-1 collision. If all 6.5 billion humans on Earth were programming, and every second, each one was producing code that was the equivalent of the entire Linux kernel history (1 million Git objects) and pushing it into one enormous Git repository, it would take 5 years until that repository contained enough objects to have a 50% probability of a single SHA-1 object collision. A higher probability exists that every member of your programming team will be attacked and killed by wolves in unrelated incidents on the same night.
 
@@ -498,7 +498,7 @@ Again, if you don’t specify a stash, Git assumes the most recent stash:
 
     $ git stash show -p | git apply -R
 
-You may want to create an alias and effectively add a `stash-unapply` command to your git. For example:
+You may want to create an alias and effectively add a `stash-unapply` command to your Git. For example:
 
     $ git config --global alias.stash-unapply '!git stash show -p | git apply -R'
     $ git stash
@@ -590,6 +590,10 @@ You need to edit the script so that it stops at the commit you want to edit. To
 
 When you save and exit the editor, Git rewinds you back to the last commit in that list and drops you on the command line with the following message:
 
+<!-- This is actually weird, as the SHA-1 of 7482e0d is not present in the list, 
+nor is the commit message. Please review 
+-->
+
 	$ git rebase -i HEAD~3
 	Stopped at 7482e0d... updated the gemspec to hopefully work better
 	You can amend the commit now, with

From 5c49f5d9208933183d87bb8e28481cd4725f948f Mon Sep 17 00:00:00 2001
From: Cor <git@cpt1.demon.nl>
Date: Thu, 20 Feb 2014 12:56:55 +0100
Subject: [PATCH 240/690] [nl] Chapter 06 - Review and retranslate

---
 nl/06-git-tools/01-chapter6.markdown | 249 +++++++++++++++------------
 1 file changed, 143 insertions(+), 106 deletions(-)

diff --git a/nl/06-git-tools/01-chapter6.markdown b/nl/06-git-tools/01-chapter6.markdown
index 9dbbf4cca..dbde96ed1 100644
--- a/nl/06-git-tools/01-chapter6.markdown
+++ b/nl/06-git-tools/01-chapter6.markdown
@@ -1,20 +1,55 @@
+<!-- Attentie heren en dames vertalers.
+Ik zou het volgende willen voorstellen:
+Er zijn bepaalde termen die voor de gemiddelde Nederlandse computer gebruiker 
+veel beter klinken (of bekender voorkomen) als de orginele Engelse term. In het
+begin zullen deze termen niet vaak voorkomen, maar in de meer diepgaandere 
+hoofdstukken komen deze steeds meer voor. Termen als "Committen", "Mergen" 
+en "Applyen" klinken beter dan "Plegen" of "Toepassen", "Samenvoegen" en 
+"Toepassen" (wat bovendien slecht valt te onderscheiden van de 
+commit-toepassing). De mensen die dit boek lezen zijn, naar mijn bescheiden 
+inschatting, al redelijk op de hoogte van versiebeheer en passen (zie ik in 
+de praktijk) deze termen al toe. Een nieuwe terminologie introduceren lijkt 
+me dan ook niet noodzakelijk.
+Verder blijven er altijd kreten over als "directory", wat vertaald zou kunnen 
+worden als "map", maar bij het Engelse werkwoord to map krijgen we dan weer het
+probleem: hoe dit weer te vertalen? Daarom zou ik willen voorstellen om deze 
+basis-termen toch onvertaald te laten.
+
+Twijfelgevallen zullen altijd blijven zoals de term "file", daarvan wordt in de
+praktijk zowel de term file als bestand gebruikt. Ik denk dat we hier moeten 
+kijken hoe het in de context past. 
+Maar ook een term als "tool" en (ik zit zelf nog op een mooie Nederlandse term
+te broeden) "plumbing", hierbij stel ik voor om eenmalig een Nederlandse 
+vertaling te geven, tussen haakjes de Engelse term te geven en in het vervolg
+de Engelse term te gebruiken. Wederom is de context hier belangrijk.
+
+Verder stel ik ook voor om de regels op https://onzetaal.nl/taaladvies zoveel
+mogelijk te volgen. Bijvoorbeeld de regels omtrent het spellen van Engelse 
+werkwoorden die in het Nederlands gebruikt worden.
+
+Let wel: ik wil niemand tot iets verplichten, maar ik denk dat we moeten 
+streven naar een zo duidelijk mogelijke en best bij de praktijk aansluitende
+vertaling moeten proberen te maken.
+
+Veel succes en plezier bij het vertalen...
+-->
 # Git tools #
 
 Nu heb je de meeste commando's en werkwijzen geleerd die je dagelijks nodig hebt om een Git repository voor je broncode te beheren en te onderhouden. Je hebt de basistaken van het tracken en committen van bestanden onder de knie, en je hebt de kracht van de staging area en lichtgewicht topic branching en mergen in de vingers.
 
-Nu ga je een aantal zeer krachtige dingen verkennen die Git kan, die je niet per se dagelijks gebruikt, maar die je op een bepaald moment toch nodig kunt gaan hebben.
+Nu ga je een aantal zeer krachtige dingen verkennen die Git voor je kan doen, die je niet per se dagelijks gebruikt, maar die je op een bepaald moment toch nodig kunt gaan hebben.
 
 ## Revisie selectie ##
 
-Git stelt je in staat om specifieke commits of een serie commits op diverse manieren te specificeren. Ze zijn niet per se voor de hand liggend, maar behulpzaam om te weten.
+Git stelt je in staat om specifieke commits of een serie commits op diverse manieren te specificeren. Ze zijn niet meteen voor de hand liggend, maar behulpzaam om te weten.
 
 ### Enkele revisies ###
 
-Natuurlijk kun je naar een commit refereren door de SHA-1 hash die het toegekend is, maar er zijn ook meer mensvriendelijke manieren om naar een commit te refereren. In deze paragraaf worden diverse manieren getoond waarop je naar een enkele commit kunt refereren.
+Natuurlijk kun je naar een commit refereren met de SHA-1 hash die het toegekend is, maar er zijn ook meer mensvriendelijke manieren om naar een commit te refereren. In deze paragraaf worden diverse manieren getoond waarop je naar een enkele commit kunt refereren.
 
 ### Korte SHA ###
 
-Git is slim genoeg om uit te vinden welke commit je bedoelde te typen als je het de eerste karakters geeft, zolang je gedeeltelijke SHA-1 minstens vier karakters lang en ondubbelzinnig is; dat wil zeggen dat slechts één object in de huidige repository begint met die gedeeltelijke SHA-1.
+Git is slim genoeg om uit te vinden welke commit je bedoelde te typen als je het de eerste paar karakters geeft, zolang je gedeeltelijke SHA-1 maar minstens vier karakters lang en ondubbelzinnig is; dat wil zeggen dat slechts één object in de huidige repository begint met die gedeeltelijke SHA-1.
 
 Bijvoorbeeld, stel dat je om een specifieke commit te zien een `git log` commando uitvoert en de commit identificeert waarin je een bepaalde functionaliteit hebt toegevoegd:
 
@@ -38,13 +73,13 @@ Bijvoorbeeld, stel dat je om een specifieke commit te zien een `git log` command
 
 	    added some blame and merge stuff
 
-In dit geval, kiezen we `1c002dd....`. Als je op die commit `git show` uitvoert, dan zijn de volgende commando's gelijkwaardig (aangenomen dat de kortere versies ondubbelzinnig zijn):
+Kies in dit geval `1c002dd....`. Als je op die commit `git show` uitvoert, dan zijn de volgende commando's gelijkwaardig (aangenomen dat de kortere versies ondubbelzinnig zijn):
 
 	$ git show 1c002dd4b536e7479fe34593e72e6c6c1819e53b
 	$ git show 1c002dd4b536e7479f
 	$ git show 1c002d
 
-Git kan met een korte unieke afkorting voor je SHA-1 waarde uit de voeten. Als je `--abbrev-commit` meegeeft aan het `git log` commando, dan zal de output kortere waarden gebruiken maar ze uniek houden; het gebruikt standaard zeven karakters maar maakt ze langer indien nodig om de SHA-1 ondubbelzinnig te houden:
+Git kan met een korte unieke afkorting van een SHA-1 waarde uit de voeten. Als je `--abbrev-commit` meegeeft aan het `git log` commando, dan zal de output kortere waarden gebruiken maar ze uniek houden; het gebruikt standaard zeven karakters maar maakt ze langer indien nodig om de SHA-1 ondubbelzinnig te houden:
 
 	$ git log --abbrev-commit --pretty=oneline
 	ca82a6d changed the version number
@@ -57,27 +92,28 @@ Over het algemeen zijn acht tot tien karakters meer dan voldoende om binnen een
 
 Veel mensen beginnen bezorgd te raken dat ze op een bepaald moment door puur toeval, twee objecten in hun repository hebben die naar dezelfde SHA-1 waarde hashen. Wat dan?
 
-Mocht je een object committen dat hashed naar dezelfde SHA-1 waarde als een vorig object in je repository, dan zal Git het vorige reeds aanwezige object in je Git database zien en aannemen dat het al geschreven was. Als je dat object opnieuw probeert uit te checken op een bepaald moment, dan zul je altijd de gegevens van het eerste object krijgen.
+Mocht je een object committen dat hashed naar dezelfde SHA-1 waarde als een vorig object in je repository, dan zal Git het vorige reeds aanwezige object in je Git database zien en aannemen dat het al geschreven was. Als je op een bepaald moment dat object opnieuw probeert uit te checken, dan zal je altijd de gegevens van het eerste object krijgen.
 
-Maar, je moet je bewust zijn hoe vreselijk onwaarschijnlijk dit scenario is. De SHA-1 waarde is 20 bytes, of 160 bits. Het aantal benodigde random gehashte objecten om een 50% waarschijnlijkheid van een botsing te garanderen is ongeveer 2^80 (de formule om botsingswaarschijnlijkheid te bepalen is `p = (n(n-1)/2) * (1/2^160)`). 2^80 is 1.2 x 10^24 of 1 miljoen miljard miljard. Dat is 1.200 keer het aantal zandkorrels op de aarde.
+<!-- Vraag: weet iemand de officiële term voor botsingswaarschijnlijkheid? Via de Engelse Wikipedia kom ik (via collision probability) op universal hashing, maar is de formule niet te zien. -->
+Maar wat je moet beseffen is hoe vreselijk onwaarschijnlijk dit scenario is. De SHA-1 waarde is 20 bytes, oftewel 160 bits. Het aantal benodigde random gehashte objecten om een 50% waarschijnlijkheid van een botsing te garanderen is ongeveer 2^80 (de formule om botsingswaarschijnlijkheid te bepalen is `p = (n(n-1)/2) * (1/2^160)`). 2^80 is 1.2 x 10^24 of 1 miljoen miljard miljard. Dat is 1.200 keer het aantal zandkorrels op aarde.
 
-Hier is een voorbeeld om je een idee te geven wat er voor nodig is om een SHA-1 botsing te krijgen. Als alle 6.5 miljard mensen op aarde zouden programmeren, en iedere seconde zou ieder van hen code genereren die gelijk was aan de hele Linux kernel-geschiedenis (1 miljoen Git objecten) en dat in één gigantische Git repository pushen, dan zou het vijf jaar duren voordat die repository genoeg objecten zou bevatten om een 50% waarschijnlijkheid van één enkele SHA-1 object botsing te krijgen. Er bestaat een grotere kans dat elk lid van je programmeerteam zal worden aangevallen en gedood door wolven in ongerelateerde incidenten op dezelfde avond.
+Hier is een voorbeeld om je een idee te geven wat er voor nodig is om een SHA-1 botsing te krijgen. Als alle 6.5 miljard mensen op aarde zouden programmeren, en iedere seconde zou ieder van hen code genereren die gelijk was aan de hele Linux kernel-geschiedenis (1 miljoen Git objecten) en dat in één gigantische Git repository pushen, dan zou het vijf jaar duren voordat die repository genoeg objecten zou bevatten om een 50% waarschijnlijkheid van één enkele SHA-1 object botsing te krijgen. De kans is groter dat elk lid van je programmeerteam zal worden aangevallen en gedood door wolven bij ongerelateerde incidenten op dezelfde avond.
 
 ### Branch referenties ###
 
-De meest eenvoudige manier om een commit te specificeren heeft als voorwaarde dat je er een branchreferentie naar hebt wijzen. Dan kun je een branchnaam in ieder Git commando gebruiken dat een commitobject of SHA-1 waarde verwacht. Bijvoorbeeld, als je het laatste commitobject op een branch wil tonen, dan zijn de volgende commando's gelijk, aangenomen dat de `topic1` branch naar `ca82a6d` wijst:
+De meest eenvoudige manier om een commit te specificeren heeft als voorwaarde dat je er een branchreferentie naar hebt wijzen. Dan kun je een branchnaam in ieder Git commando gebruiken dat een commitobject of SHA-1 waarde verwacht. Bijvoorbeeld, als je het laatste commitobject op een branch wil tonen, dan zijn de volgende commando's gelijkwaardig, aangenomen dat de `topic1` branch naar `ca82a6d` wijst:
 
 	$ git show ca82a6dff817ec66f44342007202690a93763949
 	$ git show topic1
 
-Als je wil zien naar welke specifieke SHA een branch wijst, of als je wil zien wat ieder van deze voorbeelden in termen van SHA's voorstellen, dan kun je een Git sanitaire voorzieningen (plumbin) tool genaamd `rev-parse` gebruiken. Je kunt in Hoofdstuk 9 kijken voor meer informatie over plumbingtools, eigenlijk is `rev-parse` er voor low-level operaties en is niet ontworpen voor dagelijks gebruik. Maar het kan behulpzaam zijn op momenten dat je moet zien wat er echt aan de hand is. Hier kun je `rev-parse` uitvoeren op je branch.
+Als je wilt zien naar welke specifieke SHA een branch wijst, of als je wil zien wat ieder van deze voorbeelden in termen van SHA's voorstellen, dan kun je een Git sanitaire voorzieningen (plumbing) tool genaamd `rev-parse` gebruiken. Je kunt in Hoofdstuk 9 kijken voor meer informatie over plumbingtools, eigenlijk is `rev-parse` er voor low-level operaties en is niet ontworpen voor dagelijks gebruik. Maar het kan behulpzaam zijn op momenten dat je moet zien wat er echt aan de hand is. Hier kun je `rev-parse` uitvoeren op je branch.
 
 	$ git rev-parse topic1
 	ca82a6dff817ec66f44342007202690a93763949
 
-### RefLog verkorte namen ###
+### RefLog afkortingen ###
 
-Een van de dingen die Git in de achtergrond doet terwijl jij zit te werken is een reflog bijhouden: een log waar de staat van HEAD en branchreferenties in de laatste paar maanden in is vastgelegd.
+Een van de dingen die Git in de achtergrond doet terwijl jij lekker zit te werken is een reflog bijhouden: een log waarin is vastgelegd naar welke referenties de HEAD en de branches de laatste paar maanden hebben gewezen.
 
 Je kunt je reflog zien door `git reflog` te gebruiken:
 
@@ -94,7 +130,7 @@ Iedere keer als de punt van je branch om een of andere reden is gewijzigd, dan b
 
 	$ git show HEAD@{5}
 
-Je kunt deze syntax ook gebruiken om te zien waar een branch een bepaalde hoeveelheid tijd geleden was. Bijvoorbeeld, om te zien waar je `master` branch gisteren was, kun je dit typen
+Je kunt deze syntax ook gebruiken om te zien waar een branch een bepaalde tijd geleden was. Bijvoorbeeld, om te zien waar je `master` branch gisteren was, kun je dit typen
 
 	$ git show master@{yesterday}
 
@@ -119,11 +155,11 @@ Om reflog informatie te zien, in hetzelfde formaat als de `git log` output, kun
 
 	    Merge commit 'phedders/rdocs'
 
-Het is belangrijk om te zien dat deze informatie strikt lokaal is, het is een log van wat je hebt gedaan in jouw repository. De referenties zullen niet hetzelfde zijn in de kopie van de repository die iemand anders gemaakt heeft, en meteen nadat je een eerste kloon van een repository hebt gemaakt heb je een lege reflog, omdat er nog geen activiteit is geweest in je repository. `git show HEAD@{2.months.ago}` uitvoeren werkt alleen als je het project minstens twee maanden geleden gekloond hebt, als je het vijf minuten geleden gekloond hebt krijg je geen resultaten.
+Het is belangrijk om op te merken dat deze informatie strikt lokaal is - het is een log van wat jij hebt gedaan in jouw repository. De referenties zullen niet hetzelfde zijn in de kopie van de repository die iemand anders gemaakt heeft; en meteen nadat je een eerste clone van een repository hebt gemaakt heb je een lege reflog, omdat er nog geen activiteit is geweest in je repository. `git show HEAD@{2.months.ago}` uitvoeren werkt alleen als je het project minstens twee maanden geleden gecloned hebt, als je het vijf minuten geleden gecloned hebt krijg je geen resultaten.
 
 ### Voorouder referenties ###
 
-De andere veelgebruikte manier om een commit te specificeren is via zijn voorouders. Als je een `^` aan het einde van een referentie zet zal Git hieruit herleiden dat het de ouder van die commit betekent.
+De andere veelgebruikte manier om een commit te specificeren is via zijn voorouders. Als je een `^` aan het einde van een referentie zet, zal Git hieruit herleiden dat het de ouder van die commit betekent.
 Stel dat je naar de geschiedenis van je project kijkt:
 
 	$ git log --pretty=format:'%h %s' --graph
@@ -146,7 +182,7 @@ Dan zie je de vorige commit door `HEAD^` te specificeren, wat "de ouder van HEAD
 
 	    Merge commit 'phedders/rdocs'
 
-Je kunt ook een getal na de `^` zetten, bijvoorbeeld `d921970^2` betekent "de tweede ouder van d921970." Deze syntax is alleen bruikbaar voor merge commits, die meer dan één ouder hebben. De eerste ouder is de branch waar jij op was toen je mergede, en de andere is de commit op de branch die je gemerged hebt:
+Je kunt ook een getal na de `^` zetten, bijvoorbeeld `d921970^2` betekent "de tweede ouder van d921970." Deze syntax is alleen nuttig voor merge commits, omdat die meer dan één ouder hebben. De eerste ouder is de branch waar jij op was toen je mergede, en de andere is de commit op de branch die je gemerged hebt:
 
 	$ git show d921970^
 	commit 1c002dd4b536e7479fe34593e72e6c6c1819e53b
@@ -162,7 +198,7 @@ Je kunt ook een getal na de `^` zetten, bijvoorbeeld `d921970^2` betekent "de tw
 
 	    Some rdoc changes
 
-De andere manier om voorouders mee te specificeren is de `~`. Dit refereert ook naar de eerste ouder, dus `HEAD~` en `HEAD^` zijn gelijk. Het verschil wordt pas duidelijk als je een getal specificeert. `HEAD~2` betekent "de eerste ouder van de eerste ouder", of "de grootouder", het doorloopt de eerste ouders het aantal keren dat je specificeert. Bijvoorbeeld, in de geschiedenis die eerder getoond werd, zou `HEAD~3` het volgende resultaat geven
+De andere manier om voorouders mee te specificeren is de `~`. Dit refereert ook naar de eerste ouder, dus `HEAD~` en `HEAD^` zijn gelijk. Het verschil wordt pas duidelijk als je een getal specificeert. `HEAD~2` betekent "de eerste ouder van de eerste ouder", of "de grootouder" - het doorloopt de eerste ouders het aantal keren dat je specificeert. Bijvoorbeeld, in de geschiedenis die eerder getoond werd, zou `HEAD~3` het volgende resultaat geven
 
 	$ git show HEAD~3
 	commit 1c3618887afb5fbcbea25b7c013f4e2114448b8d
@@ -184,43 +220,43 @@ Je kunt deze syntaxen combineren: je kunt de tweede ouder van de vorige referent
 
 ### Commit reeksen ###
 
-Nu je individuele commits kunt specificeren, laten we zien hoe je reeksen van commits kunt specificeren. Dit is vooral erg bruikbaar bij het beheren van je branches; als je veel branches hebt, kan je reeks-specificaties gebruiken om vragen te beantwoorden als: "Wat voor werk zit er op deze branch dat ik nog niet in mijn hoofdbranch heb?"
+Nu je individuele commits kunt specificeren, laten we zien hoe je reeksen van commits kunt specificeren. Dit is vooral erg nuttig bij het beheren van je branches - als je veel branches hebt, kan je reeks-specificaties gebruiken om vragen te beantwoorden als: "Wat voor werk zit er op deze branch dat ik nog niet in mijn hoofdbranch gemerged heb?"
 
 #### Dubbel-punt ####
 
-De meest voorkomende reeks specificatie is de dubbel-punt syntax. Dit vraagt Git een reeks commits op te zoeken, die bereikbaar zijn van de ene commit maar niet vanuit een ander. Bijvoorbeeld, stel dat je een commit-geschiedenis hebt die eruit ziet zoals in Figuur 6-1.
+De meest voorkomende reeks specificatie is de dubbel-punt syntax. Eigenlijk vraag je hiermee aan Git een reeks commits op te zoeken, die bereikbaar zijn van de ene commit maar niet vanuit een ander. Bijvoorbeeld, stel dat je een commit-geschiedenis hebt die eruit ziet zoals in Figuur 6-1.
 
 Insert 18333fig0601.png
 Figuur 6-1. Voorbeeldgeschiedenis voor reeks-selectie.
 
-Je wilt zien wat er in je experimentele branch zit dat nog niet in je hoofdbranch gemerged is. Je kunt Git vragen om je een log te tonen van alleen die commits met `master..experiment`, wat zoveel betekent als "alle commits die bereikbaar zijn voor experiment, die niet bereikbaar zijn voor master". Om de voorbeelden kort en duidelijk te houden zal ik de letters van de commitobjecten in het diagram gebruiken in plaats van de echte log output, in de volgorde waarin ze getoond zouden worden:
+Je wilt zien wat er in je experimentele branch zit dat nog niet in je hoofdbranch gemerged is. Je kunt Git vragen om een log te tonen van alleen die commits met `master..experiment`, wat zoveel betekent als "alle commits die bereikbaar zijn voor experiment, die niet bereikbaar zijn voor master". Om de voorbeelden kort en duidelijk te houden zal ik de letters van de commitobjecten in het diagram gebruiken in plaats van de echte log output, in de volgorde waarin ze getoond zouden worden:
 
 	$ git log master..experiment
 	D
 	C
 
-Als je echter het tegenovergestelde wilt zien: alle commits in `master` die niet bereikbaar zijn in `experiment`, dan moet je de branchnamen omdraaien. `experiment..master` toont je alles in `master` wat niet bereikbaar is vanuit `experiment`:
+Als je echter het tegenovergestelde wilt zien - alle commits in `master` die niet in `experiment` zitten - dan moet je de branchnamen omdraaien. `experiment..master` toont je alles in `master` wat niet bereikbaar is vanuit `experiment`:
 
 	$ git log experiment..master
 	F
 	E
 
-Dit is handig als je de `experiment` branch up to date wilt houden en vast wilt zien wat je op het punt staat te mergen. Een ander veel voorkomend gebruik van deze syntax is zien wat je op het punt staat naar een remote de pushen:
+Dit is handig als je de `experiment` branch up to date wilt houden en alvast wilt zien wat je op het punt staat te mergen. Een ander veel voorkomend gebruik van deze syntax is zien wat je op het punt staat naar een remote de pushen:
 
 	$ git log origin/master..HEAD
 
-Dit commando toont je alle commits in je huidige branch, die niet in de `master` branch op je remote `origin` zitten. Als je een `git push` uitvoert, en je huidige branch volgt de `origin/master`, dan zijn de commits die getoond worden door `git log origin/master..HEAD` de commits die verstuurd zullen worden naar de server.
-Je kunt ook één kant van de syntax weglaten om Git de HEAD laten aannemen. Bijvoorbeeld, je krijgt dezelfde resultaten als in het vorige voorbeeld door `git log origin/master..` te typen; Git vult HEAD in als er één kant ontbreekt.
+Dit commando toont je alle commits in je huidige branch, die niet in de `master` branch op de remote `origin` zitten. Als je een `git push` uitvoert, en je huidige branch volgt de `origin/master`, dan zijn de commits die getoond worden door `git log origin/master..HEAD` de commits die verstuurd zullen worden naar de server.
+Je kunt ook één kant van de syntax weglaten om Git de HEAD laten aannemen. Bijvoorbeeld, je krijgt dezelfde resultaten als in het vorige voorbeeld door `git log origin/master..` te typen - Git vult HEAD in als er één kant ontbreekt.
 
-#### Meerdere punten ####
+#### Dubbele punten ####
 
-De syntax met de dubbel-punt is makkelijk als een afkorting, maar misschien wil je meer dan twee branches specificeren om je revisie aan te geven, zoals het zien welke commits in één van een serie branches zit, die nog niet in de branch zit waar je nu op zit. Git laat je dit doen door of het `^` karakter te gebruiken, of `--not` voor iedere referentie waarvan je de bereikbare commits niet wilt zien. Dus deze drie commando's zijn gelijk:
+De syntax met de dubbel-punt is makkelijk als een afkorting, maar misschien wil je meer dan twee branches specificeren om je revisie aan te geven, zoals het zien welke commits in één van de branches in een reeks zitten, die nog niet in de branch zitten waar je nu op werkt. Git laat je dit doen door of het `^` karakter of `--not`, te gebruiken voor iedere referentie waarvan je de bereikbare commits niet wilt zien. Dus deze drie commando's zijn gelijk:
 
 	$ git log refA..refB
 	$ git log ^refA refB
 	$ git log refB --not refA
 
-Dit is prettig omdat met deze syntax je meer dan twee referenties in je vraag kunt specificeren, wat je niet met de dubbel punt syntax kan. Bijvoorbeeld, als je alle commits wilt zien die bereikbaar zijn vanuit `refA` of `refB`, maar niet vanuit `refC`, dan kun je één van deze intypen:
+Dit is prettig omdat met deze syntax je meer dan twee referenties in je vraag kunt specificeren, wat je niet met de dubbel punt syntax kan doen. Bijvoorbeeld, als je alle commits wilt zien die bereikbaar zijn vanuit `refA` of `refB`, maar niet vanuit `refC`, dan kun je één van deze intypen:
 
 	$ git log refA refB ^refC
 	$ git log refA refB --not refC
@@ -252,7 +288,7 @@ Met deze tools, kun je Git eenvoudiger laten weten welke commit of commits je wi
 
 ## Interactief stagen ##
 
-Bij Git zitten een aantal scripts, die sommige commandline taken makkelijker maken. Hier zul je een aantal interactieve commando's zien, die je kunnen helpen om je commits zo te maken dat ze alleen bepaalde combinaties en delen van bestanden bevatten. Deze tools zijn erg nuttig als je een serie bestanden aanpast en dan besluit dat je deze veranderingen in een aantal gefocuste commits wilt hebben in plaats van één grote rommelige commit. Op deze manier ben je er zeker van dat je commits logische aparte wijzigingensets zijn en makkelijk gereviewed kunnen worden door je mede-ontwikkelaars.
+Bij Git worden een aantal scripts geleverd, die sommige commandline taken makkelijker maken. Hier zul je een aantal interactieve commando's zien, die je kunnen helpen om je commits zo samen te stellen dat ze alleen bepaalde combinaties en delen van bestanden bevatten. Deze tools zijn erg nuttig als je een reeks bestanden aanpast en dan besluit dat je deze wijzigingen in een aantal gefocuste commits wilt hebben in plaats van één grote rommelige commit. Op deze manier ben je er zeker van dat je commits logische aparte wijzigingensets zijn en makkelijk gereviewed kunnen worden door je mede-ontwikkelaars.
 Als je `git add` uitvoert met de `-i` of `--interactive` optie, dan schakelt Git over naar een interactieve shell modus, waarbij zoiets als dit getoond wordt:
 
 	$ git add -i
@@ -266,9 +302,9 @@ Als je `git add` uitvoert met de `-i` of `--interactive` optie, dan schakelt Git
 	  5: patch      6: diff        7: quit       8: help
 	What now>
 
-Je kunt zien dat dit commando je een heel andere kijk op je staging area geeft: eigenlijk dezelfde informatie die je krijgt met het `git status` commando, maar dan compacter en meer informatief. Het toont links de wijzigingen die je gestaged hebt, en de niet gestagede wijzigingen rechts.
+Je kunt zien dat dit commando je een heel andere kijk op je staging area geeft - eigenlijk dezelfde informatie die je krijgt met het `git status` commando, maar dan compacter en meer informatief. Het toont links de wijzigingen die je gestaged hebt, en de niet gestagede wijzigingen rechts.
 
-Hierna volgt een commando-sectie. Hier kun je een aantal dingen doen, staging bestanden toevoegen, bestanden unstagen, delen van bestanden stagen, ongevolgde bestanden toevoegen, en diffs zien van wat gestaged is.
+Hierna volgt een commando-sectie. Hier kun je een aantal dingen doen waaronder bestanden stagen, bestanden unstagen, delen van bestanden stagen, ungetrackte bestanden toevoegen, en diffs zien van wat gestaged is.
 
 ### Bestanden stagen en unstagen ###
 
@@ -290,7 +326,7 @@ Om de TODO en index.html bestanden te stagen, kun je de getallen typen:
 	  3:    unchanged        +5/-1 lib/simplegit.rb
 	Update>>
 
-De `*` naast ieder bestand geeft aan dat het bestand geselecteerd staat om gestaged te worden. Als je Enter indrukt na niets getypt te hebben op de `Update>>` prompt, dan zal Git alles wat geselecteerd staat pakken en voor je stagen:
+De `*` naast ieder bestand geeft aan dat het bestand geselecteerd is om gestaged te worden. Als je Enter indrukt na niets getypt te hebben op de `Update>>` prompt, dan zal Git alles wat geselecteerd staat pakken en voor je stagen:
 
 	Update>>
 	updated 2 paths
@@ -304,7 +340,7 @@ De `*` naast ieder bestand geeft aan dat het bestand geselecteerd staat om gesta
 	  2:        +1/-1      nothing index.html
 	  3:    unchanged        +5/-1 lib/simplegit.rb
 
-Nu kun je zien dat de TODO en index.html bestanden gestaged zijn, en het simplegit.rb bestand nog unstaged is. Als je het TODO bestand wilt unstagen op dit punt, dan gebruik je de `3` of `r` (voor revert) optie:
+Nu kun je zien dat de TODO en index.html bestanden gestaged zijn, en het simplegit.rb bestand nog steeds unstaged is. Als je het TODO bestand nu wilt unstagen, dan gebruik je de `3` of `r` (voor revert) optie:
 
 	*** Commands ***
 	  1: status     2: update      3: revert     4: add untracked
@@ -333,7 +369,7 @@ Als je nu nog eens naar je Git status kijkt, kun je zien dat je het TODO bestand
 	  2:        +1/-1      nothing index.html
 	  3:    unchanged        +5/-1 lib/simplegit.rb
 
-Om de diff te zien van wat je gestaged hebt, kun je het `6` of `d` (voor diff) commando gebruiken. Het toont je een lijst van je gestagede bestanden, en je kunt diegenen selecteren waarvan je de gestagede diff wilt zien. Dit is vergelijkbaar met het specificeren van `git diff --cached` op de commando regel:
+Om de diff te zien van wat je gestaged hebt, kun je het `6` of `d` (voor diff) commando gebruiken. Het toont je een lijst van je gestagede bestanden, en je kunt de bestanden selecteren waarvan je de gestagede diff wilt zien. Dit is vergelijkbaar met het specificeren van `git diff --cached` op de commando regel:
 
 	*** Commands ***
 	  1: status     2: update      3: revert     4: add untracked
@@ -355,7 +391,7 @@ Om de diff te zien van wat je gestaged hebt, kun je het `6` of `d` (voor diff) c
 
 	 <script type="text/javascript">
 
-Met deze basiscommando's kun je de interactieve toevoegmodus gebruiken om een iets makkelijker manier met je staging area om te gaan.
+Met deze simpele commando's kun je de interactieve toevoegmodus gebruiken om op een iets eenvoudigere manier met je staging area om te gaan.
 
 ### Patches stagen ###
 
@@ -393,7 +429,7 @@ Hier heb je erg veel opties. Door `?` te typen krijg je een lijst met wat je kun
 	e - manually edit the current hunk
 	? - print help
 
-Over het algemeen zul je `y` of `n` typen als je ieder stuk wilt stagen, maar voor bepaalde bestanden ze allemaal ineens te stagen, of voor een bepaald stuk de beslissing uit te stellen kan ook behulpzaam zijn. Als je een gedeelte van het bestand wilt stagen en een ander gedeelte unstaged wilt laten, dan zal je status output er zo uitzien:
+Over het algemeen zal je `y` of `n` typen als je elke homp (hunk) wilt stagen, maar voor bepaalde bestanden ze allemaal stagen, of voor een bepaalde hunk de beslissing uit stellen kan ook behulpzaam zijn. Als je een gedeelte van het bestand wilt stagen en een ander gedeelte unstaged wilt laten, dan zal je status output er zo uitzien:
 
 	What now> 1
 	           staged     unstaged path
@@ -407,13 +443,13 @@ Tot slot hoef je niet in de interactieve toevoeg modus te zijn om het gedeelteli
 
 ## Stashen ##
 
-Vaak als je aan een deel van je project hebt zitten werken, zijn de dingen in een rommelige staat en wil je van branch veranderen om aan iets anders te werken. Het probleem is dat je geen halfklaar werk wilt committen, alleen maar om later verder te kunnen gaan vanaf hetzelfde punt. Het antwoord op dit probleem is het `git stash` commando.
+Vaak, als je aan een deel van je project hebt zitten werken, zijn de dingen in een rommelige staat en wil je van branch veranderen om aan iets anders te werken. Het probleem is dat je geen halfklaar werk wilt committen, alleen maar om later verder te kunnen gaan vanaf hetzelfde punt. Het oplossing voor dit probleem is het `git stash` commando.
 
-Stashen pakt de vervuilde status van je werkdirectory, dat wil zeggen: je gewijzigde tracked bestanden en gestagede wijzigingen, en bewaart het op een stapel onafgemaakte wijzigingen die je op ieder tijdstip opnieuw kunt toepassen.
+Stashen (wegstoppen) pakt de vervuilde status van je werkdirectory - dat wil zeggen: je gewijzigde getrackte bestanden en gestagede wijzigingen, en bewaart het op een stapel onafgemaakte wijzigingen die je op ieder tijdstip opnieuw kunt toepassen.
 
 ### Je werk stashen ###
 
-Ter demonstratie, ga je project in en begint met werken aan een paar bestanden en misschien stage je een van de wijzigingen. Als je `git status` uitvoert, kun je de vervuilde status zien:
+Om dit te demonstreren, ga je project in en begin met werken aan een paar bestanden en misschien stage je een van de wijzigingen. Als je `git status` uitvoert, kun je de vervuilde status zien:
 
 	$ git status
 	# On branch master
@@ -428,7 +464,7 @@ Ter demonstratie, ga je project in en begint met werken aan een paar bestanden e
 	#      modified:   lib/simplegit.rb
 	#
 
-Nu wil je van branch veranderen, maar je wilt hetgeen je aan hebt zitten werken nog niet committen, dus ga je de wijzigingen stashen. Om een nieuwe stash op je stapel te duwen, voer je `git stash` uit:
+Nu wil je van branch veranderen, maar je wilt hetgeen je aan hebt zitten werken nog niet committen, dus je gaat de wijzigingen stashen. Om een nieuwe stash op de stapel te zetten, voer je `git stash` uit:
 
 	$ git stash
 	Saved working directory and index state \
@@ -442,7 +478,7 @@ Je werkdirectory is schoon:
 	# On branch master
 	nothing to commit (working directory clean)
 
-Op dit punt kun je makkelijk van branch wisselen en ergens anders aan werken, je wijzigingen zijn opgeslagen op je stapel. Om te zien welke stashes je opgeslagen hebt, kun je `git stash list` gebruiken:
+Nu kan je eenvoudig van branch wisselen en ergens anders aan werken, je wijzigingen zijn opgeslagen op de stapel. Om te zien welke stashes je opgeslagen hebt, kun je `git stash list` gebruiken:
 
 	$ git stash list
 	stash@{0}: WIP on master: 049d078 added the index file
@@ -462,7 +498,7 @@ In dit geval waren er twee stashes al eerder opgeslagen, dus heb je toegang tot
 
 Je kunt zien dat Git opnieuw de bestanden wijzigt die je uncommitte toen je de stash opsloeg. In dit geval had je een schone werkdirectory toen je de stash probeerde toe te passen, en dat je probeerde deze op dezelfde branch toe te passen als waar je hem van opgeslagen hebt. Maar het hebben van een schone werkdirectory en het toepassen op dezelfde branch zijn niet noodzakelijk om een stash succesvol toe te kunnen passen. Je kunt een stash op één branch opslaan, later naar een andere branch omschakelen, en daar opnieuw de wijzigingen toe proberen te passen. Je kunt ook gewijzigde en uncommitted bestanden in je werkdirectory hebben wanneer je een stash probeert toe te passen, Git geeft merge conflicten aan als iets niet meer netjes toe te passen is.
 
-De wijzigingen aan je bestanden zijn opnieuw toegepast, maar het bestand dat je eerder gestaged had, is niet opnieuw gestaged. Om dat te doen moet je het `git stash apply` commando met de `--index` optie uitvoeren om het commando te vertellen de gestagede wijzigingen opnieuw proberen toe te passen. Als je dat had uitgevoerd, dan zou je weer op je originele uitgangspunt zijn uitgekomen:
+De wijzigingen aan je bestanden zijn opnieuw toegepast, maar het bestand dat je eerder gestaged had is niet opnieuw gestaged. Om dat te doen moet je het `git stash apply` commando met de `--index` optie uitvoeren om het commando te vertellen de gestagede wijzigingen opnieuw proberen toe te passen. Als je dat had uitgevoerd, dan zou je weer op je originele uitgangspunt zijn uitgekomen:
 
 	$ git stash apply --index
 	# On branch master
@@ -477,7 +513,7 @@ De wijzigingen aan je bestanden zijn opnieuw toegepast, maar het bestand dat je
 	#      modified:   lib/simplegit.rb
 	#
 
-De apply optie probeert alleen het gestashete werk toe te passen, je blijft het op je stapel behouden. Om het te verwijderen kun je `git stash drop` uitvoeren, met de naam van de stash die je wilt verwijderen:
+De apply optie probeert alleen het gestashete werk toe te passen - je blijft op de stapel behouden. Om het te verwijderen kun je `git stash drop` uitvoeren, met de naam van de stash die je wilt verwijderen:
 
 	$ git stash list
 	stash@{0}: WIP on master: 049d078 added the index file
@@ -486,7 +522,8 @@ De apply optie probeert alleen het gestashete werk toe te passen, je blijft het
 	$ git stash drop stash@{0}
 	Dropped stash@{0} (364e91f3f268f0900bc3ee613f9f733e82aaed43)
 
-Je kunt ook `git stash pop` uitvoeren om de stash toe te passen en deze direct van je stapel te verwijderen.
+Je kunt ook `git stash pop` uitvoeren om de stash toe te passen en deze direct van de stapel te verwijderen.
+
 ### Een stash ont-toepassen ###
 
 In sommige situaties zou het kunnen voorkomen dat je gestashde wijzigingen wilt toepassen, wat werk doen en dan de wijzigingen die van de stash waren gekomen ont-toepassen. Git heeft niet zoiets als een `stash unapply` commando, maar het is mogelijk om het effect te bereiken door simpelweg de patch op te halen die bij een stash hoort, en deze in zijn achteruit toe te passen:
@@ -497,7 +534,7 @@ Nogmaals: als je geen stash specificeert gaat Git van de meest recente stash uit
 
     $ git stash show -p | git apply -R
 
-Wellicht wil je een alias maken en effectief een `stash-unapply` commando aan je git toevoegen. Als voorbeeld:
+Wellicht wil je een alias maken en effectief een `stash-unapply` commando aan je Git toevoegen. Bijvoorbeeld:
 
     $ git config --global alias.stash-unapply '!git stash show -p | git apply -R'
     $ git stash
@@ -506,7 +543,7 @@ Wellicht wil je een alias maken en effectief een `stash-unapply` commando aan je
 
 ### Een branch van een stash maken ###
 
-Als je wat werk stashed, het daar poosje laat liggen, en doorwerkt op de branch waarvan je het werk gestashed hebt, dan kun je een probleem krijgen met het werk opnieuw toe te passen. Als het toepassen een bestand probeert te wijzigen dat je sindsdien gewijzigd hebt krijg je een merge conflict en zul je dat moeten proberen oplossen. Als je een eenvoudiger manier wilt hebben om je gestashde wijzigingen opnieuw te testen, kun je `git stash branch` uitvoeren. Dit zal een nieuwe branch voor je aanmaken, de commit waar je op zat toen je het werk stashte uitchecken, je werk opnieuw toepassen en dan de stash droppen als het succesvol is toegepast:
+Als je wat werk stashed, het daar poosje laat liggen, en doorwerkt op de branch waarvan je het werk gestashed hebt, dan kun je een probleem krijgen met het opnieuw toe passen van dat werk. Als het toepassen een bestand probeert te wijzigen dat je sindsdien gewijzigd hebt krijg je een merge conflict en zul je dat moeten proberen oplossen. Als je een eenvoudiger manier wilt hebben om je gestashde wijzigingen opnieuw te testen, kun je `git stash branch` uitvoeren. Dit zal een nieuwe branch voor je aanmaken, de commit waar je op zat toen je het werk stashte uitchecken, je werk opnieuw toepassen en dan de stash droppen als het succesvol is toegepast:
 
 	$ git stash branch testchanges
 	Switched to a new branch "testchanges"
@@ -527,13 +564,13 @@ Dit is een prettige manier om gestashed werk eenvoudig terug te halen en eraan t
 
 ## Geschiedenis herschrijven ##
 
-Vaak zal je, als je met Git werkt, je commit geschiedenis om een of andere reden willen aanpassen. Eén van de mooie dingen van Git is dat het je in staat stelt om beslissingen op het allerlaatste moment te maken. Je kunt bepalen welke bestanden in welke commits gaan vlak voordat je commit gebruik makende van de staging area, je kunt besluiten dat je toch nog niet aan iets had willen werken met het stash commando en je kunt commits herschrijven ook al zijn ze al gebeurd, waardoor het lijkt alsof ze op een andere manier gebeurd zijn. Dit kan bijvoorbeeld de volgorde van de commits zijn, berichten of bestanden in een commit wijzigen, commits samenvoegen (squashen) of opsplitsen, of complete commits weghalen. En dat allemaal voordat je jouw werk met anderen deelt.
+Vaak zal je, als je met Git werkt, je commit geschiedenis om een of andere reden willen aanpassen. Één van de mooie dingen van Git is dat het je in staat stelt om beslissingen op het laatst mogelijke moment te maken. Je kunt bepalen welke bestanden in welke commits gaan vlak voordat je commit, door middel van de staging area, je kunt besluiten dat je toch nog niet aan iets had willen beginnen met het stash commando en je kunt commits herschrijven ook al zijn ze al gebeurd, waardoor het lijkt alsof ze op een andere manier gebeurd zijn. Dit kan bijvoorbeeld de volgorde van de commits zijn, berichten of bestanden in een commit wijzigen, commits samenpersen(squashen) of opsplitsen, of complete commits weghalen - en dat allemaal voordat je jouw werk met anderen deelt.
 
-In deze paragraaf zal je leren hoe je deze handige taken uitvoert, zodat je je commit geschiedenis er uit kunt laten zien zoals jij dat wilt, voordat je het met anderen deelt.
+In deze paragraaf zal je leren hoe je deze handige taken uitvoert, zodat je jouw commit geschiedenis er uit kunt laten zien zoals jij dat wilt, voordat je het met anderen deelt.
 
 ### De laatste commit veranderen ###
 
-De laatste commit veranderen is waarschijnlijk de meest voorkomende geschiedenis wijziging die je zult doen. Vaak wil je twee basale dingen aan je laatste commit wijzigen: het commit bericht, of de snapshot dat je zojuist opgeslagen hebt wijzigen door het toevoegen, wijzigen of weghalen van bestanden.
+De laatste commit veranderen is waarschijnlijk de meest voorkomende geschiedenis wijziging die je zult doen. Vaak wil je twee basale dingen aan je laatste commit wijzigen: het commit bericht, of de snapshot, dat je zojuist opgeslagen hebt, wijzigen door het toevoegen, wijzigen of weghalen van bestanden.
 
 Als je alleen je laatste commit bericht wilt wijzigen, dan is dat heel eenvoudig:
 
@@ -541,7 +578,7 @@ Als je alleen je laatste commit bericht wilt wijzigen, dan is dat heel eenvoudig
 
 Dat plaatst je in de teksteditor met je laatste commit bericht erin, klaar voor je om het bericht te wijzigen. Als je opslaat en de editor sluit, dan schrijft de editor een nieuwe commit met dat bericht en maakt dat je laatste commit.
 
-Als je hebt gecommit en daarna wil je het snapshot dat je gecommit hebt wijzigen, door het toevoegen of wijzigen van bestanden, misschien omdat je vergeten was een nieuw bestand toe te voegen toen je committe, gaat het proces vergelijkbaar. Je staged de wijzigingen die je wilt door een bestand te wijzigen en `git add` er op uit te voeren, of `git rm` op een gevolgd bestand, en de daaropvolgende `git commit --amend` pakt je huidige staging area en maakt dat het snapshot voor de nieuwe commit.
+Als je hebt gecommit en daarna wil je het snapshot dat je gecommit hebt wijzigen, door het toevoegen of wijzigen van bestanden, misschien omdat je vergeten was een nieuw bestand toe te voegen toen je committe, gaat het proces vergelijkbaar. Je staged de wijzigingen die je wilt door een bestand te wijzigen en `git add` er op uit te voeren, of `git rm` op een getrackt bestand, en de daaropvolgende `git commit --amend` pakt je huidige staging area en maakt dat het snapshot voor de nieuwe commit.
 
 Je moet wel oppassen met deze techniek, omdat het amenden de SHA-1 van de commit wijzigt. Het is vergelijkbaar met een kleine rebase: niet je laatste commit wijzigen als je die al gepusht hebt.
 
@@ -553,7 +590,7 @@ Bijvoorbeeld, als je de laatste drie commit berichten wilt veranderen, of een va
 
 	$ git rebase -i HEAD~3
 
-Onthoud, nogmaals, dat dit een rebase commando is; iedere commit in de reeks `HEAD~3..HEAD` zal worden herschreven, of je het bericht wijzigt of niet. Voeg geen commit toe die je al naar een centrale server gepushed hebt; als je dit doet breng je andere gebruikers in de war omdat je ze een alternatieve versie van dezelfde wijziging te geeft.
+Onthoud, nogmaals, dat dit een rebase commando is - iedere commit in de reeks `HEAD~3..HEAD` zal worden herschreven, of je het bericht nu wijzigt of niet. Voeg geen commit toe die je al naar een centrale server gepusht hebt; als je dit doet breng je andere gebruikers in de war omdat je ze een alternatieve versie van dezelfde wijziging te geeft.
 
 Dit commando uitvoeren geeft je een lijst met commits in je tekst editor die er ongeveer zo uit ziet:
 
@@ -581,7 +618,7 @@ Het is belangrijk om op te merken dat deze commits in de tegengestelde volgorde
 
 Merk de omgekeerde volgorde op. De interactieve rebase geeft je een script dat het gaat uitvoeren. Het zal beginnen met de commit die je specificeert op de commando regel (`HEAD~3`) en de wijzigingen in elk van deze commits van voor naar achter opnieuw afspelen. Het toont de oudste het eerst in plaats van de nieuwste, omdat dat deze de eerste is die zal worden afgespeeld.
 
-Je moet het script op zodanige manier wijzigen dat het stopt bij de commit die je wilt wijzigen. Om dat te doen moet je het woord "pick" veranderen in het woord "edit" voor elke commit waarbij je het script wilt laten stoppen. Bijvoorbeeld, om alleen het derde commit bericht te wijzigen verander je het bestand zodat het er zo uitziet:
+Je moet het script zodanig aanpassen dat het stopt bij de commit die je wilt wijzigen. Om dat te doen moet je het woord "pick" veranderen in het woord "edit" voor elke commit waarbij je het script wilt laten stoppen. Bijvoorbeeld, om alleen het derde commit bericht te wijzigen verander je het bestand zodat het er zo uitziet:
 
 	edit f7f3f6d changed my name a bit
 	pick 310154e updated README formatting and added blame
@@ -668,7 +705,7 @@ Een commit opsplitsen zal een commit ongedaan maken, en dan net zo vaak gedeelte
 	edit 310154e updated README formatting and added blame
 	pick a5f4a0d added cat-file
 
-Als je opslaat en de editor verlaat, spoelt Git terug naar de parent van de eerste commit in de lijst, past de eerste commit toe (`f7f3f6d`), past de tweede te (`310154e`), en zet je dan in de console. Daar kan je een gemengde reset doen van die commit met `git reset HEAD^` , wat effectief de commit terugdraait en de gewijzigde bestanden unstaged laat. Nu kan je de wijzigingen die gereset zijn nemen en er meerdere commits van maken. Eenvoudigweg bestanden stagen en committen tot je meerdere commits hebt, en `git rebase --continue` uitvoeren zodra je klaar bent:
+Als je opslaat en de editor verlaat, spoelt Git terug naar de parent van de eerste commit in de lijst, past de eerste commit toe (`f7f3f6d`), past de tweede toe (`310154e`), en zet je dan in de console. Daar kan je een gemengde reset doen van die commit met `git reset HEAD^` , wat effectief de commit terugdraait en de gewijzigde bestanden unstaged laat. Nu kan je de wijzigingen die gereset zijn nemen en er meerdere commits van maken. Eenvoudigweg bestanden stagen en committen tot je meerdere commits hebt, en dan `git rebase --continue` uitvoeren zodra je klaar bent:
 
 	$ git reset HEAD^
 	$ git add README
@@ -685,37 +722,37 @@ Git zal de laatste commit (`a5f4a0d`) in het script toepassen, en je geschiedeni
 	35cfb2b updated README formatting
 	f3cc40e changed my name a bit
 
-Nogmaals, dit veranderd alle SHA's van alle commits in de lijst, dus zorg er voor dat er geen commit in die lijst zit die je al naar een gedeeld repository gepushed hebt.
+Nogmaals, dit verandert alle SHA's van alle commits in de lijst, dus zorg er voor dat er geen commit in die lijst zit die je al naar een gedeelde repository gepusht hebt.
 
-### De nucleaire optie: filter-branch ###
+### De optie met atoomkracht: filter-branch ###
 
-Er is nog een geschiedenis-herschrijvende optie, die je kunt gebruiken als je een groter aantal commits moet herschrijven in een scriptbare manier. Bijvoorbeeld, het globaal veranderen van je e-mail adres of een bestand uit iedere commit verwijderen. Het commando heet `filter-branch` en het kan grote gedeelten van je geschiedenis herschrijven, dus je moet het niet gebruiken tenzij je project nog niet publiekelijk is gemaakt, en andere mensen nog geen werk hebben gebaseerd op jouw commits die je op het punt staat te herschrijven. Maar het kan heel handig zijn. Je zult een paar gebruikelijke toepassingen leren zodat je een idee kunt krijgen waar het toe in staat is.
+Er is nog een geschiedenis-herschrijvende optie, die je kunt gebruiken als je een groter aantal commits moet herschrijven op een gescripte manier. Bijvoorbeeld, het globaal veranderen van je e-mail adres of een bestand uit iedere commit verwijderen. Het commando heet `filter-branch` en het kan grote gedeelten van je geschiedenis herschrijven, dus je moet het niet gebruiken tenzij je project nog niet publiekelijk is gemaakt, en andere mensen nog geen werk hebben gebaseerd op jouw commits die je op het punt staat te herschrijven. Maar het kan heel handig zijn. Je zult een paar gebruikelijke toepassingen zien zodat je een idee krijgt waar het toe in staat is.
 
 #### Een bestand uit iedere commit verwijderen ####
 
-Dit gebeurt vrij regelmatig. Iemand voegt per ongeluk een enorm binair bestand toe met een achteloze `git add .`, en je wilt het overal weghalen. Misschien heb je per ongeluk een bestand dat een wachtwoord bevat gecommit, en je wilt dat project open source maken. `filter-branch` is het tool dat je waarschijnlijk wilt gebruiken om je hele geschiedenis schoon te poetsen. Om een bestand genaamd passwords.txt uit je hele geschiedenis weg te halen, kun je de `--tree-filter` optie toevoegen aan `filter-branch`:
+Dit gebeurt vrij regelmatig. Iemand voegt per ongeluk een enorm binair bestand toe met een achteloze `git add .`, en je wilt het overal weghalen. Misschien heb je per ongeluk een bestand dat een wachtwoord bevat gecommit, en je wilt dat project open source maken. `filter-branch` is dan de tool dat je wilt gebruiken om je hele geschiedenis schoon te poetsen. Om een bestand met de naam passwords.txt uit je hele geschiedenis weg te halen, kun je de `--tree-filter` optie toevoegen aan `filter-branch`:
 
 	$ git filter-branch --tree-filter 'rm -f passwords.txt' HEAD
 	Rewrite 6b9b3cf04e7c5686a9cb838c3f36a8cb6a0fc2bd (21/21)
 	Ref 'refs/heads/master' was rewritten
 
-De `--tree-filter` optie voert het gegeven commando uit na elke checkout van het project, en commit de resultaten weer. In dit geval verwijder je een bestand genaamd passwords.txt van elke snapshot, of het bestaat of niet. Als je alle per ongeluk toegevoegde editor backup bestanden wilt verwijderen, kun je bijvoorbeeld dit uitvoeren `git filter-branch --tree-filter "find * -type f -name '*~' -delete" HEAD`.
+De `--tree-filter` optie voert het gegeven commando uit na elke checkout van het project, en commit de resultaten weer. In dit geval verwijder je een bestand genaamd passwords.txt van elke snapshot, of het bestaat of niet. Als je alle per ongeluk toegevoegde editor backup bestanden wilt verwijderen, kun je bijvoorbeeld dit uitvoeren `git filter-branch --tree-filter "rm -f *~" HEAD`.
 
-Je zult Git bomen en commits zien herschrijven en dan de branch wijzer naar het einde zien verplaatsen. Het is over het algemeen een goed idee om dit in een test branch te doen, en dan je master branch te hard-resetten nadat je gecontroleerd hebt dat de uitkomst echt is als je het wilt hebben. Om `filter-branch` op al je branches uit te voeren, kun je `--all` aan het commando meegeven.
+Je zult Git objectbomen en commits zien herschrijven en op het eind de branch wijzer zien verplaatsen. Het is over het algemeen een goed idee om dit in een test branch te doen, en dan je master branch te hard-resetten nadat je gecontroleerd hebt dat de uitkomst echt is als je het wilt hebben. Om `filter-branch` op al je branches uit te voeren, moet je `--all` aan het commando meegeven.
 
 #### Een subdirectory de nieuwe root maken ####
 
-Stel dat je een import vanuit een ander versiebeheersysteem hebt gedaan, en subdirectories hebt die niet zinnig zijn (trunk, tags enzovoort). Als je de `trunk` subdirectory de nieuwe root van het project wilt maken voor iedere commit, kan `filter-branch` je daar ook mee helpen:
+Stel dat je een import vanuit een ander versiebeheersysteem hebt gedaan, en subdirectories hebt die niet zinnig zijn (trunk, tags, enzovoort). Als je de `trunk` subdirectory de nieuwe root van het project wilt maken voor elke commit, kan `filter-branch` je daar ook mee helpen:
 
 	$ git filter-branch --subdirectory-filter trunk HEAD
 	Rewrite 856f0bf61e41a27326cdae8f09fe708d679f596f (12/12)
 	Ref 'refs/heads/master' was rewritten
 
-Nu is de nieuwe project root wat het elke keer was in de `trunk` subdirectory. Git zal ook automatisch commits verwijderen die geen effect hadden op de subdirectory.
+Nu is de nieuwe project root elke keer de inhoud van de `trunk` subdirectory. Git zal ook automatisch commits verwijderen die geen betrekking hadden op die subdirectory.
 
 #### E-mail adressen globaal veranderen ####
 
-Een ander veel voorkomend geval is dat je vergeten bent om `git config` uit te voeren om je naam en e-mail adres in te stellen voordat je bent begonnen met werken, of misschien wil je een project op het werk open source maken en al je werk e-mail adressen veranderen naar je persoonlijke adres. Je kunt zowiezo je e-mail adressen in meerdere commits ook in een keer veranderen met `filter-branch`. Je moet wel oppassen dat je alleen die e-mail adressen aan past die van jou zijn, dus gebruik je `--commit-filter`:
+Een ander veel voorkomend geval is dat je vergeten bent om `git config` uit te voeren om je naam en e-mail adres in te stellen voordat je begon met werken, of misschien wil je een project op het werk open source maken en al je werk e-mail adressen veranderen naar je persoonlijke adres. Hoe dan ook, je kunt e-mail adressen in meerdere commits ook in één klap veranderen met `filter-branch`. Je moet wel oppassen dat je alleen die e-mail adressen aanpast die van jou zijn, dus gebruik je `--commit-filter`:
 
 	$ git filter-branch --commit-filter '
 	        if [ "$GIT_AUTHOR_EMAIL" = "schacon@localhost" ];
@@ -727,15 +764,15 @@ Een ander veel voorkomend geval is dat je vergeten bent om `git config` uit te v
 	                git commit-tree "$@";
 	        fi' HEAD
 
-Dit gaat werkt alle commits door en herschrijft ze zodat het jouw nieuwe adres bevat. Om dat commits de SHA-1 waarde van hun ouders bevatten, zal dit commando iedere commit SHA in jouw geschiedenis veranderen, niet alleen diegene die het gezochte e-mailadres bevatten.
+Dit gaat alle commits door en herschrijft ze zodat het jouw nieuwe adres bevat. Om dat commits de SHA-1 waarde van hun ouders bevatten, zal dit commando iedere commit SHA in jouw geschiedenis veranderen, niet alleen diegene die het gezochte e-mailadres bevatten.
 
 ## Debuggen met Git ##
 
 Git levert ook een paar tools om je problemen te helpen debuggen in je projecten. Omdat Git is ontworpen te werken met bijna elk type project zijn deze tools erg generiek, maar ze kunnen je vaak helpen een bug of schuldige te vinden als de dingen verkeerd gaan.
 
-### Bestandsannotatie ###
+### Aantekenen van bestanden ###
 
-Als je een bug in je code traceert en wilt weten wanneer het was geïntroduceerd en waarom, dan is bestandsannotatie vaak je beste tool. Het toont je welke commit de laatste was een willekeurige regel in een bestand wijzigde. Dus als je ziet dat een methode in je code bugs bevat, dan kun je het bestand annoteren met `git blame` om te zien wanneer een regel van de methode voor het laatst aangepast was en door wie. Dit voorbeeld gebruikt de `-L` optie om de output te beperken tot regel 12 tot en met 22:
+Als je een bug in je code traceert en wilt weten wanneer het was geïntroduceerd en waarom, dan is bestands aantekenen vaak je beste methode. Het toont je welke commit de laatste was die iets wijzigde in een bepaald bestand. Dus als je ziet dat een methode in je code bugs bevat, dan kun je het bestand aantekenen met `git blame` om te zien wanneer een regel van de methode voor het laatst aangepast was en door wie. Dit voorbeeld gebruikt de `-L` optie om de output te beperken tot regel 12 tot en met 22:
 
 	$ git blame -L 12,22 simplegit.rb
 	^4832fe2 (Scott Chacon  2008-03-15 10:31:28 -0700 12)  def show(tree = 'master')
@@ -750,9 +787,9 @@ Als je een bug in je code traceert en wilt weten wanneer het was geïntroduceerd
 	42cf2861 (Magnus Chacon 2008-04-13 10:45:01 -0700 21)   command("git blame #{path}")
 	42cf2861 (Magnus Chacon 2008-04-13 10:45:01 -0700 22)  end
 
-Merk op dat het eerste veld de gedeeltelijke SHA-1 van de commit is, die als laatste die regel gewijzigd heeft. De volgende twee velden zijn waarden die gehaald zijn uit die commit: de naam van de auteur en de datum van die commit, zodat je makkelijk kunt zien wie die regel aangepast heeft en wanneer. Daarna komt het regelnummer en de inhoud van dat bestand. Let ook op de `^4832fe2` commit regels, die aangeven dat die regels in de allereerste commit van dat bestand zaten. Die commit is gedaan toen dit bestand voor het eerst was toegevoegd aan dit project, en die regels zijn sindsdien ongewijzigd gebleven. Dit is een wat verwarrend, want nu heb je minstens drie manieren gezien waarop Git het `^` symbool gebruikt om een SHA van een commit aan te passen, maar dit is wat het hier betekent.
+Merk op dat het eerste veld de gedeeltelijke SHA-1 van de commit is die als laatste die regel gewijzigd heeft. De volgende twee velden zijn waarden die gehaald zijn uit die commit: de naam van de auteur en de datum van die commit, zodat je makkelijk kunt zien wie die regel aangepast heeft en wanneer. Daarna komt het regelnummer en de inhoud van dat bestand. Let ook op de `^4832fe2` commit regels, die aangeven dat die regels in de allereerste commit van dat bestand zaten. Die commit is gedaan toen dit bestand voor het eerst was toegevoegd aan dit project, en die regels zijn sindsdien ongewijzigd gebleven. Dit is ietwat wat verwarrend, want nu heb je minstens drie manieren gezien waarop Git het `^` symbool gebruikt om een SHA van een commit aan te passen, maar dit is wat het hier betekent.
 
-Een ander gave ding van Git is dat het geen naamswijzigingen van bestanden expliciet bijhoudt. Het slaat de snapshots op en probeert dan impliciet uit te vogelen dat er iets hernoemd is, nadat het gebeurd is. Een van de interessante eigenschappen hiervan is dat je Git ook kunt vragen om allerlei soorten code verplaatsingen uit te vogelen. Als je `-C` aan `git blame` meegeeft, zal Git het bestand dat je annoteert analyseren en proberen uit te vinden waar stukjes code daarin oorspronkelijk vandaan kwamen als ze ergens vandaan gekopieerd zijn. Recentelijk was ik een bestand genaamd `GITServerHandler.m` aan het refactoreren naar meerdere bestanden, waarvan `GITPackUpload.m` er een was. Door `GITPackUpload.m` te blamen met de `-C` optie, kon ik zien waar delen van de code oorspronkelijk vandaan kwamen:
+Een ander gave ding van Git is dat het naamswijzigingen van bestanden niet expliciet bijhoudt. Het slaat de snapshots op en probeert dan impliciet uit te vogelen dat er iets hernoemd is, nadat dat gebeurd is. Een van de interessante gevolgen hiervan is dat je Git ook kunt vragen om allerlei soorten code verplaatsingen uit te zoeken. Als je `-C` aan `git blame` meegeeft, zal Git het bestand dat je aantekent analyseren en proberen uit te vinden waar stukjes code daarin oorspronkelijk vandaan kwamen als ze ergens vandaan gekopieerd zijn. Recentelijk was ik een bestand genaamd `GITServerHandler.m` aan het omschrijven naar meerdere bestanden, waarvan `GITPackUpload.m` er een was. Door `GITPackUpload.m` te blamen met de `-C` optie, kon ik zien waar delen van de code oorspronkelijk vandaan kwamen:
 
 	$ git blame -C -L 141,153 GITPackUpload.m
 	f344f58d GITServerHandler.m (Scott 2009-01-04 141)
@@ -769,13 +806,13 @@ Een ander gave ding van Git is dat het geen naamswijzigingen van bestanden expli
 	56ef2caf GITServerHandler.m (Scott 2009-01-05 152)                 [refDict setOb
 	56ef2caf GITServerHandler.m (Scott 2009-01-05 153)
 
-Dit is echt heel handig. Normaal krijg je als de originele commit de commit waar je de code overheen gekopieerd hebt, omdat dat de eerste keer is dat je die regels aangeraakt hebt in dit bestand. Git vertelt je de originele commit waarin je deze regels geschreven hebt, zelfs als dat in een ander bestand was.
+Dit is echt heel handig. Normaal krijg je als de originele commit de commit waar je de code naartoe gekopieerd hebt, omdat dat de eerste keer is dat je die regels aangeraakt hebt in dit bestand. Git vertelt je de oorspronkelijke commit waarin je deze regels geschreven hebt, zelfs als dat in een ander bestand was.
 
 ### Binair zoeken ###
 
-Een bestand annoteren helpt als je al weet waar het probleem zit. Als je niet weet waar de fout zit en er zijn dozijnen of honderden commits geweest sinds de laatste staat waarvan je weet dat de code werkte, dan zal je waarschijnlijk bij `git bisect` aankloppen voor hulp. Het `bisect` commando zoekt binair door je commit-geschiedenis om je zo snel als mogelijk te helpen identificeren welke commit het issue introduceerde.
+Een bestand aantekenen helpt als je al weet waar het probleem zit. Als je niet weet waar de fout zit en er zijn dozijnen of honderden commits geweest sinds de laatste staat waarvan je weet dat de code werkte, dan zal je waarschijnlijk bij `git bisect` aankloppen voor hulp. Het `bisect` commando zoekt binair door je commit-geschiedenis om je zo snel als mogelijk te helpen identificeren welke commit het issue introduceerde.
 
-Stel dat je zojuist een release van je code naar een productie omgeving gepushed hebt, en je krijgt bug rapporten dat er iets gebeurt wat niet in je development omgeving gebeurde en je kunt je niet voorstellen waarom de code dat aan het doen is. Je gaat terug naar je code, en het blijkt dat je het probleem kunt reproduceren maar je kunt niet zien wat er verkeerd gaat. Je kunt de code uitpluizen (bisecten) om het uit te vinden. Als eerste voer je `git bisect start` uit om aan de boel op te starten, en dan gebruik je `git bisect bad` om het systeem te vertellen dat de huidige commit kapot is. Dan moet je bisect vertellen wanneer de laatste goede status was met `git bisect good [goede_commit]`:
+Stel dat je zojuist een release van je code naar een productie omgeving gepusht hebt, en je krijgt bug rapporten dat er iets gebeurt wat niet in je development omgeving gebeurde en je kunt je niet voorstellen waarom de code dat aan het doen is. Je gaat terug naar je code, en het blijkt dat je het probleem kunt reproduceren maar je kunt niet zien wat er verkeerd gaat. Je kunt de code uitpluizen (bisecten) om het uit te vinden. Als eerste voer je `git bisect start` uit om aan de boel op te starten, en dan gebruik je `git bisect bad` om het systeem te vertellen dat de huidige commit waar je op zit kapot is. Dan moet je bisect vertellen wanneer de laatste goede status was, met `git bisect good [goede_commit]`:
 
 	$ git bisect start
 	$ git bisect bad
@@ -783,7 +820,7 @@ Stel dat je zojuist een release van je code naar een productie omgeving gepushed
 	Bisecting: 6 revisions left to test after this
 	[ecb6e1bc347ccecc5f9350d878ce677feb13d3b2] error handling on repo
 
-Git heeft gezien dat er ongeveer 12 commits gekomen zijn tussen de commit die je als laatste goede commit gemarkeerd hebt (v1.0) en de huidige slechte versie, en het heeft de middelste voor je uitgechecked. Op dit punt kun je je test uitvoeren om te zien of het probleem op deze commit ook aanwezig is. Als dat zo is, dan was het probleem ergens voor deze middelste commit geïntroduceerd, zo niet dan is het probleem na deze commit geïntroduceerd. Het blijkt dat hier geen probleem is, dus je kunt Git dat vertellen door `git bisect good` te typen en je reis te vervolgen:
+Git heeft gezien dat er ongeveer 12 commits geweest zijn tussen de commit die je als laatste goede commit gemarkeerd hebt (v1.0) en de huidige slechte versie, en het heeft de middelste voor je uitgecheckt. Op dit punt kun je de test uitvoeren om te zien of het probleem op deze commit ook aanwezig is. Als dat zo is, dan was het probleem ergens voor deze middelste commit geïntroduceerd, zo niet dan is het probleem na deze commit geïntroduceerd. Het blijkt dat hier geen probleem is, dus vertel je Git dat door `git bisect good` te typen en je reis te vervolgen:
 
 	$ git bisect good
 	Bisecting: 3 revisions left to test after this
@@ -812,24 +849,24 @@ Als je klaar bent, moet je `git bisect reset` uitvoeren om je HEAD terug te zett
 
 	$ git bisect reset
 
-Dit is een krachtige tool, die je kan helpen om in enkele minuten honderden commits te doorzoeken op zoek naar een fout. Sterker nog, als je een script hebt die eindigt met 0 als het project goed is of niet-0 als het fout is, kan je `git bisect` volledig automatiseren. Eerst vertel je het de scope van de bisect door het de goede en slechte commits te geven. Als je wilt kan dit doen door ze te tonen met het `bisect start` commando, waarbij je de slechte commit eerst en de laatst bekende goede commit als tweede geeft:
+Dit is een krachtige tool, die je kan helpen om in enkele minuten honderden commits te doorzoeken op zoek naar een fout. Sterker nog, als je een script hebt die eindigt met 0 als het project goed is of niet-0 als het fout is, kan je `git bisect` volledig automatiseren. Eerst vertel je het de scope van de bisect door het de goede en slechte commits te geven. Als je kan dit doen door ze op te geven bij het `bisect start` commando, waarbij je de slechte commit eerst en de laatst bekende goede commit als tweede geeft:
 
 	$ git bisect start HEAD v1.0
 	$ git bisect run test-error.sh
 
-Door het zo te doen wordt `test-error.sh` uitgevoerd bij elke commit die uitgechecked wordt, totdat Git de eerste kapotte commit vindt. Je kunt ook iets als `make` of `make tests` uitvoeren, of wat je ook hebt dat automatische tests voor je uitvoert.
+Door het zo te doen wordt `test-error.sh` uitgevoerd bij elke commit die uitgecheckt wordt, totdat Git de eerste kapotte commit vindt. Je kunt ook iets als `make` of `make tests` uitvoeren, of wat je ook hebt dat automatische tests voor je uitvoert.
 
 ## Submodules ##
 
-Het komt vaak voor dat terwijl je zit te werken aan het ene project, je een ander project daarbinnen nodig hebt. Bijvoorbeeld een library die een derde partij ontwikkeld heeft, of die je separaat aan het ontwikkelen bent en gebruikt in meerdere projecten. Een veel voorkomend probleem komt in deze scenario's naar voren: je wilt de twee projecten apart behandelen, maar de ene binnen de andere kunnen gebruiken.
+Het komt vaak voor dat terwijl je zit te werken aan het ene project, je een ander project daarbinnen moet gebruiken. Bijvoorbeeld een library die een derde partij ontwikkeld heeft, of die je separaat aan het ontwikkelen bent en gebruikt in meerdere projecten. Een veel voorkomend probleem komt in deze scenario's naar voren: je wilt de twee projecten apart behandelen, maar wel binnen de andere kunnen gebruiken.
 
-Hier is een voorbeeld. Stel dat je een website aan het ontwikkelen bent en Atom feeds aan het maken bent. In plaats van je eigen Atom-genererende code te schrijven, besluit je een library te gebruiken. Je zult deze code waarschijnlijk moeten includen van een gedeelde library zoals een CPAN installatie of een Ruby gem, of de broncode kopiëren naar je eigen projectboom. Het probleem met de library includen is dat het lastig is om de library op enige manier aan te passen, en vaak nog lastiger is om het uit te rollen omdat je zeker moet zijn dat iedere client die library beschikbaar heeft. Het probleem van de broncode in je project stoppen is dat alle aanpassingen die je maakt lastig te mergen zijn op het moment dat stroomopwaarts veranderingen beschikbaar komen.
+Hier is een voorbeeld. Stel dat je een website aan het ontwikkelen bent en Atom feeds aan het maken bent. In plaats van je eigen Atom-genererende code te schrijven, besluit je een library te gebruiken. Je zult deze code dan moeten includen van een gedeelde library zoals een CPAN installatie of een Ruby gem, of de broncode kopiëren naar je eigen projectboom. Het probleem met de library includen is dat het lastig is om de library op enige manier aan te passen, en vaak nog lastiger is om het uit te rollen omdat je zeker moet zijn dat iedere client die library beschikbaar heeft. Het probleem van de broncode in je project stoppen is dat alle aanpassingen die je maakt lastig te mergen zijn op het moment dat stroomopwaarts veranderingen beschikbaar komen.
 
 Git pakt dit probleem aan door submodules te gebruiken. Submodules geven je de mogelijkheid om een Git repository als een subdirectory van een ander Git repository te gebruiken. Dit stelt je in staat staat een ander repository in je project te klonen en je commits gescheiden te houden.
 
 ### Beginnen met submodules ###
 
-Stel dat je de Rack library (een Ruby web server gateway interface) wilt toevoegen aan je project, misschien je eigen veranderingen eraan wilt onderhouden, maar ook veranderingen van stroomopwaarts wilt mergen. Het eerste dat je zou moeten doen is de externe repository klonen in jouw subdirectory. Je voegt externe projecten als submodules toe door middel van het `git submodule add` commando:
+Stel dat je de Rack library (een Ruby web server gateway interface) wilt toevoegen aan je project, misschien je eigen veranderingen eraan wilt onderhouden, maar ook veranderingen van stroomopwaarts wilt mergen. Het eerste wat je moet doen is de externe repository klonen in jouw subdirectory. Je voegt externe projecten als submodules toe door middel van het `git submodule add` commando:
 
 	$ git submodule add git://github.com/chneukirchen/rack.git rack
 	Initialized empty Git repository in /opt/subtest/rack/.git/
@@ -839,7 +876,7 @@ Stel dat je de Rack library (een Ruby web server gateway interface) wilt toevoeg
 	Receiving objects: 100% (3181/3181), 675.42 KiB | 422 KiB/s, done.
 	Resolving deltas: 100% (1951/1951), done.
 
-Nu heb je het Rack project in je eigen project onder een subdirectory genaamd `rack`. Je kunt in die subdirectory gaan, wijzigingen maken, je eigen schrijfbare remote repository  toevoegen waar je veranderingen in kunt pushen, vanuit de originele repository fetchen en mergen, en zo meer. Als je `git status` uitvoert vlak nadat je de submodule toevoegt, zou je twee dingen moeten zien:
+Nu heb je het Rack project als een subdirectory genaamd `rack` in je eigen project. Je kunt die subdirectory in gaan, wijzigingen maken, je eigen schrijfbare remote repository toevoegen waar je veranderingen in kunt pushen, vanuit de originele repository fetchen en mergen, en zo meer. Als je `git status` uitvoert vlak nadat je de submodule toevoegt, zie je twee dingen:
 
 	$ git status
 	# On branch master
@@ -850,16 +887,16 @@ Nu heb je het Rack project in je eigen project onder een subdirectory genaamd `r
 	#      new file:   rack
 	#
 
-Eerst zie je het `.gitmodules` bestand. Dit is een configuratie bestand dat de mapping opslaat tussen de URL van het project en de locale subdirectory waarin je het gepulled hebt:
+Eerst zie je het `.gitmodules` bestand. Dit is een configuratie bestand dat de mapping opslaat tussen de URL van het project en de lokale subdirectory waarin je het gepulled hebt:
 
 	$ cat .gitmodules
 	[submodule "rack"]
 	      path = rack
 	      url = git://github.com/chneukirchen/rack.git
 
-Als je meerdere submodules hebt, zal je meerdere vermeldingen hebben in dit bestand. Het is belangrijk om op te merken dat dit bestand net als je andere bestanden ook onder versiebeheer staat, zoals het `.gitignore` bestand. Het wordt samen met de rest van het project gepusht en gepulled. Op deze manier weten andere mensen die je project klonen waar ze de submodule projecten vandaan moeten halen.
+Als je meerdere submodules hebt, zal je meerdere vermeldingen hebben in dit bestand. Het is belangrijk om op te merken dat dit bestand net als je andere bestanden ook onder versiebeheer staat, net als het `.gitignore` bestand. Het wordt samen met de rest van het project gepusht en gepulled. Op deze manier weten andere mensen die je project klonen waar ze de submodule projecten vandaan moeten halen.
 
-De andere vermelding in de `git status` output is de rack regel. Als je `git diff` daarop uitvoert zul je iets interessants zien:
+De andere vermelding in de `git status` uitvoer is de rack regel. Als je `git diff` daarop uitvoert zul je iets interessants zien:
 
 	$ git diff --cached rack
 	diff --git a/rack b/rack
@@ -870,7 +907,7 @@ De andere vermelding in de `git status` output is de rack regel. Als je `git dif
 	@@ -0,0 +1 @@
 	+Subproject commit 08d709f78b8c5b0fbeb7821e37fa53e69afcf433
 
-Hoewel `rack` een subdirectory in je werkdirectory is, ziet Git het als een submodule en zal de inhoud niet tracken als je niet in die directory staat. In plaats daarvan slaat Git het als een aparte commit op van dat repository. Als je wijzigingen maakt en in die subdirectory een commit doet, zal het superproject zien dat de HEAD daar is veranderd en de exacte commit opslaan waarvan je op dat moment zit te werken; op die manier zullen anderen die dit project klonen de omgeving exact kunnen reproduceren.
+Hoewel `rack` een subdirectory in je werkdirectory is, ziet Git het als een submodule en zal de inhoud niet tracken als je niet in die directory staat. In plaats daarvan slaat Git het als een aparte commit op van die repository. Als je wijzigingen maakt en in die subdirectory een commit doet, zal het superproject zien dat de HEAD daar is veranderd en de exacte commit opslaan waarop je op dat moment zit te werken; op die manier zullen anderen die dit project klonen de omgeving exact kunnen reproduceren.
 
 Dit is een belangrijk punt met submodules: je slaat ze op als de exacte commit waar ze op staan. Je kunt een submodule niet opslaan als `master` of een andere symbolische referentie.
 
@@ -882,7 +919,7 @@ Als je commit, zou je zoiets als dit moeten zien:
 	 create mode 100644 .gitmodules
 	 create mode 160000 rack
 
-Zie de 160000 modus voor de rack vermelding. Dat is een speciale modus binnen Git, die in feite betekent dat je een commit als een directory vermelding opslaat in plaats van als een subdirectory of een bestand.
+Merk de 160000 modus op voor de rack vermelding. Dat is een speciale modus binnen Git, die in feite betekent dat je een commit als een directory vermelding opslaat in plaats van als een subdirectory of een bestand.
 
 Je kunt de `rack` directory als een apart project behandelen en je superproject van tijd tot tijd vernieuwen met een pointer naar de laatste commit in dat subproject. Alle Git commando's werken onafhankelijk in de twee directories:
 
@@ -900,9 +937,9 @@ Je kunt de `rack` directory als een apart project behandelen en je superproject
 
 	    Document version change
 
-### Een project met submodules klonen ###
+### Een project met submodules clonen ###
 
-Hier zul je een project met een submodule erin klonen. Als je zo'n project ontvangt, krijg je de directories die submodules bevatten, maar nog niet de bestanden:
+Hier ga je een project met een submodule erin clonen. Als je zo'n project ontvangt, krijg je de directories die submodules bevatten, maar nog niet de bestanden:
 
 	$ git clone git://github.com/schacon/myproject.git
 	Initialized empty Git repository in /opt/myproject/.git/
@@ -918,7 +955,7 @@ Hier zul je een project met een submodule erin klonen. Als je zo'n project ontva
 	$ ls rack/
 	$
 
-De `rack` directory is er, maar hij is leeg. Je moet twee commando's uitvoeren: `git submodule init` om je locale configuratie bestand te initialiseren, en `git submodule update` om alle data van dat project te fetchen en de juiste commit die in je superproject staat uit te checken:
+De `rack` directory is er, maar hij is leeg. Je moet twee commando's uitvoeren: `git submodule init` om je lokale configuratie bestand te initialiseren, en `git submodule update` om alle data van dat project te fetchen en de juiste commit die in je superproject staat uit te checken:
 
 	$ git submodule init
 	Submodule 'rack' (git://github.com/chneukirchen/rack.git) registered for path 'rack'
@@ -931,7 +968,7 @@ De `rack` directory is er, maar hij is leeg. Je moet twee commando's uitvoeren:
 	Resolving deltas: 100% (1951/1951), done.
 	Submodule path 'rack': checked out '08d709f78b8c5b0fbeb7821e37fa53e69afcf433'
 
-Nu is je `rack` subdirectory in exact dezelfde staat als het was toen je het eerder gecommit had. Als een andere developer wijzigingen doet op de rack code en commit, en je pulled die referentie en merged de code, dan krijg je iets dat een beetje vreemd is:
+Nu is je `rack` subdirectory in exact dezelfde staat als het was toen je het eerder gecommit had. Als een andere developer wijzigingen doet op de rack code en commit en je pulled die referentie en merged de code, dan krijg je iets dat een beetje vreemd is:
 
 	$ git merge origin/master
 	Updating 0550271..85a3eee
@@ -947,7 +984,7 @@ Nu is je `rack` subdirectory in exact dezelfde staat als het was toen je het eer
 	#      modified:   rack
 	#
 
-Je hebt iets gemerged dat eigenlijk een wijziging is op de pointer naar je submodule; maar de code in de submodule directory niet vernieuwd, dus het lijkt erop dat je een vieze status hebt in je werkdirectory:
+Je hebt iets gemerged dat eigenlijk een wijziging is op de pointer naar je submodule; maar de code in de submodule directory wordt niet vernieuwd, dus het lijkt erop dat je een vervuilde status hebt in je werkdirectory:
 
 	$ git diff
 	diff --git a/rack b/rack
@@ -969,9 +1006,9 @@ Dit is het omdat de pointer die je hebt voor de submodule niet is wat eigenlijk
 	   08d709f..6c5e70b  master     -> origin/master
 	Submodule path 'rack': checked out '6c5e70b984a60b3cecd395edd5b48a7575bf58e0'
 
-Je moet dit iedere keer dat je een submodule wijziging pulled in het hoofdproject. Het is vreemd, maar het werkt.
+Je moet dit iedere keer doen wanneer je een submodule wijziging pulled in het hoofdproject. Het is vreemd, maar het werkt.
 
-Eén bekend probleem doet zich voor als een developer een locale wijziging in en submodule doet maar die niet naar een publieke server pushed. Dan committen ze een pointer naar de niet-publieke status en pushen deze naar het superproject. Als andere developers dan `git submodule update` proberen uit te voeren, dan zal het submodule systeem de commit die gerefereerd wordt niet kunnen vinden omdat het alleen op het systeem van de eerste developer bestaat. Als dat gebeurd, zul je een foutmelding als deze zien:
+Één bekend probleem doet zich voor als een developer een lokale wijziging in een submodule doet maar die niet naar een publieke server pusht. Dan committen ze een pointer naar de niet-publieke status en pushen deze naar het superproject. Als andere developers dan `git submodule update` proberen uit te voeren, dan zal het submodule systeem de commit die gerefereerd wordt niet kunnen vinden omdat het alleen op het systeem van de eerste developer bestaat. Als dat gebeurt, zal je een foutmelding als deze zien:
 
 	$ git submodule update
 	fatal: reference isn’t a tree: 6c5e70b984a60b3cecd395edd5b48a7575bf58e0
@@ -986,21 +1023,21 @@ Je moet dan bekijken wie als laatste de submodule veranderd heeft:
 
 	    added a submodule reference I will never make public. hahahahaha!
 
-Dan stuur je een e-mail naar die jongen en gaat boos zijn tegen hem.
+Dan stuur je een e-mail naar die jongen en gaat heel boos zijn tegen hem.
 
 ### Superprojecten ###
 
-Soms willen developers een combinatie van subdirectories van een groot project hebben, afhankelijk van het team waarin ze zitten. Dit komt vaak voor als je van CVS of Subversion af komt, waar je een module of verzameling subdirectory gedefinieerd hebt en je wilt deze manier van werken behouden.
+Soms willen developers een combinatie van subdirectories van een groot project hebben, afhankelijk van het team waarin ze zitten. Dit komt vaak voor als je van CVS of Subversion af komt, waar je een module of verzameling subdirectory gedefinieerd hebt en je wilt deze workflow behouden.
 
-Een goeie manier om dit in Git te doen is om elk van de subdirectories een aparte Git repository te maken en dan superproject Git repositories te maken die meerdere submodules kunnen bevatten. Een voordeel van deze aanpak is dat je meer specifiek kunt definiëren wat de relaties tussen de projecten zijn met behulp van tags en branches in de superprojects.
+Een goeie manier om dit in Git te doen is om elk van de subdirectories een aparte Git repository te maken en dan superproject Git repositories te maken die meerdere submodules bevatten. Een voordeel van deze aanpak is dat je meer specifiek kunt definiëren wat de relaties tussen de projecten zijn met behulp van tags en branches in de superprojects.
 
 ### Problemen met submodules ###
 
-Submodules gebruiken is echter niet zonder probleempjes. Ten eerste moet je relatief voorzichtig zijn met het werken in een subdirectory. Als je `git submodule update` uitvoert, zal het de specifieke versie van het project uitchecken, maar niet binnen een branch. Dit wordt een afgekoppelde (detached) HEAD genoemd – het houdt in dat het HEAD bestand direct naar een commit wijst en niet naar een symbolische referentie. Het probleem is dat je over het algemeen niet wilt werken in een detached HEAD omgeving, omdat het eenvoudig is om wijzigingen te verliezen. Als je een initiële `submodule update` doet, in die submodule directory commit zonder een branch te maken om in te werken en dan nogmaals `git submodule update` uitvoert in het superproject zonder in de tussentijd te committen, dan zal Git je wijzigingen overschrijven zonder het je te vertellen. Technisch gezien ben je het werk niet kwijt, maar je zult geen branch hebben die er naar wijst, dus het zal lastig zijn om het terug te halen.
+Submodules gebruiken is echter niet zonder probleempjes. Ten eerste moet je relatief voorzichtig zijn met het werken in de directory van de submodule. Als je `git submodule update` uitvoert, zal het de specifieke versie van het project uitchecken, maar niet binnen een branch. Dit wordt een afgekoppelde (detached) HEAD genoemd – het houdt in dat het HEAD bestand direct naar een commit wijst en niet naar een symbolische referentie. Het probleem is dat je over het algemeen niet wilt werken in een detached HEAD omgeving, omdat het eenvoudig is om wijzigingen te verliezen. Als je een initiële `submodule update` doet, in die submodule directory commit zonder een branch te maken om in te werken en dan nogmaals `git submodule update` uitvoert in het superproject zonder in de tussentijd te committen, dan zal Git je wijzigingen overschrijven zonder het je te vertellen. Technisch gezien ben je het werk niet kwijt, maar je zult geen branch hebben die er naar wijst, dus het zal wat lastig zijn om het terug te halen.
 
 Om dit probleem te vermijden creëer je een branch zodra je in een submodule directory werkt met behulp van `git checkout -b work` of iets dergelijks. Als je de tweede keer de submodule update doet, zal het nog steeds je werk terugdraaien maar je heb tenminste een pointer om naar terug te keren.
 
-Van branches wisselen die submodules bevatten kan ook lastig zijn. Als je een nieuwe branch aanmaakt, daar een submodule toevoegt en dat terug wisselt naar een branch zonder die submodule, zul je nog steeds de submodule directory als een untracked subdirectory hebben:
+Tussen branches omschakelen die submodules bevatten kan ook lastig zijn. Als je een nieuwe branch aanmaakt, daar een submodule toevoegt en dat terug wisselt naar een branch zonder die submodule, zul je nog steeds de submodule directory als een ungetrackte subdirectory hebben:
 
 	$ git checkout -b rack
 	Switched to a new branch "rack"
@@ -1023,9 +1060,9 @@ Van branches wisselen die submodules bevatten kan ook lastig zijn. Als je een ni
 	#
 	#      rack/
 
-Je moet hem verplaatsen of verwijderen, in welk geval je hem opnieuw moet klonen als je terug wisselt. Daarbij loop je kans om locale wijzigingen of branches te verliezen die je niet gepusht hebt.
+Je moet hem verplaatsen of verwijderen, in welk geval je hem opnieuw moet clonen als je terug wisselt. Daarbij loop je kans om lokale wijzigingen of branches te verliezen die je niet gepusht hebt.
 
-De laatste grote valkuil waar veel mensen in lopen heeft te maken met het wisselen van subdirectories naar submodules. Als je bestanden in je project tracked en je wilt ze naar een submodule verplaatsen, dan moet je voorzichtig zijn of zal Git boos op je worden. Stel dat je de rack bestanden in een subdirectory van je project hebt, en je wilt die naar een submodule wijzigen. Als je de subdirectory weggooit en dan `submodule add` uitvoert, begint Git naar je te schreeuwen:
+De laatste grote valkuil waar veel mensen in lopen heeft te maken met het wisselen van subdirectories naar submodules. Als je bestanden in je project trackt, en je wilt ze naar een submodule verplaatsen, dan moet je voorzichtig zijn of zal Git boos op je worden. Stel dat je de rack bestanden in een subdirectory van je project hebt, en je wilt die naar een submodule omzetten. Als je de subdirectory weggooit en dan `submodule add` uitvoert, begint Git naar je te schreeuwen:
 
 	$ rm -Rf rack/
 	$ git submodule add git@github.com:schacon/rack.git rack
@@ -1042,12 +1079,12 @@ Je moet de `rack` subdirectory eerst unstagen. Dan kun je de submodule toevoegen
 	Receiving objects: 100% (3184/3184), 677.42 KiB | 88 KiB/s, done.
 	Resolving deltas: 100% (1952/1952), done.
 
-Stel nu dat je dat in een branch gedaan had. Als je probeert terug te wisselen naar een branch waar die bestanden nog in de echte boom zitten in plaats van in een submodule – dan krijg je deze foutmelding:
+Stel nu dat je dat in een branch gedaan zou hebben. Als je probeert terug te wisselen naar een branch waar die bestanden nog in de echte boom zitten in plaats van in een submodule – dan krijg je deze foutmelding:
 
 	$ git checkout master
 	error: Untracked working tree file 'rack/AUTHORS' would be overwritten by merge.
 
-Je moet de `rack` submodule directory uit de weg halen voordat je naar een branch kunt wisselen die hem nog niet heeft:
+Je moet de `rack` submodule directory uit de weg ruimen voordat je naar een branch kunt omschakelen die hem nog niet heeft:
 
 	$ mv rack /tmp/
 	$ git checkout master
@@ -1055,15 +1092,15 @@ Je moet de `rack` submodule directory uit de weg halen voordat je naar een branc
 	$ ls
 	README	rack
 
-Als je dan terug wisselt krijg je een lege `rack` directory. Je kunt dan nogmaals `git submodule update` uitvoeren om nog eens te klonen, of je kunt je `/tmp/rack` directory terug zetten in de lege directory.
+Als je dan terug schakelt krijg je een lege `rack` directory. Je kunt dan nogmaals `git submodule update` uitvoeren om nog eens te clonen, of je kunt je `/tmp/rack` directory terug zetten in de lege directory.
 
 ## Subboom mergen ##
 
-Nu je de moeilijkheden van het submodulesysteem hebt gezien, laten we eens kijken naar een alternatieve manier om hetzelfde probleem aan te pakken. Zodra Git merged, kijkt het naar wat het moet mergen en kiest dan een toepasselijke mergestrategie om te gebruiken. Als je twee branches aan het mergen bent zal Git een _recursive_ strategie gebruiken. Als je meer dan twee branches aan het mergen bent zal Git de _octopus_ strategie kiezen. Deze strategieën worden automatisch voor je gekozen omdat de recursieve strategie complexe drie-weg merge situaties aan kan; bijvoorbeeld meer dan één gezamenlijke voorouder, maar het kan het alleen mergen van twee branches aan. De octopus merge kan meerdere branches verwerken, maar is voorzichtiger om moeilijke conflicten te vermijden, dus is het gekozen als de standaard strategie als je meer dan twee branches probeert te mergen.
+Nu je de moeilijkheden van het submodulesysteem hebt gezien, laten we eens kijken naar een alternatieve manier om hetzelfde probleem aan te pakken. Zodra Git merged, kijkt het naar wat het moet mergen en kiest dan een toepasselijke mergestrategie om te gebruiken. Als je twee branches aan het mergen bent zal Git een _recursive_ strategie gebruiken. Als je meer dan twee branches aan het mergen bent zal Git de _octopus_ strategie kiezen. Deze strategieën worden automatisch voor je gekozen omdat de recursieve strategie complexe drie-weg merge situaties aan kan - bijvoorbeeld meer dan één gezamenlijke voorouder, maar het kan het alleen mergen van twee branches aan. De octopus merge kan meerdere branches aan, maar is voorzichtiger om moeilijke conflicten te vermijden, dus wordt deze gekozen als de standaard strategie als je meer dan twee branches probeert te mergen.
 
-Maar er zijn andere strategieën die je ook kunt kiezen. Eén ervan is de _subtree_ merge, en je kunt deze gebruiken om het subproject probleem aan te gaan. Hier zul je zien hoe je dezelfde rack inbedding kunt doen als in de laatste paragraaf, maar in plaats daarvan subboommerges gebruiken.
+Maar er zijn andere strategieën die je ook kunt kiezen. Eén ervan is de _subtree_ merge, en je kunt deze gebruiken om het subproject probleem aan te gaan. Hier zul je zien hoe je dezelfde rack inbedding kunt doen als in de vorige paragraaf, maar in plaats daarvan subboom-merges gebruiken.
 
-Het idee van de subboommerge is dat je twee projecten hebt, en één van de projecten wijst naar de subdirectory van de andere en omgekeerd. Als je een subboommerge specificeert, dan is Git slim genoeg om uit te vogelen dat de ene een subboom van de andere is en vervolgens juist te mergen, het is nogal verbazingwekkend.
+Het idee van de subboom-merge is dat je twee projecten hebt, en één van de projecten komt overeen met een subdirectory van de andere en omgekeerd. Als je een subboommerge specificeert, dan is Git slim genoeg om erachter te komen dat de ene een subboom van de andere is en vervolgens juist te mergen - het is best wel verbazingwekkend.
 
 Eerst voeg je de Rack applicatie toe aan je project. Voeg het Rack project toe als een remote reference in je eigen project en check het dan uit in zijn eigen branch:
 
@@ -1084,7 +1121,7 @@ Eerst voeg je de Rack applicatie toe aan je project. Voeg het Rack project toe a
 	Branch rack_branch set up to track remote branch refs/remotes/rack_remote/master.
 	Switched to a new branch "rack_branch"
 
-Nu heb je de root van het Rack project in je `rack_branch` branch en je eigen project in de `master` branch. Als je één uitchecked en dan de andere, kun je zien dat ze verschillende project roots hebben:
+Nu heb je de root van het Rack project in je `rack_branch` branch en je eigen project in de `master` branch. Als je eerste de ene uitchecked en dan de andere, kun je zien dat ze verschillende project roots hebben:
 
 	$ ls
 	AUTHORS	       KNOWN-ISSUES   Rakefile      contrib	       lib
@@ -1098,12 +1135,12 @@ Je gaat nu het Rack project in je `master` project pullen als een subdirectory.
 
 	$ git read-tree --prefix=rack/ -u rack_branch
 
-Als je commit, ziet het eruit alsof alle Rack bestanden in die subdirectory staan; alsof je ze uit een tarball gekopieerd hebt. Waar het interessant wordt is dat je vrij makkelijk veranderingen van één branch in de andere kunt mergen. Dus als het Rack project update kan je alle wijzigingen van stroomopwaartse binnenhalen door naar die branch te wisselen en te pullen:
+Als je commit, lijkt het alsof alle Rack bestanden in die subdirectory staan - alsof je ze uit een tarball gekopieerd hebt. Waar het interessant wordt is dat je vrij makkelijk veranderingen van één branch in de andere kunt mergen. Dus als het Rack project update kan je alle wijzigingen van stroomopwaartse binnenhalen door naar die branch te wisselen en te pullen:
 
 	$ git checkout rack_branch
 	$ git pull
 
-Dan kun je die veranderingen terug in je master branch mergen. Je kunt `git merge -s subtree` gebruiken en het zal prima werken, maar Git zal ook de geschiedenissen mergen, en dat wil je waarschijnlijk niet. Om de veranderingen binnen te halen en het commit bericht voor te vullen, gebruik je de `--squash` en `--no-commit` opties samen met de `-s subtree` strategie optie:
+Dan kun je die veranderingen terug in je master branch mergen. Je kunt `git merge -s subtree` gebruiken en het zal prima werken, maar Git zal ook de geschiedenissen samenvoegen, en dat wil je eigenlijk niet. Om de veranderingen binnen te halen en het commit bericht voor te vullen, gebruik je de `--squash` en `--no-commit` opties samen met de `-s subtree` strategie optie:
 
 	$ git checkout master
 	$ git merge --squash -s subtree --no-commit rack_branch
@@ -1122,4 +1159,4 @@ Of om te vergelijken met wat in je `rack` subdirectory zit met wat in de `master
 
 ## Samenvatting ##
 
-Je hebt een aantal geavanceerde tools gezien, die je in staat stellen je commits en staging area heel exact te manipuleren. Als je problemen signaleert kun je vrij eenvoudig uitvinden welke commit deze geïntroduceerd heeft, wanneer ze geïntroduceerd zijn en door wie. Als je subprojecten in je project wilt gebruiken, heb je een paar manieren geleerd hoe je die een plaats kunt geven. Op dit punt zou je in staat moeten zijn om de meeste dingen in Git te kunnen doen die je dagelijks op de commandline moet doen, en je erbij op je gemak te voelen.
+Je hebt een aantal geavanceerde tools gezien, die je in staat stellen je commits en staging area heel exact te manipuleren. Als je problemen signaleert kun je vrij eenvoudig uitvinden welke commit deze geïntroduceerd heeft, wanneer, en door wie. Als je subprojecten in je project wilt gebruiken, heb je een paar manieren gezien hoe je die een plaats kunt geven. Nu zou je in staat moeten zijn om de meeste dingen in Git te doen die je dagelijks op de commandline moet doen, en je erbij op je gemak te voelen.

From c798d64fd143ce28e94c08510912700814d92c4f Mon Sep 17 00:00:00 2001
From: Cor <git@cpt1.demon.nl>
Date: Fri, 21 Feb 2014 20:24:27 +0100
Subject: [PATCH 241/690] [nl] Chapter 07 - Reword and retranslate

---
 nl/07-customizing-git/01-chapter7.markdown | 232 ++++++++++++---------
 1 file changed, 133 insertions(+), 99 deletions(-)

diff --git a/nl/07-customizing-git/01-chapter7.markdown b/nl/07-customizing-git/01-chapter7.markdown
index 22fbee5e2..56e41bea1 100644
--- a/nl/07-customizing-git/01-chapter7.markdown
+++ b/nl/07-customizing-git/01-chapter7.markdown
@@ -1,6 +1,41 @@
+<!-- Attentie heren en dames vertalers.
+Ik zou het volgende willen voorstellen:
+Er zijn bepaalde termen die voor de gemiddelde Nederlandse computer gebruiker 
+veel beter klinken (of bekender voorkomen) als de orginele Engelse term. In het
+begin zullen deze termen niet vaak voorkomen, maar in de meer diepgaandere 
+hoofdstukken komen deze steeds meer voor. Termen als "Committen", "Mergen" 
+en "Applyen" klinken beter dan "Plegen" of "Toepassen", "Samenvoegen" en 
+"Toepassen" (wat bovendien slecht valt te onderscheiden van de 
+commit-toepassing). De mensen die dit boek lezen zijn, naar mijn bescheiden 
+inschatting, al redelijk op de hoogte van versiebeheer en passen (zie ik in 
+de praktijk) deze termen al toe. Een nieuwe terminologie introduceren lijkt 
+me dan ook niet noodzakelijk.
+Verder blijven er altijd kreten over als "directory", wat vertaald zou kunnen 
+worden als "map", maar bij het Engelse werkwoord to map krijgen we dan weer het
+probleem: hoe dit weer te vertalen? Daarom zou ik willen voorstellen om deze 
+basis-termen toch onvertaald te laten.
+
+Twijfelgevallen zullen altijd blijven zoals de term "file", daarvan wordt in de
+praktijk zowel de term file als bestand gebruikt. Ik denk dat we hier moeten 
+kijken hoe het in de context past. 
+Maar ook een term als "tool" en (ik zit zelf nog op een mooie Nederlandse term
+te broeden) "plumbing", hierbij stel ik voor om eenmalig een Nederlandse 
+vertaling te geven, tussen haakjes de Engelse term te geven en in het vervolg
+de Engelse term te gebruiken. Wederom is de context hier belangrijk.
+
+Verder stel ik ook voor om de regels op https://onzetaal.nl/taaladvies zoveel
+mogelijk te volgen. Bijvoorbeeld de regels omtrent het spellen van Engelse 
+werkwoorden die in het Nederlands gebruikt worden.
+
+Let wel: ik wil niemand tot iets verplichten, maar ik denk dat we moeten 
+streven naar een zo duidelijk mogelijke en best bij de praktijk aansluitende
+vertaling moeten proberen te maken.
+
+Veel succes en plezier bij het vertalen...
+-->
 # Git op maat maken #
 
-Tot zover heb ik de fundamentele werking van Git behandeld en hoe het te gebruiken, en ik heb een aantal tools geïntroduceerd die Git levert om je het makkelijk en efficiënt te laten gebruiken. In dit hoofdstuk zal ik wat operaties doorlopen die je kunt gebruiken om Git op een maat gemaakte manier te laten werken door een aantal belangrijke configuratie-instellingen te introduceren en het inhaak-systeem (hooks). Met deze gereedschappen is het makkelijk om Git precies te laten werken op de manier zoals jij, je bedrijf, of je groep het nodig hebben.
+Tot zover heb ik de fundamentele werking van Git behandeld en hoe het te gebruiken, en ik heb een aantal tools geïntroduceerd die Git tot je beschikking stelt om je het makkelijk en efficiënt te laten gebruiken. In dit hoofdstuk zal ik wat operaties doorlopen die je kunt gebruiken om Git op een maat gemaakte manier te laten werken middels het introduceren van een aantal belangrijke configuratie-instellingen en het inhaak-systeem (hooks). Met deze tools is het makkelijk om Git precies te laten werken op de manier zoals jij, je bedrijf, of je groep het nodig hebben.
 
 ## Git configuratie ##
 
@@ -9,17 +44,17 @@ Zoals je kort in Hoofdstuk 1 gezien hebt, kun je Git configuratie instellingen s
 	$ git config --global user.name "John Doe"
 	$ git config --global user.email johndoe@example.com
 
-Hierna zal je een paar van de meer interessante opties leren, die je op vergelijkbare manier kunt instellen om je Git op maat te maken.
+Hierna zal je een paar van de meer interessante opties gaan zien, die je op vergelijkbare manier kunt instellen om je Git op maat te maken.
 
 Je zag al wat eenvoudige Git configuratie details in het eerste hoofdstuk, en die zal ik hier snel nog eens laten zien. Git gebruikt een aantal configuratie bestanden om het niet-standaard gedrag dat je wilt te bepalen. De eerste plek waar Git kijkt voor deze waarden is in een `/etc/gitconfig` bestand, deze bevat de waarden voor alle gebruikers op het systeem en al hun repositories. Als je de optie `--system` aan `git config` meegeeft, leest en schrijft Git naar dit bestand.
 
 De volgende plaats waar Git kijkt is het `~/.gitconfig` bestand, wat specifiek is voor elke gebruiker. Je kunt er voor zorgen dat Git naar dit bestand leest en schrijft door de `--global` optie mee te geven.
 
-Als laatste kijkt Git naar configuratie waarden in het config bestand in de Git directory (`.git/config`) van de repository dat op dat moment gebruikt wordt. Deze waarden zijn specifiek voor die ene repository. Ieder niveau overschrijft de waarden in het vorig, dus waarden in `.git/config` gaan voor op die in `/etc/gitconfig` bijvoorbeeld. Je kunt die waarden ook instellen door het bestand handmatig aan te passen en de correcte syntax te gebruiken, maar het is gewoon eenvoudiger het `git config` commando uit te voeren.
+Als laatste kijkt Git naar configuratie waarden in het config bestand in de Git directory (`.git/config`) van de repository dat op dat moment gebruikt wordt. Deze waarden zijn specifiek voor die ene repository. Ieder niveau overschrijft de waarden van de vorige, dus waarden in `.git/config` hebben voorrang op die in `/etc/gitconfig` bijvoorbeeld. Je kunt die waarden ook instellen door het bestand handmatig aan te passen en de correcte syntax te gebruiken, maar het is normaalgesproken eenvoudiger het `git config` commando uit te voeren.
 
 ### Basis client configuratie ###
 
-De configuratie opties die herkend worden door Git vallen in twee categorieën: de cliënt kant en de server kant. De meerderheid van de opties zijn voor de cliënt kant: de configuratie van je persoonlijke voorkeuren. Alhoewel er massa's opties beschikbaar zijn, zal ik er maar een paar behandelen die ofwel veelgebruikt zijn ofwel je werkwijze significant kunnen beïnvloeden. Veel opties zijn alleen van toepassing in randgevallen, die ik nu niet zal behandelen. Als je een lijst van alle opties wilt zien, die door jouw versie van Git worden herkend kan je dit uitvoeren
+De configuratie opties die herkend worden door Git vallen in twee categorieën: de client kant en de server kant. De meerderheid van de opties zijn voor de client kant: de configuratie van jouw persoonlijke voorkeuren. Alhoewel er massa's opties beschikbaar zijn, zal ik er maar een paar behandelen die ofwel veelgebruikt zijn ofwel je workflow significant kunnen beïnvloeden. Veel opties zijn alleen van toepassing in uitzonderlijke gevallen, die ik nu niet zal behandelen. Als je een lijst van alle opties wilt zien, die door jouw versie van Git worden herkend kan je dit uitvoeren
 
 	$ git config --help
 
@@ -27,15 +62,15 @@ De gebruikershandleiding voor `git config` toont alle beschikbare opties in groo
 
 #### core.editor ####
 
-Standaard zal Git de tekst editor gebruiken die je zelf ingesteld als standaard en anders valt Git terug op de Vi editor om je commit en tag boodschappen te maken of te wijzigen. Om die instelling naar iets anders om te zetten, kun je de `core.editor` instelling gebruiken:
+Standaard zal Git de tekst editor gebruiken die je zelf ingesteld hebt als standaard en anders valt Git terug op de Vi editor om je commit en tag boodschappen te maken of te wijzigen. Om die instelling naar iets anders om te zetten, kun je de `core.editor` instelling gebruiken:
 
 	$ git config --global core.editor emacs
 
-Nu maakt het niet uit wat je als je standaard shell editor waarde ingesteld hebt, en zal Git Emacs starten om boodschappen aan te passen.
+Vanaf nu maakt het niet meer uit wat je als je standaard shell editor waarde ingesteld hebt, Git zal Emacs starten om boodschappen aan te passen.
 
 #### commit.template ####
 
-Als je hier het een pad instelt dat naar een bestand op je systeem wijst, zal Git dat bestand als de standaard boodschap gebruiken bij elke commit. Bijvoorbeeld, stel dat je een sjabloon bestand aanmaakt als `$HOME/.gitmessage.txt` die er zo uitziet:
+Als je hier het een pad instelt dat naar een bestand op je systeem wijst, zal Git dat bestand als de standaard boodschap gebruiken bij elke commit. Bijvoorbeeld, stel dat je een sjabloon bestand `$HOME/.gitmessage.txt` maakt die er zo uitziet:
 
 	onderwerp regel
 
@@ -89,11 +124,11 @@ Nu kun je tags signeren zonder steeds je sleutel op te hoeven geven bij het `git
 
 #### core.excludesfile ####
 
-Je kunt patronen in het `.gitignore` bestand van je project zetten zodat Git ze niet ziet als untracked bestanden en niet zal proberen ze te stagen als je `git add` op ze uitvoert, zoals besproken in Hoofdstuk 2. Maar als je wilt dat een ander bestand buiten je project die waarden of additionele waarden bevat, kan je Git vertellen met de `core.excludesfile` waarde waar dat bestand is. Stel het eenvoudigweg in als een pad naar een bestand met een inhoud dat vergelijkbaar is met wat een `.gitignore` bestand zou hebben.
+Je kunt patronen in het `.gitignore` bestand van je project zetten zodat Git ze niet ziet als untracked bestanden en niet zal proberen ze te stagen als je `git add` op ze uitvoert, zoals besproken in Hoofdstuk 2. Maar als je wilt dat een ander bestand buiten je project die waarden bevat of additionele waarden wilt, kan je Git vertellen met de `core.excludesfile`-waarde waar dat bestand is. Stel het eenvoudigweg in als een pad naar een bestand met een inhoud dat vergelijkbaar is met wat in een `.gitignore` bestand zou staan.
 
 #### help.autocorrect ####
 
-Deze optie is alleen beschikbaar in Git 1.6.1. en later. Als je een commando in Git 1.6 verkeerd typt, toont het je zoiets als dit:
+Deze optie is alleen beschikbaar in Git 1.6.1. en later. Als je in Git een commando verkeerd intypt, toont het je zoiets als dit:
 
 	$ git com
 	git: 'com' is not a git-command. See 'git --help'.
@@ -105,15 +140,15 @@ Als je `het.autocorrect` op 1 instelt, zal Git automatisch het commando uitvoere
 
 ### Kleuren in Git ###
 
-Git kan zijn uitvoer op de terminal in kleur tonen, wat kan helpen om de uitvoer snel en eenvoudig visueel te interpreteren. Een aantal opties kan helpen om de kleuren naar jouw voorkeur in te stellen.
+Git kan zijn uitvoer op de terminal in kleur tonen, wat kan helpen om de uitvoer snel en eenvoudig visueel te verwerken. Er zijn een aantal opties die kunnen helpen om de kleuren naar jouw voorkeur in te stellen.
 
 #### color.ui ####
 
-Git zal automatisch het meeste van zijn uitvoer in kleur tonen als je het vraagt. Je kunt erg specifiek zijn in wat je gekleurd wilt hebben en hoe. Maar om alle standaard kleuren in de terminal aan te zetten, stel dan `color.ui` in op true:
+Git zal automatisch het meeste van zijn uitvoer in kleur tonen als je het vraagt. Je kunt erg specifiek worden in wat je gekleurd wilt hebben en hoe; maar om alle standaard kleuren in de terminal aan te zetten, stel dan `color.ui` in op true:
 
 	$ git config --global color.ui true
 
-Als deze waarde ingesteld is, zal Git zijn uitvoer in kleur tonen zodra deze naar een terminal gaat. Andere mogelijke opties zijn false wat de uitvoer nooit kleurt, en always, wat de kleuren altijd weergeeft zelfs als je Git commando's uitvoert naar een bestand of deze naar een ander commando doorsluist (piping).
+Als deze waarde ingesteld is, zal Git zijn uitvoer in kleur tonen zodra deze naar een terminal gaat. Andere mogelijke opties zijn false wat de uitvoer nooit kleurt, en always, wat de kleuren altijd weergeeft zelfs als je Git commando's uitvoert naar een bestand of deze naar een ander commando doorsluist (zgn. piping).
 
 Je zult zelden `color.ui = always` willen. In de meeste scenario's, als je kleuren in je omgeleide uitvoer wil, kan je een `--color` vlag aan het Git commando meegeven om het te forceren kleuren te gebruiken. De `color.ui = true` instelling is degene die je vrijwel altijd wilt gebruiken.
 
@@ -126,7 +161,7 @@ Als je meer specifiek wil zijn welke commando's gekleurd moeten zijn en hoe, dan
 	color.interactive
 	color.status
 
-Daarnaast heeft elk van deze ook sub-instellingen die je kunt gebruiken om specifieke kleuren in te stellen voor delen van de uitvoer, als je iedere kleur wilt overschrijven. Bijvoorbeeld, om de meta-informatie in je diff uitvoer in blauwe voorgrond, zwarte achtergrond en vetgedrukt in te stellen, kun je dit uitvoeren
+Daarnaast heeft elk van deze ook sub-instellingen die je kunt gebruiken om specifieke kleuren in te stellen voor delen van de uitvoer, als je iedere kleur wilt wijzigen. Bijvoorbeeld, om de meta-informatie in je diff uitvoer in blauwe voorgrond, zwarte achtergrond en vetgedrukt in te stellen, kun je dit uitvoeren
 
 	$ git config --global color.diff.meta “blue black bold”
 
@@ -136,15 +171,15 @@ Zie de manpage van `git config` voor alle sub-instellingen die je kunt instellen
 
 ### Externe merge en diff tools ###
 
-Alhoewel Git een interne implementatie van diff heeft, die heb je tot nu toe gebruikt, kan je in plaats daarvan een extern tool instellen. Je kunt ook een grafisch merge conflict-oplossings tool instellen, in plaats van handmatig de conflicten op te moeten lossen. Ik zal nu demonstreren hoe je het Perforce Visuele Merge Tool (P4Merge) in moet stellen, om je diff en merge oplossingen te doen, omdat het een fijn grafisch tool is en omdat het gratis is.
+Alhoewel Git een interne implementatie van diff heeft, deze heb je tot nu toe gebruikt, kan je in plaats daarvan een extern tool instellen. Je kunt ook een grafisch merge conflict-oplossings tool instellen, in plaats van handmatig de conflicten op te moeten lossen. Ik zal nu demonstreren hoe je het Perforce Visuele Merge Tool (P4Merge) in moet stellen, om je diff en merge oplossingen te doen, omdat het een fijn grafisch tool is en omdat het gratis is.
 
-P4Merge werkt op alle grote platformen als je dit wil proberen, dus je zou het moeten kunnen doen. Ik zal in de voorbeelden paden gebruiken die op Mac en Linux systemen werken; voor Windows moet je `/usr/local/bin` veranderen in een pad naar een uitvoerbaar bestand op jouw machine.
+Als je dit wilt proberen, P4Merge werkt op alle grote platformen, dus je zou het moeten kunnen doen. Ik zal in de voorbeelden paden gebruiken die op Mac en Linux systemen werken; voor Windows moet je `/usr/local/bin` veranderen in een pad naar een uitvoerbaar bestand op jouw machine.
 
 Je kunt P4Merge hier downloaden:
 
 	http://www.perforce.com/perforce/downloads/component.html
 
-Om te beginnen ga je externe wrapper scripts instellen om de commando's uit te voeren. Ik zal het Mac pad gebruiken voor de applicatie; in andere systemen zal het moeten wijzen naar waar de `p4merge` binary geïnstalleerd is. Stel een merge wrapper script in, genaamd `extMerge`, die jouw applicatie met alle meegegeven argumenten aanroept:
+Om te beginnen ga je externe wrapper scripts instellen om de commando's uit te voeren. Ik zal het Mac pad gebruiken voor de applicatie; in andere systemen zal het moeten wijzen naar de plaats waar de `p4merge` binary geïnstalleerd is. Maak merge wrapper script, genaamd `extMerge`, die jouw applicatie met alle meegegeven argumenten aanroept:
 
 	$ cat /usr/local/bin/extMerge
 	#!/bin/sh
@@ -160,7 +195,7 @@ Omdat je alleen de `oude-bestand` en `nieuwe-bestand` argumenten wilt, zul je he
 	#!/bin/sh
 	[ $# -eq 7 ] && /usr/local/bin/extMerge "$2" "$5"
 
-Je moet er ook zeker van zijn dat deze scripts uitvoerbaar zijn:
+Je moet er ook voor zorgen dat deze scripts uitvoerbaar zijn:
 
 	$ sudo chmod +x /usr/local/bin/extMerge
 	$ sudo chmod +x /usr/local/bin/extDiff
@@ -183,7 +218,7 @@ of je kunt je `~/.gitconfig` bestand aanpassen en deze regels toevoegen:
 	[diff]
 	  external = extDiff
 
-Nadat dit alles ingesteld is, kan je diff commando's zoals deze uitvoeren:
+Nadat dit alles gebeurd is, kan je diff commando's zoals deze uitvoeren:
 
 	$ git diff 32d1776b1^ 32d1776b1
 
@@ -194,7 +229,7 @@ Figuur 7-1. P4Merge.
 
 Als je twee branches probeert te mergen en je krijgt vervolgens merge conflicten, kan je het `git mergetool` commando uitvoeren. P4Merge wordt dan opgestart om je het conflict op te laten lossen met behulp van dat GUI tool.
 
-Het aardige van deze wrapper opstelling is dat je de diff en merge tools eenvoudig aan kunt passen. Bijvoorbeeld, om je `extDiff` en `extMerge` tools in te stellen dat ze bijvoorbeeld het KDiff3 tool uitvoeren, is het enige dat je moet doen het `extMerge` bestand aanpassen:
+Het aardige van deze wrapper opstelling is dat je de diff en merge tools eenvoudig aan kunt passen. Bijvoorbeeld, om je `extDiff` en `extMerge` tools in te stellen zodat ze bijvoorbeeld het KDiff3 tool uitvoeren, is het enige dat je moet doen het `extMerge` bestand aanpassen:
 
 	$ cat /usr/local/bin/extMerge
 	#!/bin/sh
@@ -202,7 +237,7 @@ Het aardige van deze wrapper opstelling is dat je de diff en merge tools eenvoud
 
 Nu zal Git het KDiff3 tool gebruiken voor het tonen van diff en het oplossen van merge conflicten.
 
-Git is al ingesteld om een aantal andere mergeconflict-oplossings tools te gebruiken zonder dat je de cmd configuratie op hoeft te zetten. Je kunt je merge tool op kdiff3 instellen, opendiff, tkdiff, meld, xxdiff, emerge, vimdiff of gvimdiff. Als je niet geïnteresseerd bent in het gebruik van KDiff3 als diff, maar het liever alleen wilt gebruiken voor conflict oplossing en het kdiff3 commando zit in je pad, dan kun je dit uitvoeren
+Git is 'af fabriek' al ingesteld om een aantal andere mergeconflict-oplossings tools te gebruiken zonder dat je de cmd configuratie op hoeft te zetten. Je kunt je merge tool op kdiff3 instellen, opendiff, tkdiff, meld, xxdiff, emerge, vimdiff of gvimdiff. Als je niet geïnteresseerd bent in het gebruik van KDiff3 als diff, maar het liever alleen wilt gebruiken voor merge conflict oplossing, en het kdiff3 commando zit in je pad, dan kun je dit uitvoeren
 
 	$ git config --global merge.tool kdiff3
 
@@ -210,17 +245,17 @@ Als je dit uitvoert in plaats van de `extMerge` en `extDiff` bestanden in te ste
 
 ### Opmaak en witruimten ###
 
-Problemen met opmaak en witruimten zijn één van de veelvoorkomende frustrerende en subtiele problemen die veel ontwikkelaars tegenkomen bij het samenwerken, in het bijzonder over verschillende platformen. Het is heel eenvoudig voor patches en ander werk om subtiele witruimte veranderingen te introduceren, omdat editors ze stiekum introduceren of omdat Windows programmeurs carriage returns aan het eind van de regels toevoegen van bestanden die ze bewerken in gemengde platformprojecten. Git heeft een aantal configuratie opties om met deze problemen te helpen.
+Problemen met opmaak en witruimten zijn één van de meest frustrerende en subtiele problemen die veel ontwikkelaars tegenkomen bij het samenwerken, in het bijzonder over verschillende platformen. Het is heel eenvoudig voor patches en ander werk om subtiele witruimte veranderingen te introduceren, omdat editors ze stiekum introduceren of omdat Windows programmeurs carriage returns aan het eind van de regels toevoegen van bestanden die ze bewerken in gemengde platformprojecten. Git heeft een aantal configuratie opties om met deze problemen te helpen.
 
 #### core.autocrlf ####
 
 Als je op Windows programmeert, of een ander systeem gebruikt maar samenwerkt met mensen die op Windows werken, zal je op enig moment tegen regeleinde problemen aanlopen. Dat komt omdat Windows zowel een carriage-return als een linefeed karakter gebruikt voor regeleindes in zijn bestanden, terwijl Mac en Linux systemen alleen het linefeed karakter gebruiken. Dit is een subtiel maar verschrikkelijk irritant feit van het werken met gemengde platformen.
 
-Git kan hiermee omgaan door CRLF regeleinden automatisch om te zetten naar LF zodra je commit, en vice versa op het moment dat je code uitchecked op je systeem. Je kunt deze functionaliteit aanzetten met de `core.autocrlf` instelling. Als je op een Windows machine zit, stel het dan in op `true` – dit verandert LF regeleinden in CRLF zodra je code uitchecked:
+Git kan hiermee omgaan door CRLF regeleinden automatisch om te zetten naar LF zodra je commit, en vice versa op het moment dat je code uitcheckt op je bestandssysteem. Je kunt deze functionaliteit aanzetten met de `core.autocrlf` instelling. Als je op een Windows machine zit, stel het dan in op `true` – dit verandert LF regeleinden in CRLF zodra je code uitcheckt:
 
 	$ git config --global core.autocrlf true
 
-Als je op een Linux of Mac systeem werkt (dat LF regeleinden gebruikt) dan wil je niet dat Git ze automatisch verandert op het moment dat Git bestanden uitchecked. Maar als een bestand met CRLF regeleinden onverhoopt toch geïntroduceerd wordt, dan wil je waarschijnlijk dat Git dit repareert. Je kunt Git vertellen dat je wilt dat hij CRLF in LF veranderd tijdens het committen, maar niet de andere kant op door het instellen van `core.autocrlf` op input:
+Als je op een Linux of Mac systeem werkt (die LF regeleinden gebruiken) dan wil je niet dat Git ze automatisch verandert op het moment dat Git bestanden uitcheckt. Maar als een bestand met CRLF regeleinden onverhoopt toch geïntroduceerd wordt, dan wil je waarschijnlijk dat Git dit repareert. Je kunt Git vertellen dat je wilt dat hij CRLF in LF veranderd tijdens het committen, maar niet de andere kant op door het instellen van `core.autocrlf` op input:
 
 	$ git config --global core.autocrlf input
 
@@ -232,7 +267,7 @@ Als je een Windows programmeur bent die aan een project voor alleen Windows werk
 
 #### core.whitespace ####
 
-Git is standaard ingesteld om een aantal witruimte problemen te detecteren en te repareren. Het kan op vier veelvoorkomende witruimte problemen letten – twee staan er standaard aan en kunnen uitgezet worden, en twee staan standaard uit, maar kunnen aangezet worden.
+Git is standaard ingericht om een aantal witruimte problemen te detecteren en te repareren. Het kan op vier veelvoorkomende witruimte problemen letten – twee staan er standaard aan en kunnen uitgezet worden, en twee staan standaard uit, maar kunnen aangezet worden.
 
 De twee die standaard aan staan zijn `trailing-space`, waarmee wordt gekeken of er spaties aan het eind van een regel staan, en `space-before-tab`, wat kijkt of er spaties voor tabs staan aan het begin van een regel.
 
@@ -243,15 +278,15 @@ Je kunt Git vertellen welke van deze je aan wilt zetten door `core.whitespace` d
 	$ git config --global core.whitespace \
 	    trailing-space,space-before-tab,indent-with-non-tab
 
-Git zal deze problemen detecteren zodra je een `git diff` commando uitvoert en ze proberen in te kleuren zodat je ze kunt repareren voordat je ze commit. Het zal deze waarden ook gebruiken om je te helpen met patches toe te passen met `git apply`. Als je patches gaat toepassen, kan je Git vragen om je te waarschuwen als hij patches toepast waarin deze specifieke witruimte-problemen zitten:
+Git zal deze problemen detecteren zodra je een `git diff` commando uitvoert en ze proberen in te kleuren zodat je ze mogelijk kunt repareren voordat je ze commit. Het zal deze waarden ook gebruiken om je te helpen met patches toe te passen met `git apply`. Als je patches gaat applyen, kan je Git vragen om je te waarschuwen als hij patches toepast waarin deze specifieke witruimte-problemen zitten:
 
 	$ git apply --whitespace=warn <patch>
 
-Of je kunt Git vragen om automatisch deze problemen te repareren alvorens de patch toe te passen:
+Of je kunt Git vragen om automatisch deze problemen te repareren alvorens de patch te applyen:
 
 	$ git apply --whitespace=fix <patch>
 
-Deze opties zijn ook op het `git rebase` commando van toepassing. Als je witruimte problemen gecommit hebt maar ze nog niet stroomopwaarts gepushed hebt, kun je een `rebase` uitvoeren met de `--whitespace=fix` optie om Git automatisch witruimte problemen te laten repareren zodra het de patches herschrijft.
+Deze opties zijn ook op het `git rebase` commando van toepassing. Als je witruimte problemen gecommit hebt maar ze nog niet stroomopwaarts gepushed hebt, kun je een `rebase` uitvoeren met de `--whitespace=fix` optie om Git automatisch witruimte problemen te laten repareren terwijl het de patches herschrijft.
 
 ### Server configuratie ###
 
@@ -259,35 +294,35 @@ Er zijn lang niet zoveel configuratie opties beschikbaar voor de server kant van
 
 #### receive.fsckObjects ####
 
-Standaard zal Git niet alle objecten die hij ontvangt bij een push op consistentie controleren. Alhoewel Git kan controleren of ieder object nog steeds bij zijn SHA-1 checksum past en naar geldige objecten wijst, doet hij dat niet standaard bij iedere push. Het is een relatief dure operatie en kan veel extra tijd kosten bij iedere push, afhankelijk van de grootte van het repository of de push. Als je wilt dat Git ieder object op consistentie controleert bij elke push, dan kun je dit afdwingen door `receive.fsckObjects` op true te zetten:
+Standaard zal Git niet alle objecten die tijdens een push ontvangen worden op consistentie controleren. Alhoewel Git kan controleren of ieder object nog steeds bij zijn SHA-1 checksum past en naar geldige objecten wijst, doet gebeurt dat niet standaard bij iedere push. Het is een relatief dure operatie en kan veel extra tijd kosten bij iedere push, afhankelijk van de grootte van het repository of de push. Als je wilt dat Git ieder object op consistentie controleert bij elke push, dan kun je dit afdwingen door `receive.fsckObjects` op true te zetten:
 
 	$ git config --system receive.fsckObjects true
 
-Nu zal Git de integriteit van je repository controleren voordat een push geaccepteerd wordt, om er zeker van te zijn dat defecte clients geen corrupte gegevens introduceren.
+Nu zal Git de integriteit van de repository controleren voordat een push geaccepteerd wordt, om er zeker van te zijn dat defecte clients geen corrupte gegevens introduceren.
 
 #### receive.denyNonFastForwards ####
 
-Als je commits rebased die je al gepushed hebt en dan nog eens pushed, of op een andere manier een commit probeert te pushen naar een remote branch die niet de commit bevat waarnaar de remote branch op dat moment wijst, dan wordt dat afgewezen. Dit is in het algemeen goed beleid, maar in het geval van de rebase kan je besluiten dat je weet waar je mee bezig bent en kan je de remote branch geforceerd vernieuwen door een `-f` vlag met je push commando mee te geven.
+Als je commits rebased die je al gepusht hebt en dan nog eens pusht, of op een andere manier een commit probeert te pushen naar een remote branch die niet de commit bevat waarnaar de remote branch op dat moment wijst, dan wordt dat afgewezen. Dit is over het algemeen goed beleid, maar in het geval van de rebase kan je besluiten dat je weet waar je mee bezig bent en kan je de remote branch geforceerd vernieuwen door een `-f` vlag met je push commando mee te geven.
 
 Om de mogelijkheid van het geforceerd vernieuwen van remote branches naar niet fast-forward referenties uit te schakelen, stel je `receive.denyNonFastForwards` in:
 
 	$ git config --system receive.denyNonFastForwards true
 
-Een andere manier waarop je dit kunt doen is het instellen van ontvangst haken op de server wat we zo meteen gaan behandelen. Die aanpak stelt je in staat meer complexe dingen te doen, zoals het weigeren van niet fast-forwards aan een bepaalde groep gebruikers.
+Een andere manier waarop je dit kunt doen is het instellen van ontvangst hooks op de server wat we zo meteen gaan behandelen. Die aanpak stelt je in staat meer complexe dingen te doen, zoals het weigeren van niet fast-forwards afkomstig van een bepaalde groep gebruikers.
 
 #### receive.denyDeletes ####
 
-Een van de manieren waarop een gebruiker het `denyNonFastForwards` beleid kan omzeilen is dat hij de branch verwijdert en het dan opnieuw terug pushed met een nieuwe referentie. In nieuwere versies van Git (beginnend bij versie 1.6.1), kun je `receive.denyDeletes` op true zetten:
+Een van de manieren waarop een gebruiker het `denyNonFastForwards` beleid kan omzeilen is door de branch te verwijderen en het dan opnieuw terug pushen met de nieuwe referenties. In nieuwere versies van Git (beginnend bij versie 1.6.1), kun je `receive.denyDeletes` op true zetten:
 
 	$ git config --system receive.denyDeletes true
 
-Dit zal systeembreed branch en tag verwijdering door middel van een push weigeren; geen enkele gebruiker mag het meer. Om remote branches te verwijderen, moet je de ref bestanden handmatig verwijderen van de server. Er zijn ook interessantere manieren om dit per gebruiker af te dwingen door middel van ACL's, zoals je zult leren aan het eind van dit hoofdstuk.
+Dit zal systeembreed branch en tag verwijdering door middel van een push weigeren - geen enkele gebruiker mag het meer. Om remote branches te verwijderen, moet je de ref bestanden handmatig verwijderen van de server. Er zijn ook interessantere manieren om dit per gebruiker af te dwingen door middel van ACL's, zoals je zult leren aan het eind van dit hoofdstuk.
 
 ## Git attributen ##
 
-Een aantal van deze instellingen kan ook gedaan worden voor een pad, zodat Git die instellingen alleen toepast voor een subdirectory of subset van bestanden. Deze pad-specifieke instellingen worden Git attributen genoemd en worden in een `.gitattribute` bestand in een van je directories (normaliter in de hoofddirectory van je project) of in het `.git/info/attributes` bestand als je niet wilt dat het attributes bestand gecommit wordt met je project.
+Een aantal van deze instellingen kan ook gedaan worden voor een pad, zodat Git die instellingen alleen toepast voor een subdirectory of subset van bestanden. Deze pad-specifieke instellingen worden Git attributen genoemd en worden in een `.gitattribute` bestand in een van je directories gezet (normaliter in de hoofddirectory van je project) of in het `.git/info/attributes` bestand als je niet wilt dat het attributes bestand gecommit wordt met je project.
 
-Door attributen te gebruiken kun je dingen doen als het specificeren van aparte merge strategieën voor individuele bestanden of directories in je project, Git vertellen hoe hij niet-tekst bestanden kan diff'en, of Git inhoud laten filteren voordat je het in- of uitchecked van Git. In deze paragraaf zal je iets leren over de attributen die je kun instellen op de paden in je Git project en een paar voorbeelden zien hoe je deze eigenschap in de praktijk gebruikt.
+Door attributen te gebruiken kun je dingen doen als het specificeren van aparte merge strategieën voor individuele bestanden of directories in je project, Git vertellen hoe niet-tekst bestanden moeten worden gediff'ed, of Git inhoud laten filteren voordat je het in- of uitcheckt van Git. In deze paragraaf zal je iets leren over de attributen die je kun instellen op de paden in je Git project en een paar voorbeelden zien hoe je deze eigenschappen in de praktijk gebruikt.
 
 ### Binaire bestanden ###
 
@@ -295,27 +330,27 @@ Een leuke truc waarvoor je Git attributen kunt gebruiken is het vertellen aan Gi
 
 #### Binaire bestanden identificeren ####
 
-Sommige bestanden zien eruit als tekstbestanden, maar moeten toch behandeld worden als binaire gegevens. Bijvoorbeeld, Xcode projecten op de Mac bevatten een bestand dat eindigt in `.pbxproj`, wat eigenlijk een JSON (javascript gegevens in platte tekst formaat) gegevensset is, dat geschreven wordt naar de schijf door de IDE en waarin je bouw instellingen enzovoorts opgeslagen zijn. Alhoewel het technisch gezien een tekstbestand is, omdat het volledig ASCII is, zul je het niet als zodanig willen behandelen omdat het eigenlijk een lichtgewicht gegevensbank is – je kunt de inhoud niet samenvoegen als twee mensen het gewijzigd hebben, en diffs zijn over het algemeen niet behulpzaam. Het bestand is bedoeld om gebruikt te worden door een machine. In essentie wil je het behandelen als een binair bestand.
+Sommige bestanden zien eruit als tekstbestanden, maar moeten toch behandeld worden als binaire gegevens. Bijvoorbeeld, Xcode projecten op de Mac bevatten een bestand dat eindigt in `.pbxproj`, wat eigenlijk een JSON (javascript gegevens in platte tekst formaat) gegevensset is, dat geschreven wordt naar de schijf door de IDE en waarin je bouw-instellingen enzovoorts opgeslagen zijn. Alhoewel het technisch gezien een tekstbestand is, omdat het volledig ASCII is, zul je het niet als zodanig willen behandelen omdat het eigenlijk een lichtgewicht gegevensbank is – je kunt de inhoud niet mergen als twee mensen het gewijzigd hebben, en diffs zijn over het algemeen niet behulpzaam. Het bestand is bedoeld om gebruikt te worden door een machine. In essentie wil je het behandelen als een binair bestand.
 
 Om Git te vertellen dat hij alle `pbxproj` bestanden als binaire gegevens moet behandelen, voeg je de volgende regel toe aan je `.gitattributes` bestand:
 
 	*.pbxproj -crlf -diff
 
-Nu zal Git niet proberen om CRLF problemen te corrigeren of repareren; noch zal het proberen een diff te berekenen of te tonen voor de veranderingen in dit bestand als je `git show` of `git diff` uitvoert op je project. In de 1.6 serie van Git, kun je ook het ingebouwde macro `binary` gebruiken die `-crlf -diff` betekend:
+Nu zal Git niet proberen om CRLF problemen te corrigeren of repareren; noch zal het proberen een diff te berekenen of te tonen voor de veranderingen in dit bestand als je `git show` of `git diff` uitvoert op je project. In de 1.6 serie van Git, kun je ook het ingebouwde macro `binary` gebruiken die `-crlf -diff` vervangt:
 
 	*.pbxproj binary
 
 #### Binaire bestanden diff'en ####
 
-In Git kan je de functionaliteit van Git attributen gebruiken om binaire bestanden uiteindelijk toch te diff'en. Je doet dit door Git te vertellen hoe het de binaire gegevens naar tekst formaat moet omzetten, die dan via de normale diff vergeleken kan worden. Maar de vraag is hoe je de *binaire* gegevens naar tekst omzet. De beste oplossing is om een tool t vinden die deze conversie van binair naar tekstformaat voor je doet. Helaas kunnen weinig binaire formaten als mens-leesbaar formaat gerepresenteerd worden (probeer maar eens de gegevens van een geluidsfragment om te zetten naar tekst). Als dit het geval is en je bent er niet in geslaagd om een tekst-representatie te krijgen van de inhoud van het bestand is het vaak relatief eenvoudig om een menselijk leesbare omschrijving van de inhoud, of metadata te verkrijgen. Metadata geeft je niet een volledige representatie van de inhoud van het bestand, maar het is in elk geval beter dan niets.
+In Git kan je de functionaliteit van Git attributen gebruiken om binaire bestanden uiteindelijk toch te diff'en. Je doet dit door Git te vertellen hoe het de binaire gegevens naar tekst formaat moet omzetten, die dan via de normale diff vergeleken kan worden. Maar de vraag is hoe je de *binaire* gegevens naar tekst omzet. De beste oplossing is om een tool te vinden die deze conversie van binair naar tekstformaat voor je doet. Helaas kunnen weinig binaire formaten als mens-leesbaar formaat gerepresenteerd worden (probeer maar eens de gegevens van een geluidsfragment om te zetten naar tekst). Als dit het geval is en je bent er niet in geslaagd om een tekst-representatie te krijgen van de inhoud van het bestand, is het vaak relatief eenvoudig om een menselijk leesbare omschrijving van de inhoud of metadata te verkrijgen. Metadata geeft je niet een volledige representatie van de inhoud van het bestand, maar het is in elk geval beter dan niets.
 
 We gaan beide beschreven varianten gebruiken om bruikbare diff's te krijgen voor vaakgebruikte binaire formaten.
 
-Even terzijde: Er zijn verscheidene binaire formaten met een tekstinhoud waar moeilijk een bruikbare converter voor te vinden is. In die gevallen kan je proberen een tekst uit het bestand extraheren met het `strings` programma. Sommige van deze bestanden zouden een UTF-16 encoding of andere "codepages" kunnen gebruiken en `strings` kan dan niets bruikbaars in die bestanden vinden. Resultaten in het verleden geven geen garantie voor de toekomst. Echter `strings` wordt geleverd bij de meeste Mac en Linux systemen, dus het zou een goede eerste kandidaat zijn om dit te proberen bij veel binaire formaten.
+Even een terzijde: Er zijn verscheidene binaire formaten met een tekstinhoud waar moeilijk een bruikbare converter voor te vinden is. In die gevallen kan je proberen een tekst uit het bestand extraheren met het `strings` programma. Sommige van deze bestanden zouden een UTF-16 encoding of andere "codepages" kunnen gebruiken en dan kan `strings` niets bruikbaars in die bestanden vinden. Resultaten in het verleden geven geen garantie voor de toekomst. Echter `strings` wordt geleverd bij de meeste Mac en Linux systemen, dus het zou een goede eerste kandidaat zijn om dit te proberen bij veel binaire formaten.
 
 #### MS Word bestanden ####
 
-Ten eerste zullen we de beschreven techniek gebruiken om een van de meest ergerlijke problemen in de menselijke geschiedenis op te lossen: Word documenten versioneren. Iedereen weet dat Word een van de ergste editors verkrijgbaar is, maar vreemd genoeg: iedereen gebruikt het. Als je Word documenten in versie beheer wilt krijgen, kan je ze in een Git repostiory gooien en om de zoveel tijd een commit uitvoeren, maar wat voor nut heeft dit? Als je `git diff` uitvoert, zou je iets als dit zien:
+Ten eerste zullen we de beschreven techniek gebruiken om een van de meest ergerlijke problemen in de menselijke geschiedenis op te lossen: Word documenten onder versiebeheer brengen. Iedereen weet dat Word een van de slechtste editors verkrijgbaar is; maar, vreemd genoeg, iedereen gebruikt het. Als je Word documenten in versie beheer wilt krijgen, kan je ze in een Git repostiory gooien en om de zoveel tijd een commit uitvoeren, maar wat voor nut heeft dit? Als je `git diff` uitvoert, zou je iets als dit zien:
 
 
 	$ git diff
@@ -323,11 +358,11 @@ Ten eerste zullen we de beschreven techniek gebruiken om een van de meest ergerl
 	index 88839c4..4afcb7c 100644
 	Binary files a/chapter1.doc and b/chapter1.doc differ
 
-Je kunt niet direct twee versies vergelijken tenzij je ze uitchecked en handmatig doorneemt, toch? Maar het blijkt dat je dit toch redelijk goed met Git attributen kunt doen. Zet de volgende regel in je `.gitattributes` bestand:
+Je kunt niet direct twee versies vergelijken tenzij je ze uitcheckt en handmatig doorneemt, toch? Maar gelukkig kan je dit toch redelijk goed met Git attributen doen. Zet de volgende regel in je `.gitattributes` bestand:
 
 	*.doc diff=word
 
-Dit vertelt Git dat allel bestanden die in het patroon (.doc) passen het "word" filter moeten gebruiken als je een diff probeert te bekijken die wijzigingen bevat. Wat is dat "word" filter eigenlijk? Je moet het zelf opzetten. Hier ga je Git configureren om het `catdoc` programma te gebruiken, die specifiek geschreven is om tekst uit binaire MS Word documenten te extraheren (je kunt het krijgen op `http://www.wagner.pp.ru/~vitus/software/catdoc/`), om Word documenten in leesbare tekstbestanden te converteren, en die vervolgens juist diff'en:
+Dit vertelt Git dat alle bestanden die in het patroon (.doc) passen het "word" filter moeten gebruiken als je een diff probeert te bekijken die wijzigingen bevat. Wat is dat "word" filter eigenlijk? Je moet het zelf opzetten. Hier ga je Git configureren om het `catdoc` programma te gebruiken, die specifiek geschreven is om tekst uit binaire MS Word documenten te extraheren (je kunt het krijgen op `http://www.wagner.pp.ru/~vitus/software/catdoc/`), om Word documenten in leesbare tekstbestanden te converteren, en die vervolgens juist diff'en:
 
 	$ git config diff.word.textconv catdoc
 
@@ -336,7 +371,7 @@ Dit commando voegt een sectie toe aan je `.git/config`, wat er ongeveer zo uitzi
 	[diff "word"]
 		textconv = catdoc
 
-Nu weet Git dat wanneer het probeert een diff uit te voeren tussen twee snapshots, en bestandsname eindigen op `.doc` dat het deze bestanden door de "word" filter moet halen, die gedefinieerd is als het `catdoc` programma. Effectief maakt het twee gewone tekst-gebaseerde versies van je Word bestanden vooraleer te proberen ze met diff te vergelijken.
+Nu weet Git dat wanneer het probeert een diff uit te voeren tussen twee snapshots, en bestandsnamen eindigen op `.doc` dat het deze bestanden door de "word" filter moet halen, die gedefinieerd is als het `catdoc` programma. Effectief maakt het twee gewone tekst-gebaseerde versies van je Word bestanden vooraleer te proberen ze met diff te vergelijken.
 
 Hier is een voorbeeld. Ik heb hoofdstuk 1 van dit boek in Git gezet, wat tekst in een paragraaf toegevoegd en daarna het document gesaved. Daarna voerde ik `git diff` uit om te zien wat er gewijzigd was:
 
@@ -407,12 +442,12 @@ Nu zal `git diff` je kunnen vertellen wat er gewijzigd is in `.odt` bestanden.
 
 ##### Beeldbestanden #####
 
-Een ander interessant probleem dat je hiermee kunt oplossen is het diff'en van beeldbestanden. Een manier om dit te doen is PNG bestanden door een filter te halen dat de EXIF informatie eruit peutert; dat is metadata die wordt opgeslagen bij de meeste beeldbestand formaten. Als je het `exiftool` programma download en installeert, kan je dit gebruiken om je plaatjes naar tekst over de metadata om te zetten, zodat de diff op z'n minst een tekstuele representatie van eventuele wijzigingen laat zien:
+Een ander interessant probleem dat je hiermee kunt oplossen is het diff'en van beeldbestanden. Een manier om dit te doen is PNG bestanden door een filter te halen dat de EXIF informatie eruit peutert - dat is metadata die wordt opgeslagen bij de meeste beeldbestand formaten. Als je het `exiftool` programma downloadt en installeert, kan je dit gebruiken om je plaatjes naar tekst over de metadata om te zetten, zodat de diff op z'n minst een tekstuele representatie van eventuele wijzigingen laat zien:
 
 	$ echo '*.png diff=exif' >> .gitattributes
 	$ git config diff.exif.textconv exiftool
 
-Als je een plaatje in je project verandert en `git diff` uitvoert, dan zie je zoiets als dit:
+Als je een plaatje in je project vervangt en `git diff` uitvoert, dan zie je zoiets als dit:
 
 	diff --git a/image.png b/image.png
 	index 88839c4..4afcb7c 100644
@@ -439,21 +474,21 @@ Je kunt eenvoudig zien dat zowel de bestandsgrootte als de beeld dimensies gewij
 
 Keyword expansie zoals in SVN of CVS gebruikt wordt, wordt vaak gevraagd door ontwikkelaars die gewend zijn aan die systemen. Het grote probleem in Git is dat je een bestand niet mag wijzigen met informatie over de commit nadat je het gecommit hebt, omdat Git eerst de checksum van het bestand maakt. Maar, je kunt tekst in een bestand injecteren zodra het uitgechecked wordt en dit weer verwijderen voordat het aan een commit toegevoegd wordt. Met Git attributen zijn er twee manieren om dit te doen.
 
-Als eerste kun je de SHA-1 checksum van een blob automatisch in een `$Id$` veld in het bestand stoppen. Als je dit attribuut in een bestand of aantal bestanden zet, dan zal Git de volgende keer dat je die branch uitchecked dat veld vervangen met de SHA-1 van de blob. Het is belangrijk om op te merken dat het niet de SHA van de commit is, maar van de blob zelf:
+Als eerste kun je de SHA-1 checksum van een blob automatisch in een `$Id$` veld in het bestand stoppen. Als je dit attribuut in een bestand of aantal bestanden zet, dan zal Git de volgende keer dat je die branch uitcheckt dat veld vervangen met de SHA-1 van de blob. Het is belangrijk om op te merken dat het niet de SHA van de commit is, maar van de blob zelf:
 
 	$ echo '*.txt ident' >> .gitattributes
 	$ echo '$Id$' > test.txt
 
-De volgende keer dat je dit bestand uitchecked, injecteert Git de SHA van de blob:
+De volgende keer dat je dit bestand uitcheckt, injecteert Git de SHA van de blob:
 
 	$ rm text.txt
 	$ git checkout -- text.txt
 	$ cat test.txt
 	$Id: 42812b7653c7b88933f8a9d6cad0ca16714b9bb3 $
 
-Maar, het resultaat heeft slechts een beperkt nut. Als je sleutelwoord vervanging (keyword substitution) in CVS of Subversion gebruikt hebt, kun je een datumstempel toevoegen – de SHA is niet zo bruikbaar, omdat het vrij willekeurig is en je kunt niet zeggen of de ene SHA ouder of nieuwer is dan de andere.
+Echter dit resultaat heeft slechts een beperkte nut. Als je sleutelwoord vervanging (keyword substitution) in CVS of Subversion gebruikt hebt, kun je een datumstempel toevoegen – de SHA is niet zo bruikbaar, omdat het vrij willekeurig is en je kunt niet zeggen of de ene SHA ouder of nieuwer is dan de andere.
 
-Je kunt echter je eigen filters voor het doen van vervanging bij commit/checkout schrijven. Dit zijn de "kuis" ("clean") en "besmeer" ("smudge") filters. In het `.gitattributes` bestand kan je een filter op bepaalde paden instellen en dan scripts instellen die bestanden bewerkt vlak voordat ze uitgechecked worden ("smudge", zie Figuur 7-2) en vlak voordat ze gecommit worden ("clean", zie Figuur 7-3). De filters kunnen ingesteld worden om allerlei leuke dingen doen.
+Je kunt echter je eigen filters voor het doen van vervanging bij commit/checkout schrijven. Dit zijn de "kuis" ("clean") en "besmeer" ("smudge") filters. In het `.gitattributes` bestand kan je voor bepaalde paden een filter instellen en dan scripts instellen die bestanden bewerkt vlak voordat ze uitgechecked worden ("smudge", zie Figuur 7-2) en vlak voordat ze gecommit worden ("clean", zie Figuur 7-3). De filters kunnen ingesteld worden om allerlei leuke dingen doen.
 
 Insert 18333fig0702.png
 Figuur 7-2. Het “smudge” filter wordt bij checkout uitgevoerd.
@@ -470,26 +505,26 @@ Vervolgens vertel je Git wat het "indent" filter doet bij smudge en clean:
 	$ git config --global filter.indent.clean indent
 	$ git config --global filter.indent.smudge cat
 
-In dit geval zal Git, als je bestanden commit die op `*.c` passen, ze door het indent programma halen alvorens ze te committen, en ze door het `cat` programma halen alvorens ze op de schijf uit te checken. Het `cat` programma is eigenlijk een no-op: het geeft de gegevens onveranderd door. Deze combinatie zal effectief alle C broncode bestanden door `indent` filteren alvorens te committen.
+In dit geval zal Git, als je bestanden commit die met `*.c` overeenkomen, ze door het indent programma halen alvorens ze te committen, en ze door het `cat` programma halen alvorens ze op de schijf uit te checken. Het `cat` programma is eigenlijk een no-op: het geeft de gegevens onveranderd door. Deze combinatie zal effectief alle C broncode bestanden door `indent` filteren alvorens te committen.
 
-Een ander interessant voorbeeld is `$Date$` sleutelwoord expansie, in RCS stijl. Om dit goed te doen, moet je een klein script hebben dat een bestandsnaam pakt, de laatste commit datum voor dit project opzoekt, en de datum in een bestand toevoegt. Hier volgt een klein Ruby script dat dat doet:
+Een ander interessant voorbeeld is `$Date$` sleutelwoord expansie, in RCS stijl. Om dit goed te doen, moet je een klein script hebben dat een bestandsnaam pakt, de laatste commit datum voor dit project opzoekt, en de datum in dat bestand toevoegt. Hier volgt een klein Ruby script dat dat doet:
 
 	#! /usr/bin/env ruby
 	data = STDIN.read
 	last_date = `git log --pretty=format:"%ad" -1`
 	puts data.gsub('$Date$', '$Date: ' + last_date.to_s + '$')
 
-Het enige dat het script doet is de laatste commit datum uit het `git log` commando halen, het in iedere `$Date$` tekst stoppen die het in stdin ziet, en de resultaten afdrukken – het moet eenvoudig te copieren zijn in welke taal je het beste thuisbent. Je kunt dit bestand `expand_date` noemen en het in je pad stoppen. Nu moet je een filter in Git instellen (noem het `dater`), en het vertellen jouw `expand_date` filter te gebruiken om de bestanden tijdens checkout te 'besmeren'. Je zult een Perl expressie gebruiken om dat op te ruimen tijdens een commit:
+Het enige dat het script doet is de laatste commit datum uit het `git log` commando halen, het in iedere `$Date$` tekst stoppen die het in stdin ziet, en de resultaten afdrukken – het moet eenvoudig na te bouwen zijn in de taal waar je het beste in thuisbent. Je kunt dit bestand `expand_date` noemen en het in je pad stoppen. Nu moet je een filter in Git instellen (noem het `dater`), en het vertellen jouw `expand_date` filter te gebruiken om de bestanden tijdens checkout te 'besmeren'. Je zult een Perl expressie gebruiken om dat op te ruimen tijdens een commit:
 
 	$ git config filter.dater.smudge expand_date
 	$ git config filter.dater.clean 'perl -pe "s/\\\$Date[^\\\$]*\\\$/\\\$Date\\\$/"'
 
-Dit stukje Perl haalt alles weg dat het in en `$Date$` tekst ziet, om weer op het uitgangspunt uit te komen. Nu je filter klaar is, kun je het testen door een bestand aan te maken met het `$Date$` sleutelwoord en dan een Git attribuut voor dat bestand in te stellen, die het nieuwe filter gebruikt.
+Dit stukje Perl haalt alles weg dat het in een `$Date$` tekst ziet, om weer op het uitgangspunt uit te komen. Nu je filter klaar is, kun je het testen door een bestand aan te maken met het `$Date$` sleutelwoord en dan een Git attribuut voor dat bestand in te stellen, die het nieuwe filter aanroept.
 
 	$ echo '# $Date$' > date_test.txt
 	$ echo 'date*.txt filter=dater' >> .gitattributes
 
-Als je die veranderingen commit en het bestand opnieuw uitchecked, zul je zien dat het sleutelwoord correct vervangen is:
+Als je die veranderingen commit en het bestand opnieuw uitcheckt, zal je zien dat het sleutelwoord correct vervangen wordt:
 
 	$ git add date_test.txt .gitattributes
 	$ git commit -m "Testing date expansion in Git"
@@ -506,9 +541,9 @@ De Git attribute gegevens staan je ook toe om interessante dingen te doen als je
 
 #### export-ignore ####
 
-Je kunt Git vertellen dat sommige bestanden of directories niet geëxporteerd moeten worden als een archief gegenereerd wordt. Als er een subdirectory of bestand is waarvan je niet wil dat het wordt meegenomen in je archief bestand, maar dat je wel in je project ingechecked wil hebben, dan kun je die bestanden bepalen met behulp van het `export-ignore` attribuut.
+Je kunt Git vertellen dat sommige bestanden of directories niet geëxporteerd moeten worden bij het genereren van een archief. Als er een subdirectory of bestand is waarvan je niet wilt dat het wordt meegenomen in je archief bestand, maar dat je wel in je project ingecheckt wil hebben, dan kun je die bestanden bepalen met behulp van het `export-ignore` attribuut.
 
-Bijvoorbeeld, stel dat je wat testbestanden in een `test/` submap hebt, en dat het geen zin heeft om die in de tarball export van je project mee te nemen. Dan kan je de volgende regel in je Git attributes bestand toevoegen:
+Bijvoorbeeld, stel dat je wat testbestanden in een `test/` subdirectory hebt, en dat het geen zin heeft om die in de tarball export van je project mee te nemen. Dan kan je de volgende regel in je Git attributes bestand toevoegen:
 
 	test/ export-ignore
 
@@ -516,7 +551,7 @@ Als je nu git archive uitvoert om een tarball van je project te maken, zal die m
 
 #### export-subst ####
 
-Iets anders dat je kunt doen met je archieven is eenvoudige sleutelwoord vervanging. Git staat je toe om de tekst `$Format:$` met een van de `--pretty=format` formaat afkortingen in één of meer bestanden te zetten,. Voorbeelden van die formaatafkortingen zag je al in Hoofdstuk 2. Bijvoorbeeld, als je een bestand genaamd `LAST_COMMIT` wilt meenemen in je project, waarin de laatste commit datum automatisch wordt geïnjecteerd als `git archive` loopt, kun je het bestand als volgt instellen:
+Iets anders dat je kunt doen met je archieven is eenvoudige sleutelwoord vervanging. Git staat je toe om de tekst `$Format:$` met een van de `--pretty=format` formaat afkortingen in één of meer bestanden te zetten. Veel voorbeelden van die formaatafkortingen zag je al in Hoofdstuk 2. Bijvoorbeeld, als je een bestand genaamd `LAST_COMMIT` wilt meenemen in je project, waarin de laatste commit datum automatisch wordt geïnjecteerd als `git archive` loopt, kun je het bestand als volgt instellen:
 
 	$ echo 'Last commit date: $Format:%cd$' > LAST_COMMIT
 	$ echo "LAST_COMMIT export-subst" >> .gitattributes
@@ -530,9 +565,9 @@ Als je `git archive` uitvoert, zal de inhoud van dat bestand, als mensen het arc
 
 ### Merge strategieën ###
 
-Je kunt Git attributen ook gebruiken om Git te vertellen dat het verschillende merge strategieën moet gebruiken voor specifieke bestanden in je project. Een erg handige optie is Git te vertellen dat het niet moet proberen bepaalde bestanden te mergen als ze conflicten hebben, maar jouw versie moeten gebruiken in plaats van die van de ander.
+Je kunt Git attributen ook gebruiken om Git te vertellen dat het verschillende merge strategieën moet gebruiken voor specifieke bestanden in je project. Een erg handige toepassing is Git te vertellen dat het bepaalde bestanden niet moet proberen te mergen als ze conflicten hebben, maar jouw versie moeten gebruiken in plaats van die van de ander.
 
-Dit is handig als een branch in je project af is geweken of gespecialiseerd is, je wel in staat wilt zijn om veranderingen daarvan te mergen, maar je wilt bepaalde bestanden negeren. Stel dat je een database instellingen bestand hebt dat database.xml heet en dat in twee branches verschillend is, en je wilt de andere branch mergen zonder jouw database bestand te verprutsen. Je kunt dan een attribuut als volgt instellen:
+Dit is handig als een branch in jouw project uiteen is gelopen of gespecialiseerd is, maar je wel in staat wilt zijn om veranderingen daarvan te mergen, en je wilt bepaalde bestanden negeren. Stel dat je een database instellingen bestand hebt dat database.xml heet en dat in twee branches verschillend is, en je wilt de andere branch mergen zonder jouw database bestand overhoop te halen. Je kunt dan een attribuut als volgt instellen:
 
 	database.xml merge=ours
 
@@ -546,7 +581,7 @@ In dit geval blijft database.xml staan op de versie die je origineel al had.
 
 ## Git haken (hooks) ##
 
-Zoals vele andere Versie Beheer Systemen, heeft Git een manier om eigengemaakte scripts op te starten wanneer bepaalde belangrijke acties plaatsvinden. Er zijn twee groepen van dit soort hooks: aan de client kant en aan de server kant. De hooks aan de client kant zijn voor client operaties zoals committen en mergen. De hooks voor de server kant zijn voor Git server operaties zoals het ontvangen van gepushte commits. Je kunt deze hooks om allerlei redenen gebruiken, en je zult hier over een aantal ervan leren.
+Zoals vele andere Versie Beheer Systemen, heeft Git een manier om eigengemaakte scripts aan te roepen wanneer bepaalde belangrijke acties plaatsvinden. Er zijn twee groepen van dit soort hooks: aan de client kant en aan de server kant. De hooks aan de client kant zijn voor client operaties zoals committen en mergen. De hooks voor de server kant zijn voor Git server operaties zoals het ontvangen van gepushte commits. Je kunt deze hooks om allerlei redenen gebruiken, en je zult hier over een aantal ervan kunnen lezen.
 
 ### Een hook installeren ###
 
@@ -556,61 +591,61 @@ Om een hook script aan te zetten, zet je een bestand met de juiste naam en dat u
 
 ### Hooks aan de client-kant ###
 
-Er zijn veel hooks aan de client-kant. Deze paragraaf verdeelt ze in commit-werkwijze hooks, e-mail-werkwijze scripts, en de rest van de client-kant scripts
+Er zijn veel hooks aan de client-kant. Deze paragraaf verdeelt ze in commit-workflow hooks, e-mail-workflow scripts, en de rest van de client-kant scripts
 
-#### Commit-werkwijze haken ####
+#### Commit-workflow hooks ####
 
-De eerste vier hooks hebben te maken met het commit proces. De `pre-commit` hook wordt eerst uitgevoerd, nog voor je een commit boodschap intypt. Het wordt gebruikt om het snapshot dat op het punt staat gecommit te worden te inspecteren, om te zien of je iets bent vergeten, om er zeker van te zijn dat tests uitgevoerd worden of om wat je maar wilt te onderzoeken in de code. Als deze hook met een exit-waarde anders dan nul eindigt breekt de commit af, alhoewel je dit kunt omzeilen met `git commit --no-verify`. Je kunt dingen doen als op code stijl controleren (door lint of iets dergelijks uit te voeren), op 'trailing whitespaces' te controleren (de standaard hook doet dat), of om de juiste documentatie op nieuwe methodes te controleren.
+De eerste vier hooks hebben te maken met het commit proces. De `pre-commit` hook wordt eerst uitgevoerd, nog voor je een commit boodschap intypt. Het wordt gebruikt om het snapshot dat op het punt staat gecommit te worden te inspecteren, om te zien of je iets bent vergeten, om er zeker van te zijn dat tests uitgevoerd worden of om wat je maar wilt te onderzoeken in de code. Als deze hook met een exit-waarde anders dan nul eindigt breekt de commit af, alhoewel je dit kunt omzeilen met `git commit --no-verify`. Je kunt dingen doen als op code stijl controleren (door lint of iets dergelijks uit te voeren), op 'trailing whitespaces' te controleren (de standaard hook doet precies dat), of om de juiste documentatie op nieuwe methodes te controleren.
 
 De `prepare-commit-msg` hook wordt uitgevoerd voordat de commit boodschap editor gestart wordt, maar nadat de standaard boodschap aangemaakt is. Het stelt je in staat om de standaard boodschap aan te passen voordat de commit auteur het ziet. Deze hook accepteert een aantal opties: het pad naar het bestand dat de huidige commit boodschap bevat, het type van de commit, en de SHA-1 van de commit als het een verbeterde (amended) commit betreft. Deze hook is voor normale commits niet zo bruikbaar, maar het is juist bruikbaar voor commits waarbij de standaard boodschap automatisch gegenereerd wordt, zoals sjabloon commit boodschappen, merge commits, gesquashte commits en amended commits. Je kan het samen met een commit sjabloon gebruiken om informatie programmatisch in te voegen.
 
-De `commit-msg` hook accepteert één parameter, wat weer het pad naar een tijdelijk bestand is dat de huidige commit boodschap bevat. Als dit script eindigt met een waarde anders dan nul, dan zal Git het commit proces afbreken, je kunt deze gebruiken om je project-status of de commit boodschap te valideren alvorens een commit toe te staan. In het laatste gedeelte van dit hoofdstuk, zal ik deze hook demonstreren hoe te controleren dat de commit boodschap aan een bepaald patroon voldoet.
+De `commit-msg` hook accepteert één parameter, wat, nogmaals, het pad naar een tijdelijk bestand is dat de huidige commit boodschap bevat. Als dit script eindigt met een waarde anders dan nul, dan zal Git het commit proces afbreken, je kunt deze gebruiken om je project-status of de commit boodschap te valideren alvorens een commit toe te staan. In het laatste gedeelte van dit hoofdstuk, zal ik met deze hook demonstreren hoe te controleren dat de commit boodschap aan een bepaald patroon voldoet.
 
 Nadat het hele commit proces afgerond is, zal de `post-commit` hook uitgevoerd worden. Het accepteert geen parameters, maar je kunt de laatste commit eenvoudig ophalen door `git log -1 HEAD` uit te voeren. Over het algemeen wordt dit script gebruikt om notificaties of iets dergelijks uit te sturen.
 
-De commit-werkwijze scripts aan de client-kant kunnen gebruikt worden in vrijwel iedere werkwijze. Ze worden vaak gebruikt om een bepaald beleid af te dwingen, maar het is belangrijk om op te merken dat deze scripts niet overgedragen worden bij het klonen. Je kunt beleid afdwingen aan de server kant door pushes of commits te weigeren die niet voldoen aan een bepaald beleid, maar het is aan de ontwikkelaar om deze scripts aan de client kant te gebruiken. Dus, deze scripts zijn er om ontwikkelaars te helpen en ze moeten door hen ingesteld en onderhouden worden, alhoewel ze door hen op elk moment aangepast of omzeild kunnen worden.
+De commit-workflow scripts aan de client-kant kunnen gebruikt worden in vrijwel iedere workflow. Ze worden vaak gebruikt om een bepaald beleid af te dwingen, maar het is belangrijk om op te merken dat deze scripts niet overgedragen worden bij het clonen. Je kunt beleid afdwingen aan de server kant door pushes of commits te weigeren die niet voldoen aan een bepaald beleid, maar het is aan de ontwikkelaar om deze scripts aan de client kant te gebruiken. Dus, deze scripts zijn er om ontwikkelaars te helpen en ze moeten door hen ingesteld en onderhouden worden, alhoewel ze door hen op elk moment aangepast of omzeild kunnen worden.
 
-#### E-mail werkwijze hooks ####
+#### E-mail workflow hooks ####
 
-Je kunt drie client-kant hooks instellen voor een e-mail gebaseerde werkwijze. Ze worden allemaal aangeroepen door het `git am` commando dus als je dat commando niet gebruikt in je werkwijze, dan kun je gerust doorgaan naar de volgende paragraaf. Als je patches aanneemt via e-mail die door `git format-patch` geprepareerd zijn, dan zullen sommige van deze scripts nuttig zijn voor je.
+Je kunt drie client-kant hooks instellen voor een e-mail gebaseerde workflow. Ze worden allemaal aangeroepen door het `git am` commando dus als je dat commando niet gebruikt in je workflow, dan kun je gerust doorgaan naar de volgende paragraaf. Als je patches aanneemt via e-mail die door `git format-patch` geprepareerd zijn, dan zullen sommige van deze scripts nuttig zijn voor je.
 
 De eerste hook die uitgevoerd wordt is `applypatch-msg`. Het accepteert één enkel argument: de naam van het tijdelijke bestand dat de voorgedragen commit boodschap bevat. Git breekt de patch als dit script met een waarde ongelijk aan nul eindigt. Je kunt dit gebruiken om je ervan te verzekeren dat een commit boodschap juist geformatteerd is, of om de boodschap te normaliseren door het script de boodschap aan te laten passen.
 
-De volgende hook die wordt uitgevoerd tijdens het toepassen van patches via `git am` is `pre-applypatch`. Dit neemt geen argumenten aan en wordt uitgevoerd nadat de patch is toegepast, zodat je het kunt gebruiken om het snapshot te inspecteren alvorens de commit te doen. Je kunt tests uitvoeren of de werkmap op een andere manier inspecteren met behulp van dit script. Als er iets mist of één van de tests faalt, dan zal eindigen met niet nul het `git am` script afbreken zonder de patch te committen.
+De volgende hook die wordt uitgevoerd tijdens het toepassen van patches via `git am` is `pre-applypatch`. Dit neemt geen argumenten aan en wordt uitgevoerd nadat de patch is ge-applyed, zodat je het kunt gebruiken om het snapshot te inspecteren alvorens de commit te doen. Je kunt tests uitvoeren of de werkdirectory op een andere manier inspecteren met behulp van dit script. Als er iets mist of één van de tests faalt, dan zal eindigen met niet nul het `git am` script afbreken zonder de patch te committen.
 
 De laatste hook die uitgevoerd wordt tijdens een `git am` operatie is de `post-applypatch`. Je kunt dat gebruiken om een groep te notificeren of de auteur van de patch die je zojuist gepulled hebt. Je kunt het patch proces niet stoppen met behulp van dit script.
 
 #### Andere client hooks ####
 
-De `pre-rebase` hook wordt uitgevoerd voordat je ook maar iets rebased, en kan het proces afbreken door met een waarde anders dan nul te eindigen. Je kunt deze hook gebruiken om te voorkomen dat commits die al gepushed zijn gerebased worden. De voorbeeld `pre-rebase` hook die Git installeert doet dit, alhoewel deze er vanuit gaat dat "next" de naam is van de branch die je publiceert. Je zult dat waarschijnlijk moeten veranderen in de naam van je stabiele gepubliceerde branch.
+De `pre-rebase` hook wordt uitgevoerd voordat je ook maar iets rebased, en kan het proces afbreken door met een waarde anders dan nul te eindigen. Je kunt deze hook gebruiken om te voorkomen dat commits die al gepusht zijn gerebased worden. De voorbeeld `pre-rebase` hook die Git installeert doet dit, alhoewel deze er vanuit gaat dat "next" de naam is van de branch die je publiceert. Je zult dat waarschijnlijk moeten veranderen in de naam van je stabiele gepubliceerde branch.
 
-Nadat je een succesvolle `git checkout` uitgevoerd hebt, wordt de `post-checkout` hook uitgevoerd; je kunt het gebruiken om je werkdiorectory goed in te stellen voor je project omgeving. Dit kan het invoegen van grote binaire bestanden die je niet in versie beheer wil hebben inhouden, of het automatisch genereren van documentatie of iets in die geest.
+Nadat je een succesvolle `git checkout` uitgevoerd hebt, wordt de `post-checkout` hook uitgevoerd; je kunt het gebruiken om je werkdirectory goed in te stellen voor je project omgeving. Dit kan het invoegen van grote binaire bestanden die je niet in versie beheer wil hebben inhouden, of het automatisch genereren van documentatie of iets in die geest.
 
-Als laatste wordt de `post-merge` hook uitgevoerd na een succesvolle `merge` commando. Je kunt deze gebruiken om gegevens in de werkstructuur terug te zetten die Git niet kan ophalen, bijvoorbeeld permissie gegevens. Ook kan deze hook gebruikt worden om bestanden, die buiten het beheer van Git liggen, in je werkstructuur gekopieerd te krijgen zodra deze veranderd.
+Als laatste wordt de `post-merge` hook uitgevoerd na een succesvolle `merge` commando. Je kunt deze gebruiken om gegevens in de werkstructuur terug te zetten die Git niet kan ophalen, bijvoorbeeld permissie gegevens. Ook kan deze hook gebruikt worden om te valideren of bestanden, die buiten het beheer van Git liggen, in je werkstructuur zitten die je wellicht erin wilt kopiëren als de werk-tree wijzigt.
 
 ### Hooks aan de server-kant ###
 
-Naast de hooks aan de client-kant, kun je als systeem beheerder ook een paar belangrijke hooks aan de server-kant gebruiken om vrijwel elk beleid op het project af te dwingen. Deze scripts worden voor en na de pushes op de server uitgevoerd. De pre hooks kunnen met een getal anders dan nul laten eindigen om de push te weigeren en een foutmelding naar de client te sturen; je kunt een push beleid instellen dat zo complex is als je zelf wenst.
+Naast de hooks aan de client-kant, kun je als systeem beheerder ook een paar belangrijke hooks aan de server-kant gebruiken om vrijwel elk beleid op het project af te dwingen. Deze scripts worden voor en na de pushes op de server uitgevoerd. De pre hooks kunnen op elk gewenst moment met een getal anders dan nul eindigen om de push te weigeren en een foutmelding naar de client te sturen; je kunt een push beleid instellen dat zo complex is als je zelf wenst.
 
 #### pre-receive en post-receive ####
 
-Het eerste script dat uitgevoerd wordt tijdens het afhandelen van een push van een client is `pre-receive`. Het aanvaardt een lijst van referenties die worden gepusht van stdin; als het eindigt met een andere waarde dan nul, worden ze geen van allen geaccepteerd. Je kunt deze hook gebruiken om dingen te doen als valideren dat geen van de vernieuwde referenties een non-fast-forward is, of om te controleren dat de gebruiker die de push uitvoert creatie, verwijder, of push toegang heeft, of toegang om wijzigingen te pushen voor alle bestanden die ze proberen aan te passen met de push.
+Het eerste script dat uitgevoerd wordt tijdens het afhandelen van een push van een client is `pre-receive`. Het leest een lijst van referenties die worden gepusht van stdin; als het eindigt met een andere waarde dan nul, worden ze geen van allen geaccepteerd. Je kunt deze hook gebruiken om dingen te doen als valideren dat geen van de vernieuwde referenties een non-fast-forward is, of om te controleren dat de gebruiker die de push uitvoert creatie, verwijder, of push toegang heeft, of toegang om wijzigingen te pushen voor alle bestanden die ze proberen aan te passen met de push.
 
-De `post-receive` hook wordt uitgevoerd nadat het hele proces afgerond is, en het kan gebruikt worden om andere services te vernieuwen of gebruikers te notificeren. Het aanvaardt dezelfde stdin gegevens als de `pre-receive` hook. Voorbeelden zijn een e-mail sturen naar een lijst, een continue integratie server notificeren of het vernieuwen van een ticket-volg systeem. Je kunt zelfs de commit boodschappen doorlopen om te zien of er nog tickets zijn die moeten worden geopend, aangepast of afgesloten worden. Dit script kan het push proces niet stoppen, maar de client verbreekt de connectie niet totdat het afgerond is, wees dus een voorzichtig als je iets probeert te doen dat een lange tijd in beslag neemt.
+De `post-receive` hook wordt uitgevoerd nadat het hele proces afgerond is, en het kan gebruikt worden om andere services te vernieuwen of gebruikers te notificeren. Het leest dezelfde stdin gegevens als de `pre-receive` hook. Voorbeelden zijn een e-mail sturen naar een lijst, een continue integratie server notificeren of het vernieuwen van een ticket-volg systeem. Je kunt zelfs de commit boodschappen doorlopen om te zien of er nog tickets zijn die moeten worden geopend, aangepast of afgesloten worden. Dit script kan het push proces niet stoppen, maar de client verbreekt de connectie niet totdat het afgerond is, wees dus een voorzichtig als je iets probeert te doen dat een lange tijd in beslag kan nemen.
 
 #### update ####
 
-Het update script is vergelijkbaar met het `pre-receive` script, behalve dat het uitgevoerd wordt voor iedere branch die de pusher probeert te vernieuwen. Als de pusher naar meerdere branches probeert te pushen wordt `pre-receive` slechts één keer uitgevoerd, daarentegen loopt `update` bij iedere branch waar ze naar pushen. In plaats van stdin te lezen, aanvaardt dit script drie argumenten: de naam van de referentie (branch), de SHA-1 waar die referentie naar wees vóór de push, en de SHA-1 die de gebruiker probeert te pushen. Als het update script met een andere waarde dan nul eindigt, wordt alleen die referentie geweigerd; andere referenties kunnen nog steeds vernieuwd worden.
+Het update script is vergelijkbaar met het `pre-receive` script, behalve dat het uitgevoerd wordt voor iedere branch die de pusher probeert te vernieuwen. Als de pusher naar meerdere branches probeert te pushen wordt `pre-receive` slechts één keer uitgevoerd, daarentegen loopt update bij iedere branch waar ze naar pushen. In plaats van stdin te lezen, accepteert dit script drie argumenten: de naam van de referentie (branch), de SHA-1 waar die referentie naar wees vóór de push, en de SHA-1 die de gebruiker probeert te pushen. Als het update script met een andere waarde dan nul eindigt, wordt alleen die referentie geweigerd; andere referenties kunnen nog steeds vernieuwd worden.
 
 ## Een voorbeeld van Git-afgedwongen beleid ##
 
-In deze paragraaf ga je gebruiken wat je geleerd hebt om een Git werkwijze te maken, die controleert op een niet standaard commit boodschap formaat, afdwingt om alleen fast-forward pushes te accepteren en alleen bepaalde gebruikers toestaat om bepaalde subdirectories te wijzigen in een project. Je zult client scripts maken die de ontwikkelaar helpen te ontdekken of hun push geweigerd zal worden en server scripts die het beleid afdwingen.
+In deze paragraaf ga je gebruiken wat je geleerd hebt om een Git workflow te maken, die controleert op een aangepast commit boodschap formaat, afdwingt om alleen fast-forward pushes te accepteren en alleen bepaalde gebruikers toestaat om bepaalde subdirectories te wijzigen in een project. Je zult client scripts maken die de ontwikkelaar helpen te ontdekken of hun push geweigerd zal worden en server scripts die het beleid afdwingen.
 
-Ik heb Ruby gebruikt om ze te schrijven, zowel omdat het mijn voorkeur script taal is als omdat ik vind dat het de meest pseudo code uitziende taal is van de scripttalen; dus je zou in staat moeten zijn om de code redelijk te kunnen volgen zelfs als je geen Ruby gebruikt. Maar elke taal zou prima werken. Alle voorbeeld hook scripts die met Git meegeleverd worden zijn Perl of Bash scripts, dus je kunt ook genoeg voorbeelden van hooks in die talen vinden door naar die bestanden te kijken.
+Ik heb Ruby gebruikt om ze te schrijven, zowel omdat het mijn voorkeur script taal is, als omdat ik vind dat het de meest pseudo code uitziende taal is van de scripttalen; dus je zou in staat moeten zijn om de code redelijk te kunnen volgen zelfs als je geen Ruby gebruikt. Maar elke taal zou prima werken. Alle voorbeeld hook scripts die met Git meegeleverd worden zijn Perl of Bash scripts, dus je kunt ook genoeg voorbeelden van hooks in die talen vinden door naar die bestanden te kijken.
 
 ### Server-kant hook ###
 
-Al het werk aan de server kant zal in het update bestand in je hooks directory gaan. Het update bestand zal eens per gepushte branch uitgevoerd worden en aanvaardt de referentie waarnaar gepusht wordt, de oude revisie waar die branch was en de nieuwe gepushte revisie. Je hebt ook toegang tot de gebruiker die de push doet als de push via SSH gedaan wordt. Als je iedereen hebt toegestaan om connectie te maken als één gebruiker (zoals "git") via publieke sleutel authenticatie, dan moet je wellicht die gebruiker een shell wrapper geven die bepaalt welke gebruiker er connectie maakt op basis van de publieke sleutel, en dan een omgevingsvariabele instellen waarin die gebruiker wordt gespecificeerd. Ik ga er vanuit dat de gebruiker in de `$USER` omgevingsvariabele staat, dus begint je update script met het verzamelen van alle gegevens die het nodig heeft:
+Al het werk aan de server kant zal in het update bestand in je hooks directory gaan zitten. Het update bestand zal eens per gepushte branch uitgevoerd worden en accepteert de referentie waarnaar gepusht wordt, de oude revisie waar die branch was en de nieuwe gepushte revisie. Je hebt ook toegang tot de gebruiker die de push doet als de push via SSH gedaan wordt. Als je iedereen hebt toegestaan om connectie te maken als één gebruiker (zoals "git") via publieke sleutel authenticatie, dan moet je wellicht die gebruiker een shell wrapper geven die bepaalt welke gebruiker er connectie maakt op basis van de publieke sleutel, en dan een omgevingsvariabele instellen waarin die gebruiker wordt gespecificeerd. Ik ga er vanuit dat de gebruiker in de `$USER` omgevingsvariabele staat, dus begint je update script met het verzamelen van alle gegevens die het nodig heeft:
 
 	#!/usr/bin/env ruby
 
@@ -621,13 +656,13 @@ Al het werk aan de server kant zal in het update bestand in je hooks directory g
 
 	puts "Enforcing Policies... \n(#{$refname}) (#{$oldrev[0,6]}) (#{$newrev[0,6]})"
 
-Ja, ik gebruik globale variabelen. Veroordeel me niet – het is makkelijker om het op deze manier te laten zien.
+Ja, ik gebruik globale variabelen. Schiet me niet af – het is makkelijker om het op deze manier te laten zien.
 
 #### Een specifiek commit-bericht formaat afdwingen ####
 
 Je eerste uitdaging is afdwingen dat elke commit bericht moet voldoen aan een specifiek formaat. Laten we zeggen dat ieder bericht een stuk tekst moet bevatten dat eruit ziet als "ref: 1234", omdat je wilt dat iedere commit gekoppeld is aan een werkonderdeel in je ticket systeem. Je moet dus kijken naar iedere commit die gepusht wordt, zien of die tekst in de commit boodschap zit en als de tekst in één van de commits ontbreekt, met niet nul eindigen zodat de push geweigerd wordt.
 
-Je kunt de lijst met alle SHA-1 waarden van alle commits die gepusht worden verkrijgen door de `$newrev` en `$oldrev` waarden te pakken en ze aan een Git sanitaire-voorzieningen (plumbing) commando genaamd `git rev-list` te geven. Dit is min of meer het `git log` commando, maar standaard voert het alleen de SHA-1 waarden uit en geen andere informatie. Dus, om een lijst te krijgen van alle commit SHA's die worden geïntroduceerd tussen één commit SHA en een andere, kun je zoiets als dit uitvoeren:
+Je kunt de lijst met alle SHA-1 waarden van alle commits die gepusht worden verkrijgen door de `$newrev` en `$oldrev` waarden te pakken en ze aan een Git plumbing commando genaamd `git rev-list` te geven. Dit is min of meer het `git log` commando, maar standaard voert het alleen de SHA-1 waarden uit en geen andere informatie. Dus, om een lijst te krijgen van alle commit SHA's die worden geïntroduceerd tussen één commit SHA en een andere, kun je zoiets als dit uitvoeren:
 
 	$ git rev-list 538c33..d14fc7
 	d14fc7c847ab946ec39590d87783c69b031bdfb7
@@ -638,7 +673,7 @@ Je kunt de lijst met alle SHA-1 waarden van alle commits die gepusht worden verk
 
 Je kunt die uitvoer pakken, door elk van die commit SHA's heen lopen, de boodschap daarvan pakken en die boodschap testen tegen een reguliere expressie die op een bepaald patroon zoekt.
 
-Je moet uit zien te vinden hoe je de commit boodschap kunt krijgen van alle te testen commits. Om de echte commit gegevens te krijgen, kun je een andere sanitaire-voorzieningen commando genaamd `git cat-file` gebruiken. Ik zal al deze sanitaire-voorzieningen commando's in detail behandelen in Hoofdstuk 9, maar voor nu is dit wat het commando je geeft:
+Je moet uit zien te vinden hoe je de commit boodschap kunt krijgen van alle te testen commits. Om de echte commit gegevens te krijgen, kun je een andere plumbing commando genaamd `git cat-file` gebruiken. Ik zal al plumbing commando's in detail behandelen in Hoofdstuk 9, maar voor nu is dit wat het commando je geeft:
 
 	$ git cat-file commit ca82a6
 	tree cfda3bf379e4f8dba8717dee55aab78aef7f4daf
@@ -648,7 +683,7 @@ Je moet uit zien te vinden hoe je de commit boodschap kunt krijgen van alle te t
 
 	changed the version number
 
-Een simpele manier om de commit boodschap te krijgen van een commit waarvan je de SHA-1 waarde hebt, is naar de eerste lege regel gaan en alles wat daarna komt pakken. Je kunt dat doen met het `sed` commando op Unix systemen:
+Een simpele manier om de commit boodschap uit een commit waarvan je de SHA-1 waarde hebt te krijgen, is naar de eerste lege regel gaan en alles wat daarna komt pakken. Je kunt dat doen met het `sed` commando op Unix systemen:
 
 	$ git cat-file commit ca82a6 | sed '1,/^$/d'
 	changed the version number
@@ -670,7 +705,7 @@ Je kunt die toverspreuk gebruiken om de commit boodschap te pakken van iedere co
 	end
 	check_message_format
 
-Door dat in je `update` script te stoppen, zal het updates weigeren die commits bevatten die berichten hebben die niet aan jouw regel voldoen.
+Door dat in je `update` script te stoppen, zullen updates geweigerd worden die commits bevatten met berichten die niet aan jouw beleid voldoen.
 
 #### Een gebruiker-gebaseerd ACL systeem afdwingen ####
 
@@ -685,7 +720,7 @@ In dit geval heb je een aantal beheerders, een aantal documentatie schrijvers me
 	avail|schacon|lib
 	avail|schacon|tests
 
-Je begint met het lezen van deze gegevens in een structuur die je kunt gebruiken. In dit geval, om het voorbeeld eenvoudig te houden, zul je alleen de `avail` richtlijnen handhaven. Hier is een methode die je een associatieve array geeft, waarbij de sleutel de gebruikersnaam is en de waarde een array van paden waar die gebruiker toegang tot heeft:
+Je begint met deze gegevens in een structuur in te lezen die je kunt gebruiken. In dit geval, om het voorbeeld eenvoudig te houden, zul je alleen de `avail` richtlijnen handhaven. Hier is een methode die je een associatieve array teruggeeft, waarbij de sleutel de gebruikersnaam is en de waarde een array van paden waar die gebruiker toegang tot heeft:
 
 	def get_acl_access_data(acl_file)
 	  # lees ACL gegevens
@@ -751,7 +786,7 @@ Als je gebruik maakt van de ACL structuur die wordt teruggegeven door de `get_ac
 
 	check_directory_perms
 
-Het meeste daarvan zou makkelijk te volgen moeten zijn. Je krijgt een lijst met commits die gepusht worden naar je server met `git rev-list`. Daarna vind je, voor iedere commit de bestanden die aangepast worden en stelt vast of de gebruiker die pusht toegang heeft tot alle paden die worden aangepast. Een Ruby-isme dat wellicht niet duidelijk is, is `path.index(access_path) == 0`, wat waar is als het pad begint met `access_path` – dit zorgt ervoor dat `access_path` niet slechts in één van de toegestane paden zit, maar dat het voorkomt in alle toegestane paden.
+Het meeste hiervan zou makkelijk te volgen moeten zijn. Je krijgt een lijst met commits die gepusht worden naar je server met `git rev-list`. Daarna vind je, voor iedere commit, de bestanden die aangepast worden en stelt vast of de gebruiker die pusht toegang heeft tot alle paden die worden aangepast. Een Ruby-isme dat wellicht niet duidelijk is, is `path.index(access_path) == 0`, wat waar is als het pad begint met `access_path` – dit zorgt ervoor dat `access_path` niet slechts in één van de toegestane paden zit, maar dat het voorkomt in alle toegestane paden.
 
 Nu kunnen je gebruikers geen commits pushen met slecht vormgegeven berichten of met aangepaste bestanden buiten hun toegewezen paden.
 
@@ -759,7 +794,7 @@ Nu kunnen je gebruikers geen commits pushen met slecht vormgegeven berichten of
 
 Het laatste om af te dwingen is fast-forward-only pushes. Om dit te regelen, kan je simpelweg de `receive.denyDeletes` en `receive.denyNonFastForwards` instellingen aanpassen. Maar dit afdwingen met behulp van een hook werkt ook, en je kunt het aanpassen zodat het alleen gebeurt bij bepaalde gebruikers of om elke reden die je later bedenkt.
 
-De logica om dit te controleren, is zien of er een commit is die bereikbaar is vanuit de oudere revisie, maar niet bereikbaar is vanuit de nieuwere. Als er geen zijn dan was het een fast-forward push, anders weiger je het:
+De logica om dit te controleren, is te kijken of er een commit is die bereikbaar is vanuit de oudere revisie, maar niet bereikbaar is vanuit de nieuwere. Als er geen zijn dan was het een fast-forward push, anders weiger je het:
 
 	# dwingt fast-forward-only pushes af
 	def check_fast_forward
@@ -773,7 +808,7 @@ De logica om dit te controleren, is zien of er een commit is die bereikbaar is v
 
 	check_fast_forward
 
-Alles is ingesteld. Als je `chmod u+x .git/hooks/update` uitvoert, wat het bestand is waarin je al deze code gestopt hebt, en dan probeert een non-fast-forwarded referentie te pushen  krijg je zoiets als dit:
+Alles is ingesteld. Als je `chmod u+x .git/hooks/update` uitvoert, wat het bestand is waarin je al deze code gestopt hebt, en dan probeert een non-fast-forwarded referentie te pushen krijg je zoiets als dit:
 
 
 	$ git push -f origin master
@@ -810,22 +845,21 @@ De eerste regel was door jou afgedrukt, de andere twee komen van Git die je vert
 	 ! [remote rejected] master -> master (hook declined)
 	error: failed to push some refs to 'git@gitserver:project.git'
 
-Je zult een remote weiger bericht zien voor elke referentie die door de hook wordt geweigerd, en het vertelt je dat het specifiek was geweigerd wegens een hook fout.
+Je zult een remote afwijs bericht zien voor elke referentie die door de hook wordt geweigerd, en het vertelt je dat het specifiek was geweigerd wegens een hook fout.
 
-Daarnaast zal je een foutmelding zien als in één van je commits de ref-marker ontbreekt.
+Daarnaast zal je een foutmelding zien als in één van je commits de referentie markering ontbreekt.
 
 	[POLICY] Your message is not formatted correctly
 
-Of als iemand een bestand probeert aan te passen waar ze geen toegang tot hebben en een commit probeert te pushen waar het in zit, dan zullen ze iets vergelijkbaars zien. Bijvoorbeeld, als een documentatie schrijver een commit probeert te pushen dat iets wijzigt dat in de `lib` map zit, dan zien ze
-
+Of als iemand een bestand probeert aan te passen waar ze geen toegang tot hebben en een commit proberen te pushen waar het in zit, dan zullen ze iets vergelijkbaars zien. Bijvoorbeeld, als een documentatie schrijver een commit probeert te pushen dat iets wijzigt dat in de `lib` map zit, dan zien ze
 
 	[POLICY] You do not have access to push to lib/test.rb
 
-Dat is alles. Vanaf nu, zolang als het `update` script aanwezig en uitvoerbaar is, zal je repository nooit teruggedraaid worden en zal nooit een commit bericht bevattenb waar je patroon niet in zit, en je gebruikers zullen in hun bewegingsruimte beperkt zijn.
+Dat is alles. Vanaf nu, zolang als het `update` script aanwezig en uitvoerbaar is, zal je repository nooit teruggedraaid worden en zal nooit een commit bericht bevatten waar het patroon niet in zit, en je gebruikers zullen in hun bewegingsruimte beperkt zijn.
 
 ### Hooks aan de client-kant ###
 
-Het nadeel van deze aanpak is het zeuren dat geheid zal beginnen zodra de commits van je gebruikers geweigerd worden. Het feit dat hun zorgzaam vervaardigde werk op het laatste moment pas geweigerd wordt kan enorm frustrerend en verwarrend zijn en daarnaast zullen ze hun geschiedenis moeten aanpassen om het te corrigeren, wat niet altijd geschikt is voor de wat angstiger aangelegde mensen.
+Het nadeel van deze aanpak is het zeuren dat geheid zal beginnen zodra de commits van je gebruikers geweigerd worden. Het feit dat hun zorgzaam vervaardigde werk op het laatste moment pas geweigerd wordt kan enorm frustrerend en verwarrend zijn en daarnaast zullen ze hun geschiedenis moeten aanpassen om het te corrigeren, wat niet altijd geschikt is voor de wat zwakkeren van hart.
 
 Het antwoord op dit dilemma is een aantal client-kant hooks te leveren, die gebruikers kunnen gebruiken om hen te waarschuwen dat ze iets doen dat de server waarschijnlijk gaat weigeren. Op die manier kunnen ze alle problemen corrigeren voordat ze gaan committen en voordat die problemen lastiger te herstellen zijn. Omdat haken niet overgebracht worden bij het klonen van een project, moet je deze scripts op een andere manier distribueren en je gebruikers ze in hun `.git/hooks` map laten zetten en ze uitvoerbaar maken. Je kunt deze hooks in je project of in een apart project distribueren, maar er is geen manier om ze automatisch in te laten stellen.
 
@@ -882,15 +916,15 @@ Vervolgens wil je er zeker van zijn dat je geen bestanden buiten je ACL scope aa
 
 	check_directory_perms
 
-Dit is bijna hetzelfde script als aan de server kant, maar met twee belangrijke verschillen. Als eerste staat het ACL bestand op een andere plek, omdat dit script vanuit je werkdirectory draait, en niet vanuit je Git directory. Je moet het pad naar het ACL bestand wijzigen van dit
+Dit is grofweg hetzelfde script als aan de server kant, maar met twee belangrijke verschillen. Als eerste staat het ACL bestand op een andere plek, omdat dit script vanuit je werkdirectory draait, en niet vanuit je Git directory. Je moet het pad naar het ACL bestand wijzigen van dit
 
 	access = get_acl_access_data('acl')
 
-in dit:
+naar dit:
 
 	access = get_acl_access_data('.git/acl')
 
-Het andere belangrijke verschil is de manier waarop je een lijst krijgt met bestanden die gewijzigd is. Omdat de server kant methode naar de log van commits kijkt en nu je commit nog niet opgeslagen is, moet je de bestandslijst in plaats daarvan uit het stage gebied halen. In plaats van
+Het andere belangrijke verschil is de manier waarop je een lijst krijgt met bestanden die gewijzigd is. Omdat de server kant methode naar de log van commits kijkt en nu je commit nog niet opgeslagen is, moet je de bestandslijst in plaats daarvan uit het staging area halen. In plaats van
 
 	files_modified = `git log -1 --name-only --pretty=format:'' #{ref}`
 
@@ -898,7 +932,7 @@ moet je dit gebruiken
 
 	files_modified = `git diff-index --cached --name-only HEAD`
 
-Maar dat zijn de enige twee verschillen, verder werkt het script op dezelfde manier. Een voorwaarde is dat het van je verlangt dat je lokaal werkt als dezelfde gebruiker die pushed naar de remote machine. Als dat anders is, moet je de `$user` variabele handmatig instellen.
+Maar dat zijn de enige twee verschillen - verder werkt het script op dezelfde manier. Een aandachtspunt is dat het van je verlangt dat je lokaal werkt als dezelfde gebruiker die pusht naar de remote machine. Als dat anders is, moet je de `$user` variabele handmatig instellen.
 
 Het laatste wat je moet doen is het controleren dat je niet probeert non-fast-forward referenties te pushen, maar dat komt minder voor. Om een referentie te krijgen dat non-fast-forward is, moet je voorbij een commit rebasen die je al gepusht hebt, of een andere lokale branch naar dezelfde remote branch proberen te pushen.
 
@@ -932,10 +966,10 @@ Dit script gebruikt een syntax dat niet behandeld is in de Revisie Selectie para
 
 	git rev-list ^#{sha}^@ refs/remotes/#{remote_ref}
 
-De `SHA^@` syntax wordt vervangen door alle ouders van die commit. Je bent op zoek naar een commit die bereikbaar is vanuit de laatste commit op de remote en die niet bereikbaar is vanuit enige ouder van alle SHA's die je probeert te pushen – wat inhoudt dat het een fast-forward is.
+De `SHA^@` syntax wordt vervangen door alle ouders van die commit. Je bent op zoek naar een commit die bereikbaar is vanuit de laatste commit op de remote en die niet bereikbaar is vanuit enige ouder van alle SHA's die je probeert te pushen – wat betekent dat het een fast-forward is.
 
 Het grote nadeel van deze aanpak is dat het erg traag kan zijn en vaak onnodig is, als je de push niet probeert te forceren met de `-f` optie, dan zal de server je al waarschuwen en de push niet accepteren. Maar, het is een aardige oefening en kan je in theorie helpen om een rebase te voorkomen die je later zult moeten herstellen.
 
 ## Samenvatting ##
 
-Je hebt nu de meeste manieren behandeld waarin je jouw Git client en server aan kunt passen om aan jouw werkwijze en projecten te voldoen. Je hebt allerhande configuratie instellingen geleerd, bestands-gebaseerde attributen, en gebeurtenis hooks (event hooks) en je hebt een voorbeeld gemaakt van een server die beleid afdwingt. Je zou nu in staat moeten zijn om Git bijna iedere werkwijze die je kunt verzinnen te laten doen.
+We hebben nu de meeste manieren behandeld waarin je jouw Git client en server aan kunt passen om aan jouw workflow en projecten te voldoen. Je hebt allerhande configuratie instellingen geleerd, bestands-gebaseerde attributen, en gebeurtenis hooks (event hooks) en je hebt een voorbeeld gemaakt van een server die beleid afdwingt. Je zou nu in staat moeten zijn om Git binnen iedere workflow die je kunt verzinnen te laten werken.

From 6ed7ac91d56cae84d09f63578374568ce3c9b300 Mon Sep 17 00:00:00 2001
From: Jean-Noel Avila <jn.avila@free.fr>
Date: Fri, 21 Feb 2014 23:49:15 +0100
Subject: [PATCH 242/690] backport 44936fd to other language and pdf

This change needs to be backported to all languages. The pdf toolchain
processes this formula with a transformation to some latex mathematic
typesetting and therefore needs to be updated.
---
 az/06-git-tools/01-chapter6.markdown    | 2 +-
 cs/06-git-tools/01-chapter6.markdown    | 2 +-
 de/06-git-tools/01-chapter6.markdown    | 4 ++--
 es/06-git-tools/01-chapter6.markdown    | 2 +-
 fr/06-git-tools/01-chapter6.markdown    | 2 +-
 it/06-git-tools/01-chapter6.markdown    | 2 +-
 latex/makepdf                           | 4 ++--
 no-nb/06-git-tools/01-chapter6.markdown | 2 +-
 pl/06-git-tools/01-chapter6.markdown    | 2 +-
 pt-br/06-git-tools/01-chapter6.markdown | 2 +-
 ru/06-git-tools/01-chapter6.markdown    | 2 +-
 zh/06-git-tools/01-chapter6.markdown    | 2 +-
 12 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/az/06-git-tools/01-chapter6.markdown b/az/06-git-tools/01-chapter6.markdown
index 550699d2d..5ca797d32 100644
--- a/az/06-git-tools/01-chapter6.markdown
+++ b/az/06-git-tools/01-chapter6.markdown
@@ -59,7 +59,7 @@ A lot of people become concerned at some point that they will, by random happens
 
 If you do happen to commit an object that hashes to the same SHA-1 value as a previous object in your repository, Git will see the previous object already in your Git database and assume it was already written. If you try to check out that object again at some point, you’ll always get the data of the first object. 
 
-However, you should be aware of how ridiculously unlikely this scenario is. The SHA-1 digest is 20 bytes or 160 bits. The number of randomly hashed objects needed to ensure a 50% probability of a single collision is about 2^80 (the formula for determining collision probability is `p = (n(n-1)/2) * (1/2^160))`. 2^80 is 1.2 x 10^24 or 1 million billion billion. That’s 1,200 times the number of grains of sand on the earth.
+However, you should be aware of how ridiculously unlikely this scenario is. The SHA-1 digest is 20 bytes or 160 bits. The number of randomly hashed objects needed to ensure a 50% probability of a single collision is about 2^80 (the formula for determining collision probability is `p = (n(n-1)/2) * (1/2^160)`). 2^80 is 1.2 x 10^24 or 1 million billion billion. That’s 1,200 times the number of grains of sand on the earth.
 
 Here’s an example to give you an idea of what it would take to get a SHA-1 collision. If all 6.5 billion humans on Earth were programming, and every second, each one was producing code that was the equivalent of the entire Linux kernel history (1 million Git objects) and pushing it into one enormous Git repository, it would take 5 years until that repository contained enough objects to have a 50% probability of a single SHA-1 object collision. A higher probability exists that every member of your programming team will be attacked and killed by wolves in unrelated incidents on the same night.
 
diff --git a/cs/06-git-tools/01-chapter6.markdown b/cs/06-git-tools/01-chapter6.markdown
index 33cb6cc95..17b17dcb3 100644
--- a/cs/06-git-tools/01-chapter6.markdown
+++ b/cs/06-git-tools/01-chapter6.markdown
@@ -59,7 +59,7 @@ Někteří uživatelé bývají zmateni, že mohou mít v repozitáři – shodo
 
 Pokud náhodou zapíšete objekt, který má stejnou hodnotu SHA-1 otisku jako předchozí objekt ve vašem repozitáři, Git už uvidí předchozí objekt v databázi Git a bude předpokládat, že už byl zapsán. Pokud se někdy v budoucnosti pokusíte znovu provést checkout tohoto objektu, vždy dostanete data prvního objektu.
 
-Měli bychom však také říci, jak moc je nepravděpodobné, že taková situace nastane. Otisk SHA-1 má 20 bytů, neboli 160 bitů. Počet objektů s náhodným otiskem, které bychom potřebovali k 50% pravděpodobnosti, že nastane jediná kolize, je asi 2^80 (vzorec k určení pravděpodobnosti kolize je `p = (n(n-1)/2) * (1/2^160))`. 2^80 je 1,2 * 10^24, neboli 1 milion miliard miliard. To je 1200násobek počtu všech zrnek písku na celé Zemi.
+Měli bychom však také říci, jak moc je nepravděpodobné, že taková situace nastane. Otisk SHA-1 má 20 bytů, neboli 160 bitů. Počet objektů s náhodným otiskem, které bychom potřebovali k 50% pravděpodobnosti, že nastane jediná kolize, je asi 2^80 (vzorec k určení pravděpodobnosti kolize je `p = (n(n-1)/2) * (1/2^160)`). 2^80 je 1,2 * 10^24, neboli 1 milion miliard miliard. To je 1200násobek počtu všech zrnek písku na celé Zemi.
 
 Abyste si udělali představu, jak je nepravděpodobné, že dojde ke kolizi hodnot SHA-1, připojujeme jeden malý příklad. Kdyby 6,5 miliardy lidí na zemi programovalo a každý by každou sekundu vytvořil kód odpovídající celé historii linuxového jádra (1 milion objektů Git) a odesílal ho do jednoho obřího repozitáře Git, trvalo by 5 let, než by repozitář obsahoval dost objektů na to, aby existovala 50% pravděpodobnost, že dojde ke kolizi jediného objektu SHA-1. To už je pravděpodobnější, že všichni členové vašeho programovacího týmu budou během jedné noci v navzájem nesouvisejících incidentech napadeni a zabiti smečkou vlků.
 
diff --git a/de/06-git-tools/01-chapter6.markdown b/de/06-git-tools/01-chapter6.markdown
index aec049519..294a15ca2 100644
--- a/de/06-git-tools/01-chapter6.markdown
+++ b/de/06-git-tools/01-chapter6.markdown
@@ -86,9 +86,9 @@ Eine Menge Leute machen sich Sorgen, dass ab einem zufälligen Punkt zwei Objekt
 
 Wenn es passiert, dass bei einem Commit, ein Objekt mit dem gleichen SHA-1-Hashwert im Repository vorhanden ist, wird Git sehen, dass das vorherige Objekt bereits in der Datenbank vorhanden ist und davon ausgehen, dass es bereits geschrieben wurde. Wenn Du versuchst, das Objekt später wieder auszuchecken, wirst Du immer die Daten des ersten Objekts bekommen.
 
-<!--However, you should be aware of how ridiculously unlikely this scenario is. The SHA-1 digest is 20 bytes or 160 bits. The number of randomly hashed objects needed to ensure a 50% probability of a single collision is about 2^80 (the formula for determining collision probability is `p = (n(n-1)/2) * (1/2^160))`. 2^80 is 1.2 x 10^24 or 1 million billion billion. That’s 1,200 times the number of grains of sand on the earth.-->
+<!--However, you should be aware of how ridiculously unlikely this scenario is. The SHA-1 digest is 20 bytes or 160 bits. The number of randomly hashed objects needed to ensure a 50% probability of a single collision is about 2^80 (the formula for determining collision probability is `p = (n(n-1)/2) * (1/2^160)`). 2^80 is 1.2 x 10^24 or 1 million billion billion. That’s 1,200 times the number of grains of sand on the earth.-->
 
-Allerdings solltest Du Dir bewusst machen, wie unglaublich unwahrscheinlich dieses Szenario ist. Die Länge des SHA-1-Hashs beträgt 20 Bytes oder 160 Bits. Die Anzahl der Objekte, die benötigt werden, um eine 50% Chance einer Kollision zu haben, beträgt ungefähr 2^80 (die Formel zum Berechnen der Kollisionswahrscheinlichkeit lautet `p = (n(n-1)/2) * (1/2^160))`. 2^80 ist somit 1.2 x 10^24 oder eine Trilliarde. Das ist 1200 Mal so viel, wie es Sandkörner auf der Erde gibt.
+Allerdings solltest Du Dir bewusst machen, wie unglaublich unwahrscheinlich dieses Szenario ist. Die Länge des SHA-1-Hashs beträgt 20 Bytes oder 160 Bits. Die Anzahl der Objekte, die benötigt werden, um eine 50% Chance einer Kollision zu haben, beträgt ungefähr 2^80 (die Formel zum Berechnen der Kollisionswahrscheinlichkeit lautet `p = (n(n-1)/2) * (1/2^160)`). 2^80 ist somit 1.2 x 10^24 oder eine Trilliarde. Das ist 1200 Mal so viel, wie es Sandkörner auf der Erde gibt.
 
 <!--Here’s an example to give you an idea of what it would take to get a SHA-1 collision. If all 6.5 billion humans on Earth were programming, and every second, each one was producing code that was the equivalent of the entire Linux kernel history (1 million Git objects) and pushing it into one enormous Git repository, it would take 5 years until that repository contained enough objects to have a 50% probability of a single SHA-1 object collision. A higher probability exists that every member of your programming team will be attacked and killed by wolves in unrelated incidents on the same night.-->
 
diff --git a/es/06-git-tools/01-chapter6.markdown b/es/06-git-tools/01-chapter6.markdown
index 254a8656f..df5bec3cd 100644
--- a/es/06-git-tools/01-chapter6.markdown
+++ b/es/06-git-tools/01-chapter6.markdown
@@ -59,7 +59,7 @@ Mucha gente se suele preocupar por si, por casualidad, dos objetos en su reposit
 
 Si se da la casualidad de confirmar cambios en un objeto y que a este se le asigne el mismo código SHA-1 que otro ya existente en el repositorio. Al ver  el objeto previamente almacenado en la base de datos, Git asumirá que este ya existía. Al intentar recuperar (check-out) el objeto más tarde, siempre se obtendrán los datos del primer objeto. 
 
-No obstante, hemos de ser conscientes de lo altamente improbable de un suceso así. Los códigos SHA-1 son de 20 bytes, (160 bits). El número de objetos, codificados aleatóriamente, necesarios para asegurar un 50% de probabilidad de darse una sola colisión es cercano a 2^80 (la fórmula para determinar la probabilidad de colisión es `p = (n(n-1)/2) * (1/2^160))`). 2^80 es 1'2 x 10^24, o lo que es lo mismo, 1 billón de billones. Es decir, unas 1.200 veces el número de granos de arena en la Tierra.
+No obstante, hemos de ser conscientes de lo altamente improbable de un suceso así. Los códigos SHA-1 son de 20 bytes, (160 bits). El número de objetos, codificados aleatóriamente, necesarios para asegurar un 50% de probabilidad de darse una sola colisión es cercano a 2^80 (la fórmula para determinar la probabilidad de colisión es `p = (n(n-1)/2) * (1/2^160)`)). 2^80 es 1'2 x 10^24, o lo que es lo mismo, 1 billón de billones. Es decir, unas 1.200 veces el número de granos de arena en la Tierra.
 
 El siguiente ejemplo puede ser bastante ilustrativo, para hacernos una idea de lo que podría tardarse en darse una colisión en el código SHA-1: Si todos los 6'5 billones de humanos en el planeta Tierra estuvieran programando y, cada segundo, cada uno de ellos escribiera código equivalente a todo el histórico del kernel de Linux (cerca de 1 millón de objetos Git), enviandolo todo a un enorme repositorio Git. Serían necesarios unos 5 años antes de que dicho repositorio contuviera suficientes objetos como para tener una probabilidad del 50% de darse una sola colisión en el código SHA-1. Es mucho más probable que todos los miembros de nuestro equipo de programación fuesen atacados y matados por lobos, en incidentes no relacionados entre sí, acaecidos todos ellos en una misma noche.
 
diff --git a/fr/06-git-tools/01-chapter6.markdown b/fr/06-git-tools/01-chapter6.markdown
index 1fe8e5f19..042f4ed3e 100644
--- a/fr/06-git-tools/01-chapter6.markdown
+++ b/fr/06-git-tools/01-chapter6.markdown
@@ -70,7 +70,7 @@ Si vous essayez de récupérer l'objet de nouveau à un moment donné, vous auri
 
 Quoi qu'il en soit, vous devriez être conscient à quel point ce scénario est ridiculement improbable.
 Une empreinte SHA-1 porte sur 20 octets soit 160 bits.
-Le nombre d'objets aléatoires à hacher requis pour assurer une probabilité de collision de 50 % vaut environ 2^80 (la formule pour calculer la probabilité de collision est `p = (n(n-1)/2) * (1/2^160))`.
+Le nombre d'objets aléatoires à hacher requis pour assurer une probabilité de collision de 50 % vaut environ 2^80 (la formule pour calculer la probabilité de collision est `p = (n(n-1)/2) * (1/2^160)`).
 2^80 vaut 1,2 × 10^24 soit 1 million de milliards de milliards.
 Cela représente 1200 fois le nombre de grains de sable sur Terre.
 
diff --git a/it/06-git-tools/01-chapter6.markdown b/it/06-git-tools/01-chapter6.markdown
index 516bf8580..3f4d67c19 100644
--- a/it/06-git-tools/01-chapter6.markdown
+++ b/it/06-git-tools/01-chapter6.markdown
@@ -62,7 +62,7 @@ Se capita di fare la *commit* di un oggetto a che abbia lo stesso SHA-1 di un og
 già presente nel tuo *repository*, Git vedrà l’oggetto precedente già nel database di Git e lo riterrà già scritto. Se successivamente proverai a fare il checkout di quest’ultimo oggetto, otterrai sempre i dati del primo oggetto.
 
 Ad ogni modo, è necessario essere consapevoli di quanto sia ridicolmente improbabile
-questo scenario. Il codice SHA-1 è di 20 bytes o 160 bits. Il numero di oggetti casuali necessari perché ci sia la probabilità del 50% di una singola collisione è di circa 2^80 (la formula per determinare la probabilità di collisione è `p = (n(n-1)/2) * (1/2^160))`. 2^80 è 1.2 x 10^24 ovvero un milione di miliardi di miliardi. È 1.200 volte il numero di granelli di sabbia sulla terra.
+questo scenario. Il codice SHA-1 è di 20 bytes o 160 bits. Il numero di oggetti casuali necessari perché ci sia la probabilità del 50% di una singola collisione è di circa 2^80 (la formula per determinare la probabilità di collisione è `p = (n(n-1)/2) * (1/2^160)`). 2^80 è 1.2 x 10^24 ovvero un milione di miliardi di miliardi. È 1.200 volte il numero di granelli di sabbia sulla terra.
 
 Ecco un esempio per dare un'idea di cosa ci vorrebbe per ottenere una collisione
 SHA-1. Se tutti i 6.5 miliardi di esseri umani sulla Terra programmassero e, ogni secondo, ognuno scrivesse codice che fosse equivalente all'intera cronologia del kernel Linux (1 milione di oggetti Git) e ne facesse la push su un enorme *repository* Git, ci vorrebbero 5 anni per contenere abbastanza oggetti in quel *repository* per avere il 50% di possibilità di una singola collisione di oggetti SHA-1. Esiste una probabilità più alta che ogni membro del tuo gruppo di sviluppo, per pura coincidenza, venga attaccato e ucciso da dei lupi nella stessa notte.
diff --git a/latex/makepdf b/latex/makepdf
index d60508eb4..c35e02dd6 100755
--- a/latex/makepdf
+++ b/latex/makepdf
@@ -120,8 +120,8 @@ def post_pandoc(string, config)
 		s /(\w)--(\w)/, '\1-\2'
 		s /``(.*?)''/, "#{config['dql']}\\1#{config['dqr']}"
 
-		# Typeset the maths in the book with TeX
-		s '\verb!p = (n(n-1)/2) * (1/2^160))!', '$p = \frac{n(n-1)}{2} \times \frac{1}{2^{160}}$)'
+		# Typeset the maths in the book with TeX 
+		s '\texttt{p = (n(n-1)/2) * (1/2\^{}160)}', '$p = \frac{n(n-1)}{2} \times \frac{1}{2^{160}}$'
 		s '2\^{}80', '$2^{80}$'
 		s /\sx\s10\\\^\{\}(\d+)/, '\e{\1}'
 
diff --git a/no-nb/06-git-tools/01-chapter6.markdown b/no-nb/06-git-tools/01-chapter6.markdown
index 550699d2d..5ca797d32 100644
--- a/no-nb/06-git-tools/01-chapter6.markdown
+++ b/no-nb/06-git-tools/01-chapter6.markdown
@@ -59,7 +59,7 @@ A lot of people become concerned at some point that they will, by random happens
 
 If you do happen to commit an object that hashes to the same SHA-1 value as a previous object in your repository, Git will see the previous object already in your Git database and assume it was already written. If you try to check out that object again at some point, you’ll always get the data of the first object. 
 
-However, you should be aware of how ridiculously unlikely this scenario is. The SHA-1 digest is 20 bytes or 160 bits. The number of randomly hashed objects needed to ensure a 50% probability of a single collision is about 2^80 (the formula for determining collision probability is `p = (n(n-1)/2) * (1/2^160))`. 2^80 is 1.2 x 10^24 or 1 million billion billion. That’s 1,200 times the number of grains of sand on the earth.
+However, you should be aware of how ridiculously unlikely this scenario is. The SHA-1 digest is 20 bytes or 160 bits. The number of randomly hashed objects needed to ensure a 50% probability of a single collision is about 2^80 (the formula for determining collision probability is `p = (n(n-1)/2) * (1/2^160)`). 2^80 is 1.2 x 10^24 or 1 million billion billion. That’s 1,200 times the number of grains of sand on the earth.
 
 Here’s an example to give you an idea of what it would take to get a SHA-1 collision. If all 6.5 billion humans on Earth were programming, and every second, each one was producing code that was the equivalent of the entire Linux kernel history (1 million Git objects) and pushing it into one enormous Git repository, it would take 5 years until that repository contained enough objects to have a 50% probability of a single SHA-1 object collision. A higher probability exists that every member of your programming team will be attacked and killed by wolves in unrelated incidents on the same night.
 
diff --git a/pl/06-git-tools/01-chapter6.markdown b/pl/06-git-tools/01-chapter6.markdown
index 228326762..fbba51d7a 100644
--- a/pl/06-git-tools/01-chapter6.markdown
+++ b/pl/06-git-tools/01-chapter6.markdown
@@ -90,7 +90,7 @@ Jeżeli zdarzy Ci się zapisać obiekt który ma sumę kontrolną SHA-1 taką sa
 
 Powinieneś wiedzieć jednak, że taki scenariusz jest strasznie rzadki. Skrót SHA-1 ma długość 20 bajtów lub 160 bitów. Ilość losowych obiektów potrzebnych do zapewnienia 50% prawdopodobieństwa kolizji to około 2^80 (wzór na obliczenie prawdopodobieństwa kolizji to `p = (n(n-1)/2) * (1/2^160)`). 2^80 to 1.2 x 10^24 lub 1 milion miliardów miliardów. Jest to około 1200 razy ilość ziarenek piasku na kuli ziemskiej.
 
-<!--However, you should be aware of how ridiculously unlikely this scenario is. The SHA-1 digest is 20 bytes or 160 bits. The number of randomly hashed objects needed to ensure a 50% probability of a single collision is about 2^80 (the formula for determining collision probability is `p = (n(n-1)/2) * (1/2^160))`. 2^80 is 1.2 x 10^24 or 1 million billion billion. That’s 1,200 times the number of grains of sand on the earth. -->
+<!--However, you should be aware of how ridiculously unlikely this scenario is. The SHA-1 digest is 20 bytes or 160 bits. The number of randomly hashed objects needed to ensure a 50% probability of a single collision is about 2^80 (the formula for determining collision probability is `p = (n(n-1)/2) * (1/2^160)`). 2^80 is 1.2 x 10^24 or 1 million billion billion. That’s 1,200 times the number of grains of sand on the earth. -->
 
 Weźmy przykład, aby zaprezentować Ci jak trudne jest wygenerowanie kolizji SHA-1. Jeżeli wszyscy z 6,5 miliarda osób na ziemi byłaby programistami i w każdej sekundzie, każdy z nich tworzyłby kod wielkości całego jądra Linuksa (1 milion obiektów Gita) i wgrywał go do ogromnego repozytorium Gita, zajęłoby około 5 lat, zanim w repozytorium byłoby tyle obiektów, aby mieć pewność 50% wystąpienia kolizji. Istnieje większe prawdopodobieństwo, że każdy z członków Twojego zespołu programistycznego zostanie zaatakowany i zabity przez wilki, w nie związanych ze sobą zdarzeniach, w ciągu tej samej nocy. 
 
diff --git a/pt-br/06-git-tools/01-chapter6.markdown b/pt-br/06-git-tools/01-chapter6.markdown
index 62e4811c4..4a73cba92 100644
--- a/pt-br/06-git-tools/01-chapter6.markdown
+++ b/pt-br/06-git-tools/01-chapter6.markdown
@@ -59,7 +59,7 @@ Muitas pessoas ficam preocupadas que em algum momento elas terão, por coincidê
 
 Se acontecer de você fazer um commit de um objeto que tem o hash com o mesmo valor de SHA-1 de um objeto existente no seu repositório, GIt notará o primeiro objeto existente no seu banco de dados e assumirá que ele já foi gravado. Se você tentar fazer o checkout desse objeto novamente em algum momento, sempre receberá os dados do primeiro objeto.
 
-Porém, você deve estar ciente de quão ridiculamente improvável é esse cenário. O código SHA-1 tem 20 bytes ou 160 bits. O número de objetos com hashes aleatórios necessários para garantir a probabilidade de 50% de uma única colisão é cerca de 2^80 (a fórmula para determinar a probabilidade de colisão é `p = (n(n-1)/2) * (1/2^160))`. 2^80 é 1.2 x 10^24 ou 1 milhão de bilhões de bilhões. Isso é 1.200 vezes o número de grãos de areia na Terra.
+Porém, você deve estar ciente de quão ridiculamente improvável é esse cenário. O código SHA-1 tem 20 bytes ou 160 bits. O número de objetos com hashes aleatórios necessários para garantir a probabilidade de 50% de uma única colisão é cerca de 2^80 (a fórmula para determinar a probabilidade de colisão é `p = (n(n-1)/2) * (1/2^160)`). 2^80 é 1.2 x 10^24 ou 1 milhão de bilhões de bilhões. Isso é 1.200 vezes o número de grãos de areia na Terra.
 
 Aqui está um exemplo para lhe dar uma idéia do que seria necessário para obter uma colisão de SHA-1. Se todos os 6,5 bilhões de humanos na Terra estivessem programando, e a cada segundo, cada um estivesse produzindo código que é equivalente ao histórico inteiro do kernel do Linux (1 milhão de objetos Git) e fazendo o push para um enorme repositório Git, levaria 5 anos até que esse repositório tenha objetos suficientes para ter uma probabilidade de 50% de uma única colisão de objetos SHA-1. Existe uma probabilidade maior de cada membro do seu time de programação ser atacado e morto por lobos na mesma noite em incidentes sem relação.
 
diff --git a/ru/06-git-tools/01-chapter6.markdown b/ru/06-git-tools/01-chapter6.markdown
index dbba23f5b..0299438f1 100644
--- a/ru/06-git-tools/01-chapter6.markdown
+++ b/ru/06-git-tools/01-chapter6.markdown
@@ -59,7 +59,7 @@ Git может показать короткие уникальные сокра
 
 Если вы вдруг закоммитите объект, SHA-1 хеш которого такой же, как у некоторого предыдущего объекта в вашем репозитории, Git обнаружит предыдущий объект в своей базе данных и посчитает, что он уже был записан. Если вы в какой-то момент попытаетесь получить этот объект опять, вы всегда будете получать данные первого объекта.
 
-Однако, вы должны осознавать то, как смехотворно маловероятен этот сценарий. Длина SHA-1 составляет 20 байт или 160 бит. Количество случайно хешированных объектов, необходимое для того, чтобы получить 50% вероятность одиночного совпадения составляет порядка 2^80 (формула для определения вероятности совпадения: `p = (n(n-1)/2) * (1/2^160))`). 2^80 это 1.2 x 10^24 или один миллион миллиарда миллиардов. Это в 1200 раз больше количества песчинок на земле.
+Однако, вы должны осознавать то, как смехотворно маловероятен этот сценарий. Длина SHA-1 составляет 20 байт или 160 бит. Количество случайно хешированных объектов, необходимое для того, чтобы получить 50% вероятность одиночного совпадения составляет порядка 2^80 (формула для определения вероятности совпадения: `p = (n(n-1)/2) * (1/2^160)`)). 2^80 это 1.2 x 10^24 или один миллион миллиарда миллиардов. Это в 1200 раз больше количества песчинок на земле.
 
 Вот пример для того, чтобы вы поняли, что необходимо, чтобы получить SHA-1 коллизию. Если бы все 6.5 миллиардов людей на Земле программировали и каждую секунду каждый из них производил количество кода, эквивалентное всей истории ядра Linux (1 миллион Git-объектов) и отправлял его в один огромный Git-репозиторий, то потребовалось бы 5 лет для того, чтобы заполнить репозиторий достаточно для того, чтобы получить 50% вероятность единичной SHA-1 коллизии. Более вероятно, что каждый член вашей команды программистов будет атакован и убит волками в несвязанных друг с другом случаях в одну и ту же ночь.
 
diff --git a/zh/06-git-tools/01-chapter6.markdown b/zh/06-git-tools/01-chapter6.markdown
index 078a4ac05..391317cfa 100644
--- a/zh/06-git-tools/01-chapter6.markdown
+++ b/zh/06-git-tools/01-chapter6.markdown
@@ -59,7 +59,7 @@ Git 可以为你的 SHA-1 值生成出简短且唯一的缩写。如果你传递
 
 如果你真的向仓库里提交了一个跟之前的某个对象具有相同 SHA-1 值的对象，Git 将会发现之前的那个对象已经存在在 Git 数据库中，并认为它已经被写入了。如果什么时候你想再次检出那个对象时，你会总是得到先前的那个对象的数据。
 
-不过，你应该了解到，这种情况发生的概率是多么微小。SHA-1 摘要长度是 20 字节，也就是 160 位。为了保证有 50% 的概率出现一次冲突，需要 2^80 个随机哈希的对象（计算冲突机率的公式是 `p = (n(n-1)/2) * (1/2^160))`。2^80 是 1.2 x 10^24，也就是一亿亿亿，那是地球上沙粒总数的 1200 倍。
+不过，你应该了解到，这种情况发生的概率是多么微小。SHA-1 摘要长度是 20 字节，也就是 160 位。为了保证有 50% 的概率出现一次冲突，需要 2^80 个随机哈希的对象（计算冲突机率的公式是 `p = (n(n-1)/2) * (1/2^160)`)。2^80 是 1.2 x 10^24，也就是一亿亿亿，那是地球上沙粒总数的 1200 倍。
 
 现在举例说一下怎样才能产生一次 SHA-1 冲突。如果地球上 65 亿的人类都在编程，每人每秒都在产生等价于整个 Linux 内核历史（一百万个 Git 对象）的代码，并将之提交到一个巨大的 Git 仓库里面，那将花费 5 年的时间才会产生足够的对象，使其拥有 50% 的概率产生一次 SHA-1 对象冲突。这要比你编程团队的成员同一个晚上在互不相干的意外中被狼袭击并杀死的机率还要小。
 

From 1558cafa195f536c3fa5ccd8b5b3841caad96dba Mon Sep 17 00:00:00 2001
From: cor <git@cpt1.demon.nl>
Date: Sun, 23 Feb 2014 19:16:33 +0100
Subject: [PATCH 243/690] [nl] Chapter 08 - Review and retranslate

---
 nl/08-git-and-other-scms/01-chapter8.markdown | 127 +++++++++---------
 1 file changed, 63 insertions(+), 64 deletions(-)

diff --git a/nl/08-git-and-other-scms/01-chapter8.markdown b/nl/08-git-and-other-scms/01-chapter8.markdown
index ab319ad42..7d551d94d 100644
--- a/nl/08-git-and-other-scms/01-chapter8.markdown
+++ b/nl/08-git-and-other-scms/01-chapter8.markdown
@@ -1,44 +1,44 @@
 # Git en andere systemen #
 
-Het is geen perfecte wereld. Meestal kun je niet meteen elk project waar je mee in aanraking komt omzetten naar Git. Soms zit je vast op een project dat een ander VCS gebruikt, en vaak is dat systeem Subversion. In het eerste gedeelte van dit hoofdstuk zul je leren over `git svn`, het bidirectionele Subversion poort tool van Git.
+Het is geen perfecte wereld. Meestal kan je niet meteen elk project waar je mee in aanraking komt omzetten naar Git. Soms zit je vast op een project dat een ander VCS gebruikt, en vaak is dat systeem Subversion. In het eerste gedeelte van dit hoofdstuk zal je leren over `git svn`, het bidirectionele Subversion uitwissel tool van Git.
 
 Op een gegeven moment zal je een bestaande project willen omzetten naar Git. Het tweede gedeelte van dit hoofdstuk beschrijft hoe je projecten naar Git kunt migreren: eerst uit Subversion, dan vanuit Perforce, en als laatste via een eigen import script voor een niet standaard import geval.
 
 ## Git en Subversion ##
 
-Op het moment maakt het merendeel van open source ontwikkelprojecten en een groot aantal bedrijfsprojecten gebruik van Subversion om hun broncode te beheren. Het is het populairste open source VCS en bestaat al bijna tien jaar. Het lijkt ook in veel aspecten op CVS, wat daarvoor de grootste speler was in de code-beheer wereld.
+Op dit moment maakt het merendeel van open source ontwikkelprojecten en een groot aantal bedrijfsprojecten gebruik van Subversion om hun broncode te beheren. Het is het populairste open source VCS en bestaat al bijna tien jaar. Het lijkt ook in veel aspecten op CVS, wat daarvoor de grootste speler was in de code-beheer wereld.
 
-Een van de beste features van Git is een bidirectionele brug naar Subversion genaamd `git svn`. Dit tool staat je toe om Git als een volwaardige client van een Subversion server te gebruiken, zodat je alle lokale eigenschappen van Git kunt gebruiken en daarna naar een Subversion server kunt pushen alsof je Subversion lokaal gebruikt. Dit houdt in dat je lokaal kunt branchen en mergen, het staging gebied gebruiken, kunt rebasen en cherry-picken enzovoorts, terwijl je medewerkers verder werken met hun duistere en ouderwetse middelen. Het is een goede manier om Git in de bedrijfsomgeving binnen te smokkelen en je mede-ontwikkelaars te helpen efficiënter te worden terwijl jij lobbiet om de infrastructuur te veranderen om Git volledig gesupport te krijgen. De Subversion brug is het overbruggings medicijn naar de DCVS wereld.
+Een van de beste features van Git is een bidirectionele brug naar Subversion genaamd `git svn`. Dit tool staat je toe om Git als een volwaardige client van een Subversion server te gebruiken, zodat je alle lokale eigenschappen van Git kunt gebruiken en daarna naar een Subversion server kunt pushen alsof je Subversion lokaal gebruikt. Dit houdt in dat je lokaal kunt branchen en mergen, het staging gebied gebruiken, kunt rebasen en cherry-picken enzovoorts, terwijl je medewerkers verder werken met de spreekwoordelijke griffel en leisteen. Het is een goede manier om Git in de bedrijfsomgeving binnen te smokkelen en je mede-ontwikkelaars te helpen efficiënter te worden terwijl jij lobbiet om de infrastructuur dusdanig te veranderen dat Git volledig gesupport kan worden. De Subversion brug is het uitwisselings-medicijn naar de DCVS wereld.
 
 ### git svn ###
 
-Het basiscommando in Git voor alle Subversion brugcommando's is `git svn`. Je laat dit aan alles vooraf gaan. Je hebt best een aantal commando's nodig, dus je zult de meeste leren terwijl we door een aantal werkwijzen lopen.
+Het basiscommando in Git voor alle Subversion brugcommando's is `git svn`. Je laat dit aan alles vooraf gaan. Je hebt best een aantal commando's nodig, dus je zult de meest gebruikte leren terwijl we een aantal kleine workflows behandelen.
 
-Het is belangrijk om op te merken dat terwijl je `git svn` gebruikt je aan het communiceren bent met Subversion, wat een systeem is dat veel minder vergevorderd is dan Git. Alhoewel jij eenvoudig lokaal kunt branchen en mergen, is het over het algemeen het beste om je geschiedenis zo lineair als mogelijk te houden door je werk te rebasen en te vermijden dingen te doen zoals simultaan communiceren met een Git remote repository.
+Het is belangrijk om op te merken dat, terwijl je `git svn` gebruikt, je aan het communiceren bent met Subversion, wat een systeem is dat veel minder geavanceerd is dan Git. Alhoewel jij eenvoudig lokaal kunt branchen en mergen, is het over het algemeen het beste om je geschiedenis zo lineair als mogelijk te houden door je werk te rebasen en zaken te vermijden zoals tegelijkertijd communiceren met een Git remote repository.
 
-Herschrijf je geschiedenis niet om daarna nogmaals te pushen, en ga niet Git repository ernaast gebruiken om tegelijkertijd met mede Git ontwikkelaars samen te werken. Subversion kan slechts één lineaire geschiedenis hebben, en het is heel eenvoudig om het in de war brengen. Als je met een team aan het werk bent en sommigen maken gebruik van Subversion en anderen van Git, zorg dan dat iedereen de SVN server gebruikt om samen te werken; het maakt je leven een stuk eenvoudiger.
+Herschrijf je geschiedenis niet om daarna nogmaals te pushen, en ga niet Git repository ernaast gebruiken om tegelijkertijd met mede Git ontwikkelaars samen te werken. Subversion kan slechts één enkele lineaire geschiedenis aan, en het is heel eenvoudig om het in de war brengen. Als je met een team aan het werk bent en sommigen maken gebruik van Subversion en anderen van Git, zorg dan dat iedereen de SVN server gebruikt om samen te werken - het maakt je leven een stuk eenvoudiger.
 
 ### Instellen ###
 
-Om deze functionaliteit te demonstreren heb je een normale SVN repository nodig waarop je schrijftoegang hebt. Als je deze voorbeelden wilt kopiëren, zul je een schrijfbare kopie moeten maken van mijn test repository. Om dat eenvoudig te kunnen doen, kun je een tool genaamd `svnsync` gebruiken dat bij de meer recente versies van Subversion geleverd wordt; het zou minstens bij versie 1.4 moeten zitten. Voor deze tests heb ik een nieuw Subversion repository op Google code gemaakt wat een gedeeltelijke kopie is van het `protobuf` project, wat een tool is dat gestructureerde data voor netwerk transmissie encodeert.
+Om deze functionaliteit te demonstreren heb je een normale SVN repository nodig waarop je schrijftoegang hebt. Als je deze voorbeelden wilt kopiëren, zal je een schrijfbare kopie moeten maken van mijn test repository. Om dat eenvoudig te kunnen doen, kun je een tool genaamd `svnsync` gebruiken dat bij de meer recente versies van Subversion geleverd wordt - het zou vanaf versie 1.4 meegeleverd moeten zijn. Voor deze tests heb ik een nieuwe Subversion repository op Google code gemaakt wat een gedeeltelijke kopie is van het `protobuf` project, wat een tool is dat gestructureerde data voor netwerk transmissie encodeert.
 
 Om het te volgen zal je eerst een nieuw lokaal Subversion repository moeten maken:
 
 	$ mkdir /tmp/test-svn
 	$ svnadmin create /tmp/test-svn
 
-Daarna sta je alle gebruikers toe om revprops te wijzigen; de makkelijke manier is om een pre-revprop-change script toe te voegen dat altijd met 0 afsluit:
+Daarna sta je alle gebruikers toe om revprops te wijzigen - de makkelijke manier is om een pre-revprop-change script toe te voegen dat altijd met 0 afsluit:
 
 	$ cat /tmp/test-svn/hooks/pre-revprop-change
 	#!/bin/sh
 	exit 0;
 	$ chmod +x /tmp/test-svn/hooks/pre-revprop-change
 
-Je kunt dit project nu syncen naar je lokale machine door `svnsync init` aan te roepen met de van en naar repositories.
+Je kunt dit project nu syncen naar je lokale machine door `svnsync init` aan te roepen met de doel- en bronrepository.
 
 	$ svnsync init file:///tmp/test-svn http://progit-example.googlecode.com/svn/
 
-Dit stelt de eigenschappen in om de sync uit te voeren. Je kunt de code daarna klonen door dit uit te voeren
+Dit stelt de eigenschappen in om de sync uit te voeren. Je kunt de code daarna clonen door dit uit te voeren
 
 	$ svnsync sync file:///tmp/test-svn
 	Committed revision 1.
@@ -48,11 +48,11 @@ Dit stelt de eigenschappen in om de sync uit te voeren. Je kunt de code daarna k
 	Committed revision 3.
 	...
 
-Alhoewel deze operatie maar een paar minuten in beslag neemt, zal het kopiëren van het originele repository naar een ander remote repository in plaats van een lokale meer dan een uur duren, zelfs al zitten er maar minder dan 100 commits in. Subversion moet één revisie per keer klonen en dan terug pushen in een ander repository. Het is belachelijk inefficiënt, maar het is de enige makkelijke manier om dit te doen.
+Alhoewel deze operatie maar een paar minuten in beslag neemt, zal het kopiëren van de originele repository naar een andere remote repository in plaats van een lokale meer dan een uur duren, zelfs al zitten er maar minder dan 100 commits in. Subversion moet één revisie per keer clonen en dan terug pushen in een ander repository. Het is belachelijk inefficiënt - maar het is de enige makkelijke manier om dit te doen.
 
-### Beginnen ###
+### Om te beginnen ###
 
-Nu je een Subversion repository hebt met schrijftoegang, kun je door een typische werkwijze gaan. Je begint met het `git svn clone` commando, wat een volledig Subversion repository in een lokaal Git repository kloont. Onthoud dat als je van een echt beheerd Subversion repository importeert, je de `file:///tmp/test-svn` moet vervangen door de URL van jouw Subversion repository:
+Nu je een Subversion repository hebt met schrijftoegang, kun je door een typische workflow gaan. Je begint met het `git svn clone` commando, wat een volledig Subversion repository in een lokaal Git repository cloned. Onthoud dat als je van een echt beheerd Subversion repository importeert, je de `file:///tmp/test-svn` hier moet vervangen door de URL van jouw Subversion repository:
 
 	$ git svn clone file:///tmp/test-svn -T trunk -b branches -t tags
 	Initialized empty Git repository in /Users/schacon/projects/testsvnsync/svn/.git/
@@ -70,13 +70,13 @@ Nu je een Subversion repository hebt met schrijftoegang, kun je door een typisch
 	Checked out HEAD:
 	 file:///tmp/test-svn/branches/my-calc-branch r76
 
-Dit voert het equivalent uit van twee commando's: `git svn init` gevolgd door `git svn fetch`, op de URL die je aan hebt gegeven. Het kan een tijdje duren. Het testproject heeft slechts 75 commits en de hoeveelheid code is niet zo groot, dus het neemt maar een paar minuten in beslag. Maar Git moet iedere versie uitchecken, één voor één, en ze individueel committen. Voor een project met honderdduizenden commits kan dit letterlijk uren of zelfs dagen duren om af te ronden.
+Dit voert het equivalent uit van twee commando's: `git svn init` gevolgd door `git svn fetch`, op de URL die je aan hebt gegeven. Het kan een tijdje duren. Het testproject heeft slechts 75 commits en de hoeveelheid code is niet zo groot, dus het neemt maar een paar minuten in beslag. Maar Git moet iedere versie uitchecken, één voor één, en ze individueel committen. Voor een project met honderdduizenden commits kan dit letterlijk uren of zelfs dagen duren voor het klaar is.
 
-Het `-T trunk -b branches -t tags` gedeelte vertelt Git dat binnen deze Subversion repository de basale branch en tag conventie gevolgd wordt. Als je trunk, branches of tags anders noemt, kun je deze opties aanpassen. Omdat dit zo gewoon is, kun je dit hele gedeelte vervangen door `-s`, wat standaard indeling betekent en al die opties impliceert. Het volgende commando is gelijkwaardig:
+Het `-T trunk -b branches -t tags` gedeelte vertelt Git dat binnen deze Subversion repository de basale branch en tag conventie gevolgd wordt. Als je trunk, branches of tags anders noemt, kan je deze opties aanpassen. Omdat dit zo normaal is, kun je dit hele gedeelte vervangen door `-s`, wat standaard indeling betekent en al die opties impliceert. Het volgende commando is gelijkwaardig:
 
 	$ git svn clone file:///tmp/test-svn -s
 
-Nu zou je een geldig Git repository moeten hebben, dat je branches en tags geïmporteerd heeft:
+Nu zou je een geldig Git repository moeten hebben, waar de branches en tags in geïmporteerd zijn:
 
 	$ git branch -a
 	* master
@@ -87,7 +87,7 @@ Nu zou je een geldig Git repository moeten hebben, dat je branches en tags geïm
 	  tags/release-2.0.2rc1
 	  trunk
 
-Het is belangrijk om te zien dat dit tool je remote references een andere naamruimte heeft toebedeeld. Als je normaal een Git repository kloont, krijg je alle branches op die remote server lokaal beschikbaar in de vorm van `origin/[branch]`, waarbij de naamruimte de naam van de remote gebruikt. Maar, `git svn` gaat er vanuit dat je niet meerdere remotes hebt en bewaart alle referentie naar punten op de remote server zonder naamruimte. Je kunt het Git plumbing commando `show-ref` gebruiken om al je volledige referentie namen te zien:
+Het is belangrijk om op te merken dat dit tool je remote references een andere namespace heeft toebedeeld. Als je normaal een Git repository cloned, krijg je alle branches op die remote server lokaal beschikbaar in de vorm van `origin/[branch]` - waarbij in de namespace de naam van de remote wordt gebruikt. Echter, `git svn` gaat er vanuit dat je niet meerdere remotes hebt en bewaart alle referentie naar punten op de remote server zonder gebruik te maken van namespaces. Je kunt het Git plumbing commando `show-ref` gebruiken om al je volledige referentie namen te zien:
 
 	$ git show-ref
 	1cbd4904d9982f386d87f88fce1c24ad7c0f0471 refs/heads/master
@@ -108,17 +108,17 @@ Een normale Git repository ziet er meer zo uit:
 
 Hier zijn er twee remote servers: een genaamd `gitserver` met een `master` branch, en een andere genaamd `origin` met twee branches, `master` en `testing`.
 
-Zie hoe in het voorbeeld van met `git svn` geïmporteerde remote referenties de tags toegevoegd zijn als remote branches, niet als echte Git tags. De Subversion import ziet eruit alsof het een remote heeft dat tags heet waaronder branches zitten.
+Zie hoe in het voorbeeld van met `git svn` geïmporteerde remote referenties, de tags toegevoegd zijn als remote branches, niet als echte Git tags. De Subversion import ziet eruit alsof het een remote heeft dat tags heet waaronder branches zitten.
 
 ### Terug naar Subversion committen ###
 
-Nu dat je een werkende repository hebt, kun je wat werken aan het project en je commits stroomopwaarts pushen, waarbij je Git effectief als een SVN client gebruikt. Als je een van de bestanden aanpast en het commit, heb je een lokale commit in Git, deze bestaat niet op de Subversion server:
+Nu je een werkende repository hebt, kun je wat werken aan het project en je commits stroomopwaarts pushen, waarbij je Git effectief als een SVN client gebruikt. Als je een van de bestanden aanpast en deze commit, heb je een lokale commit in Git die nog niet bestaat op de Subversion server:
 
 	$ git commit -am 'Adding git-svn instructions to the README'
 	[master 97031e5] Adding git-svn instructions to the README
 	 1 files changed, 1 insertions(+), 1 deletions(-)
 
-Vervolgens moet je de verandering stroomopwaarts pushen. Zie hoe dit de manier verandert waarop je met Subversion werkt: je kunt een paar commits offline doen en ze dan in één blok naar de Subversion server pushen. Om naar een Subversion server te pushen, voer je het `git svn dcommit` commando uit:
+Vervolgens moet je de verandering stroomopwaarts pushen. Merk op hoe dit de manier verandert waarop je met Subversion werkt: je kunt een paar commits offline doen en ze dan als één blok naar de Subversion server pushen. Om naar een Subversion server te pushen, voer je het `git svn dcommit` commando uit:
 
 	$ git svn dcommit
 	Committing to file:///tmp/test-svn/trunk ...
@@ -152,7 +152,7 @@ Als je met andere developers samenwerkt, dan zal op een bepaald moment één van
 	out-of-date: resource out of date; try updating at /Users/schacon/libexec/git-\
 	core/git-svn line 482
 
-Om deze situatie op te lossen moet je `git svn rebase` uitvoeren wat alle wijzigingen op de server die je nog niet hebt pulled, en daarna al het werk dat je hebt bovenop wat op de server staat rebased:
+Om deze situatie op te lossen moet je `git svn rebase` uitvoeren waardoor alle wijzigingen op de server die je nog niet hebt worden gepulled, en daarna al het werk dat je hebt bovenop wat op de server staat rebased:
 
 	$ git svn rebase
 	       M      README.txt
@@ -160,7 +160,7 @@ Om deze situatie op te lossen moet je `git svn rebase` uitvoeren wat alle wijzig
 	First, rewinding head to replay your work on top of it...
 	Applying: first user change
 
-Nu is al jouw werk bovenop hetgeen wat op de Subversion server staat gebracht, en kan je een succesvolle `dcommit` doen:
+Nu is al jouw werk bovenop hetgeen wat op de Subversion server staat gebaseerd, en kan je een succesvolle `dcommit` doen:
 
 	$ git svn dcommit
 	Committing to file:///tmp/test-svn/trunk ...
@@ -171,7 +171,7 @@ Nu is al jouw werk bovenop hetgeen wat op de Subversion server staat gebracht, e
 	No changes between current HEAD and refs/remotes/trunk
 	Resetting to the latest refs/remotes/trunk
 
-Het is belangrijk te onthouden dat in tegenstelling tot Git, die van je verlangt dat je werk van stroomopwaarts wat je nog niet lokaal hebt staan merged voordat je mag pushen, `git svn` je dit alleen laat doen als de wijzigingen conflicteren. Als iemand anders een verandering naar een bestand pushed en daarna push jij een verandering op een ander bestand, dan zal het `commit` commando prima werken:
+Het is belangrijk te onthouden dat in tegenstelling tot Git, die van je verlangt dat je werk van stroomopwaarts wat je nog niet lokaal hebt staan eerst merged voordat je mag pushen, `git svn` je dit alleen laat doen als de wijzigingen conflicteren. Als iemand anders een verandering naar een bestand pusht en daarna push jij een verandering op een ander bestand, dan zal het `commit` commando prima werken:
 
 	$ git svn dcommit
 	Committing to file:///tmp/test-svn/trunk ...
@@ -188,9 +188,9 @@ Het is belangrijk te onthouden dat in tegenstelling tot Git, die van je verlangt
 	First, rewinding head to replay your work on top of it...
 	Nothing to do.
 
-Dit is belangrijk om te onthouden, want de uitkomst is een project status die niet bestond op één van jullie beider computers toen je pushte. Als de veranderingen incompatibel zijn maar niet conflicteren, dan kun je problemen krijgen die lastig te diagnosticeren zijn. Het is anders dan een Git server gebruiken; in Git kun je de status volledig op je gebruikerssysteem testen voordat je het publiceert, terwijl je met SVN je nooit zeker kunt zijn dat de statussen vlak voor je commit en na je commit gelijk zijn.
+Dit is belangrijk om te onthouden, omdat de uitkomst een project status is die niet bestond op één van jullie beider computers toen je pushte. Als de veranderingen incompatibel zijn maar niet conflicteren, dan kun je problemen krijgen die lastig te diagnosticeren zijn. Het verschilt van het gebruik van een Git server; in Git kan je de status volledig op je gebruikerssysteem testen voordat je het publiceert, terwijl je met SVN je nooit zeker kunt zijn dat de statussen vlak voor je commit en na je commit gelijk zijn.
 
-Je moet dit commando ook moeten uitvoeren om wijzigingen te pullen van de Subversion server, ook als je zelf nog niet klaar bent om te committen. Je kunt `git svn fetch` uitvoeren om de nieuwe data te pakken, maar `git svn rebase` doet de fetch en vernieuwt je lokale commits.
+Je moet dit commando ook moeten uitvoeren om wijzigingen te pullen van de Subversion server, zelfs als je zelf nog niet klaar bent om te committen. Je kunt `git svn fetch` uitvoeren om de nieuwe data binnen te halen, maar `git svn rebase` doet de fetch en vernieuwt je lokale commits.
 
 	$ git svn rebase
 	       M      generate_descriptor_proto.sh
@@ -198,11 +198,11 @@ Je moet dit commando ook moeten uitvoeren om wijzigingen te pullen van de Subver
 	First, rewinding head to replay your work on top of it...
 	Fast-forwarded master to refs/remotes/trunk.
 
-Regelmatig `git svn rebase` uitvoeren zorgt er voor dat je code altijd up to date is. Je moet er wel zeker van zijn dat je werkdirectory schoon is voor je dit uitvoert. Als je lokale wijzigingen hebt, moet je of eerst je werk stashen, of tijdelijk committen voordat je `git svn rebase` uitvoert; anders zal het commando stoppen als het ziet dat de rebase zal resulteren in een mergeconflict.
+Regelmatig `git svn rebase` uitvoeren zorgt er voor dat je code altijd up to date is. Je moet er echter wel zeker van zijn dat je werkdirectory schoon is voor je dit uitvoert. Als je lokale wijzigingen hebt, moet je of eerst je werk stashen, of tijdelijk committen voordat je `git svn rebase` uitvoert - anders zal het commando stoppen zodra het ziet dat de rebase zal resulteren in een mergeconflict.
 
 ### Git branch problemen ###
 
-Als je op je gemak bent met een Git werkwijze, zul je waarschijnlijk topic branches gaan maken, er werk op doen en ze dan mergen. Als je naar een Subversion server pusht via git svn, zou je kunnen overwegen je werk iedere keer op een enkele branch rebasen in plaats van de branches samen mergen. De reden om rebasen te prefereren is dat Subversion een lineaire geschiedenis heeft, en niet met merges omgaat op de manier zoals Git dat doet, dus git svn volgt alleen de eerste ouder op het moment dat de snapshots naar Subversion commits omgezet worden.
+Als je gewend geraakt bent aan een Git workflow, zal je waarschijnlijk topic branches gaan maken, er werk op doen en ze dan terug mergen. Als je naar een Subversion server pusht via git svn, zou je kunnen overwegen je werk iedere keer op een enkele branch rebasen in plaats van de branches samen te mergen. De reden om rebasen te prefereren is dat Subversion een lineaire geschiedenis heeft, en niet met merges omgaat op de manier zoals Git dat doet, dus git svn volgt alleen de eerste ouder op het moment dat de snapshots naar Subversion commits omgezet worden.
 
 Stel dat je geschiedenis er zoals volgt uitziet: je hebt een `experiment` branch gemaakt, twee commits gedaan en ze dan terug in `master` gemerged. Als je dan `dcommit` zie je output zoals dit:
 
@@ -227,11 +227,11 @@ Stel dat je geschiedenis er zoals volgt uitziet: je hebt een `experiment` branch
 
 Het uitvoeren van `dcommit` op een branch met gemergede historie werkt prima, maar wanneer je naar je Git project historie kijkt zie je dat geen van beide commits die je op de `experiment` branch gedaan hebt herschreven is. In plaats daarvan verschijnen al die wijzigingen in de SVN versie van de enkele merge commit.
 
-Als iemand anders dat werk kloont, is alles wat ze zien de merge commit met al het werk erin gesquashed; ze zien niet de commit gegevens met waar het vandaan kwam of wanneer het was gecommit.
+Als iemand anders dat werk cloned, is alles wat ze zien de merge commit met al het werk erin gesquashed; ze zien niet de commit gegevens met waar het vandaan kwam of wanneer het was gecommit.
 
 ### Subversion branchen ###
 
-Branchen in Subversion is niet hetzelfde als branchen in Git; het is waarschijnlijk het beste om het zoveel mogelijk te vermijden. Maar, je kunt Subversion branches maken en naar committen door gebruik te maken van git svn.
+Branchen in Subversion is niet hetzelfde als branchen in Git; het is waarschijnlijk het beste om het zoveel mogelijk te vermijden. Maar, je kunt Subversion branches maken en daarnaar committen met git svn.
 
 #### Een nieuwe SVN branch maken ####
 
@@ -252,17 +252,17 @@ Dit doet hetzelfde als het `svn copy trunk branches/opera` commando in Subversio
 
 Git zoekt uit naar welke branch de dcommits horen te gaan door te kijken naar de punt van elk van je Subversion branches in je geschiedenis; je zou er slechts één moeten hebben, en het zou de laatste moeten zijn met een `git-svn-id` in je huidige branch historie.
 
-Als je wilt werken op meer dan één branch, dan kun je lokale branches instellen om de `dcommit` naar specifieke Subversion branches te doen door ze te starten bij de geïmporteerde Subversion commit voor die branch. Als je een `opera` branch wilt hebben waar je apart op kunt werken, kun je dit uitvoeren
+Als je wilt werken op meer dan één branch, dan moet je lokale branches aanmaken om te `dcommit`-en naar specifieke Subversion branches door ze te beginnen bij de geïmporteerde Subversion commit voor die branch. Als je een `opera` branch wilt hebben waar je apart op kunt werken, kun je dit uitvoeren
 
 	$ git branch opera remotes/opera
 
 Als je de `opera` branch nu in `trunk` (jouw `master` branch) wilt mergen, kan je dit doen met een normale `git merge`. Maar je moet een beschrijvend commit bericht meegeven (via `-m`), omdat de merge anders "Merge branch opera" zal bevatten in plaats van iets bruikbaars.
 
-Onthoud dat alhoewel je `git merge` gebruikt voor deze operatie, en de merge waarschijnlijk veel makkelijker gaat dan het in Subversion zou gaan (omdat Git automatisch de merge basis voor je zal detecteren), dit geen normale Git merge commit is. Je moet deze data terug pushen naar een Subversion server die geen commit aan kan die meer dan één ouder volgt; dus nadat je het gepusht hebt, zal het eruit zien als een enkele commit waarbij al het werk van een andere branch erin gesquashed zit onder één enkele commit. Nadat je een branch in een andere gemerged hebt, kan je niet eenvoudig terug gaan en op die branch verder werken zoals je dat normaal in Git zou doen. Het `dcommit` commando dat je uitvoert wist alle informatie die kan vertellen welke branch erin gemerged was, dus opvolgende merge-basis berekeningen zullen fout gaan. De `dcommit` zal je `git merge` resultaat eruit laten zien alsof je `git merge --squash` uitgevoerd hebt. Helaas is er geen manier om deze situatie te vermijden: Subversion kan deze informatie niet opslaan, dus je zult altijd gelimiteerd zijn door zijn beperkingen zolang als je het als server gebruikt. Om problemen te vermijden zou je de lokale branch moeten verwijderen (in dit geval `opera`), nadat je hem in trunk gemerged hebt.
+Onthoud dat alhoewel je `git merge` gebruikt voor deze operatie, en de merge waarschijnlijk veel makkelijker gaat dan het in Subversion zou gaan (omdat Git automatisch de merge basis voor je zal detecteren), dit geen normale Git merge commit is. Je moet deze data terug pushen naar een Subversion server die geen commit aan kan die meer dan één ouder trackt; dus nadat je het gepusht hebt, zal het eruit zien als een enkele commit waarbij al het werk van een andere branch erin gesquashed zit onder één enkele commit. Nadat je een branch in een andere gemerged hebt, kan je niet eenvoudig terug gaan en op die branch verder werken zoals je dat normaal in Git zou doen. Het `dcommit` commando dat je uitvoert wist alle informatie die kan vertellen welke branch erin gemerged was, dus daarop volgende merge-basis berekeningen zullen fout gaan. De `dcommit` zal je `git merge` resultaat eruit laten zien alsof je `git merge --squash` uitgevoerd hebt. Helaas is er geen manier om deze situatie te vermijden: Subversion kan deze informatie niet opslaan, dus je zult altijd beperkt zijn door zijn tekortkomingen zolang als je het als server gebruikt. Om problemen te vermijden zou je de lokale branch moeten verwijderen (in dit geval `opera`), nadat je hem in trunk gemerged hebt.
 
 ### Subversion commando's ###
 
-De `git svn` toolset levert een aantal commando's om de overgang naar Git te vergemakkelijken, door sommige functionaliteit te leveren die vergelijkbaar is met wat je in Subversion had. Hier zijn een paar commando's die je geven wat Subversion voorheen deed.
+De `git svn` toolset levert een aantal commando's om de overgang naar Git te vergemakkelijken, door functionaliteit te leveren die vergelijkbaar is met wat je in Subversion had. Hier zijn een paar commando's die je geven wat Subversion voorheen deed.
 
 #### SVN achtige historie ####
 
@@ -284,11 +284,11 @@ Als je gewend bent aan Subversion en je wil de historie in SVN achtige output zi
 
 	updated the changelog
 
-Je moet twee belangrijke zaken onthouden over `git svn log`. Ten eerste: het werkt offline en niet zoals het echte `svn log` commando dat de Subversion server vraagt om de data. Ten tweede: het toont je alleen commits die zijn gecommit naar de Subversion server. Lokale Git commits, die je nog niet ge-dcommit hebt worden niet getoond; een ook commits die mensen gedaan hebben in de tussentijd naar de Subversion server. Het is meer de laatst bekende status van de commits op de Subversion server.
+Je moet twee belangrijke zaken onthouden over `git svn log`. Ten eerste: het werkt offline en niet zoals het echte `svn log` commando waarbij de Subversion server vraagt om de data. Ten tweede: het toont je alleen commits die zijn gecommit naar de Subversion server. Lokale Git commits, die je nog niet ge-dcommit hebt worden niet getoond; een ook commits die mensen in de tussentijd gedaan hebben naar de Subversion server. Het is meer de laatst bekende status van de commits op de Subversion server.
 
 #### SVN annotatie ####
 
-Zoals het `git svn log` commando het `svn log` commando offline simuleert, kun je het equivalent van `svn annotate` krijgen door `git svn blame [BESTAND]` uit te voeren. De output ziet er zo uit:
+Zoals het `git svn log` commando het `svn log` commando offline simuleert, kan je het equivalent van `svn annotate` krijgen door `git svn blame [BESTAND]` uit te voeren. De output ziet er zo uit:
 
 	$ git svn blame README.txt
 	 2   temporal Protocol Buffers - Google's data interchange format
@@ -326,7 +326,7 @@ Dit is vergelijkbaar met `blame` en `log` in dat het offline draait en alleen up
 
 #### Negeren wat Subversion negeert ####
 
-Als je een Subversion repository kloont die ergens `svn:ignore` eigenschappen bevat, dan zul je waarschijnlijk overeenkomstige `.gitignore` bestanden in willen richten zodat je niet per ongeluk bestanden commit die niet hadden gemogen. `git svn` heeft twee commando's die met dit probleem helpen. De eerste is `git svn create-ignore` wat automatisch `.gitignore` bestanden voor je genereert zodat je het bij je volgende commit kan gebruiken.
+Als je een Subversion repository cloned die ergens `svn:ignore` eigenschappen bevat, dan zul je waarschijnlijk overeenkomstige `.gitignore` bestanden in willen richten zodat je niet per ongeluk bestanden commit die niet hadden gemogen. `git svn` heeft twee commando's die met dit probleem helpen. De eerste is `git svn create-ignore` wat automatisch `.gitignore` bestanden voor je genereert zodat je het bij je volgende commit kan gebruiken.
 
 Het tweede commando is `git svn show-ignore` wat op stdout de regels afdrukt die je in een `.gitignore` bestand moet stoppen zodat je de output in het exclude bestand van je project kunt stoppen:
 
@@ -336,38 +336,38 @@ Op die manier vervuil je het project niet met `.gitignore` bestanden. Dit is een
 
 ### Git-Svn samenvatting ###
 
-De `git svn` tools zijn nuttig als je voorlopig vast zit aan een Subversion server, of op een andere manier in een ontwikkelomgeving zit waar het draaien van een Subversion server noodzakelijk is. Je moet het echter beschouwen als een kreupele Git, anders loop je tegen problemen in de vertaling aan, die jou en je medewerkers in verwarring kunnen brengen. Om uit de problemen te blijven moet je deze regels volgen:
+De `git svn` tools zijn nuttig als je voorlopig vast zit aan een Subversion server, of op een andere manier in een ontwikkelomgeving zit waar het draaien van een Subversion server noodzakelijk is. Je moet het echter beschouwen als een gemankteerde Git, anders loop je tegen problemen in de vertaling aan, die jou en je medewerkers in verwarring kunnen brengen. Om uit de problemen te blijven moet je deze regels volgen:
 
 * Houdt een lineaire Git historie aan die geen merge commits bevat die gedaan zijn door `git merge`. Rebase al het werk dat je buiten je hoofd branch doet daarop; niet erin mergen.
-* Geen aparte Git server inrichten en daar op samenwerken. Je kunt er een hebben om het maken van kloons voor nieuwe developers te versnellen, maar push er niets terug in dat geen `git-svn-id` vermelding heeft. Je zou zelfs een `pre-receive` hook kunnen toevoegen, die elk commit bericht controleert op een `git-svn-id` en pushes weigert die commits zonder bevatten.
+* Geen aparte Git server inrichten en daar op samenwerken. Je kunt er een hebben om het maken van clones voor nieuwe developers te versnellen, maar push er niets terug in dat geen `git-svn-id` vermelding heeft. Je zou zelfs een `pre-receive` hook kunnen toevoegen, die elk commit bericht controleert op een `git-svn-id` en pushes weigert die commits zonder bevatten.
 
 Als je deze regels volgt dan kan werken met een Subversion server dragelijker zijn. Maar als het mogelijk is om over te gaan naar een echte Git server, dan kan dat je team een hoop meer profijt geven.
 
 ## Naar Git migreren ##
 
-Als je een bestaande hoeveelheid broncode in een ander VCS hebt, en je hebt besloten om Git te gaan gebruiken dan moet je het project op een of andere manier migreren. Deze paragraaf behandelt een aantal importeerders die bij Git worden geleverd voor veel voorkomende systemen, en demonstreert daarna hoe je je eigen importeerder kunt ontwikkelen.
+Als je een bestaande hoeveelheid broncode in een ander VCS hebt, en je hebt besloten om Git te gaan gebruiken dan moet je het project onvermijdelijk migreren. Deze paragraaf behandelt een aantal importeerders die bij Git worden geleverd voor veel voorkomende systemen, en demonstreert daarna hoe je je eigen importeerder kunt ontwikkelen.
 
 ### Importeren ###
 
-Je zult leren hoe je data uit twee van de grotere professioneel gebruikte SCM systemen kunt importeren, Subversion en Perforce. Dit omdat zij op dit moment de grootste gebruikersgroep hebben waarvan ik op dit moment hoor dat ze willen wisselen, en omdat er tools van hoge kwaliteit voor beide systemen meegeleverd worden met Git.
+Je zult leren hoe je data uit twee van de grotere professioneel gebruikte SCM systemen kunt importeren, Subversion en Perforce. Dit omdat zij op dit moment de grootste gebruikersgroep hebben waarvan ik op dit moment hoor dat ze willen omschakelen, en omdat er tools van hoge kwaliteit voor beide systemen meegeleverd worden met Git.
 
 ### Subversion ###
 
-Als je de vorige paragraaf over het gebruik van `git svn` heb gelezen, kun je die instructies eenvoudig gebruiken om een `git svn clone` te doen op een repository. Daarna stop je met het gebruik van de Subversion server, pushed naar de nieuwe Git server, en gaat die gebruiken. Als je de historie wilt hebben kan dat zo snel als dat je van de server kunt pullen voor elkaar krijgen (dat echter even duren).
+Als je de vorige paragraaf over het gebruik van `git svn` heb gelezen, kun je die instructies eenvoudig gebruiken om een `git svn clone` te doen op een repository. Daarna stop je met het gebruik van de Subversion server, pusht naar de nieuwe Git server, en gaat die gebruiken. Als je de historie wilt hebben kan dat zo snel als dat je van de server kunt pullen voor elkaar krijgen (dat echter even duren).
 
-Maar de import is niet perfect; en omdat het zo lang zal duren kan je het maar beter goed doen. Het eerste probleem is informatie over de auteurs. In Subversion heeft iedere persoon die commit een gebruikersaccount op het systeem, wat wordt opgenomen in de commit informatie. De voorbeelden in de voorgaande paragraaf laten `schacon` zien op bepaalde plaatsen zoals de `blame` output en bij `git svn log`. Als je dit naar betere Git auteur data wilt vertalen, dan heb je een vertaling nodig van de Subversion gebruikers naar de Git auteurs. Maak een bestand genaamd `users.txt` die deze vertaling in dit formaat heeft:
+Echter, de import is niet perfect; en omdat het zo veel tijd in beslag neemt kan je het maar beter meteen goed doen. Het eerste probleem is informatie over de auteurs. In Subversion heeft iedere persoon die commit een gebruikersaccount op het systeem, welke wordt opgenomen in de commit informatie. De voorbeelden in de voorgaande paragraaf laten `schacon` zien op bepaalde plaatsen zoals de `blame` output en bij `git svn log`. Als je dit naar betere Git auteur data wilt vertalen, dan heb je een vertaaltabel nodig van de Subversion gebruikers naar de Git auteurs. Maak een bestand genaamd `users.txt` die een tabel in dit formaat heeft:
 
 	schacon = Scott Chacon <schacon@geemail.com>
 	selse = Someo Nelse <selse@geemail.com>
 
-Om een lijst te krijgen van de auteurnamen die SVN gebruikt kun je dit uitvoeren:
+Om een lijst te krijgen van de auteurnamen die in SVN gebruikt worden, kan je dit uitvoeren:
 
 	$ svn log ^/ --xml | grep -P "^<author" | sort -u | \
 	      perl -pe 's/<author>(.*?)<\/author>/$1 = /' > users.txt
 
-Daarmee krijg je de log output in XML formaat, je kunt hierin zoeken naar de auteurs, eenn lijst met unieke vermeldingen creëren en dan de XML eruit verwijderen. (Dit werkt uiteraard alleen op een machine waarop `grep`, `sort` en `Perl` geïnstalleerd is.) Daarna stuur je die output naar je users.txt bestand zodat je de overeenkomstige Git gebruiker data naast iedere vermelding kunt zetten.
+Daarmee krijg je de log output in XML formaat - je kunt hierin zoeken naar de auteurs, een lijst met unieke vermeldingen creëren en dan de XML eruit verwijderen. (Dit werkt uiteraard alleen op een machine waarop `grep`, `sort` en `Perl` geïnstalleerd is.) Daarna stuur je die output naar je users.txt bestand zodat je de overeenkomstige Git gebruiker gegevens naast iedere vermelding kunt zetten.
 
-Je kunt dit bestand meegeven aan `git svn` om het te helpen de auteur data juist te vertalen. Je kunt `git svn` ook vertellen dat het niet de metadata moet toevoegen die Subversion normaal importeert, door de `--no-metadata` optie mee te geven aan het `clone` of `init` commando. Dit laat je `import` commando er zo uit zien:
+Je kunt dit bestand meegeven aan `git svn` om het te helpen de auteur gegevens juist te vertalen. Je kunt `git svn` ook vertellen dat het de metadata die Subversion normaal importeert niet te gebruiken, door de `--no-metadata` optie mee te geven aan het `clone` of `init` commando. Dit laat je `import` commando er zo uit zien:
 
 	$ git-svn clone http://my-project.googlecode.com/svn/ \
 	      --authors-file=users.txt --no-metadata -s my_project
@@ -390,9 +390,9 @@ zien ze er zo uit:
 
 	    fixed install - go to trunk
 
-Niet alleen het auteur veld ziet er beter uit, maar het `git-svn-id` is ook niet meer aanwezig.
+Niet alleen het Author veld ziet er beter uit, maar het `git-svn-id` is ook niet meer aanwezig.
 
-Je moet nog een beetje `post-import` schoonmaak doen. Je moet nog de vreemde referenties die `git svn` ingesteld heeft opruimen bijvoorbeeld. Als eerste verplaats je de tags zodat het echte tags worden in plaats van vreemde remote branches, en dan verplaats je de rest van de branches zodat ze lokaal worden.
+Je moet nog wat `post-import` schoonmaak doen. Je moet bijvoorbeeld nog de rare referenties die `git svn` opgezet heeft opruimen. Als eerste verplaats je de tags zodat het echte tags worden in plaats van vreemde remote branches, en dan verplaats je de rest van de branches zodat ze lokaal worden.
 
 Om de tags goede Git tags te laten worden, voer je dit uit
 
@@ -404,11 +404,10 @@ Daarna verplaats je de rest van de referenties onder `refs/remotes` zodat het lo
 
 	$ git for-each-ref refs/remotes | cut -d / -f 3- | grep -v @ | while read branchname; do git branch "$branchname" "refs/remotes/$branchname"; git branch -r -d "$branchname"; done
 
-Nu zijn alle oude branches echte Git branches, en alle oude tags echte Git tags. Het laatste wat je moet doen is je nieuwe Git server als een remote toevoegen en er naar pushen. Hier is een voorbeeld van hoe je de server als een remote toevoegt:
+Nu zijn alle oude branches echte Git branches en alle oude tags echte Git tags. Het laatste wat je moet doen is je nieuwe Git server als een remote toevoegen en er naar pushen. Hier is een voorbeeld van hoe je de server als een remote toevoegt:
 
 	$ git remote add origin git@my-git-server:myrepository.git
 
-
 Omdat je al jouw branches en tags naar de server wilt laten gaan, kun je dit uitvoeren:
 
 	$ git push origin --all
@@ -418,12 +417,12 @@ Al je branches en tags zouden op je Git server moeten staan in een mooie schone
 
 ### Perforce ###
 
-Het volgende systeem waar je naar gaat kijken om vanuit te importeren is Perforce. Er zit ook een Perforce importeerder bij de Git distributie. Als je een Git versie van voor 1.7.11 hebt, zit deze alleen in het `contrib` gedeelte van de broncode. In dat geval, moet je de Git broncode ophalen, die je van git.kernel.org kunt downloaden:
+Het volgende systeem waar je naar gaat kijken om vanuit te importeren is Perforce. Er zit ook een Perforce importeerder bij de Git distributie. Als je een Git versie vóór 1.7.11 hebt, zit deze alleen in het `contrib` gedeelte van de broncode. In dat geval, moet je de Git broncode ophalen, die je van git.kernel.org kunt downloaden:
 
 	$ git clone git://git.kernel.org/pub/scm/git/git.git
 	$ cd git/contrib/fast-import
 
-In deze `fast-import` directory, zou je een uitvoerbaar Python script genaamd `git-p4` moeten vinden. Je moet Python en het `p4` tool geïnstalleerd hebben op je machine om deze import te laten werken. Als voorbeeld ga je het Jam project van de Perforce Public Depot importeren. Om je client in te stellen, moet je de P$PORT omgevingsvariabele laten wijzen naar het Perforce depot:
+In deze `fast-import` directory, zou je een uitvoerbaar Python script genaamd `git-p4` moeten vinden. Je moet Python en het `p4` tool geïnstalleerd hebben op je machine om deze import te laten werken. Als voorbeeld ga je het Jam project van de Perforce Public Depot importeren. Om je client in te stellen, moet je de P4PORT omgevingsvariabele laten wijzen naar het Perforce depot:
 
 	$ export P4PORT=public.perforce.com:1666
 
@@ -457,7 +456,7 @@ Als je naar de `/opt/p4import` directory gaat en `git log` uitvoert, kun je je g
 
 	    [git-p4: depot-paths = "//public/jam/src/": change = 3108]
 
-Je kunt de `git-p4` identificator in iedere commit zien. Het is prima om die identificator daar te bewaren, voor het geval je later naar het Perforce wijzigingsnummer moet refereren. Maar, als je de identificator wilt verwijderen is nu het geschikte moment om dat te doen, voordat je begint met werken op de nieuwe repository. Je kunt `git filter-branch` gebruiken om de identificatie tekst en masse te verwijderen:
+Je kunt de `git-p4` identificator in iedere commit zien. Het is prima om die identificator daar te laten, voor het geval je later naar het Perforce wijzigingsnummer moet refereren. Maar, als je de identificator wilt verwijderen is nu het geschikte moment om dat te doen - voordat je begint met werken op de nieuwe repository. Je kunt `git filter-branch` gebruiken om de identificatie tekst en masse te verwijderen:
 
 	$ git filter-branch --msg-filter '
 	        sed -e "/^\[git-p4:/d"
@@ -483,11 +482,11 @@ Als je `git log` uitvoert, zal je zien dat alle SHA-1 checksums voor de commits
 
 	    Update derived jamgram.c
 
-Je import is nu klaar om naar je nieuwe Git server gepushed te worden.
+Je import is nu klaar om naar je nieuwe Git server gepusht te worden.
 
 ### Een eigen importeerder ###
 
-Als het door jou gebruikte systeem niet Subversion of Perforce is, zou je online voor een importeerder moeten zoeken. Er zijn importeerders van goede kwaliteit beschikbaar voor CVS, Clear Case, Visual Source Safe, en zelfs een directory met archieven. Als geen van deze tools voor jou geschikt is, je hebt een zeldzame tool of je hebt om een andere reden een eigen import proces nodig, dan zou je `git fast-import` moeten gebruiken. Dit commando leest eenvoudige instructies van stdin om specifieke Git data te schrijven. Het is veel eenvoudiger om op deze manier Git objecten te maken dan de kale Git commando's uit te voeren, of om te proberen de kale objecten te schrijven (zie hoofdstuk 9 voor meer informatie). Op deze manier kun je een import script schrijven dat de noodzakelijke data uit het systeem leest dat je aan het importeren bent en rechtstreeks instructies op stdout afdrukt. Je kunt dit programma dan uitvoeren en de output door `git fast-import` sluizen (pipen).
+Als het door jou gebruikte systeem niet Subversion of Perforce is, zou je online voor een importeerder moeten zoeken. Er zijn importeerders van goede kwaliteit beschikbaar voor CVS, Clear Case, Visual Source Safe, en zelfs voor een directory met archieven. Als geen van deze tools voor jou geschikt is, je hebt een zeldzame tool of je hebt om een andere reden een eigen import proces nodig, dan zou je `git fast-import` moeten gebruiken. Dit commando leest eenvoudige instructies van stdin om specifieke Git data te schrijven. Het is veel eenvoudiger om op deze manier Git objecten te maken dan de kale Git commando's uit te voeren, of om te proberen de kale objecten te schrijven (zie hoofdstuk 9 voor meer informatie). Op deze manier kun je een import script schrijven dat de noodzakelijke data uit het systeem dat je aan het importeren bent leest en rechtstreeks instructies op stdout afdrukt. Je kunt dit programma dan uitvoeren en de output door `git fast-import` sluizen (pipen).
 
 Voor een korte demonstratie ga je een eenvoudige importeerder schrijven. Stel dat je in current werkt, waarbij je eens in de zoveel tijd een backup maakt door de projectdirectory te kopiëren naar een backup directory die gelabeld is met de tijd `back_YYYY_MM_DD`, en je wil dit in Git importeren. Je directory-structuur ziet er zo uit:
 
@@ -498,11 +497,11 @@ Voor een korte demonstratie ga je een eenvoudige importeerder schrijven. Stel da
 	back_2009_02_03
 	current
 
-Om naar een Git directory te importeren, moet je naslaan hoe Git zijn data opslaat. Je kunt je misschien herinneren dat Git eigenlijk een gelinkte lijst is met commit objecten die naar een snapshot van inhoud wijzen. Het enige dat je hoeft te doen, is `fast-import` vertellen wat de inhoud snapshots zijn, welke commit data er naar wijst en de volgorde waarin ze moeten staan. Je strategie zal bestaan uit het doorlopen van de snapshots en commits te creëren met de inhoud van iedere directory, waarbij je iedere commit terug linkt met de vorige.
+Om naar een Git directory te importeren, moet je nalezen hoe Git zijn data opslaat. Je kunt je misschien herinneren dat Git eigenlijk een gelinkte lijst is met commit objecten die naar een snapshot van de inhoud wijzen. Het enige dat je hoeft te doen, is `fast-import` vertellen wat de inhoud snapshots zijn, welke commit data er naar wijst en de volgorde waarin ze moeten staan. Je strategie zal bestaan uit het doorlopen van de snapshots en commits te creëren met de inhoud van iedere directory, waarbij je iedere commit terug linkt met de vorige.
 
-Zoals je dat ook gedaan hebt in de "Een Voorbeeld van Git-Afgedwongen Beleid" paragraaf van Hoofdstuk 7 gaan we dit in Ruby schrijven, omdat ik daar over normaalgesproken mee werk en het relatief eenvoudig is te lezen. Je kunt dit voorbeeld vrij eenvoudig schrijven in alles waar je bekend mee bent, het hoeft alleen de juiste informatie naar stdout te schrijven. En dat betekent dat als je op Windows werkt je erg voorzichtig moet zijn om geen carriage returns te introduceren aan het einde van je regels. Want git fast-import is erg kieskeurig wat dat betreft: hij wil slechts line feeds (LF) hebben en niet de cariage return line feeds (CRLF) die Windows gebruikt.
+Zoals je dat ook gedaan hebt in de "Een Voorbeeld van Git-Afgedwongen Beleid" paragraaf van Hoofdstuk 7 gaan we dit in Ruby schrijven, omdat ik daar over normaalgesproken mee werk en het relatief eenvoudig is te lezen. Je kunt dit voorbeeld vrij eenvoudig schrijven in hetgeen waar je bekend mee bent, het hoeft alleen de juiste informatie naar stdout te schrijven. En dat betekent dat als je op Windows werkt je erg voorzichtig moet zijn om geen carriage returns te introduceren aan het einde van je regels. Want git fast-import is erg kieskeurig wat dat betreft: hij wil slechts line feeds (LF) hebben en niet de cariage return line feeds (CRLF) die Windows gebruikt.
 
-Om te beginnen ga je naar de doeldirectory en identificeert iedere subdirectory waarvan elk een snapshot is dat je als commit wil importeren. Dan ga je in iedere subdirectort en print de noodzakelijke commando's om ze te exporteren. Je basis hoofdlus ziet er zo uit:
+Om te beginnen ga je naar de doeldirectory en identificeert iedere subdirectory, waarvan elk een snapshot is dat je als commit wil importeren. Dan ga je in iedere subdirectory en print de noodzakelijke commando's om ze te exporteren. Je basis hoofdlus ziet er zo uit:
 
 	last_mark = nil
 
@@ -518,7 +517,7 @@ Om te beginnen ga je naar de doeldirectory en identificeert iedere subdirectory
 	  end
 	end
 
-Je voert `print_export` uit binnen iedere directory wat het manifest en het kenmerk van de vorige snapshot neemt, en het manifest en kenmerk van de huidige retourneert; op die manier kun je ze goed linken. "Mark" is de `fast-import` term voor een identificator die je aan een commit geeft; terwijl je commits maakt geef je ze een kenmerk ("Mark") die je kunt gebruiken om vanuit andere commits naar te linken. Dus, het eerste wat je moet doen in je `print_export` functie is een kenmerk genereren van de directortnaam:
+Je voert `print_export` uit binnen iedere directory, welke het manifest en het kenmerk van de vorige snapshot neemt, en het manifest en kenmerk van de huidige retourneert; op die manier kun je ze goed linken. "Mark" is de `fast-import` term voor een identificatie die je aan een commit geeft; terwijl je commits maakt geef je ze een kenmerk ("Mark") die je kunt gebruiken om vanuit andere commits naar te linken. Dus, het eerste wat je moet doen in je `print_export` functie is een kenmerk genereren van de directorynaam:
 
 	mark = convert_dir_to_mark(dir)
 
@@ -561,7 +560,7 @@ Nu ben je klaar om te beginnen met de commit data af te drukken voor je importee
 	export_data('imported from ' + dir)
 	puts 'from :' + last_mark if last_mark
 
-Je stelt de tijdzone (-0700) hardgecodeerd in omdat dat zo gemakkelijk is. Als je vanuit een ander systeem importeert, moet je de tijdzone als een compensatiewaarde (offset) specificeren.
+Je stelt de tijdzone (-0700) hardgecodeerd in omdat dat gemakkelijk is. Als je vanuit een ander systeem importeert, moet je de tijdzone als een compensatiewaarde (offset) specificeren.
 Het commit bericht moet uitgedrukt worden in een speciaal formaat:
 
 	data (size)\n(contents)
@@ -580,7 +579,7 @@ Het enige dat nog gespecificeerd moet worden is de bestandsinhoud voor ieder sna
 	  inline_data(file)
 	end
 
-Let op: Omdat veel systemen over hun revisie zien als veranderingen van de ene naar de andere commit, kan fast-import ook commando's aan waar bij iedere commit is gespecificeerd welke bestanden zijn toegevoegd, verwijderd, of aangepast en wat de nieuwe inhoud is. Je kunt de verschillen tussen snapshots berekenen en alleen deze data geven, maar om het zo te doen is complexer, Je kunt net zo goed Git alle data geven en hem het uit laten zoeken. Als dit beter geschikt is voor jouw situatie, bekijk dan de `fast-import` man pagina voor details over hoe je jouw gegevens op deze manier kunt aanleveren.
+Let op: Omdat veel systemen hun revisies zien als veranderingen van de ene naar de andere commit, kan fast-import ook commando's aan waar bij iedere commit is gespecificeerd welke bestanden zijn toegevoegd, verwijderd, of aangepast en wat de nieuwe inhoud is. Je kunt de verschillen tussen snapshots berekenen en alleen deze data geven, maar om het zo te doen is complexer, Je kunt net zo goed Git alle data geven en hem het uit laten zoeken. Als dit beter geschikt is voor jouw situatie, bekijk dan de `fast-import` man pagina voor details over hoe je jouw gegevens op deze manier kunt aanleveren.
 
 Het formaat om de nieuwe bestandsinhoud te tonen of een aangepast bestand met de nieuwe inhoud te specificeren is als volgt:
 
@@ -596,13 +595,13 @@ Hierbij is 644 de modus (als je uitvoerbare bestanden hebt, moet je dit detecter
 	  export_data(content)
 	end
 
-Je hergebruikt de `export_data` data functie die je eerder gedefinieerd hebt, omdat dezelfde manier gebruikt wordt als waarmee je de commit bericht data gespecificeerd hebt.
+Je hergebruikt de `export_data` data functie die je eerder gedefinieerd hebt, omdat dezelfde manier gebruikt wordt als waarme je de commit bericht data te specificeert.
 
 Het laatste wat je moet doen is het huidige kenmerk teruggeven, zodat het meegegeven kan worden aan de volgende iteratie:
 
 	return mark
 
-LET OP: Als je op Windows werkt moet je er zeker van zijn dat je nog één extra stap toevoegt. Zoals eerder gemeld is gebruikt Windows CRLF als new line karakters, terwijl git fast-import alleen LF verwacht. Om dit probleem te omzeilen en git fast-import blij te maken, moet je ruby vertellen om LF in plaats van CRLF te gebruiken:
+LET OP: Als je op Windows werkt moet je er zeker van zijn dat je nog één extra stap toevoegt. Zoals eerder gemeld is, gebruikt Windows CRLF als new line karakters, terwijl git fast-import alleen LF verwacht. Om dit probleem te omzeilen en git fast-import blij te maken, moet je ruby vertellen om LF in plaats van CRLF te gebruiken:
 
 	$stdout.binmode
 
@@ -631,7 +630,7 @@ Dat is alles. Als je dit script uitvoert, zal je inhoud krijgen die er ongeveer
 	new version one
 	(...)
 
-Om de importeerder uit te voeren, sluis je deze uitvoer door `git fast-import` terwijl je in de Git directory staat waar je naar toe wilt importeren. Je kunt een nieuwe directory aanmaken en er dan `git init` in uitvoeren als startpunt, en dan kun je het script uitvoeren:
+Om de importeerder uit te voeren, sluis (pipe) je deze uitvoer door `git fast-import` terwijl je in de Git directory staat waar je naar toe wilt importeren. Je kunt een nieuwe directory aanmaken en er dan `git init` in uitvoeren om een startpunt te maken, en dan kun je het script uitvoeren:
 
 	$ git init
 	Initialized empty Git repository in /opt/import_to/.git/
@@ -675,7 +674,7 @@ Zoals je kunt zien geeft het je een berg statistieken over wat het heeft bereikt
 
 	    imported from back_2009_02_03
 
-Hier heb je 't, een mooie, schone Git repository. Het is belangrijk om te op te merken dat nog niks uitgechecked is, je hebt om te beginnen geen bestanden in je werkdirectory. Om ze te krijgen moet je de branch resetten tot het punt waar `master` nu is:
+Hier heb je 't, een mooie, schone Git repository. Het is belangrijk om te op te merken dat nog niks uitgecheckt is, je hebt om te beginnen geen bestanden in je werkdirectory. Om ze te krijgen moet je de branch resetten tot het punt waar `master` nu is:
 
 	$ ls
 	$ git reset --hard master
@@ -687,4 +686,4 @@ Je kunt nog veel meer doen met het `fast-import` tool: verschillende bestandsmod
 
 ## Samenvatting ##
 
-Je zou je op je gemak moeten voelen om Git met Subversion te gebruiken, of bijna ieder bestaand repository te importeren in een Git versie zonder gegevens te verliezen. Het volgende hoofdstuk zal het ruwe binnenwerk van Git behandelen, zodat je iedere byte in elkaar kunt zetten, als dat nodig zou zijn.
+Je zou je op je gemak moeten voelen om Git met Subversion te gebruiken, of bijna ieder bestaand repository te importeren in een Git versie zonder gegevens te verliezen. Het volgende hoofdstuk zal het ruwe binnenwerk van Git behandelen, zodat je iedere byte kunt bewerken, als dat nodig zou zijn.

From e2028efdbbbadbb85fa85d769db7d692e3551339 Mon Sep 17 00:00:00 2001
From: Cor <git@cpt1.demon.nl>
Date: Mon, 24 Feb 2014 10:35:49 +0100
Subject: [PATCH 244/690] [nl] Chapter 09 - Review and retranslate where
 necessary.

---
 nl/09-git-internals/01-chapter9.markdown | 213 +++++++++++++----------
 1 file changed, 124 insertions(+), 89 deletions(-)

diff --git a/nl/09-git-internals/01-chapter9.markdown b/nl/09-git-internals/01-chapter9.markdown
index 7727ea3cf..d3aeb6daa 100644
--- a/nl/09-git-internals/01-chapter9.markdown
+++ b/nl/09-git-internals/01-chapter9.markdown
@@ -1,20 +1,55 @@
+<!-- Attentie heren en dames vertalers.
+Ik zou het volgende willen voorstellen:
+Er zijn bepaalde termen die voor de gemiddelde Nederlandse computer gebruiker 
+veel beter klinken (of bekender voorkomen) als de orginele Engelse term. In het
+begin zullen deze termen niet vaak voorkomen, maar in de meer diepgaandere 
+hoofdstukken komen deze steeds meer voor. Termen als "Committen", "Mergen" 
+en "Applyen" klinken beter dan "Plegen" of "Toepassen", "Samenvoegen" en 
+"Toepassen" (wat bovendien slecht valt te onderscheiden van de 
+commit-toepassing). De mensen die dit boek lezen zijn, naar mijn bescheiden 
+inschatting, al redelijk op de hoogte van versiebeheer en passen (zie ik in 
+de praktijk) deze termen al toe. Een nieuwe terminologie introduceren lijkt 
+me dan ook niet noodzakelijk.
+Verder blijven er altijd kreten over als "directory", wat vertaald zou kunnen 
+worden als "map", maar bij het Engelse werkwoord to map krijgen we dan weer het
+probleem: hoe dit weer te vertalen? Daarom zou ik willen voorstellen om deze 
+basis-termen toch onvertaald te laten.
+
+Twijfelgevallen zullen altijd blijven zoals de term "file", daarvan wordt in de
+praktijk zowel de term file als bestand gebruikt. Ik denk dat we hier moeten 
+kijken hoe het in de context past. 
+Maar ook een term als "tool" en (ik zit zelf nog op een mooie Nederlandse term
+te broeden) "plumbing", hierbij stel ik voor om eenmalig een Nederlandse 
+vertaling te geven, tussen haakjes de Engelse term te geven en in het vervolg
+de Engelse term te gebruiken. Wederom is de context hier belangrijk.
+
+Verder stel ik ook voor om de regels op https://onzetaal.nl/taaladvies zoveel
+mogelijk te volgen. Bijvoorbeeld de regels omtrent het spellen van Engelse 
+werkwoorden die in het Nederlands gebruikt worden.
+
+Let wel: ik wil niemand tot iets verplichten, maar ik denk dat we moeten 
+streven naar een zo duidelijk mogelijke en best bij de praktijk aansluitende
+vertaling moeten proberen te maken.
+
+Veel succes en plezier bij het vertalen...
+-->
 # Het binnenwerk van Git #
 
-Je zult misschien naar dit hoofdstuk gesprongen zijn vanuit een eerdere hoofdstuk, of je zult hier gekomen zijn nadat je de rest van het boek gelezen hebt; hoe dan ook zal hier het binnenwerk en implementatie van Git behandeld worden. Ik heb gemerkt dat het leren van deze informatie van fundamenteel belang is om te begrijpen hoe bruikbaar en krachtig Git is, maar anderen hebben daar tegenin gebracht dat het erg verwarrend en onnodig complex kan zijn voor beginners. Daarom heb ik deze beschrijving het laatste hoofdstuk gemaakt in het boek, zodat je het vroeg of later in je leerproces kunt lezen. Ik laat het aan jou over om dat te beslissen.
+Je zult misschien naar dit hoofdstuk gesprongen zijn vanuit een voorafgaand hoofdstuk, of je zult hier gekomen zijn nadat je de rest van het boek gelezen hebt; hoe dan ook, hier is waar het binnenwerk en implementatie van Git behandeld gaat worden. Ik heb gemerkt dat het leren van deze informatie van fundamenteel belang is om te begrijpen hoe bruikbaar en krachtig Git is, maar anderen hebben daar tegenin gebracht dat het erg verwarrend en onnodig complex kan zijn voor beginners. Daarom heb ik de behandeling hiervan het laatste hoofdstuk gemaakt in het boek, zodat je kunt besluiten om het het vroeg of later in je leerproces kunt lezen. Ik laat het aan jou over om dat te beslissen.
 
-Nu je hier bent, laten we beginnen. Ten eerste, mocht het nog niet duidelijk zijn, is Git eigenlijk een inhouds-adresseerbaar bestandssysteem met een gebruikersinterface voor versiebeheer er bovenop geschreven. Je zult over een poosje meer leren over wat dit betekent.
+Maar, nu je hier bent, laten we beginnen. Ten eerste, mocht het nog niet duidelijk zijn geworden, Git is eigenlijk een inhouds-adresseerbaar bestandssysteem met een gebruikersinterface voor versiebeheer er bovenop geschreven. Je zult over een poosje meer leren wat dit inhoudt.
 
-In de eerste dagen van Git (het merendeel pre 1.5), was de gebruikersinterface veel complexer, omdat het de nadruk legde op dit bestandssysteem in plaats van op een gepolijst VCS. De laatste paar jaren is de interface verfijnd totdat het zo netjes en eenvoudig te gebruiken is als een willekeurig ander systeem; maar vaak blijft het stereotype hangen van de vroegere Gitinterface die complex was en moeilijk te leren.
+In de eerste dagen van Git (voornamelijk pre 1.5), was de gebruikersinterface veel complexer, omdat de nadruk lag op dit bestandssysteem aspect in plaats van een gepolijste VCS. De laatste paar jaren is de interface verfijnd totdat het zo netjes en eenvoudig te gebruiken is als een willekeurig ander systeem; maar vaak blijft het stereotype hangen van de vroegere Gitinterface die complex was en moeilijk te leren.
 
-Deze laag met het inhouds-toegankelijke bestandssysteem is ongelofelijk gaaf, dus dat behandel ik dat als eerste dit hoofdstuk; daarna leer je over de transportmechanismen en het onderhouden van je repository's, iets waar je uiteindelijk mee te maken kunt krijgen.
+Deze laag met het inhouds-toegankelijke bestandssysteem is ongelofelijk gaaf, dus dat behandel ik dat als eerste dit hoofdstuk; daarna leer je over de transportmechanismen en het onderhoudentaken van repository's, iets waar je uiteindelijk mee te maken kunt krijgen.
 
 ## Sanitaire voorzieningen en porselein ##
 
 In dit boek wordt Git met ongeveer 30 werkwoorden zoals `checkout`, `branch`, `remote` enzovoorts behandeld. Maar omdat Git in eerste instantie een toolkit voor een VCS was, in plaats van een volledig gebruiksvriendelijk VCS, heeft het een berg werkwoorden die laag-bij-de-gronds werk doen en ontworpen waren om gebruikt te worden zoals in UNIX gebruikelijk is, of vanuit scripts aangeroepen te worden. Naar deze commando's wordt over het algemeen als "plumbing" (sanitaire voorzieningen) commando's gerefereerd, en de meer gebruiksvriendelijke commando's worden "porcelain" (porselein) commando's genoemd.
 
-De eerste acht hoofdstukken van het boek behandelen bijna alleen porselein commando's. Maar in dit hoofdstuk zul je het meest op het laagste niveau van de plumbing commando's om te gaan. Zij geven je toegang tot het binnenwerk van Git, en laten zien hoe en waarom Git doet wat het doet. Deze commando's zijn niet bedoeld voor normaal gebruik op de commandoregel, maar meer om als bouwstenen voor nieuwe tools en scripts gebruikt te worden.
+In de eerste acht hoofdstukken van het boek worden bijna alleen de porcelain commando's behandeld. Maar in dit hoofdstuk zal je het meest met het laagste niveau van de plumbing commando's te maken gaan krijgen. Zij geven je toegang tot het binnenwerk van Git, en laten zien hoe en waarom Git doet wat het doet. Deze commando's zijn niet bedoeld voor normaal gebruik op de commandoregel, maar meer om als bouwstenen voor nieuwe tools en zelfgemaakte scripts gebruikt te worden.
 
-Als je `git init` uitvoert in een nieuwe of bestaande directory, zal Git de directory `.git` aanmaken, wat de plek is waar bijna alles is wordt bewaard wat Git opslaat en manipuleert. Als je een backup of kopie van je repository wilt maken, dan hoef je alleen maar die directory te kopiëren, en je hebt bijna alles wat je nodig hebt. Dit hele hoofdstuk gaat in essentie over de inhoud van deze directory. Hier zie je hoe het eruit ziet:
+Als je `git init` uitvoert in een nieuwe of bestaande directory, zal Git de directory `.git` aanmaken, wat de plaats is waar bijna alles wordt bewaard wat Git opslaat en manipuleert. Als je een backup of kopie van je repository wilt maken, dan hoef je alleen maar die directory te kopiëren, en je hebt bijna alles wat je nodig hebt. Dit hele hoofdstuk gaat in essentie over de inhoud van deze directory. Hier zie je hoe het eruit ziet:
 
 	$ ls
 	HEAD
@@ -27,14 +62,14 @@ Als je `git init` uitvoert in een nieuwe of bestaande directory, zal Git de dire
 	objects/
 	refs/
 
-Je kunt een paar andere bestanden zien, maar dit is een verse `git init` repository; dit is wat je standaard ziet. De `branches` directory wordt niet gebruikt door nieuwere Git versies, en het `description` bestand wordt alleen gebruikt door het programma GitWeb, dus je hoeft je daar geen zorgen over te maken. Het bestand `config` bevat je project-specifieke configuratieopties, en de `info` directory bevat een bestand met bestandsnaampatronen die je niet wilt volgen, maar niet wilt opnemen in een .gitignore bestand. De directory `hooks` bevat scripts die aan bepaalde acties zijn “gehaakt” aan client- en serverkant, die in detail beschreven zijn in Hoofdstuk 7.
+Je zou hier een paar andere bestanden kunnen zien, maar dit is een verse `git init` repository - dit is wat je standaard ziet. De `branches` directory wordt niet gebruikt door nieuwere Git versies, en het `description` bestand wordt alleen gebruikt door het programma GitWeb, dus je hoeft je daar geen zorgen over te maken. Het bestand `config` bevat je project-specifieke configuratieopties, en de `info` directory bevat een bestand met bestandsnaampatronen die je niet wilt volgen, maar die je niet wilt opnemen in een .gitignore bestand. De directory `hooks` bevat scripts die aan bepaalde acties zijn “gehaakt” aan client- en serverkant, deze zijn in detail behandeld in Hoofdstuk 7.
 
-Dit laat vier belangrijke vermeldingen over: de bestanden `HEAD` en `index`, en de directories `objects` en `refs`. Dit zijn de kernbestandsdelen van Git. De directory `objects` bevat alle inhoud van je databank, de directory `refs` bevat verwijzingen naar commitobjecten (branches) in die databank, het bestand `HEAD` wijst naar de branch die je op dit moment uitgechecked hebt, en het bestand `index` is waar Git de informatie van je wachtrij (staging area) opslaat. Je gaat nu in detail naar elk van deze onderdelen kijken om te zien hoe Git werkt.
+Dit laat vier belangrijke vermeldingen over: de bestanden `HEAD` en `index`, en de directories `objects` en `refs`. Dit zijn de kernbestanddelen van Git. De directory `objects` bevat alle inhoud van je databank, de directory `refs` bevat verwijzingen naar commitobjecten (branches) in die databank, het bestand `HEAD` wijst naar de branch die je op dit moment uitgecheckt hebt, en het bestand `index` is waar Git de informatie van je staging area (wachtrij) opslaat. We gaan nu gedetaileerd naar elk van deze onderdelen kijken om te laten zien hoe Git werkt.
 
 ## Git objecten ##
 
 Git is een inhouds-adresseerbaar bestandssysteem. Mooi. Wat betekent dat?
-Het betekent dat in de kern van Git een eenvoudige sleutel-waarde gegevensopslag zit. Je kunt er elk soort inhoud in stoppen, en het zal je een sleutel geven die je kunt gebruiken om de inhoud op ieder moment terug te krijgen. Om te demonstreren kan je het plumbing commando `hash-object` gebruiken die wat gegevens aanneemt, het in je `.git` directory opslaat, en je de sleutel teruggeeft waarmee de gegevens zijn opgeslagen. Als eerste initialiseer je een nieuw Git repository en verifieer je dat er niets in de `objects` directory staat:
+Het betekent dat in de kern Git een eenvoudige sleutel-waarde gegevensopslagsysteem is. Je kunt er elk vorm van inhoud in stoppen, en het zal je een sleutel teruggeven die je kunt gebruiken om de inhoud op ieder moment terug te krijgen. Om te demonstreren kan je het plumbing commando `hash-object` gebruiken die wat gegevens aanneemt, het in je `.git` directory opslaat, en je de sleutel teruggeeft waarmee de gegevens zijn opgeslagen. Als eerste initialiseer je een nieuw Git repository en verifieer je dat er niets in de `objects` directory staat:
 
 	$ mkdir test
 	$ cd test
@@ -47,17 +82,17 @@ Het betekent dat in de kern van Git een eenvoudige sleutel-waarde gegevensopslag
 	$ find .git/objects -type f
 	$
 
-Git heeft de `objects` directory geïnitialiseerd en de `pack` en `info` subdirectories erin aangemaakt, maar er zijn geen reguliere bestanden. Nu sla je wat tekst in je Git databank op:
+Git heeft de `objects` directory geïnitialiseerd en de `pack` en `info` subdirectories erin aangemaakt, maar er zijn geen reguliere bestanden aanwezig. Nu sla je wat tekst in je Git databank op:
 
 	$ echo 'test content' | git hash-object -w --stdin
 	d670460b4b4aece5915caf5c68d12f560a9fe3e4
 
-De `-w` vertelt `hash-object` dat het object opgeslagen moet worden; anders zal het commando je alleen vertellen wat de sleutel zou zijn. Met `--stdin` vertel je het commando dat het de inhoud moet lezen van stdin; als je dit niet specificeert verwacht `hash-object` een pad naar een bestand. De uitvoer van het commando is een hash checksum van 40 karakters. Dit is de SHA-1 hash: een checksum van de inhoud die je opslaat plus een kop, waarover je zo meteen meer zult leren. Nu kun je zien hoe Git je gegevens opgeslagen heeft:
+De `-w` vertelt `hash-object` dat het object opgeslagen moet worden; anders zal het commando je alleen vertellen wat de sleutel zou zijn geweest. Met `--stdin` vertel je het commando dat het de inhoud moet lezen van stdin; als je dit niet specificeert verwacht `hash-object` een pad naar een bestand. De uitvoer van het commando is een hash checksum van 40 karakters. Dit is de SHA-1 hash: een checksum van de inhoud die je opslaat plus een kop, waarover je straks meer zult leren. Nu kun je zien hoe Git je gegevens opgeslagen heeft:
 
 	$ find .git/objects -type f
 	.git/objects/d6/70460b4b4aece5915caf5c68d12f560a9fe3e4
 
-Je kunt een bestand in de `objects` directory zien. Dit is hoe Git de inhoud initieel opslaat: als een enkel bestand per stuk inhoud, vernoemd naar de SHA-1 checksum van de inhoud en z'n kop. De subdirectory is vernoemd naar de eerste 2 karakters van de SHA, en de bestandsnaam is de overige 38 karakters.
+Je kunt een bestand in de `objects` directory zien. Dit is hoe Git de inhoud initieel opslaat - als een enkel bestand per stuk inhoud, vernoemd met de SHA-1 checksum van de inhoud en z'n kop. De subdirectory is vernoemd naar de eerste 2 karakters van de SHA, en de bestandsnaam is de overige 38 karakters.
 
 Je kunt de inhoud terug uit Git halen met het `cat-file` commando. Dit commando is een soort Zwitsers zakmes om Git objecten mee te inspecteren. Door de `-p` optie mee te geven, instrueer je het `cat-file` commando om uit te zoeken wat het type van de inhoud is en om het netjes aan je te tonen:
 
@@ -83,7 +118,7 @@ Je databank bevat de twee nieuwe versies van het bestand, samen met de eerste in
 	.git/objects/83/baae61804e65cc73a7201a7252750c76066a30
 	.git/objects/d6/70460b4b4aece5915caf5c68d12f560a9fe3e4
 
-Nu kun je het bestand terugbrengen naar de eerste versie
+Nu kun je het bestand terugdraaien naar de eerste versie
 
 	$ git cat-file -p 83baae61804e65cc73a7201a7252750c76066a30 > test.txt
 	$ cat test.txt
@@ -95,14 +130,14 @@ of de tweede versie:
 	$ cat test.txt
 	version 2
 
-Maar de SHA-1 sleutel voor iedere versie van je bestand onthouden is niet erg praktisch; plus je bewaart de bestandsnaam niet in je systeem, alleen de inhoud. Dit objecttype heet een blob. Je kunt Git het objecttype van ieder object in Git laten vertellen, gegeven de SHA-1 sleutel, met `cat-file -t`:
+Maar de SHA-1 sleutel voor iedere versie van je bestand onthouden is niet erg praktisch; daarbij bewaar je de bestandsnaam niet in je systeem, alleen de inhoud. Dit objecttype heet een blob. Je kunt Git het objecttype van ieder object in Git laten vertellen, gegeven de SHA-1 sleutel, met `cat-file -t`:
 
 	$ git cat-file -t 1f7a7a472abf3dd9643fd615f6da379c4acb3e3a
 	blob
 
-### Boom (tree) objecten ###
+### Tree (boom) objecten ###
 
-Het volgende type waar je naar gaat kijken is het tree object, wat het probleem van het opslaan van de bestandsnaam oplost en het ook mogelijk maakt om een groep bestanden gezamenlijk op te slaan. Git bewaart inhoud op vergelijkbare wijze als een UNIX bestandssysteem, maar dan wat vereenvoudigd. Alle inhoud wordt opgeslagen als tree- en blob-objecten, waarbij trees corresponderen met UNIX directory vermeldingen en blobs min of meer corresponderen aan inodes of bestandsinhoud. Een enkel treeobject bevat één of meer tree vermeldingen, waarvan ieder een SHA-1 pointer naar een blob of subtree bevat met zijn geassocieerde mode, type en bestandsnaam. Bijvoorbeeld, de meest recente tree in het simplegit project zou er zo uit kunnen zien:
+Het volgende type waar je naar gaat kijken is het tree object, wat het probleem van het opslaan van de bestandsnaam oplost en het ook mogelijk maakt om een groep bestanden bij elkaar op te slaan. Git bewaart inhoud op vergelijkbare wijze als een UNIX bestandssysteem, maar dan wat vereenvoudigd. Alle inhoud wordt opgeslagen als tree- en blob-objecten, waarbij trees corresponderen met UNIX directory vermeldingen en blobs min of meer corresponderen met inodes of bestandsinhoud. Een enkel treeobject bevat één of meer tree vermeldingen, waarvan ieder een SHA-1 pointer naar een blob of subtree bevat met zijn geassocieerde mode, type en bestandsnaam. Bijvoorbeeld, de meest recente tree in het simplegit project zou er zo uit kunnen zien:
 
 	$ git cat-file -p master^{tree}
 	100644 blob a906cb2a4a904a152e80877d4088654daad0c859      README
@@ -119,7 +154,7 @@ Conceptueel zijn de gegevens die Git opslaat zoiets als in Figuur 9-1.
 Insert 18333fig0901.png
 Figuur 9-1. Eenvoudige versie van het Git data model.
 
-Je kunt je eigen tree maken. Normaal gesproken maakt Git een tree door de status van je staging gebied of index te pakken en daar een tree object mee te schrijven. Dus, om een treeobject te maken moet je eerst een index opzetten door een paar bestanden te stagen. Om een index te maken met een enkele vermelding, de eerste versie van je test.txt bestand, kun je het plumbing commando `update-index` gebruiken. Je gebruikt dit commando om kunstmatig de eerdere versie van het test.txt bestand toe te voegen aan een nieuw staging gebied. Je moet het de `--add` optie meegeven omdat het bestand nog niet bestaat in je staging gebied (je hebt zelfs nog geen staging gebied ingesteld) en `--cacheinfo` omdat het bestand dat je toevoegt niet in je directory staat maar in je databank. Daarna specificeer je de modus, SHA-1 en bestandsnaam:
+Je kunt je eigen tree maken. Normaal gesproken maakt Git een tree door de status van je staging area of index te pakken en daar een tree object mee te schrijven. Dus, om een treeobject te maken moet je eerst een index opzetten door een paar bestanden te stagen. Om een index te maken met een enkele vermelding - de eerste versie van je test.txt bestand - kun je het plumbing commando `update-index` gebruiken. Je gebruikt dit commando om kunstmatig de eerdere versie van het test.txt bestand toe te voegen aan een nieuwe staging area. Je moet het de `--add` optie meegeven omdat het bestand nog niet bestaat in je staging area (je hebt zelfs nog geen staging area ingesteld) en `--cacheinfo` omdat het bestand dat je toevoegt niet in je directory staat maar in je databank. Daarna specificeer je de modus, SHA-1 en bestandsnaam:
 
 	$ git update-index --add --cacheinfo 100644 \
 	  83baae61804e65cc73a7201a7252750c76066a30 test.txt
@@ -162,14 +197,14 @@ Merk op dat deze tree beide bestandsvermeldingen bevat en ook dat de SHA van tes
 	100644 blob fa49b077972391ad58037050f2a75f74e3671e92      new.txt
 	100644 blob 1f7a7a472abf3dd9643fd615f6da379c4acb3e3a      test.txt
 
-Als je een werkdirectory zou maken van de nieuwe tree die je zojuist geschreven hebt, zou je de twee bestanden in het hoogste niveau van de werkdirectory krijgen en een subdirectory genaamd `bak` die de eerste versie van het test.txt bestand bevat. Je kunt de gegevens die Git bevat voor deze structuren zien zoals getoond in Figuur 9-2.
+Als je een werkdirectory zou hebben gemaakt van de nieuwe tree die je zojuist geschreven hebt, zou je de twee bestanden in het hoogste niveau van de werkdirectory krijgen en een subdirectory genaamd `bak` die de eerste versie van het test.txt bestand bevat. Je kunt de gegevens die Git bevat voor deze structuren zien zoals getoond in Figuur 9-2.
 
 Insert 18333fig0902.png
 Figuur 9-2. De inhoud structuur van je huidige Git gegevens.
 
 ### Commit objecten ###
 
-Je hebt drie trees die de verschillende snapshots specificeren die je wilt volgen, maar het eerdere probleem blijft: je moet alledrie SHA-1 waarden onthouden om de snapshots weer op te halen. Je hebt ook geen informatie over wie de snapshots opgeslagen heeft, wanneer ze opgeslagen zijn of waarom ze opgeslagen zijn. Dit is de basale informatie die het commit object voor je bevat.
+Je hebt drie trees die de verschillende snapshots weergeven die je wilt tracken, maar het eerdere probleem blijft: je moet alledrie SHA-1 waarden onthouden om de snapshots weer op te halen. Je hebt ook geen informatie over wie de snapshots opgeslagen heeft, wanneer ze opgeslagen zijn of waarom ze opgeslagen zijn. Dit is de basis informatie die het commit object voor je bevat.
 
 Om een commit object te creëren moet je `commit-tree` aanroepen en één tree SHA-1 specificeren en welke commit objecten, als er die zijn, er direct aan vooraf gingen. Begin met de eerste tree die je geschreven hebt:
 
@@ -185,16 +220,16 @@ Nu kun je je nieuwe commit object bekijken met `cat-file`:
 
 	first commit
 
-Het formaat van een commit object is simpel: het specificeert de hoogste tree voor de snapshot van het project op dat punt, de auteur/committer informatie die uit de `user.name` en `user.email` configuratie instellingen gehaald is, met de huidige tijd, een lege regel en dan de commit boodschap.
+Het formaat van een commit object is simpel: het specificeert de hoogste tree voor de snapshot van het project op dat punt: de auteur/committer informatie die uit de `user.name` en `user.email` configuratie instellingen gehaald is, met de huidige tijd, een lege regel en dan de commit boodschap.
 
-Nu ga je de twee andere commit objecten schrijven, waarbij ze elk naar het commit object dat er direct voor komt verwijzen:
+Vervolgens ga je de twee andere commit objecten schrijven, waarbij ze elk naar het commit object dat er direct aan vooraf gaat verwijzen:
 
 	$ echo 'second commit' | git commit-tree 0155eb -p fdf4fc3
 	cac0cab538b970a37ea1e769cbbde608743bc96d
 	$ echo 'third commit'  | git commit-tree 3c4e9c -p cac0cab
 	1a410efbd13591db07496601ebc7a059dd55cfe9
 
-Ieder van de drie commit objecten wijst naar één van de drie snapshots die je gemaakt hebt. Grappig genoeg heb je nu een echte Git historie die je kunt bekijken met het `git log` commando, als je dat op de SHA-1 van de laatste commit uitvoert:
+Elk van de drie commit objecten wijst naar één van de drie snapshots die je gemaakt hebt. Grappig genoeg heb je nu een echte Git historie die je kunt bekijken met het `git log` commando, als je dat op de SHA-1 van de laatste commit uitvoert:
 
 	$ git log --stat 1a410e
 	commit 1a410efbd13591db07496601ebc7a059dd55cfe9
@@ -225,7 +260,7 @@ Ieder van de drie commit objecten wijst naar één van de drie snapshots die je
 	 test.txt |    1 +
 	 1 files changed, 1 insertions(+), 0 deletions(-)
 
-Verbazingwekkend. Je hebt zojuist de lagere operaties uitgevoerd om een Git history op te bouwen, zonder één van de front ends te gebruiken. Dit is in essentie wat Git doet als je de `git add` en `git commit` commando's uitvoert: het slaat de blobs voor de gewijzigde bestanden op, ververst de index, schrijft de trees weg, en schrijft commit objecten die de bovenste trees en commits refereren die vlak voor ze kwamen. Deze drie hoofd Git-objecten – de blob, de tree en de commit – worden in eerste instantie als aparte bestanden opgeslagen in je `.git/objects` directory. Hier zijn alle objecten die nu in de voorbeeld directory staan, voorzien van commentaar met wat ze bevatten:
+Verbazingwekkend. Je hebt zojuist de lagere operaties uitgevoerd om een Git history op te bouwen, zonder één van de front ends te gebruiken. Dit is in essentie wat Git doet als je de `git add` en `git commit` commando's uitvoert: het slaat de blobs voor de gewijzigde bestanden op, ververst de index, schrijft de trees weg, en schrijft commit objecten die de bovenste trees en commits refereren die direct voor ze kwamen. Deze drie hoofd Git-objecten – de blob, de tree en de commit – worden in eerste instantie als aparte bestanden opgeslagen in je `.git/objects` directory. Hier zijn alle objecten die nu in de voorbeeld directory staan, voorzien van commentaar met wat ze bevatten:
 
 	$ find .git/objects -type f
 	.git/objects/01/55eb4229851634a0f03eb265b69f5a2d56f341 # tree 2
@@ -246,7 +281,7 @@ Figuur 9-3. Alle objecten in je Git directory.
 
 ### Object opslag ###
 
-Ik vertelde eerder dat er een kop wordt opgeslagen bij de inhoud. Laten we eens even kijken naar hoe Git zijn objecten opslaat. Je zult zien hoe je interactief een blob object opslaat, in dit geval de tekst "what is up, doc?", in de Ruby scripttaal. Je kunt de interactieve Ruby modus starten met het `irb` commando:
+Ik vertelde eerder dat er een kop wordt opgeslagen bij de inhoud. Laten we eens kijken naar hoe Git zijn objecten opslaat. Je zult zien hoe je een blob object opslaat, in dit geval de tekst "what is up, doc?", op een interactieve manier in de Ruby scripttaal. Je kunt Ruby in de interactieve modus starten met het `irb` commando:
 
 	$ irb
 	>> content = "what is up, doc?"
@@ -273,7 +308,7 @@ Git comprimeert de nieuwe inhoud met zlib, wat je in Ruby kunt doen met de zlib
 	>> zlib_content = Zlib::Deflate.deflate(store)
 	=> "x\234K\312\311OR04c(\317H,Q\310,V(-\320QH\311O\266\a\000_\034\a\235"
 
-Als laatste schrijf je de zlib-gecomprimeerde inhoud naar een object op de schijf. Je bepaalt het pad van het object dat je wilt wegschrijven (de eerste twee karakters van de SHA-1 waarde zijn de subdirectory naam, en de laatste 38 karakters zijn de bestandsnaam in die directory). In Ruby kun je de `FileUtils.mkdir_p()` functie gebruiken om de subdirectory aan te maken als hij nog niet bestaat. Daarna open je het bestand met `File.open()` en schrijft de eerder met zlib gecomprimeerde inhoud in het bestand met een aanroep van `write()` op het resulterende bestands-aangrijpingspunt (file handle).
+Als laatste schrijf je de zlib-gecomprimeerde inhoud naar een object op de schijf. Je bepaalt het pad van het object dat je wilt wegschrijven (de eerste twee karakters van de SHA-1 waarde zijn de subdirectory naam, en de laatste 38 karakters zijn de bestandsnaam in die directory). In Ruby kun je de `FileUtils.mkdir_p()` functie gebruiken om de subdirectory aan te maken als hij nog niet bestaat. Daarna open je het bestand met `File.open()` en schrijft de eerder met zlib gecomprimeerde inhoud in het bestand met een aanroep van `write()` op het resulterende file handle (bestands-aangrijpingspunt).
 
 	>> path = '.git/objects/' + sha1[0,2] + '/' + sha1[2,38]
 	=> ".git/objects/bd/9dbf5aae1a3862dd1526723246b20206e5fc37"
@@ -284,11 +319,11 @@ Als laatste schrijf je de zlib-gecomprimeerde inhoud naar een object op de schij
 	>> File.open(path, 'w') { |f| f.write zlib_content }
 	=> 32
 
-Dat is alles: je hebt nu een geldig Git blob object aangemaakt. Alle Git objecten zijn op dezelfde manier opgeslagen, alleen de types verschillen. In plaats van de tekst blob, zal de kop beginnen met commit of tree. En alhoewel de blob inhoud vrijwel alles kan zijn, hebben de commit en tree inhoud een zeer specifiek formaat.
+Dat is alles - je hebt nu een geldig Git blob object aangemaakt. Alle Git objecten zijn op dezelfde manier opgeslagen, alleen de types verschillen - in plaats van de tekst blob, zal de kop beginnen met commit of tree. En alhoewel de inhoud van een blob vrijwel alles kan zijn, is de inhoud van een commit en tree zeer specifiek geformatteerd.
 
 ## Git referenties ##
 
-Je kunt zoiets als `git log 1a410e` uitvoeren om door je hele geschiedenis te kijken, maar je moet nog steeds onthouden dat `1a410e` de laatste commit is om die geschiedenis te doorlopen en alle objecten te vinden. Je hebt een bestand nodig waarin je de SHA-1 waarde als een eenvoudige naam kunt opslaan, zodat je die als wijzer kunt gebruiken in plaats van de kale SHA-1 waarde.
+Je kunt zoiets als `git log 1a410e` uitvoeren om door je hele geschiedenis te kijken, maar je moet nog steeds onthouden dat `1a410e` de laatste commit is om die geschiedenis te kunnen doorlopen en alle objecten te vinden. Je hebt een bestand nodig waarin je de SHA-1 waarde als een eenvoudige naam kunt opslaan, zodat je die als wijzer kunt gebruiken in plaats van de kale SHA-1 waarde.
 
 In Git worden deze "referenties" of "refs" genoemd; je kunt de bestanden die de SHA-1 waarden bevatten vinden in de `.git/refs` directory. In het huidige project bevat deze directory geen bestanden, maar het bevat wel een eenvoudige structuur:
 
@@ -299,7 +334,7 @@ In Git worden deze "referenties" of "refs" genoemd; je kunt de bestanden die de
 	$ find .git/refs -type f
 	$
 
-Om een nieuwe referentie aan te maken,die je zal helpen herinneren waar je laatste commit is, kun je technisch zoiets eenvoudigs als dit doen:
+Om een nieuwe referentie aan te maken, die je zal helpen herinneren waar je laatste commit is, kun je technisch zoiets eenvoudigs als dit doen:
 
 	$ echo "1a410efbd13591db07496601ebc7a059dd55cfe9" > .git/refs/heads/master
 
@@ -314,7 +349,7 @@ Het wordt niet aangeraden om de referentie bestanden direct aan te passen. Git l
 
 	$ git update-ref refs/heads/master 1a410efbd13591db07496601ebc7a059dd55cfe9
 
-Dat is eigenlijk wat een branch in Git is: een eenvoudige wijzer of referentie naar de head van een stuk werk. Om een branch te maken terug bij de tweede commit, kun je dit doen:
+Dat is eigenlijk wat een branch in Git is: een eenvoudige wijzer of referentie naar de head van een bepaald stuk werk. Om een branch te maken terug bij de tweede commit, kun je dit doen:
 
 	$ git update-ref refs/heads/test cac0ca
 
@@ -329,16 +364,16 @@ Nu ziet je Git gegevensbank er conceptueel ongeveer uit zoals in Figuur 9-4.
 Insert 18333fig0904.png
 Figuur 9-4. Git directory objecten met branch head referenties erbij.
 
-Als je commando's zoals `git branch (branchnaam)` uitvoert, voert Git eigenlijk dat `update-ref` commando uit om de SHA-1 van de laatste commit van de branch waarop je zit toe te voegen aan welke referentie je ook wil maken.
+Als je commando's zoals `git branch (branchnaam)` uitvoert, voert Git eigenlijk dat `update-ref` commando uit om de SHA-1 van de laatste commit van de branch waarop je zit toe te voegen aan een door jou te benoemen nieuwe referentie.
 
 ### De HEAD ###
 
-De vraag is nu: als je `git branch (branchnaam)` uitvoert, hoe weet Git de SHA-1 van de laatste commit? Het antwoord is het HEAD bestand. Het HEAD bestand is een symbolische referentie naar de branch waar je momenteel op zit. Met symbolische referentie bedoel ik dat, in tegenstelling tot een normale referentie, het over het algemeen geen SHA-1 waarde bevat maar een verwijzing naar een andere referentie. Als je naar het bestand kijkt, zul je normaal gesproken zoiets als dit zien:
+De vraag is nu: als je `git branch (branchnaam)` uitvoert, hoe weet Git de SHA-1 van de laatste commit? Het antwoord is het HEAD bestand. Het HEAD bestand is een symbolische referentie naar de branch waar je momenteel op zit. Met symbolische referentie bedoel ik dat deze, in tegenstelling tot een normale referentie, over het algemeen geen SHA-1 waarde bevat maar een verwijzing naar een andere referentie. Als je naar het bestand kijkt, zal je normaal gesproken zoiets als dit zien:
 
 	$ cat .git/HEAD
 	ref: refs/heads/master
 
-Als je `git checkout test` uitvoert, zal Git het bestand vernieuwen zodat het er zo uit ziet:
+Als je `git checkout test` uitvoert, zal Git het bestand wijzigen zodat het er zo uit ziet:
 
 	$ cat .git/HEAD
 	ref: refs/heads/test
@@ -363,13 +398,13 @@ Je kunt geen symbolische referentie instellen die buiten de refs stijl valt:
 
 ### Tags ###
 
-We hebben zojuist de drie hoofdobject types van Git behandeld, maar er bestaat een vierde. Het tag object lijkt erg op een commit object: het bevat een tagger, een datum, een bericht en een pointer. Het grootste verschil is dat een tag object naar een commit wijst in plaats van een tree. Het is vergelijkbaar met een branch referentie, maar het beweegt nooit. Het zal altijd naar dezelfde commit wijzen, maar geeft het een vriendelijker naam.
+We hebben zojuist de drie hoofdobject types van Git behandeld, maar er bestaat een vierde. Het tag object lijkt erg op een commit object - het bevat een tagger, een datum, een bericht en een pointer. Het grootste verschil is dat een tag object naar een commit wijst in plaats van een tree. Het is vergelijkbaar met een branch referentie, maar het zal nooit verplaatst worden - het zal altijd naar dezelfde commit wijzen, maar geeft het een vriendelijker naam.
 
 Zoals besproken in hoofdstuk 2, zijn er twee soorten tags: beschreven en lichtgewicht. Je kunt een lichtgewicht tag maken door zoiets als dit uit te voeren:
 
 	$ git update-ref refs/tags/v1.0 cac0cab538b970a37ea1e769cbbde608743bc96d
 
-Dat is wat een lichtgewicht tag is: een branch die nooit beweegt. Een beschreven tag is echter ingewikkelder. Als je een beschreven tag aanmaakt, creëert Git een tag object en schrijft een referentie die daar naar wijst in plaats van direct naar de commit. Je kunt dit zien door een beschreven tag aan te maken (`-a` specificeert dat het een beschreven tag is):
+Dat is wat een lichtgewicht tag is - een branch die nooit beweegt. Een beschreven tag is echter ingewikkelder. Als je een beschreven tag aanmaakt, creëert Git een tag object en schrijft dan een referentie die daar naar wijst in plaats van direct naar de commit. Je kunt dit zien door een beschreven tag aan te maken (`-a` specificeert dat het een beschreven tag is):
 
 	$ git tag -a v1.1 1a410efbd13591db07496601ebc7a059dd55cfe9 –m 'test tag'
 
@@ -392,11 +427,11 @@ Merk op dat de object regel wijst naar de SHA-1 waarde die je getagged hebt. Mer
 
 	$ git cat-file blob junio-gpg-pub
 
-in de Git broncode. De Linux kernel heeft ook een non-commit-verwijzend tag object – het eerste tag object wijst naar de eerste tree van de import van de broncode.
+in de Git broncode. De Linux kernel heeft ook een non-commit-verwijzend tag object – het eerste tag object wijst naar de initiële tree van de import van de broncode.
 
 ### Remotes ###
 
-Het derde soort referentie dat je zult zien is een remote referentie. Als je een remote toevoegt en er naar pushed, slaat Git de laatste waarde van iedere branch op die je gepushed hebt naar die remote in de `refs/remotes` directory. Bijvoorbeeld, je kunt een remote genaamd `origin` toevoegen en je master branch hier naar pushen:
+Het derde soort referentie dat je zult zien is een remote referentie. Als je een remote toevoegt en er naar pusht, slaat Git de laatste waarde op die je gepusht hebt naar die remote voor iedere branch in de `refs/remotes` directory. Bijvoorbeeld, je kunt een remote genaamd `origin` toevoegen en je master branch hier naar pushen:
 
 	$ git remote add origin git@github.com:schacon/simplegit-progit.git
 	$ git push origin master
@@ -407,12 +442,12 @@ Het derde soort referentie dat je zult zien is een remote referentie. Als je een
 	To git@github.com:schacon/simplegit-progit.git
 	   a11bef0..ca82a6d  master -> master
 
-Daarna kun je zien wat de `master` branch op de `origin` remote was toen je voor 't laatst met de server communiceerde, door het `refs/remotes/origin/master`bestand te bekijken:
+Daarna kun je zien wat de `master` branch op de `origin` remote was toen je voor 't laatst met de server communiceerde, door het `refs/remotes/origin/master` bestand te bekijken:
 
 	$ cat .git/refs/remotes/origin/master
 	ca82a6dff817ec66f44342007202690a93763949
 
-Remote referenties verschillen hoofdzakelijk van branches (`refs/heads` referenties) in het feit dat ze niet uitgechecked kunnen worden. Git verplaatst ze als boekenleggers naar de laatste status van die branches op de servers.
+Remote referenties verschillen van branches (`refs/heads` referenties) voornamelijk in het feit dat ze niet uitgechecked kunnen worden. Git verplaatst ze als boekenleggers naar de laatste status van die branches op de servers.
 
 ## Packfiles ##
 
@@ -454,7 +489,7 @@ Dan controleer je hoe groot het object is op jouw schijf:
 	$ du -b .git/objects/9b/c1dc421dcd51b4ac296e3e5b6e2a99cf44391e
 	4102	.git/objects/9b/c1dc421dcd51b4ac296e3e5b6e2a99cf44391e
 
-Pas het bestand nu eens een beetje aan, en kijk wat er gebeurt:
+Pas dat bestand nu eens een beetje aan, en kijk wat er gebeurt:
 
 	$ echo '# testing' >> repo.rb
 	$ git commit -am 'modified repo a bit'
@@ -475,7 +510,7 @@ De blob is nu een andere blob, wat betekent dat, alhoewel je slechts een enkele
 
 Je hebt nu twee vrijwel identieke 12K grote objecten op je harde schijf. Zou het niet prettig zijn als Git één van de twee volledig op kon slaan, en het tweede object slechts als delta tussen die en de eerste?
 
-Dat kan dus. Het initiële formaat waarin Git objecten opslaat op de harde schijf wordt een los ('loose') object formaat genoemd. Maar, eens in de zoveel tijd pakt Git een aantal van die objecten samen in een enkel binair bestand wat een packfile genoemd wordt, om ruimte te besparen en efficiënter te zijn. Git doet dit als je teveel losse objecten rond hebt slingeren als je het `git gc` commando handmatig uitvoert, of als je naar een remote server pushed. Om te zien wat er gebeurt, kun je Git handmatig vragen om de objecten in te pakken met het `git gc` commando:
+Dat kan dus. Het initiële formaat waarin Git objecten opslaat op de harde schijf wordt een loose (losse) object formaat genoemd. Maar, eens in de zoveel tijd pakt Git een aantal van die objecten samen in een enkel binair bestand wat een packfile genoemd wordt, om ruimte te besparen en efficiënter te zijn. Git doet dit als je teveel loose objecten rond hebt slingeren, als je het `git gc` commando handmatig uitvoert, of als je naar een remote server pusht. Om te zien wat er gebeurt, kun je Git handmatig vragen om de objecten in te pakken met het `git gc` commando:
 
 	$ git gc
 	Counting objects: 17, done.
@@ -493,7 +528,7 @@ Als je in je objecten directory kijkt, zul je zien dat de meeste objecten verdwe
 	.git/objects/pack/pack-7a16e4488ae40c7d2bc56ea2bd43e25212a66c45.idx
 	.git/objects/pack/pack-7a16e4488ae40c7d2bc56ea2bd43e25212a66c45.pack
 
-De objecten die overgebleven zijn, zijn de blobs waarnaar geen enkel commit wijst; in dit geval zijn het de "what is up, doc?" en de "test content" voorbeeld-blobs die je eerder aangemaakt hebt. Omdat je ze nooit aan een commit toegevoegd hebt, worden ze beschouwd als rondslingerend ('dangling') en niet in je nieuwe packfile ingepakt.
+De objecten die overgebleven zijn, zijn de blobs waarnaar geen enkel commit wijst - in dit geval zijn het de "what is up, doc?" en de "test content" voorbeeld-blobs die je eerder aangemaakt hebt. Omdat je ze nooit aan een commit toegevoegd hebt, worden ze beschouwd als dangling (rondslingerend) en worden niet in je nieuwe packfile ingepakt.
 
 De andere bestanden zijn het nieuwe packbestand en een index. Het packbestand is een enkel bestand dat de inhoud bevat van alle objecten die van je bestandssysteem verwijderd zijn. De index is een bestand dat offsets binnen de packfile bevat, zodat je snel naar een specifiek object kunt zoeken. Wat stoer is, is dat waar de objecten op de harde schijf voordat je `gc` aanriep samen zo'n 8K groot waren, de nieuwe packfile slechts 4K groot is. Je hebt je schijfgebruik gehalveerd door je bestanden in te pakken.
 
@@ -522,14 +557,14 @@ Hoe doet Git dit? Als Git objecten inpakt, zoekt het naar bestanden die qua naam
 	chain length = 1: 1 object
 	pack-7a16e4488ae40c7d2bc56ea2bd43e25212a66c45.pack: ok
 
-Hier refereert de `9bc1d` blob wat, als je dat nog kunt herinneren, de eerste versie is van je repo.rb bestand, aan de `05408` blob, wat de tweede versie was van het bestand. De derde kolom in de uitvoer is de grootte van het object in het pakket, zodat je kunt zien dat `05408` 12K van het bestand in beslag neemt maar dat `9bc1d` slechts 7 bytes in beslag neemt. Wat ook interessant is, is dat de tweede versie van het bestand degene is die intact opgeslagen wordt, terwijl de originele versie als delta opgeslagen wordt. Dit is zo gedaan omdat het aannemelijk is dat je snellere toegang nodig hebt tot de meest recente versie van het bestand.
+Hier refereert de `9bc1d` blob wat, als je dat nog kunt herinneren, de eerste versie is van je repo.rb bestand, aan de `05408` blob, wat de tweede versie is van het bestand. De derde kolom in de uitvoer is de grootte van het object in het pakket, zodat je kunt zien dat `05408` 12K van het bestand in beslag neemt maar dat `9bc1d` slechts 7 bytes in beslag neemt. Wat ook interessant is, is dat de tweede versie van het bestand degene is die intact opgeslagen wordt, terwijl de originele versie als delta opgeslagen wordt - dit is zo gedaan omdat het aannemelijk is dat je snellere toegang nodig hebt tot de meest recente versie van het bestand.
 
-Het echt prettige van dit alles is, dat het op ieder gewenst moment opnieuw ingepakt kan worden. Git zal op gezette tijden je databank automatisch opnieuw inpakken, waarmee het altijd meer ruimte wil besparen. Je kunt ook handmatig opnieuw inpakken op elk gewenst tijdstip, door `git gc` met de hand uit te voeren.
+Het echt prettige van dit alles is, dat het op ieder gewenst moment opnieuw ingepakt kan worden. Git zal op gezette tijden je databank automatisch opnieuw inpakken, omdat het altijd meer ruimte wil besparen. Je kunt ook handmatig opnieuw inpakken op elk gewenst tijdstip, door `git gc` met de hand uit te voeren.
 
 ## De refspec ##
 
 Door dit boek heen heb je eenvoudige verwijzingen van remote branches naar lokale referenties gebruikt, maar ze kunnen ingewikkelder zijn.
-Stel dat je een remote zoals dit toevoegt:
+Stel dat je een remote als deze toevoegt:
 
 	$ git remote add origin git@github.com:schacon/simplegit-progit.git
 
@@ -539,9 +574,9 @@ Dit voegt een sectie toe aan je `.git/config` bestand, met de naam van de remote
 	       url = git@github.com:schacon/simplegit-progit.git
 	       fetch = +refs/heads/*:refs/remotes/origin/*
 
-Het formaat van de refspec is een optionele `+`, gevolgd door `<src>:<dst>`, waarbij `<src>` het patroon voor referenties aan de remote kant is, en `<dst>` is de locatie waar die referenties lokaal geschreven zullen worden. De `+` vertelt Git om de referentie zelfs te vernieuwen als het geen fast-forward is.
+Het formaat van de refspec is een optionele `+`, gevolgd door `<src>:<dst>`, waarbij `<src>` het patroon voor referenties aan de remote kant is, en `<dst>` de locatie is waar die referenties lokaal geschreven zullen worden. De `+` vertelt Git om de referentie zelfs te vernieuwen als het geen fast-forward is.
 
-In het standaard geval dat automatisch geschreven wordt door een `git remote add` commando, haalt Git alle referenties onder `refs/heads/` van de server op en schrijft ze lokaal naar `refs/remotes/origin/`. Dus als er een `master` branch op de server bestaat, kun je de log van die branch lokaal benaderen via
+In het standaard geval dat automatisch geschreven wordt door een `git remote add` commando, haalt Git alle referenties onder `refs/heads/` van de server op en schrijft ze lokaal naar `refs/remotes/origin/`. Dus als er een `master` branch op de server bestaat, kan je de log van die branch lokaal benaderen via
 
 	$ git log origin/master
 	$ git log remotes/origin/master
@@ -553,11 +588,11 @@ Als je wilt dat Git alleen de `master` branch pulled, en niet alle andere branch
 
 	fetch = +refs/heads/master:refs/remotes/origin/master
 
-Dit is alleen de standaard refspec voor `git fetch` voor die remote. Als je iets echt eenmalig wilt doen, kun je de refspec ook op de commandoregel specificeren. Om de `master` branch op de remote naar de lokale `origin/mymaster` te pullen, kun je dit uitvoeren
+Dit is alleen de standaard refspec voor `git fetch` voor die remote. Als je iets eenmalig wilt doen, kan je de refspec ook op de commandoregel specificeren. Om de `master` branch op de remote naar de lokale `origin/mymaster` te pullen, kun je dit uitvoeren
 
 	$ git fetch origin master:refs/remotes/origin/mymaster
 
-Je kunt ook meerdere refspecs specificeren. Met de commandoregel kun je meerdere branches op deze manier pullen:
+Je kunt ook meerdere refspecs specificeren. Met de commandoregel kan je meerdere branches op deze manier pullen:
 
 	$ git fetch origin master:refs/remotes/origin/mymaster \
 	   topic:refs/remotes/origin/topic
@@ -578,14 +613,14 @@ Je kunt geen gedeeltelijke globs in het patroon gebruiken, dus het volgende zou
 
 	fetch = +refs/heads/qa*:refs/remotes/origin/qa*
 
-Maar je kunt wel naamruimtes ('namespaces') gebruiken om zoiets voor elkaar te krijgen. Als je een QA team hebt dat naar een serie branches pushed, en je wilt de master branch en alle QA team branches hebben, maar niets anders, kun je een configuratie sectie zoals dit gebruiken:
+Maar je kunt wel namespaces (naamruimtes) gebruiken om zoiets voor elkaar te krijgen. Als je een QA team hebt dat naar een bepaalde reeks branches pusht, en je wilt de master branch en alle QA team branches hebben, maar niets anders, kun je een configuratie sectie zoals dit gebruiken:
 
 	[remote "origin"]
 	       url = git@github.com:schacon/simplegit-progit.git
 	       fetch = +refs/heads/master:refs/remotes/origin/master
 	       fetch = +refs/heads/qa/*:refs/remotes/origin/qa/*
 
-Als je een ingewikkelde workflow hebt waarbij het QA team branches pushed, ontwikkelaars branches pushen, en integratie teams op remote branches pushen en samenwerken, kun je ze op deze manier eenvoudig in namespaces onderverdelen.
+Als je een ingewikkelde workflow hebt waarbij het QA team branches pusht, ontwikkelaars branches pushen, en integratie teams op remote branches pushen en samenwerken, kun je ze op deze manier eenvoudig in namespaces onderverdelen.
 
 ### Refspecs pushen ###
 
@@ -595,7 +630,7 @@ Als het QA team hun `master` branch naar `qa/master` op de remote server wil pus
 
 	$ git push origin master:refs/heads/qa/master
 
-Als ze willen dat Git dat automatisch doet iedere keer als ze `git push origin` uitvoeren, dan kunnen ze een push waarde aan hun configuratie bestand toevoegen:
+Als ze willen dat Git dat automatisch doet iedere keer als ze `git push origin` uitvoeren, dan kunnen ze een `push` waarde aan hun configuratie bestand toevoegen:
 
 	[remote "origin"]
 	       url = git@github.com:schacon/simplegit-progit.git
@@ -610,11 +645,11 @@ Je kunt de refspec ook gebruiken om referenties te verwijderen van de remote ser
 
 	$ git push origin :topic
 
-Omdat de refspec `<src>:<dst>` is wordt, door het weglaten van het `<src>` gedeelte, in feite verteld dat de onderwerp branch op de remote niets is, waardoor het verwijderd wordt.
+Omdat de refspec `<src>:<dst>` is, wordt door het weglaten van het `<src>` gedeelte in feite verteld dat de onderwerp branch op de remote niets is, waardoor het verwijderd wordt.
 
 ## Overdracht protocollen ##
 
-Git draagt gegevens tussen twee repositories hoofdzakelijk op twee manieren over: via HTTP en via de zogenaamde slimme protocollen die in de `file://`, `ssh://` en `git://` overdrachten gebruikt worden. Deze paragraaf zal laten zien hoe deze hoofdprotocollen werken.
+Git kan gegevens tussen twee repositories hoofdzakelijk op twee manieren overdragen: via HTTP en via de zogenaamde slimme protocollen die in de `file://`, `ssh://` en `git://` overdrachten gebruikt worden. Deze paragraaf zal laten zien hoe deze twee hoofdprotocollen werken.
 
 ### Het domme Protocol ###
 
@@ -622,7 +657,7 @@ Naar Git-overdracht via HTTP wordt vaak gerefereerd als het domme protocol, omda
 
 	$ git clone http://github.com/schacon/simplegit-progit.git
 
-Het eerste wat dit commando doet is het `info/refs` bestand pullen. Dit bestand wordt geschreven door het `update-server-info` commando, en dat is de reden waarom je dat als een `post-recieve` hook in moet stellen voordat de HTTP overdracht naar behoren werkt:
+Het eerste wat dit commando doet is het `info/refs` bestand pullen. Dit bestand wordt geschreven door het `update-server-info` commando, en dat is de reden waarom je dat als een `post-recieve` hook moet activeren voordat de HTTP overdracht naar behoren werkt:
 
 	=> GET info/refs
 	ca82a6dff817ec66f44342007202690a93763949     refs/heads/master
@@ -633,12 +668,12 @@ Nu heb je een lijst met de remote referenties en SHA's. Daarna kijk je naar de w
 	ref: refs/heads/master
 
 Je moet de `master` branch uitchecken zodra je het proces afgerond hebt.
-Op dit punt ben je klaar om het proces doorlopen te starten. Omdat je startpunt het `ca82a6` commit object is dat je in het `info/refs` bestand zag, begin je met dit op te halen:
+Op dit punt kan je beginnen met het doorloop proces. Omdat je startpunt het `ca82a6` commit object is dat je in het `info/refs` bestand zag, begin je met dit op te halen:
 
 	=> GET objects/ca/82a6dff817ec66f44342007202690a93763949
 	(179 bytes of binary data)
 
-Je krijgt een object terug, dat object staat in los formaat op de server, en je hebt het gehaald met een statisch HTTP GET verzoek. Je kunt het met zlib decomprimeren, de kop eraf halen en naar de commit inhoud kijken:
+Je krijgt een object terug - dat object staat in los formaat op de server, en je hebt het gehaald met een statisch HTTP GET verzoek. Je kunt het met zlib decomprimeren, de kop eraf halen en naar de commit inhoud kijken:
 
 	$ git cat-file -p ca82a6dff817ec66f44342007202690a93763949
 	tree cfda3bf379e4f8dba8717dee55aab78aef7f4daf
@@ -648,7 +683,7 @@ Je krijgt een object terug, dat object staat in los formaat op de server, en je
 
 	changed the version number
 
-Daarna heb je nog twee objecten op te halen: `cfda3b`, wat de tree is met inhoud waar de commit die je zojuist hebt opgehaald naar wijst, en `085bb3`, wat de ouder commit is:
+Daarna heb je nog twee objecten op te halen - `cfda3b`, wat de tree is met inhoud waar de commit die je zojuist hebt opgehaald naar wijst, en `085bb3`, wat de ouder commit is:
 
 	=> GET objects/08/5bb3bcb608e1e8451d4b2432f8ecbe6306e7e7
 	(179 bytes of data)
@@ -658,22 +693,22 @@ Dat geeft je het volgende commit object. Pak het tree object:
 	=> GET objects/cf/da3bf379e4f8dba8717dee55aab78aef7f4daf
 	(404 - Not Found)
 
-Oeps, het ziet ernaar uit dat die tree object niet in het losse formaat op de server bestaat, dus krijg je een 404 antwoord. Er zijn hiervoor een aantal redenen: het object kan in een ander repository staat, of het kan in een packfile in dit repository staan. Git gaat eerst naar de benoemde alternatieven kijken:
+Oeps, het ziet ernaar uit dat die tree object niet in het loose formaat op de server bestaat, dus krijg je een 404 antwoord. Er zijn hiervoor een aantal redenen: het object zou in een ander repository kunnen staan, of het kan in een packfile in deze repository staan. Git gaat eerst naar de benoemde alternatieven kijken:
 
 	=> GET objects/info/http-alternates
 	(empty file)
 
-Als dit een lijst met alternatieve URL's bevat, zal Git daar voor losse bestanden en packfiles gaan kijken. Dit is een prettig mechanisme voor projecten die forks zijn van een ander zodat ze objecten kunnen delen op de schijf. Maar omdat er in dit geval geen alternatieven vermeld staan, moet het object in een packfile zitten. Om te zien welke packfiles beschikbaar zijn op deze server moet je het `objects/info/packs` bestand ophalen, wat een lijst hiervan bevat (ook gegenereerd door `update-server-info`):
+Als dit een lijst met alternatieve URL's bevat, zal Git daar voor loose bestanden en packfiles gaan kijken. Dit is een prettig mechanisme voor projecten die forks zijn van een ander zodat ze objecten kunnen delen op de schijf. Maar omdat er in dit geval geen alternatieven vermeld staan, moet het object in een packfile zitten. Om te zien welke packfiles beschikbaar zijn op deze server moet je het `objects/info/packs` bestand ophalen, wat een lijst hiervan bevat (ook gegenereerd door `update-server-info`):
 
 	=> GET objects/info/packs
 	P pack-816a9b2334da9953e530f27bcac22082a9f5b835.pack
 
-Er is slechts één packfile op de server dus dat object zit daar natuurlijk in, maar je controleert het index bestand om het zeker te weten. Dit is ook handig als je meerdere packfiles op de server hebt, zodat je kunt zien welke packfile het object dat je nodig hebt bevat:
+Er is slechts één packfile op de server dus dat object zit daar natuurlijk in, maar je controleert het index bestand om er zeker van te zijn. Dit is ook handig als je meerdere packfiles op de server hebt, zodat je kunt zien welke packfile het object dat je nodig hebt bevat:
 
 	=> GET objects/pack/pack-816a9b2334da9953e530f27bcac22082a9f5b835.idx
 	(4k of binary data)
 
-Nu je de packfile index hebt kun je zien of het object hier in zit; omdat de index de SHA's van de objecten in de packfile toont en de offsets naar die objecten. Het gezochte object is aanwezig, dus gaat verder en haalt de hele packfile op:
+Nu je de packfile index hebt kun je zien of het object hier in zit - omdat de index de SHA's van de objecten in de packfile toont en de offsets naar die objecten. Het gezochte object is aanwezig, dus ga je verder en haalt de hele packfile op:
 
 	=> GET objects/pack/pack-816a9b2334da9953e530f27bcac22082a9f5b835.pack
 	(13k of binary data)
@@ -697,7 +732,7 @@ Het gehele uitvoer van dit proces ziet er zo uit:
 
 ### Het slimme protocol ###
 
-De HTTP methode is eenvoudig, maar een beetje inefficiënt. Slimme protocollen gebruiken is een meer gebruikelijke manier van gegevensoverdracht. Deze protocollen hebben een proces aan de remote kant dat bewust is van Git: het kan lokale gegevens lezen en uitvinden wat de client heeft of nodig heeft en hier specifieke gegevens voor genereren. Er zijn twee paar processen voor gegevensoverdracht: één paar voor het uploaden van gegevens en één paar voor het downloaden van gegevens.
+De HTTP methode is eenvoudig, maar een beetje inefficiënt. Slimme protocollen gebruiken is een meer gebruikelijke manier van gegevensoverdracht. Deze protocollen hebben een proces aan de remote kant dat bewust is van Git - het kan lokale gegevens lezen en uitvinden wat de client heeft of nodig heeft en hier specifieke gegevens voor genereren. Er zijn twee paar processen voor gegevensoverdracht: één paar voor het uploaden van gegevens en één paar voor het downloaden van gegevens.
 
 #### Gegevens uploaden ####
 
@@ -710,7 +745,7 @@ Bijvoorbeeld, stel dat je `git push origin master` uitvoert in je project en `or
 	003e085bb3bcb608e1e84b2432f8ecbe6306e7e7 refs/heads/topic
 	0000
 
-Het `git-receive-pack` commando antwoordt onmiddellijk met één regel voor iedere referentie die het momenteel heeft; in dit geval alleen de `master` branch en zijn SHA. De eerste regel bevat ook een lijst van de mogelijkheden van de server (hier: `report-status` en `delete-refs`).
+Het `git-receive-pack` commando antwoordt direct met één regel voor iedere referentie die het momenteel heeft - in dit geval alleen de `master` branch en zijn SHA. De eerste regel bevat ook een lijst van de mogelijkheden van de server (hier: `report-status` en `delete-refs`).
 
 Iedere regel begint met een hexadecimale waarde van 4 bytes, die specificeert hoe lang de rest van de regel is. Je eerste regel begint met 005b, wat 91 in hex is, wat betekent dat er nog 91 bytes over zijn op deze regel. De volgende regel begint met 003e, wat 62 is, waarna je de overgebleven 62 bytes leest. De volgende regel is 0000, wat betekent dat de server klaar is met het tonen van zijn referenties.
 
@@ -720,7 +755,7 @@ Nu de status van de server bekend is, bepaalt het `send-pack` proces welke commi
 	00670000000000000000000000000000000000000000 cdfdb42577e2506715f8cfeacdbabc092bf63e8d refs/heads/experiment
 	0000
 
-Een SHA-1 waarde met alleen '0' betekent dat er nog niets was; omdat je de experiment referentie toevoegt. Als je een referentie aan het verwijderen was, zou je het tegenovergestelde zien: allemaal '0'en aan de rechterkant.
+De SHA-1 waarde met alleen '0' betekent dat er nog niets was - omdat je de experiment referentie toevoegt. Als je een referentie aan het verwijderen was, zou je het tegenovergestelde zien: allemaal '0'en aan de rechterkant.
 
 Git stuurt een regel voor iedere referentie die je vernieuwt met de oude SHA, de nieuwe SHA en de referentie die vernieuwd wordt. De eerste regel bevat ook de mogelijkheden van de client. Vervolgens uploadt de client een packfile met alle objecten die de server nog niet heeft. Als laatste antwoordt de server met een indicatie van succes (of mislukking):
 
@@ -734,13 +769,13 @@ Er zijn verschillende manieren om het `upload-pack` proces op de remote reposito
 
 	003fgit-upload-pack schacon/simplegit-progit.git\0host=myserver.com\0
 
-Het begint met de 4 bytes die specificeren hoeveel gegevens er volgen, daarna het commando gevolgd door een null byte, en dan de hostname van de server gevolgd door een laatste null byte. De Git daemon bekijkt of dat commando uitgevoerd kan worden, dat de repository bestaat en dat het publieke permissies heeft. Als alles OK is, dan start het het `upload-pack` proces en geeft het verzoek hier aan door.
+Het begint met de 4 bytes die specificeren hoeveel gegevens er volgen, daarna het commando gevolgd door een null byte, en dan de hostname van de server gevolgd door een laatste null byte. De Git daemon controleert of dat commando uitgevoerd kan worden, dat de repository bestaat en dat het publieke permissies heeft. Als alles in orde is, dan start het het `upload-pack` proces en geeft het verzoek hier aan door.
 
 Als je de fetch via SSH doet, voert het `fetch-pack` in plaats daarvan zoiets als dit uit:
 
 	$ ssh -x git@github.com "git-upload-pack 'schacon/simplegit-progit.git'"
 
-In beide gevallen stuurt `upload-pack`, nadat `fetch-pack` verbinding gemaakt heeft, zoiets als dit:
+In beide gevallen wordt, nadat `fetch-pack` verbinding gemaakt heeft, door `upload-pack` zoiets als het volgende gestuurd:
 
 	0088ca82a6dff817ec66f44342007202690a93763949 HEAD\0multi_ack thin-pack \
 	  side-band side-band-64k ofs-delta shallow no-progress include-tag
@@ -748,7 +783,7 @@ In beide gevallen stuurt `upload-pack`, nadat `fetch-pack` verbinding gemaakt he
 	003e085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7 refs/heads/topic
 	0000
 
-Dit komt erg overeen met hoe `receive-pack` antwoordt, maar de mogelijkheden zijn verschillend. Daarnaast stuurt het de HEAD referentie zodat de client weet wat er uitgechecked moet worden als dit een kloon is.
+Dit komt sterk overeen met hoe `receive-pack` antwoordt, maar de mogelijkheden zijn verschillend. Daarnaast stuurt het de HEAD referentie zodat de client weet wat er uitgechecked moet worden als dit een clone is.
 
 Op dit punt kijkt het `fetch-pack` proces naar welke objecten het heeft en antwoordt met de objecten die het nodig heeft door "want" te sturen, gevolgd door de SHA die het wil hebben. Het stuurt al de objecten die het al heeft met "have" en dan de SHA. Aan het einde van deze lijst schrijft het "done" om het `upload-pack` proces te laten beginnen met het sturen van de packfile met de gegevens die het nodig heeft:
 
@@ -757,21 +792,21 @@ Op dit punt kijkt het `fetch-pack` proces naar welke objecten het heeft en antwo
 	0000
 	0009done
 
-Dat is een basaal geval van de overdrachtsprotocollen. In meer complexe gevallen ondersteunt de client `multi_ack` of `side-band` mogelijkheden; maar dit voorbeeld toont je het basale over en weer dat gebruikt wordt door de slimme protocol processen.
+Dat is een erg basaal geval van de overdrachtsprotocollen. In meer complexe gevallen ondersteunt de client `multi_ack` of `side-band` mogelijkheden; maar dit voorbeeld toont je het basale over en weer dat plaatsvindt bij de slimme protocol processen.
 
 ## Onderhoud en het herstellen van gegevens ##
 
-Soms moet je wat opruimen: een repository compacter maken, een geïmporteerd repository opruimen of verloren werk terughalen. Deze paragraaf zal deze scenario's behandelen.
+Soms moet je wat opruimen - een repository compacter maken, een geïmporteerde repository opruimen of verloren werk terughalen. In deze paragraaf zal een aantal van deze scenario's behandeld worden.
 
 ### Onderhoud ###
 
-Geregeld voert Git automatisch een commando genaamd "auto gc" uit. Het merendeel van de tijd doet dit commando niets. Maar, als je teveel losse objecten (objecten die niet in een packfile zitten) of teveel packfiles hebt, lanceert Git een uitgebreid `git gc` commando. Het `gc` staat voor garbage collect (afval ophalen), en het commando doet een aantal zaken: het haalt alle losse objecten op en stopt ze in packfiles, het voegt packfiles samen in één grote packfile, en het verwijdert objecten die niet bereikbaar zijn vanuit een commit en een paar maanden oud zijn.
+Geregeld voert Git automatisch een commando genaamd "auto gc" uit. Het merendeel van de tijd doet dit commando niets. Maar, als je teveel loose objecten (objecten die niet in een packfile zitten) of teveel packfiles hebt, lanceert Git een uitgebreid `git gc` commando. Het `gc` staat voor garbage collect (afval ophalen), en het commando doet een aantal zaken: het haalt alle loose objecten op en stopt ze in packfiles, het consolideert packfiles tot één grote packfile, en het verwijdert objecten die niet bereikbaar zijn vanuit een commit en een paar maanden oud zijn.
 
 Je kunt auto gc als volgt handmatig uitvoeren:
 
 	$ git gc --auto
 
-Nogmaals, over het algemeen doet dit commando niets. Je moet ongeveer 7.000 losse objecten of meer dan 50 packfiles hebben voordat Git een echt gc commando start. Je kunt deze grenzen respectievelijk met de `gc.auto` en `gc.autopacklimit` configuratie instellingen aanpassen.
+Nogmaals, over het algemeen doet dit commando niets. Je moet ongeveer 7.000 losse objecten of meer dan 50 packfiles hebben voordat Git een echt gc commando start. Je kunt deze grenzen aanpassen met respectievelijk de `gc.auto` en `gc.autopacklimit` configuratie instellingen.
 
 Het andere dat `gc` zal doen is je referenties in een enkel bestand inpakken. Stel dat je repository de volgende branches en tags bevat:
 
@@ -781,7 +816,7 @@ Het andere dat `gc` zal doen is je referenties in een enkel bestand inpakken. St
 	.git/refs/tags/v1.0
 	.git/refs/tags/v1.1
 
-Als je `git gc` uitvoert, zul je deze bestanden niet langer in de `refs` directory hebben. Git zal ze omwille van efficiëntie in een bestand genaamd `.git/packed-refs` stoppen, dat er zo uitziet:
+Als je `git gc` uitvoert, zal je deze bestanden niet langer in de `refs` directory hebben. Git zal ze omwille van efficiëntie in een bestand genaamd `.git/packed-refs` stoppen, dat er zo uitziet:
 
 	$ cat .git/packed-refs
 	# pack-refs with: peeled
@@ -797,9 +832,9 @@ Let op de laatste regel van het bestand, die begint met een `^`. Dit betekent da
 
 ### Gegevens herstellen ###
 
-Op een bepaald punt in je reis met Git, is het mogelijk dat je per ongeluk eens een commit verliest. Over het algemeen gebeurt dit omdat je een branch waar werk op zat geforceerd verwijdert, en het blijkt dat je de branch achteraf toch had willen houden. Of je hard-reset een branch, waarmee je commits achterlaat waar je iets van wilde hebben. Stel dat dit gebeurt, hoe kun je dan je commits terug halen?
+Op een gegeven moment tijdens je reis met Git, is het mogelijk dat je per ongeluk een commit kwijtraakt. Meestal gebeurt dit omdat je een branch waar werk op zat geforceerd verwijdert, en je komt erachter dat je de branch achteraf toch had willen houden. Of je hard-reset een branch, waarmee je commits verliest waar je iets uit wilde hebben. Stel dat dit gebeurt, hoe kun je dan je commits terug halen?
 
-Hier is een voorbeeld dat een hard-reset doet naar een oudere commit op de master branch in je test repository, en de verloren commits terug haalt. Laten we eerst eens bekijken waar je repository op dit punt staat:
+Hier is een voorbeeld dat de master branch hard-reset naar een oudere commit in je test repository, en daarna verloren commits terug haalt. Laten we eerst eens bekijken waar je repository op dit punt staat:
 
 	$ git log --pretty=oneline
 	ab1afef80fac8e34258ff41fc1b867c702daa24b modified repo a bit
@@ -817,7 +852,7 @@ Nu verplaats je de `master` branch terug naar de middelste commit:
 	cac0cab538b970a37ea1e769cbbde608743bc96d second commit
 	fdf4fc3344e67ab068f836878b6c4951e3b15f3d first commit
 
-Je bent nu effectief de twee bovenste commits kwijt: je hebt geen branch van waaruit deze commits bereikbaar zijn. Je moet de laatste commit SHA vinden en dan een branch toevoegen die daar naar wijst. De truuk is om de laatste commit SHA te vinden, het is toch niet waarschijnlijk dat je die onthouden hebt, toch?
+Je bent nu effectief de twee bovenste commits kwijt - je hebt geen branch van waaruit deze commits bereikbaar zijn. Je moet de SHA van de laatste commit vinden en dan een branch toevoegen die daar naar wijst. De truuk is om de SHA van de laatste commit te vinden, het is niet waarschijnlijk dat je die uit je hoofd geleerd hebt, toch?
 
 Vaak is de snelste manier een tool genaamd `git reflog` te gebruiken. Terwijl je werkt slaat Git stilletjes op wat je HEAD is, iedere keer als je die wijzigt. Elke keer als je commit, of van branch verandert wordt de reflog vernieuwd. Het reflog wordt ook vernieuwd door het `git update-ref` commando, wat nog een reden is om het te gebruiken in plaats van gewoon de SHA's naar je ref bestanden te schrijven, zoals we beschreven hebben in de "Git Referenties" paragraaf eerder in dit hoofdstuk. Je kunt op ieder moment zien waar je geweest bent, door `git reflog` uit te voeren.
 
@@ -854,13 +889,13 @@ Het ziet er naar uit dat de onderste commit degene is die je kwijt bent geraakt,
 	cac0cab538b970a37ea1e769cbbde608743bc96d second commit
 	fdf4fc3344e67ab068f836878b6c4951e3b15f3d first commit
 
-Vet – nu heb je een branch genaamd `recover-branch` die staat op het punt waar je `master` branch eerder was, waarmee de eerste twee commits weer bereikbaar zijn.
+Vet – nu heb je een branch genaamd `recover-branch` die staat op het punt waar je `master` branch vroeger op stond, waarmee de eerste twee commits weer bereikbaar zijn.
 Vervolgens, stel dat je verloren commit om een of andere reden niet in de reflog stond; je kunt dat simuleren door `recover-branch` te verwijderen en het reflog te wissen. Nu zijn de eerste twee commits nergens meer mee te bereiken:
 
 	$ git branch –D recover-branch
 	$ rm -Rf .git/logs/
 
-Omdat de reflog gegevens bewaard worden in de `.git/logs/` directory, heb je nu effectief geen reflog meer. Hoe kun je die commit op dat punt herstellen? Één manier is om gebruik te maken van het `git fsck` tool, wat de integriteit van je gegevensbank controleert. Als je het met de `--full` optie uitvoert, dan toont het je alle objecten waarnaar niet gewezen wordt door een ander object:
+Omdat de reflog gegevens bewaard worden in de `.git/logs/` directory, heb je nu effectief geen reflog meer. Hoe kun je die commit nu herstellen? Één manier is om gebruik te maken van het `git fsck` tool, wat de integriteit van je gegevensbank controleert. Als je het met de `--full` optie uitvoert, dan toont het je alle objecten waarnaar niet gewezen wordt door een ander object:
 
 	$ git fsck --full
 	dangling blob d670460b4b4aece5915caf5c68d12f560a9fe3e4
@@ -868,15 +903,15 @@ Omdat de reflog gegevens bewaard worden in de `.git/logs/` directory, heb je nu
 	dangling tree aea790b9a58f6cf6f2804eeac9f0abbe9631e4c9
 	dangling blob 7108f7ecb345ee9d0084193f147cdad4d2998293
 
-In dit geval, kun je de vermiste commit zien na de hangende ('dangling') commit. Je kunt het op dezelfde manier herstellen, door een branch te maken die naar die SHA wijst.
+In dit geval, kun je de vermiste commit zien na de dangling commit (rondslingerende commit). Je kunt het op dezelfde manier herstellen, door een branch te maken die naar die SHA wijst.
 
 ### Objecten verwijderen ###
 
-Er zijn een hoop geweldige dingen aan Git, maar één eigenschap die problemen kan geven is het feit dat `git clone` de hele historie van het project download, inclusief alle versies van alle bestanden. Dat is geen probleem als het hele project broncode is, omdat Git zeer geoptimaliseerd is om die gegevens optimaal te comprimeren. Maar, als iemand op een bepaald punt in de geschiedenis een enorm bestand heeft toegevoegd, zal iedere kloon voor altijd gedwongen worden om dat grote bestand te downloaden, zelfs als het uit het project was verwijderd in de eerstvolgende commit. Omdat het bereikbaar is vanuit de geschiedenis, zal het er altijd zijn.
+Er zijn een hoop geweldige dingen aan Git, maar één eigenschap die problemen kan geven is het feit dat `git clone` de hele historie van het project download, inclusief alle versies van alle bestanden. Dat is geen probleem als het hele project broncode is, omdat Git zeer geoptimaliseerd is om die gegevens optimaal te comprimeren. Maar, als iemand op een bepaald punt in de geschiedenis een enorm bestand heeft toegevoegd, zal iedere clone voor altijd gedwongen worden om dat grote bestand te downloaden, zelfs als het uit het project wordt verwijderd in de eerstvolgende commit. Omdat het bereikbaar is vanuit de geschiedenis, zal het er altijd zijn.
 
-Dit kan een groot probleem zijn als je Subversion of Perforce repositories converteert naar Git. Omdat je niet de hele geschiedenis download in die systemen, zal dit soort toevoeging een paar consequenties met zich meebrengen. Als je een import vanuit een ander systeem deed, of om een andere reden vindt dat je repository veel groter is dan het zou moeten zijn, kun je hier zien hoe je grote objecten kunt vinden en verwijderen.
+Dit kan een groot probleem zijn als je Subversion of Perforce repositories converteert naar Git. Omdat je niet de hele geschiedenis downloadt in die systemen, zal dit soort toevoeging weinig consequenties met zich meebrengen. Als je een import vanuit een ander systeem deed, of om een andere reden vindt dat je repository veel groter is dan het zou moeten zijn, kun je hier zien hoe je grote objecten kunt vinden en verwijderen.
 
-Let op: deze techniek is destructief voor je commit geschiedenis. Het herschrijft ieder commit object stroomafwaarts vanaf de eerste tree die je moet aanpassen om een referentie naar een groot bestand te verwijderen. Als je dit meteen na een import doet, voordat iemand werk is gaan baseren op de commit, dan is er niets aan de hand; anders moet je alle bijdragers waarschuwen dat ze hun werk op je nieuwe commits moeten rebasen.
+Let op: deze techniek is destructief voor je commit geschiedenis. Het herschrijft ieder commit object stroomafwaarts vanaf de eerste tree die je moet aanpassen om een referentie naar een groot bestand te verwijderen. Als je dit meteen na een import doet, voordat iemand werk is gaan baseren op de commit, dan is er niets aan de hand - anders moet je alle bijdragers waarschuwen dat ze hun werk op je nieuwe commits moeten rebasen.
 
 Om het te demonstreren, voeg je een groot bestand in je test repository toe, verwijdert het in de volgende commit, vindt het, en verwijdert het daarna permanent uit de repository. Als eerste, voeg je een groot object toe aan je geschiedenis:
 
@@ -916,21 +951,21 @@ Je kunt het `count-objects` commando gebruiken om snel te zien hoeveel ruimte je
 	prune-packable: 0
 	garbage: 0
 
-Op de `size-pack` regel staat de grootte van je packfiles in kilobytes, dus je gebruikt 2Mb. Voor de laatste commit gebruikte je bijna 2K; het is duidelijk dat het verwijderen van het bestand uit de vorige commit, het niet uit je geschiedenis verwijderd heeft. Iedere keer als iemand dit repository kloont, zullen ze de volle 2Mb moeten klonen alleen maar om dit kleine project te krijgen, omdat jij per ongeluk een groot bestand toegevoegd hebt. Laten we het kwijtraken.
+Op de `size-pack` regel staat de grootte van je packfiles in kilobytes, dus je gebruikt 2Mb. Voor de laatste commit gebruikte je bijna 2K - het is duidelijk dat het verwijderen van het bestand uit de vorige commit, het niet uit je geschiedenis verwijderd heeft. Iedere keer als iemand dit repository cloned, zullen ze de volle 2Mb moeten clonen alleen maar om dit kleine project te krijgen, omdat jij per ongeluk een groot bestand toegevoegd hebt. Laten we het echt verwijderen.
 
-Eerst moet je het vinden. In dit geval weet je al welk bestand het is. Maar stel dat je het niet wist; hoe zou je kunnen vinden welk bestand of bestanden zoveel ruimte in beslag nemen? Als je `git gc` uitvoert zitten alle objecten in een packfile; je kunt de grote bestanden identificeren door een ander plumbing commando genaamd `git verify-pack` uit te voeren en te sorteren op het derde veld in de uitvoer, wat de bestandsgrootte is. Je kunt het ook door het `tail` commando leiden omdat je alleen geïnteresseerd bent in het laatste paar grote bestanden.
+Eerst moet je het vinden. In dit geval weet je al welk bestand het is. Maar stel dat je het niet zou weten; hoe zou je kunnen ontdekken welk bestand of bestanden zoveel ruimte in beslag nemen? Als je `git gc` uitvoert zitten alle objecten in een packfile; je kunt de grote bestanden identificeren door een ander plumbing commando genaamd `git verify-pack` uit te voeren en te sorteren op het derde veld in de uitvoer, wat de bestandsgrootte is. Je kunt het ook door het `tail` commando leiden omdat je alleen geïnteresseerd bent in het laatste paar grote bestanden.
 
 	$ git verify-pack -v .git/objects/pack/pack-3f8c0...bb.idx | sort -k 3 -n | tail -3
 	e3f094f522629ae358806b17daf78246c27c007b blob   1486 734 4667
 	05408d195263d853f09dca71d55116663690c27c blob   12908 3478 1189
 	7a9eb2fba2b1811321254ac360970fc169ba2330 blob   2056716 2056872 5401
 
-Het grote object staat aan het einde: 2 Mb. Om uit te vinden welk bestand het is, zul je het `rev-list` commando gebruiken, wat je eventjes gebruikt hebt in Hoofdstuk 7. Als je `--objects` meegeeft aan `ref-list`, toont het alle commit SHA's en ook de blob SHA's met de bestandspaden die er mee geassocieerd zijn. Je kunt dit gebruiken om de naam van je blob te vinden:
+Het grote object staat aan het einde: 2 Mb. Om uit te vinden welk bestand het is, kan je het `rev-list` commando gebruiken, wat je eventjes gebruikt hebt in Hoofdstuk 7. Als je `--objects` meegeeft aan `ref-list`, toont het alle commit SHA's en ook de blob SHA's met de bestandspaden die er mee geassocieerd zijn. Je kunt dit gebruiken om de naam van je blob te vinden:
 
 	$ git rev-list --objects --all | grep 7a9eb2fb
 	7a9eb2fba2b1811321254ac360970fc169ba2330 git.tbz2
 
-Nu moet je dit bestand verwijderen uit alle trees in je verleden. Je kunt eenvoudig zien welke commits dit bestand aangepast hebben:
+Nu moet je dit bestand verwijderen uit alle trees in het verleden. Je kunt eenvoudig zien welke commits dit bestand aangepast hebben:
 
 	$ git log --pretty=oneline --branches -- git.tbz2
 	da3f30d019005479c99eb4c3406225613985a1db oops - removed large tarball
@@ -944,9 +979,9 @@ Je moet alle commits die stroomafwaarts van `6df76` liggen herschrijven om dit b
 	Rewrite da3f30d019005479c99eb4c3406225613985a1db (2/2)
 	Ref 'refs/heads/master' was rewritten
 
-De `--index-filter` optie is vergelijkbaar met de `--tree-filter` optie, die gebruikt is in Hoofdstuk 6, met het verschil dat in plaats van het doorgeven van een commando dat bestanden aanpast die uitgechecked staan op je schijf, je het staging area of index iedere keer aanpast. In plaats van een specifiek bestand steeds te verwijderen met zoiets als `rm file`, moet je het met `git rm --cached` verwijderen; je moet het uit de index verwijderen, niet van de schijf. Reden om het zo te doen is snelheid: omdat Git niet iedere versie hoeft uit te checken op je schijf voordat het je filter uitvoert, kan het proces vele, vele malen sneller gaan. Je kunt dezelfde taak uitvoeren met `--tree-filter` als je dat wilt. De `--ignore-unmatch` optie op `git rm` vertelt het niet te stoppen op een fout als het patroon dat je probeert te verwijderen niet aanwezig is. Als laatste zal je `filter-branch` vragen om je geschiedenis alleen vanaf de `6df7640` commit te herschrijven, omdat je weet dat dat de plaats is waar het probleem begon. Anders start het vanaf het begin en duurt het onnodig langer.
+De `--index-filter` optie is vergelijkbaar met de `--tree-filter` optie, die gebruikt is in Hoofdstuk 6, met het verschil dat in plaats van het doorgeven van een commando dat bestanden aanpast die uitgecheckt staan op je schijf, je de staging area of index iedere keer aanpast. In plaats van een specifiek bestand steeds te verwijderen met zoiets als `rm file`, moet je het met `git rm --cached` verwijderen - je moet het uit de index verwijderen, niet van de schijf. Reden om het zo te doen is snelheid - omdat Git niet iedere versie hoeft uit te checken op je schijf voordat het je filter uitvoert, kan het proces vele, vele malen sneller gaan. Je kunt dezelfde taak uitvoeren met `--tree-filter` als je dat wilt. De `--ignore-unmatch` optie op `git rm` vertelt het niet te stoppen op een fout als het patroon dat je probeert te verwijderen niet aanwezig is. Als laatste zal je `filter-branch` vragen om je geschiedenis alleen vanaf de `6df7640` commit te herschrijven, omdat je weet dat dat de plaats is waar het probleem begon. Anders start het vanaf het begin en duurt het onnodig langer.
 
-Je geschiedenis zal niet langer een referentie bevatten naar dat bestand. Maar, je reflog en een nieuwe set refs die Git toevoegde toen je de `filter-branch` deed onder `.git/refs/original` bevatten het nog steeds, dus je moet die ook verwijderen en je gegevensbank opnieuw inpakken. Je moet alles wat een pointer naar die oude commits bevat kwijtraken voordat je opnieuw inpakt:
+Je geschiedenis zal niet langer een referentie bevatten naar dat bestand. Maar, je reflog en een nieuwe verzameling refs die Git toevoegde toen je de `filter-branch` deed onder `.git/refs/original` bevatten het nog steeds, dus je moet die ook verwijderen en dan je gegevensbank opnieuw inpakken. Je moet alles wat een pointer naar die oude commits bevat kwijtraken voordat je opnieuw inpakt:
 
 	$ rm -Rf .git/refs/original
 	$ rm -Rf .git/logs/
@@ -968,10 +1003,10 @@ Laten we eens zien hoeveel ruimte je bespaard hebt.
 	prune-packable: 0
 	garbage: 0
 
-De grootte van je ingepakte repository is omlaag gegaan naar 7 K, wat veel beter is dan 2 Mb. Je kunt aan de waarde van size zien dat het grote object nog steeds in je losse bestanden staat, dus het is niet weg; maar het zal niet meer overgedragen worden bij een push of opvolgende kloon, wat het belangrijkste is. Als je het echt zou willen, kun je het object volledig verwijderen door `git prune --expire` uit te voeren.
+De grootte van je ingepakte repository is omlaag gegaan naar 7 K, wat veel beter is dan 2 Mb. Je kunt aan de waarde van size zien dat het grote object nog steeds in je loose objecten staat, dus het is niet weg; maar het zal niet meer overgedragen worden bij een push of opvolgende clone, wat het belangrijkste is. Als je het echt zou willen, kun je het object volledig verwijderen door `git prune --expire` uit te voeren.
 
 ## Samenvatting ##
 
-Je moet een goed begrip hebben van wat Git op de achtergrond doet en, tot een bepaalde hoogte, hoe het in elkaar gezet is. Dit hoofdstuk heeft een aantal plumbing commando's besproken – commando's die op een lager niveau zitten en eenvoudige zijn dan de porcelain commando's waarover je in de rest van het boek geleerd hebt. Begrijpen hoe Git op een lager niveau werkt zou het makkelijker moeten maken om te begrijpen waarom het doet wat het doet en ook om je eigen applicaties te schrijven en hulp scripts om jouw specifieke werkwijze voor je te laten werken.
+Je moet een redelijk goed begrip hebben van wat Git op de achtergrond doet en, tot een bepaalde hoogte, hoe het geimplementeerd is. Dit hoofdstuk heeft een aantal plumbing commando's besproken – commando's die op een lager niveau zitten en eenvoudige zijn dan de porcelain commando's waarover je in de rest van het boek gelezen hebt. Begrijpen hoe Git op een lager niveau werkt zou het makkelijker moeten maken om te begrijpen waarom het doet wat het doet en ook om je eigen applicaties te schrijven en hulp scripts om jouw specifieke workflow voor je te laten werken.
 
 Git is als een inhouds-toegankelijk bestandssysteem een zeer krachtig tool dat je eenvoudig als meer dan alleen een VCS kunt gebruiken. Ik hoop dat je deze nieuwe kennis van de werking van Git kunt gebruiken om je eigen coole applicatie te bouwen met deze technologie en dat je je prettig voelt bij het gebruik van Git op meer geavanceerde manieren.

From 5a854d0917e4243e513b5298367756a206ad5620 Mon Sep 17 00:00:00 2001
From: Sicaine <sicaine@gmail.com>
Date: Tue, 25 Feb 2014 09:48:43 +0100
Subject: [PATCH 245/690] Update 01-chapter3.markdown

simple typo: Du kann mehrere Branches -> Du kannst mehrere Branches
---
 de/03-git-branching/01-chapter3.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/de/03-git-branching/01-chapter3.markdown b/de/03-git-branching/01-chapter3.markdown
index 81fea42ec..743e42ed4 100644
--- a/de/03-git-branching/01-chapter3.markdown
+++ b/de/03-git-branching/01-chapter3.markdown
@@ -536,7 +536,7 @@ Jetzt da Du die Grundlagen von 'branching' und 'merging' kennst, fragst Du Dich
 
 <!--Because Git uses a simple three-way merge, merging from one branch into another multiple times over a long period is generally easy to do. This means you can have several branches that are always open and that you use for different stages of your development cycle; you can merge regularly from some of them into others.-->
 
-Da Git das einfachen 3-Wege-'merge' verwendet, ist häufiges Zusammenführen von einer Branch in eine andere über einen langen Zeitraum generell einfach zu bewerkstelligen. Das heisst, Du kann mehrere Branches haben, die alle offen sind und auf unterschiedlichen Ebenen Deines Entwicklungszyklus verwendung finden, und diese regelmäßig ineinander zusammenführen.
+Da Git das einfachen 3-Wege-'merge' verwendet, ist häufiges Zusammenführen von einer Branch in eine andere über einen langen Zeitraum generell einfach zu bewerkstelligen. Das heisst, Du kannst mehrere Branches haben, die alle offen sind und auf unterschiedlichen Ebenen Deines Entwicklungszyklus verwendung finden, und diese regelmäßig ineinander zusammenführen.
 
 <!--Many Git developers have a workflow that embraces this approach, such as having only code that is entirely stable in their `master` branch — possibly only code that has been or will be released. They have another parallel branch named develop or next that they work from or use to test stability — it isn’t necessarily always stable, but whenever it gets to a stable state, it can be merged into `master`. It’s used to pull in topic branches (short-lived branches, like your earlier `iss53` branch) when they’re ready, to make sure they pass all the tests and don’t introduce bugs.-->
 

From 27f42b74176d374a6a2f4f3c1bdc518424b70848 Mon Sep 17 00:00:00 2001
From: cor <git@cpt1.demon.nl>
Date: Tue, 25 Feb 2014 20:45:39 +0100
Subject: [PATCH 246/690] [nl] All chapters - Add header and SHA-1 of current
 HEAD

	Added SHA-1 of current head to be used in future to
	allow for easier (hopefully) comparison of changes in
	en - original texts.
---
 nl/01-introduction/01-chapter1.markdown       |  1 +
 nl/02-git-basics/01-chapter2.markdown         | 15 ++++----
 nl/03-git-branching/01-chapter3.markdown      | 15 ++++----
 nl/04-git-server/01-chapter4.markdown         |  2 +-
 nl/05-distributed-git/01-chapter5.markdown    |  1 +
 nl/06-git-tools/01-chapter6.markdown          |  1 +
 nl/07-customizing-git/01-chapter7.markdown    |  1 +
 nl/08-git-and-other-scms/01-chapter8.markdown | 38 ++++++++++++++++++-
 nl/09-git-internals/01-chapter9.markdown      |  1 +
 9 files changed, 59 insertions(+), 16 deletions(-)

diff --git a/nl/01-introduction/01-chapter1.markdown b/nl/01-introduction/01-chapter1.markdown
index 7b8906914..117d556b0 100644
--- a/nl/01-introduction/01-chapter1.markdown
+++ b/nl/01-introduction/01-chapter1.markdown
@@ -33,6 +33,7 @@ vertaling moeten proberen te maken.
 
 Veel succes en plezier bij het vertalen...
 -->
+<!-- SHA-1 of last checked en-version: fbf24105 -->
 # Aan de slag #
 
 In dit hoofdstuk wordt uitgelegd hoe je aan de slag kunt gaan met Git. We zullen bij het begin beginnen door wat achtergrondinformatie over versiebeheersystemen te geven, daarna een korte uitleg hoe je Git werkend kan krijgen op je computer en sluiten af door uit te leggen hoe je Git kan instellen zodat je ermee aan het werk kunt.  Aan het einde van dit hoofdstuk zou je moeten kunnen begrijpen waarom Git er is, waarom je het zou moeten gebruiken en zal je helemaal klaar zijn om er mee aan de slag te gaan.
diff --git a/nl/02-git-basics/01-chapter2.markdown b/nl/02-git-basics/01-chapter2.markdown
index 7592861c2..6e1871b5c 100644
--- a/nl/02-git-basics/01-chapter2.markdown
+++ b/nl/02-git-basics/01-chapter2.markdown
@@ -33,6 +33,7 @@ vertaling moeten proberen te maken.
 
 Veel succes en plezier bij het vertalen...
 -->
+<!-- SHA-1 of last checked en-version: fbf24105 -->
 # De basis van Git #
 
 Als je slechts één hoofdstuk kunt lezen om met Git aan de slag te gaan, dan is deze het. In dit hoofdstuk worden alle basiscommando's behandeld, die je nodig hebben om het leeuwendeel van de dingen te doen waarmee je uiteindelijk je tijd met Git zult doorbrengen. Als je dit hoofdstuk doorgenomen hebt, zul je een repository kunnen configureren en initialiseren, bestanden beginnen en stoppen te volgen en veranderingen te ‘stagen’ en ‘committen’. We laten ook zien hoe je Git kunt instellen zodat het bepaalde bestanden en bestandspatronen negeert, hoe je vergissingen snel en gemakkelijk ongedaan kunt maken, hoe je de geschiedenis van je project kan doorlopen en wijzigingen tussen commits kunt zien, en hoe je kunt pushen en pullen van en naar repositories.
@@ -485,7 +486,7 @@ Als je `git log` in dit project uitvoert, zou je output moeten krijgen die er on
 
 	    first commit
 
-Zonder argumenten toont `git log` de commits die gedaan zijn in die repository, in omgekeerde chronologische volgorde. Dat wil zeggen: de meest recente commits worden als eerste getoond. Zoals je kunt zien, toont dit commando iedere commit met zijn SHA-1 checksum, de naam van de auteur en zijn e-mail, de datum van opslaan, en de commit boodschap.
+Zonder argumenten toont `git log` standaard de commits die gedaan zijn in die repository, in omgekeerde chronologische volgorde. Dat wil zeggen: de meest recente commits worden als eerste getoond. Zoals je kunt zien, toont dit commando iedere commit met zijn SHA-1 checksum, de naam van de auteur en zijn e-mail, de datum van opslaan, en de commit boodschap.
 
 Een gigantisch aantal en variëteit aan opties zijn beschikbaar voor het `git log` commando om je precies te laten zien waar je naar op zoek bent. Hier laten we je de meest gebruikte opties zien.
 
@@ -851,7 +852,7 @@ Nu kun je de naam pb op de commandoregel gebruiken in plaats van de hele URL. Bi
 	 * [new branch]      master     -> pb/master
 	 * [new branch]      ticgit     -> pb/ticgit
 
-Paul zijn master branch is lokaal toegankelijk als `pb/master`; je kunt het in een van jouw branches mergen, of je kunt een lokale branch uitchecken op dat punt als je het wil zien.
+De master branch van Paul is lokaal toegankelijk als `pb/master`; je kunt het in een van jouw branches mergen, of je kunt een lokale branch uitchecken op dat punt als je het wil zien.
 
 ### Van je remotes fetchen en pullen ###
 
@@ -931,9 +932,9 @@ Als je om een of andere reden een referentie wilt verwijderen, je hebt de server
 	$ git remote
 	origin
 
-## Labelen (Taggen) ##
+## Taggen (Labelen) ##
 
-Zoals de meeste VCS'en, heeft git de mogelijkheid om specifieke punten in de history als belangrijk te labelen (taggen). Over het algemeen gebruiken mensen deze functionaliteit om versie punten te markeren (`v1.0`, en zo). In deze paragraaf zul je leren hoe de beschikbare tags te tonen, hoe nieuwe tags te creëren, en wat de verschillende typen tags zijn.
+Zoals de meeste VCS'en, heeft git de mogelijkheid om specifieke punten in de history als belangrijk te taggen (labelen). Over het algemeen gebruiken mensen deze functionaliteit om versie punten te markeren (`v1.0`, en zo). In deze paragraaf zul je leren hoe de beschikbare tags te tonen, hoe nieuwe tags te creëren, en wat de verschillende typen tags zijn.
 
 ### Jouw tags laten zien ###
 
@@ -955,7 +956,7 @@ Je kunt ook zoeken op tags met een bepaald patroon. De Git bron repository, bijv
 
 ### Tags creëren ###
 
-Git gebruikt twee soorten tags: lichtgewicht (lightweight) en beschreven (annotated). Een lightweight tag komt overeen met een branch die niet verandert: het is slechts een wijzer naar een specifieke commit. Annotated tags daarentegen, zijn als volwaardige objecten in de Git database opgeslagen. Ze worden gechecksummed, bevatten de naam van de tagger, e-mail en datum, hebben een tag boodschap, en kunnen gesigneerd en geverifieerd worden met GNU Privacy Guard (GPG). Het wordt over het algemeen aangeraden om annotated tags te maken zodat je deze informatie hebt; maar als je een tijdelijke tag wilt of om een of andere reden de andere informatie niet wilt houden, dan zijn er ook lichtgewicht tags.
+Git gebruikt twee soorten tags: lightweight (lichtgewicht) en annotated (beschreven). Een lightweight tag komt overeen met een branch die niet verandert: het is slechts een wijzer naar een specifieke commit. Annotated tags daarentegen, zijn als volwaardige objecten in de Git database opgeslagen. Ze worden gechecksummed, bevatten de naam van de tagger, e-mail en datum, hebben een tag boodschap, en kunnen gesigneerd en geverifieerd worden met GNU Privacy Guard (GPG). Het wordt over het algemeen aangeraden om annotated tags te maken zodat je deze informatie hebt; maar als je een tijdelijke tag wilt of om een of andere reden de andere informatie niet wilt houden, dan zijn er ook lichtgewicht tags.
 
 ### Annotated tags ###
 
@@ -1134,7 +1135,7 @@ Als je veel tags hebt die je ineens wilt pushen, kun je ook de `--tags` optie aa
 	 * [new tag]         v1.4-lw -> v1.4-lw
 	 * [new tag]         v1.5 -> v1.5
 
-Als nu iemand anders van jouw repository cloned of pulled, dan zullen zij al jouw tags ook krijgen.
+Als nu iemand anders van jouw repository cloned of pullt, dan zullen zij al jouw tags ook krijgen.
 
 ## Tips en trucs ##
 
@@ -1155,7 +1156,7 @@ Druk de Tab toets als je een Git commando aan het typen bent, en het zou een lij
 	$ git co<tab><tab>
 	commit config
 
-In dit geval zal git co en dan de Tab toets twee keer indrukken git commit en config voorstellen. Als je daarna `m<tab>` toevoegt, wordt het automatisch tot `git commit` gecompleteerd.
+In dit geval zal `git co` en dan de Tab toets twee keer indrukken git commit en config voorstellen. Als je daarna `m<tab>` toevoegt, wordt het automatisch tot `git commit` gecompleteerd.
 
 Dit werkt ook met opties, wat nog bruikbaarder is. Bijvoorbeeld, als je een `git log` commando uitvoert en je een van de opties niet meer kunt herinneren, dan kun je beginnen met het te typen en Tab indrukken om te zien wat er past:
 
diff --git a/nl/03-git-branching/01-chapter3.markdown b/nl/03-git-branching/01-chapter3.markdown
index 76fcb44e1..0809e83b7 100644
--- a/nl/03-git-branching/01-chapter3.markdown
+++ b/nl/03-git-branching/01-chapter3.markdown
@@ -33,6 +33,7 @@ vertaling moeten proberen te maken.
 
 Veel succes en plezier bij het vertalen...
 -->
+<!-- SHA-1 of last checked en-version: fbf24105 -->
 # Branchen in Git #
 
 Bijna elk versiebeheersysteem ondersteunt een bepaalde vorm van branchen. Branchen komt erop neer dat je een tak afsplitst van de hoofd ontwikkellijn en daar verder mee gaat werken zonder aan de hoofdlijn te komen. Bij veel VCS'en is dat nogal een duur proces, vaak wordt er een nieuwe kopie gemaakt van de directory waar je broncode in staan, wat lang kan duren voor grote projecten.
@@ -164,7 +165,7 @@ Figuur 3-11 toont het resultaat.
 Insert 18333fig0311.png
 Figuur 3-11. Een nieuwe branch verwijzing maken.
 
-Je doet wat werk aan je web site en doet wat commits. Door dat te doen beweegt de `iss53` branch vooruit, omdat je het uitgechecked hebt (dat wil zeggen, je HEAD wijst ernaar; zie Figuur 3-12):
+Je doet wat werk aan je web site en doet wat commits. Door dat te doen beweegt de `iss53` branch vooruit, omdat je het uitgecheckt hebt (dat wil zeggen, je HEAD wijst ernaar; zie Figuur 3-12):
 
 	$ vim index.html
 	$ git commit -a -m 'added a new footer [issue 53]'
@@ -288,7 +289,7 @@ Alles wat merge conflicten heeft en wat nog niet is opgelost wordt getoond als u
 	</div>
 	>>>>>>> iss53
 
-Dit betekent dat de versie in HEAD (jouw master branch, omdat dat degene was dat je uitgechecked had toen je het merge commando uitvoerde) is het bovenste gedeelte van dat blok (alles boven de `======`), terwijl de versie in je `iss53` branch eruit ziet zoals alles in het onderste gedeelte. Om het conflict op te lossen, moet je één van de twee gedeeltes kiezen of de inhoud zelf mergen. Je zou bijvoorbeeld dit conflict op kunnen lossen door het hele blok met dit te vervangen:
+Dit betekent dat de versie in HEAD (jouw master branch, omdat dat degene was dat je uitgecheckt had toen je het merge commando uitvoerde) is het bovenste gedeelte van dat blok (alles boven de `======`), terwijl de versie in je `iss53` branch eruit ziet zoals alles in het onderste gedeelte. Om het conflict op te lossen, moet je één van de twee gedeeltes kiezen of de inhoud zelf mergen. Je zou bijvoorbeeld dit conflict op kunnen lossen door het hele blok met dit te vervangen:
 
 	<div id="footer">
 	please contact us at email.support@github.com
@@ -350,7 +351,7 @@ Het `git branch` commando doet meer dan alleen branches aanmaken en verwijderen.
 	* master
 	  testing
 
-Merk op dat het `*` karakter vooraf gaat aan de `master` branch: het geeft de branch aan dat je op dit moment uitgechecked hebt. Dit betekent dat als je op dit punt commit, de `master` branch vooruit zal gaan met je nieuwe werk. Om de laatste commit op iedere branch te zien, kun je `git branch -v` uitvoeren:
+Merk op dat het `*` karakter vooraf gaat aan de `master` branch: het geeft de branch aan dat je op dit moment uitgecheckt hebt. Dit betekent dat als je op dit punt commit, de `master` branch vooruit zal gaan met je nieuwe werk. Om de laatste commit op iedere branch te zien, kun je `git branch -v` uitvoeren:
 
 	$ git branch -v
 	  iss53   93b412c fix javascript issue
@@ -489,9 +490,9 @@ Dit maakt een lokale branch aan waar je op kunt werken, die begint met waar `ori
 
 ### Tracking branches ###
 
-Een lokale branch uitchecken van een remote branch creëert automatisch een zogenaamde _volg branch_ (_tracking branch_). Tracking branches zijn lokale branches die een directe releatie met een remote branch hebben. Als je op een tracking branch zit en `git push` typt, dat weet Git automatisch naar welke server en branch hij moet pushen. En, als je op een van die branches zit zal het uitvoeren van `git pull` alle remote referenties ophalen en automatisch de corresponderende remote branch erin mergen.
+Een lokale branch uitchecken van een remote branch creëert automatisch een zogenaamde _tracking branch_ (_volg branch_). Tracking branches zijn lokale branches die een directe releatie met een remote branch hebben. Als je op een tracking branch zit en `git push` typt, dat weet Git automatisch naar welke server en branch hij moet pushen. En, als je op een van die branches zit zal het uitvoeren van `git pull` alle remote referenties ophalen en automatisch de corresponderende remote branch erin mergen.
 
-Als je een repository cloned, zal het over het algemeen automatisch een `master` branch aanmaken die `origin/master` tracked. Daarom werken `git push` en `git pull` zo uit het doosje, zonder verdere argumenten. Maar je kan ook andere tracking branches aanmaken als je dat wilt, andere die niet branches tracken op `origin` en niet de `master` branch tracken. Een eenvoudig voorbeeld is wat je zojuist gezien hebt: `git checkout -b [branch] [remotenaam]/[branch]` uitvoeren. Als je Git versie 1.6.2 of nieuwer hebt, kun je ook de `--track` afkorting gebruiken:
+Als je een repository cloned, zal het over het algemeen automatisch een `master` branch aanmaken die `origin/master` trackt. Daarom werken `git push` en `git pull` zo uit het doosje, zonder verdere argumenten. Maar je kan ook andere tracking branches aanmaken als je dat wilt, andere die niet branches tracken op `origin` en niet de `master` branch tracken. Een eenvoudig voorbeeld is wat je zojuist gezien hebt: `git checkout -b [branch] [remotenaam]/[branch]` uitvoeren. Als je Git versie 1.6.2 of nieuwer hebt, kun je ook de `--track` afkorting gebruiken:
 
 	$ git checkout --track origin/serverfix
 	Branch serverfix set up to track remote branch serverfix from origin.
@@ -513,7 +514,7 @@ Stel dat je klaar bent met een remote branch - zeg maar, jij en je medewerkers z
 	To git@github.com:schacon/simplegit.git
 	 - [deleted]         serverfix
 
-Boem. Geen branch meer op je server. Je zult deze pagina wel een ezelsoortje willen geven, omdat je dat commando nodig gaat hebben en het waarschijnlijk zult vergeten. Een manier om dit commando te onthouden is door de `git push [remotenaam] [lokalebranch]:[remotebranch]` syntax te onthouden die we kortgeleden behandeld hebben. Als je het `[lokalebranch]` gedeelte weglaat dan zeg je in feite, "Neem niets aan mijn kant en maak dat de `[remotebranch]`."
+Poef. Geen branch meer op je server. Je zult deze pagina wel een ezelsoortje willen geven, omdat je dat commando nodig gaat hebben en het waarschijnlijk zult vergeten. Een manier om dit commando te onthouden is door de `git push [remotenaam] [lokalebranch]:[remotebranch]` syntax te onthouden die we kortgeleden behandeld hebben. Als je het `[lokalebranch]` gedeelte weglaat dan zeg je in feite, "Neem niets aan mijn kant en maak dat de `[remotebranch]`."
 
 ## Rebasen ##
 
@@ -622,7 +623,7 @@ Nu doet iemand anders wat meer werk wat een merge bevat, en pusht dat werk naar
 Insert 18333fig0337.png
 Figuur 3-37. Haal meer commits op, en merge ze in je werk.
 
-Daarna, beslist de persoon die het werk gepusht heeft om erop terug te komen en in plaats daarvan zijn werk te gaan rebasen; hij voeren een `git push --force` uit om de historie op de server te herschrijven. Je pulled daarna van die server, waarbij je de nieuwe commits binnen krijgt.
+Daarna, beslist de persoon die het werk gepusht heeft om erop terug te komen en in plaats daarvan zijn werk te gaan rebasen; hij voeren een `git push --force` uit om de historie op de server te herschrijven. Je pullt daarna van die server, waarbij je de nieuwe commits binnen krijgt.
 
 Insert 18333fig0338.png
 Figuur 3-38. Iemand pusht gerebasede commits, daarbij commits buitenspel zettend waar jij werk op gebaseerd hebt.
diff --git a/nl/04-git-server/01-chapter4.markdown b/nl/04-git-server/01-chapter4.markdown
index 6f5891a9e..78f101c69 100644
--- a/nl/04-git-server/01-chapter4.markdown
+++ b/nl/04-git-server/01-chapter4.markdown
@@ -1,4 +1,3 @@
-
 <!-- Attentie heren en dames vertalers.
 Ik zou het volgende willen voorstellen:
 Er zijn bepaalde termen die voor de gemiddelde Nederlandse computer gebruiker 
@@ -34,6 +33,7 @@ vertaling moeten proberen te maken.
 
 Veel succes en plezier bij het vertalen...
 -->
+<!-- SHA-1 of last checked en-version: fbf24105 -->
 # Git op de server #
 
 Je zou nu de alledaagse taken waarvoor je Git zult gebruiken moeten kunnen uitvoeren. Echter, om enige vorm van samenwerking te hebben in Git is een remote Git repository nodig. Technisch gezien kun je wijzigingen pushen en pullen van individuele repositories, maar dat wordt afgeraden omdat je vrij gemakkelijk het werk waar anderen mee bezig zijn in de war kunt schoppen als je niet oppast. Daarnaast wil je dat je medewerkers de repository kunnen bereiken, zelfs als jouw computer van het netwerk is; het hebben van een betrouwbare gezamenlijke repository is vaak handig. De voorkeursmethode om met iemand samen te werken is om een tussenliggende repository in te richten waar beide partijen toegang tot hebben en om daar naartoe te pushen en vandaan te pullen. We zullen deze repository de "Git server" noemen, maar je zult zien dat het over het algemeen maar weinig systeembronnen kost om een Git repository te verzorgen, dus je zult er zelden een complete server voor nodig hebben.
diff --git a/nl/05-distributed-git/01-chapter5.markdown b/nl/05-distributed-git/01-chapter5.markdown
index 6ce3eb1ac..9baad756a 100644
--- a/nl/05-distributed-git/01-chapter5.markdown
+++ b/nl/05-distributed-git/01-chapter5.markdown
@@ -33,6 +33,7 @@ vertaling moeten proberen te maken.
 
 Veel succes en plezier bij het vertalen...
 -->
+<!-- SHA-1 of last checked en-version: fbf24105 -->
 # Gedistribueerd Git #
 
 Nu je een remote Git repository hebt ingesteld als een plaats waar alle ontwikkelaars hun code kunnen delen, en je bekend bent met fundamentele Git commando's in een lokale workflow, zul je hier zien hoe je een paar gedistribueerde workflows kunt gebruiken die je met Git kunt bereiken.
diff --git a/nl/06-git-tools/01-chapter6.markdown b/nl/06-git-tools/01-chapter6.markdown
index dbde96ed1..292ddbb42 100644
--- a/nl/06-git-tools/01-chapter6.markdown
+++ b/nl/06-git-tools/01-chapter6.markdown
@@ -33,6 +33,7 @@ vertaling moeten proberen te maken.
 
 Veel succes en plezier bij het vertalen...
 -->
+<!-- SHA-1 of last checked en-version: fbf24105 -->
 # Git tools #
 
 Nu heb je de meeste commando's en werkwijzen geleerd die je dagelijks nodig hebt om een Git repository voor je broncode te beheren en te onderhouden. Je hebt de basistaken van het tracken en committen van bestanden onder de knie, en je hebt de kracht van de staging area en lichtgewicht topic branching en mergen in de vingers.
diff --git a/nl/07-customizing-git/01-chapter7.markdown b/nl/07-customizing-git/01-chapter7.markdown
index 56e41bea1..03feaf471 100644
--- a/nl/07-customizing-git/01-chapter7.markdown
+++ b/nl/07-customizing-git/01-chapter7.markdown
@@ -33,6 +33,7 @@ vertaling moeten proberen te maken.
 
 Veel succes en plezier bij het vertalen...
 -->
+<!-- SHA-1 of last checked en-version: fbf24105 -->
 # Git op maat maken #
 
 Tot zover heb ik de fundamentele werking van Git behandeld en hoe het te gebruiken, en ik heb een aantal tools geïntroduceerd die Git tot je beschikking stelt om je het makkelijk en efficiënt te laten gebruiken. In dit hoofdstuk zal ik wat operaties doorlopen die je kunt gebruiken om Git op een maat gemaakte manier te laten werken middels het introduceren van een aantal belangrijke configuratie-instellingen en het inhaak-systeem (hooks). Met deze tools is het makkelijk om Git precies te laten werken op de manier zoals jij, je bedrijf, of je groep het nodig hebben.
diff --git a/nl/08-git-and-other-scms/01-chapter8.markdown b/nl/08-git-and-other-scms/01-chapter8.markdown
index 7d551d94d..32e0b9ccd 100644
--- a/nl/08-git-and-other-scms/01-chapter8.markdown
+++ b/nl/08-git-and-other-scms/01-chapter8.markdown
@@ -1,3 +1,39 @@
+<!-- Attentie heren en dames vertalers.
+Ik zou het volgende willen voorstellen:
+Er zijn bepaalde termen die voor de gemiddelde Nederlandse computer gebruiker 
+veel beter klinken (of bekender voorkomen) als de orginele Engelse term. In het
+begin zullen deze termen niet vaak voorkomen, maar in de meer diepgaandere 
+hoofdstukken komen deze steeds meer voor. Termen als "Committen", "Mergen" 
+en "Applyen" klinken beter dan "Plegen" of "Toepassen", "Samenvoegen" en 
+"Toepassen" (wat bovendien slecht valt te onderscheiden van de 
+commit-toepassing). De mensen die dit boek lezen zijn, naar mijn bescheiden 
+inschatting, al redelijk op de hoogte van versiebeheer en passen (zie ik in 
+de praktijk) deze termen al toe. Een nieuwe terminologie introduceren lijkt 
+me dan ook niet noodzakelijk.
+Verder blijven er altijd kreten over als "directory", wat vertaald zou kunnen 
+worden als "map", maar bij het Engelse werkwoord to map krijgen we dan weer het
+probleem: hoe dit weer te vertalen? Daarom zou ik willen voorstellen om deze 
+basis-termen toch onvertaald te laten.
+
+Twijfelgevallen zullen altijd blijven zoals de term "file", daarvan wordt in de
+praktijk zowel de term file als bestand gebruikt. Ik denk dat we hier moeten 
+kijken hoe het in de context past. 
+Maar ook een term als "tool" en (ik zit zelf nog op een mooie Nederlandse term
+te broeden) "plumbing", hierbij stel ik voor om eenmalig een Nederlandse 
+vertaling te geven, tussen haakjes de Engelse term te geven en in het vervolg
+de Engelse term te gebruiken. Wederom is de context hier belangrijk.
+
+Verder stel ik ook voor om de regels op https://onzetaal.nl/taaladvies zoveel
+mogelijk te volgen. Bijvoorbeeld de regels omtrent het spellen van Engelse 
+werkwoorden die in het Nederlands gebruikt worden.
+
+Let wel: ik wil niemand tot iets verplichten, maar ik denk dat we moeten 
+streven naar een zo duidelijk mogelijke en best bij de praktijk aansluitende
+vertaling moeten proberen te maken.
+
+Veel succes en plezier bij het vertalen...
+-->
+<!-- SHA-1 of last checked en-version: fbf24105 -->
 # Git en andere systemen #
 
 Het is geen perfecte wereld. Meestal kan je niet meteen elk project waar je mee in aanraking komt omzetten naar Git. Soms zit je vast op een project dat een ander VCS gebruikt, en vaak is dat systeem Subversion. In het eerste gedeelte van dit hoofdstuk zal je leren over `git svn`, het bidirectionele Subversion uitwissel tool van Git.
@@ -152,7 +188,7 @@ Als je met andere developers samenwerkt, dan zal op een bepaald moment één van
 	out-of-date: resource out of date; try updating at /Users/schacon/libexec/git-\
 	core/git-svn line 482
 
-Om deze situatie op te lossen moet je `git svn rebase` uitvoeren waardoor alle wijzigingen op de server die je nog niet hebt worden gepulled, en daarna al het werk dat je hebt bovenop wat op de server staat rebased:
+Om deze situatie op te lossen moet je `git svn rebase` uitvoeren waardoor alle wijzigingen op de server die je nog niet hebt worden gepullt, en daarna al het werk dat je hebt bovenop wat op de server staat rebased:
 
 	$ git svn rebase
 	       M      README.txt
diff --git a/nl/09-git-internals/01-chapter9.markdown b/nl/09-git-internals/01-chapter9.markdown
index d3aeb6daa..51c798a3f 100644
--- a/nl/09-git-internals/01-chapter9.markdown
+++ b/nl/09-git-internals/01-chapter9.markdown
@@ -33,6 +33,7 @@ vertaling moeten proberen te maken.
 
 Veel succes en plezier bij het vertalen...
 -->
+<!-- SHA-1 of last checked en-version: fbf24105 -->
 # Het binnenwerk van Git #
 
 Je zult misschien naar dit hoofdstuk gesprongen zijn vanuit een voorafgaand hoofdstuk, of je zult hier gekomen zijn nadat je de rest van het boek gelezen hebt; hoe dan ook, hier is waar het binnenwerk en implementatie van Git behandeld gaat worden. Ik heb gemerkt dat het leren van deze informatie van fundamenteel belang is om te begrijpen hoe bruikbaar en krachtig Git is, maar anderen hebben daar tegenin gebracht dat het erg verwarrend en onnodig complex kan zijn voor beginners. Daarom heb ik de behandeling hiervan het laatste hoofdstuk gemaakt in het boek, zodat je kunt besluiten om het het vroeg of later in je leerproces kunt lezen. Ik laat het aan jou over om dat te beslissen.

From 0cda11e8d173d6c72be9ac6fb18f192ef1e5d079 Mon Sep 17 00:00:00 2001
From: Cloud <biluncloud@gmail.com>
Date: Thu, 27 Feb 2014 11:30:47 +0800
Subject: [PATCH 247/690] [zh] Update Chapter 5

---
 zh/05-distributed-git/01-chapter5.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/zh/05-distributed-git/01-chapter5.markdown b/zh/05-distributed-git/01-chapter5.markdown
index 772774948..34c49e34e 100644
--- a/zh/05-distributed-git/01-chapter5.markdown
+++ b/zh/05-distributed-git/01-chapter5.markdown
@@ -863,7 +863,7 @@ Insert 18333fig0527.png
 
 ### 生成内部版本号 ###
 
-因为Git不会为每次提交自动附加类似'v123'的递增序列，所以如果你想要得到一个便于理解的提交号可以运行`git describe`命令。Git将会返回一个字符串，由三部分组成：最近一次标定的版本号，加上自那次标定之后的提交次数，再加上一段SHA-1值of the commit you’re describing：
+因为Git不会为每次提交自动附加类似'v123'的递增序列，所以如果你想要得到一个便于理解的提交号可以运行`git describe`命令。Git将会返回一个字符串，由三部分组成：最近一次标定的版本号，加上自那次标定之后的提交次数，再加上一段所描述的提交的SHA-1值：
 
 	$ git describe master
 	v1.6.2-rc1-20-g8c5b85c

From 947da8c21f9c8023b27b55dfdc13e6c382c04e22 Mon Sep 17 00:00:00 2001
From: Petr Prikryl <prikryl@atlas.cz>
Date: Thu, 27 Feb 2014 14:52:11 +0100
Subject: [PATCH 248/690] [cs] changes to Chapter 1, section 1.4

---
 cs/01-introduction/01-chapter1.markdown | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/cs/01-introduction/01-chapter1.markdown b/cs/01-introduction/01-chapter1.markdown
index b1b60c735..7ded7793c 100644
--- a/cs/01-introduction/01-chapter1.markdown
+++ b/cs/01-introduction/01-chapter1.markdown
@@ -3,7 +3,7 @@
 Tato kapitola vám ve stručnosti představí systém Git. Začneme od samého začátku. Nahlédneme do historie nástrojů ke správě verzí, poté se budeme věnovat tomu, jak spustit systém Git ve vašem počítači, a nakonec se podíváme na možnosti úvodního nastavení. V této kapitole se dozvíte, k čemu Git slouží a proč byste ho měli používat. Kromě toho se také naučíte, jak Git nastavit podle svých potřeb.
 
 ## Správa verzí ##
-hi
+
 Co je to správa verzí a proč by vás měla zajímat? Správa verzí je systém, který zaznamenává změny souboru nebo sady souborů v průběhu času, a uživatel tak může kdykoli obnovit jeho/jejich konkrétní verzi (tzv. verzování). Příklady verzovaných souborů jsou v této knize ilustrovány na zdrojovém kódu softwaru, avšak ve skutečnosti lze verzování provádět téměř se všemi typy souborů v počítači.
 
 Pokud jste grafik nebo webdesigner a chcete uchovávat všechny verze obrázku nebo všechna rozložení stránky (což jistě není k zahození), je pro vás systém správy verzí (zkráceně VCS z angl. Version Control System) ideálním nástrojem. VCS umožňuje vrátit jednotlivé soubory nebo celý projekt do předchozího stavu, porovnávat změny provedené v průběhu času, zjistit, kdo naposledy upravil něco, co nyní možná způsobuje problémy, kdo vložil jakou verzi a kdy a mnoho dalšího. Používáte-li verzovací systém, většinou to také znamená, že snadno obnovíte soubory, které jste ztratili nebo v nichž byly provedeny nežádoucí změny. Všechny funkcionality verzovacího systému můžete navíc používat velice jednoduchým způsobem.
@@ -120,13 +120,13 @@ Nachází-li se konkrétní verze souboru v adresáři Git, je považována za z
 
 ## Instalace systému Git ##
 
-Je načase začít systém Git aktivně používat. Instalaci můžete provést celou řadou způsobů — obvyklá je instalace ze zdrojových souborů nebo instalace existujícího balíčku, určeného pro vaši platformu.
+Je načase začít systém Git aktivně používat. Instalaci můžete provést celou řadou způsobů. Většinou se využívá buď instalace ze zdrojových souborů, nebo instalace z existujícího balíčku, určeného pro vaši platformu.
 
 ### Instalace ze zdrojových souborů ###
 
-Pokud je to možné, je nejvhodnější instalovat Git ze zdrojových souborů. Tak je zaručeno, že vždy získáte aktuální verzi. Každá další verze systému se snaží přidat nová vylepšení uživatelského rozhraní. Použití poslední verze je tedy zpravidla tou nejlepší cestou, samozřejmě pokud vám nedělá problémy kompilace softwaru ze zdrojových souborů.
+Pokud je to možné, je nejvhodnější instalovat Git ze zdrojových souborů. Tak je zaručeno, že vždy získáte aktuální verzi. Každá další verze systému se snaží přidat nová vylepšení uživatelského rozhraní. Použití poslední verze je tedy zpravidla tou nejlepší cestou, samozřejmě pokud vám nedělá problémy kompilace softwaru ze zdrojových souborů. Skutečností také je, že mnoho linuxových distribucí obsahuje velmi staré balíčky. Takže pokud nepoužíváte velmi čerstvou distribuci, nebo pokud záměrně používáte starší verzi, bývá instalace ze zdrojových souborů nejlepší volbou.
 
-Před instalcí samotného Gitu musí váš systém obsahovat následující knihovny, na nichž je Git závislý: curl, zlib, openssl, expat, a libiconv. Pokud používáte yum (např. Fedora) nebo apt-get (např. distribuce založené na Debianu), můžete k instalaci použít jeden z následujících příkazů:
+Před instalací samotného Gitu musí váš systém obsahovat následující knihovny, na nichž je Git závislý: curl, zlib, openssl, expat, a libiconv. Pokud používáte systém s nástrojem yum (například u distribuce Fedora) nebo apt-get (například distribuce odvozené od Debianu), můžete k instalaci použít jeden z následujících příkazů:
 
 	$ yum install curl-devel expat-devel gettext-devel \
 	  openssl-devel zlib-devel
@@ -138,7 +138,7 @@ Po doinstalování všech potřebných závislostí můžete pokračovat stažen
 
 	http://git-scm.com/download
 
-Poté přistupte ke kompilaci a instalaci:
+Poté spusťte kompilaci a instalaci:
 
 	$ tar -zxf git-1.7.2.2.tar.gz
 	$ cd git-1.7.2.2
@@ -151,11 +151,11 @@ Po dokončení instalace můžete rovněž vyhledat aktualizace systému Git pro
 
 ### Instalace v Linuxu ###
 
-Chcete-li nainstalovat Git v Linuxu pomocí binárního instalátoru, většinou tak můžete učinit pomocí základního nástroje pro správu balíčků, který byl součástí vaší distribuce. Ve Fedoře můžete použít nástroj yum:
+Chcete-li nainstalovat Git v Linuxu pomocí binárního instalátoru, většinou tak můžete učinit pomocí základního nástroje pro správu balíčků, který je součástí vaší distribuce. Ve Fedoře můžete použít nástroj yum:
 
 	$ yum install git-core
 
-V distribuci založené na Debianu (např. Ubuntu) zkuste použít program apt-get:
+V distribuci založené na Debianu (jako je například Ubuntu) zkuste použít program apt-get:
 
 	$ apt-get install git
 

From 77cce999f6025c7e3d0728bd54e91e1da62b1557 Mon Sep 17 00:00:00 2001
From: Changwoo Ryu <cwryu@debian.org>
Date: Sun, 2 Mar 2014 12:12:54 +0900
Subject: [PATCH 249/690] Fix typos

---
 ko/02-git-basics/01-chapter2.markdown         | 2 +-
 ko/03-git-branching/01-chapter3.markdown      | 2 +-
 ko/04-git-server/01-chapter4.markdown         | 4 ++--
 ko/05-distributed-git/01-chapter5.markdown    | 2 +-
 ko/06-git-tools/01-chapter6.markdown          | 6 +++---
 ko/08-git-and-other-scms/01-chapter8.markdown | 4 ++--
 ko/09-git-internals/01-chapter9.markdown      | 2 +-
 7 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/ko/02-git-basics/01-chapter2.markdown b/ko/02-git-basics/01-chapter2.markdown
index 9353c88e3..5bf08bdfa 100644
--- a/ko/02-git-basics/01-chapter2.markdown
+++ b/ko/02-git-basics/01-chapter2.markdown
@@ -908,7 +908,7 @@ Git으로 커밋한 모든 것은 언제나 복구할 수 있다. 삭제한 브
 	v0.1
 	v1.3
 
-이 명령은 알파벳 순서로 태그을 보여준다. 사실 순서는 별로 중요한 게 아니다.
+이 명령은 알파벳 순서로 태그를 보여준다. 사실 순서는 별로 중요한 게 아니다.
 
 검색 패턴을 사용하여 태그를 검색할 수 있다. Git 소스 저장소는 240여 개의 태그가 있다. 만약 1.4.2 버전의 태그들만 검색하고 싶으면 아래와 같이 실행한다:
 
diff --git a/ko/03-git-branching/01-chapter3.markdown b/ko/03-git-branching/01-chapter3.markdown
index 9a66a6841..cf5dade52 100644
--- a/ko/03-git-branching/01-chapter3.markdown
+++ b/ko/03-git-branching/01-chapter3.markdown
@@ -2,7 +2,7 @@
 
 모든 버전 관리 시스템은 브랜치를 지원한다. 개발을 하다 보면 코드를 여러 개로 복사해야 하는 일이 자주 생긴다. 코드를 통째로 복사하고 나서 원래 코드와는 상관없이 독립적으로 개발을 진행할 수 있는데, 이렇게 독립적으로 개발하는 것이 브랜치다.
 
-버전 관리 시스템에서 브랜치를 만드는 과정은 고생스럽다. 개발자가 수동으로 소스코드 디렉토리를 복사해서 브랜치를 만들어야 하고 소스코드의 양이 많으면 브린채를 만드는 시간도 오래 걸린다.
+버전 관리 시스템에서 브랜치를 만드는 과정은 고생스럽다. 개발자가 수동으로 소스코드 디렉토리를 복사해서 브랜치를 만들어야 하고 소스코드의 양이 많으면 브랜치를 만드는 시간도 오래 걸린다.
 
 사람들은 브랜치 모델이 Git의 최고의 장점이라고, Git이 다른 것들과 구분되는 특징이라고 말한다. 당최 어떤 점이 그렇게 특별한 것일까? Git의 브랜치는 매우 가볍다. 순식간에 브랜치를 새로 만들고 브랜치 사이를 이동할 수 있다. 다른 버전 관리 시스템과는 달리 Git은 브랜치를 만들어 작업하고 나중에 Merge하는 방법을 권장한다. 심지어 하루에 수십 번씩해도 괜찮다. Git 브랜치에 능숙해지면 개발 방식이 완전히 바뀌고 다른 도구를 사용할 수 없게 된다.
 
diff --git a/ko/04-git-server/01-chapter4.markdown b/ko/04-git-server/01-chapter4.markdown
index 2755518da..9917fd92b 100644
--- a/ko/04-git-server/01-chapter4.markdown
+++ b/ko/04-git-server/01-chapter4.markdown
@@ -12,7 +12,7 @@ Git 서버를 운영하는 것은 어렵지 않다. 우선 사용할 전송 프
 
 Git은 Local, SSH, Git, HTTP 이렇게 네 가지의 네트워크 프로토콜을 사용할 수 있다. 이 절에서는 각각 어떤 경우에 유용한지 살펴볼 것이다.
 
-HTTP 프로토콜를 제외한 나머지들은 모두 Git이 서버에 설치돼 있어야 한다.
+HTTP 프로토콜을 제외한 나머지들은 모두 Git이 서버에 설치돼 있어야 한다.
 
 ### 로컬 프로토콜 ###
 
@@ -482,7 +482,7 @@ Gitosis의 접근제어 방법은 매우 단순하다. 만약 이 프로젝트
 	readonly = iphone_project
 	members = john
 
-이제 John은 프로젝트를 Clone하거나 Fetch할 수는 있지만, 프로젝트에 Push할 수는 없다. 다양한 사용자와 프로젝트가 있어도 필요한 만큼 그룹을 만들어 사용하면 된다. 그리고 members 항목에 사용자 대신 그룹명을 사용할 수도 있다. 그룹명 앞에 `@`를 붙이면 그 그룹의 사용자을 그대로 상속한다:
+이제 John은 프로젝트를 Clone하거나 Fetch할 수는 있지만, 프로젝트에 Push할 수는 없다. 다양한 사용자와 프로젝트가 있어도 필요한 만큼 그룹을 만들어 사용하면 된다. 그리고 members 항목에 사용자 대신 그룹명을 사용할 수도 있다. 그룹명 앞에 `@`를 붙이면 그 그룹의 사용자를 그대로 상속한다:
 
 	[group mobile_committers]
 	members = scott josie jessica
diff --git a/ko/05-distributed-git/01-chapter5.markdown b/ko/05-distributed-git/01-chapter5.markdown
index c1ea7508a..11ec5df3c 100644
--- a/ko/05-distributed-git/01-chapter5.markdown
+++ b/ko/05-distributed-git/01-chapter5.markdown
@@ -466,7 +466,7 @@ Insert 18333fig0518.png
 
 ### 대규모 공개 프로젝트 ###
 
-대규모 프로젝트은 보통 수정사항이나 Patch를 수용하는 자신만의 규칙을 마련해놓고 있다. 프로젝트마다 규칙은 서로 다를 수 있으므로 각 프로젝트의 규칙을 미리 알아둘 필요가 있다. 대규모 프로젝트는 대부분 메일링리스트를 통해서 Patch를 받아들이는데 예제를 통해 살펴본다.
+대규모 프로젝트는 보통 수정사항이나 Patch를 수용하는 자신만의 규칙을 마련해놓고 있다. 프로젝트마다 규칙은 서로 다를 수 있으므로 각 프로젝트의 규칙을 미리 알아둘 필요가 있다. 대규모 프로젝트는 대부분 메일링리스트를 통해서 Patch를 받아들이는데 예제를 통해 살펴본다.
 
 토픽 브랜치를 만들어 수정하는 작업은 앞서 살펴본 바와 거의 비슷하지만, Patch를 제출하는 방식이 다르다. 프로젝트를 Fork 하여 Push하는 것이 아니라 커밋 내용을 메일로 만들어 개발자 메일링리스트에 제출한다:
 
diff --git a/ko/06-git-tools/01-chapter6.markdown b/ko/06-git-tools/01-chapter6.markdown
index 1af11f6b2..af810484d 100644
--- a/ko/06-git-tools/01-chapter6.markdown
+++ b/ko/06-git-tools/01-chapter6.markdown
@@ -223,7 +223,7 @@ Double Dot으로는 세 개 이상의 레퍼런스에 사용할 수 없지만 
 	$ git log refA refB ^refC
 	$ git log refA refB --not refC
 
-이 조건을 잘 응용하면 작업 중인 브랜치와 다른 브랜치을 매우 상세하게 비교할 수 있다.
+이 조건을 잘 응용하면 작업 중인 브랜치와 다른 브랜치를 매우 상세하게 비교할 수 있다.
 
 #### Triple Dot ####
 
@@ -987,9 +987,9 @@ Merge해서 서브모듈의 HEAD 값이 변경됐다. 슈퍼프로젝트가 아
 
 ### 슈퍼프로젝트 ###
 
-프로젝트 규모가 크면 CVS나 Subversion에서는 모듈 프로젝트을 간단히 하위 디렉토리로 만들었다. 가끔 Git에서도 이런 Workflow을 사용하려는 개발자들이 있다.
+프로젝트 규모가 크면 CVS나 Subversion에서는 모듈 프로젝트를 간단히 하위 디렉토리로 만들었다. 가끔 Git에서도 이런 Workflow을 사용하려는 개발자들이 있다.
 
-Git에서는 각 하위 디렉토리를 별도의 Git 저장소로 만들어야 한다. 그리고 그 저장소을 포함하는 상위 저장소를 만든다. 슈퍼프로젝트의 태그와 브랜치를 이용해서 각 프로젝트의 관계를 구체적으로 정의할 수 있다는 것은 Git만의 장점이다.
+Git에서는 각 하위 디렉토리를 별도의 Git 저장소로 만들어야 한다. 그리고 그 저장소를 포함하는 상위 저장소를 만든다. 슈퍼프로젝트의 태그와 브랜치를 이용해서 각 프로젝트의 관계를 구체적으로 정의할 수 있다는 것은 Git만의 장점이다.
 
 ### 서브모듈 사용할 때 주의할 점들 ###
 
diff --git a/ko/08-git-and-other-scms/01-chapter8.markdown b/ko/08-git-and-other-scms/01-chapter8.markdown
index 307c1a6d4..9ad050838 100644
--- a/ko/08-git-and-other-scms/01-chapter8.markdown
+++ b/ko/08-git-and-other-scms/01-chapter8.markdown
@@ -16,7 +16,7 @@ Git과 Subversion을 이어주는 명령은 `git svn` 으로 시작한다. 이 
 
 `git svn` 명령을 사용할 때는 절름발이인 Subversion을 사용하고 있다는 점을 염두하자. 우리가 로컬 브랜치와 Merge를 맘대로 쓸 수 있다고 하더라도 최대한 일직선으로 히스토리를 유지하는것이 좋다. Git 저장소처럼 사용하지 않는다.
 
-히스토리를 재작성해서 Push하지 말아야 한다. Git을 사용하는 동료들끼기 따로 Git 저장소에 Push하지도 말아야 한다. Subversion은 단순하게 일직선 히스토리만 가능하다. 팀원중 일부는 SVN을 사용하고 일부는 Git을 사용하는 팀이라면 SVN Server를 사용해서 협업하는 것이 좋다. 그래야 삶이 편해진다.
+히스토리를 재작성해서 Push하지 말아야 한다. Git을 사용하는 동료들끼리 따로 Git 저장소에 Push하지도 말아야 한다. Subversion은 단순하게 일직선 히스토리만 가능하다. 팀원중 일부는 SVN을 사용하고 일부는 Git을 사용하는 팀이라면 SVN Server를 사용해서 협업하는 것이 좋다. 그래야 삶이 편해진다.
 
 ### 설정하기 ###
 
@@ -551,7 +551,7 @@ Mark는 정수 값을 사용해야 하기 때문에 디렉토리를 배열에 
 
 	$author = 'Scott Chacon <schacon@example.com>'
 
-이제 Importer에서 출력할 커밋 데이터는 다 준비했다. 이제 출력해보자. 사용할 브랜치, 해당 커밋과 관련된 Mark, 커미터 정보, 커밋 메시지, 이전 커밋를 출력한다. 코드로 만들면 아래와 같다:
+이제 Importer에서 출력할 커밋 데이터는 다 준비했다. 이제 출력해보자. 사용할 브랜치, 해당 커밋과 관련된 Mark, 커미터 정보, 커밋 메시지, 이전 커밋을 출력한다. 코드로 만들면 아래와 같다:
 
 	# print the import information
 	puts 'commit refs/heads/master'
diff --git a/ko/09-git-internals/01-chapter9.markdown b/ko/09-git-internals/01-chapter9.markdown
index fcf02085b..a30e480e8 100644
--- a/ko/09-git-internals/01-chapter9.markdown
+++ b/ko/09-git-internals/01-chapter9.markdown
@@ -453,7 +453,7 @@ Git은 zlib으로 파일 내용을 압축하기 때문에 저장 공간이 많
 	$ du -b .git/objects/9b/c1dc421dcd51b4ac296e3e5b6e2a99cf44391e
 	4102	.git/objects/9b/c1dc421dcd51b4ac296e3e5b6e2a99cf44391e
 
-피일을 수정하면 어떻게 되는지 살펴보자:
+파일을 수정하면 어떻게 되는지 살펴보자:
 
 	$ echo '# testing' >> repo.rb
 	$ git commit -am 'modified repo a bit'

From 56f07bb0f266d7cebd93d567ff1986401441dcc6 Mon Sep 17 00:00:00 2001
From: "J.M" <jm@jublo.net>
Date: Mon, 3 Mar 2014 16:59:56 +0100
Subject: [PATCH 250/690] [de] Drop trailing spaces

---
 de/README.md | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/de/README.md b/de/README.md
index 2f13c8319..a8d214960 100644
--- a/de/README.md
+++ b/de/README.md
@@ -1,3 +1,5 @@
+[![Build-Status](https://secure.travis-ci.org/progit-de/progit.png?branch=master)](https://travis-ci.org/progit-de/progit)
+
 # Deutsche Übersetzung #
 
 Die deutsche Übersetzung wird im Repository progit-de/progit verwaltet. Wenn Du an der deutschen Übersetzung mitarbeiten willst, dann melde Dich am besten bei uns. Du kannst dazu einen Issue im Repository progit-de/progit erzeugen. Wir werden Dir dann einen Vorschlag machen, wie Du uns am besten helfen kannst. Der Workflow an sich ist unter Workflow beschrieben. Ein Status der Übersetzung der jeweiligen Kapitel findest Du unter "Status der Übersetzung".

From 6cf2d9f19cf807c41a5a00ebf620440953de5203 Mon Sep 17 00:00:00 2001
From: "J.M" <jm@jublo.net>
Date: Mon, 3 Mar 2014 17:00:13 +0100
Subject: [PATCH 251/690] [de] Apply changes from 'en' original

---
 de/03-git-branching/01-chapter3.markdown | 18 +++++++++---------
 de/06-git-tools/01-chapter6.markdown     |  6 +++---
 2 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/de/03-git-branching/01-chapter3.markdown b/de/03-git-branching/01-chapter3.markdown
index 743e42ed4..64f804ed6 100644
--- a/de/03-git-branching/01-chapter3.markdown
+++ b/de/03-git-branching/01-chapter3.markdown
@@ -179,12 +179,12 @@ Lass uns das Ganze an einem Beispiel durchgehen, dessen Workflow zum Thema Branc
 
 In diesem Augenblick kommt ein Anruf, dass ein kritisches Problem aufgetreten ist und sofort gelöst werden muss. Du machst folgendes:
 
-<!--1. Revert back to your production branch.-->
+<!--1. Switch back to your production branch.-->
 <!--2. Create a branch to add the hotfix.-->
 <!--3. After it’s tested, merge the hotfix branch, and push to production.-->
 <!--4. Switch back to your original story and continue working.-->
 
-1. Geh zurück zu Deinem „Produktiv“-Zweig.
+1. Schalte zurück zu Deinem „Produktiv“-Zweig.
 2. Erstelle eine Branch für den Hotfix.
 3. Nach dem Testen führst Du den Hotfix-Branch mit dem „Produktiv“-Branch zusammen.
 4. Schalte wieder auf Deine alte Arbeit zurück und werkel weiter.
@@ -381,12 +381,12 @@ Git hat hier keinen 'merge commit' erstellt. Es hat den Prozess gestoppt, damit
 	On branch master
 	You have unmerged paths.
 	  (fix conflicts and run "git commit")
-	
+
 	Unmerged paths:
 	  (use "git add <file>..." to mark resolution)
-	
+
 	        both modified:      index.html
-	
+
 	no changes added to commit (use "git add" and/or "git commit -a")
 
 <!--Anything that has merge conflicts and hasn’t been resolved is listed as unmerged. Git adds standard conflict-resolution markers to the files that have conflicts, so you can open them manually and resolve those conflicts. Your file contains a section that looks something like this:-->
@@ -429,9 +429,9 @@ Wenn Du ein grafischen Tool zur Bereinigung benutzen willst, dann verwende `git
 	  {remote}: modified file
 	Hit return to start merge resolution tool (opendiff):
 
-<!--If you want to use a merge tool other than the default (Git chose `opendiff` for me in this case because I ran the command on a Mac), you can see all the supported tools listed at the top after “merge tool candidates”. Type the name of the tool you’d rather use. In Chapter 7, we’ll discuss how you can change this default value for your environment.-->
+<!--If you want to use a merge tool other than the default (Git chose `opendiff` for me in this case because I ran the command on a Mac), you can see all the supported tools listed at the top after “... one of the following tools:”. Type the name of the tool you’d rather use. In Chapter 7, we’ll discuss how you can change this default value for your environment.-->
 
-Wenn Du ein anderes Tool anstelle des Standardwerkzeug für ein 'merge' verwenden möchtest (Git verwendet in meinem Fall `opendiff`, da ich auf einem Mac arbeite), dann kannst Du alle unterstützten Werkzeuge oben – neben „merge tool candidates“ – aufgelistet sehen. Tippe einfach den Namen Deines gewünschten Werkzeugs ein. In Kapitel 7 besprechen wir, wie Du diesen Standardwert in Deiner Umgebung dauerhaft ändern kannst.
+Wenn Du ein anderes Tool anstelle des Standardwerkzeug für ein 'merge' verwenden möchtest (Git verwendet in meinem Fall `opendiff`, da ich auf einem Mac arbeite), dann kannst Du alle unterstützten Werkzeuge oben – unter „one of the following tools“ – aufgelistet sehen. Tippe einfach den Namen Deines gewünschten Werkzeugs ein. In Kapitel 7 besprechen wir, wie Du diesen Standardwert in Deiner Umgebung dauerhaft ändern kannst.
 
 <!--After you exit the merge tool, Git asks you if the merge was successful. If you tell the script that it was, it stages the file to mark it as resolved for you.-->
 
@@ -445,9 +445,9 @@ Du kannst `git status` erneut ausführen, um zu sehen, ob alle Konflikte gelöst
 	On branch master
 	Changes to be committed:
 	  (use "git reset HEAD <file>..." to unstage)
-	
+
 	        modified:   index.html
-	
+
 
 <!--If you’re happy with that, and you verify that everything that had conflicts has been staged, you can type `git commit` to finalize the merge commit. The commit message by default looks something like this:-->
 
diff --git a/de/06-git-tools/01-chapter6.markdown b/de/06-git-tools/01-chapter6.markdown
index aec049519..98c837256 100644
--- a/de/06-git-tools/01-chapter6.markdown
+++ b/de/06-git-tools/01-chapter6.markdown
@@ -86,9 +86,9 @@ Eine Menge Leute machen sich Sorgen, dass ab einem zufälligen Punkt zwei Objekt
 
 Wenn es passiert, dass bei einem Commit, ein Objekt mit dem gleichen SHA-1-Hashwert im Repository vorhanden ist, wird Git sehen, dass das vorherige Objekt bereits in der Datenbank vorhanden ist und davon ausgehen, dass es bereits geschrieben wurde. Wenn Du versuchst, das Objekt später wieder auszuchecken, wirst Du immer die Daten des ersten Objekts bekommen.
 
-<!--However, you should be aware of how ridiculously unlikely this scenario is. The SHA-1 digest is 20 bytes or 160 bits. The number of randomly hashed objects needed to ensure a 50% probability of a single collision is about 2^80 (the formula for determining collision probability is `p = (n(n-1)/2) * (1/2^160))`. 2^80 is 1.2 x 10^24 or 1 million billion billion. That’s 1,200 times the number of grains of sand on the earth.-->
+<!--However, you should be aware of how ridiculously unlikely this scenario is. The SHA-1 digest is 20 bytes or 160 bits. The number of randomly hashed objects needed to ensure a 50% probability of a single collision is about 2^80 (the formula for determining collision probability is `p = (n(n-1)/2) * (1/2^160)`). 2^80 is 1.2 x 10^24 or 1 million billion billion. That’s 1,200 times the number of grains of sand on the earth.-->
 
-Allerdings solltest Du Dir bewusst machen, wie unglaublich unwahrscheinlich dieses Szenario ist. Die Länge des SHA-1-Hashs beträgt 20 Bytes oder 160 Bits. Die Anzahl der Objekte, die benötigt werden, um eine 50% Chance einer Kollision zu haben, beträgt ungefähr 2^80 (die Formel zum Berechnen der Kollisionswahrscheinlichkeit lautet `p = (n(n-1)/2) * (1/2^160))`. 2^80 ist somit 1.2 x 10^24 oder eine Trilliarde. Das ist 1200 Mal so viel, wie es Sandkörner auf der Erde gibt.
+Allerdings solltest Du Dir bewusst machen, wie unglaublich unwahrscheinlich dieses Szenario ist. Die Länge des SHA-1-Hashs beträgt 20 Bytes oder 160 Bits. Die Anzahl der Objekte, die benötigt werden, um eine 50% Chance einer Kollision zu haben, beträgt ungefähr 2^80 (die Formel zum Berechnen der Kollisionswahrscheinlichkeit lautet `p = (n(n-1)/2) * (1/2^160)`). 2^80 ist somit 1.2 x 10^24 oder eine Trilliarde. Das ist 1200 Mal so viel, wie es Sandkörner auf der Erde gibt.
 
 <!--Here’s an example to give you an idea of what it would take to get a SHA-1 collision. If all 6.5 billion humans on Earth were programming, and every second, each one was producing code that was the equivalent of the entire Linux kernel history (1 million Git objects) and pushing it into one enormous Git repository, it would take 5 years until that repository contained enough objects to have a 50% probability of a single SHA-1 object collision. A higher probability exists that every member of your programming team will be attacked and killed by wolves in unrelated incidents on the same night.-->
 
@@ -655,7 +655,7 @@ An dieser Stelle noch einmal der Hinweis, dass Git den zuletzt erstellten Stash
 
     $ git stash show -p | git apply -R
 
-<!--You may want to create an alias and effectively add a `stash-unapply` command to your git. For example:-->
+<!--You may want to create an alias and effectively add a `stash-unapply` command to your Git. For example:-->
 
 Wenn Du dieses Feature öfters benötigst, ist es wahrscheinlich sinnvoll, einen Alias `stash-unapply` in Git dafür anzulegen:
 

From 3b9ba33a6ae587093ee878207d6fc77de121c149 Mon Sep 17 00:00:00 2001
From: ya_hsiung <ya_hsiung@yahoo.com>
Date: Thu, 6 Mar 2014 17:19:32 +0800
Subject: [PATCH 252/690] add 03-git-branching

---
 zh-tw/03-git-branching/01-chapter3.markdown | 604 ++++++++++++++++++++
 1 file changed, 604 insertions(+)
 create mode 100644 zh-tw/03-git-branching/01-chapter3.markdown

diff --git a/zh-tw/03-git-branching/01-chapter3.markdown b/zh-tw/03-git-branching/01-chapter3.markdown
new file mode 100644
index 000000000..ab6c7ca84
--- /dev/null
+++ b/zh-tw/03-git-branching/01-chapter3.markdown
@@ -0,0 +1,604 @@
+# Git 分支 #
+
+幾乎每一種版本控制系統都以某種形式支援分支。使用分支意味著你可以從開發主線上分離開來，然後在不影響主線的同時繼續工作。在很多版本控制系統中，這是個昂貴的過程，常常需要創建一個原始程式碼目錄的完整副本，對大型項目來說會花費很長時間。
+
+有人把 Git 的分支模型稱為“必殺技特性”，而正是因為它，將 Git 從版本控制系統家族裡區分出來。Git 有何特別之處呢？Git 的分支可謂是難以置信的羽量級，它的新建操作幾乎可以在瞬間完成，並且在不同分支間切換起來也差不多一樣快。和許多其他版本控制系統不同，Git 鼓勵在工作流程中頻繁使用分支與合併，哪怕一天之內進行許多次都沒有關係。理解分支的概念並熟練運用後，你才會意識到為什麼 Git 是一個如此強大而獨特的工具，並從此真正改變你的開發方式。
+
+## 何謂分支 ##
+
+為了理解 Git 分支的實現方式，我們需要回顧一下 Git 是如何儲存資料的。或許你還記得第一章的內容，Git 保存的不是檔差異或者變化量，而只是一系列檔快照。
+
+在 Git 中提交時，會保存一個提交（commit）物件，該物件包含一個指向暫存內容快照的指標，包含本次提交的作者等相關附屬資訊，包含零個或多個指向該提交物件的父物件指標：首次提交是沒有直接祖先的，普通提交有一個祖先，由兩個或多個分支合併產生的提交則有多個祖先。
+
+為直觀起見，我們假設在工作目錄中有三個檔，準備將它們暫存後提交。暫存操作會對每一個檔計算校驗和（即第一章中提到的 SHA-1 雜湊字串），然後把當前版本的檔快照保存到 Git 倉庫中（Git 使用 blob 類型的物件存儲這些快照），並將校驗和加入暫存區域：
+
+	$ git add README test.rb LICENSE
+	$ git commit -m 'initial commit of my project'
+
+當使用 `git commit` 新建一個提交物件前，Git 會先計算每一個子目錄（本例中就是專案根目錄）的校驗和，然後在 Git 倉庫中將這些目錄保存為樹（tree）物件。之後 Git 創建的提交物件，除了包含相關提交資訊以外，還包含著指向這個樹物件（專案根目錄）的指標，如此它就可以在將來需要的時候，重現此次快照的內容了。
+
+現在，Git 倉庫中有五個物件：三個表示檔快照內容的 blob 物件；一個記錄著目錄樹內容及其中各個檔對應 blob 物件索引的 tree 物件；以及一個包含指向 tree 物件（根目錄）的索引和其他提交資訊中繼資料的 commit 物件。概念上來說，倉庫中的各個物件保存的資料和相互關係看起來如圖 3-1 所示：
+
+Insert 18333fig0301.png
+圖 3-1. 單個提交物件在倉庫中的資料結構
+
+作些修改後再次提交，那麼這次的提交物件會包含一個指向上次提交物件的指標（譯注：即下圖中的 parent 物件）。兩次提交後，倉庫歷史會變成圖 3-2 的樣子：
+
+Insert 18333fig0302.png
+圖 3-2. 多個提交物件之間的連結關係
+
+現在來談分支。Git 中的分支，其實本質上僅僅是個指向 commit 物件的可變指標。Git 會使用 master 作為分支的預設名字。在若干次提交後，你其實已經有了一個指向最後一次提交物件的 master 分支，它在每次提交的時候都會自動向前移動。
+
+Insert 18333fig0303.png
+圖 3-3. 分支其實就是從某個提交物件往回看的歷史
+
+那么，Git 又是如何创建一个新的分支的呢？答案很简单，创建一个新的分支指针。比如新建一个 testing 分支，可以使用 `git branch` 命令：
+
+	$ git branch testing
+
+这会在当前 commit 对象上新建一个分支指针（见图 3-4）。
+
+Insert 18333fig0304.png
+图 3-4. 多个分支指向提交数据的历史
+
+那么，Git 是如何知道你当前在哪个分支上工作的呢？其实答案也很简单，它保存着一个名为 HEAD 的特别指针。请注意它和你熟知的许多其他版本控制系统（比如 Subversion 或 CVS）里的 HEAD 概念大不相同。在 Git 中，它是一个指向你正在工作中的本地分支的指针（译注：将 HEAD 想象为当前分支的别名。）。运行 `git branch` 命令，仅仅是建立了一个新的分支，但不会自动切换到这个分支中去，所以在这个例子中，我们依然还在 master 分支里工作（参考图 3-5）。
+
+Insert 18333fig0305.png
+图 3-5. HEAD 指向当前所在的分支
+
+要切换到其他分支，可以执行 `git checkout` 命令。我们现在转换到新建的 testing 分支：
+
+	$ git checkout testing
+
+这样 HEAD 就指向了 testing 分支（见图3-6）。
+
+Insert 18333fig0306.png
+图 3-6. HEAD 在你转换分支时指向新的分支
+
+这样的实现方式会给我们带来什么好处呢？好吧，现在不妨再提交一次：
+
+	$ vim test.rb
+	$ git commit -a -m 'made a change'
+
+图 3-7 展示了提交后的结果。
+
+Insert 18333fig0307.png
+图 3-7. 每次提交后 HEAD 随着分支一起向前移动
+
+非常有趣，现在 testing 分支向前移动了一格，而 master 分支仍然指向原先 `git checkout` 时所在的 commit 对象。现在我们回到 master 分支看看：
+
+	$ git checkout master
+
+图 3-8 显示了结果。
+
+Insert 18333fig0308.png
+图 3-8. HEAD 在一次 checkout 之后移动到了另一个分支
+
+这条命令做了两件事。它把 HEAD 指针移回到 master 分支，并把工作目录中的文件换成了 master 分支所指向的快照内容。也就是说，现在开始所做的改动，将始于本项目中一个较老的版本。它的主要作用是将 testing 分支里作出的修改暂时取消，这样你就可以向另一个方向进行开发。
+
+我们作些修改后再次提交：
+
+	$ vim test.rb
+	$ git commit -a -m 'made other changes'
+
+现在我们的项目提交历史产生了分叉（如图 3-9 所示），因为刚才我们创建了一个分支，转换到其中进行了一些工作，然后又回到原来的主分支进行了另外一些工作。这些改变分别孤立在不同的分支里：我们可以在不同分支里反复切换，并在时机成熟时把它们合并到一起。而所有这些工作，仅仅需要 `branch` 和 `checkout` 这两条命令就可以完成。
+
+Insert 18333fig0309.png
+图 3-9. 不同流向的分支历史
+
+由于 Git 中的分支实际上仅是一个包含所指对象校验和（40 个字符长度 SHA-1 字串）的文件，所以创建和销毁一个分支就变得非常廉价。说白了，新建一个分支就是向一个文件写入 41 个字节（外加一个换行符）那么简单，当然也就很快了。
+
+这和大多数版本控制系统形成了鲜明对比，它们管理分支大多采取备份所有项目文件到特定目录的方式，所以根据项目文件数量和大小不同，可能花费的时间也会有相当大的差别，快则几秒，慢则数分钟。而 Git 的实现与项目复杂度无关，它永远可以在几毫秒的时间内完成分支的创建和切换。同时，因为每次提交时都记录了祖先信息（译注：即 `parent` 对象），将来要合并分支时，寻找恰当的合并基础（译注：即共同祖先）的工作其实已经自然而然地摆在那里了，所以实现起来非常容易。Git 鼓励开发者频繁使用分支，正是因为有着这些特性作保障。
+
+接下来看看，我们为什么应该频繁使用分支。
+
+## 分支的新建与合并 ##
+
+现在让我们来看一个简单的分支与合并的例子，实际工作中大体也会用到这样的工作流程：
+
+1. 开发某个网站。
+2. 为实现某个新的需求，创建一个分支。
+3. 在这个分支上开展工作。
+
+假设此时，你突然接到一个电话说有个很严重的问题需要紧急修补，那么可以按照下面的方式处理：
+
+1. 返回到原先已经发布到生产服务器上的分支。
+2. 为这次紧急修补建立一个新分支，并在其中修复问题。
+3. 通过测试后，回到生产服务器所在的分支，将修补分支合并进来，然后再推送到生产服务器上。
+4. 切换到之前实现新需求的分支，继续工作。
+
+### 分支的新建与切换 ###
+
+首先，我们假设你正在项目中愉快地工作，并且已经提交了几次更新（见图 3-10）。
+
+Insert 18333fig0310.png
+图 3-10. 一个简短的提交历史
+
+现在，你决定要修补问题追踪系统上的 #53 问题。顺带说明下，Git 并不同任何特定的问题追踪系统打交道。这里为了说明要解决的问题，才把新建的分支取名为 iss53。要新建并切换到该分支，运行 `git checkout` 并加上 `-b` 参数：
+
+	$ git checkout -b iss53
+	Switched to a new branch 'iss53'
+
+这相当于执行下面这两条命令：
+
+	$ git branch iss53
+	$ git checkout iss53
+
+图 3-11 示意该命令的执行结果。
+
+Insert 18333fig0311.png
+图 3-11. 创建了一个新分支的指针
+
+接着你开始尝试修复问题，在提交了若干次更新后，`iss53` 分支的指针也会随着向前推进，因为它就是当前分支（换句话说，当前的 `HEAD` 指针正指向 `iss53`，见图 3-12）：
+
+	$ vim index.html
+	$ git commit -a -m 'added a new footer [issue 53]'
+
+Insert 18333fig0312.png
+图 3-12. iss53 分支随工作进展向前推进
+
+现在你就接到了那个网站问题的紧急电话，需要马上修补。有了 Git ，我们就不需要同时发布这个补丁和 `iss53` 里作出的修改，也不需要在创建和发布该补丁到服务器之前花费大力气来复原这些修改。唯一需要的仅仅是切换回 `master` 分支。
+
+不过在此之前，留心你的暂存区或者工作目录里，那些还没有提交的修改，它会和你即将检出的分支产生冲突从而阻止 Git 为你切换分支。切换分支的时候最好保持一个清洁的工作区域。稍后会介绍几个绕过这种问题的办法（分别叫做 stashing 和 commit amending）。目前已经提交了所有的修改，所以接下来可以正常转换到 `master` 分支：
+
+	$ git checkout master
+	Switched to branch 'master'
+
+此时工作目录中的内容和你在解决问题 #53 之前一模一样，你可以集中精力进行紧急修补。这一点值得牢记：Git 会把工作目录的内容恢复为检出某分支时它所指向的那个提交对象的快照。它会自动添加、删除和修改文件以确保目录的内容和你当时提交时完全一样。
+
+接下来，你得进行紧急修补。我们创建一个紧急修补分支 `hotfix` 来开展工作，直到搞定（见图 3-13）：
+
+	$ git checkout -b hotfix
+	Switched to a new branch 'hotfix'
+	$ vim index.html
+	$ git commit -a -m 'fixed the broken email address'
+	[hotfix 3a0874c] fixed the broken email address
+	 1 files changed, 1 deletion(-)
+
+Insert 18333fig0313.png
+图 3-13. hotfix 分支是从 master 分支所在点分化出来的
+
+有必要作些测试，确保修补是成功的，然后回到 `master` 分支并把它合并进来，然后发布到生产服务器。用 `git merge` 命令来进行合并：
+
+	$ git checkout master
+	$ git merge hotfix
+	Updating f42c576..3a0874c
+	Fast-forward
+	 README | 1 -
+	 1 file changed, 1 deletion(-)
+
+请注意，合并时出现了“Fast forward”的提示。由于当前 `master` 分支所在的提交对象是要并入的 `hotfix` 分支的直接上游，Git 只需把 `master` 分支指针直接右移。换句话说，如果顺着一个分支走下去可以到达另一个分支的话，那么 Git 在合并两者时，只会简单地把指针右移，因为这种单线的历史分支不存在任何需要解决的分歧，所以这种合并过程可以称为快进（Fast forward）。
+
+现在最新的修改已经在当前 `master` 分支所指向的提交对象中了，可以部署到生产服务器上去了（见图 3-14）。
+
+Insert 18333fig0314.png
+图 3-14. 合并之后，master 分支和 hotfix 分支指向同一位置。
+
+在那个超级重要的修补发布以后，你想要回到被打扰之前的工作。由于当前 `hotfix` 分支和 `master` 都指向相同的提交对象，所以 `hotfix` 已经完成了历史使命，可以删掉了。使用 `git branch` 的 `-d` 选项执行删除操作：
+
+	$ git branch -d hotfix
+	Deleted branch hotfix (was 3a0874c).
+
+现在回到之前未完成的 #53 问题修复分支上继续工作（图 3-15）：
+
+	$ git checkout iss53
+	Switched to branch 'iss53'
+	$ vim index.html
+	$ git commit -a -m 'finished the new footer [issue 53]'
+	[iss53 ad82d7a] finished the new footer [issue 53]
+	 1 file changed, 1 insertion(+)
+
+Insert 18333fig0315.png
+图 3-15. iss53 分支可以不受影响继续推进。
+
+值得注意的是之前 `hotfix` 分支的修改内容尚未包含到 `iss53` 中来。如果需要纳入此次修补，可以用 `git merge master` 把 master 分支合并到 `iss53`；或者等 `iss53` 完成之后，再将 `iss53` 分支中的更新并入 `master`。
+
+### 分支的合并 ###
+
+在问题 #53 相关的工作完成之后，可以合并回 `master` 分支。实际操作同前面合并 `hotfix` 分支差不多，只需回到 `master` 分支，运行 `git merge` 命令指定要合并进来的分支：
+
+	$ git checkout master
+	$ git merge iss53
+	Auto-merging README
+	Merge made by the 'recursive' strategy.
+	 README | 1 +
+	 1 file changed, 1 insertion(+)
+
+请注意，这次合并操作的底层实现，并不同于之前 `hotfix` 的并入方式。因为这次你的开发历史是从更早的地方开始分叉的。由于当前 `master` 分支所指向的提交对象（C4）并不是 `iss53` 分支的直接祖先，Git 不得不进行一些额外处理。就此例而言，Git 会用两个分支的末端（C4 和 C5）以及它们的共同祖先（C2）进行一次简单的三方合并计算。图 3-16 用红框标出了 Git 用于合并的三个提交对象：
+
+Insert 18333fig0316.png
+图 3-16. Git 为分支合并自动识别出最佳的同源合并点。
+
+这次，Git 没有简单地把分支指针右移，而是对三方合并后的结果重新做一个新的快照，并自动创建一个指向它的提交对象（C6）（见图 3-17）。这个提交对象比较特殊，它有两个祖先（C4 和 C5）。
+
+值得一提的是 Git 可以自己裁决哪个共同祖先才是最佳合并基础；这和 CVS 或 Subversion（1.5 以后的版本）不同，它们需要开发者手工指定合并基础。所以此特性让 Git 的合并操作比其他系统都要简单不少。
+
+Insert 18333fig0317.png
+图 3-17. Git 自动创建了一个包含了合并结果的提交对象。
+
+既然之前的工作成果已经合并到 `master` 了，那么 `iss53` 也就没用了。你可以就此删除它，并在问题追踪系统里关闭该问题。
+
+	$ git branch -d iss53
+
+### 遇到冲突时的分支合并 ###
+
+有时候合并操作并不会如此顺利。如果在不同的分支中都修改了同一个文件的同一部分，Git 就无法干净地把两者合到一起（译注：逻辑上说，这种问题只能由人来裁决。）。如果你在解决问题 #53 的过程中修改了 `hotfix` 中修改的部分，将得到类似下面的结果：
+
+	$ git merge iss53
+	Auto-merging index.html
+	CONFLICT (content): Merge conflict in index.html
+	Automatic merge failed; fix conflicts and then commit the result.
+
+Git 作了合并，但没有提交，它会停下来等你解决冲突。要看看哪些文件在合并时发生冲突，可以用 `git status` 查阅：
+
+	$ git status
+	On branch master
+	You have unmerged paths.
+	  (fix conflicts and run "git commit")
+	
+	Unmerged paths:
+	  (use "git add <file>..." to mark resolution)
+	
+	        both modified:      index.html
+	
+	no changes added to commit (use "git add" and/or "git commit -a")
+
+任何包含未解决冲突的文件都会以未合并（unmerged）的状态列出。Git 会在有冲突的文件里加入标准的冲突解决标记，可以通过它们来手工定位并解决这些冲突。可以看到此文件包含类似下面这样的部分：
+
+	<<<<<<< HEAD
+	<div id="footer">contact : email.support@github.com</div>
+	=======
+	<div id="footer">
+	  please contact us at support@github.com
+	</div>
+	>>>>>>> iss53
+
+可以看到 `=======` 隔开的上半部分，是 `HEAD`（即 `master` 分支，在运行 `merge` 命令时所切换到的分支）中的内容，下半部分是在 `iss53` 分支中的内容。解决冲突的办法无非是二者选其一或者由你亲自整合到一起。比如你可以通过把这段内容替换为下面这样来解决：
+
+	<div id="footer">
+	please contact us at email.support@github.com
+	</div>
+
+这个解决方案各采纳了两个分支中的一部分内容，而且我还删除了 `<<<<<<<`，`=======` 和 `>>>>>>>` 这些行。在解决了所有文件里的所有冲突后，运行 `git add` 将把它们标记为已解决状态（译注：实际上就是来一次快照保存到暂存区域。）。因为一旦暂存，就表示冲突已经解决。如果你想用一个有图形界面的工具来解决这些问题，不妨运行 `git mergetool`，它会调用一个可视化的合并工具并引导你解决所有冲突：
+
+	$ git mergetool
+
+	This message is displayed because 'merge.tool' is not configured.
+	See 'git mergetool --tool-help' or 'git help config' for more details.
+	'git mergetool' will now attempt to use one of the following tools:
+	opendiff kdiff3 tkdiff xxdiff meld tortoisemerge gvimdiff diffuse diffmerge ecmerge p4merge araxis bc3 codecompare vimdiff emerge
+	Merging:
+	index.html
+
+	Normal merge conflict for 'index.html':
+	  {local}: modified file
+	  {remote}: modified file
+	Hit return to start merge resolution tool (opendiff):
+
+如果不想用默认的合并工具（Git 为我默认选择了 `opendiff`，因为我在 Mac 上运行了该命令），你可以在上方"merge tool candidates"里找到可用的合并工具列表，输入你想用的工具名。我们将在第七章讨论怎样改变环境中的默认值。
+
+退出合并工具以后，Git 会询问你合并是否成功。如果回答是，它会为你把相关文件暂存起来，以表明状态为已解决。
+
+再运行一次 `git status` 来确认所有冲突都已解决：
+
+	$ git status
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        modified:   index.html
+	
+
+如果觉得满意了，并且确认所有冲突都已解决，也就是进入了暂存区，就可以用 `git commit` 来完成这次合并提交。提交的记录差不多是这样：
+
+	Merge branch 'iss53'
+
+	Conflicts:
+	  index.html
+	#
+	# It looks like you may be committing a merge.
+	# If this is not correct, please remove the file
+	#       .git/MERGE_HEAD
+	# and try again.
+	#
+
+如果想给将来看这次合并的人一些方便，可以修改该信息，提供更多合并细节。比如你都作了哪些改动，以及这么做的原因。有时候裁决冲突的理由并不直接或明显，有必要略加注解。
+
+## 分支的管理 ##
+
+到目前为止，你已经学会了如何创建、合并和删除分支。除此之外，我们还需要学习如何管理分支，在日后的常规工作中会经常用到下面介绍的管理命令。
+
+`git branch` 命令不仅仅能创建和删除分支，如果不加任何参数，它会给出当前所有分支的清单：
+
+	$ git branch
+	  iss53
+	* master
+	  testing
+
+注意看 `master` 分支前的 `*` 字符：它表示当前所在的分支。也就是说，如果现在提交更新，`master` 分支将随着开发进度前移。若要查看各个分支最后一个提交对象的信息，运行 `git branch -v`：
+
+	$ git branch -v
+	  iss53   93b412c fix javascript issue
+	* master  7a98805 Merge branch 'iss53'
+	  testing 782fd34 add scott to the author list in the readmes
+
+要从该清单中筛选出你已经（或尚未）与当前分支合并的分支，可以用 `--merged` 和 `--no-merged` 选项（Git 1.5.6 以上版本）。比如用 `git branch --merged` 查看哪些分支已被并入当前分支（译注：也就是说哪些分支是当前分支的直接上游。）：
+
+	$ git branch --merged
+	  iss53
+	* master
+
+之前我们已经合并了 `iss53`，所以在这里会看到它。一般来说，列表中没有 `*` 的分支通常都可以用 `git branch -d` 来删掉。原因很简单，既然已经把它们所包含的工作整合到了其他分支，删掉也不会损失什么。
+
+另外可以用 `git branch --no-merged` 查看尚未合并的工作：
+
+	$ git branch --no-merged
+	  testing
+
+它会显示还未合并进来的分支。由于这些分支中还包含着尚未合并进来的工作成果，所以简单地用 `git branch -d` 删除该分支会提示错误，因为那样做会丢失数据：
+
+	$ git branch -d testing
+	error: The branch 'testing' is not fully merged.
+	If you are sure you want to delete it, run 'git branch -D testing'.
+
+不过，如果你确实想要删除该分支上的改动，可以用大写的删除选项 `-D` 强制执行，就像上面提示信息中给出的那样。
+
+## 利用分支进行开发的工作流程 ##
+
+现在我们已经学会了新建分支和合并分支，可以（或应该）用它来做点什么呢？在本节，我们会介绍一些利用分支进行开发的工作流程。而正是由于分支管理的便捷，才衍生出了这类典型的工作模式，你可以根据项目的实际情况选择一种用用看。
+
+### 长期分支 ###
+
+由于 Git 使用简单的三方合并，所以就算在较长一段时间内，反复多次把某个分支合并到另一分支，也不是什么难事。也就是说，你可以同时拥有多个开放的分支，每个分支用于完成特定的任务，随着开发的推进，你可以随时把某个特性分支的成果并到其他分支中。
+
+许多使用 Git 的开发者都喜欢用这种方式来开展工作，比如仅在 `master` 分支中保留完全稳定的代码，即已经发布或即将发布的代码。与此同时，他们还有一个名为 `develop` 或 `next` 的平行分支，专门用于后续的开发，或仅用于稳定性测试 — 当然并不是说一定要绝对稳定，不过一旦进入某种稳定状态，便可以把它合并到 `master` 里。这样，在确保这些已完成的特性分支（短期分支，比如之前的 `iss53` 分支）能够通过所有测试，并且不会引入更多错误之后，就可以并到主干分支中，等待下一次的发布。
+
+本质上我们刚才谈论的，是随着提交对象不断右移的指针。稳定分支的指针总是在提交历史中落后一大截，而前沿分支总是比较靠前（见图 3-18）。
+
+Insert 18333fig0318.png
+图 3-18. 稳定分支总是比较老旧。
+
+或者把它们想象成工作流水线，或许更好理解一些，经过测试的提交对象集合被遴选到更稳定的流水线（见图 3-19）。
+
+Insert 18333fig0319.png
+图 3-19. 想象成流水线可能会容易点。
+
+你可以用这招维护不同层次的稳定性。某些大项目还会有个 `proposed`（建议）或 `pu`（proposed updates，建议更新）分支，它包含着那些可能还没有成熟到进入 `next` 或 `master` 的内容。这么做的目的是拥有不同层次的稳定性：当这些分支进入到更稳定的水平时，再把它们合并到更高层分支中去。再次说明下，使用多个长期分支的做法并非必需，不过一般来说，对于特大型项目或特复杂的项目，这么做确实更容易管理。
+
+### 特性分支 ###
+
+在任何规模的项目中都可以使用特性（Topic）分支。一个特性分支是指一个短期的，用来实现单一特性或与其相关工作的分支。可能你在以前的版本控制系统里从未做过类似这样的事情，因为通常创建与合并分支消耗太大。然而在 Git 中，一天之内建立、使用、合并再删除多个分支是常见的事。
+
+我们在上节的例子里已经见过这种用法了。我们创建了 `iss53` 和 `hotfix` 这两个特性分支，在提交了若干更新后，把它们合并到主干分支，然后删除。该技术允许你迅速且完全的进行语境切换 — 因为你的工作分散在不同的流水线里，每个分支里的改变都和它的目标特性相关，浏览代码之类的事情因而变得更简单了。你可以把作出的改变保持在特性分支中几分钟，几天甚至几个月，等它们成熟以后再合并，而不用在乎它们建立的顺序或者进度。
+
+现在我们来看一个实际的例子。请看图 3-20，由下往上，起先我们在 `master` 工作到 C1，然后开始一个新分支 `iss91` 尝试修复 91 号缺陷，提交到 C6 的时候，又冒出一个解决该问题的新办法，于是从之前 C4 的地方又分出一个分支 `iss91v2`，干到 C8 的时候，又回到主干 `master` 中提交了 C9 和 C10，再回到 `iss91v2` 继续工作，提交 C11，接着，又冒出个不太确定的想法，从 `master` 的最新提交 C10 处开了个新的分支 `dumbidea` 做些试验。
+
+Insert 18333fig0320.png
+图 3-20. 拥有多个特性分支的提交历史。
+
+现在，假定两件事情：我们最终决定使用第二个解决方案，即 `iss91v2` 中的办法；另外，我们把 `dumbidea` 分支拿给同事们看了以后，发现它竟然是个天才之作。所以接下来，我们准备抛弃原来的 `iss91` 分支（实际上会丢弃 C5 和 C6），直接在主干中并入另外两个分支。最终的提交历史将变成图 3-21 这样：
+
+Insert 18333fig0321.png
+图 3-21. 合并了 dumbidea 和 iss91v2 后的分支历史。
+
+请务必牢记这些分支全部都是本地分支，这一点很重要。当你在使用分支及合并的时候，一切都是在你自己的 Git 仓库中进行的 — 完全不涉及与服务器的交互。
+
+## 远程分支 ##
+
+远程分支（remote branch）是对远程仓库中的分支的索引。它们是一些无法移动的本地分支；只有在 Git 进行网络交互时才会更新。远程分支就像是书签，提醒着你上次连接远程仓库时上面各分支的位置。 
+
+我们用 `(远程仓库名)/(分支名)` 这样的形式表示远程分支。比如我们想看看上次同 `origin` 仓库通讯时 `master` 分支的样子，就应该查看 `origin/master` 分支。如果你和同伴一起修复某个问题，但他们先推送了一个 `iss53` 分支到远程仓库，虽然你可能也有一个本地的 `iss53` 分支，但指向服务器上最新更新的却应该是 `origin/iss53` 分支。
+
+可能有点乱，我们不妨举例说明。假设你们团队有个地址为 `git.ourcompany.com` 的 Git 服务器。如果你从这里克隆，Git 会自动为你将此远程仓库命名为 `origin`，并下载其中所有的数据，建立一个指向它的 `master` 分支的指针，在本地命名为 `origin/master`，但你无法在本地更改其数据。接着，Git 建立一个属于你自己的本地 `master` 分支，始于 `origin` 上 `master` 分支相同的位置，你可以就此开始工作（见图 3-22）：
+
+Insert 18333fig0322.png
+图 3-22. 一次 Git 克隆会建立你自己的本地分支 master 和远程分支 origin/master，并且将它们都指向 `origin` 上的 `master` 分支。
+
+如果你在本地 `master` 分支做了些改动，与此同时，其他人向 `git.ourcompany.com` 推送了他们的更新，那么服务器上的 `master` 分支就会向前推进，而于此同时，你在本地的提交历史正朝向不同方向发展。不过只要你不和服务器通讯，你的 `origin/master` 指针仍然保持原位不会移动（见图 3-23）。
+
+Insert 18333fig0323.png
+图 3-23. 在本地工作的同时有人向远程仓库推送内容会让提交历史开始分流。
+
+可以运行 `git fetch origin` 来同步远程服务器上的数据到本地。该命令首先找到 `origin` 是哪个服务器（本例为 `git.ourcompany.com`），从上面获取你尚未拥有的数据，更新你本地的数据库，然后把 `origin/master` 的指针移到它最新的位置上（见图 3-24）。
+
+Insert 18333fig0324.png
+图 3-24. git fetch 命令会更新 remote 索引。
+
+为了演示拥有多个远程分支（在不同的远程服务器上）的项目是如何工作的，我们假设你还有另一个仅供你的敏捷开发小组使用的内部服务器 `git.team1.ourcompany.com`。可以用第二章中提到的 `git remote add` 命令把它加为当前项目的远程分支之一。我们把它命名为 `teamone`，以便代替完整的 Git URL 以方便使用（见图 3-25）。
+
+Insert 18333fig0325.png
+图 3-25. 把另一个服务器加为远程仓库
+
+现在你可以用 `git fetch teamone` 来获取小组服务器上你还没有的数据了。由于当前该服务器上的内容是你 `origin` 服务器上的子集，Git 不会下载任何数据，而只是简单地创建一个名为 `teamone/master` 的远程分支，指向 `teamone` 服务器上 `master` 分支所在的提交对象 `31b8e`（见图 3-26）。
+
+Insert 18333fig0326.png
+图 3-26. 你在本地有了一个指向 teamone 服务器上 master 分支的索引。
+
+### 推送本地分支 ###
+
+要想和其他人分享某个本地分支，你需要把它推送到一个你拥有写权限的远程仓库。你创建的本地分支不会因为你的写入操作而被自动同步到你引入的远程服务器上，你需要明确地执行推送分支的操作。换句话说，对于无意分享的分支，你尽管保留为私人分支好了，而只推送那些协同工作要用到的特性分支。
+
+如果你有个叫 `serverfix` 的分支需要和他人一起开发，可以运行 `git push (远程仓库名) (分支名)`：
+
+	$ git push origin serverfix
+	Counting objects: 20, done.
+	Compressing objects: 100% (14/14), done.
+	Writing objects: 100% (15/15), 1.74 KiB, done.
+	Total 15 (delta 5), reused 0 (delta 0)
+	To git@github.com:schacon/simplegit.git
+	 * [new branch]      serverfix -> serverfix
+
+这里其实走了一点捷径。Git 自动把 `serverfix` 分支名扩展为 `refs/heads/serverfix:refs/heads/serverfix`，意为“取出我在本地的 serverfix 分支，推送到远程仓库的 serverfix 分支中去”。我们将在第九章进一步介绍 `refs/heads/` 部分的细节，不过一般使用的时候都可以省略它。也可以运行 `git push origin serverfix:serverfix` 来实现相同的效果，它的意思是“上传我本地的 serverfix 分支到远程仓库中去，仍旧称它为 serverfix 分支”。通过此语法，你可以把本地分支推送到某个命名不同的远程分支：若想把远程分支叫作 `awesomebranch`，可以用 `git push origin serverfix:awesomebranch` 来推送数据。
+
+接下来，当你的协作者再次从服务器上获取数据时，他们将得到一个新的远程分支 `origin/serverfix`，并指向服务器上 `serverfix` 所指向的版本：
+
+	$ git fetch origin
+	remote: Counting objects: 20, done.
+	remote: Compressing objects: 100% (14/14), done.
+	remote: Total 15 (delta 5), reused 0 (delta 0)
+	Unpacking objects: 100% (15/15), done.
+	From git@github.com:schacon/simplegit
+	 * [new branch]      serverfix    -> origin/serverfix
+
+值得注意的是，在 `fetch` 操作下载好新的远程分支之后，你仍然无法在本地编辑该远程仓库中的分支。换句话说，在本例中，你不会有一个新的 `serverfix` 分支，有的只是一个你无法移动的 `origin/serverfix` 指针。
+
+如果要把该远程分支的内容合并到当前分支，可以运行 `git merge origin/serverfix`。如果想要一份自己的 `serverfix` 来开发，可以在远程分支的基础上分化出一个新的分支来：
+
+	$ git checkout -b serverfix origin/serverfix
+	Branch serverfix set up to track remote branch serverfix from origin.
+	Switched to a new branch 'serverfix'
+
+这会切换到新建的 `serverfix` 本地分支，其内容同远程分支 `origin/serverfix` 一致，这样你就可以在里面继续开发了。
+
+### 跟踪远程分支 ###
+
+从远程分支 `checkout` 出来的本地分支，称为 _跟踪分支_ (tracking branch)。跟踪分支是一种和某个远程分支有直接联系的本地分支。在跟踪分支里输入 `git push`，Git 会自行推断应该向哪个服务器的哪个分支推送数据。同样，在这些分支里运行 `git pull` 会获取所有远程索引，并把它们的数据都合并到本地分支中来。
+
+在克隆仓库时，Git 通常会自动创建一个名为 `master` 的分支来跟踪 `origin/master`。这正是 `git push` 和 `git pull` 一开始就能正常工作的原因。当然，你可以随心所欲地设定为其它跟踪分支，比如 `origin` 上除了 `master` 之外的其它分支。刚才我们已经看到了这样的一个例子：`git checkout -b [分支名] [远程名]/[分支名]`。如果你有 1.6.2 以上版本的 Git，还可以用 `--track` 选项简化：
+
+	$ git checkout --track origin/serverfix
+	Branch serverfix set up to track remote branch serverfix from origin.
+	Switched to a new branch 'serverfix'
+
+要为本地分支设定不同于远程分支的名字，只需在第一个版本的命令里换个名字：
+
+	$ git checkout -b sf origin/serverfix
+	Branch sf set up to track remote branch serverfix from origin.
+	Switched to a new branch 'sf'
+
+现在你的本地分支 `sf` 会自动将推送和抓取数据的位置定位到 `origin/serverfix` 了。
+
+### 删除远程分支 ###
+
+如果不再需要某个远程分支了，比如搞定了某个特性并把它合并进了远程的 `master` 分支（或任何其他存放稳定代码的分支），可以用这个非常无厘头的语法来删除它：`git push [远程名] :[分支名]`。如果想在服务器上删除 `serverfix` 分支，运行下面的命令：
+
+	$ git push origin :serverfix
+	To git@github.com:schacon/simplegit.git
+	 - [deleted]         serverfix
+
+咚！服务器上的分支没了。你最好特别留心这一页，因为你一定会用到那个命令，而且你很可能会忘掉它的语法。有种方便记忆这条命令的方法：记住我们不久前见过的 `git push [远程名] [本地分支]:[远程分支]` 语法，如果省略 `[本地分支]`，那就等于是在说“在这里提取空白然后把它变成`[远程分支]`”。
+
+## 分支的衍合 ##
+
+把一个分支中的修改整合到另一个分支的办法有两种：`merge` 和 `rebase`（译注：`rebase` 的翻译暂定为“衍合”，大家知道就可以了。）。在本章我们会学习什么是衍合，如何使用衍合，为什么衍合操作如此富有魅力，以及我们应该在什么情况下使用衍合。
+
+### 基本的衍合操作 ###
+
+请回顾之前有关合并的一节（见图 3-27），你会看到开发进程分叉到两个不同分支，又各自提交了更新。
+
+Insert 18333fig0327.png
+图 3-27. 最初分叉的提交历史。
+
+之前介绍过，最容易的整合分支的方法是 `merge` 命令，它会把两个分支最新的快照（C3 和 C4）以及二者最新的共同祖先（C2）进行三方合并，合并的结果是产生一个新的提交对象（C5）。如图 3-28 所示：
+
+Insert 18333fig0328.png
+图 3-28. 通过合并一个分支来整合分叉了的历史。
+
+其实，还有另外一个选择：你可以把在 C3 里产生的变化补丁在 C4 的基础上重新打一遍。在 Git 里，这种操作叫做_衍合（rebase）_。有了 `rebase` 命令，就可以把在一个分支里提交的改变移到另一个分支里重放一遍。
+
+在上面这个例子中，运行：
+
+	$ git checkout experiment
+	$ git rebase master
+	First, rewinding head to replay your work on top of it...
+	Applying: added staged command
+
+它的原理是回到两个分支最近的共同祖先，根据当前分支（也就是要进行衍合的分支 `experiment`）后续的历次提交对象（这里只有一个 C3），生成一系列文件补丁，然后以基底分支（也就是主干分支 `master`）最后一个提交对象（C4）为新的出发点，逐个应用之前准备好的补丁文件，最后会生成一个新的合并提交对象（C3'），从而改写 `experiment` 的提交历史，使它成为 `master` 分支的直接下游，如图 3-29 所示：
+
+Insert 18333fig0329.png
+图 3-29. 把 C3 里产生的改变到 C4 上重演一遍。
+
+现在回到 `master` 分支，进行一次快进合并（见图 3-30）：
+
+Insert 18333fig0330.png
+图 3-30. master 分支的快进。
+
+现在的 C3' 对应的快照，其实和普通的三方合并，即上个例子中的 C5 对应的快照内容一模一样了。虽然最后整合得到的结果没有任何区别，但衍合能产生一个更为整洁的提交历史。如果视察一个衍合过的分支的历史记录，看起来会更清楚：仿佛所有修改都是在一根线上先后进行的，尽管实际上它们原本是同时并行发生的。
+
+一般我们使用衍合的目的，是想要得到一个能在远程分支上干净应用的补丁 — 比如某些项目你不是维护者，但想帮点忙的话，最好用衍合：先在自己的一个分支里进行开发，当准备向主项目提交补丁的时候，根据最新的 `origin/master` 进行一次衍合操作然后再提交，这样维护者就不需要做任何整合工作（译注：实际上是把解决分支补丁同最新主干代码之间冲突的责任，化转为由提交补丁的人来解决。），只需根据你提供的仓库地址作一次快进合并，或者直接采纳你提交的补丁。
+
+请注意，合并结果中最后一次提交所指向的快照，无论是通过衍合，还是三方合并，都会得到相同的快照内容，只不过提交历史不同罢了。衍合是按照每行的修改次序重演一遍修改，而合并是把最终结果合在一起。
+
+### 有趣的衍合 ###
+
+衍合也可以放到其他分支进行，并不一定非得根据分化之前的分支。以图 3-31 的历史为例，我们为了给服务器端代码添加一些功能而创建了特性分支 `server`，然后提交 C3 和 C4。然后又从 C3 的地方再增加一个 `client` 分支来对客户端代码进行一些相应修改，所以提交了 C8 和 C9。最后，又回到 `server` 分支提交了 C10。
+
+Insert 18333fig0331.png
+图 3-31. 从一个特性分支里再分出一个特性分支的历史。
+
+假设在接下来的一次软件发布中，我们决定先把客户端的修改并到主线中，而暂缓并入服务端软件的修改（因为还需要进一步测试）。这个时候，我们就可以把基于 `server` 分支而非 `master` 分支的改变（即 C8 和 C9），跳过 `server` 直接放到 `master` 分支中重演一遍，但这需要用 `git rebase` 的 `--onto` 选项指定新的基底分支 `master`：
+
+	$ git rebase --onto master server client
+
+这好比在说：“取出 `client` 分支，找出 `client` 分支和 `server` 分支的共同祖先之后的变化，然后把它们在 `master` 上重演一遍”。是不是有点复杂？不过它的结果如图 3-32 所示，非常酷（译注：虽然 `client` 里的 C8, C9 在 C3 之后，但这仅表明时间上的先后，而非在 C3 修改的基础上进一步改动，因为 `server` 和 `client` 这两个分支对应的代码应该是两套文件，虽然这么说不是很严格，但应理解为在 C3 时间点之后，对另外的文件所做的 C8，C9 修改，放到主干重演。）：
+
+Insert 18333fig0332.png
+图 3-32. 将特性分支上的另一个特性分支衍合到其他分支。
+
+现在可以快进 `master` 分支了（见图 3-33）：
+
+	$ git checkout master
+	$ git merge client
+
+Insert 18333fig0333.png
+图 3-33. 快进 master 分支，使之包含 client 分支的变化。
+
+现在我们决定把 `server` 分支的变化也包含进来。我们可以直接把 `server` 分支衍合到 `master`，而不用手工切换到 `server` 分支后再执行衍合操作 — `git rebase [主分支] [特性分支]` 命令会先取出特性分支 `server`，然后在主分支 `master` 上重演：
+
+	$ git rebase master server
+
+于是，`server` 的进度应用到 `master` 的基础上，如图 3-34 所示：
+
+Insert 18333fig0334.png
+图 3-34. 在 master 分支上衍合 server 分支。
+
+然后就可以快进主干分支 `master` 了：
+
+	$ git checkout master
+	$ git merge server
+
+现在 `client` 和 `server` 分支的变化都已经集成到主干分支来了，可以删掉它们了。最终我们的提交历史会变成图 3-35 的样子：
+
+	$ git branch -d client
+	$ git branch -d server
+
+Insert 18333fig0335.png
+图 3-35. 最终的提交历史
+
+### 衍合的风险 ###
+
+呃，奇妙的衍合也并非完美无缺，要用它得遵守一条准则：
+
+**一旦分支中的提交对象发布到公共仓库，就千万不要对该分支进行衍合操作。**
+
+如果你遵循这条金科玉律，就不会出差错。否则，人民群众会仇恨你，你的朋友和家人也会嘲笑你，唾弃你。
+
+在进行衍合的时候，实际上抛弃了一些现存的提交对象而创造了一些类似但不同的新的提交对象。如果你把原来分支中的提交对象发布出去，并且其他人更新下载后在其基础上开展工作，而稍后你又用 `git rebase` 抛弃这些提交对象，把新的重演后的提交对象发布出去的话，你的合作者就不得不重新合并他们的工作，这样当你再次从他们那里获取内容时，提交历史就会变得一团糟。
+
+下面我们用一个实际例子来说明为什么公开的衍合会带来问题。假设你从一个中央服务器克隆然后在它的基础上搞了一些开发，提交历史类似图 3-36 所示：
+
+Insert 18333fig0336.png
+图 3-36. 克隆一个仓库，在其基础上工作一番。
+
+现在，某人在 C1 的基础上做了些改变，并合并他自己的分支得到结果 C6，推送到中央服务器。当你抓取并合并这些数据到你本地的开发分支中后，会得到合并结果 C7，历史提交会变成图 3-37 这样：
+
+Insert 18333fig0337.png
+图 3-37. 抓取他人提交，并入自己主干。
+
+接下来，那个推送 C6 上来的人决定用衍合取代之前的合并操作；继而又用 `git push --force` 覆盖了服务器上的历史，得到 C4'。而之后当你再从服务器上下载最新提交后，会得到：
+
+Insert 18333fig0338.png
+图 3-38. 有人推送了衍合后得到的 C4'，丢弃了你作为开发基础的 C4 和 C6。
+
+下载更新后需要合并，但此时衍合产生的提交对象 C4' 的 SHA-1 校验值和之前 C4 完全不同，所以 Git 会把它们当作新的提交对象处理，而实际上此刻你的提交历史 C7 中早已经包含了 C4 的修改内容，于是合并操作会把 C7 和 C4' 合并为 C8（见图 3-39）:
+
+Insert 18333fig0339.png
+图 3-39. 你把相同的内容又合并了一遍，生成一个新的提交 C8。
+
+C8 这一步的合并是迟早会发生的，因为只有这样你才能和其他协作者提交的内容保持同步。而在 C8 之后，你的提交历史里就会同时包含 C4 和 C4'，两者有着不同的 SHA-1 校验值，如果用 `git log` 查看历史，会看到两个提交拥有相同的作者日期与说明，令人费解。而更糟的是，当你把这样的历史推送到服务器后，会再次把这些衍合后的提交引入到中央服务器，进一步困扰其他人（译注：这个例子中，出问题的责任方是那个发布了 C6 后又用衍合发布 C4' 的人，其他人会因此反馈双重历史到共享主干，从而混淆大家的视听。）。
+
+如果把衍合当成一种在推送之前清理提交历史的手段，而且仅仅衍合那些尚未公开的提交对象，就没问题。如果衍合那些已经公开的提交对象，并且已经有人基于这些提交对象开展了后续开发工作的话，就会出现叫人沮丧的麻烦。
+
+## 小结 ##
+
+读到这里，你应该已经学会了如何创建分支并切换到新分支，在不同分支间转换，合并本地分支，把分支推送到共享服务器上，使用共享分支与他人协作，以及在分享之前进行衍合。

From 6feadc18611459b21ae8ac7ce0bf08ffe2954ce9 Mon Sep 17 00:00:00 2001
From: ya_hsiung <ya_hsiung@yahoo.com>
Date: Thu, 6 Mar 2014 17:28:59 +0800
Subject: [PATCH 253/690] update to 3-8

---
 zh-tw/03-git-branching/01-chapter3.markdown | 26 ++++++++++-----------
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/zh-tw/03-git-branching/01-chapter3.markdown b/zh-tw/03-git-branching/01-chapter3.markdown
index ab6c7ca84..a01eee667 100644
--- a/zh-tw/03-git-branching/01-chapter3.markdown
+++ b/zh-tw/03-git-branching/01-chapter3.markdown
@@ -32,44 +32,44 @@ Insert 18333fig0302.png
 Insert 18333fig0303.png
 圖 3-3. 分支其實就是從某個提交物件往回看的歷史
 
-那么，Git 又是如何创建一个新的分支的呢？答案很简单，创建一个新的分支指针。比如新建一个 testing 分支，可以使用 `git branch` 命令：
+那麼，Git 又是如何創建一個新的分支的呢？答案很簡單，創建一個新的分支指標。比如新建一個 testing 分支，可以使用 `git branch` 命令：
 
 	$ git branch testing
 
-这会在当前 commit 对象上新建一个分支指针（见图 3-4）。
+這會在當前 commit 物件上新建一個分支指標（見圖 3-4）。
 
 Insert 18333fig0304.png
-图 3-4. 多个分支指向提交数据的历史
+圖 3-4. 多個分支指向提交資料的歷史
 
-那么，Git 是如何知道你当前在哪个分支上工作的呢？其实答案也很简单，它保存着一个名为 HEAD 的特别指针。请注意它和你熟知的许多其他版本控制系统（比如 Subversion 或 CVS）里的 HEAD 概念大不相同。在 Git 中，它是一个指向你正在工作中的本地分支的指针（译注：将 HEAD 想象为当前分支的别名。）。运行 `git branch` 命令，仅仅是建立了一个新的分支，但不会自动切换到这个分支中去，所以在这个例子中，我们依然还在 master 分支里工作（参考图 3-5）。
+那麼，Git 是如何知道你當前在哪個分支上工作的呢？其實答案也很簡單，它保存著一個名為 HEAD 的特別指標。請注意它和你熟知的許多其他版本控制系統（比如 Subversion 或 CVS）裡的 HEAD 概念大不相同。在 Git 中，它是一個指向你正在工作中的本地分支的指標（譯注：將 HEAD 想像為當前分支的別名。）。運行 `git branch` 命令，僅僅是建立了一個新的分支，但不會自動切換到這個分支中去，所以在這個例子中，我們依然還在 master 分支裡工作（參考圖 3-5）。
 
 Insert 18333fig0305.png
-图 3-5. HEAD 指向当前所在的分支
+圖 3-5. HEAD 指向當前所在的分支
 
-要切换到其他分支，可以执行 `git checkout` 命令。我们现在转换到新建的 testing 分支：
+要切換到其他分支，可以執行 `git checkout` 命令。我們現在轉換到新建的 testing 分支：
 
 	$ git checkout testing
 
-这样 HEAD 就指向了 testing 分支（见图3-6）。
+這樣 HEAD 就指向了 testing 分支（見圖3-6）。
 
 Insert 18333fig0306.png
-图 3-6. HEAD 在你转换分支时指向新的分支
+圖 3-6. HEAD 在你轉換分支時指向新的分支
 
-这样的实现方式会给我们带来什么好处呢？好吧，现在不妨再提交一次：
+這樣的實現方式會給我們帶來什麼好處呢？好吧，現在不妨再提交一次：
 
 	$ vim test.rb
 	$ git commit -a -m 'made a change'
 
-图 3-7 展示了提交后的结果。
+圖 3-7 展示了提交後的結果。
 
 Insert 18333fig0307.png
-图 3-7. 每次提交后 HEAD 随着分支一起向前移动
+圖 3-7. 每次提交後 HEAD 隨著分支一起向前移動
 
-非常有趣，现在 testing 分支向前移动了一格，而 master 分支仍然指向原先 `git checkout` 时所在的 commit 对象。现在我们回到 master 分支看看：
+非常有趣，現在 testing 分支向前移動了一格，而 master 分支仍然指向原先 `git checkout` 時所在的 commit 物件。現在我們回到 master 分支看看：
 
 	$ git checkout master
 
-图 3-8 显示了结果。
+圖 3-8 顯示了結果。
 
 Insert 18333fig0308.png
 图 3-8. HEAD 在一次 checkout 之后移动到了另一个分支

From b7b68fa09f891933792310e76626e8ceced8ca44 Mon Sep 17 00:00:00 2001
From: ya_hsiung <ya_hsiung@yahoo.com>
Date: Thu, 6 Mar 2014 17:40:35 +0800
Subject: [PATCH 254/690] finish 3-1

---
 zh-tw/03-git-branching/01-chapter3.markdown | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/zh-tw/03-git-branching/01-chapter3.markdown b/zh-tw/03-git-branching/01-chapter3.markdown
index a01eee667..5f7a915dc 100644
--- a/zh-tw/03-git-branching/01-chapter3.markdown
+++ b/zh-tw/03-git-branching/01-chapter3.markdown
@@ -72,25 +72,25 @@ Insert 18333fig0307.png
 圖 3-8 顯示了結果。
 
 Insert 18333fig0308.png
-图 3-8. HEAD 在一次 checkout 之后移动到了另一个分支
+圖 3-8. HEAD 在一次 checkout 之後移動到了另一個分支
 
-这条命令做了两件事。它把 HEAD 指针移回到 master 分支，并把工作目录中的文件换成了 master 分支所指向的快照内容。也就是说，现在开始所做的改动，将始于本项目中一个较老的版本。它的主要作用是将 testing 分支里作出的修改暂时取消，这样你就可以向另一个方向进行开发。
+這條命令做了兩件事。它把 HEAD 指標移回到 master 分支，並把工作目錄中的檔換成了 master 分支所指向的快照內容。也就是說，現在開始所做的改動，將始於本專案中一個較老的版本。它的主要作用是將 testing 分支裡作出的修改暫時取消，這樣你就可以向另一個方向進行開發。
 
-我们作些修改后再次提交：
+我們作些修改後再次提交：
 
 	$ vim test.rb
 	$ git commit -a -m 'made other changes'
 
-现在我们的项目提交历史产生了分叉（如图 3-9 所示），因为刚才我们创建了一个分支，转换到其中进行了一些工作，然后又回到原来的主分支进行了另外一些工作。这些改变分别孤立在不同的分支里：我们可以在不同分支里反复切换，并在时机成熟时把它们合并到一起。而所有这些工作，仅仅需要 `branch` 和 `checkout` 这两条命令就可以完成。
+現在我們的項目提交歷史產生了分叉（如圖 3-9 所示），因為剛才我們創建了一個分支，轉換到其中進行了一些工作，然後又回到原來的主分支進行了另外一些工作。這些改變分別孤立在不同的分支裡：我們可以在不同分支裡反復切換，並在時機成熟時把它們合併到一起。而所有這些工作，僅僅需要 `branch` 和 `checkout` 這兩條命令就可以完成。
 
 Insert 18333fig0309.png
-图 3-9. 不同流向的分支历史
+圖 3-9. 不同流向的分支歷史
 
-由于 Git 中的分支实际上仅是一个包含所指对象校验和（40 个字符长度 SHA-1 字串）的文件，所以创建和销毁一个分支就变得非常廉价。说白了，新建一个分支就是向一个文件写入 41 个字节（外加一个换行符）那么简单，当然也就很快了。
+由於 Git 中的分支實際上僅是一個包含所指物件校驗和（40 個字元長度 SHA-1 字串）的檔，所以創建和銷毀一個分支就變得非常廉價。說白了，新建一個分支就是向一個檔寫入 41 個位元組（外加一個分行符號）那麼簡單，當然也就很快了。
 
-这和大多数版本控制系统形成了鲜明对比，它们管理分支大多采取备份所有项目文件到特定目录的方式，所以根据项目文件数量和大小不同，可能花费的时间也会有相当大的差别，快则几秒，慢则数分钟。而 Git 的实现与项目复杂度无关，它永远可以在几毫秒的时间内完成分支的创建和切换。同时，因为每次提交时都记录了祖先信息（译注：即 `parent` 对象），将来要合并分支时，寻找恰当的合并基础（译注：即共同祖先）的工作其实已经自然而然地摆在那里了，所以实现起来非常容易。Git 鼓励开发者频繁使用分支，正是因为有着这些特性作保障。
+這和大多數版本控制系統形成了鮮明對比，它們管理分支大多採取備份所有專案檔案到特定目錄的方式，所以根據專案檔案數量和大小不同，可能花費的時間也會有相當大的差別，快則幾秒，慢則數分鐘。而 Git 的實現與項目複雜度無關，它永遠可以在幾毫秒的時間內完成分支的創建和切換。同時，因為每次提交時都記錄了祖先資訊（譯注：即 `parent` 物件），將來要合併分支時，尋找恰當的合併基礎（譯注：即共同祖先）的工作其實已經自然而然地擺在那裡了，所以實現起來非常容易。Git 鼓勵開發者頻繁使用分支，正是因為有著這些特性作保障。
 
-接下来看看，我们为什么应该频繁使用分支。
+接下來看看，我們為什麼應該頻繁使用分支。
 
 ## 分支的新建与合并 ##
 

From 9f1b7ad54b4de86d48635398233baff18c8e2a71 Mon Sep 17 00:00:00 2001
From: Volkan Gezer <wakeup@users.noreply.github.com>
Date: Thu, 6 Mar 2014 11:03:34 +0100
Subject: [PATCH 255/690] Update 01-chapter3.markdown

---
 tr/03-git-branching/01-chapter3.markdown | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/tr/03-git-branching/01-chapter3.markdown b/tr/03-git-branching/01-chapter3.markdown
index f897e8ea2..4a5679003 100644
--- a/tr/03-git-branching/01-chapter3.markdown
+++ b/tr/03-git-branching/01-chapter3.markdown
@@ -464,17 +464,17 @@ Uzak uçbirim dalının adından başka bir adla yerel dal oluşturmak isterseni
 
 ### Uzak Uçbirim Dallarını Silmek ###
 
-Suppose you’re done with a remote branch — say, you and your collaborators are finished with a feature and have merged it into your remote’s `master` branch (or whatever branch your stable codeline is in). You can delete a remote branch using the rather obtuse syntax `git push [remotename] :[branch]`. If you want to delete your `serverfix` branch from the server, you run the following:
+Diyelim ki uzak bir dalla yapacaklarınız bitti ve siz ile takım arkadaşlarınız bir özelliği tamamlayıp sizin uzaktaki `master` dalınıza (veya kararlı kodunuzun olduğu herhangi bir dalda) birleştirdi. Bir uzak dalı `git push [uzakadı] :[dal]` sabit sözdizimini kullanarak silebilirsiniz. Eğer sunucudan `serverfix` dalını silmek isterseniz, şu komutu çalıştırın:
 
 	$ git push origin :serverfix
 	To git@github.com:schacon/simplegit.git
 	 - [deleted]         serverfix
 
-Boom. No more branch on your server. You may want to dog-ear this page, because you’ll need that command, and you’ll likely forget the syntax. A way to remember this command is by recalling the `git push [remotename] [localbranch]:[remotebranch]` syntax that we went over a bit earlier. If you leave off the `[localbranch]` portion, then you’re basically saying, “Take nothing on my side and make it be `[remotebranch]`.”
+İşte bu! Artık sunucunuzda bu dal olmayacak. Bu sayfayı dikkatlice anlamak isteyebilirsiniz, çünkü muhtemelen bu komuta ihtiyacınız olacak ancak sözdizimini unutacaksınız. Bu komutu hatırlamanın bir yolu daha önceden biraz bahsedilen `git push [uzakadı] [yereldal]:[uzakdal]` sözdizimini hatırlamaktır. Eğer `[yereldal]` kısmını yazmazsanız, aslında dediğiniz şey “Benim tarafımdan bir şey alma ancak `[uzakdal]`dan al.”
 
-## Rebasing ## Zemin, Kök, Temel
+## Rebasing (Tekrar Adresleme) ## Zemin, Kök, Temel
 
-In Git, there are two main ways to integrate changes from one branch into another: the `merge` and the `rebase`. In this section you’ll learn what rebasing is, how to do it, why it’s a pretty amazing tool, and in what cases you won’t want to use it.
+Git içerisinde, değişiklikleri bir daldan diğerine bütünleştirmek için iki temel yol bulunuyor: `merge` ve `rebase`. Bu bölümde sadece rebase komutunun ne olduğunu, nasıl yapılacağını, neden mükemmel bir araç olduğunu ve hangi durumlarda kullanmak istemeyeceğinizi öğreneceksiniz.
 
 ### The Basic Rebase ###
 

From 0264c2e796ae4c90bce0fea0f20ff64d4ab33528 Mon Sep 17 00:00:00 2001
From: ya_hsiung <ya_hsiung@yahoo.com>
Date: Thu, 6 Mar 2014 18:23:56 +0800
Subject: [PATCH 256/690] Update 3.2

---
 zh-tw/03-git-branching/01-chapter3.markdown | 30 ++++++++++-----------
 1 file changed, 15 insertions(+), 15 deletions(-)

diff --git a/zh-tw/03-git-branching/01-chapter3.markdown b/zh-tw/03-git-branching/01-chapter3.markdown
index 5f7a915dc..ffe547565 100644
--- a/zh-tw/03-git-branching/01-chapter3.markdown
+++ b/zh-tw/03-git-branching/01-chapter3.markdown
@@ -92,34 +92,34 @@ Insert 18333fig0309.png
 
 接下來看看，我們為什麼應該頻繁使用分支。
 
-## 分支的新建与合并 ##
+## 分支的新建與合併 ##
 
-现在让我们来看一个简单的分支与合并的例子，实际工作中大体也会用到这样的工作流程：
+現在讓我們來看一個簡單的分支與合併的例子，實際工作中大體也會用到這樣的工作流程：
 
-1. 开发某个网站。
-2. 为实现某个新的需求，创建一个分支。
-3. 在这个分支上开展工作。
+1. 開發某個網站。
+2. 為實現某個新的需求，創建一個分支。
+3. 在這個分支上開展工作。
 
-假设此时，你突然接到一个电话说有个很严重的问题需要紧急修补，那么可以按照下面的方式处理：
+假設此時，你突然接到一個電話說有個很嚴重的問題需要緊急修補，那麼可以按照下面的方式處理：
 
-1. 返回到原先已经发布到生产服务器上的分支。
-2. 为这次紧急修补建立一个新分支，并在其中修复问题。
-3. 通过测试后，回到生产服务器所在的分支，将修补分支合并进来，然后再推送到生产服务器上。
-4. 切换到之前实现新需求的分支，继续工作。
+1. 返回到原先已經發佈到生產伺服器上的分支。
+2. 為這次緊急修補建立一個新分支，並在其中修復問題。
+3. 通過測試後，回到生產伺服器所在的分支，將修補分支合併進來，然後再推送到生產伺服器上。
+4. 切換到之前實現新需求的分支，繼續工作。
 
-### 分支的新建与切换 ###
+### 分支的新建與切換 ###
 
-首先，我们假设你正在项目中愉快地工作，并且已经提交了几次更新（见图 3-10）。
+首先，我們假設你正在專案中愉快地工作，並且已經提交了幾次更新（見圖 3-10）。
 
 Insert 18333fig0310.png
-图 3-10. 一个简短的提交历史
+圖 3-10. 一個簡短的提交歷史
 
-现在，你决定要修补问题追踪系统上的 #53 问题。顺带说明下，Git 并不同任何特定的问题追踪系统打交道。这里为了说明要解决的问题，才把新建的分支取名为 iss53。要新建并切换到该分支，运行 `git checkout` 并加上 `-b` 参数：
+現在，你決定要修補問題追蹤系統上的 #53 問題。順帶說明下，Git 並不同任何特定的問題追蹤系統打交道。這裡為了說明要解決的問題，才把新建的分支取名為 iss53。要新建並切換到該分支，運行 `git checkout` 並加上 `-b` 參數：
 
 	$ git checkout -b iss53
 	Switched to a new branch 'iss53'
 
-这相当于执行下面这两条命令：
+這相當於執行下麵這兩條命令：
 
 	$ git branch iss53
 	$ git checkout iss53

From f5d62c3d305a175f95df395dbc2a196b64ea4c0a Mon Sep 17 00:00:00 2001
From: ya_hsiung <ya_hsiung@yahoo.com>
Date: Thu, 6 Mar 2014 18:25:49 +0800
Subject: [PATCH 257/690] 3.2 word error

---
 zh-tw/03-git-branching/01-chapter3.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/zh-tw/03-git-branching/01-chapter3.markdown b/zh-tw/03-git-branching/01-chapter3.markdown
index ffe547565..666931398 100644
--- a/zh-tw/03-git-branching/01-chapter3.markdown
+++ b/zh-tw/03-git-branching/01-chapter3.markdown
@@ -119,7 +119,7 @@ Insert 18333fig0310.png
 	$ git checkout -b iss53
 	Switched to a new branch 'iss53'
 
-這相當於執行下麵這兩條命令：
+這相當於執行下面這兩條命令：
 
 	$ git branch iss53
 	$ git checkout iss53

From c2679d34e0123f5034ae86b576d15711a3c8c52c Mon Sep 17 00:00:00 2001
From: ya_hsiung <ya_hsiung@yahoo.com>
Date: Fri, 7 Mar 2014 13:53:58 +0800
Subject: [PATCH 258/690] chapter 3 finished

---
 zh-tw/03-git-branching/01-chapter3.markdown | 266 ++++++++++----------
 1 file changed, 133 insertions(+), 133 deletions(-)

diff --git a/zh-tw/03-git-branching/01-chapter3.markdown b/zh-tw/03-git-branching/01-chapter3.markdown
index 666931398..918a9fd6f 100644
--- a/zh-tw/03-git-branching/01-chapter3.markdown
+++ b/zh-tw/03-git-branching/01-chapter3.markdown
@@ -124,29 +124,29 @@ Insert 18333fig0310.png
 	$ git branch iss53
 	$ git checkout iss53
 
-图 3-11 示意该命令的执行结果。
+圖 3-11 示意該命令的執行結果。
 
 Insert 18333fig0311.png
-图 3-11. 创建了一个新分支的指针
+圖 3-11. 創建了一個新分支的指標
 
-接着你开始尝试修复问题，在提交了若干次更新后，`iss53` 分支的指针也会随着向前推进，因为它就是当前分支（换句话说，当前的 `HEAD` 指针正指向 `iss53`，见图 3-12）：
+接著你開始嘗試修復問題，在提交了若干次更新後，`iss53` 分支的指標也會隨著向前推進，因為它就是當前分支（換句話說，當前的 `HEAD` 指標正指向 `iss53`，見圖 3-12）：
 
 	$ vim index.html
 	$ git commit -a -m 'added a new footer [issue 53]'
 
 Insert 18333fig0312.png
-图 3-12. iss53 分支随工作进展向前推进
+圖 3-12. iss53 分支隨工作進展向前推進
 
-现在你就接到了那个网站问题的紧急电话，需要马上修补。有了 Git ，我们就不需要同时发布这个补丁和 `iss53` 里作出的修改，也不需要在创建和发布该补丁到服务器之前花费大力气来复原这些修改。唯一需要的仅仅是切换回 `master` 分支。
+現在你就接到了那個網站問題的緊急電話，需要馬上修補。有了 Git ，我們就不需要同時發佈這個補丁和 `iss53` 裡作出的修改，也不需要在創建和發佈該補丁到伺服器之前花費大力氣來復原這些修改。唯一需要的僅僅是切換回 `master` 分支。
 
-不过在此之前，留心你的暂存区或者工作目录里，那些还没有提交的修改，它会和你即将检出的分支产生冲突从而阻止 Git 为你切换分支。切换分支的时候最好保持一个清洁的工作区域。稍后会介绍几个绕过这种问题的办法（分别叫做 stashing 和 commit amending）。目前已经提交了所有的修改，所以接下来可以正常转换到 `master` 分支：
+不過在此之前，留心你的暫存區或者工作目錄裡，那些還沒有提交的修改，它會和你即將檢出的分支產生衝突從而阻止 Git 為你切換分支。切換分支的時候最好保持一個清潔的工作區域。稍後會介紹幾個繞過這種問題的辦法（分別叫做 stashing 和 commit amending）。目前已經提交了所有的修改，所以接下來可以正常轉換到 `master` 分支：
 
 	$ git checkout master
 	Switched to branch 'master'
 
-此时工作目录中的内容和你在解决问题 #53 之前一模一样，你可以集中精力进行紧急修补。这一点值得牢记：Git 会把工作目录的内容恢复为检出某分支时它所指向的那个提交对象的快照。它会自动添加、删除和修改文件以确保目录的内容和你当时提交时完全一样。
+此時工作目錄中的內容和你在解決問題 #53 之前一模一樣，你可以集中精力進行緊急修補。這一點值得牢記：Git 會把工作目錄的內容恢復為檢出某分支時它所指向的那個提交物件的快照。它會自動添加、刪除和修改檔以確保目錄的內容和你當時提交時完全一樣。
 
-接下来，你得进行紧急修补。我们创建一个紧急修补分支 `hotfix` 来开展工作，直到搞定（见图 3-13）：
+接下來，你得進行緊急修補。我們創建一個緊急修補分支 `hotfix` 來開展工作，直到搞定（見圖 3-13）：
 
 	$ git checkout -b hotfix
 	Switched to a new branch 'hotfix'
@@ -156,9 +156,9 @@ Insert 18333fig0312.png
 	 1 files changed, 1 deletion(-)
 
 Insert 18333fig0313.png
-图 3-13. hotfix 分支是从 master 分支所在点分化出来的
+圖 3-13. hotfix 分支是從 master 分支所在點分化出來的
 
-有必要作些测试，确保修补是成功的，然后回到 `master` 分支并把它合并进来，然后发布到生产服务器。用 `git merge` 命令来进行合并：
+有必要作些測試，確保修補是成功的，然後回到 `master` 分支並把它合併進來，然後發佈到生產伺服器。用 `git merge` 命令來進行合併：
 
 	$ git checkout master
 	$ git merge hotfix
@@ -167,19 +167,19 @@ Insert 18333fig0313.png
 	 README | 1 -
 	 1 file changed, 1 deletion(-)
 
-请注意，合并时出现了“Fast forward”的提示。由于当前 `master` 分支所在的提交对象是要并入的 `hotfix` 分支的直接上游，Git 只需把 `master` 分支指针直接右移。换句话说，如果顺着一个分支走下去可以到达另一个分支的话，那么 Git 在合并两者时，只会简单地把指针右移，因为这种单线的历史分支不存在任何需要解决的分歧，所以这种合并过程可以称为快进（Fast forward）。
+請注意，合併時出現了“Fast forward”的提示。由於當前 `master` 分支所在的提交物件是要併入的 `hotfix` 分支的直接上游，Git 只需把 `master` 分支指標直接右移。換句話說，如果順著一個分支走下去可以到達另一個分支的話，那麼 Git 在合併兩者時，只會簡單地把指標右移，因為這種單線的歷史分支不存在任何需要解決的分歧，所以這種合併過程可以稱為快進（Fast forward）。
 
-现在最新的修改已经在当前 `master` 分支所指向的提交对象中了，可以部署到生产服务器上去了（见图 3-14）。
+現在最新的修改已經在當前 `master` 分支所指向的提交物件中了，可以部署到生產伺服器上去了（見圖 3-14）。
 
 Insert 18333fig0314.png
-图 3-14. 合并之后，master 分支和 hotfix 分支指向同一位置。
+圖 3-14. 合併之後，master 分支和 hotfix 分支指向同一位置。
 
-在那个超级重要的修补发布以后，你想要回到被打扰之前的工作。由于当前 `hotfix` 分支和 `master` 都指向相同的提交对象，所以 `hotfix` 已经完成了历史使命，可以删掉了。使用 `git branch` 的 `-d` 选项执行删除操作：
+在那個超級重要的修補發佈以後，你想要回到被打擾之前的工作。由於當前 `hotfix` 分支和 `master` 都指向相同的提交物件，所以 `hotfix` 已經完成了歷史使命，可以刪掉了。使用 `git branch` 的 `-d` 選項執行刪除操作：
 
 	$ git branch -d hotfix
 	Deleted branch hotfix (was 3a0874c).
 
-现在回到之前未完成的 #53 问题修复分支上继续工作（图 3-15）：
+現在回到之前未完成的 #53 問題修復分支上繼續工作（圖 3-15）：
 
 	$ git checkout iss53
 	Switched to branch 'iss53'
@@ -189,13 +189,13 @@ Insert 18333fig0314.png
 	 1 file changed, 1 insertion(+)
 
 Insert 18333fig0315.png
-图 3-15. iss53 分支可以不受影响继续推进。
+圖 3-15. iss53 分支可以不受影響繼續推進。
 
-值得注意的是之前 `hotfix` 分支的修改内容尚未包含到 `iss53` 中来。如果需要纳入此次修补，可以用 `git merge master` 把 master 分支合并到 `iss53`；或者等 `iss53` 完成之后，再将 `iss53` 分支中的更新并入 `master`。
+值得注意的是之前 `hotfix` 分支的修改內容尚未包含到 `iss53` 中來。如果需要納入此次修補，可以用 `git merge master` 把 master 分支合併到 `iss53`；或者等 `iss53` 完成之後，再將 `iss53` 分支中的更新併入 `master`。
 
-### 分支的合并 ###
+### 分支的合併 ###
 
-在问题 #53 相关的工作完成之后，可以合并回 `master` 分支。实际操作同前面合并 `hotfix` 分支差不多，只需回到 `master` 分支，运行 `git merge` 命令指定要合并进来的分支：
+在問題 #53 相關的工作完成之後，可以合併回 `master` 分支。實際操作同前面合併 `hotfix` 分支差不多，只需回到 `master` 分支，運行 `git merge` 命令指定要合併進來的分支：
 
 	$ git checkout master
 	$ git merge iss53
@@ -204,32 +204,32 @@ Insert 18333fig0315.png
 	 README | 1 +
 	 1 file changed, 1 insertion(+)
 
-请注意，这次合并操作的底层实现，并不同于之前 `hotfix` 的并入方式。因为这次你的开发历史是从更早的地方开始分叉的。由于当前 `master` 分支所指向的提交对象（C4）并不是 `iss53` 分支的直接祖先，Git 不得不进行一些额外处理。就此例而言，Git 会用两个分支的末端（C4 和 C5）以及它们的共同祖先（C2）进行一次简单的三方合并计算。图 3-16 用红框标出了 Git 用于合并的三个提交对象：
+請注意，這次合併操作的底層實現，並不同於之前 `hotfix` 的併入方式。因為這次你的開發歷史是從更早的地方開始分叉的。由於當前 `master` 分支所指向的提交物件（C4）並不是 `iss53` 分支的直接祖先，Git 不得不進行一些額外處理。就此例而言，Git 會用兩個分支的末端（C4 和 C5）以及它們的共同祖先（C2）進行一次簡單的三方合併計算。圖 3-16 用紅框標出了 Git 用於合併的三個提交對象：
 
 Insert 18333fig0316.png
-图 3-16. Git 为分支合并自动识别出最佳的同源合并点。
+圖 3-16. Git 為分支合併自動識別出最佳的同源合併點。
 
-这次，Git 没有简单地把分支指针右移，而是对三方合并后的结果重新做一个新的快照，并自动创建一个指向它的提交对象（C6）（见图 3-17）。这个提交对象比较特殊，它有两个祖先（C4 和 C5）。
+這次，Git 沒有簡單地把分支指標右移，而是對三方合併後的結果重新做一個新的快照，並自動創建一個指向它的提交物件（C6）（見圖 3-17）。這個提交物件比較特殊，它有兩個祖先（C4 和 C5）。
 
-值得一提的是 Git 可以自己裁决哪个共同祖先才是最佳合并基础；这和 CVS 或 Subversion（1.5 以后的版本）不同，它们需要开发者手工指定合并基础。所以此特性让 Git 的合并操作比其他系统都要简单不少。
+值得一提的是 Git 可以自己裁決哪個共同祖先才是最佳合併基礎；這和 CVS 或 Subversion（1.5 以後的版本）不同，它們需要開發者手工指定合併基礎。所以此特性讓 Git 的合併操作比其他系統都要簡單不少。
 
 Insert 18333fig0317.png
-图 3-17. Git 自动创建了一个包含了合并结果的提交对象。
+圖 3-17. Git 自動創建了一個包含了合併結果的提交物件。
 
-既然之前的工作成果已经合并到 `master` 了，那么 `iss53` 也就没用了。你可以就此删除它，并在问题追踪系统里关闭该问题。
+既然之前的工作成果已經合併到 `master` 了，那麼 `iss53` 也就沒用了。你可以就此刪除它，並在問題追蹤系統裡關閉該問題。
 
 	$ git branch -d iss53
 
-### 遇到冲突时的分支合并 ###
+### 遇到衝突時的分支合併 ###
 
-有时候合并操作并不会如此顺利。如果在不同的分支中都修改了同一个文件的同一部分，Git 就无法干净地把两者合到一起（译注：逻辑上说，这种问题只能由人来裁决。）。如果你在解决问题 #53 的过程中修改了 `hotfix` 中修改的部分，将得到类似下面的结果：
+有時候合併操作並不會如此順利。如果在不同的分支中都修改了同一個檔的同一部分，Git 就無法乾淨地把兩者合到一起（譯注：邏輯上說，這種問題只能由人來裁決。）。如果你在解決問題 #53 的過程中修改了 `hotfix` 中修改的部分，將得到類似下面的結果：
 
 	$ git merge iss53
 	Auto-merging index.html
 	CONFLICT (content): Merge conflict in index.html
 	Automatic merge failed; fix conflicts and then commit the result.
 
-Git 作了合并，但没有提交，它会停下来等你解决冲突。要看看哪些文件在合并时发生冲突，可以用 `git status` 查阅：
+Git 作了合併，但沒有提交，它會停下來等你解決衝突。要看看哪些檔在合併時發生衝突，可以用 `git status` 查閱：
 
 	$ git status
 	On branch master
@@ -243,7 +243,7 @@ Git 作了合并，但没有提交，它会停下来等你解决冲突。要看
 	
 	no changes added to commit (use "git add" and/or "git commit -a")
 
-任何包含未解决冲突的文件都会以未合并（unmerged）的状态列出。Git 会在有冲突的文件里加入标准的冲突解决标记，可以通过它们来手工定位并解决这些冲突。可以看到此文件包含类似下面这样的部分：
+任何包含未解決衝突的檔都會以未合併（unmerged）的狀態列出。Git 會在有衝突的檔裡加入標準的衝突解決標記，可以通過它們來手工定位並解決這些衝突。可以看到此檔包含類似下面這樣的部分：
 
 	<<<<<<< HEAD
 	<div id="footer">contact : email.support@github.com</div>
@@ -253,13 +253,13 @@ Git 作了合并，但没有提交，它会停下来等你解决冲突。要看
 	</div>
 	>>>>>>> iss53
 
-可以看到 `=======` 隔开的上半部分，是 `HEAD`（即 `master` 分支，在运行 `merge` 命令时所切换到的分支）中的内容，下半部分是在 `iss53` 分支中的内容。解决冲突的办法无非是二者选其一或者由你亲自整合到一起。比如你可以通过把这段内容替换为下面这样来解决：
+可以看到 `=======` 隔開的上半部分，是 `HEAD`（即 `master` 分支，在運行 `merge` 命令時所切換到的分支）中的內容，下半部分是在 `iss53` 分支中的內容。解決衝突的辦法無非是二者選其一或者由你親自整合到一起。比如你可以通過把這段內容替換為下面這樣來解決：
 
 	<div id="footer">
 	please contact us at email.support@github.com
 	</div>
 
-这个解决方案各采纳了两个分支中的一部分内容，而且我还删除了 `<<<<<<<`，`=======` 和 `>>>>>>>` 这些行。在解决了所有文件里的所有冲突后，运行 `git add` 将把它们标记为已解决状态（译注：实际上就是来一次快照保存到暂存区域。）。因为一旦暂存，就表示冲突已经解决。如果你想用一个有图形界面的工具来解决这些问题，不妨运行 `git mergetool`，它会调用一个可视化的合并工具并引导你解决所有冲突：
+這個解決方案各採納了兩個分支中的一部分內容，而且我還刪除了 `<<<<<<<`，`=======` 和 `>>>>>>>` 這些行。在解決了所有檔裡的所有衝突後，運行 `git add` 將把它們標記為已解決狀態（譯注：實際上就是來一次快照保存到暫存區域。）。因為一旦暫存，就表示衝突已經解決。如果你想用一個有圖形介面的工具來解決這些問題，不妨運行 `git mergetool`，它會調用一個視覺化的合併工具並引導你解決所有衝突：
 
 	$ git mergetool
 
@@ -275,11 +275,11 @@ Git 作了合并，但没有提交，它会停下来等你解决冲突。要看
 	  {remote}: modified file
 	Hit return to start merge resolution tool (opendiff):
 
-如果不想用默认的合并工具（Git 为我默认选择了 `opendiff`，因为我在 Mac 上运行了该命令），你可以在上方"merge tool candidates"里找到可用的合并工具列表，输入你想用的工具名。我们将在第七章讨论怎样改变环境中的默认值。
+如果不想用默認的合併工具（Git 為我默認選擇了 `opendiff`，因為我在 Mac 上運行了該命令），你可以在上方"merge tool candidates"裡找到可用的合併工具列表，輸入你想用的工具名。我們將在第七章討論怎樣改變環境中的預設值。
 
-退出合并工具以后，Git 会询问你合并是否成功。如果回答是，它会为你把相关文件暂存起来，以表明状态为已解决。
+退出合併工具以後，Git 會詢問你合併是否成功。如果回答是，它會為你把相關檔暫存起來，以表明狀態為已解決。
 
-再运行一次 `git status` 来确认所有冲突都已解决：
+再運行一次 `git status` 來確認所有衝突都已解決：
 
 	$ git status
 	On branch master
@@ -289,7 +289,7 @@ Git 作了合并，但没有提交，它会停下来等你解决冲突。要看
 	        modified:   index.html
 	
 
-如果觉得满意了，并且确认所有冲突都已解决，也就是进入了暂存区，就可以用 `git commit` 来完成这次合并提交。提交的记录差不多是这样：
+如果覺得滿意了，並且確認所有衝突都已解決，也就是進入了暫存區，就可以用 `git commit` 來完成這次合併提交。提交的記錄差不多是這樣：
 
 	Merge branch 'iss53'
 
@@ -302,123 +302,123 @@ Git 作了合并，但没有提交，它会停下来等你解决冲突。要看
 	# and try again.
 	#
 
-如果想给将来看这次合并的人一些方便，可以修改该信息，提供更多合并细节。比如你都作了哪些改动，以及这么做的原因。有时候裁决冲突的理由并不直接或明显，有必要略加注解。
+如果想給將來看這次合併的人一些方便，可以修改該資訊，提供更多合併細節。比如你都作了哪些改動，以及這麼做的原因。有時候裁決衝突的理由並不直接或明顯，有必要略加注解。
 
 ## 分支的管理 ##
 
-到目前为止，你已经学会了如何创建、合并和删除分支。除此之外，我们还需要学习如何管理分支，在日后的常规工作中会经常用到下面介绍的管理命令。
+到目前為止，你已經學會了如何創建、合併和刪除分支。除此之外，我們還需要學習如何管理分支，在日後的常規工作中會經常用到下面介紹的管理命令。
 
-`git branch` 命令不仅仅能创建和删除分支，如果不加任何参数，它会给出当前所有分支的清单：
+`git branch` 命令不僅僅能創建和刪除分支，如果不加任何參數，它會給出當前所有分支的清單：
 
 	$ git branch
 	  iss53
 	* master
 	  testing
 
-注意看 `master` 分支前的 `*` 字符：它表示当前所在的分支。也就是说，如果现在提交更新，`master` 分支将随着开发进度前移。若要查看各个分支最后一个提交对象的信息，运行 `git branch -v`：
+注意看 `master` 分支前的 `*` 字元：它表示當前所在的分支。也就是說，如果現在提交更新，`master` 分支將隨著開發進度前移。若要查看各個分支最後一個提交物件的資訊，運行 `git branch -v`：
 
 	$ git branch -v
 	  iss53   93b412c fix javascript issue
 	* master  7a98805 Merge branch 'iss53'
 	  testing 782fd34 add scott to the author list in the readmes
 
-要从该清单中筛选出你已经（或尚未）与当前分支合并的分支，可以用 `--merged` 和 `--no-merged` 选项（Git 1.5.6 以上版本）。比如用 `git branch --merged` 查看哪些分支已被并入当前分支（译注：也就是说哪些分支是当前分支的直接上游。）：
+要從該清單中篩選出你已經（或尚未）與當前分支合併的分支，可以用 `--merged` 和 `--no-merged` 選項（Git 1.5.6 以上版本）。比如用 `git branch --merged` 查看哪些分支已被併入當前分支（譯注：也就是說哪些分支是當前分支的直接上游。）：
 
 	$ git branch --merged
 	  iss53
 	* master
 
-之前我们已经合并了 `iss53`，所以在这里会看到它。一般来说，列表中没有 `*` 的分支通常都可以用 `git branch -d` 来删掉。原因很简单，既然已经把它们所包含的工作整合到了其他分支，删掉也不会损失什么。
+之前我們已經合併了 `iss53`，所以在這裡會看到它。一般來說，清單中沒有 `*` 的分支通常都可以用 `git branch -d` 來刪掉。原因很簡單，既然已經把它們所包含的工作整合到了其他分支，刪掉也不會損失什麼。
 
-另外可以用 `git branch --no-merged` 查看尚未合并的工作：
+另外可以用 `git branch --no-merged` 查看尚未合併的工作：
 
 	$ git branch --no-merged
 	  testing
 
-它会显示还未合并进来的分支。由于这些分支中还包含着尚未合并进来的工作成果，所以简单地用 `git branch -d` 删除该分支会提示错误，因为那样做会丢失数据：
+它會顯示還未合併進來的分支。由於這些分支中還包含著尚未合併進來的工作成果，所以簡單地用 `git branch -d` 刪除該分支會提示錯誤，因為那樣做會丟失資料：
 
 	$ git branch -d testing
 	error: The branch 'testing' is not fully merged.
 	If you are sure you want to delete it, run 'git branch -D testing'.
 
-不过，如果你确实想要删除该分支上的改动，可以用大写的删除选项 `-D` 强制执行，就像上面提示信息中给出的那样。
+不過，如果你確實想要刪除該分支上的改動，可以用大寫的刪除選項 `-D` 強制執行，就像上面提示資訊中給出的那樣。
 
-## 利用分支进行开发的工作流程 ##
+## 利用分支進行開發的工作流程 ##
 
-现在我们已经学会了新建分支和合并分支，可以（或应该）用它来做点什么呢？在本节，我们会介绍一些利用分支进行开发的工作流程。而正是由于分支管理的便捷，才衍生出了这类典型的工作模式，你可以根据项目的实际情况选择一种用用看。
+現在我們已經學會了新建分支和合併分支，可以（或應該）用它來做點什麼呢？在本節，我們會介紹一些利用分支進行開發的工作流程。而正是由於分支管理的便捷，才衍生出了這類典型的工作模式，你可以根據專案的實際情況選擇一種用用看。
 
-### 长期分支 ###
+### 長期分支 ###
 
-由于 Git 使用简单的三方合并，所以就算在较长一段时间内，反复多次把某个分支合并到另一分支，也不是什么难事。也就是说，你可以同时拥有多个开放的分支，每个分支用于完成特定的任务，随着开发的推进，你可以随时把某个特性分支的成果并到其他分支中。
+由於 Git 使用簡單的三方合併，所以就算在較長一段時間內，反復多次把某個分支合併到另一分支，也不是什麼難事。也就是說，你可以同時擁有多個開放的分支，每個分支用於完成特定的任務，隨著開發的推進，你可以隨時把某個特性分支的成果並到其他分支中。
 
-许多使用 Git 的开发者都喜欢用这种方式来开展工作，比如仅在 `master` 分支中保留完全稳定的代码，即已经发布或即将发布的代码。与此同时，他们还有一个名为 `develop` 或 `next` 的平行分支，专门用于后续的开发，或仅用于稳定性测试 — 当然并不是说一定要绝对稳定，不过一旦进入某种稳定状态，便可以把它合并到 `master` 里。这样，在确保这些已完成的特性分支（短期分支，比如之前的 `iss53` 分支）能够通过所有测试，并且不会引入更多错误之后，就可以并到主干分支中，等待下一次的发布。
+許多使用 Git 的開發者都喜歡用這種方式來開展工作，比如僅在 `master` 分支中保留完全穩定的代碼，即已經發佈或即將發佈的代碼。與此同時，他們還有一個名為 `develop` 或 `next` 的平行分支，專門用於後續的開發，或僅用於穩定性測試 — 當然並不是說一定要絕對穩定，不過一旦進入某種穩定狀態，便可以把它合併到 `master` 裡。這樣，在確保這些已完成的特性分支（短期分支，比如之前的 `iss53` 分支）能夠通過所有測試，並且不會引入更多錯誤之後，就可以並到主幹分支中，等待下一次的發佈。
 
-本质上我们刚才谈论的，是随着提交对象不断右移的指针。稳定分支的指针总是在提交历史中落后一大截，而前沿分支总是比较靠前（见图 3-18）。
+本質上我們剛才談論的，是隨著提交物件不斷右移的指標。穩定分支的指標總是在提交歷史中落後一大截，而前沿分支總是比較靠前（見圖 3-18）。
 
 Insert 18333fig0318.png
-图 3-18. 稳定分支总是比较老旧。
+圖 3-18. 穩定分支總是比較老舊。
 
-或者把它们想象成工作流水线，或许更好理解一些，经过测试的提交对象集合被遴选到更稳定的流水线（见图 3-19）。
+或者把它們想像成工作流水線，或許更好理解一些，經過測試的提交物件集合被遴選到更穩定的流水線（見圖 3-19）。
 
 Insert 18333fig0319.png
-图 3-19. 想象成流水线可能会容易点。
+圖 3-19. 想像成流水線可能會容易點。
 
-你可以用这招维护不同层次的稳定性。某些大项目还会有个 `proposed`（建议）或 `pu`（proposed updates，建议更新）分支，它包含着那些可能还没有成熟到进入 `next` 或 `master` 的内容。这么做的目的是拥有不同层次的稳定性：当这些分支进入到更稳定的水平时，再把它们合并到更高层分支中去。再次说明下，使用多个长期分支的做法并非必需，不过一般来说，对于特大型项目或特复杂的项目，这么做确实更容易管理。
+你可以用這招維護不同層次的穩定性。某些大專案還會有個 `proposed`（建議）或 `pu`（proposed updates，建議更新）分支，它包含著那些可能還沒有成熟到進入 `next` 或 `master` 的內容。這麼做的目的是擁有不同層次的穩定性：當這些分支進入到更穩定的水準時，再把它們合併到更高層分支中去。再次說明下，使用多個長期分支的做法並非必需，不過一般來說，對於特大型項目或特複雜的專案，這麼做確實更容易管理。
 
 ### 特性分支 ###
 
-在任何规模的项目中都可以使用特性（Topic）分支。一个特性分支是指一个短期的，用来实现单一特性或与其相关工作的分支。可能你在以前的版本控制系统里从未做过类似这样的事情，因为通常创建与合并分支消耗太大。然而在 Git 中，一天之内建立、使用、合并再删除多个分支是常见的事。
+在任何規模的專案中都可以使用特性（Topic）分支。一個特性分支是指一個短期的，用來實現單一特性或與其相關工作的分支。可能你在以前的版本控制系統裡從未做過類似這樣的事情，因為通常創建與合併分支消耗太大。然而在 Git 中，一天之內建立、使用、合併再刪除多個分支是常見的事。
 
-我们在上节的例子里已经见过这种用法了。我们创建了 `iss53` 和 `hotfix` 这两个特性分支，在提交了若干更新后，把它们合并到主干分支，然后删除。该技术允许你迅速且完全的进行语境切换 — 因为你的工作分散在不同的流水线里，每个分支里的改变都和它的目标特性相关，浏览代码之类的事情因而变得更简单了。你可以把作出的改变保持在特性分支中几分钟，几天甚至几个月，等它们成熟以后再合并，而不用在乎它们建立的顺序或者进度。
+我們在上節的例子裡已經見過這種用法了。我們創建了 `iss53` 和 `hotfix` 這兩個特性分支，在提交了若干更新後，把它們合併到主幹分支，然後刪除。該技術允許你迅速且完全的進行語境切換 — 因為你的工作分散在不同的流水線裡，每個分支裡的改變都和它的目標特性相關，流覽代碼之類的事情因而變得更簡單了。你可以把作出的改變保持在特性分支中幾分鐘，幾天甚至幾個月，等它們成熟以後再合併，而不用在乎它們建立的順序或者進度。
 
-现在我们来看一个实际的例子。请看图 3-20，由下往上，起先我们在 `master` 工作到 C1，然后开始一个新分支 `iss91` 尝试修复 91 号缺陷，提交到 C6 的时候，又冒出一个解决该问题的新办法，于是从之前 C4 的地方又分出一个分支 `iss91v2`，干到 C8 的时候，又回到主干 `master` 中提交了 C9 和 C10，再回到 `iss91v2` 继续工作，提交 C11，接着，又冒出个不太确定的想法，从 `master` 的最新提交 C10 处开了个新的分支 `dumbidea` 做些试验。
+現在我們來看一個實際的例子。請看圖 3-20，由下往上，起先我們在 `master` 工作到 C1，然後開始一個新分支 `iss91` 嘗試修復 91 號缺陷，提交到 C6 的時候，又冒出一個解決該問題的新辦法，於是從之前 C4 的地方又分出一個分支 `iss91v2`，幹到 C8 的時候，又回到主幹 `master` 中提交了 C9 和 C10，再回到 `iss91v2` 繼續工作，提交 C11，接著，又冒出個不太確定的想法，從 `master` 的最新提交 C10 處開了個新的分支 `dumbidea` 做些試驗。
 
 Insert 18333fig0320.png
-图 3-20. 拥有多个特性分支的提交历史。
+圖 3-20. 擁有多個特性分支的提交歷史。
 
-现在，假定两件事情：我们最终决定使用第二个解决方案，即 `iss91v2` 中的办法；另外，我们把 `dumbidea` 分支拿给同事们看了以后，发现它竟然是个天才之作。所以接下来，我们准备抛弃原来的 `iss91` 分支（实际上会丢弃 C5 和 C6），直接在主干中并入另外两个分支。最终的提交历史将变成图 3-21 这样：
+現在，假定兩件事情：我們最終決定使用第二個解決方案，即 `iss91v2` 中的辦法；另外，我們把 `dumbidea` 分支拿給同事們看了以後，發現它竟然是個天才之作。所以接下來，我們準備拋棄原來的 `iss91` 分支（實際上會丟棄 C5 和 C6），直接在主幹中併入另外兩個分支。最終的提交歷史將變成圖 3-21 這樣：
 
 Insert 18333fig0321.png
-图 3-21. 合并了 dumbidea 和 iss91v2 后的分支历史。
+圖 3-21. 合併了 dumbidea 和 iss91v2 後的分支歷史。
 
-请务必牢记这些分支全部都是本地分支，这一点很重要。当你在使用分支及合并的时候，一切都是在你自己的 Git 仓库中进行的 — 完全不涉及与服务器的交互。
+請務必牢記這些分支全部都是本地分支，這一點很重要。當你在使用分支及合併的時候，一切都是在你自己的 Git 倉庫中進行的 — 完全不涉及與伺服器的交互。
 
-## 远程分支 ##
+## 遠端分支 ##
 
-远程分支（remote branch）是对远程仓库中的分支的索引。它们是一些无法移动的本地分支；只有在 Git 进行网络交互时才会更新。远程分支就像是书签，提醒着你上次连接远程仓库时上面各分支的位置。 
+遠端分支（remote branch）是對遠端倉庫中的分支的索引。它們是一些無法移動的本地分支；只有在 Git 進行網路交互時才會更新。遠端分支就像是書簽，提醒著你上次連接遠端倉庫時上面各分支的位置。 
 
-我们用 `(远程仓库名)/(分支名)` 这样的形式表示远程分支。比如我们想看看上次同 `origin` 仓库通讯时 `master` 分支的样子，就应该查看 `origin/master` 分支。如果你和同伴一起修复某个问题，但他们先推送了一个 `iss53` 分支到远程仓库，虽然你可能也有一个本地的 `iss53` 分支，但指向服务器上最新更新的却应该是 `origin/iss53` 分支。
+我們用 `(遠端倉庫名)/(分支名)` 這樣的形式表示遠端分支。比如我們想看看上次同 `origin` 倉庫通訊時 `master` 分支的樣子，就應該查看 `origin/master` 分支。如果你和同伴一起修復某個問題，但他們先推送了一個 `iss53` 分支到遠端倉庫，雖然你可能也有一個本地的 `iss53` 分支，但指向伺服器上最新更新的卻應該是 `origin/iss53` 分支。
 
-可能有点乱，我们不妨举例说明。假设你们团队有个地址为 `git.ourcompany.com` 的 Git 服务器。如果你从这里克隆，Git 会自动为你将此远程仓库命名为 `origin`，并下载其中所有的数据，建立一个指向它的 `master` 分支的指针，在本地命名为 `origin/master`，但你无法在本地更改其数据。接着，Git 建立一个属于你自己的本地 `master` 分支，始于 `origin` 上 `master` 分支相同的位置，你可以就此开始工作（见图 3-22）：
+可能有點亂，我們不妨舉例說明。假設你們團隊有個地址為 `git.ourcompany.com` 的 Git 伺服器。如果你從這裡克隆，Git 會自動為你將此遠端倉庫命名為 `origin`，並下載其中所有的資料，建立一個指向它的 `master` 分支的指標，在本地命名為 `origin/master`，但你無法在本地更改其資料。接著，Git 建立一個屬於你自己的本地 `master` 分支，始於 `origin` 上 `master` 分支相同的位置，你可以就此開始工作（見圖 3-22）：
 
 Insert 18333fig0322.png
-图 3-22. 一次 Git 克隆会建立你自己的本地分支 master 和远程分支 origin/master，并且将它们都指向 `origin` 上的 `master` 分支。
+圖 3-22. 一次 Git 克隆會建立你自己的本地分支 master 和遠端分支 origin/master，並且將它們都指向 `origin` 上的 `master` 分支。
 
-如果你在本地 `master` 分支做了些改动，与此同时，其他人向 `git.ourcompany.com` 推送了他们的更新，那么服务器上的 `master` 分支就会向前推进，而于此同时，你在本地的提交历史正朝向不同方向发展。不过只要你不和服务器通讯，你的 `origin/master` 指针仍然保持原位不会移动（见图 3-23）。
+如果你在本地 `master` 分支做了些改動，與此同時，其他人向 `git.ourcompany.com` 推送了他們的更新，那麼伺服器上的 `master` 分支就會向前推進，而於此同時，你在本地的提交歷史正朝向不同方向發展。不過只要你不和伺服器通訊，你的 `origin/master` 指標仍然保持原位不會移動（見圖 3-23）。
 
 Insert 18333fig0323.png
-图 3-23. 在本地工作的同时有人向远程仓库推送内容会让提交历史开始分流。
+圖 3-23. 在本地工作的同時有人向遠端倉庫推送內容會讓提交歷史開始分流。
 
-可以运行 `git fetch origin` 来同步远程服务器上的数据到本地。该命令首先找到 `origin` 是哪个服务器（本例为 `git.ourcompany.com`），从上面获取你尚未拥有的数据，更新你本地的数据库，然后把 `origin/master` 的指针移到它最新的位置上（见图 3-24）。
+可以運行 `git fetch origin` 來同步遠端伺服器上的資料到本地。該命令首先找到 `origin` 是哪個伺服器（本例為 `git.ourcompany.com`），從上面獲取你尚未擁有的資料，更新你本地的資料庫，然後把 `origin/master` 的指針移到它最新的位置上（見圖 3-24）。
 
 Insert 18333fig0324.png
-图 3-24. git fetch 命令会更新 remote 索引。
+圖 3-24. git fetch 命令會更新 remote 索引。
 
-为了演示拥有多个远程分支（在不同的远程服务器上）的项目是如何工作的，我们假设你还有另一个仅供你的敏捷开发小组使用的内部服务器 `git.team1.ourcompany.com`。可以用第二章中提到的 `git remote add` 命令把它加为当前项目的远程分支之一。我们把它命名为 `teamone`，以便代替完整的 Git URL 以方便使用（见图 3-25）。
+為了演示擁有多個遠端分支（在不同的遠端伺服器上）的專案是如何工作的，我們假設你還有另一個僅供你的敏捷開發小組使用的內部伺服器 `git.team1.ourcompany.com`。可以用第二章中提到的 `git remote add` 命令把它加為當前專案的遠端分支之一。我們把它命名為 `teamone`，以便代替完整的 Git URL 以方便使用（見圖 3-25）。
 
 Insert 18333fig0325.png
-图 3-25. 把另一个服务器加为远程仓库
+圖 3-25. 把另一個伺服器加為遠端倉庫
 
-现在你可以用 `git fetch teamone` 来获取小组服务器上你还没有的数据了。由于当前该服务器上的内容是你 `origin` 服务器上的子集，Git 不会下载任何数据，而只是简单地创建一个名为 `teamone/master` 的远程分支，指向 `teamone` 服务器上 `master` 分支所在的提交对象 `31b8e`（见图 3-26）。
+現在你可以用 `git fetch teamone` 來獲取小組伺服器上你還沒有的資料了。由於當前該伺服器上的內容是你 `origin` 伺服器上的子集，Git 不會下載任何資料，而只是簡單地創建一個名為 `teamone/master` 的遠端分支，指向 `teamone` 伺服器上 `master` 分支所在的提交物件 `31b8e`（見圖 3-26）。
 
 Insert 18333fig0326.png
-图 3-26. 你在本地有了一个指向 teamone 服务器上 master 分支的索引。
+圖 3-26. 你在本地有了一個指向 teamone 伺服器上 master 分支的索引。
 
 ### 推送本地分支 ###
 
-要想和其他人分享某个本地分支，你需要把它推送到一个你拥有写权限的远程仓库。你创建的本地分支不会因为你的写入操作而被自动同步到你引入的远程服务器上，你需要明确地执行推送分支的操作。换句话说，对于无意分享的分支，你尽管保留为私人分支好了，而只推送那些协同工作要用到的特性分支。
+要想和其他人分享某個本地分支，你需要把它推送到一個你擁有寫許可權的遠端倉庫。你創建的本地分支不會因為你的寫入操作而被自動同步到你引入的遠端伺服器上，你需要明確地執行推送分支的操作。換句話說，對於無意分享的分支，你儘管保留為私人分支好了，而只推送那些協同工作要用到的特性分支。
 
-如果你有个叫 `serverfix` 的分支需要和他人一起开发，可以运行 `git push (远程仓库名) (分支名)`：
+如果你有個叫 `serverfix` 的分支需要和他人一起開發，可以運行 `git push (遠端倉庫名) (分支名)`：
 
 	$ git push origin serverfix
 	Counting objects: 20, done.
@@ -428,9 +428,9 @@ Insert 18333fig0326.png
 	To git@github.com:schacon/simplegit.git
 	 * [new branch]      serverfix -> serverfix
 
-这里其实走了一点捷径。Git 自动把 `serverfix` 分支名扩展为 `refs/heads/serverfix:refs/heads/serverfix`，意为“取出我在本地的 serverfix 分支，推送到远程仓库的 serverfix 分支中去”。我们将在第九章进一步介绍 `refs/heads/` 部分的细节，不过一般使用的时候都可以省略它。也可以运行 `git push origin serverfix:serverfix` 来实现相同的效果，它的意思是“上传我本地的 serverfix 分支到远程仓库中去，仍旧称它为 serverfix 分支”。通过此语法，你可以把本地分支推送到某个命名不同的远程分支：若想把远程分支叫作 `awesomebranch`，可以用 `git push origin serverfix:awesomebranch` 来推送数据。
+這裡其實走了一點捷徑。Git 自動把 `serverfix` 分支名擴展為 `refs/heads/serverfix:refs/heads/serverfix`，意為“取出我在本地的 serverfix 分支，推送到遠端倉庫的 serverfix 分支中去”。我們將在第九章進一步介紹 `refs/heads/` 部分的細節，不過一般使用的時候都可以省略它。也可以運行 `git push origin serverfix:serverfix` 來實現相同的效果，它的意思是“上傳我本地的 serverfix 分支到遠端倉庫中去，仍舊稱它為 serverfix 分支”。通過此語法，你可以把本地分支推送到某個命名不同的遠端分支：若想把遠端分支叫作 `awesomebranch`，可以用 `git push origin serverfix:awesomebranch` 來推送數據。
 
-接下来，当你的协作者再次从服务器上获取数据时，他们将得到一个新的远程分支 `origin/serverfix`，并指向服务器上 `serverfix` 所指向的版本：
+接下來，當你的協作者再次從伺服器上獲取資料時，他們將得到一個新的遠端分支 `origin/serverfix`，並指向伺服器上 `serverfix` 所指向的版本：
 
 	$ git fetch origin
 	remote: Counting objects: 20, done.
@@ -440,165 +440,165 @@ Insert 18333fig0326.png
 	From git@github.com:schacon/simplegit
 	 * [new branch]      serverfix    -> origin/serverfix
 
-值得注意的是，在 `fetch` 操作下载好新的远程分支之后，你仍然无法在本地编辑该远程仓库中的分支。换句话说，在本例中，你不会有一个新的 `serverfix` 分支，有的只是一个你无法移动的 `origin/serverfix` 指针。
+值得注意的是，在 `fetch` 操作下載好新的遠端分支之後，你仍然無法在本地編輯該遠端倉庫中的分支。換句話說，在本例中，你不會有一個新的 `serverfix` 分支，有的只是一個你無法移動的 `origin/serverfix` 指標。
 
-如果要把该远程分支的内容合并到当前分支，可以运行 `git merge origin/serverfix`。如果想要一份自己的 `serverfix` 来开发，可以在远程分支的基础上分化出一个新的分支来：
+如果要把該遠端分支的內容合併到當前分支，可以運行 `git merge origin/serverfix`。如果想要一份自己的 `serverfix` 來開發，可以在遠端分支的基礎上分化出一個新的分支來：
 
 	$ git checkout -b serverfix origin/serverfix
 	Branch serverfix set up to track remote branch serverfix from origin.
 	Switched to a new branch 'serverfix'
 
-这会切换到新建的 `serverfix` 本地分支，其内容同远程分支 `origin/serverfix` 一致，这样你就可以在里面继续开发了。
+這會切換到新建的 `serverfix` 本地分支，其內容同遠端分支 `origin/serverfix` 一致，這樣你就可以在裡面繼續開發了。
 
-### 跟踪远程分支 ###
+### 跟蹤遠端分支 ###
 
-从远程分支 `checkout` 出来的本地分支，称为 _跟踪分支_ (tracking branch)。跟踪分支是一种和某个远程分支有直接联系的本地分支。在跟踪分支里输入 `git push`，Git 会自行推断应该向哪个服务器的哪个分支推送数据。同样，在这些分支里运行 `git pull` 会获取所有远程索引，并把它们的数据都合并到本地分支中来。
+從遠端分支 `checkout` 出來的本地分支，稱為 _跟蹤分支_ (tracking branch)。跟蹤分支是一種和某個遠端分支有直接聯繫的本地分支。在跟蹤分支裡輸入 `git push`，Git 會自行推斷應該向哪個伺服器的哪個分支推送資料。同樣，在這些分支裡運行 `git pull` 會獲取所有遠端索引，並把它們的資料都合併到本地分支中來。
 
-在克隆仓库时，Git 通常会自动创建一个名为 `master` 的分支来跟踪 `origin/master`。这正是 `git push` 和 `git pull` 一开始就能正常工作的原因。当然，你可以随心所欲地设定为其它跟踪分支，比如 `origin` 上除了 `master` 之外的其它分支。刚才我们已经看到了这样的一个例子：`git checkout -b [分支名] [远程名]/[分支名]`。如果你有 1.6.2 以上版本的 Git，还可以用 `--track` 选项简化：
+在克隆倉庫時，Git 通常會自動創建一個名為 `master` 的分支來跟蹤 `origin/master`。這正是 `git push` 和 `git pull` 一開始就能正常工作的原因。當然，你可以隨心所欲地設定為其它跟蹤分支，比如 `origin` 上除了 `master` 之外的其它分支。剛才我們已經看到了這樣的一個例子：`git checkout -b [分支名] [遠端名]/[分支名]`。如果你有 1.6.2 以上版本的 Git，還可以用 `--track` 選項簡化：
 
 	$ git checkout --track origin/serverfix
 	Branch serverfix set up to track remote branch serverfix from origin.
 	Switched to a new branch 'serverfix'
 
-要为本地分支设定不同于远程分支的名字，只需在第一个版本的命令里换个名字：
+要為本地分支設定不同于遠端分支的名字，只需在第一個版本的命令裡換個名字：
 
 	$ git checkout -b sf origin/serverfix
 	Branch sf set up to track remote branch serverfix from origin.
 	Switched to a new branch 'sf'
 
-现在你的本地分支 `sf` 会自动将推送和抓取数据的位置定位到 `origin/serverfix` 了。
+現在你的本地分支 `sf` 會自動將推送和抓取資料的位置定位到 `origin/serverfix` 了。
 
-### 删除远程分支 ###
+### 刪除遠端分支 ###
 
-如果不再需要某个远程分支了，比如搞定了某个特性并把它合并进了远程的 `master` 分支（或任何其他存放稳定代码的分支），可以用这个非常无厘头的语法来删除它：`git push [远程名] :[分支名]`。如果想在服务器上删除 `serverfix` 分支，运行下面的命令：
+如果不再需要某個遠端分支了，比如搞定了某個特性並把它合併進了遠端的 `master` 分支（或任何其他存放穩定代碼的分支），可以用這個非常無厘頭的語法來刪除它：`git push [遠程名] :[分支名]`。如果想在伺服器上刪除 `serverfix` 分支，運行下面的命令：
 
 	$ git push origin :serverfix
 	To git@github.com:schacon/simplegit.git
 	 - [deleted]         serverfix
 
-咚！服务器上的分支没了。你最好特别留心这一页，因为你一定会用到那个命令，而且你很可能会忘掉它的语法。有种方便记忆这条命令的方法：记住我们不久前见过的 `git push [远程名] [本地分支]:[远程分支]` 语法，如果省略 `[本地分支]`，那就等于是在说“在这里提取空白然后把它变成`[远程分支]`”。
+咚！伺服器上的分支沒了。你最好特別留心這一頁，因為你一定會用到那個命令，而且你很可能會忘掉它的語法。有種方便記憶這條命令的方法：記住我們不久前見過的 `git push [遠端名] [本地分支]:[遠端分支]` 語法，如果省略 `[本地分支]`，那就等於是在說“在這裡提取空白然後把它變成`[遠端分支]`”。
 
 ## 分支的衍合 ##
 
-把一个分支中的修改整合到另一个分支的办法有两种：`merge` 和 `rebase`（译注：`rebase` 的翻译暂定为“衍合”，大家知道就可以了。）。在本章我们会学习什么是衍合，如何使用衍合，为什么衍合操作如此富有魅力，以及我们应该在什么情况下使用衍合。
+把一個分支中的修改整合到另一個分支的辦法有兩種：`merge` 和 `rebase`（譯注：`rebase` 的翻譯暫定為“衍合”，大家知道就可以了。）。在本章我們會學習什麼是衍合，如何使用衍合，為什麼衍合操作如此富有魅力，以及我們應該在什麼情況下使用衍合。
 
 ### 基本的衍合操作 ###
 
-请回顾之前有关合并的一节（见图 3-27），你会看到开发进程分叉到两个不同分支，又各自提交了更新。
+請回顧之前有關合併的一節（見圖 3-27），你會看到開發進程分叉到兩個不同分支，又各自提交了更新。
 
 Insert 18333fig0327.png
-图 3-27. 最初分叉的提交历史。
+圖 3-27. 最初分叉的提交歷史。
 
-之前介绍过，最容易的整合分支的方法是 `merge` 命令，它会把两个分支最新的快照（C3 和 C4）以及二者最新的共同祖先（C2）进行三方合并，合并的结果是产生一个新的提交对象（C5）。如图 3-28 所示：
+之前介紹過，最容易的整合分支的方法是 `merge` 命令，它會把兩個分支最新的快照（C3 和 C4）以及二者最新的共同祖先（C2）進行三方合併，合併的結果是產生一個新的提交物件（C5）。如圖 3-28 所示：
 
 Insert 18333fig0328.png
-图 3-28. 通过合并一个分支来整合分叉了的历史。
+圖 3-28. 通過合併一個分支來整合分叉了的歷史。
 
-其实，还有另外一个选择：你可以把在 C3 里产生的变化补丁在 C4 的基础上重新打一遍。在 Git 里，这种操作叫做_衍合（rebase）_。有了 `rebase` 命令，就可以把在一个分支里提交的改变移到另一个分支里重放一遍。
+其實，還有另外一個選擇：你可以把在 C3 裡產生的變化補丁在 C4 的基礎上重新打一遍。在 Git 裡，這種操作叫做_衍合（rebase）_。有了 `rebase` 命令，就可以把在一個分支裡提交的改變移到另一個分支裡重放一遍。
 
-在上面这个例子中，运行：
+在上面這個例子中，運行：
 
 	$ git checkout experiment
 	$ git rebase master
 	First, rewinding head to replay your work on top of it...
 	Applying: added staged command
 
-它的原理是回到两个分支最近的共同祖先，根据当前分支（也就是要进行衍合的分支 `experiment`）后续的历次提交对象（这里只有一个 C3），生成一系列文件补丁，然后以基底分支（也就是主干分支 `master`）最后一个提交对象（C4）为新的出发点，逐个应用之前准备好的补丁文件，最后会生成一个新的合并提交对象（C3'），从而改写 `experiment` 的提交历史，使它成为 `master` 分支的直接下游，如图 3-29 所示：
+它的原理是回到兩個分支最近的共同祖先，根據當前分支（也就是要進行衍合的分支 `experiment`）後續的歷次提交物件（這裡只有一個 C3），生成一系列檔補丁，然後以基底分支（也就是主幹分支 `master`）最後一個提交物件（C4）為新的出發點，逐個應用之前準備好的補丁檔，最後會生成一個新的合併提交物件（C3'），從而改寫 `experiment` 的提交歷史，使它成為 `master` 分支的直接下游，如圖 3-29 所示：
 
 Insert 18333fig0329.png
-图 3-29. 把 C3 里产生的改变到 C4 上重演一遍。
+圖 3-29. 把 C3 裡產生的改變到 C4 上重演一遍。
 
-现在回到 `master` 分支，进行一次快进合并（见图 3-30）：
+現在回到 `master` 分支，進行一次快進合併（見圖 3-30）：
 
 Insert 18333fig0330.png
-图 3-30. master 分支的快进。
+圖 3-30. master 分支的快進。
 
-现在的 C3' 对应的快照，其实和普通的三方合并，即上个例子中的 C5 对应的快照内容一模一样了。虽然最后整合得到的结果没有任何区别，但衍合能产生一个更为整洁的提交历史。如果视察一个衍合过的分支的历史记录，看起来会更清楚：仿佛所有修改都是在一根线上先后进行的，尽管实际上它们原本是同时并行发生的。
+現在的 C3' 對應的快照，其實和普通的三方合併，即上個例子中的 C5 對應的快照內容一模一樣了。雖然最後整合得到的結果沒有任何區別，但衍合能產生一個更為整潔的提交歷史。如果視察一個衍合過的分支的歷史記錄，看起來會更清楚：仿佛所有修改都是在一根線上先後進行的，儘管實際上它們原本是同時並行發生的。
 
-一般我们使用衍合的目的，是想要得到一个能在远程分支上干净应用的补丁 — 比如某些项目你不是维护者，但想帮点忙的话，最好用衍合：先在自己的一个分支里进行开发，当准备向主项目提交补丁的时候，根据最新的 `origin/master` 进行一次衍合操作然后再提交，这样维护者就不需要做任何整合工作（译注：实际上是把解决分支补丁同最新主干代码之间冲突的责任，化转为由提交补丁的人来解决。），只需根据你提供的仓库地址作一次快进合并，或者直接采纳你提交的补丁。
+一般我們使用衍合的目的，是想要得到一個能在遠端分支上乾淨應用的補丁 — 比如某些項目你不是維護者，但想幫點忙的話，最好用衍合：先在自己的一個分支裡進行開發，當準備向主專案提交補丁的時候，根據最新的 `origin/master` 進行一次衍合操作然後再提交，這樣維護者就不需要做任何整合工作（譯注：實際上是把解決分支補丁同最新主幹代碼之間衝突的責任，化轉為由提交補丁的人來解決。），只需根據你提供的倉庫位址作一次快進合併，或者直接採納你提交的補丁。
 
-请注意，合并结果中最后一次提交所指向的快照，无论是通过衍合，还是三方合并，都会得到相同的快照内容，只不过提交历史不同罢了。衍合是按照每行的修改次序重演一遍修改，而合并是把最终结果合在一起。
+請注意，合併結果中最後一次提交所指向的快照，無論是通過衍合，還是三方合併，都會得到相同的快照內容，只不過提交歷史不同罷了。衍合是按照每行的修改次序重演一遍修改，而合併是把最終結果合在一起。
 
 ### 有趣的衍合 ###
 
-衍合也可以放到其他分支进行，并不一定非得根据分化之前的分支。以图 3-31 的历史为例，我们为了给服务器端代码添加一些功能而创建了特性分支 `server`，然后提交 C3 和 C4。然后又从 C3 的地方再增加一个 `client` 分支来对客户端代码进行一些相应修改，所以提交了 C8 和 C9。最后，又回到 `server` 分支提交了 C10。
+衍合也可以放到其他分支進行，並不一定非得根據分化之前的分支。以圖 3-31 的歷史為例，我們為了給伺服器端代碼添加一些功能而創建了特性分支 `server`，然後提交 C3 和 C4。然後又從 C3 的地方再增加一個 `client` 分支來對用戶端代碼進行一些相應修改，所以提交了 C8 和 C9。最後，又回到 `server` 分支提交了 C10。
 
 Insert 18333fig0331.png
-图 3-31. 从一个特性分支里再分出一个特性分支的历史。
+圖 3-31. 從一個特性分支裡再分出一個特性分支的歷史。
 
-假设在接下来的一次软件发布中，我们决定先把客户端的修改并到主线中，而暂缓并入服务端软件的修改（因为还需要进一步测试）。这个时候，我们就可以把基于 `server` 分支而非 `master` 分支的改变（即 C8 和 C9），跳过 `server` 直接放到 `master` 分支中重演一遍，但这需要用 `git rebase` 的 `--onto` 选项指定新的基底分支 `master`：
+假設在接下來的一次軟體發佈中，我們決定先把用戶端的修改並到主線中，而暫緩併入服務端軟體的修改（因為還需要進一步測試）。這個時候，我們就可以把基於 `server` 分支而非 `master` 分支的改變（即 C8 和 C9），跳過 `server` 直接放到 `master` 分支中重演一遍，但這需要用 `git rebase` 的 `--onto` 選項指定新的基底分支 `master`：
 
 	$ git rebase --onto master server client
 
-这好比在说：“取出 `client` 分支，找出 `client` 分支和 `server` 分支的共同祖先之后的变化，然后把它们在 `master` 上重演一遍”。是不是有点复杂？不过它的结果如图 3-32 所示，非常酷（译注：虽然 `client` 里的 C8, C9 在 C3 之后，但这仅表明时间上的先后，而非在 C3 修改的基础上进一步改动，因为 `server` 和 `client` 这两个分支对应的代码应该是两套文件，虽然这么说不是很严格，但应理解为在 C3 时间点之后，对另外的文件所做的 C8，C9 修改，放到主干重演。）：
+這好比在說：“取出 `client` 分支，找出 `client` 分支和 `server` 分支的共同祖先之後的變化，然後把它們在 `master` 上重演一遍”。是不是有點複雜？不過它的結果如圖 3-32 所示，非常酷（譯注：雖然 `client` 裡的 C8, C9 在 C3 之後，但這僅表明時間上的先後，而非在 C3 修改的基礎上進一步改動，因為 `server` 和 `client` 這兩個分支對應的代碼應該是兩套檔，雖然這麼說不是很嚴格，但應理解為在 C3 時間點之後，對另外的檔所做的 C8，C9 修改，放到主幹重演。）：
 
 Insert 18333fig0332.png
-图 3-32. 将特性分支上的另一个特性分支衍合到其他分支。
+圖 3-32. 將特性分支上的另一個特性分支衍合到其他分支。
 
-现在可以快进 `master` 分支了（见图 3-33）：
+現在可以快進 `master` 分支了（見圖 3-33）：
 
 	$ git checkout master
 	$ git merge client
 
 Insert 18333fig0333.png
-图 3-33. 快进 master 分支，使之包含 client 分支的变化。
+圖 3-33. 快進 master 分支，使之包含 client 分支的變化。
 
-现在我们决定把 `server` 分支的变化也包含进来。我们可以直接把 `server` 分支衍合到 `master`，而不用手工切换到 `server` 分支后再执行衍合操作 — `git rebase [主分支] [特性分支]` 命令会先取出特性分支 `server`，然后在主分支 `master` 上重演：
+現在我們決定把 `server` 分支的變化也包含進來。我們可以直接把 `server` 分支衍合到 `master`，而不用手工切換到 `server` 分支後再執行衍合操作 — `git rebase [主分支] [特性分支]` 命令會先取出特性分支 `server`，然後在主分支 `master` 上重演：
 
 	$ git rebase master server
 
-于是，`server` 的进度应用到 `master` 的基础上，如图 3-34 所示：
+於是，`server` 的進度應用到 `master` 的基礎上，如圖 3-34 所示：
 
 Insert 18333fig0334.png
-图 3-34. 在 master 分支上衍合 server 分支。
+圖 3-34. 在 master 分支上衍合 server 分支。
 
-然后就可以快进主干分支 `master` 了：
+然後就可以快進主幹分支 `master` 了：
 
 	$ git checkout master
 	$ git merge server
 
-现在 `client` 和 `server` 分支的变化都已经集成到主干分支来了，可以删掉它们了。最终我们的提交历史会变成图 3-35 的样子：
+現在 `client` 和 `server` 分支的變化都已經集成到主幹分支來了，可以刪掉它們了。最終我們的提交歷史會變成圖 3-35 的樣子：
 
 	$ git branch -d client
 	$ git branch -d server
 
 Insert 18333fig0335.png
-图 3-35. 最终的提交历史
+圖 3-35. 最終的提交歷史
 
-### 衍合的风险 ###
+### 衍合的風險 ###
 
-呃，奇妙的衍合也并非完美无缺，要用它得遵守一条准则：
+呃，奇妙的衍合也並非完美無缺，要用它得遵守一條準則：
 
-**一旦分支中的提交对象发布到公共仓库，就千万不要对该分支进行衍合操作。**
+**一旦分支中的提交物件發佈到公共倉庫，就千萬不要對該分支進行衍合操作。**
 
-如果你遵循这条金科玉律，就不会出差错。否则，人民群众会仇恨你，你的朋友和家人也会嘲笑你，唾弃你。
+如果你遵循這條金科玉律，就不會出差錯。否則，人民群眾會仇恨你，你的朋友和家人也會嘲笑你，唾棄你。
 
-在进行衍合的时候，实际上抛弃了一些现存的提交对象而创造了一些类似但不同的新的提交对象。如果你把原来分支中的提交对象发布出去，并且其他人更新下载后在其基础上开展工作，而稍后你又用 `git rebase` 抛弃这些提交对象，把新的重演后的提交对象发布出去的话，你的合作者就不得不重新合并他们的工作，这样当你再次从他们那里获取内容时，提交历史就会变得一团糟。
+在進行衍合的時候，實際上拋棄了一些現存的提交物件而創造了一些類似但不同的新的提交物件。如果你把原來分支中的提交物件發佈出去，並且其他人更新下載後在其基礎上開展工作，而稍後你又用 `git rebase` 拋棄這些提交物件，把新的重演後的提交物件發佈出去的話，你的合作者就不得不重新合併他們的工作，這樣當你再次從他們那裡獲取內容時，提交歷史就會變得一團糟。
 
-下面我们用一个实际例子来说明为什么公开的衍合会带来问题。假设你从一个中央服务器克隆然后在它的基础上搞了一些开发，提交历史类似图 3-36 所示：
+下面我們用一個實際例子來說明為什麼公開的衍合會帶來問題。假設你從一個中央伺服器克隆然後在它的基礎上搞了一些開發，提交歷史類似圖 3-36 所示：
 
 Insert 18333fig0336.png
-图 3-36. 克隆一个仓库，在其基础上工作一番。
+圖 3-36. 克隆一個倉庫，在其基礎上工作一番。
 
-现在，某人在 C1 的基础上做了些改变，并合并他自己的分支得到结果 C6，推送到中央服务器。当你抓取并合并这些数据到你本地的开发分支中后，会得到合并结果 C7，历史提交会变成图 3-37 这样：
+現在，某人在 C1 的基礎上做了些改變，併合並他自己的分支得到結果 C6，推送到中央伺服器。當你抓取併合並這些資料到你本地的開發分支中後，會得到合併結果 C7，歷史提交會變成圖 3-37 這樣：
 
 Insert 18333fig0337.png
-图 3-37. 抓取他人提交，并入自己主干。
+圖 3-37. 抓取他人提交，併入自己主幹。
 
-接下来，那个推送 C6 上来的人决定用衍合取代之前的合并操作；继而又用 `git push --force` 覆盖了服务器上的历史，得到 C4'。而之后当你再从服务器上下载最新提交后，会得到：
+接下來，那個推送 C6 上來的人決定用衍合取代之前的合併操作；繼而又用 `git push --force` 覆蓋了伺服器上的歷史，得到 C4'。而之後當你再從伺服器上下載最新提交後，會得到：
 
 Insert 18333fig0338.png
-图 3-38. 有人推送了衍合后得到的 C4'，丢弃了你作为开发基础的 C4 和 C6。
+圖 3-38. 有人推送了衍合後得到的 C4'，丟棄了你作為開發基礎的 C4 和 C6。
 
-下载更新后需要合并，但此时衍合产生的提交对象 C4' 的 SHA-1 校验值和之前 C4 完全不同，所以 Git 会把它们当作新的提交对象处理，而实际上此刻你的提交历史 C7 中早已经包含了 C4 的修改内容，于是合并操作会把 C7 和 C4' 合并为 C8（见图 3-39）:
+下載更新後需要合併，但此時衍合產生的提交物件 C4' 的 SHA-1 校驗值和之前 C4 完全不同，所以 Git 會把它們當作新的提交物件處理，而實際上此刻你的提交歷史 C7 中早已經包含了 C4 的修改內容，於是合併操作會把 C7 和 C4' 合併為 C8（見圖 3-39）:
 
 Insert 18333fig0339.png
-图 3-39. 你把相同的内容又合并了一遍，生成一个新的提交 C8。
+圖 3-39. 你把相同的內容又合併了一遍，生成一個新的提交 C8。
 
-C8 这一步的合并是迟早会发生的，因为只有这样你才能和其他协作者提交的内容保持同步。而在 C8 之后，你的提交历史里就会同时包含 C4 和 C4'，两者有着不同的 SHA-1 校验值，如果用 `git log` 查看历史，会看到两个提交拥有相同的作者日期与说明，令人费解。而更糟的是，当你把这样的历史推送到服务器后，会再次把这些衍合后的提交引入到中央服务器，进一步困扰其他人（译注：这个例子中，出问题的责任方是那个发布了 C6 后又用衍合发布 C4' 的人，其他人会因此反馈双重历史到共享主干，从而混淆大家的视听。）。
+C8 這一步的合併是遲早會發生的，因為只有這樣你才能和其他協作者提交的內容保持同步。而在 C8 之後，你的提交歷史裡就會同時包含 C4 和 C4'，兩者有著不同的 SHA-1 校驗值，如果用 `git log` 查看歷史，會看到兩個提交擁有相同的作者日期與說明，令人費解。而更糟的是，當你把這樣的歷史推送到伺服器後，會再次把這些衍合後的提交引入到中央伺服器，進一步困擾其他人（譯注：這個例子中，出問題的責任方是那個發佈了 C6 後又用衍合發佈 C4' 的人，其他人會因此回饋雙重歷史到共用主幹，從而混淆大家的視聽。）。
 
-如果把衍合当成一种在推送之前清理提交历史的手段，而且仅仅衍合那些尚未公开的提交对象，就没问题。如果衍合那些已经公开的提交对象，并且已经有人基于这些提交对象开展了后续开发工作的话，就会出现叫人沮丧的麻烦。
+如果把衍合當成一種在推送之前清理提交歷史的手段，而且僅僅衍合那些尚未公開的提交物件，就沒問題。如果衍合那些已經公開的提交物件，並且已經有人基於這些提交物件開展了後續開發工作的話，就會出現叫人沮喪的麻煩。
 
-## 小结 ##
+## 小結 ##
 
-读到这里，你应该已经学会了如何创建分支并切换到新分支，在不同分支间转换，合并本地分支，把分支推送到共享服务器上，使用共享分支与他人协作，以及在分享之前进行衍合。
+讀到這裡，你應該已經學會了如何創建分支並切換到新分支，在不同分支間轉換，合併本地分支，把分支推送到共用伺服器上，使用共用分支與他人協作，以及在分享之前進行衍合。

From 8dafb51f9c4f59aed6cd7e98a7a9be347c6f4f5c Mon Sep 17 00:00:00 2001
From: ya_hsiung <ya_hsiung@yahoo.com>
Date: Fri, 7 Mar 2014 13:58:06 +0800
Subject: [PATCH 259/690] add Chapter 4

---
 zh-tw/04-git-server/01-chapter4.markdown | 866 +++++++++++++++++++++++
 1 file changed, 866 insertions(+)
 create mode 100644 zh-tw/04-git-server/01-chapter4.markdown

diff --git a/zh-tw/04-git-server/01-chapter4.markdown b/zh-tw/04-git-server/01-chapter4.markdown
new file mode 100644
index 000000000..cfd2f2e3f
--- /dev/null
+++ b/zh-tw/04-git-server/01-chapter4.markdown
@@ -0,0 +1,866 @@
+# 伺服器上的 Git #
+
+到目前為止，你應該已經學會了使用 Git 來完成日常工作。然而，如果想與他人合作，還需要一個遠端的 Git 倉庫。儘管技術上可以從個人的倉庫裡推送和拉取修改內容，但我們不鼓勵這樣做，因為一不留心就很容易弄混其他人的進度。另外，你也一定希望合作者們即使在自己不開機的時候也能從倉庫獲取資料 — 擁有一個更穩定的公共倉庫十分有用。因此，更好的合作方式是建立一個大家都可以訪問的共用倉庫，從那裡推送和拉取資料。我們將把這個倉庫稱為 "Git 伺服器"；代理一個 Git 倉庫只需要花費很少的資源，幾乎從不需要整個伺服器來支援它的運行。
+
+架設一台 Git 伺服器並不難。第一步是選擇與伺服器通訊的協定。本章第一節將介紹可用的協議以及各自優缺點。下面一節將介紹一些針對各個協議典型的設置以及如何在伺服器上實施。最後，如果你不介意在他人伺服器上保存你的代碼，又想免去自己架設和維護伺服器的麻煩，倒可以試試我們介紹的幾個倉庫託管服務。
+
+如果你對架設自己的伺服器沒興趣，可以跳到本章最後一節去看看如何申請一個代碼託管服務的帳戶然後繼續下一章，我們會在那裡討論分散式源碼控制環境的林林總總。
+
+遠端倉庫通常只是一個_裸倉庫（bare repository）_ — 即一個沒有當前工作目錄的倉庫。因為該倉庫只是一個合作媒介，所以不需要從硬碟上取出最新版本的快照；倉庫裡存放的僅僅是 Git 的資料。簡單地說，裸倉庫就是你工作目錄中 `.git` 子目錄內的內容。
+
+## 協議 ##
+
+Git 可以使用四種主要的協定來傳輸資料：本地傳輸，SSH 協定，Git 協定和 HTTP 協定。下面分別介紹一下哪些情形應該使用（或避免使用）這些協定。
+
+值得注意的是，除了 HTTP 協定外，其他所有協定都要求在伺服器端安裝並運行 Git。
+
+### 本地協定 ###
+
+最基本的就是_本地協議（Local protocol）_，所謂的遠端倉庫在該協定中的表示，就是硬碟上的另一個目錄。這常見於團隊每一個成員都對一個共用的檔案系統（例如 NFS）擁有訪問權，或者比較少見的多人共用同一台電腦的情況。後面一種情況並不安全，因為所有代碼倉庫實例都儲存在同一台電腦裡，增加了災難性資料損失的可能性。
+
+如果你使用一個共用的檔案系統，就可以在一個本地檔案系統中克隆倉庫，推送和獲取。克隆的時候只需要將遠端倉庫的路徑作為 URL 使用，比如下面這樣：
+
+	$ git clone /opt/git/project.git
+
+或者這樣：
+
+	$ git clone file:///opt/git/project.git
+
+如果在 URL 開頭明確使用 `file://` ，那麼 Git 會以一種略微不同的方式運行。如果你只給出路徑，Git 會嘗試使用硬連結或直接複製它所需要的檔。如果使用了 `file://` ，Git 會調用它平時通過網路來傳輸資料的工序，而這種方式的效率相對較低。使用 `file://` 首碼的主要原因是當你需要一個不包含無關引用或物件的乾淨倉庫副本的時候 — 一般指從其他版本控制系統導入的，或類似情形（參見第 9 章的維護任務）。我們這裡僅僅使用普通路徑，這樣更快。
+
+要添加一個本地倉庫作為現有 Git 項目的遠端倉庫，可以這樣做：
+
+	$ git remote add local_proj /opt/git/project.git
+
+然後就可以像在網路上一樣向這個遠端倉庫推送和獲取資料了。
+
+#### 優點 ####
+
+基於檔倉庫的優點在於它的簡單，同時保留了現存檔的許可權和網路存取權限。如果你的團隊已經有一個全體共用的檔案系統，建立倉庫就十分容易了。你只需把一份裸倉庫的副本放在大家都能訪問的地方，然後像對其他共用目錄一樣設置讀寫許可權就可以了。我們將在下一節“在伺服器上部署 Git ”中討論如何匯出一個裸倉庫的副本。
+
+這也是從別人工作目錄中獲取工作成果的快捷方法。假如你和你的同事在一個項目中合作，他們想讓你檢出一些東西的時候，運行類似 `git pull /home/john/project` 通常會比他們推送到伺服器，而你再從伺服器獲取簡單得多。
+
+#### 缺點 ####
+
+這種方法的缺點是，與基本的網路連接訪問相比，難以控制從不同位置來的存取權限。如果你想從家裡的筆記型電腦上推送，就要先掛載遠端硬碟，這和基於網路連接的訪問相比更加困難和緩慢。
+
+另一個很重要的問題是該方法不一定就是最快的，尤其是對於共用掛載的檔案系統。本地倉庫只有在你對資料存取速度快的時候才快。在同一個伺服器上，如果二者同時允許 Git 訪問本地硬碟，通過 NFS 訪問倉庫通常會比 SSH 慢。
+
+### SSH 協議 ###
+
+Git 使用的傳輸協議中最常見的可能就是 SSH 了。這是因為大多數環境已經支持通過 SSH 對伺服器的訪問 — 即便還沒有，架設起來也很容易。SSH 也是唯一一個同時支持讀寫操作的網路通訊協定。另外兩個網路通訊協定（HTTP 和 Git）通常都是唯讀的，所以雖然二者對大多數人都可用，但執行寫操作時還是需要 SSH。SSH 同時也是一個驗證授權的網路通訊協定；而因為其普遍性，一般架設和使用都很容易。
+
+通過 SSH 克隆一個 Git 倉庫，你可以像下面這樣給出 ssh:// 的 URL：
+
+	$ git clone ssh://user@server/project.git
+
+或者不指明某個協定 — 這時 Git 會預設使用 SSH ：
+
+	$ git clone user@server:project.git
+
+如果不指明用戶，Git 會默認使用當前登錄的用戶名連接伺服器。 
+
+#### 優點 ####
+
+使用 SSH 的好處有很多。首先，如果你想擁有對網路倉庫的寫許可權，基本上不可能不使用 SSH。其次，SSH 架設相對比較簡單 — SSH 守護進程很常見，很多網路系統管理員都有一些使用經驗，而且很多作業系統都自帶了它或者相關的管理工具。再次，通過 SSH 進行訪問是安全的 — 所有資料傳輸都是加密和授權的。最後，和 Git 及本地協議一樣，SSH 也很高效，會在傳輸之前盡可能壓縮資料。
+
+#### 缺點 ####
+
+SSH 的限制在於你不能通過它實現倉庫的匿名訪問。即使僅為讀取資料，人們也必須在能通過 SSH 訪問主機的前提下才能訪問倉庫，這使得 SSH 不利於開源的項目。如果你僅僅在公司網路裡使用，SSH 可能是你唯一需要使用的協定。如果想允許對項目的匿名唯讀訪問，那麼除了為自己推送而架設 SSH 協定之外，還需要支援其他協定以便他人訪問讀取。
+
+### Git 協議 ###
+
+接下來是 Git 協議。這是一個包含在 Git 套裝軟體中的特殊守護進程； 它會監聽一個提供類似於 SSH 服務的特定埠（9418），而無需任何授權。打算支援 Git 協定的倉庫，需要先創建 `git-daemon-export-ok` 檔 — 它是協定進程提供倉庫服務的必要條件 — 但除此之外該服務沒有什麼安全措施。要麼所有人都能克隆 Git 倉庫，要麼誰也不能。這也意味著該協議通常不能用來進行推送。你可以允許推送操作；然而由於沒有授權機制，一旦允許該操作，網路上任何一個知道專案 URL 的人將都有推送許可權。不用說，這是十分罕見的情況。
+
+#### 優點 ####
+
+Git 協定是現存最快的傳輸協議。如果你在提供一個有很大訪問量的公共專案，或者一個不需要對讀操作進行授權的龐大項目，架設一個 Git 守護進程來供應倉庫是個不錯的選擇。它使用與 SSH 協定相同的資料傳輸機制，但省去了加密和授權的開銷。
+
+#### 缺點 ####
+
+Git 協議消極的一面是缺少授權機制。用 Git 協議作為訪問專案的唯一方法通常是不可取的。一般的做法是，同時提供 SSH 介面，讓幾個開發者擁有推送（寫）許可權，其他人通過 `git://` 擁有唯讀許可權。
+Git 協定可能也是最難架設的協議。它要求有單獨的守護進程，需要定制 — 我們將在本章的 “Gitosis” 一節詳細介紹它的架設 — 需要設定 `xinetd` 或類似的程式，而這些工作就沒那麼輕鬆了。該協議還要求防火牆開放 9418 埠，而企業級防火牆一般不允許對這個非標準埠的訪問。大型企業級防火牆通常會封鎖這個少見的埠。
+
+### HTTP/S 協議 ###
+
+最後還有 HTTP 協議。HTTP 或 HTTPS 協議的優美之處在於架設的簡便性。基本上，只需要把 Git 的裸倉庫檔放在 HTTP 的根目錄下，配置一個特定的 `post-update` 掛鉤（hook）就可以搞定（Git 掛鉤的細節見第 7 章）。此後，每個能訪問 Git 倉庫所在伺服器上 web 服務的人都可以進行克隆操作。下面的操作可以允許通過 HTTP 對倉庫進行讀取：
+
+	$ cd /var/www/htdocs/
+	$ git clone --bare /path/to/git_project gitproject.git
+	$ cd gitproject.git
+	$ mv hooks/post-update.sample hooks/post-update
+	$ chmod a+x hooks/post-update
+
+這樣就可以了。Git 附帶的 `post-update` 掛鉤會默認運行合適的命令（`git update-server-info`）來確保通過 HTTP 的獲取和克隆正常工作。這條命令在你用 SSH 向倉庫推送內容時運行；之後，其他人就可以用下面的命令來克隆倉庫：
+
+	$ git clone http://example.com/gitproject.git
+
+在本例中，我們使用了 Apache 設定中常用的 `/var/www/htdocs` 路徑，不過你可以使用任何靜態 web 服務 — 把裸倉庫放在它的目錄裡就行。 Git 的資料是以最基本的靜態檔的形式提供的（關於如何提供檔的詳情見第 9 章）。
+
+通過 HTTP 進行推送操作也是可能的，不過這種做法不太常見，並且牽扯到複雜的 WebDAV 設定。由於很少用到，本書將略過對該內容的討論。如果對 HTTP 推送協議感興趣，不妨打開這個位址看一下操作方法：`http://www.kernel.org/pub/software/scm/git/docs/howto/setup-git-server-over-http.txt` 。通過 HTTP 推送的好處之一是你可以使用任何 WebDAV 伺服器，不需要為 Git 設定特殊環境；所以如果主機提供商支援通過 WebDAV 更新網站內容，你也可以使用這項功能。
+
+#### 優點 ####
+
+使用 HTTP 協定的好處是易於架設。幾條必要的命令就可以讓全世界讀取到倉庫的內容。花費不過幾分鐘。HTTP 協議不會佔用過多伺服器資源。因為它一般只用到靜態的 HTTP 服務提供所有資料，普通的 Apache 伺服器平均每秒能支撐數千個檔的併發訪問 — 哪怕讓一個小型伺服器超載都很難。
+
+你也可以通過 HTTPS 提供唯讀的倉庫，這意味著你可以加密傳輸內容；你甚至可以要求用戶端使用特定簽名的 SSL 證書。一般情況下，如果到了這一步，使用 SSH 公共金鑰可能是更簡單的方案；不過也存在一些特殊情況，這時通過 HTTPS 使用帶簽名的 SSL 證書或者其他基於 HTTP 的唯讀連接授權方式是更好的解決方案。
+
+HTTP 還有個額外的好處：HTTP 是一個如此常見的協議，以至於企業級防火牆通常都允許其埠的通信。
+
+#### 缺點 ####
+
+HTTP 協議的消極面在於，相對來說用戶端效率更低。克隆或者下載倉庫內容可能會花費更多時間，而且 HTTP 傳輸的體積和網路開銷比其他任何一個協議都大。因為它沒有按需供應的能力 — 傳輸過程中沒有服務端的動態計算 — 因而 HTTP 協定經常會被稱為_傻瓜（dumb）_協議。更多 HTTP 協定和其他協定效率上的差異見第 9 章。
+
+## 在伺服器上部署 Git ##
+
+開始架設 Git 伺服器前，需要先把現有倉庫匯出為裸倉庫 — 即一個不包含當前工作目錄的倉庫。做法直截了當，克隆時用 `--bare` 選項即可。裸倉庫的目錄名一般以 `.git` 結尾，像這樣：
+
+	$ git clone --bare my_project my_project.git
+	Cloning into bare repository 'my_project.git'...
+	done.
+
+該命令的輸出或許會讓人有些不解。其實 `clone` 操作基本上相當於 `git init` 加 `git fetch`，所以這裡出現的其實是 `git init` 的輸出，先由它建立一個空目錄，而之後傳輸資料物件的操作並無任何輸出，只是悄悄在幕後執行。現在 `my_project.git` 目錄中已經有了一份 Git 目錄資料的副本。
+
+整體上的效果大致相當於：
+
+	$ cp -Rf my_project/.git my_project.git
+
+但在設定檔中有若干小改動，不過對使用者來講，使用方式都一樣，不會有什麼影響。它僅取出 Git 倉庫的必要原始資料，存放在該目錄中，而不會另外創建工作目錄。
+
+### 把裸倉庫移到伺服器上 ###
+
+有了裸倉庫的副本後，剩下的就是把它放到伺服器上並設定相關協定。假設一個功能變數名稱為 `git.example.com` 的伺服器已經架設好，並可以通過 SSH 訪問，我們打算把所有 Git 倉庫儲存在 `/opt/git` 目錄下。只要把裸倉庫複製過去：
+
+	$ scp -r my_project.git user@git.example.com:/opt/git
+
+現在，所有對該伺服器有 SSH 存取權限，並可讀取 `/opt/git` 目錄的使用者都可以用下面的命令克隆該項目：
+
+	$ git clone user@git.example.com:/opt/git/my_project.git
+
+如果某個 SSH 用戶對 `/opt/git/my_project.git` 目錄有寫許可權，那他就有推送許可權。如果到該專案目錄中運行 `git init` 命令，並加上 `--shared` 選項，那麼 Git 會自動修改該倉庫目錄的組許可權為可寫（譯注：實際上 `--shared` 可以指定其他行為，只是默認為將組許可權改為可寫並執行 `g+sx`，所以最後會得到 `rws`。）。
+
+	$ ssh user@git.example.com
+	$ cd /opt/git/my_project.git
+	$ git init --bare --shared
+
+由此可見，根據現有的 Git 倉庫創建一個裸倉庫，然後把它放上你和同事都有 SSH 訪問權的伺服器是多麼容易。現在已經可以開始在同一專案上密切合作了。
+
+值得注意的是，這的的確確是架設一個少數人具有連接權的 Git 服務的全部 — 只要在伺服器上加入可以用 SSH 登錄的帳號，然後把裸倉庫放在大家都有讀寫許可權的地方。一切都準備停當，無需更多。
+
+下面的幾節中，你會瞭解如何擴展到更複雜的設定。這些內容包含如何避免為每一個用戶建立一個帳戶，給倉庫添加公共讀取許可權，架設網頁介面，使用 Gitosis 工具等等。然而，只是和幾個人在一個不公開的專案上合作的話，僅僅是一個 SSH 伺服器和裸倉庫就足夠了，記住這點就可以了。
+
+### 小型安裝 ###
+
+如果設備較少或者你只想在小型開發團隊裡嘗試 Git ，那麼一切都很簡單。架設 Git 服務最複雜的地方在於帳戶管理。如果需要倉庫對特定的使用者可讀，而給另一部分用戶讀寫許可權，那麼訪問和許可的安排就比較困難。
+
+#### SSH 連接 ####
+
+如果已經有了一個所有開發成員都可以用 SSH 訪問的伺服器，架設第一個伺服器將變得異常簡單，幾乎什麼都不用做（正如上節中介紹的那樣）。如果需要對倉庫進行更複雜的存取控制，只要使用伺服器作業系統的本地檔訪問許可機制就行了。
+
+如果需要團隊裡的每個人都對倉庫有寫許可權，又不能給每個人在伺服器上建立帳戶，那麼提供 SSH 連接就是唯一的選擇了。我們假設用來共用倉庫的伺服器已經安裝了 SSH 服務，而且你通過它訪問伺服器。
+
+有好幾個辦法可以讓團隊的每個人都有訪問權。第一個辦法是給每個人建立一個帳戶，直截了當但略過繁瑣。反復運行 `adduser` 並給所有人設定臨時密碼可不是好玩的。
+
+第二個辦法是在主機上建立一個 `git` 帳戶，讓每個需要寫許可權的人發送一個 SSH 公開金鑰，然後將其加入 `git` 帳戶的 `~/.ssh/authorized_keys` 文件。這樣一來，所有人都將通過 `git` 帳戶訪問主機。這絲毫不會影響提交的資料 — 訪問主機用的身份不會影響提交物件的提交者資訊。
+
+另一個辦法是讓 SSH 伺服器通過某個 LDAP 服務，或者其他已經設定好的集中授權機制，來進行授權。只要每個人都能獲得主機的 shell 訪問權，任何可用的 SSH 授權機制都能達到相同效果。
+
+## 生成 SSH 公開金鑰 ##
+
+大多數 Git 伺服器都會選擇使用 SSH 公開金鑰來進行授權。系統中的每個使用者都必須提供一個公開金鑰用於授權，沒有的話就要生成一個。生成公開金鑰的過程在所有作業系統上都差不多。
+首先先確認一下是否已經有一個公開金鑰了。SSH 公開金鑰預設儲存在帳戶的主目錄下的 `~/.ssh` 目錄。進去看看：
+
+	$ cd ~/.ssh
+	$ ls
+	authorized_keys2  id_dsa       known_hosts
+	config            id_dsa.pub
+
+關鍵是看有沒有用 `something` 和 `something.pub` 來命名的一對檔，這個 `something` 通常就是 `id_dsa` 或 `id_rsa`。有 `.pub` 尾碼的檔就是公開金鑰，另一個檔則是金鑰。假如沒有這些檔，或者乾脆連 `.ssh` 目錄都沒有，可以用 `ssh-keygen` 來創建。該程式在 Linux/Mac 系統上由 SSH 包提供，而在 Windows 上則包含在 MSysGit 包裡：
+
+	$ ssh-keygen
+	Generating public/private rsa key pair.
+	Enter file in which to save the key (/Users/schacon/.ssh/id_rsa):
+	Enter passphrase (empty for no passphrase):
+	Enter same passphrase again:
+	Your identification has been saved in /Users/schacon/.ssh/id_rsa.
+	Your public key has been saved in /Users/schacon/.ssh/id_rsa.pub.
+	The key fingerprint is:
+	43:c5:5b:5f:b1:f1:50:43:ad:20:a6:92:6a:1f:9a:3a schacon@agadorlaptop.local
+
+它先要求你確認保存公開金鑰的位置（`.ssh/id_rsa`），然後它會讓你重複一個密碼兩次，如果不想在使用公開金鑰的時候輸入密碼，可以留空。
+
+現在，所有做過這一步的用戶都得把它們的公開金鑰給你或者 Git 伺服器的管理員（假設 SSH 服務被設定為使用公開金鑰機制）。他們只需要複製 `.pub` 檔的內容然後發郵件給管理員。公開金鑰的樣子大致如下：
+
+	$ cat ~/.ssh/id_rsa.pub
+	ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAklOUpkDHrfHY17SbrmTIpNLTGK9Tjom/BWDSU
+	GPl+nafzlHDTYW7hdI4yZ5ew18JH4JW9jbhUFrviQzM7xlELEVf4h9lFX5QVkbPppSwg0cda3
+	Pbv7kOdJ/MTyBlWXFCR+HAo3FXRitBqxiX1nKhXpHAZsMciLq8V6RjsNAQwdsdMFvSlVK/7XA
+	t3FaoJoAsncM1Q9x5+3V0Ww68/eIFmb1zuUFljQJKprrX88XypNDvjYNby6vw/Pb0rwert/En
+	mZ+AW4OZPnTPI89ZPmVMLuayrD2cE86Z/il8b+gw3r3+1nKatmIkjn2so1d01QraTlMqVSsbx
+	NrRFi9wrf+M7Q== schacon@agadorlaptop.local
+
+關於在多個作業系統上設立相同 SSH 公開金鑰的教程，可以查閱 GitHub 上有關 SSH 公開金鑰的嚮導：`http://github.com/guides/providing-your-ssh-key`。
+
+## 架設伺服器 ##
+
+現在我們過一邊伺服器端架設 SSH 訪問的流程。本例將使用 `authorized_keys` 方法來給用戶授權。我們還將假定使用類似 Ubuntu 這樣的標準 Linux 發行版本。首先，創建一個名為 'git' 的用戶，並為其創建一個 `.ssh` 目錄。
+
+	$ sudo adduser git
+	$ su git
+	$ cd
+	$ mkdir .ssh
+
+接下來，把開發者的 SSH 公開金鑰添加到這個用戶的 `authorized_keys` 檔中。假設你通過電郵收到了幾個公開金鑰並存到了暫存檔案裡。重複一下，公開金鑰大致看起來是這個樣子：
+
+	$ cat /tmp/id_rsa.john.pub
+	ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCB007n/ww+ouN4gSLKssMxXnBOvf9LGt4L
+	ojG6rs6hPB09j9R/T17/x4lhJA0F3FR1rP6kYBRsWj2aThGw6HXLm9/5zytK6Ztg3RPKK+4k
+	Yjh6541NYsnEAZuXz0jTTyAUfrtU3Z5E003C4oxOj6H0rfIF1kKI9MAQLMdpGW1GYEIgS9Ez
+	Sdfd8AcCIicTDWbqLAcU4UpkaX8KyGlLwsNuuGztobF8m72ALC/nLF6JLtPofwFBlgc+myiv
+	O7TCUSBdLQlgMVOFq1I2uPWQOkOWQAHukEOmfjy2jctxSDBQ220ymjaNsHT4kgtZg2AYYgPq
+	dAv8JggJICUvax2T9va5 gsg-keypair
+
+只要把它們逐個追加到 `authorized_keys` 檔案結尾部即可：
+
+	$ cat /tmp/id_rsa.john.pub >> ~/.ssh/authorized_keys
+	$ cat /tmp/id_rsa.josie.pub >> ~/.ssh/authorized_keys
+	$ cat /tmp/id_rsa.jessica.pub >> ~/.ssh/authorized_keys
+
+現在可以用 `--bare` 選項運行 `git init` 來建立一個裸倉庫，這會初始化一個不包含工作目錄的倉庫。
+
+	$ cd /opt/git
+	$ mkdir project.git
+	$ cd project.git
+	$ git --bare init
+
+這時，Join，Josie 或者 Jessica 就可以把它加為遠端倉庫，推送一個分支，從而把第一個版本的專案檔案上傳到倉庫裡了。值得注意的是，每次添加一個新專案都需要通過 shell 登入主機並創建一個裸倉庫目錄。我們不妨以 `gitserver` 作為 `git` 用戶及項目倉庫所在的主機名稱。如果在網路內部運行該主機，並在 DNS 中設定 `gitserver` 指向該主機，那麼以下這些命令都是可用的：
+
+	# 在 John 的電腦上
+	$ cd myproject
+	$ git init
+	$ git add .
+	$ git commit -m 'initial commit'
+	$ git remote add origin git@gitserver:/opt/git/project.git
+	$ git push origin master
+
+這樣，其他人的克隆和推送也一樣變得很簡單：
+
+	$ git clone git@gitserver:/opt/git/project.git
+	$ cd project
+	$ vim README
+	$ git commit -am 'fix for the README file'
+	$ git push origin master
+
+用這個方法可以很快捷地為少數幾個開發者架設一個可讀寫的 Git 服務。
+
+作為一個額外的防範措施，你可以用 Git 自帶的 `git-shell` 工具限制 `git` 用戶的活動範圍。只要把它設為 `git` 用戶登入的 shell，那麼該用戶就無法使用普通的 bash 或者 csh 什麼的 shell 程式。編輯 `/etc/passwd` 檔：
+
+	$ sudo vim /etc/passwd
+
+在檔末尾，你應該能找到類似這樣的行：
+
+	git:x:1000:1000::/home/git:/bin/sh
+
+把 `bin/sh` 改為 `/usr/bin/git-shell` （或者用 `which git-shell` 查看它的實際安裝路徑）。該行修改後的樣子如下：
+
+	git:x:1000:1000::/home/git:/usr/bin/git-shell
+
+現在 `git` 用戶只能用 SSH 連接來推送和獲取 Git 倉庫，而不能直接使用主機 shell。嘗試普通 SSH 登錄的話，會看到下面這樣的拒絕資訊：
+
+	$ ssh git@gitserver
+	fatal: What do you think I am? A shell?
+	Connection to gitserver closed.
+
+## 公共訪問 ##
+
+匿名的讀取許可權該怎麼實現呢？也許除了內部私有的專案之外，你還需要託管一些開源專案。或者因為要用一些自動化的伺服器來進行編譯，或者有一些經常變化的伺服器群組，而又不想整天生成新的 SSH 金鑰 — 總之，你需要簡單的匿名讀取許可權。
+
+或許對小型的配置來說最簡單的辦法就是運行一個靜態 web 服務，把它的根目錄設定為 Git 倉庫所在的位置，然後開啟本章第一節提到的 `post-update` 掛鉤。這裡繼續使用之前的例子。假設倉庫處於 `/opt/git` 目錄，主機上運行著 Apache 服務。重申一下，任何 web 服務程式都可以達到相同效果；作為範例，我們將用一些基本的 Apache 設定來展示大體需要的步驟。
+
+首先，開啟掛鉤：
+
+	$ cd project.git
+	$ mv hooks/post-update.sample hooks/post-update
+	$ chmod a+x hooks/post-update
+
+`post-update` 掛鉤是做什麼的呢？其內容大致如下：
+
+	$ cat .git/hooks/post-update
+	#!/bin/sh
+	#
+	# An example hook script to prepare a packed repository for use over
+	# dumb transports.
+	#
+	# To enable this hook, rename this file to "post-update".
+	#
+	
+	exec git-update-server-info
+
+意思是當通過 SSH 向伺服器推送時，Git 將運行這個 `git-update-server-info` 命令來更新匿名 HTTP 訪問獲取資料時所需要的檔。
+
+接下來，在 Apache 設定檔中添加一個 VirtualHost 條目，把文檔根目錄設為 Git 專案所在的根目錄。這裡我們假定 DNS 服務已經配置好，會把對 `.gitserver` 的請求發送到這台主機：
+
+	<VirtualHost *:80>
+	    ServerName git.gitserver
+	    DocumentRoot /opt/git
+	    <Directory /opt/git/>
+	        Order allow, deny
+	        allow from all
+	    </Directory>
+	</VirtualHost>
+
+另外，需要把 `/opt/git` 目錄的 Unix 使用者組設定為 `www-data` ，這樣 web 服務才可以讀取倉庫內容，因為運行 CGI 腳本的  Apache 實例進程預設就是以該使用者的身份起來的：
+
+	$ chgrp -R www-data /opt/git
+
+重啟 Apache 之後，就可以通過專案的 URL 來克隆該目錄下的倉庫了。
+
+	$ git clone http://git.gitserver/project.git
+
+這一招可以讓你在幾分鐘內為相當數量的用戶架設好基於 HTTP 的讀取許可權。另一個提供非授權訪問的簡單方法是開啟一個 Git 守護進程，不過這將要求該進程作為後臺進程常駐 — 接下來的這一節就要討論這方面的細節。
+
+## GitWeb ##
+
+現在我們的項目已經有了可讀可寫和唯讀的連接方式，不過如果能有一個簡單的 web 介面訪問就更好了。Git 自帶一個叫做 GitWeb 的 CGI 腳本，運行效果可以到 `http://git.kernel.org` 這樣的網站體驗下（見圖 4-1）。
+
+Insert 18333fig0401.png
+Figure 4-1. 基於網頁的 GitWeb 使用者介面
+
+如果想看看自己項目的效果，不妨用 Git 自帶的一個命令，可以使用類似 `lighttpd` 或 `webrick` 這樣羽量級的伺服器啟動一個臨時進程。如果是在 Linux 主機上，通常都預裝了 `lighttpd` ，可以到專案目錄中鍵入 `git instaweb` 來啟動。如果用的是 Mac ，Leopard 預裝了 Ruby，所以 `webrick` 應該是最好的選擇。如果要用 lighttpd 以外的程式來啟動 `git instaweb`，可以通過 `--httpd` 選項指定：
+
+	$ git instaweb --httpd=webrick
+	[2009-02-21 10:02:21] INFO  WEBrick 1.3.1
+	[2009-02-21 10:02:21] INFO  ruby 1.8.6 (2008-03-03) [universal-darwin9.0]
+
+這會在 1234 埠開啟一個 HTTPD 服務，隨之在流覽器中顯示該頁，十分簡單。關閉服務時，只需在原來的命令後面加上 `--stop` 選項就可以了：
+
+	$ git instaweb --httpd=webrick --stop
+
+如果需要為團隊或者某個開源專案長期運行 GitWeb，那麼 CGI 腳本就要由正常的網頁服務來運行。一些 Linux 發行版本可以通過 `apt` 或 `yum` 安裝一個叫做 `gitweb` 的套裝軟體，不妨首先嘗試一下。我們將快速介紹一下手動安裝 GitWeb 的流程。首先，你需要 Git 的源碼，其中帶有 GitWeb，並能生成定制的 CGI 腳本：
+
+	$ git clone git://git.kernel.org/pub/scm/git/git.git
+	$ cd git/
+	$ make GITWEB_PROJECTROOT="/opt/git" \
+	        prefix=/usr gitweb
+	$ sudo cp -Rf gitweb /var/www/
+
+注意，通過指定 `GITWEB_PROJECTROOT` 變數告訴編譯命令 Git 倉庫的位置。然後，設置 Apache 以 CGI 方式運行該腳本，添加一個 VirtualHost 配置：
+
+	<VirtualHost *:80>
+	    ServerName gitserver
+	    DocumentRoot /var/www/gitweb
+	    <Directory /var/www/gitweb>
+	        Options ExecCGI +FollowSymLinks +SymLinksIfOwnerMatch
+	        AllowOverride All
+	        order allow,deny
+	        Allow from all
+	        AddHandler cgi-script cgi
+	        DirectoryIndex gitweb.cgi
+	    </Directory>
+	</VirtualHost>
+
+不難想像，GitWeb 可以使用任何相容 CGI 的網頁服務來運行；如果偏向使用其他 web 伺服器，配置也不會很麻煩。現在，通過 `http://gitserver` 就可以線上訪問倉庫了，在 `http://git.server` 上還可以通過 HTTP 克隆和獲取倉庫的內容。
+
+## Gitosis ##
+
+把所有用戶的公開金鑰保存在 `authorized_keys` 檔的做法，只能湊和一陣子，當用戶數量達到幾百人的規模時，管理起來就會十分痛苦。每次改刪用戶都必須登錄伺服器不去說，這種做法還缺少必要的許可權管理 — 每個人都對所有專案擁有完整的讀寫許可權。
+
+幸好我們還可以選擇應用廣泛的 Gitosis 項目。簡單地說，Gitosis 就是一套用來管理 `authorized_keys` 檔和實現簡單連接限制的腳本。有趣的是，用來添加用戶和設定許可權的並非通過網頁程式，而只是管理一個特殊的 Git 倉庫。你只需要在這個特殊倉庫內做好相應的設定，然後推送到伺服器上，Gitosis 就會隨之改變運行策略，聽起來就很酷，對吧？
+
+Gitosis 的安裝算不上傻瓜化，但也不算太難。用 Linux 伺服器架設起來最簡單 — 以下例子中，我們使用裝有 Ubuntu 8.10 系統的伺服器。
+
+Gitosis 的工作依賴於某些 Python 工具，所以首先要安裝 Python 的 setuptools 包，在 Ubuntu 上稱為 python-setuptools：
+
+	$ apt-get install python-setuptools
+
+接下來，從 Gitosis 項目主頁克隆並安裝：
+
+	$ git clone https://github.com/tv42/gitosis.git
+	$ cd gitosis
+	$ sudo python setup.py install
+
+這會安裝幾個供 Gitosis 使用的工具。預設 Gitosis 會把 `/home/git` 作為存儲所有 Git 倉庫的根目錄，這沒什麼不好，不過我們之前已經把項目倉庫都放在 `/opt/git` 裡面了，所以為方便起見，我們可以做一個符號連接，直接劃轉過去，而不必重新配置：
+
+	$ ln -s /opt/git /home/git/repositories
+
+Gitosis 將會幫我們管理用戶公開金鑰，所以先把當前控制檔改名備份，以便稍後重新添加，準備好讓 Gitosis 自動管理 `authorized_keys` 文件：
+
+	$ mv /home/git/.ssh/authorized_keys /home/git/.ssh/ak.bak
+
+接下來，如果之前把 `git` 用戶的登錄 shell 改為 `git-shell` 命令的話，先恢復 'git' 用戶的登錄 shell。改過之後，大家仍然無法通過該帳號登錄（譯注：因為 `authorized_keys` 檔已經沒有了。），不過不用擔心，這會交給 Gitosis 來實現。所以現在先打開 `/etc/passwd` 檔，把這行：
+
+	git:x:1000:1000::/home/git:/usr/bin/git-shell
+
+改回:
+
+	git:x:1000:1000::/home/git:/bin/sh
+
+好了，現在可以初始化 Gitosis 了。你可以用自己的公開金鑰執行 `gitosis-init` 命令，要是公開金鑰不在伺服器上，先臨時複製一份：
+
+	$ sudo -H -u git gitosis-init < /tmp/id_dsa.pub
+	Initialized empty Git repository in /opt/git/gitosis-admin.git/
+	Reinitialized existing Git repository in /opt/git/gitosis-admin.git/
+
+這樣該公開金鑰的擁有者就能修改用於配置 Gitosis 的那個特殊 Git 倉庫了。接下來，需要手工對該倉庫中的 `post-update` 腳本加上可執行許可權：
+
+	$ sudo chmod 755 /opt/git/gitosis-admin.git/hooks/post-update
+
+基本上就算是好了。如果設定過程沒出什麼差錯，現在可以試一下用初始化 Gitosis 的公開金鑰的擁有者身份 SSH 登錄伺服器，應該會看到類似下面這樣：
+
+	$ ssh git@gitserver
+	PTY allocation request failed on channel 0
+	ERROR:gitosis.serve.main:Need SSH_ORIGINAL_COMMAND in environment.
+	  Connection to gitserver closed.
+
+說明 Gitosis 認出了該用戶的身份，但由於沒有運行任何 Git 命令，所以它切斷了連接。那麼，現在運行一個實際的 Git 命令 — 克隆 Gitosis 的控制倉庫：
+
+	# 在你本地電腦上
+	$ git clone git@gitserver:gitosis-admin.git
+
+這會得到一個名為 `gitosis-admin` 的工作目錄，主要由兩部分組成：
+
+	$ cd gitosis-admin
+	$ find .
+	./gitosis.conf
+	./keydir
+	./keydir/scott.pub
+
+`gitosis.conf` 檔是用來設置用戶、倉庫和許可權的控制檔。`keydir` 目錄則是保存所有具有存取權限用戶公開金鑰的地方— 每人一個。在 `keydir` 裡的檔案名（比如上面的 `scott.pub`）應該跟你的不一樣 — Gitosis 會自動從使用 `gitosis-init` 腳本導入的公開金鑰尾部的描述中獲取該名字。
+
+看一下 `gitosis.conf` 檔的內容，它應該只包含與剛剛克隆的 `gitosis-admin` 相關的資訊：
+
+	$ cat gitosis.conf
+	[gitosis]
+
+	[group gitosis-admin]
+	members = scott
+	writable = gitosis-admin
+
+它顯示使用者 `scott` — 初始化 Gitosis 公開金鑰的擁有者 — 是唯一能管理 `gitosis-admin` 專案的人。
+
+現在我們來添加一個新項目。為此我們要建立一個名為 `mobile` 的新段落，在其中羅列手機開發團隊的開發者，以及他們擁有寫許可權的專案。由於 'scott' 是系統中的唯一使用者，我們把他設為唯一用戶，並允許他讀寫名為 `iphone_project` 的新項目：
+
+	[group mobile]
+	members = scott
+	writable = iphone_project
+
+修改完之後，提交 `gitosis-admin` 裡的改動，並推送到伺服器使其生效：
+
+	$ git commit -am 'add iphone_project and mobile group'
+	[master 8962da8] add iphone_project and mobile group
+	 1 file changed, 4 insertions(+)
+	$ git push origin master
+	Counting objects: 5, done.
+	Compressing objects: 100% (3/3), done.
+	Writing objects: 100% (3/3), 272 bytes | 0 bytes/s, done.
+	Total 3 (delta 0), reused 0 (delta 0)
+	To git@gitserver:gitosis-admin.git
+	   fb27aec..8962da8  master -> master
+
+在新工程 `iphone_project` 裡首次推送資料到伺服器前，得先設定該伺服器地址為遠端倉庫。但你不用事先到伺服器上手工創建該項目的裸倉庫— Gitosis 會在第一次遇到推送時自動創建：
+
+	$ git remote add origin git@gitserver:iphone_project.git
+	$ git push origin master
+	Initialized empty Git repository in /opt/git/iphone_project.git/
+	Counting objects: 3, done.
+	Writing objects: 100% (3/3), 230 bytes | 0 bytes/s, done.
+	Total 3 (delta 0), reused 0 (delta 0)
+	To git@gitserver:iphone_project.git
+	 * [new branch]      master -> master
+
+請注意，這裡不用指明完整路徑（實際上，如果加上反而沒用），只需要一個冒號加項目名字即可 — Gitosis 會自動幫你映射到實際位置。
+
+要和朋友們在一個專案上協同工作，就得重新添加他們的公開金鑰。不過這次不用在伺服器上一個一個手工添加到 `~/.ssh/authorized_keys` 檔末端，而只需管理 `keydir` 目錄中的公開金鑰檔。文件的命名將決定在 `gitosis.conf` 中對使用者的標識。現在我們為 John，Josie 和 Jessica 添加公開金鑰：
+
+	$ cp /tmp/id_rsa.john.pub keydir/john.pub
+	$ cp /tmp/id_rsa.josie.pub keydir/josie.pub
+	$ cp /tmp/id_rsa.jessica.pub keydir/jessica.pub
+
+然後把他們都加進 'mobile' 團隊，讓他們對 `iphone_project` 具有讀寫許可權：
+
+	[group mobile]
+	members = scott john josie jessica
+	writable = iphone_project
+
+如果你提交並推送這個修改，四個用戶將同時具有該項目的讀寫許可權。
+
+Gitosis 也具有簡單的存取控制功能。如果想讓 John 只有讀許可權，可以這樣做：
+
+	[group mobile]
+	members = scott josie jessica
+	writable = iphone_project
+
+	[group mobile_ro]
+	members = john
+	readonly = iphone_project
+
+現在 John 可以克隆和獲取更新，但 Gitosis 不會允許他向專案推送任何內容。像這樣的組可以隨意創建，多少不限，每個都可以包含若干不同的用戶和項目。甚至還可以指定某個組為成員之一（在組名前加上 `@` 首碼），自動繼承該組的成員：
+
+	[group mobile_committers]
+	members = scott josie jessica
+
+	[group mobile]
+	members   = @mobile_committers
+	writable  = iphone_project
+
+	[group mobile_2]
+	members   = @mobile_committers john
+	writable  = another_iphone_project
+
+如果遇到意外問題，試試看把 `loglevel=DEBUG` 加到 `[gitosis]` 的段落（譯注：把日誌設置為調試級別，記錄更詳細的運行資訊。）。如果一不小心搞錯了配置，失去了推送許可權，也可以手工修改伺服器上的 `/home/git/.gitosis.conf` 檔 — Gitosis 實際是從該檔讀取資訊的。它在得到推送資料時，會把新的 `gitosis.conf` 存到該路徑上。所以如果你手工編輯該檔的話，它會一直保持到下次向 `gitosis-admin` 推送新版本的配置內容為止。
+
+## Gitolite ##
+
+This section serves as a quick introduction to Gitolite, and provides basic installation and setup instructions.  不能完全替代隨 gitolite 自帶的大量文檔。 There may also be occasional changes to this section itself, so you may also want to look at the latest version [here][gldpg].
+
+[gldpg]: http://sitaramc.github.com/gitolite/progit.html
+[gltoc]: http://sitaramc.github.com/gitolite/master-toc.html
+
+Gitolite is an authorization layer on top of Git, relying on `sshd` or `httpd` for authentication.  (Recap: authentication is identifying who the user is, authorization is deciding if he is allowed to do what he is attempting to).
+
+Gitolite 允許你定義訪問許可而不只作用於倉庫，而同樣於倉庫中的每個branch和tag name。你可以定義確切的人 (或一組人) 只能push特定的 "refs" (或者branches或者tags)而不是其他人。
+
+### 安裝 ###
+
+安裝 Gitolite非常簡單, 你甚至不用讀自帶的那一大堆文檔。你需要一個unix伺服器上的帳戶；許多linux變種和solaris 10都已經試過了。你不需要root訪問，假設git，perl，和一個openssh相容的ssh伺服器已經裝好了。在下面的例子裡，我們會用 `git` 帳戶在 `gitserver`上.
+
+Gitolite 是不同於 "server" 的軟體 -- 通過ssh訪問, 而且每個在伺服器上的userid都是一個潛在的 "gitolite host". We will describe the simplest install method in this article; for the other methods please see the documentation.
+
+To begin, create a user called `git` on your server and login to this user.  Copy your SSH public key (a file called `~/.ssh/id_rsa.pub` if you did a plain `ssh-keygen` with all the defaults) from your workstation, renaming it to `<yourname>.pub` (we'll use `scott.pub` in our examples).  Then run these commands:
+
+	$ git clone git://github.com/sitaramc/gitolite
+	$ gitolite/install -ln
+	    # assumes $HOME/bin exists and is in your $PATH
+	$ gitolite setup -pk $HOME/scott.pub
+
+That last command creates new Git repository called `gitolite-admin` on the server.
+
+Finally, back on your workstation, run `git clone git@gitserver:gitolite-admin`. And you’re done!  Gitolite has now been installed on the server, and you now have a brand new repository called `gitolite-admin` in your workstation.  You administer your Gitolite setup by making changes to this repository and pushing.
+
+### 定制安裝 ###
+
+默認快速安裝對大多數人都管用，還有一些定制安裝方法如果你用的上的話。Some changes can be made simply by editing the rc file, but if that is not sufficient, there’s documentation on customising Gitolite.
+
+### 設定檔和訪問規則 ###
+
+安裝結束後，你切換到 `gitolite-admin` 倉庫 (放在你的 HOME 目錄) 然後看看都有啥：
+
+	$ cd ~/gitolite-admin/
+	$ ls
+	conf/  keydir/
+	$ find conf keydir -type f
+	conf/gitolite.conf
+	keydir/scott.pub
+	$ cat conf/gitolite.conf
+
+	repo gitolite-admin
+	    RW+                 = scott
+
+	repo testing
+	    RW+                 = @all
+
+注意 "scott" ( 之前用`gl-setup` 命令時候的 pubkey 名稱) 有讀寫許可權而且在 `gitolite-admin` 倉庫裡有一個同名的公開金鑰檔。
+
+Adding users is easy.  To add a user called "alice", obtain her public key, name it `alice.pub`, and put it in the `keydir` directory of the clone of the `gitolite-admin` repo you just made on your workstation.  Add, commit, and push the change, and the user has been added.
+
+gitolite設定檔的語法在 `conf/example.conf`裡，我們只會提到一些主要的。
+
+你可以給用戶或者倉庫分組。分組名就像一些宏；定義的時候，無所謂他們是工程還是使用者；區別在於你’使用‘“宏”的時候
+
+	@oss_repos      = linux perl rakudo git gitolite
+	@secret_repos   = fenestra pear
+
+	@admins         = scott
+	@interns        = ashok
+	@engineers      = sitaram dilbert wally alice
+	@staff          = @admins @engineers @interns
+
+你可以控制許可在 "ref" 級別。在下面的例子裡，實習生可以 push "int" branch.  工程師可以 push任何有 "eng-"開頭的branch，還有refs/tags下面用 "rc"開頭的後面跟數字的。而且管理員可以隨便改 (包括rewind) 對任何參考名.
+
+	repo @oss_repos
+	    RW  int$                = @interns
+	    RW  eng-                = @engineers
+	    RW  refs/tags/rc[0-9]   = @engineers
+	    RW+                     = @admins
+
+在 `RW` or `RW+`之後的運算式是規則運算式 (regex) 對應著後面的push用的參考名字 (ref) 。所以我們叫它 "參考正則"（refex）！當然，一個 refex 可以比這裡表現的更強大，所以如果你對perl的規則運算式不熟的話就不要改過頭。
+
+同樣，你可能猜到了，Gitolite 字頭 `refs/heads/` 是一個便捷句法如果參考正則沒有用 `refs/`開頭。
+
+一個這個設定檔語法的重要功能是，所有的倉庫的規則不需要在同一個位置。你能報所有普通的東西放在一起，就像上面的對所有 `oss_repos` 的規則那樣，然後建一個特殊的規則對後面的特殊案例，就像：
+
+	repo gitolite
+	    RW+                     = sitaram
+
+那條規則剛剛加入規則集的 `gitolite` 倉庫.
+
+這次你可能會想要知道存取控制規則是如何應用的，我們簡要介紹一下。
+
+在gitolite裡有兩級存取控制。第一是在倉庫級別；如果你已經讀或者寫訪問過了任何在倉庫裡的參考，那麼你已經讀或者寫訪問倉庫了。
+
+第二級，應用只能寫訪問，通過在倉庫裡的 branch或者 tag。用戶名如果嘗試過訪問 (`W` 或 `+`)，參考名被更新為已知。訪問規則檢查是否出現在設定檔裡，為這個聯合尋找匹配 (但是記得參考名是正則匹配的，不是字串匹配的)。如果匹配被找到了，push就成功了。不匹配的訪問會被拒絕。
+
+### 帶'拒絕'的高級存取控制 ###
+
+目前，我們只看過了許可是 `R`, `RW`, 或者 `RW+`這樣子的。但是gitolite還允許另外一種許可：`-`，代表 "拒絕"。這個給了你更多的能力，當然也有一點複雜，因為不匹配並不是唯一的拒絕訪問的方法，因此規則的順序變得無關了！
+
+這麼說好了，在前面的情況中，我們想要工程師可以 rewind 任意 branch 除了master和 integ。 這裡是如何做到的
+
+	    RW  master integ    = @engineers
+	    -   master integ    = @engineers
+	    RW+                 = @engineers
+
+你再一次簡單跟隨規則從上至下知道你找到一個匹配你的訪問模式的，或者拒絕。非rewind push到 master或者 integ 被第一條規則允許。一個 rewind push到那些 refs不匹配第一條規則，掉到第二條，因此被拒絕。任何 push (rewind 或非rewind) 到參考或者其他 master 或者 integ不會被前兩條規則匹配，即被第三條規則允許。
+
+### 通過改變檔限制 push ###
+
+此外限制用戶 push改變到哪條branch的，你也可以限制哪個檔他們可以碰的到。比如, 可能 Makefile (或者其他哪些程式) 真的不能被任何人做任何改動，因為好多東西都靠著它呢，或者如果某些改變剛好不對就會崩潰。你可以告訴 gitolite:
+
+    repo foo
+        RW                      =   @junior_devs @senior_devs
+
+        -   VREF/NAME/Makefile  =   @junior_devs
+
+這是一個強力的公能寫在 `conf/example.conf`裡。
+
+### 個人分支 ###
+
+Gitolite 也支援一個叫 "個人分支"的功能 (或者叫, "個人分支命名空間") 在合作環境裡非常有用。
+
+在 git世界裡許多代碼交換通過 "pull" 請求發生。然而在合作環境裡，委任制的訪問是‘絕不’，一個開發者工作站不能認證，你必須push到中心伺服器並且叫其他人從那裡pull。
+
+這個通常會引起一些 branch 名稱簇變成像 VCS裡一樣集中化，加上設置許可變成管理員的苦差事。
+
+Gitolite讓你定義一個 "個人的" 或者 "亂七八糟的" 命名空間字首給每個開發人員 (比如，`refs/personal/<devname>/*`)；看在 `doc/3-faq-tips-etc.mkd`裡的 "personal branches" 一段獲取細節。
+
+### "萬用字元" 倉庫 ###
+
+Gitolite 允許你定義帶萬用字元的倉庫 (其實還是 perl正則式), 比如隨便整個例子的話 `assignments/s[0-9][0-9]/a[0-9][0-9]`。 這是一個非常有用的功能，需要通過設置 `$GL_WILDREPOS = 1;` 在 rc文件中啟用。允許你安排一個新許可模式 ("C") 允許用戶創建倉庫基於萬用字元，自動分配擁有權對特定用戶 - 創建者，允許他交出 R和 RW許可給其他合作用戶等等。這個功能在`doc/4-wildcard-repositories.mkd`文檔裡
+
+### 其他功能 ###
+
+我們用一些其他功能的例子結束這段討論，這些以及其他功能都在 "faqs, tips, etc" 和其他文檔裡。
+
+**記錄**: Gitolite 記錄所有成功的訪問。如果你太放鬆給了別人 rewind許可 (`RW+`) 和其他孩子弄沒了 "master"， 記錄檔會救你的命，如果其他簡單快速的找到SHA都不管用。
+
+**訪問權報告**: 另一個方便的功能是你嘗試用ssh連接到伺服器的時候發生了什麼。Gitolite告訴你哪個 repos你訪問過，那個訪問可能是什麼。這裡是例子：
+
+        hello scott, this is git@git running gitolite3 v3.01-18-g9609868 on git 1.7.4.4
+
+             R     anu-wsd
+             R     entrans
+             R  W  git-notes
+             R  W  gitolite
+             R  W  gitolite-admin
+             R     indic_web_input
+             R     shreelipi_converter
+
+**委託**：真正的大安裝，你可以把責任委託給一組倉庫給不同的人然後讓他們獨立管理那些部分。這個減少了主管理者的負擔，讓他瓶頸更小。這個功能在他自己的文檔目錄裡的 `doc/`下面。
+
+**鏡像**: Gitolite可以幫助你維護多個鏡像，如果主要伺服器掛掉的話在他們之間很容易切換。
+
+## Git 守護進程 ##
+
+對於提供公共的，非授權的唯讀訪問，我們可以拋棄 HTTP 協議，改用 Git 自己的協議，這主要是出於性能和速度的考慮。Git 協定遠比 HTTP 協定高效，因而存取速度也快，所以它能節省很多用戶的時間。
+
+重申一下，這一點隻適用於非授權的唯讀訪問。如果建在防火牆之外的伺服器上，那麼它所提供的服務應該只是那些公開的唯讀項目。如果是在防火牆之內的伺服器上，可用于支撐大量參與人員或自動系統（用於持續集成或編譯的主機）唯讀訪問的專案，這樣可以省去逐一配置 SSH 公開金鑰的麻煩。
+
+但不管哪種情形，Git 協定的配置設定都很簡單。基本上，只要以守護進程的形式運行該命令即可：
+
+	git daemon --reuseaddr --base-path=/opt/git/ /opt/git/
+
+這裡的 `--reuseaddr` 選項表示在重啟服務前，不等之前的連接逾時就立即重啟。而 `--base-path` 選項則允許克隆專案時不必給出完整路徑。最後面的路徑告訴 Git 守護進程允許開放給使用者訪問的倉庫目錄。假如有防火牆，則需要為該主機的 9418 埠設置為允許通信。
+
+以守護進程的形式運行該進程的方法有很多，但主要還得看用的是什麼作業系統。在 Ubuntu 主機上，可以用 Upstart 腳本達成。編輯該檔：
+
+	/etc/event.d/local-git-daemon
+
+加入以下內容：
+
+	start on startup
+	stop on shutdown
+	exec /usr/bin/git daemon \
+	    --user=git --group=git \
+	    --reuseaddr \
+	    --base-path=/opt/git/ \
+	    /opt/git/
+	respawn
+
+出於安全考慮，強烈建議用一個對倉庫只有讀取許可權的使用者身份來運行該進程 — 只需要簡單地新建一個名為 `git-ro` 的用戶（譯注：新建用戶默認對倉庫檔不具備寫許可權，但這取決於倉庫目錄的許可權設定。務必確認 `git-ro` 對倉庫只能讀不能寫。），並用它的身份來啟動進程。這裡為了簡化，後面我們還是用之前運行 Gitosis 的用戶 'git'。
+
+這樣一來，當你重啟電腦時，Git 進程也會自動啟動。要是進程意外退出或者被殺掉，也會自行重啟。在設置完成後，不重啟電腦就啟動該守護進程，可以運行：
+
+	initctl start local-git-daemon
+
+而在其他作業系統上，可以用 `xinetd`，或者 `sysvinit` 系統的腳本，或者其他類似的腳本 — 只要能讓那個命令變為守護進程並可監控。
+
+接下來，我們必須告訴 Gitosis 哪些倉庫允許通過 Git 協議進行匿名唯讀訪問。如果每個倉庫都設有各自的段落，可以分別指定是否允許 Git 進程開放給使用者匿名讀取。比如允許通過 Git 協議訪問 iphone_project，可以把下面兩行加到 `gitosis.conf` 文件的末尾：
+
+	[repo iphone_project]
+	daemon = yes
+
+在提交和推送完成後，運行中的 Git 守護進程就會回應來自 9418 埠對該專案的訪問請求。
+
+如果不考慮 Gitosis，單單起了 Git 守護進程的話，就必須到每一個允許匿名唯讀訪問的倉庫目錄內，創建一個特殊名稱的空檔作為標誌：
+
+	$ cd /path/to/project.git
+	$ touch git-daemon-export-ok
+
+該檔的存在，表明允許 Git 守護進程開放對該專案的匿名唯讀訪問。
+
+Gitosis 還能設定哪些項目允許放在 GitWeb 上顯示。先打開 GitWeb 的設定檔 `/etc/gitweb.conf`，添加以下四行：
+
+	$projects_list = "/home/git/gitosis/projects.list";
+	$projectroot = "/home/git/repositories";
+	$export_ok = "git-daemon-export-ok";
+	@git_base_url_list = ('git://gitserver');
+
+接下來，只要配置各個專案在 Gitosis 中的 `gitweb` 參數，便能達成是否允許 GitWeb 用戶流覽該專案。比如，要讓 iphone_project 項目在 GitWeb 裡出現，把 `repo` 的設定改成下面的樣子：
+
+	[repo iphone_project]
+	daemon = yes
+	gitweb = yes
+
+在提交並推送過之後，GitWeb 就會自動開始顯示 iphone_project 專案的細節和歷史。
+
+## Git 託管服務 ##
+
+如果不想經歷自己架設 Git 伺服器的麻煩，網路上有幾個專業的倉庫託管服務可供選擇。這樣做有幾大優點：託管帳戶的建立通常比較省時，方便專案的啟動，而且不涉及伺服器的維護和監控。即使內部創建並運行著自己的伺服器，同時為開源項目提供一個公共託管網站還是有好處的 — 讓開源社區更方便地找到該專案，並給予幫助。
+
+目前，可供選擇的託管服務數量繁多，各有利弊。在 Git 官方 wiki 上的 Githosting 頁面有一個最新的託管服務清單：
+
+	https://git.wiki.kernel.org/index.php/GitHosting
+
+由於本書無法全部一一介紹，而本人（譯注：指本書作者 Scott Chacon。）剛好在其中一家公司工作，所以接下來我們將會介紹如何在 GitHub 上建立新帳戶並啟動專案。至於其他託管服務大體也是這麼一個過程，基本的想法都是差不多的。
+
+GitHub 是目前為止最大的開源 Git 託管服務，並且還是少數同時提供公共代碼和私有代碼託管服務的網站之一，所以你可以在上面同時保存開源和商業代碼。事實上，本書就是放在 GitHub 上合作編著的。（譯注：本書的翻譯也是放在 GitHub 上廣泛協作的。）
+
+### GitHub ###
+
+GitHub 和大多數的代碼託管網站在處理專案命名空間的方式上略有不同。GitHub 的設計更側重於用戶，而不是完全基於專案。也就是說，如果我在 GitHub 上託管一個名為 `grit` 的項目的話，它的位址不會是 `github.com/grit`，而是按在用戶底下 `github.com/shacon/grit` （譯注：本書作者 Scott Chacon 在 GitHub 上的用戶名是 `shacon`。）。不存在所謂某個項目的官方版本，所以假如第一作者放棄了某個項目，它可以無縫轉移到其它用戶的名下。
+
+GitHub 同時也是一個向使用私有倉庫的用戶收取費用的商業公司，但任何人都可以方便快捷地申請到一個免費帳戶，並在上面託管數量不限的開源項目。接下來我們快速介紹一下 GitHub 的基本使用。
+
+### 建立新帳戶 ###
+
+首先註冊一個免費帳戶。訪問 Pricing and Signup 頁面 `http://github.com/plans` 並點擊 Free acount 裡的 Sign Up 按鈕（見圖 4-2），進入註冊頁面。
+
+Insert 18333fig0402.png
+圖 4-2. GitHub 服務簡介頁面
+
+選擇一個系統中尚未使用的用戶名，提供一個與之相關聯的電郵位址，並輸入密碼（見圖 4-3）：
+
+Insert 18333fig0403.png
+圖 4-3. GitHub 用戶註冊表單
+
+如果方便，現在就可以提供你的 SSH 公開金鑰。我們在前文的"小型安裝" 一節介紹過生成新公開金鑰的方法。把新生成的公開金鑰複製粘貼到 SSH Public Key 文字方塊中即可。要是對生成公開金鑰的步驟不太清楚，也可以點擊 "explain ssh keys" 連結，會顯示各個主流作業系統上完成該步驟的介紹。
+點擊 "I agree，sign me up" 按鈕完成使用者註冊，並轉到該使用者的 dashboard 頁面（見圖 4-4）:
+
+Insert 18333fig0404.png
+圖 4-4. GitHub 的用戶面板
+
+接下來就可以建立新倉庫了。
+
+### 建立新倉庫 ###
+
+點擊用戶面板上倉庫旁邊的 "create a new one" 連結，顯示 Create a New Repository 的表單（見圖 4-5）：
+
+Insert 18333fig0405.png
+圖 4-5. 在 GitHub 上建立新倉庫
+
+當然，項目名稱是必不可少的，此外也可以適當描述一下專案的情況或者給出官方網站的位址。然後點擊 "Create Repository" 按鈕，新倉庫就建立起來了（見圖 4-6）：
+
+Insert 18333fig0406.png
+圖 4-6. GitHub 上各個專案的概要資訊
+
+由於尚未提交代碼，點擊專案位址後 GitHub 會顯示一個簡要的指南，告訴你如何新建一個專案並推送上來，如何從現有項目推送，以及如何從一個公共的 Subversion 倉庫導入項目（見圖 4-7）：
+
+Insert 18333fig0407.png
+圖 4-7. 新倉庫指南
+
+該指南和本書前文介紹的類似，對於新的專案，需要先在本地初始化為 Git 專案，添加要管理的檔並作首次提交：
+
+	$ git init
+	$ git add .
+	$ git commit -m 'initial commit'
+
+然後在這個本地倉庫內把 GitHub 添加為遠端倉庫，並推送 master 分支上來：
+
+	$ git remote add origin git@github.com:testinguser/iphone_project.git
+	$ git push origin master
+
+現在該項目就託管在 GitHub 上了。你可以把它的 URL 分享給每位對此項目感興趣的人。本例的 URL 是 `http://github.com/testinguser/iphone_project`。而在專案頁面的摘要部分，你會發現有兩個 Git URL 位址（見圖 4-8）：
+
+Insert 18333fig0408.png
+圖 4-8. 項目摘要中的公共 URL 和私有 URL
+
+Public Clone URL 是一個公開的，唯讀的 Git URL，任何人都可以通過它克隆該專案。可以隨意散播這個 URL，比如發佈到個人網站之類的地方等等。
+
+Your Clone URL 是一個基於 SSH 協議的可讀可寫 URL，只有使用與上傳的 SSH 公開金鑰對應的金鑰來連接時，才能通過它進行讀寫操作。其他使用者訪問該專案頁面時只能看到之前那個公共的 URL，看不到這個私有的 URL。
+
+### 從 Subversion 導入項目 ###
+
+如果想把某個公共 Subversion 項目導入 Git，GitHub 可以幫忙。在指南的最後有一個指嚮導入 Subversion 頁面的連結。點擊它會看到一個表單，包含有關導入流程的資訊以及一個用來粘貼公共 Subversion 項目連接的文字方塊（見圖 4-9）：
+
+Insert 18333fig0409.png
+圖 4-9. Subversion 導入介面
+
+如果專案很大，採用非標準結構，或者是私有的，那就無法借助該工具實現導入。到第 7 章，我們會介紹如何手工導入複雜工程的具體方法。
+
+### 添加協作開發者 ###
+
+現在把團隊裡的其他人也加進來。如果 John，Josie 和 Jessica 都在 GitHub 註冊了帳戶，要賦予他們對該倉庫的推送許可權，可以把他們加為專案協作者。這樣他們就可以通過各自的公開金鑰訪問我的這個倉庫了。
+
+點擊專案頁面上方的 "edit" 按鈕或者頂部的 Admin 標籤，進入該專案的管理頁面（見圖 4-10）：
+
+Insert 18333fig0410.png
+圖 4-10. GitHub 的專案管理頁面
+
+為了給另一個用戶添加項目的寫許可權，點擊 "Add another collaborator" 連結，出現一個用於輸入用戶名的表單。在輸入的同時，它會自動跳出一個符合條件的候選名單。找到正確用戶名之後，點 Add 按鈕，把該使用者設為專案協作者（見圖 4-11）：
+
+Insert 18333fig0411.png
+圖 4-11. 為專案添加協作者
+
+添加完協作者之後，就可以在 Repository Collaborators 區域看到他們的名單（見圖 4-12）：
+
+Insert 18333fig0412.png
+圖 4-12. 專案協作者名單
+
+如果要取消某人的訪問權，點擊 "revoke" 即可取消他的推送許可權。對於將來的專案，你可以從現有專案複製協作者名單，或者直接借用協作者群組。
+
+### 專案頁面 ###
+
+在推送或從 Subversion 導入項目之後，你會看到一個類似圖 4-13 的項目主頁：
+
+Insert 18333fig0413.png
+圖 4-13. GitHub 上的項目主頁
+
+別人訪問你的專案時看到的就是這個頁面。它有若干導航標籤，Commits 標籤用於顯示提交歷史，最新的提交位於最上方，這和 `git log` 命令的輸出類似。Network 標籤展示所有派生了該專案並做出貢獻的用戶的關係圖譜。Downloads 標籤允許你上傳項目的二進位檔案，提供下載該項目各個版本的 tar/zip 包。Wiki 標籤提供了一個用於撰寫文檔或其他專案相關資訊的 wiki 網站。Graphs 標籤包含了一些視覺化的專案資訊與資料。預設打開的 Source 標籤頁面，則列出了該專案的目錄結構和概要資訊，並在下方自動展示 README 檔的內容（如果該檔存在的話），此外還會顯示最近一次提交的相關資訊。
+
+### 派生項目 ###
+
+如果要為一個自己沒有推送許可權的項目貢獻代碼，GitHub 鼓勵使用派生（fork）。到那個感興趣的項目主頁上，點擊頁面上方的 "fork" 按鈕，GitHub 就會為你複製一份該項目的副本到你的倉庫中，這樣你就可以向自己的這個副本推送資料了。
+
+採取這種辦法的好處是，專案擁有者不必忙於應付賦予他人推送許可權的工作。隨便誰都可以通過派生得到一個專案副本並在其中展開工作，事後只需要專案維護者將這些副本倉庫加為遠端倉庫，然後提取更新合併即可。
+
+要派生一個專案，到原始專案的頁面（本例中是 mojombo/chronic）點擊 "fork" 按鈕（見圖 4-14）：
+
+Insert 18333fig0414.png
+圖 4-14. 點擊 "fork" 按鈕獲得任意專案的可寫副本
+
+幾秒鐘之後，你將進入新建的專案頁面，會顯示該專案派生自哪一個項目（見圖 4-15）：
+
+Insert 18333fig0415.png
+圖 4-15. 派生後得到的項目副本
+
+### GitHub 小結 ###
+
+關於 GitHub 就先介紹這麼多，能夠快速達成這些事情非常重要（譯注：門檻的降低和完成基本任務的簡單高效，對於推動開源專案的協作發展有著舉足輕重的意義。）。短短幾分鐘內，你就能創建一個新帳戶，添加一個專案並開始推送。如果專案是開源的，整個龐大的開發者社區都可以立即訪問它，提供各式各樣的幫助和貢獻。最起碼，這也是一種 Git 新手立即體驗嘗試 Git 的捷徑。
+
+## 小結 ##
+
+我們討論並介紹了一些建立遠端 Git 倉庫的方法，接下來你可以通過這些倉庫同他人分享或合作。
+
+運行自己的伺服器意味著更多的控制權以及在防火牆內部操作的可能性，當然這樣的伺服器通常需要投入一定的時間精力來架設維護。如果直接託管，雖然能免去這部分工作，但有時出於安全或版權的考慮，有些公司禁止將商業代碼託管到協力廠商服務商。
+
+所以究竟採取哪種方案，並不是個難以取捨的問題，或者其一，或者相互配合，哪種合適就用哪種。

From d85f960bb3bb312759aa48645cd450c7cddd7be9 Mon Sep 17 00:00:00 2001
From: ya_hsiung <ya_hsiung@yahoo.com>
Date: Fri, 7 Mar 2014 14:01:29 +0800
Subject: [PATCH 260/690] chapter 5 finished

---
 zh-tw/05-distributed-git/01-chapter5.markdown | 912 ++++++++++++++++++
 1 file changed, 912 insertions(+)
 create mode 100644 zh-tw/05-distributed-git/01-chapter5.markdown

diff --git a/zh-tw/05-distributed-git/01-chapter5.markdown b/zh-tw/05-distributed-git/01-chapter5.markdown
new file mode 100644
index 000000000..b8dbecdd5
--- /dev/null
+++ b/zh-tw/05-distributed-git/01-chapter5.markdown
@@ -0,0 +1,912 @@
+# 分散式 Git #
+
+為了便於專案中的所有開發者分享代碼，我們準備好了一台伺服器存放遠端 Git 倉庫。經過前面幾章的學習，我們已經學會了一些基本的本地工作流程中所需用到的命令。接下來，我們要學習下如何利用 Git 來組織和完成分散式工作流程。
+
+特別是，當作為項目貢獻者時，我們該怎麼做才能方便維護者採納更新；或者作為專案維護者時，又該怎樣有效管理大量貢獻者的提交。
+
+## 分散式工作流程 ##
+
+同傳統的集中式版本控制系統（CVCS）不同，開發者之間的協作方式因著 Git 的分散式特性而變得更為靈活多樣。在集中式系統上，每個開發者就像是連接在集線器上的節點，彼此的工作方式大體相像。而在 Git 網路中，每個開發者同時扮演著節點和集線器的角色，這就是說，每一個開發者都可以將自己的代碼貢獻到另外一個開發者的倉庫中，或者建立自己的公共倉庫，讓其他開發者基於自己的工作開始，為自己的倉庫貢獻代碼。於是，Git 的分散式協作便可以衍生出種種不同的工作流程，我會在接下來的章節介紹幾種常見的應用方式，並分別討論各自的優缺點。你可以選擇其中的一種，或者結合起來，應用到你自己的專案中。
+
+### 集中式工作流 ###
+
+通常，集中式工作流程使用的都是單點協作模型。一個存放代碼倉庫的中心伺服器，可以接受所有開發者提交的代碼。所有的開發者都是普通的節點，作為中心集線器的消費者，平時的工作就是和中心倉庫同步資料（見圖 5-1）。
+
+Insert 18333fig0501.png
+圖 5-1. 集中式工作流
+
+如果兩個開發者從中心倉庫克隆代碼下來，同時作了一些修訂，那麼只有第一個開發者可以順利地把資料推送到共用伺服器。第二個開發者在提交他的修訂之前，必須先下載合併伺服器上的資料，解決衝突之後才能推送資料到共用伺服器上。在 Git 中這麼用也決無問題，這就好比是在用 Subversion（或其他 CVCS）一樣，可以很好地工作。
+
+如果你的團隊不是很大，或者大家都已經習慣了使用集中式工作流程，完全可以採用這種簡單的模式。只需要配置好一台中心伺服器，並給每個人推送資料的許可權，就可以開展工作了。但如果提交代碼時有衝突， Git 根本就不會讓用戶覆蓋他人代碼，它直接駁回第二個人的提交操作。這就等於告訴提交者，你所作的修訂無法通過快近（fast-forward）來合併，你必須先拉取最新資料下來，手工解決衝突合併後，才能繼續推送新的提交。
+絕大多數人都熟悉和瞭解這種模式的工作方式，所以使用也非常廣泛。
+
+### 集成管理員工作流 ###
+
+由於 Git 允許使用多個遠端倉庫，開發者便可以建立自己的公共倉庫，往裡面寫資料並共用給他人，而同時又可以從別人的倉庫中提取他們的更新過來。這種情形通常都會有個代表著官方發佈的專案倉庫（blessed repository），開發者們由此倉庫克隆出一個自己的公共倉庫（developer public），然後將自己的提交推送上去，請求官方倉庫的維護者拉取更新合併到主項目。維護者在自己的本地也有個克隆倉庫（integration manager），他可以將你的公共倉庫作為遠端倉庫添加進來，經過測試無誤後合併到主幹分支，然後再推送到官方倉庫。工作流程看起來就像圖 5-2 所示：
+
+1. 專案維護者可以推送資料到公共倉庫 blessed repository。
+2. 貢獻者克隆此倉庫，修訂或編寫新代碼。
+3. 貢獻者推送資料到自己的公共倉庫 developer public。
+4. 貢獻者給維護者發送郵件，請求拉取自己的最新修訂。
+5. 維護者在自己本地的 integration manger 倉庫中，將貢獻者的倉庫加為遠程倉庫，合併更新並做測試。
+6. 維護者將合併後的更新推送到主倉庫 blessed repository。
+
+Insert 18333fig0502.png
+圖 5-2. 集成管理員工作流
+
+在 GitHub 網站上使用得最多的就是這種工作流。人們可以複製（fork 亦即克隆）某個項目到自己的列表中，成為自己的公共倉庫。隨後將自己的更新提交到這個倉庫，所有人都可以看到你的每次更新。這麼做最主要的優點在於，你可以按照自己的節奏繼續工作，而不必等待維護者處理你提交的更新；而維護者也可以按照自己的節奏，任何時候都可以過來處理接納你的貢獻。
+
+### 司令官與副官工作流 ###
+
+這其實是上一種工作流的變體。一般超大型的專案才會用到這樣的工作方式，像是擁有數百協作開發者的 Linux 內核專案就是如此。各個集成管理員分別負責集成專案中的特定部分，所以稱為副官（lieutenant）。而所有這些集成管理員頭上還有一位負責統籌的總集成管理員，稱為司令官（dictator）。司令官維護的倉庫用於提供所有協作者拉取最新集成的項目代碼。整個流程看起來如圖 5-3 所示：
+
+1. 一般的開發者在自己的特性分支上工作，並不定期地根據主幹分支（dictator 上的 master）衍合。
+2. 副官（lieutenant）將普通開發者的特性分支合併到自己的 master 分支中。
+3. 司令官（dictator）將所有副官的 master 分支併入自己的 master 分支。
+4. 司令官（dictator）將集成後的 master 分支推送到共用倉庫 blessed repository 中，以便所有其他開發者以此為基礎進行衍合。
+
+Insert 18333fig0503.png
+圖 5-3. 司令官與副官工作流
+
+這種工作流程並不常用，只有當專案極為龐雜，或者需要多級別管理時，才會體現出優勢。利用這種方式，專案總負責人（即司令官）可以把大量分散的集成工作委託給不同的小組負責人分別處理，最後再統籌起來，如此各人的職責清晰明確，也不易出錯（譯注：此乃分而治之）。
+
+以上介紹的是常見的分散式系統可以應用的工作流程，當然不止於 Git。在實際的開發工作中，你可能會遇到各種為了滿足特定需求而有所變化的工作方式。我想現在你應該已經清楚，接下來自己需要用哪種方式開展工作了。下節我還會再舉些例子，看看各式工作流中的每個角色具體應該如何操作。
+
+## 為專案作貢獻 ##
+
+接下來，我們來學習一下作為專案貢獻者，會有哪些常見的工作模式。
+
+不過要說清楚整個協作過程真的很難，Git 如此靈活，人們的協作方式便可以各式各樣，沒有固定不變的範式可循，而每個專案的具體情況又多少會有些不同，比如說參與者的規模，所選擇的工作流程，每個人的提交許可權，以及 Git 以外貢獻等等，都會影響到具體操作的細節。
+
+首當其衝的是參與者規模。專案中有多少開發者是經常提交代碼的？經常又是多久呢？大多數兩至三人的小團隊，一天大約只有幾次提交，如果不是什麼熱門項目的話就更少了。可要是在大公司裡，或者大項目中，參與者可以多到上千，每天都會有十幾個上百個補丁提交上來。這種差異帶來的影響是顯著的，越是多的人參與進來，就越難保證每次合併正確無誤。你正在工作的代碼，可能會因為合併進來其他人的更新而變得過時，甚至受創無法運行。而已經提交上去的更新，也可能在等著審核合併的過程中變得過時。那麼，我們該怎樣做才能確保代碼是最新的，提交的補丁也是可用的呢？
+
+接下來便是專案所採用的工作流。是集中式的，每個開發者都具有等同的寫許可權？專案是否有專人負責檢查所有補丁？是不是所有補丁都做過同行複閱（peer-review）再通過審核的？你是否參與審核過程？如果使用副官系統，那你是不是限定于只能向此副官提交？
+
+還有你的提交許可權。有或沒有向主專案提交更新的許可權，結果完全不同，直接決定最終採用怎樣的工作流。如果不能直接提交更新，那該如何貢獻自己的代碼呢？是不是該有個什麼策略？你每次貢獻代碼會有多少量？提交頻率呢？
+
+所有以上這些問題都會或多或少影響到最終採用的工作流。接下來，我會在一系列由簡入繁的具體用例中，逐一闡述。此後在實踐時，應該可以借鑒這裡的例子，略作調整，以滿足實際需要構建自己的工作流。
+
+### 提交指南 ###
+
+開始分析特定用例之前，先來瞭解下如何撰寫提交說明。一份好的提交指南可以説明協作者更輕鬆更有效地配合。Git 項目本身就提供了一份文檔（Git 專案原始程式碼目錄中 `Documentation/SubmittingPatches`），列數了大量提示，從如何編撰提交說明到提交補丁，不一而足。
+
+首先，請不要在更新中提交多餘的白字元（whitespace）。Git 有種檢查此類問題的方法，在提交之前，先運行 `git diff --check`，會把可能的多餘白字元修正列出來。下面的示例，我已經把終端中顯示為紅色的白字元用 `X` 替換掉：
+
+	$ git diff --check
+	lib/simplegit.rb:5: trailing whitespace.
+	+    @git_dir = File.expand_path(git_dir)XX
+	lib/simplegit.rb:7: trailing whitespace.
+	+ XXXXXXXXXXX
+	lib/simplegit.rb:26: trailing whitespace.
+	+    def command(git_cmd)XXXX
+
+這樣在提交之前你就可以看到這類問題，及時解決以免困擾其他開發者。
+
+接下來，請將每次提交限定於完成一次邏輯功能。並且可能的話，適當地分解為多次小更新，以便每次小型提交都更易於理解。請不要在週末窮追猛打一次性解決五個問題，而最後拖到週一再提交。就算是這樣也請盡可能利用暫存區域，將之前的改動分解為每次修復一個問題，再分別提交和加注說明。如果針對兩個問題改動的是同一個檔，可以試試看 `git add --patch` 的方式將部分內容置入暫存區域（我們會在第六章再詳細介紹）。無論是五次小提交還是混雜在一起的大提交，最終分支末端的專案快照應該還是一樣的，但分解開來之後，更便於其他開發者複閱。這麼做也方便自己將來取消某個特定問題的修復。我們將在第六章介紹一些重寫提交歷史，同暫存區域交互的技巧和工具，以便最終得到一個乾淨有意義，且易於理解的提交歷史。
+
+最後需要謹記的是提交說明的撰寫。寫得好可以讓大家協作起來更輕鬆。一般來說，提交說明最好限制在一行以內，50 個字元以下，簡明扼要地描述更新內容，空開一行後，再展開詳細注解。Git 專案本身需要開發者撰寫詳盡注解，包括本次修訂的因由，以及前後不同實現之間的比較，我們也該借鑒這種做法。另外，提交說明應該用祈使現在式語態，比如，不要說成 “I added tests for” 或 “Adding tests for” 而應該用 “Add tests for”。
+下麵是來自 tpope.net 的 Tim Pope 原創的提交說明格式模版，供參考：
+
+	本次更新的簡要描述（50 個字元以內）
+
+	如果必要，此處展開詳盡闡述。段落寬度限定在 72 個字元以內。
+	某些情況下，第一行的簡要描述將用作郵件標題，其餘部分作為郵件正文。
+	其間的空行是必要的，以區分兩者（當然沒有正文另當別論）。
+	如果並在一起，rebase 這樣的工具就可能會迷惑。
+
+	另起空行後，再進一步補充其他說明。
+
+	 - 可以使用這樣的條目列舉式。
+
+	 - 一般以單個空格緊跟短劃線或者星號作為每項條目的起始符。每個條目間用一空行隔開。
+	   不過這裡按自己項目的約定，可以略作變化。
+
+如果你的提交說明都用這樣的格式來書寫，好多事情就可以變得十分簡單。Git 專案本身就是這樣要求的，我強烈建議你到 Git 專案倉庫下運行 `git log --no-merges` 看看，所有提交歷史的說明是怎樣撰寫的。（譯注：如果現在還沒有克隆 git 項目原始程式碼，是時候 `git clone git://git.kernel.org/pub/scm/git/git.git` 了。）
+
+為簡單起見，在接下來的例子（及本書隨後的所有演示）中，我都不會用這種格式，而使用 `-m` 選項提交 `git commit`。不過請還是按照我之前講的做，別學我這裡偷懶的方式。
+
+### 私有的小型團隊 ###
+
+我們從最簡單的情況開始，一個私有專案，與你一起協作的還有另外一到兩位開發者。這裡說私有，是指原始程式碼不公開，其他人無法訪問項目倉庫。而你和其他開發者則都具有推送資料到倉庫的許可權。
+
+這種情況下，你們可以用 Subversion 或其他集中式版本控制系統類似的工作流來協作。你仍然可以得到 Git 帶來的其他好處：離線提交，快速分支與合併等等，但工作流程還是差不多的。主要區別在於，合併操作發生在用戶端而非伺服器上。
+讓我們來看看，兩個開發者一起使用同一個共用倉庫，會發生些什麼。第一個人，John，克隆了倉庫，作了些更新，在本地提交。（下面的例子中省略了常規提示，用 `...` 代替以節約版面。）
+
+	# John's Machine
+	$ git clone john@githost:simplegit.git
+	Initialized empty Git repository in /home/john/simplegit/.git/
+	...
+	$ cd simplegit/
+	$ vim lib/simplegit.rb
+	$ git commit -am 'removed invalid default value'
+	[master 738ee87] removed invalid default value
+	 1 files changed, 1 insertions(+), 1 deletions(-)
+
+第二個開發者，Jessica，一樣這麼做：克隆倉庫，提交更新：
+
+	# Jessica's Machine
+	$ git clone jessica@githost:simplegit.git
+	Initialized empty Git repository in /home/jessica/simplegit/.git/
+	...
+	$ cd simplegit/
+	$ vim TODO
+	$ git commit -am 'add reset task'
+	[master fbff5bc] add reset task
+	 1 files changed, 1 insertions(+), 0 deletions(-)
+
+現在，Jessica 將她的工作推送到伺服器上：
+
+	# Jessica's Machine
+	$ git push origin master
+	...
+	To jessica@githost:simplegit.git
+	   1edee6b..fbff5bc  master -> master
+
+John 也嘗試推送自己的工作上去：
+
+	# John's Machine
+	$ git push origin master
+	To john@githost:simplegit.git
+	 ! [rejected]        master -> master (non-fast forward)
+	error: failed to push some refs to 'john@githost:simplegit.git'
+
+John 的推送操作被駁回，因為 Jessica 已經推送了新的資料上去。請注意，特別是你用慣了 Subversion 的話，這裡其實修改的是兩個檔，而不是同一個檔的同一個地方。Subversion 會在伺服器端自動合併提交上來的更新，而 Git 則必須先在本地合併後才能推送。於是，John 不得不先把 Jessica 的更新拉下來：
+
+	$ git fetch origin
+	...
+	From john@githost:simplegit
+	 + 049d078...fbff5bc master     -> origin/master
+
+此刻，John 的本地倉庫如圖 5-4 所示：
+
+Insert 18333fig0504.png
+圖 5-4. John 的倉庫歷史
+
+雖然 John 下載了 Jessica 推送到伺服器的最近更新（fbff5），但目前只是 `origin/master` 指標指向它，而當前的本地分支 `master` 仍然指向自己的更新（738ee），所以需要先把她的提交合併過來，才能繼續推送資料：
+
+	$ git merge origin/master
+	Merge made by recursive.
+	 TODO |    1 +
+	 1 files changed, 1 insertions(+), 0 deletions(-)
+
+還好，合併過程非常順利，沒有衝突，現在 John 的提交歷史如圖 5-5 所示：
+
+Insert 18333fig0505.png
+圖 5-5. 合併 origin/master 後 John 的倉庫歷史
+
+現在，John 應該再測試一下代碼是否仍然正常工作，然後將合併結果（72bbc）推送到伺服器上：
+
+	$ git push origin master
+	...
+	To john@githost:simplegit.git
+	   fbff5bc..72bbc59  master -> master
+
+最終，John 的提交歷史變為圖 5-6 所示：
+
+Insert 18333fig0506.png
+圖 5-6. 推送後 John 的倉庫歷史
+
+而在這段時間，Jessica 已經開始在另一個特性分支工作了。她創建了 `issue54` 並提交了三次更新。她還沒有下載 John 提交的合併結果，所以提交歷史如圖 5-7 所示：
+
+Insert 18333fig0507.png
+圖 5-7. Jessica 的提交歷史
+
+Jessica 想要先和伺服器上的資料同步，所以先下載資料：
+
+	# Jessica's Machine
+	$ git fetch origin
+	...
+	From jessica@githost:simplegit
+	   fbff5bc..72bbc59  master     -> origin/master
+
+於是 Jessica 的本地倉庫歷史多出了 John 的兩次提交（738ee 和 72bbc），如圖 5-8 所示：
+
+Insert 18333fig0508.png
+圖 5-8. 獲取 John 的更新之後 Jessica 的提交歷史
+
+此時，Jessica 在特性分支上的工作已經完成，但她想在推送資料之前，先確認下要並進來的資料究竟是什麼，於是運行 `git log` 查看：
+
+	$ git log --no-merges origin/master ^issue54
+	commit 738ee872852dfaa9d6634e0dea7a324040193016
+	Author: John Smith <jsmith@example.com>
+	Date:   Fri May 29 16:01:27 2009 -0700
+
+	    removed invalid default value
+
+現在，Jessica 可以將特性分支上的工作並到 `master` 分支，然後再併入 John 的工作（`origin/master`）到自己的 `master` 分支，最後再推送回伺服器。當然，得先切回主分支才能集成所有資料：
+
+	$ git checkout master
+	Switched to branch "master"
+	Your branch is behind 'origin/master' by 2 commits, and can be fast-forwarded.
+
+要合併 `origin/master` 或 `issue54` 分支，誰先誰後都沒有關係，因為它們都在上游（upstream）（譯注：想像分叉的更新像是匯流成河的源頭，所以上游 upstream 是指最新的提交），所以無所謂先後順序，最終合併後的內容快照都是一樣的，而僅是提交歷史看起來會有些先後差別。Jessica 選擇先合併 `issue54`：
+
+	$ git merge issue54
+	Updating fbff5bc..4af4298
+	Fast forward
+	 README           |    1 +
+	 lib/simplegit.rb |    6 +++++-
+	 2 files changed, 6 insertions(+), 1 deletions(-)
+
+正如所見，沒有衝突發生，僅是一次簡單快進。現在 Jessica 開始合併 John 的工作（`origin/master`）：
+
+	$ git merge origin/master
+	Auto-merging lib/simplegit.rb
+	Merge made by recursive.
+	 lib/simplegit.rb |    2 +-
+	 1 files changed, 1 insertions(+), 1 deletions(-)
+
+所有的合併都非常乾淨。現在 Jessica 的提交歷史如圖 5-9 所示：
+
+Insert 18333fig0509.png
+圖 5-9. 合併 John 的更新後 Jessica 的提交歷史
+
+現在 Jessica 已經可以在自己的 `master` 分支中訪問 `origin/master` 的最新改動了，所以她應該可以成功推送最後的合併結果到伺服器上（假設 John 此時沒再推送新資料上來）：
+
+	$ git push origin master
+	...
+	To jessica@githost:simplegit.git
+	   72bbc59..8059c15  master -> master
+
+至此，每個開發者都提交了若干次，且成功合併了對方的工作成果，最新的提交歷史如圖 5-10 所示：
+
+Insert 18333fig0510.png
+圖 5-10. Jessica 推送資料後的提交歷史
+
+以上就是最簡單的協作方式之一：先在自己的特性分支中工作一段時間，完成後合併到自己的 `master` 分支；然後下載合併 `origin/master` 上的更新（如果有的話），再推回遠端伺服器。一般的協作流程如圖 5-11 所示：
+
+Insert 18333fig0511.png
+圖 5-11. 多使用者共用倉庫協作方式的一般工作流程時序
+
+### 私有團隊間協作 ###
+
+現在我們來看更大一點規模的私有團隊協作。如果有幾個小組分頭負責若干特性的開發和集成，那他們之間的協作過程是怎樣的。
+
+假設 John 和 Jessica 一起負責開發某項特性 A，而同時 Jessica 和 Josie 一起負責開發另一項功能 B。公司使用典型的集成管理員式工作流，每個組都有一名管理員負責集成本組代碼，及更新專案主倉庫的 `master` 分支。所有開發都在代表小組的分支上進行。
+
+讓我們跟隨 Jessica 的視角看看她的工作流程。她參與開發兩項特性，同時和不同小組的開發者一起協作。克隆生成本地倉庫後，她打算先著手開發特性 A。於是創建了新的 `featureA` 分支，繼而編寫代碼：
+
+	# Jessica's Machine
+	$ git checkout -b featureA
+	Switched to a new branch "featureA"
+	$ vim lib/simplegit.rb
+	$ git commit -am 'add limit to log function'
+	[featureA 3300904] add limit to log function
+	 1 files changed, 1 insertions(+), 1 deletions(-)
+
+此刻，她需要分享目前的進展給 John，於是她將自己的 `featureA` 分支提交到伺服器。由於 Jessica 沒有許可權推送資料到主倉庫的 `master` 分支（只有集成管理員有此許可權），所以只能將此分支推上去同 John 共用協作：
+
+	$ git push origin featureA
+	...
+	To jessica@githost:simplegit.git
+	 * [new branch]      featureA -> featureA
+
+Jessica 發郵件給 John 讓他上來看看 `featureA` 分支上的進展。在等待他的回饋之前，Jessica 決定繼續工作，和 Josie 一起開發 `featureB` 上的特性 B。當然，先創建此分支，分叉點以伺服器上的 `master` 為起點：
+
+	# Jessica's Machine
+	$ git fetch origin
+	$ git checkout -b featureB origin/master
+	Switched to a new branch "featureB"
+
+隨後，Jessica 在 `featureB` 上提交了若干更新：
+
+	$ vim lib/simplegit.rb
+	$ git commit -am 'made the ls-tree function recursive'
+	[featureB e5b0fdc] made the ls-tree function recursive
+	 1 files changed, 1 insertions(+), 1 deletions(-)
+	$ vim lib/simplegit.rb
+	$ git commit -am 'add ls-files'
+	[featureB 8512791] add ls-files
+	 1 files changed, 5 insertions(+), 0 deletions(-)
+
+現在 Jessica 的更新歷史如圖 5-12 所示：
+
+Insert 18333fig0512.png
+圖 5-12. Jessica 的更新歷史
+
+Jessica 正準備推送自己的進展上去，卻收到 Josie 的來信，說是她已經將自己的工作推到伺服器上的 `featureBee` 分支了。這樣，Jessica 就必須先將 Josie 的代碼合併到自己本地分支中，才能再一起推送回伺服器。她用 `git fetch` 下載 Josie 的最新代碼：
+
+	$ git fetch origin
+	...
+	From jessica@githost:simplegit
+	 * [new branch]      featureBee -> origin/featureBee
+
+然後 Jessica 使用 `git merge` 將此分支合併到自己分支中：
+
+	$ git merge origin/featureBee
+	Auto-merging lib/simplegit.rb
+	Merge made by recursive.
+	 lib/simplegit.rb |    4 ++++
+	 1 files changed, 4 insertions(+), 0 deletions(-)
+
+合併很順利，但另外有個小問題：她要推送自己的 `featureB` 分支到伺服器上的 `featureBee` 分支上去。當然，她可以使用冒號（:）格式指定目標分支：
+
+	$ git push origin featureB:featureBee
+	...
+	To jessica@githost:simplegit.git
+	   fba9af8..cd685d1  featureB -> featureBee
+
+我們稱此為_refspec_。更多有關於 Git refspec 的討論和使用方式會在第九章作詳細闡述。
+
+接下來，John 發郵件給 Jessica 告訴她，他看了之後作了些修改，已經推回伺服器 `featureA` 分支，請她過目下。於是 Jessica 運行 `git fetch` 下載最新資料：
+
+	$ git fetch origin
+	...
+	From jessica@githost:simplegit
+	   3300904..aad881d  featureA   -> origin/featureA
+
+接下來便可以用 `git log` 查看更新了些什麼：
+
+	$ git log origin/featureA ^featureA
+	commit aad881d154acdaeb2b6b18ea0e827ed8a6d671e6
+	Author: John Smith <jsmith@example.com>
+	Date:   Fri May 29 19:57:33 2009 -0700
+
+	    changed log output to 30 from 25
+
+最後，她將 John 的工作合併到自己的 `featureA` 分支中：
+
+	$ git checkout featureA
+	Switched to branch "featureA"
+	$ git merge origin/featureA
+	Updating 3300904..aad881d
+	Fast forward
+	 lib/simplegit.rb |   10 +++++++++-
+	1 files changed, 9 insertions(+), 1 deletions(-)
+
+Jessica 稍做一番修整後同步到伺服器：
+
+	$ git commit -am 'small tweak'
+	[featureA 774b3ed] small tweak
+	 1 files changed, 1 insertions(+), 1 deletions(-)
+	$ git push origin featureA
+	...
+	To jessica@githost:simplegit.git
+	   3300904..774b3ed  featureA -> featureA
+
+現在的 Jessica 提交歷史如圖 5-13 所示：
+
+Insert 18333fig0513.png
+圖 5-13. 在特性分支中提交更新後的提交歷史
+
+現在，Jessica，Josie 和 John 通知集成管理員伺服器上的 `featureA` 及 `featureBee` 分支已經準備好，可以併入主線了。在管理員完成集成工作後，主分支上便多出一個新的合併提交（5399e），用 fetch 命令更新到本地後，提交歷史如圖 5-14 所示：
+
+Insert 18333fig0514.png
+圖 5-14. 合併特性分支後的 Jessica 提交歷史
+
+許多開發小組改用 Git 就是因為它允許多個小組間並行工作，而在稍後恰當時機再行合併。通過共用遠端分支的方式，無需干擾整體專案代碼便可以開展工作，因此使用 Git 的小型團隊間協作可以變得非常靈活自由。以上工作流程的時序如圖 5-15 所示：
+
+Insert 18333fig0515.png
+圖 5-15. 團隊間協作工作流程基本時序
+
+### 公開的小型專案 ###
+
+上面說的是私有專案協作，但要給公開專案作貢獻，情況就有些不同了。因為你沒有直接更新主倉庫分支的許可權，得尋求其它方式把工作成果交給專案維護人。下面會介紹兩種方法，第一種使用 git 託管服務商提供的倉庫複製功能，一般稱作 fork，比如 repo.or.cz 和 GitHub 都支援這樣的操作，而且許多項目管理員都希望大家使用這樣的方式。另一種方法是通過電子郵件寄送檔補丁。
+
+但不管哪種方式，起先我們總需要克隆原始倉庫，而後創建特性分支開展工作。基本工作流程如下：
+
+	$ git clone (url)
+	$ cd project
+	$ git checkout -b featureA
+	$ (work)
+	$ git commit
+	$ (work)
+	$ git commit
+
+你可能想到用 `rebase -i` 將所有更新先變作單個提交，又或者想重新安排提交之間的差異補丁，以方便專案維護者審閱 -- 有關互動式衍合操作的細節見第六章。
+
+在完成了特性分支開發，提交給專案維護者之前，先到原始專案的頁面上點擊“Fork”按鈕，創建一個自己可寫的公共倉庫（譯注：即下面的 url 部分，參照後續的例子，應該是 `git://githost/simplegit.git`）。然後將此倉庫添加為本地的第二個遠端倉庫，姑且稱為 `myfork`：
+
+	$ git remote add myfork (url)
+
+你需要將本地更新推送到這個倉庫。要是將遠端 master 合併到本地再推回去，還不如把整個特性分支推上去來得乾脆直接。而且，假若項目維護者未採納你的貢獻的話（不管是直接合併還是 cherry pick），都不用回退（rewind）自己的 master 分支。但若維護者合併或 cherry-pick 了你的工作，最後總還可以從他們的更新中同步這些代碼。好吧，現在先把 featureA 分支整個推上去：
+
+	$ git push myfork featureA
+
+然後通知專案管理員，讓他來抓取你的代碼。通常我們把這件事叫做 pull request。可以直接用 GitHub 等網站提供的 “pull request” 按鈕自動發送請求通知；或手工把 `git request-pull` 命令輸出結果電郵給專案管理員。
+
+`request-pull` 命令接受兩個參數，第一個是本地特性分支開始前的原始分支，第二個是請求對方來抓取的 Git 倉庫 URL（譯注：即下面 `myfork` 所指的，自己可寫的公共倉庫）。比如現在Jessica 準備要給 John 發一個 pull requst，她之前在自己的特性分支上提交了兩次更新，並把分支整個推到了伺服器上，所以運行該命令會看到：
+
+	$ git request-pull origin/master myfork
+	The following changes since commit 1edee6b1d61823a2de3b09c160d7080b8d1b3a40:
+	  John Smith (1):
+	        added a new function
+
+	are available in the git repository at:
+
+	  git://githost/simplegit.git featureA
+
+	Jessica Smith (2):
+	      add limit to log function
+	      change log output to 30 from 25
+
+	 lib/simplegit.rb |   10 +++++++++-
+	 1 files changed, 9 insertions(+), 1 deletions(-)
+
+輸出的內容可以直接發郵件給管理者，他們就會明白這是從哪次提交開始旁支出去的，該到哪裡去抓取新的代碼，以及新的代碼增加了哪些功能等等。
+
+像這樣隨時保持自己的 `master` 分支和官方 `origin/master` 同步，並將自己的工作限制在特性分支上的做法，既方便又靈活，採納和丟棄都輕而易舉。就算原始主幹發生變化，我們也能重新衍合提供新的補丁。比如現在要開始第二項特性的開發，不要在原來已推送的特性分支上繼續，還是按原始 `master` 開始：
+
+	$ git checkout -b featureB origin/master
+	$ (work)
+	$ git commit
+	$ git push myfork featureB
+	$ (email maintainer)
+	$ git fetch origin
+
+現在，A、B 兩個特性分支各不相擾，如同竹筒裡的兩顆豆子，佇列中的兩個補丁，你隨時都可以分別從頭寫過，或者衍合，或者修改，而不用擔心特性代碼的交叉混雜。如圖 5-16 所示：
+
+Insert 18333fig0516.png
+圖 5-16. featureB 以後的提交歷史
+
+假設項目管理員接納了許多別人提交的補丁後，準備要採納你提交的第一個分支，卻發現因為代碼基準不一致，合併工作無法正確乾淨地完成。這就需要你再次衍合到最新的 `origin/master`，解決相關衝突，然後重新提交你的修改：
+
+	$ git checkout featureA
+	$ git rebase origin/master
+	$ git push -f myfork featureA
+
+自然，這會重寫提交歷史，如圖 5-17 所示：
+
+Insert 18333fig0517.png
+圖 5-17. featureA 重新衍合後的提交歷史
+
+注意，此時推送分支必須使用 `-f` 選項（譯注：表示 force，不作檢查強制重寫）替換遠端已有的 `featureA` 分支，因為新的 commit 並非原來的後續更新。當然你也可以直接推送到另一個新的分支上去，比如稱作 `featureAv2`。
+
+再考慮另一種情形：管理員看過第二個分支後覺得思路新穎，但想請你改下具體實現。我們只需以當前 `origin/master` 分支為基準，開始一個新的特性分支 `featureBv2`，然後把原來的 `featureB` 的更新拿過來，解決衝突，按要求重新實現部分代碼，然後將此特性分支推送上去：
+
+	$ git checkout -b featureBv2 origin/master
+	$ git merge --no-commit --squash featureB
+	$ (change implementation)
+	$ git commit
+	$ git push myfork featureBv2
+
+這裡的 `--squash` 選項將目標分支上的所有更改全拿來應用到當前分支上，而 `--no-commit` 選項告訴 Git 此時無需自動生成和記錄（合併）提交。這樣，你就可以在原來代碼基礎上，繼續工作，直到最後一起提交。
+
+好了，現在可以請管理員抓取 `featureBv2` 上的最新代碼了，如圖 5-18 所示：
+
+Insert 18333fig0518.png
+圖 5-18. featureBv2 之後的提交歷史
+
+### 公開的大型專案 ###
+
+許多大型專案都會立有一套自己的接受補丁流程，你應該注意下其中細節。但多數專案都允許通過開發者郵寄清單接受補丁，現在我們來看具體例子。
+
+整個工作流程類似上面的情形：為每個補丁創建獨立的特性分支，而不同之處在於如何提交這些補丁。不需要創建自己可寫的公共倉庫，也不用將自己的更新推送到自己的伺服器，你只需將每次提交的差異內容以電子郵件的方式依次發送到郵寄清單中即可。
+
+	$ git checkout -b topicA
+	$ (work)
+	$ git commit
+	$ (work)
+	$ git commit
+
+如此一番後，有了兩個提交要發到郵寄清單。我們可以用 `git format-patch` 命令來生成 mbox 格式的檔然後作為附件發送。每個提交都會封裝為一個 `.patch` 尾碼的 mbox 檔，但其中只包含一封郵件，郵件標題就是提交消息（譯注：額外有首碼，看例子），郵件內容包含補丁正文和 Git 版本號。這種方式的妙處在於接受補丁時仍可保留原來的提交消息，請看接下來的例子：
+
+	$ git format-patch -M origin/master
+	0001-add-limit-to-log-function.patch
+	0002-changed-log-output-to-30-from-25.patch
+
+`format-patch` 命令依次創建補丁文件，並輸出檔案名。上面的 `-M` 選項允許 Git 檢查是否有對檔重命名的提交。我們來看看補丁檔的內容：
+
+	$ cat 0001-add-limit-to-log-function.patch
+	From 330090432754092d704da8e76ca5c05c198e71a8 Mon Sep 17 00:00:00 2001
+	From: Jessica Smith <jessica@example.com>
+	Date: Sun, 6 Apr 2008 10:17:23 -0700
+	Subject: [PATCH 1/2] add limit to log function
+
+	Limit log functionality to the first 20
+
+	---
+	 lib/simplegit.rb |    2 +-
+	 1 files changed, 1 insertions(+), 1 deletions(-)
+
+	diff --git a/lib/simplegit.rb b/lib/simplegit.rb
+	index 76f47bc..f9815f1 100644
+	--- a/lib/simplegit.rb
+	+++ b/lib/simplegit.rb
+	@@ -14,7 +14,7 @@ class SimpleGit
+	   end
+
+	   def log(treeish = 'master')
+	-    command("git log #{treeish}")
+	+    command("git log -n 20 #{treeish}")
+	   end
+
+	   def ls_tree(treeish = 'master')
+	--
+	1.6.2.rc1.20.g8c5b.dirty
+
+如果有額外資訊需要補充，但又不想放在提交消息中說明，可以編輯這些補丁檔，在第一個 `---` 行之前添加說明，但不要修改下面的補丁正文，比如例子中的 `Limit log functionality to the first 20` 部分。這樣，其它開發者能閱讀，但在採納補丁時不會將此合併進來。
+
+你可以用郵件用戶端軟體發送這些補丁檔，也可以直接在命令列發送。有些所謂智慧的郵件用戶端軟體會自作主張幫你調整格式，所以粘貼補丁到郵件正文時，有可能會丟失分行符號和若干空格。Git 提供了一個通過 IMAP 發送補丁檔的工具。接下來我會演示如何通過 Gmail 的 IMAP 伺服器發送。另外，在 Git 原始程式碼中有個 `Documentation/SubmittingPatches` 檔，可以仔細讀讀，看看其它郵件程式的相關導引。
+
+首先在 `~/.gitconfig` 檔中配置 imap 項。每個選項都可用 `git config` 命令分別設置，當然直接編輯檔添加以下內容更便捷：
+
+	[imap]
+	  folder = "[Gmail]/Drafts"
+	  host = imaps://imap.gmail.com
+	  user = user@gmail.com
+	  pass = p4ssw0rd
+	  port = 993
+	  sslverify = false
+
+如果你的 IMAP 伺服器沒有啟用 SSL，就無需配置最後那兩行，並且 host 應該以 `imap://` 開頭而不再是有 `s` 的 `imaps://`。
+保存設定檔後，就能用 `git send-email` 命令把補丁作為郵件依次發送到指定的 IMAP 伺服器上的資料夾中（譯注：這裡就是 Gmail 的 `[Gmail]/Drafts` 資料夾。但如果你的語言設置不是英文，此處的資料夾 Drafts 字樣會變為對應的語言。）：
+
+	$ cat *.patch |git imap-send
+	Resolving imap.gmail.com... ok
+	Connecting to [74.125.142.109]:993... ok
+	Logging in...
+	sending 2 messages
+	100% (2/2) done
+
+At this point, you should be able to go to your Drafts folder, change the To field to the mailing list you’re sending the patch to, possibly CC the maintainer or person responsible for that section, and send it off.
+
+You can also send the patches through an SMTP server. As before, you can set each value separately with a series of `git config` commands, or you can add them manually in the sendemail section in your `~/.gitconfig` file:
+
+	[sendemail]
+	  smtpencryption = tls
+	  smtpserver = smtp.gmail.com
+	  smtpuser = user@gmail.com
+	  smtpserverport = 587
+
+After this is done, you can use `git send-email` to send your patches:
+
+	$ git send-email *.patch
+	0001-added-limit-to-log-function.patch
+	0002-changed-log-output-to-30-from-25.patch
+	Who should the emails appear to be from? [Jessica Smith <jessica@example.com>]
+	Emails will be sent from: Jessica Smith <jessica@example.com>
+	Who should the emails be sent to? jessica@example.com
+	Message-ID to be used as In-Reply-To for the first email? y
+
+接下來，Git 會根據每個補丁依次輸出類似下面的日誌：
+
+	(mbox) Adding cc: Jessica Smith <jessica@example.com> from
+	  \line 'From: Jessica Smith <jessica@example.com>'
+	OK. Log says:
+	Sendmail: /usr/sbin/sendmail -i jessica@example.com
+	From: Jessica Smith <jessica@example.com>
+	To: jessica@example.com
+	Subject: [PATCH 1/2] added limit to log function
+	Date: Sat, 30 May 2009 13:29:15 -0700
+	Message-Id: <1243715356-61726-1-git-send-email-jessica@example.com>
+	X-Mailer: git-send-email 1.6.2.rc1.20.g8c5b.dirty
+	In-Reply-To: <y>
+	References: <y>
+
+	Result: OK
+
+### 小結 ###
+
+本節主要介紹了常見 Git 專案協作的工作流程，還有一些説明處理這些工作的命令和工具。接下來我們要看看如何維護 Git 項目，並成為一個合格的項目管理員，或是集成經理。
+
+## 專案的管理 ##
+
+既然是相互協作，在貢獻代碼的同時，也免不了要維護管理自己的專案。像是怎麼處理別人用 `format-patch` 生成的補丁，或是集成遠端倉庫上某個分支上的變化等等。但無論是管理代碼倉庫，還是幫忙審核收到的補丁，都需要同貢獻者約定某種長期可持續的工作方式。
+
+### 使用特性分支進行工作 ###
+
+如果想要集成新的代碼進來，最好局限在特性分支上做。臨時的特性分支可以讓你隨意嘗試，進退自如。比如碰上無法正常工作的補丁，可以先擱在那邊，直到有時間仔細核查修復為止。創建的分支可以用相關的主題關鍵字命名，比如 `ruby_client` 或者其它類似的描述性詞語，以幫助將來回憶。Git 專案本身還時常把分支名稱分置於不同命名空間下，比如 `sc/ruby_client` 就說明這是 `sc` 這個人貢獻的。
+現在從當前主幹分支為基礎，新建臨時分支：
+
+	$ git branch sc/ruby_client master
+
+另外，如果你希望立即轉到分支上去工作，可以用 `checkout -b`：
+
+	$ git checkout -b sc/ruby_client master
+
+好了，現在已經準備妥當，可以試著將別人貢獻的代碼合併進來了。之後評估一下有沒有問題，最後再決定是不是真的要併入主幹。
+
+### 採納來自郵件的補丁 ###
+
+如果收到一個通過電郵發來的補丁，你應該先把它應用到特性分支上進行評估。有兩種應用補丁的方法：`git apply` 或者 `git am`。
+
+#### 使用 apply 命令應用補丁 ####
+
+如果收到的補丁文件是用 `git diff` 或由其它 Unix 的 `diff` 命令生成，就該用 `git apply` 命令來應用補丁。假設補丁文件存在 `/tmp/patch-ruby-client.patch`，可以這樣運行：
+
+	$ git apply /tmp/patch-ruby-client.patch
+
+這會修改當前工作目錄下的檔，效果基本與運行 `patch -p1` 打補丁一樣，但它更為嚴格，且不會出現混亂。如果是 `git diff` 格式描述的補丁，此命令還會相應地添加，刪除，重命名檔。當然，普通的 `patch` 命令是不會這麼做的。另外請注意，`git apply` 是一個事務性操作的命令，也就是說，要麼所有補丁都打上去，要麼全部放棄。所以不會出現 `patch` 命令那樣，一部分檔打上了補丁而另一部分卻沒有，這樣一種不上不下的修訂狀態。所以總的來說，`git apply` 要比 `patch` 嚴謹許多。因為僅僅是更新當前的檔，所以此命令不會自動生成提交物件，你得手工緩存相應檔的更新狀態並執行提交命令。
+
+在實際打補丁之前，可以先用 `git apply --check` 查看補丁是否能夠乾淨順利地應用到當前分支中：
+
+	$ git apply --check 0001-seeing-if-this-helps-the-gem.patch
+	error: patch failed: ticgit.gemspec:1
+	error: ticgit.gemspec: patch does not apply
+
+如果沒有任何輸出，表示我們可以順利採納該補丁。如果有問題，除了報告錯誤資訊之外，該命令還會返回一個非零的狀態，所以在 shell 腳本裡可用於檢測狀態。
+
+#### 使用 am 命令應用補丁 ####
+
+如果貢獻者也用 Git，且擅於製作 `format-patch` 補丁，那你的合併工作將會非常輕鬆。因為這些補丁中除了檔內容差異外，還包含了作者資訊和提交消息。所以請鼓勵貢獻者用 `format-patch` 生成補丁。對於傳統的 `diff` 命令生成的補丁，則只能用 `git apply` 處理。
+
+對於 `format-patch` 製作的新式補丁，應當使用 `git am` 命令。從技術上來說，`git am`  能夠讀取 mbox 格式的檔。這是種簡單的純文字檔，可以包含多封電郵，格式上用 From 加空格以及隨便什麼輔助資訊所組成的行作為分隔行，以區分每封郵件，就像這樣：
+
+	From 330090432754092d704da8e76ca5c05c198e71a8 Mon Sep 17 00:00:00 2001
+	From: Jessica Smith <jessica@example.com>
+	Date: Sun, 6 Apr 2008 10:17:23 -0700
+	Subject: [PATCH 1/2] add limit to log function
+
+	Limit log functionality to the first 20
+
+這是 `format-patch` 命令輸出的開頭幾行，也是一個有效的 mbox 檔案格式。如果有人用 `git send-email` 給你發了一個補丁，你可以將此郵件下載到本地，然後運行 `git am` 命令來應用這個補丁。如果你的郵件用戶端能將多封電郵匯出為 mbox 格式的檔，就可以用 `git am` 一次性應用所有匯出的補丁。
+
+如果貢獻者將 `format-patch` 生成的補丁檔上傳到類似 Request Ticket 一樣的任務處理系統，那麼可以先下載到本地，繼而使用 `git am` 應用該補丁：
+
+	$ git am 0001-limit-log-function.patch
+	Applying: add limit to log function
+
+你會看到它被乾淨地應用到本地分支，並自動創建了新的提交物件。作者資訊取自郵件頭 `From` 和 `Date`，提交消息則取自 `Subject` 以及正文中補丁之前的內容。來看具體實例，採納之前展示的那個 mbox 電郵補丁後，最新的提交對象為：
+
+	$ git log --pretty=fuller -1
+	commit 6c5e70b984a60b3cecd395edd5b48a7575bf58e0
+	Author:     Jessica Smith <jessica@example.com>
+	AuthorDate: Sun Apr 6 10:17:23 2008 -0700
+	Commit:     Scott Chacon <schacon@gmail.com>
+	CommitDate: Thu Apr 9 09:19:06 2009 -0700
+
+	   add limit to log function
+
+	   Limit log functionality to the first 20
+
+`Commit` 部分顯示的是採納補丁的人，以及採納的時間。而 `Author` 部分則顯示的是原作者，以及創建補丁的時間。
+
+有時，我們也會遇到打不上補丁的情況。這多半是因為主幹分支和補丁的基礎分支相差太遠，但也可能是因為某些依賴補丁還未應用。這種情況下，`git am` 會報錯並詢問該怎麼做：
+
+	$ git am 0001-seeing-if-this-helps-the-gem.patch
+	Applying: seeing if this helps the gem
+	error: patch failed: ticgit.gemspec:1
+	error: ticgit.gemspec: patch does not apply
+	Patch failed at 0001.
+	When you have resolved this problem run "git am --resolved".
+	If you would prefer to skip this patch, instead run "git am --skip".
+	To restore the original branch and stop patching run "git am --abort".
+
+Git 會在有衝突的檔裡加入衝突解決標記，這同合併或衍合操作一樣。解決的辦法也一樣，先編輯檔消除衝突，然後暫存檔，最後運行 `git am --resolved` 提交修正結果：
+
+	$ (fix the file)
+	$ git add ticgit.gemspec
+	$ git am --resolved
+	Applying: seeing if this helps the gem
+
+如果想讓 Git 更智慧地處理衝突，可以用 `-3` 選項進行三方合併。如果當前分支未包含該補丁的基礎代碼或其祖先，那麼三方合併就會失敗，所以該選項預設為關閉狀態。一般來說，如果該補丁是基於某個公開的提交製作而成的話，你總是可以通過同步來獲取這個共同祖先，所以用三方合併選項可以解決很多麻煩：
+
+	$ git am -3 0001-seeing-if-this-helps-the-gem.patch
+	Applying: seeing if this helps the gem
+	error: patch failed: ticgit.gemspec:1
+	error: ticgit.gemspec: patch does not apply
+	Using index info to reconstruct a base tree...
+	Falling back to patching base and 3-way merge...
+	No changes -- Patch already applied.
+
+像上面的例子，對於打過的補丁我又再打一遍，自然會產生衝突，但因為加上了 `-3` 選項，所以它很聰明地告訴我，無需更新，原有的補丁已經應用。
+
+對於一次應用多個補丁時所用的 mbox 格式檔，可以用 `am` 命令的交互模式選項 `-i`，這樣就會在打每個補丁前停住，詢問該如何操作：
+
+	$ git am -3 -i mbox
+	Commit Body is:
+	--------------------------
+	seeing if this helps the gem
+	--------------------------
+	Apply? [y]es/[n]o/[e]dit/[v]iew patch/[a]ccept all
+
+在多個補丁要打的情況下，這是個非常好的辦法，一方面可以預覽下補丁內容，同時也可以有選擇性的接納或跳過某些補丁。
+
+打完所有補丁後，如果測試下來新特性可以正常工作，那就可以安心地將當前特性分支合併到長期分支中去了。
+
+### 檢出遠端分支 ###
+
+如果貢獻者有自己的 Git 倉庫，並將修改推送到此倉庫中，那麼當你拿到倉庫的訪問位址和對應分支的名稱後，就可以加為遠端分支，然後在本地進行合併。
+
+比如，Jessica 發來一封郵件，說在她代碼庫中的 `ruby-client` 分支上已經實現了某個非常棒的新功能，希望我們能幫忙測試一下。我們可以先把她的倉庫加為遠端倉庫，然後抓取資料，完了再將她所說的分支檢出到本地來測試：
+
+	$ git remote add jessica git://github.com/jessica/myproject.git
+	$ git fetch jessica
+	$ git checkout -b rubyclient jessica/ruby-client
+
+若是不久她又發來郵件，說還有個很棒的功能實現在另一分支上，那我們只需重新抓取下最新資料，然後檢出那個分支到本地就可以了，無需重複設置遠端倉庫。
+
+這種做法便於同別人保持長期的合作關係。但前提是要求貢獻者有自己的伺服器，而我們也需要為每個人建一個遠端分支。有些貢獻者提交代碼補丁並不是很頻繁，所以通過郵件接收補丁效率會更高。同時我們自己也不會希望建上百來個分支，卻只從每個分支取一兩個補丁。但若是用腳本程式來管理，或直接使用代碼倉庫託管服務，就可以簡化此過程。當然，選擇何種方式取決於你和貢獻者的喜好。
+
+使用遠端分支的另外一個好處是能夠得到提交歷史。不管代碼合併是不是會有問題，至少我們知道該分支的歷史分叉點，所以默認會從共同祖先開始自動進行三方合併，無需 `-3` 選項，也不用像打補丁那樣祈禱存在共同的基準點。
+
+如果只是臨時合作，只需用 `git pull` 命令抓取遠端倉庫上的資料，合併到本地臨時分支就可以了。一次性的抓取動作自然不會把該倉庫位址加為遠程倉庫。
+
+	$ git pull git://github.com/onetimeguy/project.git
+	From git://github.com/onetimeguy/project
+	 * branch            HEAD       -> FETCH_HEAD
+	Merge made by recursive.
+
+### 決斷代碼取捨 ###
+
+現在特性分支上已合併好了貢獻者的代碼，是時候決斷取捨了。本節將回顧一些之前學過的命令，以看清將要合併到主幹的是哪些代碼，從而理解它們到底做了些什麼，是否真的要併入。
+
+一般我們會先看下，特性分支上都有哪些新增的提交。比如在 `contrib` 特性分支上打了兩個補丁，僅查看這兩個補丁的提交資訊，可以用 `--not` 選項指定要遮罩的分支 `master`，這樣就會剔除重複的提交歷史：
+
+	$ git log contrib --not master
+	commit 5b6235bd297351589efc4d73316f0a68d484f118
+	Author: Scott Chacon <schacon@gmail.com>
+	Date:   Fri Oct 24 09:53:59 2008 -0700
+
+	    seeing if this helps the gem
+
+	commit 7482e0d16d04bea79d0dba8988cc78df655f16a0
+	Author: Scott Chacon <schacon@gmail.com>
+	Date:   Mon Oct 22 19:38:36 2008 -0700
+
+	    updated the gemspec to hopefully work better
+
+還可以查看每次提交的具體修改。請牢記，在 `git log` 後加 `-p` 選項將展示每次提交的內容差異。
+
+如果想看當前分支同其他分支合併時的完整內容差異，有個小竅門：
+
+	$ git diff master
+
+雖然能得到差異內容，但請記住，結果有可能和我們的預期不同。一旦主幹 `master` 在特性分支創建之後有所修改，那麼通過 `diff` 命令來比較的，是最新主幹上的提交快照。顯然，這不是我們所要的。比方在 `master` 分支中某個檔裡添了一行，然後運行上面的命令，簡單的比較最新快照所得到的結論只能是，特性分支中刪除了這一行。
+
+這個很好理解：如果 `master` 是特性分支的直接祖先，不會產生任何問題；如果它們的提交歷史在不同的分叉上，那麼產生的內容差異，看起來就像是增加了特性分支上的新代碼，同時刪除了 `master` 分支上的新代碼。
+
+實際上我們真正想要看的，是新加入到特性分支的代碼，也就是合併時會併入主幹的代碼。所以，準確地講，我們應該比較特性分支和它同 `master` 分支的共同祖先之間的差異。
+
+我們可以手工定位它們的共同祖先，然後與之比較：
+
+	$ git merge-base contrib master
+	36c7dba2c95e6bbb78dfa822519ecfec6e1ca649
+	$ git diff 36c7db
+
+但這麼做很麻煩，所以 Git 提供了便捷的 `...` 語法。對於 `diff` 命令，可以把 `...` 加在原始分支（擁有共同祖先）和當前分支之間：
+
+	$ git diff master...contrib
+
+現在看到的，就是實際將要引入的新代碼。這是一個非常有用的命令，應該牢記。
+
+### 代碼集成 ###
+
+一旦特性分支準備停當，接下來的問題就是如何集成到更靠近主線的分支中。此外還要考慮維護專案的總體步驟是什麼。雖然有很多選擇，不過我們這裡只介紹其中一部分。
+
+#### 合併流程 ####
+
+一般最簡單的情形，是在 `master` 分支中維護穩定代碼，然後在特性分支上開發新功能，或是審核測試別人貢獻的代碼，接著將它併入主幹，最後刪除這個特性分支，如此反復。來看示例，假設當前代碼庫中有兩個分支，分別為 `ruby_client` 和 `php_client`，如圖 5-19 所示。然後先把 `ruby_client` 合併進主幹，再合併 `php_client`，最後的提交歷史如圖 5-20 所示。
+
+Insert 18333fig0519.png
+圖 5-19. 多個特性分支
+
+Insert 18333fig0520.png
+圖 5-20. 合併特性分支之後
+
+這是最簡單的流程，所以在處理大一些的項目時可能會有問題。
+
+對於大型專案，至少需要維護兩個長期分支 `master` 和 `develop`。新代碼（圖 5-21 中的 `ruby_client`）將首先併入 `develop` 分支（圖 5-22 中的 `C8`），經過一個階段，確認 `develop` 中的代碼已穩定到可發行時，再將 `master` 分支快進到穩定點（圖 5-23 中的 `C8`）。而平時這兩個分支都會被推送到公開的代碼庫。
+
+Insert 18333fig0521.png
+圖 5-21. 特性分支合併前
+
+Insert 18333fig0522.png
+圖 5-22. 特性分支合併後
+
+Insert 18333fig0523.png
+圖 5-23. 特性分支發佈後
+
+這樣，在人們克隆倉庫時就有兩種選擇：既可檢出最新穩定版本，確保正常使用；也能檢出開發版本，試用最前沿的新特性。
+你也可以擴展這個概念，先將所有新代碼合併到臨時特性分支，等到該分支穩定下來並通過測試後，再併入 `develop` 分支。然後，讓時間檢驗一切，如果這些代碼確實可以正常工作相當長一段時間，那就有理由相信它已經足夠穩定，可以放心併入主幹分支發佈。
+
+#### 大專案的合併流程 ####
+
+Git 專案本身有四個長期分支：用於發佈的 `master` 分支、用於合併基本穩定特性的 `next` 分支、用於合併仍需改進特性的 `pu` 分支（pu 是 proposed updates 的縮寫），以及用於除錯維護的 `maint` 分支（maint 取自 maintenance）。維護者可以按照之前介紹的方法，將貢獻者的代碼引入為不同的特性分支（如圖 5-24 所示），然後測試評估，看哪些特性能穩定工作，哪些還需改進。穩定的特性可以併入 `next` 分支，然後再推送到公共倉庫，以供其他人試用。
+
+Insert 18333fig0524.png
+圖 5-24. 管理複雜的並行貢獻
+
+仍需改進的特性可以先併入 `pu` 分支。直到它們完全穩定後再併入 `master`。同時一併檢查下 `next` 分支，將足夠穩定的特性也併入 `master`。所以一般來說，`master` 始終是在快進，`next` 偶爾做下衍合，而 `pu` 則是頻繁衍合，如圖 5-25 所示：
+
+Insert 18333fig0525.png
+圖 5-25. 將特性併入長期分支
+
+併入 `master` 後的特性分支，已經無需保留分支索引，放心刪除好了。Git 專案還有一個 `maint` 分支，它是以最近一次發行版本為基礎分化而來的，用於維護除錯補丁。所以克隆 Git 項目倉庫後會得到這四個分支，通過檢出不同分支可以瞭解各自進展，或是試用前沿特性，或是貢獻代碼。而維護者則通過管理這些分支，逐步有序地併入協力廠商貢獻。
+
+#### 衍合與挑揀（cherry-pick）的流程 ####
+
+一些維護者更喜歡衍合或者挑揀貢獻者的代碼，而不是簡單的合併，因為這樣能夠保持線性的提交歷史。如果你完成了一個特性的開發，並決定將它引入到主幹代碼中，你可以轉到那個特性分支然後執行衍合命令，好在你的主幹分支上（也可能是`develop`分支之類的）重新提交這些修改。如果這些代碼工作得很好，你就可以快進`master`分支，得到一個線性的提交歷史。
+
+另一個引入代碼的方法是挑揀。挑揀類似於針對某次特定提交的衍合。它首先提取某次提交的補丁，然後試著應用在當前分支上。如果某個特性分支上有多個commits，但你只想引入其中之一就可以使用這種方法。也可能僅僅是因為你喜歡用挑揀，討厭衍合。假設你有一個類似圖 5-26 的工程。
+
+Insert 18333fig0526.png
+圖 5-26. 挑揀（cherry-pick）之前的歷史 
+
+如果你希望拉取`e43a6`到你的主幹分支，可以這樣：
+
+	$ git cherry-pick e43a6fd3e94888d76779ad79fb568ed180e5fcdf
+	Finished one cherry-pick.
+	[master]: created a0a41a9: "More friendly message when locking the index fails."
+	 3 files changed, 17 insertions(+), 3 deletions(-)
+
+這將會引入`e43a6`的代碼，但是會得到不同的SHA-1值，因為應用日期不同。現在你的歷史看起來像圖 5-27.
+
+Insert 18333fig0527.png
+圖 5-27. 挑揀（cherry-pick）之後的歷史
+
+現在，你可以刪除這個特性分支並丟棄你不想引入的那些commit。
+
+### 給發行版本簽名  ###
+
+你可以刪除上次發佈的版本並重新打標籤，也可以像第二章所說的那樣建立一個新的標籤。如果你決定以維護者的身份給發行版本簽名，應該這樣做：
+
+	$ git tag -s v1.5 -m 'my signed 1.5 tag'
+	You need a passphrase to unlock the secret key for
+	user: "Scott Chacon <schacon@gmail.com>"
+	1024-bit DSA key, ID F721C45A, created 2009-02-09
+
+完成簽名之後，如何分發PGP公開金鑰（public key）是個問題。（譯者注：分發公開金鑰是為了驗證標籤）。還好，Git的設計者想到了解決辦法：可以把key（既公開金鑰）作為blob變數寫入Git庫，然後把它的內容直接寫在標籤裡。`gpg --list-keys`命令可以顯示出你所擁有的key：
+
+	$ gpg --list-keys
+	/Users/schacon/.gnupg/pubring.gpg
+	---------------------------------
+	pub   1024D/F721C45A 2009-02-09 [expires: 2010-02-09]
+	uid                  Scott Chacon <schacon@gmail.com>
+	sub   2048g/45D02282 2009-02-09 [expires: 2010-02-09]
+
+然後，匯出key的內容並經由管道符傳遞給`git hash-object`，之後鑰匙會以blob類型寫入Git中，最後返回這個blob量的SHA-1值：
+
+	$ gpg -a --export F721C45A | git hash-object -w --stdin
+	659ef797d181633c87ec71ac3f9ba29fe5775b92
+
+現在你的Git已經包含了這個key的內容了，可以通過不同的SHA-1值指定不同的key來創建標籤。
+
+	$ git tag -a maintainer-pgp-pub 659ef797d181633c87ec71ac3f9ba29fe5775b92
+
+在運行`git push --tags`命令之後，`maintainer-pgp-pub`標籤就會公佈給所有人。如果有人想要校驗標籤，他可以使用如下命令導入你的key：
+
+	$ git show maintainer-pgp-pub | gpg --import
+
+人們可以用這個key校驗你簽名的所有標籤。另外，你也可以在標籤資訊裡寫入一個操作嚮導，用戶只需要運行`git show <tag>`查看標籤資訊，然後按照你的嚮導就能完成校驗。
+
+### 生成內部版本號 ###
+
+因為Git不會為每次提交自動附加類似'v123'的遞增序列，所以如果你想要得到一個便於理解的提交號可以運行`git describe`命令。Git將會返回一個字串，由三部分組成：最近一次標定的版本號，加上自那次標定之後的提交次數，再加上一段所描述的提交的SHA-1值：
+
+	$ git describe master
+	v1.6.2-rc1-20-g8c5b85c
+
+這個字串可以作為快照的名字，方便人們理解。如果你的Git是你自己下載源碼然後編譯安裝的，你會發現`git --version`命令的輸出和這個字串差不多。如果在一個剛剛打完標籤的提交上運行`describe`命令，只會得到這次標定的版本號，而沒有後面兩項資訊。
+
+`git describe`命令只適用於有標注的標籤（通過`-a`或者`-s`選項創建的標籤），所以發行版本的標籤都應該是帶有標注的，以保證`git describe`能夠正確的執行。你也可以把這個字串作為`checkout`或者`show`命令的目標，因為他們最終都依賴於一個簡短的SHA-1值，當然如果這個SHA-1值失效他們也跟著失效。最近Linux內核為了保證SHA-1值的唯一性，將位數由8位擴展到10位，這就導致擴展之前的`git describe`輸出完全失效了。
+
+### 準備發佈 ###
+
+現在可以發佈一個新的版本了。首先要將代碼的壓縮包歸檔，方便那些可憐的還沒有使用Git的人們。可以使用`git archive`：
+
+	$ git archive master --prefix='project/' | gzip > `git describe master`.tar.gz
+	$ ls *.tar.gz
+	v1.6.2-rc1-20-g8c5b85c.tar.gz
+
+這個壓縮包解壓出來的是一個資料夾，裡面是你項目的最新代碼快照。你也可以用類似的方法建立一個zip壓縮包，在`git archive`加上`--format=zip`選項：
+
+	$ git archive master --prefix='project/' --format=zip > `git describe master`.zip
+
+現在你有了一個tar.gz壓縮包和一個zip壓縮包，可以把他們上傳到你網站上或者用e-mail發給別人。
+
+### 製作簡報 ###
+
+是時候通知郵寄清單裡的朋友們來檢驗你的成果了。使用`git shortlog`命令可以方便快捷的製作一份修改日誌（changelog），告訴大家上次發佈之後又增加了哪些特性和修復了哪些bug。實際上這個命令能夠統計給定範圍內的所有提交;假如你上一次發佈的版本是v1.0.1，下面的命令將給出自從上次發佈之後的所有提交的簡介：
+
+	$ git shortlog --no-merges master --not v1.0.1
+	Chris Wanstrath (8):
+	      Add support for annotated tags to Grit::Tag
+	      Add packed-refs annotated tag support.
+	      Add Grit::Commit#to_patch
+	      Update version and History.txt
+	      Remove stray `puts`
+	      Make ls_tree ignore nils
+
+	Tom Preston-Werner (4):
+	      fix dates in history
+	      dynamic version method
+	      Version bump to 1.0.2
+	      Regenerated gemspec for version 1.0.2
+
+這就是自從v1.0.1版本以來的所有提交的簡介，內容按照作者分組，以便你能快速的發e-mail給他們。
+
+## 小結 ##
+
+你學會了如何使用Git為專案做貢獻，也學會了如何使用Git維護你的專案。恭喜！你已經成為一名高效的開發者。在下一章你將學到更強大的工具來處理更加複雜的問題，之後你會變成一位Git大師。

From ce8bf18882aca9f036d22a35fb2ab45fef1ce95f Mon Sep 17 00:00:00 2001
From: HaWay <haway.tw@gmail.com>
Date: Fri, 14 Mar 2014 23:36:38 +0800
Subject: [PATCH 261/690] Update 01-chapter2.markdown

Update line 503 and 522
---
 zh-tw/02-git-basics/01-chapter2.markdown | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/zh-tw/02-git-basics/01-chapter2.markdown b/zh-tw/02-git-basics/01-chapter2.markdown
index adb1f177c..467ec27f8 100644
--- a/zh-tw/02-git-basics/01-chapter2.markdown
+++ b/zh-tw/02-git-basics/01-chapter2.markdown
@@ -500,7 +500,7 @@ Git會在背後判斷檔案是否被更名，因此不管是用上述方法還
 
 這個選項除了顯示相同的資訊外，還另外附上每個更新的差異。 這對於重新檢視或者快速的瀏覽協同工作伙伴新增的更新非常有幫助。
 
-Sometimes it's easier to review changes on the word level rather than on the line level. There is a `--word-diff` option available in Git, that you can append to the `git log -p` command to get word diff instead of normal line by line diff. Word diff format is quite useless when applied to source code, but it comes in handy when applied to large text files, like books or your dissertation. Here is an example:
+有時候用 word level 的方式比 line level 更容易看懂變化。在 `git log -p` 後面附加 `--word-diff` 選項，就可以取代預設的  line level 模式。當你在看原始碼的時候 word level 還挺有用的，還有一些大型文字檔，如書籍或論文就派上用場了，範例如下：
 
 	$ git log -U1 --word-diff
 	commit ca82a6dff817ec66f44342007202690a93763949
@@ -518,7 +518,7 @@ Sometimes it's easier to review changes on the word level rather than on the lin
 	    s.version   =   [-"0.1.0"-]{+"0.1.1"+}
 	    s.author    =   "Scott Chacon"
 
-As you can see, there is no added and removed lines in this output as in a normal diff. Changes are shown inline instead. You can see the added word enclosed in `{+ +}` and removed one enclosed in `[- -]`. You may also want to reduce the usual three lines context in diff output to only one line, as the context is now words, not lines. You can do this with `-U1` as we did in the example above.
+如你所見，輸出範例中沒有列出新增與刪除的行，變動的地方用內嵌的方式顯示，你可以看到新增的字被包括在 `{+ +}` 內，而刪除的則包括在 `{- -}` 內，如果你想再減少顯示的資訊，將上述的三行再減少到只顯示變動的那行。你可以用 `-U1` 選項，就像上述的範例中那樣。
 
 另外也可以使用`git log`提供的一系統摘要選項。 例如：若想檢視每個更新的簡略統計資訊，可使用 `--stat` 選項：
 

From 29a614e3b4391cbec5d11c7ac4a78e6dcdcb1f73 Mon Sep 17 00:00:00 2001
From: fusionBin <iahu1988@gmail.com>
Date: Sat, 15 Mar 2014 22:24:04 +0800
Subject: [PATCH 262/690] Update 01-chapter1.markdown
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

修改错误拼写 Frenode -> Freenode
---
 zh/01-introduction/01-chapter1.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/zh/01-introduction/01-chapter1.markdown b/zh/01-introduction/01-chapter1.markdown
index 3219ccaf2..84f89e070 100644
--- a/zh/01-introduction/01-chapter1.markdown
+++ b/zh/01-introduction/01-chapter1.markdown
@@ -252,7 +252,7 @@ Git 可以理解 kdiff3，tkdiff，meld，xxdiff，emerge，vimdiff，gvimdiff
 	$ git help config
 
 我们随时都可以浏览这些帮助信息而无需连网。
-不过，要是你觉得还不够，可以到 Frenode IRC 服务器（irc.freenode.net）上的 `#git` 或 `#github` 频道寻求他人帮助。这两个频道上总有着上百号人，大多都有着丰富的 git 知识，并且乐于助人。
+不过，要是你觉得还不够，可以到 Freenode IRC 服务器（irc.freenode.net）上的 `#git` 或 `#github` 频道寻求他人帮助。这两个频道上总有着上百号人，大多都有着丰富的 git 知识，并且乐于助人。
 
 ## 小结 ##
 

From acd8d48023cef0ad527f0c7ecb3637b16bb322de Mon Sep 17 00:00:00 2001
From: fuzhli <fuzhli1007@gmail.com>
Date: Wed, 19 Mar 2014 18:40:09 +0800
Subject: [PATCH 263/690] Update 01-chapter9.markdown

correct the type mistake in the last line of section9.3
---
 zh/09-git-internals/01-chapter9.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/zh/09-git-internals/01-chapter9.markdown b/zh/09-git-internals/01-chapter9.markdown
index e112727ef..9a5a15e53 100644
--- a/zh/09-git-internals/01-chapter9.markdown
+++ b/zh/09-git-internals/01-chapter9.markdown
@@ -412,7 +412,7 @@ Insert 18333fig0904.png
 	$ cat .git/refs/remotes/origin/master
 	ca82a6dff817ec66f44342007202690a93763949
 
-Remote 应用和分支主要区别在于他们是不能被 check out 的。Git 把他们当作是标记这些了这些分支在服务器上最后状态的一种书签。
+Remote 引用和分支主要区别在于他们是不能被 check out 的。Git 把他们当作是标记了这些分支在服务器上最后状态的一种书签。
 
 ## Packfiles ##
 

From 6455d36bc30d4ae153f08dd2a90c047ab08a1842 Mon Sep 17 00:00:00 2001
From: Yena Hong <yongmin@revi.pe.kr>
Date: Sat, 22 Mar 2014 18:28:42 +0900
Subject: [PATCH 264/690] Update README

Fix typo.
---
 ko/README | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ko/README b/ko/README
index d625b729e..2d1c723c0 100644
--- a/ko/README
+++ b/ko/README
@@ -1,7 +1,7 @@
 Pro Git 책의 내용
 =====================
 
-이 저장소는 Pro Git의 source code이고 라이센스는 Creative Commons Attribution-Non Commercial-Share Alike 3.0를 따름니다. 필자는 여러분이 즐겁게 git을 배웠으면 좋겠습니다. 만약 Amazon에서 책을 구입해주신다면 저와 Apress는 깊은 감사를 드릴 것입니다:
+이 저장소는 Pro Git의 source code이고 라이센스는 Creative Commons Attribution-Non Commercial-Share Alike 3.0를 따릅니다. 필자는 여러분이 즐겁게 git을 배웠으면 좋겠습니다. 만약 Amazon에서 책을 구입해주신다면 저와 Apress는 깊은 감사를 드릴 것입니다:
 
 http://tinyurl.com/amazonprogit
 

From a335b61402bc3d5a13b8615258a8478b593e483a Mon Sep 17 00:00:00 2001
From: Changwoo Park <pismute@gmail.com>
Date: Thu, 27 Mar 2014 05:52:25 +0900
Subject: [PATCH 265/690] [ko] remove a slang.

---
 ko/04-git-server/01-chapter4.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ko/04-git-server/01-chapter4.markdown b/ko/04-git-server/01-chapter4.markdown
index 9917fd92b..1f57aa7b7 100644
--- a/ko/04-git-server/01-chapter4.markdown
+++ b/ko/04-git-server/01-chapter4.markdown
@@ -16,7 +16,7 @@ HTTP 프로토콜을 제외한 나머지들은 모두 Git이 서버에 설치돼
 
 ### 로컬 프로토콜 ###
 
-가장 기본적인 것이 _로컬 프로토콜_ 이다. 리모트 저장소가 단순히 디스크의 다른 디렉토리에 있을 때 사용한다. 팀원들이 전부 한 시스템에 로그인하여 개발하거나 아니면 NFS같은 것으로 파일시스템을 공유하고 있을 때 사용한다. 전자는 문제가 될 수 있다. 모든 저장소가 한 시스템에 있기 때문에 한순간에 찌질해질 수 있다.
+가장 기본적인 것이 _로컬 프로토콜_ 이다. 리모트 저장소가 단순히 디스크의 다른 디렉토리에 있을 때 사용한다. 팀원들이 전부 한 시스템에 로그인하여 개발하거나 아니면 NFS같은 것으로 파일시스템을 공유하고 있을 때 사용한다. 전자는 문제가 될 수 있다. 모든 저장소가 한 시스템에 있기 때문에 한순간에 모두 잃을 수 있다.
 
 공유 파일시스템을 마운트했을 때는 로컬 저장소를 사용하는 것처럼 Clone하고 Push하고 Pull하면 된다. 일단 저장소를 Clone하거나 프로젝트에 리모트 저장소로 추가한다. 추가할 때 URL 자리에 저장소의 경로를 사용한다. 예를 들어 아래와 같이 로컬 저장소를 Clone한다:
 

From 4718f1fd286cb2b2fb912b3312729822ef8c7af7 Mon Sep 17 00:00:00 2001
From: Nishant Shreshth <nishantshreshth@gmail.com>
Date: Thu, 27 Mar 2014 03:32:35 +0530
Subject: [PATCH 266/690] Added placeholder and first chapter (only Getting
 Started) for Hindi (hi) translation of the book.

---
 hi/01-introduction/01-chapter1.markdown | 3 +++
 1 file changed, 3 insertions(+)
 create mode 100644 hi/01-introduction/01-chapter1.markdown

diff --git a/hi/01-introduction/01-chapter1.markdown b/hi/01-introduction/01-chapter1.markdown
new file mode 100644
index 000000000..aa1556d9f
--- /dev/null
+++ b/hi/01-introduction/01-chapter1.markdown
@@ -0,0 +1,3 @@
+# शुरुआत #
+
+यह अध्याय गिट के साथ कैसे शुरुआत की जाए की व्याख्या करेगा। सर्वप्रथम हम संस्करण नियंत्रण (version कंट्रोल) के साधनों की पृष्ठभूमि पे एक नज़र डालेंगे, इसके बाद गिट को कैसे किसी सिस्टम में इंस्टॉल करना है ये बताया जायेगा और फिर कैसे सेटअप पूरा कर इसके साथ काम करना है बताया जाएगा। इस अध्याय के आखिरी हिस्से से स्पष्टीकरण मिलेगा कि गिट क्यों बनाया गया और आपको इसका इस्तेमाल क्यों करना चाहिए, जिसके समर्थ आप तब तक हो चुके होंगे।
\ No newline at end of file

From 11ba1f5eadd718022af8dac37ccce6bf10a454e9 Mon Sep 17 00:00:00 2001
From: Nishant Shreshth <nishantshreshth@gmail.com>
Date: Thu, 27 Mar 2014 03:56:37 +0530
Subject: [PATCH 267/690] Added a paragraph in chapter 1.

---
 hi/01-introduction/01-chapter1.markdown | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/hi/01-introduction/01-chapter1.markdown b/hi/01-introduction/01-chapter1.markdown
index aa1556d9f..9655cbc90 100644
--- a/hi/01-introduction/01-chapter1.markdown
+++ b/hi/01-introduction/01-chapter1.markdown
@@ -1,3 +1,7 @@
 # शुरुआत #
 
-यह अध्याय गिट के साथ कैसे शुरुआत की जाए की व्याख्या करेगा। सर्वप्रथम हम संस्करण नियंत्रण (version कंट्रोल) के साधनों की पृष्ठभूमि पे एक नज़र डालेंगे, इसके बाद गिट को कैसे किसी सिस्टम में इंस्टॉल करना है ये बताया जायेगा और फिर कैसे सेटअप पूरा कर इसके साथ काम करना है बताया जाएगा। इस अध्याय के आखिरी हिस्से से स्पष्टीकरण मिलेगा कि गिट क्यों बनाया गया और आपको इसका इस्तेमाल क्यों करना चाहिए, जिसके समर्थ आप तब तक हो चुके होंगे।
\ No newline at end of file
+यह अध्याय गिट के साथ कैसे शुरुआत की जाए की व्याख्या करेगा। सर्वप्रथम हम संस्करण नियंत्रण (version कंट्रोल) के साधनों की पृष्ठभूमि पे एक नज़र डालेंगे, इसके बाद गिट को कैसे किसी सिस्टम में इंस्टॉल करना है ये बताया जायेगा और फिर कैसे सेटअप पूरा कर इसके साथ काम करना है बताया जाएगा। इस अध्याय के आखिरी हिस्से से स्पष्टीकरण मिलेगा कि गिट क्यों बनाया गया और आपको इसका इस्तेमाल क्यों करना चाहिए, जिसके समर्थ आप तब तक हो चुके होंगे।
+
+## संस्करण नियंत्रण ##
+
+संस्करण नियंत्रण (version control) क्या है और इसके बारे में पता होना किसलिए मददगार है? संस्करण नियंत्रण (version control) एक पद्धति है जो समय के साथ किसी फ़ाइल या फ़ाइल समूह में होने वाले परिवर्तनों को याद रखती है जिसका प्रयोग करके आप उनकी किसी पूर्ण अवस्था का बाद में परीक्षण कर सकते हैं। यद्यपि इस पुस्तक के उदाहरण सॉफ्टवेयर फाइल्स का प्रयोग करके संस्करण नियंत्रण का प्रदर्शन करते हैं, वास्तविकता में किसी भी प्रकार की फ़ाइल ऐसे सिस्टम में रखी जा सकती है।

From 2d2380e3a9c8b6e43d4865b0f87b49bef5634152 Mon Sep 17 00:00:00 2001
From: Nishant Shreshth <nishantshreshth@gmail.com>
Date: Thu, 27 Mar 2014 04:02:13 +0530
Subject: [PATCH 268/690] Use English "control".

---
 hi/01-introduction/01-chapter1.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hi/01-introduction/01-chapter1.markdown b/hi/01-introduction/01-chapter1.markdown
index 9655cbc90..1c3a27f67 100644
--- a/hi/01-introduction/01-chapter1.markdown
+++ b/hi/01-introduction/01-chapter1.markdown
@@ -1,6 +1,6 @@
 # शुरुआत #
 
-यह अध्याय गिट के साथ कैसे शुरुआत की जाए की व्याख्या करेगा। सर्वप्रथम हम संस्करण नियंत्रण (version कंट्रोल) के साधनों की पृष्ठभूमि पे एक नज़र डालेंगे, इसके बाद गिट को कैसे किसी सिस्टम में इंस्टॉल करना है ये बताया जायेगा और फिर कैसे सेटअप पूरा कर इसके साथ काम करना है बताया जाएगा। इस अध्याय के आखिरी हिस्से से स्पष्टीकरण मिलेगा कि गिट क्यों बनाया गया और आपको इसका इस्तेमाल क्यों करना चाहिए, जिसके समर्थ आप तब तक हो चुके होंगे।
+यह अध्याय गिट के साथ कैसे शुरुआत की जाए की व्याख्या करेगा। सर्वप्रथम हम संस्करण नियंत्रण (version control) के साधनों की पृष्ठभूमि पे एक नज़र डालेंगे, इसके बाद गिट को कैसे किसी सिस्टम में इंस्टॉल करना है ये बताया जायेगा और फिर कैसे सेटअप पूरा कर इसके साथ काम करना है बताया जाएगा। इस अध्याय के आखिरी हिस्से से स्पष्टीकरण मिलेगा कि गिट क्यों बनाया गया और आपको इसका इस्तेमाल क्यों करना चाहिए, जिसके समर्थ आप तब तक हो चुके होंगे।
 
 ## संस्करण नियंत्रण ##
 

From d422a821291407e8a55cdd271ede21489bb1c795 Mon Sep 17 00:00:00 2001
From: Junle Li <lijunle@gmail.com>
Date: Sun, 30 Mar 2014 14:26:33 +0800
Subject: [PATCH 269/690] Fix typo 'ful' to 'full'

---
 zh/09-git-internals/01-chapter9.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/zh/09-git-internals/01-chapter9.markdown b/zh/09-git-internals/01-chapter9.markdown
index 9a5a15e53..d77f577bc 100644
--- a/zh/09-git-internals/01-chapter9.markdown
+++ b/zh/09-git-internals/01-chapter9.markdown
@@ -859,7 +859,7 @@ Git 会不定时地自动运行称为 "auto gc" 的命令。大部分情况下
 	$ git branch -D recover-branch
 	$ rm -Rf .git/logs/
 
-因为 reflog 数据是保存在 `.git/logs/` 目录下的，这样就没有 reflog 了。现在要怎样恢复 commit 呢？办法之一是使用 `git fsck` 工具，该工具会检查仓库的数据完整性。如果指定 `--ful` 选项，该命令显示所有未被其他对象引用 (指向) 的所有对象：
+因为 reflog 数据是保存在 `.git/logs/` 目录下的，这样就没有 reflog 了。现在要怎样恢复 commit 呢？办法之一是使用 `git fsck` 工具，该工具会检查仓库的数据完整性。如果指定 `--full` 选项，该命令显示所有未被其他对象引用 (指向) 的所有对象：
 
 	$ git fsck --full
 	dangling blob d670460b4b4aece5915caf5c68d12f560a9fe3e4

From 1b62be82cb19bfa74e1450e788bd0992435c7ad5 Mon Sep 17 00:00:00 2001
From: Junle Li <lijunle@gmail.com>
Date: Tue, 1 Apr 2014 01:04:54 +0800
Subject: [PATCH 270/690] [zh] Update chapter 1. Translate one paragraph to
 Chinese.

---
 zh/01-introduction/01-chapter1.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/zh/01-introduction/01-chapter1.markdown b/zh/01-introduction/01-chapter1.markdown
index 84f89e070..fb33d4518 100644
--- a/zh/01-introduction/01-chapter1.markdown
+++ b/zh/01-introduction/01-chapter1.markdown
@@ -182,7 +182,7 @@ Insert 18333fig0107.png
 
 完成安装之后，就可以使用命令行的 `git` 工具（已经自带了 ssh 客户端）了，另外还有一个图形界面的 Git 项目管理工具。
 
-Note on Windows usage: you should use Git with the provided msysGit shell (Unix style), it allows to use the complex lines of command given in this book. If you need, for some reason, to use the native Windows shell / command line console, you have to use double quotes instead of simple quotes (for parameters with spaces in them) and you must quote the parameters ending with the circumflex accent (^) if they are last on the line, as it is a continuation symbol in Windows.
+给 Windows 用户的敬告：你应该在 msysGit 提供的 Unix 风格的 shell 来运行 Git。在 Unix 风格的 shell 中，可以使用本书中提及的复杂多行的命令。对于那些需要在 Windows 命令行中使用 Git 的用户，必须注意：在参数中间有空格的时候，必须使用双引号将参数括起来（在 Linux 中是单引号）；另外，如果扬抑符（^）作为参数的结尾，并且作为这一行的最后一个字符，则这个参数也需要用双引号括起来。因为扬抑符在 Windows 命令行中表示续行（译注：即下一行为这一行命令的继续）。
 
 ## 初次运行 Git 前的配置 ##
 

From 45f2a22f3333c5c10fedaf1e10e6720102f0b23b Mon Sep 17 00:00:00 2001
From: Bert IJff <engbert@users.noreply.github.com>
Date: Wed, 2 Apr 2014 13:29:52 +0200
Subject: [PATCH 271/690] Update 01-chapter1.markdown

diverse typo's gecorrigeerd
---
 nl/01-introduction/01-chapter1.markdown | 26 ++++++++++++-------------
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/nl/01-introduction/01-chapter1.markdown b/nl/01-introduction/01-chapter1.markdown
index 117d556b0..335bdd45e 100644
--- a/nl/01-introduction/01-chapter1.markdown
+++ b/nl/01-introduction/01-chapter1.markdown
@@ -1,7 +1,7 @@
 <!-- Attentie heren en dames vertalers.
 Ik zou het volgende willen voorstellen:
 Er zijn bepaalde termen die voor de gemiddelde Nederlandse computer gebruiker 
-veel beter klinken (of bekender voorkomen) als de orginele Engelse term. In het
+veel beter klinken (of bekender voorkomen) dan de orginele Engelse term. In het
 begin zullen deze termen niet vaak voorkomen, maar in de meer diepgaandere 
 hoofdstukken komen deze steeds meer voor. Termen als "Committen", "Mergen" 
 en "Applyen" klinken beter dan "Plegen" of "Toepassen", "Samenvoegen" en 
@@ -42,7 +42,7 @@ In dit hoofdstuk wordt uitgelegd hoe je aan de slag kunt gaan met Git. We zullen
 
 Wat is versiebeheer, en wat heeft dat met jou te maken? Versiebeheer is het systeem waarbij veranderingen in een bestand of groep van bestanden over de tijd wordt bijgehouden, zodat je later specifieke versies kan opvragen. In de voorbeelden in dit boek is het broncode van computersoftware waarvan de versies beheerd worden maar in principe kan elk soort bestand op een computer aan versiebeheer worden onderworpen.
 
-Als je een grafisch ontwerper bent of websites ontwerpt en elke versie van een afbeelding of opmaak wilt bewaren (wat je vrijwel zeker zult willen), is het verstandig een versiebeheersysteem (Version Control System in het Engels, afgekort tot VCS) te gebruiken. Als je dat gebruikt kan je eerdere versies van bestanden of het hele project terughalen, wijzigingen tussen twee momententen in tijd bekijken, zien wie het laatst iets aangepast heeft wat een probleem zou kunnen veroorzaken, wie een probleen heeft veroorzaakt en wanneer en nog veel meer. Een VCS gebruiken betekent meestal ook dat je de situatie gemakkelijk terug kan draaien als je een fout maakt of bestanden kwijtraakt. Daarbij komt nog dat dit allemaal heel weinig extra belasting met zich mee brengt.
+Als je een grafisch ontwerper bent of websites ontwerpt en elke versie van een afbeelding of opmaak wilt bewaren (wat je vrijwel zeker zult willen), is het verstandig een versiebeheersysteem (Version Control System in het Engels, afgekort tot VCS) te gebruiken. Als je dat gebruikt kan je eerdere versies van bestanden of het hele project terughalen, wijzigingen tussen twee momententen in tijd bekijken, zien wie het laatst iets aangepast heeft wat een probleem zou kunnen veroorzaken, wie een probleem heeft veroorzaakt en wanneer en nog veel meer. Een VCS gebruiken betekent meestal ook dat je de situatie gemakkelijk terug kan draaien als je een fout maakt of bestanden kwijtraakt. Daarbij komt nog dat dit allemaal heel weinig extra belasting met zich mee brengt.
 
 ### Lokale versiebeheersystemen ###
 
@@ -53,11 +53,11 @@ Om met dit probleem om te gaan hebben programmeurs lang geleden lokale VCSen ont
 Insert 18333fig0101.png
 Figuur 1-1. Een diagram van een lokaal versiebeheersysteem.
 
-Een populair gereedschap voor VCS was een systeem genaamd rcs, wat vandaag de dag nog steeds met veel computers wordt mee geleverd. Zelfs het populaire besturingssysteem Mac OS X heeft rcs als je de Developer Tools installeert. Dit gereedschap werkt in principe door verzamelingen van ‘patches’ (de verschillen tussen bestanden) van de opvolgende bestandsversies in een speciaal formaat op de harde schijf op te slaan. Zo kan je een bestand reproduceren bestand zoals deze er uitzag op enig moment in tijd door alle patches bij elkaar op te tellen.
+Een populair gereedschap voor VCS was een systeem genaamd rcs, wat vandaag de dag nog steeds met veel computers wordt meegeleverd. Zelfs het populaire besturingssysteem Mac OS X heeft rcs als je de Developer Tools installeert. Dit gereedschap werkt in principe door verzamelingen van ‘patches’ (de verschillen tussen bestanden) van de opvolgende bestandsversies in een speciaal formaat op de harde schijf op te slaan. Zo kan je een bestand reproduceren zoals deze er uitzag op enig moment in tijd door alle patches bij elkaar op te tellen.
 
 ### Gecentraliseerde versiebeheersystemen ###
 
-De volgende belangrijke uitdaging waar mensen tegenaan lopen is dat ze samen moeten werken met ontwikkelaars op andere computers. Om deze uitdaging te aan te gaan ontwikkelde men Gecentraliseerde Versiebeheersystemen (Centralized Version Control Systems, afgekort CVCSs). Deze systemen, zoals CVS, Subversion en Perforce, hebben één centrale server waarop alle versies van de bestanden staan en een aantal clients die de bestanden daar van ophalen (‘check out’). Vele jaren was dit de standaard voor versiebeheer (zie Figuur 1-2).
+De volgende belangrijke uitdaging waar mensen tegenaan lopen is dat ze samen moeten werken met ontwikkelaars op andere computers. Om deze uitdaging aan te gaan ontwikkelde men Gecentraliseerde Versiebeheersystemen (Centralized Version Control Systems, afgekort CVCSs). Deze systemen, zoals CVS, Subversion en Perforce, hebben één centrale server waarop alle versies van de bestanden staan en een aantal clients die de bestanden daar van ophalen (‘check out’). Vele jaren was dit de standaard voor versiebeheer (zie Figuur 1-2).
 
 Insert 18333fig0102.png
 Figuur 1-2. Een diagram van een gecentraliseerd versiebeheersysteem.
@@ -91,7 +91,7 @@ Sinds het ontstaan in 2005 is Git gegroeid tot zijn huidige vorm: het is eenvoud
 
 ## De basis van Git ##
 
-Dus, wat is Git in een notendop? Dit is een belangrijke paragraaf om in je op te nemen, omdat als je goed begrijpt wat Git is en de fundamenten van de interne werking begrijpt, het waarschijnlijk een stuk makkelijker wordt om Git effectief te gebruiken. Probeer, als je Git aan het leren bent, te vergeten wat je al weet over andere VCSen zoals Subversion en Perforce; zo kan je verwarring bij gebruik door de subtiele verschillen voorkomen. Git gaat op een hele andere manier met informatie om dan die andere systemen, ook al lijken de verschillende commando’s behoorlijk op elkaar. Als je die verschillen begrijpt, kan je voorkomen dat je verward raakt als je Git gebruikt.
+Dus, wat is Git in een notendop? Dit is een belangrijke paragraaf om in je op te nemen, omdat, als je goed begrijpt wat Git is en de fundamenten van de interne werking begrijpt, het waarschijnlijk een stuk makkelijker wordt om Git effectief te gebruiken. Probeer, als je Git aan het leren bent, te vergeten wat je al weet over andere VCSen zoals Subversion en Perforce; zo kan je verwarring bij gebruik door de subtiele verschillen voorkomen. Git gaat op een hele andere manier met informatie om dan die andere systemen, ook al lijken de verschillende commando’s behoorlijk op elkaar. Als je die verschillen begrijpt, kan je voorkomen dat je verward raakt als je Git gebruikt.
 
 ### Momentopnames in plaats van verschillen ###
 
@@ -100,12 +100,12 @@ Een groot verschil tussen Git en elke andere VCS (inclusief Subversion en consor
 Insert 18333fig0104.png
 Figuur 1-4. Andere systemen bewaren data meestal als veranderingen aan een basisversie van elk bestand.
 
-Git ziet en bewaart zijn data heel anders. De kijk van Git op zijn data kan worden uitgelegd als een reeks momentopnames (snapshots) van een miniatuurbestandsysteem. Elke keer dat je ‘commit’ (de status van van je project in Git opslaat) neemt het een soort van foto van hoe al je bestanden er op dat moment uitzien en slaat een verwijzing naar die foto op. Voor efficiëntie slaat Git ongewijzigde bestanden niet elke keer opnieuw op, alleen een verwijzing naar het eerdere identieke bestand dat het eerder al opgeslagen had. In Figuur 1-5 kan je zie hoe Git ongeveer over zijn data denkt.
+Git ziet en bewaart zijn data heel anders. De kijk van Git op zijn data kan worden uitgelegd als een reeks momentopnames (snapshots) van een miniatuurbestandssysteem. Elke keer dat je ‘commit’ (de status van je project in Git opslaat) neemt het een soort van foto van hoe al je bestanden er op dat moment uitzien en slaat een verwijzing naar die foto op. Voor efficiëntie slaat Git ongewijzigde bestanden niet elke keer opnieuw op, alleen een verwijzing naar het eerdere identieke bestand dat het eerder al opgeslagen had. In Figuur 1-5 kan je zie hoe Git ongeveer over zijn data denkt.
 
 Insert 18333fig0105.png
 Figuur 1-5. Git bewaart data als momentopnames van het project.
 
-Dat is een belangrijk onderscheid tussen Git en bijna alle overige VCSen. Hierdoor moet Git bijna elk aspect van versiebeheer heroverwegen, terwijl de meeste andere systemen het van hebben overgenomen van voorgaande generaties. Dit maakt Git meer een soort mini-bestandssysteem met een paar ongelooflijk krachtige gereedschappen, in plaats van niets meer of minder dan een VCS. We zullen een paar van de voordelen die je krijgt als je op die manier over data denkt gaan onderzoeken, als we ‘branching’ (gesplitste ontwikkeling) toelichten in Hoofdstuk 3.
+Dat is een belangrijk onderscheid tussen Git en bijna alle overige VCSen. Hierdoor moet Git bijna elk aspect van versiebeheer heroverwegen, terwijl de meeste andere systemen het hebben overgenomen van voorgaande generaties. Dit maakt Git meer een soort mini-bestandssysteem met een paar ongelooflijk krachtige gereedschappen, in plaats van niets meer of minder dan een VCS. We zullen een paar van de voordelen die je krijgt als je op die manier over data denkt gaan onderzoeken, als we ‘branching’ (gesplitste ontwikkeling) toelichten in Hoofdstuk 3.
 
 ### Bijna alles is lokaal ###
 
@@ -127,18 +127,18 @@ Je zult deze hashwaarden overal tegenkomen omdat Git er zoveel gebruik van maakt
 
 ### Git voegt normaal gesproken alleen data toe ###
 
-Bijna alles wat je in Git doet, leidt tot toevoeging van data in de Git database. Het is erg moeilijk om het systeem iets te laten doen wat je niet ongedaan kan maken of het de gegevens te laten wissen op wat voor manier dan ook. Zoals met elke VCS kun je veranderingen verliezen of verhaspelen als deze nog niet hebt gecommit; maar als je dat eenmaal hebt gedaan, is het erg moeilijk om die data te verliezen, zeker als je de lokale database regelmatig uploadt (‘push’) naar een andere repository.
+Bijna alles wat je in Git doet, leidt tot toevoeging van data in de Git database. Het is erg moeilijk om het systeem iets te laten doen wat je niet ongedaan kan maken of het de gegevens te laten wissen op wat voor manier dan ook. Zoals met elke VCS kun je veranderingen verliezen of verhaspelen als je deze nog niet hebt gecommit; maar als je dat eenmaal hebt gedaan, is het erg moeilijk om die data te verliezen, zeker als je de lokale database regelmatig uploadt (‘push’) naar een andere repository.
 
 Dit maakt het gebruik van Git zo plezierig omdat je weet dat je kunt experimenteren zonder het gevaar te lopen jezelf behoorlijk in de nesten te werken. Zie Hoofdstuk 9 voor een iets diepgaandere uitleg over hoe Git zijn data bewaart en hoe je de data die verloren lijkt kunt terughalen.
 
 ### De drie toestanden ###
 
-Let nu goed op. Dit is het belangrijkste dat je over Git moet weten als je wilt dat de rest van het leerproces gladjes verloopt. Git heeft drie hoofdtoestanden waarin bestanden zich kunnen bevinden: gecommit (‘commited’), aangepast (‘modified’) en voorbereid voor een commit (‘staged’). Committed houdt in dat alle data veilig opgeslagen is in je lokale database. Modified betekent dat je het bestand hebt gewijzigd maar dat je nog niet naar je database gecommit hebt. Staged betekent dat je al hebt aangegeven dat je de huidige versie van het aangepaste bestand in je volgende commit meegenomen moet worden.
+Let nu goed op. Dit is het belangrijkste dat je over Git moet weten als je wilt dat de rest van het leerproces gladjes verloopt. Git heeft drie hoofdtoestanden waarin bestanden zich kunnen bevinden: gecommit (‘commited’), aangepast (‘modified’) en voorbereid voor een commit (‘staged’). Committed houdt in dat alle data veilig opgeslagen is in je lokale database. Modified betekent dat je het bestand hebt gewijzigd maar dat je nog niet naar je database gecommit hebt. Staged betekent dat je al hebt aangegeven dat de huidige versie van het aangepaste bestand in je volgende commit meegenomen moet worden.
 
-Dit brengt ons tot de drie hoofdonderdelen van een Gitproject: de Git directory, de werk directory, en de wachtrij voor een commit (‘staging area’)
+Dit brengt ons tot de drie hoofdonderdelen van een Gitproject: de Git directory, de werk-directory, en de wachtrij voor een commit (‘staging area’)
 
 Insert 18333fig0106.png 
-Figuur 1-6. Werk directory, wachtrij en Git directory
+Figuur 1-6. Werk-directory, wachtrij en Git directory
 
 De Git directory is waar Git de metadata en objectdatabase van je project opslaat. Dit is het belangrijkste deel van Git. Deze directory wordt gekopiëerd wanneer je een repository kloont vanaf een andere computer.
 
@@ -228,7 +228,7 @@ Git bevat standaard een stuk gereedschap genaamd `git config`, waarmee je de con
 
 *	Het bestand `/etc/gitconfig`: Bevat eigenschappen voor elk account op de computer en al hun repositories. Als je de optie `--system` meegeeft aan `git config`, zal het de configuratiegegevens in dit bestand lezen en schrijven.
 *	Het bestand `~/.gitconfig`: Eigenschappen voor jouw account. Je kunt Git dit bestand laten lezen en schrijven door de optie `--global` mee te geven.
-*	Het configuratiebestand in de Gitdirectory (dus `.git/config`) van de repository dat je op het moment gebruikt: Specifiek voor die ene repository. Elk niveau neemt voorrang boven het voorgaande, dus waarden die in `.git/config` zijn gebruikt zullen worden gebruikt in plaats van die in `/etc/gitconfig`.
+*	Het configuratiebestand in de Gitdirectory (dus `.git/config`) van de repository die je op het moment gebruikt: Specifiek voor die ene repository. Elk niveau neemt voorrang boven het voorgaande, dus waarden die in `.git/config` zijn gebruikt zullen worden gebruikt in plaats van die in `/etc/gitconfig`.
 
 Op systemen met Windows zoekt Git naar het `.gitconfig`-bestand in de `$HOME` directory (`%USERPROFILE%` in een Windows omgeving) wat zich vertaalt in `C:\Documents and Settings\$USER` of `C:\Users\$USER` voor de meesten, afhankelijk van de versie (`$USER` is `%USERNAME%` in Windows omgevingen). Het zoekt ook nog steeds naar `/etc/gitconfig`, maar dan gerelateerd aan de plek waar je MSys hebt staan, en dat is de plek is waar je Git op je Windowscomputer geïnstalleerd hebt.
 
@@ -249,7 +249,7 @@ Nu Git weet wie je bent, kun je de standaard tekstverwerker instellen die gebrui
 
 ### Je diffprogramma ###
 
-En andere nuttige optie die je misschien wel wilt instellen is het standaard diffprogramma om mergeconflicten op te lossen. Stel dat je vimdiff wilt gebruiken:
+Een andere nuttige optie die je misschien wel wilt instellen is het standaard diffprogramma om mergeconflicten op te lossen. Stel dat je vimdiff wilt gebruiken:
 
 	$ git config --global merge.tool vimdiff
 

From bd0275c31510f6b55f8c70ddcbc0f42006489418 Mon Sep 17 00:00:00 2001
From: Bert IJff <engbert@users.noreply.github.com>
Date: Wed, 2 Apr 2014 15:28:51 +0200
Subject: [PATCH 272/690] Update 01-chapter2.markdown

diverse typo's gecorrigeerd
voor wat betreft spatiecorrecties, zie ook www.spatiegebruik.nl
---
 nl/02-git-basics/01-chapter2.markdown | 78 +++++++++++++--------------
 1 file changed, 39 insertions(+), 39 deletions(-)

diff --git a/nl/02-git-basics/01-chapter2.markdown b/nl/02-git-basics/01-chapter2.markdown
index 6e1871b5c..53a08a328 100644
--- a/nl/02-git-basics/01-chapter2.markdown
+++ b/nl/02-git-basics/01-chapter2.markdown
@@ -1,7 +1,7 @@
 <!-- Attentie heren en dames vertalers.
 Ik zou het volgende willen voorstellen:
 Er zijn bepaalde termen die voor de gemiddelde Nederlandse computer gebruiker 
-veel beter klinken (of bekender voorkomen) als de orginele Engelse term. In het
+veel beter klinken (of bekender voorkomen) dan de orginele Engelse term. In het
 begin zullen deze termen niet vaak voorkomen, maar in de meer diepgaandere 
 hoofdstukken komen deze steeds meer voor. Termen als "Committen", "Mergen" 
 en "Applyen" klinken beter dan "Plegen" of "Toepassen", "Samenvoegen" en 
@@ -36,7 +36,7 @@ Veel succes en plezier bij het vertalen...
 <!-- SHA-1 of last checked en-version: fbf24105 -->
 # De basis van Git #
 
-Als je slechts één hoofdstuk kunt lezen om met Git aan de slag te gaan, dan is deze het. In dit hoofdstuk worden alle basiscommando's behandeld, die je nodig hebben om het leeuwendeel van de dingen te doen waarmee je uiteindelijk je tijd met Git zult doorbrengen. Als je dit hoofdstuk doorgenomen hebt, zul je een repository kunnen configureren en initialiseren, bestanden beginnen en stoppen te volgen en veranderingen te ‘stagen’ en ‘committen’. We laten ook zien hoe je Git kunt instellen zodat het bepaalde bestanden en bestandspatronen negeert, hoe je vergissingen snel en gemakkelijk ongedaan kunt maken, hoe je de geschiedenis van je project kan doorlopen en wijzigingen tussen commits kunt zien, en hoe je kunt pushen en pullen van en naar repositories.
+Als je slechts één hoofdstuk kunt lezen om met Git aan de slag te gaan, dan is dit het. In dit hoofdstuk worden alle basiscommando's behandeld, die je nodig hebben om het leeuwendeel van de dingen te doen waarmee je uiteindelijk je tijd met Git zult doorbrengen. Als je dit hoofdstuk doorgenomen hebt, zul je een repository kunnen configureren en initialiseren, bestanden beginnen en stoppen te volgen en veranderingen te ‘stagen’ en ‘committen’. We laten ook zien hoe je Git kunt instellen zodat het bepaalde bestanden en bestandspatronen negeert, hoe je vergissingen snel en gemakkelijk ongedaan kunt maken, hoe je de geschiedenis van je project kan doorlopen en wijzigingen tussen commits kunt zien, en hoe je kunt pushen naar en pullen van repositories.
 
 ## Een Git repository verkrijgen ##
 
@@ -62,25 +62,25 @@ We zullen zodadelijk beschrijven wat deze commando's doen. Op dit punt heb je ee
 
 Als je een kopie wilt van een bestaande Git repository, bijvoorbeeld een project waaraan je wilt bijdragen, dan is `git clone` het commando dat je nodig hebt. Als je bekend bent met andere versie-beheersystemen zoals Subversion, dan zal het je opvallen dat het commando `clone` is en niet `checkout`. Dit is een belangrijk verschil: Git ontvangt een kopie van bijna alle gegevens die de server heeft. Elke versie van ieder bestand in de hele geschiedenis van een project wordt binnengehaald als je `git clone` doet. In feite kun je als de schijf van de server kapot gaat, een clone van een willekeurige client gebruiken om de server terug in de status te brengen op het moment van clonen (al zou je wel wat hooks aan de kant van de server en dergelijke verliezen, maar alle versies van alle bestanden zullen er zijn; zie *Hoofdstuk 4* voor meer informatie).
 
-Je cloned een repository met `git clone [url]`. Bijvoorbeeld, als je de Ruby Git bibliotheek genaamd Grit wilt clonen, kun je dit als volgt doen:
+Je clonet een repository met `git clone [url]`. Bijvoorbeeld, als je de Ruby Git bibliotheek genaamd Grit wilt clonen, kun je dit als volgt doen:
 
 	$ git clone git://github.com/schacon/grit.git
 
-Dat maakt een directory genaamd `grit` aan, initialiseert hierin een `.git` directory, haalt alle data voor die repository binnen en doet een checkout van een werkkopie van de laatste versie. Als je in de nieuwe `grit` directory gaat kijken zal je de project bestanden vinden, klaar om gebruikt of aan gewerkt te worden. Als je de repository in een directory met een andere naam dan grit wilt clonen, dan kun je dit met het volgende commando specificeren:
+Dat maakt een directory genaamd `grit` aan, initialiseert hierin een `.git` directory, haalt alle data voor die repository binnen en doet een checkout van een werkkopie van de laatste versie. Als je in de nieuwe `grit` directory gaat kijken zal je de projectbestanden vinden, klaar om gebruikt of aan gewerkt te worden. Als je de repository in een directory met een andere naam dan grit wilt clonen, dan kun je dit met het volgende commando specificeren:
 
 	$ git clone git://github.com/schacon/grit.git mygrit
 
 Dat commando doet hetzelfde als het vorige, maar dan heet de doeldirectory `mygrit`.
 
-Git heeft een aantal verschillende transport protocollen die je kunt gebruiken. Het vorige voorbeeld maakt gebruik van het `git://` protocol, maar je kunt ook `http(s)://` of `gebruiker@server:/pad.git` tegenkomen, dat het SSH transport protocol gebruikt. *Hoofdstuk 4* zal alle beschikbare opties introduceren die de server kan inrichten om je toegang tot de Git repositories te geven, met daarbij de voors en tegens van elk.
+Git heeft een aantal verschillende transportprotocollen die je kunt gebruiken. Het vorige voorbeeld maakt gebruik van het `git://` protocol, maar je kunt ook `http(s)://` of `gebruiker@server:/pad.git` tegenkomen, dat het SSH transport protocol gebruikt. *Hoofdstuk 4* zal alle beschikbare opties introduceren die de server kan inrichten om je toegang tot de Git-repositories te geven, met daarbij de voors en tegens van elk.
 
 ## Wijzigingen aan het repository vastleggen ##
 
-Je hebt een eersteklas Git repository en een checkout of werkkopie van de bestanden binnen dat project. Als je wijzigingen maakt dan moet je deze committen in je repository op elk moment dat het project een status bereikt die je wilt vastleggen.
+Je hebt een eersteklas Git-repository en een checkout of werkkopie van de bestanden binnen dat project. Als je wijzigingen maakt dan moet je deze committen in je repository op elk moment dat het project een status bereikt die je wilt vastleggen.
 
-Onthoud dat elk bestand in je werkdirectory in een van twee statussen kan verkeren: *gevolgd (tracked)* of *niet gevolgd (untracked)*. *Tracked* bestanden zijn bestanden die in het laatste snapshot zaten; ze kunnen *ongewijzigd (unmodified)*, *gewijzigd (modified)* of *staged* zijn. *untracked* bestanden zijn al het andere; elk bestand in je werkdirectory dat niet in je laatste snapshot en niet in je staging area zit. Als je een repository voor het eerst cloned, zullen alle bestanden tracked en unmodified zijn, omdat je ze zojuist uitgechecked hebt en nog niets gewijzigd hebt.
+Onthoud dat elk bestand in je werkdirectory in een van twee statussen kan verkeren: *gevolgd (tracked)* of *niet gevolgd (untracked)*. *Tracked* bestanden zijn bestanden die in het laatste snapshot zaten; ze kunnen *ongewijzigd (unmodified)*, *gewijzigd (modified)* of *staged* zijn. *untracked* bestanden zijn al het andere; elk bestand in je werkdirectory dat niet in je laatste snapshot en niet in je staging area zit. Als je een repository voor het eerst clonet, zullen alle bestanden tracked en unmodified zijn, omdat je ze zojuist uitgechecked hebt en nog niets gewijzigd hebt.
 
-Zodra je bestanden wijzigt, ziet Git ze als modified omdat je ze veranderd hebt sinds je laatste commit. Je *staged* deze gewijzigde bestanden en commit al je gestagede wijzigingen, en de cyclus begint weer van voor af aan. Deze cyclus wordt in Figuur 2-1 geïllustreerd.
+Zodra je bestanden wijzigt, ziet Git ze als modified omdat je ze veranderd hebt sinds je laatste commit. Je *staget* deze gewijzigde bestanden en commit al je gestagede wijzigingen, en de cyclus begint weer van voor af aan. Deze cyclus wordt in Figuur 2-1 geïllustreerd.
 
 Insert 18333fig0201.png
 Figuur 2-1. De levenscyclus van de status van je bestanden.
@@ -93,7 +93,7 @@ Het commando dat je voornamelijk zult gebruiken om te bepalen welk bestand zich
 	# On branch master
 	nothing to commit (working directory clean)
 
-Dit betekent dat je een schone werkdirectory hebt, met andere woorden er zijn geen untracked bestanden die gewijzigd zijn. Git ziet ook geen untracked bestanden, anders zouden ze hier getoond worden. Als laatste vertelt het commando op welke tak (branch) je nu zit. Voor nu is dit altijd `master`, dat is de standaard; besteed daar voor nu nog geen aandacht aan. In het volgende hoofdstuk wordt gedetaileerd ingegaan op branches en referenties.
+Dit betekent dat je een schone werkdirectory hebt, met andere woorden er zijn geen tracked bestanden die gewijzigd zijn. Git ziet ook geen untracked bestanden, anders zouden ze hier getoond worden. Als laatste vertelt het commando op welke tak (branch) je nu zit. Voor nu is dit altijd `master`, dat is de standaard; besteed daar voor nu nog geen aandacht aan. In het volgende hoofdstuk wordt gedetaileerd ingegaan op branches en referenties.
 
 Stel dat je een nieuw bestand toevoegt aan je project, een simpel README bestand. Als het bestand voorheen nog niet bestond, en je doet `git status`, dan zul je het niet getrackte bestand op deze manier zien:
 
@@ -115,7 +115,7 @@ Om een nieuw bestand te beginnen te tracken, gebruik je het commando `git add`.
 
 	$ git add README
 
-Als je het status commando nogmaals uitvoert, zie je dat je README bestand nu getrackt en ge-staged is:
+Als je het `status` commando nogmaals uitvoert, zie je dat je README bestand nu getrackt en ge-staged is:
 
 	$ git status
 	On branch master
@@ -129,7 +129,7 @@ Je kunt zien dat het gestaged is, omdat het onder de kop “Changes to be commit
 
 ### Gewijzigde bestanden stagen ###
 
-Laten we een getrackte bestand wijzigen. Als je een reeds getrackt bestand genaamd `benchmarks.rb` wijzigt, en dan je `status` commando nog eens uitvoert, krijg je iets dat er zo uitziet:
+Laten we een getrackt bestand wijzigen. Als je een reeds getrackt bestand genaamd `benchmarks.rb` wijzigt, en dan je `status` commando nog eens uitvoert, krijg je iets dat er zo uitziet:
 
 	$ git status
 	On branch master
@@ -175,7 +175,7 @@ Beide bestanden zijn gestaged en zullen met je volgende commit meegaan. Stel nu
 	        modified:   benchmarks.rb
 	
 
-Asjemenou?! Nu staat `benchmarks.rb` zowel bij de staged en unstaged genoemd. Hoe is dat mogelijk? Het blijkt dat Git een bestand precies zoals het is staged wanneer je het `git add` commando uitvoert. Als je nu commit, dan zal de versie van `benchmarks.rb` zoals het was toen je voor 't laatst `git add` uitvoerde worden toegevoegd in de commit, en niet de versie van het bestand zoals het eruit ziet in je werkdirectory toen je `git commit` uitvoerde. Als je een bestand wijzigt nadat je `git add` uitvoert, dan moet je `git add` nogmaals uitvoeren om de laatste versie van het bestand te stagen:
+Asjemenou?! Nu staat `benchmarks.rb` zowel bij de staged en unstaged genoemd. Hoe is dat mogelijk? Het blijkt dat Git een bestand precies zoals het is staget wanneer je het `git add` commando uitvoert. Als je nu commit, dan zal de versie van `benchmarks.rb` zoals het was toen je voor 't laatst `git add` uitvoerde worden toegevoegd in de commit, en niet de versie van het bestand zoals het eruit ziet in je werkdirectory toen je `git commit` uitvoerde. Als je een bestand wijzigt nadat je `git add` uitvoert, dan moet je `git add` nogmaals uitvoeren om de laatste versie van het bestand te stagen:
 
 	$ git add benchmarks.rb
 	$ git status
@@ -195,7 +195,7 @@ Vaak zul je een klasse bestanden hebben waarvan je niet wilt dat Git deze automa
 	*.[oa]
 	*~
 
-De eerste regel vertelt Git om ieder bestand te negeren waarvan de naam eindigt op een `.o` of `.a` (*object* en *archief* bestanden die het product kunnen zijn van het bouwen van je code). De tweede regel vertelt Git dat ze alle bestanden die eindigen op een tilde (`~`), wat gebruikt wordt door editors zoals Emacs om tijdelijke bestanden aan te geven, moet negeren. Je mag ook `log`, `tmp` of een `pid` directory toevoegen, automatisch gegenereerde documentatie, enzovoort. Een `.gitignore` bestand aanmaken voordat je gaat beginnen is over 't algemeen een goed idee, zodat je niet per ongeluk bestanden commit die je echt niet in je repository wilt hebben.
+De eerste regel vertelt Git om ieder bestand te negeren waarvan de naam eindigt op een `.o` of `.a` (*object* en *archief* bestanden die het product kunnen zijn van het bouwen van je code). De tweede regel vertelt Git dat ze alle bestanden moet negeren die eindigen op een tilde (`~`), wat gebruikt wordt door editors zoals Emacs om tijdelijke bestanden aan te geven. Je mag ook `log`, `tmp` of een `pid` directory toevoegen, automatisch gegenereerde documentatie, enzovoort. Een `.gitignore` bestand aanmaken voordat je gaat beginnen is over 't algemeen een goed idee, zodat je niet per ongeluk bestanden commit die je echt niet in je repository wilt hebben.
 
 De regels voor patronen die je in het `.gitignore` bestand kunt zetten zijn als volgt:
 
@@ -204,7 +204,7 @@ De regels voor patronen die je in het `.gitignore` bestand kunt zetten zijn als
 *	Je mag patronen laten eindigen op een schuine streep (`/`) om een directory te specificeren.
 *	Je mag een patroon ontkennend maken door het te laten beginnen met een uitroepteken (`!`).
 
-Expansie (`glob`) patronen zijn vereenvoudigde reguliere expressies die in shell omgevingen gebruikt worden. Een asterisk (`*`) komt overeen met nul of meer karakters, `[abc]` komt overeen met ieder karakter dat tussen de blokhaken staat (in dit geval `a`, `b` of `c`), een vraagteken (`?`) komt overeen met een enkel karakter en blokhaken waartussen karakters staan die gescheiden zijn door een streepje (`[0-9]`) komen overeen met ieder karakter wat tussen die karakters zit (in dit geval 0 tot en met 9).
+Expansie (`glob`) patronen zijn vereenvoudigde reguliere expressies die in shell-omgevingen gebruikt worden. Een asterisk (`*`) komt overeen met nul of meer karakters, `[abc]` komt overeen met ieder karakter dat tussen de blokhaken staat (in dit geval `a`, `b` of `c`), een vraagteken (`?`) komt overeen met een enkel karakter en blokhaken waartussen karakters staan die gescheiden zijn door een streepje (`[0-9]`) komen overeen met ieder karakter wat tussen die karakters zit (in dit geval 0 tot en met 9).
 
 Hier is nog een voorbeeld van een `.gitignore` bestand:
 
@@ -226,7 +226,7 @@ Een `**/` patroon is sinds versie 1.8.2 beschikbaar in Git.
 
 Als het `git status` commando te vaag is voor je, je wilt precies weten wat je veranderd hebt en niet alleen welke bestanden veranderd zijn, dan kun je het `git diff` commando gebruiken. We zullen `git diff` later in meer detail bespreken, maar je zult dit commando het meest gebruiken om deze twee vragen te beantwoorden: Wat heb je veranderd maar nog niet gestaged? En wat heb je gestaged en sta je op het punt te committen? Waar `git status` deze vragen heel algemeen beantwoordt, laat `git diff` je de exacte toegevoegde en verwijderde regels zien, de patch, als het ware.
 
-Stel dat je het `README` bestand opnieuw verandert en staged, en dan het `benchmarks.rb` bestand verandert zonder het te stagen. Als je je `status` commando uitvoert, dan zie je nogmaals zoiets als dit:
+Stel dat je het `README` bestand opnieuw verandert en staget, en dan het `benchmarks.rb` bestand verandert zonder het te stagen. Als je je `status` commando uitvoert, dan zie je nogmaals zoiets als dit:
 
 	$ git status
 	On branch master
@@ -280,7 +280,7 @@ Als je wilt zien wat je gestaged hebt en in je volgende commit zal zitten, dan k
 
 Het is belangrijk om te zien dat `git diff` zelf niet alle wijzigingen sinds je laatste commit laat zien, alleen wijzigingen die nog niet gestaged zijn. Dit kan verwarrend zijn, omdat als je al je wijzigingen gestaged hebt, `git diff` geen output zal geven.
 
-Nog een voorbeeld. Als je het `benchmarks.rb` bestand staged en vervolgens verandert, dan kun je `git diff` gebruiken om de wijzigingen in het bestand te zien dat gestaged is en de wijzigingen die niet gestaged zijn:
+Nog een voorbeeld. Als je het `benchmarks.rb` bestand staget en vervolgens verandert, dan kun je `git diff` gebruiken om de wijzigingen in het bestand te zien dat gestaged is en de wijzigingen die niet gestaged zijn:
 
 	$ git add benchmarks.rb
 	$ echo '# test line' >> benchmarks.rb
@@ -364,7 +364,7 @@ Als alternatief kun je de commit boodschap met het `commit` commando meegeven do
 
 Nu heb je je eerste commit gemaakt! Je kunt zien dat de commit je wat output over zichzelf heeft gegeven: op welke branch je gecommit hebt (`master`), welke SHA-1 checksum de commit heeft (`463dc4f`), hoeveel bestanden er veranderd zijn, en statistieken over toegevoegde en verwijderde regels in de commit.
 
-Onthoud dat de commit de snapshot, die je in je staging area ingesteld hebt, opslaat. Alles wat je niet gestaged hebt staat nog steeds gewijzigd; je kunt een volgende commit doen om het aan je geschiedenis toe te voegen. Iedere keer dat je een commit doet, leg je een snapshot van je project vast dat je later terug kunt draaien of mee kunt vergelijken.
+Onthoud dat de commit de snapshot, die je in je staging area ingesteld hebt, opslaat. Alles wat je niet gestaged hebt staat nog steeds gewijzigd; je kunt een volgende commit doen om het aan je geschiedenis toe te voegen. Iedere keer dat je een commit doet, leg je een snapshot van je project vast dat je later terug kunt draaien of waarmee je kunt vergelijken.
 
 ### De staging area overslaan ###
 
@@ -424,7 +424,7 @@ Je kunt bestanden, directories en bestandspatronen aan het `git rm` commando mee
 
 	$ git rm log/\*.log
 
-Let op de backslash (`\`) voor de `*`. Dit is nodig omdat Git zijn eigen bestandsnaam expansie doet, naast die van je shell. In de Windows systeemconsole moet de backslash worden weggelaten. Dit commando verwijdert alle bestanden die de `.log` extensie hebben in de `log/` directory. Of, je kunt zoiets als dit doen:
+Let op de backslash (`\`) voor de `*`. Dit is nodig omdat Git zijn eigen bestandsnaam-expansie doet, naast die van je shell. In de Windows systeemconsole moet de backslash worden weggelaten. Dit commando verwijdert alle bestanden die de `.log` extensie hebben in de `log/` directory. Of, je kunt zoiets als dit doen:
 
 	$ git rm \*~
 
@@ -432,7 +432,7 @@ Dit commando verwijdert alle bestanden die eindigen met `~`.
 
 ### Bestanden verplaatsen ###
 
-Anders dan vele andere VCS systemen, traceert Git niet expliciet verplaatsingen van bestanden. Als je een bestand een nieuwe naam geeft in Git, is er geen metadata opgeslagen in Git die vertelt dat je het bestand hernoemd hebt. Maar Git is slim genoeg om dit alsnog te zien, we zullen bestandsverplaatsing detectie wat later behandelen.
+Anders dan vele andere VCS systemen, traceert Git niet expliciet verplaatsingen van bestanden. Als je een bestand een nieuwe naam geeft in Git, is er geen metadata opgeslagen in Git die vertelt dat je het bestand hernoemd hebt. Maar Git is slim genoeg om dit alsnog te zien, we zullen bestandsverplaatsing-detectie wat later behandelen.
 
 Het is daarom een beetje verwarrend dat Git een `mv` commando heeft. Als je een bestand wilt hernoemen in Git, kun je zoiets als dit doen
 
@@ -459,7 +459,7 @@ Git komt er impliciet achter dat het om een hernoemd bestand gaat, dus het maakt
 
 ## De commit geschiedenis bekijken ##
 
-Nadat je een aantal commits gemaakt hebt, of als je een repository met een bestaande commit geschiedenis gecloned hebt, zul je waarschijnlijk terug willen zien wat er gebeurd is. Het meest basale en krachtige tool om dit te doen is het `git log` commando.
+Nadat je een aantal commits gemaakt hebt, of als je een repository met een bestaande commit-geschiedenis gecloned hebt, zul je waarschijnlijk terug willen zien wat er gebeurd is. Het meest basale en krachtige tool om dit te doen is het `git log` commando.
 
 Deze voorbeelden maken gebruik van een eenvoudig project genaamd simplegit dat ik vaak voor demonstraties gebruikt. Om het project op te halen, voer dit uit
 
@@ -592,7 +592,7 @@ Een andere handige optie is `--pretty`. Deze optie verandert de log output naar
 	085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7 removed unnecessary test code
 	a11bef06a3f659402fe7563abf99ad00de2209e6 first commit
 
-De meest interessante optie is `format`, waarmee je je eigen log uitvoer formaat kunt specificeren. Dit is in het bijzonder handig als je output aan het genereren bent voor automatische verwerking; omdat je expliciet het formaat kan specificeren, weet je dat het niet zal veranderen bij volgende versies van Git:
+De meest interessante optie is `format`, waarmee je je eigen log-uitvoer-formaat kunt specificeren. Dit is in het bijzonder handig als je output aan het genereren bent voor automatische verwerking; omdat je expliciet het formaat kan specificeren, weet je dat het niet zal veranderen bij volgende versies van Git:
 
 	$ git log --pretty=format:"%h - %an, %ar : %s"
 	ca82a6d - Scott Chacon, 11 months ago : changed the version number
@@ -615,7 +615,7 @@ The lines must be formatted as follows
 	%p	Afgekorte parent hashes
 	%an	Auteur naam
 	%ae	Auteur e-mail
-	%ad	Auteur datum (formaat respecteerd de –date= optie)
+	%ad	Auteur datum (formaat respecteert de –date= optie)
 	%ar	Auteur datum, relatief
 	%cn	Committer naam
 	%ce	Committer e-mail
@@ -625,7 +625,7 @@ The lines must be formatted as follows
 
 Je zult je misschien afvragen wat het verschil is tussen _author_ en _committer_. De _author_ is de persoon die de patch oorspronkelijk geschreven heeft, en de _committer_ is de persoon die de patch als laatste heeft toegepast. Dus als je een patch naar een project stuurt en een van de kernleden past de patch toe, dan krijgen jullie beiden de eer, jij als de auteur en het kernlid als de committer. We gaan hier wat verder op in in *Hoofdstuk 5*.
 
-De `oneline` en `format` opties zijn erg handig in combinatie met een andere `log` optie genaamd `--graph`. Deze optie maakt een mooie ASCII grafiek waarin je branch en merge geschiedenis getoond worden, die we kunnen zien in onze kopie van het Grit project repository:
+De `oneline` en `format` opties zijn erg handig in combinatie met een andere `log` optie genaamd `--graph`. Deze optie maakt een mooie ASCII grafiek waarin je branch- en merge-geschiedenis getoond worden, die we kunnen zien in onze kopie van het Grit project repository:
 
 	$ git log --pretty=format:"%h %s" --graph
 	* 2d3acf9 ignore errors from SIGCHLD on trap
@@ -639,7 +639,7 @@ De `oneline` en `format` opties zijn erg handig in combinatie met een andere `lo
 	* d6016bc require time for xmlschema
 	*  11d191e Merge branch 'defunkt' into local
 
-Dat zijn slechts een paar simpele output formaat opties voor `git log`; er zijn er nog veel meer. Tabel 2-2 toont de opties waarover we het tot nog toe gehad hebben, en wat veel voorkomende formaat opties die je misschien handig vindt, samen met hoe ze de output van het `log` commando veranderen.
+Dat zijn slechts een paar simpele output formaat opties voor `git log`; er zijn er nog veel meer. Tabel 2-2 toont de opties waarover we het tot nog toe gehad hebben, en wat veel voorkomende formaat-opties die je misschien handig vindt, samen met hoe ze de output van het `log` commando veranderen.
 
 <!-- Attention to translators: this is a table declaration.
 The lines must be formatted as follows
@@ -651,11 +651,11 @@ The lines must be formatted as follows
 	--word-diff	Toon de patch in een woord diff formaat.
 	--stat	Toon statistieken voor gewijzigde bestanden per commit.
 	--shortstat	Toon alleen de gewijzigde/ingevoegde/verwijderde regel van het --stat commando.
-	--name-only	Toon de lijst van bestanden die gewijzigd zijn na de commit informatie.
+	--name-only	Toon de lijst van bestanden die gewijzigd zijn na de commit-informatie.
 	--name-status	Toon ook de lijst van bestanden die beïnvloed zijn door de toegevoegde/gewijzigde/verwijderde informatie.
 	--abbrev-commit	Toon alleen de eerste paar karakters van de SHA-1 checksum in plaats van alle 40.
 	--relative-date	Toon de datum in een relatief formaat (bijvoorbeeld, "2 weken geleden"), in plaats van het volledige datum formaat.
-	--graph		Toon een ASCII grafiek van de branch en merge geschiedenis naast de log output.
+	--graph		Toon een ASCII grafiek van de branch- en merge-geschiedenis naast de log output.
 	--pretty	Toon commits in een alternatief formaat. De opties bevatten oneline, short, full, fuller, en format (waarbij je je eigen formaat specificeert).
 	--oneline	Een gemaks-optie, staat voor `--pretty=oneline --abbrev-commit`.
 
@@ -663,7 +663,7 @@ The lines must be formatted as follows
 
 Naast het formatteren van de output, heeft `git log` nog een aantal bruikbare limiterende opties; dat wil zeggen, opties die je een subset van de commits tonen. Je hebt zo'n optie al gezien: de `-2` optie, die slechts de laatste twee commits laat zien. Sterker nog: je kunt `-<n>` doen, waarbij `n` een heel getal is om de laatste `n` commits te laten zien. In feite zul je deze vorm weinig gebruiken, omdat Git standaard alle output door een pager (pagineer applicatie) stuurt zodat je de log-uitvoer pagina voor pagina ziet.
 
-Dat gezegd hebbende, zijn de tijd limiterende opties zoals `--since` en `--until` erg handig. Dit commando bijvoorbeeld, geeft een lijst met commits die gedaan zijn gedurende de laatste twee weken:
+Dat gezegd hebbende, zijn de tijd-limiterende opties zoals `--since` en `--until` erg handig. Dit commando bijvoorbeeld, geeft een lijst met commits die gedaan zijn gedurende de laatste twee weken:
 
 	$ git log --since=2.weeks
 
@@ -687,7 +687,7 @@ The lines must be formatted as follows
 	--author	Laat alleen de commits zien waarvan de auteur bij de gegeven tekst past.
 	--committer	Laat alleen de commits zien waarvan de committer bij de gegeven tekst past.
 
-Bijvoorbeeld, als je wilt zien welke commits test bestanden in de Git broncode geschiedenis aanpasten waarvan de committer Junio Hamano is en die niet in de maand oktober van 2008 gemerged zijn, kun je zoiets als dit uitvoeren:
+Bijvoorbeeld, als je wilt zien welke commits test bestanden in de Git broncode geschiedenis aanpasten waarvan de committer Junio Hamano is en die in de maand oktober van 2008 gemerged zijn, kun je zoiets als dit uitvoeren:
 
 	$ git log --pretty="%h - %s" --author=gitster --since="2008-10-01" \
 	   --before="2008-11-01" --no-merges -- t/
@@ -705,13 +705,13 @@ Van de bijna 20.000 commits in de Git broncode historie, laat dit commando de 6
 Als je een meer grafische applicatie wilt gebruiken om je commit historie te visualiseren, wil je misschien een kijkje nemen naar het Tcl/Tk programma genaamd `gitk` dat met Git meegeleverd wordt. Gitk is eigenlijk een visuele `git log` tool, en het accepteert bijna alle filter opties die `git log` ook accepteert. Als je `gitk` in op de commandoregel in je project typt, zou je zoiets als in Figuur 2-2 moeten zien.
 
 Insert 18333fig0202.png
-Figuur 2-2. De gitk historie visualiseerder.
+Figuur 2-2. De gitk historie-visualiseerder.
 
-Je kunt de commit historie in de bovenste helft van het scherm zien, samen met een afkomst graaf. De diff in de onderste helft van het scherm laat je de veranderingen zien die geïntroduceerd zijn bij iedere commit die je aanklikt.
+Je kunt de commit-historie in de bovenste helft van het scherm zien, samen met een afkomst graaf. De diff in de onderste helft van het scherm laat je de veranderingen zien die geïntroduceerd zijn bij iedere commit die je aanklikt.
 
 ## Dingen ongedaan maken ##
 
-Op enig moment wil je misschien iets ongedaan maken. Hier zullen we een aantal basis tools laten zien om veranderingen die je gemaakt hebt weer ongedaan te maken. Maar pas op, je kunt niet altijd het ongedaan maken weer ongedaan maken. Dit is één van de weinige gedeeltes in Git waarbij je werk kwijt kunt raken als je het verkeerd doet.
+Op enig moment wil je misschien iets ongedaan maken. Hier zullen we een aantal basis-tools laten zien om veranderingen die je gemaakt hebt weer ongedaan te maken. Maar pas op, je kunt niet altijd het ongedaan maken weer ongedaan maken. Dit is één van de weinige gedeeltes in Git waarbij je werk kwijt kunt raken als je het verkeerd doet.
 
 ### Je laatste commit veranderen ###
 
@@ -768,7 +768,7 @@ Het commando is een beetje vreemd, maar het werkt. Het benchmarks.rb bestand is
 
 ### Een gewijzigd bestand weer ongewijzigd maken ###
 
-Wat als je je realiseert dat je de wijzigingen aan het `benchmarks.rb` bestand niet wilt behouden? Hoe kun je dit makkelijk ongedaan maken; terug brengen in de staat waarin het was toen je voor het laatst gecommit hebt (of initieel gecloned, of hoe je het ook in je werkdirectory gekregen hebt)? Gelukkig vertelt `git status` je ook hoe je dat moet doen. In de laatste voorbeeld output, ziet het unstaged gebied er zo uit:
+Wat als je je realiseert dat je de wijzigingen aan het `benchmarks.rb` bestand niet wilt behouden? Hoe kun je dit makkelijk ongedaan maken; terugbrengen in de staat waarin het was toen je voor het laatst gecommit hebt (of initieel gecloned, of hoe je het ook in je werkdirectory gekregen hebt)? Gelukkig vertelt `git status` je ook hoe je dat moet doen. In de laatste voorbeeld-output, ziet het unstaged gebied er zo uit:
 
 	Changes not staged for commit:
 	  (use "git add <file>..." to update what will be committed)
@@ -841,7 +841,7 @@ Ik heb het toevoegen van remote repositories al genoemd en getoond in vorige par
 	origin	git://github.com/schacon/ticgit.git
 	pb	git://github.com/paulboone/ticgit.git
 
-Nu kun je de naam pb op de commandoregel gebruiken in plaats van de hele URL. Bijvoorbeeld, als je alle informatie die Paul wel, maar jij niet in je repository wilt fetchen, dan kun je git fetch pb uitvoeren:
+Nu kun je de naam pb op de commandoregel gebruiken in plaats van de hele URL. Bijvoorbeeld, als je alle informatie die Paul wel, maar jij niet in je repository hebt wilt fetchen, dan kun je git fetch pb uitvoeren:
 
 	$ git fetch pb
 	remote: Counting objects: 58, done.
@@ -860,9 +860,9 @@ Zoals je zojuist gezien hebt, kun je om data van je remote projecten te halen di
 
 	$ git fetch [remote-name]
 
-Het commando gaat naar het remote project en haalt alle data van dat remote project dat jij nog niet hebt. Nadat je dit gedaan hebt, zou je references (referenties) naar alle branches van dat remote moeten hebben, die je op ieder tijdstip kunt mergen en bekijken. (We zullen in meer detail zien wat branches precies zijn, en hoe je ze moet gebruiken in *Hoofdstuk 3*.)
+Het commando gaat naar het remote project en haalt alle data van dat remote project dat jij nog niet hebt. Nadat je dit gedaan hebt, zou je references (referenties) naar alle branches van dat remote project moeten hebben, die je op ieder tijdstip kunt mergen en bekijken. (We zullen in meer detail zien wat branches precies zijn, en hoe je ze moet gebruiken in *Hoofdstuk 3*.)
 
-Als je een repository cloned, voegt dat commando die remote repository automatisch toe onder de naam *origin*. Dus `git fetch origin` fetcht (haalt) ieder nieuw werk dat gepusht is naar die server sinds je gecloned hebt (of voor het laatst gefetcht hebt). Het is belangrijk om te weten dat het fetch commando de data naar je locale repository haalt; het merged niet automatisch met je werk of verandert waar je momenteel aan zit te werken. Je moet het handmatig in je werk mergen wanneer je er klaar voor bent.
+Als je een repository clonet, voegt dat commando die remote repository automatisch toe onder de naam *origin*. Dus `git fetch origin` fetcht (haalt) ieder nieuw werk dat gepusht is naar die server sinds je gecloned hebt (of voor het laatst gefetcht hebt). Het is belangrijk om te weten dat het fetch commando de data naar je locale repository haalt; het merget niet automatisch met je werk of verandert waar je momenteel aan zit te werken. Je moet het handmatig in je werk mergen wanneer je er klaar voor bent.
 
 Als je een branch geconfigureerd hebt om een remote branch te volgen (tracken) (zie de volgende paragraaf en *Hoofdstuk 3* voor meer informatie), dan kun je het `git pull` commando gebruiken om automatisch een remote branch te fetchen en mergen in je huidige branch. Dit kan makkelijker of meer comfortabele workflow zijn voor je; en standaard stelt het `git clone` commando je lokale master branch zo in dat het de remote master branch van de server waarvan je gecloned hebt volgt (aangenomen dat de remote een master branch heeft). Over het algemeen zal een `git pull` dat van de server waarvan je origineel gecloned hebt halen en proberen het automatisch in de code waar je op dat moment aan zit te werken te mergen.
 
@@ -934,7 +934,7 @@ Als je om een of andere reden een referentie wilt verwijderen, je hebt de server
 
 ## Taggen (Labelen) ##
 
-Zoals de meeste VCS'en, heeft git de mogelijkheid om specifieke punten in de history als belangrijk te taggen (labelen). Over het algemeen gebruiken mensen deze functionaliteit om versie punten te markeren (`v1.0`, en zo). In deze paragraaf zul je leren hoe de beschikbare tags te tonen, hoe nieuwe tags te creëren, en wat de verschillende typen tags zijn.
+Zoals de meeste VCS'en, heeft git de mogelijkheid om specifieke punten in de history als belangrijk te taggen (labelen). Over het algemeen gebruiken mensen deze functionaliteit om versie-punten te markeren (`v1.0`, en zo). In deze paragraaf zul je leren hoe de beschikbare tags te tonen, hoe nieuwe tags te creëren, en wat de verschillende typen tags zijn.
 
 ### Jouw tags laten zien ###
 
@@ -946,7 +946,7 @@ De beschikbare tags in Git laten zien is rechttoe rechtaan. Type gewoon `git tag
 
 Dit commando toont de tags in alfabetische volgorde; de volgorde waarin ze verschijnen heeft geen echte betekenis.
 
-Je kunt ook zoeken op tags met een bepaald patroon. De Git bron repository, bijvoorbeeld, bevat meer dan 240 tags. Als je alleen geïnteresseerd bent om naar de 1.4.2 serie te kijken, kun je dit uitvoeren:
+Je kunt ook zoeken op tags met een bepaald patroon. De Git bron-repository, bijvoorbeeld, bevat meer dan 240 tags. Als je alleen geïnteresseerd bent om naar de 1.4.2 serie te kijken, kun je dit uitvoeren:
 
 	$ git tag -l 'v1.4.2.*'
 	v1.4.2.1
@@ -1135,7 +1135,7 @@ Als je veel tags hebt die je ineens wilt pushen, kun je ook de `--tags` optie aa
 	 * [new tag]         v1.4-lw -> v1.4-lw
 	 * [new tag]         v1.5 -> v1.5
 
-Als nu iemand anders van jouw repository cloned of pullt, dan zullen zij al jouw tags ook krijgen.
+Als nu iemand anders van jouw repository clonet of pullt, dan zullen zij al jouw tags ook krijgen.
 
 ## Tips en trucs ##
 
@@ -1167,7 +1167,7 @@ Dat is een erg handig trucje en zal je misschien wat tijd en documentatie lezen
 
 ### Git aliassen ###
 
-Git zal geen commando's afleiden uit wat gedeeltelijk intypt. Als je niet de hele tekst van ieder Git commando wilt intypen, kun je gemakkelijk een alias voor ieder commando configureren door `git config` te gebruiken. Hier zijn een aantal voorbeelden die je misschien wilt instellen:
+Git zal geen commando's afleiden uit wat je gedeeltelijk intypt. Als je niet de hele tekst van ieder Git commando wilt intypen, kun je gemakkelijk een alias voor ieder commando configureren door `git config` te gebruiken. Hier zijn een aantal voorbeelden die je misschien wilt instellen:
 
 	$ git config --global alias.co checkout
 	$ git config --global alias.br branch

From 5f9ab8fd90df9eb5651f84c70b2d5122eaa68d21 Mon Sep 17 00:00:00 2001
From: Bert IJff <engbert@users.noreply.github.com>
Date: Wed, 2 Apr 2014 17:16:20 +0200
Subject: [PATCH 273/690] Update 01-chapter3.markdown

diverse typo's gecorrigeerd
Nagezien tot aan Figuur 3-14.
---
 nl/03-git-branching/01-chapter3.markdown | 54 ++++++++++++------------
 1 file changed, 27 insertions(+), 27 deletions(-)

diff --git a/nl/03-git-branching/01-chapter3.markdown b/nl/03-git-branching/01-chapter3.markdown
index 0809e83b7..3ed209129 100644
--- a/nl/03-git-branching/01-chapter3.markdown
+++ b/nl/03-git-branching/01-chapter3.markdown
@@ -36,24 +36,24 @@ Veel succes en plezier bij het vertalen...
 <!-- SHA-1 of last checked en-version: fbf24105 -->
 # Branchen in Git #
 
-Bijna elk versiebeheersysteem ondersteunt een bepaalde vorm van branchen. Branchen komt erop neer dat je een tak afsplitst van de hoofd ontwikkellijn en daar verder mee gaat werken zonder aan de hoofdlijn te komen. Bij veel VCS'en is dat nogal een duur proces, vaak wordt er een nieuwe kopie gemaakt van de directory waar je broncode in staan, wat lang kan duren voor grote projecten.
+Bijna elk versiebeheersysteem ondersteunt een bepaalde vorm van branchen. Branchen komt erop neer dat je een tak afsplitst van de hoofd-ontwikkellijn en daar verder mee gaat werken zonder aan de hoofdlijn te komen. Bij veel VCS'en is dat nogal een duur proces, vaak wordt er een nieuwe kopie gemaakt van de directory waar je broncode in staat, wat lang kan duren voor grote projecten.
 
-Sommige mensen verwijzen naar het branch model in Git als de "killer eigenschap", en het onderscheidt Git zeker in de VCS gemeenschap. Waarom is het zo bijzonder? De manier waarop Git brancht is ongelooflijk lichtgewicht, waardoor branch operaties vrijwel instant zijn en het wisselen tussen de branches over het algemeen net zo snel. In tegenstelling to vele andere VCS's, moedigt Git juist een workflow aan waarbij vaak gebrancht en gemerged wordt, zelfs meerdere keren per dag. Deze eigenschap begrijpen en de techniek beheersen geeft je een krachtig en uniek gereedschap en kan letterlijk de manier waarop je ontwikkelt veranderen.
+Sommige mensen verwijzen naar het branch model in Git als de "killer eigenschap", en het onderscheidt Git zeker in de VCS-gemeenschap. Waarom is het zo bijzonder? De manier waarop Git brancht is ongelooflijk lichtgewicht, waardoor branch operaties vrijwel instant zijn en het wisselen tussen de branches over het algemeen net zo snel. In tegenstelling tot vele andere VCS's, moedigt Git juist een workflow aan waarbij vaak gebrancht en gemerged wordt, zelfs meerdere keren per dag. Deze eigenschap begrijpen en de techniek beheersen geeft je een krachtig en uniek gereedschap en kan letterlijk de manier waarop je ontwikkelt veranderen.
 
 ## Wat is een branch ##
 
-Om de manier waarop Git brancht echt te begrijpen, moeten we een stap terug doen en onderzoeken hoe Git zijn gegevens opslaat. Zoals je misschien herinnert van Hoofdstuk 1, slaat Git zijn gegevens niet op als een reeks van wijzigingen of delta's, maar in plaats daarvan als een serie snapshots.
+Om de manier waarop Git brancht echt te begrijpen, moeten we een stap terug doen en onderzoeken hoe Git zijn gegevens opslaat. Zoals je je misschien herinnert van Hoofdstuk 1, slaat Git zijn gegevens niet op als een reeks van wijzigingen of delta's, maar in plaats daarvan als een serie snapshots.
 
-Als je in Git commit, dan slaat Git een commit object op dat een verwijzing bevat naar het snapshot van de inhoud die je gestaged hebt, de auteur en bericht metagegevens, en nul of meer verwijzingen naar de commit of commits die de directe ouders van deze commit waren: nul ouders voor de eerste commit, één ouder voor een normale commit, en meerdere ouders voor een commit die het resultaat is van een merge van twee of meer branches.
+Als je in Git commit, dan slaat Git een commit object op dat een verwijzing bevat naar het snapshot van de inhoud die je gestaged hebt, de auteur- en bericht-metagegevens, en nul of meer verwijzingen naar de commit of commits die de directe ouders van deze commit waren: nul ouders voor de eerste commit, één ouder voor een normale commit, en meerdere ouders voor een commit die het resultaat is van een merge van twee of meer branches.
 
-Om dit te visualiseren, gaan we aannemen dat je een directory hebt met drie bestanden, en je staged en commit ze allemaal. Je gaat de bestanden stagen waardoor ze allemaal een checksum krijgen (de SHA-1 hash waar we het in Hoofdstuk 1 over hadden), bewaart die versie van het bestand in het Git repository (Git noemt ze blobs), en voegt die checksum toe aan de staging area:
+Om dit te visualiseren, gaan we aannemen dat je een directory hebt met drie bestanden, en je staget en commit ze allemaal. Je gaat de bestanden stagen waardoor ze allemaal een checksum krijgen (de SHA-1 hash waar we het in Hoofdstuk 1 over hadden), bewaart die versie van het bestand in het Git repository (Git noemt ze blobs), en voegt die checksum toe aan de staging area:
 
 	$ git add README test.rb LICENSE
 	$ git commit -m 'initial commit of my project'
 
-Als je de commit aanmaakt door `git commit` uit te voeren zal Git iedere directory in het project van een checksum voorzien en slaat ze als boomstructuur (`tree`) objecten in de Git repository op. Daarna creëert Git een `commit` object dat de metagegevens bevat en een verwijzing naar de hoofd `tree`-object van het project zodat Git deze snapshot kan opnieuw kan oproepen als dat nodig is.
+Als je de commit aanmaakt door `git commit` uit te voeren zal Git iedere directory in het project van een checksum voorzien en slaat ze als boomstructuur (`tree`) objecten in de Git repository op. Daarna creëert Git een `commit` object dat de metagegevens bevat en een verwijzing naar de hoofd-`tree`-object van het project zodat Git deze snapshot opnieuw kan oproepen als dat nodig is.
 
-Je Git repository bevat nu vijf objecten: een blob voor de inhoud van ieder van de drie bestanden, een tree die de inhoud van de directory weergeeft en specificeert welke bestandsnamen opgeslagen zijn als welke blobs, en een commit met de verwijzing naar die hoofd-tree en alle commit metagegevens. Conceptueel zien de gegevens in je Git repository eruit zoals in Figuur 3-1.
+Je Git repository bevat nu vijf objecten: een blob voor de inhoud van ieder van de drie bestanden, een tree die de inhoud van de directory weergeeft en specificeert welke bestandsnamen opgeslagen zijn als welke blobs, en een commit met de verwijzing naar die hoofd-tree en alle commit-metagegevens. Conceptueel zien de gegevens in je Git repository eruit zoals in Figuur 3-1.
 
 Insert 18333fig0301.png
 Figuur 3-1. Repository gegevens van een enkele commit.
@@ -61,9 +61,9 @@ Figuur 3-1. Repository gegevens van een enkele commit.
 Als je wat wijzigingen maakt en nogmaals commit, dan slaat de volgende commit een verwijzing op naar de commit die er direct aan vooraf ging. Na nog eens twee commits, zal je historie er ongeveer uit zien als Figuur 3-2.
 
 Insert 18333fig0302.png
-Figuur 3-2. Git object gegevens voor meerdere commits.
+Figuur 3-2. Git objectgegevens voor meerdere commits.
 
-Een branch in Git is simpelweg een lichtgewicht verplaatsbare verwijzing naar een van deze commits. De standaard branch naam in Git is master. Als je initieel commits maakt, dan krijg je een `master` branch die wijst naar de laatste commit die je gemaakt hebt. Iedere keer als je commit, beweegt het automatisch vooruit.
+Een branch in Git is simpelweg een lichtgewicht verplaatsbare verwijzing naar een van deze commits. De standaard branch-naam in Git is master. Als je initieel commits maakt, dan krijg je een `master`-branch die wijst naar de laatste commit die je gemaakt hebt. Iedere keer als je commit, beweegt het automatisch vooruit.
 
 Insert 18333fig0303.png
 Figuur 3-3. Branch wijzend in de commit gegevens historie.
@@ -75,12 +75,12 @@ Wat gebeurt er als je een nieuwe branch maakt? Door dat te doen wordt een nieuwe
 Dit maakt een nieuwe verwijzing naar dezelfde commit waar je nu op zit (zie Figuur 3-4).
 
 Insert 18333fig0304.png
-Figuur 3-4. Meerdere branches wijzend naar de commit gegevens historie.
+Figuur 3-4. Meerdere branches wijzend naar de commit-gegevenshistorie.
 
-Hoe weet Git op welke branch je nu zit? Het houdt een speciale verwijzing bij genaamd HEAD. Let op dat dit heel anders is dan het concept van HEAD in andere VCS's waar je misschien gewend aan bent, zoals Subversion of CVS. In Git is dit een verwijzing naar de lokale branch waar je nu op zit. In dit geval zit je nog steeds op master. Het git branch commando heeft alleen een nieuwe branch aangemaakt - we zijn nog niet overgeschakeld naar die branch (zie Figuur 3-5).
+Hoe weet Git op welke branch je nu zit? Het houdt een speciale verwijzing bij genaamd HEAD. Let op dat dit heel anders is dan het concept van HEAD in andere VCS's waar je misschien gewend aan bent, zoals Subversion of CVS. In Git is dit een verwijzing naar de lokale branch waar je nu op zit. In dit geval zit je nog steeds op master. Het `git branch`-commando heeft alleen een nieuwe branch aangemaakt - we zijn nog niet overgeschakeld naar die branch (zie Figuur 3-5).
 
 Insert 18333fig0305.png
-Figuur 3-5. HEAD bestand wijzend naar de branch waar je op zit.
+Figuur 3-5. HEAD-bestand wijzend naar de branch waar je op zit.
 
 Om over te schakelen naar een bestaande branch, voer je het `git checkout` commando uit. Laten we eens overschakelen naar de nieuwe testing branch:
 
@@ -117,14 +117,14 @@ Laten we een paar wijzigingen maken en nog eens committen:
 	$ vim test.rb
 	$ git commit -a -m 'made other changes'
 
-Nu is je project historie uiteen gelopen (zie Figuur 3-9). Je hebt een branch gemaakt en bent er naartoe overgeschakeld, hebt er wat werk op gedaan, en bent toen teruggeschakeld naar je hoofd-branch en hebt nog wat ander werk gedaan. Al die veranderingen zijn geïsoleerd van elkaar in aparte branches: je kunt heen en weer schakelen tussen de branches en ze mergen als je klaar bent. En je hebt dat alles gedaan met eenvoudige `branch` en `checkout` commando's.
+Nu is je projecthistorie uiteengelopen (zie Figuur 3-9). Je hebt een branch gemaakt en bent er naartoe overgeschakeld, hebt er wat werk op gedaan, en bent toen teruggeschakeld naar je hoofd-branch en hebt nog wat ander werk gedaan. Al die veranderingen zijn geïsoleerd van elkaar in aparte branches: je kunt heen en weer schakelen tussen de branches en ze mergen als je klaar bent. En je hebt dat alles gedaan met eenvoudige `branch` en `checkout` commando's.
 
 Insert 18333fig0309.png
-Figuur 3-9. De branch histories zijn uiteen gaan lopen.
+Figuur 3-9. De branch-histories zijn uiteen gaan lopen.
 
 Omdat een branch in Git in feite een eenvoudig bestand is dat de 40 karakter lange SHA-1 checksum van de commit bevat waar het naar wijst, zijn branches goedkoop om te maken en weer weg te gooien. Een nieuwe branch aanmaken is zo snel en eenvoudig als 41 bytes naar een bestand schrijven (40 karakters en een harde return).
 
-Dit is in scherp contrast met de wijze waarop de meeste VCS applicaties branchen, wat vaak het kopiëren van alle project bestanden naar een tweede map inhoudt. Dit kan enkele seconden of zelfs minuten duren, afhankelijk van de grootte van het project, daarentegen is het in Git altijd vrijwel meteen klaar. En omdat we de ouders opslaan terwijl we committen, wordt het vinden van een goed punt dat kan dienen als basis voor het mergen automatisch voor ons gedaan en is dat over het algemeen eenvoudig om te doen. Deze eigenschappen moedigen ontwikkelaars aan om vaak branches aan te maken en te gebruiken.
+Dit is in scherp contrast met de wijze waarop de meeste VCS applicaties branchen, wat vaak het kopiëren van alle projectbestanden naar een tweede map inhoudt. Dit kan enkele seconden of zelfs minuten duren, afhankelijk van de grootte van het project, daarentegen is het in Git altijd vrijwel meteen klaar. En omdat we de ouders opslaan terwijl we committen, wordt het vinden van een goed punt dat kan dienen als basis voor het mergen automatisch voor ons gedaan en is dat over het algemeen eenvoudig om te doen. Deze eigenschappen moedigen ontwikkelaars aan om vaak branches aan te maken en te gebruiken.
 
 Laten we eens kijken waarom je dat zou moeten doen.
 
@@ -138,9 +138,9 @@ Laten we eens door een eenvoudig voorbeeld van branchen en mergen stappen met ee
 
 Dan ontvang je een telefoontje dat je een ander probleem direct moet repareren. Je zult het volgende doen:
 
-1. Terugschakelen naar je productie branch.
+1. Terugschakelen naar je productie-branch.
 2. Een branch aanmaken om de snelle reparatie toe te voegen.
-3. Nadat het getest is de snelle reparatie branch mergen, en dat naar productie terugzetten.
+3. Nadat het getest is de snelle reparatie-branch mergen, en dat naar productie terugzetten.
 4. Terugschakelen naar je originele verhaal en doorgaan met werken.
 
 ### Eenvoudig branchen ###
@@ -148,9 +148,9 @@ Dan ontvang je een telefoontje dat je een ander probleem direct moet repareren.
 Als eerste, laten we zeggen dat je aan je project werkt en al een paar commits hebt staan (zie Figuur 3-10).
 
 Insert 18333fig0310.png
-Figuur 3-10. Een korte en eenvoudige commit historie.
+Figuur 3-10. Een korte en eenvoudige commit-historie.
 
-Je hebt besloten dan je gaat werken aan probleem #53 in wat voor systeem je bedrijf ook gebruikt om problemen te registreren. Voor de duidelijkheid: Git is niet verbonden met een specifiek probleem beheersysteem. Omdat probleem #53 een onderwerp is waar je gericht aan gaat werken, maak je een nieuwe branch aan waarin je aan de slag gaat. Om een branch aan te maken en er meteen naartoe te schakelen, kun je het `git checkout` commando uitvoeren met de `-b` optie:
+Je hebt besloten dan je gaat werken aan probleem #53 in wat voor systeem je bedrijf ook gebruikt om problemen te registreren. Voor de duidelijkheid: Git is niet verbonden met een specifiek probleembeheersysteem. Omdat probleem #53 een onderwerp is waar je gericht aan gaat werken, maak je een nieuwe branch aan waarin je aan de slag gaat. Om een branch aan te maken en er meteen naartoe te schakelen, kun je het `git checkout` commando uitvoeren met de `-b` optie:
 
 	$ git checkout -b iss53
 	Switched to a new branch 'iss53'
@@ -163,9 +163,9 @@ Dit is een afkorting voor:
 Figuur 3-11 toont het resultaat.
 
 Insert 18333fig0311.png
-Figuur 3-11. Een nieuwe branch verwijzing maken.
+Figuur 3-11. Een nieuwe branch-verwijzing maken.
 
-Je doet wat werk aan je web site en doet wat commits. Door dat te doen beweegt de `iss53` branch vooruit, omdat je het uitgecheckt hebt (dat wil zeggen, je HEAD wijst ernaar; zie Figuur 3-12):
+Je doet wat werk aan je website en doet wat commits. Door dat te doen beweegt de `iss53` branch vooruit, omdat je het uitgecheckt hebt (dat wil zeggen, je HEAD wijst ernaar; zie Figuur 3-12):
 
 	$ vim index.html
 	$ git commit -a -m 'added a new footer [issue 53]'
@@ -173,16 +173,16 @@ Je doet wat werk aan je web site en doet wat commits. Door dat te doen beweegt d
 Insert 18333fig0312.png
 Figuur 3-12. De iss53 branch is vooruit gegaan met je werk.
 
-Nu krijg je het telefoontje dan er een probleem is met de web site, en je moet het meteen repareren. Met Git hoef je de reparatie niet tegelijk uit te leveren met de `iss53` wijzigingen die je gemaakt hebt, en je hoeft ook niet veel moeite te doen om die wijzigingen terug te draaien voordat je kunt werken aan het toepassen van je reparatie in productie. Het enige wat je moet doen in terugschakelen naar je master branch.
+Nu krijg je het telefoontje dat er een probleem is met de website, en je moet het meteen repareren. Met Git hoef je de reparatie niet tegelijk uit te leveren met de `iss53` wijzigingen die je gemaakt hebt, en je hoeft ook niet veel moeite te doen om die wijzigingen terug te draaien voordat je kunt werken aan het toepassen van je reparatie in productie. Het enige wat je moet doen is terugschakelen naar je master-branch.
 
-Maar voordat je dat doet, merk op dat als je werk directory of staging area wijzigingen bevat die nog niet gecommit zijn en conflicteren met de branch die je gaat uitchecken, Git je niet laat om te schakelen. Het beste is om een schone werk status te hebben als je tussen branches gaat schakelen. Er zijn manieren om hier mee om te gaan (te weten, stashen en commit ammending) die we later gaan behandelen. Voor nu heb je alle wijzigingen gecommit, zodat je terug kunt schakelen naar je master branch:
+Maar voordat je dat doet, merk op dat als je werk-directory of staging area wijzigingen bevatten die nog niet gecommit zijn en conflicteren met de branch die je gaat uitchecken, Git je niet laat omschakelen. Het beste is om een schone werkstatus te hebben als je tussen branches gaat schakelen. Er zijn manieren om hier mee om te gaan (te weten, stashen en commit ammending) die we later gaan behandelen. Voor nu heb je alle wijzigingen gecommit, zodat je terug kunt schakelen naar je master-branch:
 
 	$ git checkout master
 	Switched to branch "master"
 
-Hierna, is je project werk directory precies zoals het was voordat je begon te werken aan probleem #53, en je kunt je concentreren op je snelle reparatie. Dit is een belangrijk punt om te onthouden: Git herstelt je werk directory zodanig dat deze eruit ziet als het snapshot van de commit waar de branch die je uitchecked naar wijst. Het voegt automatisch bestanden toe, verwijdert en wijzigt ze om er zeker van te zijn dat je werkkopie eruit ziet zoals de branch eruit zag toen je er voor het laatst op committe.
+Hierna is je project-werk-directory precies zoals het was voordat je begon te werken aan probleem #53, en je kunt je concentreren op je snelle reparatie. Dit is een belangrijk punt om te onthouden: Git herstelt je werk-directory zodanig dat deze eruit ziet als het snapshot van de commit waar de branch die je uitcheckt naar wijst. Het voegt automatisch bestanden toe, verwijdert en wijzigt ze om er zeker van te zijn dat je werkkopie eruit ziet zoals de branch eruit zag toen je er voor het laatst op committe.
 
-Vervolgens heb je een snelle reparatie (hotfix) te doen. Laten we een reparatie branch maken om op te werken totdat het af is (zie Figuur 3-13):
+Vervolgens heb je een snelle reparatie (hotfix) te doen. Laten we een reparatie-branch maken om op te werken totdat het af is (zie Figuur 3-13):
 
 	$ git checkout -b hotfix
 	Switched to a new branch 'hotfix'
@@ -194,7 +194,7 @@ Vervolgens heb je een snelle reparatie (hotfix) te doen. Laten we een reparatie
 Insert 18333fig0313.png
 Figuur 3-13. snelle reparatie branch gebaseerd op de positie van je master branch.
 
-Je kunt je tests draaien, je erzelf van verzekeren dat de reparatie is wat je wil, en het mergen in je master branch en het naar productie uitrollen. Je doet dit met het `git merge` commando:
+Je kunt je tests draaien, jezelf ervan verzekeren dat de reparatie is wat je wil, en het mergen in je master-branch en het naar productie uitrollen. Je doet dit met het `git merge` commando:
 
 	$ git checkout master
 	$ git merge hotfix
@@ -203,7 +203,7 @@ Je kunt je tests draaien, je erzelf van verzekeren dat de reparatie is wat je wi
 	 README | 1 -
 	 1 file changed, 1 deletion(-)
 
-Je zult de uitdrukking "Fast forward" zien in die merge. Omdat de commit van de branch waar je mee mergede direct stroomopwaarts is van de commit waar je op zit, zal Git de verwijzing vooruit verplaatsen. Om het op een andere manier te zeggen, als je een commit probeert te mergen met een commit die bereikt kan worden door de historie van eerste commit te volgen, zal Git de dingen vereenvoudigen door de verwijzing vooruit te verplaatsen omdat er geen afwijkend werk is om rte mergen; dit wordt een "fast forward" genoemd.
+Je zult de uitdrukking "Fast forward" zien in die merge. Omdat de commit van de branch waar je mee mergede direct stroomopwaarts is van de commit waar je op zit, zal Git de verwijzing vooruit verplaatsen. Om het op een andere manier te zeggen, als je een commit probeert te mergen met een commit die bereikt kan worden door de historie van eerste commit te volgen, zal Git de dingen vereenvoudigen door de verwijzing vooruit te verplaatsen omdat er geen afwijkend werk is om te mergen; dit wordt een "fast forward" genoemd.
 
 Je wijziging zit nu in het snapshot van de commit waar de `master` branch naar wijst, en je kunt je wijziging uitrollen (zie Figuur 3-14).
 

From 1fce7439fbdf0a5ef6ae2f3877c8a7f8d73374bd Mon Sep 17 00:00:00 2001
From: Liam Huang <liamhuang0205+git@gmail.com>
Date: Thu, 3 Apr 2014 12:53:09 +0800
Subject: [PATCH 274/690] [zh]Fix typo.

In [zh] Chapter 7.

1. Chinese left quote mark to English quote mark (4 times)
2. Chinese right quote mark to English quote mark (4 times)

Liam
---
 zh/07-customizing-git/01-chapter7.markdown | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/zh/07-customizing-git/01-chapter7.markdown b/zh/07-customizing-git/01-chapter7.markdown
index e2d361fed..2dd706ab5 100644
--- a/zh/07-customizing-git/01-chapter7.markdown
+++ b/zh/07-customizing-git/01-chapter7.markdown
@@ -19,7 +19,7 @@
 
 ### 客户端基本配置 ###
 
-Git 能够识别的配置项被分为了两大类：客户端和服务器端，其中大部分基于你个人工作偏好，属于客户端配置。尽管有数不尽的选项，但我只阐述 其中经常使用或者会对你的工作流产生巨大影响的选项，如果你想观察你当前的 Git 能识别的选项列表，请运行 
+Git 能够识别的配置项被分为了两大类：客户端和服务器端，其中大部分基于你个人工作偏好，属于客户端配置。尽管有数不尽的选项，但我只阐述 其中经常使用或者会对你的工作流产生巨大影响的选项，如果你想观察你当前的 Git 能识别的选项列表，请运行
 
 	$ git config --help
 
@@ -128,7 +128,7 @@ Git会按照你需要自动为大部分的输出加上颜色，你能明确地
 
 除此之外，以上每个选项都有子选项，可以被用来覆盖其父设置，以达到为输出的各个部分着色的目的。例如，让diff输出的改变信息以粗体、蓝色前景和黑色背景的形式显示：
 
-	$ git config --global color.diff.meta “blue black bold”
+	$ git config --global color.diff.meta "blue black bold"
 
 你能设置的颜色值如：normal、black、red、green、yellow、blue、magenta、cyan、white，正如以上例子设置的粗体属性，想要设置字体属性的话，可以选择如：bold、dim、ul、blink、reverse。
 
@@ -214,7 +214,7 @@ Git预先设置了许多其他的合并和解决冲突的工具，而你不必
 
 #### core.autocrlf ####
 
-假如你正在Windows上写程序，又或者你正在和其他人合作，他们在Windows上编程，而你却在其他系统上，在这些情况下，你可能会遇到行尾结束符问题。这是因为Windows使用回车和换行两个字符来结束一行，而Mac和Linux只使用换行一个字符。虽然这是小问题，但它会极大地扰乱跨平台协作。 
+假如你正在Windows上写程序，又或者你正在和其他人合作，他们在Windows上编程，而你却在其他系统上，在这些情况下，你可能会遇到行尾结束符问题。这是因为Windows使用回车和换行两个字符来结束一行，而Mac和Linux只使用换行一个字符。虽然这是小问题，但它会极大地扰乱跨平台协作。
 
 Git可以在你提交时自动地把行结束符CRLF转换成LF，而在签出代码时把LF转换成CRLF。用`core.autocrlf`来打开此项功能，如果是在Windows系统上，把它设置成`true`，这样当签出代码时，LF会被转换成CRLF：
 
@@ -454,10 +454,10 @@ Now `git diff` will be able to tell you what changed in `.odt` files.
 因此，你能写自己的过滤器，在提交文件到暂存区或签出文件时替换关键字。有2种过滤器，"clean"和"smudge"。在 `.gitattributes`文件中，你能对特定的路径设置一个过滤器，然后设置处理文件的脚本，这些脚本会在文件签出前（"smudge"，见图 7-2）和提交到暂存区前（"clean"，见图7-3）被调用。这些过滤器能够做各种有趣的事。
 
 Insert 18333fig0702.png
-图7-2. 签出时，“smudge”过滤器被触发。
+图7-2. 签出时，"smudge"过滤器被触发。
 
 Insert 18333fig0703.png
-图7-3. 提交到暂存区时，“clean”过滤器被触发。
+图7-3. 提交到暂存区时，"clean"过滤器被触发。
 
 这里举一个简单的例子：在暂存前，用`indent`（缩进）程序过滤所有C源代码。在`.gitattributes`文件中设置"indent"过滤器过滤`*.c`文件：
 
@@ -736,7 +736,7 @@ update 脚本和 `pre-receive` 脚本十分类似。不同之处在于它会为
 	      access[$user].each do |access_path|
 	        if !access_path || # 用户拥有完全访问权限
 	          (path.index(access_path) == 0) # 或者对此位置有访问权限
-	          has_file_access = true 
+	          has_file_access = true
 	        end
 	      end
 	      if !has_file_access
@@ -924,7 +924,7 @@ update 脚本和 `pre-receive` 脚本十分类似。不同之处在于它会为
 	  end
 	end
 
-这个脚本利用了一个第六章“修订版本选择”一节中不曾提到的语法。通过这一句可以获得一个所有已经完成推送的提交的列表：
+这个脚本利用了一个第六章"修订版本选择"一节中不曾提到的语法。通过这一句可以获得一个所有已经完成推送的提交的列表：
 
 	git rev-list ^#{sha}^@ refs/remotes/#{remote_ref}
 

From 2793b6bd26cf6493c6a58d495c5f31f3037fae62 Mon Sep 17 00:00:00 2001
From: Bert IJff <engbert@users.noreply.github.com>
Date: Thu, 3 Apr 2014 12:08:58 +0200
Subject: [PATCH 275/690] Update 01-chapter3.markdown

diverse typo's gecorrigeerd. (vanaf figuur 3-14)
---
 nl/03-git-branching/01-chapter3.markdown | 120 +++++++++++------------
 1 file changed, 60 insertions(+), 60 deletions(-)

diff --git a/nl/03-git-branching/01-chapter3.markdown b/nl/03-git-branching/01-chapter3.markdown
index 3ed209129..9032bea63 100644
--- a/nl/03-git-branching/01-chapter3.markdown
+++ b/nl/03-git-branching/01-chapter3.markdown
@@ -208,14 +208,14 @@ Je zult de uitdrukking "Fast forward" zien in die merge. Omdat de commit van de
 Je wijziging zit nu in het snapshot van de commit waar de `master` branch naar wijst, en je kunt je wijziging uitrollen (zie Figuur 3-14).
 
 Insert 18333fig0314.png
-Figuur 3-14. Je master branch wijst na de merge naar dezelfde plek als de hotfix branch.
+Figuur 3-14. Je master-branch wijst na de merge naar dezelfde plek als de hotfix branch.
 
 Nadat je super-belangrijke reparatie uitgerold is, ben je klaar om terug te schakelen naar het werk dat je deed voordat je onderbroken werd. Maar, eerst ga je de hotfix branch verwijderen, omdat je die niet langer nodig hebt - de `master` branch wijst naar dezelfde plek. Je kunt het verwijderen met de `-d` optie op `git branch`:
 
 	$ git branch -d hotfix
 	Deleted branch hotfix (3a0874c).
 
-Nu kun je terugschakelen naar je werk in uitvoering branch voor probleem #53 en doorgaan met daar aan te werken (zie Figuur 3-15):
+Nu kun je terugschakelen naar je werk-in-uitvoering-branch voor probleem #53 en doorgaan met daaraan te werken (zie Figuur 3-15):
 
 	$ git checkout iss53
 	Switched to branch 'iss53'
@@ -225,13 +225,13 @@ Nu kun je terugschakelen naar je werk in uitvoering branch voor probleem #53 en
 	 1 file changed, 1 insertion(+)
 
 Insert 18333fig0315.png
-Figuur 3-15. Je iss53 branch kan onafhankelijk vooruit bewegen.
+Figuur 3-15. Je `iss53`-branch kan onafhankelijk vooruitbewegen.
 
-Het is nuttig om hier op te merken dat het werk dat je in de hotfix branch gedaan hebt, niet in de bestanden van je `iss53` branch zit. Als je dat binnen moet halen, dan kun je de `master` branch in de `iss53` branch mergen door `git merge master` uit te voeren, of je kunt wachten met die wijzigingen te integreren tot het moment dat je het besluit neemt de `iss53` branch in de `master` te trekken.
+Het is nuttig om hier op te merken dat het werk dat je in de `hotfix`-branch gedaan hebt, niet in de bestanden van je `iss53` branch zit. Als je dat binnen moet halen, dan kun je de `master`-branch in de `iss53`-branch mergen door `git merge master` uit te voeren, of je kunt wachten met die wijzigingen te integreren tot het moment dat je het besluit neemt de `iss53`-branch in de `master` te trekken.
 
 ### Eenvoudig samenvoegen ###
 
-Stel dat je besloten hebt dat je probleem #53 werk gereed is en klaar bent om het te mergen in de `master` branch. Om dat te doen, zul je de `iss53` branch mergen zoals je die hotfix branch eerder hebt gemerged. Het enige dat je hoeft te doen is de branch uit te checken waar je in wenst te mergen en dan het `git merge` commando uit te voeren:
+Stel dat je besloten hebt dat je probleem #53 werk gereed is en klaar bent om het te mergen in de `master`-branch. Om dat te doen, zul je de `iss53`-branch mergen zoals je die hotfix branch eerder hebt gemerged. Het enige dat je hoeft te doen is de branch uit te checken waar je in wenst te mergen en dan het `git merge` commando uit te voeren:
 
 	$ git checkout master
 	$ git merge iss53
@@ -240,32 +240,32 @@ Stel dat je besloten hebt dat je probleem #53 werk gereed is en klaar bent om he
 	 README | 1 +
 	 1 file changed, 1 insertion(+)
 
-Dit ziet er iets anders uit dan de `hotfix` merge die je eerder gedaan hebt. In dit geval is je ontwikkelhistorie afgeweken van een eerder punt. Omdat de commit op de branch waar je op zit geen directe voorouder is van de branch waar je in merged, moet Git wat werk doen. In dit geval, doet Git een eenvoudige drieweg merge, gebruikmakend van de twee snapshots waarnaar gewezen wordt door de uiteinden van de branch en de gezamenlijke voorouder van die twee. Figuur 3-16 markeert de drie snapshots die Git gebruikt om de merge te doen in dit geval te doen.
+Dit ziet er iets anders uit dan de `hotfix` merge die je eerder gedaan hebt. In dit geval is je ontwikkelhistorie afgeweken van een eerder punt. Omdat de commit op de branch waar je op zit geen directe voorouder is van de branch waar je in merget, moet Git wat werk doen. In dit geval doet Git een eenvoudige drieweg-merge, gebruikmakend van de twee snapshots waarnaar gewezen wordt door de uiteinden van de branch en de gezamenlijke voorouder van die twee. Figuur 3-16 markeert de drie snapshots die Git in dit geval gebruikt om de merge te doen.
 
 Insert 18333fig0316.png
 Figuur 3-16. Git identificeert automatisch de meest geschikte gezamenlijke voorouder als basis voor het mergen van de branches.
 
-In plaats van de branch verwijzing vooruit te verplaatsen, maakt Git een nieuw snapshot dat het resultaat is van deze drieweg merge en maakt automatisch een nieuwe commit die daar naar wijst (zie Figuur 3-17). Dit wordt een merge-commit genoemd, en is bijzonder in die zin dat het meer dan één ouder heeft.
+In plaats van de branch-verwijzing vooruit te verplaatsen, maakt Git een nieuw snapshot dat het resultaat is van deze drieweg-merge en maakt automatisch een nieuwe commit die daarnaar wijst (zie Figuur 3-17). Dit wordt een merge-commit genoemd, en is bijzonder in die zin dat het meer dan één ouder heeft.
 
-Het is belangrijk om erop te wijzen dat Git de meest geschikte gezamenlijke voorouder bepaalt om te gebruiken als merge basis; dit is anders dan CVS of Subversion (voor versie 1.5), waar het de ontwikkelaar die de merge doet ook degene is die de beste merge basis moest uitzoeken. Dit maakt het mergen in Git een behoorlijk stuk eenvoudiger in vergelijking met deze andere systemen.
+Het is belangrijk om erop te wijzen dat Git de meest geschikte gezamenlijke voorouder bepaalt om te gebruiken als merge basis; dit is anders dan CVS of Subversion (voor versie 1.5), waar de ontwikkelaar die de merge doet ook degene is die de beste merge-basis moest uitzoeken. Dit maakt het mergen in Git een behoorlijk stuk eenvoudiger in vergelijking met deze andere systemen.
 
 Insert 18333fig0317.png
-Figuur 3-17. Git maakt automatisch een nieuw commit object aan die het gemergede werk bevat.
+Figuur 3-17. Git maakt automatisch een nieuw commit-object aan die het gemergede werk bevat.
 
-Nu dat je werk gemerged is, is er geen verdere noodzaak meer voor de `iss53` branch. Je kunt het verwijderen en daarna handmatig de ticket in het ticket-volg systeem sluiten:
+Nu dat je werk gemerged is, is er geen verdere noodzaak meer voor de `iss53`-branch. Je kunt deze verwijderen en daarna handmatig de ticket in het ticket-volgsysteem sluiten:
 
 	$ git branch -d iss53
 
 ### Eenvoudige merge conflicten ###
 
-Af en toe verloopt dit proces niet zo soepel. Als je hetzelfde gedeelte van hetzelfde bestand op een andere manier hebt gewijzigd in twee branches die je merged, dan zal Git niet in staat zijn om ze netjes te mergen. Als je reparatie voor probleem #53 hetzelfde gedeelte van een bestand heeft gewijzigd als de `hotfix`, dan krijg je een merge conflict dat er ongeveer zo uit ziet:
+Af en toe verloopt dit proces niet zo soepel. Als je hetzelfde gedeelte van hetzelfde bestand op een andere manier hebt gewijzigd in twee branches die je merget, dan zal Git niet in staat zijn om ze netjes te mergen. Als je reparatie voor probleem #53 hetzelfde gedeelte van een bestand heeft gewijzigd als de `hotfix`, dan krijg je een merge conflict dat er ongeveer zo uit ziet:
 
 	$ git merge iss53
 	Auto-merging index.html
 	CONFLICT (content): Merge conflict in index.html
 	Automatic merge failed; fix conflicts and then commit the result.
 
-Git heeft geen nieuwe merge commit gemaakt. Het heeft het proces gepauzeerd zolang jij het conflict aan het oplossen bent. Als je wilt zien welke bestanden nog niet zijn gemerged op enig punt na een merge conflict, dan kun je `git status` uitvoeren:
+Git heeft geen nieuwe merge-commit gemaakt. Het heeft het proces gepauzeerd zolang jij het conflict aan het oplossen bent. Als je wilt zien welke bestanden nog niet zijn gemerged op enig punt na een merge conflict, dan kun je `git status` uitvoeren:
 
 	$ git status
 	On branch master
@@ -279,7 +279,7 @@ Git heeft geen nieuwe merge commit gemaakt. Het heeft het proces gepauzeerd zola
 	
 	no changes added to commit (use "git add" and/or "git commit -a")
 
-Alles wat merge conflicten heeft en wat nog niet is opgelost wordt getoond als unmerged. Git voegt standaard conflict-oplossings markeringen toe aan de bestanden die conflicten hebben, zodat je ze handmatig kunt openen en die conflicten kunt oplossen. Je bestand bevat een sectie die er zo ongeveer uit ziet:
+Alles wat merge-conflicten heeft en wat nog niet is opgelost wordt getoond als unmerged. Git voegt standaard conflict-oplossingsmarkeringen toe aan de bestanden die conflicten hebben, zodat je ze handmatig kunt openen en die conflicten kunt oplossen. Je bestand bevat een sectie die er zo ongeveer uit ziet:
 
 	<<<<<<< HEAD
 	<div id="footer">contact : email.support@github.com</div>
@@ -289,14 +289,14 @@ Alles wat merge conflicten heeft en wat nog niet is opgelost wordt getoond als u
 	</div>
 	>>>>>>> iss53
 
-Dit betekent dat de versie in HEAD (jouw master branch, omdat dat degene was dat je uitgecheckt had toen je het merge commando uitvoerde) is het bovenste gedeelte van dat blok (alles boven de `======`), terwijl de versie in je `iss53` branch eruit ziet zoals alles in het onderste gedeelte. Om het conflict op te lossen, moet je één van de twee gedeeltes kiezen of de inhoud zelf mergen. Je zou bijvoorbeeld dit conflict op kunnen lossen door het hele blok met dit te vervangen:
+Dit betekent dat de versie in HEAD (jouw master branch, omdat dat degene was dat je uitgecheckt had toen je het merge-commando uitvoerde) is het bovenste gedeelte van dat blok (alles boven de `======`), terwijl de versie in je `iss53`-branch eruit ziet zoals alles in het onderste gedeelte. Om het conflict op te lossen, moet je één van de twee gedeeltes kiezen of de inhoud zelf mergen. Je zou bijvoorbeeld dit conflict op kunnen lossen door het hele blok met dit te vervangen:
 
 	<div id="footer">
 	please contact us at email.support@github.com
 	</div>
 
 Deze oplossing bevat een stukje uit beide secties, en ik heb de `<<<<<<<`, `=======`, en `>>>>>>>` regels volledig verwijderd. Nadat je elk van deze secties opgelost hebt in elk conflicterend bestand, voer dan `git add` uit voor elk van die bestanden om het als opgelost te markeren. Het bestand stagen markeert het als opgelost in Git.
-Als je een grafische applicatie wil gebruiken om deze problemen op te lossen, kun je `git mergetool` uitvoeren, wat een toepasselijk grafische merge applicatie opstart dat je door de conflicten heen leidt:
+Als je een grafische applicatie wil gebruiken om deze problemen op te lossen, kun je `git mergetool` uitvoeren, wat een toepasselijk grafische merge-applicatie opstart dat je door de conflicten heen leidt:
 
 	$ git mergetool
 
@@ -312,9 +312,9 @@ Als je een grafische applicatie wil gebruiken om deze problemen op te lossen, ku
 	  {remote}: modified file
 	Hit return to start merge resolution tool (opendiff):
 
-Als je een andere dan de standaard merge tool wilt gebruiken (Git koos `opendiff` voor me in dit geval, omdat ik het commando uitvoerde op een Mac), dan kun je alle ondersteunde applicaties opgenoemd zien na "... one of the following tools:". Type de naam van de applicatie die je liever gebruikt. In Hoofdstuk 7 zullen we bespreken hoe je deze standaard waarde voor jouw omgeving kunt wijzigen.
+Als je een andere dan de standaard merge-tool wilt gebruiken (Git koos `opendiff` voor me in dit geval, omdat ik het commando uitvoerde op een Mac), dan kun je alle ondersteunde applicaties opgenoemd zien na "... one of the following tools:". Type de naam van de applicatie die je liever gebruikt. In Hoofdstuk 7 zullen we bespreken hoe je deze standaard waarde voor jouw omgeving kunt wijzigen.
 
-Nadat je de merge applicatie afsluit, vraagt Git je of de merge succesvol was. Als je het script vertelt dat dit het geval is, dan staged dit script het bestand voor je om het als opgelost te markeren.
+Nadat je de merge applicatie afsluit, vraagt Git je of de merge succesvol was. Als je het script vertelt dat dit het geval is, dan staget dit script het bestand voor je om het als opgelost te markeren.
 
 Je kunt `git status` nogmaals uitvoeren om er zeker van te zijn dat alle conflicten opgelost zijn:
 
@@ -325,7 +325,7 @@ Je kunt `git status` nogmaals uitvoeren om er zeker van te zijn dat alle conflic
 	
 	        modified:   index.html
 	
-Als je het daar mee eens bent, en je gecontroleerd hebt dat alles waar conflicten in zat gestaged is, dan kun je `git commit` typen om de merge commit af te ronden. Het commit bericht ziet er standaard ongeveer zo uit:
+Als je het daar mee eens bent, en je gecontroleerd hebt dat alles waar conflicten in zaten gestaged is, dan kun je `git commit` typen om de merge-commit af te ronden. Het commit-bericht ziet er standaard ongeveer zo uit:
 
 	Merge branch 'iss53'
 
@@ -340,9 +340,9 @@ Als je het daar mee eens bent, en je gecontroleerd hebt dat alles waar conflicte
 
 Je kunt dat bericht aanpassen met details over hoe je het conflict opgelost hebt, als je denkt dat dat behulpzaam zal zijn voor anderen die in de toekomst naar deze merge kijken - waarom je hebt gedaan wat je gedaan hebt, als dat niet vanzelfsprekend is.
 
-## Branch beheer ##
+## Branch-beheer ##
 
-Nu heb je wat branches aangemaakt, gemerged, en verwijderd. Laten we eens kijken naar wat branch beheer toepassingen die handig zijn als je vaker branches gaat gebruiken.
+Nu heb je wat branches aangemaakt, gemerged, en verwijderd. Laten we eens kijken naar wat branch-beheer-toepassingen die handig zijn als je vaker branches gaat gebruiken.
 
 Het `git branch` commando doet meer dan alleen branches aanmaken en verwijderen. Als je het zonder argumenten uitvoert, dan krijg je een eenvoudige lijst van de huidige branches:
 
@@ -351,7 +351,7 @@ Het `git branch` commando doet meer dan alleen branches aanmaken en verwijderen.
 	* master
 	  testing
 
-Merk op dat het `*` karakter vooraf gaat aan de `master` branch: het geeft de branch aan dat je op dit moment uitgecheckt hebt. Dit betekent dat als je op dit punt commit, de `master` branch vooruit zal gaan met je nieuwe werk. Om de laatste commit op iedere branch te zien, kun je `git branch -v` uitvoeren:
+Merk op dat het `*` karakter vooraf gaat aan de `master` branch: het geeft de branch aan die je op dit moment uitgecheckt hebt. Dit betekent dat als je op dit punt commit, de `master` branch vooruit zal gaan met je nieuwe werk. Om de laatste commit op iedere branch te zien, kun je `git branch -v` uitvoeren:
 
 	$ git branch -v
 	  iss53   93b412c fix javascript issue
@@ -382,37 +382,37 @@ Als je de branch echt wilt verwijderen en dat werk wilt verliezen, dan kun je he
 
 ## Branch workflows ##
 
-Nu je de basis van het branchen en mergen onder de knie hebt, wat kan of zou je daarmee kunnen doen? In deze paragraaf gaan we een aantal veel voorkomende workflows die deze lichtgewicht branches mogelijk maken behandelen, zodat je kunt besluiten of je ze wilt toepassen in je eigen ontwikkel cyclus.
+Nu je de basis van het branchen en mergen onder de knie hebt, wat kan of zou je daarmee kunnen doen? In deze paragraaf gaan we een aantal veel voorkomende workflows die deze lichtgewicht branches mogelijk maken behandelen, zodat je kunt besluiten of je ze wilt toepassen in je eigen ontwikkelcyclus.
 
-### Lang-lopende branches ###
+### Langlopende branches ###
 
-Omdat Git gebruik maakt van een eenvoudige drieweg merge, is het meerdere keren mergen vanuit een branch in een andere gedurende een langere periode over het algemeen eenvoudig te doen. Dit betekent dat je meerdere branches kunt hebben, die altijd open staan en die je voor verschillende delen van je ontwikkel cyclus gebruikt; je kunt regelmatig vanuit een aantal mergen in andere.
+Omdat Git gebruik maakt van een eenvoudige drieweg-merge, is het meerdere keren mergen vanuit een branch in een andere gedurende een langere periode over het algemeen eenvoudig te doen. Dit betekent dat je meerdere branches kunt hebben, die altijd open staan en die je voor verschillende delen van je ontwikkelcyclus gebruikt; je kunt regelmatig vanuit een aantal mergen in andere.
 
-Veel Git ontwikkelaars hebben een workflow die deze aanpak omarmt, zoals het hebben van alleen volledig stabiele code in hun `master` branch — mogelijk alleen code die is of zal worden vrijgegeven. Ze hebben een andere parallelle branch "develop" of "next" genaamd waarop ze werken of die ze gebruiken om stabiliteit te testen — het is niet noodzakelijkerwijs altijd stabiel, maar zodra het in een stabiele status verkeert, kan het worden gemerged in `master`. Deze wordt gebruikt om topic branches (branches met een korte levensduur, zoals jou eerdere `iss53` branch) te pullen zodra die klaar zijn, om er zich ervan te overtuigen dat alle testen slagen en er geen fouten worden geïntroduceerd.
+Veel Git-ontwikkelaars hebben een workflow die deze aanpak omarmt, zoals het hebben van alleen volledig stabiele code in hun `master` branch — mogelijk alleen code die is of zal worden vrijgegeven. Ze hebben een andere parallelle branch "develop" of "next" genaamd waarop ze werken of die ze gebruiken om stabiliteit te testen — het is niet noodzakelijkerwijs altijd stabiel, maar zodra het in een stabiele status verkeert, kan het worden gemerged in `master`. Deze wordt gebruikt om topic branches (branches met een korte levensduur, zoals jou eerdere `iss53`-branch) te pullen zodra die klaar zijn, om zich ervan te overtuigen dat alle testen slagen en er geen fouten worden geïntroduceerd.
 
-Feitelijk praten we over verwijzingen die worden verplaatst over de lijn van de commits die je maakt. De stabiele branches zijn verder naar achterop in je commit historie, en de splinternieuwe branches zijn verder naar voren in de historie (zie Figuur 3-18).
+Feitelijk praten we over verwijzingen die worden verplaatst over de lijn van de commits die je maakt. De stabiele branches zijn verder naar achterop in je commit-historie, en de splinternieuwe branches zijn verder naar voren in de historie (zie Figuur 3-18).
 
 Insert 18333fig0318.png
-Figuur 3-18. Meer stabiele branches zijn over het algemeen verder naar achter in de commit historie.
+Figuur 3-18. Meer stabiele branches zijn over het algemeen verder naar achter in de commit-historie.
 
-Ze zijn misschien makkelijker voor te stellen als werk silo's, waar sets van commits stapsgewijs naar een meer stabiele silo worden gepromoveerd als ze volledig getest zijn (zie Figuur 3-19).
+Ze zijn misschien makkelijker voor te stellen als werksilo's, waar sets van commits stapsgewijs naar een meer stabiele silo worden gepromoveerd als ze volledig getest zijn (zie Figuur 3-19).
 
 Insert 18333fig0319.png
 Figuur 3-19. Het kan handig zijn om je branches voor te stellen als silo's.
 
-Je kunt dit blijven doen voor elk niveau van stabiliteit. Sommige grotere projecten hebben ook een `proposed` of `pu` (proposed updates) branch die branches geïntegreerd heeft die wellicht nog niet klaar zijn om in de `next` of `master` branch te gaan. Het idee erachter is dat de branches op verschillende niveaus van stabiliteit zitten. Zodra ze een meer stabiel niveau bereiken, worden ze in de branch boven hen gemerged.
+Je kunt dit blijven doen voor elk niveau van stabiliteit. Sommige grotere projecten hebben ook een `proposed` of `pu` (proposed updates) branch die branches geïntegreerd heeft die wellicht nog niet klaar zijn om in de `next` of `master` branch te gaan. Het idee erachter is dat de branches op verschillende niveaus van stabiliteit zitten. Zodra ze een stabieler niveau bereiken, worden ze in de branch boven hen gemerged.
 Nogmaals, het hebben van langlopende branches is niet noodzakelijk, maar het helpt vaak wel; in het bijzonder als je te maken hebt met zeer grote of complexe projecten.
 
 ### Topic branches ###
 
 Topic branches zijn nuttig in projecten van elke grootte. Een topic branch is een kortlopende branch die je maakt en gebruikt om een specifieke functie te realiseren of daaraan gerelateerd werk te doen. Dit is iets wat je waarschijnlijk nooit eerder met een VCS gedaan hebt, omdat het over het algemeen te duur is om branches aan te maken en te mergen. Maar in Git is het niet ongebruikelijk om meerdere keren per dag branches aan te maken, daarop te werken, en ze te verwijderen.
 
-Je zag dit in de vorige paragraaf met de `iss53` en `hotfix` branches die je gemaakt had. Je hebt een aantal commits op ze gedaan en ze meteen verwijderd nadat je ze gemerged had in je hoofd branch. Deze techniek stelt je in staat om snel en volledig van context te veranderen — omdat je werk is onderverdeeld in silo's waar alle wijzigingen in die branch te maken hebben met dat onderwerp, is het makkelijker te zien wat er is gebeurd tijdens een code review en dergelijke. Je kunt de wijzigingen daar minuten-, dagen- of maandenlang bewaren, en ze mergen als ze er klaar voor zijn, ongeacht de volgorde waarin ze gemaakt of aan gewerkt zijn.
+Je zag dit in de vorige paragraaf met de `iss53` en `hotfix` branches die je gemaakt had. Je hebt een aantal commits op ze gedaan en ze meteen verwijderd nadat je ze gemerged had in je hoofd-branch. Deze techniek stelt je in staat om snel en volledig van context te veranderen — omdat je werk is onderverdeeld in silo's waar alle wijzigingen in die branch te maken hebben met dat onderwerp, is het makkelijker te zien wat er is gebeurd tijdens een code review en dergelijke. Je kunt de wijzigingen daar minuten-, dagen- of maandenlang bewaren, en ze mergen als ze er klaar voor zijn, ongeacht de volgorde waarin ze gemaakt zijn of er aan gewerkt is.
 
-Neem als voorbeeld een situatie waarbij wat werk gedaan wordt (op `master`), er wordt een branche gemaakt voor een probleem (`iss91`) en daar wordt wat aan gewerkt, er wordt een tweede branch gemaakt om op een andere manier te proberen hetzelfde op te lossen (`iss91v2`); weer even wordt teruggegaan naar de master branch om daar een tijdje te werken, en dan vanaf daar wordt gebrancht om wat werk te doen waarvan je niet zeker weet of het wel zo'n slim idee is (`dumbidea` branch). Je commit historie zal er uit zien als Figuur 3-20.
+Neem als voorbeeld een situatie waarbij wat werk gedaan wordt (op `master`), er wordt een branche gemaakt voor een probleem (`iss91`) en daar wordt wat aan gewerkt, er wordt een tweede branch gemaakt om op een andere manier te proberen hetzelfde op te lossen (`iss91v2`); weer even wordt teruggegaan naar de master branch om daar een tijdje te werken, en dan vanaf daar wordt gebrancht om wat werk te doen waarvan je niet zeker weet of het wel zo'n slim idee is (`dumbidea` branch). Je commit-historie zal eruitzien als Figuur 3-20.
 
 Insert 18333fig0320.png
-Figuur 3-20. Je commit geschiedenis met meerdere topic branches.
+Figuur 3-20. Je commit-geschiedenis met meerdere topic branches.
 
 Laten we zeggen dat je besluit dat je de tweede oplossing voor je probleem het beste vindt (`iss91v2`), en je hebt de `dumbidea` branch aan je collega's laten zien en het blijkt geniaal te zijn. Je kunt dan de oorspronkelijke `iss91` weggooien (waardoor je commits C5 en C6 kwijt raakt), en de andere twee mergen. Je historie ziet er dan uit als Figuur 3-21.
 
@@ -423,34 +423,34 @@ Het is belangrijk om te beseffen dat tijdens al deze handelingen, al deze branch
 
 ## Remote branches ##
 
-Remote branches zijn referenties naar de staat van de branches op remote repositories. Ze zijn lokale branches die jij niet kunt verplaatsen; ze worden automatisch verplaatst zodra je er netwerk communicatie plaatsvindt. Remote branches gedragen zich als boekenleggers om je eraan te helpen herinneren wat de staat van de branches was op je remote repositories toen je voor het laatst met ze in contact was.
+Remote branches zijn referenties naar de staat van de branches op remote repositories. Ze zijn lokale branches die jij niet kunt verplaatsen; ze worden automatisch verplaatst zodra er netwerkcommunicatie plaatsvindt. Remote branches gedragen zich als boekenleggers om je eraan te helpen herinneren wat de staat van de branches was op je remote repositories toen je voor het laatst met ze in contact was.
 
-Ze hebben de vorm `(remote)/(branch)`. Bijvoorbeeld, als je wil zien hoe de `master` branch op je `origin` de laatste keer dat je er mee communiceerde er uit zag, dan zal je de `origin/master` branch moeten bekijken. Als je samen met een partner aan het werk bent met een probleem en zij heeft een `iss53` branch gepushed, zou je je een eigen lokale `iss53` kunnen hebben, maar de branch op de server zal wijzen naar de commit op `origin/iss53`.
+Ze hebben de vorm `(remote)/(branch)`. Bijvoorbeeld, als je wil zien hoe de `master`-branch op je `origin` de laatste keer dat je er mee communiceerde eruitzag, dan zal je de `origin/master`-branch moeten bekijken. Als je samen met een partner aan het werk bent met een probleem en zij heeft een `iss53`-branch gepushed, zou je je een eigen lokale `iss53` kunnen hebben, maar de branch op de server zal wijzen naar de commit op `origin/iss53`.
 
-Dit kan wat verwarrend zijn, dus laten we eens naar een voorbeeld kijken. Stel dat je een Git server op je netwerk hebt op `git.ourcompany.com`. Als je hiervan cloned dan wordt die door Git automatisch `origin` voor je genoemd, Git haalt alle gegevens binnen, maakt een verwijzing naar waar de `master` branch is en noemt dat lokaal `origin/master`, en deze kan je niet verplaatsen. Git geeft je ook een eigen `master` branch, beginnend op dezelfde plaats als de `master` branch van origin, zodat je iets hebt om vanaf te werken (zie Figuur 3-22).
+Dit kan wat verwarrend zijn, dus laten we eens naar een voorbeeld kijken. Stel dat je een Git-server op je netwerk hebt op `git.ourcompany.com`. Als je hiervan clonet dan wordt die door Git automatisch `origin` voor je genoemd, Git haalt alle gegevens binnen, maakt een verwijzing naar waar de `master`-branch is en noemt dat lokaal `origin/master`, en deze kan je niet verplaatsen. Git geeft je ook een eigen `master`-branch, beginnend op dezelfde plaats als de `master`-branch van origin, zodat je iets hebt om vanaf te werken (zie Figuur 3-22).
 
 Insert 18333fig0322.png
-Figuur 3-22. Een Git clone geeft je een eigen master branch en origin/master wijzend naar de master branch van origin.
+Figuur 3-22. Een Git clone geeft je een eigen `master`-branch en `origin/master` wijzend naar de `master`-branch van `origin`.
 
-Als je wat werk doet op je lokale master branch, en in de tussentijd pusht iemand anders iets naar `git.ourcompany.com` waardoor die master branch wordt vernieuwd, dan zijn jullie histories verschillend vooruit geschoven. En zolang je geen contact hebt met de origin server, zal jouw `origin/master` verwijzing niet verplaatsen (zie Figuur 3-23).
+Als je wat werk doet op je lokale `master`-branch, en in de tussentijd pusht iemand anders iets naar `git.ourcompany.com` waardoor die `master`branch wordt vernieuwd, dan zijn jullie histories verschillend vooruit geschoven. En zolang je geen contact hebt met de origin server, zal jouw `origin/master` verwijzing niet verplaatsen (zie Figuur 3-23).
 
 Insert 18333fig0323.png
 Figuur 3-23. Lokaal werken terwijl iemand anders naar je remote server pusht laat elke historie anders vooruit gaan.
 
-Om je werk te synchroniseren, voer je een `git fetch origin` commando uit. Dit commando bekijkt welke server origin is (in dit geval is het `git.ourcompany.com`), haalt gegevens er vanaf die je nog niet hebt en vernieuwt je lokale database, waarbij je `origin/master` verwijzing naar zijn nieuwe positie verplaatst wordt die meer up-to-date is (zie Figuur 3-24).
+Om je werk te synchroniseren, voer je een `git fetch origin` commando uit. Dit commando bekijkt welke server origin is (in dit geval is het `git.ourcompany.com`), haalt gegevens er vanaf die je nog niet hebt en vernieuwt je lokale database, waarbij je `origin/master`-verwijzing naar zijn nieuwe positie verplaatst wordt die meer up-to-date is (zie Figuur 3-24).
 
 Insert 18333fig0324.png
 Figuur 3-24. Het git fetch commando vernieuwt je remote referenties.
 
-Om het hebben van meerdere remote servers te tonen en hoe remote branches voor die remote projecten er uit zien, zullen we aannemen dat je nog een interne Git server hebt die alleen wordt gebruikt voor ontwikkeling gedaan door een van je sprint teams. Deze server bevindt zich op `git.team1.ourcompany.com`. Je kunt het als een nieuwe remote referentie toevoegen aan het project waar je nu aan werkt door het `git remote add` commando uit te voeren, zoals we behandeld hebben in Hoofdstuk 2. Noem deze remote `teamone`, wat jouw afkorting voor die hele URL wordt (zie Figuur 3-25).
+Om het hebben van meerdere remote servers te tonen en hoe remote branches voor die remote projecten eruitzien, zullen we aannemen dat je nog een interne Git-server hebt die alleen wordt gebruikt voor ontwikkeling gedaan door een van je sprint teams. Deze server bevindt zich op `git.team1.ourcompany.com`. Je kunt het als een nieuwe remote referentie toevoegen aan het project waar je nu aan werkt door het `git remote add` commando uit te voeren, zoals we behandeld hebben in Hoofdstuk 2. Noem deze remote `teamone`, wat jouw afkorting voor die hele URL wordt (zie Figuur 3-25).
 
 Insert 18333fig0325.png
 Figuur 3-25. Een andere server als een remote toevoegen.
 
-Nu kun je `git fetch teamone` uitvoeren om alles op te halen dat wat de `teamone` remote server heeft en jij nog niet. Omdat die server een subset heeft van de gegevens die jouw `origin` server op dit moment heeft, haalt Git geen gegevens op maar maakt een remote branch genaamd `teamone/master` aan en laat die wijzen naar de commit die `teamone` heeft als zijn `master` branch (zie Figuur 3-26).
+Nu kun je `git fetch teamone` uitvoeren om alles op te halen dat wat de `teamone` remote server heeft en jij nog niet. Omdat die server een subset heeft van de gegevens die jouw `origin` server op dit moment heeft, haalt Git geen gegevens op maar maakt een remote branch genaamd `teamone/master` aan en laat die wijzen naar de commit die `teamone` heeft als zijn `master`-branch (zie Figuur 3-26).
 
 Insert 18333fig0326.png
-Figuur 3-26. Je krijgt lokaal een referentie naar de master branch positie van teamone.
+Figuur 3-26. Je krijgt lokaal een referentie naar de `master`-branch-positie van teamone.
 
 ### Pushen ###
 
@@ -468,7 +468,7 @@ Als je een branch genaamd `serverfix` hebt waar je met anderen aan wilt werken,
 
 Dit is een beetje de bocht afsnijden. Git zal de `serverfix` branchnaam automatisch expanderen naar `refs/heads/serverfix:refs/heads/serverfix`, wat staat voor "Neem mijn lokale serverfix branch en push die om de serverfix branch van de remote te vernieuwen.". We zullen het `refs/heads` gedeelte gedetaileerd behandelen in Hoofdstuk 9, maar je kunt het normaalgesproken weglaten. Je kun ook `git push origin serverfix:serverfix` doen, wat hetzelfde doet. Dit staat voor "Neem mijn serverfix en maak het de serverfix van de remote." Je kunt dit formaat gebruiken om een lokale branch te pushen naar een remote branch die anders heet. Als je niet wil dat het `serverfix` heet aan de remote kant, kan je in plaats daarvan `git push origin serverfix:awesomebranch` gebruiken om je lokale `serverfix` branch naar de `awesomebranch` op het remote project te pushen.
 
-De volgende keer dat één van je medewerkers van de server fetched zal deze een referentie krijgen naar de versie van `serverfix` op de server, onder de remote branch `origin/serverfix`:
+De volgende keer dat één van je medewerkers van de server fetchet zal deze een referentie krijgen naar de versie van `serverfix` op de server, onder de remote branch `origin/serverfix`:
 
 	$ git fetch origin
 	remote: Counting objects: 20, done.
@@ -492,23 +492,23 @@ Dit maakt een lokale branch aan waar je op kunt werken, die begint met waar `ori
 
 Een lokale branch uitchecken van een remote branch creëert automatisch een zogenaamde _tracking branch_ (_volg branch_). Tracking branches zijn lokale branches die een directe releatie met een remote branch hebben. Als je op een tracking branch zit en `git push` typt, dat weet Git automatisch naar welke server en branch hij moet pushen. En, als je op een van die branches zit zal het uitvoeren van `git pull` alle remote referenties ophalen en automatisch de corresponderende remote branch erin mergen.
 
-Als je een repository cloned, zal het over het algemeen automatisch een `master` branch aanmaken die `origin/master` trackt. Daarom werken `git push` en `git pull` zo uit het doosje, zonder verdere argumenten. Maar je kan ook andere tracking branches aanmaken als je dat wilt, andere die niet branches tracken op `origin` en niet de `master` branch tracken. Een eenvoudig voorbeeld is wat je zojuist gezien hebt: `git checkout -b [branch] [remotenaam]/[branch]` uitvoeren. Als je Git versie 1.6.2 of nieuwer hebt, kun je ook de `--track` afkorting gebruiken:
+Als je een repository clonet, zal het over het algemeen automatisch een `master`-branch aanmaken die `origin/master` trackt. Daarom werken `git push` en `git pull` zo uit het doosje, zonder verdere argumenten. Maar je kan ook andere tracking branches aanmaken als je dat wilt, andere die niet branches tracken op `origin` en niet de `master`-branch tracken. Een eenvoudig voorbeeld is wat je zojuist gezien hebt: `git checkout -b [branch] [remotenaam]/[branch]` uitvoeren. Als je Git versie 1.6.2 of nieuwer hebt, kun je ook de `--track` afkorting gebruiken:
 
 	$ git checkout --track origin/serverfix
 	Branch serverfix set up to track remote branch serverfix from origin.
 	Switched to a new branch 'serverfix'
 
-Om een lokale branch te maken met een andere naam dan de remote branch, kun je simpelweg de eerste variant met een andere lokale branch naam gebruiken:
+Om een lokale branch te maken met een andere naam dan de remote branch, kun je simpelweg de eerste variant met een andere lokale branchnaam gebruiken:
 
 	$ git checkout -b sf origin/serverfix
 	Branch sf set up to track remote branch serverfix from origin.
 	Switched to a new branch 'sf'
 
-Nu zal je lokale `sf` branch automatisch pullen en pushen van origin/serverfix.
+Nu zal je lokale `sf`-branch automatisch pullen en pushen van origin/serverfix.
 
 ### Remote branches verwijderen ###
 
-Stel dat je klaar bent met een remote branch - zeg maar, jij en je medewerkers zijn klaar met een feature en het hebben gemerged in de `master` branch van de remote (of welke branch jullie stabiele code ook in zit). Dan kun je een remote branch verwijderen door de nogal botte syntax `git push [remotenaam] :[branch]` te gebruiken. Als je de `serverfix` branch van de server wilt verwijderen, dan voer je het volgende uit:
+Stel dat je klaar bent met een remote branch - zeg maar, jij en je medewerkers zijn klaar met een feature en hebben het gemerged in de `master`-branch van de remote (of welke branch jullie stabiele code ook in zit). Dan kun je een remote branch verwijderen door de nogal botte syntax `git push [remotenaam] :[branch]` te gebruiken. Als je de `serverfix` branch van de server wilt verwijderen, dan voer je het volgende uit:
 
 	$ git push origin :serverfix
 	To git@github.com:schacon/simplegit.git
@@ -518,7 +518,7 @@ Poef. Geen branch meer op je server. Je zult deze pagina wel een ezelsoortje wil
 
 ## Rebasen ##
 
-In Git zijn er twee hoofdmanieren om wijzigingen te integreren van de ene branch in een andere: de `merge` en de `rebase`. In deze paragraaf ga je leren wat rebasen is, hoe je dat moet doen, waarom het een zeer bijzondere stukje gereedschap is en in welke gevallen je het niet wilt gebruiken.
+In Git zijn er twee hoofdmanieren om wijzigingen te integreren van de ene branch in een andere: de `merge` en de `rebase`. In deze paragraaf ga je leren wat rebasen is, hoe je dat moet doen, waarom het een zeer bijzonder stukje gereedschap is en in welke gevallen je het niet wilt gebruiken.
 
 ### De simpele rebase ###
 
@@ -527,21 +527,21 @@ Als je het eerdere voorbeeld van de Merge-paragraaf erop terugslaat (zie Figuur
 Insert 18333fig0327.png
 Figuur 3-27. Je initiële uiteengelopen historie.
 
-De simpelste manier om de branches te integreren, zoals we al hebben besproken, is het `merge` commando. Het voert een drieweg merge uit tussen de twee laatste snapshots van de branches (C3 en C4), en de meest recente gezamenlijke voorouder van die twee (C2), en maakt een nieuw snapshot (en commit) zoals getoond in Figuur 3-28.
+De simpelste manier om de branches te integreren, zoals we al hebben besproken, is het `merge` commando. Het voert een drieweg-merge uit tussen de twee laatste snapshots van de branches (C3 en C4), en de meest recente gezamenlijke voorouder van die twee (C2), en maakt een nieuw snapshot (en commit) zoals getoond in Figuur 3-28.
 
 Insert 18333fig0328.png
-Figuur 3-28. Een branch mergen om de uiteengelopen werk histories te integreren.
+Figuur 3-28. Een branch mergen om de uiteengelopen werkhistories te integreren.
 
 Maar, er is nog een manier: je kunt de patch van de wijziging die werd geïntroduceerd in C3 pakken en die opnieuw toepassen op C4. In Git, wordt dit _rebasen_ genoemd. Met het `rebase` commando kan je alle wijzigingen pakken die zijn gecommit op de ene branch, en ze opnieuw afspelen op een andere.
 
-In dit voorbeeld, zou je het volgende uitvoeren:
+In dit voorbeeld zou je het volgende uitvoeren:
 
 	$ git checkout experiment
 	$ git rebase master
 	First, rewinding head to replay your work on top of it...
 	Applying: added staged command
 
-Het gebeurt door naar de gezamenlijke voorouder van de twee branches te gaan (degene waar je op zit en degene waar je op rebased), de diff te nemen die geïntroduceerd is voor elke losse commit op de branch waar je op zit, die diffs in tijdelijke bestanden te bewaren, de huidige branch terug te zetten naar dezelfde commit als de branch waar je op rebased, en uiteindelijk elke diff om de beurt te applyen, Figuur 3-29 toont dit proces.
+Het gebeurt door naar de gezamenlijke voorouder van de twee branches te gaan (degene waar je op zit en degene waar je op rebaset), de diff te nemen die geïntroduceerd is voor elke losse commit op de branch waar je op zit, die diffs in tijdelijke bestanden te bewaren, de huidige branch terug te zetten naar dezelfde commit als de branch waar je op rebaset, en uiteindelijk elke diff om de beurt te applyen, Figuur 3-29 toont dit proces.
 
 Insert 18333fig0329.png
 Figuur 3-29. De wijzigingen die geïntroduceerd zijn in C3 rebasen op C4.
@@ -553,22 +553,22 @@ Figuur 3-30. De master branch Fast-forwarden.
 
 Nu is het snapshot waar C3' naar wijst precies dezelfde als degene waar C5 naar wees in het merge voorbeeld. Er zit geen verschil in het eindresultaat van de integratie, maar rebasen zorgt voor een duidelijkere historie. Als je de log van een branch die gerebased is bekijkt, ziet het eruit als een lineaire historie: het lijkt alsof al het werk in serie heeft plaatsgevonden, zelfs wanneer het in werkelijkheid parallel eraan gedaan is.
 
-Vaak zal je dit doen om er zeker van te zijn dat je commits netjes toegepast kunnen worden op een remote branch - misschien in een project waar je aan probeert bij te dragen, maar dat je niet beheert. In dit geval zou je het werk in een branch uitvoeren en dan je werk rebasen op `origin/master` als je klaar ben om je patches in te sturen naar het hoofd project. Op die manier hoeft de beheerder geen integratie werk te doen - gewoon een fast-forward of een schone apply.
+Vaak zal je dit doen om er zeker van te zijn dat je commits netjes toegepast kunnen worden op een remote branch - misschien in een project waar je aan probeert bij te dragen, maar dat je niet beheert. In dit geval zou je het werk in een branch uitvoeren en dan je werk rebasen op `origin/master` als je klaar ben om je patches in te sturen naar het hoofdproject. Op die manier hoeft de beheerder geen integratiewerk te doen - gewoon een fast-forward of een schone apply.
 
 Merk op dat de snapshot waar de laatste commit op het eind naar wijst, of het de laatste van de gerebasede commits voor een rebase is of de laatste merge commit na een merge, detzelfde snapshot is - alleen de historie is verschillend. Rebasen speelt veranderingen van een werklijn opnieuw af op een andere, in de volgorde waarin ze gemaakt zijn, terwijl mergen de eindresultaten pakt en die samenvoegt.
 
 ### Interessantere rebases ###
 
-Je kunt je rebase ook opnieuw laten afspelen op iets anders dan de rebase branch. Pak een historie zoals in Figuur 3-31, bijvoorbeeld. Je hebt een topic branch afgesplitst (`server`) om wat server-kant functionaliteit toe te voegen aan je project en toen een gecommit. Daarna heb je daar vanaf gebranched om de client-kant wijzigingen te doen (`client`) en een paar keer gecommit. Als laatste, ben je teruggegaan naar je server branch en hebt nog een paar commits gedaan.
+Je kunt je rebase ook opnieuw laten afspelen op iets anders dan de rebase branch. Pak een historie zoals in Figuur 3-31, bijvoorbeeld. Je hebt een topic branch afgesplitst (`server`) om wat server-kant functionaliteit toe te voegen aan je project en toen een keer gecommit. Daarna heb je daar vanaf gebranched om de client-kant wijzigingen te doen (`client`) en een paar keer gecommit. Als laatste, ben je teruggegaan naar je server branch en hebt nog een paar commits gedaan.
 
 Insert 18333fig0331.png
 Figuur 3-31. Een historie met een topic branch vanaf een andere topic branch.
 
-Stel nu, je besluit dat je de client-kant wijzigingen wilt mergen in je hoofdlijn voor een release, maar je wilt de server-kant wijzigingen nog vasthouden totdat het verder getest is. Je kunt de wijzigingen van client pakken, die nog niet op server zitten (C8 en C9) en die opnieuw afspelen op je master branch door de `--onto` optie te gebruiken van `git rebase`:
+Stel nu, je besluit dat je de client-kant wijzigingen wilt mergen in je hoofdlijn voor een release, maar je wilt de server-kant wijzigingen nog vasthouden totdat het verder getest is. Je kunt de wijzigingen van `client` pakken, die nog niet op `server` zitten (C8 en C9) en die opnieuw afspelen op je `master`-branch door de `--onto` optie te gebruiken van `git rebase`:
 
 	$ git rebase --onto master server client
 
-Dit zegt in feite, "Check de client branch uit, verzamel de patches van de gezamenlijke voorouder van de `client` en de `server` branches, en speel die opnieuw af op `master`." Het is een beetje ingewikkeld, maar het resultaat, getoond in Figuur 3-32, is erg prettig.
+Dit zegt in feite, "Check de `client`-branch uit, verzamel de patches van de gezamenlijke voorouder van de `client` en de `server` branches, en speel die opnieuw af op `master`." Het is een beetje ingewikkeld, maar het resultaat, getoond in Figuur 3-32, is erg prettig.
 
 Insert 18333fig0332.png
 Figuur 3-32. Een topic branch rebasen vanaf een andere topic branch.
@@ -611,14 +611,14 @@ Ahh, maar de zegeningen van rebasen zijn niet geheel zonder nadelen, samengevat
 
 Als je die richtlijn volgt, kan je weinig gebeuren. Als je dat niet doet, zullen mensen je haten en je zult door vrienden en familie uitgehoond worden.
 
-Als je spullen rebased, zet je bestaande commits buitenspel en maak je nieuwe aan die vergelijkbaar zijn maar anders. Als je commits ergens pusht en andere pullen deze en baseren daar werk op, en vervolgens herschrijf je die commits met `git rebase` en pusht deze weer, dan zullen je medewerkers hun werk opnieuw moeten mergen en zal het allemaal erg vervelend worden als je hun werk probeert te pullen in het jouwe.
+Als je spullen rebaset, zet je bestaande commits buitenspel en maak je nieuwe aan die vergelijkbaar zijn maar anders. Als je commits ergens pusht en andere pullen deze en baseren daar werk op, en vervolgens herschrijf je die commits met `git rebase` en pusht deze weer, dan zullen je medewerkers hun werk opnieuw moeten mergen en zal het allemaal erg vervelend worden als je hun werk probeert te pullen in het jouwe.
 
-Laten we eens kijken naar een voorbeeld hoe werk rebasen dat je publiek gemaakt hebt problemen kan veroorzaken. Stel dat je van een centrale server cloned en dan daar wat werk aan doet. Je commit historie ziet er uit als Figuur 3-36.
+Laten we eens kijken naar een voorbeeld hoe werk rebasen dat je publiek gemaakt hebt problemen kan veroorzaken. Stel dat je van een centrale server clonet en dan daar wat werk aan doet. Je commit-historie ziet eruit als Figuur 3-36.
 
 Insert 18333fig0336.png
 Figuur 3-36. Clone een repository, en doe wat werk daarop.
 
-Nu doet iemand anders wat meer werk wat een merge bevat, en pusht dat werk naar de centrale server. Je fetcht dat en merged de nieuwe remote branch in jouw werk, zodat je historie er uit ziet zoals Figuur 3-37.
+Nu doet iemand anders wat meer werk wat een merge bevat, en pusht dat werk naar de centrale server. Je fetcht dat en merget de nieuwe remote branch in jouw werk, zodat je historie eruitziet zoals Figuur 3-37.
 
 Insert 18333fig0337.png
 Figuur 3-37. Haal meer commits op, en merge ze in je werk.
@@ -628,12 +628,12 @@ Daarna, beslist de persoon die het werk gepusht heeft om erop terug te komen en
 Insert 18333fig0338.png
 Figuur 3-38. Iemand pusht gerebasede commits, daarbij commits buitenspel zettend waar jij werk op gebaseerd hebt.
 
-Nu moet je dit werk opnieuw mergen, terwijl je dat al gedaan hebt. Rebasen verandert de SHA-1 hashes van deze commits, dus voor Git zien ze er uit als nieuwe commits, terwijl je in feite het C4 werk al in je historie hebt (zie Figuur 3-39).
+Nu moet je dit werk opnieuw mergen, terwijl je dat al gedaan hebt. Rebasen verandert de SHA-1 hashes van deze commits, dus voor Git zien ze eruit als nieuwe commits, terwijl je in feite het C4 werk al in je historie hebt (zie Figuur 3-39).
 
 Insert 18333fig0339.png
 Figuur 3-39. Je merget hetzelfde werk opnieuw in een nieuwe merge commit.
 
-Je moet dat werk op een gegeven moment mergen, zodat je in de toekomst bij kunt blijven met de andere ontwikkelaar. Nadat je dat gedaan hebt, zal je history zowel de C4 als de C4' commits bevatten, die verschillende SHA-1 hashes hebben, maar die hetzelfde werk introduceren en hetzelfde commit bericht hebben. Wanneer je een `git log` uitvoert als je historie er zo uitziet, dan zul je twee commits zien die dezelfde auteur, datum en bericht hebben, wat alleen maar verwarring geeft. Daarnaast zal je, als je deze historie pusht naar de server, al die gerebasede commits opnieuw introduceren op de centrale server, wat mensen nog meer kan verwarren.
+Je moet dat werk op een gegeven moment mergen, zodat je in de toekomst bij kunt blijven met de andere ontwikkelaar. Nadat je dat gedaan hebt, zal je history zowel de C4 als de C4' commits bevatten, die verschillende SHA-1 hashes hebben, maar die hetzelfde werk introduceren en hetzelfde commit-bericht hebben. Wanneer je een `git log` uitvoert als je historie er zo uitziet, dan zul je twee commits zien die dezelfde auteur, datum en bericht hebben, wat alleen maar verwarring geeft. Daarnaast zal je, als je deze historie pusht naar de server, al die gerebasede commits opnieuw introduceren op de centrale server, wat mensen nog meer kan verwarren.
 
 Als je rebasen behandelt als een manier om commits op te ruimen en ze te bewerken voordat je ze pusht, en als je alleen commits rebaset die nog nooit publiekelijk beschikbaar zijn geweest, dan zal er niets aan de hand zijn. Als je commits rebaset die al publiekelijk gepusht zijn, en mensen kunnen werk gebaseerd hebben op die commits, bereid je dan maar voor op een aantal frustrerende problemen.
 

From 1faddc07d927ef77ba332508bb442bdbb44eb6e0 Mon Sep 17 00:00:00 2001
From: Junle Li <lijunle@gmail.com>
Date: Thu, 3 Apr 2014 22:38:14 +0800
Subject: [PATCH 276/690] [zh] translate some English paragraphs in chapter 2.

---
 zh/02-git-basics/01-chapter2.markdown | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/zh/02-git-basics/01-chapter2.markdown b/zh/02-git-basics/01-chapter2.markdown
index b59978ecc..2a95c60f4 100644
--- a/zh/02-git-basics/01-chapter2.markdown
+++ b/zh/02-git-basics/01-chapter2.markdown
@@ -497,9 +497,9 @@ A `**/` pattern is available in Git since version 1.8.2.
 	-end
 	\ No newline at end of file
 
-This option displays the same information but with a diff directly following each entry. This is very helpful for code review or to quickly browse what happened during a series of commits that a collaborator has added.
+该选项除了显示基本信息之外，还在附带了每次 commit 的变化。当进行代码审查，或者快速浏览某个搭档提交的 commit 的变化的时候，这个参数就非常有用了。
 
-Sometimes it's easier to review changes on the word level rather than on the line level. There is a `--word-diff` option available in Git, that you can append to the `git log -p` command to get word diff instead of normal line by line diff. Word diff format is quite useless when applied to source code, but it comes in handy when applied to large text files, like books or your dissertation. Here is an example:
+某些时候，单词层面的对比，比行层面的对比，更加容易观察。Git 提供了 `--word-diff` 选项。我们可以将其添加到 `git log -p` 命令的后面，从而获取单词层面上的对比。在程序代码中进行单词层面的对比常常是没什么用的。不过当你需要在书籍、论文这种很大的文本文件上进行对比的时候，这个功能就显出用武之地了。下面是一个简单的例子：
 
 	$ git log -U1 --word-diff
 	commit ca82a6dff817ec66f44342007202690a93763949
@@ -517,9 +517,9 @@ Sometimes it's easier to review changes on the word level rather than on the lin
 	    s.version   =   [-"0.1.0"-]{+"0.1.1"+}
 	    s.author    =   "Scott Chacon"
 
-As you can see, there is no added and removed lines in this output as in a normal diff. Changes are shown inline instead. You can see the added word enclosed in `{+ +}` and removed one enclosed in `[- -]`. You may also want to reduce the usual three lines context in diff output to only one line, as the context is now words, not lines. You can do this with `-U1` as we did in the example above.
+如你所见，这里并没有平常看到的添加行或者删除行的信息。这里的对比显示在行间。新增加的单词被 `{+ +}` 括起来，被删除的单词被 `[- -]` 括起来。在进行单词层面的对比的时候，你可能希望上下文（ context ）行数从默认的 3 行，减为 1 行，那么可以使用 `-U1` 选项。上面的例子中，我们就使用了这个选项。 
 
-在做代码审查，或者要快速浏览其他协作者提交的更新都作了哪些改动时，就可以用这个选项。此外，还有许多摘要选项可以用，比如 `--stat`，仅显示简要的增改行数统计：
+另外，`git log` 还提供了许多摘要选项可以用，比如 `--stat`，仅显示简要的增改行数统计：
 
 	$ git log --stat
 	commit ca82a6dff817ec66f44342007202690a93763949

From fc20c0c06dfe27ed779361497cad0ec9e321f8a3 Mon Sep 17 00:00:00 2001
From: Junle Li <lijunle@gmail.com>
Date: Tue, 8 Apr 2014 22:36:37 +0800
Subject: [PATCH 277/690] [zh] Translate Chapter 7

---
 zh/07-customizing-git/01-chapter7.markdown | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/zh/07-customizing-git/01-chapter7.markdown b/zh/07-customizing-git/01-chapter7.markdown
index e2d361fed..8880500e2 100644
--- a/zh/07-customizing-git/01-chapter7.markdown
+++ b/zh/07-customizing-git/01-chapter7.markdown
@@ -301,13 +301,13 @@ Git默认情况下不会在推送期间检查所有对象的一致性。虽然
 
 	*.pbxproj -crlf -diff
 
-现在，Git 会尝试转换和修正CRLF（回车换行）问题，也不会当你在项目中运行git show或git diff时，比较不同的内容。在Git 1.6及之后的版本中，可以用一个宏代替`-crlf -diff`：
+现在，Git 会尝试转换和修正CRLF（回车换行）问题，也不会当你在项目中运行`git show`或`git diff`时，比较不同的内容。在Git 1.6及之后的版本中，可以用一个宏代替`-crlf -diff`：
 
 	*.pbxproj binary
 
 #### 比较二进制文件 ####
 
-在 Git 中，你能利用 Git 属性来有效地比较二进制文件。可以设置 Git 把二进制数据转换成文本格式，用通常的diff来比较。
+你可以使用 Git 属性来有效地比较两个二进制文件（binary files，译注：指非文本文件）。那么第一步要做的是，告诉 Git 怎么把你的二进制文件转化为纯文本格式，从而让普通的 diff 命令可以进行文本对比。但是，我们怎么把*二进制文件*转化为文本呢？最好的解决方法是找到一个转换工具帮助我们进行转化。但是，大部分的二进制文件不能表示为可读的文本，例如语音文件就很难转化为文本文件。如果你遇到这些情况，比较简单的解决方法是从这些二进制文件中获取简介，或者元数据。虽然这些数据并不能完全描述一个二进制文件，但是这总能表明一些情况。
 
 We'll make use of the both described approaches to get usable diffs for some widely used binary formats.
 

From be1132faf1fd8c4db1ce72c4c23fdfca47fe141a Mon Sep 17 00:00:00 2001
From: Junle Li <lijunle@gmail.com>
Date: Tue, 8 Apr 2014 23:18:51 +0800
Subject: [PATCH 278/690] [zh] Translate some paragraphs in Chapter 7.

---
 zh/07-customizing-git/01-chapter7.markdown | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/zh/07-customizing-git/01-chapter7.markdown b/zh/07-customizing-git/01-chapter7.markdown
index 8880500e2..24e0659e5 100644
--- a/zh/07-customizing-git/01-chapter7.markdown
+++ b/zh/07-customizing-git/01-chapter7.markdown
@@ -307,11 +307,11 @@ Git默认情况下不会在推送期间检查所有对象的一致性。虽然
 
 #### 比较二进制文件 ####
 
-你可以使用 Git 属性来有效地比较两个二进制文件（binary files，译注：指非文本文件）。那么第一步要做的是，告诉 Git 怎么把你的二进制文件转化为纯文本格式，从而让普通的 diff 命令可以进行文本对比。但是，我们怎么把*二进制文件*转化为文本呢？最好的解决方法是找到一个转换工具帮助我们进行转化。但是，大部分的二进制文件不能表示为可读的文本，例如语音文件就很难转化为文本文件。如果你遇到这些情况，比较简单的解决方法是从这些二进制文件中获取简介，或者元数据。虽然这些数据并不能完全描述一个二进制文件，但是这总能表明一些情况。
+你可以使用 Git 属性来有效地比较两个二进制文件（binary files，译注：指非文本文件）。那么第一步要做的是，告诉 Git 怎么把你的二进制文件转化为纯文本格式，从而让普通的 diff 命令可以进行文本对比。但是，我们怎么把*二进制文件*转化为文本呢？最好的解决方法是找到一个转换工具帮助我们进行转化。但是，大部分的二进制文件不能表示为可读的文本，例如语音文件就很难转化为文本文件。如果你遇到这些情况，比较简单的解决方法是从这些二进制文件中获取元数据。虽然这些元数据并不能完全描述一个二进制文件，但大多数情况下，都是能够概括文件情况的。
 
-We'll make use of the both described approaches to get usable diffs for some widely used binary formats.
+下面，我们将会展示，如何使用转化工具进行二进制文件的比较。
 
-Side note: There are different kinds of binary formats with a text content, which are hard to find usable converter for. In such a case you could try to extract a text from your file with the `strings` program. Some of these files may use an UTF-16 encoding or other "codepages" and `strings` won’t find anything useful in there. Your mileage may vary. However, `strings` is available on most Mac and Linux systems, so it may be a good first try to do this with many binary formats.
+边注：有一些二进制文件虽然包含文字，但是却难以转换。（译注：例如 Word 文档。）在这些情况，你可以尝试使用 `strings` 工具来获取其中的文字。但如果当这些文档包含 UTF-16 编码，或者其他代码页（codepages），`strings` 也可能无补于事。`strings` 在大部分的 Mac 和 Linux 下都有安装。当遇到有二进制文件需要转换的时候，你可以试试这个工具。
 
 ##### MS Word files #####
 
@@ -330,7 +330,7 @@ Side note: There are different kinds of binary formats with a text content, whic
 
 	$ git config diff.word.textconv catdoc
 
-This command adds a section to your `.git/config` that looks like this:
+这个命令会在你的 `.git/config` 文件中增加一节：
 
 	[diff "word"]
 		textconv = catdoc

From f59fab43f736f414813cd335f23f179d85b32842 Mon Sep 17 00:00:00 2001
From: konradkonrad <konradkonrad@users.noreply.github.com>
Date: Fri, 11 Apr 2014 16:17:33 +0200
Subject: [PATCH 279/690] =?UTF-8?q?Fix=20typo=20=C3=A4->a?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

This changes:
"Stattdessen *erfässt Git" -> "Stattdessen erfasst Git"
---
 de/06-git-tools/01-chapter6.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/de/06-git-tools/01-chapter6.markdown b/de/06-git-tools/01-chapter6.markdown
index 98c837256..d9574cfff 100644
--- a/de/06-git-tools/01-chapter6.markdown
+++ b/de/06-git-tools/01-chapter6.markdown
@@ -1170,7 +1170,7 @@ Die zweite Auffälligkeit bei der Ausgabe von `git status` ist der Eintrag rack.
 
 <!--Although `rack` is a subdirectory in your working directory, Git sees it as a submodule and doesn’t track its contents when you’re not in that directory. Instead, Git records it as a particular commit from that repository. When you make changes and commit in that subdirectory, the superproject notices that the HEAD there has changed and records the exact commit you’re currently working off of; that way, when others clone this project, they can re-create the environment exactly.-->
 
-Obwohl `rack` ein Unterverzeichnis in Deinem Arbeitsverzeichnis ist, erkennt Git dieses Verzeichnis als Submodul und verfolgt die Änderungen innerhalb dieses Verzeichnisses nicht, wenn Git nicht innerhalb dieses Verzeichnisses aufgerufen wird. Stattdessen erfässt Git, welcher Commit in diesem Repository ausgecheckt ist. Wenn Du also Änderungen in diesem Unterverzeichnis durchführst und eincheckst, kann das Superprojekt erkennen, dass sich der aktuelle HEAD von diesem Projekt geändert hat. Das Superprojekt kann sich jetzt diesen Commit merken. Auf diese Art und Weise ist es möglich, den kompletten Zustand des Projekts mit allen Projekten, die als Submodul hinzugefügt wurden, zu reproduzieren. In der Git-Terminologie wird das Projekt, welches eines oder mehrere Submodule enthält, als Superprojekt bezeichnet.
+Obwohl `rack` ein Unterverzeichnis in Deinem Arbeitsverzeichnis ist, erkennt Git dieses Verzeichnis als Submodul und verfolgt die Änderungen innerhalb dieses Verzeichnisses nicht, wenn Git nicht innerhalb dieses Verzeichnisses aufgerufen wird. Stattdessen erfasst Git, welcher Commit in diesem Repository ausgecheckt ist. Wenn Du also Änderungen in diesem Unterverzeichnis durchführst und eincheckst, kann das Superprojekt erkennen, dass sich der aktuelle HEAD von diesem Projekt geändert hat. Das Superprojekt kann sich jetzt diesen Commit merken. Auf diese Art und Weise ist es möglich, den kompletten Zustand des Projekts mit allen Projekten, die als Submodul hinzugefügt wurden, zu reproduzieren. In der Git-Terminologie wird das Projekt, welches eines oder mehrere Submodule enthält, als Superprojekt bezeichnet.
 
 <!--This is an important point with submodules: you record them as the exact commit they’re at. You can’t record a submodule at `master` or some other symbolic reference.-->
 

From b2b0277760a178f40a35c8d474d8983b5f687699 Mon Sep 17 00:00:00 2001
From: Volkan Gezer <wakeup@users.noreply.github.com>
Date: Sun, 13 Apr 2014 19:11:14 +0200
Subject: [PATCH 280/690] Typo fix.

---
 tr/03-git-branching/01-chapter3.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tr/03-git-branching/01-chapter3.markdown b/tr/03-git-branching/01-chapter3.markdown
index 4a5679003..a3f9b7b0c 100644
--- a/tr/03-git-branching/01-chapter3.markdown
+++ b/tr/03-git-branching/01-chapter3.markdown
@@ -115,7 +115,7 @@ Bu noktada, sizden kritik önemde başka sorun üzerinde çalışıp hızlıca b
 Insert 18333fig0310.png 
 Figür 3-10. Kısa ve basit bir kayıt tarihçesi.
 
-Şirketinizin kullandığı sorun izleme programındaki #53 numaralı sorun üzerinde çalışmaya karar verdiniz. Açıklığa kavuşturmak için söyleyelim: Git herhangi bir sorun izleme programına bağlı değildir; ama #53 numaralı sorun üzerinde çalışmak istediğiniz başı sonu belli bir konu olduğu için, çalışmanızı bir dal üzerinde yapacaksınız. Bir dalı yaratır yaratmaz hemen ona geçiş yapmak için `git checout` komutunu `-b` seçeneğiyle birlikte kullanabilirsiniz:
+Şirketinizin kullandığı sorun izleme programındaki #53 numaralı sorun üzerinde çalışmaya karar verdiniz. Açıklığa kavuşturmak için söyleyelim: Git herhangi bir sorun izleme programına bağlı değildir; ama #53 numaralı sorun üzerinde çalışmak istediğiniz başı sonu belli bir konu olduğu için, çalışmanızı bir dal üzerinde yapacaksınız. Bir dalı yaratır yaratmaz hemen ona geçiş yapmak için `git checkout` komutunu `-b` seçeneğiyle birlikte kullanabilirsiniz:
 
 	$ git checkout -b iss53
 	Switched to a new branch "iss53"

From e23885e421d997ec05bf48d65665123023ebae3d Mon Sep 17 00:00:00 2001
From: Volkan Gezer <wakeup@users.noreply.github.com>
Date: Sun, 13 Apr 2014 19:14:11 +0200
Subject: [PATCH 281/690] Typo fix.

---
 tr/03-git-branching/01-chapter3.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tr/03-git-branching/01-chapter3.markdown b/tr/03-git-branching/01-chapter3.markdown
index a3f9b7b0c..7eed43e7c 100644
--- a/tr/03-git-branching/01-chapter3.markdown
+++ b/tr/03-git-branching/01-chapter3.markdown
@@ -136,7 +136,7 @@ Web sitesi üzerinde çalışıp bazı kayıtlar yapıyorsunuz. Bunu yaptığın
 	$ git commit -a -m 'added a new footer [issue 53]'
 
 Insert 18333fig0312.png 
-Figür 3-12. Çalışamız sonucunda iss53 dalı ilerledi.
+Figür 3-12. Çalışmamız sonucunda iss53 dalı ilerledi.
 
 Şimdi, sizden web sitesindeki bir sorun için acilen bir yama hazırlamanız istensin. Git kullanıyorsanız, yamayı daha önce `iss53` dalında yaptığınız yaptığınız değişikliklerle birlikte yayına sokmanız gerekmez; yama üzerinde çalışmaya başlamadan önce söz konusu değişiklikleri geri alıp yayındaki web sitesini kaynak koduna ulaşabilmek için fazla çabalamanıza da gerek yok. Tek yapmanız gereken `master` dalına geri dönmek.
 

From 012f6d3a6f93c119fe1673270259f31e57cc7c82 Mon Sep 17 00:00:00 2001
From: Brian Gesiak <modocache@gmail.com>
Date: Mon, 14 Apr 2014 02:55:53 +0900
Subject: [PATCH 282/690] [ja] Fix translation on improvements in the Git UI
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The Japanese translation implies that all systems have had improvements
in their UI over the past few years, but many aspects of Git are still
hard to use. This is not in agreement with the original English:

"In the last few years, the UI has been refined until it’s as clean and
easy to use as any system out there; but often, the stereotype lingers
about the early Git UI that was complex and difficult to learn."

Change the Japanese translation to more closely reflect the English,
i.e.: that the Git UI has improved, but its image as a hard-to-use tool
still lingers.
---
 ja/09-git-internals/01-chapter9.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ja/09-git-internals/01-chapter9.markdown b/ja/09-git-internals/01-chapter9.markdown
index 8aef74cb1..b3834a73a 100644
--- a/ja/09-git-internals/01-chapter9.markdown
+++ b/ja/09-git-internals/01-chapter9.markdown
@@ -4,7 +4,7 @@
 
 もう既にあなたはこの章を読んでいますので、早速、開始しましょう。まず、基本的にGit は連想記憶ファイル・システム（content-addressable filesystem）であり、その上にVCS ユーザー・インターフェイスが記述されているのです。これが意味することを、もう少し見て行きましょう。
 
-初期のGit（主として1.5以前）は、洗練されたVCS というよりもむしろファイル・システムであることを（Gitの特徴として）強調しており、それ故に、ユーザー・インターフェイスは今よりも複雑なものでした。ここ数年の間に、あらゆるシステムのユーザー・インターフェイスはシンプルで扱いが簡単になるまでに改良されました。しかしGit に対しては、複雑で学習するのが難しいという初期のGit がもつ固定観念に縛られているのがほとんどです。
+初期のGit（主として1.5以前）は、洗練されたVCS というよりもむしろファイル・システムであることを（Gitの特徴として）強調しており、それ故に、ユーザー・インターフェイスは今よりも複雑なものでした。ここ数年の間に、世の中のどのシステムにも劣らないほどGit のユーザー・インターフェイスはシンプルで扱いやすいものに改良されました。しかし、複雑で学習するのが難しいという初期のGit に対する型にはまったイメージはまだ残っています。
 
 
 連想記憶ファイル・システム層は驚くほど素晴らしいので、この章の最初にそれをカバーすることにします。その次に転送メカニズムと、今後あなたが行う必要があるかもしれないリポジトリの保守作業について学習することにします。

From 167858b67f50ef9f515ef42d588b22e1758ba7d5 Mon Sep 17 00:00:00 2001
From: diceit <daisuke@ad-dice.com>
Date: Mon, 14 Apr 2014 12:37:42 +0900
Subject: [PATCH 283/690] fix mis-translation private<-->public
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

 public.key is "公開鍵" and private.key is "秘密鍵" in Japanese.
---
 ja/04-git-server/01-chapter4.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ja/04-git-server/01-chapter4.markdown b/ja/04-git-server/01-chapter4.markdown
index 7adf46c80..5aa3b77e5 100644
--- a/ja/04-git-server/01-chapter4.markdown
+++ b/ja/04-git-server/01-chapter4.markdown
@@ -393,7 +393,7 @@ Gitosis は鍵の管理も行うので、まず現在の鍵ファイルを削除
 
 	git:x:1000:1000::/home/git:/bin/sh
 
-いよいよ Gitosis の初期設定です。自分の秘密鍵を使って `gitosis-init` コマンドを実行します。サーバー上に自分の公開鍵をおいていない場合は、まず公開鍵をコピーしましょう。
+いよいよ Gitosis の初期設定です。自分の公開鍵を使って `gitosis-init` コマンドを実行します。サーバー上に自分の公開鍵をおいていない場合は、まず公開鍵をコピーしましょう。
 
 	$ sudo -H -u git gitosis-init < /tmp/id_dsa.pub
 	Initialized empty Git repository in /opt/git/gitosis-admin.git/

From a81ae8fb8ff03a704253869d31cdeb799b3a6b6c Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Sun, 13 Apr 2014 23:38:07 +0200
Subject: [PATCH 284/690] [it] updated chapter 3

---
 it/03-git-branching/01-chapter3.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/it/03-git-branching/01-chapter3.markdown b/it/03-git-branching/01-chapter3.markdown
index 50f2b7293..2e598ea06 100644
--- a/it/03-git-branching/01-chapter3.markdown
+++ b/it/03-git-branching/01-chapter3.markdown
@@ -268,7 +268,7 @@ Se vuoi usare uno strumento grafico per risolvere i problemi, puoi lanciare `git
 	  {remote}: modified
 	Hit return to start merge resolution tool (opendiff):
 
-Se vuoi usare uno strumento di fusione differente dal predefinito (Git usa `opendiff` in questo caso perché ho lanciato il comando su un Mac), puoi vedere tutti gli strumenti supportati all'inizio dopo “merge tool candidates”. Scrivi il nome dello strumento che vorresti usare. Nel Capitolo 7, discuteremo su come puoi modificare i valori predefiniti del tuo ambiente.
+Se vuoi usare uno strumento di fusione differente dal predefinito (Git usa `opendiff` in questo caso perché ho lanciato il comando su un Mac), puoi vedere tutti gli strumenti supportati all'inizio dopo “... one of the following tools:” (uno dei seguenti strumenti, ndt.). Scrivi il nome dello strumento che vorresti usare. Nel Capitolo 7, discuteremo su come puoi modificare i valori predefiniti del tuo ambiente.
 
 Dopo che sei uscito dallo strumento di fusione, Git ti chiederà se la fusione è avvenuta con successo. Se gli dirai allo script che è così, parcheggerà i file in modo da segnarli come risolti per te.
 

From 1a063cbd0dce42dff3490fbc398850a1a5b8719d Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Sun, 13 Apr 2014 23:52:53 +0200
Subject: [PATCH 285/690] [it] Chapter 2: Reviewed 'Getting a Git Repository'

---
 it/02-git-basics/01-chapter2.markdown | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/it/02-git-basics/01-chapter2.markdown b/it/02-git-basics/01-chapter2.markdown
index 6c2b29368..ba5372820 100644
--- a/it/02-git-basics/01-chapter2.markdown
+++ b/it/02-git-basics/01-chapter2.markdown
@@ -12,9 +12,9 @@ Se vuoi iniziare a tenere traccia con Git di un progetto esistente, devi andare
 
 	$ git init
 
-Questo creerà una nuova sottodirectory chiamata .git che conterrà tutti i file necessari per il tuo repository: una struttura del repository Git. A questo punto non è ancora stato tracciato niente del tuo progetto. (Vedi il *Capitolo 9* per sapere quali file sono contenuti nella directory `.git` che hai appena creato.)
+Questo creerà una nuova sottodirectory chiamata `.git` che conterrà tutti i file necessari per il tuo repository, una struttura del repository Git. A questo punto non è ancora stato tracciato niente del tuo progetto. (Vedi il *Capitolo 9* per sapere quali file sono contenuti nella directory `.git` che hai appena creato.)
 
-Se vuoi iniziare a tracciare i file esistenti (a differenza di una directory vuota), dovresti iniziare a monitorare questi file con una commit iniziale. Lo puoi fare con pochi comandi `git add`, che specificano quali file vuoi tracciare, seguiti da un commit: 
+Se vuoi iniziare a tracciare i file esistenti (a differenza di una directory vuota), dovresti iniziare a monitorare questi file con una commit iniziale. Lo puoi fare con pochi `git add`, che specificano quali file vuoi tracciare, seguiti da una commit: 
 
 	$ git add *.c
 	$ git add README

From 9d9751de14c74916b7c53d43218f7e89095b7d8d Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Mon, 14 Apr 2014 00:07:45 +0200
Subject: [PATCH 286/690] [it] Reviewed "Cloning an Existing Repository"

---
 it/02-git-basics/01-chapter2.markdown | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/it/02-git-basics/01-chapter2.markdown b/it/02-git-basics/01-chapter2.markdown
index ba5372820..471fdab49 100644
--- a/it/02-git-basics/01-chapter2.markdown
+++ b/it/02-git-basics/01-chapter2.markdown
@@ -24,19 +24,19 @@ Tra un minuto vedremo cosa fanno questi comandi. A questo punto hai un repositor
 
 ### Clonare un Repository Esistente ###
 
-Se vuoi avere la copia di un repository Git esistente — per esempio, un progetto a cui vuoi contribuire — il comando di cui hai bisogno è git clone. Se hai familiarità con altri sistemi VCS come Subversion, noterai che il comando è clone e non checkout. Questa è una distinzione importante — Git riceve una copia di circa tutti i dati che un server possiede. Ogni versione di ogni file della storia del progetto sono scaricate quando lanci `git clone`. Infatti, se il disco del tuo server è corrotto, puoi usare qualsiasi copia di qualsiasi client per ripristinare il server allo stato in cui era quando è stato clonato (puoi perdere alcuni agganci server, ma tutte le versioni dei dati saranno presenti — vedi il Capitolo 4 per maggiori dettagli).
+Se vuoi copiare un repository Git esistente — per esempio, un progetto a cui vuoi contribuire — il comando di cui hai bisogno è `git clone`. Se hai familiarità con altri sistemi VCS come Subversion, noterai che il comando è `clone` e non `checkout`. Questa è una distinzione importante: Git riceve una copia di quasi tutti i dati che sono sul server. Quando esegui `git clone` vengono scaricate tutte le versioni di ciascun file della cronologia del progetto. Infatti, se si danneggiasse il disco del tuo server, potresti usare qualsiasi clone di qualsiasi client per ripristinare il server allo stato in cui era quando è stato clonato (potresti perdere alcuni `hooks` lato-server, ma tutte le versioni dei dati saranno presenti: vedi il *Capitolo 4* per maggiori dettagli).
 
-Clona un repository con `git clone [url]`. Per esempio, se vuoi clonare la libreria Ruby Git chiamata Grit, puoi farlo così:
+Cloni un repository con `git clone [url]`. Per esempio, se vuoi clonare la libreria Ruby Git chiamata Grit, puoi farlo così:
 
 	$ git clone git://github.com/schacon/grit.git
 
-Questo comando crea un directory "grit", inizializza una directory `.git` dentro di essa, scarica tutti i dati per questo repository ed imposta la copia di lavoro dell'ultima versione. Se entri nella nuova directory `grit`, vedrai i file del progetto, pronti per essere modificati o usati. Se vuoi clonare il repository in una directory con un nome diverso da grit, puoi specificarlo come opzione successiva al comando da terminale:
+Questo comando crea un directory "grit", dentro di questa inizializza una directory `.git`, scarica tutti i dati del repository e fa il checkout dell'ultima versione per poterci lavorare su. Se vai nella nuova directory `grit`, vedrai i file del progetto, pronti per essere modificati o usati. Se vuoi clonare il repository in una directory con un nome diverso da grit, puoi specificarlo sulla riga di comando:
 
 	$ git clone git://github.com/schacon/grit.git mygrit
 
-Questo comando fa la stessa cosa del precedente, ma la directory di destinazione è chiamata mygrit.
+Questo comando fa la stessa cosa del precedente, ma la directory di destinazione è chiamata `mygrit`.
 
-Git può usare differenti protocolli di trasferimento. L'esempio precedente usa il protocollo `git://`, ma puoi anche vedere `http(s)://` o `user@server:/path.git`, che usa il protocollo di trasferimento SSH. Il Capitolo 4 introdurrà tutte le opzioni disponibili che il server può impostare per farti accedere al repository Git ed i pro e i contro di ognuna.
+Git può usare differenti protocolli di trasferimento. L'esempio precedente usa il protocollo `git://`, ma puoi anche vedere `http(s)://` o `user@server:/path.git`, che usa il protocollo di trasferimento SSH. Il *Capitolo 4* introdurrà tutte le opzioni che un server può rendere disponibili per l'accesso al repository Git e i pro e i contro di ciascuna.
 
 ## Registrare i Cambiamenti nel Repository ##
 

From 904c64a9b1a72ba677c255f9f9313bcbe866b9d4 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Mon, 14 Apr 2014 00:20:41 +0200
Subject: [PATCH 287/690] [it] Reviewed "Recording Changes to the Repository"

---
 it/02-git-basics/01-chapter2.markdown | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/it/02-git-basics/01-chapter2.markdown b/it/02-git-basics/01-chapter2.markdown
index 471fdab49..283823bf0 100644
--- a/it/02-git-basics/01-chapter2.markdown
+++ b/it/02-git-basics/01-chapter2.markdown
@@ -38,18 +38,18 @@ Questo comando fa la stessa cosa del precedente, ma la directory di destinazione
 
 Git può usare differenti protocolli di trasferimento. L'esempio precedente usa il protocollo `git://`, ma puoi anche vedere `http(s)://` o `user@server:/path.git`, che usa il protocollo di trasferimento SSH. Il *Capitolo 4* introdurrà tutte le opzioni che un server può rendere disponibili per l'accesso al repository Git e i pro e i contro di ciascuna.
 
-## Registrare i Cambiamenti nel Repository ##
+## Salvare le modifiche sul repository ##
 
-In buona fede hai copiato un repository Git e hai la copia di lavoro dei file di questo progetto. Ora puoi apportare alcune modifiche ed inviare gli snapshots di questi cambiamenti nel tuo repository ogni volta che il progetto raggiunge uno stato che vuoi registrare.
+Hai clonato un vero repository Git e hai la copia di lavoro dei file del progetto. Ora puoi fare qualche modifica e inviare gli snapshots di queste al tuo repository ogni volta che il progetto raggiunga uno stato che vuoi salvare.
 
-Ricorda che ogni file nella tua directory di lavoro è in una dei due stati seguenti: *tracciato* o *non tracciato*. I file *tracciati* sono i file presenti nell'ultimo snapshot; possono essere *non modificati*, *modificati* o *staged* (parcheggiati, ndt). I file *non tracciati* sono tutti gli altri - qualsiasi file nella tua directory di lavoro che non è presente nel tuo ultimo snapshot o nella tua area di stage. Quando cloni per la prima volta un repository, tutti i tuoi file sono tracciati e non modificati perché li hai appena prelevati e non hai modificato ancora niente.
+Ricorda che ogni file della tua directory di lavoro può essere in uno dei due stati seguenti: *tracked* (tracciato, ndt.) o *untracked* (non tracciato, ndt.). I file *tracked* sono già presenti nell'ultimo snapshot; possono quindi essere *unmodified* (non modificati, ndt.), *modified* (modificati, ndt.) o *staged*. I file *untracked* sono tutti gli altri: qualsiasi file nella tua directory di lavoro che non è presente nell'ultimo snapshot o nella tua area di stage. Quando cloni per la prima volta un repository, tutti i tuoi file sono tracciati e non modificati perché li hai appena prelevati e non hai modificato ancora niente.
 
-Quando modifichi i file, Git li vede come cambiati, perché li hai modificati rispetto all'ultimo commit. Parcheggi questi file e poi esegui il commit di tutti i cambiamenti presenti nell'area di stage, ed il ciclo si ripete. Questo ciclo di vita è illustrato nella Figura 2-1.
+Quando modifichi i file, Git li vede come modificati, perché li hai cambiati rispetto all'ultima commit. Metti nell'area di stage i file modificati e poi fai la commit di tutto ciò che è in quest'area, e quindi il ciclo si ripete. Questo ciclo di vita è illustrato nella Figura 2-1.
 
 Insert 18333fig0201.png
 Figura 2-1. Il ciclo di vita dello stato dei tuoi file.
 
-### Controlla lo Stato dei Tuoi File ###
+### Controlla lo stato dei tuoi file ###
 
 Lo strumento principale che userai per determinare quali file sono in un certo stato è il comando git status. Se lanci questo comando direttamente dopo aver fatto una clonazione, dovresti vedere qualcosa di simile a:
 

From 6ead6fac69a8585cdd14f86e5e06b93838813a33 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Mon, 14 Apr 2014 09:29:04 +0200
Subject: [PATCH 288/690] [it] Reviewed "Checking the Status of Your Files"

---
 it/02-git-basics/01-chapter2.markdown | 23 ++++++++++++-----------
 1 file changed, 12 insertions(+), 11 deletions(-)

diff --git a/it/02-git-basics/01-chapter2.markdown b/it/02-git-basics/01-chapter2.markdown
index 283823bf0..55101d0d7 100644
--- a/it/02-git-basics/01-chapter2.markdown
+++ b/it/02-git-basics/01-chapter2.markdown
@@ -44,33 +44,34 @@ Hai clonato un vero repository Git e hai la copia di lavoro dei file del progett
 
 Ricorda che ogni file della tua directory di lavoro può essere in uno dei due stati seguenti: *tracked* (tracciato, ndt.) o *untracked* (non tracciato, ndt.). I file *tracked* sono già presenti nell'ultimo snapshot; possono quindi essere *unmodified* (non modificati, ndt.), *modified* (modificati, ndt.) o *staged*. I file *untracked* sono tutti gli altri: qualsiasi file nella tua directory di lavoro che non è presente nell'ultimo snapshot o nella tua area di stage. Quando cloni per la prima volta un repository, tutti i tuoi file sono tracciati e non modificati perché li hai appena prelevati e non hai modificato ancora niente.
 
-Quando modifichi i file, Git li vede come modificati, perché li hai cambiati rispetto all'ultima commit. Metti nell'area di stage i file modificati e poi fai la commit di tutto ciò che è in quest'area, e quindi il ciclo si ripete. Questo ciclo di vita è illustrato nella Figura 2-1.
+Quando editi dei file, Git li vede come modificati, perché sono cambiati rispetto all'ultima commit. Metti nell'area di stage i file modificati e poi fai la commit di tutto ciò che è in quest'area, e quindi il ciclo si ripete. Questo ciclo di vita è illustrato nella Figura 2-1.
 
 Insert 18333fig0201.png
 Figura 2-1. Il ciclo di vita dello stato dei tuoi file.
 
 ### Controlla lo stato dei tuoi file ###
 
-Lo strumento principale che userai per determinare quali file sono in un certo stato è il comando git status. Se lanci questo comando direttamente dopo aver fatto una clonazione, dovresti vedere qualcosa di simile a:
+Lo strumento principale che userai per determinare lo stato dei tuoi file è il comando `git status`. Se esegui questo comando appena dopo un clone, dovresti vedere qualcosa di simile:
 
 	$ git status
 	# On branch master
-	nothing to commit (working directory clean)
+	nothing to commit, working directory clean
 
-Questo significa che hai una directory di lavoro pulita — in altre parole, non c'è traccia di file modificati. Git inoltre non vede altri file non tracciati, altrimenti sarebbero elencati qui. Infine, il comando ci dice in quale ramo si è. Per ora, è sempre il master, che è il predefinito; non preoccuparti di questo per ora. Il prossimo capitolo tratterà delle ramificazioni e dei riferimenti nei dettagli.
+Questo significa che hai una directory di lavoro pulita, ovvero che nessuno dei file tracciati è stato modificato. Inoltre Git non ha trovato nessun file non ancora tracciato, altrimenti sarebbero elencati qui. In aggiunta il comando indica anche in quale ramo sei. Per ora, è sempre `master`, che è il predefinito; non preoccupartene per ora. Il prossimo capitolo tratterà in dettagli dei `branch` (ramificazioni) e dei riferimenti.
 
-Ora diciamo che hai aggiunto un nuovo file al tuo progetto, un semplice file README. Se il file non esisteva prima, e lanci `git status`, vedrai il tuo file non tracciato come segue:
+Immagina di aver aggiunto un nuovo file al tuo progetto, un semplice README. Se il file non esisteva e lanci `git status`, vedrai così il file non tracciato:
 
 	$ vim README
 	$ git status
-	# On branch master
-	# Untracked files:
-	#   (use "git add <file>..." to include in what will be committed)
-	#
-	#	README
+	On branch master
+	Untracked files:
+	  (use "git add <file>..." to include in what will be committed)
+	
+	        README
+
 	nothing added to commit but untracked files present (use "git add" to track)
 
-Puoi vedere che il tuo nuovo file README non è tracciato, perché è sotto al titolo "Untracked files" nell'output degli stati. Untracked fondamentalmente significa che Git vede un file che non avevi nel precedente snapshot (commit); Git non inizierà ad includerlo negli snapshot dei tuoi commit fino a quando tu non glielo dirai esplicitamente. Si comporta così per evitare che tu accidentalmente includa file binari generati o qualsiasi altro tipo di file che non vuoi sia incluso. Se vuoi includere il file README, continua con il tracciamento dei file.
+Puoi vedere che il nuovo file README non è tracciato poiché nell'output è nella sezione dal titolo "Untracked files". `Untracked` significa che Git vede un file che non avevi nello `snapshot` precedente (commit); Git non lo includerà negli snapshot delle tuoe commit fino a quando non glielo dirai esplicitamente. Fa così per evitare che includa accidentalmente dei file binari generati o qualsiasi altro tipo di file che non intendi includere. Se vuoi includere il  README, iniziamo a tracciarlo.
 
 ### Tracciare Nuovi File ###
 

From 843f17a01aae3bc3fd1dc9f61a3cfa539408d724 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Mon, 14 Apr 2014 11:20:42 +0200
Subject: [PATCH 289/690] [it] Reviewed "Tracking New Files"

---
 it/02-git-basics/01-chapter2.markdown | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/it/02-git-basics/01-chapter2.markdown b/it/02-git-basics/01-chapter2.markdown
index 55101d0d7..07737f80c 100644
--- a/it/02-git-basics/01-chapter2.markdown
+++ b/it/02-git-basics/01-chapter2.markdown
@@ -75,21 +75,21 @@ Puoi vedere che il nuovo file README non è tracciato poiché nell'output è nel
 
 ### Tracciare Nuovi File ###
 
-Per iniziare a tracciare un nuovo file, usa il comando `git add`. Per tracciare il file `README`, lancia questo comando:
+Per iniziare a tracciare un nuovo file, si usa il comando `git add`. Per tracciare il file `README`, usa questo comando:
 
 	$ git add README
 
-Se lanci nuovamente il comando di stato, puoi vedere il tuo file `README` tracciato e parcheggiato:
+Se lanci nuovamente il comando per lo stato, puoi vedere il tuo file `README` ora è tracciato e nell'area si `stage`:
 
 	$ git status
-	# On branch master
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#	new file:   README
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        new file:   README
+	
 
-Ti dice che è in stage (parcheggiato, ndt) perché è sotto al titolo "Changes to be committed". Se fai ora il commit, la versione del file al momento in cui hai lanciato `git add` sarà quella che troverai nella storia dello snapshot.  Potresti ricordare che quando hai eseguito `git init` precedentemente, poi hai dovuto lanciare `git add (file)` — che era necessario per l'inizio del tracciamento dei file nella tua directory. Il comando git add prende il nome del percorso di ogni file o directory; se è una directory, il comando aggiunge tutti i file in quella directory ricorsivamente.
+Sai che è nell'area di `stage` perché è nella sezione "Changes to be committed". Se a questo punto fai commit, la versione del file com'era quando hai lanciato `git add` sarà quella che troverai nella cronologia dello snapshot. Ricorderai che quando prima hai eseguito `git init`, poi hai dovuto lanciare `git add (file)`, che era necessario per iniziare a tracciare i file nella tua directory. Il comando `git add` accetta il nome del percorso di un file o una directory; se è una directory, il comando aggiunge ricorsivamente tutti i file in quella directory.
 
 ### Parcheggiare File Modificati ###
 

From 7f6bde7e07ccf85ddcda2b1b3eb3310ad4932656 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Mon, 14 Apr 2014 11:50:38 +0200
Subject: [PATCH 290/690] [it] Reviewed "Staging Modified Files"

---
 it/02-git-basics/01-chapter2.markdown | 86 ++++++++++++++-------------
 1 file changed, 44 insertions(+), 42 deletions(-)

diff --git a/it/02-git-basics/01-chapter2.markdown b/it/02-git-basics/01-chapter2.markdown
index 07737f80c..d423d12a7 100644
--- a/it/02-git-basics/01-chapter2.markdown
+++ b/it/02-git-basics/01-chapter2.markdown
@@ -91,63 +91,65 @@ Se lanci nuovamente il comando per lo stato, puoi vedere il tuo file `README` or
 
 Sai che è nell'area di `stage` perché è nella sezione "Changes to be committed". Se a questo punto fai commit, la versione del file com'era quando hai lanciato `git add` sarà quella che troverai nella cronologia dello snapshot. Ricorderai che quando prima hai eseguito `git init`, poi hai dovuto lanciare `git add (file)`, che era necessario per iniziare a tracciare i file nella tua directory. Il comando `git add` accetta il nome del percorso di un file o una directory; se è una directory, il comando aggiunge ricorsivamente tutti i file in quella directory.
 
-### Parcheggiare File Modificati ###
+### Fare lo stage dei file modificati ###
 
-Ora modifichiamo un file che è già stato tracciato. Se modifichi un file precedentemente tracciato chiamato `benchmarks.rb` e poi avvii nuovamente il comando `status`, otterrai qualcosa di simile a:
+Modifichiamo un file che è già tracciato. Se modifichi un file tracciato chiamato `benchmarks.rb` e poi esegui il comando `status`, otterrai qualcosa di simile a:
 
 	$ git status
-	# On branch master
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#	new file:   README
-	#
-	# Changes not staged for commit:
-	#   (use "git add <file>..." to update what will be committed)
-	#
-	#	modified:   benchmarks.rb
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        new file:   README
 
-Il file benchmarks.rb appare sotto la sezione chiamata "Changes not staged for commit" — che significa che un file che è tracciato è stato modificato nella directory di lavoro ma non ancora messo in stage. Per parcheggiarlo, avvia il comando `git add` (è un comando multifunzione — è usato per iniziare a tracciare nuovi file, per parcheggiare i file e per fare altre cose come eseguire la fusione dei file che entrano in conflitto dopo che sono stati risolti). Avvia dunque `git add` per parcheggiare ora il file benchmarks.rb, e avvia nuovamente `git status`:
+	Changes not staged for commit:
+	  (use "git add <file>..." to update what will be committed)
+	  (use "git checkout -- <file>..." to discard changes in working directory)
+	
+	        modified:   benchmarks.rb
+	
+
+Il file benchmarks.rb appare nella sezione chiamata "Changes not staged for commit" — che significa che un file tracciato è stato modificato nella directory di lavoro ma non è ancora nello stage. Per farlo, esegui il comando `git add` (è un comando multifunzione — lo usi per iniziare a tracciare nuovi file, per fare lo stage dei file e per fare altre cose segnare come risolti i conflitti causati da un `merge`). Esegui `git add` per mettere in `stage` il file benchmarks.rb, e riesegui `git status`:
 
 	$ git add benchmarks.rb
 	$ git status
-	# On branch master
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#	new file:   README
-	#	modified:   benchmarks.rb
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        new file:   README
+	        modified:   benchmarks.rb
+	
 
-Entrambi i file sono parcheggiati ed entreranno nel prossimo commit. A questo punto, supponendo che tu ti sia ricordato di una piccola modifica da fare a benchmarks.rb prima di fare il commit. Apri nuovamente il file ed esegui la modifica, e ora sei pronto per il commit. Come sempre, lanci `git status` ancora una volta:
+Entrambi i file sono nello `stage` e staranno nella prossima commit. A questo punto, immagina che ti sia ricordato di una piccola modifica da fare in 'benchmarks.rb' prima della commit. Riapri il file e fai la modifica: ora sei pronto per la commit. Come sempre, esegui `git status` di nuovo:
 
 	$ vim benchmarks.rb
 	$ git status
-	# On branch master
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#	new file:   README
-	#	modified:   benchmarks.rb
-	#
-	# Changes not staged for commit:
-	#   (use "git add <file>..." to update what will be committed)
-	#
-	#	modified:   benchmarks.rb
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        new file:   README
+	        modified:   benchmarks.rb
+	
+	Changes not staged for commit:
+	  (use "git add <file>..." to update what will be committed)
+	  (use "git checkout -- <file>..." to discard changes in working directory)
+	
+	        modified:   benchmarks.rb
+	
 
-Che succede? Ora benchmarks.rb è elencato sia in stage che non. Come è possibile? É saltato fuori che Git ha parcheggiato il file esattamente come se tu avessi avviato il comando git add. Se esegui ora il commit, la versione di benchmarks.rb che verrà inviata nel commit sarà quella di quando tu hai lanciato il comando git add, non la versione del file che appare nella tua directory di lavoro quando lanci git commit. Se modifichi un file dopo che hai lanciato `git add`, devi nuovamente avviare `git add` per parcheggiare l'ultima versione del file:
+Cos'è successo? Ora `benchmarks.rb` è elencato sia dentro che fuori lo `stage`. Come è possibile? È saltato fuori che Git ha messo in `stage` il file esattamente com'era quando hai eseguito `git add`. Se committi ora, la versione di `benchmarks.rb` che verrà committata sarà quella che avevi quando hai eseguito il `git add`, non la versione del file che trovi nella directory di lavoro quando esegui `git commit`. Se modifichi un file dopo che hai eseguito `git add`, ridevi eseguire `git add` per mettere nello `stage` l'ultima versione del file:
 
 	$ git add benchmarks.rb
 	$ git status
-	# On branch master
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#	new file:   README
-	#	modified:   benchmarks.rb
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        new file:   README
+	        modified:   benchmarks.rb
+	
 
 ### Ignorare File ###
 

From 975264aa865be3b959a5be11309e5bc30df24664 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Mon, 14 Apr 2014 12:04:43 +0200
Subject: [PATCH 291/690] [it] reviewed "Ignoring Files"

---
 it/02-git-basics/01-chapter2.markdown | 24 ++++++++++++------------
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/it/02-git-basics/01-chapter2.markdown b/it/02-git-basics/01-chapter2.markdown
index d423d12a7..2e63a4393 100644
--- a/it/02-git-basics/01-chapter2.markdown
+++ b/it/02-git-basics/01-chapter2.markdown
@@ -153,31 +153,31 @@ Cos'è successo? Ora `benchmarks.rb` è elencato sia dentro che fuori lo `stage`
 
 ### Ignorare File ###
 
-Spesso, si ha una classe di file che non si vuole automaticamente aggiungere o far vedere come file non tracciati a Git. Ci sono generalmente alcuni file generati automaticamente come i file di log o i file prodotti dalla creazione di un sistema. In questi casi, puoi creare un file chiamato .gitignore con una lista di pattern corrispondente ad essi. Questo è un esempio di file .gitignore:
+Spesso hai un tipo di file che non vuoi che Git li aggiunga automaticamente e nemmeno te li mostri come tracciati. Generalmente si tratta di file generati automaticamente, come i log o quelli prodotti dal tuoi sistema di `build`. In questi casi puoi creare un file chiamato `.gitignore` con la lista di pattern dei file che vuoi ignorare. Questo è un `.gitignore` d'esempio:
 
 	$ cat .gitignore
 	*.[oa]
 	*~
 
-La prima linea dice a Git di ignorare qualsiasi file che finisce con .o o .a — file di oggetti o archivi che possono essere il prodotto di una compilazione del tuo codice. La seconda linea dice a Git di ignorare tutti i file che finiscono con la tilde (`~`), che è usata da alcuni editor di testo come Emacs per marcare i file temporanei. Puoi anche includere directory di log, tmp o pid; documentazioni generate automaticamente; e così via. Imposta un file .gitignore prima di di procedere è generalmente una buona idea, così si evita il rischio di eseguire accidentalmente dei commit dei file che non vuoi nel tuo repository Git.
+La prima riga dice a Git di ignorare qualsiasi file che finisce in `.o` o `.a` — file di oggetti o archivi che possono essere il prodotto di una compilazione del tuo codice. La seconda riga dice a Git di ignorare tutti i file che finiscono con tilde (`~`), che è usata da alcuni editor di testo come Emacs per marcare i file temporanei. Puoi anche includere le directory `log`, `tmp` o `pid`, documenti generati automaticamente e così via. Definire un file `.gitignore` prima di iniziare generalmente è una buona idea, così eviti il rischio di committare accidentalmente dei file che non vuoi nel tuo repository Git.
 
-Le regole per i pattern che puoi mettere nel file .gitignore sono le seguenti:
+Queste sono le regole per i pattern che puoi usare in `.gitignore`:
 
-*	Linee vuote o linee che iniziano con # sono ignorate.
-*	I glob pattern standard (formati usati per indicare classi di caratteri nelle shell, ndt) funzionano.
-*	Puoi terminare i pattern con un diviso (`/`) per specificare una directory.
-*	Puoi negare un pattern aggiungendo all'inizio il punto di esclamazione (`!`).
+*	Le righe vuote o che inizino con `#` vengono ignorate.
+*	Gli standard `glob pattern` funzionano (http://it.wikipedia.org/wiki/Glob_pattern, ndt).
+*	Puoi terminare i pattern con uno slash (`/`) per indicare una directory.
+*	Puoi negare un pattern facendolo iniziare con un punto esclamativo (`!`).
 
-I glob pattern sono come espressioni regolari semplificate usate dalla shell. Un asterisco (`*`) corrisponde a zero o più caratteri; `[abc]` corrispondente ad ogni carattere all'interno delle parentesi (in questo caso a, b, o c); il punto di domanda (`?`) corrispondente ad un singolo carattere; ed i caratteri all'interno delle parentesi quadre separati dal segno meno (`[0-9]`) corrispondono ad ogni carattere all'interno del range impostato (in questo caso da 0 a 9).
+I `glob pattern` sono come espressioni regolari semplificate, usate dalla shell. L'asterisco (`*`) corrisponde a zero o più caratteri; `[abc]` corrisponde a ogni carattere all'interno delle parentesi (in questo caso `a`, `b`, o `c`); il punto interrogativo (`?`) corrisponden ad un carattere singolo; e i caratteri all'interno delle parentesi quadre separati dal segno meno (`[0-9]`) corrispondono ad ogni carattere all'interno dell'intervallo (in questo caso da 0 a 9).
 
 Questo è un altro esempio di file .gitignore:
 
 	# un commento - questo è ignorato
-	# no file .a
+	# escludi i file .a
 	*.a
-	# ma traccia lib.a, mentre vengono ignorati tutti i file .a come sopra
+	# ma traccia lib.a, sebbene su tu stia ignorando tutti i file `.a`
 	!lib.a
-	# ignora solamente il file TODO in root, non del tipo subdir/TODO
+	# ignora solo il TODO nella root, e non subdir/TODO
 	/TODO
 	# ignora tutti i file nella directory build/
 	build/
@@ -186,7 +186,7 @@ Questo è un altro esempio di file .gitignore:
 	# ignora tutti i file .txt nella directory doc/
 	doc/**/*.txt
 
-Un pattern `**/` è disponibile in Git dalla version 1.8.2.
+Il pattern `**/` è disponibile in Git dalla version 1.8.2.
 
 ### Visualizzare le Tue Modifiche Parcheggiate e Non ###
 

From 02d9041fd26c9c7276e95d852ed614162571c3b7 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Mon, 14 Apr 2014 13:47:31 +0200
Subject: [PATCH 292/690] [it] Chapter 2

Reviewed "Viewing Your Staged and Unstaged Changes"
---
 it/02-git-basics/01-chapter2.markdown | 65 ++++++++++++++-------------
 1 file changed, 34 insertions(+), 31 deletions(-)

diff --git a/it/02-git-basics/01-chapter2.markdown b/it/02-git-basics/01-chapter2.markdown
index 2e63a4393..510294f4f 100644
--- a/it/02-git-basics/01-chapter2.markdown
+++ b/it/02-git-basics/01-chapter2.markdown
@@ -188,26 +188,27 @@ Questo è un altro esempio di file .gitignore:
 
 Il pattern `**/` è disponibile in Git dalla version 1.8.2.
 
-### Visualizzare le Tue Modifiche Parcheggiate e Non ###
+### Mostra le modifiche dentro e fuori lo `stage` ###
 
-Se il comando `git status` è troppo vago per te — vorrai conoscere esattamente cosa hai modificato, non solamente i file che hai cambiato — puoi usare il comando `git diff`. Scopriremo in maggior dettaglio `git diff` più avanti; ma probabilmente lo userai più spesso per rispondere a queste due domande: Cosa hai modificato, ma non ancora parcheggiato? E cosa hai parcheggiato e che sta per mettere nel commit? Certamente, `git status` risponde a queste domande in generale, `git diff` ti mostra le linee esatte aggiunte e rimosse — la patch, per così dire.
+Se `git status` è troppo vago per te - vuoi sapere cos'è stato effettivamente modificato e non solo quali file — puoi usare il comando `git diff`. Tratteremo più avanti `git diff` con maggior dettaglio, ma probabilmente lo userai molto spesso per rispondere a queste due domande: Cos'è che hai modificato ma non è ancora in `stage`? E cos'hai nello `stage` che non hai ancora committato? Sebbene `git status` risponda a queste domande in modo generico, `git diff` mostra le righe effettivamente aggiunte e rimosse — la patch così com'è.
 
-Nuovamente ti chiedo di modificare e parcheggiare il file README e poi modificare il file benchmarks.rb senza parcheggiarlo. Se lanci il comando `status`, vedrai nuovamente questo:
+Supponiamo che tu habbia modificato nuovamente `README` e `benchmarks.rb` ma messo nello `stage` solo il primo. Se esegui il comando `status`, vedrai qualcosa come questo:
 
 	$ git status
-	# On branch master
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#	new file:   README
-	#
-	# Changes not staged for commit:
-	#   (use "git add <file>..." to update what will be committed)
-	#
-	#	modified:   benchmarks.rb
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        new file:   README
+	
+	Changes not staged for commit:
+	  (use "git add <file>..." to update what will be committed)
+	  (use "git checkout -- <file>..." to discard changes in working directory)
+	
+	        modified:   benchmarks.rb
+	
 
-Per vedere cosa hai modificato, ma non ancora parcheggiato, digita `git diff` senza altri argomenti:
+Per vedere cosa hai modificato, ma non ancora nello `stage`, digita `git diff` senza altri argomenti:
 
 	$ git diff
 	diff --git a/benchmarks.rb b/benchmarks.rb
@@ -226,9 +227,9 @@ Per vedere cosa hai modificato, ma non ancora parcheggiato, digita `git diff` se
 	           log = git.commits('master', 15)
 	           log.size
 
-Questo comando compara cosa c'è nella tua directory di lavoro con quello che è nella tua area di stage. Il risultato ti dice i cambiamenti che hai fatto che non sono ancora stati parcheggiati.
+Questo comando confronta cosa c'è nella tua directory di lavoro con quello che c'è nella tua area di `stage`. Il risultato mostra le tue modifiche che ancora non hai messo nello `stage`.
 
-Se vuoi vedere cosa hai parcheggiato e cosa sarà inviato con il tuo prossimo commit, puoi usare `git diff --cached`. (Nella versione 1.6.1 e successive di Git, puoi usare anche `git diff --staged`, che dovrebbe essere più facile da ricordare). Questo comando compara i tuoi cambiamenti nell'area di stage ed il tuo ultimo commit:
+Se vuoi vedere cosa c'è nello `stage` e che farà parte della prossima commit, puoi usare `git diff --cached`. (Da Git 1.6.1 in poi, puoi usare anche `git diff --staged`, che dovrebbe essere più facile da ricordare). Questo comando confronta le modifiche che hai nell'area di `stage` e la tua ultima commit:
 
 	$ git diff --cached
 	diff --git a/README b/README
@@ -243,25 +244,27 @@ Se vuoi vedere cosa hai parcheggiato e cosa sarà inviato con il tuo prossimo co
 	+
 	+Grit is a Ruby library for extracting information from a Git repository
 
-É importante notare che `git diff` di per se non visualizza tutti i cambiamenti fatti dal tuo ultimo commit — solo i cambiamenti che ancora non sono parcheggiati. Questo può confondere, perché se hai messo in stage tutte le tue modifiche, `git diff` non darà nessun output.
+È importante notare che `git diff` di per se non visualizza tutte le modifiche fatte dall'ultima commit, ma solo quelle che non sono ancora in `stage`. Questo può confondere, perché se hai messo in `stage` tutte le tue modifiche, `git diff` non mostrereà nulla.
 
-Per un altro esempio, se parcheggi il file benchmarks.rb e lo modifichi, puoi usare `git diff` per vedere i cambiamenti nel file che sono in stage e i cambiamenti che non sono parcheggiati:
+Ecco un altro esempio, se metti in `stage` il file `benchmarks.rb` e lo modifichi, puoi usare `git diff` per vedere quali modifiche al file sono in stage e i quali non ancora:
 
 	$ git add benchmarks.rb
 	$ echo '# test line' >> benchmarks.rb
 	$ git status
-	# On branch master
-	#
-	# Changes to be committed:
-	#
-	#	modified:   benchmarks.rb
-	#
-	# Changes not staged for commit:
-	#
-	#	modified:   benchmarks.rb
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        modified:   benchmarks.rb
+	
+	Changes not staged for commit:
+	  (use "git add <file>..." to update what will be committed)
+	  (use "git checkout -- <file>..." to discard changes in working directory)
+	
+	        modified:   benchmarks.rb
+	
 
-Ora puoi usare `git diff` per vedere cosa non è ancora parcheggiato
+Puoi quindi usare `git diff` per vedere cosa non è ancora in `stage`
 
 	$ git diff
 	diff --git a/benchmarks.rb b/benchmarks.rb
@@ -274,7 +277,7 @@ Ora puoi usare `git diff` per vedere cosa non è ancora parcheggiato
 	 ##pp Grit::GitRuby.cache_client.stats
 	+# test line
 
-e `git diff --cached` per vedere cosa hai parcheggiato precedentemente:
+e `git diff --cached` per vedere cos'è già in `stage`:
 
 	$ git diff --cached
 	diff --git a/benchmarks.rb b/benchmarks.rb

From 37db9ca5d24527ea4ef9d507cff65945cffbdfd8 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Mon, 14 Apr 2014 14:55:58 +0200
Subject: [PATCH 293/690] [it] Chapter 2

Reviewed "Committing Your Changes"
---
 it/02-git-basics/01-chapter2.markdown | 25 ++++++++++++-------------
 1 file changed, 12 insertions(+), 13 deletions(-)

diff --git a/it/02-git-basics/01-chapter2.markdown b/it/02-git-basics/01-chapter2.markdown
index 510294f4f..119c64a2b 100644
--- a/it/02-git-basics/01-chapter2.markdown
+++ b/it/02-git-basics/01-chapter2.markdown
@@ -296,42 +296,41 @@ e `git diff --cached` per vedere cos'è già in `stage`:
 	          log = git.commits('master', 15)
 	          log.size
 
-### Eseguire il Commit delle Tue Modifiche ###
+### Committa le tue modifiche ###
 
-Ora la tua area di stage è impostata come volevi, puoi eseguire il commit delle tue modifiche. Ricorda che qualsiasi cosa che non è parcheggiata — qualsiasi file che hai creato o modificato e a cui non hai fatto `git add` — non andrà nel commit. Rimarranno come file modificati sul tuo disco.
-In questo caso, l'ultima volta che hai lanciato `git status`, hai visto che tutto era parcheggiato, così sei pronto ad inviare le tue modifiche con un commit. Il modo più semplice per eseguire il commit è digitare `git commit`:
+Ora che la tua area di stage è configurata come vuoi, puoi fare la commit delle tue modifiche. Ricorda che tutto ciò che non è in `stage` — qualsiasi file che hai creato o modificato per cui non hai fatto `git add` — non sarà nella commit. Rimarranno come file modificati sul tuo disco.
+In questo caso, l'ultima volta che hai eseguito `git status`, hai visto che tutto era in `stage`, così sei pronto a committare le tue modifiche. Il modo più semplice per farlo è eseguire `git commit`:
 
 	$ git commit
 
-Facendo questo lanci l'editor che avevi scelto. (Questo è impostato nella tua shell dalla variabile di ambiente `$EDITOR` — generalmente vim o emacs, ovviamente puoi configurarlo con qualsiasi altro editor usando il comando `git config --global core.editor` come visto nel Capitolo 1).
+Facendolo lanci il tuo editor predefinito. (Questo è impostato nella tua shell con la variabile di ambiente `$EDITOR` — generalmente vim o emacs, sebbene tu possa configurarlo con qualsiasi altro editor, usando il comando `git config --global core.editor` come hai visto nel *Capitolo 1*).
 
-L'editor visualizzerà il seguente testo (questo è un esempio della schermata di Vim):
+L'editor visualizzerà il testo (questo è un esempio della schermata di Vim):
 
 	# Please enter the commit message for your changes. Lines starting
 	# with '#' will be ignored, and an empty message aborts the commit.
 	# On branch master
 	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
 	#       new file:   README
 	#       modified:   benchmarks.rb
+	#
 	~
 	~
 	~
 	".git/COMMIT_EDITMSG" 10L, 283C
 
-Puoi vedere che il messaggio predefinito del commit contiene l'ultimo output del comando `git status`, commentato, e la prima riga in alto è vuota. Puoi rimuovere questi commenti ed inserire il tuo messaggio, o puoi lasciarli così per aiutarti a ricordare cosa hai inviato. (Per avere una nota di ricordo più esplicita puoi passare l'opzione `-v` a `git commit`. Così facendo inserirai i cambiamenti effettuati nell'editor in modo che tu possa vedere esattamente cosa hai fatto). Quando esci dall'editor, Git crea il tuo commit con un messaggio (con i commenti ed i cambiamenti eliminati).
+Come vedi, il messaggio predefinito della commit contiene l'ultimo output del comando `git status`, commentato, e la prima riga in alto è vuota. Puoi rimuovere questi commenti e inserire il tuo messaggio di commit, o puoi lasciarli così per aiutarti a ricordare cosa stai committando. (Per una nota ancora più esplicita puoi usare l'opzione `-v` a `git commit`. Facendo saranno nel commento saranno inserite anche le modifiche stesse, così che tu possa vedere esattamente cosa hai fatto). Quando esci dall'editor, Git crea la tuo commit con un messaggio (rimuovendo commenti ed eventuali diff).
 
-In alternativa, puoi inserire il messaggio del tuo commit in linea con il comando `commit` specificando dopo di esso l'opzione -m, come segue:
+In alternativa, puoi inserire il messaggio per la tua commit alla riga di comando della `commit` specificando l'opzione -m, come segue:
 
 	$ git commit -m "Story 182: Fix benchmarks for speed"
-	[master]: created 463dc4f: "Fix benchmarks for speed"
-	 2 files changed, 3 insertions(+), 0 deletions(-)
+	[master 463dc4f] Fix benchmarks for speed
+	 2 files changed, 3 insertions(+)
 	 create mode 100644 README
 
-Ora hai creato il tuo primo commit! Puoi vedere che il commit ha riportato alcune informazioni sull'operazione: a quale ramo hai affidato il commit (`master`), quale checksum SHA-1 ha il commit (`463dc4f`), quanti file sono stati modificati e le statistiche sulle linee aggiunte e rimosse nel commit.
+Hai creato la tua prima commit! Puoi vedere che la commit restituisce alcune informazioni su se stessa: su quale `branch` (ramo, ndt) hai fatto la commit (`master`), quale checksum SHA-1 ha la commit (`463dc4f`), quanti file sono stati modificati e le statistiche sulle righe aggiunte e rimosse con la commit.
 
-Ricorda che il commit registra lo snapshot che hai impostato nella tua area di stage. Qualsiasi cosa che non hai parcheggiato rimarrà come modificata; puoi fare un altro commit per aggiungere questi alla storia del progetto. Ogni volta che fai un commit stai registrando una istantanea del tuo progetto, che puoi ripristinare o comparare successivamente.
+Ricorda che la commit registra lo snapshot che hai salvato nella tua area di `stage`. Qualsiasi cosa che non è nello `stage` rimarrà lì come modificata; puoi fare un'altra commit per aggiungerli alla cronologia del progetto. Ogni volta che fai una commit, stai salvando un'istantanea (`snapshot`) del tuo progetto che puoi ripristinare o confrontare in seguito.
 
 ### Saltare l'Area di Stage ###
 

From cff23ade18004f0b2483c0118f7d8181abb5ad6d Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Mon, 14 Apr 2014 15:05:38 +0200
Subject: [PATCH 294/690] [it] Chapter 2

Skipping the Staging Area
---
 it/02-git-basics/01-chapter2.markdown | 22 ++++++++++++----------
 1 file changed, 12 insertions(+), 10 deletions(-)

diff --git a/it/02-git-basics/01-chapter2.markdown b/it/02-git-basics/01-chapter2.markdown
index 119c64a2b..8e164ee86 100644
--- a/it/02-git-basics/01-chapter2.markdown
+++ b/it/02-git-basics/01-chapter2.markdown
@@ -332,22 +332,24 @@ Hai creato la tua prima commit! Puoi vedere che la commit restituisce alcune inf
 
 Ricorda che la commit registra lo snapshot che hai salvato nella tua area di `stage`. Qualsiasi cosa che non è nello `stage` rimarrà lì come modificata; puoi fare un'altra commit per aggiungerli alla cronologia del progetto. Ogni volta che fai una commit, stai salvando un'istantanea (`snapshot`) del tuo progetto che puoi ripristinare o confrontare in seguito.
 
-### Saltare l'Area di Stage ###
+### Saltare l'area di stage ###
 
-Anche se può essere estremamente utile per amministrare i commit esattamente come li vuoi, l'area di stage è molto più complessa di quanto tu possa averne bisogno nel lavoro normale. Se vuoi saltare l'area di parcheggio, Git fornisce una semplice scorciatoia. Passando l'opzione `-a` al comando `git commit` Git automaticamente parcheggia tutti i file che sono già stati tracciati facendo il commit, permettendoti di saltare la parte `git add`:
+Sebbene sia estremamente utile per amministrare le commit come vuoi, l'area di stage è molto più complessa di quanto tu possa averne bisogno nel lavoro normale. Se vuoi saltare l'area di `stage`, Git fornisce una semplice accorciatoia. Con l'opzione `-a` al comando `git commit`, Git, committando, mette automaticamente nello `stage` tutti i file che erano già tracciati, permettendoti di saltare la parte `git add`:
 
 	$ git status
-	# On branch master
-	#
-	# Changes not staged for commit:
-	#
-	#	modified:   benchmarks.rb
-	#
+	On branch master
+	Changes not staged for commit:
+	  (use "git add <file>..." to update what will be committed)
+	  (use "git checkout -- <file>..." to discard changes in working directory)
+	
+	        modified:   benchmarks.rb
+	
+	no changes added to commit (use "git add" and/or "git commit -a")
 	$ git commit -a -m 'added new benchmarks'
 	[master 83e38c7] added new benchmarks
-	 1 files changed, 5 insertions(+), 0 deletions(-)
+	 1 files changed, 5 insertions(+)
 
-Nota come non hai bisogno, in questo caso, di lanciare `git add` sul file benchmarks.rb prima del commit.
+Nota come in questo caso non hai bisogno di eseguire `git add` per benchmarks.rb prima della commit.
 
 ### Rimuovere File ###
 

From 3cdd2610e87408e305016e54e2eb61e322ca1fc0 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Mon, 14 Apr 2014 15:16:55 +0200
Subject: [PATCH 295/690] [it] Reviewed "Removing Files"

---
 it/02-git-basics/01-chapter2.markdown | 46 +++++++++++++--------------
 1 file changed, 23 insertions(+), 23 deletions(-)

diff --git a/it/02-git-basics/01-chapter2.markdown b/it/02-git-basics/01-chapter2.markdown
index 8e164ee86..836e6f35a 100644
--- a/it/02-git-basics/01-chapter2.markdown
+++ b/it/02-git-basics/01-chapter2.markdown
@@ -351,50 +351,50 @@ Sebbene sia estremamente utile per amministrare le commit come vuoi, l'area di s
 
 Nota come in questo caso non hai bisogno di eseguire `git add` per benchmarks.rb prima della commit.
 
-### Rimuovere File ###
+### Rimuovere i file ###
 
-Per rimuovere un file con Git, hai bisogno di rimuoverlo dai file tracciati (più precisamente,  rimuoverlo dall'area di stage) e poi di fare il commit. Il comando `git rm` fa questo ed inoltre rimuove il file dalla tua directory di lavoro così non lo vedrai come un file non tracciato la prossima volta.
+Per rimuovere un file da Git devi rimuoverlo dai file tracciati (più precisamente,  rimuoverlo dall'area di `stage`) e quindi committare. Il comando `git rm` fa questo e lo rimuove dalla tua directory di lavoro, così che la prossima volta non lo vedrai come un file non tracciato.
 
-Se semplicemente rimuovi il file dalla directory di lavoro, sarà visto sotto l'area "Changes not staged for commit" (cioè, _non parcheggiato_) dell'output `git status`:
+Se rimuovi semplicemente il file dalla directory di lavoro, apparirà nella sezione "Changes not staged for commit" (cioè, _no in `stage_) dell'output `git status`:
 
 	$ rm grit.gemspec
 	$ git status
-	# On branch master
-	#
-	# Changes not staged for commit:
-	#   (use "git add/rm <file>..." to update what will be committed)
-	#
-	#       deleted:    grit.gemspec
-	#
+	On branch master
+	Changes not staged for commit:
+	  (use "git add/rm <file>..." to update what will be committed)
+	  (use "git checkout -- <file>..." to discard changes in working directory)
+	
+	        deleted:    grit.gemspec
+	
+	no changes added to commit (use "git add" and/or "git commit -a")
 
-Poi, se lanci `git rm`, parcheggia il file rimosso:
+Se poi esegui `git rm`, la rimozione del file viene messa nello `stage:
 
 	$ git rm grit.gemspec
 	rm 'grit.gemspec'
 	$ git status
-	# On branch master
-	#
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#       deleted:    grit.gemspec
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        deleted:    grit.gemspec
+	
 
-La prossima volta che fai il commit, il file se ne andrà e non sarà più tracciato. Se modifichi il file e già aggiunto all'indice, devi forzarne la rimozione con l'opzione `-f`. Questa è una caratteristica di sicurezza per prevenire la rimozione accidentale dei dati che non sono ancora stati registrati in uno snapshot e che non possono essere recuperati da Git.
+La prossima volta che committerai, il file sparirà e non sarà più tracciato. Se avevi già modificato il file e lo avevi aggiunto all'indice, devi forzarne la rimozione con l'opzione `-f`. Questa è una misura di sicurezza per prevenire la rimozione accidentale dei dati che non sono ancora stati salvati in uno `snapshot` e che non possono essere recuperati con Git.
 
-Un'altra cosa utile che potresti voler fare è mantenere il file nel tuo albero di lavoro ma rimuoverlo dall'area di stage. In altre parole, vuoi mantenere il file sul tuo disco ma non vuoi che Git ne mantenga ancora traccia. Questo è particolarmente utile se ti dimentichi di aggiungere qualcosa al tuo file `.gitignore` ed accidentalmente lo aggiungi, come un lungo file di log od un gruppo di file `.a` compilati. Per fare questo, usa l'opzione `--cached`:
+Un'altra cosa utile che potresti voler fare è mantenere il file nel tuo ambiente di di lavoro ma rimuoverlo dall'area di `stage`. In altre parole, vuoi mantenere il file sul tuo disco ma non vuoi che Git continui a tracciarlo. Questo è particolarmente utile se hai dimenticato di aggiungere qualcosa al tuo `.gitignore` e accidentalmente lo metti in `stage`, come un file di log molto grande o un gruppo di file compilati `.a`. Per farlo usa l'opzione `--cached`:
 
 	$ git rm --cached readme.txt
 
-Puoi passare file, directory o glob pattern di file al comando `git rm`. Questo significa che puoi fare cose come
+Puoi passare file, directory o pattern glob di file al comando `git rm`. Questo significa che puoi fare
 
 	$ git rm log/\*.log
 
-Nota la barra inversa (`\`) di fronte a `*`. Questo è necessario perché Git ha una sua espansione dei nomi di file in aggiunta all'espansione dei filename della tua shell. Questo comando rimuove tutti i file che hanno l'estensione `.log` nella directory `log/`. O puoi fare qualcosa di simile a:
+Nota la barra inversa (`\`) prima di `*`. Questo è necessario perché Git ha un'espansione propria dei nomi di file oltre a quella della tua shell. Questo comando rimuove tutti i file che hanno l'estensione `.log` nella directory `log/`. O puoi eseguire:
 
 	$ git rm \*~
 
-Questo comando rimuove tutti i file che finiscono con `~`.
+Per rimuovere tutti i file che finiscono con `~`.
 
 ### Muovere File ###
 

From 31228b29bff3bf077a4fb09fac717ce2a74ce719 Mon Sep 17 00:00:00 2001
From: lusecond <375441004@qq.com>
Date: Mon, 14 Apr 2014 22:34:48 +0800
Subject: [PATCH 296/690] Update 01-chapter3.markdown
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

笔误修改

原文：You can take the changes on client that aren’t on server (C8 and C9) and replay them on your master branch by using the --onto option of git rebase
---
 zh/03-git-branching/01-chapter3.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/zh/03-git-branching/01-chapter3.markdown b/zh/03-git-branching/01-chapter3.markdown
index 643c697cc..70473c28e 100644
--- a/zh/03-git-branching/01-chapter3.markdown
+++ b/zh/03-git-branching/01-chapter3.markdown
@@ -526,7 +526,7 @@ Insert 18333fig0330.png
 Insert 18333fig0331.png
 图 3-31. 从一个特性分支里再分出一个特性分支的历史。
 
-假设在接下来的一次软件发布中，我们决定先把客户端的修改并到主线中，而暂缓并入服务端软件的修改（因为还需要进一步测试）。这个时候，我们就可以把基于 `server` 分支而非 `master` 分支的改变（即 C8 和 C9），跳过 `server` 直接放到 `master` 分支中重演一遍，但这需要用 `git rebase` 的 `--onto` 选项指定新的基底分支 `master`：
+假设在接下来的一次软件发布中，我们决定先把客户端的修改并到主线中，而暂缓并入服务端软件的修改（因为还需要进一步测试）。这个时候，我们就可以把基于 `client` 分支而非 `server` 分支的改变（即 C8 和 C9），跳过 `server` 直接放到 `master` 分支中重演一遍，但这需要用 `git rebase` 的 `--onto` 选项指定新的基底分支 `master`：
 
 	$ git rebase --onto master server client
 

From ec085463a98c60c63a49af7733563d24f430205d Mon Sep 17 00:00:00 2001
From: Volkan Gezer <wakeup@users.noreply.github.com>
Date: Mon, 14 Apr 2014 19:49:53 +0200
Subject: [PATCH 297/690] Update 01-chapter3.markdown

---
 tr/03-git-branching/01-chapter3.markdown | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/tr/03-git-branching/01-chapter3.markdown b/tr/03-git-branching/01-chapter3.markdown
index 7eed43e7c..a9a150577 100644
--- a/tr/03-git-branching/01-chapter3.markdown
+++ b/tr/03-git-branching/01-chapter3.markdown
@@ -472,21 +472,21 @@ Diyelim ki uzak bir dalla yapacaklarınız bitti ve siz ile takım arkadaşları
 
 İşte bu! Artık sunucunuzda bu dal olmayacak. Bu sayfayı dikkatlice anlamak isteyebilirsiniz, çünkü muhtemelen bu komuta ihtiyacınız olacak ancak sözdizimini unutacaksınız. Bu komutu hatırlamanın bir yolu daha önceden biraz bahsedilen `git push [uzakadı] [yereldal]:[uzakdal]` sözdizimini hatırlamaktır. Eğer `[yereldal]` kısmını yazmazsanız, aslında dediğiniz şey “Benim tarafımdan bir şey alma ancak `[uzakdal]`dan al.”
 
-## Rebasing (Tekrar Adresleme) ## Zemin, Kök, Temel
+## Rebasing (Tekrar Adresleme) ##
 
 Git içerisinde, değişiklikleri bir daldan diğerine bütünleştirmek için iki temel yol bulunuyor: `merge` ve `rebase`. Bu bölümde sadece rebase komutunun ne olduğunu, nasıl yapılacağını, neden mükemmel bir araç olduğunu ve hangi durumlarda kullanmak istemeyeceğinizi öğreneceksiniz.
 
-### The Basic Rebase ###
+### Temel Tekrar Adresleme ###
 
-If you go back to an earlier example from the Merge section (see Figure 3-27), you can see that you diverged your work and made commits on two different branches.
+Birleştirme kısmındaki örneğe geri giderseniz (Figür 3-27'ye bakın), çalışmanızı ayırdığınızı ve iki farklı dal üzerinde gönderi yaptığınızı görebilirsiniz.
 
 Insert 18333fig0327.png 
-Figure 3-27. Your initial diverged commit history.
+Figure 3-27. İlk ayrılan gönderi geçmişi.
 
-The easiest way to integrate the branches, as we’ve already covered, is the `merge` command. It performs a three-way merge between the two latest branch snapshots (C3 and C4) and the most recent common ancestor of the two (C2), creating a new snapshot (and commit), as shown in Figure 3-28.
+Dalları bütünlemenin en kolay yolu - daha önceden anlattığımız gibi - `merge` komutudur. Bu komut, en son iki dal bellek kopyası (C3 ve C4) ve ikisinin en yakın ortak atası (C2) arasında üç yönlü bir birleştirme yapar. Bunun sonucunda yeni bir bellek kopyası (ve gönderi) oluşturur. Bkz. Figür 3-28.
 
 Insert 18333fig0328.png 
-Figure 3-28. Merging a branch to integrate the diverged work history.
+Figure 3-28. Ayrılmış çalışma geçmişini bütünleştirmek için bir dal birleştirmek.
 
 However, there is another way: you can take the patch of the change that was introduced in C3 and reapply it on top of C4. In Git, this is called _rebasing_. With the `rebase` command, you can take all the changes that were committed on one branch and replay them on another one.
 

From 3f6c10594c51ac7b61dab0115c5f43740ef7093b Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Mon, 14 Apr 2014 23:03:07 +0200
Subject: [PATCH 298/690] Editing 01-chapter6.markdown

To update rebase message with new output
---
 en/06-git-tools/01-chapter6.markdown | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/en/06-git-tools/01-chapter6.markdown b/en/06-git-tools/01-chapter6.markdown
index 36459d56e..ac08f55e4 100644
--- a/en/06-git-tools/01-chapter6.markdown
+++ b/en/06-git-tools/01-chapter6.markdown
@@ -566,12 +566,19 @@ Running this command gives you a list of commits in your text editor that looks
 	#
 	# Commands:
 	#  p, pick = use commit
+	#  r, reword = use commit, but edit the commit message
 	#  e, edit = use commit, but stop for amending
 	#  s, squash = use commit, but meld into previous commit
+	#  f, fixup = like "squash", but discard this commit's log message
+	#  x, exec = run command (the rest of the line) using shell
+	#
+	# These lines can be re-ordered; they are executed from top to bottom.
 	#
 	# If you remove a line here THAT COMMIT WILL BE LOST.
+	#
 	# However, if you remove everything, the rebase will be aborted.
 	#
+	# Note that empty commits are commented out
 
 It’s important to note that these commits are listed in the opposite order than you normally see them using the `log` command. If you run a `log`, you see something like this:
 
@@ -636,12 +643,19 @@ It’s also possible to take a series of commits and squash them down into a sin
 	#
 	# Commands:
 	#  p, pick = use commit
+	#  r, reword = use commit, but edit the commit message
 	#  e, edit = use commit, but stop for amending
 	#  s, squash = use commit, but meld into previous commit
+	#  f, fixup = like "squash", but discard this commit's log message
+	#  x, exec = run command (the rest of the line) using shell
+	#
+	# These lines can be re-ordered; they are executed from top to bottom.
 	#
 	# If you remove a line here THAT COMMIT WILL BE LOST.
+	#
 	# However, if you remove everything, the rebase will be aborted.
 	#
+	# Note that empty commits are commented out
 
 If, instead of "pick" or "edit", you specify "squash", Git applies both that change and the change directly before it and makes you merge the commit messages together. So, if you want to make a single commit from these three commits, you make the script look like this:
 

From a8d93bb15c32dc80d59d307cb1eaee5bff9c228f Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Mon, 14 Apr 2014 16:55:28 +0200
Subject: [PATCH 299/690] [it] Reviewed "Moving Files"

---
 it/02-git-basics/01-chapter2.markdown | 26 ++++++++++++--------------
 1 file changed, 12 insertions(+), 14 deletions(-)

diff --git a/it/02-git-basics/01-chapter2.markdown b/it/02-git-basics/01-chapter2.markdown
index 836e6f35a..c17fdb69e 100644
--- a/it/02-git-basics/01-chapter2.markdown
+++ b/it/02-git-basics/01-chapter2.markdown
@@ -396,34 +396,32 @@ Nota la barra inversa (`\`) prima di `*`. Questo è necessario perché Git ha un
 
 Per rimuovere tutti i file che finiscono con `~`.
 
-### Muovere File ###
+### Spostare i file ###
 
-A differenza di altri sistemi VCS, Git non traccia esplicitamente i movimenti di file. Se rinomini un file in Git, nessun metadato è immagazzinato in Git che ti dirà che hai rinominato il file. Tuttavia, Git è abbastanza intelligente da capirlo dopo che è avvenuto — ci occuperemo di rilevare il movimento dei file più tardi.
+A differenza di altri sistemi VCS, Git non traccia esplicitamente gli spostamenti dei file. Se rinomini un file in Git, nessun metadato viene salvato per dirgli che lo hai rinominato. Tuttavia, Git è abbastanza intelligente da capirlo dopo che l'hai fatto — più in la ci occuperemo di rilevare il movimento dei file.
 
-Perciò crea un po' di confusione il fatto che Git  abbia un comando `mv`. Se vuoi rinominare un file in Git, puoi lanciare qualcosa come
+Può perciò creare un po' di confusione il fatto che Git abbia un comando `mv`. Se vuoi rinominare un file in Git puoi eseguire qualcosa come
 
 	$ git mv file_from file_to
 
-e questo funziona bene. Infatti, se lanci qualcosa come questo e guardi lo stato, vedrai che Git considera il file rinominato:
+e funziona. Se, infatti, lanci un comando del genere e controlli lo stato, vedrai che Git considera il file rinominato:
 
 	$ git mv README.txt README
 	$ git status
-	# On branch master
-	# Your branch is ahead of 'origin/master' by 1 commit.
-	#
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#       renamed:    README.txt -> README
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        renamed:    README.txt -> README
+	
 
-Ovviamente, questo è equivalente a lanciare qualcosa come:
+Ovviamente, questo è equivalente a eseguire:
 
 	$ mv README.txt README
 	$ git rm README.txt
 	$ git add README
 
-Git capisce implicitamente che è stato rinominato, così non è un problema rinominare un file in questo modo o con il comando `mv`. L'unica reale differenza è che `mv` è un solo comando invece di tre — è un comando di convenienza.  Più importante è che tu puoi usare qualsiasi strumento per rinominare un file, ed aggiungere/togliere più tardi, prima di un commit.
+Git capisce che, implicitamente stai rinominando il file, così che non c'è differenza se rinominare un file in questo modo o con il comando `mv`. L'unica differenza reale è che `mv` è un solo comando invece di tre: è un questione di convenienza. La cosa più importante è che puoi usare qualsiasi strumento per rinominare un file, e gestire l'aggiunta/rimozione più tardi, prima della commit.
 
 ## Vedere la Storia dei Commit ##
 

From c96cc2d9cc3891ac9b575301fbb72e5bf3d52bca Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Mon, 14 Apr 2014 17:36:01 +0200
Subject: [PATCH 300/690] [it] Reviewed "Viewing the Commit History"

---
 it/02-git-basics/01-chapter2.markdown | 123 ++++++++++++++------------
 1 file changed, 68 insertions(+), 55 deletions(-)

diff --git a/it/02-git-basics/01-chapter2.markdown b/it/02-git-basics/01-chapter2.markdown
index c17fdb69e..61ab44fb5 100644
--- a/it/02-git-basics/01-chapter2.markdown
+++ b/it/02-git-basics/01-chapter2.markdown
@@ -423,15 +423,15 @@ Ovviamente, questo è equivalente a eseguire:
 
 Git capisce che, implicitamente stai rinominando il file, così che non c'è differenza se rinominare un file in questo modo o con il comando `mv`. L'unica differenza reale è che `mv` è un solo comando invece di tre: è un questione di convenienza. La cosa più importante è che puoi usare qualsiasi strumento per rinominare un file, e gestire l'aggiunta/rimozione più tardi, prima della commit.
 
-## Vedere la Storia dei Commit ##
+## Vedere la cronologia delle commit ##
 
-Dopo che hai creato un po' di commit, o se hai clonato un repository che contiene una storia di commit, probabilmente vuoi guardare indietro per vedere cosa è successo. Lo strumento base e più potente per farlo è il comando `git log`.
+Dopo che avrai creato un po' di commit, o se hai clonato un repository che già ha la sua cronologia di commit, vorrai probabilmente guardare cos'è successo nel passato. Lo strumento essenziale e quello più potente per farlo è il comando `git log`.
 
-Questi esempi usano un progetto veramente semplice chiamato simplegit che è spesso usato per le dimostrazioni. Per ottenere il progetto, lancia:
+Questi esempi usano un progetto veramente semplice chiamato `simplegit` che uso spesso per gli esempi. Per ottenere il progetto, esegui
 
 	git clone git://github.com/schacon/simplegit-progit.git
 
-Quando lanci `git log` in questo progetto, dovresti avere un output che assomiglia a questo:
+Quando esegui `git log` in questo progetto, dovresti avere un output che assomiglia a questo:
 
 	$ git log
 	commit ca82a6dff817ec66f44342007202690a93763949
@@ -452,11 +452,11 @@ Quando lanci `git log` in questo progetto, dovresti avere un output che assomigl
 
 	    first commit
 
-In modo predefinito, senza argomenti, `git log` mostra i commit fatti nel repository in ordine cronologico inverso. Così, il commit più recente è mostrato all'inizio. Come puoi vedere, questo comando elenca ogni commit con il suo codice SHA-1, il nome dell'autore e la sua e-mail, la data di scrittura ed il messaggio di invio.
+In modo predefinito, senza argomenti, `git log` mostra le commit fatte nel repository in ordine cronologico inverso. In questo modo la commit più recente è la prima ad apparire. Come vedi, questo comando elenca ogni commit con il suo codice SHA-1, il nome e l'email dell'autore, la data di salvataggio e il messaggio della commit.
 
-Un enorme numero e varietà di opzioni da passare al comando `git log` sono disponibili per vedere esattamente cosa si sta cercando. Qui, vedremo alcune opzioni più usate.
+Sono disponibili moltissime opzioni da passare al comando `git log` per vedere esattamente quello che stai cercando. Qui ne vedremo alcune tra quelle più usate.
 
-Una delle opzioni più utili è `-p`, che mostra l'introduzione del diff di ogni commit. Puoi anche usare `-2`, che limita l'output solamente agli ultimi due ingressi: 
+Una delle opzioni più utili è `-p`, che mostra le differenze introdotte da ciascuna commit. Puoi usare anche `-2`, che limita l'output agli ultimi due elementi: 
 
 	$ git log -p -2
 	commit ca82a6dff817ec66f44342007202690a93763949
@@ -469,11 +469,13 @@ Una delle opzioni più utili è `-p`, che mostra l'introduzione del diff di ogni
 	index a874b73..8f94139 100644
 	--- a/Rakefile
 	+++ b/Rakefile
-	@@ -5,7 +5,7 @@ require 'rake/gempackagetask'
+	@@ -5,5 +5,5 @@ require 'rake/gempackagetask'
 	 spec = Gem::Specification.new do |s|
+	     s.name      =   "simplegit"
 	-    s.version   =   "0.1.0"
 	+    s.version   =   "0.1.1"
 	     s.author    =   "Scott Chacon"
+	     s.email     =   "schacon@gee-mail.com
 
 	commit 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7
 	Author: Scott Chacon <schacon@gee-mail.com>
@@ -496,28 +498,29 @@ Una delle opzioni più utili è `-p`, che mostra l'introduzione del diff di ogni
 	-end
 	\ No newline at end of file
 
-Questa opzione visualizza le stessi informazioni ma direttamente seguita dal diff di ogni voce. Questo è veramente utile per la revisione del codice o per sfogliare velocemente cosa è successo in una serie di commit che un collaboratore ha aggiunto.
+Quest'opzione mostra le stessi informazioni ma ciascun elemento è seguito dalle differenze. Questo è molto utile per revisionare il codice o per dare un'occhiata veloce a cosa è successo in una serie di commit che un collaboratore ha aggiunto.
 
-Qualche volta è più semplice controllare i cambiamenti per parole piuttosto che per linee. Esiste un'opzione `--word-diff` disponibile in Git, che puoi aggiungere al comando `git log -p` per ottenere un word diff (differenza per parole, ndt) invece del normale diff linea per linea. Il formato Word diff è piuttosto inutile quando applicato al codice sorgente, ma diviene utile quando applicato a grandi file di testo, come libri o la tua dissertazione. Ecco un esempio:
+Qualche volta è più semplice verificare le singole modifiche piuttosto che intere righe. Per questo in Git è disponibile l'opzione `--word-diff`, che puoi aggiungere al comando `git log -p` per vedere le differenze tra le parole invece di quella normale, linea per linea. Il formato `word diff` è piuttosto inutile quando applicato al codice sorgente, ma diventa utile quando applicato a grandi file di testo, come i libri o la tua tesi. Ecco un esempio:
 
 	$ git log -U1 --word-diff
-	commit da734f4151c0bf92798edd67fb571f86ab4179e6
-	Author: Jed Hartman <jhartman@google.com>
-	Date:   Tue Mar 19 18:00:35 2013 -0700
-
-	    Added a missing "in" to a sentence.
+	commit ca82a6dff817ec66f44342007202690a93763949
+	Author: Scott Chacon <schacon@gee-mail.com>
+	Date:   Mon Mar 17 21:52:11 2008 -0700
 
-	diff --git a/en/01-chapter2.markdown b/en/01-chapter2.markdown
-	index 879e48c..a992ff3 100644
-	--- a/en/01-chapter2.markdown
-	+++ b/en/01-chapter2.markdown
-	@@ -553,3 +553,3 @@ You may be wondering what the difference is
+	    changed the version number
 
-	This option adds a nice little ASCII graph showing your branch and merge history, which we can see {+in+} our copy of the Grit project repository:
+	diff --git a/Rakefile b/Rakefile
+	index a874b73..8f94139 100644
+	--- a/Rakefile
+	+++ b/Rakefile
+	@@ -7,3 +7,3 @@ spec = Gem::Specification.new do |s|
+	    s.name      =   "simplegit"
+	    s.version   =   [-"0.1.0"-]{+"0.1.1"+}
+	    s.author    =   "Scott Chacon"
 
-Come puoi vedere, non ci sono linee aggiunte o rimosse in questo output come in un normale diff. Invece i cambiamenti sono mostrati sulla linea. Puoi vedere la parola racchiusa in `{+ +}` (parole rimosse sarebbe state mostrate come `[-removed-]`). Potresti anche volere ridurre le solite tre linee di contesto nell'output di diff a solo una linea, dato che il contesto è ora costituito da parole, non linee. Puoi farlo con `-U1` come abbiamo fatto nell'esempio qui sopra.
+Come puoi vedere, non ci sono righe aggiunte o rimosse in questo output, come in una normale differenza. I cambiamente sono invece mostrati sulla stessa riga. Puoi vedere la parola aggiunta racchiusa tra `{+ +}` e quella rimossa tra `[- -]`. Potresti anche volere ridurre le solite tre righe di contesto dall'output delle differenze a una sola, poiché ora il contesto è costituito da parole e non righe. Puoi farlo con `-U1`, come abbiamo fatto nell'esempio qui sopra.
 
-Puoi anche usare una serie di opzioni di riassunto con `git log`. Per esempio, se vuoi vedere alcune statistiche brevi per ogni commit, puoi usare l'opzione `--stat`:
+Puoi usare anche una serie di opzioni di riassunto con `git log`. Per esempio, se vuoi vedere alcune statistiche brevi per ciascuna commit, puoi usare l'opzione `--stat`:
 
 	$ git log --stat
 	commit ca82a6dff817ec66f44342007202690a93763949
@@ -527,7 +530,7 @@ Puoi anche usare una serie di opzioni di riassunto con `git log`. Per esempio, s
 	    changed the version number
 
 	 Rakefile |    2 +-
-	 1 files changed, 1 insertions(+), 1 deletions(-)
+	 1 file changed, 1 insertion(+), 1 deletion(-)
 
 	commit 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7
 	Author: Scott Chacon <schacon@gee-mail.com>
@@ -536,7 +539,7 @@ Puoi anche usare una serie di opzioni di riassunto con `git log`. Per esempio, s
 	    removed unnecessary test code
 
 	 lib/simplegit.rb |    5 -----
-	 1 files changed, 0 insertions(+), 5 deletions(-)
+	 1 file changed, 5 deletions(-)
 
 	commit a11bef06a3f659402fe7563abf99ad00de2209e6
 	Author: Scott Chacon <schacon@gee-mail.com>
@@ -547,45 +550,50 @@ Puoi anche usare una serie di opzioni di riassunto con `git log`. Per esempio, s
 	 README           |    6 ++++++
 	 Rakefile         |   23 +++++++++++++++++++++++
 	 lib/simplegit.rb |   25 +++++++++++++++++++++++++
-	 3 files changed, 54 insertions(+), 0 deletions(-)
+	 3 files changed, 54 insertions(+)
 
-Come puoi vedere, l'opzione `--stat` stampa sotto ogni voce di commit una lista dei file modificati, quanti file sono stati modificati, e quante linee in questi file sono state aggiunte o rimosse. Inoltre aggiunge un resoconto delle informazioni alla fine.
-Un'altra opzione veramente utile è `--pretty`. Questa opzione modifica gli output di log per la formattazione rispetto a quella predefinita. Alcune opzioni pre-costruite sono pronte all'uso. L'opzione  `oneline` stampa ogni commit in una singola linea, che è utile se stai guardando una lunga serie di commit. In aggiunta le opzioni `sort`, `full` e `fuller` mostrano l'output pressapoco nello stesso modo ma con più o meno informazioni, rispettivamente:
+Come puoi vedere, l'opzione `--stat` visualizza sotto ogni commit la lista dei file modificati, quanti file sono stati modificati, e quante righe in questi file sono state aggiunte e rimosse. Alla fine aggiunge anche un resoconto delle informazioni.
+Un'altra opzione veramente utile è `--pretty`. Questa opzione modifica gli output di log rispetto a quella predefinita. Alcune opzioni predefinite sono pronte per l'uso. L'opzione  `oneline` visualizza ogni commit su una singola linea, che è utile se stai controllando una lunga serie di commit. In aggiunta le opzioni `short`, `full` e `fuller` mostrano più o meno lo stesso output ma con più o meno informazioni, rispettivamente:
 
 	$ git log --pretty=oneline
 	ca82a6dff817ec66f44342007202690a93763949 changed the version number
 	085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7 removed unnecessary test code
 	a11bef06a3f659402fe7563abf99ad00de2209e6 first commit
 
-L'opzione più interessante è `format`, che ti permette di specificare la tua formattazione dell'output di log. Questa è specialmente utile quando stai generando un output da analizzare su una macchina —  perché specifichi in modo preciso il formato, sai che non cambierà con gli aggiornamenti di Git:
+L'opzione più interessante è `format`, che ti permette di specificare la formattazione dell'output di log. Questa è specialmente utile quando stai generando un output che sarà analizzo da una macchina, perché specificando esplicitamente il formato, sai che non cambierà con gli aggiornamenti di Git:
 
 	$ git log --pretty=format:"%h - %an, %ar : %s"
 	ca82a6d - Scott Chacon, 11 months ago : changed the version number
 	085bb3b - Scott Chacon, 11 months ago : removed unnecessary test code
 	a11bef0 - Scott Chacon, 11 months ago : first commit
 
-La Tabella 2-1 elenca alcune delle opzioni più utili da usare.
+Table 2-1 lists some of the more useful options that format takes.
+
+<!-- Messaggio per i traduttori: questa è una tabella dichiarativa.
+Le righe devono essere formattate come segue:
+<TAB><Prima colonna di testo><TAB><Seconda colunna di testo>
+-->
 
 	Opzione	Descrizione dell'output
-	%H	Hash commit
-	%h	Hash commit abbreviato
-	%T	Hash tree
-	%t	Hash tree abbreviato
-	%P	Hash genitore
-	%p	Hash genitore abbreviati
-	%an	Nome autore
-	%ae	E-mail autore
-	%ad	Data autore (rispetta il formato dell'opzione –date= )
-	%ar	Data autore, relativa
-	%cn	Nome di chi ha fatto il commit
-	%ce	E-mail di chi ha fatto il commit
-	%cd	Data di chi ha fatto il commit
-	%cr	Data di chi ha fatto il commit, relativa
+	%H	Hash della commit
+	%h	Hash della commit abbreviato
+	%T	Hash dell'albero
+	%t	Hash dell'albero abbreviato
+	%P	Hash del genitore
+	%p	Hash del genitore abbreviato
+	%an	Nome dell'autore
+	%ae	e-mail dell'autore
+	%ad	Data di commit dell'autore (il formato rispetta l'opzione --date=)
+	%ar	Data relativa di commit dell'autore
+	%cn	Nome di chi ha fatto la commit (`committer`, in inglese)
+	%ce	e-mail di chi ha fatto la commit
+	%cd	Data della commit
+	%cr	Data relativa della commit
 	%s	Oggetto
 
-Sarai sorpreso dalla differenza tra _author_ (l'autore) e _committer_ (chi ha eseguito il commit). L'autore è la persona che ha scritto originariamente il lavoro, mentre chi ha eseguito il commit è la persona che per ultima ha applicato il lavoro. Così, se invii una patch ad un progetto ed uno dei membri del progetto applica la patch, entrambi sarete riconosciuti — tu come l'autore ed il membro del progetto come colui il quale ha eseguito il commit. Scopriremo meglio questa distinzione nel Capitolo 5.
+Potresti essere sorpreso dalla differenza tra autore e _committer_ (chi ha eseguito la commit). L'autore è la persona che ha scritto la modifica, mentre il _committer_ è l'ultima persona che ha applicato la modifica. Così, se invii una modifica a un progetto ed uno dei membri principali del progetto la applica, ne avranno entrambi il riconoscimento — tu come l'autore ed il membro del progetto come chi l'ha committata. Vedremo meglio questa distinzione nel *Capitolo 5*.
 
-Le opzioni oneline e format sono particolarmente utili con un'altra opzione `log` chiamata `--graph`. Questa opzione aggiunge un grafico ASCII carino che mostra le diramazioni e le unioni della storia, che possiamo vedere nella copia del repository del progetto Grit:
+Le opzioni `oneline` e `format` sono particolarmente utili con un'altra opzione di `log` chiamata `--graph`. Questa aggiunge un piccolo grafico ASCII carino che mostra le diramazioni e le unioni della cronologia, che possiamo vedere nella copia del repository del progetto Grit:
 
 	$ git log --pretty=format:"%h %s" --graph
 	* 2d3acf9 ignore errors from SIGCHLD on trap
@@ -601,17 +609,22 @@ Le opzioni oneline e format sono particolarmente utili con un'altra opzione `log
 
 Queste sono solo alcune opzioni semplici per la formattazione dell'output di `git log` — ce ne sono altre. La tabella 2-2 elenca le opzioni che abbiamo visto prima e altre opzioni comunemente usate che possono essere utili per cambiare l'output del comando log.
 
+<!-- Messaggio per i traduttori: questa è una tabella dichiarativa.
+Le righe devono essere formattate come segue:
+<TAB><Prima colonna di testo><TAB><Seconda colunna di testo>
+-->
+
 	Opzione	Descrizione
-	-p	Mostra la patch introdotta per ogni commit.
-	--word-diff	Mostra la patch nel formato word diff.
+	-p	Mostra la modifica introdotta con ogni commit.
+	--word-diff	Mostra la modifica nel formato `word diff`.
 	--stat	Mostra le statistiche per i file modificati in ogni commit.
-	--shortstat	Mostra solo le linee cambiate/inserite/cancellate dal comando --stat.
-	--name-only	Mostra la lista dei file modificati dopo le informazione del commit.
-	--name-status	Mostra la lista dei file con le informazioni di aggiunte/modifiche/rimozioni.
-	--abbrev-commit	Mostra solo i primi caratteri del codice checksum SHA-1 invece di tutti e 40.
-	--relative-date	Mostra la data in un formato relativo (per esempio, "2 week ago", "2 settimane fa") invece di usare l'intero formato della data.
-	--graph	Mostra un grafico ASCII dei rami e delle unioni della storia accando all'output di log.
-	--pretty	Mostra i commit in un formato alternativo. L'opzione include oneline, short, full, fuller, e format (dove hai specificato la tua formattazione).
+	--shortstat	Mostra solo le righe cambiate/aggiunte/rimosse del comando --stat.
+	--name-only	Mostra l'elenco dei file modificati dopo le informazione della commit.
+	--name-status	Mostra l'elenco dei file con le informazioni  aggiunte/modifiche/eliminate.
+	--abbrev-commit	Mostra solo i primi caratteri del codice SHA-1 invece di tutti i 40.
+	--relative-date	Mostra la data in un formato relativo (per esempio, "2 week ago", "2 settimane fa") invece di usare il formato completo della data.
+	--graph	Mostra un grafico ASCII delle diramazioni e delle unioni della cronologia insieme all'output del log.
+	--pretty	Mostra le commit in un formato alternativo. L'opzione include oneline, short, full, fuller, e format (quando specifichi un tuo formato).
 	--oneline	Un'opzione di convenienza abbreviazione per `--pretty=oneline --abbrev-commit`.
 
 ### Limitare l'Output di Log ###

From 02ce2ca3e7edd6449be179c2f4dac539a557bcd1 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Tue, 15 Apr 2014 22:34:14 +0200
Subject: [PATCH 301/690] [it] Reviewed chapter2

Reviewed "Limiting Log Output"
---
 it/02-git-basics/01-chapter2.markdown | 29 ++++++++++++++++-----------
 1 file changed, 17 insertions(+), 12 deletions(-)

diff --git a/it/02-git-basics/01-chapter2.markdown b/it/02-git-basics/01-chapter2.markdown
index 61ab44fb5..7b882b241 100644
--- a/it/02-git-basics/01-chapter2.markdown
+++ b/it/02-git-basics/01-chapter2.markdown
@@ -627,30 +627,35 @@ Le righe devono essere formattate come segue:
 	--pretty	Mostra le commit in un formato alternativo. L'opzione include oneline, short, full, fuller, e format (quando specifichi un tuo formato).
 	--oneline	Un'opzione di convenienza abbreviazione per `--pretty=oneline --abbrev-commit`.
 
-### Limitare l'Output di Log ###
+### Limita l'output del log ###
 
-Oltre alle opzioni per la formattazione dell'output, git log accetta un numero di opzioni di limitazione — cioè, opzioni che ti permettono di vedere solo alcuni commit. Hai già visto una opzione del genere — l'opzione `-2`, che mostra solamente gli ultimi due commit. Infatti, puoi fare `-<n>`, dove `n` è un intero per vedere gli ultimi `n` commit. In realtà, non userai spesso questa possibilità, perché Git di base veicola tutti gli output attraverso un impaginatore così vedrai solamente una pagina di log alla volta.
+Oltre alle opzioni per la formattazione dell'output, `git log` accetta una serie di utili opzioni restrittive, ovvero opzioni che ti permettono di vedere solo alcune commit. Abbiamo già visto una opzione del genere, l'opzione `-2`, che mostra solamente le ultime due commit. Infatti, puoi usare `-<n>`, dove `n` è un intero, per vedere le ultime `n` commit. In realtà non la userai spesso, perché Git accoda tutti gli output paginandoli, così vedrai solamente una pagina alla volta.
 
-Ovviamente, le opzioni di limitazione temporali come `--since` e `--until` sono molto utili. Per esempio, questo comando prende la lista dei commit fatti nelle ultime due settimane:
+Le opzioni temporali come `--since` e `--until` sono invece molto utili. Questo comando, per esempio, prende la lista dei commit fatti nelle ultime due settimane:
 
 	$ git log --since=2.weeks
 
 Questo comando funziona con molti formati —  puoi specificare una data (“2008-01-15”) o una data relativa come “2 years 1 day 3 minutes ago”.
 
-Puoi inoltre filtrare l'elenco dei commit che corrispondono a dei criteri di ricerca. L'opzione `--author` ti permette di filtrare uno specifico autore e l'opzione `--grep` permette di cercare delle parole chiave nei messaggi dei commit. (Nota che se vuoi specificare sia le opzioni author e grep, devi aggiungere `--all-match` o il comando ricercherà i commit sia di uno sia di quell'altro.)
+Puoi inoltre filtrare l'elenco delle commit che corrispondono a dei criteri di ricerca. L'opzione `--author` ti permette di filtrare per uno specifico autore e l'opzione `--grep` ti permette di cercare delle parole chiave nei messaggi delle commit. (Nota che se vuoi specificare entremba le opzioni devi usare `--all-match` o il comando ricercherà le commit che corrispondano ad almeno una delle due.)
 
-L'ultima opzione di filtro veramente utile da passare a `git log` è un percorso.  Se specifichi una directory o un nome di file, puoi limitare l'output del log ai commit che introducono modifiche a questi file. E' sempre l'ultima opzione fornita ed è generalmente preceduta dal doppio meno (`--`) per separare i path dalle opzioni.
+L'ultima opzione di `git log` per il filtraggio è il percorso. Se specifichi il nome di una directory o di un file, puoi limitare l'output del log alle sole commit che introducono modifiche a quei file. Questa è sempre l'ultima opzione specificata e generalmente è preceduta dal doppio meno (`--`) per separare i percorsi dalle opzioni.
 
 Nella tabella 2-3 vediamo una lista di riferimento di queste e di altre opzioni comuni.
 
+<!-- Attention to translators: this is a table declaration.
+The lines must be formatted as follows
+<TAB><First column text><TAB><Second column text>
+-->
+
 	Opzioni	Descrizione
-	-(n)	Vedi solo gli ultimi n commit
-	--since, --after	Limita ai commit fatti prima o dopo una data specificata.
-	--until, --before	Limita ai commit fatti prima o fino ad una specifica data.
-	--author	Visualizza solo i commit in cui l'autore corrisponde alla stringa specificata.
-	--committer	Visualizza solo i commit dove chi ha eseguito il commit corrisponde alla stringa specificata.
+	-(n)	Vedi solo le ultime n commit
+	--since, --after	Mostra solo le commit fatte dopo la data specificata.
+	--until, --before	Mostra solo le commit fatte prima della data specificata.
+	--author	Mostra solo le commit dell'autore specificato.
+	--committer	Mostra solo le commit del committer specificato.
 
-Per esempio, se vuoi vedere quali commit modificano i file nella storia del codice sorgente di Git dove Junio Hamano ha eseguito i commit  e non sono stati unificati nel mese di Ottobre del 2008, puoi lanciare qualcosa di simile a:
+Se vuoi, per esempio, vedere quale commit della cronologia di Git modificano i test e che siano state eseguite da Junio Hamano a ottobre 2008, ma che non siano ancora stati uniti, puoi eseguire questo comando:
 
 	$ git log --pretty="%h - %s" --author=gitster --since="2008-10-01" \
 	   --before="2008-11-01" --no-merges -- t/
@@ -661,7 +666,7 @@ Per esempio, se vuoi vedere quali commit modificano i file nella storia del codi
 	51a94af - Fix "checkout --track -b newbranch" on detac
 	b0ad11e - pull: allow "git pull origin $something:$cur
 
-Ci sono circa 20,000 commit nella storia del codice sorgente di git, questo comando mostra 6 righe corrispondenti ai termini di ricerca.
+Ci sono circa 20,000 commit nella cronologia dei sorgenti di git, questo comando mostra 6 righe che corrispondono ai termini della ricerca.
 
 ### Usare una GUI per Visualizzare la Storia ###
 

From f44b9c7ebb78b9d79d3c233ae6acf5d978088956 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Tue, 15 Apr 2014 22:38:19 +0200
Subject: [PATCH 302/690] [it] Reviewing chapter2

Reviewed "Using a GUI to Visualize History"
---
 it/02-git-basics/01-chapter2.markdown | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/it/02-git-basics/01-chapter2.markdown b/it/02-git-basics/01-chapter2.markdown
index 7b882b241..2851d883b 100644
--- a/it/02-git-basics/01-chapter2.markdown
+++ b/it/02-git-basics/01-chapter2.markdown
@@ -668,14 +668,14 @@ Se vuoi, per esempio, vedere quale commit della cronologia di Git modificano i t
 
 Ci sono circa 20,000 commit nella cronologia dei sorgenti di git, questo comando mostra 6 righe che corrispondono ai termini della ricerca.
 
-### Usare una GUI per Visualizzare la Storia ###
+### Usare una GUI per visualizzare la cronologia ###
 
-Se vuoi usare uno strumento più grafico per visualizzare la storia dei tuoi commit, puoi vedere un programma in Tck/Tk chiamato gitk che è distribuito con Git. Gitk è fondamentalmente uno strumento visuale come `git log`, e accetta circa tutte le opzioni di filtro che `git log` ha. Se digiti gitk dalla riga di comando del tuo progetto, dovresti vedere qualcosa di simile alla Figura 2-2.
+Se vuoi usare uno strumento più grafico per visualizzare la cronologia delle tuoe commit, puoi provare un programma in Tck/Tk chiamato `gitk` che viene distribuito con Git. Gitk è fondamentalmente uno strumento grafico come `git log`, e accetta quasi tutte le opzioni di filtro supportate da `git log`. Se digiti `gitk` dalla riga di comando nel tuo progetto, dovresti vedere qualcosa di simile alla Figura 2-2.
 
 Insert 18333fig0202.png
-Figura 2-2. Il visualizzatore della storia gitk.
+Figura 2-2. Il grafico della cronologia con gitk.
 
-Puoi vedere la storia dei commit nella metà alta della finestra con un grafico genealogico. La finestra di diff nella metà inferiore mostra i cambiamenti introdotti ad ogni commit che selezioni.
+Puoi vedere la storia delle commit, nella metà superiore, della finestra come un albero genealogico carino. La finestra delle differenza, nella metà inferiore, mostra le modifiche introdotte con ciascuna commit che selezioni.
 
 ## Annullare le Cose ##
 

From d0b33ff9d26de444b80de3b62e28ed8901131582 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Tue, 15 Apr 2014 22:43:32 +0200
Subject: [PATCH 303/690] [it] chapter6

Translated "Issues with Submodules"
---
 it/06-git-tools/01-chapter6.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/it/06-git-tools/01-chapter6.markdown b/it/06-git-tools/01-chapter6.markdown
index 3f4d67c19..8abcd39af 100644
--- a/it/06-git-tools/01-chapter6.markdown
+++ b/it/06-git-tools/01-chapter6.markdown
@@ -435,7 +435,7 @@ A volte gli sviluppatori vogliono scaricare una combinazione di subdirectory di
 
 Un buon modo per farlo in Git è quello di rendere ciascuna sottodirectory un repository Git separato e creare quindi un repository Git con il super-progetto che contenga più moduli. Un vantaggio di questo approccio è che puoi definire meglio i rapporti tra i progetti con tag e branch nei super-progetti.
 
-### Issues with Submodules ###
+### Problemi con i sottomoduli ###
 
 Usare i moduli può comunque presentare qualche intoppo. Prima di tutto devi fare molta attenzione quando lavori nella directory del modulo. Quando esegui `git submodule update`, viene fatto il checkout della versione specifica del progetto, ma non del branch. Questo viene detto “avere l’HEAD separato: significa che il file HEAD punta direttamente alla commit, e non un riferimento simbolico. Il problema è che generalmente non vuoi lavorare in un ambiente separato perché è facile perdere commit, e non un riferimento simbolico. Il problema è che generalmente non vuoi lavorare in un ambiente separato perché è facile perdere le tue modifiche. Se inizi col comando `submodule update` e poi fai una commit nella directory del modulo senza aver creato prima un branch per lavorarci e quindi esegui una `git submodule update` dal super-progetto senz’aver committato nel frattempo, Git sovrascriverà le tue modifiche senza dirti nulla.  Tecnicamente non hai perso il tuo lavoro, ma non avendo nessun branch che vi punti sarà difficile da recuperare.
 

From aec9e6b9e3cc93c6caf3e3ba6b5bb06a8edd3960 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Tue, 15 Apr 2014 22:50:32 +0200
Subject: [PATCH 304/690] [it] chapter6

Cosmetic review
---
 it/06-git-tools/01-chapter6.markdown | 30 ++++++++++------------------
 1 file changed, 10 insertions(+), 20 deletions(-)

diff --git a/it/06-git-tools/01-chapter6.markdown b/it/06-git-tools/01-chapter6.markdown
index 8abcd39af..c00633753 100644
--- a/it/06-git-tools/01-chapter6.markdown
+++ b/it/06-git-tools/01-chapter6.markdown
@@ -51,23 +51,19 @@ Git riesce a capire un valore SHA-1 intero da uno corto, abbreviato. Se usi l’
 	085bb3b removed unnecessary test code
 	a11bef0 first commit
 
-Da otto a dieci caratteri sono, generalmente, più che sufficienti per essere
-univoci all'interno di un progetto. Uno dei progetti Git più grandi, il kernel di Linux, inizia a necessitare 12 caratteri, dei 40 possibili, per essere univoco.
+Da otto a dieci caratteri sono, generalmente, più che sufficienti per essere univoci all'interno di un progetto. Uno dei progetti Git più grandi, il kernel di Linux, inizia a necessitare 12 caratteri, dei 40 possibili, per essere univoco.
 
 ### Una breve nota su SHA-1 ###
 
 Arriva un momento in cui molte persone si preoccupano che possano avere, per puro caso, due oggetti nel proprio *repository* che abbiano lo stesso hash SHA-1. E allora?
 
-Se capita di fare la *commit* di un oggetto a che abbia lo stesso SHA-1 di un oggetto
-già presente nel tuo *repository*, Git vedrà l’oggetto precedente già nel database di Git e lo riterrà già scritto. Se successivamente proverai a fare il checkout di quest’ultimo oggetto, otterrai sempre i dati del primo oggetto.
+Se capita di fare la *commit* di un oggetto a che abbia lo stesso SHA-1 di un oggetto già presente nel tuo *repository*, Git vedrà l’oggetto precedente già nel database di Git e lo riterrà già scritto. Se successivamente proverai a fare il checkout di quest’ultimo oggetto, otterrai sempre i dati del primo oggetto.
 
-Ad ogni modo, è necessario essere consapevoli di quanto sia ridicolmente improbabile
-questo scenario. Il codice SHA-1 è di 20 bytes o 160 bits. Il numero di oggetti casuali necessari perché ci sia la probabilità del 50% di una singola collisione è di circa 2^80 (la formula per determinare la probabilità di collisione è `p = (n(n-1)/2) * (1/2^160)`). 2^80 è 1.2 x 10^24 ovvero un milione di miliardi di miliardi. È 1.200 volte il numero di granelli di sabbia sulla terra.
+Ad ogni modo, è necessario essere consapevoli di quanto sia ridicolmente improbabile questo scenario. Il codice SHA-1 è di 20 bytes o 160 bits. Il numero di oggetti casuali necessari perché ci sia la probabilità del 50% di una singola collisione è di circa 2^80 (la formula per determinare la probabilità di collisione è `p = (n(n-1)/2) * (1/2^160)`). 2^80 è 1.2 x 10^24 ovvero un milione di miliardi di miliardi. È 1.200 volte il numero di granelli di sabbia sulla terra.
 
-Ecco un esempio per dare un'idea di cosa ci vorrebbe per ottenere una collisione
-SHA-1. Se tutti i 6.5 miliardi di esseri umani sulla Terra programmassero e, ogni secondo, ognuno scrivesse codice che fosse equivalente all'intera cronologia del kernel Linux (1 milione di oggetti Git) e ne facesse la push su un enorme *repository* Git, ci vorrebbero 5 anni per contenere abbastanza oggetti in quel *repository* per avere il 50% di possibilità di una singola collisione di oggetti SHA-1. Esiste una probabilità più alta che ogni membro del tuo gruppo di sviluppo, per pura coincidenza, venga attaccato e ucciso da dei lupi nella stessa notte.
+Ecco un esempio per dare un'idea di cosa ci vorrebbe per ottenere una collisione SHA-1. Se tutti i 6.5 miliardi di esseri umani sulla Terra programmassero e, ogni secondo, ognuno scrivesse codice che fosse equivalente all'intera cronologia del kernel Linux (1 milione di oggetti Git) e ne facesse la push su un enorme *repository* Git, ci vorrebbero 5 anni per contenere abbastanza oggetti in quel *repository* per avere il 50% di possibilità di una singola collisione di oggetti SHA-1. Esiste una probabilità più alta che ogni membro del tuo gruppo di sviluppo, per pura coincidenza, venga attaccato e ucciso da dei lupi nella stessa notte.
 
-### Riferimenti ai *branch* ###
+### Riferimenti alle diramazioni (*branch*) ###
 
 Il modo più diretto per specificare una *commit* è avere un *branch* che vi faccia riferimento, che ti permetterebbe di usare il nome del *branch* in qualsiasi comando Git che richieda un oggetto *commit* o un valore SHA-1. Se vuoi, per esempio, mostrare l'ultima *commit* di un *branch*, i seguenti comandi sono equivalenti, supponendo che il *branch* 'topic1' punti a 'ca82a6d':
 
@@ -79,7 +75,7 @@ Se vuoi vedere a quale SHA specifico punti un *branch*, o se vuoi vedere a quale
 	$ git rev-parse topic1
 	ca82a6dff817ec66f44342007202690a93763949
 
-### Nomi brevi di RefLog ###
+### Nomi brevi dei RefLog ###
 
 Una delle cose che Git fa dietro le quinte è aggiornare il file reflog, che memorizza silenziosamente la posizione negli ultimi mesi del tuo HEAD e dei riferimenti ai tuoi branch , ogni volta che li cambi.
 
@@ -102,12 +98,9 @@ Puoi usare usare questa sintassi anche per vedere dove era un *branch* a una cer
 
 	$ git show master@{yesterday}
 
-Questo mostra dove era il *branch* ieri. Questa tecnica funziona solo per i dati
-che sono ancora nel *reflog* e non puoi quindi usarla per vedere *commit* più
-vecchie di qualche mese.
+Questo mostra dove era il *branch* ieri. Questa tecnica funziona solo per i dati che sono ancora nel *reflog* e non puoi quindi usarla per vedere *commit* più vecchie di qualche mese.
 
-Per vedere le informazioni del *reflog* formattate come l’output di '*git log*', puoi
-eseguire il comando 'git log -g':
+Per vedere le informazioni del *reflog* formattate come l’output di '*git log*', puoi eseguire il comando 'git log -g':
 
 	$ git log -g master
 	commit 734713bc047d87bf7eac9674765ae793478c50d3
@@ -153,9 +146,7 @@ Puoi quindi vedere la *commit* precedente specificando `HEAD^`, che significa "i
 
 	    Merge commit 'phedders/rdocs'
 
-Puoi anche specificare un numero dopo `^`: per esempio `d921970^2` significa
-"il secondo genitore di d921870." Questa sintassi è utile solo per fare il *merge* di
-*commit* che hanno più di un genitore. Il primo genitore è il *branch* dove ti trovi al momento del *merge*, e il secondo è la *commit* sul *branch* da cui hai fatto il *merge*:
+Puoi anche specificare un numero dopo `^`: per esempio `d921970^2` significa "il secondo genitore di d921870." Questa sintassi è utile solo per fare il *merge* di *commit* che hanno più di un genitore. Il primo genitore è il *branch* dove ti trovi al momento del *merge*, e il secondo è la *commit* sul *branch* da cui hai fatto il *merge*:
 
 	$ git show d921970^
 	commit 1c002dd4b536e7479fe34593e72e6c6c1819e53b
@@ -171,8 +162,7 @@ Puoi anche specificare un numero dopo `^`: per esempio `d921970^2` significa
 
 	    Some rdoc changes
 
-Un altro modo riferimento ancestrale è `~`. Questo si riferisce anche al genitore, quindi `HEAD~` e `HEAD^` sono equivalenti. La differenza si nota quando specifichi un numero. `HEAD~2` significa "il genitore del genitore", o "il nonno”: attraversa i primi genitori il numero di volte che specifichi. Per esempio, nella
-cronologia precedente, `HEAD~3` sarebbe
+Un altro modo riferimento ancestrale è `~`. Questo si riferisce anche al genitore, quindi `HEAD~` e `HEAD^` sono equivalenti. La differenza si nota quando specifichi un numero. `HEAD~2` significa "il genitore del genitore", o "il nonno”: attraversa i primi genitori il numero di volte che specifichi. Per esempio, nella cronologia precedente, `HEAD~3` sarebbe
 
 	$ git show HEAD~3
 	commit 1c3618887afb5fbcbea25b7c013f4e2114448b8d

From a842962e56e3876389fb2d49a9b2992b309ddd97 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Tue, 15 Apr 2014 22:57:44 +0200
Subject: [PATCH 305/690] [it] chapter6

Added source text in english, to translate into italian
---
 it/06-git-tools/01-chapter6.markdown | 590 ++++++++++++++++++++++++++-
 1 file changed, 589 insertions(+), 1 deletion(-)

diff --git a/it/06-git-tools/01-chapter6.markdown b/it/06-git-tools/01-chapter6.markdown
index c00633753..5d950ab16 100644
--- a/it/06-git-tools/01-chapter6.markdown
+++ b/it/06-git-tools/01-chapter6.markdown
@@ -249,6 +249,594 @@ In questo è comune usare il parametro `--left-right` con il comando `log`, che
 	> C
 
 Con questi strumenti puoi dire facilmente a Git quale o quali commit vuoi ispezionare.
+<!-- da tradurre fino a riga 840 -->
+## Interactive Staging ## 
+
+Git comes with a couple of scripts that make some command-line tasks easier. Here, you’ll look at a few interactive commands that can help you easily craft your commits to include only certain combinations and parts of files. These tools are very helpful if you modify a bunch of files and then decide that you want those changes to be in several focused commits rather than one big messy commit. This way, you can make sure your commits are logically separate changesets and can be easily reviewed by the developers working with you.
+If you run `git add` with the `-i` or `--interactive` option, Git goes into an interactive shell mode, displaying something like this:
+
+	$ git add -i
+	           staged     unstaged path
+	  1:    unchanged        +0/-1 TODO
+	  2:    unchanged        +1/-1 index.html
+	  3:    unchanged        +5/-1 lib/simplegit.rb
+
+	*** Commands ***
+	  1: status     2: update      3: revert     4: add untracked
+	  5: patch      6: diff        7: quit       8: help
+	What now>
+
+You can see that this command shows you a much different view of your staging area — basically the same information you get with `git status` but a bit more succinct and informative. It lists the changes you’ve staged on the left and unstaged changes on the right.
+
+After this comes a Commands section. Here you can do a number of things, including staging files, unstaging files, staging parts of files, adding untracked files, and seeing diffs of what has been staged.
+
+### Staging and Unstaging Files ###
+
+If you type `2` or `u` at the `What now>` prompt, the script prompts you for which files you want to stage:
+
+	What now> 2
+	           staged     unstaged path
+	  1:    unchanged        +0/-1 TODO
+	  2:    unchanged        +1/-1 index.html
+	  3:    unchanged        +5/-1 lib/simplegit.rb
+	Update>>
+
+To stage the TODO and index.html files, you can type the numbers:
+
+	Update>> 1,2
+	           staged     unstaged path
+	* 1:    unchanged        +0/-1 TODO
+	* 2:    unchanged        +1/-1 index.html
+	  3:    unchanged        +5/-1 lib/simplegit.rb
+	Update>>
+
+The `*` next to each file means the file is selected to be staged. If you press Enter after typing nothing at the `Update>>` prompt, Git takes anything selected and stages it for you:
+
+	Update>>
+	updated 2 paths
+
+	*** Commands ***
+	  1: status     2: update      3: revert     4: add untracked
+	  5: patch      6: diff        7: quit       8: help
+	What now> 1
+	           staged     unstaged path
+	  1:        +0/-1      nothing TODO
+	  2:        +1/-1      nothing index.html
+	  3:    unchanged        +5/-1 lib/simplegit.rb
+
+Now you can see that the TODO and index.html files are staged and the simplegit.rb file is still unstaged. If you want to unstage the TODO file at this point, you use the `3` or `r` (for revert) option:
+
+	*** Commands ***
+	  1: status     2: update      3: revert     4: add untracked
+	  5: patch      6: diff        7: quit       8: help
+	What now> 3
+	           staged     unstaged path
+	  1:        +0/-1      nothing TODO
+	  2:        +1/-1      nothing index.html
+	  3:    unchanged        +5/-1 lib/simplegit.rb
+	Revert>> 1
+	           staged     unstaged path
+	* 1:        +0/-1      nothing TODO
+	  2:        +1/-1      nothing index.html
+	  3:    unchanged        +5/-1 lib/simplegit.rb
+	Revert>> [enter]
+	reverted one path
+
+Looking at your Git status again, you can see that you’ve unstaged the TODO file:
+
+	*** Commands ***
+	  1: status     2: update      3: revert     4: add untracked
+	  5: patch      6: diff        7: quit       8: help
+	What now> 1
+	           staged     unstaged path
+	  1:    unchanged        +0/-1 TODO
+	  2:        +1/-1      nothing index.html
+	  3:    unchanged        +5/-1 lib/simplegit.rb
+
+To see the diff of what you’ve staged, you can use the `6` or `d` (for diff) command. It shows you a list of your staged files, and you can select the ones for which you would like to see the staged diff. This is much like specifying `git diff --cached` on the command line:
+
+	*** Commands ***
+	  1: status     2: update      3: revert     4: add untracked
+	  5: patch      6: diff        7: quit       8: help
+	What now> 6
+	           staged     unstaged path
+	  1:        +1/-1      nothing index.html
+	Review diff>> 1
+	diff --git a/index.html b/index.html
+	index 4d07108..4335f49 100644
+	--- a/index.html
+	+++ b/index.html
+	@@ -16,7 +16,7 @@ Date Finder
+
+	 <p id="out">...</p>
+
+	-<div id="footer">contact : support@github.com</div>
+	+<div id="footer">contact : email.support@github.com</div>
+
+	 <script type="text/javascript">
+
+With these basic commands, you can use the interactive add mode to deal with your staging area a little more easily.
+
+### Staging Patches ###
+
+It’s also possible for Git to stage certain parts of files and not the rest. For example, if you make two changes to your simplegit.rb file and want to stage one of them and not the other, doing so is very easy in Git. From the interactive prompt, type `5` or `p` (for patch). Git will ask you which files you would like to partially stage; then, for each section of the selected files, it will display hunks of the file diff and ask if you would like to stage them, one by one:
+
+	diff --git a/lib/simplegit.rb b/lib/simplegit.rb
+	index dd5ecc4..57399e0 100644
+	--- a/lib/simplegit.rb
+	+++ b/lib/simplegit.rb
+	@@ -22,7 +22,7 @@ class SimpleGit
+	   end
+
+	   def log(treeish = 'master')
+	-    command("git log -n 25 #{treeish}")
+	+    command("git log -n 30 #{treeish}")
+	   end
+
+	   def blame(path)
+	Stage this hunk [y,n,a,d,/,j,J,g,e,?]?
+
+You have a lot of options at this point. Typing `?` shows a list of what you can do:
+
+	Stage this hunk [y,n,a,d,/,j,J,g,e,?]? ?
+	y - stage this hunk
+	n - do not stage this hunk
+	a - stage this and all the remaining hunks in the file
+	d - do not stage this hunk nor any of the remaining hunks in the file
+	g - select a hunk to go to
+	/ - search for a hunk matching the given regex
+	j - leave this hunk undecided, see next undecided hunk
+	J - leave this hunk undecided, see next hunk
+	k - leave this hunk undecided, see previous undecided hunk
+	K - leave this hunk undecided, see previous hunk
+	s - split the current hunk into smaller hunks
+	e - manually edit the current hunk
+	? - print help
+
+Generally, you’ll type `y` or `n` if you want to stage each hunk, but staging all of them in certain files or skipping a hunk decision until later can be helpful too. If you stage one part of the file and leave another part unstaged, your status output will look like this:
+
+	What now> 1
+	           staged     unstaged path
+	  1:    unchanged        +0/-1 TODO
+	  2:        +1/-1      nothing index.html
+	  3:        +1/-1        +4/-0 lib/simplegit.rb
+
+The status of the simplegit.rb file is interesting. It shows you that a couple of lines are staged and a couple are unstaged. You’ve partially staged this file. At this point, you can exit the interactive adding script and run `git commit` to commit the partially staged files.
+
+Finally, you don’t need to be in interactive add mode to do the partial-file staging — you can start the same script by using `git add -p` or `git add --patch` on the command line.
+
+## Stashing ##
+
+Often, when you’ve been working on part of your project, things are in a messy state and you want to switch branches for a bit to work on something else. The problem is, you don’t want to do a commit of half-done work just so you can get back to this point later. The answer to this issue is the `git stash` command.
+
+Stashing takes the dirty state of your working directory — that is, your modified tracked files and staged changes — and saves it on a stack of unfinished changes that you can reapply at any time.
+
+### Stashing Your Work ###
+
+To demonstrate, you’ll go into your project and start working on a couple of files and possibly stage one of the changes. If you run `git status`, you can see your dirty state:
+
+	$ git status
+	# On branch master
+	# Changes to be committed:
+	#   (use "git reset HEAD <file>..." to unstage)
+	#
+	#      modified:   index.html
+	#
+	# Changes not staged for commit:
+	#   (use "git add <file>..." to update what will be committed)
+	#
+	#      modified:   lib/simplegit.rb
+	#
+
+Now you want to switch branches, but you don’t want to commit what you’ve been working on yet; so you’ll stash the changes. To push a new stash onto your stack, run `git stash`:
+
+	$ git stash
+	Saved working directory and index state \
+	  "WIP on master: 049d078 added the index file"
+	HEAD is now at 049d078 added the index file
+	(To restore them type "git stash apply")
+
+Your working directory is clean:
+
+	$ git status
+	# On branch master
+	nothing to commit (working directory clean)
+
+At this point, you can easily switch branches and do work elsewhere; your changes are stored on your stack. To see which stashes you’ve stored, you can use `git stash list`:
+
+	$ git stash list
+	stash@{0}: WIP on master: 049d078 added the index file
+	stash@{1}: WIP on master: c264051... Revert "added file_size"
+	stash@{2}: WIP on master: 21d80a5... added number to log
+
+In this case, two stashes were done previously, so you have access to three different stashed works. You can reapply the one you just stashed by using the command shown in the help output of the original stash command: `git stash apply`. If you want to apply one of the older stashes, you can specify it by naming it, like this: `git stash apply stash@{2}`. If you don’t specify a stash, Git assumes the most recent stash and tries to apply it:
+
+	$ git stash apply
+	# On branch master
+	# Changes not staged for commit:
+	#   (use "git add <file>..." to update what will be committed)
+	#
+	#      modified:   index.html
+	#      modified:   lib/simplegit.rb
+	#
+
+You can see that Git re-modifies the files you uncommitted when you saved the stash. In this case, you had a clean working directory when you tried to apply the stash, and you tried to apply it on the same branch you saved it from; but having a clean working directory and applying it on the same branch aren’t necessary to successfully apply a stash. You can save a stash on one branch, switch to another branch later, and try to reapply the changes. You can also have modified and uncommitted files in your working directory when you apply a stash — Git gives you merge conflicts if anything no longer applies cleanly.
+
+The changes to your files were reapplied, but the file you staged before wasn’t restaged. To do that, you must run the `git stash apply` command with a `--index` option to tell the command to try to reapply the staged changes. If you had run that instead, you’d have gotten back to your original position:
+
+	$ git stash apply --index
+	# On branch master
+	# Changes to be committed:
+	#   (use "git reset HEAD <file>..." to unstage)
+	#
+	#      modified:   index.html
+	#
+	# Changes not staged for commit:
+	#   (use "git add <file>..." to update what will be committed)
+	#
+	#      modified:   lib/simplegit.rb
+	#
+
+The apply option only tries to apply the stashed work — you continue to have it on your stack. To remove it, you can run `git stash drop` with the name of the stash to remove:
+
+	$ git stash list
+	stash@{0}: WIP on master: 049d078 added the index file
+	stash@{1}: WIP on master: c264051... Revert "added file_size"
+	stash@{2}: WIP on master: 21d80a5... added number to log
+	$ git stash drop stash@{0}
+	Dropped stash@{0} (364e91f3f268f0900bc3ee613f9f733e82aaed43)
+
+You can also run `git stash pop` to apply the stash and then immediately drop it from your stack.
+
+### Un-applying a Stash ###
+
+In some use case scenarios you might want to apply stashed changes, do some work, but then un-apply those changes that originally came from the stash. Git does not provide such a `stash unapply` command, but it is possible to achieve the effect by simply retrieving the patch associated with a stash and applying it in reverse:
+
+    $ git stash show -p stash@{0} | git apply -R
+
+Again, if you don’t specify a stash, Git assumes the most recent stash:
+
+    $ git stash show -p | git apply -R
+
+You may want to create an alias and effectively add a `stash-unapply` command to your Git. For example:
+
+    $ git config --global alias.stash-unapply '!git stash show -p | git apply -R'
+    $ git stash
+    $ #... work work work
+    $ git stash-unapply
+
+### Creating a Branch from a Stash ###
+
+If you stash some work, leave it there for a while, and continue on the branch from which you stashed the work, you may have a problem reapplying the work. If the apply tries to modify a file that you’ve since modified, you’ll get a merge conflict and will have to try to resolve it. If you want an easier way to test the stashed changes again, you can run `git stash branch`, which creates a new branch for you, checks out the commit you were on when you stashed your work, reapplies your work there, and then drops the stash if it applies successfully:
+
+	$ git stash branch testchanges
+	Switched to a new branch "testchanges"
+	# On branch testchanges
+	# Changes to be committed:
+	#   (use "git reset HEAD <file>..." to unstage)
+	#
+	#      modified:   index.html
+	#
+	# Changes not staged for commit:
+	#   (use "git add <file>..." to update what will be committed)
+	#
+	#      modified:   lib/simplegit.rb
+	#
+	Dropped refs/stash@{0} (f0dfc4d5dc332d1cee34a634182e168c4efc3359)
+
+This is a nice shortcut to recover stashed work easily and work on it in a new branch.
+
+## Rewriting History ##
+
+Many times, when working with Git, you may want to revise your commit history for some reason. One of the great things about Git is that it allows you to make decisions at the last possible moment. You can decide what files go into which commits right before you commit with the staging area, you can decide that you didn’t mean to be working on something yet with the stash command, and you can rewrite commits that already happened so they look like they happened in a different way. This can involve changing the order of the commits, changing messages or modifying files in a commit, squashing together or splitting apart commits, or removing commits entirely — all before you share your work with others.
+
+In this section, you’ll cover how to accomplish these very useful tasks so that you can make your commit history look the way you want before you share it with others.
+
+### Changing the Last Commit ###
+
+Changing your last commit is probably the most common rewriting of history that you’ll do. You’ll often want to do two basic things to your last commit: change the commit message, or change the snapshot you just recorded by adding, changing and removing files.
+
+If you only want to modify your last commit message, it’s very simple:
+
+	$ git commit --amend
+
+That drops you into your text editor, which has your last commit message in it, ready for you to modify the message. When you save and close the editor, the editor writes a new commit containing that message and makes it your new last commit.
+
+If you’ve committed and then you want to change the snapshot you committed by adding or changing files, possibly because you forgot to add a newly created file when you originally committed, the process works basically the same way. You stage the changes you want by editing a file and running `git add` on it or `git rm` to a tracked file, and the subsequent `git commit --amend` takes your current staging area and makes it the snapshot for the new commit.
+
+You need to be careful with this technique because amending changes the SHA-1 of the commit. It’s like a very small rebase — don’t amend your last commit if you’ve already pushed it.
+
+### Changing Multiple Commit Messages ###
+
+To modify a commit that is farther back in your history, you must move to more complex tools. Git doesn’t have a modify-history tool, but you can use the rebase tool to rebase a series of commits onto the HEAD they were originally based on instead of moving them to another one. With the interactive rebase tool, you can then stop after each commit you want to modify and change the message, add files, or do whatever you wish. You can run rebase interactively by adding the `-i` option to `git rebase`. You must indicate how far back you want to rewrite commits by telling the command which commit to rebase onto.
+
+For example, if you want to change the last three commit messages, or any of the commit messages in that group, you supply as an argument to `git rebase -i` the parent of the last commit you want to edit, which is `HEAD~2^` or `HEAD~3`. It may be easier to remember the `~3` because you’re trying to edit the last three commits; but keep in mind that you’re actually designating four commits ago, the parent of the last commit you want to edit:
+
+	$ git rebase -i HEAD~3
+
+Remember again that this is a rebasing command — every commit included in the range `HEAD~3..HEAD` will be rewritten, whether you change the message or not. Don’t include any commit you’ve already pushed to a central server — doing so will confuse other developers by providing an alternate version of the same change.
+
+Running this command gives you a list of commits in your text editor that looks something like this:
+
+	pick f7f3f6d changed my name a bit
+	pick 310154e updated README formatting and added blame
+	pick a5f4a0d added cat-file
+
+	# Rebase 710f0f8..a5f4a0d onto 710f0f8
+	#
+	# Commands:
+	#  p, pick = use commit
+	#  r, reword = use commit, but edit the commit message
+	#  e, edit = use commit, but stop for amending
+	#  s, squash = use commit, but meld into previous commit
+	#  f, fixup = like "squash", but discard this commit's log message
+	#  x, exec = run command (the rest of the line) using shell
+	#
+	# These lines can be re-ordered; they are executed from top to bottom.
+	#
+	# If you remove a line here THAT COMMIT WILL BE LOST.
+	#
+	# However, if you remove everything, the rebase will be aborted.
+	#
+	# Note that empty commits are commented out
+
+It’s important to note that these commits are listed in the opposite order than you normally see them using the `log` command. If you run a `log`, you see something like this:
+
+	$ git log --pretty=format:"%h %s" HEAD~3..HEAD
+	a5f4a0d added cat-file
+	310154e updated README formatting and added blame
+	f7f3f6d changed my name a bit
+
+Notice the reverse order. The interactive rebase gives you a script that it’s going to run. It will start at the commit you specify on the command line (`HEAD~3`) and replay the changes introduced in each of these commits from top to bottom. It lists the oldest at the top, rather than the newest, because that’s the first one it will replay.
+
+You need to edit the script so that it stops at the commit you want to edit. To do so, change the word pick to the word edit for each of the commits you want the script to stop after. For example, to modify only the third commit message, you change the file to look like this:
+
+	edit f7f3f6d changed my name a bit
+	pick 310154e updated README formatting and added blame
+	pick a5f4a0d added cat-file
+
+When you save and exit the editor, Git rewinds you back to the last commit in that list and drops you on the command line with the following message:
+
+<!-- This is actually weird, as the SHA-1 of 7482e0d is not present in the list, 
+nor is the commit message. Please review 
+-->
+
+	$ git rebase -i HEAD~3
+	Stopped at 7482e0d... updated the gemspec to hopefully work better
+	You can amend the commit now, with
+
+	       git commit --amend
+
+	Once you’re satisfied with your changes, run
+
+	       git rebase --continue
+
+These instructions tell you exactly what to do. Type
+
+	$ git commit --amend
+
+Change the commit message, and exit the editor. Then, run
+
+	$ git rebase --continue
+
+This command will apply the other two commits automatically, and then you’re done. If you change pick to edit on more lines, you can repeat these steps for each commit you change to edit. Each time, Git will stop, let you amend the commit, and continue when you’re finished.
+
+### Reordering Commits ###
+
+You can also use interactive rebases to reorder or remove commits entirely. If you want to remove the "added cat-file" commit and change the order in which the other two commits are introduced, you can change the rebase script from this
+
+	pick f7f3f6d changed my name a bit
+	pick 310154e updated README formatting and added blame
+	pick a5f4a0d added cat-file
+
+to this:
+
+	pick 310154e updated README formatting and added blame
+	pick f7f3f6d changed my name a bit
+
+When you save and exit the editor, Git rewinds your branch to the parent of these commits, applies `310154e` and then `f7f3f6d`, and then stops. You effectively change the order of those commits and remove the "added cat-file" commit completely.
+
+### Squashing Commits ###
+
+It’s also possible to take a series of commits and squash them down into a single commit with the interactive rebasing tool. The script puts helpful instructions in the rebase message:
+
+	#
+	# Commands:
+	#  p, pick = use commit
+	#  r, reword = use commit, but edit the commit message
+	#  e, edit = use commit, but stop for amending
+	#  s, squash = use commit, but meld into previous commit
+	#  f, fixup = like "squash", but discard this commit's log message
+	#  x, exec = run command (the rest of the line) using shell
+	#
+	# These lines can be re-ordered; they are executed from top to bottom.
+	#
+	# If you remove a line here THAT COMMIT WILL BE LOST.
+	#
+	# However, if you remove everything, the rebase will be aborted.
+	#
+	# Note that empty commits are commented out
+
+If, instead of "pick" or "edit", you specify "squash", Git applies both that change and the change directly before it and makes you merge the commit messages together. So, if you want to make a single commit from these three commits, you make the script look like this:
+
+	pick f7f3f6d changed my name a bit
+	squash 310154e updated README formatting and added blame
+	squash a5f4a0d added cat-file
+
+When you save and exit the editor, Git applies all three changes and then puts you back into the editor to merge the three commit messages:
+
+	# This is a combination of 3 commits.
+	# The first commit's message is:
+	changed my name a bit
+
+	# This is the 2nd commit message:
+
+	updated README formatting and added blame
+
+	# This is the 3rd commit message:
+
+	added cat-file
+
+When you save that, you have a single commit that introduces the changes of all three previous commits.
+
+### Splitting a Commit ###
+
+Splitting a commit undoes a commit and then partially stages and commits as many times as commits you want to end up with. For example, suppose you want to split the middle commit of your three commits. Instead of "updated README formatting and added blame", you want to split it into two commits: "updated README formatting" for the first, and "added blame" for the second. You can do that in the `rebase -i` script by changing the instruction on the commit you want to split to "edit":
+
+	pick f7f3f6d changed my name a bit
+	edit 310154e updated README formatting and added blame
+	pick a5f4a0d added cat-file
+
+When you save and exit the editor, Git rewinds to the parent of the first commit in your list, applies the first commit (`f7f3f6d`), applies the second (`310154e`), and drops you to the console. There, you can do a mixed reset of that commit with `git reset HEAD^`, which effectively undoes that commit and leaves the modified files unstaged. Now you can take the changes that have been reset, and create multiple commits out of them. Simply stage and commit files until you have several commits, and run `git rebase --continue` when you’re done:
+
+	$ git reset HEAD^
+	$ git add README
+	$ git commit -m 'updated README formatting'
+	$ git add lib/simplegit.rb
+	$ git commit -m 'added blame'
+	$ git rebase --continue
+
+Git applies the last commit (`a5f4a0d`) in the script, and your history looks like this:
+
+	$ git log -4 --pretty=format:"%h %s"
+	1c002dd added cat-file
+	9b29157 added blame
+	35cfb2b updated README formatting
+	f3cc40e changed my name a bit
+
+Once again, this changes the SHAs of all the commits in your list, so make sure no commit shows up in that list that you’ve already pushed to a shared repository.
+
+### The Nuclear Option: filter-branch ###
+
+There is another history-rewriting option that you can use if you need to rewrite a larger number of commits in some scriptable way — for instance, changing your e-mail address globally or removing a file from every commit. The command is `filter-branch`, and it can rewrite huge swaths of your history, so you probably shouldn’t use it unless your project isn’t yet public and other people haven’t based work off the commits you’re about to rewrite. However, it can be very useful. You’ll learn a few of the common uses so you can get an idea of some of the things it’s capable of.
+
+#### Removing a File from Every Commit ####
+
+This occurs fairly commonly. Someone accidentally commits a huge binary file with a thoughtless `git add .`, and you want to remove it everywhere. Perhaps you accidentally committed a file that contained a password, and you want to make your project open source. `filter-branch` is the tool you probably want to use to scrub your entire history. To remove a file named passwords.txt from your entire history, you can use the `--tree-filter` option to `filter-branch`:
+
+	$ git filter-branch --tree-filter 'rm -f passwords.txt' HEAD
+	Rewrite 6b9b3cf04e7c5686a9cb838c3f36a8cb6a0fc2bd (21/21)
+	Ref 'refs/heads/master' was rewritten
+
+The `--tree-filter` option runs the specified command after each checkout of the project and then recommits the results. In this case, you remove a file called passwords.txt from every snapshot, whether it exists or not. If you want to remove all accidentally committed editor backup files, you can run something like `git filter-branch --tree-filter "rm -f *~" HEAD`.
+
+You’ll be able to watch Git rewriting trees and commits and then move the branch pointer at the end. It’s generally a good idea to do this in a testing branch and then hard-reset your master branch after you’ve determined the outcome is what you really want. To run `filter-branch` on all your branches, you can pass `--all` to the command.
+
+#### Making a Subdirectory the New Root ####
+
+Suppose you’ve done an import from another source control system and have subdirectories that make no sense (trunk, tags, and so on). If you want to make the `trunk` subdirectory be the new project root for every commit, `filter-branch` can help you do that, too:
+
+	$ git filter-branch --subdirectory-filter trunk HEAD
+	Rewrite 856f0bf61e41a27326cdae8f09fe708d679f596f (12/12)
+	Ref 'refs/heads/master' was rewritten
+
+Now your new project root is what was in the `trunk` subdirectory each time. Git will also automatically remove commits that did not affect the subdirectory.
+
+#### Changing E-Mail Addresses Globally ####
+
+Another common case is that you forgot to run `git config` to set your name and e-mail address before you started working, or perhaps you want to open-source a project at work and change all your work e-mail addresses to your personal address. In any case, you can change e-mail addresses in multiple commits in a batch with `filter-branch` as well. You need to be careful to change only the e-mail addresses that are yours, so you use `--commit-filter`:
+
+	$ git filter-branch --commit-filter '
+	        if [ "$GIT_AUTHOR_EMAIL" = "schacon@localhost" ];
+	        then
+	                GIT_AUTHOR_NAME="Scott Chacon";
+	                GIT_AUTHOR_EMAIL="schacon@example.com";
+	                git commit-tree "$@";
+	        else
+	                git commit-tree "$@";
+	        fi' HEAD
+
+This goes through and rewrites every commit to have your new address. Because commits contain the SHA-1 values of their parents, this command changes every commit SHA in your history, not just those that have the matching e-mail address.
+
+## Debugging with Git ##
+
+Git also provides a couple of tools to help you debug issues in your projects. Because Git is designed to work with nearly any type of project, these tools are pretty generic, but they can often help you hunt for a bug or culprit when things go wrong.
+
+### File Annotation ###
+
+If you track down a bug in your code and want to know when it was introduced and why, file annotation is often your best tool. It shows you what commit was the last to modify each line of any file. So, if you see that a method in your code is buggy, you can annotate the file with `git blame` to see when each line of the method was last edited and by whom. This example uses the `-L` option to limit the output to lines 12 through 22:
+
+	$ git blame -L 12,22 simplegit.rb
+	^4832fe2 (Scott Chacon  2008-03-15 10:31:28 -0700 12)  def show(tree = 'master')
+	^4832fe2 (Scott Chacon  2008-03-15 10:31:28 -0700 13)   command("git show #{tree}")
+	^4832fe2 (Scott Chacon  2008-03-15 10:31:28 -0700 14)  end
+	^4832fe2 (Scott Chacon  2008-03-15 10:31:28 -0700 15)
+	9f6560e4 (Scott Chacon  2008-03-17 21:52:20 -0700 16)  def log(tree = 'master')
+	79eaf55d (Scott Chacon  2008-04-06 10:15:08 -0700 17)   command("git log #{tree}")
+	9f6560e4 (Scott Chacon  2008-03-17 21:52:20 -0700 18)  end
+	9f6560e4 (Scott Chacon  2008-03-17 21:52:20 -0700 19)
+	42cf2861 (Magnus Chacon 2008-04-13 10:45:01 -0700 20)  def blame(path)
+	42cf2861 (Magnus Chacon 2008-04-13 10:45:01 -0700 21)   command("git blame #{path}")
+	42cf2861 (Magnus Chacon 2008-04-13 10:45:01 -0700 22)  end
+
+Notice that the first field is the partial SHA-1 of the commit that last modified that line. The next two fields are values extracted from that commit—the author name and the authored date of that commit — so you can easily see who modified that line and when. After that come the line number and the content of the file. Also note the `^4832fe2` commit lines, which designate that those lines were in this file’s original commit. That commit is when this file was first added to this project, and those lines have been unchanged since. This is a tad confusing, because now you’ve seen at least three different ways that Git uses the `^` to modify a commit SHA, but that is what it means here.
+
+Another cool thing about Git is that it doesn’t track file renames explicitly. It records the snapshots and then tries to figure out what was renamed implicitly, after the fact. One of the interesting features of this is that you can ask it to figure out all sorts of code movement as well. If you pass `-C` to `git blame`, Git analyzes the file you’re annotating and tries to figure out where snippets of code within it originally came from if they were copied from elsewhere. Recently, I was refactoring a file named `GITServerHandler.m` into multiple files, one of which was `GITPackUpload.m`. By blaming `GITPackUpload.m` with the `-C` option, I could see where sections of the code originally came from:
+
+	$ git blame -C -L 141,153 GITPackUpload.m
+	f344f58d GITServerHandler.m (Scott 2009-01-04 141)
+	f344f58d GITServerHandler.m (Scott 2009-01-04 142) - (void) gatherObjectShasFromC
+	f344f58d GITServerHandler.m (Scott 2009-01-04 143) {
+	70befddd GITServerHandler.m (Scott 2009-03-22 144)         //NSLog(@"GATHER COMMI
+	ad11ac80 GITPackUpload.m    (Scott 2009-03-24 145)
+	ad11ac80 GITPackUpload.m    (Scott 2009-03-24 146)         NSString *parentSha;
+	ad11ac80 GITPackUpload.m    (Scott 2009-03-24 147)         GITCommit *commit = [g
+	ad11ac80 GITPackUpload.m    (Scott 2009-03-24 148)
+	ad11ac80 GITPackUpload.m    (Scott 2009-03-24 149)         //NSLog(@"GATHER COMMI
+	ad11ac80 GITPackUpload.m    (Scott 2009-03-24 150)
+	56ef2caf GITServerHandler.m (Scott 2009-01-05 151)         if(commit) {
+	56ef2caf GITServerHandler.m (Scott 2009-01-05 152)                 [refDict setOb
+	56ef2caf GITServerHandler.m (Scott 2009-01-05 153)
+
+This is really useful. Normally, you get as the original commit the commit where you copied the code over, because that is the first time you touched those lines in this file. Git tells you the original commit where you wrote those lines, even if it was in another file.
+
+### Binary Search ###
+
+Annotating a file helps if you know where the issue is to begin with. If you don’t know what is breaking, and there have been dozens or hundreds of commits since the last state where you know the code worked, you’ll likely turn to `git bisect` for help. The `bisect` command does a binary search through your commit history to help you identify as quickly as possible which commit introduced an issue.
+
+Let’s say you just pushed out a release of your code to a production environment, you’re getting bug reports about something that wasn’t happening in your development environment, and you can’t imagine why the code is doing that. You go back to your code, and it turns out you can reproduce the issue, but you can’t figure out what is going wrong. You can bisect the code to find out. First you run `git bisect start` to get things going, and then you use `git bisect bad` to tell the system that the current commit you’re on is broken. Then, you must tell bisect when the last known good state was, using `git bisect good [good_commit]`:
+
+	$ git bisect start
+	$ git bisect bad
+	$ git bisect good v1.0
+	Bisecting: 6 revisions left to test after this
+	[ecb6e1bc347ccecc5f9350d878ce677feb13d3b2] error handling on repo
+
+Git figured out that about 12 commits came between the commit you marked as the last good commit (v1.0) and the current bad version, and it checked out the middle one for you. At this point, you can run your test to see if the issue exists as of this commit. If it does, then it was introduced sometime before this middle commit; if it doesn’t, then the problem was introduced sometime after the middle commit. It turns out there is no issue here, and you tell Git that by typing `git bisect good` and continue your journey:
+
+	$ git bisect good
+	Bisecting: 3 revisions left to test after this
+	[b047b02ea83310a70fd603dc8cd7a6cd13d15c04] secure this thing
+
+Now you’re on another commit, halfway between the one you just tested and your bad commit. You run your test again and find that this commit is broken, so you tell Git that with `git bisect bad`:
+
+	$ git bisect bad
+	Bisecting: 1 revisions left to test after this
+	[f71ce38690acf49c1f3c9bea38e09d82a5ce6014] drop exceptions table
+
+This commit is fine, and now Git has all the information it needs to determine where the issue was introduced. It tells you the SHA-1 of the first bad commit and show some of the commit information and which files were modified in that commit so you can figure out what happened that may have introduced this bug:
+
+	$ git bisect good
+	b047b02ea83310a70fd603dc8cd7a6cd13d15c04 is first bad commit
+	commit b047b02ea83310a70fd603dc8cd7a6cd13d15c04
+	Author: PJ Hyett <pjhyett@example.com>
+	Date:   Tue Jan 27 14:48:32 2009 -0800
+
+	    secure this thing
+
+	:040000 040000 40ee3e7821b895e52c1695092db9bdc4c61d1730
+	f24d3c6ebcfc639b1a3814550e62d60b8e68a8e4 M  config
+
+When you’re finished, you should run `git bisect reset` to reset your HEAD to where you were before you started, or you’ll end up in a weird state:
+
+	$ git bisect reset
+
+This is a powerful tool that can help you check hundreds of commits for an introduced bug in minutes. In fact, if you have a script that will exit 0 if the project is good or non-0 if the project is bad, you can fully automate `git bisect`. First, you again tell it the scope of the bisect by providing the known bad and good commits. You can do this by listing them with the `bisect start` command if you want, listing the known bad commit first and the known good commit second:
+
+	$ git bisect start HEAD v1.0
+	$ git bisect run test-error.sh
+
+Doing so automatically runs `test-error.sh` on each checked-out commit until Git finds the first broken commit. You can also run something like `make` or `make tests` or whatever you have that runs automated tests for you.
 
 ## Moduli ##
 
@@ -425,7 +1013,7 @@ A volte gli sviluppatori vogliono scaricare una combinazione di subdirectory di
 
 Un buon modo per farlo in Git è quello di rendere ciascuna sottodirectory un repository Git separato e creare quindi un repository Git con il super-progetto che contenga più moduli. Un vantaggio di questo approccio è che puoi definire meglio i rapporti tra i progetti con tag e branch nei super-progetti.
 
-### Problemi con i sottomoduli ###
+### Problemi con i moduli ###
 
 Usare i moduli può comunque presentare qualche intoppo. Prima di tutto devi fare molta attenzione quando lavori nella directory del modulo. Quando esegui `git submodule update`, viene fatto il checkout della versione specifica del progetto, ma non del branch. Questo viene detto “avere l’HEAD separato: significa che il file HEAD punta direttamente alla commit, e non un riferimento simbolico. Il problema è che generalmente non vuoi lavorare in un ambiente separato perché è facile perdere commit, e non un riferimento simbolico. Il problema è che generalmente non vuoi lavorare in un ambiente separato perché è facile perdere le tue modifiche. Se inizi col comando `submodule update` e poi fai una commit nella directory del modulo senza aver creato prima un branch per lavorarci e quindi esegui una `git submodule update` dal super-progetto senz’aver committato nel frattempo, Git sovrascriverà le tue modifiche senza dirti nulla.  Tecnicamente non hai perso il tuo lavoro, ma non avendo nessun branch che vi punti sarà difficile da recuperare.
 

From 1bb1d88012b780f8d368976e54ac7ab54b719051 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Tue, 15 Apr 2014 23:36:40 +0200
Subject: [PATCH 306/690] [it] Edited chapter2

Cambiato storia in cronologia per essere consistente con il resto del libro
---
 it/02-git-basics/01-chapter2.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/it/02-git-basics/01-chapter2.markdown b/it/02-git-basics/01-chapter2.markdown
index 2851d883b..a5619cfdd 100644
--- a/it/02-git-basics/01-chapter2.markdown
+++ b/it/02-git-basics/01-chapter2.markdown
@@ -675,7 +675,7 @@ Se vuoi usare uno strumento più grafico per visualizzare la cronologia delle tu
 Insert 18333fig0202.png
 Figura 2-2. Il grafico della cronologia con gitk.
 
-Puoi vedere la storia delle commit, nella metà superiore, della finestra come un albero genealogico carino. La finestra delle differenza, nella metà inferiore, mostra le modifiche introdotte con ciascuna commit che selezioni.
+Puoi vedere la cronologia delle commit, nella metà superiore, della finestra come un albero genealogico carino. La finestra delle differenza, nella metà inferiore, mostra le modifiche introdotte con ciascuna commit che selezioni.
 
 ## Annullare le Cose ##
 

From 9d3721383cc5f26c255ea6ae92f8d1baebdbc990 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Tue, 15 Apr 2014 23:39:16 +0200
Subject: [PATCH 307/690] [it] Reviewing chapter2

Reviewed "Undoing Things"
---
 it/02-git-basics/01-chapter2.markdown | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/it/02-git-basics/01-chapter2.markdown b/it/02-git-basics/01-chapter2.markdown
index a5619cfdd..433fd7e53 100644
--- a/it/02-git-basics/01-chapter2.markdown
+++ b/it/02-git-basics/01-chapter2.markdown
@@ -677,9 +677,9 @@ Figura 2-2. Il grafico della cronologia con gitk.
 
 Puoi vedere la cronologia delle commit, nella metà superiore, della finestra come un albero genealogico carino. La finestra delle differenza, nella metà inferiore, mostra le modifiche introdotte con ciascuna commit che selezioni.
 
-## Annullare le Cose ##
+## Annullare qualcosa ##
 
-Ad ogni stadio potresti voler annullare qualcosa. Qui, vedremo alcuni strumenti fondamentali per annullare i cambiamenti che hai fatto. Attenzione, perché non sempre puoi invertire alcuni annullamenti. Questa è una delle aree in Git dove puoi perdere qualche lavoro se sbagli.
+In qualsiasi momento puoi voler annullare qualcosa. Rivedremo alcuni strumenti basilari per annullare le modifiche fatte. Attenzione però, perché non sempre puoi ripristinare ciò che annulli. Questa è una delle aree di Git dove puoi perdere del lavoro svolto se commetti un errore.
 
 ### Modificare il Tuo Ultimo Commit ###
 

From 1415a97f19da34aba0540ccf4fcb0749afeaa5af Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Tue, 15 Apr 2014 23:47:21 +0200
Subject: [PATCH 308/690] [it] Reviewing chapter2

Reviewed "Changing Your Last Commit"
---
 it/02-git-basics/01-chapter2.markdown | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/it/02-git-basics/01-chapter2.markdown b/it/02-git-basics/01-chapter2.markdown
index 433fd7e53..a121c10e0 100644
--- a/it/02-git-basics/01-chapter2.markdown
+++ b/it/02-git-basics/01-chapter2.markdown
@@ -681,23 +681,23 @@ Puoi vedere la cronologia delle commit, nella metà superiore, della finestra co
 
 In qualsiasi momento puoi voler annullare qualcosa. Rivedremo alcuni strumenti basilari per annullare le modifiche fatte. Attenzione però, perché non sempre puoi ripristinare ciò che annulli. Questa è una delle aree di Git dove puoi perdere del lavoro svolto se commetti un errore.
 
-### Modificare il Tuo Ultimo Commit ###
+### Modifica la tua ultima commit ###
 
-Uno degli annullamenti comuni avviene quando invii troppo presto un commit e magari dimentichi di aggiungere alcuni file, o sbagli il messaggio di commit. Se vuoi provare nuovamente questo commit, puoi lanciare commit con l'opzione `--amend`:
+Uno degli annullamenti più comuni si verifica quando committi qualcosa troppo presto e magari dimentichi di aggiungere qualche file, o sbagli qualcosa nel messaggio di commit. Se vuoi modificare questa commit puoi eseguire il comando commit con l'opzione `--amend`:
 
 	$ git commit --amend
 
-Questo comando prende la tua area di stage e la usa per il commit. Se non hai fatto cambiamenti dal tuo ultimo commit (per esempio, lanci questo comando subito dopo il tuo commit precedente), allora il tuo snapshot sarà esattamente uguale e potrai cambiare il tuo messaggio di commit.
+Questo comando usa la tua area di `stage` per la commit. Se non hai fatto modifiche dalla tua ultima commit (per esempio, esegui questo comando subito dopo la tua commit precedente), allora il tuo snapshot sarà identico e potrai cambiare il tuo messaggio di commit.
 
-L'editor per il messaggio del commit apparirà, ma già contiene il messaggio del commit precedente. Puoi modificare il messaggio come sempre, ma sovrascriverà il commit precedente.
+Verrà lanciata la stessa applicazione per scrivere il messaggio della commit, ma conterrà già il messaggio della commit precedente. Puoi modificare il messaggio normalmente, ma questo sovrascriverà la commit precedente.
 
-Come esempio, se fai il commit e poi realizzi di aver dimenticato un cambiamento nella tua area di stage di un file e vuoi aggiungerlo a questo commit, puoi farlo così:
+Per esempio, se fai una commit e realizzi di non aver messo nello `stage` le modifiche a un file e vuoi aggiungerlo a questa commit, puoi fare così:
 
 	$ git commit -m 'initial commit'
 	$ git add forgotten_file
 	$ git commit --amend
 
-Tutti e tre i comandi finisco in un singolo commit —  il secondo commit riscrive il risultato del primo.
+Dopo questi tre comandi ti ritroverai con una sola commit: la seconda sovrascrive la prima.
 
 ### Disimpegnare un File Staged ###
 

From 822784aea9cb31322cb9a620a940138004b8ed27 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Tue, 15 Apr 2014 23:54:36 +0200
Subject: [PATCH 309/690] [it] Reviewing chapter2

reviewed "Unstaging a Staged File"
---
 it/02-git-basics/01-chapter2.markdown | 49 ++++++++++++++-------------
 1 file changed, 25 insertions(+), 24 deletions(-)

diff --git a/it/02-git-basics/01-chapter2.markdown b/it/02-git-basics/01-chapter2.markdown
index a121c10e0..da31bced4 100644
--- a/it/02-git-basics/01-chapter2.markdown
+++ b/it/02-git-basics/01-chapter2.markdown
@@ -699,39 +699,40 @@ Per esempio, se fai una commit e realizzi di non aver messo nello `stage` le mod
 
 Dopo questi tre comandi ti ritroverai con una sola commit: la seconda sovrascrive la prima.
 
-### Disimpegnare un File Staged ###
+### Rimuovere un file dall'area di `stage` ###
 
-Le prossime due sezioni mostrano come gestire le modifiche della tua area di stage e della directory di lavoro. La parte divertente è che il comando che usi per determinare lo stato di queste due aree ricorda come annullare i cambiamenti fatti. Per esempio, supponiamo che hai modificato due file e vuoi inviarli come modifiche separate, ma accidentalmente digiti `git add *` e li parcheggi entrambi. Come puoi disimpegnare uno dei due? Il comando `git status` ti ricorda:
+Le prossime due sezioni mostrano come gestire le modifiche della tua area di stage e della directory di lavoro. La parte divertente è che il comando che usi per determinare lo stato di queste due aree ti ricorda come annullare le modifiche alle stesse. Per esempio, supponiamo che hai modificato due file e vuoi committarli come modifiche separate, ma accidentalmente digiti `git add *` e li metti entrambi in `stage`. Come puoi rimuoverne uno? Il comando `git status` ti ricorda:
 
 	$ git add .
 	$ git status
-	# On branch master
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#       modified:   README.txt
-	#       modified:   benchmarks.rb
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        modified:   README.txt
+	        modified:   benchmarks.rb
+	
 
-Ora il testo sotto “Changes to be committed”, dice di usare `git reset HEAD <file>...` per annullare. Così, usa questo avviso per disimpegnare il file benchmarks.rb dal parcheggio:
+Il testo sotto “Changes to be committed” ti dice di usare `git reset HEAD <file>...` per rimuovere dallo `stage`. Usa quindi questo consiglio per rimuoever `benchmarks.rb`:
 
 	$ git reset HEAD benchmarks.rb
-	benchmarks.rb: locally modified
+	Unstaged changes after reset:
+	M       benchmarks.rb
 	$ git status
-	# On branch master
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#       modified:   README.txt
-	#
-	# Changes not staged for commit:
-	#   (use "git add <file>..." to update what will be committed)
-	#   (use "git checkout -- <file>..." to discard changes in working directory)
-	#
-	#       modified:   benchmarks.rb
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        modified:   README.txt
+	
+	Changes not staged for commit:
+	  (use "git add <file>..." to update what will be committed)
+	  (use "git checkout -- <file>..." to discard changes in working directory)
+	
+	        modified:   benchmarks.rb
+	
 
-Il comando è un po' strano, ma funziona. Il file benchmarks.rb è modificato ma non parcheggiato.
+Il comando è un po' strano, ma funziona. Il file `benchmarks.rb` ora è modificato ma non più nello `stage`.
 
 ### Annullare le Modifiche di un File Modificato ###
 

From 5874ce8517fb0c9bedba0344bf279b53352c5ccd Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Wed, 16 Apr 2014 00:04:41 +0200
Subject: [PATCH 310/690] [it] reviewing chapter2

reviewed "Unmodifying a Modified File"
---
 it/02-git-basics/01-chapter2.markdown | 34 +++++++++++++--------------
 1 file changed, 17 insertions(+), 17 deletions(-)

diff --git a/it/02-git-basics/01-chapter2.markdown b/it/02-git-basics/01-chapter2.markdown
index da31bced4..7cb147cba 100644
--- a/it/02-git-basics/01-chapter2.markdown
+++ b/it/02-git-basics/01-chapter2.markdown
@@ -734,31 +734,31 @@ Il testo sotto “Changes to be committed” ti dice di usare `git reset HEAD <f
 
 Il comando è un po' strano, ma funziona. Il file `benchmarks.rb` ora è modificato ma non più nello `stage`.
 
-### Annullare le Modifiche di un File Modificato ###
+### Annullare le modifiche a un file ###
 
-Come fare se hai realizzato che non vuoi più tenere le modifiche che hai fatto al file `benchmarks.rb`? Come puoi annullarle facilmente — ritornare a come era al tuo ultimo commit (o alla clonazione iniziale, o come lo avevi nella tua directory di lavoro)? Fortunatamente, `git status` ci dice come farlo. Nell'ultimo output di esempio, l'area di unstage (file non parcheggiati) assomiglia a:
+Come fare se ti rendi conto che non vuoi più mantenere le modifiche di `benchmarks.rb`? Come puoi annullarle facilmente — ritornare a come era prima dell'ultima commit (o al clone iniziale, o comunque lo avevi nella tua directory di lavoro)? Fortunatamente `git status` ti dice come farlo. Nell'ultimo output di esempio, l'area dei file modificati appare così:
 
-	# Changes not staged for commit:
-	#   (use "git add <file>..." to update what will be committed)
-	#   (use "git checkout -- <file>..." to discard changes in working directory)
-	#
-	#       modified:   benchmarks.rb
-	#
+	Changes not staged for commit:
+	  (use "git add <file>..." to update what will be committed)
+	  (use "git checkout -- <file>..." to discard changes in working directory)
+	
+	        modified:   benchmarks.rb
+	
 
-Ci dice abbastanza esplicitamente come annullare le modifiche fatte (al limite, le nuove versioni di Git, 1.6.1 e successive, lo fanno —  se hai una versione più vecchia è raccomandato aggiornarla per avere queste funzioni utili). Vediamo cosa ci dice:
+Ti dice abbastanza chiaramente come annullare le tue modifiche (almeno le nuove versioni di Git, dalla 1.6.1 in poi, lo fanno:  se hai una versione più vecchia ti raccomandiamo di aggiornarla per avere alcune di queste funzioni utili e carine). Vediamo cosa dice:
 
 	$ git checkout -- benchmarks.rb
 	$ git status
-	# On branch master
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#       modified:   README.txt
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        modified:   README.txt
+	
 
-Puoi vedere come le modifiche sono state annullate. Dovresti inoltre realizzare che è un comando pericoloso: ogni cambiamento fatto al file è sparito — semplicemente hai copiato un altro file su di esso. Non usare mai questo comando a meno che non sai assolutamente che non vuoi il file. Se hai bisogno solamente di toglierlo di torno, vedremo ripostigli e ramificazioni nei capitoli successivi ; queste sono generalmente le vie migliori da seguire.
+Puoi vedere come le modifiche siano state annullate. Dovresti capire quanto questo sia un comando pericoloso: tutte le modifiche fatte al file sono sparite: lo hai praticamente sovrascritto con un altro file. Non usare mai questo comando a meno che non sia assolutamente certo di non volere il file. Se hai solo bisogno di toglierlo di torno, vedremo i `ripostigli` (*stash*) e le diramazioni (*branch*) nei prossimi capitoli, che generalmente sono le strade migliori da seguire.
 
-Ricorda, qualsiasi cosa che è stata affidata a Git può quasi sempre essere recuperata. Tutti i commit che erano su rami che sono stati cancellati o sovrascritti tramite un commit `--amend` possono essere recuperati (vedi il *Capitolo 9* per il recupero dei dati). Tuttavia, qualsiasi cosa che perdi e che non è stata affidata a Git probabilmente non sarà mai più visto.
+Ricorda: qualsiasi cosa che sia stata committata in Git può quasi sempre essere recuperata. Tutte le commit che erano sulle diramazioni che sono state cancellate o sovrascritte con una commit `--amend` possono essere recuperate (vedi il *Capitolo 9* per il recupero dei dati). Ma qualsiasi cosa che perdi che non sia stata mai committata non la vedrai mai più.
 
 ## Lavorare con Sorgenti Remote ##
 

From ae0e37754f96a2187980e80a6eb192288c6eaff7 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Wed, 16 Apr 2014 09:00:47 +0200
Subject: [PATCH 311/690] [it] updating chapter2

Reviewed "Working with Remotes"
---
 it/02-git-basics/01-chapter2.markdown | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/it/02-git-basics/01-chapter2.markdown b/it/02-git-basics/01-chapter2.markdown
index 7cb147cba..e80f0cd39 100644
--- a/it/02-git-basics/01-chapter2.markdown
+++ b/it/02-git-basics/01-chapter2.markdown
@@ -760,10 +760,10 @@ Puoi vedere come le modifiche siano state annullate. Dovresti capire quanto ques
 
 Ricorda: qualsiasi cosa che sia stata committata in Git può quasi sempre essere recuperata. Tutte le commit che erano sulle diramazioni che sono state cancellate o sovrascritte con una commit `--amend` possono essere recuperate (vedi il *Capitolo 9* per il recupero dei dati). Ma qualsiasi cosa che perdi che non sia stata mai committata non la vedrai mai più.
 
-## Lavorare con Sorgenti Remote ##
+## Lavorare con sorgenti remote ##
 
-Per essere in grado di collaborare con un qualsiasi progetto Git, hai bisogno di sapere come amministrare il tuo repository remoto. I repository remoti sono versioni di progetti che sono ospitati in Internet o su una rete da qualche parte. Puoi averne più di uno, molti dei quali possono essere di sola lettura o di scrittura e lettura per te. Collaborare con altri implica di sapere amministrare questi repository remoti e mettere e togliere i dati a e da questi quando hai necessità di condividerli per lavoro.
-Amministrare repository remoti include il sapere aggiungere repository remoti, rimuovere quelli che non sono validi, amministrare vari rami remoti e definire quando sono tracciati o meno, e altro. In questa sezione, vedremo le tecniche di amministrazione remota.
+Per poter collaborare con un qualsiasi progetto Git, devi sapere come amministrare i tuoi repository remoti. I repository remoti sono versioni dei progetti ospitate da qualche parte su Internet o sulla rete locale. Puoi averne molti e normalmente avrai un accesso in sola lettura o anche in scrittura. Collaborare con altri implica di sapere amministrare questi repository remoti, inviarne e prelevarne dati per condividere il lavoro.
+Amministrare i repository remoti significa sapere come aggiungerli, rimuovere quelli che non più validi, amministrare varie diramazioni remote e decidere quali tracciare e quali no, e ancora altro. Di seguito tratteremo le conoscenze necessarie per farlo.
 
 ### Visualizzare la Sorgente Remota ###
 

From 139d8fb27671f63f5074d3fe7bbcfd078192bbe6 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Wed, 16 Apr 2014 09:02:08 +0200
Subject: [PATCH 312/690] [it] update chapter2

Updated titles
---
 it/02-git-basics/01-chapter2.markdown | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/it/02-git-basics/01-chapter2.markdown b/it/02-git-basics/01-chapter2.markdown
index e80f0cd39..40e2c6344 100644
--- a/it/02-git-basics/01-chapter2.markdown
+++ b/it/02-git-basics/01-chapter2.markdown
@@ -760,12 +760,12 @@ Puoi vedere come le modifiche siano state annullate. Dovresti capire quanto ques
 
 Ricorda: qualsiasi cosa che sia stata committata in Git può quasi sempre essere recuperata. Tutte le commit che erano sulle diramazioni che sono state cancellate o sovrascritte con una commit `--amend` possono essere recuperate (vedi il *Capitolo 9* per il recupero dei dati). Ma qualsiasi cosa che perdi che non sia stata mai committata non la vedrai mai più.
 
-## Lavorare con sorgenti remote ##
+## Lavorare coi server remote ##
 
 Per poter collaborare con un qualsiasi progetto Git, devi sapere come amministrare i tuoi repository remoti. I repository remoti sono versioni dei progetti ospitate da qualche parte su Internet o sulla rete locale. Puoi averne molti e normalmente avrai un accesso in sola lettura o anche in scrittura. Collaborare con altri implica di sapere amministrare questi repository remoti, inviarne e prelevarne dati per condividere il lavoro.
 Amministrare i repository remoti significa sapere come aggiungerli, rimuovere quelli che non più validi, amministrare varie diramazioni remote e decidere quali tracciare e quali no, e ancora altro. Di seguito tratteremo le conoscenze necessarie per farlo.
 
-### Visualizzare la Sorgente Remota ###
+### Vedi i tuoi server remoti ###
 
 Per vedere quale server remoto hai configurato, puoi lanciare il comando git remote. Questo elenca i soprannomi di ogni nodo specificato. Se hai clonato il tuo repository, dovresti al limite vedere origin —  che è il nome predefinito che Git da al server che hai clonato:
 

From aeff2e9a7e1b30ed408edd6b650b58f60b355248 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Wed, 16 Apr 2014 09:09:37 +0200
Subject: [PATCH 313/690] [it] updating chapter2

Reviewed "Showing Your Remotes"
---
 it/02-git-basics/01-chapter2.markdown | 20 ++++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/it/02-git-basics/01-chapter2.markdown b/it/02-git-basics/01-chapter2.markdown
index 40e2c6344..755964e81 100644
--- a/it/02-git-basics/01-chapter2.markdown
+++ b/it/02-git-basics/01-chapter2.markdown
@@ -767,26 +767,26 @@ Amministrare i repository remoti significa sapere come aggiungerli, rimuovere qu
 
 ### Vedi i tuoi server remoti ###
 
-Per vedere quale server remoto hai configurato, puoi lanciare il comando git remote. Questo elenca i soprannomi di ogni nodo specificato. Se hai clonato il tuo repository, dovresti al limite vedere origin —  che è il nome predefinito che Git da al server che hai clonato:
+Per vedere i server remoti che hai configurato, puoi eseguire il comando `git remote`. Questo elenca i nomi brevi di ogni nodo remoto che hai configurato. Se hai clonato il tuo repository, dovresti vedere almeno *origin* —  che è il nome predefinito che Git da al server da cui cloni:
 
 	$ git clone git://github.com/schacon/ticgit.git
-	Initialized empty Git repository in /private/tmp/ticgit/.git/
-	remote: Counting objects: 595, done.
-	remote: Compressing objects: 100% (269/269), done.
-	remote: Total 595 (delta 255), reused 589 (delta 253)
-	Receiving objects: 100% (595/595), 73.31 KiB | 1 KiB/s, done.
-	Resolving deltas: 100% (255/255), done.
+	Cloning into 'ticgit'...
+	remote: Reusing existing pack: 1857, done.
+	remote: Total 1857 (delta 0), reused 0 (delta 0)
+	Receiving objects: 100% (1857/1857), 374.35 KiB | 193.00 KiB/s, done.
+	Resolving deltas: 100% (772/772), done.
+	Checking connectivity... done.
 	$ cd ticgit
 	$ git remote
 	origin
 
-Puoi anche specificare `-v`, che mostra l'URL che Git ha salvato per il soprannome:
+Puoi anche aggiungere `-v`, che mostra anche l'URL che Git ha associato a quel nome breve:
 
 	$ git remote -v
 	origin  git://github.com/schacon/ticgit.git (fetch)
 	origin  git://github.com/schacon/ticgit.git (push)
 
-Se hai più di un repository remoto, il comando li elenca tutti. Per esempio, il mio repository Grit assomiglia a questo.
+Se hai più di un server remoto, il comando li elenca tutti. Per esempio, il mio repository di Grit appare così:
 
 	$ cd grit
 	$ git remote -v
@@ -796,7 +796,7 @@ Se hai più di un repository remoto, il comando li elenca tutti. Per esempio, il
 	koke      git://github.com/koke/grit.git
 	origin    git@github.com:mojombo/grit.git
 
-Questo significa che possiamo prendere i contributi da qualsiasi di questi utenti in modo facile. Ma nota che solo origin è un URL SSH, è l'unico dove posso fare il push (vedremo questa cosa nel Capitolo 4).
+Questo significa che posso prendere facilmente i contributi da qualunque di questi utenti. Nota però che solamente *origin* è un URL SSH, e quindi è l'unico dove posso inviare il mio lavoro con `push` (il perché lo vedremo nel *Capitolo 4*).
 
 ### Aggiungere un Repository Remoto ###
 

From ceba7dfb5358143802192fd6f231db1aa06aaccb Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Wed, 16 Apr 2014 09:12:28 +0200
Subject: [PATCH 314/690] updating chapter2

changed "we" with "I" to stay coherent with the end of the phrase.
He's talking about his own repository and his permissions.
---
 en/02-git-basics/01-chapter2.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/en/02-git-basics/01-chapter2.markdown b/en/02-git-basics/01-chapter2.markdown
index 57d2103a7..5a85343ce 100644
--- a/en/02-git-basics/01-chapter2.markdown
+++ b/en/02-git-basics/01-chapter2.markdown
@@ -796,7 +796,7 @@ If you have more than one remote, the command lists them all. For example, my Gr
 	koke      git://github.com/koke/grit.git
 	origin    git@github.com:mojombo/grit.git
 
-This means we can pull contributions from any of these users pretty easily. But notice that only the origin remote is an SSH URL, so it’s the only one I can push to (we’ll cover why this is in *Chapter 4*).
+This means I can pull contributions from any of these users pretty easily. But notice that only the origin remote is an SSH URL, so it’s the only one I can push to (we’ll cover why this is in *Chapter 4*).
 
 ### Adding Remote Repositories ###
 

From e37b5b2c0fca360cc353146366f0383c4817a927 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Wed, 16 Apr 2014 09:33:38 +0200
Subject: [PATCH 315/690] [it] updating chapter2

Reviewed "Adding Remote Repositories"
---
 it/02-git-basics/01-chapter2.markdown | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/it/02-git-basics/01-chapter2.markdown b/it/02-git-basics/01-chapter2.markdown
index 755964e81..8e3e596cc 100644
--- a/it/02-git-basics/01-chapter2.markdown
+++ b/it/02-git-basics/01-chapter2.markdown
@@ -798,9 +798,9 @@ Se hai più di un server remoto, il comando li elenca tutti. Per esempio, il mio
 
 Questo significa che posso prendere facilmente i contributi da qualunque di questi utenti. Nota però che solamente *origin* è un URL SSH, e quindi è l'unico dove posso inviare il mio lavoro con `push` (il perché lo vedremo nel *Capitolo 4*).
 
-### Aggiungere un Repository Remoto ###
+### Aggiungere un repository remoto ###
 
-Ho menzionato e fornito alcune dimostrazioni, nelle sezioni precedenti, sull'aggiunta di repository remoti, ma qui scendo nello specifico. Per aggiungere un nuovo repository Git con un soprannome per riconoscerlo velocemente, avvia `git remote add [soprannome] [url]`:
+Nelle sezioni precedenti ho accennato all'aggiunta dei repository remoti e dato alcuni esempi, ma qui lo vedremo nello specifico. Per aggiungere un nuovo repository Git remoto con un nome breve a cui possa riferirti facilmente, esegui `git remote add [nome breve] [url]`:
 
 	$ git remote
 	origin
@@ -809,7 +809,7 @@ Ho menzionato e fornito alcune dimostrazioni, nelle sezioni precedenti, sull'agg
 	origin	git://github.com/schacon/ticgit.git
 	pb	git://github.com/paulboone/ticgit.git
 
-Ora puoi usare la stringa pb dalla linea di comando al posto dell'intero URL. Per esempio, se vuoi prelevare tutte le informazioni che Paul ha ma che ancora non hai nel tuo repository, puoi lanciare git fetch pb:
+Ora potrai usare il nome `pb` alla riga di comando al posto dell'URL intero. Se vuoi, per esempio, prendere tutto ciò che ha Paul, ma che non sono ancora nel tuo repository, puoi eseguire `git fetch pb`:
 
 	$ git fetch pb
 	remote: Counting objects: 58, done.
@@ -820,7 +820,7 @@ Ora puoi usare la stringa pb dalla linea di comando al posto dell'intero URL. Pe
 	 * [new branch]      master     -> pb/master
 	 * [new branch]      ticgit     -> pb/ticgit
 
-Il ramo master di Paul è accessibile localmente come `pb/master` —  puoi unirlo in uno dei tuoi rami, o puoi caricare un tuo ramo locale a questo punto per ispezionarlo.
+La diramazione `master` di Paul è accessibile localmente come `pb/master` —  puoi farne il `merge` in uno delle tue diramazioni, o puoi scaricarla in una tua diramazione locale se vuoi controllarla.
 
 ### Prelevare e Trarre da Sorgenti in Remoto ###
 

From 063cc7f237ce04dd142971476fcefc8cb2c02051 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Wed, 16 Apr 2014 09:53:00 +0200
Subject: [PATCH 316/690] [it] updating chapter2

Reviewed "Fetching and Pulling from Your Remotes"
---
 it/02-git-basics/01-chapter2.markdown | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/it/02-git-basics/01-chapter2.markdown b/it/02-git-basics/01-chapter2.markdown
index 8e3e596cc..87717a49a 100644
--- a/it/02-git-basics/01-chapter2.markdown
+++ b/it/02-git-basics/01-chapter2.markdown
@@ -822,17 +822,17 @@ Ora potrai usare il nome `pb` alla riga di comando al posto dell'URL intero. Se
 
 La diramazione `master` di Paul è accessibile localmente come `pb/master` —  puoi farne il `merge` in uno delle tue diramazioni, o puoi scaricarla in una tua diramazione locale se vuoi controllarla.
 
-### Prelevare e Trarre da Sorgenti in Remoto ###
+### Scarica e condividi coi server remoti ###
 
-Come già visto, per ottenere i dati da un progetto remoto, puoi farlo:
+Come abbiamo appena visto, per scaricare dati da un progetto remoto, puoi fare:
 
 	$ git fetch [nome-remoto]
 
-Il comando va sul progetto remoto e si tira giù tutti i dati dal progetto remoto che ancora non hai. Dopo aver fatto questo, dovresti avere tutti i riferimenti ai rami da questa sorgente remota, che poi potrai fondere o ispezionare in ogni momento. (Vedremo cosa sono i rami e come usarli in maggior dettaglio al *Capitolo 3*).
+Il comando va sul progetto remoto e scarica tutti i dati dal progetto remoto che tu ancora non hai. Dopo averlo fatto dovresti trovare i riferimenti a tutte le diramazioni di quel server, che potrai unire o controllare in qualsiasi momento. (Vedremo in dettaglio cosa sono le diramazioni e come usarle nel *Capitolo 3*).
 
-Se hai clonato un repository, il comando automaticamente aggiunge un repository remoto sotto il nome origin. Così, `git fetch origin` preleva ogni lavoro che è stato inserito su quel server da quando hai fatto la clonazione (o dall'ultimo prelievo). E' importante notare che il comando `fetch` mette i dati nel tuo repository locale — non unisce automaticamente e non modifica alcun file su cui tu stai lavorando. Devi eseguire la fusione manualmente nel tuo lavoro, quando sei pronto.
+Quando cloni un repository, viene aggiunto automaticamente un repository remoto chiamato *origin*. In questo modo `git fetch origin` scarica le modifiche che sono state condividise con server remoto da quando lo hai clonato (o dall'ultimo tuo aggiornamento). È importante notare che il comando `fetch` scarica queste informazioni nel tuo repository locale: non le unisce automaticamente e non modifica alcun file su cui stai lavorando. Quando sei pronto dovrai essere tu a unirle al tuo lavoro, manualmente.
 
-Se hai un ramo impostato per tracciare un ramo remoto (vedi la prossima sezione e il Capitolo 3 per maggiori informazioni), puoi usare il comando `git pull` per prelevare automaticamente e poi fondere un ramo remoto nel ramo corrente. Questo è un modo più facile e comodo di lavorare; e in modo predefinito, il comando `git clone` automaticamente imposta il tuo ramo locale master per tracciare il ramo remoto master del server che hai clonato (assumendo che il sorgente remoto abbia un ramo master). Lanciare `git pull` generalmente preleva i dati dal server di origine clonato e automaticamente prova a fondere il codice con il codice su cui stai lavorando.
+Se hai una diramazione impostata per tracciarne una remota (vedi la prossima sezione e il *Capitolo 3* per maggiori informazioni), puoi usare il comando `git pull` per scaricare e unire automaticamente una diramazione remota in quella attuale. Questo potrebbe essere un modo più facile e più comodo per lavorare; e in modo predefinito, il comando `git clone` imposta automaticamente la tua diramazione `master` per tracciare il master del server che hai clonato (supponendo che il server remoto abbia una diramazione `master`). Eseguendo `git pull` vengono generalmente scaricati i dati dal server da cui hai fatto il clone originario e prova a unirli automaticamente con il codice su cui stai lavorando.
 
 ### Inserire nella Sorgente Remota ###
 

From dace670a29a4cd7e06941cb590005a569ca61cfa Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Wed, 16 Apr 2014 10:10:58 +0200
Subject: [PATCH 317/690] [it] changing chapter2

Reviewed "Pushing to Your Remotes"
---
 it/02-git-basics/01-chapter2.markdown | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/it/02-git-basics/01-chapter2.markdown b/it/02-git-basics/01-chapter2.markdown
index 87717a49a..e8c538088 100644
--- a/it/02-git-basics/01-chapter2.markdown
+++ b/it/02-git-basics/01-chapter2.markdown
@@ -834,13 +834,13 @@ Quando cloni un repository, viene aggiunto automaticamente un repository remoto
 
 Se hai una diramazione impostata per tracciarne una remota (vedi la prossima sezione e il *Capitolo 3* per maggiori informazioni), puoi usare il comando `git pull` per scaricare e unire automaticamente una diramazione remota in quella attuale. Questo potrebbe essere un modo più facile e più comodo per lavorare; e in modo predefinito, il comando `git clone` imposta automaticamente la tua diramazione `master` per tracciare il master del server che hai clonato (supponendo che il server remoto abbia una diramazione `master`). Eseguendo `git pull` vengono generalmente scaricati i dati dal server da cui hai fatto il clone originario e prova a unirli automaticamente con il codice su cui stai lavorando.
 
-### Inserire nella Sorgente Remota ###
+### Condividi coi server remoti ###
 
-Quando hai il tuo progetto al punto in cui lo vuoi condividere, devi inviarlo a monte (push upstream). Il comando per fare questo è semplice: `git push [nome-remoto] [nome-ramo]`. Se vuoi fare il push del tuo ramo master al tuo server `origin` (ancora, generalmente con la clonazione sono impostati entrambi questi nomi automaticamente), puoi lanciare il push per mettere il tuo lavoro sul server:
+Quando il tuo progetto raggiunge uno stato che vuoi condividere, devi caricarlo sul server principale. Il comando perlo è semplice: `git push [nome-remoto] [diramazione]`. Se vuoi condividere la tua diramazione `master` sul tuo server `origin` (lo ripeto: clonando questi nomi vengono generalmente definiti automaticamente), puoi eseguire il comando seguente per caricare il tuo lavoro sul server:
 
 	$ git push origin master
 
-Questo comando funziona solamente se hai fatto una clonazione da un server in cui hai i permessi di scrittura e se nessuno ha inviato dati nel mentre. Se tu e qualcun altro clonate un repository nello stesso momento ed essi inviano i dati, e poi tu invii i dati, il tuo invio verrà gustamente rifiutato. Devi prima scaricare il loro lavoro ed incorporarlo nel tuo per poter inviare le tue modifiche. Vedi il *Capitolo 3* per maggiori dettagli ed informazioni su come fare il push su server remoti.
+Questo comando funziona solamente se hai clonato il tuo progetto da un server su cui hai i permessi di scrittura e se nessun altro ha caricato modifiche nel frattempo. Se cloni un repository assieme ad altri e questi caricano delle modifiche sul server, il tuo invio verrà rifiutato. Dovrai prima scaricare le loro modifiche e incorporarle con le tue per poterle poi inviare. Vedi il *Capitolo 3* per maggiori informazioni su come fare il `push` su server remoti.
 
 ### Ispezionare una Sorgente Remota ###
 

From 413e731b2220b79b9d87e1bcc1d61dc62d1b12ea Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Wed, 16 Apr 2014 10:38:18 +0200
Subject: [PATCH 318/690] [it] updating chapter2

Reviewed "Inspecting a Remote"
---
 it/02-git-basics/01-chapter2.markdown | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/it/02-git-basics/01-chapter2.markdown b/it/02-git-basics/01-chapter2.markdown
index e8c538088..27a4fe66b 100644
--- a/it/02-git-basics/01-chapter2.markdown
+++ b/it/02-git-basics/01-chapter2.markdown
@@ -842,9 +842,9 @@ Quando il tuo progetto raggiunge uno stato che vuoi condividere, devi caricarlo
 
 Questo comando funziona solamente se hai clonato il tuo progetto da un server su cui hai i permessi di scrittura e se nessun altro ha caricato modifiche nel frattempo. Se cloni un repository assieme ad altri e questi caricano delle modifiche sul server, il tuo invio verrà rifiutato. Dovrai prima scaricare le loro modifiche e incorporarle con le tue per poterle poi inviare. Vedi il *Capitolo 3* per maggiori informazioni su come fare il `push` su server remoti.
 
-### Ispezionare una Sorgente Remota ###
+### Controllare un server remoto ###
 
-Se vuoi vedere più informazioni su di una sorgente remota in particolare, puoi usare il comando `git remote show [nome-remoto]`. Se lanci il comando con un soprannome particolare, come `origin`, avrai qualcosa di simile a questo:
+Se vuoi più informazioni su una particolare server remoto, puoi usare il comando `git remote show [nome-remoto]`. Se esegui il comando con un nome particolare, per esempio `origin`, avrai qualcosa di simile:
 
 	$ git remote show origin
 	* remote origin
@@ -855,9 +855,9 @@ Se vuoi vedere più informazioni su di una sorgente remota in particolare, puoi
 	    master
 	    ticgit
 
-Questo elenca tutti gli URL del repository remoto oltre che alle informazioni sui rami tracciati. Il comando utilmente ti dirà che sei sul ramo principale e se lanci `git pull`, questo automaticamente unirà il ramo master sul server remoto dopo aver prelevato tutte i riferimenti remoti. Inoltre elencherà i riferimenti che ha scaricato.
+che mostra gli URL del repository remoto oltre alle informazioni sulle diramazioni tracciate. Il comando ti dice anche se esegui `git pull` mentre sei su `master`, integrerà le modifiche sul `master` remoto dopo aver scaricato tutti i riferimenti remoti. Elenca anche i riferimenti remoti che hai già scaricato.
 
-Questo è un semplice esempio che potrai incontrare. Quando usi moltissimo Git, tuttavia, potrai vedere molte più informazioni da `git remote show`:
+Questo è un esempio semplice di quanto probabilmente vedrai. Tuttavia, quando usi intensamente Git potresti trovare molte più informazioni con `git remote show`:
 
 	$ git remote show origin
 	* remote origin
@@ -881,7 +881,7 @@ Questo è un semplice esempio che potrai incontrare. Quando usi moltissimo Git,
 	  Local branch pushed with 'git push'
 	    master:master
 
-Questo comando mostra quale ramo è automaticamente caricato quando lanci `git push` su certe diramazioni. Inoltre ti mostrerà quali rami remoti sul server che ancora non possiedi, quali rami remoti possiedi e che saranno rimossi dal server, e le diramazioni che saranno automaticamente unite quando lancerai `git pull`.
+Questo comando mostra quale diramazione viene scaricata automaticamente quando esegui `git push` su certe diramazioni. Mostra anche quali diramazioni remote non hai ancora scaricato, quali diramazioni remote hai in locale che sono state rimosse dal server, e le diramazioni che vengono unite automaticamente quando esegui `git pull`.
 
 ### Rimuovere e Rinominare Sorgenti Remote ###
 

From 706bed250c0635d3f2a54275edb5a14e21e547a5 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Wed, 16 Apr 2014 10:41:22 +0200
Subject: [PATCH 319/690] [it] updating chapter2

Reviewed "Removing and Renaming Remotes"
---
 it/02-git-basics/01-chapter2.markdown | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/it/02-git-basics/01-chapter2.markdown b/it/02-git-basics/01-chapter2.markdown
index 27a4fe66b..b3c9ee3cc 100644
--- a/it/02-git-basics/01-chapter2.markdown
+++ b/it/02-git-basics/01-chapter2.markdown
@@ -883,18 +883,18 @@ Questo è un esempio semplice di quanto probabilmente vedrai. Tuttavia, quando u
 
 Questo comando mostra quale diramazione viene scaricata automaticamente quando esegui `git push` su certe diramazioni. Mostra anche quali diramazioni remote non hai ancora scaricato, quali diramazioni remote hai in locale che sono state rimosse dal server, e le diramazioni che vengono unite automaticamente quando esegui `git pull`.
 
-### Rimuovere e Rinominare Sorgenti Remote ###
+### Rimuovere e rinominare server remoti ###
 
-Se vuoi rinominare un riferimento, nelle nuove versioni di Git, puoi lanciare `git remote rename` per cambiare il soprannome di una sorgente remota. Per esempio, se vuoi rinominare `pb` in `paul`, puoi farlo con `git remote rename`:
+Se vuoi rinominare un riferimento, con versioni più recenti di Git, puoi farlo con `git remote rename` per cambiare il nome breve di un server remoto. Se vuoi per esempio rinominare `pb` in `paul`, puoi farlo con `git remote rename`:
 
 	$ git remote rename pb paul
 	$ git remote
 	origin
 	paul
 
-Vale la pena ricordare che questo cambia anche i nomi dei rami remoti. Quello che prima era riferito a `pb/master` ora è `paul/master`.
+Vale la pena ricordare che questo cambia anche i nomi delle diramazioni remote. Quello che prima veniva chiamato `pb/master` ora è `paul/master`.
 
-Se vuoi rimuovere un riferimento per una qualche ragione — hai spostato il server o non stai più usando un mirror particolare, o magari un collaboratore non collabora più — puoi usare `git remote rm`:
+Se vuoi rimuovere un riferimento per qualsiasi ragione (hai spostato il server o non stai più usando un particolare mirror, o magari un collaboratore che non collabora più) puoi usare `git remote rm`:
 
 	$ git remote rm paul
 	$ git remote

From d5a0378cb8482add3b3018dd3121c071752d9034 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Wed, 16 Apr 2014 10:45:39 +0200
Subject: [PATCH 320/690] [it] updating chapter2

Reviewed "Tagging"
---
 it/02-git-basics/01-chapter2.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/it/02-git-basics/01-chapter2.markdown b/it/02-git-basics/01-chapter2.markdown
index b3c9ee3cc..4ebad9565 100644
--- a/it/02-git-basics/01-chapter2.markdown
+++ b/it/02-git-basics/01-chapter2.markdown
@@ -902,7 +902,7 @@ Se vuoi rimuovere un riferimento per qualsiasi ragione (hai spostato il server o
 
 ### Etichettare ###
 
-Come la maggior parte dei VCS, Git ha la possibilità di contrassegnare (tag, ndt) dei punti specifici della storia come importanti. Generalmente, le persone usano questa funzionalità per marcare i punti di rilascio (v1.0, e così via). In questa sezione, imparerai come elencare le etichette disponibili, come crearne di nuove, ed i differenti tipi di etichette esistenti.
+Come la maggior parte dei VCS, Git ha la possibilità di contrassegnare (tag, ndt) dei punti specifici della cronologia come importanti. Le persone normalmente usano questa funzionalità per segnare i punti di rilascio (v1.0, e così via). In questa sezione, imparerai come elencare le etichette disponibili, come crearne di nuove, e i diversi tipi di etichette esistenti.
 
 ### Elencare le Proprie Etichette ###
 

From 14e474c9e088419095e8b86508d5a9e4161aae28 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Wed, 16 Apr 2014 10:47:52 +0200
Subject: [PATCH 321/690] [it] updating "Listing Your Tags"

---
 it/02-git-basics/01-chapter2.markdown | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/it/02-git-basics/01-chapter2.markdown b/it/02-git-basics/01-chapter2.markdown
index 4ebad9565..45c0a48d9 100644
--- a/it/02-git-basics/01-chapter2.markdown
+++ b/it/02-git-basics/01-chapter2.markdown
@@ -904,17 +904,17 @@ Se vuoi rimuovere un riferimento per qualsiasi ragione (hai spostato il server o
 
 Come la maggior parte dei VCS, Git ha la possibilità di contrassegnare (tag, ndt) dei punti specifici della cronologia come importanti. Le persone normalmente usano questa funzionalità per segnare i punti di rilascio (v1.0, e così via). In questa sezione, imparerai come elencare le etichette disponibili, come crearne di nuove, e i diversi tipi di etichette esistenti.
 
-### Elencare le Proprie Etichette ###
+### Elena le etichette ###
 
-Elencare le etichette disponibili in Git è facilissimo. Semplicemente digita `git tag`:
+Elencare le etichette esistenti in Git è facilissimo. Digita semplicemente `git tag`:
 
 	$ git tag
 	v0.1
 	v1.3
 
-Questo comando elenca le etichette in ordine alfabetico; l'ordine con il quale compaiono non è realmente importante.
+Questo comando elenca le etichette in ordine alfabetico; l'ordine con cui appaiono non ha importanza.
 
-Puoi inoltre cercare le etichette con uno schema specifico. Il repository sorgente di Git, per esempio, contiene più di 240 etichette. Se sei solo interessato a vedere quelli della serie 1.4.2, puoi lanciare:
+Puoi inoltre cercare etichette con uno schema specifico. Il repository sorgente di Git, per esempio, contiene più di 240 etichette. Se sei interessato a vedere solo quelli della serie 1.4.2, puoi eseguire:
 
 	$ git tag -l 'v1.4.2.*'
 	v1.4.2.1

From b04a0289091bfcd622d82fa1181e964dace61b27 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Wed, 16 Apr 2014 10:54:37 +0200
Subject: [PATCH 322/690] [it] reviewed "Creating Tags"

---
 it/02-git-basics/01-chapter2.markdown | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/it/02-git-basics/01-chapter2.markdown b/it/02-git-basics/01-chapter2.markdown
index 45c0a48d9..4fb61f8e0 100644
--- a/it/02-git-basics/01-chapter2.markdown
+++ b/it/02-git-basics/01-chapter2.markdown
@@ -922,9 +922,9 @@ Puoi inoltre cercare etichette con uno schema specifico. Il repository sorgente
 	v1.4.2.3
 	v1.4.2.4
 
-### Creare Etichette ###
+### Creare etichette ###
 
-Git usa due principali tipi di etichette: lightweight (semplificate, ndt) e annotated (commentate, ndt). Un'etichetta lightweight è molto simile ad un ramo che non è cambiato —  è semplicemente un riferimento ad uno specifico commit. Le etichette annotated, tuttavia, sono salvate come oggetti nel database Git. Ne viene calcolato il checksum; contengono il nome, l'e-mail e la data di chi ha inserito l'etichetta; hanno un messaggio; e possono essere firmati e verificati con GNU Privacy Guard (GPG). É generalmente raccomandato creare etichette annotated così puoi avere tutte queste informazioni; ma se vuoi temporaneamente inserire un'etichetta e per qualche ragione non vuoi avere queste informazioni, le etichette lightweight sono ancora disponibili.
+Git ha due tipi di etichette: semplici (`lightweight`, ndt) e annotate (`annotated`, ndt). Un'etichetta semplice è molto simile a una ramificazione che non cambia mai:  è semplicemente un riferimento ad una commit specifica. Le etichette annotate, al contrario, sono salvate come oggetti complessi nel database Git. Ne viene calcolato il checksum, contengono il nome, l'e-mail e la data di chi ha inserito l'etichetta, hanno un messaggio d'etichetta; e possono essere firmate e verificate con GPG (GNU Privacy Guard). Generalmente si raccomanda di usare le etichette annotate così da avere tutte queste informazioni, ma se vuoi aggiungere un'etichetta temporanea o per qualche ragione non vuoi salvare quelle informazioni aggiuntive, hai sempre a disposizione le etichette semplici.
 
 ### Etichette Annotated ###
 

From fc4d2f72e6afd729a48223168724a09fa56d8482 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Wed, 16 Apr 2014 11:01:41 +0200
Subject: [PATCH 323/690] [it] updating chapter2

Reviewed "Annotated Tags"
---
 it/02-git-basics/01-chapter2.markdown | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/it/02-git-basics/01-chapter2.markdown b/it/02-git-basics/01-chapter2.markdown
index 4fb61f8e0..d9d5193de 100644
--- a/it/02-git-basics/01-chapter2.markdown
+++ b/it/02-git-basics/01-chapter2.markdown
@@ -926,9 +926,9 @@ Puoi inoltre cercare etichette con uno schema specifico. Il repository sorgente
 
 Git ha due tipi di etichette: semplici (`lightweight`, ndt) e annotate (`annotated`, ndt). Un'etichetta semplice è molto simile a una ramificazione che non cambia mai:  è semplicemente un riferimento ad una commit specifica. Le etichette annotate, al contrario, sono salvate come oggetti complessi nel database Git. Ne viene calcolato il checksum, contengono il nome, l'e-mail e la data di chi ha inserito l'etichetta, hanno un messaggio d'etichetta; e possono essere firmate e verificate con GPG (GNU Privacy Guard). Generalmente si raccomanda di usare le etichette annotate così da avere tutte queste informazioni, ma se vuoi aggiungere un'etichetta temporanea o per qualche ragione non vuoi salvare quelle informazioni aggiuntive, hai sempre a disposizione le etichette semplici.
 
-### Etichette Annotated ###
+### Etichette annotate ###
 
-Creare un'etichetta annotated in Git è semplice. La via più facile è specificare `-a` quando si lancia il comando `tag`:
+Creare un'etichetta annotate in Git è semplice. Il modo più facile è specificare `-a` quando esegui il comando `tag`:
 
 	$ git tag -a v1.4 -m 'my version 1.4'
 	$ git tag
@@ -936,9 +936,9 @@ Creare un'etichetta annotated in Git è semplice. La via più facile è specific
 	v1.3
 	v1.4
 
-`-m` specifica il messaggio, che è salvato con l'etichetta. Se non specifichi un messaggio per una etichetta annotated, Git lancerà il tuo editor così potrai inserirlo.
+`-m` specifica il messaggio per l'etichetta, che viene salvato con l'a stessa. Se non specifichi un messaggio per un'etichetta annotata, Git lancerà il tuo editor così da scriverla.
 
-Puoi vedere i dati dell'etichetta assieme al commit in cui è stato inserito l'etichetta con il comando `git show`:
+Puoi vedere i dati dell'etichetta assieme alla commit etichettata con il comando `git show`:
 
 	$ git show v1.4
 	tag v1.4
@@ -953,7 +953,7 @@ Puoi vedere i dati dell'etichetta assieme al commit in cui è stato inserito l'e
 
 	    Merge branch 'experiment'
 
-Questo mostra le informazioni di chi ha eseguito l'etichetta, la data del commit della stessa, ed il messaggio prima di mostrare le informazioni del commit.
+Questo mostra le informazioni dell'etichetta, la data in cui la commit è stata etichettata e il messaggio, prima di mostrare le informazioni della commit.
 
 ### Firmare le Etichette ###
 

From 86fd34b2e4a928a4bcaf1d500b54ad019075fbac Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Wed, 16 Apr 2014 11:56:54 +0200
Subject: [PATCH 324/690] [it] updating chapter2

Reviewed "Signed Tags"
---
 it/02-git-basics/01-chapter2.markdown | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/it/02-git-basics/01-chapter2.markdown b/it/02-git-basics/01-chapter2.markdown
index d9d5193de..ce6a6433b 100644
--- a/it/02-git-basics/01-chapter2.markdown
+++ b/it/02-git-basics/01-chapter2.markdown
@@ -955,16 +955,16 @@ Puoi vedere i dati dell'etichetta assieme alla commit etichettata con il comando
 
 Questo mostra le informazioni dell'etichetta, la data in cui la commit è stata etichettata e il messaggio, prima di mostrare le informazioni della commit.
 
-### Firmare le Etichette ###
+### Etichette firmate ###
 
-Puoi anche firmare le tue etichette con GPG, assumendo che tu abbia una chiave privata. Tutto quello che devi fare è usare `-s` invece di `-a`:
+Puoi anche firmare le tue etichette con GPG, presumendo che tu abbia una chiave privata. Tutto quello che devi fare è usare `-s` invece di `-a`:
 
 	$ git tag -s v1.5 -m 'my signed 1.5 tag'
 	You need a passphrase to unlock the secret key for
 	user: "Scott Chacon <schacon@gee-mail.com>"
 	1024-bit DSA key, ID F721C45A, created 2009-02-09
 
-Se lanci `git show` su questa etichetta, potrai vedere la tua firma GPG in allegato ad essa:
+Se esegui `git show` per questa etichetta, puoi vedere che è stata allegata la tua firma GPG:
 
 	$ git show v1.5
 	tag v1.5

From bb591956e0a5b723c24441d13978fa2622666600 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Wed, 16 Apr 2014 12:00:01 +0200
Subject: [PATCH 325/690] [it] updating chapter2

Reviewed "Lightweight Tags"
---
 it/02-git-basics/01-chapter2.markdown | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/it/02-git-basics/01-chapter2.markdown b/it/02-git-basics/01-chapter2.markdown
index ce6a6433b..f6e047065 100644
--- a/it/02-git-basics/01-chapter2.markdown
+++ b/it/02-git-basics/01-chapter2.markdown
@@ -988,9 +988,9 @@ Se esegui `git show` per questa etichetta, puoi vedere che è stata allegata la
 
 Più avanti, imparerai come verificare le etichette firmate.
 
-### Etichette Lightweight ###
+### Etichette semplici ###
 
-Un altro modo per marcare i commit è usare le etichette lightweight. Questo è semplicemente fare il checksum del commit salvato in un file — nessun'altra informazione è mantenuta. Per creare un'etichetta semplificata, non fornire l'opzione `-a`, `s` o `-m`:
+Un altro modo per etichettare una commit è con le etichette semplici. Questo in pratica è salvare il checksum della commit in un file: non viene salvata nessun'altra informazione. Per creare un'etichetta semplice, non usare le opzioni `-a`, `s` o `-m`:
 
 	$ git tag v1.4-lw
 	$ git tag
@@ -1000,7 +1000,7 @@ Un altro modo per marcare i commit è usare le etichette lightweight. Questo è
 	v1.4-lw
 	v1.5
 
-A questo punto, se lanci `git show` sulla tua etichetta, non vedrai altre informazioni aggiuntive. Il comando semplicemente mostra il commit:
+Se ora lanci `git show` per questa etichetta, non vedrai altre informazioni aggiuntive. Il comando mostra solamente la commit:
 
 	$ git show v1.4-lw
 	commit 15027957951b64cf874c3557a0f3547bd83b3ff6

From ce8008c388ef706e83a15aa6a1a656b59302f1e4 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Wed, 16 Apr 2014 12:03:16 +0200
Subject: [PATCH 326/690] [it] updating chapter2

Reviewed "Verifying Tags"
---
 it/02-git-basics/01-chapter2.markdown | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/it/02-git-basics/01-chapter2.markdown b/it/02-git-basics/01-chapter2.markdown
index f6e047065..d7f9ab134 100644
--- a/it/02-git-basics/01-chapter2.markdown
+++ b/it/02-git-basics/01-chapter2.markdown
@@ -1010,9 +1010,9 @@ Se ora lanci `git show` per questa etichetta, non vedrai altre informazioni aggi
 
 	    Merge branch 'experiment'
 
-### Verificare le Etichette ###
+### Verificare le etichette ###
 
-Per verificarele etichetta firmate, usa `git tag -v [nome-tag]`. Questo comando usa la verifica GPG della firma. Avrai bisogno della chiave pubblica del firmatario nel tuo portachiavi affinché funzioni correttamente:
+Per verificarele un'etichetta firmata, usa `git tag -v [nome-tag]`. Questo comando usa GPG per verificare la verifica. Affinché funzioni hai bisogno che la chiave pubblica del firmatario sia nel tuo portachiavi:
 
 	$ git tag -v v1.4.2.1
 	object 883653babd8ee7ea23e6a5c392bb739348b1eb61
@@ -1028,7 +1028,7 @@ Per verificarele etichetta firmate, usa `git tag -v [nome-tag]`. Questo comando
 	gpg:                 aka "[jpeg image of size 1513]"
 	Primary key fingerprint: 3565 2A26 2040 E066 C9A7  4A7D C0C6 D9A4 F311 9B9A
 
-Se non hai la chiave pubblica del firmatario, otterrai qualche cosa di simile a questo invece:
+Se non hai la chiave pubblica del firmatario, otterrai invece qualcosa così:
 
 	gpg: Signature made Wed Sep 13 02:08:25 2006 PDT using DSA key ID F3119B9A
 	gpg: Can't check signature: public key not found

From a52a3868d932ae82b8feddfcb9f03b48b61fb0a9 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Wed, 16 Apr 2014 12:07:08 +0200
Subject: [PATCH 327/690] [it] updating chapter2

Reviewed "Tagging Later"
---
 it/02-git-basics/01-chapter2.markdown | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/it/02-git-basics/01-chapter2.markdown b/it/02-git-basics/01-chapter2.markdown
index d7f9ab134..fa1f5fdb6 100644
--- a/it/02-git-basics/01-chapter2.markdown
+++ b/it/02-git-basics/01-chapter2.markdown
@@ -1034,9 +1034,9 @@ Se non hai la chiave pubblica del firmatario, otterrai invece qualcosa così:
 	gpg: Can't check signature: public key not found
 	error: could not verify the tag 'v1.4.2.1'
 
-### Inserire una Etichetta Successivamente ###
+### Etichettare successivamente ###
 
-Puoi anche etichettare i commit che hai già superato. Supponiamo che la storia dei tuoi commit sia come questa: 
+Puoi etichettare anche commit passate. Supponiamo che la cronologia delle tue commit sia questa: 
 
 	$ git log --pretty=oneline
 	15027957951b64cf874c3557a0f3547bd83b3ff6 Merge branch 'experiment'
@@ -1050,11 +1050,11 @@ Puoi anche etichettare i commit che hai già superato. Supponiamo che la storia
 	964f16d36dfccde844893cac5b347e7b3d44abbc commit the todo
 	8a5cbc430f1a9c3d00faaeffd07798508422908a updated readme
 
-Ora, supponiamo che ti sia dimenticato di mettere l'etichetta v1.2 al tuo progetto, che è al commit "updated rakefile". Puoi aggiungerlo successivamente. Per marcare questo commit, devi specificare il checksum (o parte di esso) del commit alla fine del comando:
+Supponiamo che abbia dimenticato di etichettare il progetto alla `v1.2`, che era con la commit "updated rakefile". Puoi sempre aggiungerla in un secondo momento. Per etichettare questa commit, alla fine del comando, devi indicare il checksum (o parte di esso) della commit:
 
-	$ git tag -a v1.2 9fceb02
+	$ git tag -a v1.2 -m 'version 1.2' 9fceb02
 
-Puoi vedere che hai marcato il commit:
+Puoi vedere che hai etichettato la commit:
 
 	$ git tag
 	v0.1

From 6143fdb5b59196a7681f94871159d111841aaf26 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Wed, 16 Apr 2014 12:11:21 +0200
Subject: [PATCH 328/690] [it] updating chapter2

Reviewed "Sharing Tags"
---
 it/02-git-basics/01-chapter2.markdown | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/it/02-git-basics/01-chapter2.markdown b/it/02-git-basics/01-chapter2.markdown
index fa1f5fdb6..6be336ad5 100644
--- a/it/02-git-basics/01-chapter2.markdown
+++ b/it/02-git-basics/01-chapter2.markdown
@@ -1077,9 +1077,9 @@ Puoi vedere che hai etichettato la commit:
 	    updated rakefile
 	...
 
-### Condividere le Etichette ###
+### Condividere le etichette ###
 
-Di base, il comando `git push` non trasferisce le etichette sui server remoti. Devi esplicitamente inviare le etichette da condividere con il server dopo averle create. Questo processo è come condividere rami remoti — puoi lanciare `git push origin [nometag]`.
+Normalmente il comando `git push` non invia le etichette sui server remoti. Devi farlo esplicitamente, dopo averle create, per condividerle con il server. Questo procedimento è come la condivisione delle diramazioni remote: puoi eseguire `git push origin [nome-tag
 
 	$ git push origin v1.5
 	Counting objects: 50, done.
@@ -1089,7 +1089,7 @@ Di base, il comando `git push` non trasferisce le etichette sui server remoti. D
 	To git@github.com:schacon/simplegit.git
 	* [new tag]         v1.5 -> v1.5
 
-Se hai molte etichetta che vuoi inviare tutte assieme, puoi farlo usando l'opzione `--tags` del comando `git push`. Questo trasferirà tutti le tue etichette sul server remoto che non sono ancora presenti.
+Se hai molte etichetta che vuoi inviare tutte assieme, puoi farlo usando l'opzione `--tags` col comando `git push`. Questo trasferirà al server remoto tutte le tue etichette che non sono ancora presenti.
 
 	$ git push origin --tags
 	Counting objects: 50, done.
@@ -1103,7 +1103,7 @@ Se hai molte etichetta che vuoi inviare tutte assieme, puoi farlo usando l'opzio
 	 * [new tag]         v1.4-lw -> v1.4-lw
 	 * [new tag]         v1.5 -> v1.5
 
-Ora, quando qualcun altro clona o scarica dal tuo repository, avrà anche tutti le tue etichette.
+Quando qualcuno clonerà il repository o scaricherà gli aggiornamenti, scaricherà anche tutte le tue etichette.
 
 ## Suggerimenti e Trucchi ##
 

From de493de93e9e71033570cc1f1e7259a34bb3cc63 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Wed, 16 Apr 2014 12:14:05 +0200
Subject: [PATCH 329/690] [it] updating chapter2

Reviewed "Tips and Tricks"
---
 it/02-git-basics/01-chapter2.markdown | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/it/02-git-basics/01-chapter2.markdown b/it/02-git-basics/01-chapter2.markdown
index 6be336ad5..a796fc380 100644
--- a/it/02-git-basics/01-chapter2.markdown
+++ b/it/02-git-basics/01-chapter2.markdown
@@ -1105,9 +1105,9 @@ Se hai molte etichetta che vuoi inviare tutte assieme, puoi farlo usando l'opzio
 
 Quando qualcuno clonerà il repository o scaricherà gli aggiornamenti, scaricherà anche tutte le tue etichette.
 
-## Suggerimenti e Trucchi ##
+## Suggerimenti ##
 
-Prima di finire questo capitolo sulle basi di Git, ecco alcuni suggerimenti e trucchi per rendere l'esperienza nell'uso di Git più semplice, facile e familiare. Molte persone usano Git senza usare questi suggerimenti e non ci riferiremo ad essi o presumeremo che tu li abbia usati successivamente nel libro; ma probabilmente dovresti sapere come realizzarli.
+Prima di terminare questo capitolo sulle basi di Git, ecco alcuni suggerimenti e trucchi per rendere la tua esperienza con Git più semplice, più facile e più familiare. Molte persone usano Git ma nessuno di questi suggerimenti e in seguito nel libro non ci riferiremo ad essi né presumeremo che tu li abbia usati, ma probabilmente dovresti sapere come realizzarli.
 
 ### Auto-Completamento ###
 

From 65028ab986ced0762277132b0118860335d6bff1 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Wed, 16 Apr 2014 12:37:08 +0200
Subject: [PATCH 330/690] [it] updating chapter2

Reviewed "Auto-Completion
---
 it/02-git-basics/01-chapter2.markdown | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/it/02-git-basics/01-chapter2.markdown b/it/02-git-basics/01-chapter2.markdown
index a796fc380..f72778e01 100644
--- a/it/02-git-basics/01-chapter2.markdown
+++ b/it/02-git-basics/01-chapter2.markdown
@@ -1109,29 +1109,29 @@ Quando qualcuno clonerà il repository o scaricherà gli aggiornamenti, scariche
 
 Prima di terminare questo capitolo sulle basi di Git, ecco alcuni suggerimenti e trucchi per rendere la tua esperienza con Git più semplice, più facile e più familiare. Molte persone usano Git ma nessuno di questi suggerimenti e in seguito nel libro non ci riferiremo ad essi né presumeremo che tu li abbia usati, ma probabilmente dovresti sapere come realizzarli.
 
-### Auto-Completamento ###
+### Completamento automatico ###
 
-Se usi una shell Bash, Git fornisce un piacevole script di auto completamento che può essere usato. Scarica il codice sorgente di Git, e guarda nella directory `contrib/completation`; dovrebbe esserci un file chiamato `git-completation.bash`. Copia questo file nella tua directory di home e aggiungila al tuo file `.bashrc`:
+Se usi una shell Bash, Git fornisce uno script carino per il completamento automatico che potresti usare. Scaricalo direttamente dai sorgenti di Git su https://github.com/git/git/blob/master/contrib/completion/git-completion.bash. Copia questo file nella tua directory `home` e al tuo file `.bashrc` aggiungi:
 
 	source ~/.git-completion.bash
 
-Se vuoi impostare Git per avere l'auto completamento della shell Bash per tutti gli utenti, copia lo script nella directory `/opt/local/etc/bash_completion.d` sui sistemi Mac o in `/etc/bash_completion.d/` sui sistemi Linux. Questa è una directory degli script che Bash automaticamente carica per fornire l'auto completamento da shell.
+Se vuoi che Git usi il comletamento automatico in Bash per tutti gli utenti, copia lo script nella directory `/opt/local/etc/bash_completion.d` sui sistemi Mac o in `/etc/bash_completion.d/` sui sistemi Linux. Questa è una directory di script che Bash carica automaticamente, per fornire il completamento automatico nella shell.
 
-Se stai usando Windows con Git Bash, che è l'installazione di base per Git su Windows con msysGit, l'auto completamento dovrebbe essere preconfigurato.
+Se stai usando Windows con Git Bash, che è il predefinito quando installi Git su Windows con msysGit, il completamento automatico dovrebbe essere preconfigurato.
 
-Premi il tasto Tab quando stai scrivendo un comando Git, e dovresti avere una serie di suggerimenti da selezionare:
+Premi il tasto Tab quando stai scrivendo un comando Git, e dovresti vedere una serie di suggerimenti tra cui scegliere:
 
 	$ git co<tab><tab>
 	commit config
 
-In questo caso, scrivendo git co e poi premendo il tasto Tab due volte compaiono i suggerimenti commit e config. Aggiungendo `m<tab>` si completa `git commit` automaticamente.
+In questo caso, scrivendo `git co` e premendo poi due volte il tasto Tab, compaiono i suggerimenti commit e config. Aggiungendo `m<tab>` automaticamente si completa `git commit`.
 
-Questo funziona anche con le opzioni, cosa che forse è molto più utile. Per esempio, se si lancia il comando `git log` e non si ricorda una opzione, si può iniziare a pigiare il tasto Tab per vedere le corrispondenze:
+Questo funziona anche con le opzioni, che probabilmente è molto più utile. Se per esempio stai eseguendo `git log` e non ricordi un'opzione, puoi premere il tasto Tab per vedere quelle disponibili:
 
 	$ git log --s<tab>
 	--shortstat  --since=  --src-prefix=  --stat   --summary
 
-Questo è un trucco davvero utile e permette di risparmiare molto tempo e lettura della documentazione.
+Questo è un trucco davvero utile e permette di risparmiare molto tempo e evitarti la lettura della documentazione.
 
 ### Alias con Git ###
 

From d279224b0831cce1348e0392f783af1bdfe4dc80 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Wed, 16 Apr 2014 15:06:17 +0200
Subject: [PATCH 331/690] [it] updated chapter2

Fully reviewed
---
 it/02-git-basics/01-chapter2.markdown | 20 ++++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/it/02-git-basics/01-chapter2.markdown b/it/02-git-basics/01-chapter2.markdown
index f72778e01..36559d422 100644
--- a/it/02-git-basics/01-chapter2.markdown
+++ b/it/02-git-basics/01-chapter2.markdown
@@ -1133,31 +1133,31 @@ Questo funziona anche con le opzioni, che probabilmente è molto più utile. Se
 
 Questo è un trucco davvero utile e permette di risparmiare molto tempo e evitarti la lettura della documentazione.
 
-### Alias con Git ###
+### Alias di Git ###
 
-Git non deduce il comando se si digita solo in parte. Se non si vuole scrivere l'intero testo di qualsiasi comando Git, puoi facilmente scegliere un alias per ogni comando, usando `git config`. Qui ci sono un po' di esempi su alcune configurazioni che potresti volere impostare:
+Git non indovina il tuo comando se ne digiti solo una parte. Se non vuoi vuole scrivere tutto il testo di un qualsiasi comando Git puoi configurare facilmente un alias per ogni comando usando `git config`. Di seguito ci sono alcuni esempi che potresti voler usare:
 
 	$ git config --global alias.co checkout
 	$ git config --global alias.br branch
 	$ git config --global alias.ci commit
 	$ git config --global alias.st status
 
-Questo significa che, per esempio, invece di digitare `git commit`, hai solamente bisogno di scrivere `git ci`. Andando avanti con l'uso di Git, probabilmente ci saranno altri comandi che userai di frequente; in questi casi, non esitare a creare nuovi alias.
+Questo significa che, per esempio, invece di digitare `git commit`, dovrai scrivere solo `git ci`. Andando avanti con l'uso di Git userai alcuni comandi con maggiore frequenza: e in questi casi non esitare a creare nuovi alias.
 
-Questa tecnica può anche essere molto utile per creare comandi che ritieni dovrebbero esistere. Per esempio, per correggere un problema comune in cui si incorre quando si vuole disimpegnare un file dall'area di stage, puoi aggiungere il tuo alias unstage a Git:
+Questa tecnica può essere anche molto utile per creare comandi che ritieni dovrebbero esistere. Per esempio, per correggere un problema comune in cui si incorre quando si vuole rimuovere un file dall'area di stage, puoi aggiungere il tuo alias `unstage` in Git:
 
 	$ git config --global alias.unstage 'reset HEAD --'
 
-Questo rende i seguenti due comandi equivalenti:
+Questo rende equivalenti i due comandi seguenti:
 
 	$ git unstage fileA
 	$ git reset HEAD fileA
 
-Questo sembra più pulito. É anche comodo aggiungere il comando `last`, come:
+Questo sembra più pulito. É anche comodo aggiungere il comando `last`, così:
 
 	$ git config --global alias.last 'log -1 HEAD'
 
-In questo modo puoi vedere l'ultimo commit facilmente:
+In questo modo puoi vedere facilmente l'ultima commit:
 
 	$ git last
 	commit 66938dae3329c7aebe598c2246a8e6af90d04646
@@ -1168,10 +1168,10 @@ In questo modo puoi vedere l'ultimo commit facilmente:
 
 	    Signed-off-by: Scott Chacon <schacon@example.com>
 
-Git semplicemente sostituisce il nuovo comando con quello che corrisponde all'alias. Magari, vuoi avviare un comando esterno, invece dei sotto comandi Git. In questo caso, devi avviare il comando con il carattere "!". Questo è utile se stai scrivendo i tuoi strumenti di lavoro con un repository Git. Per esempio creiamo un alias `git visual` per lanciare `gitk`:
+Come immaginerai, Git semplicemente sostituisce il nuovo comando con qualsiasi cosa corrisponda all'alias. Potresti anche voler eseguire un comando esterno, piuttosto che uno di Git. In questo caso devi iniziare il comando con un "!". Questo è utile se stai scrivendo degli strumenti di lavoro tuoi per lavorare con un repository Git. Vediamolo praticamente creando l'alias `git visual` per eseguire `gitk`:
 
 	$ git config --global alias.visual '!gitk'
 
-## Riassunto ##
+## Sommario ##
 
-A questo punto, sei in grado di fare tutte le operazioni di Git base in locale — creare o clonare un repository, fare delle modifiche, parcheggiare ed inviare queste modifiche, vedere la storia di tutti i cambiamenti del repository fatti. Nel prossimo capitolo, vedremo una caratteristica vincente di Git: il suo modello di ramificazione.
+A questo punto, sei in grado di eseguire tutte le operazioni di base di Git in locale: creare o clonare un repository, fare delle modifiche, mettere nello `stage` e inviare queste modifiche, vedere la cronologia delle modifiche fatte al repository. Nel prossimo capitolo, vedremo la caratteristica vincente di Git: il suo modello di ramificazione.

From 5f7c67e119f3bcf0685dd85c737b905025bd2821 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Wed, 16 Apr 2014 15:09:24 +0200
Subject: [PATCH 332/690] [it] updating chapter6

Title was untraslated
---
 it/06-git-tools/01-chapter6.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/it/06-git-tools/01-chapter6.markdown b/it/06-git-tools/01-chapter6.markdown
index 5d950ab16..0363c27d7 100644
--- a/it/06-git-tools/01-chapter6.markdown
+++ b/it/06-git-tools/01-chapter6.markdown
@@ -1,4 +1,4 @@
-# Git Tools #
+# Strumenti di Git #
 
 Finora hai imparato la la maggior parte dei comandi d’uso quotidiani e i workflow che potrebbero essere necessari a gestire e mantenere un repository per il controllo del codice sorgente con Git. Hai eseguito le attività di base per il tracciamento e la commit dei file, e hai sfruttato il potere della *staging area* e il *branch* (la ramificazione) e il *merge* di argomenti dall’impatto leggero.
 

From 88833226fde95058e65ebe5e135c6d9ba1a0a588 Mon Sep 17 00:00:00 2001
From: Zack Yang <zackyang@outlook.com>
Date: Thu, 17 Apr 2014 14:37:49 +0800
Subject: [PATCH 333/690] Fixed typo.

---
 zh/05-distributed-git/01-chapter5.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/zh/05-distributed-git/01-chapter5.markdown b/zh/05-distributed-git/01-chapter5.markdown
index 34c49e34e..e3443221e 100644
--- a/zh/05-distributed-git/01-chapter5.markdown
+++ b/zh/05-distributed-git/01-chapter5.markdown
@@ -17,7 +17,7 @@ Insert 18333fig0501.png
 
 如果两个开发者从中心仓库克隆代码下来，同时作了一些修订，那么只有第一个开发者可以顺利地把数据推送到共享服务器。第二个开发者在提交他的修订之前，必须先下载合并服务器上的数据，解决冲突之后才能推送数据到共享服务器上。在 Git 中这么用也决无问题，这就好比是在用 Subversion（或其他 CVCS）一样，可以很好地工作。
 
-如果你的团队不是很大，或者大家都已经习惯了使用集中式工作流程，完全可以采用这种简单的模式。只需要配置好一台中心服务器，并给每个人推送数据的权限，就可以开展工作了。但如果提交代码时有冲突， Git 根本就不会让用户覆盖他人代码，它直接驳回第二个人的提交操作。这就等于告诉提交者，你所作的修订无法通过快近（fast-forward）来合并，你必须先拉取最新数据下来，手工解决冲突合并后，才能继续推送新的提交。
+如果你的团队不是很大，或者大家都已经习惯了使用集中式工作流程，完全可以采用这种简单的模式。只需要配置好一台中心服务器，并给每个人推送数据的权限，就可以开展工作了。但如果提交代码时有冲突， Git 根本就不会让用户覆盖他人代码，它直接驳回第二个人的提交操作。这就等于告诉提交者，你所作的修订无法通过快进（fast-forward）来合并，你必须先拉取最新数据下来，手工解决冲突合并后，才能继续推送新的提交。
 绝大多数人都熟悉和了解这种模式的工作方式，所以使用也非常广泛。
 
 ### 集成管理员工作流 ###

From ba8affc70c213056694798180f9baffcca18b03f Mon Sep 17 00:00:00 2001
From: Linquize <linquize@yahoo.com.hk>
Date: Fri, 18 Apr 2014 00:57:25 +0800
Subject: [PATCH 334/690] Deprecate google code downloads, point to sourceforge
 / github

---
 ar/01-introduction/01-chapter1.markdown       | 2 +-
 az/01-introduction/01-chapter1.markdown       | 4 ++--
 az/08-git-and-other-scms/01-chapter8.markdown | 2 +-
 be/01-introduction/01-chapter1.markdown       | 4 ++--
 ca/01-introduction/01-chapter1.markdown       | 4 ++--
 cs/01-introduction/01-chapter1.markdown       | 4 ++--
 de/01-introduction/01-chapter1.markdown       | 6 +++---
 en/01-introduction/01-chapter1.markdown       | 4 ++--
 eo/01-introduction/01-chapter1.markdown       | 4 ++--
 es-ni/01-introduction/01-chapter1.markdown    | 4 ++--
 es/01-introduction/01-chapter1.markdown       | 4 ++--
 fi/01-introduction/01-chapter1.markdown       | 2 +-
 fr/01-introduction/01-chapter1.markdown       | 4 ++--
 hu/01-introduction/01-chapter1.markdown       | 4 ++--
 id/01-introduction/01-chapter1.markdown       | 4 ++--
 it/01-introduction/01-chapter1.markdown       | 4 ++--
 ja/01-introduction/01-chapter1.markdown       | 4 ++--
 ko/01-introduction/01-chapter1.markdown       | 4 ++--
 mk/01-introduction/01-chapter1.markdown       | 4 ++--
 nl/01-introduction/01-chapter1.markdown       | 2 +-
 no-nb/01-introduction/01-chapter1.markdown    | 4 ++--
 pl/01-introduction/01-chapter1.markdown       | 4 ++--
 pt-br/01-introduction/01-chapter1.markdown    | 4 ++--
 ro/01-introduction/01-chapter1.markdown       | 4 ++--
 ru/01-introduction/01-chapter1.markdown       | 4 ++--
 sr/01-introduction/01-chapter1.markdown       | 4 ++--
 th/01-introduction/01-chapter1.markdown       | 4 ++--
 tr/01-introduction/01-chapter1.markdown       | 4 ++--
 vi/01-introduction/01-chapter1.markdown       | 4 ++--
 zh-tw/01-introduction/01-chapter1.markdown    | 6 +++---
 zh/01-introduction/01-chapter1.markdown       | 2 +-
 31 files changed, 59 insertions(+), 59 deletions(-)

diff --git a/ar/01-introduction/01-chapter1.markdown b/ar/01-introduction/01-chapter1.markdown
index c91e325ea..6ec46b534 100644
--- a/ar/01-introduction/01-chapter1.markdown
+++ b/ar/01-introduction/01-chapter1.markdown
@@ -168,7 +168,7 @@ If a particular version of a file is in the git directory, it’s considered com
 
 هناك طريقتين للتنصيب على  ماك أو اس، الأسهل هي استخدام الواجهة الرسومية للتنصيب، والتي يمكنك تحميلها من صفحة المشروع على غوغل كود (انظر الشكل 1-7):
 
-	http://code.google.com/p/git-osx-installer
+	http://sourceforge.net/projects/git-osx-installer/
 
 Insert 18333fig0107.png 
 الشكل 1-7. تنصيب Git على ماك أو اس.
diff --git a/az/01-introduction/01-chapter1.markdown b/az/01-introduction/01-chapter1.markdown
index e45515bdd..baa828d98 100644
--- a/az/01-introduction/01-chapter1.markdown
+++ b/az/01-introduction/01-chapter1.markdown
@@ -161,9 +161,9 @@ Or if you’re on a Debian-based distribution like Ubuntu, try apt-get:
 
 ### Installing on Mac ###
 
-There are two easy ways to install Git on a Mac. The easiest is to use the graphical Git installer, which you can download from the Google Code page (see Figure 1-7):
+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 SourceForge page (see Figure 1-7):
 
-	http://code.google.com/p/git-osx-installer
+	http://sourceforge.net/projects/git-osx-installer/
 
 Insert 18333fig0107.png 
 Figure 1-7. Git OS X installer.
diff --git a/az/08-git-and-other-scms/01-chapter8.markdown b/az/08-git-and-other-scms/01-chapter8.markdown
index 2465ffaa5..e21879ba3 100644
--- a/az/08-git-and-other-scms/01-chapter8.markdown
+++ b/az/08-git-and-other-scms/01-chapter8.markdown
@@ -20,7 +20,7 @@ Don’t rewrite your history and try to push again, and don’t push to a parall
 
 ### Setting Up ###
 
-To demonstrate this functionality, you need a typical SVN repository that you have write access to. If you want to copy these examples, you’ll have to make a writeable copy of my test repository. In order to do that easily, you can use a tool called `svnsync` that comes with more recent versions of Subversion — it should be distributed with at least 1.4. For these tests, I created a new Subversion repository on Google code that was a partial copy of the `protobuf` project, which is a tool that encodes structured data for network transmission. 
+To demonstrate this functionality, you need a typical SVN repository that you have write access to. If you want to copy these examples, you’ll have to make a writeable copy of my test repository. In order to do that easily, you can use a tool called `svnsync` that comes with more recent versions of Subversion — it should be distributed with at least 1.4. For these tests, I created a new Subversion repository on SourceForge that was a partial copy of the `protobuf` project, which is a tool that encodes structured data for network transmission. 
 
 To follow along, you first need to create a new local Subversion repository:
 
diff --git a/be/01-introduction/01-chapter1.markdown b/be/01-introduction/01-chapter1.markdown
index 93b2bc5ee..604f912e2 100644
--- a/be/01-introduction/01-chapter1.markdown
+++ b/be/01-introduction/01-chapter1.markdown
@@ -161,9 +161,9 @@ Insert 18333fig0106.png
 
 ### Усталёўка на Mac ###
 
-Ёсць два лёгкіх пуці ўсталёкі Git на Mac. Самы лёгкі - выкарыстаць графічны ўсталёўшчык, які вы можаце спампаваць са старонкі Google Code(гл. Малюнак 1-7):
+Ёсць два лёгкіх пуці ўсталёкі Git на Mac. Самы лёгкі - выкарыстаць графічны ўсталёўшчык, які вы можаце спампаваць са старонкі SourceForge(гл. Малюнак 1-7):
 
-	http://code.google.com/p/git-osx-installer
+	http://sourceforge.net/projects/git-osx-installer/
 
 Insert 18333fig0107.png 
 Малюнак 1-7. Усталёўчшык Git на OS X.
diff --git a/ca/01-introduction/01-chapter1.markdown b/ca/01-introduction/01-chapter1.markdown
index 726af3fb5..e245b9236 100644
--- a/ca/01-introduction/01-chapter1.markdown
+++ b/ca/01-introduction/01-chapter1.markdown
@@ -161,9 +161,9 @@ Or if you’re on a Debian-based distribution like Ubuntu, try apt-get:
 
 ### Installing on Mac ###
 
-There are two easy ways to install Git on a Mac. The easiest is to use the graphical Git installer, which you can download from the Google Code page (see Figure 1-7):
+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 SourceForge page (see Figure 1-7):
 
-	http://code.google.com/p/git-osx-installer
+	http://sourceforge.net/projects/git-osx-installer/
 
 Insert 18333fig0107.png 
 Figure 1-7. Git OS X installer.
diff --git a/cs/01-introduction/01-chapter1.markdown b/cs/01-introduction/01-chapter1.markdown
index 44fdd2521..50107a576 100644
--- a/cs/01-introduction/01-chapter1.markdown
+++ b/cs/01-introduction/01-chapter1.markdown
@@ -161,9 +161,9 @@ V distribuci založené na Debianu (např. Ubuntu) zkuste použít program apt-g
 
 ### Instalace v systému Mac ###
 
-Existují dva jednoduché způsoby, jak nainstalovat Git v systému Mac. Tím nejjednodušším je použít grafický instalátor Git, který si můžete stáhnout ze stránky Google Code (viz obrázek 1-7):
+Existují dva jednoduché způsoby, jak nainstalovat Git v systému Mac. Tím nejjednodušším je použít grafický instalátor Git, který si můžete stáhnout ze stránky SourceForge (viz obrázek 1-7):
 
-	http://code.google.com/p/git-osx-installer
+	http://sourceforge.net/projects/git-osx-installer/
 
 Insert 18333fig0107.png
 Obrázek 1-7. Instalátor Git pro OS X
diff --git a/de/01-introduction/01-chapter1.markdown b/de/01-introduction/01-chapter1.markdown
index a7d675858..ff5c6ef4c 100644
--- a/de/01-introduction/01-chapter1.markdown
+++ b/de/01-introduction/01-chapter1.markdown
@@ -281,11 +281,11 @@ Auf einem Debian-basierten System wie Ubuntu steht Dir apt-get zur Verfügung:
 <!--### Installing on Mac ###-->
 ### Installation unter Mac OS X ###
 
-<!--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):-->
+<!--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 SourceForge page (see Figure 1-7):-->
 
-Auf einem Mac kann man Git auf zwei Arten installieren. Der einfachste ist, das grafische Git Installationsprogramm zu verwenden, den man von der Google Code Webseite herunterladen kann (siehe Bild 1-7)
+Auf einem Mac kann man Git auf zwei Arten installieren. Der einfachste ist, das grafische Git Installationsprogramm zu verwenden, den man von der SourceForge Webseite herunterladen kann (siehe Bild 1-7)
 
-	http://code.google.com/p/git-osx-installer
+	http://sourceforge.net/projects/git-osx-installer/
 
 <!--Figure 1-7. Git OS X installer.-->
 
diff --git a/en/01-introduction/01-chapter1.markdown b/en/01-introduction/01-chapter1.markdown
index c7f12a2ed..e30752b7f 100644
--- a/en/01-introduction/01-chapter1.markdown
+++ b/en/01-introduction/01-chapter1.markdown
@@ -161,9 +161,9 @@ Or if you’re on a Debian-based distribution like Ubuntu, try apt-get:
 
 ### Installing on Mac ###
 
-There are two easy ways to install Git on a Mac. The easiest is to use the graphical Git installer, which you can download from the Google Code page (see Figure 1-7):
+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 SourceForge page (see Figure 1-7):
 
-	http://code.google.com/p/git-osx-installer
+	http://sourceforge.net/projects/git-osx-installer/
 
 Insert 18333fig0107.png
 Figure 1-7. Git OS X installer.
diff --git a/eo/01-introduction/01-chapter1.markdown b/eo/01-introduction/01-chapter1.markdown
index 9911a776b..d8c3313bc 100644
--- a/eo/01-introduction/01-chapter1.markdown
+++ b/eo/01-introduction/01-chapter1.markdown
@@ -161,9 +161,9 @@ Or if you’re on a Debian-based distribution like Ubuntu, try apt-get:
 
 ### Installing on Mac ###
 
-There are two easy ways to install Git on a Mac. The easiest is to use the graphical Git installer, which you can download from the Google Code page (see Figure 1-7):
+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 SourceForge page (see Figure 1-7):
 
-	http://code.google.com/p/git-osx-installer
+	http://sourceforge.net/projects/git-osx-installer/
 
 Insert 18333fig0107.png 
 Figure 1-7. Git OS X installer.
diff --git a/es-ni/01-introduction/01-chapter1.markdown b/es-ni/01-introduction/01-chapter1.markdown
index 36868fc48..7b8de3c69 100755
--- a/es-ni/01-introduction/01-chapter1.markdown
+++ b/es-ni/01-introduction/01-chapter1.markdown
@@ -161,9 +161,9 @@ Or if you’re on a Debian-based distribution like Ubuntu, try apt-get:
 
 ### Installing on Mac ###
 
-There are two easy ways to install Git on a Mac. The easiest is to use the graphical Git installer, which you can download from the Google Code page (see Figure 1-7):
+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 SourceForge page (see Figure 1-7):
 
-	http://code.google.com/p/git-osx-installer
+	http://sourceforge.net/projects/git-osx-installer/
 
 Insert 18333fig0107.png 
 Figure 1-7. Git OS X installer
diff --git a/es/01-introduction/01-chapter1.markdown b/es/01-introduction/01-chapter1.markdown
index 0321144ba..793f342e6 100644
--- a/es/01-introduction/01-chapter1.markdown
+++ b/es/01-introduction/01-chapter1.markdown
@@ -161,9 +161,9 @@ O si estás en una distribución basada en Debian como Ubuntu, prueba con apt-ge
 
 ### Instalando en Mac ###
 
-Hay dos maneras fáciles de instalar Git en un Mac. La más sencilla es usar el instalador gráfico de Git, que puedes descargar desde la página de Google Code (véase Figura 1-7):
+Hay dos maneras fáciles de instalar Git en un Mac. La más sencilla es usar el instalador gráfico de Git, que puedes descargar desde la página de SourceForge (véase Figura 1-7):
 
-	http://code.google.com/p/git-osx-installer
+	http://sourceforge.net/projects/git-osx-installer/
 
 Insert 18333fig0107.png
 Figura 1-7. Instalador de Git para OS X.
diff --git a/fi/01-introduction/01-chapter1.markdown b/fi/01-introduction/01-chapter1.markdown
index 8ca8f2b98..ead7c3bf8 100644
--- a/fi/01-introduction/01-chapter1.markdown
+++ b/fi/01-introduction/01-chapter1.markdown
@@ -163,7 +163,7 @@ Tai jos olet Debian-pohjaisessa julkaisussa kuten Ubuntussa, kokeile apt-getiä:
 
 On olemassa kaksi helppoa tapaa asentaa Git Macissä. Helpoin on käyttää graafista Git-asennusohjelmaa, jonka voit ladata Googlen Code -verkkosivuilta (katso Kuva 1-7):
 
-	http://code.google.com/p/git-osx-installer
+	http://sourceforge.net/projects/git-osx-installer/
 
 Insert 18333fig0107.png
 Kuva 1-7. Git OS X -asennusohjelma.
diff --git a/fr/01-introduction/01-chapter1.markdown b/fr/01-introduction/01-chapter1.markdown
index fbc0ef1ad..2fda80793 100644
--- a/fr/01-introduction/01-chapter1.markdown
+++ b/fr/01-introduction/01-chapter1.markdown
@@ -248,9 +248,9 @@ Si vous êtes sur un système basé sur Debian, tel qu'Ubuntu, essayez apt-get 
 ### Installation sur Mac ###
 
 Il y a deux moyens simples d'installer Git sur Mac.
-Le plus simple et d'utiliser l'installateur graphique de Git que vous pouvez télécharger depuis les pages Google Code (voir figure 1-7) :
+Le plus simple et d'utiliser l'installateur graphique de Git que vous pouvez télécharger depuis les pages SourceForge (voir figure 1-7) :
 
-	http://code.google.com/p/git-osx-installer
+	http://sourceforge.net/projects/git-osx-installer/
 
 Insert 18333fig0107.png
 Figure 1-7. Installateur OS X de Git.
diff --git a/hu/01-introduction/01-chapter1.markdown b/hu/01-introduction/01-chapter1.markdown
index c3cef723a..7f314fc2b 100644
--- a/hu/01-introduction/01-chapter1.markdown
+++ b/hu/01-introduction/01-chapter1.markdown
@@ -161,9 +161,9 @@ Or if you’re on a Debian-based distribution like Ubuntu, try apt-get:
 
 ### Installing on Mac ###
 
-There are two easy ways to install Git on a Mac. The easiest is to use the graphical Git installer, which you can download from the Google Code page (see Figure 1-7):
+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 SourceForge page (see Figure 1-7):
 
-	http://code.google.com/p/git-osx-installer
+	http://sourceforge.net/projects/git-osx-installer/
 
 Insert 18333fig0107.png 
 Figure 1-7. Git OS X installer.
diff --git a/id/01-introduction/01-chapter1.markdown b/id/01-introduction/01-chapter1.markdown
index af9b8cfc3..8fe56b1e6 100644
--- a/id/01-introduction/01-chapter1.markdown
+++ b/id/01-introduction/01-chapter1.markdown
@@ -161,9 +161,9 @@ Atau jika anda menggunakan distro berbasis Debian seperti Ubuntu, coba gunakan a
 
 ### Menginstall Git pada Mac ###
 
-Terdapat dua cara mudah untuk menginstal Git pada sebuah komputer Mac. Cara termudah adalah menggunakan installer Git berbasis GUI, yang dapat anda peroleh dari halaman Google Code (lihat Gambar 1-7):
+Terdapat dua cara mudah untuk menginstal Git pada sebuah komputer Mac. Cara termudah adalah menggunakan installer Git berbasis GUI, yang dapat anda peroleh dari halaman SourceForge (lihat Gambar 1-7):
 
-	http://code.google.com/p/git-osx-installer
+	http://sourceforge.net/projects/git-osx-installer/
 
 Insert 18333fig0107.png 
 Gambar 1-7. Git OS X installer.
diff --git a/it/01-introduction/01-chapter1.markdown b/it/01-introduction/01-chapter1.markdown
index 2806f937b..4b5701a8a 100644
--- a/it/01-introduction/01-chapter1.markdown
+++ b/it/01-introduction/01-chapter1.markdown
@@ -161,9 +161,9 @@ O se sei su una distribuzione basata su Debian, come Ubuntu, prova apt-get:
 
 ### Installazione su Mac ###
 
-Ci sono due metodi per installare Git su Mac. Il più semplice è usare l'installer grafico di Git, che puoi scaricare dalla pagina di Google Code (vedi Figura 1-7):
+Ci sono due metodi per installare Git su Mac. Il più semplice è usare l'installer grafico di Git, che puoi scaricare dalla pagina di SourceForge (vedi Figura 1-7):
 
-	http://code.google.com/p/git-osx-installer
+	http://sourceforge.net/projects/git-osx-installer/
 
 Insert 18333fig0107.png 
 Figura 1-7. Installer di Git per OS X.
diff --git a/ja/01-introduction/01-chapter1.markdown b/ja/01-introduction/01-chapter1.markdown
index 9346f4055..039eb307e 100644
--- a/ja/01-introduction/01-chapter1.markdown
+++ b/ja/01-introduction/01-chapter1.markdown
@@ -163,9 +163,9 @@ Gitをインストールするためには、Gitが依存するライブラリ
 
 ### Macにインストール ###
 
-MacにGitをインストールするには2つの簡単な方法があります。もっとも簡単な方法は、グラフィカルなGitインストーラーを使うことで、このGitインストーラーはGoogle Codeのページ（図1-7参照）からダウンロードすることができます：
+MacにGitをインストールするには2つの簡単な方法があります。もっとも簡単な方法は、グラフィカルなGitインストーラーを使うことで、このGitインストーラーはSourceForgeのページ（図1-7参照）からダウンロードすることができます：
 
-	http://code.google.com/p/git-osx-installer
+	http://sourceforge.net/projects/git-osx-installer/
 
 Insert 18333fig0107.png
 図 1-7. Git OS X installer
diff --git a/ko/01-introduction/01-chapter1.markdown b/ko/01-introduction/01-chapter1.markdown
index a7a24715b..8a015f6ca 100644
--- a/ko/01-introduction/01-chapter1.markdown
+++ b/ko/01-introduction/01-chapter1.markdown
@@ -161,9 +161,9 @@ Ubuntu같은 데비안류 배포판에서는 apt-get을 사용한다:
 
 ### Mac에 설치하기 ###
 
-Mac에 Git을 쉽게 설치하는 방법은 두 가지가 있다. GUI 인스톨러가 가장 쉽게 사용할 수 있다. Google Code 페이지에서 내려받는다:
+Mac에 Git을 쉽게 설치하는 방법은 두 가지가 있다. GUI 인스톨러가 가장 쉽게 사용할 수 있다. SourceForge 페이지에서 내려받는다:
 
-	http://code.google.com/p/git-osx-installer
+	http://sourceforge.net/projects/git-osx-installer/
 
 Insert 18333fig0107.png 
 그림 1-7. OS X Git 인스톨러
diff --git a/mk/01-introduction/01-chapter1.markdown b/mk/01-introduction/01-chapter1.markdown
index 73c0f079e..b310b78b1 100644
--- a/mk/01-introduction/01-chapter1.markdown
+++ b/mk/01-introduction/01-chapter1.markdown
@@ -161,9 +161,9 @@ Git папката е местото каде што Git ги складира 
 
 ### Инсталирање на Мекинтош ###
 
-Постојат два лесни начини како да го инсталирате Git на Мекинтош. Најлесниот е да го користите графичкиот Git инсталатор, кој што може да го симнете до Google Code страната (види слика 1-7):
+Постојат два лесни начини како да го инсталирате Git на Мекинтош. Најлесниот е да го користите графичкиот Git инсталатор, кој што може да го симнете до SourceForge страната (види слика 1-7):
 
-	http://code.google.com/p/git-osx-installer
+	http://sourceforge.net/projects/git-osx-installer/
 
 Insert 18333fig0107.png 
 Слика 1-7. Git OS X инсталатор.
diff --git a/nl/01-introduction/01-chapter1.markdown b/nl/01-introduction/01-chapter1.markdown
index 335bdd45e..4907ff94c 100644
--- a/nl/01-introduction/01-chapter1.markdown
+++ b/nl/01-introduction/01-chapter1.markdown
@@ -199,7 +199,7 @@ Of als je een distributie hebt die op Debian gebaseerd is, zoals Ubuntu, kun je
 
 Er zijn twee makkelijke manieren om Git op een Mac te installeren. De simpelste is om het grafische Git installatieprogramma te gebruiken, dat je van de volgende pagina op Google Code kunt downloaden (zie Figuur 1-7):
 
-	http://code.google.com/p/git-osx-installer
+	http://sourceforge.net/projects/git-osx-installer/
 
 Insert 18333fig0107.png
 Figuur 1-7. Gitinstallatieprogramma voor OS X.
diff --git a/no-nb/01-introduction/01-chapter1.markdown b/no-nb/01-introduction/01-chapter1.markdown
index 6254fca01..6957dc82f 100644
--- a/no-nb/01-introduction/01-chapter1.markdown
+++ b/no-nb/01-introduction/01-chapter1.markdown
@@ -161,9 +161,9 @@ Or if you’re on a Debian-based distribution like Ubuntu, try apt-get:
 
 ### Installing on Mac ###
 
-There are two easy ways to install Git on a Mac. The easiest is to use the graphical Git installer, which you can download from the Google Code page (see Figure 1-7):
+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 SourceForge page (see Figure 1-7):
 
-	http://code.google.com/p/git-osx-installer
+	http://sourceforge.net/projects/git-osx-installer/
 
 Insert 18333fig0107.png
 Figure 1-7. Git OS X installer.
diff --git a/pl/01-introduction/01-chapter1.markdown b/pl/01-introduction/01-chapter1.markdown
index 58058c78e..5ef367d64 100644
--- a/pl/01-introduction/01-chapter1.markdown
+++ b/pl/01-introduction/01-chapter1.markdown
@@ -161,9 +161,9 @@ Jeśli korzystasz z dystrybucji opartej na Debianie (np. Ubuntu), użyj apt-get:
 
 ### Instalacja na komputerze Mac ###
 
-Istnieją dwa proste sposoby instalacji Git na komputerze Mac. Najprostszym z nich jest użycie graficznego instalatora, którego można pobrać z witryny Google Code (patrz Ekran 1-7):
+Istnieją dwa proste sposoby instalacji Git na komputerze Mac. Najprostszym z nich jest użycie graficznego instalatora, którego można pobrać z witryny SourceForge (patrz Ekran 1-7):
 
-	http://code.google.com/p/git-osx-installer
+	http://sourceforge.net/projects/git-osx-installer/
 
 Insert 18333fig0107.png 
 Figure 1-7. Instalator Git dla OS X.
diff --git a/pt-br/01-introduction/01-chapter1.markdown b/pt-br/01-introduction/01-chapter1.markdown
index 7d3a98c53..3d0937919 100644
--- a/pt-br/01-introduction/01-chapter1.markdown
+++ b/pt-br/01-introduction/01-chapter1.markdown
@@ -161,9 +161,9 @@ Ou se você estiver em uma distribuição baseada no Debian, como o Ubuntu, use
 
 ### Instalando no Mac ###
 
-Existem duas formas fáceis de se instalar Git em um Mac. A mais fácil delas é usar o instalador gráfico do Git, que você pode baixar da página do Google Code (veja Figura 1-7):
+Existem duas formas fáceis de se instalar Git em um Mac. A mais fácil delas é usar o instalador gráfico do Git, que você pode baixar da página do SourceForge (veja Figura 1-7):
 
-    http://code.google.com/p/git-osx-installer
+    http://sourceforge.net/projects/git-osx-installer/
 
 Insert 18333fig0107.png
 Figura 1-7. Instalador Git OS X.
diff --git a/ro/01-introduction/01-chapter1.markdown b/ro/01-introduction/01-chapter1.markdown
index c8d6c7054..46b3e00fc 100644
--- a/ro/01-introduction/01-chapter1.markdown
+++ b/ro/01-introduction/01-chapter1.markdown
@@ -161,9 +161,9 @@ Sau dacă folosiți o distribuție bazată pe Debian, de exemplu Ubuntu, încerc
 
 ### Instalarea pe sistemele Mac ###
 
-Sunt două moduri simple de a instala Git pe sistemele Mac. Cea mai simplă este să folosiți programul de instalare grafic pentru Git, pe care îl puteți descărca de la pagina Google Code ( vedeți Figura 1-7):
+Sunt două moduri simple de a instala Git pe sistemele Mac. Cea mai simplă este să folosiți programul de instalare grafic pentru Git, pe care îl puteți descărca de la pagina SourceForge ( vedeți Figura 1-7):
 
-	http://code.google.com/p/git-osx-installer
+	http://sourceforge.net/projects/git-osx-installer/
 
 Insert 18333fig0107.png 
 Figura 1-7. Programul de instalare Git în OS X.
diff --git a/ru/01-introduction/01-chapter1.markdown b/ru/01-introduction/01-chapter1.markdown
index 864a00e05..2212d4888 100644
--- a/ru/01-introduction/01-chapter1.markdown
+++ b/ru/01-introduction/01-chapter1.markdown
@@ -161,9 +161,9 @@ Insert 18333fig0106.png
 
 ### Установка на Mac ###
 
-Есть два простых способа установить Git на Mac. Самый простой — использовать графический инсталлятор Git'а, который вы можете скачать со страницы на Google Code (см. рисунок 1-7):
+Есть два простых способа установить Git на Mac. Самый простой — использовать графический инсталлятор Git'а, который вы можете скачать со страницы на SourceForge (см. рисунок 1-7):
 
-	http://code.google.com/p/git-osx-installer
+	http://sourceforge.net/projects/git-osx-installer/
 
 Insert 18333fig0107.png
 Рисунок 1-7. Инсталлятор Git'а под OS X.
diff --git a/sr/01-introduction/01-chapter1.markdown b/sr/01-introduction/01-chapter1.markdown
index 1cf422998..0603869b1 100644
--- a/sr/01-introduction/01-chapter1.markdown
+++ b/sr/01-introduction/01-chapter1.markdown
@@ -161,9 +161,9 @@ Or if you’re on a Debian-based distribution like Ubuntu, try apt-get:
 
 ### Installing on Mac ###
 
-There are two easy ways to install Git on a Mac. The easiest is to use the graphical Git installer, which you can download from the Google Code page (see Figure 1-7):
+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 SourceForge page (see Figure 1-7):
 
-	http://code.google.com/p/git-osx-installer
+	http://sourceforge.net/projects/git-osx-installer/
 
 Insert 18333fig0107.png 
 Figure 1-7. Git OS X installer
diff --git a/th/01-introduction/01-chapter1.markdown b/th/01-introduction/01-chapter1.markdown
index 945fbe006..50cf03606 100644
--- a/th/01-introduction/01-chapter1.markdown
+++ b/th/01-introduction/01-chapter1.markdown
@@ -161,9 +161,9 @@ staging area เป็นไฟล์ธรรมดาไฟล์นึง โ
 
 ### การติดตั้งบนแมค ###
 
-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):
+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 SourceForge page (see Figure 1-7):
 
-	http://code.google.com/p/git-osx-installer
+	http://sourceforge.net/projects/git-osx-installer/
 
 Insert 18333fig0107.png 
 Figure 1-7. Git OS X installer.
diff --git a/tr/01-introduction/01-chapter1.markdown b/tr/01-introduction/01-chapter1.markdown
index c0ae4c269..e7f87df22 100644
--- a/tr/01-introduction/01-chapter1.markdown
+++ b/tr/01-introduction/01-chapter1.markdown
@@ -163,9 +163,9 @@ Ubuntu gibi Debian-tabanlı bir sistemdeyseniz, apt-get'i kullanabilirsiniz:
 
 ### Mac'te Kurulum ###
 
-Git'i Mac'te kurmak için iki kolay yol vardır. En kolayı, Google Code sayfasından indirebileceğiniz görsel Git yükleyicisini kullanmaktır (bkz. Figür 1-7).
+Git'i Mac'te kurmak için iki kolay yol vardır. En kolayı, SourceForge sayfasından indirebileceğiniz görsel Git yükleyicisini kullanmaktır (bkz. Figür 1-7).
 
-	http://code.google.com/p/git-osx-installer
+	http://sourceforge.net/projects/git-osx-installer/
 
 Insert 18333fig0107.png 
 Figür 1-7. Git OS X yükleyicisi.
diff --git a/vi/01-introduction/01-chapter1.markdown b/vi/01-introduction/01-chapter1.markdown
index 43e416fbf..81fbbb597 100644
--- a/vi/01-introduction/01-chapter1.markdown
+++ b/vi/01-introduction/01-chapter1.markdown
@@ -161,9 +161,9 @@ Còn nếu bạn đang sử dụng một hệ điều hành dựa trên nhân De
 
 ### Cài Đặt Trên Mac ###
 
-Có hai cách đơn giản để cài đặt Git trên Mac. Cách đơn giản nhất là sử dụng chương trình cài đặt có hỗ trợ giao diện, bạn có thể tải về từ trang web của Google Code (xem Hình 1-7):
+Có hai cách đơn giản để cài đặt Git trên Mac. Cách đơn giản nhất là sử dụng chương trình cài đặt có hỗ trợ giao diện, bạn có thể tải về từ trang web của SourceForge (xem Hình 1-7):
 
-	http://code.google.com/p/git-osx-installer
+	http://sourceforge.net/projects/git-osx-installer/
 
 Insert 18333fig0107.png
 Hình 1-7. Chương trình cài đặt Git cho Mac OS X.
diff --git a/zh-tw/01-introduction/01-chapter1.markdown b/zh-tw/01-introduction/01-chapter1.markdown
index 2c581fec5..d594820ea 100644
--- a/zh-tw/01-introduction/01-chapter1.markdown
+++ b/zh-tw/01-introduction/01-chapter1.markdown
@@ -161,9 +161,9 @@ Git目錄是Git用來儲存讀者的專案的元數據及物件資料庫。 這
 
 ### 在Mac系統安裝 ###
 
-有兩種很容易將Git安裝到Mac的方法。 最簡單的是使用圖形化界面的Git安裝程式，可從Google Code下載）圖1－7）：
+有兩種很容易將Git安裝到Mac的方法。 最簡單的是使用圖形化界面的Git安裝程式，可從SourceForge下載）圖1－7）：
 
-	http://code.google.com/p/git-osx-installer
+	http://sourceforge.net/projects/git-osx-installer/
 
 Insert 18333fig0107.png
 圖1-7. Git OS X 安裝程式。
@@ -176,7 +176,7 @@ Insert 18333fig0107.png
 
 ### 在Windows系統安裝 ###
 
-在Windows系統安裝Git相當地容易。 msysGit專案已提供相當容易安裝的程序。 只要從Google Code網頁下載安裝程式並執行即可：
+在Windows系統安裝Git相當地容易。 msysGit專案已提供相當容易安裝的程序。 只要從GitHub網頁下載安裝程式並執行即可：
 
 	http://msysgit.github.com/
 
diff --git a/zh/01-introduction/01-chapter1.markdown b/zh/01-introduction/01-chapter1.markdown
index fb33d4518..cfac13adf 100644
--- a/zh/01-introduction/01-chapter1.markdown
+++ b/zh/01-introduction/01-chapter1.markdown
@@ -163,7 +163,7 @@ Git 的工作需要调用 curl，zlib，openssl，expat，libiconv 等库的代
 
 在 Mac 上安装 Git 有两种方式。最容易的当属使用图形化的 Git 安装工具，界面如图 1-7，下载地址在：
 
-	http://code.google.com/p/git-osx-installer
+	http://sourceforge.net/projects/git-osx-installer/
 
 Insert 18333fig0107.png
 图 1-7. Git OS X 安装工具

From 7c94839bb46a44931447878a731d57db77fb1a37 Mon Sep 17 00:00:00 2001
From: Zack Yang <zackyang@outlook.com>
Date: Fri, 18 Apr 2014 11:03:20 +0800
Subject: [PATCH 335/690] Translate lost of paragraphs.

---
 zh/05-distributed-git/01-chapter5.markdown | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/zh/05-distributed-git/01-chapter5.markdown b/zh/05-distributed-git/01-chapter5.markdown
index 34c49e34e..4100f63bc 100644
--- a/zh/05-distributed-git/01-chapter5.markdown
+++ b/zh/05-distributed-git/01-chapter5.markdown
@@ -539,9 +539,9 @@ Insert 18333fig0518.png
 	sending 2 messages
 	100% (2/2) done
 
-At this point, you should be able to go to your Drafts folder, change the To field to the mailing list you’re sending the patch to, possibly CC the maintainer or person responsible for that section, and send it off.
+然后，你应该去你到草稿箱去更改你要发送的补丁的收件人信息，以及需要抄送的人，然后发送它。
 
-You can also send the patches through an SMTP server. As before, you can set each value separately with a series of `git config` commands, or you can add them manually in the sendemail section in your `~/.gitconfig` file:
+您也可以通过SMTP服务器发送补丁。和上面一样，你可以通过`git config`命令单独设置每个参数，也可以在你的`~/.gitconfig`文件中的sendemail节点手动添加它们。
 
 	[sendemail]
 	  smtpencryption = tls
@@ -549,7 +549,7 @@ You can also send the patches through an SMTP server. As before, you can set eac
 	  smtpuser = user@gmail.com
 	  smtpserverport = 587
 
-After this is done, you can use `git send-email` to send your patches:
+配置完成后，您可以使用`git send-email`来发送你的补丁：
 
 	$ git send-email *.patch
 	0001-added-limit-to-log-function.patch

From 60e261895a77951a6541470c9438f32a1e5b7fd0 Mon Sep 17 00:00:00 2001
From: Ilya Kuznetsov <i.kuznetsov@xored.com>
Date: Sat, 19 Apr 2014 15:10:22 +0700
Subject: [PATCH 336/690] As of current Git version, --all-match matches greps

---
 en/02-git-basics/01-chapter2.markdown | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/en/02-git-basics/01-chapter2.markdown b/en/02-git-basics/01-chapter2.markdown
index 5a85343ce..8090ba342 100644
--- a/en/02-git-basics/01-chapter2.markdown
+++ b/en/02-git-basics/01-chapter2.markdown
@@ -637,7 +637,9 @@ However, the time-limiting options such as `--since` and `--until` are very usef
 
 This command works with lots of formats — you can specify a specific date (“2008-01-15”) or a relative date such as “2 years 1 day 3 minutes ago”.
 
-You can also filter the list to commits that match some search criteria. The `--author` option allows you to filter on a specific author, and the `--grep` option lets you search for keywords in the commit messages. (Note that if you want to specify both author and grep options, you have to add `--all-match` or the command will match commits with either.)
+You can also filter the list to commits that match some search criteria. The `--author` option allows you to filter on a specific author, and the `--grep` option lets you search for keywords in the commit messages. (Note that if you specify both author and grep options, the command will match commits with both.)
+
+If you want to specify multiple grep options, you have to add `--all-match` or the command will match commits with either.
 
 The last really useful option to pass to `git log` as a filter is a path. If you specify a directory or file name, you can limit the log output to commits that introduced a change to those files. This is always the last option and is generally preceded by double dashes (`--`) to separate the paths from the options.
 

From 17c28fd78d43bfe360bde1f82022995272d8fea0 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Sun, 20 Apr 2014 19:59:47 +0200
Subject: [PATCH 337/690] [it] update chapter2

Translate commit 60e2618
---
 it/02-git-basics/01-chapter2.markdown | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/it/02-git-basics/01-chapter2.markdown b/it/02-git-basics/01-chapter2.markdown
index 36559d422..e4de7ab6a 100644
--- a/it/02-git-basics/01-chapter2.markdown
+++ b/it/02-git-basics/01-chapter2.markdown
@@ -637,7 +637,9 @@ Le opzioni temporali come `--since` e `--until` sono invece molto utili. Questo
 
 Questo comando funziona con molti formati —  puoi specificare una data (“2008-01-15”) o una data relativa come “2 years 1 day 3 minutes ago”.
 
-Puoi inoltre filtrare l'elenco delle commit che corrispondono a dei criteri di ricerca. L'opzione `--author` ti permette di filtrare per uno specifico autore e l'opzione `--grep` ti permette di cercare delle parole chiave nei messaggi delle commit. (Nota che se vuoi specificare entremba le opzioni devi usare `--all-match` o il comando ricercherà le commit che corrispondano ad almeno una delle due.)
+Puoi inoltre filtrare l'elenco delle commit che corrispondono a dei criteri di ricerca. L'opzione `--author` ti permette di filtrare per uno specifico autore e l'opzione `--grep` ti permette di cercare delle parole chiave nei messaggi delle commit. (Nota che specifichi entrambe le opzioni il comando cercherà le commit che corrispondano a tutte le opzioni specificate.)
+
+Se vuoi specificare più opzioni `--grep` alternative devi usare `--all-match`.
 
 L'ultima opzione di `git log` per il filtraggio è il percorso. Se specifichi il nome di una directory o di un file, puoi limitare l'output del log alle sole commit che introducono modifiche a quei file. Questa è sempre l'ultima opzione specificata e generalmente è preceduta dal doppio meno (`--`) per separare i percorsi dalle opzioni.
 

From 055569026dd6c3b3ee7cf4f83fc40ffc28e7999b Mon Sep 17 00:00:00 2001
From: Linquize <linquize@yahoo.com.hk>
Date: Fri, 18 Apr 2014 00:57:25 +0800
Subject: [PATCH 338/690] Deprecate google code downloads, point to sourceforge
 / github

---
 ar/01-introduction/01-chapter1.markdown       | 2 +-
 az/01-introduction/01-chapter1.markdown       | 4 ++--
 az/08-git-and-other-scms/01-chapter8.markdown | 2 +-
 be/01-introduction/01-chapter1.markdown       | 4 ++--
 ca/01-introduction/01-chapter1.markdown       | 4 ++--
 cs/01-introduction/01-chapter1.markdown       | 4 ++--
 de/01-introduction/01-chapter1.markdown       | 6 +++---
 en/01-introduction/01-chapter1.markdown       | 4 ++--
 eo/01-introduction/01-chapter1.markdown       | 4 ++--
 es-ni/01-introduction/01-chapter1.markdown    | 4 ++--
 es/01-introduction/01-chapter1.markdown       | 4 ++--
 fi/01-introduction/01-chapter1.markdown       | 2 +-
 fr/01-introduction/01-chapter1.markdown       | 4 ++--
 hu/01-introduction/01-chapter1.markdown       | 4 ++--
 id/01-introduction/01-chapter1.markdown       | 4 ++--
 it/01-introduction/01-chapter1.markdown       | 4 ++--
 ja/01-introduction/01-chapter1.markdown       | 4 ++--
 ko/01-introduction/01-chapter1.markdown       | 4 ++--
 mk/01-introduction/01-chapter1.markdown       | 4 ++--
 nl/01-introduction/01-chapter1.markdown       | 2 +-
 no-nb/01-introduction/01-chapter1.markdown    | 4 ++--
 pl/01-introduction/01-chapter1.markdown       | 4 ++--
 pt-br/01-introduction/01-chapter1.markdown    | 4 ++--
 ro/01-introduction/01-chapter1.markdown       | 4 ++--
 ru/01-introduction/01-chapter1.markdown       | 4 ++--
 sr/01-introduction/01-chapter1.markdown       | 4 ++--
 th/01-introduction/01-chapter1.markdown       | 4 ++--
 tr/01-introduction/01-chapter1.markdown       | 4 ++--
 vi/01-introduction/01-chapter1.markdown       | 4 ++--
 zh-tw/01-introduction/01-chapter1.markdown    | 6 +++---
 zh/01-introduction/01-chapter1.markdown       | 2 +-
 31 files changed, 59 insertions(+), 59 deletions(-)

diff --git a/ar/01-introduction/01-chapter1.markdown b/ar/01-introduction/01-chapter1.markdown
index c91e325ea..6ec46b534 100644
--- a/ar/01-introduction/01-chapter1.markdown
+++ b/ar/01-introduction/01-chapter1.markdown
@@ -168,7 +168,7 @@ If a particular version of a file is in the git directory, it’s considered com
 
 هناك طريقتين للتنصيب على  ماك أو اس، الأسهل هي استخدام الواجهة الرسومية للتنصيب، والتي يمكنك تحميلها من صفحة المشروع على غوغل كود (انظر الشكل 1-7):
 
-	http://code.google.com/p/git-osx-installer
+	http://sourceforge.net/projects/git-osx-installer/
 
 Insert 18333fig0107.png 
 الشكل 1-7. تنصيب Git على ماك أو اس.
diff --git a/az/01-introduction/01-chapter1.markdown b/az/01-introduction/01-chapter1.markdown
index e45515bdd..baa828d98 100644
--- a/az/01-introduction/01-chapter1.markdown
+++ b/az/01-introduction/01-chapter1.markdown
@@ -161,9 +161,9 @@ Or if you’re on a Debian-based distribution like Ubuntu, try apt-get:
 
 ### Installing on Mac ###
 
-There are two easy ways to install Git on a Mac. The easiest is to use the graphical Git installer, which you can download from the Google Code page (see Figure 1-7):
+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 SourceForge page (see Figure 1-7):
 
-	http://code.google.com/p/git-osx-installer
+	http://sourceforge.net/projects/git-osx-installer/
 
 Insert 18333fig0107.png 
 Figure 1-7. Git OS X installer.
diff --git a/az/08-git-and-other-scms/01-chapter8.markdown b/az/08-git-and-other-scms/01-chapter8.markdown
index 2465ffaa5..e21879ba3 100644
--- a/az/08-git-and-other-scms/01-chapter8.markdown
+++ b/az/08-git-and-other-scms/01-chapter8.markdown
@@ -20,7 +20,7 @@ Don’t rewrite your history and try to push again, and don’t push to a parall
 
 ### Setting Up ###
 
-To demonstrate this functionality, you need a typical SVN repository that you have write access to. If you want to copy these examples, you’ll have to make a writeable copy of my test repository. In order to do that easily, you can use a tool called `svnsync` that comes with more recent versions of Subversion — it should be distributed with at least 1.4. For these tests, I created a new Subversion repository on Google code that was a partial copy of the `protobuf` project, which is a tool that encodes structured data for network transmission. 
+To demonstrate this functionality, you need a typical SVN repository that you have write access to. If you want to copy these examples, you’ll have to make a writeable copy of my test repository. In order to do that easily, you can use a tool called `svnsync` that comes with more recent versions of Subversion — it should be distributed with at least 1.4. For these tests, I created a new Subversion repository on SourceForge that was a partial copy of the `protobuf` project, which is a tool that encodes structured data for network transmission. 
 
 To follow along, you first need to create a new local Subversion repository:
 
diff --git a/be/01-introduction/01-chapter1.markdown b/be/01-introduction/01-chapter1.markdown
index 93b2bc5ee..604f912e2 100644
--- a/be/01-introduction/01-chapter1.markdown
+++ b/be/01-introduction/01-chapter1.markdown
@@ -161,9 +161,9 @@ Insert 18333fig0106.png
 
 ### Усталёўка на Mac ###
 
-Ёсць два лёгкіх пуці ўсталёкі Git на Mac. Самы лёгкі - выкарыстаць графічны ўсталёўшчык, які вы можаце спампаваць са старонкі Google Code(гл. Малюнак 1-7):
+Ёсць два лёгкіх пуці ўсталёкі Git на Mac. Самы лёгкі - выкарыстаць графічны ўсталёўшчык, які вы можаце спампаваць са старонкі SourceForge(гл. Малюнак 1-7):
 
-	http://code.google.com/p/git-osx-installer
+	http://sourceforge.net/projects/git-osx-installer/
 
 Insert 18333fig0107.png 
 Малюнак 1-7. Усталёўчшык Git на OS X.
diff --git a/ca/01-introduction/01-chapter1.markdown b/ca/01-introduction/01-chapter1.markdown
index 726af3fb5..e245b9236 100644
--- a/ca/01-introduction/01-chapter1.markdown
+++ b/ca/01-introduction/01-chapter1.markdown
@@ -161,9 +161,9 @@ Or if you’re on a Debian-based distribution like Ubuntu, try apt-get:
 
 ### Installing on Mac ###
 
-There are two easy ways to install Git on a Mac. The easiest is to use the graphical Git installer, which you can download from the Google Code page (see Figure 1-7):
+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 SourceForge page (see Figure 1-7):
 
-	http://code.google.com/p/git-osx-installer
+	http://sourceforge.net/projects/git-osx-installer/
 
 Insert 18333fig0107.png 
 Figure 1-7. Git OS X installer.
diff --git a/cs/01-introduction/01-chapter1.markdown b/cs/01-introduction/01-chapter1.markdown
index 44fdd2521..50107a576 100644
--- a/cs/01-introduction/01-chapter1.markdown
+++ b/cs/01-introduction/01-chapter1.markdown
@@ -161,9 +161,9 @@ V distribuci založené na Debianu (např. Ubuntu) zkuste použít program apt-g
 
 ### Instalace v systému Mac ###
 
-Existují dva jednoduché způsoby, jak nainstalovat Git v systému Mac. Tím nejjednodušším je použít grafický instalátor Git, který si můžete stáhnout ze stránky Google Code (viz obrázek 1-7):
+Existují dva jednoduché způsoby, jak nainstalovat Git v systému Mac. Tím nejjednodušším je použít grafický instalátor Git, který si můžete stáhnout ze stránky SourceForge (viz obrázek 1-7):
 
-	http://code.google.com/p/git-osx-installer
+	http://sourceforge.net/projects/git-osx-installer/
 
 Insert 18333fig0107.png
 Obrázek 1-7. Instalátor Git pro OS X
diff --git a/de/01-introduction/01-chapter1.markdown b/de/01-introduction/01-chapter1.markdown
index a7d675858..ff5c6ef4c 100644
--- a/de/01-introduction/01-chapter1.markdown
+++ b/de/01-introduction/01-chapter1.markdown
@@ -281,11 +281,11 @@ Auf einem Debian-basierten System wie Ubuntu steht Dir apt-get zur Verfügung:
 <!--### Installing on Mac ###-->
 ### Installation unter Mac OS X ###
 
-<!--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):-->
+<!--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 SourceForge page (see Figure 1-7):-->
 
-Auf einem Mac kann man Git auf zwei Arten installieren. Der einfachste ist, das grafische Git Installationsprogramm zu verwenden, den man von der Google Code Webseite herunterladen kann (siehe Bild 1-7)
+Auf einem Mac kann man Git auf zwei Arten installieren. Der einfachste ist, das grafische Git Installationsprogramm zu verwenden, den man von der SourceForge Webseite herunterladen kann (siehe Bild 1-7)
 
-	http://code.google.com/p/git-osx-installer
+	http://sourceforge.net/projects/git-osx-installer/
 
 <!--Figure 1-7. Git OS X installer.-->
 
diff --git a/en/01-introduction/01-chapter1.markdown b/en/01-introduction/01-chapter1.markdown
index c7f12a2ed..e30752b7f 100644
--- a/en/01-introduction/01-chapter1.markdown
+++ b/en/01-introduction/01-chapter1.markdown
@@ -161,9 +161,9 @@ Or if you’re on a Debian-based distribution like Ubuntu, try apt-get:
 
 ### Installing on Mac ###
 
-There are two easy ways to install Git on a Mac. The easiest is to use the graphical Git installer, which you can download from the Google Code page (see Figure 1-7):
+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 SourceForge page (see Figure 1-7):
 
-	http://code.google.com/p/git-osx-installer
+	http://sourceforge.net/projects/git-osx-installer/
 
 Insert 18333fig0107.png
 Figure 1-7. Git OS X installer.
diff --git a/eo/01-introduction/01-chapter1.markdown b/eo/01-introduction/01-chapter1.markdown
index 9911a776b..d8c3313bc 100644
--- a/eo/01-introduction/01-chapter1.markdown
+++ b/eo/01-introduction/01-chapter1.markdown
@@ -161,9 +161,9 @@ Or if you’re on a Debian-based distribution like Ubuntu, try apt-get:
 
 ### Installing on Mac ###
 
-There are two easy ways to install Git on a Mac. The easiest is to use the graphical Git installer, which you can download from the Google Code page (see Figure 1-7):
+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 SourceForge page (see Figure 1-7):
 
-	http://code.google.com/p/git-osx-installer
+	http://sourceforge.net/projects/git-osx-installer/
 
 Insert 18333fig0107.png 
 Figure 1-7. Git OS X installer.
diff --git a/es-ni/01-introduction/01-chapter1.markdown b/es-ni/01-introduction/01-chapter1.markdown
index 36868fc48..7b8de3c69 100755
--- a/es-ni/01-introduction/01-chapter1.markdown
+++ b/es-ni/01-introduction/01-chapter1.markdown
@@ -161,9 +161,9 @@ Or if you’re on a Debian-based distribution like Ubuntu, try apt-get:
 
 ### Installing on Mac ###
 
-There are two easy ways to install Git on a Mac. The easiest is to use the graphical Git installer, which you can download from the Google Code page (see Figure 1-7):
+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 SourceForge page (see Figure 1-7):
 
-	http://code.google.com/p/git-osx-installer
+	http://sourceforge.net/projects/git-osx-installer/
 
 Insert 18333fig0107.png 
 Figure 1-7. Git OS X installer
diff --git a/es/01-introduction/01-chapter1.markdown b/es/01-introduction/01-chapter1.markdown
index 0321144ba..793f342e6 100644
--- a/es/01-introduction/01-chapter1.markdown
+++ b/es/01-introduction/01-chapter1.markdown
@@ -161,9 +161,9 @@ O si estás en una distribución basada en Debian como Ubuntu, prueba con apt-ge
 
 ### Instalando en Mac ###
 
-Hay dos maneras fáciles de instalar Git en un Mac. La más sencilla es usar el instalador gráfico de Git, que puedes descargar desde la página de Google Code (véase Figura 1-7):
+Hay dos maneras fáciles de instalar Git en un Mac. La más sencilla es usar el instalador gráfico de Git, que puedes descargar desde la página de SourceForge (véase Figura 1-7):
 
-	http://code.google.com/p/git-osx-installer
+	http://sourceforge.net/projects/git-osx-installer/
 
 Insert 18333fig0107.png
 Figura 1-7. Instalador de Git para OS X.
diff --git a/fi/01-introduction/01-chapter1.markdown b/fi/01-introduction/01-chapter1.markdown
index 8ca8f2b98..ead7c3bf8 100644
--- a/fi/01-introduction/01-chapter1.markdown
+++ b/fi/01-introduction/01-chapter1.markdown
@@ -163,7 +163,7 @@ Tai jos olet Debian-pohjaisessa julkaisussa kuten Ubuntussa, kokeile apt-getiä:
 
 On olemassa kaksi helppoa tapaa asentaa Git Macissä. Helpoin on käyttää graafista Git-asennusohjelmaa, jonka voit ladata Googlen Code -verkkosivuilta (katso Kuva 1-7):
 
-	http://code.google.com/p/git-osx-installer
+	http://sourceforge.net/projects/git-osx-installer/
 
 Insert 18333fig0107.png
 Kuva 1-7. Git OS X -asennusohjelma.
diff --git a/fr/01-introduction/01-chapter1.markdown b/fr/01-introduction/01-chapter1.markdown
index fbc0ef1ad..2fda80793 100644
--- a/fr/01-introduction/01-chapter1.markdown
+++ b/fr/01-introduction/01-chapter1.markdown
@@ -248,9 +248,9 @@ Si vous êtes sur un système basé sur Debian, tel qu'Ubuntu, essayez apt-get 
 ### Installation sur Mac ###
 
 Il y a deux moyens simples d'installer Git sur Mac.
-Le plus simple et d'utiliser l'installateur graphique de Git que vous pouvez télécharger depuis les pages Google Code (voir figure 1-7) :
+Le plus simple et d'utiliser l'installateur graphique de Git que vous pouvez télécharger depuis les pages SourceForge (voir figure 1-7) :
 
-	http://code.google.com/p/git-osx-installer
+	http://sourceforge.net/projects/git-osx-installer/
 
 Insert 18333fig0107.png
 Figure 1-7. Installateur OS X de Git.
diff --git a/hu/01-introduction/01-chapter1.markdown b/hu/01-introduction/01-chapter1.markdown
index c3cef723a..7f314fc2b 100644
--- a/hu/01-introduction/01-chapter1.markdown
+++ b/hu/01-introduction/01-chapter1.markdown
@@ -161,9 +161,9 @@ Or if you’re on a Debian-based distribution like Ubuntu, try apt-get:
 
 ### Installing on Mac ###
 
-There are two easy ways to install Git on a Mac. The easiest is to use the graphical Git installer, which you can download from the Google Code page (see Figure 1-7):
+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 SourceForge page (see Figure 1-7):
 
-	http://code.google.com/p/git-osx-installer
+	http://sourceforge.net/projects/git-osx-installer/
 
 Insert 18333fig0107.png 
 Figure 1-7. Git OS X installer.
diff --git a/id/01-introduction/01-chapter1.markdown b/id/01-introduction/01-chapter1.markdown
index af9b8cfc3..8fe56b1e6 100644
--- a/id/01-introduction/01-chapter1.markdown
+++ b/id/01-introduction/01-chapter1.markdown
@@ -161,9 +161,9 @@ Atau jika anda menggunakan distro berbasis Debian seperti Ubuntu, coba gunakan a
 
 ### Menginstall Git pada Mac ###
 
-Terdapat dua cara mudah untuk menginstal Git pada sebuah komputer Mac. Cara termudah adalah menggunakan installer Git berbasis GUI, yang dapat anda peroleh dari halaman Google Code (lihat Gambar 1-7):
+Terdapat dua cara mudah untuk menginstal Git pada sebuah komputer Mac. Cara termudah adalah menggunakan installer Git berbasis GUI, yang dapat anda peroleh dari halaman SourceForge (lihat Gambar 1-7):
 
-	http://code.google.com/p/git-osx-installer
+	http://sourceforge.net/projects/git-osx-installer/
 
 Insert 18333fig0107.png 
 Gambar 1-7. Git OS X installer.
diff --git a/it/01-introduction/01-chapter1.markdown b/it/01-introduction/01-chapter1.markdown
index 2806f937b..4b5701a8a 100644
--- a/it/01-introduction/01-chapter1.markdown
+++ b/it/01-introduction/01-chapter1.markdown
@@ -161,9 +161,9 @@ O se sei su una distribuzione basata su Debian, come Ubuntu, prova apt-get:
 
 ### Installazione su Mac ###
 
-Ci sono due metodi per installare Git su Mac. Il più semplice è usare l'installer grafico di Git, che puoi scaricare dalla pagina di Google Code (vedi Figura 1-7):
+Ci sono due metodi per installare Git su Mac. Il più semplice è usare l'installer grafico di Git, che puoi scaricare dalla pagina di SourceForge (vedi Figura 1-7):
 
-	http://code.google.com/p/git-osx-installer
+	http://sourceforge.net/projects/git-osx-installer/
 
 Insert 18333fig0107.png 
 Figura 1-7. Installer di Git per OS X.
diff --git a/ja/01-introduction/01-chapter1.markdown b/ja/01-introduction/01-chapter1.markdown
index 9346f4055..039eb307e 100644
--- a/ja/01-introduction/01-chapter1.markdown
+++ b/ja/01-introduction/01-chapter1.markdown
@@ -163,9 +163,9 @@ Gitをインストールするためには、Gitが依存するライブラリ
 
 ### Macにインストール ###
 
-MacにGitをインストールするには2つの簡単な方法があります。もっとも簡単な方法は、グラフィカルなGitインストーラーを使うことで、このGitインストーラーはGoogle Codeのページ（図1-7参照）からダウンロードすることができます：
+MacにGitをインストールするには2つの簡単な方法があります。もっとも簡単な方法は、グラフィカルなGitインストーラーを使うことで、このGitインストーラーはSourceForgeのページ（図1-7参照）からダウンロードすることができます：
 
-	http://code.google.com/p/git-osx-installer
+	http://sourceforge.net/projects/git-osx-installer/
 
 Insert 18333fig0107.png
 図 1-7. Git OS X installer
diff --git a/ko/01-introduction/01-chapter1.markdown b/ko/01-introduction/01-chapter1.markdown
index a7a24715b..8a015f6ca 100644
--- a/ko/01-introduction/01-chapter1.markdown
+++ b/ko/01-introduction/01-chapter1.markdown
@@ -161,9 +161,9 @@ Ubuntu같은 데비안류 배포판에서는 apt-get을 사용한다:
 
 ### Mac에 설치하기 ###
 
-Mac에 Git을 쉽게 설치하는 방법은 두 가지가 있다. GUI 인스톨러가 가장 쉽게 사용할 수 있다. Google Code 페이지에서 내려받는다:
+Mac에 Git을 쉽게 설치하는 방법은 두 가지가 있다. GUI 인스톨러가 가장 쉽게 사용할 수 있다. SourceForge 페이지에서 내려받는다:
 
-	http://code.google.com/p/git-osx-installer
+	http://sourceforge.net/projects/git-osx-installer/
 
 Insert 18333fig0107.png 
 그림 1-7. OS X Git 인스톨러
diff --git a/mk/01-introduction/01-chapter1.markdown b/mk/01-introduction/01-chapter1.markdown
index 73c0f079e..b310b78b1 100644
--- a/mk/01-introduction/01-chapter1.markdown
+++ b/mk/01-introduction/01-chapter1.markdown
@@ -161,9 +161,9 @@ Git папката е местото каде што Git ги складира 
 
 ### Инсталирање на Мекинтош ###
 
-Постојат два лесни начини како да го инсталирате Git на Мекинтош. Најлесниот е да го користите графичкиот Git инсталатор, кој што може да го симнете до Google Code страната (види слика 1-7):
+Постојат два лесни начини како да го инсталирате Git на Мекинтош. Најлесниот е да го користите графичкиот Git инсталатор, кој што може да го симнете до SourceForge страната (види слика 1-7):
 
-	http://code.google.com/p/git-osx-installer
+	http://sourceforge.net/projects/git-osx-installer/
 
 Insert 18333fig0107.png 
 Слика 1-7. Git OS X инсталатор.
diff --git a/nl/01-introduction/01-chapter1.markdown b/nl/01-introduction/01-chapter1.markdown
index 335bdd45e..4907ff94c 100644
--- a/nl/01-introduction/01-chapter1.markdown
+++ b/nl/01-introduction/01-chapter1.markdown
@@ -199,7 +199,7 @@ Of als je een distributie hebt die op Debian gebaseerd is, zoals Ubuntu, kun je
 
 Er zijn twee makkelijke manieren om Git op een Mac te installeren. De simpelste is om het grafische Git installatieprogramma te gebruiken, dat je van de volgende pagina op Google Code kunt downloaden (zie Figuur 1-7):
 
-	http://code.google.com/p/git-osx-installer
+	http://sourceforge.net/projects/git-osx-installer/
 
 Insert 18333fig0107.png
 Figuur 1-7. Gitinstallatieprogramma voor OS X.
diff --git a/no-nb/01-introduction/01-chapter1.markdown b/no-nb/01-introduction/01-chapter1.markdown
index 6254fca01..6957dc82f 100644
--- a/no-nb/01-introduction/01-chapter1.markdown
+++ b/no-nb/01-introduction/01-chapter1.markdown
@@ -161,9 +161,9 @@ Or if you’re on a Debian-based distribution like Ubuntu, try apt-get:
 
 ### Installing on Mac ###
 
-There are two easy ways to install Git on a Mac. The easiest is to use the graphical Git installer, which you can download from the Google Code page (see Figure 1-7):
+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 SourceForge page (see Figure 1-7):
 
-	http://code.google.com/p/git-osx-installer
+	http://sourceforge.net/projects/git-osx-installer/
 
 Insert 18333fig0107.png
 Figure 1-7. Git OS X installer.
diff --git a/pl/01-introduction/01-chapter1.markdown b/pl/01-introduction/01-chapter1.markdown
index 58058c78e..5ef367d64 100644
--- a/pl/01-introduction/01-chapter1.markdown
+++ b/pl/01-introduction/01-chapter1.markdown
@@ -161,9 +161,9 @@ Jeśli korzystasz z dystrybucji opartej na Debianie (np. Ubuntu), użyj apt-get:
 
 ### Instalacja na komputerze Mac ###
 
-Istnieją dwa proste sposoby instalacji Git na komputerze Mac. Najprostszym z nich jest użycie graficznego instalatora, którego można pobrać z witryny Google Code (patrz Ekran 1-7):
+Istnieją dwa proste sposoby instalacji Git na komputerze Mac. Najprostszym z nich jest użycie graficznego instalatora, którego można pobrać z witryny SourceForge (patrz Ekran 1-7):
 
-	http://code.google.com/p/git-osx-installer
+	http://sourceforge.net/projects/git-osx-installer/
 
 Insert 18333fig0107.png 
 Figure 1-7. Instalator Git dla OS X.
diff --git a/pt-br/01-introduction/01-chapter1.markdown b/pt-br/01-introduction/01-chapter1.markdown
index 7d3a98c53..3d0937919 100644
--- a/pt-br/01-introduction/01-chapter1.markdown
+++ b/pt-br/01-introduction/01-chapter1.markdown
@@ -161,9 +161,9 @@ Ou se você estiver em uma distribuição baseada no Debian, como o Ubuntu, use
 
 ### Instalando no Mac ###
 
-Existem duas formas fáceis de se instalar Git em um Mac. A mais fácil delas é usar o instalador gráfico do Git, que você pode baixar da página do Google Code (veja Figura 1-7):
+Existem duas formas fáceis de se instalar Git em um Mac. A mais fácil delas é usar o instalador gráfico do Git, que você pode baixar da página do SourceForge (veja Figura 1-7):
 
-    http://code.google.com/p/git-osx-installer
+    http://sourceforge.net/projects/git-osx-installer/
 
 Insert 18333fig0107.png
 Figura 1-7. Instalador Git OS X.
diff --git a/ro/01-introduction/01-chapter1.markdown b/ro/01-introduction/01-chapter1.markdown
index c8d6c7054..46b3e00fc 100644
--- a/ro/01-introduction/01-chapter1.markdown
+++ b/ro/01-introduction/01-chapter1.markdown
@@ -161,9 +161,9 @@ Sau dacă folosiți o distribuție bazată pe Debian, de exemplu Ubuntu, încerc
 
 ### Instalarea pe sistemele Mac ###
 
-Sunt două moduri simple de a instala Git pe sistemele Mac. Cea mai simplă este să folosiți programul de instalare grafic pentru Git, pe care îl puteți descărca de la pagina Google Code ( vedeți Figura 1-7):
+Sunt două moduri simple de a instala Git pe sistemele Mac. Cea mai simplă este să folosiți programul de instalare grafic pentru Git, pe care îl puteți descărca de la pagina SourceForge ( vedeți Figura 1-7):
 
-	http://code.google.com/p/git-osx-installer
+	http://sourceforge.net/projects/git-osx-installer/
 
 Insert 18333fig0107.png 
 Figura 1-7. Programul de instalare Git în OS X.
diff --git a/ru/01-introduction/01-chapter1.markdown b/ru/01-introduction/01-chapter1.markdown
index 864a00e05..2212d4888 100644
--- a/ru/01-introduction/01-chapter1.markdown
+++ b/ru/01-introduction/01-chapter1.markdown
@@ -161,9 +161,9 @@ Insert 18333fig0106.png
 
 ### Установка на Mac ###
 
-Есть два простых способа установить Git на Mac. Самый простой — использовать графический инсталлятор Git'а, который вы можете скачать со страницы на Google Code (см. рисунок 1-7):
+Есть два простых способа установить Git на Mac. Самый простой — использовать графический инсталлятор Git'а, который вы можете скачать со страницы на SourceForge (см. рисунок 1-7):
 
-	http://code.google.com/p/git-osx-installer
+	http://sourceforge.net/projects/git-osx-installer/
 
 Insert 18333fig0107.png
 Рисунок 1-7. Инсталлятор Git'а под OS X.
diff --git a/sr/01-introduction/01-chapter1.markdown b/sr/01-introduction/01-chapter1.markdown
index 1cf422998..0603869b1 100644
--- a/sr/01-introduction/01-chapter1.markdown
+++ b/sr/01-introduction/01-chapter1.markdown
@@ -161,9 +161,9 @@ Or if you’re on a Debian-based distribution like Ubuntu, try apt-get:
 
 ### Installing on Mac ###
 
-There are two easy ways to install Git on a Mac. The easiest is to use the graphical Git installer, which you can download from the Google Code page (see Figure 1-7):
+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 SourceForge page (see Figure 1-7):
 
-	http://code.google.com/p/git-osx-installer
+	http://sourceforge.net/projects/git-osx-installer/
 
 Insert 18333fig0107.png 
 Figure 1-7. Git OS X installer
diff --git a/th/01-introduction/01-chapter1.markdown b/th/01-introduction/01-chapter1.markdown
index 945fbe006..50cf03606 100644
--- a/th/01-introduction/01-chapter1.markdown
+++ b/th/01-introduction/01-chapter1.markdown
@@ -161,9 +161,9 @@ staging area เป็นไฟล์ธรรมดาไฟล์นึง โ
 
 ### การติดตั้งบนแมค ###
 
-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):
+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 SourceForge page (see Figure 1-7):
 
-	http://code.google.com/p/git-osx-installer
+	http://sourceforge.net/projects/git-osx-installer/
 
 Insert 18333fig0107.png 
 Figure 1-7. Git OS X installer.
diff --git a/tr/01-introduction/01-chapter1.markdown b/tr/01-introduction/01-chapter1.markdown
index c0ae4c269..e7f87df22 100644
--- a/tr/01-introduction/01-chapter1.markdown
+++ b/tr/01-introduction/01-chapter1.markdown
@@ -163,9 +163,9 @@ Ubuntu gibi Debian-tabanlı bir sistemdeyseniz, apt-get'i kullanabilirsiniz:
 
 ### Mac'te Kurulum ###
 
-Git'i Mac'te kurmak için iki kolay yol vardır. En kolayı, Google Code sayfasından indirebileceğiniz görsel Git yükleyicisini kullanmaktır (bkz. Figür 1-7).
+Git'i Mac'te kurmak için iki kolay yol vardır. En kolayı, SourceForge sayfasından indirebileceğiniz görsel Git yükleyicisini kullanmaktır (bkz. Figür 1-7).
 
-	http://code.google.com/p/git-osx-installer
+	http://sourceforge.net/projects/git-osx-installer/
 
 Insert 18333fig0107.png 
 Figür 1-7. Git OS X yükleyicisi.
diff --git a/vi/01-introduction/01-chapter1.markdown b/vi/01-introduction/01-chapter1.markdown
index 43e416fbf..81fbbb597 100644
--- a/vi/01-introduction/01-chapter1.markdown
+++ b/vi/01-introduction/01-chapter1.markdown
@@ -161,9 +161,9 @@ Còn nếu bạn đang sử dụng một hệ điều hành dựa trên nhân De
 
 ### Cài Đặt Trên Mac ###
 
-Có hai cách đơn giản để cài đặt Git trên Mac. Cách đơn giản nhất là sử dụng chương trình cài đặt có hỗ trợ giao diện, bạn có thể tải về từ trang web của Google Code (xem Hình 1-7):
+Có hai cách đơn giản để cài đặt Git trên Mac. Cách đơn giản nhất là sử dụng chương trình cài đặt có hỗ trợ giao diện, bạn có thể tải về từ trang web của SourceForge (xem Hình 1-7):
 
-	http://code.google.com/p/git-osx-installer
+	http://sourceforge.net/projects/git-osx-installer/
 
 Insert 18333fig0107.png
 Hình 1-7. Chương trình cài đặt Git cho Mac OS X.
diff --git a/zh-tw/01-introduction/01-chapter1.markdown b/zh-tw/01-introduction/01-chapter1.markdown
index 2c581fec5..d594820ea 100644
--- a/zh-tw/01-introduction/01-chapter1.markdown
+++ b/zh-tw/01-introduction/01-chapter1.markdown
@@ -161,9 +161,9 @@ Git目錄是Git用來儲存讀者的專案的元數據及物件資料庫。 這
 
 ### 在Mac系統安裝 ###
 
-有兩種很容易將Git安裝到Mac的方法。 最簡單的是使用圖形化界面的Git安裝程式，可從Google Code下載）圖1－7）：
+有兩種很容易將Git安裝到Mac的方法。 最簡單的是使用圖形化界面的Git安裝程式，可從SourceForge下載）圖1－7）：
 
-	http://code.google.com/p/git-osx-installer
+	http://sourceforge.net/projects/git-osx-installer/
 
 Insert 18333fig0107.png
 圖1-7. Git OS X 安裝程式。
@@ -176,7 +176,7 @@ Insert 18333fig0107.png
 
 ### 在Windows系統安裝 ###
 
-在Windows系統安裝Git相當地容易。 msysGit專案已提供相當容易安裝的程序。 只要從Google Code網頁下載安裝程式並執行即可：
+在Windows系統安裝Git相當地容易。 msysGit專案已提供相當容易安裝的程序。 只要從GitHub網頁下載安裝程式並執行即可：
 
 	http://msysgit.github.com/
 
diff --git a/zh/01-introduction/01-chapter1.markdown b/zh/01-introduction/01-chapter1.markdown
index fb33d4518..cfac13adf 100644
--- a/zh/01-introduction/01-chapter1.markdown
+++ b/zh/01-introduction/01-chapter1.markdown
@@ -163,7 +163,7 @@ Git 的工作需要调用 curl，zlib，openssl，expat，libiconv 等库的代
 
 在 Mac 上安装 Git 有两种方式。最容易的当属使用图形化的 Git 安装工具，界面如图 1-7，下载地址在：
 
-	http://code.google.com/p/git-osx-installer
+	http://sourceforge.net/projects/git-osx-installer/
 
 Insert 18333fig0107.png
 图 1-7. Git OS X 安装工具

From 9f74e930db69ae5fc61496608733acf5f89e5ee8 Mon Sep 17 00:00:00 2001
From: Ilya Kuznetsov <i.kuznetsov@xored.com>
Date: Sat, 19 Apr 2014 15:10:22 +0700
Subject: [PATCH 339/690] As of current Git version, --all-match matches greps

---
 en/02-git-basics/01-chapter2.markdown | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/en/02-git-basics/01-chapter2.markdown b/en/02-git-basics/01-chapter2.markdown
index 5a85343ce..8090ba342 100644
--- a/en/02-git-basics/01-chapter2.markdown
+++ b/en/02-git-basics/01-chapter2.markdown
@@ -637,7 +637,9 @@ However, the time-limiting options such as `--since` and `--until` are very usef
 
 This command works with lots of formats — you can specify a specific date (“2008-01-15”) or a relative date such as “2 years 1 day 3 minutes ago”.
 
-You can also filter the list to commits that match some search criteria. The `--author` option allows you to filter on a specific author, and the `--grep` option lets you search for keywords in the commit messages. (Note that if you want to specify both author and grep options, you have to add `--all-match` or the command will match commits with either.)
+You can also filter the list to commits that match some search criteria. The `--author` option allows you to filter on a specific author, and the `--grep` option lets you search for keywords in the commit messages. (Note that if you specify both author and grep options, the command will match commits with both.)
+
+If you want to specify multiple grep options, you have to add `--all-match` or the command will match commits with either.
 
 The last really useful option to pass to `git log` as a filter is a path. If you specify a directory or file name, you can limit the log output to commits that introduced a change to those files. This is always the last option and is generally preceded by double dashes (`--`) to separate the paths from the options.
 

From 657ea88fc42c4f82e08db3e2ac5fdc2c617aa8ba Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Sun, 20 Apr 2014 20:06:30 +0200
Subject: [PATCH 340/690] [it] update chapter6

Reviewed "Git Tools"
---
 it/06-git-tools/01-chapter6.markdown | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/it/06-git-tools/01-chapter6.markdown b/it/06-git-tools/01-chapter6.markdown
index 0363c27d7..1f8d26c85 100644
--- a/it/06-git-tools/01-chapter6.markdown
+++ b/it/06-git-tools/01-chapter6.markdown
@@ -1,8 +1,8 @@
 # Strumenti di Git #
 
-Finora hai imparato la la maggior parte dei comandi d’uso quotidiani e i workflow che potrebbero essere necessari a gestire e mantenere un repository per il controllo del codice sorgente con Git. Hai eseguito le attività di base per il tracciamento e la commit dei file, e hai sfruttato il potere della *staging area* e il *branch* (la ramificazione) e il *merge* di argomenti dall’impatto leggero.
+Finora hai imparato la maggior parte dei comandi d’uso quotidiani e i flussi di lavoro che devi conoscere per gestire o mantenere un repository Git per i tuoi sorgenti. Hai eseguito le attività di base per tracciare e committare i file, hai sfruttato il potere dell' *area di staging* e le diramazioni (*branch*) e le unioni (*merge*) leggere.
 
-Vedremo ora una serie di potenzialità di Git che potresti non usare quotidianamente, ma di cui potresti averne bisogno a un certo punto.
+Ora vedremo una serie di cose molto potenti di Git che potresti non usare quotidianamente, ma di cui a un certo punto potresti averne bisogno.
 
 ## Selezione della revisione ##
 

From d7369babefeb9c47b33b3c7051acd03e3b1b7871 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Sun, 20 Apr 2014 20:21:55 +0200
Subject: [PATCH 341/690] [it] updating chapter6

Reviewed "Short SHA"
---
 it/06-git-tools/01-chapter6.markdown | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/it/06-git-tools/01-chapter6.markdown b/it/06-git-tools/01-chapter6.markdown
index 1f8d26c85..243fb24f4 100644
--- a/it/06-git-tools/01-chapter6.markdown
+++ b/it/06-git-tools/01-chapter6.markdown
@@ -14,9 +14,9 @@ Puoi fare riferimento a una singola commit usando l’hash SHA-1 attribuito, ma
 
 ### SHA breve ###
 
-Git è abbastanza intelligente da capire a quale *commit* ti riferisci scrivi i primi caratteri purché il codice SHA-1 sia di almeno quattro caratteri e sia univoco, ovvero che un solo oggetti nel *repository* attuale inizi con quel SHA-1.
+Git è abbastanza intelligente da capire a quale *commit* ti riferisci se scrivi i primi caratteri purché il codice SHA-1 sia di almeno quattro caratteri e sia univoco: ovvero che uno solo degli oggetti nel *repository* inizi con quel SHA-1.
 
-Per vedere per esempio una *commit*  specifica, immaginiamo di eseguire 'git log' e venga identificata una *commit* dove sono state aggiunte determinate funzionalità:
+Per vedere per esempio una specifica *commit*, immagina di eseguire 'git log' e trovi la *commit* dove sono state aggiunte determinate funzionalità:
 
 	$ git log
 	commit 734713bc047d87bf7eac9674765ae793478c50d3
@@ -38,7 +38,7 @@ Per vedere per esempio una *commit*  specifica, immaginiamo di eseguire 'git log
 
 	    added some blame and merge stuff
 
-In questo caso scegliamo '1c002dd....'. Se vuoi eseguire 'git show' su quella *commit*, i seguenti comandi sono equivalenti (assumendo che le versioni più brevi siano univoche):            
+In questo caso scegli '1c002dd....'. Se vuoi eseguire 'git show' su quella *commit*, i seguenti comandi sono equivalenti (assumendo che le versioni più brevi siano univoche):            
 
 	$ git show 1c002dd4b536e7479fe34593e72e6c6c1819e53b
 	$ git show 1c002dd4b536e7479f

From 7881959c267f1ac0f66471e2d3d679aecdde041d Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Mon, 21 Apr 2014 19:44:14 +0200
Subject: [PATCH 342/690] [it] updating chapter6

Reviewed "A SHORT NOTE ABOUT SHA-1"
---
 it/06-git-tools/01-chapter6.markdown | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/it/06-git-tools/01-chapter6.markdown b/it/06-git-tools/01-chapter6.markdown
index 243fb24f4..a08a01c47 100644
--- a/it/06-git-tools/01-chapter6.markdown
+++ b/it/06-git-tools/01-chapter6.markdown
@@ -55,13 +55,13 @@ Da otto a dieci caratteri sono, generalmente, più che sufficienti per essere un
 
 ### Una breve nota su SHA-1 ###
 
-Arriva un momento in cui molte persone si preoccupano che possano avere, per puro caso, due oggetti nel proprio *repository* che abbiano lo stesso hash SHA-1. E allora?
+Molte persone si preoccupa che a un certo punto, in modo del tutto casuale, ci possano essere due oggetti nel tuo *repository* che abbiano lo stesso SHA-1. Cosa succederebbe?
 
-Se capita di fare la *commit* di un oggetto a che abbia lo stesso SHA-1 di un oggetto già presente nel tuo *repository*, Git vedrà l’oggetto precedente già nel database di Git e lo riterrà già scritto. Se successivamente proverai a fare il checkout di quest’ultimo oggetto, otterrai sempre i dati del primo oggetto.
+Se dovessi committare un oggetto che abbia lo stesso hash SHA-1 di un altro oggetto che sia già nel tuo repository, Git troverà l'altro oggetto già nel database di Git e lo considererà già scritto. Se in seguito vorrai scaricare quest'ultimo ogetto, otterrai sempre le informazioni del più vecchio.
 
-Ad ogni modo, è necessario essere consapevoli di quanto sia ridicolmente improbabile questo scenario. Il codice SHA-1 è di 20 bytes o 160 bits. Il numero di oggetti casuali necessari perché ci sia la probabilità del 50% di una singola collisione è di circa 2^80 (la formula per determinare la probabilità di collisione è `p = (n(n-1)/2) * (1/2^160)`). 2^80 è 1.2 x 10^24 ovvero un milione di miliardi di miliardi. È 1.200 volte il numero di granelli di sabbia sulla terra.
+Dovresti comunque essere consapevole che questo sia uno scenario molto improbabile. Il codice SHA-1 è di 20 bytes o 160 bits. Il numero di oggetti casuali necessari perché ci sia la probabilità del 50% di una singola collisione è di circa 2^80 (la formula per determinare la probabilità di collisione è `p = (n(n-1)/2) * (1/2^160)`). 2^80 è 1.2 x 10^24 ovvero 1 milione di miliardi di miliardi. È 1.200 volte il numero di granelli di sabbia sulla terra.
 
-Ecco un esempio per dare un'idea di cosa ci vorrebbe per ottenere una collisione SHA-1. Se tutti i 6.5 miliardi di esseri umani sulla Terra programmassero e, ogni secondo, ognuno scrivesse codice che fosse equivalente all'intera cronologia del kernel Linux (1 milione di oggetti Git) e ne facesse la push su un enorme *repository* Git, ci vorrebbero 5 anni per contenere abbastanza oggetti in quel *repository* per avere il 50% di possibilità di una singola collisione di oggetti SHA-1. Esiste una probabilità più alta che ogni membro del tuo gruppo di sviluppo, per pura coincidenza, venga attaccato e ucciso da dei lupi nella stessa notte.
+Ecco un esempio per dare un'idea di cosa ci vorrebbe per ottenere una collisione SHA-1. Se tutti i 6.5 miliardi di esseri umani sulla Terra programmassero e, ogni secondo, ognuno scrivesse codice che sia equivalente all'intera cronologia del kernel Linux (1 milione di oggetti Git) e ne facesse la push su un enorme *repository* Git, ci vorrebbero 5 anni per contenere abbastanza oggetti in quel *repository* per avere il 50% di possibilità di una singola collisione di oggetti SHA-1. Esiste una probabilità più alta che ogni membro del tuo gruppo di sviluppo, in incidenti non correlati venga attaccato e ucciso da dei lupi nella stessa notte.
 
 ### Riferimenti alle diramazioni (*branch*) ###
 

From 19d185c85729cbae9fd0a070fe3e361c67f4d00e Mon Sep 17 00:00:00 2001
From: Jean-Noel Avila <jn.avila@free.fr>
Date: Tue, 22 Apr 2014 21:57:32 +0200
Subject: [PATCH 343/690] [it] fix error in formating

---
 it/02-git-basics/01-chapter2.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/it/02-git-basics/01-chapter2.markdown b/it/02-git-basics/01-chapter2.markdown
index e4de7ab6a..7fb1bb6f8 100644
--- a/it/02-git-basics/01-chapter2.markdown
+++ b/it/02-git-basics/01-chapter2.markdown
@@ -355,7 +355,7 @@ Nota come in questo caso non hai bisogno di eseguire `git add` per benchmarks.rb
 
 Per rimuovere un file da Git devi rimuoverlo dai file tracciati (più precisamente,  rimuoverlo dall'area di `stage`) e quindi committare. Il comando `git rm` fa questo e lo rimuove dalla tua directory di lavoro, così che la prossima volta non lo vedrai come un file non tracciato.
 
-Se rimuovi semplicemente il file dalla directory di lavoro, apparirà nella sezione "Changes not staged for commit" (cioè, _no in `stage_) dell'output `git status`:
+Se rimuovi semplicemente il file dalla directory di lavoro, apparirà nella sezione "Changes not staged for commit" (cioè, _no in `stage`_) dell'output `git status`:
 
 	$ rm grit.gemspec
 	$ git status

From 57fbc22fa58b530e73a43aec3d4e7ce3db053fa6 Mon Sep 17 00:00:00 2001
From: Jean-Noel Avila <jn.avila@free.fr>
Date: Tue, 22 Apr 2014 22:13:56 +0200
Subject: [PATCH 344/690] [it] fix remaining typos

---
 it/02-git-basics/01-chapter2.markdown | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/it/02-git-basics/01-chapter2.markdown b/it/02-git-basics/01-chapter2.markdown
index 7fb1bb6f8..37e424f01 100644
--- a/it/02-git-basics/01-chapter2.markdown
+++ b/it/02-git-basics/01-chapter2.markdown
@@ -368,7 +368,7 @@ Se rimuovi semplicemente il file dalla directory di lavoro, apparirà nella sezi
 	
 	no changes added to commit (use "git add" and/or "git commit -a")
 
-Se poi esegui `git rm`, la rimozione del file viene messa nello `stage:
+Se poi esegui `git rm`, la rimozione del file viene messa nello `stage`:
 
 	$ git rm grit.gemspec
 	rm 'grit.gemspec'
@@ -1081,7 +1081,7 @@ Puoi vedere che hai etichettato la commit:
 
 ### Condividere le etichette ###
 
-Normalmente il comando `git push` non invia le etichette sui server remoti. Devi farlo esplicitamente, dopo averle create, per condividerle con il server. Questo procedimento è come la condivisione delle diramazioni remote: puoi eseguire `git push origin [nome-tag
+Normalmente il comando `git push` non invia le etichette sui server remoti. Devi farlo esplicitamente, dopo averle create, per condividerle con il server. Questo procedimento è come la condivisione delle diramazioni remote: puoi eseguire `git push origin [nome-tag]`
 
 	$ git push origin v1.5
 	Counting objects: 50, done.

From daba9e6942f0ef88866c6b7ed0f581ba402e1c77 Mon Sep 17 00:00:00 2001
From: Jean-Noel Avila <jn.avila@free.fr>
Date: Tue, 22 Apr 2014 22:17:56 +0200
Subject: [PATCH 345/690] [it] fix space at end of title

---
 it/06-git-tools/01-chapter6.markdown | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/it/06-git-tools/01-chapter6.markdown b/it/06-git-tools/01-chapter6.markdown
index 243fb24f4..bfb370452 100644
--- a/it/06-git-tools/01-chapter6.markdown
+++ b/it/06-git-tools/01-chapter6.markdown
@@ -250,7 +250,7 @@ In questo è comune usare il parametro `--left-right` con il comando `log`, che
 
 Con questi strumenti puoi dire facilmente a Git quale o quali commit vuoi ispezionare.
 <!-- da tradurre fino a riga 840 -->
-## Interactive Staging ## 
+## Interactive Staging ##
 
 Git comes with a couple of scripts that make some command-line tasks easier. Here, you’ll look at a few interactive commands that can help you easily craft your commits to include only certain combinations and parts of files. These tools are very helpful if you modify a bunch of files and then decide that you want those changes to be in several focused commits rather than one big messy commit. This way, you can make sure your commits are logically separate changesets and can be easily reviewed by the developers working with you.
 If you run `git add` with the `-i` or `--interactive` option, Git goes into an interactive shell mode, displaying something like this:
@@ -1135,4 +1135,4 @@ O confrontare quello che c’è nella directory `rack` con quello che c’era ne
 
 ## Sommario ##
 
-Hai visto numerosi strumenti avanzati che ti permettono di manipolare le tue commit e la tua area di staging in modo più preciso. Quando incontrassi dei problemi dovresti essere facilmente in grado di capire quale commit li ha generati, quando e chi ne è l’autore. Se desideri usare dei sotto-progetti nel tuo progetto e hai appreso alcuni modi per soddisfare tali esigenze. A questo punto dovresti essere in grado di fare in Git la maggior parte delle cose sulla riga di comando di uso quotidiano, e sentirti a tuo agio facendole.
\ No newline at end of file
+Hai visto numerosi strumenti avanzati che ti permettono di manipolare le tue commit e la tua area di staging in modo più preciso. Quando incontrassi dei problemi dovresti essere facilmente in grado di capire quale commit li ha generati, quando e chi ne è l’autore. Se desideri usare dei sotto-progetti nel tuo progetto e hai appreso alcuni modi per soddisfare tali esigenze. A questo punto dovresti essere in grado di fare in Git la maggior parte delle cose sulla riga di comando di uso quotidiano, e sentirti a tuo agio facendole.

From fff2a591a51fbb9f86f0b0dd7f7cc0e3cb25c83a Mon Sep 17 00:00:00 2001
From: Jean-Noel Avila <jn.avila@free.fr>
Date: Tue, 22 Apr 2014 22:21:41 +0200
Subject: [PATCH 346/690] switch travis to parallel ci check

---
 .travis.yml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.travis.yml b/.travis.yml
index 021aa63ec..7f1427481 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -1,6 +1,6 @@
 language: ruby
 rvm:
   - 1.9.3
-script: rake ci:check
+script: rake ci:parallel_check
 notifications:
   email: false
\ No newline at end of file

From 866ea6a184e574ad4ac2b4977598ab7d68d9542b Mon Sep 17 00:00:00 2001
From: Jean-Noel Avila <jn.avila@free.fr>
Date: Tue, 22 Apr 2014 22:32:10 +0200
Subject: [PATCH 347/690] travis: add e-mail notification on status change

---
 .travis.yml | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/.travis.yml b/.travis.yml
index 7f1427481..9071e3867 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -3,4 +3,7 @@ rvm:
   - 1.9.3
 script: rake ci:parallel_check
 notifications:
-  email: false
\ No newline at end of file
+  email:
+    recipients:
+      - jn.avila@free.fr
+

From 508daa7dd0b30cc5820e6617157277e7e1a59066 Mon Sep 17 00:00:00 2001
From: harupong <harupong@gmail.com>
Date: Wed, 23 Apr 2014 13:38:05 +0900
Subject: [PATCH 348/690] Apply 60e2618 to ja tree

---
 ja/02-git-basics/01-chapter2.markdown | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/ja/02-git-basics/01-chapter2.markdown b/ja/02-git-basics/01-chapter2.markdown
index 4200b6c66..b78d99bf7 100755
--- a/ja/02-git-basics/01-chapter2.markdown
+++ b/ja/02-git-basics/01-chapter2.markdown
@@ -635,7 +635,9 @@ The lines must be formatted as follows
 
 このコマンドはさまざまな書式で動作します。特定の日を指定する (“2008-01-15”) こともできますし、相対日付を“2 years 1 day 3 minutes ago”のように指定することも可能です。
 
-コミット一覧から検索条件にマッチするものだけを取り出すこともできます。`--author` オプションは特定の author のみを抜き出し、`--grep` オプションはコミットメッセージの中のキーワードを検索します (author と grep を両方指定したい場合は `--all-match` を追加しないといけません。そうしないと、どちらか一方にだけマッチするものも対象になってしまいます)。
+コミット一覧から検索条件にマッチするものだけを取り出すこともできます。`--author` オプションは特定の author のみを抜き出し、`--grep` オプションはコミットメッセージの中のキーワードを検索します (author と grep を両方指定すると、両方にマッチするものだけが対象になります)。
+
+grep を複数指定したい場合は、`--all-match` を追加しないといけません。そうしないと、どちらか一方にだけマッチするものも対象になってしまいます。
 
 最後に紹介する `git log` のフィルタリング用オプションは、パスです。ディレクトリ名あるいはファイル名を指定すると、それを変更したコミットのみが対象となります。このオプションは常に最後に指定し、一般にダブルダッシュ (`--`) の後に記述します。このダブルダッシュが他のオプションとパスの区切りとなります。
 

From 74358327065587f752b8f768ceb80c0770beb61b Mon Sep 17 00:00:00 2001
From: harupong <harupong@gmail.com>
Date: Wed, 23 Apr 2014 13:45:52 +0900
Subject: [PATCH 349/690] Apply c418e2e to ja tree

---
 ja/03-git-branching/01-chapter3.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ja/03-git-branching/01-chapter3.markdown b/ja/03-git-branching/01-chapter3.markdown
index 240042ab2..6b16045b8 100644
--- a/ja/03-git-branching/01-chapter3.markdown
+++ b/ja/03-git-branching/01-chapter3.markdown
@@ -275,7 +275,7 @@ Git は新たなマージコミットを自動的には作成しませんでし
 	  {remote}: modified file
 	Hit return to start merge resolution tool (opendiff):
 
-デフォルトのツール (Git は `opendiff` を選びました。私がこのコマンドを Mac で実行したからです) 以外のマージツールを使いたい場合は、“merge tool candidates”にあるツール一覧を見ましょう。そして、使いたいツールの名前を打ち込みます。第 7 章で、環境にあわせてこのデフォルトを変更する方法を説明します。
+デフォルトのツール (Git は `opendiff` を選びました。私がこのコマンドを Mac で実行したからです) 以外のマージツールを使いたい場合は、“... one of the following tools:”にあるツール一覧を見ましょう。そして、使いたいツールの名前を打ち込みます。第 7 章で、環境にあわせてこのデフォルトを変更する方法を説明します。
 
 マージツールを終了させると、マージに成功したかどうかを Git が聞いてきます。成功したと伝えると、ファイルを自動的にステージしてコンフリクトが解決したことを示します。
 

From 025a6b0249838c4ffc4de0756891559278f3bfe5 Mon Sep 17 00:00:00 2001
From: harupong <harupong@gmail.com>
Date: Wed, 23 Apr 2014 13:50:56 +0900
Subject: [PATCH 350/690] Apply 44936fd to ja tree

---
 ja/06-git-tools/01-chapter6.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ja/06-git-tools/01-chapter6.markdown b/ja/06-git-tools/01-chapter6.markdown
index 8be958fa4..42b841145 100644
--- a/ja/06-git-tools/01-chapter6.markdown
+++ b/ja/06-git-tools/01-chapter6.markdown
@@ -493,7 +493,7 @@ apply オプションは、スタックに隠した作業を再度適用する
 
     $ git stash show -p | git apply -R
 
-次の例のようにエイリアスを作れば、git に `stash-unapply` コマンドを追加したのと事実上同じことになります。
+次の例のようにエイリアスを作れば、Git に `stash-unapply` コマンドを追加したのと事実上同じことになります。
 
     $ git config --global alias.stash-unapply '!git stash show -p | git apply -R'
     $ git stash

From 58bda0182d5276c975a249047e0efbda7103ae07 Mon Sep 17 00:00:00 2001
From: harupong <harupong@gmail.com>
Date: Wed, 23 Apr 2014 14:07:48 +0900
Subject: [PATCH 351/690] Apply 3f6c105 to ja tree

---
 ja/06-git-tools/01-chapter6.markdown | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/ja/06-git-tools/01-chapter6.markdown b/ja/06-git-tools/01-chapter6.markdown
index 42b841145..fae8cf67c 100644
--- a/ja/06-git-tools/01-chapter6.markdown
+++ b/ja/06-git-tools/01-chapter6.markdown
@@ -561,12 +561,19 @@ Git を使って作業をしていると、何らかの理由でコミットの
 	#
 	# Commands:
 	#  p, pick = use commit
+	#  r, reword = use commit, but edit the commit message
 	#  e, edit = use commit, but stop for amending
 	#  s, squash = use commit, but meld into previous commit
+	#  f, fixup = like "squash", but discard this commit's log message
+	#  x, exec = run command (the rest of the line) using shell
+	#
+	# These lines can be re-ordered; they are executed from top to bottom.
 	#
 	# If you remove a line here THAT COMMIT WILL BE LOST.
+	#
 	# However, if you remove everything, the rebase will be aborted.
 	#
+	# Note that empty commits are commented out
 
 このコミット一覧の表示順は、`log` コマンドを使ったときの通常の表示順とは逆になることに注意しましょう。`log` を実行すると、このようになります。
 
@@ -627,12 +634,19 @@ Git を使って作業をしていると、何らかの理由でコミットの
 	#
 	# Commands:
 	#  p, pick = use commit
+	#  r, reword = use commit, but edit the commit message
 	#  e, edit = use commit, but stop for amending
 	#  s, squash = use commit, but meld into previous commit
+	#  f, fixup = like "squash", but discard this commit's log message
+	#  x, exec = run command (the rest of the line) using shell
+	#
+	# These lines can be re-ordered; they are executed from top to bottom.
 	#
 	# If you remove a line here THAT COMMIT WILL BE LOST.
+	#
 	# However, if you remove everything, the rebase will be aborted.
 	#
+	# Note that empty commits are commented out
 
 「pick」や「edit」のかわりに「squash」を指定すると、Git はその変更と直前の変更をひとつにまとめて新たなコミットメッセージを書き込めるようにします。つまり、これらの三つのコミットをひとつのコミットにまとめたい場合は、スクリプトをこのように変更します。
 

From cda07c1a01e94da2e13598170245f0aa81357052 Mon Sep 17 00:00:00 2001
From: Cor <git@cpt1.demon.nl>
Date: Fri, 25 Apr 2014 15:00:47 +0200
Subject: [PATCH 352/690] [nl] Synchronized translation with SHA-1 3c18779

---
 nl/01-introduction/01-chapter1.markdown |  4 ++--
 nl/02-git-basics/01-chapter2.markdown   |  4 ++--
 nl/06-git-tools/01-chapter6.markdown    | 16 +++++++++++++++-
 3 files changed, 19 insertions(+), 5 deletions(-)

diff --git a/nl/01-introduction/01-chapter1.markdown b/nl/01-introduction/01-chapter1.markdown
index 4907ff94c..2a6870648 100644
--- a/nl/01-introduction/01-chapter1.markdown
+++ b/nl/01-introduction/01-chapter1.markdown
@@ -33,7 +33,7 @@ vertaling moeten proberen te maken.
 
 Veel succes en plezier bij het vertalen...
 -->
-<!-- SHA-1 of last checked en-version: fbf24105 -->
+<!-- SHA-1 of last checked en-version: 3c18779 -->
 # Aan de slag #
 
 In dit hoofdstuk wordt uitgelegd hoe je aan de slag kunt gaan met Git. We zullen bij het begin beginnen door wat achtergrondinformatie over versiebeheersystemen te geven, daarna een korte uitleg hoe je Git werkend kan krijgen op je computer en sluiten af door uit te leggen hoe je Git kan instellen zodat je ermee aan het werk kunt.  Aan het einde van dit hoofdstuk zou je moeten kunnen begrijpen waarom Git er is, waarom je het zou moeten gebruiken en zal je helemaal klaar zijn om er mee aan de slag te gaan.
@@ -197,7 +197,7 @@ Of als je een distributie hebt die op Debian gebaseerd is, zoals Ubuntu, kun je
 
 ### Op een Mac installeren ###
 
-Er zijn twee makkelijke manieren om Git op een Mac te installeren. De simpelste is om het grafische Git installatieprogramma te gebruiken, dat je van de volgende pagina op Google Code kunt downloaden (zie Figuur 1-7):
+Er zijn twee makkelijke manieren om Git op een Mac te installeren. De simpelste is om het grafische Git installatieprogramma te gebruiken, dat je van de volgende pagina op SourceForge kunt downloaden (zie Figuur 1-7):
 
 	http://sourceforge.net/projects/git-osx-installer/
 
diff --git a/nl/02-git-basics/01-chapter2.markdown b/nl/02-git-basics/01-chapter2.markdown
index 53a08a328..2e2a50a51 100644
--- a/nl/02-git-basics/01-chapter2.markdown
+++ b/nl/02-git-basics/01-chapter2.markdown
@@ -33,7 +33,7 @@ vertaling moeten proberen te maken.
 
 Veel succes en plezier bij het vertalen...
 -->
-<!-- SHA-1 of last checked en-version: fbf24105 -->
+<!-- SHA-1 of last checked en-version: 3c18779  -->
 # De basis van Git #
 
 Als je slechts één hoofdstuk kunt lezen om met Git aan de slag te gaan, dan is dit het. In dit hoofdstuk worden alle basiscommando's behandeld, die je nodig hebben om het leeuwendeel van de dingen te doen waarmee je uiteindelijk je tijd met Git zult doorbrengen. Als je dit hoofdstuk doorgenomen hebt, zul je een repository kunnen configureren en initialiseren, bestanden beginnen en stoppen te volgen en veranderingen te ‘stagen’ en ‘committen’. We laten ook zien hoe je Git kunt instellen zodat het bepaalde bestanden en bestandspatronen negeert, hoe je vergissingen snel en gemakkelijk ongedaan kunt maken, hoe je de geschiedenis van je project kan doorlopen en wijzigingen tussen commits kunt zien, en hoe je kunt pushen naar en pullen van repositories.
@@ -669,7 +669,7 @@ Dat gezegd hebbende, zijn de tijd-limiterende opties zoals `--since` en `--until
 
 Dit commando werkt met veel formaten: je kunt een specifieke datum kiezen ("2008-01-15”) of een relatieve datum zoals "2 jaar 1 dag en 3 minuten geleden".
 
-Je kunt ook de lijst met commits filteren op bepaalde criteria. De `--author` optie laat je filteren op een specifieke auteur, en de `--grep` optie laat je op bepaalde zoekwoorden filteren in de commit boodschappen. (Let op dat als je zowel auteur als grep opties wilt specificeren, je `--all-match` moet toevoegen of anders zal het commando ook commits met één van de twee criteria selecteren.)
+Je kunt ook de lijst met commits filteren op bepaalde criteria. De `--author` optie laat je filteren op een specifieke auteur, en de `--grep` optie laat je op bepaalde zoekwoorden filteren in de commit boodschappen. (Let op dat als je zowel auteur als grep opties specificeert het commando commits zal matchen met beide.) Als je meerdere grep opties wilt specificeren, zal je `--all-match` moet toevoegen, anders zal het commando ook commits met één van de twee criteria selecteren.
 
 De laatste echt handige optie om aan `git log` als filter mee te geven is een pad. Als je een directory of bestandsnaam opgeeft, kun je de log output limiteren tot commits die een verandering introduceren op die bestanden. Dit is altijd de laatste optie en wordt over het algemeen vooraf gegaan door dubbele streepjes (`--`) om de paden van de opties te scheiden.
 
diff --git a/nl/06-git-tools/01-chapter6.markdown b/nl/06-git-tools/01-chapter6.markdown
index 292ddbb42..98180e261 100644
--- a/nl/06-git-tools/01-chapter6.markdown
+++ b/nl/06-git-tools/01-chapter6.markdown
@@ -33,7 +33,7 @@ vertaling moeten proberen te maken.
 
 Veel succes en plezier bij het vertalen...
 -->
-<!-- SHA-1 of last checked en-version: fbf24105 -->
+<!-- SHA-1 of last checked en-version: 3c18779  -->
 # Git tools #
 
 Nu heb je de meeste commando's en werkwijzen geleerd die je dagelijks nodig hebt om een Git repository voor je broncode te beheren en te onderhouden. Je hebt de basistaken van het tracken en committen van bestanden onder de knie, en je hebt de kracht van de staging area en lichtgewicht topic branching en mergen in de vingers.
@@ -603,12 +603,19 @@ Dit commando uitvoeren geeft je een lijst met commits in je tekst editor die er
 	#
 	# Commands:
 	#  p, pick = use commit
+	#  r, reword = use commit, but edit the commit message
 	#  e, edit = use commit, but stop for amending
 	#  s, squash = use commit, but meld into previous commit
+	#  f, fixup = like "squash", but discard this commit's log message
+	#  x, exec = run command (the rest of the line) using shell
+	#
+	# These lines can be re-ordered; they are executed from top to bottom.
 	#
 	# If you remove a line here THAT COMMIT WILL BE LOST.
+	#
 	# However, if you remove everything, the rebase will be aborted.
 	#
+	# Note that empty commits are commented out
 
 Het is belangrijk om op te merken dat deze commits in de tegengestelde volgorde getoond worden dan hoe je ze normaliter ziet als je het `log` commando gebruikt. Als je een `log` uitvoert, zie je zoiets als dit:
 
@@ -669,12 +676,19 @@ Het is ook mogelijk een serie commits te pakken en ze in één enkele commit sam
 	#
 	# Commands:
 	#  p, pick = use commit
+	#  r, reword = use commit, but edit the commit message
 	#  e, edit = use commit, but stop for amending
 	#  s, squash = use commit, but meld into previous commit
+	#  f, fixup = like "squash", but discard this commit's log message
+	#  x, exec = run command (the rest of the line) using shell
+	#
+	# These lines can be re-ordered; they are executed from top to bottom.
 	#
 	# If you remove a line here THAT COMMIT WILL BE LOST.
+	#
 	# However, if you remove everything, the rebase will be aborted.
 	#
+	# Note that empty commits are commented out
 
 Als je in plaats van "pick" of "edit", "squash" specificeert zal Git zowel die verandering als de verandering die er direct aan vooraf gaat toepassen, en je dwingen om de commit berichten samen te voegen. Dus als je een enkele commit van deze drie commits wil maken, laat je het script er zo uit zien:
 

From 5f72fef306296811cc8b165e312b703f6090931c Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Sat, 26 Apr 2014 08:36:33 +0200
Subject: [PATCH 353/690] update `git reflog` output to current one

---
 en/06-git-tools/01-chapter6.markdown | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/en/06-git-tools/01-chapter6.markdown b/en/06-git-tools/01-chapter6.markdown
index ac08f55e4..78578a93b 100644
--- a/en/06-git-tools/01-chapter6.markdown
+++ b/en/06-git-tools/01-chapter6.markdown
@@ -82,13 +82,13 @@ One of the things Git does in the background while you’re working away is keep
 You can see your reflog by using `git reflog`:
 
 	$ git reflog
-	734713b... HEAD@{0}: commit: fixed refs handling, added gc auto, updated
-	d921970... HEAD@{1}: merge phedders/rdocs: Merge made by recursive.
-	1c002dd... HEAD@{2}: commit: added some blame and merge stuff
-	1c36188... HEAD@{3}: rebase -i (squash): updating HEAD
-	95df984... HEAD@{4}: commit: # This is a combination of two commits.
-	1c36188... HEAD@{5}: rebase -i (squash): updating HEAD
-	7e05da5... HEAD@{6}: rebase -i (pick): updating HEAD
+	734713b HEAD@{0}: commit: fixed refs handling, added gc auto, updated
+	d921970 HEAD@{1}: merge phedders/rdocs: Merge made by recursive.
+	1c002dd HEAD@{2}: commit: added some blame and merge stuff
+	1c36188 HEAD@{3}: rebase -i (squash): updating HEAD
+	95df984 HEAD@{4}: commit: # This is a combination of two commits.
+	1c36188 HEAD@{5}: rebase -i (squash): updating HEAD
+	7e05da5 HEAD@{6}: rebase -i (pick): updating HEAD
 
 Every time your branch tip is updated for any reason, Git stores that information for you in this temporary history. And you can specify older commits with this data, as well. If you want to see the fifth prior value of the HEAD of your repository, you can use the `@{n}` reference that you see in the reflog output:
 

From e84b4217b6fc47214cc064cfdd21708e05145dbe Mon Sep 17 00:00:00 2001
From: Jean-Noel Avila <jn.avila@free.fr>
Date: Tue, 22 Apr 2014 21:57:32 +0200
Subject: [PATCH 354/690] [it] fix error in formating

---
 it/02-git-basics/01-chapter2.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/it/02-git-basics/01-chapter2.markdown b/it/02-git-basics/01-chapter2.markdown
index e4de7ab6a..7fb1bb6f8 100644
--- a/it/02-git-basics/01-chapter2.markdown
+++ b/it/02-git-basics/01-chapter2.markdown
@@ -355,7 +355,7 @@ Nota come in questo caso non hai bisogno di eseguire `git add` per benchmarks.rb
 
 Per rimuovere un file da Git devi rimuoverlo dai file tracciati (più precisamente,  rimuoverlo dall'area di `stage`) e quindi committare. Il comando `git rm` fa questo e lo rimuove dalla tua directory di lavoro, così che la prossima volta non lo vedrai come un file non tracciato.
 
-Se rimuovi semplicemente il file dalla directory di lavoro, apparirà nella sezione "Changes not staged for commit" (cioè, _no in `stage_) dell'output `git status`:
+Se rimuovi semplicemente il file dalla directory di lavoro, apparirà nella sezione "Changes not staged for commit" (cioè, _no in `stage`_) dell'output `git status`:
 
 	$ rm grit.gemspec
 	$ git status

From dd44a49639aab21c68543e644b3b1e03cb24aab7 Mon Sep 17 00:00:00 2001
From: Jean-Noel Avila <jn.avila@free.fr>
Date: Tue, 22 Apr 2014 22:13:56 +0200
Subject: [PATCH 355/690] [it] fix remaining typos

---
 it/02-git-basics/01-chapter2.markdown | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/it/02-git-basics/01-chapter2.markdown b/it/02-git-basics/01-chapter2.markdown
index 7fb1bb6f8..37e424f01 100644
--- a/it/02-git-basics/01-chapter2.markdown
+++ b/it/02-git-basics/01-chapter2.markdown
@@ -368,7 +368,7 @@ Se rimuovi semplicemente il file dalla directory di lavoro, apparirà nella sezi
 	
 	no changes added to commit (use "git add" and/or "git commit -a")
 
-Se poi esegui `git rm`, la rimozione del file viene messa nello `stage:
+Se poi esegui `git rm`, la rimozione del file viene messa nello `stage`:
 
 	$ git rm grit.gemspec
 	rm 'grit.gemspec'
@@ -1081,7 +1081,7 @@ Puoi vedere che hai etichettato la commit:
 
 ### Condividere le etichette ###
 
-Normalmente il comando `git push` non invia le etichette sui server remoti. Devi farlo esplicitamente, dopo averle create, per condividerle con il server. Questo procedimento è come la condivisione delle diramazioni remote: puoi eseguire `git push origin [nome-tag
+Normalmente il comando `git push` non invia le etichette sui server remoti. Devi farlo esplicitamente, dopo averle create, per condividerle con il server. Questo procedimento è come la condivisione delle diramazioni remote: puoi eseguire `git push origin [nome-tag]`
 
 	$ git push origin v1.5
 	Counting objects: 50, done.

From 75285df78ecc35a21f4dc7c1801d8a9397e60d2f Mon Sep 17 00:00:00 2001
From: Jean-Noel Avila <jn.avila@free.fr>
Date: Tue, 22 Apr 2014 22:17:56 +0200
Subject: [PATCH 356/690] [it] fix space at end of title

---
 it/06-git-tools/01-chapter6.markdown | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/it/06-git-tools/01-chapter6.markdown b/it/06-git-tools/01-chapter6.markdown
index a08a01c47..b4a41bc62 100644
--- a/it/06-git-tools/01-chapter6.markdown
+++ b/it/06-git-tools/01-chapter6.markdown
@@ -250,7 +250,7 @@ In questo è comune usare il parametro `--left-right` con il comando `log`, che
 
 Con questi strumenti puoi dire facilmente a Git quale o quali commit vuoi ispezionare.
 <!-- da tradurre fino a riga 840 -->
-## Interactive Staging ## 
+## Interactive Staging ##
 
 Git comes with a couple of scripts that make some command-line tasks easier. Here, you’ll look at a few interactive commands that can help you easily craft your commits to include only certain combinations and parts of files. These tools are very helpful if you modify a bunch of files and then decide that you want those changes to be in several focused commits rather than one big messy commit. This way, you can make sure your commits are logically separate changesets and can be easily reviewed by the developers working with you.
 If you run `git add` with the `-i` or `--interactive` option, Git goes into an interactive shell mode, displaying something like this:
@@ -1135,4 +1135,4 @@ O confrontare quello che c’è nella directory `rack` con quello che c’era ne
 
 ## Sommario ##
 
-Hai visto numerosi strumenti avanzati che ti permettono di manipolare le tue commit e la tua area di staging in modo più preciso. Quando incontrassi dei problemi dovresti essere facilmente in grado di capire quale commit li ha generati, quando e chi ne è l’autore. Se desideri usare dei sotto-progetti nel tuo progetto e hai appreso alcuni modi per soddisfare tali esigenze. A questo punto dovresti essere in grado di fare in Git la maggior parte delle cose sulla riga di comando di uso quotidiano, e sentirti a tuo agio facendole.
\ No newline at end of file
+Hai visto numerosi strumenti avanzati che ti permettono di manipolare le tue commit e la tua area di staging in modo più preciso. Quando incontrassi dei problemi dovresti essere facilmente in grado di capire quale commit li ha generati, quando e chi ne è l’autore. Se desideri usare dei sotto-progetti nel tuo progetto e hai appreso alcuni modi per soddisfare tali esigenze. A questo punto dovresti essere in grado di fare in Git la maggior parte delle cose sulla riga di comando di uso quotidiano, e sentirti a tuo agio facendole.

From f17a7a01c1f0f6adf7973575d756a0f9a706ef20 Mon Sep 17 00:00:00 2001
From: Jean-Noel Avila <jn.avila@free.fr>
Date: Tue, 22 Apr 2014 22:21:41 +0200
Subject: [PATCH 357/690] switch travis to parallel ci check

---
 .travis.yml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.travis.yml b/.travis.yml
index 021aa63ec..7f1427481 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -1,6 +1,6 @@
 language: ruby
 rvm:
   - 1.9.3
-script: rake ci:check
+script: rake ci:parallel_check
 notifications:
   email: false
\ No newline at end of file

From 78df263aed727552fa2a3bd0d783c20b71c79b43 Mon Sep 17 00:00:00 2001
From: Jean-Noel Avila <jn.avila@free.fr>
Date: Tue, 22 Apr 2014 22:32:10 +0200
Subject: [PATCH 358/690] travis: add e-mail notification on status change

---
 .travis.yml | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/.travis.yml b/.travis.yml
index 7f1427481..9071e3867 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -3,4 +3,7 @@ rvm:
   - 1.9.3
 script: rake ci:parallel_check
 notifications:
-  email: false
\ No newline at end of file
+  email:
+    recipients:
+      - jn.avila@free.fr
+

From 1667d8ed8c5178a0c6ea5232d4899278d0cd53f4 Mon Sep 17 00:00:00 2001
From: harupong <harupong@gmail.com>
Date: Wed, 23 Apr 2014 13:38:05 +0900
Subject: [PATCH 359/690] Apply 60e2618 to ja tree

---
 ja/02-git-basics/01-chapter2.markdown | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/ja/02-git-basics/01-chapter2.markdown b/ja/02-git-basics/01-chapter2.markdown
index 4200b6c66..b78d99bf7 100755
--- a/ja/02-git-basics/01-chapter2.markdown
+++ b/ja/02-git-basics/01-chapter2.markdown
@@ -635,7 +635,9 @@ The lines must be formatted as follows
 
 このコマンドはさまざまな書式で動作します。特定の日を指定する (“2008-01-15”) こともできますし、相対日付を“2 years 1 day 3 minutes ago”のように指定することも可能です。
 
-コミット一覧から検索条件にマッチするものだけを取り出すこともできます。`--author` オプションは特定の author のみを抜き出し、`--grep` オプションはコミットメッセージの中のキーワードを検索します (author と grep を両方指定したい場合は `--all-match` を追加しないといけません。そうしないと、どちらか一方にだけマッチするものも対象になってしまいます)。
+コミット一覧から検索条件にマッチするものだけを取り出すこともできます。`--author` オプションは特定の author のみを抜き出し、`--grep` オプションはコミットメッセージの中のキーワードを検索します (author と grep を両方指定すると、両方にマッチするものだけが対象になります)。
+
+grep を複数指定したい場合は、`--all-match` を追加しないといけません。そうしないと、どちらか一方にだけマッチするものも対象になってしまいます。
 
 最後に紹介する `git log` のフィルタリング用オプションは、パスです。ディレクトリ名あるいはファイル名を指定すると、それを変更したコミットのみが対象となります。このオプションは常に最後に指定し、一般にダブルダッシュ (`--`) の後に記述します。このダブルダッシュが他のオプションとパスの区切りとなります。
 

From 9556c414617eae52f2f7b549c7a751784c56277d Mon Sep 17 00:00:00 2001
From: harupong <harupong@gmail.com>
Date: Wed, 23 Apr 2014 13:45:52 +0900
Subject: [PATCH 360/690] Apply c418e2e to ja tree

---
 ja/03-git-branching/01-chapter3.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ja/03-git-branching/01-chapter3.markdown b/ja/03-git-branching/01-chapter3.markdown
index 240042ab2..6b16045b8 100644
--- a/ja/03-git-branching/01-chapter3.markdown
+++ b/ja/03-git-branching/01-chapter3.markdown
@@ -275,7 +275,7 @@ Git は新たなマージコミットを自動的には作成しませんでし
 	  {remote}: modified file
 	Hit return to start merge resolution tool (opendiff):
 
-デフォルトのツール (Git は `opendiff` を選びました。私がこのコマンドを Mac で実行したからです) 以外のマージツールを使いたい場合は、“merge tool candidates”にあるツール一覧を見ましょう。そして、使いたいツールの名前を打ち込みます。第 7 章で、環境にあわせてこのデフォルトを変更する方法を説明します。
+デフォルトのツール (Git は `opendiff` を選びました。私がこのコマンドを Mac で実行したからです) 以外のマージツールを使いたい場合は、“... one of the following tools:”にあるツール一覧を見ましょう。そして、使いたいツールの名前を打ち込みます。第 7 章で、環境にあわせてこのデフォルトを変更する方法を説明します。
 
 マージツールを終了させると、マージに成功したかどうかを Git が聞いてきます。成功したと伝えると、ファイルを自動的にステージしてコンフリクトが解決したことを示します。
 

From 1e9aaab85c88aaba18f9779ce0f96df23065646a Mon Sep 17 00:00:00 2001
From: harupong <harupong@gmail.com>
Date: Wed, 23 Apr 2014 13:50:56 +0900
Subject: [PATCH 361/690] Apply 44936fd to ja tree

---
 ja/06-git-tools/01-chapter6.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ja/06-git-tools/01-chapter6.markdown b/ja/06-git-tools/01-chapter6.markdown
index 8be958fa4..42b841145 100644
--- a/ja/06-git-tools/01-chapter6.markdown
+++ b/ja/06-git-tools/01-chapter6.markdown
@@ -493,7 +493,7 @@ apply オプションは、スタックに隠した作業を再度適用する
 
     $ git stash show -p | git apply -R
 
-次の例のようにエイリアスを作れば、git に `stash-unapply` コマンドを追加したのと事実上同じことになります。
+次の例のようにエイリアスを作れば、Git に `stash-unapply` コマンドを追加したのと事実上同じことになります。
 
     $ git config --global alias.stash-unapply '!git stash show -p | git apply -R'
     $ git stash

From ceb3d7dd9a04794c991e352adc0ee124605c636a Mon Sep 17 00:00:00 2001
From: harupong <harupong@gmail.com>
Date: Wed, 23 Apr 2014 14:07:48 +0900
Subject: [PATCH 362/690] Apply 3f6c105 to ja tree

---
 ja/06-git-tools/01-chapter6.markdown | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/ja/06-git-tools/01-chapter6.markdown b/ja/06-git-tools/01-chapter6.markdown
index 42b841145..fae8cf67c 100644
--- a/ja/06-git-tools/01-chapter6.markdown
+++ b/ja/06-git-tools/01-chapter6.markdown
@@ -561,12 +561,19 @@ Git を使って作業をしていると、何らかの理由でコミットの
 	#
 	# Commands:
 	#  p, pick = use commit
+	#  r, reword = use commit, but edit the commit message
 	#  e, edit = use commit, but stop for amending
 	#  s, squash = use commit, but meld into previous commit
+	#  f, fixup = like "squash", but discard this commit's log message
+	#  x, exec = run command (the rest of the line) using shell
+	#
+	# These lines can be re-ordered; they are executed from top to bottom.
 	#
 	# If you remove a line here THAT COMMIT WILL BE LOST.
+	#
 	# However, if you remove everything, the rebase will be aborted.
 	#
+	# Note that empty commits are commented out
 
 このコミット一覧の表示順は、`log` コマンドを使ったときの通常の表示順とは逆になることに注意しましょう。`log` を実行すると、このようになります。
 
@@ -627,12 +634,19 @@ Git を使って作業をしていると、何らかの理由でコミットの
 	#
 	# Commands:
 	#  p, pick = use commit
+	#  r, reword = use commit, but edit the commit message
 	#  e, edit = use commit, but stop for amending
 	#  s, squash = use commit, but meld into previous commit
+	#  f, fixup = like "squash", but discard this commit's log message
+	#  x, exec = run command (the rest of the line) using shell
+	#
+	# These lines can be re-ordered; they are executed from top to bottom.
 	#
 	# If you remove a line here THAT COMMIT WILL BE LOST.
+	#
 	# However, if you remove everything, the rebase will be aborted.
 	#
+	# Note that empty commits are commented out
 
 「pick」や「edit」のかわりに「squash」を指定すると、Git はその変更と直前の変更をひとつにまとめて新たなコミットメッセージを書き込めるようにします。つまり、これらの三つのコミットをひとつのコミットにまとめたい場合は、スクリプトをこのように変更します。
 

From 9d532d71fdc6e84784926d70d493f2e5e7a0b3f2 Mon Sep 17 00:00:00 2001
From: Cor <git@cpt1.demon.nl>
Date: Fri, 25 Apr 2014 15:00:47 +0200
Subject: [PATCH 363/690] [nl] Synchronized translation with SHA-1 3c18779

---
 nl/01-introduction/01-chapter1.markdown |  4 ++--
 nl/02-git-basics/01-chapter2.markdown   |  4 ++--
 nl/06-git-tools/01-chapter6.markdown    | 16 +++++++++++++++-
 3 files changed, 19 insertions(+), 5 deletions(-)

diff --git a/nl/01-introduction/01-chapter1.markdown b/nl/01-introduction/01-chapter1.markdown
index 4907ff94c..2a6870648 100644
--- a/nl/01-introduction/01-chapter1.markdown
+++ b/nl/01-introduction/01-chapter1.markdown
@@ -33,7 +33,7 @@ vertaling moeten proberen te maken.
 
 Veel succes en plezier bij het vertalen...
 -->
-<!-- SHA-1 of last checked en-version: fbf24105 -->
+<!-- SHA-1 of last checked en-version: 3c18779 -->
 # Aan de slag #
 
 In dit hoofdstuk wordt uitgelegd hoe je aan de slag kunt gaan met Git. We zullen bij het begin beginnen door wat achtergrondinformatie over versiebeheersystemen te geven, daarna een korte uitleg hoe je Git werkend kan krijgen op je computer en sluiten af door uit te leggen hoe je Git kan instellen zodat je ermee aan het werk kunt.  Aan het einde van dit hoofdstuk zou je moeten kunnen begrijpen waarom Git er is, waarom je het zou moeten gebruiken en zal je helemaal klaar zijn om er mee aan de slag te gaan.
@@ -197,7 +197,7 @@ Of als je een distributie hebt die op Debian gebaseerd is, zoals Ubuntu, kun je
 
 ### Op een Mac installeren ###
 
-Er zijn twee makkelijke manieren om Git op een Mac te installeren. De simpelste is om het grafische Git installatieprogramma te gebruiken, dat je van de volgende pagina op Google Code kunt downloaden (zie Figuur 1-7):
+Er zijn twee makkelijke manieren om Git op een Mac te installeren. De simpelste is om het grafische Git installatieprogramma te gebruiken, dat je van de volgende pagina op SourceForge kunt downloaden (zie Figuur 1-7):
 
 	http://sourceforge.net/projects/git-osx-installer/
 
diff --git a/nl/02-git-basics/01-chapter2.markdown b/nl/02-git-basics/01-chapter2.markdown
index 53a08a328..2e2a50a51 100644
--- a/nl/02-git-basics/01-chapter2.markdown
+++ b/nl/02-git-basics/01-chapter2.markdown
@@ -33,7 +33,7 @@ vertaling moeten proberen te maken.
 
 Veel succes en plezier bij het vertalen...
 -->
-<!-- SHA-1 of last checked en-version: fbf24105 -->
+<!-- SHA-1 of last checked en-version: 3c18779  -->
 # De basis van Git #
 
 Als je slechts één hoofdstuk kunt lezen om met Git aan de slag te gaan, dan is dit het. In dit hoofdstuk worden alle basiscommando's behandeld, die je nodig hebben om het leeuwendeel van de dingen te doen waarmee je uiteindelijk je tijd met Git zult doorbrengen. Als je dit hoofdstuk doorgenomen hebt, zul je een repository kunnen configureren en initialiseren, bestanden beginnen en stoppen te volgen en veranderingen te ‘stagen’ en ‘committen’. We laten ook zien hoe je Git kunt instellen zodat het bepaalde bestanden en bestandspatronen negeert, hoe je vergissingen snel en gemakkelijk ongedaan kunt maken, hoe je de geschiedenis van je project kan doorlopen en wijzigingen tussen commits kunt zien, en hoe je kunt pushen naar en pullen van repositories.
@@ -669,7 +669,7 @@ Dat gezegd hebbende, zijn de tijd-limiterende opties zoals `--since` en `--until
 
 Dit commando werkt met veel formaten: je kunt een specifieke datum kiezen ("2008-01-15”) of een relatieve datum zoals "2 jaar 1 dag en 3 minuten geleden".
 
-Je kunt ook de lijst met commits filteren op bepaalde criteria. De `--author` optie laat je filteren op een specifieke auteur, en de `--grep` optie laat je op bepaalde zoekwoorden filteren in de commit boodschappen. (Let op dat als je zowel auteur als grep opties wilt specificeren, je `--all-match` moet toevoegen of anders zal het commando ook commits met één van de twee criteria selecteren.)
+Je kunt ook de lijst met commits filteren op bepaalde criteria. De `--author` optie laat je filteren op een specifieke auteur, en de `--grep` optie laat je op bepaalde zoekwoorden filteren in de commit boodschappen. (Let op dat als je zowel auteur als grep opties specificeert het commando commits zal matchen met beide.) Als je meerdere grep opties wilt specificeren, zal je `--all-match` moet toevoegen, anders zal het commando ook commits met één van de twee criteria selecteren.
 
 De laatste echt handige optie om aan `git log` als filter mee te geven is een pad. Als je een directory of bestandsnaam opgeeft, kun je de log output limiteren tot commits die een verandering introduceren op die bestanden. Dit is altijd de laatste optie en wordt over het algemeen vooraf gegaan door dubbele streepjes (`--`) om de paden van de opties te scheiden.
 
diff --git a/nl/06-git-tools/01-chapter6.markdown b/nl/06-git-tools/01-chapter6.markdown
index 292ddbb42..98180e261 100644
--- a/nl/06-git-tools/01-chapter6.markdown
+++ b/nl/06-git-tools/01-chapter6.markdown
@@ -33,7 +33,7 @@ vertaling moeten proberen te maken.
 
 Veel succes en plezier bij het vertalen...
 -->
-<!-- SHA-1 of last checked en-version: fbf24105 -->
+<!-- SHA-1 of last checked en-version: 3c18779  -->
 # Git tools #
 
 Nu heb je de meeste commando's en werkwijzen geleerd die je dagelijks nodig hebt om een Git repository voor je broncode te beheren en te onderhouden. Je hebt de basistaken van het tracken en committen van bestanden onder de knie, en je hebt de kracht van de staging area en lichtgewicht topic branching en mergen in de vingers.
@@ -603,12 +603,19 @@ Dit commando uitvoeren geeft je een lijst met commits in je tekst editor die er
 	#
 	# Commands:
 	#  p, pick = use commit
+	#  r, reword = use commit, but edit the commit message
 	#  e, edit = use commit, but stop for amending
 	#  s, squash = use commit, but meld into previous commit
+	#  f, fixup = like "squash", but discard this commit's log message
+	#  x, exec = run command (the rest of the line) using shell
+	#
+	# These lines can be re-ordered; they are executed from top to bottom.
 	#
 	# If you remove a line here THAT COMMIT WILL BE LOST.
+	#
 	# However, if you remove everything, the rebase will be aborted.
 	#
+	# Note that empty commits are commented out
 
 Het is belangrijk om op te merken dat deze commits in de tegengestelde volgorde getoond worden dan hoe je ze normaliter ziet als je het `log` commando gebruikt. Als je een `log` uitvoert, zie je zoiets als dit:
 
@@ -669,12 +676,19 @@ Het is ook mogelijk een serie commits te pakken en ze in één enkele commit sam
 	#
 	# Commands:
 	#  p, pick = use commit
+	#  r, reword = use commit, but edit the commit message
 	#  e, edit = use commit, but stop for amending
 	#  s, squash = use commit, but meld into previous commit
+	#  f, fixup = like "squash", but discard this commit's log message
+	#  x, exec = run command (the rest of the line) using shell
+	#
+	# These lines can be re-ordered; they are executed from top to bottom.
 	#
 	# If you remove a line here THAT COMMIT WILL BE LOST.
+	#
 	# However, if you remove everything, the rebase will be aborted.
 	#
+	# Note that empty commits are commented out
 
 Als je in plaats van "pick" of "edit", "squash" specificeert zal Git zowel die verandering als de verandering die er direct aan vooraf gaat toepassen, en je dwingen om de commit berichten samen te voegen. Dus als je een enkele commit van deze drie commits wil maken, laat je het script er zo uit zien:
 

From 2b1ac1eba79f83a6b53a2f655c434af32e793409 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Sat, 26 Apr 2014 08:30:35 +0200
Subject: [PATCH 364/690] [it] reviewing chapter 6

reviewed "Branch References"
---
 it/06-git-tools/01-chapter6.markdown | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/it/06-git-tools/01-chapter6.markdown b/it/06-git-tools/01-chapter6.markdown
index b4a41bc62..b8645387a 100644
--- a/it/06-git-tools/01-chapter6.markdown
+++ b/it/06-git-tools/01-chapter6.markdown
@@ -63,14 +63,14 @@ Dovresti comunque essere consapevole che questo sia uno scenario molto improbabi
 
 Ecco un esempio per dare un'idea di cosa ci vorrebbe per ottenere una collisione SHA-1. Se tutti i 6.5 miliardi di esseri umani sulla Terra programmassero e, ogni secondo, ognuno scrivesse codice che sia equivalente all'intera cronologia del kernel Linux (1 milione di oggetti Git) e ne facesse la push su un enorme *repository* Git, ci vorrebbero 5 anni per contenere abbastanza oggetti in quel *repository* per avere il 50% di possibilità di una singola collisione di oggetti SHA-1. Esiste una probabilità più alta che ogni membro del tuo gruppo di sviluppo, in incidenti non correlati venga attaccato e ucciso da dei lupi nella stessa notte.
 
-### Riferimenti alle diramazioni (*branch*) ###
+### Riferimenti alle diramazioni ###
 
-Il modo più diretto per specificare una *commit* è avere un *branch* che vi faccia riferimento, che ti permetterebbe di usare il nome del *branch* in qualsiasi comando Git che richieda un oggetto *commit* o un valore SHA-1. Se vuoi, per esempio, mostrare l'ultima *commit* di un *branch*, i seguenti comandi sono equivalenti, supponendo che il *branch* 'topic1' punti a 'ca82a6d':
+Il modo più diretto per specificare una *commit* è avere una diramazione (*branch* in inglese) che vi faccia riferimento, che ti permetterebbe di usare il nome della diramazione in qualsiasi comando Git che richieda un oggetto *commit* o un valore SHA-1. Se per esempio vuoi vedere l'ultima *commit* di una diramazione, i comandi seguenti sono equivalenti (supponendo che la diramazione 'topic1' punti a 'ca82a6d'):
 
 	$ git show ca82a6dff817ec66f44342007202690a93763949
 	$ git show topic1
 
-Se vuoi vedere a quale SHA specifico punti un *branch*, o se vuoi vedere a quale SHA puntino questi esempi, puoi usare il comando 'rev-parse' di Git, che fa parte dei comandi *plumbing* . Nel Capitolo 9 trovi maggiori informazioni sui comandi *plumbing*: brevemente, 'rev-parse' esiste per operazioni di basso livello e non è concepito per essere usato nelle operazioni quotidiane. Può Comunque essere d'aiuto quando hai bisogno di vedere cosa sta succedendo. Puoi quindi eseguire 'rev-parse' su tuo *branch*.
+Se vuoi vedere a quale SHA specifico punti una diramazione, o se vuoi vedere a quali SHA puntino questi esempi, puoi usare il comando 'rev-parse' di Git, che fa parte dei comandi sottotraccia (*plumbing* in inglese) . Nel Capitolo 9 trovi maggiori informazioni sui comandi sottotraccia ma, brevemente, 'rev-parse' esiste per operazioni di basso livello e non è concepito per essere usato nelle operazioni quotidiane. Può comunque essere d'aiuto quando hai bisogno di vedere cosa sta succedendo davvero. Qui puoi quindi eseguire 'rev-parse' sulla tua diramazione.
 
 	$ git rev-parse topic1
 	ca82a6dff817ec66f44342007202690a93763949

From e79fe76828a5d6eed5bd5f4d7c024b9ca8d4f2c7 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Sat, 26 Apr 2014 08:47:46 +0200
Subject: [PATCH 365/690] [it] reviewing chapter 6

reviewed "RefLog Shortnames"
---
 it/06-git-tools/01-chapter6.markdown | 32 ++++++++++++++--------------
 1 file changed, 16 insertions(+), 16 deletions(-)

diff --git a/it/06-git-tools/01-chapter6.markdown b/it/06-git-tools/01-chapter6.markdown
index b8645387a..b880062ce 100644
--- a/it/06-git-tools/01-chapter6.markdown
+++ b/it/06-git-tools/01-chapter6.markdown
@@ -75,37 +75,37 @@ Se vuoi vedere a quale SHA specifico punti una diramazione, o se vuoi vedere a q
 	$ git rev-parse topic1
 	ca82a6dff817ec66f44342007202690a93763949
 
-### Nomi brevi dei RefLog ###
+### Nomi brevi dei riferimenti ###
 
-Una delle cose che Git fa dietro le quinte è aggiornare il file reflog, che memorizza silenziosamente la posizione negli ultimi mesi del tuo HEAD e dei riferimenti ai tuoi branch , ogni volta che li cambi.
+Una delle cose che Git fa dietro le quinte è aggiornare il registro dei riferimenti (*reflog* in inglese), che registra la posizione dei tuoi riferimenti HEAD e delle diramazione su cui hai lavorato negli ulti mesi.
 
-Puoi consultare il reflog con il comando 'git reflog':
+Puoi consultare il registro con il comando 'git reflog':
 
 	$ git reflog
-	734713b... HEAD@{0}: commit: fixed refs handling, added gc auto, updated
-	d921970... HEAD@{1}: merge phedders/rdocs: Merge made by recursive.
-	1c002dd... HEAD@{2}: commit: added some blame and merge stuff
-	1c36188... HEAD@{3}: rebase -i (squash): updating HEAD
-	95df984... HEAD@{4}: commit: # This is a combination of two commits.
-	1c36188... HEAD@{5}: rebase -i (squash): updating HEAD
-	7e05da5... HEAD@{6}: rebase -i (pick): updating HEAD
+	734713b HEAD@{0}: commit: fixed refs handling, added gc auto, updated
+	d921970 HEAD@{1}: merge phedders/rdocs: Merge made by recursive.
+	1c002dd HEAD@{2}: commit: added some blame and merge stuff
+	1c36188 HEAD@{3}: rebase -i (squash): updating HEAD
+	95df984 HEAD@{4}: commit: # This is a combination of two commits.
+	1c36188 HEAD@{5}: rebase -i (squash): updating HEAD
+	7e05da5 HEAD@{6}: rebase -i (pick): updating HEAD
 
-Ogni volta che un *branch* viene aggiornato per qualsiasi ragione, Git memorizza questa informazione in questa cronologia temporanea. E puoi anche specificare *commit* più vecchie. Se vuoi vedere la cronologia a partire dalla quinta commit più vecchia a partire dalla *HEAD* del tuo *repository*, puoi usare il riferimento '@{n}' che vedi nel *output* di reflog:
+Ogni volta che una diramazione viene aggiornata per qualsiasi ragione, Git memorizza questa informazione in questa cronologia temporanea. E puoi anche specificare *commit* più vecchie. Se vuoi vedere la cronologia a partire dalla quintultima commit a partire dalla *HEAD* del tuo *repository*, puoi usare il riferimento '@{n}' che vedi nel *output* del registro:
 
 	$ git show HEAD@{5}
 
-Puoi usare usare questa sintassi anche per vedere dove era un *branch* a una certa data. Se vuoi vedere, per esempio, dov'era il 'master' *branch* ieri, puoi scrivere:
+Puoi anche usare questa sintassi per vedere dov'era una diramazione a una certa data. Se vuoi vedere, per esempio, dov'era ieri la diramazione 'master' puoi scrivere:
 
 	$ git show master@{yesterday}
 
-Questo mostra dove era il *branch* ieri. Questa tecnica funziona solo per i dati che sono ancora nel *reflog* e non puoi quindi usarla per vedere *commit* più vecchie di qualche mese.
+Che mostra dov'era ieri la diramazione. Questa tecnica funziona solo per i dati che sono ancora nel registri e non puoi quindi usarla per vedere *commit* più vecchie di qualche mese.
 
-Per vedere le informazioni del *reflog* formattate come l’output di '*git log*', puoi eseguire il comando 'git log -g':
+Per vedere le informazioni del registro formattate come l’output di `git log`, puoi eseguire il comando `git log -g`:
 
 	$ git log -g master
 	commit 734713bc047d87bf7eac9674765ae793478c50d3
 	Reflog: master@{0} (Scott Chacon <schacon@gmail.com>)
-	Reflog message: commit: fixed refs handling, added gc auto, updated 
+	Reflog message: commit: fixed refs handling, added gc auto, updated
 	Author: Scott Chacon <schacon@gmail.com>
 	Date:   Fri Jan 2 18:32:33 2009 -0800
 
@@ -119,7 +119,7 @@ Per vedere le informazioni del *reflog* formattate come l’output di '*git log*
 
 	    Merge commit 'phedders/rdocs'
 
-E' importante notare che l'informazione del *reflog* è strettamente locale: è un log di cosa hai fatto nel tuo *repository*. I riferimenti non saranno uguali sui cloni degli altri. Appena dopo aver clonato un *repository* il tuo reflog sarà vuoto perché ancora non hai svolto nessuna attività sul tuo *repository*. Eseguendo 'git show HEAD@{2.months.ago}' funzionerà solo se hai clonato il progetto almeno due mesi fa: se è stato clonato cinque minuti fa non otterrai nessun risultato.
+E' importante notare che l'informazione del registro è solamente locale: è un registro di ciò che hai fatto nel tuo *repository*. I riferimenti non saranno uguali sui cloni degli altri. Appena dopo aver clonato un *repository* il tuo registro sarà vuoto perché non è successo ancora nulla nel tuo *repository*. Potrai eseguire 'git show HEAD@{2.months.ago}' solo se hai clonato il progetto almeno due mesi fa: se è stato clonato cinque minuti fa non otterrai nessun risultato.
 
 ### Riferimenti ancestrali ###
 

From cf7588d0282e964b50516f64a8c6d0a3e8018339 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Sat, 26 Apr 2014 09:15:20 +0200
Subject: [PATCH 366/690] [it] reviewing chapter 6

reviewed "Ancestry References"
---
 it/06-git-tools/01-chapter6.markdown | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/it/06-git-tools/01-chapter6.markdown b/it/06-git-tools/01-chapter6.markdown
index b880062ce..f563490b5 100644
--- a/it/06-git-tools/01-chapter6.markdown
+++ b/it/06-git-tools/01-chapter6.markdown
@@ -123,20 +123,20 @@ E' importante notare che l'informazione del registro è solamente locale: è un
 
 ### Riferimenti ancestrali ###
 
-L'altro modo principale per specificare una *commit* è attraverso i suoi ascendenti. Se metti un `^` alla fine di un riferimento, Git lo risolve interpretandolo come il padre
-padre di quella determinata *commit*. Immagina di guardare la cronologia del tuo progetto:
+L'altro modo principale per specificare una *commit* è attraverso i suoi ascendenti. Se metti un `^` alla fine di un riferimento, Git lo risolve interpretandolo come il padre padre di quella determinata *commit*.
+Immagina di vedere la cronologia del tuo progetto:
 
 	$ git log --pretty=format:'%h %s' --graph
 	* 734713b fixed refs handling, added gc auto, updated tests
 	*   d921970 Merge commit 'phedders/rdocs'
-	|\  
+	|\
 	| * 35cfb2b Some rdoc changes
 	* | 1c002dd added some blame and merge stuff
-	|/  
+	|/
 	* 1c36188 ignore *.gem
 	* 9b29157 add open3_detach to gemspec file list
 
-Puoi quindi vedere la *commit* precedente specificando `HEAD^`, che significa "il genitore di HEAD":
+Puoi quindi vedere la *commit* precedente specificando `HEAD^`, che significa "l'ascendente di HEAD":
 
 	$ git show HEAD^
 	commit d921970aadf03b3cf0e71becdaab3147ba71cdef
@@ -146,7 +146,7 @@ Puoi quindi vedere la *commit* precedente specificando `HEAD^`, che significa "i
 
 	    Merge commit 'phedders/rdocs'
 
-Puoi anche specificare un numero dopo `^`: per esempio `d921970^2` significa "il secondo genitore di d921870." Questa sintassi è utile solo per fare il *merge* di *commit* che hanno più di un genitore. Il primo genitore è il *branch* dove ti trovi al momento del *merge*, e il secondo è la *commit* sul *branch* da cui hai fatto il *merge*:
+Puoi specificare anche un numero dopo la `^`: per esempio `d921970^2` significa "il secondo ascendente di d921870." Questa sintassi è utile solo per incorporare delle *commit* che hanno più di un ascendente. Il primo ascendente è la diramazione dove ti trovi al momento dell'incorporamento, e il secondo è la *commit* sulla diramazione da cui hai fatto l'incorporamento:
 
 	$ git show d921970^
 	commit 1c002dd4b536e7479fe34593e72e6c6c1819e53b
@@ -162,7 +162,7 @@ Puoi anche specificare un numero dopo `^`: per esempio `d921970^2` significa "il
 
 	    Some rdoc changes
 
-Un altro modo riferimento ancestrale è `~`. Questo si riferisce anche al genitore, quindi `HEAD~` e `HEAD^` sono equivalenti. La differenza si nota quando specifichi un numero. `HEAD~2` significa "il genitore del genitore", o "il nonno”: attraversa i primi genitori il numero di volte che specifichi. Per esempio, nella cronologia precedente, `HEAD~3` sarebbe
+Un altro modo di specificare un riferimento ancestrale è la `~`. Questo si riferisce anche al primo ascendente, quindi `HEAD~` e `HEAD^` sono equivalenti. La differenza diventa evidente quando specifichi un numero. `HEAD~2` significa "il primo ascendente del primo ascendente", o "il nonno”: attraversa i primi ascendenti il numero di volte specificato. Per esempio, nella cronologia precedente, `HEAD~3` sarebbe
 
 	$ git show HEAD~3
 	commit 1c3618887afb5fbcbea25b7c013f4e2114448b8d
@@ -171,7 +171,7 @@ Un altro modo riferimento ancestrale è `~`. Questo si riferisce anche al genito
 
 	    ignore *.gem
 
-Che può anche essere scritto come `HEAD^^^` che, di nuovo, è sempre il genitore del genitore del genitore:
+Che può essere scritto anche come `HEAD^^^` che, di nuovo, è sempre il primo genitore del primo genitore del primo genitore:
 
 	$ git show HEAD^^^
 	commit 1c3618887afb5fbcbea25b7c013f4e2114448b8d
@@ -180,7 +180,7 @@ Che può anche essere scritto come `HEAD^^^` che, di nuovo, è sempre il genitor
 
 	    ignore *.gem
 
-È anche possibile combinare queste sintassi: puoi prendere il nonno del riferimento precedente (assumendo che si tratti di una commit di *merge*) usando `HEAD~3^2`, e così via.
+È anche possibile combinare queste sintassi: puoi prendere il secondo genitore del riferimento precedente (assumendo che si tratti di una commit d'incorporamento) usando `HEAD~3^2`, e così via.
 
 ### Intervalli di Commit ###
 

From cbd79b5fb75a83775c3f2dfb5a3ec7a8d48ff892 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Sat, 26 Apr 2014 09:18:08 +0200
Subject: [PATCH 367/690] [it] reviewing chapter 6

Reviewed "Commit Ranges"
---
 it/06-git-tools/01-chapter6.markdown | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/it/06-git-tools/01-chapter6.markdown b/it/06-git-tools/01-chapter6.markdown
index f563490b5..5cbcab10c 100644
--- a/it/06-git-tools/01-chapter6.markdown
+++ b/it/06-git-tools/01-chapter6.markdown
@@ -182,9 +182,9 @@ Che può essere scritto anche come `HEAD^^^` che, di nuovo, è sempre il primo g
 
 È anche possibile combinare queste sintassi: puoi prendere il secondo genitore del riferimento precedente (assumendo che si tratti di una commit d'incorporamento) usando `HEAD~3^2`, e così via.
 
-### Intervalli di Commit ###
+### Intervalli di commit ###
 
-Ora che sai come specificare delle commit singole, vediamo come specificare intervalli di commit. Ciò è particolarmente utile per gestire i tuoi branch: se hai molti branch puoi usare gli intervalli per rispondere a domande come “cosa c’è nel tuo branch di cui io non ho ancora fatto il merge?”
+Ora che sai come specificare singole commit, vediamo come specificare intervalli di commit. Ciò è particolarmente utile per gestire le tue diramazioni: se ne hai molte puoi usare gli intervalli per rispondere a domande come “cosa c’è in questa diramazione che non ho ancora incorporato?”
 
 #### Due punti ####
 

From 789f2c4a905c9ce8d5973746966fde34df78bc18 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Sat, 26 Apr 2014 09:36:09 +0200
Subject: [PATCH 368/690] [it] reviewing chapter 6

---
 it/06-git-tools/01-chapter6.markdown | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/it/06-git-tools/01-chapter6.markdown b/it/06-git-tools/01-chapter6.markdown
index 5cbcab10c..77627ec20 100644
--- a/it/06-git-tools/01-chapter6.markdown
+++ b/it/06-git-tools/01-chapter6.markdown
@@ -188,24 +188,24 @@ Ora che sai come specificare singole commit, vediamo come specificare intervalli
 
 #### Due punti ####
 
-Il modo più comune per specificare un intervallo è con i due punti che, praticamente, chiedono a Git di risolvere l’intervallo tra commit che sia raggiungibile da una commit, ma che non sia raggiungibile dall’altra. Per esempio, immaginiamo di avere una cronologia come nell’immagine 6-1
+Il modo più comune per specificare un intervallo è con i due punti che, praticamente, chiede a Git di risolvere l’intervallo tra commit che sia raggiungibile da una commit, ma non dall’altra. Immaginiamo di avere la cronologia dell’immagine 6-1
 
 Insert 18333fig0601.png
-Figure 6-1. Esempio di cronologia per selezione di intervalli.
+Figure 6-1. Esempio di cronologia per la selezione di intervalli.
 
-Vuoi vedere cosa sia nel tuo branch sperimentale che non sia ancora stato incluso nel branch master: puoi chiedere a Git di mostrarti il log esclusivamente di quelle commit con `master..experiment`: questo significa “tutte le commit raggiungibili da experiment che non siano raggiungibili da master”. Affinché questi esempi siano sintetici ma chiari, invece del log effettivamente scritto da Git, userò le lettere degli oggetti commit del diagramma:
+Vuoi vedere cosa sia nella tua diramazione sperimentale che non sia ancora stato incorporato nella master: puoi chiedere a Git di mostrarti solo il registro delle commit con `master..experiment`: questo significa “tutte le commit raggiungibili da experiment che non lo siano da master”. Affinché questi esempi siano sintetici ma chiari, invece del registro effettivo di Git, userò le lettere degli oggetti commit del diagramma:
 
 	$ git log master..experiment
 	D
 	C
 
-Se, invece vuoi vedere il contrario, ovvero tutte le commit in `master` che non siano in `experiment`, puoi invertire i nomi dei branch: `experiment..master` ti mostra tutto ciò che è in `master` e che non sia raggiungibile da `experiment`:
+Se volessi invece vedere il contrario, ovvero tutte le commit in `master` che non siano in `experiment`, puoi invertire i nomi dei branch: `experiment..master` ti mostra tutto ciò che è in `master` e che non sia raggiungibile da `experiment`:
 
 	$ git log experiment..master
 	F
 	E
 
-Questo è utile se vuoi mantenere il branch `experiment` aggiornato e sapere di cosa stai per fare il merge. Un’altro caso in cui si usa spesso questa sintassi è quando stai per fare una push verso un repository remoto:
+Questo è utile se vuoi mantenere aggiornata la diramazione `experiment` e sapere cosa stai per incorporare. Un’altro caso in cui si usa spesso questa sintassi è quando stai per condividere delle commit verso un repository remoto:
 
 	$ git log origin/master..HEAD
 

From 2372519a32489886f1130fe023a40106e22c20e3 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Sat, 26 Apr 2014 09:40:16 +0200
Subject: [PATCH 369/690] [it] reviewing chapter 6

Reviewed "Double Dot"
---
 it/06-git-tools/01-chapter6.markdown | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/it/06-git-tools/01-chapter6.markdown b/it/06-git-tools/01-chapter6.markdown
index 77627ec20..88091bfe7 100644
--- a/it/06-git-tools/01-chapter6.markdown
+++ b/it/06-git-tools/01-chapter6.markdown
@@ -209,8 +209,8 @@ Questo è utile se vuoi mantenere aggiornata la diramazione `experiment` e saper
 
 	$ git log origin/master..HEAD
 
-Questo comando mostra tutte le commit nel tuo branch che non sono nel branch `master` del tuo repository remoto `origin`. Se esegui `git push` quando il tuo branch è associato a `origin/master`, le commit elencate da `git log origin/master..HEAD` saranno le commit che saranno inviate al server.
-Puoi anche omettere una delle parti della sintassi, e Git assumerà che sia HEAD. Puoi per esempio ottenere lo stesso risultato dell’esempio precedente scrivendo `git log origin/master..`: Git sostituisce la parte mancante con HEAD.
+Questo comando mostra tutte le commit della tua diramazione che non sono in quella `master` del tuo repository remoto `origin`. Se esegui `git push` quando la tua diramazione attuale è associata a `origin/master`, le commit elencate da `git log origin/master..HEAD` saranno quelle che saranno inviate al server.
+Puoi anche omettere una delle parti della sintassi, e Git assumerà che sia HEAD. Per esempio puoi ottenere lo stesso risultato dell’esempio precedente scrivendo `git log origin/master..`: Git sostituisce la parte mancante con HEAD.
 
 #### Punti multipli ####
 

From 403a1f7ec771a5f77b2a5c4ecc5db13ee3b51b7a Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Sat, 26 Apr 2014 09:45:51 +0200
Subject: [PATCH 370/690] [it] reviewing chapter 6

Multiple Points
---
 it/06-git-tools/01-chapter6.markdown | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/it/06-git-tools/01-chapter6.markdown b/it/06-git-tools/01-chapter6.markdown
index 88091bfe7..b32bace39 100644
--- a/it/06-git-tools/01-chapter6.markdown
+++ b/it/06-git-tools/01-chapter6.markdown
@@ -214,18 +214,18 @@ Puoi anche omettere una delle parti della sintassi, e Git assumerà che sia HEAD
 
 #### Punti multipli ####
 
-La sintassi dei due punti è utile come la stenografia, ma potresti voler specificare più di due branch, così come vedere le commit che sono nei vari branch e che non sono nel tuo branch attuale. Git ti permette di farlo sia con il carattere `^` che con l’opzione `--not` prima di ciascun riferimento del quale vuoi vedere le commit non raggiungibili. Quindi questi tre comandi sono equivalenti:
+La sintassi dei due punti è utile come la stenografia, ma potresti voler specificare più di due branch per indicare la tua revisione, per vedere le commit che sono nelle varie diramazioni che non siano in quella attuale. Git ti permette di farlo sia con `^` che con l’opzione `--not` prima di ciascun riferimento del quale vuoi vedere le commit raggiungibili. Quindi questi tre comandi sono equivalenti:
 
 	$ git log refA..refB
 	$ git log ^refA refB
 	$ git log refB --not refA
 
-Questo è interessante, perché con questa sintassi puoi specificare più di due riferimenti nella tua query, cosa che non puoi fare con i due punti. Se per esempio vuoi vedere tutte le commit che siano raggiungibili da `refA` o da `refB` ma non da `refC` puoi usare una delle seguenti alternative:
+Questo è interessante, perché con questa sintassi puoi specificare più di due riferimenti nella tua richiesta, cosa che non puoi fare con i due punti. Se per esempio vuoi vedere tutte le commit che siano raggiungibili da `refA` o da `refB` ma non da `refC` puoi usare una delle seguenti alternative:
 
 	$ git log refA refB ^refC
 	$ git log refA refB --not refC
 
-Questo la rende un sistema potente di query di revisione che dovrebbe aiutarti a capire cosa c’è nei tuo branch.
+Questo produce un sistema di revisione molto potente che dovrebbe aiutarti a capire cosa c’è nelle tue diramazioni.
 
 #### Tre punti ####
 

From d01b230a62fa1c363b410cec2cce2151d419cf0c Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Sat, 26 Apr 2014 09:58:42 +0200
Subject: [PATCH 371/690] [it] reviewing chapter 6

Triple Dot
---
 it/06-git-tools/01-chapter6.markdown | 11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/it/06-git-tools/01-chapter6.markdown b/it/06-git-tools/01-chapter6.markdown
index b32bace39..c476abec0 100644
--- a/it/06-git-tools/01-chapter6.markdown
+++ b/it/06-git-tools/01-chapter6.markdown
@@ -229,8 +229,8 @@ Questo produce un sistema di revisione molto potente che dovrebbe aiutarti a cap
 
 #### Tre punti ####
 
-L’ultima sintassi per la selezione di intervalli è quella dei tre punti che indica tutte le commit raggiungibili da ciascuno dei riferimenti ma non da entrambi. Rivedi la cronologia delle commit nella Figura 6-1.
-Se vuoi vedere cosa sia in `master` o in `experiment` ma non i riferimenti comuni puoi eseguire questo comando
+L’ultima sintassi per la selezione di intervalli è quella dei tre punti, che indica tutte le commit raggiungibili da uno qualsiasi dei riferimenti ma non da entrambi. Rivedi la cronologia delle commit nella Figura 6-1.
+Se vuoi vedere cosa ci sia nel `master` o in `experiment` ma non i riferimenti comuni, puoi eseguire
 
 	$ git log master...experiment
 	F
@@ -238,9 +238,10 @@ Se vuoi vedere cosa sia in `master` o in `experiment` ma non i riferimenti comun
 	D
 	C
 
-Che ti mostra l’output normale del *log*, ma solo con le informazioni di quelle quattro commit nel solito ordinamento cronologico.
+Che ti mostra l’output normale del `log` mostrando solo le informazioni di quelle quattro commit nell'ordinamento cronologico normale.
 
-In questo è comune usare il parametro `--left-right` con il comando `log`, che mostra da che parte è la commit nell’intervallo selezionato, che rende i dati molto più utili:
+
+Un'opzione comunemente usata in questi casi con il comando `log` è il parametro `--left-right`, che mostra da che lato dell'intervallo si trovi ciascuna commit dell’intervallo selezionato, che rende le informazioni molto più utili:
 
 	$ git log --left-right master...experiment
 	< F
@@ -248,7 +249,7 @@ In questo è comune usare il parametro `--left-right` con il comando `log`, che
 	> D
 	> C
 
-Con questi strumenti puoi dire facilmente a Git quale o quali commit vuoi ispezionare.
+Con questi strumenti puoi dire facilmente a Git quali commit vuoi ispezionare.
 <!-- da tradurre fino a riga 840 -->
 ## Interactive Staging ##
 

From 76aede3d62ba030fb68c459f4fcdb63d6b639b43 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Sat, 26 Apr 2014 11:02:45 +0200
Subject: [PATCH 372/690] [it] reviewing chapter 6

removed blank line
---
 it/06-git-tools/01-chapter6.markdown | 1 -
 1 file changed, 1 deletion(-)

diff --git a/it/06-git-tools/01-chapter6.markdown b/it/06-git-tools/01-chapter6.markdown
index c476abec0..6eb441140 100644
--- a/it/06-git-tools/01-chapter6.markdown
+++ b/it/06-git-tools/01-chapter6.markdown
@@ -240,7 +240,6 @@ Se vuoi vedere cosa ci sia nel `master` o in `experiment` ma non i riferimenti c
 
 Che ti mostra l’output normale del `log` mostrando solo le informazioni di quelle quattro commit nell'ordinamento cronologico normale.
 
-
 Un'opzione comunemente usata in questi casi con il comando `log` è il parametro `--left-right`, che mostra da che lato dell'intervallo si trovi ciascuna commit dell’intervallo selezionato, che rende le informazioni molto più utili:
 
 	$ git log --left-right master...experiment

From d7c6dd41aec05b5467c078a55195c559444e7171 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Sat, 26 Apr 2014 11:12:58 +0200
Subject: [PATCH 373/690] [it] translating chapter 6

Translated "Interactive Staging"
---
 it/06-git-tools/01-chapter6.markdown | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/it/06-git-tools/01-chapter6.markdown b/it/06-git-tools/01-chapter6.markdown
index 6eb441140..4aa372668 100644
--- a/it/06-git-tools/01-chapter6.markdown
+++ b/it/06-git-tools/01-chapter6.markdown
@@ -249,11 +249,11 @@ Un'opzione comunemente usata in questi casi con il comando `log` è il parametro
 	> C
 
 Con questi strumenti puoi dire facilmente a Git quali commit vuoi ispezionare.
-<!-- da tradurre fino a riga 840 -->
-## Interactive Staging ##
 
-Git comes with a couple of scripts that make some command-line tasks easier. Here, you’ll look at a few interactive commands that can help you easily craft your commits to include only certain combinations and parts of files. These tools are very helpful if you modify a bunch of files and then decide that you want those changes to be in several focused commits rather than one big messy commit. This way, you can make sure your commits are logically separate changesets and can be easily reviewed by the developers working with you.
-If you run `git add` with the `-i` or `--interactive` option, Git goes into an interactive shell mode, displaying something like this:
+## Assemblaggio interattivo ##
+
+Git viene distribuito con un paio di script che rendono più semplice l'uso della riga di comando. In questo capitolo vedremo alcuni comandi interattivi che possono aiutarti a modellare le tue commit perché includano solo determinate combinazioni di parti dei file. Questi strumenti sono molto utili se modifichi molti file tutti assieme e poi decidi che vuoi distribuire le modifiche in più commit puntuali, piuttosto che un'unica grossa commit confusa. In questo modo puoi fare che le tue commit separino logicamente le tue modifiche e possano essere facilmente revisionate dagli altri sviluppatori con cui lavori.
+Se esegui `git add` con le opzioni `-i` o `--interactive`, Git entrerà nella modalità interattiva, mostrandoti qualcosa del genere:
 
 	$ git add -i
 	           staged     unstaged path
@@ -266,10 +266,10 @@ If you run `git add` with the `-i` or `--interactive` option, Git goes into an i
 	  5: patch      6: diff        7: quit       8: help
 	What now>
 
-You can see that this command shows you a much different view of your staging area — basically the same information you get with `git status` but a bit more succinct and informative. It lists the changes you’ve staged on the left and unstaged changes on the right.
-
-After this comes a Commands section. Here you can do a number of things, including staging files, unstaging files, staging parts of files, adding untracked files, and seeing diffs of what has been staged.
+Come vedi, questo comando mostra una vista della tua area di assemblaggio molto diversa: sono le stesse informazioni che otterà con il comando `git status`, ma in maniera più succinta e con più informazioni. Sulla sinistra mostra le modifiche che stai assemblando e quelle non ancora assemblate sulla destra.
 
+Dopo questa sezione c'è quella dei Comandi. Qui puoi fare una serie di cose, incluso assemblare file, disassemblarli, assemblare alcune parti dei file, aggiungere file non ancora tracciati e vedere le differenze con ciò che è già stato assemblato.
+<!-- da tradurre fino a riga 840 -->
 ### Staging and Unstaging Files ###
 
 If you type `2` or `u` at the `What now>` prompt, the script prompts you for which files you want to stage:

From 1fe99a39138c2b23f353cf83b99596e10db44fa8 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Sat, 26 Apr 2014 11:28:20 +0200
Subject: [PATCH 374/690] [it] translating chapter 6

Translated "Staging and Unstaging Files"
---
 it/06-git-tools/01-chapter6.markdown | 20 ++++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/it/06-git-tools/01-chapter6.markdown b/it/06-git-tools/01-chapter6.markdown
index 4aa372668..ec612ec27 100644
--- a/it/06-git-tools/01-chapter6.markdown
+++ b/it/06-git-tools/01-chapter6.markdown
@@ -269,10 +269,10 @@ Se esegui `git add` con le opzioni `-i` o `--interactive`, Git entrerà nella mo
 Come vedi, questo comando mostra una vista della tua area di assemblaggio molto diversa: sono le stesse informazioni che otterà con il comando `git status`, ma in maniera più succinta e con più informazioni. Sulla sinistra mostra le modifiche che stai assemblando e quelle non ancora assemblate sulla destra.
 
 Dopo questa sezione c'è quella dei Comandi. Qui puoi fare una serie di cose, incluso assemblare file, disassemblarli, assemblare alcune parti dei file, aggiungere file non ancora tracciati e vedere le differenze con ciò che è già stato assemblato.
-<!-- da tradurre fino a riga 840 -->
-### Staging and Unstaging Files ###
 
-If you type `2` or `u` at the `What now>` prompt, the script prompts you for which files you want to stage:
+### Assemblare e disassemblare file ###
+
+Se digiti `2` o `u` alla richiesta `What now>`, lo script ti chiederà quale file vuoi assemblare:
 
 	What now> 2
 	           staged     unstaged path
@@ -281,7 +281,7 @@ If you type `2` or `u` at the `What now>` prompt, the script prompts you for whi
 	  3:    unchanged        +5/-1 lib/simplegit.rb
 	Update>>
 
-To stage the TODO and index.html files, you can type the numbers:
+Per assemblare i file TODO e index.html, puoi digitare i numeri:
 
 	Update>> 1,2
 	           staged     unstaged path
@@ -290,7 +290,7 @@ To stage the TODO and index.html files, you can type the numbers:
 	  3:    unchanged        +5/-1 lib/simplegit.rb
 	Update>>
 
-The `*` next to each file means the file is selected to be staged. If you press Enter after typing nothing at the `Update>>` prompt, Git takes anything selected and stages it for you:
+L'asterisco (`*`) vicino a ogni file, significa che è stato selezionato per essere assemblato. Se premi INVIO alla richiesta `Update>>`, Git assembla tutto ciò che è stato selezionato:
 
 	Update>>
 	updated 2 paths
@@ -304,7 +304,7 @@ The `*` next to each file means the file is selected to be staged. If you press
 	  2:        +1/-1      nothing index.html
 	  3:    unchanged        +5/-1 lib/simplegit.rb
 
-Now you can see that the TODO and index.html files are staged and the simplegit.rb file is still unstaged. If you want to unstage the TODO file at this point, you use the `3` or `r` (for revert) option:
+Ora puoi vedere che i file TODO e index.html sono assemblati e simplegit.rb non lo è ancora. Se ora vuoi disassemblare il file TODO, devi digitare `3` o `r` (come `revert` - annullare):
 
 	*** Commands ***
 	  1: status     2: update      3: revert     4: add untracked
@@ -322,7 +322,7 @@ Now you can see that the TODO and index.html files are staged and the simplegit.
 	Revert>> [enter]
 	reverted one path
 
-Looking at your Git status again, you can see that you’ve unstaged the TODO file:
+Rivedendo lo stato di Git, puoi vedere che hai disassemblato il file TODO:
 
 	*** Commands ***
 	  1: status     2: update      3: revert     4: add untracked
@@ -333,7 +333,7 @@ Looking at your Git status again, you can see that you’ve unstaged the TODO fi
 	  2:        +1/-1      nothing index.html
 	  3:    unchanged        +5/-1 lib/simplegit.rb
 
-To see the diff of what you’ve staged, you can use the `6` or `d` (for diff) command. It shows you a list of your staged files, and you can select the ones for which you would like to see the staged diff. This is much like specifying `git diff --cached` on the command line:
+Per vedere le differenze di ciò che hai assemblato puoi digitare `6` o `d` (come differenza). Ti mostrerà un elenco dei tuoi file assemblati, e potrai selezionare quelli di cui vuoi vedere le modifiche assemblate. Questo fa la stessa cosa del comando `git diff --cached`:
 
 	*** Commands ***
 	  1: status     2: update      3: revert     4: add untracked
@@ -355,8 +355,8 @@ To see the diff of what you’ve staged, you can use the `6` or `d` (for diff) c
 
 	 <script type="text/javascript">
 
-With these basic commands, you can use the interactive add mode to deal with your staging area a little more easily.
-
+Con questi comandi elementari puoi usare la modalità interattiva per interaggire un po' più facilmente con l'area di assemblagio.
+<!-- da tradurre fino a riga 840 -->
 ### Staging Patches ###
 
 It’s also possible for Git to stage certain parts of files and not the rest. For example, if you make two changes to your simplegit.rb file and want to stage one of them and not the other, doing so is very easy in Git. From the interactive prompt, type `5` or `p` (for patch). Git will ask you which files you would like to partially stage; then, for each section of the selected files, it will display hunks of the file diff and ask if you would like to stage them, one by one:

From 2f8a74969aa55e6941b9680e867d86faf7672bfe Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Sat, 26 Apr 2014 14:03:01 +0200
Subject: [PATCH 375/690] [it] reviewing chapter 6

changed "staging area" with "area di assemblaggio"
---
 it/06-git-tools/01-chapter6.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/it/06-git-tools/01-chapter6.markdown b/it/06-git-tools/01-chapter6.markdown
index ec612ec27..523ab69a5 100644
--- a/it/06-git-tools/01-chapter6.markdown
+++ b/it/06-git-tools/01-chapter6.markdown
@@ -1,6 +1,6 @@
 # Strumenti di Git #
 
-Finora hai imparato la maggior parte dei comandi d’uso quotidiani e i flussi di lavoro che devi conoscere per gestire o mantenere un repository Git per i tuoi sorgenti. Hai eseguito le attività di base per tracciare e committare i file, hai sfruttato il potere dell' *area di staging* e le diramazioni (*branch*) e le unioni (*merge*) leggere.
+Finora hai imparato la maggior parte dei comandi d’uso quotidiani e i flussi di lavoro che devi conoscere per gestire o mantenere un repository Git per i tuoi sorgenti. Hai eseguito le attività di base per tracciare e committare i file, hai sfruttato il potere dell' *area di assemblamento* e le diramazioni (*branch*) e le unioni (*merge*) leggere.
 
 Ora vedremo una serie di cose molto potenti di Git che potresti non usare quotidianamente, ma di cui a un certo punto potresti averne bisogno.
 

From 690556d08f80643ce15a127d8146514a3bd20eab Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Sat, 26 Apr 2014 14:50:43 +0200
Subject: [PATCH 376/690] [it] translated chapter 6

Staging Patches
---
 it/06-git-tools/01-chapter6.markdown | 48 ++++++++++++++--------------
 1 file changed, 24 insertions(+), 24 deletions(-)

diff --git a/it/06-git-tools/01-chapter6.markdown b/it/06-git-tools/01-chapter6.markdown
index 523ab69a5..b5fb84d42 100644
--- a/it/06-git-tools/01-chapter6.markdown
+++ b/it/06-git-tools/01-chapter6.markdown
@@ -356,10 +356,10 @@ Per vedere le differenze di ciò che hai assemblato puoi digitare `6` o `d` (com
 	 <script type="text/javascript">
 
 Con questi comandi elementari puoi usare la modalità interattiva per interaggire un po' più facilmente con l'area di assemblagio.
-<!-- da tradurre fino a riga 840 -->
-### Staging Patches ###
 
-It’s also possible for Git to stage certain parts of files and not the rest. For example, if you make two changes to your simplegit.rb file and want to stage one of them and not the other, doing so is very easy in Git. From the interactive prompt, type `5` or `p` (for patch). Git will ask you which files you would like to partially stage; then, for each section of the selected files, it will display hunks of the file diff and ask if you would like to stage them, one by one:
+### Assemblare i pezzi ###
+
+Git può anche assemblare solo alcune parti di un file e non il resto. Se per esempio fai due modifiche al tuo simplegit.rb file e vuoi assemblarne solo una, con Git puoi farlo molto semplicemente. Al `prompt` digita `5` o `p` (come pezzo, `patch` ndt). Git ti chiederà quali file vuoi assemblare parzialmente e, per ciascuna sezione dei file selezionati, mostrerà blocchi di differenze chiedendoti se vuoi assemblarle, una per una:
 
 	diff --git a/lib/simplegit.rb b/lib/simplegit.rb
 	index dd5ecc4..57399e0 100644
@@ -376,24 +376,24 @@ It’s also possible for Git to stage certain parts of files and not the rest. F
 	   def blame(path)
 	Stage this hunk [y,n,a,d,/,j,J,g,e,?]?
 
-You have a lot of options at this point. Typing `?` shows a list of what you can do:
-
-	Stage this hunk [y,n,a,d,/,j,J,g,e,?]? ?
-	y - stage this hunk
-	n - do not stage this hunk
-	a - stage this and all the remaining hunks in the file
-	d - do not stage this hunk nor any of the remaining hunks in the file
-	g - select a hunk to go to
-	/ - search for a hunk matching the given regex
-	j - leave this hunk undecided, see next undecided hunk
-	J - leave this hunk undecided, see next hunk
-	k - leave this hunk undecided, see previous undecided hunk
-	K - leave this hunk undecided, see previous hunk
-	s - split the current hunk into smaller hunks
-	e - manually edit the current hunk
-	? - print help
-
-Generally, you’ll type `y` or `n` if you want to stage each hunk, but staging all of them in certain files or skipping a hunk decision until later can be helpful too. If you stage one part of the file and leave another part unstaged, your status output will look like this:
+A questo punto hai molte opzioni. Digitando `?` vedrai la lista di ciò che puoi fare:
+
+	Assemblare questo blocco [y,n,a,d,/,j,J,g,e,?]? ?
+	y - assembla questo blocco
+	n - non assemblare questo blocco
+	a - assembla questo blocco e tutti gli altri rimanenti nel file
+	d - non assemblare questo blocco né gli altri rimanenti nel file
+	g - seleziona un blocco per continuare
+	/ - cerca un blocco con una regex
+	j - salta questo blocco e vedi il successivo saltato
+	J - salta questo blocco e vedi il prossimo blocco
+	k - salta questo blocco e vedi il precedente saltato
+	K - salta questo blocco e vedi il blocco precedente
+	s - dividi il blocco attuale in blocchi più piccoli
+	e - modifica manualmente il blocco attuale
+	? - mostra l'aiuto
+
+Generalmente digiterai `y` o `n` se vuoi assemblare tutti i blocchi, ma assemblare tutti quelli di un file o saltarne qualcuno per decidere in un secondo momento può essere molto prezioso. Se assembli solo alcuni blocchi di un file ma non gli altri, lo stato del tuo repository sarà così:
 
 	What now> 1
 	           staged     unstaged path
@@ -401,10 +401,10 @@ Generally, you’ll type `y` or `n` if you want to stage each hunk, but staging
 	  2:        +1/-1      nothing index.html
 	  3:        +1/-1        +4/-0 lib/simplegit.rb
 
-The status of the simplegit.rb file is interesting. It shows you that a couple of lines are staged and a couple are unstaged. You’ve partially staged this file. At this point, you can exit the interactive adding script and run `git commit` to commit the partially staged files.
-
-Finally, you don’t need to be in interactive add mode to do the partial-file staging — you can start the same script by using `git add -p` or `git add --patch` on the command line.
+È interessante lo stato di simplegit.rb, dove alcune righe sono assemblate ma non le altre. Hai assemblato parzialmente questo file. A questo punto puoi uscire dall'area interattiva ed eseguire `git commit` per committare la parte di file assemblata.
 
+Non devi essere nell'area interattiva per assemblare solo una parte di un file: puoi avviare lo stesso script dalla riga di comando con `git add -p` o `git add --patch`.
+<!-- da tradurre fino a riga 840 -->
 ## Stashing ##
 
 Often, when you’ve been working on part of your project, things are in a messy state and you want to switch branches for a bit to work on something else. The problem is, you don’t want to do a commit of half-done work just so you can get back to this point later. The answer to this issue is the `git stash` command.

From e112cb7e38c7a433a96197cb248791ccd29468eb Mon Sep 17 00:00:00 2001
From: Jean-Noel Avila <jean-noel.avila@scantech.fr>
Date: Sat, 26 Apr 2014 15:33:41 +0200
Subject: [PATCH 377/690] Bump Maruku required version to 0.7.1

---
 Gemfile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Gemfile b/Gemfile
index aa6b79223..59fd845ae 100644
--- a/Gemfile
+++ b/Gemfile
@@ -1,5 +1,5 @@
 source 'https://rubygems.org'
 
-gem 'maruku', '0.6.1'
+gem 'maruku', '0.7.1'
 gem 'redcarpet'
 gem 'parallel'

From fc637787340353c5f1f020b1281fc98e58c048d9 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Sat, 26 Apr 2014 15:53:04 +0200
Subject: [PATCH 378/690] [it] translating chapter 6

Translated "Stashing"
---
 it/06-git-tools/01-chapter6.markdown | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/it/06-git-tools/01-chapter6.markdown b/it/06-git-tools/01-chapter6.markdown
index b5fb84d42..481d42072 100644
--- a/it/06-git-tools/01-chapter6.markdown
+++ b/it/06-git-tools/01-chapter6.markdown
@@ -404,13 +404,13 @@ Generalmente digiterai `y` o `n` se vuoi assemblare tutti i blocchi, ma assembla
 È interessante lo stato di simplegit.rb, dove alcune righe sono assemblate ma non le altre. Hai assemblato parzialmente questo file. A questo punto puoi uscire dall'area interattiva ed eseguire `git commit` per committare la parte di file assemblata.
 
 Non devi essere nell'area interattiva per assemblare solo una parte di un file: puoi avviare lo stesso script dalla riga di comando con `git add -p` o `git add --patch`.
-<!-- da tradurre fino a riga 840 -->
-## Stashing ##
 
-Often, when you’ve been working on part of your project, things are in a messy state and you want to switch branches for a bit to work on something else. The problem is, you don’t want to do a commit of half-done work just so you can get back to this point later. The answer to this issue is the `git stash` command.
+## Riporre ##
 
-Stashing takes the dirty state of your working directory — that is, your modified tracked files and staged changes — and saves it on a stack of unfinished changes that you can reapply at any time.
+Spesso, mentre stai lavorando ad una parte del tuo progetto, le cose possono essere in uno stato confusionario e tu vuoi passare a un'altra ramificazione per lavorare per un po' a qualcosa di diverso. Il problema è che non vuoi committare qualcosa fatta a metà per poi tornarci in un secondo momento. La risposta a questo problema è il comando `git stash`.
 
+Questo comando prende tutte le modifiche della tua cartella di lavoro — cioè tutti i file tracciati che hai modificato e le modifiche assemblate — e le salva in una pila di modifiche incomplete che puoi riapplicare in qualsiasi momento.
+<!-- da tradurre fino a riga 840 -->
 ### Stashing Your Work ###
 
 To demonstrate, you’ll go into your project and start working on a couple of files and possibly stage one of the changes. If you run `git status`, you can see your dirty state:

From 9c4252b492885aabe41346148d589b480e753a60 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Sat, 26 Apr 2014 16:17:44 +0200
Subject: [PATCH 379/690] updating 'git stash list' output

---
 en/06-git-tools/01-chapter6.markdown | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/en/06-git-tools/01-chapter6.markdown b/en/06-git-tools/01-chapter6.markdown
index 78578a93b..f5b10d700 100644
--- a/en/06-git-tools/01-chapter6.markdown
+++ b/en/06-git-tools/01-chapter6.markdown
@@ -446,8 +446,8 @@ At this point, you can easily switch branches and do work elsewhere; your change
 
 	$ git stash list
 	stash@{0}: WIP on master: 049d078 added the index file
-	stash@{1}: WIP on master: c264051... Revert "added file_size"
-	stash@{2}: WIP on master: 21d80a5... added number to log
+	stash@{1}: WIP on master: c264051 Revert "added file_size"
+	stash@{2}: WIP on master: 21d80a5 added number to log
 
 In this case, two stashes were done previously, so you have access to three different stashed works. You can reapply the one you just stashed by using the command shown in the help output of the original stash command: `git stash apply`. If you want to apply one of the older stashes, you can specify it by naming it, like this: `git stash apply stash@{2}`. If you don’t specify a stash, Git assumes the most recent stash and tries to apply it:
 

From 6359d5e166bab56b170054bb74c529bc63dd9bc9 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Sat, 26 Apr 2014 17:41:49 +0200
Subject: [PATCH 380/690] [it] translating chapter 6

Translated "Stashing Your Work"
---
 it/06-git-tools/01-chapter6.markdown | 36 ++++++++++++++--------------
 1 file changed, 18 insertions(+), 18 deletions(-)

diff --git a/it/06-git-tools/01-chapter6.markdown b/it/06-git-tools/01-chapter6.markdown
index 481d42072..b62a1a74f 100644
--- a/it/06-git-tools/01-chapter6.markdown
+++ b/it/06-git-tools/01-chapter6.markdown
@@ -405,15 +405,15 @@ Generalmente digiterai `y` o `n` se vuoi assemblare tutti i blocchi, ma assembla
 
 Non devi essere nell'area interattiva per assemblare solo una parte di un file: puoi avviare lo stesso script dalla riga di comando con `git add -p` o `git add --patch`.
 
-## Riporre ##
+## Accantonare ##
 
 Spesso, mentre stai lavorando ad una parte del tuo progetto, le cose possono essere in uno stato confusionario e tu vuoi passare a un'altra ramificazione per lavorare per un po' a qualcosa di diverso. Il problema è che non vuoi committare qualcosa fatta a metà per poi tornarci in un secondo momento. La risposta a questo problema è il comando `git stash`.
 
-Questo comando prende tutte le modifiche della tua cartella di lavoro — cioè tutti i file tracciati che hai modificato e le modifiche assemblate — e le salva in una pila di modifiche incomplete che puoi riapplicare in qualsiasi momento.
-<!-- da tradurre fino a riga 840 -->
-### Stashing Your Work ###
+Questo comando prende tutte le modifiche della tua cartella di lavoro — cioè tutti i file tracciati che hai modificato e le modifiche assemblate — e le accantona in una pila di modifiche incomplete che puoi riapplicare in qualsiasi momento.
+
+### Accantona il tuo lavoro ###
 
-To demonstrate, you’ll go into your project and start working on a couple of files and possibly stage one of the changes. If you run `git status`, you can see your dirty state:
+Per dimostrare come funziona, vai nella cartella del tuo progetto e modifica un paio di file e assemblane alcuni. Se esegui `git status`, puoi vederne lo stato "sporco":
 
 	$ git status
 	# On branch master
@@ -428,7 +428,7 @@ To demonstrate, you’ll go into your project and start working on a couple of f
 	#      modified:   lib/simplegit.rb
 	#
 
-Now you want to switch branches, but you don’t want to commit what you’ve been working on yet; so you’ll stash the changes. To push a new stash onto your stack, run `git stash`:
+Ora vuoi passare a un'altra diramazione, ma non vuoi ancora committare il tuo lavoro perché non è ancora pronto; accantona quindi le tue modifiche. Per aggiungere un nuovo livello alla pila devi eseguire `git stash`:
 
 	$ git stash
 	Saved working directory and index state \
@@ -436,20 +436,20 @@ Now you want to switch branches, but you don’t want to commit what you’ve be
 	HEAD is now at 049d078 added the index file
 	(To restore them type "git stash apply")
 
-Your working directory is clean:
+La tua cartella di lavoro ora è pulita:
 
 	$ git status
 	# On branch master
 	nothing to commit (working directory clean)
 
-At this point, you can easily switch branches and do work elsewhere; your changes are stored on your stack. To see which stashes you’ve stored, you can use `git stash list`:
+A questo punto puoi passare facilmente a un'altra diramazione e lavorare ad altro; le tue modifiche sono salvate nella tua pila di accantonamento. Per vedere cosa c'è nella tua pila usa `git stash list`:
 
 	$ git stash list
 	stash@{0}: WIP on master: 049d078 added the index file
-	stash@{1}: WIP on master: c264051... Revert "added file_size"
-	stash@{2}: WIP on master: 21d80a5... added number to log
+	stash@{1}: WIP on master: c264051 Revert "added file_size"
+	stash@{2}: WIP on master: 21d80a5 added number to log
 
-In this case, two stashes were done previously, so you have access to three different stashed works. You can reapply the one you just stashed by using the command shown in the help output of the original stash command: `git stash apply`. If you want to apply one of the older stashes, you can specify it by naming it, like this: `git stash apply stash@{2}`. If you don’t specify a stash, Git assumes the most recent stash and tries to apply it:
+In questo caso hai due accantonamenti precedenti, e hai così accesso a tre lavori differenti accantonati. Puoi riapplicare quello che hai appena accantonato usando il comando mostrato nell'output d'aiuto del comando che hai usato quanto hai accantonato le tue modifiche: `git stash apply`. Se vuoi applicare uno degli accantonamenti precedenti, puoi specificarlo usandone il nome così: `git stash apply stash@{2}`. Se non specifiche un accantonamento Git suppone che ti riferisca all'ultimo e prova ad applicarlo:
 
 	$ git stash apply
 	# On branch master
@@ -460,9 +460,9 @@ In this case, two stashes were done previously, so you have access to three diff
 	#      modified:   lib/simplegit.rb
 	#
 
-You can see that Git re-modifies the files you uncommitted when you saved the stash. In this case, you had a clean working directory when you tried to apply the stash, and you tried to apply it on the same branch you saved it from; but having a clean working directory and applying it on the same branch aren’t necessary to successfully apply a stash. You can save a stash on one branch, switch to another branch later, and try to reapply the changes. You can also have modified and uncommitted files in your working directory when you apply a stash — Git gives you merge conflicts if anything no longer applies cleanly.
+Puoi vedere che Git ha rimodificato i file che aveva rimosso quando hai salvato l'accantonamento. In questo caso avevi una cartella di lavoro pulita quando provasti ad applicare l'accantonamento e stai provando a riappricarlo alla stessa ramificazione da cui l'avevi salvato; ma non è necessario avere una cartella pulita per applicare un accantonamento né che sia la stessa ramificazione. Puoi salvare un accantonamento da una ramificazione, passare a un'altra e applicare le modifiche accantonate. Nella tua cartella puoi anche avere modifiche non ancora committate quando applichi un accantonamento: Git ti darà un conflitto d'incorporamento nel caso che qualcosa non si possa applicare senza problemi.
 
-The changes to your files were reapplied, but the file you staged before wasn’t restaged. To do that, you must run the `git stash apply` command with a `--index` option to tell the command to try to reapply the staged changes. If you had run that instead, you’d have gotten back to your original position:
+Le modifiche vengono riapplicate ai tuoi file, ma quello che avevi assemblato ora non lo sono. Per farlo devi eseguire il comando `git stash apply` con il parametro `--index` perché provi a riapplicare le modifiche assemblate. Se lo avessi fatto ti saresti trovato nella stessa posizione originale:
 
 	$ git stash apply --index
 	# On branch master
@@ -477,17 +477,17 @@ The changes to your files were reapplied, but the file you staged before wasn’
 	#      modified:   lib/simplegit.rb
 	#
 
-The apply option only tries to apply the stashed work — you continue to have it on your stack. To remove it, you can run `git stash drop` with the name of the stash to remove:
+L'opzione `apply` prova solo ad applicare le modifiche assemblate: continua per averle nel tuo accantonamento. Per cancellare l'accantonamento devi eseguire `git stash drop` con il nome dell'accantonamento da rimuovere:
 
 	$ git stash list
 	stash@{0}: WIP on master: 049d078 added the index file
-	stash@{1}: WIP on master: c264051... Revert "added file_size"
-	stash@{2}: WIP on master: 21d80a5... added number to log
+	stash@{1}: WIP on master: c264051 Revert "added file_size"
+	stash@{2}: WIP on master: 21d80a5 added number to log
 	$ git stash drop stash@{0}
 	Dropped stash@{0} (364e91f3f268f0900bc3ee613f9f733e82aaed43)
 
-You can also run `git stash pop` to apply the stash and then immediately drop it from your stack.
-
+Puoi eseguire anche `git stash pop` per applicare l'accantonamento e cancellare immediatamente dopo.
+<!-- da tradurre fino a riga 840 -->
 ### Un-applying a Stash ###
 
 In some use case scenarios you might want to apply stashed changes, do some work, but then un-apply those changes that originally came from the stash. Git does not provide such a `stash unapply` command, but it is possible to achieve the effect by simply retrieving the patch associated with a stash and applying it in reverse:

From b94db13de0ef164962a92007e1ec2582b7ec03ce Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Sat, 26 Apr 2014 22:12:38 +0200
Subject: [PATCH 381/690] [it] translating chapter 6

Translated "Un-applying a Stash"
---
 it/06-git-tools/01-chapter6.markdown | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/it/06-git-tools/01-chapter6.markdown b/it/06-git-tools/01-chapter6.markdown
index b62a1a74f..df4c35d2b 100644
--- a/it/06-git-tools/01-chapter6.markdown
+++ b/it/06-git-tools/01-chapter6.markdown
@@ -487,24 +487,24 @@ L'opzione `apply` prova solo ad applicare le modifiche assemblate: continua per
 	Dropped stash@{0} (364e91f3f268f0900bc3ee613f9f733e82aaed43)
 
 Puoi eseguire anche `git stash pop` per applicare l'accantonamento e cancellare immediatamente dopo.
-<!-- da tradurre fino a riga 840 -->
-### Un-applying a Stash ###
 
-In some use case scenarios you might want to apply stashed changes, do some work, but then un-apply those changes that originally came from the stash. Git does not provide such a `stash unapply` command, but it is possible to achieve the effect by simply retrieving the patch associated with a stash and applying it in reverse:
+### Annullare una modifica accantonata ###
+
+In alcuni scenari potresti voler applicare delle modifiche accantonate, fare dell'altro lavoro e successivamente voler rimuovere le modifiche che venivano dall'accantonamento. Git non ha un comando `stash unapply`, ma è possibile ottenere lo stesso risultato richiamando la modifica associata all'accantonamento e applicarla al contrario:
 
     $ git stash show -p stash@{0} | git apply -R
 
-Again, if you don’t specify a stash, Git assumes the most recent stash:
+Di nuovo, se non specifichi un accantonamento, Git assume che sia l'ultimo:
 
     $ git stash show -p | git apply -R
 
-You may want to create an alias and effectively add a `stash-unapply` command to your Git. For example:
+Puoi voler creare un alias per avere un comando `stash-unapply` nel tuo Git. Per esempio:
 
     $ git config --global alias.stash-unapply '!git stash show -p | git apply -R'
     $ git stash
     $ #... work work work
     $ git stash-unapply
-
+<!-- da tradurre fino a riga 840 -->
 ### Creating a Branch from a Stash ###
 
 If you stash some work, leave it there for a while, and continue on the branch from which you stashed the work, you may have a problem reapplying the work. If the apply tries to modify a file that you’ve since modified, you’ll get a merge conflict and will have to try to resolve it. If you want an easier way to test the stashed changes again, you can run `git stash branch`, which creates a new branch for you, checks out the commit you were on when you stashed your work, reapplies your work there, and then drops the stash if it applies successfully:

From e49956283eaa1edc34205208684ac0d129cd3942 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Sat, 26 Apr 2014 22:18:49 +0200
Subject: [PATCH 382/690] [it] translating chapter 6

Translated "Creating a Branch from a Stash"
---
 it/06-git-tools/01-chapter6.markdown | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/it/06-git-tools/01-chapter6.markdown b/it/06-git-tools/01-chapter6.markdown
index df4c35d2b..26d1e0821 100644
--- a/it/06-git-tools/01-chapter6.markdown
+++ b/it/06-git-tools/01-chapter6.markdown
@@ -504,10 +504,10 @@ Puoi voler creare un alias per avere un comando `stash-unapply` nel tuo Git. Per
     $ git stash
     $ #... work work work
     $ git stash-unapply
-<!-- da tradurre fino a riga 840 -->
-### Creating a Branch from a Stash ###
 
-If you stash some work, leave it there for a while, and continue on the branch from which you stashed the work, you may have a problem reapplying the work. If the apply tries to modify a file that you’ve since modified, you’ll get a merge conflict and will have to try to resolve it. If you want an easier way to test the stashed changes again, you can run `git stash branch`, which creates a new branch for you, checks out the commit you were on when you stashed your work, reapplies your work there, and then drops the stash if it applies successfully:
+### Creare una diramazione da un accantonamento ###
+
+Se accantoni del lavoro e lo lasci lì mentre continui a lavorare per un po' nella diramazione da cui hai creato l'accantonamento, potresti avere dei problemi a riapplicarlo. Se l'applicazione prova a modificare un file che avevi modificato successivamente, otterrai un conflitto d'incorporazione e dovrai risolverlo. Se vuoi un modo facile per ritestare le modifiche accantonate, puoi eseguire il comando `git stash branch`, che crea una diramazione, scarica la commit dov'eri quando hai accantonato il tuo lavoro, lo riapplica e, se ci riesce senza problemi, cancella l'accantonamento:
 
 	$ git stash branch testchanges
 	Switched to a new branch "testchanges"
@@ -524,8 +524,8 @@ If you stash some work, leave it there for a while, and continue on the branch f
 	#
 	Dropped refs/stash@{0} (f0dfc4d5dc332d1cee34a634182e168c4efc3359)
 
-This is a nice shortcut to recover stashed work easily and work on it in a new branch.
-
+Questa è una bella accorciatoioa per recuperare il lavoro accantonato e lavorarci in una nuova diramazione.
+<!-- da tradurre fino a riga 840 -->
 ## Rewriting History ##
 
 Many times, when working with Git, you may want to revise your commit history for some reason. One of the great things about Git is that it allows you to make decisions at the last possible moment. You can decide what files go into which commits right before you commit with the staging area, you can decide that you didn’t mean to be working on something yet with the stash command, and you can rewrite commits that already happened so they look like they happened in a different way. This can involve changing the order of the commits, changing messages or modifying files in a commit, squashing together or splitting apart commits, or removing commits entirely — all before you share your work with others.

From 20a3f53631c8b3fb448ac7717263b62a22f4ffda Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Sat, 26 Apr 2014 22:31:09 +0200
Subject: [PATCH 383/690] updating output of 'git stash list'

---
 en/06-git-tools/01-chapter6.markdown | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/en/06-git-tools/01-chapter6.markdown b/en/06-git-tools/01-chapter6.markdown
index f5b10d700..f986c2e38 100644
--- a/en/06-git-tools/01-chapter6.markdown
+++ b/en/06-git-tools/01-chapter6.markdown
@@ -481,8 +481,8 @@ The apply option only tries to apply the stashed work — you continue to have i
 
 	$ git stash list
 	stash@{0}: WIP on master: 049d078 added the index file
-	stash@{1}: WIP on master: c264051... Revert "added file_size"
-	stash@{2}: WIP on master: 21d80a5... added number to log
+	stash@{1}: WIP on master: c264051 Revert "added file_size"
+	stash@{2}: WIP on master: 21d80a5 added number to log
 	$ git stash drop stash@{0}
 	Dropped stash@{0} (364e91f3f268f0900bc3ee613f9f733e82aaed43)
 

From 72c9c1eb016a166fc4a6d3ae7fbe54e0f688555c Mon Sep 17 00:00:00 2001
From: Cor Takken <git@cpt1.demon.nl>
Date: Sun, 27 Apr 2014 16:07:07 +0200
Subject: [PATCH 384/690] [nl] - Synchronized with 7f80ea23

---
 nl/06-git-tools/01-chapter6.markdown | 78 ++++++++++++++--------------
 1 file changed, 39 insertions(+), 39 deletions(-)

diff --git a/nl/06-git-tools/01-chapter6.markdown b/nl/06-git-tools/01-chapter6.markdown
index 98180e261..413d0130e 100644
--- a/nl/06-git-tools/01-chapter6.markdown
+++ b/nl/06-git-tools/01-chapter6.markdown
@@ -33,7 +33,7 @@ vertaling moeten proberen te maken.
 
 Veel succes en plezier bij het vertalen...
 -->
-<!-- SHA-1 of last checked en-version: 3c18779  -->
+<!-- SHA-1 of last checked en-version: 7f80ea23  -->
 # Git tools #
 
 Nu heb je de meeste commando's en werkwijzen geleerd die je dagelijks nodig hebt om een Git repository voor je broncode te beheren en te onderhouden. Je hebt de basistaken van het tracken en committen van bestanden onder de knie, en je hebt de kracht van de staging area en lichtgewicht topic branching en mergen in de vingers.
@@ -50,7 +50,7 @@ Natuurlijk kun je naar een commit refereren met de SHA-1 hash die het toegekend
 
 ### Korte SHA ###
 
-Git is slim genoeg om uit te vinden welke commit je bedoelde te typen als je het de eerste paar karakters geeft, zolang je gedeeltelijke SHA-1 maar minstens vier karakters lang en ondubbelzinnig is; dat wil zeggen dat slechts één object in de huidige repository begint met die gedeeltelijke SHA-1.
+Git is slim genoeg om uit te vinden welke commit je bedoelde te typen als je het de eerste paar karakters geeft, zolang je gedeeltelijke SHA-1 maar minstens vier karakters lang en ondubbelzinnig is; dat wil zeggen dat slechts ��n object in de huidige repository begint met die gedeeltelijke SHA-1.
 
 Bijvoorbeeld, stel dat je om een specifieke commit te zien een `git log` commando uitvoert en de commit identificeert waarin je een bepaalde functionaliteit hebt toegevoegd:
 
@@ -95,10 +95,10 @@ Veel mensen beginnen bezorgd te raken dat ze op een bepaald moment door puur toe
 
 Mocht je een object committen dat hashed naar dezelfde SHA-1 waarde als een vorig object in je repository, dan zal Git het vorige reeds aanwezige object in je Git database zien en aannemen dat het al geschreven was. Als je op een bepaald moment dat object opnieuw probeert uit te checken, dan zal je altijd de gegevens van het eerste object krijgen.
 
-<!-- Vraag: weet iemand de officiële term voor botsingswaarschijnlijkheid? Via de Engelse Wikipedia kom ik (via collision probability) op universal hashing, maar is de formule niet te zien. -->
+<!-- Vraag: weet iemand de offici�le term voor botsingswaarschijnlijkheid? Via de Engelse Wikipedia kom ik (via collision probability) op universal hashing, maar is de formule niet te zien. -->
 Maar wat je moet beseffen is hoe vreselijk onwaarschijnlijk dit scenario is. De SHA-1 waarde is 20 bytes, oftewel 160 bits. Het aantal benodigde random gehashte objecten om een 50% waarschijnlijkheid van een botsing te garanderen is ongeveer 2^80 (de formule om botsingswaarschijnlijkheid te bepalen is `p = (n(n-1)/2) * (1/2^160)`). 2^80 is 1.2 x 10^24 of 1 miljoen miljard miljard. Dat is 1.200 keer het aantal zandkorrels op aarde.
 
-Hier is een voorbeeld om je een idee te geven wat er voor nodig is om een SHA-1 botsing te krijgen. Als alle 6.5 miljard mensen op aarde zouden programmeren, en iedere seconde zou ieder van hen code genereren die gelijk was aan de hele Linux kernel-geschiedenis (1 miljoen Git objecten) en dat in één gigantische Git repository pushen, dan zou het vijf jaar duren voordat die repository genoeg objecten zou bevatten om een 50% waarschijnlijkheid van één enkele SHA-1 object botsing te krijgen. De kans is groter dat elk lid van je programmeerteam zal worden aangevallen en gedood door wolven bij ongerelateerde incidenten op dezelfde avond.
+Hier is een voorbeeld om je een idee te geven wat er voor nodig is om een SHA-1 botsing te krijgen. Als alle 6.5 miljard mensen op aarde zouden programmeren, en iedere seconde zou ieder van hen code genereren die gelijk was aan de hele Linux kernel-geschiedenis (1 miljoen Git objecten) en dat in ��n gigantische Git repository pushen, dan zou het vijf jaar duren voordat die repository genoeg objecten zou bevatten om een 50% waarschijnlijkheid van ��n enkele SHA-1 object botsing te krijgen. De kans is groter dat elk lid van je programmeerteam zal worden aangevallen en gedood door wolven bij ongerelateerde incidenten op dezelfde avond.
 
 ### Branch referenties ###
 
@@ -119,13 +119,13 @@ Een van de dingen die Git in de achtergrond doet terwijl jij lekker zit te werke
 Je kunt je reflog zien door `git reflog` te gebruiken:
 
 	$ git reflog
-	734713b... HEAD@{0}: commit: fixed refs handling, added gc auto, updated
-	d921970... HEAD@{1}: merge phedders/rdocs: Merge made by recursive.
-	1c002dd... HEAD@{2}: commit: added some blame and merge stuff
-	1c36188... HEAD@{3}: rebase -i (squash): updating HEAD
-	95df984... HEAD@{4}: commit: # This is a combination of two commits.
-	1c36188... HEAD@{5}: rebase -i (squash): updating HEAD
-	7e05da5... HEAD@{6}: rebase -i (pick): updating HEAD
+	734713b HEAD@{0}: commit: fixed refs handling, added gc auto, updated
+	d921970 HEAD@{1}: merge phedders/rdocs: Merge made by recursive.
+	1c002dd HEAD@{2}: commit: added some blame and merge stuff
+	1c36188 HEAD@{3}: rebase -i (squash): updating HEAD
+	95df984 HEAD@{4}: commit: # This is a combination of two commits.
+	1c36188 HEAD@{5}: rebase -i (squash): updating HEAD
+	7e05da5 HEAD@{6}: rebase -i (pick): updating HEAD
 
 Iedere keer als de punt van je branch om een of andere reden is gewijzigd, dan bewaart Git die informatie voor je in deze tijdelijke geschiedenis. En je kunt ook oudere commits met deze gegevens specificeren. Als je de vijfde voorgaande waarde van de HEAD van je repository wilt zien, dan kun je de `@{n}` referentie gebruiken, die je in de reflog output kunt zien:
 
@@ -183,7 +183,7 @@ Dan zie je de vorige commit door `HEAD^` te specificeren, wat "de ouder van HEAD
 
 	    Merge commit 'phedders/rdocs'
 
-Je kunt ook een getal na de `^` zetten, bijvoorbeeld `d921970^2` betekent "de tweede ouder van d921970." Deze syntax is alleen nuttig voor merge commits, omdat die meer dan één ouder hebben. De eerste ouder is de branch waar jij op was toen je mergede, en de andere is de commit op de branch die je gemerged hebt:
+Je kunt ook een getal na de `^` zetten, bijvoorbeeld `d921970^2` betekent "de tweede ouder van d921970." Deze syntax is alleen nuttig voor merge commits, omdat die meer dan ��n ouder hebben. De eerste ouder is de branch waar jij op was toen je mergede, en de andere is de commit op de branch die je gemerged hebt:
 
 	$ git show d921970^
 	commit 1c002dd4b536e7479fe34593e72e6c6c1819e53b
@@ -247,17 +247,17 @@ Dit is handig als je de `experiment` branch up to date wilt houden en alvast wil
 	$ git log origin/master..HEAD
 
 Dit commando toont je alle commits in je huidige branch, die niet in de `master` branch op de remote `origin` zitten. Als je een `git push` uitvoert, en je huidige branch volgt de `origin/master`, dan zijn de commits die getoond worden door `git log origin/master..HEAD` de commits die verstuurd zullen worden naar de server.
-Je kunt ook één kant van de syntax weglaten om Git de HEAD laten aannemen. Bijvoorbeeld, je krijgt dezelfde resultaten als in het vorige voorbeeld door `git log origin/master..` te typen - Git vult HEAD in als er één kant ontbreekt.
+Je kunt ook ��n kant van de syntax weglaten om Git de HEAD laten aannemen. Bijvoorbeeld, je krijgt dezelfde resultaten als in het vorige voorbeeld door `git log origin/master..` te typen - Git vult HEAD in als er ��n kant ontbreekt.
 
 #### Dubbele punten ####
 
-De syntax met de dubbel-punt is makkelijk als een afkorting, maar misschien wil je meer dan twee branches specificeren om je revisie aan te geven, zoals het zien welke commits in één van de branches in een reeks zitten, die nog niet in de branch zitten waar je nu op werkt. Git laat je dit doen door of het `^` karakter of `--not`, te gebruiken voor iedere referentie waarvan je de bereikbare commits niet wilt zien. Dus deze drie commando's zijn gelijk:
+De syntax met de dubbel-punt is makkelijk als een afkorting, maar misschien wil je meer dan twee branches specificeren om je revisie aan te geven, zoals het zien welke commits in ��n van de branches in een reeks zitten, die nog niet in de branch zitten waar je nu op werkt. Git laat je dit doen door of het `^` karakter of `--not`, te gebruiken voor iedere referentie waarvan je de bereikbare commits niet wilt zien. Dus deze drie commando's zijn gelijk:
 
 	$ git log refA..refB
 	$ git log ^refA refB
 	$ git log refB --not refA
 
-Dit is prettig omdat met deze syntax je meer dan twee referenties in je vraag kunt specificeren, wat je niet met de dubbel punt syntax kan doen. Bijvoorbeeld, als je alle commits wilt zien die bereikbaar zijn vanuit `refA` of `refB`, maar niet vanuit `refC`, dan kun je één van deze intypen:
+Dit is prettig omdat met deze syntax je meer dan twee referenties in je vraag kunt specificeren, wat je niet met de dubbel punt syntax kan doen. Bijvoorbeeld, als je alle commits wilt zien die bereikbaar zijn vanuit `refA` of `refB`, maar niet vanuit `refC`, dan kun je ��n van deze intypen:
 
 	$ git log refA refB ^refC
 	$ git log refA refB --not refC
@@ -266,7 +266,7 @@ Dit zorgt voor een erg krachtig revisie vraagsysteem dat je kan helpen om uit te
 
 #### Drievoudige punt ####
 
-De laatste veelgebruikte reeks-selectie syntax is de drievoudige punt syntax, wat alle commits specificeert die bereikbaar zijn door één van de twee referenties, maar niet door allebei. Kijk nog eens naar de voorbeeld commitgeschiedenis in Figuur 6-1.
+De laatste veelgebruikte reeks-selectie syntax is de drievoudige punt syntax, wat alle commits specificeert die bereikbaar zijn door ��n van de twee referenties, maar niet door allebei. Kijk nog eens naar de voorbeeld commitgeschiedenis in Figuur 6-1.
 Als je wilt zien wat in je `master` of in je `experiment` zit, maar geen gedeelde referenties, dan kun je dit uitvoeren
 
 	$ git log master...experiment
@@ -289,7 +289,7 @@ Met deze tools, kun je Git eenvoudiger laten weten welke commit of commits je wi
 
 ## Interactief stagen ##
 
-Bij Git worden een aantal scripts geleverd, die sommige commandline taken makkelijker maken. Hier zul je een aantal interactieve commando's zien, die je kunnen helpen om je commits zo samen te stellen dat ze alleen bepaalde combinaties en delen van bestanden bevatten. Deze tools zijn erg nuttig als je een reeks bestanden aanpast en dan besluit dat je deze wijzigingen in een aantal gefocuste commits wilt hebben in plaats van één grote rommelige commit. Op deze manier ben je er zeker van dat je commits logische aparte wijzigingensets zijn en makkelijk gereviewed kunnen worden door je mede-ontwikkelaars.
+Bij Git worden een aantal scripts geleverd, die sommige commandline taken makkelijker maken. Hier zul je een aantal interactieve commando's zien, die je kunnen helpen om je commits zo samen te stellen dat ze alleen bepaalde combinaties en delen van bestanden bevatten. Deze tools zijn erg nuttig als je een reeks bestanden aanpast en dan besluit dat je deze wijzigingen in een aantal gefocuste commits wilt hebben in plaats van ��n grote rommelige commit. Op deze manier ben je er zeker van dat je commits logische aparte wijzigingensets zijn en makkelijk gereviewed kunnen worden door je mede-ontwikkelaars.
 Als je `git add` uitvoert met de `-i` of `--interactive` optie, dan schakelt Git over naar een interactieve shell modus, waarbij zoiets als dit getoond wordt:
 
 	$ git add -i
@@ -396,7 +396,7 @@ Met deze simpele commando's kun je de interactieve toevoegmodus gebruiken om op
 
 ### Patches stagen ###
 
-Het is met Git ook mogelijk om bepaalde delen van bestanden te stagen en de rest niet. Bijvoorbeeld, als je twee wijzigingen maakt in je simplegit.rb bestand en één van die twee wilt stagen en de andere niet, dan is dat eenvoudig in Git. Vanaf de interactieve prompt, type `5` of `p` (voor patch). Git zal je vragen welke bestanden je deels wilt stagen en daarna, voor iedere sectie van de geselecteerde bestanden, zal het stukken van de bestandsdiff tonen en je vragen of je ze wilt stagen, één voor één:
+Het is met Git ook mogelijk om bepaalde delen van bestanden te stagen en de rest niet. Bijvoorbeeld, als je twee wijzigingen maakt in je simplegit.rb bestand en ��n van die twee wilt stagen en de andere niet, dan is dat eenvoudig in Git. Vanaf de interactieve prompt, type `5` of `p` (voor patch). Git zal je vragen welke bestanden je deels wilt stagen en daarna, voor iedere sectie van de geselecteerde bestanden, zal het stukken van de bestandsdiff tonen en je vragen of je ze wilt stagen, ��n voor ��n:
 
 	diff --git a/lib/simplegit.rb b/lib/simplegit.rb
 	index dd5ecc4..57399e0 100644
@@ -483,8 +483,8 @@ Nu kan je eenvoudig van branch wisselen en ergens anders aan werken, je wijzigin
 
 	$ git stash list
 	stash@{0}: WIP on master: 049d078 added the index file
-	stash@{1}: WIP on master: c264051... Revert "added file_size"
-	stash@{2}: WIP on master: 21d80a5... added number to log
+	stash@{1}: WIP on master: c264051 Revert "added file_size"
+	stash@{2}: WIP on master: 21d80a5 added number to log
 
 In dit geval waren er twee stashes al eerder opgeslagen, dus heb je toegang tot drie verschillende gestashede werken. Je kunt degene die je zojuist gestashed hebt opnieuw toepassen, door het commando uit te voeren dat in de help output van het originele stash commando stond: `git stash apply`. Als je een van de oudere stashes wilt toepassen, dan kun je die specificeren door hem te benoemen, zoals hier: `git apply stash stash@{2}`. Als je geen stash specificeert, neemt Git aan dat je de meest recente stash bedoelt en probeert die toe te passen:
 
@@ -497,7 +497,7 @@ In dit geval waren er twee stashes al eerder opgeslagen, dus heb je toegang tot
 	#      modified:   lib/simplegit.rb
 	#
 
-Je kunt zien dat Git opnieuw de bestanden wijzigt die je uncommitte toen je de stash opsloeg. In dit geval had je een schone werkdirectory toen je de stash probeerde toe te passen, en dat je probeerde deze op dezelfde branch toe te passen als waar je hem van opgeslagen hebt. Maar het hebben van een schone werkdirectory en het toepassen op dezelfde branch zijn niet noodzakelijk om een stash succesvol toe te kunnen passen. Je kunt een stash op één branch opslaan, later naar een andere branch omschakelen, en daar opnieuw de wijzigingen toe proberen te passen. Je kunt ook gewijzigde en uncommitted bestanden in je werkdirectory hebben wanneer je een stash probeert toe te passen, Git geeft merge conflicten aan als iets niet meer netjes toe te passen is.
+Je kunt zien dat Git opnieuw de bestanden wijzigt die je uncommitte toen je de stash opsloeg. In dit geval had je een schone werkdirectory toen je de stash probeerde toe te passen, en dat je probeerde deze op dezelfde branch toe te passen als waar je hem van opgeslagen hebt. Maar het hebben van een schone werkdirectory en het toepassen op dezelfde branch zijn niet noodzakelijk om een stash succesvol toe te kunnen passen. Je kunt een stash op ��n branch opslaan, later naar een andere branch omschakelen, en daar opnieuw de wijzigingen toe proberen te passen. Je kunt ook gewijzigde en uncommitted bestanden in je werkdirectory hebben wanneer je een stash probeert toe te passen, Git geeft merge conflicten aan als iets niet meer netjes toe te passen is.
 
 De wijzigingen aan je bestanden zijn opnieuw toegepast, maar het bestand dat je eerder gestaged had is niet opnieuw gestaged. Om dat te doen moet je het `git stash apply` commando met de `--index` optie uitvoeren om het commando te vertellen de gestagede wijzigingen opnieuw proberen toe te passen. Als je dat had uitgevoerd, dan zou je weer op je originele uitgangspunt zijn uitgekomen:
 
@@ -565,7 +565,7 @@ Dit is een prettige manier om gestashed werk eenvoudig terug te halen en eraan t
 
 ## Geschiedenis herschrijven ##
 
-Vaak zal je, als je met Git werkt, je commit geschiedenis om een of andere reden willen aanpassen. Één van de mooie dingen van Git is dat het je in staat stelt om beslissingen op het laatst mogelijke moment te maken. Je kunt bepalen welke bestanden in welke commits gaan vlak voordat je commit, door middel van de staging area, je kunt besluiten dat je toch nog niet aan iets had willen beginnen met het stash commando en je kunt commits herschrijven ook al zijn ze al gebeurd, waardoor het lijkt alsof ze op een andere manier gebeurd zijn. Dit kan bijvoorbeeld de volgorde van de commits zijn, berichten of bestanden in een commit wijzigen, commits samenpersen(squashen) of opsplitsen, of complete commits weghalen - en dat allemaal voordat je jouw werk met anderen deelt.
+Vaak zal je, als je met Git werkt, je commit geschiedenis om een of andere reden willen aanpassen. �n van de mooie dingen van Git is dat het je in staat stelt om beslissingen op het laatst mogelijke moment te maken. Je kunt bepalen welke bestanden in welke commits gaan vlak voordat je commit, door middel van de staging area, je kunt besluiten dat je toch nog niet aan iets had willen beginnen met het stash commando en je kunt commits herschrijven ook al zijn ze al gebeurd, waardoor het lijkt alsof ze op een andere manier gebeurd zijn. Dit kan bijvoorbeeld de volgorde van de commits zijn, berichten of bestanden in een commit wijzigen, commits samenpersen(squashen) of opsplitsen, of complete commits weghalen - en dat allemaal voordat je jouw werk met anderen deelt.
 
 In deze paragraaf zal je leren hoe je deze handige taken uitvoert, zodat je jouw commit geschiedenis er uit kunt laten zien zoals jij dat wilt, voordat je het met anderen deelt.
 
@@ -656,7 +656,7 @@ Dit commando zal de andere twee commits automatisch toepassen, en je bent klaar.
 
 ### Commits opnieuw rangschikken ###
 
-Je kunt een interactieve rebase ook gebruiken om commits opnieuw te rangschikken of zijn geheel te verwijderen. Als je de "added cat-file" commit wilt verwijderen en de volgorde waarin de andere twee commits zijn geïntroduceerd wilt veranderen, dan kun je het rebase script van dit
+Je kunt een interactieve rebase ook gebruiken om commits opnieuw te rangschikken of zijn geheel te verwijderen. Als je de "added cat-file" commit wilt verwijderen en de volgorde waarin de andere twee commits zijn ge�ntroduceerd wilt veranderen, dan kun je het rebase script van dit
 
 	pick f7f3f6d changed my name a bit
 	pick 310154e updated README formatting and added blame
@@ -671,7 +671,7 @@ Als je dan opslaat en de editor sluit, zal Git je branch terugzetten naar de oud
 
 ### Een commit samenpersen (squashing) ###
 
-Het is ook mogelijk een serie commits te pakken en ze in één enkele commit samen te persen (squash) met het interactieve rebase tool. Het script stopt behulpzame instructies in het rebase bericht:
+Het is ook mogelijk een serie commits te pakken en ze in ��n enkele commit samen te persen (squash) met het interactieve rebase tool. Het script stopt behulpzame instructies in het rebase bericht:
 
 	#
 	# Commands:
@@ -767,7 +767,7 @@ Nu is de nieuwe project root elke keer de inhoud van de `trunk` subdirectory. Gi
 
 #### E-mail adressen globaal veranderen ####
 
-Een ander veel voorkomend geval is dat je vergeten bent om `git config` uit te voeren om je naam en e-mail adres in te stellen voordat je begon met werken, of misschien wil je een project op het werk open source maken en al je werk e-mail adressen veranderen naar je persoonlijke adres. Hoe dan ook, je kunt e-mail adressen in meerdere commits ook in één klap veranderen met `filter-branch`. Je moet wel oppassen dat je alleen die e-mail adressen aanpast die van jou zijn, dus gebruik je `--commit-filter`:
+Een ander veel voorkomend geval is dat je vergeten bent om `git config` uit te voeren om je naam en e-mail adres in te stellen voordat je begon met werken, of misschien wil je een project op het werk open source maken en al je werk e-mail adressen veranderen naar je persoonlijke adres. Hoe dan ook, je kunt e-mail adressen in meerdere commits ook in ��n klap veranderen met `filter-branch`. Je moet wel oppassen dat je alleen die e-mail adressen aanpast die van jou zijn, dus gebruik je `--commit-filter`:
 
 	$ git filter-branch --commit-filter '
 	        if [ "$GIT_AUTHOR_EMAIL" = "schacon@localhost" ];
@@ -787,7 +787,7 @@ Git levert ook een paar tools om je problemen te helpen debuggen in je projecten
 
 ### Aantekenen van bestanden ###
 
-Als je een bug in je code traceert en wilt weten wanneer het was geïntroduceerd en waarom, dan is bestands aantekenen vaak je beste methode. Het toont je welke commit de laatste was die iets wijzigde in een bepaald bestand. Dus als je ziet dat een methode in je code bugs bevat, dan kun je het bestand aantekenen met `git blame` om te zien wanneer een regel van de methode voor het laatst aangepast was en door wie. Dit voorbeeld gebruikt de `-L` optie om de output te beperken tot regel 12 tot en met 22:
+Als je een bug in je code traceert en wilt weten wanneer het was ge�ntroduceerd en waarom, dan is bestands aantekenen vaak je beste methode. Het toont je welke commit de laatste was die iets wijzigde in een bepaald bestand. Dus als je ziet dat een methode in je code bugs bevat, dan kun je het bestand aantekenen met `git blame` om te zien wanneer een regel van de methode voor het laatst aangepast was en door wie. Dit voorbeeld gebruikt de `-L` optie om de output te beperken tot regel 12 tot en met 22:
 
 	$ git blame -L 12,22 simplegit.rb
 	^4832fe2 (Scott Chacon  2008-03-15 10:31:28 -0700 12)  def show(tree = 'master')
@@ -835,7 +835,7 @@ Stel dat je zojuist een release van je code naar een productie omgeving gepusht
 	Bisecting: 6 revisions left to test after this
 	[ecb6e1bc347ccecc5f9350d878ce677feb13d3b2] error handling on repo
 
-Git heeft gezien dat er ongeveer 12 commits geweest zijn tussen de commit die je als laatste goede commit gemarkeerd hebt (v1.0) en de huidige slechte versie, en het heeft de middelste voor je uitgecheckt. Op dit punt kun je de test uitvoeren om te zien of het probleem op deze commit ook aanwezig is. Als dat zo is, dan was het probleem ergens voor deze middelste commit geïntroduceerd, zo niet dan is het probleem na deze commit geïntroduceerd. Het blijkt dat hier geen probleem is, dus vertel je Git dat door `git bisect good` te typen en je reis te vervolgen:
+Git heeft gezien dat er ongeveer 12 commits geweest zijn tussen de commit die je als laatste goede commit gemarkeerd hebt (v1.0) en de huidige slechte versie, en het heeft de middelste voor je uitgecheckt. Op dit punt kun je de test uitvoeren om te zien of het probleem op deze commit ook aanwezig is. Als dat zo is, dan was het probleem ergens voor deze middelste commit ge�ntroduceerd, zo niet dan is het probleem na deze commit ge�ntroduceerd. Het blijkt dat hier geen probleem is, dus vertel je Git dat door `git bisect good` te typen en je reis te vervolgen:
 
 	$ git bisect good
 	Bisecting: 3 revisions left to test after this
@@ -847,7 +847,7 @@ Nu zit je op een andere commit, halverwege degene die je zojuist getest hebt en
 	Bisecting: 1 revisions left to test after this
 	[f71ce38690acf49c1f3c9bea38e09d82a5ce6014] drop exceptions table
 
-Deze commit is in orde, en nu heeft Git alle informatie die het nodig heeft om vast te stellen wanneer het probleem was geïntroduceerd. Het vertelt je de SHA-1 van de eerste slechte commit en toont een stukje commit informatie en welke bestanden aangepast waren in die commit, zodat je er achter kunt komen wat deze bug geïntroduceerd kan hebben:
+Deze commit is in orde, en nu heeft Git alle informatie die het nodig heeft om vast te stellen wanneer het probleem was ge�ntroduceerd. Het vertelt je de SHA-1 van de eerste slechte commit en toont een stukje commit informatie en welke bestanden aangepast waren in die commit, zodat je er achter kunt komen wat deze bug ge�ntroduceerd kan hebben:
 
 	$ git bisect good
 	b047b02ea83310a70fd603dc8cd7a6cd13d15c04 is first bad commit
@@ -875,7 +875,7 @@ Door het zo te doen wordt `test-error.sh` uitgevoerd bij elke commit die uitgech
 
 Het komt vaak voor dat terwijl je zit te werken aan het ene project, je een ander project daarbinnen moet gebruiken. Bijvoorbeeld een library die een derde partij ontwikkeld heeft, of die je separaat aan het ontwikkelen bent en gebruikt in meerdere projecten. Een veel voorkomend probleem komt in deze scenario's naar voren: je wilt de twee projecten apart behandelen, maar wel binnen de andere kunnen gebruiken.
 
-Hier is een voorbeeld. Stel dat je een website aan het ontwikkelen bent en Atom feeds aan het maken bent. In plaats van je eigen Atom-genererende code te schrijven, besluit je een library te gebruiken. Je zult deze code dan moeten includen van een gedeelde library zoals een CPAN installatie of een Ruby gem, of de broncode kopiëren naar je eigen projectboom. Het probleem met de library includen is dat het lastig is om de library op enige manier aan te passen, en vaak nog lastiger is om het uit te rollen omdat je zeker moet zijn dat iedere client die library beschikbaar heeft. Het probleem van de broncode in je project stoppen is dat alle aanpassingen die je maakt lastig te mergen zijn op het moment dat stroomopwaarts veranderingen beschikbaar komen.
+Hier is een voorbeeld. Stel dat je een website aan het ontwikkelen bent en Atom feeds aan het maken bent. In plaats van je eigen Atom-genererende code te schrijven, besluit je een library te gebruiken. Je zult deze code dan moeten includen van een gedeelde library zoals een CPAN installatie of een Ruby gem, of de broncode kopi�ren naar je eigen projectboom. Het probleem met de library includen is dat het lastig is om de library op enige manier aan te passen, en vaak nog lastiger is om het uit te rollen omdat je zeker moet zijn dat iedere client die library beschikbaar heeft. Het probleem van de broncode in je project stoppen is dat alle aanpassingen die je maakt lastig te mergen zijn op het moment dat stroomopwaarts veranderingen beschikbaar komen.
 
 Git pakt dit probleem aan door submodules te gebruiken. Submodules geven je de mogelijkheid om een Git repository als een subdirectory van een ander Git repository te gebruiken. Dit stelt je in staat staat een ander repository in je project te klonen en je commits gescheiden te houden.
 
@@ -1023,7 +1023,7 @@ Dit is het omdat de pointer die je hebt voor de submodule niet is wat eigenlijk
 
 Je moet dit iedere keer doen wanneer je een submodule wijziging pulled in het hoofdproject. Het is vreemd, maar het werkt.
 
-Één bekend probleem doet zich voor als een developer een lokale wijziging in een submodule doet maar die niet naar een publieke server pusht. Dan committen ze een pointer naar de niet-publieke status en pushen deze naar het superproject. Als andere developers dan `git submodule update` proberen uit te voeren, dan zal het submodule systeem de commit die gerefereerd wordt niet kunnen vinden omdat het alleen op het systeem van de eerste developer bestaat. Als dat gebeurt, zal je een foutmelding als deze zien:
+�n bekend probleem doet zich voor als een developer een lokale wijziging in een submodule doet maar die niet naar een publieke server pusht. Dan committen ze een pointer naar de niet-publieke status en pushen deze naar het superproject. Als andere developers dan `git submodule update` proberen uit te voeren, dan zal het submodule systeem de commit die gerefereerd wordt niet kunnen vinden omdat het alleen op het systeem van de eerste developer bestaat. Als dat gebeurt, zal je een foutmelding als deze zien:
 
 	$ git submodule update
 	fatal: reference isn’t a tree: 6c5e70b984a60b3cecd395edd5b48a7575bf58e0
@@ -1044,13 +1044,13 @@ Dan stuur je een e-mail naar die jongen en gaat heel boos zijn tegen hem.
 
 Soms willen developers een combinatie van subdirectories van een groot project hebben, afhankelijk van het team waarin ze zitten. Dit komt vaak voor als je van CVS of Subversion af komt, waar je een module of verzameling subdirectory gedefinieerd hebt en je wilt deze workflow behouden.
 
-Een goeie manier om dit in Git te doen is om elk van de subdirectories een aparte Git repository te maken en dan superproject Git repositories te maken die meerdere submodules bevatten. Een voordeel van deze aanpak is dat je meer specifiek kunt definiëren wat de relaties tussen de projecten zijn met behulp van tags en branches in de superprojects.
+Een goeie manier om dit in Git te doen is om elk van de subdirectories een aparte Git repository te maken en dan superproject Git repositories te maken die meerdere submodules bevatten. Een voordeel van deze aanpak is dat je meer specifiek kunt defini�ren wat de relaties tussen de projecten zijn met behulp van tags en branches in de superprojects.
 
 ### Problemen met submodules ###
 
-Submodules gebruiken is echter niet zonder probleempjes. Ten eerste moet je relatief voorzichtig zijn met het werken in de directory van de submodule. Als je `git submodule update` uitvoert, zal het de specifieke versie van het project uitchecken, maar niet binnen een branch. Dit wordt een afgekoppelde (detached) HEAD genoemd – het houdt in dat het HEAD bestand direct naar een commit wijst en niet naar een symbolische referentie. Het probleem is dat je over het algemeen niet wilt werken in een detached HEAD omgeving, omdat het eenvoudig is om wijzigingen te verliezen. Als je een initiële `submodule update` doet, in die submodule directory commit zonder een branch te maken om in te werken en dan nogmaals `git submodule update` uitvoert in het superproject zonder in de tussentijd te committen, dan zal Git je wijzigingen overschrijven zonder het je te vertellen. Technisch gezien ben je het werk niet kwijt, maar je zult geen branch hebben die er naar wijst, dus het zal wat lastig zijn om het terug te halen.
+Submodules gebruiken is echter niet zonder probleempjes. Ten eerste moet je relatief voorzichtig zijn met het werken in de directory van de submodule. Als je `git submodule update` uitvoert, zal het de specifieke versie van het project uitchecken, maar niet binnen een branch. Dit wordt een afgekoppelde (detached) HEAD genoemd - het houdt in dat het HEAD bestand direct naar een commit wijst en niet naar een symbolische referentie. Het probleem is dat je over het algemeen niet wilt werken in een detached HEAD omgeving, omdat het eenvoudig is om wijzigingen te verliezen. Als je een initi�le `submodule update` doet, in die submodule directory commit zonder een branch te maken om in te werken en dan nogmaals `git submodule update` uitvoert in het superproject zonder in de tussentijd te committen, dan zal Git je wijzigingen overschrijven zonder het je te vertellen. Technisch gezien ben je het werk niet kwijt, maar je zult geen branch hebben die er naar wijst, dus het zal wat lastig zijn om het terug te halen.
 
-Om dit probleem te vermijden creëer je een branch zodra je in een submodule directory werkt met behulp van `git checkout -b work` of iets dergelijks. Als je de tweede keer de submodule update doet, zal het nog steeds je werk terugdraaien maar je heb tenminste een pointer om naar terug te keren.
+Om dit probleem te vermijden cre�er je een branch zodra je in een submodule directory werkt met behulp van `git checkout -b work` of iets dergelijks. Als je de tweede keer de submodule update doet, zal het nog steeds je werk terugdraaien maar je heb tenminste een pointer om naar terug te keren.
 
 Tussen branches omschakelen die submodules bevatten kan ook lastig zijn. Als je een nieuwe branch aanmaakt, daar een submodule toevoegt en dat terug wisselt naar een branch zonder die submodule, zul je nog steeds de submodule directory als een ungetrackte subdirectory hebben:
 
@@ -1094,7 +1094,7 @@ Je moet de `rack` subdirectory eerst unstagen. Dan kun je de submodule toevoegen
 	Receiving objects: 100% (3184/3184), 677.42 KiB | 88 KiB/s, done.
 	Resolving deltas: 100% (1952/1952), done.
 
-Stel nu dat je dat in een branch gedaan zou hebben. Als je probeert terug te wisselen naar een branch waar die bestanden nog in de echte boom zitten in plaats van in een submodule – dan krijg je deze foutmelding:
+Stel nu dat je dat in een branch gedaan zou hebben. Als je probeert terug te wisselen naar een branch waar die bestanden nog in de echte boom zitten in plaats van in een submodule - dan krijg je deze foutmelding:
 
 	$ git checkout master
 	error: Untracked working tree file 'rack/AUTHORS' would be overwritten by merge.
@@ -1111,11 +1111,11 @@ Als je dan terug schakelt krijg je een lege `rack` directory. Je kunt dan nogmaa
 
 ## Subboom mergen ##
 
-Nu je de moeilijkheden van het submodulesysteem hebt gezien, laten we eens kijken naar een alternatieve manier om hetzelfde probleem aan te pakken. Zodra Git merged, kijkt het naar wat het moet mergen en kiest dan een toepasselijke mergestrategie om te gebruiken. Als je twee branches aan het mergen bent zal Git een _recursive_ strategie gebruiken. Als je meer dan twee branches aan het mergen bent zal Git de _octopus_ strategie kiezen. Deze strategieën worden automatisch voor je gekozen omdat de recursieve strategie complexe drie-weg merge situaties aan kan - bijvoorbeeld meer dan één gezamenlijke voorouder, maar het kan het alleen mergen van twee branches aan. De octopus merge kan meerdere branches aan, maar is voorzichtiger om moeilijke conflicten te vermijden, dus wordt deze gekozen als de standaard strategie als je meer dan twee branches probeert te mergen.
+Nu je de moeilijkheden van het submodulesysteem hebt gezien, laten we eens kijken naar een alternatieve manier om hetzelfde probleem aan te pakken. Zodra Git merged, kijkt het naar wat het moet mergen en kiest dan een toepasselijke mergestrategie om te gebruiken. Als je twee branches aan het mergen bent zal Git een _recursive_ strategie gebruiken. Als je meer dan twee branches aan het mergen bent zal Git de _octopus_ strategie kiezen. Deze strategie�n worden automatisch voor je gekozen omdat de recursieve strategie complexe drie-weg merge situaties aan kan - bijvoorbeeld meer dan ��n gezamenlijke voorouder, maar het kan het alleen mergen van twee branches aan. De octopus merge kan meerdere branches aan, maar is voorzichtiger om moeilijke conflicten te vermijden, dus wordt deze gekozen als de standaard strategie als je meer dan twee branches probeert te mergen.
 
-Maar er zijn andere strategieën die je ook kunt kiezen. Eén ervan is de _subtree_ merge, en je kunt deze gebruiken om het subproject probleem aan te gaan. Hier zul je zien hoe je dezelfde rack inbedding kunt doen als in de vorige paragraaf, maar in plaats daarvan subboom-merges gebruiken.
+Maar er zijn andere strategie�n die je ook kunt kiezen. E�n ervan is de _subtree_ merge, en je kunt deze gebruiken om het subproject probleem aan te gaan. Hier zul je zien hoe je dezelfde rack inbedding kunt doen als in de vorige paragraaf, maar in plaats daarvan subboom-merges gebruiken.
 
-Het idee van de subboom-merge is dat je twee projecten hebt, en één van de projecten komt overeen met een subdirectory van de andere en omgekeerd. Als je een subboommerge specificeert, dan is Git slim genoeg om erachter te komen dat de ene een subboom van de andere is en vervolgens juist te mergen - het is best wel verbazingwekkend.
+Het idee van de subboom-merge is dat je twee projecten hebt, en ��n van de projecten komt overeen met een subdirectory van de andere en omgekeerd. Als je een subboommerge specificeert, dan is Git slim genoeg om erachter te komen dat de ene een subboom van de andere is en vervolgens juist te mergen - het is best wel verbazingwekkend.
 
 Eerst voeg je de Rack applicatie toe aan je project. Voeg het Rack project toe als een remote reference in je eigen project en check het dan uit in zijn eigen branch:
 
@@ -1150,7 +1150,7 @@ Je gaat nu het Rack project in je `master` project pullen als een subdirectory.
 
 	$ git read-tree --prefix=rack/ -u rack_branch
 
-Als je commit, lijkt het alsof alle Rack bestanden in die subdirectory staan - alsof je ze uit een tarball gekopieerd hebt. Waar het interessant wordt is dat je vrij makkelijk veranderingen van één branch in de andere kunt mergen. Dus als het Rack project update kan je alle wijzigingen van stroomopwaartse binnenhalen door naar die branch te wisselen en te pullen:
+Als je commit, lijkt het alsof alle Rack bestanden in die subdirectory staan - alsof je ze uit een tarball gekopieerd hebt. Waar het interessant wordt is dat je vrij makkelijk veranderingen van ��n branch in de andere kunt mergen. Dus als het Rack project update kan je alle wijzigingen van stroomopwaartse binnenhalen door naar die branch te wisselen en te pullen:
 
 	$ git checkout rack_branch
 	$ git pull
@@ -1174,4 +1174,4 @@ Of om te vergelijken met wat in je `rack` subdirectory zit met wat in de `master
 
 ## Samenvatting ##
 
-Je hebt een aantal geavanceerde tools gezien, die je in staat stellen je commits en staging area heel exact te manipuleren. Als je problemen signaleert kun je vrij eenvoudig uitvinden welke commit deze geïntroduceerd heeft, wanneer, en door wie. Als je subprojecten in je project wilt gebruiken, heb je een paar manieren gezien hoe je die een plaats kunt geven. Nu zou je in staat moeten zijn om de meeste dingen in Git te doen die je dagelijks op de commandline moet doen, en je erbij op je gemak te voelen.
+Je hebt een aantal geavanceerde tools gezien, die je in staat stellen je commits en staging area heel exact te manipuleren. Als je problemen signaleert kun je vrij eenvoudig uitvinden welke commit deze ge�ntroduceerd heeft, wanneer, en door wie. Als je subprojecten in je project wilt gebruiken, heb je een paar manieren gezien hoe je die een plaats kunt geven. Nu zou je in staat moeten zijn om de meeste dingen in Git te doen die je dagelijks op de commandline moet doen, en je erbij op je gemak te voelen.

From 005cd217b06a92464aa00465235b4c0006f49154 Mon Sep 17 00:00:00 2001
From: Cor Takken <git@cpt1.demon.nl>
Date: Sun, 27 Apr 2014 16:41:38 +0200
Subject: [PATCH 385/690] [nl] - Corrections because of UTF-8 issue

---
 nl/06-git-tools/01-chapter6.markdown | 56 ++++++++++++++--------------
 1 file changed, 28 insertions(+), 28 deletions(-)

diff --git a/nl/06-git-tools/01-chapter6.markdown b/nl/06-git-tools/01-chapter6.markdown
index 413d0130e..667354d80 100644
--- a/nl/06-git-tools/01-chapter6.markdown
+++ b/nl/06-git-tools/01-chapter6.markdown
@@ -50,7 +50,7 @@ Natuurlijk kun je naar een commit refereren met de SHA-1 hash die het toegekend
 
 ### Korte SHA ###
 
-Git is slim genoeg om uit te vinden welke commit je bedoelde te typen als je het de eerste paar karakters geeft, zolang je gedeeltelijke SHA-1 maar minstens vier karakters lang en ondubbelzinnig is; dat wil zeggen dat slechts ��n object in de huidige repository begint met die gedeeltelijke SHA-1.
+Git is slim genoeg om uit te vinden welke commit je bedoelde te typen als je het de eerste paar karakters geeft, zolang je gedeeltelijke SHA-1 maar minstens vier karakters lang en ondubbelzinnig is; dat wil zeggen dat slechts één object in de huidige repository begint met die gedeeltelijke SHA-1.
 
 Bijvoorbeeld, stel dat je om een specifieke commit te zien een `git log` commando uitvoert en de commit identificeert waarin je een bepaalde functionaliteit hebt toegevoegd:
 
@@ -95,10 +95,10 @@ Veel mensen beginnen bezorgd te raken dat ze op een bepaald moment door puur toe
 
 Mocht je een object committen dat hashed naar dezelfde SHA-1 waarde als een vorig object in je repository, dan zal Git het vorige reeds aanwezige object in je Git database zien en aannemen dat het al geschreven was. Als je op een bepaald moment dat object opnieuw probeert uit te checken, dan zal je altijd de gegevens van het eerste object krijgen.
 
-<!-- Vraag: weet iemand de offici�le term voor botsingswaarschijnlijkheid? Via de Engelse Wikipedia kom ik (via collision probability) op universal hashing, maar is de formule niet te zien. -->
+<!-- Vraag: weet iemand de officiéle term voor botsingswaarschijnlijkheid? Via de Engelse Wikipedia kom ik (via collision probability) op universal hashing, maar is de formule niet te zien. -->
 Maar wat je moet beseffen is hoe vreselijk onwaarschijnlijk dit scenario is. De SHA-1 waarde is 20 bytes, oftewel 160 bits. Het aantal benodigde random gehashte objecten om een 50% waarschijnlijkheid van een botsing te garanderen is ongeveer 2^80 (de formule om botsingswaarschijnlijkheid te bepalen is `p = (n(n-1)/2) * (1/2^160)`). 2^80 is 1.2 x 10^24 of 1 miljoen miljard miljard. Dat is 1.200 keer het aantal zandkorrels op aarde.
 
-Hier is een voorbeeld om je een idee te geven wat er voor nodig is om een SHA-1 botsing te krijgen. Als alle 6.5 miljard mensen op aarde zouden programmeren, en iedere seconde zou ieder van hen code genereren die gelijk was aan de hele Linux kernel-geschiedenis (1 miljoen Git objecten) en dat in ��n gigantische Git repository pushen, dan zou het vijf jaar duren voordat die repository genoeg objecten zou bevatten om een 50% waarschijnlijkheid van ��n enkele SHA-1 object botsing te krijgen. De kans is groter dat elk lid van je programmeerteam zal worden aangevallen en gedood door wolven bij ongerelateerde incidenten op dezelfde avond.
+Hier is een voorbeeld om je een idee te geven wat er voor nodig is om een SHA-1 botsing te krijgen. Als alle 6.5 miljard mensen op aarde zouden programmeren, en iedere seconde zou ieder van hen code genereren die gelijk was aan de hele Linux kernel-geschiedenis (1 miljoen Git objecten) en dat in één gigantische Git repository pushen, dan zou het vijf jaar duren voordat die repository genoeg objecten zou bevatten om een 50% waarschijnlijkheid van één enkele SHA-1 object botsing te krijgen. De kans is groter dat elk lid van je programmeerteam zal worden aangevallen en gedood door wolven bij ongerelateerde incidenten op dezelfde avond.
 
 ### Branch referenties ###
 
@@ -183,7 +183,7 @@ Dan zie je de vorige commit door `HEAD^` te specificeren, wat "de ouder van HEAD
 
 	    Merge commit 'phedders/rdocs'
 
-Je kunt ook een getal na de `^` zetten, bijvoorbeeld `d921970^2` betekent "de tweede ouder van d921970." Deze syntax is alleen nuttig voor merge commits, omdat die meer dan ��n ouder hebben. De eerste ouder is de branch waar jij op was toen je mergede, en de andere is de commit op de branch die je gemerged hebt:
+Je kunt ook een getal na de `^` zetten, bijvoorbeeld `d921970^2` betekent "de tweede ouder van d921970." Deze syntax is alleen nuttig voor merge commits, omdat die meer dan één ouder hebben. De eerste ouder is de branch waar jij op was toen je mergede, en de andere is de commit op de branch die je gemerged hebt:
 
 	$ git show d921970^
 	commit 1c002dd4b536e7479fe34593e72e6c6c1819e53b
@@ -247,17 +247,17 @@ Dit is handig als je de `experiment` branch up to date wilt houden en alvast wil
 	$ git log origin/master..HEAD
 
 Dit commando toont je alle commits in je huidige branch, die niet in de `master` branch op de remote `origin` zitten. Als je een `git push` uitvoert, en je huidige branch volgt de `origin/master`, dan zijn de commits die getoond worden door `git log origin/master..HEAD` de commits die verstuurd zullen worden naar de server.
-Je kunt ook ��n kant van de syntax weglaten om Git de HEAD laten aannemen. Bijvoorbeeld, je krijgt dezelfde resultaten als in het vorige voorbeeld door `git log origin/master..` te typen - Git vult HEAD in als er ��n kant ontbreekt.
+Je kunt ook één kant van de syntax weglaten om Git de HEAD laten aannemen. Bijvoorbeeld, je krijgt dezelfde resultaten als in het vorige voorbeeld door `git log origin/master..` te typen - Git vult HEAD in als er één kant ontbreekt.
 
 #### Dubbele punten ####
 
-De syntax met de dubbel-punt is makkelijk als een afkorting, maar misschien wil je meer dan twee branches specificeren om je revisie aan te geven, zoals het zien welke commits in ��n van de branches in een reeks zitten, die nog niet in de branch zitten waar je nu op werkt. Git laat je dit doen door of het `^` karakter of `--not`, te gebruiken voor iedere referentie waarvan je de bereikbare commits niet wilt zien. Dus deze drie commando's zijn gelijk:
+De syntax met de dubbel-punt is makkelijk als een afkorting, maar misschien wil je meer dan twee branches specificeren om je revisie aan te geven, zoals het zien welke commits in één van de branches in een reeks zitten, die nog niet in de branch zitten waar je nu op werkt. Git laat je dit doen door of het `^` karakter of `--not`, te gebruiken voor iedere referentie waarvan je de bereikbare commits niet wilt zien. Dus deze drie commando's zijn gelijk:
 
 	$ git log refA..refB
 	$ git log ^refA refB
 	$ git log refB --not refA
 
-Dit is prettig omdat met deze syntax je meer dan twee referenties in je vraag kunt specificeren, wat je niet met de dubbel punt syntax kan doen. Bijvoorbeeld, als je alle commits wilt zien die bereikbaar zijn vanuit `refA` of `refB`, maar niet vanuit `refC`, dan kun je ��n van deze intypen:
+Dit is prettig omdat met deze syntax je meer dan twee referenties in je vraag kunt specificeren, wat je niet met de dubbel punt syntax kan doen. Bijvoorbeeld, als je alle commits wilt zien die bereikbaar zijn vanuit `refA` of `refB`, maar niet vanuit `refC`, dan kun je één van deze intypen:
 
 	$ git log refA refB ^refC
 	$ git log refA refB --not refC
@@ -266,7 +266,7 @@ Dit zorgt voor een erg krachtig revisie vraagsysteem dat je kan helpen om uit te
 
 #### Drievoudige punt ####
 
-De laatste veelgebruikte reeks-selectie syntax is de drievoudige punt syntax, wat alle commits specificeert die bereikbaar zijn door ��n van de twee referenties, maar niet door allebei. Kijk nog eens naar de voorbeeld commitgeschiedenis in Figuur 6-1.
+De laatste veelgebruikte reeks-selectie syntax is de drievoudige punt syntax, wat alle commits specificeert die bereikbaar zijn door één van de twee referenties, maar niet door allebei. Kijk nog eens naar de voorbeeld commitgeschiedenis in Figuur 6-1.
 Als je wilt zien wat in je `master` of in je `experiment` zit, maar geen gedeelde referenties, dan kun je dit uitvoeren
 
 	$ git log master...experiment
@@ -289,7 +289,7 @@ Met deze tools, kun je Git eenvoudiger laten weten welke commit of commits je wi
 
 ## Interactief stagen ##
 
-Bij Git worden een aantal scripts geleverd, die sommige commandline taken makkelijker maken. Hier zul je een aantal interactieve commando's zien, die je kunnen helpen om je commits zo samen te stellen dat ze alleen bepaalde combinaties en delen van bestanden bevatten. Deze tools zijn erg nuttig als je een reeks bestanden aanpast en dan besluit dat je deze wijzigingen in een aantal gefocuste commits wilt hebben in plaats van ��n grote rommelige commit. Op deze manier ben je er zeker van dat je commits logische aparte wijzigingensets zijn en makkelijk gereviewed kunnen worden door je mede-ontwikkelaars.
+Bij Git worden een aantal scripts geleverd, die sommige commandline taken makkelijker maken. Hier zul je een aantal interactieve commando's zien, die je kunnen helpen om je commits zo samen te stellen dat ze alleen bepaalde combinaties en delen van bestanden bevatten. Deze tools zijn erg nuttig als je een reeks bestanden aanpast en dan besluit dat je deze wijzigingen in een aantal gefocuste commits wilt hebben in plaats van één grote rommelige commit. Op deze manier ben je er zeker van dat je commits logische aparte wijzigingensets zijn en makkelijk gereviewed kunnen worden door je mede-ontwikkelaars.
 Als je `git add` uitvoert met de `-i` of `--interactive` optie, dan schakelt Git over naar een interactieve shell modus, waarbij zoiets als dit getoond wordt:
 
 	$ git add -i
@@ -396,7 +396,7 @@ Met deze simpele commando's kun je de interactieve toevoegmodus gebruiken om op
 
 ### Patches stagen ###
 
-Het is met Git ook mogelijk om bepaalde delen van bestanden te stagen en de rest niet. Bijvoorbeeld, als je twee wijzigingen maakt in je simplegit.rb bestand en ��n van die twee wilt stagen en de andere niet, dan is dat eenvoudig in Git. Vanaf de interactieve prompt, type `5` of `p` (voor patch). Git zal je vragen welke bestanden je deels wilt stagen en daarna, voor iedere sectie van de geselecteerde bestanden, zal het stukken van de bestandsdiff tonen en je vragen of je ze wilt stagen, ��n voor ��n:
+Het is met Git ook mogelijk om bepaalde delen van bestanden te stagen en de rest niet. Bijvoorbeeld, als je twee wijzigingen maakt in je simplegit.rb bestand en één van die twee wilt stagen en de andere niet, dan is dat eenvoudig in Git. Vanaf de interactieve prompt, type `5` of `p` (voor patch). Git zal je vragen welke bestanden je deels wilt stagen en daarna, voor iedere sectie van de geselecteerde bestanden, zal het stukken van de bestandsdiff tonen en je vragen of je ze wilt stagen, één voor één:
 
 	diff --git a/lib/simplegit.rb b/lib/simplegit.rb
 	index dd5ecc4..57399e0 100644
@@ -497,7 +497,7 @@ In dit geval waren er twee stashes al eerder opgeslagen, dus heb je toegang tot
 	#      modified:   lib/simplegit.rb
 	#
 
-Je kunt zien dat Git opnieuw de bestanden wijzigt die je uncommitte toen je de stash opsloeg. In dit geval had je een schone werkdirectory toen je de stash probeerde toe te passen, en dat je probeerde deze op dezelfde branch toe te passen als waar je hem van opgeslagen hebt. Maar het hebben van een schone werkdirectory en het toepassen op dezelfde branch zijn niet noodzakelijk om een stash succesvol toe te kunnen passen. Je kunt een stash op ��n branch opslaan, later naar een andere branch omschakelen, en daar opnieuw de wijzigingen toe proberen te passen. Je kunt ook gewijzigde en uncommitted bestanden in je werkdirectory hebben wanneer je een stash probeert toe te passen, Git geeft merge conflicten aan als iets niet meer netjes toe te passen is.
+Je kunt zien dat Git opnieuw de bestanden wijzigt die je uncommitte toen je de stash opsloeg. In dit geval had je een schone werkdirectory toen je de stash probeerde toe te passen, en dat je probeerde deze op dezelfde branch toe te passen als waar je hem van opgeslagen hebt. Maar het hebben van een schone werkdirectory en het toepassen op dezelfde branch zijn niet noodzakelijk om een stash succesvol toe te kunnen passen. Je kunt een stash op één branch opslaan, later naar een andere branch omschakelen, en daar opnieuw de wijzigingen toe proberen te passen. Je kunt ook gewijzigde en uncommitted bestanden in je werkdirectory hebben wanneer je een stash probeert toe te passen, Git geeft merge conflicten aan als iets niet meer netjes toe te passen is.
 
 De wijzigingen aan je bestanden zijn opnieuw toegepast, maar het bestand dat je eerder gestaged had is niet opnieuw gestaged. Om dat te doen moet je het `git stash apply` commando met de `--index` optie uitvoeren om het commando te vertellen de gestagede wijzigingen opnieuw proberen toe te passen. Als je dat had uitgevoerd, dan zou je weer op je originele uitgangspunt zijn uitgekomen:
 
@@ -565,7 +565,7 @@ Dit is een prettige manier om gestashed werk eenvoudig terug te halen en eraan t
 
 ## Geschiedenis herschrijven ##
 
-Vaak zal je, als je met Git werkt, je commit geschiedenis om een of andere reden willen aanpassen. �n van de mooie dingen van Git is dat het je in staat stelt om beslissingen op het laatst mogelijke moment te maken. Je kunt bepalen welke bestanden in welke commits gaan vlak voordat je commit, door middel van de staging area, je kunt besluiten dat je toch nog niet aan iets had willen beginnen met het stash commando en je kunt commits herschrijven ook al zijn ze al gebeurd, waardoor het lijkt alsof ze op een andere manier gebeurd zijn. Dit kan bijvoorbeeld de volgorde van de commits zijn, berichten of bestanden in een commit wijzigen, commits samenpersen(squashen) of opsplitsen, of complete commits weghalen - en dat allemaal voordat je jouw werk met anderen deelt.
+Vaak zal je, als je met Git werkt, je commit geschiedenis om een of andere reden willen aanpassen. Één van de mooie dingen van Git is dat het je in staat stelt om beslissingen op het laatst mogelijke moment te maken. Je kunt bepalen welke bestanden in welke commits gaan vlak voordat je commit, door middel van de staging area, je kunt besluiten dat je toch nog niet aan iets had willen beginnen met het stash commando en je kunt commits herschrijven ook al zijn ze al gebeurd, waardoor het lijkt alsof ze op een andere manier gebeurd zijn. Dit kan bijvoorbeeld de volgorde van de commits zijn, berichten of bestanden in een commit wijzigen, commits samenpersen(squashen) of opsplitsen, of complete commits weghalen - en dat allemaal voordat je jouw werk met anderen deelt.
 
 In deze paragraaf zal je leren hoe je deze handige taken uitvoert, zodat je jouw commit geschiedenis er uit kunt laten zien zoals jij dat wilt, voordat je het met anderen deelt.
 
@@ -656,7 +656,7 @@ Dit commando zal de andere twee commits automatisch toepassen, en je bent klaar.
 
 ### Commits opnieuw rangschikken ###
 
-Je kunt een interactieve rebase ook gebruiken om commits opnieuw te rangschikken of zijn geheel te verwijderen. Als je de "added cat-file" commit wilt verwijderen en de volgorde waarin de andere twee commits zijn ge�ntroduceerd wilt veranderen, dan kun je het rebase script van dit
+Je kunt een interactieve rebase ook gebruiken om commits opnieuw te rangschikken of zijn geheel te verwijderen. Als je de "added cat-file" commit wilt verwijderen en de volgorde waarin de andere twee commits zijn geïntroduceerd wilt veranderen, dan kun je het rebase script van dit
 
 	pick f7f3f6d changed my name a bit
 	pick 310154e updated README formatting and added blame
@@ -671,7 +671,7 @@ Als je dan opslaat en de editor sluit, zal Git je branch terugzetten naar de oud
 
 ### Een commit samenpersen (squashing) ###
 
-Het is ook mogelijk een serie commits te pakken en ze in ��n enkele commit samen te persen (squash) met het interactieve rebase tool. Het script stopt behulpzame instructies in het rebase bericht:
+Het is ook mogelijk een serie commits te pakken en ze in één enkele commit samen te persen (squash) met het interactieve rebase tool. Het script stopt behulpzame instructies in het rebase bericht:
 
 	#
 	# Commands:
@@ -767,7 +767,7 @@ Nu is de nieuwe project root elke keer de inhoud van de `trunk` subdirectory. Gi
 
 #### E-mail adressen globaal veranderen ####
 
-Een ander veel voorkomend geval is dat je vergeten bent om `git config` uit te voeren om je naam en e-mail adres in te stellen voordat je begon met werken, of misschien wil je een project op het werk open source maken en al je werk e-mail adressen veranderen naar je persoonlijke adres. Hoe dan ook, je kunt e-mail adressen in meerdere commits ook in ��n klap veranderen met `filter-branch`. Je moet wel oppassen dat je alleen die e-mail adressen aanpast die van jou zijn, dus gebruik je `--commit-filter`:
+Een ander veel voorkomend geval is dat je vergeten bent om `git config` uit te voeren om je naam en e-mail adres in te stellen voordat je begon met werken, of misschien wil je een project op het werk open source maken en al je werk e-mail adressen veranderen naar je persoonlijke adres. Hoe dan ook, je kunt e-mail adressen in meerdere commits ook in één klap veranderen met `filter-branch`. Je moet wel oppassen dat je alleen die e-mail adressen aanpast die van jou zijn, dus gebruik je `--commit-filter`:
 
 	$ git filter-branch --commit-filter '
 	        if [ "$GIT_AUTHOR_EMAIL" = "schacon@localhost" ];
@@ -787,7 +787,7 @@ Git levert ook een paar tools om je problemen te helpen debuggen in je projecten
 
 ### Aantekenen van bestanden ###
 
-Als je een bug in je code traceert en wilt weten wanneer het was ge�ntroduceerd en waarom, dan is bestands aantekenen vaak je beste methode. Het toont je welke commit de laatste was die iets wijzigde in een bepaald bestand. Dus als je ziet dat een methode in je code bugs bevat, dan kun je het bestand aantekenen met `git blame` om te zien wanneer een regel van de methode voor het laatst aangepast was en door wie. Dit voorbeeld gebruikt de `-L` optie om de output te beperken tot regel 12 tot en met 22:
+Als je een bug in je code traceert en wilt weten wanneer het was geïntroduceerd en waarom, dan is bestands aantekenen vaak je beste methode. Het toont je welke commit de laatste was die iets wijzigde in een bepaald bestand. Dus als je ziet dat een methode in je code bugs bevat, dan kun je het bestand aantekenen met `git blame` om te zien wanneer een regel van de methode voor het laatst aangepast was en door wie. Dit voorbeeld gebruikt de `-L` optie om de output te beperken tot regel 12 tot en met 22:
 
 	$ git blame -L 12,22 simplegit.rb
 	^4832fe2 (Scott Chacon  2008-03-15 10:31:28 -0700 12)  def show(tree = 'master')
@@ -835,7 +835,7 @@ Stel dat je zojuist een release van je code naar een productie omgeving gepusht
 	Bisecting: 6 revisions left to test after this
 	[ecb6e1bc347ccecc5f9350d878ce677feb13d3b2] error handling on repo
 
-Git heeft gezien dat er ongeveer 12 commits geweest zijn tussen de commit die je als laatste goede commit gemarkeerd hebt (v1.0) en de huidige slechte versie, en het heeft de middelste voor je uitgecheckt. Op dit punt kun je de test uitvoeren om te zien of het probleem op deze commit ook aanwezig is. Als dat zo is, dan was het probleem ergens voor deze middelste commit ge�ntroduceerd, zo niet dan is het probleem na deze commit ge�ntroduceerd. Het blijkt dat hier geen probleem is, dus vertel je Git dat door `git bisect good` te typen en je reis te vervolgen:
+Git heeft gezien dat er ongeveer 12 commits geweest zijn tussen de commit die je als laatste goede commit gemarkeerd hebt (v1.0) en de huidige slechte versie, en het heeft de middelste voor je uitgecheckt. Op dit punt kun je de test uitvoeren om te zien of het probleem op deze commit ook aanwezig is. Als dat zo is, dan was het probleem ergens voor deze middelste commit geïntroduceerd, zo niet dan is het probleem na deze commit geïntroduceerd. Het blijkt dat hier geen probleem is, dus vertel je Git dat door `git bisect good` te typen en je reis te vervolgen:
 
 	$ git bisect good
 	Bisecting: 3 revisions left to test after this
@@ -847,7 +847,7 @@ Nu zit je op een andere commit, halverwege degene die je zojuist getest hebt en
 	Bisecting: 1 revisions left to test after this
 	[f71ce38690acf49c1f3c9bea38e09d82a5ce6014] drop exceptions table
 
-Deze commit is in orde, en nu heeft Git alle informatie die het nodig heeft om vast te stellen wanneer het probleem was ge�ntroduceerd. Het vertelt je de SHA-1 van de eerste slechte commit en toont een stukje commit informatie en welke bestanden aangepast waren in die commit, zodat je er achter kunt komen wat deze bug ge�ntroduceerd kan hebben:
+Deze commit is in orde, en nu heeft Git alle informatie die het nodig heeft om vast te stellen wanneer het probleem was geïntroduceerd. Het vertelt je de SHA-1 van de eerste slechte commit en toont een stukje commit informatie en welke bestanden aangepast waren in die commit, zodat je er achter kunt komen wat deze bug geïntroduceerd kan hebben:
 
 	$ git bisect good
 	b047b02ea83310a70fd603dc8cd7a6cd13d15c04 is first bad commit
@@ -875,7 +875,7 @@ Door het zo te doen wordt `test-error.sh` uitgevoerd bij elke commit die uitgech
 
 Het komt vaak voor dat terwijl je zit te werken aan het ene project, je een ander project daarbinnen moet gebruiken. Bijvoorbeeld een library die een derde partij ontwikkeld heeft, of die je separaat aan het ontwikkelen bent en gebruikt in meerdere projecten. Een veel voorkomend probleem komt in deze scenario's naar voren: je wilt de twee projecten apart behandelen, maar wel binnen de andere kunnen gebruiken.
 
-Hier is een voorbeeld. Stel dat je een website aan het ontwikkelen bent en Atom feeds aan het maken bent. In plaats van je eigen Atom-genererende code te schrijven, besluit je een library te gebruiken. Je zult deze code dan moeten includen van een gedeelde library zoals een CPAN installatie of een Ruby gem, of de broncode kopi�ren naar je eigen projectboom. Het probleem met de library includen is dat het lastig is om de library op enige manier aan te passen, en vaak nog lastiger is om het uit te rollen omdat je zeker moet zijn dat iedere client die library beschikbaar heeft. Het probleem van de broncode in je project stoppen is dat alle aanpassingen die je maakt lastig te mergen zijn op het moment dat stroomopwaarts veranderingen beschikbaar komen.
+Hier is een voorbeeld. Stel dat je een website aan het ontwikkelen bent en Atom feeds aan het maken bent. In plaats van je eigen Atom-genererende code te schrijven, besluit je een library te gebruiken. Je zult deze code dan moeten includen van een gedeelde library zoals een CPAN installatie of een Ruby gem, of de broncode kopiéren naar je eigen projectboom. Het probleem met de library includen is dat het lastig is om de library op enige manier aan te passen, en vaak nog lastiger is om het uit te rollen omdat je zeker moet zijn dat iedere client die library beschikbaar heeft. Het probleem van de broncode in je project stoppen is dat alle aanpassingen die je maakt lastig te mergen zijn op het moment dat stroomopwaarts veranderingen beschikbaar komen.
 
 Git pakt dit probleem aan door submodules te gebruiken. Submodules geven je de mogelijkheid om een Git repository als een subdirectory van een ander Git repository te gebruiken. Dit stelt je in staat staat een ander repository in je project te klonen en je commits gescheiden te houden.
 
@@ -1023,7 +1023,7 @@ Dit is het omdat de pointer die je hebt voor de submodule niet is wat eigenlijk
 
 Je moet dit iedere keer doen wanneer je een submodule wijziging pulled in het hoofdproject. Het is vreemd, maar het werkt.
 
-�n bekend probleem doet zich voor als een developer een lokale wijziging in een submodule doet maar die niet naar een publieke server pusht. Dan committen ze een pointer naar de niet-publieke status en pushen deze naar het superproject. Als andere developers dan `git submodule update` proberen uit te voeren, dan zal het submodule systeem de commit die gerefereerd wordt niet kunnen vinden omdat het alleen op het systeem van de eerste developer bestaat. Als dat gebeurt, zal je een foutmelding als deze zien:
+Één bekend probleem doet zich voor als een developer een lokale wijziging in een submodule doet maar die niet naar een publieke server pusht. Dan committen ze een pointer naar de niet-publieke status en pushen deze naar het superproject. Als andere developers dan `git submodule update` proberen uit te voeren, dan zal het submodule systeem de commit die gerefereerd wordt niet kunnen vinden omdat het alleen op het systeem van de eerste developer bestaat. Als dat gebeurt, zal je een foutmelding als deze zien:
 
 	$ git submodule update
 	fatal: reference isn’t a tree: 6c5e70b984a60b3cecd395edd5b48a7575bf58e0
@@ -1044,13 +1044,13 @@ Dan stuur je een e-mail naar die jongen en gaat heel boos zijn tegen hem.
 
 Soms willen developers een combinatie van subdirectories van een groot project hebben, afhankelijk van het team waarin ze zitten. Dit komt vaak voor als je van CVS of Subversion af komt, waar je een module of verzameling subdirectory gedefinieerd hebt en je wilt deze workflow behouden.
 
-Een goeie manier om dit in Git te doen is om elk van de subdirectories een aparte Git repository te maken en dan superproject Git repositories te maken die meerdere submodules bevatten. Een voordeel van deze aanpak is dat je meer specifiek kunt defini�ren wat de relaties tussen de projecten zijn met behulp van tags en branches in de superprojects.
+Een goeie manier om dit in Git te doen is om elk van de subdirectories een aparte Git repository te maken en dan superproject Git repositories te maken die meerdere submodules bevatten. Een voordeel van deze aanpak is dat je meer specifiek kunt definiéren wat de relaties tussen de projecten zijn met behulp van tags en branches in de superprojects.
 
 ### Problemen met submodules ###
 
-Submodules gebruiken is echter niet zonder probleempjes. Ten eerste moet je relatief voorzichtig zijn met het werken in de directory van de submodule. Als je `git submodule update` uitvoert, zal het de specifieke versie van het project uitchecken, maar niet binnen een branch. Dit wordt een afgekoppelde (detached) HEAD genoemd - het houdt in dat het HEAD bestand direct naar een commit wijst en niet naar een symbolische referentie. Het probleem is dat je over het algemeen niet wilt werken in een detached HEAD omgeving, omdat het eenvoudig is om wijzigingen te verliezen. Als je een initi�le `submodule update` doet, in die submodule directory commit zonder een branch te maken om in te werken en dan nogmaals `git submodule update` uitvoert in het superproject zonder in de tussentijd te committen, dan zal Git je wijzigingen overschrijven zonder het je te vertellen. Technisch gezien ben je het werk niet kwijt, maar je zult geen branch hebben die er naar wijst, dus het zal wat lastig zijn om het terug te halen.
+Submodules gebruiken is echter niet zonder probleempjes. Ten eerste moet je relatief voorzichtig zijn met het werken in de directory van de submodule. Als je `git submodule update` uitvoert, zal het de specifieke versie van het project uitchecken, maar niet binnen een branch. Dit wordt een afgekoppelde (detached) HEAD genoemd - het houdt in dat het HEAD bestand direct naar een commit wijst en niet naar een symbolische referentie. Het probleem is dat je over het algemeen niet wilt werken in een detached HEAD omgeving, omdat het eenvoudig is om wijzigingen te verliezen. Als je een initiéle `submodule update` doet, in die submodule directory commit zonder een branch te maken om in te werken en dan nogmaals `git submodule update` uitvoert in het superproject zonder in de tussentijd te committen, dan zal Git je wijzigingen overschrijven zonder het je te vertellen. Technisch gezien ben je het werk niet kwijt, maar je zult geen branch hebben die er naar wijst, dus het zal wat lastig zijn om het terug te halen.
 
-Om dit probleem te vermijden cre�er je een branch zodra je in een submodule directory werkt met behulp van `git checkout -b work` of iets dergelijks. Als je de tweede keer de submodule update doet, zal het nog steeds je werk terugdraaien maar je heb tenminste een pointer om naar terug te keren.
+Om dit probleem te vermijden creéer je een branch zodra je in een submodule directory werkt met behulp van `git checkout -b work` of iets dergelijks. Als je de tweede keer de submodule update doet, zal het nog steeds je werk terugdraaien maar je heb tenminste een pointer om naar terug te keren.
 
 Tussen branches omschakelen die submodules bevatten kan ook lastig zijn. Als je een nieuwe branch aanmaakt, daar een submodule toevoegt en dat terug wisselt naar een branch zonder die submodule, zul je nog steeds de submodule directory als een ungetrackte subdirectory hebben:
 
@@ -1111,11 +1111,11 @@ Als je dan terug schakelt krijg je een lege `rack` directory. Je kunt dan nogmaa
 
 ## Subboom mergen ##
 
-Nu je de moeilijkheden van het submodulesysteem hebt gezien, laten we eens kijken naar een alternatieve manier om hetzelfde probleem aan te pakken. Zodra Git merged, kijkt het naar wat het moet mergen en kiest dan een toepasselijke mergestrategie om te gebruiken. Als je twee branches aan het mergen bent zal Git een _recursive_ strategie gebruiken. Als je meer dan twee branches aan het mergen bent zal Git de _octopus_ strategie kiezen. Deze strategie�n worden automatisch voor je gekozen omdat de recursieve strategie complexe drie-weg merge situaties aan kan - bijvoorbeeld meer dan ��n gezamenlijke voorouder, maar het kan het alleen mergen van twee branches aan. De octopus merge kan meerdere branches aan, maar is voorzichtiger om moeilijke conflicten te vermijden, dus wordt deze gekozen als de standaard strategie als je meer dan twee branches probeert te mergen.
+Nu je de moeilijkheden van het submodulesysteem hebt gezien, laten we eens kijken naar een alternatieve manier om hetzelfde probleem aan te pakken. Zodra Git merged, kijkt het naar wat het moet mergen en kiest dan een toepasselijke mergestrategie om te gebruiken. Als je twee branches aan het mergen bent zal Git een _recursive_ strategie gebruiken. Als je meer dan twee branches aan het mergen bent zal Git de _octopus_ strategie kiezen. Deze strategieén worden automatisch voor je gekozen omdat de recursieve strategie complexe drie-weg merge situaties aan kan - bijvoorbeeld meer dan één gezamenlijke voorouder, maar het kan het alleen mergen van twee branches aan. De octopus merge kan meerdere branches aan, maar is voorzichtiger om moeilijke conflicten te vermijden, dus wordt deze gekozen als de standaard strategie als je meer dan twee branches probeert te mergen.
 
-Maar er zijn andere strategie�n die je ook kunt kiezen. E�n ervan is de _subtree_ merge, en je kunt deze gebruiken om het subproject probleem aan te gaan. Hier zul je zien hoe je dezelfde rack inbedding kunt doen als in de vorige paragraaf, maar in plaats daarvan subboom-merges gebruiken.
+Maar er zijn andere strategieén die je ook kunt kiezen. Eén ervan is de _subtree_ merge, en je kunt deze gebruiken om het subproject probleem aan te gaan. Hier zul je zien hoe je dezelfde rack inbedding kunt doen als in de vorige paragraaf, maar in plaats daarvan subboom-merges gebruiken.
 
-Het idee van de subboom-merge is dat je twee projecten hebt, en ��n van de projecten komt overeen met een subdirectory van de andere en omgekeerd. Als je een subboommerge specificeert, dan is Git slim genoeg om erachter te komen dat de ene een subboom van de andere is en vervolgens juist te mergen - het is best wel verbazingwekkend.
+Het idee van de subboom-merge is dat je twee projecten hebt, en één van de projecten komt overeen met een subdirectory van de andere en omgekeerd. Als je een subboommerge specificeert, dan is Git slim genoeg om erachter te komen dat de ene een subboom van de andere is en vervolgens juist te mergen - het is best wel verbazingwekkend.
 
 Eerst voeg je de Rack applicatie toe aan je project. Voeg het Rack project toe als een remote reference in je eigen project en check het dan uit in zijn eigen branch:
 
@@ -1150,7 +1150,7 @@ Je gaat nu het Rack project in je `master` project pullen als een subdirectory.
 
 	$ git read-tree --prefix=rack/ -u rack_branch
 
-Als je commit, lijkt het alsof alle Rack bestanden in die subdirectory staan - alsof je ze uit een tarball gekopieerd hebt. Waar het interessant wordt is dat je vrij makkelijk veranderingen van ��n branch in de andere kunt mergen. Dus als het Rack project update kan je alle wijzigingen van stroomopwaartse binnenhalen door naar die branch te wisselen en te pullen:
+Als je commit, lijkt het alsof alle Rack bestanden in die subdirectory staan - alsof je ze uit een tarball gekopieerd hebt. Waar het interessant wordt is dat je vrij makkelijk veranderingen van één branch in de andere kunt mergen. Dus als het Rack project update kan je alle wijzigingen van stroomopwaartse binnenhalen door naar die branch te wisselen en te pullen:
 
 	$ git checkout rack_branch
 	$ git pull
@@ -1174,4 +1174,4 @@ Of om te vergelijken met wat in je `rack` subdirectory zit met wat in de `master
 
 ## Samenvatting ##
 
-Je hebt een aantal geavanceerde tools gezien, die je in staat stellen je commits en staging area heel exact te manipuleren. Als je problemen signaleert kun je vrij eenvoudig uitvinden welke commit deze ge�ntroduceerd heeft, wanneer, en door wie. Als je subprojecten in je project wilt gebruiken, heb je een paar manieren gezien hoe je die een plaats kunt geven. Nu zou je in staat moeten zijn om de meeste dingen in Git te doen die je dagelijks op de commandline moet doen, en je erbij op je gemak te voelen.
+Je hebt een aantal geavanceerde tools gezien, die je in staat stellen je commits en staging area heel exact te manipuleren. Als je problemen signaleert kun je vrij eenvoudig uitvinden welke commit deze geïntroduceerd heeft, wanneer, en door wie. Als je subprojecten in je project wilt gebruiken, heb je een paar manieren gezien hoe je die een plaats kunt geven. Nu zou je in staat moeten zijn om de meeste dingen in Git te doen die je dagelijks op de commandline moet doen, en je erbij op je gemak te voelen.

From 5a321321a9e04ad3d19b7978082ec5b809fdc50e Mon Sep 17 00:00:00 2001
From: nicesw123 <nicesw123@users.noreply.github.com>
Date: Sun, 27 Apr 2014 20:53:28 +0200
Subject: [PATCH 386/690] Expl: in `git log --after=2008-10-01` the time
 defaults to the time the command is run. So e.g. the command is equiv to `git
 log --after="2008-10-01 09:00:00"` when run at 09:00:00

---
 en/02-git-basics/01-chapter2.markdown | 15 +++++++++++++--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/en/02-git-basics/01-chapter2.markdown b/en/02-git-basics/01-chapter2.markdown
index 8090ba342..2d8793891 100644
--- a/en/02-git-basics/01-chapter2.markdown
+++ b/en/02-git-basics/01-chapter2.markdown
@@ -659,8 +659,11 @@ The lines must be formatted as follows
 
 For example, if you want to see which commits modifying test files in the Git source code history were committed by Junio Hamano in the month of October 2008 and were not merges, you can run something like this:
 
-	$ git log --pretty="%h - %s" --author=gitster --since="2008-10-01" \
-	   --before="2008-11-01" --no-merges -- t/
+	$ # get dates on-or-after  "2008-10-01 00:00:00"
+	$ # and       on-or-before "2008-11-01 00:00:00"
+	$
+	$ git log --pretty="%h - %s" --author=gitster --after="2008-10-01 00:00:00" \
+	   --before="2008-11-01 00:00:00" --no-merges -- t/
 	5610e3b - Fix testcase failure when extended attribute
 	acd3b9e - Enhance hold_lock_file_for_{update,append}()
 	f563754 - demonstrate breakage of detached checkout wi
@@ -670,6 +673,14 @@ For example, if you want to see which commits modifying test files in the Git so
 
 Of the nearly 20,000 commits in the Git source code history, this command shows the 6 that match those criteria.
 
+When using `git log` without specifying time,
+
+	git log --after=2008-10-01 --before=2008-11-01
+
+then it defaults to using the time at the instant the command is executed. For example when the above command is executed at time 09:00:00, then the result is equivalent to doing:
+
+	git log --after="2008-10-01 09:00:00" --before="2008-11-01 09:00:00"
+
 ### Using a GUI to Visualize History ###
 
 If you like to use a more graphical tool to visualize your commit history, you may want to take a look at a Tcl/Tk program called `gitk` that is distributed with Git. Gitk is basically a visual `git log` tool, and it accepts nearly all the filtering options that `git log` does. If you type `gitk` on the command line in your project, you should see something like Figure 2-2.

From 7a6b7d18d7bfbd6f027f4ed743ba3743f033cc1e Mon Sep 17 00:00:00 2001
From: Ciro Santilli <ciro.santilli@gmail.com>
Date: Mon, 28 Apr 2014 16:53:39 +0200
Subject: [PATCH 387/690] Set dummy merge driver merge ours .gitattributes.

---
 en/07-customizing-git/01-chapter7.markdown | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/en/07-customizing-git/01-chapter7.markdown b/en/07-customizing-git/01-chapter7.markdown
index 7029378e5..a71e44d53 100644
--- a/en/07-customizing-git/01-chapter7.markdown
+++ b/en/07-customizing-git/01-chapter7.markdown
@@ -535,6 +535,10 @@ This is helpful if a branch in your project has diverged or is specialized, but
 
 	database.xml merge=ours
 
+And then define a dummy `ours` merge strategy with:
+
+    git config --global merge.ours.driver true
+
 If you merge in the other branch, instead of having merge conflicts with the database.xml file, you see something like this:
 
 	$ git merge topic

From 949cfa3736c0891791d7d9da06591c47dd11d4b5 Mon Sep 17 00:00:00 2001
From: kanhua <kanhwa@gmail.com>
Date: Tue, 29 Apr 2014 23:15:31 +0100
Subject: [PATCH 388/690] imporve some zh-tw translation in git-diff section

---
 zh-tw/02-git-basics/01-chapter2.markdown | 27 ++++++++++++------------
 1 file changed, 14 insertions(+), 13 deletions(-)

diff --git a/zh-tw/02-git-basics/01-chapter2.markdown b/zh-tw/02-git-basics/01-chapter2.markdown
index 467ec27f8..2f80c92c1 100644
--- a/zh-tw/02-git-basics/01-chapter2.markdown
+++ b/zh-tw/02-git-basics/01-chapter2.markdown
@@ -1,6 +1,6 @@
 # Git 基礎 #
 
-若讀者只需要閱讀一個章節即可開始使用Git，這章就是你所需要的。 本章節涵蓋讀者大部份用到Git時需要使用的所有基本命令。 在讀完本章節後，讀者應該有能力組態及初始化一個儲存庫、開始及停止追蹤檔案、暫存及提交更新。 還會提到如何讓Git忽略某些檔案、如何輕鬆且很快地救回失誤、如何瀏覽讀者的專案歷史及觀看各個已提交的更新之間的變更、以及如何從遠端儲存庫`拉`更新下來或將更新`推`上去。
+讀完這一章，你就可以開始使用Git了。本章節涵蓋大部份最常被使用的Git基本指令。 在讀完本章節後，讀者應該有能力組態及初始化一個儲存庫(repository)、開始及停止追蹤檔案(track)、暫存(stage)及提交(commit)更新。 本章還會提到如何讓Git忽略某些檔案、如何輕鬆且很快地救回失誤、如何瀏覽讀者的專案歷史及觀看各個已提交的更新之間的變更、以及如何從遠端儲存庫`拉`(pull)更新下來或將更新`推`(push)上去。
 
 ## 取得Git儲存庫 ##
 
@@ -57,7 +57,7 @@ Insert 18333fig0201.png
 	On branch master
 	nothing to commit, working directory clean
 
-這意謂著讀者有一份乾淨的工作目錄（換句話說，沒有未被追蹤或已被修改的檔案）。 Git未看到任何未被追蹤的檔案，否則會將它們列出。 最後，這個命令告訴讀者目前在哪一個分支。 到目前為止，一直都是master，這是預設的。 目前讀者不用考慮它。 下一個章節會詳細介紹分支。
+Wokring directory clean意謂著目前的工作目錄沒有未被追蹤或已被修改的檔案。Git未看到任何未被追蹤的檔案，否則會將它們列出。 最後，這個命令告訴讀者目前在哪一個分支(branch)。到目前為止，一直都是master，這是預設的。下一個章節會詳細介紹分支(branch)，目前我們先不考慮它。
 
 假設讀者新增一些檔案到專案，如`README`。 若該檔案先前並不存在，執行 `git status` 命令後，讀者會看到未被追蹤的檔案，如下：
 
@@ -71,15 +71,15 @@ Insert 18333fig0201.png
 
 	nothing added to commit but untracked files present (use "git add" to track)
 
-讀者可看到新增的`README`尚未被追蹤，因為它被列在輸出訊息的 Untracked files 下方。 除非讀者明確指定要將該檔案加入提交的快照，Git不會主動將它加入。 這樣就不會突然地將一些二進位格式的檔案或其它讀者並不想加入的檔案含入。 讀者的確是要新增 `README` 檔案，因此讓我們開始追蹤該檔案。
+我們可以看到新增的`README`尚未被追蹤，因為它被列在輸出訊息的 Untracked files 下方。 除非我們明確指定要將該檔案加入提交的快照，Git不會主動將它加入。這樣可以避免加入一些二進位格式的檔案或其它使用者不想列入追蹤的檔案。 不過在這個例子中，我們的確是要將 `README` 檔案加入追蹤:
 
 ### 追蹤新檔案 ###
 
-要追蹤新增的檔案，讀者可使用`git add`命令。 欲追蹤`README`檔案，讀者可執行：
+要追蹤新增的檔案，我們可以使用`git add`命令。例如:要追蹤`README`檔案，可執行：
 
 	$ git add README
 
-若讀者再度檢查目前狀態，可看到`README`檔案已被列入追蹤並且已被暫存：
+如此一來，我們重新檢查狀態(status)時，可看到`README`檔案已被列入追蹤並且已被暫存：
 
 	$ git status
 	On branch master
@@ -89,11 +89,11 @@ Insert 18333fig0201.png
 	        new file:   README
 	
 
-因為它被放在Changes to be commited文字下方，讀者可得知它已被暫存起來。 若讀者此時提交更新，剛才執行`git add`加進來的檔案就會被記錄在歷史的快照。 讀者可能可回想一下先前執行`git init`後也有執行過`git add`，開始追蹤目錄內的檔案。 `git add`命令可接受檔名或者目錄名。 若是目錄名，會遞迴將整個目錄下所有檔案及子目錄都加進來。
+因為它被放在Changes to be commited文字下方，讀者可得知它已被暫存起來。 若讀者此時提交更新，剛才執行`git add`加進來的檔案就會被記錄在歷史的快照。 讀者可能可回想一下先前執行`git init`後也有執行過`git add`，開始追蹤目錄內的檔案。`git add`命令可接受檔名或者目錄名。 若是目錄名，Git會以遞迴(recursive)的方式會將整個目錄下所有檔案及子目錄都加進來。
 
 ### 暫存已修改檔案 ###
 
-讓我們修改已被追蹤的檔案。 若讀者修改先前已被追蹤的檔案，名為`benchmarks.rb`，並檢查目前儲存庫的狀態。 讀者會看到類似以下文字：
+讓我們修改已被追蹤的檔案。 若讀者修改先前已被追蹤的檔案，名為`benchmarks.rb`，並檢查目前儲存庫的狀態。我們會看到類似以下文字：
 
 	$ git status
 	On branch master
@@ -159,7 +159,7 @@ Insert 18333fig0201.png
 	*.[oa]
 	*~
 
-第一列告訴Git忽略任何檔名為`.o`或`.a`結尾的檔案，它們是可能是編譯系統建置讀者的程式碼時產生的目的檔及程式庫。 第二列告訴Git忽略所有檔名為~結尾的檔案，通常被很多文書編輯器，如：Emacs，使用的暫存檔案。 讀者可能會想一併將log、tmp、pid目錄及自動產生的文件等也一併加進來。 依據類推。 在讀者要開始開發之前將`.gitignore`設定好，通常是一個不錯的點子。 這樣子讀者不會意外地將真的不想追蹤的檔案提交到Git儲存庫。
+第一列告訴Git忽略任何檔名為`.o`或`.a`結尾的檔案，它們是可能是編譯系統建置讀者的程式碼時產生的目的檔及程式庫。 第二列告訴Git忽略所有檔名為~結尾的檔案，通常被很多文書編輯器，如：Emacs，使用的暫存檔案。 讀者可能會想一併將log、tmp、pid目錄及自動產生的文件等也一併加進來。 依據類推。在讀者要開始開發之前將`.gitignore`設定好，通常是一個不錯的點子。這樣子讀者不會意外地將真的不想追蹤的檔案提交到Git儲存庫。
 
 編寫`.gitignore`檔案的規則如下：
 
@@ -190,9 +190,10 @@ A `**/` pattern is available in Git since version 1.8.2.
 
 ### 檢視已暫存及尚未暫存的更動 ###
 
-若`git status`命令仍無法清楚告訴讀者想要的資訊（讀者想知道的是更動了哪些內容，而不是哪些檔案）。 可使用`git diff`命令。 稍後我們會更詳盡講解該命令。 讀者使用它時通常會是為了瞭解兩個問題： 目前已做的修改但尚未暫存的內容是哪些？ 以及將被提交的暫存資料有哪些？ 雖然`git status`一般來說即可回答這些問題。 `git diff`可精確的顯示哪些列被加入或刪除，以修補檔方式表達。
+在某些情況下，`git status`指令提供的資訊就太過簡要。
+有的時候我們不只想知道那些檔案被更動，而是想更進一步知道被檔案的內容被做了那些修改，這時我們可以使用`git diff`命令。稍後我們會有更詳盡講解該命令。讀者使用它時通常會是為了瞭解兩個問題：目前已做的修改但尚未暫存的內容是哪些？以及將被提交的暫存資料有哪些？儘管`git status`指令可以大略回答這些問題，但`git diff`可顯示檔案裡的哪些列被加入或刪除，以修補檔(patch)方式表達。
 
-假設讀者編輯並暫存`README`，接者修改`benchmarks.rb`檔案，卻未暫存。 若讀者檢視目前的狀況，會看到類似下方文字：
+假設讀者編輯並暫存(stage)`README`，接著修改`benchmarks.rb`檔案，卻未暫存。若讀者檢視目前的狀況，會看到類似下方文字：
 
 	$ git status
 	On branch master
@@ -227,9 +228,9 @@ A `**/` pattern is available in Git since version 1.8.2.
 	           log = git.commits('master', 15)
 	           log.size
 
-這命令比對目前工作目錄及暫存區域後告訴讀者哪些變更尚未被暫存。
+這命令會比對目前工作目錄(working directory)及暫存區域(stage area)的版本，然後顯示尚未被存入暫存區(stage area)的變更。
 
-若讀者想知道將被提交的暫存資料，使用`git diff --cached`（在Git 1.6.1及更新版本，也可以使用較易記憶的`git diff --staged` 命令）。 這命令比對暫存區域及最後一個提交。
+若讀者想比對暫存區域(stage)及最後一次提交(commit)的差異，可用`git diff --cached`指令（Git 1.6.1之後的版本，可用較易記的`git diff --staged` 指令）:
 
 	$ git diff --cached
 	diff --git a/README b/README
@@ -244,7 +245,7 @@ A `**/` pattern is available in Git since version 1.8.2.
 	+
 	+Grit is a Ruby library for extracting information from a Git repository
 
-很重要的一點是`git diff`不會顯示最後一次commit後的所有變更；只會顯示尚未暫存的變更。 這一點可能會混淆，若讀者已暫存所有的變更，`git diff`不會顯示任何資訊。
+很重要的一點是`git diff`不會顯示最後一次commit後的所有變更；只會顯示尚未存入暫存區(即unstaged)的變更。這麼說可能會混淆，舉個例子來說，若讀者已暫存(stage)所有的變更，輸入`git diff`不會顯示任何資訊。
 
 舉其它例子，若讀者暫存`benchmarks.rb`檔案後又編輯，可使用`git diff`看已暫存的版本與工作目錄內版本尚未暫存的變更：
 

From e34582af22e06214928ac2120e4db08e3de7654e Mon Sep 17 00:00:00 2001
From: Carlos Arturo Guerra Parra <carlosarturoguerra@gmail.com>
Date: Thu, 1 May 2014 16:55:31 +0200
Subject: [PATCH 389/690] [es] Update chapter 1: grammatical change
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Versión previa: "Git no guarda todo por nombre de archivo, sino..." Versión modificada: "Git guarda todo no por nombre de archivo, sino..."

La modificación se adecúa más al texto inglés: "Git stores everything not by file name but..."

También podría haberse traducido por: "Git no guarda nada por nombre de archivo, sino...", que viene a significar lo mismo.
---
 es/01-introduction/01-chapter1.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/es/01-introduction/01-chapter1.markdown b/es/01-introduction/01-chapter1.markdown
index 793f342e6..f91e3d103 100644
--- a/es/01-introduction/01-chapter1.markdown
+++ b/es/01-introduction/01-chapter1.markdown
@@ -87,7 +87,7 @@ El mecanismo que usa Git para generar esta suma de comprobación se conoce como
 
 	24b9da6552252987aa493b52f8696cd6d3b00373
 
-Verás estos valores hash por todos lados en Git, ya que los usa con mucha frecuencia. De hecho, Git no guarda todo por nombre de archivo, sino por el valor hash de sus contenidos.
+Verás estos valores hash por todos lados en Git, ya que los usa con mucha frecuencia. De hecho, Git guarda todo no por nombre de archivo, sino por el valor hash de sus contenidos.
 
 ### Git generalmente sólo añade información ###
 

From fb1c50ad1f163fe6460c1ec4295c19c75c6a266f Mon Sep 17 00:00:00 2001
From: Carlos Arturo Guerra Parra <carlosarturoguerra@gmail.com>
Date: Thu, 1 May 2014 17:04:14 +0200
Subject: [PATCH 390/690] [es] Update chapter 1: grammatical change: extra
 commas
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Sobra una coma en la enumeración antes de la conjunción "y"
---
 es/01-introduction/01-chapter1.markdown | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/es/01-introduction/01-chapter1.markdown b/es/01-introduction/01-chapter1.markdown
index f91e3d103..2e96b9da2 100644
--- a/es/01-introduction/01-chapter1.markdown
+++ b/es/01-introduction/01-chapter1.markdown
@@ -102,7 +102,7 @@ Ahora presta atención. Esto es lo más importante a recordar acerca de Git si q
 Esto nos lleva a las tres secciones principales de un proyecto de Git: el directorio de Git (Git directory), el directorio de trabajo (working directory), y el área de preparación (staging area).
 
 Insert 18333fig0106.png
-Figura 1-6. Directorio de trabajo, área de preparación, y directorio de Git.
+Figura 1-6. Directorio de trabajo, área de preparación y directorio de Git.
 
 El directorio de Git es donde Git almacena los metadatos y la base de datos de objetos para tu proyecto. Es la parte más importante de Git, y es lo que se copia cuando clonas un repositorio desde otro ordenador.
 
@@ -126,7 +126,7 @@ Vamos a empezar a usar un poco de Git. Lo primero es lo primero: tienes que inst
 
 Si puedes, en general es útil instalar Git desde código fuente, porque obtendrás la versión más reciente. Cada versión de Git tiende a incluir útiles mejoras en la interfaz de usuario, por lo que utilizar la última versión es a menudo el camino más adecuado si te sientes cómodo compilando software desde código fuente. También ocurre que muchas distribuciones de Linux contienen paquetes muy antiguos; así que a menos que estés en una distribución muy actualizada o estés usando backports, instalar desde código fuente puede ser la mejor opción.
 
-Para instalar Git, necesitas tener las siguientes librerías de las que Git depende: curl, zlib, openssl, expat, y libiconv. Por ejemplo, si estás en un sistema que tiene yum (como Fedora) o apt-get (como un sistema basado en Debian), puedes usar estos comandos para instalar todas las dependencias:
+Para instalar Git, necesitas tener las siguientes librerías de las que Git depende: curl, zlib, openssl, expat y libiconv. Por ejemplo, si estás en un sistema que tiene yum (como Fedora) o apt-get (como un sistema basado en Debian), puedes usar estos comandos para instalar todas las dependencias:
 
 	$ yum install curl-devel expat-devel gettext-devel \
 	  openssl-devel zlib-devel

From f37d74715ec2e625f5f4f81a11fbd54c9790c7c9 Mon Sep 17 00:00:00 2001
From: Carlos Arturo Guerra Parra <carlosarturoguerra@gmail.com>
Date: Thu, 1 May 2014 17:17:01 +0200
Subject: [PATCH 391/690] [es] Update chapter 1: mistake: letter in lower case
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Pongo "Git" con mayúscula por coherencia con el resto de apariciones.
---
 es/01-introduction/01-chapter1.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/es/01-introduction/01-chapter1.markdown b/es/01-introduction/01-chapter1.markdown
index 2e96b9da2..39830df0a 100644
--- a/es/01-introduction/01-chapter1.markdown
+++ b/es/01-introduction/01-chapter1.markdown
@@ -190,7 +190,7 @@ Git trae una herramienta llamada `git config` que te permite obtener y establece
 
 *	Archivo `/etc/gitconfig`: Contiene valores para todos los usuarios del sistema y todos sus repositorios. Si pasas la opción `--system` a `git config`, lee y escribe específicamente en este archivo.
 *	Archivo `~/.gitconfig` file: Específico a tu usuario. Puedes hacer que Git lea y escriba específicamente en este archivo pasando la opción `--global`.
-*	Archivo config en el directorio de git (es decir, `.git/config`) del repositorio que estés utilizando actualmente: Específico a ese repositorio. Cada nivel sobrescribe los valores del nivel anterior, por lo que los valores de `.git/config` tienen preferencia sobre los de `/etc/gitconfig`.
+*	Archivo config en el directorio de Git (es decir, `.git/config`) del repositorio que estés utilizando actualmente: Específico a ese repositorio. Cada nivel sobrescribe los valores del nivel anterior, por lo que los valores de `.git/config` tienen preferencia sobre los de `/etc/gitconfig`.
 
 En sistemas Windows, Git busca el archivo `.gitconfig` en el directorio `$HOME` (`C:\Documents and Settings\$USER` para la mayoría de usuarios). También busca en el directorio `/etc/gitconfig`, aunque esta ruta es relativa a la raíz MSys, que es donde quiera que decidieses instalar Git en tu sistema Windows cuando ejecutaste el instalador.
 

From 683d7770ac618f7cde0ecf9940a0a798fd6384c3 Mon Sep 17 00:00:00 2001
From: Carlos Arturo Guerra Parra <carlosarturoguerra@gmail.com>
Date: Thu, 1 May 2014 20:27:51 +0200
Subject: [PATCH 392/690] [es] Update chapter 2: extra character "space"

---
 es/02-git-basics/01-chapter2.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/es/02-git-basics/01-chapter2.markdown b/es/02-git-basics/01-chapter2.markdown
index 62196fc18..2373829ac 100644
--- a/es/02-git-basics/01-chapter2.markdown
+++ b/es/02-git-basics/01-chapter2.markdown
@@ -12,7 +12,7 @@ Si estás empezando el seguimiento en Git de un proyecto existente, necesitas ir
 
 	$ git init
 
-Esto crea un nuevo subdirectorio llamado .git que contiene todos los archivos necesarios del repositorio — un esqueleto de un repositorio Git. Todavía no hay nada en tu proyecto que esté bajo seguimiento. (Véase el Capítulo 9 para obtener más información sobre qué archivos están contenidos en el directorio `.git` que acabas de crear.)
+Esto crea un nuevo subdirectorio llamado .git que contiene todos los archivos necesarios del repositorio —un esqueleto de un repositorio Git. Todavía no hay nada en tu proyecto que esté bajo seguimiento. (Véase el Capítulo 9 para obtener más información sobre qué archivos están contenidos en el directorio `.git` que acabas de crear.)
 
 Si deseas empezar a controlar versiones de archivos existentes (a diferencia de un directorio vacío), probablemente deberías comenzar el seguimiento de esos archivos y hacer una confirmación inicial. Puedes conseguirlo con unos pocos comandos `git add` para especificar qué archivos quieres controlar, seguidos de un `commit` para confirmar los cambios:
 

From 2235c9652b06afc5a73ab33e1183bce570bf9304 Mon Sep 17 00:00:00 2001
From: Carlos Arturo Guerra Parra <carlosarturoguerra@gmail.com>
Date: Thu, 1 May 2014 20:53:31 +0200
Subject: [PATCH 393/690] [es] Update chapter 2: grammatical mistake: extra
 comma

---
 es/02-git-basics/01-chapter2.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/es/02-git-basics/01-chapter2.markdown b/es/02-git-basics/01-chapter2.markdown
index 2373829ac..51386fad7 100644
--- a/es/02-git-basics/01-chapter2.markdown
+++ b/es/02-git-basics/01-chapter2.markdown
@@ -165,7 +165,7 @@ Las reglas para los patrones que pueden ser incluidos en el archivo .gitignore s
 *	Puedes indicar un directorio añadiendo una barra hacia delante (`/`) al final.
 *	Puedes negar un patrón añadiendo una exclamación (`!`) al principio.
 
-Los patrones glob son expresiones regulares simplificadas que pueden ser usadas por las shells. Un asterisco (`*`) reconoce cero o más caracteres; `[abc]` reconoce cualquier carácter de los especificados entre corchetes (en este caso, a, b, o c); una interrogación (`?`) reconoce un único carácter; y caracteres entre corchetes separados por un guión (`[0-9]`) reconoce cualquier carácter entre ellos (en este caso, de 0 a 9).
+Los patrones glob son expresiones regulares simplificadas que pueden ser usadas por las shells. Un asterisco (`*`) reconoce cero o más caracteres; `[abc]` reconoce cualquier carácter de los especificados entre corchetes (en este caso, a, b o c); una interrogación (`?`) reconoce un único carácter; y caracteres entre corchetes separados por un guión (`[0-9]`) reconoce cualquier carácter entre ellos (en este caso, de 0 a 9).
 
 He aquí otro ejemplo de archivo .gitignore:
 

From 7fefc720d1d24936d493e8256156a0e5c9a80d83 Mon Sep 17 00:00:00 2001
From: Carlos Arturo Guerra Parra <carlosarturoguerra@gmail.com>
Date: Thu, 1 May 2014 21:12:07 +0200
Subject: [PATCH 394/690] [es] Update chapter 2: missing character

---
 es/02-git-basics/01-chapter2.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/es/02-git-basics/01-chapter2.markdown b/es/02-git-basics/01-chapter2.markdown
index 51386fad7..4dbba2ad0 100644
--- a/es/02-git-basics/01-chapter2.markdown
+++ b/es/02-git-basics/01-chapter2.markdown
@@ -573,7 +573,7 @@ Las opciones `oneline` y `format` son especialmente útiles combinadas con otra
 	* d6016bc require time for xmlschema
 	*  11d191e Merge branch 'defunkt' into local
 
-Éstas son sólo algunas de las opciones para formatear la salida de `git log` —existen muchas más. La Tabla 2-2 lista las opcines vistas hasta ahora, y algunas otras opciones de formateo que pueden resultarte útiles, así como su efecto sobre la salida—.
+Éstas son sólo algunas de las opciones para formatear la salida de `git log` —existen muchas más. La Tabla 2-2 lista las opciones vistas hasta ahora, y algunas otras opciones de formateo que pueden resultarte útiles, así como su efecto sobre la salida—.
 
 	Opción	Descripción
 	-p	Muestra el parche introducido en cada confirmación.

From 8c7f17747b51fa062a68b1e6e3e59142222fe748 Mon Sep 17 00:00:00 2001
From: Carlos Arturo Guerra Parra <carlosarturoguerra@gmail.com>
Date: Thu, 1 May 2014 21:13:55 +0200
Subject: [PATCH 395/690] [es] Update chapter 2: grammatical mistake: extra
 comma

---
 es/02-git-basics/01-chapter2.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/es/02-git-basics/01-chapter2.markdown b/es/02-git-basics/01-chapter2.markdown
index 4dbba2ad0..9f4101ecb 100644
--- a/es/02-git-basics/01-chapter2.markdown
+++ b/es/02-git-basics/01-chapter2.markdown
@@ -584,7 +584,7 @@ Las opciones `oneline` y `format` son especialmente útiles combinadas con otra
 	--abbrev-commit	Muestra solamente los primeros caracteres de la suma SHA-1, en vez de los 40 caracteres de que se compone.
 	--relative-date	Muestra la fecha en formato relativo (por ejemplo, “2 weeks ago” (“hace 2 semanas”)) en lugar del formato completo.
 	--graph	Muestra un gráfico ASCII con la historia de ramificaciones y uniones.
-	--pretty	Muestra las confirmaciones usando un formato alternativo. Posibles opciones son oneline, short, full, fuller, y format (mediante el cual puedes especificar tu propio formato).
+	--pretty	Muestra las confirmaciones usando un formato alternativo. Posibles opciones son oneline, short, full, fuller y format (mediante el cual puedes especificar tu propio formato).
 
 ### Limitando la salida del histórico ###
 

From b4f65ea74d77f750f238bff3eeb8718f3c445118 Mon Sep 17 00:00:00 2001
From: Carlos Arturo Guerra Parra <carlosarturoguerra@gmail.com>
Date: Thu, 1 May 2014 21:35:03 +0200
Subject: [PATCH 396/690] [es] Update chapter 2: "em dash" in bad position
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

La oración entre paréntesis debe estar antes de la raya ('—') de cerrado para que tenga el sentido de la versión inglesa,
y puesto que le correspondería ir al final de la oración, queda suprimido.
---
 es/02-git-basics/01-chapter2.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/es/02-git-basics/01-chapter2.markdown b/es/02-git-basics/01-chapter2.markdown
index 9f4101ecb..3bf038304 100644
--- a/es/02-git-basics/01-chapter2.markdown
+++ b/es/02-git-basics/01-chapter2.markdown
@@ -690,7 +690,7 @@ El comando es un poco extraño, pero funciona. El archivo benchmarks.rb ahora es
 
 ### Deshaciendo la modificación de un archivo ###
 
-¿Qué pasa si te das cuenta de que no quieres mantener las modificaciones que has hecho sobre el archivo benchmarks.rb? ¿Cómo puedes deshacerlas fácilmente —revertir el archivo al mismo estado en el que estaba cuando hiciste tu última confirmación— (o cuando clonaste el repositorio, o como quiera que metieses el archivo en tu directorio de trabajo)? Afortunadamente, `git status` también te dice como hacer esto. En la salida del último ejemplo, la cosa estaba así:
+¿Qué pasa si te das cuenta de que no quieres mantener las modificaciones que has hecho sobre el archivo benchmarks.rb? ¿Cómo puedes deshacerlas fácilmente —revertir el archivo al mismo estado en el que estaba cuando hiciste tu última confirmación (o cuando clonaste el repositorio, o como quiera que metieses el archivo en tu directorio de trabajo)? Afortunadamente, `git status` también te dice como hacer esto. En la salida del último ejemplo, la cosa estaba así:
 
 	# Changes not staged for commit:
 	#   (use "git add <file>..." to update what will be committed)

From ffb8e4869e8b54cc7afda9bbb8557fd67c117a14 Mon Sep 17 00:00:00 2001
From: Carlos Arturo Guerra Parra <carlosarturoguerra@gmail.com>
Date: Thu, 1 May 2014 22:05:20 +0200
Subject: [PATCH 397/690] [es] Update chapter 2: extra "em dash"

---
 es/02-git-basics/01-chapter2.markdown | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/es/02-git-basics/01-chapter2.markdown b/es/02-git-basics/01-chapter2.markdown
index 3bf038304..59e5cec63 100644
--- a/es/02-git-basics/01-chapter2.markdown
+++ b/es/02-git-basics/01-chapter2.markdown
@@ -183,7 +183,7 @@ He aquí otro ejemplo de archivo .gitignore:
 
 ### Viendo tus cambios preparados y no preparados ###
 
-Si el comando `git status` es demasiado impreciso para ti —quieres saber exactamente lo que ha cambiado, no sólo qué archivos fueron modificados— puedes usar el comando `git diff`. Veremos `git diff` en más detalle después; pero probablemente lo usarás para responder estas dos preguntas: ¿qué has cambiado pero aún no has preparado?, y ¿qué has preparado y estás a punto de confirmar? Aunque `git status` responde esas preguntas de  manera general, `git diff` te muestra exactamente las líneas añadidas y eliminadas —el parche, como si dijésemos—.
+Si el comando `git status` es demasiado impreciso para ti —quieres saber exactamente lo que ha cambiado, no sólo qué archivos fueron modificados— puedes usar el comando `git diff`. Veremos `git diff` en más detalle después; pero probablemente lo usarás para responder estas dos preguntas: ¿qué has cambiado pero aún no has preparado?, y ¿qué has preparado y estás a punto de confirmar? Aunque `git status` responde esas preguntas de  manera general, `git diff` te muestra exactamente las líneas añadidas y eliminadas —el parche, como si dijésemos.
 
 Supongamos que quieres editar y preparar el archivo README otra vez, y luego editar el archivo benchmarks.rb sin prepararlo. Si ejecutas el comando `status`, de nuevo verás algo así:
 
@@ -388,7 +388,7 @@ Este comando elimina todos los archivos que terminan en `~`.
 
 ### Moviendo archivos ###
 
-A diferencia de muchos otros VCSs, Git no hace un seguimiento explicito del movimiento de archivos. Si renombras un archivo, en Git no se almacena ningún metadato que indique que lo has renombrado. Sin embargo, Git es suficientemente inteligente como para darse cuenta —trataremos el tema de la detección de movimiento de archivos un poco más adelante—.
+A diferencia de muchos otros VCSs, Git no hace un seguimiento explicito del movimiento de archivos. Si renombras un archivo, en Git no se almacena ningún metadato que indique que lo has renombrado. Sin embargo, Git es suficientemente inteligente como para darse cuenta —trataremos el tema de la detección de movimiento de archivos un poco más adelante.
 
 Por tanto, es un poco desconcertante que Git tenga un comando `mv`. Si quieres renombrar un archivo en Git, puedes ejecutar algo así:
 
@@ -573,7 +573,7 @@ Las opciones `oneline` y `format` son especialmente útiles combinadas con otra
 	* d6016bc require time for xmlschema
 	*  11d191e Merge branch 'defunkt' into local
 
-Éstas son sólo algunas de las opciones para formatear la salida de `git log` —existen muchas más. La Tabla 2-2 lista las opciones vistas hasta ahora, y algunas otras opciones de formateo que pueden resultarte útiles, así como su efecto sobre la salida—.
+Éstas son sólo algunas de las opciones para formatear la salida de `git log` —existen muchas más. La Tabla 2-2 lista las opciones vistas hasta ahora, y algunas otras opciones de formateo que pueden resultarte útiles, así como su efecto sobre la salida.
 
 	Opción	Descripción
 	-p	Muestra el parche introducido en cada confirmación.
@@ -652,7 +652,7 @@ Por ejemplo, si confirmas y luego te das cuenta de que se te olvidó preparar lo
 	$ git add forgotten_file
 	$ git commit --amend
 
-Estos tres comandos acabarán convirtiéndose en una única confirmación —la segunda confirmación reemplazará los resultados de la primera—.
+Estos tres comandos acabarán convirtiéndose en una única confirmación —la segunda confirmación reemplazará los resultados de la primera.
 
 ### Deshaciendo la preparación de un archivo ###
 
@@ -699,7 +699,7 @@ El comando es un poco extraño, pero funciona. El archivo benchmarks.rb ahora es
 	#       modified:   benchmarks.rb
 	#
 
-Te dice de forma bastante explícita cómo descartar las modificaciones que hayas hecho (al menos las versiones de Git a partir de la 1.6.1 lo hacen —si tienes una versión más antigua, te recomendamos encarecidamente que la actualices para obtener algunas de estas mejoras de usabilidad—). Vamos a hacer lo que dice:
+Te dice de forma bastante explícita cómo descartar las modificaciones que hayas hecho (al menos las versiones de Git a partir de la 1.6.1 lo hacen —si tienes una versión más antigua, te recomendamos encarecidamente que la actualices para obtener algunas de estas mejoras de usabilidad). Vamos a hacer lo que dice:
 
 	$ git checkout -- benchmarks.rb
 	$ git status
@@ -774,7 +774,7 @@ Ahora puedes usar la cadena "pb" en la línea de comandos, en lugar de toda la U
 	 * [new branch]      master     -> pb/master
 	 * [new branch]      ticgit     -> pb/ticgit
 
-La rama maestra de Paul es accesible localmente como `pb/master` —puedes unirla a una de tus ramas, o copiarla localmente para inspeccionarla—.
+La rama maestra de Paul es accesible localmente como `pb/master` —puedes unirla a una de tus ramas, o copiarla localmente para inspeccionarla.
 
 ### Recibiendo de tus repositorios remotos ###
 
@@ -784,7 +784,7 @@ Como acabas de ver, para recuperar datos de tus repositorios remotos puedes ejec
 
 Este comando recupera todos los datos del proyecto remoto que no tengas todavía. Después de hacer esto, deberías tener referencias a todas las ramas del repositorio remoto, que puedes unir o inspeccionar en cualquier momento. (Veremos qué son las ramas y cómo utilizarlas en más detalle en el Capítulo 3.)
 
-Si clonas un repositorio, el comando añade automáticamente ese repositorio remoto con el nombre de "origin". Por tanto, `git fetch origin` recupera toda la información enviada a ese servidor desde que lo clonaste (o desde la última vez que ejecutaste `fetch`). Es importante tener en cuenta que el comando `fetch` sólo recupera la información y la pone en tu repositorio local —no la une automáticamente con tu trabajo ni modifica aquello en lo que estás trabajando. Tendrás que unir ambos manualmente a posteriori—.
+Si clonas un repositorio, el comando añade automáticamente ese repositorio remoto con el nombre de "origin". Por tanto, `git fetch origin` recupera toda la información enviada a ese servidor desde que lo clonaste (o desde la última vez que ejecutaste `fetch`). Es importante tener en cuenta que el comando `fetch` sólo recupera la información y la pone en tu repositorio local —no la une automáticamente con tu trabajo ni modifica aquello en lo que estás trabajando. Tendrás que unir ambos manualmente a posteriori.
 
 Si has configurado una rama para seguir otra rama remota (véase la siguiente sección y el Capítulo 3 para más información), puedes usar el comando `git pull` para recuperar y unir automáticamente la rama remota con tu rama actual. Éste puede resultarte un flujo de trabajo más sencillo y más cómodo; y por defecto, el comando `git clone` automáticamente configura tu rama local maestra para que siga la rama remota maestra del servidor del cual clonaste (asumiendo que el repositorio remoto tiene una rama maestra). Al ejecutar `git pull`, por lo general se recupera la información del servidor del que clonaste, y automáticamente se intenta unir con el código con el que estás trabajando actualmente.
 
@@ -1033,7 +1033,7 @@ Puedes ver que has etiquetado la confirmación:
 
 ### Compartiendo etiquetas ###
 
-Por defecto, el comando `git push` no transfiere etiquetas a servidores remotos. Tienes que enviarlas explicitamente a un servidor compartido después de haberlas creado. Este proceso es igual a compartir ramas remotas —puedes ejecutar `git push origin [tagname]`—.
+Por defecto, el comando `git push` no transfiere etiquetas a servidores remotos. Tienes que enviarlas explicitamente a un servidor compartido después de haberlas creado. Este proceso es igual a compartir ramas remotas —puedes ejecutar `git push origin [tagname]`.
 
 	$ git push origin v1.5
 	Counting objects: 50, done.

From 72f1e73eef449665e760c59227a6bef3cbd4713e Mon Sep 17 00:00:00 2001
From: Carlos Arturo Guerra Parra <carlosarturoguerra@gmail.com>
Date: Thu, 1 May 2014 22:28:01 +0200
Subject: [PATCH 398/690] [es] Update chapter 2: final point (instead of em
 dash)

---
 es/02-git-basics/01-chapter2.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/es/02-git-basics/01-chapter2.markdown b/es/02-git-basics/01-chapter2.markdown
index 59e5cec63..0df681142 100644
--- a/es/02-git-basics/01-chapter2.markdown
+++ b/es/02-git-basics/01-chapter2.markdown
@@ -856,7 +856,7 @@ Si por algún motivo quieres eliminar una referencia —has movido el servidor o
 
 ## Creando etiquetas ##
 
-Como muchos VCSs, Git tiene la habilidad de etiquetar (tag) puntos específicos en la historia como importantes. Generalmente la gente usa esta funcionalidad para marcar puntos donde se ha lanzado alguna versión (v1.0, y así sucesivamente). En esta sección aprenderás cómo listar las etiquetas disponibles, crear nuevas etiquetas y qué tipos diferentes de etiquetas hay-
+Como muchos VCSs, Git tiene la habilidad de etiquetar (tag) puntos específicos en la historia como importantes. Generalmente la gente usa esta funcionalidad para marcar puntos donde se ha lanzado alguna versión (v1.0, y así sucesivamente). En esta sección aprenderás cómo listar las etiquetas disponibles, crear nuevas etiquetas y qué tipos diferentes de etiquetas hay.
 
 ### Listando tus etiquetas ###
 

From 211069e64e4c980344424627104e51c5bc058a02 Mon Sep 17 00:00:00 2001
From: Carlos Arturo Guerra Parra <carlosarturoguerra@gmail.com>
Date: Thu, 1 May 2014 22:58:19 +0200
Subject: [PATCH 399/690] [es] Update chapter 2: missing accent

---
 es/02-git-basics/01-chapter2.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/es/02-git-basics/01-chapter2.markdown b/es/02-git-basics/01-chapter2.markdown
index 0df681142..54c61a5fc 100644
--- a/es/02-git-basics/01-chapter2.markdown
+++ b/es/02-git-basics/01-chapter2.markdown
@@ -868,7 +868,7 @@ Listar las etiquetas disponibles en Git es sencillo, Simplemente escribe `git ta
 
 Este comando lista las etiquetas en orden alfabético; el orden en el que aparecen no es realmente importante.
 
-También puedes buscar etiquetas de acuerdo a un patrón en particular. El repositorio fuente de Git, por ejemplo, contiene mas de 240 etiquetas. Si solo estas interesado en la serie 1.4.2, puedes ejecutar esto:
+También puedes buscar etiquetas de acuerdo a un patrón en particular. El repositorio fuente de Git, por ejemplo, contiene mas de 240 etiquetas. Si solo estás interesado en la serie 1.4.2, puedes ejecutar esto:
 
 	$ git tag -l 'v1.4.2.*'
 	v1.4.2.1

From 46f025e8fa44d58dd959496c19e8cfad6a7de9f2 Mon Sep 17 00:00:00 2001
From: Carlos Arturo Guerra Parra <carlosarturoguerra@gmail.com>
Date: Thu, 1 May 2014 23:04:21 +0200
Subject: [PATCH 400/690] [es] Update chapter 2: gender mistake

---
 es/02-git-basics/01-chapter2.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/es/02-git-basics/01-chapter2.markdown b/es/02-git-basics/01-chapter2.markdown
index 54c61a5fc..6a0eba8b4 100644
--- a/es/02-git-basics/01-chapter2.markdown
+++ b/es/02-git-basics/01-chapter2.markdown
@@ -990,7 +990,7 @@ Si no tienes la clave pública del autor de la firma, se obtiene algo parecido a
 
 ### Etiquetando más tarde ###
 
-Puedes incluso etiquetar confirmaciones después de avanzar sobre ellos. Supón que tu historico de confirmaciones se parece a esto:
+Puedes incluso etiquetar confirmaciones después de avanzar sobre ellas. Supón que tu historico de confirmaciones se parece a esto:
 
 	$ git log --pretty=oneline
 	15027957951b64cf874c3557a0f3547bd83b3ff6 Merge branch 'experiment'

From 8155dfdf705f42d7d40dcf7b7ef26d22b39e4cc0 Mon Sep 17 00:00:00 2001
From: Carlos Arturo Guerra Parra <carlosarturoguerra@gmail.com>
Date: Thu, 1 May 2014 23:08:04 +0200
Subject: [PATCH 401/690] [es] Update chapter 2: word mistake

---
 es/02-git-basics/01-chapter2.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/es/02-git-basics/01-chapter2.markdown b/es/02-git-basics/01-chapter2.markdown
index 6a0eba8b4..5ada6deaa 100644
--- a/es/02-git-basics/01-chapter2.markdown
+++ b/es/02-git-basics/01-chapter2.markdown
@@ -1043,7 +1043,7 @@ Por defecto, el comando `git push` no transfiere etiquetas a servidores remotos.
 	To git@github.com:schacon/simplegit.git
 	* [new tag]         v1.5 -> v1.5
 
-Si tienes un montón de etiquetas que quieres enviar a la vez, también puedes usar la opción `--tags` en el comando `git push`. Esto transifere todas tus etiquetas que no estén ya en el servidor remoto.
+Si tienes un montón de etiquetas que quieres enviar a la vez, también puedes usar la opción `--tags` en el comando `git push`. Esto transfiere todas tus etiquetas que no estén ya en el servidor remoto.
 
 	$ git push origin --tags
 	Counting objects: 50, done.

From bfca2d81ad08a09ceb97fcf7bbb031ee95e29896 Mon Sep 17 00:00:00 2001
From: Carlos Arturo Guerra Parra <carlosarturoguerra@gmail.com>
Date: Thu, 1 May 2014 23:12:42 +0200
Subject: [PATCH 402/690] [es] Update chapter 2: missing accent

---
 es/02-git-basics/01-chapter2.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/es/02-git-basics/01-chapter2.markdown b/es/02-git-basics/01-chapter2.markdown
index 5ada6deaa..dab55528d 100644
--- a/es/02-git-basics/01-chapter2.markdown
+++ b/es/02-git-basics/01-chapter2.markdown
@@ -1061,7 +1061,7 @@ Ahora, cuando alguien clone o reciba de tu repositorio, obtendrá también todas
 
 ## Consejos y trucos ##
 
-Antes de que terminemos este capitulo de Git básico, unos pocos trucos y consejos que harán de tu experiencia con Git más sencilla, fácil, o más familiar. Mucha gente usa Git sin usar ninguno de estos consejos, y no nos referiremos a ellos o asumiremos que los has usado más tarde en el libro, pero probablemente debas saber como hacerlos.
+Antes de que terminemos este capitulo de Git básico, unos pocos trucos y consejos que harán de tu experiencia con Git más sencilla, fácil, o más familiar. Mucha gente usa Git sin usar ninguno de estos consejos, y no nos referiremos a ellos o asumiremos que los has usado más tarde en el libro, pero probablemente debas saber cómo hacerlos.
 
 ### Autocompletado ###
 

From a76f341579f4aefa8bd6d4a33c8077bd8d0d778c Mon Sep 17 00:00:00 2001
From: Carlos Arturo Guerra Parra <carlosarturoguerra@gmail.com>
Date: Thu, 1 May 2014 23:13:57 +0200
Subject: [PATCH 403/690] [es] Update chapter 2: missing accent

---
 es/02-git-basics/01-chapter2.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/es/02-git-basics/01-chapter2.markdown b/es/02-git-basics/01-chapter2.markdown
index dab55528d..441fee9eb 100644
--- a/es/02-git-basics/01-chapter2.markdown
+++ b/es/02-git-basics/01-chapter2.markdown
@@ -1071,7 +1071,7 @@ Si usas el shell Bash, Git viene con un buen script de autocompletado que puedes
 
 Si quieres que Git tenga automáticamente autocompletado para todos los usuarios, copia este script en el  directorio `/opt/local/etc/bash_completion.d` en sistemas Mac, o en el directorio `/etc/bash_completion.d/` en sistemas Linux. Este es un directorio de scripts que Bash cargará automáticamente para proveer de autocompletado.
 
-Si estas usando Windows con el Bash de Git, el cual es el predeterminado cuando instalas Git en Windows con msysGit, el autocompletado debería estar preconfigurado.
+Si estás usando Windows con el Bash de Git, el cual es el predeterminado cuando instalas Git en Windows con msysGit, el autocompletado debería estar preconfigurado.
 
 Presiona el tabulador cuando estés escribiendo un comando de Git, y deberían aparecer un conjunto de sugerencias para que escojas:
 

From fd4eccb4c4dcaab895371e7330c19740f99d8316 Mon Sep 17 00:00:00 2001
From: Carlos Arturo Guerra Parra <carlosarturoguerra@gmail.com>
Date: Thu, 1 May 2014 23:22:54 +0200
Subject: [PATCH 404/690] [es] Update chapter 2: extra space between words

---
 es/02-git-basics/01-chapter2.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/es/02-git-basics/01-chapter2.markdown b/es/02-git-basics/01-chapter2.markdown
index 441fee9eb..0ef0ec975 100644
--- a/es/02-git-basics/01-chapter2.markdown
+++ b/es/02-git-basics/01-chapter2.markdown
@@ -1069,7 +1069,7 @@ Si usas el shell Bash, Git viene con un buen script de autocompletado que puedes
 
 	source ~/.git-completion.bash
 
-Si quieres que Git tenga automáticamente autocompletado para todos los usuarios, copia este script en el  directorio `/opt/local/etc/bash_completion.d` en sistemas Mac, o en el directorio `/etc/bash_completion.d/` en sistemas Linux. Este es un directorio de scripts que Bash cargará automáticamente para proveer de autocompletado.
+Si quieres que Git tenga automáticamente autocompletado para todos los usuarios, copia este script en el directorio `/opt/local/etc/bash_completion.d` en sistemas Mac, o en el directorio `/etc/bash_completion.d/` en sistemas Linux. Este es un directorio de scripts que Bash cargará automáticamente para proveer de autocompletado.
 
 Si estás usando Windows con el Bash de Git, el cual es el predeterminado cuando instalas Git en Windows con msysGit, el autocompletado debería estar preconfigurado.
 

From df9325af648ab6cc8aaf4cfbec52325a0eff0aa2 Mon Sep 17 00:00:00 2001
From: Carlos Arturo Guerra Parra <carlosarturoguerra@gmail.com>
Date: Thu, 1 May 2014 23:26:17 +0200
Subject: [PATCH 405/690] [es] Update chapter 2: word not translated

---
 es/02-git-basics/01-chapter2.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/es/02-git-basics/01-chapter2.markdown b/es/02-git-basics/01-chapter2.markdown
index 0ef0ec975..3d992356e 100644
--- a/es/02-git-basics/01-chapter2.markdown
+++ b/es/02-git-basics/01-chapter2.markdown
@@ -1080,7 +1080,7 @@ Presiona el tabulador cuando estés escribiendo un comando de Git, y deberían a
 
 En este caso, escribiendo `git co` y presionando el tabulador dos veces sugiere `commit` y `config`. Añadiendo `m` y pulsando el tabulador completa `git commit` automáticamente.
 
-Esto también funciona con optiones, que probablemente es más útil. Por ejemplo, si quieres ejecutar `git log` y no recuerdas una de las opciones, puedes empezar a escribirla y presionar el tabulador para ver que coincide:
+Esto también funciona con opciones, que probablemente es más útil. Por ejemplo, si quieres ejecutar `git log` y no recuerdas una de las opciones, puedes empezar a escribirla y presionar el tabulador para ver que coincide:
 
 	$ git log --s<tab>
 	--shortstat  --since=  --src-prefix=  --stat   --summary

From d44084474981076df0306cd01cc9d99b35f64f2a Mon Sep 17 00:00:00 2001
From: Carlos Arturo Guerra Parra <carlosarturoguerra@gmail.com>
Date: Thu, 1 May 2014 23:26:54 +0200
Subject: [PATCH 406/690] [es] Update chapter 2: missing accent

---
 es/02-git-basics/01-chapter2.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/es/02-git-basics/01-chapter2.markdown b/es/02-git-basics/01-chapter2.markdown
index 3d992356e..9724fa7e0 100644
--- a/es/02-git-basics/01-chapter2.markdown
+++ b/es/02-git-basics/01-chapter2.markdown
@@ -1080,7 +1080,7 @@ Presiona el tabulador cuando estés escribiendo un comando de Git, y deberían a
 
 En este caso, escribiendo `git co` y presionando el tabulador dos veces sugiere `commit` y `config`. Añadiendo `m` y pulsando el tabulador completa `git commit` automáticamente.
 
-Esto también funciona con opciones, que probablemente es más útil. Por ejemplo, si quieres ejecutar `git log` y no recuerdas una de las opciones, puedes empezar a escribirla y presionar el tabulador para ver que coincide:
+Esto también funciona con opciones, que probablemente es más útil. Por ejemplo, si quieres ejecutar `git log` y no recuerdas una de las opciones, puedes empezar a escribirla y presionar el tabulador para ver qué coincide:
 
 	$ git log --s<tab>
 	--shortstat  --since=  --src-prefix=  --stat   --summary

From f9b392417b6940c6ef97f6bc1caa8bf9fbb0fae2 Mon Sep 17 00:00:00 2001
From: Carlos Arturo Guerra Parra <carlosarturoguerra@gmail.com>
Date: Thu, 1 May 2014 23:29:07 +0200
Subject: [PATCH 407/690] [es] Update chapter 2: extra character

---
 es/02-git-basics/01-chapter2.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/es/02-git-basics/01-chapter2.markdown b/es/02-git-basics/01-chapter2.markdown
index 9724fa7e0..5d981cf99 100644
--- a/es/02-git-basics/01-chapter2.markdown
+++ b/es/02-git-basics/01-chapter2.markdown
@@ -1128,4 +1128,4 @@ Como puedes ver, Git simplemente reemplaza el nuevo comando con lo que le pongas
 
 ## Resumen ##
 
-En este punto puedes hacer todas las operaciones básicas de Git a nivel local —crear o clonar un repositorio, hacer cambios, preparar y confirmar esos cambios y ver la historioa de los cambios en el repositorio—. A continuación cubriremos la mejor característica de Git: su modelo de ramas.
+En este punto puedes hacer todas las operaciones básicas de Git a nivel local —crear o clonar un repositorio, hacer cambios, preparar y confirmar esos cambios y ver la historia de los cambios en el repositorio—. A continuación cubriremos la mejor característica de Git: su modelo de ramas.

From 1cf071f1e71c432de52c6c15479af72100f98182 Mon Sep 17 00:00:00 2001
From: Carlos Arturo Guerra Parra <carlosarturoguerra@gmail.com>
Date: Fri, 2 May 2014 02:31:19 +0200
Subject: [PATCH 408/690] [es] Update chapter 1: translation of a new paragraph

Translation of a paragraph added in bc3f922f about Windows Git usage
---
 es/01-introduction/01-chapter1.markdown | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/es/01-introduction/01-chapter1.markdown b/es/01-introduction/01-chapter1.markdown
index 39830df0a..cfddccc5b 100644
--- a/es/01-introduction/01-chapter1.markdown
+++ b/es/01-introduction/01-chapter1.markdown
@@ -182,6 +182,8 @@ Instalar Git en Windows es muy fácil. El proyecto msysGit tiene uno de los proc
 
 Una vez instalado, tendrás tanto la versión de línea de comandos (incluido un cliente SSH que nos será útil más adelante) como la interfaz gráfica de usuario estándar.
 
+Nota para el uso en Windows: Se debería usar Git con la shell provista por msysGit (estilo Unix), lo cual permite usar las complejas líneas de comandos de este libro. Si por cualquier razón se necesitara usar la shell nativa de Windows, la consola de línea de comandos, se han de usar las comillas dobles en vez de las simples (para parámetros que contengan espacios) y se deben entrecomillar los parámetros terminándolos con el acento circunflejo (^) si están al final de la línea, ya que en Windows es uno de los símbolos de continuación.
+
 ## Configurando Git por primera vez ##
 
 Ahora que tienes Git en tu sistema, querrás hacer algunas cosas para personalizar tu entorno de Git. Sólo es necesario hacer estas cosas una vez; se mantendrán entre actualizaciones. También puedes cambiarlas en cualquier momento volviendo a ejecutar los comandos correspondientes.

From cc734916180e16bf53519e08a28a0a5aeb28eb63 Mon Sep 17 00:00:00 2001
From: Carlos Arturo Guerra Parra <carlosarturoguerra@gmail.com>
Date: Fri, 2 May 2014 03:02:20 +0200
Subject: [PATCH 409/690] [es] Update chapter 1: line change from english
 version

From bfead6c2 "added another ubuntu dep"
---
 es/01-introduction/01-chapter1.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/es/01-introduction/01-chapter1.markdown b/es/01-introduction/01-chapter1.markdown
index cfddccc5b..c5be3376e 100644
--- a/es/01-introduction/01-chapter1.markdown
+++ b/es/01-introduction/01-chapter1.markdown
@@ -132,7 +132,7 @@ Para instalar Git, necesitas tener las siguientes librerías de las que Git depe
 	  openssl-devel zlib-devel
 
 	$ apt-get install libcurl4-gnutls-dev libexpat1-dev gettext \
-	  libz-dev
+	  libz-dev libssl-dev
 
 Cuando tengas todas las dependencias necesarias, puedes descargar la versión más reciente de Git desde su página web:
 

From 8ffdb47f1580407348822193eef7540690cb9c1d Mon Sep 17 00:00:00 2001
From: Carlos Arturo Guerra Parra <carlosarturoguerra@gmail.com>
Date: Fri, 2 May 2014 03:32:18 +0200
Subject: [PATCH 410/690] [es] Update chapter 1: change from english version

From 33e9d89 "Reference whole chapter instead of a single section. "
---
 es/01-introduction/01-chapter1.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/es/01-introduction/01-chapter1.markdown b/es/01-introduction/01-chapter1.markdown
index c5be3376e..c99ee0258 100644
--- a/es/01-introduction/01-chapter1.markdown
+++ b/es/01-introduction/01-chapter1.markdown
@@ -93,7 +93,7 @@ Verás estos valores hash por todos lados en Git, ya que los usa con mucha frecu
 
 Cuando realizas acciones en Git, casi todas ellas sólo añaden información a la base de datos de Git. Es muy difícil conseguir que el sistema haga algo que no se pueda deshacer, o que de algún modo borre información. Como en cualquier VCS, puedes perder o estropear cambios que no has confirmado todavía; pero después de confirmar una instantánea en Git, es muy difícil de perder, especialmente si envías (push) tu base de datos a otro repositorio con regularidad.
 
-Esto hace que usar Git sea un placer, porque sabemos que podemos experimentar sin peligro de fastidiar gravemente las cosas. Para un análisis más exhaustivo de cómo almacena Git su información y cómo puedes recuperar datos aparentemente perdidos, ver “Entre bambalinas” en el Capítulo 9.
+Esto hace que usar Git sea un placer, porque sabemos que podemos experimentar sin peligro de fastidiar gravemente las cosas. Para un análisis más exhaustivo de cómo almacena Git su información y cómo puedes recuperar datos aparentemente perdidos, ver Capítulo 9.
 
 ### Los tres estados ###
 

From 7980d7dd46a97c9c3aff1f015c932941dcf10454 Mon Sep 17 00:00:00 2001
From: Carlos Arturo Guerra Parra <carlosarturoguerra@gmail.com>
Date: Fri, 2 May 2014 03:41:15 +0200
Subject: [PATCH 411/690] [es] Update chapter 1: added paragraph from english
 version

From 0cec524 "1.1 (en): Clarify the wording in the first paragraphs to be less awkward "
---
 es/01-introduction/01-chapter1.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/es/01-introduction/01-chapter1.markdown b/es/01-introduction/01-chapter1.markdown
index c99ee0258..593d5a6d3 100644
--- a/es/01-introduction/01-chapter1.markdown
+++ b/es/01-introduction/01-chapter1.markdown
@@ -4,7 +4,7 @@ Este capítulo tratará sobre cómo empezar con Git. Partiremos explicando algun
 
 ## Acerca del control de versiones ##
 
-¿Qué es el control de versiones, y por qué debería importarte? El control de versiones es un sistema que registra los cambios realizados sobre un archivo o conjunto de archivos a lo largo del tiempo, de modo que puedas recuperar versiones específicas más adelante. Para los ejemplos de este libro llevarás control de versiones de código fuente, aunque en realidad puedes hacer esto con casi cualquier tipo de archivo que encuentres en un ordenador.
+¿Qué es el control de versiones, y por qué debería importarte? El control de versiones es un sistema que registra los cambios realizados sobre un archivo o conjunto de archivos a lo largo del tiempo, de modo que puedas recuperar versiones específicas más adelante. A pesar de que los ejemplos de este libro muestran código fuente como archivos bajo control de versiones, en realidad cualquier tipo de archivo que encuentres en un ordenador puede ponerse bajo control de versiones.
 
 Si eres diseñador gráfico o web, y quieres mantener cada versión de una imagen o diseño (algo que sin duda quieres), un sistema de control de versiones (Version Control System o VCS en inglés) es una elección muy sabia. Te permite revertir archivos a un estado anterior, revertir el proyecto entero a un estado anterior, comparar cambios a lo largo del tiempo, ver quién modificó por última vez algo que puede estar causando un problema, quién introdujo un error y cuándo, y mucho más. Usar un VCS también significa generalmente que si fastidias o pierdes archivos, puedes recuperarlos fácilmente. Además, obtienes todos estos beneficios a un coste muy bajo.
 

From bb0158b04cfb6fd7fa6b1dda5318f20ce9874c7b Mon Sep 17 00:00:00 2001
From: Carlos Arturo Guerra Parra <carlosarturoguerra@gmail.com>
Date: Fri, 2 May 2014 03:51:11 +0200
Subject: [PATCH 412/690] [es] Update chapter 1: change from english version

From b294744 "Minor updates (Windows & typo) "
---
 es/01-introduction/01-chapter1.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/es/01-introduction/01-chapter1.markdown b/es/01-introduction/01-chapter1.markdown
index 593d5a6d3..64bc3bbdf 100644
--- a/es/01-introduction/01-chapter1.markdown
+++ b/es/01-introduction/01-chapter1.markdown
@@ -194,7 +194,7 @@ Git trae una herramienta llamada `git config` que te permite obtener y establece
 *	Archivo `~/.gitconfig` file: Específico a tu usuario. Puedes hacer que Git lea y escriba específicamente en este archivo pasando la opción `--global`.
 *	Archivo config en el directorio de Git (es decir, `.git/config`) del repositorio que estés utilizando actualmente: Específico a ese repositorio. Cada nivel sobrescribe los valores del nivel anterior, por lo que los valores de `.git/config` tienen preferencia sobre los de `/etc/gitconfig`.
 
-En sistemas Windows, Git busca el archivo `.gitconfig` en el directorio `$HOME` (`C:\Documents and Settings\$USER` para la mayoría de usuarios). También busca en el directorio `/etc/gitconfig`, aunque esta ruta es relativa a la raíz MSys, que es donde quiera que decidieses instalar Git en tu sistema Windows cuando ejecutaste el instalador.
+En sistemas Windows, Git busca el archivo `.gitconfig` en el directorio `$HOME` (`%USERPROFILE%` in Windows’ environment), que es `C:\Documents and Settings\$USER` para la mayoría de usuarios, pedendiendo de la versión (`$USER` es `%USERNAME%` en el entorno Windows). También busca en el directorio `/etc/gitconfig`, aunque esta ruta es relativa a la raíz MSys, que es donde quiera que decidieses instalar Git en tu sistema Windows cuando ejecutaste el instalador.
 
 ### Tu identidad ###
 

From db581019330e1988f9aedc5dea8bd2bf13a314a6 Mon Sep 17 00:00:00 2001
From: nicesw123 <nicesw123@users.noreply.github.com>
Date: Sun, 4 May 2014 00:36:54 +0200
Subject: [PATCH 413/690] how to robustly use `git log` and limit the commits
 by date/time

* show that CommitDate is considered, when using `--after` and `--before`
* show that `--after` means on-or-after and `--before` means on-or-before
* best practices: show how to limit by absolute time (ISO format),
  so that the log command's results are identical for everyone around the
  world
* format dates returned by git log according to your timezone of choice,
  using TZ (tested on GNU/Linux and Windows) and `--date=local`
* explain how `--after=2008-06-01` default to using time when command is
  run; and how offsets from UTC are (in this case) not corrected for
  DST changes.
---
 en/02-git-basics/01-chapter2.markdown | 116 ++++++++++++++++++++++----
 1 file changed, 99 insertions(+), 17 deletions(-)

diff --git a/en/02-git-basics/01-chapter2.markdown b/en/02-git-basics/01-chapter2.markdown
index 2d8793891..6ec2e3cf4 100644
--- a/en/02-git-basics/01-chapter2.markdown
+++ b/en/02-git-basics/01-chapter2.markdown
@@ -652,18 +652,108 @@ The lines must be formatted as follows
 
 	Option	Description
 	-(n)	Show only the last n commits
-	--since, --after	Limit the commits to those made after the specified date.
-	--until, --before	Limit the commits to those made before the specified date.
+	--since, --after	Limit the commits to those whose CommitDate was made on-or-after the specified date/time.
+	--until, --before	Limit the commits to those whose CommitDate was made on-or-before the specified date/time.
 	--author	Only show commits in which the author entry matches the specified string.
 	--committer	Only show commits in which the committer entry matches the specified string.
 
-For example, if you want to see which commits modifying test files in the Git source code history were committed by Junio Hamano in the month of October 2008 and were not merges, you can run something like this:
 
-	$ # get dates on-or-after  "2008-10-01 00:00:00"
-	$ # and       on-or-before "2008-11-01 00:00:00"
-	$
-	$ git log --pretty="%h - %s" --author=gitster --after="2008-10-01 00:00:00" \
-	   --before="2008-11-01 00:00:00" --no-merges -- t/
+### Limiting Log Output according to Date/Time ###
+
+To determine which commits in the Git source code repository (git://git.kernel.org/pub/scm/git/git.git) have CommitDate on 2014-04-29 relative to your local timezone, use
+
+    $ git log --after="2014-04-29 00:00:00" --before="2014-04-29 23:59:59" \
+      --pretty=fuller
+
+However this command will not yield identical results, when run by collegues, who may be situated in other timezones around the world. Therefore it is recommended to always use an absolute time such as ISO 8601 format (which includes timezone information) as argument to `--after` and `--before`, so that everone running the command will get the same repeatable results. If your timezone is that of France (e.g. you are in Paris) you can change the above example, to use absolute-time arguments, so that all your collegues around the world would get the same results as you. First determine the absolute-times using e.g. the `date` program:
+
+    $ TZ="CET-1CEST,M3.5.0,M10.5.0/3" date --date="2014-04-29 00:00:00" -Is
+    2014-04-29T00:00:00+0200
+    
+    $ TZ="CET-1CEST,M3.5.0,M10.5.0/3" date --date="2014-04-29 23:59:59" -Is
+    2014-04-29T23:59:59+0200
+
+    $ # for TZ values of various countries/cities
+    $ # see http://wiki.openwrt.org/doc/uci/system#time.zones 
+
+    $ # Alternative (simplification) under GNU/Linux -- see /usr/share/zoneinfo/
+    $ TZ="Europe/Paris" date --date="2014-04-29 00:00:00" -Is
+    2014-04-29T00:00:00+0200
+    
+    $ TZ="Europe/Paris" date --date="2014-04-29 23:59:59" -Is
+    2014-04-29T23:59:59+0200
+
+Using the resulting absolute-times, we can now modify the above example and construct a git log command, that gives repeatable ("Paris"-based) results for everyone, irrespective of location:
+
+    $ git log --after="2014-04-29T00:00:00+0200" \
+    --before="2014-04-29T23:59:59+0200" --pretty=fuller
+
+`+0200` means that here Paris is 2 hours ahead of UTC: 
+
+For example: for `2014-04-29T23:59:59+0200` the corresponding 
+
+UTC is `2014-04-29 21:59:59`.
+
+
+To obtain commits made at a specific instant in time, we can use e.g.
+
+    $ git log  --after="2013-04-29T17:07:22+0200"      \
+              --before="2013-04-29T17:07:22+0200" --pretty=fuller
+    
+    commit de7c201a10857e5d424dbd8db880a6f24ba250f9
+    Author:     Ramkumar Ramachandra <artagnon@gmail.com>
+    AuthorDate: Mon Apr 29 18:19:37 2013 +0530
+    Commit:     Junio C Hamano <gitster@pobox.com>
+    CommitDate: Mon Apr 29 08:07:22 2013 -0700
+    
+        git-completion.bash: lexical sorting for diff.statGraphWidth
+        
+        df44483a (diff --stat: add config option to limit graph width,
+        2012-03-01) added the option diff.startGraphWidth to the list of
+        configuration variables in git-completion.bash, but failed to notice
+        that the list is sorted alphabetically.  Move it to its rightful place
+        in the list.
+        
+        Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
+        Signed-off-by: Junio C Hamano <gitster@pobox.com>
+
+The above times (`AuthorDate`, `CommitDate`) are displayed in default format (`--date=default`), which shows timezone information of respective author and commiter.
+
+We can change the way that these are displayed in the resulting log list. `--date=local` displays times according to your local timezone:
+
+    $ git log  --after="2013-04-29T17:07:22+0200" \
+              --before="2013-04-29T17:07:22+0200" --pretty=fuller --date=local
+
+To show all times according to e.g. French timezone, we can prefix an appropriate `TZ=..."` value to the above command (under GNU/Linux simply `TZ="Europe/Paris"`):
+
+    $ TZ="CET-1CEST,M3.5.0,M10.5.0/3"             \
+      git log  --after="2013-04-29T17:07:22+0200" \
+              --before="2013-04-29T17:07:22+0200" --pretty=fuller --date=local
+
+Other useful formats include `--date=iso` (ISO 8601), `--date=rfc` (RFC 2822), `--date=raw` (seconds since the epoch (1970-01-01 UTC)) as well as `--date=relative` (e.g. "2 hours ago").
+
+When using `git log` without specifying time,
+
+    $ git log --after=2008-06-01 --before=2008-07-01
+
+the time defaults to the time at which the command is run. For example when the above command is executed at 09:00, then the result is usually equivalent to doing:
+
+    $ git log --after="2008-06-01 09:00:00" \
+      --before="2008-07-01 09:00:00"
+
+More precisely: Actually in this case Git considers the time-offset from UTC to stay the same for the whole year. Offset-changes from UTC will not be considered. The time that will be considered, is the same time as when the command is run, including the identical timezone offset from UTC. Therefore when the above (date-only) command is run in December in Paris at local time `2009-12-14T09:00:00+0100`, then the result is equivalent to doing:
+
+    $ git log --after="2008-06-01T09:00:00+0100" \
+      --before="2008-07-01T09:00:00+0100"
+
+even though `2008-06-01T09:00:00+0100` would actually be 10:00 in June in Paris:
+
+ `2008-06-01T10:00:00+0200`.
+
+As a final example:, if you want to see which commits modifying test files in the Git source code history were committed by Junio Hamano and committed with CommitDate being in the month of October 2008 (relative to the timezone of New York) and were not merges, you can run something like this:
+
+	$ git log --pretty="%h - %s" --author=gitster --after="2008-10-01T00:00:00-0400" \
+           --before="2008-10-31T23:59:59-0400" --no-merges -- t/
 	5610e3b - Fix testcase failure when extended attribute
 	acd3b9e - Enhance hold_lock_file_for_{update,append}()
 	f563754 - demonstrate breakage of detached checkout wi
@@ -671,15 +761,7 @@ For example, if you want to see which commits modifying test files in the Git so
 	51a94af - Fix "checkout --track -b newbranch" on detac
 	b0ad11e - pull: allow "git pull origin $something:$cur
 
-Of the nearly 20,000 commits in the Git source code history, this command shows the 6 that match those criteria.
-
-When using `git log` without specifying time,
-
-	git log --after=2008-10-01 --before=2008-11-01
-
-then it defaults to using the time at the instant the command is executed. For example when the above command is executed at time 09:00:00, then the result is equivalent to doing:
-
-	git log --after="2008-10-01 09:00:00" --before="2008-11-01 09:00:00"
+Of the more than 36,000 commits in the Git source code history, this command shows the 6 that match those criteria.
 
 ### Using a GUI to Visualize History ###
 

From 9de0db392918e9cc9afe2a4d301d76f9578f9b75 Mon Sep 17 00:00:00 2001
From: nicesw123 <nicesw123@users.noreply.github.com>
Date: Sun, 4 May 2014 01:05:32 +0200
Subject: [PATCH 414/690] minor: fix code formatting (for pdf output)

---
 en/02-git-basics/01-chapter2.markdown | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/en/02-git-basics/01-chapter2.markdown b/en/02-git-basics/01-chapter2.markdown
index 6ec2e3cf4..dc3d4ccc2 100644
--- a/en/02-git-basics/01-chapter2.markdown
+++ b/en/02-git-basics/01-chapter2.markdown
@@ -752,8 +752,9 @@ even though `2008-06-01T09:00:00+0100` would actually be 10:00 in June in Paris:
 
 As a final example:, if you want to see which commits modifying test files in the Git source code history were committed by Junio Hamano and committed with CommitDate being in the month of October 2008 (relative to the timezone of New York) and were not merges, you can run something like this:
 
-	$ git log --pretty="%h - %s" --author=gitster --after="2008-10-01T00:00:00-0400" \
-           --before="2008-10-31T23:59:59-0400" --no-merges -- t/
+        $ git log --pretty="%h - %s" --author=gitster \
+           --after="2008-10-01T00:00:00-0400"         \
+          --before="2008-10-31T23:59:59-0400" --no-merges -- t/
 	5610e3b - Fix testcase failure when extended attribute
 	acd3b9e - Enhance hold_lock_file_for_{update,append}()
 	f563754 - demonstrate breakage of detached checkout wi

From f987da8c61924b4f710fd9aac26619bf6b5e9d85 Mon Sep 17 00:00:00 2001
From: iosias <stemcel@gmail.com>
Date: Mon, 5 May 2014 10:02:30 -0700
Subject: [PATCH 415/690] Update 01-chapter7.markdown

Global variables are not necessary to demonstrate anything in this script. Tested:

% cat foo.rb
#!/usr/bin/env ruby

refname = ARGV[0]
oldrev  = ARGV[1]
newrev  = ARGV[2]
user    = ENV['USER']

puts "Enforcing Policies... \n(#{refname}) (#{oldrev[0,6]}) (#{newrev[0,6]})"

% ./foo.rb refs/heads/what $(git rev-parse HEAD) $(git rev-parse HEAD~~)
Enforcing Policies...
(refs/heads/what) (27240a) (ae2ef7)
---
 en/07-customizing-git/01-chapter7.markdown | 12 +++++-------
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/en/07-customizing-git/01-chapter7.markdown b/en/07-customizing-git/01-chapter7.markdown
index 7029378e5..b1dbaa989 100644
--- a/en/07-customizing-git/01-chapter7.markdown
+++ b/en/07-customizing-git/01-chapter7.markdown
@@ -613,14 +613,12 @@ All the server-side work will go into the update file in your hooks directory. T
 
 	#!/usr/bin/env ruby
 
-	$refname = ARGV[0]
-	$oldrev  = ARGV[1]
-	$newrev  = ARGV[2]
-	$user    = ENV['USER']
-
-	puts "Enforcing Policies... \n(#{$refname}) (#{$oldrev[0,6]}) (#{$newrev[0,6]})"
+	refname = ARGV[0]
+	oldrev  = ARGV[1]
+	newrev  = ARGV[2]
+	user    = ENV['USER']
 
-Yes, I’m using global variables. Don’t judge me — it’s easier to demonstrate in this manner.
+	puts "Enforcing Policies... \n(#{refname}) (#{oldrev[0,6]}) (#{newrev[0,6]})"
 
 #### Enforcing a Specific Commit-Message Format ####
 

From 88239bb0ddb32e60334f59b2346ca1c101e6c4fd Mon Sep 17 00:00:00 2001
From: Carlos Arturo Guerra Parra <carlosarturoguerra@gmail.com>
Date: Mon, 12 May 2014 00:35:11 +0200
Subject: [PATCH 416/690] [es] Update Chapter 1: word mistake

---
 es/01-introduction/01-chapter1.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/es/01-introduction/01-chapter1.markdown b/es/01-introduction/01-chapter1.markdown
index 64bc3bbdf..e340e566b 100644
--- a/es/01-introduction/01-chapter1.markdown
+++ b/es/01-introduction/01-chapter1.markdown
@@ -194,7 +194,7 @@ Git trae una herramienta llamada `git config` que te permite obtener y establece
 *	Archivo `~/.gitconfig` file: Específico a tu usuario. Puedes hacer que Git lea y escriba específicamente en este archivo pasando la opción `--global`.
 *	Archivo config en el directorio de Git (es decir, `.git/config`) del repositorio que estés utilizando actualmente: Específico a ese repositorio. Cada nivel sobrescribe los valores del nivel anterior, por lo que los valores de `.git/config` tienen preferencia sobre los de `/etc/gitconfig`.
 
-En sistemas Windows, Git busca el archivo `.gitconfig` en el directorio `$HOME` (`%USERPROFILE%` in Windows’ environment), que es `C:\Documents and Settings\$USER` para la mayoría de usuarios, pedendiendo de la versión (`$USER` es `%USERNAME%` en el entorno Windows). También busca en el directorio `/etc/gitconfig`, aunque esta ruta es relativa a la raíz MSys, que es donde quiera que decidieses instalar Git en tu sistema Windows cuando ejecutaste el instalador.
+En sistemas Windows, Git busca el archivo `.gitconfig` en el directorio `$HOME` (`%USERPROFILE%` in Windows’ environment), que es `C:\Documents and Settings\$USER` para la mayoría de usuarios, dependiendo de la versión (`$USER` es `%USERNAME%` en el entorno Windows). También busca en el directorio `/etc/gitconfig`, aunque esta ruta es relativa a la raíz MSys, que es donde quiera que decidieses instalar Git en tu sistema Windows cuando ejecutaste el instalador.
 
 ### Tu identidad ###
 

From 305be5218cefa0d5db062de83a65107efb269dec Mon Sep 17 00:00:00 2001
From: Carlos Arturo Guerra Parra <carlosarturoguerra@gmail.com>
Date: Tue, 13 May 2014 18:32:06 +0200
Subject: [PATCH 417/690] [es] Update Chapter 2

Update from commit "Added fix for git remote -v example" 7ba488683f86e8b507c0f04c36544f512bbc3447
---
 es/02-git-basics/01-chapter2.markdown | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/es/02-git-basics/01-chapter2.markdown b/es/02-git-basics/01-chapter2.markdown
index 5d981cf99..553f46f4b 100644
--- a/es/02-git-basics/01-chapter2.markdown
+++ b/es/02-git-basics/01-chapter2.markdown
@@ -738,7 +738,8 @@ Para ver qué repositorios remotos tienes configurados, puedes ejecutar el coman
 También puedes añadir la opción `-v`, que muestra la URL asociada a cada repositorio remoto:
 
 	$ git remote -v
-	origin	git://github.com/schacon/ticgit.git
+	origin  git://github.com/schacon/ticgit.git (fetch)
+	origin  git://github.com/schacon/ticgit.git (push)
 
 Si tienes más de un remoto, este comando los lista todos. Por ejemplo, mi repositorio Grit tiene esta pinta:
 

From aa3000778b3827f0222f2207cce38b3a3c7aeb88 Mon Sep 17 00:00:00 2001
From: Carlos Arturo Guerra Parra <carlosarturoguerra@gmail.com>
Date: Tue, 13 May 2014 19:52:51 +0200
Subject: [PATCH 418/690] [es] Update Chapter 2 from english version

Update from commit "Chapter 2 improvements and corrections " cfdce8587ed1654f07665660d5347a4b6309a062
---
 es/02-git-basics/01-chapter2.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/es/02-git-basics/01-chapter2.markdown b/es/02-git-basics/01-chapter2.markdown
index 553f46f4b..cbbc2d466 100644
--- a/es/02-git-basics/01-chapter2.markdown
+++ b/es/02-git-basics/01-chapter2.markdown
@@ -1007,7 +1007,7 @@ Puedes incluso etiquetar confirmaciones después de avanzar sobre ellas. Supón
 
 Ahora, supón que olvidaste etiquetar el proyecto en v1.2, que estaba en la confirmación "updated rakefile". Puedes hacerlo ahora. Para etiquetar esa confirmación especifica la suma de comprobación de la confirmación (o una parte de la misma) al final del comando:
 
-	$ git tag -a v1.2 9fceb02
+	$ git tag -a v1.2 -m 'version 1.2' 9fceb02
 
 Puedes ver que has etiquetado la confirmación:
 

From 0f3652ac67c02c48bffce1ab77a65cd0fbae5957 Mon Sep 17 00:00:00 2001
From: Carlos Arturo Guerra Parra <carlosarturoguerra@gmail.com>
Date: Tue, 13 May 2014 20:24:42 +0200
Subject: [PATCH 419/690] [es] Update Chapter 2: new sentence from English
 version

Updated from "Minor updates (Windows & typo)" b294744d98a6f6cdbc3508b0058f8616147c1596
---
 es/02-git-basics/01-chapter2.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/es/02-git-basics/01-chapter2.markdown b/es/02-git-basics/01-chapter2.markdown
index cbbc2d466..b10c1831c 100644
--- a/es/02-git-basics/01-chapter2.markdown
+++ b/es/02-git-basics/01-chapter2.markdown
@@ -380,7 +380,7 @@ El comando `git rm` acepta archivos, directorios, y patrones glob. Es decir, que
 
 	$ git rm log/\*.log
 
-Fíjate en la barra hacia atrás (`\`) antes del `*`. Es necesaria debido a que Git hace su propia expansión de rutas, además de la expansión que hace tu shell. Este comando elimina todos los archivos con la extensión `.log` en el directorio `log/`. También puedes hacer algo así:
+Fíjate en la barra hacia atrás (`\`) antes del `*`. Es necesaria debido a que Git hace su propia expansión de rutas, además de la expansión que hace tu shell. En la consola del sistema de Windows, esta barra debe de ser omitida. Este comando elimina todos los archivos con la extensión `.log` en el directorio `log/`. También puedes hacer algo así:
 
 	$ git rm \*~
 

From 6e793954966d8dcc214105d57350515f20686fb4 Mon Sep 17 00:00:00 2001
From: Carlos Arturo Guerra Parra <carlosarturoguerra@gmail.com>
Date: Tue, 13 May 2014 21:26:27 +0200
Subject: [PATCH 420/690] [es] Update Chapter 2: new sentence from English
 version

Updated from commit: "Mention --oneline in Table 2-2"
5502e94d3237d285eb3157cc7e4d6710d650464e
---
 es/02-git-basics/01-chapter2.markdown | 1 +
 1 file changed, 1 insertion(+)

diff --git a/es/02-git-basics/01-chapter2.markdown b/es/02-git-basics/01-chapter2.markdown
index b10c1831c..232d0b4e9 100644
--- a/es/02-git-basics/01-chapter2.markdown
+++ b/es/02-git-basics/01-chapter2.markdown
@@ -585,6 +585,7 @@ Las opciones `oneline` y `format` son especialmente útiles combinadas con otra
 	--relative-date	Muestra la fecha en formato relativo (por ejemplo, “2 weeks ago” (“hace 2 semanas”)) en lugar del formato completo.
 	--graph	Muestra un gráfico ASCII con la historia de ramificaciones y uniones.
 	--pretty	Muestra las confirmaciones usando un formato alternativo. Posibles opciones son oneline, short, full, fuller y format (mediante el cual puedes especificar tu propio formato).
+	--oneline	Un cómodo acortamiento de la opción `--pretty=oneline --abbrev-commit`.
 
 ### Limitando la salida del histórico ###
 

From 4b2c0b013aa544f0ecc9873798c41625b2edb54d Mon Sep 17 00:00:00 2001
From: Carlos Arturo Guerra Parra <carlosarturoguerra@gmail.com>
Date: Tue, 13 May 2014 21:38:29 +0200
Subject: [PATCH 421/690] [es] Update Chapter 2 from English version

Updated from commit: "Add an example on `**/` pattern to the example of .gitignore file."
df7639bb6d5b6ef453de18bd43d0b7f59464d1ab
---
 es/02-git-basics/01-chapter2.markdown | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/es/02-git-basics/01-chapter2.markdown b/es/02-git-basics/01-chapter2.markdown
index 232d0b4e9..7127ba3e7 100644
--- a/es/02-git-basics/01-chapter2.markdown
+++ b/es/02-git-basics/01-chapter2.markdown
@@ -180,6 +180,10 @@ He aquí otro ejemplo de archivo .gitignore:
 	build/
 	# ignore doc/notes.txt, but not doc/server/arch.txt
 	doc/*.txt
+	# ignore all .txt files in the doc/ directory
+	doc/**/*.txt
+
+El patrón `**/` está disponible en Git desde la versión 1.8.2.
 
 ### Viendo tus cambios preparados y no preparados ###
 

From 71cc219597a07e81ab3360944254614151c22816 Mon Sep 17 00:00:00 2001
From: Carlos Arturo Guerra Parra <carlosarturoguerra@gmail.com>
Date: Tue, 13 May 2014 22:21:37 +0200
Subject: [PATCH 422/690] [es] Update Chapter 2: Translation of some new
 English paragraphs

Updated from commit: "Add --word-diff option description"
716e1926c63890027cf133492bf59c8f05e8bfa1
and from commit: "Add --word-diff option description v2"
aa830655d85f8799554a8789a9607347c81e47be
---
 es/02-git-basics/01-chapter2.markdown | 21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)

diff --git a/es/02-git-basics/01-chapter2.markdown b/es/02-git-basics/01-chapter2.markdown
index 7127ba3e7..12d9cc29c 100644
--- a/es/02-git-basics/01-chapter2.markdown
+++ b/es/02-git-basics/01-chapter2.markdown
@@ -494,6 +494,26 @@ Una de las opciones más útiles es `-p`, que muestra las diferencias introducid
 
 Esta opción muestra la misma información, pero añadiendo tras cada entrada las diferencias que le corresponden. Esto resulta muy útil para revisiones de código, o para visualizar rápidamente lo que ha pasado en las confirmaciones enviadas por un colaborador.
 
+A veces es más fácil revisar cambios a nivel de palabra que a nivel de línea. Git dispone de la opción `--word-diff`, que se puede añadir al comando `git log -p` para obtener las diferencias por palabras en lugar de las diferencias línea por línea. Formatear las diferencias a nivel de palabra es bastante inusual cuando se aplica a código fuente, pero resulta muy práctico cuando se aplica a grandes archivos de texto, como libros o tu propia tesis. He aquí un ejemplo:
+
+	$ git log -U1 --word-diff
+	commit ca82a6dff817ec66f44342007202690a93763949
+	Author: Scott Chacon <schacon@gee-mail.com>
+	Date:   Mon Mar 17 21:52:11 2008 -0700
+
+	    changed the version number
+
+	diff --git a/Rakefile b/Rakefile
+	index a874b73..8f94139 100644
+	--- a/Rakefile
+	+++ b/Rakefile
+	@@ -7,3 +7,3 @@ spec = Gem::Specification.new do |s|
+	    s.name      =   "simplegit"
+	    s.version   =   [-"0.1.0"-]{+"0.1.1"+}
+	    s.author    =   "Scott Chacon"
+
+Como se puede ver, no aparecen líneas añadidas o eliminadas en la salida como en las diferencias normales. Se puede ver la palabra añadida encerrada en `{+ +}` y la eliminada en `[- -]`. Puede que se quiera reducir las usuales tres líneas de contexto en las diferencias a sólo una línea puesto que el contexto es ahora de palabras, no de líneas. Se puede hacer esto con `-U1`, como hicimos en el ejemplo de arriba.
+
 También puedes usar con `git log` una serie de opciones de resumen. Por ejemplo, si quieres ver algunas estadísticas de cada confirmación, puedes usar la opción `--stat`:
 
 	$ git log --stat
@@ -581,6 +601,7 @@ Las opciones `oneline` y `format` son especialmente útiles combinadas con otra
 
 	Opción	Descripción
 	-p	Muestra el parche introducido en cada confirmación.
+	--word-diff	Muestra el parche en formato de una palabra.
 	--stat	Muestra estadísticas sobre los archivos modificados en cada confirmación.
 	--shortstat	Muestra solamente la línea de resumen de la opción `--stat`.
 	--name-only	Muestra la lista de archivos afectados.

From 4111372d85cc0584a8b9b2768d37da6abdfaabc5 Mon Sep 17 00:00:00 2001
From: Carlos Arturo Guerra Parra <carlosarturoguerra@gmail.com>
Date: Tue, 13 May 2014 22:42:23 +0200
Subject: [PATCH 423/690] [es] Update Chapter 2: new sentence from English
 version

Update from commit: "Direct the reader directly to the git-completion download link"
21e84addadf2ea58eebfeb77379fc0434aa952a3
---
 es/02-git-basics/01-chapter2.markdown | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/es/02-git-basics/01-chapter2.markdown b/es/02-git-basics/01-chapter2.markdown
index 12d9cc29c..bc2425c73 100644
--- a/es/02-git-basics/01-chapter2.markdown
+++ b/es/02-git-basics/01-chapter2.markdown
@@ -1092,9 +1092,9 @@ Antes de que terminemos este capitulo de Git básico, unos pocos trucos y consej
 
 ### Autocompletado ###
 
-Si usas el shell Bash, Git viene con un buen script de autocompletado que puedes activar. Descarga el código fuente de Git y busca en el directorio `contrib/completion`; ahí debe haber un archivo llamado `git-completion.bash`. Copia este fichero en tu directorio `home` y añade esto a tu archivo `.bashrc`: 
+Si usas el shell Bash, Git viene con un buen script de autocompletado que puedes activar. Descárgalo directamente desde el código fuente de Git en `https://github.com/git/git/blob/master/contrib/completion/git-completion.bash`, copia este fichero en tu directorio `home` y añade esto a tu archivo `.bashrc`: 
 
-	source ~/.git-completion.bash
+	source ~/git-completion.bash
 
 Si quieres que Git tenga automáticamente autocompletado para todos los usuarios, copia este script en el directorio `/opt/local/etc/bash_completion.d` en sistemas Mac, o en el directorio `/etc/bash_completion.d/` en sistemas Linux. Este es un directorio de scripts que Bash cargará automáticamente para proveer de autocompletado.
 

From d0551ea518abe1e791ab9a34fd743a48c60eb010 Mon Sep 17 00:00:00 2001
From: Carlos Arturo Guerra Parra <carlosarturoguerra@gmail.com>
Date: Wed, 14 May 2014 00:23:21 +0200
Subject: [PATCH 424/690] [es] Updated Chapter 2: Included not translated
 paragraph in a comment

This English paragraph comes from commit: "As of current Git version, --all-match matches greps "
60e261895a77951a6541470c9438f32a1e5b7fd0

I have included it here to not forget that it should be translated if necesary.
---
 es/02-git-basics/01-chapter2.markdown | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/es/02-git-basics/01-chapter2.markdown b/es/02-git-basics/01-chapter2.markdown
index bc2425c73..d46c1cb7d 100644
--- a/es/02-git-basics/01-chapter2.markdown
+++ b/es/02-git-basics/01-chapter2.markdown
@@ -624,6 +624,13 @@ Este comando acepta muchos formatos. Puedes indicar una fecha concreta (“2008-
 
 También puedes filtrar la lista para que muestre sólo aquellas confirmaciones que cumplen ciertos criterios. La opción `--author` te permite filtrar por autor, y `--grep` te permite buscar palabras clave entre los mensajes de confirmación. (Ten en cuenta que si quieres aplicar ambas opciones simultáneamente, tienes que añadir `--all-match`, o el comando mostrará las confirmaciones que cumplan cualquiera de las dos, no necesariamente las dos a la vez.)
 
+<!-- The prior paragraph was changed in English version for the following two in commit 60e261895a77951a6541470c9438f32a1e5b7fd0. It has not been trasnlated yet:
+
+You can also filter the list to commits that match some search criteria. The `--author` option allows you to filter on a specific author, and the `--grep` option lets you search for keywords in the commit messages. (Note that if you specify both author and grep options, the command will match commits with both.)
+
+If you want to specify multiple grep options, you have to add `--all-match` or the command will match commits with either.
+-->
+
 La última opción verdaderamente útil para filtrar la salida de `git log` es especificar una ruta. Si especificas la ruta de un directorio o archivo, puedes limitar la salida a aquellas confirmaciones que introdujeron un cambio en dichos archivos. Ésta debe ser siempre la última opción, y suele ir precedida de dos guiones (`--`) para separar la ruta del resto de opciones.
 
 En la Tabla 2-3 se listan estas opciones, y algunas otras bastante comunes, a modo de referencia.

From 77c738375f4fd7a2aea1240e6335ab144abaefba Mon Sep 17 00:00:00 2001
From: nicesw123 <nicesw123@users.noreply.github.com>
Date: Thu, 15 May 2014 21:47:41 +0200
Subject: [PATCH 425/690] provide timezone-examples from different Cities *
 Auckland/New Zealand, Berlin, etc. -- not just Paris * minor corrections

---
 en/02-git-basics/01-chapter2.markdown | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/en/02-git-basics/01-chapter2.markdown b/en/02-git-basics/01-chapter2.markdown
index dc3d4ccc2..dd13cc7fc 100644
--- a/en/02-git-basics/01-chapter2.markdown
+++ b/en/02-git-basics/01-chapter2.markdown
@@ -660,12 +660,12 @@ The lines must be formatted as follows
 
 ### Limiting Log Output according to Date/Time ###
 
-To determine which commits in the Git source code repository (git://git.kernel.org/pub/scm/git/git.git) have CommitDate on 2014-04-29 relative to your local timezone, use
+To determine which commits in the Git source code repository (git://git.kernel.org/pub/scm/git/git.git) have CommitDate on 2014-04-29 relative to your local timezone (as set on your computer), use
 
     $ git log --after="2014-04-29 00:00:00" --before="2014-04-29 23:59:59" \
       --pretty=fuller
 
-However this command will not yield identical results, when run by collegues, who may be situated in other timezones around the world. Therefore it is recommended to always use an absolute time such as ISO 8601 format (which includes timezone information) as argument to `--after` and `--before`, so that everone running the command will get the same repeatable results. If your timezone is that of France (e.g. you are in Paris) you can change the above example, to use absolute-time arguments, so that all your collegues around the world would get the same results as you. First determine the absolute-times using e.g. the `date` program:
+However this command will not yield identical results when run by collegues, who may be situated in other timezones around the world. Therefore it is recommended to always use an absolute time such as ISO 8601 format (which includes timezone information) as argument to `--after` and `--before`, so that everone running the command will get the same repeatable results. If your timezone is that of France (e.g. you are in Paris) you can change the above example, to use absolute-time arguments. First determine the absolute-times using e.g. the `date` program:
 
     $ TZ="CET-1CEST,M3.5.0,M10.5.0/3" date --date="2014-04-29 00:00:00" -Is
     2014-04-29T00:00:00+0200
@@ -695,7 +695,7 @@ For example: for `2014-04-29T23:59:59+0200` the corresponding
 UTC is `2014-04-29 21:59:59`.
 
 
-To obtain commits made at a specific instant in time, we can use e.g.
+To obtain commits made at a specific instant in time (e.g. `2013-04-29T17:07:22+0200`), we can use
 
     $ git log  --after="2013-04-29T17:07:22+0200"      \
               --before="2013-04-29T17:07:22+0200" --pretty=fuller
@@ -724,9 +724,9 @@ We can change the way that these are displayed in the resulting log list. `--dat
     $ git log  --after="2013-04-29T17:07:22+0200" \
               --before="2013-04-29T17:07:22+0200" --pretty=fuller --date=local
 
-To show all times according to e.g. French timezone, we can prefix an appropriate `TZ=..."` value to the above command (under GNU/Linux simply `TZ="Europe/Paris"`):
+To show all times according to the timezone of New Zealand, we can prefix an appropriate `TZ=..."` value to the above command (under GNU/Linux simply `TZ="Pacific/Auckland"`):
 
-    $ TZ="CET-1CEST,M3.5.0,M10.5.0/3"             \
+    $ TZ="NZST-12NZDT,M9.5.0,M4.1.0/3"            \
       git log  --after="2013-04-29T17:07:22+0200" \
               --before="2013-04-29T17:07:22+0200" --pretty=fuller --date=local
 
@@ -736,17 +736,17 @@ When using `git log` without specifying time,
 
     $ git log --after=2008-06-01 --before=2008-07-01
 
-the time defaults to the time at which the command is run. For example when the above command is executed at 09:00, then the result is usually equivalent to doing:
+the time defaults to the time at which the command is run on your computer. For example when the above command is executed at 09:00, then the result is usually equivalent to doing:
 
     $ git log --after="2008-06-01 09:00:00" \
       --before="2008-07-01 09:00:00"
 
-More precisely: Actually in this case Git considers the time-offset from UTC to stay the same for the whole year. Offset-changes from UTC will not be considered. The time that will be considered, is the same time as when the command is run, including the identical timezone offset from UTC. Therefore when the above (date-only) command is run in December in Paris at local time `2009-12-14T09:00:00+0100`, then the result is equivalent to doing:
+More precisely: Actually in this case Git considers the time-offset from UTC to stay the same for the whole year. Offset-changes from UTC will not be considered: The time that will be considered is the same time as when the command is run, including the identical timezone offset from UTC. Therefore when the above (date-only) command is run in December in Berlin at local time `2009-12-14T09:00:00+0100`, then the result is equivalent to doing:
 
     $ git log --after="2008-06-01T09:00:00+0100" \
       --before="2008-07-01T09:00:00+0100"
 
-even though `2008-06-01T09:00:00+0100` would actually be 10:00 in June in Paris:
+even though `2008-06-01T09:00:00+0100` would actually be 10:00 in June in Berlin (because of Daylight Saving Time):
 
  `2008-06-01T10:00:00+0200`.
 

From a30a7dd6b1b18dd8446a331619ee303158db068b Mon Sep 17 00:00:00 2001
From: nicesw123 <nicesw123@users.noreply.github.com>
Date: Thu, 15 May 2014 22:06:53 +0200
Subject: [PATCH 426/690] minor: remove repetition ("committed")

---
 en/02-git-basics/01-chapter2.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/en/02-git-basics/01-chapter2.markdown b/en/02-git-basics/01-chapter2.markdown
index dd13cc7fc..6af8e59e8 100644
--- a/en/02-git-basics/01-chapter2.markdown
+++ b/en/02-git-basics/01-chapter2.markdown
@@ -750,7 +750,7 @@ even though `2008-06-01T09:00:00+0100` would actually be 10:00 in June in Berlin
 
  `2008-06-01T10:00:00+0200`.
 
-As a final example:, if you want to see which commits modifying test files in the Git source code history were committed by Junio Hamano and committed with CommitDate being in the month of October 2008 (relative to the timezone of New York) and were not merges, you can run something like this:
+As a final example:, if you want to see which commits modifying test files in the Git source code history were committed by Junio Hamano with CommitDate being in the month of October 2008 (relative to the timezone of New York) and were not merges, you can run something like this:
 
         $ git log --pretty="%h - %s" --author=gitster \
            --after="2008-10-01T00:00:00-0400"         \

From de1d8de938210c39f875b30f1ca5f0d05b2f234f Mon Sep 17 00:00:00 2001
From: nicesw123 <nicesw123@users.noreply.github.com>
Date: Thu, 15 May 2014 22:22:07 +0200
Subject: [PATCH 427/690] shorten explanation for `git log --after=2008-06-01`
 (date-only)

---
 en/02-git-basics/01-chapter2.markdown | 15 +++------------
 1 file changed, 3 insertions(+), 12 deletions(-)

diff --git a/en/02-git-basics/01-chapter2.markdown b/en/02-git-basics/01-chapter2.markdown
index 6af8e59e8..4e68be6ed 100644
--- a/en/02-git-basics/01-chapter2.markdown
+++ b/en/02-git-basics/01-chapter2.markdown
@@ -736,19 +736,10 @@ When using `git log` without specifying time,
 
     $ git log --after=2008-06-01 --before=2008-07-01
 
-the time defaults to the time at which the command is run on your computer. For example when the above command is executed at 09:00, then the result is usually equivalent to doing:
+the time defaults to the time at which the command is run on your computer (keeping the identical offset from UTC; effectively disregarding Daylight Saving Time). For example when the above command is executed at 09:00 on your computer with your timezone currently 3 hours ahead of UTC, then the result is equivalent to doing:
 
-    $ git log --after="2008-06-01 09:00:00" \
-      --before="2008-07-01 09:00:00"
-
-More precisely: Actually in this case Git considers the time-offset from UTC to stay the same for the whole year. Offset-changes from UTC will not be considered: The time that will be considered is the same time as when the command is run, including the identical timezone offset from UTC. Therefore when the above (date-only) command is run in December in Berlin at local time `2009-12-14T09:00:00+0100`, then the result is equivalent to doing:
-
-    $ git log --after="2008-06-01T09:00:00+0100" \
-      --before="2008-07-01T09:00:00+0100"
-
-even though `2008-06-01T09:00:00+0100` would actually be 10:00 in June in Berlin (because of Daylight Saving Time):
-
- `2008-06-01T10:00:00+0200`.
+    $ git log --after="2008-06-01T09:00:00+0300" \
+      --before="2008-07-01T09:00:00+0300"
 
 As a final example:, if you want to see which commits modifying test files in the Git source code history were committed by Junio Hamano with CommitDate being in the month of October 2008 (relative to the timezone of New York) and were not merges, you can run something like this:
 

From 3e67b84c15c63f02c13c94e55b1c1aebc9091972 Mon Sep 17 00:00:00 2001
From: nicesw123 <nicesw123@users.noreply.github.com>
Date: Thu, 15 May 2014 22:26:28 +0200
Subject: [PATCH 428/690] `git log --after=2008-06-01` keeps timezone offset
 from UTC equiv. to the time when it is run on your computer. Saying this is
 "disregarding Daylight Saving Time" is confusing, because it could lead one
 to mistakenly assume that git then only considers summer-time, or only
 winter-time. But this is not the case. Git just keeps the offset from UTC
 identical.

---
 en/02-git-basics/01-chapter2.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/en/02-git-basics/01-chapter2.markdown b/en/02-git-basics/01-chapter2.markdown
index 4e68be6ed..465f3cc9a 100644
--- a/en/02-git-basics/01-chapter2.markdown
+++ b/en/02-git-basics/01-chapter2.markdown
@@ -736,7 +736,7 @@ When using `git log` without specifying time,
 
     $ git log --after=2008-06-01 --before=2008-07-01
 
-the time defaults to the time at which the command is run on your computer (keeping the identical offset from UTC; effectively disregarding Daylight Saving Time). For example when the above command is executed at 09:00 on your computer with your timezone currently 3 hours ahead of UTC, then the result is equivalent to doing:
+the time defaults to the time at which the command is run on your computer (keeping the identical offset from UTC). For example when the above command is executed at 09:00 on your computer with your timezone currently 3 hours ahead of UTC, then the result is equivalent to doing:
 
     $ git log --after="2008-06-01T09:00:00+0300" \
       --before="2008-07-01T09:00:00+0300"

From f5170bb2e34131c7088236066d13d1f657dfa381 Mon Sep 17 00:00:00 2001
From: Alex Moundalexis <alexm@clouderagovt.com>
Date: Fri, 16 May 2014 12:41:42 -0400
Subject: [PATCH 429/690] Update command line output in Chapter 2

The command line output in the examples is slightly inconsistent with the
latest version; git doesn't strip content from the commit message.
---
 en/02-git-basics/01-chapter2.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/en/02-git-basics/01-chapter2.markdown b/en/02-git-basics/01-chapter2.markdown
index 8090ba342..74784dc65 100644
--- a/en/02-git-basics/01-chapter2.markdown
+++ b/en/02-git-basics/01-chapter2.markdown
@@ -324,7 +324,7 @@ You can see that the default commit message contains the latest output of the `g
 Alternatively, you can type your commit message inline with the `commit` command by specifying it after a `-m` flag, like this:
 
 	$ git commit -m "Story 182: Fix benchmarks for speed"
-	[master 463dc4f] Fix benchmarks for speed
+	[master 463dc4f] Story 182: Fix benchmarks for speed
 	 2 files changed, 3 insertions(+)
 	 create mode 100644 README
 

From 4d32ade1d53c023ca645f3bf2ad42ea3bc2e5f4c Mon Sep 17 00:00:00 2001
From: Carlos Arturo Guerra Parra <carlosarturoguerra@gmail.com>
Date: Sun, 18 May 2014 01:51:29 +0200
Subject: [PATCH 430/690] [es] Update chapter 3: fixed markdown mistake

Fixed wrong character to indicate markdown span of code:
There was made with apostrophes instead of backtick quotes

Signed-off-by: Carlos Arturo Guerra Parra <carlosarturoguerra@gmail.com>
---
 es/03-git-branching/01-chapter3.markdown | 166 +++++++++++------------
 1 file changed, 83 insertions(+), 83 deletions(-)

diff --git a/es/03-git-branching/01-chapter3.markdown b/es/03-git-branching/01-chapter3.markdown
index bb63d84a4..9a732fa23 100644
--- a/es/03-git-branching/01-chapter3.markdown
+++ b/es/03-git-branching/01-chapter3.markdown
@@ -15,7 +15,7 @@ Para ilustrar esto, vamos a suponer, por ejemplo, que tienes una carpeta con tre
 	$ git add README test.rb LICENSE
 	$ git commit -m 'initial commit of my project'
 
-Cuando creas una confirmación con el comando 'git commit', Git realiza sumas de control de cada subcarpeta (en el ejemplo, solamente tenemos la carpeta principal del proyecto), y guarda en el repositorio Git una copia de cada uno de los archivos contenidos en ella/s. Después, Git crea un objeto de confirmación con los metadatos pertinentes y un apuntador al nodo correspondiente del árbol de proyecto. Esto permitirá poder regenerar posteriormente dicha instantánea cuando sea necesario.
+Cuando creas una confirmación con el comando `git commit`, Git realiza sumas de control de cada subcarpeta (en el ejemplo, solamente tenemos la carpeta principal del proyecto), y guarda en el repositorio Git una copia de cada uno de los archivos contenidos en ella/s. Después, Git crea un objeto de confirmación con los metadatos pertinentes y un apuntador al nodo correspondiente del árbol de proyecto. Esto permitirá poder regenerar posteriormente dicha instantánea cuando sea necesario.
 
 En este momento, el repositorio de Git contendrá cinco objetos: un "blob" para cada uno de los tres archivos, un árbol con la lista de contenidos de la carpeta (más sus respectivas relaciones con los "blobs"), y una confirmación de cambios (commit) apuntando a la raiz de ese árbol y conteniendo el resto de metadatos pertinentes. Conceptualmente, el contenido del repositorio Git será algo parecido a la Figura 3-1
 
@@ -27,12 +27,12 @@ Si haces más cambios y vuelves a confirmar, la siguiente confirmación guardar
 Insert 18333fig0302.png 
 Figura 3-2. Datos en el repositorio tras una serie de confirmaciones.
 
-Una rama Git es simplemente un apuntador móvil apuntando a una de esas confirmaciones. La rama por defecto de Git es la rama 'master'. Con la primera confirmación de cambios que realicemos, se creará esta rama principal 'master' apuntando a dicha confirmación. En cada confirmación de cambios que realicemos, la rama irá avanzando automáticamente. Y la rama 'master' apuntará siempre a la última confirmación realizada.
+Una rama Git es simplemente un apuntador móvil apuntando a una de esas confirmaciones. La rama por defecto de Git es la rama `master`. Con la primera confirmación de cambios que realicemos, se creará esta rama principal `master` apuntando a dicha confirmación. En cada confirmación de cambios que realicemos, la rama irá avanzando automáticamente. Y la rama `master` apuntará siempre a la última confirmación realizada.
 
 Insert 18333fig0303.png 
 Figura 3-3. Apuntadores en el registro de confirmaciones de una rama.
 
-¿Qué sucede cuando creas una nueva rama? Bueno....., simplemente se crea un nuevo apuntador para que lo puedas mover libremente. Por ejemplo, si quieres crear una nueva rama denominada "testing". Usarás el comando 'git branch':
+¿Qué sucede cuando creas una nueva rama? Bueno....., simplemente se crea un nuevo apuntador para que lo puedas mover libremente. Por ejemplo, si quieres crear una nueva rama denominada "testing". Usarás el comando `git branch`:
 
 	$ git branch testing
 
@@ -41,16 +41,16 @@ Esto creará un nuevo apuntador apuntando a la misma confirmación donde estés
 Insert 18333fig0304.png 
 Figura 3-4. Apuntadores de varias ramas en el registro de confirmaciones de cambio.
 
-Y, ¿cómo sabe Git en qué rama estás en este momento? Pues...., mediante un apuntador especial denominado HEAD. Aunque es preciso comentar que este HEAD es totalmente distinto al concepto de HEAD en otros sistemas de control de cambios como Subversion o CVS. En Git, es simplemente el apuntador a la rama local en la que tú estés en ese momento. En este caso, en la rama 'master'. Puesto que el comando git branch solamente crea una nueva rama, y no salta a dicha rama.
+Y, ¿cómo sabe Git en qué rama estás en este momento? Pues...., mediante un apuntador especial denominado HEAD. Aunque es preciso comentar que este HEAD es totalmente distinto al concepto de HEAD en otros sistemas de control de cambios como Subversion o CVS. En Git, es simplemente el apuntador a la rama local en la que tú estés en ese momento. En este caso, en la rama `master`. Puesto que el comando git branch solamente crea una nueva rama, y no salta a dicha rama.
 
 Insert 18333fig0305.png 
 Figura 3-5. Apuntador HEAD a la rama donde estás actualmente.
 
-Para saltar de una rama a otra, tienes que utilizar el comando 'git checkout'. Hagamos una prueba, saltando a la rama 'testing' recién creada:
+Para saltar de una rama a otra, tienes que utilizar el comando `git checkout`. Hagamos una prueba, saltando a la rama `testing` recién creada:
 
 	$ git checkout testing
 
-Esto mueve el apuntador HEAD a la rama 'testing' (ver Figura 3-6).
+Esto mueve el apuntador HEAD a la rama `testing` (ver Figura 3-6).
 
 Insert 18333fig0306.png
 Figura 3-6. Apuntador HEAD apuntando a otra rama cuando saltamos de rama.
@@ -65,7 +65,7 @@ La Figura 3-7 ilustra el resultado.
 Insert 18333fig0307.png 
 Figura 3-7. La rama apuntada por HEAD avanza con cada confirmación de cambios.
 
-Observamos algo interesante: la rama 'testing' avanza, mientras que la rama 'master' permanece en la confirmación donde estaba cuando lanzaste el comando 'git checkout' para saltar. Volvamos ahora a la rama 'master':
+Observamos algo interesante: la rama `testing` avanza, mientras que la rama `master` permanece en la confirmación donde estaba cuando lanzaste el comando `git checkout` para saltar. Volvamos ahora a la rama `master`:
 
 	$ git checkout master
 
@@ -74,14 +74,14 @@ La Figura 3-8 muestra el resultado.
 Insert 18333fig0308.png 
 Figura 3-8. HEAD apunta a otra rama cuando hacemos un checkout.
 
-Este comando realiza dos acciones: Mueve el apuntador HEAD de nuevo a la rama 'master', y revierte los archivos de tu directorio de trabajo; dejandolos tal y como estaban en la última instantánea confirmada en dicha rama 'master'. Esto supone que los cambios que hagas desde este momento en adelante divergerán de la antigua versión del proyecto. Básicamente, lo que se está haciendo es rebobinar el trabajo que habias hecho temporalmente en la rama 'testing'; de tal forma que puedas avanzar en otra dirección diferente.
+Este comando realiza dos acciones: Mueve el apuntador HEAD de nuevo a la rama `master`, y revierte los archivos de tu directorio de trabajo; dejandolos tal y como estaban en la última instantánea confirmada en dicha rama `master`. Esto supone que los cambios que hagas desde este momento en adelante divergerán de la antigua versión del proyecto. Básicamente, lo que se está haciendo es rebobinar el trabajo que habias hecho temporalmente en la rama `testing`; de tal forma que puedas avanzar en otra dirección diferente.
 
 Haz algunos cambios más y confirmalos:
 
 	$ vim test.rb
 	$ git commit -a -m 'made other changes'
 
-Ahora el registro de tu proyecto diverge (ver Figura 3-9). Has creado una rama y saltado a ella, has trabajado sobre ella; has vuelto a la rama original, y has trabajado también sobre ella. Los cambios realizados en ambas sesiones de trabajo están aislados en ramas independientes: puedes saltar libremente de una a otra según estimes oportuno. Y todo ello simplemente con dos comandos:  'git branch' y 'git checkout'.
+Ahora el registro de tu proyecto diverge (ver Figura 3-9). Has creado una rama y saltado a ella, has trabajado sobre ella; has vuelto a la rama original, y has trabajado también sobre ella. Los cambios realizados en ambas sesiones de trabajo están aislados en ramas independientes: puedes saltar libremente de una a otra según estimes oportuno. Y todo ello simplemente con dos comandos:  `git branch` y `git checkout`.
 
 Insert 18333fig0309.png 
 Figura 3-9. Los registros de las ramas divergen.
@@ -114,7 +114,7 @@ Imagina que estas trabajando en un proyecto, y tienes un par de confirmaciones (
 Insert 18333fig0310.png 
 Figura 3-10. Un registro de confirmaciones simple y corto.
 
-Decides trabajar el problema #53, del sistema que tu compañia utiliza para llevar seguimiento de los problemas. Aunque, por supuesto, Git no está ligado a ningún sistema de seguimiento de problemas concreto. Como el problema #53 es un tema concreto y puntual en el que vas a trabajar, creas una nueva rama para él. Para crear una nueva rama y saltar a ella, en un solo paso, puedes utilizar el comando 'git checkout' con la opción '-b':
+Decides trabajar el problema #53, del sistema que tu compañia utiliza para llevar seguimiento de los problemas. Aunque, por supuesto, Git no está ligado a ningún sistema de seguimiento de problemas concreto. Como el problema #53 es un tema concreto y puntual en el que vas a trabajar, creas una nueva rama para él. Para crear una nueva rama y saltar a ella, en un solo paso, puedes utilizar el comando `git checkout` con la opción `-b`:
 
 	$ git checkout -b iss53
 	Switched to a new branch "iss53"
@@ -129,24 +129,24 @@ Figura 3-11 muestra el resultado.
 Insert 18333fig0311.png 
 Figura 3-11. Creación de un apuntador a la nueva rama.
 
-Trabajas en el sitio web y haces algunas confirmaciones de cambios (commits). Con ello avanzas la rama 'iss53', que es la que tienes activada (checked out) en este momento (es decir, a la que apunta HEAD; ver Figura 3-12):
+Trabajas en el sitio web y haces algunas confirmaciones de cambios (commits). Con ello avanzas la rama `iss53`, que es la que tienes activada (checked out) en este momento (es decir, a la que apunta HEAD; ver Figura 3-12):
 
 	$ vim index.html
 	$ git commit -a -m 'added a new footer [issue 53]'
 
 Insert 18333fig0312.png 
-Figura 3-12. La rama 'iss53' ha avanzado con tu trabajo.
+Figura 3-12. La rama `iss53` ha avanzado con tu trabajo.
 
-Entonces, recibes una llamada avisandote de otro problema urgente en el sitio web. Problema que has de resolver inmediatamente. Usando Git, no necesitas mezclar el nuevo problema con los cambios que ya habias realizado sobre el problema #53; ni tampoco perder tiempo revirtiendo esos cambios para poder trabajar sobre el contenido que está en producción. Basta con saltar de nuevo a la rama 'master' y continuar trabajando a partir de ella.
+Entonces, recibes una llamada avisandote de otro problema urgente en el sitio web. Problema que has de resolver inmediatamente. Usando Git, no necesitas mezclar el nuevo problema con los cambios que ya habias realizado sobre el problema #53; ni tampoco perder tiempo revirtiendo esos cambios para poder trabajar sobre el contenido que está en producción. Basta con saltar de nuevo a la rama `master` y continuar trabajando a partir de ella.
 
-Pero, antes de poder hacer eso, hemos de tener en cuenta  que teniendo cambios aún no confirmados en la carpeta de trabajo o en el área de preparación, Git no nos permitirá saltar a otra rama con la que podríamos tener conflictos.  Lo mejor es tener siempre un estado de trabajo limpio y despejado antes de saltar entre ramas. Y, para ello, tenemos algunos procedimientos (stash y commit ammend), que vamos a ver más adelante. Por ahora, como tenemos confirmados todos los cambios, podemos saltar a la rama 'master' sin problemas:
+Pero, antes de poder hacer eso, hemos de tener en cuenta  que teniendo cambios aún no confirmados en la carpeta de trabajo o en el área de preparación, Git no nos permitirá saltar a otra rama con la que podríamos tener conflictos.  Lo mejor es tener siempre un estado de trabajo limpio y despejado antes de saltar entre ramas. Y, para ello, tenemos algunos procedimientos (stash y commit ammend), que vamos a ver más adelante. Por ahora, como tenemos confirmados todos los cambios, podemos saltar a la rama `master` sin problemas:
 
 	$ git checkout master
 	Switched to branch "master"
 
 Tras esto, tendrás la carpeta de trabajo exactamente igual a como estaba antes de comenzar a trabajar sobre el problema #53. Y podrás concentrarte en el nuevo problema urgente. Es importante recordar que Git revierte la carpeta de trabajo exactamente al estado en que estaba en la confirmación (commit)  apuntada por la rama que activamos (checkout) en cada momento.  Git añade, quita y modifica archivos automáticamente. Para asegurarte que tu copia de trabajo es exactamente tal y como era la rama en la última confirmación de cambios realizada sobre ella.
 
-Volviendo al problema urgente. Vamos a crear una nueva rama 'hotfix', sobre la que trabajar hasta resolverlo (ver Figura 3-13):
+Volviendo al problema urgente. Vamos a crear una nueva rama `hotfix`, sobre la que trabajar hasta resolverlo (ver Figura 3-13):
 
 	$ git checkout -b 'hotfix'
 	Switched to a new branch "hotfix"
@@ -156,9 +156,9 @@ Volviendo al problema urgente. Vamos a crear una nueva rama 'hotfix', sobre la q
 	 1 files changed, 0 insertions(+), 1 deletions(-)
 
 Insert 18333fig0313.png 
-Figura 3-13. rama 'hotfix' basada en la rama 'master' original.
+Figura 3-13. rama `hotfix` basada en la rama `master` original.
 
-Puedes realizar las pruebas oportunas, asegurarte que la solución es correcta, e incorporar los cambios a la rama 'master' para ponerlos en producción. Esto se hace con el comando 'git merge':
+Puedes realizar las pruebas oportunas, asegurarte que la solución es correcta, e incorporar los cambios a la rama `master` para ponerlos en producción. Esto se hace con el comando `git merge`:
 
 	$ git checkout master
 	$ git merge hotfix
@@ -169,12 +169,12 @@ Puedes realizar las pruebas oportunas, asegurarte que la solución es correcta,
 
 Merece destacar la frase "Avance rápido" ("Fast forward") que aparece en la respuesta al comando. Git ha movido el apuntador hacia adelante, ya que la confirmación apuntada en la rama donde has fusionado estaba directamente "aguas arriba" respecto de la confirmación actual. Dicho de otro modo: cuando intentas fusionar una confirmación con otra confirmación accesible siguiendo directamente el registro de la primera; Git simplifica las cosas avanzando el puntero, ya que no hay ningûn otro trabajo divergente a fusionar. Esto es lo que se denomina "avance rápido" ("fast forward").
 
-Ahora, los cambios realizados están ya en la instantánea (snapshot) de la confirmación (commit) apuntada por la rama 'master'. Y puedes desplegarlos (ver Figura 3-14)
+Ahora, los cambios realizados están ya en la instantánea (snapshot) de la confirmación (commit) apuntada por la rama `master`. Y puedes desplegarlos (ver Figura 3-14)
 
 Insert 18333fig0314.png 
-Figura 3-14. Tras la fusión (merge), la rama 'master' apunta al mismo sitio que la rama 'hotfix'.
+Figura 3-14. Tras la fusión (merge), la rama `master` apunta al mismo sitio que la rama `hotfix`.
 
-Tras haber resuelto el problema urgente que te habia interrumpido tu trabajo, puedes volver a donde estabas. Pero antes, es interesante borrar la rama 'hotfix'. Ya que no la vamos a necesitar más, puesto que apunta exactamente al mismo sitio que la rama 'master'. Esto lo puedes hacer con la opción '-d' del comando 'git branch':
+Tras haber resuelto el problema urgente que te habia interrumpido tu trabajo, puedes volver a donde estabas. Pero antes, es interesante borrar la rama `hotfix`. Ya que no la vamos a necesitar más, puesto que apunta exactamente al mismo sitio que la rama `master`. Esto lo puedes hacer con la opción `-d` del comando `git branch`:
 
 	$ git branch -d hotfix
 	Deleted branch hotfix (3a0874c).
@@ -189,13 +189,13 @@ Y, con esto, ya estas dispuesto para regresar al trabajo sobre el problema #53 (
 	 1 files changed, 1 insertions(+), 0 deletions(-)
 
 Insert 18333fig0315.png 
-Figura 3-15. La rama 'iss53' puede avanzar independientemente.
+Figura 3-15. La rama `iss53` puede avanzar independientemente.
 
-Cabe indicar que todo el trabajo realizado en la rama 'hotfix' no está en los archivos de la rama 'iss53'. Si fuera necesario agregarlos, puedes fusionar (merge) la rama 'master' sobre la rama 'iss53' utilizando el comando 'git merge master'. O puedes esperar hasta que decidas llevar (pull) la rama 'iss53' a la rama 'master'.
+Cabe indicar que todo el trabajo realizado en la rama `hotfix` no está en los archivos de la rama `iss53`. Si fuera necesario agregarlos, puedes fusionar (merge) la rama `master` sobre la rama `iss53` utilizando el comando `git merge master`. O puedes esperar hasta que decidas llevar (pull) la rama `iss53` a la rama `master`.
 
 ### Procedimientos básicos de fusión ###
 
-Supongamos que tu trabajo con el problema #53 está ya completo y listo para fusionarlo (merge) con la rama 'master'. Para ello, de forma similar a como antes has hecho con la rama 'hotfix', vas a fusionar la rama 'iss53'. Simplemente, activando (checkout) la rama donde deseas fusionar y lanzando el comando 'git merge':
+Supongamos que tu trabajo con el problema #53 está ya completo y listo para fusionarlo (merge) con la rama `master`. Para ello, de forma similar a como antes has hecho con la rama `hotfix`, vas a fusionar la rama `iss53`. Simplemente, activando (checkout) la rama donde deseas fusionar y lanzando el comando `git merge`:
 
 	$ git checkout master
 	$ git merge iss53
@@ -203,7 +203,7 @@ Supongamos que tu trabajo con el problema #53 está ya completo y listo para fus
 	 README |    1 +
 	 1 files changed, 1 insertions(+), 0 deletions(-)
 
-Es algo diferente de la fusión realizada anteriormente con 'hotfix'. En este caso, el registro de desarrollo habia divergido en un punto anterior. Debido a que la confirmación en la rama actual no es ancestro directo de la rama que pretendes fusionar, Git tiene cierto trabajo extra que hacer. Git realizará una fusión a tres bandas, utilizando las dos instantáneas apuntadas por el extremo de cada una de las ramas y por el ancestro común a ambas dos. La figura 3-16 ilustra las tres instantáneas que Git utiliza para realizar la fusión en este caso.
+Es algo diferente de la fusión realizada anteriormente con `hotfix`. En este caso, el registro de desarrollo habia divergido en un punto anterior. Debido a que la confirmación en la rama actual no es ancestro directo de la rama que pretendes fusionar, Git tiene cierto trabajo extra que hacer. Git realizará una fusión a tres bandas, utilizando las dos instantáneas apuntadas por el extremo de cada una de las ramas y por el ancestro común a ambas dos. La figura 3-16 ilustra las tres instantáneas que Git utiliza para realizar la fusión en este caso.
 
 Insert 18333fig0316.png 
 Figura 3-16. Git identifica automáticamente el mejor ancestro común para realizar la fusión de las ramas.
@@ -215,20 +215,20 @@ Merece la pena destacar el hecho de que es el propio Git quien determina automá
 Insert 18333fig0317.png 
 Figura 3-17. Git crea automáticamente una nueva confirmación para la fusión.
 
-Ahora que todo tu trabajo está ya fusionado con la rama principal, ya no tienes necesidad de la rama 'iss53'. Por lo que puedes borrarla. Y cerrar manualmente el problema en el sistema de seguimiento de problemas de tu empresa.
+Ahora que todo tu trabajo está ya fusionado con la rama principal, ya no tienes necesidad de la rama `iss53`. Por lo que puedes borrarla. Y cerrar manualmente el problema en el sistema de seguimiento de problemas de tu empresa.
 
 	$ git branch -d iss53
 
 ### Principales conflictos que pueden surgir en las fusiones ###
 
-En algunas ocasiones, los procesos de fusión no suelen ser fluidos. Si hay modificaciones dispares en una misma porción de un mismo archivo en las dos ramas distintas que pretendes fusionar, Git no será capaz de fusionarlas directamente. Por ejemplo, si en tu trabajo del problema #53 has modificado una misma porción que también ha sido modificada en el problema 'hotfix'. Puedes obtener un conflicto de fusión tal que:
+En algunas ocasiones, los procesos de fusión no suelen ser fluidos. Si hay modificaciones dispares en una misma porción de un mismo archivo en las dos ramas distintas que pretendes fusionar, Git no será capaz de fusionarlas directamente. Por ejemplo, si en tu trabajo del problema #53 has modificado una misma porción que también ha sido modificada en el problema `hotfix`. Puedes obtener un conflicto de fusión tal que:
 
 	$ git merge iss53
 	Auto-merging index.html
 	CONFLICT (content): Merge conflict in index.html
 	Automatic merge failed; fix conflicts and then commit the result.
 
-Git no crea automáticamente una nueva fusión confirmada (merge commit). Sino que hace una pausa en el proceso, esperando a que tu resuelvas el conflicto. Para ver qué archivos permanecen sin fusionar en un determinado momento conflictivo de una fusión, puedes usar el comando 'git status':
+Git no crea automáticamente una nueva fusión confirmada (merge commit). Sino que hace una pausa en el proceso, esperando a que tu resuelvas el conflicto. Para ver qué archivos permanecen sin fusionar en un determinado momento conflictivo de una fusión, puedes usar el comando `git status`:
 
 	[master*]$ git status
 	index.html: needs merge
@@ -250,14 +250,14 @@ Todo aquello que sea conflictivo y no se haya podido resolver, se marca como "si
 	</div>
 	>>>>>>> iss53:index.html
 
-Donde nos dice que la versión en HEAD (la rama 'master', la que habias activado antes de lanzar el comando de fusión), contiene lo indicado en la parte superior del bloque (todo lo que está encima de '======='). Y que la versión en 'iss53' contiene el resto, lo indicado en la parte inferior del bloque. Para resolver el conflicto, has de elegir manualmente contenido de uno o de otro lado. Por ejemplo, puedes optar por cambiar el bloque, dejandolo tal que:
+Donde nos dice que la versión en HEAD (la rama `master`, la que habias activado antes de lanzar el comando de fusión), contiene lo indicado en la parte superior del bloque (todo lo que está encima de `=======`). Y que la versión en `iss53` contiene el resto, lo indicado en la parte inferior del bloque. Para resolver el conflicto, has de elegir manualmente contenido de uno o de otro lado. Por ejemplo, puedes optar por cambiar el bloque, dejandolo tal que:
 
 	<div id="footer">
 	please contact us at email.support@github.com
 	</div>
 
-Esta corrección contiene un poco de ambas partes. Y se han eliminado completamente las líneas `<<<<<<<` , `=======` y `>>>>>>>` Tras resolver todos los bloques conflictivos, has de lanzar comandos 'git add' para marcar cada archivo modificado. Marcar archivos como preparados (staging), indica a Git que sus conflictos han sido resueltos.
-Si en lugar de resolver directamente, prefieres utilizar una herramienta gráfica, puedes usar el comando 'git mergetool'. Esto arrancará la correspondiente herramienta de visualización y te permirá ir resolviendo conflictos con ella.
+Esta corrección contiene un poco de ambas partes. Y se han eliminado completamente las líneas `<<<<<<<` , `=======` y `>>>>>>>` Tras resolver todos los bloques conflictivos, has de lanzar comandos `git add` para marcar cada archivo modificado. Marcar archivos como preparados (staging), indica a Git que sus conflictos han sido resueltos.
+Si en lugar de resolver directamente, prefieres utilizar una herramienta gráfica, puedes usar el comando `git mergetool`. Esto arrancará la correspondiente herramienta de visualización y te permirá ir resolviendo conflictos con ella.
 
 	$ git mergetool
 	merge tool candidates: kdiff3 tkdiff xxdiff meld gvimdiff opendiff emerge vimdiff
@@ -268,11 +268,11 @@ Si en lugar de resolver directamente, prefieres utilizar una herramienta gráfic
 	  {remote}: modified
 	Hit return to start merge resolution tool (opendiff):
 
-Si deseas usar una herramienta distinta de la escogida por defecto (en mi caso 'opendiff', porque estoy lanzando el comando en un Mac), puedes escogerla entre la lista de herramientas soportadas mostradas al principio ("merge tool candidates"). Tecleando el nombre de dicha herramienta. En el capítulo 7 se verá cómo cambiar este valor por defecto de tu entorno de trabajo.
+Si deseas usar una herramienta distinta de la escogida por defecto (en mi caso `opendiff`, porque estoy lanzando el comando en un Mac), puedes escogerla entre la lista de herramientas soportadas mostradas al principio ("merge tool candidates"). Tecleando el nombre de dicha herramienta. En el capítulo 7 se verá cómo cambiar este valor por defecto de tu entorno de trabajo.
 
 Tras salir de la herramienta de fusionado, Git preguntará a ver si hemos resuelto todos los conflictos y la fusión ha sido satisfactoria. Si le indicas que así ha sido, Git marca como preparado (staged) el archivo que acabamos de modificar.
 
-En cualquier momento, puedes lanzar el comando 'git status' para ver si ya has resuelto todos los conflictos:
+En cualquier momento, puedes lanzar el comando `git status` para ver si ya has resuelto todos los conflictos:
 
 	$ git status
 	# On branch master
@@ -282,7 +282,7 @@ En cualquier momento, puedes lanzar el comando 'git status' para ver si ya has r
 	#	modified:   index.html
 	#
 
-Si todo ha ido correctamente, y ves que todos los archivos conflictivos están marcados como preparados, puedes lanzar el comando 'git commit' para terminar de confirmar la fusión. El mensaje de confirmación por defecto será algo parecido a:
+Si todo ha ido correctamente, y ves que todos los archivos conflictivos están marcados como preparados, puedes lanzar el comando `git commit` para terminar de confirmar la fusión. El mensaje de confirmación por defecto será algo parecido a:
 
 	Merge branch 'iss53'
 
@@ -301,40 +301,40 @@ Puedes modificar este mensaje añadiendo detalles sobre cómo has resuelto la fu
 
 Ahora que ya has creado, fusionado y borrado algunas ramas, vamos a dar un vistazo a algunas herramientas de gestión muy útiles cuando comienzas a utilizar ramas profusamente.
 
-El comando 'git branch' tiene más funciones que las de crear y borrar ramas. Si lo lanzas sin argumentos, obtienes una lista de las ramas presentes en tu proyecto:
+El comando `git branch` tiene más funciones que las de crear y borrar ramas. Si lo lanzas sin argumentos, obtienes una lista de las ramas presentes en tu proyecto:
 
 	$ git branch
 	  iss53
 	* master
 	  testing
 
-Fijate en el carácter `*` delante de la rama 'master': nos indica la rama  activa en este momento. Si hacemos una confirmación de cambios (commit), esa será la rama que avance. Para ver la última confirmación de cambios en cada rama, puedes usar el comando 'git branch -v':
+Fijate en el carácter `*` delante de la rama `master`: nos indica la rama  activa en este momento. Si hacemos una confirmación de cambios (commit), esa será la rama que avance. Para ver la última confirmación de cambios en cada rama, puedes usar el comando `git branch -v`:
 
 	$ git branch -v
 	  iss53   93b412c fix javascript issue
 	* master  7a98805 Merge branch 'iss53'
 	  testing 782fd34 add scott to the author list in the readmes
 
-Otra opción útil para averiguar el estado de las ramas, es filtrarlas y mostrar solo aquellas que han sido fusionadas (o que no lo han sido) con la rama actualmente activa. Para ello, Git dispone, desde la versión 1.5.6, las opciones '--merged' y '--no-merged'. Si deseas ver las ramas que han sido fusionadas en la rama activa, puedes lanzar el comando 'git branch --merged':
+Otra opción útil para averiguar el estado de las ramas, es filtrarlas y mostrar solo aquellas que han sido fusionadas (o que no lo han sido) con la rama actualmente activa. Para ello, Git dispone, desde la versión 1.5.6, las opciones `--merged` y `--no-merged`. Si deseas ver las ramas que han sido fusionadas en la rama activa, puedes lanzar el comando `git branch --merged`:
 
 	$ git branch --merged
 	  iss53
 	* master
 
-Aparece la rama 'iss53' porque ya ha sido fusionada.  Y no lleva por delante el caracter `*` porque todo su contenido ya ha sido incorporado a otras ramas. Podemos borrarla tranquilamente con 'git branch -d', sin miedo a perder nada.
+Aparece la rama `iss53` porque ya ha sido fusionada.  Y no lleva por delante el caracter `*` porque todo su contenido ya ha sido incorporado a otras ramas. Podemos borrarla tranquilamente con `git branch -d`, sin miedo a perder nada.
 
-Para mostrar todas las ramas que contienen trabajos sin fusionar aún, puedes utilizar el comando 'git branch --no-merged':
+Para mostrar todas las ramas que contienen trabajos sin fusionar aún, puedes utilizar el comando `git branch --no-merged`:
 
 	$ git branch --no-merged
 	  testing
 
-Esto nos muestra la otra rama en el proyecto. Debido a que contiene trabajos sin fusionar aún, al intentarla borrar con 'git branch -d', el comando nos dará un error:
+Esto nos muestra la otra rama en el proyecto. Debido a que contiene trabajos sin fusionar aún, al intentarla borrar con `git branch -d`, el comando nos dará un error:
 
 	$ git branch -d testing
 	error: The branch 'testing' is not an ancestor of your current HEAD.
 	If you are sure you want to delete it, run 'git branch -D testing'.
 
-Si realmente deseas borrar la rama, y perder el trabajo contenido en ella, puedes forzar el borrado con la opción '-D'; tal y como lo indica el mensaje de ayuda.
+Si realmente deseas borrar la rama, y perder el trabajo contenido en ella, puedes forzar el borrado con la opción `-D`; tal y como lo indica el mensaje de ayuda.
 
 ## Flujos de trabajo ramificados ##
 
@@ -344,7 +344,7 @@ Ahora que ya has visto los procedimientos básicos de ramificación y fusión, 
 
 Por la sencillez de la fusión a tres bandas de Git, el fusionar de una rama a otra multitud de veces a lo largo del tiempo es facil de hacer. Esto te posibilita tener varias ramas siempre abiertas, e irlas usando en diferentes etapas del ciclo de desarrollo; realizando frecuentes fusiones entre ellas.
 
-Muchos desarrolladores que usan Git llevan un flujo de trabajo de esta naturaleza, manteniendo en la rama 'master' únicamente el código totalmente estable (el código que ha sido o que va a ser liberado). Teniendo otras ramas paralelas denominadas 'desarrollo' o 'siguiente', en las que trabajan y realizan pruebas. Estas ramas paralelas no suele estar siempre en un estado estable; pero cada vez que sí lo están, pueden ser fusionadas con la rama 'master'. También es habitual el incorporarle (pull) ramas puntuales (ramas temporales, como la rama 'iss53' del anterior ejemplo) cuando las completamos y estamos seguros de que no van a introducir errores.
+Muchos desarrolladores que usan Git llevan un flujo de trabajo de esta naturaleza, manteniendo en la rama `master` únicamente el código totalmente estable (el código que ha sido o que va a ser liberado). Teniendo otras ramas paralelas denominadas `desarrollo` o `siguiente`, en las que trabajan y realizan pruebas. Estas ramas paralelas no suele estar siempre en un estado estable; pero cada vez que sí lo están, pueden ser fusionadas con la rama `master`. También es habitual el incorporarle (pull) ramas puntuales (ramas temporales, como la rama `iss53` del anterior ejemplo) cuando las completamos y estamos seguros de que no van a introducir errores.
 
 En realidad, en todo momento estamos hablando simplemente de apuntadores moviendose por la línea temporal de confirmaciones de cambio (commit history). Las ramas estables apuntan hacia posiciones más antiguas en el registro de confirmaciones. Mientras que las ramas avanzadas, las que van abriendo camino, apuntan hacia posiciones más recientes.
 
@@ -356,24 +356,24 @@ Podría ser más sencillo pensar en las ramas como si fueran silos de almacenami
 Insert 18333fig0319.png 
 Figura 3-19. Puede ayudar pensar en las ramas como silos de almacenamiento.
 
-Este sistema de trabajo se puede ampliar para diversos grados de estabilidad. Algunos proyectos muy grandes suelen tener una rama denominada 'propuestas' o 'pu' (proposed updates). Donde suele estar todo aquello integrado desde otras ramas, pero que aún no está listo para ser incorporado a las ramas 'siguiente' o 'master'. La idea es mantener siempre diversas ramas en diversos grados de estabilidad; pero cuando alguna alcanza un estado más estable, la fusionamos con la rama inmediatamente superior a ella.
+Este sistema de trabajo se puede ampliar para diversos grados de estabilidad. Algunos proyectos muy grandes suelen tener una rama denominada `propuestas` o `pu` (proposed updates). Donde suele estar todo aquello integrado desde otras ramas, pero que aún no está listo para ser incorporado a las ramas `siguiente` o `master`. La idea es mantener siempre diversas ramas en diversos grados de estabilidad; pero cuando alguna alcanza un estado más estable, la fusionamos con la rama inmediatamente superior a ella.
 Aunque no es obligatorio el trabajar con ramas de larga duración, realmente es práctico y útil. Sobre todo en proyectos largos o complejos.
 
 ### Ramas puntuales ###
 
 Las ramas puntuales, en cambio, son útiles en proyectos de cualquier tamaño. Una rama puntual es aquella de corta duración que abres para un tema o para una funcionalidad muy concretos. Es algo que nunca habrías hecho en otro sistema VCS, debido a los altos costos de crear y fusionar ramas que se suelen dar en esos sistemas. Pero en Git, por el contrario, es muy habitual el crear, trabajar con, fusionar y borrar ramas varias veces al día.
 
-Tal y como has visto con las ramas 'iss53' y 'hotfix' que has creado en la sección anterior. Has hecho unas pocas confirmaciones de cambio en ellas, y luego las has borrado tras fusionarlas con la rama principal. Esta técnica te posibilita realizar rápidos y completos saltos de contexto. Y, debido a que el trabajo está claramente separado en silos, con todos los cambios de cada tema en su propia rama, te será mucho más sencillo revisar el código y seguir su evolución. Puedes mantener los cambios ahí durante minutos, dias o meses; y fusionarlos cuando realmente estén listos. En lugar de verte obligado a fusionarlos en el orden en que fueron creados y comenzaste a trabajar en ellos.
+Tal y como has visto con las ramas `iss53` y `hotfix` que has creado en la sección anterior. Has hecho unas pocas confirmaciones de cambio en ellas, y luego las has borrado tras fusionarlas con la rama principal. Esta técnica te posibilita realizar rápidos y completos saltos de contexto. Y, debido a que el trabajo está claramente separado en silos, con todos los cambios de cada tema en su propia rama, te será mucho más sencillo revisar el código y seguir su evolución. Puedes mantener los cambios ahí durante minutos, dias o meses; y fusionarlos cuando realmente estén listos. En lugar de verte obligado a fusionarlos en el orden en que fueron creados y comenzaste a trabajar en ellos.
 
-Por ejemplo, puedes realizar cierto trabajo en la rama 'master', ramificar para un problema concreto (rama 'iss91'), trabajar en él un rato, ramificar a una segunda rama para probar otra manera de resolverlo (rama 'iss92v2'), volver a la rama 'master' y trabajar un poco más, y, por último, ramificar temporalmente para probar algo de lo que no estás seguro (rama 'dumbidea'). El registro de confirmaciones (commit history) será algo parecido a la Figura 3-20.
+Por ejemplo, puedes realizar cierto trabajo en la rama `master`, ramificar para un problema concreto (rama `iss91`), trabajar en él un rato, ramificar a una segunda rama para probar otra manera de resolverlo (rama `iss92v2`), volver a la rama `master` y trabajar un poco más, y, por último, ramificar temporalmente para probar algo de lo que no estás seguro (rama `dumbidea`). El registro de confirmaciones (commit history) será algo parecido a la Figura 3-20.
 
 Insert 18333fig0320.png 
 Figura 3-20. El registro de confirmaciones con múltiples ramas puntuales.
 
-En este momento, supongamos que te decides por la segunda solución al problema (rama 'iss92v2'); y que, tras mostrar la rama 'dumbidea' a tus compañeros, resulta que les parece una idea genial. Puedes descartar la rama 'iss91' (perdiendo las confirmaciones C5 y C6), y fusionar las otras dos. El registro será algo parecido a la Figura 3-21.
+En este momento, supongamos que te decides por la segunda solución al problema (rama `iss92v2`); y que, tras mostrar la rama `dumbidea` a tus compañeros, resulta que les parece una idea genial. Puedes descartar la rama `iss91` (perdiendo las confirmaciones C5 y C6), y fusionar las otras dos. El registro será algo parecido a la Figura 3-21.
 
 Insert 18333fig0321.png 
-Figura 3-21. El registro tras fusionar 'dumbidea' e 'iss91v2'.
+Figura 3-21. El registro tras fusionar `dumbidea` e `iss91v2`.
 
 Es importante recordar que, mientras estás haciendo todo esto, todas las ramas son completamente locales. Cuando ramificas y fusionas, todo se realiza en tu propio repositório Git. No hay nigún tipo de tráfico con ningún servidor.
 
@@ -381,38 +381,38 @@ Es importante recordar que, mientras estás haciendo todo esto, todas las ramas
 
 Las ramas remotas son referencias al estado de ramas en tus repositorios remotos. Son ramas locales que no puedes mover;  se mueven automáticamente cuando estableces comunicaciones en la red. Las ramas remotas funcionan como marcadores, para recordarte en qué estado se encontraban tus repositorios remotos la última vez que conectaste con ellos.
 
-Suelen referenciarse como '(remoto)/(rama)'. Por ejemplo, si quieres saber cómo estaba la rama 'master' en el remoto 'origin'. Puedes revisar la rama 'origin/master'. O si estás trabajando en un problema con un compañero y este envia (push) una rama 'iss53', tu tendrás tu propia rama de trabajo local 'iss53'; pero la rama en el servidor apuntará a la última confirmación (commit) en la rama 'origin/iss53'.
+Suelen referenciarse como `(remoto)/(rama)`. Por ejemplo, si quieres saber cómo estaba la rama `master` en el remoto `origin`. Puedes revisar la rama `origin/master`. O si estás trabajando en un problema con un compañero y este envia (push) una rama `iss53`, tu tendrás tu propia rama de trabajo local `iss53`; pero la rama en el servidor apuntará a la última confirmación (commit) en la rama `origin/iss53`.
 
-Esto puede ser un tanto confuso, pero intentemos aclararlo con un ejemplo.  Supongamos que tienes un sevidor Git en tu red, en 'git.ourcompany.com'. Si haces un clón desde ahí, Git automáticamente lo denominará 'origin', traerá (pull) sus datos, creará un apuntador hacia donde esté en ese momento su rama 'master', denominará la copia local 'origin/master'; y será inamovible para tí.  Git te proporcionará también tu propia rama 'master', apuntando al mismo lugar que la rama 'master' de 'origin'; siendo en esta última donde podrás trabajar.
+Esto puede ser un tanto confuso, pero intentemos aclararlo con un ejemplo.  Supongamos que tienes un sevidor Git en tu red, en `git.ourcompany.com`. Si haces un clón desde ahí, Git automáticamente lo denominará `origin`, traerá (pull) sus datos, creará un apuntador hacia donde esté en ese momento su rama `master`, denominará la copia local `origin/master`; y será inamovible para tí.  Git te proporcionará también tu propia rama `master`, apuntando al mismo lugar que la rama `master` de `origin`; siendo en esta última donde podrás trabajar.
 
 Insert 18333fig0322.png 
-Figura 3-22. Un clón Git te proporciona tu propia rama 'master' y otra rama 'origin/master' apuntando a la rama 'master' original.
+Figura 3-22. Un clón Git te proporciona tu propia rama `master` y otra rama `origin/master` apuntando a la rama `master` original.
 
-Si haces algún trabajo en tu rama 'master' local, y al mismo tiempo, alguna otra persona lleva (push) su trabajo al servidor 'git.ourcompany.com', actualizando la rama 'master' de allí, te encontrarás con que ambos registros avanzan de forma diferente. Además, mientras no tengas contacto con el servidor, tu apuntador a tu rama 'origin/master' no se moverá (ver Figura 3/23).
+Si haces algún trabajo en tu rama `master` local, y al mismo tiempo, alguna otra persona lleva (push) su trabajo al servidor `git.ourcompany.com`, actualizando la rama `master` de allí, te encontrarás con que ambos registros avanzan de forma diferente. Además, mientras no tengas contacto con el servidor, tu apuntador a tu rama `origin/master` no se moverá (ver Figura 3/23).
 
 Insert 18333fig0323.png 
 Figura 3-23. Trabajando localmente y que otra persona esté llevando (push) algo al servidor remoto, hace que cada registro avance de forma distinta.
 
-Para sincronizarte, puedes utilizar el comando 'git fetch origin'. Este comando localiza en qué servidor está el origen (en este caso 'git.ourcompany.com'), recupera cualquier dato presente allí que tu no tengas, y actualiza tu base de datos local, moviendo tu rama 'origin/master' para que apunte a esta nueva y más reciente posición (ver Figura 3-24).
+Para sincronizarte, puedes utilizar el comando `git fetch origin`. Este comando localiza en qué servidor está el origen (en este caso `git.ourcompany.com`), recupera cualquier dato presente allí que tu no tengas, y actualiza tu base de datos local, moviendo tu rama `origin/master` para que apunte a esta nueva y más reciente posición (ver Figura 3-24).
 
 Insert 18333fig0324.png 
-Figura 3-24. El comando 'git fetch' actualiza tus referencias remotas.
+Figura 3-24. El comando `git fetch` actualiza tus referencias remotas.
 
-Para ilustrar mejor el caso de tener múltiples servidores y cómo van las ramas remotas para esos proyectos remotos. Supongamos que tienes otro servidor Git; utilizado solamente para desarrollo, por uno de tus equipos sprint. Un servidor en 'git.team1.ourcompany.com'. Puedes incluirlo como una nueva referencia remota a tu proyecto actual, mediante el comando 'git remote add', tal y como vimos en el capítulo 2. Puedes denominar 'teamone' a este remoto, poniendo este nombre abreviado para la URL (ver Figura 3-25)
+Para ilustrar mejor el caso de tener múltiples servidores y cómo van las ramas remotas para esos proyectos remotos. Supongamos que tienes otro servidor Git; utilizado solamente para desarrollo, por uno de tus equipos sprint. Un servidor en `git.team1.ourcompany.com`. Puedes incluirlo como una nueva referencia remota a tu proyecto actual, mediante el comando `git remote add`, tal y como vimos en el capítulo 2. Puedes denominar `teamone` a este remoto, poniendo este nombre abreviado para la URL (ver Figura 3-25)
 
 Insert 18333fig0325.png 
 Figura 3-25. Añadiendo otro servidor como remoto.
 
-Ahora, puedes usar el comando 'git fetch teamone' para recuperar todo el contenido del servidor que tu no tenias. Debido a que dicho servidor es un subconjunto de de los datos del servidor 'origin' que tienes actualmente, Git no recupera (fetch) ningún  dato; simplemente prepara una rama remota llamada 'teamone/master' para apuntar a la confirmación (commit) que 'teamone' tiene en su rama 'master'.
+Ahora, puedes usar el comando `git fetch teamone` para recuperar todo el contenido del servidor que tu no tenias. Debido a que dicho servidor es un subconjunto de de los datos del servidor `origin` que tienes actualmente, Git no recupera (fetch) ningún  dato; simplemente prepara una rama remota llamada `teamone/master` para apuntar a la confirmación (commit) que `teamone` tiene en su rama `master`.
 
 Insert 18333fig0326.png 
-Figura 3-26. Obtienes una referencia local a la posición en la rama 'master' de 'teamone'.
+Figura 3-26. Obtienes una referencia local a la posición en la rama `master` de `teamone`.
 
 ### Publicando ###
 
 Cuando quieres compartir una rama con el resto del mundo, has de llevarla (push) a un remoto donde tengas permisos de escritura. Tus ramas locales no se sincronizan automáticamente con los remotos en los que escribes. Sino que tienes que llevar (push) expresamente, cada vez, al remoto las ramas que desees compartir. De esta forma, puedes usar ramas privadas para el trabajo que no deseas compartir. Llevando a un remoto tan solo aquellas partes que deseas aportar a los demás.
 
-Si tienes una rama llamada 'serverfix', con la que vas a trabajar en colaboración; puedes llevarla al remoto de la misma forma que llevaste tu primera rama. Con el comando 'git push (remoto) (rama)':
+Si tienes una rama llamada `serverfix`, con la que vas a trabajar en colaboración; puedes llevarla al remoto de la misma forma que llevaste tu primera rama. Con el comando `git push (remoto) (rama)`:
 
 	$ git push origin serverfix
 	Counting objects: 20, done.
@@ -422,9 +422,9 @@ Si tienes una rama llamada 'serverfix', con la que vas a trabajar en colaboraci
 	To git@github.com:schacon/simplegit.git
 	 * [new branch]      serverfix -> serverfix
 
-Esto es un poco como un atajo. Git expande automáticamente el nombre de rama 'serverfix' a 'refs/heads/serverfix:refs/heads/serverfix', que significa: "coge mi rama local 'serverfix' y actualiza con ella la rama 'serverfix' del remoto". Volveremos más tarde sobre el tema de 'refs/heads/', viendolo en detalle en el capítulo 9; aunque puedes ignorarlo por ahora. También puedes hacer 'git push origin serverfix:serverfix', que hace lo mismo; es decir: "coge mi 'serverfix' y hazlo el 'serverfix' remoto". Puedes utilizar este último formato para llevar una rama local a una rama remota con otro nombre distinto. Si no quieres que se llame 'serverfix' en el remoto, puedes lanzar, por ejemplo, 'git push origin serverfix:awesomebranch'; para llevar tu rama 'serverfix' local a la rama 'awesomebranch' en el proyecto remoto.
+Esto es un poco como un atajo. Git expande automáticamente el nombre de rama `serverfix` a `refs/heads/serverfix:refs/heads/serverfix`, que significa: "coge mi rama local `serverfix` y actualiza con ella la rama `serverfix` del remoto". Volveremos más tarde sobre el tema de `refs/heads/`, viendolo en detalle en el capítulo 9; aunque puedes ignorarlo por ahora. También puedes hacer `git push origin serverfix:serverfix`, que hace lo mismo; es decir: "coge mi `serverfix` y hazlo el `serverfix` remoto". Puedes utilizar este último formato para llevar una rama local a una rama remota con otro nombre distinto. Si no quieres que se llame `serverfix` en el remoto, puedes lanzar, por ejemplo, `git push origin serverfix:awesomebranch`; para llevar tu rama `serverfix` local a la rama `awesomebranch` en el proyecto remoto.
 
-La próxima vez que tus colaboradores recuperen desde el servidor, obtendrán una referencia a donde la versión de 'serverfix' en el servidor esté bajo la rama remota 'origin/serverfix':
+La próxima vez que tus colaboradores recuperen desde el servidor, obtendrán una referencia a donde la versión de `serverfix` en el servidor esté bajo la rama remota `origin/serverfix`:
 
 	$ git fetch origin
 	remote: Counting objects: 20, done.
@@ -434,21 +434,21 @@ La próxima vez que tus colaboradores recuperen desde el servidor, obtendrán un
 	From git@github.com:schacon/simplegit
 	 * [new branch]      serverfix    -> origin/serverfix
 
-Es importante destacar que cuando recuperas (fetch) nuevas ramas remotas, no obtienes automáticamente una copia editable local de las mismas. En otras palabras, en este caso, no tienes una nueva rama 'serverfix'. Sino que únicamente tienes un puntero no editable a 'origin/serverfix'.
+Es importante destacar que cuando recuperas (fetch) nuevas ramas remotas, no obtienes automáticamente una copia editable local de las mismas. En otras palabras, en este caso, no tienes una nueva rama `serverfix`. Sino que únicamente tienes un puntero no editable a `origin/serverfix`.
 
-Para integrar (merge) esto en tu actual rama de trabajo, puedes usar el comando 'git merge origin/serverfix'. Y si quieres tener tu propia rama 'serverfix', donde puedas trabajar, puedes crearla directamente basandote en rama remota:
+Para integrar (merge) esto en tu actual rama de trabajo, puedes usar el comando `git merge origin/serverfix`. Y si quieres tener tu propia rama `serverfix`, donde puedas trabajar, puedes crearla directamente basandote en rama remota:
 
 	$ git checkout -b serverfix origin/serverfix
 	Branch serverfix set up to track remote branch refs/remotes/origin/serverfix.
 	Switched to a new branch "serverfix"Switched to a new branch "serverfix"
 
-Esto sí te da una rama local donde puedes trabajar, comenzando donde 'origin/serverfix' estaba en ese momento.
+Esto sí te da una rama local donde puedes trabajar, comenzando donde `origin/serverfix` estaba en ese momento.
 
 ### Haciendo seguimiento a las ramas ###
 
-Activando (checkout) una rama local a partir de una rama remota, se crea automáticamente lo que podríamos denominar "una rama de seguimiento" (tracking branch). Las ramas de seguimiento son ramas locales que tienen una relación directa con alguna rama remota. Si estás en una rama de seguimiento y tecleas el comando 'git push', Git sabe automáticamente a qué servidor y a qué rama ha de llevar los contenidos. Igualmente, tecleando 'git pull' mientras estamos en una de esas ramas, recupera (fetch) todas las referencias remotas y las consolida (merge) automáticamente en la correspondiente rama remota.
+Activando (checkout) una rama local a partir de una rama remota, se crea automáticamente lo que podríamos denominar "una rama de seguimiento" (tracking branch). Las ramas de seguimiento son ramas locales que tienen una relación directa con alguna rama remota. Si estás en una rama de seguimiento y tecleas el comando `git push`, Git sabe automáticamente a qué servidor y a qué rama ha de llevar los contenidos. Igualmente, tecleando `git pull` mientras estamos en una de esas ramas, recupera (fetch) todas las referencias remotas y las consolida (merge) automáticamente en la correspondiente rama remota.
 
-Cuando clonas un repositorio, este suele crear automáticamente una rama 'master' que hace seguimiento de 'origin/master'. Y es por eso que 'git push' y 'git pull' trabajan directamente, sin necesidad de más argumentos. Sin embargo, puedes preparar otras ramas de seguimiento si deseas tener unas que no hagan seguimiento de ramas en 'origin' y que no sigan a la rama 'master'. El ejemplo más simple, es el que acabas de ver al lanzar el comando 'git checkout -b [rama] [nombreremoto]/[rama]'. Si tienes la versión 1.6.2 de Git, o superior, puedes utilizar también el parámetro '--track':
+Cuando clonas un repositorio, este suele crear automáticamente una rama `master` que hace seguimiento de `origin/master`. Y es por eso que `git push` y `git pull` trabajan directamente, sin necesidad de más argumentos. Sin embargo, puedes preparar otras ramas de seguimiento si deseas tener unas que no hagan seguimiento de ramas en `origin` y que no sigan a la rama `master`. El ejemplo más simple, es el que acabas de ver al lanzar el comando `git checkout -b [rama] [nombreremoto]/[rama]`. Si tienes la versión 1.6.2 de Git, o superior, puedes utilizar también el parámetro `--track`:
 
 	$ git checkout --track origin/serverfix
 	Branch serverfix set up to track remote branch refs/remotes/origin/serverfix.
@@ -460,17 +460,17 @@ Para preparar una rama local con un nombre distinto a la del remoto, puedes util
 	Branch sf set up to track remote branch refs/remotes/origin/serverfix.
 	Switched to a new branch "sf"
 
-Así, tu rama local 'sf' va a llevar (push) y traer (pull) hacia o desde 'origin/serverfix'.
+Así, tu rama local `sf` va a llevar (push) y traer (pull) hacia o desde `origin/serverfix`.
 
 ### Borrando ramas remotas ###
 
-Imagina que ya has terminado con una rama remota. Es decir, tanto tu como tus colaboradores habeis completado una determinada funcionalidad y la habeis incorporado (merge) a la rama 'master' en el remoto (o donde quiera que tengais la rama de código estable). Puedes borrar la rama remota utilizando la un tanto confusa sintaxis:  'git push [nombreremoto] :[rama]'. Por ejemplo, si quieres borrar la rama 'serverfix' del servidor, puedes utilizar:
+Imagina que ya has terminado con una rama remota. Es decir, tanto tu como tus colaboradores habeis completado una determinada funcionalidad y la habeis incorporado (merge) a la rama `master` en el remoto (o donde quiera que tengais la rama de código estable). Puedes borrar la rama remota utilizando la un tanto confusa sintaxis:  `git push [nombreremoto] :[rama]`. Por ejemplo, si quieres borrar la rama `serverfix` del servidor, puedes utilizar:
 
 	$ git push origin :serverfix
 	To git@github.com:schacon/simplegit.git
 	 - [deleted]         serverfix
 
-Y....Boom!. La rama en el servidor ha desaparecido. Puedes grabarte a fuego esta página, porque necesitarás ese comando y, lo más probable es que hayas olvidado su sintaxis. Una manera de recordar este comando es dándonos cuenta de que proviene de la sintaxis 'git push [nombreremoto] [ramalocal]:[ramaremota]'. Si omites la parte '[ramalocal]', lo que estás diciendo es: "no cojas nada de mi lado y haz con ello [ramaremota]".
+Y....Boom!. La rama en el servidor ha desaparecido. Puedes grabarte a fuego esta página, porque necesitarás ese comando y, lo más probable es que hayas olvidado su sintaxis. Una manera de recordar este comando es dándonos cuenta de que proviene de la sintaxis `git push [nombreremoto] [ramalocal]:[ramaremota]`. Si omites la parte `[ramalocal]`, lo que estás diciendo es: "no cojas nada de mi lado y haz con ello [ramaremota]".
 
 ## Reorganizando el trabajo realizado ##
 
@@ -483,12 +483,12 @@ Volviendo al ejemplo anterior, en la sección sobre fusiones (ver Figura 3-27),
 Insert 18333fig0327.png 
 Figura 3-27. El registro de confirmaciones inicial.
 
-La manera más sencilla de integrar ramas, tal y como hemos visto, es el comando 'git merge'. Realiza una fusión a tres bandas entre las dos últimas instantáneas de cada rama (C3 y C4) y el ancestro común a ambas (C2); creando una nueva instantánea (snapshot)  y la correspondiente confirmación (commit), según se muestra en la Figura 3-28.
+La manera más sencilla de integrar ramas, tal y como hemos visto, es el comando `git merge`. Realiza una fusión a tres bandas entre las dos últimas instantáneas de cada rama (C3 y C4) y el ancestro común a ambas (C2); creando una nueva instantánea (snapshot)  y la correspondiente confirmación (commit), según se muestra en la Figura 3-28.
 
 Insert 18333fig0328.png 
 Figura 3-28. Fusionando una rama para integrar el registro de trabajos divergentes.
 
-Aunque también hay otra forma de hacerlo: puedes coger los cambios introducidos en C3 y reaplicarlos encima de C4. Esto es lo que en Git llamamos _reorganizar_. Con el comando 'git rebase', puedes coger todos los cambios confirmados en una rama, y reaplicarlos sobre otra.
+Aunque también hay otra forma de hacerlo: puedes coger los cambios introducidos en C3 y reaplicarlos encima de C4. Esto es lo que en Git llamamos _reorganizar_. Con el comando `git rebase`, puedes coger todos los cambios confirmados en una rama, y reaplicarlos sobre otra.
 
 Por ejemplo, puedes lanzar los comandos:
 
@@ -502,29 +502,29 @@ Haciendo que Git: vaya al ancestro común de ambas ramas (donde estás actualmen
 Insert 18333fig0329.png 
 Figura 3-29. Reorganizando sobre C4 los cambios introducidos en C3.
 
-En este momento, puedes volver a la rama 'master' y hacer una fusión con avance rápido (fast-forward merge). (ver Figura 3-30)
+En este momento, puedes volver a la rama `master` y hacer una fusión con avance rápido (fast-forward merge). (ver Figura 3-30)
 
 Insert 18333fig0330.png 
-Figura 3-30. Avance rápido de la rama 'master'.
+Figura 3-30. Avance rápido de la rama `master`.
 
 Así, la instantánea apuntada por C3' aquí es exactamente la misma apuntada por C5 en el ejemplo de la fusión. No hay ninguna diferencia en el resultado final de la integración, pero el haberla hecho reorganizando nos deja un registro más claro. Si examinas el registro de una rama reorganizada, este aparece siempre como un registro lineal: como si todo el trabajo se hubiera realizado en series, aunque realmente se haya hecho en paralelo.
 
-Habitualmente, optarás por esta vía cuando quieras estar seguro de que tus confirmaciones de cambio (commits) se pueden aplicar limpiamente sobre una rama remota; posiblemente, en un proyecto donde estés intentando colaborar, pero lleves tu el mantenimiento. En casos como esos, puedes trabajar sobre una rama y luego reorgainzar lo realizado en la rama 'origin/master' cuando lo tengas todo listo para enviarlo al proyecto principal. De esta forma, la persona que mantiene el proyecto no necesitará hacer ninguna integración con tu trabajo; le bastará con un avance rápido o una incorporación limpia.
+Habitualmente, optarás por esta vía cuando quieras estar seguro de que tus confirmaciones de cambio (commits) se pueden aplicar limpiamente sobre una rama remota; posiblemente, en un proyecto donde estés intentando colaborar, pero lleves tu el mantenimiento. En casos como esos, puedes trabajar sobre una rama y luego reorgainzar lo realizado en la rama `origin/master` cuando lo tengas todo listo para enviarlo al proyecto principal. De esta forma, la persona que mantiene el proyecto no necesitará hacer ninguna integración con tu trabajo; le bastará con un avance rápido o una incorporación limpia.
 
 Cabe destacar que la instantánea (snapshot) apuntada por la confirmación (commit) final, tanto si es producto de una regorganización (rebase) como si lo es de una fusión (merge), es exactamente la misma instantánea. Lo único diferente es el registro. La reorganización vuelve a aplicar cambios de una rama de trabajo sobre otra rama, en el mismo orden en que fueron introducidos en la primera. Mientras que la fusión combina entre sí los dos puntos finales de ambas ramas.
 
 ### Algunas otras reorganizaciones interesantes ###
 
-También puedes aplicar una reorganización (rebase) sobre otra cosa además de sobre la rama de reorganización. Por ejemplo, sea un registro como el de la Figura 3-31. Has ramificado a una rama puntual ('server') para añadir algunas funcionalidades al proyecto, y luego has confirmado los cambios. Despues, vuelves a la rama original para hacer algunos cambios en la parte cliente (rama 'client'), y confirmas también esos cambios. Por último, vuelves sobre la rama 'server' y haces algunos cambios más.
+También puedes aplicar una reorganización (rebase) sobre otra cosa además de sobre la rama de reorganización. Por ejemplo, sea un registro como el de la Figura 3-31. Has ramificado a una rama puntual (`server`) para añadir algunas funcionalidades al proyecto, y luego has confirmado los cambios. Despues, vuelves a la rama original para hacer algunos cambios en la parte cliente (rama `client`), y confirmas también esos cambios. Por último, vuelves sobre la rama `server` y haces algunos cambios más.
 
 Insert 18333fig0331.png 
 Figura 3-31. Un registro con una rama puntual sobre otra rama puntual.
 
-Imagina que decides incorporar tus cambios de la parte cliente sobre el proyecto principal, para hacer un lanzamiento de versión; pero no quieres lanzar aún los cambios de la parte server porque no están aún suficientemente probados. Puedes coger los cambios del cliente que no estan en server (C8 y C9), y reaplicarlos sobre tu rama principal usando la opción '--onto' del comando 'git rebase':
+Imagina que decides incorporar tus cambios de la parte cliente sobre el proyecto principal, para hacer un lanzamiento de versión; pero no quieres lanzar aún los cambios de la parte server porque no están aún suficientemente probados. Puedes coger los cambios del cliente que no estan en server (C8 y C9), y reaplicarlos sobre tu rama principal usando la opción `--onto` del comando `git rebase`:
 
 	$ git rebase --onto master server client
 
-Esto viene a decir: "Activa la rama 'client', averigua los cambios desde el ancestro común entre las ramas 'client' y 'server', y aplicalos en la rama 'master'. Puede parecer un poco complicado, pero los resultados, mostrados en la Figura 3-32, son realmente interesantes.
+Esto viene a decir: "Activa la rama `client`, averigua los cambios desde el ancestro común entre las ramas `client` y `server`, y aplicalos en la rama `master`. Puede parecer un poco complicado, pero los resultados, mostrados en la Figura 3-32, son realmente interesantes.
 
 Insert 18333fig0332.png 
 Figura 3-32. Reorganizando una rama puntual fuera de otra rama puntual.
@@ -535,23 +535,23 @@ Y, tras esto, ya puedes avanzar la rama principal (ver Figura 3-33):
 	$ git merge client
 
 Insert 18333fig0333.png 
-Figura 3-33. Avance rápido de tu rama 'master', para incluir los cambios de la rama 'client'.
+Figura 3-33. Avance rápido de tu rama `master`, para incluir los cambios de la rama `client`.
 
-Ahora supongamos que decides traerlos (pull) también sobre tu rama 'server'. Puedes reorganizar (rebase) la rama 'server' sobre la rama 'master' sin necesidad siquiera de comprobarlo previamente, usando el comando 'git rebase [ramabase] [ramapuntual]'. El cual activa la rama puntual ('server' en este caso) y la aplica sobre la rama base ('master' en este caso):
+Ahora supongamos que decides traerlos (pull) también sobre tu rama `server`. Puedes reorganizar (rebase) la rama `server` sobre la rama `master` sin necesidad siquiera de comprobarlo previamente, usando el comando `git rebase [ramabase] [ramapuntual]`. El cual activa la rama puntual (`server` en este caso) y la aplica sobre la rama base (`master` en este caso):
 
 	$ git rebase master server
 
-Esto vuelca el trabajo de 'server' sobre el de 'master', tal y como se muestra en la Figura 3-34.
+Esto vuelca el trabajo de `server` sobre el de `master`, tal y como se muestra en la Figura 3-34.
 
 Insert 18333fig0334.png 
-Figura 3-34. Reorganizando la rama 'server' sobre la rama 'branch'.
+Figura 3-34. Reorganizando la rama `server` sobre la rama `branch`.
 
-Después, puedes avanzar rápidamente la rama base ('master'):
+Después, puedes avanzar rápidamente la rama base (`master`):
 
 	$ git checkout master
 	$ git merge server
 
-Y por último puedes eliminar las ramas 'client' y 'server' porque ya todo su contenido ha sido integrado y no las vas a necesitar más. Dejando tu registro tras todo este proceso tal y como se muestra en la Figura 3-35:
+Y por último puedes eliminar las ramas `client` y `server` porque ya todo su contenido ha sido integrado y no las vas a necesitar más. Dejando tu registro tras todo este proceso tal y como se muestra en la Figura 3-35:
 
 	$ git branch -d client
 	$ git branch -d server
@@ -567,7 +567,7 @@ Ahh...., pero la dicha de la reorganización no la alcanzamos sin sus contrapart
 
 Siguiendo esta recomendación, no tendrás problemas. Pero si no la sigues, la gente te odiará y serás despreciado por tus familiares y amigos.
 
-Cuando reorganizas algo, estás abandonando las confirmaciones de cambio ya creadas y estás creando unas nuevas; que son similares, pero diferentes. Si envias (push) confirmaciones (commits) a alguna parte, y otros las recogen (pull) de allí. Y después vas tu y las reescribes con 'git rebase' y las vuelves a enviar (push) de nuevo. Tus colaboradores tendrán que refusionar (re-merge) su trabajo  y todo se volverá tremendamente complicado cuando intentes recoger (pull) su trabajo de vuelta sobre el tuyo.
+Cuando reorganizas algo, estás abandonando las confirmaciones de cambio ya creadas y estás creando unas nuevas; que son similares, pero diferentes. Si envias (push) confirmaciones (commits) a alguna parte, y otros las recogen (pull) de allí. Y después vas tu y las reescribes con `git rebase` y las vuelves a enviar (push) de nuevo. Tus colaboradores tendrán que refusionar (re-merge) su trabajo  y todo se volverá tremendamente complicado cuando intentes recoger (pull) su trabajo de vuelta sobre el tuyo.
 
 Vamos a verlo con un ejemplo. Imaginate que haces un clon desde un servidor central, y luego trabajas sobre él. Tu registro de cambios puede ser algo como lo de la Figura 3-36.
 
@@ -579,7 +579,7 @@ Ahora, otra persona trabaja también sobre ello, realiza una fusión (merge) y l
 Insert 18333fig0337.png 
 Figura 3-37. Traer (fetch) algunas confirmaciones de cambio (commits) y fusionarlas (merge) sobre tu trabajo.
 
-A continuación, la persona que habia llevado cambios al servidor central decide retroceder y reorganizar su trabajo; haciendo un 'git push --force' para sobreescribir el registro en el servidor. Tu te traes (fetch) esos nuevos cambios desde el servidor.
+A continuación, la persona que habia llevado cambios al servidor central decide retroceder y reorganizar su trabajo; haciendo un `git push --force` para sobreescribir el registro en el servidor. Tu te traes (fetch) esos nuevos cambios desde el servidor.
 
 Insert 18333fig0338.png 
 Figura 3-38. Alguien envia (push) confirmaciones (commits) reorganizadas, abandonando las confirmaciones en las que tu habias basado tu trabajo.
@@ -589,7 +589,7 @@ En ese momento, tu te ves obligado a fusionar (merge) tu trabajo de nuevo, aunqu
 Insert 18333fig0339.png 
 Figura 3-39. Vuelves a fusionar el mismo trabajo en una nueva fusión confirmada.
 
-Te ves obligado a fusionar (merge) ese trabajo en algún punto, para poder seguir adelante con otros desarrollos en el futuro. Tras todo esto, tu registro de confirmaciones de cambio (commit history) contendrá tanto la confirmación C4 como la C4'; teniendo ambas el mismo contenido y el mismo mensaje de confirmación. Si lanzas un 'git log' en un registro como este, verás dos confirmaciones  con el mismo autor, misma fecha y mismo mensaje. Lo que puede llevar a confusiones. Es más, si luego tu envias (push) ese registro de vuelta al servidor, vas a introducir todas esas confirmaciones reorganizadas en el servidor central. Lo que puede confundir aún más a la gente.
+Te ves obligado a fusionar (merge) ese trabajo en algún punto, para poder seguir adelante con otros desarrollos en el futuro. Tras todo esto, tu registro de confirmaciones de cambio (commit history) contendrá tanto la confirmación C4 como la C4'; teniendo ambas el mismo contenido y el mismo mensaje de confirmación. Si lanzas un `git log` en un registro como este, verás dos confirmaciones  con el mismo autor, misma fecha y mismo mensaje. Lo que puede llevar a confusiones. Es más, si luego tu envias (push) ese registro de vuelta al servidor, vas a introducir todas esas confirmaciones reorganizadas en el servidor central. Lo que puede confundir aún más a la gente.
 
 Si solo usas la reorganización como una vía para hacer limpieza y organizar confirmaciones de cambio antes de enviarlas, y si únicamente reorganizas confirmaciones que nunca han sido públicas. Entonces no tendrás problemas. Si, por el contrario, reorganizas confirmaciones que alguna vez han sido públicas y otra gente ha basado su trabajo  en ellas. Entonces estarás en un aprieto.
 

From b6a2407be6f5f665198ff030481c34573ada5b4d Mon Sep 17 00:00:00 2001
From: Carlos Arturo Guerra Parra <carlosarturoguerra@gmail.com>
Date: Sun, 18 May 2014 02:15:33 +0200
Subject: [PATCH 431/690] [es] Update chapter 3: fixed some mistakes

* Suspension points had 4 or 5 points instead of 3.
* Closing exclamation mark not opened.
---
 es/03-git-branching/01-chapter3.markdown | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/es/03-git-branching/01-chapter3.markdown b/es/03-git-branching/01-chapter3.markdown
index 9a732fa23..2977cb2ab 100644
--- a/es/03-git-branching/01-chapter3.markdown
+++ b/es/03-git-branching/01-chapter3.markdown
@@ -32,7 +32,7 @@ Una rama Git es simplemente un apuntador móvil apuntando a una de esas confirma
 Insert 18333fig0303.png 
 Figura 3-3. Apuntadores en el registro de confirmaciones de una rama.
 
-¿Qué sucede cuando creas una nueva rama? Bueno....., simplemente se crea un nuevo apuntador para que lo puedas mover libremente. Por ejemplo, si quieres crear una nueva rama denominada "testing". Usarás el comando `git branch`:
+¿Qué sucede cuando creas una nueva rama? Bueno..., simplemente se crea un nuevo apuntador para que lo puedas mover libremente. Por ejemplo, si quieres crear una nueva rama denominada "testing". Usarás el comando `git branch`:
 
 	$ git branch testing
 
@@ -41,7 +41,7 @@ Esto creará un nuevo apuntador apuntando a la misma confirmación donde estés
 Insert 18333fig0304.png 
 Figura 3-4. Apuntadores de varias ramas en el registro de confirmaciones de cambio.
 
-Y, ¿cómo sabe Git en qué rama estás en este momento? Pues...., mediante un apuntador especial denominado HEAD. Aunque es preciso comentar que este HEAD es totalmente distinto al concepto de HEAD en otros sistemas de control de cambios como Subversion o CVS. En Git, es simplemente el apuntador a la rama local en la que tú estés en ese momento. En este caso, en la rama `master`. Puesto que el comando git branch solamente crea una nueva rama, y no salta a dicha rama.
+Y, ¿cómo sabe Git en qué rama estás en este momento? Pues..., mediante un apuntador especial denominado HEAD. Aunque es preciso comentar que este HEAD es totalmente distinto al concepto de HEAD en otros sistemas de control de cambios como Subversion o CVS. En Git, es simplemente el apuntador a la rama local en la que tú estés en ese momento. En este caso, en la rama `master`. Puesto que el comando git branch solamente crea una nueva rama, y no salta a dicha rama.
 
 Insert 18333fig0305.png 
 Figura 3-5. Apuntador HEAD a la rama donde estás actualmente.
@@ -55,7 +55,7 @@ Esto mueve el apuntador HEAD a la rama `testing` (ver Figura 3-6).
 Insert 18333fig0306.png
 Figura 3-6. Apuntador HEAD apuntando a otra rama cuando saltamos de rama.
 
-¿Cuál es el significado de todo esto?. Bueno.... lo veremos tras realizar otra confirmación de cambios:
+¿Cuál es el significado de todo esto?. Bueno... lo veremos tras realizar otra confirmación de cambios:
 
 	$ vim test.rb
 	$ git commit -a -m 'made a change'
@@ -470,7 +470,7 @@ Imagina que ya has terminado con una rama remota. Es decir, tanto tu como tus co
 	To git@github.com:schacon/simplegit.git
 	 - [deleted]         serverfix
 
-Y....Boom!. La rama en el servidor ha desaparecido. Puedes grabarte a fuego esta página, porque necesitarás ese comando y, lo más probable es que hayas olvidado su sintaxis. Una manera de recordar este comando es dándonos cuenta de que proviene de la sintaxis `git push [nombreremoto] [ramalocal]:[ramaremota]`. Si omites la parte `[ramalocal]`, lo que estás diciendo es: "no cojas nada de mi lado y haz con ello [ramaremota]".
+Y... ¡Boom!. La rama en el servidor ha desaparecido. Puedes grabarte a fuego esta página, porque necesitarás ese comando y, lo más probable es que hayas olvidado su sintaxis. Una manera de recordar este comando es dándonos cuenta de que proviene de la sintaxis `git push [nombreremoto] [ramalocal]:[ramaremota]`. Si omites la parte `[ramalocal]`, lo que estás diciendo es: "no cojas nada de mi lado y haz con ello [ramaremota]".
 
 ## Reorganizando el trabajo realizado ##
 
@@ -561,7 +561,7 @@ Figura 3-35. Registro final de confirmaciones de cambio.
 
 ### Los peligros de la reorganización ###
 
-Ahh...., pero la dicha de la reorganización no la alcanzamos sin sus contrapartidas: 
+Ahh..., pero la dicha de la reorganización no la alcanzamos sin sus contrapartidas: 
 
 **Nunca reorganices confirmaciones de cambio (commits) que hayas enviado (push) a un repositorio público.**
 

From 6652b8578e0baaa634e5cf7af3318a908df0bab2 Mon Sep 17 00:00:00 2001
From: Carlos Arturo Guerra Parra <carlosarturoguerra@gmail.com>
Date: Sun, 18 May 2014 23:16:28 +0200
Subject: [PATCH 432/690] [es] Fixed some orthography mistakes

---
 es/03-git-branching/01-chapter3.markdown | 58 ++++++++++++------------
 1 file changed, 29 insertions(+), 29 deletions(-)

diff --git a/es/03-git-branching/01-chapter3.markdown b/es/03-git-branching/01-chapter3.markdown
index 2977cb2ab..44f715729 100644
--- a/es/03-git-branching/01-chapter3.markdown
+++ b/es/03-git-branching/01-chapter3.markdown
@@ -74,7 +74,7 @@ La Figura 3-8 muestra el resultado.
 Insert 18333fig0308.png 
 Figura 3-8. HEAD apunta a otra rama cuando hacemos un checkout.
 
-Este comando realiza dos acciones: Mueve el apuntador HEAD de nuevo a la rama `master`, y revierte los archivos de tu directorio de trabajo; dejandolos tal y como estaban en la última instantánea confirmada en dicha rama `master`. Esto supone que los cambios que hagas desde este momento en adelante divergerán de la antigua versión del proyecto. Básicamente, lo que se está haciendo es rebobinar el trabajo que habias hecho temporalmente en la rama `testing`; de tal forma que puedas avanzar en otra dirección diferente.
+Este comando realiza dos acciones: Mueve el apuntador HEAD de nuevo a la rama `master`, y revierte los archivos de tu directorio de trabajo; dejándolos tal y como estaban en la última instantánea confirmada en dicha rama `master`. Esto supone que los cambios que hagas desde este momento en adelante divergirán de la antigua versión del proyecto. Básicamente, lo que se está haciendo es rebobinar el trabajo que habías hecho temporalmente en la rama `testing`; de tal forma que puedas avanzar en otra dirección diferente.
 
 Haz algunos cambios más y confirmalos:
 
@@ -88,7 +88,7 @@ Figura 3-9. Los registros de las ramas divergen.
 
 Debido a que una rama Git es realmente un simple archivo que contiene los 40 caracteres de una suma de control SHA-1, (representando la confirmación de cambios a la que apunta), no cuesta nada el crear y destruir ramas en Git. Crear una nueva rama es tan rápido y simple como escribir 41 bytes en un archivo, (40 caracteres y un retorno de carro).
 
-Esto contrasta fuertemente con los métodos de ramificación usados por otros sistemas de control de versiones. En los que crear una nueva rama supone el copiar todos los archivos del proyecto a una nueva carpeta adiccional. Lo que puede llevar segundos o incluso minutos, dependiendo del tamaño del proyecto. Mientras que en Git el proceso es siempre instantáneo. Y, además, debido a que se almacenan tambien los nodos padre para cada confirmación, el encontrar las bases adecuadas para realizar una fusión entre ramas es un proceso automático y generalmente sencillo de realizar. Animando así a los desarrolladores a utilizar ramificaciones frecuentemente.
+Esto contrasta fuertemente con los métodos de ramificación usados por otros sistemas de control de versiones. En los que crear una nueva rama supone el copiar todos los archivos del proyecto a una nueva carpeta adicional. Lo que puede llevar segundos o incluso minutos, dependiendo del tamaño del proyecto. Mientras que en Git el proceso es siempre instantáneo. Y, además, debido a que se almacenan también los nodos padre para cada confirmación, el encontrar las bases adecuadas para realizar una fusión entre ramas es un proceso automático y generalmente sencillo de realizar. Animando así a los desarrolladores a utilizar ramificaciones frecuentemente.
 
 Y vamos a ver el por qué merece la pena hacerlo así.
 
@@ -100,11 +100,11 @@ Vamos a presentar un ejemplo simple de ramificar y de fusionar, con un flujo de
 2. Creas una rama para un nuevo tema sobre el que quieres trabajar.
 3. Realizas algo de trabajo en esa rama.
 
-En este momento, recibes una llamada avisandote de un problema crítico que has de resolver. Y sigues los siguientes pasos:
+En este momento, recibes una llamada avisándote de un problema crítico que has de resolver. Y sigues los siguientes pasos:
 
 1. Vuelves a la rama de producción original.
 2. Creas una nueva rama para el problema crítico y lo resuelves trabajando en ella.
-3. Tras las pertinentes pruebas, fusionas (merge) esa rama y la envias (push) a la rama de producción.
+3. Tras las pertinentes pruebas, fusionas (merge) esa rama y la envías (push) a la rama de producción.
 4. Vuelves a la rama del tema en que andabas antes de la llamada y continuas tu trabajo.
 
 ### Procedimientos básicos de ramificación ###
@@ -114,7 +114,7 @@ Imagina que estas trabajando en un proyecto, y tienes un par de confirmaciones (
 Insert 18333fig0310.png 
 Figura 3-10. Un registro de confirmaciones simple y corto.
 
-Decides trabajar el problema #53, del sistema que tu compañia utiliza para llevar seguimiento de los problemas. Aunque, por supuesto, Git no está ligado a ningún sistema de seguimiento de problemas concreto. Como el problema #53 es un tema concreto y puntual en el que vas a trabajar, creas una nueva rama para él. Para crear una nueva rama y saltar a ella, en un solo paso, puedes utilizar el comando `git checkout` con la opción `-b`:
+Decides trabajar el problema #53, del sistema que tu compañía utiliza para llevar seguimiento de los problemas. Aunque, por supuesto, Git no está ligado a ningún sistema de seguimiento de problemas concreto. Como el problema #53 es un tema concreto y puntual en el que vas a trabajar, creas una nueva rama para él. Para crear una nueva rama y saltar a ella, en un solo paso, puedes utilizar el comando `git checkout` con la opción `-b`:
 
 	$ git checkout -b iss53
 	Switched to a new branch "iss53"
@@ -137,7 +137,7 @@ Trabajas en el sitio web y haces algunas confirmaciones de cambios (commits). Co
 Insert 18333fig0312.png 
 Figura 3-12. La rama `iss53` ha avanzado con tu trabajo.
 
-Entonces, recibes una llamada avisandote de otro problema urgente en el sitio web. Problema que has de resolver inmediatamente. Usando Git, no necesitas mezclar el nuevo problema con los cambios que ya habias realizado sobre el problema #53; ni tampoco perder tiempo revirtiendo esos cambios para poder trabajar sobre el contenido que está en producción. Basta con saltar de nuevo a la rama `master` y continuar trabajando a partir de ella.
+Entonces, recibes una llamada avisándote de otro problema urgente en el sitio web. Problema que has de resolver inmediatamente. Usando Git, no necesitas mezclar el nuevo problema con los cambios que ya habías realizado sobre el problema #53; ni tampoco perder tiempo revirtiendo esos cambios para poder trabajar sobre el contenido que está en producción. Basta con saltar de nuevo a la rama `master` y continuar trabajando a partir de ella.
 
 Pero, antes de poder hacer eso, hemos de tener en cuenta  que teniendo cambios aún no confirmados en la carpeta de trabajo o en el área de preparación, Git no nos permitirá saltar a otra rama con la que podríamos tener conflictos.  Lo mejor es tener siempre un estado de trabajo limpio y despejado antes de saltar entre ramas. Y, para ello, tenemos algunos procedimientos (stash y commit ammend), que vamos a ver más adelante. Por ahora, como tenemos confirmados todos los cambios, podemos saltar a la rama `master` sin problemas:
 
@@ -167,19 +167,19 @@ Puedes realizar las pruebas oportunas, asegurarte que la solución es correcta,
 	 README |    1 -
 	 1 files changed, 0 insertions(+), 1 deletions(-)
 
-Merece destacar la frase "Avance rápido" ("Fast forward") que aparece en la respuesta al comando. Git ha movido el apuntador hacia adelante, ya que la confirmación apuntada en la rama donde has fusionado estaba directamente "aguas arriba" respecto de la confirmación actual. Dicho de otro modo: cuando intentas fusionar una confirmación con otra confirmación accesible siguiendo directamente el registro de la primera; Git simplifica las cosas avanzando el puntero, ya que no hay ningûn otro trabajo divergente a fusionar. Esto es lo que se denomina "avance rápido" ("fast forward").
+Merece destacar la frase "Avance rápido" ("Fast forward") que aparece en la respuesta al comando. Git ha movido el apuntador hacia adelante, ya que la confirmación apuntada en la rama donde has fusionado estaba directamente "aguas arriba" respecto de la confirmación actual. Dicho de otro modo: cuando intentas fusionar una confirmación con otra confirmación accesible siguiendo directamente el registro de la primera; Git simplifica las cosas avanzando el puntero, ya que no hay ningún otro trabajo divergente a fusionar. Esto es lo que se denomina "avance rápido" ("fast forward").
 
 Ahora, los cambios realizados están ya en la instantánea (snapshot) de la confirmación (commit) apuntada por la rama `master`. Y puedes desplegarlos (ver Figura 3-14)
 
 Insert 18333fig0314.png 
 Figura 3-14. Tras la fusión (merge), la rama `master` apunta al mismo sitio que la rama `hotfix`.
 
-Tras haber resuelto el problema urgente que te habia interrumpido tu trabajo, puedes volver a donde estabas. Pero antes, es interesante borrar la rama `hotfix`. Ya que no la vamos a necesitar más, puesto que apunta exactamente al mismo sitio que la rama `master`. Esto lo puedes hacer con la opción `-d` del comando `git branch`:
+Tras haber resuelto el problema urgente que te habií interrumpido tu trabajo, puedes volver a donde estabas. Pero antes, es interesante borrar la rama `hotfix`. Ya que no la vamos a necesitar más, puesto que apunta exactamente al mismo sitio que la rama `master`. Esto lo puedes hacer con la opción `-d` del comando `git branch`:
 
 	$ git branch -d hotfix
 	Deleted branch hotfix (3a0874c).
 
-Y, con esto, ya estas dispuesto para regresar al trabajo sobre el problema #53 (ver Figura 3-15):
+Y, con esto, ya estás dispuesto para regresar al trabajo sobre el problema #53 (ver Figura 3-15):
 
 	$ git checkout iss53
 	Switched to branch "iss53"
@@ -203,14 +203,14 @@ Supongamos que tu trabajo con el problema #53 está ya completo y listo para fus
 	 README |    1 +
 	 1 files changed, 1 insertions(+), 0 deletions(-)
 
-Es algo diferente de la fusión realizada anteriormente con `hotfix`. En este caso, el registro de desarrollo habia divergido en un punto anterior. Debido a que la confirmación en la rama actual no es ancestro directo de la rama que pretendes fusionar, Git tiene cierto trabajo extra que hacer. Git realizará una fusión a tres bandas, utilizando las dos instantáneas apuntadas por el extremo de cada una de las ramas y por el ancestro común a ambas dos. La figura 3-16 ilustra las tres instantáneas que Git utiliza para realizar la fusión en este caso.
+Es algo diferente de la fusión realizada anteriormente con `hotfix`. En este caso, el registro de desarrollo había divergido en un punto anterior. Debido a que la confirmación en la rama actual no es ancestro directo de la rama que pretendes fusionar, Git tiene cierto trabajo extra que hacer. Git realizará una fusión a tres bandas, utilizando las dos instantáneas apuntadas por el extremo de cada una de las ramas y por el ancestro común a ambas dos. La figura 3-16 ilustra las tres instantáneas que Git utiliza para realizar la fusión en este caso.
 
 Insert 18333fig0316.png 
 Figura 3-16. Git identifica automáticamente el mejor ancestro común para realizar la fusión de las ramas.
 
 En lugar de simplemente avanzar el apuntador de la rama, Git crea una nueva instantánea (snapshot) resultante de la fusión a tres bandas; y crea automáticamente una nueva confirmación de cambios (commit) que apunta a ella. Nos referimos a este proceso como "fusión confirmada". Y se diferencia en que tiene más de un padre.
 
-Merece la pena destacar el hecho de que es el propio Git quien determina automáticamente el mejor ancestro común para realizar la fusión. Diferenciandose de otros sistemas tales como CVS o Subversion, donde es el desarrollador quien ha de imaginarse cuál puede ser dicho mejor ancestro común. Esto hace que en Git sea mucho más facil el realizar fusiones.
+Merece la pena destacar el hecho de que es el propio Git quien determina automáticamente el mejor ancestro común para realizar la fusión. Diferenciandose de otros sistemas tales como CVS o Subversion, donde es el desarrollador quien ha de imaginarse cuál puede ser dicho mejor ancestro común. Esto hace que en Git sea mucho más fácil el realizar fusiones.
 
 Insert 18333fig0317.png 
 Figura 3-17. Git crea automáticamente una nueva confirmación para la fusión.
@@ -250,14 +250,14 @@ Todo aquello que sea conflictivo y no se haya podido resolver, se marca como "si
 	</div>
 	>>>>>>> iss53:index.html
 
-Donde nos dice que la versión en HEAD (la rama `master`, la que habias activado antes de lanzar el comando de fusión), contiene lo indicado en la parte superior del bloque (todo lo que está encima de `=======`). Y que la versión en `iss53` contiene el resto, lo indicado en la parte inferior del bloque. Para resolver el conflicto, has de elegir manualmente contenido de uno o de otro lado. Por ejemplo, puedes optar por cambiar el bloque, dejandolo tal que:
+Donde nos dice que la versión en HEAD (la rama `master`, la que habias activado antes de lanzar el comando de fusión), contiene lo indicado en la parte superior del bloque (todo lo que está encima de `=======`). Y que la versión en `iss53` contiene el resto, lo indicado en la parte inferior del bloque. Para resolver el conflicto, has de elegir manualmente contenido de uno o de otro lado. Por ejemplo, puedes optar por cambiar el bloque, dejándolo tal que:
 
 	<div id="footer">
 	please contact us at email.support@github.com
 	</div>
 
 Esta corrección contiene un poco de ambas partes. Y se han eliminado completamente las líneas `<<<<<<<` , `=======` y `>>>>>>>` Tras resolver todos los bloques conflictivos, has de lanzar comandos `git add` para marcar cada archivo modificado. Marcar archivos como preparados (staging), indica a Git que sus conflictos han sido resueltos.
-Si en lugar de resolver directamente, prefieres utilizar una herramienta gráfica, puedes usar el comando `git mergetool`. Esto arrancará la correspondiente herramienta de visualización y te permirá ir resolviendo conflictos con ella.
+Si en lugar de resolver directamente, prefieres utilizar una herramienta gráfica, puedes usar el comando `git mergetool`. Esto arrancará la correspondiente herramienta de visualización y te permitirá ir resolviendo conflictos con ella.
 
 	$ git mergetool
 	merge tool candidates: kdiff3 tkdiff xxdiff meld gvimdiff opendiff emerge vimdiff
@@ -295,7 +295,7 @@ Si todo ha ido correctamente, y ves que todos los archivos conflictivos están m
 	# and try again.
 	#
 
-Puedes modificar este mensaje añadiendo detalles sobre cómo has resuelto la fusión, si lo consideras util para que otros entiendan esta fusión en un futuro. Se trata de indicar porqué has hecho lo que has hecho; a no ser que resulte obvio, claro está.
+Puedes modificar este mensaje añadiendo detalles sobre cómo has resuelto la fusión, si lo consideras útil para que otros entiendan esta fusión en un futuro. Se trata de indicar porqué has hecho lo que has hecho; a no ser que resulte obvio, claro está.
 
 ## Gestión de ramificaciones ##
 
@@ -342,7 +342,7 @@ Ahora que ya has visto los procedimientos básicos de ramificación y fusión, 
 
 ### Ramas de largo recorrido ###
 
-Por la sencillez de la fusión a tres bandas de Git, el fusionar de una rama a otra multitud de veces a lo largo del tiempo es facil de hacer. Esto te posibilita tener varias ramas siempre abiertas, e irlas usando en diferentes etapas del ciclo de desarrollo; realizando frecuentes fusiones entre ellas.
+Por la sencillez de la fusión a tres bandas de Git, el fusionar de una rama a otra multitud de veces a lo largo del tiempo es fácil de hacer. Esto te posibilita tener varias ramas siempre abiertas, e irlas usando en diferentes etapas del ciclo de desarrollo; realizando frecuentes fusiones entre ellas.
 
 Muchos desarrolladores que usan Git llevan un flujo de trabajo de esta naturaleza, manteniendo en la rama `master` únicamente el código totalmente estable (el código que ha sido o que va a ser liberado). Teniendo otras ramas paralelas denominadas `desarrollo` o `siguiente`, en las que trabajan y realizan pruebas. Estas ramas paralelas no suele estar siempre en un estado estable; pero cada vez que sí lo están, pueden ser fusionadas con la rama `master`. También es habitual el incorporarle (pull) ramas puntuales (ramas temporales, como la rama `iss53` del anterior ejemplo) cuando las completamos y estamos seguros de que no van a introducir errores.
 
@@ -375,7 +375,7 @@ En este momento, supongamos que te decides por la segunda solución al problema
 Insert 18333fig0321.png 
 Figura 3-21. El registro tras fusionar `dumbidea` e `iss91v2`.
 
-Es importante recordar que, mientras estás haciendo todo esto, todas las ramas son completamente locales. Cuando ramificas y fusionas, todo se realiza en tu propio repositório Git. No hay nigún tipo de tráfico con ningún servidor.
+Es importante recordar que, mientras estás haciendo todo esto, todas las ramas son completamente locales. Cuando ramificas y fusionas, todo se realiza en tu propio repositorio Git. No hay nigún tipo de tráfico con ningún servidor.
 
 ## Ramas Remotas ##
 
@@ -383,7 +383,7 @@ Las ramas remotas son referencias al estado de ramas en tus repositorios remotos
 
 Suelen referenciarse como `(remoto)/(rama)`. Por ejemplo, si quieres saber cómo estaba la rama `master` en el remoto `origin`. Puedes revisar la rama `origin/master`. O si estás trabajando en un problema con un compañero y este envia (push) una rama `iss53`, tu tendrás tu propia rama de trabajo local `iss53`; pero la rama en el servidor apuntará a la última confirmación (commit) en la rama `origin/iss53`.
 
-Esto puede ser un tanto confuso, pero intentemos aclararlo con un ejemplo.  Supongamos que tienes un sevidor Git en tu red, en `git.ourcompany.com`. Si haces un clón desde ahí, Git automáticamente lo denominará `origin`, traerá (pull) sus datos, creará un apuntador hacia donde esté en ese momento su rama `master`, denominará la copia local `origin/master`; y será inamovible para tí.  Git te proporcionará también tu propia rama `master`, apuntando al mismo lugar que la rama `master` de `origin`; siendo en esta última donde podrás trabajar.
+Esto puede ser un tanto confuso, pero intentemos aclararlo con un ejemplo.  Supongamos que tienes un sevidor Git en tu red, en `git.ourcompany.com`. Si haces un clón desde ahí, Git automáticamente lo denominará `origin`, traerá (pull) sus datos, creará un apuntador hacia donde esté en ese momento su rama `master`, denominará la copia local `origin/master`; y será inamovible para ti.  Git te proporcionará también tu propia rama `master`, apuntando al mismo lugar que la rama `master` de `origin`; siendo en esta última donde podrás trabajar.
 
 Insert 18333fig0322.png 
 Figura 3-22. Un clón Git te proporciona tu propia rama `master` y otra rama `origin/master` apuntando a la rama `master` original.
@@ -422,7 +422,7 @@ Si tienes una rama llamada `serverfix`, con la que vas a trabajar en colaboraci
 	To git@github.com:schacon/simplegit.git
 	 * [new branch]      serverfix -> serverfix
 
-Esto es un poco como un atajo. Git expande automáticamente el nombre de rama `serverfix` a `refs/heads/serverfix:refs/heads/serverfix`, que significa: "coge mi rama local `serverfix` y actualiza con ella la rama `serverfix` del remoto". Volveremos más tarde sobre el tema de `refs/heads/`, viendolo en detalle en el capítulo 9; aunque puedes ignorarlo por ahora. También puedes hacer `git push origin serverfix:serverfix`, que hace lo mismo; es decir: "coge mi `serverfix` y hazlo el `serverfix` remoto". Puedes utilizar este último formato para llevar una rama local a una rama remota con otro nombre distinto. Si no quieres que se llame `serverfix` en el remoto, puedes lanzar, por ejemplo, `git push origin serverfix:awesomebranch`; para llevar tu rama `serverfix` local a la rama `awesomebranch` en el proyecto remoto.
+Esto es un poco como un atajo. Git expande automáticamente el nombre de rama `serverfix` a `refs/heads/serverfix:refs/heads/serverfix`, que significa: "coge mi rama local `serverfix` y actualiza con ella la rama `serverfix` del remoto". Volveremos más tarde sobre el tema de `refs/heads/`, viéndolo en detalle en el capítulo 9; aunque puedes ignorarlo por ahora. También puedes hacer `git push origin serverfix:serverfix`, que hace lo mismo; es decir: "coge mi `serverfix` y hazlo el `serverfix` remoto". Puedes utilizar este último formato para llevar una rama local a una rama remota con otro nombre distinto. Si no quieres que se llame `serverfix` en el remoto, puedes lanzar, por ejemplo, `git push origin serverfix:awesomebranch`; para llevar tu rama `serverfix` local a la rama `awesomebranch` en el proyecto remoto.
 
 La próxima vez que tus colaboradores recuperen desde el servidor, obtendrán una referencia a donde la versión de `serverfix` en el servidor esté bajo la rama remota `origin/serverfix`:
 
@@ -436,7 +436,7 @@ La próxima vez que tus colaboradores recuperen desde el servidor, obtendrán un
 
 Es importante destacar que cuando recuperas (fetch) nuevas ramas remotas, no obtienes automáticamente una copia editable local de las mismas. En otras palabras, en este caso, no tienes una nueva rama `serverfix`. Sino que únicamente tienes un puntero no editable a `origin/serverfix`.
 
-Para integrar (merge) esto en tu actual rama de trabajo, puedes usar el comando `git merge origin/serverfix`. Y si quieres tener tu propia rama `serverfix`, donde puedas trabajar, puedes crearla directamente basandote en rama remota:
+Para integrar (merge) esto en tu actual rama de trabajo, puedes usar el comando `git merge origin/serverfix`. Y si quieres tener tu propia rama `serverfix`, donde puedas trabajar, puedes crearla directamente basaádote en rama remota:
 
 	$ git checkout -b serverfix origin/serverfix
 	Branch serverfix set up to track remote branch refs/remotes/origin/serverfix.
@@ -509,22 +509,22 @@ Figura 3-30. Avance rápido de la rama `master`.
 
 Así, la instantánea apuntada por C3' aquí es exactamente la misma apuntada por C5 en el ejemplo de la fusión. No hay ninguna diferencia en el resultado final de la integración, pero el haberla hecho reorganizando nos deja un registro más claro. Si examinas el registro de una rama reorganizada, este aparece siempre como un registro lineal: como si todo el trabajo se hubiera realizado en series, aunque realmente se haya hecho en paralelo.
 
-Habitualmente, optarás por esta vía cuando quieras estar seguro de que tus confirmaciones de cambio (commits) se pueden aplicar limpiamente sobre una rama remota; posiblemente, en un proyecto donde estés intentando colaborar, pero lleves tu el mantenimiento. En casos como esos, puedes trabajar sobre una rama y luego reorgainzar lo realizado en la rama `origin/master` cuando lo tengas todo listo para enviarlo al proyecto principal. De esta forma, la persona que mantiene el proyecto no necesitará hacer ninguna integración con tu trabajo; le bastará con un avance rápido o una incorporación limpia.
+Habitualmente, optarás por esta vía cuando quieras estar seguro de que tus confirmaciones de cambio (commits) se pueden aplicar limpiamente sobre una rama remota; posiblemente, en un proyecto donde estés intentando colaborar, pero lleves tu el mantenimiento. En casos como esos, puedes trabajar sobre una rama y luego reorganizar lo realizado en la rama `origin/master` cuando lo tengas todo listo para enviarlo al proyecto principal. De esta forma, la persona que mantiene el proyecto no necesitará hacer ninguna integración con tu trabajo; le bastará con un avance rápido o una incorporación limpia.
 
-Cabe destacar que la instantánea (snapshot) apuntada por la confirmación (commit) final, tanto si es producto de una regorganización (rebase) como si lo es de una fusión (merge), es exactamente la misma instantánea. Lo único diferente es el registro. La reorganización vuelve a aplicar cambios de una rama de trabajo sobre otra rama, en el mismo orden en que fueron introducidos en la primera. Mientras que la fusión combina entre sí los dos puntos finales de ambas ramas.
+Cabe destacar que la instantánea (snapshot) apuntada por la confirmación (commit) final, tanto si es producto de una reorganización (rebase) como si lo es de una fusión (merge), es exactamente la misma instantánea. Lo único diferente es el registro. La reorganización vuelve a aplicar cambios de una rama de trabajo sobre otra rama, en el mismo orden en que fueron introducidos en la primera. Mientras que la fusión combina entre sí los dos puntos finales de ambas ramas.
 
 ### Algunas otras reorganizaciones interesantes ###
 
-También puedes aplicar una reorganización (rebase) sobre otra cosa además de sobre la rama de reorganización. Por ejemplo, sea un registro como el de la Figura 3-31. Has ramificado a una rama puntual (`server`) para añadir algunas funcionalidades al proyecto, y luego has confirmado los cambios. Despues, vuelves a la rama original para hacer algunos cambios en la parte cliente (rama `client`), y confirmas también esos cambios. Por último, vuelves sobre la rama `server` y haces algunos cambios más.
+También puedes aplicar una reorganización (rebase) sobre otra cosa además de sobre la rama de reorganización. Por ejemplo, sea un registro como el de la Figura 3-31. Has ramificado a una rama puntual (`server`) para añadir algunas funcionalidades al proyecto, y luego has confirmado los cambios. Después, vuelves a la rama original para hacer algunos cambios en la parte cliente (rama `client`), y confirmas también esos cambios. Por último, vuelves sobre la rama `server` y haces algunos cambios más.
 
 Insert 18333fig0331.png 
 Figura 3-31. Un registro con una rama puntual sobre otra rama puntual.
 
-Imagina que decides incorporar tus cambios de la parte cliente sobre el proyecto principal, para hacer un lanzamiento de versión; pero no quieres lanzar aún los cambios de la parte server porque no están aún suficientemente probados. Puedes coger los cambios del cliente que no estan en server (C8 y C9), y reaplicarlos sobre tu rama principal usando la opción `--onto` del comando `git rebase`:
+Imagina que decides incorporar tus cambios de la parte cliente sobre el proyecto principal, para hacer un lanzamiento de versión; pero no quieres lanzar aún los cambios de la parte server porque no están aún suficientemente probados. Puedes coger los cambios del cliente que no están en server (C8 y C9), y reaplicarlos sobre tu rama principal usando la opción `--onto` del comando `git rebase`:
 
 	$ git rebase --onto master server client
 
-Esto viene a decir: "Activa la rama `client`, averigua los cambios desde el ancestro común entre las ramas `client` y `server`, y aplicalos en la rama `master`. Puede parecer un poco complicado, pero los resultados, mostrados en la Figura 3-32, son realmente interesantes.
+Esto viene a decir: "Activa la rama `client`, averigua los cambios desde el ancestro común entre las ramas `client` y `server`, y aplicarlos en la rama `master`. Puede parecer un poco complicado, pero los resultados, mostrados en la Figura 3-32, son realmente interesantes.
 
 Insert 18333fig0332.png 
 Figura 3-32. Reorganizando una rama puntual fuera de otra rama puntual.
@@ -569,7 +569,7 @@ Siguiendo esta recomendación, no tendrás problemas. Pero si no la sigues, la g
 
 Cuando reorganizas algo, estás abandonando las confirmaciones de cambio ya creadas y estás creando unas nuevas; que son similares, pero diferentes. Si envias (push) confirmaciones (commits) a alguna parte, y otros las recogen (pull) de allí. Y después vas tu y las reescribes con `git rebase` y las vuelves a enviar (push) de nuevo. Tus colaboradores tendrán que refusionar (re-merge) su trabajo  y todo se volverá tremendamente complicado cuando intentes recoger (pull) su trabajo de vuelta sobre el tuyo.
 
-Vamos a verlo con un ejemplo. Imaginate que haces un clon desde un servidor central, y luego trabajas sobre él. Tu registro de cambios puede ser algo como lo de la Figura 3-36.
+Vamos a verlo con un ejemplo. Imagínate que haces un clon desde un servidor central, y luego trabajas sobre él. Tu registro de cambios puede ser algo como lo de la Figura 3-36.
 
 Insert 18333fig0336.png 
 Figura 3-36. Clonar un repositorio y trabajar sobre él.
@@ -579,20 +579,20 @@ Ahora, otra persona trabaja también sobre ello, realiza una fusión (merge) y l
 Insert 18333fig0337.png 
 Figura 3-37. Traer (fetch) algunas confirmaciones de cambio (commits) y fusionarlas (merge) sobre tu trabajo.
 
-A continuación, la persona que habia llevado cambios al servidor central decide retroceder y reorganizar su trabajo; haciendo un `git push --force` para sobreescribir el registro en el servidor. Tu te traes (fetch) esos nuevos cambios desde el servidor.
+A continuación, la persona que había llevado cambios al servidor central decide retroceder y reorganizar su trabajo; haciendo un `git push --force` para sobrescribir el registro en el servidor. Tu te traes (fetch) esos nuevos cambios desde el servidor.
 
 Insert 18333fig0338.png 
-Figura 3-38. Alguien envia (push) confirmaciones (commits) reorganizadas, abandonando las confirmaciones en las que tu habias basado tu trabajo.
+Figura 3-38. Alguien envií (push) confirmaciones (commits) reorganizadas, abandonando las confirmaciones en las que tu habías basado tu trabajo.
 
 En ese momento, tu te ves obligado a fusionar (merge) tu trabajo de nuevo, aunque creias que ya lo habias hecho antes. La reorganización cambia los resumenes (hash) SHA-1 de esas confirmaciones (commits), haciendo que Git se crea que son nuevas confirmaciones. Cuando realmente tu ya tenias el trabajo de C4 en tu registro.
 
 Insert 18333fig0339.png 
 Figura 3-39. Vuelves a fusionar el mismo trabajo en una nueva fusión confirmada.
 
-Te ves obligado a fusionar (merge) ese trabajo en algún punto, para poder seguir adelante con otros desarrollos en el futuro. Tras todo esto, tu registro de confirmaciones de cambio (commit history) contendrá tanto la confirmación C4 como la C4'; teniendo ambas el mismo contenido y el mismo mensaje de confirmación. Si lanzas un `git log` en un registro como este, verás dos confirmaciones  con el mismo autor, misma fecha y mismo mensaje. Lo que puede llevar a confusiones. Es más, si luego tu envias (push) ese registro de vuelta al servidor, vas a introducir todas esas confirmaciones reorganizadas en el servidor central. Lo que puede confundir aún más a la gente.
+Te ves obligado a fusionar (merge) ese trabajo en algún punto, para poder seguir adelante con otros desarrollos en el futuro. Tras todo esto, tu registro de confirmaciones de cambio (commit history) contendrá tanto la confirmación C4 como la C4'; teniendo ambas el mismo contenido y el mismo mensaje de confirmación. Si lanzas un `git log` en un registro como este, verás dos confirmaciones  con el mismo autor, misma fecha y mismo mensaje. Lo que puede llevar a confusiones. Es más, si luego tu envías (push) ese registro de vuelta al servidor, vas a introducir todas esas confirmaciones reorganizadas en el servidor central. Lo que puede confundir aún más a la gente.
 
 Si solo usas la reorganización como una vía para hacer limpieza y organizar confirmaciones de cambio antes de enviarlas, y si únicamente reorganizas confirmaciones que nunca han sido públicas. Entonces no tendrás problemas. Si, por el contrario, reorganizas confirmaciones que alguna vez han sido públicas y otra gente ha basado su trabajo  en ellas. Entonces estarás en un aprieto.
 
 ## Recapitulación ##
 
-Hemos visto los procedimientos básicos de ramificación (branching) y fusión (merging) en Git. A estas alturas, te sentirás cómodo creando nuevas ramas (branch), saltando (checkout) entre ramas para trabajar y fusionando (merge) ramas entre ellas.  También conocerás cómo compatir tus ramas enviandolas (push) a un servidor compartido, cómo trabajar colaborativamente en ramas compartidas, y cómo reorganizar (rebase) tus ramas antes de compartirlas.
+Hemos visto los procedimientos básicos de ramificación (branching) y fusión (merging) en Git. A estas alturas, te sentirás cómodo creando nuevas ramas (branch), saltando (checkout) entre ramas para trabajar y fusionando (merge) ramas entre ellas.  También conocerás cómo compartir tus ramas enviándolas (push) a un servidor compartido, cómo trabajar colaborativamente en ramas compartidas, y cómo reorganizar (rebase) tus ramas antes de compartirlas.

From 0f99958673a96ff97ea9a28556c1d7d022987883 Mon Sep 17 00:00:00 2001
From: Petr Prikryl <prikryl@atlas.cz>
Date: Sun, 18 May 2014 23:22:49 +0200
Subject: [PATCH 433/690] [cs] the empty
 cs/09-git-internals/02-translation-notes.markdown added

The reason is to try overwrite incorectly rendered content.
---
 cs/09-git-internals/02-translation-notes.markdown | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 cs/09-git-internals/02-translation-notes.markdown

diff --git a/cs/09-git-internals/02-translation-notes.markdown b/cs/09-git-internals/02-translation-notes.markdown
new file mode 100644
index 000000000..e69de29bb

From b8ca7b9979f981269279f04ff1201243fca74d59 Mon Sep 17 00:00:00 2001
From: Petr Prikryl <prikryl@atlas.cz>
Date: Tue, 20 May 2014 12:01:24 +0200
Subject: [PATCH 434/690] [cs] faked chapter in
 cs/09-git-internals/02-translation-notes.markdown

---
 cs/09-git-internals/02-translation-notes.markdown | 1 +
 1 file changed, 1 insertion(+)

diff --git a/cs/09-git-internals/02-translation-notes.markdown b/cs/09-git-internals/02-translation-notes.markdown
index e69de29bb..e769bc6e0 100644
--- a/cs/09-git-internals/02-translation-notes.markdown
+++ b/cs/09-git-internals/02-translation-notes.markdown
@@ -0,0 +1 @@
+# ..........
\ No newline at end of file

From 656765a765691d837ba919bc3974529f6ee728c2 Mon Sep 17 00:00:00 2001
From: Soon Van <cog@randomecho.com>
Date: Tue, 20 May 2014 22:47:49 -0400
Subject: [PATCH 435/690] Word spacing and capitals on README [ci skip]

---
 README.md | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/README.md b/README.md
index 5e72d6d1f..0230cddf5 100644
--- a/README.md
+++ b/README.md
@@ -33,7 +33,7 @@ On MacOS you can do like this::
 
 ## Notes on pandoc
 
-Please use Pandoc version 1.11.1 or later as older versions(confirmed on 1.9.1.1) has a [bug](https://github.com/jgm/pandoc/issues/964) which hides a word after tilde `~`.  You can do `pandoc -v` to see which version you have installed.
+Please use Pandoc version 1.11.1 or later as older versions (confirmed on 1.9.1.1) has a [bug](https://github.com/jgm/pandoc/issues/964) which hides a word after tilde `~`.  You can do `pandoc -v` to see which version you have installed.
 
 # Errata
 
@@ -46,13 +46,13 @@ correction, please [open an issue](https://github.com/progit/progit/issues/new)
 If you wish to translate the book, your work will be put up on the 
 git-scm.com site.  Please put your translation into the appropriate
 subdirectory of this project, using the 
-[ISO 639](http://en.wikipedia.org/wiki/List_of_ISO_639-1_codes) 
+[ISO 639](http://en.wikipedia.org/wiki/List_of_ISO_639-1_codes) code 
 and send a pull request.
 
 # Sending a pull request
 
 * Be careful to use UTF-8 encoding in your files.
-* Do not mix changes to the original english with translations in a single pull request.
-* If your pull request changes a translation, prefix your pull request and commits'messages with the ISO 639 code, e.g. `[de] Update chapter 2`. Please only push files where there is already some translation done.
+* Do not mix changes to the original English with translations in a single pull request.
+* If your pull request changes a translation, prefix your pull request and commits' messages with the ISO 639 code, e.g. `[de] Update chapter 2`. Please only push files where there is already some translation done.
 * Make sure the translation changes can be automatically merged. The maintainers can not make the merge manually if there are some conflicts.
-* Make as sure as possible that the changes work correctly for publishing to pdf, ebooks and the git-scm.com website
+* Make as sure as possible that the changes work correctly for publishing to PDF, ebooks and the git-scm.com website.

From fce58269569383f95c59278c838feb8a4226c98e Mon Sep 17 00:00:00 2001
From: Yue Lin Ho <b8732003@student.nsysu.edu.tw>
Date: Fri, 23 May 2014 07:11:54 +0800
Subject: [PATCH 436/690] [zh-tw] Synchronize with En version

Based on commits from 2014.04.15 to 2014.05.17:
 1) 3f6c10594c51ac7b61dab0115c5f43740ef7093b
 2) ceba7dfb5358143802192fd6f231db1aa06aaccb
 3) 60e261895a77951a6541470c9438f32a1e5b7fd0
 4) 5f72fef306296811cc8b165e312b703f6090931c
 5) 9c4252b492885aabe41346148d589b480e753a60
 6) 20a3f53631c8b3fb448ac7717263b62a22f4ffda
 7) f987da8c61924b4f710fd9aac26619bf6b5e9d85
 8) f5170bb2e34131c7088236066d13d1f657dfa381
---
 zh-tw/02-git-basics/01-chapter2.markdown      |  8 +++--
 zh-tw/06-git-tools/01-chapter6.markdown       | 36 +++++++++++++------
 zh-tw/07-customizing-git/01-chapter7.markdown | 12 +++----
 3 files changed, 35 insertions(+), 21 deletions(-)

diff --git a/zh-tw/02-git-basics/01-chapter2.markdown b/zh-tw/02-git-basics/01-chapter2.markdown
index 2f80c92c1..0ab5bb8e7 100644
--- a/zh-tw/02-git-basics/01-chapter2.markdown
+++ b/zh-tw/02-git-basics/01-chapter2.markdown
@@ -325,7 +325,7 @@ A `**/` pattern is available in Git since version 1.8.2.
 另一種方式則是在commit命令後方以`-m`參數指定提交訊息，如下：
 
 	$ git commit -m "Story 182: Fix benchmarks for speed"
-	[master 463dc4f] Fix benchmarks for speed
+	[master 463dc4f] Story 182: Fix benchmarks for speed
 	 2 files changed, 3 insertions(+)
 	 create mode 100644 README
 
@@ -638,7 +638,9 @@ The lines must be formatted as follows
 
 此命令支援多種格式。 可指定特定日期（如：“2008-01-15”）或相對的日期，如：“2 years 1 day 3 minutes ago”。
 
-使用者也可以過濾出符合某些搜尋條件的更新。 `--author` 選項允許使用者過濾出特定作者，而 `--grep` 選項允許以關鍵字搜尋提交的訊息。（注意：若希望同時符合作者名字及字串比對，需要再加上 `--all-match`；否則預設為列出符合任一條件的更新）
+使用者也可以過濾出符合某些搜尋條件的更新。 `--author` 選項允許使用者過濾出特定作者，而 `--grep` 選項允許以關鍵字搜尋提交的訊息。（注意：若同時使用作者名字及字串比對，該命令會列出同時符合二個條件的更新。）
+
+若希望比對多個字串，需要再加上 `--all-match`；否則只會列出符合任一條件的更新。
 
 最後一個有用的選項是過濾路徑。 若指定目錄或檔案名稱，可僅印出更動到這些檔案的更新。 這選項永遠放在最後，而且一般來說會在前方加上 -- 以資區別。
 
@@ -797,7 +799,7 @@ Insert 18333fig0202.png
 	koke      git://github.com/koke/grit.git
 	origin    git@github.com:mojombo/grit.git
 
-這意謂著我們可很容易從這些伙伴的儲存庫取得最新的更新。 要留意的是只有 origin 遠端的 URL 是 SSH。 因此它是唯一我們能上傳的遠端的儲存庫。（關於這部份將在第四章介紹） 
+這意謂著我可以很容易從這些伙伴的儲存庫取得最新的更新。 要留意的是只有 origin 遠端的 URL 是 SSH。 因此它是唯一我能上傳的遠端的儲存庫。（關於這部份將在第四章介紹） 
 
 ### 新增遠端儲存庫 ###
 
diff --git a/zh-tw/06-git-tools/01-chapter6.markdown b/zh-tw/06-git-tools/01-chapter6.markdown
index 392cc7b5b..42c34316e 100644
--- a/zh-tw/06-git-tools/01-chapter6.markdown
+++ b/zh-tw/06-git-tools/01-chapter6.markdown
@@ -82,13 +82,13 @@ Git 可以為你的 SHA-1 值生成出簡短且唯一的縮寫。如果你傳遞
 你可以使用 `git reflog` 來查看引用日誌：
 
 	$ git reflog
-	734713b... HEAD@{0}: commit: fixed refs handling, added gc auto, updated
-	d921970... HEAD@{1}: merge phedders/rdocs: Merge made by recursive.
-	1c002dd... HEAD@{2}: commit: added some blame and merge stuff
-	1c36188... HEAD@{3}: rebase -i (squash): updating HEAD
-	95df984... HEAD@{4}: commit: # This is a combination of two commits.
-	1c36188... HEAD@{5}: rebase -i (squash): updating HEAD
-	7e05da5... HEAD@{6}: rebase -i (pick): updating HEAD
+	734713b HEAD@{0}: commit: fixed refs handling, added gc auto, updated
+	d921970 HEAD@{1}: merge phedders/rdocs: Merge made by recursive.
+	1c002dd HEAD@{2}: commit: added some blame and merge stuff
+	1c36188 HEAD@{3}: rebase -i (squash): updating HEAD
+	95df984 HEAD@{4}: commit: # This is a combination of two commits.
+	1c36188 HEAD@{5}: rebase -i (squash): updating HEAD
+	7e05da5 HEAD@{6}: rebase -i (pick): updating HEAD
 
 每次你的分支頂端因為某些原因被修改時，Git 就會為你將資訊保存在這個臨時歷史記錄裡面。你也可以使用這份資料來指明更早的分支。如果你想查看倉庫中 HEAD 在五次前的值，你可以使用引用日誌的輸出中的 @{n} 引用： 
 
@@ -445,8 +445,8 @@ simplegit.rb 的狀態非常有意思。它顯示有幾行被暫存了，有幾
 
 	$ git stash list
 	stash@{0}: WIP on master: 049d078 added the index file
-	stash@{1}: WIP on master: c264051... Revert "added file_size"
-	stash@{2}: WIP on master: 21d80a5... added number to log
+	stash@{1}: WIP on master: c264051 Revert "added file_size"
+	stash@{2}: WIP on master: 21d80a5 added number to log
 
 在這個案例中，之前已經進行了兩次儲藏，所以你可以取得三個不同的儲藏。你可以重新應用你剛剛的儲藏，所採用的命令就是原本 stash 命令輸出的輔助訊息裡提示的：`git stash apply`。如果你想應用較舊的儲藏，你可以通過名字指定它，像這樣：`git stash apply stash@{2}`。如果你不指明，Git 預設使用最近的儲藏並嘗試應用它： 
 
@@ -480,8 +480,8 @@ apply 選項只嘗試應用儲藏的工作——儲藏的內容仍然在堆疊
 
 	$ git stash list
 	stash@{0}: WIP on master: 049d078 added the index file
-	stash@{1}: WIP on master: c264051... Revert "added file_size"
-	stash@{2}: WIP on master: 21d80a5... added number to log
+	stash@{1}: WIP on master: c264051 Revert "added file_size"
+	stash@{2}: WIP on master: 21d80a5 added number to log
 	$ git stash drop stash@{0}
 	Dropped stash@{0} (364e91f3f268f0900bc3ee613f9f733e82aaed43)
 
@@ -565,12 +565,19 @@ apply 選項只嘗試應用儲藏的工作——儲藏的內容仍然在堆疊
 	#
 	# Commands:
 	#  p, pick = use commit
+	#  r, reword = use commit, but edit the commit message
 	#  e, edit = use commit, but stop for amending
 	#  s, squash = use commit, but meld into previous commit
+	#  f, fixup = like "squash", but discard this commit's log message
+	#  x, exec = run command (the rest of the line) using shell
+	#
+	# These lines can be re-ordered; they are executed from top to bottom.
 	#
 	# If you remove a line here THAT COMMIT WILL BE LOST.
+	#
 	# However, if you remove everything, the rebase will be aborted.
 	#
+	# Note that empty commits are commented out
 
 很重要的一點是你得注意這些提交的順序與你通常通過 `log` 命令看到的是相反的。如果你執行 `log`，你會看到下面這樣的結果： 
 
@@ -631,12 +638,19 @@ apply 選項只嘗試應用儲藏的工作——儲藏的內容仍然在堆疊
 	#
 	# Commands:
 	#  p, pick = use commit
+	#  r, reword = use commit, but edit the commit message
 	#  e, edit = use commit, but stop for amending
 	#  s, squash = use commit, but meld into previous commit
+	#  f, fixup = like "squash", but discard this commit's log message
+	#  x, exec = run command (the rest of the line) using shell
+	#
+	# These lines can be re-ordered; they are executed from top to bottom.
 	#
 	# If you remove a line here THAT COMMIT WILL BE LOST.
+	#
 	# However, if you remove everything, the rebase will be aborted.
 	#
+	# Note that empty commits are commented out
 
 如果不用 ”pick” 或者 ”edit”，而是指定 ”squash”，Git 會同時應用那個變更和它之前的變更並將提交說明歸併。因此，如果你想將這三個提交合併為單一提交，你可以將腳本修改成這樣： 
 
diff --git a/zh-tw/07-customizing-git/01-chapter7.markdown b/zh-tw/07-customizing-git/01-chapter7.markdown
index 4c85c396e..e16573d71 100644
--- a/zh-tw/07-customizing-git/01-chapter7.markdown
+++ b/zh-tw/07-customizing-git/01-chapter7.markdown
@@ -609,14 +609,12 @@ update 腳本和 `pre-receive` 腳本十分類似，除了它會為推送者更
 
 	#!/usr/bin/env ruby
 
-	$refname = ARGV[0]
-	$oldrev  = ARGV[1]
-	$newrev  = ARGV[2]
-	$user    = ENV['USER']
-
-	puts "Enforcing Policies... \n(#{$refname}) (#{$oldrev[0,6]}) (#{$newrev[0,6]})"
+	refname = ARGV[0]
+	oldrev  = ARGV[1]
+	newrev  = ARGV[2]
+	user    = ENV['USER']
 
-沒錯，我在用全域變數。別鄙視我——這樣比較利於演示過程。 
+	puts "Enforcing Policies... \n(#{refname}) (#{oldrev[0,6]}) (#{newrev[0,6]})"
 
 #### 強制特定的提交資訊格式 ####
 

From 178682200b339a8802be852494c0282f5467e9d5 Mon Sep 17 00:00:00 2001
From: Xue Fuqiao <xfq.free@gmail.com>
Date: Tue, 27 May 2014 16:59:45 +0800
Subject: [PATCH 437/690] Markup fix.

---
 en/05-distributed-git/01-chapter5.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/en/05-distributed-git/01-chapter5.markdown b/en/05-distributed-git/01-chapter5.markdown
index 7d06fb1e8..af0ae4ad2 100644
--- a/en/05-distributed-git/01-chapter5.markdown
+++ b/en/05-distributed-git/01-chapter5.markdown
@@ -632,7 +632,7 @@ To apply a patch generated by `format-patch`, you use `git am`. Technically, `gi
 
 	Limit log functionality to the first 20
 
-This is the beginning of the output of the format-patch command that you saw in the previous section. This is also a valid mbox e-mail format. If someone has e-mailed you the patch properly using git send-email, and you download that into an mbox format, then you can point git am to that mbox file, and it will start applying all the patches it sees. If you run a mail client that can save several e-mails out in mbox format, you can save entire patch series into a file and then use git am to apply them one at a time.
+This is the beginning of the output of the format-patch command that you saw in the previous section. This is also a valid mbox e-mail format. If someone has e-mailed you the patch properly using `git send-email`, and you download that into an mbox format, then you can point `git am` to that mbox file, and it will start applying all the patches it sees. If you run a mail client that can save several e-mails out in mbox format, you can save entire patch series into a file and then use `git am` to apply them one at a time.
 
 However, if someone uploaded a patch file generated via `format-patch` to a ticketing system or something similar, you can save the file locally and then pass that file saved on your disk to `git am` to apply it:
 

From 10de0a2643bba02739c4dd6a44bd3bf40223654d Mon Sep 17 00:00:00 2001
From: Xue Fuqiao <xfq.free@gmail.com>
Date: Tue, 27 May 2014 17:28:24 +0800
Subject: [PATCH 438/690] [zh] Sync with English version.

---
 zh/02-git-basics/01-chapter2.markdown      |  2 +-
 zh/06-git-tools/01-chapter6.markdown       | 22 +++++++++++-----------
 zh/07-customizing-git/01-chapter7.markdown | 12 +++++-------
 3 files changed, 17 insertions(+), 19 deletions(-)

diff --git a/zh/02-git-basics/01-chapter2.markdown b/zh/02-git-basics/01-chapter2.markdown
index 2a95c60f4..e8e878d0e 100644
--- a/zh/02-git-basics/01-chapter2.markdown
+++ b/zh/02-git-basics/01-chapter2.markdown
@@ -323,7 +323,7 @@ A `**/` pattern is available in Git since version 1.8.2.
 另外也可以用 -m 参数后跟提交说明的方式，在一行命令中提交更新：
 
 	$ git commit -m "Story 182: Fix benchmarks for speed"
-	[master 463dc4f] Fix benchmarks for speed
+	[master 463dc4f] Story 182: Fix benchmarks for speed
 	 2 files changed, 3 insertions(+)
 	 create mode 100644 README
 
diff --git a/zh/06-git-tools/01-chapter6.markdown b/zh/06-git-tools/01-chapter6.markdown
index 391317cfa..ac3f20ac1 100644
--- a/zh/06-git-tools/01-chapter6.markdown
+++ b/zh/06-git-tools/01-chapter6.markdown
@@ -82,13 +82,13 @@ Git 可以为你的 SHA-1 值生成出简短且唯一的缩写。如果你传递
 你可以使用 `git reflog` 来查看引用日志：
 
 	$ git reflog
-	734713b... HEAD@{0}: commit: fixed refs handling, added gc auto, updated
-	d921970... HEAD@{1}: merge phedders/rdocs: Merge made by recursive.
-	1c002dd... HEAD@{2}: commit: added some blame and merge stuff
-	1c36188... HEAD@{3}: rebase -i (squash): updating HEAD
-	95df984... HEAD@{4}: commit: # This is a combination of two commits.
-	1c36188... HEAD@{5}: rebase -i (squash): updating HEAD
-	7e05da5... HEAD@{6}: rebase -i (pick): updating HEAD
+	734713b HEAD@{0}: commit: fixed refs handling, added gc auto, updated
+	d921970 HEAD@{1}: merge phedders/rdocs: Merge made by recursive.
+	1c002dd HEAD@{2}: commit: added some blame and merge stuff
+	1c36188 HEAD@{3}: rebase -i (squash): updating HEAD
+	95df984 HEAD@{4}: commit: # This is a combination of two commits.
+	1c36188 HEAD@{5}: rebase -i (squash): updating HEAD
+	7e05da5 HEAD@{6}: rebase -i (pick): updating HEAD
 
 每次你的分支顶端因为某些原因被修改时，Git 就会为你将信息保存在这个临时历史记录里面。你也可以使用这份数据来指明更早的分支。如果你想查看仓库中 HEAD 在五次前的值，你可以使用引用日志的输出中的 `@{n}` 引用：
 
@@ -445,8 +445,8 @@ simplegit.rb的状态非常有意思。它显示有几行被暂存了，有几
 
 	$ git stash list
 	stash@{0}: WIP on master: 049d078 added the index file
-	stash@{1}: WIP on master: c264051... Revert "added file_size"
-	stash@{2}: WIP on master: 21d80a5... added number to log
+	stash@{1}: WIP on master: c264051 Revert "added file_size"
+	stash@{2}: WIP on master: 21d80a5 added number to log
 
 在这个案例中，之前已经进行了两次储藏，所以你可以访问到三个不同的储藏。你可以重新应用你刚刚实施的储藏，所采用的命令就是之前在原始的 stash 命令的帮助输出里提示的：`git stash apply`。如果你想应用更早的储藏，你可以通过名字指定它，像这样：`git stash apply stash@{2}`。如果你不指明，Git 默认使用最近的储藏并尝试应用它：
 
@@ -480,8 +480,8 @@ apply 选项只尝试应用储藏的工作——储藏的内容仍然在栈上
 
 	$ git stash list
 	stash@{0}: WIP on master: 049d078 added the index file
-	stash@{1}: WIP on master: c264051... Revert "added file_size"
-	stash@{2}: WIP on master: 21d80a5... added number to log
+	stash@{1}: WIP on master: c264051 Revert "added file_size"
+	stash@{2}: WIP on master: 21d80a5 added number to log
 	$ git stash drop stash@{0}
 	Dropped stash@{0} (364e91f3f268f0900bc3ee613f9f733e82aaed43)
 
diff --git a/zh/07-customizing-git/01-chapter7.markdown b/zh/07-customizing-git/01-chapter7.markdown
index 9b1a5b9aa..2b4d20121 100644
--- a/zh/07-customizing-git/01-chapter7.markdown
+++ b/zh/07-customizing-git/01-chapter7.markdown
@@ -612,14 +612,12 @@ update 脚本和 `pre-receive` 脚本十分类似。不同之处在于它会为
 
 	#!/usr/bin/env ruby
 
-	$refname = ARGV[0]
-	$oldrev  = ARGV[1]
-	$newrev  = ARGV[2]
-	$user    = ENV['USER']
-
-	puts "Enforcing Policies... \n(#{$refname}) (#{$oldrev[0,6]}) (#{$newrev[0,6]})"
+	refname = ARGV[0]
+	oldrev  = ARGV[1]
+	newrev  = ARGV[2]
+	user    = ENV['USER']
 
-没错，我在用全局变量。别鄙视我——这样比较利于演示过程。
+	puts "Enforcing Policies... \n(#{refname}) (#{oldrev[0,6]}) (#{newrev[0,6]})"
 
 #### 指定特殊的提交信息格式 ####
 

From 766b4a0cb5c03d6539e955213eb57e4635a78cfa Mon Sep 17 00:00:00 2001
From: Changwoo Park <pismute@gmail.com>
Date: Sat, 31 May 2014 00:12:13 +0900
Subject: [PATCH 439/690] [ko] update translation

---
 ko/01-introduction/01-chapter1.markdown    |   2 +-
 ko/02-git-basics/01-chapter2.markdown      | 300 +++++++++++----------
 ko/03-git-branching/01-chapter3.markdown   |  92 ++++---
 ko/04-git-server/01-chapter4.markdown      |  50 ++--
 ko/05-distributed-git/01-chapter5.markdown |  37 ++-
 ko/06-git-tools/01-chapter6.markdown       |  40 ++-
 ko/07-customizing-git/01-chapter7.markdown |  12 +-
 7 files changed, 298 insertions(+), 235 deletions(-)

diff --git a/ko/01-introduction/01-chapter1.markdown b/ko/01-introduction/01-chapter1.markdown
index a7a24715b..131e80efb 100644
--- a/ko/01-introduction/01-chapter1.markdown
+++ b/ko/01-introduction/01-chapter1.markdown
@@ -163,7 +163,7 @@ Ubuntu같은 데비안류 배포판에서는 apt-get을 사용한다:
 
 Mac에 Git을 쉽게 설치하는 방법은 두 가지가 있다. GUI 인스톨러가 가장 쉽게 사용할 수 있다. Google Code 페이지에서 내려받는다:
 
-	http://code.google.com/p/git-osx-installer
+	http://sourceforge.net/projects/git-osx-installer/
 
 Insert 18333fig0107.png 
 그림 1-7. OS X Git 인스톨러
diff --git a/ko/02-git-basics/01-chapter2.markdown b/ko/02-git-basics/01-chapter2.markdown
index 5bf08bdfa..61764f4ab 100644
--- a/ko/02-git-basics/01-chapter2.markdown
+++ b/ko/02-git-basics/01-chapter2.markdown
@@ -54,8 +54,8 @@ Insert 18333fig0201.png
 파일의 상태를 확인하려면 보통 `git status` 명령을 사용한다. Clone한 후에 바로 이 명령을 실행하면 아래과 같은 메시지를 볼 수 있다:
 
 	$ git status
-	# On branch master
-	nothing to commit (working directory clean)
+	On branch master
+	nothing to commit, working directory clean
 
 위의 내용은 파일을 하나도 수정하지 않았다는 것을 말해준다. Tracked나 Modified 상태인 파일이 없다는 의미다. Untracked 파일은 아직 없어서 목록에 나타나지 않는다. 그리고 현재 작업 중인 브랜치를 알려준다. 기본 브랜치가 master이기 때문에 현재 master로 나오는 것이다. 브랜치 관련 내용은 차차 알아가자. 다음 장에서 브랜치와 레퍼런스에 대해 자세히 다룬다.
 
@@ -63,11 +63,12 @@ Insert 18333fig0201.png
 
 	$ vim README
 	$ git status
-	# On branch master
-	# Untracked files:
-	#   (use "git add <file>..." to include in what will be committed)
-	#
-	#	README
+	On branch master
+	Untracked files:
+	  (use "git add <file>..." to include in what will be committed)
+	
+		README
+	
 	nothing added to commit but untracked files present (use "git add" to track)
 
 `README` 파일은 `Untracked files` 부분에 속해 있는데 이것은 `README` 파일이 Untracked 상태라는 것을 말한다. Git은 Untracked 파일을 아직 스냅샷(커밋)에 넣어지지 않은 파일이라고 본다. 파일이 Tracked 상태가 되기 전까지는 Git은 절대 그 파일을 커밋하지 않는다. 그래서 일하면서 생성하는 바이너리 파일 같은 것을 커밋하는 실수는 하지 않게 된다. README 파일을 추가해서 직접 Tracked 상태로 만들어 보자.
@@ -81,12 +82,12 @@ Insert 18333fig0201.png
 `git status` 명령을 다시 실행하면 README 파일이 Tracked 상태이면서 Staged 상태라는 것을 확인할 수 있다:
 
 	$ git status
-	# On branch master
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#	new file:   README
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        new file:   README
+	
 
 'Changes to be committed' 에 들어 있는 파일은 Staged 상태라는 것을 의미한다. 커밋하면 `git add`를 실행한 시점의 파일이 커밋되어 저장소 히스토리에 남는다. 앞에서 `git init` 명령을 실행했을 때, 그 다음 `git add (files)` 명령을 실행했던 걸 기억할 것이다. 이것은 작업 디렉토리에 있는 파일들을 추적하기 시작하게 하였다. `git add` 명령은 파일 또는 디렉토리의 경로명을 아규먼트로 받는다; 만일 디렉토리를 아규먼트로 줄 경우, 그 디렉토리 아래에 있는 모든 파일들을 재귀적으로 추가한다.
 
@@ -95,58 +96,59 @@ Insert 18333fig0201.png
 이미 Tracked 상태인 파일을 수정하는 법을 알아보자. `benchmarks.rb`라는 파일을 수정하고 나서 `git status` 명령을 다시 실행하면 결과는 아래와 같다:
 
 	$ git status
-	# On branch master
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#	new file:   README
-	#
-	# Changes not staged for commit:
-	#   (use "git add <file>..." to update what will be committed)
-	#
-	#	modified:   benchmarks.rb
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        new file:   README
+	
+	Changes not staged for commit:
+	  (use "git add <file>..." to update what will be committed)
+	  (use "git checkout -- <file>..." to discard changes in working directory)
+	
+	        modified:   benchmarks.rb
+	
 
 이 `benchmarks.rb` 파일은 `Changes not staged for commit`에 있다. 이것은 수정한 파일이 Tracked 상태이지만 아직 Staged 상태는 아니라는 것이다. Staged 상태로 만들려면 `git add` 명령을 실행해야 한다. `git add`는 파일을 새로 추적할 때도 사용하고 수정한 파일을 Staged 상태로 만들 때도 사용한다. `git add`를 실행하여 benchmarks.rb 파일을 Staged 상태로 만들고 `git status` 명령으로 결과를 확인해보자:
 
 	$ git add benchmarks.rb
 	$ git status
-	# On branch master
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#	new file:   README
-	#	modified:   benchmarks.rb
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        new file:   README
+	        modified:   benchmarks.rb
+	
 
 두 파일 모두 Staged 상태이므로 다음 커밋에 포함된다. 하지만, 아직 더 수정해야 한다는 것을 알게 되어 바로 커밋하지 못하는 상황이 되었다고 하자. 이 상황에서 benchmark.rb 파일을 열고 수정한다. 아마 당신은 커밋할 준비가 다 됐다고 생각할 테지만, Git은 그렇지 않다. `git status` 명령으로 파일의 상태를 다시 확인해보자:
 
 	$ vim benchmarks.rb
 	$ git status
-	# On branch master
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#	new file:   README
-	#	modified:   benchmarks.rb
-	#
-	# Changes not staged for commit:
-	#   (use "git add <file>..." to update what will be committed)
-	#
-	#	modified:   benchmarks.rb
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        new file:   README
+	        modified:   benchmarks.rb
+	
+	Changes not staged for commit:
+	  (use "git add <file>..." to update what will be committed)
+	
+	        modified:   benchmarks.rb
+	
 
 헉! benchmarks.rb가 Staged 상태이면서 동시에 Unstaged 상태로 나온다. 어떻게 이런 일이 가능할까? `git add` 명령을 실행하면 Git은 파일을 바로 Staged 상태로 만든다. 지금 이 시점에서 커밋을 하면 `git commit` 명령을 실행하는 시점의 버전이 커밋되는 것이 아니라 마지막으로 `git add` 명령을 실행했을 때의 버전이 커밋된다. 그러니까 `git add` 명령을 실행한 후에 또 파일을 수정하면 `git add` 명령을 다시 실행해서 최신 버전을 Staged 상태로 만들어야 한다:
 
 	$ git add benchmarks.rb
 	$ git status
-	# On branch master
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#	new file:   README
-	#	modified:   benchmarks.rb
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        new file:   README
+	        modified:   benchmarks.rb
+	
 
 ### 파일 무시하기 ###
 
@@ -192,17 +194,18 @@ Glob 패턴은 정규표현식을 단순하게 만든 것으로 생각하면 되
 README 파일을 수정해서 Staged 상태로 만들고 benchmarks.rb 파일은 그냥 수정만 해둔다. 이 상태에서 `git status` 명령을 실행하면 아래와 같은 메시지를 볼 수 있다:
 
 	$ git status
-	# On branch master
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#	new file:   README
-	#
-	# Changes not staged for commit:
-	#   (use "git add <file>..." to update what will be committed)
-	#
-	#	modified:   benchmarks.rb
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        new file:   README
+	
+	Changes not staged for commit:
+	  (use "git add <file>..." to update what will be committed)
+	  (use "git checkout -- <file>..." to discard changes in working directory)
+	
+	        modified:   benchmarks.rb
+	
 
 `git diff` 명령을 실행하면 수정했지만 아직 staged 상태가 아닌 파일을 비교해 볼 수 있다:
 
@@ -247,16 +250,18 @@ benchmarks.rb 파일을 Stage한 후에 다시 수정해도 `git diff` 명령을
 	$ git add benchmarks.rb
 	$ echo '# test line' >> benchmarks.rb
 	$ git status
-	# On branch master
-	#
-	# Changes to be committed:
-	#
-	#	modified:   benchmarks.rb
-	#
-	# Changes not staged for commit:
-	#
-	#	modified:   benchmarks.rb
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        modified:   benchmarks.rb
+	
+	Changes not staged for commit:
+	  (use "git add <file>..." to update what will be committed)
+	  (use "git checkout -- <file>..." to discard changes in working directory)
+	
+	        modified:   benchmarks.rb
+	
 
 `git diff` 명령으로 Unstaged 상태인 변경 부분을 확인해 볼 수 있다:
 
@@ -305,10 +310,9 @@ Git 설정에 지정된 편집기가 실행되고, 아래와 같은 텍스트가
 	# with '#' will be ignored, and an empty message aborts the commit.
 	# On branch master
 	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
 	#       new file:   README
 	#       modified:   benchmarks.rb
+	#
 	~
 	~
 	~
@@ -319,8 +323,8 @@ Git 설정에 지정된 편집기가 실행되고, 아래와 같은 텍스트가
 메시지를 인라인으로 첨부할 수도 있다. `commit` 명령을 실행할 때 아래와 같이 `-m` 옵션을 사용한다:
 
 	$ git commit -m "Story 182: Fix benchmarks for speed"
-	[master]: created 463dc4f: "Fix benchmarks for speed"
-	 2 files changed, 3 insertions(+), 0 deletions(-)
+	[master 463dc4f] Story 182: Fix benchmarks for speed
+	 2 files changed, 3 insertions(+)
 	 create mode 100644 README
 
 `commit` 명령은 몇 가지 정보를 출력하는데 위 예제는 master 브랜치에 커밋했고 체크섬은 `463dc4f`이라고 알려준다. 그리고 수정한 파일이 몇 개이고 삭제됐거나 추가된 줄이 몇 줄인지 알려준다.
@@ -332,15 +336,17 @@ Git은 Staging Area에 속한 스냅샷을 커밋한다는 것을 기억해야 
 Staging Area는 커밋할 파일을 정리한다는 점에서 매우 유용하지만 복잡하기만 하고 필요하지 않은 때도 있다. 아주 쉽게 Staging Area를 생략할 수 있다. `git commit` 명령을 실행할 때 `-a` 옵션을 추가하면 Git은 Tracked 상태의 파일을 자동으로 Staging Area에 넣는다. 그래서 `git add` 명령을 실행하는 수고를 덜 수 있다:
 
 	$ git status
-	# On branch master
-	#
-	# Changes not staged for commit:
-	#
-	#	modified:   benchmarks.rb
-	#
+	On branch master
+	Changes not staged for commit:
+	  (use "git add <file>..." to update what will be committed)
+	  (use "git checkout -- <file>..." to discard changes in working directory)
+	
+	        modified:   benchmarks.rb
+	
+	no changes added to commit (use "git add" and/or "git commit -a")
 	$ git commit -a -m 'added new benchmarks'
 	[master 83e38c7] added new benchmarks
-	 1 files changed, 5 insertions(+), 0 deletions(-)
+	 1 files changed, 5 insertions(+)
 
 이 예제에서는 커밋하기 전에 `git add` 명령으로 benchmarks.rb 파일을 추가하지 않았다는 점을 눈여겨보자.
 
@@ -352,26 +358,26 @@ Git에서 파일을 제거하려면 `git rm` 명령으로 Tracked 상태의 파
 
 	$ rm grit.gemspec
 	$ git status
-	# On branch master
-	#
-	# Changes not staged for commit:
-	#   (use "git add/rm <file>..." to update what will be committed)
-	#
-	#       deleted:    grit.gemspec
-	#
+	On branch master
+	Changes not staged for commit:
+	  (use "git add/rm <file>..." to update what will be committed)
+	  (use "git checkout -- <file>..." to discard changes in working directory)
+	
+	        deleted:    grit.gemspec
+	
+	no changes added to commit (use "git add" and/or "git commit -a")
 
 그리고 `git rm` 명령을 실행하면 삭제한 파일은 staged 상태가 된다:
 
 	$ git rm grit.gemspec
 	rm 'grit.gemspec'
 	$ git status
-	# On branch master
-	#
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#       deleted:    grit.gemspec
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        deleted:    grit.gemspec
+	
 
 커밋하면 파일은 삭제되고 Git은 이 파일을 더는 추적하지 않는다. 이미 파일을 수정했거나 Index에(역주, Staging Area을 Git Index라고도 부른다) 추가했다면 `-f`옵션을 주어 강제로 삭제해야 한다. 이 점은 실수로 데이터를 삭제하지 못하도록 하는 안전장치다. 한 번도 커밋한적 없는 데이터는 Git으로 복구할 수 없다.
 
@@ -401,14 +407,12 @@ Git은 다른 VCS 시스템과는 달리 파일 이름의 변경이나 파일의
 
 	$ git mv README.txt README
 	$ git status
-	# On branch master
-	# Your branch is ahead of 'origin/master' by 1 commit.
-	#
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#       renamed:    README.txt -> README
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        renamed:    README.txt -> README
+	
 
 사실 `git mv` 명령은 아래 명령어들을 수행한 것과 완전히 똑같다:
 
@@ -525,7 +529,7 @@ Git은 다른 VCS 시스템과는 달리 파일 이름의 변경이나 파일의
 	    changed the version number
 
 	 Rakefile |    2 +-
-	 1 files changed, 1 insertions(+), 1 deletions(-)
+	 1 file changed, 1 insertion(+), 1 deletion(-)
 
 	commit 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7
 	Author: Scott Chacon <schacon@gee-mail.com>
@@ -534,7 +538,7 @@ Git은 다른 VCS 시스템과는 달리 파일 이름의 변경이나 파일의
 	    removed unnecessary test code
 
 	 lib/simplegit.rb |    5 -----
-	 1 files changed, 0 insertions(+), 5 deletions(-)
+	 1 file changed, 5 deletions(-)
 
 	commit a11bef06a3f659402fe7563abf99ad00de2209e6
 	Author: Scott Chacon <schacon@gee-mail.com>
@@ -545,7 +549,7 @@ Git은 다른 VCS 시스템과는 달리 파일 이름의 변경이나 파일의
 	 README           |    6 ++++++
 	 Rakefile         |   23 +++++++++++++++++++++++
 	 lib/simplegit.rb |   25 +++++++++++++++++++++++++
-	 3 files changed, 54 insertions(+), 0 deletions(-)
+	 3 files changed, 54 insertions(+)
 
 이 결과에서 `--stat` 옵션은 어떤 파일이 수정됐는지, 얼마나 많은 파일이 변경됐는지, 또 얼마나 많은 줄을 추가하거나 삭제했는지 보여준다. 요약정보는 가장 뒤쪽에 보여준다.
 
@@ -633,7 +637,9 @@ The lines must be formatted as follows
 
 이 옵션은 다양한 형식을 지원한다. `2008-01-15`같이 정확한 날짜도 사용할 수 있고 `2 years 1 day 3 minutes ago`같이 상대적인 기간을 사용할 수도 있다.
 
-또 다른 기준도 있다. `--author` 옵션으로 저자를 지정하여 검색할 수도 있고 `--grep` 옵션으로 커밋 메시지에서 키워드를 검색할 수도 있다(author와 grep 옵션을 나눠서 지정하고 싶지 않으면 `--all-match` 옵션으로 한 번에 검색할 수 있다).  
+또 다른 기준도 있다. `--author` 옵션으로 저자를 지정하여 검색할 수도 있고 `--grep` 옵션으로 커밋 메시지에서 키워드를 검색할 수도 있다(author와 grep 옵션을 함께 사용하면 모두 만족하는 커밋을 찾는다).
+
+grep 옵션을 여러개 사용하면 그중 하나이상 만족하는 커밋을 찾는다. 모두 만족하는 커밋을 찾으려면 `--all-match` 옵션을 추가해야 한다.
 
 마지막으로 파일 경로로 검색하는 옵션이 있는데 이것도 정말 유용하다. 디렉토리나 파일 이름을 사용하여 그 파일이 변경된 log의 결과를 검색할 수 있다. 이 옵션은 `--`와 함께 경로 이름을 사용하는데 명령어 끝 부분에 쓴다(역주, `git log -- path1 path2`).
 
@@ -701,31 +707,32 @@ Insert 18333fig0202.png
 
 	$ git add .
 	$ git status
-	# On branch master
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#       modified:   README.txt
-	#       modified:   benchmarks.rb
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        modified:   README.txt
+	        modified:   benchmarks.rb
+	
 
 `Changes to be commited` 밑에 `git reset HEAD <file>...`이라는 문장을 볼 수 있다. 이 명령으로 Unstage 상태로 변경할 수 있다. benchmarks.rb 파일을 Unstage 상태로 변경해보자:
 
 	$ git reset HEAD benchmarks.rb
-	benchmarks.rb: locally modified
+	Unstaged changes after reset:
+	M       benchmarks.rb
 	$ git status
-	# On branch master
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#       modified:   README.txt
-	#
-	# Changes not staged for commit:
-	#   (use "git add <file>..." to update what will be committed)
-	#   (use "git checkout -- <file>..." to discard changes in working directory)
-	#
-	#       modified:   benchmarks.rb
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        modified:   README.txt
+	
+	Changes not staged for commit:
+	  (use "git add <file>..." to update what will be committed)
+	  (use "git checkout -- <file>..." to discard changes in working directory)
+	
+	        modified:   benchmarks.rb
+	
 
 명령어가 낮설게 느껴질 수도 있지만 잘 동작한다. benchmarks.rb 파일은 Unstage 상태가 됐다.
 
@@ -733,23 +740,23 @@ Insert 18333fig0202.png
 
 어떻게 해야 benchmarks.rb 파일을 수정하고 나서 다시 되돌릴 수 있을까? 그러니까 최근 커밋된 버전으로(아니면 처음 Clone했을 때처럼 워킹 디렉토리에 처음 Checkout 한 그 내용으로) 되돌리는 방법이 무얼까? `git status` 명령이 친절하게 알려준다. 바로 위에 있는 예제에서 Unstaged 부분을 보자:
 
-	# Changes not staged for commit:
-	#   (use "git add <file>..." to update what will be committed)
-	#   (use "git checkout -- <file>..." to discard changes in working directory)
-	#
-	#       modified:   benchmarks.rb
-	#
+	Changes not staged for commit:
+	  (use "git add <file>..." to update what will be committed)
+	  (use "git checkout -- <file>..." to discard changes in working directory)
+	
+	        modified:   benchmarks.rb
+	
 
 위의 메시지는 수정한 파일을 되돌리는 방법을 꽤 정확하게 알려준다(적어도 Git 1.6.1이후 버전부터는 그렇다. 만약 예전 것을 아직 사용하고 있으면 업그레드하는 것이 좋다. 편의성이 많이 개선됐다). 알려주는 대로 한 번 해보자:
 
 	$ git checkout -- benchmarks.rb
 	$ git status
-	# On branch master
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#       modified:   README.txt
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        modified:   README.txt
+	
 
 정상적으로 복원된 것을 알 수 있다. 하지만 이 명령은 꽤 위험한 명령이라는 것을 알아야 한다. 수정 이전의 파일로 덮어썼기 때문에 수정했던 내용은 전부 사라진다. 수정한 내용이 진짜 마음에 들지 않을 때에만 사용하자. 정말 이렇게 삭제해야 한다면 Stash와 Branch를 사용하자. 다음 장에서 다루는 이 방법들이 훨씬 낫다.
 
@@ -764,12 +771,12 @@ Git으로 커밋한 모든 것은 언제나 복구할 수 있다. 삭제한 브
 `git remote` 명령으로 현재 프로젝트에 등록된 리모트 저장소를 확인할 수 있다. 이 명령은 리모트 저장소의 단축 이름을 보여준다. 저장소를 Clone하면 origin이라는 리모트 저장소가 자동으로 등록되기 때문에 origin이라는 이름을 볼 수 있다:
 
 	$ git clone git://github.com/schacon/ticgit.git
-	Initialized empty Git repository in /private/tmp/ticgit/.git/
-	remote: Counting objects: 595, done.
-	remote: Compressing objects: 100% (269/269), done.
-	remote: Total 595 (delta 255), reused 589 (delta 253)
-	Receiving objects: 100% (595/595), 73.31 KiB | 1 KiB/s, done.
-	Resolving deltas: 100% (255/255), done.
+	Cloning into 'ticgit'...
+	remote: Reusing existing pack: 1857, done.
+	remote: Total 1857 (delta 0), reused 0 (delta 0)
+	Receiving objects: 100% (1857/1857), 374.35 KiB | 193.00 KiB/s, done.
+	Resolving deltas: 100% (772/772), done.
+	Checking connectivity... done.
 	$ cd ticgit
 	$ git remote
 	origin
@@ -942,6 +949,7 @@ Annotated 태그를 만드는 방법은 간단하다. `tag` 명령을 실행할
 	Date:   Mon Feb 9 14:45:11 2009 -0800
 
 	my version 1.4
+	
 	commit 15027957951b64cf874c3557a0f3547bd83b3ff6
 	Merge: 4a447f7... a6b4c97...
 	Author: Scott Chacon <schacon@gee-mail.com>
diff --git a/ko/03-git-branching/01-chapter3.markdown b/ko/03-git-branching/01-chapter3.markdown
index cf5dade52..6b52978ce 100644
--- a/ko/03-git-branching/01-chapter3.markdown
+++ b/ko/03-git-branching/01-chapter3.markdown
@@ -104,7 +104,7 @@ Insert 18333fig0309.png
 
 이때 중요한 문제가 생겨서 그것을 해결하는 Hotfix를 먼저 만들어야 한다. 그러면 다음과 같이 할 수 있다:
 
-1. 새로운 이슈를 처리하기 이전의 운영(Production) 브랜치로 복원.
+1. 새로운 이슈를 처리하기 이전의 운영(Production) 브랜치로 이동.
 2. Hotfix 브랜치를 새로 하나 생성.
 3. 수정한 Hotfix 테스트를 마치고 운영 브랜치로 Merge.
 4. 다시 작업하던 브랜치로 옮겨가서 하던 일 진행.
@@ -154,8 +154,8 @@ hotfix라는 브랜치를 만들고 새로운 이슈를 해결할 때까지 사
 	Switched to a new branch 'hotfix'
 	$ vim index.html
 	$ git commit -a -m 'fixed the broken email address'
-	[hotfix]: created 3a0874c: 'fixed the broken email address'
-	 1 files changed, 0 insertions(+), 1 deletions(-)
+	[hotfix 3a0874c] fixed the broken email address
+	 1 files changed, 1 deletion(-)
 
 Insert 18333fig0313.png
 그림 3-13. master 브랜치에서 갈라져 나온 hotfix 브랜치
@@ -165,11 +165,11 @@ Insert 18333fig0313.png
 	$ git checkout master
 	$ git merge hotfix
 	Updating f42c576..3a0874c
-	Fast forward
-	 README |    1 -
-	 1 files changed, 0 insertions(+), 1 deletions(-)
+	Fast-forward
+	 README | 1 -
+	 1 file changed, 1 deletion(-)
 
-Merge 메시지에서 'Fast forward'가 보이는가? Merge할 브랜치가 가리키고 있던 커밋이 현 브랜치가 가리키는 것보다 '앞으로 진행한' 커밋이기 때문에 master 브랜치 포인터는 최신 커밋으로 이동한다. 이런 Merge 방식을 'Fast forward'라고 부른다. 다시 말해서 A 브랜치에서 다른 B 브랜치를 Merge할 때 B가 A 이후의 커밋을 가리키고 있으면 그저 A가 B의 커밋을 가리키게 할 뿐이다.
+Merge 메시지에서 'Fast-forward'가 보이는가? Merge할 브랜치가 가리키고 있던 커밋이 현 브랜치가 가리키는 것보다 '앞으로 진행한' 커밋이기 때문에 master 브랜치 포인터는 최신 커밋으로 이동한다. 이런 Merge 방식을 'Fast forward'라고 부른다. 다시 말해서 A 브랜치에서 다른 B 브랜치를 Merge할 때 B가 A 이후의 커밋을 가리키고 있으면 그저 A가 B의 커밋을 가리키게 할 뿐이다.
 
 이제 hotfix는 master 브랜치에 포함됐고 운영환경에 적용할 수 있다(그림 3-14).
 
@@ -179,7 +179,7 @@ Insert 18333fig0314.png
 문제를 급히 해결하고 master 브랜치에 적용하고 나면 다시 일하던 브랜치로 돌아가야 한다. 하지만, 그전에 필요없는 hotfix 브랜치를 삭제한다. `git branch` 명령에 `-d` 옵션을 주고 브랜치를 삭제한다.
 
 	$ git branch -d hotfix
-	Deleted branch hotfix (3a0874c).
+	Deleted branch hotfix (was 3a0874c).
 
 자 이제 이슈 53번을 처리하던 환경으로 되돌아가서 하던 일을 계속 하자(그림 3-15):
 
@@ -187,8 +187,8 @@ Insert 18333fig0314.png
 	Switched to branch 'iss53'
 	$ vim index.html
 	$ git commit -a -m 'finished the new footer [issue 53]'
-	[iss53]: created ad82d7a: 'finished the new footer [issue 53]'
-	 1 files changed, 1 insertions(+), 0 deletions(-)
+	[iss53 ad82d7a] finished the new footer [issue 53]
+	 1 file changed, 1 insertion(+)
 
 Insert 18333fig0315.png
 그림 3-15. master와 별개로 진행하는 iss53 브랜치
@@ -201,9 +201,10 @@ Insert 18333fig0315.png
 
 	$ git checkout master
 	$ git merge iss53
-	Merge made by recursive.
-	 README |    1 +
-	 1 files changed, 1 insertions(+), 0 deletions(-)
+	Auto-merging README
+	Merge made by the 'recursive' strategy.
+	 README | 1 +
+	 1 file changed, 1 insertion(+)
 
 hotfix를 Merge했을 때와 메시지가 다르다. 현 브랜치가 가리키는 커밋이 Merge할 브랜치의 조상이 아니므로 Git은 'Fast-forward'로 Merge하지 않는다. 이러면 Git은 각 브랜치가 가리키는 커밋 두 개와 공통 조상 하나를 사용하여 3-way Merge를 한다. 그림 3-16에 이 Merge에서 사용하는 커밋 세 개가 표시된다.
 
@@ -232,25 +233,27 @@ iss53 브랜치를 master에 Merge하고 나면 더는 iss53 브랜치가 필요
 
 Git은 자동으로 Merge하지 못해서 새 커밋이 생기지 않는다. 변경사항의 충돌을 개발자가 해결하지 않는 한 Merge 과정을 진행할 수 없다. Merge 충돌이 일어났을 때 Git이 어떤 파일을 Merge할 수 없었는지 살펴보려면 `git status` 명령을 이용한다:
 
-	[master*]$ git status
-	index.html: needs merge
-	# On branch master
-	# Changes not staged for commit:
-	#   (use 'git add <file>...' to update what will be committed)
-	#   (use 'git checkout -- <file>...' to discard changes in working directory)
-	#
-	#	unmerged:   index.html
-	#
+	$ git status
+	On branch master
+	You have unmerged paths.
+	  (fix conflicts and run "git commit")
+	
+	Unmerged paths:
+	  (use "git add <file>..." to mark resolution)
+	
+	        both modified:      index.html
+	
+	no changes added to commit (use "git add" and/or "git commit -a")
 
 충돌이 일어난 파일은 unmerged 상태로 표시된다. Git은 충돌이 난 부분을 표준 형식에 따라 표시해준다. 그러면 개발자는 해당 부분을 수동으로 해결한다. 충돌 난 부분은 다음과 같이 표시된다.
 
-	<<<<<<< HEAD:index.html
+	<<<<<<< HEAD
 	<div id='footer'>contact : email.support@github.com</div>
 	=======
 	<div id='footer'>
 	  please contact us at support@github.com
 	</div>
-	>>>>>>> iss53:index.html
+	>>>>>>> iss53
 
 `=======` 위쪽의 내용은 HEAD 버전(merge 명령을 실행할 때 작업하던 master 브랜치)의 내용이고 아래쪽은 iss53 브랜치의 내용이다. 충돌을 해결하려면 위쪽이나 아래쪽 내용 중에서 고르거나 새로 작성하여 Merge한다. 다음은 아예 새로 작성하여 충돌을 해결하는 예제다:
 
@@ -261,27 +264,32 @@ Git은 자동으로 Merge하지 못해서 새 커밋이 생기지 않는다. 변
 충돌한 양쪽에서 조금씩 가져와서 새로 수정했다. 그리고 `<<<<<<<`, `=======`, `>>>>>>>` 가 포함된 행을 삭제하였다. 이렇게 충돌한 부분을 해결하고 `git add` 명령으로 다시 Git에 저장한다. 충돌을 쉽게 해결하기 위해 다른 Merge 도구도 이용할 수 있다. `git mergetool` 명령으로 실행한다:
 
 	$ git mergetool
-	merge tool candidates: kdiff3 tkdiff xxdiff meld gvimdiff opendiff emerge vimdiff
-	Merging the files: index.html
+
+	This message is displayed because 'merge.tool' is not configured.
+	See 'git mergetool --tool-help' or 'git help config' for more details.
+	'git mergetool' will now attempt to use one of the following tools:
+	opendiff kdiff3 tkdiff xxdiff meld tortoisemerge gvimdiff diffuse diffmerge ecmerge p4merge araxis bc3 codecompare vimdiff emerge
+	Merging:
+	index.html
 
 	Normal merge conflict for 'index.html':
-	  {local}: modified
-	  {remote}: modified
+	  {local}: modified file
+	  {remote}: modified file
 	Hit return to start merge resolution tool (opendiff):
 
-Mac에서는 `opendiff`가 실행된다. 기본 도구 말고 사용할 수 있는 다른 Merge 도구도 있는데, 'merge tool candidates' 부분에 보여준다. 여기에 표시된 도구 중 하나를 고를 수 있다. Merge 도구를 변경하는 방법은 *7장*에서 다룬다.
+Mac에서는 `opendiff`가 실행된다. 기본 도구 말고 사용할 수 있는 다른 Merge 도구도 있는데, "... one of the following tools:" 부분에 보여준다. 여기에 표시된 도구 중 하나를 고를 수 있다. Merge 도구를 변경하는 방법은 *7장*에서 다룬다.
 
 Merge 도구를 종료하면 Git은 잘 Merge했는지 물어본다. 잘 마쳤다고 입력하면 자동으로 `git add`가 수행되고 해당 파일이 Staging Area에 저장된다.
 
 `git status` 명령으로 충돌이 해결된 상태인지 다시 한번 확인해볼 수 있다.
 
 	$ git status
-	# On branch master
-	# Changes to be committed:
-	#   (use 'git reset HEAD <file>...' to unstage)
-	#
-	#	modified:   index.html
-	#
+	On branch master
+	Changes to be committed:
+	  (use 'git reset HEAD <file>...' to unstage)
+	
+	        modified:   index.html
+	
 
 충돌을 해결하고 나서 해당 파일이 Staging Area에 저장됐는지 확인했으면 `git commit` 명령으로 Merge 한 것을 커밋한다. 충돌을 해결하고 Merge할 때에는 커밋 메시지가 아래와 같다.
 
@@ -290,9 +298,9 @@ Merge 도구를 종료하면 Git은 잘 Merge했는지 물어본다. 잘 마쳤
 	Conflicts:
 	  index.html
 	#
-	# It looks like you may be committing a MERGE.
+	# It looks like you may be committing a merge.
 	# If this is not correct, please remove the file
-	# .git/MERGE_HEAD
+	#       .git/MERGE_HEAD
 	# and try again.
 	#
 
@@ -332,7 +340,7 @@ iss53 브랜치는 앞에서 이미 Merge했기 때문에 목록에 나타난다
 위에는 없었던 다른 브랜치가 보인다. 아직 Merge하지 않은 커밋을 담고 있기 때문에 `git branch -d` 명령으로 삭제되지 않는다:
 
 	$ git branch -d testing
-	error: The branch 'testing' is not an ancestor of your current HEAD.
+	error: The branch 'testing' is not fully merged.
 	If you are sure you want to delete it, run 'git branch -D testing'.
 
 Merge하지 않은 브랜치를 강제로 삭제하려면 `-D` 옵션으로 삭제한다.
@@ -445,7 +453,7 @@ Git은 serverfix라는 브랜치 이름을 `refs/heads/serverfix:refs/heads/serv
 새로 받은 브랜치의 내용을 Merge하려면 `git merge origin/serverfix` 명령을 사용한다. Merge하지 않고 리모트 브랜치에서 시작하는 새 브랜치를 만들려면 아래와 같은 명령을 사용한다.
 
 	$ git checkout -b serverfix origin/serverfix
-	Branch serverfix set up to track remote branch refs/remotes/origin/serverfix.
+	Branch serverfix set up to track remote branch serverfix from origin.
 	Switched to a new branch 'serverfix'
 
 그러면 origin/serverfix에서 시작하고 수정할 수 있는 serverfix라는 로컬 브랜치가 만들어진다.
@@ -457,16 +465,16 @@ Git은 serverfix라는 브랜치 이름을 `refs/heads/serverfix:refs/heads/serv
 서버로부터 저장소를 Clone해올 때도 Git은 자동으로 master 브랜치를 origin/master 브랜치의 트래킹 브랜치로 만든다. 그래서 `git push`, `git pull` 명령이 추가적인 아규먼트 없이도 동작한다. 트래킹 브랜치를 직접 만들 수 있는데 origin/master뿐만 아니라 다른 저장소의 다른 브랜치도 추적하게(Tracking) 할 수 있다. `git checkout -b [branch] [remotename]/[branch]` 명령으로 간단히 트래킹 브랜치를 만들 수 있다. Git 1.6.2 버전 이상을 사용하는 경우에는  --track 옵션도 사용할 수 있다.
 
 	$ git checkout --track origin/serverfix
-	Branch serverfix set up to track remote branch refs/remotes/origin/serverfix.
+	Branch serverfix set up to track remote branch serverfix from origin.
 	Switched to a new branch 'serverfix'
 
 리모트 브랜치와 다른 이름으로 브랜치를 만들려면 로컬 브랜치의 이름을 아래와 같이 다르게 지정한다:
 
 	$ git checkout -b sf origin/serverfix
-	Branch sf set up to track remote branch refs/remotes/origin/serverfix.
+	Branch sf set up to track remote branch serverfix from origin.
 	Switched to a new branch 'sf'
 
-이제 sf 브랜치에서 Push나 Pull하면 자동으로 origin/serverfix에 데이터를 보내거나 가져온다.
+이제 `sf` 브랜치에서 Push나 Pull하면 자동으로 `origin/serverfix`에 데이터를 보내거나 가져온다.
 
 ### 리모트 브랜치 삭제 ###
 
diff --git a/ko/04-git-server/01-chapter4.markdown b/ko/04-git-server/01-chapter4.markdown
index 1f57aa7b7..ff28be894 100644
--- a/ko/04-git-server/01-chapter4.markdown
+++ b/ko/04-git-server/01-chapter4.markdown
@@ -26,7 +26,7 @@ HTTP 프로토콜을 제외한 나머지들은 모두 Git이 서버에 설치돼
 
 	$ git clone file:///opt/git/project.git
 
-Git은 파일 경로를 직접 쓸 때와 `file://`로 시작하는 URL을 사용할 때에 약간 다르게 처리한다. 디렉토리 경로를 그대로 사용하면 Git은 필요한 파일을 직접 복사하거나 하드 링크를 사용한다. 하지만 `file://`로 시작하면 Git은 네트워크를 통해서 데이터를 전송할 때처럼 프로세스를 별도로 생성하여 처리한다. 이 프로세스로 데이터를 전송하는 것은 효율이 좀 떨어지지만 그래도 `file://`를 사용하는 이유가 있다. 보통은 다른 버전 관리 시스템들에서 임포트한 후에 이렇게 사용하는데, 외부 레퍼런스나 개체들이 포함된 저장소의 복사본을 깨끗한 상태로 남겨두고자 할때 사용한다(*9장*에서 자세히 다룬다). 여기서는 속도가 빠른 디렉토리 경로를 사용한다.
+Git은 파일 경로를 직접 쓸 때와 `file://`로 시작하는 URL을 사용할 때에 약간 다르게 처리한다. 디렉토리 경로를 사용해서 같은 파일시스템에 있는 저장소를 Clone할 때 Git은 하드링크를 만든다. 같은 파일시스템에 있는게 아니면 그냥 복사한다. 하지만 `file://`로 시작하면 Git은 네트워크를 통해서 데이터를 전송할 때처럼 프로세스를 별도로 생성하여 처리한다. 이 프로세스로 데이터를 전송하는 것은 효율이 좀 떨어지지만 그래도 `file://`를 사용하는 이유가 있다. 보통은 다른 버전 관리 시스템들에서 임포트한 후에 이렇게 사용하는데, 외부 레퍼런스나 개체들이 포함된 저장소의 복사본을 깨끗한 상태로 남겨두고자 할때 사용한다(*9장*에서 자세히 다룬다). 여기서는 속도가 빠른 디렉토리 경로를 사용한다.
 
 이미 있는 Git 프로젝트에서 아래와 같이 로컬 저장소를 추가한다:
 
@@ -70,7 +70,7 @@ SSH의 단점은 익명으로 접근할 수 없다는 것이다. 심지어 읽
 
 ### Git 프로토콜 ###
 
-Git 프로토콜은 Git에 포함된 데몬을 사용하는 방법이다. 포트는 9418이며 SSH 프로토콜과 비슷한 서비스를 제공하지만, 인증 메커니즘이 없다. 저장소에 git-daemon-export-ok 파일을 만들면 Git 프로토콜로 서비스할 수 있지만, 보안은 없다. 이 파일이 없는 저장소는 Git 프로토콜로 서비스할 수 없다. 이 저장소는 누구나 Clone할 수 있거나 아무도 Clone할 수 없거나 둘 중의 하나만 선택할 수 있다. 그래서 이 프로토콜로는 Push 가능하게 설정할 수 없다. 엄밀히 말해서 Push할 수 있도록 설정할 수 있지만, 인증하도록 할 수 없다. 그러니까 당신이 Push할 수 있으면 이 프로젝트의 URL을 아는 사람은 누구나 Push할 수 있다. 그냥 이런 것도 있지만 잘 안 쓴다고 알고 있으면 된다.
+Git 프로토콜은 Git에 포함된 데몬을 사용하는 방법이다. 포트는 9418이며 SSH 프로토콜과 비슷한 서비스를 제공하지만, 인증 메커니즘이 없다. 저장소에 git-export-daemon-ok 파일을 만들면 Git 프로토콜로 서비스할 수 있지만, 보안은 없다. 이 파일이 없는 저장소는 Git 프로토콜로 서비스할 수 없다. 이 저장소는 누구나 Clone할 수 있거나 아무도 Clone할 수 없거나 둘 중의 하나만 선택할 수 있다. 그래서 이 프로토콜로는 Push 가능하게 설정할 수 없다. 엄밀히 말해서 Push할 수 있도록 설정할 수 있지만, 인증하도록 할 수 없다. 그러니까 당신이 Push할 수 있으면 이 프로젝트의 URL을 아는 사람은 누구나 Push할 수 있다. 그냥 이런 것도 있지만 잘 안 쓴다고 알고 있으면 된다.
 
 #### 장점 ####
 
@@ -115,7 +115,13 @@ HTTP는 매우 보편적인 프로토콜이라서 거의 모든 회사가 트래
 어떤 서버를 설치하더라도 일단 저장소를 Bare 저장소로 만들어야 한다. 다시 말하지만, Bare 저장소는 워킹 디렉토리가 없는 저장소이다. `--bare` 옵션을 주고 Clone하면 새로운 Bare 저장소가 만들어진다. Bare 저장소 디렉토리는 관례에 따라. git 확장자로 끝난다:
 
 	$ git clone --bare my_project my_project.git
-	Initialized empty Git repository in /opt/projects/my_project.git/
+	Cloning into bare repository 'my_project.git'...
+	done.
+
+<!-- This next part doesn't fit the actual output as shown, the confusing part
+     of the output is no longer shown in the command output. I would like to asks
+     the original author to modify the text.
+-->
 
 이 명령이 출력하는 메시지가 조금 이상해보일 수도 있다.  사실 `git clone` 명령은 `git init`을 하고 나서 `git fetch`를 실행한다. 그런데 빈 디렉토리밖에 만들지 않는 `git init` 명령의 메시지만 보여준다. 개체 전송에 관련된 메시지는 아무것도 보여주지 않는다. 전송 메시지를 보여주지 않지만 `my_project.git` 디렉토리를 보면 Git 데이터가 들어 있다.
 
@@ -282,6 +288,13 @@ something, something.pub이라는 형식으로 된 파일을 볼 수 있다. som
 
 	$ cat .git/hooks/post-update
 	#!/bin/sh
+	#
+	# An example hook script to prepare a packed repository for use over
+	# dumb transports.
+	#
+	# To enable this hook, rename this file to "post-update".
+	#
+	
 	exec git-update-server-info
 
 SSH를 통해서 서버에 Push하면 Git은 이 명령어를 실행하여 HTTP를 통해서도 Fetch할 수 있도록 파일를 갱신한다.
@@ -363,7 +376,7 @@ Gitosis는 Python이 필요하기 때문에 먼저 Python setuptools 패키지
 
 그리고 Gitosis 프로젝트 사이트에서 Gitosis를 Clone한 후 설치한다:
 
-	$ git clone git://eagain.net/gitosis.git
+	$ git clone https://github.com/tv42/gitosis.git
 	$ cd gitosis
 	$ sudo python setup.py install
 
@@ -397,6 +410,7 @@ Gitosis가 키들을 관리할 것이기 때문에 현재 파일은 삭제하고
 
 	$ ssh git@gitserver
 	PTY allocation request failed on channel 0
+	ERROR:gitosis.serve.main:Need SSH_ORIGINAL_COMMAND in environment.
 	fatal: unrecognized command 'gitosis-serve schacon@quaternion'
 	  Connection to gitserver closed.
 
@@ -421,8 +435,8 @@ Gitosis가 키들을 관리할 것이기 때문에 현재 파일은 삭제하고
 	[gitosis]
 
 	[group gitosis-admin]
-	writable = gitosis-admin
 	members = scott
+	writable = gitosis-admin
 
 scott이라는 사용자는 Gitosis를 초기화할 때 사용한 공개키의 사용자이다. 이 사용자만 `gitosis-admin` 프로젝트에 접근할 수 있다.
 
@@ -435,14 +449,14 @@ scott이라는 사용자는 Gitosis를 초기화할 때 사용한 공개키의 
 `gitosis-admin` 프로젝트를 수정하면 커밋하고 서버에 Push해야 수정한 설정이 적용된다:
 
 	$ git commit -am 'add iphone_project and mobile group'
-	[master]: created 8962da8: "changed name"
-	 1 files changed, 4 insertions(+), 0 deletions(-)
-	$ git push
+	[master 8962da8] add iphone_project and mobile group
+	 1 file changed, 4 insertions(+)
+	$ git push origin master
 	Counting objects: 5, done.
-	Compressing objects: 100% (2/2), done.
-	Writing objects: 100% (3/3), 272 bytes, done.
-	Total 3 (delta 1), reused 0 (delta 0)
-	To git@gitserver:/opt/git/gitosis-admin.git
+	Compressing objects: 100% (3/3), done.
+	Writing objects: 100% (3/3), 272 bytes | 0 bytes/s, done.
+	Total 3 (delta 0), reused 0 (delta 0)
+	To git@gitserver:gitosis-admin.git
 	   fb27aec..8962da8  master -> master
 
 로컬에 있는 `iphone_project` 프로젝트에 이 서버를 리모트 저장소로 추가하고 Push하면 서버에 새로운 저장소가 추가된다. 서버에 프로젝트를 새로 만들 때 이제는 수동으로 Bare 저장소를 만들 필요가 없다. 처음 Push할 때 Gitosis가 알아서 생성해 준다:
@@ -451,7 +465,7 @@ scott이라는 사용자는 Gitosis를 초기화할 때 사용한 공개키의 
 	$ git push origin master
 	Initialized empty Git repository in /opt/git/iphone_project.git/
 	Counting objects: 3, done.
-	Writing objects: 100% (3/3), 230 bytes, done.
+> Writing objects: 100% (3/3), 230 bytes | 0 bytes/s, done.
 	Total 3 (delta 0), reused 0 (delta 0)
 	To git@gitserver:iphone_project.git
 	 * [new branch]      master -> master
@@ -467,20 +481,20 @@ Gitosis를 이용할 때에는 저장소 경로를 명시할 필요도 없고 
 이 세 사람을 모두 mobile 팀으로 추가하여 `iphone_project` 에 대한 읽기, 쓰기를 허용한다:
 
 	[group mobile]
-	writable = iphone_project
 	members = scott john josie jessica
+	writable = iphone_project
 
 이 파일을 커밋하고 Push하고 나면 네 명 모두 `iphone_project`를 읽고 쓸 수 있게 된다.
 
 Gitosis의 접근제어 방법은 매우 단순하다. 만약 이 프로젝트에 대해서 John은 읽기만 가능하도록 설정하려면 아래와 같이 한다:
 
 	[group mobile]
-	writable = iphone_project
 	members = scott josie jessica
+	writable = iphone_project
 
 	[group mobile_ro]
-	readonly = iphone_project
 	members = john
+	readonly = iphone_project
 
 이제 John은 프로젝트를 Clone하거나 Fetch할 수는 있지만, 프로젝트에 Push할 수는 없다. 다양한 사용자와 프로젝트가 있어도 필요한 만큼 그룹을 만들어 사용하면 된다. 그리고 members 항목에 사용자 대신 그룹명을 사용할 수도 있다. 그룹명 앞에 `@`를 붙이면 그 그룹의 사용자를 그대로 상속한다:
 
@@ -488,12 +502,12 @@ Gitosis의 접근제어 방법은 매우 단순하다. 만약 이 프로젝트
 	members = scott josie jessica
 
 	[group mobile]
-	writable  = iphone_project
 	members   = @mobile_committers
+	writable  = iphone_project
 
 	[group mobile_2]
-	writable  = another_iphone_project
 	members   = @mobile_committers john
+	writable  = another_iphone_project
 
 `[gitosis]` 절에 `loglevel=DEBUG`라고 적으면 문제가 생겼을 때 해결하는데 도움이 된다. 그리고 설정이 꼬여버려서 Push할 수 없게 되면 서버에 있는 파일을 수동으로 고쳐도 된다. Gitosis는 `/home/git/.gitosis.conf` 파일의 정보를 읽기 때문에 이 파일을 고친다. `gitosis.conf`는 Push할 때 그 위치로 복사되기 때문에 수동으로 고친 파일은 `gitosis-admin` 프로젝트가 다음에 Push될 때까지 유지된다.
 
diff --git a/ko/05-distributed-git/01-chapter5.markdown b/ko/05-distributed-git/01-chapter5.markdown
index 11ec5df3c..acbe5dc68 100644
--- a/ko/05-distributed-git/01-chapter5.markdown
+++ b/ko/05-distributed-git/01-chapter5.markdown
@@ -169,7 +169,7 @@ John씨는 Jessica씨가 저장소로 Push했던 커밋과 를 로컬 저장소
 Merge가 잘 이루어지면 John씨의 브랜치는 그림 5-5와 같은 상태가 된다.
 
 Insert 18333fig0505.png
-그림 5-5. origin/master 브랜치를 Merge하고 난 후, John씨의 저장소
+그림 5-5. `origin/master` 브랜치를 Merge하고 난 후, John씨의 저장소
 
 John씨는 Merge하고 나서 자신이 작업한 코드가 제대로 동작하는지 확인한다. 그 후에 공유하는 저장소에 Push한다:
 
@@ -210,13 +210,13 @@ Insert 18333fig0508.png
 
 	    removed invalid default value
 
-Merge할 내용을 확인한 Jessica씨는 자신이 작업한 내용과 John씨가 Push한 작업(origin/master)을 master 브랜치에 Merge하고 Push한다. 모든 내용을 합치기 전에 우선 master 브랜치를 Checkout한다:
+Merge할 내용을 확인한 Jessica씨는 자신이 작업한 내용과 John씨가 Push한 작업(`origin/master`)을 `master` 브랜치에 Merge하고 Push한다. 모든 내용을 합치기 전에 우선 `master` 브랜치를 Checkout한다:
 
 	$ git checkout master
 	Switched to branch "master"
 	Your branch is behind 'origin/master' by 2 commits, and can be fast-forwarded.
 
-origin/master, issue54 모두 master보다 Fast-forward된 브랜치이기 때문에 둘 중에 무엇을 먼저 Merge하든 상관이 없다. 물론 어떤 것을 먼저 Merge하느냐에 따라 히스토리 순서는 달라지지만, 최종 결과는 똑같다. Jessica씨는 먼저 issue54 브랜치를 Merge한다:
+`origin/master`, `issue54` 모두 `master`보다 Fast-forward된 브랜치이기 때문에 둘 중에 무엇을 먼저 Merge하든 상관이 없다. 물론 어떤 것을 먼저 Merge하느냐에 따라 히스토리 순서는 달라지지만, 최종 결과는 똑같다. Jessica씨는 먼저 `issue54` 브랜치를 Merge한다:
 
 	$ git merge issue54
 	Updating fbff5bc..4af4298
@@ -225,7 +225,7 @@ origin/master, issue54 모두 master보다 Fast-forward된 브랜치이기 때
 	 lib/simplegit.rb |    6 +++++-
 	 2 files changed, 6 insertions(+), 1 deletions(-)
 
-보다시피 Fast-forward Merge이기 때문에 별 문제 없이 실행된다. 다음은 John씨의 커밋(origin/master)을 Merge한다:
+보다시피 Fast-forward Merge이기 때문에 별 문제 없이 실행된다. 다음은 John씨의 커밋(`origin/master`)을 Merge한다:
 
 	$ git merge origin/master
 	Auto-merging lib/simplegit.rb
@@ -238,7 +238,7 @@ origin/master, issue54 모두 master보다 Fast-forward된 브랜치이기 때
 Insert 18333fig0509.png
 그림 5-9. Merge 이후 Jessica씨의 저장소
 
-origin/master 브랜치가 Jessica씨의 master 브랜치로 나아갈(reachable) 수 있기 때문에 Push는 성공한다(물론 John씨가 그 사이에 Push를 하지 않았다면):
+`origin/master` 브랜치가 Jessica씨의 `master` 브랜치로 나아갈(reachable) 수 있기 때문에 Push는 성공한다(물론 John씨가 그 사이에 Push를 하지 않았다면):
 
 	$ git push origin master
 	...
@@ -250,7 +250,7 @@ origin/master 브랜치가 Jessica씨의 master 브랜치로 나아갈(reachable
 Insert 18333fig0510.png
 그림 5-10. Jessica씨가 서버로 Push하고 난 후의 저장소
 
-여기서 살펴본 예제가 가장 간단한 상황이다. 토픽 브랜치에서 수정하고 로컬의 master 브랜치에 Merge한다. 작업한 내용을 프로젝트의 공유 저장소에 Push하고자 할 때에는 우선 origin/master 브랜치를 Fetch하고 Merge한다. 그리고 나서 Merge한 결과를 다시 서버로 Push한다. 이런 Workflow가 일반적이고 그림 5-11로 나타낼 수 있다.
+여기서 살펴본 예제가 가장 간단한 상황이다. 토픽 브랜치에서 수정하고 로컬의 `master` 브랜치에 Merge한다. 작업한 내용을 프로젝트의 공유 저장소에 Push하고자 할 때에는 우선 `origin/master` 브랜치를 Fetch하고 Merge한다. 그리고 나서 Merge한 결과를 다시 서버로 Push한다. 이런 Workflow가 일반적이고 그림 5-11로 나타낼 수 있다.
 
 Insert 18333fig0511.png
 그림 5-11. 여러 개발자가 Git을 사용하는 Workflow
@@ -518,7 +518,7 @@ format-patch 명령을 실행하면 생성한 파일 이름을 보여준다. -M
 
 다행히 Git에는 Patch 메일을 그대로 보낼 수 있는 도구가 있다. IMAP 프로토콜로 보낸다. 저자가 사용하는 방법으로 Gmail을 사용하여 Patch 메일을 전송하는 방법을 살펴보자. 추가로 Git 프로젝트의 `Documentation/SubmittingPatches` 문서의 마지막 부분을 살펴보면 다양한 메일 프로그램으로 메일을 보내는 방법을 설명한다.
 
-메일을 보내려면 먼저 ~/.gitconfig 파일에서 이메일 부분 설정한다. `git config` 명령으로 추가할 수도 있고 직접 파일을 열어서 추가할 수도 있다. 아무튼, 아래와 같이 설정을 한다:
+메일을 보내려면 먼저 `~/.gitconfig` 파일에서 이메일 부분 설정한다. `git config` 명령으로 추가할 수도 있고 직접 파일을 열어서 추가할 수도 있다. 아무튼, 아래와 같이 설정을 한다:
 
 	[imap]
 	  folder = "[Gmail]/Drafts"
@@ -528,7 +528,26 @@ format-patch 명령을 실행하면 생성한 파일 이름을 보여준다. -M
 	  port = 993
 	  sslverify = false
 
-IMAP 서버가 SSL을 사용하지 않으면 마지막 두 줄은 필요 없고 host에서 `imaps://` 대신 `imap://`로 한다. 이렇게 설정하면 `git send-email` 명령으로 메일을 전송할 수 있다:
+IMAP 서버가 SSL을 사용하지 않으면 마지막 두 줄은 필요 없고 host에서 `imaps://` 대신 `imap://`로 한다. 이렇게 설정하면 `git imap-send` 명령으로 메일을 전송할 수 있다:
+
+	$ cat *.patch |git imap-send
+	Resolving imap.gmail.com... ok
+	Connecting to [74.125.142.109]:993... ok
+	Logging in...
+	sending 2 messages
+	100% (2/2) done
+
+이후 Gmail의 Draft 폴더로 가서 To 부분을 메일링리스트의 주소로 변경하고 CC 부분에 해당 메일을 참고해야 하는 관리자나 개발자의 메일 주소를 적고 실제로 전송한다.
+
+SMTP 서버로도 패치를 보낼 수 있다. `git config` 명령으로 설정을 하나씩 입력하거나 `~/.gitconfig` 파일의 sendmail 부분을 손으로 직접 수정한다:
+
+	[sendemail]
+	  smtpencryption = tls
+	  smtpserver = smtp.gmail.com
+	  smtpuser = user@gmail.com
+	  smtpserverport = 587
+
+이렇게 했으면 `git send-mail`로 패치를 보낸다:
 
 	$ git send-email *.patch
 	0001-added-limit-to-log-function.patch
@@ -555,8 +574,6 @@ Git으로 메일을 보내면 아래와 같은 로그 메시지가 출력된다:
 
 	Result: OK
 
-이후 Gmail의 Draft 폴더로 가서 To 부분을 메일링리스트의 주소로 변경하고 CC 부분에 해당 메일을 참고해야 하는 관리자나 개발자의 메일 주소를 적고 실제로 전송한다.
-
 ### 요약 ###
 
 이번 절에서는 다양한 Workflow에 따라 Git을 어떻게 사용하는 지 살펴보고 그에 필요한 도구들을 설명했다. 다음 절에서는 동전의 뒷면인 프로젝트를 운영하는 방법에 대하여 살펴본다. 즉 친절한 Dictator나 Integration-Manager가 되어 보는 것이다.
diff --git a/ko/06-git-tools/01-chapter6.markdown b/ko/06-git-tools/01-chapter6.markdown
index af810484d..231d2dc8c 100644
--- a/ko/06-git-tools/01-chapter6.markdown
+++ b/ko/06-git-tools/01-chapter6.markdown
@@ -82,13 +82,13 @@ Git은 자동으로 브랜치와 HEAD가 지난 몇 달 동안에 가리켰었
 `git reflog`를 실행하면 Reflog를 볼 수 있다:
 
 	$ git reflog
-	734713b... HEAD@{0}: commit: fixed refs handling, added gc auto, updated
-	d921970... HEAD@{1}: merge phedders/rdocs: Merge made by recursive.
-	1c002dd... HEAD@{2}: commit: added some blame and merge stuff
-	1c36188... HEAD@{3}: rebase -i (squash): updating HEAD
-	95df984... HEAD@{4}: commit: # This is a combination of two commits.
-	1c36188... HEAD@{5}: rebase -i (squash): updating HEAD
-	7e05da5... HEAD@{6}: rebase -i (pick): updating HEAD
+	734713b HEAD@{0}: commit: fixed refs handling, added gc auto, updated
+	d921970 HEAD@{1}: merge phedders/rdocs: Merge made by recursive.
+	1c002dd HEAD@{2}: commit: added some blame and merge stuff
+	1c36188 HEAD@{3}: rebase -i (squash): updating HEAD
+	95df984 HEAD@{4}: commit: # This is a combination of two commits.
+	1c36188 HEAD@{5}: rebase -i (squash): updating HEAD
+	7e05da5 HEAD@{6}: rebase -i (pick): updating HEAD
 
 Git은 브랜치가 가리키는 것이 변경될 때마다 그 정보를 임시 영역에 저장한다. 그래서 예전에 뭘 가리켰었는지 확인할 수 있다. `@{n}` 규칙을 사용하면 아래와 같이 HEAD가 5번 전에 가리켰던 것을 알 수 있다:
 
@@ -442,8 +442,8 @@ Stash 명령을 사용하면 워킹 디렉토리에서 수정한 파일만 저
 
 	$ git stash list
 	stash@{0}: WIP on master: 049d078 added the index file
-	stash@{1}: WIP on master: c264051... Revert "added file_size"
-	stash@{2}: WIP on master: 21d80a5... added number to log
+	stash@{1}: WIP on master: c264051 Revert "added file_size"
+	stash@{2}: WIP on master: 21d80a5 added number to log
 
 Stash 두 개는 원래 있었던 것이다. 그래서 현재 총 세 개의 Stash를 사용할 수 있다. 이제 `git stash apply`를 사용하여 Stash를 적용할 수 있다. `git stash` 명령을 실행하면 이 명령에 대한 도움말을 보여주기 때문에 편리하다. 다른 Stash를 고르고 싶으면 Stash 이름을 입력해야 한다. 이름이 없으면 Git은 가장 최근의 Stash를 적용한다:
 
@@ -477,8 +477,8 @@ Git은 Stash를 적용할 때 Staged 상태였던 파일을 자동으로 다시
 
 	$ git stash list
 	stash@{0}: WIP on master: 049d078 added the index file
-	stash@{1}: WIP on master: c264051... Revert "added file_size"
-	stash@{2}: WIP on master: 21d80a5... added number to log
+	stash@{1}: WIP on master: c264051 Revert "added file_size"
+	stash@{2}: WIP on master: 21d80a5 added number to log
 	$ git stash drop stash@{0}
 	Dropped stash@{0} (364e91f3f268f0900bc3ee613f9f733e82aaed43)
 
@@ -562,12 +562,19 @@ Git으로 일하다 보면 어떤 이유로든 커밋 히스토리를 수정해
 	#
 	# Commands:
 	#  p, pick = use commit
+	#  r, reword = use commit, but edit the commit message
 	#  e, edit = use commit, but stop for amending
 	#  s, squash = use commit, but meld into previous commit
+	#  f, fixup = like "squash", but discard this commit's log message
+	#  x, exec = run command (the rest of the line) using shell
+	#
+	# These lines can be re-ordered; they are executed from top to bottom.
 	#
 	# If you remove a line here THAT COMMIT WILL BE LOST.
+	#
 	# However, if you remove everything, the rebase will be aborted.
 	#
+	# Note that empty commits are commented out
 
 이 커밋은 모두 `log` 명령과는 정반대의 순서로 나열된다. `log` 명령을 실행하면 아래와 같은 결과를 볼 수 있다:
 
@@ -586,6 +593,10 @@ Git으로 일하다 보면 어떤 이유로든 커밋 히스토리를 수정해
 
 저장하고 편집기를 종료하면 Git은 목록에 있는 커밋 중에서 가장 오래된 커밋으로 이동하고, 아래와 같은 메시지를 보여주고, 명령 프롬프트를 보여준다:
 
+<!-- This is actually weird, as the SHA-1 of 7482e0d is not present in the list, 
+nor is the commit message. Please review 
+-->
+
 	$ git rebase -i HEAD~3
 	Stopped at 7482e0d... updated the gemspec to hopefully work better
 	You can amend the commit now, with
@@ -628,12 +639,19 @@ Git으로 일하다 보면 어떤 이유로든 커밋 히스토리를 수정해
 	#
 	# Commands:
 	#  p, pick = use commit
+	#  r, reword = use commit, but edit the commit message
 	#  e, edit = use commit, but stop for amending
 	#  s, squash = use commit, but meld into previous commit
+	#  f, fixup = like "squash", but discard this commit's log message
+	#  x, exec = run command (the rest of the line) using shell
+	#
+	# These lines can be re-ordered; they are executed from top to bottom.
 	#
 	# If you remove a line here THAT COMMIT WILL BE LOST.
+	#
 	# However, if you remove everything, the rebase will be aborted.
 	#
+	# Note that empty commits are commented out
 
 "pick"이나 "edit"말고 "squash"를 입력하면 Git은 해당 커밋과 바로 이전 커밋을 합칠 것이고 커밋 메시지도 Merge한다. 그래서 3개의 커밋을 모두 합치려면 스크립트를 아래와 같이 수정한다:
 
diff --git a/ko/07-customizing-git/01-chapter7.markdown b/ko/07-customizing-git/01-chapter7.markdown
index 8e363021f..901c2d27c 100644
--- a/ko/07-customizing-git/01-chapter7.markdown
+++ b/ko/07-customizing-git/01-chapter7.markdown
@@ -612,14 +612,12 @@ update 스크립트는 각 브랜치마다 한 번씩 실행된다는 것을 제
 
 	#!/usr/bin/env ruby
 
-	$refname = ARGV[0]
-	$oldrev  = ARGV[1]
-	$newrev  = ARGV[2]
-	$user    = ENV['USER']
-
-	puts "Enforcing Policies... \n(#{$refname}) (#{$oldrev[0,6]}) (#{$newrev[0,6]})"
+	refname = ARGV[0]
+	oldrev  = ARGV[1]
+	newrev  = ARGV[2]
+	user    = ENV['USER']
 
-쉽게 설명하기 위해 전역 변수를 사용했다. 비판하지 말기 바란다.
+	puts "Enforcing Policies... \n(#{refname}) (#{oldrev[0,6]}) (#{newrev[0,6]})"
 
 #### 커밋 메시지 규칙 만들기 ####
 

From 7092f297fd9c73108d588a9bc5d1ce8a7bce000a Mon Sep 17 00:00:00 2001
From: "Larry Shatzer, Jr" <larrys@gmail.com>
Date: Fri, 30 May 2014 14:14:50 -0600
Subject: [PATCH 440/690] Markup fixes.

---
 en/01-introduction/01-chapter1.markdown       | 8 ++++----
 en/03-git-branching/01-chapter3.markdown      | 4 ++--
 en/05-distributed-git/01-chapter5.markdown    | 2 +-
 en/07-customizing-git/01-chapter7.markdown    | 2 +-
 en/08-git-and-other-scms/01-chapter8.markdown | 8 ++++----
 en/09-git-internals/01-chapter9.markdown      | 2 +-
 6 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/en/01-introduction/01-chapter1.markdown b/en/01-introduction/01-chapter1.markdown
index e30752b7f..b82705a07 100644
--- a/en/01-introduction/01-chapter1.markdown
+++ b/en/01-introduction/01-chapter1.markdown
@@ -102,7 +102,7 @@ Now, pay attention. This is the main thing to remember about Git if you want the
 This leads us to the three main sections of a Git project: the Git directory, the working directory, and the staging area.
 
 Insert 18333fig0106.png
-Figure 1-6. Working directory, staging area, and git directory.
+Figure 1-6. Working directory, staging area, and Git directory.
 
 The Git directory is where Git stores the metadata and object database for your project. This is the most important part of Git, and it is what is copied when you clone a repository from another computer.
 
@@ -116,7 +116,7 @@ The basic Git workflow goes something like this:
 2. You stage the files, adding snapshots of them to your staging area.
 3. You do a commit, which takes the files as they are in the staging area and stores that snapshot permanently to your Git directory.
 
-If a particular version of a file is in the git directory, it’s considered committed. If it’s modified but has been added to the staging area, it is staged. And if it was changed since it was checked out but has not been staged, it is modified. In Chapter 2, you’ll learn more about these states and how you can either take advantage of them or skip the staged part entirely.
+If a particular version of a file is in the Git directory, it’s considered committed. If it’s modified but has been added to the staging area, it is staged. And if it was changed since it was checked out but has not been staged, it is modified. In Chapter 2, you’ll learn more about these states and how you can either take advantage of them or skip the staged part entirely.
 
 ## Installing Git ##
 
@@ -188,11 +188,11 @@ Note on Windows usage: you should use Git with the provided msysGit shell (Unix
 
 Now that you have Git on your system, you’ll want to do a few things to customize your Git environment. You should have to do these things only once; they’ll stick around between upgrades. You can also change them at any time by running through the commands again.
 
-Git comes with a tool called git config that lets you get and set configuration variables that control all aspects of how Git looks and operates. These variables can be stored in three different places:
+Git comes with a tool called `git config` that lets you get and set configuration variables that control all aspects of how Git looks and operates. These variables can be stored in three different places:
 
 *	`/etc/gitconfig` file: Contains values for every user on the system and all their repositories. If you pass the option` --system` to `git config`, it reads and writes from this file specifically.
 *	`~/.gitconfig` file: Specific to your user. You can make Git read and write to this file specifically by passing the `--global` option.
-*	config file in the git directory (that is, `.git/config`) of whatever repository you’re currently using: Specific to that single repository. Each level overrides values in the previous level, so values in `.git/config` trump those in `/etc/gitconfig`.
+*	config file in the Git directory (that is, `.git/config`) of whatever repository you’re currently using: Specific to that single repository. Each level overrides values in the previous level, so values in `.git/config` trump those in `/etc/gitconfig`.
 
 On Windows systems, Git looks for the `.gitconfig` file in the `$HOME` directory (`%USERPROFILE%` in Windows’ environment), which is `C:\Documents and Settings\$USER` or `C:\Users\$USER` for most people, depending on version (`$USER` is `%USERNAME%` in Windows’ environment). 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.
 
diff --git a/en/03-git-branching/01-chapter3.markdown b/en/03-git-branching/01-chapter3.markdown
index 0ab31e938..adf1995d1 100644
--- a/en/03-git-branching/01-chapter3.markdown
+++ b/en/03-git-branching/01-chapter3.markdown
@@ -41,7 +41,7 @@ This creates a new pointer at the same commit you’re currently on (see Figure
 Insert 18333fig0304.png
 Figure 3-4. Multiple branches pointing into the commit’s data history.
 
-How does Git know what branch you’re currently on? It keeps a special pointer called HEAD. Note that this is a lot different than the concept of HEAD in other VCSs you may be used to, such as Subversion or CVS. In Git, this is a pointer to the local branch you’re currently on. In this case, you’re still on master. The git branch command only created a new branch — it didn’t switch to that branch (see Figure 3-5).
+How does Git know what branch you’re currently on? It keeps a special pointer called HEAD. Note that this is a lot different than the concept of HEAD in other VCSs you may be used to, such as Subversion or CVS. In Git, this is a pointer to the local branch you’re currently on. In this case, you’re still on master. The `git branch` command only created a new branch — it didn’t switch to that branch (see Figure 3-5).
 
 Insert 18333fig0305.png
 Figure 3-5. HEAD file pointing to the branch you’re on.
@@ -404,7 +404,7 @@ Figure 3-23. Working locally and having someone push to your remote server makes
 To synchronize your work, you run a `git fetch origin` command. This command looks up which server origin is (in this case, it’s `git.ourcompany.com`), fetches any data from it that you don’t yet have, and updates your local database, moving your `origin/master` pointer to its new, more up-to-date position (see Figure 3-24).
 
 Insert 18333fig0324.png
-Figure 3-24. The git fetch command updates your remote references.
+Figure 3-24. The `git fetch` command updates your remote references.
 
 To demonstrate having multiple remote servers and what remote branches for those remote projects look like, let’s assume you have another internal Git server that is used only for development by one of your sprint teams. This server is at `git.team1.ourcompany.com`. You can add it as a new remote reference to the project you’re currently working on by running the `git remote add` command as we covered in Chapter 2. Name this remote `teamone`, which will be your shortname for that whole URL (see Figure 3-25).
 
diff --git a/en/05-distributed-git/01-chapter5.markdown b/en/05-distributed-git/01-chapter5.markdown
index af0ae4ad2..a4d821de9 100644
--- a/en/05-distributed-git/01-chapter5.markdown
+++ b/en/05-distributed-git/01-chapter5.markdown
@@ -611,7 +611,7 @@ If you received the patch from someone who generated it with the `git diff` or a
 
 This modifies the files in your working directory. It’s almost identical to running a `patch -p1` command to apply the patch, although it’s more paranoid and accepts fewer fuzzy matches than patch. It also handles file adds, deletes, and renames if they’re described in the `git diff` format, which `patch` won’t do. Finally, `git apply` is an "apply all or abort all" model where either everything is applied or nothing is, whereas `patch` can partially apply patchfiles, leaving your working directory in a weird state. `git apply` is overall much more paranoid than `patch`. It won’t create a commit for you — after running it, you must stage and commit the changes introduced manually.
 
-You can also use git apply to see if a patch applies cleanly before you try actually applying it — you can run `git apply --check` with the patch:
+You can also use `git apply` to see if a patch applies cleanly before you try actually applying it — you can run `git apply --check` with the patch:
 
 	$ git apply --check 0001-seeing-if-this-helps-the-gem.patch
 	error: patch failed: ticgit.gemspec:1
diff --git a/en/07-customizing-git/01-chapter7.markdown b/en/07-customizing-git/01-chapter7.markdown
index b1dbaa989..e77128dd8 100644
--- a/en/07-customizing-git/01-chapter7.markdown
+++ b/en/07-customizing-git/01-chapter7.markdown
@@ -511,7 +511,7 @@ For example, say you have some test files in a `test/` subdirectory, and it does
 
 	test/ export-ignore
 
-Now, when you run git archive to create a tarball of your project, that directory won’t be included in the archive.
+Now, when you run `git archive` to create a tarball of your project, that directory won’t be included in the archive.
 
 #### export-subst ####
 
diff --git a/en/08-git-and-other-scms/01-chapter8.markdown b/en/08-git-and-other-scms/01-chapter8.markdown
index 4e6671c27..a270b14e3 100644
--- a/en/08-git-and-other-scms/01-chapter8.markdown
+++ b/en/08-git-and-other-scms/01-chapter8.markdown
@@ -202,7 +202,7 @@ Running `git svn rebase` every once in a while makes sure your code is always up
 
 ### Git Branching Issues ###
 
-When you’ve become comfortable with a Git workflow, you’ll likely create topic branches, do work on them, and then merge them in. If you’re pushing to a Subversion server via git svn, you may want to rebase your work onto a single branch each time instead of merging branches together. The reason to prefer rebasing is that Subversion has a linear history and doesn’t deal with merges like Git does, so git svn follows only the first parent when converting the snapshots into Subversion commits.
+When you’ve become comfortable with a Git workflow, you’ll likely create topic branches, do work on them, and then merge them in. If you’re pushing to a Subversion server via `git svn`, you may want to rebase your work onto a single branch each time instead of merging branches together. The reason to prefer rebasing is that Subversion has a linear history and doesn’t deal with merges like Git does, so `git svn` follows only the first parent when converting the snapshots into Subversion commits.
 
 Suppose your history looks like the following: you created an `experiment` branch, did two commits, and then merged them back into `master`. When you `dcommit`, you see output like this:
 
@@ -231,7 +231,7 @@ When someone else clones that work, all they see is the merge commit with all th
 
 ### Subversion Branching ###
 
-Branching in Subversion isn’t the same as branching in Git; if you can avoid using it much, that’s probably best. However, you can create and commit to branches in Subversion using git svn.
+Branching in Subversion isn’t the same as branching in Git; if you can avoid using it much, that’s probably best. However, you can create and commit to branches in Subversion using `git svn`.
 
 #### Creating a New SVN Branch ####
 
@@ -499,7 +499,7 @@ To quickly demonstrate, you’ll write a simple importer. Suppose you work in cu
 
 In order to import a Git directory, you need to review how Git stores its data. As you may remember, Git is fundamentally a linked list of commit objects that point to a snapshot of content. All you have to do is tell `fast-import` what the content snapshots are, what commit data points to them, and the order they go in. Your strategy will be to go through the snapshots one at a time and create commits with the contents of each directory, linking each commit back to the previous one.
 
-As you did in the "An Example Git Enforced Policy" section of Chapter 7, we’ll write this in Ruby, because it’s what I generally work with and it tends to be easy to read. You can write this example pretty easily in anything you’re familiar with — it just needs to print the appropriate information to stdout. And, if you are running on Windows, this means you’ll need to take special care to not introduce carriage returns at the end your lines — git fast-import is very particular about just wanting line feeds (LF) not the carriage return line feeds (CRLF) that Windows uses.
+As you did in the "An Example Git Enforced Policy" section of Chapter 7, we’ll write this in Ruby, because it’s what I generally work with and it tends to be easy to read. You can write this example pretty easily in anything you’re familiar with — it just needs to print the appropriate information to stdout. And, if you are running on Windows, this means you’ll need to take special care to not introduce carriage returns at the end your lines — `git fast-import` is very particular about just wanting line feeds (LF) not the carriage return line feeds (CRLF) that Windows uses.
 
 To begin, you’ll change into the target directory and identify every subdirectory, each of which is a snapshot that you want to import as a commit. You’ll change into each subdirectory and print the commands necessary to export it. Your basic main loop looks like this:
 
@@ -601,7 +601,7 @@ The last thing you need to do is to return the current mark so it can be passed
 
 	return mark
 
-NOTE: If you are running on Windows you’ll need to make sure that you add one extra step. As mentioned before, Windows uses CRLF for new line characters while git fast-import expects only LF. To get around this problem and make git fast-import happy, you need to tell ruby to use LF instead of CRLF:
+NOTE: If you are running on Windows you’ll need to make sure that you add one extra step. As mentioned before, Windows uses CRLF for new line characters while `git fast-import` expects only LF. To get around this problem and make `git fast-import` happy, you need to tell ruby to use LF instead of CRLF:
 
 	$stdout.binmode
 
diff --git a/en/09-git-internals/01-chapter9.markdown b/en/09-git-internals/01-chapter9.markdown
index 71d41a932..b638c04b7 100644
--- a/en/09-git-internals/01-chapter9.markdown
+++ b/en/09-git-internals/01-chapter9.markdown
@@ -27,7 +27,7 @@ When you run `git init` in a new or existing directory, Git creates the `.git` d
 	objects/
 	refs/
 
-You may see some other files in there, but this is a fresh `git init` repository — it’s what you see by default. The `branches` directory isn’t used by newer Git versions, and the `description` file is only used by the GitWeb program, so don’t worry about those. The `config` file contains your project-specific configuration options, and the `info` directory keeps a global exclude file for ignored patterns that you don’t want to track in a .gitignore file. The `hooks` directory contains your client- or server-side hook scripts, which are discussed in detail in Chapter 7.
+You may see some other files in there, but this is a fresh `git init` repository — it’s what you see by default. The `branches` directory isn’t used by newer Git versions, and the `description` file is only used by the GitWeb program, so don’t worry about those. The `config` file contains your project-specific configuration options, and the `info` directory keeps a global exclude file for ignored patterns that you don’t want to track in a `.gitignore` file. The `hooks` directory contains your client- or server-side hook scripts, which are discussed in detail in Chapter 7.
 
 This leaves four important entries: the `HEAD` and `index` files and the `objects` and `refs` directories. These are the core parts of Git. The `objects` directory stores all the content for your database, the `refs` directory stores pointers into commit objects in that data (branches), the `HEAD` file points to the branch you currently have checked out, and the `index` file is where Git stores your staging area information. You’ll now look at each of these sections in detail to see how Git operates.
 

From fdee83e97c2dea0dc103988f1f0bb4ffeeb435bf Mon Sep 17 00:00:00 2001
From: Xue Fuqiao <xfq.free@gmail.com>
Date: Sun, 1 Jun 2014 11:14:00 +0800
Subject: [PATCH 441/690] [zh] Synchronize with English version.

---
 zh/01-introduction/01-chapter1.markdown       | 4 ++--
 zh/03-git-branching/01-chapter3.markdown      | 2 +-
 zh/07-customizing-git/01-chapter7.markdown    | 2 +-
 zh/08-git-and-other-scms/01-chapter8.markdown | 8 ++++----
 zh/09-git-internals/01-chapter9.markdown      | 2 +-
 5 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/zh/01-introduction/01-chapter1.markdown b/zh/01-introduction/01-chapter1.markdown
index cfac13adf..93ceddd73 100644
--- a/zh/01-introduction/01-chapter1.markdown
+++ b/zh/01-introduction/01-chapter1.markdown
@@ -188,11 +188,11 @@ Insert 18333fig0107.png
 
 一般在新的系统上，我们都需要先配置下自己的 Git 工作环境。配置工作只需一次，以后升级时还会沿用现在的配置。当然，如果需要，你随时可以用相同的命令修改已有的配置。
 
-Git 提供了一个叫做 git config 的工具（译注：实际是 `git-config` 命令，只不过可以通过 `git` 加一个名字来呼叫此命令。），专门用来配置或读取相应的工作环境变量。而正是由这些环境变量，决定了 Git 在各个环节的具体工作方式和行为。这些变量可以存放在以下三个不同的地方：
+Git 提供了一个叫做 `git config` 的工具（译注：实际是 `git-config` 命令，只不过可以通过 `git` 加一个名字来呼叫此命令。），专门用来配置或读取相应的工作环境变量。而正是由这些环境变量，决定了 Git 在各个环节的具体工作方式和行为。这些变量可以存放在以下三个不同的地方：
 
 *	`/etc/gitconfig` 文件：系统中对所有用户都普遍适用的配置。若使用 `git config` 时用 ` --system` 选项，读写的就是这个文件。
 *	`~/.gitconfig` 文件：用户目录下的配置文件只适用于该用户。若使用 `git config` 时用 ` --global` 选项，读写的就是这个文件。
-*	当前项目的 git 目录中的配置文件（也就是工作目录中的 `.git/config` 文件）：这里的配置仅仅针对当前项目有效。每一个级别的配置都会覆盖上层的相同配置，所以 `.git/config` 里的配置会覆盖 `/etc/gitconfig` 中的同名变量。
+*	当前项目的 Git 目录中的配置文件（也就是工作目录中的 `.git/config` 文件）：这里的配置仅仅针对当前项目有效。每一个级别的配置都会覆盖上层的相同配置，所以 `.git/config` 里的配置会覆盖 `/etc/gitconfig` 中的同名变量。
 
 在 Windows 系统上，Git 会找寻用户主目录下的 `.gitconfig` 文件。主目录即 `$HOME` 变量指定的目录，一般都是 `C:\Documents and Settings\$USER`。此外，Git 还会尝试找寻 `/etc/gitconfig` 文件，只不过看当初 Git 装在什么目录，就以此作为根目录来定位。
 
diff --git a/zh/03-git-branching/01-chapter3.markdown b/zh/03-git-branching/01-chapter3.markdown
index 70473c28e..05bc4817f 100644
--- a/zh/03-git-branching/01-chapter3.markdown
+++ b/zh/03-git-branching/01-chapter3.markdown
@@ -402,7 +402,7 @@ Insert 18333fig0323.png
 可以运行 `git fetch origin` 来同步远程服务器上的数据到本地。该命令首先找到 `origin` 是哪个服务器（本例为 `git.ourcompany.com`），从上面获取你尚未拥有的数据，更新你本地的数据库，然后把 `origin/master` 的指针移到它最新的位置上（见图 3-24）。
 
 Insert 18333fig0324.png
-图 3-24. git fetch 命令会更新 remote 索引。
+图 3-24. `git fetch` 命令会更新 remote 索引。
 
 为了演示拥有多个远程分支（在不同的远程服务器上）的项目是如何工作的，我们假设你还有另一个仅供你的敏捷开发小组使用的内部服务器 `git.team1.ourcompany.com`。可以用第二章中提到的 `git remote add` 命令把它加为当前项目的远程分支之一。我们把它命名为 `teamone`，以便代替完整的 Git URL 以方便使用（见图 3-25）。
 
diff --git a/zh/07-customizing-git/01-chapter7.markdown b/zh/07-customizing-git/01-chapter7.markdown
index 2b4d20121..43ef5f389 100644
--- a/zh/07-customizing-git/01-chapter7.markdown
+++ b/zh/07-customizing-git/01-chapter7.markdown
@@ -510,7 +510,7 @@ Git属性在导出项目归档时也能发挥作用。
 
 	test/ export-ignore
 
-现在，当运行git archive来创建项目的压缩包时，那个目录不会在归档中出现。
+现在，当运行 `git archive` 来创建项目的压缩包时，那个目录不会在归档中出现。
 
 #### export-subst ####
 
diff --git a/zh/08-git-and-other-scms/01-chapter8.markdown b/zh/08-git-and-other-scms/01-chapter8.markdown
index 1aae0d2a3..0110dde53 100644
--- a/zh/08-git-and-other-scms/01-chapter8.markdown
+++ b/zh/08-git-and-other-scms/01-chapter8.markdown
@@ -202,7 +202,7 @@ Git 中所有 Subversion 桥接命令的基础是 `git svn` 。所有的命令
 
 ### Git 分支问题 ###
 
-习惯了 Git 的工作流程以后，你可能会创建一些特性分支，完成相关的开发工作，然后合并他们。如果要用 git svn 向 Subversion 推送内容，那么最好是每次用衍合来并入一个单一分支，而不是直接合并。使用衍合的原因是 Subversion 只有一个线性的历史而不像 Git 那样处理合并，所以 Git svn 在把快照转换为 Subversion 的 commit 时只能包含第一个祖先。
+习惯了 Git 的工作流程以后，你可能会创建一些特性分支，完成相关的开发工作，然后合并他们。如果要用 `git svn` 向 Subversion 推送内容，那么最好是每次用衍合来并入一个单一分支，而不是直接合并。使用衍合的原因是 Subversion 只有一个线性的历史而不像 Git 那样处理合并，所以 `git svn` 在把快照转换为 Subversion 的 commit 时只能包含第一个祖先。
 
 假设分支历史如下：创建一个 `experiment` 分支，进行两次提交，然后合并到 `master` 。在 `dcommit` 的时候会得到如下输出：
 
@@ -231,7 +231,7 @@ Git 中所有 Subversion 桥接命令的基础是 `git svn` 。所有的命令
 
 ### Subversion 分支 ###
 
-Subversion 的分支和 Git 中的不尽相同；避免过多的使用可能是最好方案。不过，用 git svn 创建和提交不同的 Subversion 分支仍是可行的。
+Subversion 的分支和 Git 中的不尽相同；避免过多的使用可能是最好方案。不过，用 `git svn` 创建和提交不同的 Subversion 分支仍是可行的。
 
 #### 创建新的 SVN 分支 ####
 
@@ -499,7 +499,7 @@ Git 通过搜寻提交历史中 Subversion 分支的头部来决定 dcommit 的
 
 为了导入到一个 Git 目录，我们首先回顾一下 Git 储存数据的方式。你可能还记得，Git 本质上是一个 commit 对象的链表，每一个对象指向一个内容的快照。而这里需要做的工作就是告诉 `fast-import` 内容快照的位置，什么样的 commit 数据指向它们，以及它们的顺序。我们采取一次处理一个快照的策略，为每一个内容目录建立对应的 commit ，每一个 commit 与之前的建立链接。
 
-正如在第七章 "Git 执行策略一例" 一节中一样，我们将使用 Ruby 来编写这个脚本，因为它是我日常使用的语言而且阅读起来简单一些。你可以用任何其他熟悉的语言来重写这个例子——它仅需要把必要的信息打印到标准输出而已。同时，如果你在使用 Windows，这意味着你要特别留意不要在换行的时候引入回车符（译注：carriage returns，Windows 换行时加入的符号，通常说的 `\r` ）—— Git 的 fast-import 对仅使用换行符（LF）而非 Windows 的回车符（CRLF）要求非常严格。
+正如在第七章 "Git 执行策略一例" 一节中一样，我们将使用 Ruby 来编写这个脚本，因为它是我日常使用的语言而且阅读起来简单一些。你可以用任何其他熟悉的语言来重写这个例子——它仅需要把必要的信息打印到标准输出而已。同时，如果你在使用 Windows，这意味着你要特别留意不要在换行的时候引入回车符（译注：carriage returns，Windows 换行时加入的符号，通常说的 `\r` ）—— `git fast-import` 对仅使用换行符（LF）而非 Windows 的回车符（CRLF）要求非常严格。
 
 首先，进入目标目录并且找到所有子目录，每一个子目录将作为一个快照被导入为一个 commit。我们将依次进入每一个子目录并打印所需的命令来导出它们。脚本的主循环大致是这样：
 
@@ -601,7 +601,7 @@ Git 通过搜寻提交历史中 Subversion 分支的头部来决定 dcommit 的
 
 	return mark
 
-注意：如果你在用 Windows，一定记得添加一项额外的步骤。前面提过，Windows 使用 CRLF 作为换行字符而 Git fast-import 只接受 LF。为了绕开这个问题来满足 git fast-import，你需要让 ruby 用 LF 取代 CRLF：
+注意：如果你在用 Windows，一定记得添加一项额外的步骤。前面提过，Windows 使用 CRLF 作为换行字符而 `git fast-import` 只接受 LF。为了绕开这个问题来满足 `git fast-import`，你需要让 ruby 用 LF 取代 CRLF：
 
 	$stdout.binmode
 
diff --git a/zh/09-git-internals/01-chapter9.markdown b/zh/09-git-internals/01-chapter9.markdown
index d77f577bc..0c29420fc 100644
--- a/zh/09-git-internals/01-chapter9.markdown
+++ b/zh/09-git-internals/01-chapter9.markdown
@@ -27,7 +27,7 @@
 	objects/
 	refs/
 
-该目录下有可能还有其他文件，但这是一个全新的 `git init` 生成的库，所以默认情况下这些就是你能看到的结构。新版本的 Git 不再使用 `branches` 目录，`description` 文件仅供 GitWeb 程序使用，所以不用关心这些内容。`config` 文件包含了项目特有的配置选项，`info` 目录保存了一份不希望在 .gitignore 文件中管理的忽略模式 (ignored patterns) 的全局可执行文件。`hooks` 目录保存了第七章详细介绍了的客户端或服务端钩子脚本。
+该目录下有可能还有其他文件，但这是一个全新的 `git init` 生成的库，所以默认情况下这些就是你能看到的结构。新版本的 Git 不再使用 `branches` 目录，`description` 文件仅供 GitWeb 程序使用，所以不用关心这些内容。`config` 文件包含了项目特有的配置选项，`info` 目录保存了一份不希望在 `.gitignore` 文件中管理的忽略模式 (ignored patterns) 的全局可执行文件。`hooks` 目录保存了第七章详细介绍了的客户端或服务端钩子脚本。
 
 另外还有四个重要的文件或目录：`HEAD` 及 `index` 文件，`objects` 及 `refs` 目录。这些是 Git 的核心部分。`objects` 目录存储所有数据内容，`refs`  目录存储指向数据 (分支) 的提交对象的指针，`HEAD` 文件指向当前分支，`index` 文件保存了暂存区域信息。马上你将详细了解 Git 是如何操纵这些内容的。
 

From adc3ae7adf55d3e51c66cf205094264e5ba82235 Mon Sep 17 00:00:00 2001
From: Jean-Noel Avila <jn.avila@free.fr>
Date: Mon, 2 Jun 2014 21:52:19 +0200
Subject: [PATCH 442/690] [fr] Update chapter on diffing

---
 fr/07-customizing-git/01-chapter7.markdown | 48 ++++++++++++----------
 1 file changed, 26 insertions(+), 22 deletions(-)

diff --git a/fr/07-customizing-git/01-chapter7.markdown b/fr/07-customizing-git/01-chapter7.markdown
index e7248a28a..835a4dc3c 100644
--- a/fr/07-customizing-git/01-chapter7.markdown
+++ b/fr/07-customizing-git/01-chapter7.markdown
@@ -385,12 +385,23 @@ Dans la branche 1.6 de Git, vous pouvez aussi utiliser une macro fournie qui sig
 
 #### Comparaison de fichiers binaires ####
 
-Dans la branche 1.6 de Git, vous pouvez utiliser la fonctionnalité des attributs Git pour effectivement comparer les fichiers binaires.
+Dans Git, vous pouvez utiliser la fonctionnalité des attributs pour comparer efficacement les fichiers binaires.
 Pour ce faire, indiquez à Git comment convertir vos données binaires en format texte qui peut être comparé via un diff normal.
+Mais le question revient alors à savoir comment convertir les données binaires en texte.
+La meilleure solution consiste à trouver un outil qui réalise pour vous la conversion des données binaires en représentation textuelle (imaginez par exemple comment convertir un fichier audio en texte).
+Si c'est impossible et qur vous ne parvenez pas à obtenir une réprésentation du contenu sous forme de texte, il reste relativement facile d'obtenir une description dans un format humainement lisible de ce contenu.
+Les métadonnées ne vous donneront pas une représentation complète du contenu du fichier, mais c'est en tout cas mieux que rien.
+
+Nous allons utiliser les deux méthodes précédentes pour obtenir des comparaisons de formats binaires largement utilisés.
+
+Note : il existe de nombreux types de formats binaires avec du contenu textuel pour lesquels il est difficile de trouver une convertisseur vers du texte.
+Dans ces cas, il reste toujours possible d'extraire le texte au moyen du programme `strings`.
+Certains de ces fichiers peuvent aussi utiliser une encodage spécifique du texte, comme UTF-16, et `strings` ne trouvera alors rien de probant.
+Les résultats sont très variables.
+Dans tous les cas, `strings` est disponible sur la plupart des systèmes Mac et Linux, et constitue une bonne option pour un premier essai. 
 
 ##### Fichiers MS Word #####
 
-Comme c'est une fonctionnalité plutôt cool et peu connue, nous allons en voir quelques exemples.
 Premièrement, nous utiliserons cette technique pour résoudre un des problèmes les plus ennuyeux de l'humanité : gérer en contrôle de version les documents Word.
 Tout le monde convient que Word est l'éditeur de texte le plus horrible qui existe, mais bizarrement, tout le monde persiste à l'utiliser.
 Si vous voulez gérer en version des documents Word, vous pouvez les coller dans un dépôt Git et les valider de temps à autre.
@@ -411,20 +422,17 @@ Ajoutez la ligne suivante dans votre fichier `.gitattributes` :
 Cette ligne indique à Git que tout fichier correspondant au patron (.doc) doit utiliser le filtre `word` pour visualiser le diff des modifications.
 Qu'est-ce que le filtre « word » ?
 Nous devons le définir.
-Vous allez configurer Git à utiliser le programme `strings` pour convertir les documents Word en fichiers texte lisibles qu'il pourra alors comparer correctement :
+Vous allez indiquer à Git d'utiliser le programme `catdoc` qui a été écrit spécifiquement pour extraire le texte d'un document MS Word.
+Vous pouvez l'obtenir depuis `http://www.wagner.pp.ru/~vitus/software/catdoc`.
 
-	$ git config diff.word.textconv strings
+	$ git config diff.word.textconv catdoc
 
 Cette commande ajoute à votre fichier `.git/config` une section qui ressemble à ceci :
 
 	[diff "word"]
-	  textconv = strings
-
-Note : il existe différents types de fichiers `.doc`.
-Certains utilisent un codage UTF-16 ou d'autres pages de codes plus exotiques dans lesquels `strings` ne trouvera aucune chaîne utile.
-Le résultat de ce filtre pour vos fichiers dépendra de ces conditions.
+	  textconv = catdoc
 
-À présent, Git sait que s'il essaie de faire un diff entre deux instantanés et qu'un des fichiers finit en `.doc`, il devrait faire passer ces fichiers par le filtre `word` défini comme le programme `strings`.
+À présent, Git sait que s'il essaie de faire un diff entre deux instantanés et qu'un des fichiers finit en `.doc`, il devrait faire passer ces fichiers par le filtre `word` défini comme le programme `catdoc`.
 Cette méthode fait effectivement des jolies versions texte de vos fichiers Word avant d'essayer de les comparer.
 
 Voici un exemple.
@@ -436,18 +444,14 @@ Puis, j'ai lancé `git diff` pour visualiser ce qui a changé :
 	index c1c8a0a..b93c9e4 100644
 	--- a/chapter1.doc
 	+++ b/chapter1.doc
-	@@ -8,7 +8,8 @@ re going to cover Version Control Systems (VCS) and Git basics
-	 re going to cover how to get it and set it up for the first time if you don
-	 t already have it on your system.
-	 In Chapter Two we will go over basic Git usage - how to use Git for the 80%
-	-s going on, modify stuff and contribute changes. If the book spontaneously
-	+s going on, modify stuff and contribute changes. If the book spontaneously
-	+Let's see if this works.
-
-Git réussit à m'indiquer succinctement que j'ai ajouté la chaîne « *Let's see if this works* », ce qui est correct.
-Ce n'est pas parfait car il y a toujours un tas de données aléatoires à la fin, mais c'est suffisant.
-Si vous êtes capable d'écrire un convertisseur Word vers texte qui fonctionne suffisamment bien, cette solution peut s'avérer très efficace.
-Cependant, `strings` est disponible sur la plupart des systèmes Mac et Linux et peut donc constituer un bon début pour de nombreux formats binaires.
+	@@ -128,7 +128,7 @@ and data size)
+	 Since its birth in 2005, Git has evolved and matured to be easy to use
+	 and yet retain these initial qualities. It’s incredibly fast, it’s
+	 very efficient with large projects, and it has an incredible branching
+	-system for non-linear development.
+	+system for non-linear development (See Chapter 3).
+
+Git m'indique succinctement que j'ai ajouté la chaîne « (see Chapter 3) », ce qui est correct.
 
 ##### Fichiers OpenDocument texte #####
 

From 203fe7efccf629cc0ecaa7ace38fffa42ec9a206 Mon Sep 17 00:00:00 2001
From: Jean-Noel Avila <jn.avila@free.fr>
Date: Mon, 2 Jun 2014 21:53:47 +0200
Subject: [PATCH 443/690] [fr] sync with 90c92ceb

---
 fr/08-git-and-other-scms/01-chapter8.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fr/08-git-and-other-scms/01-chapter8.markdown b/fr/08-git-and-other-scms/01-chapter8.markdown
index e7e3ad7ac..f31bf8d22 100644
--- a/fr/08-git-and-other-scms/01-chapter8.markdown
+++ b/fr/08-git-and-other-scms/01-chapter8.markdown
@@ -456,7 +456,7 @@ Vous pouvez alors fournir ce fichier à `git svn` pour l'aider à convertir les
 Vous pouvez aussi indiquer à `git svn` de ne pas inclure les méta-données que Subversion importe habituellement en passant l'option `--no-metadata` à la commande `clone` ou `init`.
 Au final, votre commande d'import ressemble à ceci :
 
-	$ git-svn clone http://mon-projet.googlecode.com/svn/ \
+	$ git svn clone http://mon-projet.googlecode.com/svn/ \
 	      --authors-file=users.txt --no-metadata -s my_project
 
 Maintenant, l'import depuis Subversion dans le répertoire `my_project` est plus présentable.

From dae161eb9b4b0f83f0c0f5f5ce9fbbf3e3e90cfd Mon Sep 17 00:00:00 2001
From: Jean-Noel Avila <jn.avila@free.fr>
Date: Mon, 2 Jun 2014 22:05:23 +0200
Subject: [PATCH 444/690] [fr] sync with 21e84add

---
 fr/02-git-basics/01-chapter2.markdown | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/fr/02-git-basics/01-chapter2.markdown b/fr/02-git-basics/01-chapter2.markdown
index 1ed5f012e..a52fc4c61 100644
--- a/fr/02-git-basics/01-chapter2.markdown
+++ b/fr/02-git-basics/01-chapter2.markdown
@@ -1289,8 +1289,7 @@ De nombreuses personnes utilisent parfaitement Git sans connaître aucun de ces
 ### Auto-Complétion ###
 
 Si vous utilisez le shell Bash, Git est livré avec un script d'auto-complétion utile.
-Téléchargez le code source de Git, et jetez un œil dans le répertoire `contrib/completion`.
-Il devrait y avoir un fichier nommé `git-completion.bash`.
+Téléchargez le directement depuis le code source de Git à https://github.com/git/git/blob/master/contrib/git-completion.bash .
 Copiez ce fichier dans votre répertoire personnel et ajoutez cette ligne à votre fichier `.bashrc` :
 
 	source ~/.git-completion.bash

From 26630312925924dbd75e895558544935a79f6724 Mon Sep 17 00:00:00 2001
From: Jean-Noel Avila <jn.avila@free.fr>
Date: Mon, 2 Jun 2014 22:11:03 +0200
Subject: [PATCH 445/690] [fr] sync with 2a0a8371

---
 fr/04-git-server/01-chapter4.markdown | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/fr/04-git-server/01-chapter4.markdown b/fr/04-git-server/01-chapter4.markdown
index 698952413..91238f71c 100644
--- a/fr/04-git-server/01-chapter4.markdown
+++ b/fr/04-git-server/01-chapter4.markdown
@@ -43,7 +43,8 @@ Ou bien cela :
 	$ git clone file:///opt/git/projet.git
 
 Git opère légèrement différemment si vous spécifiez explicitement le protocole `file://` au début de l'URL.
-Si vous spécifiez simplement le chemin, Git tente d'utiliser des liens durs ou une copie des fichiers nécessaires.
+Si vous spécifiez simplement le chemin et si la destination se trouve sur le même système de fichiers, Git tente d'utiliser des liens durs pour le fichiers communs.
+Si la destination se trouve sur un autre système de fichiers, Git fait une copie des fichiers nécessaires.
 Si vous spécifiez le protocole `file://`, Git lance un processus d'accès au travers du réseau, ce qui est généralement moins efficace.
 La raison d'utiliser spécifiquement le préfixe `file://` est la volonté d'obtenir une copie propre du dépôt, sans aucune référence ou aucun objet supplémentaire qui pourraient résulter d'un import depuis un autre système de gestion de version ou d'une action similaire (voir chapitre 9 pour les tâches de maintenance).
 Nous utiliserons les chemins normaux par la suite car c'est la méthode la plus efficace.

From 7fc30646d5f26b6271b23eee5500a74602595ec1 Mon Sep 17 00:00:00 2001
From: Jean-Noel Avila <jn.avila@free.fr>
Date: Mon, 2 Jun 2014 22:28:46 +0200
Subject: [PATCH 446/690] [fr] apply 15f2bf1b

---
 fr/05-distributed-git/01-chapter5.markdown | 28 ++++++++++++++++++----
 1 file changed, 23 insertions(+), 5 deletions(-)

diff --git a/fr/05-distributed-git/01-chapter5.markdown b/fr/05-distributed-git/01-chapter5.markdown
index 19716edfd..72096ff41 100644
--- a/fr/05-distributed-git/01-chapter5.markdown
+++ b/fr/05-distributed-git/01-chapter5.markdown
@@ -678,11 +678,31 @@ Vous pouvez positionner ces valeurs séparément avec une série de commandes `g
 	  sslverify = false
 
 Si votre serveur IMAP n'utilise pas SSL, les deux dernières lignes ne sont probablement pas nécessaires et le paramètre `host` commencera par `imap://` au lieu de `imaps://`.
-Quand c'est fait, vous pouvez utiliser la commande `git send-email` pour placer la série de patchs dans le répertoire *Drafts* du serveur IMAP spécifié :
+Quand c'est fait, vous pouvez utiliser la commande `git imap-send` pour placer la série de patchs dans le répertoire *Drafts* du serveur IMAP spécifié :
+
+	$ cat *.patch |git imap-send
+	Resolving imap.gmail.com... ok
+	Connecting to [74.125.142.109]:993... ok
+	Logging in...
+	sending 2 messages
+	100% (2/2) done
+
+À présent, vous devriez pouvoir vous rendre dans le répertoire *Drafts*, changer le champ destinataire pour celui de la liste de diffusion, y ajouter optionnellement en copie le mainteneur du projet ou le responsable et l'envoyer.
+
+Une autre méthode consiste à envoyer vos patchs par un serveur SMTP.
+Comme précédemment, vous pouvez régler chaque paramètre séparément avec une série de commandes `git config` ou vous pouvez les ajouter directement dans la section `sendemail` de votre fichier `~/.gitconfig` :
+
+	[sendemail]
+	  smtpencryption = tls
+	  smtpserver = smtp.gmail.com
+	  smtpuser = user@gmail.com
+	  smtpserverport = 587
+
+Après ceci, vous pouvez utiliser la commande `git send-email` pour envoyer vos patchs :
 
 	$ git send-email *.patch
-	0001-Ajout-d-une-limite-la-fonction-de-log.patch
-	0002-change-la-largeur-du-log-de-25-a-30.patch
+	0001-added-limit-to-log-function.patch
+	0002-changed-log-output-to-30-from-25.patch
 	Who should the emails appear to be from? [Jessica Smith <jessica@example.com>]
 	Emails will be sent from: Jessica Smith <jessica@example.com>
 	Who should the emails be sent to? jessica@example.com
@@ -707,8 +727,6 @@ Ensuite, Git crache un certain nombre d'informations qui ressemblent à ceci pou
 
 	Result: OK
 
-À présent, vous devriez pouvoir vous rendre dans le répertoire Drafts, changer le champ destinataire pour celui de la liste de diffusion, y ajouter optionnellement en copie le mainteneur du projet ou le responsable et l'envoyer.
-
 ### Résumé ###
 
 Ce chapitre a traité quelques-unes des méthodes communes de gestion de types différents de projets Git que vous pourrez rencontrer et a introduit un certain nombre de nouveaux outils pour vous aider à gérer ces processus.

From 28fdda9302fb2d1dc80211e91faea62c0dc65aa1 Mon Sep 17 00:00:00 2001
From: Jean-Noel Avila <jn.avila@free.fr>
Date: Mon, 2 Jun 2014 22:34:11 +0200
Subject: [PATCH 447/690] [fr] apply bdef6f76 and 1ca5ef16

---
 fr/03-git-branching/01-chapter3.markdown   | 2 +-
 fr/05-distributed-git/01-chapter5.markdown | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/fr/03-git-branching/01-chapter3.markdown b/fr/03-git-branching/01-chapter3.markdown
index 6768e4a02..832292d3b 100644
--- a/fr/03-git-branching/01-chapter3.markdown
+++ b/fr/03-git-branching/01-chapter3.markdown
@@ -597,7 +597,7 @@ Pour créer une branche locale avec un nom différent de celui de la branche dis
 	Branch sf set up to track remote branch refs/remotes/origin/correctionserveur.
 	Switched to a new branch "sf"
 
-À présent, votre branche locale sf poussera vers et tirera automatiquement depuis origin/correctionserveur.
+À présent, votre branche locale `sf` poussera vers et tirera automatiquement depuis `origin/correctionserveur`.
 
 ### Effacer des branches distantes ###
 
diff --git a/fr/05-distributed-git/01-chapter5.markdown b/fr/05-distributed-git/01-chapter5.markdown
index 72096ff41..8b0ac0a35 100644
--- a/fr/05-distributed-git/01-chapter5.markdown
+++ b/fr/05-distributed-git/01-chapter5.markdown
@@ -255,7 +255,7 @@ John a une référence aux modifications que Jessica a poussées, mais il doit l
 Cette fusion se passe sans problème — l'historique de *commits* de John ressemble à présent à la figure 5-5.
 
 Insert 18333fig0505.png
-Figure 5-5. Le dépôt local de John après la fusion d'origin/master.
+Figure 5-5. Le dépôt local de John après la fusion d'`origin/master`.
 
 Maintenant, John peut tester son code pour s'assurer qu'il fonctionne encore correctement et peut pousser son travail nouvellement fusionné sur le serveur :
 

From 3e72fe91a906f5a1c7ca1d50cadef6f86c617ecb Mon Sep 17 00:00:00 2001
From: lord63 <lord63.j@gmail.com>
Date: Tue, 3 Jun 2014 16:34:35 +0800
Subject: [PATCH 448/690] [zh] Fix a small typo in 01-chapter5

---
 zh/05-distributed-git/01-chapter5.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/zh/05-distributed-git/01-chapter5.markdown b/zh/05-distributed-git/01-chapter5.markdown
index b74cf66a9..2eaacee66 100644
--- a/zh/05-distributed-git/01-chapter5.markdown
+++ b/zh/05-distributed-git/01-chapter5.markdown
@@ -837,7 +837,7 @@ Insert 18333fig0527.png
 	user: "Scott Chacon <schacon@gmail.com>"
 	1024-bit DSA key, ID F721C45A, created 2009-02-09
 
-完成签名之后，如何分发PGP公钥（public key）是个问题。（译者注：分发公钥是为了验证标签）。还好，Git的设计者想到了解决办法：可以把key（既公钥）作为blob变量写入Git库，然后把它的内容直接写在标签里。`gpg --list-keys`命令可以显示出你所拥有的key：
+完成签名之后，如何分发PGP公钥（public key）是个问题。（译者注：分发公钥是为了验证标签）。还好，Git的设计者想到了解决办法：可以把key（即公钥）作为blob变量写入Git库，然后把它的内容直接写在标签里。`gpg --list-keys`命令可以显示出你所拥有的key：
 
 	$ gpg --list-keys
 	/Users/schacon/.gnupg/pubring.gpg

From 06245d5a93718e1e24db4e3a48495dc02c097b51 Mon Sep 17 00:00:00 2001
From: onovy <novy@ondrej.org>
Date: Sat, 7 Jun 2014 18:59:51 +0200
Subject: [PATCH 449/690] (working directory clean) message change.

This change was introduced in git at
https://github.com/git/git/commit/50bd8b7eb960ff7a646195e0751b48a0e57e03ad
---
 ar/02-git-basics/01-chapter2.markdown    | 2 +-
 az/02-git-basics/01-chapter2.markdown    | 2 +-
 az/06-git-tools/01-chapter6.markdown     | 2 +-
 be/02-git-basics/01-chapter2.markdown    | 2 +-
 cs/02-git-basics/01-chapter2.markdown    | 2 +-
 cs/06-git-tools/01-chapter6.markdown     | 2 +-
 de/06-git-tools/01-chapter6.markdown     | 2 +-
 en/06-git-tools/01-chapter6.markdown     | 2 +-
 eo/02-git-basics/01-chapter2.markdown    | 2 +-
 es-ni/02-git-basics/01-chapter2.markdown | 2 +-
 es/02-git-basics/01-chapter2.markdown    | 2 +-
 es/06-git-tools/01-chapter6.markdown     | 2 +-
 es/omegat-Benzirpi.tmx                   | 4 ++--
 fi/02-git-basics/01-chapter2.markdown    | 2 +-
 fr/02-git-basics/01-chapter2.markdown    | 2 +-
 fr/06-git-tools/01-chapter6.markdown     | 2 +-
 id/02-git-basics/01-chapter2.markdown    | 2 +-
 it/06-git-tools/01-chapter6.markdown     | 2 +-
 ja/06-git-tools/01-chapter6.markdown     | 2 +-
 ko/06-git-tools/01-chapter6.markdown     | 2 +-
 mk/02-git-basics/01-chapter2.markdown    | 2 +-
 nl/02-git-basics/01-chapter2.markdown    | 2 +-
 nl/06-git-tools/01-chapter6.markdown     | 2 +-
 no-nb/02-git-basics/01-chapter2.markdown | 2 +-
 no-nb/06-git-tools/01-chapter6.markdown  | 2 +-
 pl/02-git-basics/02-chapter2.markdown    | 2 +-
 pl/06-git-tools/01-chapter6.markdown     | 2 +-
 pt-br/02-git-basics/01-chapter2.markdown | 2 +-
 pt-br/06-git-tools/01-chapter6.markdown  | 2 +-
 ru/02-git-basics/01-chapter2.markdown    | 2 +-
 ru/06-git-tools/01-chapter6.markdown     | 2 +-
 th/02-git-basics/01-chapter2.markdown    | 2 +-
 tr/02-git-basics/01-chapter2.markdown    | 2 +-
 vi/02-git-basics/01-chapter2.markdown    | 2 +-
 zh-tw/06-git-tools/01-chapter6.markdown  | 2 +-
 zh/06-git-tools/01-chapter6.markdown     | 2 +-
 36 files changed, 37 insertions(+), 37 deletions(-)

diff --git a/ar/02-git-basics/01-chapter2.markdown b/ar/02-git-basics/01-chapter2.markdown
index 42771d7b9..0bea0227d 100644
--- a/ar/02-git-basics/01-chapter2.markdown
+++ b/ar/02-git-basics/01-chapter2.markdown
@@ -56,7 +56,7 @@ The main tool you use to determine which files are in which state is the git sta
 
 	$ git status
 	# On branch master
-	nothing to commit (working directory clean)
+	nothing to commit, working directory clean
 
 This means you have a clean working directory—in other words, there are no tracked and modified files. Git also doesn’t see any untracked files, or they would be listed here. Finally, the command tells you which branch you’re on. For now, that is always master, which is the default; you won’t worry about it here. The next chapter will go over branches and references in detail.
 
diff --git a/az/02-git-basics/01-chapter2.markdown b/az/02-git-basics/01-chapter2.markdown
index 4e177b56a..7f405674a 100644
--- a/az/02-git-basics/01-chapter2.markdown
+++ b/az/02-git-basics/01-chapter2.markdown
@@ -55,7 +55,7 @@ The main tool you use to determine which files are in which state is the `git st
 
 	$ git status
 	# On branch master
-	nothing to commit (working directory clean)
+	nothing to commit, working directory clean
 
 This means you have a clean working directory — in other words, there are no tracked and modified files. Git also doesn’t see any untracked files, or they would be listed here. Finally, the command tells you which branch you’re on. For now, that is always `master`, which is the default; you won’t worry about it here. The next chapter will go over branches and references in detail.
 
diff --git a/az/06-git-tools/01-chapter6.markdown b/az/06-git-tools/01-chapter6.markdown
index 5ca797d32..a6f0108af 100644
--- a/az/06-git-tools/01-chapter6.markdown
+++ b/az/06-git-tools/01-chapter6.markdown
@@ -440,7 +440,7 @@ Your working directory is clean:
 
 	$ git status
 	# On branch master
-	nothing to commit (working directory clean)
+	nothing to commit, working directory clean
 
 At this point, you can easily switch branches and do work elsewhere; your changes are stored on your stack. To see which stashes you’ve stored, you can use `git stash list`:
 
diff --git a/be/02-git-basics/01-chapter2.markdown b/be/02-git-basics/01-chapter2.markdown
index 4767c095a..d1f61ded5 100644
--- a/be/02-git-basics/01-chapter2.markdown
+++ b/be/02-git-basics/01-chapter2.markdown
@@ -55,7 +55,7 @@ Insert 18333fig0201.png
 
 	$ git status
 	# On branch master
-	nothing to commit (working directory clean)
+	nothing to commit, working directory clean
 
 Гэта значыць, што ў вас чысты працоўны каталог, іншымі словамі - адсутнічаюць мадыфікаваныя адсочваемыя файлы. Git таксама не знайшоў якія-небудзь неадсочваемыя файлы, у зваротным выпадку яны былі б пералічаны тут. У канцы каманда паказвае вам на якой ветцы вы знаходзіцеся.   This means you have a clean working directory — in other words, there are no tracked and modified files. Git also doesn’t see any untracked files, or they would be listed here. Finally, the command tells you which branch you’re on. For now, that is always `master`, which is the default; you won’t worry about it here. The next chapter will go over branches and references in detail.
 
diff --git a/cs/02-git-basics/01-chapter2.markdown b/cs/02-git-basics/01-chapter2.markdown
index b8b37c4c0..cae0cc93e 100644
--- a/cs/02-git-basics/01-chapter2.markdown
+++ b/cs/02-git-basics/01-chapter2.markdown
@@ -55,7 +55,7 @@ Hlavním nástrojem na zjišťování stavu jednotlivých souborů je příkaz `
 
 	$ git status
 	# On branch master
-	nothing to commit (working directory clean)
+	nothing to commit, working directory clean
 
 To znamená, že žádné soubory nejsou připraveny k zapsání a pracovní adresář je čistý. Jinými slovy žádné sledované soubory nebyly změněny. Git také neví o žádných nesledovaných souborech, jinak by byly ve výčtu uvedeny. Příkaz vám dále sděluje, na jaké větvi (branch) se nacházíte. Pro tuto chvíli nebudeme situaci komplikovat a výchozí bude vždy hlavní větev (`master` branch). Větve a reference budou podrobně popsány v následující kapitole.
 
diff --git a/cs/06-git-tools/01-chapter6.markdown b/cs/06-git-tools/01-chapter6.markdown
index 17b17dcb3..8b4349abf 100644
--- a/cs/06-git-tools/01-chapter6.markdown
+++ b/cs/06-git-tools/01-chapter6.markdown
@@ -457,7 +457,7 @@ Váš pracovní adresář se vyčistil:
 
 	$ git status
 	# On branch master
-	nothing to commit (working directory clean)
+	nothing to commit, working directory clean
 
 Nyní můžete bez obav přepnout větve a pracovat na jiném úkolu, vaše změny byly uloženy do zásobníku. Chcete-li se podívat, které soubory jste odložili, spusťte příkaz `git stash list`:
 
diff --git a/de/06-git-tools/01-chapter6.markdown b/de/06-git-tools/01-chapter6.markdown
index d9574cfff..0a16b2f0a 100644
--- a/de/06-git-tools/01-chapter6.markdown
+++ b/de/06-git-tools/01-chapter6.markdown
@@ -580,7 +580,7 @@ In Deinem Arbeitsverzeichnis befinden sich jetzt keine geänderten Dateien mehr
 
 	$ git status
 	# On branch master
-	nothing to commit (working directory clean)
+	nothing to commit, working directory clean
 
 <!--At this point, you can easily switch branches and do work elsewhere; your changes are stored on your stack. To see which stashes you’ve stored, you can use `git stash list`:-->
 
diff --git a/en/06-git-tools/01-chapter6.markdown b/en/06-git-tools/01-chapter6.markdown
index f986c2e38..eaa9b42a0 100644
--- a/en/06-git-tools/01-chapter6.markdown
+++ b/en/06-git-tools/01-chapter6.markdown
@@ -440,7 +440,7 @@ Your working directory is clean:
 
 	$ git status
 	# On branch master
-	nothing to commit (working directory clean)
+	nothing to commit, working directory clean
 
 At this point, you can easily switch branches and do work elsewhere; your changes are stored on your stack. To see which stashes you’ve stored, you can use `git stash list`:
 
diff --git a/eo/02-git-basics/01-chapter2.markdown b/eo/02-git-basics/01-chapter2.markdown
index be6a22bcf..78f6820c2 100644
--- a/eo/02-git-basics/01-chapter2.markdown
+++ b/eo/02-git-basics/01-chapter2.markdown
@@ -55,7 +55,7 @@ The main tool you use to determine which files are in which state is the `git st
 
 	$ git status
 	# On branch master
-	nothing to commit (working directory clean)
+	nothing to commit, working directory clean
 
 This means you have a clean working directory — in other words, no tracked files are modified. Git also doesn’t see any untracked files, or they would be listed here. Finally, the command tells you which branch you’re on. For now, that is always `master`, which is the default; you won’t worry about it here. The next chapter will go over branches and references in detail.
 
diff --git a/es-ni/02-git-basics/01-chapter2.markdown b/es-ni/02-git-basics/01-chapter2.markdown
index aac17c27c..701d8c983 100644
--- a/es-ni/02-git-basics/01-chapter2.markdown
+++ b/es-ni/02-git-basics/01-chapter2.markdown
@@ -55,7 +55,7 @@ La herramienta principal que se utiliza para determinar qué archivos están en
 
 	$ git status
 	# On branch master
-	nothing to commit (working directory clean)
+	nothing to commit, working directory clean
 
 Esto significa que tienes una copia de trabajo limpia, en otras palabras, que no hay ningún archivo versionado que haya sido modificado. Git tampoco detectó ningún archivo sin versionar, de otra manera debería estar listado aquí. Por último, el comando indica en qué branch estás trabajando. Por ahora, siempre será master, que es el branch por defecto; no hace falta que te preocupes por saber qué significa en este punto aún. En el próximo capítulo analizaremos los branches y referencias en detalle.
 
diff --git a/es/02-git-basics/01-chapter2.markdown b/es/02-git-basics/01-chapter2.markdown
index d46c1cb7d..d4e8d4098 100644
--- a/es/02-git-basics/01-chapter2.markdown
+++ b/es/02-git-basics/01-chapter2.markdown
@@ -55,7 +55,7 @@ Tu principal herramienta para determinar qué archivos están en qué estado es
 
 	$ git status
 	# On branch master
-	nothing to commit (working directory clean)
+	nothing to commit, working directory clean
 
 Esto significa que tienes un directorio de trabajo limpio —en otras palabras, no tienes archivos bajo seguimiento y modificados—. Git tampoco ve ningún archivo que no esté bajo seguimiento, o estaría listado ahí. Por último, el comando te dice en qué rama estás. Por ahora, esa rama siempre es "master", que es la predeterminada. No te preocupes de eso por ahora, el siguiente capítulo tratará los temas de las ramas y las referencias en detalle.
 
diff --git a/es/06-git-tools/01-chapter6.markdown b/es/06-git-tools/01-chapter6.markdown
index df5bec3cd..5ae5c5c8b 100644
--- a/es/06-git-tools/01-chapter6.markdown
+++ b/es/06-git-tools/01-chapter6.markdown
@@ -440,7 +440,7 @@ Con ello, se limpia el área de trabajo:
 
 	$ git status
 	# On branch master
-	nothing to commit (working directory clean)
+	nothing to commit, working directory clean
 
 Y se permite cambiar de rama para ponerse a trabajar en cualquier otra parte. Con la tranquilidad de que los cambios a medio completar están guardados a buen recaudo en la pila de guardado rápido. Para ver el contenido de dicha pila, se emplea el comando 'git stash list':
 
diff --git a/es/omegat-Benzirpi.tmx b/es/omegat-Benzirpi.tmx
index f789972d9..971ad7931 100644
--- a/es/omegat-Benzirpi.tmx
+++ b/es/omegat-Benzirpi.tmx
@@ -28305,12 +28305,12 @@ Figura 5-21.</seg>
       <tuv lang="EN">
         <seg>$ git status
 	# On branch master
-	nothing to commit (working directory clean)</seg>
+	nothing to commit, working directory clean</seg>
       </tuv>
       <tuv lang="ES" changedate="20120702T085314Z" changeid="juan">
         <seg>$ git status
 	# On branch master
-	nothing to commit (working directory clean)</seg>
+	nothing to commit, working directory clean</seg>
       </tuv>
     </tu>
     <tu>
diff --git a/fi/02-git-basics/01-chapter2.markdown b/fi/02-git-basics/01-chapter2.markdown
index f5c7f1ab0..2221d8629 100644
--- a/fi/02-git-basics/01-chapter2.markdown
+++ b/fi/02-git-basics/01-chapter2.markdown
@@ -55,7 +55,7 @@ Päätyökalu tiedostojesi eri tilojen selvittämiseen on `git status` -komento.
 
 	$ git status
 	# On branch master
-	nothing to commit (working directory clean)
+	nothing to commit, working directory clean
 
 Tämä tarkoittaa, että sinulla on puhdas työhakemisto - toisin sanoen, jäljitettyjä tiedostoja ei ole muutettu. Git ei myöskään näe yhtään jäljittämätöntä tiedostoa, muuten ne olisi listattu näkymään. Lopuksi komento kertoo sinulle missä haarassa olet. Tällä hetkellä se on aina `master`-haara, joka on oletusarvo; sinun ei tarvitse huolehtia siitä nyt. Seuraava luku käy läpi haarautumiset ja viittaukset yksityiskohtaisesti.
 
diff --git a/fr/02-git-basics/01-chapter2.markdown b/fr/02-git-basics/01-chapter2.markdown
index 1ed5f012e..5196cc1b0 100644
--- a/fr/02-git-basics/01-chapter2.markdown
+++ b/fr/02-git-basics/01-chapter2.markdown
@@ -81,7 +81,7 @@ Si vous lancez cette commande juste après un clonage, vous devriez voir ce qui
 
 	$ git status
 	# On branch master
-	nothing to commit (working directory clean)
+	nothing to commit, working directory clean
 
 Ce message signifie que votre copie de travail est propre, en d'autres mots, aucun fichier suivi n'a été modifié.
 Git ne voit pas non plus de fichiers non-suivis, sinon ils seraient listés ici.
diff --git a/fr/06-git-tools/01-chapter6.markdown b/fr/06-git-tools/01-chapter6.markdown
index 042f4ed3e..81009134a 100644
--- a/fr/06-git-tools/01-chapter6.markdown
+++ b/fr/06-git-tools/01-chapter6.markdown
@@ -504,7 +504,7 @@ Votre répertoire de travail est propre :
 
 	$ git status
 	# On branch master
-	nothing to commit (working directory clean)
+	nothing to commit, working directory clean
 
 À ce moment, vous pouvez facilement changer de branche et travailler autre part ; vos modifications sont conservées dans votre pile.
 Pour voir quelles remises vous avez sauvegardées, vous pouvez utiliser la commande `git stash list` :
diff --git a/id/02-git-basics/01-chapter2.markdown b/id/02-git-basics/01-chapter2.markdown
index dd67c0367..428e91669 100644
--- a/id/02-git-basics/01-chapter2.markdown
+++ b/id/02-git-basics/01-chapter2.markdown
@@ -55,7 +55,7 @@ Alat utama yang Anda gunakan untuk menentukan berkas-berkas mana yang berada dal
 
 	$ git status
 	# On branch master
-	nothing to commit (working directory clean)
+	nothing to commit, working directory clean
 
 Ini berarti Anda memiliki direktori kerja yang bersih-dengan kata lain, tidak ada berkas terpantau yang terubah. Git juga tidak melihat berkas-berkas yang tak terpantau, karena pasti akan dilaporkan oleh alat ini. Juga, perintah ini memberitahu Anda tentang cabang tempat Anda berada. Pada saat ini, cabang akan selalu berada di master, karena sudah menjadi default-nya; Anda tidak perlu khawatir tentang cabang dulu. Bab berikutnya akan membahas tentang percabangan dan referensi secara lebih detil.
 
diff --git a/it/06-git-tools/01-chapter6.markdown b/it/06-git-tools/01-chapter6.markdown
index 26d1e0821..28a30020c 100644
--- a/it/06-git-tools/01-chapter6.markdown
+++ b/it/06-git-tools/01-chapter6.markdown
@@ -440,7 +440,7 @@ La tua cartella di lavoro ora è pulita:
 
 	$ git status
 	# On branch master
-	nothing to commit (working directory clean)
+	nothing to commit, working directory clean
 
 A questo punto puoi passare facilmente a un'altra diramazione e lavorare ad altro; le tue modifiche sono salvate nella tua pila di accantonamento. Per vedere cosa c'è nella tua pila usa `git stash list`:
 
diff --git a/ja/06-git-tools/01-chapter6.markdown b/ja/06-git-tools/01-chapter6.markdown
index fae8cf67c..84519bda2 100644
--- a/ja/06-git-tools/01-chapter6.markdown
+++ b/ja/06-git-tools/01-chapter6.markdown
@@ -435,7 +435,7 @@ simplegit.rb のステータスがおもしろいことになっています。
 
 	$ git status
 	# On branch master
-	nothing to commit (working directory clean)
+	nothing to commit, working directory clean
 
 これで、簡単にブランチを切り替えて別の作業をできるようになりました。これまでの変更内容はスタックに格納されています。今までに格納した内容を見るには `git stash list` を使います。
 
diff --git a/ko/06-git-tools/01-chapter6.markdown b/ko/06-git-tools/01-chapter6.markdown
index 231d2dc8c..ae30bf7f2 100644
--- a/ko/06-git-tools/01-chapter6.markdown
+++ b/ko/06-git-tools/01-chapter6.markdown
@@ -436,7 +436,7 @@ Stash 명령을 사용하면 워킹 디렉토리에서 수정한 파일만 저
 
 	$ git status
 	# On branch master
-	nothing to commit (working directory clean)
+	nothing to commit, working directory clean
 
 이제 아무 브랜치나 골라서 바꿀 수 있다. 수정하던 것은 스택에 저장했다. 아래와 같이 `git stash list`를 사용하여 저장한 Stash를 확인한다:
 
diff --git a/mk/02-git-basics/01-chapter2.markdown b/mk/02-git-basics/01-chapter2.markdown
index 22d47ac85..82152512d 100644
--- a/mk/02-git-basics/01-chapter2.markdown
+++ b/mk/02-git-basics/01-chapter2.markdown
@@ -54,7 +54,7 @@ Insert 18333fig0201.png
 Главната алатка која ја користите за да дознаете кој фајл во која фаза се наоѓа е Git статус командата. Ако ја извршите оваа комнада веднаш по клонирањето треба да забележите нешто вака:
 	$ git status
 	# On branch master
-	nothing to commit (working directory clean)
+	nothing to commit, working directory clean
 
 Ова значи дека имате чист работен директориѕм, т.е. не постојат следени и променети фајлови. Git не нашол неследени фајлови, во спротивно ќе бидат прикажани овде. Како последна информација што ви ја дава оваа команда е тоа на кој бранч се наоѓате. За сега тоа секогаш е главниот бранч кој е предодреден; не треба да ве засега тоа во овој момент. Во следното поглавје ќе бидат детално разгледани бранчовите и референците.  
 
diff --git a/nl/02-git-basics/01-chapter2.markdown b/nl/02-git-basics/01-chapter2.markdown
index 2e2a50a51..1df052bc7 100644
--- a/nl/02-git-basics/01-chapter2.markdown
+++ b/nl/02-git-basics/01-chapter2.markdown
@@ -91,7 +91,7 @@ Het commando dat je voornamelijk zult gebruiken om te bepalen welk bestand zich
 
 	$ git status
 	# On branch master
-	nothing to commit (working directory clean)
+	nothing to commit, working directory clean
 
 Dit betekent dat je een schone werkdirectory hebt, met andere woorden er zijn geen tracked bestanden die gewijzigd zijn. Git ziet ook geen untracked bestanden, anders zouden ze hier getoond worden. Als laatste vertelt het commando op welke tak (branch) je nu zit. Voor nu is dit altijd `master`, dat is de standaard; besteed daar voor nu nog geen aandacht aan. In het volgende hoofdstuk wordt gedetaileerd ingegaan op branches en referenties.
 
diff --git a/nl/06-git-tools/01-chapter6.markdown b/nl/06-git-tools/01-chapter6.markdown
index 667354d80..6ff291d40 100644
--- a/nl/06-git-tools/01-chapter6.markdown
+++ b/nl/06-git-tools/01-chapter6.markdown
@@ -477,7 +477,7 @@ Je werkdirectory is schoon:
 
 	$ git status
 	# On branch master
-	nothing to commit (working directory clean)
+	nothing to commit, working directory clean
 
 Nu kan je eenvoudig van branch wisselen en ergens anders aan werken, je wijzigingen zijn opgeslagen op de stapel. Om te zien welke stashes je opgeslagen hebt, kun je `git stash list` gebruiken:
 
diff --git a/no-nb/02-git-basics/01-chapter2.markdown b/no-nb/02-git-basics/01-chapter2.markdown
index 7ce179f56..69de1735e 100644
--- a/no-nb/02-git-basics/01-chapter2.markdown
+++ b/no-nb/02-git-basics/01-chapter2.markdown
@@ -55,7 +55,7 @@ The main tool you use to determine which files are in which state is the `git st
 
 	$ git status
 	# On branch master
-	nothing to commit (working directory clean)
+	nothing to commit, working directory clean
 
 This means you have a clean working directory — in other words, there are no tracked and modified files. Git also doesn’t see any untracked files, or they would be listed here. Finally, the command tells you which branch you’re on. For now, that is always `master`, which is the default; you won’t worry about it here. The next chapter will go over branches and references in detail.
 
diff --git a/no-nb/06-git-tools/01-chapter6.markdown b/no-nb/06-git-tools/01-chapter6.markdown
index 5ca797d32..a6f0108af 100644
--- a/no-nb/06-git-tools/01-chapter6.markdown
+++ b/no-nb/06-git-tools/01-chapter6.markdown
@@ -440,7 +440,7 @@ Your working directory is clean:
 
 	$ git status
 	# On branch master
-	nothing to commit (working directory clean)
+	nothing to commit, working directory clean
 
 At this point, you can easily switch branches and do work elsewhere; your changes are stored on your stack. To see which stashes you’ve stored, you can use `git stash list`:
 
diff --git a/pl/02-git-basics/02-chapter2.markdown b/pl/02-git-basics/02-chapter2.markdown
index c10ec28a2..3695a4541 100644
--- a/pl/02-git-basics/02-chapter2.markdown
+++ b/pl/02-git-basics/02-chapter2.markdown
@@ -55,7 +55,7 @@ Podstawowe narzędzie używane do sprawdzenia stanu plików to polecenie `git st
 
 	$ git status
 	# On branch master
-	nothing to commit (working directory clean)
+	nothing to commit, working directory clean
 
 Oznacza to, że posiadasz czysty katalog roboczy — innymi słowy nie zawiera on śledzonych i zmodyfikowanych plików. Git nie widzi także żadnych plików nieśledzonych, w przeciwnym wypadku wyświetliłby ich listę. W końcu polecenie pokazuje również gałąź, na której aktualnie pracujesz. Póki co, jest to zawsze master, wartość domyślna; nie martw się tym jednak teraz. Następny rozdział w szczegółach omawia gałęzie oraz odniesienia.
 
diff --git a/pl/06-git-tools/01-chapter6.markdown b/pl/06-git-tools/01-chapter6.markdown
index fbba51d7a..9dd3e6e3b 100644
--- a/pl/06-git-tools/01-chapter6.markdown
+++ b/pl/06-git-tools/01-chapter6.markdown
@@ -602,7 +602,7 @@ Twój katalog roboczy jest teraz w stanie niezmienionym:
 
 	$ git status
 	# On branch master
-	nothing to commit (working directory clean)
+	nothing to commit, working directory clean
 
 W tej chwili, możesz bez problemu przejść na inną gałąź i rozpocząć pracę nad innymi zmianami; Twoje poprzednie modyfikacje zapisane są w przechowalni. Aby zobaczyć listę zapisanych zmian w przechowalni, użyj komendy `git stash list`: 
 
diff --git a/pt-br/02-git-basics/01-chapter2.markdown b/pt-br/02-git-basics/01-chapter2.markdown
index a773e232c..d4b0201cb 100644
--- a/pt-br/02-git-basics/01-chapter2.markdown
+++ b/pt-br/02-git-basics/01-chapter2.markdown
@@ -55,7 +55,7 @@ A principal ferramenta utilizada para determinar quais arquivos estão em quais
 
     $ git status
     # On branch master
-    nothing to commit (working directory clean)
+    nothing to commit, working directory clean
 
 Isso significa que você tem um diretório de trabalho limpo — em outras palavras, não existem arquivos monitorados e modificados. Git também não encontrou qualquer arquivo não monitorado, caso contrário eles seriam listados aqui. Por fim, o comando lhe mostra em qual branch você se encontra. Por enquanto, esse sempre é o `master`, que é o padrão; você não deve se preocupar com isso. No próximo capítulo nós vamos falar sobre branches e referências em detalhes.
 
diff --git a/pt-br/06-git-tools/01-chapter6.markdown b/pt-br/06-git-tools/01-chapter6.markdown
index 4a73cba92..8b4da423a 100644
--- a/pt-br/06-git-tools/01-chapter6.markdown
+++ b/pt-br/06-git-tools/01-chapter6.markdown
@@ -436,7 +436,7 @@ Seu diretório de trabalho está limpo:
 
     $ git status
     # On branch master
-    nothing to commit (working directory clean)
+    nothing to commit, working directory clean
 
 Neste momento, você pode facilmente mudar de branch e trabalhar em outra coisa; suas alterações estão armazenadas na sua pilha. Para ver as stashes que você guardou, você pode usar `git stash list`:
 
diff --git a/ru/02-git-basics/01-chapter2.markdown b/ru/02-git-basics/01-chapter2.markdown
index e2fa37cf8..b033ab202 100644
--- a/ru/02-git-basics/01-chapter2.markdown
+++ b/ru/02-git-basics/01-chapter2.markdown
@@ -55,7 +55,7 @@ Insert 18333fig0201.png
 
 	$ git status
 	# On branch master
-	nothing to commit (working directory clean)
+	nothing to commit, working directory clean
 
 Это означает, что у вас чистый рабочий каталог, другими словами — в нём нет отслеживаемых изменённых файлов. Git также не обнаружил неотслеживаемых файлов, в противном случае они бы были перечислены здесь. И наконец, команда сообщает вам на какой ветке (branch) вы сейчас находитесь. Пока что это всегда ветка `master` — это ветка по умолчанию; в этой главе это не важно. В следующей главе будет подробно рассказано про ветки и ссылки.
 
diff --git a/ru/06-git-tools/01-chapter6.markdown b/ru/06-git-tools/01-chapter6.markdown
index 0299438f1..470168f78 100644
--- a/ru/06-git-tools/01-chapter6.markdown
+++ b/ru/06-git-tools/01-chapter6.markdown
@@ -440,7 +440,7 @@ Insert 18333fig0601.png
 
 	$ git status
 	# On branch master
-	nothing to commit (working directory clean)
+	nothing to commit, working directory clean
 
 В данный момент вы легко можете переключить ветки и поработать где-то ещё; ваши изменения сохранены в стеке. Чтобы посмотреть, что у вас есть припрятанного, используйте `git stash list`:
 
diff --git a/th/02-git-basics/01-chapter2.markdown b/th/02-git-basics/01-chapter2.markdown
index d6cad5300..0e23db3e3 100644
--- a/th/02-git-basics/01-chapter2.markdown
+++ b/th/02-git-basics/01-chapter2.markdown
@@ -55,7 +55,7 @@ Insert 18333fig0201.png
 
 	$ git status
 	# On branch master
-	nothing to commit (working directory clean)
+	nothing to commit, working directory clean
 
 ผลลัพธ์ด้านบนหมายความว่าไดเรกทอรีของคุณยังสะอาดอยู่ นั่นก็คือไม่มีการแก้ไขแฟ้มที่ถูก track และ ไม่มีแฟ้มที่อยู่ในสถานะ untracked ในไดเรกทอรี นอกจากนั้นคำสั่งนี้ยังบอกว่าคุณอยู่ใน branch ชื่อ master ซึ่งเป็น branch เริ่มต้นอยู่แล้ว เราจะลงรายละเอียดเกี่ยวกับ branch และ reference ในบทถัดไป
 
diff --git a/tr/02-git-basics/01-chapter2.markdown b/tr/02-git-basics/01-chapter2.markdown
index fd769f132..7d90fb73c 100644
--- a/tr/02-git-basics/01-chapter2.markdown
+++ b/tr/02-git-basics/01-chapter2.markdown
@@ -56,7 +56,7 @@ Hangi dosyanın hangi durumda olduğunu görmek için kullanılacak temel araç
 
 	$ git status
 	# On branch master
-	nothing to commit (working directory clean)
+	nothing to commit, working directory clean
 
 Bu çalışma klasörünüzün temiz olduğu anlamına gelir —başka bir deyişle, izlenmekte olup da değiştirilmiş herhangi bir dosya yoktur. Git'in saptadığı herhangi bir izlenmeyen dosya da yok, olsaydı burada listelenmiş olurdu. Son olarak, bu komut size hangi dal (_branch_) üzerinde olduğunuzu söylüyor. Şimdilik bu, daima varsayılan dal olan `master` olacaktır; Şu anda buna kafa yormayın. Sonraki bölüm de dallar ve referanslar konusu derinlemesine ele alınacak.
 
diff --git a/vi/02-git-basics/01-chapter2.markdown b/vi/02-git-basics/01-chapter2.markdown
index 460b5455a..9b4e38645 100644
--- a/vi/02-git-basics/01-chapter2.markdown
+++ b/vi/02-git-basics/01-chapter2.markdown
@@ -55,7 +55,7 @@ Công cụ chính để phát hiện trạng thái của tập tin là lệnh `g
 
 	$ git status
 	# On branch master
-	nothing to commit (working directory clean)
+	nothing to commit, working directory clean
 
 Điều này có nghĩa là bạn có một thư mục làm việc "sạch" - hay nói cách khác, không có tập tin đang theo dõi nào bị thay đổi. Git cũng không phát hiện ra tập tin chưa được theo dõi nào, nếu không thì chúng đã được liệt kê ra đây. Cuối cùng, lệnh này cho bạn biết bạn đang thao tác trên "nhánh" (branch) nào. Hiện tại thì nó sẽ luôn là `master`, đó là nhánh mặc định; bạn chưa nên quan tâm đến vấn đề này bây giờ. Chương tiếp theo chúng ta sẽ bàn về các Nhánh chi tiết hơn.
 
diff --git a/zh-tw/06-git-tools/01-chapter6.markdown b/zh-tw/06-git-tools/01-chapter6.markdown
index 42c34316e..9315aedd9 100644
--- a/zh-tw/06-git-tools/01-chapter6.markdown
+++ b/zh-tw/06-git-tools/01-chapter6.markdown
@@ -439,7 +439,7 @@ simplegit.rb 的狀態非常有意思。它顯示有幾行被暫存了，有幾
 
 	$ git status
 	# On branch master
-	nothing to commit (working directory clean)
+	nothing to commit, working directory clean
 
 這時，你可以方便地切換到其他分支工作；你的變更都保存在堆疊上。要查看現有的儲藏，你可以使用 `git stash list`： 
 
diff --git a/zh/06-git-tools/01-chapter6.markdown b/zh/06-git-tools/01-chapter6.markdown
index ac3f20ac1..948b1ff1d 100644
--- a/zh/06-git-tools/01-chapter6.markdown
+++ b/zh/06-git-tools/01-chapter6.markdown
@@ -439,7 +439,7 @@ simplegit.rb的状态非常有意思。它显示有几行被暂存了，有几
 
 	$ git status
 	# On branch master
-	nothing to commit (working directory clean)
+	nothing to commit, working directory clean
 
 这时，你可以方便地切换到其他分支工作；你的变更都保存在栈上。要查看现有的储藏，你可以使用 `git stash list`：
 

From 4396aa8204094e4ca72ba05e16e3cc36686745d4 Mon Sep 17 00:00:00 2001
From: FrankLo <contact@software.bacal.de>
Date: Mon, 9 Jun 2014 06:27:55 +0200
Subject: [PATCH 450/690] Update 01-chapter1.markdown

The sentence did not make sense, so I hopefully could write it in a more clear format.
---
 de/01-introduction/01-chapter1.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/de/01-introduction/01-chapter1.markdown b/de/01-introduction/01-chapter1.markdown
index ff5c6ef4c..5c60ced9d 100644
--- a/de/01-introduction/01-chapter1.markdown
+++ b/de/01-introduction/01-chapter1.markdown
@@ -340,7 +340,7 @@ Git umfasst das Werkzeug `git config`, das Dir erlaubt, Konfigurationswerte zu v
 
 <!--On Windows systems, Git looks for the `.gitconfig` file in the `$HOME` directory (`%USERPROFILE%` in Windows’ environment), which is `C:\Documents and Settings\$USER` or `C:\Users\$USER` for most people, depending on version (`$USER` is `%USERNAME%` in Windows’ environment). 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.-->
 
-Auf Windows Systemen sucht Git nach der `.gitconfig` Datei im `$HOME` Verzeichnis (für die meisten Leute ist das das Verzeichnis `C:\Dokumente und Einstellungen\$USER`). Git sucht außerdem auch nach dem Verzeichnis /etc/gitconfig, aber es sucht relativ demjenigen Verzeichnis, in dem Du Git mit Hilfe des Installers installiert hast.
+Auf Windows Systemen sucht Git nach der `.gitconfig` Datei im `$HOME` Verzeichnis (für die meisten Leute ist das das Verzeichnis `C:\Dokumente und Einstellungen\$USER`). Es schaut auch immer nach `/etc/gitconfig`, auch wenn dieses relativ zu dem MSys Wurzelverzeichnis ist, welches das ist, wohin Du Git bei der Installation in Windows installiert hast.
 
 <!--### Your Identity ###-->
 ### Deine Identität ###

From 9597815435afd21c146d501a32a7af280455d689 Mon Sep 17 00:00:00 2001
From: Jean-Noel Avila <jn.avila@free.fr>
Date: Mon, 9 Jun 2014 17:38:09 +0200
Subject: [PATCH 451/690] fix  chap 4.

---
 fr/04-git-server/01-chapter4.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fr/04-git-server/01-chapter4.markdown b/fr/04-git-server/01-chapter4.markdown
index 91238f71c..76257d723 100644
--- a/fr/04-git-server/01-chapter4.markdown
+++ b/fr/04-git-server/01-chapter4.markdown
@@ -43,7 +43,7 @@ Ou bien cela :
 	$ git clone file:///opt/git/projet.git
 
 Git opère légèrement différemment si vous spécifiez explicitement le protocole `file://` au début de l'URL.
-Si vous spécifiez simplement le chemin et si la destination se trouve sur le même système de fichiers, Git tente d'utiliser des liens durs pour le fichiers communs.
+Si vous spécifiez simplement le chemin et si la destination se trouve sur le même système de fichiers, Git tente d'utiliser des liens physiques pour le fichiers communs.
 Si la destination se trouve sur un autre système de fichiers, Git fait une copie des fichiers nécessaires.
 Si vous spécifiez le protocole `file://`, Git lance un processus d'accès au travers du réseau, ce qui est généralement moins efficace.
 La raison d'utiliser spécifiquement le préfixe `file://` est la volonté d'obtenir une copie propre du dépôt, sans aucune référence ou aucun objet supplémentaire qui pourraient résulter d'un import depuis un autre système de gestion de version ou d'une action similaire (voir chapitre 9 pour les tâches de maintenance).

From 0ecb87948149ab9e8bdd4a7a5dfb2a334776733b Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Mon, 9 Jun 2014 17:49:55 +0200
Subject: [PATCH 452/690] Updating to current message.

The message is no more confusing.
---
 en/04-git-server/01-chapter4.markdown | 7 +------
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/en/04-git-server/01-chapter4.markdown b/en/04-git-server/01-chapter4.markdown
index 622648798..9d3496693 100644
--- a/en/04-git-server/01-chapter4.markdown
+++ b/en/04-git-server/01-chapter4.markdown
@@ -120,12 +120,7 @@ In order to clone your repository to create a new bare repository, you run the c
 	Cloning into bare repository 'my_project.git'...
 	done.
 
-<!-- This next part doesn't fit the actual output as shown, the confusing part
-     of the output is no longer shown in the command output. I would like to asks
-     the original author to modify the text.
--->
-
-The output for this command is a little confusing. Since `clone` is basically a `git init` then a `git fetch`, we see some output from the `git init` part, which creates an empty directory. The actual object transfer gives no output, but it does happen. You should now have a copy of the Git directory data in your `my_project.git` directory.
+You should now have a copy of the Git directory data in your `my_project.git` directory.
 
 This is roughly equivalent to something like
 

From 995117cde957f1b573aeb02c282989a75c284c82 Mon Sep 17 00:00:00 2001
From: Mengz You <mengz.you@gmail.com>
Date: Tue, 10 Jun 2014 17:10:04 +0800
Subject: [PATCH 453/690] [zh] Simple Chinese translation

Translate the rest of part in Chapter 4.
---
 zh/04-git-server/01-chapter4.markdown | 58 +++++++++++++--------------
 1 file changed, 29 insertions(+), 29 deletions(-)

diff --git a/zh/04-git-server/01-chapter4.markdown b/zh/04-git-server/01-chapter4.markdown
index ae751aeef..ef41b90b2 100644
--- a/zh/04-git-server/01-chapter4.markdown
+++ b/zh/04-git-server/01-chapter4.markdown
@@ -58,7 +58,7 @@ Git 使用的传输协议中最常见的可能就是 SSH 了。这是因为大
 
 	$ git clone user@server:project.git
 
-如果不指明用户，Git 会默认使用当前登录的用户名连接服务器。 
+如果不指明用户，Git 会默认使用当前登录的用户名连接服务器。
 
 #### 优点 ####
 
@@ -293,7 +293,7 @@ HTTP 协议的消极面在于，相对来说客户端效率更低。克隆或者
 	#
 	# To enable this hook, rename this file to "post-update".
 	#
-	
+
 	exec git-update-server-info
 
 意思是当通过 SSH 向服务器推送时，Git 将运行这个 `git-update-server-info` 命令来更新匿名 HTTP 访问获取数据时所需要的文件。
@@ -511,39 +511,39 @@ Gitosis 也具有简单的访问控制功能。如果想让 John 只有读权限
 
 ## Gitolite ##
 
-This section serves as a quick introduction to Gitolite, and provides basic installation and setup instructions.  不能完全替代随 gitolite 自带的大量文档。 There may also be occasional changes to this section itself, so you may also want to look at the latest version [here][gldpg].
+本节作为Gitolite的一个快速指南，指导基本的安装和设置。不能完全替代随Gitolite自带的大量文档。而且可能会随时改变本节内容，因此你也许想看看最新的[版本][gldpg]。
 
 [gldpg]: http://sitaramc.github.com/gitolite/progit.html
 [gltoc]: http://sitaramc.github.com/gitolite/master-toc.html
 
-Gitolite is an authorization layer on top of Git, relying on `sshd` or `httpd` for authentication.  (Recap: authentication is identifying who the user is, authorization is deciding if he is allowed to do what he is attempting to).
+Gitolite是在Git之上的一个授权层，依托`sshd`或者`httpd`来进行认证。（概括：认证是确定用户是谁，授权是决定该用户是否被允许做他想做的事情）。
 
-Gitolite 允许你定义访问许可而不只作用于仓库，而同样于仓库中的每个branch和tag name。你可以定义确切的人 (或一组人) 只能push特定的 "refs" (或者branches或者tags)而不是其他人。
+Gitolite允许你定义访问许可而不只作用于仓库，而同样于仓库中的每个branch和tag name。你可以定义确切的人(或一组人)只能push特定的"refs"(或者branches或者tags)而不是其他人。
 
 ### 安装 ###
 
-安装 Gitolite非常简单, 你甚至不用读自带的那一大堆文档。你需要一个unix服务器上的账户；许多linux变种和solaris 10都已经试过了。你不需要root访问，假设git，perl，和一个openssh兼容的ssh服务器已经装好了。在下面的例子里，我们会用 `git` 账户在 `gitserver`上.
+安装Gitolite非常简单, 你甚至不用读自带的那一大堆文档。你需要一个unix服务器上的账户；许多linux变种和solaris 10都已经试过了。你不需要root访问，假设git，perl，和一个openssh兼容的ssh服务器已经装好了。在下面的例子里，我们会用`git`账户在`gitserver`进行。
 
-Gitolite 是不同于 "server" 的软件 -- 通过ssh访问, 而且每个在服务器上的userid都是一个潜在的 "gitolite host". We will describe the simplest install method in this article; for the other methods please see the documentation.
+Gitolite是不同于“服务”的软件 -- 其通过ssh访问, 而且每个在服务器上的userid都是一个潜在的“gitolite主机”。我们在这里描述最简单的安装方法，对于其他方法，请参考其文档。
 
-To begin, create a user called `git` on your server and login to this user.  Copy your SSH public key (a file called `~/.ssh/id_rsa.pub` if you did a plain `ssh-keygen` with all the defaults) from your workstation, renaming it to `<yourname>.pub` (we'll use `scott.pub` in our examples).  Then run these commands:
+开始，在你的服务器上创建一个名为`git`的用户，然后以这个用户登录。从你的工作站拷贝你的SSH公钥（也就是你用`ssh-keygen`默认生成的`~/.ssh/id_dsa.pub`文件），重命名为`<yourname>.pub`（我们这里使用`scott.pub`作为例子）。然后执行下面的命令：
 
 	$ git clone git://github.com/sitaramc/gitolite
 	$ gitolite/install -ln
 	    # assumes $HOME/bin exists and is in your $PATH
 	$ gitolite setup -pk $HOME/scott.pub
 
-That last command creates new Git repository called `gitolite-admin` on the server.
+最后一个命令在服务器上创建了一个名为`gitolite-admin`的Git仓库。
 
-Finally, back on your workstation, run `git clone git@gitserver:gitolite-admin`. And you’re done!  Gitolite has now been installed on the server, and you now have a brand new repository called `gitolite-admin` in your workstation.  You administer your Gitolite setup by making changes to this repository and pushing.
+最后，回到你的工作站，执行`git clone git@gitserver:gitolite-admin`。然后你就完成了！Gitolite现在已经安装在了服务器上，在你的工作站上，你也有一个名为`gitolite-admin`的新仓库。你可用通过更改这个仓库以及推送到服务器上来管理你的Gitolite配置。
 
 ### 定制安装 ###
 
-默认快速安装对大多数人都管用，还有一些定制安装方法如果你用的上的话。Some changes can be made simply by editing the rc file, but if that is not sufficient, there’s documentation on customising Gitolite.
+默认快速安装对大多数人都管用，还有一些定制安装方法如果你用的上的话。一些设置可以通过编辑rc文件来简单地改变，但是如果这个不够，有关于定制Gitolite的文档供参考。
 
 ### 配置文件和访问规则 ###
 
-安装结束后，你切换到 `gitolite-admin` 仓库 (放在你的 HOME 目录) 然后看看都有啥：
+安装结束后，你切换到`gitolite-admin`仓库（放在你的HOME目录）然后看看都有啥：
 
 	$ cd ~/gitolite-admin/
 	$ ls
@@ -561,11 +561,11 @@ Finally, back on your workstation, run `git clone git@gitserver:gitolite-admin`.
 
 注意 "scott" ( 之前用`gl-setup` 命令时候的 pubkey 名稱) 有读写权限而且在 `gitolite-admin` 仓库里有一个同名的公钥文件。
 
-Adding users is easy.  To add a user called "alice", obtain her public key, name it `alice.pub`, and put it in the `keydir` directory of the clone of the `gitolite-admin` repo you just made on your workstation.  Add, commit, and push the change, and the user has been added.
+添加用户很简单。为了添加一个名为`alice`的用户，获取她的公钥，命名为`alice.pub`，然后放到在你工作站上的`gitolite-admin`克隆的`keydir`目录。添加，提交，然后推送更改。这样用户就被添加了。
 
-gitolite配置文件的语法在 `conf/example.conf`里，我们只会提到一些主要的。
+gitolite配置文件的语法在`conf/example.conf`里，我们只会提到一些主要的。
 
-你可以给用户或者仓库分组。分组名就像一些宏；定义的时候，无所谓他们是工程还是用户；区别在于你’使用‘“宏”的时候
+你可以给用户或者仓库分组。分组名就像一些宏；定义的时候，无所谓他们是工程还是用户；区别在于你*使用*“宏”的时候
 
 	@oss_repos      = linux perl rakudo git gitolite
 	@secret_repos   = fenestra pear
@@ -575,7 +575,7 @@ gitolite配置文件的语法在 `conf/example.conf`里，我们只会提到一
 	@engineers      = sitaram dilbert wally alice
 	@staff          = @admins @engineers @interns
 
-你可以控制许可在 "ref" 级别。在下面的例子里，实习生可以 push "int" branch.  工程师可以 push任何有 "eng-"开头的branch，还有refs/tags下面用 "rc"开头的后面跟数字的。而且管理员可以随便改 (包括rewind) 对任何参考名.
+你可以控制许可在”ref“级别。在下面的例子里，实习生可以push ”int“分支。工程师可以push任何有"eng-"开头的branch，还有refs/tags下面用"rc"开头的后面跟数字的。而且管理员可以随便更改(包括rewind)对任何参考名。
 
 	repo @oss_repos
 	    RW  int$                = @interns
@@ -583,11 +583,11 @@ gitolite配置文件的语法在 `conf/example.conf`里，我们只会提到一
 	    RW  refs/tags/rc[0-9]   = @engineers
 	    RW+                     = @admins
 
-在 `RW` or `RW+`之后的表达式是正则表达式 (regex) 对应着后面的push用的参考名字 (ref) 。所以我们叫它 "参考正则"（refex）！当然，一个 refex 可以比这里表现的更强大，所以如果你对perl的正则表达式不熟的话就不要改过头。
+在`RW`or`RW+`之后的表达式是正则表达式(regex)对应着后面的push用的参考名字(ref)。所以我们叫它”参考正则“（refex）！当然，一个refex可以比这里表现的更强大，所以如果你对perl的正则表达式不熟的话就不要改过头。
 
-同样，你可能猜到了，Gitolite 字头 `refs/heads/` 是一个便捷句法如果参考正则没有用 `refs/`开头。
+同样，你可能猜到了，Gitolite字头`refs/heads/`是一个便捷句法如果参考正则没有用`refs/`开头。
 
-一个这个配置文件语法的重要功能是，所有的仓库的规则不需要在同一个位置。你能报所有普通的东西放在一起，就像上面的对所有 `oss_repos` 的规则那样，然后建一个特殊的规则对后面的特殊案例，就像：
+一个这个配置文件语法的重要功能是，所有的仓库的规则不需要在同一个位置。你能报所有普通的东西放在一起，就像上面的对所有`oss_repos`的规则那样，然后建一个特殊的规则对后面的特殊案例，就像：
 
 	repo gitolite
 	    RW+                     = sitaram
@@ -598,23 +598,23 @@ gitolite配置文件的语法在 `conf/example.conf`里，我们只会提到一
 
 在gitolite里有两级访问控制。第一是在仓库级别；如果你已经读或者写访问过了任何在仓库里的参考，那么你已经读或者写访问仓库了。
 
-第二级，应用只能写访问，通过在仓库里的 branch或者 tag。用户名如果尝试过访问 (`W` 或 `+`)，参考名被更新为已知。访问规则检查是否出现在配置文件里，为这个联合寻找匹配 (但是记得参考名是正则匹配的，不是字符串匹配的)。如果匹配被找到了，push就成功了。不匹配的访问会被拒绝。
+第二级，应用只能写访问，通过在仓库里的branch或者tag。用户名如果尝试过访问 (`W`或`+`)，参考名被更新为已知。访问规则检查是否出现在配置文件里，为这个联合寻找匹配 (但是记得参考名是正则匹配的，不是字符串匹配的)。如果匹配被找到了，push就成功了。不匹配的访问会被拒绝。
 
 ### 带'拒绝'的高级访问控制 ###
 
-目前，我们只看过了许可是 `R`, `RW`, 或者 `RW+`这样子的。但是gitolite还允许另外一种许可：`-`，代表 "拒绝"。这个给了你更多的能力，当然也有一点复杂，因为不匹配并不是唯一的拒绝访问的方法，因此规则的顺序变得无关了！
+目前，我们只看过了许可是`R`,`RW`, 或者`RW+`这样子的。但是gitolite还允许另外一种许可：`-`，代表 ”拒绝“。这个给了你更多的能力，当然也有一点复杂，因为不匹配并不是唯一的拒绝访问的方法，因此规则的顺序变得无关了！
 
-这么说好了，在前面的情况中，我们想要工程师可以 rewind 任意 branch 除了master和 integ。 这里是如何做到的
+这么说好了，在前面的情况中，我们想要工程师可以rewind任意branch除了master和integ。 这里是如何做到的
 
 	    RW  master integ    = @engineers
 	    -   master integ    = @engineers
 	    RW+                 = @engineers
 
-你再一次简单跟随规则从上至下知道你找到一个匹配你的访问模式的，或者拒绝。非rewind push到 master或者 integ 被第一条规则允许。一个 rewind push到那些 refs不匹配第一条规则，掉到第二条，因此被拒绝。任何 push (rewind 或非rewind) 到参考或者其他 master 或者 integ不会被前两条规则匹配，即被第三条规则允许。
+你再一次简单跟随规则从上至下知道你找到一个匹配你的访问模式的，或者拒绝。非rewind push到master或者integ 被第一条规则允许。一个rewind push到那些refs不匹配第一条规则，掉到第二条，因此被拒绝。任何push(rewind或非rewind)到参考或者其他master或者integ不会被前两条规则匹配，即被第三条规则允许。
 
 ### 通过改变文件限制 push ###
 
-此外限制用户 push改变到哪条branch的，你也可以限制哪个文件他们可以碰的到。比如, 可能 Makefile (或者其他哪些程序) 真的不能被任何人做任何改动，因为好多东西都靠着它呢，或者如果某些改变刚好不对就会崩溃。你可以告诉 gitolite:
+此外限制用户push改变到哪条branch的，你也可以限制哪个文件他们可以碰的到。比如, 可能Makefile (或者其他哪些程序) 真的不能被任何人做任何改动，因为好多东西都靠着它呢，或者如果某些改变刚好不对就会崩溃。你可以告诉 gitolite:
 
     repo foo
         RW                      =   @junior_devs @senior_devs
@@ -625,17 +625,17 @@ gitolite配置文件的语法在 `conf/example.conf`里，我们只会提到一
 
 ### 个人分支 ###
 
-Gitolite 也支持一个叫 "个人分支"的功能 (或者叫, "个人分支命名空间") 在合作环境里非常有用。
+Gitolite也支持一个叫”个人分支“的功能 (或者叫, ”个人分支命名空间“) 在合作环境里非常有用。
 
-在 git世界里许多代码交换通过 "pull" 请求发生。然而在合作环境里，委任制的访问是‘绝不’，一个开发者工作站不能认证，你必须push到中心服务器并且叫其他人从那里pull。
+在 git世界里许多代码交换通过”pull“请求发生。然而在合作环境里，委任制的访问是‘绝不’，一个开发者工作站不能认证，你必须push到中心服务器并且叫其他人从那里pull。
 
-这个通常会引起一些 branch 名称簇变成像 VCS里一样集中化，加上设置许可变成管理员的苦差事。
+这个通常会引起一些branch名称簇变成像 VCS里一样集中化，加上设置许可变成管理员的苦差事。
 
-Gitolite让你定义一个 "个人的" 或者 "乱七八糟的" 命名空间字首给每个开发人员 (比如，`refs/personal/<devname>/*`)；看在 `doc/3-faq-tips-etc.mkd`里的 "personal branches" 一段获取细节。
+Gitolite让你定义一个”个人的“或者”乱七八糟的”命名空间字首给每个开发人员(比如，`refs/personal/<devname>/*`)；看在`doc/3-faq-tips-etc.mkd`里的"personal branches"一段获取细节。
 
 ### "通配符" 仓库 ###
 
-Gitolite 允许你定义带通配符的仓库 (其实还是 perl正则式), 比如随便整个例子的话 `assignments/s[0-9][0-9]/a[0-9][0-9]`。 这是一个非常有用的功能，需要通过设置 `$GL_WILDREPOS = 1;` 在 rc文件中启用。允许你安排一个新许可模式 ("C") 允许用户创建仓库基于通配符，自动分配拥有权对特定用户 - 创建者，允许他交出 R和 RW许可给其他合作用户等等。这个功能在`doc/4-wildcard-repositories.mkd`文档里
+Gitolite 允许你定义带通配符的仓库(其实还是perl正则式), 比如随便整个例子的话`assignments/s[0-9][0-9]/a[0-9][0-9]`。 这是一个非常有用的功能，需要通过设置`$GL_WILDREPOS = 1;` 在 rc文件中启用。允许你安排一个新许可模式("C")允许用户创建仓库基于通配符，自动分配拥有权对特定用户 - 创建者，允许他交出 R和 RW许可给其他合作用户等等。这个功能在`doc/4-wildcard-repositories.mkd`文档里
 
 ### 其他功能 ###
 

From 5b3fc96703e1555189aaf3d5022e1d85dcaee31f Mon Sep 17 00:00:00 2001
From: yamel <yevhen@live.com>
Date: Tue, 10 Jun 2014 19:27:00 +0300
Subject: [PATCH 454/690] [uk] Chapter 01, translation

---
 uk/01-introduction/01-chapter1.markdown | 522 ++++++++++++++++++++++++
 1 file changed, 522 insertions(+)
 create mode 100644 uk/01-introduction/01-chapter1.markdown

diff --git a/uk/01-introduction/01-chapter1.markdown b/uk/01-introduction/01-chapter1.markdown
new file mode 100644
index 000000000..dae022f01
--- /dev/null
+++ b/uk/01-introduction/01-chapter1.markdown
@@ -0,0 +1,522 @@
+# Введення #
+
+<!-- # Getting Started # -->
+
+В цьому розділі йдеться про початок роботи з Git.
+
+Знайомство відбувається поступово: пояснення основних принципів роботи систем контролю версій, потім інструкція з запуску Git у вашій системі та врешті-решт опис його налаштування для початку роботи.
+
+Наприкінці розділу ви вже розумітимете передумови виникнення Git, причини та способи його використання саме у ваших проектах та будете готові до практичних дій у цьому напрямі.
+
+<!-- This chapter will be about getting started with Git.  We will begin at the beginning by explaining some background on version control tools, then move on to how to get Git running on your system and finally how to get it setup to start working with.  At the end of this chapter you should understand why Git is around, why you should use it and you should be all setup to do so. -->
+
+## Про контроль версій ##
+
+<!-- ## About Version Control ## -->
+
+Що таке контроль версій і навіщо він вам?
+
+Контроль версій здійснює система, що записує та «запам’ятовує» усі зміни одного чи сукупності файлів, завдяки чому ви можете відновити будь-яку версію пізніше.
+
+Не варто надавати багато значення тому, що у прикладах цієї книги в якості файлів для контролю версій використовуються початкові коди програм. Насправді, для контролю версій можуть використовуватись будь-які файли
+
+<!--What is version control, and why should you care? Version control is a system that records changes to a file or set of files over time so that you can recall specific versions later. Even though the examples in this book show software source code as the files under version control, in reality any type of file on a computer can be placed under version control.-->
+
+Якщо ви графічний чи вебовий дизайнер та бажаєте зберігати кожну копію зображення чи шару, то використання системи контролю версій (СКВ) стане навпрочуд мудрим рішенням.
+
+СКВ дозволяє: повертати до попереднього стану будь-які файли чи увесь проект цілком; переглядати зміни зроблені протягом усього часу; бачити хто вносив правки у щось, що могло викликати проблему; хто і коли додав  зауваження та багато інших рречей.
+
+Використання СКВ також передбачає можливість легкого відновлення файлів у разі їх втрати чи пошкодження. На додачу, все це ви отримуєте за досить невеликих витрат часу та ресурсів системи
+
+<!-- If you are a graphic or web designer and want to keep every version of an image or layout (which you certainly would), it is very wise to use a Version Control System (VCS). A VCS allows you to: revert files back to a previous state, revert the entire project back to a previous state, review changes made over time, see who last modified something that might be causing a problem, who introduced an issue and when, and more. Using a VCS also means that if you screw things up or lose files, you can generally recover easily. In addition, you get all this for very little overhead. -->
+
+### Локальні системи контролю версій ###
+
+<!-- ### Local Version Control Systems ### -->
+
+Багато людей здійснюють контроль версій шляхом простого копіювання файлів до іншої директорії (особливо охайні навіть іменують директорії у хронологічному порядку). Завдяки своїй простоті такий підхід дуже розповсюджений, втім він також неймовірно ненадійний. Адже дуже легко переплутати в якій саме директорії ви зараз знаходитесь і випадково перезаписати не ті файли
+
+<!-- Many people’s version-control method of choice is to copy files into another directory (perhaps a time-stamped directory, if they’re clever). This approach is very common because it is so simple, but it is also incredibly error prone. It is easy to forget which directory you’re in and accidentally write to the wrong file or copy over files you don’t mean to. -->
+
+Для вирішення цієї проблеми були створені локальні СКВ, що мали просту базу даних для зберігання усіх змін необхідних файлів. (див. Ілюстрацію 1-1).
+
+<!-- To deal with this issue, programmers long ago developed local VCSs that had a simple database that kept all the changes to files under revision control (see Figure 1-1). -->
+
+Insert 18333fig0101.png
+Ілюстрація 1-1. Схема локальної системи контролю версій.
+
+<!-- Figure 1-1. Local version control diagram. -->
+
+Однією з найпопулярніших систем цього типу була rcs, що й досі розповсюджується разом з багатьма комп’ютерами. Навіть операційна система Mac OS X отримує команду rcs після встановлення Developer Tools (Інструменти Розробника). Робота цієї програми заснована на зберіганні сукупності патчів (так називаються відмінності між файлами) між версіями у спеціальному форматі на диску. Вона може відновити стан будь якого файлу у будь-який час шляхом застосування усіх патчів.
+
+<!-- One of the more popular VCS tools was a system called rcs, which is still distributed with many computers today. Even the popular Mac OS X operating system includes the rcs command when you install the Developer Tools. This tool basically works by keeping patch sets (that is, the differences between files) from one revision to another in a special format on disk; it can then recreate what any file looked like at any point in time by adding up all the patches. -->
+
+### Централізовані системи контролю версій ###
+
+<!-- ### Centralized Version Control Systems ### -->
+
+Наступною великою проблемою, з якою зіткнулись люди, стала необхідність співпраці з іншими розробниками. В результаті, справу було вирішено завдяки централізованим системам контролю версій (ЦСКВ). Такі системи, як CVS, Subversion та Perforce, складаються з одного сервера, що зберігає усі контрольовані файли, та деякої кількості клієнтів, які отримують файли з цього «центру». Протягом багатьох років це залишалось стандартом у контролі версій (див. Ілюстрацію 1-2).
+
+<!-- The next major issue that people encounter is that they need to collaborate with developers on other systems. To deal with this problem, Centralized Version Control Systems (CVCSs) were developed. These systems, such as CVS, Subversion, and Perforce, have a single server that contains all the versioned files, and a number of clients that check out files from that central place. For many years, this has been the standard for version control (see Figure 1-2). -->
+
+Insert 18333fig0102.png
+Ілюстрація 1-2. Схема централізованої системи контролю версій.
+
+<!-- Figure 1-2. Centralized version control diagram. -->
+
+Така конфігурація має багато переваг, особливо у порівнянні з локальними СКВ. Наприклад, кожен може дізнатись чим займається інший учасник проекту на будь-якому етапі. У адміністраторів є чіткий контроль над тим, хто і що може робити. До того ж, значно простіше адмініструвати централізовану систему, аніж мати справу з локальними базами даних кожного клієнта.
+
+<!-- This setup offers many advantages, especially over local VCSs. For example, everyone knows to a certain degree what everyone else on the project is doing. Administrators have fine-grained control over who can do what; and it’s far easier to administer a CVCS than it is to deal with local databases on every client. -->
+
+Втім, і цей підхід має деякі серйозні вади. Найбільш очевидною є безумовна залежність від одного елементу мережі, що являє собою централізований сервер. Якщо на годину вимкнути сервер, то протягом цієї години стає неможливою взаємодія між учасниками системи та збереження версійних змін до об’єктів, над якими ведеться робота. При пошкодженні жорсткого диску з центральною базою даних та відсутності її резервних копій ви втрачаєте абсолютно все — всю історію проекту, за виключенням хіба що поодиноких знімків, які клієнтам пощастило мати на локальних машинах.
+
+Локальні СКВ страждають від тієї ж проблеми — ризик повної втрати проекту у результаті зберігання усієї історії в одному місці.
+
+<!-- However, this setup also has some serious downsides. The most obvious is the single point of failure that the centralized server represents. If that server goes down for an hour, then during that hour nobody can collaborate at all or save versioned changes to anything they’re working on. If the hard disk the central database is on becomes corrupted, and proper backups haven’t been kept, you lose absolutely everything—the entire history of the project except whatever single snapshots people happen to have on their local machines. Local VCS systems suffer from this same problem—whenever you have the entire history of the project in a single place, you risk losing everything. -->
+
+### Розподілені системи контролю версій ###
+
+<!-- ### Distributed Version Control Systems ### -->
+
+Ось тут в гру вступають розподілені системи контролю версій (РСКВ). У цих системах (наприклад: Git, Mercurial, Bazaar чи Darcs) клієнти мають не лише останній знімок файлів, вони отримують повне дзеркало репозиторію. Тож, за втрати одного з серверів, за допомогою якого відбувається співпраця, будь-який з клієнтських репозиторіїв може бути скопійований назад на сервер для відновлення. Кожне стягування файлів, по суті є повною резервною копією усіх даних (див. Ілюстрацію 1-3).
+
+<!-- This is where Distributed Version Control Systems (DVCSs) step in. In a DVCS (such as Git, Mercurial, Bazaar or Darcs), clients don’t just check out the latest snapshot of the files: they fully mirror the repository. Thus if any server dies, and these systems were collaborating via it, any of the client repositories can be copied back up to the server to restore it. Every checkout is really a full backup of all the data (see Figure 1-3). -->
+
+Insert 18333fig0103.png
+Ілюстрація 1-3. Розподілена система контролю версій.
+
+<!-- Figure 1-3. Distributed version control diagram. -->
+
+Крім того, багато з цих систем чудово працюють з декількома віддаленими репозиторіями. Таким чином, у межах одного проекту ви можете співпрацювати з різними групами людей і різними шляхами одночасно. Це дозволяє налаштувати декілька типів робочих процесів, на відміну від централізованих систем.
+
+<!-- Furthermore, many of these systems deal pretty well with having several remote repositories they can work with, so you can collaborate with different groups of people in different ways simultaneously within the same project. This allows you to set up several types of workflows that aren’t possible in centralized systems, such as hierarchical models. -->
+
+## Коротенький екскурс в історію ##
+
+<!-- ## A Short History of Git ## -->
+
+Як і багато інших видатних речей, Git почався з творчого непорозуміння та гарячих протиріч. Ядро Linux це проект з відкритим програмним кодом достатньо великих розмірів. Протягом більшої частини існування ядра (1991-2002 рр.) зміни у коді передавались у вигляді патчів та архівів. У 2002 році у проекті почала використовуватись пропрієтарна РСКВ під назвою BitKeeper.
+
+<!-- As with many great things in life, Git began with a bit of creative destruction and fiery controversy. The Linux kernel is an open source software project of fairly large scope. For most of the lifetime of the Linux kernel maintenance (1991–2002), changes to the software were passed around as patches and archived files. In 2002, the Linux kernel project began using a proprietary DVCS system called BitKeeper. -->
+
+У 2005 році взаємовідносини між спільнотою розробників ядра та комерційною компанією, що займалась розробкою BitKeeper, погіршились і право безкоштовного користування продуктом було скасовано. Це спонукало спільноту Linux (і особливо Лінуса Торвальдса, засновника Linux) до створення власного інструменту. У пригоді став досвід використання BitKeeper з усіма його перевагами і недоліками. Головні вимоги до нової системи були такі:
+
+<!-- In 2005, the relationship between the community that developed the Linux kernel and the commercial company that developed BitKeeper broke down, and the tool’s free-of-charge status was revoked. This prompted the Linux development community (and in particular Linus Torvalds, the creator of Linux) to develop their own tool based on some of the lessons they learned while using BitKeeper. Some of the goals of the new system were as follows: -->
+
+*   швидкість;
+*   простий дизайн;
+*   підтримка нелінійної розробки (тисячі паралельних гілок);
+*   повна розподільність;
+*   можливість ефективного управління великими проектами на зразок ядра Linux (швидкість та розмір даних).
+
+<!-- 
+*	Speed
+*	Simple design
+*	Strong support for non-linear development (thousands of parallel branches)
+*	Fully distributed
+*	Able to handle large projects like the Linux kernel efficiently (speed and data size)
+-->
+
+Від свого створення у 2005 Git розвивався зберігаючи простоту використання, але не втрачаючи цих початкових орієнтирів. Він неймовірно швидкий, ефективний на великих проектах і має вражаючу систему розгалужування для нелінійної розробки (див. Розділ 3).
+
+<!-- Since its birth in 2005, Git has evolved and matured to be easy to use and yet retain these initial qualities. It’s incredibly fast, it’s very efficient with large projects, and it has an incredible branching system for non-linear development (See Chapter 3). -->
+
+## Основи Git ##
+
+<!-- ## Git Basics ## -->
+
+Отже, що таке Git у двох словах?
+
+Це дуже важливо засвоїти, оскільки, зрозумівши основи та принципи функціонування Git, ви зможете використовувати його більш ефективно і з меншими зусиллями.
+
+На час знайомства з Git спробуйте забути все що ви знаєте про інші СКВ. Це дозволить уникнути деяких непорозумінь.
+
+Git зберігає інформацію та оперує нею дещо по-іншому, ніж інші системи, навіть попри схожий користувацький інтерфейс. Розуміння цих відмінностей допоможе уникнути плутанини у подальшому.
+
+<!-- So, what is Git in a nutshell? This is an important section to absorb, because if you understand what Git is and the fundamentals of how it works, then using Git effectively will probably be much easier for you. As you learn Git, try to clear your mind of the things you may know about other VCSs, such as Subversion and Perforce; doing so will help you avoid subtle confusion when using the tool. Git stores and thinks about information much differently than these other systems, even though the user interface is fairly similar; understanding those differences will help prevent you from becoming confused while using it. -->
+
+### Знімки ###
+
+<!-- ### Snapshots, Not Differences ### -->
+
+Однією з головних відмінностей від інших систем (таких як Subversion та подібних їй) є те, як Git сприймає дані.
+
+Більшість СКВ зберігають інформацію як список файлових редагувань. Ці системи (CVS, Subversion, Perforce, Bazaar) розглядають інформацію як список файлів та їх змін, що показано на Ілюстрації 1-4.
+
+<!-- The major difference between Git and any other VCS (Subversion and friends included) is the way Git thinks about its data. Conceptually, most other systems store information as a list of file-based changes. These systems (CVS, Subversion, Perforce, Bazaar, and so on) think of the information they keep as a set of files and the changes made to each file over time, as illustrated in Figure 1-4. -->
+
+Insert 18333fig0104.png
+Ілюстрація 1-4. Інші системи зберігають дані як список змін до початкової версії кожного файлу.
+<!-- Figure 1-4. Other systems tend to store data as changes to a base version of each file. -->
+
+Git сприймає та зберігає інформацію по-іншому. Git розглядає свої дані ніби сукупність знімків невеликої файлової системи. Щоразу, при збереженні поточного стану проекту, Git робить знімок (копію) того, як виглядають ваші файли саме у цей момент і зберігає посилання на цей знімок. Для ефективності, якщо файл не змінився, Git не збергіє його знову, а просто робить посилання на ідентичний файл з попередньої фіксації змін. Схематичне зображення такого підходу показано нижче.
+
+<!-- Git doesn’t think of or store its data this way. Instead, Git thinks of its data more like a set of snapshots of a mini filesystem. Every time you commit, or save the state of your project in Git, it basically takes a picture of what all your files look like at that moment and stores a reference to that snapshot. To be efficient, if files have not changed, Git doesn’t store the file again—just a link to the previous identical file it has already stored. Git thinks about its data more like Figure 1-5. -->
+
+Insert 18333fig0105.png
+Ілюстрація 1-5. Git зберігає дані як знімки проекту за хронологією.
+
+<!-- Figure 1-5. Git stores data as snapshots of the project over time. -->
+
+Це дуже важлива різниця між Git та іншими СКВ. З цієї причини у Git було заново переосмислено майже кожен аспект контролю версій, що зробило його схожим на мініатюрну файлову систему з деякими неймовірно потужними вбудованими інструментами. Ми познайомимось з деякими перевагами, які ви отримаєте при сприйнятті інформації подібним чином, у третьому розділі, де йдеться про гілки.
+
+<!-- This is an important distinction between Git and nearly all other VCSs. It makes Git reconsider almost every aspect of version control that most other systems copied from the previous generation. This makes Git more like a mini filesystem with some incredibly powerful tools built on top of it, rather than simply a VCS. We’ll explore some of the benefits you gain by thinking of your data this way when we cover Git branching in Chapter 3. -->
+
+### Майже кожна операція — локальна  ###
+
+<!-- ### Nearly Every Operation Is Local ### -->
+
+Більшість операцій в Git потребують лише локальних файлів та ресурсів для здійснення операцій — немає небхідності у інформації з інших комп’ютерів вашої мережі. Якщо ви працюєте з ЦСКВ, де більшість операцій обтяжені такими мережевими запитами, то цей аспект може привести вас до думки, що боги швидкості наділили Git неземною силою. Через те, що повна історія проекту знаходиться на вашому локльному диску, більшість операцій здійснюються майже миттєво.
+
+<!-- Most operations in Git only need local files and resources to operate — generally no information is needed from another computer on your network.  If you’re used to a CVCS where most operations have that network latency overhead, this aspect of Git will make you think that the gods of speed have blessed Git with unworldly powers. Because you have the entire history of the project right there on your local disk, most operations seem almost instantaneous. -->
+
+Наприклад, для перегляду історії, Git не має потреби брати її з серверу, він просто зчитує її прямо з локальної бази даних. Це означає, що ви отримуєте історію проекту не встигнувши кліпнути оком. Якщо ви бажаєте переглянути відмінності між поточною версією файлу та його редакцією місячної давності, Git знайде копію збережену місяць тому і проведе локальний розрахунок замість того, щоб звертатись за цим до віддаленого серверу чи спочатку робити запит на отримання старішої версії файлу.
+
+<!-- For example, to browse the history of the project, Git doesn’t need to go out to the server to get the history and display it for you—it simply reads it directly from your local database. This means you see the project history almost instantly. If you want to see the changes introduced between the current version of a file and the file a month ago, Git can look up the file a month ago and do a local difference calculation, instead of having to either ask a remote server to do it or pull an older version of the file from the remote server to do it locally. -->
+
+Також це значить, що за відсутності мережевого з’єднання ви не будете мати особливих обмежень. Перебуваючи у літаку чи потязі можна цілком комфортно фіксувати зміни поки не відновите з’єднання з мережею для їх завантаження. Дорогою додому, не маючи змоги належним чином використовувати свій VPN-клієнт, все одно можна продовжувати роботу. В багатьох інших системах подібні дії або неможливі, або пов’язані з безліччю труднощів. Наприклад, в Perforce, без з’єднання з мережею вам не вдасться зробити багато; у Subversion та CVS ви можете редагувати файли, але не можете фіксувати внесені зміни (оскільки немає зв’язку з базою даних). На перший погляд такі речі здаються незначним, але ви будете вражені наскільки велике значення вони можуть мати.
+
+<!-- This also means that there is very little you can’t do if you’re offline or off VPN. If you get on an airplane or a train and want to do a little work, you can commit happily until you get to a network connection to upload. If you go home and can’t get your VPN client working properly, you can still work. In many other systems, doing so is either impossible or painful. In Perforce, for example, you can’t do much when you aren’t connected to the server; and in Subversion and CVS, you can edit files, but you can’t commit changes to your database (because your database is offline). This may not seem like a huge deal, but you may be surprised what a big difference it can make. -->
+
+### Git виконує перевірку цілісності даних ###
+
+<!-- ### Git Has Integrity ### -->
+
+Будь-що у Git, перед збереженням, отримує контрольну суму, за якою потім і перевіряється. Таким чином, неможливо змінити файл чи директорію так, щоб Git про це не дізнався. Цей функціонал вбудовано у систему на найнижчих рівнях і є складовою частиною її філософії. Ви не можете втратити інформацію при передачі чи отримати пошкоджений файл без відома Git.
+
+<!-- Everything in Git is check-summed before it is stored and is then referred to by that checksum. This means it’s impossible to change the contents of any file or directory without Git knowing about it. This functionality is built into Git at the lowest levels and is integral to its philosophy. You can’t lose information in transit or get file corruption without Git being able to detect it. -->
+
+Механізм, який використовується для цього контролю, називається хеш SHA-1. Він являє собою 40-символьну послідовність цифр та перших літер латинського алфавіту (a-f) і вираховується на основі вмісту файлу чи структури директорії. Виглядає це приблизно так:
+
+    24b9da6552252987aa493b52f8696cd6d3b00373
+
+При роботі з Git ви постійно зустрічатимете такі хеші. Фактично, Git зберігає все не за назвою файлу, а саме за такими адресами.
+
+<!-- The mechanism that Git uses for this checksumming is called a SHA-1 hash. This is a 40-character string composed of hexadecimal characters (0–9 and a–f) and calculated based on the contents of a file or directory structure in Git. A SHA-1 hash looks something like this:
+
+	24b9da6552252987aa493b52f8696cd6d3b00373
+
+You will see these hash values all over the place in Git because it uses them so much. In fact, Git stores everything not by file name but in the Git database addressable by the hash value of its contents. -->
+
+### Git, зазвичай, тільки додає дані ###
+
+<!-- ### Git Generally Only Adds Data ### -->
+
+Коли ви виконуєте певні дії в Git, при цьому, майже завжди відбувається додавання інформації до її бази даних. Дуже складно змусити систему зробити щось невиправне чи повністю видалити дані. Як і в будь-якій СКВ, ви можете втратити чи зіпсувати лише незафіксовані зміни. Але це майже неможливо, коли вже зроблено знімок, особливо, якщо ви регулярно надсилаєте свою базу до іншого репозиторію.
+
+<!-- When you do actions in Git, nearly all of them only add data to the Git database. It is very difficult to get the system to do anything that is not undoable or to make it erase data in any way. As in any VCS, you can lose or mess up changes you haven’t committed yet; but after you commit a snapshot into Git, it is very difficult to lose, especially if you regularly push your database to another repository. -->
+
+Це робить використання Git приємним, оскільки можна експериментувати без загрози щось зіпсувати.
+
+Про те, як Git зберігає інформацію та як можна відновити втрачені дані, детальніше розповідається у Розділі 9.
+
+<!-- This makes using Git a joy because we know we can experiment without the danger of severely screwing things up. For a more in-depth look at how Git stores its data and how you can recover data that seems lost, see Chapter 9. -->
+
+### Три стани ###
+
+<!-- ### The Three States ### -->
+
+А зараз, будьте уважні. Це найважливіша річ, яку потрібно запам’ятати, якщо ви хочете щоб подальше вивчення Git пройшло гладко.
+
+Git має три основних стани, у яких можуть перебувати ваші файли: зафіксований, змінений та доданий.
+
+Зафіксований — значить, дані безпечно збережено в локальній базі даних.
+
+Змінений означає, що у файл внесено редагування, які ще не зафіксовано у базі даних.
+
+Доданий стан виникає тоді, коли ви позначаєте змінений файл у поточній версії, готуючи його таким чином до фіксації.
+
+<!-- Now, pay attention. This is the main thing to remember about Git if you want the rest of your learning process to go smoothly. Git has three main states that your files can reside in: committed, modified, and staged. Committed means that the data is safely stored in your local database. Modified means that you have changed the file but have not committed it to your database yet. Staged means that you have marked a modified file in its current version to go into your next commit snapshot. -->
+
+Це приводить нас до трьох головних відділів проекту під управлінням Git: директорія Git, робоча директорія та область додавання.
+
+<!-- This leads us to the three main sections of a Git project: the Git directory, the working directory, and the staging area. -->
+
+Insert 18333fig0106.png
+Ілюстрація 1-6. Робоча директорія, область додавання та директорія Git.
+
+<!-- Figure 1-6. Working directory, staging area, and git directory. -->
+
+У директорії Git система зберігає метадані та базу даних об’єктів вашого проекту. Це найважливіша частина проекту. Саме вона копіюється при клонуванні проекту з іншого комп’ютеру.
+
+<!-- The Git directory is where Git stores the metadata and object database for your project. This is the most important part of Git, and it is what is copied when you clone a repository from another computer. -->
+
+Робоча директорія являє собою файли і директорії проекту у поточному стані. Ці об’єкти видобуваються з бази даних (яка, пригадаємо, зберігається у директорії Git) і розміщуються на диску для подальшого використання та редагування.
+
+<!-- The working directory is a single checkout of one version of the project. These files are pulled out of the compressed database in the Git directory and placed on disk for you to use or modify. -->
+
+Область додавання це простий файл, що зазвичай знаходиться у директорії Git і містить інформацію про об’єкти, стан яких буде враховано під час наступної фіксації змін.
+
+<!-- The staging area is a simple file, generally contained in your Git directory, that stores information about what will go into your next commit. It’s sometimes referred to as the index, but it’s becoming standard to refer to it as the staging area. -->
+
+Найпростіший процес взаємодії з Git виглядає приблизно так:
+
+1. Ви редагуєте файли у своїй робочій директорії.
+2. Надсилаєте файли в область додавання, шляхом створення знімків їх поточного стану.
+3. Робите фіксацію, яка бере файли в області додавання і остаточно зберігає цей знімок у директорії Git.
+
+<!-- The basic Git workflow goes something like this:
+
+1. You modify files in your working directory.
+2. You stage the files, adding snapshots of them to your staging area.
+3. You do a commit, which takes the files as they are in the staging area and stores that snapshot permanently to your Git directory. -->
+
+У випадку, якщо окрема версія файлу вже є у директорії Git, цей файл вважається зафіксованим. Якщо він зазнав змін і перебуває в області додавання, то він доданий. Якщо ж його стан відрізняється від того, який було зафіксовано, і файл не знаходиться в області додавання, то він називається зміненим.
+
+У наступному розділі ви дізнаєтесь більше про ці стани, а також про те, як використовувати їхні переваги або взагалі пропускати етап області додавання.
+
+<!-- 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. -->
+
+## Встановлення Git ##
+
+<!-- ## Installing Git ## -->
+
+Перш за все, для використання Git, ви маєте його встановити. Для цього існує декілька способів; два найбільш вживаних це встановлення з сирців та встановлення існуючого пакунку для вашої платформи.
+
+<!-- Let’s get into using some Git. First things first—you have to install it. You can get it a number of ways; the two major ones are to install it from source or to install an existing package for your platform. -->
+
+### Встановлення з джерельного коду ###
+
+<!-- ### Installing from Source ### -->
+
+Встановлення Git з джерельного коду є дуже корисним, оскільки ви отримуєте найсвіжішу версію. У кожній новій версії системи зберігається тенденція до покращення елементів користувацького інтерфейсу, тож встановлення останньої версії це найкращий шлях, якщо ви володієте навиками компіляції програм з сирців. Крім того, багато дистрибутивів Лінукс містять досить застарілі пакунки, що може слугувати одним з приводів до цього способу встановлення.
+
+<!-- If you can, it’s generally useful to install Git from source, because you’ll get the most recent version. Each version of Git tends to include useful UI enhancements, so getting the latest version is often the best route if you feel comfortable compiling software from source. It is also the case that many Linux distributions contain very old packages; so unless you’re on a very up-to-date distro or are using backports, installing from source may be the best bet. -->
+
+Для встановлення Git вам знадобляться бібліотеки, від яких залежить система: curl, zlib, openssl, expat та libiconv. Якщо ви користуєтесь системою, в якій є утиліта yum (наприклад, Fedora) чи apt-get (будь-яка система на основі Debian — Ubuntu, Mint тощо), для встановлення цих залежностей в нагоді вам може стати одна з таких команд:
+
+<!-- To install Git, you need to have the following libraries that Git depends on: curl, zlib, openssl, expat, and libiconv. For example, if you’re on a system that has yum (such as Fedora) or apt-get (such as a Debian based system), you can use one of these commands to install all of the dependencies: -->
+
+	$ yum install curl-devel expat-devel gettext-devel \
+	  openssl-devel zlib-devel
+
+	$ apt-get install libcurl4-gnutls-dev libexpat1-dev gettext \
+	  libz-dev libssl-dev
+
+Після отримання необхідних компонентів, можна рухатись далі і стягнути останній знімок системи Git з офіційного сайту:
+
+<!-- When you have all the necessary dependencies, you can go ahead and grab the latest snapshot from the Git web site: -->
+
+	http://git-scm.com/download
+
+Потім компіляція і встановлення:
+
+<!-- Then, compile and install: -->
+
+	$ tar -zxf git-1.7.2.2.tar.gz
+	$ cd git-1.7.2.2
+	$ make prefix=/usr/local all
+	$ sudo make prefix=/usr/local install
+
+Коли все вишевказане виконано, ви можете завершити процес оновленням Git його власними засобами:
+
+<!-- After this is done, you can also get Git via Git itself for updates: -->
+
+	$ git clone git://git.kernel.org/pub/scm/git/git.git
+
+### Встановлення на Linux ###
+
+<!-- ### Installing on Linux ### -->
+
+Якщо бажаєте встановити Git у системі Linux, можете скористатись вбудованим менеджером пакунків. Наприклад, у Fedora це робиться так:
+
+<!-- If you want to install Git on Linux via a binary installer, you can generally do so through the basic package-management tool that comes with your distribution. If you’re on Fedora, you can use yum: -->
+
+	$ yum install git-core
+
+Якщо ж ви користувач дистрибутиву базованого на Debian чи його нащадках (як Ubuntu, Mint чи elementary), спробуйте apt-get:
+
+<!-- Or if you’re on a Debian-based distribution like Ubuntu, try apt-get: -->
+
+	$ apt-get install git
+
+Крім того, багато сучасних дистрибутивів мають графічний інтерфейс управління програмним оточенням — це найпростіший шлях встановлення, а всі залежності підтягнуться автоматично.
+
+### Встановлення на Mac ###
+
+<!-- ### Installing on Mac ### -->
+
+Існує два простих шляхи встановлення Git на Mac.
+
+Найпростішим є використання графічного інсталятору, який можна звантажити з його сторінки на сервісі Google Code:
+
+<!-- There are two easy ways to install Git on a Mac. The easiest is to use the graphical Git installer, which you can download from the Google Code page (see Figure 1-7): -->
+
+	http://code.google.com/p/git-osx-installer
+
+Insert 18333fig0107.png
+Ілюстрація 1-7. Програма встановлення Git в OS X. 
+
+<!-- Figure 1-7. Git OS X installer. -->
+
+Іншим розповсюдженим способом є встановлення за допомогою MacPorts (`http://www.macports.org`). Якщо маєте цей пакет, встановіть Git командою:
+
+<!-- The other major way is to install Git via MacPorts (`http://www.macports.org`). If you have MacPorts installed, install Git via -->
+
+	$ sudo port install git-core +svn +doc +bash_completion +gitweb
+
+Вам не обов’язково мати всі розширення. Але якщо коли-небудь ви будете використовувати Git з репозиторіями Subversion, вам знадобиться +svn (детальніше у Розділі 8).
+
+<!-- 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). -->
+
+### Встановлення на Windows ###
+
+<!-- ### Installing on Windows ### -->
+
+Встановлення Git на комп’ютері під управлінням операційної системи Windows не повинно викликати проблем.
+
+Одну з найпростіших процедур встановлення пропонує проект msysGit. Просто звантажте встановлювач зі сторінки на GitHub і запустіть процес встановлення:
+
+<!-- Installing Git on Windows is very easy. The msysGit project has one of the easier installation procedures. Simply download the installer exe file from the GitHub page, and run it: -->
+
+	http://msysgit.github.com/
+
+Після встановлення, ви отримаєте і командний рядок (що включає також SSH клієнт), і стандартний графічний інтерфейс.
+
+<!-- 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. -->
+
+Примітка: ви можете використовувати Git з командним рядком msysGit, він допускає набори команд, що наводяться в цій книзі. Якщо ж, з якихось причин, вам потрібно використовувати вбудований у Windows командний рядок, то замість простих одинарних лапок потрібно використовувати подвійні (наприклад, для параметрів, що містять пробіли чи закінчуються символом "^", оскільки це символ продовження).
+
+<!-- Note on Windows usage: you should use Git with the provided msysGit shell (Unix style), it allows to use the complex lines of command given in this book. If you need, for some reason, to use the native Windows shell / command line console, you have to use double quotes instead of simple quotes (for parameters with spaces in them) and you must quote the parameters ending with the circumflex accent (^) if they are last on the line, as it is a continuation symbol in Windows. -->
+
+## Початкове налаштування ##
+
+<!-- ## First-Time Git Setup ## -->
+
+Тепер, маючи у своїй системі Git, варто зробити деякі налаштування його середовища. Це потрібно зробити лише один раз, оновлення не перезаписуватимуть їх. Втім, ви завжди можете внести зміни, повторно виконавши потрібні команди.
+
+<!-- Now that you have Git on your system, you’ll want to do a few things to customize your Git environment. You should have to do these things only once; they’ll stick around between upgrades. You can also change them at any time by running through the commands again. -->
+
+Git містить інструмент під назвою "git config", що дозволяє переглядати та встановлювати налаштування, від яких залежить вигляд та функціонал Git. Ці налаштування можуть зберігатись у трьох різних місцях:
+
+<!-- Git comes with a tool called git config that lets you get and set configuration variables that control all aspects of how Git looks and operates. These variables can be stored in three different places: -->
+
+*   файл `/etc/gitconfig`: містить значення змінних усіх користувачів системи та їхніх репозиторіїв. Для звернення до цього файлу потрібно в команду `git config` передати параметр `--system`.
+
+<!-- *	`/etc/gitconfig` file: Contains values for every user on the system and all their repositories. If you pass the option` --system` to `git config`, it reads and writes from this file specifically. -->
+
+*   файл `~/.gitconfig` містить налаштування лише для вашого користувача. Працювати з цим файлом можна за допомогою опції `--global`.
+
+<!-- *	`~/.gitconfig` file: Specific to your user. You can make Git read and write to this file specifically by passing the `--global` option. -->
+
+*   конфігураційний файл у директорії Git (`.git/config`) стосується лише цього окремого репозиторію. Значення кожного наступного равня мають пріоритет перед попереднім, тож значення з `.git/config` більш важливі, ніж з `/etc/gitconfig`. 
+
+<!-- *	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`. -->
+
+У системі Windows Git шукатиме файл `.gitconfig` у директорії `$HOME` (`%USERPROFILE%` у системному середовищі), що зазвичай вказує на `C:\Documents and Settings\$USER` або `C:\Users\$USER`, в залежності від версії операційної системи. Крім того, шукатиметься також файл /etc/gitconfig, що пов’язаний з кореневою директорією MSys, яка знаходиться там, де ви вирішили встановити Git.
+
+<!-- On Windows systems, Git looks for the `.gitconfig` file in the `$HOME` directory (`%USERPROFILE%` in Windows’ environment), which is `C:\Documents and Settings\$USER` or `C:\Users\$USER` for most people, depending on version (`$USER` is `%USERNAME%` in Windows’ environment). It also still looks for /etc/gitconfig, although it’s relative to the MSys root, which is wherever you decide to install Git on your Windows system when you run the installer. -->
+
+### Особисті налаштування ###
+
+<!-- ### Your Identity ### -->
+
+Перша річ, про яку варто подбати після встановлення Git, вказати ваше ім’я та адресу електронної пошти. Це важливо, оскільки кожна фіксація змін використовує цю інформацію і записує її у дані про знімки:
+
+<!-- The first thing you should do when you install Git is to set your user name and e-mail address. This is important because every Git commit uses this information, and it’s immutably baked into the commits you pass around: -->
+
+	$ git config --global user.name "Ivan Franko"
+	$ git config --global user.email ivanfranko@example.com
+
+Знову ж таки, за умови використання параметру `--global`, вам знадобиться виконати цю дію лише одного разу. Git постійно використовуватиме вказану інформацію для кожної з ваших дій у цій системі. Змінити введені ім’я чи адресу пошти для окремих проектів можна, знаходячись у директорії проекту, тими ж командами, але вже без використання параметру `--global`.
+
+<!-- Again, you need to do this only once if you pass the `--global` option, because then Git will always use that information for anything you do on that system. If you want to override this with a different name or e-mail address for specific projects, you can run the command without the `--global` option when you’re in that project. -->
+
+### Редактор ###
+
+<!-- ### Your Editor ### -->
+
+Тепер, коли особисті налаштування у порядку, ви можете вказати який текстовий редактор бажаєте використовувати у випадках, коли знадобиться вводити текстову інформацію. Типово Git використовує редактор, що є стандартним у системі (зазвичай це Vi чи Vim). Для того щоб змінити його на інший (наприклад, Emacs), потрібно виконати таку команду: 
+
+<!-- Now that your identity is set up, you can configure the default text editor that will be used when Git needs you to type in a message. By default, Git uses your system’s default editor, which is generally Vi or Vim. If you want to use a different text editor, such as Emacs, you can do the following: -->
+
+	$ git config --global core.editor emacs
+
+### Утиліта порівняння ###
+
+<!-- ### Your Diff Tool ### -->
+
+Іншою корисною опцією може бути використання певної утиліти порівняння, що буде використовуватись для розв’язання конфліктів при об’єднанні знімків. Припустімо, це має бути vimdiff:
+
+<!-- Another useful option you may want to configure is the default diff tool to use to resolve merge conflicts. Say you want to use vimdiff: -->
+
+	$ git config --global merge.tool vimdiff
+
+Git сприймає kdiff3, tkdiff, meld, xxdiff, emerge, vimdiff, gvimdiff, ecmerge, та opendiff у якості коректних значень. Також ви можете вказати інший інструмент, про що більш детальніше розповідається у Розділі 7.
+
+<!-- Git accepts kdiff3, tkdiff, meld, xxdiff, emerge, vimdiff, gvimdiff, ecmerge, and opendiff as valid merge tools. You can also set up a custom tool; see Chapter 7 for more information about doing that. -->
+
+### Перевірка налаштувань ###
+
+<!-- ### Checking Your Settings ### -->
+
+Для перегляду своїх налаштувань використовуйте команду `git config --list`:
+
+<!-- If you want to check your settings, you can use the `git config --list` command to list all the settings Git can find at that point: -->
+
+	$ git config --list
+	user.name=Taras Shevchenko
+	user.email=taras@example.com
+	color.status=auto
+	color.branch=auto
+	color.interactive=auto
+	color.diff=auto
+	...
+	
+<!--$ git config --list
+    user.name=Scott Chacon
+	user.email=schacon@gmail.com
+	color.status=auto
+	color.branch=auto
+	color.interactive=auto
+	color.diff=auto
+	... -->
+
+Деякі ключі можуть зустрічатись декілька разів. Це може статись через те, що Git шукає значення у різних місцях (наприклад, `/etc/gitconfig` та `~/.gitconfg`). В такому випадку, Git використовує останнє знайдене значення для кожного з ключів.
+
+<!-- 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. -->
+
+Також, за допомогою конструкції `git config {key}` можна перевірити значення певного ключа:
+
+<!-- You can also check what Git thinks a specific key’s value is by typing `git config {key}`: -->
+
+    $ git config user.name
+	Taras Shevchenko
+	
+<!-- $ git config user.name
+    Scott Chacon -->
+
+## Отримання допомоги ##
+
+<!-- ## Getting Help ## -->
+
+У випадку, якщо вам знадобиться допомога, існує три шляхи доступу до керівництва з використання для будь-якої команди Git:
+
+<!-- If you ever need help while using Git, there are three ways to get the manual page (manpage) help for any of the Git commands: -->
+
+	$ git help <verb>
+	$ git <verb> --help
+	$ man git-<verb>
+
+Наприклад, так ви можете переглянути допоміжну інформацію щодо використання команди config:
+
+<!-- For example, you can get the manpage help for the config command by running -->
+
+	$ git help config
+
+Особлива зручність цих команд у том, що вони доступні навіть без підключення до мережі.
+
+Якщо ж офіційного керівництва  і цієї книжки буде недостатньо, і вам знадобиться персональна допомога, спробуйте під’єднатись до каналу `#git` або `#github` на IRC сервері Freenode. Там постійно перебувають сотні людей, що добре розуміються на роботі з Git і готові допомогти. 
+
+<!-- These commands are nice because you can access them anywhere, even offline.
+If the manpages and this book aren’t enough and you need in-person help, you can try the `#git` or `#github` channel on the Freenode IRC server (irc.freenode.net). These channels are regularly filled with hundreds of people who are all very knowledgeable about Git and are often willing to help. -->
+
+## Підсумок ##
+
+<!-- ## Summary ## -->
+
+Тепер ви знаєте що таке Git і в чому його відмінність від централізованих систем контролю версій, з якими ви, можливо, вже знайомі. Також ви отримали у своїй системі робочу версію Git з персональними налаштуваннями.
+
+Настав час дізнатись про Git більше.
+
+<!-- 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. -->

From 411ed8eafc2e3ba623416697b09afeb75ab287fe Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Mon, 9 Jun 2014 17:23:01 +0200
Subject: [PATCH 455/690] [it] Update command line output in Chapter 2

Git doesn't strip content from the commit message
PR#761
---
 it/02-git-basics/01-chapter2.markdown | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/it/02-git-basics/01-chapter2.markdown b/it/02-git-basics/01-chapter2.markdown
index 37e424f01..ef9a148e5 100644
--- a/it/02-git-basics/01-chapter2.markdown
+++ b/it/02-git-basics/01-chapter2.markdown
@@ -323,8 +323,8 @@ Come vedi, il messaggio predefinito della commit contiene l'ultimo output del co
 
 In alternativa, puoi inserire il messaggio per la tua commit alla riga di comando della `commit` specificando l'opzione -m, come segue:
 
-	$ git commit -m "Story 182: Fix benchmarks for speed"
-	[master 463dc4f] Fix benchmarks for speed
+	$ git commit -m "Storia 182: Corretti benchmarks per la velocità"
+	[master 463dc4f] Storia 182: Corretti benchmarks per la velocità
 	 2 files changed, 3 insertions(+)
 	 create mode 100644 README
 

From b002cf8fdaeff37b5b2c4f98cd24c62796771092 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Mon, 9 Jun 2014 17:34:42 +0200
Subject: [PATCH 456/690] [it] translating chapter 6

---
 it/06-git-tools/01-chapter6.markdown | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/it/06-git-tools/01-chapter6.markdown b/it/06-git-tools/01-chapter6.markdown
index 26d1e0821..a8a40b57f 100644
--- a/it/06-git-tools/01-chapter6.markdown
+++ b/it/06-git-tools/01-chapter6.markdown
@@ -525,13 +525,13 @@ Se accantoni del lavoro e lo lasci lì mentre continui a lavorare per un po' nel
 	Dropped refs/stash@{0} (f0dfc4d5dc332d1cee34a634182e168c4efc3359)
 
 Questa è una bella accorciatoioa per recuperare il lavoro accantonato e lavorarci in una nuova diramazione.
-<!-- da tradurre fino a riga 840 -->
-## Rewriting History ##
 
-Many times, when working with Git, you may want to revise your commit history for some reason. One of the great things about Git is that it allows you to make decisions at the last possible moment. You can decide what files go into which commits right before you commit with the staging area, you can decide that you didn’t mean to be working on something yet with the stash command, and you can rewrite commits that already happened so they look like they happened in a different way. This can involve changing the order of the commits, changing messages or modifying files in a commit, squashing together or splitting apart commits, or removing commits entirely — all before you share your work with others.
+## Riscrivere la storia ##
 
-In this section, you’ll cover how to accomplish these very useful tasks so that you can make your commit history look the way you want before you share it with others.
+Molto spesso, lavorando con Git, you may want to revise your commit history for some reason. One of the great things about Git is that it allows you to make decisions at the last possible moment. You can decide what files go into which commits right before you commit with the staging area, you can decide that you didn’t mean to be working on something yet with the stash command, and you can rewrite commits that already happened so they look like they happened in a different way. This can involve changing the order of the commits, changing messages or modifying files in a commit, squashing together or splitting apart commits, or removing commits entirely — all before you share your work with others.
 
+In this section, you’ll cover how to accomplish these very useful tasks so that you can make your commit history look the way you want before you share it with others.
+<!-- da tradurre fino a riga 840 -->
 ### Changing the Last Commit ###
 
 Changing your last commit is probably the most common rewriting of history that you’ll do. You’ll often want to do two basic things to your last commit: change the commit message, or change the snapshot you just recorded by adding, changing and removing files.

From 9b0c3e8f6aa8544fe5217f1939ac3c8058595a29 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Mon, 9 Jun 2014 17:55:37 +0200
Subject: [PATCH 457/690] [it] Add a chmod on the ~/.ssh on server

As per merged PR#777
---
 it/04-git-server/01-chapter4.markdown | 12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/it/04-git-server/01-chapter4.markdown b/it/04-git-server/01-chapter4.markdown
index 56a46cd8c..23de5a0a5 100644
--- a/it/04-git-server/01-chapter4.markdown
+++ b/it/04-git-server/01-chapter4.markdown
@@ -117,9 +117,10 @@ Per inizializzare un qualsiasi server Git, devi esportare un repository esistent
 Per clonare il tuo repository per creare un nuovo repository di soli dati, devi avviare il comando clone con l'opzione `--bare`. Convenzionalmente, un repository di soli dati in finisce in `.git`, ad esempio:
 
 	$ git clone --bare my_project my_project.git
-	Initialized empty Git repository in /opt/projects/my_project.git/
+	Cloning into bare repository 'my_project.git'...
+  	done.
 
-L'output di questo comando confonde un pochino. Dato che `clone` è un `git init` quindi un `git fetch`, vediamo parte dell'output dalla parte `git init`, il quale crea una directory vuota. L'effecttivo trasferimento dell'oggetto non fornisce output, ma avviene. Ora dovresti avere una copia della directory dei dati di Git nella directory `my_project.git`.
+Ora dovresti avere una copia della directory dei dati di Git nella directory `my_project.git`.
 
 La stessa cosa la si può ottenere con
 
@@ -226,7 +227,12 @@ Devi solo aggiungerle al tuo file `authorized_keys`:
 	$ cat /tmp/id_rsa.josie.pub >> ~/.ssh/authorized_keys
 	$ cat /tmp/id_rsa.jessica.pub >> ~/.ssh/authorized_keys
 
-Ora, puoi impostare un repository vuoto avviando `git init` con l'opzione `--bare`, che inizializza il repository senza la directory di lavoro:
+L'autenticazione tramite chiavi SSH generalmente richiede una restrizione dei diritti di accesso ai file coinvolti. Per prevenire qualsiasi problema è necessario eseguire:
+ 
+ 	$ chmod -R go= ~/.ssh
+ 
+
+ Ora, puoi impostare un repository vuoto avviando `git init` con l'opzione `--bare`, che inizializza il repository senza la directory di lavoro:
 
 	$ cd /opt/git
 	$ mkdir project.git

From d52662e12dd88a1dac772738998311d2182c18ff Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Wed, 11 Jun 2014 11:45:21 +0200
Subject: [PATCH 458/690] Rewording

---
 en/02-git-basics/01-chapter2.markdown | 57 ++-------------------------
 1 file changed, 4 insertions(+), 53 deletions(-)

diff --git a/en/02-git-basics/01-chapter2.markdown b/en/02-git-basics/01-chapter2.markdown
index b8bb571f6..ad75d9c3b 100644
--- a/en/02-git-basics/01-chapter2.markdown
+++ b/en/02-git-basics/01-chapter2.markdown
@@ -665,37 +665,8 @@ To determine which commits in the Git source code repository (git://git.kernel.o
     $ git log --after="2014-04-29 00:00:00" --before="2014-04-29 23:59:59" \
       --pretty=fuller
 
-However this command will not yield identical results when run by collegues, who may be situated in other timezones around the world. Therefore it is recommended to always use an absolute time such as ISO 8601 format (which includes timezone information) as argument to `--after` and `--before`, so that everone running the command will get the same repeatable results. If your timezone is that of France (e.g. you are in Paris) you can change the above example, to use absolute-time arguments. First determine the absolute-times using e.g. the `date` program:
-
-    $ TZ="CET-1CEST,M3.5.0,M10.5.0/3" date --date="2014-04-29 00:00:00" -Is
-    2014-04-29T00:00:00+0200
-    
-    $ TZ="CET-1CEST,M3.5.0,M10.5.0/3" date --date="2014-04-29 23:59:59" -Is
-    2014-04-29T23:59:59+0200
-
-    $ # for TZ values of various countries/cities
-    $ # see http://wiki.openwrt.org/doc/uci/system#time.zones 
-
-    $ # Alternative (simplification) under GNU/Linux -- see /usr/share/zoneinfo/
-    $ TZ="Europe/Paris" date --date="2014-04-29 00:00:00" -Is
-    2014-04-29T00:00:00+0200
-    
-    $ TZ="Europe/Paris" date --date="2014-04-29 23:59:59" -Is
-    2014-04-29T23:59:59+0200
-
-Using the resulting absolute-times, we can now modify the above example and construct a git log command, that gives repeatable ("Paris"-based) results for everyone, irrespective of location:
-
-    $ git log --after="2014-04-29T00:00:00+0200" \
-    --before="2014-04-29T23:59:59+0200" --pretty=fuller
-
-`+0200` means that here Paris is 2 hours ahead of UTC: 
-
-For example: for `2014-04-29T23:59:59+0200` the corresponding 
-
-UTC is `2014-04-29 21:59:59`.
-
-
-To obtain commits made at a specific instant in time (e.g. `2013-04-29T17:07:22+0200`), we can use
+As the output will be different according to the timezone where it will be run, it's recommended to always use an absolute time such as ISO 8601 format (which includes timezone information) as argument to `--after` and `--before`, so that everone running the command will get the same repeatable results. 
+To obtain commits made at a specific instant in time (e.g. 29 April 2013 at 17:07:22 CET), we can use
 
     $ git log  --after="2013-04-29T17:07:22+0200"      \
               --before="2013-04-29T17:07:22+0200" --pretty=fuller
@@ -719,29 +690,9 @@ To obtain commits made at a specific instant in time (e.g. `2013-04-29T17:07:22+
 
 The above times (`AuthorDate`, `CommitDate`) are displayed in default format (`--date=default`), which shows timezone information of respective author and commiter.
 
-We can change the way that these are displayed in the resulting log list. `--date=local` displays times according to your local timezone:
-
-    $ git log  --after="2013-04-29T17:07:22+0200" \
-              --before="2013-04-29T17:07:22+0200" --pretty=fuller --date=local
-
-To show all times according to the timezone of New Zealand, we can prefix an appropriate `TZ=..."` value to the above command (under GNU/Linux simply `TZ="Pacific/Auckland"`):
-
-    $ TZ="NZST-12NZDT,M9.5.0,M4.1.0/3"            \
-      git log  --after="2013-04-29T17:07:22+0200" \
-              --before="2013-04-29T17:07:22+0200" --pretty=fuller --date=local
-
-Other useful formats include `--date=iso` (ISO 8601), `--date=rfc` (RFC 2822), `--date=raw` (seconds since the epoch (1970-01-01 UTC)) as well as `--date=relative` (e.g. "2 hours ago").
-
-When using `git log` without specifying time,
-
-    $ git log --after=2008-06-01 --before=2008-07-01
-
-the time defaults to the time at which the command is run on your computer (keeping the identical offset from UTC). For example when the above command is executed at 09:00 on your computer with your timezone currently 3 hours ahead of UTC, then the result is equivalent to doing:
-
-    $ git log --after="2008-06-01T09:00:00+0300" \
-      --before="2008-07-01T09:00:00+0300"
+Other useful formats include `--date=iso` (ISO 8601), `--date=rfc` (RFC 2822), `--date=raw` (seconds since the epoch (1970-01-01 UTC)) `--date=local` (times according to your local timezone) as well as `--date=relative` (e.g. "2 hours ago").
 
-As a final example:, if you want to see which commits modifying test files in the Git source code history were committed by Junio Hamano with CommitDate being in the month of October 2008 (relative to the timezone of New York) and were not merges, you can run something like this:
+As a final example, if you want to see which commits modifying test files in the Git source code history were committed by Junio Hamano with CommitDate being in the month of October 2008 (relative to the timezone of New York) and were not merges, you can run something like this:
 
         $ git log --pretty="%h - %s" --author=gitster \
            --after="2008-10-01T00:00:00-0400"         \

From 3389a244274cc9584240ba1dae733590714df584 Mon Sep 17 00:00:00 2001
From: hoeggi <hoeggerl.daniel@gmail.com>
Date: Fri, 13 Jun 2014 11:29:37 +0200
Subject: [PATCH 459/690] Update 01-chapter3.markdown

---
 de/03-git-branching/01-chapter3.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/de/03-git-branching/01-chapter3.markdown b/de/03-git-branching/01-chapter3.markdown
index 64f804ed6..e8e0f3145 100644
--- a/de/03-git-branching/01-chapter3.markdown
+++ b/de/03-git-branching/01-chapter3.markdown
@@ -867,7 +867,7 @@ Lass uns annehmen, Du entscheidest Dich Deinen Server-Branch ebenfalls einzupfle
 
 <!--This replays your `server` work on top of your `master` work, as shown in Figure 3-34.-->
 
-Das wiederholt Deine `server`-Arbeit auf der Basis der `server`-Arbeit, wie in Abbildung 3-34 ersichtlich.
+Das wiederholt Deine `server`-Arbeit auf der Basis der `master`-Arbeit, wie in Abbildung 3-34 ersichtlich.
 
 <!--Figure 3-34. Rebasing your server branch on top of your master branch.-->
 

From ef5722785db3451ab43cbf862b8a602fa38715c5 Mon Sep 17 00:00:00 2001
From: lord63 <lord63.j@gmail.com>
Date: Sun, 15 Jun 2014 22:44:47 +0800
Subject: [PATCH 460/690] [zh] Fix typo in 01-chapter1
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Change 丰富的 git 知识 --> 丰富的 Git 知识
In the original en-document, it should be Git rather than git.
What's more, this book often use Git rather than git when refer
to Git, so I think it should be a typo.
---
 zh/01-introduction/01-chapter1.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/zh/01-introduction/01-chapter1.markdown b/zh/01-introduction/01-chapter1.markdown
index 93ceddd73..5af662642 100644
--- a/zh/01-introduction/01-chapter1.markdown
+++ b/zh/01-introduction/01-chapter1.markdown
@@ -252,7 +252,7 @@ Git 可以理解 kdiff3，tkdiff，meld，xxdiff，emerge，vimdiff，gvimdiff
 	$ git help config
 
 我们随时都可以浏览这些帮助信息而无需连网。
-不过，要是你觉得还不够，可以到 Freenode IRC 服务器（irc.freenode.net）上的 `#git` 或 `#github` 频道寻求他人帮助。这两个频道上总有着上百号人，大多都有着丰富的 git 知识，并且乐于助人。
+不过，要是你觉得还不够，可以到 Freenode IRC 服务器（irc.freenode.net）上的 `#git` 或 `#github` 频道寻求他人帮助。这两个频道上总有着上百号人，大多都有着丰富的 Git 知识，并且乐于助人。
 
 ## 小结 ##
 

From 93463d3739819e23aab2b75f9fdce1ef5283e1db Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Sun, 15 Jun 2014 20:56:58 +0200
Subject: [PATCH 461/690] Improving description

Describing what happens when not specifying the time of the day.
---
 en/02-git-basics/01-chapter2.markdown | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/en/02-git-basics/01-chapter2.markdown b/en/02-git-basics/01-chapter2.markdown
index ad75d9c3b..2a5dd41ab 100644
--- a/en/02-git-basics/01-chapter2.markdown
+++ b/en/02-git-basics/01-chapter2.markdown
@@ -666,6 +666,7 @@ To determine which commits in the Git source code repository (git://git.kernel.o
       --pretty=fuller
 
 As the output will be different according to the timezone where it will be run, it's recommended to always use an absolute time such as ISO 8601 format (which includes timezone information) as argument to `--after` and `--before`, so that everone running the command will get the same repeatable results. 
+
 To obtain commits made at a specific instant in time (e.g. 29 April 2013 at 17:07:22 CET), we can use
 
     $ git log  --after="2013-04-29T17:07:22+0200"      \
@@ -692,6 +693,13 @@ The above times (`AuthorDate`, `CommitDate`) are displayed in default format (`-
 
 Other useful formats include `--date=iso` (ISO 8601), `--date=rfc` (RFC 2822), `--date=raw` (seconds since the epoch (1970-01-01 UTC)) `--date=local` (times according to your local timezone) as well as `--date=relative` (e.g. "2 hours ago").
 
+When using `git log` without specifying time, the time defaults to the time at which the command is run on your computer (keeping the identical offset from UTC).
+
+For example, running a `git log` at 09:00 on your computer with your timezone currently 3 hours ahead of UTC, makes the following two commands equivalent:
+    $ git log --after=2008-06-01 --before=2008-07-01
+    $ git log --after="2008-06-01T09:00:00+0300" \
+        --before="2008-07-01T09:00:00+0300"
+
 As a final example, if you want to see which commits modifying test files in the Git source code history were committed by Junio Hamano with CommitDate being in the month of October 2008 (relative to the timezone of New York) and were not merges, you can run something like this:
 
         $ git log --pretty="%h - %s" --author=gitster \

From 0a9790cf27874895f1cfe3b31d6f3fe96cb19427 Mon Sep 17 00:00:00 2001
From: Aaron Schumacher <ajschumacher@gmail.com>
Date: Sun, 15 Jun 2014 21:06:23 -0400
Subject: [PATCH 462/690] typo: "User who are" to "Users who are"

---
 en/04-git-server/01-chapter4.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/en/04-git-server/01-chapter4.markdown b/en/04-git-server/01-chapter4.markdown
index 9d3496693..a52ba5361 100644
--- a/en/04-git-server/01-chapter4.markdown
+++ b/en/04-git-server/01-chapter4.markdown
@@ -622,7 +622,7 @@ In addition to restricting what branches a user can push changes to, you can als
 
         -   VREF/NAME/Makefile  =   @junior_devs
 
-User who are migrating from the older Gitolite should note that there is a significant change in behaviour with regard to this feature; please see the migration guide for details.
+Users who are migrating from the older Gitolite should note that there is a significant change in behaviour with regard to this feature; please see the migration guide for details.
 
 ### Personal Branches ###
 

From 3d0f81fbc60f453d6eaa6177de7c4df7dacceb7f Mon Sep 17 00:00:00 2001
From: Aaron Schumacher <ajschumacher@gmail.com>
Date: Sun, 15 Jun 2014 21:48:11 -0400
Subject: [PATCH 463/690] typo: "works as follow:" to "works as follows:"

---
 en/05-distributed-git/01-chapter5.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/en/05-distributed-git/01-chapter5.markdown b/en/05-distributed-git/01-chapter5.markdown
index a4d821de9..bb6a633e4 100644
--- a/en/05-distributed-git/01-chapter5.markdown
+++ b/en/05-distributed-git/01-chapter5.markdown
@@ -22,7 +22,7 @@ This workflow is attractive to a lot of people because it’s a paradigm that ma
 
 ### Integration-Manager Workflow ###
 
-Because Git allows you to have multiple remote repositories, it’s possible to have a workflow where each developer has write access to their own public repository and read access to everyone else’s. This scenario often includes a canonical repository that represents the "official" project. To contribute to that project, you create your own public clone of the project and push your changes to it. Then, you can send a request to the maintainer of the main project to pull in your changes. They can add your repository as a remote, test your changes locally, merge them into their branch, and push back to their repository. The process works as follow (see Figure 5-2):
+Because Git allows you to have multiple remote repositories, it’s possible to have a workflow where each developer has write access to their own public repository and read access to everyone else’s. This scenario often includes a canonical repository that represents the "official" project. To contribute to that project, you create your own public clone of the project and push your changes to it. Then, you can send a request to the maintainer of the main project to pull in your changes. They can add your repository as a remote, test your changes locally, merge them into their branch, and push back to their repository. The process works as follows (see Figure 5-2):
 
 1. The project maintainer pushes to their public repository.
 2. A contributor clones that repository and makes changes.

From e19f55231f7c393857c507788d6c4b1e7480a996 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Wed, 11 Jun 2014 09:37:15 +0200
Subject: [PATCH 464/690] Introducing PR#750

---
 it/02-git-basics/01-chapter2.markdown | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/it/02-git-basics/01-chapter2.markdown b/it/02-git-basics/01-chapter2.markdown
index ef9a148e5..fe8ff7d70 100644
--- a/it/02-git-basics/01-chapter2.markdown
+++ b/it/02-git-basics/01-chapter2.markdown
@@ -652,8 +652,8 @@ The lines must be formatted as follows
 
 	Opzioni	Descrizione
 	-(n)	Vedi solo le ultime n commit
-	--since, --after	Mostra solo le commit fatte dopo la data specificata.
-	--until, --before	Mostra solo le commit fatte prima della data specificata.
+	--since, --after	Mostra solo le commit fatte dalla data specificata.
+	--until, --before	Mostra solo le commit fatte entro la data specificata.
 	--author	Mostra solo le commit dell'autore specificato.
 	--committer	Mostra solo le commit del committer specificato.
 

From 80c1acec7828c8b859782c85e861fa984af45675 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Wed, 11 Jun 2014 11:50:32 +0200
Subject: [PATCH 465/690] Translating Limiting Log Output according to
 Date/Time

---
 it/02-git-basics/01-chapter2.markdown | 51 +++++++++++++++++++++++++--
 1 file changed, 48 insertions(+), 3 deletions(-)

diff --git a/it/02-git-basics/01-chapter2.markdown b/it/02-git-basics/01-chapter2.markdown
index fe8ff7d70..d817acee6 100644
--- a/it/02-git-basics/01-chapter2.markdown
+++ b/it/02-git-basics/01-chapter2.markdown
@@ -657,10 +657,55 @@ The lines must be formatted as follows
 	--author	Mostra solo le commit dell'autore specificato.
 	--committer	Mostra solo le commit del committer specificato.
 
-Se vuoi, per esempio, vedere quale commit della cronologia di Git modificano i test e che siano state eseguite da Junio Hamano a ottobre 2008, ma che non siano ancora stati uniti, puoi eseguire questo comando:
 
-	$ git log --pretty="%h - %s" --author=gitster --since="2008-10-01" \
-	   --before="2008-11-01" --no-merges -- t/
+### Filtrare i risultati in base a data e ora ###
+ 
+ Per sapere cosa è stato committato nel repository di Git (git://git.kernel.org/pub/scm/git/git.git) il 29/04/2014 (usando come riferimento il fuso orario impostato sul tuo computer)
+ 
+    $ git log --after="2014-04-29 00:00:00" --before="2014-04-29 23:59:59" \
+         --pretty=fuller
+ 
+ Il risultato che si ottiene eseguendo questo comando cambia in base al fuso orario dove viene eseguito. È quindi consigliato usare un orario assoluto quando si usano le opzioni `--after` e `--before`, come per esempio l'ISO 8601 (che include anche informazioni sul furo orario), così da ottenere gli stessi risultati indipendentemente dal fuso orario. 
+
+Per ottenere le commit eseguite in un determinato istante (per esempio il 29 Aprile 2013 alle 17:07:22 CET), possiamo eseguire:
+
+    $ git log  --after="2013-04-29T17:07:22+0200"      \
+              --before="2013-04-29T17:07:22+0200" --pretty=fuller
+    
+    commit de7c201a10857e5d424dbd8db880a6f24ba250f9
+    Author:     Ramkumar Ramachandra <artagnon@gmail.com>
+    AuthorDate: Mon Apr 29 18:19:37 2013 +0530
+    Commit:     Junio C Hamano <gitster@pobox.com>
+    CommitDate: Mon Apr 29 08:07:22 2013 -0700
+    
+        git-completion.bash: lexical sorting for diff.statGraphWidth
+        
+        df44483a (diff --stat: add config option to limit graph width,
+        2012-03-01) added the option diff.startGraphWidth to the list of
+        configuration variables in git-completion.bash, but failed to notice
+        that the list is sorted alphabetically.  Move it to its rightful place
+        in the list.
+        
+        Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
+        Signed-off-by: Junio C Hamano <gitster@pobox.com>
+
+Data e ora di `AuthorDate` e `CommitDate` hanno un formato standard (`--date=default`) che mostra le informazioni sul fuso orario, rispettivamente, dell'autore e di chi ha eseguito la commit.
+
+Altri formati utili sono `--date=iso` (ISO 8601), `--date=rfc` (RFC 2822), `--date=raw` (i secondi passati dall'1/1/1970 UTC) `--date=local` (l'orario del tuo attuale fuso) e `--date=relative` (per esempio: "2 ore fa").
+
+Usando `git log` senza specificare un orario equivale a specificare l'orario attuale del tuo computer (mantenendo la differenza con l'UTC).
+
+Per esempio, eseguendo `git log` alle 09:00 su un computer che sia 3 ore avanti rispetto all'UTC, rende equivalenti questi comandi:
+
+    $ git log --after=2008-06-01 --before=2008-07-01
+    $ git log --after="2008-06-01T09:00:00+0300" \
+        --before="2008-07-01T09:00:00+0300"
+
+Per fare un ultimo esempio, se vuoi vedere quale commit di Junio Hamano dell'ottobre del 2008 (relative al fuso di New York) che modificano i file di test nella cronologia dei sorgenti di Git che non sono ancora state unite con merge, puoi eseguire questo:
+ 
+    $ git log --pretty="%h - %s" --author=gitster \
+        --after="2008-10-01T00:00:00-0400"         \
+        --before="2008-10-31T23:59:59-0400" --no-merges -- t/
 	5610e3b - Fix testcase failure when extended attribute
 	acd3b9e - Enhance hold_lock_file_for_{update,append}()
 	f563754 - demonstrate breakage of detached checkout wi

From 038f1f006eacc5098c03e3edbd16dc328706a233 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Mon, 16 Jun 2014 18:48:09 +0200
Subject: [PATCH 466/690] Adding empty row

To stay consistent
---
 en/02-git-basics/01-chapter2.markdown | 1 +
 1 file changed, 1 insertion(+)

diff --git a/en/02-git-basics/01-chapter2.markdown b/en/02-git-basics/01-chapter2.markdown
index 2a5dd41ab..452f350a2 100644
--- a/en/02-git-basics/01-chapter2.markdown
+++ b/en/02-git-basics/01-chapter2.markdown
@@ -696,6 +696,7 @@ Other useful formats include `--date=iso` (ISO 8601), `--date=rfc` (RFC 2822), `
 When using `git log` without specifying time, the time defaults to the time at which the command is run on your computer (keeping the identical offset from UTC).
 
 For example, running a `git log` at 09:00 on your computer with your timezone currently 3 hours ahead of UTC, makes the following two commands equivalent:
+
     $ git log --after=2008-06-01 --before=2008-07-01
     $ git log --after="2008-06-01T09:00:00+0300" \
         --before="2008-07-01T09:00:00+0300"

From 7e9ef78b7395f61ad2277925091b7b831b28e30b Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Mon, 16 Jun 2014 19:00:37 +0200
Subject: [PATCH 467/690] [it] Updating chapter 6

---
 it/06-git-tools/01-chapter6.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/it/06-git-tools/01-chapter6.markdown b/it/06-git-tools/01-chapter6.markdown
index 9c3dc0c59..7d684617d 100644
--- a/it/06-git-tools/01-chapter6.markdown
+++ b/it/06-git-tools/01-chapter6.markdown
@@ -248,7 +248,7 @@ Un'opzione comunemente usata in questi casi con il comando `log` è il parametro
 	> D
 	> C
 
-Con questi strumenti puoi dire facilmente a Git quali commit vuoi ispezionare.
+Con questi strumenti puoi dire facilmente a Git quale o quali commit vuoi ispezionare.
 
 ## Assemblaggio interattivo ##
 

From 010759cf9136844db39461f4ec314d68beefe316 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Mon, 16 Jun 2014 19:09:10 +0200
Subject: [PATCH 468/690] [it] Updating chapter 1

---
 it/01-introduction/01-chapter1.markdown | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/it/01-introduction/01-chapter1.markdown b/it/01-introduction/01-chapter1.markdown
index 4b5701a8a..09f2af980 100644
--- a/it/01-introduction/01-chapter1.markdown
+++ b/it/01-introduction/01-chapter1.markdown
@@ -75,25 +75,25 @@ Questa è una distinzione importante tra Git e pressocché tutti gli altri VCS.
 
 La maggior parte delle operazioni in Git, necessitano solo di file e risorse locali per operare — generalmente non occorrono informazioni da altri computer della rete. Se sei abituato ad un CVCS in cui la maggior parte delle operazioni sono soggette alle latenze di rete, questo aspetto di Git ti farà pensare che gli Dei della velocità abbiano benedetto Git con poteri soprannaturali. Poiché hai l'intera storia del progetto sul tuo disco locale, molte operazioni sembrano quasi istantanee.
 
-Per esempio, per scorrere la storia di un progetto, Git non ha bisogno di connettersi al server per scaricarla e per poi visualizzarla — la legge direttamente dal database locale. Questo significa che puoi vedere la storia del progetto quasi istantaneamente. Se vuoi vedere i cambiamenti introdotti tra la versione corrente di un file e la versione di un mese fa, Git può consultare il file di un mese fa e calcolare localmente le differenze, invece di richiedere di farlo ad un server remoto o di estrarre una precedente versione del file dal server remoto, per poi farlo in locale.
+Per esempio, per navigare la storia di un progetto, Git non ha bisogno di connettersi al server per scaricarla e per poi mostrarla: la legge direttamente dal tuo database locale. Questo significa che puoi vedere la storia del progetto quasi istantaneamente. Se vuoi vedere le modifiche introdotte tra la versione corrente e la versione di un mese fa di un file, Git può accedere al file com'era un mese fa e calcolare le differenze localmente, invece di dover chiedere a un server remoto di farlo o di scaricare dal server remoto una versione precedente del file, per poi farlo in locale.
 
-Questo significa anche che sono minime le cose che non si possono fare se si è offline o non connesso alla VPN. Se sei in aereo o sul treno e vuoi fare un po' di lavoro, puoi eseguire tranquillamente il commit, anche se non sei connesso alla rete per fare l'upload. Se tornando a casa, trovi che il tuo client VPN non funziona correttamente, puoi comunque lavorare. In molti altri sistemi, fare questo è quasi impossibile o penoso. Con Perforce, per esempio, puoi fare ben poco se non sei connesso al server; e con Subversion e CVS, puoi modificare i file, ma non puoi inviare i cambiamenti al tuo database (perché il database è offline). Tutto ciò non ti può sembrare una gran cosa, tuttavia potresti rimanere di stucco dalla differenza che Git può fare.
+Questo significa anche che sono pochissime le cose che non puoi fare se sei offline o non sei connesso alla VPN. Se sei in aereo o sul treno e vuoi fare un po' di lavoro, puoi committare tranquillamente in attesa di essere di nuovo connesso per fare l'upload. Se vai a casa e il tuo client VPN non funziona correttamente, puoi lavorare ugualmente. In molti altri sistemi questo è impossibile o molto penoso. Con Perforce, per esempio, puoi fare ben poco se non sei connesso al server; e con Subversion e CVS, puoi modificare i file, ma non puoi inviare le modifiche al tuo database (perché il database è offline). Tutto ciò potrebbe non sembrarti una gran cosa, ma potrebbe sorprenderti quanta differenza possa fare.
 
 ### Git Ha Integrità ###
 
-Qualsiasi cosa in Git è controllata, tramite checksum, prima di essere salvata ed è referenziata da un checksum. Questo significa che è impossibile cambiare il contenuto di qualsiasi file o directory senza che Git lo sappia. Questa è una funzionalità interna di Git al più basso livello ed è intrinseco nella sua filosofia. Non puoi perdere informazioni nel transito o avere corruzioni di file senza che Git non sia in grado di accorgersene.
+Qualsiasi cosa in Git è controllata, tramite checksum, prima di essere salvata ed è referenziata da un checksum. Questo significa che è impossibile cambiare il contenuto di qualsiasi file o directory senza che Git lo sappia. Questa è una funzionalità interna di basso livello di Git ed è intrinseco della sua filosofia. Non può capira che delle informazioni in transito si perdano o che un file si corrompa senza che Git non sia in grado di accorgersene.
 
-Il meccanismo che Git usa per fare questo checksum, è un hash, denominato SHA-1. Si tratta di una stringa di 40-caratteri, composta da caratteri esadecimali (0–9 ed a–f) e calcolata in base al contenuto di file o della struttura della directory in Git. Un hash SHA-1 assomiglia a qualcosa come:
+Il meccanismo che Git usa per fare questo checksum è un hash chiamato SHA-1. Si tratta di una stringa di 40-caratteri, composta da caratteri esadecimali (0–9 ed a–f) e calcolata in base al contenuto di file o della struttura della directory in Git. Un hash SHA-1 assomiglia a qualcosa come:
 
 	24b9da6552252987aa493b52f8696cd6d3b00373
 
-in Git, questi valori di hash si vedono dappertutto, perché Git li usa tantissimo. Infatti, Git immagazzina ogni cosa, nel proprio database indirizzabile, non per nome di file, ma per il valore di hash del suo contenuto.
+Vedrai questi hash dappertutto in Git perché li usa tantissimo. Infatti Git salva qualsiasi cosa non in base al nome del file, ma nel suo database indirizzabile per l'hash del suo contenuto.
 
 ### Git Generalmente Aggiunge Solo Dati ###
 
-Quando si fanno delle azioni in Git, quasi tutte aggiungono solo dati al database di Git. E' piuttosto difficile che si porti il sistema a fare qualcosa che non sia annullabile o a cancellare i dati in una qualche maniera. Come in altri VCS, si possono perdere o confondere le modifiche, di cui non si è ancora fatto il commit; ma dopo aver fatto il commit di uno snapshot in Git, è veramente difficile perderle, specialmente se si esegue regolarmente, il push del proprio database su di un altro repository.
+Quasi tutte le azioni in Git aggiungono dati al database di Git. È piuttosto difficile fare qualcosa che non sia annullabile o che cancelli i dati in una qualche maniera. Come negli altri VCS, puoi perdere o fare confusione con le modifiche che non hai ancora committato, ma dopo aver committato uno snapshot in Git, è veramente difficile perderle, specialmente se regolarmente fai il push del tuo database su un altro repository.
 
-Questo rende l'uso di Git un piacere perché sappiamo che possiamo sperimentare senza il pericolo di perdere seriamente le cose. Per un maggior approfondimento su come Git salva i dati e come puoi recuperare i dati che sembrano persi, vedi "Sotto il Cofano" nel Capitolo 9.
+Questo rende piaceole l'uso di Git perché sappiamo che possiamo sperimentare senza il pericolo di causare danni pesanti. Per un maggior approfondimento su come Git salvi i dati e come tu possa recuperare quelli che sembrino persi, consulta il Capitolo 9.
 
 ### I Tre Stati ###
 

From f43fe652072573f024137c7943fdb979d63d729f Mon Sep 17 00:00:00 2001
From: Jean-Noel Avila <jn.avila@free.fr>
Date: Tue, 27 May 2014 22:59:01 +0200
Subject: [PATCH 469/690] Add a chmod on the ~/.ssh on server

As remarked in #709, setting up a key-based server may need to set up
restricted rights.
---
 en/04-git-server/01-chapter4.markdown | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/en/04-git-server/01-chapter4.markdown b/en/04-git-server/01-chapter4.markdown
index 622648798..78b6c9d84 100644
--- a/en/04-git-server/01-chapter4.markdown
+++ b/en/04-git-server/01-chapter4.markdown
@@ -232,7 +232,11 @@ You just append them to your `authorized_keys` file:
 	$ cat /tmp/id_rsa.josie.pub >> ~/.ssh/authorized_keys
 	$ cat /tmp/id_rsa.jessica.pub >> ~/.ssh/authorized_keys
 
-Now, you can set up an empty repository for them by running `git init` with the `--bare` option, which initializes the repository without a working directory:
+Key-based SSH authentication usually enforces security by requiring restricted rights on the involved files. To prevent SSH from refusing to work, type this:
+
+	$ chmod -R go= ~/.ssh
+
+Now, you can set up an empty repository for your users by running `git init` with the `--bare` option, which initializes the repository without a working directory:
 
 	$ cd /opt/git
 	$ mkdir project.git

From 8086a29391fd3e20daaea242e2e399d1bf5f5a2d Mon Sep 17 00:00:00 2001
From: Alex Schroeder <alex@gnu.org>
Date: Sat, 21 Jun 2014 21:48:07 +0200
Subject: [PATCH 470/690] [de] Add missing word and comma

---
 de/03-git-branching/01-chapter3.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/de/03-git-branching/01-chapter3.markdown b/de/03-git-branching/01-chapter3.markdown
index e8e0f3145..fd2081a01 100644
--- a/de/03-git-branching/01-chapter3.markdown
+++ b/de/03-git-branching/01-chapter3.markdown
@@ -739,7 +739,7 @@ Nun wird Dein lokaler Branch `sf` automatisch push und pull auf `origin/serverfi
 
 <!--Suppose you’re done with a remote branch — say, you and your collaborators are finished with a feature and have merged it into your remote’s `master` branch (or whatever branch your stable codeline is in). You can delete a remote branch using the rather obtuse syntax `git push [remotename] :[branch]`. If you want to delete your `serverfix` branch from the server, you run the following:-->
 
-Stellen wir uns Du bist fertig mit Deinem Remote-Branch – sagen wir Deine Mitarbeiter und Du, Ihr seid fertig mit einer neuen Funktion und habt sie in den entfernten `master`-Branch (oder in welchem Zweig Ihr sonst den stabilen Code ablegt) gemerged. Du kannst einen Remote-Branch mit der unlogischen Syntax `git push [remotename] :[branch]` löschen. Wenn Du Deinen `serverfix`-Branch vom Server löschen möchtest, führe folgendes aus:
+Stellen wir uns vor, Du bist fertig mit Deinem Remote-Branch – sagen wir Deine Mitarbeiter und Du, Ihr seid fertig mit einer neuen Funktion und habt sie in den entfernten `master`-Branch (oder in welchem Zweig Ihr sonst den stabilen Code ablegt) gemerged. Du kannst einen Remote-Branch mit der unlogischen Syntax `git push [remotename] :[branch]` löschen. Wenn Du Deinen `serverfix`-Branch vom Server löschen möchtest, führe folgendes aus:
 
 	$ git push origin :serverfix
 	To git@github.com:schacon/simplegit.git

From 30568d68d9f2491f24ecef48fbecba0040e9b0de Mon Sep 17 00:00:00 2001
From: Soon Van <cog@randomecho.com>
Date: Mon, 23 Jun 2014 23:29:31 -0400
Subject: [PATCH 471/690] Clarify usage of single quotes, not simple

' is more commonly known as a single quote.

Was pointed out in #792 by @harupong
---
 en/01-introduction/01-chapter1.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/en/01-introduction/01-chapter1.markdown b/en/01-introduction/01-chapter1.markdown
index b82705a07..fc6d9bdd5 100644
--- a/en/01-introduction/01-chapter1.markdown
+++ b/en/01-introduction/01-chapter1.markdown
@@ -182,7 +182,7 @@ Installing Git on Windows is very easy. The msysGit project has one of the easie
 
 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.
 
-Note on Windows usage: you should use Git with the provided msysGit shell (Unix style), it allows to use the complex lines of command given in this book. If you need, for some reason, to use the native Windows shell / command line console, you have to use double quotes instead of simple quotes (for parameters with spaces in them) and you must quote the parameters ending with the circumflex accent (^) if they are last on the line, as it is a continuation symbol in Windows.
+Note on Windows usage: you should use Git with the provided msysGit shell (Unix style), it allows to use the complex lines of command given in this book. If you need, for some reason, to use the native Windows shell / command line console, you have to use double quotes instead of single quotes (for parameters with spaces in them) and you must quote the parameters ending with the circumflex accent (^) if they are last on the line, as it is a continuation symbol in Windows.
 
 ## First-Time Git Setup ##
 

From 27641e62039ab3ec98785dd48bdf425b08e4e75e Mon Sep 17 00:00:00 2001
From: Olivier Trichet <nive@nivalis.org>
Date: Wed, 25 Jun 2014 14:42:19 +0200
Subject: [PATCH 472/690] Synchronize command example with previous one

The file "README" is created/added by previous examples of the chapter.
Therefore, it's best for reader to use it as source for "git mv"
---
 en/02-git-basics/01-chapter2.markdown | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/en/02-git-basics/01-chapter2.markdown b/en/02-git-basics/01-chapter2.markdown
index 452f350a2..9aa20341f 100644
--- a/en/02-git-basics/01-chapter2.markdown
+++ b/en/02-git-basics/01-chapter2.markdown
@@ -406,20 +406,20 @@ Thus it’s a bit confusing that Git has a `mv` command. If you want to rename a
 
 and it works fine. In fact, if you run something like this and look at the status, you’ll see that Git considers it a renamed file:
 
-	$ git mv README.txt README
+	$ git mv README README.txt
 	$ git status
 	On branch master
 	Changes to be committed:
 	  (use "git reset HEAD <file>..." to unstage)
 	
-	        renamed:    README.txt -> README
+	        renamed:    README -> README.txt
 	
 
 However, this is equivalent to running something like this:
 
-	$ mv README.txt README
-	$ git rm README.txt
-	$ git add README
+	$ mv README README.txt
+	$ git rm README
+	$ git add README.txt
 
 Git figures out that it’s a rename implicitly, so it doesn’t matter if you rename a file that way or with the `mv` command. The only real difference is that `mv` is one command instead of three — it’s a convenience function. More important, you can use any tool you like to rename a file, and address the add/rm later, before you commit.
 

From 833a634d818bce260020928f6d56c0550de14ddf Mon Sep 17 00:00:00 2001
From: JordiPujol <equidiscentes@gmail.com>
Date: Wed, 25 Jun 2014 11:59:31 -0500
Subject: [PATCH 473/690] Update 01-chapter1.markdown
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

he traduit un parell de paragrafs.
dema més
---
 ca/01-introduction/01-chapter1.markdown | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/ca/01-introduction/01-chapter1.markdown b/ca/01-introduction/01-chapter1.markdown
index e245b9236..1944283d7 100644
--- a/ca/01-introduction/01-chapter1.markdown
+++ b/ca/01-introduction/01-chapter1.markdown
@@ -4,11 +4,11 @@ Aquest capítol tracta com iniciar-se amb Git. Començarem explicant alguns conc
 
 ## Control de Versions ##
 
-What is version control, and why should you care? Version control is a system that records changes to a file or set of files over time so that you can recall specific versions later. For the examples in this book you will use software source code as the files being version controlled, though in reality you can do this with nearly any type of file on a computer.
+Que es el control de version i per què t'hauria d'importar? El control de versions es un sitema que registra els canvis a un arxiu o conjunt d'arxius de manera que despres pot recuperar cualsevol de les versions. Tot i que els exemples de control de versions del llibre son codi font, potfer servir gairebe quansevol mena de arxiu per del teu ordinador.
 
-If you are a graphic or web designer and want to keep every version of an image or layout (which you would most certainly want to), a Version Control System (VCS) is a very wise thing to use. It allows you to revert files back to a previous state, revert the entire project back to a previous state, compare changes over time, see who last modified something that might be causing a problem, who introduced an issue and when, and more. Using a VCS also generally means that if you screw things up or lose files, you can easily recover. In addition, you get all this for very little overhead.
+Si ets un disenyador gràfic o de pagines web i vols guardar cada escuna de les versions d'una imatge o disenys (que segur que vols) un sitema de control de versions (Version Control System -VCS-) sera una eina acurada. Et permetrà torna al estat anterior dels fitxers, tornar a un punt anterior de tot el projecte, comparà canvis en el proces, saber qui es el darrer a modificat coses que potser estant donant problemes, qui a introduit un tema i quant, i encara més coses. Fer servir VCS vol dir que si la pífias o pot arreglar, generalment. i tot aixo amb pocs costos.
 
-### Local Version Control Systems ###
+### Sitemas de control de versions locals ###
 
 Many people’s version-control method of choice is to copy files into another directory (perhaps a time-stamped directory, if they’re clever). This approach is very common because it is so simple, but it is also incredibly error prone. It is easy to forget which directory you’re in and accidentally write to the wrong file or copy over files you don’t mean to.
 

From cbcaef87564369049c33e5180963383182df7308 Mon Sep 17 00:00:00 2001
From: Severyn Kozak <severyn.kozak@gmail.com>
Date: Wed, 25 Jun 2014 22:50:43 -0400
Subject: [PATCH 474/690] Add numeric color values to 07-customizing-git.

en/07-customizing-git/01-chapter7.markdown
	-Explain that, when colorizing `git` output, users can specify arbitrary
	numeric color values instead of color names.
---
 en/07-customizing-git/01-chapter7.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/en/07-customizing-git/01-chapter7.markdown b/en/07-customizing-git/01-chapter7.markdown
index e77128dd8..1a1b7f729 100644
--- a/en/07-customizing-git/01-chapter7.markdown
+++ b/en/07-customizing-git/01-chapter7.markdown
@@ -130,7 +130,7 @@ In addition, each of these has subsettings you can use to set specific colors fo
 
 	$ git config --global color.diff.meta "blue black bold"
 
-You can set the color to any of the following values: normal, black, red, green, yellow, blue, magenta, cyan, or white. If you want an attribute like bold in the previous example, you can choose from bold, dim, ul, blink, and reverse.
+You can set the color to any of the following values: `normal`, `black`, `red`, `green`, `yellow`, `blue`, `magenta`, `cyan`, or `white`, or, if your terminal supports more than 16 colors, an arbitrary numeric color value (between 0 and 255 on a 256-color terminal). If you want an attribute like bold in the previous example, you can choose from `bold`, `dim`, `ul`, `blink`, and `reverse`.
 
 See the `git config` manpage for all the subsettings you can configure, if you want to do that.
 

From dbecbe304cc01511f9e5bc7ec49d48e25f573df9 Mon Sep 17 00:00:00 2001
From: Soon Van <cog@randomecho.com>
Date: Thu, 26 Jun 2014 08:47:28 -0400
Subject: [PATCH 475/690] Smooth out intro from using too many begins

---
 en/01-introduction/01-chapter1.markdown | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/en/01-introduction/01-chapter1.markdown b/en/01-introduction/01-chapter1.markdown
index fc6d9bdd5..d1248fee1 100644
--- a/en/01-introduction/01-chapter1.markdown
+++ b/en/01-introduction/01-chapter1.markdown
@@ -1,6 +1,6 @@
 # Getting Started #
 
-This chapter will be about getting started with Git.  We will begin at the beginning by explaining some background on version control tools, then move on to how to get Git running on your system and finally how to get it setup to start working with.  At the end of this chapter you should understand why Git is around, why you should use it and you should be all setup to do so.
+This chapter will be about getting started with Git.  We will begin by explaining some background on version control tools, then move on to how to get Git running on your system and finally how to get it set up to start working with.  At the end of this chapter you should understand why Git is around, why you should use it and you should be all set up to do so.
 
 ## About Version Control ##
 
@@ -178,7 +178,7 @@ You don’t have to add all the extras, but you’ll probably want to include +s
 
 Installing Git on Windows is very easy. The msysGit project has one of the easier installation procedures. Simply download the installer exe file from the GitHub page, and run it:
 
-	http://msysgit.github.com/
+	http://msysgit.github.io
 
 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.
 

From e77e54e0243b0f8c5faac676a5aa028d8111970e Mon Sep 17 00:00:00 2001
From: Alec Clews <alecclews@gmail.com>
Date: Thu, 16 Jan 2014 19:05:07 +1100
Subject: [PATCH 476/690] Added some brief details on BFG
 http://rtyley.github.io/bfg-repo-cleaner/

---
 en/06-git-tools/01-chapter6.markdown | 21 +++++++++++++++++++--
 1 file changed, 19 insertions(+), 2 deletions(-)

diff --git a/en/06-git-tools/01-chapter6.markdown b/en/06-git-tools/01-chapter6.markdown
index 3eef10757..099b47ea4 100644
--- a/en/06-git-tools/01-chapter6.markdown
+++ b/en/06-git-tools/01-chapter6.markdown
@@ -1,4 +1,4 @@
-# Git Tools #
+ Git Tools #
 
 By now, you’ve learned most of the day-to-day commands and workflows that you need to manage or maintain a Git repository for your source code control. You’ve accomplished the basic tasks of tracking and committing files, and you’ve harnessed the power of the staging area and lightweight topic branching and merging.
 
@@ -690,7 +690,9 @@ Once again, this changes the SHAs of all the commits in your list, so make sure
 
 ### The Nuclear Option: filter-branch ###
 
-There is another history-rewriting option that you can use if you need to rewrite a larger number of commits in some scriptable way — for instance, changing your e-mail address globally or removing a file from every commit. The command is `filter-branch`, and it can rewrite huge swaths of your history, so you probably shouldn’t use it unless your project isn’t yet public and other people haven’t based work off the commits you’re about to rewrite. However, it can be very useful. You’ll learn a few of the common uses so you can get an idea of some of the things it’s capable of.
+There is another history-rewriting option that you can use if you need to rewrite a larger number of commits in some scriptable way — for instance, changing your e-mail address globally or removing a file from every commit.
+The command is `filter-branch`, and it can rewrite huge swaths of your history, so you probably shouldn’t use it unless your project isn’t yet public and other people haven’t based work off the commits you’re about to rewrite.
+However, it can be very useful. You’ll learn a few of the common uses so you can get an idea of some of the things it’s capable of.
 
 #### Removing a File from Every Commit ####
 
@@ -730,6 +732,21 @@ Another common case is that you forgot to run `git config` to set your name and
 
 This goes through and rewrites every commit to have your new address. Because commits contain the SHA-1 values of their parents, this command changes every commit SHA in your history, not just those that have the matching e-mail address.
 
+### The Very Fast Nuclear Option: Big Friendly Giant Repo Cleaner###
+
+[Roberto Tyley](https://github.com/rtyley) has written a similar
+tool to filter-branch call the BFG. It is more limited in what is can do,
+but it does it _very_ fast.
+On a large repository this can make a big difference.
+
+See the [BFG](http://rtyley.github.io/bfg-repo-cleaner/) website for details.
+
+Tip: BFG is a standalone Java program. However if you create the following alias in your `~/.gitconfig` file you can use `git bfg ...`
+
+        bfg = !java -jar ~/bin/bfg.jar
+
+(Assuming that you have copied the bfg-x.x.x.jar file to ~/bin/bfg.jar)
+
 ## Debugging with Git ##
 
 Git also provides a couple of tools to help you debug issues in your projects. Because Git is designed to work with nearly any type of project, these tools are pretty generic, but they can often help you hunt for a bug or culprit when things go wrong.

From 45f9e9860dd0ea7b7d79c73c7ab081264a485155 Mon Sep 17 00:00:00 2001
From: Alec Clews <alecclews@gmail.com>
Date: Thu, 16 Jan 2014 19:25:03 +1100
Subject: [PATCH 477/690] A note about using 'git svn info' in build scripts

Also fixed a small typo
---
 en/06-git-tools/01-chapter6.markdown          |  2 +-
 en/08-git-and-other-scms/01-chapter8.markdown | 11 +++++++++++
 2 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/en/06-git-tools/01-chapter6.markdown b/en/06-git-tools/01-chapter6.markdown
index 099b47ea4..9e1d85e54 100644
--- a/en/06-git-tools/01-chapter6.markdown
+++ b/en/06-git-tools/01-chapter6.markdown
@@ -1,4 +1,4 @@
- Git Tools #
+# Git Tools #
 
 By now, you’ve learned most of the day-to-day commands and workflows that you need to manage or maintain a Git repository for your source code control. You’ve accomplished the basic tasks of tracking and committing files, and you’ve harnessed the power of the staging area and lightweight topic branching and merging.
 
diff --git a/en/08-git-and-other-scms/01-chapter8.markdown b/en/08-git-and-other-scms/01-chapter8.markdown
index 4e6671c27..49792b126 100644
--- a/en/08-git-and-other-scms/01-chapter8.markdown
+++ b/en/08-git-and-other-scms/01-chapter8.markdown
@@ -324,6 +324,17 @@ You can also get the same sort of information that `svn info` gives you by runni
 
 This is like `blame` and `log` in that it runs offline and is up to date only as of the last time you communicated with the Subversion server.
 
+Tip: If your build scripts expect to be able to run `svn info` then providing a wrapper around git will often work.
+Here is example to experiment with
+
+    #!/usr/bin/env bash
+
+    if git rev-parse --git-dir > /dev/null 2>&1 && [[ $1 == "info" ]] ; then
+      git svn info
+    else 
+      /usr/local/bin/svn "$@"
+    fi
+
 #### Ignoring What Subversion Ignores ####
 
 If you clone a Subversion repository that has `svn:ignore` properties set anywhere, you’ll likely want to set corresponding `.gitignore` files so you don’t accidentally commit files that you shouldn’t. `git svn` has two commands to help with this issue. The first is `git svn create-ignore`, which automatically creates corresponding `.gitignore` files for you so your next commit can include them.

From b36c68c02674d5a24ac7560ff64e33ed4197e4f3 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Sat, 28 Jun 2014 09:40:17 +0200
Subject: [PATCH 478/690] [it] Fixing as per PR#799

---
 it/01-introduction/01-chapter1.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/it/01-introduction/01-chapter1.markdown b/it/01-introduction/01-chapter1.markdown
index 09f2af980..868a83984 100644
--- a/it/01-introduction/01-chapter1.markdown
+++ b/it/01-introduction/01-chapter1.markdown
@@ -182,7 +182,7 @@ Installare Git su Windows è davvero facile. Il progetto msysGit ha una delle pr
 
 Una volta installato avrai a disposizione sia la versione da riga di comando (incluso un client SSH ti servirà in seguito) sia l'interfaccia grafica (_GUI_) standard.
 
-Nota sull'uso su Windows: dovresti usare Git con la shell msysGit fornita (stile Unix) perché permette di usare le complesse linee di comando di questo libro. Se hai bisogno, per qualche ragione, di usare la shell nativa di Windows / la console a linea di comando, devi usare le doppie virgolette invece delle virgolette semplici (per i parametri con che contengono spazi) e devi virgolettare i parametri che terminano con l'accento circonflesso (^) se questi sono al termine della linea, poiché in Windows è uno dei simboli di proseguimento.
+Nota sull'uso su Windows: dovresti usare Git con la shell msysGit fornita (stile Unix) perché permette di usare le complesse linee di comando di questo libro. Se hai bisogno, per qualche ragione, di usare la shell nativa di Windows / la console a linea di comando, devi usare le doppie virgolette invece delle virgolette singole (per i parametri con che contengono spazi) e devi virgolettare i parametri che terminano con l'accento circonflesso (^) se questi sono al termine della linea, poiché in Windows è uno dei simboli di proseguimento.
 
 ## Prima Configurazione di Git ##
 

From c00e5fc24a3c3ffd61a970903b78ce1f71ea27b6 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Sat, 28 Jun 2014 09:44:25 +0200
Subject: [PATCH 479/690] [it] Introducing changes as per PR#800

Riusando negli esempi il file "README" creato precedentemente
---
 it/02-git-basics/01-chapter2.markdown | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/it/02-git-basics/01-chapter2.markdown b/it/02-git-basics/01-chapter2.markdown
index d817acee6..aa304ff8e 100644
--- a/it/02-git-basics/01-chapter2.markdown
+++ b/it/02-git-basics/01-chapter2.markdown
@@ -406,20 +406,20 @@ Può perciò creare un po' di confusione il fatto che Git abbia un comando `mv`.
 
 e funziona. Se, infatti, lanci un comando del genere e controlli lo stato, vedrai che Git considera il file rinominato:
 
-	$ git mv README.txt README
+	$ git mv README README.txt
 	$ git status
 	On branch master
 	Changes to be committed:
 	  (use "git reset HEAD <file>..." to unstage)
 	
-	        renamed:    README.txt -> README
+	        renamed:    README -> README.txt
 	
 
 Ovviamente, questo è equivalente a eseguire:
 
-	$ mv README.txt README
-	$ git rm README.txt
-	$ git add README
+	$ mv README README.txt
+	$ git rm README
+	$ git add README.txt
 
 Git capisce che, implicitamente stai rinominando il file, così che non c'è differenza se rinominare un file in questo modo o con il comando `mv`. L'unica differenza reale è che `mv` è un solo comando invece di tre: è un questione di convenienza. La cosa più importante è che puoi usare qualsiasi strumento per rinominare un file, e gestire l'aggiunta/rimozione più tardi, prima della commit.
 

From c73da3ca13cff8fa1edbecc3224307e22e185110 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Sat, 28 Jun 2014 09:54:25 +0200
Subject: [PATCH 480/690] [it] updating msygit URL

to http://msysgit.github.io/
---
 it/01-introduction/01-chapter1.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/it/01-introduction/01-chapter1.markdown b/it/01-introduction/01-chapter1.markdown
index 868a83984..8f716ca98 100644
--- a/it/01-introduction/01-chapter1.markdown
+++ b/it/01-introduction/01-chapter1.markdown
@@ -178,7 +178,7 @@ Non ti occorre aggiungere tutti i pacchetti extra, ma probabilmente vorrai inclu
 
 Installare Git su Windows è davvero facile. Il progetto msysGit ha una delle procedure di installazione più facili. Semplicemente scarica l'eseguibile dalla pagina di GitHub e lancialo:
 
-	http://msysgit.github.com/
+	http://msysgit.github.io/
 
 Una volta installato avrai a disposizione sia la versione da riga di comando (incluso un client SSH ti servirà in seguito) sia l'interfaccia grafica (_GUI_) standard.
 

From 1354a7db41b2e3aad98190a5ffab9004395432fa Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Sun, 29 Jun 2014 19:28:00 +0200
Subject: [PATCH 481/690] [it] aggiunge l'uso dei valori numerici per i colori

vedi anche PR n.872
---
 it/07-customizing-git/01-chapter7.markdown | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/it/07-customizing-git/01-chapter7.markdown b/it/07-customizing-git/01-chapter7.markdown
index 4ea91604d..a5e42995a 100644
--- a/it/07-customizing-git/01-chapter7.markdown
+++ b/it/07-customizing-git/01-chapter7.markdown
@@ -1,4 +1,4 @@
-# Customizing Git #
+	# Customizing Git #
 
 Finora abbiamo quindi coperto le basi di come Git funzioni e come usarlo, abbiamo introdotto un numero di strumenti che Git fornisce per aiutarti ad utilizzarlo al meglio ed in modo efficiente. In questo capitolo spiegherò alcune delle operazioni che possono essere utilizzate per personalizzare il comportamento di Git introducendo molti settaggi ed il Hooks System. Tramite questi strumenti, è semplice fare in modo che Git lavori nel modo che tu, la tua azienda, o il tuo gruppo desiderate.
 
@@ -130,7 +130,7 @@ In aggiunta, ognuna di queste ha sottoimpostazioni che possono essere utilizzate
 
 	$ git config --global color.diff.meta "blue black bold"
 
-Il colore può essere impostato di ognuno dei seguenti valori: normal, black, red, green, yellow, blue, magenta, cyan, oppure white. Per quanto riguarda gli attributi, come bold nell'esempio precedente, puoi scegliere tra from bold, dim, ul, blink, e reverse.
+Il colore può essere impostato di ognuno dei seguenti valori: `normal` (normale), `black` (nero), `red` (rosso), `green` (verde), `yellow` (giallo), `blue` (blu), `magenta`, `cyan` (ciano), `white` (bianco) oppure, se il tuo terminale supporta più di sedici colori, un valore numerico per il colore che vada da 0 a 255 (in un terminale a 256 colori). Per quanto riguarda gli attributi, come `bold` nell'esempio precedente, puoi scegliere tra from `bold` (grassetto), `dim` (ridotto), `ul` (sottolineato), `blink` (lampeggiante), e `revers` (a colori invertiti).
 
 Per queste sotto-configurazioni puoi guardare la pagina di manuale di `git config`.
 

From 888599ff6927e874ea5b9a0e4dc257c8f11a5b99 Mon Sep 17 00:00:00 2001
From: harupong <harupong@gmail.com>
Date: Fri, 20 Jun 2014 14:46:19 +0900
Subject: [PATCH 482/690] Apply 7092f29 to ja tree

---
 ja/01-introduction/01-chapter1.markdown       | 2 +-
 ja/03-git-branching/01-chapter3.markdown      | 4 ++--
 ja/05-distributed-git/01-chapter5.markdown    | 2 +-
 ja/07-customizing-git/01-chapter7.markdown    | 2 +-
 ja/08-git-and-other-scms/01-chapter8.markdown | 8 ++++----
 5 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/ja/01-introduction/01-chapter1.markdown b/ja/01-introduction/01-chapter1.markdown
index 039eb307e..9dc643ca3 100644
--- a/ja/01-introduction/01-chapter1.markdown
+++ b/ja/01-introduction/01-chapter1.markdown
@@ -190,7 +190,7 @@ Windows利用時の注意点: この本で紹介されている複雑なコマ
 
 今や、Gitがシステムにあります。Git環境をカスタマイズするためにしたい事が少しはあることでしょう。アップグレードの度についてまわるので、たった一度でそれらを終わらすべきでしょう。またそれらは、またコマンドを実行することによっていつでも変更することができます。
 
-Gitには、git configと呼ばれるツールが付属します。これで、どのようにGitが見えて機能するかの全ての面を制御できる設定変数を取得し、設定することができます。これらの変数は三つの異なる場所に格納されうります：
+Gitには、`git config`と呼ばれるツールが付属します。これで、どのようにGitが見えて機能するかの全ての面を制御できる設定変数を取得し、設定することができます。これらの変数は三つの異なる場所に格納されうります：
 
 *	`/etc/gitconfig` file: システム上の全てのユーザーと全てのリポジトリに対する設定値を保持します。もし`--system`オプションを`git config`に指定すると、明確にこのファイルに読み書きを行ないます。
 *	`~/.gitconfig` file: 特定のユーザーに対する設定値を保持します. `--global`オプションを指定することで、Gitに、明確にこのファイルに読み書きを行なわせることができます。
diff --git a/ja/03-git-branching/01-chapter3.markdown b/ja/03-git-branching/01-chapter3.markdown
index 6b16045b8..7d002206e 100644
--- a/ja/03-git-branching/01-chapter3.markdown
+++ b/ja/03-git-branching/01-chapter3.markdown
@@ -41,7 +41,7 @@ Insert 18333fig0303.png
 Insert 18333fig0304.png
 図 3-4. 複数のブランチがコミットデータの履歴を指す例
 
-Git は、あなたが今どのブランチで作業しているのかをどうやって知るのでしょうか? それを保持する特別なポインタが HEAD と呼ばれるものです。これは、Subversion や CVS といった他の VCS における HEAD の概念とはかなり違うものであることに注意しましょう。Git では、HEAD はあなたが作業しているローカルブランチへのポインタとなります。今回の場合は、あなたはまだ master ブランチにいます。git branch コマンドは新たにブランチを作成するだけであり、そのブランチに切り替えるわけではありません (図 3-5 を参照ください)。
+Git は、あなたが今どのブランチで作業しているのかをどうやって知るのでしょうか? それを保持する特別なポインタが HEAD と呼ばれるものです。これは、Subversion や CVS といった他の VCS における HEAD の概念とはかなり違うものであることに注意しましょう。Git では、HEAD はあなたが作業しているローカルブランチへのポインタとなります。今回の場合は、あなたはまだ master ブランチにいます。`git branch` コマンドは新たにブランチを作成するだけであり、そのブランチに切り替えるわけではありません (図 3-5 を参照ください)。
 
 Insert 18333fig0305.png
 図 3-5. 現在作業中のブランチを指す HEAD
@@ -402,7 +402,7 @@ Insert 18333fig0323.png
 手元での作業を同期させるには、`git fetch origin` コマンドを実行します。このコマンドは、まず origin が指すサーバー (今回の場合は `git.ourcompany.com`) を探し、まだ手元にないデータをすべて取得し、ローカルデータベースを更新し、`origin/master` が指す先を最新の位置に変更します (図 3-24 を参照ください)。
 
 Insert 18333fig0324.png
-図 3-24. git fetch コマンドによるリモートへの参照の更新
+図 3-24. `git fetch` コマンドによるリモートへの参照の更新
 
 複数のリモートサーバーがあった場合にリモートのブランチがどのようになるのかを知るために、もうひとつ Git サーバーがあるものと仮定しましょう。こちらのサーバーは、チームの一部のメンバーが開発目的にのみ使用しています。このサーバーは `git.team1.ourcompany.com` にあるものとしましょう。このサーバーをあなたの作業中のプロジェクトから参照できるようにするには、第 2 章で紹介した `git remote add` コマンドを使用します。このリモートに `teamone` という名前をつけ、URL ではなく短い名前で参照できるようにします (図 3-25 を参照ください)。
 
diff --git a/ja/05-distributed-git/01-chapter5.markdown b/ja/05-distributed-git/01-chapter5.markdown
index 2b68260f7..0c44af676 100644
--- a/ja/05-distributed-git/01-chapter5.markdown
+++ b/ja/05-distributed-git/01-chapter5.markdown
@@ -606,7 +606,7 @@ Git はその後、各パッチについてこのようなログ情報をはき
 
 これは、作業ディレクトリ内のファイルを変更します。`patch -p1` コマンドでパッチをあてるのとほぼ同じなのですが、それ以上に「これでもか」というほどのこだわりを持ってパッチを適用するので fuzzy マッチになる可能性が少なくなります。また、`git diff` 形式ではファイルの追加・削除やファイル名の変更も扱うことができますが、`patch` コマンドにはそれはできません。そして最後に、`git apply` は「全部適用するか、あるいは一切適用しないか」というモデルを採用しています。一方 `patch` コマンドの場合は、途中までパッチがあたった中途半端な状態になって困ることがあります。`git apply` のほうが、 `patch` よりもこだわりを持った処理を行うのです。`git apply` コマンドはコミットを作成するわけではありません。実行した後で、その変更をステージしてコミットする必要があります。
 
-git apply を使って、そのパッチをきちんと適用できるかどうかを事前に確かめることができます。パッチをチェックするには `git apply --check` を実行します。
+`git apply` を使って、そのパッチをきちんと適用できるかどうかを事前に確かめることができます。パッチをチェックするには `git apply --check` を実行します。
 
 	$ git apply --check 0001-seeing-if-this-helps-the-gem.patch
 	error: patch failed: ticgit.gemspec:1
diff --git a/ja/07-customizing-git/01-chapter7.markdown b/ja/07-customizing-git/01-chapter7.markdown
index 860824fbe..86ea6fca3 100644
--- a/ja/07-customizing-git/01-chapter7.markdown
+++ b/ja/07-customizing-git/01-chapter7.markdown
@@ -511,7 +511,7 @@ RCSスタイルの`$Date$`キーワード展開もまた別の興味深い例で
 
 	test/ export-ignore
 
-これで、プロジェクトのtarballを作成するためにgitを実行した時、アーカイブには`test/`ディレクトリが含まれないようになります。
+これで、プロジェクトのtarballを作成するために`git archive`を実行した時、アーカイブには`test/`ディレクトリが含まれないようになります。
 
 #### export-subst ####
 
diff --git a/ja/08-git-and-other-scms/01-chapter8.markdown b/ja/08-git-and-other-scms/01-chapter8.markdown
index 7b86af20e..6f41e8a70 100644
--- a/ja/08-git-and-other-scms/01-chapter8.markdown
+++ b/ja/08-git-and-other-scms/01-chapter8.markdown
@@ -203,7 +203,7 @@ Git と Subversion の橋渡しをするコマンド群のベースとなるコ
 
 ### Git でのブランチに関する問題 ###
 
-Git のワークフローに慣れてくると、トピックブランチを作ってそこで作業を行い、それをマージすることもあるでしょう。git svn を使って Subversion サーバーにプッシュする場合は、それらのブランチをまとめてプッシュするのではなく一つのブランチ上にリベースしてからプッシュしたくなるかもしれません。リベースしたほうがよい理由は、Subversion はリニアに歴史を管理していて Git のようなマージができないからです。git svn がスナップショットを Subversion のコミットに変換するときには、最初の親だけに続けます。
+Git のワークフローに慣れてくると、トピックブランチを作ってそこで作業を行い、それをマージすることもあるでしょう。`git svn` を使って Subversion サーバーにプッシュする場合は、それらのブランチをまとめてプッシュするのではなく一つのブランチ上にリベースしてからプッシュしたくなるかもしれません。リベースしたほうがよい理由は、Subversion はリニアに歴史を管理していて Git のようなマージができないからです。`git svn` がスナップショットを Subversion のコミットに変換するときには、最初の親だけに続けます。
 
 歴史が次のような状態になっているものとしましょう。`experiment` ブランチを作ってそこで 2 回のコミットを済ませ、それを `master` にマージしたところです。ここで `dcommit` すると、出力はこのようになります。
 
@@ -232,7 +232,7 @@ Git のワークフローに慣れてくると、トピックブランチを作
 
 ### Subversion のブランチ ###
 
-Subversion のブランチは Git のブランチとは異なります。可能ならば、Subversion のブランチは使わないようにするのがベストでしょう。しかし、Subversion のブランチの作成やコミットも、git svn を使ってすることができます。
+Subversion のブランチは Git のブランチとは異なります。可能ならば、Subversion のブランチは使わないようにするのがベストでしょう。しかし、Subversion のブランチの作成やコミットも、`git svn` を使ってすることができます。
 
 #### 新しい SVN ブランチの作成 ####
 
@@ -501,7 +501,7 @@ Subversion や Perforce 以外のシステムを使っている場合は、そ
 
 Git のディレクトリにインポートするにはまず、これらのデータをどのように Git に格納するかをレビューしなければなりません。Git は基本的にはコミットオブジェクトのリンクリストであり、コミットオブジェクトがコンテンツのスナップショットを指しています。`fast-import` に指示しなければならないのは、コンテンツのスナップショットが何でどのコミットデータがそれを指しているのかということと、コミットデータを取り込む順番だけです。ここでは、スナップショットをひとつずつたどって各ディレクトリの中身をさすコミットオブジェクトを作り、それらを日付順にリンクさせるものとします。
 
-第 7 章の「Git ポリシーの実施例」同様、ここでも Ruby を使って書きます。ふだんから使いなれており、きっと他の方にも読みやすいであろうからです。このサンプルをあなたの使いなれた言語で書き換えるのも簡単でしょう。単に適切な情報を標準出力に送るだけなのだから。また、Windows を使っている場合は、行末にキャリッジリターンを含めないように注意が必要です。git fast-import が想定している行末は LF だけであり、Windows で使われている CRLF は想定していません。
+第 7 章の「Git ポリシーの実施例」同様、ここでも Ruby を使って書きます。ふだんから使いなれており、きっと他の方にも読みやすいであろうからです。このサンプルをあなたの使いなれた言語で書き換えるのも簡単でしょう。単に適切な情報を標準出力に送るだけなのだから。また、Windows を使っている場合は、行末にキャリッジリターンを含めないように注意が必要です。`git fast-import` が想定している行末は LF だけであり、Windows で使われている CRLF は想定していません。
 
 まず最初に対象ディレクトリに移動し、コミットとしてインポートするスナップショットとしてサブディレクトリを識別します。基本的なメインループは、このようになります。
 
@@ -602,7 +602,7 @@ Git のディレクトリにインポートするにはまず、これらのデ
 
 	return mark
 
-注意: Windows 上で動かす場合はさらにもう一手間必要です。先述したように、Windows の改行文字は CRLF ですが git fast-import は LF にしか対応していません。この問題に対応して git fast-import をうまく動作させるには、CRLF ではなく LF を使うよう ruby に指示しなければなりません。
+注意: Windows 上で動かす場合はさらにもう一手間必要です。先述したように、Windows の改行文字は CRLF ですが `git fast-import` は LF にしか対応していません。この問題に対応して `git fast-import` をうまく動作させるには、CRLF ではなく LF を使うよう ruby に指示しなければなりません。
 
 	$stdout.binmode
 

From 468fc7712a9667064c1c7dda5a866de3ea2cec9d Mon Sep 17 00:00:00 2001
From: harupong <harupong@gmail.com>
Date: Fri, 20 Jun 2014 14:54:10 +0900
Subject: [PATCH 483/690] Apply 0ecb879 to ja tree

---
 ja/04-git-server/01-chapter4.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ja/04-git-server/01-chapter4.markdown b/ja/04-git-server/01-chapter4.markdown
index 5aa3b77e5..af26092c6 100644
--- a/ja/04-git-server/01-chapter4.markdown
+++ b/ja/04-git-server/01-chapter4.markdown
@@ -118,7 +118,7 @@ Git サーバーを立ち上げるには、既存のリポジトリをエクス
     Cloning into bare repository 'my_project.git'...
     done.
 
-このコマンドを実行したときの出力はちょっとわかりにくいかもしれません。`clone` は基本的に `git init` をしてから `git fetch` をするのと同じことなので、`git init` の部分の出力も見ることになります。そのメッセージは「空のディレクトリを作成しました」というものです。実際にどんなオブジェクトの転送が行われたのかは何も表示されませんが、きちんと転送は行われています。これで、`my_project.git` ディレクトリに Git リポジトリのデータができあがりました。
+そうすると、Git ディレクトリのデータを `my_project.git` ディレクトリにコピーできます。
 
 これは、おおざっぱに言うと次の操作と同じようなことです。
 

From caa686a5648baf26a92d0e40282c4b317e94b06a Mon Sep 17 00:00:00 2001
From: harupong <harupong@gmail.com>
Date: Fri, 20 Jun 2014 14:59:59 +0900
Subject: [PATCH 484/690] Apply 1786822 to ja tree

---
 ja/05-distributed-git/01-chapter5.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ja/05-distributed-git/01-chapter5.markdown b/ja/05-distributed-git/01-chapter5.markdown
index 0c44af676..5dd8964f2 100644
--- a/ja/05-distributed-git/01-chapter5.markdown
+++ b/ja/05-distributed-git/01-chapter5.markdown
@@ -627,7 +627,7 @@ Git はその後、各パッチについてこのようなログ情報をはき
 
 	Limit log functionality to the first 20
 
-先ほどのセクションでごらんいただいたように、format-patch コマンドの出力結果もこれと同じ形式で始まっていますね。これは、mbox 形式のメールフォーマットとしても正しいものです。git send-email を正しく使ったパッチが送られてきた場合、受け取ったメールを mbox 形式で保存して git am コマンドでそのファイルを指定すると、すべてのパッチの適用が始まります。複数のメールをまとめてひとつの mbox に保存できるメールソフトを使っていれば、送られてきたパッチをひとつのファイルにまとめて git am で一度に適用することもできます。
+先ほどのセクションでごらんいただいたように、format-patch コマンドの出力結果もこれと同じ形式で始まっていますね。これは、mbox 形式のメールフォーマットとしても正しいものです。`git send-email` を正しく使ったパッチが送られてきた場合、受け取ったメールを mbox 形式で保存して `git am` コマンドでそのファイルを指定すると、すべてのパッチの適用が始まります。複数のメールをまとめてひとつの mbox に保存できるメールソフトを使っていれば、送られてきたパッチをひとつのファイルにまとめて `git am` で一度に適用することもできます。
 
 しかし、`format-patch` で作ったパッチがチケットシステム (あるいはそれに類する何か) にアップロードされたような場合は、まずそのファイルをローカルに保存して、それを `git am` に渡すことになります。
 

From 71736c19716b13c62e1f46171bbbe2ac524ae735 Mon Sep 17 00:00:00 2001
From: harupong <harupong@gmail.com>
Date: Fri, 20 Jun 2014 15:04:54 +0900
Subject: [PATCH 485/690] Apply 20a3f53 to ja tree

---
 ja/06-git-tools/01-chapter6.markdown | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/ja/06-git-tools/01-chapter6.markdown b/ja/06-git-tools/01-chapter6.markdown
index 84519bda2..15e854955 100644
--- a/ja/06-git-tools/01-chapter6.markdown
+++ b/ja/06-git-tools/01-chapter6.markdown
@@ -476,8 +476,8 @@ apply オプションは、スタックに隠した作業を再度適用する
 
 	$ git stash list
 	stash@{0}: WIP on master: 049d078 added the index file
-	stash@{1}: WIP on master: c264051... Revert "added file_size"
-	stash@{2}: WIP on master: 21d80a5... added number to log
+	stash@{1}: WIP on master: c264051 Revert "added file_size"
+	stash@{2}: WIP on master: 21d80a5 added number to log
 	$ git stash drop stash@{0}
 	Dropped stash@{0} (364e91f3f268f0900bc3ee613f9f733e82aaed43)
 

From 3e51e0c1194cd76d834736fafdb22c8d969ac20d Mon Sep 17 00:00:00 2001
From: harupong <harupong@gmail.com>
Date: Fri, 20 Jun 2014 15:09:17 +0900
Subject: [PATCH 486/690] Apply 9c4252b to ja tree

---
 ja/06-git-tools/01-chapter6.markdown | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/ja/06-git-tools/01-chapter6.markdown b/ja/06-git-tools/01-chapter6.markdown
index 15e854955..90a2342e9 100644
--- a/ja/06-git-tools/01-chapter6.markdown
+++ b/ja/06-git-tools/01-chapter6.markdown
@@ -441,8 +441,8 @@ simplegit.rb のステータスがおもしろいことになっています。
 
 	$ git stash list
 	stash@{0}: WIP on master: 049d078 added the index file
-	stash@{1}: WIP on master: c264051... Revert "added file_size"
-	stash@{2}: WIP on master: 21d80a5... added number to log
+	stash@{1}: WIP on master: c264051 Revert "added file_size"
+	stash@{2}: WIP on master: 21d80a5 added number to log
 
 この例では、以前にも二回ほど作業を隠していたようです。そこで、三種類の異なる作業にアクセスできるようになっています。先ほど隠した変更を再度適用するには、stash コマンドの出力に書かれていたように `git stash apply` コマンドを実行します。それよりもっと前に隠したものを適用したい場合は `git stash apply stash@{2}` のようにして名前を指定することもできます。名前を指定しなければ、Git は直近に隠された変更を再適用します。
 

From 074f6f806f0b655d4b4814a0bc29c15154505c3e Mon Sep 17 00:00:00 2001
From: harupong <harupong@gmail.com>
Date: Fri, 20 Jun 2014 15:10:18 +0900
Subject: [PATCH 487/690] Apply 5f72fef to ja tree

---
 ja/06-git-tools/01-chapter6.markdown | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/ja/06-git-tools/01-chapter6.markdown b/ja/06-git-tools/01-chapter6.markdown
index 90a2342e9..40379d5ee 100644
--- a/ja/06-git-tools/01-chapter6.markdown
+++ b/ja/06-git-tools/01-chapter6.markdown
@@ -81,13 +81,13 @@ SHA-1 の衝突を見るにはどうしたらいいのか、ひとつの例を
 参照ログを見るには `git reflog` を使います。
 
 	$ git reflog
-	734713b... HEAD@{0}: commit: fixed refs handling, added gc auto, updated
-	d921970... HEAD@{1}: merge phedders/rdocs: Merge made by recursive.
-	1c002dd... HEAD@{2}: commit: added some blame and merge stuff
-	1c36188... HEAD@{3}: rebase -i (squash): updating HEAD
-	95df984... HEAD@{4}: commit: # This is a combination of two commits.
-	1c36188... HEAD@{5}: rebase -i (squash): updating HEAD
-	7e05da5... HEAD@{6}: rebase -i (pick): updating HEAD
+	734713b HEAD@{0}: commit: fixed refs handling, added gc auto, updated
+	d921970 HEAD@{1}: merge phedders/rdocs: Merge made by recursive.
+	1c002dd HEAD@{2}: commit: added some blame and merge stuff
+	1c36188 HEAD@{3}: rebase -i (squash): updating HEAD
+	95df984 HEAD@{4}: commit: # This is a combination of two commits.
+	1c36188 HEAD@{5}: rebase -i (squash): updating HEAD
+	7e05da5 HEAD@{6}: rebase -i (pick): updating HEAD
 
 何らかの理由でブランチの先端が更新されるたびに、Git はその情報をこの一時履歴に格納します。そして、このデータを使って過去のコミットを指定することもできます。リポジトリの HEAD の五つ前の状態を知りたい場合は、先ほど見た reflog の出力のように `@{n}` 形式で参照することができます。
 

From 6dfa9e1ff7d35612596208429b70e505a9a5b4d5 Mon Sep 17 00:00:00 2001
From: harupong <harupong@gmail.com>
Date: Fri, 20 Jun 2014 15:16:57 +0900
Subject: [PATCH 488/690] Apply f987da8 to ja tree

---
 ja/07-customizing-git/01-chapter7.markdown | 12 +++++-------
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/ja/07-customizing-git/01-chapter7.markdown b/ja/07-customizing-git/01-chapter7.markdown
index 86ea6fca3..4050bdcf9 100644
--- a/ja/07-customizing-git/01-chapter7.markdown
+++ b/ja/07-customizing-git/01-chapter7.markdown
@@ -613,14 +613,12 @@ update スクリプトは `pre-receive` スクリプトと似ていますが、
 
 	#!/usr/bin/env ruby
 
-	$refname = ARGV[0]
-	$oldrev  = ARGV[1]
-	$newrev  = ARGV[2]
-	$user    = ENV['USER']
-
-	puts "Enforcing Policies... \n(#{$refname}) (#{$oldrev[0,6]}) (#{$newrev[0,6]})"
+	refname = ARGV[0]
+	oldrev  = ARGV[1]
+	newrev  = ARGV[2]
+	user    = ENV['USER']
 
-ああ、グローバル変数を使ってるとかいうツッコミは勘弁してください。このほうが説明が楽なので。
+	puts "Enforcing Policies... \n(#{refname}) (#{oldrev[0,6]}) (#{newrev[0,6]})"
 
 #### 特定のコミットメッセージ書式の強制 ####
 

From 5c868cd9538db8c48250fd1bb46ba45e2fcde77c Mon Sep 17 00:00:00 2001
From: harupong <harupong@gmail.com>
Date: Thu, 26 Jun 2014 15:28:43 +0900
Subject: [PATCH 489/690] Apply f5170bb to ja tree

---
 ja/02-git-basics/01-chapter2.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ja/02-git-basics/01-chapter2.markdown b/ja/02-git-basics/01-chapter2.markdown
index b78d99bf7..fdc4f7980 100755
--- a/ja/02-git-basics/01-chapter2.markdown
+++ b/ja/02-git-basics/01-chapter2.markdown
@@ -323,7 +323,7 @@ glob パターンとは、シェルで用いる簡易正規表現のようなも
 あるいは、コミットメッセージをインラインで記述することもできます。その場合は、`commit` コマンドの後で `-m` フラグに続けて次のように記述します。
 
 	$ git commit -m "Story 182: Fix benchmarks for speed"
-	[master 463dc4f] Fix benchmarks for speed
+	[master 463dc4f] Story 182: Fix benchmarks for speed
 	 2 files changed, 3 insertions(+)
 	 create mode 100644 README
 

From bf8c8bb47d2fc16ac21f5562da62b02a4a2d27e5 Mon Sep 17 00:00:00 2001
From: harupong <harupong@gmail.com>
Date: Thu, 26 Jun 2014 16:27:02 +0900
Subject: [PATCH 490/690] Apply #750 #787 to ja tree

Also applied 038f1f0 as it is related to those two pull requests.
---
 ja/02-git-basics/01-chapter2.markdown | 56 ++++++++++++++++++++++++---
 1 file changed, 50 insertions(+), 6 deletions(-)

diff --git a/ja/02-git-basics/01-chapter2.markdown b/ja/02-git-basics/01-chapter2.markdown
index fdc4f7980..2bfd2962a 100755
--- a/ja/02-git-basics/01-chapter2.markdown
+++ b/ja/02-git-basics/01-chapter2.markdown
@@ -650,15 +650,59 @@ The lines must be formatted as follows
 
 	オプション	説明
 	-(n)	直近の n 件のコミットのみを表示する
-	--since, --after	指定した日付以降のコミットのみに制限する
-	--until, --before	指定した日付以前のコミットのみに制限する
+	--since, --after    指定した日付/時刻以降のCommitDateのコミットのみに制限する
+	--until, --before    指定した日付/時刻以前のCommitDateのコミットのみに制限する
 	--author	エントリが指定した文字列にマッチするコミットのみを表示する
 	--committer	エントリが指定した文字列にマッチするコミットのみを表示する
 
-たとえば、Git ソースツリーのテストファイルに対する変更があったコミットのうち、Junio Hamano がコミットしたもの (マージは除く) で 2008 年 10 月に行われたものを知りたければ次のように指定します。
+### 日時にもとづくログ出力の制限 ###
 
-	$ git log --pretty="%h - %s" --author=gitster --since="2008-10-01" \
-	   --before="2008-11-01" --no-merges -- t/
+Git のリポジトリ(git://git.kernel.org/pub/scm/git/git.git)からCommitDateを使ってコミットを検索してみましょう。パソコンに設定されたタイムゾーンにおける2014/04/29のコミットを検索するには、以下のコマンドを実行します。
+
+    $ git log --after="2014-04-29 00:00:00" --before="2014-04-29 23:59:59" \
+      --pretty=fuller
+
+この場合、コマンドの結果はパソコンのタイムゾーン設定ごとに異なってしまいます。それを避けるには、タイムゾーンを含むISO 8601フォーマットのような日時を `--after` や `--before` の引数に指定するといいでしょう。そうすれば、上述のケースのようにコマンド実行結果が異なる可能性がなくなります。
+
+特定日時(例として、中央ヨーロッパ時間で2013/04/29 17:07:22)を指定してコミットを検索するには、以下のコマンドを使います。
+
+    $ git log  --after="2013-04-29T17:07:22+0200"      \
+              --before="2013-04-29T17:07:22+0200" --pretty=fuller
+    
+    commit de7c201a10857e5d424dbd8db880a6f24ba250f9
+    Author:     Ramkumar Ramachandra <artagnon@gmail.com>
+    AuthorDate: Mon Apr 29 18:19:37 2013 +0530
+    Commit:     Junio C Hamano <gitster@pobox.com>
+    CommitDate: Mon Apr 29 08:07:22 2013 -0700
+    
+        git-completion.bash: lexical sorting for diff.statGraphWidth
+        
+        df44483a (diff --stat: add config option to limit graph width,
+        2012-03-01) added the option diff.startGraphWidth to the list of
+        configuration variables in git-completion.bash, but failed to notice
+        that the list is sorted alphabetically.  Move it to its rightful place
+        in the list.
+        
+        Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
+        Signed-off-by: Junio C Hamano <gitster@pobox.com>
+
+これらの日時(`AuthorDate` と `CommitDate`)はGitのデフォルトフォーマット(`--date=default` オプション相当)です。作者とコミッター、それぞれのタイムゾーン情報を表示します。
+
+日時フォーマットの指定は他にも `--date=iso` (ISO 8601)、`--date=rfc` (RFC 2822)、`--date=raw` (Unix時間)、`--date=local` (端末のタイムゾーン)、`--date=relative`("2 hours ago"のように相対的な指定)などがあります。
+
+また、 `git log` 実行時に日時指定を省略すると、パソコンの時計をもとにコマンド実行日時を指定日時として使用します(協定標準時からの時差も同一になります)。
+
+具体的には、仮にパソコンの時計が09:00を指していて、かつタイムゾーン設定が協定標準時プラス3時間の場合、以下の `git log` コマンドの日時指定は同一として扱われます。
+
+    $ git log --after=2008-06-01 --before=2008-07-01
+    $ git log --after="2008-06-01T09:00:00+0300" \
+        --before="2008-07-01T09:00:00+0300"
+
+もう一つ例を挙げておきましょう。Git ソースツリーのテストファイルに対する変更があったコミットのうち、Junio Hamano がコミットしたもの (マージは除く) で 2008 年 10 月(ニューヨークのタイムゾーン)に行われたものを知りたければ次のように指定します。
+
+	$ git log --pretty="%h - %s" --author=gitster \
+	   --after="2008-10-01T00:00:00-0400"         \
+	  --before="2008-10-31T23:59:59-0400" --no-merges -- t/
 	5610e3b - Fix testcase failure when extended attribute
 	acd3b9e - Enhance hold_lock_file_for_{update,append}()
 	f563754 - demonstrate breakage of detached checkout wi
@@ -666,7 +710,7 @@ The lines must be formatted as follows
 	51a94af - Fix "checkout --track -b newbranch" on detac
 	b0ad11e - pull: allow "git pull origin $something:$cur
 
-約 20,000 件におよぶ Git ソースコードのコミットの歴史の中で、このコマンドの条件にマッチするのは 6 件となります。
+約 36,000 件におよぶ Git ソースコードのコミットの歴史の中で、このコマンドの条件にマッチするのは 6 件となります。
 
 ### GUI による歴史の可視化 ###
 

From c3d1c382901a56433e3f6693345a7f0a4548278f Mon Sep 17 00:00:00 2001
From: harupong <harupong@gmail.com>
Date: Tue, 1 Jul 2014 15:26:52 +0900
Subject: [PATCH 491/690] Fix indent for pdf table output

---
 ja/02-git-basics/01-chapter2.markdown | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/ja/02-git-basics/01-chapter2.markdown b/ja/02-git-basics/01-chapter2.markdown
index 2bfd2962a..775f52e51 100755
--- a/ja/02-git-basics/01-chapter2.markdown
+++ b/ja/02-git-basics/01-chapter2.markdown
@@ -650,8 +650,8 @@ The lines must be formatted as follows
 
 	オプション	説明
 	-(n)	直近の n 件のコミットのみを表示する
-	--since, --after    指定した日付/時刻以降のCommitDateのコミットのみに制限する
-	--until, --before    指定した日付/時刻以前のCommitDateのコミットのみに制限する
+	--since, --after	指定した日付/時刻以降のCommitDateのコミットのみに制限する
+	--until, --before	指定した日付/時刻以前のCommitDateのコミットのみに制限する
 	--author	エントリが指定した文字列にマッチするコミットのみを表示する
 	--committer	エントリが指定した文字列にマッチするコミットのみを表示する
 

From f138201bbd15091db65eb5c25797e10a9921510c Mon Sep 17 00:00:00 2001
From: cor <git@cpt1.demon.nl>
Date: Mon, 7 Jul 2014 15:01:11 +0200
Subject: [PATCH 492/690] [NL] resynchronized with 4cefec

---
 nl/01-introduction/01-chapter1.markdown       |  4 +-
 nl/02-git-basics/01-chapter2.markdown         | 70 +++++++++++++++----
 nl/03-git-branching/01-chapter3.markdown      |  4 +-
 nl/04-git-server/01-chapter4.markdown         |  4 +-
 nl/05-distributed-git/01-chapter5.markdown    |  6 +-
 nl/06-git-tools/01-chapter6.markdown          |  6 +-
 nl/07-customizing-git/01-chapter7.markdown    | 16 ++---
 nl/08-git-and-other-scms/01-chapter8.markdown | 10 +--
 nl/09-git-internals/01-chapter9.markdown      |  4 +-
 9 files changed, 83 insertions(+), 41 deletions(-)

diff --git a/nl/01-introduction/01-chapter1.markdown b/nl/01-introduction/01-chapter1.markdown
index 2a6870648..458169187 100644
--- a/nl/01-introduction/01-chapter1.markdown
+++ b/nl/01-introduction/01-chapter1.markdown
@@ -33,10 +33,10 @@ vertaling moeten proberen te maken.
 
 Veel succes en plezier bij het vertalen...
 -->
-<!-- SHA-1 of last checked en-version: 3c18779 -->
+<!-- SHA-1 of last checked en-version: 4cefec -->
 # Aan de slag #
 
-In dit hoofdstuk wordt uitgelegd hoe je aan de slag kunt gaan met Git. We zullen bij het begin beginnen door wat achtergrondinformatie over versiebeheersystemen te geven, daarna een korte uitleg hoe je Git werkend kan krijgen op je computer en sluiten af door uit te leggen hoe je Git kan instellen zodat je ermee aan het werk kunt.  Aan het einde van dit hoofdstuk zou je moeten kunnen begrijpen waarom Git er is, waarom je het zou moeten gebruiken en zal je helemaal klaar zijn om er mee aan de slag te gaan.
+In dit hoofdstuk wordt uitgelegd hoe je aan de slag kunt gaan met Git. We zullen beginnen met wat achtergrondinformatie over versiebeheersystemen te geven, daarna een korte uitleg hoe je Git werkend kan krijgen op je computer en sluiten af door uit te leggen hoe je Git kan instellen zodat je ermee aan het werk kunt.  Aan het einde van dit hoofdstuk zou je moeten kunnen begrijpen waarom Git er is, waarom je het zou moeten gebruiken en zal je helemaal klaar zijn om er mee aan de slag te gaan.
 
 ## Het wat en waarom van versiebeheer ##
 
diff --git a/nl/02-git-basics/01-chapter2.markdown b/nl/02-git-basics/01-chapter2.markdown
index 1df052bc7..a87e88310 100644
--- a/nl/02-git-basics/01-chapter2.markdown
+++ b/nl/02-git-basics/01-chapter2.markdown
@@ -33,7 +33,7 @@ vertaling moeten proberen te maken.
 
 Veel succes en plezier bij het vertalen...
 -->
-<!-- SHA-1 of last checked en-version: 3c18779  -->
+<!-- SHA-1 of last checked en-version: 4cefec  -->
 # De basis van Git #
 
 Als je slechts één hoofdstuk kunt lezen om met Git aan de slag te gaan, dan is dit het. In dit hoofdstuk worden alle basiscommando's behandeld, die je nodig hebben om het leeuwendeel van de dingen te doen waarmee je uiteindelijk je tijd met Git zult doorbrengen. Als je dit hoofdstuk doorgenomen hebt, zul je een repository kunnen configureren en initialiseren, bestanden beginnen en stoppen te volgen en veranderingen te ‘stagen’ en ‘committen’. We laten ook zien hoe je Git kunt instellen zodat het bepaalde bestanden en bestandspatronen negeert, hoe je vergissingen snel en gemakkelijk ongedaan kunt maken, hoe je de geschiedenis van je project kan doorlopen en wijzigingen tussen commits kunt zien, en hoe je kunt pushen naar en pullen van repositories.
@@ -358,7 +358,7 @@ Je kunt zien dat de standaard commit boodschap de laatste output van het `git st
 Als alternatief kun je de commit boodschap met het `commit` commando meegeven door hem achter de `-m` optie te specificeren, zoals hier:
 
 	$ git commit -m "Story 182: Fix benchmarks for speed"
-	[master 463dc4f] Fix benchmarks for speed
+	[master 463dc4f] Story 182: Fix benchmarks for speed
 	 2 files changed, 3 insertions(+)
 	 create mode 100644 README
 
@@ -440,20 +440,20 @@ Het is daarom een beetje verwarrend dat Git een `mv` commando heeft. Als je een
 
 en dat werkt prima. Sterker nog, als je zoiets als dit uitvoert en naar de status kijkt, zul je zien dat Git het als een hernoemd bestand beschouwt:
 
-	$ git mv README.txt README
+	$ git mv README README.txt
 	$ git status
 	On branch master
 	Changes to be committed:
 	  (use "git reset HEAD <file>..." to unstage)
 	
-	        renamed:    README.txt -> README
+	        renamed:    README -> README.txt
 	
 
 Maar dat is gelijk aan het uitvoeren van het volgende:
 
-	$ mv README.txt README
-	$ git rm README.txt
-	$ git add README
+	$ mv README README.txt
+	$ git rm README
+	$ git add README.txt
 
 Git komt er impliciet achter dat het om een hernoemd bestand gaat, dus het maakt niet uit of je een bestand op deze manier hernoemt of met het `mv` commando. Het enige echte verschil is dat het `mv` commando slechts één commando is in plaats van drie. En belangrijker nog is dat je iedere applicatie kunt gebruiken om een bestand te hernoemen, en de add/rm later kunt afhandelen voordat je commit.
 
@@ -682,15 +682,59 @@ The lines must be formatted as follows
 
 	Optie	Omschrijving
 	-(n)	Laat alleen de laatste n commits zien
-	--since, --after	Limiteer de commits tot degenen na de gegeven datum.
-	--until, --before	Limiteer de commits tot degenen voor de gegeven datum.
+	--since, --after	Limiteer de commits tot degenen waarvan de CommitDate op of na de gegeven datum/tijd ligt.
+	--until, --before	Limiteer de commits tot degenen waarvan de CommitDate op of voor de gegeven datum/tijd ligt.
 	--author	Laat alleen de commits zien waarvan de auteur bij de gegeven tekst past.
 	--committer	Laat alleen de commits zien waarvan de committer bij de gegeven tekst past.
 
-Bijvoorbeeld, als je wilt zien welke commits test bestanden in de Git broncode geschiedenis aanpasten waarvan de committer Junio Hamano is en die in de maand oktober van 2008 gemerged zijn, kun je zoiets als dit uitvoeren:
+### Log uitvoer beperken volgens datum/tijd ###
+
+Om te bepalen welke commits in de Git broncode repository aanwezig zijn  (git://git.kernel.org/pub/scm/git/git.git) met een CommitDate van 2014-04-29 relatief aan je lokale tijdzone (zoals ingesteld op jouw computer), gebruik je
+
+    $ git log --after="2014-04-29 00:00:00" --before="2014-04-29 23:59:59" \
+      --pretty=fuller
+
+Omdat de uitvoer zal verschillen met de tijdzone waar dit commando wordt gegeven, wordt het aangeraden om altijd een absolute tijd zoals volgens het ISO 8601 formaat (welke tijdzone informatie bevat) als argument bij `--after` and `--before` te gebruiken, zodat iedereen die het commando geeft dezelfde herhaalbare resultaten krijgt. 
+
+Om de commits gemaakt op een specifiek moment in de tijd te krijgen (bijv. 29 April 2013 om 17:07:22 CET), kunnen we dit gebruiken
+
+    $ git log  --after="2013-04-29T17:07:22+0200"      \
+              --before="2013-04-29T17:07:22+0200" --pretty=fuller
+    
+    commit de7c201a10857e5d424dbd8db880a6f24ba250f9
+    Author:     Ramkumar Ramachandra <artagnon@gmail.com>
+    AuthorDate: Mon Apr 29 18:19:37 2013 +0530
+    Commit:     Junio C Hamano <gitster@pobox.com>
+    CommitDate: Mon Apr 29 08:07:22 2013 -0700
+    
+        git-completion.bash: lexical sorting for diff.statGraphWidth
+        
+        df44483a (diff --stat: add config option to limit graph width,
+        2012-03-01) added the option diff.startGraphWidth to the list of
+        configuration variables in git-completion.bash, but failed to notice
+        that the list is sorted alphabetically.  Move it to its rightful place
+        in the list.
+        
+        Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
+        Signed-off-by: Junio C Hamano <gitster@pobox.com>
+
+De bovenstaande tijden (`AuthorDate`, `CommitDate`) worden getoond in het standaard formaat (`--date=default`), welke de tijdzone informatie van respectievelijk de auteur en committer weergeeft.
+
+Andere nuttige formaten zijn onder andere `--date=iso` (ISO 8601), `--date=rfc` (RFC 2822), `--date=raw` (seconden sinds de "epoch" (1970-01-01 UTC)) `--date=local` (tijden volgens jouw locale tijdzone) alsmede `--date=relative` (bijv. "2 hours ago").
+
+Als het commando `git log` zonder tijdsaanduiding gebruikt wordt, wordt de tijd van je computer aangehouden op het moment dat het commando wordt uitgevoerd (met behoud van het relatieve verschil met UTC).
+
+Bijvoorbeeld, het uitvoeren van een `git log` commando om 09:00 op jouw computer waarbij je tijdzone op dat moment 3 uur voorloopt op UTC, maakt de uitvoer van de volgende twee commando's gelijk:
+
+    $ git log --after=2008-06-01 --before=2008-07-01
+    $ git log --after="2008-06-01T09:00:00+0300" \
+        --before="2008-07-01T09:00:00+0300"
+
+Als laatste voorbeeld, als je commits wilt zien die de testbestanden wijzigen in de Git sourcecode geschiedenis die door Junio Hamano gecommit waren met de CommitDate in de maand  oktober 2008 (relatief tot de tijdzone van New York) en die geen merges waren, kan je bijvoorbeeld het volgende commando typen:
 
-	$ git log --pretty="%h - %s" --author=gitster --since="2008-10-01" \
-	   --before="2008-11-01" --no-merges -- t/
+        $ git log --pretty="%h - %s" --author=gitster \
+           --after="2008-10-01T00:00:00-0400"         \
+          --before="2008-10-31T23:59:59-0400" --no-merges -- t/
 	5610e3b - Fix testcase failure when extended attribute
 	acd3b9e - Enhance hold_lock_file_for_{update,append}()
 	f563754 - demonstrate breakage of detached checkout wi
@@ -698,7 +742,7 @@ Bijvoorbeeld, als je wilt zien welke commits test bestanden in de Git broncode g
 	51a94af - Fix "checkout --track -b newbranch" on detac
 	b0ad11e - pull: allow "git pull origin $something:$cur
 
-Van de bijna 20.000 commits in de Git broncode historie, laat dit commando de 6 zien die bij die criteria passen.
+Van de bijna 36.000 commits in de Git broncode historie, laat dit commando de 6 zien die bij die criteria passen.
 
 ### Een grafische interface gebruiken om de historie te visualiseren ###
 
diff --git a/nl/03-git-branching/01-chapter3.markdown b/nl/03-git-branching/01-chapter3.markdown
index 9032bea63..f0439bf51 100644
--- a/nl/03-git-branching/01-chapter3.markdown
+++ b/nl/03-git-branching/01-chapter3.markdown
@@ -33,7 +33,7 @@ vertaling moeten proberen te maken.
 
 Veel succes en plezier bij het vertalen...
 -->
-<!-- SHA-1 of last checked en-version: fbf24105 -->
+<!-- SHA-1 of last checked en-version: 4cefec -->
 # Branchen in Git #
 
 Bijna elk versiebeheersysteem ondersteunt een bepaalde vorm van branchen. Branchen komt erop neer dat je een tak afsplitst van de hoofd-ontwikkellijn en daar verder mee gaat werken zonder aan de hoofdlijn te komen. Bij veel VCS'en is dat nogal een duur proces, vaak wordt er een nieuwe kopie gemaakt van de directory waar je broncode in staat, wat lang kan duren voor grote projecten.
@@ -440,7 +440,7 @@ Figuur 3-23. Lokaal werken terwijl iemand anders naar je remote server pusht laa
 Om je werk te synchroniseren, voer je een `git fetch origin` commando uit. Dit commando bekijkt welke server origin is (in dit geval is het `git.ourcompany.com`), haalt gegevens er vanaf die je nog niet hebt en vernieuwt je lokale database, waarbij je `origin/master`-verwijzing naar zijn nieuwe positie verplaatst wordt die meer up-to-date is (zie Figuur 3-24).
 
 Insert 18333fig0324.png
-Figuur 3-24. Het git fetch commando vernieuwt je remote referenties.
+Figuur 3-24. Het `git fetch` commando vernieuwt je remote referenties.
 
 Om het hebben van meerdere remote servers te tonen en hoe remote branches voor die remote projecten eruitzien, zullen we aannemen dat je nog een interne Git-server hebt die alleen wordt gebruikt voor ontwikkeling gedaan door een van je sprint teams. Deze server bevindt zich op `git.team1.ourcompany.com`. Je kunt het als een nieuwe remote referentie toevoegen aan het project waar je nu aan werkt door het `git remote add` commando uit te voeren, zoals we behandeld hebben in Hoofdstuk 2. Noem deze remote `teamone`, wat jouw afkorting voor die hele URL wordt (zie Figuur 3-25).
 
diff --git a/nl/04-git-server/01-chapter4.markdown b/nl/04-git-server/01-chapter4.markdown
index 78f101c69..4ddf3e9fc 100644
--- a/nl/04-git-server/01-chapter4.markdown
+++ b/nl/04-git-server/01-chapter4.markdown
@@ -33,7 +33,7 @@ vertaling moeten proberen te maken.
 
 Veel succes en plezier bij het vertalen...
 -->
-<!-- SHA-1 of last checked en-version: fbf24105 -->
+<!-- SHA-1 of last checked en-version: 4cefec -->
 # Git op de server #
 
 Je zou nu de alledaagse taken waarvoor je Git zult gebruiken moeten kunnen uitvoeren. Echter, om enige vorm van samenwerking te hebben in Git is een remote Git repository nodig. Technisch gezien kun je wijzigingen pushen en pullen van individuele repositories, maar dat wordt afgeraden omdat je vrij gemakkelijk het werk waar anderen mee bezig zijn in de war kunt schoppen als je niet oppast. Daarnaast wil je dat je medewerkers de repository kunnen bereiken, zelfs als jouw computer van het netwerk is; het hebben van een betrouwbare gezamenlijke repository is vaak handig. De voorkeursmethode om met iemand samen te werken is om een tussenliggende repository in te richten waar beide partijen toegang tot hebben en om daar naartoe te pushen en vandaan te pullen. We zullen deze repository de "Git server" noemen, maar je zult zien dat het over het algemeen maar weinig systeembronnen kost om een Git repository te verzorgen, dus je zult er zelden een complete server voor nodig hebben.
@@ -156,7 +156,7 @@ Om je repository te clonen met als doel het maken van een kale repository, voer
 	Cloning into bare repository 'my_project.git'...
 	done.
 
-De output van dit commando is een beetje verwarrend. Het commando `clone` is eigenlijk een `git init` en dan een `git fetch`, wat we hier zien is de output van het `git init` gedeelte wat een lege directory aanmaakt. De eigenlijke object overdracht geeft geen output, maar het gebeurt wel. Nu zou je een kopie van de Git directory data in je `my_project.git` directory moeten hebben.
+Nu zou je een kopie van de Git directory data in je `my_project.git` directory moeten hebben.
 
 Dit is grofweg gelijk aan dit
 
diff --git a/nl/05-distributed-git/01-chapter5.markdown b/nl/05-distributed-git/01-chapter5.markdown
index 9baad756a..231734e24 100644
--- a/nl/05-distributed-git/01-chapter5.markdown
+++ b/nl/05-distributed-git/01-chapter5.markdown
@@ -33,7 +33,7 @@ vertaling moeten proberen te maken.
 
 Veel succes en plezier bij het vertalen...
 -->
-<!-- SHA-1 of last checked en-version: fbf24105 -->
+<!-- SHA-1 of last checked en-version: 4cefec -->
 # Gedistribueerd Git #
 
 Nu je een remote Git repository hebt ingesteld als een plaats waar alle ontwikkelaars hun code kunnen delen, en je bekend bent met fundamentele Git commando's in een lokale workflow, zul je hier zien hoe je een paar gedistribueerde workflows kunt gebruiken die je met Git kunt bereiken.
@@ -650,7 +650,7 @@ Als je de patch ontvangen hebt van iemand die het gegenereerd heeft met de `git
 
 Dit wijzigt de bestanden in je werk directory. Het is vrijwel gelijk aan het uitvoeren van een `patch -p1` commando om de patch toe te passen, alhoewel het meer paranoïde is en minder "fuzzy matches" accepteert dan patch. Het handelt ook het toevoegen, verwijderen, en hernoemen van bestanden af als ze beschreven staan in het `git diff` formaat, wat `patch` niet doet. Als laatste volgt `git apply` een "pas alles toe of laat alles weg" model waarbij alles of niets wordt toegepast. Dit in tegenstelling tot `patch` die gedeeltelijke patches kan toepassen, waardoor je werkdirectory in een vreemde status achterblijft. Over het algemeen is `git apply` meer paranoïde dan `patch`. Het zal geen commit voor je aanmaken: na het uitvoeren moet je de geïntroduceerde wijzigingen handmatig stagen en committen.
 
-Je kunt ook git apply gebruiken om te zien of een patch netjes kan worden toepast voordat je het echt doet; je kunt `git apply --check` uitvoeren met de patch:
+Je kunt ook `git apply` gebruiken om te zien of een patch netjes kan worden toepast voordat je het echt doet; je kunt `git apply --check` uitvoeren met de patch:
 
 	$ git apply --check 0001-seeing-if-this-helps-the-gem.patch
 	error: patch failed: ticgit.gemspec:1
@@ -671,7 +671,7 @@ Om een patch gegenereerd met `format-patch` toe te passen, gebruik je `git am`.
 
 	Limit log functionality to the first 20
 
-Dit is het begin van de uitvoer van het format-patch commando dat je gezien hebt in de vorige paragraaf. Dit is ook een geldig mbox e-mail formaat. Als iemand jou de patch correct gemaild heeft door gebruik te maken van git send-email en je downloadt dat in een mbox formaat, dan kan je het git am naar dat mbox bestand verwijzen, en het zal beginnen met alle patches die het tegenkomt toe te passen. Als je een mail client gebruikt die meerdere e-mails kan opslaan in mbox formaat, dan kun je hele reeksen patches in een bestand opslaan en dan git am gebruiken om ze één voor één toe te passen.
+Dit is het begin van de uitvoer van het format-patch commando dat je gezien hebt in de vorige paragraaf. Dit is ook een geldig mbox e-mail formaat. Als iemand jou de patch correct gemaild heeft door gebruik te maken van `git send-email` en je downloadt dat in een mbox formaat, dan kan je het `git am` naar dat mbox bestand verwijzen, en het zal beginnen met alle patches die het tegenkomt toe te passen. Als je een mail client gebruikt die meerdere e-mails kan opslaan in mbox formaat, dan kun je hele reeksen patches in een bestand opslaan en dan `git am` gebruiken om ze één voor één toe te passen.
 
 Maar, als iemand een patch bestand heeft geüpload die gegenereerd is met `format-patch` naar een ticket systeem of zoiets, kun je het bestand lokaal opslaan en dan dat opgeslagen bestand aan `git am` doorgeven om het te applyen:
 
diff --git a/nl/06-git-tools/01-chapter6.markdown b/nl/06-git-tools/01-chapter6.markdown
index 6ff291d40..d4cc79d8f 100644
--- a/nl/06-git-tools/01-chapter6.markdown
+++ b/nl/06-git-tools/01-chapter6.markdown
@@ -33,7 +33,7 @@ vertaling moeten proberen te maken.
 
 Veel succes en plezier bij het vertalen...
 -->
-<!-- SHA-1 of last checked en-version: 7f80ea23  -->
+<!-- SHA-1 of last checked en-version: 4cefec  -->
 # Git tools #
 
 Nu heb je de meeste commando's en werkwijzen geleerd die je dagelijks nodig hebt om een Git repository voor je broncode te beheren en te onderhouden. Je hebt de basistaken van het tracken en committen van bestanden onder de knie, en je hebt de kracht van de staging area en lichtgewicht topic branching en mergen in de vingers.
@@ -518,8 +518,8 @@ De apply optie probeert alleen het gestashete werk toe te passen - je blijft op
 
 	$ git stash list
 	stash@{0}: WIP on master: 049d078 added the index file
-	stash@{1}: WIP on master: c264051... Revert "added file_size"
-	stash@{2}: WIP on master: 21d80a5... added number to log
+	stash@{1}: WIP on master: c264051 Revert "added file_size"
+	stash@{2}: WIP on master: 21d80a5 added number to log
 	$ git stash drop stash@{0}
 	Dropped stash@{0} (364e91f3f268f0900bc3ee613f9f733e82aaed43)
 
diff --git a/nl/07-customizing-git/01-chapter7.markdown b/nl/07-customizing-git/01-chapter7.markdown
index 03feaf471..b1bb95223 100644
--- a/nl/07-customizing-git/01-chapter7.markdown
+++ b/nl/07-customizing-git/01-chapter7.markdown
@@ -33,7 +33,7 @@ vertaling moeten proberen te maken.
 
 Veel succes en plezier bij het vertalen...
 -->
-<!-- SHA-1 of last checked en-version: fbf24105 -->
+<!-- SHA-1 of last checked en-version: 4cefec -->
 # Git op maat maken #
 
 Tot zover heb ik de fundamentele werking van Git behandeld en hoe het te gebruiken, en ik heb een aantal tools geïntroduceerd die Git tot je beschikking stelt om je het makkelijk en efficiënt te laten gebruiken. In dit hoofdstuk zal ik wat operaties doorlopen die je kunt gebruiken om Git op een maat gemaakte manier te laten werken middels het introduceren van een aantal belangrijke configuratie-instellingen en het inhaak-systeem (hooks). Met deze tools is het makkelijk om Git precies te laten werken op de manier zoals jij, je bedrijf, of je groep het nodig hebben.
@@ -548,7 +548,7 @@ Bijvoorbeeld, stel dat je wat testbestanden in een `test/` subdirectory hebt, en
 
 	test/ export-ignore
 
-Als je nu git archive uitvoert om een tarball van je project te maken, zal die map niet meegenomen worden in het archief.
+Als je nu `git archive` uitvoert om een tarball van je project te maken, zal die map niet meegenomen worden in het archief.
 
 #### export-subst ####
 
@@ -650,14 +650,12 @@ Al het werk aan de server kant zal in het update bestand in je hooks directory g
 
 	#!/usr/bin/env ruby
 
-	$refname = ARGV[0]
-	$oldrev  = ARGV[1]
-	$newrev  = ARGV[2]
-	$user    = ENV['USER']
-
-	puts "Enforcing Policies... \n(#{$refname}) (#{$oldrev[0,6]}) (#{$newrev[0,6]})"
+	refname = ARGV[0]
+	oldrev  = ARGV[1]
+	newrev  = ARGV[2]
+	user    = ENV['USER']
 
-Ja, ik gebruik globale variabelen. Schiet me niet af – het is makkelijker om het op deze manier te laten zien.
+	puts "Enforcing Policies... \n(#{refname}) (#{oldrev[0,6]}) (#{newrev[0,6]})"
 
 #### Een specifiek commit-bericht formaat afdwingen ####
 
diff --git a/nl/08-git-and-other-scms/01-chapter8.markdown b/nl/08-git-and-other-scms/01-chapter8.markdown
index 32e0b9ccd..8a17493e8 100644
--- a/nl/08-git-and-other-scms/01-chapter8.markdown
+++ b/nl/08-git-and-other-scms/01-chapter8.markdown
@@ -33,7 +33,7 @@ vertaling moeten proberen te maken.
 
 Veel succes en plezier bij het vertalen...
 -->
-<!-- SHA-1 of last checked en-version: fbf24105 -->
+<!-- SHA-1 of last checked en-version: 4cefec -->
 # Git en andere systemen #
 
 Het is geen perfecte wereld. Meestal kan je niet meteen elk project waar je mee in aanraking komt omzetten naar Git. Soms zit je vast op een project dat een ander VCS gebruikt, en vaak is dat systeem Subversion. In het eerste gedeelte van dit hoofdstuk zal je leren over `git svn`, het bidirectionele Subversion uitwissel tool van Git.
@@ -238,7 +238,7 @@ Regelmatig `git svn rebase` uitvoeren zorgt er voor dat je code altijd up to dat
 
 ### Git branch problemen ###
 
-Als je gewend geraakt bent aan een Git workflow, zal je waarschijnlijk topic branches gaan maken, er werk op doen en ze dan terug mergen. Als je naar een Subversion server pusht via git svn, zou je kunnen overwegen je werk iedere keer op een enkele branch rebasen in plaats van de branches samen te mergen. De reden om rebasen te prefereren is dat Subversion een lineaire geschiedenis heeft, en niet met merges omgaat op de manier zoals Git dat doet, dus git svn volgt alleen de eerste ouder op het moment dat de snapshots naar Subversion commits omgezet worden.
+Als je gewend geraakt bent aan een Git workflow, zal je waarschijnlijk topic branches gaan maken, er werk op doen en ze dan terug mergen. Als je naar een Subversion server pusht via `git svn`, zou je kunnen overwegen je werk iedere keer op een enkele branch rebasen in plaats van de branches samen te mergen. De reden om rebasen te prefereren is dat Subversion een lineaire geschiedenis heeft, en niet met merges omgaat op de manier zoals Git dat doet, dus `git svn` volgt alleen de eerste ouder op het moment dat de snapshots naar Subversion commits omgezet worden.
 
 Stel dat je geschiedenis er zoals volgt uitziet: je hebt een `experiment` branch gemaakt, twee commits gedaan en ze dan terug in `master` gemerged. Als je dan `dcommit` zie je output zoals dit:
 
@@ -267,7 +267,7 @@ Als iemand anders dat werk cloned, is alles wat ze zien de merge commit met al h
 
 ### Subversion branchen ###
 
-Branchen in Subversion is niet hetzelfde als branchen in Git; het is waarschijnlijk het beste om het zoveel mogelijk te vermijden. Maar, je kunt Subversion branches maken en daarnaar committen met git svn.
+Branchen in Subversion is niet hetzelfde als branchen in Git; het is waarschijnlijk het beste om het zoveel mogelijk te vermijden. Maar, je kunt Subversion branches maken en daarnaar committen met `git svn`.
 
 #### Een nieuwe SVN branch maken ####
 
@@ -535,7 +535,7 @@ Voor een korte demonstratie ga je een eenvoudige importeerder schrijven. Stel da
 
 Om naar een Git directory te importeren, moet je nalezen hoe Git zijn data opslaat. Je kunt je misschien herinneren dat Git eigenlijk een gelinkte lijst is met commit objecten die naar een snapshot van de inhoud wijzen. Het enige dat je hoeft te doen, is `fast-import` vertellen wat de inhoud snapshots zijn, welke commit data er naar wijst en de volgorde waarin ze moeten staan. Je strategie zal bestaan uit het doorlopen van de snapshots en commits te creëren met de inhoud van iedere directory, waarbij je iedere commit terug linkt met de vorige.
 
-Zoals je dat ook gedaan hebt in de "Een Voorbeeld van Git-Afgedwongen Beleid" paragraaf van Hoofdstuk 7 gaan we dit in Ruby schrijven, omdat ik daar over normaalgesproken mee werk en het relatief eenvoudig is te lezen. Je kunt dit voorbeeld vrij eenvoudig schrijven in hetgeen waar je bekend mee bent, het hoeft alleen de juiste informatie naar stdout te schrijven. En dat betekent dat als je op Windows werkt je erg voorzichtig moet zijn om geen carriage returns te introduceren aan het einde van je regels. Want git fast-import is erg kieskeurig wat dat betreft: hij wil slechts line feeds (LF) hebben en niet de cariage return line feeds (CRLF) die Windows gebruikt.
+Zoals je dat ook gedaan hebt in de "Een Voorbeeld van Git-Afgedwongen Beleid" paragraaf van Hoofdstuk 7 gaan we dit in Ruby schrijven, omdat ik daar over normaalgesproken mee werk en het relatief eenvoudig is te lezen. Je kunt dit voorbeeld vrij eenvoudig schrijven in hetgeen waar je bekend mee bent, het hoeft alleen de juiste informatie naar stdout te schrijven. En dat betekent dat als je op Windows werkt je erg voorzichtig moet zijn om geen carriage returns te introduceren aan het einde van je regels. Want `git fast-import` is erg kieskeurig wat dat betreft: hij wil slechts line feeds (LF) hebben en niet de carriage return line feeds (CRLF) die Windows gebruikt.
 
 Om te beginnen ga je naar de doeldirectory en identificeert iedere subdirectory, waarvan elk een snapshot is dat je als commit wil importeren. Dan ga je in iedere subdirectory en print de noodzakelijke commando's om ze te exporteren. Je basis hoofdlus ziet er zo uit:
 
@@ -637,7 +637,7 @@ Het laatste wat je moet doen is het huidige kenmerk teruggeven, zodat het meegeg
 
 	return mark
 
-LET OP: Als je op Windows werkt moet je er zeker van zijn dat je nog één extra stap toevoegt. Zoals eerder gemeld is, gebruikt Windows CRLF als new line karakters, terwijl git fast-import alleen LF verwacht. Om dit probleem te omzeilen en git fast-import blij te maken, moet je ruby vertellen om LF in plaats van CRLF te gebruiken:
+LET OP: Als je op Windows werkt moet je er zeker van zijn dat je nog één extra stap toevoegt. Zoals eerder gemeld is, gebruikt Windows CRLF als new line karakters, terwijl git fast-import alleen LF verwacht. Om dit probleem te omzeilen en `git fast-import` blij te maken, moet je ruby vertellen om LF in plaats van CRLF te gebruiken:
 
 	$stdout.binmode
 
diff --git a/nl/09-git-internals/01-chapter9.markdown b/nl/09-git-internals/01-chapter9.markdown
index 51c798a3f..ac6228145 100644
--- a/nl/09-git-internals/01-chapter9.markdown
+++ b/nl/09-git-internals/01-chapter9.markdown
@@ -33,7 +33,7 @@ vertaling moeten proberen te maken.
 
 Veel succes en plezier bij het vertalen...
 -->
-<!-- SHA-1 of last checked en-version: fbf24105 -->
+<!-- SHA-1 of last checked en-version: 4cefec -->
 # Het binnenwerk van Git #
 
 Je zult misschien naar dit hoofdstuk gesprongen zijn vanuit een voorafgaand hoofdstuk, of je zult hier gekomen zijn nadat je de rest van het boek gelezen hebt; hoe dan ook, hier is waar het binnenwerk en implementatie van Git behandeld gaat worden. Ik heb gemerkt dat het leren van deze informatie van fundamenteel belang is om te begrijpen hoe bruikbaar en krachtig Git is, maar anderen hebben daar tegenin gebracht dat het erg verwarrend en onnodig complex kan zijn voor beginners. Daarom heb ik de behandeling hiervan het laatste hoofdstuk gemaakt in het boek, zodat je kunt besluiten om het het vroeg of later in je leerproces kunt lezen. Ik laat het aan jou over om dat te beslissen.
@@ -63,7 +63,7 @@ Als je `git init` uitvoert in een nieuwe of bestaande directory, zal Git de dire
 	objects/
 	refs/
 
-Je zou hier een paar andere bestanden kunnen zien, maar dit is een verse `git init` repository - dit is wat je standaard ziet. De `branches` directory wordt niet gebruikt door nieuwere Git versies, en het `description` bestand wordt alleen gebruikt door het programma GitWeb, dus je hoeft je daar geen zorgen over te maken. Het bestand `config` bevat je project-specifieke configuratieopties, en de `info` directory bevat een bestand met bestandsnaampatronen die je niet wilt volgen, maar die je niet wilt opnemen in een .gitignore bestand. De directory `hooks` bevat scripts die aan bepaalde acties zijn “gehaakt” aan client- en serverkant, deze zijn in detail behandeld in Hoofdstuk 7.
+Je zou hier een paar andere bestanden kunnen zien, maar dit is een verse `git init` repository - dit is wat je standaard ziet. De `branches` directory wordt niet gebruikt door nieuwere Git versies, en het `description` bestand wordt alleen gebruikt door het programma GitWeb, dus je hoeft je daar geen zorgen over te maken. Het bestand `config` bevat je project-specifieke configuratieopties, en de `info` directory bevat een bestand met bestandsnaampatronen die je niet wilt volgen, maar die je niet wilt opnemen in een `.gitignore` bestand. De directory `hooks` bevat scripts die aan bepaalde acties zijn “gehaakt” aan client- en serverkant, deze zijn in detail behandeld in Hoofdstuk 7.
 
 Dit laat vier belangrijke vermeldingen over: de bestanden `HEAD` en `index`, en de directories `objects` en `refs`. Dit zijn de kernbestanddelen van Git. De directory `objects` bevat alle inhoud van je databank, de directory `refs` bevat verwijzingen naar commitobjecten (branches) in die databank, het bestand `HEAD` wijst naar de branch die je op dit moment uitgecheckt hebt, en het bestand `index` is waar Git de informatie van je staging area (wachtrij) opslaat. We gaan nu gedetaileerd naar elk van deze onderdelen kijken om te laten zien hoe Git werkt.
 

From 971cf63ed1553970685939997dd2201e6e55511e Mon Sep 17 00:00:00 2001
From: Kangyi Zhu <zhukangyi@gmail.com>
Date: Tue, 8 Jul 2014 20:55:54 +0800
Subject: [PATCH 493/690] [zh] Fix a missing word in 01-chapter6

"All the changes from your Rack project are merged in and ready to be committed locally."
The word "and" is missed in the translation.
---
 zh/06-git-tools/01-chapter6.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/zh/06-git-tools/01-chapter6.markdown b/zh/06-git-tools/01-chapter6.markdown
index 948b1ff1d..b0929d272 100644
--- a/zh/06-git-tools/01-chapter6.markdown
+++ b/zh/06-git-tools/01-chapter6.markdown
@@ -1110,7 +1110,7 @@ Git 通过子模块处理这个问题。子模块允许你将一个 Git 仓库
 	Squash commit -- not updating HEAD
 	Automatic merge went well; stopped before committing as requested
 
-所有 Rack 项目的变更都被归并可以进行本地提交。你也可以做相反的事情——在你主分支的`rack`目录里进行变更然后归并回`rack_branch`分支，然后将它们提交给维护者或者推送到上游。
+所有 Rack 项目的变更都被归并并且可以进行本地提交。你也可以做相反的事情——在你主分支的`rack`目录里进行变更然后归并回`rack_branch`分支，然后将它们提交给维护者或者推送到上游。
 
 为了得到`rack`子目录和你`rack_branch`分支的区别——以决定你是否需要归并它们——你不能使用一般的`diff`命令。而是对你想比较的分支运行`git diff-tree`：
 

From d481a879e337300ec08786faf4d9c974fb25597d Mon Sep 17 00:00:00 2001
From: Soon Van <cog@randomecho.com>
Date: Wed, 9 Jul 2014 20:45:54 -0400
Subject: [PATCH 494/690] Add -L flag to cURL command to follow any redirects

cURL by default will not follow redirects, leading
to blank file unless the `-L` flag is included since
all resources once hosted on raw.github.com are now
on the raw.githubusercontent.com domain.

Fixes issue mentioned at https://github.com/git/git-scm.com/issues/422
---
 cs/09-git-internals/01-chapter9.markdown    | 2 +-
 de/09-git-internals/01-chapter9.markdown    | 2 +-
 en/09-git-internals/01-chapter9.markdown    | 2 +-
 fr/09-git-internals/01-chapter9.markdown    | 2 +-
 ja/09-git-internals/01-chapter9.markdown    | 2 +-
 ko/09-git-internals/01-chapter9.markdown    | 2 +-
 pl/09-git-internals/01-chapter9.markdown    | 2 +-
 ru/09-git-internals/01-chapter9.markdown    | 2 +-
 zh-tw/09-git-internals/01-chapter9.markdown | 2 +-
 9 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/cs/09-git-internals/01-chapter9.markdown b/cs/09-git-internals/01-chapter9.markdown
index 81708d2b4..83c7505fd 100644
--- a/cs/09-git-internals/01-chapter9.markdown
+++ b/cs/09-git-internals/01-chapter9.markdown
@@ -433,7 +433,7 @@ Vraťme se zpět do databáze objektů vašeho testovacího repozitáře Git. V
 
 Git komprimuje obsah těchto souborů metodou zlib a uložená data tak nejsou příliš velká. Všechny tyto soubory zabírají dohromady pouhých 925 bytů. Do repozitáře tak nyní přidáme větší objem dat, na němž si budeme moci ukázat jednu zajímavou funkci systému Git. Z knihovny Grit, s níž jsme pracovali před časem, přidejte soubor „repo.rb“. Je to soubor se zdrojovým kódem o velikosti asi 12 kB:
 
-	$ curl https://raw.github.com/mojombo/grit/master/lib/grit/repo.rb > repo.rb
+	$ curl -L https://raw.github.com/mojombo/grit/master/lib/grit/repo.rb > repo.rb
 	$ git add repo.rb
 	$ git commit -m 'added repo.rb'
 	[master 484a592] added repo.rb
diff --git a/de/09-git-internals/01-chapter9.markdown b/de/09-git-internals/01-chapter9.markdown
index 6f92c1d00..947c36bc9 100644
--- a/de/09-git-internals/01-chapter9.markdown
+++ b/de/09-git-internals/01-chapter9.markdown
@@ -596,7 +596,7 @@ Kommen wir noch einmal auf die Objekt-Datenbank zurück, die Du für Dein Test-R
 
 Git komprimiert die Inhalte dieser Dateien mit zlib und Du hast nicht sonderlich viele davon, sodass die Gesamtgröße der Dateien gerade mal 925 Bytes beträgt. Wir wollen ein anderes interessantes Feature von Git demonstrieren, und dazu müssen wir eine größere Datei hinzufügen, z.B. die `repo.rb` Datei aus der Grit-Bibliothek, die Du schon verwendet hast. Diese Datei ist eine etwa 12K große Quelltext-Datei:
 
-	$ curl https://raw.github.com/mojombo/grit/master/lib/grit/repo.rb > repo.rb
+	$ curl -L https://raw.github.com/mojombo/grit/master/lib/grit/repo.rb > repo.rb
 	$ git add repo.rb
 	$ git commit -m 'added repo.rb'
 	[master 484a592] added repo.rb
diff --git a/en/09-git-internals/01-chapter9.markdown b/en/09-git-internals/01-chapter9.markdown
index b638c04b7..354a44f16 100644
--- a/en/09-git-internals/01-chapter9.markdown
+++ b/en/09-git-internals/01-chapter9.markdown
@@ -433,7 +433,7 @@ Let’s go back to the objects database for your test Git repository. At this po
 
 Git compresses the contents of these files with zlib, and you’re not storing much, so all these files collectively take up only 925 bytes. You’ll add some larger content to the repository to demonstrate an interesting feature of Git. Add the repo.rb file from the Grit library you worked with earlier — this is about a 12K source code file:
 
-	$ curl https://raw.github.com/mojombo/grit/master/lib/grit/repo.rb > repo.rb
+	$ curl -L https://raw.github.com/mojombo/grit/master/lib/grit/repo.rb > repo.rb
 	$ git add repo.rb
 	$ git commit -m 'added repo.rb'
 	[master 484a592] added repo.rb
diff --git a/fr/09-git-internals/01-chapter9.markdown b/fr/09-git-internals/01-chapter9.markdown
index ccf9eb886..9e881901d 100644
--- a/fr/09-git-internals/01-chapter9.markdown
+++ b/fr/09-git-internals/01-chapter9.markdown
@@ -544,7 +544,7 @@ Ajoutons de plus gros contenu au dépôt pour montrer une fonctionnalité intér
 Ajoutez le fichier `repo.rb` de la bibliothèque Grit que vous avez manipulé plus tôt.
 Il représente environ 12 Kio de code source :
 
-	$ curl https://raw.github.com/mojombo/grit/master/lib/grit/repo.rb > repo.rb
+	$ curl -L https://raw.github.com/mojombo/grit/master/lib/grit/repo.rb > repo.rb
 	$ git add repo.rb
 	$ git commit -m 'added repo.rb'
 	[master 484a592] added repo.rb
diff --git a/ja/09-git-internals/01-chapter9.markdown b/ja/09-git-internals/01-chapter9.markdown
index b3834a73a..133f5eaed 100644
--- a/ja/09-git-internals/01-chapter9.markdown
+++ b/ja/09-git-internals/01-chapter9.markdown
@@ -439,7 +439,7 @@ Git レポジトリ test のオブジェクトデータベースに戻りまし
 
 Git は zlib を使用してこれらのファイルのコンテンツを圧縮するため、多くを格納していません。これらすべてのファイルを集めても 925バイトにしかならないのです。Git の興味深い機能を実際に見るために、幾つか大きなコンテンツをレポジトリに追加してみましょう。前に作業したGritライブラリから `repo.rb` ファイルを追加します。これは約 12Kバイトのソースコードファイルです。
 
-	$ curl https://raw.github.com/mojombo/grit/master/lib/grit/repo.rb > repo.rb
+	$ curl -L https://raw.github.com/mojombo/grit/master/lib/grit/repo.rb > repo.rb
 	$ git add repo.rb
 	$ git commit -m 'added repo.rb'
 	[master 484a592] added repo.rb
diff --git a/ko/09-git-internals/01-chapter9.markdown b/ko/09-git-internals/01-chapter9.markdown
index a30e480e8..51acb5422 100644
--- a/ko/09-git-internals/01-chapter9.markdown
+++ b/ko/09-git-internals/01-chapter9.markdown
@@ -432,7 +432,7 @@ Linux Kernel 저장소에도 커밋이 아닌 다른 개체를 가리키는 태
 
 Git은 zlib으로 파일 내용을 압축하기 때문에 저장 공간이 많이 필요하지 않다. 그래서 이 데이터베이스에 저장된 파일은 겨우 925바이트밖에 되지 않는다. 크기가 큰 파일을 추가해서 이 기능의 효과를 좀 더 살펴보자. 앞 장에서 사용했던 Grit 라이브러리에 들어 있는 repo.rb 파일을 추가한다. 이 파일의 크기는 약 12K이다.
 
-	$ curl https://raw.github.com/mojombo/grit/master/lib/grit/repo.rb > repo.rb
+	$ curl -L https://raw.github.com/mojombo/grit/master/lib/grit/repo.rb > repo.rb
 	$ git add repo.rb
 	$ git commit -m 'added repo.rb'
 	[master 484a592] added repo.rb
diff --git a/pl/09-git-internals/01-chapter9.markdown b/pl/09-git-internals/01-chapter9.markdown
index 3bdd05268..9dafcad67 100644
--- a/pl/09-git-internals/01-chapter9.markdown
+++ b/pl/09-git-internals/01-chapter9.markdown
@@ -612,7 +612,7 @@ Git kompresuje zawartość tych plików za pomocą biblioteki zlib, a Ty nie mas
 
 <!-- Git compresses the contents of these files with zlib, and you’re not storing much, so all these files collectively take up only 925 bytes. You’ll add some larger content to the repository to demonstrate an interesting feature of Git. Add the repo.rb file from the Grit library you worked with earlier — this is about a 12K source code file: -->
 
-    $ curl https://raw.github.com/mojombo/grit/master/lib/grit/repo.rb > repo.rb
+    $ curl -L https://raw.github.com/mojombo/grit/master/lib/grit/repo.rb > repo.rb
     $ git add repo.rb
     $ git commit -m 'added repo.rb'
     [master 484a592] added repo.rb
diff --git a/ru/09-git-internals/01-chapter9.markdown b/ru/09-git-internals/01-chapter9.markdown
index 7fed573a4..7ec5b914b 100644
--- a/ru/09-git-internals/01-chapter9.markdown
+++ b/ru/09-git-internals/01-chapter9.markdown
@@ -433,7 +433,7 @@ Insert 18333fig0904.png
 
 Git сжал содержимое этих файлов при помощи zlib, к тому же мы не записывали много данных, поэтому все эти файлы вместе занимают всего 925 байт. Для того чтобы продемонстрировать одну интересную возможность Git'а, добавим файл побольше. Добавим файл repo.rb из библиотеки Grit, с которой мы работали ранее, он занимает примерно 12 Кбайт:
 
-	$ curl https://raw.github.com/mojombo/grit/master/lib/grit/repo.rb > repo.rb
+	$ curl -L https://raw.github.com/mojombo/grit/master/lib/grit/repo.rb > repo.rb
 	$ git add repo.rb 
 	$ git commit -m 'added repo.rb'
 	[master 484a592] added repo.rb
diff --git a/zh-tw/09-git-internals/01-chapter9.markdown b/zh-tw/09-git-internals/01-chapter9.markdown
index 864290411..d7fadb1b1 100644
--- a/zh-tw/09-git-internals/01-chapter9.markdown
+++ b/zh-tw/09-git-internals/01-chapter9.markdown
@@ -433,7 +433,7 @@ Remote references 和分支(`refs/heads` references)的主要區別在於他們
 
 Git 用 zlib 壓縮檔案內容，因此這些檔並沒有佔用太多空間，所有檔加起來總共僅用了 925 位元組。接下去你將添加一些大檔以演示 Git 的一個很有意思的功能。將你之前用到過的 Grit 庫中的 repo.rb 檔加進去 ── 這個原始程式碼檔大小約為 12K： 
 
-	$ curl https://raw.github.com/mojombo/grit/master/lib/grit/repo.rb > repo.rb
+	$ curl -L https://raw.github.com/mojombo/grit/master/lib/grit/repo.rb > repo.rb
 	$ git add repo.rb
 	$ git commit -m 'added repo.rb'
 	[master 484a592] added repo.rb

From ceea34fc6c3fc44fceb1ba31de8f8020938af95e Mon Sep 17 00:00:00 2001
From: Yu Takasuka <github@takasuka.net>
Date: Thu, 10 Jul 2014 22:22:43 +0800
Subject: [PATCH 495/690] [JP]Fix typo in chapter2
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Change to "時点" from "地点"
---
 ja/02-git-basics/01-chapter2.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ja/02-git-basics/01-chapter2.markdown b/ja/02-git-basics/01-chapter2.markdown
index 775f52e51..3d08a1a11 100755
--- a/ja/02-git-basics/01-chapter2.markdown
+++ b/ja/02-git-basics/01-chapter2.markdown
@@ -879,7 +879,7 @@ Paul の master ブランチは、ローカルでは `pb/master` としてアク
 
 ### リモートへのプッシュ ###
 
-あなたのプロジェクトがみんなと共有できる状態に達したら、それを上流にプッシュしなければなりません。そのためのコマンドが `git push [remote-name] [branch-name]` です。master ブランチの内容を `origin` サーバー (何度も言いますが、クローンした地点でこのブランチ名とサーバー名が自動設定されます) にプッシュしたい場合は、このように実行します。
+あなたのプロジェクトがみんなと共有できる状態に達したら、それを上流にプッシュしなければなりません。そのためのコマンドが `git push [remote-name] [branch-name]` です。master ブランチの内容を `origin` サーバー (何度も言いますが、クローンした時点でこのブランチ名とサーバー名が自動設定されます) にプッシュしたい場合は、このように実行します。
 
 	$ git push origin master
 

From 62e3eacaf7f2e442deb2166e23c15ec44b71086c Mon Sep 17 00:00:00 2001
From: Alec Clews <alecclews@gmail.com>
Date: Thu, 16 Jan 2014 19:05:07 +1100
Subject: [PATCH 496/690] Added some brief details on BFG
 http://rtyley.github.io/bfg-repo-cleaner/

---
 en/06-git-tools/01-chapter6.markdown | 21 +++++++++++++++++++--
 1 file changed, 19 insertions(+), 2 deletions(-)

diff --git a/en/06-git-tools/01-chapter6.markdown b/en/06-git-tools/01-chapter6.markdown
index 3eef10757..099b47ea4 100644
--- a/en/06-git-tools/01-chapter6.markdown
+++ b/en/06-git-tools/01-chapter6.markdown
@@ -1,4 +1,4 @@
-# Git Tools #
+ Git Tools #
 
 By now, you’ve learned most of the day-to-day commands and workflows that you need to manage or maintain a Git repository for your source code control. You’ve accomplished the basic tasks of tracking and committing files, and you’ve harnessed the power of the staging area and lightweight topic branching and merging.
 
@@ -690,7 +690,9 @@ Once again, this changes the SHAs of all the commits in your list, so make sure
 
 ### The Nuclear Option: filter-branch ###
 
-There is another history-rewriting option that you can use if you need to rewrite a larger number of commits in some scriptable way — for instance, changing your e-mail address globally or removing a file from every commit. The command is `filter-branch`, and it can rewrite huge swaths of your history, so you probably shouldn’t use it unless your project isn’t yet public and other people haven’t based work off the commits you’re about to rewrite. However, it can be very useful. You’ll learn a few of the common uses so you can get an idea of some of the things it’s capable of.
+There is another history-rewriting option that you can use if you need to rewrite a larger number of commits in some scriptable way — for instance, changing your e-mail address globally or removing a file from every commit.
+The command is `filter-branch`, and it can rewrite huge swaths of your history, so you probably shouldn’t use it unless your project isn’t yet public and other people haven’t based work off the commits you’re about to rewrite.
+However, it can be very useful. You’ll learn a few of the common uses so you can get an idea of some of the things it’s capable of.
 
 #### Removing a File from Every Commit ####
 
@@ -730,6 +732,21 @@ Another common case is that you forgot to run `git config` to set your name and
 
 This goes through and rewrites every commit to have your new address. Because commits contain the SHA-1 values of their parents, this command changes every commit SHA in your history, not just those that have the matching e-mail address.
 
+### The Very Fast Nuclear Option: Big Friendly Giant Repo Cleaner###
+
+[Roberto Tyley](https://github.com/rtyley) has written a similar
+tool to filter-branch call the BFG. It is more limited in what is can do,
+but it does it _very_ fast.
+On a large repository this can make a big difference.
+
+See the [BFG](http://rtyley.github.io/bfg-repo-cleaner/) website for details.
+
+Tip: BFG is a standalone Java program. However if you create the following alias in your `~/.gitconfig` file you can use `git bfg ...`
+
+        bfg = !java -jar ~/bin/bfg.jar
+
+(Assuming that you have copied the bfg-x.x.x.jar file to ~/bin/bfg.jar)
+
 ## Debugging with Git ##
 
 Git also provides a couple of tools to help you debug issues in your projects. Because Git is designed to work with nearly any type of project, these tools are pretty generic, but they can often help you hunt for a bug or culprit when things go wrong.

From 4028d5a9568aea30599d8f0f8f4d29d23b4d44c2 Mon Sep 17 00:00:00 2001
From: Alec Clews <alecclews@gmail.com>
Date: Mon, 14 Jul 2014 21:07:14 +1000
Subject: [PATCH 497/690] Added reference to BFG

---
 en/06-git-tools/01-chapter6.markdown | 19 ++++---------------
 1 file changed, 4 insertions(+), 15 deletions(-)

diff --git a/en/06-git-tools/01-chapter6.markdown b/en/06-git-tools/01-chapter6.markdown
index 099b47ea4..762e1aab6 100644
--- a/en/06-git-tools/01-chapter6.markdown
+++ b/en/06-git-tools/01-chapter6.markdown
@@ -1,4 +1,4 @@
- Git Tools #
+# Git Tools #
 
 By now, you’ve learned most of the day-to-day commands and workflows that you need to manage or maintain a Git repository for your source code control. You’ve accomplished the basic tasks of tracking and committing files, and you’ve harnessed the power of the staging area and lightweight topic branching and merging.
 
@@ -690,9 +690,7 @@ Once again, this changes the SHAs of all the commits in your list, so make sure
 
 ### The Nuclear Option: filter-branch ###
 
-There is another history-rewriting option that you can use if you need to rewrite a larger number of commits in some scriptable way — for instance, changing your e-mail address globally or removing a file from every commit.
-The command is `filter-branch`, and it can rewrite huge swaths of your history, so you probably shouldn’t use it unless your project isn’t yet public and other people haven’t based work off the commits you’re about to rewrite.
-However, it can be very useful. You’ll learn a few of the common uses so you can get an idea of some of the things it’s capable of.
+There is another history-rewriting option that you can use if you need to rewrite a larger number of commits in some scriptable way — for instance, changing your e-mail address globally or removing a file from every commit.  The command is `filter-branch`, and it can rewrite huge swaths of your history, so you probably shouldn’t use it unless your project isn’t yet public and other people haven’t based work off the commits you’re about to rewrite.  However, it can be very useful. You’ll learn a few of the common uses so you can get an idea of some of the things it’s capable of.
 
 #### Removing a File from Every Commit ####
 
@@ -732,21 +730,12 @@ Another common case is that you forgot to run `git config` to set your name and
 
 This goes through and rewrites every commit to have your new address. Because commits contain the SHA-1 values of their parents, this command changes every commit SHA in your history, not just those that have the matching e-mail address.
 
-### The Very Fast Nuclear Option: Big Friendly Giant Repo Cleaner###
+### The Very Fast Nuclear Option: Big Friendly Giant Repo Cleaner ###
 
-[Roberto Tyley](https://github.com/rtyley) has written a similar
-tool to filter-branch call the BFG. It is more limited in what is can do,
-but it does it _very_ fast.
-On a large repository this can make a big difference.
+[Roberto Tyley](https://github.com/rtyley) has written a similar tool to filter-branch called the BFG. It is more limited in what is can do, but it is _very_ fast and on a large repository this can make a big difference.
 
 See the [BFG](http://rtyley.github.io/bfg-repo-cleaner/) website for details.
 
-Tip: BFG is a standalone Java program. However if you create the following alias in your `~/.gitconfig` file you can use `git bfg ...`
-
-        bfg = !java -jar ~/bin/bfg.jar
-
-(Assuming that you have copied the bfg-x.x.x.jar file to ~/bin/bfg.jar)
-
 ## Debugging with Git ##
 
 Git also provides a couple of tools to help you debug issues in your projects. Because Git is designed to work with nearly any type of project, these tools are pretty generic, but they can often help you hunt for a bug or culprit when things go wrong.

From 39a1ea40cc088be3854fdf15fdd45d1ba992c2f7 Mon Sep 17 00:00:00 2001
From: Alec Clews <alecclews@gmail.com>
Date: Thu, 16 Jan 2014 19:25:03 +1100
Subject: [PATCH 498/690] A note about using 'git svn info' in build scripts

Also fixed a small typo
---
 en/08-git-and-other-scms/01-chapter8.markdown | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/en/08-git-and-other-scms/01-chapter8.markdown b/en/08-git-and-other-scms/01-chapter8.markdown
index 4e6671c27..49792b126 100644
--- a/en/08-git-and-other-scms/01-chapter8.markdown
+++ b/en/08-git-and-other-scms/01-chapter8.markdown
@@ -324,6 +324,17 @@ You can also get the same sort of information that `svn info` gives you by runni
 
 This is like `blame` and `log` in that it runs offline and is up to date only as of the last time you communicated with the Subversion server.
 
+Tip: If your build scripts expect to be able to run `svn info` then providing a wrapper around git will often work.
+Here is example to experiment with
+
+    #!/usr/bin/env bash
+
+    if git rev-parse --git-dir > /dev/null 2>&1 && [[ $1 == "info" ]] ; then
+      git svn info
+    else 
+      /usr/local/bin/svn "$@"
+    fi
+
 #### Ignoring What Subversion Ignores ####
 
 If you clone a Subversion repository that has `svn:ignore` properties set anywhere, you’ll likely want to set corresponding `.gitignore` files so you don’t accidentally commit files that you shouldn’t. `git svn` has two commands to help with this issue. The first is `git svn create-ignore`, which automatically creates corresponding `.gitignore` files for you so your next commit can include them.

From 4a84b8b8ae3d463d2014525a67920914bf5ea868 Mon Sep 17 00:00:00 2001
From: Kangyi Zhu <zhukangyi@gmail.com>
Date: Mon, 14 Jul 2014 19:24:25 +0800
Subject: [PATCH 499/690] [zh] Synchronize with English version

Synchronize with English version commit 9e0a6b9.
Synchronize the description of new example.
---
 zh/07-customizing-git/01-chapter7.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/zh/07-customizing-git/01-chapter7.markdown b/zh/07-customizing-git/01-chapter7.markdown
index 43ef5f389..33e268454 100644
--- a/zh/07-customizing-git/01-chapter7.markdown
+++ b/zh/07-customizing-git/01-chapter7.markdown
@@ -351,7 +351,7 @@ Git默认情况下不会在推送期间检查所有对象的一致性。虽然
 	-system for non-linear development.
 	+system for non-linear development (See Chapter 3).
 
-Git 成功且简洁地显示出我增加的文本"Let’s see if this works"。虽然有些瑕疵，在末尾显示了一些随机的内容，但确实可以比较了。如果你能找到或自己写个Word到纯文本的转换器的话，效果可能会更好。 `strings`可以在大部分Mac和Linux系统上运行，所以它是处理二进制格式的第一选择。
+Git 成功且简洁地显示出我增加的文本"(See Chapter 3)"。工作的很完美！
 
 ##### OpenDocument Text files #####
 

From 652925e2c5faffa67e3c9b1c3aa140fe0020e3a6 Mon Sep 17 00:00:00 2001
From: Kangyi Zhu <zhukangyi@gmail.com>
Date: Mon, 14 Jul 2014 19:26:39 +0800
Subject: [PATCH 500/690] [zh] Fix typo in 01-chapter7

Fix typo.
---
 zh/07-customizing-git/01-chapter7.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/zh/07-customizing-git/01-chapter7.markdown b/zh/07-customizing-git/01-chapter7.markdown
index 43ef5f389..500f4030e 100644
--- a/zh/07-customizing-git/01-chapter7.markdown
+++ b/zh/07-customizing-git/01-chapter7.markdown
@@ -819,7 +819,7 @@ update 脚本和 `pre-receive` 脚本十分类似。不同之处在于它会为
 
 ### 客户端挂钩 ###
 
-这种手段的缺点在于用户推送内容遭到拒绝后几乎无法避免的抱怨。辛辛苦苦写成的代码在最后时刻惨遭拒绝是十分悲剧切具迷惑性的；更可怜的是他们不得不修改提交历史来解决问题，这怎么也算不上王道。
+这种手段的缺点在于用户推送内容遭到拒绝后几乎无法避免的抱怨。辛辛苦苦写成的代码在最后时刻惨遭拒绝是十分悲剧且具有迷惑性的；更可怜的是他们不得不修改提交历史来解决问题，这怎么也算不上王道。
 
 逃离这种两难境地的法宝是给用户一些客户端的挂钩，在他们作出可能悲剧的事情的时候给以警告。然后呢，用户们就能在提交--问题变得更难修正之前解除隐患。由于挂钩本身不跟随克隆的项目副本分发，所以必须通过其他途径把这些挂钩分发到用户的 .git/hooks 目录并设为可执行文件。虽然可以在相同或单独的项目内 容里加入并分发它们，全自动的解决方案是不存在的。
 

From 1a5228d470049b28d9808db2418da81f61645554 Mon Sep 17 00:00:00 2001
From: Daniel Lin <brickgit@gmail.com>
Date: Mon, 14 Jul 2014 22:19:55 +0800
Subject: [PATCH 501/690] Correct some typos on chapter2

---
 zh-tw/02-git-basics/01-chapter2.markdown | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/zh-tw/02-git-basics/01-chapter2.markdown b/zh-tw/02-git-basics/01-chapter2.markdown
index 0ab5bb8e7..f637fa8f4 100644
--- a/zh-tw/02-git-basics/01-chapter2.markdown
+++ b/zh-tw/02-git-basics/01-chapter2.markdown
@@ -673,7 +673,7 @@ Git 原始碼的更新歷史接近二萬筆更新，本命令顯示符合條件
 
 ### 使用圖形界面檢視歷史 ###
 
-若讀者較偏向使用圖形界面檢視歷史，或與會想看一下隨著 Git 發佈的，名為 `gitk` 的 Tcl/Tk 程式。 Gitk 基本上就是 `git log` 的圖形界面版本，而且幾乎接受所有 `git log` 支援的過濾用選項。 若在專案所在目錄下執行 gitk 命令，將會看到如圖2-2的畫面。
+若讀者較偏向使用圖形界面檢視歷史，或許會想看一下隨著 Git 發佈的，名為 `gitk` 的 Tcl/Tk 程式。 Gitk 基本上就是 `git log` 的圖形界面版本，而且幾乎接受所有 `git log` 支援的過濾用選項。 若在專案所在目錄下執行 gitk 命令，將會看到如圖2-2的畫面。
 
 Insert 18333fig0202.png
 圖2-2。 gitk檢視歷史程式。
@@ -739,7 +739,7 @@ Insert 18333fig0202.png
 
 ### 復原已被更動的檔案 ###
 
-若讀者發現其者並不需要保留 `benchmarks.rb` 檔案被更動部份，應該如何做才能很容易的復原為最後一次提交的狀態（或者最被複製儲存庫時、或放到工作目錄時的版本）？ 很幸運的，`git status` 同樣也告訴讀者如何做。 在最近一次檢視狀態時，暫存區看起來應如下所示：
+若讀者發現其者並不需要保留 `benchmarks.rb` 檔案被更動部份，應該如何做才能很容易的復原為最後一次提交的狀態（或者最初複製儲存庫時、或放到工作目錄時的版本）？ 很幸運的，`git status` 同樣也告訴讀者如何做。 在最近一次檢視狀態時，暫存區看起來應如下所示：
 
 	Changes not staged for commit:
 	  (use "git add <file>..." to update what will be committed)
@@ -761,7 +761,7 @@ Insert 18333fig0202.png
 
 在上述文字可看到該變更已被復原。 讀者應該瞭解這是危險的命令，任何對該檔案做的修改將不復存在，就好像複製別的檔案將它覆蓋。 除非很清楚真的不需要該檔案，絕不要使用此檔案。 若需要將這些修改排除，我們在下一章節會介紹備份及分支。 一般來說會比此方法來的好。
 
-切記，任何在 Git 提交的更新幾乎都是可復原的。 即使是分支中的更新被刪除或被 `--amend` 覆寫，皆能被覆原。（參考第九章關於資料的復原） 然而，未被提交的則幾乎無法救回。
+切記，任何在 Git 提交的更新幾乎都是可復原的。 即使是分支中的更新被刪除或被 `--amend` 覆寫，皆能被復原。（參考第九章關於資料的復原） 然而，未被提交的則幾乎無法救回。
 
 ## 與遠端協同工作 ##
 
@@ -927,7 +927,7 @@ Insert 18333fig0202.png
 	v1.4.2.3
 	v1.4.2.4
 
-### 建立標簽 ###
+### 建立標籤 ###
 
 Git使用兩大類的標籤：輕量級(lightweight)和含附註(annotated)。輕量級標籤就像是沒有更動的分支，實際上它僅是指到特定commit的指標。然而，含附註的標籤則是實際存在Git資料庫上的完整物件。它具備檢查碼、e-mail和日期，也包含標籤訊息，並可以被GNU Privacy Guard (GPG)簽署和驗證。一般而言，我們都建議使用含附註的標籤以便保留相關訊息；但如果只是臨時加註標籤或不需要保留其他訊息，就是使用輕量級標籤的時機。
 
@@ -994,9 +994,9 @@ Git使用兩大類的標籤：輕量級(lightweight)和含附註(annotated)。
 
 稍後你會看到如何驗證已簽署的標籤。
 
-### 輕量級的標簽 ###
+### 輕量級的標籤 ###
 
-另一種則是輕量級的標簽。基本上就是只保存commit檢查碼的文件。要建立這樣的標籤，不必下任何選項，直接設定標籤名稱即可。
+另一種則是輕量級的標籤。基本上就是只保存commit檢查碼的文件。要建立這樣的標籤，不必下任何選項，直接設定標籤名稱即可。
 
 	$ git tag v1.4-lw
 	$ git tag
@@ -1180,4 +1180,4 @@ Git使用兩大類的標籤：輕量級(lightweight)和含附註(annotated)。
 
 ## 總結 ##
 
-至此，讀者已具備所有Git的本地端操作，包括：創建和副本儲存庫、建立修改、暫存和提交這些修改，以及檢視在儲存庫中所有修改歷史。接下來，我們將觸及Git的殺手級特性，也就是他的分支模型。
+至此，讀者已具備所有Git的本地端操作，包括：創建和複製儲存庫、建立修改、暫存和提交這些修改，以及檢視在儲存庫中所有修改歷史。接下來，我們將觸及Git的殺手級特性，也就是他的分支模型。

From 526c669412d42addb597f1bf0ff3084ba0fe5929 Mon Sep 17 00:00:00 2001
From: Daniel Lin <brickgit@gmail.com>
Date: Mon, 14 Jul 2014 22:19:55 +0800
Subject: [PATCH 502/690] [zh-tw] Correct some typos on chapter2

---
 zh-tw/02-git-basics/01-chapter2.markdown | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/zh-tw/02-git-basics/01-chapter2.markdown b/zh-tw/02-git-basics/01-chapter2.markdown
index 0ab5bb8e7..f637fa8f4 100644
--- a/zh-tw/02-git-basics/01-chapter2.markdown
+++ b/zh-tw/02-git-basics/01-chapter2.markdown
@@ -673,7 +673,7 @@ Git 原始碼的更新歷史接近二萬筆更新，本命令顯示符合條件
 
 ### 使用圖形界面檢視歷史 ###
 
-若讀者較偏向使用圖形界面檢視歷史，或與會想看一下隨著 Git 發佈的，名為 `gitk` 的 Tcl/Tk 程式。 Gitk 基本上就是 `git log` 的圖形界面版本，而且幾乎接受所有 `git log` 支援的過濾用選項。 若在專案所在目錄下執行 gitk 命令，將會看到如圖2-2的畫面。
+若讀者較偏向使用圖形界面檢視歷史，或許會想看一下隨著 Git 發佈的，名為 `gitk` 的 Tcl/Tk 程式。 Gitk 基本上就是 `git log` 的圖形界面版本，而且幾乎接受所有 `git log` 支援的過濾用選項。 若在專案所在目錄下執行 gitk 命令，將會看到如圖2-2的畫面。
 
 Insert 18333fig0202.png
 圖2-2。 gitk檢視歷史程式。
@@ -739,7 +739,7 @@ Insert 18333fig0202.png
 
 ### 復原已被更動的檔案 ###
 
-若讀者發現其者並不需要保留 `benchmarks.rb` 檔案被更動部份，應該如何做才能很容易的復原為最後一次提交的狀態（或者最被複製儲存庫時、或放到工作目錄時的版本）？ 很幸運的，`git status` 同樣也告訴讀者如何做。 在最近一次檢視狀態時，暫存區看起來應如下所示：
+若讀者發現其者並不需要保留 `benchmarks.rb` 檔案被更動部份，應該如何做才能很容易的復原為最後一次提交的狀態（或者最初複製儲存庫時、或放到工作目錄時的版本）？ 很幸運的，`git status` 同樣也告訴讀者如何做。 在最近一次檢視狀態時，暫存區看起來應如下所示：
 
 	Changes not staged for commit:
 	  (use "git add <file>..." to update what will be committed)
@@ -761,7 +761,7 @@ Insert 18333fig0202.png
 
 在上述文字可看到該變更已被復原。 讀者應該瞭解這是危險的命令，任何對該檔案做的修改將不復存在，就好像複製別的檔案將它覆蓋。 除非很清楚真的不需要該檔案，絕不要使用此檔案。 若需要將這些修改排除，我們在下一章節會介紹備份及分支。 一般來說會比此方法來的好。
 
-切記，任何在 Git 提交的更新幾乎都是可復原的。 即使是分支中的更新被刪除或被 `--amend` 覆寫，皆能被覆原。（參考第九章關於資料的復原） 然而，未被提交的則幾乎無法救回。
+切記，任何在 Git 提交的更新幾乎都是可復原的。 即使是分支中的更新被刪除或被 `--amend` 覆寫，皆能被復原。（參考第九章關於資料的復原） 然而，未被提交的則幾乎無法救回。
 
 ## 與遠端協同工作 ##
 
@@ -927,7 +927,7 @@ Insert 18333fig0202.png
 	v1.4.2.3
 	v1.4.2.4
 
-### 建立標簽 ###
+### 建立標籤 ###
 
 Git使用兩大類的標籤：輕量級(lightweight)和含附註(annotated)。輕量級標籤就像是沒有更動的分支，實際上它僅是指到特定commit的指標。然而，含附註的標籤則是實際存在Git資料庫上的完整物件。它具備檢查碼、e-mail和日期，也包含標籤訊息，並可以被GNU Privacy Guard (GPG)簽署和驗證。一般而言，我們都建議使用含附註的標籤以便保留相關訊息；但如果只是臨時加註標籤或不需要保留其他訊息，就是使用輕量級標籤的時機。
 
@@ -994,9 +994,9 @@ Git使用兩大類的標籤：輕量級(lightweight)和含附註(annotated)。
 
 稍後你會看到如何驗證已簽署的標籤。
 
-### 輕量級的標簽 ###
+### 輕量級的標籤 ###
 
-另一種則是輕量級的標簽。基本上就是只保存commit檢查碼的文件。要建立這樣的標籤，不必下任何選項，直接設定標籤名稱即可。
+另一種則是輕量級的標籤。基本上就是只保存commit檢查碼的文件。要建立這樣的標籤，不必下任何選項，直接設定標籤名稱即可。
 
 	$ git tag v1.4-lw
 	$ git tag
@@ -1180,4 +1180,4 @@ Git使用兩大類的標籤：輕量級(lightweight)和含附註(annotated)。
 
 ## 總結 ##
 
-至此，讀者已具備所有Git的本地端操作，包括：創建和副本儲存庫、建立修改、暫存和提交這些修改，以及檢視在儲存庫中所有修改歷史。接下來，我們將觸及Git的殺手級特性，也就是他的分支模型。
+至此，讀者已具備所有Git的本地端操作，包括：創建和複製儲存庫、建立修改、暫存和提交這些修改，以及檢視在儲存庫中所有修改歷史。接下來，我們將觸及Git的殺手級特性，也就是他的分支模型。

From aa1e9bc460a8c335a9add63a5e4812925f582e6b Mon Sep 17 00:00:00 2001
From: klern <sam.wang@ortery.com>
Date: Tue, 15 Jul 2014 15:29:40 +0800
Subject: [PATCH 503/690] Update 01-chapter5.markdown

typo
---
 zh-tw/05-distributed-git/01-chapter5.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/zh-tw/05-distributed-git/01-chapter5.markdown b/zh-tw/05-distributed-git/01-chapter5.markdown
index b8dbecdd5..655b22b01 100644
--- a/zh-tw/05-distributed-git/01-chapter5.markdown
+++ b/zh-tw/05-distributed-git/01-chapter5.markdown
@@ -85,7 +85,7 @@ Insert 18333fig0503.png
 接下來，請將每次提交限定於完成一次邏輯功能。並且可能的話，適當地分解為多次小更新，以便每次小型提交都更易於理解。請不要在週末窮追猛打一次性解決五個問題，而最後拖到週一再提交。就算是這樣也請盡可能利用暫存區域，將之前的改動分解為每次修復一個問題，再分別提交和加注說明。如果針對兩個問題改動的是同一個檔，可以試試看 `git add --patch` 的方式將部分內容置入暫存區域（我們會在第六章再詳細介紹）。無論是五次小提交還是混雜在一起的大提交，最終分支末端的專案快照應該還是一樣的，但分解開來之後，更便於其他開發者複閱。這麼做也方便自己將來取消某個特定問題的修復。我們將在第六章介紹一些重寫提交歷史，同暫存區域交互的技巧和工具，以便最終得到一個乾淨有意義，且易於理解的提交歷史。
 
 最後需要謹記的是提交說明的撰寫。寫得好可以讓大家協作起來更輕鬆。一般來說，提交說明最好限制在一行以內，50 個字元以下，簡明扼要地描述更新內容，空開一行後，再展開詳細注解。Git 專案本身需要開發者撰寫詳盡注解，包括本次修訂的因由，以及前後不同實現之間的比較，我們也該借鑒這種做法。另外，提交說明應該用祈使現在式語態，比如，不要說成 “I added tests for” 或 “Adding tests for” 而應該用 “Add tests for”。
-下麵是來自 tpope.net 的 Tim Pope 原創的提交說明格式模版，供參考：
+下面是來自 tpope.net 的 Tim Pope 原創的提交說明格式模版，供參考：
 
 	本次更新的簡要描述（50 個字元以內）
 

From c6b3fc8240ed9de96f2135f7e2a5d882c6bc7824 Mon Sep 17 00:00:00 2001
From: Daniel Lin <brickgit@gmail.com>
Date: Tue, 15 Jul 2014 15:50:07 +0800
Subject: [PATCH 504/690] [zh-tw] Correct some typos on chapter3

---
 zh-tw/03-git-branching/01-chapter3.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/zh-tw/03-git-branching/01-chapter3.markdown b/zh-tw/03-git-branching/01-chapter3.markdown
index 918a9fd6f..a4fe6b5e8 100644
--- a/zh-tw/03-git-branching/01-chapter3.markdown
+++ b/zh-tw/03-git-branching/01-chapter3.markdown
@@ -580,7 +580,7 @@ Insert 18333fig0335.png
 Insert 18333fig0336.png
 圖 3-36. 克隆一個倉庫，在其基礎上工作一番。
 
-現在，某人在 C1 的基礎上做了些改變，併合並他自己的分支得到結果 C6，推送到中央伺服器。當你抓取併合並這些資料到你本地的開發分支中後，會得到合併結果 C7，歷史提交會變成圖 3-37 這樣：
+現在，某人在 C1 的基礎上做了些改變，並合併他自己的分支得到結果 C6，推送到中央伺服器。當你抓取並合併這些資料到你本地的開發分支中後，會得到合併結果 C7，歷史提交會變成圖 3-37 這樣：
 
 Insert 18333fig0337.png
 圖 3-37. 抓取他人提交，併入自己主幹。

From ccdf2802a71755f5ed60ae06620061b0e41c1322 Mon Sep 17 00:00:00 2001
From: Jean-Noel Avila <jn.avila@free.fr>
Date: Tue, 15 Jul 2014 19:14:41 +0200
Subject: [PATCH 505/690] [fr] update with bdef6f76

---
 fr/02-git-basics/01-chapter2.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fr/02-git-basics/01-chapter2.markdown b/fr/02-git-basics/01-chapter2.markdown
index a52fc4c61..f35cc0469 100644
--- a/fr/02-git-basics/01-chapter2.markdown
+++ b/fr/02-git-basics/01-chapter2.markdown
@@ -1290,7 +1290,7 @@ De nombreuses personnes utilisent parfaitement Git sans connaître aucun de ces
 
 Si vous utilisez le shell Bash, Git est livré avec un script d'auto-complétion utile.
 Téléchargez le directement depuis le code source de Git à https://github.com/git/git/blob/master/contrib/git-completion.bash .
-Copiez ce fichier dans votre répertoire personnel et ajoutez cette ligne à votre fichier `.bashrc` :
+Copiez ce fichier dans votre répertoire personnel sous le nom `.git-completion.bash` et ajoutez cette ligne à votre fichier `.bashrc` :
 
 	source ~/.git-completion.bash
 

From 8343398db460066104f0514d76352a220e0df304 Mon Sep 17 00:00:00 2001
From: Jean-Noel Avila <jn.avila@free.fr>
Date: Tue, 15 Jul 2014 21:54:24 +0200
Subject: [PATCH 506/690] [fr] sync with c418e2ea

---
 fr/03-git-branching/01-chapter3.markdown | 15 ++++++++++-----
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/fr/03-git-branching/01-chapter3.markdown b/fr/03-git-branching/01-chapter3.markdown
index 832292d3b..2f6370579 100644
--- a/fr/03-git-branching/01-chapter3.markdown
+++ b/fr/03-git-branching/01-chapter3.markdown
@@ -336,15 +336,20 @@ Placer le fichier dans l'index marque le conflit comme résolu pour Git.
 Si vous souhaitez utiliser un outil graphique pour résoudre ces problèmes, vous pouvez lancer `git mergetool` qui démarre l'outil graphique de fusion approprié et vous permet de naviguer dans les conflits :
 
 	$ git mergetool
-	merge tool candidates: kdiff3 tkdiff xxdiff meld gvimdiff opendiff emerge vimdiff
-	Merging the files: index.html
+
+	This message is displayed because 'merge.tool' is not configured.
+	See 'git mergetool --tool-help' or 'git help config' for more details.
+	'git mergetool' will now attempt to use one of the following tools:
+	opendiff kdiff3 tkdiff xxdiff meld tortoisemerge gvimdiff diffuse diffmerge ecmerge p4merge araxis bc3 codecompare vimdiff emerge
+	Merging:
+	index.html
 
 	Normal merge conflict for 'index.html':
-	  {local}: modified
-	  {remote}: modified
+	  {local}: modified file
+	  {remote}: modified file
 	Hit return to start merge resolution tool (opendiff):
 
-Si vous souhaitez utiliser un outil de fusion autre que celui par défaut (Git a choisi `opendiff` pour moi dans ce cas car j'utilise la commande sous Mac), vous pouvez voir tous les outils supportés après l'indication « merge tool candidates ».
+Si vous souhaitez utiliser un outil de fusion autre que celui par défaut (Git a choisi `opendiff` pour moi dans ce cas car j'utilise la commande sous Mac), vous pouvez voir tous les outils supportés après l'indication « *of the following tools:* ».
 Tapez le nom de l'outil que vous préfèreriez utiliser.
 Au chapitre 7, nous expliquerons comment changer cette valeur par défaut dans votre environnement.
 

From 608b8b2cf1dd5903fc5159a71da0ad642302f0bd Mon Sep 17 00:00:00 2001
From: Jean-Noel Avila <jn.avila@free.fr>
Date: Tue, 15 Jul 2014 21:57:48 +0200
Subject: [PATCH 507/690] [fr] Sync with ceba7dfb

---
 fr/02-git-basics/01-chapter2.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fr/02-git-basics/01-chapter2.markdown b/fr/02-git-basics/01-chapter2.markdown
index f35cc0469..771cd44a7 100644
--- a/fr/02-git-basics/01-chapter2.markdown
+++ b/fr/02-git-basics/01-chapter2.markdown
@@ -924,7 +924,7 @@ Par exemple, mon dépôt Grit ressemble à ceci.
 	koke      git://github.com/koke/grit.git
 	origin    git@github.com:mojombo/grit.git
 
-Cela signifie que nous pouvons tirer très facilement des contributions depuis certains utilisateurs.
+Cela signifie que je peux tirer très facilement des contributions depuis certains utilisateurs.
 Mais il est à noter que seul le dépôt distant `origin` utilise une URL SSH, ce qui signifie que c'est le seul sur lequel je peux pousser (nous traiterons de ceci au chapitre 4).
 
 ### Ajouter des dépôts distants ###

From ac28a7e8e49923e895e380a9fec56e44ddf34211 Mon Sep 17 00:00:00 2001
From: Jean-Noel Avila <jn.avila@free.fr>
Date: Tue, 15 Jul 2014 22:10:07 +0200
Subject: [PATCH 508/690] [fr] Sync with 60e26189

---
 fr/02-git-basics/01-chapter2.markdown | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/fr/02-git-basics/01-chapter2.markdown b/fr/02-git-basics/01-chapter2.markdown
index 771cd44a7..29843aad8 100644
--- a/fr/02-git-basics/01-chapter2.markdown
+++ b/fr/02-git-basics/01-chapter2.markdown
@@ -738,7 +738,9 @@ Cette commande fonctionne avec de nombreux formats — vous pouvez indiquer une
 
 Vous pouvez aussi restreindre la liste aux *commits* vérifiant certains critères de recherche.
 L'option `--author` permet de filtrer sur un auteur spécifique, et l'option `--grep` permet de chercher des mots clés dans les messages de validation.
-Notez que si vous cherchez seulement des *commits* correspondant simultanément aux deux critères, vous devez ajouter l'option `--all-match`, car par défaut ces commandes retournent les *commits* vérifiant au moins un critère lors de recherche.
+Notez que si vous spécifiez à la fois `--author` et `--grep`, la commande retournera seulement des *commits* correspondant simultanément aux deux critères.
+
+Si vous souhaitez spécifier plusieurs options `--grep`,  vous devez ajouter l'option `--all-match`, car par défaut ces commandes retournent les *commits* vérifiant au moins un critère de recherche.
 
 La dernière option vraiment utile à `git log` est la spécification d'un chemin.
 Si un répertoire ou un nom de fichier est spécifié, le journal est limité aux *commits* qui ont introduit des modifications aux fichiers concernés.

From b6305ab38e5cfc83eca5b9a84eee85298250b87d Mon Sep 17 00:00:00 2001
From: Alec Clews <alecclews@gmail.com>
Date: Wed, 16 Jul 2014 13:27:13 +1000
Subject: [PATCH 509/690] Updated after feedback on 548a15f

---
 en/06-git-tools/01-chapter6.markdown | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/en/06-git-tools/01-chapter6.markdown b/en/06-git-tools/01-chapter6.markdown
index 762e1aab6..15cf7b93a 100644
--- a/en/06-git-tools/01-chapter6.markdown
+++ b/en/06-git-tools/01-chapter6.markdown
@@ -730,9 +730,9 @@ Another common case is that you forgot to run `git config` to set your name and
 
 This goes through and rewrites every commit to have your new address. Because commits contain the SHA-1 values of their parents, this command changes every commit SHA in your history, not just those that have the matching e-mail address.
 
-### The Very Fast Nuclear Option: Big Friendly Giant Repo Cleaner ###
+### The Very Fast Nuclear Option: Big Friendly Giant Repo Cleaner (BFG) ###
 
-[Roberto Tyley](https://github.com/rtyley) has written a similar tool to filter-branch called the BFG. It is more limited in what is can do, but it is _very_ fast and on a large repository this can make a big difference.
+[Roberto Tyley](https://github.com/rtyley) has written a similar tool to `filter-branch` called the BFG. BFG cannot do as much as `filter-branch`, but it is _very_ fast and on a large repository this can make a big difference. If the change you want to make is in the scope of BFG capaility, and you have performance issues, then you should consider using it.
 
 See the [BFG](http://rtyley.github.io/bfg-repo-cleaner/) website for details.
 

From a41419d570381128264b02f2cfa56f0de8630a45 Mon Sep 17 00:00:00 2001
From: Kangyi Zhu <zhukangyi@gmail.com>
Date: Tue, 15 Jul 2014 20:08:10 +0800
Subject: [PATCH 510/690] [zh]Fix a typo in chapter 7 fix a typo

---
 zh/07-customizing-git/01-chapter7.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/zh/07-customizing-git/01-chapter7.markdown b/zh/07-customizing-git/01-chapter7.markdown
index 43ef5f389..427a37ab5 100644
--- a/zh/07-customizing-git/01-chapter7.markdown
+++ b/zh/07-customizing-git/01-chapter7.markdown
@@ -251,7 +251,7 @@ Git预先设置了一些选项来探测和修正空白问题，其4种主要选
 
 	$ git apply --whitespace=fix <patch>
 
-这些选项也能运用于衍合。如果提交了有空白问题的文件但还没推送到上流，你可以运行带有`--whitespace=fix`选项的`rebase`来让Git在重写补丁时自动修正它们。
+这些选项也能运用于衍合。如果提交了有空白问题的文件但还没推送到上游，你可以运行带有`--whitespace=fix`选项的`rebase`来让Git在重写补丁时自动修正它们。
 
 ### 服务器端配置 ###
 

From 6bd33272819cb1e2af0e94eb48102baaa302d111 Mon Sep 17 00:00:00 2001
From: Kangyi Zhu <zhukangyi@gmail.com>
Date: Tue, 15 Jul 2014 19:47:16 +0800
Subject: [PATCH 511/690] [zh]Translate binary file type name

---
 zh/07-customizing-git/01-chapter7.markdown | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/zh/07-customizing-git/01-chapter7.markdown b/zh/07-customizing-git/01-chapter7.markdown
index 986f0b379..0f7a3c68e 100644
--- a/zh/07-customizing-git/01-chapter7.markdown
+++ b/zh/07-customizing-git/01-chapter7.markdown
@@ -313,7 +313,7 @@ Git默认情况下不会在推送期间检查所有对象的一致性。虽然
 
 边注：有一些二进制文件虽然包含文字，但是却难以转换。（译注：例如 Word 文档。）在这些情况，你可以尝试使用 `strings` 工具来获取其中的文字。但如果当这些文档包含 UTF-16 编码，或者其他代码页（codepages），`strings` 也可能无补于事。`strings` 在大部分的 Mac 和 Linux 下都有安装。当遇到有二进制文件需要转换的时候，你可以试试这个工具。
 
-##### MS Word files #####
+##### Word文档 #####
 
 这个特性很酷，而且鲜为人知，因此我会结合实例来讲解。首先，要解决的是最令人头疼的问题：对Word文档进行版本控制。很多人对Word文档又恨又爱，如果想对其进行版本控制，你可以把文件加入到 Git 库中，每次修改后提交即可。但这样做没有一点实际意义，因为运行`git diff`命令后，你只能得到如下的结果：
 
@@ -353,7 +353,7 @@ Git默认情况下不会在推送期间检查所有对象的一致性。虽然
 
 Git 成功且简洁地显示出我增加的文本"(See Chapter 3)"。工作的很完美！
 
-##### OpenDocument Text files #####
+##### OpenDocument文本文档 #####
 
 The same approach that we used for MS Word files (`*.doc`) can be used for OpenDocument Text files (`*.odt`) created by OpenOffice.org.
 
@@ -403,7 +403,7 @@ And make it executable
 
 Now `git diff` will be able to tell you what changed in `.odt` files.
 
-##### Image files #####
+##### 图像文件 #####
 
 你还能用这个方法比较图像文件。当比较时，对JPEG文件运用一个过滤器，它能提炼出EXIF信息 — 大部分图像格式使用的元数据。如果你下载并安装了`exiftool`程序，可以用它参照元数据把图像转换成文本。比较的不同结果将会用文本向你展示：
 

From ce39ac2e9afca4ab9a02a5e9d546d90347988c43 Mon Sep 17 00:00:00 2001
From: Kangyi Zhu <zhukangyi@gmail.com>
Date: Wed, 16 Jul 2014 19:51:42 +0800
Subject: [PATCH 512/690] [zh]Translate a part of chapter 7 Translate
 OpenDocument Text files section in chapter 7

---
 zh/07-customizing-git/01-chapter7.markdown | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/zh/07-customizing-git/01-chapter7.markdown b/zh/07-customizing-git/01-chapter7.markdown
index 0f7a3c68e..f793fa52a 100644
--- a/zh/07-customizing-git/01-chapter7.markdown
+++ b/zh/07-customizing-git/01-chapter7.markdown
@@ -355,19 +355,19 @@ Git 成功且简洁地显示出我增加的文本"(See Chapter 3)"。工作的
 
 ##### OpenDocument文本文档 #####
 
-The same approach that we used for MS Word files (`*.doc`) can be used for OpenDocument Text files (`*.odt`) created by OpenOffice.org.
+我们用于处理Word文档（`*.doc`）的方法同样适用于处理OpenOffice.org创建的OpenDocument文本文档（`*.odt`）。
 
-Add the following line to your `.gitattributes` file:
+把下面这行添加到`.gitattributes`文件：
 
 	*.odt diff=odt
 
-Now set up the `odt` diff filter in `.git/config`:
+然后在`.git/config` 文件中设置`odt`过滤器：
 
 	[diff "odt"]
 		binary = true
 		textconv = /usr/local/bin/odt-to-txt
 
-OpenDocument files are actually zip’ped directories containing multiple files (the content in an XML format, stylesheets, images, etc.). We’ll need to write a script to extract the content and return it as plain text. Create a file `/usr/local/bin/odt-to-txt` (you are free to put it into a different directory) with the following content:
+OpenDocument文档实际上是多个文件（包括一个XML文件和表格、图片等文件）的压缩包。我们需要写一个脚本来提取其中纯文本格式的内容。创建一个文件`/usr/local/bin/odt-to-txt`（你也可以放到其他目录下），写入下面内容：
 
 	#! /usr/bin/env perl
 	# Simplistic OpenDocument Text (.odt) to plain text converter.
@@ -397,11 +397,11 @@ OpenDocument files are actually zip’ped directories containing multiple files
 	s/\A\n+//;                         # remove leading blank lines
 	print "\n", $_, "\n\n";
 
-And make it executable
+然后把它设为可执行文件
 
 	chmod +x /usr/local/bin/odt-to-txt
 
-Now `git diff` will be able to tell you what changed in `.odt` files.
+现在`git diff`命令就可以显示`.odt`文件的变更了。
 
 ##### 图像文件 #####
 

From 5277a400c8cf1c8a807c0810580681394b4d41f7 Mon Sep 17 00:00:00 2001
From: Daniel Lin <brickgit@gmail.com>
Date: Tue, 15 Jul 2014 15:50:07 +0800
Subject: [PATCH 513/690] [zh-tw] Correct some typos on chapter3

---
 zh-tw/03-git-branching/01-chapter3.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/zh-tw/03-git-branching/01-chapter3.markdown b/zh-tw/03-git-branching/01-chapter3.markdown
index 918a9fd6f..a4fe6b5e8 100644
--- a/zh-tw/03-git-branching/01-chapter3.markdown
+++ b/zh-tw/03-git-branching/01-chapter3.markdown
@@ -580,7 +580,7 @@ Insert 18333fig0335.png
 Insert 18333fig0336.png
 圖 3-36. 克隆一個倉庫，在其基礎上工作一番。
 
-現在，某人在 C1 的基礎上做了些改變，併合並他自己的分支得到結果 C6，推送到中央伺服器。當你抓取併合並這些資料到你本地的開發分支中後，會得到合併結果 C7，歷史提交會變成圖 3-37 這樣：
+現在，某人在 C1 的基礎上做了些改變，並合併他自己的分支得到結果 C6，推送到中央伺服器。當你抓取並合併這些資料到你本地的開發分支中後，會得到合併結果 C7，歷史提交會變成圖 3-37 這樣：
 
 Insert 18333fig0337.png
 圖 3-37. 抓取他人提交，併入自己主幹。

From 70fdcc7a74ce2c465cde933652e2f1c3a7c8c655 Mon Sep 17 00:00:00 2001
From: okhtayaz <okhtay@gmail.com>
Date: Tue, 15 Jul 2014 17:36:48 -0700
Subject: [PATCH 514/690] [fa] Persian translation started. includes two
 paragraphs from chapter 1 and an inirial README file to complete as the work
 progresses

---
 fa/.gitignore                           |   2 +
 fa/01-introduction/01-chapter1.markdown | 262 ++++++++++++++++++++++++
 fa/README.md                            |   7 +
 3 files changed, 271 insertions(+)
 create mode 100644 fa/.gitignore
 create mode 100644 fa/01-introduction/01-chapter1.markdown
 create mode 100644 fa/README.md

diff --git a/fa/.gitignore b/fa/.gitignore
new file mode 100644
index 000000000..b7cd94167
--- /dev/null
+++ b/fa/.gitignore
@@ -0,0 +1,2 @@
+.DS_store
+.idea
\ No newline at end of file
diff --git a/fa/01-introduction/01-chapter1.markdown b/fa/01-introduction/01-chapter1.markdown
new file mode 100644
index 000000000..11b5b2d71
--- /dev/null
+++ b/fa/01-introduction/01-chapter1.markdown
@@ -0,0 +1,262 @@
+# آغاز #
+
+این فصل در موردشروع استفاده از گیت خواهد بود.  
+ما ابتدا کمی پیشزمینه ابزارهای کنترل نسخه را مرور میکنیم، سپس میرسیم به قسمتی که چگونه گیت را  در سیستم خود راه اندازی کنید و در نهایت چگونه آن را نصب کنید تا بتوانید با آن شروع به کار نمایید. 
+در انتهای این فصل شما باید فهمیده باشید که چرا گیت لازم است، چرا باید از آن استفاده کرد و آماده باشید تا شروع به استفاده از آن کنید.  
+
+## درباره کنترل نسخه ##
+
+کنترل نسخه چیست، و چرا باید برای شما اهمیتی داشته باشد؟ کنترل نسخه سیستمی ست که تغییرات ایجاد شده در یک فایل یا مجموعه ای از فایلها را در طول زمان ثبت میکند تا شما بتوانید نسخه مشخصی از آنها را بعدا بازخوانی کنید. 
+ Even though the examples in this book show software source code as the files under version control, in reality any type of file on a computer can be placed under version control.
+
+If you are a graphic or web designer and want to keep every version of an image or layout (which you certainly would), it is very wise to use a Version Control System (VCS). A VCS allows you to: revert files back to a previous state, revert the entire project back to a previous state, review changes made over time, see who last modified something that might be causing a problem, who introduced an issue and when, and more. Using a VCS also means that if you screw things up or lose files, you can generally recover easily. In addition, you get all this for very little overhead.
+
+### Local Version Control Systems ###
+
+Many people’s version-control method of choice is to copy files into another directory (perhaps a time-stamped directory, if they’re clever). This approach is very common because it is so simple, but it is also incredibly error prone. It is easy to forget which directory you’re in and accidentally write to the wrong file or copy over files you don’t mean to.
+
+To deal with this issue, programmers long ago developed local VCSs that had a simple database that kept all the changes to files under revision control (see Figure 1-1).
+
+Insert 18333fig0101.png
+Figure 1-1. Local version control diagram.
+
+One of the more popular VCS tools was a system called rcs, which is still distributed with many computers today. Even the popular Mac OS X operating system includes the rcs command when you install the Developer Tools. This tool basically works by keeping patch sets (that is, the differences between files) from one revision to another in a special format on disk; it can then recreate what any file looked like at any point in time by adding up all the patches.
+
+### Centralized Version Control Systems ###
+
+The next major issue that people encounter is that they need to collaborate with developers on other systems. To deal with this problem, Centralized Version Control Systems (CVCSs) were developed. These systems, such as CVS, Subversion, and Perforce, have a single server that contains all the versioned files, and a number of clients that check out files from that central place. For many years, this has been the standard for version control (see Figure 1-2).
+
+Insert 18333fig0102.png
+Figure 1-2. Centralized version control diagram.
+
+This setup offers many advantages, especially over local VCSs. For example, everyone knows to a certain degree what everyone else on the project is doing. Administrators have fine-grained control over who can do what; and it’s far easier to administer a CVCS than it is to deal with local databases on every client.
+
+However, this setup also has some serious downsides. The most obvious is the single point of failure that the centralized server represents. If that server goes down for an hour, then during that hour nobody can collaborate at all or save versioned changes to anything they’re working on. If the hard disk the central database is on becomes corrupted, and proper backups haven’t been kept, you lose absolutely everything—the entire history of the project except whatever single snapshots people happen to have on their local machines. Local VCS systems suffer from this same problem—whenever you have the entire history of the project in a single place, you risk losing everything.
+
+### Distributed Version Control Systems ###
+
+This is where Distributed Version Control Systems (DVCSs) step in. In a DVCS (such as Git, Mercurial, Bazaar or Darcs), clients don’t just check out the latest snapshot of the files: they fully mirror the repository. Thus if any server dies, and these systems were collaborating via it, any of the client repositories can be copied back up to the server to restore it. Every checkout is really a full backup of all the data (see Figure 1-3).
+
+Insert 18333fig0103.png
+Figure 1-3. Distributed version control diagram.
+
+Furthermore, many of these systems deal pretty well with having several remote repositories they can work with, so you can collaborate with different groups of people in different ways simultaneously within the same project. This allows you to set up several types of workflows that aren’t possible in centralized systems, such as hierarchical models.
+
+## A Short History of Git ##
+
+As with many great things in life, Git began with a bit of creative destruction and fiery controversy. The Linux kernel is an open source software project of fairly large scope. For most of the lifetime of the Linux kernel maintenance (1991–2002), changes to the software were passed around as patches and archived files. In 2002, the Linux kernel project began using a proprietary DVCS system called BitKeeper.
+
+In 2005, the relationship between the community that developed the Linux kernel and the commercial company that developed BitKeeper broke down, and the tool’s free-of-charge status was revoked. This prompted the Linux development community (and in particular Linus Torvalds, the creator of Linux) to develop their own tool based on some of the lessons they learned while using BitKeeper. Some of the goals of the new system were as follows:
+
+*	Speed
+*	Simple design
+*	Strong support for non-linear development (thousands of parallel branches)
+*	Fully distributed
+*	Able to handle large projects like the Linux kernel efficiently (speed and data size)
+
+Since its birth in 2005, Git has evolved and matured to be easy to use and yet retain these initial qualities. It’s incredibly fast, it’s very efficient with large projects, and it has an incredible branching system for non-linear development (See Chapter 3).
+
+## Git Basics ##
+
+So, what is Git in a nutshell? This is an important section to absorb, because if you understand what Git is and the fundamentals of how it works, then using Git effectively will probably be much easier for you. As you learn Git, try to clear your mind of the things you may know about other VCSs, such as Subversion and Perforce; doing so will help you avoid subtle confusion when using the tool. Git stores and thinks about information much differently than these other systems, even though the user interface is fairly similar; understanding those differences will help prevent you from becoming confused while using it.
+
+### Snapshots, Not Differences ###
+
+The major difference between Git and any other VCS (Subversion and friends included) is the way Git thinks about its data. Conceptually, most other systems store information as a list of file-based changes. These systems (CVS, Subversion, Perforce, Bazaar, and so on) think of the information they keep as a set of files and the changes made to each file over time, as illustrated in Figure 1-4.
+
+Insert 18333fig0104.png
+Figure 1-4. Other systems tend to store data as changes to a base version of each file.
+
+Git doesn’t think of or store its data this way. Instead, Git thinks of its data more like a set of snapshots of a mini filesystem. Every time you commit, or save the state of your project in Git, it basically takes a picture of what all your files look like at that moment and stores a reference to that snapshot. To be efficient, if files have not changed, Git doesn’t store the file again—just a link to the previous identical file it has already stored. Git thinks about its data more like Figure 1-5.
+
+Insert 18333fig0105.png
+Figure 1-5. Git stores data as snapshots of the project over time.
+
+This is an important distinction between Git and nearly all other VCSs. It makes Git reconsider almost every aspect of version control that most other systems copied from the previous generation. This makes Git more like a mini filesystem with some incredibly powerful tools built on top of it, rather than simply a VCS. We’ll explore some of the benefits you gain by thinking of your data this way when we cover Git branching in Chapter 3.
+
+### Nearly Every Operation Is Local ###
+
+Most operations in Git only need local files and resources to operate — generally no information is needed from another computer on your network.  If you’re used to a CVCS where most operations have that network latency overhead, this aspect of Git will make you think that the gods of speed have blessed Git with unworldly powers. Because you have the entire history of the project right there on your local disk, most operations seem almost instantaneous.
+
+For example, to browse the history of the project, Git doesn’t need to go out to the server to get the history and display it for you—it simply reads it directly from your local database. This means you see the project history almost instantly. If you want to see the changes introduced between the current version of a file and the file a month ago, Git can look up the file a month ago and do a local difference calculation, instead of having to either ask a remote server to do it or pull an older version of the file from the remote server to do it locally.
+
+This also means that there is very little you can’t do if you’re offline or off VPN. If you get on an airplane or a train and want to do a little work, you can commit happily until you get to a network connection to upload. If you go home and can’t get your VPN client working properly, you can still work. In many other systems, doing so is either impossible or painful. In Perforce, for example, you can’t do much when you aren’t connected to the server; and in Subversion and CVS, you can edit files, but you can’t commit changes to your database (because your database is offline). This may not seem like a huge deal, but you may be surprised what a big difference it can make.
+
+### Git Has Integrity ###
+
+Everything in Git is check-summed before it is stored and is then referred to by that checksum. This means it’s impossible to change the contents of any file or directory without Git knowing about it. This functionality is built into Git at the lowest levels and is integral to its philosophy. You can’t lose information in transit or get file corruption without Git being able to detect it.
+
+The mechanism that Git uses for this checksumming is called a SHA-1 hash. This is a 40-character string composed of hexadecimal characters (0–9 and a–f) and calculated based on the contents of a file or directory structure in Git. A SHA-1 hash looks something like this:
+
+	24b9da6552252987aa493b52f8696cd6d3b00373
+
+You will see these hash values all over the place in Git because it uses them so much. In fact, Git stores everything not by file name but in the Git database addressable by the hash value of its contents.
+
+### Git Generally Only Adds Data ###
+
+When you do actions in Git, nearly all of them only add data to the Git database. It is very difficult to get the system to do anything that is not undoable or to make it erase data in any way. As in any VCS, you can lose or mess up changes you haven’t committed yet; but after you commit a snapshot into Git, it is very difficult to lose, especially if you regularly push your database to another repository.
+
+This makes using Git a joy because we know we can experiment without the danger of severely screwing things up. For a more in-depth look at how Git stores its data and how you can recover data that seems lost, see Chapter 9.
+
+### The Three States ###
+
+Now, pay attention. This is the main thing to remember about Git if you want the rest of your learning process to go smoothly. Git has three main states that your files can reside in: committed, modified, and staged. Committed means that the data is safely stored in your local database. Modified means that you have changed the file but have not committed it to your database yet. Staged means that you have marked a modified file in its current version to go into your next commit snapshot.
+
+This leads us to the three main sections of a Git project: the Git directory, the working directory, and the staging area.
+
+Insert 18333fig0106.png
+Figure 1-6. Working directory, staging area, and Git directory.
+
+The Git directory is where Git stores the metadata and object database for your project. This is the most important part of Git, and it is what is copied when you clone a repository from another computer.
+
+The working directory is a single checkout of one version of the project. These files are pulled out of the compressed database in the Git directory and placed on disk for you to use or modify.
+
+The staging area is a simple file, generally contained in your Git directory, that stores information about what will go into your next commit. It’s sometimes referred to as the index, but it’s becoming standard to refer to it as the staging area.
+
+The basic Git workflow goes something like this:
+
+1. You modify files in your working directory.
+2. You stage the files, adding snapshots of them to your staging area.
+3. You do a commit, which takes the files as they are in the staging area and stores that snapshot permanently to your Git directory.
+
+If a particular version of a file is in the Git directory, it’s considered committed. If it’s modified but has been added to the staging area, it is staged. And if it was changed since it was checked out but has not been staged, it is modified. In Chapter 2, you’ll learn more about these states and how you can either take advantage of them or skip the staged part entirely.
+
+## Installing Git ##
+
+Let’s get into using some Git. First things first—you have to install it. You can get it a number of ways; the two major ones are to install it from source or to install an existing package for your platform.
+
+### Installing from Source ###
+
+If you can, it’s generally useful to install Git from source, because you’ll get the most recent version. Each version of Git tends to include useful UI enhancements, so getting the latest version is often the best route if you feel comfortable compiling software from source. It is also the case that many Linux distributions contain very old packages; so unless you’re on a very up-to-date distro or are using backports, installing from source may be the best bet.
+
+To install Git, you need to have the following libraries that Git depends on: curl, zlib, openssl, expat, and libiconv. For example, if you’re on a system that has yum (such as Fedora) or apt-get (such as a Debian based system), you can use one of these commands to install all of the dependencies:
+
+	$ yum install curl-devel expat-devel gettext-devel \
+	  openssl-devel zlib-devel
+
+	$ apt-get install libcurl4-gnutls-dev libexpat1-dev gettext \
+	  libz-dev libssl-dev
+
+When you have all the necessary dependencies, you can go ahead and grab the latest snapshot from the Git web site:
+
+	http://git-scm.com/download
+
+Then, compile and install:
+
+	$ tar -zxf git-1.7.2.2.tar.gz
+	$ cd git-1.7.2.2
+	$ make prefix=/usr/local all
+	$ sudo make prefix=/usr/local install
+
+After this is done, you can also get Git via Git itself for updates:
+
+	$ git clone git://git.kernel.org/pub/scm/git/git.git
+
+### Installing on Linux ###
+
+If you want to install Git on Linux via a binary installer, you can generally do so through the basic package-management tool that comes with your distribution. If you’re on Fedora, you can use yum:
+
+	$ yum install git-core
+
+Or if you’re on a Debian-based distribution like Ubuntu, try apt-get:
+
+	$ apt-get install git
+
+### Installing on Mac ###
+
+There are two easy ways to install Git on a Mac. The easiest is to use the graphical Git installer, which you can download from the SourceForge page (see Figure 1-7):
+
+	http://sourceforge.net/projects/git-osx-installer/
+
+Insert 18333fig0107.png
+Figure 1-7. Git OS X installer.
+
+The other major way is to install Git via MacPorts (`http://www.macports.org`). If you have MacPorts installed, install Git via
+
+	$ sudo port install git-core +svn +doc +bash_completion +gitweb
+
+You don’t have to add all the extras, but you’ll probably want to include +svn in case you ever have to use Git with Subversion repositories (see Chapter 8).
+
+### Installing on Windows ###
+
+Installing Git on Windows is very easy. The msysGit project has one of the easier installation procedures. Simply download the installer exe file from the GitHub page, and run it:
+
+	http://msysgit.github.io
+
+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.
+
+Note on Windows usage: you should use Git with the provided msysGit shell (Unix style), it allows to use the complex lines of command given in this book. If you need, for some reason, to use the native Windows shell / command line console, you have to use double quotes instead of single quotes (for parameters with spaces in them) and you must quote the parameters ending with the circumflex accent (^) if they are last on the line, as it is a continuation symbol in Windows.
+
+## First-Time Git Setup ##
+
+Now that you have Git on your system, you’ll want to do a few things to customize your Git environment. You should have to do these things only once; they’ll stick around between upgrades. You can also change them at any time by running through the commands again.
+
+Git comes with a tool called `git config` that lets you get and set configuration variables that control all aspects of how Git looks and operates. These variables can be stored in three different places:
+
+*	`/etc/gitconfig` file: Contains values for every user on the system and all their repositories. If you pass the option` --system` to `git config`, it reads and writes from this file specifically.
+*	`~/.gitconfig` file: Specific to your user. You can make Git read and write to this file specifically by passing the `--global` option.
+*	config file in the Git directory (that is, `.git/config`) of whatever repository you’re currently using: Specific to that single repository. Each level overrides values in the previous level, so values in `.git/config` trump those in `/etc/gitconfig`.
+
+On Windows systems, Git looks for the `.gitconfig` file in the `$HOME` directory (`%USERPROFILE%` in Windows’ environment), which is `C:\Documents and Settings\$USER` or `C:\Users\$USER` for most people, depending on version (`$USER` is `%USERNAME%` in Windows’ environment). It also still looks for /etc/gitconfig, although it’s relative to the MSys root, which is wherever you decide to install Git on your Windows system when you run the installer.
+
+### Your Identity ###
+
+The first thing you should do when you install Git is to set your user name and e-mail address. This is important because every Git commit uses this information, and it’s immutably baked into the commits you pass around:
+
+	$ git config --global user.name "John Doe"
+	$ git config --global user.email johndoe@example.com
+
+Again, you need to do this only once if you pass the `--global` option, because then Git will always use that information for anything you do on that system. If you want to override this with a different name or e-mail address for specific projects, you can run the command without the `--global` option when you’re in that project.
+
+### Your Editor ###
+
+Now that your identity is set up, you can configure the default text editor that will be used when Git needs you to type in a message. By default, Git uses your system’s default editor, which is generally Vi or Vim. If you want to use a different text editor, such as Emacs, you can do the following:
+
+	$ git config --global core.editor emacs
+
+### Your Diff Tool ###
+
+Another useful option you may want to configure is the default diff tool to use to resolve merge conflicts. Say you want to use vimdiff:
+
+	$ git config --global merge.tool vimdiff
+
+Git accepts kdiff3, tkdiff, meld, xxdiff, emerge, vimdiff, gvimdiff, ecmerge, and opendiff as valid merge tools. You can also set up a custom tool; see Chapter 7 for more information about doing that.
+
+### Checking Your Settings ###
+
+If you want to check your settings, you can use the `git config --list` command to list all the settings Git can find at that point:
+
+	$ git config --list
+	user.name=Scott Chacon
+	user.email=schacon@gmail.com
+	color.status=auto
+	color.branch=auto
+	color.interactive=auto
+	color.diff=auto
+	...
+
+You may see keys more than once, because Git reads the same key from different files (`/etc/gitconfig` and `~/.gitconfig`, for example). In this case, Git uses the last value for each unique key it sees.
+
+You can also check what Git thinks a specific key’s value is by typing `git config {key}`:
+
+	$ git config user.name
+	Scott Chacon
+
+## Getting Help ##
+
+If you ever need help while using Git, there are three ways to get the manual page (manpage) help for any of the Git commands:
+
+	$ git help <verb>
+	$ git <verb> --help
+	$ man git-<verb>
+
+For example, you can get the manpage help for the config command by running
+
+	$ git help config
+
+These commands are nice because you can access them anywhere, even offline.
+If the manpages and this book aren’t enough and you need in-person help, you can try the `#git` or `#github` channel on the Freenode IRC server (irc.freenode.net). These channels are regularly filled with hundreds of people who are all very knowledgeable about Git and are often willing to help.
+
+## Summary ##
+
+You should have a basic understanding of what Git is and how it’s different from the CVCS you may have been using. You should also now have a working version of Git on your system that’s set up with your personal identity. It’s now time to learn some Git basics.
diff --git a/fa/README.md b/fa/README.md
new file mode 100644
index 000000000..936a0ec43
--- /dev/null
+++ b/fa/README.md
@@ -0,0 +1,7 @@
+# تلاش برای ترجمه فارسی #
+
+
+## لیست افراد حاضر در این پروژه ##
+
+اگر شما هم بر روی این ترجمه کار میکنید یا در نظر دارید  که این کار را شروع  کنید لطفآ به ما اطلاع دهید تا از دوباره کاری پرهیز شود .
+

From 9d03a436893932f0f16e38c26351851c9ffe1e67 Mon Sep 17 00:00:00 2001
From: okhtayaz <okhtay@gmail.com>
Date: Fri, 18 Jul 2014 11:16:20 -0700
Subject: [PATCH 515/690] chapter 1 progressing, chapter 3 started

---
 fa/01-introduction/01-chapter1.markdown  |   7 +-
 fa/03-git-branching/01-chapter3.markdown | 608 +++++++++++++++++++++++
 2 files changed, 613 insertions(+), 2 deletions(-)
 create mode 100644 fa/03-git-branching/01-chapter3.markdown

diff --git a/fa/01-introduction/01-chapter1.markdown b/fa/01-introduction/01-chapter1.markdown
index 11b5b2d71..0bab2f4a4 100644
--- a/fa/01-introduction/01-chapter1.markdown
+++ b/fa/01-introduction/01-chapter1.markdown
@@ -7,9 +7,12 @@
 ## درباره کنترل نسخه ##
 
 کنترل نسخه چیست، و چرا باید برای شما اهمیتی داشته باشد؟ کنترل نسخه سیستمی ست که تغییرات ایجاد شده در یک فایل یا مجموعه ای از فایلها را در طول زمان ثبت میکند تا شما بتوانید نسخه مشخصی از آنها را بعدا بازخوانی کنید. 
- Even though the examples in this book show software source code as the files under version control, in reality any type of file on a computer can be placed under version control.
+ هر چند مثالهای این کتاب کدهای نرم افزاری را به عنوان فایلهای تحت کنترل نسخه نشان میدهند, در واقع هر نوع فایلی بر روی رایانه میتواند تحت کنترل نسخه قرار بگیرد.
 
-If you are a graphic or web designer and want to keep every version of an image or layout (which you certainly would), it is very wise to use a Version Control System (VCS). A VCS allows you to: revert files back to a previous state, revert the entire project back to a previous state, review changes made over time, see who last modified something that might be causing a problem, who introduced an issue and when, and more. Using a VCS also means that if you screw things up or lose files, you can generally recover easily. In addition, you get all this for very little overhead.
+
+اگر شما طراح  گرافیکی یا طراح  وب هستید و میخواهید که تمام نسخه های یک تصویر یا طرح را نگاه دارد (که معمولا هم همینطور است), استفاده از یک سیستم کنترل نسخه کار معقولی خواهد بود.
+
+A VCS allows you to: revert files back to a previous state, revert the entire project back to a previous state, review changes made over time, see who last modified something that might be causing a problem, who introduced an issue and when, and more. Using a VCS also means that if you screw things up or lose files, you can generally recover easily. In addition, you get all this for very little overhead.
 
 ### Local Version Control Systems ###
 
diff --git a/fa/03-git-branching/01-chapter3.markdown b/fa/03-git-branching/01-chapter3.markdown
new file mode 100644
index 000000000..f5e2663bd
--- /dev/null
+++ b/fa/03-git-branching/01-chapter3.markdown
@@ -0,0 +1,608 @@
+# Git Branching #
+
+تقریبا تمام انواع VCS نوعی از انشعاب را پشتیبانی میکنند.
+
+Nearly every VCS has some form of branching support. Branching means you diverge from the main line of development and continue to do work without messing with that main line. In many VCS tools, this is a somewhat expensive process, often requiring you to create a new copy of your source code directory, which can take a long time for large projects.
+
+Some people refer to the branching model in Git as its “killer feature”  , and it certainly sets Git apart in the VCS community. Why is it so special? The way Git branches is incredibly lightweight, making branching operations nearly instantaneous and switching back and forth between branches generally just as fast. Unlike many other VCSs, Git encourages a workflow that branches and merges often, even multiple times in a day. Understanding and mastering this feature gives you a powerful and unique tool and can literally change the way that you develop.
+
+## What a Branch Is ##
+
+To really understand the way Git does branching, we need to take a step back and examine how Git stores its data. As you may remember from Chapter 1, Git doesn’t store data as a series of changesets or deltas, but instead as a series of snapshots.
+
+When you commit in Git, Git stores a commit object that contains a pointer to the snapshot of the content you staged, the author and message metadata, and zero or more pointers to the commit or commits that were the direct parents of this commit: zero parents for the first commit, one parent for a normal commit, and multiple parents for a commit that results from a merge of two or more branches.
+
+To visualize this, let’s assume that you have a directory containing three files, and you stage them all and commit. Staging the files checksums each one (the SHA-1 hash we mentioned in Chapter 1), stores that version of the file in the Git repository (Git refers to them as blobs), and adds that checksum to the staging area:
+
+	$ git add README test.rb LICENSE
+	$ git commit -m 'initial commit of my project'
+
+Running `git commit` checksums all project directories and stores them as `tree` objects in the Git repository. Git then creates a `commit` object that has the metadata and a pointer to the root project `tree` object so it can re-create that snapshot when needed.
+
+Your Git repository now contains five objects: one blob for the contents of each of your three files, one tree that lists the contents of the directory and specifies which file names are stored as which blobs, and one commit with the pointer to that root tree and all the commit metadata. Conceptually, the data in your Git repository looks something like Figure 3-1.
+
+Insert 18333fig0301.png
+Figure 3-1. Single commit repository data.
+
+If you make some changes and commit again, the next commit stores a pointer to the commit that came immediately before it. After two more commits, your history might look something like Figure 3-2.
+
+Insert 18333fig0302.png
+Figure 3-2. Git object data for multiple commits.
+
+A branch in Git is simply a lightweight movable pointer to one of these commits. The default branch name in Git is master. As you initially make commits, you’re given a `master` branch that points to the last commit you made. Every time you commit, it moves forward automatically.
+
+Insert 18333fig0303.png
+Figure 3-3. Branch pointing into the commit data’s history.
+
+What happens if you create a new branch? Well, doing so creates a new pointer for you to move around. Let’s say you create a new branch called testing. You do this with the `git branch` command:
+
+	$ git branch testing
+
+This creates a new pointer at the same commit you’re currently on (see Figure 3-4).
+
+Insert 18333fig0304.png
+Figure 3-4. Multiple branches pointing into the commit’s data history.
+
+How does Git know what branch you’re currently on? It keeps a special pointer called HEAD. Note that this is a lot different than the concept of HEAD in other VCSs you may be used to, such as Subversion or CVS. In Git, this is a pointer to the local branch you’re currently on. In this case, you’re still on master. The `git branch` command only created a new branch — it didn’t switch to that branch (see Figure 3-5).
+
+Insert 18333fig0305.png
+Figure 3-5. HEAD file pointing to the branch you’re on.
+
+To switch to an existing branch, you run the `git checkout` command. Let’s switch to the new testing branch:
+
+	$ git checkout testing
+
+This moves HEAD to point to the testing branch (see Figure 3-6).
+
+Insert 18333fig0306.png
+Figure 3-6. HEAD points to another branch when you switch branches.
+
+What is the significance of that? Well, let’s do another commit:
+
+	$ vim test.rb
+	$ git commit -a -m 'made a change'
+
+Figure 3-7 illustrates the result.
+
+Insert 18333fig0307.png
+Figure 3-7. The branch that HEAD points to moves forward with each commit.
+
+This is interesting, because now your testing branch has moved forward, but your `master` branch still points to the commit you were on when you ran `git checkout` to switch branches. Let’s switch back to the `master` branch:
+
+	$ git checkout master
+
+Figure 3-8 shows the result.
+
+Insert 18333fig0308.png
+Figure 3-8. HEAD moves to another branch on a checkout.
+
+That command did two things. It moved the HEAD pointer back to point to the `master` branch, and it reverted the files in your working directory back to the snapshot that `master` points to. This also means the changes you make from this point forward will diverge from an older version of the project. It essentially rewinds the work you’ve done in your testing branch temporarily so you can go in a different direction.
+
+Let’s make a few changes and commit again:
+
+	$ vim test.rb
+	$ git commit -a -m 'made other changes'
+
+Now your project history has diverged (see Figure 3-9). You created and switched to a branch, did some work on it, and then switched back to your main branch and did other work. Both of those changes are isolated in separate branches: you can switch back and forth between the branches and merge them together when you’re ready. And you did all that with simple `branch` and `checkout` commands.
+
+Insert 18333fig0309.png
+Figure 3-9. The branch histories have diverged.
+
+Because a branch in Git is in actuality a simple file that contains the 40 character SHA-1 checksum of the commit it points to, branches are cheap to create and destroy. Creating a new branch is as quick and simple as writing 41 bytes to a file (40 characters and a newline).
+
+This is in sharp contrast to the way most VCS tools branch, which involves copying all of the project’s files into a second directory. This can take several seconds or even minutes, depending on the size of the project, whereas in Git the process is always instantaneous. Also, because we’re recording the parents when we commit, finding a proper merge base for merging is automatically done for us and is generally very easy to do. These features help encourage developers to create and use branches often.
+
+Let’s see why you should do so.
+
+## Basic Branching and Merging ##
+
+Let’s go through a simple example of branching and merging with a workflow that you might use in the real world. You’ll follow these steps:
+
+1. Do work on a web site.
+2. Create a branch for a new story you’re working on.
+3. Do some work in that branch.
+
+At this stage, you’ll receive a call that another issue is critical and you need a hotfix. You’ll do the following:
+
+1. Switch back to your production branch.
+2. Create a branch to add the hotfix.
+3. After it’s tested, merge the hotfix branch, and push to production.
+4. Switch back to your original story and continue working.
+
+### Basic Branching ###
+
+First, let’s say you’re working on your project and have a couple of commits already (see Figure 3-10).
+
+Insert 18333fig0310.png
+Figure 3-10. A short and simple commit history.
+
+You’ve decided that you’re going to work on issue #53 in whatever issue-tracking system your company uses. To be clear, Git isn’t tied into any particular issue-tracking system; but because issue #53 is a focused topic that you want to work on, you’ll create a new branch in which to work. To create a branch and switch to it at the same time, you can run the `git checkout` command with the `-b` switch:
+
+	$ git checkout -b iss53
+	Switched to a new branch 'iss53'
+
+This is shorthand for:
+
+	$ git branch iss53
+	$ git checkout iss53
+
+Figure 3-11 illustrates the result.
+
+Insert 18333fig0311.png
+Figure 3-11. Creating a new branch pointer.
+
+You work on your web site and do some commits. Doing so moves the `iss53` branch forward, because you have it checked out (that is, your HEAD is pointing to it; see Figure 3-12):
+
+	$ vim index.html
+	$ git commit -a -m 'added a new footer [issue 53]'
+
+Insert 18333fig0312.png
+Figure 3-12. The iss53 branch has moved forward with your work.
+
+Now you get the call that there is an issue with the web site, and you need to fix it immediately. With Git, you don’t have to deploy your fix along with the `iss53` changes you’ve made, and you don’t have to put a lot of effort into reverting those changes before you can work on applying your fix to what is in production. All you have to do is switch back to your master branch.
+
+However, before you do that, note that if your working directory or staging area has uncommitted changes that conflict with the branch you’re checking out, Git won’t let you switch branches. It’s best to have a clean working state when you switch branches. There are ways to get around this (namely, stashing and commit amending) that we’ll cover later. For now, you’ve committed all your changes, so you can switch back to your master branch:
+
+	$ git checkout master
+	Switched to branch 'master'
+
+At this point, your project working directory is exactly the way it was before you started working on issue #53, and you can concentrate on your hotfix. This is an important point to remember: Git resets your working directory to look like the snapshot of the commit that the branch you check out points to. It adds, removes, and modifies files automatically to make sure your working copy is what the branch looked like on your last commit to it.
+
+Next, you have a hotfix to make. Let’s create a hotfix branch on which to work until it’s completed (see Figure 3-13):
+
+	$ git checkout -b hotfix
+	Switched to a new branch 'hotfix'
+	$ vim index.html
+	$ git commit -a -m 'fixed the broken email address'
+	[hotfix 3a0874c] fixed the broken email address
+	 1 files changed, 1 deletion(-)
+
+Insert 18333fig0313.png
+Figure 3-13. hotfix branch based back at your master branch point.
+
+You can run your tests, make sure the hotfix is what you want, and merge it back into your master branch to deploy to production. You do this with the `git merge` command:
+
+	$ git checkout master
+	$ git merge hotfix
+	Updating f42c576..3a0874c
+	Fast-forward
+	 README | 1 -
+	 1 file changed, 1 deletion(-)
+
+You’ll notice the phrase "Fast-forward" in that merge. Because the commit pointed to by the branch you merged in was directly upstream of the commit you’re on, Git moves the pointer forward. To phrase that another way, when you try to merge one commit with a commit that can be reached by following the first commit’s history, Git simplifies things by moving the pointer forward because there is no divergent work to merge together — this is called a "fast forward".
+
+Your change is now in the snapshot of the commit pointed to by the `master` branch, and you can deploy your change (see Figure 3-14).
+
+Insert 18333fig0314.png
+Figure 3-14. Your master branch points to the same place as your hotfix branch after the merge.
+
+After your super-important fix is deployed, you’re ready to switch back to the work you were doing before you were interrupted. However, first you’ll delete the `hotfix` branch, because you no longer need it — the `master` branch points at the same place. You can delete it with the `-d` option to `git branch`:
+
+	$ git branch -d hotfix
+	Deleted branch hotfix (was 3a0874c).
+
+Now you can switch back to your work-in-progress branch on issue #53 and continue working on it (see Figure 3-15):
+
+	$ git checkout iss53
+	Switched to branch 'iss53'
+	$ vim index.html
+	$ git commit -a -m 'finished the new footer [issue 53]'
+	[iss53 ad82d7a] finished the new footer [issue 53]
+	 1 file changed, 1 insertion(+)
+
+Insert 18333fig0315.png
+Figure 3-15. Your iss53 branch can move forward independently.
+
+It’s worth noting here that the work you did in your `hotfix` branch is not contained in the files in your `iss53` branch. If you need to pull it in, you can merge your `master` branch into your `iss53` branch by running `git merge master`, or you can wait to integrate those changes until you decide to pull the `iss53` branch back into `master` later.
+
+### Basic Merging ###
+
+Suppose you’ve decided that your issue #53 work is complete and ready to be merged into your `master` branch. In order to do that, you’ll merge in your `iss53` branch, much like you merged in your `hotfix` branch earlier. All you have to do is check out the branch you wish to merge into and then run the `git merge` command:
+
+	$ git checkout master
+	$ git merge iss53
+	Auto-merging README
+	Merge made by the 'recursive' strategy.
+	 README | 1 +
+	 1 file changed, 1 insertion(+)
+
+This looks a bit different than the `hotfix` merge you did earlier. In this case, your development history has diverged from some older point. Because the commit on the branch you’re on isn’t a direct ancestor of the branch you’re merging in, Git has to do some work. In this case, Git does a simple three-way merge, using the two snapshots pointed to by the branch tips and the common ancestor of the two. Figure 3-16 highlights the three snapshots that Git uses to do its merge in this case.
+
+Insert 18333fig0316.png
+Figure 3-16. Git automatically identifies the best common-ancestor merge base for branch merging.
+
+Instead of just moving the branch pointer forward, Git creates a new snapshot that results from this three-way merge and automatically creates a new commit that points to it (see Figure 3-17). This is referred to as a merge commit and is special in that it has more than one parent.
+
+It’s worth pointing out that Git determines the best common ancestor to use for its merge base; this is different than CVS or Subversion (before version 1.5), where the developer doing the merge has to figure out the best merge base for themselves. This makes merging a heck of a lot easier in Git than in these other systems.
+
+Insert 18333fig0317.png
+Figure 3-17. Git automatically creates a new commit object that contains the merged work.
+
+Now that your work is merged in, you have no further need for the `iss53` branch. You can delete it and then manually close the ticket in your ticket-tracking system:
+
+	$ git branch -d iss53
+
+### Basic Merge Conflicts ###
+
+Occasionally, this process doesn’t go smoothly. If you changed the same part of the same file differently in the two branches you’re merging together, Git won’t be able to merge them cleanly. If your fix for issue #53 modified the same part of a file as the `hotfix`, you’ll get a merge conflict that looks something like this:
+
+	$ git merge iss53
+	Auto-merging index.html
+	CONFLICT (content): Merge conflict in index.html
+	Automatic merge failed; fix conflicts and then commit the result.
+
+Git hasn’t automatically created a new merge commit. It has paused the process while you resolve the conflict. If you want to see which files are unmerged at any point after a merge conflict, you can run `git status`:
+
+	$ git status
+	On branch master
+	You have unmerged paths.
+	  (fix conflicts and run "git commit")
+	
+	Unmerged paths:
+	  (use "git add <file>..." to mark resolution)
+	
+	        both modified:      index.html
+	
+	no changes added to commit (use "git add" and/or "git commit -a")
+
+Anything that has merge conflicts and hasn’t been resolved is listed as unmerged. Git adds standard conflict-resolution markers to the files that have conflicts, so you can open them manually and resolve those conflicts. Your file contains a section that looks something like this:
+
+	<<<<<<< HEAD
+	<div id="footer">contact : email.support@github.com</div>
+	=======
+	<div id="footer">
+	  please contact us at support@github.com
+	</div>
+	>>>>>>> iss53
+
+This means the version in HEAD (your master branch, because that was what you had checked out when you ran your merge command) is the top part of that block (everything above the `=======`), while the version in your `iss53` branch looks like everything in the bottom part. In order to resolve the conflict, you have to either choose one side or the other or merge the contents yourself. For instance, you might resolve this conflict by replacing the entire block with this:
+
+	<div id="footer">
+	please contact us at email.support@github.com
+	</div>
+
+This resolution has a little of each section, and I’ve fully removed the `<<<<<<<`, `=======`, and `>>>>>>>` lines. After you’ve resolved each of these sections in each conflicted file, run `git add` on each file to mark it as resolved. Staging the file marks it as resolved in Git.
+If you want to use a graphical tool to resolve these issues, you can run `git mergetool`, which fires up an appropriate visual merge tool and walks you through the conflicts:
+
+	$ git mergetool
+
+	This message is displayed because 'merge.tool' is not configured.
+	See 'git mergetool --tool-help' or 'git help config' for more details.
+	'git mergetool' will now attempt to use one of the following tools:
+	opendiff kdiff3 tkdiff xxdiff meld tortoisemerge gvimdiff diffuse diffmerge ecmerge p4merge araxis bc3 codecompare vimdiff emerge
+	Merging:
+	index.html
+
+	Normal merge conflict for 'index.html':
+	  {local}: modified file
+	  {remote}: modified file
+	Hit return to start merge resolution tool (opendiff):
+
+If you want to use a merge tool other than the default (Git chose `opendiff` for me in this case because I ran the command on a Mac), you can see all the supported tools listed at the top after “... one of the following tools:”. Type the name of the tool you’d rather use. In Chapter 7, we’ll discuss how you can change this default value for your environment.
+
+After you exit the merge tool, Git asks you if the merge was successful. If you tell the script that it was, it stages the file to mark it as resolved for you.
+
+You can run `git status` again to verify that all conflicts have been resolved:
+
+	$ git status
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        modified:   index.html
+	
+
+If you’re happy with that, and you verify that everything that had conflicts has been staged, you can type `git commit` to finalize the merge commit. The commit message by default looks something like this:
+
+	Merge branch 'iss53'
+
+	Conflicts:
+	  index.html
+	#
+	# It looks like you may be committing a merge.
+	# If this is not correct, please remove the file
+	#       .git/MERGE_HEAD
+	# and try again.
+	#
+
+You can modify that message with details about how you resolved the merge if you think it would be helpful to others looking at this merge in the future — why you did what you did, if it’s not obvious.
+
+## Branch Management ##
+
+Now that you’ve created, merged, and deleted some branches, let’s look at some branch-management tools that will come in handy when you begin using branches all the time.
+
+The `git branch` command does more than just create and delete branches. If you run it with no arguments, you get a simple listing of your current branches:
+
+	$ git branch
+	  iss53
+	* master
+	  testing
+
+Notice the `*` character that prefixes the `master` branch: it indicates the branch that you currently have checked out. This means that if you commit at this point, the `master` branch will be moved forward with your new work. To see the last commit on each branch, you can run `git branch -v`:
+
+	$ git branch -v
+	  iss53   93b412c fix javascript issue
+	* master  7a98805 Merge branch 'iss53'
+	  testing 782fd34 add scott to the author list in the readmes
+
+Another useful option to figure out what state your branches are in is to filter this list to branches that you have or have not yet merged into the branch you’re currently on. There are useful `--merged` and `--no-merged` options available in Git for this purpose. To see which branches are already merged into the branch you’re on, you can run `git branch --merged`:
+
+	$ git branch --merged
+	  iss53
+	* master
+
+Because you already merged in `iss53` earlier, you see it in your list. Branches on this list without the `*` in front of them are generally fine to delete with `git branch -d`; you’ve already incorporated their work into another branch, so you’re not going to lose anything.
+
+To see all the branches that contain work you haven’t yet merged in, you can run `git branch --no-merged`:
+
+	$ git branch --no-merged
+	  testing
+
+This shows your other branch. Because it contains work that isn’t merged in yet, trying to delete it with `git branch -d` will fail:
+
+	$ git branch -d testing
+	error: The branch 'testing' is not fully merged.
+	If you are sure you want to delete it, run 'git branch -D testing'.
+
+If you really do want to delete the branch and lose that work, you can force it with `-D`, as the helpful message points out.
+
+## Branching Workflows ##
+
+Now that you have the basics of branching and merging down, what can or should you do with them? In this section, we’ll cover some common workflows that this lightweight branching makes possible, so you can decide if you would like to incorporate it into your own development cycle.
+
+### Long-Running Branches ###
+
+Because Git uses a simple three-way merge, merging from one branch into another multiple times over a long period is generally easy to do. This means you can have several branches that are always open and that you use for different stages of your development cycle; you can merge regularly from some of them into others.
+
+Many Git developers have a workflow that embraces this approach, such as having only code that is entirely stable in their `master` branch — possibly only code that has been or will be released. They have another parallel branch named develop or next that they work from or use to test stability — it isn’t necessarily always stable, but whenever it gets to a stable state, it can be merged into `master`. It’s used to pull in topic branches (short-lived branches, like your earlier `iss53` branch) when they’re ready, to make sure they pass all the tests and don’t introduce bugs.
+
+In reality, we’re talking about pointers moving up the line of commits you’re making. The stable branches are farther down the line in your commit history, and the bleeding-edge branches are farther up the history (see Figure 3-18).
+
+Insert 18333fig0318.png
+Figure 3-18. More stable branches are generally farther down the commit history.
+
+It’s generally easier to think about them as work silos, where sets of commits graduate to a more stable silo when they’re fully tested (see Figure 3-19).
+
+Insert 18333fig0319.png
+Figure 3-19. It may be helpful to think of your branches as silos.
+
+You can keep doing this for several levels of stability. Some larger projects also have a `proposed` or `pu` (proposed updates) branch that has integrated branches that may not be ready to go into the `next` or `master` branch. The idea is that your branches are at various levels of stability; when they reach a more stable level, they’re merged into the branch above them.
+Again, having multiple long-running branches isn’t necessary, but it’s often helpful, especially when you’re dealing with very large or complex projects.
+
+### Topic Branches ###
+
+Topic branches, however, are useful in projects of any size. A topic branch is a short-lived branch that you create and use for a single particular feature or related work. This is something you’ve likely never done with a VCS before because it’s generally too expensive to create and merge branches. But in Git it’s common to create, work on, merge, and delete branches several times a day.
+
+You saw this in the last section with the `iss53` and `hotfix` branches you created. You did a few commits on them and deleted them directly after merging them into your main branch. This technique allows you to context-switch quickly and completely — because your work is separated into silos where all the changes in that branch have to do with that topic, it’s easier to see what has happened during code review and such. You can keep the changes there for minutes, days, or months, and merge them in when they’re ready, regardless of the order in which they were created or worked on.
+
+Consider an example of doing some work (on `master`), branching off for an issue (`iss91`), working on it for a bit, branching off the second branch to try another way of handling the same thing (`iss91v2`), going back to your master branch and working there for a while, and then branching off there to do some work that you’re not sure is a good idea (`dumbidea` branch). Your commit history will look something like Figure 3-20.
+
+Insert 18333fig0320.png
+Figure 3-20. Your commit history with multiple topic branches.
+
+Now, let’s say you decide you like the second solution to your issue best (`iss91v2`); and you showed the `dumbidea` branch to your coworkers, and it turns out to be genius. You can throw away the original `iss91` branch (losing commits C5 and C6) and merge in the other two. Your history then looks like Figure 3-21.
+
+Insert 18333fig0321.png
+Figure 3-21. Your history after merging in dumbidea and iss91v2.
+
+It’s important to remember when you’re doing all this that these branches are completely local. When you’re branching and merging, everything is being done only in your Git repository — no server communication is happening.
+
+## Remote Branches ##
+
+Remote branches are references to the state of branches on your remote repositories. They’re local branches that you can’t move; they’re moved automatically whenever you do any network communication. Remote branches act as bookmarks to remind you where the branches on your remote repositories were the last time you connected to them.
+
+They take the form `(remote)/(branch)`. For instance, if you wanted to see what the `master` branch on your `origin` remote looked like as of the last time you communicated with it, you would check the `origin/master` branch. If you were working on an issue with a partner and they pushed up an `iss53` branch, you might have your own local `iss53` branch; but the branch on the server would point to the commit at `origin/iss53`.
+
+This may be a bit confusing, so let’s look at an example. Let’s say you have a Git server on your network at `git.ourcompany.com`. If you clone from this, Git automatically names it `origin` for you, pulls down all its data, creates a pointer to where its `master` branch is, and names it `origin/master` locally; and you can’t move it. Git also gives you your own `master` branch starting at the same place as origin’s `master` branch, so you have something to work from (see Figure 3-22).
+
+Insert 18333fig0322.png
+Figure 3-22. A Git clone gives you your own master branch and origin/master pointing to origin’s master branch.
+
+If you do some work on your local master branch, and, in the meantime, someone else pushes to `git.ourcompany.com` and updates its master branch, then your histories move forward differently. Also, as long as you stay out of contact with your origin server, your `origin/master` pointer doesn’t move (see Figure 3-23).
+
+Insert 18333fig0323.png
+Figure 3-23. Working locally and having someone push to your remote server makes each history move forward differently.
+
+To synchronize your work, you run a `git fetch origin` command. This command looks up which server origin is (in this case, it’s `git.ourcompany.com`), fetches any data from it that you don’t yet have, and updates your local database, moving your `origin/master` pointer to its new, more up-to-date position (see Figure 3-24).
+
+Insert 18333fig0324.png
+Figure 3-24. The `git fetch` command updates your remote references.
+
+To demonstrate having multiple remote servers and what remote branches for those remote projects look like, let’s assume you have another internal Git server that is used only for development by one of your sprint teams. This server is at `git.team1.ourcompany.com`. You can add it as a new remote reference to the project you’re currently working on by running the `git remote add` command as we covered in Chapter 2. Name this remote `teamone`, which will be your shortname for that whole URL (see Figure 3-25).
+
+Insert 18333fig0325.png
+Figure 3-25. Adding another server as a remote.
+
+Now, you can run `git fetch teamone` to fetch everything the remote `teamone` server has that you don’t have yet. Because that server has a subset of the data your `origin` server has right now, Git fetches no data but sets a remote branch called `teamone/master` to point to the commit that `teamone` has as its `master` branch (see Figure 3-26).
+
+Insert 18333fig0326.png
+Figure 3-26. You get a reference to teamone’s master branch position locally.
+
+### Pushing ###
+
+When you want to share a branch with the world, you need to push it up to a remote that you have write access to. Your local branches aren’t automatically synchronized to the remotes you write to — you have to explicitly push the branches you want to share. That way, you can use private branches for work you don’t want to share, and push up only the topic branches you want to collaborate on.
+
+If you have a branch named `serverfix` that you want to work on with others, you can push it up the same way you pushed your first branch. Run `git push (remote) (branch)`:
+
+	$ git push origin serverfix
+	Counting objects: 20, done.
+	Compressing objects: 100% (14/14), done.
+	Writing objects: 100% (15/15), 1.74 KiB, done.
+	Total 15 (delta 5), reused 0 (delta 0)
+	To git@github.com:schacon/simplegit.git
+	 * [new branch]      serverfix -> serverfix
+
+This is a bit of a shortcut. Git automatically expands the `serverfix` branchname out to `refs/heads/serverfix:refs/heads/serverfix`, which means, “Take my serverfix local branch and push it to update the remote’s serverfix branch.” We’ll go over the `refs/heads/` part in detail in Chapter 9, but you can generally leave it off. You can also do `git push origin serverfix:serverfix`, which does the same thing — it says, “Take my serverfix and make it the remote’s serverfix.” You can use this format to push a local branch into a remote branch that is named differently. If you didn’t want it to be called `serverfix` on the remote, you could instead run `git push origin serverfix:awesomebranch` to push your local `serverfix` branch to the `awesomebranch` branch on the remote project.
+
+The next time one of your collaborators fetches from the server, they will get a reference to where the server’s version of `serverfix` is under the remote branch `origin/serverfix`:
+
+	$ git fetch origin
+	remote: Counting objects: 20, done.
+	remote: Compressing objects: 100% (14/14), done.
+	remote: Total 15 (delta 5), reused 0 (delta 0)
+	Unpacking objects: 100% (15/15), done.
+	From git@github.com:schacon/simplegit
+	 * [new branch]      serverfix    -> origin/serverfix
+
+It’s important to note that when you do a fetch that brings down new remote branches, you don’t automatically have local, editable copies of them. In other words, in this case, you don’t have a new `serverfix` branch — you only have an `origin/serverfix` pointer that you can’t modify.
+
+To merge this work into your current working branch, you can run `git merge origin/serverfix`. If you want your own `serverfix` branch that you can work on, you can base it off your remote branch:
+
+	$ git checkout -b serverfix origin/serverfix
+	Branch serverfix set up to track remote branch serverfix from origin.
+	Switched to a new branch 'serverfix'
+
+This gives you a local branch that you can work on that starts where `origin/serverfix` is.
+
+### Tracking Branches ###
+
+Checking out a local branch from a remote branch automatically creates what is called a _tracking branch_. Tracking branches are local branches that have a direct relationship to a remote branch. If you’re on a tracking branch and type `git push`, Git automatically knows which server and branch to push to. Also, running `git pull` while on one of these branches fetches all the remote references and then automatically merges in the corresponding remote branch.
+
+When you clone a repository, it generally automatically creates a `master` branch that tracks `origin/master`. That’s why `git push` and `git pull` work out of the box with no other arguments. However, you can set up other tracking branches if you wish — ones that don’t track branches on `origin` and don’t track the `master` branch. The simple case is the example you just saw, running `git checkout -b [branch] [remotename]/[branch]`. If you have Git version 1.6.2 or later, you can also use the `--track` shorthand:
+
+	$ git checkout --track origin/serverfix
+	Branch serverfix set up to track remote branch serverfix from origin.
+	Switched to a new branch 'serverfix'
+
+To set up a local branch with a different name than the remote branch, you can easily use the first version with a different local branch name:
+
+	$ git checkout -b sf origin/serverfix
+	Branch sf set up to track remote branch serverfix from origin.
+	Switched to a new branch 'sf'
+
+Now, your local branch `sf` will automatically push to and pull from `origin/serverfix`.
+
+### Deleting Remote Branches ###
+
+Suppose you’re done with a remote branch — say, you and your collaborators are finished with a feature and have merged it into your remote’s `master` branch (or whatever branch your stable codeline is in). You can delete a remote branch using the rather obtuse syntax `git push [remotename] :[branch]`. If you want to delete your `serverfix` branch from the server, you run the following:
+
+	$ git push origin :serverfix
+	To git@github.com:schacon/simplegit.git
+	 - [deleted]         serverfix
+
+Boom. No more branch on your server. You may want to dog-ear this page, because you’ll need that command, and you’ll likely forget the syntax. A way to remember this command is by recalling the `git push [remotename] [localbranch]:[remotebranch]` syntax that we went over a bit earlier. If you leave off the `[localbranch]` portion, then you’re basically saying, “Take nothing on my side and make it be `[remotebranch]`.”
+
+## Rebasing ##
+
+In Git, there are two main ways to integrate changes from one branch into another: the `merge` and the `rebase`. In this section you’ll learn what rebasing is, how to do it, why it’s a pretty amazing tool, and in what cases you won’t want to use it.
+
+### The Basic Rebase ###
+
+If you go back to an earlier example from the Merge section (see Figure 3-27), you can see that you diverged your work and made commits on two different branches.
+
+Insert 18333fig0327.png
+Figure 3-27. Your initial diverged commit history.
+
+The easiest way to integrate the branches, as we’ve already covered, is the `merge` command. It performs a three-way merge between the two latest branch snapshots (C3 and C4) and the most recent common ancestor of the two (C2), creating a new snapshot (and commit), as shown in Figure 3-28.
+
+Insert 18333fig0328.png
+Figure 3-28. Merging a branch to integrate the diverged work history.
+
+However, there is another way: you can take the patch of the change that was introduced in C3 and reapply it on top of C4. In Git, this is called _rebasing_. With the `rebase` command, you can take all the changes that were committed on one branch and replay them on another one.
+
+In this example, you’d run the following:
+
+	$ git checkout experiment
+	$ git rebase master
+	First, rewinding head to replay your work on top of it...
+	Applying: added staged command
+
+It works by going to the common ancestor of the two branches (the one you’re on and the one you’re rebasing onto), getting the diff introduced by each commit of the branch you’re on, saving those diffs to temporary files, resetting the current branch to the same commit as the branch you are rebasing onto, and finally applying each change in turn. Figure 3-29 illustrates this process.
+
+Insert 18333fig0329.png
+Figure 3-29. Rebasing the change introduced in C3 onto C4.
+
+At this point, you can go back to the master branch and do a fast-forward merge (see Figure 3-30).
+
+Insert 18333fig0330.png
+Figure 3-30. Fast-forwarding the master branch.
+
+Now, the snapshot pointed to by C3' is exactly the same as the one that was pointed to by C5 in the merge example. There is no difference in the end product of the integration, but rebasing makes for a cleaner history. If you examine the log of a rebased branch, it looks like a linear history: it appears that all the work happened in series, even when it originally happened in parallel.
+
+Often, you’ll do this to make sure your commits apply cleanly on a remote branch — perhaps in a project to which you’re trying to contribute but that you don’t maintain. In this case, you’d do your work in a branch and then rebase your work onto `origin/master` when you were ready to submit your patches to the main project. That way, the maintainer doesn’t have to do any integration work — just a fast-forward or a clean apply.
+
+Note that the snapshot pointed to by the final commit you end up with, whether it’s the last of the rebased commits for a rebase or the final merge commit after a merge, is the same snapshot — it’s only the history that is different. Rebasing replays changes from one line of work onto another in the order they were introduced, whereas merging takes the endpoints and merges them together.
+
+### More Interesting Rebases ###
+
+You can also have your rebase replay on something other than the rebase branch. Take a history like Figure 3-31, for example. You branched a topic branch (`server`) to add some server-side functionality to your project, and made a commit. Then, you branched off that to make the client-side changes (`client`) and committed a few times. Finally, you went back to your server branch and did a few more commits.
+
+Insert 18333fig0331.png
+Figure 3-31. A history with a topic branch off another topic branch.
+
+Suppose you decide that you want to merge your client-side changes into your mainline for a release, but you want to hold off on the server-side changes until it’s tested further. You can take the changes on client that aren’t on server (C8 and C9) and replay them on your master branch by using the `--onto` option of `git rebase`:
+
+	$ git rebase --onto master server client
+
+This basically says, “Check out the client branch, figure out the patches from the common ancestor of the `client` and `server` branches, and then replay them onto `master`.” It’s a bit complex; but the result, shown in Figure 3-32, is pretty cool.
+
+Insert 18333fig0332.png
+Figure 3-32. Rebasing a topic branch off another topic branch.
+
+Now you can fast-forward your master branch (see Figure 3-33):
+
+	$ git checkout master
+	$ git merge client
+
+Insert 18333fig0333.png
+Figure 3-33. Fast-forwarding your master branch to include the client branch changes.
+
+Let’s say you decide to pull in your server branch as well. You can rebase the server branch onto the master branch without having to check it out first by running `git rebase [basebranch] [topicbranch]` — which checks out the topic branch (in this case, `server`) for you and replays it onto the base branch (`master`):
+
+	$ git rebase master server
+
+This replays your `server` work on top of your `master` work, as shown in Figure 3-34.
+
+Insert 18333fig0334.png
+Figure 3-34. Rebasing your server branch on top of your master branch.
+
+Then, you can fast-forward the base branch (`master`):
+
+	$ git checkout master
+	$ git merge server
+
+You can remove the `client` and `server` branches because all the work is integrated and you don’t need them anymore, leaving your history for this entire process looking like Figure 3-35:
+
+	$ git branch -d client
+	$ git branch -d server
+
+Insert 18333fig0335.png
+Figure 3-35. Final commit history.
+
+### The Perils of Rebasing ###
+
+Ahh, but the bliss of rebasing isn’t without its drawbacks, which can be summed up in a single line:
+
+**Do not rebase commits that you have pushed to a public repository.**
+
+If you follow that guideline, you’ll be fine. If you don’t, people will hate you, and you’ll be scorned by friends and family.
+
+When you rebase stuff, you’re abandoning existing commits and creating new ones that are similar but different. If you push commits somewhere and others pull them down and base work on them, and then you rewrite those commits with `git rebase` and push them up again, your collaborators will have to re-merge their work and things will get messy when you try to pull their work back into yours.
+
+Let’s look at an example of how rebasing work that you’ve made public can cause problems. Suppose you clone from a central server and then do some work off that. Your commit history looks like Figure 3-36.
+
+Insert 18333fig0336.png
+Figure 3-36. Clone a repository, and base some work on it.
+
+Now, someone else does more work that includes a merge, and pushes that work to the central server. You fetch them and merge the new remote branch into your work, making your history look something like Figure 3-37.
+
+Insert 18333fig0337.png
+Figure 3-37. Fetch more commits, and merge them into your work.
+
+Next, the person who pushed the merged work decides to go back and rebase their work instead; they do a `git push --force` to overwrite the history on the server. You then fetch from that server, bringing down the new commits.
+
+Insert 18333fig0338.png
+Figure 3-38. Someone pushes rebased commits, abandoning commits you’ve based your work on.
+
+At this point, you have to merge this work in again, even though you’ve already done so. Rebasing changes the SHA-1 hashes of these commits so to Git they look like new commits, when in fact you already have the C4 work in your history (see Figure 3-39).
+
+Insert 18333fig0339.png
+Figure 3-39. You merge in the same work again into a new merge commit.
+
+You have to merge that work in at some point so you can keep up with the other developer in the future. After you do that, your commit history will contain both the C4 and C4' commits, which have different SHA-1 hashes but introduce the same work and have the same commit message. If you run a `git log` when your history looks like this, you’ll see two commits that have the same author date and message, which will be confusing. Furthermore, if you push this history back up to the server, you’ll reintroduce all those rebased commits to the central server, which can further confuse people.
+
+If you treat rebasing as a way to clean up and work with commits before you push them, and if you only rebase commits that have never been available publicly, then you’ll be fine. If you rebase commits that have already been pushed publicly, and people may have based work on those commits, then you may be in for some frustrating trouble.
+
+## Summary ##
+
+We’ve covered basic branching and merging in Git. You should feel comfortable creating and switching to new branches, switching between branches and merging local branches together.  You should also be able to share your branches by pushing them to a shared server, working with others on shared branches and rebasing your branches before they are shared.

From 49df6b1c3757e1b03116b22d6613b5f51befb4e1 Mon Sep 17 00:00:00 2001
From: Soon Van <cog@randomecho.com>
Date: Tue, 22 Jul 2014 17:42:15 -0400
Subject: [PATCH 516/690] Update link to download P4Merge tool

---
 az/07-customizing-git/01-chapter7.markdown    | 2 +-
 cs/07-customizing-git/01-chapter7.markdown    | 2 +-
 de/07-customizing-git/01-chapter7.markdown    | 2 +-
 en/07-customizing-git/01-chapter7.markdown    | 4 ++--
 es/07-customizing-git/01-chapter7.markdown    | 2 +-
 es/omegat-Benzirpi.tmx                        | 4 ++--
 fr/07-customizing-git/01-chapter7.markdown    | 2 +-
 it/07-customizing-git/01-chapter7.markdown    | 2 +-
 ja/07-customizing-git/01-chapter7.markdown    | 2 +-
 ko/07-customizing-git/01-chapter7.markdown    | 2 +-
 nl/07-customizing-git/01-chapter7.markdown    | 2 +-
 no-nb/07-customizing-git/01-chapter7.markdown | 2 +-
 pl/07-customizing-git/01-chapter7.markdown    | 2 +-
 pt-br/07-customizing-git/01-chapter7.markdown | 2 +-
 ru/07-customizing-git/01-chapter7.markdown    | 2 +-
 zh-tw/07-customizing-git/01-chapter7.markdown | 2 +-
 zh/07-customizing-git/01-chapter7.markdown    | 2 +-
 17 files changed, 19 insertions(+), 19 deletions(-)

diff --git a/az/07-customizing-git/01-chapter7.markdown b/az/07-customizing-git/01-chapter7.markdown
index 41f5dd33f..c2bb85fc1 100644
--- a/az/07-customizing-git/01-chapter7.markdown
+++ b/az/07-customizing-git/01-chapter7.markdown
@@ -142,7 +142,7 @@ If you want to try this out, P4Merge works on all major platforms, so you should
 
 You can download P4Merge here:
 
-	http://www.perforce.com/perforce/downloads/component.html
+	http://www.perforce.com/product/components/perforce-visual-merge-and-diff-tools
 
 To begin, you’ll set up external wrapper scripts to run your commands. I’ll use the Mac path for the executable; in other systems, it will be where your `p4merge` binary is installed. Set up a merge wrapper script named `extMerge` that calls your binary with all the arguments provided:
 
diff --git a/cs/07-customizing-git/01-chapter7.markdown b/cs/07-customizing-git/01-chapter7.markdown
index 54d0ca3a5..5491834de 100644
--- a/cs/07-customizing-git/01-chapter7.markdown
+++ b/cs/07-customizing-git/01-chapter7.markdown
@@ -142,7 +142,7 @@ Pokud ho chcete vyzkoušet, nemělo by vám v tom nic bránit, P4Merge funguje n
 
 P4Merge můžete stáhnout na této adrese:
 
-	http://www.perforce.com/perforce/downloads/component.html
+	http://www.perforce.com/product/components/perforce-visual-merge-and-diff-tools
 
 Pro začátek je třeba nastavit kvůli spouštění příkazů externí skripty wrapperu. Jako cestu ke spustitelnému souboru používám cestu v systému Mac. V ostatních systémech použijte cestu k umístění, kde máte nainstalován binární soubor `p4merge`. Nastavte wrapperový skript pro slučování `extMerge`, který bude volat binární soubor všemi dostupnými parametry:
 
diff --git a/de/07-customizing-git/01-chapter7.markdown b/de/07-customizing-git/01-chapter7.markdown
index aefff281d..1d9a629d2 100644
--- a/de/07-customizing-git/01-chapter7.markdown
+++ b/de/07-customizing-git/01-chapter7.markdown
@@ -219,7 +219,7 @@ Da P4Merge für die üblichen Plattformen verfügbar ist, sollte es kein Problem
 
 Du kannst P4Merge hier herunterladen:
 
-	http://www.perforce.com/perforce/downloads/component.html
+	http://www.perforce.com/product/components/perforce-visual-merge-and-diff-tools
 
 <!--To begin, you’ll set up external wrapper scripts to run your commands. I’ll use the Mac path for the executable; in other systems, it will be where your `p4merge` binary is installed. Set up a merge wrapper script named `extMerge` that calls your binary with all the arguments provided:-->
 
diff --git a/en/07-customizing-git/01-chapter7.markdown b/en/07-customizing-git/01-chapter7.markdown
index 1a1b7f729..de99afcd7 100644
--- a/en/07-customizing-git/01-chapter7.markdown
+++ b/en/07-customizing-git/01-chapter7.markdown
@@ -4,7 +4,7 @@ So far, I’ve covered the basics of how Git works and how to use it, and I’ve
 
 ## Git Configuration ##
 
-As you briefly saw in the Chapter 1, you can specify Git configuration settings with the `git config` command. One of the first things you did was set up your name and e-mail address:
+As you briefly saw in Chapter 1, you can specify Git configuration settings with the `git config` command. One of the first things you did was set up your name and e-mail address:
 
 	$ git config --global user.name "John Doe"
 	$ git config --global user.email johndoe@example.com
@@ -142,7 +142,7 @@ If you want to try this out, P4Merge works on all major platforms, so you should
 
 You can download P4Merge here:
 
-	http://www.perforce.com/perforce/downloads/component.html
+	http://www.perforce.com/product/components/perforce-visual-merge-and-diff-tools
 
 To begin, you’ll set up external wrapper scripts to run your commands. I’ll use the Mac path for the executable; in other systems, it will be where your `p4merge` binary is installed. Set up a merge wrapper script named `extMerge` that calls your binary with all the arguments provided:
 
diff --git a/es/07-customizing-git/01-chapter7.markdown b/es/07-customizing-git/01-chapter7.markdown
index af19b3cc6..6ac5413f4 100644
--- a/es/07-customizing-git/01-chapter7.markdown
+++ b/es/07-customizing-git/01-chapter7.markdown
@@ -142,7 +142,7 @@ Si lo quieres probar, P4Merge funciona en todas las principales plataformas. Los
 
 P4Merge se puede descargar desde:
 
-	http://www.perforce.com/perforce/downloads/component.html
+	http://www.perforce.com/product/components/perforce-visual-merge-and-diff-tools
 
 Para empezar, tienes que preparar los correspondientes scripts para lanzar tus comandos. En estos ejemplos, voy a utilizar caminos y nombres Mac para los ejecutables; en otros sistemas, tendrás que sustituirlos por los correspondientes donde tengas instalado 'p4merge'. El primer script a preparar es uno al que denominaremos 'extMerge', para llamar al ejecutable con los correspodientes argumentos:
 
diff --git a/es/omegat-Benzirpi.tmx b/es/omegat-Benzirpi.tmx
index 971ad7931..95f49f3b2 100644
--- a/es/omegat-Benzirpi.tmx
+++ b/es/omegat-Benzirpi.tmx
@@ -2369,10 +2369,10 @@ Figura 3-36.</seg>
     </tu>
     <tu>
       <tuv lang="EN">
-        <seg>http://www.perforce.com/perforce/downloads/component.html</seg>
+        <seg>http://www.perforce.com/product/components/perforce-visual-merge-and-diff-tools</seg>
       </tuv>
       <tuv lang="ES">
-        <seg>http://www.perforce.com/perforce/downloads/component.html</seg>
+        <seg>http://www.perforce.com/product/components/perforce-visual-merge-and-diff-tools</seg>
       </tuv>
     </tu>
     <tu>
diff --git a/fr/07-customizing-git/01-chapter7.markdown b/fr/07-customizing-git/01-chapter7.markdown
index e7248a28a..fefd66dcc 100644
--- a/fr/07-customizing-git/01-chapter7.markdown
+++ b/fr/07-customizing-git/01-chapter7.markdown
@@ -177,7 +177,7 @@ Pour Windows, vous devrez changer `/usr/local/bin` en un chemin d'exécution d'u
 
 Vous pouvez télécharger P4Merge ici :
 
-	http://www.perforce.com/perforce/downloads/component.html
+	http://www.perforce.com/product/components/perforce-visual-merge-and-diff-tools
 
 Pour commencer, créez un script d'appel externe pour lancer vos commandes.
 Je vais utiliser le chemin Mac pour l'exécutable ; dans d'autres systèmes, il résidera où votre binaire `p4merge` a été installé.
diff --git a/it/07-customizing-git/01-chapter7.markdown b/it/07-customizing-git/01-chapter7.markdown
index a5e42995a..78b49f917 100644
--- a/it/07-customizing-git/01-chapter7.markdown
+++ b/it/07-customizing-git/01-chapter7.markdown
@@ -142,7 +142,7 @@ Se vuoi provarlo, P4Merge funziona su tutte le maggiori piattaforme, quindi dovr
 
 Puoi scarucare P4Merge qua:
 
-	http://www.perforce.com/perforce/downloads/component.html
+	http://www.perforce.com/product/components/perforce-visual-merge-and-diff-tools
 
 Per iniziare dovrai impostare scripts esterni di wrapping per eseguire i tuoi comandi. Utilizzerò il percorso relativo a Mac per l'eseguibile; in altri sistemi, sarà dove è posizionato il binario `p4merge`. Imposta uno script per il wrapping del merge chiamato `extMerge` che chiami il binario con tutti gli argomenti necessari:
 
diff --git a/ja/07-customizing-git/01-chapter7.markdown b/ja/07-customizing-git/01-chapter7.markdown
index 4050bdcf9..74d0dd626 100644
--- a/ja/07-customizing-git/01-chapter7.markdown
+++ b/ja/07-customizing-git/01-chapter7.markdown
@@ -142,7 +142,7 @@ P4Merge はすべての主要プラットフォーム上で動作するので、
 
 まず、P4Merge をここからダウンロードします。
 
-	http://www.perforce.com/perforce/downloads/component.html
+	http://www.perforce.com/product/components/perforce-visual-merge-and-diff-tools
 
 最初に、コマンドを実行するための外部ラッパースクリプトを用意します。この例では、Mac 用の実行パスを使います。他のシステムで使う場合は、`p4merge` のバイナリがインストールされた場所に置き換えてください。次のようなマージ用ラッパースクリプト `extMerge` を用意しました。これは、すべての引数を受け取ってバイナリをコールします。
 
diff --git a/ko/07-customizing-git/01-chapter7.markdown b/ko/07-customizing-git/01-chapter7.markdown
index 901c2d27c..26a6a4737 100644
--- a/ko/07-customizing-git/01-chapter7.markdown
+++ b/ko/07-customizing-git/01-chapter7.markdown
@@ -142,7 +142,7 @@ P4Merge는 중요 플랫폼을 모두 지원하기 때문에 웬만한 환경이
 
 다음 페이지에서 P4Merge를 내려받는다:
 
-	http://www.perforce.com/perforce/downloads/component.html
+	http://www.perforce.com/product/components/perforce-visual-merge-and-diff-tools
 
 먼저 P4Merge에 쓸 Wrapper 스크립트를 만든다. 필자는 Mac 사용자라서 Mac 경로를 사용한다. 어떤 시스템이든 `p4merge`가 설치된 경로를 사용하면 된다. extMerge라는 Merge용 Wrapper 스크립트를 만들고 이 스크립트로 넘어오는 모든 아규먼트를 p4merge 프로그램으로 넘긴다:
 
diff --git a/nl/07-customizing-git/01-chapter7.markdown b/nl/07-customizing-git/01-chapter7.markdown
index b1bb95223..53edfbce1 100644
--- a/nl/07-customizing-git/01-chapter7.markdown
+++ b/nl/07-customizing-git/01-chapter7.markdown
@@ -178,7 +178,7 @@ Als je dit wilt proberen, P4Merge werkt op alle grote platformen, dus je zou het
 
 Je kunt P4Merge hier downloaden:
 
-	http://www.perforce.com/perforce/downloads/component.html
+	http://www.perforce.com/product/components/perforce-visual-merge-and-diff-tools
 
 Om te beginnen ga je externe wrapper scripts instellen om de commando's uit te voeren. Ik zal het Mac pad gebruiken voor de applicatie; in andere systemen zal het moeten wijzen naar de plaats waar de `p4merge` binary geïnstalleerd is. Maak merge wrapper script, genaamd `extMerge`, die jouw applicatie met alle meegegeven argumenten aanroept:
 
diff --git a/no-nb/07-customizing-git/01-chapter7.markdown b/no-nb/07-customizing-git/01-chapter7.markdown
index 38f7d4562..2a800faf9 100644
--- a/no-nb/07-customizing-git/01-chapter7.markdown
+++ b/no-nb/07-customizing-git/01-chapter7.markdown
@@ -142,7 +142,7 @@ If you want to try this out, P4Merge works on all major platforms, so you should
 
 You can download P4Merge here:
 
-	http://www.perforce.com/perforce/downloads/component.html
+	http://www.perforce.com/product/components/perforce-visual-merge-and-diff-tools
 
 To begin, you’ll set up external wrapper scripts to run your commands. I’ll use the Mac path for the executable; in other systems, it will be where your `p4merge` binary is installed. Set up a merge wrapper script named `extMerge` that calls your binary with all the arguments provided:
 
diff --git a/pl/07-customizing-git/01-chapter7.markdown b/pl/07-customizing-git/01-chapter7.markdown
index be288a25a..f7346cd0d 100644
--- a/pl/07-customizing-git/01-chapter7.markdown
+++ b/pl/07-customizing-git/01-chapter7.markdown
@@ -218,7 +218,7 @@ Możesz pobrać P4Merge stąd:
 
 <!-- You can download P4Merge here: -->
 
-	http://www.perforce.com/perforce/downloads/component.html
+	http://www.perforce.com/product/components/perforce-visual-merge-and-diff-tools
 
 Na początek, ustawimy zewnętrzny skrypt do uruchamiania komend. Użyję ścieżki z systemu Mac wskazującej na program; w innych systemach, będzie ona musiała wskazywać na miejsce w którym program `p4merge` został zainstalowany. Stwórz skrypt o nazwie `extMerge`, który będzie przyjmował wszystkie podane parametry i uruchamiał program:
 
diff --git a/pt-br/07-customizing-git/01-chapter7.markdown b/pt-br/07-customizing-git/01-chapter7.markdown
index c734872e3..47fc4964c 100644
--- a/pt-br/07-customizing-git/01-chapter7.markdown
+++ b/pt-br/07-customizing-git/01-chapter7.markdown
@@ -142,7 +142,7 @@ Se você quiser experimentar, P4Merge funciona em todas as principais plataforma
 
 Você pode baixar P4Merge aqui:
 
-    http://www.perforce.com/perforce/downloads/component.html
+    http://www.perforce.com/product/components/perforce-visual-merge-and-diff-tools
 
 Para começar, você vai configurar um script para executar seus comandos. Vou usar o caminho para o executável Mac; em outros sistemas, este será onde o seu binário do `p4merge` está instalado. Configure um script chamado `extMerge` que chama seu binário com todos os argumentos necessários:
 
diff --git a/ru/07-customizing-git/01-chapter7.markdown b/ru/07-customizing-git/01-chapter7.markdown
index 3fc54cceb..94009ba4a 100644
--- a/ru/07-customizing-git/01-chapter7.markdown
+++ b/ru/07-customizing-git/01-chapter7.markdown
@@ -142,7 +142,7 @@ Git автоматически раскрасит большую часть св
 
 Скачать P4Merge можно здесь:
 
-	http://www.perforce.com/perforce/downloads/component.html
+	http://www.perforce.com/product/components/perforce-visual-merge-and-diff-tools
 
 Для начала сделаем внешние сценарии-обёртки для запуска нужных команд. Я буду использовать Mac'овский путь к исполняемым файлам; для других систем это будет тот путь, куда установлен ваш файл `p4merge`. Сделайте для слияния сценарий-обёртку с именем `extMerge`, он будет вызывать бинарник со всеми переданными аргументами:
 
diff --git a/zh-tw/07-customizing-git/01-chapter7.markdown b/zh-tw/07-customizing-git/01-chapter7.markdown
index e16573d71..a5ead4413 100644
--- a/zh-tw/07-customizing-git/01-chapter7.markdown
+++ b/zh-tw/07-customizing-git/01-chapter7.markdown
@@ -142,7 +142,7 @@ Git 會按照你的需要，自動為大部分的輸出加上顏色。你能明
 
 你可以在這裏下載 P4Merge： 
 
-	http://www.perforce.com/perforce/downloads/component.html
+	http://www.perforce.com/product/components/perforce-visual-merge-and-diff-tools
 
 首先，你要設定一個外部包裝腳本(external wrapper scripts)來執行你要的命令，我會使用 Mac 系統上的路徑來指定該腳本的位置；在其他系統上，它應該被放置在二進位檔案 `p4merge` 所在的目錄中。創建一個 merge 包裝腳本，名字叫作 `extMerge`，讓它附帶所有參數呼叫 p4merge 二進位檔案： 
 
diff --git a/zh/07-customizing-git/01-chapter7.markdown b/zh/07-customizing-git/01-chapter7.markdown
index 564f32c6d..f3e7082a9 100644
--- a/zh/07-customizing-git/01-chapter7.markdown
+++ b/zh/07-customizing-git/01-chapter7.markdown
@@ -142,7 +142,7 @@ P4Merge可以在所有主流平台上运行，现在开始大胆尝试吧。对
 
 下载P4Merge：
 
-	http://www.perforce.com/perforce/downloads/component.html
+	http://www.perforce.com/product/components/perforce-visual-merge-and-diff-tools
 
 首先把你要运行的命令放入外部包装脚本中，我会使用Mac系统上的路径来指定该脚本的位置，在其他系统上，它应该被放置在二进制文件`p4merge`所在的目录中。创建一个merge包装脚本，名字叫作`extMerge`，让它带参数调用`p4merge`二进制文件：
 

From 375f9d876fbf8899633098985a1a190402f278ce Mon Sep 17 00:00:00 2001
From: Micah Walter <micahjwalter@gmail.com>
Date: Fri, 25 Jul 2014 16:39:37 -0400
Subject: [PATCH 517/690] Update 01-chapter1.markdown

Translation of the brief history / Traduko de la mallonga historio
---
 eo/01-introduction/01-chapter1.markdown | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/eo/01-introduction/01-chapter1.markdown b/eo/01-introduction/01-chapter1.markdown
index d8c3313bc..2702db772 100644
--- a/eo/01-introduction/01-chapter1.markdown
+++ b/eo/01-introduction/01-chapter1.markdown
@@ -39,19 +39,19 @@ Figure 1-3. Distributed version control diagram.
 
 Furthermore, many of these systems deal pretty well with having several remote repositories they can work with, so you can collaborate with different groups of people in different ways simultaneously within the same project. This allows you to set up several types of workflows that aren’t possible in centralized systems, such as hierarchical models.
 
-## A Short History of Git ##
+## Mallonga historio de Git ##
 
-As with many great things in life, Git began with a bit of creative destruction and fiery controversy. The Linux kernel is an open source software project of fairly large scope. For most of the lifetime of the Linux kernel maintenance (1991–2002), changes to the software were passed around as patches and archived files. In 2002, the Linux kernel project began using a proprietary DVCS system called BitKeeper.
+Kiel pluraj el la bonaĵoj en la vivo, Git komenciĝis per iom da kreiga detruo kaj granda disputego. La Linux-kerno estas malfermitkoda programaro-projekto kun sufiĉe granda amplekso. Dum la plejparto de la tempo en kiu la Linux-kerno estis prizorgata (1991–2002), oni disdonis ŝanĝojn al la programaro kiel flikaĵoj kaj enarkivigitaj dosieroj. En 2002, la Linux-kerna projekto komencis uzi proprietan DVCS-sistemon nomita BitKeeper.
 
-In 2005, the relationship between the community that developed the Linux kernel and the commercial company that developed BitKeeper broke down, and the tool’s free-of-charge status was revoked. This prompted the Linux development community (and in particular Linus Torvalds, the creator of Linux) to develop their own tool based on some of the lessons they learned while using BitKeeper. Some of the goals of the new system were as follows:
+En 2005 rompiĝis la rilato inter la komunumo, en kiu la Linux-kerno evoluis, kaj la komerco firmao, kiu produktis BitKeeper; oni senvalidigis la senkostan statuson de la ilo. Tio instigis la komunumo, kiu sin prizorgis pri la evoluo de Linux—kaj precipe Linus Torvalds, la kreinto de Linux—krei sian propran ilon, tenante en la menso la lecionojn, kiujn ili lernis, dum ili uzis BitKeeper. Jen kelkaj el la celoj de la nova sistemo:
 
-*	Speed
-*	Simple design
-*	Strong support for non-linear development (thousands of parallel branches)
-*	Fully distributed
-*	Able to handle large projects like the Linux kernel efficiently (speed and data size)
+*	Rapideco
+*	Simpla desegno
+*	Bona subteno por nelinea konstruado (miloj da paralelaj branĉoj)
+*	Tute disa sistemo
+*	La ebleco rendimente trakti grandajn projektojn (kiel la Linux-kerno) koncerne al rapideco kaj datuma grandeco
 
-Since its birth in 2005, Git has evolved and matured to be easy to use and yet retain these initial qualities. It’s incredibly fast, it’s very efficient with large projects, and it has an incredible branching system for non-linear development (See Chapter 3).
+Ekde ĝia naskiĝo en 2005, Git evoluis kaj prenkreskiĝis por esti facile uzebla kaj tamen reteni tiujn dekomencaj ecoj. Ĝi estas nekredeble rapida; ĝi estas tre rendimenta kun grandaj projektoj; kaj ĝi havas bonegan branĉigan sistemon por nelinea konstruado (vidu Ĉapitro 3).
 
 ## Git Basics ##
 

From 95a5fb84c899447b6555ae197b84b5c81dedf707 Mon Sep 17 00:00:00 2001
From: mxamin <amin.solhizadeh@gmail.com>
Date: Sun, 27 Jul 2014 10:54:13 +0330
Subject: [PATCH 518/690] [fa] ch1 update

---
 fa/01-introduction/01-chapter1.markdown | 176 ++++++++++++------------
 1 file changed, 89 insertions(+), 87 deletions(-)

diff --git a/fa/01-introduction/01-chapter1.markdown b/fa/01-introduction/01-chapter1.markdown
index 0bab2f4a4..44d312701 100644
--- a/fa/01-introduction/01-chapter1.markdown
+++ b/fa/01-introduction/01-chapter1.markdown
@@ -1,138 +1,138 @@
-# آغاز #
+# سرآغاز #
 
-این فصل در موردشروع استفاده از گیت خواهد بود.  
-ما ابتدا کمی پیشزمینه ابزارهای کنترل نسخه را مرور میکنیم، سپس میرسیم به قسمتی که چگونه گیت را  در سیستم خود راه اندازی کنید و در نهایت چگونه آن را نصب کنید تا بتوانید با آن شروع به کار نمایید. 
-در انتهای این فصل شما باید فهمیده باشید که چرا گیت لازم است، چرا باید از آن استفاده کرد و آماده باشید تا شروع به استفاده از آن کنید.  
+در این فصل در رابطه با شروع کار با Git صحبت خواهد شد. این فصل با توضیحاتی در رابطه با تاریخچه ابزارهای کنترل ورژن شروع می شود، سپس چگونگی راه اندازی Git برروی یک سیستم خاص آموزش داده می شود و در انتها انجام تنظیمات موردنیاز برروی این نرم افزار جهت شروع به کار با آن مورد بررسی قرار می گیرد. در انتهای این فصل خواننده باید دلیل وجود و استفاده از Git را بداند و همچنین باید محیط کار را برای استفاده از آن فراهم کرده باشد.
 
-## درباره کنترل نسخه ##
+## کنترل ورژن ##
 
-کنترل نسخه چیست، و چرا باید برای شما اهمیتی داشته باشد؟ کنترل نسخه سیستمی ست که تغییرات ایجاد شده در یک فایل یا مجموعه ای از فایلها را در طول زمان ثبت میکند تا شما بتوانید نسخه مشخصی از آنها را بعدا بازخوانی کنید. 
- هر چند مثالهای این کتاب کدهای نرم افزاری را به عنوان فایلهای تحت کنترل نسخه نشان میدهند, در واقع هر نوع فایلی بر روی رایانه میتواند تحت کنترل نسخه قرار بگیرد.
+کنترل ورژن چیست و چه اهمیتی دارد؟ کنترل ورژن سیستمی است که تغییرات مربوط به یک یا چندین فایل را در طول زمان ذخیره می کند، تا کاربر بتواند به ورژن های قبلی مراجعت داشته باشد. در مثالهای استفاده شده در این کتاب از فایل های سورس نرم افزار جهت نمایش کنترل ورژن استفاده میشود، ولی با این وجود میتوان هر نوع فایلی را تحت کنترل ورژن قرار داد.
 
+اگر شما یک گرافیست یا طراح وب باشید و تصمیم به نگهداری تمامی ورژنهای یک عکس یا ساختار باشید (که قطعا به همین منوال است)، استفاده از یک سیستم کنترل ورژن (VCS) راهبردی عاقلانه است. یک VCS این امکان را به شما میدهد که: فایلها را به یک وضعیت قبل برگردانید، یک پروژه را به یک وضعیت قبل برگردانید، تغییرات انجام گرفته در مرور زمان را مشاهده کنید، باعث و بانی تغییری را بیابید که منجر به ایجاد خطا یا مشکلی در سیستم شده است، چه کسی و چه زمانی مسئلهای خاص مطرح شده است و بسیاری موارد دیگر. استفاده از یک VCS حتی این امکان را به شما میدهد که اگر احیاناً خطایی مرتکب شدید یا فایلی را اشتباهاً حذف یا از دست دادید، به راحتی آن را اصلاح و بازیابی کنید.
 
-اگر شما طراح  گرافیکی یا طراح  وب هستید و میخواهید که تمام نسخه های یک تصویر یا طرح را نگاه دارد (که معمولا هم همینطور است), استفاده از یک سیستم کنترل نسخه کار معقولی خواهد بود.
+### سیستمهای کنترل ورژن محلی ###
 
-A VCS allows you to: revert files back to a previous state, revert the entire project back to a previous state, review changes made over time, see who last modified something that might be causing a problem, who introduced an issue and when, and more. Using a VCS also means that if you screw things up or lose files, you can generally recover easily. In addition, you get all this for very little overhead.
+روشی که اکثر کاربران جهت کنترل ورژن انتخاب میکنند شامل کپی کردن فایلها در پوشهای دیگر است (البته اگر هوشمند باشد، پوشه موردنظر را با تاریخ و زمانی مشخص نامگذاری میکنند). چنین روشی به جهت سادگی بین کاربران بسیار رایج میباشد، ولی خطاپذیری بالایی نیز دارد. در این روش امکان دارد فرد به آسانی پوشهای که در آن قرار دارد را فراموش کند و به اشتباه شروع به تغییر برروی فایلهایی کند که مدنظر او نیست.
 
-### Local Version Control Systems ###
-
-Many people’s version-control method of choice is to copy files into another directory (perhaps a time-stamped directory, if they’re clever). This approach is very common because it is so simple, but it is also incredibly error prone. It is easy to forget which directory you’re in and accidentally write to the wrong file or copy over files you don’t mean to.
-
-To deal with this issue, programmers long ago developed local VCSs that had a simple database that kept all the changes to files under revision control (see Figure 1-1).
+برای مقابله با این موذل، برنامه نویسان از زمانهای بسیار قبل اقدام به توسعه VCSها زده اند که در بردارنده پایگاه داده ساده ای هستند به گونه ای که تمامی تغییرات انجام شده برروی فایلهای هدف را در قالب کنترل رویژن نگهداری می کنند (تصویر 1-1)
 
 Insert 18333fig0101.png
-Figure 1-1. Local version control diagram.
+تصویر 1-1. دیاگرام کنترل ورژن محلی.
 
-One of the more popular VCS tools was a system called rcs, which is still distributed with many computers today. Even the popular Mac OS X operating system includes the rcs command when you install the Developer Tools. This tool basically works by keeping patch sets (that is, the differences between files) from one revision to another in a special format on disk; it can then recreate what any file looked like at any point in time by adding up all the patches.
+یکی از رایجترین ابزارهای VCS سیستمی با نام rcs بوده است، که هم اکنون نیز به همراه تعداد زیادی از کامپیوترهای امروزی نیز توزیع می شود. حتی سیستم عامل رایج Mac OS X نیز با نصب ابزارهای توسعه توسط کاربر برروی آن، دستور خط فرمان rcs را در اختیار فرد قرار میدهد. این ابزار به زبانی ساده با حفظ مجموعه ای از پچها (که تغییرات بین فایلها میباشند) از یک رویژن به رویژنی دیگر در قالب فرمتی خاص برروی دیسک عمل میکند؛ با چنین سیستمی این ابزار قادر است با متصل کردن پچها به یکدیگر توانایی بازسازی هر فایلی را در هر نقطه ای از زمان داشته باشد.
 
-### Centralized Version Control Systems ###
+### سیستمهای کنترل ورژن مرکزی ###
 
-The next major issue that people encounter is that they need to collaborate with developers on other systems. To deal with this problem, Centralized Version Control Systems (CVCSs) were developed. These systems, such as CVS, Subversion, and Perforce, have a single server that contains all the versioned files, and a number of clients that check out files from that central place. For many years, this has been the standard for version control (see Figure 1-2).
+مسئله مهم دیگری که کاربران با آن مواجه میشوند، نیاز آنها به همکاری با دیگر توسعه دهندگان برروی سیستمهای دیگر است. برای حل این مسئله، سیستمهای کنترل ورژن مرکزی (CVCSs) توسعه یافتند. چنین سیستمهایی مانند CVS، Subversion و Perforce در بردارنده سروری مرکزی هستند که تمامی ورژنهای فایلها و حتی کاربرانی که این فایلها را از این مکان مرکزی check out کرده اند در خود نگهداری میکند. برای سالهای زیادی، چنین روشی، روشی استاندارد برای کنترل ورژن بوده است (تصویر 1-2).
 
 Insert 18333fig0102.png
-Figure 1-2. Centralized version control diagram.
+تصویر 1-2. دیاگرام کنترل ورژن مرکزی.
 
-This setup offers many advantages, especially over local VCSs. For example, everyone knows to a certain degree what everyone else on the project is doing. Administrators have fine-grained control over who can do what; and it’s far easier to administer a CVCS than it is to deal with local databases on every client.
+این ساختار مزایای بسیاری مخصوصاً نسبت به سیستمهای کنترل ورژن محلی دارد. به عنوان مثال، هر فرد در حد و اندازه مشخصی  خواهد توانست بداند که دیگر افراد تا چه اندازه در پروژه شریک هستند. مدیران از این نظر که هرکس از نظر سطح دسترسی قادر به انجام چه کاری است، کنترل مناسبی دارند؛ همچنین مدیریت یک CVCS به مراتب آسانتر از تعامل با پایگاههای داده محلی موجود برروی سیستمهای کاربران است.
 
-However, this setup also has some serious downsides. The most obvious is the single point of failure that the centralized server represents. If that server goes down for an hour, then during that hour nobody can collaborate at all or save versioned changes to anything they’re working on. If the hard disk the central database is on becomes corrupted, and proper backups haven’t been kept, you lose absolutely everything—the entire history of the project except whatever single snapshots people happen to have on their local machines. Local VCS systems suffer from this same problem—whenever you have the entire history of the project in a single place, you risk losing everything.
+با این وجود، چنین ساختاری معایبی نیز دارد. واضحترین موضوع بروز کوچکترین ایراد در سرورهای مرکزی میباشد. اگر برای مدت یک ساعت این سرور متوقف و از کار بیافتد، در طی این بازه یک ساعته هیچکس نخواهد توانست تعاملی داشته باشد یا حتی تغییرات ورژن را برروی چیزی که در حال کارکردن با آن است ذخیره کند. اگر هارد دیسکی که  پایگاه داده مرکزی برروی آن قرار دارد خراب شود، و پشتیبان مناسبی از آن گرفته نشده باشد، کاربر به طور کامل تاریخچه پروژه را از دست خواهد داد به جز snapshotهایی که هر کاربر احتمالاً برروی ماشین محلی خود خواهد داشت. سیستمهای VCS محلی نیز این عیب را به ارث میبرند-اگر کاربر تمامی تاریخچه پروژه را در یک مکان ذخیره کند، ریسک از دادن همه چیز به قوت خود باقی خواهد ماند.
 
-### Distributed Version Control Systems ###
+### سیستمهای کنترل ورژن پخشی ###
 
-This is where Distributed Version Control Systems (DVCSs) step in. In a DVCS (such as Git, Mercurial, Bazaar or Darcs), clients don’t just check out the latest snapshot of the files: they fully mirror the repository. Thus if any server dies, and these systems were collaborating via it, any of the client repositories can be copied back up to the server to restore it. Every checkout is really a full backup of all the data (see Figure 1-3).
+اینجا است که سیستمهای کنترل ورژن پخشی (DVCSs) نمود پیدا میکنند. در یک DVCS (مانند Git، Mercurial، Bazaar یا Darcs) کابران به check out کردن آخرین snapshot فایلها اکتفا نمیکنند: آنها repository را نیز به صورت کامل کپی میکنند. بنابراین اگر هر سروری که سیستمها به واسطه آن در حال تعامل با یکدیگر هستند متوقف و از کار بیافتد، با کپی repository هر کدام از کاربران برروی سرور، عمل بازیابی انجام میگیرد. در واقع هر checkoutای، پشتیبان کاملی از تمامی داده ها است.
 
 Insert 18333fig0103.png
-Figure 1-3. Distributed version control diagram.
+تصویر 1-3. دیاگرام کنترل ورژن پخشی.
 
-Furthermore, many of these systems deal pretty well with having several remote repositories they can work with, so you can collaborate with different groups of people in different ways simultaneously within the same project. This allows you to set up several types of workflows that aren’t possible in centralized systems, such as hierarchical models.
+علاوه بر آن اکثر این سیستمها تعامل خوبی با داشتن remote repositoryهای متعدد جهت کار کردن با آنها دارند، در نتیجه شخص خواهد توانست با گروههای مختلفی در قالب پروژه ای یکسان به صورت همزمان تعامل داشته باشد. این قابلیت این امکان را به کاربر خواهد داد که workflowهای متنوعی همانند مدلهای سلسه مراتبی را پیاده سازی کند که انجام آن در سیستمهای متمرکز امکان پذیر نیست.
 
-## A Short History of Git ##
+## تاریخچه کوتاهی از Git ##
 
-As with many great things in life, Git began with a bit of creative destruction and fiery controversy. The Linux kernel is an open source software project of fairly large scope. For most of the lifetime of the Linux kernel maintenance (1991–2002), changes to the software were passed around as patches and archived files. In 2002, the Linux kernel project began using a proprietary DVCS system called BitKeeper.
+همانند اکثر حوادث بزرگ در در زندگی، Git نیز با خلاقیتی مخرب و جنجالی آتشین شروع شد. هسته لینوکس پروژه نرم افزاری متن باز با وسعت نسبتاً زیادی است. برای مدت زمان زیادی از عمر نگهداری هسته لینوکس (1991 - 2002) تغییرات نرم افزاری به واسطه پچ ها و فایلهای آرشیو شده انتقال پیدا میکرد. در سال 2002، پروژه هسته لینوکس اقدام به استفاده از سیستم DVCS خصوصی با نام BitKeeper کرد.
 
-In 2005, the relationship between the community that developed the Linux kernel and the commercial company that developed BitKeeper broke down, and the tool’s free-of-charge status was revoked. This prompted the Linux development community (and in particular Linus Torvalds, the creator of Linux) to develop their own tool based on some of the lessons they learned while using BitKeeper. Some of the goals of the new system were as follows:
+در سال 2005، ارتباط بین مجموعه تیم توسعه دهنده هسته لینوکس و شرکت تجاری توسعه دهنده BitKeeper گسسته شد و وضعیت ابزاری که قبل از آن  به صورت رایگان عرضه میشد تغییر پیدا کرد. این اتفاق اخطاری را متوجه مجموعه تیم توسعه دهنده لینوکس (به خصوص مؤسس لینوکس، لینوس تورلوادز) کرد که بر اساس تجربه های کسب شده در استفاده از BitKeeper، خود اقدام به تولید نرم افزاری در زمینه بزنند. مواردی از اهداف سیستم جدید عبارتند از:
 
-*	Speed
-*	Simple design
-*	Strong support for non-linear development (thousands of parallel branches)
-*	Fully distributed
-*	Able to handle large projects like the Linux kernel efficiently (speed and data size)
+*  	سرعت
+*	طراحی ساده
+*	پشتیبانی قوی از توسعه غیر خطی (هزاران branch موازی)
+*	کاملاً پخشی
+* 	قابلیت کنترل بهینه پروژه های بزرگ همانند هسته لینوکس (از نظر سرعت و اندازه داده)
 
-Since its birth in 2005, Git has evolved and matured to be easy to use and yet retain these initial qualities. It’s incredibly fast, it’s very efficient with large projects, and it has an incredible branching system for non-linear development (See Chapter 3).
+از زمان تولد Git در سال 2005، این نرم افزار از نظر استفاده آسان و حفظ اهداف اولیه ذکر شده به تکامل و بلوغ رسیده است. Git نرم افزاری سریع، بسیار بهینه در مواجه با پروژه های بزرگ و حاوی سیستم شاخه ای (branching) باورنکردنی برای توسعه غیر خطی است (فصل 3).
 
-## Git Basics ##
+## مقدمات Git ##
 
-So, what is Git in a nutshell? This is an important section to absorb, because if you understand what Git is and the fundamentals of how it works, then using Git effectively will probably be much easier for you. As you learn Git, try to clear your mind of the things you may know about other VCSs, such as Subversion and Perforce; doing so will help you avoid subtle confusion when using the tool. Git stores and thinks about information much differently than these other systems, even though the user interface is fairly similar; understanding those differences will help prevent you from becoming confused while using it.
+خوب، Git چیست؟ این بخش از نظر یادگیری، بخشی مهم قلمداد می شود، زیرا اگر فرد از پایه و اساس عملکرد Git  اطلاع پیدا کند، آنگاه خواهد توانست آسانتر در استفاده مؤثر از آن بهره جوید. در حین یادگیری Git، بهتر است فرد ذهن خود را از مواردی که احیاناً در رابطه با دیگر VCSها همانند Subversion و Perforce میداند تخلیه کند؛ بدین وسیله از بروز اشتباهات موردی در استفاده از این ابزار پیشگیری می شود. با وجود آن که رابط کاربری Git نسبتاً مشابه با دیگر سیستم ها است، ولی در ذخیره سازی و نگاه به اطلاعات، دید بسیار متفاوتی در مقایسه با دیگر سیستم ها دارد؛ دانستن این تفاوت ها میتواند به فرد در جلوگیری از  بروز اشتباهات بعدی در استفاده از این ابزار یاری دهد.
 
-### Snapshots, Not Differences ###
+### Snapshotها، نه تفاوتها ###
+
+اصلی ترین تفاوت بین Git و دیگر VCSها (که شامل Subversion و هم خانواده های آن نیز می شود) دیدگاهی است که Git نسبت به داده های خود دارد. از نظر مفهومی، اکثریت دیگر سیستم ها اطلاعات را به مثابه لیستی از تغییرات بر مبنای فایل، ذخیره می کنند. این سیستم ها (CVS، Subversion، Perfoce، Bazaar و غیره) همانطور که در تصویر 1-4 نشان داده شده است،  به اطلاعاتی که نگهداری میکنند به شکل مجموعه ای از فایلها و تغییراتی که برروی هر فایل در مرور زمان انجام گرفته است، مینگرند.
 
-The major difference between Git and any other VCS (Subversion and friends included) is the way Git thinks about its data. Conceptually, most other systems store information as a list of file-based changes. These systems (CVS, Subversion, Perforce, Bazaar, and so on) think of the information they keep as a set of files and the changes made to each file over time, as illustrated in Figure 1-4.
 
 Insert 18333fig0104.png
-Figure 1-4. Other systems tend to store data as changes to a base version of each file.
+تصویر 1-4. دیگر سیستم ها داده ها به شکل  تغییرات در ورژن پایه هر فایل ذخیره می کنند.
 
-Git doesn’t think of or store its data this way. Instead, Git thinks of its data more like a set of snapshots of a mini filesystem. Every time you commit, or save the state of your project in Git, it basically takes a picture of what all your files look like at that moment and stores a reference to that snapshot. To be efficient, if files have not changed, Git doesn’t store the file again—just a link to the previous identical file it has already stored. Git thinks about its data more like Figure 1-5.
+Git از چنین تفکر یا روش ذخیره سازی داده ای پیروی نمی کند. در عوض دیدگاه Git نسبت به داده های خود به شکل  snapshotهایی از یک سیستم فایلی کوجک است. هر زمانی که شخص commitای انجام میدهد یا وضعیت پروژه خود را در Git ذخیره می کند، در اصل تصویری از وضعیت تمامی فایل ها در لحظه موردنظر تهیه و ارجاعی به snapshot ایجاد شده ذخیره می شود. برای آنکه این عمل به صورت بهینه انجام پذیرد، اگر در فایلی تغییری ایجاد نشده باشد، Git اقدام به ذخیره سازی مجدد فایل نمی کند - تنها ارتباطی (link) به نسخه مشابه آن فایل که قبلاً ذخیره شده است را ذخیره می کند. طریقه نگرش Git به داده در تصویر 1-5 نمایش داده شده است.
 
 Insert 18333fig0105.png
-Figure 1-5. Git stores data as snapshots of the project over time.
+تصویر 1-5. Git داده ها را به شکل snapshotهایی از پروژه در مرور زمان نگهداری میکند.
+
+این شکل نگرش مهمترین اصل تمایز Git با دیگر VCSها است. این امر موجب می شود تا Git تجدیدنظری نسبت به تمامی ابعاد کنترل ورژن داشته باشد، که اکثریت دیگر سیستم ها از نسل های قبل از خود به ارث برده اند. این موضوع باعث شده است تا Git از یک VCS ساده، به سیستم فایلی کوچکی بدل شود که در بالادست آن ابزار قدرتمند باورنکردنی بنا شده است. در فصل 3 بعضی از مزایای چنین دیدگاهی نسبت به داده پوشش داده می شود.
 
-This is an important distinction between Git and nearly all other VCSs. It makes Git reconsider almost every aspect of version control that most other systems copied from the previous generation. This makes Git more like a mini filesystem with some incredibly powerful tools built on top of it, rather than simply a VCS. We’ll explore some of the benefits you gain by thinking of your data this way when we cover Git branching in Chapter 3.
+### تقریباً تمام عملیات به صورت محلی انجام می پذیرد ###
 
-### Nearly Every Operation Is Local ###
+اکثر عملیاتی که در Git انجام میپذیرد جهت اجرا تنها نیازمند فایلها و منابع محلی هستند - به طور کلی نیازمند هیچگونه اطلاعاتی از کامپیوتری دیگر در شبکه نیست. اگر شما فردی هستید که به CVCSای عادت کرده اید که در آن اکثر فعالیت ها دارای افزونگی رکود شبکه ای داشته اند، شاید این مزیت Git این فکر را برای شما تداعی کند که خدایان سرعت Git را با قدرتی وصف ناشدنی مورد لطف و رحمت قرار داده اند. از آن جهت که تمامی تاریخچه پروژه برروی دیسک محلی قرار دارد، به نظر می رسد که اکثر عملیات به صورت لحظه ای و بلادرنگ انجام می پذیرند.
 
-Most operations in Git only need local files and resources to operate — generally no information is needed from another computer on your network.  If you’re used to a CVCS where most operations have that network latency overhead, this aspect of Git will make you think that the gods of speed have blessed Git with unworldly powers. Because you have the entire history of the project right there on your local disk, most operations seem almost instantaneous.
+به عنوان مثال، Git برای نمایش تاریخچه پروژه نیازی جهت مراجعه به سرور برای اخذ تاریخچه و نمایش آن ندارد - Git این عمل را با خواندن مستقیم  پایگاه داده محلی انجام میدهد. این بدان معناست که شخص میتوان تاریخچه پروژه را تقریباً بلادرنگ مشاهده کند. اگر نیاز به مشاهده تغییرات بین ورژن فعلی یک فایل با ورژن یک ماه قبل از آن باشد، Git میتواند بجای آنکه از سرور درخواست این عمل را داشته باشد و یا آنکه نسخه قبلی را از سرور خارجی فراخوانی و سپس مقایسه محلی را انجام دهد، این عمل  را با نگاهی به نسخه یک ماه قبل فایل و انجام محاسبات محلی تغییرات رخ داده، انجام میدهد.
 
-For example, to browse the history of the project, Git doesn’t need to go out to the server to get the history and display it for you—it simply reads it directly from your local database. This means you see the project history almost instantly. If you want to see the changes introduced between the current version of a file and the file a month ago, Git can look up the file a month ago and do a local difference calculation, instead of having to either ask a remote server to do it or pull an older version of the file from the remote server to do it locally.
+همچنین بدین معناست که در صورت آفلاین بودن و یا وصل نبودن به VPN دامنه عملکرد شخص زیاد محدود نمی شود. اگر سوار بر هواپیما یا قطار شده باشید و تصمیم به انجام کاری داشته باشید، میتوانید به راحتی commit را انجام داده و زمانی که دسترسی به شبکه پیدا کردید آپلود را انجام دهید. اگر به خانه رفته باشید و قادر به فعال سازی VPN خود نشده باشید، باز هم وقفه ای در کار شما حاصل نمی شود. در اکثریت دیگر سیستم ها انجام این موارد غیرممکن یا به سختی انجام می پذیرد. به عنوان مثال در Perforce، در صورتی که به شبکه متصل نباشید در واقع توانایی انجام کاری نخواهید داشت؛ در Subversion و CVS، امکان دستکاری فایل ها برای شما وجود دارد، ولی برای commit تغییرات روی پایگاه داده محدودیت دارید (زیرا اتصال شما به پایگاه داده بر قرار نیست). شاید این موضوع مسئله مهمی به نظر نیاید، ولی شاید با مشاهده تغییرات بزرگی که میتواند به موجب آن ایجاد شود، شگفت زده شوید.
 
-This also means that there is very little you can’t do if you’re offline or off VPN. If you get on an airplane or a train and want to do a little work, you can commit happily until you get to a network connection to upload. If you go home and can’t get your VPN client working properly, you can still work. In many other systems, doing so is either impossible or painful. In Perforce, for example, you can’t do much when you aren’t connected to the server; and in Subversion and CVS, you can edit files, but you can’t commit changes to your database (because your database is offline). This may not seem like a huge deal, but you may be surprised what a big difference it can make.
+### Git صداقت دارد ###
 
-### Git Has Integrity ###
+هرچیزی که بخواهد در Git ذخیره شود، ابتدا checksum آن محاسبه میشود و سپس بوسیله همین checksum ارجاع داده میشود. چنین عملی موجب میشود که در صورت ایجاد کوچکترین تغییری در مححتویات فایل یا پوشه ای، Git از آن آگاهی پیدا کند. این دستورالعمل در Git در پایینترین سطح پیاده سازی شده است و تاییدی بر صحت فلسفه Git دارد. بدین دلیل است که اگر داده ای در حین انتقال از دست برود و یا فایلی مخدوش شود، Git به سرعت از آن اطلاع پیدا میکند.
 
-Everything in Git is check-summed before it is stored and is then referred to by that checksum. This means it’s impossible to change the contents of any file or directory without Git knowing about it. This functionality is built into Git at the lowest levels and is integral to its philosophy. You can’t lose information in transit or get file corruption without Git being able to detect it.
+مکانیزمی که Git برای تولید checksum استفاده میکند، هش SHA-1 است. این هش یک رشته 40 کاراکتری از کاراکترهای مبنای شانزده است (0 - 9 و a - f) که از روی محتویات فایل و یا ساختار پوشه موردنظر در Git محاسبه میگردد. در ادامه یک نمونه از هش SHA-1 آورده شده است:
 
-The mechanism that Git uses for this checksumming is called a SHA-1 hash. This is a 40-character string composed of hexadecimal characters (0–9 and a–f) and calculated based on the contents of a file or directory structure in Git. A SHA-1 hash looks something like this:
 
 	24b9da6552252987aa493b52f8696cd6d3b00373
 
-You will see these hash values all over the place in Git because it uses them so much. In fact, Git stores everything not by file name but in the Git database addressable by the hash value of its contents.
+به علت استفاده زیاد Git از این هش، به کرات در جای جای Git مشاهده گر این هش ها خواهید بود. در واقع، Git از نام فایل برای ذخیره سازی آن استفاده نمیکند بلکه Git از هش تولید شده از محتویات فایل مربوطه برای آدرس دهی آن در پایگاه داده خود بهره میگیرد.
+
+### عموماً Git فقط داده اضافه میکند ###
 
 ### Git Generally Only Adds Data ###
 
-When you do actions in Git, nearly all of them only add data to the Git database. It is very difficult to get the system to do anything that is not undoable or to make it erase data in any way. As in any VCS, you can lose or mess up changes you haven’t committed yet; but after you commit a snapshot into Git, it is very difficult to lose, especially if you regularly push your database to another repository.
+هرگاه عملی در Git انجام میپذیرد، تقریباً در تمامی موارد Git داده ای به داده های خود در پایگاه داده اضافه می کند. انجام دادن عملی در این سیستم که برگشت پذیر نباشد یا باعث حذف داده ای از سیستم شود، بسیار سخت است. مشابه اکثر VCSها، فرد میتواند تا قبل از commit هرگونه تغییراتی را انجام دهد؛ ولی به محض commit یک snapshot در Git، امکان حذف آن بسیار سخت است، مخصوصاً اگر فرد عادتاً  پایگاه داده خود را به repository دیگری push کند.
+
+این قابلیت باعث می شود که استفاده از Git، به عملی فرح بخش تبدیل شود زیرا فرد خواهد توانست بدون در خطر انداختن چیزی دست به هرگونه آزمایشی بزند. برای آشنایی بیشتر با چگونگی عملکرد Git در ذخیره سازی و بازیابی داده هایی که به نظر از دست رفته می باشند، میتوانید به فصل 9 مراجعه کنید.
 
-This makes using Git a joy because we know we can experiment without the danger of severely screwing things up. For a more in-depth look at how Git stores its data and how you can recover data that seems lost, see Chapter 9.
+### سه وضعیت ###
 
 ### The Three States ###
 
-Now, pay attention. This is the main thing to remember about Git if you want the rest of your learning process to go smoothly. Git has three main states that your files can reside in: committed, modified, and staged. Committed means that the data is safely stored in your local database. Modified means that you have changed the file but have not committed it to your database yet. Staged means that you have marked a modified file in its current version to go into your next commit snapshot.
+توجه، توجه. اگر میخواهید پروسه یادگیری Git را بدون دردسر ادامه دهید، این مطلب را به خاطر بسپارید. فایلها در Git میتوانند در سه وضعیت اصلی قرار داشته باشند: committed، modified و staged. committed بدین معناست که فایل موردنظر در پایگاه داده محلی ذخیره شده است. modified یعنی تغییری در فایل ایجاد شده است ولی هنوز commitای به موجب این فایل روی پایگاه داده انجام نگرفته است. فایلی که در وضعیت staged قرار گرفته است، فایلی تغییر یافته میباشد که ورژن فعلی آن جهت snapshot بعدی جهت commit نشانه گذاری شده است.
 
-This leads us to the three main sections of a Git project: the Git directory, the working directory, and the staging area.
+حال میتوان سه بخش اصلی پروژه Git را معرفی کرد: پوشه Git، پوشه در حال کار (working directory) و staging area.
 
 Insert 18333fig0106.png
-Figure 1-6. Working directory, staging area, and Git directory.
+تصویر 1-6. پوشه در حال کار، staging area و پوشه Git
 
-The Git directory is where Git stores the metadata and object database for your project. This is the most important part of Git, and it is what is copied when you clone a repository from another computer.
+در Git، metadata و پایگاه داده پروژه در پوشه Git ذخیره میشوند. این قسمت مهمترین بخش Git است، در واقع هنگامی که از repository کامپیوتری cloneای گرفته می شود، کپی از این پوشه ایجاد میگردد.
 
-The working directory is a single checkout of one version of the project. These files are pulled out of the compressed database in the Git directory and placed on disk for you to use or modify.
+پوشه در حال کار، checkout منفردی از ورژنی از پروژه است. فایلهای این بخش، فایلهایی می باشند که از پایگاه داده فشرده واقع در پوشه Git بیرون کشیده شده و جهت استفاده و ایجاد تغییر بر روی دیسک قرار داده شده اند.
 
-The staging area is a simple file, generally contained in your Git directory, that stores information about what will go into your next commit. It’s sometimes referred to as the index, but it’s becoming standard to refer to it as the staging area.
+staging area عموماً از یک فایل ساده تشکیل شده است که محتوی اطلاعاتی است که مشخص میکند که چه چیزهایی در commit بعدی قرار میگیرند. معمولاً از این فایل را index مینامند ولی staging area نیز در حال تبدیل شدن به نامی استاندارد برای چنین فایلی است.
 
-The basic Git workflow goes something like this:
+روند کاری Git عموماً به صورت ذیل است:
 
-1. You modify files in your working directory.
-2. You stage the files, adding snapshots of them to your staging area.
-3. You do a commit, which takes the files as they are in the staging area and stores that snapshot permanently to your Git directory.
+1. ایجاد تغییرات روی فایلهای واقع در پوشه در حال کار.
+2. stage کردن فایلها و اضافه کردن snapshotهای فایلها به staging area.
+3. commit کردن، که به موجب آن وضعیت فعلی فایلها در staging area تحت یک snapshot به صورت دائمی در پوشه Git ذخیره میگردد.
 
-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.
+اگر ورژنی از یک فایل در پوشه git قرار داشته باشد، commit شده فرض میشود. اگر تغییری در فایل ایجاد شده باشد و به staging area اضافه شده باشد، گوییم staged شده است. و اگر در فایل از آخرین مرتبه ای که check out شده است تغییری ایجاد شده باشد ولی staged نشده باشد، گوییم modified شده است. در فصل 2، با این وضعیت ها بیشتر آشنا خواهید شد و یاد خواهید گرفت که چگونه میتوان از آنها به نحو احسنت استفاده کرد و یا حتی به صورت کامل از روی مرحله stage پرش کرد.
 
-## Installing Git ##
+## نصب Git ##
 
-Let’s get into using some Git. First things first—you have to install it. You can get it a number of ways; the two major ones are to install it from source or to install an existing package for your platform.
+حال وقت آن است که کار با Git را شروع کنیم. اول از هر چیز میبایست Git را نصب کرد. روشهای مختلفی برای این کار وجود دارد؛ دو مورد از رایجترین این روشها نصب از طریق سورس یا نصب به واسطه پکیج های موجودی است که برای پلتفرم مورد نظر شما تهیه شده است.
 
-### Installing from Source ###
+### نصب از طریق سورس ###
 
-If you can, it’s generally useful to install Git from source, because you’ll get the most recent version. Each version of Git tends to include useful UI enhancements, so getting the latest version is often the best route if you feel comfortable compiling software from source. It is also the case that many Linux distributions contain very old packages; so unless you’re on a very up-to-date distro or are using backports, installing from source may be the best bet.
+اگر امکان نصب از طریق سورس برای شما وجود دارد، این روش مناسبترین روش جهت نصب میباشد، زیرا شما بعد از نصب آخرین ورژن نرم افزار را در اختیار خواهید داشت. در هر نسخه از Git سعی شده است که تا در رابط کاربری بهبودهایی حاصل شود، بنابراین در اختیار داشتن آخرین ورژن بهترین گزینه است البته اگر با کامپایل سورس نرم افزار مشکلی نداشته باشید. همچنین معمولاً مخازن نرم افزاری اکثر توزیعهای لینوکس در بر دارنده پکیجهایی با ورژنهای قدیمی هستند؛ بنابراین در صورتی که شما توسعه دهنده ای به روز هستید یا از backportها استفاده میکنید، نصب از طریق سورس بهترین انتخاب برای شما می باشد.
 
-To install Git, you need to have the following libraries that Git depends on: curl, zlib, openssl, expat, and libiconv. For example, if you’re on a system that has yum (such as Fedora) or apt-get (such as a Debian based system), you can use one of these commands to install all of the dependencies:
+برای نصب Git نیاز به کتابخانه های curl، zlib، openssl، expat و libiconv است که Git نیازمند آنهاست. به عنوان مثال، اگر روی سیستمی کار میکنید که yum (مانند Fedora) یا apt-get (مانند سیستم های مبتنی بر Debian) دارد، میتوانید برای نصب این بسته های  نیازمندی از دستورهای ذیل استفاده کنید:
 
 	$ yum install curl-devel expat-devel gettext-devel \
 	  openssl-devel zlib-devel
@@ -140,65 +140,67 @@ To install Git, you need to have the following libraries that Git depends on: cu
 	$ apt-get install libcurl4-gnutls-dev libexpat1-dev gettext \
 	  libz-dev libssl-dev
 
-When you have all the necessary dependencies, you can go ahead and grab the latest snapshot from the Git web site:
+حال که تمامی نیازمندیها نصب گردید، میتوان آخرین نسخه Git را از وب سایت آن دانلود کرد:
 
 	http://git-scm.com/download
 
-Then, compile and install:
+و آن را کامپایل و نصب کرد:
 
 	$ tar -zxf git-1.7.2.2.tar.gz
 	$ cd git-1.7.2.2
 	$ make prefix=/usr/local all
 	$ sudo make prefix=/usr/local install
 
-After this is done, you can also get Git via Git itself for updates:
+بعد از کامل شدن این مراحل میتوان از خود Git برای دریافت آپدیت های Git استفاده کرد:
 
 	$ git clone git://git.kernel.org/pub/scm/git/git.git
 
-### Installing on Linux ###
+### نصب بر روی لینوکس ###
 
-If you want to install Git on Linux via a binary installer, you can generally do so through the basic package-management tool that comes with your distribution. If you’re on Fedora, you can use yum:
+اگر قصد نصب Git بر روی لینوکس به واسطه یک نصاب باینری را دارید، میتوانید این کار را از طریق ابزار مدیریت بسته های نرم افزاری که همراه توزیع موردنظر شما ارائه می شود انجام دهید. اگر توزیع شما Fedora است، میتوانید از yum استفاده کنید:
 
 	$ yum install git-core
 
-Or if you’re on a Debian-based distribution like Ubuntu, try apt-get:
+یا اگر توزیعی مبتنی بر Debian مانند Ubuntu دارید، میتوانید از apt-get استفاده کنید:
 
 	$ apt-get install git
 
-### Installing on Mac ###
+### نصب بر روی Mac ###
 
-There are two easy ways to install Git on a Mac. The easiest is to use the graphical Git installer, which you can download from the SourceForge page (see Figure 1-7):
+برای نصب بر روی Mac دو روش آسان وجود دارد. آسانترین روش استفاده از نصاب گرافیکی Git است، که امکان دانلود آن از صفحه Google Code وجود دارد (تصویر 1-7):
 
-	http://sourceforge.net/projects/git-osx-installer/
+	http://code.google.com/p/git-osx-installer
 
 Insert 18333fig0107.png
-Figure 1-7. Git OS X installer.
+تصویر 1-7. نصاب Git OS X
 
-The other major way is to install Git via MacPorts (`http://www.macports.org`). If you have MacPorts installed, install Git via
+روش دیگر نصب از طریق MacPortها (`http://www.macports.org`) است. اگر MacPorts را نصب شده روی سیستم خود دارید، میتوانید Git را با دستور ذیل نصب کنید
 
 	$ sudo port install git-core +svn +doc +bash_completion +gitweb
 
-You don’t have to add all the extras, but you’ll probably want to include +svn in case you ever have to use Git with Subversion repositories (see Chapter 8).
+نیازی به افزودن تمامی اضافات نیست، ولی شاید برای استفاده از Git به همراه مخازن Subversion، احتمالاً افزودن +svn  گزینه مناسبی است.
+
+### نصب بر روی ویندوز ###
 
-### Installing on Windows ###
+نصب Git روی ویندوز بسیار آسان است. پروژه msysGit یکی از آسانترین مراحل نصب را دارد. تنها نیاز است که فایل نصاب exe را از صفحه GitHub دانلود، و آن را اجرا کرد:
 
-Installing Git on Windows is very easy. The msysGit project has one of the easier installation procedures. Simply download the installer exe file from the GitHub page, and run it:
+	http://msysgit.github.com/
 
-	http://msysgit.github.io
+بعد از اتمام نصب، هم نسخه خط فرمان (شامل SSH client که در ادامه مشاهده خواهد شد که ابزاری کارآمد است) و هم رابط گرافیکی استاندارد را در اختیار خواهید داشت.
 
-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.
+نکته برای کابران ویندوز: کاربر باید جهت کار با Git از پوسته ارائه شده به همراه msysGit (به سبک Unix)، تا بتواند دستورات چند خطی پیچیده ای که در این کتاب آورده شده را اجرا کند. اگر به هر دلیلی، نیاز به استفاده از پوسته خود ویندوز / کنسول خط فرمان، شدید باید در عوض تک کوت (simple quote) از دابل کوت  (برای پارامترهایی که در بر دارنده فاصله هستند) استفاده کنید و باید پارامترهای موجود در آخرین خط که با circumflex accent (^) به پایان میرسند را داخل کوت قرار دهید، زیرا این علامت، نشانگر ادامه دار بودن خط در ویندوز است.
 
-Note on Windows usage: you should use Git with the provided msysGit shell (Unix style), it allows to use the complex lines of command given in this book. If you need, for some reason, to use the native Windows shell / command line console, you have to use double quotes instead of single quotes (for parameters with spaces in them) and you must quote the parameters ending with the circumflex accent (^) if they are last on the line, as it is a continuation symbol in Windows.
+## تنظیمات شروع به کار Git ##
 
 ## First-Time Git Setup ##
 
 Now that you have Git on your system, you’ll want to do a few things to customize your Git environment. You should have to do these things only once; they’ll stick around between upgrades. You can also change them at any time by running through the commands again.
 
-Git comes with a tool called `git config` that lets you get and set configuration variables that control all aspects of how Git looks and operates. These variables can be stored in three different places:
+Git comes with a tool called git config that lets you get and set configuration variables that control all aspects of how Git looks and operates. These variables can be stored in three different places:
 
 *	`/etc/gitconfig` file: Contains values for every user on the system and all their repositories. If you pass the option` --system` to `git config`, it reads and writes from this file specifically.
 *	`~/.gitconfig` file: Specific to your user. You can make Git read and write to this file specifically by passing the `--global` option.
-*	config file in the Git directory (that is, `.git/config`) of whatever repository you’re currently using: Specific to that single repository. Each level overrides values in the previous level, so values in `.git/config` trump those in `/etc/gitconfig`.
+*	config file in the git directory (that is, `.git/config`) of whatever repository you’re currently using: Specific to that single repository. Each level overrides values in the previous level, so values in `.git/config` trump those in `/etc/gitconfig`.
 
 On Windows systems, Git looks for the `.gitconfig` file in the `$HOME` directory (`%USERPROFILE%` in Windows’ environment), which is `C:\Documents and Settings\$USER` or `C:\Users\$USER` for most people, depending on version (`$USER` is `%USERNAME%` in Windows’ environment). 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.
 

From 8a8974877aee75884c58cdcec0aa152a151abaaa Mon Sep 17 00:00:00 2001
From: mxamin <amin.solhizadeh@gmail.com>
Date: Sun, 27 Jul 2014 23:41:21 +0430
Subject: [PATCH 519/690] [fa] chapter 1 update

---
 fa/01-introduction/01-chapter1.markdown | 22 +++++++++++-----------
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/fa/01-introduction/01-chapter1.markdown b/fa/01-introduction/01-chapter1.markdown
index 44d312701..f03cf8c65 100644
--- a/fa/01-introduction/01-chapter1.markdown
+++ b/fa/01-introduction/01-chapter1.markdown
@@ -192,26 +192,26 @@ Insert 18333fig0107.png
 
 ## تنظیمات شروع به کار Git ##
 
-## First-Time Git Setup ##
+حال که Git روی سیستم نصب شده است، نیاز به شخصی سازی بعضی از منابع Git است. انجام این تنظیمات فقط برای یک مرتبه انجام می‌پذیرد؛ و بعد از آن با هر بار ارتقاء بدون تغییر باقی می‌مانند. همچنین امکان تغییر آن‌ها در هر زمانی که نیاز باشد به کمک خط فرمان قابل انجام است.
 
-Now that you have Git on your system, you’ll want to do a few things to customize your Git environment. You should have to do these things only once; they’ll stick around between upgrades. You can also change them at any time by running through the commands again.
+به همراه Git ابزاری ارائه شده است با نام git config که امکان خواندن و اعمال متغیرهای تنظیماتی که تمامی ابعاد ظاهری و عملیاتی Git را کنترل می‌کند فراهم می‌سازد.
 
-Git comes with a tool called git config that lets you get and set configuration variables that control all aspects of how Git looks and operates. These variables can be stored in three different places:
+*  فایل `/etc/gitconfig`: حاوی مقادیر تمامی کاربران سیستم  و مخازن آن‌ها است. اگر به همراه `git config` از آپشن `--system` استفاده شود، خواندن و نوشتن به صورت اختصاصی از این فایل انجام می‌پذیرد.
+*  فایل `~/.gitconfig`: مختص کاربر مشخصی است. با استفاده از آپشن `--global` خواندن و نوشتن Git به صورت اختصاصی از این فایل انجام می‌پذیرد.
+*  فایل config موجود در پوشه git (`.git/config`) یا هر مخزنی که در حال استفاده از آن می‌باشید: مختص یک مخزن خاص است. مقادیر هر سطح باعث لغو مقادیر سطح قبلی خود می‌شود. بنابراین مقادیر `.git/config` موجب لغو مقادیر `/etc/gitconfig` خواهد شد.
 
-*	`/etc/gitconfig` file: Contains values for every user on the system and all their repositories. If you pass the option` --system` to `git config`, it reads and writes from this file specifically.
-*	`~/.gitconfig` file: Specific to your user. You can make Git read and write to this file specifically by passing the `--global` option.
-*	config file in the git directory (that is, `.git/config`) of whatever repository you’re currently using: Specific to that single repository. Each level overrides values in the previous level, so values in `.git/config` trump those in `/etc/gitconfig`.
+در سیستم‌های ویندوزی، Git در پوشه `$HOME` (متغیر محیطی `%USERPROFILE%` در ویندوز) که برای اکثر کاربران با توجه به ورژن سیستم در مسیرهای `C:\Documents and Settings\$USER‍ یا `C:\Users\$USER` (`$USER‍ در ویندوز متغیر محیطی `%USERNAME%`) قرار دارد، فایل `.gitconfig` را جستجو می‌کند. همچنین نسبت به مسیر ریشه MSys که همان مسیر نصب انتخاب شده در هنگام اجرای نصاب Git در ویندوز می‌باشد، به دنبال فایلی با نام /etc/gitconfig می‌گردد.
 
-On Windows systems, Git looks for the `.gitconfig` file in the `$HOME` directory (`%USERPROFILE%` in Windows’ environment), which is `C:\Documents and Settings\$USER` or `C:\Users\$USER` for most people, depending on version (`$USER` is `%USERNAME%` in Windows’ environment). It also still looks for /etc/gitconfig, although it’s relative to the MSys root, which is wherever you decide to install Git on your Windows system when you run the installer.
+### شناسه کاربر ###
 
-### Your Identity ###
-
-The first thing you should do when you install Git is to set your user name and e-mail address. This is important because every Git commit uses this information, and it’s immutably baked into the commits you pass around:
+اولین عملی که بعد از نصب Git باید انجام شود، مقداردهی کردن دو متغیر نام کاربری (user name) و آدرس پست الکترونیکی (e-mail address) است. این عمل از آن جهت اهمیت دارد که در هر commit این اطلاعات به‌صورتی تغییر ناپذیر روی commit انجام شده حک می‌شوند.
 
 	$ git config --global user.name "John Doe"
 	$ git config --global user.email johndoe@example.com
 
-Again, you need to do this only once if you pass the `--global` option, because then Git will always use that information for anything you do on that system. If you want to override this with a different name or e-mail address for specific projects, you can run the command without the `--global` option when you’re in that project.
+مجدداْ یادآوری می‌شود که انجام این عمل در صورت استفاده از آپشن `--global` فقط یک مرتبه انجام می‌پذیرد، زیرا Git برای هر عملی که در سیستم انجام می‌پذیرد از این اطلاعات استفاده می‌کند. حال اگر فرد نیاز به استفاده از نام و آدرس پست الکترونیکی متفاوتی برای پروژه‌های خاصی داردُ، می‌تواند با اجرای همان دستورات البته بدون استفاده از آپشن `--global` هنگامی که در مسیر پروژه مذکور قرار دارد به مقصود خود دست یابد.
+
+### ویرایشگر کاربر ###
 
 ### Your Editor ###
 

From 1781fde635bf9d6ebcde7e9c6902012de5c371bb Mon Sep 17 00:00:00 2001
From: mxamin <amin.solhizadeh@gmail.com>
Date: Mon, 28 Jul 2014 09:04:32 +0330
Subject: [PATCH 520/690] [fa] chapter 1 complete

translation of chapter 1 completed but it needs another lookup for
spelling correction and some minor modifications.
---
 fa/01-introduction/01-chapter1.markdown | 37 ++++++++++++-------------
 1 file changed, 18 insertions(+), 19 deletions(-)

diff --git a/fa/01-introduction/01-chapter1.markdown b/fa/01-introduction/01-chapter1.markdown
index f03cf8c65..09f80590b 100644
--- a/fa/01-introduction/01-chapter1.markdown
+++ b/fa/01-introduction/01-chapter1.markdown
@@ -202,7 +202,7 @@ Insert 18333fig0107.png
 
 در سیستم‌های ویندوزی، Git در پوشه `$HOME` (متغیر محیطی `%USERPROFILE%` در ویندوز) که برای اکثر کاربران با توجه به ورژن سیستم در مسیرهای `C:\Documents and Settings\$USER‍ یا `C:\Users\$USER` (`$USER‍ در ویندوز متغیر محیطی `%USERNAME%`) قرار دارد، فایل `.gitconfig` را جستجو می‌کند. همچنین نسبت به مسیر ریشه MSys که همان مسیر نصب انتخاب شده در هنگام اجرای نصاب Git در ویندوز می‌باشد، به دنبال فایلی با نام /etc/gitconfig می‌گردد.
 
-### شناسه کاربر ###
+### شناسه ###
 
 اولین عملی که بعد از نصب Git باید انجام شود، مقداردهی کردن دو متغیر نام کاربری (user name) و آدرس پست الکترونیکی (e-mail address) است. این عمل از آن جهت اهمیت دارد که در هر commit این اطلاعات به‌صورتی تغییر ناپذیر روی commit انجام شده حک می‌شوند.
 
@@ -211,25 +211,23 @@ Insert 18333fig0107.png
 
 مجدداْ یادآوری می‌شود که انجام این عمل در صورت استفاده از آپشن `--global` فقط یک مرتبه انجام می‌پذیرد، زیرا Git برای هر عملی که در سیستم انجام می‌پذیرد از این اطلاعات استفاده می‌کند. حال اگر فرد نیاز به استفاده از نام و آدرس پست الکترونیکی متفاوتی برای پروژه‌های خاصی داردُ، می‌تواند با اجرای همان دستورات البته بدون استفاده از آپشن `--global` هنگامی که در مسیر پروژه مذکور قرار دارد به مقصود خود دست یابد.
 
-### ویرایشگر کاربر ###
+### ویرایشگر ###
 
-### Your Editor ###
-
-Now that your identity is set up, you can configure the default text editor that will be used when Git needs you to type in a message. By default, Git uses your system’s default editor, which is generally Vi or Vim. If you want to use a different text editor, such as Emacs, you can do the following:
+حال که شناسه تنظیم شد، میتوان ویرایشگر متنی پیش فرضی را معرفی کرد تا هنگامی که نیاز به نوشتن پیغامی در Git وجود دارد فراخوانی شود. به صورت پیش فرض Git از ویرایشگر پیش فرض سیستم برای این امر استفاده می کند، که معمولاً Vi یا Vim است. اگر نظر شخص به استفاده از ویرایشگر متنی متفاوتی مانند Emacs باشد، میتوان به صورت ذیل عمل کرد:
 
 	$ git config --global core.editor emacs
 
-### Your Diff Tool ###
+### ابزار Diff ###
 
-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:
+ابزار مفید دیگری که شاید نیاز به تنظیم داشته باشد، ابزار diff پیش فرضی است که برای رفع مغایرت ایجاد شده در استفاده از دستور merge استفاده میگردد. به عنوان مثال اگر هدف استفاده از vimdiff باشد خواهیم داشت:
 
 	$ git config --global merge.tool vimdiff
 
-Git accepts kdiff3, tkdiff, meld, xxdiff, emerge, vimdiff, gvimdiff, ecmerge, and opendiff as valid merge tools. You can also set up a custom tool; see Chapter 7 for more information about doing that.
+Git ابزارهای kdiff3، tkdiff، meld، xxdiff، emerge، vimdiff، gvimdiff، ecmerge و opendiff را به عنوان ابزارهایی معتبر جهت merge می شناسد. با این وجود امکان تعریف ابزاری شخصی نیز وجود دارد؛ برای اطلاعات بیشتر جهت انجام این مورد میتوانید به فصل 7 مراجعه کنید.
 
-### Checking Your Settings ###
+### بررسی تنظیمات ###
 
-If you want to check your settings, you can use the `git config --list` command to list all the settings Git can find at that point:
+برای مشاهده و بررسی تنظیمات، میتوان از دستور `git config --list` استفاده کرد که در نتیجه آن Git تمامی تنظیمات موجود تا آن لحظه را در قالب لیستی نمایش می دهد:
 
 	$ git config --list
 	user.name=Scott Chacon
@@ -240,28 +238,29 @@ If you want to check your settings, you can use the `git config --list` command
 	color.diff=auto
 	...
 
-You may see keys more than once, because Git reads the same key from different files (`/etc/gitconfig` and `~/.gitconfig`, for example). In this case, Git uses the last value for each unique key it sees.
+احتمال دارد در این لیست کلیدهایی بیش از یک بار مشاهده شود، دلیل این امر آن است که Git کلید مشابهی را از فایلهای مختلفی (مانند `/etc/giconfig` و `~/.gitconfig`) خوانده باشد. در اینگونه موارد، Git آخرین مقدار کلید منحصر به فردی که مشاهده می کند را مورد استفاده قرار میدهد.
 
-You can also check what Git thinks a specific key’s value is by typing `git config {key}`:
+همچنین برای مشاهده مقدار مورداستفاده یک کلید خاص توسط Git، میتوان از دستور `git config {key}` استفاده کرد:
 
 	$ git config user.name
 	Scott Chacon
 
-## Getting Help ##
+## دریافت راهنمایی ##
 
-If you ever need help while using Git, there are three ways to get the manual page (manpage) help for any of the Git commands:
+هرگاه در استفاده از Git نیازمند راهنمایی بودید، سه روش برای مشاهده صفحه راهنما (manpage) هرگونه دستوری در Git وجود دارد:
 
 	$ git help <verb>
 	$ git <verb> --help
 	$ man git-<verb>
 
-For example, you can get the manpage help for the config command by running
+برای مثال، برای مشاهده راهنما manpage دستور config داریم
 
 	$ git help config
 
-These commands are nice because you can access them anywhere, even offline.
-If the manpages and this book aren’t enough and you need in-person help, you can try the `#git` or `#github` channel on the Freenode IRC server (irc.freenode.net). These channels are regularly filled with hundreds of people who are all very knowledgeable about Git and are often willing to help.
+این دستورات از آن جهت که میتوان از هر مکانی، حتی در حالت آفلاین، به آنها دسترسی پیدا کرد ابزاری کاربردی میباشند.
+اگر manpageها و این کتاب جوابگوی نیاز شما نبودند و نیاز به راهنمایی فردی پیدا کردید، میتوانید به کانالهای `#git` یا `#github` در سرور Freenode IRC (irc.freenode.net) مراجعه کنید.
+معمولاً این کانالها مملؤ از افرادی با سطح دانش بالا در زمینه Git هستند که آماده راهنمایی رساندن به شما می باشند.
 
-## Summary ##
+## خلاصه ##
 
-You should have a basic understanding of what Git is and how it’s different from the CVCS you may have been using. You should also now have a working version of Git on your system that’s set up with your personal identity. It’s now time to learn some Git basics.
+با مطالعه این فصل شما باید درک اولیه ای از این که Git چیست و چه تفاوتی با دیگر CVCSهایی که احتمالاً از آن استفاده میکردید پیدا کرده باشد. همچنین شما باید نسخه آماده به کاری از Git را روی سیستم خود داشته باشید که با شناسه شخصی شما تنظیم شده است. حال زمان یادگیری اصول اولیه Git است.

From 1cb178b66d7e015fdfb5df96ba3bd6ec337a9f03 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Mon, 28 Jul 2014 17:46:34 +0200
Subject: [PATCH 521/690] [it] Update URL used in cURL to fetch from Grit
 library

Add -L flag to cURL command to follow any redirects

cURL by default will not follow redirects, leading
to blank file unless the `-L` flag is included since
all resources once hosted on raw.github.com are now
on the raw.githubusercontent.com domain.

Fixes issue mentioned at https://github.com/git/git-scm.com/issues/422
See also PR #811
---
 it/09-git-internals/01-chapter9.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/it/09-git-internals/01-chapter9.markdown b/it/09-git-internals/01-chapter9.markdown
index b39dc0830..56fe57b36 100644
--- a/it/09-git-internals/01-chapter9.markdown
+++ b/it/09-git-internals/01-chapter9.markdown
@@ -451,7 +451,7 @@ Torniamo agli oggetti del database per il tuo repository Git di test. A questo p
 
 Git comprime il contenuto di questi file con zlib e, poiché non stai memorizzando molte cose, complessivamente tutti questi file occupano solo 925 bytes. Aggiungeremo al repository del contenuto più pesante per dimostrare un’interessante caratteristica di Git. Aggiungi il file repo.rb dalla libreria Grit che abbiamo visto prima: sono circa 12K di sorgenti:
 
-	$ curl http://github.com/mojombo/grit/raw/master/lib/grit/repo.rb > repo.rb
+	$ curl -L http://github.com/mojombo/grit/raw/master/lib/grit/repo.rb > repo.rb
 	$ git add repo.rb 
 	$ git commit -m ‘aggiunto repo.rb'
 	[master 484a592] aggiunto repo.rb

From 37947df9797c67b03d24d34a262a6e231b0c56e9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Jos=C3=A9=20Barbosa?= <kide.lemark@gmail.com>
Date: Wed, 30 Jul 2014 16:36:56 -0300
Subject: [PATCH 522/690] Phrase fix in line 35

Updated the 'or' clause for the correct in portuguese is 'ou'
---
 pt-br/01-introduction/01-chapter1.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/pt-br/01-introduction/01-chapter1.markdown b/pt-br/01-introduction/01-chapter1.markdown
index 3d0937919..aa852021c 100644
--- a/pt-br/01-introduction/01-chapter1.markdown
+++ b/pt-br/01-introduction/01-chapter1.markdown
@@ -32,7 +32,7 @@ Entretanto, esse arranjo também possui grandes desvantagens. O mais óbvio é q
 
 ### Sistemas de Controle de Versão Distribuídos ###
 
-É aí que surgem os Sistemas de Controle de Versão Distribuídos (Distributed Version Control System ou DVCS). Em um DVCS (tais como Git, Mercurial, Bazaar or Darcs), os clientes não apenas fazem cópias das últimas versões dos arquivos: eles são cópias completas do repositório. Assim, se um servidor falha, qualquer um dos repositórios dos clientes pode ser copiado de volta para o servidor para restaurá-lo. Cada checkout (resgate) é na prática um backup completo de todos os dados (veja Figura 1-3).
+É aí que surgem os Sistemas de Controle de Versão Distribuídos (Distributed Version Control System ou DVCS). Em um DVCS (tais como Git, Mercurial, Bazaar ou Darcs), os clientes não apenas fazem cópias das últimas versões dos arquivos: eles são cópias completas do repositório. Assim, se um servidor falha, qualquer um dos repositórios dos clientes pode ser copiado de volta para o servidor para restaurá-lo. Cada checkout (resgate) é na prática um backup completo de todos os dados (veja Figura 1-3).
 
 Insert 18333fig0103.png
 Figura 1-3. Diagrama de Controle de Versão Distribuído.

From 7376aaff1a6e8f7de8536ca261032cc36903aab3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Stian=20Dr=C3=B8bak?= <sum41rules4@hotmail.com>
Date: Thu, 31 Jul 2014 17:56:11 +0200
Subject: [PATCH 523/690] translated 3 sections

---
 no-nb/01-introduction/01-chapter1.markdown | 25 +++++++++++-----------
 1 file changed, 13 insertions(+), 12 deletions(-)

diff --git a/no-nb/01-introduction/01-chapter1.markdown b/no-nb/01-introduction/01-chapter1.markdown
index 6957dc82f..6966cdf11 100644
--- a/no-nb/01-introduction/01-chapter1.markdown
+++ b/no-nb/01-introduction/01-chapter1.markdown
@@ -8,7 +8,7 @@ Hva er versjonskontroll, og hvorfor burde du bry deg? Versjonskontroll er et sys
 
 Er du en grafisk designer eller arbeider med webdesign og ønsker å beholde alle versjoner av et bilde eller en layout (som du sannsynligvis vil), så er det lurt å bruke et Version Control System (VCS). Et VCS gjør det mulig for deg å: tilbakestille filer til en tidligere utgave, tilbakestille hele prosjektet til en tidligere utgave, sjekke forandringer over tid, se hvem som sist forandret noe som muligens forårsaker et problem, hvem som introduserte en sak og når, osv. Å benytte seg av et VCS betyr også at dersom du roter det til eller mister filer, kan du vanligvis komme tilbake opp å kjøre raskt og enkelt. I tillegg, så får du alt dette uten at det krever noe videre av deg eller systemet ditt.
 
-### Lokalt versjonsstyringssystem ###
+### Lokalt versjonskontrollsystem ###
 
 Mange folks valgte versjonskontrollmetode innebærer å kopiere filer til en annen mappe (kanskje med datomerking hvis de er smarte). Denne tilnærmingen er vanlig, fordi den er enkel, men det kan også fort gå galt. Det er lett å glemme hvilken mappe man befinner seg i og så ved et uhell skrive til feil fil, eller kopiere over filer man ikke mente.
 
@@ -30,28 +30,29 @@ This setup offers many advantages, especially over local VCSs. For example, ever
 
 However, this setup also has some serious downsides. The most obvious is the single point of failure that the centralized server represents. If that server goes down for an hour, then during that hour nobody can collaborate at all or save versioned changes to anything they’re working on. If the hard disk the central database is on becomes corrupted, and proper backups haven’t been kept, you lose absolutely everything—the entire history of the project except whatever single snapshots people happen to have on their local machines. Local VCS systems suffer from this same problem—whenever you have the entire history of the project in a single place, you risk losing everything.
 
-### Distributed Version Control Systems ###
+### Distribuerte versjonkontrollsystemer ###
 
-This is where Distributed Version Control Systems (DVCSs) step in. In a DVCS (such as Git, Mercurial, Bazaar or Darcs), clients don’t just check out the latest snapshot of the files: they fully mirror the repository. Thus if any server dies, and these systems were collaborating via it, any of the client repositories can be copied back up to the server to restore it. Every checkout is really a full backup of all the data (see Figure 1-3).
+Her er det Distribuerte Versjonkontrollsystemer  (DVCSer) komme inn. I et DVCS (slik som Git, Mercurial, Bazaar eller Darcs), så henter ikke klientene bare ut det nyeste bildet av filene: de speilere hele repositoriet. Så derfor, om en server skulle dø, og disse systemene samarbeidet via den, så kan hvilken som helst av klient repositoriene bli kopiert opp til serveren for å fikse det. Hver utsjekking er en hel backup av alle dataene (see Figure 1-3).
 
 Insert 18333fig0103.png
 Figure 1-3. Distributed version control diagram.
 
-Furthermore, many of these systems deal pretty well with having several remote repositories they can work with, so you can collaborate with different groups of people in different ways simultaneously within the same project. This allows you to set up several types of workflows that aren’t possible in centralized systems, such as hierarchical models.
+Mange av disse systemene håndterer også veldig godt det å ha flere fjerne repositorier å jobbe mot, sq du kan sammarbeide med flere forskjellige grupper folk på forskjellige måter samtidig innen for det samme prosjektet. Dette lar deg sette opp flere arbeidsmåter som ikke er mulig i sentraliserte systemer, som hierarkiske modeller.
 
-## A Short History of Git ##
+## Kort Historie om Git ##
 
-As with many great things in life, Git began with a bit of creative destruction and fiery controversy. The Linux kernel is an open source software project of fairly large scope. For most of the lifetime of the Linux kernel maintenance (1991–2002), changes to the software were passed around as patches and archived files. In 2002, the Linux kernel project began using a proprietary DVCS system called BitKeeper.
+Som mange flotte ting i livet, så begynte Git med litt kreativ ødeleggelse og voldsom uenighet. Linux kjernen er et åpenkildekode prosjekt ved en ganske vidt skop. Mesteparten av livet til Linux kjerne vedlikeholdet (1991-2002), så var endringer i programvaren sendt rundt som patcher og arkiverte filer. I 2002 begynte Linux kjerne prosjektet å bruke et proprietært DVCS system med navn BitKeeper. 
 
-In 2005, the relationship between the community that developed the Linux kernel and the commercial company that developed BitKeeper broke down, and the tool’s free-of-charge status was revoked. This prompted the Linux development community (and in particular Linus Torvalds, the creator of Linux) to develop their own tool based on some of the lessons they learned while using BitKeeper. Some of the goals of the new system were as follows:
+I 2005 så falt forholdet mellom samholdet som utviklet Linux-kjernen og det komersielle firmaet som utviklet Bitkeeper sammen, og verktøyets gratis-bruk status ble fjernet. Dette fikk Linux utviklingssamholdet (og spesielt Linux Torvals, skaperen av Linux) til å utvikle deres eget verktøy med grunnlag i noen av tingene de lærte mens de brukte BitKeeper. Noen av målene for det nye systemet ble som følger:
 
-*	Speed
-*	Simple design
-*	Strong support for non-linear development (thousands of parallel branches)
-*	Fully distributed
+*	Fart
+*	Enkelt design
+*	Sterk støtter for ikke-lineær utvikling (tusenvis av parallelle grener)
+*	Helt distribuert
 *	Able to handle large projects like the Linux kernel efficiently (speed and data size)
+*	I stand til å håndtere store prosjekter som Linux-kjernern effektivt (fart og datastørrelse)
 
-Since its birth in 2005, Git has evolved and matured to be easy to use and yet retain these initial qualities. It’s incredibly fast, it’s very efficient with large projects, and it has an incredible branching system for non-linear development (See Chapter 3).
+Siden den ble skapt i 2005, har Git utviklet seg og modnet til å bli et enkelt å bruke men forsatt beholde disse opprinnelige kvalitetene. Den er er utrolig rask, og den er veldig effektiv med store prosjekter, og den har et utrolig avgreningsystem for ikke-lineær utvikling (See Chapter 3).
 
 ## Git Basics ##
 

From 327906ab6ae0ecdf712cc4b377ebc544b88592e9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Stian=20Dr=C3=B8bak?= <sum41rules4@hotmail.com>
Date: Thu, 31 Jul 2014 18:18:00 +0200
Subject: [PATCH 524/690] added no-nb to makeebooks script

---
 makeebooks | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/makeebooks b/makeebooks
index 5d2f308e4..25d3310ea 100755
--- a/makeebooks
+++ b/makeebooks
@@ -83,6 +83,11 @@ ARGV.each do |lang|
       figure_title = 'Obrázek'
       book_title = 'Pro Git — profesionální správa verzí'
       comments = 'Licence: Creative Commons Attribution-Non Commercial-Share Alike 3.0 license'
+    elsif lang == "no-nb"
+        figure_title = 'Figur'
+        book_title = 'Pro Git - profesjonell versjonkontroll'
+        comments = 'Lisens: Creative Commons Attribution-Non Commercial-Share Alike 3.0 license'
+      
     end
 
     book_content = %(<html xmlns="http://www.w3.org/1999/xhtml"><head><title>#{book_title}</title></head><body>)

From dad6608b46eacb107cb128a0ca67daf14c6d409f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Stian=20Dr=C3=B8bak?= <sum41rules4@hotmail.com>
Date: Thu, 31 Jul 2014 19:33:27 +0200
Subject: [PATCH 525/690] 'no-NB' translated 2 sub-sections chapter 1

---
 no-nb/01-introduction/01-chapter1.markdown | 25 +++++++++++-----------
 1 file changed, 13 insertions(+), 12 deletions(-)

diff --git a/no-nb/01-introduction/01-chapter1.markdown b/no-nb/01-introduction/01-chapter1.markdown
index 6966cdf11..1fdb7d062 100644
--- a/no-nb/01-introduction/01-chapter1.markdown
+++ b/no-nb/01-introduction/01-chapter1.markdown
@@ -54,31 +54,32 @@ I 2005 så falt forholdet mellom samholdet som utviklet Linux-kjernen og det kom
 
 Siden den ble skapt i 2005, har Git utviklet seg og modnet til å bli et enkelt å bruke men forsatt beholde disse opprinnelige kvalitetene. Den er er utrolig rask, og den er veldig effektiv med store prosjekter, og den har et utrolig avgreningsystem for ikke-lineær utvikling (See Chapter 3).
 
-## Git Basics ##
+## Grunnleggende Git ##
 
-So, what is Git in a nutshell? This is an important section to absorb, because if you understand what Git is and the fundamentals of how it works, then using Git effectively will probably be much easier for you. As you learn Git, try to clear your mind of the things you may know about other VCSs, such as Subversion and Perforce; doing so will help you avoid subtle confusion when using the tool. Git stores and thinks about information much differently than these other systems, even though the user interface is fairly similar; understanding those differences will help prevent you from becoming confused while using it.
+Så, hva er Git i et nøtteskall? Dette er en veldig viktig seksjon og ta innover seg, fordi om du forstår hva Git er og det fundamentelle rundt hvordan det virker, så vil det å bruke Git effektiv, sannsynligvis bli mye enklere for deg. Etter som du lærer Git, prøv å tøm tankene for de tingene du vet om andre VCSer, som Subversion og Perforce; å gjøre det vil hjelpe deg å unngå småforvirring når du bruker verktøyet. Git lagrer og tenker på informasjon veldig annerledes disse andre systemene, selv om bruker grensesnittet er ganske likt; å forstå de forskjellene vil hjelpe deg unngå å bli forvirret mens du bruker det.
 
-### Snapshots, Not Differences ###
 
-The major difference between Git and any other VCS (Subversion and friends included) is the way Git thinks about its data. Conceptually, most other systems store information as a list of file-based changes. These systems (CVS, Subversion, Perforce, Bazaar, and so on) think of the information they keep as a set of files and the changes made to each file over time, as illustrated in Figure 1-4.
+### Bilder, Ikke Forskjeller ###
+
+Hovedforskjellen mellom Git og andre VCS verktøy (inklusivt Subversion og dens venner) er hvordan den tenker på sin data. Konseptuelt, så lagrer de fleste andre systemer informasjon som en liste over filbaserte endringer. Disse systemene (CVS, Subversion, Perforce, Bazaar, og så vidre) tenker på informasjon som det tar vare på som et sett med filer og endringene gjort til hver fil over tid, som illustrert i Figur 1-4.
 
 Insert 18333fig0104.png
-Figure 1-4. Other systems tend to store data as changes to a base version of each file.
+Figure 1-4. Andre systemer pleier å lagre data som endringer til en grunnleggende versjon av hver fil.
 
-Git doesn’t think of or store its data this way. Instead, Git thinks of its data more like a set of snapshots of a mini filesystem. Every time you commit, or save the state of your project in Git, it basically takes a picture of what all your files look like at that moment and stores a reference to that snapshot. To be efficient, if files have not changed, Git doesn’t store the file again—just a link to the previous identical file it has already stored. Git thinks about its data more like Figure 1-5.
+Git verken tenker eller lagrere dataen på denne måten. Istedet så tenker Git på dataen mer som et sett med bilder av mini filsystemer. Hver gang du commit-er, eller lagrere tilstanden for prosjektet ditt i Git, så tar den i hovedask et bilde av hvordan alle filene dine ser ut i det øyeblikket of lagrer en referanse til det bildet. For å være effektiv, hvis filer ikke har blitt endre, så lagrer ikke Git filen igjen, den bare linker til forrige indentiske fil som den allerede har lagret. Git tenker på dataen mer som Figure 1-5.
 
 Insert 18333fig0105.png
-Figure 1-5. Git stores data as snapshots of the project over time.
+Figure 1-5.  Git lagrere data som et bilde av prosjektet over tid.
 
-This is an important distinction between Git and nearly all other VCSs. It makes Git reconsider almost every aspect of version control that most other systems copied from the previous generation. This makes Git more like a mini filesystem with some incredibly powerful tools built on top of it, rather than simply a VCS. We’ll explore some of the benefits you gain by thinking of your data this way when we cover Git branching in Chapter 3.
+Dette er et viktig skille mellom Git og nesten alle andre VCSer. Det gjør at Git revurderer nesten alle aspekter av versjonkontroll som de fleste andre systemer kopierte fra den forrige generasjonen. Dette gjør Git mer til et mini-filsystem som har utrolig kraftige verktøy bygd oppå seg, istedet for bare en VCS. Vi vil utforske noen av fordelene du vil få ved å tenke på dataen din på denne måten når vi dekker Git avgrening  i Kapitell 3.
 
-### Nearly Every Operation Is Local ###
+### Nærmest Alle Operasjoner Er Lokale  ###
 
-Most operations in Git only need local files and resources to operate — generally no information is needed from another computer on your network.  If you’re used to a CVCS where most operations have that network latency overhead, this aspect of Git will make you think that the gods of speed have blessed Git with unworldly powers. Because you have the entire history of the project right there on your local disk, most operations seem almost instantaneous.
+De fleste operasjonene i Git trenger bare lokale filer og resurser for å operer - generelt sett så er ikke informasjon fra noen annen maskin på nettverket ditt nødvendig. Hvis du har brukt en CVCS hvor de fleste operasjoner har den type nettverk forsinkelse, så vil dette aspektet av Git få deg til å tenke at gudene for fart har velsignet Git med uparallelle krefter. Fordi du har hele historien til prosjektet rett der på den lokale disk, så virker de fleste operasjoner som om de nesten skjer med en gang.
 
-For example, to browse the history of the project, Git doesn’t need to go out to the server to get the history and display it for you—it simply reads it directly from your local database. This means you see the project history almost instantly. If you want to see the changes introduced between the current version of a file and the file a month ago, Git can look up the file a month ago and do a local difference calculation, instead of having to either ask a remote server to do it or pull an older version of the file from the remote server to do it locally.
+For eksempel, for å se gjennom historien til prosjektet, så trenger ikke Git å gå til serveren for å få historien, og vise det til deg- den simpelthen leser den rett fra din likale database. Dette betyr at du ser prosjekt historien nesten med en gang. Hvis du ønsker å se endringene introdusert mellom den nåværende versjonen av filen og filen for en måned isden, så kan Git sjekke den filen fra en måned siden og gjøre en lokal forskjell kalkulasjon, istedet for å enten måtte spøre en server om å gjøre det, eller å måtte hente en eldre versjon av filen fra den serveren for å gjøre det lokalt.
 
-This also means that there is very little you can’t do if you’re offline or off VPN. If you get on an airplane or a train and want to do a little work, you can commit happily until you get to a network connection to upload. If you go home and can’t get your VPN client working properly, you can still work. In many other systems, doing so is either impossible or painful. In Perforce, for example, you can’t do much when you aren’t connected to the server; and in Subversion and CVS, you can edit files, but you can’t commit changes to your database (because your database is offline). This may not seem like a huge deal, but you may be surprised what a big difference it can make.
+Dette betyr også at det er veldig lite du ikke kan gære om du er offline eller ikke er på VPN. Du kan gå på et fly, eller et tog og så ønske å jobbe litt, og du kan gladelig comitte det fram til du kommer til en nettverkstilkobling for å laste det opp. Hvis du går hjem og ikke kan få VPN klienten til å virke skikkelig, så kan du fortsatt jobbe. I mange systemer, så er det enten umulig å gjøre, eller smertefult. I Perforce, for eksempel, så kan du ikke gjære stort når du ikke er koblet til serveren, og i Subversion og CVS, så kan du endre filer, men du kan ikke bruke commit på endringene dine til databasen (siden databasen din er offline). Dette virker kanskje ikke som noe stort, men du kan bli overrasket over hvor stor forskjell det kan utgjøre.
 
 ### Git Has Integrity ###
 

From e11b06b2376e35ee84d78077290299a7615dc972 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Stian=20Dr=C3=B8bak?= <sum41rules4@hotmail.com>
Date: Thu, 31 Jul 2014 21:19:34 +0200
Subject: [PATCH 526/690] no-NB translated 2 sections in Chapther 1

"Git has Integrity"
"Git generally only add data"
---
 no-nb/01-introduction/01-chapter1.markdown | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/no-nb/01-introduction/01-chapter1.markdown b/no-nb/01-introduction/01-chapter1.markdown
index 1fdb7d062..1163c12c6 100644
--- a/no-nb/01-introduction/01-chapter1.markdown
+++ b/no-nb/01-introduction/01-chapter1.markdown
@@ -81,21 +81,21 @@ For eksempel, for å se gjennom historien til prosjektet, så trenger ikke Git 
 
 Dette betyr også at det er veldig lite du ikke kan gære om du er offline eller ikke er på VPN. Du kan gå på et fly, eller et tog og så ønske å jobbe litt, og du kan gladelig comitte det fram til du kommer til en nettverkstilkobling for å laste det opp. Hvis du går hjem og ikke kan få VPN klienten til å virke skikkelig, så kan du fortsatt jobbe. I mange systemer, så er det enten umulig å gjøre, eller smertefult. I Perforce, for eksempel, så kan du ikke gjære stort når du ikke er koblet til serveren, og i Subversion og CVS, så kan du endre filer, men du kan ikke bruke commit på endringene dine til databasen (siden databasen din er offline). Dette virker kanskje ikke som noe stort, men du kan bli overrasket over hvor stor forskjell det kan utgjøre.
 
-### Git Has Integrity ###
+### Git Har Integritet ###
 
-Everything in Git is check-summed before it is stored and is then referred to by that checksum. This means it’s impossible to change the contents of any file or directory without Git knowing about it. This functionality is built into Git at the lowest levels and is integral to its philosophy. You can’t lose information in transit or get file corruption without Git being able to detect it.
+Alt i Git er sjekksummert før det er lagret, og så blir den referert til med den sjekksummen. Dette betyr at det umulig å endre innhodlet på en fil eller mappe uten at Git vet om det. Denne funksjonaliteten er bygd inn i Git på de laveste nivåene og er viktig del av dens filosofi. Du kan ikke miste informasjon når den prossesserer endringer eller ende opp med en korrupt fil uten at Git er i stand til å oppdage det.
 
-The mechanism that Git uses for this checksumming is called a SHA-1 hash. This is a 40-character string composed of hexadecimal characters (0–9 and a–f) and calculated based on the contents of a file or directory structure in Git. A SHA-1 hash looks something like this:
+Mekanismen Git bruker for denne sjekksummeringen er kalt en SHA-1 hash. Dette er en 40-tegn lang tekst satt sammen av hexadecimal-tegn (0-9 og a-f) og er kalkulert baser på innholdet av en fil og mappe structuren i Git. En SHA-1 hash ser ut noe sånt som dette:
 
 	24b9da6552252987aa493b52f8696cd6d3b00373
 
-You will see these hash values all over the place in Git because it uses them so much. In fact, Git stores everything not by file name but in the Git database addressable by the hash value of its contents.
+Du vil se disse hash verdiene overalt i Git fordi den bruker dem så mye. Git lagrer faktisk alt, ikke med navn, men i Git databasen adresserbart med hash verdien av innholdet dens.
 
-### Git Generally Only Adds Data ###
+### Git Legger Generelt Bare Til Data ###
 
-When you do actions in Git, nearly all of them only add data to the Git database. It is very difficult to get the system to do anything that is not undoable or to make it erase data in any way. As in any VCS, you can lose or mess up changes you haven’t committed yet; but after you commit a snapshot into Git, it is very difficult to lose, especially if you regularly push your database to another repository.
+Når du gjør ting i Git, så vil nesten alle bare legge til data til Git databasen. Det er veldig vanskelig å få systemet til å gjøre noe som ikke kan angres, eller få det til å slette data på en eller annen måte. Som i en hver VCS, så kan du miste eller rote til endringer du ikke har commitet enda; men etter du har commited et bilde inn i Git, så er det veldig vanskelig å miste det, spesielt om du jevnlig bruker push for å sende databasen til en annen repository.
 
-This makes using Git a joy because we know we can experiment without the danger of severely screwing things up. For a more in-depth look at how Git stores its data and how you can recover data that seems lost, see Chapter 9.
+Dette gjør det å bruke Git til en gledelig opplevelse fordi vi vet at vi kan eksperimentere uten fare for å virkelig rote til ting skikkelig. For en mer dypere innsyn i hvoradn Git lagerer data og hvordan du kan få tilbake data som virker tapt, se Kapitel 9.
 
 ### The Three States ###
 

From fa7b20f4a00d4fd2f0f37b8b04b7a52dd0c7869b Mon Sep 17 00:00:00 2001
From: mxamin <amin.solhizadeh@gmail.com>
Date: Fri, 1 Aug 2014 00:08:45 +0430
Subject: [PATCH 527/690] [fa] Update Chapter 1

Some minor modification on chapter 1.
Added some notes for better translation.
Updated README file.
---
 fa/01-introduction/01-chapter1.markdown | 166 ++++++++++++------------
 fa/NOTES.en-fa.md                       | 143 ++++++++++++++++++++
 fa/README.md                            |   6 +-
 3 files changed, 227 insertions(+), 88 deletions(-)
 create mode 100644 fa/NOTES.en-fa.md

diff --git a/fa/01-introduction/01-chapter1.markdown b/fa/01-introduction/01-chapter1.markdown
index 09f80590b..f259f012f 100644
--- a/fa/01-introduction/01-chapter1.markdown
+++ b/fa/01-introduction/01-chapter1.markdown
@@ -1,138 +1,134 @@
 # سرآغاز #
 
-در این فصل در رابطه با شروع کار با Git صحبت خواهد شد. این فصل با توضیحاتی در رابطه با تاریخچه ابزارهای کنترل ورژن شروع می شود، سپس چگونگی راه اندازی Git برروی یک سیستم خاص آموزش داده می شود و در انتها انجام تنظیمات موردنیاز برروی این نرم افزار جهت شروع به کار با آن مورد بررسی قرار می گیرد. در انتهای این فصل خواننده باید دلیل وجود و استفاده از Git را بداند و همچنین باید محیط کار را برای استفاده از آن فراهم کرده باشد.
+در این فصل در رابطه با شروع کار با Git صحبت خواهد شد. این فصل با توضیحاتی در رابطه با تاریخچه ابزارهای کنترل نسخه شروع می‌شود، سپس چگونگی راه اندازی Git برروی یک سیستم خاص آموزش داده خواهد شد و در انتها انجام تنظیمات موردنیاز برروی این نرم افزار جهت شروع به کار با آن مورد بررسی قرار می‌گیرد. در انتهای این فصل خواننده باید دلیل وجود و استفاده از Git را بداند و همچنین باید محیط کار را برای استفاده از آن فراهم کرده باشد.
 
-## کنترل ورژن ##
+## کنترل نسخه ##
 
-کنترل ورژن چیست و چه اهمیتی دارد؟ کنترل ورژن سیستمی است که تغییرات مربوط به یک یا چندین فایل را در طول زمان ذخیره می کند، تا کاربر بتواند به ورژن های قبلی مراجعت داشته باشد. در مثالهای استفاده شده در این کتاب از فایل های سورس نرم افزار جهت نمایش کنترل ورژن استفاده میشود، ولی با این وجود میتوان هر نوع فایلی را تحت کنترل ورژن قرار داد.
+کنترل نسخه چیست و چه اهمیتی دارد؟ کنترل نسخه سیستمی است که تغییرات مربوط به یک یا چندین فایل را در طول زمان ذخیره می‌کند، تا کاربر بتواند به نسخه‌های قبلی مراجعت داشته باشد. در مثال‌های استفاده شده در این کتاب از فایل های سورس نرم افزار جهت نمایش کنترل نسخه استفاده می‌شود، ولی با این وجود می‌توان هر نوع فایلی را تحت کنترل نسخه قرار داد.
 
-اگر شما یک گرافیست یا طراح وب باشید و تصمیم به نگهداری تمامی ورژنهای یک عکس یا ساختار باشید (که قطعا به همین منوال است)، استفاده از یک سیستم کنترل ورژن (VCS) راهبردی عاقلانه است. یک VCS این امکان را به شما میدهد که: فایلها را به یک وضعیت قبل برگردانید، یک پروژه را به یک وضعیت قبل برگردانید، تغییرات انجام گرفته در مرور زمان را مشاهده کنید، باعث و بانی تغییری را بیابید که منجر به ایجاد خطا یا مشکلی در سیستم شده است، چه کسی و چه زمانی مسئلهای خاص مطرح شده است و بسیاری موارد دیگر. استفاده از یک VCS حتی این امکان را به شما میدهد که اگر احیاناً خطایی مرتکب شدید یا فایلی را اشتباهاً حذف یا از دست دادید، به راحتی آن را اصلاح و بازیابی کنید.
+اگر شما یک گرافیست یا طراح وب باشید و تصمیم به نگهداری تمامی نسخه‌های یک عکس یا ساختار را داشته باشید (که قطعًا به همین منوال است)، استفاده از یک سیستم کنترل نسخه (VCS) راهبردی عاقلانه است. یک VCS این امکان را به شما می‌دهد تا: فایل‌ها یا پروژه‌ای را به یک وضعیت قبل برگردانید، تغییرات انجام گرفته در مرور زمان را مشاهده کنید، باعث و بانی تغییری را که منجر به ایجاد خطا یا مشکلی در سیستم شده است بیابید، چه کسی و چه زمانی موردی خاص را مطرح کرده است و بسیاری موارد دیگر. استفاده از یک VCS حتی این امکان را به شما می‌دهد که اگر احیاناً خطایی مرتکب شدید یا فایلی را اشتباهاً حذف یا از دست دادید، به راحتی آن را اصلاح و بازیابی کنید.
 
-### سیستمهای کنترل ورژن محلی ###
+### سیستمهای کنترل نسخه محلی ###
 
-روشی که اکثر کاربران جهت کنترل ورژن انتخاب میکنند شامل کپی کردن فایلها در پوشهای دیگر است (البته اگر هوشمند باشد، پوشه موردنظر را با تاریخ و زمانی مشخص نامگذاری میکنند). چنین روشی به جهت سادگی بین کاربران بسیار رایج میباشد، ولی خطاپذیری بالایی نیز دارد. در این روش امکان دارد فرد به آسانی پوشهای که در آن قرار دارد را فراموش کند و به اشتباه شروع به تغییر برروی فایلهایی کند که مدنظر او نیست.
+روشی که اکثر کاربران جهت کنترل نسخه انتخاب می‌کنند شامل کپی کردن فایل‌ها در پوشه‌های دیگر است (البته اگر هوشمندی نشان دهند، پوشه موردنظر را با تاریخ و زمان مشخصی نامگذاری می‌کنند). چنین روشی به جهت سادگی بین کاربران بسیار رایج است، ولی خطاپذیری بالایی نیز دارد. در این روش امکان دارد فرد به آسانی پوشه‌ای که در آن قرار دارد را فراموش کرده و به اشتباه دست به تغییر فایل‌هایی بزند که مدنظر او نیست.
 
-برای مقابله با این موذل، برنامه نویسان از زمانهای بسیار قبل اقدام به توسعه VCSها زده اند که در بردارنده پایگاه داده ساده ای هستند به گونه ای که تمامی تغییرات انجام شده برروی فایلهای هدف را در قالب کنترل رویژن نگهداری می کنند (تصویر 1-1)
+برای مقابله با این موذل، برنامه نویسان از زمان‌های بسیار قبل اقدام به توسعه VCSها زده‌اند که در بردارنده پایگاه داده ساده‌ای هستند به گونه ای که تمامی تغییرات انجام شده برروی فایل‌های هدف را در قالب کنترل نسخه نگهداری می‌کنند (تصویر 1-1)
 
 Insert 18333fig0101.png
-تصویر 1-1. دیاگرام کنترل ورژن محلی.
+تصویر 1-1. دیاگرام کنترل نسخه محلی.
 
-یکی از رایجترین ابزارهای VCS سیستمی با نام rcs بوده است، که هم اکنون نیز به همراه تعداد زیادی از کامپیوترهای امروزی نیز توزیع می شود. حتی سیستم عامل رایج Mac OS X نیز با نصب ابزارهای توسعه توسط کاربر برروی آن، دستور خط فرمان rcs را در اختیار فرد قرار میدهد. این ابزار به زبانی ساده با حفظ مجموعه ای از پچها (که تغییرات بین فایلها میباشند) از یک رویژن به رویژنی دیگر در قالب فرمتی خاص برروی دیسک عمل میکند؛ با چنین سیستمی این ابزار قادر است با متصل کردن پچها به یکدیگر توانایی بازسازی هر فایلی را در هر نقطه ای از زمان داشته باشد.
+یکی از رایجترین ابزارهای VCS سیستمی با نام rcs بوده است، که هم اکنون نیز به همراه تعداد زیادی از کامپیوترهای امروزی نیز توزیع می‌شود. حتی سیستم عامل رایج Mac OS X نیز با نصب ابزارهای توسعه توسط کاربر برروی آن، دستور خط فرمان rcs را در اختیار فرد قرار می‌دهد. این ابزار به زبانی ساده با حفظ مجموعه‌ای از وصله‌ها (که تغییرات بین فایل‌ها می‌باشند) از یک نسخه به نسخه‌ای دیگر در قالب فرمتی خاص برروی دیسک عمل می‌کند؛ این ابزار با اجرای چنین سیستمی قادر است با متصل کردن وصله‌ها به یکدیگر توانایی بازسازی هر فایلی را در هر لحظه‌ای از زمان داشته باشد.
 
-### سیستمهای کنترل ورژن مرکزی ###
+### سیستمهای کنترل نسخه‌ مرکزی ###
 
-مسئله مهم دیگری که کاربران با آن مواجه میشوند، نیاز آنها به همکاری با دیگر توسعه دهندگان برروی سیستمهای دیگر است. برای حل این مسئله، سیستمهای کنترل ورژن مرکزی (CVCSs) توسعه یافتند. چنین سیستمهایی مانند CVS، Subversion و Perforce در بردارنده سروری مرکزی هستند که تمامی ورژنهای فایلها و حتی کاربرانی که این فایلها را از این مکان مرکزی check out کرده اند در خود نگهداری میکند. برای سالهای زیادی، چنین روشی، روشی استاندارد برای کنترل ورژن بوده است (تصویر 1-2).
+مسئله مهم دیگری که کاربران با آن مواجه می‌شوند، نیاز آن‌ها به همکاری با دیگر توسعه‌دهندگان برروی سیستم‌های دیگر است. برای حل این مسئله، سیستم‌های کنترل نسخه مرکزی (CVCSs) توسعه یافتند. چنین سیستم‌هایی مانند CVS، Subversion و Perforce در بردارنده سروری مرکزی هستند که تمامی نسخه‌های فایل‌ها و حتی کاربرانی که این فایل‌ها را از این مکان مرکزی checkout کرده‌اند در خود نگهداری می‌کند. برای سال‌های زیادی، چنین روشی، روشی استاندارد برای کنترل نسخه بوده است (تصویر 1-2).
 
 Insert 18333fig0102.png
-تصویر 1-2. دیاگرام کنترل ورژن مرکزی.
+تصویر 1-2. دیاگرام کنترل نسخه مرکزی.
 
-این ساختار مزایای بسیاری مخصوصاً نسبت به سیستمهای کنترل ورژن محلی دارد. به عنوان مثال، هر فرد در حد و اندازه مشخصی  خواهد توانست بداند که دیگر افراد تا چه اندازه در پروژه شریک هستند. مدیران از این نظر که هرکس از نظر سطح دسترسی قادر به انجام چه کاری است، کنترل مناسبی دارند؛ همچنین مدیریت یک CVCS به مراتب آسانتر از تعامل با پایگاههای داده محلی موجود برروی سیستمهای کاربران است.
+این ساختار مزایای بسیاری مخصوصاً نسبت به سیستم‌های کنترل نسخه محلی دارد. به عنوان مثال، هر فرد در حد و اندازه مشخصی خواهد توانست بداند که دیگر افراد تا چه اندازه در پروژه شریک هستند. مدیران از این نظر که هرکس از نظر سطح دسترسی قادر به انجام چه کاری است، کنترل مناسبی دارند؛ همچنین مدیریت یک CVCS به مراتب آسانتر از تعامل با پایگاه‌های داده محلی موجود برروی سیستم‌های کاربران است.
 
-با این وجود، چنین ساختاری معایبی نیز دارد. واضحترین موضوع بروز کوچکترین ایراد در سرورهای مرکزی میباشد. اگر برای مدت یک ساعت این سرور متوقف و از کار بیافتد، در طی این بازه یک ساعته هیچکس نخواهد توانست تعاملی داشته باشد یا حتی تغییرات ورژن را برروی چیزی که در حال کارکردن با آن است ذخیره کند. اگر هارد دیسکی که  پایگاه داده مرکزی برروی آن قرار دارد خراب شود، و پشتیبان مناسبی از آن گرفته نشده باشد، کاربر به طور کامل تاریخچه پروژه را از دست خواهد داد به جز snapshotهایی که هر کاربر احتمالاً برروی ماشین محلی خود خواهد داشت. سیستمهای VCS محلی نیز این عیب را به ارث میبرند-اگر کاربر تمامی تاریخچه پروژه را در یک مکان ذخیره کند، ریسک از دادن همه چیز به قوت خود باقی خواهد ماند.
+با این وجود، چنین ساختاری معایبی نیز دارد. واضح‌ترین موضوع بروز کوچکترین ایراد در سرورهای مرکزی است. اگر برای مدت یک ساعت این سرور متوقف و از کار بیفتد، در طی این بازه یک ساعته هیچکس نخواهد توانست تعاملی با سرور داشته باشد یا حتی تغییرات نسخه را برروی چیزی که در حال کارکردن با آن است ذخیره کند. اگر هارد دیسکی که  پایگاه داده مرکزی برروی آن قرار دارد خراب شود، و پشتیبان مناسبی از آن گرفته نشده باشد، کاربر به طور کامل تاریخچه پروژه را از دست خواهد داد به جز تصاویر لحظه‌ای که هر کاربر احتمالاً برروی ماشین محلی خود خواهد داشت. سیستمهای VCS محلی نیز این عیب را به ارث می‌برند-اگر کاربر تمامی تاریخچه پروژه را در یک مکان ذخیره کند، ریسک از دادن همه چیز به قوت خود باقی خواهد ماند.
 
-### سیستمهای کنترل ورژن پخشی ###
+### سیستمهای کنترل نسخه پخشی ###
 
-اینجا است که سیستمهای کنترل ورژن پخشی (DVCSs) نمود پیدا میکنند. در یک DVCS (مانند Git، Mercurial، Bazaar یا Darcs) کابران به check out کردن آخرین snapshot فایلها اکتفا نمیکنند: آنها repository را نیز به صورت کامل کپی میکنند. بنابراین اگر هر سروری که سیستمها به واسطه آن در حال تعامل با یکدیگر هستند متوقف و از کار بیافتد، با کپی repository هر کدام از کاربران برروی سرور، عمل بازیابی انجام میگیرد. در واقع هر checkoutای، پشتیبان کاملی از تمامی داده ها است.
+اینجا است که سیستم‌های کنترل نسخه پخشی (DVCSs) نمود پیدا می‌کنند. در یک DVCS (مانند Git، Mercurial، Bazaar یا Darcs) کابران به checkout کردن آخرین تصویر لحظه‌ای فایل‌ها اکتفا نمی‌کنند: آن‌ها مخزن را نیز به‌صورت کامل کپی می‌کنند. بنابراین اگر هر سروری که سیستم‌ها به واسطه آن در حال تعامل با یکدیگر هستند متوقف و از کار بیافتد، با کپی مخرن هر کدام از کاربران برروی سرور، عمل بازیابی انجام می‌گیرد. در واقع هر checkoutای، پشتیبان کاملی از تمامی داده‌ها است.
 
 Insert 18333fig0103.png
-تصویر 1-3. دیاگرام کنترل ورژن پخشی.
+تصویر 1-3. دیاگرام کنترل نسخه پخشی.
 
-علاوه بر آن اکثر این سیستمها تعامل خوبی با داشتن remote repositoryهای متعدد جهت کار کردن با آنها دارند، در نتیجه شخص خواهد توانست با گروههای مختلفی در قالب پروژه ای یکسان به صورت همزمان تعامل داشته باشد. این قابلیت این امکان را به کاربر خواهد داد که workflowهای متنوعی همانند مدلهای سلسه مراتبی را پیاده سازی کند که انجام آن در سیستمهای متمرکز امکان پذیر نیست.
+علاوه بر آن اکثر این سیستم‌ها تعامل خوبی با داشتن مخازن خارجی متعدد جهت کار کردن با آن‌ها دارند، در نتیجه شخص خواهد توانست با گروه‌های مختلفی در قالب پروژه‌ای یکسان به‌صورت همزمان تعامل داشته باشد. این قابلیت این امکان را به کاربر خواهد داد که جریان‌های کاری متنوعی همانند مدل‌های سلسه مراتبی را پیاده سازی کند که انجام آن در سیستم‌های متمرکز امکان پذیر نیست.
 
 ## تاریخچه کوتاهی از Git ##
 
-همانند اکثر حوادث بزرگ در در زندگی، Git نیز با خلاقیتی مخرب و جنجالی آتشین شروع شد. هسته لینوکس پروژه نرم افزاری متن باز با وسعت نسبتاً زیادی است. برای مدت زمان زیادی از عمر نگهداری هسته لینوکس (1991 - 2002) تغییرات نرم افزاری به واسطه پچ ها و فایلهای آرشیو شده انتقال پیدا میکرد. در سال 2002، پروژه هسته لینوکس اقدام به استفاده از سیستم DVCS خصوصی با نام BitKeeper کرد.
+همانند اکثر حوادث بزرگ در در زندگی، Git نیز با خلاقیتی مخرب و جنجالی آتشین شروع شد. هسته لینوکس پروژه نرم‌افزاری متن باز با وسعت نسبتاً زیادی است. جهت نگهداری هسته لینوکس برای مدت زمان زیادی (1991 - 2002) تغییرات نرم‌افزاری به واسطه وصله‌ها و فایل‌های بایگانی شده انتقال پیدا می‌کرد. در سال 2002، پروژه هسته لینوکس شروع به استفاده از سیستم DVCS خصوصی با نام BitKeeper کرد.
 
-در سال 2005، ارتباط بین مجموعه تیم توسعه دهنده هسته لینوکس و شرکت تجاری توسعه دهنده BitKeeper گسسته شد و وضعیت ابزاری که قبل از آن  به صورت رایگان عرضه میشد تغییر پیدا کرد. این اتفاق اخطاری را متوجه مجموعه تیم توسعه دهنده لینوکس (به خصوص مؤسس لینوکس، لینوس تورلوادز) کرد که بر اساس تجربه های کسب شده در استفاده از BitKeeper، خود اقدام به تولید نرم افزاری در زمینه بزنند. مواردی از اهداف سیستم جدید عبارتند از:
+در سال 2005، ارتباط بین مجموعه تیم توسعه دهنده هسته لینوکس و شرکت تجاری توسعه دهنده BitKeeper گسسته شد و وضعیت ابزاری که قبل از آن  به صورت رایگان عرضه می‌گشت تغییر پیدا کرد. این اتفاق زنگ هشداری برای مجموعه تیم توسعه دهنده لینوکس (به خصوص مؤسس لینوکس، لینوس تورلوادز) بود که بر اساس تجربه‌های کسب شده در استفاده از BitKeeper، خود اقدام به تولید نرم افزاری در این زمینه بزنند. مواردی از اهداف سیستم جدید عبارت بودند از:
 
 *  	سرعت
 *	طراحی ساده
-*	پشتیبانی قوی از توسعه غیر خطی (هزاران branch موازی)
+*	پشتیبانی قوی از توسعه غیر خطی (هزاران انشعاب موازی)
 *	کاملاً پخشی
-* 	قابلیت کنترل بهینه پروژه های بزرگ همانند هسته لینوکس (از نظر سرعت و اندازه داده)
+* 	قابلیت کنترل بهینه پروژه‌های بزرگ همانند هسته لینوکس (از نظر سرعت و اندازه داده)
 
-از زمان تولد Git در سال 2005، این نرم افزار از نظر استفاده آسان و حفظ اهداف اولیه ذکر شده به تکامل و بلوغ رسیده است. Git نرم افزاری سریع، بسیار بهینه در مواجه با پروژه های بزرگ و حاوی سیستم شاخه ای (branching) باورنکردنی برای توسعه غیر خطی است (فصل 3).
+از زمان تولد Git در سال 2005، این نرم افزار از نظر استفاده آسان و حفظ اهداف اولیه ذکر شده به تکامل و بلوغ رسیده است. Git نرم افزاری سریع، بسیار بهینه در مواجه با پروژه‌های بزرگ و حاوی سیستم انشعابی باورنکردنی برای توسعه غیر خطی است (فصل 3).
 
 ## مقدمات Git ##
 
-خوب، Git چیست؟ این بخش از نظر یادگیری، بخشی مهم قلمداد می شود، زیرا اگر فرد از پایه و اساس عملکرد Git  اطلاع پیدا کند، آنگاه خواهد توانست آسانتر در استفاده مؤثر از آن بهره جوید. در حین یادگیری Git، بهتر است فرد ذهن خود را از مواردی که احیاناً در رابطه با دیگر VCSها همانند Subversion و Perforce میداند تخلیه کند؛ بدین وسیله از بروز اشتباهات موردی در استفاده از این ابزار پیشگیری می شود. با وجود آن که رابط کاربری Git نسبتاً مشابه با دیگر سیستم ها است، ولی در ذخیره سازی و نگاه به اطلاعات، دید بسیار متفاوتی در مقایسه با دیگر سیستم ها دارد؛ دانستن این تفاوت ها میتواند به فرد در جلوگیری از  بروز اشتباهات بعدی در استفاده از این ابزار یاری دهد.
+خوب، Git چیست؟ این بخش از نظر یادگیری، بخشی مهم قلمداد می شود، زیرا اگر فرد از پایه و اساس عملکرد Git  اطلاع پیدا کند، آنگاه خواهد توانست آسان‌تر در استفاده مؤثر از آن بهره جوید. در حین یادگیری Git، بهتر است فرد ذهن خود را از مواردی که احیاناً در رابطه با دیگر VCSها همانند Subversion و Perforce می‌داند تخلیه کند؛ بدین سبب از بروز اشتباهات موردی در استفاده از این ابزار پیشگیری می‌شود. با وجود آن‌که رابط کاربری Git نسبتاً مشابه با دیگر سیستم‌ها است، ولی در ذخیره سازی و نگاه به اطلاعات، دید بسیار متفاوتی در مقایسه با دیگر سیستم‌ها دارد؛ دانستن این تفاوت‌ها می‌تواند به فرد در جلوگیری از  بروز اشتباهات بعدی در استفاده از این ابزار یاری دهد.
 
-### Snapshotها، نه تفاوتها ###
+### تصاویر لحظه‌ای، نه تفاوتها ###
 
-اصلی ترین تفاوت بین Git و دیگر VCSها (که شامل Subversion و هم خانواده های آن نیز می شود) دیدگاهی است که Git نسبت به داده های خود دارد. از نظر مفهومی، اکثریت دیگر سیستم ها اطلاعات را به مثابه لیستی از تغییرات بر مبنای فایل، ذخیره می کنند. این سیستم ها (CVS، Subversion، Perfoce، Bazaar و غیره) همانطور که در تصویر 1-4 نشان داده شده است،  به اطلاعاتی که نگهداری میکنند به شکل مجموعه ای از فایلها و تغییراتی که برروی هر فایل در مرور زمان انجام گرفته است، مینگرند.
+اصلی‌ترین تفاوت بین Git و دیگر VCSها (که شامل Subversion و هم خانواده های آن نیز می‌شود) دیدگاهی است که Git نسبت به داده‌های خود دارد. از نظر مفهومی، اکثریت دیگر سیستم‌ها اطلاعات را به مثابه لیستی از تغییرات بر مبنای فایل، ذخیره می‌کنند. این سیستم‌ها (CVS، Subversion، Perfoce، Bazaar و غیره) همان‌طور که در تصویر 1-4 نشان داده شده است، به اطلاعاتی که نگهداری می‌کنند به شکل مجموعه‌ای از فایل‌ها و تغییراتی که برروی هر فایل در مرور زمان انجام گرفته است، می‌نگرند.
 
 
 Insert 18333fig0104.png
-تصویر 1-4. دیگر سیستم ها داده ها به شکل  تغییرات در ورژن پایه هر فایل ذخیره می کنند.
+تصویر 1-4. دیگر سیستم‌ها داده‌ها به شکل تغییرات در نسخه پایه هر فایل ذخیره می‌کنند.
 
-Git از چنین تفکر یا روش ذخیره سازی داده ای پیروی نمی کند. در عوض دیدگاه Git نسبت به داده های خود به شکل  snapshotهایی از یک سیستم فایلی کوجک است. هر زمانی که شخص commitای انجام میدهد یا وضعیت پروژه خود را در Git ذخیره می کند، در اصل تصویری از وضعیت تمامی فایل ها در لحظه موردنظر تهیه و ارجاعی به snapshot ایجاد شده ذخیره می شود. برای آنکه این عمل به صورت بهینه انجام پذیرد، اگر در فایلی تغییری ایجاد نشده باشد، Git اقدام به ذخیره سازی مجدد فایل نمی کند - تنها ارتباطی (link) به نسخه مشابه آن فایل که قبلاً ذخیره شده است را ذخیره می کند. طریقه نگرش Git به داده در تصویر 1-5 نمایش داده شده است.
+سGit از چنین تفکر یا روش ذخیره سازی داده‌ای پیروی نمی‌کند. در عوض دیدگاه Git نسبت به داده‌های خود به شکل تصاویر لحظه‌ای از یک سیستم فایلی کوچک است. هر زمانی که شخص commitای انجام می‌دهد یا وضعیت پروژه خود را در Git ذخیره می‌کند، در اصل تصویری از وضعیت تمامی فایل‌ها در لحظه موردنظر تهیه و ارجاعی به تصویر لحظه‌ای ایجاد شده ذخیره می شود. برای آن‌که این عمل به صورت بهینه انجام پذیرد، اگر در فایلی تغییری ایجاد نشده باشد، Git اقدام به ذخیره سازی مجدد فایل نمی‌کند - تنها پیوندی به نسخه مشابه آن فایل که قبلاً ذخیره شده است را ذخیره می کند. طریقه نگرش Git به داده در تصویر 1-5 نمایش داده شده است.
 
 Insert 18333fig0105.png
-تصویر 1-5. Git داده ها را به شکل snapshotهایی از پروژه در مرور زمان نگهداری میکند.
+تصویر 1-5. Git داده‌ها را به شکل تصاویر لحظه‌ای از پروژه در مرور زمان نگهداری می‌کند.
 
-این شکل نگرش مهمترین اصل تمایز Git با دیگر VCSها است. این امر موجب می شود تا Git تجدیدنظری نسبت به تمامی ابعاد کنترل ورژن داشته باشد، که اکثریت دیگر سیستم ها از نسل های قبل از خود به ارث برده اند. این موضوع باعث شده است تا Git از یک VCS ساده، به سیستم فایلی کوچکی بدل شود که در بالادست آن ابزار قدرتمند باورنکردنی بنا شده است. در فصل 3 بعضی از مزایای چنین دیدگاهی نسبت به داده پوشش داده می شود.
+این شکل نگرش مهمترین اصل تمایز Git با دیگر VCSها است. این امر موجب می‌شود تا Git تجدیدنظری نسبت به تمامی ابعاد کنترل نسخه داشته باشد، که اکثریت دیگر سیستم‌ها از نسل‌های قبل از خود به ارث برده‌اند. این موضوع باعث شده است تا Git از یک VCS ساده، به سیستم فایلی کوچکی بدل شود که در بالادست آن ابزار قدرتمند باورنکردنی بنا شده است. در فصل 3 بعضی از مزایای چنین دیدگاهی نسبت به داده، پوشش داده می‌شود.
 
-### تقریباً تمام عملیات به صورت محلی انجام می پذیرد ###
+### تقریباً تمام عملیات به صورت محلی انجام می‌پذیرد ###
 
-اکثر عملیاتی که در Git انجام میپذیرد جهت اجرا تنها نیازمند فایلها و منابع محلی هستند - به طور کلی نیازمند هیچگونه اطلاعاتی از کامپیوتری دیگر در شبکه نیست. اگر شما فردی هستید که به CVCSای عادت کرده اید که در آن اکثر فعالیت ها دارای افزونگی رکود شبکه ای داشته اند، شاید این مزیت Git این فکر را برای شما تداعی کند که خدایان سرعت Git را با قدرتی وصف ناشدنی مورد لطف و رحمت قرار داده اند. از آن جهت که تمامی تاریخچه پروژه برروی دیسک محلی قرار دارد، به نظر می رسد که اکثر عملیات به صورت لحظه ای و بلادرنگ انجام می پذیرند.
+اکثر عملیاتی که در Git انجام می‌پذیرد جهت اجرا تنها نیازمند فایل‌ها و منابع محلی هستند - به‌طور کلی نیازمند هیچ‌گونه اطلاعاتی از کامپیوتری دیگر در شبکه نیست. اگر شما فردی هستید که به CVCSای عادت کرده‌اید که در آن اکثر فعالیت‌ها دارای افزونگی رکود شبکه‌ای داشته‌اند، شاید این مزیت Git این فکر را برای شما تداعی کند که خدایان سرعت Git را با قدرتی وصف ناشدنی مورد لطف و رحمت قرار داده‌اند. از آن جهت که تمامی تاریخچه پروژه برروی دیسک محلی قرار دارد، به نظر می‌رسد که اکثر عملیات به صورت لحظه‌ای و بلادرنگ انجام می‌پذیرند.
 
-به عنوان مثال، Git برای نمایش تاریخچه پروژه نیازی جهت مراجعه به سرور برای اخذ تاریخچه و نمایش آن ندارد - Git این عمل را با خواندن مستقیم  پایگاه داده محلی انجام میدهد. این بدان معناست که شخص میتوان تاریخچه پروژه را تقریباً بلادرنگ مشاهده کند. اگر نیاز به مشاهده تغییرات بین ورژن فعلی یک فایل با ورژن یک ماه قبل از آن باشد، Git میتواند بجای آنکه از سرور درخواست این عمل را داشته باشد و یا آنکه نسخه قبلی را از سرور خارجی فراخوانی و سپس مقایسه محلی را انجام دهد، این عمل  را با نگاهی به نسخه یک ماه قبل فایل و انجام محاسبات محلی تغییرات رخ داده، انجام میدهد.
+به عنوان مثال، Git برای نمایش تاریخچه پروژه نیازی جهت مراجعه به سرور برای اخذ تاریخچه و نمایش آن ندارد - Git این عمل را با خواندن مستقیم پایگاه داده محلی انجام می‌دهد. این بدان معناست که شخص می‌تواند تاریخچه پروژه را تقریباً بلادرنگ مشاهده کند. اگر نیاز به مشاهده تغییرات بین نسخه فعلی یک فایل با نسخه یک ماه قبل از آن باشد، Git می‌تواند به‌جای آن‌که از سرور درخواست این عمل را داشته باشد و یا آن‌که نسخه قبلی را از سرور خارجی فراخوانی و سپس مقایسه محلی را انجام دهد، این عمل  را با نگاهی به نسخه یک ماه قبل فایل و انجام محاسبات محلی تغییرات رخ داده، انجام می‌دهد.
 
-همچنین بدین معناست که در صورت آفلاین بودن و یا وصل نبودن به VPN دامنه عملکرد شخص زیاد محدود نمی شود. اگر سوار بر هواپیما یا قطار شده باشید و تصمیم به انجام کاری داشته باشید، میتوانید به راحتی commit را انجام داده و زمانی که دسترسی به شبکه پیدا کردید آپلود را انجام دهید. اگر به خانه رفته باشید و قادر به فعال سازی VPN خود نشده باشید، باز هم وقفه ای در کار شما حاصل نمی شود. در اکثریت دیگر سیستم ها انجام این موارد غیرممکن یا به سختی انجام می پذیرد. به عنوان مثال در Perforce، در صورتی که به شبکه متصل نباشید در واقع توانایی انجام کاری نخواهید داشت؛ در Subversion و CVS، امکان دستکاری فایل ها برای شما وجود دارد، ولی برای commit تغییرات روی پایگاه داده محدودیت دارید (زیرا اتصال شما به پایگاه داده بر قرار نیست). شاید این موضوع مسئله مهمی به نظر نیاید، ولی شاید با مشاهده تغییرات بزرگی که میتواند به موجب آن ایجاد شود، شگفت زده شوید.
+همچنین بدین معناست که در صورت آفلاین بودن و یا وصل نبودن به VPN دامنه عملکرد شخص زیاد محدود نمی‌شود. اگر سوار بر هواپیما یا قطار شده باشید و تصمیم به انجام کاری داشته باشید، می‌توانید به راحتی commit را انجام داده و زمانی که دسترسی به شبکه پیدا کردید آپلود را انجام دهید. اگر به خانه رفته باشید و قادر به فعال سازی VPN خود نشده باشید، باز هم وقفه‌ای در کار شما حاصل نمی‌شود. در اکثریت دیگر سیستم‌ها انجام این موارد غیرممکن یا به سختی انجام می‌پذیرد. به عنوان مثال در Perforce، در صورتی که به شبکه متصل نباشید در واقع توانایی انجام کاری نخواهید داشت؛ در Subversion و CVS، امکان دست‌کاری فایل‌ها برای شما وجود دارد، ولی برای commit تغییرات روی پایگاه داده محدودیت دارید (زیرا اتصال شما به پایگاه داده بر قرار نیست). شاید این موضوع مسئله مهمی به نظر نیاید، ولی شاید با مشاهده تفاوت‌های بزرگی که می‌تواند به موجب آن ایجاد شود، شگفت زده شوید.
 
 ### Git صداقت دارد ###
 
-هرچیزی که بخواهد در Git ذخیره شود، ابتدا checksum آن محاسبه میشود و سپس بوسیله همین checksum ارجاع داده میشود. چنین عملی موجب میشود که در صورت ایجاد کوچکترین تغییری در مححتویات فایل یا پوشه ای، Git از آن آگاهی پیدا کند. این دستورالعمل در Git در پایینترین سطح پیاده سازی شده است و تاییدی بر صحت فلسفه Git دارد. بدین دلیل است که اگر داده ای در حین انتقال از دست برود و یا فایلی مخدوش شود، Git به سرعت از آن اطلاع پیدا میکند.
+هرچیزی که بخواهد در Git ذخیره شود، ابتدا checksum آن محاسبه می‌شود و سپس به‌وسیله همین checksum ارجاع داده می‌شود. چنین عملی موجب می‌شود که در صورت ایجاد کوچکترین تغییری در محتویات فایل یا پوشه‌ای، Git از آن آگاهی پیدا کند. این دستورالعمل در Git در پایینترین سطح پیاده‌سازی شده است و تأییدی بر صحت فلسفه Git دارد. بدین دلیل است که اگر داده‌ای در حین انتقال از دست برود و یا فایلی مخدوش شود، Git به سرعت از آن اطلاع پیدا می‌کند.
 
-مکانیزمی که Git برای تولید checksum استفاده میکند، هش SHA-1 است. این هش یک رشته 40 کاراکتری از کاراکترهای مبنای شانزده است (0 - 9 و a - f) که از روی محتویات فایل و یا ساختار پوشه موردنظر در Git محاسبه میگردد. در ادامه یک نمونه از هش SHA-1 آورده شده است:
+مکانیزمی که Git برای تولید checksum استفاده می‌کند، هش SHA-1 است. این هش یک رشته 40 کاراکتری از کاراکترهای مبنای شانزده است (0 - 9 و a - f) که از روی محتویات فایل و یا ساختار پوشه موردنظر در Git محاسبه می‌گردد. در ادامه یک نمونه از هش SHA-1 آورده شده است:
 
 
 	24b9da6552252987aa493b52f8696cd6d3b00373
 
-به علت استفاده زیاد Git از این هش، به کرات در جای جای Git مشاهده گر این هش ها خواهید بود. در واقع، Git از نام فایل برای ذخیره سازی آن استفاده نمیکند بلکه Git از هش تولید شده از محتویات فایل مربوطه برای آدرس دهی آن در پایگاه داده خود بهره میگیرد.
+به علت استفاده زیاد Git از این هش، به کرات در جای جای Git مشاهده‌گر این هش‌ها خواهید بود. در واقع، Git از نام فایل برای ذخیره‌سازی آن استفاده نمی‌کند بلکه Git از هش تولید شده از محتویات فایل مربوطه برای آدرس دهی آن در پایگاه داده خود بهره می‌گیرد.
 
 ### عموماً Git فقط داده اضافه میکند ###
 
-### Git Generally Only Adds Data ###
+هرگاه عملی در Git انجام می‌پذیرد، تقریباً در تمامی موارد Git داده‌ای به داده‌های خود در پایگاه داده اضافه می‌کند. انجام دادن عملی در این سیستم که برگشت‌پذیر نباشد یا باعث حذف داده ای از سیستم شود، بسیار سخت است. مشابه اکثر VCSها، فرد می‌تواند تا قبل از commit هرگونه تغییراتی را انجام دهد؛ ولی به محض commit یک تصویر لحظه‌ای در Git، امکان حذف آن بسیار سخت است، مخصوصاً اگر فرد عادتاً پایگاه داده خود را به مخزن دیگری push کند.
 
-هرگاه عملی در Git انجام میپذیرد، تقریباً در تمامی موارد Git داده ای به داده های خود در پایگاه داده اضافه می کند. انجام دادن عملی در این سیستم که برگشت پذیر نباشد یا باعث حذف داده ای از سیستم شود، بسیار سخت است. مشابه اکثر VCSها، فرد میتواند تا قبل از commit هرگونه تغییراتی را انجام دهد؛ ولی به محض commit یک snapshot در Git، امکان حذف آن بسیار سخت است، مخصوصاً اگر فرد عادتاً  پایگاه داده خود را به repository دیگری push کند.
-
-این قابلیت باعث می شود که استفاده از Git، به عملی فرح بخش تبدیل شود زیرا فرد خواهد توانست بدون در خطر انداختن چیزی دست به هرگونه آزمایشی بزند. برای آشنایی بیشتر با چگونگی عملکرد Git در ذخیره سازی و بازیابی داده هایی که به نظر از دست رفته می باشند، میتوانید به فصل 9 مراجعه کنید.
+این قابلیت باعث می‌شود که استفاده از Git، به عملی فرح بخش تبدیل شود زیرا فرد خواهد توانست بدون در خطر انداختن چیزی دست به هرگونه آزمایشی بزند. برای آشنایی بیشتر با چگونگی ذخیره‌سازی و بازیابی داده‌ها در Git  که به نظر از دست رفته می‌باشند، می‌توانید به فصل 9 مراجعه کنید.
 
 ### سه وضعیت ###
 
-### The Three States ###
-
-توجه، توجه. اگر میخواهید پروسه یادگیری Git را بدون دردسر ادامه دهید، این مطلب را به خاطر بسپارید. فایلها در Git میتوانند در سه وضعیت اصلی قرار داشته باشند: committed، modified و staged. committed بدین معناست که فایل موردنظر در پایگاه داده محلی ذخیره شده است. modified یعنی تغییری در فایل ایجاد شده است ولی هنوز commitای به موجب این فایل روی پایگاه داده انجام نگرفته است. فایلی که در وضعیت staged قرار گرفته است، فایلی تغییر یافته میباشد که ورژن فعلی آن جهت snapshot بعدی جهت commit نشانه گذاری شده است.
+توجه، توجه. اگر می‌خواهید پروسه یادگیری Git را بدون دردسر ادامه دهید، این بخش را به دقت مطالعه کنید. فایلها در Git می‌توانند در سه وضعیت اصلی قرار داشته باشند: committed، modified و staged. committed بدین معناست که فایل موردنظر در پایگاه داده محلی ذخیره شده است. modified یعنی تغییری در فایل ایجاد شده است ولی هنوز commitای از این فایل روی پایگاه داده انجام نگرفته است. فایلی که در وضعیت staged قرار گرفته است، فایلی تغییر یافته است که نسخه فعلی آن در تصویر لحظه‌ای بعدی جهت commit نشانه‌گذاری شده است.
 
-حال میتوان سه بخش اصلی پروژه Git را معرفی کرد: پوشه Git، پوشه در حال کار (working directory) و staging area.
+حال می‌توان سه بخش اصلی پروژه Git را معرفی کرد: پوشه Git، پوشه در حال کار (working directory) و staging area.
 
 Insert 18333fig0106.png
 تصویر 1-6. پوشه در حال کار، staging area و پوشه Git
 
-در Git، metadata و پایگاه داده پروژه در پوشه Git ذخیره میشوند. این قسمت مهمترین بخش Git است، در واقع هنگامی که از repository کامپیوتری cloneای گرفته می شود، کپی از این پوشه ایجاد میگردد.
+در Git، metadata و پایگاه داده پروژه در پوشه Git ذخیره می‌شوند. این قسمت مهمترین بخش Git است، در واقع هنگامی که از مخزن کامپیوتری cloneای گرفته می‌شود، کپی از این پوشه ایجاد می‌گردد.
 
-پوشه در حال کار، checkout منفردی از ورژنی از پروژه است. فایلهای این بخش، فایلهایی می باشند که از پایگاه داده فشرده واقع در پوشه Git بیرون کشیده شده و جهت استفاده و ایجاد تغییر بر روی دیسک قرار داده شده اند.
+پوشه در حال کار، checkout منفردی از نسخه‌ای از پروژه است. فایل‌های این بخش، فایل‌هایی می‌باشند که از پایگاه داده فشرده واقع در پوشه Git بیرون کشیده شده و جهت استفاده و ایجاد تغییر بر روی دیسک قرار داده شده‌اند.
 
-staging area عموماً از یک فایل ساده تشکیل شده است که محتوی اطلاعاتی است که مشخص میکند که چه چیزهایی در commit بعدی قرار میگیرند. معمولاً از این فایل را index مینامند ولی staging area نیز در حال تبدیل شدن به نامی استاندارد برای چنین فایلی است.
+staging area عموماً از یک فایل ساده تشکیل شده است که محتوی اطلاعاتی است که مشخص می‌کند که چه چیزهایی در commit بعدی قرار می‌گیرند. معمولاً این فایل را index می‌نامند ولی عبارت staging area نیز در حال تبدیل شدن به نامی استاندارد برای چنین فایلی است.
 
 روند کاری Git عموماً به صورت ذیل است:
 
-1. ایجاد تغییرات روی فایلهای واقع در پوشه در حال کار.
-2. stage کردن فایلها و اضافه کردن snapshotهای فایلها به staging area.
-3. commit کردن، که به موجب آن وضعیت فعلی فایلها در staging area تحت یک snapshot به صورت دائمی در پوشه Git ذخیره میگردد.
+1. ایجاد تغییرات روی فایل‌های واقع در پوشه در حال کار.
+2. stage کردن فایل‌ها و اضافه کردن تصاویر لحظه‌ای فایلها به staging area.
+3. commit کردن، که به موجب آن وضعیت فعلی فایل‌ها در staging area تحت یک تصویر لحظه‌ای به صورت دائمی در پوشه Git ذخیره می‌گردد.
 
-اگر ورژنی از یک فایل در پوشه git قرار داشته باشد، commit شده فرض میشود. اگر تغییری در فایل ایجاد شده باشد و به staging area اضافه شده باشد، گوییم staged شده است. و اگر در فایل از آخرین مرتبه ای که check out شده است تغییری ایجاد شده باشد ولی staged نشده باشد، گوییم modified شده است. در فصل 2، با این وضعیت ها بیشتر آشنا خواهید شد و یاد خواهید گرفت که چگونه میتوان از آنها به نحو احسنت استفاده کرد و یا حتی به صورت کامل از روی مرحله stage پرش کرد.
+اگر نسخه‌ای از یک فایل در پوشه git قرار داشته باشد، commit شده فرض می‌شود. اگر تغییری در فایل ایجاد شده باشد و به staging area اضافه شده باشد، گوییم staged شده است. و اگر در فایل از آخرین مرتبه‌ای که checkout شده است تغییری ایجاد شده باشد ولی staged نشده باشد، گوییم modified شده است. در فصل 2، با این وضعیت‌ها بیشتر آشنا خواهید شد و یاد خواهید گرفت که چگونه می‌توان از آن‌ها به نحو احسنت استفاده کرد و یا حتی به صورت کامل از روی مرحله stage پرش کرد.
 
 ## نصب Git ##
 
-حال وقت آن است که کار با Git را شروع کنیم. اول از هر چیز میبایست Git را نصب کرد. روشهای مختلفی برای این کار وجود دارد؛ دو مورد از رایجترین این روشها نصب از طریق سورس یا نصب به واسطه پکیج های موجودی است که برای پلتفرم مورد نظر شما تهیه شده است.
+حال وقت آن است که کار با Git را شروع کنیم. اول از هر چیز می‌بایست Git را نصب کرد. روشهای مختلفی برای این کار وجود دارد؛ دو مورد از رایج‌ترین این روش‌ها نصب از طریق سورس یا نصب به واسطه بسته‌های موجودی است که برای پلتفرم موردنظر شما تهیه شده است.
 
 ### نصب از طریق سورس ###
 
-اگر امکان نصب از طریق سورس برای شما وجود دارد، این روش مناسبترین روش جهت نصب میباشد، زیرا شما بعد از نصب آخرین ورژن نرم افزار را در اختیار خواهید داشت. در هر نسخه از Git سعی شده است که تا در رابط کاربری بهبودهایی حاصل شود، بنابراین در اختیار داشتن آخرین ورژن بهترین گزینه است البته اگر با کامپایل سورس نرم افزار مشکلی نداشته باشید. همچنین معمولاً مخازن نرم افزاری اکثر توزیعهای لینوکس در بر دارنده پکیجهایی با ورژنهای قدیمی هستند؛ بنابراین در صورتی که شما توسعه دهنده ای به روز هستید یا از backportها استفاده میکنید، نصب از طریق سورس بهترین انتخاب برای شما می باشد.
+اگر امکان نصب از طریق سورس برای شما وجود دارد، این روش مناسب‌ترین روش جهت نصب می‌باشد، زیرا شما بعد از نصب آخرین نسخه نرم‌افزار را در اختیار خواهید داشت. در هر نسخه از Git سعی شده است که تا در رابط کاربری بهبودهایی حاصل شود، بنابراین در اختیار داشتن آخرین نسخه بهترین گزینه است البته اگر با کامپایل سورس نرم‌افزار مشکلی نداشته باشید. همچنین معمولاً مخازن نرم افزاری اکثر توزیعهای لینوکس دربردارنده بسته‌هایی با نسخه‌های قدیمی هستند؛ بنابراین در صورتی که شما توسعه دهنده‌ای به روز هستید یا از backportها استفاده می‌کنید، نصب از طریق سورس بهترین انتخاب برای شما است.
 
-برای نصب Git نیاز به کتابخانه های curl، zlib، openssl، expat و libiconv است که Git نیازمند آنهاست. به عنوان مثال، اگر روی سیستمی کار میکنید که yum (مانند Fedora) یا apt-get (مانند سیستم های مبتنی بر Debian) دارد، میتوانید برای نصب این بسته های  نیازمندی از دستورهای ذیل استفاده کنید:
+برای نصب Git نیاز به کتابخانه های curl، zlib، openssl، expat و libiconv است که Git نیازمند آنهاست. به عنوان مثال، اگر روی سیستمی کار می‌کنید که yum (مانند Fedora) یا apt-get (مانند سیستم های مبتنی بر Debian) دارد، می‌توانید برای نصب این بسته‌های نیازمندی از دستورهای ذیل استفاده کنید:
 
 	$ yum install curl-devel expat-devel gettext-devel \
 	  openssl-devel zlib-devel
@@ -140,41 +136,41 @@ staging area عموماً از یک فایل ساده تشکیل شده است 
 	$ apt-get install libcurl4-gnutls-dev libexpat1-dev gettext \
 	  libz-dev libssl-dev
 
-حال که تمامی نیازمندیها نصب گردید، میتوان آخرین نسخه Git را از وب سایت آن دانلود کرد:
+حال که تمامی نیازمندی‌ها نصب گردید، می‌توان آخرین نسخه Git را از وب سایت آن دانلود کرد:
 
 	http://git-scm.com/download
 
-و آن را کامپایل و نصب کرد:
+و آن را کامپایل و نصب نمود:
 
 	$ tar -zxf git-1.7.2.2.tar.gz
 	$ cd git-1.7.2.2
 	$ make prefix=/usr/local all
 	$ sudo make prefix=/usr/local install
 
-بعد از کامل شدن این مراحل میتوان از خود Git برای دریافت آپدیت های Git استفاده کرد:
+بعد از کامل شدن این مراحل می‌توان از خود Git برای دریافت آپدیت‌های Git استفاده کرد:
 
 	$ git clone git://git.kernel.org/pub/scm/git/git.git
 
 ### نصب بر روی لینوکس ###
 
-اگر قصد نصب Git بر روی لینوکس به واسطه یک نصاب باینری را دارید، میتوانید این کار را از طریق ابزار مدیریت بسته های نرم افزاری که همراه توزیع موردنظر شما ارائه می شود انجام دهید. اگر توزیع شما Fedora است، میتوانید از yum استفاده کنید:
+اگر قصد نصب Git بر روی لینوکس به واسطه یک نصاب باینری را دارید، می‌توانید این کار را از طریق ابزار مدیریت بسته های نرم‌افزاری که همراه توزیع موردنظر شما ارائه می‌شود انجام دهید. اگر توزیع شما Fedora است، می‌توانید از yum استفاده کنید:
 
 	$ yum install git-core
 
-یا اگر توزیعی مبتنی بر Debian مانند Ubuntu دارید، میتوانید از apt-get استفاده کنید:
+یا اگر توزیعی مبتنی بر Debian مانند Ubuntu دارید، می‌توانید از apt-get استفاده کنید:
 
 	$ apt-get install git
 
-### نصب بر روی Mac ###
+### نصب برروی Mac ###
 
-برای نصب بر روی Mac دو روش آسان وجود دارد. آسانترین روش استفاده از نصاب گرافیکی Git است، که امکان دانلود آن از صفحه Google Code وجود دارد (تصویر 1-7):
+برای نصب برروی Mac دو روش آسان وجود دارد. آسان‌ترین روش استفاده از نصاب گرافیکی Git است، که امکان دانلود آن از صفحه Google Code وجود دارد (تصویر 1-7):
 
 	http://code.google.com/p/git-osx-installer
 
 Insert 18333fig0107.png
 تصویر 1-7. نصاب Git OS X
 
-روش دیگر نصب از طریق MacPortها (`http://www.macports.org`) است. اگر MacPorts را نصب شده روی سیستم خود دارید، میتوانید Git را با دستور ذیل نصب کنید
+روش دیگر نصب از طریق MacPortها (`http://www.macports.org`) است. اگر MacPortها را نصب شده روی سیستم خود دارید، می‌توانید Git را با دستور ذیل نصب کنید
 
 	$ sudo port install git-core +svn +doc +bash_completion +gitweb
 
@@ -182,52 +178,52 @@ Insert 18333fig0107.png
 
 ### نصب بر روی ویندوز ###
 
-نصب Git روی ویندوز بسیار آسان است. پروژه msysGit یکی از آسانترین مراحل نصب را دارد. تنها نیاز است که فایل نصاب exe را از صفحه GitHub دانلود، و آن را اجرا کرد:
+نصب Git روی ویندوز بسیار آسان است. پروژه msysGit یکی از آسان‌ترین مراحل نصب را دارد. تنها نیاز است که فایل نصاب exe را از صفحه GitHub دانلود، و آن را اجرا کرد:
 
 	http://msysgit.github.com/
 
 بعد از اتمام نصب، هم نسخه خط فرمان (شامل SSH client که در ادامه مشاهده خواهد شد که ابزاری کارآمد است) و هم رابط گرافیکی استاندارد را در اختیار خواهید داشت.
 
-نکته برای کابران ویندوز: کاربر باید جهت کار با Git از پوسته ارائه شده به همراه msysGit (به سبک Unix)، تا بتواند دستورات چند خطی پیچیده ای که در این کتاب آورده شده را اجرا کند. اگر به هر دلیلی، نیاز به استفاده از پوسته خود ویندوز / کنسول خط فرمان، شدید باید در عوض تک کوت (simple quote) از دابل کوت  (برای پارامترهایی که در بر دارنده فاصله هستند) استفاده کنید و باید پارامترهای موجود در آخرین خط که با circumflex accent (^) به پایان میرسند را داخل کوت قرار دهید، زیرا این علامت، نشانگر ادامه دار بودن خط در ویندوز است.
+نکته برای کابران ویندوز: کاربر باید جهت کار با Git از پوسته ارائه شده به همراه msysGit (به سبک Unix) استفاده کند، تا بتواند دستورات چند خطی پیچیده‌ای که در این کتاب آورده شده را اجرا کند. اگر به هر دلیلی، نیاز به استفاده از پوسته خود ویندوز/کنسول خط فرمان، شدید باید در عوض تک کوت (simple quote) از دابل کوت  (برای پارامترهایی که در بر دارنده فاصله هستند) استفاده کنید و باید پارامترهای موجود در آخرین خط که با circumflex accent (^) به پایان می‌رسند را داخل کوت قرار دهید، زیرا این علامت، نشانگر ادامه دار بودن خط در ویندوز است.
 
 ## تنظیمات شروع به کار Git ##
 
-حال که Git روی سیستم نصب شده است، نیاز به شخصی سازی بعضی از منابع Git است. انجام این تنظیمات فقط برای یک مرتبه انجام می‌پذیرد؛ و بعد از آن با هر بار ارتقاء بدون تغییر باقی می‌مانند. همچنین امکان تغییر آن‌ها در هر زمانی که نیاز باشد به کمک خط فرمان قابل انجام است.
+حال که Git روی سیستم نصب شده است، نیاز به شخصی‌سازی بعضی از منابع Git است. انجام این تنظیمات فقط برای یک مرتبه انجام می‌پذیرد؛ و بعد از آن با هر بار ارتقاء بدون تغییر باقی می‌مانند. همچنین امکان تغییر آن‌ها در هر زمانی که نیاز باشد به کمک خط فرمان وجود دارد.
 
 به همراه Git ابزاری ارائه شده است با نام git config که امکان خواندن و اعمال متغیرهای تنظیماتی که تمامی ابعاد ظاهری و عملیاتی Git را کنترل می‌کند فراهم می‌سازد.
 
-*  فایل `/etc/gitconfig`: حاوی مقادیر تمامی کاربران سیستم  و مخازن آن‌ها است. اگر به همراه `git config` از آپشن `--system` استفاده شود، خواندن و نوشتن به صورت اختصاصی از این فایل انجام می‌پذیرد.
-*  فایل `~/.gitconfig`: مختص کاربر مشخصی است. با استفاده از آپشن `--global` خواندن و نوشتن Git به صورت اختصاصی از این فایل انجام می‌پذیرد.
+*  فایل `/etc/gitconfig`: حاوی مقادیر تمامی کاربران سیستم  و مخازن آن‌ها است. اگر به همراه `git config` از گزینه `--system` استفاده شود، خواندن و نوشتن به صورت اختصاصی از این فایل انجام می‌پذیرد.
+*  فایل `~/.gitconfig`: مختص کاربر مشخصی است. با استفاده از گزینه `--global` خواندن و نوشتن Git به صورت اختصاصی از این فایل انجام می‌پذیرد.
 *  فایل config موجود در پوشه git (`.git/config`) یا هر مخزنی که در حال استفاده از آن می‌باشید: مختص یک مخزن خاص است. مقادیر هر سطح باعث لغو مقادیر سطح قبلی خود می‌شود. بنابراین مقادیر `.git/config` موجب لغو مقادیر `/etc/gitconfig` خواهد شد.
 
-در سیستم‌های ویندوزی، Git در پوشه `$HOME` (متغیر محیطی `%USERPROFILE%` در ویندوز) که برای اکثر کاربران با توجه به ورژن سیستم در مسیرهای `C:\Documents and Settings\$USER‍ یا `C:\Users\$USER` (`$USER‍ در ویندوز متغیر محیطی `%USERNAME%`) قرار دارد، فایل `.gitconfig` را جستجو می‌کند. همچنین نسبت به مسیر ریشه MSys که همان مسیر نصب انتخاب شده در هنگام اجرای نصاب Git در ویندوز می‌باشد، به دنبال فایلی با نام /etc/gitconfig می‌گردد.
+در سیستم‌های ویندوزی، Git در پوشه `$HOME` (متغیر محیطی `%USERPROFILE%` در ویندوز) که برای اکثر کاربران با توجه به نسخه سیستم در مسیرهای `C:\Documents and Settings\$USER‍ یا `C:\Users\$USER` (`$USER‍ در ویندوز متغیر محیطی `%USERNAME%`) قرار دارد، فایل `.gitconfig` را جستجو می‌کند. همچنین نسبت به مسیر ریشه MSys که همان مسیر نصب انتخاب شده در هنگام اجرای نصاب Git در ویندوز می‌باشد، به دنبال فایلی با نام /etc/gitconfig می‌گردد.
 
-### شناسه ###
+### شناسه کاربر ###
 
-اولین عملی که بعد از نصب Git باید انجام شود، مقداردهی کردن دو متغیر نام کاربری (user name) و آدرس پست الکترونیکی (e-mail address) است. این عمل از آن جهت اهمیت دارد که در هر commit این اطلاعات به‌صورتی تغییر ناپذیر روی commit انجام شده حک می‌شوند.
+اولین عملی که بعد از نصب Git باید انجام شود، مقداردهی دو متغیر نام کاربری (user name) و آدرس پست الکترونیکی (e-mail address) است. این عمل از آن جهت اهمیت دارد که در هر commit این اطلاعات به‌صورتی تغییر ناپذیر روی commit انجام شده حک می‌شوند.
 
 	$ git config --global user.name "John Doe"
 	$ git config --global user.email johndoe@example.com
 
-مجدداْ یادآوری می‌شود که انجام این عمل در صورت استفاده از آپشن `--global` فقط یک مرتبه انجام می‌پذیرد، زیرا Git برای هر عملی که در سیستم انجام می‌پذیرد از این اطلاعات استفاده می‌کند. حال اگر فرد نیاز به استفاده از نام و آدرس پست الکترونیکی متفاوتی برای پروژه‌های خاصی داردُ، می‌تواند با اجرای همان دستورات البته بدون استفاده از آپشن `--global` هنگامی که در مسیر پروژه مذکور قرار دارد به مقصود خود دست یابد.
+مجدداً یادآوری می‌شود که انجام این عمل در صورت استفاده از گزینه `--global` فقط یک مرتبه انجام می‌پذیرد، زیرا Git برای هر عملی که در سیستم انجام می‌پذیرد از این اطلاعات استفاده می‌کند. حال اگر فرد نیاز به استفاده از نام و آدرس پست الکترونیکی متفاوتی برای پروژه‌های خاصی دارد، می‌تواند با اجرای همان دستورات البته بدون استفاده از گزینه `--global` هنگامی که در مسیر پروژه مذکور قرار دارد به مقصود خود دست یابد.
 
-### ویرایشگر ###
+### ویرایشگر کاربر ###
 
-حال که شناسه تنظیم شد، میتوان ویرایشگر متنی پیش فرضی را معرفی کرد تا هنگامی که نیاز به نوشتن پیغامی در Git وجود دارد فراخوانی شود. به صورت پیش فرض Git از ویرایشگر پیش فرض سیستم برای این امر استفاده می کند، که معمولاً Vi یا Vim است. اگر نظر شخص به استفاده از ویرایشگر متنی متفاوتی مانند Emacs باشد، میتوان به صورت ذیل عمل کرد:
+حال که شناسه تنظیم شد، می‌توان ویرایشگر متن پیش فرضی را معرفی کرد تا هنگامی که نیاز به درج پیغامی در Git است فراخوانی شود. به صورت پیش فرض Git از ویرایشگر پیش فرض سیستم برای این امر استفاده می کند، که معمولاً Vi یا Vim است. اگر نظر شخص به استفاده از ویرایشگر متنی متفاوتی مانند Emacs باشد، می‌توان به صورت ذیل عمل کرد:
 
 	$ git config --global core.editor emacs
 
 ### ابزار Diff ###
 
-ابزار مفید دیگری که شاید نیاز به تنظیم داشته باشد، ابزار diff پیش فرضی است که برای رفع مغایرت ایجاد شده در استفاده از دستور merge استفاده میگردد. به عنوان مثال اگر هدف استفاده از vimdiff باشد خواهیم داشت:
+ابزار مفید دیگری که شاید نیاز به تنظیم داشته باشد، ابزار diff پیش فرضی است که برای رفع مغایرت ایجاد شده در هنگام اجرای دستور merge استفاده می‌گردد. به عنوان مثال اگر هدف استفاده از vimdiff باشد خواهیم داشت:
 
 	$ git config --global merge.tool vimdiff
 
-Git ابزارهای kdiff3، tkdiff، meld، xxdiff، emerge، vimdiff، gvimdiff، ecmerge و opendiff را به عنوان ابزارهایی معتبر جهت merge می شناسد. با این وجود امکان تعریف ابزاری شخصی نیز وجود دارد؛ برای اطلاعات بیشتر جهت انجام این مورد میتوانید به فصل 7 مراجعه کنید.
+سGit از ابزارهای kdiff3، tkdiff، meld، xxdiff، emerge، vimdiff، gvimdiff، ecmerge و opendiff جهت merge پشتیبانی می‌کند. با این وجود امکان تعریف ابزاری شخصی نیز وجود دارد؛ برای اطلاعات بیشتر جهت انجام این مورد می‌توانید به فصل 7 مراجعه کنید.
 
 ### بررسی تنظیمات ###
 
-برای مشاهده و بررسی تنظیمات، میتوان از دستور `git config --list` استفاده کرد که در نتیجه آن Git تمامی تنظیمات موجود تا آن لحظه را در قالب لیستی نمایش می دهد:
+برای مشاهده و بررسی تنظیمات، می‌توان از دستور `git config --list` استفاده کرد که در نتیجه آن Git تمامی تنظیمات موجود تا آن لحظه را در قالب لیستی نمایش می‌دهد:
 
 	$ git config --list
 	user.name=Scott Chacon
@@ -238,29 +234,29 @@ Git ابزارهای kdiff3، tkdiff، meld، xxdiff، emerge، vimdiff، gvimdi
 	color.diff=auto
 	...
 
-احتمال دارد در این لیست کلیدهایی بیش از یک بار مشاهده شود، دلیل این امر آن است که Git کلید مشابهی را از فایلهای مختلفی (مانند `/etc/giconfig` و `~/.gitconfig`) خوانده باشد. در اینگونه موارد، Git آخرین مقدار کلید منحصر به فردی که مشاهده می کند را مورد استفاده قرار میدهد.
+احتمال دارد در این لیست کلیدهایی بیش از یک بار مشاهده شوند، دلیل این امر آن است که Git کلید مشابهی را از فایل‌های مختلفی (مانند `/etc/giconfig` و `~/.gitconfig`) خوانده است. در این‌گونه موارد، Git آخرین مقدار کلید منحصر به فردی که مشاهده می‌کند را جهت استفاده به‌کار می‌گیرد.
 
-همچنین برای مشاهده مقدار مورداستفاده یک کلید خاص توسط Git، میتوان از دستور `git config {key}` استفاده کرد:
+همچنین برای مشاهده مقدار مورد استفاده یک کلید خاص توسط Git، می‌توان از دستور `git config {key}` استفاده کرد:
 
 	$ git config user.name
 	Scott Chacon
 
 ## دریافت راهنمایی ##
 
-هرگاه در استفاده از Git نیازمند راهنمایی بودید، سه روش برای مشاهده صفحه راهنما (manpage) هرگونه دستوری در Git وجود دارد:
+هرگاه در استفاده از Git نیازمند راهنمایی بودید، سه روش برای مشاهده صفحه راهنما هرگونه دستوری در Git وجود دارد:
 
 	$ git help <verb>
 	$ git <verb> --help
 	$ man git-<verb>
 
-برای مثال، برای مشاهده راهنما manpage دستور config داریم
+برای مثال، برای مشاهده صفحه راهنما دستور config داریم
 
 	$ git help config
 
-این دستورات از آن جهت که میتوان از هر مکانی، حتی در حالت آفلاین، به آنها دسترسی پیدا کرد ابزاری کاربردی میباشند.
-اگر manpageها و این کتاب جوابگوی نیاز شما نبودند و نیاز به راهنمایی فردی پیدا کردید، میتوانید به کانالهای `#git` یا `#github` در سرور Freenode IRC (irc.freenode.net) مراجعه کنید.
-معمولاً این کانالها مملؤ از افرادی با سطح دانش بالا در زمینه Git هستند که آماده راهنمایی رساندن به شما می باشند.
+این دستورات از آن جهت که می‌توان از هر مکانی، حتی در حالت آفلاین، به آن‌ها دسترسی پیدا کرد ابزاری کاربردی می‌باشند.
+اگر صفحات راهنما و این کتاب جوابگوی نیاز شما نبودند و نیاز به راهنمایی فردی پیدا کردید، میتوانید به کانالهای `#git` یا `#github` در سرور Freenode IRC (irc.freenode.net) مراجعه کنید.
+معمولاً این کانال‌ها مملؤ از افرادی با سطح دانش بالا در زمینه Git هستند که آماده راهنمایی رساندن به شما می‌باشند.
 
 ## خلاصه ##
 
-با مطالعه این فصل شما باید درک اولیه ای از این که Git چیست و چه تفاوتی با دیگر CVCSهایی که احتمالاً از آن استفاده میکردید پیدا کرده باشد. همچنین شما باید نسخه آماده به کاری از Git را روی سیستم خود داشته باشید که با شناسه شخصی شما تنظیم شده است. حال زمان یادگیری اصول اولیه Git است.
+با مطالعه این فصل شما باید درک اولیه‌ای از این که Git چیست و چه تفاوتی با دیگر CVCSهایی که احتمالاً از آن استفاده می‌کردید دارد پیدا کرده باشد. همچنین شما باید نسخه آماده به کاری از Git را روی سیستم خود داشته باشید که شناسه شخصی شما برروی آن تنظیم شده است. حال زمان یادگیری اصول اولیه Git است.
diff --git a/fa/NOTES.en-fa.md b/fa/NOTES.en-fa.md
new file mode 100644
index 000000000..aef4537e1
--- /dev/null
+++ b/fa/NOTES.en-fa.md
@@ -0,0 +1,143 @@
+نکاتی در رابطه با ترجمه کتاب
+======================
+  
+همان‌طور که اطلاع دارید کلمات تخصصی اکثر رشته‌ها در زبان فارسی مورد کم لطفی واقع شده‌اند و معمولاً معادل فارسی آن‌ها به صورت رسمی و مدون تعیین نشده‌اند. باالاجبار مترجمان جهت ترجمه این لغات به رای و نظر شخصی خود رجوع می‌کنند. بدین دلیل است که ممکن است برای یک عبارت تخصصی معادل‌های گوناگونی در کتب مختلف یافت شود.
+
+از آن جهت که ترجمه این کتاب به صورت گروهی انجام می‌پذیرد، برای جلوگیری از سردرگمی خواننده بعد از ترجمه کامل اثر سعی شده است تا لغت‌نامه کوچکی از کلمات کلیدی که در این کتاب به‌کار رفته شده است تهیه شود تا تمامی افرادی که در این کار گروهی شرکت می‌کنند از یک الگوی یکسان در ترجمه پیروی کنند.
+
+لذا از تمامی افرادی که در ترجمه این کتاب شرکت می‌کنند خواهشمندیم تا از این الگو پیروی کنند و همچنین اگر خود به کلمه کلیدی جدیدی برخورد کردند که در این لیست وجود ندارد، آن را به لیست اضافه کرده و حتی اگر جایگزین مناسبتری برای کلمه خاصی در نظر داشتند با هماهنگی دیگر مترجمان آن را جایگزین کنند.
+
+توجه: کلماتی که جایگزین مناسبی هنوز برای آن‌ها یافت نشده است، در قسمت معادل فارسی،همان عبارت انگلیسی کلمه آورده شده است.
+
+ 
+archive
+-------
+
+		بایگانی
+
+branch
+------
+
+		انشعاب
+
+checkout
+--------
+
+		checkout
+
+checksum
+--------
+
+		checksum
+
+clone
+-----
+
+		clone
+
+
+commit
+------
+
+		commit
+
+customize
+---------
+
+		شخصی‌سازی
+
+diff
+----
+
+		diff
+
+link
+----
+
+		پیوند
+
+manpage
+-------
+
+		صفحه راهنما
+
+merge
+-----
+
+		merge
+
+metadata
+--------
+
+		metadata
+
+option
+------
+
+		گزینه
+
+package
+-------
+
+		بسته
+
+
+patch
+-----
+
+وصله
+
+platform
+--------
+
+		platform
+
+push
+----
+
+		push
+
+remote repository
+-----------------
+
+		مخزن خارجی
+
+repository
+----------
+
+		مخزن	
+
+revision
+--------
+
+		نسخه
+
+snapshot
+--------
+
+		تصویر لحظه‌ای
+
+staging area
+------------
+
+		staging area
+
+state
+-----
+
+وضعیت
+
+version
+-------
+
+نسخه
+
+workflow
+--------
+
+جریان کاری
+
+working directory
+-----------------
+
+پوشه در حال کار
\ No newline at end of file
diff --git a/fa/README.md b/fa/README.md
index 936a0ec43..95dab6b2c 100644
--- a/fa/README.md
+++ b/fa/README.md
@@ -1,7 +1,7 @@
 # تلاش برای ترجمه فارسی #
 
-
 ## لیست افراد حاضر در این پروژه ##
+Oxtay
+mxamin
 
-اگر شما هم بر روی این ترجمه کار میکنید یا در نظر دارید  که این کار را شروع  کنید لطفآ به ما اطلاع دهید تا از دوباره کاری پرهیز شود .
-
+اگر شما هم برروی این ترجمه کار می‌کنید یا در نظر دارید که این کار را شروع  کنید لطفآ به ما اطلاع دهید تا از دوباره کاری پرهیز شود.
\ No newline at end of file

From 0f0aa507274fb17ef7eb79b400fd3de848087f4c Mon Sep 17 00:00:00 2001
From: Petr Prikryl <prikryl@atlas.cz>
Date: Fri, 1 Aug 2014 16:11:09 +0200
Subject: [PATCH 528/690] [cs] Synchronizing with [en] by structure and markup

---
 cs/01-introduction/01-chapter1.markdown       |   6 +-
 cs/02-git-basics/01-chapter2.markdown         | 411 +++++++++++-------
 cs/03-git-branching/01-chapter3.markdown      | 108 ++---
 cs/04-git-server/01-chapter4.markdown         |  50 ++-
 cs/05-distributed-git/01-chapter5.markdown    |  33 +-
 cs/06-git-tools/01-chapter6.markdown          |  40 +-
 cs/07-customizing-git/01-chapter7.markdown    |  47 +-
 cs/08-git-and-other-scms/01-chapter8.markdown |   2 +-
 8 files changed, 421 insertions(+), 276 deletions(-)

diff --git a/cs/01-introduction/01-chapter1.markdown b/cs/01-introduction/01-chapter1.markdown
index 10bebf266..007fa3a9b 100644
--- a/cs/01-introduction/01-chapter1.markdown
+++ b/cs/01-introduction/01-chapter1.markdown
@@ -6,7 +6,7 @@ Tato kapitola vám ve stručnosti představí systém Git. Začneme od samého z
 
 Co je to správa verzí a proč by vás měla zajímat? Správa verzí je systém, který zaznamenává změny souboru nebo sady souborů v průběhu času, a uživatel tak může kdykoli obnovit jeho/jejich konkrétní verzi (tzv. verzování). Příklady verzovaných souborů jsou v této knize ilustrovány na zdrojovém kódu softwaru, avšak ve skutečnosti lze verzování provádět téměř se všemi typy souborů v počítači.
 
-Pokud jste grafik nebo webdesigner a chcete uchovávat všechny verze obrázku nebo všechna rozložení stránky (což jistě není k zahození), je pro vás systém správy verzí (zkráceně VCS z angl. Version Control System) ideálním nástrojem. VCS umožňuje vrátit jednotlivé soubory nebo celý projekt do předchozího stavu, porovnávat změny provedené v průběhu času, zjistit, kdo naposledy upravil něco, co nyní možná způsobuje problémy, kdo vložil jakou verzi a kdy a mnoho dalšího. Používáte-li verzovací systém, většinou to také znamená, že snadno obnovíte soubory, které jste ztratili nebo v nichž byly provedeny nežádoucí změny. Všechny funkcionality verzovacího systému můžete navíc používat velice jednoduchým způsobem.
+Pokud jste grafik nebo webdesigner a chcete uchovávat všechny verze obrázku nebo všechna rozložení stránky (což jistě není k zahození), je pro vás systém správy verzí (zkráceně VCS z anglického Version Control System) ideálním nástrojem. VCS umožňuje vrátit jednotlivé soubory nebo celý projekt do předchozího stavu, porovnávat změny provedené v průběhu času, zjistit, kdo naposledy upravil něco, co nyní možná způsobuje problémy, kdo vložil jakou verzi a kdy a mnoho dalšího. Používáte-li verzovací systém, většinou to také znamená, že snadno obnovíte soubory, které jste ztratili nebo v nichž byly provedeny nežádoucí změny. Všechny funkcionality verzovacího systému můžete navíc používat velice jednoduchým způsobem.
 
 ### Lokální systémy správy verzí ###
 
@@ -178,7 +178,7 @@ Není nutné přidávat všechny doplňky, ale pokud budete někdy používat Gi
 
 Instalace systému Git v OS Windows je velice nenáročná. Postup instalace projektu msysGit patří k těm nejjednodušším. Ze stránky GitHub stáhněte instalační soubor exe a spusťte ho:
 
-	http://msysgit.github.com/
+	http://msysgit.github.io
 
 Po dokončení instalace budete mít k dispozici jak verzi pro příkazový řádek (včetně SSH klienta, který se vám bude hodit později), tak standardní grafické uživatelské rozhraní.
 
@@ -188,7 +188,7 @@ Poznámka k používání pod Windows: Git byste měli používat z dodaného sh
 
 Nyní, když máte Git nainstalovaný, můžete provést některá uživatelská nastavení systému. Nastavení stačí provést pouze jednou — zůstanou zachována i po případných aktualizacích.
 
-Nastavení konfiguračních proměnných systému, které ovlivňují jak vzhled systému Git, tak ostatní aspekty jeho práce, umožňuje příkaz git config. Tyto proměnné mohou být uloženy na třech různých místech:
+Nastavení konfiguračních proměnných systému, které ovlivňují jak vzhled systému Git, tak ostatní aspekty jeho práce, umožňuje příkaz `git config`. Tyto proměnné mohou být uloženy na třech různých místech:
 
 *	Soubor `/etc/gitconfig` obsahuje údaje o všech uživatelích systému a jejich repozitářích. Pokud příkazu `git config` zadáme parametr `--system` bude číst a zapisovat jen do tohoto souboru.
 *	Soubor `~/.gitconfig` je vázán na uživatelský účet. Čtení a zápis do tohoto souboru zajistíte zadáním parametru `--global`.
diff --git a/cs/02-git-basics/01-chapter2.markdown b/cs/02-git-basics/01-chapter2.markdown
index cae0cc93e..7720fdead 100644
--- a/cs/02-git-basics/01-chapter2.markdown
+++ b/cs/02-git-basics/01-chapter2.markdown
@@ -54,7 +54,7 @@ Obrázek 2-1. Cyklus stavů vašich souborů
 Hlavním nástrojem na zjišťování stavu jednotlivých souborů je příkaz `git status`. Spustíte-li tento příkaz bezprostředně po klonování, objeví se zhruba následující:
 
 	$ git status
-	# On branch master
+	On branch master
 	nothing to commit, working directory clean
 
 To znamená, že žádné soubory nejsou připraveny k zapsání a pracovní adresář je čistý. Jinými slovy žádné sledované soubory nebyly změněny. Git také neví o žádných nesledovaných souborech, jinak by byly ve výčtu uvedeny. Příkaz vám dále sděluje, na jaké větvi (branch) se nacházíte. Pro tuto chvíli nebudeme situaci komplikovat a výchozí bude vždy hlavní větev (`master` branch). Větve a reference budou podrobně popsány v následující kapitole.
@@ -63,11 +63,12 @@ To znamená, že žádné soubory nejsou připraveny k zapsání a pracovní adr
 
 	$ vim README
 	$ git status
-	# On branch master
-	# Untracked files:
-	#   (use "git add <file>..." to include in what will be committed)
-	#
-	#	README
+	On branch master
+	Untracked files:
+	  (use "git add <file>..." to include in what will be committed)
+
+	        README
+
 	nothing added to commit but untracked files present (use "git add" to track)
 
 Vidíte, že nový soubor `README` není sledován, protože je ve výpisu stavů uveden v části „Untracked files“. Není-li soubor sledován, obecně to znamená, že Git ví o souboru, který nebyl v předchozím snímku (v předchozí revizi), a nezařadí ho ani do dalších snímků, dokud mu k tomu nedáte výslovný příkaz. Díky tomu se nemůže stát, že budou do revizí nedopatřením zahrnuty vygenerované binární soubory nebo jiné soubory, které si nepřejete zahrnout. Vy si ale přejete soubor README zahrnout, a proto spusťme jeho sledování.
@@ -81,12 +82,12 @@ K zahájení sledování nových souborů se používá příkaz `git add`. Chce
 Když nyní znovu provedete příkaz k výpisu stavů (git status), uvidíte, že je nyní soubor `README` sledován a připraven k zapsání:
 
 	$ git status
-	# On branch master
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#	new file:   README
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+
+	        new file:   README
+
 
 Můžeme říci, že je připraven k zapsání, protože je uveden v části „Changes to be committed“, tedy „Změny k zapsání“. Pokud v tomto okamžiku zapíšete revizi, v historickém snímku bude verze souboru z okamžiku, kdy jste spustili příkaz `git add`. Možná si vzpomínáte, že když jste před časem spustili příkaz `git init`, provedli jste potom příkaz `git add (soubory)`. Příkaz jste zadávali kvůli zahájení sledování souborů ve vašem adresáři. Příkaz `git add` je doplněn uvedením cesty buď k souboru, nebo k adresáři. Pokud se jedná o adresář, příkaz přidá rekurzivně všechny soubory v tomto adresáři.
 
@@ -95,58 +96,60 @@ Můžeme říci, že je připraven k zapsání, protože je uveden v části „
 Nyní provedeme změny v souboru, který už byl sledován. Pokud změníte už dříve sledovaný soubor s názvem `benchmarks.rb` a poté znovu spustíte příkaz `status`, zobrazí se výpis podobného obsahu:
 
 	$ git status
-	# On branch master
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#	new file:   README
-	#
-	# Changes not staged for commit:
-	#   (use "git add <file>..." to update what will be committed)
-	#
-	#	modified:   benchmarks.rb
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+
+	        new file:   README
+
+	Changes not staged for commit:
+	  (use "git add <file>..." to update what will be committed)
+	  (use "git checkout -- <file>..." to discard changes in working directory)
+
+	        modified:   benchmarks.rb
+
 
 Soubor `benchmarks.rb` je uveden v části „Changes not staged for commit“ (Změněno, ale neaktualizováno). Znamená to, že soubor, který je sledován, byl v pracovním adresáři změněn, avšak ještě nebyl připraven k zapsání. Chcete-li ho připravit, spusťte příkaz `git add` (jedná se o univerzální příkaz – používá se k zahájení sledování nových souborů, k připravení souborů a k dalším operacím, jako např. k označení souborů, které kolidovaly při sloučení, za vyřešené). Spusťme nyní příkaz `git add` k připravení souboru `benchmarks.rb` k zapsání a následně znovu příkaz `git status`:
 
 	$ git add benchmarks.rb
 	$ git status
-	# On branch master
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#	new file:   README
-	#	modified:   benchmarks.rb
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+
+	        new file:   README
+	        modified:   benchmarks.rb
+
 
 Oba soubory jsou nyní připraveny k zapsání a budou zahrnuty do příští revize. Nyní předpokládejme, že jste si vzpomněli na jednu malou změnu, kterou chcete ještě před zapsáním revize provést v souboru `benchmarks.rb`. Soubor znovu otevřete a provedete změnu. Soubor je připraven k zapsání. Spusťme však ještě jednou příkaz `git status`:
 
 	$ vim benchmarks.rb
 	$ git status
-	# On branch master
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#	new file:   README
-	#	modified:   benchmarks.rb
-	#
-	# Changes not staged for commit:
-	#   (use "git add <file>..." to update what will be committed)
-	#
-	#	modified:   benchmarks.rb
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+
+	        new file:   README
+	        modified:   benchmarks.rb
+
+	Changes not staged for commit:
+	  (use "git add <file>..." to update what will be committed)
+	  (use "git checkout -- <file>..." to discard changes in working directory)
+
+	        modified:   benchmarks.rb
+
 
 Co to má být? Soubor `benchmarks.rb` je nyní uveden jak v části připraveno k zapsání (Changes to be committed), tak v části nepřipraveno k zapsání (Changes not staged for commit). Jak je tohle možné? Věc se má tak, že Git po spuštění příkazu `git add` připraví soubor přesně tak, jak je. Pokud nyní revizi zapíšete, bude obsahovat soubor `benchmarks.rb` tak, jak vypadal když jste naposledy spustili příkaz `git add`, nikoli v té podobě, kterou měl v pracovním adresáři v okamžiku, když jste spustili příkaz `git commit`. Pokud upravíte soubor po provedení příkazu `git add`, je třeba spustit `git add` ještě jednou, aby byla připravena aktuální verze souboru:
 
 	$ git add benchmarks.rb
 	$ git status
-	# On branch master
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#	new file:   README
-	#	modified:   benchmarks.rb
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+
+	        new file:   README
+	        modified:   benchmarks.rb
+
 
 ### Ignorované soubory ###
 
@@ -180,6 +183,10 @@ Tady je další příklad souboru `.gitignore`:
 	build/
 	# ignoruj doc/notes.txt, ale nikoli doc/server/arch.txt
 	doc/*.txt
+	# ignoruj všechny .txt soubory v adresáři doc/
+	doc/**/*.txt
+
+Část masky `**/` je v Gitu dostupná od verze 1.8.2.
 
 ### Zobrazení připravených a nepřipravených změn ###
 
@@ -188,17 +195,18 @@ Je-li pro vaše potřeby příkaz `git status` příliš neurčitý – chcete p
 Řekněme, že znovu upravíte a připravíte soubor `README` a poté bez připravení upravíte soubor `benchmarks.rb`. Po spuštění příkazu `status` se zobrazí zhruba toto:
 
 	$ git status
-	# On branch master
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#	new file:   README
-	#
-	# Changes not staged for commit:
-	#   (use "git add <file>..." to update what will be committed)
-	#
-	#	modified:   benchmarks.rb
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+
+	        new file:   README
+
+	Changes not staged for commit:
+	  (use "git add <file>..." to update what will be committed)
+	  (use "git checkout -- <file>..." to discard changes in working directory)
+
+	        modified:   benchmarks.rb
+
 
 Chcete-li vidět, co jste změnili, avšak ještě nepřipravili k zapsání, zadejte příkaz `git diff` bez dalších parametrů:
 
@@ -243,16 +251,18 @@ V dalším příkladu ukážeme situaci, kdy jste připravili soubor `benchmarks
 	$ git add benchmarks.rb
 	$ echo '# test line' >> benchmarks.rb
 	$ git status
-	# On branch master
-	#
-	# Changes to be committed:
-	#
-	#	modified:   benchmarks.rb
-	#
-	# Changes not staged for commit:
-	#
-	#	modified:   benchmarks.rb
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+
+	        modified:   benchmarks.rb
+
+	Changes not staged for commit:
+	  (use "git add <file>..." to update what will be committed)
+	  (use "git checkout -- <file>..." to discard changes in working directory)
+
+	        modified:   benchmarks.rb
+
 
 Příkaz `git diff` nyní můžete použít k zobrazení změn, které dosud nejsou připraveny:
 
@@ -301,10 +311,9 @@ Editor zobrazí následující text (tento příklad je z editoru Vim):
 	# with '#' will be ignored, and an empty message aborts the commit.
 	# On branch master
 	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
 	#       new file:   README
 	#       modified:   benchmarks.rb
+	#
 	~
 	~
 	~
@@ -315,8 +324,8 @@ Jak vidíte, výchozí zpráva k revizi (commit message) obsahuje zakomentovaný
 Zprávu k revizi můžete rovněž napsat do řádku k příkazu `commit`. Jako zprávu ji označíte tak, že před ni vložíte příznak `-m`:
 
 	$ git commit -m "Story 182: Fix benchmarks for speed"
-	[master]: created 463dc4f: "Fix benchmarks for speed"
-	 2 files changed, 3 insertions(+), 0 deletions(-)
+	[master 463dc4f] Story 182: Fix benchmarks for speed
+	 2 files changed, 3 insertions(+)
 	 create mode 100644 README
 
 Nyní jste vytvořili svou první revizi! Vidíte, že se po zapsání revize zobrazil výpis s informacemi: do jaké větve jste revizi zapsali (hlavní, `master`), jaký kontrolní součet SHA-1 revize dostala (`463dc4f`), kolik souborů bylo změněno a statistiku přidaných a odstraněných řádků revize.
@@ -328,15 +337,17 @@ Nezapomeňte, že revize zaznamená snímek projektu, jak je obsažen v oblasti
 Přestože může být oblast připravených změn opravdu užitečným nástrojem pro přesné vytváření revizí, je někdy při daném pracovním postupu zbytečným mezikrokem. Chcete-li oblast připravených změn úplně přeskočit, nabízí Git jednoduchou zkratku. Přidáte-li k příkazu `git commit` parametr `-a`, Git do revize automaticky zahrne každý soubor, který je sledován. Zcela tak odpadá potřeba zadávat příkaz `git add`:
 
 	$ git status
-	# On branch master
-	#
-	# Changes not staged for commit:
-	#
-	#	modified:   benchmarks.rb
-	#
+	On branch master
+	Changes not staged for commit:
+	  (use "git add <file>..." to update what will be committed)
+	  (use "git checkout -- <file>..." to discard changes in working directory)
+
+	        modified:   benchmarks.rb
+
+	no changes added to commit (use "git add" and/or "git commit -a")
 	$ git commit -a -m 'added new benchmarks'
 	[master 83e38c7] added new benchmarks
-	 1 files changed, 5 insertions(+), 0 deletions(-)
+	 1 files changed, 5 insertions(+)
 
 Tímto způsobem není nutné provádět před zapsáním revize příkaz `git add` pro soubor `benchmarks.rb`.
 
@@ -348,26 +359,26 @@ Pokud soubor jednoduše odstraníte z pracovního adresáře, zobrazí se ve vý
 
 	$ rm grit.gemspec
 	$ git status
-	# On branch master
-	#
-	# Changes not staged for commit:
-	#   (use "git add/rm <file>..." to update what will be committed)
-	#
-	#       deleted:    grit.gemspec
-	#
+	On branch master
+	Changes not staged for commit:
+	  (use "git add/rm <file>..." to update what will be committed)
+	  (use "git checkout -- <file>..." to discard changes in working directory)
+
+	        deleted:    grit.gemspec
+
+	no changes added to commit (use "git add" and/or "git commit -a")
 
 Pokud nyní provedete příkaz `git rm`, bude k zapsání připraveno odstranění souboru:
 
 	$ git rm grit.gemspec
 	rm 'grit.gemspec'
 	$ git status
-	# On branch master
-	#
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#       deleted:    grit.gemspec
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+
+	        deleted:    grit.gemspec
+
 
 Po příštím zapsání revize soubor zmizí a nebude sledován. Pokud už jste soubor upravili a přidali do indexu, musíte odstranění provést pomocí parametru `-f`. Jedná se o bezpečnostní funkci, jež má zabránit nechtěnému odstranění dat, která ještě nebyla nahrána do snímku, a nemohou proto být ze systému Git obnovena.
 
@@ -395,22 +406,20 @@ Může se zdát zvláštní, že Git přesto používá příkaz `mv`. Chcete-li
 
 a vše funguje na výbornou. A skutečně, pokud takový příkaz provedete a podíváte se na stav souboru, uvidíte, že ho Git považuje za přejmenovaný (renamed):
 
-	$ git mv README.txt README
+	$ git mv README README.txt
 	$ git status
-	# On branch master
-	# Your branch is ahead of 'origin/master' by 1 commit.
-	#
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#       renamed:    README.txt -> README
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+
+	        renamed:    README -> README.txt
+
 
 Výsledek je však stejný, jako byste provedli následující:
 
-	$ mv README.txt README
-	$ git rm README.txt
-	$ git add README
+	$ mv README README.txt
+	$ git rm README
+	$ git add README.txt
 
 Git implicitně zjistí, že se jedná o přejmenování, a proto nehraje roli, zda přejmenujete soubor tímto způsobem, nebo pomocí příkazu `mv`. Jediným skutečným rozdílem je, že `mv` je jediný příkaz, zatímco u druhého způsobu potřebujete příkazy tři — příkaz `mv` je pouze zjednodušením. Důležitější je, že můžete použít jakýkoli způsob přejmenování a příkaz add/rm provést později, před zapsáním revize.
 
@@ -460,11 +469,13 @@ Jedním z nejužitečnějších je parametr `-p`, který zobrazí rozdíly diff
 	index a874b73..8f94139 100644
 	--- a/Rakefile
 	+++ b/Rakefile
-	@@ -5,7 +5,7 @@ require 'rake/gempackagetask'
+	@@ -5,5 +5,5 @@ require 'rake/gempackagetask'
 	 spec = Gem::Specification.new do |s|
+	     s.name      =   "simplegit"
 	-    s.version   =   "0.1.0"
 	+    s.version   =   "0.1.1"
 	     s.author    =   "Scott Chacon"
+	     s.email     =   "schacon@gee-mail.com
 
 	commit 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7
 	Author: Scott Chacon <schacon@gee-mail.com>
@@ -488,6 +499,27 @@ Jedním z nejužitečnějších je parametr `-p`, který zobrazí rozdíly diff
 	\ No newline at end of file
 
 Tento parametr zobrazí tytéž informace, ale za každým záznamem následuje informace o rozdílech. Tato funkce je velmi užitečná při kontrole kódu nebo k rychlému zjištění, co bylo obsahem série revizí, které přidal váš spolupracovník.
+
+Někdy se změny kontrolují snadněji na úrovni slov než na úrovni řádků. Git nabízí parametr `--word-diff`, který můžeme přidat za příkaz `git log -p`. Místo obvyklé detekce rozdílů po řádcích získáme rozdíly po slovech. Zjišťování rozdílů po slovech je u zdrojového kódu celkem k ničemu, ale pokud porovnáváme velké textové soubory -- jako například knihy nebo vaši disertační práci --, pak se tato možnost hodí. Tady máme příklad:
+
+	$ git log -U1 --word-diff
+	commit ca82a6dff817ec66f44342007202690a93763949
+	Author: Scott Chacon <schacon@gee-mail.com>
+	Date:   Mon Mar 17 21:52:11 2008 -0700
+
+	    changed the version number
+
+	diff --git a/Rakefile b/Rakefile
+	index a874b73..8f94139 100644
+	--- a/Rakefile
+	+++ b/Rakefile
+	@@ -7,3 +7,3 @@ spec = Gem::Specification.new do |s|
+	    s.name      =   "simplegit"
+	    s.version   =   [-"0.1.0"-]{+"0.1.1"+}
+	    s.author    =   "Scott Chacon"
+
+Jak vidíte, výstup neobsahuje žádné přidané a odstraněné řádky, jak tomu bývá u běžného zobrazení rozdílů (diff). Místo toho se změny zobrazují uvnitř textu. Přidaná slova jsou uzavřena mezi značkami `{+ +}` a odstraněná jsou uzavřena v `[- -]`. Možná byste také rádi zredukovali obvyklé třířádkové okolí změny na pouhý jeden řádek, protože chcete znát okolí slova a ne okolí řádku. Můžeme toho dosáhnout zadáním parametru `-U1`, jako ve výše uvedeném příkladu.
+
 Ve spojení s příkazem `git log` můžete použít také celou řadu shrnujících parametrů. Pokud například chcete zobrazit některé stručné statistiky pro každou revizi, použijte parametr `--stat`:
 
 	$ git log --stat
@@ -498,7 +530,7 @@ Ve spojení s příkazem `git log` můžete použít také celou řadu shrnujíc
 	    changed the version number
 
 	 Rakefile |    2 +-
-	 1 files changed, 1 insertions(+), 1 deletions(-)
+	 1 file changed, 1 insertion(+), 1 deletion(-)
 
 	commit 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7
 	Author: Scott Chacon <schacon@gee-mail.com>
@@ -507,7 +539,7 @@ Ve spojení s příkazem `git log` můžete použít také celou řadu shrnujíc
 	    removed unnecessary test code
 
 	 lib/simplegit.rb |    5 -----
-	 1 files changed, 0 insertions(+), 5 deletions(-)
+	 1 file changed, 5 deletions(-)
 
 	commit a11bef06a3f659402fe7563abf99ad00de2209e6
 	Author: Scott Chacon <schacon@gee-mail.com>
@@ -518,7 +550,7 @@ Ve spojení s příkazem `git log` můžete použít také celou řadu shrnujíc
 	 README           |    6 ++++++
 	 Rakefile         |   23 +++++++++++++++++++++++
 	 lib/simplegit.rb |   25 +++++++++++++++++++++++++
-	 3 files changed, 54 insertions(+), 0 deletions(-)
+	 3 files changed, 54 insertions(+)
 
 Jak vidíte, parametr `--stat` vypíše pod každým záznamem revize seznam změněných souborů, kolik souborů bylo změněno (changed) a kolik řádků bylo v těchto souborech vloženo (insertions) a smazáno (deletions). Zároveň vloží na konec výpisu shrnutí těchto informací.
 Další opravdu užitečnou možností je parametr `--pretty`. Tento parametr změní výstup logu na jiný než výchozí formát. K dispozici máte několik přednastavených možností. Parametr `oneline` vypíše všechny revize na jednom řádku. Tuto možnost oceníte při velkém množství revizí. Dále se nabízejí parametry `short`, `full` a `fuller` (zkrácený, plný, úplný). Zobrazují výstup přibližně ve stejném formátu, avšak s více či méně podrobnými informacemi:
@@ -537,6 +569,11 @@ Nejzajímavějším parametrem je pak `format`, který umožňuje definovat vlas
 
 Tabulka 2-1 uvádí některé užitečné parametry, které format akceptuje.
 
+<!-- Poznámka pro překladatele: toto je zápis tabulky.
+Řádky musí být formátovány následovně
+<TAB><Text prvního sloupce><TAB><Text druhého sloupce>
+-->
+
 	Parametr	Popis výstupu
 	%H	Otisk (hash) revize
 	%h	Zkrácený otisk revize
@@ -572,8 +609,14 @@ Parametry `oneline` a `format` jsou zvlášť užitečné ve spojení s další
 
 To je jen několik základních parametrů k formátování výstupu pro příkaz `git log`, celkově jich je mnohem více. Tabulka 2-2 uvádí parametry, které jsme už zmínili, a některé další běžné parametry formátování, které mohou být užitečné. Pravý sloupec popisuje, jak který parametr změní výstup `log`u.
 
+<!-- Poznámka pro překladatele: toto je zápis tabulky.
+Řádky musí být formátovány následovně
+<TAB><Text prvního sloupce><TAB><Text druhého sloupce>
+-->
+
 	Parametr	Popis
 	-p	Zobrazí záplatu vytvořenou s každou revizí.
+	--word-diff	Zobrazí záplatu ve tvaru rozdílu po slovech.
 	--stat	Zobrazí statistiku pro změněné soubory v každé revizi.
 	--shortstat	Zobrazí pouze řádek změněno/vloženo/smazáno z příkazu --stat.
 	--name-only	Za informacemi o revizi zobrazí seznam změněných souborů.
@@ -581,7 +624,7 @@ To je jen několik základních parametrů k formátování výstupu pro příka
 	--abbrev-commit	Zobrazí pouze prvních několik znaků kontrolního součtu SHA-1 místo všech 40.
 	--relative-date	Zobrazí datum v relativním formátu (např. "2 weeks ago", tj. před 2 týdny) místo formátu s úplným datem.
 	--graph	Zobrazí vedle výstupu logu ASCII graf k historii větve a slučování.
-	--pretty	Zobrazí revize v alternativním formátu. Parametry příkazu jsou oneline, short, full, fuller a format (lze zadat vlastní formát).
+	--pretty	Zobrazí revize v alternativním formátu. Parametry příkazu jsou oneline, short, full, fuller a format (ve kterém uvedete svůj vlastní formát).
 	--oneline	Užitečná zkratka pro `--pretty=oneline --abbrev-commit`.
 
 ### Omezení výstupu logu ###
@@ -594,12 +637,19 @@ Velmi užitečné jsou naproti tomu časově omezující parametry, jako `--sinc
 
 Tento příkaz pracuje s velkým množstvím formátů. Můžete zadat konkrétní datum („2008-01-15“) nebo relativní datum, např. „2 years 1 day 3 minutes ago“ (před 2 roky, 1 dnem a 3 minutami).
 
-Z výpisu rovněž můžete filtrovat pouze revize, které odpovídají určitým kritériím. Parametr `--author` umožňuje filtrovat výpisy podle konkrétního autora, pomocí parametru `--grep` můžete ve zprávách k revizím vyhledávat klíčová slova. Chcete-li hledat současný výskyt parametrů author i grep, musíte přidat výraz `--all-match`, jinak se bude hledat kterýkoli z nich.
+Z výpisu rovněž můžete filtrovat pouze revize, které odpovídají určitým kritériím. Parametr `--author` umožňuje filtrovat výpisy podle konkrétního autora, pomocí parametru `--grep` můžete ve zprávách k revizím vyhledávat klíčová slova. (Všimněte si, že pokud použijete současně parametry author a grep, bude příkaz vyhledávat záznamy splňující obojí.)
+
+Pokud chcete zadat více parametrů grep, musíte přidat výraz `--all-match`, jinak se bude hledat kterýkoli z nich.
 
 Posledním opravdu užitečným parametrem, který lze přidat k příkazu `git log` , je zadání cesty. Jestliže zadáte název adresáře nebo souboru, výstup logu tím omezíte na revize, které provedly změnu v těchto souborech. Cesta je vždy posledním parametrem a většinou jí předcházejí dvě pomlčky (`--`) , jimiž je oddělena od ostatních parametrů.
 
 Tabulka 2-3 uvádí pro přehlednost zmíněné parametry a několik málo dalších. Tabulka 2.2
 
+<!-- Poznámka pro překladatele: toto je zápis tabulky.
+Řádky musí být formátovány následovně
+<TAB><Text prvního sloupce><TAB><Text druhého sloupce>
+-->
+
 	Parametr	Popis
 	-(n)	Zobrazí pouze posledních n revizí.
 	--since, --after	Omezí výpis na revize provedené po zadaném datu.
@@ -607,10 +657,55 @@ Tabulka 2-3 uvádí pro přehlednost zmíněné parametry a několik málo dalš
 	--author	Zobrazí pouze revize, v nichž autor odpovídá zadanému řetězci.
 	--committer	Zobrazí pouze revize, v nichž autor revize odpovídá zadanému řetězci.
 
-Pokud chcete například zjistit, které revize upravující testovací soubory byly v historii zdrojového kódu Git zapsány v říjnu 2008 Juniem Hamanem a nebyly sloučením, můžete zadat následující příkaz:
 
-	$ git log --pretty="%h - %s" --author=gitster --since="2008-10-01" \
-	   --before="2008-11-01" --no-merges -- t/
+### Omezení výstupního logu na určité datum nebo čas ###
+
+Pokud chcete zjistit, které revize (commit) v repozitáři se zdrojovým kódem Git (git://git.kernel.org/pub/scm/git/git.git) mají datum zápisu (CommitDate) 2014-04-29 -- relativně k vašemu lokálnímu časovému pásmu (takovému, jaké je nastaveno na vašem počítači), použijte příkaz
+
+    $ git log --after="2014-04-29 00:00:00" --before="2014-04-29 23:59:59" \
+      --pretty=fuller
+
+Protože se výstup bude lišit podle časového pásma v místě spuštění, doporučuje se v argumentech `--after` a `--before` vždy používat absolutní čas (například ve formátu ISO 8601, který obsahuje i informaci o časovém pásmu). Činíme tak proto, aby každý, kdo stejný příkaz spustí, obdržel stejné, opakovatelné výsledky.
+
+Pokud chceme získat zápisy z určitého časového okamžiku (například z 29. dubna 2013 v 17:07:22 středoevropského času), můžeme použít příkaz
+
+    $ git log  --after="2013-04-29T17:07:22+0200"      \
+              --before="2013-04-29T17:07:22+0200" --pretty=fuller
+
+    commit de7c201a10857e5d424dbd8db880a6f24ba250f9
+    Author:     Ramkumar Ramachandra <artagnon@gmail.com>
+    AuthorDate: Mon Apr 29 18:19:37 2013 +0530
+    Commit:     Junio C Hamano <gitster@pobox.com>
+    CommitDate: Mon Apr 29 08:07:22 2013 -0700
+
+        git-completion.bash: lexical sorting for diff.statGraphWidth
+
+        df44483a (diff --stat: add config option to limit graph width,
+        2012-03-01) added the option diff.startGraphWidth to the list of
+        configuration variables in git-completion.bash, but failed to notice
+        that the list is sorted alphabetically.  Move it to its rightful place
+        in the list.
+
+        Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
+        Signed-off-by: Junio C Hamano <gitster@pobox.com>
+
+Výše uvedené časy (`AuthorDate`, `CommitDate`) se zobrazují v základním tvaru (`--date=default`), který zobrazuje informaci o časovém pásmu autora nebo přispěvatele.
+
+K dalším užitečným formátům patří `--date=iso` (ISO 8601), `--date=rfc` (RFC 2822), `--date=raw` (sekundy od počátku (epoch; 1970-01-01 UTC)), `--date=local` (časy ve vašem lokálním časovém pásmu) a také `--date=relative` (jako například "2 hours ago", tj. před dvěma hodinami).
+
+Pokud použijete příkaz `git log` bez určení času, uvažuje se čas odpovídající okamžiku spuštění na vašem počítači (používá stejný posun vůči UTC).
+
+Pokud například na vašem počítači spustíte `git log` v 09:00 a vaše časové pásmo je vůči greenwichskému času posunut o tři hodiny vpřed, pak se výsledek následujících dvou příkazů shoduje:
+
+    $ git log --after=2008-06-01 --before=2008-07-01
+    $ git log --after="2008-06-01T09:00:00+0300" \
+        --before="2008-07-01T09:00:00+0300"
+
+A poslední příklad. Pokud chcete zjistit, které revize upravující testovací soubory ve zdrojovém kódu Git zapsal Junio Hamano v říjnu 2008 (relativě k časové zóně New Yorku) a které přitom nebyly sloučením (merge), můžete zadat následující příkaz:
+
+        $ git log --pretty="%h - %s" --author=gitster \
+           --after="2008-10-01T00:00:00-0400"         \
+          --before="2008-10-31T23:59:59-0400" --no-merges -- t/
 	5610e3b - Fix testcase failure when extended attribute
 	acd3b9e - Enhance hold_lock_file_for_{update,append}()
 	f563754 - demonstrate breakage of detached checkout wi
@@ -618,7 +713,7 @@ Pokud chcete například zjistit, které revize upravující testovací soubory
 	51a94af - Fix "checkout --track -b newbranch" on detac
 	b0ad11e - pull: allow "git pull origin $something:$cur
 
-Z téměř 20 000 revizí v historii zdrojového kódu Git zobrazí tento příkaz 6 záznamů, které odpovídají zadaným kritériím.
+Z více než 36 tisíc revizí v historii zdrojového kódu Git zobrazí tento příkaz 6 záznamů, které odpovídají zadaným kritériím.
 
 ### Grafické uživatelské rozhraní pro procházení historie ###
 
@@ -657,31 +752,32 @@ Následující dvě části popisují, jak vrátit změny provedené v oblasti p
 
 	$ git add .
 	$ git status
-	# On branch master
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#       modified:   README.txt
-	#       modified:   benchmarks.rb
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+
+	        modified:   README.txt
+	        modified:   benchmarks.rb
+
 
 Přímo pod nadpisem „Changes to be committed“ (Změny k zapsání) se říká: pro návrat z oblasti připravených změn použijte příkaz `git reset HEAD <soubor>...` Budeme se tedy řídit touto radou a vrátíme soubor `benchmarks.rb` z oblasti připravených změn:
 
 	$ git reset HEAD benchmarks.rb
-	benchmarks.rb: locally modified
+	Unstaged changes after reset:
+	M       benchmarks.rb
 	$ git status
-	# On branch master
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#       modified:   README.txt
-	#
-	# Changes not staged for commit:
-	#   (use "git add <file>..." to update what will be committed)
-	#   (use "git checkout -- <file>..." to discard changes in working directory)
-	#
-	#       modified:   benchmarks.rb
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+
+	        modified:   README.txt
+
+	Changes not staged for commit:
+	  (use "git add <file>..." to update what will be committed)
+	  (use "git checkout -- <file>..." to discard changes in working directory)
+
+	        modified:   benchmarks.rb
+
 
 Příkaz je sice trochu zvláštní, ale funguje. Soubor `benchmarks.rb` má stav „změněn“, ale už se nenachází v oblasti připravených změn.
 
@@ -689,23 +785,23 @@ Příkaz je sice trochu zvláštní, ale funguje. Soubor `benchmarks.rb` má sta
 
 A co když zjistíte, že nechcete zachovat změny, které jste provedli v souboru `benchmarks.rb`? Jak je můžete snadno zrušit a vrátit soubor zpět do podoby při poslední revizi (nebo při prvním klonování nebo v jakémkoli okamžiku, kdy jste ho zaznamenali v pracovním adresáři)? Příkaz `git status` vám naštěstí řekne, co dělat. U posledního příkladu vypadá oblast připravených změn takto:
 
-	# Changes not staged for commit:
-	#   (use "git add <file>..." to update what will be committed)
-	#   (use "git checkout -- <file>..." to discard changes in working directory)
-	#
-	#       modified:   benchmarks.rb
-	#
+	Changes not staged for commit:
+	  (use "git add <file>..." to update what will be committed)
+	  (use "git checkout -- <file>..." to discard changes in working directory)
+
+	        modified:   benchmarks.rb
+
 
 Výpis vám sděluje, jak zahodit změny (discard changes), které jste provedli (přinejmenším tak činí novější verze systému Git, od verze 1.6.1; pokud máte starší verzi, doporučujeme ji aktualizovat, čímž získáte některé z těchto vylepšených funkcí). Uděláme, co nám výpis radí:
 
 	$ git checkout -- benchmarks.rb
 	$ git status
-	# On branch master
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#       modified:   README.txt
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+
+	        modified:   README.txt
+
 
 Jak vidíte, změny byly zahozeny. Všimněte si také, že se jedná o nebezpečný příkaz. Veškeré změny, které jste v souboru provedli, jsou ztraceny, soubor jste právě překopírovali jiným souborem. Nikdy tento příkaz nepoužívejte, pokud si nejste zcela jisti, že už daný soubor nebudete potřebovat. Pokud potřebujete pouze odstranit soubor z cesty, podívejte se na odkládání a větvení v následující kapitole. Tyto postupy většinou bývají vhodnější.
 
@@ -721,12 +817,12 @@ Při manipulaci se vzdálenými repozitáři je nutné vědět, jak lze přidat
 Chcete-li zjistit, jaké vzdálené servery máte nakonfigurovány, můžete použít příkaz `git remote`. Systém vypíše zkrácené názvy všech identifikátorů vzdálených repozitářů, jež máte zadány. Pokud byl váš repozitář vytvořen klonováním, měli byste vidět přinejmenším server origin. Origin je výchozí název, který Git dává serveru, z nějž jste repozitář klonovali.
 
 	$ git clone git://github.com/schacon/ticgit.git
-	Initialized empty Git repository in /private/tmp/ticgit/.git/
-	remote: Counting objects: 595, done.
-	remote: Compressing objects: 100% (269/269), done.
-	remote: Total 595 (delta 255), reused 589 (delta 253)
-	Receiving objects: 100% (595/595), 73.31 KiB | 1 KiB/s, done.
-	Resolving deltas: 100% (255/255), done.
+	Cloning into 'ticgit'...
+	remote: Reusing existing pack: 1857, done.
+	remote: Total 1857 (delta 0), reused 0 (delta 0)
+	Receiving objects: 100% (1857/1857), 374.35 KiB | 193.00 KiB/s, done.
+	Resolving deltas: 100% (772/772), done.
+	Checking connectivity... done.
 	$ cd ticgit
 	$ git remote
 	origin
@@ -897,6 +993,7 @@ Informace značky se zobrazí spolu s revizí, kterou značka označuje, po zad
 	Date:   Mon Feb 9 14:45:11 2009 -0800
 
 	my version 1.4
+
 	commit 15027957951b64cf874c3557a0f3547bd83b3ff6
 	Merge: 4a447f7... a6b4c97...
 	Author: Scott Chacon <schacon@gee-mail.com>
@@ -1062,9 +1159,9 @@ Než ukončíme tuto kapitolu o základech práce se systémem Git, přidáme je
 
 ### Automatické dokončování ###
 
-Jestliže používáte shell Bash, nabízí vám Git možnost zapnout si skript automatického dokončování. Stáhněte si zdrojový kód Git a podívejte se do adresáře `contrib/completion`. Měli byste tam najít soubor s názvem `git-completion.bash`. Zkopírujte tento soubor do svého domovského adresáře a přidejte ho do souboru `.bashrc`:
+Jestliže používáte shell Bash, nabízí vám Git možnost zapnout si skript pro automatické dokončování. Stáhněte si zdrojový kód Git https://github.com/git/git/blob/master/contrib/completion/git-completion.bash. Nakopírujte tento soubor do vašeho domovského adresáře a do souboru `.bashrc` přidejte:
 
-	source ~/.git-completion.bash
+	source ~/git-completion.bash
 
 Chcete-li nastavit Git tak, aby měl automaticky dokončování pro shell Bash pro všechny uživatele, zkopírujte tento skript do adresáře `/opt/local/etc/bash_completion.d` v systémech Mac nebo do adresáře `/etc/bash_completion.d/` v systémech Linux. Toto je adresář skriptů, z nějž Bash automaticky načítá pro shellové dokončování.
 
diff --git a/cs/03-git-branching/01-chapter3.markdown b/cs/03-git-branching/01-chapter3.markdown
index 808bcb086..c71858d38 100644
--- a/cs/03-git-branching/01-chapter3.markdown
+++ b/cs/03-git-branching/01-chapter3.markdown
@@ -41,7 +41,7 @@ Tento příkaz vytvoří nový ukazatel na stejné revizi, na níž se právě n
 Insert 18333fig0304.png
 Obrázek 3-4. Několik větví ukazujících do historie dat revizí
 
-Jak Git pozná, na jaké větvi se právě nacházíte? Používá speciální ukazatel zvaný HEAD. Nenechte se mást, tento HEAD je velmi odlišný od všech koncepcí v ostatních systémech VCS, na něž jste možná zvyklí, jako Subversion nebo CVS. V systému Git se jedná o ukazatel na lokální větev, na níž se právě nacházíte. V našem případě jste však stále ještě na hlavní větvi. Příkazem git branch jste pouze vytvořili novou větev, zatím jste na ni nepřepnuli (viz obrázek 3-5).
+Jak Git pozná, na jaké větvi se právě nacházíte? Používá speciální ukazatel zvaný HEAD. Nenechte se mást, tento HEAD je velmi odlišný od všech koncepcí v ostatních systémech VCS, na něž jste možná zvyklí, jako Subversion nebo CVS. V systému Git se jedná o ukazatel na lokální větev, na níž se právě nacházíte. V našem případě jste však stále ještě na hlavní větvi. Příkazem `git branch` jste pouze vytvořili novou větev, zatím jste na ni nepřepnuli (viz obrázek 3-5).
 
 Insert 18333fig0305.png
 Obrázek 3-5. Soubor HEAD ukazující na větev, na níž se nacházíte.
@@ -117,7 +117,7 @@ Obrázek 3-10. Krátká a jednoduchá historie revizí
 Rozhodli jste se, že budete pracovat na chybě č. 53, ať už vaše společnost používá jakýkoli systém sledování chyb. Přesněji řečeno, Git není začleněn do žádného konkrétního systému sledování chyb, ale protože je chyba č. 53 významná a chcete na ní pracovat, vytvoříte si pro ni novou větev. Abyste vytvořili novou větev a rovnou na ni přepnuli, můžete spustit příkaz `git checkout` s přepínačem `-b`:
 
 	$ git checkout -b iss53
-	Switched to a new branch "iss53"
+	Switched to a new branch 'iss53'
 
 Tímto způsobem jste spojili dva příkazy:
 
@@ -142,18 +142,18 @@ V tomto okamžiku vám zavolají, že se na webových stránkách vyskytl probl
 Než tak učiníte, zkontrolujte, zda nemáte v pracovním adresáři nebo v oblasti připravených změn nezapsané změny, které kolidují s větví, jejíž checkout provádíte. V takovém případě by vám Git přepnutí větví nedovolil. Při přepínání větví je ideální, pokud máte čistý pracovní stav. Existují způsoby, jak toho docílit (jmenovitě odložení a doplnění revize), těm se však budeme věnovat až později. Pro tuto chvíli jste zapsali všechny provedené změny a můžete přepnout zpět na hlavní větev.
 
 	$ git checkout master
-	Switched to branch "master"
+	Switched to branch 'master'
 
 V tomto okamžiku vypadá váš pracovní adresář přesně tak, jak vypadal, než jste začali pracovat na chybě č. 53, a vy se nyní můžete soustředit na rychlou opravu. Na paměti byste však stále měli mít následující: Git vždy vrátí pracovní adresář do stejného stavu, jak vypadal snímek revize, na niž ukazuje větev, jejíž checkout nyní provádíte. Automaticky budou přidány, odstraněny a upraveny soubory tak, aby byla vaše pracovní kopie totožná se stavem větve v okamžiku, kdy jste na ni zapsali poslední revizi.
 
 Nyní přichází na řadu hotfix. Vytvořme větev s hotfixem, v níž budeme pracovat, dokud nebude oprava hotová (viz obrázek 3-13):
 
 	$ git checkout -b hotfix
-	Switched to a new branch "hotfix"
+	Switched to a new branch 'hotfix'
 	$ vim index.html
 	$ git commit -a -m 'fixed the broken email address'
-	[hotfix]: created 3a0874c: "fixed the broken email address"
-	 1 files changed, 0 insertions(+), 1 deletions(-)
+	[hotfix 3a0874c] fixed the broken email address
+	 1 files changed, 1 deletion(-)
 
 Insert 18333fig0313.png
 Obrázek 3-13. Větev „hotfix“ začleněná zpět v místě hlavní větve
@@ -163,9 +163,9 @@ Můžete provádět testování, ujistit se, že hotfix splňuje všechny požad
 	$ git checkout master
 	$ git merge hotfix
 	Updating f42c576..3a0874c
-	Fast forward
-	 README |    1 -
-	 1 files changed, 0 insertions(+), 1 deletions(-)
+	Fast-forward
+	 README | 1 -
+	 1 file changed, 1 deletion(-)
 
 Při sloučení jste si možná všimli spojení „Fast forward“ (rychle vpřed). Jelikož revize, na niž ukazovala větev, do níž jste začleňovali, byla v přímé linii s revizí, na níž jste se nacházeli, Git přesunul ukazatel vpřed. Jinými slovy: pokud se pokoušíte sloučit jednu revizi s revizí druhou, k níž lze dospět následováním historie první revize, Git proces zjednoduší a přesune ukazatel vpřed, protože neexistuje žádná rozdílná práce, kterou by bylo třeba sloučit. Tomuto postupu se říká „rychle vpřed“.
 
@@ -177,16 +177,16 @@ Obrázek 3-14. Hlavní větev ukazuje po sloučení na stejné místo jako věte
 Poté, co jste dokončili práci na bezodkladné opravě, můžete přepnout zpět na práci, jíž jste se věnovali před telefonátem. Nejprve však smažete větev `hotfix`, kterou teď už nebudete potřebovat – větev `master` ukazuje na totéž místo. Větev smažete přidáním parametru `-d` k příkazu `git branch`:
 
 	$ git branch -d hotfix
-	Deleted branch hotfix (3a0874c).
+	Deleted branch hotfix (was 3a0874c).
 
 Nyní můžete přepnout zpět na větev s rozdělanou prací a pokračovat na chybě č. 53 (viz obrázek 3-15):
 
 	$ git checkout iss53
-	Switched to branch "iss53"
+	Switched to branch 'iss53'
 	$ vim index.html
 	$ git commit -a -m 'finished the new footer [issue 53]'
-	[iss53]: created ad82d7a: "finished the new footer [issue 53]"
-	 1 files changed, 1 insertions(+), 0 deletions(-)
+	[iss53 ad82d7a] finished the new footer [issue 53]
+	 1 file changed, 1 insertion(+)
 
 Insert 18333fig0315.png
 Obrázek 3-15. Větev iss53 může nezávisle postupovat vpřed.
@@ -199,9 +199,10 @@ Předpokládejme, že jste dokončili práci na chybě č. 53 a nyní byste ji r
 
 	$ git checkout master
 	$ git merge iss53
-	Merge made by recursive.
-	 README |    1 +
-	 1 files changed, 1 insertions(+), 0 deletions(-)
+	Auto-merging README
+	Merge made by the 'recursive' strategy.
+	 README | 1 +
+	 1 file changed, 1 insertion(+)
 
 Toto už se trochu liší od začlenění větve `hotfix`, které jste prováděli před chvílí. V tomto případě se historie vývoje od určitého bodu v minulosti rozbíhala. Vzhledem k tomu, že revize na větvi, na níž se nacházíte, není přímým předkem větve, kterou chcete začlenit, Git bude muset podniknout určité kroky. Git v tomto případě provádí jednoduché třícestné sloučení: vychází ze dvou snímků, na které ukazují větve, a jejich společného předka. Obrázek 3-16 označuje ony tři snímky, které Git v tomto případě použije ke sloučení.
 
@@ -230,25 +231,27 @@ Může se stát, že sloučení neproběhne bez problémů. Pokud jste tutéž 
 
 Git nepřistoupil k automatickému vytvoření nové revize sloučením. Prozatím pozastavil celý proces do doby, než konflikt vyřešíte. Chcete-li kdykoli po konfliktu zjistit, které soubory zůstaly nesloučeny, spusťte příkaz `git status`:
 
-	[master*]$ git status
-	index.html: needs merge
-	# On branch master
-	# Changes not staged for commit:
-	#   (use "git add <file>..." to update what will be committed)
-	#   (use "git checkout -- <file>..." to discard changes in working directory)
-	#
-	#	unmerged:   index.html
-	#
+	$ git status
+	On branch master
+	You have unmerged paths.
+	  (fix conflicts and run "git commit")
+
+	Unmerged paths:
+	  (use "git add <file>..." to mark resolution)
+
+	        both modified:      index.html
+
+	no changes added to commit (use "git add" and/or "git commit -a")
 
 Vše, co při sloučení kolidovalo a nebylo vyřešeno, je označeno jako „unmerged“ (nesloučeno). Git přidává ke kolidujícím souborům standardní poznámky o řešení konfliktů (conflict-resolution markers), takže je můžete ručně otevřít a konflikty vyřešit. Jedna část vašeho souboru bude vypadat zhruba takto:
 
-	<<<<<<< HEAD:index.html
+	<<<<<<< HEAD
 	<div id="footer">contact : email.support@github.com</div>
 	=======
 	<div id="footer">
 	  please contact us at support@github.com
 	</div>
-	>>>>>>> iss53:index.html
+	>>>>>>> iss53
 
 To znamená, že verze ve větvi s ukazatelem HEAD (vaše hlavní větev – v té jste se nacházeli při provádění příkazu merge) je uvedena v horní části tohoto bloku (všechno nad oddělovačem `=======`), verze obsažená ve větvi `iss53` je vše, co se nachází v dolní části. Chcete-li vzniklý konflikt vyřešit, musíte buď vybrat jednu z obou stran, nebo konflikt sloučit sami. Tento konflikt můžete vyřešit například nahrazením celého bloku tímto textem:
 
@@ -260,12 +263,17 @@ Toto řešení obsahuje trochu z každé části a zcela jsem odstranil řádky
 Chcete-li k vyřešení problémů použít grafický nástroj, můžete spustit příkaz `git mergetool`, kterým otevřete příslušný vizuální nástroj pro slučování, a ten vás všemi konflikty provede:
 
 	$ git mergetool
-	merge tool candidates: kdiff3 tkdiff xxdiff meld gvimdiff opendiff emerge vimdiff
-	Merging the files: index.html
+
+	This message is displayed because 'merge.tool' is not configured.
+	See 'git mergetool --tool-help' or 'git help config' for more details.
+	'git mergetool' will now attempt to use one of the following tools:
+	opendiff kdiff3 tkdiff xxdiff meld tortoisemerge gvimdiff diffuse diffmerge ecmerge p4merge araxis bc3 codecompare vimdiff emerge
+	Merging:
+	index.html
 
 	Normal merge conflict for 'index.html':
-	  {local}: modified
-	  {remote}: modified
+	  {local}: modified file
+	  {remote}: modified file
 	Hit return to start merge resolution tool (opendiff):
 
 Chcete-li použít jiný než výchozí nástroj pro slučování (Git mi v tomto případě vybral `opendiff`, protože jsem příkaz zadal v systému Mac), všechny podporované nástroje jsou uvedeny na začátku výstupu v části „merge tool candidates“ (možné nástroje pro slučování). Zadejte název nástroje, který chcete použít. V kapitole 7 probereme, jak lze tuto výchozí hodnotu pro vaše prostředí změnit.
@@ -275,12 +283,12 @@ Až nástroj pro slučování zavřete, Git se vás zeptá, zda sloučení prob
 Ještě jednou můžete spustit příkaz `git status`, abyste si ověřili, že byly všechny konflikty vyřešeny:
 
 	$ git status
-	# On branch master
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#	modified:   index.html
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+
+	        modified:   index.html
+
 
 Pokud jste s výsledkem spokojeni a ujistili jste se, že všechny kolidující soubory jsou připraveny k zapsání, můžete zadat příkaz `git commit` a dokončit revizi sloučením. Zpráva revize má v takovém případě přednastavenu tuto podobu:
 
@@ -289,9 +297,9 @@ Pokud jste s výsledkem spokojeni a ujistili jste se, že všechny kolidující
 	Conflicts:
 	  index.html
 	#
-	# It looks like you may be committing a MERGE.
+	# It looks like you may be committing a merge.
 	# If this is not correct, please remove the file
-	# .git/MERGE_HEAD
+	#       .git/MERGE_HEAD
 	# and try again.
 	#
 
@@ -331,7 +339,7 @@ Chcete-li zobrazit větve, které obsahují dosud nezačleněnou práci, spusťt
 Nyní se zobrazila jiná větev. Jelikož obsahuje práci, která ještě nebyla začleněna, bude pokus o její smazání příkazem `git branch -d` neúspěšný:
 
 	$ git branch -d testing
-	error: The branch 'testing' is not an ancestor of your current HEAD.
+	error: The branch 'testing' is not fully merged.
 	If you are sure you want to delete it, run 'git branch -D testing'.
 
 Pokud chcete větev skutečně odstranit a zahodit práci, kterou obsahuje, můžete si to vynutit parametrem `-D` (jak napovídá užitečná zpráva pod řádkem s chybovým hlášením).
@@ -344,7 +352,7 @@ Teď, když jste absolvovali základní seznámení s větvemi a jejich slučov
 
 Vzhledem k tomu, že Git používá jednoduché třícestné slučování, je velmi snadné začleňovat jednu větev do druhé i několikrát v rámci dlouhého časového intervalu. Můžete tak mít několik větví, které jsou stále otevřené a které používáte pro různé fáze vývojového cyklu. Pravidelně můžete začleňovat práci z jedné větve do ostatních.
 
-Mnoho vývojářů systému Git používá pracovní postup, při němž je tato metoda zcela ideální. Ve větvi `master` mají pouze kód, který je stoprocentně stabilní — třeba jen kód, který byl nebo bude součástí vydání. Kromě ní mají další paralelní větev, pojmenovanou `develop` nebo `next`, v níž skutečně pracují nebo testují stabilitu kódu. Tato větev nemusí být nutně stabilní, ale jakmile se dostane do stabilního stavu, může být začleněna do větve `master`. Používá se k natahování tematických větví (těch dočasných, jako byla vaše větev `iss53`) ve chvíli, kdy je k tomu vše připraveno a nehrozí, že práce neprojde testy nebo bude způsobovat chyby.
+Mnoho vývojářů systému Git používá pracovní postup, kdy mají ve větvi `master` pouze kód, který je stoprocentně stabilní — třeba jen kód, který byl nebo bude součástí vydání. Kromě ní mají další paralelní větev, pojmenovanou `develop` nebo `next`, v níž skutečně pracují nebo testují stabilitu kódu. Tato větev nemusí být nutně stabilní, ale jakmile se dostane do stabilního stavu, může být začleněna do větve `master`. Ta se pak používá se k začleňování do tematických větví (těch dočasných, jako byla vaše větev `iss53`) ve chvíli, kdy je k tomu vše připraveno a nehrozí, že práce neprojde testy nebo bude způsobovat chyby.
 
 Ve skutečnosti hovoříme o ukazatelích pohybujících se vzhůru po linii revizí, které zapisujete. Stabilní větve leží v linii historie revizí níže a nové, neověřené větve se nacházejí nad nimi (viz obrázek 3-18).
 
@@ -381,7 +389,7 @@ Při tom všem, co nyní děláte, je důležité mít na paměti, že všechny
 
 Vzdálené větve jsou reference (tj. odkazy) na stav větví ve vašich vzdálených repozitářích. Jsou to lokální větve, které nemůžete přesouvat. Přesouvají se automaticky při síťové komunikaci. Vzdálené větve slouží jako záložky, které vám připomínají, kde byly větve ve vzdálených repozitářích, když jste se k nim naposledy připojili.
 
-Vzdálené větve mají podobu `(vzdálený repozitář)/(větev)`. Například: Chcete-li zjistit, jak vypadala větev `master` na vašem vzdáleném serveru `origin`, když jste s ní naposledy komunikovali, budete hledat větev `origin/master`. Pokud pracujete s kolegou na stejném problému a on odešle na server větev s názvem `iss53`, může se stát, že i vy máte jednu z lokálních větví pojmenovanou jako `iss53`. Větev na serveru však ukazuje na revizi označenou jako `origin/iss53`.
+Vzdálené větve mají podobu `(vzdálený repozitář)/(větev)`. Pokud například chcete zjistit, jak vypadala větev `master` na vašem vzdáleném serveru `origin`, když jste s ní naposledy komunikovali, budete hledat větev `origin/master`. Pokud pracujete s kolegou na stejném problému a on odešle na server větev s názvem `iss53`, může se stát, že i vy máte jednu z lokálních větví pojmenovanou jako `iss53`. Větev na serveru však ukazuje na revizi označenou jako `origin/iss53`.
 
 Mohlo by to být trochu matoucí, takže si uveďme příklad. Řekněme, že máte v síti server Git označený `git.ourcompany.com`. Pokud provedete klonování z tohoto serveru, Git ho automaticky pojmenuje `origin`, stáhne z něj všechna data, vytvoří ukazatel, který bude označovat jeho větev `master`, a lokálně ji pojmenuje `origin/master`. Tuto větev nemůžete přesouvat. Git vám rovněž vytvoří vaši vlastní větev `master`, která bude začínat ve stejném místě jako větev `master` serveru `origin`. Máte tak definován výchozí bod pro svoji práci (viz obrázek 3-22).
 
@@ -396,7 +404,7 @@ Obrázek 3-23. Pokud pracujete lokálně a někdo jiný odešle svou práci na v
 K synchronizaci své práce použijte příkaz `git fetch origin`. Tento příkaz zjistí, který server je „origin“ (v našem případě je to `git.ourcompany.com`), vyzvedne z něj všechna data, která ještě nemáte, a aktualizuje vaši lokální databázi. Při tom přemístí ukazatel `origin/master` na novou, aktuálnější pozici (viz obrázek 3-24).
 
 Insert 18333fig0324.png
-Obrázek 3-24. Příkaz git fetch aktualizuje vaše reference na vzdálený server.
+Obrázek 3-24. Příkaz `git fetch` aktualizuje vaše reference na vzdálený server.
 
 Abychom si mohli ukázat, jak se pracuje s několika vzdálenými servery a jak vypadají vzdálené větve takových vzdálených projektů, předpokládejme, že máte ještě další interní server Git, který při vývoji používá pouze jeden z vašich sprint teamů. Tento server se nachází na `git.team1.ourcompany.com`. Můžete ho přidat jako novou vzdálenou referenci k projektu, na němž právě pracujete – spusťte příkaz `git remote add` (viz kapitola 2). Pojmenujte tento vzdálený server jako `teamone`, což bude zkrácený název pro celou URL adresu (viz obrázek 3-25).
 
@@ -439,8 +447,8 @@ Tady je důležité upozornit, že pokud vyzvedáváte data a stáhnete s nimi i
 Chcete-li začlenit tato data do své aktuální pracovní větve, spusťte příkaz `git merge origin/serverfix`. Chcete-li mít vlastní větev `serverfix`, na níž budete pracovat, můžete ji ze vzdálené větve vyvázat:
 
 	$ git checkout -b serverfix origin/serverfix
-	Branch serverfix set up to track remote branch refs/remotes/origin/serverfix.
-	Switched to a new branch "serverfix"
+	Branch serverfix set up to track remote branch serverfix from origin.
+	Switched to a new branch 'serverfix'
 
 Tímto způsobem získáte lokální větev, na níž můžete pracovat a která začíná na pozici `origin/serverfix`.
 
@@ -451,16 +459,16 @@ Checkoutem lokální větve ze vzdálené větve automaticky vytvoříte tzv. Sl
 Pokud klonujete repozitář, většinou se vytvoří větev `master`, která bude sledovat větev `origin/master`. To je také důvod, proč příkazy `git push` a `git pull` fungují i bez dalších parametrů. Pokud chcete, můžete nastavit i jiné sledující větve – takové, které nebudou sledovat větve na serveru `origin` a nebudou sledovat hlavní větev `master`. Jednoduchým případem je příklad, který jste právě viděli: spuštění příkazu `git checkout -b [větev] [vzdálený server]/[větev]`. Máte-li Git ve verzi 1.6.2 nebo novější, můžete použít také zkrácenou variantu `--track`:
 
 	$ git checkout --track origin/serverfix
-	Branch serverfix set up to track remote branch refs/remotes/origin/serverfix.
-	Switched to a new branch "serverfix"
+	Branch serverfix set up to track remote branch serverfix from origin.
+	Switched to a new branch 'serverfix'
 
 Chcete-li nastavit lokální větev s jiným názvem, než má vzdálená větev, můžete jednoduše použít první variantu s odlišným názvem lokální větve:
 
 	$ git checkout -b sf origin/serverfix
-	Branch sf set up to track remote branch refs/remotes/origin/serverfix.
-	Switched to a new branch "sf"
+	Branch sf set up to track remote branch serverfix from origin.
+	Switched to a new branch 'sf'
 
-Vaše lokální větev „sf“ bude nyní automaticky stahovat data ze vzdálené větve origin/serverfix a bude do ní i odesílat.
+Vaše lokální větev `sf` bude nyní automaticky stahovat data ze vzdálené větve `origin/serverfix` a bude do ní i odesílat.
 
 ### Mazání vzdálených větví ###
 
diff --git a/cs/04-git-server/01-chapter4.markdown b/cs/04-git-server/01-chapter4.markdown
index 890884cc4..93147edbe 100644
--- a/cs/04-git-server/01-chapter4.markdown
+++ b/cs/04-git-server/01-chapter4.markdown
@@ -117,9 +117,10 @@ Pro úvodní nastavení serveru Git je třeba exportovat existující repozitá
 Chcete-li naklonovat stávající repozitář, a vytvořit tak nový a holý, zadejte příkaz clone s parametrem `--bare`. Je zvykem, že adresáře s holým repozitářem končí na `.git`, například:
 
 	$ git clone --bare my_project my_project.git
-	Initialized empty Git repository in /opt/projects/my_project.git/
+	Cloning into bare repository 'my_project.git'...
+	done.
 
-Výstup tohoto příkazu je trochu nejasný. Protože příkaz `clone` znamená v podstatě `git init` a následně `git fetch`, vidíme z části `git init`, která vytvoří prázdný adresář, nějaký výstup. Následný přenos objektu neposkytuje žádný výstup, přesto však proběhl. V adresáři `my_project.git` byste nyní měli mít kopii dat z adresáře Git.
+V adresáři `my_project.git` byste nyní měli mít kopii dat z adresáře Git.
 
 Je to přibližně stejné, jako byste zadali například:
 
@@ -283,12 +284,17 @@ Nejprve ze všeho budete muset zapnout zásuvný modul:
 	$ mv hooks/post-update.sample hooks/post-update
 	$ chmod a+x hooks/post-update
 
-Jestliže používáte verzi systému Git starší než 1.6, nebude příkaz `mv` nutný. Git začal pojmenovávat příklady zásuvných modulů příponou „.sample“ teprve nedávno.
-
 Jaká je funkce zásuvného modulu `post-update`? V principu vypadá asi takto:
 
 	$ cat .git/hooks/post-update
 	#!/bin/sh
+	#
+	# An example hook script to prepare a packed repository for use over
+	# dumb transports.
+	#
+	# To enable this hook, rename this file to "post-update".
+	#
+
 	exec git-update-server-info
 
 Znamená to, že až budete odesílat data na server prostřednictvím SSH, Git spustí tento příkaz a aktualizuje soubory vyžadované pro přístup přes HTTP.
@@ -404,7 +410,7 @@ Nyní máte vše hotovo. Pokud jste nastavení provedli správně, můžete vyzk
 
 	$ ssh git@gitserver
 	PTY allocation request failed on channel 0
-	fatal: unrecognized command 'gitosis-serve schacon@quaternion'
+	ERROR:gitosis.serve.main:Need SSH_ORIGINAL_COMMAND in environment.
 	  Connection to gitserver closed.
 
 To znamená, že vás Gitosis sice rozpoznal, ale nedovolí vám přístup, protože se nepokoušíte zadat žádný příkaz Git. Provedeme tedy skutečný příkaz systému Git a naklonujeme řídicí repozitář Gitosis:
@@ -428,28 +434,28 @@ Pokud se podíváte na soubor `gitosis.conf`, měl by udávat pouze informace o
 	[gitosis]
 
 	[group gitosis-admin]
-	writable = gitosis-admin
 	members = scott
+	writable = gitosis-admin
 
 Tato informace znamená, že uživatel 'scott' – ten, jehož veřejným klíčem jste inicializovali Gitosis – je jediným uživatelem, který má přístup k projektu `gitosis-admin`.
 
 Nyní přidáme nový projekt. Přidáte novou část s názvem `mobile`, která bude obsahovat seznam vývojářů vašeho mobilního týmu a projektů, k nimž tito vývojáři potřebují přístup. Protože je v tuto chvíli jediným uživatelem v systému 'scott', přidáte ho jako jediného člena a vytvoříte pro něj nový projekt s názvem `iphone_project`:
 
 	[group mobile]
-	writable = iphone_project
 	members = scott
+	writable = iphone_project
 
 Pokaždé, když provedete změny v projektu `gitosis-admin`, musíte tyto změny zapsat a odeslat je zpět na server, aby nabyly účinnosti:
 
 	$ git commit -am 'add iphone_project and mobile group'
-	[master]: created 8962da8: "changed name"
-	 1 files changed, 4 insertions(+), 0 deletions(-)
-	$ git push
+	[master 8962da8] add iphone_project and mobile group
+	 1 file changed, 4 insertions(+)
+	$ git push origin master
 	Counting objects: 5, done.
-	Compressing objects: 100% (2/2), done.
-	Writing objects: 100% (3/3), 272 bytes, done.
-	Total 3 (delta 1), reused 0 (delta 0)
-	To git@gitserver:/opt/git/gitosis-admin.git
+	Compressing objects: 100% (3/3), done.
+	Writing objects: 100% (3/3), 272 bytes | 0 bytes/s, done.
+	Total 3 (delta 0), reused 0 (delta 0)
+	To git@gitserver:gitosis-admin.git
 	   fb27aec..8962da8  master -> master
 
 Do nového projektu `iphone_project` teď můžete odeslat svá první data: přidejte do lokální verze projektu svůj server jako vzdálený repozitář a odešlete změny. Od této chvíle už nebudete muset ručně vytvářet holé repozitáře pro nové projekty na serveru. Gitosis je vytvoří automaticky, jakmile zjistí první odeslání dat:
@@ -458,7 +464,7 @@ Do nového projektu `iphone_project` teď můžete odeslat svá první data: př
 	$ git push origin master
 	Initialized empty Git repository in /opt/git/iphone_project.git/
 	Counting objects: 3, done.
-	Writing objects: 100% (3/3), 230 bytes, done.
+	Writing objects: 100% (3/3), 230 bytes | 0 bytes/s, done.
 	Total 3 (delta 0), reused 0 (delta 0)
 	To git@gitserver:iphone_project.git
 	 * [new branch]      master -> master
@@ -474,20 +480,20 @@ Na tomto projektu chcete spolupracovat s přáteli, a proto budete muset znovu p
 Nyní je můžete všechny přidat do týmu 'mobile', čímž získají oprávnění pro čtení i pro zápis k `iphone_project`:
 
 	[group mobile]
-	writable = iphone_project
 	members = scott john josie jessica
+	writable = iphone_project
 
 Až tuto změnu zapíšete a odešlete, všichni čtyři uživatelé budou moci z tohoto projektu číst a zapisovat do něj.
 
 Gitosis nabízí také jednoduchou správu přístupu. Pokud chcete, aby měl John u projektu pouze oprávnění pro čtení, můžete provést následující:
 
 	[group mobile]
-	writable = iphone_project
 	members = scott josie jessica
+	writable = iphone_project
 
 	[group mobile_ro]
-	readonly = iphone_project
 	members = john
+	readonly = iphone_project
 
 John nyní může naklonovat projekt a stahovat jeho aktualizace, ale Gitosis mu neumožní, aby odesílal data zpět do projektu. Takových skupin můžete vytvořit libovolně mnoho. Každá může obsahovat různé uživatele a projekty. Jako jednoho ze členů skupiny můžete zadat také celou jinou skupinu (použijete pro ni předponu `@`). Všichni její členové se tím automaticky zdědí.
 
@@ -495,12 +501,12 @@ John nyní může naklonovat projekt a stahovat jeho aktualizace, ale Gitosis mu
 	members = scott josie jessica
 
 	[group mobile]
-	writable  = iphone_project
 	members   = @mobile_committers
+	writable  = iphone_project
 
 	[group mobile_2]
-	writable  = another_iphone_project
 	members   = @mobile_committers john
+	writable  = another_iphone_project
 
 Máte-li jakékoli problémy, může vám pomoci zadání `loglevel=DEBUG` do části `[gitosis]`. Pokud jste odesláním nesprávné konfigurace ztratili oprávnění k odesílání dat, můžete ručně opravit soubor na serveru v adresáři `/home/git/.gitosis.conf` – jedná se o soubor, z nějž Gitosis načítá data. Po odeslání dat do projektu bude soubor `gitosis.conf`, který jste právě odeslali, umístěn do tohoto adresáře. Pokud soubor ručně upravíte, zůstane v této podobě až do dalšího úspěšného odeslání do projektu `gitosis-admin`.
 
@@ -521,11 +527,11 @@ Instalace Gitolite je velmi jednoduchá a to i když nebudete číst obsáhlou d
 
 Nástroj Gitolite je ve smyslu „serverového“ softwaru poněkud neobvyklý. Přístup se realizuje přes ssh, takže každá serverová userid je potenciálně „hostitelem gitolite“ (gitolite host). Teď si popíšeme nejjednodušší způsob instalace. V dokumentaci naleznete další metody.
 
-Začněte tím, že na serveru vytvoříte uživatele nazvaného `git` a přihlásíte se na něj. Z vaší pracovní stanice nakopírujte svůj veřejný ssh klíč (pokud jste spustili `ssh-keygen` s implicitními hodnotami, jde o soubor `~/.ssh/id_rsa.pub`) a přejmenujte jej na `VaseJmeno.pub`. Potom proveďte následující příkazy:
+Začněte tím, že na serveru vytvoříte uživatele nazvaného `git` a přihlásíte se na něj. Z vaší pracovní stanice nakopírujte svůj veřejný SSH klíč (pokud jste spustili `ssh-keygen` s implicitními hodnotami, jde o soubor `~/.ssh/id_rsa.pub`) a přejmenujte jej na `<vasejmeno>.pub` (v příkladech budeme používat `scott.pub`). Potom proveďte následující příkazy:
 
 	$ git clone git://github.com/sitaramc/gitolite
 	$ gitolite/install -ln
-	    # předpokládá existenci $HOME/bin a uvedení tohoto adresáře v $PATH
+	    # assumes $HOME/bin exists and is in your $PATH
 	$ gitolite setup -pk $HOME/scott.pub
 
 Poslední příkaz vytvoří na serveru nový gitovský repozitář nazvaný `gitolite-admin`.
diff --git a/cs/05-distributed-git/01-chapter5.markdown b/cs/05-distributed-git/01-chapter5.markdown
index e046c1f2d..89140cfe2 100644
--- a/cs/05-distributed-git/01-chapter5.markdown
+++ b/cs/05-distributed-git/01-chapter5.markdown
@@ -174,7 +174,7 @@ John má referenci ke změnám, které odeslala Jessica, ale než bude moci sám
 Sloučení probíhá hladce, Johnova historie revizí teď vypadá jako na obrázku 5-5.
 
 Insert 18333fig0505.png
-Obrázek 5-5. Johnův repozitář po začlenění větve origin/master
+Obrázek 5-5. Johnův repozitář po začlenění větve `origin/master`
 
 John nyní může otestovat svůj kód, aby se ujistil, že stále pracuje správně, a pak může odeslat svou novou sloučenou práci na server:
 
@@ -215,7 +215,7 @@ Jessica považuje svou tematickou větev za dokončenou, ale chce vědět, do č
 
 	    removed invalid default value
 
-Jessica nyní může začlenit tematickou větev do své hlavní větve, tamtéž začlenit i Johnovu práci (`origin/master`) do své větve `master` a vše odeslat zpět na server. Nejprve se přepne zpět na svou hlavní větev, aby do ní mohla vše integrovat:
+Jessica nyní může začlenit tematickou větev do své větve `master`, začlenit (merge) i Johnovu práci (`origin/master`) do své větve `master` a vše odeslat zpět na server. Nejprve se přepne zpět na svou větev `master`, aby do ní mohla vše integrovat:
 
 	$ git checkout master
 	Switched to branch "master"
@@ -255,7 +255,7 @@ Všichni vývojáři zapsali několik revizí a úspěšně začlenili práci os
 Insert 18333fig0510.png
 Obrázek 5-10. Historie Jessicy po odeslání všech změn zpět na server
 
-Toto je jeden z nejjednodušších pracovních postupů. Po určitou dobu pracujete, obvykle na nějaké tematické větvi, a když je připravena k integraci, začleníte ji do hlavní větve. Chcete-li tuto práci sdílet, začleníte ji do své hlavní větve. Poté vyzvednete a začleníte větev `origin/master`, jestliže se změnila. Nakonec odešlete všechna data do větve `master` na serveru. Obecná posloupnost kroků je naznačena na obrázku 5-11.
+Toto je jeden z nejjednodušších pracovních postupů. Po určitou dobu pracujete, obvykle na nějaké tematické větvi, a když je připravena k integraci, začleníte ji do své větve `master`. Chcete-li tuto práci sdílet, začleníte ji do své větve `master`. Poté vyzvednete (fetch) a začleníte (merge) větev `origin/master`, jestliže se změnila. Nakonec odešlete všechna data do větve `master` na serveru. Obecná posloupnost kroků je naznačena na obrázku 5-11.
 
 Insert 18333fig0511.png
 Obrázek 5-11. Obecná posloupnost kroků u jednoduchého pracovního postupu s více vývojáři v systému Git
@@ -532,7 +532,26 @@ Nejprve je třeba nastavit sekci „imap“ v souboru `~/.gitconfig`. Každou ho
 	  sslverify = false
 
 Pokud váš server IMAP nepoužívá SSL, dva poslední řádky zřejmě nebudou vůbec třeba a hodnota hostitele bude `imap://`, a nikoli `imaps://`.
-Až toto nastavení dokončíte, můžete použít příkaz `git send-email`, jímž umístíte sérii patchů do složky Koncepty (Drafts) zadaného serveru IMAP:
+Až toto nastavení dokončíte, můžete použít příkaz `git imap-send`, jímž umístíte sérii záplat (patch) do složky Koncepty (Drafts) zadaného serveru IMAP:
+
+	$ cat *.patch |git imap-send
+	Resolving imap.gmail.com... ok
+	Connecting to [74.125.142.109]:993... ok
+	Logging in...
+	sending 2 messages
+	100% (2/2) done
+
+V tomto okamžiku byste měli být schopni přejít do složky Drafts, změnit pole To na mailing list, do kterého záplatu posíláte, případně pole CC na správce nebo na osobu zodpovědnou za tuto část, a odeslat.
+
+Záplaty můžete odesílat i přes SMTP server. Stejně jako v předchozím případu můžete nastavit sérií příkazů `git config` každou hodnotu zvlášť, nebo je můžete vložit ručně do sekce sendemail souboru `~/.gitconfig`:
+
+	[sendemail]
+	  smtpencryption = tls
+	  smtpserver = smtp.gmail.com
+	  smtpuser = user@gmail.com
+	  smtpserverport = 587
+
+Jakmile je to hotové, můžete záplaty odeslat příkazem `git send-email`:
 
 	$ git send-email *.patch
 	0001-added-limit-to-log-function.patch
@@ -559,8 +578,6 @@ Git poté vytvoří log s určitými informacemi, který bude pro každou zápla
 
 	Result: OK
 
-V tomto okamžiku můžete přejít do své složky Koncepty, změnit pole Komu na adresáty z poštovní konference, jimž chcete záplatu odeslat, případně přidat kopii na správce nebo osobu odpovědnou za tuto část a e-mail odeslat.
-
 ### Shrnutí ###
 
 V této části jsme popsali několik obvyklých pracovních postupů při přispívání do velmi odlišných typů projektů Git, s nimiž se můžete setkat. Představili jsme k nim také nové nástroje, které vám mohou v těchto procesech pomoci. V další části se na projekty podíváme z té druhé strany – ukážeme, jak může vypadat jejich správa. Dozvíte se, jak být benevolentním diktátorem nebo integračním manažerem.
@@ -594,7 +611,7 @@ Pokud dostanete záplatu od někoho, kdo ji vygeneroval příkazem `git diff` ne
 
 Tím změníte soubory ve svém pracovním adresáři. Je to téměř stejné, jako byste k aplikaci záplaty použili příkaz `patch -p1`. Tento postup je však přísnější a nepřijímá tolik přibližných shod jako příkaz patch. Poradí si také s přidanými, odstraněnými a přejmenovanými soubory, jsou-li popsány ve formátu `git diff`, což příkaz `patch` nedělá. A konečně příkaz `git apply` pracuje na principu „aplikuj vše, nebo zruš vše“. Buď jsou tedy aplikovány všechny soubory, nebo žádný. Naproti tomu příkaz `patch` může aplikovat soubory záplaty jen částečně a zanechat váš pracovní adresář v neurčitém stavu. Příkaz `git apply` je tedy celkově víc paranoidní než příkaz `patch`. Tímto příkazem ostatně ani nezapíšete revizi, po jeho spuštění budete muset připravit a zapsat provedené změny ručně.
 
-Příkaz git apply můžete použít také ke kontrole, zda bude záplata aplikována čistě. V takovém případě použijte na patch příkaz `git apply --check`:
+Příkaz `git apply` můžete použít také ke kontrole, zda bude záplata aplikována čistě. V takovém případě použijte na patch příkaz `git apply --check`:
 
 	$ git apply --check 0001-seeing-if-this-helps-the-gem.patch
 	error: patch failed: ticgit.gemspec:1
@@ -615,7 +632,7 @@ K aplikaci patche vygenerovaného příkazem `format-patch` použijte příkaz `
 
 	Limit log functionality to the first 20
 
-Toto je začátek výstupu příkazu format-patch, s nímž jsme se setkali v předchozí části. Zároveň je to také platný e-mailový formát mbox. Jestliže vám přispěvatel řádně poslal záplatu e-mailem pomocí příkazu git send-email a vy záplatu stáhnete do formátu mbox, můžete na soubor mbox použít příkaz git am, který začne aplikovat všechny záplaty, které najde. Jestliže spustíte poštovního klienta, který dokáže uložit několik e-mailů ve formátu mbox, můžete do jednoho souboru uložit celou sérii záplat a příkazem git am je pak aplikovat všechny najednou.
+Toto je začátek výstupu příkazu format-patch, s nímž jsme se setkali v předchozí části. Zároveň je to také platný e-mailový formát mbox. Jestliže vám přispěvatel řádně poslal záplatu e-mailem pomocí příkazu `git send-email` a vy záplatu stáhnete do formátu mbox, můžete na soubor mbox použít příkaz `git am`, který začne aplikovat všechny záplaty, které najde. Jestliže spustíte poštovního klienta, který dokáže uložit několik e-mailů ve formátu mbox, můžete do jednoho souboru uložit celou sérii záplat a příkazem `git am` je pak aplikovat všechny najednou.
 
 Pokud však někdo nahrál soubor záplaty vygenerovaný příkazem `format-patch` do tiketového nebo podobného systému, můžete soubor uložit lokálně a poté na tento uložený soubor použít příkaz `git am`. Tímto způsobem záplatu aplikujete:
 
diff --git a/cs/06-git-tools/01-chapter6.markdown b/cs/06-git-tools/01-chapter6.markdown
index 8b4349abf..987a56217 100644
--- a/cs/06-git-tools/01-chapter6.markdown
+++ b/cs/06-git-tools/01-chapter6.markdown
@@ -82,13 +82,13 @@ Jednou z věcí, které probíhají na pozadí systému Git, zatímco vy pracuje
 Svůj reflog si můžete nechat zobrazit příkazem `git reflog`:
 
 	$ git reflog
-	734713b... HEAD@{0}: commit: fixed refs handling, added gc auto, updated
-	d921970... HEAD@{1}: merge phedders/rdocs: Merge made by recursive.
-	1c002dd... HEAD@{2}: commit: added some blame and merge stuff
-	1c36188... HEAD@{3}: rebase -i (squash): updating HEAD
-	95df984... HEAD@{4}: commit: # This is a combination of two commits.
-	1c36188... HEAD@{5}: rebase -i (squash): updating HEAD
-	7e05da5... HEAD@{6}: rebase -i (pick): updating HEAD
+	734713b HEAD@{0}: commit: fixed refs handling, added gc auto, updated
+	d921970 HEAD@{1}: merge phedders/rdocs: Merge made by recursive.
+	1c002dd HEAD@{2}: commit: added some blame and merge stuff
+	1c36188 HEAD@{3}: rebase -i (squash): updating HEAD
+	95df984 HEAD@{4}: commit: # This is a combination of two commits.
+	1c36188 HEAD@{5}: rebase -i (squash): updating HEAD
+	7e05da5 HEAD@{6}: rebase -i (pick): updating HEAD
 
 Pokaždé, když je z nějakého důvodu aktualizován vrchol větve, Git tuto informaci uloží v dočasné historii reflog. Pomocí těchto dat lze rovněž specifikovat starší revize. Chcete-li zobrazit pátou poslední hodnotu ukazatele HEAD svého repozitáře, použijte referenci `@{n}` z výstupu reflog:
 
@@ -463,8 +463,8 @@ Nyní můžete bez obav přepnout větve a pracovat na jiném úkolu, vaše změ
 
 	$ git stash list
 	stash@{0}: WIP on master: 049d078 added the index file
-	stash@{1}: WIP on master: c264051... Revert "added file_size"
-	stash@{2}: WIP on master: 21d80a5... added number to log
+	stash@{1}: WIP on master: c264051 Revert "added file_size"
+	stash@{2}: WIP on master: 21d80a5 added number to log
 
 V tomto případě byly už dříve provedeny dva další odklady, a máte tak k dispozici tři různé odklady. Naposledy odložené soubory můžete znovu aplikovat příkazem, který byl uveden už v nápovědě ve výstupu původního příkazu stash: `git stash apply`. Chcete-li aplikovat některý ze starších odkladů, můžete ho určit na základě jeho označení, např. `git stash apply stash@{2}`. Pokud u příkazu neoznačíte konkrétní odklad, Git se automaticky pokusí aplikovat ten nejnovější:
 
@@ -498,8 +498,8 @@ Parametr apply se pouze pokusí aplikovat odloženou práci, ta zůstává ulož
 
 	$ git stash list
 	stash@{0}: WIP on master: 049d078 added the index file
-	stash@{1}: WIP on master: c264051... Revert "added file_size"
-	stash@{2}: WIP on master: 21d80a5... added number to log
+	stash@{1}: WIP on master: c264051 Revert "added file_size"
+	stash@{2}: WIP on master: 21d80a5 added number to log
 	$ git stash drop stash@{0}
 	Dropped stash@{0} (364e91f3f268f0900bc3ee613f9f733e82aaed43)
 
@@ -583,12 +583,19 @@ Spuštěním tohoto příkazu otevřete textový editor se seznamem revizí zhru
 	#
 	# Commands:
 	#  p, pick = use commit
+	#  r, reword = use commit, but edit the commit message
 	#  e, edit = use commit, but stop for amending
 	#  s, squash = use commit, but meld into previous commit
+	#  f, fixup = like "squash", but discard this commit's log message
+	#  x, exec = run command (the rest of the line) using shell
+	#
+	# These lines can be re-ordered; they are executed from top to bottom.
 	#
 	# If you remove a line here THAT COMMIT WILL BE LOST.
+	#
 	# However, if you remove everything, the rebase will be aborted.
 	#
+	# Note that empty commits are commented out
 
 Tady bychom chtěli upozornit, že revize jsou uvedeny v opačném pořadí, než jste zvyklí v případě příkazu `log`. Po spuštění příkazu `log` by se zobrazilo následující:
 
@@ -607,6 +614,10 @@ Skript je třeba upravit tak, aby zastavil na revizi, v níž chcete provést zm
 
 Po uložení změn a zavření editoru vás Git vrátí zpět na poslední revizi v seznamu a zobrazí vám příkazový řádek s touto zprávou:
 
+<!-- This is actually weird, as the SHA-1 of 7482e0d is not present in the list,
+nor is the commit message. Please review
+-->
+
 	$ git rebase -i HEAD~3
 	Stopped at 7482e0d... updated the gemspec to hopefully work better
 	You can amend the commit now, with
@@ -649,12 +660,19 @@ Další možností, jak lze využít interaktivního nástroje přeskládání,
 	#
 	# Commands:
 	#  p, pick = use commit
+	#  r, reword = use commit, but edit the commit message
 	#  e, edit = use commit, but stop for amending
 	#  s, squash = use commit, but meld into previous commit
+	#  f, fixup = like "squash", but discard this commit's log message
+	#  x, exec = run command (the rest of the line) using shell
+	#
+	# These lines can be re-ordered; they are executed from top to bottom.
 	#
 	# If you remove a line here THAT COMMIT WILL BE LOST.
+	#
 	# However, if you remove everything, the rebase will be aborted.
 	#
+	# Note that empty commits are commented out
 
 Zadáte-li místo pick nebo edit instrukci pro komprimaci squash, Git aplikuje změnu na tomto řádku a změnu těsně před ní a zároveň sloučí dohromady obě zprávy k revizím. Chcete-li tedy vytvořit jedinou revizi z těchto tří revizí, bude skript vypadat takto:
 
diff --git a/cs/07-customizing-git/01-chapter7.markdown b/cs/07-customizing-git/01-chapter7.markdown
index 5491834de..463bffe5f 100644
--- a/cs/07-customizing-git/01-chapter7.markdown
+++ b/cs/07-customizing-git/01-chapter7.markdown
@@ -130,7 +130,7 @@ Chcete-li sami nastavit jednotlivé barvy, mají všechny tyto parametry navíc
 
 	$ git config --global color.diff.meta "blue black bold"
 
-U barev lze zadávat tyto hodnoty: normal (normální), black (černá), red (červená), green (zelená), yellow (žlutá), blue (modrá), magenta (purpurová), cyan (azurová) nebo white (bílá). Pokud chcete použít atribut, jakým bylo v předchozím příkladu například tučné písmo, můžete vybírat mezi bold (tučné), dim (tlumené), ul (podtržené), blink (blikající) a reverse (obrácené).
+U barev lze zadávat tyto hodnoty: `normal` (normální), `black` (černá), `red` (červená), `green` (zelená), `yellow` (žlutá), `blue` (modrá), `magenta` (purpurová), `cyan` (azurová) nebo `white` (bílá). Pokud chcete použít atribut, jakým bylo v předchozím příkladu například tučné písmo, můžete vybírat mezi `bold` (tučné), `dim` (tlumené), `ul` (podtržené), `blink` (blikající) a `reverse` (obrácené).
 
 Chcete-li použít dílčí nastavení, podrobnější informace naleznete na manuálové stránce `git config`.
 
@@ -301,17 +301,21 @@ Chcete-li systému Git zadat, aby nakládal se všemi soubory `pbxproj` jako s b
 
 	*.pbxproj -crlf -diff
 
-Až v projektu spustíte příkaz git show nebo git diff, Git se nebude pokoušet konvertovat nebo opravovat chyby CRLF ani vypočítat ani zobrazit rozdíly v tomto souboru pomocí nástroje diff. V systému Git verze 1.6 můžete také použít existující makro s významem `-crlf -diff`:
+Až v projektu spustíte příkaz `git show` nebo `git diff`, Git se nebude pokoušet konvertovat nebo opravovat chyby CRLF ani vypočítat ani zobrazit rozdíly v tomto souboru pomocí nástroje diff. Můžete také použít zabudované makro `binary` s významem `-crlf -diff`:
 
 	*.pbxproj binary
 
 #### Nástroj diff pro binární soubory ####
 
-Ve verzi 1.6 systému Git můžete použít funkci atributů Git k efektivnímu zpracování binárních souborů nástrojem diff. Systému Git přitom sdělíte, jak má konvertovat binární data do textového formátu, který lze zpracovávat běžným nástrojem diff.
+V systému Git můžete zadáním vhodných parametrů efektivně porovnávat binární soubory. Dosáhnete toho tím, že systému Git sdělíte, jak má konvertovat binární data do textového formátu, který lze zpracovávat běžným algoritmem pro zjišťování rozdílů (diff). Ale otázkou je, jak byste měli konverzi *binárních* dat na text provést? Nejlepší by bylo, kdybyste našli nějaký nástroj, který vám binární tvar na textový převede. Naneštěstí existuje jen velmi málo binárních formátů, které lze převést na lidsky čitelný text. (Představte si, jak byste na text převáděli zvuková data.) Pokud takový případ nastal a nejste schopni textovou reprezentaci obsahu souboru získat, lze často poměrně snadno získat lidsky čitelný popis obsahu, metadata. Metadata vám sice neposkytnou plnou reprezentaci obsahu souboru, ale v každém případě je to lepší než nic.
+
+Oba popsané přístupy k získání použitelných informací o rozdílech si ukážeme na některých běžně používaných binárních formátech.
+
+Poznámka: Existují různé druhy binárních formátů, které obsahují text, a pro které se dají obtížně najít použitelné konvertory. V takovém případě můžete zkusit získat z vašeho souboru texty programem `strings`. Některé z těchto souborů ale mohou používat kódování UTF-16 nebo jiné kódování a `strings` v nich nic rozumného nenajde. Je to případ od případu. Nicméně program `strings` je k dispozici na většině operačních systémů Mac a Linux, takže může jít o dobrou první volbu při pokusech s celou řadou binárních souborů.
 
 #### Soubory MS Word ####
 
-Protože se jedná o opravdu šikovnou a nepříliš známou funkci, uvedu několik příkladů. Tuto metodu budete využívat především k řešení jednoho z nejpalčivějších problémů, s nímž se lidstvo potýká: verzování dokumentů Word. Je všeobecně známo, že Word je nejpříšejnější editor na světě, přesto ho však – bůhví proč – všichni používají. Chcete-li verzovat dokumenty Word, můžete je uložit do repozitáře Git a všechny hned zapsat do revize. K čemu to však bude? Spustíte-li příkaz `git diff` normálně, zobrazí se zhruba toto:
+Tuto metodu budete využívat především k řešení jednoho z nejpalčivějších problémů, s nímž se lidstvo potýká: verzování dokumentů Word. Je všeobecně známo, že Word je nejpříšernější editor na světě, přesto ho však – bůhví proč – všichni používají. Chcete-li verzovat dokumenty Word, můžete je uložit do repozitáře Git a všechny hned zapsat do revize. K čemu to však bude? Spustíte-li příkaz `git diff` normálně, zobrazí se zhruba toto:
 
 	$ git diff
 	diff --git a/chapter1.doc b/chapter1.doc
@@ -322,16 +326,14 @@ Srovnávat dvě verze přímo nelze, můžete je tak nanejvýš otevřít a ruč
 
 	*.doc diff=word
 
-Systému Git tím sdělíte, že pro všechny soubory, které odpovídají této masce (.doc), by měl být při zobrazení rozdílů použít filter word. Co je to filtr „word“? To budete muset nastavit. V našem případě nastavíme Git tak, aby ke konverzi dokumentů Word do čitelných textových souborů, způsobilých ke zpracování nástrojem diff, používal program `strings`:
+Systému Git tím sdělíte, že pro všechny soubory, které odpovídají této masce (.doc), by měl být při zobrazení rozdílů použít filter „word“. Co je to filtr „word“? To budete muset nastavit. V našem případě nastavíme Git tak, aby ke konverzi dokumentů Word do čitelných textových souborů, způsobilých ke zpracování nástrojem diff, používal program `catdoc`, který byl napsán přímo pro extrakci textu z binární podoby dokumentů MS Word (můžete jej získat z `http://www.wagner.pp.ru/~vitus/software/catdoc/`). Tím wordovské dokumenty převedeme na čitelné textové soubory, na které lze úspěšně aplikovat algoritmus pro zjišťování rozdílů (diff):
 
-	$ git config diff.word.textconv strings
+	$ git config diff.word.textconv catdoc
 
 Tento příkaz do vašeho `.git/config` přidá sekci, která vypadá následovně:
 
 	[diff "word"]
-		textconv = strings
-
-Okrajová poznámka: Existují různé druhy `.doc` souborů. Některé používají kódování UTF-16 nebo jiné kódové stránky a `strings` v nich nic rozumného nenajde. Záleží na okolnostech.
+		textconv = catdoc
 
 Git nyní ví, že až se bude pokoušet vypočítat rozdíl mezi dvěma snímky a jeden ze souborů bude končit na `.doc`, má tyto soubory spustit přes filtr word, který je definován jako program `strings`. Než se Git pokusí porovnat soubory Word nástrojem diff, efektivně vytvoří hezké textové verze souborů.
 
@@ -342,15 +344,14 @@ Uveďme malý příklad. Kapitolu 1 této knihy jsem vložil do systému Git, do
 	index c1c8a0a..b93c9e4 100644
 	--- a/chapter1.doc
 	+++ b/chapter1.doc
-	@@ -8,7 +8,8 @@ re going to cover Version Control Systems (VCS) and Git basics
-	 re going to cover how to get it and set it up for the first time if you don
-	 t already have it on your system.
-	 In Chapter Two we will go over basic Git usage - how to use Git for the 80%
-	-s going on, modify stuff and contribute changes. If the book spontaneously
-	+s going on, modify stuff and contribute changes. If the book spontaneously
-	+Let's see if this works.
+	@@ -128,7 +128,7 @@ and data size)
+	 Since its birth in 2005, Git has evolved and matured to be easy to use
+	 and yet retain these initial qualities. It’s incredibly fast, it’s
+	 very efficient with large projects, and it has an incredible branching
+	-system for non-linear development.
+	+system for non-linear development (See Chapter 3).
 
-Git mi stroze, ale pravdivě sděluje, že jsem přidal řetězec „Let’s see if this works“. Není to sice dokonalé – na konci je přidáno několik náhodných znaků – ale evidentně to funguje. Pokud se vám podaří najít či vytvořit dobře fungující převaděč dokumentů Word na prostý text, bude toto řešení bezpochyby velmi účinné. Program `strings` je však k dispozici ve většině systémů Mac i Linux, a tak možná nejprve vyzkoušejte tento program s různými binárními formáty.
+Git mi stroze, ale pravdivě sděluje, že jsem přidal řetězec „(See Chapter 3)“, což je správné. Funguje to perfektně!
 
 ##### OpenDocument Text files #####
 
@@ -612,14 +613,12 @@ Veškerá práce na straně serveru bude uložena do souboru update v adresáři
 
 	#!/usr/bin/env ruby
 
-	$refname = ARGV[0]
-	$oldrev  = ARGV[1]
-	$newrev  = ARGV[2]
-	$user    = ENV['USER']
-
-	puts "Enforcing Policies... \n(#{$refname}) (#{$oldrev[0,6]}) (#{$newrev[0,6]})"
+	refname = ARGV[0]
+	oldrev  = ARGV[1]
+	newrev  = ARGV[2]
+	user    = ENV['USER']
 
-Ano, je to tak, používám globální proměnné. Ale neodsuzujte mne – náš příklad díky tomu bude názornější.
+	puts "Enforcing Policies... \n(#{refname}) (#{oldrev[0,6]}) (#{newrev[0,6]})"
 
 #### Standardizovaná zpráva k revizi ####
 
diff --git a/cs/08-git-and-other-scms/01-chapter8.markdown b/cs/08-git-and-other-scms/01-chapter8.markdown
index b12839ae7..fc5ecc81d 100644
--- a/cs/08-git-and-other-scms/01-chapter8.markdown
+++ b/cs/08-git-and-other-scms/01-chapter8.markdown
@@ -369,7 +369,7 @@ Vytvoříte tím log ve formátu XML. Můžete v něm vyhledávat autory, vytvo
 
 Tento soubor můžete dát k dispozici nástroji `git svn`, aby mohl přesněji zmapovat informace o autorech. Nástroji `git svn` můžete také zadat, aby ignoroval metadata, která systém Subversion normálně importuje: zadejte parametr `--no-metadata` k příkazu `clone` nebo `init`. Váš příkaz `import` pak bude mít tuto podobu:
 
-	$ git-svn clone http://my-project.googlecode.com/svn/ \
+	$ git svn clone http://my-project.googlecode.com/svn/ \
 	      --authors-file=users.txt --no-metadata -s my_project
 
 Import ze systému Subversion v adresáři `my_project` by měl nyní vypadat o něco lépe. Revize už nebudou mít tuto podobu:

From 3ac88dac986604845087d2eccc41d14ef9c2aca2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Stian=20Dr=C3=B8bak?= <sum41rules4@hotmail.com>
Date: Fri, 1 Aug 2014 22:01:16 +0200
Subject: [PATCH 529/690] no-NB translation Chapter 1#The Three States

---
 no-nb/01-introduction/01-chapter1.markdown | 22 +++++++++++-----------
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/no-nb/01-introduction/01-chapter1.markdown b/no-nb/01-introduction/01-chapter1.markdown
index 1163c12c6..1122a47bb 100644
--- a/no-nb/01-introduction/01-chapter1.markdown
+++ b/no-nb/01-introduction/01-chapter1.markdown
@@ -97,28 +97,28 @@ Når du gjør ting i Git, så vil nesten alle bare legge til data til Git databa
 
 Dette gjør det å bruke Git til en gledelig opplevelse fordi vi vet at vi kan eksperimentere uten fare for å virkelig rote til ting skikkelig. For en mer dypere innsyn i hvoradn Git lagerer data og hvordan du kan få tilbake data som virker tapt, se Kapitel 9.
 
-### The Three States ###
+### De Tre Tilstandene ###
 
-Now, pay attention. This is the main thing to remember about Git if you want the rest of your learning process to go smoothly. Git has three main states that your files can reside in: committed, modified, and staged. Committed means that the data is safely stored in your local database. Modified means that you have changed the file but have not committed it to your database yet. Staged means that you have marked a modified file in its current version to go into your next commit snapshot.
+Følg med. Detter er viktigeste å huske om Git om du ønsker at resten av læringsprossessen din skal gå flytende. Git har tre hoved tilstandet som filene dine kan være i: committed, modified, og staged. Commited betyr at dataen er laget trygt i din lokale database. Mofigied betyr at du har endret på filen men ikke har committed den til databasen enda. Staged betyr at du har markert en modified fil i dens nåværende versjon til å gå inn i ditt neste commit bilde.
 
 This leads us to the three main sections of a Git project: the Git directory, the working directory, and the staging area.
 
 Insert 18333fig0106.png
-Figure 1-6. Working directory, staging area, and git directory.
+Figure 1-6. Arbeidsmappe, staging området, og git mappe.
 
-The Git directory is where Git stores the metadata and object database for your project. This is the most important part of Git, and it is what is copied when you clone a repository from another computer.
+Git mappen er der Git  lagere metadata og objekt databasen for prosjektet ditt. Dette er den mest viktige delen av Git, og det er det som er kopier når du kloner et repository fra en annen maskin.
 
-The working directory is a single checkout of one version of the project. These files are pulled out of the compressed database in the Git directory and placed on disk for you to use or modify.
+Arbeidsmappen er en enkel checkout av en versjon av prosjektet. Disse filene er dratt ut av den komprimerte databasen i Git mappen og plassert på disken slik at du kan bruke eller modifisere det.
 
-The staging area is a simple file, generally contained in your Git directory, that stores information about what will go into your next commit. It’s sometimes referred to as the index, but it’s becoming standard to refer to it as the staging area.
+Staging området er en enkelt fil, generelt holdt i Git mappen din, som lagrer informasjon om hva som vil gå inn i din neste commit. Det er noen ganger referert til som indeksen, men det begynner å bli det vanlige å kalle det staging området.
 
-The basic Git workflow goes something like this:
+Den grunnleggende Git arbeidsmåten er litt som dette:
 
-1. You modify files in your working directory.
-2. You stage the files, adding snapshots of them to your staging area.
-3. You do a commit, which takes the files as they are in the staging area and stores that snapshot permanently to your Git directory.
+1. Du modifiserer filer i arbeidmappa.
+2. Du stage-er filene, og lager bilder av den til staging området.
+3. Du gjør en commit, som tar filene som de er i staging området og lagrer det bildet permanent i Git mappen din.
 
-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.
+Hvis en bestemt versjon av en fil er i git mappen, så er den ansett som comitted. Hvis den er modifisert men har blitt lagt til i staging området, så der den staged. Og hvis den var endret siden den var sjekket ut men ikke blitt staged, så er den modifisert. I Kapitel 2 så vil du lære om disse tilstande og hvordan du kan utnytte deg av dem eller hoppe over staged-delen helt.
 
 ## Installing Git ##
 

From fd86b63d6cc990817867b50033b67b41d66c5a4b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Stian=20Dr=C3=B8bak?= <sum41rules4@hotmail.com>
Date: Fri, 1 Aug 2014 22:12:25 +0200
Subject: [PATCH 530/690] no-NB translation Chapter 1#Installing Git

and Install Git through souce code
---
 no-nb/01-introduction/01-chapter1.markdown | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/no-nb/01-introduction/01-chapter1.markdown b/no-nb/01-introduction/01-chapter1.markdown
index 1122a47bb..9f472c44a 100644
--- a/no-nb/01-introduction/01-chapter1.markdown
+++ b/no-nb/01-introduction/01-chapter1.markdown
@@ -120,15 +120,15 @@ Den grunnleggende Git arbeidsmåten er litt som dette:
 
 Hvis en bestemt versjon av en fil er i git mappen, så er den ansett som comitted. Hvis den er modifisert men har blitt lagt til i staging området, så der den staged. Og hvis den var endret siden den var sjekket ut men ikke blitt staged, så er den modifisert. I Kapitel 2 så vil du lære om disse tilstande og hvordan du kan utnytte deg av dem eller hoppe over staged-delen helt.
 
-## Installing Git ##
+## Installer Git ##
 
-Let’s get into using some Git. First things first—you have to install it. You can get it a number of ways; the two major ones are to install it from source or to install an existing package for your platform.
+La oss gå inn for å bruke litt Git. Det første du trenger gjøre er å installere det. Du kan gjøre det på flere måter; de to vanlige er å installere det fra kildekode eller å installere en allerede eksisterende pakke for din platform.
 
-### Installing from Source ###
+### Installere fra Kildekode ###
 
-If you can, it’s generally useful to install Git from source, because you’ll get the most recent version. Each version of Git tends to include useful UI enhancements, so getting the latest version is often the best route if you feel comfortable compiling software from source. It is also the case that many Linux distributions contain very old packages; so unless you’re on a very up-to-date distro or are using backports, installing from source may be the best bet.
+Hvis du kan, så er det generelt sett nyttig å installere Git fra kildekode, ettersom du vil få nyeste versjon. Hver versjon av Git pleier å inkludere nyttige grensensitt forbedringer, så å skaffe seg den nyeste versjonen er ofte den beste måten, dersom du føler deg komfortable med å kompilere programvare fra kildekode. Det er er også tilfellet at mange Linux distrobusjoner har veldig gamle pakker; så med mindre du er på en veldig up-to-date distro eller bruker backports, så er det å installere fra kildekode den beste løsningen.
 
-To install Git, you need to have the following libraries that Git depends on: curl, zlib, openssl, expat, and libiconv. For example, if you’re on a system that has yum (such as Fedora) or apt-get (such as a Debian based system), you can use one of these commands to install all of the dependencies:
+For å installere git så trenger du følgene biblioteker som Git er avhengige av: curl, zlib, openssl, expat, and libiconv. For eksempel, om du er på et system som har yum (som Fedora) eller apt-get (som Debian baserte systemer), så kan du bruke en av disse kommandoene for å installere alle avhengighetene:
 
 	$ yum install curl-devel expat-devel gettext-devel \
 	  openssl-devel zlib-devel
@@ -136,18 +136,18 @@ To install Git, you need to have the following libraries that Git depends on: cu
 	$ apt-get install libcurl4-gnutls-dev libexpat1-dev gettext \
 	  libz-dev libssl-dev
 
-When you have all the necessary dependencies, you can go ahead and grab the latest snapshot from the Git web site:
+Når du har alle de nødvendige avhengighetene, så kan du gå å laste det nyeste bildet fra Git nettsiden:
 
 	http://git-scm.com/download
 
-Then, compile and install:
+Og så, kompiler og installer:
 
 	$ tar -zxf git-1.7.2.2.tar.gz
 	$ cd git-1.7.2.2
 	$ make prefix=/usr/local all
 	$ sudo make prefix=/usr/local install
 
-After this is done, you can also get Git via Git itself for updates:
+Etter alt dette er gjort, så kan du også få Git gjennom Git for oppdateringer.
 
 	$ git clone git://git.kernel.org/pub/scm/git/git.git
 

From cef6c2b8679930b20eb882231beb0123c4af13d7 Mon Sep 17 00:00:00 2001
From: Petr Prikryl <prikryl@atlas.cz>
Date: Fri, 1 Aug 2014 23:47:00 +0200
Subject: [PATCH 531/690] [cs] synchronization with latest [en] finished...

- examples (code snippets) fully synchronized
- text sychronization based only on structure and recognized markup
- newly found (missing in cs) translated
---
 cs/07-customizing-git/01-chapter7.markdown    | 10 +++++-----
 cs/08-git-and-other-scms/01-chapter8.markdown | 14 +++++++-------
 cs/09-git-internals/01-chapter9.markdown      |  2 +-
 3 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/cs/07-customizing-git/01-chapter7.markdown b/cs/07-customizing-git/01-chapter7.markdown
index 463bffe5f..0e587fe57 100644
--- a/cs/07-customizing-git/01-chapter7.markdown
+++ b/cs/07-customizing-git/01-chapter7.markdown
@@ -335,7 +335,7 @@ Tento příkaz do vašeho `.git/config` přidá sekci, která vypadá následovn
 	[diff "word"]
 		textconv = catdoc
 
-Git nyní ví, že až se bude pokoušet vypočítat rozdíl mezi dvěma snímky a jeden ze souborů bude končit na `.doc`, má tyto soubory spustit přes filtr word, který je definován jako program `strings`. Než se Git pokusí porovnat soubory Word nástrojem diff, efektivně vytvoří hezké textové verze souborů.
+Git nyní ví, že až se bude pokoušet vypočítat rozdíl mezi dvěma snímky a každý ze souborů končící na `.doc` se má prohnat přes filtr „word“, který je definován jako program `catdoc`. Než se Git pokusí zjistit ve wordovských souborech rozdíly, dojde k jejich převedení na hezké textové verze.
 
 Uveďme malý příklad. Kapitolu 1 této knihy jsem vložil do systému Git, do jednoho odstavce jsem přidal kousek textu a dokument jsem uložil. Poté jsem spustil příkaz `git diff`, abych se podíval, co se změnilo:
 
@@ -355,7 +355,7 @@ Git mi stroze, ale pravdivě sděluje, že jsem přidal řetězec „(See Chapte
 
 ##### OpenDocument Text files #####
 
-Stejný postup, který jsme použili pro soubory MS Word (`*.doc`), můžeme použít i pro soubory ve formátu OpenDocument Text (`*.odt`), kter vytváří OpenOffice.org.
+Stejný postup, který jsme použili pro soubory MS Word (`*.doc`), můžeme použít i pro soubory ve formátu OpenDocument Text (`*.odt`), které vytváří OpenOffice.org.
 
 Do souboru `.gitattributes` přidejte následující řádek:
 
@@ -460,7 +460,7 @@ Obrázek 7-2. Filtr smudge spuštěný při checkoutu – git checkout
 Insert 18333fig0703.png
 Obrázek 7-3. Filtr clean spuštěný při přípravě souborů k zapsání – git add
 
-Původní zpráva k revizi s touto funkcí uvádí jednoduchý příklad, jak můžete před zapsáním prohnat veškeré vaše céčkové zdrojové texty programem `indent`. Tuto možnost lze aplikovat nastavením atributu `filter` v souboru `.gitattributes` tak, aby přefiltroval soubory `*.c` filtrem pro úpravu odsazování:
+Původní zpráva k revizi s touto funkcí uvádí jednoduchý příklad, jak můžete před zapsáním prohnat veškeré vaše céčkové zdrojové texty programem `indent`. V souboru `.gitattributes` můžeme nastavit atribut `filter` tak, aby se soubory `*.c` zpracovaly filtrem `indent`:
 
 	*.c     filter=indent
 
@@ -511,7 +511,7 @@ Systému Git můžete zadat, aby při generování archivu neexportoval určité
 
 	test/ export-ignore
 
-Až nyní spustíte příkaz git archive k vytvoření tarballu projektu, nebude tento adresář součástí archivu.
+Až nyní spustíte příkaz `git archive` k vytvoření tarballu projektu, nebude tento adresář součástí archivu.
 
 #### export-subst ####
 
@@ -601,7 +601,7 @@ Zásuvný modul `post-receive` se spouští až poté, co je celý proces dokon
 
 Skript update je velice podobný skriptu `pre-receive`, avšak s tím rozdílem, že se spouští zvlášť pro každou větev, kterou chce odesílatel aktualizovat. Pokud se uživatel pokouší odeslat revize do více větví, skript `pre-receive` se spustí pouze jednou, zatímco update se spustí jednou pro každou větev, již se odesílatel pokouší aktualizovat. Tento skript nenačítá data ze standardního vstupu, místo nich používá tři jiné parametry: název reference (větve), hodnotu SHA-1, na niž reference ukazovala před odesláním, a hodnotu SHA-1, kterou se uživatel pokouší odeslat. Je-li výstup skriptu update nenulový, je zamítnuta pouze tato reference, ostatní mohou být aktualizovány.
 
-## Příklad standardů kontrolovaných systémem Git ##
+## Příklad vynucení chování systémem Git ##
 
 V této části použijeme to, co jsme se naučili o vytváření pracovního postupu v systému Git. Systém může kontrolovat formát uživatelovy zprávy k revizi, dovolit pouze aktualizace „rychle vpřed“ a umožňovat změnu obsahu konkrétních podadresářů projektu pouze vybraným uživatelům. V této části vytvoříte skripty pro klienta, které vývojářům pomohou zjistit, zda budou jejich revize odmítnuty, a skripty na server, které si specifikované požadavky přímo vynutí.
 
diff --git a/cs/08-git-and-other-scms/01-chapter8.markdown b/cs/08-git-and-other-scms/01-chapter8.markdown
index fc5ecc81d..01dc32810 100644
--- a/cs/08-git-and-other-scms/01-chapter8.markdown
+++ b/cs/08-git-and-other-scms/01-chapter8.markdown
@@ -87,7 +87,7 @@ V tomto okamžiku byste tedy měli mít platný repozitář Git s importovanými
 	  tags/release-2.0.2rc1
 	  trunk
 
-Doplňme také, že tento nástroj odlišně přiřazuje jmenný prostor vzdálených referencí. Jestliže klonujete normální repozitář Git, získáte ze vzdáleného serveru všechny větve, lokálně dostupné pod označením `origin/[větev]` – jmenný prostor se přiřazuje na základě vzdáleného serveru. `git svn` však předpokládá, že nebudete mít více vzdálených repozitářů a všechny reference uloží na místa na vzdáleném serveru bez jmenného prostoru. Pokud si přejete zobrazit všechny své reference s úplným názvem, můžete použít nízkoúrovňový příkaz `show-ref`:
+Doplňme také, že tento nástroj odlišně přiřazuje jmenný prostor vzdálených referencí. Jestliže klonujete normální repozitář Git, získáte ze vzdáleného serveru všechny větve, lokálně dostupné pod označením `origin/[větev]` – jmenný prostor je dán jménem vzdáleného serveru. Příkaz `git svn` však předpokládá, že nebudete mít více vzdálených repozitářů a všechny odkazy na místa na vzdáleném serveru uloží bez použití jmenného prostoru. Pokud si přejete zobrazit všechny své reference s úplným názvem, můžete použít nízkoúrovňový příkaz `show-ref`:
 
 	$ git show-ref
 	1cbd4904d9982f386d87f88fce1c24ad7c0f0471 refs/heads/master
@@ -202,7 +202,7 @@ Spustíte-li čas od času příkaz `git svn rebase`, budete mít jistotu, že p
 
 ### Problémy s větvemi systému Git ###
 
-Pokud vám vyhovuje způsob práce v systému Git, začnete pravděpodobně vytvářet tematické větve, budete v nich vytvářet svou práci a začleňovat je. Odesíláte-li revize na server Subversion nástrojem git svn, budete možná chtít pokaždé raději přeskládat svou práci na jedinou větev, místo abyste je slučovali. Důvod, proč raději využít možnosti přeskládání, spočívá v tom, že Subversion má lineární historii a neprovádí začleňování stejně jako Git. Nástroj git svn tak při konverzi snímků na revize Subversion sleduje pouze prvního rodiče.
+Jakmile pracovní postupy v systému Git zvládnete, začnete pravděpodobně vytvářet tematické větve, budete v nich pracovat a potom je budete začleňovat (merge). Pokud odesíláte revizi na server Subversion nástrojem `git svn`, budete možná místo slučování chtít svou práci pokaždé přeskládat (rebase) na jedinou větev. Důvod, proč raději využít možnosti přeskládání, spočívá v tom, že Subversion uchovává lineární historii a neprovádí začleňování stejně jako Git. Takže `git svn` při konverzi snímků na revize Subversion sleduje pouze prvního rodiče.
 
 Předpokládejme, že vaše historie vypadá následovně: vytvořili jste větev `experiment`, zapsali jste dvě revize a začlenili jste je zpět do větve `master`. Výstup příkazu `dcommit` bude nyní vypadat následovně:
 
@@ -231,7 +231,7 @@ Pokud tuto práci naklonuje jiný uživatel, uvidí jen jednu revizi vzniklou sl
 
 ### Větve v systému Subversion ###
 
-Princip větvení v systému Subversion se odlišuje od větvení v systému Git. Pokud se mu můžete úplně vyhnout, mohu vám to vřele doporučit. Pokud se mu vyhnout nelze, můžete i tady použít nástroj git svn, pomocí nějž lze vytvářet nové větve a zapisovat do nich revize.
+Princip větvení v systému Subversion se odlišuje od větvení v systému Git. Pravděpodobně nejlepší bude, když se mu pokusíte co nejvíc vyhýbat. Nicméně příkaz `git svn` vytváření větví a zapisování revizí do systému Subversion umožňuje.
 
 #### Vytvoření nové větve SVN ####
 
@@ -288,7 +288,7 @@ O příkazu `git svn log` byste měli vědět dvě důležité věci. Zaprvé to
 
 #### Anotace SVN ####
 
-Tak jako příkaz `git svn log` simuluje offline příkaz `svn log`, ekvivalentem příkazu `svn annotate` je `git svn blame [SOUBOR]`. Jeho výstup vypadá takto:
+Tak jako příkaz `git svn log` simuluje příkaz `svn log` (bez nutnosti připojení), ekvivalentem příkazu `svn annotate` je provedení `git svn blame [SOUBOR]`. Jeho výstup vypadá takto:
 
 	$ git svn blame README.txt
 	 2   temporal Protocol Buffers - Google's data interchange format
@@ -392,7 +392,7 @@ they look like this:
 
 Nejenže teď pole Author vypadá podstatně lépe, ale navíc jste se zbavili i záznamu `git-svn-id`.
 
-Po importu bude nutné data trochu vyčistit. Zaprvé je nutné vyčistit nejasné reference, které vytvořil příkaz `git svn`. Nejprve přesunete značky tak, aby se z nich staly skutečné značky, a ne podivné vzdálené větve. V dalším kroku přesunete zbytek větví a uděláte z nich větve lokální.
+Po importu bude nutné data trochu vyčistit. Zaprvé je nutné vyčistit podivné reference, které vytvořil příkaz `git svn`. Nejprve přesuňte značky tak, aby se z nich staly skutečné značky, a ne podivné vzdálené větve. V dalším kroku přesunete zbytek větví a uděláte z nich větve lokální.
 
 Abyste značky upravili na korektní gitové značky, spusťte
 
@@ -499,7 +499,7 @@ Jako rychlou ukázku napíšeme jednoduchý importér. Řekněme, že pracujete
 
 Chcete-li importovat adresář Git, budeme se muset podívat na to, jak Git ukládá svá data. Jak si možná vzpomínáte, říkali jsme, že Git je v podstatě seznam odkazů na objekty revizí, které ukazují na určitý snímek obsahu. Jediné, co tedy musíte udělat, je sdělit příkazu `fast-import`, co je obsahem snímků, jaká data revizí na ně ukazují a pořadí, v němž budou převzaty. Vaše strategie tedy bude spočívat v tom, že postupně projdete jednotlivé snímky a vytvoříte revize s obsahem každého adresáře, přičemž každá revize bude odkazovat na revizi předchozí.
 
-Stejně jako v části „Příklad systémem Git kontrolovaných standardů“ v kapitole 7 použijeme i tentokrát Ruby, s nímž většinou pracuji a který je srozumitelný. Tento příklad můžete ale beze všeho napsat v čemkoli, co vám vyhovuje. Jedinou podmínkou je, aby byly potřebné informace zapsány do výstupu stdout.
+Stejně jako v podkapitole „Příklad vynucení chování systémem Git“ v kapitole 7 použijeme i tentokrát Ruby, s nímž většinou pracuji a který je srozumitelný. Tento příklad můžete ale beze všeho napsat v čemkoli, co vám vyhovuje. Jedinou podmínkou je, aby byly potřebné informace zapsány na standardní výstup (stdout). A to v případě používání Windows znamená, že budete muset věnovat zvláštní pozornost tomu, abyste na koncích řádků nevkládali znaky CR (carriage return). Příkaz `git fast-import` je v tomto směru velmi vybíravý a chce jen znaky LF (line feed) a nikoliv kombinaci CRLF, kterou používají Windows.
 
 Na začátku přejdete do cílového adresáře a identifikujete všechny podadresáře, z nichž bude každý představovat jeden snímek, který chcete importovat jako revizi. Přejdete do každého podadresáře a zadáte příkazy potřebné k jeho exportu. Základní smyčka bude mít tuto podobu:
 
@@ -601,7 +601,7 @@ Poslední věcí, kterou musíte udělat, je vrátit aktuální označovač, aby
 
 	return mark
 
-Poznámka: Pokud používáte Windows, budete muset provést jeden krok navíc. Jak už jsem se zmínil, Windows používají nahrazují znak konce řádku posloupností CRLF, zatímco git fast-import očekává pouze LF. Abychom tento problém obešli a aby si git fast-import nestěžoval, musíte ruby říct, aby místo LF používal CRLF:
+Poznámka: Pokud používáte Windows, budete muset provést jeden krok navíc. Jak už jsem se zmínil, Windows nahrazují znak konce řádku posloupností CRLF, zatímco `git fast-import` očekává pouze LF. Abychom tento problém obešli a přitom učinili příkaz `git fast-import` šťastným, musíte ruby říct, aby místo LF používal CRLF:
 
 	$stdout.binmode
 
diff --git a/cs/09-git-internals/01-chapter9.markdown b/cs/09-git-internals/01-chapter9.markdown
index 83c7505fd..3fe65175e 100644
--- a/cs/09-git-internals/01-chapter9.markdown
+++ b/cs/09-git-internals/01-chapter9.markdown
@@ -27,7 +27,7 @@ Spustíte-li v novém nebo existujícím adresáři příkaz `git init`, Git vyt
 	objects/
 	refs/
 
-Možná ve svém adresáři najdete i další soubory. Toto je však příkazem `git init` čerstvě vytvořený repozitář s výchozím obsahem. Adresář `branches` se už v novějších verzích systému Git nepoužívá a soubor `description` používá pouze program GitWeb, o tyto dvě položky se tedy nemusíte starat. Soubor `config` obsahuje jednotlivá nastavení pro konfiguraci vašeho projektu a v adresáři `info` je uchováván globální soubor .gitignore s maskami ignorovaných souborů a adresářů, které si nepřejete sledovat. Adresář `hooks` obsahuje skripty zásuvných modulů na straně klienta nebo serveru, které jsme podrobně popisovali v kapitole 6.
+Možná ve svém adresáři najdete i další soubory. Toto je však příkazem `git init` čerstvě vytvořený repozitář s výchozím obsahem. Adresář `branches` se už v novějších verzích systému Git nepoužívá a soubor `description` používá pouze program GitWeb, takže o tyto dvě položky se nemusíte starat. Soubor `config` obsahuje konfigurační nastavení vašeho projektu a v adresáři `info` je uložen globální soubor `exclude` s maskami ignorovaných souborů a adresářů, které nechcete explicitně ignorovat prostřednictvím souboru `.gitignore`. Adresář `hooks` obsahuje skripty zásuvných modulů na straně klienta nebo serveru, které jsme podrobně popisovali v kapitole 7.
 
 Zbývají čtyři důležité položky: soubory `HEAD` a `index` a adresáře `objects` a `refs`. To jsou ústřední součásti adresáře Git. V adresáři `objects` je uložen celý obsah vaší databáze, v adresáři `refs` jsou uloženy ukazatele na objekty revizí v datech (větve). Soubor `HEAD` ukazuje na větev, na níž se právě nacházíte, a soubor `index` je pro systém Git úložištěm informací o oblasti připravených změn. Na každou z těchto částí se teď podíváme podrobněji, abyste pochopili, jak Git pracuje.
 

From cd82197d67d500e0edf2dd7aba05f3deb929f03f Mon Sep 17 00:00:00 2001
From: Petr Prikryl <prikryl@atlas.cz>
Date: Sat, 2 Aug 2014 20:06:57 +0200
Subject: [PATCH 532/690] [cs] ch.1 -- translation revision/comparison with new
 [en] finished

---
 cs/01-introduction/01-chapter1.markdown | 34 ++++++++++++-------------
 1 file changed, 17 insertions(+), 17 deletions(-)

diff --git a/cs/01-introduction/01-chapter1.markdown b/cs/01-introduction/01-chapter1.markdown
index 007fa3a9b..88b767131 100644
--- a/cs/01-introduction/01-chapter1.markdown
+++ b/cs/01-introduction/01-chapter1.markdown
@@ -190,38 +190,38 @@ Nyní, když máte Git nainstalovaný, můžete provést některá uživatelská
 
 Nastavení konfiguračních proměnných systému, které ovlivňují jak vzhled systému Git, tak ostatní aspekty jeho práce, umožňuje příkaz `git config`. Tyto proměnné mohou být uloženy na třech různých místech:
 
-*	Soubor `/etc/gitconfig` obsahuje údaje o všech uživatelích systému a jejich repozitářích. Pokud příkazu `git config` zadáme parametr `--system` bude číst a zapisovat jen do tohoto souboru.
+*	Soubor `/etc/gitconfig` obsahuje údaje pro všechny uživatele systému a pro všechny jejich repozitáře. Pokud příkazu `git config` zadáme parametr `--system` bude číst a zapisovat jen do tohoto souboru.
 *	Soubor `~/.gitconfig` je vázán na uživatelský účet. Čtení a zápis do tohoto souboru zajistíte zadáním parametru `--global`.
-*	Konfigurační soubor v adresáři Git (tedy `.git/config`) jakéhokoliv užívaného repozitáře přísluší tomuto konkrétnímu repozitáři. Každá úroveň je nadřazená hodnotám úrovně předchozí, takže hodnoty  v `.git/config` přebíjejí hodnotami v `/etc/gitconfig`.
+*	Konfigurační soubor v adresáři Git (tedy `.git/config`) jakéhokoliv užívaného repozitáře přísluší tomuto konkrétnímu repozitáři. Každá úroveň je nadřazená hodnotám úrovně předchozí, takže hodnoty v `.git/config` převládnou nad hodnotami v `/etc/gitconfig`.
 
-Ve Windows používá Git soubor `.gitconfig`, který je umístěný v adresáři `$HOME` (v prostředí Windows je to `%USERPROFILE%`), což je u většiny uživatelů `C:\Documents and Settings\$USER` nebo `C:\Users\$USER` (kde `$USER` se v prostředí Windows označuje `%USERNAME%`). I ve Windows se hledá soubor `/etc/gitconfig`, který je ale umístěn relativně v kořeni Msys, tedy vůči místu, do kterého jste se po spuštění instalačního programu rozhodli Git nainstalovat.
+Ve Windows Git hledá soubor `.gitconfig` v adresáři `$HOME` (v proměnných prostředí Windows je to `%USERPROFILE%`), což je u většiny uživatelů `C:\Documents and Settings\$USER` nebo `C:\Users\$USER` (`$USER` se ve Windows zapisuje odkazem na proměnnou prostředí `%USERNAME%`). I ve Windows se hledá soubor `/etc/gitconfig`, který je ale umístěn relativně v kořeni MSys, tedy vůči místu, do kterého jste se po spuštění instalačního programu rozhodli Git nainstalovat.
 
-### Totožnost uživatele ###
+### Vaše totožnost ###
 
-První věcí, kterou byste měli po nainstalování systému Git udělat, je nastavení uživatelského jména (user name) a e-mailové adresy. Tyto údaje se totiž později využívají při všech revizích v systému Git a jsou nezměnitelnou složkou každé revize, kterou zapíšete:
+První věcí, kterou byste měli po nainstalování systému Git udělat, je nastavení vašeho uživatelského jména (user name) a e-mailové adresy. Je to důležité, protože tuto informaci Git používá pro každý zápis revize a uvedené údaje stanou trvalou složkou záznamů o revizi, které budou putovat po okolí:
 
 	$ git config --global user.name "John Doe"
 	$ git config --global user.email johndoe@example.com
 
-Použijete-li parametr `--global`, pak také toto nastavení stačí provést pouze jednou. Git bude používat tyto údaje pro všechny operace, které v systému uděláte. Pokud chcete pro konkrétní projekty změnit uživatelské jméno nebo e-mailovou adresu, můžete příkaz spustit bez parametru `--global`. V takovém případě je nutné, abyste se nacházeli v adresáři daného projektu.
+Použijete-li parametr `--global`, pak také toto nastavení stačí provést pouze jednou. Git bude používat tyto údaje pro všechny operace, které v systému uděláte. Pokud chcete pro konkrétní projekt uživatelské jméno nebo e-mailovou adresu změnit (přebít), můžete příkaz spustit bez parametru `--global`. V takovém případě je nutné, abyste se nacházeli v adresáři daného projektu.
 
-### Nastavení editoru ###
+### Váš editor ###
 
-Nyní, když jste zadali své osobní údaje, můžete nastavit výchozí textový editor, který bude Git využívat pro psaní zpráv. Pokud toto nastavení nezměníte, bude Git používat výchozí editor vašeho systému, jímž je většinou Vi nebo Vim. Chcete-li používat jiný textový editor (např. Emacs), můžete použít následující příkaz:
+Nyní, když jste zadali své osobní údaje, můžete nastavit výchozí textový editor, který se použije, když po vás Git bude chtít napsat nějakou zprávu. Pokud toto nastavení nezměníte, bude Git používat výchozí editor vašeho systému, jímž je většinou Vi nebo Vim. Chcete-li používat jiný textový editor, například Emacs, můžete použít následující příkaz:
 
 	$ git config --global core.editor emacs
 
-### Nastavení nástroje diff ###
+### Váš nástroj diff ###
 
-Další proměnnou, jejíž nastavení můžete považovat za užitečné, je výchozí nástroj diff, jenž bude Git používat k řešení konfliktů při slučování. Řekněme, že jste se rozhodli používat vimdiff:
+Další užitečnou volbou, jejíž nastavení můžete chtít upravit, je výchozí nástroj pro zjišťování rozdílů (diff), který Git používá k řešení konfliktů při slučování (merge). Řekněme, že jste se rozhodli používat vimdiff:
 
 	$ git config --global merge.tool vimdiff
 
 Jako platné nástroje slučování Git akceptuje: kdiff3, tkdiff, meld, xxdiff, emerge, vimdiff, gvimdiff, ecmerge a opendiff. Nastavit můžete ale i jiné uživatelské nástroje — více informací o této možnosti naleznete v kapitole 7.
 
-### Kontrola provedeného nastavení ###
+### Kontrola va3eho nastavení ###
 
-Chcete-li zkontrolovat provedené nastavení, použijte příkaz `git config --list`. Git vypíše všechna aktuálně dostupná nastavení:
+Chcete-li zkontrolovat vaše nastavení, použijte příkaz `git config --list`. Git vypíše všechna aktuálně dostupná nastavení:
 
 	$ git config --list
 	user.name=Scott Chacon
@@ -232,14 +232,14 @@ Chcete-li zkontrolovat provedené nastavení, použijte příkaz `git config --l
 	color.diff=auto
 	...
 
-Některé klíče se mohou objevit vícekrát, protože Git načítá stejný klíč z různých souborů (např. `/etc/gitconfig` a `~/.gitconfig`). V takovém případě použije Git poslední hodnotu pro každý unikátní klíč, který vidí.
+Některé klíče se mohou objevit vícekrát, protože Git načítá stejný klíč z různých souborů (například `/etc/gitconfig` a `~/.gitconfig`). V takovém případě použije Git poslední hodnotu pro každý unikátní klíč, který vidí.
 
-Můžete také zkontrolovat, jakou hodnotu Git uchovává pro konkrétní položku. Zadejte příkaz `git config {key}`:
+Můžete také zkontrolovat, jakou hodnotu Git uchovává pro konkrétní klíč zadáním `git config {klíč}`:
 
 	$ git config user.name
 	Scott Chacon
 
-## Kde hledat pomoc ##
+## Získání nápovědy ##
 
 Budete-li někdy při používání systému Git potřebovat pomoc, existují tři způsoby, jak vyvolat nápovědu z manuálové stránky (manpage) pro jakýkoli z příkazů systému Git:
 
@@ -247,12 +247,12 @@ Budete-li někdy při používání systému Git potřebovat pomoc, existují t
 	$ git <příkaz> --help
 	$ man git-<příkaz>
 
-Například manpage nápovědu pro příkaz config vyvoláte zadáním:
+Například manpage nápovědu pro příkaz `config` vyvoláte zadáním:
 
 	$ git help config
 
 Tyto příkazy jsou užitečné, neboť je můžete spustit kdykoli, dokonce i offline.
-Pokud nenajdete pomoc na manuálové stránce ani v této knize a uvítali byste osobní pomoc, můžete zkusit kanál `#git` nebo `#github` na serveru Freenode IRC (irc.freenode.net). Na těchto kanálech se většinou pohybují stovky lidí, kteří mají se systémem Git bohaté zkušenosti a často ochotně pomohou.
+Pokud nestačí ani manuálová stránka ani tato kniha a uvítali byste osobní pomoc, můžete zkusit kanál `#git` nebo `#github` na serveru Freenode IRC (irc.freenode.net). Na těchto kanálech se většinou pohybují stovky lidí, kteří mají se systémem Git bohaté zkušenosti a často ochotně pomohou.
 
 ## Shrnutí ##
 

From a0bdb27526da078c50edcfaf37ccb341f3a5b4e9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Stian=20Dr=C3=B8bak?= <sum41rules4@hotmail.com>
Date: Sat, 2 Aug 2014 22:39:04 +0200
Subject: [PATCH 533/690] no-NB translation Chapter 1 installation done.

---
 no-nb/01-introduction/01-chapter1.markdown | 24 +++++++++++-----------
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/no-nb/01-introduction/01-chapter1.markdown b/no-nb/01-introduction/01-chapter1.markdown
index 9f472c44a..9c73eab43 100644
--- a/no-nb/01-introduction/01-chapter1.markdown
+++ b/no-nb/01-introduction/01-chapter1.markdown
@@ -151,40 +151,40 @@ Etter alt dette er gjort, så kan du også få Git gjennom Git for oppdateringer
 
 	$ git clone git://git.kernel.org/pub/scm/git/git.git
 
-### Installing on Linux ###
+### Installer på Linux ###
 
-If you want to install Git on Linux via a binary installer, you can generally do so through the basic package-management tool that comes with your distribution. If you’re on Fedora, you can use yum:
+Hvis du vil installere Git på Linux via en binær installasjonspakke, så kan du generelt få gjort det gjennom det vanlige pakkebehandlerverktøyet som kommer med distroen din. Hiv du er på Fedora, så kan du bruke yum:
 
 	$ yum install git-core
 
-Or if you’re on a Debian-based distribution like Ubuntu, try apt-get:
+Eller om du bruker en Debian-basert distro som Ubuntu, prøv apt-get:
 
 	$ apt-get install git
 
-### Installing on Mac ###
+### Installer på Mac ###
 
-There are two easy ways to install Git on a Mac. The easiest is to use the graphical Git installer, which you can download from the SourceForge page (see Figure 1-7):
+Det er to enkle måter å installere Git på en Mac. Den enkleste er å bruke den grafiske Git installasjonspakken, som du kan laste ned fra SourceForge siden (se Figur 1-7):
 
 	http://sourceforge.net/projects/git-osx-installer/
 
 Insert 18333fig0107.png
-Figure 1-7. Git OS X installer.
+Figure 1-7. Git OS X innstallasjon.
 
-The other major way is to install Git via MacPorts (`http://www.macports.org`). If you have MacPorts installed, install Git via
+Den andre vanlige måten å gjære det på er å installere Git via MacPorts ('http://macports.org'). Hvis du har MacPorts installert, installer Git med
 
 	$ sudo port install git-core +svn +doc +bash_completion +gitweb
 
-You don’t have to add all the extras, but you’ll probably want to include +svn in case you ever have to use Git with Subversion repositories (see Chapter 8).
+Du trenger ikke alt det ekstra, men du vil sannynligvis ønske å inkludere +svn sånn i fall du trenger å bruke git med Subversion repositorier (se Kapitel 8).
 
-### Installing on Windows ###
+### Installer på Windows ###
 
-Installing Git on Windows is very easy. The msysGit project has one of the easier installation procedures. Simply download the installer exe file from the GitHub page, and run it:
+Å installere Git på Windows er veldig enkelt. msysGit prosjektet har en av de enkleste installasjonprossedyrene. Bare last ned installasjons exe filen fra GitHub siden, og kjær den:
 
 	http://msysgit.github.com/
 
-After it’s installed, you have both a command-line version (including an SSH client that will come in handy later) and the standard GUI.
+Etter den er installert, så har du både en kommandolinje versjon (inkludert en SSH klient som vil bli nyttig senere) og det standard grafiske brukgergrensesnittet.
 
-Note on Windows usage: you should use Git with the provided msysGit shell (Unix style), it allows to use the complex lines of command given in this book. If you need, for some reason, to use the native Windows shell / command line console, you have to use double quotes instead of simple quotes (for parameters with spaces in them) and you must quote the parameters ending with the circumflex accent (^) if they are last on the line, as it is a continuation symbol in Windows.
+Merknad om Windows bruk: du burde bruke Git med msysGit shellet (Unix stil) som kommer med, det lar deg bruke de komplekse linjene med kommandoer gitt i denne boken. Om du av en eller annen grunn skulle trenge å bruke Windows sitt eget shell/kommandolinje konsoll, så må du bruker dobbelt annførsel tegn istedet for enkelt annførselstegn (for parametere med mellomrom i seg) og du må bruke annførseltegn på parametere som slutter med ^ om de er på slutten av linjen, siden det er et forsettelsesymbol i Windows.
 
 ## First-Time Git Setup ##
 

From 414039a62d8d5f98e1aa066e7e4fa79d847b368b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Stian=20Dr=C3=B8bak?= <sum41rules4@hotmail.com>
Date: Sat, 2 Aug 2014 22:53:27 +0200
Subject: [PATCH 534/690] no-NB translation Chapter 1 First time setup

---
 no-nb/01-introduction/01-chapter1.markdown | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/no-nb/01-introduction/01-chapter1.markdown b/no-nb/01-introduction/01-chapter1.markdown
index 9c73eab43..cdaefb9d0 100644
--- a/no-nb/01-introduction/01-chapter1.markdown
+++ b/no-nb/01-introduction/01-chapter1.markdown
@@ -186,17 +186,17 @@ Etter den er installert, så har du både en kommandolinje versjon (inkludert en
 
 Merknad om Windows bruk: du burde bruke Git med msysGit shellet (Unix stil) som kommer med, det lar deg bruke de komplekse linjene med kommandoer gitt i denne boken. Om du av en eller annen grunn skulle trenge å bruke Windows sitt eget shell/kommandolinje konsoll, så må du bruker dobbelt annførsel tegn istedet for enkelt annførselstegn (for parametere med mellomrom i seg) og du må bruke annførseltegn på parametere som slutter med ^ om de er på slutten av linjen, siden det er et forsettelsesymbol i Windows.
 
-## First-Time Git Setup ##
+## Git Oppsett For Førstegangsbruk ##
 
-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.
+Nå som du har Git på systemet ditt, så vil du ønske å gjøre noen få endringer for Git miljøet ditt. Du burder bare trenge å gjøre disse tingene en gang; for de blir værende med deg mellom oppgraderinger. Du kan også endre dem når som helst ved å gå gjennom kommandoene igjen.
 
-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:
+Git kommer med et verktøy kalt git config som lar deg hente og sette instillingvariabler som kontrollerer alle aspektene av hvoran Git ser ut og virker. Disse varaiblene kan bli lagret i tre forskjellige steder:
 
-*	`/etc/gitconfig` file: Contains values for every user on the system and all their repositories. If you pass the option` --system` to `git config`, it reads and writes from this file specifically.
-*	`~/.gitconfig` file: Specific to your user. You can make Git read and write to this file specifically by passing the `--global` option.
-*	config file in the git directory (that is, `.git/config`) of whatever repository you’re currently using: Specific to that single repository. Each level overrides values in the previous level, so values in `.git/config` trump those in `/etc/gitconfig`.
+*	`/etc/gitconfig` filen: Inneholder verdier for alle brukerene på systemet og alle repositoriene deres. Hvis du sender valget `--system` til `git config`, så vil det lese og skrives i denne filen.
+*	`~/.gitconfig` filen: Spesifikk for brukeren. Du kan får Git til å lese og skrive til denne filen ved å sende `--global` valget.
+*	config filen i git mappen (altså `.git/config`) av hvilken som helst repository du bruker for øyeblikket: Brukes for det enkelte repositoriet. Hver nivå overstyrer verdiene fra forrige nivå, så verdiene i `.git/config` trumfer de som er i `/etc/gitconfig`.
 
-On Windows systems, Git looks for the `.gitconfig` file in the `$HOME` directory (`%USERPROFILE%` in Windows’ environment), which is `C:\Documents and Settings\$USER` or `C:\Users\$USER` for most people, depending on version (`$USER` is `%USERNAME%` in Windows’ environment). 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.
+På Windows systemer så ser Git etter `.gitconfig`filen i `$HOME` mappen (`%USERPROFILE%` for Windows), som er `C:\Documents and Settings\$USER` eller `C:\Users\$User` for de fleste, avhengig av versjon (`$USER` er `%USERNAME%` i Windows). Det ser forsatt etter /etc/gitconfig/, selv om det er relativt til MSys root, som er hvor du la inn Git for Windows systemet når du installerte det.
 
 ### Your Identity ###
 

From 951934924227d527f0d112a4d1ffc60bc6d6b75f Mon Sep 17 00:00:00 2001
From: Petr Prikryl <prikryl@atlas.cz>
Date: Sun, 3 Aug 2014 01:07:35 +0200
Subject: [PATCH 535/690] [cs] typo in chapter 1

---
 cs/01-introduction/01-chapter1.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/cs/01-introduction/01-chapter1.markdown b/cs/01-introduction/01-chapter1.markdown
index 88b767131..3e34d6e33 100644
--- a/cs/01-introduction/01-chapter1.markdown
+++ b/cs/01-introduction/01-chapter1.markdown
@@ -219,7 +219,7 @@ Další užitečnou volbou, jejíž nastavení můžete chtít upravit, je vých
 
 Jako platné nástroje slučování Git akceptuje: kdiff3, tkdiff, meld, xxdiff, emerge, vimdiff, gvimdiff, ecmerge a opendiff. Nastavit můžete ale i jiné uživatelské nástroje — více informací o této možnosti naleznete v kapitole 7.
 
-### Kontrola va3eho nastavení ###
+### Kontrola vašeho nastavení ###
 
 Chcete-li zkontrolovat vaše nastavení, použijte příkaz `git config --list`. Git vypíše všechna aktuálně dostupná nastavení:
 

From 858c3d39fc92cd7336f2201a8a123b18480d8a03 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Jos=C3=A9=20Barbosa?= <kide.lemark@gmail.com>
Date: Sun, 3 Aug 2014 02:55:48 -0300
Subject: [PATCH 536/690] [pt-br] Update chapter 3 git-branching

In line 53 'testing' is the name of branch
---
 pt-br/03-git-branching/01-chapter3.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/pt-br/03-git-branching/01-chapter3.markdown b/pt-br/03-git-branching/01-chapter3.markdown
index 1b41b516a..21bf4b417 100644
--- a/pt-br/03-git-branching/01-chapter3.markdown
+++ b/pt-br/03-git-branching/01-chapter3.markdown
@@ -50,7 +50,7 @@ Para mudar para um branch existente, você executa o comando `git checkout`. Vam
 
     $ git checkout testing
 
-Isto move o HEAD para apontar para o branch de testes (ver Figura 3-6).
+Isto move o HEAD para apontar para o branch testing (ver Figura 3-6).
 
 Insert 18333fig0306.png
 Figura 3-6. O HEAD aponta para outro branch quando você troca de branches.

From 37fd1be85e3b8181747413051c4d9ca7e200e24e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Stian=20Dr=C3=B8bak?= <sum41rules4@hotmail.com>
Date: Sun, 3 Aug 2014 14:38:06 +0200
Subject: [PATCH 537/690] no-NB translation Chapter 1 everything after Setup

---
 no-nb/01-introduction/01-chapter1.markdown | 38 +++++++++++-----------
 1 file changed, 19 insertions(+), 19 deletions(-)

diff --git a/no-nb/01-introduction/01-chapter1.markdown b/no-nb/01-introduction/01-chapter1.markdown
index cdaefb9d0..ffa721142 100644
--- a/no-nb/01-introduction/01-chapter1.markdown
+++ b/no-nb/01-introduction/01-chapter1.markdown
@@ -198,32 +198,32 @@ Git kommer med et verktøy kalt git config som lar deg hente og sette instilling
 
 På Windows systemer så ser Git etter `.gitconfig`filen i `$HOME` mappen (`%USERPROFILE%` for Windows), som er `C:\Documents and Settings\$USER` eller `C:\Users\$User` for de fleste, avhengig av versjon (`$USER` er `%USERNAME%` i Windows). Det ser forsatt etter /etc/gitconfig/, selv om det er relativt til MSys root, som er hvor du la inn Git for Windows systemet når du installerte det.
 
-### Your Identity ###
+### Din Identitet ###
 
-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:
+Det første du burde gjøre når du installerer Git er å sette brukernavnet og email-addressen din. Dette er viktig fordig alle Git commiter bruker denne informasjonen, og det er uforanderlig integrert inn i commitene du sender rundt.
 
 	$ git config --global user.name "John Doe"
 	$ git config --global user.email johndoe@example.com
 
-Again, you need to do this only once if you pass the `--global` option, because then Git will always use that information for anything you do on that system. If you want to override this with a different name or e-mail address for specific projects, you can run the command without the `--global` option when you’re in that project.
+Igjen, så trenger du bare å gjøre dette en gang om du bruker `--global` valget, siden Git alltid bruker den informasjonen for alt du gjør på det systemet. Hvis du ønsker å overstyre dette med ett annet navn eller email-adresse for bestemte prosjekter, så kan du kjøre kommandoen uten `--global` valget når du er i det prosjektet.
 
-### Your Editor ###
+### Din Editor ###
 
-Now that your identity is set up, you can configure the default text editor that will be used when Git needs you to type in a message. By default, Git uses your system’s default editor, which is generally Vi or Vim. If you want to use a different text editor, such as Emacs, you can do the following:
+Nå som din identiter er satt opp, så kan du konfigurere den forhåndsvalgte tekst editoren som vil bli brukt når Git trenger at du skriver en beskjed. Forhåndsvalget satt i Git bruker systemets forhåndsvalgte editor, som generelt sett er Vi eller Vim. Hvis du ønsker å bruke en annen tekst editor, som Emacs, så kan du gjøre følgende:
 
 	$ git config --global core.editor emacs
 
-### Your Diff Tool ###
+### Ditt Diff Verktøy ###
 
-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:
+Et annet nyttig valg du kanskje vil endre på er forhåndsvalgt diff verktøy for å bruke til å håndtere merge konflikter. Så si du ønsker å bruke vimdiff:
 
 	$ git config --global merge.tool vimdiff
 
-Git accepts kdiff3, tkdiff, meld, xxdiff, emerge, vimdiff, gvimdiff, ecmerge, and opendiff as valid merge tools. You can also set up a custom tool; see Chapter 7 for more information about doing that.
+Git godtar kdiff3, tkdiff, meld, xxdif, emerge, vimdiff, gvimdiff, ecmerge, and opendiff som godkjente merge verktøy. Du kan også sette opp et eget verktøy; se Kapitel 7 for mer informasjon om hvordan gjøre det.
 
-### Checking Your Settings ###
+### Sjekke Innstillingene Dine ###
 
-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:
+Hvis du ænsker å sjekke innstillingene dine, så kan du bruke `git config --list` kommandoen for å liste alle innstillingene Git kan finne akkurat da:
 
 	$ git config --list
 	user.name=Scott Chacon
@@ -234,28 +234,28 @@ If you want to check your settings, you can use the `git config --list` command
 	color.diff=auto
 	...
 
-You may see keys more than once, because Git reads the same key from different files (`/etc/gitconfig` and `~/.gitconfig`, for example). In this case, Git uses the last value for each unique key it sees.
+Du kan se nøkler mer enn en gang, siden Git leser den samme nøkkelen fra forskjellige filer (`/etc/gitconfig` og `~/.gitconfig`, for eksempel). I såfall, så bruker Git den siste verdien for hver unike nøkkel den ser.
 
-You can also check what Git thinks a specific key’s value is by typing `git config {key}`:
+Du kan også sjekke hva Git tror en spesifikk nøkkels verdi er ved å skrive `git config {nøkkel}`:
 
 	$ git config user.name
 	Scott Chacon
 
-## Getting Help ##
+## Skaffe Seg Hjelp ##
 
-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:
+Hvis du noen gang trenger hjelp mens du bruker Git, så er det tre måter å få manual sidens (manpage) hjelp for en hvilken som helst Git kommando:
 
 	$ git help <verb>
 	$ git <verb> --help
 	$ man git-<verb>
 
-For example, you can get the manpage help for the config command by running
+For eksempel, du kan få manpage hjelp ved for config kommandoen ved å bruke
 
 	$ git help config
 
-These commands are nice because you can access them anywhere, even offline.
-If the manpages and this book aren’t enough and you need in-person help, you can try the `#git` or `#github` channel on the Freenode IRC server (irc.freenode.net). These channels are regularly filled with hundreds of people who are all very knowledgeable about Git and are often willing to help.
+Disse kommandoene er fine fordi du kan få tilgang til dem over alt, tilogmed offline.
+Hvis manpagene og denne boken ikke er nok, og du trenger hjelp fra folk, så kan du prøve `#git` eller `#github` kanalene på Freenode IRC Server (irc.freenode.net). Disse kanalene er til vanlig fylt med hundrevis av folk som alle kan veldig mye om Git og er ofte villige til å hjelpe.
 
-## Summary ##
+## Sammendrag ##
 
-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.
+Du burde ha grunnleggende forståelse for hva Git er og hvordan det skiller seg fra CVCSene du kan ha brukt. Du burde også nå ha en funksjonell versjon av Git på ditt system som er satt opp med din personlige identitet. Det er nå på tide å lære litt grunnleggende Git.

From 1cc57ebcf8aaba0d2fc30d43057188835d0378de Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Stian=20Dr=C3=B8bak?= <sum41rules4@hotmail.com>
Date: Sun, 3 Aug 2014 14:50:13 +0200
Subject: [PATCH 538/690] no-NB translation Chapter 1 translated.

---
 no-nb/01-introduction/01-chapter1.markdown | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/no-nb/01-introduction/01-chapter1.markdown b/no-nb/01-introduction/01-chapter1.markdown
index ffa721142..158c7678c 100644
--- a/no-nb/01-introduction/01-chapter1.markdown
+++ b/no-nb/01-introduction/01-chapter1.markdown
@@ -19,16 +19,16 @@ Figure 1-1. Lokalt versjonskontrolldiagram.
 
 Et av de mer populære VCS-verktøyene var et system kalt rcs, som fremdeles distribueres med mange datamaskiner i dag. Selv det populære Mac OS X-operativsystemet inkluderer rcs-kommandoen når en installerer utviklerverktøyene. Dette verktøyet virker, enkelt fortalt, ved å beholde et sett av patcher (dvs, forskjellen mellom filene) fra en revisjon til en annen, i et spesielt format på disken; det kan så gjenskape hvordan enhver fil så ut på et hvilket som helst tidspunkt, ved å legge sammen alle patchene.
 
-### Centralized Version Control Systems ###
+### Sentraliserte Versjonkontrol Systemer ###
 
-The next major issue that people encounter is that they need to collaborate with developers on other systems. To deal with this problem, Centralized Version Control Systems (CVCSs) were developed. These systems, such as CVS, Subversion, and Perforce, have a single server that contains all the versioned files, and a number of clients that check out files from that central place. For many years, this has been the standard for version control (see Figure 1-2).
+Det neste store problemet folk møter er at de trenger å sammarbeide med utviklere på andre systemer. For å håndere det problemet så var Sentraliserte Versjonkontrol Systmer (CVCSer) utviklet. Disse systemene, som CVS, Subversion, og Perforce, har en ekelt server som inneholder alle versjonerte filer, og tallvis med klienter som sjekker ut filene fra det sentrale stedet. I mange år så har det vært standard for versjonkontrol (Se Figur 1-2).
 
 Insert 18333fig0102.png
-Figure 1-2. Centralized version control diagram.
+Figure 1-2. Sentralisert versjonkontroll diagram.
 
-This setup offers many advantages, especially over local VCSs. For example, everyone knows to a certain degree what everyone else on the project is doing. Administrators have fine-grained control over who can do what; and it’s far easier to administer a CVCS than it is to deal with local databases on every client.
+Dette oppsettet tilbyr mange fordeler, spesielt over lokal VCS. For eksempel, alle vet til en viss grad hva alle andre i prosjektet gjør. Administratorer har god kontroll over hvem som kan gjøre hva; og det er langt enklere å administrere en CVCS enn det er å jobbe med lokale databaser på alle klienter.
 
-However, this setup also has some serious downsides. The most obvious is the single point of failure that the centralized server represents. If that server goes down for an hour, then during that hour nobody can collaborate at all or save versioned changes to anything they’re working on. If the hard disk the central database is on becomes corrupted, and proper backups haven’t been kept, you lose absolutely everything—the entire history of the project except whatever single snapshots people happen to have on their local machines. Local VCS systems suffer from this same problem—whenever you have the entire history of the project in a single place, you risk losing everything.
+Dette oppsettet har også noen seriøse ulemper. Det mest opplagte er det enkelte punktet for feiling som den sentraliserte serven representere. Hvis den serveren er nede i en time, så kan ingen samarbeide i det hele tatt, eller lagre versjon endringer for noe som helst de jobber på i løpet av den timen. Hvis harddisken den sentraliserte databasen er på blir korrupt, og skikkelige backuper ikke har blir lagt, så vil du miste alt- hele historien til prosjektet med untak i hvilket nå enn enkle bildet folk har akkurat da på deres lokale maskiner. Lokale VCS systmer lider fra det samme problemet, når du har hele historien til prosjeket på ett sted, så risikerer du å miste alt.
 
 ### Distribuerte versjonkontrollsystemer ###
 

From 739323d072d4785be6721b7c81a1063631779c19 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Stian=20Dr=C3=B8bak?= <sum41rules4@hotmail.com>
Date: Sun, 3 Aug 2014 22:44:20 +0200
Subject: [PATCH 539/690] no-NB trans Chapter 2 Git Basic

---
 no-nb/02-git-basics/01-chapter2.markdown | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/no-nb/02-git-basics/01-chapter2.markdown b/no-nb/02-git-basics/01-chapter2.markdown
index 69de1735e..b8642eb2e 100644
--- a/no-nb/02-git-basics/01-chapter2.markdown
+++ b/no-nb/02-git-basics/01-chapter2.markdown
@@ -1,6 +1,6 @@
-# Git Basics #
+# Grunnleggende Git #
 
-If you can read only one chapter to get going with Git, this is it. This chapter covers every basic command you need to do the vast majority of the things you’ll eventually spend your time doing with Git. By the end of the chapter, you should be able to configure and initialize a repository, begin and stop tracking files, and stage and commit changes. We’ll also show you how to set up Git to ignore certain files and file patterns, how to undo mistakes quickly and easily, how to browse the history of your project and view changes between commits, and how to push and pull from remote repositories.
+Om du bare kan lese et kapitel for å komme i gang med Git, så er dette det kapitelet. Dette kapitellet dekker hver grunnlegende kommando du trenger for å gjøre største delen av ting du etterhvert vil bruke tiden din på å gjøre i Git. Ved slutten av dette kapitelet, så burde du være istand til å konfigurere og initiere et repository, begynne og stoppe overvåking av filer, og stage og commite endringer. Vi vil også vise deg hvordan sette opp Git til å ignorere visse filer og filmønstre, hvordan angre på feil fort og enkelt, hvordan se gjennom historien for prosjektet ditt og se på endringer mellom commiter, og hvordan pushe(dytte) endringer til eller pulle(dra) endringer fra en fjern repository.
 
 ## Getting a Git Repository ##
 

From 15f5ed0e7e1f57060be54e9d44aa6e0f9948de2b Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Mon, 4 Aug 2014 07:59:02 +0200
Subject: [PATCH 540/690] [it] reviewed chapter 1

Rewording for better understanding
---
 it/04-git-server/01-chapter4.markdown | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/it/04-git-server/01-chapter4.markdown b/it/04-git-server/01-chapter4.markdown
index 23de5a0a5..4ec820877 100644
--- a/it/04-git-server/01-chapter4.markdown
+++ b/it/04-git-server/01-chapter4.markdown
@@ -231,15 +231,14 @@ L'autenticazione tramite chiavi SSH generalmente richiede una restrizione dei di
  
  	$ chmod -R go= ~/.ssh
  
-
- Ora, puoi impostare un repository vuoto avviando `git init` con l'opzione `--bare`, che inizializza il repository senza la directory di lavoro:
+Ora, puoi impostare un repository vuoto avviando `git init` con l'opzione `--bare`, che inizializza il repository senza la directory di lavoro:
 
 	$ cd /opt/git
 	$ mkdir project.git
 	$ cd project.git
 	$ git --bare init
 
-Poi, John, Josie o Jessica possono inviare la prima versione del loro progetto nel repository aggiungendolo come ramo remoto ed inviandolo su di un ramo. Nota che qualcuno deve accedere via shell alla macchina e creare un repository base ogni volta che si vuole aggiungere un progetto. Usiamo il nome `gitserver` per il server dove hai impostato il tuo utente 'git' ed il repository. Se lo stai usando nella rete interna e hai impostato un DNS con il punto `gitserver` per puntare a questo server, allora puoi usare il comando:
+E John, Josie o Jessica possono inviare la prima versione del loro progetto nel repository aggiungendolo come ramo remoto ed inviandolo su di un ramo. Fai attenzione che ogni volta che vuoi aggiungere un progetto, qualcuno deve accedere via shell alla macchina e creare un repository base. Usiamo il nome `gitserver` per il server dove hai impostato il tuo utente 'git' ed il repository. Se lo stai usando nella rete interna e hai impostato un DNS con il punto `gitserver` per puntare a questo server, allora puoi usare il comando:
 
 	# sul computer di Johns
 	$ cd myproject

From 127cfe7d73c540bfc2a76c642736fe54a950d8fc Mon Sep 17 00:00:00 2001
From: Petr Prikryl <prikryl@atlas.cz>
Date: Mon, 4 Aug 2014 16:44:00 +0200
Subject: [PATCH 541/690] [cs] Chapter 2 manually revised up to 2.3 including

---
 cs/02-git-basics/01-chapter2.markdown | 84 +++++++++++++--------------
 1 file changed, 42 insertions(+), 42 deletions(-)

diff --git a/cs/02-git-basics/01-chapter2.markdown b/cs/02-git-basics/01-chapter2.markdown
index 7720fdead..9ea03b7ef 100644
--- a/cs/02-git-basics/01-chapter2.markdown
+++ b/cs/02-git-basics/01-chapter2.markdown
@@ -1,10 +1,10 @@
 # Základy práce se systémem Git #
 
-Pokud jste ochotni přečíst si o systému Git jen jednu kapitolu, měla by to být právě tahle. Tato kapitola popíše všechny základní příkazy, jejichž prováděním strávíte drtivou většinu času při práci se systémem Git. Po přečtení kapitoly byste měli být schopni nakonfigurovat a inicializovat repozitář, spustit a ukončit sledování souborů, připravovat soubory a zapisovat revize. Ukážeme také, jak nastavit Git, aby ignoroval určité soubory a masky souborů, jak rychle a jednoduše vrátit nežádoucí změny, jak procházet historii projektu a zobrazit změny mezi jednotlivými revizemi a jak posílat soubory do vzdálených repozitářů a stahovat z nich.
+Pokud jste ochotni přečíst si o systému Git jen jednu kapitolu, měla by to být právě tahle. Tato kapitola popíše všechny základní příkazy, jejichž prováděním strávíte při práci se systémem Git drtivou většinu času. Po přečtení kapitoly byste měli být schopni nakonfigurovat a inicializovat repozitář, spustit a ukončit sledování souborů, připravovat soubory a zapisovat revize. Ukážeme si také, jak nastavit Git, aby ignoroval určité soubory a masky souborů, jak rychle a jednoduše vrátit nežádoucí změny, jak procházet historii projektu a zobrazit změny mezi jednotlivými revizemi a jak posílat soubory do vzdálených repozitářů a naopak z nich soubory zase stahovat.
 
 ## Získání repozitáře Git ##
 
-Projekt v systému Git lze získat dvěma základními způsoby. První vezme existující projekt nebo adresář a importuje ho do systému Git. Druhý naklonuje existující repozitář Git z jiného serveru.
+Projekt v systému Git lze získat dvěma základními způsoby. První způsob spočívá v tom, že vezmeme existující projekt nebo adresář a importujeme ho do systému Git. Druhý způsob spočívá v naklonování již existujícího repozitáře Git z jiného serveru.
 
 ### Inicializace repozitáře v existujícím adresáři ###
 
@@ -12,9 +12,9 @@ Chcete-li zahájit sledování existujícího projektu v systému Git, přejdět
 
 	$ git init
 
-Příkaz vytvoří nový podadresář s názvem `.git`, který bude obsahovat všechny soubory nezbytné pro repozitář, tzv. kostru repozitáře Git. V tomto okamžiku ještě není nic z vašeho projektu sledováno. (Více informací o tom, jaké soubory obsahuje právě vytvořený adresář `.git`, naleznete v kapitole 9.)
+Příkaz vytvoří nový podadresář s názvem `.git`, který bude obsahovat všechny soubory nezbytné pro repozitář, tzv. kostru repozitáře Git. V tomto okamžiku se z vašeho projektu ještě nic nesleduje. (Více informací o tom, jaké soubory obsahuje právě vytvořený adresář `.git`, naleznete v *kapitole 9*.)
 
-Chcete-li spustit verzování existujících souborů (na rozdíl od prázdného adresáře), měli byste pravděpodobně zahájit sledování (tracking) těchto souborů a provést první revizi (commit). Můžete tak učinit pomocí několika příkazů `git add`, jimiž určíte soubory, které chcete sledovat, a provedete revizi:
+Chcete-li spustit verzování existujících souborů (a ne jen prázdného adresáře), měli byste pravděpodobně zahájit sledování (tracking) těchto souborů a provést první revizi (commit). Můžete tak učinit pomocí několika příkazů `git add`, jimiž určíte soubory, které chcete sledovat, a provedete revizi:
 
 	$ git add *.c
 	$ git add README
@@ -24,27 +24,27 @@ K tomu, co přesně tyto příkazy provedou, se dostaneme za okamžik. V této c
 
 ### Klonování existujícího repozitáře ###
 
-Chcete-li vytvořit kopii existujícího repozitáře Git (například u projektu, do nějž chcete začít přispívat), pak příkazem, který hledáte, je `git clone`. Pokud jste zvyklí pracovat s jinými systémy VCS, např. se systémem Subversion, jistě jste si všimli, že příkaz zní `clone`, a nikoli `checkout`. Souvisí to s jedním podstatným rozdílem: Git stáhne kopii téměř všech dat na serveru. Po spuštění příkazu `git clone` budou k historii projektu staženy všechny verze všech souborů. Pokud by někdy poté došlo k poruše disku serveru, lze použít libovolný z těchto klonů na kterémkoli klientovi a obnovit pomocí něj server zpět do stavu, v němž byl v okamžiku klonování (může dojít ke ztrátě některých zásuvných modulů na straně serveru apod., ale všechna verzovaná dat budou obnovena – další podrobnosti v kapitole 4).
+Chcete-li vytvořit kopii existujícího repozitáře Git (například u projektu, do nějž chcete začít přispívat), pak příkazem, který hledáte, je `git clone`. Pokud jste zvyklí pracovat s jinými systémy pro správu verzí, jako je například Subversion, jistě jste si všimli, že příkaz zní `clone`, a nikoli `checkout`. Souvisí to s jedním podstatným rozdílem: Git získá kopii téměř všech dat na serveru. Po spuštění příkazu `git clone` budou k historii projektu staženy všechny verze všech souborů. Pokud by někdy poté došlo k poruše disku serveru, lze použít libovolný z těchto klonů na kterémkoli klientovi a obnovit pomocí něj server zpět do stavu, v němž byl v okamžiku klonování (může dojít ke ztrátě některých zásuvných modulů na straně serveru a podobných věcí, ale všechna verzovaná data budou obnovena. Další podrobnosti naleznete v *kapitole 4*).
 
 Repozitář naklonujete příkazem `git clone [url]`. Pokud například chcete naklonovat knihovnu Ruby Git nazvanou Grit, můžete to provést následovně:
 
 	$ git clone git://github.com/schacon/grit.git
 
-Tímto příkazem vytvoříte adresář s názvem `grit`, inicializujete v něm adresář `.git`, stáhnete všechna data pro tento repozitář a systém rovněž stáhne pracovní kopii nejnovější verze. Přejdete-li do nového adresáře `grit`, uvidíte v něm soubory projektu připravené ke zpracování nebo jinému použití. Pokud chcete naklonovat repozitář do adresáře pojmenovaného jinak než grit, můžete název zadat jako další parametr na příkazovém řádku:
+Tímto příkazem se vytvoří adresář s názvem `grit`, inicializuje se v něm adresář `.git`, stáhnou se všechna data pro tento repozitář a vytvoří se pracovní kopie nejnovější verze. Přejdete-li do nového adresáře `grit`, uvidíte v něm soubory projektu připravené ke zpracování nebo jinému použití. Pokud chcete naklonovat repozitář do adresáře pojmenovaného jinak než grit, můžete název zadat jako další parametr na příkazovém řádku:
 
 	$ git clone git://github.com/schacon/grit.git mygrit
 
-Tento příkaz učiní totéž co příkaz předchozí, jen cílový adresář se bude jmenovat `mygrit`.
+Tento příkaz učiní totéž co příkaz předchozí, ale cílový adresář se bude jmenovat `mygrit`.
 
-Git nabízí celou řadu různých přenosových protokolů. Předchozí příklad využívá protokol `git://`, můžete se ale setkat také s protokolem `http(s)://` nebo `user@server:/path.git`, který používá přenosový protokol SSH. V kapitole 4 budou představeny všechny dostupné parametry pro nastavení serveru pro přístup do repozitáře Git, včetně jejich předností a nevýhod.
+Git nabízí celou řadu různých přenosových protokolů. Předchozí příklad využívá protokol `git://`, můžete se ale setkat také s protokolem `http(s)://` nebo `user@server:/path.git`, který používá přenosový protokol SSH. V *kapitole 4* budou představeny všechny dostupné možnosti, které mohou být pro přístup do repozitáře Git na serveru nastaveny, včetně jejich předností a nevýhod.
 
 ## Nahrávání změn do repozitáře ##
 
-Nyní máte vytvořen repozitář Git a checkout nebo pracovní kopii souborů k projektu. Řekněme, že potřebujete udělat pár změn a zapsat snímky těchto změn do svého repozitáře pokaždé, kdy se projekt dostane do stavu, v němž ho chcete nahrát.
+Nyní máte vytvořen opravdový gitový repozitář a pracovní kopii souborů k projektu (checkout). Řekněme, že potřebujete udělat pár změn a zapsat snímky těchto změn do svého repozitáře pokaždé, kdy se projekt dostane do stavu, který chcete zaznamenat.
 
-Nezapomeňte, že každý soubor ve vašem pracovním adresáři může být ve dvou různých stavech: sledován a nesledován. Za sledované jsou označovány soubory, které byly součástí posledního snímku. Mohou být ve stavu změněno (modified), nezměněno (unmodified) nebo připraveno k zapsání (staged). Nesledované soubory jsou všechny ostatní, tedy veškeré soubory ve vašem pracovním adresáři, které nebyly obsaženy ve vašem posledním snímku a nejsou v oblasti připravených změn. Po úvodním klonování repozitáře budou všechny vaše soubory sledované a nezměněné, protože jste právě provedli jejich checkout a dosud jste neudělali žádné změny.
+Nezapomeňte, že každý soubor ve vašem pracovním adresáři může být ve dvou různých stavech: *sledován* (tracked) a *nesledován* (untracked). Za *sledované* jsou označovány soubory, které byly součástí posledního snímku. Mohou být ve stavu *změněn* (modified), *nezměněn* (unmodified) nebo *připraven k zapsání* (staged). *Nesledované* soubory jsou všechny ostatní, tedy veškeré soubory ve vašem pracovním adresáři, které nebyly obsaženy ve vašem posledním snímku a nejsou v oblasti připravených změn. Po úvodním klonování repozitáře budou všechny vaše soubory sledované a nezměněné, protože jste právě provedli jejich checkout a dosud jste neudělali žádné změny.
 
-Jakmile začnete soubory upravovat, Git je bude považovat za „změněné“, protože jste v nich od poslední revize provedli změny. Poté všechny tyto změněné soubory připravíte k zapsání a následně všechny připravené změny zapíšete. Cyklus může začít od začátku. Pracovní cyklus je znázorněn na obrázku 2-1.
+Jakmile začnete soubory upravovat, Git je bude považovat za změněné, protože jste v nich od poslední revize provedli změny. Poté všechny tyto změněné soubory *připravíte k zapsání* (stage) a následně všechny připravené změny zapíšete (commit). A celý cyklus se opakuje. Pracovní cyklus je znázorněn na obrázku 2-1.
 
 Insert 18333fig0201.png
 Obrázek 2-1. Cyklus stavů vašich souborů
@@ -57,9 +57,9 @@ Hlavním nástrojem na zjišťování stavu jednotlivých souborů je příkaz `
 	On branch master
 	nothing to commit, working directory clean
 
-To znamená, že žádné soubory nejsou připraveny k zapsání a pracovní adresář je čistý. Jinými slovy žádné sledované soubory nebyly změněny. Git také neví o žádných nesledovaných souborech, jinak by byly ve výčtu uvedeny. Příkaz vám dále sděluje, na jaké větvi (branch) se nacházíte. Pro tuto chvíli nebudeme situaci komplikovat a výchozí bude vždy hlavní větev (`master` branch). Větve a reference budou podrobně popsány v následující kapitole.
+To znamená, že žádné soubory nejsou připraveny k zapsání a pracovní adresář je čistý. Jinými slovy, žádné sledované soubory nebyly změněny. Git také neví o žádných nesledovaných souborech, jinak by byly ve výčtu uvedeny. Příkaz vám dále sděluje, na jaké větvi (branch) se nacházíte. Pro tuto chvíli nebudeme situaci komplikovat a výchozí bude vždy hlavní větev (`master` branch). Větve a reference budou podrobně popsány v následující kapitole.
 
-Řekněme, že nyní přidáte do projektu nový soubor, například soubor `README`. Pokud soubor neexistoval dříve a vy spustíte příkaz `git status`, bude nesledovaný soubor uveden takto:
+Řekněme, že nyní přidáte do projektu nový soubor, například soubor `README`. Pokud soubor dříve neexistoval a vy spustíte příkaz `git status`, bude nesledovaný soubor uveden takto:
 
 	$ vim README
 	$ git status
@@ -91,9 +91,9 @@ Když nyní znovu provedete příkaz k výpisu stavů (git status), uvidíte, ž
 
 Můžeme říci, že je připraven k zapsání, protože je uveden v části „Changes to be committed“, tedy „Změny k zapsání“. Pokud v tomto okamžiku zapíšete revizi, v historickém snímku bude verze souboru z okamžiku, kdy jste spustili příkaz `git add`. Možná si vzpomínáte, že když jste před časem spustili příkaz `git init`, provedli jste potom příkaz `git add (soubory)`. Příkaz jste zadávali kvůli zahájení sledování souborů ve vašem adresáři. Příkaz `git add` je doplněn uvedením cesty buď k souboru, nebo k adresáři. Pokud se jedná o adresář, příkaz přidá rekurzivně všechny soubory v tomto adresáři.
 
-### Připravení změněných souborů ###
+### Příprava změněných souborů k zapsání ###
 
-Nyní provedeme změny v souboru, který už byl sledován. Pokud změníte už dříve sledovaný soubor s názvem `benchmarks.rb` a poté znovu spustíte příkaz `status`, zobrazí se výpis podobného obsahu:
+Nyní provedeme změny v souboru, který už byl sledován. Pokud změníte už dříve sledovaný soubor s názvem `benchmarks.rb` a poté znovu spustíte příkaz `status`, zobrazí se něco takového:
 
 	$ git status
 	On branch master
@@ -109,7 +109,7 @@ Nyní provedeme změny v souboru, který už byl sledován. Pokud změníte už
 	        modified:   benchmarks.rb
 
 
-Soubor `benchmarks.rb` je uveden v části „Changes not staged for commit“ (Změněno, ale neaktualizováno). Znamená to, že soubor, který je sledován, byl v pracovním adresáři změněn, avšak ještě nebyl připraven k zapsání. Chcete-li ho připravit, spusťte příkaz `git add` (jedná se o univerzální příkaz – používá se k zahájení sledování nových souborů, k připravení souborů a k dalším operacím, jako např. k označení souborů, které kolidovaly při sloučení, za vyřešené). Spusťme nyní příkaz `git add` k připravení souboru `benchmarks.rb` k zapsání a následně znovu příkaz `git status`:
+Soubor `benchmarks.rb` je uveden v části „Changes not staged for commit“ (změněny nejsou připraveny k zapsání). Znamená to, že soubor, který je sledován, byl v pracovním adresáři změněn, avšak ještě nebyl připraven k zapsání (staged). Chcete-li ho připravit k zapsání, spusťte příkaz `git add` (jedná se o víceúčelový příkaz – používá se k zahájení sledování nových souborů i k dalším operacím, jako je například označení vyřešených případů kolize souborů při slučování). Spusťme nyní příkaz `git add`, abychom soubor `benchmarks.rb` připravili k zapsání, a potom znovu zadejme příkaz `git status`:
 
 	$ git add benchmarks.rb
 	$ git status
@@ -121,7 +121,7 @@ Soubor `benchmarks.rb` je uveden v části „Changes not staged for commit“ (
 	        modified:   benchmarks.rb
 
 
-Oba soubory jsou nyní připraveny k zapsání a budou zahrnuty do příští revize. Nyní předpokládejme, že jste si vzpomněli na jednu malou změnu, kterou chcete ještě před zapsáním revize provést v souboru `benchmarks.rb`. Soubor znovu otevřete a provedete změnu. Soubor je připraven k zapsání. Spusťme však ještě jednou příkaz `git status`:
+Oba soubory jsou nyní připraveny k zapsání a budou zahrnuty do příští revize. Nyní předpokládejme, že jste si vzpomněli na jednu malou změnu, kterou chcete ještě před zapsáním revize provést v souboru `benchmarks.rb`. Soubor znovu otevřete, provedete změnu a chcete jej zapsat. Spusťme však ještě jednou příkaz `git status`:
 
 	$ vim benchmarks.rb
 	$ git status
@@ -139,7 +139,7 @@ Oba soubory jsou nyní připraveny k zapsání a budou zahrnuty do příští re
 	        modified:   benchmarks.rb
 
 
-Co to má být? Soubor `benchmarks.rb` je nyní uveden jak v části připraveno k zapsání (Changes to be committed), tak v části nepřipraveno k zapsání (Changes not staged for commit). Jak je tohle možné? Věc se má tak, že Git po spuštění příkazu `git add` připraví soubor přesně tak, jak je. Pokud nyní revizi zapíšete, bude obsahovat soubor `benchmarks.rb` tak, jak vypadal když jste naposledy spustili příkaz `git add`, nikoli v té podobě, kterou měl v pracovním adresáři v okamžiku, když jste spustili příkaz `git commit`. Pokud upravíte soubor po provedení příkazu `git add`, je třeba spustit `git add` ještě jednou, aby byla připravena aktuální verze souboru:
+Co to má být? Soubor `benchmarks.rb` je nyní uveden jak v části připraveno k zapsání (Changes to be committed), tak v části nepřipraveno k zapsání (Changes not staged for commit). Jak je tohle možné? Věc se má tak, že Git po spuštění příkazu `git add` připraví soubor k zapsání ve přesně tak, jak vypadá v daném okamžiku. Pokud nyní revizi zapíšete, bude obsahovat soubor `benchmarks.rb` tak, jak vypadal, když jste naposledy spustili příkaz `git add`, nikoli v té podobě, kterou měl v pracovním adresáři v okamžiku, když jste spustili příkaz `git commit`. Pokud upravíte soubor po provedení příkazu `git add`, je třeba spustit `git add` ještě jednou, aby byla připravena aktuální verze souboru:
 
 	$ git add benchmarks.rb
 	$ git status
@@ -153,18 +153,18 @@ Co to má být? Soubor `benchmarks.rb` je nyní uveden jak v části připraveno
 
 ### Ignorované soubory ###
 
-Často se ve vašem adresáři vyskytne skupina souborů, u nichž nebudete chtít, aby je Git automaticky přidával nebo aby je vůbec uváděl jako nesledované. Jedná se většinou o automaticky vygenerované soubory, jako soubory log nebo soubory vytvořené sestavovacím systémem. V takovém případě můžete vytvořit soubor `.gitignore`, který specifikuje ignorované soubory. Tady je malý příklad souboru `.gitignore`:
+Ve vašem adresáři se často vyskytne skupina souborů, u nichž nebudete chtít, aby je Git automaticky přidával nebo aby je vůbec uváděl jako nesledované. Jedná se většinou o automaticky vygenerované soubory, jako soubory log nebo soubory vytvořené při překladu. V takových případech můžete vytvořit soubor `.gitignore` se seznamem masek pro ignorované soubory. Tady je malý příklad souboru `.gitignore`:
 
 	$ cat .gitignore
 	*.[oa]
 	*~
 
-První řádek říká systému Git, že má ignorovat všechny soubory končící na `.o` nebo `.a` – objektové a archivní soubory, které mohou být výsledkem vytváření kódu. Druhý řádek systému Git říká, aby ignoroval všechny soubory končící vlnovkou (`~`), již mnoho textových editorů (např. Emacs) používá k označení dočasných souborů. Můžete rovněž přidat adresář `log`, `tmp` nebo `pid`, automaticky vygenerovanou dokumentaci apod. Nastavit soubor `.gitignore`, ještě než se pustíte do práce, bývá většinou dobrý nápad. Alespoň se vám nestane, že byste nedopatřením zapsali také soubory, o které v repozitáři Git nestojíte.
+První řádek říká systému Git, že má ignorovat všechny soubory končící na `.o` nebo `.a` – *objekty* a *archivní* soubory, které mohou být výsledkem překladu. Druhý řádek systému Git říká, aby ignoroval všechny soubory končící vlnovkou (`~`), kterou mnoho textových editorů (např. Emacs) používá k označení dočasných souborů. Můžete rovněž přidat adresář `log`, `tmp` nebo `pid`, automaticky vygenerovanou dokumentaci a podobné. Vytvoření a naplnění souboru `.gitignore` ještě dříve než se pustíte do práce, bývá většinou dobrý nápad. Alespoň se vám nestane, že byste nedopatřením zapsali také soubory, o které v repozitáři Git nestojíte.
 
-Toto jsou pravidla pro masky, které můžete použít v souboru `.gitignore`:
+Pravidla pro masky, které můžete použít v souboru `.gitignore`, jsou následující:
 
 *	Prázdné řádky nebo řádky začínající znakem `#` budou ignorovány.
-*	Standardní masku souborů.
+*	Standardní masky souborů.
 *	Chcete-li označit adresář, můžete masku zakončit lomítkem (`/`).
 *	Pokud řádek začíná vykřičníkem (`!`), maska na něm je negována.
 
@@ -190,7 +190,7 @@ Tady je další příklad souboru `.gitignore`:
 
 ### Zobrazení připravených a nepřipravených změn ###
 
-Je-li pro vaše potřeby příkaz `git status` příliš neurčitý – chcete přesně vědět, co jste změnili, nejen které soubory – můžete použít příkaz `git diff`. Podrobněji se budeme příkazu `git diff` věnovat později. Vy ho však nejspíš budete nejčastěji využívat k zodpovězení těchto dvou otázek: Co jste změnili, ale ještě nepřipravili k zapsání? A co jste připravili a nyní může být zapsáno? Zatímco příkaz `git status` vám tyto otázky zodpoví velmi obecně, příkaz `git diff` přesně zobrazí přidané a odstraněné řádky – tedy samotná záplata.
+Je-li pro vaše potřeby příkaz `git status` příliš neurčitý – chcete přesně vědět, co jste změnili, nejen které soubory – můžete použít příkaz `git diff`. Podrobněji se budeme příkazu `git diff` věnovat později. Vy ho však nejspíš budete nejčastěji využívat k zodpovězení těchto dvou otázek: Co jste změnili, ale ještě nepřipravili k zapsání? A co jste připravili a nyní může být zapsáno? Zatímco příkaz `git status` vám tyto otázky zodpoví velmi obecně, příkaz `git diff` přesně zobrazí přidané a odstraněné řádky – tedy samotnou záplatu.
 
 Řekněme, že znovu upravíte a připravíte soubor `README` a poté bez připravení upravíte soubor `benchmarks.rb`. Po spuštění příkazu `status` se zobrazí zhruba toto:
 
@@ -229,7 +229,7 @@ Chcete-li vidět, co jste změnili, avšak ještě nepřipravili k zapsání, za
 
 Tento příkaz srovná obsah vašeho pracovního adresáře a oblasti připravených změn. Výsledek vám ukáže provedené změny, které jste dosud nepřipravili k zapsání.
 
-Chcete-li vidět, co jste připravili a co bude součástí příští revize, použijte příkaz `git diff --cached`. (Ve verzích Git 1.6.1 a novějších můžete použít také příkaz `git diff --staged`, který se možná snáze pamatuje.) Tento příkaz srovná připravené změny s poslední revizí:
+Chcete-li vidět, co jste připravili a co bude součástí příští revize, použijte příkaz `git diff --cached`. (Ve verzích Git 1.6.1 a novějších můžete použít také příkaz `git diff --staged`, který se možná snáze pamatuje.) Tento příkaz srovná připravené změny (staged changes) s poslední revizí:
 
 	$ git diff --cached
 	diff --git a/README b/README
@@ -244,7 +244,7 @@ Chcete-li vidět, co jste připravili a co bude součástí příští revize, p
 	+
 	+Grit is a Ruby library for extracting information from a Git repository
 
-K tomu je třeba poznamenat, že příkaz `git diff` sám o sobě nezobrazí všechny změny provedené od poslední revize, ale jen změny, které zatím nejsou připraveny. To může být občas matoucí, protože pokud jste připravili všechny provedené změny, výstup příkazu `git diff` bude prázdný.
+K tomu je třeba poznamenat, že příkaz `git diff` sám o sobě nezobrazí všechny změny provedené od poslední revize, ale jen změny, které zatím nejsou připraveny. To může být občas matoucí, protože pokud jste připravili všechny provedené změny, bude výstup příkazu `git diff` prázdný.
 
 V dalším příkladu ukážeme situaci, kdy jste připravili soubor `benchmarks.rb` a poté ho znovu upravili. Příkaz `git diff` můžete nyní použít k zobrazení změn v souboru, které byly připraveny, a změn, které nejsou připraveny:
 
@@ -298,12 +298,12 @@ A příkaz `git diff --cached` ukáže změny, které už připraveny jsou:
 
 ### Zapisování změn ###
 
-Nyní, když jste seznam připravených změn nastavili podle svých představ, můžete začít zapisovat změny. Nezapomeňte, že všechno, co dosud nebylo připraveno k zapsání – všechny soubory, které jste vytvořili nebo změnili a na které jste po úpravách nepoužili příkaz `git add` – nebudou do revize zahrnuty. Zůstanou na vašem disku ve stavu „změněno“.
-Když jsme v našem případě naposledy spustili příkaz `git status`, viděli jste, že všechny soubory byly připraveny k zapsání. Nyní může proběhnout samotné zapsání změn. Nejjednodušším způsobem zapsání je zadat příkaz `git commit`:
+Nyní, když jste seznam připravených změn nastavili podle svých představ, můžete začít zapisovat změny. Nezapomeňte, že všechno, co dosud nebylo připraveno k zapsání – všechny soubory, které jste vytvořili nebo změnili a na které jste po úpravách nepoužili příkaz `git add` –, nebudou do revize zahrnuty. Zůstanou na vašem disku jako změněné soubory.
+Když jste v našem případě naposledy spustili příkaz `git status`, viděli jste, že všechny soubory byly připraveny k zapsání. Takže jste připraveni k samotnému zapsání změn. Nejjednodušší způsob zapsání změn spočívá v použití příkazu `git commit`:
 
 	$ git commit
 
-Po zadání příkazu se otevře zvolený editor. (Ten je nastaven proměnnou prostředí `$EDITOR` vašeho shellu. Většinou se bude jednat o editor vim nebo emacs, ale pomocí příkazu `git config --global core.editor` můžete nastavit i jakýkoli jiný – viz kapitola 1.)
+Po zadání příkazu se otevře vámi zvolený editor. (Ten je nastaven proměnnou prostředí `$EDITOR` vašeho shellu. Většinou se bude jednat o editor vim nebo emacs, ale pomocí příkazu `git config --global core.editor` můžete nastavit i jakýkoli jiný – viz *kapitola 1*.)
 
 Editor zobrazí následující text (tento příklad je z editoru Vim):
 
@@ -319,7 +319,7 @@ Editor zobrazí následující text (tento příklad je z editoru Vim):
 	~
 	".git/COMMIT_EDITMSG" 10L, 283C
 
-Jak vidíte, výchozí zpráva k revizi (commit message) obsahuje zakomentovaný aktuální výstup příkazu `git status` a nahoře jeden prázdný řádek. Tyto komentáře můžete odstranit a napsat vlastní zprávu k revizi, nebo je můžete v souboru ponechat, abyste si lépe vzpomněli, co bylo obsahem dané revize. (Chcete-li zařadit ještě podrobnější informace o tom, co jste měnili, můžete k příkazu `git commit` přidat parametr `-v`. V editoru se pak zobrazí také výstup „diff“ ke konkrétním změnám a vy přesně uvidíte, co bylo změněno.) Jakmile editor zavřete, Git vytvoří revizi se zprávou, kterou jste napsali (s odstraněnými komentáři a rozdíly).
+Jak vidíte, výchozí zpráva k revizi (commit message) obsahuje zakomentovaný aktuální výstup příkazu `git status` a nahoře jeden prázdný řádek. Tyto komentáře můžete odstranit a napsat vlastní zprávu k revizi, nebo je můžete v souboru ponechat, abyste si lépe vzpomněli, co bylo obsahem dané revize. (Chcete-li zařadit ještě podrobnější informace o tom, co jste měnili, můžete k příkazu `git commit` přidat parametr `-v`. V editoru se pak zobrazí také výstup rozdílů (diff) ke konkrétním změnám a vy přesně uvidíte, co bylo změněno.) Jakmile editor zavřete, Git vytvoří revizi se zprávou, kterou jste napsali (s odstraněnými komentáři a rozdíly).
 
 Zprávu k revizi můžete rovněž napsat do řádku k příkazu `commit`. Jako zprávu ji označíte tak, že před ni vložíte příznak `-m`:
 
@@ -328,13 +328,13 @@ Zprávu k revizi můžete rovněž napsat do řádku k příkazu `commit`. Jako
 	 2 files changed, 3 insertions(+)
 	 create mode 100644 README
 
-Nyní jste vytvořili svou první revizi! Vidíte, že se po zapsání revize zobrazil výpis s informacemi: do jaké větve jste revizi zapsali (hlavní, `master`), jaký kontrolní součet SHA-1 revize dostala (`463dc4f`), kolik souborů bylo změněno a statistiku přidaných a odstraněných řádků revize.
+Nyní jste vytvořili svou první revizi! Vidíte, že se po zapsání revize zobrazil výpis s informacemi: do jaké větve jste revizi zapsali (`master`), jaký je kontrolní součet SHA-1 revize (`463dc4f`), kolik souborů bylo změněno a statistiku přidaných a odstraněných řádků revize.
 
-Nezapomeňte, že revize zaznamená snímek projektu, jak je obsažen v oblasti připravených změn. Vše, co jste nepřipravili k zapsání, zůstane ve stavu „změněno“ na vašem disku. Chcete-li i tyto soubory přidat do své historie, zapište další revizi. Pokaždé, když zapíšete revizi, nahrajete snímek svého projektu, k němuž se můžete později vrátit nebo ho můžete použít k srovnání.
+Nezapomeňte, že revize zaznamená snímek projektu, jak je obsažen v oblasti připravených změn. Vše, co jste nepřipravili k zapsání, zůstane ve stavu změněno na vašem disku. Chcete-li i tyto soubory přidat do své historie, zapište další revizi. Pokaždé, když zapíšete revizi, nahrajete snímek svého projektu, k němuž se můžete později vrátit nebo ho můžete použít k srovnání.
 
 ### Přeskočení oblasti připravených změn ###
 
-Přestože může být oblast připravených změn opravdu užitečným nástrojem pro přesné vytváření revizí, je někdy při daném pracovním postupu zbytečným mezikrokem. Chcete-li oblast připravených změn úplně přeskočit, nabízí Git jednoduchou zkratku. Přidáte-li k příkazu `git commit` parametr `-a`, Git do revize automaticky zahrne každý soubor, který je sledován. Zcela tak odpadá potřeba zadávat příkaz `git add`:
+Přestože může být oblast připravených změn opravdu užitečným nástrojem pro přesné vytváření revizí, je někdy při daném pracovním postupu zbytečným mezikrokem. Chcete-li oblast připravených změn úplně přeskočit, nabízí Git jednoduchou zkratku. Přidáte-li k příkazu `git commit` parametr `-a`, Git do revize automaticky zahrne každý soubor, který je sledován. Odpadá potřeba zadávat příkaz `git add`:
 
 	$ git status
 	On branch master
@@ -349,13 +349,13 @@ Přestože může být oblast připravených změn opravdu užitečným nástroj
 	[master 83e38c7] added new benchmarks
 	 1 files changed, 5 insertions(+)
 
-Tímto způsobem není nutné provádět před zapsáním revize příkaz `git add` pro soubor `benchmarks.rb`.
+Povšimněte si, že kvůli souboru `benchmarks.rb` v tomto případě nemusíte před zapsáním revize provádět příkaz `git add`.
 
 ### Odstraňování souborů ###
 
 Chcete-li odstranit soubor ze systému Git, musíte ho odstranit ze sledovaných souborů (přesněji řečeno odstranit z oblasti připravených změn) a zapsat revizi. Odstranění provedete příkazem `git rm`, který odstraní soubor zároveň z vašeho pracovního adresáře, a proto ho už příště neuvidíte mezi nesledovanými soubory.
 
-Pokud soubor jednoduše odstraníte z pracovního adresáře, zobrazí se ve výpisu `git status` v části „Changes not staged for commit“ (tedy nepřipraveno):
+Pokud soubor jednoduše odstraníte z pracovního adresáře, zobrazí se ve výpisu `git status` v části „Changes not staged for commit“ (tedy *nepřipraveno*):
 
 	$ rm grit.gemspec
 	$ git status
@@ -380,7 +380,7 @@ Pokud nyní provedete příkaz `git rm`, bude k zapsání připraveno odstraněn
 	        deleted:    grit.gemspec
 
 
-Po příštím zapsání revize soubor zmizí a nebude sledován. Pokud už jste soubor upravili a přidali do indexu, musíte odstranění provést pomocí parametru `-f`. Jedná se o bezpečnostní funkci, jež má zabránit nechtěnému odstranění dat, která ještě nebyla nahrána do snímku, a nemohou proto být ze systému Git obnovena.
+Po příštím zapsání revize soubor zmizí a přestane být sledován. Pokud už jste soubor upravili a přidali do indexu, musíte odstranění provést pomocí parametru `-f`. Jedná se o bezpečnostní funkci, jež má zabránit nechtěnému odstranění dat, která ještě nebyla nahrána do snímku, a nemohou proto být ze systému Git obnovena.
 
 Další užitečnou možností, která se vám může hodit, je zachování souboru v pracovním stromě a odstranění z oblasti připravených změn. Soubor tak ponecháte na svém pevném disku, ale ukončíte jeho sledování systémem Git. To může být užitečné zejména v situaci, kdy něco zapomenete přidat do souboru `.gitignore`, a omylem to tak zahrnete do revize, např. velký log soubor nebo pár zkompilovaných souborů s příponou `.a`. V takovém případě použijte parametr `--cached`:
 
@@ -398,7 +398,7 @@ Tento příkaz odstraní všechny soubory, které končí vlnovkou (`~`).
 
 ### Přesouvání souborů ###
 
-Na rozdíl od ostatních systémů VCS nesleduje Git explicitně přesouvání souborů. Pokud přejmenujete v systému Git soubor, neuloží se žádná metadata s informací, že jste soubor přejmenovali. Git však používá jinou fintu, aby zjistil, že byl soubor přejmenován. Na ni se podíváme později.
+Na rozdíl od ostatních systémů pro správu verzí nesleduje Git explicitně přesouvání souborů. Pokud soubor v systému Git přejmenujete, neuloží se žádná metadata s informací, že jste soubor přejmenovali. Git však používá jinou fintu, aby zjistil, že byl soubor přejmenován. Na ni se podíváme později.
 
 Může se zdát zvláštní, že Git přesto používá příkaz `mv`. Chcete-li v systému Git přejmenovat soubor, můžete spustit třeba příkaz
 
@@ -431,7 +431,7 @@ Následující příklady ukazují velmi jednoduchý projekt pojmenovaný `simpl
 
 	git clone git://github.com/schacon/simplegit-progit.git
 
-Po zadání příkazu `git log` v tomto projektu byste měli dostat výstup, který vypadá zhruba následovně:
+Po zadání příkazu `git log` v tomto projektu byste měli dostat výstup, který vypadá zhruba takto:
 
 	$ git log
 	commit ca82a6dff817ec66f44342007202690a93763949
@@ -452,11 +452,11 @@ Po zadání příkazu `git log` v tomto projektu byste měli dostat výstup, kte
 
 	    first commit
 
-Ve výchozím nastavení a bez dalších parametrů vypíše příkaz `git log` revize provedené v daném repozitáři v obráceném chronologickém pořadí. Nejnovější revize tak budou uvedeny nahoře. Jak vidíte, tento příkaz vypíše všechny revize s jejich kontrolním součtem SHA-1, jménem a e-mailem autora, datem zápisu a zprávou k revizi.
+Ve výchozím nastavení a bez dalších parametrů vypíše příkaz `git log` revize provedené v daném repozitáři v obráceném chronologickém pořadí. Nejnovější revize tak budou uvedeny nahoře. Jak vidíte, tento příkaz vypíše všechny revize s jejich kontrolním součtem SHA-1, jménem a e-mailem autora, datem zápisu a zprávou o revizi.
 
-K příkazu `git log` je k dispozici velké množství nejrůznějších parametrů, díky nimž můžete najít přesně to, co hledáte. Vyjmenujme některé z nejčastěji používaných parametrů.
+K příkazu `git log` je k dispozici velké množství nejrůznějších parametrů, díky nimž můžete zobrazit přesně to, co potřebujete. Ukážeme si některé z nejpoužívanějších možností.
 
-Jedním z nejužitečnějších je parametr `-p`, který zobrazí rozdíly diff provedené v každé revizi. Můžete také použít parametr `-2`, který omezí výpis pouze na dva poslední záznamy:
+Jedním z nejužitečnějších je parametr `-p`, který zobrazí rozdíly (diff) provedené v každé revizi. Můžete také použít parametr `-2`, který omezí výpis pouze na dva poslední záznamy:
 
 	$ git log -p -2
 	commit ca82a6dff817ec66f44342007202690a93763949
@@ -591,7 +591,7 @@ Tabulka 2-1 uvádí některé užitečné parametry, které format akceptuje.
 	%cr	Datum autora revize, relativní
 	%s	Předmět
 
-Možná se ptáte, jaký je rozdíl mezi autorem a autorem revize. Autor je osoba, která práci původně napsala, zatímco autor revize je osoba, která práci zapsala do repozitáře. Pokud tedy pošlete záplatu k projektu a některý z ústředních členů (core members) ji použije, do výpisu se dostanete oba – vy jako autor a core member jako autor revize. K tomuto rozlišení se blíže dostaneme v kapitole 5.
+Možná se ptáte, jaký je rozdíl mezi *autorem* a *autorem revize*. *Autor* (author) je osoba, která práci původně napsala, zatímco *autor revize* (committer) je osoba, která práci zapsala do repozitáře. Pokud tedy pošlete záplatu k projektu a některý z ústředních členů (core members) ji použije, do výpisu se dostanete oba – vy jako autor a core member jako autor revize. K tomuto rozlišení se blíže dostaneme v *kapitole 5*.
 
 Parametry `oneline` a `format` jsou zvlášť užitečné ve spojení s další možností `log`u – parametrem `--graph`. Tento parametr vloží pěkný malý ASCII graf, znázorňující historii vaší větve a slučování, kterou si ukážeme na naší kopii repozitáře projektu Grit:
 
@@ -695,7 +695,7 @@ K dalším užitečným formátům patří `--date=iso` (ISO 8601), `--date=rfc`
 
 Pokud použijete příkaz `git log` bez určení času, uvažuje se čas odpovídající okamžiku spuštění na vašem počítači (používá stejný posun vůči UTC).
 
-Pokud například na vašem počítači spustíte `git log` v 09:00 a vaše časové pásmo je vůči greenwichskému času posunut o tři hodiny vpřed, pak se výsledek následujících dvou příkazů shoduje:
+Pokud například na vašem počítači spustíte `git log` v 09:00 a vaše časové pásmo je vůči greenwichskému času posunuto o tři hodiny vpřed, pak se výsledek následujících dvou příkazů shoduje:
 
     $ git log --after=2008-06-01 --before=2008-07-01
     $ git log --after="2008-06-01T09:00:00+0300" \

From 9efccf9f2876ee04e88515b8fb24e27e44c8f733 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Stian=20Dr=C3=B8bak?= <sum41rules4@hotmail.com>
Date: Mon, 4 Aug 2014 19:27:01 +0200
Subject: [PATCH 542/690] no-NB trans Chapter 2 Getting repository + 1 sub

---
 no-nb/02-git-basics/01-chapter2.markdown | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/no-nb/02-git-basics/01-chapter2.markdown b/no-nb/02-git-basics/01-chapter2.markdown
index b8642eb2e..bb023a44f 100644
--- a/no-nb/02-git-basics/01-chapter2.markdown
+++ b/no-nb/02-git-basics/01-chapter2.markdown
@@ -2,25 +2,25 @@
 
 Om du bare kan lese et kapitel for å komme i gang med Git, så er dette det kapitelet. Dette kapitellet dekker hver grunnlegende kommando du trenger for å gjøre største delen av ting du etterhvert vil bruke tiden din på å gjøre i Git. Ved slutten av dette kapitelet, så burde du være istand til å konfigurere og initiere et repository, begynne og stoppe overvåking av filer, og stage og commite endringer. Vi vil også vise deg hvordan sette opp Git til å ignorere visse filer og filmønstre, hvordan angre på feil fort og enkelt, hvordan se gjennom historien for prosjektet ditt og se på endringer mellom commiter, og hvordan pushe(dytte) endringer til eller pulle(dra) endringer fra en fjern repository.
 
-## Getting a Git Repository ##
+## Skaffe seg et Git Repository ##
 
-You can get a Git project using two main approaches. The first takes an existing project or directory and imports it into Git. The second clones an existing Git repository from another server.
+Du kan skaffe deg et Git prosjekt ved å bruke to hovedframganger. Den første tar et eksisterende prosjekt eller mappe og importerer det inn i Git. Den andre kloner et eksisterende Git repository fra en annen server.
 
-### Initializing a Repository in an Existing Directory ###
+### Initere et Repository i en Eksisterende Mappe ###
 
-If you’re starting to track an existing project in Git, you need to go to the project’s directory and type
+Om du begynner å spore et eksisterende prosjekt i Git, så trenger du å gå inn i projektets mappe og skrive
 
 	$ git init
 
-This creates a new subdirectory named `.git` that contains all of your necessary repository files — a Git repository skeleton. At this point, nothing in your project is tracked yet. (See *Chapter 9* for more information about exactly what files are contained in the `.git` directory you just created.)
+Dette lager en ny undermappe kalt `.git` som inneholder alle dine nødvendige repository filer – et Git repository skjellet. På dette tidspunktet, så er ingenting i prosjektet ditt overvåket enda. (See *Kapitel 9* for mer informasjon om nøyaktig hvile filer som finnes i `.git`mappen du akkurat lagde.)
 
-If you want to start version-controlling existing files (as opposed to an empty directory), you should probably begin tracking those files and do an initial commit. You can accomplish that with a few `git add` commands that specify the files you want to track, followed by a commit:
+Om du ønsker å starte versjonkontroll på eksisterende filer (imotsetning til en tom mappe), så burde du sannsynligvis begynne å overvåke de filene og gjøre en første commit. Du kan gjøre det med noen få `git add` kommandoer som spesifiserer filene du ønsker å overvåke, fulgt med en commit:
 
 	$ git add *.c
 	$ git add README
 	$ git commit -m 'initial project version'
 
-We’ll go over what these commands do in just a minute. At this point, you have a Git repository with tracked files and an initial commit.
+Vi vil gæ over hva disse kommandoene gjør straks. Nå har du et Git repository med overvåkedne filer og en første kommit.
 
 ### Cloning an Existing Repository ###
 

From ca3f3de73aa1303ba9f1afb1197e2cc6d8b2654e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Stian=20Dr=C3=B8bak?= <sum41rules4@hotmail.com>
Date: Mon, 4 Aug 2014 23:34:17 +0200
Subject: [PATCH 543/690] no-NB updated the non-translated text to newer rev

---
 no-nb/02-git-basics/01-chapter2.markdown      | 445 +++++++++++-------
 no-nb/03-git-branching/01-chapter3.markdown   | 200 ++++----
 no-nb/04-git-server/01-chapter4.markdown      | 221 ++++-----
 no-nb/05-distributed-git/01-chapter5.markdown |  47 +-
 no-nb/06-git-tools/01-chapter6.markdown       |  84 ++--
 no-nb/07-customizing-git/01-chapter7.markdown | 129 +++--
 .../01-chapter8.markdown                      |  53 +--
 no-nb/09-git-internals/01-chapter9.markdown   |  84 ++--
 8 files changed, 690 insertions(+), 573 deletions(-)

diff --git a/no-nb/02-git-basics/01-chapter2.markdown b/no-nb/02-git-basics/01-chapter2.markdown
index bb023a44f..04d6eb7a3 100644
--- a/no-nb/02-git-basics/01-chapter2.markdown
+++ b/no-nb/02-git-basics/01-chapter2.markdown
@@ -54,39 +54,40 @@ Figure 2-1. The lifecycle of the status of your files.
 The main tool you use to determine which files are in which state is the `git status` command. If you run this command directly after a clone, you should see something like this:
 
 	$ git status
-	# On branch master
+	On branch master
 	nothing to commit, working directory clean
 
-This means you have a clean working directory — in other words, there are no tracked and modified files. Git also doesn’t see any untracked files, or they would be listed here. Finally, the command tells you which branch you’re on. For now, that is always `master`, which is the default; you won’t worry about it here. The next chapter will go over branches and references in detail.
+This means you have a clean working directory — in other words, no tracked files are modified. Git also doesn’t see any untracked files, or they would be listed here. Finally, the command tells you which branch you’re on. For now, that is always `master`, which is the default; you won’t worry about it here. The next chapter will go over branches and references in detail.
 
-Let’s say you add a new file to your project, a simple README file. If the file didn’t exist before, and you run `git status`, you see your untracked file like so:
+Let’s say you add a new file to your project, a simple `README` file. If the file didn’t exist before, and you run `git status`, you see your untracked file like so:
 
 	$ vim README
 	$ git status
-	# On branch master
-	# Untracked files:
-	#   (use "git add <file>..." to include in what will be committed)
-	#
-	#	README
+	On branch master
+	Untracked files:
+	  (use "git add <file>..." to include in what will be committed)
+	
+	        README
+
 	nothing added to commit but untracked files present (use "git add" to track)
 
-You can see that your new README file is untracked, because it’s under the “Untracked files” heading in your status output. Untracked basically means that Git sees a file you didn’t have in the previous snapshot (commit); Git won’t start including it in your commit snapshots until you explicitly tell it to do so. It does this so you don’t accidentally begin including generated binary files or other files that you did not mean to include. You do want to start including README, so let’s start tracking the file.
+You can see that your new `README` file is untracked, because it’s under the “Untracked files” heading in your status output. Untracked basically means that Git sees a file you didn’t have in the previous snapshot (commit); Git won’t start including it in your commit snapshots until you explicitly tell it to do so. It does this so you don’t accidentally begin including generated binary files or other files that you did not mean to include. You do want to start including README, so let’s start tracking the file.
 
 ### Tracking New Files ###
 
-In order to begin tracking a new file, you use the command `git add`. To begin tracking the README file, you can run this:
+In order to begin tracking a new file, you use the command `git add`. To begin tracking the `README` file, you can run this:
 
 	$ git add README
 
-If you run your status command again, you can see that your README file is now tracked and staged:
+If you run your status command again, you can see that your `README` file is now tracked and staged:
 
 	$ git status
-	# On branch master
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#	new file:   README
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        new file:   README
+	
 
 You can tell that it’s staged because it’s under the “Changes to be committed” heading. If you commit at this point, the version of the file at the time you ran `git add` is what will be in the historical snapshot. You may recall that when you ran `git init` earlier, you then ran `git add (files)` — that was to begin tracking files in your directory. The `git add` command takes a path name for either a file or a directory; if it’s a directory, the command adds all the files in that directory recursively.
 
@@ -95,58 +96,60 @@ You can tell that it’s staged because it’s under the “Changes to be commit
 Let’s change a file that was already tracked. If you change a previously tracked file called `benchmarks.rb` and then run your `status` command again, you get something that looks like this:
 
 	$ git status
-	# On branch master
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#	new file:   README
-	#
-	# Changes not staged for commit:
-	#   (use "git add <file>..." to update what will be committed)
-	#
-	#	modified:   benchmarks.rb
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        new file:   README
+
+	Changes not staged for commit:
+	  (use "git add <file>..." to update what will be committed)
+	  (use "git checkout -- <file>..." to discard changes in working directory)
+	
+	        modified:   benchmarks.rb
+	
 
 The `benchmarks.rb` file appears under a section named “Changes not staged for commit” — which means that a file that is tracked has been modified in the working directory but not yet staged. To stage it, you run the `git add` command (it’s a multipurpose command — you use it to begin tracking new files, to stage files, and to do other things like marking merge-conflicted files as resolved). Let’s run `git add` now to stage the `benchmarks.rb` file, and then run `git status` again:
 
 	$ git add benchmarks.rb
 	$ git status
-	# On branch master
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#	new file:   README
-	#	modified:   benchmarks.rb
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        new file:   README
+	        modified:   benchmarks.rb
+	
 
 Both files are staged and will go into your next commit. At this point, suppose you remember one little change that you want to make in `benchmarks.rb` before you commit it. You open it again and make that change, and you’re ready to commit. However, let’s run `git status` one more time:
 
 	$ vim benchmarks.rb
 	$ git status
-	# On branch master
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#	new file:   README
-	#	modified:   benchmarks.rb
-	#
-	# Changes not staged for commit:
-	#   (use "git add <file>..." to update what will be committed)
-	#
-	#	modified:   benchmarks.rb
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        new file:   README
+	        modified:   benchmarks.rb
+	
+	Changes not staged for commit:
+	  (use "git add <file>..." to update what will be committed)
+	  (use "git checkout -- <file>..." to discard changes in working directory)
+	
+	        modified:   benchmarks.rb
+	
 
 What the heck? Now `benchmarks.rb` is listed as both staged and unstaged. How is that possible? It turns out that Git stages a file exactly as it is when you run the `git add` command. If you commit now, the version of `benchmarks.rb` as it was when you last ran the `git add` command is how it will go into the commit, not the version of the file as it looks in your working directory when you run `git commit`. If you modify a file after you run `git add`, you have to run `git add` again to stage the latest version of the file:
 
 	$ git add benchmarks.rb
 	$ git status
-	# On branch master
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#	new file:   README
-	#	modified:   benchmarks.rb
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        new file:   README
+	        modified:   benchmarks.rb
+	
 
 ### Ignoring Files ###
 
@@ -180,6 +183,10 @@ Here is another example `.gitignore` file:
 	build/
 	# ignore doc/notes.txt, but not doc/server/arch.txt
 	doc/*.txt
+	# ignore all .txt files in the doc/ directory
+	doc/**/*.txt
+
+A `**/` pattern is available in Git since version 1.8.2.
 
 ### Viewing Your Staged and Unstaged Changes ###
 
@@ -188,17 +195,18 @@ If the `git status` command is too vague for you — you want to know exactly wh
 Let’s say you edit and stage the `README` file again and then edit the `benchmarks.rb` file without staging it. If you run your `status` command, you once again see something like this:
 
 	$ git status
-	# On branch master
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#	new file:   README
-	#
-	# Changes not staged for commit:
-	#   (use "git add <file>..." to update what will be committed)
-	#
-	#	modified:   benchmarks.rb
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        new file:   README
+	
+	Changes not staged for commit:
+	  (use "git add <file>..." to update what will be committed)
+	  (use "git checkout -- <file>..." to discard changes in working directory)
+	
+	        modified:   benchmarks.rb
+	
 
 To see what you’ve changed but not yet staged, type `git diff` with no other arguments:
 
@@ -243,16 +251,18 @@ For another example, if you stage the `benchmarks.rb` file and then edit it, you
 	$ git add benchmarks.rb
 	$ echo '# test line' >> benchmarks.rb
 	$ git status
-	# On branch master
-	#
-	# Changes to be committed:
-	#
-	#	modified:   benchmarks.rb
-	#
-	# Changes not staged for commit:
-	#
-	#	modified:   benchmarks.rb
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        modified:   benchmarks.rb
+	
+	Changes not staged for commit:
+	  (use "git add <file>..." to update what will be committed)
+	  (use "git checkout -- <file>..." to discard changes in working directory)
+	
+	        modified:   benchmarks.rb
+	
 
 Now you can use `git diff` to see what is still unstaged
 
@@ -301,10 +311,9 @@ The editor displays the following text (this example is a Vim screen):
 	# with '#' will be ignored, and an empty message aborts the commit.
 	# On branch master
 	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
 	#       new file:   README
 	#       modified:   benchmarks.rb
+	#
 	~
 	~
 	~
@@ -315,8 +324,8 @@ You can see that the default commit message contains the latest output of the `g
 Alternatively, you can type your commit message inline with the `commit` command by specifying it after a `-m` flag, like this:
 
 	$ git commit -m "Story 182: Fix benchmarks for speed"
-	[master]: created 463dc4f: "Fix benchmarks for speed"
-	 2 files changed, 3 insertions(+), 0 deletions(-)
+	[master 463dc4f] Story 182: Fix benchmarks for speed
+	 2 files changed, 3 insertions(+)
 	 create mode 100644 README
 
 Now you’ve created your first commit! You can see that the commit has given you some output about itself: which branch you committed to (`master`), what SHA-1 checksum the commit has (`463dc4f`), how many files were changed, and statistics about lines added and removed in the commit.
@@ -328,15 +337,17 @@ Remember that the commit records the snapshot you set up in your staging area. A
 Although it can be amazingly useful for crafting commits exactly how you want them, the staging area is sometimes a bit more complex than you need in your workflow. If you want to skip the staging area, Git provides a simple shortcut. Providing the `-a` option to the `git commit` command makes Git automatically stage every file that is already tracked before doing the commit, letting you skip the `git add` part:
 
 	$ git status
-	# On branch master
-	#
-	# Changes not staged for commit:
-	#
-	#	modified:   benchmarks.rb
-	#
+	On branch master
+	Changes not staged for commit:
+	  (use "git add <file>..." to update what will be committed)
+	  (use "git checkout -- <file>..." to discard changes in working directory)
+	
+	        modified:   benchmarks.rb
+	
+	no changes added to commit (use "git add" and/or "git commit -a")
 	$ git commit -a -m 'added new benchmarks'
 	[master 83e38c7] added new benchmarks
-	 1 files changed, 5 insertions(+), 0 deletions(-)
+	 1 files changed, 5 insertions(+)
 
 Notice how you don’t have to run `git add` on the `benchmarks.rb` file in this case before you commit.
 
@@ -348,30 +359,30 @@ If you simply remove the file from your working directory, it shows up under the
 
 	$ rm grit.gemspec
 	$ git status
-	# On branch master
-	#
-	# Changes not staged for commit:
-	#   (use "git add/rm <file>..." to update what will be committed)
-	#
-	#       deleted:    grit.gemspec
-	#
+	On branch master
+	Changes not staged for commit:
+	  (use "git add/rm <file>..." to update what will be committed)
+	  (use "git checkout -- <file>..." to discard changes in working directory)
+	
+	        deleted:    grit.gemspec
+	
+	no changes added to commit (use "git add" and/or "git commit -a")
 
 Then, if you run `git rm`, it stages the file’s removal:
 
 	$ git rm grit.gemspec
 	rm 'grit.gemspec'
 	$ git status
-	# On branch master
-	#
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#       deleted:    grit.gemspec
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        deleted:    grit.gemspec
+	
 
 The next time you commit, the file will be gone and no longer tracked. If you modified the file and added it to the index already, you must force the removal with the `-f` option. This is a safety feature to prevent accidental removal of data that hasn’t yet been recorded in a snapshot and that can’t be recovered from Git.
 
-Another useful thing you may want to do is to keep the file in your working tree but remove it from your staging area. In other words, you may want to keep the file on your hard drive but not have Git track it anymore. This is particularly useful if you forgot to add something to your `.gitignore` file and accidentally added it, like a large log file or a bunch of `.a` compiled files. To do this, use the `--cached` option:
+Another useful thing you may want to do is to keep the file in your working tree but remove it from your staging area. In other words, you may want to keep the file on your hard drive but not have Git track it anymore. This is particularly useful if you forgot to add something to your `.gitignore` file and accidentally staged it, like a large log file or a bunch of `.a` compiled files. To do this, use the `--cached` option:
 
 	$ git rm --cached readme.txt
 
@@ -379,7 +390,7 @@ You can pass files, directories, and file-glob patterns to the `git rm` command.
 
 	$ git rm log/\*.log
 
-Note the backslash (`\`) in front of the `*`. This is necessary because Git does its own filename expansion in addition to your shell’s filename expansion. This command removes all files that have the `.log` extension in the `log/` directory. Or, you can do something like this:
+Note the backslash (`\`) in front of the `*`. This is necessary because Git does its own filename expansion in addition to your shell’s filename expansion. On Windows with the system console, the backslash must be omitted. This command removes all files that have the `.log` extension in the `log/` directory. Or, you can do something like this:
 
 	$ git rm \*~
 
@@ -395,22 +406,20 @@ Thus it’s a bit confusing that Git has a `mv` command. If you want to rename a
 
 and it works fine. In fact, if you run something like this and look at the status, you’ll see that Git considers it a renamed file:
 
-	$ git mv README.txt README
+	$ git mv README README.txt
 	$ git status
-	# On branch master
-	# Your branch is ahead of 'origin/master' by 1 commit.
-	#
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#       renamed:    README.txt -> README
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        renamed:    README -> README.txt
+	
 
 However, this is equivalent to running something like this:
 
-	$ mv README.txt README
-	$ git rm README.txt
-	$ git add README
+	$ mv README README.txt
+	$ git rm README
+	$ git add README.txt
 
 Git figures out that it’s a rename implicitly, so it doesn’t matter if you rename a file that way or with the `mv` command. The only real difference is that `mv` is one command instead of three — it’s a convenience function. More important, you can use any tool you like to rename a file, and address the add/rm later, before you commit.
 
@@ -460,11 +469,13 @@ One of the more helpful options is `-p`, which shows the diff introduced in each
 	index a874b73..8f94139 100644
 	--- a/Rakefile
 	+++ b/Rakefile
-	@@ -5,7 +5,7 @@ require 'rake/gempackagetask'
+	@@ -5,5 +5,5 @@ require 'rake/gempackagetask'
 	 spec = Gem::Specification.new do |s|
+	     s.name      =   "simplegit"
 	-    s.version   =   "0.1.0"
 	+    s.version   =   "0.1.1"
 	     s.author    =   "Scott Chacon"
+	     s.email     =   "schacon@gee-mail.com
 
 	commit 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7
 	Author: Scott Chacon <schacon@gee-mail.com>
@@ -488,6 +499,27 @@ One of the more helpful options is `-p`, which shows the diff introduced in each
 	\ No newline at end of file
 
 This option displays the same information but with a diff directly following each entry. This is very helpful for code review or to quickly browse what happened during a series of commits that a collaborator has added.
+
+Sometimes it's easier to review changes on the word level rather than on the line level. There is a `--word-diff` option available in Git, that you can append to the `git log -p` command to get word diff instead of normal line by line diff. Word diff format is quite useless when applied to source code, but it comes in handy when applied to large text files, like books or your dissertation. Here is an example:
+
+	$ git log -U1 --word-diff
+	commit ca82a6dff817ec66f44342007202690a93763949
+	Author: Scott Chacon <schacon@gee-mail.com>
+	Date:   Mon Mar 17 21:52:11 2008 -0700
+
+	    changed the version number
+
+	diff --git a/Rakefile b/Rakefile
+	index a874b73..8f94139 100644
+	--- a/Rakefile
+	+++ b/Rakefile
+	@@ -7,3 +7,3 @@ spec = Gem::Specification.new do |s|
+	    s.name      =   "simplegit"
+	    s.version   =   [-"0.1.0"-]{+"0.1.1"+}
+	    s.author    =   "Scott Chacon"
+
+As you can see, there is no added and removed lines in this output as in a normal diff. Changes are shown inline instead. You can see the added word enclosed in `{+ +}` and removed one enclosed in `[- -]`. You may also want to reduce the usual three lines context in diff output to only one line, as the context is now words, not lines. You can do this with `-U1` as we did in the example above.
+
 You can also use a series of summarizing options with `git log`. For example, if you want to see some abbreviated stats for each commit, you can use the `--stat` option:
 
 	$ git log --stat
@@ -498,7 +530,7 @@ You can also use a series of summarizing options with `git log`. For example, if
 	    changed the version number
 
 	 Rakefile |    2 +-
-	 1 files changed, 1 insertions(+), 1 deletions(-)
+	 1 file changed, 1 insertion(+), 1 deletion(-)
 
 	commit 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7
 	Author: Scott Chacon <schacon@gee-mail.com>
@@ -507,7 +539,7 @@ You can also use a series of summarizing options with `git log`. For example, if
 	    removed unnecessary test code
 
 	 lib/simplegit.rb |    5 -----
-	 1 files changed, 0 insertions(+), 5 deletions(-)
+	 1 file changed, 5 deletions(-)
 
 	commit a11bef06a3f659402fe7563abf99ad00de2209e6
 	Author: Scott Chacon <schacon@gee-mail.com>
@@ -518,7 +550,7 @@ You can also use a series of summarizing options with `git log`. For example, if
 	 README           |    6 ++++++
 	 Rakefile         |   23 +++++++++++++++++++++++
 	 lib/simplegit.rb |   25 +++++++++++++++++++++++++
-	 3 files changed, 54 insertions(+), 0 deletions(-)
+	 3 files changed, 54 insertions(+)
 
 As you can see, the `--stat` option prints below each commit entry a list of modified files, how many files were changed, and how many lines in those files were added and removed. It also puts a summary of the information at the end.
 Another really useful option is `--pretty`. This option changes the log output to formats other than the default. A few prebuilt options are available for you to use. The `oneline` option prints each commit on a single line, which is useful if you’re looking at a lot of commits. In addition, the `short`, `full`, and `fuller` options show the output in roughly the same format but with less or more information, respectively:
@@ -537,6 +569,11 @@ The most interesting option is `format`, which allows you to specify your own lo
 
 Table 2-1 lists some of the more useful options that format takes.
 
+<!-- Attention to translators: this is a table declaration.
+The lines must be formatted as follows
+<TAB><First column text><TAB><Second column text>
+-->
+
 	Option	Description of Output
 	%H	Commit hash
 	%h	Abbreviated commit hash
@@ -546,7 +583,7 @@ Table 2-1 lists some of the more useful options that format takes.
 	%p	Abbreviated parent hashes
 	%an	Author name
 	%ae	Author e-mail
-	%ad	Author date (format respects the –date= option)
+	%ad	Author date (format respects the --date= option)
 	%ar	Author date, relative
 	%cn	Committer name
 	%ce	Committer email
@@ -556,7 +593,7 @@ Table 2-1 lists some of the more useful options that format takes.
 
 You may be wondering what the difference is between _author_ and _committer_. The _author_ is the person who originally wrote the patch, whereas the _committer_ is the person who last applied the patch. So, if you send in a patch to a project and one of the core members applies the patch, both of you get credit — you as the author and the core member as the committer. We’ll cover this distinction a bit more in *Chapter 5*.
 
-The `oneline` and `format` options are particularly useful with another `log` option called `--graph`. This option adds a nice little ASCII graph showing your branch and merge history, which we can see our copy of the Grit project repository:
+The `oneline` and `format` options are particularly useful with another `log` option called `--graph`. This option adds a nice little ASCII graph showing your branch and merge history, which we can see in our copy of the Grit project repository:
 
 	$ git log --pretty=format:"%h %s" --graph
 	* 2d3acf9 ignore errors from SIGCHLD on trap
@@ -570,10 +607,16 @@ The `oneline` and `format` options are particularly useful with another `log` op
 	* d6016bc require time for xmlschema
 	*  11d191e Merge branch 'defunkt' into local
 
-Those are only some simple output-formatting options to `git log` — there are many more. Table 2-2 lists the options we’ve covered so far and some other common formatting options that may be useful, along with how they change the output of the log command.
+Those are only some simple output-formatting options to `git log` — there are many more. Table 2-2 lists the options we’ve covered so far and some other common formatting options that may be useful, along with how they change the output of the `log` command.
+
+<!-- Attention to translators: this is a table declaration.
+The lines must be formatted as follows
+<TAB><First column text><TAB><Second column text>
+-->
 
 	Option	Description
 	-p	Show the patch introduced with each commit.
+	--word-diff	Show the patch in a word diff format.
 	--stat	Show statistics for files modified in each commit.
 	--shortstat	Display only the changed/insertions/deletions line from the --stat command.
 	--name-only	Show the list of files modified after the commit information.
@@ -582,10 +625,11 @@ Those are only some simple output-formatting options to `git log` — there are
 	--relative-date	Display the date in a relative format (for example, “2 weeks ago”) instead of using the full date format.
 	--graph	Display an ASCII graph of the branch and merge history beside the log output.
 	--pretty	Show commits in an alternate format. Options include oneline, short, full, fuller, and format (where you specify your own format).
+	--oneline	A convenience option short for `--pretty=oneline --abbrev-commit`.
 
 ### Limiting Log Output ###
 
-In addition to output-formatting options, `git log` takes a number of useful limiting options — that is, options that let you show only a subset of commits. You’ve seen one such option already — the `-2` option, which show only the last two commits. In fact, you can do `-<n>`, where `n` is any integer to show the last `n` commits. In reality, you’re unlikely to use that often, because Git by default pipes all output through a pager so you see only one page of log output at a time.
+In addition to output-formatting options, `git log` takes a number of useful limiting options — that is, options that let you show only a subset of commits. You’ve seen one such option already — the `-2` option, which shows only the last two commits. In fact, you can do `-<n>`, where `n` is any integer to show the last `n` commits. In reality, you’re unlikely to use that often, because Git by default pipes all output through a pager so you see only one page of log output at a time.
 
 However, the time-limiting options such as `--since` and `--until` are very useful. For example, this command gets the list of commits made in the last two weeks:
 
@@ -593,23 +637,75 @@ However, the time-limiting options such as `--since` and `--until` are very usef
 
 This command works with lots of formats — you can specify a specific date (“2008-01-15”) or a relative date such as “2 years 1 day 3 minutes ago”.
 
-You can also filter the list to commits that match some search criteria. The `--author` option allows you to filter on a specific author, and the `--grep` option lets you search for keywords in the commit messages. (Note that if you want to specify both author and grep options, you have to add `--all-match` or the command will match commits with either.)
+You can also filter the list to commits that match some search criteria. The `--author` option allows you to filter on a specific author, and the `--grep` option lets you search for keywords in the commit messages. (Note that if you specify both author and grep options, the command will match commits with both.)
+
+If you want to specify multiple grep options, you have to add `--all-match` or the command will match commits with either.
 
 The last really useful option to pass to `git log` as a filter is a path. If you specify a directory or file name, you can limit the log output to commits that introduced a change to those files. This is always the last option and is generally preceded by double dashes (`--`) to separate the paths from the options.
 
 In Table 2-3 we’ll list these and a few other common options for your reference.
 
+<!-- Attention to translators: this is a table declaration.
+The lines must be formatted as follows
+<TAB><First column text><TAB><Second column text>
+-->
+
 	Option	Description
 	-(n)	Show only the last n commits
-	--since, --after	Limit the commits to those made after the specified date.
-	--until, --before	Limit the commits to those made before the specified date.
+	--since, --after	Limit the commits to those whose CommitDate was made on-or-after the specified date/time.
+	--until, --before	Limit the commits to those whose CommitDate was made on-or-before the specified date/time.
 	--author	Only show commits in which the author entry matches the specified string.
 	--committer	Only show commits in which the committer entry matches the specified string.
 
-For example, if you want to see which commits modifying test files in the Git source code history were committed by Junio Hamano and were not merges in the month of October 2008, you can run something like this:
 
-	$ git log --pretty="%h - %s" --author=gitster --since="2008-10-01" \
-	   --before="2008-11-01" --no-merges -- t/
+### Limiting Log Output according to Date/Time ###
+
+To determine which commits in the Git source code repository (git://git.kernel.org/pub/scm/git/git.git) have CommitDate on 2014-04-29 relative to your local timezone (as set on your computer), use
+
+    $ git log --after="2014-04-29 00:00:00" --before="2014-04-29 23:59:59" \
+      --pretty=fuller
+
+As the output will be different according to the timezone where it will be run, it's recommended to always use an absolute time such as ISO 8601 format (which includes timezone information) as argument to `--after` and `--before`, so that everone running the command will get the same repeatable results. 
+
+To obtain commits made at a specific instant in time (e.g. 29 April 2013 at 17:07:22 CET), we can use
+
+    $ git log  --after="2013-04-29T17:07:22+0200"      \
+              --before="2013-04-29T17:07:22+0200" --pretty=fuller
+    
+    commit de7c201a10857e5d424dbd8db880a6f24ba250f9
+    Author:     Ramkumar Ramachandra <artagnon@gmail.com>
+    AuthorDate: Mon Apr 29 18:19:37 2013 +0530
+    Commit:     Junio C Hamano <gitster@pobox.com>
+    CommitDate: Mon Apr 29 08:07:22 2013 -0700
+    
+        git-completion.bash: lexical sorting for diff.statGraphWidth
+        
+        df44483a (diff --stat: add config option to limit graph width,
+        2012-03-01) added the option diff.startGraphWidth to the list of
+        configuration variables in git-completion.bash, but failed to notice
+        that the list is sorted alphabetically.  Move it to its rightful place
+        in the list.
+        
+        Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
+        Signed-off-by: Junio C Hamano <gitster@pobox.com>
+
+The above times (`AuthorDate`, `CommitDate`) are displayed in default format (`--date=default`), which shows timezone information of respective author and commiter.
+
+Other useful formats include `--date=iso` (ISO 8601), `--date=rfc` (RFC 2822), `--date=raw` (seconds since the epoch (1970-01-01 UTC)) `--date=local` (times according to your local timezone) as well as `--date=relative` (e.g. "2 hours ago").
+
+When using `git log` without specifying time, the time defaults to the time at which the command is run on your computer (keeping the identical offset from UTC).
+
+For example, running a `git log` at 09:00 on your computer with your timezone currently 3 hours ahead of UTC, makes the following two commands equivalent:
+
+    $ git log --after=2008-06-01 --before=2008-07-01
+    $ git log --after="2008-06-01T09:00:00+0300" \
+        --before="2008-07-01T09:00:00+0300"
+
+As a final example, if you want to see which commits modifying test files in the Git source code history were committed by Junio Hamano with CommitDate being in the month of October 2008 (relative to the timezone of New York) and were not merges, you can run something like this:
+
+        $ git log --pretty="%h - %s" --author=gitster \
+           --after="2008-10-01T00:00:00-0400"         \
+          --before="2008-10-31T23:59:59-0400" --no-merges -- t/
 	5610e3b - Fix testcase failure when extended attribute
 	acd3b9e - Enhance hold_lock_file_for_{update,append}()
 	f563754 - demonstrate breakage of detached checkout wi
@@ -617,7 +713,7 @@ For example, if you want to see which commits modifying test files in the Git so
 	51a94af - Fix "checkout --track -b newbranch" on detac
 	b0ad11e - pull: allow "git pull origin $something:$cur
 
-Of the nearly 20,000 commits in the Git source code history, this command shows the 6 that match those criteria.
+Of the more than 36,000 commits in the Git source code history, this command shows the 6 that match those criteria.
 
 ### Using a GUI to Visualize History ###
 
@@ -656,31 +752,32 @@ The next two sections demonstrate how to wrangle your staging area and working d
 
 	$ git add .
 	$ git status
-	# On branch master
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#       modified:   README.txt
-	#       modified:   benchmarks.rb
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        modified:   README.txt
+	        modified:   benchmarks.rb
+	
 
 Right below the “Changes to be committed” text, it says "use `git reset HEAD <file>...` to unstage". So, let’s use that advice to unstage the `benchmarks.rb` file:
 
 	$ git reset HEAD benchmarks.rb
-	benchmarks.rb: locally modified
+	Unstaged changes after reset:
+	M       benchmarks.rb
 	$ git status
-	# On branch master
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#       modified:   README.txt
-	#
-	# Changes not staged for commit:
-	#   (use "git add <file>..." to update what will be committed)
-	#   (use "git checkout -- <file>..." to discard changes in working directory)
-	#
-	#       modified:   benchmarks.rb
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        modified:   README.txt
+	
+	Changes not staged for commit:
+	  (use "git add <file>..." to update what will be committed)
+	  (use "git checkout -- <file>..." to discard changes in working directory)
+	
+	        modified:   benchmarks.rb
+	
 
 The command is a bit strange, but it works. The `benchmarks.rb` file is modified but once again unstaged.
 
@@ -688,23 +785,23 @@ The command is a bit strange, but it works. The `benchmarks.rb` file is modified
 
 What if you realize that you don’t want to keep your changes to the `benchmarks.rb` file? How can you easily unmodify it — revert it back to what it looked like when you last committed (or initially cloned, or however you got it into your working directory)? Luckily, `git status` tells you how to do that, too. In the last example output, the unstaged area looks like this:
 
-	# Changes not staged for commit:
-	#   (use "git add <file>..." to update what will be committed)
-	#   (use "git checkout -- <file>..." to discard changes in working directory)
-	#
-	#       modified:   benchmarks.rb
-	#
+	Changes not staged for commit:
+	  (use "git add <file>..." to update what will be committed)
+	  (use "git checkout -- <file>..." to discard changes in working directory)
+	
+	        modified:   benchmarks.rb
+	
 
 It tells you pretty explicitly how to discard the changes you’ve made (at least, the newer versions of Git, 1.6.1 and later, do this — if you have an older version, we highly recommend upgrading it to get some of these nicer usability features). Let’s do what it says:
 
 	$ git checkout -- benchmarks.rb
 	$ git status
-	# On branch master
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#       modified:   README.txt
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        modified:   README.txt
+	
 
 You can see that the changes have been reverted. You should also realize that this is a dangerous command: any changes you made to that file are gone — you just copied another file over it. Don’t ever use this command unless you absolutely know that you don’t want the file. If you just need to get it out of the way, we’ll go over stashing and branching in the next chapter; these are generally better ways to go.
 
@@ -720,12 +817,12 @@ Managing remote repositories includes knowing how to add remote repositories, re
 To see which remote servers you have configured, you can run the `git remote` command. It lists the shortnames of each remote handle you’ve specified. If you’ve cloned your repository, you should at least see *origin* — that is the default name Git gives to the server you cloned from:
 
 	$ git clone git://github.com/schacon/ticgit.git
-	Initialized empty Git repository in /private/tmp/ticgit/.git/
-	remote: Counting objects: 595, done.
-	remote: Compressing objects: 100% (269/269), done.
-	remote: Total 595 (delta 255), reused 589 (delta 253)
-	Receiving objects: 100% (595/595), 73.31 KiB | 1 KiB/s, done.
-	Resolving deltas: 100% (255/255), done.
+	Cloning into 'ticgit'...
+	remote: Reusing existing pack: 1857, done.
+	remote: Total 1857 (delta 0), reused 0 (delta 0)
+	Receiving objects: 100% (1857/1857), 374.35 KiB | 193.00 KiB/s, done.
+	Resolving deltas: 100% (772/772), done.
+	Checking connectivity... done.
 	$ cd ticgit
 	$ git remote
 	origin
@@ -733,7 +830,8 @@ To see which remote servers you have configured, you can run the `git remote` co
 You can also specify `-v`, which shows you the URL that Git has stored for the shortname to be expanded to:
 
 	$ git remote -v
-	origin	git://github.com/schacon/ticgit.git
+	origin  git://github.com/schacon/ticgit.git (fetch)
+	origin  git://github.com/schacon/ticgit.git (push)
 
 If you have more than one remote, the command lists them all. For example, my Grit repository looks something like this.
 
@@ -745,7 +843,7 @@ If you have more than one remote, the command lists them all. For example, my Gr
 	koke      git://github.com/koke/grit.git
 	origin    git@github.com:mojombo/grit.git
 
-This means we can pull contributions from any of these users pretty easily. But notice that only the origin remote is an SSH URL, so it’s the only one I can push to (we’ll cover why this is in *Chapter 4*).
+This means I can pull contributions from any of these users pretty easily. But notice that only the origin remote is an SSH URL, so it’s the only one I can push to (we’ll cover why this is in *Chapter 4*).
 
 ### Adding Remote Repositories ###
 
@@ -758,7 +856,7 @@ I’ve mentioned and given some demonstrations of adding remote repositories in
 	origin	git://github.com/schacon/ticgit.git
 	pb	git://github.com/paulboone/ticgit.git
 
-Now you can use the string `pb` on the command line in lieu of the whole URL. For example, if you want to fetch all the information that Paul has but that you don’t yet have in your repository, you can run git fetch pb:
+Now you can use the string `pb` on the command line in lieu of the whole URL. For example, if you want to fetch all the information that Paul has but that you don’t yet have in your repository, you can run `git fetch pb`:
 
 	$ git fetch pb
 	remote: Counting objects: 58, done.
@@ -895,6 +993,7 @@ You can see the tag data along with the commit that was tagged by using the `git
 	Date:   Mon Feb 9 14:45:11 2009 -0800
 
 	my version 1.4
+
 	commit 15027957951b64cf874c3557a0f3547bd83b3ff6
 	Merge: 4a447f7... a6b4c97...
 	Author: Scott Chacon <schacon@gee-mail.com>
@@ -1001,7 +1100,7 @@ You can also tag commits after you’ve moved past them. Suppose your commit his
 
 Now, suppose you forgot to tag the project at `v1.2`, which was at the "updated rakefile" commit. You can add it after the fact. To tag that commit, you specify the commit checksum (or part of it) at the end of the command:
 
-	$ git tag -a v1.2 9fceb02
+	$ git tag -a v1.2 -m 'version 1.2' 9fceb02
 
 You can see that you’ve tagged the commit:
 
@@ -1060,9 +1159,9 @@ Before we finish this chapter on basic Git, a few little tips and tricks may mak
 
 ### Auto-Completion ###
 
-If you use the Bash shell, Git comes with a nice auto-completion script you can enable. Download the Git source code, and look in the `contrib/completion` directory; there should be a file called `git-completion.bash`. Copy this file to your home directory, and add this to your `.bashrc` file:
+If you use the Bash shell, Git comes with a nice auto-completion script you can enable. Download it directly from the Git source code at https://github.com/git/git/blob/master/contrib/completion/git-completion.bash . Copy this file to your home directory, and add this to your `.bashrc` file:
 
-	source ~/.git-completion.bash
+	source ~/git-completion.bash
 
 If you want to set up Git to automatically have Bash shell completion for all users, copy this script to the `/opt/local/etc/bash_completion.d` directory on Mac systems or to the `/etc/bash_completion.d/` directory on Linux systems. This is a directory of scripts that Bash will automatically load to provide shell completions.
 
diff --git a/no-nb/03-git-branching/01-chapter3.markdown b/no-nb/03-git-branching/01-chapter3.markdown
index de57576f7..adf1995d1 100644
--- a/no-nb/03-git-branching/01-chapter3.markdown
+++ b/no-nb/03-git-branching/01-chapter3.markdown
@@ -15,21 +15,21 @@ To visualize this, let’s assume that you have a directory containing three fil
 	$ git add README test.rb LICENSE
 	$ git commit -m 'initial commit of my project'
 
-When you create the commit by running `git commit`, Git checksums each subdirectory (in this case, just the root project directory) and stores those tree objects in the Git repository. Git then creates a commit object that has the metadata and a pointer to the root project tree so it can re-create that snapshot when needed.
+Running `git commit` checksums all project directories and stores them as `tree` objects in the Git repository. Git then creates a `commit` object that has the metadata and a pointer to the root project `tree` object so it can re-create that snapshot when needed.
 
 Your Git repository now contains five objects: one blob for the contents of each of your three files, one tree that lists the contents of the directory and specifies which file names are stored as which blobs, and one commit with the pointer to that root tree and all the commit metadata. Conceptually, the data in your Git repository looks something like Figure 3-1.
 
-Insert 18333fig0301.png 
+Insert 18333fig0301.png
 Figure 3-1. Single commit repository data.
 
 If you make some changes and commit again, the next commit stores a pointer to the commit that came immediately before it. After two more commits, your history might look something like Figure 3-2.
 
-Insert 18333fig0302.png 
+Insert 18333fig0302.png
 Figure 3-2. Git object data for multiple commits.
 
-A branch in Git is simply a lightweight movable pointer to one of these commits. The default branch name in Git is master. As you initially make commits, you’re given a master branch that points to the last commit you made. Every time you commit, it moves forward automatically.
+A branch in Git is simply a lightweight movable pointer to one of these commits. The default branch name in Git is master. As you initially make commits, you’re given a `master` branch that points to the last commit you made. Every time you commit, it moves forward automatically.
 
-Insert 18333fig0303.png 
+Insert 18333fig0303.png
 Figure 3-3. Branch pointing into the commit data’s history.
 
 What happens if you create a new branch? Well, doing so creates a new pointer for you to move around. Let’s say you create a new branch called testing. You do this with the `git branch` command:
@@ -38,12 +38,12 @@ What happens if you create a new branch? Well, doing so creates a new pointer fo
 
 This creates a new pointer at the same commit you’re currently on (see Figure 3-4).
 
-Insert 18333fig0304.png 
+Insert 18333fig0304.png
 Figure 3-4. Multiple branches pointing into the commit’s data history.
 
-How does Git know what branch you’re currently on? It keeps a special pointer called HEAD. Note that this is a lot different than the concept of HEAD in other VCSs you may be used to, such as Subversion or CVS. In Git, this is a pointer to the local branch you’re currently on. In this case, you’re still on master. The git branch command only created a new branch — it didn’t switch to that branch (see Figure 3-5).
+How does Git know what branch you’re currently on? It keeps a special pointer called HEAD. Note that this is a lot different than the concept of HEAD in other VCSs you may be used to, such as Subversion or CVS. In Git, this is a pointer to the local branch you’re currently on. In this case, you’re still on master. The `git branch` command only created a new branch — it didn’t switch to that branch (see Figure 3-5).
 
-Insert 18333fig0305.png 
+Insert 18333fig0305.png
 Figure 3-5. HEAD file pointing to the branch you’re on.
 
 To switch to an existing branch, you run the `git checkout` command. Let’s switch to the new testing branch:
@@ -62,19 +62,19 @@ What is the significance of that? Well, let’s do another commit:
 
 Figure 3-7 illustrates the result.
 
-Insert 18333fig0307.png 
+Insert 18333fig0307.png
 Figure 3-7. The branch that HEAD points to moves forward with each commit.
 
-This is interesting, because now your testing branch has moved forward, but your master branch still points to the commit you were on when you ran `git checkout` to switch branches. Let’s switch back to the master branch:
+This is interesting, because now your testing branch has moved forward, but your `master` branch still points to the commit you were on when you ran `git checkout` to switch branches. Let’s switch back to the `master` branch:
 
 	$ git checkout master
 
 Figure 3-8 shows the result.
 
-Insert 18333fig0308.png 
+Insert 18333fig0308.png
 Figure 3-8. HEAD moves to another branch on a checkout.
 
-That command did two things. It moved the HEAD pointer back to point to the master branch, and it reverted the files in your working directory back to the snapshot that master points to. This also means the changes you make from this point forward will diverge from an older version of the project. It essentially rewinds the work you’ve done in your testing branch temporarily so you can go in a different direction.
+That command did two things. It moved the HEAD pointer back to point to the `master` branch, and it reverted the files in your working directory back to the snapshot that `master` points to. This also means the changes you make from this point forward will diverge from an older version of the project. It essentially rewinds the work you’ve done in your testing branch temporarily so you can go in a different direction.
 
 Let’s make a few changes and commit again:
 
@@ -83,7 +83,7 @@ Let’s make a few changes and commit again:
 
 Now your project history has diverged (see Figure 3-9). You created and switched to a branch, did some work on it, and then switched back to your main branch and did other work. Both of those changes are isolated in separate branches: you can switch back and forth between the branches and merge them together when you’re ready. And you did all that with simple `branch` and `checkout` commands.
 
-Insert 18333fig0309.png 
+Insert 18333fig0309.png
 Figure 3-9. The branch histories have diverged.
 
 Because a branch in Git is in actuality a simple file that contains the 40 character SHA-1 checksum of the commit it points to, branches are cheap to create and destroy. Creating a new branch is as quick and simple as writing 41 bytes to a file (40 characters and a newline).
@@ -102,7 +102,7 @@ Let’s go through a simple example of branching and merging with a workflow tha
 
 At this stage, you’ll receive a call that another issue is critical and you need a hotfix. You’ll do the following:
 
-1. Revert back to your production branch.
+1. Switch back to your production branch.
 2. Create a branch to add the hotfix.
 3. After it’s tested, merge the hotfix branch, and push to production.
 4. Switch back to your original story and continue working.
@@ -111,13 +111,13 @@ At this stage, you’ll receive a call that another issue is critical and you ne
 
 First, let’s say you’re working on your project and have a couple of commits already (see Figure 3-10).
 
-Insert 18333fig0310.png 
+Insert 18333fig0310.png
 Figure 3-10. A short and simple commit history.
 
 You’ve decided that you’re going to work on issue #53 in whatever issue-tracking system your company uses. To be clear, Git isn’t tied into any particular issue-tracking system; but because issue #53 is a focused topic that you want to work on, you’ll create a new branch in which to work. To create a branch and switch to it at the same time, you can run the `git checkout` command with the `-b` switch:
 
 	$ git checkout -b iss53
-	Switched to a new branch "iss53"
+	Switched to a new branch 'iss53'
 
 This is shorthand for:
 
@@ -126,7 +126,7 @@ This is shorthand for:
 
 Figure 3-11 illustrates the result.
 
-Insert 18333fig0311.png 
+Insert 18333fig0311.png
 Figure 3-11. Creating a new branch pointer.
 
 You work on your web site and do some commits. Doing so moves the `iss53` branch forward, because you have it checked out (that is, your HEAD is pointing to it; see Figure 3-12):
@@ -134,7 +134,7 @@ You work on your web site and do some commits. Doing so moves the `iss53` branch
 	$ vim index.html
 	$ git commit -a -m 'added a new footer [issue 53]'
 
-Insert 18333fig0312.png 
+Insert 18333fig0312.png
 Figure 3-12. The iss53 branch has moved forward with your work.
 
 Now you get the call that there is an issue with the web site, and you need to fix it immediately. With Git, you don’t have to deploy your fix along with the `iss53` changes you’ve made, and you don’t have to put a lot of effort into reverting those changes before you can work on applying your fix to what is in production. All you have to do is switch back to your master branch.
@@ -142,20 +142,20 @@ Now you get the call that there is an issue with the web site, and you need to f
 However, before you do that, note that if your working directory or staging area has uncommitted changes that conflict with the branch you’re checking out, Git won’t let you switch branches. It’s best to have a clean working state when you switch branches. There are ways to get around this (namely, stashing and commit amending) that we’ll cover later. For now, you’ve committed all your changes, so you can switch back to your master branch:
 
 	$ git checkout master
-	Switched to branch "master"
+	Switched to branch 'master'
 
 At this point, your project working directory is exactly the way it was before you started working on issue #53, and you can concentrate on your hotfix. This is an important point to remember: Git resets your working directory to look like the snapshot of the commit that the branch you check out points to. It adds, removes, and modifies files automatically to make sure your working copy is what the branch looked like on your last commit to it.
 
 Next, you have a hotfix to make. Let’s create a hotfix branch on which to work until it’s completed (see Figure 3-13):
 
-	$ git checkout -b 'hotfix'
-	Switched to a new branch "hotfix"
+	$ git checkout -b hotfix
+	Switched to a new branch 'hotfix'
 	$ vim index.html
 	$ git commit -a -m 'fixed the broken email address'
-	[hotfix]: created 3a0874c: "fixed the broken email address"
-	 1 files changed, 0 insertions(+), 1 deletions(-)
+	[hotfix 3a0874c] fixed the broken email address
+	 1 files changed, 1 deletion(-)
 
-Insert 18333fig0313.png 
+Insert 18333fig0313.png
 Figure 3-13. hotfix branch based back at your master branch point.
 
 You can run your tests, make sure the hotfix is what you want, and merge it back into your master branch to deploy to production. You do this with the `git merge` command:
@@ -163,32 +163,32 @@ You can run your tests, make sure the hotfix is what you want, and merge it back
 	$ git checkout master
 	$ git merge hotfix
 	Updating f42c576..3a0874c
-	Fast forward
-	 README |    1 -
-	 1 files changed, 0 insertions(+), 1 deletions(-)
+	Fast-forward
+	 README | 1 -
+	 1 file changed, 1 deletion(-)
 
-You’ll notice the phrase "Fast forward" in that merge. Because the commit pointed to by the branch you merged in was directly upstream of the commit you’re on, Git moves the pointer forward. To phrase that another way, when you try to merge one commit with a commit that can be reached by following the first commit’s history, Git simplifies things by moving the pointer forward because there is no divergent work to merge together — this is called a "fast forward".
+You’ll notice the phrase "Fast-forward" in that merge. Because the commit pointed to by the branch you merged in was directly upstream of the commit you’re on, Git moves the pointer forward. To phrase that another way, when you try to merge one commit with a commit that can be reached by following the first commit’s history, Git simplifies things by moving the pointer forward because there is no divergent work to merge together — this is called a "fast forward".
 
 Your change is now in the snapshot of the commit pointed to by the `master` branch, and you can deploy your change (see Figure 3-14).
 
-Insert 18333fig0314.png 
+Insert 18333fig0314.png
 Figure 3-14. Your master branch points to the same place as your hotfix branch after the merge.
 
 After your super-important fix is deployed, you’re ready to switch back to the work you were doing before you were interrupted. However, first you’ll delete the `hotfix` branch, because you no longer need it — the `master` branch points at the same place. You can delete it with the `-d` option to `git branch`:
 
 	$ git branch -d hotfix
-	Deleted branch hotfix (3a0874c).
+	Deleted branch hotfix (was 3a0874c).
 
 Now you can switch back to your work-in-progress branch on issue #53 and continue working on it (see Figure 3-15):
 
 	$ git checkout iss53
-	Switched to branch "iss53"
+	Switched to branch 'iss53'
 	$ vim index.html
 	$ git commit -a -m 'finished the new footer [issue 53]'
-	[iss53]: created ad82d7a: "finished the new footer [issue 53]"
-	 1 files changed, 1 insertions(+), 0 deletions(-)
+	[iss53 ad82d7a] finished the new footer [issue 53]
+	 1 file changed, 1 insertion(+)
 
-Insert 18333fig0315.png 
+Insert 18333fig0315.png
 Figure 3-15. Your iss53 branch can move forward independently.
 
 It’s worth noting here that the work you did in your `hotfix` branch is not contained in the files in your `iss53` branch. If you need to pull it in, you can merge your `master` branch into your `iss53` branch by running `git merge master`, or you can wait to integrate those changes until you decide to pull the `iss53` branch back into `master` later.
@@ -199,20 +199,21 @@ Suppose you’ve decided that your issue #53 work is complete and ready to be me
 
 	$ git checkout master
 	$ git merge iss53
-	Merge made by recursive.
-	 README |    1 +
-	 1 files changed, 1 insertions(+), 0 deletions(-)
+	Auto-merging README
+	Merge made by the 'recursive' strategy.
+	 README | 1 +
+	 1 file changed, 1 insertion(+)
 
 This looks a bit different than the `hotfix` merge you did earlier. In this case, your development history has diverged from some older point. Because the commit on the branch you’re on isn’t a direct ancestor of the branch you’re merging in, Git has to do some work. In this case, Git does a simple three-way merge, using the two snapshots pointed to by the branch tips and the common ancestor of the two. Figure 3-16 highlights the three snapshots that Git uses to do its merge in this case.
 
-Insert 18333fig0316.png 
+Insert 18333fig0316.png
 Figure 3-16. Git automatically identifies the best common-ancestor merge base for branch merging.
 
 Instead of just moving the branch pointer forward, Git creates a new snapshot that results from this three-way merge and automatically creates a new commit that points to it (see Figure 3-17). This is referred to as a merge commit and is special in that it has more than one parent.
 
 It’s worth pointing out that Git determines the best common ancestor to use for its merge base; this is different than CVS or Subversion (before version 1.5), where the developer doing the merge has to figure out the best merge base for themselves. This makes merging a heck of a lot easier in Git than in these other systems.
 
-Insert 18333fig0317.png 
+Insert 18333fig0317.png
 Figure 3-17. Git automatically creates a new commit object that contains the merged work.
 
 Now that your work is merged in, you have no further need for the `iss53` branch. You can delete it and then manually close the ticket in your ticket-tracking system:
@@ -230,25 +231,27 @@ Occasionally, this process doesn’t go smoothly. If you changed the same part o
 
 Git hasn’t automatically created a new merge commit. It has paused the process while you resolve the conflict. If you want to see which files are unmerged at any point after a merge conflict, you can run `git status`:
 
-	[master*]$ git status
-	index.html: needs merge
-	# On branch master
-	# Changes not staged for commit:
-	#   (use "git add <file>..." to update what will be committed)
-	#   (use "git checkout -- <file>..." to discard changes in working directory)
-	#
-	#	unmerged:   index.html
-	#
+	$ git status
+	On branch master
+	You have unmerged paths.
+	  (fix conflicts and run "git commit")
+	
+	Unmerged paths:
+	  (use "git add <file>..." to mark resolution)
+	
+	        both modified:      index.html
+	
+	no changes added to commit (use "git add" and/or "git commit -a")
 
 Anything that has merge conflicts and hasn’t been resolved is listed as unmerged. Git adds standard conflict-resolution markers to the files that have conflicts, so you can open them manually and resolve those conflicts. Your file contains a section that looks something like this:
 
-	<<<<<<< HEAD:index.html
+	<<<<<<< HEAD
 	<div id="footer">contact : email.support@github.com</div>
 	=======
 	<div id="footer">
 	  please contact us at support@github.com
 	</div>
-	>>>>>>> iss53:index.html
+	>>>>>>> iss53
 
 This means the version in HEAD (your master branch, because that was what you had checked out when you ran your merge command) is the top part of that block (everything above the `=======`), while the version in your `iss53` branch looks like everything in the bottom part. In order to resolve the conflict, you have to either choose one side or the other or merge the contents yourself. For instance, you might resolve this conflict by replacing the entire block with this:
 
@@ -260,27 +263,32 @@ This resolution has a little of each section, and I’ve fully removed the `<<<<
 If you want to use a graphical tool to resolve these issues, you can run `git mergetool`, which fires up an appropriate visual merge tool and walks you through the conflicts:
 
 	$ git mergetool
-	merge tool candidates: kdiff3 tkdiff xxdiff meld gvimdiff opendiff emerge vimdiff
-	Merging the files: index.html
+
+	This message is displayed because 'merge.tool' is not configured.
+	See 'git mergetool --tool-help' or 'git help config' for more details.
+	'git mergetool' will now attempt to use one of the following tools:
+	opendiff kdiff3 tkdiff xxdiff meld tortoisemerge gvimdiff diffuse diffmerge ecmerge p4merge araxis bc3 codecompare vimdiff emerge
+	Merging:
+	index.html
 
 	Normal merge conflict for 'index.html':
-	  {local}: modified
-	  {remote}: modified
+	  {local}: modified file
+	  {remote}: modified file
 	Hit return to start merge resolution tool (opendiff):
 
-If you want to use a merge tool other than the default (Git chose `opendiff` for me in this case because I ran the command on a Mac), you can see all the supported tools listed at the top after “merge tool candidates”. Type the name of the tool you’d rather use. In Chapter 7, we’ll discuss how you can change this default value for your environment.
+If you want to use a merge tool other than the default (Git chose `opendiff` for me in this case because I ran the command on a Mac), you can see all the supported tools listed at the top after “... one of the following tools:”. Type the name of the tool you’d rather use. In Chapter 7, we’ll discuss how you can change this default value for your environment.
 
 After you exit the merge tool, Git asks you if the merge was successful. If you tell the script that it was, it stages the file to mark it as resolved for you.
 
 You can run `git status` again to verify that all conflicts have been resolved:
 
 	$ git status
-	# On branch master
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#	modified:   index.html
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+	
+	        modified:   index.html
+	
 
 If you’re happy with that, and you verify that everything that had conflicts has been staged, you can type `git commit` to finalize the merge commit. The commit message by default looks something like this:
 
@@ -289,9 +297,9 @@ If you’re happy with that, and you verify that everything that had conflicts h
 	Conflicts:
 	  index.html
 	#
-	# It looks like you may be committing a MERGE.
+	# It looks like you may be committing a merge.
 	# If this is not correct, please remove the file
-	# .git/MERGE_HEAD
+	#       .git/MERGE_HEAD
 	# and try again.
 	#
 
@@ -315,7 +323,7 @@ Notice the `*` character that prefixes the `master` branch: it indicates the bra
 	* master  7a98805 Merge branch 'iss53'
 	  testing 782fd34 add scott to the author list in the readmes
 
-Another useful option to figure out what state your branches are in is to filter this list to branches that you have or have not yet merged into the branch you’re currently on. The useful `--merged` and `--no-merged` options have been available in Git since version 1.5.6 for this purpose. To see which branches are already merged into the branch you’re on, you can run `git branch --merged`:
+Another useful option to figure out what state your branches are in is to filter this list to branches that you have or have not yet merged into the branch you’re currently on. There are useful `--merged` and `--no-merged` options available in Git for this purpose. To see which branches are already merged into the branch you’re on, you can run `git branch --merged`:
 
 	$ git branch --merged
 	  iss53
@@ -331,7 +339,7 @@ To see all the branches that contain work you haven’t yet merged in, you can r
 This shows your other branch. Because it contains work that isn’t merged in yet, trying to delete it with `git branch -d` will fail:
 
 	$ git branch -d testing
-	error: The branch 'testing' is not an ancestor of your current HEAD.
+	error: The branch 'testing' is not fully merged.
 	If you are sure you want to delete it, run 'git branch -D testing'.
 
 If you really do want to delete the branch and lose that work, you can force it with `-D`, as the helpful message points out.
@@ -348,12 +356,12 @@ Many Git developers have a workflow that embraces this approach, such as having
 
 In reality, we’re talking about pointers moving up the line of commits you’re making. The stable branches are farther down the line in your commit history, and the bleeding-edge branches are farther up the history (see Figure 3-18).
 
-Insert 18333fig0318.png 
+Insert 18333fig0318.png
 Figure 3-18. More stable branches are generally farther down the commit history.
 
 It’s generally easier to think about them as work silos, where sets of commits graduate to a more stable silo when they’re fully tested (see Figure 3-19).
 
-Insert 18333fig0319.png 
+Insert 18333fig0319.png
 Figure 3-19. It may be helpful to think of your branches as silos.
 
 You can keep doing this for several levels of stability. Some larger projects also have a `proposed` or `pu` (proposed updates) branch that has integrated branches that may not be ready to go into the `next` or `master` branch. The idea is that your branches are at various levels of stability; when they reach a more stable level, they’re merged into the branch above them.
@@ -367,12 +375,12 @@ You saw this in the last section with the `iss53` and `hotfix` branches you crea
 
 Consider an example of doing some work (on `master`), branching off for an issue (`iss91`), working on it for a bit, branching off the second branch to try another way of handling the same thing (`iss91v2`), going back to your master branch and working there for a while, and then branching off there to do some work that you’re not sure is a good idea (`dumbidea` branch). Your commit history will look something like Figure 3-20.
 
-Insert 18333fig0320.png 
+Insert 18333fig0320.png
 Figure 3-20. Your commit history with multiple topic branches.
 
 Now, let’s say you decide you like the second solution to your issue best (`iss91v2`); and you showed the `dumbidea` branch to your coworkers, and it turns out to be genius. You can throw away the original `iss91` branch (losing commits C5 and C6) and merge in the other two. Your history then looks like Figure 3-21.
 
-Insert 18333fig0321.png 
+Insert 18333fig0321.png
 Figure 3-21. Your history after merging in dumbidea and iss91v2.
 
 It’s important to remember when you’re doing all this that these branches are completely local. When you’re branching and merging, everything is being done only in your Git repository — no server communication is happening.
@@ -385,27 +393,27 @@ They take the form `(remote)/(branch)`. For instance, if you wanted to see what
 
 This may be a bit confusing, so let’s look at an example. Let’s say you have a Git server on your network at `git.ourcompany.com`. If you clone from this, Git automatically names it `origin` for you, pulls down all its data, creates a pointer to where its `master` branch is, and names it `origin/master` locally; and you can’t move it. Git also gives you your own `master` branch starting at the same place as origin’s `master` branch, so you have something to work from (see Figure 3-22).
 
-Insert 18333fig0322.png 
+Insert 18333fig0322.png
 Figure 3-22. A Git clone gives you your own master branch and origin/master pointing to origin’s master branch.
 
 If you do some work on your local master branch, and, in the meantime, someone else pushes to `git.ourcompany.com` and updates its master branch, then your histories move forward differently. Also, as long as you stay out of contact with your origin server, your `origin/master` pointer doesn’t move (see Figure 3-23).
 
-Insert 18333fig0323.png 
+Insert 18333fig0323.png
 Figure 3-23. Working locally and having someone push to your remote server makes each history move forward differently.
 
 To synchronize your work, you run a `git fetch origin` command. This command looks up which server origin is (in this case, it’s `git.ourcompany.com`), fetches any data from it that you don’t yet have, and updates your local database, moving your `origin/master` pointer to its new, more up-to-date position (see Figure 3-24).
 
-Insert 18333fig0324.png 
-Figure 3-24. The git fetch command updates your remote references.
+Insert 18333fig0324.png
+Figure 3-24. The `git fetch` command updates your remote references.
 
 To demonstrate having multiple remote servers and what remote branches for those remote projects look like, let’s assume you have another internal Git server that is used only for development by one of your sprint teams. This server is at `git.team1.ourcompany.com`. You can add it as a new remote reference to the project you’re currently working on by running the `git remote add` command as we covered in Chapter 2. Name this remote `teamone`, which will be your shortname for that whole URL (see Figure 3-25).
 
-Insert 18333fig0325.png 
+Insert 18333fig0325.png
 Figure 3-25. Adding another server as a remote.
 
-Now, you can run `git fetch teamone` to fetch everything the remote `teamone` server has that you don’t have yet. Because that server is a subset of the data your `origin` server has right now, Git fetches no data but sets a remote branch called `teamone/master` to point to the commit that `teamone` has as its `master` branch (see Figure 3-26).
+Now, you can run `git fetch teamone` to fetch everything the remote `teamone` server has that you don’t have yet. Because that server has a subset of the data your `origin` server has right now, Git fetches no data but sets a remote branch called `teamone/master` to point to the commit that `teamone` has as its `master` branch (see Figure 3-26).
 
-Insert 18333fig0326.png 
+Insert 18333fig0326.png
 Figure 3-26. You get a reference to teamone’s master branch position locally.
 
 ### Pushing ###
@@ -439,8 +447,8 @@ It’s important to note that when you do a fetch that brings down new remote br
 To merge this work into your current working branch, you can run `git merge origin/serverfix`. If you want your own `serverfix` branch that you can work on, you can base it off your remote branch:
 
 	$ git checkout -b serverfix origin/serverfix
-	Branch serverfix set up to track remote branch refs/remotes/origin/serverfix.
-	Switched to a new branch "serverfix"
+	Branch serverfix set up to track remote branch serverfix from origin.
+	Switched to a new branch 'serverfix'
 
 This gives you a local branch that you can work on that starts where `origin/serverfix` is.
 
@@ -451,16 +459,16 @@ Checking out a local branch from a remote branch automatically creates what is c
 When you clone a repository, it generally automatically creates a `master` branch that tracks `origin/master`. That’s why `git push` and `git pull` work out of the box with no other arguments. However, you can set up other tracking branches if you wish — ones that don’t track branches on `origin` and don’t track the `master` branch. The simple case is the example you just saw, running `git checkout -b [branch] [remotename]/[branch]`. If you have Git version 1.6.2 or later, you can also use the `--track` shorthand:
 
 	$ git checkout --track origin/serverfix
-	Branch serverfix set up to track remote branch refs/remotes/origin/serverfix.
-	Switched to a new branch "serverfix"
+	Branch serverfix set up to track remote branch serverfix from origin.
+	Switched to a new branch 'serverfix'
 
 To set up a local branch with a different name than the remote branch, you can easily use the first version with a different local branch name:
 
 	$ git checkout -b sf origin/serverfix
-	Branch sf set up to track remote branch refs/remotes/origin/serverfix.
-	Switched to a new branch "sf"
+	Branch sf set up to track remote branch serverfix from origin.
+	Switched to a new branch 'sf'
 
-Now, your local branch sf will automatically push to and pull from origin/serverfix.
+Now, your local branch `sf` will automatically push to and pull from `origin/serverfix`.
 
 ### Deleting Remote Branches ###
 
@@ -480,12 +488,12 @@ In Git, there are two main ways to integrate changes from one branch into anothe
 
 If you go back to an earlier example from the Merge section (see Figure 3-27), you can see that you diverged your work and made commits on two different branches.
 
-Insert 18333fig0327.png 
+Insert 18333fig0327.png
 Figure 3-27. Your initial diverged commit history.
 
 The easiest way to integrate the branches, as we’ve already covered, is the `merge` command. It performs a three-way merge between the two latest branch snapshots (C3 and C4) and the most recent common ancestor of the two (C2), creating a new snapshot (and commit), as shown in Figure 3-28.
 
-Insert 18333fig0328.png 
+Insert 18333fig0328.png
 Figure 3-28. Merging a branch to integrate the diverged work history.
 
 However, there is another way: you can take the patch of the change that was introduced in C3 and reapply it on top of C4. In Git, this is called _rebasing_. With the `rebase` command, you can take all the changes that were committed on one branch and replay them on another one.
@@ -499,12 +507,12 @@ In this example, you’d run the following:
 
 It works by going to the common ancestor of the two branches (the one you’re on and the one you’re rebasing onto), getting the diff introduced by each commit of the branch you’re on, saving those diffs to temporary files, resetting the current branch to the same commit as the branch you are rebasing onto, and finally applying each change in turn. Figure 3-29 illustrates this process.
 
-Insert 18333fig0329.png 
+Insert 18333fig0329.png
 Figure 3-29. Rebasing the change introduced in C3 onto C4.
 
 At this point, you can go back to the master branch and do a fast-forward merge (see Figure 3-30).
 
-Insert 18333fig0330.png 
+Insert 18333fig0330.png
 Figure 3-30. Fast-forwarding the master branch.
 
 Now, the snapshot pointed to by C3' is exactly the same as the one that was pointed to by C5 in the merge example. There is no difference in the end product of the integration, but rebasing makes for a cleaner history. If you examine the log of a rebased branch, it looks like a linear history: it appears that all the work happened in series, even when it originally happened in parallel.
@@ -517,7 +525,7 @@ Note that the snapshot pointed to by the final commit you end up with, whether i
 
 You can also have your rebase replay on something other than the rebase branch. Take a history like Figure 3-31, for example. You branched a topic branch (`server`) to add some server-side functionality to your project, and made a commit. Then, you branched off that to make the client-side changes (`client`) and committed a few times. Finally, you went back to your server branch and did a few more commits.
 
-Insert 18333fig0331.png 
+Insert 18333fig0331.png
 Figure 3-31. A history with a topic branch off another topic branch.
 
 Suppose you decide that you want to merge your client-side changes into your mainline for a release, but you want to hold off on the server-side changes until it’s tested further. You can take the changes on client that aren’t on server (C8 and C9) and replay them on your master branch by using the `--onto` option of `git rebase`:
@@ -526,7 +534,7 @@ Suppose you decide that you want to merge your client-side changes into your mai
 
 This basically says, “Check out the client branch, figure out the patches from the common ancestor of the `client` and `server` branches, and then replay them onto `master`.” It’s a bit complex; but the result, shown in Figure 3-32, is pretty cool.
 
-Insert 18333fig0332.png 
+Insert 18333fig0332.png
 Figure 3-32. Rebasing a topic branch off another topic branch.
 
 Now you can fast-forward your master branch (see Figure 3-33):
@@ -534,7 +542,7 @@ Now you can fast-forward your master branch (see Figure 3-33):
 	$ git checkout master
 	$ git merge client
 
-Insert 18333fig0333.png 
+Insert 18333fig0333.png
 Figure 3-33. Fast-forwarding your master branch to include the client branch changes.
 
 Let’s say you decide to pull in your server branch as well. You can rebase the server branch onto the master branch without having to check it out first by running `git rebase [basebranch] [topicbranch]` — which checks out the topic branch (in this case, `server`) for you and replays it onto the base branch (`master`):
@@ -543,7 +551,7 @@ Let’s say you decide to pull in your server branch as well. You can rebase the
 
 This replays your `server` work on top of your `master` work, as shown in Figure 3-34.
 
-Insert 18333fig0334.png 
+Insert 18333fig0334.png
 Figure 3-34. Rebasing your server branch on top of your master branch.
 
 Then, you can fast-forward the base branch (`master`):
@@ -556,7 +564,7 @@ You can remove the `client` and `server` branches because all the work is integr
 	$ git branch -d client
 	$ git branch -d server
 
-Insert 18333fig0335.png 
+Insert 18333fig0335.png
 Figure 3-35. Final commit history.
 
 ### The Perils of Rebasing ###
@@ -571,22 +579,22 @@ When you rebase stuff, you’re abandoning existing commits and creating new one
 
 Let’s look at an example of how rebasing work that you’ve made public can cause problems. Suppose you clone from a central server and then do some work off that. Your commit history looks like Figure 3-36.
 
-Insert 18333fig0336.png 
+Insert 18333fig0336.png
 Figure 3-36. Clone a repository, and base some work on it.
 
 Now, someone else does more work that includes a merge, and pushes that work to the central server. You fetch them and merge the new remote branch into your work, making your history look something like Figure 3-37.
 
-Insert 18333fig0337.png 
+Insert 18333fig0337.png
 Figure 3-37. Fetch more commits, and merge them into your work.
 
 Next, the person who pushed the merged work decides to go back and rebase their work instead; they do a `git push --force` to overwrite the history on the server. You then fetch from that server, bringing down the new commits.
 
-Insert 18333fig0338.png 
+Insert 18333fig0338.png
 Figure 3-38. Someone pushes rebased commits, abandoning commits you’ve based your work on.
 
 At this point, you have to merge this work in again, even though you’ve already done so. Rebasing changes the SHA-1 hashes of these commits so to Git they look like new commits, when in fact you already have the C4 work in your history (see Figure 3-39).
 
-Insert 18333fig0339.png 
+Insert 18333fig0339.png
 Figure 3-39. You merge in the same work again into a new merge commit.
 
 You have to merge that work in at some point so you can keep up with the other developer in the future. After you do that, your commit history will contain both the C4 and C4' commits, which have different SHA-1 hashes but introduce the same work and have the same commit message. If you run a `git log` when your history looks like this, you’ll see two commits that have the same author date and message, which will be confusing. Furthermore, if you push this history back up to the server, you’ll reintroduce all those rebased commits to the central server, which can further confuse people.
diff --git a/no-nb/04-git-server/01-chapter4.markdown b/no-nb/04-git-server/01-chapter4.markdown
index 4c9639ff6..a52ba5361 100644
--- a/no-nb/04-git-server/01-chapter4.markdown
+++ b/no-nb/04-git-server/01-chapter4.markdown
@@ -26,7 +26,7 @@ Or you can do this:
 
 	$ git clone file:///opt/git/project.git
 
-Git operates slightly differently if you explicitly specify `file://` at the beginning of the URL. If you just specify the path, Git tries to use hardlinks or directly copy the files it needs. If you specify `file://`, Git fires up the processes that it normally uses to transfer data over a network which is generally a lot less efficient method of transferring the data. The main reason to specify the `file://` prefix is if you want a clean copy of the repository with extraneous references or objects left out — generally after an import from another version-control system or something similar (see Chapter 9 for maintenance tasks). We’ll use the normal path here because doing so is almost always faster.
+Git operates slightly differently if you explicitly specify `file://` at the beginning of the URL. If you just specify the path, and the source and the destination are on the same filesystem, Git tries to hardlink the objects it needs. If they are not on the same filesystem, it will copy the objects it needs using the system's standard copying functionality. If you specify `file://`, Git fires up the processes that it normally uses to transfer data over a network which is generally a lot less efficient method of transferring the data. The main reason to specify the `file://` prefix is if you want a clean copy of the repository with extraneous references or objects left out — generally after an import from another version-control system or something similar (see Chapter 9 for maintenance tasks). We’ll use the normal path here because doing so is almost always faster.
 
 To add a local repository to an existing Git project, you can run something like this:
 
@@ -55,7 +55,7 @@ To clone a Git repository over SSH, you can specify ssh:// URL like this:
 	$ git clone ssh://user@server/project.git
 
 Or you can use the shorter scp-like syntax for SSH protocol:
-	
+
 	$ git clone user@server:project.git
 
 You can also not specify a user, and Git assumes the user you’re currently logged in as.
@@ -117,9 +117,10 @@ In order to initially set up any Git server, you have to export an existing repo
 In order to clone your repository to create a new bare repository, you run the clone command with the `--bare` option. By convention, bare repository directories end in `.git`, like so:
 
 	$ git clone --bare my_project my_project.git
-	Initialized empty Git repository in /opt/projects/my_project.git/
+	Cloning into bare repository 'my_project.git'...
+	done.
 
-The output for this command is a little confusing. Since `clone` is basically a `git init` then a `git fetch`, we see some output from the `git init` part, which creates an empty directory. The actual object transfer gives no output, but it does happen. You should now have a copy of the Git directory data in your `my_project.git` directory.
+You should now have a copy of the Git directory data in your `my_project.git` directory.
 
 This is roughly equivalent to something like
 
@@ -177,11 +178,11 @@ First, you should check to make sure you don’t already have a key. By default,
 
 You’re looking for a pair of files named something and something.pub, where the something is usually `id_dsa` or `id_rsa`. The `.pub` file is your public key, and the other file is your private key. If you don’t have these files (or you don’t even have a `.ssh` directory), you can create them by running a program called `ssh-keygen`, which is provided with the SSH package on Linux/Mac systems and comes with the MSysGit package on Windows:
 
-	$ ssh-keygen 
+	$ ssh-keygen
 	Generating public/private rsa key pair.
-	Enter file in which to save the key (/Users/schacon/.ssh/id_rsa): 
-	Enter passphrase (empty for no passphrase): 
-	Enter same passphrase again: 
+	Enter file in which to save the key (/Users/schacon/.ssh/id_rsa):
+	Enter passphrase (empty for no passphrase):
+	Enter same passphrase again:
 	Your identification has been saved in /Users/schacon/.ssh/id_rsa.
 	Your public key has been saved in /Users/schacon/.ssh/id_rsa.pub.
 	The key fingerprint is:
@@ -191,7 +192,7 @@ First it confirms where you want to save the key (`.ssh/id_rsa`), and then it as
 
 Now, each user that does this has to send their public key to you or whoever is administrating the Git server (assuming you’re using an SSH server setup that requires public keys). All they have to do is copy the contents of the `.pub` file and e-mail it. The public keys look something like this:
 
-	$ cat ~/.ssh/id_rsa.pub 
+	$ cat ~/.ssh/id_rsa.pub
 	ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAklOUpkDHrfHY17SbrmTIpNLTGK9Tjom/BWDSU
 	GPl+nafzlHDTYW7hdI4yZ5ew18JH4JW9jbhUFrviQzM7xlELEVf4h9lFX5QVkbPppSwg0cda3
 	Pbv7kOdJ/MTyBlWXFCR+HAo3FXRitBqxiX1nKhXpHAZsMciLq8V6RjsNAQwdsdMFvSlVK/7XA
@@ -246,6 +247,7 @@ Then, John, Josie, or Jessica can push the first version of their project into t
 At this point, the others can clone it down and push changes back up just as easily:
 
 	$ git clone git@gitserver:/opt/git/project.git
+	$ cd project
 	$ vim README
 	$ git commit -am 'fix for the README file'
 	$ git push origin master
@@ -282,12 +284,17 @@ First you need to enable the hook:
 	$ mv hooks/post-update.sample hooks/post-update
 	$ chmod a+x hooks/post-update
 
-If you’re using a version of Git earlier than 1.6, the `mv` command isn’t necessary — Git started naming the hooks examples with the .sample postfix only recently. 
-
 What does this `post-update` hook do? It looks basically like this:
 
-	$ cat .git/hooks/post-update 
+	$ cat .git/hooks/post-update
 	#!/bin/sh
+	#
+	# An example hook script to prepare a packed repository for use over
+	# dumb transports.
+	#
+	# To enable this hook, rename this file to "post-update".
+	#
+	
 	exec git-update-server-info
 
 This means that when you push to the server via SSH, Git will run this command to update the files needed for HTTP fetching.
@@ -317,7 +324,7 @@ This way, you can set up HTTP-based read access to any of your projects for a fa
 
 Now that you have basic read/write and read-only access to your project, you may want to set up a simple web-based visualizer. Git comes with a CGI script called GitWeb that is commonly used for this. You can see GitWeb in use at sites like `http://git.kernel.org` (see Figure 4-1).
 
-Insert 18333fig0401.png 
+Insert 18333fig0401.png
 Figure 4-1. The GitWeb web-based user interface.
 
 If you want to check out what GitWeb would look like for your project, Git comes with a command to fire up a temporary instance if you have a lightweight server on your system like `lighttpd` or `webrick`. On Linux machines, `lighttpd` is often installed, so you may be able to get it to run by typing `git instaweb` in your project directory. If you’re running a Mac, Leopard comes preinstalled with Ruby, so `webrick` may be your best bet. To start `instaweb` with a non-lighttpd handler, you can run it with the `--httpd` option.
@@ -335,7 +342,7 @@ If you want to run the web interface on a server all the time for your team or f
 	$ git clone git://git.kernel.org/pub/scm/git/git.git
 	$ cd git/
 	$ make GITWEB_PROJECTROOT="/opt/git" \
-	        prefix=/usr gitweb/gitweb.cgi
+	        prefix=/usr gitweb
 	$ sudo cp -Rf gitweb /var/www/
 
 Notice that you have to tell the command where to find your Git repositories with the `GITWEB_PROJECTROOT` variable. Now, you need to make Apache use CGI for that script, for which you can add a VirtualHost:
@@ -403,7 +410,7 @@ You’re ready to roll. If you’re set up correctly, you can try to SSH into yo
 
 	$ ssh git@gitserver
 	PTY allocation request failed on channel 0
-	fatal: unrecognized command 'gitosis-serve schacon@quaternion'
+	ERROR:gitosis.serve.main:Need SSH_ORIGINAL_COMMAND in environment.
 	  Connection to gitserver closed.
 
 That means Gitosis recognized you but shut you out because you’re not trying to do any Git commands. So, let’s do an actual Git command — you’ll clone the Gitosis control repository:
@@ -423,32 +430,32 @@ The `gitosis.conf` file is the control file you use to specify users, repositori
 
 If you look at the `gitosis.conf` file, it should only specify information about the `gitosis-admin` project that you just cloned:
 
-	$ cat gitosis.conf 
+	$ cat gitosis.conf
 	[gitosis]
 
 	[group gitosis-admin]
-	writable = gitosis-admin
 	members = scott
+	writable = gitosis-admin
 
 It shows you that the 'scott' user — the user with whose public key you initialized Gitosis — is the only one who has access to the `gitosis-admin` project.
 
 Now, let’s add a new project for you. You’ll add a new section called `mobile` where you’ll list the developers on your mobile team and projects that those developers need access to. Because 'scott' is the only user in the system right now, you’ll add him as the only member, and you’ll create a new project called `iphone_project` to start on:
 
 	[group mobile]
-	writable = iphone_project
 	members = scott
+	writable = iphone_project
 
 Whenever you make changes to the `gitosis-admin` project, you have to commit the changes and push them back up to the server in order for them to take effect:
 
 	$ git commit -am 'add iphone_project and mobile group'
-	[master]: created 8962da8: "changed name"
-	 1 files changed, 4 insertions(+), 0 deletions(-)
-	$ git push
+	[master 8962da8] add iphone_project and mobile group
+	 1 file changed, 4 insertions(+)
+	$ git push origin master
 	Counting objects: 5, done.
-	Compressing objects: 100% (2/2), done.
-	Writing objects: 100% (3/3), 272 bytes, done.
-	Total 3 (delta 1), reused 0 (delta 0)
-	To git@gitserver:/opt/git/gitosis-admin.git
+	Compressing objects: 100% (3/3), done.
+	Writing objects: 100% (3/3), 272 bytes | 0 bytes/s, done.
+	Total 3 (delta 0), reused 0 (delta 0)
+	To git@gitserver:gitosis-admin.git
 	   fb27aec..8962da8  master -> master
 
 You can make your first push to the new `iphone_project` project by adding your server as a remote to your local version of the project and pushing. You no longer have to manually create a bare repository for new projects on the server — Gitosis creates them automatically when it sees the first push:
@@ -457,7 +464,7 @@ You can make your first push to the new `iphone_project` project by adding your
 	$ git push origin master
 	Initialized empty Git repository in /opt/git/iphone_project.git/
 	Counting objects: 3, done.
-	Writing objects: 100% (3/3), 230 bytes, done.
+	Writing objects: 100% (3/3), 230 bytes | 0 bytes/s, done.
 	Total 3 (delta 0), reused 0 (delta 0)
 	To git@gitserver:iphone_project.git
 	 * [new branch]      master -> master
@@ -473,20 +480,20 @@ You want to work on this project with your friends, so you’ll have to re-add t
 Now you can add them all to your 'mobile' team so they have read and write access to `iphone_project`:
 
 	[group mobile]
-	writable = iphone_project
 	members = scott john josie jessica
+	writable = iphone_project
 
 After you commit and push that change, all four users will be able to read from and write to that project.
 
 Gitosis has simple access controls as well. If you want John to have only read access to this project, you can do this instead:
 
 	[group mobile]
-	writable = iphone_project
 	members = scott josie jessica
+	writable = iphone_project
 
 	[group mobile_ro]
-	readonly = iphone_project
 	members = john
+	readonly = iphone_project
 
 Now John can clone the project and get updates, but Gitosis won’t allow him to push back up to the project. You can create as many of these groups as you want, each containing different users and projects. You can also specify another group as one of the members (using `@` as prefix), to inherit all of its members automatically:
 
@@ -494,102 +501,78 @@ Now John can clone the project and get updates, but Gitosis won’t allow him to
 	members = scott josie jessica
 
 	[group mobile]
-	writable  = iphone_project
 	members   = @mobile_committers
+	writable  = iphone_project
 
 	[group mobile_2]
-	writable  = another_iphone_project
 	members   = @mobile_committers john
+	writable  = another_iphone_project
 
 If you have any issues, it may be useful to add `loglevel=DEBUG` under the `[gitosis]` section. If you’ve lost push access by pushing a messed-up configuration, you can manually fix the file on the server under `/home/git/.gitosis.conf` — the file from which Gitosis reads its info. A push to the project takes the `gitosis.conf` file you just pushed up and sticks it there. If you edit that file manually, it remains like that until the next successful push to the `gitosis-admin` project.
 
 ## Gitolite ##
 
-Note: the latest copy of this section of the ProGit book is always available within the [gitolite documentation][gldpg].  The author would also like to humbly state that, while this section is accurate, and *can* (and often *has*) been used to install gitolite without reading any other documentation, it is of necessity not complete, and cannot completely replace the enormous amount of documentation that gitolite comes with.
+This section serves as a quick introduction to Gitolite, and provides basic installation and setup instructions.  It cannot, however, replace the enormous amount of [documentation][gltoc] that Gitolite comes with.  There may also be occasional changes to this section itself, so you may also want to look at the latest version [here][gldpg].
 
-[gldpg]: http://github.com/sitaramc/gitolite/blob/pu/doc/progit-article.mkd
+[gldpg]: http://sitaramc.github.com/gitolite/progit.html
+[gltoc]: http://sitaramc.github.com/gitolite/master-toc.html
 
-Git has started to become very popular in corporate environments, which tend to have some additional requirements in terms of access control.  Gitolite was originally created to help with those requirements, but it turns out that it's equally useful in the open source world: the Fedora Project controls access to their package management repositories (over 10,000 of them!) using gitolite, and this is probably the largest gitolite installation anywhere too.
+Gitolite is an authorization layer on top of Git, relying on `sshd` or `httpd` for authentication.  (Recap: authentication is identifying who the user is, authorization is deciding if he is allowed to do what he is attempting to).
 
 Gitolite allows you to specify permissions not just by repository, but also by branch or tag names within each repository.  That is, you can specify that certain people (or groups of people) can only push certain "refs" (branches or tags) but not others.
 
 ### Installing ###
 
-Installing Gitolite is very easy, even if you don't read the extensive documentation that comes with it.  You need an account on a Unix server of some kind; various Linux flavours, and Solaris 10, have been tested.  You do not need root access, assuming git, perl, and an openssh compatible ssh server are already installed.  In the examples below, we will use the `gitolite` account on a host called `gitserver`.
-
-Gitolite is somewhat unusual as far as "server" software goes -- access is via ssh, and so every userid on the server is a potential "gitolite host".  As a result, there is a notion of "installing" the software itself, and then "setting up" a user as a "gitolite host".
-
-Gitolite has 4 methods of installation.  People using Fedora or Debian systems can obtain an RPM or a DEB and install that.  People with root access can install it manually.  In these two methods, any user on the system can then become a "gitolite host".
-
-People without root access can install it within their own userids.  And finally, gitolite can be installed by running a script *on the workstation*, from a bash shell.  (Even the bash that comes with msysgit will do, in case you're wondering.)
-
-We will describe this last method in this article; for the other methods please see the documentation.
-
-You start by obtaining public key based access to your server, so that you can log in from your workstation to the server without getting a password prompt.  The following method works on Linux; for other workstation OSs you may have to do this manually.  We assume you already had a key pair generated using `ssh-keygen`.
-
-	$ ssh-copy-id -i ~/.ssh/id_rsa gitolite@gitserver
+Installing Gitolite is very easy, even if you don’t read the extensive documentation that comes with it.  You need an account on a Unix server of some kind.  You do not need root access, assuming Git, Perl, and an OpenSSH compatible SSH server are already installed.  In the examples below, we will use the `git` account on a host called `gitserver`.
 
-This will ask you for the password to the gitolite account, and then set up public key access.  This is **essential** for the install script, so check to make sure you can run a command without getting a password prompt:
+Gitolite is somewhat unusual as far as "server" software goes — access is via SSH, and so every userid on the server is a potential "gitolite host".  We will describe the simplest install method in this article; for the other methods please see the documentation.
 
-	$ ssh gitolite@gitserver pwd
-	/home/gitolite
-
-Next, you clone Gitolite from the project's main site and run the "easy install" script (the third argument is your name as you would like it to appear in the resulting gitolite-admin repository):
+To begin, create a user called `git` on your server and login to this user.  Copy your SSH public key (a file called `~/.ssh/id_rsa.pub` if you did a plain `ssh-keygen` with all the defaults) from your workstation, renaming it to `<yourname>.pub` (we'll use `scott.pub` in our examples).  Then run these commands:
 
 	$ git clone git://github.com/sitaramc/gitolite
-	$ cd gitolite/src
-	$ ./gl-easy-install -q gitolite gitserver sitaram
-
-And you're done!  Gitolite has now been installed on the server, and you now have a brand new repository called `gitolite-admin` in the home directory of your workstation.  You administer your gitolite setup by making changes to this repository and pushing.
-
-That last command does produce a fair amount of output, which might be interesting to read.  Also, the first time you run this, a new keypair is created; you will have to choose a passphrase or hit enter for none.  Why a second keypair is needed, and how it is used, is explained in the "ssh troubleshooting" document that comes with Gitolite.  (Hey the documentation has to be good for *something*!)
-
-Repos named `gitolite-admin` and `testing` are created on the server by default. If you wish to clone either of these locally (from an account that has SSH console access to the gitolite account via *authorized_keys*), type:
+	$ gitolite/install -ln
+	    # assumes $HOME/bin exists and is in your $PATH
+	$ gitolite setup -pk $HOME/scott.pub
 
-	$ git clone gitolite:gitolite-admin
-	$ git clone gitolite:testing
-	
-To clone these same repos from any other account:
-
-	$ git clone gitolite@servername:gitolite-admin
-	$ git clone gitolite@servername:testing
+That last command creates new Git repository called `gitolite-admin` on the server.
 
+Finally, back on your workstation, run `git clone git@gitserver:gitolite-admin`. And you’re done!  Gitolite has now been installed on the server, and you now have a brand new repository called `gitolite-admin` in your workstation.  You administer your Gitolite setup by making changes to this repository and pushing.
 
 ### Customising the Install ###
 
-While the default, quick, install works for most people, there are some ways to customise the install if you need to.  If you omit the `-q` argument, you get a "verbose" mode install -- detailed information on what the install is doing at each step.  The verbose mode also allows you to change certain server-side parameters, such as the location of the actual repositories, by editing an "rc" file that the server uses.  This "rc" file is liberally commented so you should be able to make any changes you need quite easily, save it, and continue.  This file also contains various settings that you can change to enable or disable some of gitolite's advanced features.
+While the default, quick, install works for most people, there are some ways to customise the install if you need to.  Some changes can be made simply by editing the rc file, but if that is not sufficient, there’s documentation on customising Gitolite.
 
 ### Config File and Access Control Rules ###
 
-Once the install is done, you switch to the `gitolite-admin` repository (placed in your HOME directory) and poke around to see what you got:
+Once the install is done, you switch to the `gitolite-admin` clone you just made on your workstation, and poke around to see what you got:
 
 	$ cd ~/gitolite-admin/
 	$ ls
 	conf/  keydir/
 	$ find conf keydir -type f
 	conf/gitolite.conf
-	keydir/sitaram.pub
+	keydir/scott.pub
 	$ cat conf/gitolite.conf
-	#gitolite conf
-	# please see conf/example.conf for details on syntax and features
 
 	repo gitolite-admin
-	    RW+                 = sitaram
+	    RW+                 = scott
 
 	repo testing
 	    RW+                 = @all
 
-Notice that "sitaram" (the last argument in the `gl-easy-install` command you gave earlier) has read-write permissions on the `gitolite-admin` repository as well as a public key file of the same name.
+Notice that "scott" (the name of the pubkey in the `gitolite setup` command you used earlier) has read-write permissions on the `gitolite-admin` repository as well as a public key file of the same name.
 
-The config file syntax for gitolite is liberally documented in `conf/example.conf`, so we'll only mention some highlights here.
+Adding users is easy.  To add a user called "alice", obtain her public key, name it `alice.pub`, and put it in the `keydir` directory of the clone of the `gitolite-admin` repo you just made on your workstation.  Add, commit, and push the change, and the user has been added.
 
-You can group users or repos for convenience.  The group names are just like macros; when defining them, it doesn't even matter whether they are projects or users; that distinction is only made when you *use* the "macro".
+The config file syntax for Gitolite is well documented, so we’ll only mention some highlights here.
+
+You can group users or repos for convenience.  The group names are just like macros; when defining them, it doesn’t even matter whether they are projects or users; that distinction is only made when you *use* the "macro".
 
 	@oss_repos      = linux perl rakudo git gitolite
 	@secret_repos   = fenestra pear
 
-	@admins         = scott     # Adams, not Chacon, sorry :)
-	@interns        = ashok     # get the spelling right, Scott!
+	@admins         = scott
+	@interns        = ashok
 	@engineers      = sitaram dilbert wally alice
 	@staff          = @admins @engineers @interns
 
@@ -601,74 +584,70 @@ You can control permissions at the "ref" level.  In the following example, inter
 	    RW  refs/tags/rc[0-9]   = @engineers
 	    RW+                     = @admins
 
-The expression after the `RW` or `RW+` is a regular expression (regex) that the refname (ref) being pushed is matched against.  So we call it a "refex"!  Of course, a refex can be far more powerful than shown here, so don't overdo it if you're not comfortable with perl regexes.
+The expression after the `RW` or `RW+` is a regular expression (regex) that the refname (ref) being pushed is matched against.  So we call it a "refex"!  Of course, a refex can be far more powerful than shown here, so don’t overdo it if you’re not comfortable with Perl regexes.
 
 Also, as you probably guessed, Gitolite prefixes `refs/heads/` as a syntactic convenience if the refex does not begin with `refs/`.
 
-An important feature of the config file's syntax is that all the rules for a repository need not be in one place.  You can keep all the common stuff together, like the rules for all `oss_repos` shown above, then add specific rules for specific cases later on, like so:
+An important feature of the config file’s syntax is that all the rules for a repository need not be in one place.  You can keep all the common stuff together, like the rules for all `oss_repos` shown above, then add specific rules for specific cases later on, like so:
 
 	repo gitolite
 	    RW+                     = sitaram
 
 That rule will just get added to the ruleset for the `gitolite` repository.
 
-At this point you might be wondering how the access control rules are actually applied, so let's go over that briefly.
+At this point you might be wondering how the access control rules are actually applied, so let’s go over that briefly.
 
-There are two levels of access control in gitolite.  The first is at the repository level; if you have read (or write) access to *any* ref in the repository, then you have read (or write) access to the repository.
+There are two levels of access control in Gitolite.  The first is at the repository level; if you have read (or write) access to *any* ref in the repository, then you have read (or write) access to the repository.  This is the only access control that Gitosis had.
 
 The second level, applicable only to "write" access, is by branch or tag within a repository.  The username, the access being attempted (`W` or `+`), and the refname being updated are known.  The access rules are checked in order of appearance in the config file, looking for a match for this combination (but remember that the refname is regex-matched, not merely string-matched).  If a match is found, the push succeeds.  A fallthrough results in access being denied.
 
 ### Advanced Access Control with "deny" rules ###
 
-So far, we've only seen permissions to be one of `R`, `RW`, or `RW+`.  However, gitolite allows another permission: `-`, standing for "deny".  This gives you a lot more power, at the expense of some complexity, because now fallthrough is not the *only* way for access to be denied, so the *order of the rules now matters*!
+So far, we’ve only seen permissions to be one of `R`, `RW`, or `RW+`.  However, Gitolite allows another permission: `-`, standing for "deny".  This gives you a lot more power, at the expense of some complexity, because now fallthrough is not the *only* way for access to be denied, so the *order of the rules now matters*!
 
-Let us say, in the situation above, we want engineers to be able to rewind any branch *except* master and integ.  Here's how to do that:
+Let us say, in the situation above, we want engineers to be able to rewind any branch *except* master and integ.  Here’s how to do that:
 
 	    RW  master integ    = @engineers
 	    -   master integ    = @engineers
 	    RW+                 = @engineers
 
-Again, you simply follow the rules top down until you hit a match for your access mode, or a deny.  Non-rewind push to master or integ is allowed by the first rule.  A rewind push to those refs does not match the first rule, drops down to the second, and is therefore denied.  Any push (rewind or non-rewind) to refs other than master or integ won't match the first two rules anyway, and the third rule allows it.
+Again, you simply follow the rules top down until you hit a match for your access mode, or a deny.  Non-rewind push to master or integ is allowed by the first rule.  A rewind push to those refs does not match the first rule, drops down to the second, and is therefore denied.  Any push (rewind or non-rewind) to refs other than master or integ won’t match the first two rules anyway, and the third rule allows it.
 
 ### Restricting pushes by files changed ###
 
-In addition to restricting what branches a user can push changes to, you can also restrict what files they are allowed to touch.  For example, perhaps the Makefile (or some other program) is really not supposed to be changed by just anyone, because a lot of things depend on it or would break if the changes are not done *just right*.  You can tell gitolite:
+In addition to restricting what branches a user can push changes to, you can also restrict what files they are allowed to touch.  For example, perhaps the Makefile (or some other program) is really not supposed to be changed by just anyone, because a lot of things depend on it or would break if the changes are not done *just right*.  You can tell Gitolite:
 
     repo foo
-        RW                  =   @junior_devs @senior_devs
+        RW                      =   @junior_devs @senior_devs
 
-        RW  NAME/           =   @senior_devs
-        -   NAME/Makefile   =   @junior_devs
-        RW  NAME/           =   @junior_devs
+        -   VREF/NAME/Makefile  =   @junior_devs
 
-This powerful feature is documented in `conf/example.conf`.
+Users who are migrating from the older Gitolite should note that there is a significant change in behaviour with regard to this feature; please see the migration guide for details.
 
 ### Personal Branches ###
 
 Gitolite also has a feature called "personal branches" (or rather, "personal branch namespace") that can be very useful in a corporate environment.
 
-A lot of code exchange in the git world happens by "please pull" requests.  In a corporate environment, however, unauthenticated access is a no-no, and a developer workstation cannot do authentication, so you have to push to the central server and ask someone to pull from there.
+A lot of code exchange in the Git world happens by "please pull" requests.  In a corporate environment, however, unauthenticated access is a no-no, and a developer workstation cannot do authentication, so you have to push to the central server and ask someone to pull from there.
 
 This would normally cause the same branch name clutter as in a centralised VCS, plus setting up permissions for this becomes a chore for the admin.
 
-Gitolite lets you define a "personal" or "scratch" namespace prefix for each developer (for example, `refs/personal/<devname>/*`); see the "personal branches" section in `doc/3-faq-tips-etc.mkd` for details.
+Gitolite lets you define a "personal" or "scratch" namespace prefix for each developer (for example, `refs/personal/<devname>/*`); please see the documentation for details.
 
 ### "Wildcard" repositories ###
 
-Gitolite allows you to specify repositories with wildcards (actually perl regexes), like, for example `assignments/s[0-9][0-9]/a[0-9][0-9]`, to pick a random example.  This is a *very* powerful feature, which has to be enabled by setting `$GL_WILDREPOS = 1;` in the rc file.  It allows you to assign a new permission mode ("C") which allows users to create repositories based on such wild cards, automatically assigns ownership to the specific user who created it, allows him/her to hand out R and RW permissions to other users to collaborate, etc.  This feature is documented in `doc/4-wildcard-repositories.mkd`.
+Gitolite allows you to specify repositories with wildcards (actually Perl regexes), like, for example `assignments/s[0-9][0-9]/a[0-9][0-9]`, to pick a random example.  It also allows you to assign a new permission mode (`C`) which enables users to create repositories based on such wild cards, automatically assigns ownership to the specific user who created it, allows him/her to hand out `R` and `RW` permissions to other users to collaborate, etc.  Again, please see the documentation for details.
 
 ### Other Features ###
 
-We'll round off this discussion with a sampling of other features, all of which, and many more, are described in great detail in the "faqs, tips, etc" and other documents.
+We’ll round off this discussion with a sampling of other features, all of which, and many more, are described in great detail in the documentation.
 
-**Logging**: Gitolite logs all successful accesses.  If you were somewhat relaxed about giving people rewind permissions (`RW+`) and some kid blew away "master", the log file is a life saver, in terms of easily and quickly finding the SHA that got hosed.
+**Logging**: Gitolite logs all successful accesses.  If you were somewhat relaxed about giving people rewind permissions (`RW+`) and some kid blew away `master`, the log file is a life saver, in terms of easily and quickly finding the SHA that got hosed.
 
-**Git outside normal PATH**: One extremely useful convenience feature in gitolite is support for git installed outside the normal `$PATH` (this is more common than you think; some corporate environments or even some hosting providers refuse to install things system-wide and you end up putting them in your own directories).  Normally, you are forced to make the *client-side* git aware of this non-standard location of the git binaries in some way.  With gitolite, just choose a verbose install and set `$GIT_PATH` in the "rc" files.  No client-side changes are required after that :-)
+**Access rights reporting**: Another convenient feature is what happens when you try and just ssh to the server.  Gitolite shows you what repos you have access to, and what that access may be.  Here’s an example:
 
-**Access rights reporting**: Another convenient feature is what happens when you try and just ssh to the server.  Gitolite shows you what repos you have access to, and what that access may be.  Here's an example:
+        hello scott, this is git@git running gitolite3 v3.01-18-g9609868 on git 1.7.4.4
 
-        hello sitaram, the gitolite version here is v1.5.4-19-ga3397d4
-        the gitolite config gives you the following access:
              R     anu-wsd
              R     entrans
              R  W  git-notes
@@ -677,9 +656,7 @@ We'll round off this discussion with a sampling of other features, all of which,
              R     indic_web_input
              R     shreelipi_converter
 
-**Delegation**: For really large installations, you can delegate responsibility for groups of repositories to various people and have them manage those pieces independently.  This reduces the load on the main admin, and makes him less of a bottleneck.  This feature has its own documentation file in the `doc/` directory.
-
-**Gitweb support**: Gitolite supports gitweb in several ways.  You can specify which repos are visible via gitweb.  You can set the "owner" and "description" for gitweb from the gitolite config file.  Gitweb has a mechanism for you to implement access control based on HTTP authentication, so you can make it use the "compiled" config file that gitolite produces, which means the same access control rules (for read access) apply for gitweb and gitolite.
+**Delegation**: For really large installations, you can delegate responsibility for groups of repositories to various people and have them manage those pieces independently.  This reduces the load on the main admin, and makes him less of a bottleneck.
 
 **Mirroring**: Gitolite can help you maintain multiple mirrors, and switch between them easily if the primary server goes down.
 
@@ -718,7 +695,7 @@ When you restart your machine, your Git daemon will start automatically and resp
 
 On other systems, you may want to use `xinetd`, a script in your `sysvinit` system, or something else — as long as you get that command daemonized and watched somehow.
 
-Next, you have to tell your Gitosis server which repositories to allow unauthenticated Git server-based access to. If you add a section for each repository, you can specify the ones from which you want your Git daemon to allow reading. If you want to allow Git protocol access for your iphone project, you add this to the end of the `gitosis.conf` file:
+Next, you have to tell your Gitosis server which repositories to allow unauthenticated Git server-based access to. If you add a section for each repository, you can specify the ones from which you want your Git daemon to allow reading. If you want to allow Git protocol access for the `iphone_project`, you add this to the end of the `gitosis.conf` file:
 
 	[repo iphone_project]
 	daemon = yes
@@ -739,13 +716,13 @@ Gitosis can also control which projects GitWeb shows. First, you need to add som
 	$export_ok = "git-daemon-export-ok";
 	@git_base_url_list = ('git://gitserver');
 
-You can control which projects GitWeb lets users browse by adding or removing a `gitweb` setting in the Gitosis configuration file. For instance, if you want the iphone project to show up on GitWeb, you make the `repo` setting look like this:
+You can control which projects GitWeb lets users browse by adding or removing a `gitweb` setting in the Gitosis configuration file. For instance, if you want the `iphone_project` to show up on GitWeb, you make the `repo` setting look like this:
 
 	[repo iphone_project]
 	daemon = yes
 	gitweb = yes
 
-Now, if you commit and push the project, GitWeb will automatically start showing your iphone project.
+Now, if you commit and push the project, GitWeb will automatically start showing the `iphone_project`.
 
 ## Hosted Git ##
 
@@ -755,7 +732,7 @@ These days, you have a huge number of hosting options to choose from, each with
 
 	https://git.wiki.kernel.org/index.php/GitHosting
 
-Because we can’t cover all of them, and because I happen to work at one of them, we’ll use this section to walk through setting up an account and creating a new project at GitHub. This will give you an idea of what is involved. 
+Because we can’t cover all of them, and because I happen to work at one of them, we’ll use this section to walk through setting up an account and creating a new project at GitHub. This will give you an idea of what is involved.
 
 GitHub is by far the largest open source Git hosting site and it’s also one of the very few that offers both public and private hosting options so you can keep your open source and private commercial code in the same place. In fact, we used GitHub to privately collaborate on this book.
 
@@ -767,39 +744,39 @@ GitHub is also a commercial company that charges for accounts that maintain priv
 
 ### Setting Up a User Account ###
 
-The first thing you need to do is set up a free user account. If you visit the Pricing and Signup page at `http://github.com/plans` and click the "Sign Up" button on the Free account (see figure 4-2), you’re taken to the signup page.
+The first thing you need to do is set up a free user account. If you visit the Pricing and Signup page at `http://github.com/plans` and click the "Sign Up" button on the Free account (see Figure 4-2), you’re taken to the signup page.
 
 Insert 18333fig0402.png
 Figure 4-2. The GitHub plan page.
 
 Here you must choose a username that isn’t yet taken in the system and enter an e-mail address that will be associated with the account and a password (see Figure 4-3).
 
-Insert 18333fig0403.png 
+Insert 18333fig0403.png
 Figure 4-3. The GitHub user signup form.
 
 If you have it available, this is a good time to add your public SSH key as well. We covered how to generate a new key earlier, in the "Simple Setups" section. Take the contents of the public key of that pair, and paste it into the SSH Public Key text box. Clicking the "explain ssh keys" link takes you to detailed instructions on how to do so on all major operating systems.
 Clicking the "I agree, sign me up" button takes you to your new user dashboard (see Figure 4-4).
 
-Insert 18333fig0404.png 
+Insert 18333fig0404.png
 Figure 4-4. The GitHub user dashboard.
 
-Next you can create a new repository. 
+Next you can create a new repository.
 
 ### Creating a New Repository ###
 
 Start by clicking the "create a new one" link next to Your Repositories on the user dashboard. You’re taken to the Create a New Repository form (see Figure 4-5).
 
-Insert 18333fig0405.png 
+Insert 18333fig0405.png
 Figure 4-5. Creating a new repository on GitHub.
 
 All you really have to do is provide a project name, but you can also add a description. When that is done, click the "Create Repository" button. Now you have a new repository on GitHub (see Figure 4-6).
 
-Insert 18333fig0406.png 
+Insert 18333fig0406.png
 Figure 4-6. GitHub project header information.
 
 Since you have no code there yet, GitHub will show you instructions for how create a brand-new project, push an existing Git project up, or import a project from a public Subversion repository (see Figure 4-7).
 
-Insert 18333fig0407.png 
+Insert 18333fig0407.png
 Figure 4-7. Instructions for a new repository.
 
 These instructions are similar to what we’ve already gone over. To initialize a project if it isn’t already a Git project, you use
@@ -815,7 +792,7 @@ When you have a Git repository locally, add GitHub as a remote and push up your
 
 Now your project is hosted on GitHub, and you can give the URL to anyone you want to share your project with. In this case, it’s `http://github.com/testinguser/iphone_project`. You can also see from the header on each of your project’s pages that you have two Git URLs (see Figure 4-8).
 
-Insert 18333fig0408.png 
+Insert 18333fig0408.png
 Figure 4-8. Project header with a public URL and a private URL.
 
 The Public Clone URL is a public, read-only Git URL over which anyone can clone the project. Feel free to give out that URL and post it on your web site or what have you.
@@ -826,7 +803,7 @@ The Your Clone URL is a read/write SSH-based URL that you can read or write over
 
 If you have an existing public Subversion project that you want to import into Git, GitHub can often do that for you. At the bottom of the instructions page is a link to a Subversion import. If you click it, you see a form with information about the import process and a text box where you can paste in the URL of your public Subversion project (see Figure 4-9).
 
-Insert 18333fig0409.png 
+Insert 18333fig0409.png
 Figure 4-9. Subversion importing interface.
 
 If your project is very large, nonstandard, or private, this process probably won’t work for you. In Chapter 7, you’ll learn how to do more complicated manual project imports.
@@ -837,17 +814,17 @@ Let’s add the rest of the team. If John, Josie, and Jessica all sign up for ac
 
 Click the "edit" button in the project header or the Admin tab at the top of the project to reach the Admin page of your GitHub project (see Figure 4-10).
 
-Insert 18333fig0410.png 
+Insert 18333fig0410.png
 Figure 4-10. GitHub administration page.
 
 To give another user write access to your project, click the “Add another collaborator” link. A new text box appears, into which you can type a username. As you type, a helper pops up, showing you possible username matches. When you find the correct user, click the Add button to add that user as a collaborator on your project (see Figure 4-11).
 
-Insert 18333fig0411.png 
+Insert 18333fig0411.png
 Figure 4-11. Adding a collaborator to your project.
 
 When you’re finished adding collaborators, you should see a list of them in the Repository Collaborators box (see Figure 4-12).
 
-Insert 18333fig0412.png 
+Insert 18333fig0412.png
 Figure 4-12. A list of collaborators on your project.
 
 If you need to revoke access to individuals, you can click the "revoke" link, and their push access will be removed. For future projects, you can also copy collaborator groups by copying the permissions of an existing project.
@@ -856,7 +833,7 @@ If you need to revoke access to individuals, you can click the "revoke" link, an
 
 After you push your project up or have it imported from Subversion, you have a main project page that looks something like Figure 4-13.
 
-Insert 18333fig0413.png 
+Insert 18333fig0413.png
 Figure 4-13. A GitHub main project page.
 
 When people visit your project, they see this page. It contains tabs to different aspects of your projects. The Commits tab shows a list of commits in reverse chronological order, similar to the output of the `git log` command. The Network tab shows all the people who have forked your project and contributed back. The Downloads tab allows you to upload project binaries and link to tarballs and zipped versions of any tagged points in your project. The Wiki tab provides a wiki where you can write documentation or other information about your project. The Graphs tab has some contribution visualizations and statistics about your project. The main Source tab that you land on shows your project’s main directory listing and automatically renders the README file below it if you have one. This tab also shows a box with the latest commit information.
@@ -869,12 +846,12 @@ This way, projects don’t have to worry about adding users as collaborators to
 
 To fork a project, visit the project page (in this case, mojombo/chronic) and click the "fork" button in the header (see Figure 4-14).
 
-Insert 18333fig0414.png 
+Insert 18333fig0414.png
 Figure 4-14. Get a writable copy of any repository by clicking the "fork" button.
 
 After a few seconds, you’re taken to your new project page, which indicates that this project is a fork of another one (see Figure 4-15).
 
-Insert 18333fig0415.png 
+Insert 18333fig0415.png
 Figure 4-15. Your fork of a project.
 
 ### GitHub Summary ###
diff --git a/no-nb/05-distributed-git/01-chapter5.markdown b/no-nb/05-distributed-git/01-chapter5.markdown
index e72635415..bb6a633e4 100644
--- a/no-nb/05-distributed-git/01-chapter5.markdown
+++ b/no-nb/05-distributed-git/01-chapter5.markdown
@@ -22,7 +22,7 @@ This workflow is attractive to a lot of people because it’s a paradigm that ma
 
 ### Integration-Manager Workflow ###
 
-Because Git allows you to have multiple remote repositories, it’s possible to have a workflow where each developer has write access to their own public repository and read access to everyone else’s. This scenario often includes a canonical repository that represents the "official" project. To contribute to that project, you create your own public clone of the project and push your changes to it. Then, you can send a request to the maintainer of the main project to pull in your changes. They can add your repository as a remote, test your changes locally, merge them into their branch, and push back to their repository. The process works as follow (see Figure 5-2):
+Because Git allows you to have multiple remote repositories, it’s possible to have a workflow where each developer has write access to their own public repository and read access to everyone else’s. This scenario often includes a canonical repository that represents the "official" project. To contribute to that project, you create your own public clone of the project and push your changes to it. Then, you can send a request to the maintainer of the main project to pull in your changes. They can add your repository as a remote, test your changes locally, merge them into their branch, and push back to their repository. The process works as follows (see Figure 5-2):
 
 1. The project maintainer pushes to their public repository.
 2. A contributor clones that repository and makes changes.
@@ -48,7 +48,7 @@ This is a variant of a multiple-repository workflow. It’s generally used by hu
 Insert 18333fig0503.png
 Figure 5-3. Benevolent dictator workflow.
 
-This kind of workflow isn’t common but can be useful in very big projects or in highly hierarchical environments, because as it allows the project leader (the dictator) to delegate much of the work and collect large subsets of code at multiple points before integrating them.
+This kind of workflow isn’t common but can be useful in very big projects or in highly hierarchical environments, as it allows the project leader (the dictator) to delegate much of the work and collect large subsets of code at multiple points before integrating them.
 
 These are some commonly used workflows that are possible with a distributed system like Git, but you can see that many variations are possible to suit your particular real-world workflow. Now that you can (I hope) determine which workflow combination may work for you, I’ll cover some more specific examples of how to accomplish the main roles that make up the different flows.
 
@@ -174,7 +174,7 @@ John has a reference to the changes Jessica pushed up, but he has to merge them
 The merge goes smoothly — John’s commit history now looks like Figure 5-5.
 
 Insert 18333fig0505.png
-Figure 5-5. John’s repository after merging origin/master.
+Figure 5-5. John’s repository after merging `origin/master`.
 
 Now, John can test his code to make sure it still works properly, and then he can push his new merged work up to the server:
 
@@ -215,7 +215,7 @@ Jessica thinks her topic branch is ready, but she wants to know what she has to
 
 	    removed invalid default value
 
-Now, Jessica can merge her topic work into her master branch, merge John’s work (`origin/master`) into her `master` branch, and then push back to the server again. First, she switches back to her master branch to integrate all this work:
+Now, Jessica can merge her topic work into her `master` branch, merge John’s work (`origin/master`) into her `master` branch, and then push back to the server again. First, she switches back to her `master` branch to integrate all this work:
 
 	$ git checkout master
 	Switched to branch "master"
@@ -230,7 +230,7 @@ She can merge either `origin/master` or `issue54` first — they’re both upstr
 	 lib/simplegit.rb |    6 +++++-
 	 2 files changed, 6 insertions(+), 1 deletions(-)
 
-No problems occur; as you can see it, was a simple fast-forward. Now Jessica merges in John’s work (`origin/master`):
+No problems occur; as you can see, it was a simple fast-forward. Now Jessica merges in John’s work (`origin/master`):
 
 	$ git merge origin/master
 	Auto-merging lib/simplegit.rb
@@ -255,7 +255,7 @@ Each developer has committed a few times and merged each other’s work successf
 Insert 18333fig0510.png
 Figure 5-10. Jessica’s history after pushing all changes back to the server.
 
-That is one of the simplest workflows. You work for a while, generally in a topic branch, and merge into your master branch when it’s ready to be integrated. When you want to share that work, you merge it into your own master branch, then fetch and merge `origin/master` if it has changed, and finally push to the `master` branch on the server. The general sequence is something like that shown in Figure 5-11.
+That is one of the simplest workflows. You work for a while, generally in a topic branch, and merge into your `master` branch when it’s ready to be integrated. When you want to share that work, you merge it into your own `master` branch, then fetch and merge `origin/master` if it has changed, and finally push to the `master` branch on the server. The general sequence is something like that shown in Figure 5-11.
 
 Insert 18333fig0511.png
 Figure 5-11. General sequence of events for a simple multiple-developer Git workflow.
@@ -359,12 +359,12 @@ Finally, she merges John’s work into her own `featureA` branch:
 Jessica wants to tweak something, so she commits again and then pushes this back up to the server:
 
 	$ git commit -am 'small tweak'
-	[featureA ed774b3] small tweak
+	[featureA 774b3ed] small tweak
 	 1 files changed, 1 insertions(+), 1 deletions(-)
 	$ git push origin featureA
 	...
 	To jessica@githost:simplegit.git
-	   3300904..ed774b3  featureA -> featureA
+	   3300904..774b3ed  featureA -> featureA
 
 Jessica’s commit history now looks something like Figure 5-13.
 
@@ -481,7 +481,7 @@ The workflow is similar to the previous use case — you create topic branches f
 	$ (work)
 	$ git commit
 
-Now you have two commits that you want to send to the mailing list. You use `git format-patch` to generate the mbox-formatted files that you can e-mail to the list — it turns each commit into an e-mail message with the first line of the commit message as the subject and the rest of the message plus the patch that the commit introduces as the body. The nice thing about this is that applying a patch from an e-mail generated with `format-patch` preserves all the commit information properly, as you’ll see more of in the next section when you apply these commits:
+Now you have two commits that you want to send to the mailing list. You use `git format-patch` to generate the mbox-formatted files that you can e-mail to the list — it turns each commit into an e-mail message with the first line of the commit message as the subject and the rest of the message plus the patch that the commit introduces as the body. The nice thing about this is that applying a patch from an e-mail generated with `format-patch` preserves all the commit information properly, as you’ll see more of in the next section when you apply these patches:
 
 	$ git format-patch -M origin/master
 	0001-add-limit-to-log-function.patch
@@ -532,7 +532,26 @@ First, you need to set up the imap section in your `~/.gitconfig` file. You can
 	  sslverify = false
 
 If your IMAP server doesn’t use SSL, the last two lines probably aren’t necessary, and the host value will be `imap://` instead of `imaps://`.
-When that is set up, you can use `git send-email` to place the patch series in the Drafts folder of the specified IMAP server:
+When that is set up, you can use `git imap-send` to place the patch series in the Drafts folder of the specified IMAP server:
+
+	$ cat *.patch |git imap-send
+	Resolving imap.gmail.com... ok
+	Connecting to [74.125.142.109]:993... ok
+	Logging in...
+	sending 2 messages
+	100% (2/2) done
+
+At this point, you should be able to go to your Drafts folder, change the To field to the mailing list you’re sending the patch to, possibly CC the maintainer or person responsible for that section, and send it off.
+
+You can also send the patches through an SMTP server. As before, you can set each value separately with a series of `git config` commands, or you can add them manually in the sendemail section in your `~/.gitconfig` file:
+
+	[sendemail]
+	  smtpencryption = tls
+	  smtpserver = smtp.gmail.com
+	  smtpuser = user@gmail.com
+	  smtpserverport = 587
+
+After this is done, you can use `git send-email` to send your patches:
 
 	$ git send-email *.patch
 	0001-added-limit-to-log-function.patch
@@ -559,8 +578,6 @@ Then, Git spits out a bunch of log information looking something like this for e
 
 	Result: OK
 
-At this point, you should be able to go to your Drafts folder, change the To field to the mailing list you’re sending the patch to, possibly CC the maintainer or person responsible for that section, and send it off.
-
 ### Summary ###
 
 This section has covered a number of common workflows for dealing with several very different types of Git projects you’re likely to encounter and introduced a couple of new tools to help you manage this process. Next, you’ll see how to work the other side of the coin: maintaining a Git project. You’ll learn how to be a benevolent dictator or integration manager.
@@ -576,7 +593,7 @@ As you’ll remember, you can create the branch based off your master branch lik
 
 	$ git branch sc/ruby_client master
 
-Or, if you want to also switch to it immediately, you can use the `checkout -b` option:
+Or, if you want to also switch to it immediately, you can use the `checkout -b` command:
 
 	$ git checkout -b sc/ruby_client master
 
@@ -594,7 +611,7 @@ If you received the patch from someone who generated it with the `git diff` or a
 
 This modifies the files in your working directory. It’s almost identical to running a `patch -p1` command to apply the patch, although it’s more paranoid and accepts fewer fuzzy matches than patch. It also handles file adds, deletes, and renames if they’re described in the `git diff` format, which `patch` won’t do. Finally, `git apply` is an "apply all or abort all" model where either everything is applied or nothing is, whereas `patch` can partially apply patchfiles, leaving your working directory in a weird state. `git apply` is overall much more paranoid than `patch`. It won’t create a commit for you — after running it, you must stage and commit the changes introduced manually.
 
-You can also use git apply to see if a patch applies cleanly before you try actually applying it — you can run `git apply --check` with the patch:
+You can also use `git apply` to see if a patch applies cleanly before you try actually applying it — you can run `git apply --check` with the patch:
 
 	$ git apply --check 0001-seeing-if-this-helps-the-gem.patch
 	error: patch failed: ticgit.gemspec:1
@@ -615,7 +632,7 @@ To apply a patch generated by `format-patch`, you use `git am`. Technically, `gi
 
 	Limit log functionality to the first 20
 
-This is the beginning of the output of the format-patch command that you saw in the previous section. This is also a valid mbox e-mail format. If someone has e-mailed you the patch properly using git send-email, and you download that into an mbox format, then you can point git am to that mbox file, and it will start applying all the patches it sees. If you run a mail client that can save several e-mails out in mbox format, you can save entire patch series into a file and then use git am to apply them one at a time.
+This is the beginning of the output of the format-patch command that you saw in the previous section. This is also a valid mbox e-mail format. If someone has e-mailed you the patch properly using `git send-email`, and you download that into an mbox format, then you can point `git am` to that mbox file, and it will start applying all the patches it sees. If you run a mail client that can save several e-mails out in mbox format, you can save entire patch series into a file and then use `git am` to apply them one at a time.
 
 However, if someone uploaded a patch file generated via `format-patch` to a ticketing system or something similar, you can save the file locally and then pass that file saved on your disk to `git am` to apply it:
 
diff --git a/no-nb/06-git-tools/01-chapter6.markdown b/no-nb/06-git-tools/01-chapter6.markdown
index a6f0108af..eaa9b42a0 100644
--- a/no-nb/06-git-tools/01-chapter6.markdown
+++ b/no-nb/06-git-tools/01-chapter6.markdown
@@ -57,7 +57,7 @@ Generally, eight to ten characters are more than enough to be unique within a pr
 
 A lot of people become concerned at some point that they will, by random happenstance, have two objects in their repository that hash to the same SHA-1 value. What then?
 
-If you do happen to commit an object that hashes to the same SHA-1 value as a previous object in your repository, Git will see the previous object already in your Git database and assume it was already written. If you try to check out that object again at some point, you’ll always get the data of the first object. 
+If you do happen to commit an object that hashes to the same SHA-1 value as a previous object in your repository, Git will see the previous object already in your Git database and assume it was already written. If you try to check out that object again at some point, you’ll always get the data of the first object.
 
 However, you should be aware of how ridiculously unlikely this scenario is. The SHA-1 digest is 20 bytes or 160 bits. The number of randomly hashed objects needed to ensure a 50% probability of a single collision is about 2^80 (the formula for determining collision probability is `p = (n(n-1)/2) * (1/2^160)`). 2^80 is 1.2 x 10^24 or 1 million billion billion. That’s 1,200 times the number of grains of sand on the earth.
 
@@ -82,13 +82,13 @@ One of the things Git does in the background while you’re working away is keep
 You can see your reflog by using `git reflog`:
 
 	$ git reflog
-	734713b... HEAD@{0}: commit: fixed refs handling, added gc auto, updated
-	d921970... HEAD@{1}: merge phedders/rdocs: Merge made by recursive.
-	1c002dd... HEAD@{2}: commit: added some blame and merge stuff
-	1c36188... HEAD@{3}: rebase -i (squash): updating HEAD
-	95df984... HEAD@{4}: commit: # This is a combination of two commits.
-	1c36188... HEAD@{5}: rebase -i (squash): updating HEAD
-	7e05da5... HEAD@{6}: rebase -i (pick): updating HEAD
+	734713b HEAD@{0}: commit: fixed refs handling, added gc auto, updated
+	d921970 HEAD@{1}: merge phedders/rdocs: Merge made by recursive.
+	1c002dd HEAD@{2}: commit: added some blame and merge stuff
+	1c36188 HEAD@{3}: rebase -i (squash): updating HEAD
+	95df984 HEAD@{4}: commit: # This is a combination of two commits.
+	1c36188 HEAD@{5}: rebase -i (squash): updating HEAD
+	7e05da5 HEAD@{6}: rebase -i (pick): updating HEAD
 
 Every time your branch tip is updated for any reason, Git stores that information for you in this temporary history. And you can specify older commits with this data, as well. If you want to see the fifth prior value of the HEAD of your repository, you can use the `@{n}` reference that you see in the reflog output:
 
@@ -105,7 +105,7 @@ To see reflog information formatted like the `git log` output, you can run `git
 	$ git log -g master
 	commit 734713bc047d87bf7eac9674765ae793478c50d3
 	Reflog: master@{0} (Scott Chacon <schacon@gmail.com>)
-	Reflog message: commit: fixed refs handling, added gc auto, updated 
+	Reflog message: commit: fixed refs handling, added gc auto, updated
 	Author: Scott Chacon <schacon@gmail.com>
 	Date:   Fri Jan 2 18:32:33 2009 -0800
 
@@ -119,7 +119,7 @@ To see reflog information formatted like the `git log` output, you can run `git
 
 	    Merge commit 'phedders/rdocs'
 
-It’s important to note that the reflog information is strictly local — it’s a log of what you’ve done in your repository. The references won’t be the same on someone else’s copy of the repository; and right after you initially clone a repository, you'll have an empty reflog, as no activity has occurred yet in your repository. Running `git show HEAD@{2.months.ago}` will work only if you cloned the project at least two months ago — if you cloned it five minutes ago, you’ll get no results.
+It’s important to note that the reflog information is strictly local — it’s a log of what you’ve done in your repository. The references won’t be the same on someone else’s copy of the repository; and right after you initially clone a repository, you’ll have an empty reflog, as no activity has occurred yet in your repository. Running `git show HEAD@{2.months.ago}` will work only if you cloned the project at least two months ago — if you cloned it five minutes ago, you’ll get no results.
 
 ### Ancestry References ###
 
@@ -129,10 +129,10 @@ Suppose you look at the history of your project:
 	$ git log --pretty=format:'%h %s' --graph
 	* 734713b fixed refs handling, added gc auto, updated tests
 	*   d921970 Merge commit 'phedders/rdocs'
-	|\  
+	|\
 	| * 35cfb2b Some rdoc changes
 	* | 1c002dd added some blame and merge stuff
-	|/  
+	|/
 	* 1c36188 ignore *.gem
 	* 9b29157 add open3_detach to gemspec file list
 
@@ -190,7 +190,7 @@ Now that you can specify individual commits, let’s see how to specify ranges o
 
 The most common range specification is the double-dot syntax. This basically asks Git to resolve a range of commits that are reachable from one commit but aren’t reachable from another. For example, say you have a commit history that looks like Figure 6-1.
 
-Insert 18333fig0601.png 
+Insert 18333fig0601.png
 Figure 6-1. Example history for range selection.
 
 You want to see what is in your experiment branch that hasn’t yet been merged into your master branch. You can ask Git to show you a log of just those commits with `master..experiment` — that means "all commits reachable by experiment that aren’t reachable by master." For the sake of brevity and clarity in these examples, I’ll use the letters of the commit objects from the diagram in place of the actual log output in the order that they would display:
@@ -248,7 +248,7 @@ A common switch to use with the `log` command in this case is `--left-right`, wh
 	> D
 	> C
 
-With these tools, you can much more easily let Git know what commit or commits you want to inspect. 
+With these tools, you can much more easily let Git know what commit or commits you want to inspect.
 
 ## Interactive Staging ##
 
@@ -264,9 +264,9 @@ If you run `git add` with the `-i` or `--interactive` option, Git goes into an i
 	*** Commands ***
 	  1: status     2: update      3: revert     4: add untracked
 	  5: patch      6: diff        7: quit       8: help
-	What now> 
+	What now>
 
-You can see that this command shows you a much different view of your staging area — basically the same information you get with `git status` but a bit more succinct and informative. It lists the changes you’ve staged on the left and unstaged changes on the right. 
+You can see that this command shows you a much different view of your staging area — basically the same information you get with `git status` but a bit more succinct and informative. It lists the changes you’ve staged on the left and unstaged changes on the right.
 
 After this comes a Commands section. Here you can do a number of things, including staging files, unstaging files, staging parts of files, adding untracked files, and seeing diffs of what has been staged.
 
@@ -292,7 +292,7 @@ To stage the TODO and index.html files, you can type the numbers:
 
 The `*` next to each file means the file is selected to be staged. If you press Enter after typing nothing at the `Update>>` prompt, Git takes anything selected and stages it for you:
 
-	Update>> 
+	Update>>
 	updated 2 paths
 
 	*** Commands ***
@@ -374,7 +374,7 @@ It’s also possible for Git to stage certain parts of files and not the rest. F
 	   end
 
 	   def blame(path)
-	Stage this hunk [y,n,a,d,/,j,J,g,e,?]? 
+	Stage this hunk [y,n,a,d,/,j,J,g,e,?]?
 
 You have a lot of options at this point. Typing `?` shows a list of what you can do:
 
@@ -403,7 +403,7 @@ Generally, you’ll type `y` or `n` if you want to stage each hunk, but staging
 
 The status of the simplegit.rb file is interesting. It shows you that a couple of lines are staged and a couple are unstaged. You’ve partially staged this file. At this point, you can exit the interactive adding script and run `git commit` to commit the partially staged files.
 
-Finally, you don’t need to be in interactive add mode to do the partial-file staging — you can start the same script by using `git add -p` or `git add --patch` on the command line. 
+Finally, you don’t need to be in interactive add mode to do the partial-file staging — you can start the same script by using `git add -p` or `git add --patch` on the command line.
 
 ## Stashing ##
 
@@ -446,8 +446,8 @@ At this point, you can easily switch branches and do work elsewhere; your change
 
 	$ git stash list
 	stash@{0}: WIP on master: 049d078 added the index file
-	stash@{1}: WIP on master: c264051... Revert "added file_size"
-	stash@{2}: WIP on master: 21d80a5... added number to log
+	stash@{1}: WIP on master: c264051 Revert "added file_size"
+	stash@{2}: WIP on master: 21d80a5 added number to log
 
 In this case, two stashes were done previously, so you have access to three different stashed works. You can reapply the one you just stashed by using the command shown in the help output of the original stash command: `git stash apply`. If you want to apply one of the older stashes, you can specify it by naming it, like this: `git stash apply stash@{2}`. If you don’t specify a stash, Git assumes the most recent stash and tries to apply it:
 
@@ -481,8 +481,8 @@ The apply option only tries to apply the stashed work — you continue to have i
 
 	$ git stash list
 	stash@{0}: WIP on master: 049d078 added the index file
-	stash@{1}: WIP on master: c264051... Revert "added file_size"
-	stash@{2}: WIP on master: 21d80a5... added number to log
+	stash@{1}: WIP on master: c264051 Revert "added file_size"
+	stash@{2}: WIP on master: 21d80a5 added number to log
 	$ git stash drop stash@{0}
 	Dropped stash@{0} (364e91f3f268f0900bc3ee613f9f733e82aaed43)
 
@@ -498,7 +498,7 @@ Again, if you don’t specify a stash, Git assumes the most recent stash:
 
     $ git stash show -p | git apply -R
 
-You may want to create an alias and effectively add a `stash-unapply` command to your git. For example:
+You may want to create an alias and effectively add a `stash-unapply` command to your Git. For example:
 
     $ git config --global alias.stash-unapply '!git stash show -p | git apply -R'
     $ git stash
@@ -566,12 +566,19 @@ Running this command gives you a list of commits in your text editor that looks
 	#
 	# Commands:
 	#  p, pick = use commit
+	#  r, reword = use commit, but edit the commit message
 	#  e, edit = use commit, but stop for amending
 	#  s, squash = use commit, but meld into previous commit
+	#  f, fixup = like "squash", but discard this commit's log message
+	#  x, exec = run command (the rest of the line) using shell
+	#
+	# These lines can be re-ordered; they are executed from top to bottom.
 	#
 	# If you remove a line here THAT COMMIT WILL BE LOST.
+	#
 	# However, if you remove everything, the rebase will be aborted.
 	#
+	# Note that empty commits are commented out
 
 It’s important to note that these commits are listed in the opposite order than you normally see them using the `log` command. If you run a `log`, you see something like this:
 
@@ -590,6 +597,10 @@ You need to edit the script so that it stops at the commit you want to edit. To
 
 When you save and exit the editor, Git rewinds you back to the last commit in that list and drops you on the command line with the following message:
 
+<!-- This is actually weird, as the SHA-1 of 7482e0d is not present in the list, 
+nor is the commit message. Please review 
+-->
+
 	$ git rebase -i HEAD~3
 	Stopped at 7482e0d... updated the gemspec to hopefully work better
 	You can amend the commit now, with
@@ -632,12 +643,19 @@ It’s also possible to take a series of commits and squash them down into a sin
 	#
 	# Commands:
 	#  p, pick = use commit
+	#  r, reword = use commit, but edit the commit message
 	#  e, edit = use commit, but stop for amending
 	#  s, squash = use commit, but meld into previous commit
+	#  f, fixup = like "squash", but discard this commit's log message
+	#  x, exec = run command (the rest of the line) using shell
+	#
+	# These lines can be re-ordered; they are executed from top to bottom.
 	#
 	# If you remove a line here THAT COMMIT WILL BE LOST.
+	#
 	# However, if you remove everything, the rebase will be aborted.
 	#
+	# Note that empty commits are commented out
 
 If, instead of "pick" or "edit", you specify "squash", Git applies both that change and the change directly before it and makes you merge the commit messages together. So, if you want to make a single commit from these three commits, you make the script look like this:
 
@@ -669,7 +687,7 @@ Splitting a commit undoes a commit and then partially stages and commits as many
 	edit 310154e updated README formatting and added blame
 	pick a5f4a0d added cat-file
 
-Then, when the script drops you to the command line, you reset that commit, take the changes that have been reset, and create multiple commits out of them. When you save and exit the editor, Git rewinds to the parent of the first commit in your list, applies the first commit (`f7f3f6d`), applies the second (`310154e`), and drops you to the console. There, you can do a mixed reset of that commit with `git reset HEAD^`, which effectively undoes that commit and leaves the modified files unstaged. Now you can stage and commit files until you have several commits, and run `git rebase --continue` when you’re done:
+When you save and exit the editor, Git rewinds to the parent of the first commit in your list, applies the first commit (`f7f3f6d`), applies the second (`310154e`), and drops you to the console. There, you can do a mixed reset of that commit with `git reset HEAD^`, which effectively undoes that commit and leaves the modified files unstaged. Now you can take the changes that have been reset, and create multiple commits out of them. Simply stage and commit files until you have several commits, and run `git rebase --continue` when you’re done:
 
 	$ git reset HEAD^
 	$ git add README
@@ -700,7 +718,7 @@ This occurs fairly commonly. Someone accidentally commits a huge binary file wit
 	Rewrite 6b9b3cf04e7c5686a9cb838c3f36a8cb6a0fc2bd (21/21)
 	Ref 'refs/heads/master' was rewritten
 
-The `--tree-filter` option runs the specified command after each checkout of the project and then recommits the results. In this case, you remove a file called passwords.txt from every snapshot, whether it exists or not. If you want to remove all accidentally committed editor backup files, you can run something like `git filter-branch --tree-filter "find * -type f -name '*~' -delete" HEAD`.
+The `--tree-filter` option runs the specified command after each checkout of the project and then recommits the results. In this case, you remove a file called passwords.txt from every snapshot, whether it exists or not. If you want to remove all accidentally committed editor backup files, you can run something like `git filter-branch --tree-filter "rm -f *~" HEAD`.
 
 You’ll be able to watch Git rewriting trees and commits and then move the branch pointer at the end. It’s generally a good idea to do this in a testing branch and then hard-reset your master branch after you’ve determined the outcome is what you really want. To run `filter-branch` on all your branches, you can pass `--all` to the command.
 
@@ -712,7 +730,7 @@ Suppose you’ve done an import from another source control system and have subd
 	Rewrite 856f0bf61e41a27326cdae8f09fe708d679f596f (12/12)
 	Ref 'refs/heads/master' was rewritten
 
-Now your new project root is what was in the `trunk` subdirectory each time. Git will also automatically remove commits that did not affect the subdirectory. 
+Now your new project root is what was in the `trunk` subdirectory each time. Git will also automatically remove commits that did not affect the subdirectory.
 
 #### Changing E-Mail Addresses Globally ####
 
@@ -738,7 +756,7 @@ Git also provides a couple of tools to help you debug issues in your projects. B
 
 If you track down a bug in your code and want to know when it was introduced and why, file annotation is often your best tool. It shows you what commit was the last to modify each line of any file. So, if you see that a method in your code is buggy, you can annotate the file with `git blame` to see when each line of the method was last edited and by whom. This example uses the `-L` option to limit the output to lines 12 through 22:
 
-	$ git blame -L 12,22 simplegit.rb 
+	$ git blame -L 12,22 simplegit.rb
 	^4832fe2 (Scott Chacon  2008-03-15 10:31:28 -0700 12)  def show(tree = 'master')
 	^4832fe2 (Scott Chacon  2008-03-15 10:31:28 -0700 13)   command("git show #{tree}")
 	^4832fe2 (Scott Chacon  2008-03-15 10:31:28 -0700 14)  end
@@ -746,7 +764,7 @@ If you track down a bug in your code and want to know when it was introduced and
 	9f6560e4 (Scott Chacon  2008-03-17 21:52:20 -0700 16)  def log(tree = 'master')
 	79eaf55d (Scott Chacon  2008-04-06 10:15:08 -0700 17)   command("git log #{tree}")
 	9f6560e4 (Scott Chacon  2008-03-17 21:52:20 -0700 18)  end
-	9f6560e4 (Scott Chacon  2008-03-17 21:52:20 -0700 19) 
+	9f6560e4 (Scott Chacon  2008-03-17 21:52:20 -0700 19)
 	42cf2861 (Magnus Chacon 2008-04-13 10:45:01 -0700 20)  def blame(path)
 	42cf2861 (Magnus Chacon 2008-04-13 10:45:01 -0700 21)   command("git blame #{path}")
 	42cf2861 (Magnus Chacon 2008-04-13 10:45:01 -0700 22)  end
@@ -755,8 +773,8 @@ Notice that the first field is the partial SHA-1 of the commit that last modifie
 
 Another cool thing about Git is that it doesn’t track file renames explicitly. It records the snapshots and then tries to figure out what was renamed implicitly, after the fact. One of the interesting features of this is that you can ask it to figure out all sorts of code movement as well. If you pass `-C` to `git blame`, Git analyzes the file you’re annotating and tries to figure out where snippets of code within it originally came from if they were copied from elsewhere. Recently, I was refactoring a file named `GITServerHandler.m` into multiple files, one of which was `GITPackUpload.m`. By blaming `GITPackUpload.m` with the `-C` option, I could see where sections of the code originally came from:
 
-	$ git blame -C -L 141,153 GITPackUpload.m 
-	f344f58d GITServerHandler.m (Scott 2009-01-04 141) 
+	$ git blame -C -L 141,153 GITPackUpload.m
+	f344f58d GITServerHandler.m (Scott 2009-01-04 141)
 	f344f58d GITServerHandler.m (Scott 2009-01-04 142) - (void) gatherObjectShasFromC
 	f344f58d GITServerHandler.m (Scott 2009-01-04 143) {
 	70befddd GITServerHandler.m (Scott 2009-03-22 144)         //NSLog(@"GATHER COMMI
@@ -853,7 +871,7 @@ Now you have the Rack project under a subdirectory named `rack` within your proj
 
 First you notice the `.gitmodules` file. This is a configuration file that stores the mapping between the project’s URL and the local subdirectory you’ve pulled it into:
 
-	$ cat .gitmodules 
+	$ cat .gitmodules
 	[submodule "rack"]
 	      path = rack
 	      url = git://github.com/chneukirchen/rack.git
@@ -993,7 +1011,7 @@ Then, you e-mail that guy and yell at him.
 
 Sometimes, developers want to get a combination of a large project’s subdirectories, depending on what team they’re on. This is common if you’re coming from CVS or Subversion, where you’ve defined a module or collection of subdirectories, and you want to keep this type of workflow.
 
-A good way to do this in Git is to make each of the subfolders a separate Git repository and then create superproject Git repositories that contain multiple submodules. A benefit of this approach is that you can more specifically define the relationships between the projects with tags and branches in the superprojects.
+A good way to do this in Git is to make each of the subdirectories a separate Git repository and then create superproject Git repositories that contain multiple submodules. A benefit of this approach is that you can more specifically define the relationships between the projects with tags and branches in the superprojects.
 
 ### Issues with Submodules ###
 
diff --git a/no-nb/07-customizing-git/01-chapter7.markdown b/no-nb/07-customizing-git/01-chapter7.markdown
index 2a800faf9..de99afcd7 100644
--- a/no-nb/07-customizing-git/01-chapter7.markdown
+++ b/no-nb/07-customizing-git/01-chapter7.markdown
@@ -4,16 +4,16 @@ So far, I’ve covered the basics of how Git works and how to use it, and I’ve
 
 ## Git Configuration ##
 
-As you briefly saw in the Chapter 1, you can specify Git configuration settings with the `git config` command. One of the first things you did was set up your name and e-mail address:
+As you briefly saw in Chapter 1, you can specify Git configuration settings with the `git config` command. One of the first things you did was set up your name and e-mail address:
 
 	$ git config --global user.name "John Doe"
 	$ git config --global user.email johndoe@example.com
 
 Now you’ll learn a few of the more interesting options that you can set in this manner to customize your Git usage.
 
-You saw some simple Git configuration details in the first chapter, but I’ll go over them again quickly here. Git uses a series of configuration files to determine non-default behavior that you may want. The first place Git looks for these values is in an `/etc/gitconfig` file, which contains values for every user on the system and all of their repositories. If you pass the option `--system` to `git config`, it reads and writes from this file specifically. 
+You saw some simple Git configuration details in the first chapter, but I’ll go over them again quickly here. Git uses a series of configuration files to determine non-default behavior that you may want. The first place Git looks for these values is in an `/etc/gitconfig` file, which contains values for every user on the system and all of their repositories. If you pass the option `--system` to `git config`, it reads and writes from this file specifically.
 
-The next place Git looks is the `~/.gitconfig` file, which is specific to each user. You can make Git read and write to this file by passing the `--global` option. 
+The next place Git looks is the `~/.gitconfig` file, which is specific to each user. You can make Git read and write to this file by passing the `--global` option.
 
 Finally, Git looks for configuration values in the config file in the Git directory (`.git/config`) of whatever repository you’re currently using. These values are specific to that single repository. Each level overwrites values in the previous level, so values in `.git/config` trump those in `/etc/gitconfig`, for instance. You can also set these values by manually editing the file and inserting the correct syntax, but it’s generally easier to run the `git config` command.
 
@@ -75,7 +75,7 @@ The core.pager setting determines what pager is used when Git pages output such
 
 	$ git config --global core.pager ''
 
-If you run that, Git will page the entire output of all commands, no matter how long they are.
+If you run that, Git will page the entire output of all commands, no matter how long it is.
 
 #### user.signingkey ####
 
@@ -93,7 +93,7 @@ You can put patterns in your project’s `.gitignore` file to have Git not see t
 
 #### help.autocorrect ####
 
-This option is available only in Git 1.6.1 and later. If you mistype a command in Git 1.6, it shows you something like this:
+This option is available only in Git 1.6.1 and later. If you mistype a command in Git, it shows you something like this:
 
 	$ git com
 	git: 'com' is not a git-command. See 'git --help'.
@@ -113,13 +113,13 @@ Git automatically colors most of its output if you ask it to. You can get very s
 
 	$ git config --global color.ui true
 
-When that value is set, Git colors its output if the output goes to a terminal. Other possible settings are false, which never colors the output, and always, which sets colors all the time, even if you’re redirecting Git commands to a file or piping them to another command. This setting was added in Git version 1.5.5; if you have an older version, you’ll have to specify all the color settings individually.
+When that value is set, Git colors its output if the output goes to a terminal. Other possible settings are false, which never colors the output, and always, which sets colors all the time, even if you’re redirecting Git commands to a file or piping them to another command.
 
 You’ll rarely want `color.ui = always`. In most scenarios, if you want color codes in your redirected output, you can instead pass a `--color` flag to the Git command to force it to use color codes. The `color.ui = true` setting is almost always what you’ll want to use.
 
 #### `color.*` ####
 
-If you want to be more specific about which commands are colored and how, or you have an older version, Git provides verb-specific coloring settings. Each of these can be set to `true`, `false`, or `always`:
+If you want to be more specific about which commands are colored and how, Git provides verb-specific coloring settings. Each of these can be set to `true`, `false`, or `always`:
 
 	color.branch
 	color.diff
@@ -128,9 +128,9 @@ If you want to be more specific about which commands are colored and how, or you
 
 In addition, each of these has subsettings you can use to set specific colors for parts of the output, if you want to override each color. For example, to set the meta information in your diff output to blue foreground, black background, and bold text, you can run
 
-	$ git config --global color.diff.meta “blue black bold”
+	$ git config --global color.diff.meta "blue black bold"
 
-You can set the color to any of the following values: normal, black, red, green, yellow, blue, magenta, cyan, or white. If you want an attribute like bold in the previous example, you can choose from bold, dim, ul, blink, and reverse.
+You can set the color to any of the following values: `normal`, `black`, `red`, `green`, `yellow`, `blue`, `magenta`, `cyan`, or `white`, or, if your terminal supports more than 16 colors, an arbitrary numeric color value (between 0 and 255 on a 256-color terminal). If you want an attribute like bold in the previous example, you can choose from `bold`, `dim`, `ul`, `blink`, and `reverse`.
 
 See the `git config` manpage for all the subsettings you can configure, if you want to do that.
 
@@ -156,13 +156,13 @@ The diff wrapper checks to make sure seven arguments are provided and passes two
 
 Because you only want the `old-file` and `new-file` arguments, you use the wrapper script to pass the ones you need.
 
-	$ cat /usr/local/bin/extDiff 
+	$ cat /usr/local/bin/extDiff
 	#!/bin/sh
 	[ $# -eq 7 ] && /usr/local/bin/extMerge "$2" "$5"
 
 You also need to make sure these tools are executable:
 
-	$ sudo chmod +x /usr/local/bin/extMerge 
+	$ sudo chmod +x /usr/local/bin/extMerge
 	$ sudo chmod +x /usr/local/bin/extDiff
 
 Now you can set up your config file to use your custom merge resolution and diff tools. This takes a number of custom settings: `merge.tool` to tell Git what strategy to use, `mergetool.*.cmd` to specify how to run the command, `mergetool.trustExitCode` to tell Git if the exit code of that program indicates a successful merge resolution or not, and `diff.external` to tell Git what command to run for diffs. So, you can either run four config commands
@@ -184,12 +184,12 @@ or you can edit your `~/.gitconfig` file to add these lines:
 	  external = extDiff
 
 After all this is set, if you run diff commands such as this:
-	
+
 	$ git diff 32d1776b1^ 32d1776b1
 
 Instead of getting the diff output on the command line, Git fires up P4Merge, which looks something like Figure 7-1.
 
-Insert 18333fig0701.png 
+Insert 18333fig0701.png
 Figure 7-1. P4Merge.
 
 If you try to merge two branches and subsequently have merge conflicts, you can run the command `git mergetool`; it starts P4Merge to let you resolve the conflicts through that GUI tool.
@@ -197,7 +197,7 @@ If you try to merge two branches and subsequently have merge conflicts, you can
 The nice thing about this wrapper setup is that you can change your diff and merge tools easily. For example, to change your `extDiff` and `extMerge` tools to run the KDiff3 tool instead, all you have to do is edit your `extMerge` file:
 
 	$ cat /usr/local/bin/extMerge
-	#!/bin/sh	
+	#!/bin/sh
 	/Applications/kdiff3.app/Contents/MacOS/kdiff3 $*
 
 Now, Git will use the KDiff3 tool for diff viewing and merge conflict resolution.
@@ -214,7 +214,7 @@ Formatting and whitespace issues are some of the more frustrating and subtle pro
 
 #### core.autocrlf ####
 
-If you’re programming on Windows or using another system but working with people who are programming on Windows, you’ll probably run into line-ending issues at some point. This is because Windows uses both a carriage-return character and a linefeed character for newlines in its files, whereas Mac and Linux systems use only the linefeed character. This is a subtle but incredibly annoying fact of cross-platform work. 
+If you’re programming on Windows or using another system but working with people who are programming on Windows, you’ll probably run into line-ending issues at some point. This is because Windows uses both a carriage-return character and a linefeed character for newlines in its files, whereas Mac and Linux systems use only the linefeed character. This is a subtle but incredibly annoying fact of cross-platform work.
 
 Git can handle this by auto-converting CRLF line endings into LF when you commit, and vice versa when it checks out code onto your filesystem. You can turn on this functionality with the `core.autocrlf` setting. If you’re on a Windows machine, set it to `true` — this converts LF endings into CRLF when you check out code:
 
@@ -251,7 +251,7 @@ Or you can have Git try to automatically fix the issue before applying the patch
 
 	$ git apply --whitespace=fix <patch>
 
-These options apply to the git rebase option as well. If you’ve committed whitespace issues but haven’t yet pushed upstream, you can run a `rebase` with the `--whitespace=fix` option to have Git automatically fix whitespace issues as it’s rewriting the patches.
+These options apply to the `git rebase` command as well. If you’ve committed whitespace issues but haven’t yet pushed upstream, you can run a `rebase` with the `--whitespace=fix` option to have Git automatically fix whitespace issues as it’s rewriting the patches.
 
 ### Server Configuration ###
 
@@ -301,19 +301,23 @@ To tell Git to treat all `pbxproj` files as binary data, add the following line
 
 	*.pbxproj -crlf -diff
 
-Now, Git won’t try to convert or fix CRLF issues; nor will it try to compute or print a diff for changes in this file when you run git show or git diff on your project. In the 1.6 series of Git, you can also use a macro that is provided that means `-crlf -diff`:
+Now, Git won’t try to convert or fix CRLF issues; nor will it try to compute or print a diff for changes in this file when you run `git show` or `git diff` on your project. You can also use a built-in macro `binary` that means `-crlf -diff`:
 
 	*.pbxproj binary
 
 #### Diffing Binary Files ####
 
-In the 1.6 series of Git, you can use the Git attributes functionality to effectively diff binary files. You do this by telling Git how to convert your binary data to a text format that can be compared via the normal diff.
+In Git, you can use the attributes functionality to effectively diff binary files. You do this by telling Git how to convert your binary data to a text format that can be compared via the normal diff. But the question is how do you convert *binary* data to a text? The best solution is to find some tool that does conversion for your binary format to a text representation. Unfortunately, very few binary formats can be represented as human readable text (imagine trying to convert audio data to a text). If this is the case and you failed to get a text presentation of your file's contents, it's often relatively easy to get a human readable description of that content, or metadata. Metadata won't give you a full representation of your file's content, but in any case it's better than nothing.
+
+We'll make use of the both described approaches to get usable diffs for some widely used binary formats.
+
+Side note: There are different kinds of binary formats with a text content, which are hard to find usable converter for. In such a case you could try to extract a text from your file with the `strings` program. Some of these files may use an UTF-16 encoding or other "codepages" and `strings` won’t find anything useful in there. Your mileage may vary. However, `strings` is available on most Mac and Linux systems, so it may be a good first try to do this with many binary formats.
 
 ##### MS Word files #####
 
-Because this is a pretty cool and not widely known feature, I’ll go over a few examples. First, you’ll use this technique to solve one of the most annoying problems known to humanity: version-controlling Word documents. Everyone knows that Word is the most horrific editor around; but, oddly, everyone uses it. If you want to version-control Word documents, you can stick them in a Git repository and commit every once in a while; but what good does that do? If you run `git diff` normally, you only see something like this:
+First, you’ll use the described technique to solve one of the most annoying problems known to humanity: version-controlling Word documents. Everyone knows that Word is the most horrific editor around; but, oddly, everyone uses it. If you want to version-control Word documents, you can stick them in a Git repository and commit every once in a while; but what good does that do? If you run `git diff` normally, you only see something like this:
 
-	$ git diff 
+	$ git diff
 	diff --git a/chapter1.doc b/chapter1.doc
 	index 88839c4..4afcb7c 100644
 	Binary files a/chapter1.doc and b/chapter1.doc differ
@@ -322,18 +326,16 @@ You can’t directly compare two versions unless you check them out and scan the
 
 	*.doc diff=word
 
-This tells Git that any file that matches this pattern (.doc) should use the "word" filter when you try to view a diff that contains changes. What is the "word" filter? You have to set it up. Here you’ll configure Git to use the `strings` program to convert Word documents into readable text files, which it will then diff properly:
+This tells Git that any file that matches this pattern (.doc) should use the "word" filter when you try to view a diff that contains changes. What is the "word" filter? You have to set it up. Here you’ll configure Git to use the `catdoc` program, which was written specifically for extracting text from a binary MS Word documents (you can get it from `http://www.wagner.pp.ru/~vitus/software/catdoc/`), to convert Word documents into readable text files, which it will then diff properly:
 
-	$ git config diff.word.textconv strings
+	$ git config diff.word.textconv catdoc
 
 This command adds a section to your `.git/config` that looks like this:
 
 	[diff "word"]
-		textconv = strings
-
-Side note: There are different kinds of `.doc` files. Some use an UTF-16 encoding or other "codepages" and `strings` won't find anything useful in there. Your mileage may vary.
+		textconv = catdoc
 
-Now Git knows that if it tries to do a diff between two snapshots, and any of the files end in `.doc`, it should run those files through the "word" filter, which is defined as the `strings` program. This effectively makes nice text-based versions of your Word files before attempting to diff them.
+Now Git knows that if it tries to do a diff between two snapshots, and any of the files end in `.doc`, it should run those files through the "word" filter, which is defined as the `catdoc` program. This effectively makes nice text-based versions of your Word files before attempting to diff them.
 
 Here’s an example. I put Chapter 1 of this book into Git, added some text to a paragraph, and saved the document. Then, I ran `git diff` to see what changed:
 
@@ -342,15 +344,14 @@ Here’s an example. I put Chapter 1 of this book into Git, added some text to a
 	index c1c8a0a..b93c9e4 100644
 	--- a/chapter1.doc
 	+++ b/chapter1.doc
-	@@ -8,7 +8,8 @@ re going to cover Version Control Systems (VCS) and Git basics
-	 re going to cover how to get it and set it up for the first time if you don
-	 t already have it on your system.
-	 In Chapter Two we will go over basic Git usage - how to use Git for the 80% 
-	-s going on, modify stuff and contribute changes. If the book spontaneously 
-	+s going on, modify stuff and contribute changes. If the book spontaneously 
-	+Let's see if this works.
+	@@ -128,7 +128,7 @@ and data size)
+	 Since its birth in 2005, Git has evolved and matured to be easy to use
+	 and yet retain these initial qualities. It’s incredibly fast, it’s
+	 very efficient with large projects, and it has an incredible branching
+	-system for non-linear development.
+	+system for non-linear development (See Chapter 3).
 
-Git successfully and succinctly tells me that I added the string "Let’s see if this works", which is correct. It’s not perfect — it adds a bunch of random stuff at the end — but it certainly works. If you can find or write a Word-to-plain-text converter that works well enough, that solution will likely be incredibly effective. However, `strings` is available on most Mac and Linux systems, so it may be a good first try to do this with many binary formats.
+Git successfully and succinctly tells me that I added the string "(See Chapter 3)", which is correct. Works perfectly!
 
 ##### OpenDocument Text files #####
 
@@ -366,18 +367,18 @@ Now set up the `odt` diff filter in `.git/config`:
 		binary = true
 		textconv = /usr/local/bin/odt-to-txt
 
-OpenDocument files are actually zip'ped directories containing multiple files (the content in an XML format, stylesheets, images, etc.). We'll need to write a script to extract the content and return it as plain text. Create a file `/usr/local/bin/odt-to-txt` (you are free to put it into a different directory) with the following content:
+OpenDocument files are actually zip’ped directories containing multiple files (the content in an XML format, stylesheets, images, etc.). We’ll need to write a script to extract the content and return it as plain text. Create a file `/usr/local/bin/odt-to-txt` (you are free to put it into a different directory) with the following content:
 
 	#! /usr/bin/env perl
 	# Simplistic OpenDocument Text (.odt) to plain text converter.
 	# Author: Philipp Kempgen
-	
+
 	if (! defined($ARGV[0])) {
 		print STDERR "No filename given!\n";
 		print STDERR "Usage: $0 filename\n";
 		exit 1;
 	}
-	
+
 	my $content = '';
 	open my $fh, '-|', 'unzip', '-qq', '-p', $ARGV[0], 'content.xml' or die $!;
 	{
@@ -405,7 +406,7 @@ Now `git diff` will be able to tell you what changed in `.odt` files.
 
 ##### Image files #####
 
-Another interesting problem you can solve this way involves diffing image files. One way to do this is to run JPEG files through a filter that extracts their EXIF information — metadata that is recorded with most image formats. If you download and install the `exiftool` program, you can use it to convert your images into text about the metadata, so at least the diff will show you a textual representation of any changes that happened:
+Another interesting problem you can solve this way involves diffing image files. One way to do this is to run PNG files through a filter that extracts their EXIF information — metadata that is recorded with most image formats. If you download and install the `exiftool` program, you can use it to convert your images into text about the metadata, so at least the diff will show you a textual representation of any changes that happened:
 
 	$ echo '*.png diff=exif' >> .gitattributes
 	$ git config diff.exif.textconv exiftool
@@ -419,7 +420,7 @@ If you replace an image in your project and run `git diff`, you see something li
 	@@ -1,12 +1,12 @@
 	 ExifTool Version Number         : 7.74
 	-File Size                       : 70 kB
-	-File Modification Date/Time     : 2009:04:21 07:02:45-07:00
+	-File Modification Date/Time     : 2009:04:17 10:12:35-07:00
 	+File Size                       : 94 kB
 	+File Modification Date/Time     : 2009:04:21 07:02:43-07:00
 	 File Type                       : PNG
@@ -444,26 +445,26 @@ First, you can inject the SHA-1 checksum of a blob into an `$Id$` field in the f
 
 The next time you check out this file, Git injects the SHA of the blob:
 
-	$ rm text.txt
-	$ git checkout -- text.txt
-	$ cat test.txt 
+	$ rm test.txt
+	$ git checkout -- test.txt
+	$ cat test.txt
 	$Id: 42812b7653c7b88933f8a9d6cad0ca16714b9bb3 $
 
 However, that result is of limited use. If you’ve used keyword substitution in CVS or Subversion, you can include a datestamp — the SHA isn’t all that helpful, because it’s fairly random and you can’t tell if one SHA is older or newer than another.
 
 It turns out that you can write your own filters for doing substitutions in files on commit/checkout. These are the "clean" and "smudge" filters. In the `.gitattributes` file, you can set a filter for particular paths and then set up scripts that will process files just before they’re checked out ("smudge", see Figure 7-2) and just before they’re committed ("clean", see Figure 7-3). These filters can be set to do all sorts of fun things.
 
-Insert 18333fig0702.png 
+Insert 18333fig0702.png
 Figure 7-2. The “smudge” filter is run on checkout.
 
-Insert 18333fig0703.png 
+Insert 18333fig0703.png
 Figure 7-3. The “clean” filter is run when files are staged.
 
 The original commit message for this functionality gives a simple example of running all your C source code through the `indent` program before committing. You can set it up by setting the filter attribute in your `.gitattributes` file to filter `*.c` files with the "indent" filter:
 
 	*.c     filter=indent
 
-Then, tell Git what the "indent"" filter does on smudge and clean:
+Then, tell Git what the "indent" filter does on smudge and clean:
 
 	$ git config --global filter.indent.clean indent
 	$ git config --global filter.indent.smudge cat
@@ -510,7 +511,7 @@ For example, say you have some test files in a `test/` subdirectory, and it does
 
 	test/ export-ignore
 
-Now, when you run git archive to create a tarball of your project, that directory won’t be included in the archive.
+Now, when you run `git archive` to create a tarball of your project, that directory won’t be included in the archive.
 
 #### export-subst ####
 
@@ -548,7 +549,7 @@ Like many other Version Control Systems, Git has a way to fire off custom script
 
 ### Installing a Hook ###
 
-The hooks are all stored in the `hooks` subdirectory of the Git directory. In most projects, that’s `.git/hooks`. By default, Git populates this directory with a bunch of example scripts, many of which are useful by themselves; but they also document the input values of each script. All the examples are written as shell scripts, with some Perl thrown in, but any properly named executable scripts will work fine — you can write them in Ruby or Python or what have you. For post-1.6 versions of Git, these example hook files end with .sample; you’ll need to rename them. For pre-1.6 versions of Git, the example files are named properly but are not executable.
+The hooks are all stored in the `hooks` subdirectory of the Git directory. In most projects, that’s `.git/hooks`. By default, Git populates this directory with a bunch of example scripts, many of which are useful by themselves; but they also document the input values of each script. All the examples are written as shell scripts, with some Perl thrown in, but any properly named executable scripts will work fine — you can write them in Ruby or Python or what have you. These example hook files end with .sample; you’ll need to rename them.
 
 To enable a hook script, put a file in the `hooks` subdirectory of your Git directory that is named appropriately and is executable. From that point forward, it should be called. I’ll cover most of the major hook filenames here.
 
@@ -612,14 +613,12 @@ All the server-side work will go into the update file in your hooks directory. T
 
 	#!/usr/bin/env ruby
 
-	$refname = ARGV[0]
-	$oldrev  = ARGV[1]
-	$newrev  = ARGV[2]
-	$user    = ENV['USER']
-
-	puts "Enforcing Policies... \n(#{$refname}) (#{$oldrev[0,6]}) (#{$newrev[0,6]})"
+	refname = ARGV[0]
+	oldrev  = ARGV[1]
+	newrev  = ARGV[2]
+	user    = ENV['USER']
 
-Yes, I’m using global variables. Don’t judge me — it’s easier to demonstrate in this manner.
+	puts "Enforcing Policies... \n(#{refname}) (#{oldrev[0,6]}) (#{newrev[0,6]})"
 
 #### Enforcing a Specific Commit-Message Format ####
 
@@ -736,7 +735,7 @@ If you use the ACL structure returned from the `get_acl_access_data` method and
 	      access[$user].each do |access_path|
 	        if !access_path || # user has access to everything
 	          (path.index(access_path) == 0) # access to this path
-	          has_file_access = true 
+	          has_file_access = true
 	        end
 	      end
 	      if !has_file_access
@@ -744,22 +743,22 @@ If you use the ACL structure returned from the `get_acl_access_data` method and
 	        exit 1
 	      end
 	    end
-	  end  
+	  end
 	end
 
 	check_directory_perms
 
-Most of that should be easy to follow. You get a list of new commits being pushed to your server with `git rev-list`. Then, for each of those, you find which files are modified and make sure the user who’s pushing has access to all the paths being modified. One Rubyism that may not be clear is `path.index(access_path) == 0`, which is true if path begins with `access_path` — this ensures that `access_path` is not just in one of the allowed paths, but an allowed path begins with each accessed path. 
+Most of that should be easy to follow. You get a list of new commits being pushed to your server with `git rev-list`. Then, for each of those, you find which files are modified and make sure the user who’s pushing has access to all the paths being modified. One Rubyism that may not be clear is `path.index(access_path) == 0`, which is true if path begins with `access_path` — this ensures that `access_path` is not just in one of the allowed paths, but an allowed path begins with each accessed path.
 
 Now your users can’t push any commits with badly formed messages or with modified files outside of their designated paths.
 
 #### Enforcing Fast-Forward-Only Pushes ####
 
-The only thing left is to enforce fast-forward-only pushes. In Git versions 1.6 or newer, you can set the `receive.denyDeletes` and `receive.denyNonFastForwards` settings. But enforcing this with a hook will work in older versions of Git, and you can modify it to do so only for certain users or whatever else you come up with later.
+The only thing left is to enforce fast-forward-only pushes. To do so, you can simply set the `receive.denyDeletes` and `receive.denyNonFastForwards` settings. But enforcing this with a hook will also work, and you can modify it to do so only for certain users or whatever else you come up with later.
 
 The logic for checking this is to see if any commits are reachable from the older revision that aren’t reachable from the newer one. If there are none, then it was a fast-forward push; otherwise, you deny it:
 
-	# enforces fast-forward only pushes 
+	# enforces fast-forward only pushes
 	def check_fast_forward
 	  missed_refs = `git rev-list #{$newrev}..#{$oldrev}`
 	  missed_ref_count = missed_refs.split("\n").size
@@ -771,7 +770,7 @@ The logic for checking this is to see if any commits are reachable from the olde
 
 	check_fast_forward
 
-Everything is set up. If you run `chmod u+x .git/hooks/update`, which is the file into which you should have put all this code, and then try to push a non-fast-forwarded reference, you get something like this:
+Everything is set up. If you run `chmod u+x .git/hooks/update`, which is the file into which you should have put all this code, and then try to push a non-fast-forward reference, you’ll get something like this:
 
 	$ git push -f origin master
 	Counting objects: 5, done.
@@ -779,9 +778,9 @@ Everything is set up. If you run `chmod u+x .git/hooks/update`, which is the fil
 	Writing objects: 100% (3/3), 323 bytes, done.
 	Total 3 (delta 1), reused 0 (delta 0)
 	Unpacking objects: 100% (3/3), done.
-	Enforcing Policies... 
+	Enforcing Policies...
 	(refs/heads/master) (8338c5) (c5b616)
-	[POLICY] Cannot push a non-fast-forward reference
+	[POLICY] Cannot push a non fast-forward reference
 	error: hooks/update exited with error code 1
 	error: hook declined to update refs/heads/master
 	To git@gitserver:project.git
@@ -790,8 +789,8 @@ Everything is set up. If you run `chmod u+x .git/hooks/update`, which is the fil
 
 There are a couple of interesting things here. First, you see this where the hook starts running.
 
-	Enforcing Policies... 
-	(refs/heads/master) (fb8c72) (c56860)
+	Enforcing Policies...
+	(refs/heads/master) (8338c5) (c5b616)
 
 Notice that you printed that out to stdout at the very beginning of your update script. It’s important to note that anything your script prints to stdout will be transferred to the client.
 
@@ -917,7 +916,7 @@ Here is an example pre-rebase script that checks for that. It gets a list of all
 	target_shas.each do |sha|
 	  remote_refs.each do |remote_ref|
 	    shas_pushed = `git rev-list ^#{sha}^@ refs/remotes/#{remote_ref}`
-	    if shas_pushed.split(“\n”).include?(sha)
+	    if shas_pushed.split("\n").include?(sha)
 	      puts "[POLICY] Commit #{sha} has already been pushed to #{remote_ref}"
 	      exit 1
 	    end
diff --git a/no-nb/08-git-and-other-scms/01-chapter8.markdown b/no-nb/08-git-and-other-scms/01-chapter8.markdown
index 2465ffaa5..a270b14e3 100644
--- a/no-nb/08-git-and-other-scms/01-chapter8.markdown
+++ b/no-nb/08-git-and-other-scms/01-chapter8.markdown
@@ -2,7 +2,7 @@
 
 The world isn’t perfect. Usually, you can’t immediately switch every project you come in contact with to Git. Sometimes you’re stuck on a project using another VCS, and many times that system is Subversion. You’ll spend the first part of this chapter learning about `git svn`, the bidirectional Subversion gateway tool in Git.
 
-At some point, you may want to convert your existing project to Git. The second part of this chapter covers how to migrate your project into Git: first from Subversion, then from Perforce, and finally via a custom import script for a nonstandard importing case. 
+At some point, you may want to convert your existing project to Git. The second part of this chapter covers how to migrate your project into Git: first from Subversion, then from Perforce, and finally via a custom import script for a nonstandard importing case.
 
 ## Git and Subversion ##
 
@@ -20,7 +20,7 @@ Don’t rewrite your history and try to push again, and don’t push to a parall
 
 ### Setting Up ###
 
-To demonstrate this functionality, you need a typical SVN repository that you have write access to. If you want to copy these examples, you’ll have to make a writeable copy of my test repository. In order to do that easily, you can use a tool called `svnsync` that comes with more recent versions of Subversion — it should be distributed with at least 1.4. For these tests, I created a new Subversion repository on Google code that was a partial copy of the `protobuf` project, which is a tool that encodes structured data for network transmission. 
+To demonstrate this functionality, you need a typical SVN repository that you have write access to. If you want to copy these examples, you’ll have to make a writeable copy of my test repository. In order to do that easily, you can use a tool called `svnsync` that comes with more recent versions of Subversion — it should be distributed with at least 1.4. For these tests, I created a new Subversion repository on Google code that was a partial copy of the `protobuf` project, which is a tool that encodes structured data for network transmission.
 
 To follow along, you first need to create a new local Subversion repository:
 
@@ -29,14 +29,14 @@ To follow along, you first need to create a new local Subversion repository:
 
 Then, enable all users to change revprops — the easy way is to add a pre-revprop-change script that always exits 0:
 
-	$ cat /tmp/test-svn/hooks/pre-revprop-change 
+	$ cat /tmp/test-svn/hooks/pre-revprop-change
 	#!/bin/sh
 	exit 0;
 	$ chmod +x /tmp/test-svn/hooks/pre-revprop-change
 
 You can now sync this project to your local machine by calling `svnsync init` with the to and from repositories.
 
-	$ svnsync init file:///tmp/test-svn http://progit-example.googlecode.com/svn/ 
+	$ svnsync init file:///tmp/test-svn http://progit-example.googlecode.com/svn/
 
 This sets up the properties to run the sync. You can then clone the code by running
 
@@ -106,7 +106,7 @@ A normal Git repository looks more like this:
 	0a30dd3b0c795b80212ae723640d4e5d48cabdff refs/remotes/origin/master
 	25812380387fdd55f916652be4881c6f11600d6f refs/remotes/origin/testing
 
-You have two remote servers: one named `gitserver` with a `master` branch; and another named `origin` with two branches, `master` and `testing`. 
+You have two remote servers: one named `gitserver` with a `master` branch; and another named `origin` with two branches, `master` and `testing`.
 
 Notice how in the example of remote references imported from `git svn`, tags are added as remote branches, not as real Git tags. Your Subversion import looks like it has a remote named tags with branches under it.
 
@@ -202,7 +202,7 @@ Running `git svn rebase` every once in a while makes sure your code is always up
 
 ### Git Branching Issues ###
 
-When you’ve become comfortable with a Git workflow, you’ll likely create topic branches, do work on them, and then merge them in. If you’re pushing to a Subversion server via git svn, you may want to rebase your work onto a single branch each time instead of merging branches together. The reason to prefer rebasing is that Subversion has a linear history and doesn’t deal with merges like Git does, so git svn follows only the first parent when converting the snapshots into Subversion commits.
+When you’ve become comfortable with a Git workflow, you’ll likely create topic branches, do work on them, and then merge them in. If you’re pushing to a Subversion server via `git svn`, you may want to rebase your work onto a single branch each time instead of merging branches together. The reason to prefer rebasing is that Subversion has a linear history and doesn’t deal with merges like Git does, so `git svn` follows only the first parent when converting the snapshots into Subversion commits.
 
 Suppose your history looks like the following: you created an `experiment` branch, did two commits, and then merged them back into `master`. When you `dcommit`, you see output like this:
 
@@ -231,7 +231,7 @@ When someone else clones that work, all they see is the merge commit with all th
 
 ### Subversion Branching ###
 
-Branching in Subversion isn’t the same as branching in Git; if you can avoid using it much, that’s probably best. However, you can create and commit to branches in Subversion using git svn.
+Branching in Subversion isn’t the same as branching in Git; if you can avoid using it much, that’s probably best. However, you can create and commit to branches in Subversion using `git svn`.
 
 #### Creating a New SVN Branch ####
 
@@ -250,7 +250,7 @@ This does the equivalent of the `svn copy trunk branches/opera` command in Subve
 
 ### Switching Active Branches ###
 
-Git figures out what branch your dcommits go to by looking for the tip of any of your Subversion branches in your history — you should have only one, and it should be the last one with a `git-svn-id` in your current branch history. 
+Git figures out what branch your dcommits go to by looking for the tip of any of your Subversion branches in your history — you should have only one, and it should be the last one with a `git-svn-id` in your current branch history.
 
 If you want to work on more than one branch simultaneously, you can set up local branches to `dcommit` to specific Subversion branches by starting them at the imported Subversion commit for that branch. If you want an `opera` branch that you can work on separately, you can run
 
@@ -281,7 +281,7 @@ If you’re used to Subversion and want to see your history in SVN output style,
 
 	------------------------------------------------------------------------
 	r85 | schacon | 2009-05-02 16:00:09 -0700 (Sat, 02 May 2009) | 2 lines
-	
+
 	updated the changelog
 
 You should know two important things about `git svn log`. First, it works offline, unlike the real `svn log` command, which asks the Subversion server for the data. Second, it only shows you commits that have been committed up to the Subversion server. Local Git commits that you haven’t dcommited don’t show up; neither do commits that people have made to the Subversion server in the meantime. It’s more like the last known state of the commits on the Subversion server.
@@ -290,19 +290,19 @@ You should know two important things about `git svn log`. First, it works offlin
 
 Much as the `git svn log` command simulates the `svn log` command offline, you can get the equivalent of `svn annotate` by running `git svn blame [FILE]`. The output looks like this:
 
-	$ git svn blame README.txt 
+	$ git svn blame README.txt
 	 2   temporal Protocol Buffers - Google's data interchange format
 	 2   temporal Copyright 2008 Google Inc.
 	 2   temporal http://code.google.com/apis/protocolbuffers/
-	 2   temporal 
+	 2   temporal
 	22   temporal C++ Installation - Unix
 	22   temporal =======================
-	 2   temporal 
+	 2   temporal
 	79    schacon Committing in git-svn.
-	78    schacon 
+	78    schacon
 	 2   temporal To build and install the C++ Protocol Buffer runtime and the Protocol
 	 2   temporal Buffer compiler (protoc) execute the following:
-	 2   temporal 
+	 2   temporal
 
 Again, it doesn’t show commits that you did locally in Git or that have been pushed to Subversion in the meantime.
 
@@ -369,7 +369,7 @@ That gives you the log output in XML format — you can look for the authors, cr
 
 You can provide this file to `git svn` to help it map the author data more accurately. You can also tell `git svn` not to include the metadata that Subversion normally imports, by passing `--no-metadata` to the `clone` or `init` command. This makes your `import` command look like this:
 
-	$ git-svn clone http://my-project.googlecode.com/svn/ \
+	$ git svn clone http://my-project.googlecode.com/svn/ \
 	      --authors-file=users.txt --no-metadata -s my_project
 
 Now you should have a nicer Subversion import in your `my_project` directory. Instead of commits that look like this
@@ -396,15 +396,13 @@ You need to do a bit of `post-import` cleanup. For one thing, you should clean u
 
 To move the tags to be proper Git tags, run
 
-	$ cp -Rf .git/refs/remotes/tags/* .git/refs/tags/
-	$ rm -Rf .git/refs/remotes/tags
+	$ git for-each-ref refs/remotes/tags | cut -d / -f 4- | grep -v @ | while read tagname; do git tag "$tagname" "tags/$tagname"; git branch -r -d "tags/$tagname"; done
 
 This takes the references that were remote branches that started with `tag/` and makes them real (lightweight) tags.
 
 Next, move the rest of the references under `refs/remotes` to be local branches:
 
-	$ cp -Rf .git/refs/remotes/* .git/refs/heads/
-	$ rm -Rf .git/refs/remotes
+	$ git for-each-ref refs/remotes | cut -d / -f 3- | grep -v @ | while read branchname; do git branch "$branchname" "refs/remotes/$branchname"; git branch -r -d "$branchname"; done
 
 Now all the old branches are real Git branches and all the old tags are real Git tags. The last thing to do is add your new Git server as a remote and push to it. Here is an example of adding your server as a remote:
 
@@ -413,12 +411,13 @@ Now all the old branches are real Git branches and all the old tags are real Git
 Because you want all your branches and tags to go up, you can now run this:
 
 	$ git push origin --all
+	$ git push origin --tags
 
 All your branches and tags should be on your new Git server in a nice, clean import.
 
 ### Perforce ###
 
-The next system you’ll look at importing from is Perforce. A Perforce importer is also distributed with Git, but only in the `contrib` section of the source code — it isn’t available by default like `git svn`. To run it, you must get the Git source code, which you can download from git.kernel.org:
+The next system you’ll look at importing from is Perforce. A Perforce importer is also distributed with Git. If you have a version of Git earlier than 1.7.11, then the importer is only available in the `contrib` section of the source code. In that case you must get the Git source code, which you can download from git.kernel.org:
 
 	$ git clone git://git.kernel.org/pub/scm/git/git.git
 	$ cd git/contrib/fast-import
@@ -500,7 +499,7 @@ To quickly demonstrate, you’ll write a simple importer. Suppose you work in cu
 
 In order to import a Git directory, you need to review how Git stores its data. As you may remember, Git is fundamentally a linked list of commit objects that point to a snapshot of content. All you have to do is tell `fast-import` what the content snapshots are, what commit data points to them, and the order they go in. Your strategy will be to go through the snapshots one at a time and create commits with the contents of each directory, linking each commit back to the previous one.
 
-As you did in the "An Example Git Enforced Policy" section of Chapter 7, we’ll write this in Ruby, because it’s what I generally work with and it tends to be easy to read. You can write this example pretty easily in anything you’re familiar with — it just needs to print the appropriate information to stdout. And, if you are running on Windows, this means you'll need to take special care to not introduce carriage returns at the end your lines — git fast-import is very particular about just wanting line feeds (LF) not the carriage return line feeds (CRLF) that Windows uses.
+As you did in the "An Example Git Enforced Policy" section of Chapter 7, we’ll write this in Ruby, because it’s what I generally work with and it tends to be easy to read. You can write this example pretty easily in anything you’re familiar with — it just needs to print the appropriate information to stdout. And, if you are running on Windows, this means you’ll need to take special care to not introduce carriage returns at the end your lines — `git fast-import` is very particular about just wanting line feeds (LF) not the carriage return line feeds (CRLF) that Windows uses.
 
 To begin, you’ll change into the target directory and identify every subdirectory, each of which is a snapshot that you want to import as a commit. You’ll change into each subdirectory and print the commands necessary to export it. Your basic main loop looks like this:
 
@@ -512,7 +511,7 @@ To begin, you’ll change into the target directory and identify every subdirect
 	    next if File.file?(dir)
 
 	    # move into the target directory
-	    Dir.chdir(dir) do 
+	    Dir.chdir(dir) do
 	      last_mark = print_export(dir, last_mark)
 	    end
 	  end
@@ -561,7 +560,7 @@ Now you’re ready to begin printing out the commit data for your importer. The
 	export_data('imported from ' + dir)
 	puts 'from :' + last_mark if last_mark
 
-You hardcode the time zone (-0700) because doing so is easy. If you’re importing from another system, you must specify the time zone as an offset. 
+You hardcode the time zone (-0700) because doing so is easy. If you’re importing from another system, you must specify the time zone as an offset.
 The commit message must be expressed in a special format:
 
 	data (size)\n(contents)
@@ -596,19 +595,19 @@ Here, 644 is the mode (if you have executable files, you need to detect and spec
 	  export_data(content)
 	end
 
-You reuse the `export_data` method you defined earlier, because it’s the same as the way you specified your commit message data. 
+You reuse the `export_data` method you defined earlier, because it’s the same as the way you specified your commit message data.
 
 The last thing you need to do is to return the current mark so it can be passed to the next iteration:
 
 	return mark
 
-NOTE: If you are running on Windows you'll need to make sure that you add one extra step. As mentioned before, Windows uses CRLF for new line characters while git fast-import expects only LF. To get around this problem and make git fast-import happy, you need to tell ruby to use LF instead of CRLF:
+NOTE: If you are running on Windows you’ll need to make sure that you add one extra step. As mentioned before, Windows uses CRLF for new line characters while `git fast-import` expects only LF. To get around this problem and make `git fast-import` happy, you need to tell ruby to use LF instead of CRLF:
 
 	$stdout.binmode
 
 That’s it. If you run this script, you’ll get content that looks something like this:
 
-	$ ruby import.rb /opt/import_from 
+	$ ruby import.rb /opt/import_from
 	commit refs/heads/master
 	mark :1
 	committer Scott Chacon <schacon@geemail.com> 1230883200 -0700
@@ -631,7 +630,7 @@ That’s it. If you run this script, you’ll get content that looks something l
 	new version one
 	(...)
 
-To run the importer, pipe this output through `git fast-import` while in the Git directory you want to import into. You can create a new directory and then run `git init` in it for a starting point, and then run your script:
+To run the importer, pipe this output through `git fast-import` while in the Git repository you want to import into. You can create a new directory and then run `git init` in it for a starting point, and then run your script:
 
 	$ git init
 	Initialized empty Git repository in /opt/import_to/.git/
diff --git a/no-nb/09-git-internals/01-chapter9.markdown b/no-nb/09-git-internals/01-chapter9.markdown
index a04fee487..354a44f16 100644
--- a/no-nb/09-git-internals/01-chapter9.markdown
+++ b/no-nb/09-git-internals/01-chapter9.markdown
@@ -16,7 +16,7 @@ The book’s first eight chapters deal almost exclusively with porcelain command
 
 When you run `git init` in a new or existing directory, Git creates the `.git` directory, which is where almost everything that Git stores and manipulates is located. If you want to back up or clone your repository, copying this single directory elsewhere gives you nearly everything you need. This entire chapter basically deals with the stuff in this directory. Here’s what it looks like:
 
-	$ ls 
+	$ ls
 	HEAD
 	branches/
 	config
@@ -27,7 +27,7 @@ When you run `git init` in a new or existing directory, Git creates the `.git` d
 	objects/
 	refs/
 
-You may see some other files in there, but this is a fresh `git init` repository — it’s what you see by default. The `branches` directory isn’t used by newer Git versions, and the `description` file is only used by the GitWeb program, so don’t worry about those. The `config` file contains your project-specific configuration options, and the `info` directory keeps a global exclude file for ignored patterns that you don’t want to track in a .gitignore file. The `hooks` directory contains your client- or server-side hook scripts, which are discussed in detail in Chapter 7.
+You may see some other files in there, but this is a fresh `git init` repository — it’s what you see by default. The `branches` directory isn’t used by newer Git versions, and the `description` file is only used by the GitWeb program, so don’t worry about those. The `config` file contains your project-specific configuration options, and the `info` directory keeps a global exclude file for ignored patterns that you don’t want to track in a `.gitignore` file. The `hooks` directory contains your client- or server-side hook scripts, which are discussed in detail in Chapter 7.
 
 This leaves four important entries: the `HEAD` and `index` files and the `objects` and `refs` directories. These are the core parts of Git. The `objects` directory stores all the content for your database, the `refs` directory stores pointers into commit objects in that data (branches), the `HEAD` file points to the branch you currently have checked out, and the `index` file is where Git stores your staging area information. You’ll now look at each of these sections in detail to see how Git operates.
 
@@ -54,7 +54,7 @@ Git has initialized the `objects` directory and created `pack` and `info` subdir
 
 The `-w` tells `hash-object` to store the object; otherwise, the command simply tells you what the key would be. `--stdin` tells the command to read the content from stdin; if you don’t specify this, `hash-object` expects the path to a file. The output from the command is a 40-character checksum hash. This is the SHA-1 hash — a checksum of the content you’re storing plus a header, which you’ll learn about in a bit. Now you can see how Git has stored your data:
 
-	$ find .git/objects -type f 
+	$ find .git/objects -type f
 	.git/objects/d6/70460b4b4aece5915caf5c68d12f560a9fe3e4
 
 You can see a file in the `objects` directory. This is how Git stores the content initially — as a single file per piece of content, named with the SHA-1 checksum of the content and its header. The subdirectory is named with the first 2 characters of the SHA, and the filename is the remaining 38 characters.
@@ -67,32 +67,32 @@ You can pull the content back out of Git with the `cat-file` command. This comma
 Now, you can add content to Git and pull it back out again. You can also do this with content in files. For example, you can do some simple version control on a file. First, create a new file and save its contents in your database:
 
 	$ echo 'version 1' > test.txt
-	$ git hash-object -w test.txt 
+	$ git hash-object -w test.txt
 	83baae61804e65cc73a7201a7252750c76066a30
 
 Then, write some new content to the file, and save it again:
 
 	$ echo 'version 2' > test.txt
-	$ git hash-object -w test.txt 
+	$ git hash-object -w test.txt
 	1f7a7a472abf3dd9643fd615f6da379c4acb3e3a
 
 Your database contains the two new versions of the file as well as the first content you stored there:
 
-	$ find .git/objects -type f 
+	$ find .git/objects -type f
 	.git/objects/1f/7a7a472abf3dd9643fd615f6da379c4acb3e3a
 	.git/objects/83/baae61804e65cc73a7201a7252750c76066a30
 	.git/objects/d6/70460b4b4aece5915caf5c68d12f560a9fe3e4
 
 Now you can revert the file back to the first version
 
-	$ git cat-file -p 83baae61804e65cc73a7201a7252750c76066a30 > test.txt 
-	$ cat test.txt 
+	$ git cat-file -p 83baae61804e65cc73a7201a7252750c76066a30 > test.txt
+	$ cat test.txt
 	version 1
 
 or the second version:
 
-	$ git cat-file -p 1f7a7a472abf3dd9643fd615f6da379c4acb3e3a > test.txt 
-	$ cat test.txt 
+	$ git cat-file -p 1f7a7a472abf3dd9643fd615f6da379c4acb3e3a > test.txt
+	$ cat test.txt
 	version 2
 
 But remembering the SHA-1 key for each version of your file isn’t practical; plus, you aren’t storing the filename in your system — just the content. This object type is called a blob. You can have Git tell you the object type of any object in Git, given its SHA-1 key, with `cat-file -t`:
@@ -116,10 +116,10 @@ The `master^{tree}` syntax specifies the tree object that is pointed to by the l
 
 Conceptually, the data that Git is storing is something like Figure 9-1.
 
-Insert 18333fig0901.png 
+Insert 18333fig0901.png
 Figure 9-1. Simple version of the Git data model.
 
-You can create your own tree. Git normally creates a tree by taking the state of your staging area or index and writing a tree object from it. So, to create a tree object, you first have to set up an index by staging some files. To create an index with a single entry — the first version of your text.txt file — you can use the plumbing command `update-index`. You use this command to artificially add the earlier version of the test.txt file to a new staging area. You must pass it the `--add` option because the file doesn’t yet exist in your staging area (you don’t even have a staging area set up yet) and `--cacheinfo` because the file you’re adding isn’t in your directory but is in your database. Then, you specify the mode, SHA-1, and filename:
+You can create your own tree. Git normally creates a tree by taking the state of your staging area or index and writing a tree object from it. So, to create a tree object, you first have to set up an index by staging some files. To create an index with a single entry — the first version of your test.txt file — you can use the plumbing command `update-index`. You use this command to artificially add the earlier version of the test.txt file to a new staging area. You must pass it the `--add` option because the file doesn’t yet exist in your staging area (you don’t even have a staging area set up yet) and `--cacheinfo` because the file you’re adding isn’t in your directory but is in your database. Then, you specify the mode, SHA-1, and filename:
 
 	$ git update-index --add --cacheinfo 100644 \
 	  83baae61804e65cc73a7201a7252750c76066a30 test.txt
@@ -141,8 +141,8 @@ You can also verify that this is a tree object:
 You’ll now create a new tree with the second version of test.txt and a new file as well:
 
 	$ echo 'new file' > new.txt
-	$ git update-index test.txt 
-	$ git update-index --add new.txt 
+	$ git update-index test.txt
+	$ git update-index --add new.txt
 
 Your staging area now has the new version of test.txt as well as the new file new.txt. Write out that tree (recording the state of the staging area or index to a tree object) and see what it looks like:
 
@@ -164,7 +164,7 @@ Notice that this tree has both file entries and also that the test.txt SHA is th
 
 If you created a working directory from the new tree you just wrote, you would get the two files in the top level of the working directory and a subdirectory named `bak` that contained the first version of the test.txt file. You can think of the data that Git contains for these structures as being like Figure 9-2.
 
-Insert 18333fig0902.png 
+Insert 18333fig0902.png
 Figure 9-2. The content structure of your current Git data.
 
 ### Commit Objects ###
@@ -241,7 +241,7 @@ Amazing. You’ve just done the low-level operations to build up a Git history w
 
 If you follow all the internal pointers, you get an object graph something like Figure 9-3.
 
-Insert 18333fig0903.png 
+Insert 18333fig0903.png
 Figure 9-3. All the objects in your Git directory.
 
 ### Object Storage ###
@@ -326,7 +326,7 @@ Your branch will contain only work from that commit down:
 
 Now, your Git database conceptually looks something like Figure 9-4.
 
-Insert 18333fig0904.png 
+Insert 18333fig0904.png
 Figure 9-4. Git directory objects with branch head references included.
 
 When you run commands like `git branch (branchname)`, Git basically runs that `update-ref` command to add the SHA-1 of the last commit of the branch you’re on into whatever new reference you want to create.
@@ -335,12 +335,12 @@ When you run commands like `git branch (branchname)`, Git basically runs that `u
 
 The question now is, when you run `git branch (branchname)`, how does Git know the SHA-1 of the last commit? The answer is the HEAD file. The HEAD file is a symbolic reference to the branch you’re currently on. By symbolic reference, I mean that unlike a normal reference, it doesn’t generally contain a SHA-1 value but rather a pointer to another reference. If you look at the file, you’ll normally see something like this:
 
-	$ cat .git/HEAD 
+	$ cat .git/HEAD
 	ref: refs/heads/master
 
 If you run `git checkout test`, Git updates the file to look like this:
 
-	$ cat .git/HEAD 
+	$ cat .git/HEAD
 	ref: refs/heads/test
 
 When you run `git commit`, it creates the commit object, specifying the parent of that commit object to be whatever SHA-1 value the reference in HEAD points to.
@@ -353,7 +353,7 @@ You can also manually edit this file, but again a safer command exists to do so:
 You can also set the value of HEAD:
 
 	$ git symbolic-ref HEAD refs/heads/test
-	$ cat .git/HEAD 
+	$ cat .git/HEAD
 	ref: refs/heads/test
 
 You can’t set a symbolic reference outside of the refs style:
@@ -375,7 +375,7 @@ That is all a lightweight tag is — a branch that never moves. An annotated tag
 
 Here’s the object SHA-1 value it created:
 
-	$ cat .git/refs/tags/v1.1 
+	$ cat .git/refs/tags/v1.1
 	9585191f37f7b0fb9444f35a9bf50de191beadc2
 
 Now, run the `cat-file` command on that SHA-1 value:
@@ -409,7 +409,7 @@ The third type of reference that you’ll see is a remote reference. If you add
 
 Then, you can see what the `master` branch on the `origin` remote was the last time you communicated with the server, by checking the `refs/remotes/origin/master` file:
 
-	$ cat .git/refs/remotes/origin/master 
+	$ cat .git/refs/remotes/origin/master
 	ca82a6dff817ec66f44342007202690a93763949
 
 Remote references differ from branches (`refs/heads` references) mainly in that they can’t be checked out. Git moves them around as bookmarks to the last known state of where those branches were on those servers.
@@ -433,8 +433,8 @@ Let’s go back to the objects database for your test Git repository. At this po
 
 Git compresses the contents of these files with zlib, and you’re not storing much, so all these files collectively take up only 925 bytes. You’ll add some larger content to the repository to demonstrate an interesting feature of Git. Add the repo.rb file from the Grit library you worked with earlier — this is about a 12K source code file:
 
-	$ curl http://github.com/mojombo/grit/raw/master/lib/grit/repo.rb > repo.rb
-	$ git add repo.rb 
+	$ curl -L https://raw.github.com/mojombo/grit/master/lib/grit/repo.rb > repo.rb
+	$ git add repo.rb
 	$ git commit -m 'added repo.rb'
 	[master 484a592] added repo.rb
 	 3 files changed, 459 insertions(+), 2 deletions(-)
@@ -449,14 +449,14 @@ If you look at the resulting tree, you can see the SHA-1 value your repo.rb file
 	100644 blob 9bc1dc421dcd51b4ac296e3e5b6e2a99cf44391e      repo.rb
 	100644 blob e3f094f522629ae358806b17daf78246c27c007b      test.txt
 
-You can then use `git cat-file` to see how big that object is:
+You can then check how big is that object on your disk:
 
-	$ git cat-file -s 9bc1dc421dcd51b4ac296e3e5b6e2a99cf44391e
-	12898
+	$ du -b .git/objects/9b/c1dc421dcd51b4ac296e3e5b6e2a99cf44391e
+	4102	.git/objects/9b/c1dc421dcd51b4ac296e3e5b6e2a99cf44391e
 
 Now, modify that file a little, and see what happens:
 
-	$ echo '# testing' >> repo.rb 
+	$ echo '# testing' >> repo.rb
 	$ git commit -am 'modified repo a bit'
 	[master ab1afef] modified repo a bit
 	 1 files changed, 1 insertions(+), 0 deletions(-)
@@ -470,10 +470,10 @@ Check the tree created by that commit, and you see something interesting:
 
 The blob is now a different blob, which means that although you added only a single line to the end of a 400-line file, Git stored that new content as a completely new object:
 
-	$ git cat-file -s 05408d195263d853f09dca71d55116663690c27c
-	12908
+	$ du -b .git/objects/05/408d195263d853f09dca71d55116663690c27c
+	4109	.git/objects/05/408d195263d853f09dca71d55116663690c27c
 
-You have two nearly identical 12K objects on your disk. Wouldn’t it be nice if Git could store one of them in full but then the second object only as the delta between it and the first?
+You have two nearly identical 4K objects on your disk. Wouldn’t it be nice if Git could store one of them in full but then the second object only as the delta between it and the first?
 
 It turns out that it can. The initial format in which Git saves objects on disk is called a loose object format. However, occasionally Git packs up several of these objects into a single binary file called a packfile in order to save space and be more efficient. Git does this if you have too many loose objects around, if you run the `git gc` command manually, or if you push to a remote server. To see what happens, you can manually ask Git to pack up the objects by calling the `git gc` command:
 
@@ -495,7 +495,7 @@ If you look in your objects directory, you’ll find that most of your objects a
 
 The objects that remain are the blobs that aren’t pointed to by any commit — in this case, the "what is up, doc?" example and the "test content" example blobs you created earlier. Because you never added them to any commits, they’re considered dangling and aren’t packed up in your new packfile.
 
-The other files are your new packfile and an index. The packfile is a single file containing the contents of all the objects that were removed from your filesystem. The index is a file that contains offsets into that packfile so you can quickly seek to a specific object. What is cool is that although the objects on disk before you ran the `gc` were collectively about 12K in size, the new packfile is only 6K. You’ve halved your disk usage by packing your objects.
+The other files are your new packfile and an index. The packfile is a single file containing the contents of all the objects that were removed from your filesystem. The index is a file that contains offsets into that packfile so you can quickly seek to a specific object. What is cool is that although the objects on disk before you ran the `gc` were collectively about 8K in size, the new packfile is only 4K. You’ve halved your disk usage by packing your objects.
 
 How does Git do this? When Git packs objects, it looks for files that are named and sized similarly, and stores just the deltas from one version of the file to the next. You can look into the packfile and see what Git did to save space. The `git verify-pack` plumbing command allows you to see what was packed up:
 
@@ -510,9 +510,9 @@ How does Git do this? When Git packs objects, it looks for files that are named
 	484a59275031909e19aadb7c92262719cfcdf19a commit 226 153 169
 	83baae61804e65cc73a7201a7252750c76066a30 blob   10 19 5362
 	9585191f37f7b0fb9444f35a9bf50de191beadc2 tag    136 127 5476
-	9bc1dc421dcd51b4ac296e3e5b6e2a99cf44391e blob   7 18 5193 1
-	05408d195263d853f09dca71d55116663690c27c \
-	  ab1afef80fac8e34258ff41fc1b867c702daa24b commit 232 157 12
+	9bc1dc421dcd51b4ac296e3e5b6e2a99cf44391e blob   7 18 5193 1 \
+	  05408d195263d853f09dca71d55116663690c27c
+	ab1afef80fac8e34258ff41fc1b867c702daa24b commit 232 157 12
 	cac0cab538b970a37ea1e769cbbde608743bc96d commit 226 154 473
 	d8329fc1cc938780ffdd9f94e0d364e0ea74f579 tree   36 46 5316
 	e3f094f522629ae358806b17daf78246c27c007b blob   1486 734 4352
@@ -522,7 +522,7 @@ How does Git do this? When Git packs objects, it looks for files that are named
 	chain length = 1: 1 object
 	pack-7a16e4488ae40c7d2bc56ea2bd43e25212a66c45.pack: ok
 
-Here, the `9bc1d` blob, which if you remember was the first version of your repo.rb file, is referencing the `05408` blob, which was the second version of the file. The third column in the output is the size of the object in the pack, so you can see that `05408` takes up 12K of the file but that `9bc1d` only takes up 7 bytes. What is also interesting is that the second version of the file is the one that is stored intact, whereas the original version is stored as a delta — this is because you’re most likely to need faster access to the most recent version of the file.
+Here, the `9bc1d` blob, which if you remember was the first version of your repo.rb file, is referencing the `05408` blob, which was the second version of the file. The third column in the output is the size of the object’s content, so you can see that the content of `05408` takes up 12K, but that of `9bc1d` only takes up 7 bytes. What is also interesting is that the second version of the file is the one that is stored intact, whereas the original version is stored as a delta — this is because you’re most likely to need faster access to the most recent version of the file.
 
 The really nice thing about this is that it can be repacked at any time. Git will occasionally repack your database automatically, always trying to save more space. You can also manually repack at any time by running `git gc` by hand.
 
@@ -610,7 +610,7 @@ You can also use the refspec to delete references from the remote server by runn
 
 	$ git push origin :topic
 
-Because the refspec is `<src>:<dst>`, by leaving off the `<src>` part, this basically says to make the topic branch on the remote nothing, which deletes it. 
+Because the refspec is `<src>:<dst>`, by leaving off the `<src>` part, this basically says to make the topic branch on the remote nothing, which deletes it.
 
 ## Transfer Protocols ##
 
@@ -632,7 +632,7 @@ Now you have a list of the remote references and SHAs. Next, you look for what t
 	=> GET HEAD
 	ref: refs/heads/master
 
-You need to check out the `master` branch when you’ve completed the process. 
+You need to check out the `master` branch when you’ve completed the process.
 At this point, you’re ready to start the walking process. Because your starting point is the `ca82a6` commit object you saw in the `info/refs` file, you start by fetching that:
 
 	=> GET objects/ca/82a6dff817ec66f44342007202690a93763949
@@ -783,8 +783,8 @@ The other thing `gc` will do is pack up your references into a single file. Supp
 
 If you run `git gc`, you’ll no longer have these files in the `refs` directory. Git will move them for the sake of efficiency into a file named `.git/packed-refs` that looks like this:
 
-	$ cat .git/packed-refs 
-	# pack-refs with: peeled 
+	$ cat .git/packed-refs
+	# pack-refs with: peeled
 	cac0cab538b970a37ea1e769cbbde608743bc96d refs/heads/experiment
 	ab1afef80fac8e34258ff41fc1b867c702daa24b refs/heads/master
 	cac0cab538b970a37ea1e769cbbde608743bc96d refs/tags/v1.0
@@ -854,7 +854,7 @@ It looks like the bottom commit is the one you lost, so you can recover it by cr
 	cac0cab538b970a37ea1e769cbbde608743bc96d second commit
 	fdf4fc3344e67ab068f836878b6c4951e3b15f3d first commit
 
-Cool — now you have a branch named `recover-branch` that is where your `master` branch used to be, making the first two commits reachable again. 
+Cool — now you have a branch named `recover-branch` that is where your `master` branch used to be, making the first two commits reachable again.
 Next, suppose your loss was for some reason not in the reflog — you can simulate that by removing `recover-branch` and deleting the reflog. Now the first two commits aren’t reachable by anything:
 
 	$ git branch -D recover-branch
@@ -889,7 +889,7 @@ To demonstrate, you’ll add a large file into your test repository, remove it i
 
 Oops — you didn’t want to add a huge tarball to your project. Better get rid of it:
 
-	$ git rm git.tbz2 
+	$ git rm git.tbz2
 	rm 'git.tbz2'
 	$ git commit -m 'oops - removed large tarball'
 	[master da3f30d] oops - removed large tarball

From 79a83b05651140ea563c36f176c24615b99b4be3 Mon Sep 17 00:00:00 2001
From: Petr Prikryl <prikryl@atlas.cz>
Date: Tue, 5 Aug 2014 12:55:17 +0200
Subject: [PATCH 544/690] [cs] translation revision of Chapter 2

---
 cs/02-git-basics/01-chapter2.markdown | 66 +++++++++++++--------------
 1 file changed, 33 insertions(+), 33 deletions(-)

diff --git a/cs/02-git-basics/01-chapter2.markdown b/cs/02-git-basics/01-chapter2.markdown
index 9ea03b7ef..f0932e788 100644
--- a/cs/02-git-basics/01-chapter2.markdown
+++ b/cs/02-git-basics/01-chapter2.markdown
@@ -726,11 +726,11 @@ V horní polovině okna vidíte historii revizí, doplněnou názorným hierarch
 
 ## Rušení změn ##
 
-Kdykoli si můžete přát zrušit nějakou provedenou změnu. Podívejme se proto, jaké základní nástroje se nám tu nabízejí. Ale buďte opatrní! Ne všechny zrušené změny se dají vrátit. Je to jedna z mála oblastí v systému Git, kdy při neuváženém postupu riskujete, že přijdete o část své práce.
+Kdykoli se může stát, že byste nějakou úpravu chtěli vrátit do původního stavu.. Podívejme se proto, jaké základní nástroje se nám tu nabízejí. Ale buďte opatrní! Ne všechny zrušené změny se dají vrátit. Je to jedna z mála oblastí v systému Git, kdy při neuváženém postupu riskujete, že přijdete o část své práce.
 
 ### Změna poslední revize ###
 
-Jedním z nejčastějších rušení úprav je situace, kdy zapíšete revizi příliš brzy a ještě jste např. zapomněli přidat některé soubory nebo byste rádi změnili zprávu k revizi. Chcete-li opravit poslední revizi, můžete spustit příkaz commit s parametrem `--amend`:
+Jedním z nejčastějších důvodů pro rušení úprav je situace, kdy zapíšete revizi příliš brzy a ještě jste například zapomněli přidat některé soubory, nebo byste rádi změnili zprávu k revizi. Chcete-li opravit poslední revizi, můžete spustit příkaz commit s parametrem `--amend`:
 
 	$ git commit --amend
 
@@ -744,11 +744,11 @@ Pokud například zapíšete revizi a potom si uvědomíte, že jste zapomněli
 	$ git add forgotten_file
 	$ git commit --amend
 
-Tyto tři příkazy vytvoří jedinou revizi – třetí příkaz nahradí výsledky prvního.
+Provedení uvedených tří příkazů zůstane jediná revize – druhý příkaz `commit` nahradí výsledky prvního.
 
-### Návrat souboru z oblasti připravených změn ###
+### Odstranění souboru z oblasti připravených změn ###
 
-Následující dvě části popisují, jak vrátit změny provedené v oblasti připravených změn a v pracovním adresáři. Je příjemné, že příkaz, jímž se zjišťuje stav těchto dvou oblastí, zároveň připomíná, jak v nich zrušit nežádoucí změny. Řekněme například, že jste změnili dva soubory a chcete je zapsat jako dvě oddělené změny, jenže omylem jste zadali příkaz `git add *` a oba soubory jste tím připravili k zapsání. Jak lze tyto dva soubory vrátit z oblasti připravených změn? Připomene vám to příkaz `git status`:
+Následující dvě části popisují, jak se poprat s oblastí připravených změn a se změnami v pracovním adresáři. Je příjemné, že příkaz, jímž se zjišťuje stav těchto dvou oblastí, zároveň připomíná, jak v nich nežádoucí změny zrušit. Řekněme například, že jste změnili dva soubory a chcete je zapsat jako dvě oddělené změny. Jenže omylem jste zadali příkaz `git add *` a oba soubory jste tím připravili k zapsání. Jak lze tyto dva soubory vrátit z oblasti připravených změn? Připomene vám to příkaz `git status`:
 
 	$ git add .
 	$ git status
@@ -803,18 +803,18 @@ Výpis vám sděluje, jak zahodit změny (discard changes), které jste provedli
 	        modified:   README.txt
 
 
-Jak vidíte, změny byly zahozeny. Všimněte si také, že se jedná o nebezpečný příkaz. Veškeré změny, které jste v souboru provedli, jsou ztraceny, soubor jste právě překopírovali jiným souborem. Nikdy tento příkaz nepoužívejte, pokud si nejste zcela jisti, že už daný soubor nebudete potřebovat. Pokud potřebujete pouze odstranit soubor z cesty, podívejte se na odkládání a větvení v následující kapitole. Tyto postupy většinou bývají vhodnější.
+Jak vidíte, změny byly zahozeny. Všimněte si také, že se jedná o nebezpečný příkaz. Veškeré změny, které jste v souboru provedli, jsou ztraceny, soubor jste právě překopírovali jiným souborem. Nikdy tento příkaz nepoužívejte, pokud si nejste zcela jisti, že už daný soubor nebudete potřebovat. Pokud potřebujete pouze odstranit soubor z cesty, podívejte se na odkládání (stashing) a větvení v následující kapitole. Tyto postupy většinou bývají vhodnější.
 
-Vše, co je zapsáno v systému Git, lze téměř vždy obnovit. Obnovit lze dokonce i revize na odstraněných větvích nebo revize, které byly přepsány revizí `--amend` (o obnovování dat viz kapitola 9). Pokud však dojde ke ztrátě dat, která dosud nebyla součástí žádné revize, bude tato ztráta patrně nevratná.
+Zapamatujte si, že vše, co je zapsáno v systému Git, lze téměř vždy obnovit. Obnovit lze dokonce i revize na odstraněných větvích nebo revize, které byly přepsány revizí `--amend` (o obnovování dat viz *kapitola 9*). Pokud však dojde ke ztrátě dat, která dosud nebyla součástí žádné revize, bude tato ztráta patrně nevratná.
 
 ## Práce se vzdálenými repozitáři ##
 
-Abyste mohli spolupracovat na projektech v systému Git, je třeba vědět, jak manipulovat se vzdálenými repozitáři (remote repositories). Vzdálené repozitáře jsou verze vašeho projektu umístěné na internetu nebo kdekoli v síti. Vzdálených repozitářů můžete mít hned několik, každý pro vás přitom bude buď pouze ke čtení (read-only) nebo ke čtení a zápisu (read write). Spolupráce s ostatními uživateli zahrnuje také manipulaci s těmito vzdálenými repozitáři. Chcete-li svou práci sdílet, je nutné ji posílat do repozitářů a také ji z nich stahovat.
-Při manipulaci se vzdálenými repozitáři je nutné vědět, jak lze přidat vzdálený repozitář, jak odstranit repozitář, který už není platný, jak spravovat různé vzdálené větve, jak je definovat jako sledované či nesledované apod. V této části se zaměříme právě na správu vzdálených repozitářů.
+Abyste mohli spolupracovat na projektech v systému Git, je třeba vědět, jak manipulovat se vzdálenými repozitáři (remote repositories). Vzdálené repozitáře jsou verze vašeho projektu umístěné na Internetu nebo kdekoli v síti. Vzdálených repozitářů můžete mít hned několik, každý pro vás přitom bude buď pouze ke čtení (read-only) nebo ke čtení a zápisu (read write). Spolupráce s ostatními uživateli zahrnuje také správu těchto vzdálených repozitářů. Při sdílení práce musíte do těchto repozitářů data odesílat (push) a zase je z nich stahovat (pull).
+Při správě vzdálených repozitářů musíte vědět, jak lze přidat vzdálený repozitář, jak odstranit vzdálený repozitář, který už není platný, jak spravovat různé vzdálené větve, jak je definovat jako sledované či nesledované a další věci. V této části se zaměříme právě na správu vzdálených repozitářů.
 
 ### Zobrazení vzdálených serverů ###
 
-Chcete-li zjistit, jaké vzdálené servery máte nakonfigurovány, můžete použít příkaz `git remote`. Systém vypíše zkrácené názvy všech identifikátorů vzdálených repozitářů, jež máte zadány. Pokud byl váš repozitář vytvořen klonováním, měli byste vidět přinejmenším server origin. Origin je výchozí název, který Git dává serveru, z nějž jste repozitář klonovali.
+Chcete-li zjistit, jaké vzdálené servery máte nakonfigurovány, můžete použít příkaz `git remote`. Systém vypíše krátké názvy, přes které se se vzdálenými repozitáři manipuluje, a které jste dříve určili. Pokud byl váš repozitář vytvořen klonováním, měli byste vidět přinejmenším server *origin*. Jde o výchozí název, který Git dává serveru, z nějž jste repozitář klonovali.
 
 	$ git clone git://github.com/schacon/ticgit.git
 	Cloning into 'ticgit'...
@@ -833,7 +833,7 @@ Můžete rovněž zadat parametr `-v`, jenž zobrazí adresu URL, kterou má Git
 	origin  git://github.com/schacon/ticgit.git (fetch)
 	origin  git://github.com/schacon/ticgit.git (push)
 
-Pokud máte více než jeden vzdálený repozitář, příkaz je vypíše všechny. Například můj repozitář Grit vypadá takto:
+Pokud používáte více než jeden vzdálený repozitář, příkaz je vypíše všechny. Například můj repozitář Grit vypadá takto:
 
 	$ cd grit
 	$ git remote -v
@@ -843,11 +843,11 @@ Pokud máte více než jeden vzdálený repozitář, příkaz je vypíše všech
 	koke      git://github.com/koke/grit.git
 	origin    git@github.com:mojombo/grit.git
 
-To znamená, že můžeme velmi snadno stáhnout příspěvky od kteréhokoli z těchto uživatelů. Nezapomeňte však, že pouze vzdálený server origin je SSH URL, a je tedy jediným repozitářem, kam lze posílat soubory (důvod objasníme v kapitole 4).
+To znamená, že mohu velmi snadno stáhnout příspěvky od kteréhokoli z těchto uživatelů. Ale všimněte si, že pouze vzdálený server origin je SSH URL, a je tedy jediným repozitářem, kam lze soubory odesílat (push; důvod objasníme v *kapitole 4*).
 
 ### Přidávání vzdálených repozitářů ###
 
-V předchozích částech už jsem se letmo dotkl přidávání vzdálených repozitářů. V této části se dostávám k tomu, jak přesně při přidávání postupovat. Chcete-li přidat nový vzdálený repozitář Git ve formě zkráceného názvu, na nějž lze snadno odkazovat, spusťte příkaz `git remote add [zkrácený název] [url]`:
+V předchozích částech už jsem se letmo dotkl přidávání vzdálených repozitářů. V této části se dostávám k tomu, jak přesně při přidávání postupovat. Chcete-li přidat nový vzdálený repozitář Git a zadat zkrácený název, přes který se můžete snadno odkazovat, spusťte příkaz `git remote add [zkrácený název] [url]`:
 
 	$ git remote
 	origin
@@ -867,7 +867,7 @@ V předchozích částech už jsem se letmo dotkl přidávání vzdálených rep
 	 * [new branch]      master     -> pb/master
 	 * [new branch]      ticgit     -> pb/ticgit
 
-Paulova hlavní větev (master branch) je lokálně dostupná jako `pb/master`. Můžete ji začlenit do některé ze svých větví nebo tu můžete provést checkout lokální větve, jestliže si ji chcete prohlédnout.
+Paulova hlavní větev (master branch) je teď lokálně dostupná jako `pb/master`. Můžete ji začlenit (merge) do některé ze svých větví, nebo ji můžete zpřístupnit jako lokální větev (check out), jestliže si ji chcete prohlédnout.
 
 ### Vyzvedávání a stahování ze vzdálených repozitářů ###
 
@@ -875,19 +875,19 @@ Jak jste právě viděli, data ze vzdálených projektů můžete získat pomoc
 
 	$ git fetch [název vzdáleného repozitáře]
 
-Příkaz zamíří do vzdáleného projektu a stáhne z něj všechna data, která ještě nevlastníte. Poté byste měli mít reference na všechny větve tohoto vzdáleného projektu. Nyní je můžete kdykoli slučovat nebo prohlížet. (Podrobněji se budeme větvím a jejich použití věnovat v kapitole 3.)
+Příkaz zamíří do vzdáleného projektu a stáhne z něj všechna data, která ještě nemáte u sebe. Poté byste měli mít k dispozici odkazy na všechny větve tohoto vzdáleného projektu. Od toho okamžiku je můžete kdykoli slučovat nebo prohlížet. (Podrobněji se budeme větvím a jejich použití věnovat v *kapitole 3*.)
 
-Pokud jste naklonovali repozitář, příkaz automaticky přiřadí tento vzdálený repozitář pod název „origin“. Příkaz `git fetch origin` tak vyzvedne veškerou novou práci, která byla na server poslána (push) od okamžiku, kdy jste odsud klonovali (popř. odsud naposledy vyzvedávali práci). Měli bychom zmínit, že příkaz `fetch` stáhne data do vašeho lokálního repozitáře, v žádném případě ale data automaticky nesloučí s vaší prací ani jinak nezmění nic z toho, na čem právě pracujete. Data ručně sloučíte se svou prací, až to uznáte za vhodné.
+Pokud jste naklonovali repozitář, příkaz automaticky přidá tento vzdálený repozitář pod názvem *origin*. Takže příkaz `git fetch origin` vyzvedne veškerou novou práci, která byla na uvedený server poslána (push) od okamžiku, kdy jste odtud klonovali (nebo kdy jste odtud naposledy vyzvedávali práci). Měli bychom zmínit, že příkaz `fetch` stáhne data do vašeho lokálního repozitáře. V žádném případě ale data automaticky nesloučí s vaší prací ani jinak nezmění nic z toho, na čem právě pracujete. Sloučení s vaší prací musíte udělat ručně, až to uznáte za vhodné.
 
-Pokud máte větev nastavenou ke sledování vzdálené větve (více informací naleznete v následující části a v kapitole 3), můžete použít příkaz `git pull`, který automaticky vyzvedne a poté začlení vzdálenou větev do vaší aktuální větve. Tento postup pro vás může být snazší a pohodlnější. Standardně přitom příkaz `git clone` automaticky nastaví vaši lokální hlavní větev, aby sledovala vzdálenou hlavní větev na serveru, z nějž jste klonovali (za předpokladu, že má vzdálený server hlavní větev). Příkaz `git pull` většinou vyzvedne data ze serveru, z nějž jste původně klonovali, a automaticky se pokusí začlenit je do kódu, na němž právě pracujete.
+Pokud máte větev nastavenou ke sledování vzdálené větve (více informací naleznete v následující části a v *kapitole 3*), můžete použít příkaz `git pull`, který automaticky vyzvedne (fetch) a poté začlení (merge) vzdálenou větev do vaší aktuální větve. Tento postup pro vás může být snazší a pohodlnější. Standardně přitom příkaz `git clone` automaticky nastaví vaši lokální hlavní větev, aby sledovala vzdálenou hlavní větev na serveru, z kterého jste klonovali (za předpokladu, že má vzdálený server hlavní větev). Příkaz `git pull` většinou vyzvedne data ze serveru, z něhož jste původně klonovali, a automaticky se pokusí začlenit je do kódu, na němž právě pracujete.
 
-### Posílání do vzdálených repozitářů ###
+### Odesílání do vzdálených repozitářů ###
 
-Pokud se váš projekt nachází ve fázi, kdy ho chcete sdílet s ostatními, můžete ho odeslat (push) na vzdálený server. Příkaz pro tuto akci je jednoduchý: `git push [název vzdáleného repozitáře] [název větve]`. Pokud chcete poslat svou hlavní větev na server `origin` (i tady platí, že proces klonování vám nastaví názvy `master` i `origin` automaticky), můžete k odeslání své práce na server použít tento příkaz:
+Pokud se váš projekt nachází ve stavu, kdy ho chcete sdílet s ostatními, můžete ho odeslat (push) na vzdálený server. Příkaz pro tuto akci je jednoduchý: `git push [název vzdáleného repozitáře] [název větve]`. Pokud chcete poslat svou hlavní větev na server `origin` (i tady platí, že proces klonování vám nastaví názvy `master` i `origin` automaticky), můžete k odeslání své práce na server použít tento příkaz:
 
 	$ git push origin master
 
-Tento příkaz bude funkční, pouze pokud jste klonovali ze serveru, k němuž máte oprávnění pro zápis, a pokud sem od vašeho klonování nikdo neposílal svou práci. Pokud spolu s vámi provádí současně klonování ještě někdo další a ten poté svou práci odešle na server, vaše později odesílaná práce bude oprávněně odmítnuta. Nejprve musíte stáhnout práci ostatních a začlenit ji do své, teprve potom vám server umožní odeslání. Více informací o odesílání na vzdálené servery najdete v kapitole 3.
+Tento příkaz bude funkční, pouze pokud jste klonovali ze serveru, k němuž máte oprávnění pro zápis, a pokud sem od vašeho klonování nikdo neposílal svou práci. Pokud spolu s vámi provádí současně klonování ještě někdo další a ten poté svou práci odešle na server, vaše později odesílaná práce bude oprávněně odmítnuta. Nejprve musíte stáhnout práci ostatních a začlenit ji do své, teprve potom vám server umožní odeslání. Více informací o odesílání na vzdálené servery najdete v *kapitole 3*.
 
 ### Prohlížení vzdálených repozitářů ###
 
@@ -902,9 +902,9 @@ Jestliže chcete získat více informací o konkrétním vzdáleném repozitář
 	    master
 	    ticgit
 
-Bude obsahovat adresu URL vzdáleného repozitáře a informace ke sledování větví. Příkaz vám mimo jiné sděluje, že pokud se nacházíte na hlavní větvi (branch master) a spustíte příkaz `git pull`, automaticky začlení (merge) práci do hlavní větve na vzdáleném serveru, jakmile vyzvedne všechny vzdálené reference. Součástí výpisu jsou také všechny vzdálené reference, které příkaz stáhl.
+Bude obsahovat adresu URL vzdáleného repozitáře a informace ke sledování větví. Příkaz vám mimo jiné sděluje, že pokud se nacházíte na hlavní větvi (branch `master`) a spustíte příkaz `git pull`, pak se po vyzvednutí všech vzdálených referencí (fetch) práce z hlavní větve na vzdáleném serveru automaticky začlení (merge). Součástí výpisu jsou také všechny vzdálené reference, které příkaz stáhl.
 
-Toto je jednoduchý příklad, s nímž se můžete setkat. Pokud však Git používáte na pokročilé bázi, příkaz `git remote show` vám patrně zobrazí podstatně více informací:
+S uvedeným jednoduchým případem se pravděpodobně setkáte. Pokud však Git používáte na intenzivněji, může vám příkaz `git remote show` zobrazit mnohem více informací:
 
 	$ git remote show origin
 	* remote origin
@@ -928,11 +928,11 @@ Toto je jednoduchý příklad, s nímž se můžete setkat. Pokud však Git pou
 	  Local branch pushed with 'git push'
 	    master:master
 
-Tento příkaz vám ukáže, která větev bude automaticky odeslána, pokud spustíte příkaz `git push` na určitých větvích. Příkaz vám také oznámí, které vzdálené větve na serveru ještě nemáte, které vzdálené větve máte, jež už byly ze serveru odstraněny, a několik větví, které budou automaticky sloučeny, jestliže spustíte příkaz `git pull`.
+Tento příkaz ukazuje, která větev bude automaticky odeslána, pokud spustíte příkaz `git push` na určitých větvích. Příkaz vám také oznámí, které vzdálené větve na serveru ještě nemáte, které vzdálené větve máte, ale ze serveru už byly odstraněny, a několik větví, které budou automaticky sloučeny, jestliže spustíte příkaz `git pull`.
 
-### Přesouvání a přejmenovávání vzdálených repozitářů ###
+### Odstraňování a přejmenovávání vzdálených repozitářů ###
 
-Chcete-li přejmenovat vzdálený repozitář, můžete v novějších verzích systému Git spustit příkaz `git remote rename`. Příkazem lze změnit zkrácený název vzdáleného repozitáře. Pokud například chcete přejmenovat repozitář z `pb` na `paul`, můžete tak učinit pomocí příkazu `git remote rename`:
+Chcete-li změnit zkrácené jméno vzdáleného repozitáře, můžete v novějších verzích systému Git spustit příkaz `git remote rename`. Pokud například chcete přejmenovat repozitář z `pb` na `paul`, můžete tak učinit příkazem `git remote rename`:
 
 	$ git remote rename pb paul
 	$ git remote
@@ -941,7 +941,7 @@ Chcete-li přejmenovat vzdálený repozitář, můžete v novějších verzích
 
 Za zmínku stojí, že tímto příkazem změníte zároveň i názvy vzdálených větví. Z původní reference `pb/master` se tak nyní stává `paul/master`.
 
-Chcete-li, ať už z jakéhokoli důvodu, odstranit referenci (např. jste přesunuli server nebo už nepoužíváte dané zrcadlo, popř. přispěvatel přestal přispívat), můžete využít příkaz `git remote rm`:
+Chcete-li, ať už z jakéhokoli důvodu, odstranit referenci (přesunuli jste například server nebo už nepoužíváte dané zrcadlo, nebo třeba přispěvatel přestal přispívat), můžete využít příkaz `git remote rm`:
 
 	$ git remote rm paul
 	$ git remote
@@ -949,7 +949,7 @@ Chcete-li, ať už z jakéhokoli důvodu, odstranit referenci (např. jste přes
 
 ## Značky ##
 
-Stejně jako většina systémů VCS nabízí i Git možnost označovat v historii určitá místa, jež považujete za důležitá. Tato funkce se nejčastěji používá k označení jednotlivých vydání (např. `v1.0`). V této části vysvětlíme, jak pořídíte výpis všech dostupných značek, jak lze vytvářet značky nové a jaké typy značek se vám nabízejí.
+Stejně jako většina systémů VCS nabízí i Git možnost označovat v historii určitá místa, jež považujete za důležitá. Tato funkce se nejčastěji používá k označení jednotlivých vydání (například `v1.0`). V této části vysvětlíme, jak pořídíte výpis všech dostupných značek, jak lze vytvářet značky nové a jaké typy značek se vám nabízejí.
 
 ### Výpis značek ###
 
@@ -1127,7 +1127,7 @@ Můžete se podívat, že jste revizi označil:
 
 ### Sdílení značek ###
 
-Příkaz `git push` nepřenáší značky na vzdálené servery automaticky. Pokud jste vytvořili značku, budete ji muset na sdílený server poslat ručně. Tento proces je stejný jako sdílení vzdálených větví. Spusťte příkaz `git push origin [název značky]`.
+Příkaz `git push` nepřenáší značky na vzdálené servery automaticky. Pokud jste vytvořili značku, budete ji muset na sdílený server poslat explicitně. Tento proces je stejný jako sdílení vzdálených větví. Spusťte příkaz `git push origin [název značky]`.
 
 	$ git push origin v1.5
 	Counting objects: 50, done.
@@ -1155,17 +1155,17 @@ Pokud nyní někdo bude klonovat nebo stahovat z vašeho repozitáře, stáhne r
 
 ## Tipy a triky ##
 
-Než ukončíme tuto kapitolu o základech práce se systémem Git, přidáme ještě pár tipů a triků, které vám mohou usnadnit či zpříjemnit práci. Mnoho uživatelů pracuje se systémem Git, aniž by tyto triky znali a používali. V dalších částech knihy se už o nich nebudeme zmiňovat ani nebudeme předpokládat, že je používáte. Přesto pro vás mohou být užitečné.
+Než ukončíme tuto kapitolu věnovanou základům práce se systémem Git, přidáme ještě pár tipů a triků, které vám mohou usnadnit či zpříjemnit práci. Mnoho uživatelů pracuje se systémem Git, aniž by tyto triky znali a používali. V dalších částech knihy se už o nich nebudeme zmiňovat ani nebudeme předpokládat, že je používáte. Přesto pro vás mohou být užitečné.
 
 ### Automatické dokončování ###
 
-Jestliže používáte shell Bash, nabízí vám Git možnost zapnout si skript pro automatické dokončování. Stáhněte si zdrojový kód Git https://github.com/git/git/blob/master/contrib/completion/git-completion.bash. Nakopírujte tento soubor do vašeho domovského adresáře a do souboru `.bashrc` přidejte:
+Jestliže používáte shell Bash, nabízí vám Git možnost zapnout si skript pro automatické dokončování. Stáhněte si jej ze zdrojových textů systému Git z https://github.com/git/git/blob/master/contrib/completion/git-completion.bash. Soubor nakopírujte tento do vašeho domovského adresáře a do souboru `.bashrc` přidejte:
 
 	source ~/git-completion.bash
 
-Chcete-li nastavit Git tak, aby měl automaticky dokončování pro shell Bash pro všechny uživatele, zkopírujte tento skript do adresáře `/opt/local/etc/bash_completion.d` v systémech Mac nebo do adresáře `/etc/bash_completion.d/` v systémech Linux. Toto je adresář skriptů, z nějž Bash automaticky načítá pro shellové dokončování.
+Chcete-li nastavit Git tak, aby měl automaticky dokončování pro shell Bash pro všechny uživatele, zkopírujte u systému Mac tento skript do adresáře `/opt/local/etc/bash_completion.d`, nebo u systémů Linux do adresáře `/etc/bash_completion.d/`. Jde o adresář skriptů, ze kterého si Bash automaticky načítá podporu pro shellové dokončování.
 
-Pokud používáte Git Bash v systému Windows (Git Bash je výchozím programem při instalaci systému Git v OS Windows pomocí msysGit), mělo by být automatické dokončování přednastaveno.
+Pokud používáte Git Bash v systému Windows (Git Bash je pro instalaci msysGit pod Windows výchozím programem), mělo by být automatické dokončování přednastaveno.
 
 Při zadávání příkazu Git stiskněte klávesu Tab a měla by se objevit nabídka, z níž můžete zvolit příslušné dokončení:
 
@@ -1174,7 +1174,7 @@ Při zadávání příkazu Git stiskněte klávesu Tab a měla by se objevit nab
 
 Pokud zadáte – stejně jako v našem příkladu nahoře – `git co` a dvakrát stisknete klávesu Tab, systém vám navrhne „commit“ a „config“. Doplníte-li ještě `m<tab>`, skript automaticky dokončí příkaz na `git commit`.
 
-Automatické dokončování pravděpodobně více využijete v případě parametrů. Pokud například zadáváte příkaz `git log` a nemůžete si vzpomenout na některý z parametrů, můžete zadat jeho začátek a stisknout klávesu Tab, aby vám systém navrhl možná dokončení.
+Automatické dokončování pravděpodobně více využijete v případě parametrů. Pokud například zadáváte příkaz `git log` a nemůžete si vzpomenout na některý z parametrů, můžete zadat jeho začátek, stisknout klávesu Tab a podívat se, co by to mohlo přesně být:
 
 	$ git log --s<tab>
 	--shortstat  --since=  --src-prefix=  --stat   --summary

From 296367f8a8c8e1725a3b717e58899e7d9ca3551e Mon Sep 17 00:00:00 2001
From: Petr Prikryl <prikryl@atlas.cz>
Date: Tue, 5 Aug 2014 16:30:09 +0200
Subject: [PATCH 545/690] [cs] fixing the markup; minor translation
 enhancements

---
 cs/03-git-branching/01-chapter3.markdown   |  6 +++---
 cs/04-git-server/01-chapter4.markdown      | 20 ++++++++++----------
 cs/05-distributed-git/01-chapter5.markdown |  2 +-
 cs/06-git-tools/01-chapter6.markdown       |  4 ++--
 4 files changed, 16 insertions(+), 16 deletions(-)

diff --git a/cs/03-git-branching/01-chapter3.markdown b/cs/03-git-branching/01-chapter3.markdown
index c71858d38..9c4935cd7 100644
--- a/cs/03-git-branching/01-chapter3.markdown
+++ b/cs/03-git-branching/01-chapter3.markdown
@@ -454,7 +454,7 @@ Tímto způsobem získáte lokální větev, na níž můžete pracovat a která
 
 ### Sledující větve ###
 
-Checkoutem lokální větve ze vzdálené větve automaticky vytvoříte tzv. Sledující větev (angl. tracking branch). Sledující větve jsou lokální větve s přímým vztahem ke vzdálené větvi. Pokud se nacházíte na Sledující větvi a zadáte příkaz `git push`, Git automaticky ví, na který server a do které větve má data odeslat. Také příkazem `git pull` zadaným na sledovací větvi vyzvednete všechny vzdálené reference a Git poté odpovídající vzdálenou větev automaticky začlení.
+Checkoutem lokální větve ze vzdálené větve automaticky vytvoříte takzvanou *sledující větev* (angl. tracking branch). Sledující větve jsou lokální větve s přímým vztahem ke vzdálené větvi. Pokud se nacházíte na Sledující větvi a zadáte příkaz `git push`, Git automaticky ví, na který server a do které větve má data odeslat. Také příkazem `git pull` zadaným na sledovací větvi vyzvednete všechny vzdálené reference a Git poté odpovídající vzdálenou větev automaticky začlení.
 
 Pokud klonujete repozitář, většinou se vytvoří větev `master`, která bude sledovat větev `origin/master`. To je také důvod, proč příkazy `git push` a `git pull` fungují i bez dalších parametrů. Pokud chcete, můžete nastavit i jiné sledující větve – takové, které nebudou sledovat větve na serveru `origin` a nebudou sledovat hlavní větev `master`. Jednoduchým případem je příklad, který jste právě viděli: spuštění příkazu `git checkout -b [větev] [vzdálený server]/[větev]`. Máte-li Git ve verzi 1.6.2 nebo novější, můžete použít také zkrácenou variantu `--track`:
 
@@ -496,7 +496,7 @@ Víme, že nejjednodušším způsobem, jak integrovat větve, je příkaz `merg
 Insert 18333fig0328.png
 Obrázek 3-28. Integrace rozdělené historie sloučením větví
 
-Existuje však ještě jiný způsob. Můžete vzít záplatu se změnou, kterou jste provedli revizí C3, a aplikovat ji na vrcholu revize C4. V systému Git se tato metoda nazývá přeskládání (rebasing). Příkazem `rebase` vezmete všechny změny, které byly zapsány na jedné větvi, a necháte je znovu provést na jiné větvi.
+Existuje však ještě jiný způsob. Můžete vzít záplatu se změnou, kterou jste provedli revizí C3, a aplikovat ji na vrcholu revize C4. V systému Git se tato metoda nazývá *přeskládání* (rebasing). Příkazem `rebase` vezmete všechny změny, které byly zapsány na jedné větvi, a necháte je znovu provést na jiné větvi.
 
 V našem případě tedy provedete následující:
 
@@ -571,7 +571,7 @@ Obrázek 3-35. Konečná historie revizí
 
 Přeskládání sice nabízí určité výhody, má však také svá úskalí. Ta se dají shrnout do jedné věty:
 
-Neprovádějte přeskládání u revizí, které jste odeslali do veřejného repozitáře.
+**Neprovádějte přeskládání u revizí, které jste odeslali do veřejného repozitáře.**
 
 Budete-li se touto zásadou řídit, nemusíte se přeskládání obávat. V opačném případě vás čeká opovržení ostatních, rodina a přátelé vás zapřou.
 
diff --git a/cs/04-git-server/01-chapter4.markdown b/cs/04-git-server/01-chapter4.markdown
index 93147edbe..5e4d1a27c 100644
--- a/cs/04-git-server/01-chapter4.markdown
+++ b/cs/04-git-server/01-chapter4.markdown
@@ -6,7 +6,7 @@ Spuštění serveru Git je jednoduché. Nejprve určíte, jakými protokoly má
 
 Pokud víte, že nebudete chtít spravovat vlastní server, můžete přeskočit rovnou na poslední část této kapitoly a podívat se na možnosti nastavení hostovaného účtu. Pak přejděte na následující kapitolu, v níž se dočtete o různých vstupech a výstupech při práci v prostředí s distribuovanou správou zdrojového kódu.
 
-Vzdálený repozitář je obvykle holý repozitář, tj. repozitář Git bez pracovního adresáře. Protože se repozitář používá pouze jako místo pro spolupráci, není žádný důvod, aby byl na disku načten konkrétní snímek. Jsou tu pouze uložena data systému Git. Jednoduše bychom mohli také říct, že holý repozitář je obsah adresáře `.git` vašeho projektu a nic víc.
+Vzdálený repozitář je obvykle *holý repozitář* (bare repository), tj. repozitář Git bez pracovního adresáře. Protože se repozitář používá pouze jako místo pro spolupráci, není žádný důvod, aby byl na disku načten konkrétní snímek. Jsou tu pouze uložena data systému Git. Jednoduše bychom mohli také říct, že holý repozitář je obsah adresáře `.git` vašeho projektu a nic víc.
 
 ## Protokoly ##
 
@@ -16,7 +16,7 @@ Neměli bychom zamlčet ani to, že s výjimkou protokolu HTTP všechny vyžaduj
 
 ### Protokol Local ###
 
-Nejzákladnější variantou je protokol Local, v němž je vzdálený repozitář uložen v jiném adresáři na disku. Často se využívá v případech, kdy mají všichni z vašeho týmu přístup k vašim sdíleným souborům, např. přes připojení systému NFS, nebo – v méně pravděpodobném případě – se všichni přihlašují na jednom počítači. Tato druhá varianta není právě ideální, protože všechny instance repozitáře s kódem jsou v takovém případě umístěny v jednom počítači, čímž se zvyšuje riziko nevratné ztráty dat.
+Nejzákladnější variantou je *lokální protokol* (Local protocol), v němž je vzdálený repozitář uložen v jiném adresáři na disku. Často se využívá v případech, kdy mají všichni z vašeho týmu přístup k vašim sdíleným souborům, např. přes připojení systému NFS, nebo – v méně pravděpodobném případě – se všichni přihlašují na jednom počítači. Tato druhá varianta není právě ideální, protože všechny instance repozitáře s kódem jsou v takovém případě umístěny v jednom počítači, čímž se zvyšuje riziko nevratné ztráty dat.
 
 Máte-li připojený sdílený systém souborů, můžete klonovat, odesílat a stahovat z lokálního souborového repozitáře (local file-based repository). Chcete-li takový repozitář naklonovat nebo přidat jako vzdálený repozitář do existujícího projektu, použijte jako URL cestu k repozitáři. K naklonování lokálního repozitáře můžete použít příkaz například v tomto tvaru:
 
@@ -109,7 +109,7 @@ Z dalších výhod protokolu HTTP bychom mohli jmenovat i jeho značné rozší
 
 #### Nevýhody ####
 
-Nevýhodou obsluhy repozitáře přes protokol HTTP je poměrně nízká výkonnost pro klienta. Klonovat nebo vyzvedávat data z repozitáře trvá v případě protokolu HTTP obecně mnohem déle a vyžádá si většinou podstatně větší režii síťových operací a objem přenášených dat, než je tomu u ostatních síťových protokolů. Protože protokol není natolik inteligentní, aby přenášel pouze data, která potřebujete – v těchto transakcích se na straně serveru nesetkáte s dynamickou činností – je protokol HTTP často nazýván „dumb protocol“ (hloupý protokol). Více informací o rozdílech ve výkonnosti mezi protokolem HTTP a ostatními protokoly najdete v kapitole 9.
+Nevýhodou obsluhy repozitáře přes protokol HTTP je poměrně nízká výkonnost pro klienta. Klonovat nebo vyzvedávat data z repozitáře trvá v případě protokolu HTTP obecně mnohem déle a vyžádá si většinou podstatně větší režii síťových operací a objem přenášených dat, než je tomu u ostatních síťových protokolů. Protože protokol není natolik inteligentní, aby přenášel pouze data, která potřebujete – v těchto transakcích se na straně serveru nesetkáte s dynamickou činností – je protokol HTTP často nazýván *dumb protocol* (hloupý protokol). Více informací o rozdílech ve výkonnosti mezi protokolem HTTP a ostatními protokoly najdete v kapitole 9.
 
 ## Jak umístit Git na server ##
 
@@ -148,7 +148,7 @@ Vidíte, jak je jednoduché vzít repozitář Git, vytvořit jeho holou verzi a
 
 A to je skutečně vše, co je třeba ke spuštění serveru Git, k němuž bude mít přístup více lidí – na server stačí přidat SSH účty a umístit holý repozitář někam, kam budou mít všichni uživatelé oprávnění ke čtení i zápisu. Vše je připraveno, nic dalšího se od vás nevyžaduje.
 
-V dalších částech se podíváme na některé pokročilé možnosti nastavení. Dozvíte se v nich, jak se vyhnout nutnosti vytvářet uživatelské účty pro všechny uživatele, jak k repozitářům přiřadit veřejné oprávnění pro čtení, jak nastavit webová rozhraní nebo k čemu se používá nástroj Gitosis. To však nemění nic na tom, že ke spolupráci se skupinou lidí na soukromém projektu vystačíte s jedním SSH serverem a holým repozitářem.
+V dalších částech se podíváme na některé pokročilé možnosti nastavení. Dozvíte se v nich, jak se vyhnout nutnosti vytvářet uživatelské účty pro všechny uživatele, jak k repozitářům přiřadit veřejné oprávnění pro čtení, jak nastavit webová rozhraní nebo k čemu se používá nástroj Gitosis. To však nemění nic na tom, že ke spolupráci se skupinou lidí na soukromém projektu *vystačíte* s jedním SSH serverem a holým repozitářem.
 
 ### Nastavení pro malou skupinu ###
 
@@ -566,7 +566,7 @@ Přidávání dalších uživatelů je snadné. Pokud chceme přidat uživatele
 
 Syntaxe konfiguračního souboru pro Gitolite je dobře dokumentovaná, takže zde uvedu jen pár zajímavých věcí.
 
-Pro usnadnění můžete dávat uživatele i repozitáře do skupin. Jména skupin jsou podobná jako makra; když je definujete, je úplně jedno jestli jde o projekty nebo uživatele; rozdíl to je až v momentu, kdy „makro“ použijete.
+Pro usnadnění můžete dávat uživatele i repozitáře do skupin. Jména skupin jsou podobná jako makra; když je definujete, je úplně jedno jestli jde o projekty nebo uživatele; rozdíl to je až v momentu, kdy „makro“ *použijete*.
 
 	@oss_repos      = linux perl rakudo git gitolite
 	@secret_repos   = fenestra pear
@@ -597,21 +597,21 @@ Toto pravidlo se pak přidá do skupiny pravidel `gitolite` repozitáře.
 
 Teď by vás mohlo zajímat, jak jsou vlastně pravidla pro přístup aplikována, pojďme se na to tedy krátce podívat.
 
-V gitolite jsou dvě úrovně kontroly přístupů. První je úroveň repozitářů; jestliže máte práva na čtení (nebo zápis) k jakékoliv referenci v repozitáři, máte tím práva na čtení (nebo zápis) k tomuto repozitáři. Tohle je jediná možnost jakou měl nástroj Gitosis.
+V gitolite jsou dvě úrovně kontroly přístupů. První je úroveň repozitářů; jestliže máte práva na čtení (nebo zápis) *k jakékoliv* referenci v repozitáři, máte tím práva na čtení (nebo zápis) k tomuto repozitáři. Tohle je jediná možnost jakou měl nástroj Gitosis.
 
 Druhá úroveň je pouze pro práva pro „zápis“ a je podle větve nebo značky v repozitáři. Uživatelské jméno uživatele snažícího se o přístup (`W` nebo `+`) a jméno reference, kterou uživatel chce aktualizovat, jsou dané. Pravidla pro přístup jsou procházena postupně v pořadí, tak jak jsou uvedena v konfiguračním souboru a hledají se záznamy odpovídající této kombinaci uživatelského jména a reference (nezapomeňte ale, že refname se porovnává jako regulární výraz nikoliv jako pouhý řetězec). Jestliže je nalezen odpovídající záznam, odesílání je povoleno. Pokud není nalezeno nic, je přístup zamítnut.
 
-### Rozšířená kontrola přístupu ve větvi „rebel“ ###
+### Rozšířené řízení přístupu pravidly typu „odmítnutí“ ###
 
-Jak můžete vidět výše, práva musí být jedno z nastavení `R`, `RW` nebo `RW+`. Dříve zmíněná větev „rebel“ přidává ještě jedno další právo: `-`, znamenající „odmítnutí“. To dává mnohem více možností za cenu zvýšení složitosti, protože nyní už není nenalezení odpovídajícího záznamu při procházení pravidel jedinou možností, jak může být přístup zamítnut. Takže nyní už na pořadí pravidel záleží!
+Prozatím jsme si ukázali jen oprávnění nastavená na jednu z hodnot `R`, `RW` nebo `RW+`. Ale Gitolite dovoluje nastavení dalšího oprávnění: `-` s významem „odmítnutí“. To vám dává mnohem více možností, ale za cenu zvýšení složitosti. Popadnutí sítem pravidel už totiž není *jedinou* možností vedoucí k zamítnutí přístupu. *Nyní už záleží na pořadí pravidel!*
 
-Řekněme, že ve výše uvedené situaci budeme chtít, aby skupina engineers mohla vracet změny v jakékoliv větvi s výjimkou větvě „hlavní“ a větve „integ“. To se nedá nastavit pomocí normální syntaxe, ale s pomocí větve „rebel“ podle následujícího postupu:
+Řekněme, že ve výše uvedené situaci budeme chtít, aby skupina engineers mohla vracet změny v jakékoliv větvi *s výjimkou* větví `master` a `integ`. Udělá se to následovně:
 
 	    RW  master integ    = @engineers
 	    -   master integ    = @engineers
 	    RW+                 = @engineers
 
-Pravidla se znovu budou procházet postupně až do momentu, kdy bude nalezeno odpovídají pravidlo nebo bude přístup zamítnut. Odeslání do hlavní větve nebo větve „integ“, která nevracejí zpět změny, jsou povolena prvním pravidlem. Odeslání, která vracejí změny do těchto větví, neodpovídají prvnímu pravidlu. Porovnají se tedy s druhým pravidlem a na jeho základě budou zamítnuty. Odeslání (bez ohledu na to zda se jedná o vracení změn nebo ne) do jiných referencí než hlavní a „integ“ nebudou odpovídat ani prvnímu ani druhému pravidlu a budou tedy díky třetímu pravidlu povolena.
+Pravidla se  budou opět procházet shora dolů až do momentu, kdy narazíte na shodu s vaším režimem přístupu nebo na pravidlo typu odmítnutí (deny). Odeslání do větve `master` nebo `integ`, která nevracejí zpět změny (non-rewind push), jsou povolena prvním pravidlem. Odeslání, která vracejí změny (rewind push) do těchto větví, neodpovídají prvnímu pravidlu. Porovnají se tedy s druhým pravidlem a na jeho základě budou zamítnuty. Jakékoliv odeslání (bez ohledu na to zda se jedná o vracení změn nebo ne) do jiných referencí než `master` nebo `integ` nebudou odpovídat ani prvnímu ani druhému pravidlu, a proto bude díky třetímu pravidlu povoleno.
 
 ### Omezení odesílání změn vázané na soubory ###
 
diff --git a/cs/05-distributed-git/01-chapter5.markdown b/cs/05-distributed-git/01-chapter5.markdown
index 89140cfe2..f5848226b 100644
--- a/cs/05-distributed-git/01-chapter5.markdown
+++ b/cs/05-distributed-git/01-chapter5.markdown
@@ -328,7 +328,7 @@ Tady nastává určitý problém. Musí odeslat práci začleněnou ve své vět
 	To jessica@githost:simplegit.git
 	   fba9af8..cd685d1  featureB -> featureBee
 
-Říká se tomu refspec. Více o vzorcích refspec systému Git a různých možnostech, k nimž je lze využít, najdete v kapitole 9.
+Říká se tomu *refspec*. Více o vzorcích refspec systému Git a různých možnostech, k nimž je lze využít, najdete v kapitole 9.
 
 Poté pošle John Jessice e-mail, že odeslal několik změn do větve `featureA`, a poprosí ji, aby je ověřila. Jessica spustí příkaz `git fetch`, jímž tyto změny stáhne.
 
diff --git a/cs/06-git-tools/01-chapter6.markdown b/cs/06-git-tools/01-chapter6.markdown
index 987a56217..068bba4c9 100644
--- a/cs/06-git-tools/01-chapter6.markdown
+++ b/cs/06-git-tools/01-chapter6.markdown
@@ -1095,9 +1095,9 @@ Až poté přepnete zpět, bude adresář `rack` prázdný. Buď můžete spusti
 
 ## Začlenění podstromu ##
 
-Nyní, když jsme poznali obtíže spojené se systémem submodulů, podívejme se na jedno alternativní řešení tohoto problému. Git se vždy při slučování nejprve podívá, co a kam začleňuje, a podle toho zvolí vhodnou strategii začlenění. Pokud slučujete dvě větve, používá Git rekurzivní strategii. Pokud slučujete více než dvě větve, zvolí Git tzv. strategii chobotnice (octopus strategy). Git vybírá tyto strategie automaticky. Rekurzivní strategie zvládá složité třícestné slučování (např. s více než jedním společným předkem), ale nedokáže sloučit více než dvě větve. Chobotnicové sloučení dokáže naproti tomu sloučit několik větví, ale je opatrnější při předcházení složitým konfliktům. Proto je ostatně nastaveno jako výchozí strategie při slučování více než dvou větví.
+Nyní, když jsme poznali obtíže spojené se systémem submodulů, podívejme se na jedno alternativní řešení tohoto problému. Git se vždy při slučování nejprve podívá, co a kam začleňuje, a podle toho zvolí vhodnou strategii začlenění. Pokud slučujete dvě větve, používá Git *rekurzivní* strategii. Pokud slučujete více než dvě větve, zvolí Git tzv. strategii *chobotnice* (octopus strategy). Git vybírá tyto strategie automaticky. Rekurzivní strategie zvládá složité třícestné slučování (např. s více než jedním společným předkem), ale nedokáže sloučit více než dvě větve. Chobotnicové sloučení dokáže naproti tomu sloučit několik větví, ale je opatrnější při předcházení složitým konfliktům. Proto je ostatně nastaveno jako výchozí strategie při slučování více než dvou větví.
 
-Existují však ještě další strategie. Jednou z nich je tzv. začlenění podstromu (subtree merge), které lze použít jako řešení problémů se subprojektem. Ukažme si, jak se dá začlenit stejný adresář rack jako v předchozí části, tentokrát však s využitím strategie začlenění podstromu.
+Existují však ještě další strategie. Jednou z nich je tzv. začlenění *podstromu* (subtree merge), které lze použít jako řešení problémů se subprojektem. Ukažme si, jak se dá začlenit stejný adresář rack jako v předchozí části, tentokrát však s využitím strategie začlenění podstromu.
 
 Začlenění podstromu spočívá v tom, že máte dva projekty a jeden z projektů se promítá do podadresáře druhého projektu a naopak. Pokud určíte strategii začlenění podstromu, je Git natolik inteligentní, aby zjistil, že je jeden podstromem druhého, a provedl sloučení odpovídajícím způsobem – počíná si opravdu sofistikovaně.
 

From 9cd87e79edfac532e75c4f273a28a2133644a442 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Stian=20Dr=C3=B8bak?= <sum41rules4@hotmail.com>
Date: Tue, 5 Aug 2014 22:14:40 +0200
Subject: [PATCH 546/690] no-NB translate Ch. 2#Clone an Existing Repository

---
 no-nb/02-git-basics/01-chapter2.markdown | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/no-nb/02-git-basics/01-chapter2.markdown b/no-nb/02-git-basics/01-chapter2.markdown
index 04d6eb7a3..795cc3dbc 100644
--- a/no-nb/02-git-basics/01-chapter2.markdown
+++ b/no-nb/02-git-basics/01-chapter2.markdown
@@ -20,23 +20,23 @@ Om du ønsker å starte versjonkontroll på eksisterende filer (imotsetning til
 	$ git add README
 	$ git commit -m 'initial project version'
 
-Vi vil gæ over hva disse kommandoene gjør straks. Nå har du et Git repository med overvåkedne filer og en første kommit.
+Vi vil gå over hva disse kommandoene gjør straks. Nå har du et Git repository med overvåkedne filer og en første kommit.
 
-### Cloning an Existing Repository ###
+### Klone et Eksistrende Repository ###
 
-If you want to get a copy of an existing Git repository — for example, a project you’d like to contribute to — the command you need is `git clone`. If you’re familiar with other VCS systems such as Subversion, you’ll notice that the command is `clone` and not `checkout`. This is an important distinction — Git receives a copy of nearly all data that the server has. Every version of every file for the history of the project is pulled down when you run `git clone`. In fact, if your server disk gets corrupted, you can use any of the clones on any client to set the server back to the state it was in when it was cloned (you may lose some server-side hooks and such, but all the versioned data would be there — see *Chapter 4* for more details).
+Hvis du ænsker å hente en kopi av et eksisterende Git repository, for eksempel, et prosjekt du gjerne vil bidra til, så er kommandoen du trenger `git clone`. Hvis du er kjent med andre VCS systemer som Subversion, så vil du legge merke til at kommandoen er `clone`ikke `checkout`. Dette er en viktig forskjell. Git mottar en kopi av nesten all data som serveren har. Hver version av en hver fil i løpet av prosjektet historie vil bli dratt ned når du kjører `git clone`. Om server disken blir korrupt, så kan du bruke hvilken som helst av klonene på en hvilken som helst klient for å sette til tilstanden den var i når den var klonet (du mister kanskje noen hook-er og slikt på server siden , men all den versjonerte dataen ville vært der. Se *Kapitel 4* for mer detaljer).
 
-You clone a repository with `git clone [url]`. For example, if you want to clone the Ruby Git library called Grit, you can do so like this:
+Du kloner et repository med `git clone [url]`. For eksempel, hvis du ænsker å klone Ruby Git biblioteket kalt Grit, så kan du gjøre det slik:
 
 	$ git clone git://github.com/schacon/grit.git
 
-That creates a directory named `grit`, initializes a `.git` directory inside it, pulls down all the data for that repository, and checks out a working copy of the latest version. If you go into the new `grit` directory, you’ll see the project files in there, ready to be worked on or used. If you want to clone the repository into a directory named something other than grit, you can specify that as the next command-line option:
+Det lager en mappe kalt `grit`, initierer en `.git` mappe inni den, og drar ned all dataen fra det repositoriet, og sjekker ut en funksjonell kopi av den nyeste versjonen. Hvis du går inn i den nye `grit`mappen, så vil du se prosjekt filer inni den, klar til å bli bearbeidet eller brukt. Om du ønsker å klone repositoriet inn i en annen mappe kalt noe annet enn grit, så kan du spesifisere det som det neste kommandolinje valget.
 
 	$ git clone git://github.com/schacon/grit.git mygrit
 
-That command does the same thing as the previous one, but the target directory is called `mygrit`.
+Den kommandoen gjør det samme som den forrige, bare at målmappen blir kalt `mygrit`.
 
-Git has a number of different transfer protocols you can use. The previous example uses the `git://` protocol, but you may also see `http(s)://` or `user@server:/path.git`, which uses the SSH transfer protocol. *Chapter 4* will introduce all of the available options the server can set up to access your Git repository and the pros and cons of each.
+Git har tallvis av forskjellige overgangprotokoller du kan bruke. Det forrige eksemplet bruker `git://`-protokollen , men du ser kanskje også `http(s)://` eller `user@server:/path.gti`, som bruker SSH overganprotokollen. *Kapitel 4* vil introdusere alle de tilgjenglige valgene serveren kan sette opp for å gi tilgang til ditt Git repository og fordelen og ulempen med hver av dem.
 
 ## Recording Changes to the Repository ##
 

From d68619c89852bddd90ca0f0bdb368fffb7959c15 Mon Sep 17 00:00:00 2001
From: Petr Prikryl <prikryl@atlas.cz>
Date: Tue, 5 Aug 2014 22:34:41 +0200
Subject: [PATCH 547/690] [cs] revision of Chapter 3 finished

---
 cs/03-git-branching/01-chapter3.markdown | 50 ++++++++++++------------
 1 file changed, 25 insertions(+), 25 deletions(-)

diff --git a/cs/03-git-branching/01-chapter3.markdown b/cs/03-git-branching/01-chapter3.markdown
index 9c4935cd7..5d486f281 100644
--- a/cs/03-git-branching/01-chapter3.markdown
+++ b/cs/03-git-branching/01-chapter3.markdown
@@ -1,23 +1,23 @@
 # Větve v systému Git #
 
-Téměř každý systém VCS podporuje do určité míry větvení. Větvení znamená, že se můžete odloučit od hlavní linie vývoje a pokračovat v práci, aniž byste tuto hlavní linii zanášeli. V mnoha VCS nástrojích se může jednat o poněkud náročný proces, který často vyžaduje vytvoření nové kopie adresáře se zdrojovým kódem. To může – zvláště u velkých projektů – trvat poměrně dlouho.
+Téměř každý systém pro správu verzí podporuje do určité míry větvení. Větvení znamená, že se můžete odloučit od hlavní linie vývoje a pokračovat v práci, aniž byste hlavní linii zanášeli smetím. V mnoha VCS nástrojích se může jednat o poněkud náročný proces, který často vyžaduje vytvoření nové kopie adresáře se zdrojovým kódem. To může – zvláště u velkých projektů – trvat poměrně dlouho.
 
-Někteří lidé mluví o modelu větvení v systému Git jako o jeho exkluzivní funkci. Není sporu o tom, že je Git díky tomuto modelu v komunitě VCS poměrně jedinečný. V čem je jeho větvení ojedinělé? Větvení je v systému Git neuvěřitelně lehké a operace s ním související probíhají téměř okamžitě. Stejně rychlé je i přepínání mezi jednotlivými větvemi. Na rozdíl od ostatních systémů VCS Git podporuje způsob práce s bohatým větvením a častým slučováním, a to i několikrát za den. Pokud tuto funkci pochopíte a zvládnete její ovládání, dostanete do ruky výkonný a unikátní nástroj, který doslova změní váš pohled na vývoj.
+Někteří lidé mluví o modelu větvení v systému Git jako o jeho „vražedné vlastnosti“. Není sporu o tom, že je Git díky tomu ve skupině systémů pro správu verzí poměrně jedinečný. V čem je jeho větvení tak zvláštní? Větvení je v systému Git neuvěřitelně snadné a operace s ním související probíhají téměř okamžitě. A stejně rychlé je i přepínání mezi jednotlivými větvemi. Na rozdíl od ostatních systémů pro správu verzí vybízí Git ke způsobu práce s bohatým větvením a častým slučováním, a to i několikrát za den. Pokud tuto funkci pochopíte a zvládnete její ovládání, dostanete do ruky výkonný a unikátní nástroj, který doslova změní váš pohled na vývoj.
 
 ## Co je to větev ##
 
 Abychom skutečně pochopili, jak funguje v systému Git větvení, budeme se muset vrátit o krok zpět a podívat se, jak Git ukládá data. Jak si možná vzpomínáte z kapitoly 1, Git neukládá data jako sérii změn nebo rozdílů, ale jako sérii snímků.
 
-Zapíšete-li v systému Git revizi, Git uloží objekt revize, obsahující ukazatel na snímek obsahu, který jste určili k zapsání, metadata o autorovi a zprávě a nula nebo více ukazatelů na revizi nebo revize, které byly přímými rodiči této revize – žádné rodiče nemá první revize, jednoho rodiče má běžná revize a několik rodičů mají revize, které vznikly sloučením ze dvou či více větví.
+Zapíšete-li v systému Git revizi, Git uloží objekt revize, obsahující ukazatel na snímek obsahu, který jste určili k zapsání, metadata o autorovi a zprávě a nula nebo více ukazatelů na revizi nebo revize, které byly přímými rodiči této revize: žádné rodiče nemá první revize, jednoho rodiče má běžná revize a několik rodičů mají revize, které vznikly sloučením ze dvou či více větví.
 
-Pro ilustraci předpokládejme, že máte adresář se třemi soubory, které připravíte k zapsání a následně zapíšete. S připravením souborů k zapsání proběhne u každého z nich kontrolní součet (o otisku SHA-1 jsme se zmínili v kapitole 1), daná verze souborů se uloží v repozitáři Git (Git na ně odkazuje jako na bloby) a přidá jejich kontrolní součet do oblasti připravených změn:
+Pro ilustraci předpokládejme, že máte adresář se třemi soubory, které připravíte k zapsání a následně zapíšete. Při přípravě souborů k zapsání je pro každý z nich vypočítán kontrolní součet (o otisku SHA-1 jsme se zmínili v kapitole 1), daná verze souborů se uloží v repozitáři Git (Git na ně odkazuje jako na bloby) a přidá jejich kontrolní součet do oblasti připravených změn:
 
 	$ git add README test.rb LICENSE
 	$ git commit -m 'initial commit of my project'
 
 Vytvoříte-li revizi příkazem `git commit`, provede Git kontrolní součet každého adresáře (v tomto případě pouze kořenového adresáře projektu) a uloží tyto objekty stromu v repozitáři Git. Poté vytvoří objekt revize s metadaty a ukazatelem na kořenový strom projektu, aby mohl v případě potřeby tento snímek obnovit.
 
-Váš repozitář Git nyní obsahuje pět objektů: jeden blob pro obsah každého ze tří vašich souborů, jeden strom, který zaznamenává obsah adresáře a udává, které názvy souborů jsou uloženy jako který blob, a jednu revizi s ukazatelem na kořenový strom a se všemi metadaty revize. Data ve vašem repozitáři Git se dají schematicky znázornit jako na obrázku 3-1.
+Váš gitovský repozitář nyní obsahuje pět objektů: jeden blob pro obsah každého ze tří vašich souborů, jeden strom, který zaznamenává obsah adresáře a udává, které názvy souborů jsou uloženy jako který blob, a jeden objekt revize s ukazatelem na kořenový strom a se všemi metadaty revize. Data ve vašem repozitáři Git se dají schematicky znázornit jako na obrázku 3-1.
 
 Insert 18333fig0301.png
 Obrázek 3-1. Repozitář s daty jedné revize
@@ -41,7 +41,7 @@ Tento příkaz vytvoří nový ukazatel na stejné revizi, na níž se právě n
 Insert 18333fig0304.png
 Obrázek 3-4. Několik větví ukazujících do historie dat revizí
 
-Jak Git pozná, na jaké větvi se právě nacházíte? Používá speciální ukazatel zvaný HEAD. Nenechte se mást, tento HEAD je velmi odlišný od všech koncepcí v ostatních systémech VCS, na něž jste možná zvyklí, jako Subversion nebo CVS. V systému Git se jedná o ukazatel na lokální větev, na níž se právě nacházíte. V našem případě jste však stále ještě na hlavní větvi. Příkazem `git branch` jste pouze vytvořili novou větev, zatím jste na ni nepřepnuli (viz obrázek 3-5).
+Jak Git pozná, na jaké větvi se právě nacházíte? Používá speciální ukazatel zvaný HEAD. Nenechte se mást, tento HEAD je velmi odlišný od všech koncepcí v ostatních systémech pro správu verzí, na něž jste možná zvyklí, jako Subversion nebo CVS. V systému Git se jedná o ukazatel na lokální větev, na níž se právě nacházíte. V našem případě jste však stále ještě na hlavní větvi. Příkazem `git branch` jste pouze vytvořili novou větev, zatím jste na ni nepřepnuli (viz obrázek 3-5).
 
 Insert 18333fig0305.png
 Obrázek 3-5. Soubor HEAD ukazující na větev, na níž se nacházíte.
@@ -86,11 +86,11 @@ Nyní se historie vašeho projektu rozdělila (viz obrázek 3-9). Vytvořili jst
 Insert 18333fig0309.png
 Obrázek 3-9. Historie větví se rozdělila.
 
-Vzhledem k tomu, že větev v systému Git tvoří jeden jednoduchý soubor, obsahující 40 znaků kontrolního součtu SHA-1 revize, na niž ukazuje, je snadné větve vytvářet i odstraňovat. Vytvořit novou větev je právě tak snadné a rychlé jako zapsat 41 bytů do souboru (40 znaků a jeden nový řádek).
+Vzhledem k tomu, že větev v systému Git tvoří jeden jednoduchý soubor, obsahující 40 znaků kontrolního součtu SHA-1 revize, na niž ukazuje, je snadné větve vytvářet i odstraňovat. Vytvořit novou větev je právě tak snadné a rychlé jako zapsat 41 bytů do souboru (40 znaků a jeden znak pro nový řádek).
 
 Tato metoda se výrazně liší od způsobu, jakým probíhá větvení v ostatních nástrojích VCS, kde je nutné zkopírovat všechny soubory projektu do jiného adresáře. To může zabrat – podle velikosti projektu – několik sekund i minut, zatímco v systému Git probíhá tento proces vždy okamžitě. A protože při zapisování revize zaznamenáváme její rodiče, probíhá vyhledávání příslušné základny pro sloučení automaticky a je většinou velmi snadné. Tyto funkce slouží k tomu, aby se vývojáři nebáli vytvářet a používat nové větve.
 
-Podívejme se, jaké výhody jim z toho plynou.
+Podívejme se, proč byste to měli dělat také tak.
 
 ## Základy větvení a slučování ##
 
@@ -100,7 +100,7 @@ Vytvořme si jednoduchý příklad větvení a slučování s pracovním postupe
 2.  Vytvoříte větev pro novou část stránek, v níž budete pracovat.
 3.  Vytvoříte práci v této větvi.
 
-V tomto okamžiku vám zavolají, že se vyskytla jiná kritická chyba, která vyžaduje hotfix. Uděláte následující:
+V tomto okamžiku vám zavolají, že se vyskytla jiná kritická chyba, která vyžaduje rychlou opravu (hotfix). Uděláte následující:
 
 1.  Vrátíte se zpět na produkční větev.
 2.  Vytvoříte větev pro přidání hotfixu.
@@ -129,7 +129,7 @@ Obrázek 3-11 ukazuje výsledek.
 Insert 18333fig0311.png
 Obrázek 3-11. Vytvoření nového ukazatele na větev
 
-Pracujete na webových stránkách a zapíšete několik revizí. S každou novou revizí se větev `iss53` posune vpřed, protože jste provedli její checkout (to znamená, že jste na ni přepnuli a ukazuje na ni soubor HEAD – viz obrázek 3-12):
+Pracujete na webových stránkách a zapíšete několik revizí. S každou novou revizí se větev `iss53` posune vpřed, protože jste provedli její checkout (to znamená, že na ni přepnuli ukazuje HEAD – viz obrázek 3-12):
 
 	$ vim index.html
 	$ git commit -a -m 'added a new footer [issue 53]'
@@ -139,12 +139,12 @@ Obrázek 3-12. Větev iss53 se s vaší prací posouvá vpřed.
 
 V tomto okamžiku vám zavolají, že se na webových stránkách vyskytl problém, který musíte okamžitě vyřešit. Jelikož pracujete v systému Git, nemusíte svou opravu vytvářet uprostřed změn, které jste provedli v části `iss53`, ani nemusíte dělat zbytečnou práci, abyste všechny tyto změny vrátili, než budete moci začít pracovat na opravě produkční verze stránek. Jediné, co teď musíte udělat, je přepnout zpět na hlavní větev.
 
-Než tak učiníte, zkontrolujte, zda nemáte v pracovním adresáři nebo v oblasti připravených změn nezapsané změny, které kolidují s větví, jejíž checkout provádíte. V takovém případě by vám Git přepnutí větví nedovolil. Při přepínání větví je ideální, pokud máte čistý pracovní stav. Existují způsoby, jak toho docílit (jmenovitě odložení a doplnění revize), těm se však budeme věnovat až později. Pro tuto chvíli jste zapsali všechny provedené změny a můžete přepnout zpět na hlavní větev.
+Než tak učiníte, zkontrolujte, zda nemáte v pracovním adresáři nebo v oblasti připravených změn nezapsané změny, které kolidují s větví, jejíž checkout provádíte. V takovém případě by vám Git přepnutí větví nedovolil. Při přepínání větví je ideální, pokud máte čistý pracovní stav. Existují způsoby, jak to obejít (jmenovitě odložení (stashing) a doplnění revize (commit amending)), těm se však budeme věnovat až později. Pro tuto chvíli jste zapsali všechny provedené změny a můžete přepnout zpět na hlavní větev.
 
 	$ git checkout master
 	Switched to branch 'master'
 
-V tomto okamžiku vypadá váš pracovní adresář přesně tak, jak vypadal, než jste začali pracovat na chybě č. 53, a vy se nyní můžete soustředit na rychlou opravu. Na paměti byste však stále měli mít následující: Git vždy vrátí pracovní adresář do stejného stavu, jak vypadal snímek revize, na niž ukazuje větev, jejíž checkout nyní provádíte. Automaticky budou přidány, odstraněny a upraveny soubory tak, aby byla vaše pracovní kopie totožná se stavem větve v okamžiku, kdy jste na ni zapsali poslední revizi.
+V tomto okamžiku vypadá váš pracovní adresář přesně tak, jak vypadal, než jste začali pracovat na chybě č. 53, a vy se nyní můžete soustředit na rychlou opravu. Tento důležitý bod si zapamatujte: Git vždy vrátí pracovní adresář do stejného stavu, jak vypadal snímek revize, na niž ukazuje větev, jejíž checkout nyní provádíte. Automaticky budou přidány, odstraněny a upraveny soubory tak, aby byla vaše pracovní kopie totožná se stavem větve v okamžiku, kdy jste na ni zapsali poslední revizi.
 
 Nyní přichází na řadu hotfix. Vytvořme větev s hotfixem, v níž budeme pracovat, dokud nebude oprava hotová (viz obrázek 3-13):
 
@@ -158,7 +158,7 @@ Nyní přichází na řadu hotfix. Vytvořme větev s hotfixem, v níž budeme p
 Insert 18333fig0313.png
 Obrázek 3-13. Větev „hotfix“ začleněná zpět v místě hlavní větve
 
-Můžete provádět testování, ujistit se, že hotfix splňuje všechny požadavky, a pak můžete větev začlenit (merge) zpět do hlavní větve, aby byla připravena do produkce. Učiníte tak příkazem `git merge`:
+Můžete spustit testy, abyste se ujistili, že hotfix splňuje všechny požadavky, a pak můžete větev začlenit (merge) zpět do hlavní větve, aby byla připravena do produkce. Učiníte tak příkazem `git merge`:
 
 	$ git checkout master
 	$ git merge hotfix
@@ -191,7 +191,7 @@ Nyní můžete přepnout zpět na větev s rozdělanou prací a pokračovat na c
 Insert 18333fig0315.png
 Obrázek 3-15. Větev iss53 může nezávisle postupovat vpřed.
 
-Za zmínku stojí, že práce, kterou jste udělali ve větvi `hotfix`, není obsažena v souborech ve větvi `iss53`. Pokud potřebujete tyto změny do větve natáhnout, můžete začlenit větev `master` do větve `iss53` – použijte příkaz `git merge master`. Druhou možností je s integrací změn vyčkat a provést ji až ve chvíli, kdy budete chtít větev `iss53` natáhnout zpět do větve `master`.
+Za zmínku stojí, že práce, kterou jste udělali ve větvi `hotfix`, není obsažena v souborech ve větvi `iss53`. Pokud potřebujete tyto změny do větve vtáhnout, můžete začlenit větev `master` do větve `iss53` provedením příkazu `git merge master`. Druhou možností je s integrací změn vyčkat a provést ji až ve chvíli, kdy budete chtít větev `iss53` vtáhnout zpět do větve `master`.
 
 ### Základní slučování ###
 
@@ -211,7 +211,7 @@ Obrázek 3-16. Git automaticky identifikuje nejvhodnějšího společného před
 
 Git tentokrát neposune ukazatel větve vpřed, ale vytvoří nový snímek jako výsledek tohoto třícestného sloučení a automaticky vytvoří novou revizi, která bude na snímek ukazovat (viz obrázek 3-17). Takové revizi se říká revize sloučením (merge commit) a její zvláštností je to, že má více než jednoho rodiče.
 
-Na tomto místě bych chtěl zopakovat, že Git určuje nejvhodnějšího společného předka, který bude použit jako základna pro sloučení, automaticky. Liší se tím od systému CVS i Subversion (před verzí 1.5), kde musí vývojář při slučování najít nejvhodnější základnu pro sloučení sám. Slučování větví je tak v systému Git o poznání jednodušší než v těchto ostatních systémech.
+Na tomto místě bych chtěl zopakovat, že Git určuje nejvhodnějšího společného předka, který bude použit jako základna pro sloučení, automaticky. Liší se tím od systému CVS i Subversion (před verzí 1.5), kde musí vývojář při slučování najít nejvhodnější základnu pro sloučení sám. Slučování větví je proto v systému Git o poznání jednodušší než v ostatních systémech.
 
 Insert 18333fig0317.png
 Obrázek 3-17. Git automaticky vytvoří nový objekt revize, který obsahuje sloučenou práci.
@@ -243,7 +243,7 @@ Git nepřistoupil k automatickému vytvoření nové revize sloučením. Prozat
 
 	no changes added to commit (use "git add" and/or "git commit -a")
 
-Vše, co při sloučení kolidovalo a nebylo vyřešeno, je označeno jako „unmerged“ (nesloučeno). Git přidává ke kolidujícím souborům standardní poznámky o řešení konfliktů (conflict-resolution markers), takže je můžete ručně otevřít a konflikty vyřešit. Jedna část vašeho souboru bude vypadat zhruba takto:
+Vše, co při sloučení kolidovalo a nebylo vyřešeno, je označeno jako „unmerged“ (nesloučeno). Git přidává ke kolidujícím souborům standardní značky pro označení konfliktů (conflict-resolution markers), takže soubor můžete ručně otevřít a konflikty vyřešit. Jedna část vašeho souboru bude vypadat zhruba takto:
 
 	<<<<<<< HEAD
 	<div id="footer">contact : email.support@github.com</div>
@@ -352,7 +352,7 @@ Teď, když jste absolvovali základní seznámení s větvemi a jejich slučov
 
 Vzhledem k tomu, že Git používá jednoduché třícestné slučování, je velmi snadné začleňovat jednu větev do druhé i několikrát v rámci dlouhého časového intervalu. Můžete tak mít několik větví, které jsou stále otevřené a které používáte pro různé fáze vývojového cyklu. Pravidelně můžete začleňovat práci z jedné větve do ostatních.
 
-Mnoho vývojářů systému Git používá pracovní postup, kdy mají ve větvi `master` pouze kód, který je stoprocentně stabilní — třeba jen kód, který byl nebo bude součástí vydání. Kromě ní mají další paralelní větev, pojmenovanou `develop` nebo `next`, v níž skutečně pracují nebo testují stabilitu kódu. Tato větev nemusí být nutně stabilní, ale jakmile se dostane do stabilního stavu, může být začleněna do větve `master`. Ta se pak používá se k začleňování do tematických větví (těch dočasných, jako byla vaše větev `iss53`) ve chvíli, kdy je k tomu vše připraveno a nehrozí, že práce neprojde testy nebo bude způsobovat chyby.
+Mnoho vývojářů systému Git používá pracovní postup, kdy mají ve větvi `master` pouze kód, který je stoprocentně stabilní — třeba jen kód, který byl nebo bude součástí vydání. Kromě ní mají další paralelní větev, pojmenovanou `develop` nebo `next`, v níž skutečně pracují nebo testují stabilitu kódu. Tato větev nemusí být nutně stabilní, ale jakmile se dostane do stabilního stavu, může být začleněna do větve `master`. Do ní se vtahují tématické větve (ty dočasné, jako byla vaše větev `iss53`) ve chvíli, kdy jsou připravené a je jisté, že projdou všemi testy a nezavlečou chyby.
 
 Ve skutečnosti hovoříme o ukazatelích pohybujících se vzhůru po linii revizí, které zapisujete. Stabilní větve leží v linii historie revizí níže a nové, neověřené větve se nacházejí nad nimi (viz obrázek 3-18).
 
@@ -369,11 +369,11 @@ Není nutné používat při práci několik dlouhých větví, ale často to m
 
 ### Tematické větve ###
 
-Naproti tomu tematické větve se vám budou hodit v projektech jakékoli velikosti. Tematická větev (topic branch) je krátkodobá větev, kterou vytvoříte a používáte pro jediný konkrétní účel nebo práci. Je to záležitost, do které byste se ve VCS asi raději nikdy nepustili, protože vytvářet a slučovat větve je v něm opravdu složité. V systému Git naopak není výjimkou vytvářet, používat, slučovat a mazat větve i několikrát denně.
+Naproti tomu tematické větve se vám budou hodit v projektech jakékoli velikosti. Tematická větev (topic branch) je krátkodobá větev, kterou vytvoříte a používáte pro jediný konkrétní účel nebo práci. Je to záležitost, do které byste se v jiném systému pro správu verzí asi raději nikdy nepustili, protože vytvářet a slučovat větve je v něm opravdu složité. V systému Git naopak není výjimkou vytvářet, používat, slučovat a mazat větve i několikrát denně.
 
-Viděli jste to v předchozí části, kdy jste si vytvořili větve `iss53` a `hotfix`. Provedli jste v nich pár revizí a smazali jste je hned po začlenění změn do hlavní větve. Tato technika umožňuje rychlé a kompletní kontextové přepínání. Protože je vaše práce rozdělena do zásobníků, kde všechny změny v jedné větvi souvisí s jedním tématem, je při kontrole kódu snazší dohledat, čeho se změny týkaly apod. Změny tu můžete uchovávat několik minut, dní i měsíců a začlenit je přesně ve vhodnou chvíli. Na pořadí, v jakém byly větve vytvořeny nebo vyvíjeny, nezáleží.
+Viděli jste to v předchozí části, kdy jste si vytvořili větve `iss53` a `hotfix`. Provedli jste v nich pár revizí a smazali jste je hned po začlenění změn do hlavní větve. Tato technika umožňuje rychlé a snadné kontextové přepínání. Protože je vaše práce rozdělena do zásobníků, kde všechny změny v jedné větvi souvisí s jedním tématem, je při kontrole kódu snazší dohledat, čeho se změny týkaly apod. Změny tu můžete uchovávat několik minut, dní i měsíců a začlenit je přesně ve vhodnou chvíli. Na pořadí, v jakém byly větve vytvořeny nebo vyvíjeny, nezáleží.
 
-Uvažujme nyní následující situaci: pracujete na projektu v hlavní větvi (`master`), odbočíte z ní k vyřešení jednoho problému (`iss91`), chvíli na něm pracujete, ale vytvoříte ještě další větev, abyste zkusili jiné řešení stejné chyby (`iss91v2`). Pak se vrátíte zpět na hlavní větev, kde pokračujete v práci, než dostanete nápad, který by se možná mohl osvědčit, a tak pro něj vytvoříte další větev (`dumbidea`). Historie revizí bude vypadat zhruba jako na obrázku 3-20.
+Uvažujme nyní následující situaci: pracujete na projektu v hlavní větvi (`master`), odvětvíme se z ní k vyřešení jednoho problému (`iss91`), chvíli na něm pracujete, ale vytvoříte ještě další větev, abyste zkusili jiné řešení stejné chyby (`iss91v2`). Pak se vrátíte zpět do hlavní větve, kde pokračujete v práci, a pak dostanete nápad, který by se možná mohl osvědčit, a tak pro něj vytvoříte další větev (`dumbidea`). Historie revizí bude vypadat zhruba jako na obrázku 3-20.
 
 Insert 18333fig0320.png
 Obrázek 3-20. Historie revizí s několika tematickými větvemi
@@ -401,7 +401,7 @@ Pokud nyní budete pracovat na své lokální hlavní větvi a někdo z kolegů
 Insert 18333fig0323.png
 Obrázek 3-23. Pokud pracujete lokálně a někdo jiný odešle svou práci na vzdálený server, obě historie se rozejdou.
 
-K synchronizaci své práce použijte příkaz `git fetch origin`. Tento příkaz zjistí, který server je „origin“ (v našem případě je to `git.ourcompany.com`), vyzvedne z něj všechna data, která ještě nemáte, a aktualizuje vaši lokální databázi. Při tom přemístí ukazatel `origin/master` na novou, aktuálnější pozici (viz obrázek 3-24).
+K synchronizaci své práce použijte příkaz `git fetch origin`. Tento příkaz zjistí, který server je `origin` (v našem případě je to `git.ourcompany.com`), vyzvedne z něj všechna data, která ještě nemáte, a aktualizuje vaši lokální databázi. Při tom přemístí ukazatel `origin/master` na novou, aktuálnější pozici (viz obrázek 3-24).
 
 Insert 18333fig0324.png
 Obrázek 3-24. Příkaz `git fetch` aktualizuje vaše reference na vzdálený server.
@@ -454,9 +454,9 @@ Tímto způsobem získáte lokální větev, na níž můžete pracovat a která
 
 ### Sledující větve ###
 
-Checkoutem lokální větve ze vzdálené větve automaticky vytvoříte takzvanou *sledující větev* (angl. tracking branch). Sledující větve jsou lokální větve s přímým vztahem ke vzdálené větvi. Pokud se nacházíte na Sledující větvi a zadáte příkaz `git push`, Git automaticky ví, na který server a do které větve má data odeslat. Také příkazem `git pull` zadaným na sledovací větvi vyzvednete všechny vzdálené reference a Git poté odpovídající vzdálenou větev automaticky začlení.
+Checkoutem lokální větve ze vzdálené větve automaticky vytvoříte takzvanou *sledující větev* (angl. tracking branch). Sledující větve jsou lokální větve s přímým vztahem ke vzdálené větvi. Pokud se nacházíte na sledující větvi a zadáte příkaz `git push`, Git automaticky ví, na který server a do které větve má data odeslat. Také příkazem `git pull` zadaným na sledovací větvi vyzvednete všechny vzdálené reference a Git poté odpovídající vzdálenou větev automaticky začlení.
 
-Pokud klonujete repozitář, většinou se vytvoří větev `master`, která bude sledovat větev `origin/master`. To je také důvod, proč příkazy `git push` a `git pull` fungují i bez dalších parametrů. Pokud chcete, můžete nastavit i jiné sledující větve – takové, které nebudou sledovat větve na serveru `origin` a nebudou sledovat hlavní větev `master`. Jednoduchým případem je příklad, který jste právě viděli: spuštění příkazu `git checkout -b [větev] [vzdálený server]/[větev]`. Máte-li Git ve verzi 1.6.2 nebo novější, můžete použít také zkrácenou variantu `--track`:
+Pokud klonujete repozitář, většinou se vytvoří větev `master`, která bude sledovat větev `origin/master`. To je také důvod, proč příkazy `git push` a `git pull` fungují samy od sebe i bez dalších parametrů. Pokud chcete, můžete nastavit i jiné sledující větve – takové, které nebudou sledovat větve na serveru `origin` a nebudou sledovat hlavní větev `master`. Jednoduchým případem je příklad, který jste právě viděli: spuštění příkazu `git checkout -b [větev] [vzdálený server]/[větev]`. Máte-li Git ve verzi 1.6.2 nebo novější, můžete použít také zkrácenou variantu `--track`:
 
 	$ git checkout --track origin/serverfix
 	Branch serverfix set up to track remote branch serverfix from origin.
@@ -545,7 +545,7 @@ Nyní můžete posunout hlavní větev „rychle vpřed“ (viz obrázek 3-33):
 Insert 18333fig0333.png
 Obrázek 3-33. Posun hlavní větve rychle vpřed na konec změn přeskládaných z větve client
 
-Řekněme, že se později rozhodnete natáhnout i větev server. Větev server můžete přeskládat na hlavní větev příkazem `git rebase [základna] [tematická větev]`. Příkaz provede checkout tematické větve (v tomto případě větve `server`) a přeskládá její změny na základnu (angl. base branch, v tomto případě `master`):
+Řekněme, že se později rozhodnete vtáhnout i větev server. Větev server můžete přeskládat na hlavní větev příkazem `git rebase [základna] [tematická větev]`. Příkaz provede checkout tematické větve (v tomto případě větve `server`) a přeskládá její změny na základnu (angl. base branch, v tomto případě `master`):
 
 	$ git rebase master server
 
@@ -573,7 +573,7 @@ Přeskládání sice nabízí určité výhody, má však také svá úskalí. T
 
 **Neprovádějte přeskládání u revizí, které jste odeslali do veřejného repozitáře.**
 
-Budete-li se touto zásadou řídit, nemusíte se přeskládání obávat. V opačném případě vás čeká opovržení ostatních, rodina a přátelé vás zapřou.
+Budete-li se touto zásadou řídit, nemusíte se přeskládání obávat. V opačném případě vás čeká nenávist ostatních a rodina a přátelé vás zavrhnou.
 
 Při přeskládání dat zahodíte existující revize a vytvoříte nové, které jsou jim podobné, ale přesto jiné. Pokud odešlete svou práci, ostatní si ji stáhnou a založí na nich svou práci. A vy potom tyto revize přepíšete příkazem `git rebase` a znovu je odešlete, vaši spolupracovníci do ní budou muset znovu začlenit svou práci a ve všem nastane chaos, až se pokusíte natáhnout jejich práci zpět do své.
 

From a4fa9be029aef760495b1374b7be16951645fe73 Mon Sep 17 00:00:00 2001
From: Petr Prikryl <prikryl@atlas.cz>
Date: Wed, 6 Aug 2014 08:11:16 +0200
Subject: [PATCH 548/690] [cs] minor formulation correction in chapter 2

---
 cs/02-git-basics/01-chapter2.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/cs/02-git-basics/01-chapter2.markdown b/cs/02-git-basics/01-chapter2.markdown
index f0932e788..bb25003fd 100644
--- a/cs/02-git-basics/01-chapter2.markdown
+++ b/cs/02-git-basics/01-chapter2.markdown
@@ -139,7 +139,7 @@ Oba soubory jsou nyní připraveny k zapsání a budou zahrnuty do příští re
 	        modified:   benchmarks.rb
 
 
-Co to má být? Soubor `benchmarks.rb` je nyní uveden jak v části připraveno k zapsání (Changes to be committed), tak v části nepřipraveno k zapsání (Changes not staged for commit). Jak je tohle možné? Věc se má tak, že Git po spuštění příkazu `git add` připraví soubor k zapsání ve přesně tak, jak vypadá v daném okamžiku. Pokud nyní revizi zapíšete, bude obsahovat soubor `benchmarks.rb` tak, jak vypadal, když jste naposledy spustili příkaz `git add`, nikoli v té podobě, kterou měl v pracovním adresáři v okamžiku, když jste spustili příkaz `git commit`. Pokud upravíte soubor po provedení příkazu `git add`, je třeba spustit `git add` ještě jednou, aby byla připravena aktuální verze souboru:
+Co to má být? Soubor `benchmarks.rb` je nyní uveden jak v části připraveno k zapsání (Changes to be committed), tak v části nepřipraveno k zapsání (Changes not staged for commit). Jak je tohle možné? Věc se má tak, že Git po spuštění příkazu `git add` připraví soubor k zapsání přesně ve tvaru, v jakém se nachází v daném okamžiku. Pokud nyní revizi zapíšete, bude obsahovat soubor `benchmarks.rb` tak, jak vypadal, když jste naposledy spustili příkaz `git add`, nikoli v té podobě, kterou měl v pracovním adresáři v okamžiku, když jste spustili příkaz `git commit`. Pokud upravíte soubor po provedení příkazu `git add`, je třeba spustit `git add` ještě jednou, aby byla připravena aktuální verze souboru:
 
 	$ git add benchmarks.rb
 	$ git status

From bf1ea661c94855b55f5a9144ca209fe3eecc4d51 Mon Sep 17 00:00:00 2001
From: annoab <annoa.b@gmail.com>
Date: Sat, 30 Nov 2013 23:09:31 +0100
Subject: [PATCH 549/690] Update 01-chapter1.markdown

Few mispelled word
---
 fr/01-introduction/01-chapter1.markdown | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fr/01-introduction/01-chapter1.markdown b/fr/01-introduction/01-chapter1.markdown
index 2fda80793..8a0868fcc 100644
--- a/fr/01-introduction/01-chapter1.markdown
+++ b/fr/01-introduction/01-chapter1.markdown
@@ -291,10 +291,10 @@ Ces variables peuvent être stockées dans trois endroits différents :
 Si vous passez l'option `--system` à `git config`, il lit et écrit ce fichier spécifiquement.
 *	Fichier `~/.gitconfig` : Spécifique à votre utilisateur.
 Vous pouvez forcer Git à lire et écrire ce fichier en passant l'option `--global`.
-*	Fichier `config` dans le répertoire Git (c'est à dire `.git/config`) du dépôt en cours d'utilisation : spécifique au seul dépôt en cours.
+*	Fichier `config` dans le répertoire Git (c'est-à-dire `.git/config`) du dépôt en cours d'utilisation : spécifique au seul dépôt en cours.
 Chaque niveau surcharge le niveau précédent, donc les valeurs dans `.git/config` surchargent celles de `/etc/gitconfig`.
 
-Sur les systèmes Windows, Git recherche le fichier `.gitconfig` dans le répertoire `$HOME` (`%USERPROFILE%` dans l'environement natif de Windows) qui est `C:\Documents and Settings\$USER` ou `C:\Users\$USER` la plupart du temps, selon la version (`$USER` devient `%USERNAME%` dans l'environement de Windows).
+Sur les systèmes Windows, Git recherche le fichier `.gitconfig` dans le répertoire `$HOME` (`%USERPROFILE%` dans l’environnement natif de Windows) qui est `C:\Documents and Settings\$USER` ou `C:\Users\$USER` la plupart du temps, selon la version (`$USER` devient `%USERNAME%` dans l’environnement de Windows).
 Il recherche tout de même `/etc/gitconfig`, bien qu'il soit relatif à la racine MSys, qui se trouve où vous aurez décidé d'installer Git sur votre système Windows.
 
 ### Votre identité ###

From 8dda255d5c80d2d6d4e47ae53aceb10f491d5a03 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Wed, 6 Aug 2014 22:36:27 +0200
Subject: [PATCH 550/690] Reviewing chapter name

---
 it/04-git-server/01-chapter4.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/it/04-git-server/01-chapter4.markdown b/it/04-git-server/01-chapter4.markdown
index 4ec820877..55d98c233 100644
--- a/it/04-git-server/01-chapter4.markdown
+++ b/it/04-git-server/01-chapter4.markdown
@@ -111,7 +111,7 @@ Un'altra cosa carina è che l'HTTP è un protocollo comunissimo che i firewall d
 
 L'altra faccia della medaglia nel fornire il tuo repository via HTTP è che è relativamente inefficiente per il client. In genere porta via molto tempo per clonare o scaricare dal repository, e si ha spesso un sovraccarico della rete tramite il trasferimento di volumi via HTTP rispetto ad altri protocolli di rete. Non essendo abbastanza intelligente da trasferire solo i dati di cui hai bisogno — non c'è un lavoro dinamico dalla parte del server in questa transazione — il protocollo HTTP viene spesso definito un protocollo _stupido_. Per maggiori informazioni sulle differenze nell'efficienza tra il protocollo HTTP e gli altri, vedi il Capitolo 9.
 
-## Ottenere Git su di un Server ##
+## Mettere Git su di un server ##
 
 Per inizializzare un qualsiasi server Git, devi esportare un repository esistente in un nuovo repository di soli dati — cioè un repository che non contiene la directory di lavoro. Questo è generalmente molto semplice da fare.
 Per clonare il tuo repository per creare un nuovo repository di soli dati, devi avviare il comando clone con l'opzione `--bare`. Convenzionalmente, un repository di soli dati in finisce in `.git`, ad esempio:

From ff3b6ff0aa032f7d1542a9c9b542fc11697a534a Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Wed, 6 Aug 2014 22:39:08 +0200
Subject: [PATCH 551/690] Rewording sentence

---
 it/04-git-server/01-chapter4.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/it/04-git-server/01-chapter4.markdown b/it/04-git-server/01-chapter4.markdown
index 55d98c233..431538b69 100644
--- a/it/04-git-server/01-chapter4.markdown
+++ b/it/04-git-server/01-chapter4.markdown
@@ -231,7 +231,7 @@ L'autenticazione tramite chiavi SSH generalmente richiede una restrizione dei di
  
  	$ chmod -R go= ~/.ssh
  
-Ora, puoi impostare un repository vuoto avviando `git init` con l'opzione `--bare`, che inizializza il repository senza la directory di lavoro:
+Ora, puoi configurargli un repository vuoto eseguendo `git init` con l'opzione `--bare`, che inizializza il repository senza la directory di lavoro:
 
 	$ cd /opt/git
 	$ mkdir project.git

From bbcc26cd7942d6c45487dc2ffda0af280d9ccb14 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Wed, 6 Aug 2014 22:44:25 +0200
Subject: [PATCH 552/690] Updating chapter6

with changes from PR#805
---
 it/06-git-tools/01-chapter6.markdown | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/it/06-git-tools/01-chapter6.markdown b/it/06-git-tools/01-chapter6.markdown
index 7d684617d..e358907eb 100644
--- a/it/06-git-tools/01-chapter6.markdown
+++ b/it/06-git-tools/01-chapter6.markdown
@@ -708,7 +708,7 @@ Once again, this changes the SHAs of all the commits in your list, so make sure
 
 ### The Nuclear Option: filter-branch ###
 
-There is another history-rewriting option that you can use if you need to rewrite a larger number of commits in some scriptable way — for instance, changing your e-mail address globally or removing a file from every commit. The command is `filter-branch`, and it can rewrite huge swaths of your history, so you probably shouldn’t use it unless your project isn’t yet public and other people haven’t based work off the commits you’re about to rewrite. However, it can be very useful. You’ll learn a few of the common uses so you can get an idea of some of the things it’s capable of.
+There is another history-rewriting option that you can use if you need to rewrite a larger number of commits in some scriptable way — for instance, changing your e-mail address globally or removing a file from every commit.  The command is `filter-branch`, and it can rewrite huge swaths of your history, so you probably shouldn’t use it unless your project isn’t yet public and other people haven’t based work off the commits you’re about to rewrite.  However, it can be very useful. You’ll learn a few of the common uses so you can get an idea of some of the things it’s capable of.
 
 #### Removing a File from Every Commit ####
 
@@ -748,6 +748,12 @@ Another common case is that you forgot to run `git config` to set your name and
 
 This goes through and rewrites every commit to have your new address. Because commits contain the SHA-1 values of their parents, this command changes every commit SHA in your history, not just those that have the matching e-mail address.
 
+### The Very Fast Nuclear Option: Big Friendly Giant Repo Cleaner (BFG) ###
+
+[Roberto Tyley](https://github.com/rtyley) has written a similar tool to `filter-branch` called the BFG. BFG cannot do as much as `filter-branch`, but it is _very_ fast and on a large repository this can make a big difference. If the change you want to make is in the scope of BFG capaility, and you have performance issues, then you should consider using it.
+
+See the [BFG](http://rtyley.github.io/bfg-repo-cleaner/) website for details.
+
 ## Debugging with Git ##
 
 Git also provides a couple of tools to help you debug issues in your projects. Because Git is designed to work with nearly any type of project, these tools are pretty generic, but they can often help you hunt for a bug or culprit when things go wrong.

From 3ca4fdc628b553edab2ff5d3ebca6f26aaa5d97c Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Wed, 6 Aug 2014 22:44:39 +0200
Subject: [PATCH 553/690] Translating changes from PR#805

---
 it/08-git-and-other-scms/01-chapter8.markdown | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/it/08-git-and-other-scms/01-chapter8.markdown b/it/08-git-and-other-scms/01-chapter8.markdown
index 7eb703c2c..2e460254b 100644
--- a/it/08-git-and-other-scms/01-chapter8.markdown
+++ b/it/08-git-and-other-scms/01-chapter8.markdown
@@ -328,6 +328,17 @@ Puoi ottenere le infommazioni disponibili con `svn info` eseguendo `git svn info
 
 Come per `blame` e `log`, le informazioni vengono ricercate offline e sono aggiornate all'ultima volta che si è comunicato con il server Subversion.
 
+Suggerimento: Se il tuo script di compilazione deve poter eseguire `svn info` è meglio porre un wrapper attorno a git.
+Qui c'è un esempio per i tuoi esperimenti:
+
+    #!/usr/bin/env bash
+
+    if git rev-parse --git-dir > /dev/null 2>&1 && [[ $1 == "info" ]] ; then
+      git svn info
+    else 
+      /usr/local/bin/svn "$@"
+    fi
+
 #### Ignorare ciò che Subversion ignora ####
 
 Se cloni un repository Subversion che abbia definito delle proprietà `svn:ignore`, vorrai avere un file `.gitignore` con le stesse proprietà per evitare di committare qualcosa che non dovresti. `git svn` ha due comandi per aiutarti a risolvere questo problema. Il primo, `git svn create-ignore`, crea automaticamente i file `.gitignore`, in modo che la committ successiva li includa.

From b324e3078ca212973fea2e9e11ae03fd75cf0c5e Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Wed, 6 Aug 2014 22:46:41 +0200
Subject: [PATCH 554/690] Translating changes from PR#751

---
 it/07-customizing-git/01-chapter7.markdown | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/it/07-customizing-git/01-chapter7.markdown b/it/07-customizing-git/01-chapter7.markdown
index 78b49f917..c65d63bbf 100644
--- a/it/07-customizing-git/01-chapter7.markdown
+++ b/it/07-customizing-git/01-chapter7.markdown
@@ -534,6 +534,10 @@ Questo è utile se un ramo nel progetto presenta divergenze o è specializzato,
 
 	database.xml merge=ours
 
+Definisci quindi una strategia di merge fittizia chiamata `ours`:
+
+    git config --global merge.ours.driver true
+    
 Nel caso si voglia fare un merge nell'altro ramo, invece di avere conflitti di merge con il file database.xml, si noterà qualcosa di simile a:
 
 	$ git merge topic

From d91bd055343ffec3882c4f988545bc37e2b230b0 Mon Sep 17 00:00:00 2001
From: Ming-Yang Kao <vincent0629@gmail.com>
Date: Thu, 7 Aug 2014 16:50:15 +0800
Subject: [PATCH 555/690] Correct chapter 2 typo

---
 zh-tw/02-git-basics/01-chapter2.markdown | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/zh-tw/02-git-basics/01-chapter2.markdown b/zh-tw/02-git-basics/01-chapter2.markdown
index f637fa8f4..7ffc67937 100644
--- a/zh-tw/02-git-basics/01-chapter2.markdown
+++ b/zh-tw/02-git-basics/01-chapter2.markdown
@@ -30,7 +30,7 @@
 
 	$ git clone git://github.com/schacon/grit.git
 
-接下來會有個名為`grit`的目錄被建立，並在其下初始化名為`.git`的目錄。 拉下所有存在該儲存庫的所有資料，並取出最新版本為工作複本。 若讀者進入新建立的 `grit` 目錄，會看到專案的檔案都在這兒，且可使用。 若讀者想畏複製儲存庫到grit以外其它名字的目錄，只需要在下一個參數指定即可：
+接下來會有個名為`grit`的目錄被建立，並在其下初始化名為`.git`的目錄。 拉下所有存在該儲存庫的所有資料，並取出最新版本為工作複本。 若讀者進入新建立的 `grit` 目錄，會看到專案的檔案都在這兒，且可使用。 若讀者想要複製儲存庫到grit以外其它名字的目錄，只需要在下一個參數指定即可：
 
 	$ git clone git://github.com/schacon/grit.git mygrit
 
@@ -299,7 +299,7 @@ A `**/` pattern is available in Git since version 1.8.2.
 
 ### 提交修改 ###
 
-現在讀者的暫存區域已被更新為讀者想畏的，可開始提交變更的部份。 要記得任何尚未被暫存的新建檔案或已被修改但尚未使用git add暫存的檔案將不會被記錄在本次的提交中。 它們仍會以被修改的檔案的身份存在磁碟中。
+現在讀者的暫存區域已被更新為讀者想要的，可開始提交變更的部份。 要記得任何尚未被暫存的新建檔案或已被修改但尚未使用git add暫存的檔案將不會被記錄在本次的提交中。 它們仍會以被修改的檔案的身份存在磁碟中。
 在這情況下，最後一次執行`git status`，讀者會看到所有已被暫存的檔案，讀者也準備好要提交修改。 最簡單的提交是執行`git commit`：
 
 	$ git commit
@@ -391,7 +391,7 @@ A `**/` pattern is available in Git since version 1.8.2.
 
 	$ git rm log/\*.log
 
-注意倒斜線（`\`）前方的星號（`*`）。 這是必須的，因為Git會在shell以上執行檔案的擴展。 此命令移除log目錄下所有檔名以`.log`結尾的檔案。 讀者也可以執行類似下列命令：
+注意星號（`*`）前方的倒斜線（`\`）。 這是必須的，因為Git會在shell以上執行檔案的擴展。 此命令移除log目錄下所有檔名以`.log`結尾的檔案。 讀者也可以執行類似下列命令：
 
 	$ git rm \*~
 
@@ -519,7 +519,7 @@ Git會在背後判斷檔案是否被更名，因此不管是用上述方法還
 	    s.version   =   [-"0.1.0"-]{+"0.1.1"+}
 	    s.author    =   "Scott Chacon"
 
-如你所見，輸出範例中沒有列出新增與刪除的行，變動的地方用內嵌的方式顯示，你可以看到新增的字被包括在 `{+ +}` 內，而刪除的則包括在 `{- -}` 內，如果你想再減少顯示的資訊，將上述的三行再減少到只顯示變動的那行。你可以用 `-U1` 選項，就像上述的範例中那樣。
+如你所見，輸出範例中沒有列出新增與刪除的行，變動的地方用內嵌的方式顯示，你可以看到新增的字被包括在 `{+ +}` 內，而刪除的則包括在 `[- -]` 內，如果你想再減少顯示的資訊，將上述的三行再減少到只顯示變動的那行。你可以用 `-U1` 選項，就像上述的範例中那樣。
 
 另外也可以使用`git log`提供的一系統摘要選項。 例如：若想檢視每個更新的簡略統計資訊，可使用 `--stat` 選項：
 

From 6f07d8c0637386c56325adb64852f5399cc9ed9f Mon Sep 17 00:00:00 2001
From: msxiyev <msxiyev@gmail.com>
Date: Thu, 7 Aug 2014 18:34:45 +0300
Subject: [PATCH 556/690] updated 01-chapter1.markdown {1 & 2 paragraphs}

---
 az/01-introduction/01-chapter1.markdown | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/az/01-introduction/01-chapter1.markdown b/az/01-introduction/01-chapter1.markdown
index baa828d98..30e626bdd 100644
--- a/az/01-introduction/01-chapter1.markdown
+++ b/az/01-introduction/01-chapter1.markdown
@@ -1,12 +1,12 @@
 # Başlanğıc #
 
-Bu bölmə size git haqqında başlıca məlumatları çattırmağı hədəfləyir.  We will begin at the beginning by explaining some background on version control tools, then move on to how to get Git running on your system and finally how to get it setup to start working with.  At the end of this chapter you should understand why Git is around, why you should use it and you should be all setup to do so.
+Bu bölmə size git haqqında başlıca məlumatları çattırmağı hədəfləyir. İşə başlamazdan əvvəl version nəzarət vasitəsinin bəzi fon məlumatlarını açıqlayaraq başlayacağıq, daha sonra Git quraşdırılmanının necə ediləcəyini, ən son olaraq da vasitənin konfiqurasiya və istifadəsini açıqlayacağıq. Bu hissənin sonunda Git'in varlıq səbəbini və niyə onu istifadə etməniz lazım olduğunu anlayacaq, Git'i istifadə etmeye başlamaq üçün quraşdırma bitirmiş olacaqsınız. 
 
-## About Version Control ##
+## Versiya Nəzarət Haqqında ##
 
-What is version control, and why should you care? Version control is a system that records changes to a file or set of files over time so that you can recall specific versions later. Even though the examples in this book show software source code as the files under version control, in reality any type of file on a computer can be placed under version control.
+Versiya nəzarəti nədir və nə işə yarayar? Versiya nəzarəti, Bir ya da daha çox fayl üzərində edilən dəyişiklikləri yazan və daha sonra müəyyən bir distributivə geri dönə bilmənizi təmin edən bir sistemdir. Bu kitabdakı nümunələrdə proqram qaynaq kod fayllarının versiya idarəsini edəcəksiniz, nə var ki, əslində versiyası idarəsini demək olar ki hər növdən fayl üçün istifadə edə bilərsiniz.
 
-If you are a graphic or web designer and want to keep every version of an image or layout (which you certainly would), it is very wise to use a Version Control System (VCS). A VCS allows you to: revert files back to a previous state, revert the entire project back to a previous state, compare changes over time, see who last modified something that might be causing a problem, who introduced an issue and when, and more. Using a VCS also means that if you screw things up or lose files, you can generally recover easily. In addition, you get all this for very little overhead.
+Bir grafik və ya web dizayn tək və bir vizual və ya dizaynın dəyişik versiyalarını qorumaq istəyirsinizsə (ki ehtimalla bunu etmək istəyərsiniz), bir Versiya Kontrol Sistemi (VKS) istifadə etməniz çox ağıllıca olacaq. VKS, faylların və ya bütün layihənin keçmişdəki müəyyən bir versiyaya daxil olmağa, zaman içində edilən dəyişiklikləri müqayisə etməyinizi, problemə səbəb olan şeydə ən son kimin dəyişiklik etdiyini, müəyyən bir səhvi kimin, nə vaxt sistemə daxil etdiyini və daha başqa bir çox şeyi görə bilməyinizi təmin edər. Digər tərəfdən, VKS istifadə etmək, bir səhv etdikdə və ya bəzi faylları səhvən sildiyiniz də vəziyyəti asanlıqla kompensasiya etmənizə köməkçi olar. Üstəlik, bütün bunlar sizə əhəmiyyətli bir əlavə yük də gətirməz.
 
 ### Local Version Control Systems ###
 

From b9aba77271c076d8164d636fea369b8d2304de1c Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Thu, 7 Aug 2014 16:52:37 +0200
Subject: [PATCH 557/690] Translating titles

---
 it/07-customizing-git/01-chapter7.markdown | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/it/07-customizing-git/01-chapter7.markdown b/it/07-customizing-git/01-chapter7.markdown
index c65d63bbf..558645d79 100644
--- a/it/07-customizing-git/01-chapter7.markdown
+++ b/it/07-customizing-git/01-chapter7.markdown
@@ -526,7 +526,7 @@ All'esecuzione di `git archive`, il contenuto del file quando qualcuno aprirà l
 	$ cat LAST_COMMIT
 	Last commit date: $Format:Tue Apr 21 08:38:48 2009 -0700$
 
-### Merge Strategies ###
+### Strategie di merge ###
 
 È possibile inoltre utilizzare attributi Git per comunicare a Git di utilizzare differenti strategie di merge per files specifici nel progetto. Un opzione molto utile è comunicare a Git di non provare ad eseguire merge di files specifici quando sussistono conflitti, ma, invece, di la propria parte di merge sopra quella di qualcun altro.
 
@@ -556,11 +556,11 @@ Gli hooks sono salvati nella sottodirectory `hooks` all'interno della directory
 
 Per abilitare uno script hook, bisogna inserire il file nella sottodirectory `hooks` della directory Git, il file dovrà essere nominato in modo appropriato ed eseguibile. Da questo punto in poi dovrebbe essere chiamato. Vedremo ora i principali nomi di hook.
 
-### Hooks Lato Client ###
+### Hook sul client ###
 
 Esistono molti hooks lato client. In questa sezione li divideremo in committing-workflow hooks, e-mail-workflow scripts, ed i restanti client-side scripts.
 
-#### Committing-Workflow Hooks ####
+#### Hook per le commit ####
 
 I primi quattro hooks sono correlati con il processo di commit. L'hook `pre-commit` è eseguito per primo, prima che venga richiesto l'inserimento del messaggio di commit. È usato per controllare lo snapshot di cui si vuole eseguire il commit, per vedere se ci si è dimenticati di qualcosa, per assicurarsi che i test funzionino, o per esaminare qualsiasi cosa si voglia nel codice. Se il valore di uscita di questo hook è un non-zero il commit viene annullato, in alternativa può essere bypassato tramite il comando `git commit --no-veriy`. È possibile eseguire operazioni come controllare lo stile del codice (eseguendo lint o qualcosa di simile), cercare whitespace alla fine (l'hook di default fa esattamente questo), cercare documentazione appropriata su nuovi metodi.
 
@@ -572,7 +572,7 @@ Al termine dell'intero processo di commit, viene eseguito l'hook `post-commit`.
 
 Gli script client-side per il committing-workflow possono essere utilizzati in ogni flusso di lavoro. Sono spesso utilizzati per rafforzare alcune norme, è comunque importante notare che questi scripts non sono trasferiti durante un clone. È possibile rafforzare le norme lato server per rifiutare push di commits che non siano conformi a qualche norma, ma è responsabilità dello sviluppatore utilizzare questi script lato client. Quindi, questi sono scripts che aiutano gli sviluppatori, devono essere impostati e mantenuti da loro, possono essere modificati o sovrascritti da loro in ogni momento.
 
-#### E-mail Workflow Hooks ####
+#### Hook per le e-mail ####
 
 È possibile impostare tre hooks lato client per un flusso di lavoro basato sulle e-mail. Sono tutti invocati dal comando `git am`, quindi se non si utilizza il detto comando, questa sezione può essere tranquillamente saltata. Se si prendono patches via e-mail preparate tramite `git format-patch`, allora alcuni di questi hooks potrebbero risultare utili.
 
@@ -582,7 +582,7 @@ Il prossimo hook che viene eseguito è `pre-applypatch`. Non riceve argomenti e
 
 L'ultimo hook che viene eseguito è `post-applypatch`. È possibile utilizzarlo per notificare ad un gruppo o all'autore della patch che è stato eseguito il pull nel quale si è lavorato. È possibile fermare il patching tramite questo script.
 
-#### Altri Client Hooks ####
+#### Altri hook sul client ####
 
 L'hook `pre-rebase` viene eseguito prima di un rebase e può fermare il processo ritornando un non-zero. È possibile utilizzare questo hook per negare il rebasing di qualsiasi commit di cui sia stato già effettuato un push. Lo script `pre-rebase` di esempio esegue quanto detto, in alternativa assume che next sia il nome del branch che si vuole pubblicare. Dovresti cambiarlo nel branch stabile.
 
@@ -591,7 +591,7 @@ Dopo aver eseguito con successp `git checkout`, viene eseguito l'hook `post-chec
 
 Infine, l'hook `post-merge` viene eseguito dopo un comando `merge` terminato con successo. È possibile utilizzarlo per ripristinare informazioni dell'albero che Git non riesce a tracciare (come informazioni di permessi). Questo hook può allo stesso modo validare la presenza di files esterni al controllo di Git che potresti voler copiare all'interno quando l'albero di lavoro cambia.
 
-### Hooks Lato Server ###
+### Hook sul server ###
 
 In aggiunta agli hooks lato client, è possibile utilizzare un paio di hooks lato server come amministrazione di sistema per rafforzare praticamente ogni tipo di norma per il progetto. Questi scripts vengono eseguiti prima e dopo i push verso il server. I pre hooks possono ritornare non-zero in ogni momento per rifiutare il push inviando un messaggio di errore al client; è possibile configurare una politica di push che sia complessa quanto si desidera.
 

From c3fc6451ce72344bb31507d35d366ab421b23d6d Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Thu, 7 Aug 2014 16:55:57 +0200
Subject: [PATCH 558/690] Translating chapter #7

---
 it/07-customizing-git/01-chapter7.markdown | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/it/07-customizing-git/01-chapter7.markdown b/it/07-customizing-git/01-chapter7.markdown
index 558645d79..32662445b 100644
--- a/it/07-customizing-git/01-chapter7.markdown
+++ b/it/07-customizing-git/01-chapter7.markdown
@@ -1,6 +1,6 @@
-	# Customizing Git #
+# Personalizzare Git #
 
-Finora abbiamo quindi coperto le basi di come Git funzioni e come usarlo, abbiamo introdotto un numero di strumenti che Git fornisce per aiutarti ad utilizzarlo al meglio ed in modo efficiente. In questo capitolo spiegherò alcune delle operazioni che possono essere utilizzate per personalizzare il comportamento di Git introducendo molti settaggi ed il Hooks System. Tramite questi strumenti, è semplice fare in modo che Git lavori nel modo che tu, la tua azienda, o il tuo gruppo desiderate.
+Finora abbiamo viso le basi di come Git e come usarlo, abbiamo introdotto alcuni strumenti forniti da Git per aiutarti a usarlo al meglio ed efficientemente. In questo capitolo vedremo alcune operazioni che possono essere utilizzate per personalizzare il comportamento di Git, introducendo molte impostazione e il sistema degli `hook`. Tramite questi strumenti sarà semplice fare in modo che Git lavori come tu, la tua azienda, o il tuo gruppo desideriate.
 
 ## Configurazione di Git ##
 

From 9858222d083a803f993fb79a192b8d34e7180e6d Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Thu, 7 Aug 2014 17:09:46 +0200
Subject: [PATCH 559/690] Fixing translation for "Git Configuration"

---
 it/07-customizing-git/01-chapter7.markdown | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/it/07-customizing-git/01-chapter7.markdown b/it/07-customizing-git/01-chapter7.markdown
index 32662445b..b834aa454 100644
--- a/it/07-customizing-git/01-chapter7.markdown
+++ b/it/07-customizing-git/01-chapter7.markdown
@@ -4,18 +4,18 @@ Finora abbiamo viso le basi di come Git e come usarlo, abbiamo introdotto alcuni
 
 ## Configurazione di Git ##
 
-Come hai visto brevemente nel capitolo 1, si possono specificare delle impostazioni per Git tramite il comando `git config`. Una delle prime cose che hai fatto è stato impostare il tuo nome ed il tuo indirizzo e-mail:
+Come abbiamo visto brevemente nel capitolo 1, è possibile configurare Git con il comando `git config`. Una delle prime cose che abbiamo fatto è stato definire il nostro nome e il nostro indirizzo e-mail:
 
 	$ git config --global user.name "John Doe"
 	$ git config --global user.email johndoe@example.com
 
-Ora imparerai alcune delle opzioni più interessanti che si possono impostare in questa maniera per personalizzare l'utilizzo di Git.
+Ora vedremo alcune delle opzioni più interessanti che puoi configurare allo stesso modo, per personalizzare il modo in cui usi Git.
 
-Hai visto alcuni semplici dettagli di configurazione nel primo capitolo, ora li esamineremo ancora velocemente. Git utilizza una serie di files di configurazione per determinare comportamenti non standard che potresti desiderare. In primo luogo Git cercherà questi valori nel file `/etc/gitconfig`, il quale contiene valori per ogni utente e repository di sua proprietà presenti sul sitema. Se si passa l'opzione `--system` a `git config`, il programma leggerà e scriverà in modo specifico su questo file.
+Nel primo capitolo hai visto alcuni dettagli per delle configurazioni semplici, ora li rivedremo velocemente. Git usa più file di configurazione per decidere cosa fare in situazioni non standard. Il primo di questi, dove Git cercherà, è `/etc/gitconfig`, che contiene la configurazione per tutti gli utenti del sistema e dei loro repository. Git legge e scrive su questo file quando usi l'opzione `--system` con `git config`.
 
-Successivamente Git controlla il file `~/.gitconfig`, che è specifico per ogni utente. Puoi fare in modo che Git legga e scriva su questo file utilizzando l'opzione `--global`.
+Il file successivo dove Git va a cercare è `~/.gitconfig`, che è specifico per ogni utente. Puoi fare in modo che Git legga e scriva su questo file con l'opzione `--global`.
 
-Infine, Git controlla i valori di configurazione nel file di configurazione presente nella directory Git (`.git/config`) di qualsiasi repository che stai utilizzando. Questi valori sono specifici del singolo repository. Ongi livello sovrascrive i valori del livello precedente, per esempio i valori in `.git/config` battono quelli in `/etc/gitconfig`. Si può inoltre impostare questi valori modificando manualmente il file ed inserendo la corretta sintassi, tuttavia solitamente è più semplice eseguire il comando `git config`.
+Infine Git controlla le impostazioni nel file di configurazione presente nella directory Git (`.git/config`) di qualsiasi repository che tu stia utilizzando. Queste impostazioni sono specifiche di quel singolo repository. Ogni livello sovrascrive i valori del livello precedente, quindi i valori in `.git/config` battono quelli in `/etc/gitconfig`. Puoi configurare queste impostazioni anche editando manualmente il file, usando la sintassi corretta, ma solitamente è più semplice eseguire il comando `git config`.
 
 ### Configurazione Base del Client ###
 

From d446e333acda216cae0613195383dc4902873324 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Thu, 7 Aug 2014 17:13:51 +0200
Subject: [PATCH 560/690] Updating "Basic Client Configuration"

---
 it/07-customizing-git/01-chapter7.markdown | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/it/07-customizing-git/01-chapter7.markdown b/it/07-customizing-git/01-chapter7.markdown
index b834aa454..e85dc11de 100644
--- a/it/07-customizing-git/01-chapter7.markdown
+++ b/it/07-customizing-git/01-chapter7.markdown
@@ -17,9 +17,9 @@ Il file successivo dove Git va a cercare è `~/.gitconfig`, che è specifico per
 
 Infine Git controlla le impostazioni nel file di configurazione presente nella directory Git (`.git/config`) di qualsiasi repository che tu stia utilizzando. Queste impostazioni sono specifiche di quel singolo repository. Ogni livello sovrascrive i valori del livello precedente, quindi i valori in `.git/config` battono quelli in `/etc/gitconfig`. Puoi configurare queste impostazioni anche editando manualmente il file, usando la sintassi corretta, ma solitamente è più semplice eseguire il comando `git config`.
 
-### Configurazione Base del Client ###
+### Configurazione minima del client ###
 
-Le opzioni di configurazione riconosciute da Git si suddividono in due categorie: client-side e server-side. La maggioranza delle opzioni sono client-side—impostando le tue personali preferenze. Sono comunque disponibili molte opzioni, ne copriremo solo alcune che sono solitamente utilizzate o possono personalizzare il tuo ambiente di lavoro in modo significativo. Molte opzioni sono utili solo in casi limite che non esamineremo in questa sede. Nel caso tu voglia vedere una lista di tutte le opzioni che la tua versione di Git riconosce puoi eseguire il comando
+Le opzioni di configurazione riconosciute da Git si suddividono in due categorie: `client-side` e `server-side`. La maggioranza delle opzioni sono client-side perché definiscono le tue preferenze personali. Sebbene siano disponibili moltissime opzioni, vedremo solo le poche che sono utilizzate spesso o che possono influenzare significativamente il tuo ambiente di lavoro. Molte opzioni sono utili solo in casi estremi che quindi non esamineremo in questa sede. Se vuoi vedere l'elenco di tutte le opzioni disponibili in Git, puoi eseguire il comando
 
 	$ git config --help
 

From 21c6b25f3c44cc933c209ab4eb34f1f6c0f9b210 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Thu, 7 Aug 2014 17:16:30 +0200
Subject: [PATCH 561/690] Updating "core.editor"

---
 it/07-customizing-git/01-chapter7.markdown | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/it/07-customizing-git/01-chapter7.markdown b/it/07-customizing-git/01-chapter7.markdown
index e85dc11de..f8f244185 100644
--- a/it/07-customizing-git/01-chapter7.markdown
+++ b/it/07-customizing-git/01-chapter7.markdown
@@ -27,11 +27,11 @@ La pagina del manuale per `git config` elenca tutte le opzioni disponibili aggiu
 
 #### core.editor ####
 
-Di default, Git utilizza qualsiasi programma che tu abbia impostato come text editor, in alternativa sceglie l'editor Vi per creare e modificare commit tag e messaggi. Per cambiare l'impostazione standard, puoi utilizzare l'impostazione `core.editor`:
+Di default, Git utilizza qualsiasi programma tu abbia impostato come text editor o, in mancanza, sceglie l'editor Vi per creare e modificare i messaggi delle commit e dei tag. Per cambiare l'impostazione standard, puoi configurare il `core.editor`:
 
 	$ git config --global core.editor emacs
 
-Ora, non importa quale sia la variabile shell per l'editor, Git utilizzerà Emacs per modificare i messaggi.
+Facendo così non importa quale sia l'editor predefinito configurato per la tua shell, Git lancerà sempre Emacs per modificare i messaggi.
 
 #### commit.template ####
 

From 43533f1b29f0d2a8e1b4d5678652ff8fb43a5c4a Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Thu, 7 Aug 2014 17:24:33 +0200
Subject: [PATCH 562/690] Updating "commit.template"

---
 it/07-customizing-git/01-chapter7.markdown | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/it/07-customizing-git/01-chapter7.markdown b/it/07-customizing-git/01-chapter7.markdown
index f8f244185..e6d0d2345 100644
--- a/it/07-customizing-git/01-chapter7.markdown
+++ b/it/07-customizing-git/01-chapter7.markdown
@@ -35,24 +35,24 @@ Facendo così non importa quale sia l'editor predefinito configurato per la tua
 
 #### commit.template ####
 
-Se impostato verso il percorso di un file, Git utilizzerà questo file come messaggio di default per i tuoi commit. Ad esempio, supponiamo che tu abbia creato un file di template in `$HOME/.gitmessage.txt` in questo modo:
+Se come valore per questo parametro definisci il percorso di un file, Git utilizzerà quel file come modello per i tuoi messaggio quando committi. Supponiamo per esempio che tu abbia creato il seguente modello in `$HOME/.gitmessage.txt`:
 
-	subject line
+	oggetto
 
-	what happened
+	cos'è successo: giustifica la tua commit
 
 	[ticket: X]
 
-Per comunicare a Git di utilizzare come messaggio di default il messaggio che compare nell'editor quando viene eseguito `git commit`, imposta il valore `commit.template` in questo modo:
+Per comunicare a Git di usare sempre questo messaggio nel tuo editor quando esegui `git commit`, configura `commit.template` in questo modo:
 
 	$ git config --global commit.template $HOME/.gitmessage.txt
 	$ git commit
 
-Il tuo editor si aprirà quindi in un modo simile a questo per la tua variabile metasintattica del messaggio di commit, ad ogni tuo commit:
+Quando committi, il tuo editor si aprirà con un contenuto simile al seguente, perché tu scriva il tuo messaggio:
 
-	subject line
+	oggetto
 
-	what happened
+	cos'è successo: giustifica la tua commit
 
 	[ticket: X]
 	# Please enter the commit message for your changes. Lines starting
@@ -67,7 +67,7 @@ Il tuo editor si aprirà quindi in un modo simile a questo per la tua variabile
 	~
 	".git/COMMIT_EDITMSG" 14L, 297C
 
-Nel caso tu abbia una norma per il messaggio di commit, allora inserire un template per quella norma sul tuo sistema e configurare Git per utilizzarla di default può aiutare ad aumentare le possibilità che quella norma venga seguita regolarmente.
+Nel caso tu abbia una sintassi standard da seguire per i messaggi di commit, configurare Git perché usi un modello può aumentare le possibilità che quello standard venga rispettato.
 
 #### core.pager ####
 

From 01455c4aea87e3a9142eae1c1a767c13b6d8b510 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Thu, 7 Aug 2014 17:28:05 +0200
Subject: [PATCH 563/690] Updating "core.pager"

---
 it/07-customizing-git/01-chapter7.markdown | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/it/07-customizing-git/01-chapter7.markdown b/it/07-customizing-git/01-chapter7.markdown
index e6d0d2345..93dff862d 100644
--- a/it/07-customizing-git/01-chapter7.markdown
+++ b/it/07-customizing-git/01-chapter7.markdown
@@ -71,11 +71,11 @@ Nel caso tu abbia una sintassi standard da seguire per i messaggi di commit, con
 
 #### core.pager ####
 
-L'impostazione core.pager determina quale pager venga utilizzato quando Git pagina l'output come `log` e `diff`. Puoi impostarlo a `more` o al tuo pager preferito (di default è `less`), in alternativa puoi disattivarlo impostandolo ad una stringa vuota:
+L'impostazione core.pager determina quale applicazione debba essere usata da Git quando pagina output lunghi come `log` e `diff`. Puoi impostarlo a `more` o alla tua applicazione preferita (predefinito è `less`), o puoi anche disattivarlo impostandolo a una stringa vuota:
 
 	$ git config --global core.pager ''
 
-Nel caso tu lo esegua, Git paginerà l'output di ogni comando, non importa quanto esso sia lungo.
+Se eseguissi questo comando, Git paginerà l'intero output di qualsiasi comando, non importa quanto esso sia lungo.
 
 #### user.signingkey ####
 

From 5cfd28996aac9a05ffbbf0ab5c75abdf64c0557b Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Thu, 7 Aug 2014 17:29:57 +0200
Subject: [PATCH 564/690] Updating "user.signingkey"

---
 it/07-customizing-git/01-chapter7.markdown | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/it/07-customizing-git/01-chapter7.markdown b/it/07-customizing-git/01-chapter7.markdown
index 93dff862d..2e9d86514 100644
--- a/it/07-customizing-git/01-chapter7.markdown
+++ b/it/07-customizing-git/01-chapter7.markdown
@@ -79,11 +79,11 @@ Se eseguissi questo comando, Git paginerà l'intero output di qualsiasi comando,
 
 #### user.signingkey ####
 
-Nel caso tu voglia firmare i tags (come discusso nel Capitolo 2), impostare la tua chiave GPG nelle impostazioni rende le cose più semplici. Imposta l'ID della tua chiave in questo modo:
+Nel caso utilizzi tag firmati (come descritto nel capitolo 2), definire la tua chiave GPG nelle impostazioni rende le cose più semplici. Imposta l'ID della tua chiave in questo modo:
 
 	$ git config --global user.signingkey <gpg-key-id>
 
-Ora, puoi firmare i tags senza dover specificare la tua chiave ogni volta con il comando `git tag`:
+Ora, puoi firmare i tags, senza dover specificare ogni volta la tua chiave, con il comando `git tag`:
 
 	$ git tag -s <tag-name>
 

From 163ed76670e6e3d209fc92423c2bc9dd946c036f Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Thu, 7 Aug 2014 17:33:36 +0200
Subject: [PATCH 565/690] Updating "user.signingkey"

---
 it/07-customizing-git/01-chapter7.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/it/07-customizing-git/01-chapter7.markdown b/it/07-customizing-git/01-chapter7.markdown
index 2e9d86514..665590518 100644
--- a/it/07-customizing-git/01-chapter7.markdown
+++ b/it/07-customizing-git/01-chapter7.markdown
@@ -89,7 +89,7 @@ Ora, puoi firmare i tags, senza dover specificare ogni volta la tua chiave, con
 
 #### core.excludesfile ####
 
-Puoi inserire patterns nel file `.gitignore` del tuo progetto per fare in modo che Git non li veda come untracked files o provi a farne uno stage all'esecuzione del comando `git add` su di loro, come visto nel Capitolo 2. Comunque, se vuoi che un altro file all'esterno del tuo progetto gestisca questi valori o abbia valori extra, puoi informare Git della posizione del file tramite il parametro `core.excludesfile`. Impostalo semplicemente sul percorso del file che ha un contenuto simile a quello che avrebbe un file `.gitignore`.
+Puoi inserire dei modelli nel file `.gitignore` del tuo progetto per fare in modo che Git non li veda come file non tracciati o provi a metterli nell'area di stage quando esegui `git add`, come visto nel capitolo 2. Se però vuoi che un altro file, all'esterno del tuo progetto, gestisca queste esclusioni o vuoi definire valori addizionali, puoi dire a Git dove si trovi quel file con `core.excludesfile`. Ti basta specificare il percorso del file che abbia un contenuto simile a quello che avrebbe il `.gitignore`.
 
 #### help.autocorrect ####
 

From a2c680a2bbe1a3fd7253c17d3ed42e70052c50b9 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Thu, 7 Aug 2014 17:35:39 +0200
Subject: [PATCH 566/690] Updating "help.autocorrect"

---
 it/07-customizing-git/01-chapter7.markdown | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/it/07-customizing-git/01-chapter7.markdown b/it/07-customizing-git/01-chapter7.markdown
index 665590518..584005247 100644
--- a/it/07-customizing-git/01-chapter7.markdown
+++ b/it/07-customizing-git/01-chapter7.markdown
@@ -93,7 +93,7 @@ Puoi inserire dei modelli nel file `.gitignore` del tuo progetto per fare in mod
 
 #### help.autocorrect ####
 
-Questa opzione è disponibile solo in Git 1.6.1 e successivi. Se digiti in modo errato un comando in Git 1.6, ti mostrerà qualcosa del genere:
+Questa opzione è disponibile solo da Git 1.6.1 in poi. Se digiti male un comando in Git, otterrai qualcosa del genere:
 
 	$ git com
 	git: 'com' is not a git-command. See 'git --help'.
@@ -101,7 +101,7 @@ Questa opzione è disponibile solo in Git 1.6.1 e successivi. Se digiti in modo
 	Did you mean this?
 	     commit
 
-Se imposti `help.autocorrect` a 1, Git automaticamente eseguirà il comando nel caso in cui corrisponda ad un solo match.
+Se imposti `help.autocorrect` a 1, Git eseguirà automaticamente il comando nel caso esista un'unica corrispondenza.
 
 ### Colors in Git ###
 

From de5632929eaecff64f5cf9a38b75570978bf3250 Mon Sep 17 00:00:00 2001
From: Petr Prikryl <prikryl@atlas.cz>
Date: Fri, 8 Aug 2014 00:35:26 +0200
Subject: [PATCH 567/690] [cs] fixed translation in ch. 3, reflecting new
 things in ch. 4

---
 cs/03-git-branching/01-chapter3.markdown | 2 +-
 cs/04-git-server/01-chapter4.markdown    | 4 ++++
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/cs/03-git-branching/01-chapter3.markdown b/cs/03-git-branching/01-chapter3.markdown
index 5d486f281..2c0701fef 100644
--- a/cs/03-git-branching/01-chapter3.markdown
+++ b/cs/03-git-branching/01-chapter3.markdown
@@ -2,7 +2,7 @@
 
 Téměř každý systém pro správu verzí podporuje do určité míry větvení. Větvení znamená, že se můžete odloučit od hlavní linie vývoje a pokračovat v práci, aniž byste hlavní linii zanášeli smetím. V mnoha VCS nástrojích se může jednat o poněkud náročný proces, který často vyžaduje vytvoření nové kopie adresáře se zdrojovým kódem. To může – zvláště u velkých projektů – trvat poměrně dlouho.
 
-Někteří lidé mluví o modelu větvení v systému Git jako o jeho „vražedné vlastnosti“. Není sporu o tom, že je Git díky tomu ve skupině systémů pro správu verzí poměrně jedinečný. V čem je jeho větvení tak zvláštní? Větvení je v systému Git neuvěřitelně snadné a operace s ním související probíhají téměř okamžitě. A stejně rychlé je i přepínání mezi jednotlivými větvemi. Na rozdíl od ostatních systémů pro správu verzí vybízí Git ke způsobu práce s bohatým větvením a častým slučováním, a to i několikrát za den. Pokud tuto funkci pochopíte a zvládnete její ovládání, dostanete do ruky výkonný a unikátní nástroj, který doslova změní váš pohled na vývoj.
+Někteří lidé mluví o modelu větvení v systému Git jako o jeho „omračující vlastnosti“. Není sporu o tom, že je Git díky tomu ve skupině systémů pro správu verzí poměrně jedinečný. V čem je jeho větvení tak zvláštní? Větvení je v systému Git neuvěřitelně snadné a operace s ním související probíhají téměř okamžitě. A stejně rychlé je i přepínání mezi jednotlivými větvemi. Na rozdíl od ostatních systémů pro správu verzí vybízí Git ke způsobu práce s bohatým větvením a častým slučováním, a to i několikrát za den. Pokud tuto funkci pochopíte a zvládnete její ovládání, dostanete do ruky výkonný a unikátní nástroj, který doslova změní váš pohled na vývoj.
 
 ## Co je to větev ##
 
diff --git a/cs/04-git-server/01-chapter4.markdown b/cs/04-git-server/01-chapter4.markdown
index 5e4d1a27c..d3b0c44b7 100644
--- a/cs/04-git-server/01-chapter4.markdown
+++ b/cs/04-git-server/01-chapter4.markdown
@@ -227,6 +227,10 @@ Vy nyní klíče vložíte do souboru `authorized_keys`:
 	$ cat /tmp/id_rsa.josie.pub >> ~/.ssh/authorized_keys
 	$ cat /tmp/id_rsa.jessica.pub >> ~/.ssh/authorized_keys
 
+Autentizace vůči SSH, která je založená na klíči, obvykle vynucuje zvýšenou bezpečnost tím, že pro zúčastněné soubory vyžaduje omezená oprávnění. Aby SSH neodmítl pracovat, napište následující:
+
+	$ chmod -R go= ~/.ssh
+
 Nyní pro ně můžete nastavit prázdný repozitář. Spusťte příkaz `git init` s parametrem `--bare`, který inicializuje repozitář bez pracovního adresáře:
 
 	$ cd /opt/git

From 9579cf8722b0d6449c75644b2cfddf1962307fad Mon Sep 17 00:00:00 2001
From: Choongmin Lee <choongmin@me.com>
Date: Fri, 8 Aug 2014 16:20:12 +0900
Subject: [PATCH 568/690] [ko] rename README to README.md

---
 ko/{README => README.md} | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 rename ko/{README => README.md} (100%)

diff --git a/ko/README b/ko/README.md
similarity index 100%
rename from ko/README
rename to ko/README.md

From b371a70485c7a1eae2a3485aeebc3ad5bc34e92b Mon Sep 17 00:00:00 2001
From: msxiyev <msxiyev@gmail.com>
Date: Fri, 8 Aug 2014 13:44:45 +0300
Subject: [PATCH 569/690] =?UTF-8?q?3=20abzas=20terc=C3=BCmesi=20edildi=20{?=
 =?UTF-8?q?LVNS,=20MVNS,=20PVNS=20}=20:pencil2:?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 az/01-introduction/01-chapter1.markdown | 30 ++++++++++++-------------
 1 file changed, 15 insertions(+), 15 deletions(-)

diff --git a/az/01-introduction/01-chapter1.markdown b/az/01-introduction/01-chapter1.markdown
index 30e626bdd..d2cea2626 100644
--- a/az/01-introduction/01-chapter1.markdown
+++ b/az/01-introduction/01-chapter1.markdown
@@ -6,38 +6,38 @@ Bu bölmə size git haqqında başlıca məlumatları çattırmağı hədəfləy
 
 Versiya nəzarəti nədir və nə işə yarayar? Versiya nəzarəti, Bir ya da daha çox fayl üzərində edilən dəyişiklikləri yazan və daha sonra müəyyən bir distributivə geri dönə bilmənizi təmin edən bir sistemdir. Bu kitabdakı nümunələrdə proqram qaynaq kod fayllarının versiya idarəsini edəcəksiniz, nə var ki, əslində versiyası idarəsini demək olar ki hər növdən fayl üçün istifadə edə bilərsiniz.
 
-Bir grafik və ya web dizayn tək və bir vizual və ya dizaynın dəyişik versiyalarını qorumaq istəyirsinizsə (ki ehtimalla bunu etmək istəyərsiniz), bir Versiya Kontrol Sistemi (VKS) istifadə etməniz çox ağıllıca olacaq. VKS, faylların və ya bütün layihənin keçmişdəki müəyyən bir versiyaya daxil olmağa, zaman içində edilən dəyişiklikləri müqayisə etməyinizi, problemə səbəb olan şeydə ən son kimin dəyişiklik etdiyini, müəyyən bir səhvi kimin, nə vaxt sistemə daxil etdiyini və daha başqa bir çox şeyi görə bilməyinizi təmin edər. Digər tərəfdən, VKS istifadə etmək, bir səhv etdikdə və ya bəzi faylları səhvən sildiyiniz də vəziyyəti asanlıqla kompensasiya etmənizə köməkçi olar. Üstəlik, bütün bunlar sizə əhəmiyyətli bir əlavə yük də gətirməz.
+Bir grafik və ya web dizayn tək və bir vizual və ya dizaynın dəyişik versiyalarını qorumaq istəyirsinizsə (ki ehtimalla bunu etmək istəyərsiniz), bir Versiya Nəzarət Sistemi (VNS) istifadə etməniz çox ağıllıca olacaq. VNS, faylların və ya bütün layihənin keçmişdəki müəyyən bir versiyaya daxil olmağa, zaman içində edilən dəyişiklikləri müqayisə etməyinizi, problemə səbəb olan şeydə ən son kimin dəyişiklik etdiyini, müəyyən bir səhvi kimin, nə vaxt sistemə daxil etdiyini və daha başqa bir çox şeyi görə bilməyinizi təmin edər. Digər tərəfdən, VNS istifadə etmək, bir səhv etdikdə və ya bəzi faylları səhvən sildiyiniz də vəziyyəti asanlıqla kompensasiya etmənizə köməkçi olar. Üstəlik, bütün bunlar sizə əhəmiyyətli bir əlavə yük də gətirməz.
 
-### Local Version Control Systems ###
+### Lokal Sürüm Nəzarət Sistemləri ###
 
-Many people’s version-control method of choice is to copy files into another directory (perhaps a time-stamped directory, if they’re clever). This approach is very common because it is so simple, but it is also incredibly error prone. It is easy to forget which directory you’re in and accidentally write to the wrong file or copy over files you don’t mean to.
+Əksəriyyəti faylları bir qovluğa (ağılları başlarındaysa tarix və zaman məlumatını də daxil olmaqla bir qovluğa) kopiyalayaraq versiyas nəzarətini etməyi seçər. Bu yanaşma çox məşhurdur, çünki çox asandır; amma eyni zamanda səhvlərə də ala bildiyinə açıqdır. Hansı qovluqda olduğunuzu unudub səhv fayla yaza ya da istəmədiyiniz faylların üstünə kopiyalama edə bilərsiniz.
 
-To deal with this issue, programmers long ago developed local VCSs that had a simple database that kept all the changes to files under revision control (see Figure 1-1).
+Bu problemlə baş edə bilmək üçün, proqramçılar uzun zaman əvvəl, fayllardakı bütün dəyişiklikləri versiya nəzarətinə alan sadə bir veri bazasına sahib olan lokal VNS'leri inkişaf etdirdilər (bax Göstərici 1-1).
 
 Insert 18333fig0101.png 
-Figure 1-1. Local version control diagram.
+Göstərici 1-1. Lokal Sürüm Nəzarət diaqramı.
 
-One of the more popular VCS tools was a system called rcs, which is still distributed with many computers today. Even the popular Mac OS X operating system includes the  rcs command when you install the Developer Tools. This tool basically works by keeping patch sets (that is, the differences between files) from one change to another in a special format on disk; it can then re-create what any file looked like at any point in time by adding up all the patches.
+Ən məşhur VNS vasitələrindən biri, bu gün hələ çox kompüterə yüklenmiş olaraq yayılan, RCS adında bir sistem idi. Məşhur Mac OS X əməliyyat sistemi belə, Developer Tools'u yüklediğinizde, RCS əmrini qurmaqdadır. Bu vasitə, iki versiyası arasındakı yamaqları (yəni, fayllar arasındakı fərqləri) xüsusi bir şəkildə diskə yazar; daha sonra, bu yamaqları bir-birinə əlavə, bir faylın müəyyən bir distributivdəki görünüşünü yenidən meydana gətirər.
 
-### Centralized Version Control Systems ###
+### Mərkəzi Versiya Nəzarət Sistemləri ###
 
-The next major issue that people encounter is that they need to collaborate with developers on other systems. To deal with this problem, Centralized Version Control Systems (CVCSs) were developed. These systems, such as CVS, Subversion, and Perforce, have a single server that contains all the versioned files, and a number of clients that check out files from that central place. For many years, this has been the standard for version control (see Figure 1-2).
+İnsanların qarşılaşdığı ikinci böyük problem, başqa sistemlərdəki proqramçılar ilə birlikdə iş ehtiyacından irəli gəlir. Bu problemlə başa çıxa bilmək üçün, Mərkəzi Versiya Nəzarət Sistemləri (MVNS) inkişaf etdirilmişdir. Bu sistemlər, məsələn CVS, Subversion və Perforce, versiyası idarəsinə alınan bütün faylları tutan bir server və bu serverdən faylları seçərək alan (check out) alıcını meydana gələr. Bu üsul, illərcə, versiyası idarəsində standart üsul olaraq qəbul gördü (bax Göstərici 1-2).
 
 Insert 18333fig0102.png 
-Figure 1-2. Centralized version control diagram.
+Göstərici 1-2. Mərkəzi Versiya Nəzarət diaqramı.
 
-This setup offers many advantages, especially over local VCSs. For example, everyone knows to a certain degree what everyone else on the project is doing. Administrators have fine-grained control over who can do what; and it’s far easier to administer a CVCS than it is to deal with local databases on every client.
+Bu üsulun, xüsusilə lokal VNS lere görə, çox sayda üstünlüyü vardır. Məsələn, bir projedeki hər kəs, digərlərinin nə etdiyindən müəyyən ölçüdə xəbərdardır. Sistem idarəçiləri kimin hansı səlahiyyətlərə sahib olacağını olduqca detallı şəkildə təşkil; üstəlik bir MVNS'yi idarə, hər alıcını ayrı-ayrı heyəti olan yerli bazalarını idarə görə çox daha asandır.
 
-However, this setup also has some serious downsides. The most obvious is the single point of failure that the centralized server represents. If that server goes down for an hour, then during that hour nobody can collaborate at all or save versioned changes to anything they’re working on. If the hard disk the central database is on becomes corrupted, and proper backups haven’t been kept, you lose absolutely everything—the entire history of the project except whatever single snapshots people happen to have on their local machines. Local VCS systems suffer from this same problem—whenever you have the entire history of the project in a single place, you risk losing everything.
+Nə var ki, bu üsulun də ciddi bəzi çətinlikləri vardır. Ən aşkar çətinlik, mərkəzi serverin işləməməsi vəziyyətində ortaya çıxacaq qırılma nöqtəsi problemidir. Server bir saatlığına çökəcək olsa, o bir saat boyunca istifadəçilərin işlərini sistemə köçürmələri ya da çalışdıqları şeylərin sürümlenmiş surətlərini saxlamaq mümkün olmayacaq. Mərkəzi bazanın sabit diski pozulacaq olsa, ehtiyyat da olması lazım olduğu kimi edilməmişsə, əlinizdəki hər şeyi -projenin, istifadəçilərin kompüterlərində qalan lokal yaddaş kopiyaları (snapshot) xaricindəki bütün tarihçesini- itirərsiniz. Yerli VNS'ler də bu problemdən çəkir -projenin bütün tarixçəsini tək bir yerdə tutduğunuz müddətcə hər şeyi itirmə riskiniz var.
 
-### Distributed Version Control Systems ###
+### Paylanmış Versiya Nəzarət Sistemləri ###
 
-This is where Distributed Version Control Systems (DVCSs) step in. In a DVCS (such as Git, Mercurial, Bazaar or Darcs), clients don’t just check out the latest snapshot of the files: they fully mirror the repository. Thus if any server dies, and these systems were collaborating via it, any of the client repositories can be copied back up to the server to restore it. Every checkout is really a full backup of all the data (see Figure 1-3).
+Bu nöqtədə Paylanmış Versiya Nəzarət Sistemləri (PVNS) dövrəyə girər. Bir PVNS'de (Git, Mercurial, Bazaar ya da Darcs nümunələrində olduğu kimi), müştərilər (istifadəçilər) faylların yalnız ən son yaddaş surətlərini almaqla qalmazlar: proqram hovuzunu (repository) tamamilə yansılalar (kopyalarlar).Beləcə, serverlərdən biri çöksə, və o server üzərindən ortaq iş icra edən sistemlər varsa, alıcını birinin proqram hovuzu serverə geri yüklənərək sistem qurtarıla bilər. Hər seçmə (checkout) əməliyyatı əsasında bütün məlumatın yedeklenmesiyle nəticələnər(bax Göstərici 1-3).
 
 Insert 18333fig0103.png 
-Figure 1-3. Distributed version control diagram.
+Göstərici 1-3. Paylanmış Versiya Nəzarət diaqramı.
 
-Furthermore, many of these systems deal pretty well with having several remote repositories they can work with, so you can collaborate with different groups of people in different ways simultaneously within the same project. This allows you to set up several types of workflows that aren’t possible in centralized systems, such as hierarchical models.
+Dahası, bu sistemlerden çoğu birden çok uzak uçbirimdeki yazılım havuzuyla rahatlıkla çalışır, böylece, aynı proje için aynı anda farklı insan topluluklarıyla farklı biçimlerde ortak çalışmalar yürütebilirsiniz. Bu, birden çok iş akışı ile çalışabilmenizi sağlar, ki bu merkezi sistemlerde (hiyerarşik modeller gibi) mümkün değildir.
 
 ## A Short History of Git ##
 

From bf1d1b7637e9136abdfc3d39a350f98b5ce93db4 Mon Sep 17 00:00:00 2001
From: Choongmin Lee <choongmin@me.com>
Date: Fri, 8 Aug 2014 16:31:15 +0900
Subject: [PATCH 570/690] [ko] update README

It was a tad outdated.
---
 ko/README.md | 83 +++++++++++++++++++++++++++++-----------------------
 1 file changed, 46 insertions(+), 37 deletions(-)

diff --git a/ko/README.md b/ko/README.md
index 2d1c723c0..747df1892 100644
--- a/ko/README.md
+++ b/ko/README.md
@@ -1,56 +1,65 @@
-Pro Git 책의 내용
-=====================
+This is a translation of the original [README.md](../README.md) in English with
+some additional information about the Korean translation.
 
-이 저장소는 Pro Git의 source code이고 라이센스는 Creative Commons Attribution-Non Commercial-Share Alike 3.0를 따릅니다. 필자는 여러분이 즐겁게 git을 배웠으면 좋겠습니다. 만약 Amazon에서 책을 구입해주신다면 저와 Apress는 깊은 감사를 드릴 것입니다:
+# Pro Git
 
-http://tinyurl.com/amazonprogit
+이곳에 담긴 내용물은 「Pro Git」 한국어판의 소스 코드로, 원본은 영어판 「Pro Git」입니다. 원작과
+본 번역물은 [크리에이티브 커먼즈 저작자표시-비영리-동일조건변경허락 3.0 (CC BY-NC-SA
+3.0)](https://creativecommons.org/licenses/by-nc-sa/3.0/) 조건에 따라 이용할 수
+있습니다.
 
-Ebook 만드는 법
-=====================
+이 책을 통해 Git을 즐겁게 배우시길 바랍니다. [출판된 책을 Amazon에서 구입](http://tinyurl.com/amazonprogit)하시면
+원저자인 Scott Chacon과 Apress 출판사에게 큰 도움이 됩니다.
+[git-scm.com](http://git-scm.com/book/)에서 영어, 한국어 및 10여개의 다른 언어로 온라인에서
+읽을 수도 있습니다.
 
-페도라에서는 다음과 같이 하면 됩니다:
+# 전자책 만들기
 
-    $ yum install ruby calibre rubygems ruby-devel rubygem-ruby-debug 
-    $ gem install rdiscount
-    $ FORMAT=epub ./makeebooks ko # FORMAT이 없으면 mobi파일이 생성됩니다.
+페도라(16 이상)에서는 아래와 같이 할 수 있습니다.
 
-Mac에서는 먼저 Calibre를 내려받아 설치하고 `ebook-convert` 명령을 실행경로에 넣어 줘야 합니다. 예를 들어 `~/bin/`을 실행경로로 사용하고 있다면 다음과 같이합니다:
+    $ yum install ruby calibre rubygems ruby-devel rubygem-ruby-debug rubygem-rdiscount
+    $ ./makeebooks en  # mobi 파일 생성
 
-    $ ln -s /Applications/calibre.app/Contents/MacOS/ebook-convert ~/bin/ebook-convert
+맥에서는 아래의 설명을 따르세요.
 
-그리고 gem을 설치하고 만들면 됩니다:
+1. ruby와 rubygems을 설치
+2. 터미널에서 `gem install rdiscount` 실행
+3. 맥용 Calibre를 다운로드 및 명령줄 도구 설치. PDF를 만들려면 다음 소프트웨어도 설치해야 합니다:
+    * pandoc: http://johnmacfarlane.net/pandoc/installing.html
+    * xelatex: http://tug.org/mactex/
+4. 터미널에서 `./makeebooks ko` 실행 (mobi 파일 생성)
 
-    $ sudo gem install rdiscount ruby-debug
-    $ ./makeebooks en  # will produce a mobi
+역주: 모든 명령어는 프로젝트의 루트 디렉토리에서 실행되어야 합니다.
 
-Pdf 만드는 법
-=====================
+# 정오표
 
-Mac에서는 먼저 Pandoc과 MacTex 패키지를 설치합니다. pdf를 빌드하려면 xetex가 필요한데 MacTex가 가장 쉽습니다. MacTex(2011 패키지 1.8G)는 용량이 크지만 전부 설치합니다.
+이 책에서 잘못된 점이나 수정되어야 하는 부분을 발견한 경우, GitHub 저장소에 [이슈를
+등록](https://github.com/progit/progit/issues/new)해주세요.
 
-그리고 makepdf명령으로 만들 수 있습니다:
+# 번역
 
-    $ ./makepdfs ko
+이 책을 새로운 언어로 번역하고 싶다면 [ISO 639](http://en.wikipedia.org/wiki/List_of_ISO_639-1_codes)
+코드에 맞는 이름으로 프로젝트의 루트 디렉토리에 새 디렉토리를 만든 뒤 pull request를 보내주세요.
+번역된 책은 git-scm.com 웹사이트에 게시되어 누구나 볼 수 있게 됩니다.
 
-오류
-=====================
+# pull request 보내기
 
-틀린 부분이나 개선해야 할 부분이 있으면 주저 말고 저에게 메일을 보내주세요.
-(schacon at gmail dot com)
+* 모든 파일은 UTF-8 인코딩을 사용해야 합니다.
+* 영어 원본과 번역본의 변경 사항은 각각 다른 pull request로 보내주세요.
+* 번역본을 수정할 때는 commit 메시지와 pull request의 제목을 해당 언어의 ISO 639 코드로
+  시작해주세요. 예를 들어 한국어판의 내용을 수정했을 경우 `[ko] improve wording`처럼 제목을
+  달면 됩니다.
+* 변경 사항이 conflict 없이 자동으로 merge될 수 있어야 합니다.
+* PDF 만들기, 전자책 만들기, git-scm.com 웹사이트 등이 잘 작동하는지 꼭 확인해주세요.
 
-번역
-=====================
+# 한국어판 출판 및 역자 정보
 
-이 책을 번역해서 알려주시면 제가 progit.org에 번역본을 올릴 것입니다. 적당히(이탈리아어로 번역한다면 `it`라는 디렉토리를 만든다) 하위 디렉토리를 만들고 번역을 완성하고 나서 필자에게 pull 요청을 해주세요.
+인사이트를 통해서 [Pro Git
+한국어판](http://www.insightbook.co.kr/books/programming-insight/프로-git)이
+2013년 4월 19일에 출판되었습니다. 출판된 책을 구입하시면 도서출판 인사이트와 역자들에게 도움이 됩니다.
 
-역자 정보
-=====================
+## 역자 소개
 
-번역, 박창우(Changwoo Park), pismute at gmail dot com, https://github.com/pismute
-번역, 이성환(Sean Lee), lethee at gmail dot comt, https://github.com/lethee
-번역, 최용재(Yongjae choi), lnyarl at gmail dot comt, https://github.com/lnyarl
-
-종이책
-=====================
-
-[인사이트](http://www.insightbook.co.kr/)를 통해서 Pro Git 한글 번역판이 종이로도 출간됐습니다. 인사이트와 역자에게 도움을 주시기 바람니다.
+* [박창우(Changwoo Park)](https://github.com/pismute), pismute at gmail dot com
+* [이성환(Sean Lee)](https://github.com/lethee), lethee at gmail dot com
+* [최용재(Yongjae choi)](https://github.com/lnyarl), lnyarl at gmail dot com

From c575051c70c07f4d2efec0a915467896f560af61 Mon Sep 17 00:00:00 2001
From: Choongmin Lee <choongmin@me.com>
Date: Fri, 8 Aug 2014 20:15:31 +0900
Subject: [PATCH 571/690] [ko] update chapter 1

This commit improves the Korean translation of the first two paragraphs
in Chapter 1. It makes the sentences sound more natural and removes the
wrong clause in the first paragragh which says there will be an
explanation in this chapter for how to set up a Git server, which is not
true.
---
 ko/01-introduction/01-chapter1.markdown | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/ko/01-introduction/01-chapter1.markdown b/ko/01-introduction/01-chapter1.markdown
index 8a015f6ca..436f67173 100644
--- a/ko/01-introduction/01-chapter1.markdown
+++ b/ko/01-introduction/01-chapter1.markdown
@@ -1,10 +1,10 @@
 # 시작하기 #
 
-이 장에서 설명하는 것은 Git을 처음 접하는 사람에게 필요한 내용이다. 먼저 버전 관리 도구에 대한 이해와 Git을 설치하는 방법을 설명하고 마지막으로 Git 서버를 설정하고 사용하는 방법을 설명한다. 이 장을 다 읽고 나면 Git 탄생 배경, Git을 사용하는 이유, Git을 설정하고 사용하는 방법을 터득하게 될 것이다.
+이 장에서는 Git을 처음 접하는 사람에게 필요한 내용을 다룬다. 버전 관리 도구에 대한 전반적인 사항부터 시작해서 Git의 특징, Git을 설치하는 방법, 마지막으로 Git을 설정하는 법을 설명할 것이다. 이 장을 다 읽고 나면 Git의 탄생 배경과 Git을 사용하는 이유를 이해하고, Git을 사용하기 위한 준비가 다 되어있을 것이다.
 
 ## 버전 관리란? ##
 
-버전 관리는 무엇이고 우리는 왜 이것을 알아야 할까? 버전 관리 시스템은 파일 변화를 시간에 따라 기록했다가 나중에 특정 시점의 버전을 다시 꺼내올 수 있는 시스템이다. 이 책에서는 버전 관리하는 예제로 소스 코드만 보여주지만, 실제로 거의 모든 컴퓨터 파일의 버전을 관리할 수 있다.
+버전 관리란 무엇이며, 이것을 왜 알아야 할까? 버전 관리 시스템은 파일 변화를 시간에 따라 기록했다가 나중에 특정 시점의 버전을 다시 꺼내올 수 있는 시스템이다. 이 책에서는 소프트웨어의 소스 코드를 버전 관리하는 예만 나오지만, 실제로는 모든 컴퓨터 파일이 버전 관리의 대상이 될 수 있다.
 
 그래픽 디자이너나 웹 디자이너도 버전 관리 시스템(VCS - Version Control System)을 사용할 수 있다. VCS로 이미지나 레이아웃의 버전(변경 이력 혹은 수정 내용)을 관리하는 것은 매우 현명하다. VCS를 사용하면 각 파일을 이전 상태로 되돌릴 수 있고, 프로젝트를 통째로 이전 상태로 되돌릴 수 있고, 시간에 따라 수정 내용을 비교해 볼 수 있고, 누가 문제를 일으켰는지도 추적할 수 있고, 누가 언제 만들어낸 이슈인지도 알 수 있다. VCS를 사용하면 파일을 잃어버리거나 잘못 고쳤을 때도 쉽게 복구할 수 있다. 이런 모든 장점을 큰 노력 없이 이용할 수 있다.
 

From d09d45b390013b5f492a1230069616eaed1436ca Mon Sep 17 00:00:00 2001
From: Petr Prikryl <prikryl@atlas.cz>
Date: Fri, 8 Aug 2014 14:03:42 +0200
Subject: [PATCH 572/690] [cs] synchronizing with the new additions to [en]

---
 cs/03-git-branching/01-chapter3.markdown      |  2 +-
 cs/06-git-tools/01-chapter6.markdown          |  6 ++++++
 cs/07-customizing-git/01-chapter7.markdown    |  6 +++++-
 cs/08-git-and-other-scms/01-chapter8.markdown | 11 +++++++++++
 4 files changed, 23 insertions(+), 2 deletions(-)

diff --git a/cs/03-git-branching/01-chapter3.markdown b/cs/03-git-branching/01-chapter3.markdown
index 2c0701fef..2b46fc54b 100644
--- a/cs/03-git-branching/01-chapter3.markdown
+++ b/cs/03-git-branching/01-chapter3.markdown
@@ -2,7 +2,7 @@
 
 Téměř každý systém pro správu verzí podporuje do určité míry větvení. Větvení znamená, že se můžete odloučit od hlavní linie vývoje a pokračovat v práci, aniž byste hlavní linii zanášeli smetím. V mnoha VCS nástrojích se může jednat o poněkud náročný proces, který často vyžaduje vytvoření nové kopie adresáře se zdrojovým kódem. To může – zvláště u velkých projektů – trvat poměrně dlouho.
 
-Někteří lidé mluví o modelu větvení v systému Git jako o jeho „omračující vlastnosti“. Není sporu o tom, že je Git díky tomu ve skupině systémů pro správu verzí poměrně jedinečný. V čem je jeho větvení tak zvláštní? Větvení je v systému Git neuvěřitelně snadné a operace s ním související probíhají téměř okamžitě. A stejně rychlé je i přepínání mezi jednotlivými větvemi. Na rozdíl od ostatních systémů pro správu verzí vybízí Git ke způsobu práce s bohatým větvením a častým slučováním, a to i několikrát za den. Pokud tuto funkci pochopíte a zvládnete její ovládání, dostanete do ruky výkonný a unikátní nástroj, který doslova změní váš pohled na vývoj.
+Někteří lidé mluví o modelu větvení v systému Git jako o převratné vlastnosti („killer feature“). Není sporu o tom, že je Git díky tomu ve skupině systémů pro správu verzí poměrně jedinečný. V čem je jeho větvení tak zvláštní? Větvení je v systému Git neuvěřitelně snadné a operace s ním související probíhají téměř okamžitě. A stejně rychlé je i přepínání mezi jednotlivými větvemi. Na rozdíl od ostatních systémů pro správu verzí vybízí Git ke způsobu práce s bohatým větvením a častým slučováním, a to i několikrát za den. Pokud tuto funkci pochopíte a zvládnete její ovládání, dostanete do ruky výkonný a unikátní nástroj, který doslova změní váš pohled na vývoj.
 
 ## Co je to větev ##
 
diff --git a/cs/06-git-tools/01-chapter6.markdown b/cs/06-git-tools/01-chapter6.markdown
index 068bba4c9..768f9c2f9 100644
--- a/cs/06-git-tools/01-chapter6.markdown
+++ b/cs/06-git-tools/01-chapter6.markdown
@@ -765,6 +765,12 @@ Dalším častým případem bývá, že uživatel zapomene spustit příkaz `gi
 
 Příkaz projde a přepíše všechny revize tak, aby obsahovaly novou adresu. Protože revize obsahují hodnoty SHA-1 svých rodičů, změní tento příkaz SHA všech revizí ve vaší historii, ne pouze těch, které mají odpovídající e-mailovou adresu.
 
+### Velmi rychlá a nebezpečná zbraň: Big Friendly Giant Repo Cleaner (BFG) ###
+
+[Roberto Tyley](https://github.com/rtyley) vytvořil nástroj, který se funkčností podobá `filter-branch` a nazval jej BFG. (Celý název lze doslova přeložit jako Velký, přátelský, obří čistič repozitáře --- představte si pod tím, co chcete.) BFG neumí tolik věcí jako `filter-branch`, ale je *velmi* rychlý. Pro velké repozitáře to může být zásadní rozdíl. Pokud lze vámi zamýšlenou změnu pomocí BFG provést a pokud máte problémy s výkonností prostředí, pak byste o použití tohoto nástroje měli uvažovat.
+
+Podrobnosti naleznete na stránkách [BFG](http://rtyley.github.io/bfg-repo-cleaner/).
+
 ## Ladění v systému Git ##
 
 Git také nabízí několik nástrojů, které vám pomohou ladit problémy v projektech. Protože je Git navržen tak, aby pracoval téměř s jakýmkoli typem projektu, jsou tyto nástroje velmi univerzální. Často vám mohou pomoci odhalit vzniklou chybu nebo problém.
diff --git a/cs/07-customizing-git/01-chapter7.markdown b/cs/07-customizing-git/01-chapter7.markdown
index 0e587fe57..e910b46f3 100644
--- a/cs/07-customizing-git/01-chapter7.markdown
+++ b/cs/07-customizing-git/01-chapter7.markdown
@@ -531,10 +531,14 @@ Spustíte-li příkaz `git archive`, bude po otevření soubor archivu vypadat o
 
 Atributy Git lze použít také k nastavení různých strategií slučování pro různé soubory v projektu. Velmi užitečnou možností je například nastavení, aby se Git nepokoušel sloučit konkrétní soubory, pokud u nich dojde ke konfliktu, a raději použil vaši verzi souboru než jinou.
 
-Tuto možnost využijete, pokud se rozdělila nebo specializovala některá z větví vašeho projektu, avšak vy z ní budete chtít začlenit změny zpět a ignorovat přitom určité soubory. Řekněme, že máte soubor s nastavením databáze database.xml, který se ve dvou větvích liší, a vy sem chcete začlenit jinou svoji větev, aniž byste tento soubor změnili. V tom případě můžete nastavit tento atribut:
+Tuto možnost využijete, pokud se rozdělila nebo specializovala některá z větví vašeho projektu, avšak vy z ní budete chtít začlenit změny zpět a ignorovat přitom určité soubory. Řekněme, že máte soubor s nastavením databáze nazvaný database.xml, který se ve dvou větvích liší, a vy sem chcete začlenit jinou svoji větev, aniž byste tento soubor změnili. V tom případě můžete nastavit tento atribut:
 
 	database.xml merge=ours
 
+A potom nadefinujete prázdnou slučovací strategii `ours` příkazem:
+
+    git config --global merge.ours.driver true
+
 Pokud začleníte druhou větev, místo řešení konfliktů u souboru database.xml se zobrazí následující:
 
 	$ git merge topic
diff --git a/cs/08-git-and-other-scms/01-chapter8.markdown b/cs/08-git-and-other-scms/01-chapter8.markdown
index 01dc32810..303db4d2f 100644
--- a/cs/08-git-and-other-scms/01-chapter8.markdown
+++ b/cs/08-git-and-other-scms/01-chapter8.markdown
@@ -324,6 +324,17 @@ Stejné informace, jaké poskytuje příkaz `svn info`, získáte příkazem `gi
 
 Stejně jako v případě příkazů `blame` a `log` pracuje i tento příkaz offline a zobrazuje stav v okamžiku, kdy jste naposledy komunikovali se serverem Subversion.
 
+Tip: Pokud vaše skripty pro sestavení projektu chtějí spouštět `svn info`, pak si často můžete vystačit s obálkou příkazu git.
+Můžete vyzkoušet
+
+    #!/usr/bin/env bash
+
+    if git rev-parse --git-dir > /dev/null 2>&1 && [[ $1 == "info" ]] ; then
+      git svn info
+    else
+      /usr/local/bin/svn "$@"
+    fi
+
 #### Ignorování souborů, které ignoruje Subversion ####
 
 Jestliže naklonujete repozitář Subversion s nastavenými vlastnostmi `svn:ignore`, pravděpodobně budete chtít nastavit také odpovídající soubory `.gitignore`, abyste omylem nezapsali nežádoucí soubory. Nástroj `git svn` vám k řešení tohoto problému nabízí dva příkazy. Tím prvním je `git svn create-ignore`, jenž automaticky vytvoří odpovídající soubory `.gitignore`, podle nichž se bude řídit už vaše příští revize.

From b7774688c84e2d9d5f5a13cf93e2b0b2ac78964f Mon Sep 17 00:00:00 2001
From: Choongmin Lee <choongmin@me.com>
Date: Sat, 9 Aug 2014 01:21:08 +0900
Subject: [PATCH 573/690] [ko] add a translation guide

---
 ko/translation_guide.txt | 65 ++++++++++++++++++++++++++++++++++++++++
 1 file changed, 65 insertions(+)
 create mode 100644 ko/translation_guide.txt

diff --git a/ko/translation_guide.txt b/ko/translation_guide.txt
new file mode 100644
index 000000000..fb39b71bf
--- /dev/null
+++ b/ko/translation_guide.txt
@@ -0,0 +1,65 @@
+이 문서는 번역에 기여하는 사람들이 기준으로 삼을 수 있는 원칙들을 제시함으로써 일관성과 높은 품질의
+번역을 달성하기 위해 작성되었습니다.
+
+
+1. 기본 원칙
+
+아래는 「C++ 프로그래밍 언어(특별판)」(비야네 스트롭스트룹 지음, 곽용재 옮김)의 번역 원칙 및 용어
+대역(21쪽)에 있는 내용으로, 어느 기술 서적의 번역에도 적용되는 내용이라고 생각하여 옮깁니다.
+
+    1.1 문장
+
+    * 모든 문장은 모호성과 오독률을 최소화하는 데 가장 큰 무게를 둔다.
+    * 원전의 권위는 무시하지 않되, 그 뜻을 충분히 해석한 후 우리말의 리듬을 살려 가장 편하게 읽을 수
+      있는 문장을 사용한다.
+
+    1.2 대역 용어
+
+    * 원문 용어의 대역어는 우리나라 개발업계에서 쓰이는 용어 중 가장 보편적이고 순화된 용어를
+      사옹하며, 그러한 용어가 없을 경우에는 충분한 검토를 거쳐 새로 만든다.
+    * 대역 용어의 선택 및 사용에 있어서는 자연스러움과 보수적인 입장 사이를 최대한 조율하여, 의미
+      전달에 어려움이 없도록 한다.
+
+    1.3 기타
+
+    * 편집 형태는 원서와 동일하게 하되 그 안에서 최대한의 가독률을 추구한다.
+    * 용어 대역표의 경우, 원어-우리말 대치와 우리말-원어 대치를 함께 두어 찾아보기에 편리하도록
+      하였다.
+
+
+2. 편집 지침
+
+고유명사는 대소문자를 바꾸지 않고 그대로 표기하되, 원문이 틀렸을 경우 옳은 표기로 씁니다(예: rcs ->
+RCS). "옳은 표기"의 기준은 위키백과의 표제어로 하고, 없을 경우 구글 검색 결과에서 결과가 많은 쪽을
+따릅니다.
+
+파일명, 명령어(`git add` 등) 등은 그대로 씁니다. 원문과 마찬가지로 반드시 ``로 감싸야 합니다.
+
+용어 대역표에 있는 용어가 맨 처음 나타날 경우, 독자의 이해를 위해 필요한 경우 한국어 용어로 쓴 뒤 괄호
+안에 원문 용어를 넣을 수 있습니다. 이때 원문 용어는 원래 쓰는 방법에 대문자가 들어가 있는 것이 아닌 한
+모두 소문자로 씁니다.
+
+    잘못된 예: 마지막 스냅샷을 가져오는 대신 저장소(Repository)를 통째로 복제한다.
+    옳은 예: 마지막 스냅샷을 가져오는 대신 저장소(repository)를 통째로 복제한다.
+
+같은 용어가 두 번 이상 나타날 경우 약어를 쓸 수 있습니다(예: VCS).
+
+한국어 문장에서는 괄호 앞뒤에 띄어쓰기를 하지 않습니다.
+
+구어체는 지양해주세요(예: 거다 -> 것이다).
+
+
+3. 용어 대역표
+
+이 표는 현재 미완성입니다. 작업을 진행하면서 채워주세요.
+
+centralized                      중앙집중식
+checkout                         가져오다, 체크아웃(하다)
+hierarchical model               계층 모델
+history                          역사, 이력
+local                            로컬
+repository                       저장소
+remote                           원격(의), 원격 저장소
+version control                  버전 관리, 버전(을) 관리하다
+Version Control System           버전 관리 시스템
+workflow                         작업 방식

From e8a47b3f9ae3306b4d186b182fa95d8feebab1d9 Mon Sep 17 00:00:00 2001
From: Choongmin Lee <choongmin@me.com>
Date: Sat, 9 Aug 2014 01:56:34 +0900
Subject: [PATCH 574/690] [ko] update chapter 1

Improve the overall translation quality by conveying the meaning of the
original text more accurately, avoiding colloquial expressions, using
a more consistent writing style, etc.
---
 ko/01-introduction/01-chapter1.markdown | 26 ++++++++++++-------------
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/ko/01-introduction/01-chapter1.markdown b/ko/01-introduction/01-chapter1.markdown
index 436f67173..aa89d1a43 100644
--- a/ko/01-introduction/01-chapter1.markdown
+++ b/ko/01-introduction/01-chapter1.markdown
@@ -1,43 +1,43 @@
 # 시작하기 #
 
-이 장에서는 Git을 처음 접하는 사람에게 필요한 내용을 다룬다. 버전 관리 도구에 대한 전반적인 사항부터 시작해서 Git의 특징, Git을 설치하는 방법, 마지막으로 Git을 설정하는 법을 설명할 것이다. 이 장을 다 읽고 나면 Git의 탄생 배경과 Git을 사용하는 이유를 이해하고, Git을 사용하기 위한 준비가 다 되어있을 것이다.
+이 장에서는 Git을 처음 접하는 사람에게 필요한 내용을 다룬다. 버전 관리 도구에 대한 약간의 배경지식, Git의 특징, Git을 설치하는 법 그리고 Git을 시작하기에 앞서 필요한 설정을 하는 방법을 설명한다. 이 장을 다 읽고 나면 Git의 탄생 배경과 Git이 사용되는 이유를 이해하고, Git을 시작하기 위한 준비가 되어있을 것이다.
 
 ## 버전 관리란? ##
 
-버전 관리란 무엇이며, 이것을 왜 알아야 할까? 버전 관리 시스템은 파일 변화를 시간에 따라 기록했다가 나중에 특정 시점의 버전을 다시 꺼내올 수 있는 시스템이다. 이 책에서는 소프트웨어의 소스 코드를 버전 관리하는 예만 나오지만, 실제로는 모든 컴퓨터 파일이 버전 관리의 대상이 될 수 있다.
+버전 관리란 무엇이며, 왜 이것을 알아야 할까? 버전 관리 시스템은 파일의 변화를 시간에 따라 기록하여 과거 특정 시점의 버전을 다시 불러올 수 있는 시스템이다. 이 책에는 소프트웨어의 소스 코드를 버전 관리하는 예만 나오지만 실제로는 모든 컴퓨터 파일이 버전 관리의 대상이 될 수 있다.
 
-그래픽 디자이너나 웹 디자이너도 버전 관리 시스템(VCS - Version Control System)을 사용할 수 있다. VCS로 이미지나 레이아웃의 버전(변경 이력 혹은 수정 내용)을 관리하는 것은 매우 현명하다. VCS를 사용하면 각 파일을 이전 상태로 되돌릴 수 있고, 프로젝트를 통째로 이전 상태로 되돌릴 수 있고, 시간에 따라 수정 내용을 비교해 볼 수 있고, 누가 문제를 일으켰는지도 추적할 수 있고, 누가 언제 만들어낸 이슈인지도 알 수 있다. VCS를 사용하면 파일을 잃어버리거나 잘못 고쳤을 때도 쉽게 복구할 수 있다. 이런 모든 장점을 큰 노력 없이 이용할 수 있다.
+이미지나 레이아웃을 수정할 때마다 각각의 형태를 모두 보존하고 싶은 그래픽 디자이너나 웹 디자이너라면 버전 관리 시스템(Version Control System; VCS)을 사용하는 것이 현명할 수 있다. VCS를 사용하면 개별 파일 혹은 프로젝트 전체를 이전 상태로 되돌리거나 시간에 따른 변경 사항을 검토할 수 있으며, 문제가 되는 부분을 누가 마지막으로 수정했는지, 누가 언제 이슈를 만들어냈는지 등을 알 수 있다. 또한 파일을 잃어버리거나 무언가 잘못되어도 대개 쉽게 복구할 수 있다. 그리고 이 모든 장점을 누리는 데는 큰 노력이 들지 않는다.
 
 ### 로컬 버전 관리 시스템 ###
 
-많은 사람은 버전을 관리하기 위해 디렉토리로 파일을 복사하는 방법을 쓴다(똑똑한 사람이라면 디렉토리 이름에 시간을 넣을 거다). 이 방법은 간단하므로 자주 사용한다. 그렇지만, 정말 뭔가가 잘못되기 쉽다. 작업하던 디렉토리를 지워버리거나, 실수로 파일을 잘못 고칠 수도 있고, 잘못 복사할 수도 있다.
+대부분의 사람들이 버전 관리를 위해 쓰는 방법은 파일을 다른 디렉토리에 복사하는 것이다(똑똑한 사람이라면 디렉토리 이름에 시간을 넣을 것이다). 이 방법은 간단하고 자주 사용되는 방법이지만 실수가 발생하기 쉽다. 어느 디렉토리에서 작업하고 있었는지 잊어버리고 엉뚱한 파일을 덮어쓰거나 의도하지 않았던 위치로 복사할 수도 있다.
 
-이런 이유로 프로그래머들은 오래전에 로컬 VCS라는 걸 만들었다. 이 VCS는 아주 간단한 데이터베이스를 사용해서 파일의 변경 정보를 관리했다.
+이 문제를 해결하기 위해 오래전에 프로그래머들은 간단한 데이터베이스에 파일의 변경 사항을 기록하는 로컬 버전 관리 시스템을 만들었다(그림 1-1 참조).
 
 Insert 18333fig0101.png
 그림 1-1. 로컬 버전 관리 다이어그램
 
-많이 쓰는 VCS 도구 중에 rcs라고 부르는 것이 있는데 오늘날까지도 아직 많은 회사가 사용하고 있다. Mac OS X 운영체제에서도 개발 도구를 설치하면 RCS가 함께 설치된다. RCS는 기본적으로 Patch Set(파일에서 변경되는 부분)을 관리한다. 이 Patch Set은 특별한 형식의 파일로 저장한다. 그리고 일련의 Patch Set을 적용해서 모든 파일을 특정 시점으로 되돌릴 수 있다.
+유명했던 VCS 도구들 중 현재에도 널리 쓰이는 것으로 RCS라 불리는 시스템이 있다. 그 예로 Mac OS X 운영체제에서는 개발 도구를 설치하면 RCS가 딸려온다. RCS의 기본적인 동작 방식은 각 리비전들 간의 패치 세트(patch set)라고 하는 데이터의 차이점들을 특별한 형식의 파일에 저장, 특정 시점의 파일 내용을 보고 싶을 때 해당 시점까지의 패치들을 모두 더하여 파일을 만들어내는 것이다.
 
 ### 중앙집중식 버전 관리 시스템 ###
 
-프로젝트를 진행하다 보면 다른 개발자와 함께 작업해야 하는 경우가 많다. 이럴 때 생기는 문제를 해결하기 위해 CVCS(중앙집중식 VCS)가 개발됐다. CVS, Subversion, Perforce 같은 시스템은 파일을 관리하는 서버가 별도로 있고 클라이언트가 중앙 서버에서 파일을 받아서 사용(Checkout)한다. 수년 동안 이러한 시스템들이 많은 사랑을 받았다.
+또 다른 문제는 시스템 외부에 있는 개발자들과 함께 작업하는 것이다. 중앙집중식 버전 관리 시스템(Centralized Version Control System; CVCS)은 이 문제를 해결하기 위해 개발됐다. CVS, Subversion, Perforce와 같은 시스템들이 여기에 속한다. CVCS에서는 버전 관리되는 모든 파일을 저장하는 하나의 서버와, 이 중앙 서버에서 파일들을 가져오는(checkout) 다수의 클라이언트가 존재한다. 오랫동안 사용된 이 방식은 지금까지도 버전 관리의 대표적인 방식이다(그림 1-2 참조).
 
 Insert 18333fig0102.png 
-그림 1-2. 중앙집중식 버전 관리(CVCS) 다이어그램
+그림 1-2. 중앙집중식 버전 관리 다이어그램
 
-CVCS 환경은 로컬 VCS에 비해 장점이 많다. 프로젝트에 참여한 사람이면 누가 무엇을 하고 있는지 알 수 있다. 관리자는 누가 무엇을 할 수 있는지 꼼꼼하게 관리할 수 있다. 모든 클라이언트의 로컬 데이터베이스를 관리하는 것보다 VCS 하나를 관리하기가 훨씬 쉽다.
+CVCS는 로컬 VCS에 비해 장점이 많다. 누구나 다른 사람들이 무엇을 하고 있는지 알 수 있고, 관리자는 누가 무엇을 할 수 있는지 꼼꼼하게 관리할 수 있다. CVCS를 관리하는 것은 수많은 클라이언트의 로컬 데이터베이스를 관리하는 것보다 훨씬 쉽다.
 
-그러나 CVCS 환경은 몇 가지 치명적인 결점이 있다. 가장 대표적인 것이 중앙 서버에 발생한 문제다. 만약 서버가 한 시간 동안 다운되면 그동안 아무도 다른 사람과 협업할 수 없고 사람들이 하는 일을 백업할 방법도 없다. 그리고 중앙 데이터베이스가 있는 하드디스크에 문제가 생기면 프로젝트의 모든 히스토리를 잃는다. 물론 사람마다 하나씩 가진 스냅샷은 괜찮다. 로컬 VCS 시스템도 이와 비슷한 결점이 있고 이런 문제가 발생하면 모든 것을 잃는다.
+그러나 CVCS는 심각한 단점이 있다. 중앙 서버가 잘못되면 모든 것이 잘못된다는 점이다. 서버가 다운될 경우 서버가 다시 복구될 때까지 다른 사람과의 협업도, 진행 중이던 작업을 버전 관리하는 것도 불가능해진다. 중앙 데이터베이스가 저장된 하드디스크에 오류가 발생하고 백업도 없다면, 사람들이 각자 자신의 컴퓨터에 가지고 있던 스냅샷 외에는 그동안 쌓인 프로젝트의 이력을 모두 잃게 된다. 로컬 VCS 시스템도 같은 문제가 있다. 프로젝트의 모든 이력이 한곳에만 있을 경우 이것은 피할 수 없는 문제다.
 
 ### 분산 버전 관리 시스템 ###
 
-DVCS(분산 버전 관리 시스템)을 설명할 차례다. Git, Mecurial, Bazaar, Darcs 같은 DVCS에서는 클라이언트가 파일의 마지막 스냅샷을 Checkout하지 않는다. 그냥 저장소를 전부 복제한다. 서버에 문제가 생기면 이 복제물로 다시 작업을 시작할 수 있다. 클라이언트 중에서 아무거나 골라도 서버를 복원할 수 있다. 모든 Checkout은 모든 데이터를 가진 진정한 백업이다.
+분산 버전 관리 시스템(Distributed Version Control System; DVCS)은 앞서 말한 문제를 해결하기 위해 개발되었다. Git, Mecurial, Bazaar, Darcs 등 DVCS에서는 클라이언트가 파일들의 마지막 스냅샷을 가져오는 대신 저장소(repository)를 통째로 복제한다. 따라서 서버에 문제가 생겨도 어느 클라이언트든 복제된 저장소를 다시 서버로 복사하면 서버가 복구된다. 체크아웃(checkout)을 할 때마다 전체 백업이 일어나는 셈이다(그림 1-3 참조).
 
 Insert 18333fig0103.png
-그림 1-3. 분산 버전 관리 시스템(DVCS) 다이어그램
+그림 1-3. 분산 버전 관리 시스템 다이어그램
 
-게다가 대부분의 DVCS 환경에서는 리모트 저장소가 존재한다. 리모트 저장소가 많을 수도 있다. 그래서 사람들은 동시에 다양한 그룹과 다양한 방법으로 협업할 수 있다. 계층 모델 같은 중앙집중식 시스템으로는 할 수 없는 몇 가지 워크플로우를 사용할 수 있다.
+게다가 대부분의 DVCS에서는 다수의 원격 저장소(remote repository)를 갖는 것이 가능하기 때문에 동시에 여러 그룹과 여러 방법으로 함께 작업할 수 있다. 이로 인해 계층 모델(hierarchical model) 등 중앙집중 시스템에서는 할 수 없는 다양한 작업 방식(workflow)들을 사용해볼 수 있다.
 
 ## 짧게 보는 Git의 역사 ##
 

From 21d12234bac54cf05b7644b5deddba4e85b6f70f Mon Sep 17 00:00:00 2001
From: Choongmin Lee <choongmin@me.com>
Date: Sat, 9 Aug 2014 15:33:13 +0900
Subject: [PATCH 575/690] [ko] update README

Add notes on pandoc
---
 ko/README.md | 12 +++++++++++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/ko/README.md b/ko/README.md
index 747df1892..785666934 100644
--- a/ko/README.md
+++ b/ko/README.md
@@ -29,7 +29,17 @@ some additional information about the Korean translation.
     * xelatex: http://tug.org/mactex/
 4. 터미널에서 `./makeebooks ko` 실행 (mobi 파일 생성)
 
-역주: 모든 명령어는 프로젝트의 루트 디렉토리에서 실행되어야 합니다.
+## Pandoc 관련 노트
+
+Pandoc 버전 1.9.1.1에서 확인된 [버그](https://github.com/jgm/pandoc/issues/964)로 인해
+~표 이후의 글자가 사라지는 현상이 있습니다. 버전 1.11.1 이상을 사용해주세요. `pandoc -v` 명령으로
+현재 버전을 알 수 있습니다.
+
+## 역주
+
+* 모든 명령어는 프로젝트의 루트 디렉토리에서 실행되어야 합니다.
+* 한국어판 PDF를 만들려면 [나눔바른고딕](http://hangeul.naver.com),
+  [나눔코딕코딩](http://dev.naver.com/projects/nanumfont/download) 글꼴이 필요합니다.
 
 # 정오표
 

From c0d036bec7eb88e0f9e011ee1be2461ee29488e1 Mon Sep 17 00:00:00 2001
From: Choongmin Lee <choongmin@me.com>
Date: Sat, 9 Aug 2014 15:49:03 +0900
Subject: [PATCH 576/690] [ko] update translation of thanks

---
 ko/README.md     | 8 ++++----
 latex/config.yml | 2 +-
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/ko/README.md b/ko/README.md
index 785666934..2e87baf4c 100644
--- a/ko/README.md
+++ b/ko/README.md
@@ -8,7 +8,7 @@ some additional information about the Korean translation.
 3.0)](https://creativecommons.org/licenses/by-nc-sa/3.0/) 조건에 따라 이용할 수
 있습니다.
 
-이 책을 통해 Git을 즐겁게 배우시길 바랍니다. [출판된 책을 Amazon에서 구입](http://tinyurl.com/amazonprogit)하시면
+이 책을 통해 Git을 즐겁게 배울 수 있기를 바랍니다. [출판된 책을 Amazon에서 구입](http://tinyurl.com/amazonprogit)하시면
 원저자인 Scott Chacon과 Apress 출판사에게 큰 도움이 됩니다.
 [git-scm.com](http://git-scm.com/book/)에서 영어, 한국어 및 10여개의 다른 언어로 온라인에서
 읽을 수도 있습니다.
@@ -64,9 +64,9 @@ Pandoc 버전 1.9.1.1에서 확인된 [버그](https://github.com/jgm/pandoc/iss
 
 # 한국어판 출판 및 역자 정보
 
-인사이트를 통해서 [Pro Git
-한국어판](http://www.insightbook.co.kr/books/programming-insight/프로-git)이
-2013년 4월 19일에 출판되었습니다. 출판된 책을 구입하시면 도서출판 인사이트와 역자들에게 도움이 됩니다.
+도서출판 인사이트를 통해서
+[한국어판](http://www.insightbook.co.kr/books/programming-insight/프로-git)이
+2013년 4월 19일에 출판되었습니다. 출판된 책을 구입하시면 인사이트와 역자들에게 도움이 됩니다.
 
 ## 역자 소개
 
diff --git a/latex/config.yml b/latex/config.yml
index 33d11a1e7..c3baf1e90 100644
--- a/latex/config.yml
+++ b/latex/config.yml
@@ -127,7 +127,7 @@ ko:
   con: "목차"
   fig: "그림"
   tab: "표"
-  thanks: "지금 보시는 문서는 Pro Git 책에 대한 PDF 파일입니다. 본 문서는 Creative Commons 저작자표시-비영리조건-동일조건변경허락 3.0(Creative Commons Attribution-Non Commercial-Share Alike 3.0) 라이센스를 따릅니다. 여러분이 Git을 이해하는데 도움이 되기를 희망합니다. 종이로 출판된 책을 Amazon 웹사이트 \\url{http://tinyurl.com/amazonprogit} 에서 구입하여 저를 비롯한 Apress에도 도움을 주시기를 기대하겠습니다.\\newline한국어 번역판도 인사이트를 통해 종이로 출판됐습니다. 한국어 번역에 대한 자세한 정보는 \\url{https://github.com/progit/progit/tree/master/ko}에서 확인 바람니다."
+  thanks: "지금 보시는 문서는 책 「Pro Git」의 PDF 파일입니다. 본 문서는 크리에이티브 커먼즈 저작자표시-비영리-동일조건변경허락 3.0 (Creative Commons Attribution-Non Commercial-Share Alike 3.0) 조건에 따라 이용할 수 있습니다. 이 책을 통해 Git을 즐겁게 배울 수 있기를 바랍니다. 출판된 책을 Amazon 웹사이트\\url{http://tinyurl.com/amazonprogit}에서 구입하시면 원저자인 Scott Chacon과 Apress 출판사에게 큰 도움이 됩니다.\\newline도서출판 인사이트를 통해서 한국어판이 2013년 4월 19일에 출판되었습니다. 한국어 번역에 대한 자세한 정보는 \\url{https://github.com/progit/progit/tree/master/ko}에서 확인해 주세요."
 be:
   prechap: "Глава "
   presect: "Раздзел "

From 2f1eed8665a8dbb57d714c441dbd9268255a423b Mon Sep 17 00:00:00 2001
From: Ryuichi Okumura <okuryu@okuryu.com>
Date: Sun, 10 Aug 2014 21:26:54 +0900
Subject: [PATCH 577/690] Install git instead of git-core with yum

The repository of yum seems that may be installed git instead of
git-core as same as the Debian based distributions.
---
 en/01-introduction/01-chapter1.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/en/01-introduction/01-chapter1.markdown b/en/01-introduction/01-chapter1.markdown
index d1248fee1..d859765ac 100644
--- a/en/01-introduction/01-chapter1.markdown
+++ b/en/01-introduction/01-chapter1.markdown
@@ -153,7 +153,7 @@ After this is done, you can also get Git via Git itself for updates:
 
 If you want to install Git on Linux via a binary installer, you can generally do so through the basic package-management tool that comes with your distribution. If you’re on Fedora, you can use yum:
 
-	$ yum install git-core
+	$ yum install git
 
 Or if you’re on a Debian-based distribution like Ubuntu, try apt-get:
 

From d1ec03e1b44a11fc21092e59ca53c938eaad41e0 Mon Sep 17 00:00:00 2001
From: Petr Viktorin <encukou@gmail.com>
Date: Sun, 10 Aug 2014 21:55:52 +0200
Subject: [PATCH 578/690] [cs] Chapter 1: Improve wording

---
 cs/01-introduction/01-chapter1.markdown | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/cs/01-introduction/01-chapter1.markdown b/cs/01-introduction/01-chapter1.markdown
index 3e34d6e33..670b411ee 100644
--- a/cs/01-introduction/01-chapter1.markdown
+++ b/cs/01-introduction/01-chapter1.markdown
@@ -32,7 +32,7 @@ Avšak i tato koncepce má závažné nedostatky. Tímto nejkřiklavějším je
 
 ### Distribuované systémy správy verzí ###
 
-V tomto místě přicházejí ke slovu tzv. distribuované systémy správy verzí (DVCS z angl. Distributed Version Control System). V systémech DVCS (např. Git, Mercurial, Bazaar nebo Darcs) uživatelé pouze nestahují nejnovější verzi souborů (tzv. snímek, anglicky snapshot), ale uchovávají kompletní kopii repozitáře (repository). Pokud v takové situaci dojde ke kolapsu serveru, lze jej obnovit zkopírováním repozitáře od libovolného uživatele. Každá lokální kopie (checkout) je plnohodnotnou zálohou všech dat (viz obrázek 1-3).
+V tomto místě přicházejí ke slovu tzv. distribuované systémy správy verzí (DVCS z angl. Distributed Version Control System). V systémech DVCS (např. Git, Mercurial, Bazaar nebo Darcs) uživatelé nestahují pouze nejnovější verzi souborů (tzv. snímek, anglicky snapshot), ale uchovávají kompletní kopii repozitáře (repository). Pokud v takové situaci dojde ke kolapsu serveru, lze jej obnovit zkopírováním repozitáře od libovolného uživatele. Každá lokální kopie (checkout) je plnohodnotnou zálohou všech dat (viz obrázek 1-3).
 
 Insert 18333fig0103.png
 Obrázek 1-3. Diagram distribuované správy verzí
@@ -69,7 +69,7 @@ Git zpracovává data jinak. Chápe je spíše jako sadu snímků (snapshots) vl
 Insert 18333fig0105.png
 Obrázek 1-5. Git ukládá data jako snímky projektu proměnlivé v čase.
 
-Toto je důležitý rozdíl mezi systémem Git a téměř všemi ostatními systémy VCS. Git díky tomu znovu zkoumá skoro každý aspekt správy verzí, které ostatní systémy kopírovaly z předchozí generace. Git se podobá malému systému souborů (spíše než obyčejnému VCS) s řadou skutečně výkonných nástrojů, jež stojí na jeho vrcholu. Některé přednosti, které tato metoda správy dat nabízí, si podrobně ukážeme na systému větvení v kapitole 3.
+Toto je důležitý rozdíl mezi systémem Git a téměř všemi ostatními systémy VCS. Git díky tomu znovu zkoumá skoro každý aspekt správy verzí, které ostatní systémy kopírovaly z předchozí generace. Git se podobá malému systému souborů (spíše než obyčejnému VCS) s řadou skutečně výkonných nástrojů, jež jsou na něm postavené. Některé přednosti, které tato metoda správy dat nabízí, si podrobně ukážeme na systému větvení v kapitole 3.
 
 ### Téměř každá operace je lokální ###
 

From d687d7e50b4206f1135591cbe5ac1d0dcca93556 Mon Sep 17 00:00:00 2001
From: Petr Viktorin <encukou@gmail.com>
Date: Sun, 10 Aug 2014 22:15:43 +0200
Subject: [PATCH 579/690] [cs] Chapter 1 - Note that discussions on the IRC
 channel are in English

---
 cs/01-introduction/01-chapter1.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/cs/01-introduction/01-chapter1.markdown b/cs/01-introduction/01-chapter1.markdown
index 670b411ee..ee3a7e6d4 100644
--- a/cs/01-introduction/01-chapter1.markdown
+++ b/cs/01-introduction/01-chapter1.markdown
@@ -252,7 +252,7 @@ Například manpage nápovědu pro příkaz `config` vyvoláte zadáním:
 	$ git help config
 
 Tyto příkazy jsou užitečné, neboť je můžete spustit kdykoli, dokonce i offline.
-Pokud nestačí ani manuálová stránka ani tato kniha a uvítali byste osobní pomoc, můžete zkusit kanál `#git` nebo `#github` na serveru Freenode IRC (irc.freenode.net). Na těchto kanálech se většinou pohybují stovky lidí, kteří mají se systémem Git bohaté zkušenosti a často ochotně pomohou.
+Pokud nestačí ani manuálová stránka ani tato kniha a uvítali byste osobní pomoc, můžete zkusit kanál `#git` nebo `#github` na serveru Freenode IRC (irc.freenode.net). Na těchto kanálech se většinou pohybují stovky lidí, kteří mají se systémem Git bohaté zkušenosti a často ochotně pomohou. (Nutno ovšem podotknout, že se na těchto kanálech mluví anglicky – pozn. překl.)
 
 ## Shrnutí ##
 

From 8a2868cdaaace2e6a5ba7823c51d8ac0e4b8ffb2 Mon Sep 17 00:00:00 2001
From: Petr Viktorin <encukou@gmail.com>
Date: Sun, 10 Aug 2014 22:40:47 +0200
Subject: [PATCH 580/690] [cs] Chapter 2 - wording improvements, typo fixes

---
 cs/02-git-basics/01-chapter2.markdown | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/cs/02-git-basics/01-chapter2.markdown b/cs/02-git-basics/01-chapter2.markdown
index bb25003fd..f90025885 100644
--- a/cs/02-git-basics/01-chapter2.markdown
+++ b/cs/02-git-basics/01-chapter2.markdown
@@ -71,7 +71,7 @@ To znamená, že žádné soubory nejsou připraveny k zapsání a pracovní adr
 
 	nothing added to commit but untracked files present (use "git add" to track)
 
-Vidíte, že nový soubor `README` není sledován, protože je ve výpisu stavů uveden v části „Untracked files“. Není-li soubor sledován, obecně to znamená, že Git ví o souboru, který nebyl v předchozím snímku (v předchozí revizi), a nezařadí ho ani do dalších snímků, dokud mu k tomu nedáte výslovný příkaz. Díky tomu se nemůže stát, že budou do revizí nedopatřením zahrnuty vygenerované binární soubory nebo jiné soubory, které si nepřejete zahrnout. Vy si ale přejete soubor README zahrnout, a proto spusťme jeho sledování.
+Vidíte, že nový soubor `README` není sledován, protože je ve výpisu stavů uveden v části „Untracked files“. Není-li soubor sledován, obecně to znamená, že Git ví o souboru, který nebyl v předchozím snímku (v předchozí revizi), a nezařadí ho ani do dalších snímků, dokud mu k tomu nedáte výslovný příkaz. Díky tomu se nemůže stát, že budou do revizí nedopatřením zahrnuty vygenerované binární soubory nebo jiné soubory, které si nepřejete zahrnout. Vy si ale přejete soubor README zahrnout, a proto ho začněme sledovat.
 
 ### Sledování nových souborů ###
 
@@ -109,7 +109,7 @@ Nyní provedeme změny v souboru, který už byl sledován. Pokud změníte už
 	        modified:   benchmarks.rb
 
 
-Soubor `benchmarks.rb` je uveden v části „Changes not staged for commit“ (změněny nejsou připraveny k zapsání). Znamená to, že soubor, který je sledován, byl v pracovním adresáři změněn, avšak ještě nebyl připraven k zapsání (staged). Chcete-li ho připravit k zapsání, spusťte příkaz `git add` (jedná se o víceúčelový příkaz – používá se k zahájení sledování nových souborů i k dalším operacím, jako je například označení vyřešených případů kolize souborů při slučování). Spusťme nyní příkaz `git add`, abychom soubor `benchmarks.rb` připravili k zapsání, a potom znovu zadejme příkaz `git status`:
+Soubor `benchmarks.rb` je uveden v části „Changes not staged for commit“ (změny, které nejsou připraveny k zapsání). Znamená to, že soubor, který je sledován, byl v pracovním adresáři změněn, avšak ještě nebyl připraven k zapsání (staged). Chcete-li ho připravit k zapsání, spusťte příkaz `git add` (jedná se o víceúčelový příkaz – používá se k zahájení sledování nových souborů i k dalším operacím, jako je například označení vyřešených případů kolize souborů při slučování). Spusťme nyní příkaz `git add`, abychom soubor `benchmarks.rb` připravili k zapsání, a potom znovu zadejme příkaz `git status`:
 
 	$ git add benchmarks.rb
 	$ git status
@@ -159,7 +159,7 @@ Ve vašem adresáři se často vyskytne skupina souborů, u nichž nebudete cht
 	*.[oa]
 	*~
 
-První řádek říká systému Git, že má ignorovat všechny soubory končící na `.o` nebo `.a` – *objekty* a *archivní* soubory, které mohou být výsledkem překladu. Druhý řádek systému Git říká, aby ignoroval všechny soubory končící vlnovkou (`~`), kterou mnoho textových editorů (např. Emacs) používá k označení dočasných souborů. Můžete rovněž přidat adresář `log`, `tmp` nebo `pid`, automaticky vygenerovanou dokumentaci a podobné. Vytvoření a naplnění souboru `.gitignore` ještě dříve než se pustíte do práce, bývá většinou dobrý nápad. Alespoň se vám nestane, že byste nedopatřením zapsali také soubory, o které v repozitáři Git nestojíte.
+První řádek říká systému Git, že má ignorovat všechny soubory končící na `.o` nebo `.a` – *objekty* a *archivní* soubory, které mohou být výsledkem překladu. Druhý řádek systému Git říká, aby ignoroval všechny soubory končící vlnovkou (`~`), kterou mnoho textových editorů (např. Emacs) používá k označení dočasných souborů. Můžete rovněž přidat adresář `log`, `tmp` nebo `pid`, automaticky vygenerovanou dokumentaci a podobné. Vytvoření a naplnění souboru `.gitignore` ještě dříve než se pustíte do práce bývá většinou dobrý nápad. Alespoň se vám nestane, že byste nedopatřením zapsali také soubory, o které v repozitáři Git nestojíte.
 
 Pravidla pro masky, které můžete použít v souboru `.gitignore`, jsou následující:
 
@@ -579,8 +579,8 @@ Tabulka 2-1 uvádí některé užitečné parametry, které format akceptuje.
 	%h	Zkrácený otisk revize
 	%T	Otisk stromu
 	%t	Zkrácený otisk stromu
-	%P	Nadřazené otisky
-	%p	Zkrácené nadřazené otisky
+	%P	Otisky rodičovských revizí
+	%p	Zkrácené otisky rodičovských revizí
 	%an	Jméno autora
 	%ae	E-mail autora
 	%ad	Datum autora (formát je možné nastavit parametrem --date)

From be9fa675bad4e16d1f506fd0d181e3eca10d7f62 Mon Sep 17 00:00:00 2001
From: Petr Viktorin <encukou@gmail.com>
Date: Sun, 10 Aug 2014 22:41:30 +0200
Subject: [PATCH 581/690] [cs] Chapter 2 - Give the English equivalent for
 "glob patterns"

---
 cs/02-git-basics/01-chapter2.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/cs/02-git-basics/01-chapter2.markdown b/cs/02-git-basics/01-chapter2.markdown
index f90025885..c301bbb54 100644
--- a/cs/02-git-basics/01-chapter2.markdown
+++ b/cs/02-git-basics/01-chapter2.markdown
@@ -164,7 +164,7 @@ První řádek říká systému Git, že má ignorovat všechny soubory končíc
 Pravidla pro masky, které můžete použít v souboru `.gitignore`, jsou následující:
 
 *	Prázdné řádky nebo řádky začínající znakem `#` budou ignorovány.
-*	Standardní masky souborů.
+*	Standardní masky souborů (glob patterns).
 *	Chcete-li označit adresář, můžete masku zakončit lomítkem (`/`).
 *	Pokud řádek začíná vykřičníkem (`!`), maska na něm je negována.
 

From e2b9d99e752653fa19b57124aa72dc7728bc89c7 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Tue, 12 Aug 2014 16:59:07 +0200
Subject: [PATCH 582/690] [it] updating chapter 1
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Così suona meglio
---
 it/01-introduction/01-chapter1.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/it/01-introduction/01-chapter1.markdown b/it/01-introduction/01-chapter1.markdown
index 8f716ca98..58e00a284 100644
--- a/it/01-introduction/01-chapter1.markdown
+++ b/it/01-introduction/01-chapter1.markdown
@@ -155,7 +155,7 @@ Se vuoi installare Git su Linux, tramite una installazione da binario, generalme
 
 	$ yum install git-core
 
-O se sei su una distribuzione basata su Debian, come Ubuntu, prova apt-get:
+O, se usi una distribuzione basata su Debian (come Ubuntu) prova apt-get:
 
 	$ apt-get install git
 

From 6737149397f57726b37b5881b504ad62885a74e6 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Tue, 12 Aug 2014 16:48:14 +0200
Subject: [PATCH 583/690] Updating yum package name for git

Currently seems the repository of yum has a git package instead of git-core. Now it's the same as for Debian based distributions.

See also PR #851
---
 it/01-introduction/01-chapter1.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/it/01-introduction/01-chapter1.markdown b/it/01-introduction/01-chapter1.markdown
index 8f716ca98..f8e5a3ccd 100644
--- a/it/01-introduction/01-chapter1.markdown
+++ b/it/01-introduction/01-chapter1.markdown
@@ -153,7 +153,7 @@ Dopo aver fatto questo, puoi scaricare gli aggiornamenti di Git con lo stesso Gi
 
 Se vuoi installare Git su Linux, tramite una installazione da binario, generalmente puoi farlo con lo strumento base di amministrazione dei pacchetti della tua distribuzione. Se usi Fedora, puoi usare yum:
 
-	$ yum install git-core
+	$ yum install git
 
 O se sei su una distribuzione basata su Debian, come Ubuntu, prova apt-get:
 

From f6bc9c5b64b23202dfaa865572177f6b8f44aa1d Mon Sep 17 00:00:00 2001
From: Peter Vojtek <peter.vojtek@gmail.com>
Date: Tue, 12 Aug 2014 18:52:32 +0200
Subject: [PATCH 584/690] change past tense to present in commit msgs in
 chapter 3.2 (Branching)

---
 en/03-git-branching/01-chapter3.markdown | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/en/03-git-branching/01-chapter3.markdown b/en/03-git-branching/01-chapter3.markdown
index adf1995d1..3d63b2577 100644
--- a/en/03-git-branching/01-chapter3.markdown
+++ b/en/03-git-branching/01-chapter3.markdown
@@ -132,7 +132,7 @@ Figure 3-11. Creating a new branch pointer.
 You work on your web site and do some commits. Doing so moves the `iss53` branch forward, because you have it checked out (that is, your HEAD is pointing to it; see Figure 3-12):
 
 	$ vim index.html
-	$ git commit -a -m 'added a new footer [issue 53]'
+	$ git commit -a -m 'add a new footer [issue 53]'
 
 Insert 18333fig0312.png
 Figure 3-12. The iss53 branch has moved forward with your work.
@@ -151,8 +151,8 @@ Next, you have a hotfix to make. Let’s create a hotfix branch on which to work
 	$ git checkout -b hotfix
 	Switched to a new branch 'hotfix'
 	$ vim index.html
-	$ git commit -a -m 'fixed the broken email address'
-	[hotfix 3a0874c] fixed the broken email address
+	$ git commit -a -m 'fix the broken email address'
+	[hotfix 3a0874c] fix the broken email address
 	 1 files changed, 1 deletion(-)
 
 Insert 18333fig0313.png
@@ -184,8 +184,8 @@ Now you can switch back to your work-in-progress branch on issue #53 and continu
 	$ git checkout iss53
 	Switched to branch 'iss53'
 	$ vim index.html
-	$ git commit -a -m 'finished the new footer [issue 53]'
-	[iss53 ad82d7a] finished the new footer [issue 53]
+	$ git commit -a -m 'finish the new footer [issue 53]'
+	[iss53 ad82d7a] finish the new footer [issue 53]
 	 1 file changed, 1 insertion(+)
 
 Insert 18333fig0315.png

From 421b64f2ac3b608c5bcc7b322aeaff47a7675692 Mon Sep 17 00:00:00 2001
From: Ryuichi Okumura <okuryu@okuryu.com>
Date: Sat, 16 Aug 2014 10:23:03 +0900
Subject: [PATCH 585/690] [ja] Update chapter 1

This change is follow up of #851.
---
 ja/01-introduction/01-chapter1.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ja/01-introduction/01-chapter1.markdown b/ja/01-introduction/01-chapter1.markdown
index 9dc643ca3..8f779f48d 100644
--- a/ja/01-introduction/01-chapter1.markdown
+++ b/ja/01-introduction/01-chapter1.markdown
@@ -155,7 +155,7 @@ Gitをインストールするためには、Gitが依存するライブラリ
 
 バイナリのインストーラーを通じてLinux上にGitをインストールしたいのであれば、大抵はディストリビューションに付属する基本的なパッケージ・マネジメント・ツールを使って、それを行なう事ができます。もしFedoraを使っているのであれば、yumを使う事が出来ます：
 
-	$ yum install git-core
+	$ yum install git
 
 もしくは、もしUbuntuのようなDebianベースのディストリュビューションを使っているのであれば、apt-getをやってみましょう：
 

From e70bff13af562b256dc1617ef7540daffc44f9ff Mon Sep 17 00:00:00 2001
From: Hans Ginzel <hans@matfyz.cz>
Date: Mon, 18 Aug 2014 12:21:44 +0200
Subject: [PATCH 586/690] Update 01-chapter9.markdown
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Oprava nechcete ignorovat → chcete ignorovat (soubory z .gitignore).
---
 cs/09-git-internals/01-chapter9.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/cs/09-git-internals/01-chapter9.markdown b/cs/09-git-internals/01-chapter9.markdown
index 3fe65175e..33ac85619 100644
--- a/cs/09-git-internals/01-chapter9.markdown
+++ b/cs/09-git-internals/01-chapter9.markdown
@@ -27,7 +27,7 @@ Spustíte-li v novém nebo existujícím adresáři příkaz `git init`, Git vyt
 	objects/
 	refs/
 
-Možná ve svém adresáři najdete i další soubory. Toto je však příkazem `git init` čerstvě vytvořený repozitář s výchozím obsahem. Adresář `branches` se už v novějších verzích systému Git nepoužívá a soubor `description` používá pouze program GitWeb, takže o tyto dvě položky se nemusíte starat. Soubor `config` obsahuje konfigurační nastavení vašeho projektu a v adresáři `info` je uložen globální soubor `exclude` s maskami ignorovaných souborů a adresářů, které nechcete explicitně ignorovat prostřednictvím souboru `.gitignore`. Adresář `hooks` obsahuje skripty zásuvných modulů na straně klienta nebo serveru, které jsme podrobně popisovali v kapitole 7.
+Možná ve svém adresáři najdete i další soubory. Toto je však příkazem `git init` čerstvě vytvořený repozitář s výchozím obsahem. Adresář `branches` se už v novějších verzích systému Git nepoužívá a soubor `description` používá pouze program GitWeb, takže o tyto dvě položky se nemusíte starat. Soubor `config` obsahuje konfigurační nastavení vašeho projektu a v adresáři `info` je uložen globální soubor `exclude` s maskami ignorovaných souborů a adresářů, které chcete explicitně ignorovat prostřednictvím souboru `.gitignore`. Adresář `hooks` obsahuje skripty zásuvných modulů na straně klienta nebo serveru, které jsme podrobně popisovali v kapitole 7.
 
 Zbývají čtyři důležité položky: soubory `HEAD` a `index` a adresáře `objects` a `refs`. To jsou ústřední součásti adresáře Git. V adresáři `objects` je uložen celý obsah vaší databáze, v adresáři `refs` jsou uloženy ukazatele na objekty revizí v datech (větve). Soubor `HEAD` ukazuje na větev, na níž se právě nacházíte, a soubor `index` je pro systém Git úložištěm informací o oblasti připravených změn. Na každou z těchto částí se teď podíváme podrobněji, abyste pochopili, jak Git pracuje.
 

From 88811569e6ebd10dce719cc25afbfdc4755e15da Mon Sep 17 00:00:00 2001
From: hsy <che@gmail.com>
Date: Tue, 19 Aug 2014 15:10:19 +0800
Subject: [PATCH 587/690] [zh] Update chapter 3, fixed one spelling

---
 zh/03-git-branching/01-chapter3.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/zh/03-git-branching/01-chapter3.markdown b/zh/03-git-branching/01-chapter3.markdown
index 05bc4817f..56cb8b96b 100644
--- a/zh/03-git-branching/01-chapter3.markdown
+++ b/zh/03-git-branching/01-chapter3.markdown
@@ -394,7 +394,7 @@ Insert 18333fig0321.png
 Insert 18333fig0322.png
 图 3-22. 一次 Git 克隆会建立你自己的本地分支 master 和远程分支 origin/master，并且将它们都指向 `origin` 上的 `master` 分支。
 
-如果你在本地 `master` 分支做了些改动，与此同时，其他人向 `git.ourcompany.com` 推送了他们的更新，那么服务器上的 `master` 分支就会向前推进，而于此同时，你在本地的提交历史正朝向不同方向发展。不过只要你不和服务器通讯，你的 `origin/master` 指针仍然保持原位不会移动（见图 3-23）。
+如果你在本地 `master` 分支做了些改动，与此同时，其他人向 `git.ourcompany.com` 推送了他们的更新，那么服务器上的 `master` 分支就会向前推进，而与此同时，你在本地的提交历史正朝向不同方向发展。不过只要你不和服务器通讯，你的 `origin/master` 指针仍然保持原位不会移动（见图 3-23）。
 
 Insert 18333fig0323.png
 图 3-23. 在本地工作的同时有人向远程仓库推送内容会让提交历史开始分流。

From 8cd54f51023f465e4d4c6547a6d61651b57f1806 Mon Sep 17 00:00:00 2001
From: Petr Prikryl <prikryl@atlas.cz>
Date: Tue, 19 Aug 2014 16:03:29 +0200
Subject: [PATCH 588/690] [cs] fix after merging with newer [en]

---
 cs/01-introduction/01-chapter1.markdown  |  2 +-
 cs/03-git-branching/01-chapter3.markdown | 10 +++++-----
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/cs/01-introduction/01-chapter1.markdown b/cs/01-introduction/01-chapter1.markdown
index ee3a7e6d4..35e688ebe 100644
--- a/cs/01-introduction/01-chapter1.markdown
+++ b/cs/01-introduction/01-chapter1.markdown
@@ -153,7 +153,7 @@ Po dokončení instalace můžete rovněž vyhledat aktualizace systému Git pro
 
 Chcete-li nainstalovat Git v Linuxu pomocí binárního instalátoru, většinou tak můžete učinit pomocí základního nástroje pro správu balíčků, který je součástí vaší distribuce. Ve Fedoře můžete použít nástroj yum:
 
-	$ yum install git-core
+	$ yum install git
 
 V distribuci založené na Debianu (jako je například Ubuntu) zkuste použít program apt-get:
 
diff --git a/cs/03-git-branching/01-chapter3.markdown b/cs/03-git-branching/01-chapter3.markdown
index 2b46fc54b..37a3352c1 100644
--- a/cs/03-git-branching/01-chapter3.markdown
+++ b/cs/03-git-branching/01-chapter3.markdown
@@ -132,7 +132,7 @@ Obrázek 3-11. Vytvoření nového ukazatele na větev
 Pracujete na webových stránkách a zapíšete několik revizí. S každou novou revizí se větev `iss53` posune vpřed, protože jste provedli její checkout (to znamená, že na ni přepnuli ukazuje HEAD – viz obrázek 3-12):
 
 	$ vim index.html
-	$ git commit -a -m 'added a new footer [issue 53]'
+	$ git commit -a -m 'add a new footer [issue 53]'
 
 Insert 18333fig0312.png
 Obrázek 3-12. Větev iss53 se s vaší prací posouvá vpřed.
@@ -151,8 +151,8 @@ Nyní přichází na řadu hotfix. Vytvořme větev s hotfixem, v níž budeme p
 	$ git checkout -b hotfix
 	Switched to a new branch 'hotfix'
 	$ vim index.html
-	$ git commit -a -m 'fixed the broken email address'
-	[hotfix 3a0874c] fixed the broken email address
+	$ git commit -a -m 'fix the broken email address'
+	[hotfix 3a0874c] fix the broken email address
 	 1 files changed, 1 deletion(-)
 
 Insert 18333fig0313.png
@@ -184,8 +184,8 @@ Nyní můžete přepnout zpět na větev s rozdělanou prací a pokračovat na c
 	$ git checkout iss53
 	Switched to branch 'iss53'
 	$ vim index.html
-	$ git commit -a -m 'finished the new footer [issue 53]'
-	[iss53 ad82d7a] finished the new footer [issue 53]
+	$ git commit -a -m 'finish the new footer [issue 53]'
+	[iss53 ad82d7a] finish the new footer [issue 53]
 	 1 file changed, 1 insertion(+)
 
 Insert 18333fig0315.png

From 2a55c7db6bb7ef82720b84ee2a351027637d8e6f Mon Sep 17 00:00:00 2001
From: Soon Van <cog@randomecho.com>
Date: Tue, 19 Aug 2014 11:18:44 -0400
Subject: [PATCH 589/690] Update link and name to Plans and pricing page

---
 az/04-git-server/01-chapter4.markdown    | 2 +-
 cs/04-git-server/01-chapter4.markdown    | 2 +-
 de/04-git-server/01-chapter4.markdown    | 4 ++--
 en/04-git-server/01-chapter4.markdown    | 4 ++--
 es/04-git-server/01-chapter4.markdown    | 2 +-
 fr/04-git-server/01-chapter4.markdown    | 2 +-
 it/04-git-server/01-chapter4.markdown    | 2 +-
 ja/04-git-server/01-chapter4.markdown    | 2 +-
 ko/04-git-server/01-chapter4.markdown    | 2 +-
 nl/04-git-server/01-chapter4.markdown    | 2 +-
 no-nb/04-git-server/01-chapter4.markdown | 2 +-
 pl/04-git-server/01-chapter4.markdown    | 2 +-
 pt-br/04-git-server/01-chapter4.markdown | 2 +-
 ru/04-git-server/01-chapter4.markdown    | 2 +-
 zh-tw/04-git-server/01-chapter4.markdown | 2 +-
 zh/04-git-server/01-chapter4.markdown    | 2 +-
 16 files changed, 18 insertions(+), 18 deletions(-)

diff --git a/az/04-git-server/01-chapter4.markdown b/az/04-git-server/01-chapter4.markdown
index 1e4df37b1..c51b6a74d 100644
--- a/az/04-git-server/01-chapter4.markdown
+++ b/az/04-git-server/01-chapter4.markdown
@@ -738,7 +738,7 @@ GitHub is also a commercial company that charges for accounts that maintain priv
 
 ### Setting Up a User Account ###
 
-The first thing you need to do is set up a free user account. If you visit the Pricing and Signup page at `http://github.com/plans` and click the "Sign Up" button on the Free account (see figure 4-2), you’re taken to the signup page.
+The first thing you need to do is set up a free user account. If you visit the "Plans and pricing" page at `https://github.com/pricing` and click the "Sign Up" button on the Free account (see figure 4-2), you’re taken to the signup page.
 
 Insert 18333fig0402.png
 Figure 4-2. The GitHub plan page.
diff --git a/cs/04-git-server/01-chapter4.markdown b/cs/04-git-server/01-chapter4.markdown
index 5e4d1a27c..46ac01d16 100644
--- a/cs/04-git-server/01-chapter4.markdown
+++ b/cs/04-git-server/01-chapter4.markdown
@@ -744,7 +744,7 @@ GitHub je zároveň komerční společnost, jejíž finanční příjmy plynou z
 
 ### Založení uživatelského účtu ###
 
-První věcí, kterou budete muset udělat, je vytvoření bezplatného uživatelské účtu. Jestliže na stránce „Pricing and Signup“ (`http://github.com/plans`) kliknete u bezplatného účtu (Free) na tlačítko „Sign Up“ (viz obrázek 4-2), přejdete na registrační stránku.
+První věcí, kterou budete muset udělat, je vytvoření bezplatného uživatelské účtu. Jestliže na stránce „Pricing and Signup“ (`https://github.com/pricing`) kliknete u bezplatného účtu (Free) na tlačítko „Sign Up“ (viz obrázek 4-2), přejdete na registrační stránku.
 
 Insert 18333fig0402.png
 Obrázek 4-2. Výběr typu účtu na serveru GitHub
diff --git a/de/04-git-server/01-chapter4.markdown b/de/04-git-server/01-chapter4.markdown
index 16f912007..e0f25980c 100644
--- a/de/04-git-server/01-chapter4.markdown
+++ b/de/04-git-server/01-chapter4.markdown
@@ -1121,9 +1121,9 @@ Wenn ein Anwender ein geschützes, nicht öffentliches Repository auf GitHub ver
 <!--### Setting Up a User Account ###-->
 ## Einrichten eines Benutzeraccounts ###
 
-<!--The first thing you need to do is set up a free user account. If you visit the Pricing and Signup page at `http://github.com/plans` and click the "Sign Up" button on the Free account (see Figure 4-2), you’re taken to the signup page.-->
+<!--The first thing you need to do is set up a free user account. If you visit the "Plans and pricing" page at `https://github.com/pricing` and click the "Sign Up" button on the Free account (see Figure 4-2), you’re taken to the signup page.-->
 
-Um loslegen zu können, musst Du Dir einen Benutzeraccount erstellen. Gib dazu die Adresse `http://github.com/plans` in Deinem Browser ein und wähle den Button „Sign Up“ unter dem „Free account“-Bereich aus (siehe Abbildung 4-2). Danach wirst Du auf die Anmeldeseite weitergeleitet.
+Um loslegen zu können, musst Du Dir einen Benutzeraccount erstellen. Gib dazu die Adresse `https://github.com/pricing` in Deinem Browser ein und wähle den Button „Sign Up“ unter dem „Free account“-Bereich aus (siehe Abbildung 4-2). Danach wirst Du auf die Anmeldeseite weitergeleitet.
 
 <!--Figure 4-2. The GitHub plan page.-->
 
diff --git a/en/04-git-server/01-chapter4.markdown b/en/04-git-server/01-chapter4.markdown
index 8ff5fa1a0..88bfff101 100644
--- a/en/04-git-server/01-chapter4.markdown
+++ b/en/04-git-server/01-chapter4.markdown
@@ -742,13 +742,13 @@ GitHub is by far the largest open source Git hosting site and it’s also one of
 
 ### GitHub ###
 
-GitHub is slightly different than most code-hosting sites in the way that it namespaces projects. Instead of being primarily based on the project, GitHub is user centric. That means when I host my `grit` project on GitHub, you won’t find it at `github.com/grit` but instead at `github.com/schacon/grit`. There is no canonical version of any project, which allows a project to move from one user to another seamlessly if the first author abandons the project.
+GitHub is slightly different than most code-hosting sites in the way that it namespaces projects. Instead of being primarily based on the project, GitHub is user-centric. That means when I host my `grit` project on GitHub, you won’t find it at `github.com/grit` but instead at `github.com/schacon/grit`. There is no canonical version of any project, which allows a project to move from one user to another seamlessly if the first author abandons the project.
 
 GitHub is also a commercial company that charges for accounts that maintain private repositories, but anyone can quickly get a free account to host as many open source projects as they want. We’ll quickly go over how that is done.
 
 ### Setting Up a User Account ###
 
-The first thing you need to do is set up a free user account. If you visit the Pricing and Signup page at `http://github.com/plans` and click the "Sign Up" button on the Free account (see Figure 4-2), you’re taken to the signup page.
+The first thing you need to do is set up a free user account. If you visit the "Plans and pricing" page at `https://github.com/pricing` and click the "Sign Up" button on the Free account (see Figure 4-2), you’re taken to the signup page.
 
 Insert 18333fig0402.png
 Figure 4-2. The GitHub plan page.
diff --git a/es/04-git-server/01-chapter4.markdown b/es/04-git-server/01-chapter4.markdown
index 81597c804..b9fde505d 100755
--- a/es/04-git-server/01-chapter4.markdown
+++ b/es/04-git-server/01-chapter4.markdown
@@ -584,7 +584,7 @@ GitHub es también una compañia comercial, que cobra por las cuentas que tienen
 
 ### Configurando una cuenta de usuario ###
 
-El primer paso es dar de alta una cuenta gratuita. Si visitas la página de Precios e Inicio de Sesión, en 'http://github.com/plans', y clicas sobre el botón "Registro" ("Sign Up") de las cuentas gratuitas, verás una página de registro:
+El primer paso es dar de alta una cuenta gratuita. Si visitas la página de Precios e Inicio de Sesión, en 'https://github.com/pricing', y clicas sobre el botón "Registro" ("Sign Up") de las cuentas gratuitas, verás una página de registro:
 
 Insert 18333fig0402.png
 Figura 4-2. La página de planes GitHub.
diff --git a/fr/04-git-server/01-chapter4.markdown b/fr/04-git-server/01-chapter4.markdown
index 76257d723..5d68cb7bb 100644
--- a/fr/04-git-server/01-chapter4.markdown
+++ b/fr/04-git-server/01-chapter4.markdown
@@ -983,7 +983,7 @@ Nous allons détailler comment faire.
 ### Création d'un compte utilisateur ###
 
 La première chose à faire, c'est de créer un compte utilisateur gratuit.
-Visitez la page « Plans & Pricing » (plans et prix) à `http://github.com/plans` et cliquez sur le bouton « Create a free account » (créer un compte gratuit) de la zone  « Free for open source » (gratuit pour l'open source) (voir figure 4-2) qui vous amène à la page d'enregistrement.
+Visitez la page « Plans and pricing » (plans et prix) à `https://github.com/pricing` et cliquez sur le bouton « Create a free account » (créer un compte gratuit) de la zone  « Free for open source » (gratuit pour l'open source) (voir figure 4-2) qui vous amène à la page d'enregistrement.
 
 Insert 18333fig0402.png
 Figure 4-2. La page des différents plans de GitHub.
diff --git a/it/04-git-server/01-chapter4.markdown b/it/04-git-server/01-chapter4.markdown
index 431538b69..388095f08 100644
--- a/it/04-git-server/01-chapter4.markdown
+++ b/it/04-git-server/01-chapter4.markdown
@@ -741,7 +741,7 @@ GitHub è inoltre una organizzazione commerciale che addebita gli account che ma
 
 ### Configurare un Account Utente ###
 
-La prima cosa di cui hai bisogno è configurare un account utente gratuito. Se visiti la pagina "Pricing and Signup" all'inidirizzo `http://github.com/plans` e fai click sul pulsante "Sign Up" per un account gratuito (vedi figura 4-2), sarai portato alla pagina di iscrizione.
+La prima cosa di cui hai bisogno è configurare un account utente gratuito. Se visiti la pagina "Plans and pricing" all'inidirizzo `http://https://github.com/pricing` e fai click sul pulsante "Sign Up" per un account gratuito (vedi figura 4-2), sarai portato alla pagina di iscrizione.
 
 Insert 18333fig0402.png
 Figura 4-2. La pagina dei piani di GitHub.
diff --git a/ja/04-git-server/01-chapter4.markdown b/ja/04-git-server/01-chapter4.markdown
index af26092c6..3beeeedbe 100644
--- a/ja/04-git-server/01-chapter4.markdown
+++ b/ja/04-git-server/01-chapter4.markdown
@@ -741,7 +741,7 @@ GitHub は営利企業なので、非公開のリポジトリについては料
 
 ### ユーザーアカウントの作成 ###
 
-まずはフリー版のユーザーアカウントを作成しましょう。Pricing and Signup のページ `http://github.com/plans` で、フリーアカウントの "Sign Up" ボタンを押すと (図 4-2 を参照ください)、新規登録ページに移動します。
+まずはフリー版のユーザーアカウントを作成しましょう。Plans and pricing のページ `https://github.com/pricing` で、フリーアカウントの "Sign Up" ボタンを押すと (図 4-2 を参照ください)、新規登録ページに移動します。
 
 Insert 18333fig0402.png
 図 4-2. GitHub のプラン説明ページ
diff --git a/ko/04-git-server/01-chapter4.markdown b/ko/04-git-server/01-chapter4.markdown
index ff28be894..b093a204d 100644
--- a/ko/04-git-server/01-chapter4.markdown
+++ b/ko/04-git-server/01-chapter4.markdown
@@ -745,7 +745,7 @@ GitHub은 이윤을 목적으로 하는 회사이기 때문에 비공개 저장
 
 ### 계정 설정하기 ###
 
-먼저 무료 계정을 하나 만든다. 가격 정책에 대해 알려주며 가입을 시작할 수 있는 `http://github.com/plans`에 방문하여 "Sign up" 버튼을 클릭한다. 그러면 가입 페이지로 이동한다.
+먼저 무료 계정을 하나 만든다. 가격 정책에 대해 알려주며 가입을 시작할 수 있는 `https://github.com/pricing`에 방문하여 "Sign up" 버튼을 클릭한다. 그러면 가입 페이지로 이동한다.
 
 Insert 18333fig0402.png
 그림 4-2. GitHub 가격 정책 페이지
diff --git a/nl/04-git-server/01-chapter4.markdown b/nl/04-git-server/01-chapter4.markdown
index 4ddf3e9fc..1068d2e82 100644
--- a/nl/04-git-server/01-chapter4.markdown
+++ b/nl/04-git-server/01-chapter4.markdown
@@ -779,7 +779,7 @@ GitHub is ook een commercieel bedrijf dat geld vraagt voor accounts die privé r
 
 ### Een gebruikersaccount instellen ###
 
-Het eerste dat je moet doen is een gratis gebruikers account aanvragen. Als je de Pricing and Signup pagina op `http://github.com/plans` bezoekt en de "Sign Up" knop aanklikt op het Free account (zie figuur 4-2), dan wordt je naar de inteken pagina gebracht.
+Het eerste dat je moet doen is een gratis gebruikers account aanvragen. Als je de "Plans and pricing" pagina op `https://github.com/pricing` bezoekt en de "Sign Up" knop aanklikt op het Free account (zie figuur 4-2), dan wordt je naar de inteken pagina gebracht.
 
 Insert 18333fig0402.png
 Figuur 4-2. De GitHub plan pagina.
diff --git a/no-nb/04-git-server/01-chapter4.markdown b/no-nb/04-git-server/01-chapter4.markdown
index a52ba5361..2bf5855cc 100644
--- a/no-nb/04-git-server/01-chapter4.markdown
+++ b/no-nb/04-git-server/01-chapter4.markdown
@@ -744,7 +744,7 @@ GitHub is also a commercial company that charges for accounts that maintain priv
 
 ### Setting Up a User Account ###
 
-The first thing you need to do is set up a free user account. If you visit the Pricing and Signup page at `http://github.com/plans` and click the "Sign Up" button on the Free account (see Figure 4-2), you’re taken to the signup page.
+The first thing you need to do is set up a free user account. If you visit the "Plans and pricing" page at `https://github.com/pricing` and click the "Sign Up" button on the Free account (see Figure 4-2), you’re taken to the signup page.
 
 Insert 18333fig0402.png
 Figure 4-2. The GitHub plan page.
diff --git a/pl/04-git-server/01-chapter4.markdown b/pl/04-git-server/01-chapter4.markdown
index 90b545c36..23fb04850 100644
--- a/pl/04-git-server/01-chapter4.markdown
+++ b/pl/04-git-server/01-chapter4.markdown
@@ -774,7 +774,7 @@ GitHub jest również spółką handlową, która pobiera opłaty za utrzymanie
 
 ### Konfigurowanie konta użytkownika ###
 
-Pierwszą rzeczą jaką musisz zrobić jest założenie darmowego konta użytkownika. W tym celu wchodzisz na stronę rejestracji `http://github.com/plans` i klikasz przycisk "Zarejestruj się" na darmowe konto (patrz rysunek 4-2) i jesteś już przeniesiony na stronę rejestracji.
+Pierwszą rzeczą jaką musisz zrobić jest założenie darmowego konta użytkownika. W tym celu wchodzisz na stronę rejestracji `https://github.com/pricing` i klikasz przycisk "Zarejestruj się" na darmowe konto (patrz rysunek 4-2) i jesteś już przeniesiony na stronę rejestracji.
 
 Insert 18333fig0402.png
 Figure 4-2. Strona rejestracji GitHub.
diff --git a/pt-br/04-git-server/01-chapter4.markdown b/pt-br/04-git-server/01-chapter4.markdown
index c97feb3ae..7b633ec58 100644
--- a/pt-br/04-git-server/01-chapter4.markdown
+++ b/pt-br/04-git-server/01-chapter4.markdown
@@ -766,7 +766,7 @@ GitHub também é uma empresa comercial que cobra para contas que mantêm reposi
 
 ### Criando uma Conta de Usuário ###
 
-A primeira coisa que você precisa fazer é criar uma conta de usuário gratuita. Se você visitar a página de Preços e Inscrição em `http://github.com/plans` e clicar no botão "Sign Up" na conta gratuita (ver figura 4-2), você é levado à página de inscrição.
+A primeira coisa que você precisa fazer é criar uma conta de usuário gratuita. Se você visitar a página de Preços e Inscrição em `https://github.com/pricing` e clicar no botão "Sign Up" na conta gratuita (ver figura 4-2), você é levado à página de inscrição.
 
 Insert 18333fig0402.png
 Figure 4-2. A página de planos do GitHub.
diff --git a/ru/04-git-server/01-chapter4.markdown b/ru/04-git-server/01-chapter4.markdown
index 92d11d939..30927a9a7 100644
--- a/ru/04-git-server/01-chapter4.markdown
+++ b/ru/04-git-server/01-chapter4.markdown
@@ -731,7 +731,7 @@ GitHub — это коммерческая компания, которая вз
 
 ### Настройка учётной записи ###
 
-Первое, что вам нужно сделать, это настроить учётную запись. Если вы посетите страницу Plans & Pricing по адресу `http://github.com/plans` и нажмёте на кнопку "Create a free account" (см. рисунок 4-2), вы попадёте на страницу регистрации.
+Первое, что вам нужно сделать, это настроить учётную запись. Если вы посетите страницу "Plans and pricing" по адресу `https://github.com/pricing` и нажмёте на кнопку "Create a free account" (см. рисунок 4-2), вы попадёте на страницу регистрации.
 
 Insert 18333fig0402.png
 Рисунок 4-2. Страница тарифных планов на GitHub'е.
diff --git a/zh-tw/04-git-server/01-chapter4.markdown b/zh-tw/04-git-server/01-chapter4.markdown
index cfd2f2e3f..b9aa91489 100644
--- a/zh-tw/04-git-server/01-chapter4.markdown
+++ b/zh-tw/04-git-server/01-chapter4.markdown
@@ -743,7 +743,7 @@ GitHub 同時也是一個向使用私有倉庫的用戶收取費用的商業公
 
 ### 建立新帳戶 ###
 
-首先註冊一個免費帳戶。訪問 Pricing and Signup 頁面 `http://github.com/plans` 並點擊 Free acount 裡的 Sign Up 按鈕（見圖 4-2），進入註冊頁面。
+首先註冊一個免費帳戶。訪問 "Plans and pricing" 頁面 `https://github.com/pricing` 並點擊 Free acount 裡的 Sign Up 按鈕（見圖 4-2），進入註冊頁面。
 
 Insert 18333fig0402.png
 圖 4-2. GitHub 服務簡介頁面
diff --git a/zh/04-git-server/01-chapter4.markdown b/zh/04-git-server/01-chapter4.markdown
index ef41b90b2..a2cd86672 100644
--- a/zh/04-git-server/01-chapter4.markdown
+++ b/zh/04-git-server/01-chapter4.markdown
@@ -743,7 +743,7 @@ GitHub 同时也是一个向使用私有仓库的用户收取费用的商业公
 
 ### 建立新账户 ###
 
-首先注册一个免费账户。访问 Pricing and Signup 页面 `http://github.com/plans` 并点击 Free acount 里的 Sign Up 按钮（见图 4-2），进入注册页面。
+首先注册一个免费账户。访问 "Plans and pricing" 页面 `https://github.com/pricing` 并点击 Free acount 里的 Sign Up 按钮（见图 4-2），进入注册页面。
 
 Insert 18333fig0402.png
 图 4-2. GitHub 服务简介页面

From c9c079fc5cd96c1846b2d8fbc098a30d3bca3c7c Mon Sep 17 00:00:00 2001
From: Kieran Spear <kispear@gmail.com>
Date: Fri, 22 Aug 2014 16:17:14 +1000
Subject: [PATCH 590/690] Fix BFG capability

---
 en/06-git-tools/01-chapter6.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/en/06-git-tools/01-chapter6.markdown b/en/06-git-tools/01-chapter6.markdown
index 16179c5aa..18044f27e 100644
--- a/en/06-git-tools/01-chapter6.markdown
+++ b/en/06-git-tools/01-chapter6.markdown
@@ -750,7 +750,7 @@ This goes through and rewrites every commit to have your new address. Because co
 
 ### The Very Fast Nuclear Option: Big Friendly Giant Repo Cleaner (BFG) ###
 
-[Roberto Tyley](https://github.com/rtyley) has written a similar tool to `filter-branch` called the BFG. BFG cannot do as much as `filter-branch`, but it is _very_ fast and on a large repository this can make a big difference. If the change you want to make is in the scope of BFG capaility, and you have performance issues, then you should consider using it.
+[Roberto Tyley](https://github.com/rtyley) has written a similar tool to `filter-branch` called the BFG. BFG cannot do as much as `filter-branch`, but it is _very_ fast and on a large repository this can make a big difference. If the change you want to make is in the scope of BFG capability, and you have performance issues, then you should consider using it.
 
 See the [BFG](http://rtyley.github.io/bfg-repo-cleaner/) website for details.
 

From d11be6feb16db1269ed29b8663ac6c01088547a9 Mon Sep 17 00:00:00 2001
From: Petr Prikryl <prikryl@atlas.cz>
Date: Fri, 22 Aug 2014 12:53:48 +0200
Subject: [PATCH 591/690] [cs] "killer feature" translation (left out)

---
 cs/03-git-branching/01-chapter3.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/cs/03-git-branching/01-chapter3.markdown b/cs/03-git-branching/01-chapter3.markdown
index 37a3352c1..95f3afe98 100644
--- a/cs/03-git-branching/01-chapter3.markdown
+++ b/cs/03-git-branching/01-chapter3.markdown
@@ -2,7 +2,7 @@
 
 Téměř každý systém pro správu verzí podporuje do určité míry větvení. Větvení znamená, že se můžete odloučit od hlavní linie vývoje a pokračovat v práci, aniž byste hlavní linii zanášeli smetím. V mnoha VCS nástrojích se může jednat o poněkud náročný proces, který často vyžaduje vytvoření nové kopie adresáře se zdrojovým kódem. To může – zvláště u velkých projektů – trvat poměrně dlouho.
 
-Někteří lidé mluví o modelu větvení v systému Git jako o převratné vlastnosti („killer feature“). Není sporu o tom, že je Git díky tomu ve skupině systémů pro správu verzí poměrně jedinečný. V čem je jeho větvení tak zvláštní? Větvení je v systému Git neuvěřitelně snadné a operace s ním související probíhají téměř okamžitě. A stejně rychlé je i přepínání mezi jednotlivými větvemi. Na rozdíl od ostatních systémů pro správu verzí vybízí Git ke způsobu práce s bohatým větvením a častým slučováním, a to i několikrát za den. Pokud tuto funkci pochopíte a zvládnete její ovládání, dostanete do ruky výkonný a unikátní nástroj, který doslova změní váš pohled na vývoj.
+Někteří lidé mluví o modelu větvení v systému Git jako o převratné vlastnosti. Není sporu o tom, že je Git díky tomu ve skupině systémů pro správu verzí poměrně jedinečný. V čem je jeho větvení tak zvláštní? Větvení je v systému Git neuvěřitelně snadné a operace s ním související probíhají téměř okamžitě. A stejně rychlé je i přepínání mezi jednotlivými větvemi. Na rozdíl od ostatních systémů pro správu verzí vybízí Git ke způsobu práce s bohatým větvením a častým slučováním, a to i několikrát za den. Pokud tuto funkci pochopíte a zvládnete její ovládání, dostanete do ruky výkonný a unikátní nástroj, který doslova změní váš pohled na vývoj.
 
 ## Co je to větev ##
 

From 1361b5850a8b8e2f29f05763102d99d559bfd8a3 Mon Sep 17 00:00:00 2001
From: Petr Prikryl <prikryl@atlas.cz>
Date: Fri, 22 Aug 2014 15:39:25 +0200
Subject: [PATCH 592/690] [cs] ch1 typo, ch4 wording

---
 cs/01-introduction/01-chapter1.markdown |  2 +-
 cs/04-git-server/01-chapter4.markdown   | 12 ++++++------
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/cs/01-introduction/01-chapter1.markdown b/cs/01-introduction/01-chapter1.markdown
index 35e688ebe..33aa76d00 100644
--- a/cs/01-introduction/01-chapter1.markdown
+++ b/cs/01-introduction/01-chapter1.markdown
@@ -41,7 +41,7 @@ Mnoho z těchto systémů navíc bez větších obtíží pracuje i s několika
 
 ## Stručná historie systému Git ##
 
-Tak jako mnoho velkých věcí v lidské historii se i systém Git zrodil z kreativní destrukce a vášnivého sporu. Jádro Linuxu je software celkém velkého rozsahu, s otevřeným kódem. V letech 1991 — 2002 bylo jádro Linuxu spravováno formou záplat a archivních souborů. V roce 2002 začal projekt vývoje linuxového jádra využívat komerční systém DVCS s názvem BitKeeper.
+Tak jako mnoho velkých věcí v lidské historii se i systém Git zrodil z kreativní destrukce a vášnivého sporu. Jádro Linuxu je software celkem velkého rozsahu, s otevřeným kódem. V letech 1991 — 2002 bylo jádro Linuxu spravováno formou záplat a archivních souborů. V roce 2002 začal projekt vývoje linuxového jádra využívat komerční systém DVCS s názvem BitKeeper.
 
 V roce 2005 se zhoršily vztahy mezi komunitou, která vyvíjela jádro Linuxu, a komerční společností, která vyvinula BitKeeper, a společnost přestala tento systém poskytovat zdarma. To přimělo komunitu vývojářů Linuxu (a zejména Linuse Torvaldse, tvůrce Linuxu), aby vyvinula vlastní nástroj, založený na poznatcích, které nasbírala při užívání systému BitKeeper. Mezi požadované vlastnosti systému patřily zejména:
 
diff --git a/cs/04-git-server/01-chapter4.markdown b/cs/04-git-server/01-chapter4.markdown
index d3b0c44b7..18566f64a 100644
--- a/cs/04-git-server/01-chapter4.markdown
+++ b/cs/04-git-server/01-chapter4.markdown
@@ -1,20 +1,20 @@
 # Git na serveru #
 
-V této chvíli byste už měli zvládat většinu každodenních úkonů, pro něž se vyplatí Git používat. Abyste však mohli v systému Git spolupracovat s ostatními, budete potřebovat vzdálený repozitář Git. Technicky vzato sice můžete odesílat a stahovat změny z repozitářů jednotlivých spolupracovníků, tento postup ale nedoporučujeme, protože se může při troše neopatrnosti velmi snadno stát, že zapomenete, kdo na čem pracuje. Navíc chcete, aby měli vaši spolupracovníci do repozitáře přístup, i když je váš počítač offline – na společný repozitář bývá často lepší spolehnutí. Jako nejlepší metodu spolupráce s ostatními proto můžeme doporučit nastavení „neutrálního“ repozitáře, do nějž budete mít všichni přístup, budete do něj moci odesílat data a budete z něj moci stahovat. Tomuto repozitáři budeme říkat „server Git“. Jak ale zjistíte, nebývá hostování repozitáře Git nijak zvlášť náročné na zdroje, a tak nejspíš nebudete potřebovat celý server.
+V této chvíli byste už měli zvládat většinu každodenních úkonů, pro něž se vyplatí Git používat. Abyste však mohli v systému Git spolupracovat s ostatními, budete potřebovat vzdálený repozitář Git. Technicky vzato sice můžete odesílat a stahovat změny z repozitářů jednotlivých spolupracovníků, tento postup ale nedoporučujeme, protože se může při troše neopatrnosti velmi snadno stát, že zapomenete, kdo na čem pracuje. Navíc chcete, aby měli vaši spolupracovníci do repozitáře přístup, i když je váš počítač vypnutý nebo odpojený – na společný repozitář bývá často lepší spolehnutí. Jako nejlepší metodu spolupráce s ostatními proto můžeme doporučit nastavení „neutrálního“ repozitáře, do nějž budete mít všichni přístup, budete do něj moci odesílat data a budete z něj moci stahovat. Tomuto repozitáři budeme říkat „gitový server“. Jak ale zjistíte, nebývá hostování gitového repozitáře nijak zvlášť náročné na zdroje, a tak nejspíš nebudete potřebovat celý server.
 
-Spuštění serveru Git je jednoduché. Nejprve určíte, jakými protokoly má váš server komunikovat. První část této kapitoly se bude věnovat možným protokolům, jejich přednostem a nevýhodám. V dalších částech popíšeme některá typická nastavení pro použití těchto protokolů, a jak s nimi uvést server do provozu. Nakonec se podíváme na několik možností hostování pro případ, že nebudete mít chuť podstupovat martyrium s nastavováním a správou vlastního serveru a nevadí vám umístit svůj kód na cizí server.
+Zprovoznění gitového serveru je jednoduché. Nejprve určíte, jakými protokoly má váš server komunikovat. První část této kapitoly se bude věnovat možným protokolům, jejich přednostem a nevýhodám. V dalších částech popíšeme některá typická nastavení pro použití těchto protokolů, a jak s nimi uvést server do provozu. Nakonec se podíváme na několik možností hostování pro případ, že nebudete mít chuť podstupovat martyrium s nastavováním a správou vlastního serveru a nevadí vám umístit svůj kód na cizí server.
 
-Pokud víte, že nebudete chtít spravovat vlastní server, můžete přeskočit rovnou na poslední část této kapitoly a podívat se na možnosti nastavení hostovaného účtu. Pak přejděte na následující kapitolu, v níž se dočtete o různých vstupech a výstupech při práci v prostředí s distribuovanou správou zdrojového kódu.
+Pokud víte, že nebudete chtít spravovat vlastní server, můžete přeskočit rovnou na poslední část této kapitoly a podívat se na možnosti nastavení hostovaného účtu. Pak přejděte na následující kapitolu, v níž se dočtete o detailech a záludnostech při práci v prostředí s distribuovanou správou zdrojového kódu.
 
-Vzdálený repozitář je obvykle *holý repozitář* (bare repository), tj. repozitář Git bez pracovního adresáře. Protože se repozitář používá pouze jako místo pro spolupráci, není žádný důvod, aby byl na disku načten konkrétní snímek. Jsou tu pouze uložena data systému Git. Jednoduše bychom mohli také říct, že holý repozitář je obsah adresáře `.git` vašeho projektu a nic víc.
+Vzdálený repozitář je obvykle *holý repozitář* (bare repository), tj. gitový repozitář bez pracovního adresáře. Protože se repozitář používá pouze jako místo pro spolupráci, není žádný důvod, aby byl na disku načten konkrétní snímek. Jsou tu pouze uložena data systému Git. Jednoduše bychom mohli také říct, že holý repozitář je obsah adresáře `.git` vašeho projektu a nic víc.
 
 ## Protokoly ##
 
 Git může k přenosu dat používat jeden ze čtyř hlavních síťových protokolů: Local, Secure Shell (SSH), Git nebo HTTP. V této části se podíváme na to, co jsou jednotlivé protokoly zač a za jakých okolností je (ne)vhodné je použít.
 
-Neměli bychom zamlčet ani to, že s výjimkou protokolu HTTP všechny vyžadují, aby byl na serveru nainstalován a spuštěn systém Git.
+Neměli bychom zamlčet ani to, že s výjimkou protokolu HTTP všechny vyžadují, aby byl na serveru nainstalován a zprovozněn systém Git.
 
-### Protokol Local ###
+### Lokální protokol ###
 
 Nejzákladnější variantou je *lokální protokol* (Local protocol), v němž je vzdálený repozitář uložen v jiném adresáři na disku. Často se využívá v případech, kdy mají všichni z vašeho týmu přístup k vašim sdíleným souborům, např. přes připojení systému NFS, nebo – v méně pravděpodobném případě – se všichni přihlašují na jednom počítači. Tato druhá varianta není právě ideální, protože všechny instance repozitáře s kódem jsou v takovém případě umístěny v jednom počítači, čímž se zvyšuje riziko nevratné ztráty dat.
 

From fb71aa4628cfed003914298d167a50657a0b20ea Mon Sep 17 00:00:00 2001
From: Petr Prikryl <prikryl@atlas.cz>
Date: Sat, 23 Aug 2014 16:08:19 +0200
Subject: [PATCH 593/690] [cs] part of ch.4 revised

---
 cs/04-git-server/01-chapter4.markdown | 22 +++++++++++-----------
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/cs/04-git-server/01-chapter4.markdown b/cs/04-git-server/01-chapter4.markdown
index 18566f64a..dbe0741b6 100644
--- a/cs/04-git-server/01-chapter4.markdown
+++ b/cs/04-git-server/01-chapter4.markdown
@@ -26,7 +26,7 @@ Nebo můžete provést následující:
 
 	$ git clone file:///opt/git/project.git
 
-Pokud na začátek URL explicitně zadáte výraz `file://`, pracuje Git trochu jinak. Pokud pouze zadáte cestu, Git se pokusí použít hardlinky nebo rovnou zkopírovat soubory, které potřebuje. Pokud zadáte výraz `file://`, Git spustí procesy, jež běžně používá k přenosu dat prostřednictvím sítě. Síť je většinou výrazně méně výkonnou metodou přenosu dat. Hlavním důvodem, proč zadat předponu `file://` je to, že tak získáte čistou kopii repozitáře bez nepotřebných referencí a objektů, např. po importu z jiného verzovacího systému a podobně (úkony správy jsou popsány v kapitole 9). My budeme používat normální cestu, neboť tato metoda je téměř vždy rychlejší.
+Pokud na začátek URL explicitně zadáte výraz `file://`, pracuje Git trochu jinak. Pokud pouze zadáte cestu a zdroj i cíl se nacházejí ve stejném systému souborů, pokusí se Git použít hardlinky na potřebné objekty. Pokud se nenacházejí ve stejném systému souborů, dojde k okopírování potřebných objektů pomocí standardních prostředků systému pro kopírování. Pokud zadáte výraz `file://`, Git spustí procesy, jež běžně používá k přenosu dat prostřednictvím sítě. Síť je většinou výrazně méně výkonnou metodou přenosu dat. Hlavním důvodem, proč zadat předponu `file://` je to, že tak získáte čistou kopii repozitáře bez nepotřebných referencí a objektů, například po importu z jiného verzovacího systému a podobně (úkony správy jsou popsány v kapitole 9). My budeme používat normální cestu, neboť tato metoda je téměř vždy rychlejší.
 
 K přidání lokálního repozitáře do existujícího projektu Git můžete použít příkaz například v tomto tvaru:
 
@@ -44,17 +44,17 @@ Jedná se také o výbornou možnost, jak rychle získat práci z pracovního re
 
 Nevýhodou této metody je, že nastavit a získat sdílený přístup z více umístění je většinou těžší než obyčejný síťový přístup. Budete-li chtít pracovat doma a odeslat data z notebooku, budete muset připojit vzdálený disk, což může být ve srovnání s přístupem prostřednictvím sítě složité a pomalé.
 
-Zapomenout bychom neměli ani na to, že používáte-li sdílené připojení určitého druhu, nemusí být tato možnost vždy nutně nejrychlejší. Lokální repozitář je rychlý pouze v případě, že máte rychlý přístup k datům. Repozitář na NFS je často pomalejší než repozitář nad SSH na tomtéž serveru, který ve všech systémech umožňuje spustit Git z lokálních disků.
+Zapomenout bychom neměli ani na to, že používáte-li sdílené připojení určitého druhu, nemusí být tato možnost vždy nutně nejrychlejší. Lokální repozitář je rychlý pouze v případě, že máte rychlý přístup k datům. Repozitář na NFS je často pomalejší než stejný repozitář nad SSH na tomtéž serveru, který ve všech systémech umožňuje spustit Git z lokálních disků.
 
 ### Protokol SSH ###
 
-Patrně nejčastějším přenosovým protokolem pro systém Git je SSH. Je to z toho důvodu, že SSH přístup k serverům je na většině míst už nastaven, a pokud ne, není ho těžké nastavit. SSH je navíc jediným síťovým protokolem, z nějž lze snadno číst a do nějž lze snadno zapisovat. Oba zbývající síťové protokoly (HTTP i Git) jsou většinou určeny pouze ke čtení, a proto i když je máte k dispozici, budete potřebovat SSH protokol pro příkazy k zápisu. SSH je také síťovým protokolem s ověřováním, a protože je hojně rozšířen, je jeho nastavení a používání většinou snadné.
+Patrně nejčastějším přenosovým protokolem pro systém Git je SSH. Je to z toho důvodu, že SSH přístup k serverům je na většině míst už nastaven, a pokud ne, není ho těžké nastavit. SSH je navíc jediným síťovým protokolem, z nějž lze snadno číst a do nějž lze snadno zapisovat. Oba zbývající síťové protokoly (HTTP i Git) jsou většinou určeny pouze ke čtení, a proto i když je dáváte k dispozici ostatním, pro sebe budete potřebovat SSH protokol pro příkazy zápisu. SSH je také síťovým protokolem s autentizací, a protože je hojně rozšířen, je jeho nastavení a používání většinou snadné.
 
-Chcete-li naklonovat repozitář Git pomocí protokolu SSH, zadejte „ssh:// URL“, například:
+Chcete-li naklonovat repozitář Git pomocí protokolu SSH, zadejte `ssh://` URL, například:
 
 	$ git clone ssh://user@server/project.git
 
-Protokol ostatně ani nemusíte zadávat – pokud žádný výslovně neurčíte, Git použije SSH jako výchozí možnost:
+Nebo můžete pro SSH protokol použít kratší zápis jako u scp:
 
 	$ git clone user@server:project.git
 
@@ -62,24 +62,24 @@ Stejně tak nemusíte zadávat ani uživatele, Git automaticky použije uživate
 
 #### Výhody ####
 
-Používání protokolu SSH přináší mnoho výhod. Především byste ho měli používat vždy, když chcete v síti ověřovat oprávnění k zápisu do repozitáře. Zadruhé: protokol SSH má snadné nastavení – SSH démoni jsou zcela běžní, správci sítě si s nimi většinou vědí rady a mnoho distribucí OS je má ve výchozí instalaci nebo má nástroje, aby s nimi mohly pracovat. Z dalších výhod bychom měli zmínit také to, že přístup přes protokol SSH je bezpečný, veškerý přenos dat je šifrovaný a ověřený. A stejně jako protokoly Git a Local je i protokol SSH výkonný. Data jsou před přenosem upravena do co nejkompaktnější podoby.
+Používání protokolu SSH přináší mnoho výhod. Především byste ho měli používat vždy, když chcete v síti používat autentizovaný zápis do repozitáře. Zadruhé: protokol SSH se snadno nastavuje – SSH démoni jsou zcela běžní, správci sítě si s nimi většinou vědí rady a mnoho distribucí OS je má ve výchozí instalaci nebo poskytuje nástroje pro jejich správu. Z dalších výhod bychom měli zmínit také to, že přístup přes protokol SSH je bezpečný, veškerý přenos dat je šifrovaný a autentizovaný. A stejně jako protokoly Git a Local je i protokol SSH výkonný, protože data jsou před přenosem upravena do co nejkompaktnější podoby.
 
 #### Nevýhody ####
 
-Nevýhodou protokolu SSH je, že neumožňuje anonymní přístup do repozitáře. Chce-li někdo získat přístup do vašeho repozitáře, byť třeba jen ke čtení, musí mít přístup k vašemu počítači přes SSH. Proto se protokol SSH nehodí pro projekty s otevřeným zdrojovým kódem. Pokud repozitář používáte jen v rámci firemní sítě, bude pro vás protokol SSH zřejmě naprosto ideální. Pokud chcete povolit anonymní přístup pro čtení k vašim projektům, budete muset nastavit protokol SSH k odesílání svých dat, ale přidat jiný protokol, pomocí nějž budou ostatní tato data stahovat.
+Nevýhodou protokolu SSH je, že neumožňuje anonymní přístup do repozitáře. Chce-li někdo získat přístup do vašeho repozitáře, byť třeba jen ke čtení, musí mít přístup k vašemu počítači přes SSH. Proto se protokol SSH nehodí pro projekty s otevřeným zdrojovým kódem. Pokud repozitář používáte jen v rámci firemní sítě, bude pro vás protokol SSH zřejmě naprosto ideální. Pokud chcete povolit anonymní přístup pro čtení k vašim projektům, budete muset nastavit protokol SSH k odesílání svých dat, ale musíte přidat i jiný protokol, který budou ostatní používat pro stahování.
 
 ### Protokol Git ###
 
-Dalším protokolem v pořadí je protokol Git. Je to speciální démon, který je distribuován spolu se systémem Git. Naslouchá na vyhrazeném portu (9418) a poskytuje podobnou službu jako protokol SSH, avšak bez jakéhokoli ověřování. Chcete-li, aby byl repozitář obsluhován protokolem Git, musíte vytvořit soubor `git-daemon-export-ok` – démon nebude repozitář obsluhovat, dokud v něm tento soubor nebude. Žádné jiné zabezpečení k dispozici není. Repozitář Git je buď dostupný pro všechny a všichni z něj mohou klonovat, nebo dostupný není. To znamená, že se přes tento protokol nedají odesílat žádné revize. Možnost odesílání lze aktivovat, ale vzhledem k tomu, že protokol neumožňuje ověřování, aktivované odesílání znamená, že kdokoli na internetu, kdo najde URL vašeho projektu, do něj bude moci odesílat data. Tato možnost se však téměř nepoužívá.
+Dalším protokolem v pořadí je protokol Git. Je to speciální démon, který je distribuován spolu se systémem Git. Naslouchá na vyhrazeném portu (9418) a poskytuje podobnou službu jako protokol SSH, avšak bez jakékoliv autentizace. Chcete-li, aby byl repozitář zpřístupněn protokolem Git, musíte vytvořit soubor `git-daemon-export-ok`. Bez tohoto souboru nebude repozitář démonem zpřístupněn. Žádné jiné zabezpečení ale k dispozici není. Repozitář Git je buď dostupný pro všechny a všichni z něj mohou klonovat, nebo dostupný není. To znamená, že se přes tento protokol nedají odesílat žádné revize. Možnost odesílání lze zapnout, ale vzhledem k tomu, že protokol neumožňuje autentizaci, aktivované odesílání znamená, že kdokoli na internetu, kdo najde URL vašeho projektu, do něj bude moci odesílat data. Je jasné, že to většinou nechcete.
 
 #### Výhody ####
 
-Protokol Git je ze všech dostupných protokolů nejrychlejší. Potřebujete-li, aby protokol obsluhoval frekventovaný provoz u veřejného projektu nebo velmi velký projekt, u nějž není třeba ověřování identity uživatele ohledně oprávnění pro čtení, bude k obsluze nejvhodnější pravděpodobně právě démon Git. Používá stejný mechanismus přenosu dat jako protokol SSH, na rozdíl od něj ale není zpomalován šifrováním a ověřováním.
+Protokol Git je ze všech dostupných protokolů nejrychlejší. Potřebujete-li, aby protokol obsluhoval frekventovaný provoz u veřejného projektu nebo velmi velký projekt, u nějž není třeba ověřování identity uživatele ohledně oprávnění pro čtení, bude k obsluze nejvhodnější pravděpodobně právě démon Git. Používá stejný mechanismus přenosu dat jako protokol SSH, na rozdíl od něj ale není zpomalován šifrováním a ověřováním identity (autentizací).
 
 #### Nevýhody ####
 
-Nevýhodou protokolu Git je, že neprovádí ověřování. Většinou není žádoucí, aby protokol Git tvořil jediný přístup k vašemu projektu. Protokol Git většinou využijete v kombinaci s přístupem přes SSH. Protokol SSH bude nastaven pro několik málo vývojářů s oprávněním k zápisu (odesílání dat) a všichni ostatní budou používat `git://` pro přístup pouze ke čtení.
-Pravděpodobně se také jedná o protokol s nejobtížnějším nastavením. Vyžaduje spuštění vlastního démona – na jeho nastavení se podíváme v části „Gitosis“ této kapitoly – a dále konfiguraci `xinetd` nebo podobnou, která také není právě jednoduchá. Vyžaduje rovněž povolení přístupu k portu 9418 skrz firewall. Tento port nepatří mezi standardní porty, které by firemní firewally vždy povolovaly. Velkými podnikovými firewally je tento málo rozšířený port většinou blokován.
+Nevýhodou protokolu Git je, že neprovádí autentizaci. Většinou není žádoucí, aby protokol Git tvořil jediný přístup k vašemu projektu. Protokol Git většinou využijete v kombinaci s přístupem přes SSH. Protokol SSH bude nastaven pro několik málo vývojářů s oprávněním k zápisu (odesílání dat) a všichni ostatní budou používat `git://` pro přístup pouze ke čtení.
+Pravděpodobně se také jedná o protokol s nejobtížnějším nastavením. Vyžaduje spuštění vlastního démona – na jeho nastavení se podíváme v části „Gitosis“ této kapitoly – a dále konfiguraci `xinetd` nebo podobnou, což není zrovna procházka růžovou zahradou. Vyžaduje rovněž povolení přístupu k portu 9418 skrz firewall. Tento port nepatří mezi standardní porty, které by firemní firewally vždy povolovaly. Velkými podnikovými firewally je tento málo rozšířený port většinou blokován.
 
 ### Protokol HTTP/S ###
 

From 60fab8d0b43eade28fa49348a5c0485d3826090f Mon Sep 17 00:00:00 2001
From: Petr Prikryl <prikryl@atlas.cz>
Date: Sat, 23 Aug 2014 21:36:43 +0200
Subject: [PATCH 594/690] [cs] revision of a part of the chapter 4

---
 cs/04-git-server/01-chapter4.markdown | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/cs/04-git-server/01-chapter4.markdown b/cs/04-git-server/01-chapter4.markdown
index dbe0741b6..2c80ca9f0 100644
--- a/cs/04-git-server/01-chapter4.markdown
+++ b/cs/04-git-server/01-chapter4.markdown
@@ -91,11 +91,11 @@ Na konec jsme si nechali protokol HTTP. Co je na protokolu HTTP nebo HTTPS sympa
 	$ mv hooks/post-update.sample hooks/post-update
 	$ chmod a+x hooks/post-update
 
-A to je vše. Zásuvný modul `post-update`, který je standardně součástí systému Git, spustí příkaz `git update-server-info`, který zajistí správné vyzvedávání a klonování dat přes protokol HTTP. Tento příkaz se spustí, když do tohoto repozitáře odesíláte data přes protokol SSH. Ostatní mohou klonovat třeba takto:
+A to je vše. Zásuvný modul `post-update`, který je standardně součástí systému Git, spustí příslušný příkaz (`git update-server-info`), který zajistí správné vyzvedávání a klonování dat přes protokol HTTP. Tento příkaz se spustí, když do tohoto repozitáře odesíláte data přes protokol SSH. Poté mohou ostatní klonovat třeba takto:
 
 	$ git clone http://example.com/gitproject.git
 
-V tomto konkrétním případě používáme cestu `/var/www/htdocs`, která je obvyklá u nastavení Apache, ale použít lze v podstatě jakýkoli webový server – stačí uložit holý repozitář do daného umístění. Data repozitáře Git jsou obsluhována jako obyčejné statické soubory (podrobnosti naleznete v kapitole 9).
+V tomto konkrétním případě používáme cestu `/var/www/htdocs`, která je obvyklá u nastavení Apache, ale použít lze v podstatě jakýkoli statický webový server – stačí uložit holý repozitář do dané cesty. Data repozitáře Git jsou obsluhována jako obyčejné statické soubory (podrobnosti o přesném způsobu obsluhy naleznete v kapitole 9).
 
 Odesílat data do repozitáře Git je možné také přes protokol HTTP, avšak tento způsob není příliš rozšířený a vyžaduje nastavení komplexních požadavků protokolu WebDAV. Protože se tato možnost využívá zřídka, nebudeme se jí v této knize věnovat. Pokud vás zajímá používání protokolů HTTP k odesílání dat, více se o přípravě repozitáře k tomuto účelu dočtete na adrese: `http://www.kernel.org/pub/software/scm/git/docs/howto/setup-git-server-over-http.txt` (anglicky). Příjemným faktem na odesílání dat přes protokol HTTP je, že můžete použít jakýkoli server WebDAV i bez speciálních funkcí systému Git. Tuto možnost tak můžete využít, pokud váš poskytovatel webhostingu podporuje WebDAV pro zápis aktualizací na vaše webové stránky.
 
@@ -103,7 +103,7 @@ Odesílat data do repozitáře Git je možné také přes protokol HTTP, avšak
 
 Pro používání protokolu HTTP mluví zejména jeho snadné nastavení. Vystačíte s několika málo příkazy, ale získáte jednoduchý způsob, jak nastavit oprávnění pro čtení repozitáře Git pro okolní svět. Celý postup nezabere víc než pár minut. Protokol HTTP navíc jen minimálně omezuje zdroje serveru. Vzhledem k tomu, že k obsluze všech dat používá většinou statický HTTP server, obslouží běžný server Apache průměrně několik tisíc souborů za sekundu. Ani malý server proto není snadné přetížit.
 
-Své repozitáře můžete prostřednictvím protokolu HTTPS poskytovat pouze ke čtení a šifrovat přenos dat. Nebo můžete zajít ještě dál a vyžadovat, aby klienti používali konkrétní podepsané SSL certifikáty. Je pravda, že v takovém případě by už bylo jednodušší použít veřejné SSH klíče, ale ve vašem konkrétním případě může být použití podepsaných SSL certifikátů nebo jiné ověření identity na základě protokolu HTTP lepší metodou, jak zajistit přístup přes HTTPS pouze ke čtení.
+Své repozitáře můžete zpřístupnit ke čtení prostřednictvím protokolu HTTPS, což znamená, že se přenášený obsah šifruje. Nebo můžete zajít ještě dál a vyžadovat, aby klienti používali konkrétní podepsané SSL certifikáty. Je pravda, že v takovém případě by už bylo jednodušší použít veřejné SSH klíče, ale ve vašem konkrétním případě může být použití podepsaných SSL certifikátů nebo jiné ověření identity na základě protokolu HTTP lepší metodou, jak zajistit přístup přes HTTPS pouze ke čtení.
 
 Z dalších výhod protokolu HTTP bychom mohli jmenovat i jeho značné rozšíření, díky čemuž jsou firemní firewally často nastaveny tak, že umožňují provoz přes standardní port protokolu HTTP.
 
@@ -114,7 +114,7 @@ Nevýhodou obsluhy repozitáře přes protokol HTTP je poměrně nízká výkonn
 ## Jak umístit Git na server ##
 
 Pro úvodní nastavení serveru Git je třeba exportovat existující repozitář do nového, holého repozitáře (bare repository), tj. do repozitáře, který neobsahuje pracovní adresář. S tím obvykle nebývá problém.
-Chcete-li naklonovat stávající repozitář, a vytvořit tak nový a holý, zadejte příkaz clone s parametrem `--bare`. Je zvykem, že adresáře s holým repozitářem končí na `.git`, například:
+Chcete-li naklonovat stávající repozitář, a vytvořit tak nový a holý, zadejte příkaz pro klonování s parametrem `--bare`. Je zvykem, že adresáře s holým repozitářem končí na `.git`, například:
 
 	$ git clone --bare my_project my_project.git
 	Cloning into bare repository 'my_project.git'...

From 22d9440fbde8c3c2717160c4675fca5ab1bb8480 Mon Sep 17 00:00:00 2001
From: Petr Prikryl <prikryl@atlas.cz>
Date: Sun, 24 Aug 2014 12:23:45 +0200
Subject: [PATCH 595/690] [cs] ch. 4 partly revised

---
 cs/04-git-server/01-chapter4.markdown | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/cs/04-git-server/01-chapter4.markdown b/cs/04-git-server/01-chapter4.markdown
index 2c80ca9f0..325d6d84c 100644
--- a/cs/04-git-server/01-chapter4.markdown
+++ b/cs/04-git-server/01-chapter4.markdown
@@ -204,7 +204,7 @@ Budete-li potřebovat podrobnější návod k vytvoření SSH klíče v různýc
 
 ## Nastavení serveru ##
 
-Podívejme se nyní na nastavení SSH přístupu na straně serveru. V tomto příkladu použijeme k ověření uživatelů metodu `authorized_keys`. Předpokládáme také, že pracujete se standardní linuxovou distribucí, jako je např. Ubuntu. Nejprve vytvoříte uživatele 'git' a adresář `.ssh` pro tohoto uživatele.
+Podívejme se nyní na nastavení SSH přístupu na straně serveru. V tomto příkladu použijeme k ověření identity uživatelů metodu `authorized_keys`. Předpokládáme také, že pracujete se standardní linuxovou distribucí, jako je např. Ubuntu. Nejprve vytvoříte uživatele 'git' a adresář `.ssh` pro tohoto uživatele.
 
 	$ sudo adduser git
 	$ su git
@@ -221,7 +221,7 @@ V dalším kroku musíte vložit veřejné SSH klíče od svých vývojářů do
 	O7TCUSBdLQlgMVOFq1I2uPWQOkOWQAHukEOmfjy2jctxSDBQ220ymjaNsHT4kgtZg2AYYgPq
 	dAv8JggJICUvax2T9va5 gsg-keypair
 
-Vy nyní klíče vložíte do souboru `authorized_keys`:
+Vy nyní klíče přidáte do souboru `authorized_keys`:
 
 	$ cat /tmp/id_rsa.john.pub >> ~/.ssh/authorized_keys
 	$ cat /tmp/id_rsa.josie.pub >> ~/.ssh/authorized_keys
@@ -278,7 +278,7 @@ Uživatel 'git' nyní může používat SSH připojení k odesílání a stahov
 
 ## Veřejný přístup ##
 
-A co když chcete u svého projektu nastavit anonymní oprávnění pro čtení? Nehostujete třeba interní soukromý projekt, ale „open source“ projekt. Nebo možná máte několik serverů průběžné integrace, které se neustále mění a vy nechcete stále generovat SSH klíče, rádi byste vždy přidali jen obyčejné anonymní oprávnění pro čtení.
+A co když chcete u svého projektu nastavit anonymní oprávnění pro čtení? Nehostujete třeba interní soukromý projekt, ale „open source“ projekt. Nebo možná máte několik serverů průběžné integrace, které se neustále mění a vy nechcete stále generovat SSH klíče. Rádi byste vždy přidali jen obyčejné anonymní oprávnění pro čtení.
 
 Patrně nejjednodušším způsobem pro menší týmy je spustit statický webový server s kořenovým adresářem dokumentů, v němž budou uloženy vaše Git repozitáře, a zapnout zásuvný modul `post-update`, o kterém jsme se zmínili už v první části této kapitoly. Můžeme pokračovat v našem předchozím příkladu. Řekněme, že máte repozitáře uloženy v adresáři `/opt/git` a na vašem počítači je spuštěn server Apache. Opět, můžete použít jakýkoli webový server. Pro názornost ale ukážeme některá základní nastavení serveru Apache, abyste získali představu, co vás může čekat.
 

From cd59265c596d7e45e1bca1a3d7a0fe35c17d41b7 Mon Sep 17 00:00:00 2001
From: Petr Prikryl <prikryl@atlas.cz>
Date: Mon, 25 Aug 2014 15:05:34 +0200
Subject: [PATCH 596/690] [cs] 09-git-internals/02-translation-notes.markdown
 removed

---
 cs/09-git-internals/02-translation-notes.markdown | 1 -
 1 file changed, 1 deletion(-)
 delete mode 100644 cs/09-git-internals/02-translation-notes.markdown

diff --git a/cs/09-git-internals/02-translation-notes.markdown b/cs/09-git-internals/02-translation-notes.markdown
deleted file mode 100644
index e769bc6e0..000000000
--- a/cs/09-git-internals/02-translation-notes.markdown
+++ /dev/null
@@ -1 +0,0 @@
-# ..........
\ No newline at end of file

From d340c350114b9d77e2f4e39b5e6a27f90bb55dbf Mon Sep 17 00:00:00 2001
From: sampablokuper <sam.kuper@uclmail.net>
Date: Tue, 26 Aug 2014 22:45:33 +0100
Subject: [PATCH 597/690] Install git instead of git-core with MacPorts

`sudo port install git +svn +doc +bash_completion +gitweb` succeeds, whereas `sudo port install git-core +svn +doc +bash_completion +gitweb` fails with output that includes the following helpful messages:
Error: git-core has been made obsolete by the port git. Please install git instead.
Error: org.macports.configure for port git-core returned: obsolete port
Please see the log file for port git-core for details:
    /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_git-core/git-core/main.log
Error: Processing of port git-core failed
---
 en/01-introduction/01-chapter1.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/en/01-introduction/01-chapter1.markdown b/en/01-introduction/01-chapter1.markdown
index d859765ac..9079a47b5 100644
--- a/en/01-introduction/01-chapter1.markdown
+++ b/en/01-introduction/01-chapter1.markdown
@@ -170,7 +170,7 @@ Figure 1-7. Git OS X installer.
 
 The other major way is to install Git via MacPorts (`http://www.macports.org`). If you have MacPorts installed, install Git via
 
-	$ sudo port install git-core +svn +doc +bash_completion +gitweb
+	$ sudo port install git +svn +doc +bash_completion +gitweb
 
 You don’t have to add all the extras, but you’ll probably want to include +svn in case you ever have to use Git with Subversion repositories (see Chapter 8).
 

From ee4586a072772a16faeba18bbea431ffc3da402a Mon Sep 17 00:00:00 2001
From: Petr Prikryl <prikryl@atlas.cz>
Date: Wed, 27 Aug 2014 09:53:55 +0200
Subject: [PATCH 598/690] [fr] newer code snippets

---
 fr/02-git-basics/01-chapter2.markdown | 13 +++++++------
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/fr/02-git-basics/01-chapter2.markdown b/fr/02-git-basics/01-chapter2.markdown
index 07245f842..dc7277735 100644
--- a/fr/02-git-basics/01-chapter2.markdown
+++ b/fr/02-git-basics/01-chapter2.markdown
@@ -80,7 +80,7 @@ L'outil principal pour déterminer quels fichiers sont dans quel état est la co
 Si vous lancez cette commande juste après un clonage, vous devriez voir ce qui suit :
 
 	$ git status
-	# On branch master
+	On branch master
 	nothing to commit, working directory clean
 
 Ce message signifie que votre copie de travail est propre, en d'autres mots, aucun fichier suivi n'a été modifié.
@@ -94,11 +94,12 @@ Si ce fichier n'existait pas auparavant, et que vous lancez la commande `git sta
 
 	$ vim LISEZMOI
 	$ git status
-	# On branch master
-	# Untracked files:
-	#   (use "git add <file>..." to include in what will be committed)
-	#
-	#	LISEZMOI
+	On branch master
+	Untracked files:
+	  (use "git add <file>..." to include in what will be committed)
+
+	        LISEZMOI
+
 	nothing added to commit but untracked files present (use "git add" to track)
 
 Vous pouvez constater que votre nouveau fichier `LISEZMOI` n'est pas en suivi de version, car il apparaît dans la section « Untracked files » de l'état de la copie de travail.

From d880ffab2851adb6dc719f95224b44f15b4415d3 Mon Sep 17 00:00:00 2001
From: Petr Prikryl <prikryl@atlas.cz>
Date: Wed, 27 Aug 2014 10:15:39 +0200
Subject: [PATCH 599/690] [fr] newer snippets in ch.1 and some in ch.2

---
 fr/01-introduction/01-chapter1.markdown |   4 +-
 fr/02-git-basics/01-chapter2.markdown   | 111 ++++++++++++------------
 2 files changed, 59 insertions(+), 56 deletions(-)

diff --git a/fr/01-introduction/01-chapter1.markdown b/fr/01-introduction/01-chapter1.markdown
index 8a0868fcc..9985aa6f0 100644
--- a/fr/01-introduction/01-chapter1.markdown
+++ b/fr/01-introduction/01-chapter1.markdown
@@ -239,7 +239,7 @@ Après ceci, vous pouvez obtenir Git par Git lui-même pour les mises à jour :
 Si vous souhaitez installer Git sur Linux via un installateur d'application, vous pouvez généralement le faire via le système de gestion de paquets de base fourni avec votre distribution.
 Si vous êtes sur Fedora, vous pouvez utiliser yum :
 
-	$ yum install git-core
+	$ yum install git
 
 Si vous êtes sur un système basé sur Debian, tel qu'Ubuntu, essayez apt-get :
 
@@ -268,7 +268,7 @@ Installer Git sur Windows est très facile.
 Le projet msysGit fournit une des procédures d'installation les plus simples.
 Téléchargez simplement le fichier exe d'installateur depuis la page GitHub, et lancez-le :
 
-	http://msysgit.github.com/
+	http://msysgit.github.io
 
 Après son installation, vous avez à la fois la version en ligne de commande (avec un client SSH utile pour la suite) et l'interface graphique standard.
 
diff --git a/fr/02-git-basics/01-chapter2.markdown b/fr/02-git-basics/01-chapter2.markdown
index dc7277735..c7742c88d 100644
--- a/fr/02-git-basics/01-chapter2.markdown
+++ b/fr/02-git-basics/01-chapter2.markdown
@@ -117,12 +117,12 @@ Pour commencer à suivre le fichier `LISEZMOI`, vous pouvez entrer ceci :
 Si vous lancez à nouveau la commande `git status`, vous pouvez constater que votre fichier `LISEZMOI` est maintenant suivi et indexé :
 
 	$ git status
-	# On branch master
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#	new file:   LISEZMOI
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+
+	        new file:   LISEZMOI
+
 
 Vous pouvez affirmer qu'il est indexé car il apparaît dans la section « Changes to be committed » (Modifications à valider).
 Si vous enregistrez à ce moment, la version du fichier à l'instant où vous lancez `git add` est celle qui appartiendra à l'instantané.
@@ -135,17 +135,18 @@ Maintenant, modifions un fichier qui est déjà sous suivi de version.
 Si vous modifiez le fichier sous suivi de version appelé `benchmarks.rb` et que vous lancez à nouveau votre commande `git status`, vous verrez ceci :
 
 	$ git status
-	# On branch master
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#	new file:   LISEZMOI
-	#
-	# Changes not staged for commit:
-	#   (use "git add <file>..." to update what will be committed)
-	#
-	#	modified:   benchmarks.rb
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+
+	        new file:   LISEZMOI
+
+	Changes not staged for commit:
+	  (use "git add <file>..." to update what will be committed)
+	  (use "git checkout -- <file>..." to discard changes in working directory)
+
+	        modified:   benchmarks.rb
+
 
 Le fichier `benchmarks.rb` apparaît sous la section nommée « Changes not staged for commit » ce qui signifie que le fichier sous suivi de version a été modifié dans la copie de travail mais n'est pas encore indexé.
 Pour l'indexer, il faut lancer la commande `git add` (qui est une commande multi-usage — elle peut être utilisée pour placer un fichier sous suivi de version, pour indexer un fichier ou pour d'autres actions telles que marquer comme résolus des conflits de fusion de fichiers).
@@ -153,13 +154,13 @@ Lançons maintenant `git add` pour indexer le fichier `benchmarks.rb`, et relan
 
 	$ git add benchmarks.rb
 	$ git status
-	# On branch master
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#	new file:   LISEZMOI
-	#	modified:   benchmarks.rb
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+
+	        new file:   LISEZMOI
+	        modified:   benchmarks.rb
+
 
 À présent, les deux fichiers sont indexés et feront partie de la prochaine validation.
 Mais supposons que vous souhaitiez apporter encore une petite modification au fichier `benchmarks.rb` avant de réellement valider la nouvelle version.
@@ -168,18 +169,19 @@ Néanmoins, vous lancez `git status` une dernière fois :
 
 	$ vim benchmarks.rb
 	$ git status
-	# On branch master
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#	new file:   LISEZMOI
-	#	modified:   benchmarks.rb
-	#
-	# Changes not staged for commit:
-	#   (use "git add <file>..." to update what will be committed)
-	#
-	#	modified:   benchmarks.rb
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+
+	        new file:   LISEZMOI
+	        modified:   benchmarks.rb
+
+	Changes not staged for commit:
+	  (use "git add <file>..." to update what will be committed)
+	  (use "git checkout -- <file>..." to discard changes in working directory)
+
+	        modified:   benchmarks.rb
+
 
 Que s'est-il donc passé ? À présent, `benchmarks.rb` apparaît à la fois comme indexé et non indexé.
 En fait, Git indexe un fichier dans son état au moment où la commande `git add` est lancée.
@@ -188,13 +190,13 @@ Si le fichier est modifié après un `git add`, il faut relancer `git add` pour
 
 	$ git add benchmarks.rb
 	$ git status
-	# On branch master
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#	new file:   LISEZMOI
-	#	modified:   benchmarks.rb
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+
+	        new file:   LISEZMOI
+	        modified:   benchmarks.rb
+
 
 ### Ignorer des fichiers ###
 
@@ -249,17 +251,18 @@ Supposons que vous éditez et indexez le fichier `LISEZMOI` et que vous éditez
 Si vous lancez la commande `git status`, vous verrez ceci :
 
 	$ git status
-	# On branch master
-	# Changes to be committed:
-	#   (use "git reset HEAD <file>..." to unstage)
-	#
-	#	new file:   LISEZMOI
-	#
-	# Changes not staged for commit:
-	#   (use "git add <file>..." to update what will be committed)
-	#
-	#	modified:   benchmarks.rb
-	#
+	On branch master
+	Changes to be committed:
+	  (use "git reset HEAD <file>..." to unstage)
+
+	        new file:   LISEZMOI
+
+	Changes not staged for commit:
+	  (use "git add <file>..." to update what will be committed)
+	  (use "git checkout -- <file>..." to discard changes in working directory)
+
+	        modified:   benchmarks.rb
+
 
 Pour visualiser ce qui a été modifié mais pas encore indexé, tapez `git diff` sans autre argument :
 

From 281cdffb19186b511af0611ac7fbf614f947b11f Mon Sep 17 00:00:00 2001
From: Hosein <hosein@hosein-K53SD>
Date: Wed, 27 Aug 2014 16:05:22 +0430
Subject: [PATCH 600/690] Signed-off-by: Hosein <hosein@hosein-K53SD>

---
 fa/04-git-server/01-chapter4.markdown | 872 ++++++++++++++++++++++++++
 1 file changed, 872 insertions(+)
 create mode 100644 fa/04-git-server/01-chapter4.markdown

diff --git a/fa/04-git-server/01-chapter4.markdown b/fa/04-git-server/01-chapter4.markdown
new file mode 100644
index 000000000..538ff671d
--- /dev/null
+++ b/fa/04-git-server/01-chapter4.markdown
@@ -0,0 +1,872 @@
+#Git  روی سرور#
+	در این نقطه، شما باید توانایی انجام کارهای روزانه ای را که قصد دارید با Git انجام دهید، داشته باشید. بااین وجود، برای همکاری با دیگران در Git ، به یک مخزن خارجی Git  نیاز دارید.
+
+At this point, you should be able to do most of the day-to-day tasks for which you’ll be using Git. However, in order to do any collaboration in Git, you’ll need to have a remote Git repository. Although you can technically push changes to and pull changes from individuals’ repositories, doing so is discouraged because you can fairly easily confuse what they’re working on if you’re not careful. Furthermore, you want your collaborators to be able to access the repository even if your computer is offline — having a more reliable common repository is often useful. Therefore, the preferred method for collaborating with someone is to set up an intermediate repository that you both have access to, and push to and pull from that. We’ll refer to this repository as a "Git server"; but you’ll notice that it generally takes a tiny amount of resources to host a Git repository, so you’ll rarely need to use an entire server for it.
+
+Running a Git server is simple. First, you choose which protocols you want your server to communicate with. The first section of this chapter will cover the available protocols and the pros and cons of each. The next sections will explain some typical setups using those protocols and how to get your server running with them. Last, we’ll go over a few hosted options, if you don’t mind hosting your code on someone else’s server and don’t want to go through the hassle of setting up and maintaining your own server.
+
+If you have no interest in running your own server, you can skip to the last section of the chapter to see some options for setting up a hosted account and then move on to the next chapter, where we discuss the various ins and outs of working in a distributed source control environment.
+
+A remote repository is generally a _bare repository_ — a Git repository that has no working directory. Because the repository is only used as a collaboration point, there is no reason to have a snapshot checked out on disk; it’s just the Git data. In the simplest terms, a bare repository is the contents of your project’s `.git` directory and nothing else.
+
+## The Protocols ##
+
+Git can use four major network protocols to transfer data: Local, Secure Shell (SSH), Git, and HTTP. Here we’ll discuss what they are and in what basic circumstances you would want (or not want) to use them.
+
+It’s important to note that with the exception of the HTTP protocols, all of these require Git to be installed and working on the server.
+
+### Local Protocol ###
+
+The most basic is the _Local protocol_, in which the remote repository is in another directory on disk. This is often used if everyone on your team has access to a shared filesystem such as an NFS mount, or in the less likely case that everyone logs in to the same computer. The latter wouldn’t be ideal, because all your code repository instances would reside on the same computer, making a catastrophic loss much more likely.
+
+If you have a shared mounted filesystem, then you can clone, push to, and pull from a local file-based repository. To clone a repository like this or to add one as a remote to an existing project, use the path to the repository as the URL. For example, to clone a local repository, you can run something like this:
+
+	$ git clone /opt/git/project.git
+
+Or you can do this:
+
+	$ git clone file:///opt/git/project.git
+
+Git operates slightly differently if you explicitly specify `file://` at the beginning of the URL. If you just specify the path, and the source and the destination are on the same filesystem, Git tries to hardlink the objects it needs. If they are not on the same filesystem, it will copy the objects it needs using the system's standard copying functionality. If you specify `file://`, Git fires up the processes that it normally uses to transfer data over a network which is generally a lot less efficient method of transferring the data. The main reason to specify the `file://` prefix is if you want a clean copy of the repository with extraneous references or objects left out — generally after an import from another version-control system or something similar (see Chapter 9 for maintenance tasks). We’ll use the normal path here because doing so is almost always faster.
+
+To add a local repository to an existing Git project, you can run something like this:
+
+	$ git remote add local_proj /opt/git/project.git
+
+Then, you can push to and pull from that remote as though you were doing so over a network.
+
+#### The Pros ####
+
+The pros of file-based repositories are that they’re simple and they use existing file permissions and network access. If you already have a shared filesystem to which your whole team has access, setting up a repository is very easy. You stick the bare repository copy somewhere everyone has shared access to and set the read/write permissions as you would for any other shared directory. We’ll discuss how to export a bare repository copy for this purpose in the next section, “Getting Git on a Server.”
+
+This is also a nice option for quickly grabbing work from someone else’s working repository. If you and a co-worker are working on the same project and they want you to check something out, running a command like `git pull /home/john/project` is often easier than them pushing to a remote server and you pulling down.
+
+#### The Cons ####
+
+The cons of this method are that shared access is generally more difficult to set up and reach from multiple locations than basic network access. If you want to push from your laptop when you’re at home, you have to mount the remote disk, which can be difficult and slow compared to network-based access.
+
+It’s also important to mention that this isn’t necessarily the fastest option if you’re using a shared mount of some kind. A local repository is fast only if you have fast access to the data. A repository on NFS is often slower than the repository over SSH on the same server, allowing Git to run off local disks on each system.
+
+### The SSH Protocol ###
+
+Probably the most common transport protocol for Git is SSH. This is because SSH access to servers is already set up in most places — and if it isn’t, it’s easy to do. SSH is also the only network-based protocol that you can easily read from and write to. The other two network protocols (HTTP and Git) are generally read-only, so even if you have them available for the unwashed masses, you still need SSH for your own write commands. SSH is also an authenticated network protocol; and because it’s ubiquitous, it’s generally easy to set up and use.
+
+To clone a Git repository over SSH, you can specify ssh:// URL like this:
+
+	$ git clone ssh://user@server/project.git
+
+Or you can use the shorter scp-like syntax for SSH protocol:
+
+	$ git clone user@server:project.git
+
+You can also not specify a user, and Git assumes the user you’re currently logged in as.
+
+#### The Pros ####
+
+The pros of using SSH are many. First, you basically have to use it if you want authenticated write access to your repository over a network. Second, SSH is relatively easy to set up — SSH daemons are commonplace, many network admins have experience with them, and many OS distributions are set up with them or have tools to manage them. Next, access over SSH is secure — all data transfer is encrypted and authenticated. Last, like the Git and Local protocols, SSH is efficient, making the data as compact as possible before transferring it.
+
+#### The Cons ####
+
+The negative aspect of SSH is that you can’t serve anonymous access of your repository over it. People must have access to your machine over SSH to access it, even in a read-only capacity, which doesn’t make SSH access conducive to open source projects. If you’re using it only within your corporate network, SSH may be the only protocol you need to deal with. If you want to allow anonymous read-only access to your projects, you’ll have to set up SSH for you to push over but something else for others to pull over.
+
+### The Git Protocol ###
+
+Next is the Git protocol. This is a special daemon that comes packaged with Git; it listens on a dedicated port (9418) that provides a service similar to the SSH protocol, but with absolutely no authentication. In order for a repository to be served over the Git protocol, you must create the `git-daemon-export-ok` file — the daemon won’t serve a repository without that file in it — but other than that there is no security. Either the Git repository is available for everyone to clone or it isn’t. This means that there is generally no pushing over this protocol. You can enable push access; but given the lack of authentication, if you turn on push access, anyone on the internet who finds your project’s URL could push to your project. Suffice it to say that this is rare.
+
+#### The Pros ####
+
+The Git protocol is the fastest transfer protocol available. If you’re serving a lot of traffic for a public project or serving a very large project that doesn’t require user authentication for read access, it’s likely that you’ll want to set up a Git daemon to serve your project. It uses the same data-transfer mechanism as the SSH protocol but without the encryption and authentication overhead.
+
+#### The Cons ####
+
+The downside of the Git protocol is the lack of authentication. It’s generally undesirable for the Git protocol to be the only access to your project. Generally, you’ll pair it with SSH access for the few developers who have push (write) access and have everyone else use `git://` for read-only access.
+It’s also probably the most difficult protocol to set up. It must run its own daemon, which is custom — we’ll look at setting one up in the “Gitosis” section of this chapter — it requires `xinetd` configuration or the like, which isn’t always a walk in the park. It also requires firewall access to port 9418, which isn’t a standard port that corporate firewalls always allow. Behind big corporate firewalls, this obscure port is commonly blocked.
+
+### The HTTP/S Protocol ###
+
+Last we have the HTTP protocol. The beauty of the HTTP or HTTPS protocol is the simplicity of setting it up. Basically, all you have to do is put the bare Git repository under your HTTP document root and set up a specific `post-update` hook, and you’re done (See Chapter 7 for details on Git hooks). At that point, anyone who can access the web server under which you put the repository can also clone your repository. To allow read access to your repository over HTTP, do something like this:
+
+	$ cd /var/www/htdocs/
+	$ git clone --bare /path/to/git_project gitproject.git
+	$ cd gitproject.git
+	$ mv hooks/post-update.sample hooks/post-update
+	$ chmod a+x hooks/post-update
+
+That’s all. The `post-update` hook that comes with Git by default runs the appropriate command (`git update-server-info`) to make HTTP fetching and cloning work properly. This command is run when you push to this repository over SSH; then, other people can clone via something like
+
+	$ git clone http://example.com/gitproject.git
+
+In this particular case, we’re using the `/var/www/htdocs` path that is common for Apache setups, but you can use any static web server — just put the bare repository in its path. The Git data is served as basic static files (see Chapter 9 for details about exactly how it’s served).
+
+It’s possible to make Git push over HTTP as well, although that technique isn’t as widely used and requires you to set up complex WebDAV requirements. Because it’s rarely used, we won’t cover it in this book. If you’re interested in using the HTTP-push protocols, you can read about preparing a repository for this purpose at `http://www.kernel.org/pub/software/scm/git/docs/howto/setup-git-server-over-http.txt`. One nice thing about making Git push over HTTP is that you can use any WebDAV server, without specific Git features; so, you can use this functionality if your web-hosting provider supports WebDAV for writing updates to your web site.
+
+#### The Pros ####
+
+The upside of using the HTTP protocol is that it’s easy to set up. Running the handful of required commands gives you a simple way to give the world read access to your Git repository. It takes only a few minutes to do. The HTTP protocol also isn’t very resource intensive on your server. Because it generally uses a static HTTP server to serve all the data, a normal Apache server can serve thousands of files per second on average — it’s difficult to overload even a small server.
+
+You can also serve your repositories read-only over HTTPS, which means you can encrypt the content transfer; or you can go so far as to make the clients use specific signed SSL certificates. Generally, if you’re going to these lengths, it’s easier to use SSH public keys; but it may be a better solution in your specific case to use signed SSL certificates or other HTTP-based authentication methods for read-only access over HTTPS.
+
+Another nice thing is that HTTP is such a commonly used protocol that corporate firewalls are often set up to allow traffic through this port.
+
+#### The Cons ####
+
+The downside of serving your repository over HTTP is that it’s relatively inefficient for the client. It generally takes a lot longer to clone or fetch from the repository, and you often have a lot more network overhead and transfer volume over HTTP than with any of the other network protocols. Because it’s not as intelligent about transferring only the data you need — there is no dynamic work on the part of the server in these transactions — the HTTP protocol is often referred to as a _dumb_ protocol. For more information about the differences in efficiency between the HTTP protocol and the other protocols, see Chapter 9.
+
+## Getting Git on a Server ##
+
+In order to initially set up any Git server, you have to export an existing repository into a new bare repository — a repository that doesn’t contain a working directory. This is generally straightforward to do.
+In order to clone your repository to create a new bare repository, you run the clone command with the `--bare` option. By convention, bare repository directories end in `.git`, like so:
+
+	$ git clone --bare my_project my_project.git
+	Cloning into bare repository 'my_project.git'...
+	done.
+
+You should now have a copy of the Git directory data in your `my_project.git` directory.
+
+This is roughly equivalent to something like
+
+	$ cp -Rf my_project/.git my_project.git
+
+There are a couple of minor differences in the configuration file; but for your purpose, this is close to the same thing. It takes the Git repository by itself, without a working directory, and creates a directory specifically for it alone.
+
+### Putting the Bare Repository on a Server ###
+
+Now that you have a bare copy of your repository, all you need to do is put it on a server and set up your protocols. Let’s say you’ve set up a server called `git.example.com` that you have SSH access to, and you want to store all your Git repositories under the `/opt/git` directory. You can set up your new repository by copying your bare repository over:
+
+	$ scp -r my_project.git user@git.example.com:/opt/git
+
+At this point, other users who have SSH access to the same server which has read-access to the `/opt/git` directory can clone your repository by running
+
+	$ git clone user@git.example.com:/opt/git/my_project.git
+
+If a user SSHs into a server and has write access to the `/opt/git/my_project.git` directory, they will also automatically have push access.  Git will automatically add group write permissions to a repository properly if you run the `git init` command with the `--shared` option.
+
+	$ ssh user@git.example.com
+	$ cd /opt/git/my_project.git
+	$ git init --bare --shared
+
+You see how easy it is to take a Git repository, create a bare version, and place it on a server to which you and your collaborators have SSH access. Now you’re ready to collaborate on the same project.
+
+It’s important to note that this is literally all you need to do to run a useful Git server to which several people have access — just add SSH-able accounts on a server, and stick a bare repository somewhere that all those users have read and write access to. You’re ready to go — nothing else needed.
+
+In the next few sections, you’ll see how to expand to more sophisticated setups. This discussion will include not having to create user accounts for each user, adding public read access to repositories, setting up web UIs, using the Gitosis tool, and more. However, keep in mind that to collaborate with a couple of people on a private project, all you _need_ is an SSH server and a bare repository.
+
+### Small Setups ###
+
+If you’re a small outfit or are just trying out Git in your organization and have only a few developers, things can be simple for you. One of the most complicated aspects of setting up a Git server is user management. If you want some repositories to be read-only to certain users and read/write to others, access and permissions can be a bit difficult to arrange.
+
+#### SSH Access ####
+
+If you already have a server to which all your developers have SSH access, it’s generally easiest to set up your first repository there, because you have to do almost no work (as we covered in the last section). If you want more complex access control type permissions on your repositories, you can handle them with the normal filesystem permissions of the operating system your server runs.
+
+If you want to place your repositories on a server that doesn’t have accounts for everyone on your team whom you want to have write access, then you must set up SSH access for them. We assume that if you have a server with which to do this, you already have an SSH server installed, and that’s how you’re accessing the server.
+
+There are a few ways you can give access to everyone on your team. The first is to set up accounts for everybody, which is straightforward but can be cumbersome. You may not want to run `adduser` and set temporary passwords for every user.
+
+A second method is to create a single 'git' user on the machine, ask every user who is to have write access to send you an SSH public key, and add that key to the `~/.ssh/authorized_keys` file of your new 'git' user. At that point, everyone will be able to access that machine via the 'git' user. This doesn’t affect the commit data in any way — the SSH user you connect as doesn’t affect the commits you’ve recorded.
+
+Another way to do it is to have your SSH server authenticate from an LDAP server or some other centralized authentication source that you may already have set up. As long as each user can get shell access on the machine, any SSH authentication mechanism you can think of should work.
+
+## Generating Your SSH Public Key ##
+
+That being said, many Git servers authenticate using SSH public keys. In order to provide a public key, each user in your system must generate one if they don’t already have one. This process is similar across all operating systems.
+First, you should check to make sure you don’t already have a key. By default, a user’s SSH keys are stored in that user’s `~/.ssh` directory. You can easily check to see if you have a key already by going to that directory and listing the contents:
+
+	$ cd ~/.ssh
+	$ ls
+	authorized_keys2  id_dsa       known_hosts
+	config            id_dsa.pub
+
+You’re looking for a pair of files named something and something.pub, where the something is usually `id_dsa` or `id_rsa`. The `.pub` file is your public key, and the other file is your private key. If you don’t have these files (or you don’t even have a `.ssh` directory), you can create them by running a program called `ssh-keygen`, which is provided with the SSH package on Linux/Mac systems and comes with the MSysGit package on Windows:
+
+	$ ssh-keygen
+	Generating public/private rsa key pair.
+	Enter file in which to save the key (/Users/schacon/.ssh/id_rsa):
+	Enter passphrase (empty for no passphrase):
+	Enter same passphrase again:
+	Your identification has been saved in /Users/schacon/.ssh/id_rsa.
+	Your public key has been saved in /Users/schacon/.ssh/id_rsa.pub.
+	The key fingerprint is:
+	43:c5:5b:5f:b1:f1:50:43:ad:20:a6:92:6a:1f:9a:3a schacon@agadorlaptop.local
+
+First it confirms where you want to save the key (`.ssh/id_rsa`), and then it asks twice for a passphrase, which you can leave empty if you don’t want to type a password when you use the key.
+
+Now, each user that does this has to send their public key to you or whoever is administrating the Git server (assuming you’re using an SSH server setup that requires public keys). All they have to do is copy the contents of the `.pub` file and e-mail it. The public keys look something like this:
+
+	$ cat ~/.ssh/id_rsa.pub
+	ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAklOUpkDHrfHY17SbrmTIpNLTGK9Tjom/BWDSU
+	GPl+nafzlHDTYW7hdI4yZ5ew18JH4JW9jbhUFrviQzM7xlELEVf4h9lFX5QVkbPppSwg0cda3
+	Pbv7kOdJ/MTyBlWXFCR+HAo3FXRitBqxiX1nKhXpHAZsMciLq8V6RjsNAQwdsdMFvSlVK/7XA
+	t3FaoJoAsncM1Q9x5+3V0Ww68/eIFmb1zuUFljQJKprrX88XypNDvjYNby6vw/Pb0rwert/En
+	mZ+AW4OZPnTPI89ZPmVMLuayrD2cE86Z/il8b+gw3r3+1nKatmIkjn2so1d01QraTlMqVSsbx
+	NrRFi9wrf+M7Q== schacon@agadorlaptop.local
+
+For a more in-depth tutorial on creating an SSH key on multiple operating systems, see the GitHub guide on SSH keys at `http://github.com/guides/providing-your-ssh-key`.
+
+## Setting Up the Server ##
+
+Let’s walk through setting up SSH access on the server side. In this example, you’ll use the `authorized_keys` method for authenticating your users. We also assume you’re running a standard Linux distribution like Ubuntu. First, you create a 'git' user and a `.ssh` directory for that user.
+
+	$ sudo adduser git
+	$ su git
+	$ cd
+	$ mkdir .ssh
+
+Next, you need to add some developer SSH public keys to the `authorized_keys` file for that user. Let’s assume you’ve received a few keys by e-mail and saved them to temporary files. Again, the public keys look something like this:
+
+	$ cat /tmp/id_rsa.john.pub
+	ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCB007n/ww+ouN4gSLKssMxXnBOvf9LGt4L
+	ojG6rs6hPB09j9R/T17/x4lhJA0F3FR1rP6kYBRsWj2aThGw6HXLm9/5zytK6Ztg3RPKK+4k
+	Yjh6541NYsnEAZuXz0jTTyAUfrtU3Z5E003C4oxOj6H0rfIF1kKI9MAQLMdpGW1GYEIgS9Ez
+	Sdfd8AcCIicTDWbqLAcU4UpkaX8KyGlLwsNuuGztobF8m72ALC/nLF6JLtPofwFBlgc+myiv
+	O7TCUSBdLQlgMVOFq1I2uPWQOkOWQAHukEOmfjy2jctxSDBQ220ymjaNsHT4kgtZg2AYYgPq
+	dAv8JggJICUvax2T9va5 gsg-keypair
+
+You just append them to your `authorized_keys` file:
+
+	$ cat /tmp/id_rsa.john.pub >> ~/.ssh/authorized_keys
+	$ cat /tmp/id_rsa.josie.pub >> ~/.ssh/authorized_keys
+	$ cat /tmp/id_rsa.jessica.pub >> ~/.ssh/authorized_keys
+
+Key-based SSH authentication usually enforces security by requiring restricted rights on the involved files. To prevent SSH from refusing to work, type this:
+
+	$ chmod -R go= ~/.ssh
+
+Now, you can set up an empty repository for your users by running `git init` with the `--bare` option, which initializes the repository without a working directory:
+
+	$ cd /opt/git
+	$ mkdir project.git
+	$ cd project.git
+	$ git --bare init
+
+Then, John, Josie, or Jessica can push the first version of their project into that repository by adding it as a remote and pushing up a branch. Note that someone must shell onto the machine and create a bare repository every time you want to add a project. Let’s use `gitserver` as the hostname of the server on which you’ve set up your 'git' user and repository. If you’re running it internally, and you set up DNS for `gitserver` to point to that server, then you can use the commands pretty much as is:
+
+	# on Johns computer
+	$ cd myproject
+	$ git init
+	$ git add .
+	$ git commit -m 'initial commit'
+	$ git remote add origin git@gitserver:/opt/git/project.git
+	$ git push origin master
+
+At this point, the others can clone it down and push changes back up just as easily:
+
+	$ git clone git@gitserver:/opt/git/project.git
+	$ cd project
+	$ vim README
+	$ git commit -am 'fix for the README file'
+	$ git push origin master
+
+With this method, you can quickly get a read/write Git server up and running for a handful of developers.
+
+As an extra precaution, you can easily restrict the 'git' user to only doing Git activities with a limited shell tool called `git-shell` that comes with Git. If you set this as your 'git' user’s login shell, then the 'git' user can’t have normal shell access to your server. To use this, specify `git-shell` instead of bash or csh for your user’s login shell. To do so, you’ll likely have to edit your `/etc/passwd` file:
+
+	$ sudo vim /etc/passwd
+
+At the bottom, you should find a line that looks something like this:
+
+	git:x:1000:1000::/home/git:/bin/sh
+
+Change `/bin/sh` to `/usr/bin/git-shell` (or run `which git-shell` to see where it’s installed). The line should look something like this:
+
+	git:x:1000:1000::/home/git:/usr/bin/git-shell
+
+Now, the 'git' user can only use the SSH connection to push and pull Git repositories and can’t shell onto the machine. If you try, you’ll see a login rejection like this:
+
+	$ ssh git@gitserver
+	fatal: What do you think I am? A shell?
+	Connection to gitserver closed.
+
+## Public Access ##
+
+What if you want anonymous read access to your project? Perhaps instead of hosting an internal private project, you want to host an open source project. Or maybe you have a bunch of automated build servers or continuous integration servers that change a lot, and you don’t want to have to generate SSH keys all the time — you just want to add simple anonymous read access.
+
+Probably the simplest way for smaller setups is to run a static web server with its document root where your Git repositories are, and then enable that `post-update` hook we mentioned in the first section of this chapter. Let’s work from the previous example. Say you have your repositories in the `/opt/git` directory, and an Apache server is running on your machine. Again, you can use any web server for this; but as an example, we’ll demonstrate some basic Apache configurations that should give you an idea of what you might need.
+
+First you need to enable the hook:
+
+	$ cd project.git
+	$ mv hooks/post-update.sample hooks/post-update
+	$ chmod a+x hooks/post-update
+
+What does this `post-update` hook do? It looks basically like this:
+
+	$ cat .git/hooks/post-update
+	#!/bin/sh
+	#
+	# An example hook script to prepare a packed repository for use over
+	# dumb transports.
+	#
+	# To enable this hook, rename this file to "post-update".
+	#
+	
+	exec git-update-server-info
+
+This means that when you push to the server via SSH, Git will run this command to update the files needed for HTTP fetching.
+
+Next, you need to add a VirtualHost entry to your Apache configuration with the document root as the root directory of your Git projects. Here, we’re assuming that you have wildcard DNS set up to send `*.gitserver` to whatever box you’re using to run all this:
+
+	<VirtualHost *:80>
+	    ServerName git.gitserver
+	    DocumentRoot /opt/git
+	    <Directory /opt/git/>
+	        Order allow, deny
+	        allow from all
+	    </Directory>
+	</VirtualHost>
+
+You’ll also need to set the Unix user group of the `/opt/git` directories to `www-data` so your web server can read-access the repositories, because the Apache instance running the CGI script will (by default) be running as that user:
+
+	$ chgrp -R www-data /opt/git
+
+When you restart Apache, you should be able to clone your repositories under that directory by specifying the URL for your project:
+
+	$ git clone http://git.gitserver/project.git
+
+This way, you can set up HTTP-based read access to any of your projects for a fair number of users in a few minutes. Another simple option for public unauthenticated access is to start a Git daemon, although that requires you to daemonize the process - we’ll cover this option in the next section, if you prefer that route.
+
+## GitWeb ##
+
+Now that you have basic read/write and read-only access to your project, you may want to set up a simple web-based visualizer. Git comes with a CGI script called GitWeb that is commonly used for this. You can see GitWeb in use at sites like `http://git.kernel.org` (see Figure 4-1).
+
+Insert 18333fig0401.png
+Figure 4-1. The GitWeb web-based user interface.
+
+If you want to check out what GitWeb would look like for your project, Git comes with a command to fire up a temporary instance if you have a lightweight server on your system like `lighttpd` or `webrick`. On Linux machines, `lighttpd` is often installed, so you may be able to get it to run by typing `git instaweb` in your project directory. If you’re running a Mac, Leopard comes preinstalled with Ruby, so `webrick` may be your best bet. To start `instaweb` with a non-lighttpd handler, you can run it with the `--httpd` option.
+
+	$ git instaweb --httpd=webrick
+	[2009-02-21 10:02:21] INFO  WEBrick 1.3.1
+	[2009-02-21 10:02:21] INFO  ruby 1.8.6 (2008-03-03) [universal-darwin9.0]
+
+That starts up an HTTPD server on port 1234 and then automatically starts a web browser that opens on that page. It’s pretty easy on your part. When you’re done and want to shut down the server, you can run the same command with the `--stop` option:
+
+	$ git instaweb --httpd=webrick --stop
+
+If you want to run the web interface on a server all the time for your team or for an open source project you’re hosting, you’ll need to set up the CGI script to be served by your normal web server. Some Linux distributions have a `gitweb` package that you may be able to install via `apt` or `yum`, so you may want to try that first. We’ll walk though installing GitWeb manually very quickly. First, you need to get the Git source code, which GitWeb comes with, and generate the custom CGI script:
+
+	$ git clone git://git.kernel.org/pub/scm/git/git.git
+	$ cd git/
+	$ make GITWEB_PROJECTROOT="/opt/git" \
+	        prefix=/usr gitweb
+	$ sudo cp -Rf gitweb /var/www/
+
+Notice that you have to tell the command where to find your Git repositories with the `GITWEB_PROJECTROOT` variable. Now, you need to make Apache use CGI for that script, for which you can add a VirtualHost:
+
+	<VirtualHost *:80>
+	    ServerName gitserver
+	    DocumentRoot /var/www/gitweb
+	    <Directory /var/www/gitweb>
+	        Options ExecCGI +FollowSymLinks +SymLinksIfOwnerMatch
+	        AllowOverride All
+	        order allow,deny
+	        Allow from all
+	        AddHandler cgi-script cgi
+	        DirectoryIndex gitweb.cgi
+	    </Directory>
+	</VirtualHost>
+
+Again, GitWeb can be served with any CGI capable web server; if you prefer to use something else, it shouldn’t be difficult to set up. At this point, you should be able to visit `http://gitserver/` to view your repositories online, and you can use `http://git.gitserver` to clone and fetch your repositories over HTTP.
+
+## Gitosis ##
+
+Keeping all users’ public keys in the `authorized_keys` file for access works well only for a while. When you have hundreds of users, it’s much more of a pain to manage that process. You have to shell onto the server each time, and there is no access control — everyone in the file has read and write access to every project.
+
+At this point, you may want to turn to a widely used software project called Gitosis. Gitosis is basically a set of scripts that help you manage the `authorized_keys` file as well as implement some simple access controls. The really interesting part is that the UI for this tool for adding people and determining access isn’t a web interface but a special Git repository. You set up the information in that project; and when you push it, Gitosis reconfigures the server based on that, which is cool.
+
+Installing Gitosis isn’t the simplest task ever, but it’s not too difficult. It’s easiest to use a Linux server for it — these examples use a stock Ubuntu 8.10 server.
+
+Gitosis requires some Python tools, so first you have to install the Python setuptools package, which Ubuntu provides as python-setuptools:
+
+	$ apt-get install python-setuptools
+
+Next, you clone and install Gitosis from the project’s main site:
+
+	$ git clone https://github.com/tv42/gitosis.git
+	$ cd gitosis
+	$ sudo python setup.py install
+
+That installs a couple of executables that Gitosis will use. Next, Gitosis wants to put its repositories under `/home/git`, which is fine. But you have already set up your repositories in `/opt/git`, so instead of reconfiguring everything, you create a symlink:
+
+	$ ln -s /opt/git /home/git/repositories
+
+Gitosis is going to manage your keys for you, so you need to remove the current file, re-add the keys later, and let Gitosis control the `authorized_keys` file automatically. For now, move the `authorized_keys` file out of the way:
+
+	$ mv /home/git/.ssh/authorized_keys /home/git/.ssh/ak.bak
+
+Next you need to turn your shell back on for the 'git' user, if you changed it to the `git-shell` command. People still won’t be able to log in, but Gitosis will control that for you. So, let’s change this line in your `/etc/passwd` file
+
+	git:x:1000:1000::/home/git:/usr/bin/git-shell
+
+back to this:
+
+	git:x:1000:1000::/home/git:/bin/sh
+
+Now it’s time to initialize Gitosis. You do this by running the `gitosis-init` command with your personal public key. If your public key isn’t on the server, you’ll have to copy it there:
+
+	$ sudo -H -u git gitosis-init < /tmp/id_dsa.pub
+	Initialized empty Git repository in /opt/git/gitosis-admin.git/
+	Reinitialized existing Git repository in /opt/git/gitosis-admin.git/
+
+This lets the user with that key modify the main Git repository that controls the Gitosis setup. Next, you have to manually set the execute bit on the `post-update` script for your new control repository.
+
+	$ sudo chmod 755 /opt/git/gitosis-admin.git/hooks/post-update
+
+You’re ready to roll. If you’re set up correctly, you can try to SSH into your server as the user for which you added the public key to initialize Gitosis. You should see something like this:
+
+	$ ssh git@gitserver
+	PTY allocation request failed on channel 0
+	ERROR:gitosis.serve.main:Need SSH_ORIGINAL_COMMAND in environment.
+	  Connection to gitserver closed.
+
+That means Gitosis recognized you but shut you out because you’re not trying to do any Git commands. So, let’s do an actual Git command — you’ll clone the Gitosis control repository:
+
+	# on your local computer
+	$ git clone git@gitserver:gitosis-admin.git
+
+Now you have a directory named `gitosis-admin`, which has two major parts:
+
+	$ cd gitosis-admin
+	$ find .
+	./gitosis.conf
+	./keydir
+	./keydir/scott.pub
+
+The `gitosis.conf` file is the control file you use to specify users, repositories, and permissions. The `keydir` directory is where you store the public keys of all the users who have any sort of access to your repositories — one file per user. The name of the file in `keydir` (in the previous example, `scott.pub`) will be different for you — Gitosis takes that name from the description at the end of the public key that was imported with the `gitosis-init` script.
+
+If you look at the `gitosis.conf` file, it should only specify information about the `gitosis-admin` project that you just cloned:
+
+	$ cat gitosis.conf
+	[gitosis]
+
+	[group gitosis-admin]
+	members = scott
+	writable = gitosis-admin
+
+It shows you that the 'scott' user — the user with whose public key you initialized Gitosis — is the only one who has access to the `gitosis-admin` project.
+
+Now, let’s add a new project for you. You’ll add a new section called `mobile` where you’ll list the developers on your mobile team and projects that those developers need access to. Because 'scott' is the only user in the system right now, you’ll add him as the only member, and you’ll create a new project called `iphone_project` to start on:
+
+	[group mobile]
+	members = scott
+	writable = iphone_project
+
+Whenever you make changes to the `gitosis-admin` project, you have to commit the changes and push them back up to the server in order for them to take effect:
+
+	$ git commit -am 'add iphone_project and mobile group'
+	[master 8962da8] add iphone_project and mobile group
+	 1 file changed, 4 insertions(+)
+	$ git push origin master
+	Counting objects: 5, done.
+	Compressing objects: 100% (3/3), done.
+	Writing objects: 100% (3/3), 272 bytes | 0 bytes/s, done.
+	Total 3 (delta 0), reused 0 (delta 0)
+	To git@gitserver:gitosis-admin.git
+	   fb27aec..8962da8  master -> master
+
+You can make your first push to the new `iphone_project` project by adding your server as a remote to your local version of the project and pushing. You no longer have to manually create a bare repository for new projects on the server — Gitosis creates them automatically when it sees the first push:
+
+	$ git remote add origin git@gitserver:iphone_project.git
+	$ git push origin master
+	Initialized empty Git repository in /opt/git/iphone_project.git/
+	Counting objects: 3, done.
+	Writing objects: 100% (3/3), 230 bytes | 0 bytes/s, done.
+	Total 3 (delta 0), reused 0 (delta 0)
+	To git@gitserver:iphone_project.git
+	 * [new branch]      master -> master
+
+Notice that you don’t need to specify the path (in fact, doing so won’t work), just a colon and then the name of the project — Gitosis finds it for you.
+
+You want to work on this project with your friends, so you’ll have to re-add their public keys. But instead of appending them manually to the `~/.ssh/authorized_keys` file on your server, you’ll add them, one key per file, into the `keydir` directory. How you name the keys determines how you refer to the users in the `gitosis.conf` file. Let’s re-add the public keys for John, Josie, and Jessica:
+
+	$ cp /tmp/id_rsa.john.pub keydir/john.pub
+	$ cp /tmp/id_rsa.josie.pub keydir/josie.pub
+	$ cp /tmp/id_rsa.jessica.pub keydir/jessica.pub
+
+Now you can add them all to your 'mobile' team so they have read and write access to `iphone_project`:
+
+	[group mobile]
+	members = scott john josie jessica
+	writable = iphone_project
+
+After you commit and push that change, all four users will be able to read from and write to that project.
+
+Gitosis has simple access controls as well. If you want John to have only read access to this project, you can do this instead:
+
+	[group mobile]
+	members = scott josie jessica
+	writable = iphone_project
+
+	[group mobile_ro]
+	members = john
+	readonly = iphone_project
+
+Now John can clone the project and get updates, but Gitosis won’t allow him to push back up to the project. You can create as many of these groups as you want, each containing different users and projects. You can also specify another group as one of the members (using `@` as prefix), to inherit all of its members automatically:
+
+	[group mobile_committers]
+	members = scott josie jessica
+
+	[group mobile]
+	members   = @mobile_committers
+	writable  = iphone_project
+
+	[group mobile_2]
+	members   = @mobile_committers john
+	writable  = another_iphone_project
+
+If you have any issues, it may be useful to add `loglevel=DEBUG` under the `[gitosis]` section. If you’ve lost push access by pushing a messed-up configuration, you can manually fix the file on the server under `/home/git/.gitosis.conf` — the file from which Gitosis reads its info. A push to the project takes the `gitosis.conf` file you just pushed up and sticks it there. If you edit that file manually, it remains like that until the next successful push to the `gitosis-admin` project.
+
+## Gitolite ##
+
+This section serves as a quick introduction to Gitolite, and provides basic installation and setup instructions.  It cannot, however, replace the enormous amount of [documentation][gltoc] that Gitolite comes with.  There may also be occasional changes to this section itself, so you may also want to look at the latest version [here][gldpg].
+
+[gldpg]: http://sitaramc.github.com/gitolite/progit.html
+[gltoc]: http://sitaramc.github.com/gitolite/master-toc.html
+
+Gitolite is an authorization layer on top of Git, relying on `sshd` or `httpd` for authentication.  (Recap: authentication is identifying who the user is, authorization is deciding if he is allowed to do what he is attempting to).
+
+Gitolite allows you to specify permissions not just by repository, but also by branch or tag names within each repository.  That is, you can specify that certain people (or groups of people) can only push certain "refs" (branches or tags) but not others.
+
+### Installing ###
+
+Installing Gitolite is very easy, even if you don’t read the extensive documentation that comes with it.  You need an account on a Unix server of some kind.  You do not need root access, assuming Git, Perl, and an OpenSSH compatible SSH server are already installed.  In the examples below, we will use the `git` account on a host called `gitserver`.
+
+Gitolite is somewhat unusual as far as "server" software goes — access is via SSH, and so every userid on the server is a potential "gitolite host".  We will describe the simplest install method in this article; for the other methods please see the documentation.
+
+To begin, create a user called `git` on your server and login to this user.  Copy your SSH public key (a file called `~/.ssh/id_rsa.pub` if you did a plain `ssh-keygen` with all the defaults) from your workstation, renaming it to `<yourname>.pub` (we'll use `scott.pub` in our examples).  Then run these commands:
+
+	$ git clone git://github.com/sitaramc/gitolite
+	$ gitolite/install -ln
+	    # assumes $HOME/bin exists and is in your $PATH
+	$ gitolite setup -pk $HOME/scott.pub
+
+That last command creates new Git repository called `gitolite-admin` on the server.
+
+Finally, back on your workstation, run `git clone git@gitserver:gitolite-admin`. And you’re done!  Gitolite has now been installed on the server, and you now have a brand new repository called `gitolite-admin` in your workstation.  You administer your Gitolite setup by making changes to this repository and pushing.
+
+### Customising the Install ###
+
+While the default, quick, install works for most people, there are some ways to customise the install if you need to.  Some changes can be made simply by editing the rc file, but if that is not sufficient, there’s documentation on customising Gitolite.
+
+### Config File and Access Control Rules ###
+
+Once the install is done, you switch to the `gitolite-admin` clone you just made on your workstation, and poke around to see what you got:
+
+	$ cd ~/gitolite-admin/
+	$ ls
+	conf/  keydir/
+	$ find conf keydir -type f
+	conf/gitolite.conf
+	keydir/scott.pub
+	$ cat conf/gitolite.conf
+
+	repo gitolite-admin
+	    RW+                 = scott
+
+	repo testing
+	    RW+                 = @all
+
+Notice that "scott" (the name of the pubkey in the `gitolite setup` command you used earlier) has read-write permissions on the `gitolite-admin` repository as well as a public key file of the same name.
+
+Adding users is easy.  To add a user called "alice", obtain her public key, name it `alice.pub`, and put it in the `keydir` directory of the clone of the `gitolite-admin` repo you just made on your workstation.  Add, commit, and push the change, and the user has been added.
+
+The config file syntax for Gitolite is well documented, so we’ll only mention some highlights here.
+
+You can group users or repos for convenience.  The group names are just like macros; when defining them, it doesn’t even matter whether they are projects or users; that distinction is only made when you *use* the "macro".
+
+	@oss_repos      = linux perl rakudo git gitolite
+	@secret_repos   = fenestra pear
+
+	@admins         = scott
+	@interns        = ashok
+	@engineers      = sitaram dilbert wally alice
+	@staff          = @admins @engineers @interns
+
+You can control permissions at the "ref" level.  In the following example, interns can only push the "int" branch.  Engineers can push any branch whose name starts with "eng-", and tags that start with "rc" followed by a digit.  And the admins can do anything (including rewind) to any ref.
+
+	repo @oss_repos
+	    RW  int$                = @interns
+	    RW  eng-                = @engineers
+	    RW  refs/tags/rc[0-9]   = @engineers
+	    RW+                     = @admins
+
+The expression after the `RW` or `RW+` is a regular expression (regex) that the refname (ref) being pushed is matched against.  So we call it a "refex"!  Of course, a refex can be far more powerful than shown here, so don’t overdo it if you’re not comfortable with Perl regexes.
+
+Also, as you probably guessed, Gitolite prefixes `refs/heads/` as a syntactic convenience if the refex does not begin with `refs/`.
+
+An important feature of the config file’s syntax is that all the rules for a repository need not be in one place.  You can keep all the common stuff together, like the rules for all `oss_repos` shown above, then add specific rules for specific cases later on, like so:
+
+	repo gitolite
+	    RW+                     = sitaram
+
+That rule will just get added to the ruleset for the `gitolite` repository.
+
+At this point you might be wondering how the access control rules are actually applied, so let’s go over that briefly.
+
+There are two levels of access control in Gitolite.  The first is at the repository level; if you have read (or write) access to *any* ref in the repository, then you have read (or write) access to the repository.  This is the only access control that Gitosis had.
+
+The second level, applicable only to "write" access, is by branch or tag within a repository.  The username, the access being attempted (`W` or `+`), and the refname being updated are known.  The access rules are checked in order of appearance in the config file, looking for a match for this combination (but remember that the refname is regex-matched, not merely string-matched).  If a match is found, the push succeeds.  A fallthrough results in access being denied.
+
+### Advanced Access Control with "deny" rules ###
+
+So far, we’ve only seen permissions to be one of `R`, `RW`, or `RW+`.  However, Gitolite allows another permission: `-`, standing for "deny".  This gives you a lot more power, at the expense of some complexity, because now fallthrough is not the *only* way for access to be denied, so the *order of the rules now matters*!
+
+Let us say, in the situation above, we want engineers to be able to rewind any branch *except* master and integ.  Here’s how to do that:
+
+	    RW  master integ    = @engineers
+	    -   master integ    = @engineers
+	    RW+                 = @engineers
+
+Again, you simply follow the rules top down until you hit a match for your access mode, or a deny.  Non-rewind push to master or integ is allowed by the first rule.  A rewind push to those refs does not match the first rule, drops down to the second, and is therefore denied.  Any push (rewind or non-rewind) to refs other than master or integ won’t match the first two rules anyway, and the third rule allows it.
+
+### Restricting pushes by files changed ###
+
+In addition to restricting what branches a user can push changes to, you can also restrict what files they are allowed to touch.  For example, perhaps the Makefile (or some other program) is really not supposed to be changed by just anyone, because a lot of things depend on it or would break if the changes are not done *just right*.  You can tell Gitolite:
+
+    repo foo
+        RW                      =   @junior_devs @senior_devs
+
+        -   VREF/NAME/Makefile  =   @junior_devs
+
+Users who are migrating from the older Gitolite should note that there is a significant change in behaviour with regard to this feature; please see the migration guide for details.
+
+### Personal Branches ###
+
+Gitolite also has a feature called "personal branches" (or rather, "personal branch namespace") that can be very useful in a corporate environment.
+
+A lot of code exchange in the Git world happens by "please pull" requests.  In a corporate environment, however, unauthenticated access is a no-no, and a developer workstation cannot do authentication, so you have to push to the central server and ask someone to pull from there.
+
+This would normally cause the same branch name clutter as in a centralised VCS, plus setting up permissions for this becomes a chore for the admin.
+
+Gitolite lets you define a "personal" or "scratch" namespace prefix for each developer (for example, `refs/personal/<devname>/*`); please see the documentation for details.
+
+### "Wildcard" repositories ###
+
+Gitolite allows you to specify repositories with wildcards (actually Perl regexes), like, for example `assignments/s[0-9][0-9]/a[0-9][0-9]`, to pick a random example.  It also allows you to assign a new permission mode (`C`) which enables users to create repositories based on such wild cards, automatically assigns ownership to the specific user who created it, allows him/her to hand out `R` and `RW` permissions to other users to collaborate, etc.  Again, please see the documentation for details.
+
+### Other Features ###
+
+We’ll round off this discussion with a sampling of other features, all of which, and many more, are described in great detail in the documentation.
+
+**Logging**: Gitolite logs all successful accesses.  If you were somewhat relaxed about giving people rewind permissions (`RW+`) and some kid blew away `master`, the log file is a life saver, in terms of easily and quickly finding the SHA that got hosed.
+
+**Access rights reporting**: Another convenient feature is what happens when you try and just ssh to the server.  Gitolite shows you what repos you have access to, and what that access may be.  Here’s an example:
+
+        hello scott, this is git@git running gitolite3 v3.01-18-g9609868 on git 1.7.4.4
+
+             R     anu-wsd
+             R     entrans
+             R  W  git-notes
+             R  W  gitolite
+             R  W  gitolite-admin
+             R     indic_web_input
+             R     shreelipi_converter
+
+**Delegation**: For really large installations, you can delegate responsibility for groups of repositories to various people and have them manage those pieces independently.  This reduces the load on the main admin, and makes him less of a bottleneck.
+
+**Mirroring**: Gitolite can help you maintain multiple mirrors, and switch between them easily if the primary server goes down.
+
+## Git Daemon ##
+
+For public, unauthenticated read access to your projects, you’ll want to move past the HTTP protocol and start using the Git protocol. The main reason is speed. The Git protocol is far more efficient and thus faster than the HTTP protocol, so using it will save your users time.
+
+Again, this is for unauthenticated read-only access. If you’re running this on a server outside your firewall, it should only be used for projects that are publicly visible to the world. If the server you’re running it on is inside your firewall, you might use it for projects that a large number of people or computers (continuous integration or build servers) have read-only access to, when you don’t want to have to add an SSH key for each.
+
+In any case, the Git protocol is relatively easy to set up. Basically, you need to run this command in a daemonized manner:
+
+	git daemon --reuseaddr --base-path=/opt/git/ /opt/git/
+
+`--reuseaddr` allows the server to restart without waiting for old connections to time out, the `--base-path` option allows people to clone projects without specifying the entire path, and the path at the end tells the Git daemon where to look for repositories to export. If you’re running a firewall, you’ll also need to punch a hole in it at port 9418 on the box you’re setting this up on.
+
+You can daemonize this process a number of ways, depending on the operating system you’re running. On an Ubuntu machine, you use an Upstart script. So, in the following file
+
+	/etc/event.d/local-git-daemon
+
+you put this script:
+
+	start on startup
+	stop on shutdown
+	exec /usr/bin/git daemon \
+	    --user=git --group=git \
+	    --reuseaddr \
+	    --base-path=/opt/git/ \
+	    /opt/git/
+	respawn
+
+For security reasons, it is strongly encouraged to have this daemon run as a user with read-only permissions to the repositories — you can easily do this by creating a new user 'git-ro' and running the daemon as them.  For the sake of simplicity we’ll simply run it as the same 'git' user that Gitosis is running as.
+
+When you restart your machine, your Git daemon will start automatically and respawn if it goes down. To get it running without having to reboot, you can run this:
+
+	initctl start local-git-daemon
+
+On other systems, you may want to use `xinetd`, a script in your `sysvinit` system, or something else — as long as you get that command daemonized and watched somehow.
+
+Next, you have to tell your Gitosis server which repositories to allow unauthenticated Git server-based access to. If you add a section for each repository, you can specify the ones from which you want your Git daemon to allow reading. If you want to allow Git protocol access for the `iphone_project`, you add this to the end of the `gitosis.conf` file:
+
+	[repo iphone_project]
+	daemon = yes
+
+When that is committed and pushed up, your running daemon should start serving requests for the project to anyone who has access to port 9418 on your server.
+
+If you decide not to use Gitosis, but you want to set up a Git daemon, you’ll have to run this on each project you want the Git daemon to serve:
+
+	$ cd /path/to/project.git
+	$ touch git-daemon-export-ok
+
+The presence of that file tells Git that it’s OK to serve this project without authentication.
+
+Gitosis can also control which projects GitWeb shows. First, you need to add something like the following to the `/etc/gitweb.conf` file:
+
+	$projects_list = "/home/git/gitosis/projects.list";
+	$projectroot = "/home/git/repositories";
+	$export_ok = "git-daemon-export-ok";
+	@git_base_url_list = ('git://gitserver');
+
+You can control which projects GitWeb lets users browse by adding or removing a `gitweb` setting in the Gitosis configuration file. For instance, if you want the `iphone_project` to show up on GitWeb, you make the `repo` setting look like this:
+
+	[repo iphone_project]
+	daemon = yes
+	gitweb = yes
+
+Now, if you commit and push the project, GitWeb will automatically start showing the `iphone_project`.
+
+## Hosted Git ##
+
+If you don’t want to go through all of the work involved in setting up your own Git server, you have several options for hosting your Git projects on an external dedicated hosting site. Doing so offers a number of advantages: a hosting site is generally quick to set up and easy to start projects on, and no server maintenance or monitoring is involved. Even if you set up and run your own server internally, you may still want to use a public hosting site for your open source code — it’s generally easier for the open source community to find and help you with.
+
+These days, you have a huge number of hosting options to choose from, each with different advantages and disadvantages. To see an up-to-date list, check out the following page:
+
+	https://git.wiki.kernel.org/index.php/GitHosting
+
+Because we can’t cover all of them, and because I happen to work at one of them, we’ll use this section to walk through setting up an account and creating a new project at GitHub. This will give you an idea of what is involved.
+
+GitHub is by far the largest open source Git hosting site and it’s also one of the very few that offers both public and private hosting options so you can keep your open source and private commercial code in the same place. In fact, we used GitHub to privately collaborate on this book.
+
+### GitHub ###
+
+GitHub is slightly different than most code-hosting sites in the way that it namespaces projects. Instead of being primarily based on the project, GitHub is user-centric. That means when I host my `grit` project on GitHub, you won’t find it at `github.com/grit` but instead at `github.com/schacon/grit`. There is no canonical version of any project, which allows a project to move from one user to another seamlessly if the first author abandons the project.
+
+GitHub is also a commercial company that charges for accounts that maintain private repositories, but anyone can quickly get a free account to host as many open source projects as they want. We’ll quickly go over how that is done.
+
+### Setting Up a User Account ###
+
+The first thing you need to do is set up a free user account. If you visit the "Plans and pricing" page at `https://github.com/pricing` and click the "Sign Up" button on the Free account (see Figure 4-2), you’re taken to the signup page.
+
+Insert 18333fig0402.png
+Figure 4-2. The GitHub plan page.
+
+Here you must choose a username that isn’t yet taken in the system and enter an e-mail address that will be associated with the account and a password (see Figure 4-3).
+
+Insert 18333fig0403.png
+Figure 4-3. The GitHub user signup form.
+
+If you have it available, this is a good time to add your public SSH key as well. We covered how to generate a new key earlier, in the "Simple Setups" section. Take the contents of the public key of that pair, and paste it into the SSH Public Key text box. Clicking the "explain ssh keys" link takes you to detailed instructions on how to do so on all major operating systems.
+Clicking the "I agree, sign me up" button takes you to your new user dashboard (see Figure 4-4).
+
+Insert 18333fig0404.png
+Figure 4-4. The GitHub user dashboard.
+
+Next you can create a new repository.
+
+### Creating a New Repository ###
+
+Start by clicking the "create a new one" link next to Your Repositories on the user dashboard. You’re taken to the Create a New Repository form (see Figure 4-5).
+
+Insert 18333fig0405.png
+Figure 4-5. Creating a new repository on GitHub.
+
+All you really have to do is provide a project name, but you can also add a description. When that is done, click the "Create Repository" button. Now you have a new repository on GitHub (see Figure 4-6).
+
+Insert 18333fig0406.png
+Figure 4-6. GitHub project header information.
+
+Since you have no code there yet, GitHub will show you instructions for how create a brand-new project, push an existing Git project up, or import a project from a public Subversion repository (see Figure 4-7).
+
+Insert 18333fig0407.png
+Figure 4-7. Instructions for a new repository.
+
+These instructions are similar to what we’ve already gone over. To initialize a project if it isn’t already a Git project, you use
+
+	$ git init
+	$ git add .
+	$ git commit -m 'initial commit'
+
+When you have a Git repository locally, add GitHub as a remote and push up your master branch:
+
+	$ git remote add origin git@github.com:testinguser/iphone_project.git
+	$ git push origin master
+
+Now your project is hosted on GitHub, and you can give the URL to anyone you want to share your project with. In this case, it’s `http://github.com/testinguser/iphone_project`. You can also see from the header on each of your project’s pages that you have two Git URLs (see Figure 4-8).
+
+Insert 18333fig0408.png
+Figure 4-8. Project header with a public URL and a private URL.
+
+The Public Clone URL is a public, read-only Git URL over which anyone can clone the project. Feel free to give out that URL and post it on your web site or what have you.
+
+The Your Clone URL is a read/write SSH-based URL that you can read or write over only if you connect with the SSH private key associated with the public key you uploaded for your user. When other users visit this project page, they won’t see that URL—only the public one.
+
+### Importing from Subversion ###
+
+If you have an existing public Subversion project that you want to import into Git, GitHub can often do that for you. At the bottom of the instructions page is a link to a Subversion import. If you click it, you see a form with information about the import process and a text box where you can paste in the URL of your public Subversion project (see Figure 4-9).
+
+Insert 18333fig0409.png
+Figure 4-9. Subversion importing interface.
+
+If your project is very large, nonstandard, or private, this process probably won’t work for you. In Chapter 7, you’ll learn how to do more complicated manual project imports.
+
+### Adding Collaborators ###
+
+Let’s add the rest of the team. If John, Josie, and Jessica all sign up for accounts on GitHub, and you want to give them push access to your repository, you can add them to your project as collaborators. Doing so will allow pushes from their public keys to work.
+
+Click the "edit" button in the project header or the Admin tab at the top of the project to reach the Admin page of your GitHub project (see Figure 4-10).
+
+Insert 18333fig0410.png
+Figure 4-10. GitHub administration page.
+
+To give another user write access to your project, click the “Add another collaborator” link. A new text box appears, into which you can type a username. As you type, a helper pops up, showing you possible username matches. When you find the correct user, click the Add button to add that user as a collaborator on your project (see Figure 4-11).
+
+Insert 18333fig0411.png
+Figure 4-11. Adding a collaborator to your project.
+
+When you’re finished adding collaborators, you should see a list of them in the Repository Collaborators box (see Figure 4-12).
+
+Insert 18333fig0412.png
+Figure 4-12. A list of collaborators on your project.
+
+If you need to revoke access to individuals, you can click the "revoke" link, and their push access will be removed. For future projects, you can also copy collaborator groups by copying the permissions of an existing project.
+
+### Your Project ###
+
+After you push your project up or have it imported from Subversion, you have a main project page that looks something like Figure 4-13.
+
+Insert 18333fig0413.png
+Figure 4-13. A GitHub main project page.
+
+When people visit your project, they see this page. It contains tabs to different aspects of your projects. The Commits tab shows a list of commits in reverse chronological order, similar to the output of the `git log` command. The Network tab shows all the people who have forked your project and contributed back. The Downloads tab allows you to upload project binaries and link to tarballs and zipped versions of any tagged points in your project. The Wiki tab provides a wiki where you can write documentation or other information about your project. The Graphs tab has some contribution visualizations and statistics about your project. The main Source tab that you land on shows your project’s main directory listing and automatically renders the README file below it if you have one. This tab also shows a box with the latest commit information.
+
+### Forking Projects ###
+
+If you want to contribute to an existing project to which you don’t have push access, GitHub encourages forking the project. When you land on a project page that looks interesting and you want to hack on it a bit, you can click the "fork" button in the project header to have GitHub copy that project to your user so you can push to it.
+
+This way, projects don’t have to worry about adding users as collaborators to give them push access. People can fork a project and push to it, and the main project maintainer can pull in those changes by adding them as remotes and merging in their work.
+
+To fork a project, visit the project page (in this case, mojombo/chronic) and click the "fork" button in the header (see Figure 4-14).
+
+Insert 18333fig0414.png
+Figure 4-14. Get a writable copy of any repository by clicking the "fork" button.
+
+After a few seconds, you’re taken to your new project page, which indicates that this project is a fork of another one (see Figure 4-15).
+
+Insert 18333fig0415.png
+Figure 4-15. Your fork of a project.
+
+### GitHub Summary ###
+
+That’s all we’ll cover about GitHub, but it’s important to note how quickly you can do all this. You can create an account, add a new project, and push to it in a matter of minutes. If your project is open source, you also get a huge community of developers who now have visibility into your project and may well fork it and help contribute to it. At the very least, this may be a way to get up and running with Git and try it out quickly.
+
+## Summary ##
+
+You have several options to get a remote Git repository up and running so that you can collaborate with others or share your work.
+
+Running your own server gives you a lot of control and allows you to run the server within your own firewall, but such a server generally requires a fair amount of your time to set up and maintain. If you place your data on a hosted server, it’s easy to set up and maintain; however, you have to be able to keep your code on someone else’s servers, and some organizations don’t allow that.
+
+It should be fairly straightforward to determine which solution or combination of solutions is appropriate for you and your organization.

From e6294b6cfe8dca83b242519705ba7100616e834b Mon Sep 17 00:00:00 2001
From: Karol Jung <jungkarol@gmail.com>
Date: Wed, 27 Aug 2014 18:39:04 +0200
Subject: [PATCH 601/690] Translation of descriptions under illustrations.

---
 pl/01-introduction/01-chapter1.markdown    | 14 ++--
 pl/02-git-basics/02-chapter2.markdown      |  2 +-
 pl/03-git-branching/01-chapter3.markdown   | 84 +++++++++++-----------
 pl/04-git-server/01-chapter4.markdown      | 30 ++++----
 pl/05-distributed-git/01-chapter5.markdown | 54 +++++++-------
 pl/06-git-tools/01-chapter6.markdown       |  2 +-
 pl/07-customizing-git/01-chapter7.markdown |  6 +-
 pl/09-git-internals/01-chapter9.markdown   |  8 +--
 8 files changed, 100 insertions(+), 100 deletions(-)

diff --git a/pl/01-introduction/01-chapter1.markdown b/pl/01-introduction/01-chapter1.markdown
index 5ef367d64..8b6d4a909 100644
--- a/pl/01-introduction/01-chapter1.markdown
+++ b/pl/01-introduction/01-chapter1.markdown
@@ -15,7 +15,7 @@ Dla wielu ludzi preferowaną metodą kontroli wersji jest kopiowanie plików do
 Aby poradzić sobie z takimi problemami, programiści już dość dawno temu stworzyli lokalne systemy kontroli wersji, które składały się z prostej bazy danych w której przechowywane były wszystkie zmiany dokonane na śledzonych plikach (por. Rysunek 1-1).
 
 Insert 18333fig0101.png 
-Figure 1-1. Diagram lokalnego systemu kontroli wersji.
+Rysunek 1-1. Diagram lokalnego systemu kontroli wersji.
 
 Jednym z najbardziej popularnych narzędzi VCS był system rcs, który wciąż jest obecny na wielu dzisiejszych komputerach. Nawet w popularnym systemie operacyjnym Mac OS X rcs jest dostępny po zainstalowaniu Narzędzi Programistycznych (Developer Tools). Program ten działa zapisując, w specjalnym formacie na dysku, dane różnicowe (to jest zawierające jedynie różnice pomiędzy plikami) z każdej dokonanej modyfikacji. Używając tych danych jest w stanie przywołać stan pliku z dowolnego momentu.
 
@@ -24,7 +24,7 @@ Jednym z najbardziej popularnych narzędzi VCS był system rcs, który wciąż j
 Kolejnym poważnym problemem z którym można się spotkać jest potrzeba współpracy w rozwoju projektu z odrębnych systemów. Aby poradzić sobie z tym problemem stworzono scentralizowane systemy kontroli wersji (CVCS - Centralized Version Control System). Systemy takie jak CVS, Subversion czy Perforce składają się z jednego serwera, który zawiera wszystkie pliki poddane kontroli wersji, oraz klientów którzy mogą się z nim łączyć i uzyskać dostęp do najnowszych wersji plików. Przez wiele lat był to standardowy model kontroli wersji (por. Rysunek 1-2).
 
 Insert 18333fig0102.png 
-Figure 1-2. Diagram scentralizowanego systemu kontroli wersji.
+Rysunek 1-2. Diagram scentralizowanego systemu kontroli wersji.
 
 Taki schemat posiada wiele zalet, szczególnie w porównaniu z VCS. Dla przykładu każdy może się zorientować co robią inni uczestnicy projektu. Administratorzy mają dokładną kontrolę nad uprawnieniami poszczególnych użytkowników. Co więcej systemy CVCS są także dużo łatwiejsze w zarządzaniu niż lokalne bazy danych u każdego z klientów.
 
@@ -35,7 +35,7 @@ Niemniej systemy te mają także poważne wady. Najbardziej oczywistą jest prob
 W ten sposób dochodzimy do rozproszonych systemów kontroli wersji (DVCS - Distributed Version Control System). W systemach DVCS (takich jak Git, Mercurial, Bazaar lub Darcs) klienci nie dostają dostępu jedynie do najnowszych wersji plików ale w pełni kopiują całe repozytorium. Gdy jeden z serwerów, używanych przez te systemy do współpracy, ulegnie awarii, repozytorium każdego klienta może zostać po prostu skopiowane na ten serwer w celu przywrócenia go do pracy (por. Rysunek 1-3).
 
 Insert 18333fig0103.png 
-Figure 1-3. Diagram rozproszonego systemu kontroli wersji.
+Rysunek 1-3. Diagram rozproszonego systemu kontroli wersji.
 
 Co więcej, wiele z tych systemów dość dobrze radzi sobie z kilkoma zdalnymi repozytoriami, więc możliwa jest jednoczesna współpraca z różnymi grupami ludzi nad tym samym projektem. Daje to swobodę wykorzystania różnych schematów pracy, nawet takich które nie są możliwe w scentralizowanych systemach, na przykład modeli hierarchicznych.
 
@@ -62,12 +62,12 @@ Czym jest w skrócie Git? To jest bardzo istotna sekcja tej książki, ponieważ
 Podstawową różnicą pomiędzy Git a każdym innym systemem VCS (włączając w to Subversion) jest podejście Git do przechowywanych danych. Większość pozostałych systemów przechowuje informacje jako listę zmian na plikach. Systemy te (CVS, Subversion, Perforce, Bazaar i inne) traktują przechowywane informacje jako zbiór plików i zmian dokonanych na każdym z nich w okresie czasu. Obrazuje to Rysunek 1-4.
 
 Insert 18333fig0104.png 
-Figure 1-4. Inne system przechowują dane w postaci zmian do podstawowej wersji każdego z plików.
+Rysunek 1-4. Inne system przechowują dane w postaci zmian do podstawowej wersji każdego z plików.
 
 Git podchodzi do przechowywania danych w odmienny sposób. Traktuje on dane podobnie jak zestaw migawek (ang. snapshots) małego systemu plików. Za każdym razem jak tworzysz commit lub zapisujesz stan projektu, Git tworzy obraz przedstawiający to jak wyglądają wszystkie pliki w danym momencie i przechowuje referencję do tej migawki. W celu uzyskania dobrej wydajności, jeśli dany plik nie został zmieniony, Git nie zapisuje ponownie tego pliku, a tylko referencję do jego poprzedniej, identycznej wersji, która jest już zapisana. Git myśli o danych w sposób podobny do przedstawionego na Rysunku 1-5.
 
 Insert 18333fig0105.png 
-Figure 1-5. Git przechowuje dane jako migawki projektu w okresie czasu.
+Rysunek 1-5. Git przechowuje dane jako migawki projektu w okresie czasu.
 
 To jest istotna różnica pomiędzy Git i prawie wszystkimi innymi systemami VCS. Jej konsekwencją jest to, że Git rewiduje prawie wszystkie aspekty kontroli wersji, które pozostałe systemy po prostu kopiowały z poprzednich generacji. Powoduje także, że Git jest bardziej podobny do mini systemu plików ze zbudowanymi na nim potężnymi narzędziami, niż do zwykłego systemu VCS. Odkryjemy niektóre z zalet które zyskuje się poprzez myślenie o danych w ten sposób, gdy w trzecim rozdziale będziemy omawiać tworzenie gałęzi w Git.
 
@@ -102,7 +102,7 @@ Teraz uwaga. To jedna z najważniejszych spraw do zapamiętania jeśli chodzi o
 Z powyższego wynikają trzy główne sekcje projektu Git: katalog Git, katalog roboczy i przechowalnia (ang. staging area).
 
 Insert 18333fig0106.png 
-Figure 1-6. Katalog roboczy, przechowalnia, katalog git.
+Rysunek 1-6. Katalog roboczy, przechowalnia, katalog git.
 
 Katalog Git jest miejscem, w którym Git przechowuje własne metadane oraz obiektową bazę danych Twojego projektu. To najważniejsza część Git i to właśnie ten katalog jest kopiowany podczas klonowania repozytorium z innego komputera.
 
@@ -166,7 +166,7 @@ Istnieją dwa proste sposoby instalacji Git na komputerze Mac. Najprostszym z ni
 	http://sourceforge.net/projects/git-osx-installer/
 
 Insert 18333fig0107.png 
-Figure 1-7. Instalator Git dla OS X.
+Rysunek 1-7. Instalator Git dla OS X.
 
 Innym prostym sposobem jest instalacja Git z wykorzystaniem MacPorts (`http://www.macports.org`). Jeśli masz zainstalowane MacPorts, zainstaluj Git za pomocą
 
diff --git a/pl/02-git-basics/02-chapter2.markdown b/pl/02-git-basics/02-chapter2.markdown
index 3695a4541..ce2501c0b 100644
--- a/pl/02-git-basics/02-chapter2.markdown
+++ b/pl/02-git-basics/02-chapter2.markdown
@@ -47,7 +47,7 @@ Pamiętaj, że każdy plik w twoim katalogu roboczym może być w jednym z dwóc
 Kiedy zmieniasz pliki, Git rozpoznaje je jako zmodyfikowane, ponieważ różnią się od ostatniej zatwierdzonej zmiany. Zmodyfikowane pliki umieszczasz w poczekalni, a następnie zatwierdzasz oczekujące tam zmiany i tak powtarza się cały cykl. Przedstawia go Diagram 2-1.
 
 Insert 18333fig0201.png 
-Figure 2-1. Cykl życia stanu twoich plików.
+Rysunek 2-1. Cykl życia stanu twoich plików.
 
 ### Sprawdzanie stanu twoich plików ###
 
diff --git a/pl/03-git-branching/01-chapter3.markdown b/pl/03-git-branching/01-chapter3.markdown
index db73ebf01..3cba76b94 100644
--- a/pl/03-git-branching/01-chapter3.markdown
+++ b/pl/03-git-branching/01-chapter3.markdown
@@ -20,17 +20,17 @@ Kiedy zatwierdzasz zmiany przez uruchomienie polecenia `git commit`, Git liczy s
 Teraz repozytorium Gita zawiera już 5 obiektów: jeden blob dla zawartości każdego z trzech plików, jedno drzewo opisujące zawartość katalogu i określające, które pliki przechowywane są w których blobach, oraz jeden zestaw zmian ze wskaźnikiem na owo drzewo i wszystkimi metadanymi. Jeśli chodzi o ideę, dane w repozytorium Gita wyglądają jak na Rysunku 3-1.
 
 Insert 18333fig0301.png 
-Figure 3-1. Dane repozytorium z jedną zatwierdzoną zmianą.
+Rysunek 3-1. Dane repozytorium z jedną zatwierdzoną zmianą.
 
 Jeśli dokonasz zmian i je również zatwierdzisz, kolejne zatwierdzenie zachowa wskaźnik do zestawu zmian, który został utworzony bezpośrednio przed właśnie dodawanym. Po dwóch kolejnych zatwierdzeniach, Twoja historia może wyglądać podobnie do przedstawionej na Rysunku 3-2:
 
 Insert 18333fig0302.png 
-Figure 3-2. Dane Gita dla wielu zestawów zmian.
+Rysunek 3-2. Dane Gita dla wielu zestawów zmian.
 
 Gałąź w Gicie jest po prostu lekkim, przesuwalnym wskaźnikiem na któryś z owych zestawów zmian. Domyślna nazwa gałęzi Gita to master. Kiedy zatwierdzasz pierwsze zmiany, otrzymujesz gałąź master, która wskazuje na ostatni zatwierdzony przez Ciebie zestaw. Z każdym zatwierdzeniem automatycznie przesuwa się ona do przodu.
 
 Insert 18333fig0303.png 
-Figure 3-3. Gałąź wskazująca na dane zestawu zmian w historii.
+Rysunek 3-3. Gałąź wskazująca na dane zestawu zmian w historii.
 
 Co się stanie, jeśli utworzysz nową gałąź? Cóż, utworzony zostanie nowy wskaźnik, który następnie będziesz mógł przesuwać. Powiedzmy, że tworzysz nową gałąź o nazwie testing. Zrobisz to za pomocą polecenia `git branch`:
 
@@ -39,12 +39,12 @@ Co się stanie, jeśli utworzysz nową gałąź? Cóż, utworzony zostanie nowy
 Polecenie to tworzy nowy wskaźnik na ten sam zestaw zmian, w którym aktualnie się znajdujesz (zobacz Rysunek 3-4).
 
 Insert 18333fig0304.png 
-Figure 3-4. Wiele gałęzi wskazujących na dane zestawów zmian w historii.
+Rysunek 3-4. Wiele gałęzi wskazujących na dane zestawów zmian w historii.
 
 Skąd Git wie, na której gałęzi się aktualnie znajdujesz? Utrzymuje on specjalny wskaźnik o nazwie HEAD. Istotnym jest, że bardzo różni się on od koncepcji HEADa znanej z innych systemów kontroli wersji, do jakich mogłeś się już przyzwyczaić, na przykład Subversion czy CVS. W Gicie jest to wskaźnik na lokalną gałąź, na której właśnie się znajdujesz. W tym wypadku, wciąż jesteś na gałęzi master. Polecenie `git branch` utworzyło jedynie nową gałąź, ale nie przełączyło cię na nią (porównaj z Rysunkiem 3-5).
 
 Insert 18333fig0305.png 
-Figure 3-5. HEAD wskazuje na gałąź, na której się znajdujesz.
+Rysunek 3-5. HEAD wskazuje na gałąź, na której się znajdujesz.
 
 Aby przełączyć się na istniejącą gałąź, używasz polecenia `git checkout`. Przełączmy się zatem do nowo utworzonej gałęzi testing:
 
@@ -53,26 +53,26 @@ Aby przełączyć się na istniejącą gałąź, używasz polecenia `git checkou
 HEAD zostaje zmieniony tak, by wskazywać na gałąź testing (zobacz Rysunek 3-6).
 
 Insert 18333fig0306.png
-Figure 3-6. Po przełączaniu gałęzi, HEAD wskazuje inną gałąź.
+Rysunek 3-6. Po przełączaniu gałęzi, HEAD wskazuje inną gałąź.
 
 Jakie ma to znaczenie? Zatwierdźmy nowe zmiany:
 
 	$ vim test.rb
 	$ git commit -a -m 'zmiana'
 
-Figure 3-7 ilustruje wynik operacji.
+Rysunek 3-7 ilustruje wynik operacji.
 
 Insert 18333fig0307.png 
-Figure 3-7. Gałąź wskazywana przez HEAD przesuwa się naprzód po każdym zatwierdzeniu zmian.
+Rysunek 3-7. Gałąź wskazywana przez HEAD przesuwa się naprzód po każdym zatwierdzeniu zmian.
 
 To interesujące, bo teraz Twoja gałąź testing przesunęła się do przodu, jednak gałąź master ciągle wskazuje ten sam zestaw zmian, co w momencie użycia `git checkout` do zmiany aktywnej gałęzi. Przełączmy się zatem z powrotem na gałąź master:
 
 	$ git checkout master
 
-Figure 3-8 pokazuje wynik.
+Rysunek 3-8 pokazuje wynik.
 
 Insert 18333fig0308.png 
-Figure 3-8. Po wykonaniu `checkout`, HEAD przesuwa się na inną gałąź.
+Rysunek 3-8. Po wykonaniu `checkout`, HEAD przesuwa się na inną gałąź.
 
 Polecenie dokonało dwóch rzeczy. Przesunęło wskaźnik HEAD z powrotem na gałąź master i przywróciło pliki w katalogu roboczym do stanu z migawki, na którą wskazuje master. Oznacza to również, że zmiany, które od tej pory wprowadzisz, będą rozwidlały się od starszej wersji projektu. W gruncie rzeczy cofa to tymczasowo pracę, jaką wykonałeś na gałęzi testing, byś mógł z dalszymi zmianami pójść w innym kierunku.
 
@@ -84,7 +84,7 @@ Wykonajmy teraz kilka zmian i zatwierdźmy je:
 Teraz historia Twojego projektu została rozszczepiona (porównaj Rysunek 3-9). Stworzyłeś i przełączyłeś się na gałąź, wykonałeś na niej pracę, a następnie powróciłeś na gałąź główną i wykonałeś inną pracę. Oba zestawy zmian są od siebie odizolowane w odrębnych gałęziach: możesz przełączać się pomiędzy nimi oraz scalić je razem, kiedy będziesz na to gotowy. A wszystko to wykonałeś za pomocą dwóch prostych poleceń `branch` i `checkout`.
 
 Insert 18333fig0309.png 
-Figure 3-9. Rozwidlona historia gałęzi.
+Rysunek 3-9. Rozwidlona historia gałęzi.
 
 Ponieważ gałęzie w Gicie są tak naprawdę prostymi plikami, zawierającymi 40 znaków sumy kontrolnej SHA-1 zestawu zmian, na który wskazują, są one bardzo tanie w tworzeniu i usuwaniu. Stworzenie nowej gałęzi zajmuje dokładnie tyle czasu, co zapisanie 41 bajtów w pliku (40 znaków + znak nowej linii).
 
@@ -112,7 +112,7 @@ Na tym etapie otrzymasz telefon, że inny problem jest obecnie priorytetem i pot
 Na początek załóżmy, że pracujesz nad swoim projektem i masz już zatwierdzonych kilka zestawów zmian (patrz Rysunek 3-10).
 
 Insert 18333fig0310.png 
-Figure 3-10. Krótka i prosta historia zmian.
+Rysunek 3-10. Krótka i prosta historia zmian.
 
 Zdecydowałeś się zająć problemem #53 z systemu śledzenia zgłoszeń, którego używa Twoja firma, czymkolwiek by on nie był. Dla ścisłości, Git nie jest powiązany z żadnym konkretnym systemem tego typu; tym niemniej ponieważ problem #53 to dość konkretny temat, utworzysz nową gałąź by się nim zająć. Aby utworzyć gałąź i jednocześnie się na nią przełączyć, możesz wykonać polecenie `git checkout` z przełącznikiem `-b`:
 
@@ -124,10 +124,10 @@ Jest to krótsza wersja:
 	$ git branch iss53
 	$ git checkout iss53
 
-Figure 3-11 pokazuje wynik.
+Rysunek 3-11 pokazuje wynik.
 
 Insert 18333fig0311.png 
-Figure 3-11. Tworzenie wskaźnika nowej gałęzi.
+Rysunek 3-11. Tworzenie wskaźnika nowej gałęzi.
 
 Pracujesz nad swoim serwisem WWW i zatwierdzasz kolejne zmiany. Każdorazowo naprzód przesuwa się także gałąź `iss53`, ponieważ jest aktywna (to znaczy, że wskazuje na nią wskaźnik HEAD; patrz Rysunek 2-12):
 
@@ -135,7 +135,7 @@ Pracujesz nad swoim serwisem WWW i zatwierdzasz kolejne zmiany. Każdorazowo nap
 	$ git commit -a -m 'nowa stopka [#53]'
 
 Insert 18333fig0312.png 
-Figure 3-12. Gałąź iss53 przesunęła się do przodu wraz z postępami w Twojej pracy.
+Rysunek 3-12. Gałąź iss53 przesunęła się do przodu wraz z postępami w Twojej pracy.
 
 Teraz właśnie otrzymujesz telefon, że na stronie wykryto błąd i musisz go natychmiast poprawić. Z Gitem nie musisz wprowadzać poprawki razem ze zmianami wykonanymi w ramach pracy nad `iss35`. Co więcej, nie będzie cię również kosztować wiele wysiłku przywrócenie katalogu roboczego do stanu sprzed tych zmian, tak, by nanieść poprawki na kod, który używany jest na serwerze produkcyjnym. Wszystko, co musisz teraz zrobić, to przełączyć się z powrotem na gałąź master.
 
@@ -156,7 +156,7 @@ Masz jednak teraz do wykonania ważną poprawkę. Stwórzmy zatem gałąź, na k
 	 1 files changed, 0 insertions(+), 1 deletions(-)
 
 Insert 18333fig0313.png 
-Figure 3-13. Gałąź hotfix bazująca na gałęzi master.
+Rysunek 3-13. Gałąź hotfix bazująca na gałęzi master.
 
 Możesz uruchomić swoje testy, upewnić się, że poprawka w gałęzi hotfix jest tym, czego potrzebujesz i scalić ją na powrót z gałęzią master, by następnie przenieść zmiany na serwer produkcyjny. Robi się to poleceniem `git merge`:
 
@@ -172,7 +172,7 @@ Rezultat polecenia scalenia zawiera frazę „Fast forward”. Ponieważ zestaw
 Twoja zmiana jest teraz częścią migawki zestawu zmian wskazywanego przez gałąź `master` i możesz zaktualizować kod na serwerze produkcyjnym (zobacz Rysunek 3-14).
 
 Insert 18333fig0314.png 
-Figure 3-14. Po scaleniu Twoja gałąź master wskazuje to samo miejsce, co gałąź hotfix.
+Rysunek 3-14. Po scaleniu Twoja gałąź master wskazuje to samo miejsce, co gałąź hotfix.
 
 Po tym, jak Twoje niezwykle istotne poprawki trafią na serwer, jesteś gotowy powrócić do uprzednio przerwanej pracy. Najpierw jednak usuniesz gałąź hotfix, gdyż nie jest już ci potrzebna — gałąź `master` wskazuje to samo miejsce. Możesz ją usunąć używając opcji `-d` polecenia `git branch`:
 
@@ -189,7 +189,7 @@ Teraz możesz przełączyć się z powrotem do gałęzi z rozpoczętą wcześnie
 	 1 files changed, 1 insertions(+), 0 deletions(-)
 
 Insert 18333fig0315.png 
-Figure 3-15. Twoja gałąź iss53 może przesuwać się do przodu niezależnie.
+Rysunek 3-15. Twoja gałąź iss53 może przesuwać się do przodu niezależnie.
 
 Warto tu zauważyć, że praca, jaką wykonałeś na gałęzi `hotfix` nie jest uwzględniona w plikach w gałęzi `iss53`. Jeśli jej potrzebujesz, możesz scalić zmiany z gałęzi `master` do gałęzi `iss53`, uruchamiając `git merge master`, możesz też zaczekać z integracją zmian na moment, kiedy zdecydujesz się przenieść zmiany z gałęzi `iss53` z powrotem do gałęzi `master`.
 
@@ -206,14 +206,14 @@ Załóżmy, że zdecydowałeś, że praca nad problemem #53 dobiegła końca i j
 Wygląda to odrobinę inaczej, niż w przypadku wcześniejszego scalenia gałęzi `hotfix`. W tym wypadku Twoja historia rozwoju została rozszczepiona na wcześniejszym etapie. Ponieważ zestaw zmian z gałęzi, na której obecnie jesteś, nie jest bezpośrednim potomkiem gałęzi, którą scalasz, Git musi w końcu popracować. W tym przypadku Git przeprowadza scalenie trójstronne (ang. three-way merge), używając dwóch migawek wskazywanych przez końcówki gałęzi oraz ich wspólnego przodka. Rysunek 3-16 pokazuje trzy migawki, których w tym przypadku Git używa do scalania.
 
 Insert 18333fig0316.png 
-Figure 3-16. Git automatycznie odnajduje najlepszego wspólnego przodka, który będzie punktem wyjściowym do scalenia gałęzi.
+Rysunek 3-16. Git automatycznie odnajduje najlepszego wspólnego przodka, który będzie punktem wyjściowym do scalenia gałęzi.
 
 Zamiast zwykłego przeniesienia wskaźnika gałęzi do przodu, Git tworzy nową migawkę, która jest wynikiem wspomnianego scalenia trójstronnego i automatycznie tworzy nowy zestaw zmian, wskazujący na ową migawkę (patrz Rysunek 3-17). Określane jest to mianem zmiany scalającej (ang. merge commit), która jest o tyle wyjątkowa, że posiada więcej niż jednego rodzica.
 
 Warto zaznaczyć, że Git sam określa najlepszego wspólnego przodka do wykorzystania jako punkt wyjściowy scalenia; różni się to od zachowania CVS czy Subversion (przed wersją 1.5), gdzie osoba scalająca zmiany musi punkt wyjściowy scalania znaleźć samodzielnie. Czyni to scalanie w Gicie znacznie łatwiejszym, niż w przypadku tamtych systemów.
 
 Insert 18333fig0317.png 
-Figure 3-17. Git automatycznie tworzy nowy zestaw zmian zawierający scaloną pracę.
+Rysunek 3-17. Git automatycznie tworzy nowy zestaw zmian zawierający scaloną pracę.
 
 Teraz, kiedy Twoja praca jest już scalona, nie potrzebujesz dłużej gałęzi `iss53`. Możesz ją usunąć, a następnie ręcznie zamknąć zgłoszenie w swoim systemie śledzenia zadań:
 
@@ -349,12 +349,12 @@ Wielu programistów pracuje z Gitem wykorzystując to podejście, trzymając w g
 W rzeczywistości mówimy o wskaźnikach przesuwających się w przód po zatwierdzanych przez Ciebie zestawach zmian. Stabilne gałęzie znajdują się wcześniej w historii, a gałęzie robocze na jej końcu (patrz Rysunek 3-18).
 
 Insert 18333fig0318.png 
-Figure 3-18. Stabilniejsze gałęzie z reguły znajdują się wcześniej w historii zmian.
+Rysunek 3-18. Stabilniejsze gałęzie z reguły znajdują się wcześniej w historii zmian.
 
 Ogólnie łatwiej jest myśleć o nich jak o silosach na zmiany, gdzie grupy zmian są promowane do stabilniejszych silosów, kiedy już zostaną przetestowane (Rysunek 3-19).
 
 Insert 18333fig0319.png 
-Figure 3-19. Może być ci łatwiej myśleć o swoich gałęziach jak o silosach.
+Rysunek 3-19. Może być ci łatwiej myśleć o swoich gałęziach jak o silosach.
 
 Możesz powielić ten schemat na kilka poziomów stabilności. Niektóre większe projekty posiadają dodatkowo gałąź `proposed` albo `pu` („proposed updates” — proponowane zmiany), scalającą gałęzie, które nie są jeszcze gotowe trafić do gałęzi `next` czy `master`. Zamysł jest taki, że twoje gałęzie reprezentują różne poziomy stabilności; kiedy osiągają wyższy stopień stabilności, są scalane do gałęzi powyżej.
 Podobnie jak poprzednio, posiadanie takich długodystansowych gałęzi nie jest konieczne, ale często bardzo pomocne, zwłaszcza jeśli pracujesz przy dużych, złożonych projektach.
@@ -368,12 +368,12 @@ Widziałeś to w poprzedniej sekcji, kiedy pracowaliśmy z gałęziami `iss53` i
 Rozważ przykład wykonywania pewnego zadania (na gałęzi głównej), stworzenia gałęzi w celu rozwiązania konkretnego problemu (`iss91`), pracy na niej przez chwilę, stworzenia drugiej gałęzi w celu wypróbowania innego sposobu rozwiązania tego samego problemu (`iss91v2`), powrotu do gałęzi głównej i pracy z nią przez kolejną chwilę, a następnie stworzenia tam kolejnej gałęzi do sprawdzenia pomysłu, co do którego nie jesteś pewny, czy ma on sens (gałąź `dumbidea`). Twoja historia rewizji będzie wygląda mniej więcej tak:
 
 Insert 18333fig0320.png 
-Figure 3-20. Twoja historia rewizji zawierająca kilka gałęzi tematycznych.
+Rysunek 3-20. Twoja historia rewizji zawierająca kilka gałęzi tematycznych.
 
 Teraz, powiedzmy, że decydujesz się, że najbardziej podoba ci się drugie rozwiązanie Twojego problemu (`iss91v2`); zdecydowałeś się także pokazać gałąź `dumbidea` swoim współpracownikom i okazało się, że pomysł jest genialny. Możesz wyrzucić oryginalne rozwiązanie problemu znajdujące się w gałęzi `iss91` (tracąc rewizje C5 i C6) i scalić dwie pozostałe gałęzie. Twoja historia będzie wyglądać tak, jak na Rysunku 3-21.
 
 Insert 18333fig0321.png 
-Figure 3-21. Historia zmian po scaleniu gałęzi dumbidea i iss91v2.
+Rysunek 3-21. Historia zmian po scaleniu gałęzi dumbidea i iss91v2.
 
 Ważne jest, żeby robiąc to wszystko pamiętać, że są to zupełnie lokalne gałęzie. Tworząc nowe gałęzie i scalając je później, robisz to wyłącznie w ramach własnego repozytorium - bez jakiejkolwiek komunikacji z serwerem.
 
@@ -386,27 +386,27 @@ Ich nazwy przybierają następującą formę: `(nazwa zdalnego repozytorium)/(na
 Może być to nieco mylące, więc przyjrzyjmy się dokładniej przykładowi. Powiedzmy, że w swojej sieci masz serwer Git pod adresem `git.ourcompany.com`. Po sklonowaniu z niego repozytorium, Git automatycznie nazwie je jako `origin`, pobierze wszystkie dane, stworzy wskaźnik do miejsca gdzie znajduje się gałąź `master` i nazwie ją lokalnie `origin/master`; nie będziesz mógł jej przesuwać. Git da ci także do pracy Twoją własną gałąź `master` zaczynającą się w tym samym miejscu, co zdalna (zobacz Rysunek 3-22).
 
 Insert 18333fig0322.png
-Figure 3-22. Po sklonowaniu otrzymasz własną gałąź główną oraz zdalną origin/master wskazującą na gałąź w zdalnym repozytorium.
+Rysunek 3-22. Po sklonowaniu otrzymasz własną gałąź główną oraz zdalną origin/master wskazującą na gałąź w zdalnym repozytorium.
 
 Jeśli wykonasz jakąś pracę na gałęzi głównej, a w międzyczasie ktoś inny wypchnie zmiany na `git.ourcompany.com` i zaktualizuje jego gałąź główną, wówczas wasze historie przesuną się do przodu w różny sposób. Co więcej, dopóki nie skontaktujesz się z serwerem zdalnym, Twój wskaźnik `origin/master` nie przesunie się (Rysunek 3-23).
 
 Insert 18333fig0323.png 
-Figure 3-23. Kiedy pracujesz lokalnie, wypchnięcie przez kogoś zmian na serwer powoduje, że obie historie zaczynają przesuwać się do przodu w odmienny sposób.
+Rysunek 3-23. Kiedy pracujesz lokalnie, wypchnięcie przez kogoś zmian na serwer powoduje, że obie historie zaczynają przesuwać się do przodu w odmienny sposób.
 
 Aby zsynchronizować zmiany uruchom polecenie `git fetch origin`. Polecenie to zajrzy na serwer, na który wskazuje nazwa origin (w tym wypadku `git.ourcompany.com`), pobierze z niego wszystkie dane, których jeszcze nie masz u siebie, i zaktualizuje Twoją lokalną bazę danych przesuwając jednocześnie wskaźnik `origin/master` do nowej, aktualniejszej pozycji (zobacz Rysunek 3-24).
 
 Insert 18333fig0324.png 
-Figure 3-24. Polecenie git fetch aktualizuje zdalne referencje.
+Rysunek 3-24. Polecenie git fetch aktualizuje zdalne referencje.
 
 Aby zaprezentować fakt posiadania kilku zdalnych serwerów oraz stan ich zdalnych gałęzi, załóżmy, że posiadasz jeszcze jeden firmowy serwer Git, który jest używany wyłącznie przez jeden z twoich zespołów sprintowych. Jest to serwer dostępny pod adresem `git.team1.ourcompany.com`. Możesz go dodać do projektu, nad którym pracujesz, jako nowy zdalny odnośnik uruchamiając polecenie `git remote add` tak, jak pokazaliśmy to w rozdziale 2. Nazwij go `teamone`, dzięki czemu później będziesz używał tej nazwy zamiast pełnego adresu URL (rysunek 3-25).
 
 Insert 18333fig0325.png 
-Figure 3-25. Dodanie kolejnego zdalnego serwera.
+Rysunek 3-25. Dodanie kolejnego zdalnego serwera.
 
 Możesz teraz uruchomić polecenie `git fetch teamone` aby pobrać wszystko, co znajduje się na serwerze, a czego jeszcze nie posiadasz lokalnie. Ponieważ serwer ten zawiera podzbiór danych które zawiera serwer `origin`, Git nie pobiera niczego ale tworzy zdalną gałąź `teamone/master` wskazującą na rewizję dostępną w repozytorium `teamone` i jej gałęzi `master` (rysunek 3-26).
 
 Insert 18333fig0326.png 
-Figure 3-26. Dostajesz lokalny odnośnik do gałęzi master w repozytorium teamone.
+Rysunek 3-26. Dostajesz lokalny odnośnik do gałęzi master w repozytorium teamone.
 
 ### Wypychanie zmian ###
 
@@ -481,12 +481,12 @@ W Git istnieją dwa podstawowe sposoby integrowania zmian z jednej gałęzi do d
 Jeśli cofniesz się do poprzedniego przykładu z sekcji Scalanie (patrz Rysunek 3-27), zobaczysz, że rozszczepiłeś swoją pracę i wykonywałeś zmiany w dwóch różnych gałęziach.
 
 Insert 18333fig0327.png 
-Figure 3-27. Początkowa historia po rozszczepieniu.
+Rysunek 3-27. Początkowa historia po rozszczepieniu.
 
 Najprostszym sposobem, aby zintegrować gałęzie - jak już napisaliśmy - jest polecenie `merge`. Przeprowadza ono trójstronne scalanie pomiędzy dwoma ostatnimi migawkami gałęzi (C3 i C4) oraz ich ostatnim wspólnym przodkiem (C2), tworząc nową migawkę (oraz rewizję), tak jak widać to na rysunku 3-28.
 
 Insert 18333fig0328.png 
-Figure 3-28. Scalanie gałęzi integrujące rozszczepioną historię zmian.
+Rysunek 3-28. Scalanie gałęzi integrujące rozszczepioną historię zmian.
 
 Jednakże istnieje inny sposób: możesz stworzyć łatkę ze zmianami wprowadzonymi w C3 i zaaplikować ją na rewizję C4. W Gicie nazywa się to zmianą bazy (ang. rebase). Dzięki poleceniu `rebase` możesz wziąć wszystkie zmiany, które zostały zatwierdzone w jednej gałęzi i zaaplikować je w innej.
 
@@ -500,12 +500,12 @@ W tym wypadku, mógłbyś uruchomić następujące polecenie:
 Polecenie to działa przesuwając się do ostatniego wspólnego przodka obu gałęzi (tej w której się znajdujesz oraz tej *do* której robisz zmianę bazy), pobierając różnice opisujące kolejne zmiany (ang. diffs) wprowadzane przez kolejne rewizje w gałęzi w której się znajdujesz, zapisując je w tymczasowych plikach, następnie resetuje bieżącą gałąź do tej samej rewizji *do* której wykonujesz operację zmiany bazy, po czym aplikuje po kolei zapisane zmiany. Ilustruje to rysunek 3-29.
 
 Insert 18333fig0329.png 
-Figure 3-29. Zmiana bazy dla zmian wprowadzonych w C3 do C4.
+Rysunek 3-29. Zmiana bazy dla zmian wprowadzonych w C3 do C4.
 
 W tym momencie możesz wrócić do gałęzi `master` i scalić zmiany wykonując proste przesunięcie wskaźnika (co przesunie wskaźnik master na koniec) (rysunek 3-30).
 
 Insert 18333fig0330.png 
-Figure 3-30. Przesunięcie gałęzi master po operacji zmiany bazy.
+Rysunek 3-30. Przesunięcie gałęzi master po operacji zmiany bazy.
 
 Teraz migawka wskazywana przez C3' jest dokładnie taka sama jak ta, na którą wskazuje C5 w przykładzie ze scalaniem. Nie ma różnicy w produkcie końcowym integracji. Zmiana bazy tworzy jednak czystszą historię. Jeśli przejrzysz historię gałęzi po operacji `rebase`, wygląda ona na liniową: wygląda jakby cała praca była wykonywana stopniowo, nawet jeśli oryginalnie odbywała się równolegle.
 
@@ -518,7 +518,7 @@ Zauważ, że migawka wskazywana przez wynikową rewizję bez względu na to, czy
 Poleceniem `rebase` możesz także zastosować zmiany na innej gałęzi niż ta, której zmieniasz bazę. Dla przykładu - weź historię taką jak na rysunku 3-31. Utworzyłeś gałąź tematyczną (`server`), żeby dodać nowe funkcje do kodu serwerowego, po czym utworzyłeś rewizję. Następnie utworzyłeś gałąź, żeby wykonać zmiany w kliencie (`client`) i kilkukrotnie zatwierdziłeś zmiany. W końcu wróciłeś do gałęzi `server` i wykonałeś kilka kolejnych rewizji.
 
 Insert 18333fig0331.png 
-Figure 3-31. Historia z gałęzią tematyczną utworzoną na podstawie innej gałęzi tematycznej.
+Rysunek 3-31. Historia z gałęzią tematyczną utworzoną na podstawie innej gałęzi tematycznej.
 
 Załóżmy, że zdecydowałeś się scalić zmiany w kliencie do kodu głównego, ale chcesz się jeszcze wstrzymać ze zmianami po stronie serwera, dopóki nie zostaną one dokładniej przetestowane. Możesz wziąć zmiany w kodzie klienta, których nie ma w kodzie serwera (C8 i C9) i zastosować je na gałęzi głównej używając opcji `--onto` polecenia `git rebase`:
 
@@ -527,7 +527,7 @@ Załóżmy, że zdecydowałeś się scalić zmiany w kliencie do kodu głównego
 Oznacza to mniej więcej "Przełącz się do gałęzi klienta, określ zmiany wprowadzone od wspólnego przodka gałęzi `client` i `server`, a następnie nanieś te zmiany na gałąź główną `master`. Jest to nieco skomplikowane, ale wynik (pokazany na rysunku 3-32) całkiem niezły.
 
 Insert 18333fig0332.png 
-Figure 3-32. Zmiana bazy gałęzi tematycznej odbitej z innej gałęzi tematycznej.
+Rysunek 3-32. Zmiana bazy gałęzi tematycznej odbitej z innej gałęzi tematycznej.
 
 Teraz możesz zwyczajnie przesunąć wskaźnik gałęzi głównej do przodu (rysunek 3-33):
 
@@ -535,7 +535,7 @@ Teraz możesz zwyczajnie przesunąć wskaźnik gałęzi głównej do przodu (rys
 	$ git merge client
 
 Insert 18333fig0333.png 
-Figure 3-33. Przesunięcie do przodu gałęzi master w celu uwzględnienia zmian z gałęzi klienta.
+Rysunek 3-33. Przesunięcie do przodu gałęzi master w celu uwzględnienia zmian z gałęzi klienta.
 
 Powiedzmy, że zdecydujesz się pobrać i scalić zmiany z gałęzi `server`. Możesz zmienić bazę gałęzi `server` na wskazywaną przez `master` bez konieczności przełączania się do gałęzi `server` używając `git rebase [gałąź bazowa] [gałąź tematyczna]` - w ten sposób zmiany z gałęzi `server` zostaną zaaplikowane do gałęzi bazowej `master`:
 
@@ -544,7 +544,7 @@ Powiedzmy, że zdecydujesz się pobrać i scalić zmiany z gałęzi `server`. Mo
 Polecenie odtwarza zmiany z gałęzi `server` na gałęzi `master` tak, jak pokazuje to rysunek 3-34.
 
 Insert 18333fig0334.png 
-Figure 3-34. Zmiana bazy gałęzi `serwer` na koniec gałęzi głównej.
+Rysunek 3-34. Zmiana bazy gałęzi `serwer` na koniec gałęzi głównej.
 
 Następnie możesz przesunąć gałąź bazową (`master`):
 
@@ -557,7 +557,7 @@ Możesz teraz usunąć gałęzie `client` i `server`, ponieważ cała praca jest
 	$ git branch -d server
 
 Insert 18333fig0335.png 
-Figure 3-35. Ostateczna historia rewizji.
+Rysunek 3-35. Ostateczna historia rewizji.
 
 ### Zagrożenia operacji zmiany bazy ###
 
@@ -572,22 +572,22 @@ Stosując operację zmiany bazy porzucasz istniejące rewizje i tworzysz nowe, k
 Spójrzmy na przykład obrazujący, jak operacja zmiany bazy może spowodować problemy. Załóżmy, że sklonujesz repozytorium z centralnego serwera, a następnie wykonasz bazując na tym nowe zmiany. Twoja historia rewizji wygląda tak jak na rysunku 3-36.
 
 Insert 18333fig0336.png 
-Figure 3-36. Sklonowane repozytorium i dokonane zmiany.
+Rysunek 3-36. Sklonowane repozytorium i dokonane zmiany.
 
 Teraz ktoś inny wykonuje inną pracę, która obejmuje scalenie, i wypycha ją na centralny serwer. Pobierasz zmiany, scalasz nową, zdalną gałąź z własną pracą, w wyniku czego historia wygląda mniej więcej tak, jak na rysunku 3-37.
 
 Insert 18333fig0337.png 
-Figure 3-37. Pobranie kolejnych rewizji i scalenie ich z własnymi zmianami.
+Rysunek 3-37. Pobranie kolejnych rewizji i scalenie ich z własnymi zmianami.
 
 Następnie osoba, która wypchnęła scalone zmiany, rozmyśliła się i zdecydowała zamiast scalenia zmienić bazę swoich zmian; wykonuje `git push --force`, żeby zastąpić historię na serwerze. Następnie ty pobierasz dane z serwera ściągając nowe rewizje.
 
 Insert 18333fig0338.png 
-Figure 3-38. Ktoś wypycha rewizje po operacji zmiany bazy porzucając rewizje, na których ty oparłeś swoje zmiany.
+Rysunek 3-38. Ktoś wypycha rewizje po operacji zmiany bazy porzucając rewizje, na których ty oparłeś swoje zmiany.
 
 W tym momencie musisz raz jeszcze scalać tę pracę mimo tego, że już to wcześniej raz zrobiłeś. Operacja zmiany bazy zmienia sumy kontrolne SHA-1 tych rewizji, więc dla Gita wyglądają one jak zupełnie nowe, choć w rzeczywistości masz już zmiany wprowadzone w C4 w swojej historii (rysunek 3-39).
 
 Insert 18333fig0339.png 
-Figure 3-39. Scalasz tą samą pracę raz jeszcze tworząc nową rewizję scalającą.
+Rysunek 3-39. Scalasz tą samą pracę raz jeszcze tworząc nową rewizję scalającą.
 
 Musisz scalić swoją pracę w pewnym momencie po to, żeby dotrzymywać kroku innym programistom. Kiedy już to zrobisz, Twoja historia zmian będzie zawierać zarówno rewizje C4 jak i C4', które mają różne sumy SHA-1, ale zawierają te same zmiany i mają ten sam komentarz. Jeśli uruchomisz `git log` dla takiej historii, zobaczysz dwie rewizje mające tego samego autora, datę oraz komentarz, co będzie mylące. Co więcej, jeśli wypchniesz tę historię z powrotem na serwer, raz jeszcze wprowadzisz wszystkie rewizje powstałe w wyniku operacji zmiany bazy na serwer centralny, co może dalej mylić i denerwować ludzi.
 
diff --git a/pl/04-git-server/01-chapter4.markdown b/pl/04-git-server/01-chapter4.markdown
index 23fb04850..28e41f0fe 100644
--- a/pl/04-git-server/01-chapter4.markdown
+++ b/pl/04-git-server/01-chapter4.markdown
@@ -318,7 +318,7 @@ W ten sposób możesz ustawić oparty na HTTP dostęp odczytu do swoich projekt
 Teraz, gdy już podstawy odczytu i zapisu są dostępne tylko dla Twojego projektu, możesz założyć prostą internetową wizualizacje. Do tego celu Git wyposażony jest w skrypt CGI o nazwie GitWeb. Jak widać GitWeb stosowany jest w miejscach takich jak:`http://git.kernel.org` (patrz rys. 4-1).
 
 Insert 18333fig0401.png
-Figure 4-1.GitWeb internetowy interfejs użytkownika.
+Rysunek 4-1.GitWeb internetowy interfejs użytkownika.
 
 Jeśli chcesz zobaczyć jak GitWeb będzie wyglądał dla Twojego projektu, Git posiada polecenie do uruchamiania tymczasowej instancji, pod warunkiem, że posiadasz lekki serwer taki jak `lighttpd` lub `webrick`. Na komputerach z zainstalowanym linuxem `lighttpd` jest bardzo często instalowany więc należy go uruchomić wpisując `git instaweb` w katalogu projektu. Jeśli używasz komputera Mac, Leopard jest automatycznie instalowany z Ruby więc `webrick` może być najlepszym rozwiązaniem. Aby rozpocząć `instaweb` bez tymczasowej instancji, należy uruchomić go z opcją `--httpd`.
 
@@ -777,18 +777,18 @@ GitHub jest również spółką handlową, która pobiera opłaty za utrzymanie
 Pierwszą rzeczą jaką musisz zrobić jest założenie darmowego konta użytkownika. W tym celu wchodzisz na stronę rejestracji `https://github.com/pricing` i klikasz przycisk "Zarejestruj się" na darmowe konto (patrz rysunek 4-2) i jesteś już przeniesiony na stronę rejestracji.
 
 Insert 18333fig0402.png
-Figure 4-2. Strona rejestracji GitHub.
+Rysunek 4-2. Strona rejestracji GitHub.
 
 Tutaj musisz wybrać nazwę użytkownika, taką która nie istnieje jeszcze w systemie, podać adres e-mail, który będzie powiązany z kontem i podać hasło Rysunek 4-3).
 
 Insert 18333fig0403.png 
-Figure 4-3. Rejestracja użytkownika GitHub.
+Rysunek 4-3. Rejestracja użytkownika GitHub.
 
 Jeśli jest to możliwe to jest to dobry moment aby dodać swój publiczny klucz SSH. W rozdziale "Simple Setups" wyjaśniliśmy już jak wygenerować nowy klucz. Skopiuj zawartość klucza i wklej go w polu "SSH Public Key". Kliknięcie "explain ssh keys" przeniesie Cię do szczegółowych informacji jak zrobić to na poszczególnych systemach operacyjnych.
 Kliknięcie "I agree, sign me up" powoduje przeniesienie do nowego panelu użytkownika (patrz rysunek 4-4).
 
 Insert 18333fig0404.png 
-Figure 4-4. Panel użytkownika GitHub.
+Rysunek 4-4. Panel użytkownika GitHub.
 
 Następnie możesz utworzyć nowe repozytorium.
 
@@ -797,17 +797,17 @@ Następnie możesz utworzyć nowe repozytorium.
 Zacznij klikając na link "create a new one" obok Twoich repozytoriów na panelu użytkownika. Jesteś na stronie do tworzenia nowego repozytorium (patrz rysunek 4-5).
 
 Insert 18333fig0405.png 
-Figure 4-5. Tworzenie nowego repozytorium na GitHubie.
+Rysunek 4-5. Tworzenie nowego repozytorium na GitHubie.
 
 Wszystko co tak naprawdę musisz zrobić to podać nazwę projektu. Możesz też podać dodatkowy opis. Kiedy to zrobisz klikasz przycisk "Create Repository". Masz już nowe repozytorium na GitHubie (patrz rysunek 4-6).
 
 Insert 18333fig0406.png 
-Figure 4-6. Główne informacje o projekcie.
+Rysunek 4-6. Główne informacje o projekcie.
 
 Ponieważ nie masz tam jeszcze kodu, GitHub pokaże instrukcje jak stworzyć zupełnie nowy projekt. Wciśnij istniejący już projekt, lub zaimportuj projekt z publicznego repozytorium Subversion (patrz rysunek 4-7).
 
 Insert 18333fig0407.png 
-Figure 4-7. Instrukcja tworzenia nowego repozytorium.
+Rysunek 4-7. Instrukcja tworzenia nowego repozytorium.
 
 Instrukcje te są podobne do tego co już przeszedłeś. Aby zainicjować projekt, jeśli nie jest jeszcze projektem gita, możesz użyć:
 
@@ -823,7 +823,7 @@ Kiedy masz już lokalne repozytorium Gita, dodaj GitHub jako zdalne repozytorium
 Teraz Twój projekt jest już utrzymywany na GitHubie. Możesz każdemu udostępnić swój projekt wysyłając adres URL. W naszym przypadku jest to `http://github.com/testinguser/iphone_project`. Możesz także zobaczyć na nagłówku każdego z projektów, że masz dwa adresy URL (patrz rysunek 4-8).
 
 Insert 18333fig0408.png 
-Figure 4-8. Nagłówek projektu z prywatnym i publicznym adresem URL.
+Rysunek 4-8. Nagłówek projektu z prywatnym i publicznym adresem URL.
 
 Publiczny adres URL służy tylko do pobierania repozytorium projektu. Zachęcamy do umieszczania go na stronach WWW.
 
@@ -834,7 +834,7 @@ Prywatny adres URL służy do pobierania i wysyłania repozytorium na serwer. Ko
 Jeśli masz już projekt publiczny Subversion, który chcesz zaimportować do Gita, GitHub często może zrobić to dla Ciebie. Na dole strony instrukcji jest link służący do importu Subversion. Po kliknięciu na niego pojawi się formularz z informacjami o imporcie projektu i pole gdzie można wkleić adres swojego publicznego projektu Subversion (patrz rysunek 4-9).
 
 Insert 18333fig0409.png 
-Figure 4-9. Interfejs importowanie Subversion.
+Rysunek 4-9. Interfejs importowanie Subversion.
 
 Jeśli Twój projekt jest bardzo duży, niestandardowy lub prywatny to proces ten najprawdopodobniej nie zadziała. W rozdziale 7 dowiesz się jak ręcznie przeprowadzić bardziej skomplikowany import.
 
@@ -845,17 +845,17 @@ Dodajmy więc resztę naszej drużyny. Jeśli John, Josie i Jessica zapiszą si
 Naciśnij przycisk "edit" na nagłówku projektu lub w zakładce Admina na górze projektu aby uzyskać dostęp do strony Admina projektu GitHub (zobacz Rysunek 4-10).
 
 Insert 18333fig0410.png 
-Figure 4-10. Strona administratora GitHub.
+Rysunek 4-10. Strona administratora GitHub.
 
 Aby dać dostęp do projektu kolejnej osobie, naciśnij link “Add another collaborator”. Pojawia się nowe pole tekstowe gdzie można wpisać nazwę użytkownika. Jak już wpiszesz nazwę użytkownika, wyskakujące okienko podpowie Ci pasujących do nazwy użytkowników. Kiedy znajdziesz prawidłowego użytkownika, naciśnij przycisk "Add" aby dodać użytkownika do współpracowników w Twoim projekcie (zobacz Rysunek 4-11).
 
 Insert 18333fig0411.png 
-Figure 4-11. Dodawanie współpracowników do Twojego projektu.
+Rysunek 4-11. Dodawanie współpracowników do Twojego projektu.
 
 Kiedy skończysz dodawanie współpracowników, powinieneś zobaczyć ich listę w okienku "Repository Collaborators" (zobacz Rysunek 4-12).
 
 Insert 18333fig0412.png 
-Figure 4-12. Lista współpracowników w Twoim projekcie.
+Rysunek 4-12. Lista współpracowników w Twoim projekcie.
 
 Jeśli musisz zablokować dostęp poszczególnym osobom, możesz kliknąć link "revoke", w ten sposób usuniesz możliwość użycia komendy "push". Dla przyszłych projektów, możesz skopiować grupę współpracowników kopiując ich dane dostępowe w istniejącym projekcie.
 
@@ -864,7 +864,7 @@ Jeśli musisz zablokować dostęp poszczególnym osobom, możesz kliknąć link
 Po tym jak wyślesz swój projekt lub zaimportujesz z Subversion, będziesz miał stronę główną projektu wyglądającą jak na Rysunku 4-13.
 
 Insert 18333fig0413.png 
-Figure 4-13. Strona główna projektu GitHub.
+Rysunek 4-13. Strona główna projektu GitHub.
 
 Kiedy ludzie będą odwiedzali Twój projekt, zobaczą tę stronę. Zawiera ona kilka kart. Karta zatwierdzeń pokazuje zatwierdzenia w odwrotnej kolejności, tak samo jak w przypadku polecenia `git log`. Karta połączeń pokazuje wszystkich którzy zrobili rozwidlenie Twojego projektu i uzupełniają go. Karta ściągnięć pozwala ci załadować pliki binarne do projektu oraz linki do paczek z kodami i spakowane wersje wszystkich zaznaczonych punktów w projekcie. Karta Wiki pozwala na dodawanie dokumentacji oraz informacji do projektu. Karta Grafów pokazuje w graficzny sposób statystyki użytkowania projektu. Głowna karta z plikami źródłowymi, które lądują w projekcie pokazuje listę katalogów w projekcie i automatycznie renderuje plik README poniżej jeśli taki znajduje się w głównym katalogu projektu. Ta karta pokazuje również okno z zatwierdzeniami.
 
@@ -877,12 +877,12 @@ W tego typu projektach nie musimy martwić się o dodawanie współpracowników
 Aby rozwidlić projekt, odwiedź stronę projektu (w tym przykładzie, mojombo/chronic) i naciśnij przycisk "fork" w nagłówku (zobacz Rysunek 4-14).
 
 Insert 18333fig0414.png 
-Figure 4-14. Pozyskanie zapisywalnej wersji projektu poprzez użycie "fork".
+Rysunek 4-14. Pozyskanie zapisywalnej wersji projektu poprzez użycie "fork".
 
 Po kilku sekundach zostaniesz przeniesiony na swoją stronę projektu, która zawiera informacje, że dany projekt został rozwidlony (zobacz Rysunek 4-15).
 
 Insert 18333fig0415.png 
-Figure 4-15. Twoje rozwidlenie projektu.
+Rysunek 4-15. Twoje rozwidlenie projektu.
 
 ### Podsumowanie GitHub ###
 
diff --git a/pl/05-distributed-git/01-chapter5.markdown b/pl/05-distributed-git/01-chapter5.markdown
index fd5408ae4..92eb3984f 100644
--- a/pl/05-distributed-git/01-chapter5.markdown
+++ b/pl/05-distributed-git/01-chapter5.markdown
@@ -19,7 +19,7 @@ W scentralizowanych systemach, zazwyczaj jest stosowany model centralnego przep
 <!-- In centralized systems, there is generally a single collaboration model—the centralized workflow. One central hub, or repository, can accept code, and everyone synchronizes their work to it. A number of developers are nodes — consumers of that hub — and synchronize to that one place (see Figure 5-1). -->
 
 Insert 18333fig0501.png
-Figure 5-1. Scentralizowany przepływ pracy.
+Rysunek 5-1. Scentralizowany przepływ pracy.
 
 Oznacza to tyle, że w sytuacji w której dwóch niezależnych programistów korzystających z tego centralnego repozytorium będzie próbowało wgrać swoje zmiany, tylko pierwszemu z nich uda się tego dokonać bezproblemowo. Drugi przed wgraniem, będzie musiał najpierw pobrać i zintegrować zmiany wprowadzone przez pierwszego programistę, a dopiero później ponowić próbę wysłania swoich na serwer. Taki rodzaj współpracy sprawdza się doskonale w Gitcie, tak samo jak funkcjonuje on w Subversion (lub każdym innym CVCS).
 
@@ -52,7 +52,7 @@ Ponieważ Git powala na posiadanie wielu zdalnych repozytoriów, możliwy jest s
 -->
 
 Insert 18333fig0502.png
-Figure 5-2. Przepływ pracy z osobą integrującą zmiany.
+Rysunek 5-2. Przepływ pracy z osobą integrującą zmiany.
 
 To jest bardzo popularne podejście podczas współpracy przy pomocy stron takich jak GitHub, gdzie bardzo łatwo można stworzyć kopię repozytorium i wgrywać zmiany do niego aby każdy mógł je zobaczyć. jedną z głównych zalet takiego podejścia jest to, że możesz kontynuować pracę, a opiekun może pobrać Twoje zmiany w dowolnym czasie. Programiści nie muszą czekać na opiekuna, aż ten włączy ich zmiany, każdy z nich może pracować oddzielnie.
 
@@ -78,7 +78,7 @@ To jest wariant przepływu z wieloma repozytoriami. Zazwyczaj jest on używany w
 -->
 
 Insert 18333fig0503.png
-Figure 5-3. Przepływ pracy z miłościwym dyktatorem.
+Rysunek 5-3. Przepływ pracy z miłościwym dyktatorem.
 
 Ten rodzaj współpracy nie jest częsty w użyciu, ale może być użyteczny w bardzo dużych projektach, lub bardzo rozbudowanych strukturach zespołów w których lider zespołu może delegować większość pracy do innych i zbierać duże zestawy zmian przed integracją.
 
@@ -237,7 +237,7 @@ W tym momencie lokalne repozytorium Johna wygląda podobnie do tego z rys. 5-4.
 <!-- At this point, John’s local repository looks something like Figure 5-4. -->
 
 Insert 18333fig0504.png
-Figure 5-4. Lokalne repozytorium Johna.
+Rysunek 5-4. Lokalne repozytorium Johna.
 
 John ma już odniesienie do zmian które wypchnęła Jessica, ale musi je lokalnie połączyć ze swoimi zmianami, zanim będzie w stanie wypchnąć je:
 
@@ -253,7 +253,7 @@ John ma już odniesienie do zmian które wypchnęła Jessica, ale musi je lokaln
 <!-- The merge goes smoothly — John’s commit history now looks like Figure 5-5. -->
 
 Insert 18333fig0505.png
-Figure 5-5. Repozytorium Johna po połączeniu z origin/master.
+Rysunek 5-5. Repozytorium Johna po połączeniu z origin/master.
 
 Teraz, John może przetestować swój kod aby upewnić się że nadal działa poprawnie, oraz następnie wypchnąć swoje zmiany na serwer:
 
@@ -269,7 +269,7 @@ Ostatecznie, historia zmian u Johna wygląda tak jak na rys. 5-6.
 <!-- Finally, John’s commit history looks like Figure 5-6. -->
 
 Insert 18333fig0506.png
-Figure 5-6. Historia zmian Johna po wypchnięciu ich na serwer "origin".
+Rysunek 5-6. Historia zmian Johna po wypchnięciu ich na serwer "origin".
 
 <!-- Figure 5-6. John’s history after pushing to the origin server. -->
 
@@ -278,7 +278,7 @@ W tym samym czasie, Jessica pracowała na swojej tematycznej gałęzi. Stworzył
 <!-- In the meantime, Jessica has been working on a topic branch. She’s created a topic branch called `issue54` and done three commits on that branch. She hasn’t fetched John’s changes yet, so her commit history looks like Figure 5-7. -->
 
 Insert 18333fig0507.png
-Figure 5-7. Początkowa historia zmian u Jessici.
+Rysunek 5-7. Początkowa historia zmian u Jessici.
 
 Jessica chce zsynchronizować się ze zmianami Johna, więc pobiera ("fetch"):
 
@@ -295,7 +295,7 @@ Ta komenda pobiera zmiany Johna, które wprowadził w międzyczasie. Historia zm
 <!-- That pulls down the work John has pushed up in the meantime. Jessica’s history now looks like Figure 5-8. -->
 
 Insert 18333fig0508.png
-Figure 5-8. Historia zmian u Jessici po pobraniu zmian Johna.
+Rysunek 5-8. Historia zmian u Jessici po pobraniu zmian Johna.
 
 <!-- Figure 5-8. Jessica’s history after fetching John’s changes. -->
 
@@ -344,7 +344,7 @@ Wszystko połączyło się bez problemów, więc historia zmian u Jessici wyglą
 <!-- Everything merges cleanly, and Jessica’s history looks like Figure 5-9. -->
 
 Insert 18333fig0509.png
-Figure 5-9. Historia zmian u Jessici po włączeniu zmian Johna.
+Rysunek 5-9. Historia zmian u Jessici po włączeniu zmian Johna.
 
 <!-- Figure 5-9. Jessica’s history after merging John’s changes. -->
 
@@ -362,7 +362,7 @@ Każdy programista wprowadził zmiany kilkukrotnie, oraz połączył zmiany drug
 <!-- Each developer has committed a few times and merged each other’s work successfully; see Figure 5-10. -->
 
 Insert 18333fig0510.png
-Figure 5-10. Historia zmian u Jessici po wypchnięciu zmian na serwer.
+Rysunek 5-10. Historia zmian u Jessici po wypchnięciu zmian na serwer.
 
 <!-- Figure 5-10. Jessica’s history after pushing all changes back to the server. -->
 
@@ -371,7 +371,7 @@ To jest jeden z najprostszych przepływów pracy. Pracujesz przez chwilę, gener
 <!-- That is one of the simplest workflows. You work for a while, generally in a topic branch, and merge into your master branch when it’s ready to be integrated. When you want to share that work, you merge it into your own master branch, then fetch and merge `origin/master` if it has changed, and finally push to the `master` branch on the server. The general sequence is something like that shown in Figure 5-11. -->
 
 Insert 18333fig0511.png
-Figure 5-11. Sekwencja zdarzeń dla prostego przepływu zmian między programistami.
+Rysunek 5-11. Sekwencja zdarzeń dla prostego przepływu zmian między programistami.
 
 <!-- Figure 5-11. General sequence of events for a simple multiple-developer Git workflow. -->
 
@@ -433,7 +433,7 @@ Repozytorium Jessici wygląda tak jak na rys. 5-12.
 <!-- Jessica’s repository looks like Figure 5-12. -->
 
 Insert 18333fig0512.png
-Figure 5-12. Początkowa historia zmian u Jessici.
+Rysunek 5-12. Początkowa historia zmian u Jessici.
 
 <!-- Figure 5-12. Jessica’s initial commit history. -->
 
@@ -519,7 +519,7 @@ Historia zmian u Jessici wygląda teraz tak jak na rys. 5-13.
 <!-- Jessica’s commit history now looks something like Figure 5-13. -->
 
 Insert 18333fig0513.png
-Figure 5-13. Historia zmian Jessici po wprowadzeniu zmian w gałęzi.
+Rysunek 5-13. Historia zmian Jessici po wprowadzeniu zmian w gałęzi.
 
 <!-- Figure 5-13. Jessica’s history after committing on a feature branch. -->
 
@@ -528,7 +528,7 @@ Jessica, Josie i John powiadamiają osoby zajmujące się integracją, że gał
 <!-- Jessica, Josie, and John inform the integrators that the `featureA` and `featureBee` branches on the server are ready for integration into the mainline. After they integrate these branches into the mainline, a fetch will bring down the new merge commits, making the commit history look like Figure 5-14. -->
 
 Insert 18333fig0514.png
-Figure 5-14. Historia zmian u Jessici po włączeniu jej obu gałęzi.
+Rysunek 5-14. Historia zmian u Jessici po włączeniu jej obu gałęzi.
 
 <!-- Figure 5-14. Jessica’s history after merging both her topic branches. -->
 
@@ -537,7 +537,7 @@ Duża ilość grup przechodzi na Gita ze względu na możliwość jednoczesnej w
 <!-- Many groups switch to Git because of this ability to have multiple teams working in parallel, merging the different lines of work late in the process. The ability of smaller subgroups of a team to collaborate via remote branches without necessarily having to involve or impede the entire team is a huge benefit of Git. The sequence for the workflow you saw here is something like Figure 5-15. -->
 
 Insert 18333fig0515.png
-Figure 5-15. Przebieg zdarzeń w takim przepływie.
+Rysunek 5-15. Przebieg zdarzeń w takim przepływie.
 
 <!-- Figure 5-15. Basic sequence of this managed-team workflow. -->
 
@@ -620,7 +620,7 @@ Teraz, każdy z zestawów zmian przechowywany jest w formie silosu - podobnego d
 <!-- Now, each of your topics is contained within a silo — similar to a patch queue — that you can rewrite, rebase, and modify without the topics interfering or interdepending on each other as in Figure 5-16. -->
 
 Insert 18333fig0516.png
-Figure 5-16. Początkowa historia ze zmianami featureB.
+Rysunek 5-16. Początkowa historia ze zmianami featureB.
 
 <!-- Figure 5-16. Initial commit history with featureB work. -->
 
@@ -637,7 +637,7 @@ To przepisuje twoją historię, która wygląda teraz tak jak na rys. 5-17.
 <!-- This rewrites your history to now look like Figure 5-17. -->
 
 Insert 18333fig0517.png
-Figure 5-17. Historia zmian po pracach na featureA.
+Rysunek 5-17. Historia zmian po pracach na featureA.
 
 <!-- Figure 5-17. Commit history after featureA work. -->
 
@@ -665,7 +665,7 @@ Teraz możesz wysłać do opiekuna wiadomość, że wprowadziłeś wszystkie wym
 <!-- Now you can send the maintainer a message that you’ve made the requested changes and they can find those changes in your `featureBv2` branch (see Figure 5-18). -->
 
 Insert 18333fig0518.png
-Figure 5-18. Historia zmian po zmianach w featureBv2.
+Rysunek 5-18. Historia zmian po zmianach w featureBv2.
 
 <!-- Figure 5-18. Commit history after featureBv2 work. -->
 
@@ -1060,12 +1060,12 @@ Jednym z prostszych przepływów pracy jest scalenie zmian z twoją gałęzią `
 <!-- One simple workflow merges your work into your `master` branch. In this scenario, you have a `master` branch that contains basically stable code. When you have work in a topic branch that you’ve done or that someone has contributed and you’ve verified, you merge it into your master branch, delete the topic branch, and then continue the process.  If we have a repository with work in two branches named `ruby_client` and `php_client` that looks like Figure 5-19 and merge `ruby_client` first and then `php_client` next, then your history will end up looking like Figure 5-20. -->
 
 Insert 18333fig0519.png
-Figure 5-19. Historia zmian z kilkoma gałęziami tematycznymi.
+Rysunek 5-19. Historia zmian z kilkoma gałęziami tematycznymi.
 
 <!-- Figure 5-19. History with several topic branches. -->
 
 Insert 18333fig0520.png
-Figure 5-20. Po scaleniu gałęzi.
+Rysunek 5-20. Po scaleniu gałęzi.
 
 <!-- Figure 5-20. After a topic branch merge. -->
 
@@ -1078,17 +1078,17 @@ Jeżeli masz większą ilość deweloperów lub większy projekt, będziesz chci
 <!-- If you have more developers or a larger project, you’ll probably want to use at least a two-phase merge cycle. In this scenario, you have two long-running branches, `master` and `develop`, in which you determine that `master` is updated only when a very stable release is cut and all new code is integrated into the `develop` branch. You regularly push both of these branches to the public repository. Each time you have a new topic branch to merge in (Figure 5-21), you merge it into `develop` (Figure 5-22); then, when you tag a release, you fast-forward `master` to wherever the now-stable `develop` branch is (Figure 5-23). -->
 
 Insert 18333fig0521.png
-Figure 5-21. Przed scaleniem gałęzi tematycznej.
+Rysunek 5-21. Przed scaleniem gałęzi tematycznej.
 
 <!-- Figure 5-21. Before a topic branch merge. -->
 
 Insert 18333fig0522.png
-Figure 5-22. Po scaleniu gałęzi tematycznej.
+Rysunek 5-22. Po scaleniu gałęzi tematycznej.
 
 <!-- Figure 5-22. After a topic branch merge. -->
 
 Insert 18333fig0523.png
-Figure 5-23. Po utworzeniu kolejnej wersji.
+Rysunek 5-23. Po utworzeniu kolejnej wersji.
 
 <!-- Figure 5-23. After a topic branch release. -->
 
@@ -1105,7 +1105,7 @@ Projekt Gita ma cztery długodystansowe gałęzie: `master`, `next`, `pu` (propo
 <!-- The Git project has four long-running branches: `master`, `next`, and `pu` (proposed updates) for new work, and `maint` for maintenance backports. When new work is introduced by contributors, it’s collected into topic branches in the maintainer’s repository in a manner similar to what I’ve described (see Figure 5-24). At this point, the topics are evaluated to determine whether they’re safe and ready for consumption or whether they need more work. If they’re safe, they’re merged into `next`, and that branch is pushed up so everyone can try the topics integrated together. -->
 
 Insert 18333fig0524.png
-Figure 5-24. Zarządzanie złożoną serią równoczesnych zmian w gałęziach tematycznych.
+Rysunek 5-24. Zarządzanie złożoną serią równoczesnych zmian w gałęziach tematycznych.
 
 <!-- Figure 5-24. Managing a complex series of parallel contributed topic branches. -->
 
@@ -1114,7 +1114,7 @@ Jeżeli funkcjonalność potrzebuje jeszcze kolejnych zmian, są one włączane
 <!-- If the topics still need work, they’re merged into `pu` instead. When it’s determined that they’re totally stable, the topics are re-merged into `master` and are then rebuilt from the topics that were in `next` but didn’t yet graduate to `master`. This means `master` almost always moves forward, `next` is rebased occasionally, and `pu` is rebased even more often (see Figure 5-25). -->
 
 Insert 18333fig0525.png
-Figure 5-25. Włączanie gałęzi tematycznych do gałęzi długodystansowych.
+Rysunek 5-25. Włączanie gałęzi tematycznych do gałęzi długodystansowych.
 
 <!-- Figure 5-25. Merging contributed topic branches into long-term integration branches. -->
 
@@ -1133,7 +1133,7 @@ Drugim sposobem na przeniesienie zmian z jednej gałęzi do drugiej jest zrobien
 <!-- The other way to move introduced work from one branch to another is to cherry-pick it. A cherry-pick in Git is like a rebase for a single commit. It takes the patch that was introduced in a commit and tries to reapply it on the branch you’re currently on. This is useful if you have a number of commits on a topic branch and you want to integrate only one of them, or if you only have one commit on a topic branch and you’d prefer to cherry-pick it rather than run rebase. For example, suppose you have a project that looks like Figure 5-26. -->
 
 Insert 18333fig0526.png
-Figure 5-26. Przykładowa historia przez wybiórczym zaciąganiem zmian.
+Rysunek 5-26. Przykładowa historia przez wybiórczym zaciąganiem zmian.
 
 <!-- Figure 5-26. Example history before a cherry pick. -->
 
@@ -1151,7 +1151,7 @@ To pobierze tylko zmiany z commita `e43a6`, ale otrzyma nową sumę SHA-1, ze wz
 <!--  This pulls the same change introduced in `e43a6`, but you get a new commit SHA-1 value, because the date applied is different. Now your history looks like Figure 5-27. -->
 
 Insert 18333fig0527.png
-Figure 5-27. Historia po wybiórczym zaciągnięciu zmiany z gałęzi tematycznej.
+Rysunek 5-27. Historia po wybiórczym zaciągnięciu zmiany z gałęzi tematycznej.
 
 <!-- Figure 5-27. History after cherry-picking a commit on a topic branch. -->
 
diff --git a/pl/06-git-tools/01-chapter6.markdown b/pl/06-git-tools/01-chapter6.markdown
index 9dd3e6e3b..2bb6cb043 100644
--- a/pl/06-git-tools/01-chapter6.markdown
+++ b/pl/06-git-tools/01-chapter6.markdown
@@ -269,7 +269,7 @@ Najczęściej używaną składnią wskazywania zakresu zmian jest podwójna krop
 <!-- The most common range specification is the double-dot syntax. This basically asks Git to resolve a range of commits that are reachable from one commit but aren’t reachable from another. For example, say you have a commit history that looks like Figure 6-1. -->
 
 Insert 18333fig0601.png
-Figure 6-1. Przykładowa historia dla wskazania zakresu zmian.
+Rysunek 6-1. Przykładowa historia dla wskazania zakresu zmian.
 
 <!-- Figure 6-1. Example history for range selection. -->
 
diff --git a/pl/07-customizing-git/01-chapter7.markdown b/pl/07-customizing-git/01-chapter7.markdown
index f7346cd0d..12865f217 100644
--- a/pl/07-customizing-git/01-chapter7.markdown
+++ b/pl/07-customizing-git/01-chapter7.markdown
@@ -285,7 +285,7 @@ Zamiast wyniku pokazanego w wierszu poleceń, Git uruchomi P4Merge, pokazując w
 <!-- Instead of getting the diff output on the command line, Git fires up P4Merge, which looks something like Figure 7-1. -->
 
 Insert 18333fig0701.png
-Figure 7-1. P4Merge.
+Rysunek 7-1. P4Merge.
 
 Jeżeli spróbujesz wykonać łączenie (ang. merge) na dwóch gałęziach, które zakończy się konfliktem, możesz uruchomić komendę `git mergetool`; zostanie uruchomiony skrypt P4Merge, pozwalający na rozwiązanie konfliktów poprzez interfejs graficzny GUI.
 
@@ -574,10 +574,10 @@ However, that result is of limited use. If you’ve used keyword substitution in
 It turns out that you can write your own filters for doing substitutions in files on commit/checkout. These are the "clean" and "smudge" filters. In the `.gitattributes` file, you can set a filter for particular paths and then set up scripts that will process files just before they’re checked out ("smudge", see Figure 7-2) and just before they’re committed ("clean", see Figure 7-3). These filters can be set to do all sorts of fun things.
 
 Insert 18333fig0702.png
-Figure 7-2. The “smudge” filter is run on checkout.
+Rysunek 7-2. The “smudge” filter is run on checkout.
 
 Insert 18333fig0703.png
-Figure 7-3. The “clean” filter is run when files are staged.
+Rysunek 7-3. The “clean” filter is run when files are staged.
 
 The original commit message for this functionality gives a simple example of running all your C source code through the `indent` program before committing. You can set it up by setting the filter attribute in your `.gitattributes` file to filter `*.c` files with the "indent" filter:
 
diff --git a/pl/09-git-internals/01-chapter9.markdown b/pl/09-git-internals/01-chapter9.markdown
index 9dafcad67..1b8b04533 100644
--- a/pl/09-git-internals/01-chapter9.markdown
+++ b/pl/09-git-internals/01-chapter9.markdown
@@ -173,7 +173,7 @@ W ogólnym zarysie, dane które Git przechowuje wyglądają podobnie do tych pok
 <!-- Conceptually, the data that Git is storing is something like Figure 9-1. -->
 
 Insert 18333fig0901.png
-Figure 9-1. Prosty przykład modelu danych w Git.
+Rysunek 9-1. Prosty przykład modelu danych w Git.
 
 <!-- Figure 9-1. Simple version of the Git data model. -->
 
@@ -240,7 +240,7 @@ Jeżeli odtworzyłeś katalog roboczy z drzewa które właśnie zapisałeś, otr
 <!-- If you created a working directory from the new tree you just wrote, you would get the two files in the top level of the working directory and a subdirectory named `bak` that contained the first version of the test.txt file. You can think of the data that Git contains for these structures as being like Figure 9-2. -->
 
 Insert 18333fig0902.png
-Figure 9-2. Zawartość struktury obecnych danych Git.
+Rysunek 9-2. Zawartość struktury obecnych danych Git.
 
 <!-- Figure 9-2. The content structure of your current Git data. -->
 
@@ -337,7 +337,7 @@ Jeżeli prześledzisz wszystkie wskaźniki, dostaniesz widok obiektów podobny d
 <!-- If you follow all the internal pointers, you get an object graph something like Figure 9-3. -->
 
 Insert 18333fig0903.png
-Figure 9-3. Wszystkie obiekty w Twoim repozytorium Gita.
+Rysunek 9-3. Wszystkie obiekty w Twoim repozytorium Gita.
 
 <!-- Figure 9-3. All the objects in your Git directory. -->
 
@@ -456,7 +456,7 @@ W tej chwili, Twoja baza w Git wygląda podobnie do tej z rysunka 9-4.
 <!-- Now, your Git database conceptually looks something like Figure 9-4. -->
 
 Insert 18333fig0904.png
-Figure 9-4. Obiekty w katalogach Git z uwzględnieniem referencji do gałęzi.
+Rysunek 9-4. Obiekty w katalogach Git z uwzględnieniem referencji do gałęzi.
 
 <!-- Figure 9-4. Git directory objects with branch head references included. -->
 

From 8df927becc61ef4eb87715184bee0241c006bd78 Mon Sep 17 00:00:00 2001
From: Petr Prikryl <prikryl@atlas.cz>
Date: Wed, 27 Aug 2014 23:01:13 +0200
Subject: [PATCH 602/690] [cs] revision of the part of ch. 4

---
 cs/04-git-server/01-chapter4.markdown | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/cs/04-git-server/01-chapter4.markdown b/cs/04-git-server/01-chapter4.markdown
index 10929a1fc..48228acbe 100644
--- a/cs/04-git-server/01-chapter4.markdown
+++ b/cs/04-git-server/01-chapter4.markdown
@@ -158,9 +158,9 @@ Pokud provádíte nastavení jen pro malý okruh lidí nebo jen zkoušíte Git v
 
 Jestliže už máte server, k němuž mají všichni vaši vývojáři SSH přístup, bude většinou nejjednodušší nastavit první repozitář tam, protože celé nastavení už tím máte v podstatě hotové (jak jsme ukázali v předchozí části). Pokud chcete pro své repozitáře nastavit komplexnější správu oprávnění, můžete je opatřit běžnými oprávněními k systému souborů, které vám nabízí operační systém daného serveru.
 
-Pokud chcete své repozitáře umístit na server, jenž nemá účty pro všechny členy vašeho týmu, kteří by měli mít oprávnění k zápisu, musíte pro ně nastavit SSH přístup. Předpokládáme, že pokud máte server, na němž to lze provést, máte už nainstalován server SSH. Tímto způsobem získáte přístup na server.
+Pokud chcete své repozitáře umístit na server, jenž nemá účty pro všechny členy vašeho týmu, kteří by měli mít oprávnění k zápisu, musíte pro ně nastavit SSH přístup. Předpokládáme, že pokud máte server, na němž to lze provést, máte už nainstalován server SSH a jeho prostřednictvím k serveru přistupujete.
 
-Existuje několik způsobů, jak umožnit přístup všem členům vašeho týmu. Prvním způsobem je nastavit účty pro všechny, což není složité, ale může být poněkud zdlouhavé. Možná nebudete mít chuť spouštět příkaz `adduser` (přidat uživatele) a nastavovat dočasná hesla pro každého uživatele zvlášť.
+Existuje několik způsobů, jak umožnit přístup všem členům vašeho týmu. Prvním způsobem je nastavit účty pro všechny, což je sice přímočaré, ale může to být poněkud zdlouhavé. Možná nebudete mít chuť spouštět příkaz `adduser` (přidat uživatele) a nastavovat pro každého uživatele dočasná hesla.
 
 Druhým způsobem je vytvořit na počítači jediného uživatele 'git', požádat všechny uživatele, kteří mají mít oprávnění k zápisu, aby vám poslali veřejný SSH klíč, a přidat tento klíč do souboru `~/.ssh/authorized_keys` vašeho nového uživatele 'git'. Nyní budou mít všichni přístup k tomuto počítači prostřednictvím uživatele 'git'. Tento postup nemá žádný vliv na data vašich revizí – SSH uživatel, jehož účtem se přihlašujete, neovlivní revize, které jste nahráli.
 
@@ -168,7 +168,7 @@ Dalším možným způsobem je nechat ověřovat SSH přístupy LDAP serveru neb
 
 ## Vygenerování veřejného SSH klíče ##
 
-Mnoho serverů Git provádí ověřování pomocí veřejných SSH klíčů. Aby vám mohli všichni uživatelé ve vašem systému poskytnout veřejný klíč, musí si ho nechat vygenerovat (pokud klíč ještě nemají). Tento proces se napříč operačními systémy téměř neliší.
+Mnoho serverů Git provádí ověřování totožnosti pomocí veřejných SSH klíčů. Aby vám mohli všichni uživatelé ve vašem systému poskytnout veřejný klíč, musí si ho každý z nich nechat vygenerovat (pokud klíč ještě nemá). Tento proces se napříč operačními systémy téměř neliší.
 Nejprve byste se měli ujistit, že ještě žádný klíč nemáte. Uživatelské SSH klíče jsou standardně uloženy v adresáři `~/.ssh` daného uživatele. Nejsnazší způsob kontroly, zda už klíč vlastníte, je přejít do tohoto adresáře a zjistit jeho obsah:
 
 	$ cd ~/.ssh
@@ -188,7 +188,7 @@ Zobrazí se několik souborů s názvem `xxx` a `xxx.pub`, kde `xxx` je většin
 	The key fingerprint is:
 	43:c5:5b:5f:b1:f1:50:43:ad:20:a6:92:6a:1f:9a:3a schacon@agadorlaptop.local
 
-Program nejprve potvrdí, kam chcete klíč uložit (`.ssh/id_rsa`), a poté se dvakrát zeptá na přístupové heslo. Pokud nechcete při používání klíče zadávat heslo, nemusíte ho nyní vyplňovat.
+Program nejprve potvrdí, kam chcete klíč uložit (`.ssh/id_rsa`), a poté se dvakrát zeptá na přístupové heslo. Pokud nechcete při používání klíče zadávat heslo, můžete ho nyní nechat prázdné.
 
 Každý uživatel, který si tímto způsobem nechá vygenerovat veřejný klíč, ho nyní pošle vám nebo jinému správci serveru Git (za předpokladu, že používáte nastavení SSH serveru vyžadující veřejné klíče). Stačí přitom zkopírovat obsah souboru `.pub` a odeslat ho e-mailem. Veřejné klíče mají zhruba tuto podobu:
 
@@ -204,7 +204,7 @@ Budete-li potřebovat podrobnější návod k vytvoření SSH klíče v různýc
 
 ## Nastavení serveru ##
 
-Podívejme se nyní na nastavení SSH přístupu na straně serveru. V tomto příkladu použijeme k ověření identity uživatelů metodu `authorized_keys`. Předpokládáme také, že pracujete se standardní linuxovou distribucí, jako je např. Ubuntu. Nejprve vytvoříte uživatele 'git' a adresář `.ssh` pro tohoto uživatele.
+Projděme si nastavení SSH přístupu na straně serveru. V tomto příkladu použijeme k ověření identity uživatelů metodu `authorized_keys`. Předpokládáme také, že pracujete se standardní linuxovou distribucí, jako je např. Ubuntu. Nejprve vytvoříte uživatele 'git' a adresář `.ssh` pro tohoto uživatele.
 
 	$ sudo adduser git
 	$ su git
@@ -238,7 +238,7 @@ Nyní pro ně můžete nastavit prázdný repozitář. Spusťte příkaz `git in
 	$ cd project.git
 	$ git --bare init
 
-John, Josie a Jessica pak mohou do tohoto repozitáře odeslat první verzi svého projektu: přidají si ho jako vzdálený repozitář a odešlou do něj svou větev. Nezapomeňte, že pokaždé, když chcete přidat projekt, se musí k počítači někdo přihlásit a vytvořit holý repozitář. Pro server, na kterém jste nastavili uživatele 'git' a repozitář, můžeme použít název hostitele `gitserver`. Pokud server provozujete interně a nastavíte DNS pro `gitserver` tak, aby ukazovalo na tento server, můžete používat i takovéto příkazy:
+John, Josie a Jessica pak mohou do tohoto repozitáře odeslat první verzi svého projektu: přidají si ho jako vzdálený repozitář a odešlou do něj svou větev. Nezapomeňte, že pokaždé, když chcete vytvořit projekt, musí se k počítači někdo přihlásit a vytvořit holý repozitář. Pro server, na kterém jste nastavili uživatele 'git' a repozitář, můžeme použít název hostitele `gitserver`. Pokud server provozujete interně a nastavíte DNS pro `gitserver` tak, aby ukazovalo na tento server, můžete používat i takovéto příkazy:
 
 	# on Johns computer
 	$ cd myproject
@@ -258,7 +258,7 @@ Ostatní nyní mohou velmi snadno repozitář naklonovat i do něj odesílat zm
 
 Tímto způsobem lze rychle vytvořit a spustit server Git ke čtení i zápisu pro menší počet vývojářů.
 
-Pro větší bezpečnost máte možnost využít nástroj `git-shell`, který je distribuován se systémem Git. Pomocí něj lze snadno nastavit, aby uživatel 'git' prováděl pouze operace systému Git. Pokud ho nastavíte jako přihlašovací shell uživatele 'git', pak nebude mít uživatel 'git' normální shellový přístup k vašemu serveru. Chcete-li nástroj použít, zadejte pro přihlašovací shell vašeho uživatele `git-shell` místo bash nebo csh. V takovém případě pravděpodobně budete muset upravit soubor `/etc/passwd`:
+Pro větší bezpečnost máte možnost využít nástroj `git-shell`, který je distribuován se systémem Git. Pomocí něj lze uživatele 'git' snadno omezit tak, aby mohl prováděl pouze operace systému Git. Pokud ho nastavíte jako přihlašovací shell uživatele 'git', pak nebude mít uživatel 'git' normální shellový přístup k vašemu serveru. Chcete-li nástroj použít, zadejte pro přihlašovací shell vašeho uživatele `git-shell` místo bash nebo csh. V takovém případě pravděpodobně budete muset upravit soubor `/etc/passwd`:
 
 	$ sudo vim /etc/passwd
 

From 083cfaab89828d5fcb3fa1561fcd0f115627eb96 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Thu, 28 Aug 2014 14:16:55 +0200
Subject: [PATCH 603/690] Updating macports git package name

git-core has been made obsolete by the port git
---
 it/01-introduction/01-chapter1.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/it/01-introduction/01-chapter1.markdown b/it/01-introduction/01-chapter1.markdown
index 695b407af..4a9dfc8d2 100644
--- a/it/01-introduction/01-chapter1.markdown
+++ b/it/01-introduction/01-chapter1.markdown
@@ -170,7 +170,7 @@ Figura 1-7. Installer di Git per OS X.
 
 L'altro metodo è installare Git con MacPorts (`http://www.macports.org`). Se hai MacPorts installato puoi farlo con:
 
-	$ sudo port install git-core +svn +doc +bash_completion +gitweb
+	$ sudo port install git +svn +doc +bash_completion +gitweb
 
 Non ti occorre aggiungere tutti i pacchetti extra, ma probabilmente vorrai includere +svn, nel caso tu debba usare Git con i repository di Subversion (vedi Capitolo 8).
 

From f8dac602fb74d95e0f258acacc91270be82d6b94 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Thu, 28 Aug 2014 14:23:25 +0200
Subject: [PATCH 604/690] [it] reviewing translation for chapter4

---
 it/04-git-server/01-chapter4.markdown | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/it/04-git-server/01-chapter4.markdown b/it/04-git-server/01-chapter4.markdown
index 388095f08..514cd51f0 100644
--- a/it/04-git-server/01-chapter4.markdown
+++ b/it/04-git-server/01-chapter4.markdown
@@ -739,19 +739,19 @@ GitHub è leggermente differente nello spazio dei nomi che usa per i progetti ri
 
 GitHub è inoltre una organizzazione commerciale che addebita gli account che mantengono repository privati, ma chiunque può avere un account libero per ospitare qualsiasi progetto open source come preferisce. Vedremo velocemente come ottenere ciò.
 
-### Configurare un Account Utente ###
+### Configurare un account ###
 
-La prima cosa di cui hai bisogno è configurare un account utente gratuito. Se visiti la pagina "Plans and pricing" all'inidirizzo `http://https://github.com/pricing` e fai click sul pulsante "Sign Up" per un account gratuito (vedi figura 4-2), sarai portato alla pagina di iscrizione.
+La prima cosa di cui hai bisogno di un account gratuito. Vai alla pagina "Plans and pricing", che trovi all'inidirizzo `http://https://github.com/pricing`, e clicca sul pulsante "Sign Up" per creare un account gratuito (vedi figura 4-2), sarai portato alla pagina di iscrizione.
 
 Insert 18333fig0402.png
 Figura 4-2. La pagina dei piani di GitHub.
 
-Qui devi scegliere un nome utente che non è già stato scelto nel sistema ed inserire un indirizzo e-mail che verrà associato all'account e una password (vedi Figura 4-3).
+Qui devi scegliere un nome utente che non sia già stato scelto da qualcun altro, indicare un indirizzo e-mail che verrà associato all'account e una password (vedi Figura 4-3).
 
 Insert 18333fig0403.png 
 Figura 4-3. Il form di iscrizione di GitHub.
 
-Se ne hai una, è buona cosa aggiungere la propria chiave pubblica SSH. Abbiamo già visto come generare una nuova chiave, nella sezione "Piccole Configurazioni". Prendi il contenuto della chiave pubblica della tua coppia di chiavi, ed incollala nel box SSH Public Key. Facendo click sul link "explain ssh keys" otterrai le istruzioni dettagliate su come fare questa cosa sui maggiori sistemi operativi.
+Se già ne hai una, è buona cosa aggiungere la propria chiave pubblica SSH. Abbiamo già visto come generare una nuova chiave, nella sezione "Piccole Configurazioni". Prendi il contenuto della chiave pubblica della tua coppia di chiavi, ed incollala nel box SSH Public Key. Facendo click sul link "explain ssh keys" otterrai le istruzioni dettagliate su come fare questa cosa sui maggiori sistemi operativi.
 Cliccare il pulsante "I agree, sign me up" ti porta al tuo nuovo pannello utente (vedi Figura 4-4).
 
 Insert 18333fig0404.png 

From 9bd72636f2bfe006a57a44cf3f3a7012203f2888 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Thu, 28 Aug 2014 14:44:52 +0200
Subject: [PATCH 605/690] [it] improving translation

---
 it/01-introduction/01-chapter1.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/it/01-introduction/01-chapter1.markdown b/it/01-introduction/01-chapter1.markdown
index 695b407af..e46791bb5 100644
--- a/it/01-introduction/01-chapter1.markdown
+++ b/it/01-introduction/01-chapter1.markdown
@@ -161,7 +161,7 @@ O, se usi una distribuzione basata su Debian (come Ubuntu) prova apt-get:
 
 ### Installazione su Mac ###
 
-Ci sono due metodi per installare Git su Mac. Il più semplice è usare l'installer grafico di Git, che puoi scaricare dalla pagina di SourceForge (vedi Figura 1-7):
+Ci sono due metodi per installare facilmente Git su Mac. Il più semplice è usare l'installazione l'installer grafico di Git, che puoi scaricare da SourceForge (vedi Figura 1-7):
 
 	http://sourceforge.net/projects/git-osx-installer/
 

From f004712b5c07a26b884f8a89d4f6b02353b1e4f7 Mon Sep 17 00:00:00 2001
From: Petr Prikryl <prikryl@atlas.cz>
Date: Thu, 28 Aug 2014 15:41:43 +0200
Subject: [PATCH 606/690] [cs] revision of chapter 4 finished

---
 cs/04-git-server/01-chapter4.markdown | 80 +++++++++++++--------------
 1 file changed, 40 insertions(+), 40 deletions(-)

diff --git a/cs/04-git-server/01-chapter4.markdown b/cs/04-git-server/01-chapter4.markdown
index 48228acbe..3dd7abd9b 100644
--- a/cs/04-git-server/01-chapter4.markdown
+++ b/cs/04-git-server/01-chapter4.markdown
@@ -326,7 +326,7 @@ Tímto způsobem můžete během pár minut nastavit oprávnění pro čtení za
 
 ## GitWeb ##
 
-Nyní, když máte ke svému projektu nastavena základní oprávnění pro čtení/zápis a pouze pro čtení, možná budete chtít nastavit jednoduchou online vizualizaci. Git vám nabízí CGI skript s názvem GitWeb, který slouží k tomuto účelu. Jak GitWeb funguje, na to se můžete podívat např. na stránkách `http://git.kernel.org` (viz obrázek 4-1).
+Nyní, když máte ke svému projektu nastavena základní oprávnění pro čtení/zápis a pouze pro čtení, možná budete chtít nastavit jednoduchou online vizualizaci. Git vám nabízí CGI skript s názvem GitWeb, který se k tomuto účelu běžně používá. V činnosti můžete GitWeb pozorovat například na stránkách `http://git.kernel.org` (viz obrázek 4-1).
 
 Insert 18333fig0401.png
 Obrázek 4-1. Online uživatelské rozhraní GitWeb
@@ -364,7 +364,7 @@ Všimněte si, že musíte příkazu pomocí proměnné `GITWEB_PROJECTROOT` sd
 	    </Directory>
 	</VirtualHost>
 
-Také GitWeb může být obsluhován jakýmkoli webovým serverem umožňujícím CGI. Chcete-li používat jakýkoli jiný server, nemělo by být nastavení obtížné. V tomto okamžiku byste měli být schopni prohlížet své repozitáře online na adrese `http://gitserver/` a používat `http://git.gitserver` ke klonování a vyzvedávání repozitářů prostřednictvím protokolu HTTP.
+Znovu připomeňme, že GitWeb může být obsluhován jakýmkoli webovým serverem podporujícím CGI. Chcete-li používat jakýkoli jiný server, nemělo by být nastavení obtížné. V tomto okamžiku byste měli být schopni prohlížet své repozitáře online na adrese `http://gitserver/` a používat `http://git.gitserver` ke klonování a vyzvedávání repozitářů prostřednictvím protokolu HTTP.
 
 ## Gitosis ##
 
@@ -374,7 +374,7 @@ Proto možná rádi přejdete na rozšířený softwarový projekt „Gitosis“
 
 Instalace nástroje Gitosis sice nepatří mezi nejsnazší, ale není ani příliš složitá. Nejjednodušší je k ní použít linuxový server – tyto příklady používají běžný Ubuntu server 8.10.
 
-Gitosis vyžaduje některé nástroje v jazyce Python, a proto první, co musíte udělat, je nainstalovat balíček nástrojů nastavení Python, který je v Ubuntu dostupný jako python-setuptools:
+Gitosis vyžaduje některé nástroje v jazyce Python, a proto první, co musíte udělat, je nainstalovat pythonovský balíček setuptools, který je v Ubuntu dostupný jako python-setuptools:
 
 	$ apt-get install python-setuptools
 
@@ -392,7 +392,7 @@ Gitosis teď bude spravovat klíče za vás. Proto je třeba, abyste odstranili
 
 	$ mv /home/git/.ssh/authorized_keys /home/git/.ssh/ak.bak
 
-Dále musíte znovu zapnout shell na uživatele 'git', jestliže jste ho změnili na příkaz `git-shell`. Uživatelé se stále ještě nebudou moci přihlásit, ale Gitosis za vás bude provádět správu. V souboru `/etc/passwd` tak nyní změníme řádek:
+Dále musíte znovu zapnout shell na uživatele 'git', jestliže jste ho změnili na příkaz `git-shell`. Uživatelé se stále ještě nebudou moci přihlásit, ale Gitosis za vás bude provádět správu. Takže v souboru `/etc/passwd` změňte následující řádek
 
 	git:x:1000:1000::/home/git:/usr/bin/git-shell
 
@@ -400,17 +400,17 @@ zpět na
 
 	git:x:1000:1000::/home/git:/bin/sh
 
-V tomto okamžiku můžeme inicializovat nástroj Gitosis. Učiníte tak spuštěním příkazu `gitosis-init` se svým osobním veřejným klíčem. Není-li váš veřejný klíč na serveru, bude ho tam nutné zkopírovat:
+V tomto okamžiku můžeme inicializovat nástroj Gitosis. Učiníte tak spuštěním příkazu `gitosis-init` se svým osobním veřejným klíčem. Není-li váš veřejný klíč na serveru, musíte ho tam nakopírovat:
 
 	$ sudo -H -u git gitosis-init < /tmp/id_dsa.pub
 	Initialized empty Git repository in /opt/git/gitosis-admin.git/
 	Reinitialized existing Git repository in /opt/git/gitosis-admin.git/
 
-Uživatel s tímto klíčem poté bude moci měnit hlavní repozitář Git, který kontroluje nastavení nástroje Gitosis. Dále je třeba ručně nastavit právo spuštění na skriptu `post-update` pro nový řídicí repozitář.
+Uživatel s tímto klíčem poté bude moci měnit hlavní repozitář Git, kterým se ovládá nastavení nástroje Gitosis. Dále je třeba ručně nastavit právo spuštění na skriptu `post-update` pro nový řídicí repozitář.
 
 	$ sudo chmod 755 /opt/git/gitosis-admin.git/hooks/post-update
 
-Nyní máte vše hotovo. Pokud jste nastavení provedli správně, můžete vyzkoušet SSH přístup na server jako uživatel, pro kterého jste přidali veřejný klíč při inicializaci nástroje Gitosis. Mělo by se zobrazit asi následující:
+Teď to můžete rozjet. Pokud jste nastavení provedli správně, můžete vyzkoušet SSH přístup na server jako uživatel, pro kterého jste přidali veřejný klíč při inicializaci nástroje Gitosis. Mělo by se zobrazit asi následující:
 
 	$ ssh git@gitserver
 	PTY allocation request failed on channel 0
@@ -516,20 +516,20 @@ Máte-li jakékoli problémy, může vám pomoci zadání `loglevel=DEBUG` do č
 
 ## Gitolite ##
 
-Git se stal hodně populárním v korporátním prostředí, které obvykle mívá další doplňující požadavky na kontrolu přístupu. Nástroj Gitolite byl vytvořen právě na řešení těchto požadavků.
+Tato podkapitola slouží k rychlému seznámení s Gitolite a uvádí základní pokyny pro instalaci a nastavení. Nemůže ale nahradit ohromný objem [dokumentace][gltoc], která se s Gitolite dodává. Tato podkapitola se může občas změnit, takže se možná chcete podívat na její [poslední verzi][gldpg].
 
 [gldpg]: http://sitaramc.github.com/gitolite/progit.html
 [gltoc]: http://sitaramc.github.com/gitolite/master-toc.html
 
 Gitolite je autorizační vrstva nad gitem, která při autentizaci spoléhá na `sshd` nebo `httpd`. (Připomeňme si: autentizace spočívá v rozpoznání uživatele, autorizací rozumíme rozhodování, zda má povolení k provádění toho, co se provést pokouší.)
 
-Gitolite umožňuje nastavit přístupová práva nejen na repozitáře (podobně jako Gitosis), ale také na větve a značky v každém repozitáři. To znamená, že lze nastavit, aby určití lidé mohli odesílat jen do určité reference (větve nebo značky) a do jiné ne.
+Gitolite umožňuje nastavit přístupová práva nejen na repozitáře (podobně jako Gitosis), ale také na větve a značky v každém repozitáři. To znamená, že lze nastavit, aby určití lidé mohli odesílat jen do určité větve (nebo určité značky; obecně „refs“), ale do jiné ne.
 
 ### Instalace ###
 
-Instalace Gitolite je velmi jednoduchá a to i když nebudete číst obsáhlou dokumentaci, která je k dispozici. Budete potřebovat účet na nějakém unixovém serveru (bylo testováno na různých distribucích Linuxu a na Solarisu 10), kde musí být nainstalovány git, Perl a SSH server kompatibilní s OpenSSH. V příkladech uvedených níže budeme používat účet `git` na serveru `gitserver`.
+Instalace Gitolite je velmi jednoduchá a to i když si nepřečtete obsáhlou dokumentaci, která je k dispozici. Budete potřebovat účet na nějakém unixovém serveru. Pokud už jsou nainstalovány nástroje Git, Perl a SSH server kompatibilní s OpenSSH, nebudete potřebovat ani přístup root. V příkladech uvedených níže budeme používat účet `git` na serveru `gitserver`.
 
-Nástroj Gitolite je ve smyslu „serverového“ softwaru poněkud neobvyklý. Přístup se realizuje přes ssh, takže každá serverová userid je potenciálně „hostitelem gitolite“ (gitolite host). Teď si popíšeme nejjednodušší způsob instalace. V dokumentaci naleznete další metody.
+Nástroj Gitolite je ve smyslu „serverového“ softwaru poněkud neobvyklý. Přístup se realizuje přes SSH, takže každá serverová userid je potenciálně „hostitelem gitolite“ (gitolite host). Teď si popíšeme nejjednodušší způsob instalace. V dokumentaci naleznete další metody.
 
 Začněte tím, že na serveru vytvoříte uživatele nazvaného `git` a přihlásíte se na něj. Z vaší pracovní stanice nakopírujte svůj veřejný SSH klíč (pokud jste spustili `ssh-keygen` s implicitními hodnotami, jde o soubor `~/.ssh/id_rsa.pub`) a přejmenujte jej na `<vasejmeno>.pub` (v příkladech budeme používat `scott.pub`). Potom proveďte následující příkazy:
 
@@ -548,7 +548,7 @@ Základní rychlá metoda instalace bude většině lidí vyhovovoat. V případ
 
 ### Konfigurační soubor a pravidla přístupu ###
 
-Přepněte se do repozitáře `gitolite-admin` (je umístěn ve vašem domácím adresáři), jakmile je instalace dokončena, a podívejte se co tam je:
+Jakmile je instalace dokončena, přepněte se do repozitáře `gitolite-admin`, který jste naklonovali na váš počítač, a podívejte se co tam je:
 
 	$ cd ~/gitolite-admin/
 	$ ls
@@ -568,9 +568,9 @@ Všimněte si, že „scott“ (jméno veřejného klíče v dříve použitém
 
 Přidávání dalších uživatelů je snadné. Pokud chceme přidat uživatele „alice“, získáme její veřejný klíč, pojmenujeme jej `alice.pub` a umístíme jej do adresáře `keydir`. Je součástí klonu repozitáře `gitolite-admin`, který jsme právě vytvořili na pracovní stanici. Přidáme, potvrdíme a odešleme změny (add, commit, push). Tím jsme dosáhli přidání uživatele.
 
-Syntaxe konfiguračního souboru pro Gitolite je dobře dokumentovaná, takže zde uvedu jen pár zajímavých věcí.
+Syntaxe konfiguračního souboru pro Gitolite je dobře dokumentovaná, takže zde zdůrazníme jen pár věcí.
 
-Pro usnadnění můžete dávat uživatele i repozitáře do skupin. Jména skupin jsou podobná jako makra; když je definujete, je úplně jedno jestli jde o projekty nebo uživatele; rozdíl to je až v momentu, kdy „makro“ *použijete*.
+Pro usnadnění můžete uživatele i repozitáře sdružovat do skupin. Jména skupin se chovají jako makra; když je definujete, je úplně jedno jestli jde o projekty nebo uživatele; rozdíl se pozná až v momentu, kdy „makro“ *použijete*.
 
 	@oss_repos      = linux perl rakudo git gitolite
 	@secret_repos   = fenestra pear
@@ -588,7 +588,7 @@ Můžete nastavovat přístupová práva na úrovni referencí. Skupina interns
 	    RW  refs/tags/rc[0-9]   = @engineers
 	    RW+                     = @admins
 
-Výraz za `RW` nebo `RW+` je regulární výraz (regex), se kterým se porovnává jméno odesílané reference. Nazvěme jej tedy „refex“! Refex může mít samozřejmě mnohem více použití než je tady ukázáno, takže si dejte pozor ať to nepřeženete, zvláště pokud se necítíte experty na regulární výrazy.
+Výraz za `RW` nebo `RW+` je regulární výraz (regex), se kterým se porovnává jméno odesílané reference (ref). Nazvěme jej tedy „refex“! Refex může mít samozřejmě mnohem více použití než je tady ukázáno, takže si dejte pozor ať to nepřeženete, zvláště pokud nejste kovaní v perlovských regulárních výrazech.
 
 Gitolite přidává prefix `refs/heads/` jako usnadnění syntaxe, pokud refex nezačíná na `refs/`, jak jste mohli odhadnout z příkladu.
 
@@ -597,17 +597,17 @@ Důležitou vlastností syntaxe konfiguračního souboru je to, že všechna pra
 	repo gitolite
 	    RW+                     = sitaram
 
-Toto pravidlo se pak přidá do skupiny pravidel `gitolite` repozitáře.
+Toto pravidlo se pak přidá do skupiny pravidel repozitáře `gitolite`.
 
 Teď by vás mohlo zajímat, jak jsou vlastně pravidla pro přístup aplikována, pojďme se na to tedy krátce podívat.
 
-V gitolite jsou dvě úrovně kontroly přístupů. První je úroveň repozitářů; jestliže máte práva na čtení (nebo zápis) *k jakékoliv* referenci v repozitáři, máte tím práva na čtení (nebo zápis) k tomuto repozitáři. Tohle je jediná možnost jakou měl nástroj Gitosis.
+V Gitolite jsou dvě úrovně kontroly přístupů. První je úroveň repozitářů; jestliže máte práva na čtení (nebo zápis) *k jakékoliv* referenci v repozitáři, máte tím práva na čtení (nebo zápis) k tomuto repozitáři. Tohle je jediná možnost jakou měl nástroj Gitosis.
 
-Druhá úroveň je pouze pro práva pro „zápis“ a je podle větve nebo značky v repozitáři. Uživatelské jméno uživatele snažícího se o přístup (`W` nebo `+`) a jméno reference, kterou uživatel chce aktualizovat, jsou dané. Pravidla pro přístup jsou procházena postupně v pořadí, tak jak jsou uvedena v konfiguračním souboru a hledají se záznamy odpovídající této kombinaci uživatelského jména a reference (nezapomeňte ale, že refname se porovnává jako regulární výraz nikoliv jako pouhý řetězec). Jestliže je nalezen odpovídající záznam, odesílání je povoleno. Pokud není nalezeno nic, je přístup zamítnut.
+Druhá úroveň se dá použít jen pro práva pro „zápis“ a vázána na větve nebo značky v repozitáři. Uživatelské jméno uživatele snažícího se o přístup (`W` nebo `+`) a jméno reference, kterou uživatel chce aktualizovat, jsou dané. Pravidla pro přístup jsou procházena postupně v pořadí, tak jak jsou uvedena v konfiguračním souboru a hledají se záznamy odpovídající této kombinaci uživatelského jména a reference (nezapomeňte ale, že refname se porovnává jako regulární výraz nikoliv jako pouhý řetězec). Jestliže je nalezen odpovídající záznam, odesílání je povoleno. Pokud není nalezeno nic, je přístup zamítnut.
 
 ### Rozšířené řízení přístupu pravidly typu „odmítnutí“ ###
 
-Prozatím jsme si ukázali jen oprávnění nastavená na jednu z hodnot `R`, `RW` nebo `RW+`. Ale Gitolite dovoluje nastavení dalšího oprávnění: `-` s významem „odmítnutí“. To vám dává mnohem více možností, ale za cenu zvýšení složitosti. Popadnutí sítem pravidel už totiž není *jedinou* možností vedoucí k zamítnutí přístupu. *Nyní už záleží na pořadí pravidel!*
+Prozatím jsme si ukázali jen oprávnění nastavená na jednu z hodnot `R`, `RW` nebo `RW+`. Ale Gitolite dovoluje nastavení dalšího oprávnění: `-` s významem „odmítnutí“. To vám dává mnohem více možností, ale za cenu zvýšení složitosti. Popadnutí sítem pravidel už totiž není *jedinou* možností vedoucí k zamítnutí přístupu. *Záleží na pořadí pravidel!*
 
 Řekněme, že ve výše uvedené situaci budeme chtít, aby skupina engineers mohla vracet změny v jakékoliv větvi *s výjimkou* větví `master` a `integ`. Udělá se to následovně:
 
@@ -619,28 +619,28 @@ Pravidla se  budou opět procházet shora dolů až do momentu, kdy narazíte na
 
 ### Omezení odesílání změn vázané na soubory ###
 
-K omezení odesílání do určitých větví a určitými uživateli můžete přidat také omezení určující, které soubory mohou uživatelé měnit. Například  soubor Makefile (a možná některé programy) by asi neměl kdokoliv měnit, protože je na něm závislá řada dalších věcí. Pokud se neupraví *správným způsobem*, něco by se pokazilo. Nástroji gitolite můžeme říct:
+K omezení odesílání do určitých větví a určitými uživateli můžete přidat také omezení určující, které soubory mohou uživatelé měnit. Například  soubor Makefile (a možná některé programy) by asi neměl kdokoliv měnit, protože je na něm závislá řada dalších věcí. Pokud se neupraví *správným způsobem*, něco by se pokazilo. Nástroji Gitolite můžeme říct:
 
     repo foo
         RW                      =   @junior_devs @senior_devs
 
         -   VREF/NAME/Makefile  =   @junior_devs
 
-Uživatelé, kteří přecházejí ze starší verze gitolite by si měli dát pozor na to, že v souvislosti s uvedeným rysem došlo k výrazné změně chování. Věnujte prosím pozornost detailům, které jsou uvedeny v příručce pro přechod k nové verzi.
+Uživatelé, kteří přecházejí ze starší verze Gitolite by si měli dát pozor na to, že v souvislosti s uvedeným rysem došlo k výrazné změně chování. Věnujte prosím pozornost detailům, které jsou uvedeny v příručce pro přechod k nové verzi.
 
 ### Osobní větve ###
 
 Konečně Gitolite má také funkci, která se nazývá „osobní větve“ (nebo raději „jmenný prostor osobních větví“) a může být velmi užitečná v korporátním prostředí.
 
-Hodně výměny kódu probíhá v otevřeném git světě metodou „prosím stáhněte si“. V korporátním prostředí ovšem nebývá jakýkoliv neautorizovaný přístup vítán a pracovní stanice vývojáře nemůže provádět autentizaci, takže můžete na centrální server odesílat, ale musíte požádat někoho jiného, když odtud chcete stahovat.
+Hodně výměny kódu probíhá v otevřeném gitovém světě metodou „prosím stáhněte si“. V korporátním prostředí ovšem nebývá jakýkoliv přístup bez prokázání totožnosti vítán a pracovní stanice vývojáře nemůže provádět autentizaci, takže můžete na centrální server odesílat, ale musíte požádat někoho jiného, když odtud chcete stahovat.
 
-To by za normálních okolností způsobilo stejný zmatek ve jménech větví jako v centralizovaných systémech správy verzí a navíc nastavování přístupových práv by se stalo noční můrou pro administrátory.
+To by za normálních okolností způsobilo stejný zmatek ve jménech větví jako v centralizovaných systémech správy verzí a navíc nastavování přístupových práv by administrátorovi přidalo práci.
 
 Gitolite vám umožní nadefinovat pro každého vývojáře jmenné prostory s prefixy „personal“ nebo „scratch“ (např. `refs/personal/<devname>/*`). Podrobnosti hledejte v dokumentaci.
 
 ### „Wildcard“ repozitáře ###
 
-Gitolite vám umožní určit repozitáře zástupnými znaky (wildcards; ve skutečnosti jde o perlovské regulární výrazy) -- například k náhodnému výběru zadání příkladu můžeme použít `assignments/s[0-9][0-9]/a[0-9][0-9]`. Umožní nám též přidělit nový režim oprávnění (`C`), který uživatelům povoluje vytvářet repozitáře popsané zástupnými znaky, automaticky přidělí vlastnictví konkrétnímu uživateli, který jej vytvořil, umožní mu přidělit oprávnění `R` a `RW` dalším spolupracovníkům atd. Podrobnosti opět hledejte v dokumentaci.
+Gitolite vám umožní určit repozitáře zástupnými znaky (wildcards; ve skutečnosti jde o perlovské regulární výrazy) -- jako například u náhodně vybraného příkladu `assignments/s[0-9][0-9]/a[0-9][0-9]`. Umožní nám též přidělit nový režim oprávnění (`C`), který uživatelům povoluje vytvářet repozitáře popsané zástupnými znaky, automaticky přidělí vlastnictví konkrétnímu uživateli, který jej vytvořil, umožní mu přidělit oprávnění `R` a `RW` dalším spolupracovníkům atd. Podrobnosti opět hledejte v dokumentaci.
 
 ### Další vlastnosti ###
 
@@ -648,7 +648,7 @@ Vysvětlení Gitolite završíme přehledem několika vlastností, které jsou d
 
 **Logování:** Gitolite loguje všechny úspěšné přístupy. Jestliže máte volná pravidla pro přidělování oprávnění vracet změny (práva `RW+`) a stane se, že někdo takto „zkazí“ větev `master`, je tu ještě log soubor, který vám zachrání život, protože v něm můžete postižené SHA najít.
 
-**Přehledy uživatelských oprávnění:** Další příjemnou vlastností je to, co se stane, pokud se pouze pokusíte připojit pomocí SSH na server. Gitolite vám ukáže, ke kterým repozitářům máte přístup a s jakoými oprávněními. Příklad:
+**Přehledy uživatelských oprávnění:** Další příjemnou vlastností je to, co se stane, pokud se pouze pokusíte připojit pomocí SSH na server. Gitolite vám ukáže, ke kterým repozitářům máte přístup a s jakými oprávněními. Příklad:
 
         hello scott, this is git@git running gitolite3 v3.01-18-g9609868 on git 1.7.4.4
 
@@ -660,15 +660,15 @@ Vysvětlení Gitolite završíme přehledem několika vlastností, které jsou d
              R     indic_web_input
              R     shreelipi_converter
 
-**Delegace:** Pro opravdu velké instalace můžete delegovat zodpovědnost za skupiny a repozitáře dalším lidem a nechat je samotné spravovat jednotlivé části. To snižuje vytížení hlavního administrátora, který tím přestává být úským místem správy.
+**Delegace:** Pro opravdu velké instalace můžete delegovat zodpovědnost za skupiny a repozitáře dalším lidem a nechat je spravovat jednotlivé části nezávisle. To snižuje vytížení hlavního administrátora, který tím přestává být úzkým místem správy.
 
 **Zrcadlení:** Gitolite vám pomůže se správou více zrcadel a při výpadku hlavního serveru můžete snadno přepnout na jiný.
 
 ## Démon Git ##
 
-Jestliže potřebujete ke svým projektům veřejný, neověřovaný přístup pro čtení, budete muset překročit hranice vymezené protokolem HTTP a začít používat protokol Git. Mluví pro něj především rychlost. Protokol Git je daleko výkonnější, a proto také rychlejší než protokol HTTP a svým uživatelů tím ušetří spoustu času.
+Jestliže potřebujete ke svým projektům přístup pro čtení bez ověřování totožnosti, budete muset obejít protokol HTTP a začít používat protokol Git. Mluví pro něj především rychlost. Protokol Git je daleko výkonnější, a proto také rychlejší než protokol HTTP, takže uživatelům ušetří nějaký čas.
 
-I v tomto případě se jedná o neověřený přístup pouze pro čtení. Pokud protokol používáte na serveru mimo firewall, mělo by to být pouze u projektů, které jsou veřejně viditelné okolnímu světu. Pokud je server, na kterém protokol spouštíte, uvnitř firewallu, můžete ho používat u projektů, k nimž má přístup pro čtení velký počet lidí nebo počítačů (servery průběžné integrace nebo servery sestavení), jimž nechcete jednotlivě přiřazovat SSH klíče.
+I v tomto případě se jedná o přístup pouze pro čtení bez ověřování totožnosti. Pokud protokol používáte na serveru mimo firewall, mělo by to být pouze u projektů, které jsou veřejně viditelné okolnímu světu. Pokud je server, na kterém protokol spouštíte, uvnitř firewallu, můžete ho používat u projektů, k nimž má přístup pro čtení velký počet lidí nebo počítačů (servery průběžné integrace nebo servery sestavení), jimž nechcete jednotlivě přiřazovat SSH klíče.
 
 Ať tak či tak, na protokolu Git jistě oceníte jeho snadné nastavení. V podstatě je třeba spustit tento příkaz:
 
@@ -699,7 +699,7 @@ Při restartování počítače se démon Git spustí automaticky. V případě
 
 V jiných systémech možná budete chtít použít `xinetd`, skript systému `sysvinit`, nebo podobný skript – můžete-li spouštět příkaz démonizovaný a sledovaný.
 
-Dále budete muset svému serveru Gitosis sdělit, k jakým repozitářům si přejete povolit neověřený serverový přístup Git. Pokud přidáte jednu část pro každý repozitář, můžete určit repozitáře, z nichž si přejete dovolit démonovi Git načítat data. Chcete-li povolit přístup přes protokol Git k projektu `iphone_project`, přidejte ho na konec souboru `gitosis.conf`:
+Dále budete muset svému serveru Gitosis sdělit, k jakým repozitářům si přejete povolit neautentizovaný serverový přístup Git. Pokud pro každý repozitář přidáte sekci, můžete určit repozitáře, z nichž si přejete dovolit démonovi Git načítat data. Chcete-li povolit přístup přes protokol Git k projektu `iphone_project`, přidejte ho na konec souboru `gitosis.conf`:
 
 	[repo iphone_project]
 	daemon = yes
@@ -711,7 +711,7 @@ Pokud nechcete používat Gitosis, ale chcete nastavit démona Git, budete muset
 	$ cd /path/to/project.git
 	$ touch git-daemon-export-ok
 
-Přítomnost tohoto souboru systému Git sděluje, že si přejete obsluhovat tento projekt bez ověřování.
+Přítomnost tohoto souboru systému Git sděluje, že si přejete obsluhovat tento projekt bez ověřování totožnosti.
 
 Gitosis může také určovat, jaké projekty bude zobrazovat GitWeb. Nejprve budete muset do souboru `/etc/gitweb.conf` vložit následující:
 
@@ -730,15 +730,15 @@ Pokud teď zapíšete a odešlete projekt, GitWeb začne automaticky zobrazovat
 
 ## Hostování projektů Git ##
 
-Pokud nemáte chuť absolvovat celý proces nastavování vlastního serveru Git, existuje několik možností hostování vašich projektů Git na externím specializovaném hostingovém místě. Toto řešení vám nabízí celou řadu výhod. Hostingové místo má většinou velmi rychlé nastavení, snadno se na něm spouštějí projekty a nevyžaduje od vás správu ani monitoring serveru. Dokonce i když budete nastavovat a spouštět interně svůj vlastní server, budete možná přesto chtít použít veřejné hostingové místo pro otevřený zdrojový kód – komunita open source vývojářů si vás tak snáze najde a pomůže vám.
+Pokud nemáte chuť absolvovat celý proces nastavování vlastního serveru Git, existuje několik možností hostování vašich projektů Git na externím specializovaném hostingovém místě. Toto řešení vám nabízí celou řadu výhod. Hostingové místo má většinou velmi rychlé nastavení, snadno se na něm zakládají projekty a nevyžaduje od vás správu ani monitoring serveru. Dokonce i když budete nastavovat a spouštět interně svůj vlastní server, budete možná přesto chtít použít veřejné hostingové místo pro otevřený zdrojový kód – komunita open source vývojářů si vás tak snáze najde a pomůže vám.
 
-V dnešní době můžete vybírat z velkého počtu možností hostingu. Každá má jiné klady a zápory. Aktuální seznam těchto míst najdete na stránce GitHosting, dostupné z hlavní stránky GitWiki:
+V dnešní době můžete vybírat z velkého počtu možností hostingu. Každá má jiné klady a zápory. Aktuální seznam těchto míst najdete na následující stránce:
 
 	https://git.wiki.kernel.org/index.php/GitHosting
 
 Protože se tu nemůžeme věnovat všem možnostem a protože shodou okolností na jednom hostingovém místě pracuji, využijeme tuto část k tomu, abychom ukázali nastavení účtu a vytvoření nového projektu na serveru GitHub. Získáte tak představu, co všechno vás čeká.
 
-GitHub je zdaleka největším hostingovým místem pro projekty Git s otevřeným zdrojovým kódem a je zároveň jedním z velmi mála těch, která nabízejí možnosti jak veřejného, tak soukromého hostingu. Na jednom místě tak můžete mít uložen jak otevřený zdrojový kód, tak soukromý komerční kód. GitHub se ostatně soukromě podílel i na vzniku této knihy.
+GitHub je zdaleka největším hostingovým místem pro projekty Git s otevřeným zdrojovým kódem a je zároveň jedním z velmi mála těch, která nabízejí možnosti jak veřejného, tak soukromého hostingu. Na jednom místě tak můžete mít uložen jak otevřený zdrojový kód, tak soukromý komerční kód. Možnost soukromého použití GitHub jsme ostatně používali pro spolupráci při vzniku této knihy.
 
 ### GitHub ###
 
@@ -773,7 +773,7 @@ Začněte kliknutím na odkaz „create a new one“ (vytvořit nový) vedle nad
 Insert 18333fig0405.png
 Obrázek 4-5. Vytvoření nového repozitáře na serveru GitHub
 
-Vše, co tu bezpodmínečně musíte udělat, je zadat název projektu. Kromě toho můžete přidat i jeho popis. Poté klikněte na tlačítko „Create Repository“ (Vytvořit repozitář). Nyní máte na serveru GitHub vytvořen nový repozitář (viz obrázek 4-6).
+Vše, co tu opravdu musíte udělat, je zadat název projektu. Kromě toho můžete přidat i jeho popis. Poté klikněte na tlačítko „Create Repository“ (Vytvořit repozitář). Nyní máte na serveru GitHub vytvořen nový repozitář (viz obrázek 4-6).
 
 Insert 18333fig0406.png
 Obrázek 4-6. Záhlaví s informacemi o projektu na serveru GitHub
@@ -805,7 +805,7 @@ Obrázek 4-8. Záhlaví projektu s veřejnou a soukromou adresou URL
 
 ### Import ze systému Subversion ###
 
-Máte-li existující veřejný projekt Subversion, který byste rádi importovali do systému Git, GitHub vám s tím často ochotně pomůže. Dole na stránce s instrukcemi najdete odkaz na import ze systému Subversion. Pokud na něj kliknete, zobrazí se formulář s informacemi o importu a textové pole, kam můžete vložit adresu URL svého veřejného projektu Subversion (viz obrázek 4-9).
+Máte-li existující veřejný projekt Subversion, který byste rádi importovali do systému Git, GitHub vám s tím obvykle pomůže. Dole na stránce s instrukcemi najdete odkaz na import ze systému Subversion. Pokud na něj kliknete, zobrazí se formulář s informacemi o importu a textové pole, kam můžete vložit adresu URL svého veřejného projektu Subversion (viz obrázek 4-9).
 
 Insert 18333fig0409.png
 Obrázek 4-9. Rozhraní importu ze systému Subversion
@@ -840,20 +840,20 @@ Po odeslání projektu nebo jeho naimportování ze systému Subversion budete m
 Insert 18333fig0413.png
 Obrázek 4-13. Hlavní stránka projektu na serveru GitHub
 
-Navštíví-li váš projekt ostatní uživatelé, tuto stránku uvidí. Obsahuje několik záložek k různým aspektům vašich projektů. Záložka „Commits“ zobrazuje seznam revizí v obráceném chronologickém pořadí, podobně jako výstup příkazu `git log`. Záložka „Network“ zobrazuje všechny uživatele, kteří rozštěpili váš projekt a přispěli do něj. Záložka „Downloads“ umožňuje nahrávat binární soubory k projektu a přidávat odkazy na tarbally a komprimované verze všech míst ve vašem projektu, které jsou označeny značkou (tagem). Záložka „Wiki“ vám nabízí stránku wiki, kam můžete napsat dokumentaci nebo jiné informace ke svému projektu. Záložka „Graphs“ graficky zobrazuje některé příspěvky a statistiky k vašemu projektu. Hlavní záložka „Source“, na níž se stránka otvírá, zobrazuje hlavní adresář vašeho projektu, a máte-li soubor README, automaticky ho zařadí na konec seznamu. Tato záložka obsahuje rovněž pole s informacemi o poslední zapsané revizi.
+Navštíví-li váš projekt ostatní uživatelé, tuto stránku uvidí. Obsahuje několik záložek k různým aspektům vašich projektů. Záložka „Commits“ zobrazuje seznam revizí v obráceném chronologickém pořadí, podobně jako výstup příkazu `git log`. Záložka „Network“ zobrazuje všechny uživatele, kteří se odštěpili od vašeho projektu a zase do něj přispěli. Záložka „Downloads“ umožňuje nahrávat binární soubory k projektu a přidávat odkazy na tarbally a komprimované verze všech míst ve vašem projektu, které jsou označeny značkou (tagem). Záložka „Wiki“ vám nabízí stránku wiki, kam můžete napsat dokumentaci nebo jiné informace ke svému projektu. Záložka „Graphs“ graficky zobrazuje některé příspěvky a statistiky k vašemu projektu. Hlavní záložka „Source“, na níž se stránka otvírá, zobrazuje hlavní adresář vašeho projektu, a máte-li soubor README, automaticky pod adresářem projektu zobrazí jeho obsah. Tato záložka obsahuje rovněž pole s informacemi o poslední zapsané revizi.
 
 ### Štěpení projektů ###
 
-Chcete-li přispět do existujícího projektu, k němuž nemáte oprávnění pro odesílání, umožňuje GitHub rozštěpení projektu. Pokud se dostanete na zajímavou stránku projektu a chtěli byste se do projektu zapojit, můžete kliknout na tlačítko „fork“ (rozštěpit) v záhlaví projektu a GitHub vytvoří kopii projektu pro vašeho uživatele. Do ní pak můžete odesílat revize.
+Chcete-li přispět do existujícího projektu, k němuž nemáte oprávnění pro odesílání, umožňuje GitHub rozštěpení projektu. Pokud se dostanete na zajímavou stránku projektu a chtěli byste se do projektu zapojit, můžete kliknout na tlačítko „fork“ (rozštěpit -- doslova vidlička) v záhlaví projektu a GitHub vytvoří kopii projektu pro vašeho uživatele. Do ní pak můžete odesílat revize.
 
-Díky tomu se projekty nemusí starat o přidávání uživatelů do role spolupracovníků, aby mohli odesílat své příspěvky. Uživatelé mohou projekt rozštěpit a odesílat do něj revize. Hlavní správce projektu tyto změny natáhne tím, že je přidá jako vzdálené repozitáře a začlení jejich data.
+Díky tomu se projekty nemusí starat o přidávání uživatelů do role spolupracovníků, kteří by měli právo zápisu. Uživatelé mohou projekt rozštěpit a odesílat do něj revize. Hlavní správce projektu tyto změny natáhne tím, že je přidá jako vzdálené repozitáře a začlení jejich data.
 
 Chcete-li projekt rozštěpit, přejděte na stránku projektu (v tomto případě mojombo/chronic) a klikněte na tlačítko „fork“ v záhlaví (viz obrázek 4-14).
 
 Insert 18333fig0414.png
 Obrázek 4-14. Zapisovatelnou kopii jakéhokoli repozitáře získáte kliknutím na tlačítko „fork“.
 
-Po několika sekundách přejdete na novou stránku svého projektu, která oznamuje, že je tento projekt rozštěpením (fork) jiného projektu (viz obrázek 4-15).
+Po několika sekundách přejdete na novou stránku svého projektu, která oznamuje, že je tento projekt odštěpen (fork) z jiného projektu (viz obrázek 4-15).
 
 Insert 18333fig0415.png
 Obrázek 4-15. Vaše rozštěpení projektu
@@ -868,4 +868,4 @@ Existuje několik možností, jak vytvořit a zprovoznit vzdálený repozitář
 
 Provoz vlastního serveru vám dává celou řadu možností kontroly a umožňuje provozovat server za vaším firewallem. Nastavení a správa takového serveru však obvykle bývají časově náročné. Umístíte-li data na hostovaný server, je jejich nastavení a správa jednoduchá. Svůj zdrojový kód však v takovém případě ukládáte na cizím serveru, což některé organizace nedovolují.
 
-Mělo by být jasně dáno, které řešení nebo jaká kombinace řešení je vhodná pro vás a pro vaši organizaci.
+Teď už byste se měli umět rozhodnout, které řešení nebo jaká kombinace řešení se pro vás a pro vaši organizaci hodí.

From a56e1a75549fb17b111df1cc2e8a94da6537bd6a Mon Sep 17 00:00:00 2001
From: Petr Prikryl <prikryl@atlas.cz>
Date: Thu, 28 Aug 2014 15:48:06 +0200
Subject: [PATCH 607/690] [cs] snippet updated in chapter 1

---
 cs/01-introduction/01-chapter1.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/cs/01-introduction/01-chapter1.markdown b/cs/01-introduction/01-chapter1.markdown
index 33aa76d00..6a29be757 100644
--- a/cs/01-introduction/01-chapter1.markdown
+++ b/cs/01-introduction/01-chapter1.markdown
@@ -170,7 +170,7 @@ Obrázek 1-7. Instalátor Git pro OS X
 
 Jiným obvyklým způsobem je instalace systému Git prostřednictvím systému MacPorts (`http://www.macports.org`). Máte-li systém MacPorts nainstalován, nainstalujte Git příkazem:
 
-	$ sudo port install git-core +svn +doc +bash_completion +gitweb
+	$ sudo port install git +svn +doc +bash_completion +gitweb
 
 Není nutné přidávat všechny doplňky, ale pokud budete někdy používat Git s repozitáři systému Subversion, budete pravděpodobně chtít nainstalovat i doplněk +svn (viz kapitola 8).
 

From 71619c4f5bba8d352d907b992b67bfdb8a4e2dae Mon Sep 17 00:00:00 2001
From: Andrew McCarthy <me@andrewmccarthy.ie>
Date: Thu, 28 Aug 2014 20:14:48 +0100
Subject: [PATCH 608/690] Remove mention of gitosis in gitolite section.

Gitosis is mentioned for no useful reason in the gitolite section.
Remove it (fixes #508).
---
 en/04-git-server/01-chapter4.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/en/04-git-server/01-chapter4.markdown b/en/04-git-server/01-chapter4.markdown
index 88bfff101..e4022c1b0 100644
--- a/en/04-git-server/01-chapter4.markdown
+++ b/en/04-git-server/01-chapter4.markdown
@@ -601,7 +601,7 @@ That rule will just get added to the ruleset for the `gitolite` repository.
 
 At this point you might be wondering how the access control rules are actually applied, so let’s go over that briefly.
 
-There are two levels of access control in Gitolite.  The first is at the repository level; if you have read (or write) access to *any* ref in the repository, then you have read (or write) access to the repository.  This is the only access control that Gitosis had.
+There are two levels of access control in Gitolite.  The first is at the repository level; if you have read (or write) access to *any* ref in the repository, then you have read (or write) access to the repository.
 
 The second level, applicable only to "write" access, is by branch or tag within a repository.  The username, the access being attempted (`W` or `+`), and the refname being updated are known.  The access rules are checked in order of appearance in the config file, looking for a match for this combination (but remember that the refname is regex-matched, not merely string-matched).  If a match is found, the push succeeds.  A fallthrough results in access being denied.
 

From 4db85c6bd52b056cf8e6d7714404cf3bcd9bee96 Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Thu, 28 Aug 2014 14:48:36 +0200
Subject: [PATCH 609/690] Adding homebrew as alternative to install git

It's very easy to install git with brew
---
 en/01-introduction/01-chapter1.markdown | 6 +++++-
 es/01-introduction/01-chapter1.markdown | 8 ++++++--
 it/01-introduction/01-chapter1.markdown | 6 +++++-
 3 files changed, 16 insertions(+), 4 deletions(-)

diff --git a/en/01-introduction/01-chapter1.markdown b/en/01-introduction/01-chapter1.markdown
index 9079a47b5..9cd2d5620 100644
--- a/en/01-introduction/01-chapter1.markdown
+++ b/en/01-introduction/01-chapter1.markdown
@@ -161,7 +161,7 @@ Or if you’re on a Debian-based distribution like Ubuntu, try apt-get:
 
 ### Installing on Mac ###
 
-There are two easy ways to install Git on a Mac. The easiest is to use the graphical Git installer, which you can download from the SourceForge page (see Figure 1-7):
+There are three easy ways to install Git on a Mac. The easiest is to use the graphical Git installer, which you can download from the SourceForge page (see Figure 1-7):
 
 	http://sourceforge.net/projects/git-osx-installer/
 
@@ -174,6 +174,10 @@ The other major way is to install Git via MacPorts (`http://www.macports.org`).
 
 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).
 
+Homebrew (`http://brew.sh/`) is another alternative to install Git. If you have Homebrew installed, install Git via
+
+	$ brew install git
+
 ### Installing on Windows ###
 
 Installing Git on Windows is very easy. The msysGit project has one of the easier installation procedures. Simply download the installer exe file from the GitHub page, and run it:
diff --git a/es/01-introduction/01-chapter1.markdown b/es/01-introduction/01-chapter1.markdown
index e340e566b..692764e4c 100644
--- a/es/01-introduction/01-chapter1.markdown
+++ b/es/01-introduction/01-chapter1.markdown
@@ -161,19 +161,23 @@ O si estás en una distribución basada en Debian como Ubuntu, prueba con apt-ge
 
 ### Instalando en Mac ###
 
-Hay dos maneras fáciles de instalar Git en un Mac. La más sencilla es usar el instalador gráfico de Git, que puedes descargar desde la página de SourceForge (véase Figura 1-7):
+Hay tres maneras fáciles de instalar Git en un Mac. La más sencilla es usar el instalador gráfico de Git, que puedes descargar desde la página de SourceForge (véase Figura 1-7):
 
 	http://sourceforge.net/projects/git-osx-installer/
 
 Insert 18333fig0107.png
 Figura 1-7. Instalador de Git para OS X.
 
-La otra manera es instalar Git a través de MacPorts (`http://www.macports.org`). Si tienes MacPorts instalado, instala Git con:
+Una alternativa es instalar Git a través de MacPorts (`http://www.macports.org`). Si tienes MacPorts instalado, instala Git con:
 
 	$ sudo port install git-core +svn +doc +bash_completion +gitweb
 
 No necesitas añadir todos los extras, pero probablemente quieras incluir +svn en caso de que alguna vez necesites usar Git con repositorios Subversion (véase el Capítulo 8).
 
+La segunda alternativa es Homebrew (`http://brew.sh/`). Si ya tienes instalado Homebrew, instala Git con:
+
+	$ brew install git
+
 ### Instalando en Windows ###
 
 Instalar Git en Windows es muy fácil. El proyecto msysGit tiene uno de los procesos de instalación más sencillos. Simplemente descarga el archivo exe del instalador desde la página de GitHub, y ejecútalo:
diff --git a/it/01-introduction/01-chapter1.markdown b/it/01-introduction/01-chapter1.markdown
index e46791bb5..72a6dfeb6 100644
--- a/it/01-introduction/01-chapter1.markdown
+++ b/it/01-introduction/01-chapter1.markdown
@@ -168,12 +168,16 @@ Ci sono due metodi per installare facilmente Git su Mac. Il più semplice è usa
 Insert 18333fig0107.png 
 Figura 1-7. Installer di Git per OS X.
 
-L'altro metodo è installare Git con MacPorts (`http://www.macports.org`). Se hai MacPorts installato puoi farlo con:
+La prima alternativa è usando MacPorts (`http://www.macports.org`). Se hai già installato MacPorts puoi installare Git con:
 
 	$ sudo port install git-core +svn +doc +bash_completion +gitweb
 
 Non ti occorre aggiungere tutti i pacchetti extra, ma probabilmente vorrai includere +svn, nel caso tu debba usare Git con i repository di Subversion (vedi Capitolo 8).
 
+La seconda alternativa è Homebrew (`http://brew.sh/`). Se hai già installato Homebrew puoi installare Git con:
+
+	$ brew install git
+
 ### Installare su Windows ###
 
 Installare Git su Windows è davvero facile. Il progetto msysGit ha una delle procedure di installazione più facili. Semplicemente scarica l'eseguibile dalla pagina di GitHub e lancialo:

From 0a7234cbce6ab1c40e119e69ba9ddad9d8a80a5b Mon Sep 17 00:00:00 2001
From: Petr Prikryl <prikryl@atlas.cz>
Date: Fri, 29 Aug 2014 16:22:04 +0200
Subject: [PATCH 610/690] [cs] first changes during revision of chapter 5

---
 cs/05-distributed-git/01-chapter5.markdown | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/cs/05-distributed-git/01-chapter5.markdown b/cs/05-distributed-git/01-chapter5.markdown
index f5848226b..da4cbf4b8 100644
--- a/cs/05-distributed-git/01-chapter5.markdown
+++ b/cs/05-distributed-git/01-chapter5.markdown
@@ -6,7 +6,7 @@ V této kapitole se dozvíte, jak pracovat se systémem Git v distribuovaném pr
 
 ## Distribuované pracovní postupy ##
 
-Na rozdíl od centralizovaných systémů správy verzí (CVCS) umožňuje distribuovaný charakter systému Git mnohem větší flexibilitu při spolupráci vývojářů na projektech. V centralizovaných systémech představuje každý vývojář samostatný uzel, pracující více či méně na stejné úrovni vůči centrálnímu úložišti. Naproti tomu je v systému Git každý vývojář potenciálním uzlem i úložištěm, každý vývojář může přispívat kódem do jiných repozitářů i spravovat veřejný repozitář, na němž mohou ostatní založit svou práci a do nějž mohou přispívat. Tím se otvírá široké spektrum možností organizace práce pro váš projekt a/nebo váš tým. Zkusíme se tedy podívat na pár častých postupů, které tato flexibilita umožňuje. Uvedeme přednosti i eventuální slabiny všech těchto postupů. Budete si moci vybrat některý z postupů nebo je navzájem kombinovat a spojovat jejich funkce.
+Na rozdíl od centralizovaných systémů správy verzí (CVCS) umožňuje distribuovaný charakter systému Git mnohem větší flexibilitu při spolupráci vývojářů na projektech. V centralizovaných systémech představuje každý vývojář samostatný uzel, pracující více či méně na stejné úrovni vůči centrálnímu úložišti. Naproti tomu je v systému Git každý vývojář potenciálním uzlem i úložištěm, každý vývojář může přispívat kódem do jiných repozitářů i spravovat veřejný repozitář, na němž mohou ostatní založit svou práci a do nějž mohou přispívat. Tím se pro váš projekt a váš tým otvírá široké spektrum pracovních postupů. Zkusíme se tedy podívat na pár častých přístupů, které tato flexibilita umožňuje. Uvedeme jejich přednosti i eventuální slabiny. Budete si moci vybrat některý z postupů nebo je navzájem kombinovat a spojovat jejich vlastnosti.
 
 ### Centralizovaný pracovní postup ###
 
@@ -17,12 +17,12 @@ Obrázek 5-1. Centralizovaný pracovní postup
 
 To znamená, že pokud dva vývojáři klonují z centrálního úložiště a oba provedou změny, jen první z nich, který odešle své změny, to může provést bez komplikací. Druhý vývojář musí před odesláním svých změn začlenit práci prvního vývojáře do své, aby nepřepsal jeho změny. Tento koncept platí jak pro Git, tak pro Subversion (popř. jakýkoli CVCS). I v systému Git funguje bez problémů.
 
-Pokud pracujete v malém týmu nebo už jste ve své společnosti nebo ve svém týmu zvyklí na centralizovaný pracovní postup, můžete v něm beze všeho pokračovat. Jednoduše vytvořte repozitář a přidělte všem ze svého týmu oprávnění k odesílání dat. Git neumožní uživatelům, aby se navzájem přepisovali. Pokud některý z vývojářů naklonuje data, provede změny a poté se je pokusí odeslat, a jiný vývojář mezitím odeslal svoje revize, server tyto změny odmítne. Git vývojáři při odmítnutí sdělí, že se pokouší odeslat změny, které nesměřují „rychle vpřed“, což není možné provést, dokud nevyzvedne a nezačlení stávající data z repozitáře.
+Pokud pracujete v malém týmu nebo už jste ve své společnosti nebo ve svém týmu zvyklí na centralizovaný pracovní postup, můžete v něm beze všeho pokračovat. Jednoduše vytvořte repozitář a přidělte všem ze svého týmu oprávnění k odesílání dat. Git neumožní uživatelům, aby se navzájem přepisovali. Pokud některý z vývojářů naklonuje data, provede změny a poté se je pokusí odeslat, a jiný vývojář mezitím odeslal svoje revize, server tyto změny odmítne. Git vývojáři při odmítnutí sdělí, že se pokouší odeslat změny, které nesměřují „rychle vpřed“, což není možné provést, dokud nevyzvedne a nezačlení (fetch and merge) stávající data z repozitáře.
 Tento pracovní postup může být pro mnoho lidí zajímavý, protože je to schéma, které jsou zvyklí používat a jsou s ním spokojeni.
 
 ### Pracovní postup s integračním manažerem ###
 
-Protože Git umožňuje, abyste měli několik vzdálených repozitářů, lze použít pracovní postup, kdy má každý vývojář oprávnění k zápisu do vlastního veřejného repozitáře a oprávnění pro čtení k repozitářům všech ostatních. Tento scénář často zahrnuje jeden standardní repozitář, který reprezentuje „oficiální“ projekt. Chcete-li do tohoto projektu přispívat, vytvořte vlastní veřejný klon projektu a odešlete do něj změny, které jste provedli. Poté odešlete správci hlavního projektu žádost, aby do projektu natáhl vaše změny. Váš repozitář může přidat jako vzdálený repozitář, lokálně otestovat vaše změny, začlenit je do své větve a odeslat zpět do svého repozitáře. Postup práce je následující (viz obrázek 5-2):
+Protože Git umožňuje, abyste měli několik vzdálených repozitářů, lze použít pracovní postup, kdy má každý vývojář oprávnění k zápisu do vlastního veřejného repozitáře a oprávnění pro čtení k repozitářům všech ostatních. Tento scénář často zahrnuje jeden standardní repozitář, který reprezentuje „oficiální“ projekt. Chcete-li do tohoto projektu přispívat, vytvořte vlastní veřejný klon projektu a odešlete do něj změny, které jste provedli. Poté odešlete správci hlavního projektu žádost, aby do projektu natáhl vaše změny. Správce může váš repozitář přidat jako vzdálený repozitář, lokálně otestovat vaše změny, začlenit je do své větve a odeslat zpět do svého repozitáře. Postup práce je následující (viz obrázek 5-2):
 
 1. Správce projektu odešle data do svého veřejného repozitáře.
 2. Přispěvatel naklonuje tento repozitář a provede změny.
@@ -34,7 +34,7 @@ Protože Git umožňuje, abyste měli několik vzdálených repozitářů, lze p
 Insert 18333fig0502.png
 Obrázek 5-2. Pracovní postup s integračním manažerem
 
-Tento pracovní postup je velmi rozšířený na stránkách jako GitHub, kde je snadné rozštěpit projekt a odeslat změny do své odštěpené části, kde jsou pro každého k nahlédnutí. Jednou z hlavních předností tohoto postupu je, že můžete pracovat bez přerušení a správce hlavního repozitáře může natáhnout vaše změny do projektu, kdykoli uzná za vhodné. Přispěvatelé nemusí čekat, až budou jejich změny začleněny do projektu – každá strana může pracovat svým tempem.
+Tento pracovní postup je velmi rozšířený na serverech jako je GitHub, kde je snadné rozštěpit projekt a odeslat změny do své odštěpené části, kde jsou pro každého k nahlédnutí. Jednou z hlavních předností tohoto postupu je, že můžete pracovat bez přerušení a správce hlavního repozitáře může natáhnout vaše změny do projektu, kdykoli uzná za vhodné. Přispěvatelé nemusí čekat, až budou jejich změny začleněny do projektu – každá strana může pracovat svým tempem.
 
 ### Pracovní postup s diktátorem a poručíky ###
 

From cbfa4f81798d5b34991654a91655467a9de3148d Mon Sep 17 00:00:00 2001
From: "Alessandro P." <byteriot@users.noreply.github.com>
Date: Sun, 31 Aug 2014 10:14:57 +0200
Subject: [PATCH 611/690] Misspelling uppercase insert -> Insert image 3-8

Cause the misspelling the website do not show the figure in the html tag but only print [..]insert 18333fig0308.png [..]
---
 it/03-git-branching/01-chapter3.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/it/03-git-branching/01-chapter3.markdown b/it/03-git-branching/01-chapter3.markdown
index 2e598ea06..de1d4975c 100644
--- a/it/03-git-branching/01-chapter3.markdown
+++ b/it/03-git-branching/01-chapter3.markdown
@@ -71,7 +71,7 @@ Questo è interessante, perché ora il tuo ramo testing è stato spostato in ava
 
 La Figura 3-8 mostra il risultato.
 
-insert 18333fig0308.png 
+Insert 18333fig0308.png 
 Figura 3-8. HEAD si è spostato ad un altro ramo con un checkout.
 
 Questo comando ha fatto due cose. Ha spostato il puntatore HEAD indietro per puntare al ramo master e ha riportato i file nella tua directory di lavoro allo stato in cui si trovavano in quel momento. Questo significa anche che i cambiamenti che farai da questo punto in poi saranno separati da una versione più vecchia del progetto. Essenzialmente riavvolge temporaneamente il lavoro che hai fatto nel tuo ramo testing così puoi muoverti in una direzione differente.

From ab98f8f0c6c15c665d1bcf8b4b1a0595805023c9 Mon Sep 17 00:00:00 2001
From: "Alessandro P." <byteriot@users.noreply.github.com>
Date: Sun, 31 Aug 2014 14:31:24 +0200
Subject: [PATCH 612/690] [it] misspelling temo -> tempo

 allo stesso temo -> allo stesso tempo
---
 it/03-git-branching/01-chapter3.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/it/03-git-branching/01-chapter3.markdown b/it/03-git-branching/01-chapter3.markdown
index 2e598ea06..81aabfc5e 100644
--- a/it/03-git-branching/01-chapter3.markdown
+++ b/it/03-git-branching/01-chapter3.markdown
@@ -388,7 +388,7 @@ Questo può un po' confondere, quindi vediamo un esempio. Diciamo che hai un ser
 Insert 18333fig0322.png 
 Figura 3-22. Un clone con Git fornisce un proprio ramo principale e un puntatore origin/master al ramo principale di origine.
 
-Se fai del lavoro sul tuo ramo principale locale, e, allo stesso temo, qualcuno ha inviato degli aggiornamenti al ramo principale di `git.ourcompany.com`, allora la tua storia si muoverà in avanti in modo differente. Inoltre, mentre non hai contatti con il tuo server di partenza, il tuo puntatore `origin/master` non si sposterà (vedi Figura 3-23).
+Se fai del lavoro sul tuo ramo principale locale, e, allo stesso tempo, qualcuno ha inviato degli aggiornamenti al ramo principale di `git.ourcompany.com`, allora la tua storia si muoverà in avanti in modo differente. Inoltre, mentre non hai contatti con il tuo server di partenza, il tuo puntatore `origin/master` non si sposterà (vedi Figura 3-23).
 
 Insert 18333fig0323.png 
 Figura 3-23. Lavorando in locale ed avendo qualcuno che ha inviato al server remoto qualcosa rende l'avanzamento delle storie differente.

From fedcc90c057d1cc27695139ba809fa5183568917 Mon Sep 17 00:00:00 2001
From: "Alessandro P." <byteriot@users.noreply.github.com>
Date: Mon, 1 Sep 2014 12:26:56 +0200
Subject: [PATCH 613/690] [it] Fixed various misspelling

---
 it/05-distributed-git/01-chapter5.markdown | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/it/05-distributed-git/01-chapter5.markdown b/it/05-distributed-git/01-chapter5.markdown
index adb3990f0..102ff0e02 100755
--- a/it/05-distributed-git/01-chapter5.markdown
+++ b/it/05-distributed-git/01-chapter5.markdown
@@ -105,11 +105,11 @@ Questo modello è stato originariamente scritto da Tim Pope su tpope.net:
 
 Se tutti i tuoi messaggi di commit fossero così, per te e gli altri sviluppatori con cui lavori le cose saranno molto più semplici per te e per gli sviluppatore con cui lavori. Il progetto di Git ha dei messaggi di commit ben formattati: ti incoraggio a eseguire `git log --no-merges` per vedere qual è l'aspetto di una cronologia ben leggibile.
 
-Nei esempi che seguono e nella maggior parte di questo libro, per brevità, non formatterò i messaggi accuratamente come descritto: userò invece l'opzione `-m` di `git commit`. Fa' come dico, non come faccio.
+Negli esempi che seguono e nella maggior parte di questo libro, per brevità, non formatterò i messaggi accuratamente come descritto: userò invece l'opzione `-m` di `git commit`. Fa' come dico, non come faccio.
 
 ### Piccoli gruppi privati ###
 
-La configurazione più semplice che è più facile che incontrerai è quella del progetto privato con uno o due sviluppatori. Con privato intendo codice a sorgente chiuso: non accessibile al resto del mondo. Tu e gli altri sviluppatori avete accesso in scrittura al repository.
+La configurazione più semplice che è più facilmente incontrerai è quella del progetto privato con uno o due sviluppatori. Con privato intendo codice a sorgente chiuso: non accessibile al resto del mondo. Tu e gli altri sviluppatori avete accesso in scrittura al repository.
 
 Con questa configurazione, puoi utilizzare un workflow simile a quello che magari stai già usando con Subversion o un altro sistema centralizzato. Hai comunque i vantaggi (ad esempio) di poter eseguire commit da offline e la creazione di rami (ed unione degli stessi) molto più semplici, ma il workflow può restare simile; la differenza principale è che, nel momento del commit, l'unione avviene nel tuo repository piuttosto che in quello sul server.
 Vediamo come potrebbe essere la situazione quando due sviluppatori iniziano a lavorare insieme con un repository condiviso. Il primo sviluppatore, John, clona in repository, fa dei cambiamenti ed esegue il commit localmente. (In questi esempi sostituirò, per brevità, il messaggio del protocollo con `...`)

From f2f76f1331ab55702de6c98dd8dc0f86736c98ca Mon Sep 17 00:00:00 2001
From: "Alessandro P." <byteriot@users.noreply.github.com>
Date: Mon, 1 Sep 2014 12:32:30 +0200
Subject: [PATCH 614/690] [it] Improved sentence readability

---
 it/05-distributed-git/01-chapter5.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/it/05-distributed-git/01-chapter5.markdown b/it/05-distributed-git/01-chapter5.markdown
index 102ff0e02..1ff072e7f 100755
--- a/it/05-distributed-git/01-chapter5.markdown
+++ b/it/05-distributed-git/01-chapter5.markdown
@@ -109,7 +109,7 @@ Negli esempi che seguono e nella maggior parte di questo libro, per brevità, no
 
 ### Piccoli gruppi privati ###
 
-La configurazione più semplice che è più facilmente incontrerai è quella del progetto privato con uno o due sviluppatori. Con privato intendo codice a sorgente chiuso: non accessibile al resto del mondo. Tu e gli altri sviluppatori avete accesso in scrittura al repository.
+La configurazione più semplice che più facilmente incontrerai è quella del progetto privato con uno o due sviluppatori. Con privato intendo codice a sorgente chiuso: non accessibile al resto del mondo. Tu e gli altri sviluppatori avete accesso in scrittura al repository.
 
 Con questa configurazione, puoi utilizzare un workflow simile a quello che magari stai già usando con Subversion o un altro sistema centralizzato. Hai comunque i vantaggi (ad esempio) di poter eseguire commit da offline e la creazione di rami (ed unione degli stessi) molto più semplici, ma il workflow può restare simile; la differenza principale è che, nel momento del commit, l'unione avviene nel tuo repository piuttosto che in quello sul server.
 Vediamo come potrebbe essere la situazione quando due sviluppatori iniziano a lavorare insieme con un repository condiviso. Il primo sviluppatore, John, clona in repository, fa dei cambiamenti ed esegue il commit localmente. (In questi esempi sostituirò, per brevità, il messaggio del protocollo con `...`)

From 762b4b1f37610c6fb262a090bb0b93b49cbad984 Mon Sep 17 00:00:00 2001
From: "Alessandro P." <byteriot@users.noreply.github.com>
Date: Mon, 1 Sep 2014 12:46:43 +0200
Subject: [PATCH 615/690] [it] Added tab space - Fixed ''

---
 it/05-distributed-git/01-chapter5.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/it/05-distributed-git/01-chapter5.markdown b/it/05-distributed-git/01-chapter5.markdown
index 1ff072e7f..8b53f93f0 100755
--- a/it/05-distributed-git/01-chapter5.markdown
+++ b/it/05-distributed-git/01-chapter5.markdown
@@ -285,7 +285,7 @@ A questo punto lei deve condividere il suo lavoro con John, così fa la push sul
 
 Jessica manda una e-mail a John dicendogli che fatto la push del suo lavoro su un branch chiamato `funzioanlitaA` chiedendogli se lui può dargli un'occhiata. Mentre aspetta una risposta da John, Jessica decide di iniziare a lavorare su `funzionalitaB` con Josie. Per iniziare, crea un nuovo branch basandosi sul branch `master` del server:
 
-  # Computer di Jessica
+	# Computer di Jessica
 	$ git fetch origin
 	$ git checkout -b featureB origin/master
 	Switched to a new branch "featureB"

From 015820d29ae7bdca10ff94ccc15b35999fa682f6 Mon Sep 17 00:00:00 2001
From: Brennon Bortz <brennon@brennonbortz.com>
Date: Tue, 2 Sep 2014 09:07:57 -0400
Subject: [PATCH 616/690] Update 'git log' completion output

---
 en/02-git-basics/01-chapter2.markdown | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/en/02-git-basics/01-chapter2.markdown b/en/02-git-basics/01-chapter2.markdown
index 9aa20341f..8737af541 100644
--- a/en/02-git-basics/01-chapter2.markdown
+++ b/en/02-git-basics/01-chapter2.markdown
@@ -1176,8 +1176,11 @@ In this case, typing `git co` and then pressing the Tab key twice suggests commi
 
 This also works with options, which is probably more useful. For instance, if you’re running a `git log` command and can’t remember one of the options, you can start typing it and press Tab to see what matches:
 
-	$ git log --s<tab>
-	--shortstat  --since=  --src-prefix=  --stat   --summary
+	$ git log --s<tab><tab>
+	--shortstat               --sparse
+	--simplify-by-decoration  --src-prefix=
+	--simplify-merges         --stat
+	--since=                  --summary
 
 That’s a pretty nice trick and may save you some time and documentation reading.
 

From 0efe58537fb6dc6006dccd3c80073e6834a0410c Mon Sep 17 00:00:00 2001
From: Tobias Kerst <tobias.kerst@tobscore.com>
Date: Wed, 3 Sep 2014 03:39:40 +0200
Subject: [PATCH 617/690] [de] Entfernt die Anmerkung von gitosis im Abschnitt
 zu gitolite
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Gitosis wird im Abschnitt zu gitolite erwähnt, ohne das dies relevant wäre. Dies behebt #508 und geht auf den Fix in #870 ein.
---
 de/04-git-server/01-chapter4.markdown | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/de/04-git-server/01-chapter4.markdown b/de/04-git-server/01-chapter4.markdown
index e0f25980c..432ee1436 100644
--- a/de/04-git-server/01-chapter4.markdown
+++ b/de/04-git-server/01-chapter4.markdown
@@ -887,9 +887,9 @@ Diese Regel gehört dann zum Regelsatz des `gitolite` Repository.
 
 An dieser Stelle fragst Du Dich vielleicht, wie die Zugriffsregeln eigentlich angewandt werden. Lass uns das kurz anschauen.
 
-<!--There are two levels of access control in Gitolite.  The first is at the repository level; if you have read (or write) access to *any* ref in the repository, then you have read (or write) access to the repository.  This is the only access control that Gitosis had.-->
+<!--There are two levels of access control in Gitolite.  The first is at the repository level; if you have read (or write) access to *any* ref in the repository, then you have read (or write) access to the repository.-->
 
-Es gibt zwei Ebenen für die Zugriffsberechtigung in Gitolite. Die erste befindet sich auf Repository Ebene. Wenn Du Lese- oder Schreifzugriff auf jede Ref in einem Repository hast, dann kannst Du damit das ganze Repository sowohl lesen, als auch schreiben. Gitosis kennt nur diese Art der Zugriffsberechtigung.
+Es gibt zwei Ebenen für die Zugriffsberechtigung in Gitolite. Die erste befindet sich auf Repository Ebene. Wenn Du Lese- oder Schreifzugriff auf jede Ref in einem Repository hast, dann kannst Du damit das ganze Repository sowohl lesen, als auch schreiben.
 
 <!--The second level, applicable only to "write" access, is by branch or tag within a repository.  The username, the access being attempted (`W` or `+`), and the refname being updated are known.  The access rules are checked in order of appearance in the config file, looking for a match for this combination (but remember that the refname is regex-matched, not merely string-matched).  If a match is found, the push succeeds.  A fallthrough results in access being denied.-->
 

From aa90017e17b57545f612b32ddc7dc1d22b53f54b Mon Sep 17 00:00:00 2001
From: Tobias Kerst <tobias.kerst@tobscore.com>
Date: Wed, 3 Sep 2014 03:51:41 +0200
Subject: [PATCH 618/690] [de] Includes homebrew as an alternative to install
 git.
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Fügt die in Issue #868 angemerkte Möglichkeit der Installation über Homebrew zur deutschen Übersetzung hinzu.
---
 de/01-introduction/01-chapter1.markdown | 12 +++++++++++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/de/01-introduction/01-chapter1.markdown b/de/01-introduction/01-chapter1.markdown
index 5c60ced9d..28c1e64e3 100644
--- a/de/01-introduction/01-chapter1.markdown
+++ b/de/01-introduction/01-chapter1.markdown
@@ -221,7 +221,7 @@ Wenn eine bestimmte Version einer Datei im Git Verzeichnis liegt, gilt sie als 
 <!--## Installing Git ##-->
 ## Git installieren ##
 
-<!--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.-->
+<!--Let’s get into using some Git. First things first—you have to install it. You can get it a number of ways; the three major ones are to install it from source or to install an existing package for your platform.-->
 
 Lass uns damit anfangen, Git tatsächlich zu verwenden. Der erste Schritt besteht natürlich darin, Git zu installieren und das kann, wie üblich, auf unterschiedliche Weisen geschehen. Die beiden wichtigsten bestehen darin, entweder den Quellcode herunterzuladen und selbst zu kompilieren oder ein fertiges Paket für Dein Betriebssystem zu installieren.
 
@@ -302,6 +302,16 @@ Die andere Möglichkeit ist, Git via MacPorts (http://www.macports.org) zu insta
 
 Du brauchst die optionalen Features natürlich nicht mit zu installieren, aber es macht Sinn `+svn` zu verwenden, falls Du jemals Git mit einem Subversion Repository verwenden willst.
 
+<!--Homebrew (`http://brew.sh/`) is another alternative to install Git. If you have Homebrew installed, install Git via
+
+	$ brew install git
+
+-->
+
+Alternativ kann man Git auch über Homebrew (`http://brew.sh/`) installieren. Hast Du Homebrew bereits, kannst Du Git einfach über den folgenden Befehl installieren:
+
+	$ brew install git
+
 <!--### Installing on Windows ###-->
 ### Installation unter Windows ###
 

From efa9203323abb68b8d2d82ba7d51cc13ae76d03d Mon Sep 17 00:00:00 2001
From: Denis C de Azevedo <denis.azevedo@gmail.com>
Date: Wed, 3 Sep 2014 02:12:45 -0300
Subject: [PATCH 619/690] [pt-br] fix mispelling concerto -> conserto

---
 pt-br/03-git-branching/01-chapter3.markdown | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/pt-br/03-git-branching/01-chapter3.markdown b/pt-br/03-git-branching/01-chapter3.markdown
index 21bf4b417..8f9bb99fd 100644
--- a/pt-br/03-git-branching/01-chapter3.markdown
+++ b/pt-br/03-git-branching/01-chapter3.markdown
@@ -151,8 +151,8 @@ Em seguida, você tem uma correção para fazer. Vamos criar um branch para a co
     $ git checkout -b 'hotfix'
     Switched to a new branch "hotfix"
     $ vim index.html
-    $ git commit -a -m 'concertei o endereço de email'
-    [hotfix]: created 3a0874c: "concertei o endereço de email"
+    $ git commit -a -m 'consertei o endereço de email'
+    [hotfix]: created 3a0874c: "consertei o endereço de email"
      1 files changed, 0 insertions(+), 1 deletions(-)
 
 Insert 18333fig0313.png
@@ -310,7 +310,7 @@ O comando `git branch` faz mais do que criar e apagar branches. Se você execut
 Note o caractere `*` que vem antes do branch `master`: ele indica o branch que você está atualmente (fez o checkout). Isso significa que se você fizer um commit nesse momento, o branch `master` irá se mover adiante com seu novo trabalho. Para ver o último commit em cada branch, você pode executar o comando `git branch -v`:
 
     $ git branch -v
-      iss53   93b412c concertar problema em javascript
+      iss53   93b412c consertar problema em javascript
     * master  7a98805 Merge branch 'iss53'
       testing 782fd34 adicionar scott para a lista de autores nos readmes
 

From 956b22e669f861ca311784bd14d7dc2b9d23b667 Mon Sep 17 00:00:00 2001
From: "Alessandro P." <byteriot@users.noreply.github.com>
Date: Wed, 3 Sep 2014 18:24:01 +0200
Subject: [PATCH 620/690] [it] Sentence improved

Miglioramento della frase introduttiva sotto consiglio di @daftano in seguito ad un breve scambio di commenti
---
 it/05-distributed-git/01-chapter5.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/it/05-distributed-git/01-chapter5.markdown b/it/05-distributed-git/01-chapter5.markdown
index 8b53f93f0..6d453984b 100755
--- a/it/05-distributed-git/01-chapter5.markdown
+++ b/it/05-distributed-git/01-chapter5.markdown
@@ -109,7 +109,7 @@ Negli esempi che seguono e nella maggior parte di questo libro, per brevità, no
 
 ### Piccoli gruppi privati ###
 
-La configurazione più semplice che più facilmente incontrerai è quella del progetto privato con uno o due sviluppatori. Con privato intendo codice a sorgente chiuso: non accessibile al resto del mondo. Tu e gli altri sviluppatori avete accesso in scrittura al repository.
+La configurazione più semplice che probabilmente incontrerai sarà di un progetto privato con uno o due sviluppatori. Con privato intendo codice a sorgente chiuso: non accessibile al resto del mondo. Tu e gli altri sviluppatori avete accesso in scrittura al repository.
 
 Con questa configurazione, puoi utilizzare un workflow simile a quello che magari stai già usando con Subversion o un altro sistema centralizzato. Hai comunque i vantaggi (ad esempio) di poter eseguire commit da offline e la creazione di rami (ed unione degli stessi) molto più semplici, ma il workflow può restare simile; la differenza principale è che, nel momento del commit, l'unione avviene nel tuo repository piuttosto che in quello sul server.
 Vediamo come potrebbe essere la situazione quando due sviluppatori iniziano a lavorare insieme con un repository condiviso. Il primo sviluppatore, John, clona in repository, fa dei cambiamenti ed esegue il commit localmente. (In questi esempi sostituirò, per brevità, il messaggio del protocollo con `...`)

From 68e778d69531cc39350f4987b485e4c60cf473a1 Mon Sep 17 00:00:00 2001
From: Jean-Noel Avila <jean-noel.avila@scantech.fr>
Date: Wed, 3 Sep 2014 21:10:19 +0200
Subject: [PATCH 621/690] Add a test on badly formated insert directive

The directive for inserting an image is:

 Insert <image>
---
 Rakefile | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/Rakefile b/Rakefile
index d5d31dd16..3aeaebf78 100644
--- a/Rakefile
+++ b/Rakefile
@@ -197,8 +197,13 @@ def test_lang(lang, out)
           error_code = true
         end
       end
-      if line.match /^\s*Insert\s(.*)/
-        figure_count = figure_count + 1
+      if line.match /^\s*Insert\s(.*)/i
+	if line.match /^\s*Insert\s(.*)/
+	  figure_count = figure_count + 1
+	else
+	  out << "\n#{lang}: Badly cased Insert directive: #{line}\n"
+	  error_code = true
+	end
       end
     end
     # This extraction is a bit contorted, because the pl translation renamed

From 6289f47fc735a3c7aa6110fae688ca32ad1cd072 Mon Sep 17 00:00:00 2001
From: Ciro Santilli <ciro.santilli@gmail.com>
Date: Thu, 4 Sep 2014 21:52:30 +0200
Subject: [PATCH 622/690] Mention packed-refs.

---
 en/09-git-internals/01-chapter9.markdown | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/en/09-git-internals/01-chapter9.markdown b/en/09-git-internals/01-chapter9.markdown
index 71d41a932..e1e0071a9 100644
--- a/en/09-git-internals/01-chapter9.markdown
+++ b/en/09-git-internals/01-chapter9.markdown
@@ -331,6 +331,12 @@ Figure 9-4. Git directory objects with branch head references included.
 
 When you run commands like `git branch (branchname)`, Git basically runs that `update-ref` command to add the SHA-1 of the last commit of the branch you’re on into whatever new reference you want to create.
 
+If a reference is not found under the `refs` directory, Git then searches for it in the `.git/packed-refs` file, which contains space separated SHA-1 path pairs, for example:
+
+    52d771167707552d8e2a50f602c669e2ad135722 refs/tags/v1.0.1
+
+This file exists for performance reasons, as it is more efficient to have a single file rather than many small ones for references that don't change very often. You can tell Git to pack references into that file by using the `git pack-refs` command.
+
 ### The HEAD ###
 
 The question now is, when you run `git branch (branchname)`, how does Git know the SHA-1 of the last commit? The answer is the HEAD file. The HEAD file is a symbolic reference to the branch you’re currently on. By symbolic reference, I mean that unlike a normal reference, it doesn’t generally contain a SHA-1 value but rather a pointer to another reference. If you look at the file, you’ll normally see something like this:

From 9c936d027ab1492bfb681f5883c4116f8ee7ba51 Mon Sep 17 00:00:00 2001
From: "Ammar M. Zerouk" <ammarzerouk@outlook.com>
Date: Sun, 7 Sep 2014 01:11:26 +0300
Subject: [PATCH 623/690] [ar] translating file editing, checking status,
 tracking new files, staging modified files, ignoring files

---
 ar/02-git-basics/01-chapter2.markdown | 61 +++++++++++++--------------
 1 file changed, 30 insertions(+), 31 deletions(-)

diff --git a/ar/02-git-basics/01-chapter2.markdown b/ar/02-git-basics/01-chapter2.markdown
index 0bea0227d..da77fdd39 100644
--- a/ar/02-git-basics/01-chapter2.markdown
+++ b/ar/02-git-basics/01-chapter2.markdown
@@ -1,4 +1,4 @@
-# مبادئ Git #
+# مبادئ Git #
 
 إذا كان هناك فصل واحد عليك قراءته لكي تبدأ بإستخدام Git، فعليك بهذا الفصل! يغطي هذا الفصل جميع الأوامر الأساسية التي عليك معرفتها لكي تتمكن من القيام بأغلب الأمور أثناء استخدامك لـ Git. في نهاية هذا الفصل يجب أن تكون قادراً على انشاء واعداد الـ repository لمشروعك وعلى تحديد الملفات التي ستتم متابعتها والتي ستترك، وعلى تهييئ التغييرات لعمل commit عليها. ستتعلم أيضاً كيف تعد Git لكي تتجاهل بعض أنواع الملفات، كيف تقوم بالتراجع عن الأخطاء التي سترتكبها بسرعة وبسهولة، كيف تتصفح تاريخ مشروعك وكيف تعرض التغيرات بين الـ commits، وكيف تنشر وتسحب (push & pull) التغيرات من الـ repositories البعيدة عنك.
 
@@ -40,27 +40,26 @@
 هناك عدد من البروتوكولات المختلفة التي يمكنك اسستعمالها لنقل المعلومات في git. المثال السابق يستعمل بروتوكول 'git://'، ولكن من الممكن أن تجد أيضاً استخداماً لـ 'http(s)://' أو 'user@server:/path.git'، والتي تستعمل بروتوكول SSH في النقل. في الفصل الرابع من الكتاب ستتعرف على الخيارات المتوفرة للتواصل مع الـ repository الخاصة بك وميزات ومساوئ كل منها.
 
 ## تسجيل التعديلات في الـ repository ##
+لديك repository أصلي ونسخة لتعمل عليها من ملفات المشروع. عليك أن تقوم ببعض التعديلات ثم تعمل commit لهذه التعديلات في repository الخاص بك في كل مرة يصل فيها المشروع إلى نقطة تود تسجيلها.
 
-You have a bona fide Git repository and a checkout or working copy of the files for that project. You need to make some changes and commit snapshots of those changes into your repository each time the project reaches a state you want to record.
+تذكر أنه كل ملف في مجلد العمل يمكن أن يكون في إحدى الحالتين فقط: مٌتَتَبّع tracked أو غير مٌتَتَبّع untracked. الملفات المٌتتبّعة هي ملفات كانت في أخر snapshot ويمكن إلغاء التعديلات عليها أو التعديل عليها أو وضعه في حالة staged (جاهز من أجل commit). الملفات غير المُتتبّعة هي كل الملفات الآخرى - أي ملف في مجلد العمل لم يكن موجوداً في آخر snapshot وليس معلماً بأنه staged. عندما تقوم باستنساخ repository جميع ملفاتك تكون بحالة متتبّعة tracked و غير معدلة unmodified لأنك قمت للتو بعمل check out ولم تقم بأي تعديل.
 
-Remember that each file in your working directory can be in one of two states: tracked or untracked. Tracked files are files that were in the last snapshot; they can be unmodified, modified, or staged. Untracked files are everything else - any files in your working directory that were not in your last snapshot and are not in your staging area.  When you first clone a repository, all of your files will be tracked and unmodified because you just checked them out and haven’t edited anything. 
-
-As you edit files, Git sees them as modified, because you’ve changed them since your last commit. You stage these modified files and then commit all your staged changes, and the cycle repeats. This lifecycle is illustrated in Figure 2-1.
+عندما تعدل الملفات، سيقوم git بتأشيرهم على أنهم modified، لأنك قمت بتغيرهم عن آخر commit. تقوم بعمل stage لهذه الملفات المعدلة ثم تقوم بعمل commit لجميع التغيرات في منطقة stage، وتتكرر العملية. يوضع الشكل 2-1 دورة العملية.
 
 Insert 18333fig0201.png 
-Figure 2-1. The lifecycle of the status of your files.
+الشكل 2-1. دورة حالة الملفات.
 
-### Checking the Status of Your Files ###
+### تفقد حالة ملفاتك ###
 
-The main tool you use to determine which files are in which state is the git status command. If you run this command directly after a clone, you should see something like this:
+باستخدام الأمر git status يمكننا معرفة حالة الملفات لدينا. إذا قمت بتشغيل هذا الأمر مباشرة بعد قيامك بعمل clone يجب أن ترى شيئاً يشبه التالي:
 
 	$ git status
 	# On branch master
 	nothing to commit, working directory clean
 
-This means you have a clean working directory—in other words, there are no tracked and modified files. Git also doesn’t see any untracked files, or they would be listed here. Finally, the command tells you which branch you’re on. For now, that is always master, which is the default; you won’t worry about it here. The next chapter will go over branches and references in detail.
+وهذا يعني أنه لديك مجلد عمل نظيف - بمعنى آخر، لايوجد أي ملفات معدلة أو ملفات غير مُتتبّعة. كما أنّ هذا الأمر يخبرك بأي فرع branch أنت تعمل. حالياً، دائماً هو master، وهو الافتراضي؛ في الفصل المقبل سنمر على الأفرع و المرجعيات references بالتفصيل.
 
-Let’s say you add a new file to your project, a simple README file. If the file didn’t exist before, and you run `git status`, you see your untracked file like so:
+لنقل بأنك قمت بإضافة ملف جديد على مشروعك، وليكن ملف README بسيط. إذا لم يكن الملف موجوداً مسبقاً، وقمت بتنفيذ الأمر `git status` سترى الملف غير مُتتبّعاً كما يلي:
 
 	$ vim README
 	$ git status
@@ -71,15 +70,15 @@ Let’s say you add a new file to your project, a simple README file. If the fil
 	#	README
 	nothing added to commit but untracked files present (use "git add" to track)
 
-You can see that your new README file is untracked, because it’s under the “Untracked files” heading in your status output. Untracked basically means that Git sees a file you didn’t have in the previous snapshot (commit); Git won’t start including it in your commit snapshots until you explicitly tell it to do so. It does this so you don’t accidentally begin including generated binary files or other files that you did not mean to include. You do want to start including README, so let’s start tracking the file.
+يمكنك ملاحظة أنّ ملفك الجديد README غير مُتتبّع، فهو تحت تبويب "untracked files" في خرج الأمر. ويعني ذلك أنّ git يرى ملفاً جديداً على commit السابقة؛ علماً أنّ git لن يقوم بإضافة هذا الملف إلى الملفات المتتبعة إلا إذا قمت بطلب ذلك بشكل مباشر، والهدف من ذلك من أجل حماية المشروع من الضم الخاطئ لملفات binary أو أي ملفات لا تود بإضافتها. إلاّ أنّك ترغب في إضافة README إلى الملفات المتتبّعة. وسنقوم بذلك حالاً.
 
-### Tracking New Files ###
+### تتبع الملفات الجديدة ###
 
-In order to begin tracking a new file, you use the command `git add`. To begin tracking the README file, you can run this:
+للقيام بتتبع ملف جديد عليه استخدام الأمر `git add` . مثلاً لنقم بتتبع الملف الجديد README:
 
 	$ git add README
 
-If you run your status command again, you can see that your README file is now tracked and staged:
+إذا قمنا بتنفيذ الأمر `git status` مرة أخرى سنلاحظ أن الملف README أصبح متتبعاً وجاهزاً staged للقيام بعملية commit:
 
 	$ git status
 	# On branch master
@@ -89,11 +88,11 @@ If you run your status command again, you can see that your README file is now t
 	#	new file:   README
 	#
 
-You can tell that it’s staged because it’s under the “Changes to be committed” heading. If you commit at this point, the version of the file at the time you ran git add is what will be in the historical snapshot. You may recall that when you ran git init earlier, you then ran git add (files) — that was to begin tracking files in your directory. The git add command takes a path name for either a file or a directory; if it’s a directory, the command adds all the files in that directory recursively.
+نستطيع معرفة بأن الملف staged من خلال ملاحظته تحت بند "changes to be comitted". إذا قمت بعمل commit في هذه اللحظة، سيقوم git بإضافة النسخة الحالية من الملف إلى snapshot. تذكر عندما قمنا بعمل git init سابقاً، ثم قمنا بإضافة الملفات عن طريق git add، كان ذلك للقيام ببدء تتبع الملفات في مجلد المشروع. يقبل الأمر git add مسار لملف أو لمجلد؛ فإذا كان المسار لمجلد سيقوم git بإضافة جميع الملفات والمجلدات ضمنه بشكل تعاودي recursively.
 
-### Staging Modified Files ###
+### تجهيز الملفات المعدلة ###
 
-Let’s change a file that was already tracked. If you change a previously tracked file called `benchmarks.rb` and then run your `status` command again, you get something that looks like this:
+لنقم بالتعديل على ملف قمنا بإضافته سابقاً. إذا قمنا مثلاً بالتعديل على ملف متتبع مسبقاً يدعى `benchmarks.rb`  وقمنا بتنفيذ الأمر git status، سيكون الخرج مشابهاً للخرج التالي:
 
 	$ git status
 	# On branch master
@@ -108,7 +107,7 @@ Let’s change a file that was already tracked. If you change a previously track
 	#	modified:   benchmarks.rb
 	#
 
-The benchmarks.rb file appears under a section named “Changes not staged for commit” — which means that a file that is tracked has been modified in the working directory but not yet staged. To stage it, you run the `git add` command (it’s a multipurpose command — you use it to begin tracking new files, to stage files, and to do other things like marking merge-conflicted files as resolved). Let’s run `git add` now to stage the benchmarks.rb file, and then run `git status` again:
+يظهر الملف benchmarks.rb تحت بند "changes not staged for commit" وهذا يعني أن الملف المُتتبّع قد خضع لعملية تعديل لكنه لم يخضع للتجهيز من أجل commit. للقيام بتجهيزه (أو تأشيره للإضافة إلى commit الجديد) يجب علينا تنفيذ الأمر `git add` (لاحظ بأنّه أمر متعدد الوظائف - نستطيع استخدامه لتتبع الملفات الجديدة، تجهيز الملفات من أجل commit، والقيام بأمور أخرى مثل حل الاعتراضات في حال القيام بدمج merge). لنقم بتنفيذ git add الآن لوضع benchmarks.rb بحالة staged، ومن ثم لنقم بتنفيذ الأمر git status لنرى ما الذي قد تغيّر:
 
 	$ git add benchmarks.rb
 	$ git status
@@ -120,7 +119,7 @@ The benchmarks.rb file appears under a section named “Changes not staged for c
 	#	modified:   benchmarks.rb
 	#
 
-Both files are staged and will go into your next commit. At this point, suppose you remember one little change that you want to make in benchmarks.rb before you commit it. You open it again and make that change, and you’re ready to commit. However, let’s run `git status` one more time:
+كلا الملفين الآن جاهز للإدخال بعملية commit المقبلة. في هذه النقطة، لنفرض أنك تود القيام بتعديل على ملف benchmarks.rb قبل القيام بعملية commit، ستقوم بفتح الملف والتعديل عليه وأنك جاهز للقيام بعملية commit. لكن قبل ذلك، دعنا نقوم بتنفيذ الأمر git status مرة إضافية:
 
 	$ vim benchmarks.rb 
 	$ git status
@@ -137,7 +136,7 @@ Both files are staged and will go into your next commit. At this point, suppose
 	#	modified:   benchmarks.rb
 	#
 
-What the heck? Now benchmarks.rb is listed as both staged and unstaged. How is that possible? It turns out that Git stages a file exactly as it is when you run the git add command. If you commit now, the version of benchmarks.rb as it was when you last ran the git add command is how it will go into the commit, not the version of the file as it looks in your working directory when you run git commit. If you modify a file after you run `git add`, you have to run `git add` again to stage the latest version of the file:
+ما الذي يحصل؟ كيف أصبح benchmarks.rb موجوداً تحت التبويبين staged و unstaged؟ لقد اتضح لنا أنّ git يقوم بتجهيز الملف على حالته عند قيامك بتنفيذ الأمر git add. إذا قمت بعمل commit الآن، ستكون نسخة benchmarks.rb كما كانت عند قيامك بتنفيذ الأمر git add وليس النسخة الجديدة التي حصلنا عليها بعد قيامنا بتعديل الملف. لذا إذا قمنا بتعديل ملف قبل قيامنا بتنفيذ git add، وقبل القيام بعملية commit، علينا تجهيز الملف مرة أخرى لعملية commit، وذلك بتنفيذ الأمر git add مرة جديدة:
 
 	$ git add benchmarks.rb
 	$ git status
@@ -149,26 +148,26 @@ What the heck? Now benchmarks.rb is listed as both staged and unstaged. How is t
 	#	modified:   benchmarks.rb
 	#
 
-### Ignoring Files ###
+### تجاهل الملفات ###
 
-Often, you’ll have a class of files that you don’t want Git to automatically add or even show you as being untracked. These are generally automatically generated files such as log files or files produced by your build system. In such cases, you can create a file listing patterns to match them named .gitignore.  Here is an example .gitignore file:
+غالباً ما تود من git تجاهل صنف من الملفات بحث لا يقوم بإضافتها تلقائياً أو لا يظهرها بأنّها غير متتبعة. تكون هذه الملفات عادة ملفات مولدة بشكل تلقائي مثل ملفات log و الملفات الوسيطة التي تولدها أدوات التطوير لديك. في مثل هذه الحالات/ يمكن إنشاء ملف .gitignore يحوي على أنماط لأسماء الملفات التي نرغب بتجاهلها. هذا مثال عمّا قد يحتويه ملف .gitignore:
 
 	$ cat .gitignore
 	*.[oa]
 	*~
 
-The first line tells Git to ignore any files ending in .o or .a — object and archive files that may be the product of building your code. The second line tells Git to ignore all files that end with a tilde (`~`), which is used by many text editors such as Emacs to mark temporary files. You may also include a log, tmp, or pid directory; automatically generated documentation; and so on. Setting up a .gitignore file before you get going is generally a good idea so you don’t accidentally commit files that you really don’t want in your Git repository.
+أول سطر يقوم بتوجيه git إلى تجاهل أي ملفات ذات لواحق من النوع o أو a - ملفات الكائنات وملفات الأرشيف وهي ملفات وسيطة تولدها أدوات بناء الكود عادة. السطر الثاني يوجه git إلى تجاهل أي ملفات تنتهي بالرمز (~) والتي تكون ملفات مؤقتة عادةً تستخدمها بعض برامج تحرير الكود. قد ترغب أيضاً بإضافة مجلدات log و tmp أو pid؛ أو حتى ملفات التوثيق تلقائية التوليد (من الكود عادة)، وغيرها. ينصح بإضافة ملف .gitignore في بداية إنشاء repository حتى نتجنب إضافة بعض الملفات عن طريق الخطأ وتلويث respository.
 
-The rules for the patterns you can put in the .gitignore file are as follows:
+قواعد الأنماط التي يمكن وضعها ضمن ملف .gitignore هي كالتالي:
 
-*	Blank lines or lines starting with # are ignored.
-*	Standard glob patterns work.
-*	You can end patterns with a forward slash (`/`) to specify a directory.
-*	You can negate a pattern by starting it with an exclamation point (`!`).
+*	الأسطر التي تبدأ بالرمز (#) يتم تجاهلها.
+*	أنماط glob القياسية تعمل.
+*	يمكن إنهاء النمط برمز (/) للدلالة على أنه يستهدف مجلداً.
+*	يمكن نفي نمط ما عن طريق وضع علامة التعجب (!) في بداية السطر قبل النمط.
 
-Glob patterns are like simplified regular expressions that shells use. An asterisk (`*`) matches zero or more characters; `[abc]` matches any character inside the brackets (in this case a, b, or c); a question mark (`?`) matches a single character; and brackets enclosing characters separated by a hyphen(`[0-9]`) matches any character between them (in this case 0 through 9) . 
+أنماط Glob عبارة عن نسخة مبسطة من Regular Expressions يتم استخدامها ضمن واجهة الأوامر shell. رمز النجمة (*) يطابق صفر-محرفاً أو أكثر. `[abc]` تطابق أي محارف ضمن الأقواس المربعة في هذه الحالة تكون a b c؛ علامة الاستفهام (?) تطابق محرفاً واحداً فقط؛ بينما تطابق الأقواس المربعة التي تحوي على محارف مفصولة بإشارة hyphen أي محرفاً يقع في المجال بين محرف البداية والنهاية - مثلا [0-9] يطابق محارف الأرقام بين 0 و 9 ضمناً.
 
-Here is another example .gitignore file:
+مثال عن ملف .gitignore:
 
 	# a comment – this is ignored
 	# no .a files
@@ -182,7 +181,7 @@ Here is another example .gitignore file:
 	# ignore doc/notes.txt, but not doc/server/arch.txt
 	doc/*.txt
 
-### Viewing Your Staged and Unstaged Changes ###
+### مشاهدة التغيّرات المجهّزة والتغيّرات غير المجهّزة ###
 
 If the `git status` command is too vague for you — you want to know exactly what you changed, not just which files were changed — you can use the `git diff` command. We’ll cover `git diff` in more detail later; but you’ll probably use it most often to answer these two questions: What have you changed but not yet staged? And what have you staged that you are about to commit? Although `git status` answers those questions very generally, `git diff` shows you the exact lines added and removed — the patch, as it were. 
 

From 0fa39cad0a85ea9b848c8c96862f167ae8c660ea Mon Sep 17 00:00:00 2001
From: Ulf Ninow <mail@fnumatic.de>
Date: Sun, 7 Sep 2014 11:27:29 +0200
Subject: [PATCH 624/690] fix typo in 01-chapter2

---
 de/02-git-basics/01-chapter2.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/de/02-git-basics/01-chapter2.markdown b/de/02-git-basics/01-chapter2.markdown
index 525e6382b..c4be80626 100644
--- a/de/02-git-basics/01-chapter2.markdown
+++ b/de/02-git-basics/01-chapter2.markdown
@@ -1129,7 +1129,7 @@ Dieser Befehl lädt alle Daten aus dem Remote Repository herunter, die noch nich
 
 <!--If you clone a repository, the command automatically adds that remote repository under the name *origin*. So, `git fetch origin` fetches any new work that has been pushed to that server since you cloned (or last fetched from) it. It’s important to note that the `fetch` command pulls the data to your local repository — it doesn’t automatically merge it with any of your work or modify what you’re currently working on. You have to merge it manually into your work when you’re ready.-->
 
-Wenn Du ein Repository geklont hast, legt der Befehl automatisch einen Verweis auf dieses Repository unter dem Namen `origin` an. D.h. `git fetch origin` lädt alle Neuigkeiten herunter, die in dem Remote Repository von anderen hinzugefügt wurden, seit Du es geklont hast (oder zuletzt `git fetch` ausgeführt hast). Es ist wichtig, zu verstehen, dass der `git fetch` Befehl Daten lediglich in Dein lokales Repository lädt. Er führt sich mit Deinen eigenen Commits in keiner Weise zusammen (mergt) oder modifiziert, woran Du gerade arbeitest. D.h. Du musst die heruntergeladenen Änderungen anschließend selbst manuell mit Deinen eigenen zusammeführen, wenn Du das willst.
+Wenn Du ein Repository geklont hast, legt der Befehl automatisch einen Verweis auf dieses Repository unter dem Namen `origin` an. D.h. `git fetch origin` lädt alle Neuigkeiten herunter, die in dem Remote Repository von anderen hinzugefügt wurden, seit Du es geklont hast (oder zuletzt `git fetch` ausgeführt hast). Es ist wichtig, zu verstehen, dass der `git fetch` Befehl Daten lediglich in Dein lokales Repository lädt. Er führt sich mit Deinen eigenen Commits in keiner Weise zusammen (mergt) oder modifiziert, woran Du gerade arbeitest. D.h. Du musst die heruntergeladenen Änderungen anschließend selbst manuell mit Deinen eigenen zusammenführen, wenn Du das willst.
 
 <!--If you have a branch set up to track a remote branch (see the next section and *Chapter 3* for more information), you can use the `git pull` command to automatically fetch and then merge a remote branch into your current branch. This may be an easier or more comfortable workflow for you; and by default, the `git clone` command automatically sets up your local master branch to track the remote master branch on the server you cloned from (assuming the remote has a master branch). Running `git pull` generally fetches data from the server you originally cloned from and automatically tries to merge it into the code you’re currently working on.-->
 

From 20603d9eec60eb8ad79c82af91166446fc1b5fca Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Tue, 9 Sep 2014 18:20:13 +0200
Subject: [PATCH 625/690] Translating PR878

---
 it/09-git-internals/01-chapter9.markdown | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/it/09-git-internals/01-chapter9.markdown b/it/09-git-internals/01-chapter9.markdown
index 56fe57b36..82116868f 100644
--- a/it/09-git-internals/01-chapter9.markdown
+++ b/it/09-git-internals/01-chapter9.markdown
@@ -345,8 +345,13 @@ Ora, il tuo database Git assomiglia concettualmente alla Figura 9-4.
 Insert 18333fig0904.png 
 Figura 9-4. La directory degli oggetti Git directory con inclusi i riferimenti branch e head.
 
-Quando esegui comandi come `git branch (branchname)`, Git in realtà esegue il comando `update-ref` per
-aggiungere lo SHA-1 dell'ultima commit del branch nel quale siete, in qualsiasi nuovo riferimento vogliate creare.
+Quando esegui comandi come `git branch (branchname)`, Git in realtà esegue il comando `update-ref` per aggiungere lo SHA-1 dell'ultima commit del branch nel quale siete, in qualsiasi nuovo riferimento vogliate creare.
+
+Se Git non trova un riferimento nella directory `refs` lo cercherà nel file `.git/packed-refs`, che contiene coppie di percorsi con i relativi SHA-1. Per esempio:
+
+    52d771167707552d8e2a50f602c669e2ad135722 refs/tags/v1.0.1
+
+Questo file esiste per motivi di prestazioni, perché, per riferimenti che non cambiano spesso, è molto più efficiente avere un unico file, piuttosto che tanti piccolissimi. Puoi far comprimere a Git i riferimenti in questo file con il comando `git pack-refs`.
 
 ### Intestazione ###
 

From f93b8a3d28397f848e872db86eb5b941840f66fe Mon Sep 17 00:00:00 2001
From: Davide Fiorentino lo Regio <davide.fiorentino.loregio@gmail.com>
Date: Tue, 9 Sep 2014 18:26:34 +0200
Subject: [PATCH 626/690] [it] updating autocompletion output

As per PR #874
---
 it/02-git-basics/01-chapter2.markdown | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/it/02-git-basics/01-chapter2.markdown b/it/02-git-basics/01-chapter2.markdown
index aa304ff8e..b3621e6f9 100644
--- a/it/02-git-basics/01-chapter2.markdown
+++ b/it/02-git-basics/01-chapter2.markdown
@@ -1175,8 +1175,11 @@ In questo caso, scrivendo `git co` e premendo poi due volte il tasto Tab, compai
 
 Questo funziona anche con le opzioni, che probabilmente è molto più utile. Se per esempio stai eseguendo `git log` e non ricordi un'opzione, puoi premere il tasto Tab per vedere quelle disponibili:
 
-	$ git log --s<tab>
-	--shortstat  --since=  --src-prefix=  --stat   --summary
+	$ git log --s<tab><tab>
+	--shortstat               --sparse
+	--simplify-by-decoration  --src-prefix=
+	--simplify-merges         --stat
+	--since=                  --summary
 
 Questo è un trucco davvero utile e permette di risparmiare molto tempo e evitarti la lettura della documentazione.
 

From edfd7c840a99550f10161a986ee54ffd4e3fc0d4 Mon Sep 17 00:00:00 2001
From: "P. Tamami" <tamami.oka@gmail.com>
Date: Wed, 10 Sep 2014 16:00:30 +0700
Subject: [PATCH 627/690] Update 01-chapter3.markdown

update sub-head Basic Branching and Merging and partially in sub-sub-header Basic Branching
---
 id/03-git-branching/01-chapter3.markdown | 38 ++++++++++++------------
 1 file changed, 19 insertions(+), 19 deletions(-)

diff --git a/id/03-git-branching/01-chapter3.markdown b/id/03-git-branching/01-chapter3.markdown
index 3762d0418..13bb0bf7b 100644
--- a/id/03-git-branching/01-chapter3.markdown
+++ b/id/03-git-branching/01-chapter3.markdown
@@ -92,50 +92,50 @@ Hal ini kontras dengan cara yang dilakukan banyak VCS dalam branch, yang butuh m
 
 Mari kita lihat mengapa anda harus melakukannya.
 
-## Basic Branching and Merging ##
+## Dasar Pencabangan (Branching) dan Penggabungan (Merging) ##
 
-Let’s go through a simple example of branching and merging with a workflow that you might use in the real world. You’ll follow these steps:
+Mari kita lihat contoh sederhana dari Pencabangan dan Penggabungan dengan diagram alir yang biasa kita gunakan secara nyata. Anda akan mengikut tahapan berikut :
 
-1. Do work on a web site.
-2. Create a branch for a new story you’re working on.
-3. Do some work in that branch.
+1. Bekerja di jejaring (website).
+2. Buat pencabangan untuk hal baru yang sedang dikerjakan.
+3. Bekerja di pencabangan tersebut.
 
-At this stage, you’ll receive a call that another issue is critical and you need a hotfix. You’ll do the following:
+Pada tahap ini, anda akan menerima pesan bahwa ada masalah yang kritis dan anda perlu memperbaikinya. Anda akan melakukan tahapan berikut :
 
-1. Revert back to your production branch.
-2. Create a branch to add the hotfix.
-3. After it’s tested, merge the hotfix branch, and push to production.
-4. Switch back to your original story and continue working.
+1. Kembali ke pencabangan saat produksi.
+2. Membuat pencabangan untuk memperbaiki masalah.
+3. Setelah diuji, gabungkan pencabangan perbaikan tadi, dan tempatkan di bagian produksi.
+4. Kembali ke kasus sebelumnya dan kembali bekerja.
 
-### Basic Branching ###
+### Dasar Pencabangan ###
 
-First, let’s say you’re working on your project and have a couple of commits already (see Figure 3-10).
+Pertama, katakan anda sedang mengerjakan sebuah proyek dan telah melakukan *commits* (lihat Gambar 3-10).
 
 Insert 18333fig0310.png 
-Figure 3-10. A short and simple commit history.
+Gambar 3-10. Sejarah *commit* yang pendek dan sederhana.
 
-You’ve decided that you’re going to work on issue #53 in whatever issue-tracking system your company uses. To be clear, Git isn’t tied into any particular issue-tracking system; but because issue #53 is a focused topic that you want to work on, you’ll create a new branch in which to work. To create a branch and switch to it at the same time, you can run the `git checkout` command with the `-b` switch:
+Anda memutuskan untuk mengerjakan masalah #53 pada apapun jenis sistem pelacak-masalah yang digunakan perusahaan. Untuk memperjelas, Git tidak terikat dengan sistem pelacak-masalah apapun; tapi karena masalah #53 adalah inti topik yang akan dikerjakan, anda akan membuat pencabangan dimana anda bekerja. Untuk membuat pencabangan dan berpindah kesana dalam satu waktu, anda dapat menjalankan perintah `git checkout` dengan tanda `-b` :
 
 	$ git checkout -b iss53
 	Switched to a new branch "iss53"
 
-This is shorthand for:
+Ini adalah bentuk singkat untuk :
 
 	$ git branch iss53
 	$ git checkout iss53
 
-Figure 3-11 illustrates the result.
+Gambar 3-11 menjelaskan hasilnya.
 
 Insert 18333fig0311.png 
-Figure 3-11. Creating a new branch pointer.
+Gambar 3-11. Membuat penunjuk baru pencabangan.
 
-You work on your web site and do some commits. Doing so moves the `iss53` branch forward, because you have it checked out (that is, your HEAD is pointing to it; see Figure 3-12):
+Anda bekerja di jejaring *website* dan melakukan beberapa *commits*. Dengan melakukannya, menggeser cabang `iss53` kedepan, karena anda menyelesaikannya (demikianlah, HEAD anda penunjuk ke sana; lihat Gambar 3-12) :
 
 	$ vim index.html
 	$ git commit -a -m 'added a new footer [issue 53]'
 
 Insert 18333fig0312.png 
-Figure 3-12. The iss53 branch has moved forward with your work.
+Gambar 3-12. Cabang iss53 telah bergerak kedepan sesuai pekerjaan anda.
 
 Now you get the call that there is an issue with the web site, and you need to fix it immediately. With Git, you don’t have to deploy your fix along with the `iss53` changes you’ve made, and you don’t have to put a lot of effort into reverting those changes before you can work on applying your fix to what is in production. All you have to do is switch back to your master branch.
 

From dc4d50f37c8393eaa86a12d9f6b668c53d1929c9 Mon Sep 17 00:00:00 2001
From: Lauri Nurmi <lanurmi@iki.fi>
Date: Sat, 13 Sep 2014 22:12:32 +0300
Subject: [PATCH 628/690] [fi] Change the words used as translation for
 stage/staging area/etc.

The previously used word is based on the wrong meaning of "stage", not the one intended by Git.
---
 fi/01-introduction/01-chapter1.markdown | 14 ++---
 fi/02-git-basics/01-chapter2.markdown   | 70 ++++++++++++-------------
 fi/NOTES                                |  3 +-
 3 files changed, 44 insertions(+), 43 deletions(-)

diff --git a/fi/01-introduction/01-chapter1.markdown b/fi/01-introduction/01-chapter1.markdown
index ead7c3bf8..2c562dca0 100644
--- a/fi/01-introduction/01-chapter1.markdown
+++ b/fi/01-introduction/01-chapter1.markdown
@@ -97,26 +97,26 @@ Tämä tekee Gitin käyttämisestä hauskaa, koska me tiedämme, että voimme ko
 
 ### Kolme tilaa ###
 
-Lue nyt huolellisesti. Tämä on pääasia muistaa Gitistä, jos sinä haluat lopun opiskeluprosessistasi menevän sulavasti. Gitillä on kolme pääasiallista tilaa, joissa tiedostosi voivat olla: pysyvästi muutettu (commited), muutettu (modified), ja lavastettu (staged). Pysyvästi muutettu tarkoittaa, että data on turvallisesti varastoitu sinun paikalliseen tietokantaasi. Muutettu tarkoittaa, että olet muuttanut tiedostoa, mutta et ole tehnyt vielä pysyvää muutosta tietokantaasi. Lavastettu tarkoittaa, että olet merkannut muutetun tiedoston nykyisessä versiossaan menemään seuraavaan pysyvään tilannekuvaan.
+Lue nyt huolellisesti. Tämä on pääasia muistaa Gitistä, jos sinä haluat lopun opiskeluprosessistasi menevän sulavasti. Gitillä on kolme pääasiallista tilaa, joissa tiedostosi voivat olla: pysyvästi muutettu (commited), muutettu (modified), ja valmisteltu (staged). Pysyvästi muutettu tarkoittaa, että data on turvallisesti varastoitu sinun paikalliseen tietokantaasi. Muutettu tarkoittaa, että olet muuttanut tiedostoa, mutta et ole tehnyt vielä pysyvää muutosta tietokantaasi. Valmisteltu tarkoittaa, että olet merkannut muutetun tiedoston nykyisessä versiossaan menemään seuraavaan pysyvään tilannekuvaan.
 
-Tämä johdattaa meidät kolmeen seuraavaan osaan Git-projektia: Git-hakemisto, työskentelyhakemisto, ja lavastusalue.
+Tämä johdattaa meidät kolmeen seuraavaan osaan Git-projektia: Git-hakemisto, työskentelyhakemisto, ja valmistelualue.
 
 Insert 18333fig0106.png
-Kuva 1-6. Työskentelyhakemisto, lavastusalue, ja Git-hakemisto.
+Kuva 1-6. Työskentelyhakemisto, valmistelualue, ja Git-hakemisto.
 
 Git-hakemisto on paikka, johon Git varastoi metadatan ja oliotietokannan projektillesi. Tämä on kaikkein tärkein osa Gitiä, ja se sisältää sen, mitä kopioidaan, kun kloonaat tietovaraston toiselta tietokoneelta.
 
 Työskentelyhakemisto on yksittäinen tiedonhaku yhdestä projektin versiosta. Nämä tiedostot vedetään ulos pakatusta tietokannasta Git-hakemistosta ja sijoitetaan levylle sinun käytettäväksesi tai muokattavaksesi.
 
-Lavastusalue on yksinkertainen tiedosto, yleensä se sisältyy Git-hakemistoosi, joka varastoi informaatiota siitä, mitä menee seuraavaan pysyvään muutokseen. Sitä viitataan joskus indeksiksi, mutta on tulossa standardiksi viitata sitä lavastusalueeksi.
+Valmistelualue on yksinkertainen tiedosto, yleensä se sisältyy Git-hakemistoosi, joka varastoi informaatiota siitä, mitä menee seuraavaan pysyvään muutokseen. Sitä viitataan joskus indeksiksi, mutta on tulossa standardiksi viitata sitä valmistelualueeksi.
 
 Normaali Git-työnkulku menee jokseenkin näin:
 
 1. Muokkaat tiedostoja työskentelyhakemistossasi.
-2. Lavastat tiedostosi, lisäten niistä tilannekuvia lavastusalueellesi.
-3. Teet pysyvän muutoksen, joka ottaa tiedostot sellaisina, kuin ne ovat lavastusalueella, ja varastoi tämän tilannekuvan pysyvästi sinun Git-tietolähteeseesi.
+2. Valmistelet tiedostosi, lisäten niistä tilannekuvia valmistelualueellesi.
+3. Teet pysyvän muutoksen, joka ottaa tiedostot sellaisina, kuin ne ovat valmistelualueella, ja varastoi tämän tilannekuvan pysyvästi sinun Git-tietolähteeseesi.
 
-Jos tietty versio tiedostosta on Git-hakemistossa, se on yhtä kuin pysyvä muutos. Jos sitä on muokattu, mutta se on lisätty lavastusalueelle, se on lavastettu. Ja jos se on muuttunut siitä, kun se on haettu, mutta sitä ei ole lavastettu, se on muutettu. Luvussa 2 opit enemmän näistä tiloista ja kuinka voit hyödyntää niitä tai ohittaa lavastusosan kokonaan.
+Jos tietty versio tiedostosta on Git-hakemistossa, se on yhtä kuin pysyvä muutos. Jos sitä on muokattu, mutta se on lisätty valmistelualueelle, se on valmisteltu. Ja jos se on muuttunut siitä, kun se on haettu, mutta sitä ei ole valmisteltu, se on muutettu. Luvussa 2 opit enemmän näistä tiloista ja kuinka voit hyödyntää niitä tai ohittaa valmisteluvaiheen kokonaan.
 
 ## Gitin asennus ##
 
diff --git a/fi/02-git-basics/01-chapter2.markdown b/fi/02-git-basics/01-chapter2.markdown
index 2221d8629..259e0b2cb 100644
--- a/fi/02-git-basics/01-chapter2.markdown
+++ b/fi/02-git-basics/01-chapter2.markdown
@@ -1,6 +1,6 @@
 # Gitin perusteet #
 
-Jos voit lukea vain yhden kappaleen päästäksesi vauhtiin Gitin kanssa, se on tämä kappale. Tämä kappale sisältää jokaisen peruskomennon, jonka tarvitset tehdäksesi valtavan määrän asioita, joiden kanssa viimein tulet käyttämään aikaasi Gitillä työskennellessäsi. Tämän kappaleen lopussa, sinun tulisi pystyä konfiguroimaan ja alustamaan tietolähde, aloittamaan ja lopettamaan tiedostojen jäljitys sekä lavastaa ja tehdä pysyviä muutoksia. Me myös näytämme sinulle kuinka asettaa Git niin, että se jättää tietyt tiedostot ja tiedostomallit huomioimatta, kuinka kumota virheet nopeasti ja helposti, kuinka selata projektisi historiaa ja tarkastella muutoksia pysyvien muutosten välillä sekä kuinka työntää ja vetää etätietolähteistä.
+Jos voit lukea vain yhden kappaleen päästäksesi vauhtiin Gitin kanssa, se on tämä kappale. Tämä kappale sisältää jokaisen peruskomennon, jonka tarvitset tehdäksesi valtavan määrän asioita, joiden kanssa viimein tulet käyttämään aikaasi Gitillä työskennellessäsi. Tämän kappaleen lopussa, sinun tulisi pystyä konfiguroimaan ja alustamaan tietolähde, aloittamaan ja lopettamaan tiedostojen jäljitys sekä valmistelemaan ja tehdä pysyviä muutoksia. Me myös näytämme sinulle kuinka asettaa Git niin, että se jättää tietyt tiedostot ja tiedostomallit huomioimatta, kuinka kumota virheet nopeasti ja helposti, kuinka selata projektisi historiaa ja tarkastella muutoksia pysyvien muutosten välillä sekä kuinka työntää ja vetää etätietolähteistä.
 
 ## Git-tietolähteen hankinta ##
 
@@ -42,9 +42,9 @@ Gitissä on monta erilaista siirtoprotokollaa, joita voit käyttää. Edellinen
 
 Sinulla on oikea Git-tietolähde ja tiedonhaku (checkout) tai työkopio projektin tiedostoista. Sinun täytyy tehdä joitain muutoksia ja pysyviä tilannekuvia näistä muutoksista sinun tietolähteeseesi joka kerta, kun projekti saavuttaa tilan, jonka haluat tallentaa.
 
-Muista, että jokainen tiedosto työhakemistossasi voi olla yhdessä kahdesta tilasta: *jäljitetty* tai *jäljittämätön*. *Jäljitetyt* tiedostot ovat tiedostoja, jotka olivat viimeisimmässä tilannekuvassa; ne voivat olla *muokkaamattomia*, *muokattuja* tai *lavastettuja*. *Jäljittämättömät* tiedostot ovat kaikkea muuta - mitkä tahansa tiedostoja työhakemistossasi, jotka eivät olleet viimeisimmässä tilannekuvassa ja jotka eivät ole lavastusalueella. Kun ensimmäisen kerran kloonaat tietolähteen, kaikki tiedostoistasi tulevat olemaan jäljitettyjä ja muokkaamattomia, koska sinä juuri hait ne etkä ole muokannut vielä mitään.
+Muista, että jokainen tiedosto työhakemistossasi voi olla yhdessä kahdesta tilasta: *jäljitetty* tai *jäljittämätön*. *Jäljitetyt* tiedostot ovat tiedostoja, jotka olivat viimeisimmässä tilannekuvassa; ne voivat olla *muokkaamattomia*, *muokattuja* tai *valmisteltuja*. *Jäljittämättömät* tiedostot ovat kaikkea muuta - mitkä tahansa tiedostoja työhakemistossasi, jotka eivät olleet viimeisimmässä tilannekuvassa ja jotka eivät ole valmistelualueella. Kun ensimmäisen kerran kloonaat tietolähteen, kaikki tiedostoistasi tulevat olemaan jäljitettyjä ja muokkaamattomia, koska sinä juuri hait ne etkä ole muokannut vielä mitään.
 
-Editoidessasi tiedostoja Git näkee ne muokattuina, koska olet muuttanut niitä viimeisimmän pysyvän muutoksen jälkeen. *Lavastat* nämä muutetut tiedostot, jonka jälkeen muutat kaikki lavastetut muutokset pysyvästi, ja sykli toistuu. Tämä elämänsykli on kuvattu Kuvassa 2-1.
+Editoidessasi tiedostoja Git näkee ne muokattuina, koska olet muuttanut niitä viimeisimmän pysyvän muutoksen jälkeen. *Valmistelet* nämä muutetut tiedostot, jonka jälkeen muutat kaikki valmistellut muutokset pysyvästi, ja sykli toistuu. Tämä elämänsykli on kuvattu Kuvassa 2-1.
 
 Insert 18333fig0201.png 
 Kuva 2-1. Tiedostojesi tilan elämänsykli.
@@ -78,7 +78,7 @@ Jotta voisit jäljittää uusia tiedostoja, sinun täytyy käyttää `git add` -
 
 	$ git add README
 
-Jos ajat status-komennon uudestaan, näet että `README`-tiedostosi on nyt jäljitetty ja lavastettu:
+Jos ajat status-komennon uudestaan, näet että `README`-tiedostosi on nyt jäljitetty ja valmisteltu:
 
 	$ git status
 	# On branch master
@@ -88,9 +88,9 @@ Jos ajat status-komennon uudestaan, näet että `README`-tiedostosi on nyt jälj
 	#	new file:   README
 	#
 
-Voit nähdä, että se on lavastettu, koska se on otsikon ”Changes to be committed” alla. Jos teet pysyvän muutoksen tässä kohtaa, versio tiedostosta sillä hetkellä kun ajoit `git add` -komennon on se, joka tulee olemaan historian tilannekuvassa. Voit palauttaa mieleen hetken, jolloin ajoit `git init` -komennon aikaisemmin, ajoit sen jälkeen `git add (tiedostot)` -komennon - tämä komento aloitti tiedostojen jäljittämisen hakemistossa. `Git add` -komento ottaa polun nimen joko tiedostolle tai hakemistolle; jos se on hakemisto, komento lisää kaikki tiedostot hakemiston alta rekursiivisesti.
+Voit nähdä, että se on valmisteltu, koska se on otsikon ”Changes to be committed” alla. Jos teet pysyvän muutoksen tässä kohtaa, versio tiedostosta sillä hetkellä kun ajoit `git add` -komennon on se, joka tulee olemaan historian tilannekuvassa. Voit palauttaa mieleen hetken, jolloin ajoit `git init` -komennon aikaisemmin, ajoit sen jälkeen `git add (tiedostot)` -komennon - tämä komento aloitti tiedostojen jäljittämisen hakemistossa. `Git add` -komento ottaa polun nimen joko tiedostolle tai hakemistolle; jos se on hakemisto, komento lisää kaikki tiedostot hakemiston alta rekursiivisesti.
 
-### Muutettujen tiedostojen lavastus ###
+### Muutettujen tiedostojen valmistelu ###
 
 Muutetaanpa tiedostoa, joka on jo jäljitetty. Jos muutat aikaisemmin jäljitettyä `benchmarks.rb`-tiedostoa ja sen jälkeen ajat `status`-komennon uudestaan, saat suunnilleen tämän näköisen tulosteen:
 
@@ -107,7 +107,7 @@ Muutetaanpa tiedostoa, joka on jo jäljitetty. Jos muutat aikaisemmin jäljitett
 	#	modified:   benchmarks.rb
 	#
 
-`Benchmarks.rb`-tiedosto näkyy kohdan ”Changes not staged for commit” alla - mikä tarkoittaa, että tiedostoa, jota jäljitetään, on muokattu työskentelyhakemistossa, mutta sitä ei vielä ole lavastettu. Lavastaaksesi sen, ajat `git add` -komennon (se on monitoimikomento - käytät sitä aloittaaksesi uusien tiedostojen jäljittämisen, lavastaaksesi tiedostoja, ja tehdäksesi muita asioita, kuten merkataksesi liitoskonfliktitiedostot ratkaistuksi). Ajetaanpa nyt `git add` -komento lavastaaksemme `benchmarks.rb`-tiedoston, ja ajetaan sitten `git status` -komento uudestaan:
+`Benchmarks.rb`-tiedosto näkyy kohdan ”Changes not staged for commit” alla - mikä tarkoittaa, että tiedostoa, jota jäljitetään, on muokattu työskentelyhakemistossa, mutta sitä ei vielä ole valmisteltu. Valmistellaksesi sen, ajat `git add` -komennon (se on monitoimikomento - käytät sitä aloittaaksesi uusien tiedostojen jäljittämisen, valmistellaksesi tiedostoja, ja tehdäksesi muita asioita, kuten merkataksesi liitoskonfliktitiedostot ratkaistuksi). Ajetaanpa nyt `git add` -komento valmistellaksemme `benchmarks.rb`-tiedoston, ja ajetaan sitten `git status` -komento uudestaan:
 
 	$ git add benchmarks.rb
 	$ git status
@@ -119,7 +119,7 @@ Muutetaanpa tiedostoa, joka on jo jäljitetty. Jos muutat aikaisemmin jäljitett
 	#	modified:   benchmarks.rb
 	#
 
-Kummatkin tiedostot ovat lavastettuja ja tulevat menemään seuraavaan pysyvään muutokseen. Oletetaan, että tässä kohdassa muistat pienen muutoksen, jonka haluat tehdä `benchmarks.rb`-tiedostoon, ennen kuin teet pysyvää muutosta. Avaat tiedoston uudestaan ja muutat sitä, jonka jälkeen olet valmis tekemään pysyvän muutoksen. Ajetaan silti `git status` -komento vielä kerran:
+Kummatkin tiedostot ovat valmisteltuja ja tulevat menemään seuraavaan pysyvään muutokseen. Oletetaan, että tässä kohdassa muistat pienen muutoksen, jonka haluat tehdä `benchmarks.rb`-tiedostoon, ennen kuin teet pysyvää muutosta. Avaat tiedoston uudestaan ja muutat sitä, jonka jälkeen olet valmis tekemään pysyvän muutoksen. Ajetaan silti `git status` -komento vielä kerran:
 
 	$ vim benchmarks.rb 
 	$ git status
@@ -136,7 +136,7 @@ Kummatkin tiedostot ovat lavastettuja ja tulevat menemään seuraavaan pysyvää
 	#	modified:   benchmarks.rb
 	#
 
-Mitä ihmettä? Nyt `benchmarks.rb` on listattu sekä lavastettuna että lavastamattomana. Miten se on mahdollista? Tapahtuu niin, että Git lavastaa tiedoston juuri sellaisena kuin se on, kun ajat `git add` -komennon. Jos teet pysyvän muutoksen nyt, `benchmark.rb`-tiedoston versio sillä hetkellä, kun ajoit `git add` -komennon, on se, joka menee tähän pysyvään muutokseen, eikä se tiedoston versio, joka on työskentelyhakemistossasi sillä hetkellä, kun ajat `git commit` -komennon. Jos muutat tiedostoa sen jälkeen, kun olet ajanut `git add` -komennon, sinun täytyy ajaa `git add` uudestaan lavastaaksesi uusimman version tiedostosta:
+Mitä ihmettä? Nyt `benchmarks.rb` on listattu sekä valmisteltuna että valmistelemattomana. Miten se on mahdollista? Tapahtuu niin, että Git valmistelee tiedoston juuri sellaisena kuin se on, kun ajat `git add` -komennon. Jos teet pysyvän muutoksen nyt, `benchmark.rb`-tiedoston versio sillä hetkellä, kun ajoit `git add` -komennon, on se, joka menee tähän pysyvään muutokseen, eikä se tiedoston versio, joka on työskentelyhakemistossasi sillä hetkellä, kun ajat `git commit` -komennon. Jos muutat tiedostoa sen jälkeen, kun olet ajanut `git add` -komennon, sinun täytyy ajaa `git add` uudestaan valmistellaksesi uusimman version tiedostosta:
 
 	$ git add benchmarks.rb
 	$ git status
@@ -185,11 +185,11 @@ Tässä toinen esimerkki .gitignore-tiedostosta:
 
 `**/`-malli on saatavilla Gitin versiosta 1.8.2 lähtien.
 
-### Lavastettujen ja lavastamattomien muutosten tarkastelu ###
+### Valmisteltujen ja valmistelemattomien muutosten tarkastelu ###
 
-Jos `git status` -komento on liian epämääräinen sinulle - haluat tietää tarkalleen mitä on muutettu, et ainoastaan sitä, mitkä tiedostot ovat muuttuneet - voit käyttää `git diff` -komentoa. Me käsittelemme `git diff` -kommenon yksityiskohtaisesti myöhemmin; mutta sinä tulet mahdollisesti käyttämään sitä useasti, vastataksesi näihin kahteen kysymykseen: Mitä olet muuttanut, mutta et ole vielä lavastanut? Ja mitä sellaista olet lavastanut, josta olet tekemässä pysyvän muutoksen? Vaikkakin `git status` vastaa näihin kysymyksiin yleisesti, `git diff` näyttää sinulle tarkalleen ne rivit, jotka on lisätty ja poistettu - vähän niin kuin pätsi.
+Jos `git status` -komento on liian epämääräinen sinulle - haluat tietää tarkalleen mitä on muutettu, et ainoastaan sitä, mitkä tiedostot ovat muuttuneet - voit käyttää `git diff` -komentoa. Me käsittelemme `git diff` -kommenon yksityiskohtaisesti myöhemmin; mutta sinä tulet mahdollisesti käyttämään sitä useasti, vastataksesi näihin kahteen kysymykseen: Mitä olet muuttanut, mutta et ole vielä valmistellut? Ja mitä sellaista olet valmistellut, josta olet tekemässä pysyvän muutoksen? Vaikkakin `git status` vastaa näihin kysymyksiin yleisesti, `git diff` näyttää sinulle tarkalleen ne rivit, jotka on lisätty ja poistettu - vähän niin kuin pätsi.
 
-Sanotaan vaikka, että muokkaat ja lavastat `README`-tiedostoa uudestaan, jonka jälkeen muokkaat `benchmarks.rb`-tiedostoa, ilman että lavastat sitä. Jos ajat `status`-komennon, näet jälleen kerran jotain tällaista:
+Sanotaan vaikka, että muokkaat ja valmistelet `README`-tiedostoa uudestaan, jonka jälkeen muokkaat `benchmarks.rb`-tiedostoa, ilman että valmistelet sitä. Jos ajat `status`-komennon, näet jälleen kerran jotain tällaista:
 
 	$ git status
 	# On branch master
@@ -204,7 +204,7 @@ Sanotaan vaikka, että muokkaat ja lavastat `README`-tiedostoa uudestaan, jonka
 	#	modified:   benchmarks.rb
 	#
 
-Nähdäksesi, mitä olet muuttanut, mutta et vielä lavastanut, kirjoita `git diff` ilman mitään muita argumentteja:
+Nähdäksesi, mitä olet muuttanut, mutta et vielä valmistellut, kirjoita `git diff` ilman mitään muita argumentteja:
 
 	$ git diff
 	diff --git a/benchmarks.rb b/benchmarks.rb
@@ -223,9 +223,9 @@ Nähdäksesi, mitä olet muuttanut, mutta et vielä lavastanut, kirjoita `git di
 	           log = git.commits('master', 15)
 	           log.size
 
-Tämä komento vertailee sitä, mitä sinun työskentelyhakemistossa on verrattuna siihen, mitä sinun lavastusalueellasi on. Tulos kertoo tekemäsi muutokset, joita et ole vielä lavastanut.
+Tämä komento vertailee sitä, mitä sinun työskentelyhakemistossa on verrattuna siihen, mitä sinun valmistelualueellasi on. Tulos kertoo tekemäsi muutokset, joita et ole vielä valmistellut.
 
-Jos haluat nähdä, mitä sellaista olet lavastanut, joka menee seuraavaan pysyvään muutokseen, voit käyttää `git diff --cached` -komentoa. (Gitin versiosta 1.6.1 lähtien voit käyttää myös `git diff --staged` -komentoa, joka on helpompi muistaa.) Tämä komento vertailee lavastettuja muutoksia viimeisimpään pysyvään muutokseen.
+Jos haluat nähdä, mitä sellaista olet valmistellut, joka menee seuraavaan pysyvään muutokseen, voit käyttää `git diff --cached` -komentoa. (Gitin versiosta 1.6.1 lähtien voit käyttää myös `git diff --staged` -komentoa, joka on helpompi muistaa.) Tämä komento vertailee valmisteltuja muutoksia viimeisimpään pysyvään muutokseen.
 
 	$ git diff --cached
 	diff --git a/README b/README
@@ -240,9 +240,9 @@ Jos haluat nähdä, mitä sellaista olet lavastanut, joka menee seuraavaan pysyv
 	+
 	+Grit is a Ruby library for extracting information from a Git repository
 
-On tärkeää ottaa huomioon, että `git diff` itsessään ei näytä kaikkia muutoksia viimeisimmästä pysyvästä muutoksesta lähtien - vain muutokset, jotka ovat yhä lavastamattomia. Tämä voi olla sekavaa, koska kun olet lavastanut kaikki muutoksesi, `git diff` ei anna ollenkaan tulostetta.
+On tärkeää ottaa huomioon, että `git diff` itsessään ei näytä kaikkia muutoksia viimeisimmästä pysyvästä muutoksesta lähtien - vain muutokset, jotka ovat yhä valmistelemattomia. Tämä voi olla sekavaa, koska kun olet valmistellut kaikki muutoksesi, `git diff` ei anna ollenkaan tulostetta.
 
-Toisena esimerkkinä, jos lavastat `benchmarks.rb`-tiedoston ja sitten muokkaat sitä, voit käyttää `git diff` -komentoa nähdäksesi tiedoston lavastetut muutokset ja lavastamattomat muutokset:
+Toisena esimerkkinä, jos valmistelet `benchmarks.rb`-tiedoston ja sitten muokkaat sitä, voit käyttää `git diff` -komentoa nähdäksesi tiedoston valmistellut muutokset ja valmistelemattomat muutokset:
 
 	$ git add benchmarks.rb
 	$ echo '# test line' >> benchmarks.rb
@@ -258,7 +258,7 @@ Toisena esimerkkinä, jos lavastat `benchmarks.rb`-tiedoston ja sitten muokkaat
 	#	modified:   benchmarks.rb
 	#
 
-Nyt voit käyttää `git diff` -komentoa nähdäksesi, mitä on yhä lavastamatta:
+Nyt voit käyttää `git diff` -komentoa nähdäksesi, mitä on yhä valmistelematta:
 
 	$ git diff 
 	diff --git a/benchmarks.rb b/benchmarks.rb
@@ -271,7 +271,7 @@ Nyt voit käyttää `git diff` -komentoa nähdäksesi, mitä on yhä lavastamatt
 	 ##pp Grit::GitRuby.cache_client.stats 
 	+# test line
 
-Ja `git diff --cached` -komentoa nähdäksesi, mitä olet lavastanut tähän mennessä:
+Ja `git diff --cached` -komentoa nähdäksesi, mitä olet valmistellut tähän mennessä:
 
 	$ git diff --cached
 	diff --git a/benchmarks.rb b/benchmarks.rb
@@ -292,8 +292,8 @@ Ja `git diff --cached` -komentoa nähdäksesi, mitä olet lavastanut tähän men
 
 ### Pysyvien muutoksien tekeminen ###
 
-Nyt, kun lavastusalueesi on asetettu niin kuin sen haluat, voit tehdä muutoksistasi pysyviä. Muista, että kaikki, mikä vielä on lavastamatta - mitkä tahansa tiedostot, jotka olet luonut tai joita olet muokannut, joihin et ole ajanut `git add` -komentoa editoinnin jälkeen - eivät mene pysyvään muutokseen. Ne pysyvät muokattuina tiedostoina levylläsi.
-Tässä tapauksessa oletamme, että viime kerran, kun ajoit `git status` -komennon, näit, että kaikki oli lavastettu, joten olet valmis tekemään pysyvän muutoksen. Helpoin tapa pysyvän muutoksen tekoon on kirjoittaa `git commit`:
+Nyt, kun valmistelualueesi on asetettu niin kuin sen haluat, voit tehdä muutoksistasi pysyviä. Muista, että kaikki, mikä vielä on valmistelematta - mitkä tahansa tiedostot, jotka olet luonut tai joita olet muokannut, joihin et ole ajanut `git add` -komentoa editoinnin jälkeen - eivät mene pysyvään muutokseen. Ne pysyvät muokattuina tiedostoina levylläsi.
+Tässä tapauksessa oletamme, että viime kerran, kun ajoit `git status` -komennon, näit, että kaikki oli valmisteltu, joten olet valmis tekemään pysyvän muutoksen. Helpoin tapa pysyvän muutoksen tekoon on kirjoittaa `git commit`:
 
 	$ git commit
 
@@ -325,11 +325,11 @@ Vaihtoehtoisesti, voit kirjoittaa pysyvän muutoksen viestin suoraan `commit`-ko
 
 Nyt olet luonut ensimmäisen pysyvän muutoksen! Voit nähdä, että pysyvä muutos on antanut sinulle tulosteen itsestään: kertoen mihin haaraan teit pysyvän muutoksen (`master`), mikä SHA-1 tarkistussumma pysyvällä muutoksella on (`463dc4f`), kuinka monta tiedostoa muutettiin ja tilastoja pysyvän muutoksen rivien lisäyksistä ja poistoista.
 
-Muista, että pysyvä muutos tallentaa tilannekuvan lavastusalueestasi. Kaikki, mitä et lavastanut on yhä istumassa projektissasi muokattuna; voit tehdä toisen pysyvän muutoksen lisätäksesi ne historiaasi. Joka kerta, kun teet pysyvän muutoksen, olet tallentamassa tilannekuvaa projektistasi. Tilannekuvaa, johon voit palata tai jota voit vertailla myöhemmin. 
+Muista, että pysyvä muutos tallentaa tilannekuvan valmistelualueestasi. Kaikki, mitä et valmistellut on yhä istumassa projektissasi muokattuna; voit tehdä toisen pysyvän muutoksen lisätäksesi ne historiaasi. Joka kerta, kun teet pysyvän muutoksen, olet tallentamassa tilannekuvaa projektistasi. Tilannekuvaa, johon voit palata tai jota voit vertailla myöhemmin. 
 
-### Lavastusalueen ohittaminen ###
+### Valmistelualueen ohittaminen ###
 
-Vaikka lavastusalue voi olla uskomattoman hyödyllinen pysyvien muutoksien tekoon tarkalleen niin kuin ne haluat, on lavastusalue joskus hieman liian monimutkainen, kuin mitä työnkulussasi tarvitsisit. Jos haluat ohittaa lavastusalueen, Git tarjoaa siihen helpon oikoreitin. Antamalla `-a`-option `git commit` -komennolle, asettaa Gitin automaattisesti lavastamaan jokaisen jo jäljitetyn tiedoston ennen pysyvää muutosta, antaen sinun ohittaa `git add` -osan:
+Vaikka valmistelualue voi olla uskomattoman hyödyllinen pysyvien muutoksien tekoon tarkalleen niin kuin ne haluat, on valmistelualue joskus hieman liian monimutkainen, kuin mitä työnkulussasi tarvitsisit. Jos haluat ohittaa valmistelualueen, Git tarjoaa siihen helpon oikoreitin. Antamalla `-a`-option `git commit` -komennolle, asettaa Gitin automaattisesti valmistelemaan jokaisen jo jäljitetyn tiedoston ennen pysyvää muutosta, antaen sinun ohittaa `git add` -osan:
 
 	$ git status
 	# On branch master
@@ -346,9 +346,9 @@ Huomaa, miten sinun ei tarvitse ajaa `git add` -komentoa `benchmarks.rb`-tiedost
 
 ### Tiedostojen poistaminen ###
 
-Poistaaksesi tiedoston Gitistä, sinun täytyy poistaa se sinun jäljitetyistä tiedostoistasi (tarkemmin sanoen, poistaa se lavastusalueeltasi) ja sitten tehdä pysyvä muutos. Komento `git rm` tekee tämän ja myös poistaa tiedoston työskentelyhakemistostasi, joten et näe sitä enää jäljittämättömänä tiedostona.
+Poistaaksesi tiedoston Gitistä, sinun täytyy poistaa se sinun jäljitetyistä tiedostoistasi (tarkemmin sanoen, poistaa se valmistelualueeltasi) ja sitten tehdä pysyvä muutos. Komento `git rm` tekee tämän ja myös poistaa tiedoston työskentelyhakemistostasi, joten et näe sitä enää jäljittämättömänä tiedostona.
 
-Jos yksinkertaisesti poistat tiedoston työskentelyhakemistostasi, näkyy se ”Changes not staged for commit” otsikon alla (se on, _lavastamaton_) `git status` -tulosteessasi:
+Jos yksinkertaisesti poistat tiedoston työskentelyhakemistostasi, näkyy se ”Changes not staged for commit” otsikon alla (se on, _valmistelematon_) `git status` -tulosteessasi:
 
 	$ rm grit.gemspec
 	$ git status
@@ -360,7 +360,7 @@ Jos yksinkertaisesti poistat tiedoston työskentelyhakemistostasi, näkyy se ”
 	#       deleted:    grit.gemspec
 	#
 
-Jos ajat tämän jälkeen `git rm` -komennon, se lavastaa tiedostot poistoon:
+Jos ajat tämän jälkeen `git rm` -komennon, se valmistelee tiedostot poistoon:
 
 	$ git rm grit.gemspec
 	rm 'grit.gemspec'
@@ -375,7 +375,7 @@ Jos ajat tämän jälkeen `git rm` -komennon, se lavastaa tiedostot poistoon:
 
 Seuraavan kerran, kun teet pysyvän muutoksen, tiedosto katoaa ja sitä ei jäljitetä enää. Jos muokkasit tiedostoa ja lisäsit sen jo indeksiin, täytyy sinun pakottaa poisto `-f`-optiolla. Tämä on turvallisuusominaisuus, joka estää vahingossa tapahtuvan datan poistamisen, datan, jota ei ole vielä tallennettu tilannekuvaksi ja jota ei voida palauttaa Gitistä.
 
-Toinen hyödyllinen asia, jonka saatat haluta tehdä, on tiedoston pitäminen työskentelypuussa, mutta samalla sen poistaminen lavastusalueelta. Toisin sanoen, voit haluta pitää tiedoston kovalevylläsi, mutta et halua, että Git jäljittää sitä enää. Tämä on erityisesti hyödyllinen, jos unohdit lisätä jotain `.gitignore`-tiedostoosi ja vahingossa lavastit sellaisen, kuten suuri lokitiedosto tai joukko `.a`-muotoon käännettyjä tiedostoja. Tehdäksesi tämän, käytä `--cached`-optiota:
+Toinen hyödyllinen asia, jonka saatat haluta tehdä, on tiedoston pitäminen työskentelypuussa, mutta samalla sen poistaminen valmistelualueelta. Toisin sanoen, voit haluta pitää tiedoston kovalevylläsi, mutta et halua, että Git jäljittää sitä enää. Tämä on erityisesti hyödyllinen, jos unohdit lisätä jotain `.gitignore`-tiedostoosi ja vahingossa valmistelit sellaisen, kuten suuri lokitiedosto tai joukko `.a`-muotoon käännettyjä tiedostoja. Tehdäksesi tämän, käytä `--cached`-optiota:
 
 	$ git rm --cached readme.txt
 
@@ -682,11 +682,11 @@ Yksi yleinen kumoaminen tapahtuu, kun teet pysyvän muutoksen liian aikaisin ja
 
 	$ git commit --amend
 
-Tämä komento ottaa lavastusalueesi ja käyttää sitä pysyvään muutokseen. Jos et ole tehnyt muutoksia viimeisimmän pysyvän muutoksesi jälkeen (esimerkiksi, jos ajat tämän komennon heti edellisen pysyvän muutoksesi jälkeen), tilannekuvasi näyttää tarkalleen samalta ja kaikki, mitä muutat, on pysyvän muutoksesi viesti.
+Tämä komento ottaa valmistelualueesi ja käyttää sitä pysyvään muutokseen. Jos et ole tehnyt muutoksia viimeisimmän pysyvän muutoksesi jälkeen (esimerkiksi, jos ajat tämän komennon heti edellisen pysyvän muutoksesi jälkeen), tilannekuvasi näyttää tarkalleen samalta ja kaikki, mitä muutat, on pysyvän muutoksesi viesti.
 
 Sama pysyvän muutoksen viestin editori aktivoituu, mutta se sisältää jo viestin edellisestä pysyvästä muutoksesta. Voit muokata viestiä samoin kuin aina, mutta se korvaa edellisen pysyvän muutoksesi.
 
-Esimerkkinä, jos teet pysyvän muutoksen ja sitten huomaat unohtaneesi lavastaa muutokset tiedostossa, jonka haluat lisätä tähän pysyvään muutokseen, voit tehdä jotakuinkin seuraavasti:
+Esimerkkinä, jos teet pysyvän muutoksen ja sitten huomaat unohtaneesi valmistelee muutokset tiedostossa, jonka haluat lisätä tähän pysyvään muutokseen, voit tehdä jotakuinkin seuraavasti:
 
 	$ git commit -m 'initial commit'
 	$ git add unohtunut_tiedosto
@@ -694,9 +694,9 @@ Esimerkkinä, jos teet pysyvän muutoksen ja sitten huomaat unohtaneesi lavastaa
 
 Näiden kolmen komennon jälkeen päädyt yhteen pysyvään muutokseen — toinen pysyvä muutos korvaa ensimmäisen.
 
-### Lavastetun tiedoston lavastuksen purkaminen ###
+### Valmistellun tiedoston valmistelun purkaminen ###
 
-Kaksi seuraavaa kappaletta havainnollistavat, kuinka paimentaa muutoksia lavastusalueellasi ja työskentelyhakemistossasi. Mukava osa on, että komento, jota käytät selvittääksesi näiden kahden alueen tilan, muistuttaa sinua myös, kuinka peruuttaa muutokset niihin. Sanokaamme, esimerkiksi, että olet muuttanut kahta tiedostoa ja haluat tehdä niistä kaksi erillistä pysyvää muutosta, mutta kirjoitit vahingossa `git add *` ja lavastit ne molemmat. Kuinka voit purkaa toisen lavastuksen? `Git status` -komento muistuttaa sinua:
+Kaksi seuraavaa kappaletta havainnollistavat, kuinka paimentaa muutoksia valmistelualueellasi ja työskentelyhakemistossasi. Mukava osa on, että komento, jota käytät selvittääksesi näiden kahden alueen tilan, muistuttaa sinua myös, kuinka peruuttaa muutokset niihin. Sanokaamme, esimerkiksi, että olet muuttanut kahta tiedostoa ja haluat tehdä niistä kaksi erillistä pysyvää muutosta, mutta kirjoitit vahingossa `git add *` ja valmistelit ne molemmat. Kuinka voit purkaa toisen valmistelun? `Git status` -komento muistuttaa sinua:
 
 	$ git add .
 	$ git status
@@ -708,7 +708,7 @@ Kaksi seuraavaa kappaletta havainnollistavat, kuinka paimentaa muutoksia lavastu
 	#       modified:   benchmarks.rb
 	#
 
-Heti ”Changes to be committed” -tekstin alla, sanotaan "use `git reset HEAD <file>...` to unstage". Joten, käyttäkäämme tätä neuvoa purkaaksemme `benchmarks.rb`-tiedoston lavastuksen:
+Heti ”Changes to be committed” -tekstin alla, sanotaan "use `git reset HEAD <file>...` to unstage". Joten, käyttäkäämme tätä neuvoa purkaaksemme `benchmarks.rb`-tiedoston valmistelun:
 
 	$ git reset HEAD benchmarks.rb
 	benchmarks.rb: locally modified
@@ -726,11 +726,11 @@ Heti ”Changes to be committed” -tekstin alla, sanotaan "use `git reset HEAD
 	#       modified:   benchmarks.rb
 	#
 
-Komento on hieman kummallinen, mutta se toimii. `Benchmarks.rb`-tiedosto on muokattu mutta lavastamaton jälleen.
+Komento on hieman kummallinen, mutta se toimii. `Benchmarks.rb`-tiedosto on muokattu mutta valmistelematon jälleen.
 
 ### Muutetun tiedoston muutosten kumoaminen ###
 
-Mitä, jos tajuat, ettet halua säilyttää muutoksiasi `benchmarks.rb`-tiedostoon? Kuinka voit helposti kumota sen muutokset — palauttaa sen takaisin sellaiseksi, miltä se näytti, kun teit viimeksi pysyvän muutoksen (tai alun perin kloonasit tai miten saitkaan sen työskentelyhakemistoosi)? Onneksi `git status` kertoo sinulle myös, miten tämä tehdään. Edellisessä esimerkkitulosteessa lavastamaton alue näyttää tältä:
+Mitä, jos tajuat, ettet halua säilyttää muutoksiasi `benchmarks.rb`-tiedostoon? Kuinka voit helposti kumota sen muutokset — palauttaa sen takaisin sellaiseksi, miltä se näytti, kun teit viimeksi pysyvän muutoksen (tai alun perin kloonasit tai miten saitkaan sen työskentelyhakemistoosi)? Onneksi `git status` kertoo sinulle myös, miten tämä tehdään. Edellisessä esimerkkitulosteessa valmistelematon alue näyttää tältä:
 
 	# Changes not staged for commit:
 	#   (use "git add <file>..." to update what will be committed)
diff --git a/fi/NOTES b/fi/NOTES
index fef3c2fe5..84cb89f3c 100644
--- a/fi/NOTES
+++ b/fi/NOTES
@@ -1,4 +1,5 @@
 Chapter 1 - Line 56: 		What is a proper finnish translation for the word "snapshot" in this case? Translated now as 'tilannekuvat'.
 						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?
-						Chapter "The Three Stages" ("Kolme tilaa") has mentioned the "staged" word, what is correct translation for this in finnish? Now translated as "lavastettu".
+						Chapter "The Three Stages" ("Kolme tilaa") has mentioned the "staged" word, what is correct translation for this in finnish? Was translated as "lavastettu".
+                        -> "lavastettu" is an obvious but bad choice, because it's based on another meaning of "stage", not the one that Git uses. Now translated as "valmisteltu".
 						Line 230:		Translation for a word "Backports"

From de335675711b41e4b9d1e5f2f339b9f81d3d3a26 Mon Sep 17 00:00:00 2001
From: "P. Tamami" <tamami.oka@gmail.com>
Date: Mon, 15 Sep 2014 16:12:59 +0700
Subject: [PATCH 629/690] Update 01-chapter3.markdown

update in a few paragraph at Basic Branching.
---
 id/03-git-branching/01-chapter3.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/id/03-git-branching/01-chapter3.markdown b/id/03-git-branching/01-chapter3.markdown
index 13bb0bf7b..0595c1a6b 100644
--- a/id/03-git-branching/01-chapter3.markdown
+++ b/id/03-git-branching/01-chapter3.markdown
@@ -137,7 +137,7 @@ Anda bekerja di jejaring *website* dan melakukan beberapa *commits*. Dengan mela
 Insert 18333fig0312.png 
 Gambar 3-12. Cabang iss53 telah bergerak kedepan sesuai pekerjaan anda.
 
-Now you get the call that there is an issue with the web site, and you need to fix it immediately. With Git, you don’t have to deploy your fix along with the `iss53` changes you’ve made, and you don’t have to put a lot of effort into reverting those changes before you can work on applying your fix to what is in production. All you have to do is switch back to your master branch.
+Lalu kemudian, saat kita melihat ada permasalahan dalam situs jejaring, dan kita perlu untuk memperbaikinya segera. Dengan Git, anda tidak perlu memasang pembetulannya bersama dengan perubahan di `iss53`, dan anda tidak perlu melakukan cara yang sulit untuk kembali ke pekerjaan anda sebelumnya di tahap produksi. Yang anda perlukan hanya kembali ke pencabangan *master*.
 
 However, before you do that, note that if your working directory or staging area has uncommitted changes that conflict with the branch you’re checking out, Git won’t let you switch branches. It’s best to have a clean working state when you switch branches. There are ways to get around this (namely, stashing and commit amending) that we’ll cover later. For now, you’ve committed all your changes, so you can switch back to your master branch:
 

From 1caee30dd15edb93d6abad3fc4f9c7c485b46f85 Mon Sep 17 00:00:00 2001
From: "P. Tamami" <tamami.oka@gmail.com>
Date: Tue, 16 Sep 2014 15:46:52 +0700
Subject: [PATCH 630/690] Update 01-chapter3.markdown

Translate just one paragraph in Basic Branching
---
 id/03-git-branching/01-chapter3.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/id/03-git-branching/01-chapter3.markdown b/id/03-git-branching/01-chapter3.markdown
index 0595c1a6b..ff4bd8c44 100644
--- a/id/03-git-branching/01-chapter3.markdown
+++ b/id/03-git-branching/01-chapter3.markdown
@@ -139,7 +139,7 @@ Gambar 3-12. Cabang iss53 telah bergerak kedepan sesuai pekerjaan anda.
 
 Lalu kemudian, saat kita melihat ada permasalahan dalam situs jejaring, dan kita perlu untuk memperbaikinya segera. Dengan Git, anda tidak perlu memasang pembetulannya bersama dengan perubahan di `iss53`, dan anda tidak perlu melakukan cara yang sulit untuk kembali ke pekerjaan anda sebelumnya di tahap produksi. Yang anda perlukan hanya kembali ke pencabangan *master*.
 
-However, before you do that, note that if your working directory or staging area has uncommitted changes that conflict with the branch you’re checking out, Git won’t let you switch branches. It’s best to have a clean working state when you switch branches. There are ways to get around this (namely, stashing and commit amending) that we’ll cover later. For now, you’ve committed all your changes, so you can switch back to your master branch:
+Bagaimanapun, sebelum anda melakukannya, perhatikan bahwa jika dalam kandar kerja anda atau kondisi *staging* memiliki perubahan yang bertentangan dengan pencabangan yang akan anda tinggalkan, Git tidak akan memperbolehkan anda berpindah. Ini adalah cara terbaik untuk meninggalkan pekerjaan dalam keadaan bersih ketika anda akan berpindah pencabangan. Ada beberapa cara untuk melakukan ini (*namely*, *stashing*, dan merubah *commit*) yang akan kita bahas berikutnya. Untuk saat ini, anda telah *commit* seluruh perubahan, sehingga anda dapat kembali ke pencabangan *master*:
 
 	$ git checkout master
 	Switched to branch "master"

From ef7acd6bc7dcae1b2b4c90e3f572c27e74aac1d6 Mon Sep 17 00:00:00 2001
From: Maro Shim <scmaro@users.noreply.github.com>
Date: Wed, 17 Sep 2014 13:18:35 +0900
Subject: [PATCH 631/690] Update 01-chapter2.markdown
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

"마지막으로 커밋한 후에 수정한 것들 전부를 보여주지 않는다."

all changes made since your last commit의 번역입니다.

읽다가 조금 이해가 잘 안되어서 원문을 참조했습니다.
---
 ko/02-git-basics/01-chapter2.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ko/02-git-basics/01-chapter2.markdown b/ko/02-git-basics/01-chapter2.markdown
index 61764f4ab..da62f4c31 100644
--- a/ko/02-git-basics/01-chapter2.markdown
+++ b/ko/02-git-basics/01-chapter2.markdown
@@ -243,7 +243,7 @@ README 파일을 수정해서 Staged 상태로 만들고 benchmarks.rb 파일은
 	+
 	+Grit is a Ruby library for extracting information from a Git repository
 
-꼭 잊지 말아야 할 것이 있는데 `git diff` 명령은 마지막으로 커밋한 후에 수정한 것을 보여주지 않는다. `git diff`는 Unstaged 상태인 것들만 보여준다. 이 부분이 조금 헷갈릴 수 있다. 수정한 파일을 모두 Staging Area에 넣었다면 `git diff` 명령은 아무것도 출력하지 않는다.
+꼭 잊지 말아야 할 것이 있는데 `git diff` 명령은 마지막으로 커밋한 후에 수정한 것들 전부를 보여주지 않는다. `git diff`는 Unstaged 상태인 것들만 보여준다. 이 부분이 조금 헷갈릴 수 있다. 수정한 파일을 모두 Staging Area에 넣었다면 `git diff` 명령은 아무것도 출력하지 않는다.
 
 benchmarks.rb 파일을 Stage한 후에 다시 수정해도 `git diff` 명령을 사용할 수 있다. 이때는 Staged 상태인 것과 Unstaged 상태인 것을 비교한다:
 

From 81376e39662b5850272420f6637b7a4773e6a029 Mon Sep 17 00:00:00 2001
From: "P. Tamami" <tamami.oka@gmail.com>
Date: Sun, 21 Sep 2014 09:57:08 +0700
Subject: [PATCH 632/690] Update 01-chapter3.markdown

update 1 (one) paragraph
---
 id/03-git-branching/01-chapter3.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/id/03-git-branching/01-chapter3.markdown b/id/03-git-branching/01-chapter3.markdown
index ff4bd8c44..8c9184375 100644
--- a/id/03-git-branching/01-chapter3.markdown
+++ b/id/03-git-branching/01-chapter3.markdown
@@ -144,7 +144,7 @@ Bagaimanapun, sebelum anda melakukannya, perhatikan bahwa jika dalam kandar kerj
 	$ git checkout master
 	Switched to branch "master"
 
-At this point, your project working directory is exactly the way it was before you started working on issue #53, and you can concentrate on your hotfix. This is an important point to remember: Git resets your working directory to look like the snapshot of the commit that the branch you check out points to. It adds, removes, and modifies files automatically to make sure your working copy is what the branch looked like on your last commit to it.
+Saat ini, anda berada dalam kandar kerja dalam kondisi tepat seperti anda belum mengerjakan masalah #53, dan anda dapat konsentrasi mengerjakan perbaikannya. Hal yang perlu diingat adalah: Git mengkondisikan kandar kerja anda agar terlihat sebagaimana anda kembali ke titik pencabangan yang anda tuju. Git menambahkan, menghapus, dan mengubah berkas secara otomatis untuk memastikan bahwa anda bekerja pada pencabangan terakhir yang anda *commit*.
 
 Next, you have a hotfix to make. Let’s create a hotfix branch on which to work until it’s completed (see Figure 3-13):
 

From 1827b5ef76d31602e6969d03e90786dd0877c36c Mon Sep 17 00:00:00 2001
From: "Ammar M. Zerouk" <ammarzerouk@outlook.com>
Date: Tue, 23 Sep 2014 03:18:26 +0300
Subject: [PATCH 633/690] [ar] translating  and

---
 ar/02-git-basics/01-chapter2.markdown | 37 +++++++++++++--------------
 1 file changed, 18 insertions(+), 19 deletions(-)

diff --git a/ar/02-git-basics/01-chapter2.markdown b/ar/02-git-basics/01-chapter2.markdown
index da77fdd39..89e6b9ae2 100644
--- a/ar/02-git-basics/01-chapter2.markdown
+++ b/ar/02-git-basics/01-chapter2.markdown
@@ -183,9 +183,10 @@ Insert 18333fig0201.png
 
 ### مشاهدة التغيّرات المجهّزة والتغيّرات غير المجهّزة ###
 
-If the `git status` command is too vague for you — you want to know exactly what you changed, not just which files were changed — you can use the `git diff` command. We’ll cover `git diff` in more detail later; but you’ll probably use it most often to answer these two questions: What have you changed but not yet staged? And what have you staged that you are about to commit? Although `git status` answers those questions very generally, `git diff` shows you the exact lines added and removed — the patch, as it were. 
+إذا لم تكتف بالمعلومات التي يقدمها لك أمر `git status` يمكنك استخدام أمر `git diff`  للحصول على معلومات تفصيلية حول التغيرات التي طرأت على الملفات. سنقوم لاحقاً بالتعمق في هذا الأمر، لكن الآن سنكتفي بالإشارة إلى الاستخدامات الغالبة له؛ حيث أنك ستستخدمه غالباً للحصول على أجوبة على هذين السؤالين: ما الذي قمنا بالتعديل عليه ولم نجهزه بعد لعملية commit؟ ما الملفات التي أصبحت جاهزة للدخول في عملية commit المقبلة؟
+بالرغم من أنه يمكننا أن نحصل على هذه المعلومات باستخدام أمر `git status` إلا أنّ أمر `git diff` يوضح لنا التغيرات التي جرت على مستوى السطر والحرف - ما الذي قمنا بإضافته وما الذي أزلناه!
 
-Let’s say you edit and stage the README file again and then edit the benchmarks.rb file without staging it. If you run your `status` command, you once again see something like this:
+لنقل أنك قمت بالتعديل على ملف README مرة أخرى وأشرته للإضافة إلى عملية commit وقمت بالتعديل على ملف benchmarks.rb ولم تضفه إلى قائمة الملفات الجاهزة لعملية commit؛ إذا قمت بتنفيذ الأمر `status` ستشاهد مرة أخرى شيئاً من الشكل:
 
 	$ git status
 	# On branch master
@@ -200,7 +201,7 @@ Let’s say you edit and stage the README file again and then edit the benchmark
 	#	modified:   benchmarks.rb
 	#
 
-To see what you’ve changed but not yet staged, type `git diff` with no other arguments:
+لترى ما قمت بالتعديل عليه ولم تجهزه للإضافة نفذ الأمر `git diff` بدون إضافات:
 
 	$ git diff
 	diff --git a/benchmarks.rb b/benchmarks.rb
@@ -219,9 +220,9 @@ To see what you’ve changed but not yet staged, type `git diff` with no other a
 	           log = git.commits('master', 15)
 	           log.size
 
-That command compares what is in your working directory with what is in your staging area. The result tells you the changes you’ve made that you haven’t yet staged.
+يقوم هذا الأمر بعمل مقارنة بين الملفات ضمن مجلد العمل والملفات الموجودة في منطقة التعديلات المجهزة للإضافة staging area. وتخبرنا نتيجته بالتعديلات التي أجريناها ولم نقم بتجهيزها للإضافة إلى عملية commit المقبلة.
 
-If you want to see what you’ve staged that will go into your next commit, you can use `git diff –-cached`. (In Git versions 1.6.1 and later, you can also use `git diff –-staged`, which may be easier to remember.) This command compares your staged changes to your last commit:
+لمشاهدة الملفات ذات الحالة staged والتي ستدخل في عملية commit المقبلة، يمكن استخدام الأمر `git diff --cached` (بالنسبة للإصدارات 1.6.1 وما بعد من git يمكنك أيضاً استخدام الأمر `git diff --staged` )، كالتالي:
 
 	$ git diff --cached
 	diff --git a/README b/README
@@ -236,9 +237,9 @@ If you want to see what you’ve staged that will go into your next commit, you
 	+
 	+Grit is a Ruby library for extracting information from a Git repository
 
-It’s important to note that `git diff` by itself doesn’t show all changes made since your last commit — only changes that are still unstaged. This can be confusing, because if you’ve staged all of your changes, `git diff` will give you no output.
+من الجدير بالذكر أن أمر `git diff` لوحده لا يقوم بعرض جميع التعديلات التي تمت من آخر commit - فهو يقوم بعرض فقط التعديلات التي لم تؤشر على أنها staged. ويمكن أن يسبب ذلك بعض الإرباك، حيث أنك إذا قمت بإضافة جميع التعديلات إلى قائمة staged فلن يقوم بعرض أي شي في خرج تنفيذه.
 
-For another example, if you stage the benchmarks.rb file and then edit it, you can use `git diff` to see the changes in the file that are staged and the changes that are unstaged:
+كمثال أيضاً، إذا قمنا بإضافة benchmarks.rb إلى قائمة staged ومن ثم قمنا بالتعديل عليه من جديد، يمكننا استخدام أمر `git diff` للحصول على لائحة بالتغييرات التي حصلت ولم تضف إلى قائمة staged كالتالي:
 
 	$ git add benchmarks.rb
 	$ echo '# test line' >> benchmarks.rb
@@ -254,7 +255,6 @@ For another example, if you stage the benchmarks.rb file and then edit it, you c
 	#	modified:   benchmarks.rb
 	#
 
-Now you can use `git diff` to see what is still unstaged
 
 	$ git diff 
 	diff --git a/benchmarks.rb b/benchmarks.rb
@@ -267,7 +267,7 @@ Now you can use `git diff` to see what is still unstaged
 	 ##pp Grit::GitRuby.cache_client.stats 
 	+# test line
 
-and `git diff --cached` to see what you’ve staged so far:
+وباستخدام `git diff --cached` نتمكن من رؤية ما تم تجهيزه للإضافة إلى عملية commit القادمة:
 
 	$ git diff --cached
 	diff --git a/benchmarks.rb b/benchmarks.rb
@@ -286,16 +286,15 @@ and `git diff --cached` to see what you’ve staged so far:
 	          log = git.commits('master', 15)
 	          log.size
 
-### Committing Your Changes ###
+### القيام بعملية (اعتماد) commit للتغيّرات ###
 
-Now that your staging area is set up the way you want it, you can commit your changes. Remember that anything that is still unstaged — any files you have created or modified that you haven’t run `git add` on since you edited them — won’t go into this commit. They will stay as modified files on your disk.
-In this case, the last time you ran `git status`, you saw that everything was staged, so you’re ready to commit your changes. The simplest way to commit is to type `git commit`:
+بعد اكمال تجهيز الملفات التي ترغب بإضافتها إلى النسخة snapshot الجديدة، يمكنك تنفيذ أمر commit ليتم اعتماد التعديلات التي أجريتها في سجل git. تذكر أنّ أي ملف لم يتم تجهيزه - سواء لم تقم بإضافته باستخدام الأمر git add بعد إنشاءه أو التعديل عليه - لن يدخل في هذه الإعتمادية، وستبقى على أنها ملفات تم تعديلها في مجلد العمل. أبسط طريقة لاعتماد التعديلات هي القيام بأمر `git commit` كالتالي:
 
 	$ git commit
 
-Doing so launches your editor of choice. (This is set by your shell’s `$EDITOR` environment variable — usually vim or emacs, although you can configure it with whatever you want using the `git config --global core.editor` command as you saw in Chapter 1). 
+تنفيذ هذا الأمر سيطلب منا إدخال رسالة عملية commit - عادة ما يتم فتح محرر النصوص المشار إليه بمتغير البيئة `$EDITOR`. يمكنك تهيئته عن طريق الأمر `git config --global core.editor` كما شاهدنا في الفصل الأول.
 
-The editor displays the following text (this example is a Vim screen):
+يقوم محرر النصوص بعرض هذه الشاشة (مثالنا باستخدام VIM):
 
 	# Please enter the commit message for your changes. Lines starting
 	# with '#' will be ignored, and an empty message aborts the commit.
@@ -310,20 +309,20 @@ The editor displays the following text (this example is a Vim screen):
 	~
 	".git/COMMIT_EDITMSG" 10L, 283C
 
-You can see that the default commit message contains the latest output of the `git status` command commented out and one empty line on top. You can remove these comments and type your commit message, or you can leave them there to help you remember what you’re committing. (For an even more explicit reminder of what you’ve modified, you can pass the `-v` option to `git commit`. Doing so also puts the diff of your change in the editor so you can see exactly what you did.) When you exit the editor, Git creates your commit with that commit message (with the comments and diff stripped out).
+يمكنك ملاحظة أن رسالة عملية commit تحوي على خرج آخر عملية `git status` على شكل تعليقات بالإضافة إلى سطر فارغ في بداية الملف. يمكنك إزالة هذه التعليقات، أو يمكنك تركها لمساعدتك بتذكر ما قمت باعتماد تعديلاته. يمكنك الحصول على معلومات أكثر تفصلياً إذا قمت بتمرير الخيار `-v` إلى الأمر `git commit`. حيث يقوم ذلك بإضافة خرج أمر `git diff` إلى رسالة commit على شكل تعليقات أيضاً. عند إغلاق المحرر يقوم git بإنشاء commit ويتجاهل التعليقات.
 
-Alternatively, you can type your commit message inline with the `commit` command by specifying it after a -m flag, like this:
+علماً أنّه يمكنك كتابة رسالة الاعتمادية مباشرة من خلال تمرير الخيار `-m` إلى الأمر `git commit` على الشكل التالي:
 
 	$ git commit -m "Story 182: Fix benchmarks for speed"
 	[master]: created 463dc4f: "Fix benchmarks for speed"
 	 2 files changed, 3 insertions(+), 0 deletions(-)
 	 create mode 100644 README
 
-Now you’ve created your first commit! You can see that the commit has given you some output about itself: which branch you committed to (master), what SHA-1 checksum the commit has (`463dc4f`), how many files were changed, and statistics about lines added and removed in the commit.
+مبروك، لقد قمت بعمل أول commit لك! يعطيك خرج العملية معلومات عنها: في أي فرع branch تم الإعتماد (هنا master)، ما قيمة هاش SHA-1 الخاصة بالعملية ( هنا `463dc4f`)، عدد الملفات التي تغيّرت، بالإضافة إلى إحصاءات حول الأسطر التي أضيفت وأزيلت في هذه العملية.
 
-Remember that the commit records the snapshot you set up in your staging area. Anything you didn’t stage is still sitting there modified; you can do another commit to add it to your history. Every time you perform a commit, you’re recording a snapshot of your project that you can revert to or compare to later.
+تذكر أنّ عملية commit تأخذ صورة عن الملفات في قائمة staged. أي شيء لم تقم بإضافته إلى هذه القائمة ما زال في مجلد العمل بحالة "معدل" modified؛ يمكنك القيام بإضافتهم من خلال عملية commit جديدة إلى التأريخ في git. نستنتج أنّه في كل عملية commit يقوم git بأخذ "صورة" snapshot عن المشروع يمكننا العودة لها لاحقاً أو مقارنتها أو غير ذلك..
 
-### Skipping the Staging Area ###
+### تجاوز منطقة التجهيز Staging Area ###
 
 Although it can be amazingly useful for crafting commits exactly how you want them, the staging area is sometimes a bit more complex than you need in your workflow. If you want to skip the staging area, Git provides a simple shortcut. Providing the `-a` option to the `git commit` command makes Git automatically stage every file that is already tracked before doing the commit, letting you skip the `git add` part:
 

From 35636c0d6b2956a2696e650fac821409d09ae36e Mon Sep 17 00:00:00 2001
From: "Ammar M. Zerouk" <ammarzerouk@outlook.com>
Date: Sun, 7 Sep 2014 01:11:26 +0300
Subject: [PATCH 634/690] [ar] translating file editing, checking status,
 tracking new files, staging modified files, ignoring files

---
 ar/02-git-basics/01-chapter2.markdown | 61 +++++++++++++--------------
 1 file changed, 30 insertions(+), 31 deletions(-)

diff --git a/ar/02-git-basics/01-chapter2.markdown b/ar/02-git-basics/01-chapter2.markdown
index 0bea0227d..da77fdd39 100644
--- a/ar/02-git-basics/01-chapter2.markdown
+++ b/ar/02-git-basics/01-chapter2.markdown
@@ -1,4 +1,4 @@
-# مبادئ Git #
+# مبادئ Git #
 
 إذا كان هناك فصل واحد عليك قراءته لكي تبدأ بإستخدام Git، فعليك بهذا الفصل! يغطي هذا الفصل جميع الأوامر الأساسية التي عليك معرفتها لكي تتمكن من القيام بأغلب الأمور أثناء استخدامك لـ Git. في نهاية هذا الفصل يجب أن تكون قادراً على انشاء واعداد الـ repository لمشروعك وعلى تحديد الملفات التي ستتم متابعتها والتي ستترك، وعلى تهييئ التغييرات لعمل commit عليها. ستتعلم أيضاً كيف تعد Git لكي تتجاهل بعض أنواع الملفات، كيف تقوم بالتراجع عن الأخطاء التي سترتكبها بسرعة وبسهولة، كيف تتصفح تاريخ مشروعك وكيف تعرض التغيرات بين الـ commits، وكيف تنشر وتسحب (push & pull) التغيرات من الـ repositories البعيدة عنك.
 
@@ -40,27 +40,26 @@
 هناك عدد من البروتوكولات المختلفة التي يمكنك اسستعمالها لنقل المعلومات في git. المثال السابق يستعمل بروتوكول 'git://'، ولكن من الممكن أن تجد أيضاً استخداماً لـ 'http(s)://' أو 'user@server:/path.git'، والتي تستعمل بروتوكول SSH في النقل. في الفصل الرابع من الكتاب ستتعرف على الخيارات المتوفرة للتواصل مع الـ repository الخاصة بك وميزات ومساوئ كل منها.
 
 ## تسجيل التعديلات في الـ repository ##
+لديك repository أصلي ونسخة لتعمل عليها من ملفات المشروع. عليك أن تقوم ببعض التعديلات ثم تعمل commit لهذه التعديلات في repository الخاص بك في كل مرة يصل فيها المشروع إلى نقطة تود تسجيلها.
 
-You have a bona fide Git repository and a checkout or working copy of the files for that project. You need to make some changes and commit snapshots of those changes into your repository each time the project reaches a state you want to record.
+تذكر أنه كل ملف في مجلد العمل يمكن أن يكون في إحدى الحالتين فقط: مٌتَتَبّع tracked أو غير مٌتَتَبّع untracked. الملفات المٌتتبّعة هي ملفات كانت في أخر snapshot ويمكن إلغاء التعديلات عليها أو التعديل عليها أو وضعه في حالة staged (جاهز من أجل commit). الملفات غير المُتتبّعة هي كل الملفات الآخرى - أي ملف في مجلد العمل لم يكن موجوداً في آخر snapshot وليس معلماً بأنه staged. عندما تقوم باستنساخ repository جميع ملفاتك تكون بحالة متتبّعة tracked و غير معدلة unmodified لأنك قمت للتو بعمل check out ولم تقم بأي تعديل.
 
-Remember that each file in your working directory can be in one of two states: tracked or untracked. Tracked files are files that were in the last snapshot; they can be unmodified, modified, or staged. Untracked files are everything else - any files in your working directory that were not in your last snapshot and are not in your staging area.  When you first clone a repository, all of your files will be tracked and unmodified because you just checked them out and haven’t edited anything. 
-
-As you edit files, Git sees them as modified, because you’ve changed them since your last commit. You stage these modified files and then commit all your staged changes, and the cycle repeats. This lifecycle is illustrated in Figure 2-1.
+عندما تعدل الملفات، سيقوم git بتأشيرهم على أنهم modified، لأنك قمت بتغيرهم عن آخر commit. تقوم بعمل stage لهذه الملفات المعدلة ثم تقوم بعمل commit لجميع التغيرات في منطقة stage، وتتكرر العملية. يوضع الشكل 2-1 دورة العملية.
 
 Insert 18333fig0201.png 
-Figure 2-1. The lifecycle of the status of your files.
+الشكل 2-1. دورة حالة الملفات.
 
-### Checking the Status of Your Files ###
+### تفقد حالة ملفاتك ###
 
-The main tool you use to determine which files are in which state is the git status command. If you run this command directly after a clone, you should see something like this:
+باستخدام الأمر git status يمكننا معرفة حالة الملفات لدينا. إذا قمت بتشغيل هذا الأمر مباشرة بعد قيامك بعمل clone يجب أن ترى شيئاً يشبه التالي:
 
 	$ git status
 	# On branch master
 	nothing to commit, working directory clean
 
-This means you have a clean working directory—in other words, there are no tracked and modified files. Git also doesn’t see any untracked files, or they would be listed here. Finally, the command tells you which branch you’re on. For now, that is always master, which is the default; you won’t worry about it here. The next chapter will go over branches and references in detail.
+وهذا يعني أنه لديك مجلد عمل نظيف - بمعنى آخر، لايوجد أي ملفات معدلة أو ملفات غير مُتتبّعة. كما أنّ هذا الأمر يخبرك بأي فرع branch أنت تعمل. حالياً، دائماً هو master، وهو الافتراضي؛ في الفصل المقبل سنمر على الأفرع و المرجعيات references بالتفصيل.
 
-Let’s say you add a new file to your project, a simple README file. If the file didn’t exist before, and you run `git status`, you see your untracked file like so:
+لنقل بأنك قمت بإضافة ملف جديد على مشروعك، وليكن ملف README بسيط. إذا لم يكن الملف موجوداً مسبقاً، وقمت بتنفيذ الأمر `git status` سترى الملف غير مُتتبّعاً كما يلي:
 
 	$ vim README
 	$ git status
@@ -71,15 +70,15 @@ Let’s say you add a new file to your project, a simple README file. If the fil
 	#	README
 	nothing added to commit but untracked files present (use "git add" to track)
 
-You can see that your new README file is untracked, because it’s under the “Untracked files” heading in your status output. Untracked basically means that Git sees a file you didn’t have in the previous snapshot (commit); Git won’t start including it in your commit snapshots until you explicitly tell it to do so. It does this so you don’t accidentally begin including generated binary files or other files that you did not mean to include. You do want to start including README, so let’s start tracking the file.
+يمكنك ملاحظة أنّ ملفك الجديد README غير مُتتبّع، فهو تحت تبويب "untracked files" في خرج الأمر. ويعني ذلك أنّ git يرى ملفاً جديداً على commit السابقة؛ علماً أنّ git لن يقوم بإضافة هذا الملف إلى الملفات المتتبعة إلا إذا قمت بطلب ذلك بشكل مباشر، والهدف من ذلك من أجل حماية المشروع من الضم الخاطئ لملفات binary أو أي ملفات لا تود بإضافتها. إلاّ أنّك ترغب في إضافة README إلى الملفات المتتبّعة. وسنقوم بذلك حالاً.
 
-### Tracking New Files ###
+### تتبع الملفات الجديدة ###
 
-In order to begin tracking a new file, you use the command `git add`. To begin tracking the README file, you can run this:
+للقيام بتتبع ملف جديد عليه استخدام الأمر `git add` . مثلاً لنقم بتتبع الملف الجديد README:
 
 	$ git add README
 
-If you run your status command again, you can see that your README file is now tracked and staged:
+إذا قمنا بتنفيذ الأمر `git status` مرة أخرى سنلاحظ أن الملف README أصبح متتبعاً وجاهزاً staged للقيام بعملية commit:
 
 	$ git status
 	# On branch master
@@ -89,11 +88,11 @@ If you run your status command again, you can see that your README file is now t
 	#	new file:   README
 	#
 
-You can tell that it’s staged because it’s under the “Changes to be committed” heading. If you commit at this point, the version of the file at the time you ran git add is what will be in the historical snapshot. You may recall that when you ran git init earlier, you then ran git add (files) — that was to begin tracking files in your directory. The git add command takes a path name for either a file or a directory; if it’s a directory, the command adds all the files in that directory recursively.
+نستطيع معرفة بأن الملف staged من خلال ملاحظته تحت بند "changes to be comitted". إذا قمت بعمل commit في هذه اللحظة، سيقوم git بإضافة النسخة الحالية من الملف إلى snapshot. تذكر عندما قمنا بعمل git init سابقاً، ثم قمنا بإضافة الملفات عن طريق git add، كان ذلك للقيام ببدء تتبع الملفات في مجلد المشروع. يقبل الأمر git add مسار لملف أو لمجلد؛ فإذا كان المسار لمجلد سيقوم git بإضافة جميع الملفات والمجلدات ضمنه بشكل تعاودي recursively.
 
-### Staging Modified Files ###
+### تجهيز الملفات المعدلة ###
 
-Let’s change a file that was already tracked. If you change a previously tracked file called `benchmarks.rb` and then run your `status` command again, you get something that looks like this:
+لنقم بالتعديل على ملف قمنا بإضافته سابقاً. إذا قمنا مثلاً بالتعديل على ملف متتبع مسبقاً يدعى `benchmarks.rb`  وقمنا بتنفيذ الأمر git status، سيكون الخرج مشابهاً للخرج التالي:
 
 	$ git status
 	# On branch master
@@ -108,7 +107,7 @@ Let’s change a file that was already tracked. If you change a previously track
 	#	modified:   benchmarks.rb
 	#
 
-The benchmarks.rb file appears under a section named “Changes not staged for commit” — which means that a file that is tracked has been modified in the working directory but not yet staged. To stage it, you run the `git add` command (it’s a multipurpose command — you use it to begin tracking new files, to stage files, and to do other things like marking merge-conflicted files as resolved). Let’s run `git add` now to stage the benchmarks.rb file, and then run `git status` again:
+يظهر الملف benchmarks.rb تحت بند "changes not staged for commit" وهذا يعني أن الملف المُتتبّع قد خضع لعملية تعديل لكنه لم يخضع للتجهيز من أجل commit. للقيام بتجهيزه (أو تأشيره للإضافة إلى commit الجديد) يجب علينا تنفيذ الأمر `git add` (لاحظ بأنّه أمر متعدد الوظائف - نستطيع استخدامه لتتبع الملفات الجديدة، تجهيز الملفات من أجل commit، والقيام بأمور أخرى مثل حل الاعتراضات في حال القيام بدمج merge). لنقم بتنفيذ git add الآن لوضع benchmarks.rb بحالة staged، ومن ثم لنقم بتنفيذ الأمر git status لنرى ما الذي قد تغيّر:
 
 	$ git add benchmarks.rb
 	$ git status
@@ -120,7 +119,7 @@ The benchmarks.rb file appears under a section named “Changes not staged for c
 	#	modified:   benchmarks.rb
 	#
 
-Both files are staged and will go into your next commit. At this point, suppose you remember one little change that you want to make in benchmarks.rb before you commit it. You open it again and make that change, and you’re ready to commit. However, let’s run `git status` one more time:
+كلا الملفين الآن جاهز للإدخال بعملية commit المقبلة. في هذه النقطة، لنفرض أنك تود القيام بتعديل على ملف benchmarks.rb قبل القيام بعملية commit، ستقوم بفتح الملف والتعديل عليه وأنك جاهز للقيام بعملية commit. لكن قبل ذلك، دعنا نقوم بتنفيذ الأمر git status مرة إضافية:
 
 	$ vim benchmarks.rb 
 	$ git status
@@ -137,7 +136,7 @@ Both files are staged and will go into your next commit. At this point, suppose
 	#	modified:   benchmarks.rb
 	#
 
-What the heck? Now benchmarks.rb is listed as both staged and unstaged. How is that possible? It turns out that Git stages a file exactly as it is when you run the git add command. If you commit now, the version of benchmarks.rb as it was when you last ran the git add command is how it will go into the commit, not the version of the file as it looks in your working directory when you run git commit. If you modify a file after you run `git add`, you have to run `git add` again to stage the latest version of the file:
+ما الذي يحصل؟ كيف أصبح benchmarks.rb موجوداً تحت التبويبين staged و unstaged؟ لقد اتضح لنا أنّ git يقوم بتجهيز الملف على حالته عند قيامك بتنفيذ الأمر git add. إذا قمت بعمل commit الآن، ستكون نسخة benchmarks.rb كما كانت عند قيامك بتنفيذ الأمر git add وليس النسخة الجديدة التي حصلنا عليها بعد قيامنا بتعديل الملف. لذا إذا قمنا بتعديل ملف قبل قيامنا بتنفيذ git add، وقبل القيام بعملية commit، علينا تجهيز الملف مرة أخرى لعملية commit، وذلك بتنفيذ الأمر git add مرة جديدة:
 
 	$ git add benchmarks.rb
 	$ git status
@@ -149,26 +148,26 @@ What the heck? Now benchmarks.rb is listed as both staged and unstaged. How is t
 	#	modified:   benchmarks.rb
 	#
 
-### Ignoring Files ###
+### تجاهل الملفات ###
 
-Often, you’ll have a class of files that you don’t want Git to automatically add or even show you as being untracked. These are generally automatically generated files such as log files or files produced by your build system. In such cases, you can create a file listing patterns to match them named .gitignore.  Here is an example .gitignore file:
+غالباً ما تود من git تجاهل صنف من الملفات بحث لا يقوم بإضافتها تلقائياً أو لا يظهرها بأنّها غير متتبعة. تكون هذه الملفات عادة ملفات مولدة بشكل تلقائي مثل ملفات log و الملفات الوسيطة التي تولدها أدوات التطوير لديك. في مثل هذه الحالات/ يمكن إنشاء ملف .gitignore يحوي على أنماط لأسماء الملفات التي نرغب بتجاهلها. هذا مثال عمّا قد يحتويه ملف .gitignore:
 
 	$ cat .gitignore
 	*.[oa]
 	*~
 
-The first line tells Git to ignore any files ending in .o or .a — object and archive files that may be the product of building your code. The second line tells Git to ignore all files that end with a tilde (`~`), which is used by many text editors such as Emacs to mark temporary files. You may also include a log, tmp, or pid directory; automatically generated documentation; and so on. Setting up a .gitignore file before you get going is generally a good idea so you don’t accidentally commit files that you really don’t want in your Git repository.
+أول سطر يقوم بتوجيه git إلى تجاهل أي ملفات ذات لواحق من النوع o أو a - ملفات الكائنات وملفات الأرشيف وهي ملفات وسيطة تولدها أدوات بناء الكود عادة. السطر الثاني يوجه git إلى تجاهل أي ملفات تنتهي بالرمز (~) والتي تكون ملفات مؤقتة عادةً تستخدمها بعض برامج تحرير الكود. قد ترغب أيضاً بإضافة مجلدات log و tmp أو pid؛ أو حتى ملفات التوثيق تلقائية التوليد (من الكود عادة)، وغيرها. ينصح بإضافة ملف .gitignore في بداية إنشاء repository حتى نتجنب إضافة بعض الملفات عن طريق الخطأ وتلويث respository.
 
-The rules for the patterns you can put in the .gitignore file are as follows:
+قواعد الأنماط التي يمكن وضعها ضمن ملف .gitignore هي كالتالي:
 
-*	Blank lines or lines starting with # are ignored.
-*	Standard glob patterns work.
-*	You can end patterns with a forward slash (`/`) to specify a directory.
-*	You can negate a pattern by starting it with an exclamation point (`!`).
+*	الأسطر التي تبدأ بالرمز (#) يتم تجاهلها.
+*	أنماط glob القياسية تعمل.
+*	يمكن إنهاء النمط برمز (/) للدلالة على أنه يستهدف مجلداً.
+*	يمكن نفي نمط ما عن طريق وضع علامة التعجب (!) في بداية السطر قبل النمط.
 
-Glob patterns are like simplified regular expressions that shells use. An asterisk (`*`) matches zero or more characters; `[abc]` matches any character inside the brackets (in this case a, b, or c); a question mark (`?`) matches a single character; and brackets enclosing characters separated by a hyphen(`[0-9]`) matches any character between them (in this case 0 through 9) . 
+أنماط Glob عبارة عن نسخة مبسطة من Regular Expressions يتم استخدامها ضمن واجهة الأوامر shell. رمز النجمة (*) يطابق صفر-محرفاً أو أكثر. `[abc]` تطابق أي محارف ضمن الأقواس المربعة في هذه الحالة تكون a b c؛ علامة الاستفهام (?) تطابق محرفاً واحداً فقط؛ بينما تطابق الأقواس المربعة التي تحوي على محارف مفصولة بإشارة hyphen أي محرفاً يقع في المجال بين محرف البداية والنهاية - مثلا [0-9] يطابق محارف الأرقام بين 0 و 9 ضمناً.
 
-Here is another example .gitignore file:
+مثال عن ملف .gitignore:
 
 	# a comment – this is ignored
 	# no .a files
@@ -182,7 +181,7 @@ Here is another example .gitignore file:
 	# ignore doc/notes.txt, but not doc/server/arch.txt
 	doc/*.txt
 
-### Viewing Your Staged and Unstaged Changes ###
+### مشاهدة التغيّرات المجهّزة والتغيّرات غير المجهّزة ###
 
 If the `git status` command is too vague for you — you want to know exactly what you changed, not just which files were changed — you can use the `git diff` command. We’ll cover `git diff` in more detail later; but you’ll probably use it most often to answer these two questions: What have you changed but not yet staged? And what have you staged that you are about to commit? Although `git status` answers those questions very generally, `git diff` shows you the exact lines added and removed — the patch, as it were. 
 

From 5e9c6a0416d1c02876a07c8af351c3ecf5aba310 Mon Sep 17 00:00:00 2001
From: "Ammar M. Zerouk" <ammarzerouk@outlook.com>
Date: Tue, 23 Sep 2014 03:18:26 +0300
Subject: [PATCH 635/690] [ar] translating  and

---
 ar/02-git-basics/01-chapter2.markdown | 37 +++++++++++++--------------
 1 file changed, 18 insertions(+), 19 deletions(-)

diff --git a/ar/02-git-basics/01-chapter2.markdown b/ar/02-git-basics/01-chapter2.markdown
index da77fdd39..89e6b9ae2 100644
--- a/ar/02-git-basics/01-chapter2.markdown
+++ b/ar/02-git-basics/01-chapter2.markdown
@@ -183,9 +183,10 @@ Insert 18333fig0201.png
 
 ### مشاهدة التغيّرات المجهّزة والتغيّرات غير المجهّزة ###
 
-If the `git status` command is too vague for you — you want to know exactly what you changed, not just which files were changed — you can use the `git diff` command. We’ll cover `git diff` in more detail later; but you’ll probably use it most often to answer these two questions: What have you changed but not yet staged? And what have you staged that you are about to commit? Although `git status` answers those questions very generally, `git diff` shows you the exact lines added and removed — the patch, as it were. 
+إذا لم تكتف بالمعلومات التي يقدمها لك أمر `git status` يمكنك استخدام أمر `git diff`  للحصول على معلومات تفصيلية حول التغيرات التي طرأت على الملفات. سنقوم لاحقاً بالتعمق في هذا الأمر، لكن الآن سنكتفي بالإشارة إلى الاستخدامات الغالبة له؛ حيث أنك ستستخدمه غالباً للحصول على أجوبة على هذين السؤالين: ما الذي قمنا بالتعديل عليه ولم نجهزه بعد لعملية commit؟ ما الملفات التي أصبحت جاهزة للدخول في عملية commit المقبلة؟
+بالرغم من أنه يمكننا أن نحصل على هذه المعلومات باستخدام أمر `git status` إلا أنّ أمر `git diff` يوضح لنا التغيرات التي جرت على مستوى السطر والحرف - ما الذي قمنا بإضافته وما الذي أزلناه!
 
-Let’s say you edit and stage the README file again and then edit the benchmarks.rb file without staging it. If you run your `status` command, you once again see something like this:
+لنقل أنك قمت بالتعديل على ملف README مرة أخرى وأشرته للإضافة إلى عملية commit وقمت بالتعديل على ملف benchmarks.rb ولم تضفه إلى قائمة الملفات الجاهزة لعملية commit؛ إذا قمت بتنفيذ الأمر `status` ستشاهد مرة أخرى شيئاً من الشكل:
 
 	$ git status
 	# On branch master
@@ -200,7 +201,7 @@ Let’s say you edit and stage the README file again and then edit the benchmark
 	#	modified:   benchmarks.rb
 	#
 
-To see what you’ve changed but not yet staged, type `git diff` with no other arguments:
+لترى ما قمت بالتعديل عليه ولم تجهزه للإضافة نفذ الأمر `git diff` بدون إضافات:
 
 	$ git diff
 	diff --git a/benchmarks.rb b/benchmarks.rb
@@ -219,9 +220,9 @@ To see what you’ve changed but not yet staged, type `git diff` with no other a
 	           log = git.commits('master', 15)
 	           log.size
 
-That command compares what is in your working directory with what is in your staging area. The result tells you the changes you’ve made that you haven’t yet staged.
+يقوم هذا الأمر بعمل مقارنة بين الملفات ضمن مجلد العمل والملفات الموجودة في منطقة التعديلات المجهزة للإضافة staging area. وتخبرنا نتيجته بالتعديلات التي أجريناها ولم نقم بتجهيزها للإضافة إلى عملية commit المقبلة.
 
-If you want to see what you’ve staged that will go into your next commit, you can use `git diff –-cached`. (In Git versions 1.6.1 and later, you can also use `git diff –-staged`, which may be easier to remember.) This command compares your staged changes to your last commit:
+لمشاهدة الملفات ذات الحالة staged والتي ستدخل في عملية commit المقبلة، يمكن استخدام الأمر `git diff --cached` (بالنسبة للإصدارات 1.6.1 وما بعد من git يمكنك أيضاً استخدام الأمر `git diff --staged` )، كالتالي:
 
 	$ git diff --cached
 	diff --git a/README b/README
@@ -236,9 +237,9 @@ If you want to see what you’ve staged that will go into your next commit, you
 	+
 	+Grit is a Ruby library for extracting information from a Git repository
 
-It’s important to note that `git diff` by itself doesn’t show all changes made since your last commit — only changes that are still unstaged. This can be confusing, because if you’ve staged all of your changes, `git diff` will give you no output.
+من الجدير بالذكر أن أمر `git diff` لوحده لا يقوم بعرض جميع التعديلات التي تمت من آخر commit - فهو يقوم بعرض فقط التعديلات التي لم تؤشر على أنها staged. ويمكن أن يسبب ذلك بعض الإرباك، حيث أنك إذا قمت بإضافة جميع التعديلات إلى قائمة staged فلن يقوم بعرض أي شي في خرج تنفيذه.
 
-For another example, if you stage the benchmarks.rb file and then edit it, you can use `git diff` to see the changes in the file that are staged and the changes that are unstaged:
+كمثال أيضاً، إذا قمنا بإضافة benchmarks.rb إلى قائمة staged ومن ثم قمنا بالتعديل عليه من جديد، يمكننا استخدام أمر `git diff` للحصول على لائحة بالتغييرات التي حصلت ولم تضف إلى قائمة staged كالتالي:
 
 	$ git add benchmarks.rb
 	$ echo '# test line' >> benchmarks.rb
@@ -254,7 +255,6 @@ For another example, if you stage the benchmarks.rb file and then edit it, you c
 	#	modified:   benchmarks.rb
 	#
 
-Now you can use `git diff` to see what is still unstaged
 
 	$ git diff 
 	diff --git a/benchmarks.rb b/benchmarks.rb
@@ -267,7 +267,7 @@ Now you can use `git diff` to see what is still unstaged
 	 ##pp Grit::GitRuby.cache_client.stats 
 	+# test line
 
-and `git diff --cached` to see what you’ve staged so far:
+وباستخدام `git diff --cached` نتمكن من رؤية ما تم تجهيزه للإضافة إلى عملية commit القادمة:
 
 	$ git diff --cached
 	diff --git a/benchmarks.rb b/benchmarks.rb
@@ -286,16 +286,15 @@ and `git diff --cached` to see what you’ve staged so far:
 	          log = git.commits('master', 15)
 	          log.size
 
-### Committing Your Changes ###
+### القيام بعملية (اعتماد) commit للتغيّرات ###
 
-Now that your staging area is set up the way you want it, you can commit your changes. Remember that anything that is still unstaged — any files you have created or modified that you haven’t run `git add` on since you edited them — won’t go into this commit. They will stay as modified files on your disk.
-In this case, the last time you ran `git status`, you saw that everything was staged, so you’re ready to commit your changes. The simplest way to commit is to type `git commit`:
+بعد اكمال تجهيز الملفات التي ترغب بإضافتها إلى النسخة snapshot الجديدة، يمكنك تنفيذ أمر commit ليتم اعتماد التعديلات التي أجريتها في سجل git. تذكر أنّ أي ملف لم يتم تجهيزه - سواء لم تقم بإضافته باستخدام الأمر git add بعد إنشاءه أو التعديل عليه - لن يدخل في هذه الإعتمادية، وستبقى على أنها ملفات تم تعديلها في مجلد العمل. أبسط طريقة لاعتماد التعديلات هي القيام بأمر `git commit` كالتالي:
 
 	$ git commit
 
-Doing so launches your editor of choice. (This is set by your shell’s `$EDITOR` environment variable — usually vim or emacs, although you can configure it with whatever you want using the `git config --global core.editor` command as you saw in Chapter 1). 
+تنفيذ هذا الأمر سيطلب منا إدخال رسالة عملية commit - عادة ما يتم فتح محرر النصوص المشار إليه بمتغير البيئة `$EDITOR`. يمكنك تهيئته عن طريق الأمر `git config --global core.editor` كما شاهدنا في الفصل الأول.
 
-The editor displays the following text (this example is a Vim screen):
+يقوم محرر النصوص بعرض هذه الشاشة (مثالنا باستخدام VIM):
 
 	# Please enter the commit message for your changes. Lines starting
 	# with '#' will be ignored, and an empty message aborts the commit.
@@ -310,20 +309,20 @@ The editor displays the following text (this example is a Vim screen):
 	~
 	".git/COMMIT_EDITMSG" 10L, 283C
 
-You can see that the default commit message contains the latest output of the `git status` command commented out and one empty line on top. You can remove these comments and type your commit message, or you can leave them there to help you remember what you’re committing. (For an even more explicit reminder of what you’ve modified, you can pass the `-v` option to `git commit`. Doing so also puts the diff of your change in the editor so you can see exactly what you did.) When you exit the editor, Git creates your commit with that commit message (with the comments and diff stripped out).
+يمكنك ملاحظة أن رسالة عملية commit تحوي على خرج آخر عملية `git status` على شكل تعليقات بالإضافة إلى سطر فارغ في بداية الملف. يمكنك إزالة هذه التعليقات، أو يمكنك تركها لمساعدتك بتذكر ما قمت باعتماد تعديلاته. يمكنك الحصول على معلومات أكثر تفصلياً إذا قمت بتمرير الخيار `-v` إلى الأمر `git commit`. حيث يقوم ذلك بإضافة خرج أمر `git diff` إلى رسالة commit على شكل تعليقات أيضاً. عند إغلاق المحرر يقوم git بإنشاء commit ويتجاهل التعليقات.
 
-Alternatively, you can type your commit message inline with the `commit` command by specifying it after a -m flag, like this:
+علماً أنّه يمكنك كتابة رسالة الاعتمادية مباشرة من خلال تمرير الخيار `-m` إلى الأمر `git commit` على الشكل التالي:
 
 	$ git commit -m "Story 182: Fix benchmarks for speed"
 	[master]: created 463dc4f: "Fix benchmarks for speed"
 	 2 files changed, 3 insertions(+), 0 deletions(-)
 	 create mode 100644 README
 
-Now you’ve created your first commit! You can see that the commit has given you some output about itself: which branch you committed to (master), what SHA-1 checksum the commit has (`463dc4f`), how many files were changed, and statistics about lines added and removed in the commit.
+مبروك، لقد قمت بعمل أول commit لك! يعطيك خرج العملية معلومات عنها: في أي فرع branch تم الإعتماد (هنا master)، ما قيمة هاش SHA-1 الخاصة بالعملية ( هنا `463dc4f`)، عدد الملفات التي تغيّرت، بالإضافة إلى إحصاءات حول الأسطر التي أضيفت وأزيلت في هذه العملية.
 
-Remember that the commit records the snapshot you set up in your staging area. Anything you didn’t stage is still sitting there modified; you can do another commit to add it to your history. Every time you perform a commit, you’re recording a snapshot of your project that you can revert to or compare to later.
+تذكر أنّ عملية commit تأخذ صورة عن الملفات في قائمة staged. أي شيء لم تقم بإضافته إلى هذه القائمة ما زال في مجلد العمل بحالة "معدل" modified؛ يمكنك القيام بإضافتهم من خلال عملية commit جديدة إلى التأريخ في git. نستنتج أنّه في كل عملية commit يقوم git بأخذ "صورة" snapshot عن المشروع يمكننا العودة لها لاحقاً أو مقارنتها أو غير ذلك..
 
-### Skipping the Staging Area ###
+### تجاوز منطقة التجهيز Staging Area ###
 
 Although it can be amazingly useful for crafting commits exactly how you want them, the staging area is sometimes a bit more complex than you need in your workflow. If you want to skip the staging area, Git provides a simple shortcut. Providing the `-a` option to the `git commit` command makes Git automatically stage every file that is already tracked before doing the commit, letting you skip the `git add` part:
 

From 6ec6c76a4308fd1941f03c39f3145b2e38262086 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Jean-No=C3=ABl=20Avila?= <jn.avila@free.fr>
Date: Tue, 23 Sep 2014 22:07:43 +0200
Subject: [PATCH 636/690] [fr] fix mistranslation

---
 fr/03-git-branching/01-chapter3.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fr/03-git-branching/01-chapter3.markdown b/fr/03-git-branching/01-chapter3.markdown
index 2f6370579..c6c7f1246 100644
--- a/fr/03-git-branching/01-chapter3.markdown
+++ b/fr/03-git-branching/01-chapter3.markdown
@@ -584,7 +584,7 @@ Cette commande vous fournit une branche locale modifiable basée sur l'état act
 L'extraction d'une branche locale à partir d'une branche distante crée automatiquement ce qu'on appelle une _branche de suivi_.
 Les branches de suivi sont des branches locales qui sont en relation directe avec une branche distante.
 Si vous vous trouvez sur une branche de suivi et que vous tapez `git push`, Git sélectionne automatiquement le serveur vers lequel pousser vos modifications.
-De même, `git pull` sur une de ces branches récupère toutes les références distantes et les fusionne automatiquement dans la branche distante correspondante.
+De même, `git pull` sur une de ces branches récupère toutes les références distantes et fusionne automatiquement la branche distante correspondante dans la branche actuelle.
 
 Lorsque vous clonez un dépôt, il crée généralement automatiquement une branche `master` qui suit `origin/master`.
 C'est pourquoi les commandes `git push` et `git pull` fonctionnent directement sans plus de paramétrage.

From 43a54d1a4a8e0bf73f54b65db7867883e24b0b87 Mon Sep 17 00:00:00 2001
From: "Ammar M. Zerouk" <ammarzerouk@outlook.com>
Date: Tue, 23 Sep 2014 23:31:40 +0300
Subject: [PATCH 637/690] [ar] translating until section 'Viewing the Commit
 History', fixing mixxing '`'

---
 ar/02-git-basics/01-chapter2.markdown | 119 +++++++++++++-------------
 1 file changed, 59 insertions(+), 60 deletions(-)

diff --git a/ar/02-git-basics/01-chapter2.markdown b/ar/02-git-basics/01-chapter2.markdown
index 89e6b9ae2..8cbf79f6b 100644
--- a/ar/02-git-basics/01-chapter2.markdown
+++ b/ar/02-git-basics/01-chapter2.markdown
@@ -165,7 +165,7 @@ Insert 18333fig0201.png
 *	يمكن إنهاء النمط برمز (/) للدلالة على أنه يستهدف مجلداً.
 *	يمكن نفي نمط ما عن طريق وضع علامة التعجب (!) في بداية السطر قبل النمط.
 
-أنماط Glob عبارة عن نسخة مبسطة من Regular Expressions يتم استخدامها ضمن واجهة الأوامر shell. رمز النجمة (*) يطابق صفر-محرفاً أو أكثر. `[abc]` تطابق أي محارف ضمن الأقواس المربعة في هذه الحالة تكون a b c؛ علامة الاستفهام (?) تطابق محرفاً واحداً فقط؛ بينما تطابق الأقواس المربعة التي تحوي على محارف مفصولة بإشارة hyphen أي محرفاً يقع في المجال بين محرف البداية والنهاية - مثلا [0-9] يطابق محارف الأرقام بين 0 و 9 ضمناً.
+أنماط Glob عبارة عن نسخة مبسطة من Regular Expressions يتم استخدامها ضمن واجهة الأوامر shell. رمز النجمة (`*`) يطابق صفر-محرفاً أو أكثر. `[abc]` تطابق أي محارف ضمن الأقواس المربعة في هذه الحالة تكون a b c؛ علامة الاستفهام (?) تطابق محرفاً واحداً فقط؛ بينما تطابق الأقواس المربعة التي تحوي على محارف مفصولة بإشارة hyphen أي محرفاً يقع في المجال بين محرف البداية والنهاية - مثلا [0-9] يطابق محارف الأرقام بين 0 و 9 ضمناً.
 
 مثال عن ملف .gitignore:
 
@@ -324,7 +324,7 @@ Insert 18333fig0201.png
 
 ### تجاوز منطقة التجهيز Staging Area ###
 
-Although it can be amazingly useful for crafting commits exactly how you want them, the staging area is sometimes a bit more complex than you need in your workflow. If you want to skip the staging area, Git provides a simple shortcut. Providing the `-a` option to the `git commit` command makes Git automatically stage every file that is already tracked before doing the commit, letting you skip the `git add` part:
+منطقة التجهيز تكون أحياناً معقدة أكثر مما تحتاج في عملك إلا أنّها مفيدة لعمل commits تماماً كما تودهم أن يكونوا. إذا أردت تجاوز منطقة التجهيز، يوفر git اختصاراً بسيطاً لذلك. باستخدام الأمر `git commit -a` يقوم git بإضافة الملفات المتتبعة إلى منطقة التجهيز بشكل تلقائي، كأنك قمت بعمل `git add`:
 
 	$ git status
 	# On branch master
@@ -337,13 +337,13 @@ Although it can be amazingly useful for crafting commits exactly how you want th
 	[master 83e38c7] added new benchmarks
 	 1 files changed, 5 insertions(+), 0 deletions(-)
 
-Notice how you don’t have to run `git add` on the benchmarks.rb file in this case before you commit.
+لاحظ بأنك لاتحتاج إلى تنفيذ الأمر `git add` على ملف benchmark.rb قبل القيام بعملية commit.
 
-### Removing Files ###
+### إزالة الملفات ###
 
-To remove a file from Git, you have to remove it from your tracked files (more accurately, remove it from your staging area) and then commit. The `git rm` command does that and also removes the file from your working directory so you don’t see it as an untracked file next time around.
+لحذف ملف من git، يجب عليك إزالته من قائمة الملفات المتتبعة (وبشكل أدق، إزالته من منطقة التجهيز) ومن ثم القيام بعملية commit. الأمر `git rm` يقوم بعمل ذلك كما يقوم بحذف الملف من مجلد العمل الخاص بك لذا لن تراه بعد الآن في قائمة الملفات غير المتتبعة في المرة المقبلة.
 
-If you simply remove the file from your working directory, it shows up under the “Changes not staged for commit” (that is, _unstaged_) area of your `git status` output:
+إذا قمت بإزالة الملف من مجلد العمل، يظهر تحت بند "تعديلات غير مجهزة للاعتماد" (أي _unstaged_) من خرج الأمر `git status`:
 
 	$ rm grit.gemspec
 	$ git status
@@ -355,7 +355,7 @@ If you simply remove the file from your working directory, it shows up under the
 	#       deleted:    grit.gemspec
 	#
 
-Then, if you run `git rm`, it stages the file’s removal:
+فإذا قمت بتنفيذ أمر `git rm` يقوم بتجهيز عملية الحذف ليتم اعتمادها:
 
 	$ git rm grit.gemspec
 	rm 'grit.gemspec'
@@ -368,31 +368,31 @@ Then, if you run `git rm`, it stages the file’s removal:
 	#       deleted:    grit.gemspec
 	#
 
-The next time you commit, the file will be gone and no longer tracked. If you modified the file and added it to the index already, you must force the removal with the `-f` option. This is a safety feature to prevent accidental removal of data that hasn’t yet been recorded in a snapshot and that can’t be recovered from Git.
+وفي المرة المقبلة التي ستقوم فيها بعمل commit، سيتم إزالة الملف من قائمة التتبع. إذا قمت مسبقاً بتعديل الملف وإضفته إلى الفهرس، يجب عليه تنفيذ عملية الحذف قسرياً وذلك بإضافة الخيار `-f`. يتم اتباع هذه الطريقة بغية حماية البيانات من أية عمليات حذف "عرضية" لملفات لم يتم تسجيلها ضمن git ولايمكن استعادتها بعد ذلك.
 
-Another useful thing you may want to do is to keep the file in your working tree but remove it from your staging area. In other words, you may want to keep the file on your hard drive but not have Git track it anymore. This is particularly useful if you forgot to add something to your `.gitignore` file and accidentally added it, like a large log file or a bunch of `.a` compiled files. To do this, use the `--cached` option:
+أما إذا أردت إزالة الملف من منطقة التجهيز مع الحفاظ عليه في مجلد العمل (أي إزالته من تتبع git مع بقاءه على وسيطة التخزين) - وهو شيء مفيد إذا قمت بنسيان إضافة شيء ما إلى ملف `.gitignore` وأضفته عن طريق الخطأ ؛ كملف log كبير مثلاً - استخدم الخيار `--cached` مع الأمر `git rm` كالتالي:
 
 	$ git rm --cached readme.txt
 
-You can pass files, directories, and file-glob patterns to the `git rm` command. That means you can do things such as
+يمكنك تمرير أسماء ملفات، مجلدات، وأنماط glob للأمر `git rm`. وهذا يعني بأنه يمكننا عمل أشياء كالتالي:
 
 	$ git rm log/\*.log
 
-Note the backslash (`\`) in front of the `*`. This is necessary because Git does its own filename expansion in addition to your shell’s filename expansion. This command removes all files that have the `.log` extension in the `log/` directory. Or, you can do something like this:
+لاحظ الشرطة العكسية (`\`) قبل رمز النجمة `*`. إنّها ضرورية لأن git يقوم بعمل توسعة الأسماء الخاصة به بالإضافة إلى التوسعة الخاصة بسطر الأوامر. هذا الأمر يقوم بحذف كافة الملفات التي تملك اللاحقة `.log` في مجلد `/log`. أو يمكنك عمل شيء كالتالي:
 
 	$ git rm \*~
 
-This command removes all files that end with `~`.
+وهذا الأمر يقوم بحذف كافة الملفات المنتهية بالمحرف `~`.
 
-### Moving Files ###
+### نقل الملفات ###
 
-Unlike many other VCS systems, Git doesn’t explicitly track file movement. If you rename a file in Git, no metadata is stored in Git that tells it you renamed the file. However, Git is pretty smart about figuring that out after the fact — we’ll deal with detecting file movement a bit later.
+على خلاف أغلب أنظمة إدارة الإصدارات VCS الأخرى، لا يقوم git بتعقب حركة الملفات بشكل صريح. إذا قمت بإعادة تسمية ملف ضمن git، لايتم تسجيل أي بيانات وصفية metadata في git تقوم بأنك قمت بإعادة تسمية الملف. لكن، git ذكي جداً في استعياب ذلك - وسنقوم بمناقشة الأمر بعد قليل.
 
-Thus it’s a bit confusing that Git has a `mv` command. If you want to rename a file in Git, you can run something like
+إذا أردت القيام بإعادة تسمية ملف يمكنك استخدام أمر `mv` في git كالتالي:
 
 	$ git mv file_from file_to
 
-and it works fine. In fact, if you run something like this and look at the status, you’ll see that Git considers it a renamed file:
+إذا قمنا بتنفيذ الأمر والنظر إلى خرج أمر `git status`:
 
 	$ git mv README.txt README
 	$ git status
@@ -405,23 +405,23 @@ and it works fine. In fact, if you run something like this and look at the statu
 	#       renamed:    README.txt -> README
 	#
 
-However, this is equivalent to running something like this:
+وهو مكافئ للقيام بتنفيذ الأوامر التالي على التسلسل:
 
 	$ mv README.txt README
 	$ git rm README.txt
 	$ git add README
 
-Git figures out that it’s a rename implicitly, so it doesn’t matter if you rename a file that way or with the `mv` command. The only real difference is that `mv` is one command instead of three — it’s a convenience function. More important, you can use any tool you like to rename a file, and address the add/rm later, before you commit.
+يدرك git بأنك قمت بعملية إعادة تسمية، لذا فالإختلاف الوحيد بين الطريقتين هو أنّ `git mv` عبارة عن أمر واحد، وليس ثلاثة أوامر. يمكن الاستفادة من هذه الخاصة باستخدام أية أدوات للقيام بعمليات إعادة التسمية، واستخدام add/rm قبل القيام بعملية commit.
 
-## Viewing the Commit History ##
+## مراجعة تأريخ عمليات commit ##
 
-After you have created several commits, or if you have cloned a repository with an existing commit history, you’ll probably want to look back to see what has happened. The most basic and powerful tool to do this is the `git log` command.
+بعد قيامك بعدد من عمليات الاعتماد commit، أو استنساخ repository بسجل تأريخ، ربما ستود إلقاء نظرة على ما جرى. أبسط وأقوى أداة لعمل ذلك هي الأمر `git log`.
 
-These examples use a very simple project called simplegit that I often use for demonstrations. To get the project, run 
+هذه الأمثلة تستخدم مشروع بسيط جداً يدعى simplegit أقوم باستخدامه في عمليات العرض بأغلب الأحيان. للحصول على المشروع قم باستنساخه عن موقع github كالتالي:
 
 	git clone git://github.com/schacon/simplegit-progit.git
 
-When you run `git log` in this project, you should get output that looks something like this:
+عندما تقوم بعمل `git log` ضمن المشروع، سيظهر لديك خرج مشابه للتالي:
 
 	$ git log
 	commit ca82a6dff817ec66f44342007202690a93763949
@@ -442,11 +442,11 @@ When you run `git log` in this project, you should get output that looks somethi
 
 	    first commit
 
-By default, with no arguments, `git log` lists the commits made in that repository in reverse chronological order. That is, the most recent commits show up first. As you can see, this command lists each commit with its SHA-1 checksum, the author’s name and e-mail, the date written, and the commit message.
+بتنفيذ الأمر بدون بارمترات، يقوم git بعرض عمليات commit في repository بترتيب زمني معكوس - من الأحدث إلى الأقدم. كما يقوم بعرض بجانب كل commit هاش SHA-1 checksum الخاص بها، اسم وبريد الكاتب الإلكتروني، تاريخ الاعتماد، ورسالة الاعتماد.
 
-A huge number and variety of options to the `git log` command are available to show you exactly what you’re looking for. Here, we’ll show you some of the most-used options.
+يمكن إرفاق الأمر `git log` بعدد كبير من الخيارات للحصول على المعلومات التي نريدها بالضبط.. تجد في الأسفل مثالاً عن أكثر الخيارات استخداماً.
 
-One of the more helpful options is `-p`, which shows the diff introduced in each commit. You can also use `-2`, which limits the output to only the last two entries:
+أحد أهم الخيارات هو `-p`، والذي يقوم بإظهار الفوارق المستحدثة بين عمليات commit المختلفة. يمكن أيضاً استخدام الخيار `-2` ليحد خرج النتيجة إلى آخر عمليتين:
 
 	$ git log –p -2
 	commit ca82a6dff817ec66f44342007202690a93763949
@@ -486,8 +486,7 @@ One of the more helpful options is `-p`, which shows the diff introduced in each
 	-end
 	\ No newline at end of file
 
-This option displays the same information but with a diff directly following each entry. This is very helpful for code review or to quickly browse what happened during a series of commits that a collaborator has added.
-You can also use a series of summarizing options with `git log`. For example, if you want to see some abbreviated stats for each commit, you can use the `--stat` option:
+هذا الخيار يعرض نفس المعلومات بالإضافة خرج diff بعده مباشرة. فهو مهم جداً من أجل مراجعة الكود واستعراض ما الذي تغير بشكل سريع ضمن سلسلة من عمليات commit. يمكنك أيضاً استخدام خيارات للتلخيص مع أمر `git log`. على سبيل المثال، إذا أردت رؤية بعض الإحصاءات المختصرة لكل commit، يمكنك استخدام الخيار `stat`:
 
 	$ git log --stat 
 	commit ca82a6dff817ec66f44342007202690a93763949
@@ -519,43 +518,43 @@ You can also use a series of summarizing options with `git log`. For example, if
 	 lib/simplegit.rb |   25 +++++++++++++++++++++++++
 	 3 files changed, 54 insertions(+), 0 deletions(-)
 
-As you can see, the `--stat` option prints below each commit entry a list of modified files, how many files were changed, and how many lines in those files were added and removed. It also puts a summary of the information at the end.
-Another really useful option is `--pretty`. This option changes the log output to formats other than the default. A few prebuilt options are available for you to use. The oneline option prints each commit on a single line, which is useful if you’re looking at a lot of commits. In addition, the `short`, `full`, and `fuller` options show the output in roughly the same format but with less or more information, respectively:
+كما ترى باستخدام الخيار `--stat` يتم عرض قائمة من الملفات المعدلة، عدد الملفات التي تغيرت، وعدد الأسطر التي أضيفت أو أزيلت. كما يضع ملخصاً للمعلومات في النهاية.
+يوجد خيار مفيد آخر وهو `--pretty`. هذا الخيار يغير خرج السل إلى صيغ غير الافتراضية. يوجد بعضها مركب مسبقاً. مثلاً `oneline` يقوم بطباعة كل commit على سطر لوحدها، وهذا أمر مفيد في حال كنت تنظر إلى العديد من عمليات commit. بالإضافة إلى `short`، `full` و `fuller` والتي تعرض خرجاً تقريباً بنفس الصيغة مع معلومات أكثر أو أقل:
 
 	$ git log --pretty=oneline
 	ca82a6dff817ec66f44342007202690a93763949 changed the version number
 	085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7 removed unnecessary test code
 	a11bef06a3f659402fe7563abf99ad00de2209e6 first commit
 
-The most interesting option is `format`, which allows you to specify your own log output format. This is especially useful when you’re generating output for machine parsing — because you specify the format explicitly, you know it won’t change with updates to Git:
+أكثر الخيارات أهمية هو `format`، والذي يسمح لك بتحديد صيغة الخرج بشكل صريح بما يتناسب مع إعرابها آلياً - حيث أنك تعرف أنّه لن يتغير عند التحديث إلى git:
 
 	$ git log --pretty=format:"%h - %an, %ar : %s"
 	ca82a6d - Scott Chacon, 11 months ago : changed the version number
 	085bb3b - Scott Chacon, 11 months ago : removed unnecessary test code
 	a11bef0 - Scott Chacon, 11 months ago : first commit
 
-Table 2-1 lists some of the more useful options that format takes.
-
-	Option	Description of Output
-	%H	Commit hash
-	%h	Abbreviated commit hash
-	%T	Tree hash
-	%t	Abbreviated tree hash
-	%P	Parent hashes
-	%p	Abbreviated parent hashes
-	%an	Author name
-	%ae	Author e-mail
-	%ad	Author date (format respects the –date= option)
-	%ar	Author date, relative
-	%cn	Committer name
-	%ce	Committer email
-	%cd	Committer date
-	%cr	Committer date, relative
-	%s	Subject
-
-You may be wondering what the difference is between _author_ and _committer_. The author is the person who originally wrote the work, whereas the committer is the person who last applied the work. So, if you send in a patch to a project and one of the core members applies the patch, both of you get credit — you as the author and the core member as the committer. We’ll cover this distinction a bit more in Chapter 5.
-
-The oneline and format options are particularly useful with another `log` option called `--graph`. This option adds a nice little ASCII graph showing your branch and merge history, which we can see our copy of the Grit project repository:
+الجدول 2-1 يعرض بعض الخيارات المفيدة التي يمكن إضافتها إلى الصيغة.
+
+	الخيار	وصف الخرج
+	%H	Commit هاش
+	%h	الهاش الاعتمادي المختصر
+	%T	هاش الشجرة
+	%t	هاش الشجرة المختصر
+	%P	هاشات الوالد
+	%p	هاشات الوالد المختصرة
+	%an	اسم الكاتب
+	%ae	بريد الكاتب الإلكتروني
+	%ad	تاريخ الكاتب (يراعي الصيغة –date= option)
+	%ar	تاريخ الكاتب - نسبياً
+	%cn	اسم منفذ الاعتماد
+	%ce	بريد منفذ الاعتماد الإلكتروني
+	%cd	تاريخ منفذ الاعتماد
+	%cr	تاريخ منفذ الاعتماد - نسبياً
+	%s	العنوان
+
+قد تتسائل عن الاختلاف بين _الكاتب_ AUTHOR و _منفذ الاعتماد_ COMMITTER. الكاتب هو الشخص الذي كتب العمل بداية، بينما منفذ الاعتماد هو آخر شخص طبق العمل. لذا، إذا أرسلت باتشاً إلى مشروع وأحد المطورين الرئيسين قام بتطبيق الباتش، تأخذان كلاكما الاعتمادية - أنت ككاتب وهو كمنفذ اعتماد.
+
+وتكون هذه الخيارات مفيدة أكثر بالترافق مع الخيار `--graph`. حيث يضيف هذا الأمر غراف ASCII بسيط يوضح تأريخ الأفرع و الدمج، لاحظ التالي:
 
 	$ git log --pretty=format:"%h %s" --graph
 	* 2d3acf9 ignore errors from SIGCHLD on trap
@@ -569,17 +568,17 @@ The oneline and format options are particularly useful with another `log` option
 	* d6016bc require time for xmlschema
 	*  11d191e Merge branch 'defunkt' into local
 
-Those are only some simple output-formatting options to `git log` — there are many more. Table 2-2 lists the options we’ve covered so far and some other common formatting options that may be useful, along with how they change the output of the log command.
+يوجد مجموعة من الخيارات البسيطة مع أمر `git log`. يوضح الجدول 2-2 قائمة من الخيارات التي قمنا بتغطيتها حتى الآن وبعض صيغ التنسيق الشائعة والتي قد تكون مفيدة، وبجانبها شرح مبسط عن التغيير الذي تجريه على الخرج.
 
-	Option	Description
-	-p	Show the patch introduced with each commit.
-	--stat	Show statistics for files modified in each commit.
+	الخيار	الوصف
+	-p	يظهر الباتش المدخل مع كل عملية commit.
+	--stat	يظهر إحصاءات حول التعديلات التي حصلت على الملفات مع كل عملية commit.
 	--shortstat	Display only the changed/insertions/deletions line from the --stat command.
-	--name-only	Show the list of files modified after the commit information.
-	--name-status	Show the list of files affected with added/modified/deleted information as well.
-	--abbrev-commit	Show only the first few characters of the SHA-1 checksum instead of all 40.
+	--name-only	يظهر قائمة الملفات المعدلة.
+	--name-status	يظهر قائمة الملفات المعدلة عن طريق الإضافة والحذف وغير ذلك.
+	--abbrev-commit	يظهر أول مجموعة من هاش SHA-1 بدلاً عن كامل الأحرف 40.
 	--relative-date	Display the date in a relative format (for example, “2 weeks ago”) instead of using the full date format.
-	--graph	Display an ASCII graph of the branch and merge history beside the log output.
+	--graph	عرض غراف ASCII مع الخرج يظهر عمليات التفريع و الدمج.
 	--pretty	Show commits in an alternate format. Options include oneline, short, full, fuller, and format (where you specify your own format).
 
 ### Limiting Log Output ###

From da580c9c661c27dd44f7ac350b35e176052cab22 Mon Sep 17 00:00:00 2001
From: "Ammar M. Zerouk" <ammarzerouk@outlook.com>
Date: Sun, 7 Sep 2014 01:11:26 +0300
Subject: [PATCH 638/690] [ar] translating file editing, checking status,
 tracking new files, staging modified files, ignoring files

---
 ar/02-git-basics/01-chapter2.markdown | 61 +++++++++++++--------------
 1 file changed, 30 insertions(+), 31 deletions(-)

diff --git a/ar/02-git-basics/01-chapter2.markdown b/ar/02-git-basics/01-chapter2.markdown
index 0bea0227d..da77fdd39 100644
--- a/ar/02-git-basics/01-chapter2.markdown
+++ b/ar/02-git-basics/01-chapter2.markdown
@@ -1,4 +1,4 @@
-# مبادئ Git #
+# مبادئ Git #
 
 إذا كان هناك فصل واحد عليك قراءته لكي تبدأ بإستخدام Git، فعليك بهذا الفصل! يغطي هذا الفصل جميع الأوامر الأساسية التي عليك معرفتها لكي تتمكن من القيام بأغلب الأمور أثناء استخدامك لـ Git. في نهاية هذا الفصل يجب أن تكون قادراً على انشاء واعداد الـ repository لمشروعك وعلى تحديد الملفات التي ستتم متابعتها والتي ستترك، وعلى تهييئ التغييرات لعمل commit عليها. ستتعلم أيضاً كيف تعد Git لكي تتجاهل بعض أنواع الملفات، كيف تقوم بالتراجع عن الأخطاء التي سترتكبها بسرعة وبسهولة، كيف تتصفح تاريخ مشروعك وكيف تعرض التغيرات بين الـ commits، وكيف تنشر وتسحب (push & pull) التغيرات من الـ repositories البعيدة عنك.
 
@@ -40,27 +40,26 @@
 هناك عدد من البروتوكولات المختلفة التي يمكنك اسستعمالها لنقل المعلومات في git. المثال السابق يستعمل بروتوكول 'git://'، ولكن من الممكن أن تجد أيضاً استخداماً لـ 'http(s)://' أو 'user@server:/path.git'، والتي تستعمل بروتوكول SSH في النقل. في الفصل الرابع من الكتاب ستتعرف على الخيارات المتوفرة للتواصل مع الـ repository الخاصة بك وميزات ومساوئ كل منها.
 
 ## تسجيل التعديلات في الـ repository ##
+لديك repository أصلي ونسخة لتعمل عليها من ملفات المشروع. عليك أن تقوم ببعض التعديلات ثم تعمل commit لهذه التعديلات في repository الخاص بك في كل مرة يصل فيها المشروع إلى نقطة تود تسجيلها.
 
-You have a bona fide Git repository and a checkout or working copy of the files for that project. You need to make some changes and commit snapshots of those changes into your repository each time the project reaches a state you want to record.
+تذكر أنه كل ملف في مجلد العمل يمكن أن يكون في إحدى الحالتين فقط: مٌتَتَبّع tracked أو غير مٌتَتَبّع untracked. الملفات المٌتتبّعة هي ملفات كانت في أخر snapshot ويمكن إلغاء التعديلات عليها أو التعديل عليها أو وضعه في حالة staged (جاهز من أجل commit). الملفات غير المُتتبّعة هي كل الملفات الآخرى - أي ملف في مجلد العمل لم يكن موجوداً في آخر snapshot وليس معلماً بأنه staged. عندما تقوم باستنساخ repository جميع ملفاتك تكون بحالة متتبّعة tracked و غير معدلة unmodified لأنك قمت للتو بعمل check out ولم تقم بأي تعديل.
 
-Remember that each file in your working directory can be in one of two states: tracked or untracked. Tracked files are files that were in the last snapshot; they can be unmodified, modified, or staged. Untracked files are everything else - any files in your working directory that were not in your last snapshot and are not in your staging area.  When you first clone a repository, all of your files will be tracked and unmodified because you just checked them out and haven’t edited anything. 
-
-As you edit files, Git sees them as modified, because you’ve changed them since your last commit. You stage these modified files and then commit all your staged changes, and the cycle repeats. This lifecycle is illustrated in Figure 2-1.
+عندما تعدل الملفات، سيقوم git بتأشيرهم على أنهم modified، لأنك قمت بتغيرهم عن آخر commit. تقوم بعمل stage لهذه الملفات المعدلة ثم تقوم بعمل commit لجميع التغيرات في منطقة stage، وتتكرر العملية. يوضع الشكل 2-1 دورة العملية.
 
 Insert 18333fig0201.png 
-Figure 2-1. The lifecycle of the status of your files.
+الشكل 2-1. دورة حالة الملفات.
 
-### Checking the Status of Your Files ###
+### تفقد حالة ملفاتك ###
 
-The main tool you use to determine which files are in which state is the git status command. If you run this command directly after a clone, you should see something like this:
+باستخدام الأمر git status يمكننا معرفة حالة الملفات لدينا. إذا قمت بتشغيل هذا الأمر مباشرة بعد قيامك بعمل clone يجب أن ترى شيئاً يشبه التالي:
 
 	$ git status
 	# On branch master
 	nothing to commit, working directory clean
 
-This means you have a clean working directory—in other words, there are no tracked and modified files. Git also doesn’t see any untracked files, or they would be listed here. Finally, the command tells you which branch you’re on. For now, that is always master, which is the default; you won’t worry about it here. The next chapter will go over branches and references in detail.
+وهذا يعني أنه لديك مجلد عمل نظيف - بمعنى آخر، لايوجد أي ملفات معدلة أو ملفات غير مُتتبّعة. كما أنّ هذا الأمر يخبرك بأي فرع branch أنت تعمل. حالياً، دائماً هو master، وهو الافتراضي؛ في الفصل المقبل سنمر على الأفرع و المرجعيات references بالتفصيل.
 
-Let’s say you add a new file to your project, a simple README file. If the file didn’t exist before, and you run `git status`, you see your untracked file like so:
+لنقل بأنك قمت بإضافة ملف جديد على مشروعك، وليكن ملف README بسيط. إذا لم يكن الملف موجوداً مسبقاً، وقمت بتنفيذ الأمر `git status` سترى الملف غير مُتتبّعاً كما يلي:
 
 	$ vim README
 	$ git status
@@ -71,15 +70,15 @@ Let’s say you add a new file to your project, a simple README file. If the fil
 	#	README
 	nothing added to commit but untracked files present (use "git add" to track)
 
-You can see that your new README file is untracked, because it’s under the “Untracked files” heading in your status output. Untracked basically means that Git sees a file you didn’t have in the previous snapshot (commit); Git won’t start including it in your commit snapshots until you explicitly tell it to do so. It does this so you don’t accidentally begin including generated binary files or other files that you did not mean to include. You do want to start including README, so let’s start tracking the file.
+يمكنك ملاحظة أنّ ملفك الجديد README غير مُتتبّع، فهو تحت تبويب "untracked files" في خرج الأمر. ويعني ذلك أنّ git يرى ملفاً جديداً على commit السابقة؛ علماً أنّ git لن يقوم بإضافة هذا الملف إلى الملفات المتتبعة إلا إذا قمت بطلب ذلك بشكل مباشر، والهدف من ذلك من أجل حماية المشروع من الضم الخاطئ لملفات binary أو أي ملفات لا تود بإضافتها. إلاّ أنّك ترغب في إضافة README إلى الملفات المتتبّعة. وسنقوم بذلك حالاً.
 
-### Tracking New Files ###
+### تتبع الملفات الجديدة ###
 
-In order to begin tracking a new file, you use the command `git add`. To begin tracking the README file, you can run this:
+للقيام بتتبع ملف جديد عليه استخدام الأمر `git add` . مثلاً لنقم بتتبع الملف الجديد README:
 
 	$ git add README
 
-If you run your status command again, you can see that your README file is now tracked and staged:
+إذا قمنا بتنفيذ الأمر `git status` مرة أخرى سنلاحظ أن الملف README أصبح متتبعاً وجاهزاً staged للقيام بعملية commit:
 
 	$ git status
 	# On branch master
@@ -89,11 +88,11 @@ If you run your status command again, you can see that your README file is now t
 	#	new file:   README
 	#
 
-You can tell that it’s staged because it’s under the “Changes to be committed” heading. If you commit at this point, the version of the file at the time you ran git add is what will be in the historical snapshot. You may recall that when you ran git init earlier, you then ran git add (files) — that was to begin tracking files in your directory. The git add command takes a path name for either a file or a directory; if it’s a directory, the command adds all the files in that directory recursively.
+نستطيع معرفة بأن الملف staged من خلال ملاحظته تحت بند "changes to be comitted". إذا قمت بعمل commit في هذه اللحظة، سيقوم git بإضافة النسخة الحالية من الملف إلى snapshot. تذكر عندما قمنا بعمل git init سابقاً، ثم قمنا بإضافة الملفات عن طريق git add، كان ذلك للقيام ببدء تتبع الملفات في مجلد المشروع. يقبل الأمر git add مسار لملف أو لمجلد؛ فإذا كان المسار لمجلد سيقوم git بإضافة جميع الملفات والمجلدات ضمنه بشكل تعاودي recursively.
 
-### Staging Modified Files ###
+### تجهيز الملفات المعدلة ###
 
-Let’s change a file that was already tracked. If you change a previously tracked file called `benchmarks.rb` and then run your `status` command again, you get something that looks like this:
+لنقم بالتعديل على ملف قمنا بإضافته سابقاً. إذا قمنا مثلاً بالتعديل على ملف متتبع مسبقاً يدعى `benchmarks.rb`  وقمنا بتنفيذ الأمر git status، سيكون الخرج مشابهاً للخرج التالي:
 
 	$ git status
 	# On branch master
@@ -108,7 +107,7 @@ Let’s change a file that was already tracked. If you change a previously track
 	#	modified:   benchmarks.rb
 	#
 
-The benchmarks.rb file appears under a section named “Changes not staged for commit” — which means that a file that is tracked has been modified in the working directory but not yet staged. To stage it, you run the `git add` command (it’s a multipurpose command — you use it to begin tracking new files, to stage files, and to do other things like marking merge-conflicted files as resolved). Let’s run `git add` now to stage the benchmarks.rb file, and then run `git status` again:
+يظهر الملف benchmarks.rb تحت بند "changes not staged for commit" وهذا يعني أن الملف المُتتبّع قد خضع لعملية تعديل لكنه لم يخضع للتجهيز من أجل commit. للقيام بتجهيزه (أو تأشيره للإضافة إلى commit الجديد) يجب علينا تنفيذ الأمر `git add` (لاحظ بأنّه أمر متعدد الوظائف - نستطيع استخدامه لتتبع الملفات الجديدة، تجهيز الملفات من أجل commit، والقيام بأمور أخرى مثل حل الاعتراضات في حال القيام بدمج merge). لنقم بتنفيذ git add الآن لوضع benchmarks.rb بحالة staged، ومن ثم لنقم بتنفيذ الأمر git status لنرى ما الذي قد تغيّر:
 
 	$ git add benchmarks.rb
 	$ git status
@@ -120,7 +119,7 @@ The benchmarks.rb file appears under a section named “Changes not staged for c
 	#	modified:   benchmarks.rb
 	#
 
-Both files are staged and will go into your next commit. At this point, suppose you remember one little change that you want to make in benchmarks.rb before you commit it. You open it again and make that change, and you’re ready to commit. However, let’s run `git status` one more time:
+كلا الملفين الآن جاهز للإدخال بعملية commit المقبلة. في هذه النقطة، لنفرض أنك تود القيام بتعديل على ملف benchmarks.rb قبل القيام بعملية commit، ستقوم بفتح الملف والتعديل عليه وأنك جاهز للقيام بعملية commit. لكن قبل ذلك، دعنا نقوم بتنفيذ الأمر git status مرة إضافية:
 
 	$ vim benchmarks.rb 
 	$ git status
@@ -137,7 +136,7 @@ Both files are staged and will go into your next commit. At this point, suppose
 	#	modified:   benchmarks.rb
 	#
 
-What the heck? Now benchmarks.rb is listed as both staged and unstaged. How is that possible? It turns out that Git stages a file exactly as it is when you run the git add command. If you commit now, the version of benchmarks.rb as it was when you last ran the git add command is how it will go into the commit, not the version of the file as it looks in your working directory when you run git commit. If you modify a file after you run `git add`, you have to run `git add` again to stage the latest version of the file:
+ما الذي يحصل؟ كيف أصبح benchmarks.rb موجوداً تحت التبويبين staged و unstaged؟ لقد اتضح لنا أنّ git يقوم بتجهيز الملف على حالته عند قيامك بتنفيذ الأمر git add. إذا قمت بعمل commit الآن، ستكون نسخة benchmarks.rb كما كانت عند قيامك بتنفيذ الأمر git add وليس النسخة الجديدة التي حصلنا عليها بعد قيامنا بتعديل الملف. لذا إذا قمنا بتعديل ملف قبل قيامنا بتنفيذ git add، وقبل القيام بعملية commit، علينا تجهيز الملف مرة أخرى لعملية commit، وذلك بتنفيذ الأمر git add مرة جديدة:
 
 	$ git add benchmarks.rb
 	$ git status
@@ -149,26 +148,26 @@ What the heck? Now benchmarks.rb is listed as both staged and unstaged. How is t
 	#	modified:   benchmarks.rb
 	#
 
-### Ignoring Files ###
+### تجاهل الملفات ###
 
-Often, you’ll have a class of files that you don’t want Git to automatically add or even show you as being untracked. These are generally automatically generated files such as log files or files produced by your build system. In such cases, you can create a file listing patterns to match them named .gitignore.  Here is an example .gitignore file:
+غالباً ما تود من git تجاهل صنف من الملفات بحث لا يقوم بإضافتها تلقائياً أو لا يظهرها بأنّها غير متتبعة. تكون هذه الملفات عادة ملفات مولدة بشكل تلقائي مثل ملفات log و الملفات الوسيطة التي تولدها أدوات التطوير لديك. في مثل هذه الحالات/ يمكن إنشاء ملف .gitignore يحوي على أنماط لأسماء الملفات التي نرغب بتجاهلها. هذا مثال عمّا قد يحتويه ملف .gitignore:
 
 	$ cat .gitignore
 	*.[oa]
 	*~
 
-The first line tells Git to ignore any files ending in .o or .a — object and archive files that may be the product of building your code. The second line tells Git to ignore all files that end with a tilde (`~`), which is used by many text editors such as Emacs to mark temporary files. You may also include a log, tmp, or pid directory; automatically generated documentation; and so on. Setting up a .gitignore file before you get going is generally a good idea so you don’t accidentally commit files that you really don’t want in your Git repository.
+أول سطر يقوم بتوجيه git إلى تجاهل أي ملفات ذات لواحق من النوع o أو a - ملفات الكائنات وملفات الأرشيف وهي ملفات وسيطة تولدها أدوات بناء الكود عادة. السطر الثاني يوجه git إلى تجاهل أي ملفات تنتهي بالرمز (~) والتي تكون ملفات مؤقتة عادةً تستخدمها بعض برامج تحرير الكود. قد ترغب أيضاً بإضافة مجلدات log و tmp أو pid؛ أو حتى ملفات التوثيق تلقائية التوليد (من الكود عادة)، وغيرها. ينصح بإضافة ملف .gitignore في بداية إنشاء repository حتى نتجنب إضافة بعض الملفات عن طريق الخطأ وتلويث respository.
 
-The rules for the patterns you can put in the .gitignore file are as follows:
+قواعد الأنماط التي يمكن وضعها ضمن ملف .gitignore هي كالتالي:
 
-*	Blank lines or lines starting with # are ignored.
-*	Standard glob patterns work.
-*	You can end patterns with a forward slash (`/`) to specify a directory.
-*	You can negate a pattern by starting it with an exclamation point (`!`).
+*	الأسطر التي تبدأ بالرمز (#) يتم تجاهلها.
+*	أنماط glob القياسية تعمل.
+*	يمكن إنهاء النمط برمز (/) للدلالة على أنه يستهدف مجلداً.
+*	يمكن نفي نمط ما عن طريق وضع علامة التعجب (!) في بداية السطر قبل النمط.
 
-Glob patterns are like simplified regular expressions that shells use. An asterisk (`*`) matches zero or more characters; `[abc]` matches any character inside the brackets (in this case a, b, or c); a question mark (`?`) matches a single character; and brackets enclosing characters separated by a hyphen(`[0-9]`) matches any character between them (in this case 0 through 9) . 
+أنماط Glob عبارة عن نسخة مبسطة من Regular Expressions يتم استخدامها ضمن واجهة الأوامر shell. رمز النجمة (*) يطابق صفر-محرفاً أو أكثر. `[abc]` تطابق أي محارف ضمن الأقواس المربعة في هذه الحالة تكون a b c؛ علامة الاستفهام (?) تطابق محرفاً واحداً فقط؛ بينما تطابق الأقواس المربعة التي تحوي على محارف مفصولة بإشارة hyphen أي محرفاً يقع في المجال بين محرف البداية والنهاية - مثلا [0-9] يطابق محارف الأرقام بين 0 و 9 ضمناً.
 
-Here is another example .gitignore file:
+مثال عن ملف .gitignore:
 
 	# a comment – this is ignored
 	# no .a files
@@ -182,7 +181,7 @@ Here is another example .gitignore file:
 	# ignore doc/notes.txt, but not doc/server/arch.txt
 	doc/*.txt
 
-### Viewing Your Staged and Unstaged Changes ###
+### مشاهدة التغيّرات المجهّزة والتغيّرات غير المجهّزة ###
 
 If the `git status` command is too vague for you — you want to know exactly what you changed, not just which files were changed — you can use the `git diff` command. We’ll cover `git diff` in more detail later; but you’ll probably use it most often to answer these two questions: What have you changed but not yet staged? And what have you staged that you are about to commit? Although `git status` answers those questions very generally, `git diff` shows you the exact lines added and removed — the patch, as it were. 
 

From 91143f4c7769a0d08bd66edcf83a5b91a8e4c353 Mon Sep 17 00:00:00 2001
From: "Ammar M. Zerouk" <ammarzerouk@outlook.com>
Date: Tue, 23 Sep 2014 03:18:26 +0300
Subject: [PATCH 639/690] [ar] translating  and

---
 ar/02-git-basics/01-chapter2.markdown | 37 +++++++++++++--------------
 1 file changed, 18 insertions(+), 19 deletions(-)

diff --git a/ar/02-git-basics/01-chapter2.markdown b/ar/02-git-basics/01-chapter2.markdown
index da77fdd39..89e6b9ae2 100644
--- a/ar/02-git-basics/01-chapter2.markdown
+++ b/ar/02-git-basics/01-chapter2.markdown
@@ -183,9 +183,10 @@ Insert 18333fig0201.png
 
 ### مشاهدة التغيّرات المجهّزة والتغيّرات غير المجهّزة ###
 
-If the `git status` command is too vague for you — you want to know exactly what you changed, not just which files were changed — you can use the `git diff` command. We’ll cover `git diff` in more detail later; but you’ll probably use it most often to answer these two questions: What have you changed but not yet staged? And what have you staged that you are about to commit? Although `git status` answers those questions very generally, `git diff` shows you the exact lines added and removed — the patch, as it were. 
+إذا لم تكتف بالمعلومات التي يقدمها لك أمر `git status` يمكنك استخدام أمر `git diff`  للحصول على معلومات تفصيلية حول التغيرات التي طرأت على الملفات. سنقوم لاحقاً بالتعمق في هذا الأمر، لكن الآن سنكتفي بالإشارة إلى الاستخدامات الغالبة له؛ حيث أنك ستستخدمه غالباً للحصول على أجوبة على هذين السؤالين: ما الذي قمنا بالتعديل عليه ولم نجهزه بعد لعملية commit؟ ما الملفات التي أصبحت جاهزة للدخول في عملية commit المقبلة؟
+بالرغم من أنه يمكننا أن نحصل على هذه المعلومات باستخدام أمر `git status` إلا أنّ أمر `git diff` يوضح لنا التغيرات التي جرت على مستوى السطر والحرف - ما الذي قمنا بإضافته وما الذي أزلناه!
 
-Let’s say you edit and stage the README file again and then edit the benchmarks.rb file without staging it. If you run your `status` command, you once again see something like this:
+لنقل أنك قمت بالتعديل على ملف README مرة أخرى وأشرته للإضافة إلى عملية commit وقمت بالتعديل على ملف benchmarks.rb ولم تضفه إلى قائمة الملفات الجاهزة لعملية commit؛ إذا قمت بتنفيذ الأمر `status` ستشاهد مرة أخرى شيئاً من الشكل:
 
 	$ git status
 	# On branch master
@@ -200,7 +201,7 @@ Let’s say you edit and stage the README file again and then edit the benchmark
 	#	modified:   benchmarks.rb
 	#
 
-To see what you’ve changed but not yet staged, type `git diff` with no other arguments:
+لترى ما قمت بالتعديل عليه ولم تجهزه للإضافة نفذ الأمر `git diff` بدون إضافات:
 
 	$ git diff
 	diff --git a/benchmarks.rb b/benchmarks.rb
@@ -219,9 +220,9 @@ To see what you’ve changed but not yet staged, type `git diff` with no other a
 	           log = git.commits('master', 15)
 	           log.size
 
-That command compares what is in your working directory with what is in your staging area. The result tells you the changes you’ve made that you haven’t yet staged.
+يقوم هذا الأمر بعمل مقارنة بين الملفات ضمن مجلد العمل والملفات الموجودة في منطقة التعديلات المجهزة للإضافة staging area. وتخبرنا نتيجته بالتعديلات التي أجريناها ولم نقم بتجهيزها للإضافة إلى عملية commit المقبلة.
 
-If you want to see what you’ve staged that will go into your next commit, you can use `git diff –-cached`. (In Git versions 1.6.1 and later, you can also use `git diff –-staged`, which may be easier to remember.) This command compares your staged changes to your last commit:
+لمشاهدة الملفات ذات الحالة staged والتي ستدخل في عملية commit المقبلة، يمكن استخدام الأمر `git diff --cached` (بالنسبة للإصدارات 1.6.1 وما بعد من git يمكنك أيضاً استخدام الأمر `git diff --staged` )، كالتالي:
 
 	$ git diff --cached
 	diff --git a/README b/README
@@ -236,9 +237,9 @@ If you want to see what you’ve staged that will go into your next commit, you
 	+
 	+Grit is a Ruby library for extracting information from a Git repository
 
-It’s important to note that `git diff` by itself doesn’t show all changes made since your last commit — only changes that are still unstaged. This can be confusing, because if you’ve staged all of your changes, `git diff` will give you no output.
+من الجدير بالذكر أن أمر `git diff` لوحده لا يقوم بعرض جميع التعديلات التي تمت من آخر commit - فهو يقوم بعرض فقط التعديلات التي لم تؤشر على أنها staged. ويمكن أن يسبب ذلك بعض الإرباك، حيث أنك إذا قمت بإضافة جميع التعديلات إلى قائمة staged فلن يقوم بعرض أي شي في خرج تنفيذه.
 
-For another example, if you stage the benchmarks.rb file and then edit it, you can use `git diff` to see the changes in the file that are staged and the changes that are unstaged:
+كمثال أيضاً، إذا قمنا بإضافة benchmarks.rb إلى قائمة staged ومن ثم قمنا بالتعديل عليه من جديد، يمكننا استخدام أمر `git diff` للحصول على لائحة بالتغييرات التي حصلت ولم تضف إلى قائمة staged كالتالي:
 
 	$ git add benchmarks.rb
 	$ echo '# test line' >> benchmarks.rb
@@ -254,7 +255,6 @@ For another example, if you stage the benchmarks.rb file and then edit it, you c
 	#	modified:   benchmarks.rb
 	#
 
-Now you can use `git diff` to see what is still unstaged
 
 	$ git diff 
 	diff --git a/benchmarks.rb b/benchmarks.rb
@@ -267,7 +267,7 @@ Now you can use `git diff` to see what is still unstaged
 	 ##pp Grit::GitRuby.cache_client.stats 
 	+# test line
 
-and `git diff --cached` to see what you’ve staged so far:
+وباستخدام `git diff --cached` نتمكن من رؤية ما تم تجهيزه للإضافة إلى عملية commit القادمة:
 
 	$ git diff --cached
 	diff --git a/benchmarks.rb b/benchmarks.rb
@@ -286,16 +286,15 @@ and `git diff --cached` to see what you’ve staged so far:
 	          log = git.commits('master', 15)
 	          log.size
 
-### Committing Your Changes ###
+### القيام بعملية (اعتماد) commit للتغيّرات ###
 
-Now that your staging area is set up the way you want it, you can commit your changes. Remember that anything that is still unstaged — any files you have created or modified that you haven’t run `git add` on since you edited them — won’t go into this commit. They will stay as modified files on your disk.
-In this case, the last time you ran `git status`, you saw that everything was staged, so you’re ready to commit your changes. The simplest way to commit is to type `git commit`:
+بعد اكمال تجهيز الملفات التي ترغب بإضافتها إلى النسخة snapshot الجديدة، يمكنك تنفيذ أمر commit ليتم اعتماد التعديلات التي أجريتها في سجل git. تذكر أنّ أي ملف لم يتم تجهيزه - سواء لم تقم بإضافته باستخدام الأمر git add بعد إنشاءه أو التعديل عليه - لن يدخل في هذه الإعتمادية، وستبقى على أنها ملفات تم تعديلها في مجلد العمل. أبسط طريقة لاعتماد التعديلات هي القيام بأمر `git commit` كالتالي:
 
 	$ git commit
 
-Doing so launches your editor of choice. (This is set by your shell’s `$EDITOR` environment variable — usually vim or emacs, although you can configure it with whatever you want using the `git config --global core.editor` command as you saw in Chapter 1). 
+تنفيذ هذا الأمر سيطلب منا إدخال رسالة عملية commit - عادة ما يتم فتح محرر النصوص المشار إليه بمتغير البيئة `$EDITOR`. يمكنك تهيئته عن طريق الأمر `git config --global core.editor` كما شاهدنا في الفصل الأول.
 
-The editor displays the following text (this example is a Vim screen):
+يقوم محرر النصوص بعرض هذه الشاشة (مثالنا باستخدام VIM):
 
 	# Please enter the commit message for your changes. Lines starting
 	# with '#' will be ignored, and an empty message aborts the commit.
@@ -310,20 +309,20 @@ The editor displays the following text (this example is a Vim screen):
 	~
 	".git/COMMIT_EDITMSG" 10L, 283C
 
-You can see that the default commit message contains the latest output of the `git status` command commented out and one empty line on top. You can remove these comments and type your commit message, or you can leave them there to help you remember what you’re committing. (For an even more explicit reminder of what you’ve modified, you can pass the `-v` option to `git commit`. Doing so also puts the diff of your change in the editor so you can see exactly what you did.) When you exit the editor, Git creates your commit with that commit message (with the comments and diff stripped out).
+يمكنك ملاحظة أن رسالة عملية commit تحوي على خرج آخر عملية `git status` على شكل تعليقات بالإضافة إلى سطر فارغ في بداية الملف. يمكنك إزالة هذه التعليقات، أو يمكنك تركها لمساعدتك بتذكر ما قمت باعتماد تعديلاته. يمكنك الحصول على معلومات أكثر تفصلياً إذا قمت بتمرير الخيار `-v` إلى الأمر `git commit`. حيث يقوم ذلك بإضافة خرج أمر `git diff` إلى رسالة commit على شكل تعليقات أيضاً. عند إغلاق المحرر يقوم git بإنشاء commit ويتجاهل التعليقات.
 
-Alternatively, you can type your commit message inline with the `commit` command by specifying it after a -m flag, like this:
+علماً أنّه يمكنك كتابة رسالة الاعتمادية مباشرة من خلال تمرير الخيار `-m` إلى الأمر `git commit` على الشكل التالي:
 
 	$ git commit -m "Story 182: Fix benchmarks for speed"
 	[master]: created 463dc4f: "Fix benchmarks for speed"
 	 2 files changed, 3 insertions(+), 0 deletions(-)
 	 create mode 100644 README
 
-Now you’ve created your first commit! You can see that the commit has given you some output about itself: which branch you committed to (master), what SHA-1 checksum the commit has (`463dc4f`), how many files were changed, and statistics about lines added and removed in the commit.
+مبروك، لقد قمت بعمل أول commit لك! يعطيك خرج العملية معلومات عنها: في أي فرع branch تم الإعتماد (هنا master)، ما قيمة هاش SHA-1 الخاصة بالعملية ( هنا `463dc4f`)، عدد الملفات التي تغيّرت، بالإضافة إلى إحصاءات حول الأسطر التي أضيفت وأزيلت في هذه العملية.
 
-Remember that the commit records the snapshot you set up in your staging area. Anything you didn’t stage is still sitting there modified; you can do another commit to add it to your history. Every time you perform a commit, you’re recording a snapshot of your project that you can revert to or compare to later.
+تذكر أنّ عملية commit تأخذ صورة عن الملفات في قائمة staged. أي شيء لم تقم بإضافته إلى هذه القائمة ما زال في مجلد العمل بحالة "معدل" modified؛ يمكنك القيام بإضافتهم من خلال عملية commit جديدة إلى التأريخ في git. نستنتج أنّه في كل عملية commit يقوم git بأخذ "صورة" snapshot عن المشروع يمكننا العودة لها لاحقاً أو مقارنتها أو غير ذلك..
 
-### Skipping the Staging Area ###
+### تجاوز منطقة التجهيز Staging Area ###
 
 Although it can be amazingly useful for crafting commits exactly how you want them, the staging area is sometimes a bit more complex than you need in your workflow. If you want to skip the staging area, Git provides a simple shortcut. Providing the `-a` option to the `git commit` command makes Git automatically stage every file that is already tracked before doing the commit, letting you skip the `git add` part:
 

From 95ae9439cad6ebecff175ded38c7fbe7bbb009d1 Mon Sep 17 00:00:00 2001
From: "Ammar M. Zerouk" <ammarzerouk@outlook.com>
Date: Tue, 23 Sep 2014 23:31:40 +0300
Subject: [PATCH 640/690] [ar] translating until section 'Viewing the Commit
 History', fixing mixxing '`'

---
 ar/02-git-basics/01-chapter2.markdown | 119 +++++++++++++-------------
 1 file changed, 59 insertions(+), 60 deletions(-)

diff --git a/ar/02-git-basics/01-chapter2.markdown b/ar/02-git-basics/01-chapter2.markdown
index 89e6b9ae2..8cbf79f6b 100644
--- a/ar/02-git-basics/01-chapter2.markdown
+++ b/ar/02-git-basics/01-chapter2.markdown
@@ -165,7 +165,7 @@ Insert 18333fig0201.png
 *	يمكن إنهاء النمط برمز (/) للدلالة على أنه يستهدف مجلداً.
 *	يمكن نفي نمط ما عن طريق وضع علامة التعجب (!) في بداية السطر قبل النمط.
 
-أنماط Glob عبارة عن نسخة مبسطة من Regular Expressions يتم استخدامها ضمن واجهة الأوامر shell. رمز النجمة (*) يطابق صفر-محرفاً أو أكثر. `[abc]` تطابق أي محارف ضمن الأقواس المربعة في هذه الحالة تكون a b c؛ علامة الاستفهام (?) تطابق محرفاً واحداً فقط؛ بينما تطابق الأقواس المربعة التي تحوي على محارف مفصولة بإشارة hyphen أي محرفاً يقع في المجال بين محرف البداية والنهاية - مثلا [0-9] يطابق محارف الأرقام بين 0 و 9 ضمناً.
+أنماط Glob عبارة عن نسخة مبسطة من Regular Expressions يتم استخدامها ضمن واجهة الأوامر shell. رمز النجمة (`*`) يطابق صفر-محرفاً أو أكثر. `[abc]` تطابق أي محارف ضمن الأقواس المربعة في هذه الحالة تكون a b c؛ علامة الاستفهام (?) تطابق محرفاً واحداً فقط؛ بينما تطابق الأقواس المربعة التي تحوي على محارف مفصولة بإشارة hyphen أي محرفاً يقع في المجال بين محرف البداية والنهاية - مثلا [0-9] يطابق محارف الأرقام بين 0 و 9 ضمناً.
 
 مثال عن ملف .gitignore:
 
@@ -324,7 +324,7 @@ Insert 18333fig0201.png
 
 ### تجاوز منطقة التجهيز Staging Area ###
 
-Although it can be amazingly useful for crafting commits exactly how you want them, the staging area is sometimes a bit more complex than you need in your workflow. If you want to skip the staging area, Git provides a simple shortcut. Providing the `-a` option to the `git commit` command makes Git automatically stage every file that is already tracked before doing the commit, letting you skip the `git add` part:
+منطقة التجهيز تكون أحياناً معقدة أكثر مما تحتاج في عملك إلا أنّها مفيدة لعمل commits تماماً كما تودهم أن يكونوا. إذا أردت تجاوز منطقة التجهيز، يوفر git اختصاراً بسيطاً لذلك. باستخدام الأمر `git commit -a` يقوم git بإضافة الملفات المتتبعة إلى منطقة التجهيز بشكل تلقائي، كأنك قمت بعمل `git add`:
 
 	$ git status
 	# On branch master
@@ -337,13 +337,13 @@ Although it can be amazingly useful for crafting commits exactly how you want th
 	[master 83e38c7] added new benchmarks
 	 1 files changed, 5 insertions(+), 0 deletions(-)
 
-Notice how you don’t have to run `git add` on the benchmarks.rb file in this case before you commit.
+لاحظ بأنك لاتحتاج إلى تنفيذ الأمر `git add` على ملف benchmark.rb قبل القيام بعملية commit.
 
-### Removing Files ###
+### إزالة الملفات ###
 
-To remove a file from Git, you have to remove it from your tracked files (more accurately, remove it from your staging area) and then commit. The `git rm` command does that and also removes the file from your working directory so you don’t see it as an untracked file next time around.
+لحذف ملف من git، يجب عليك إزالته من قائمة الملفات المتتبعة (وبشكل أدق، إزالته من منطقة التجهيز) ومن ثم القيام بعملية commit. الأمر `git rm` يقوم بعمل ذلك كما يقوم بحذف الملف من مجلد العمل الخاص بك لذا لن تراه بعد الآن في قائمة الملفات غير المتتبعة في المرة المقبلة.
 
-If you simply remove the file from your working directory, it shows up under the “Changes not staged for commit” (that is, _unstaged_) area of your `git status` output:
+إذا قمت بإزالة الملف من مجلد العمل، يظهر تحت بند "تعديلات غير مجهزة للاعتماد" (أي _unstaged_) من خرج الأمر `git status`:
 
 	$ rm grit.gemspec
 	$ git status
@@ -355,7 +355,7 @@ If you simply remove the file from your working directory, it shows up under the
 	#       deleted:    grit.gemspec
 	#
 
-Then, if you run `git rm`, it stages the file’s removal:
+فإذا قمت بتنفيذ أمر `git rm` يقوم بتجهيز عملية الحذف ليتم اعتمادها:
 
 	$ git rm grit.gemspec
 	rm 'grit.gemspec'
@@ -368,31 +368,31 @@ Then, if you run `git rm`, it stages the file’s removal:
 	#       deleted:    grit.gemspec
 	#
 
-The next time you commit, the file will be gone and no longer tracked. If you modified the file and added it to the index already, you must force the removal with the `-f` option. This is a safety feature to prevent accidental removal of data that hasn’t yet been recorded in a snapshot and that can’t be recovered from Git.
+وفي المرة المقبلة التي ستقوم فيها بعمل commit، سيتم إزالة الملف من قائمة التتبع. إذا قمت مسبقاً بتعديل الملف وإضفته إلى الفهرس، يجب عليه تنفيذ عملية الحذف قسرياً وذلك بإضافة الخيار `-f`. يتم اتباع هذه الطريقة بغية حماية البيانات من أية عمليات حذف "عرضية" لملفات لم يتم تسجيلها ضمن git ولايمكن استعادتها بعد ذلك.
 
-Another useful thing you may want to do is to keep the file in your working tree but remove it from your staging area. In other words, you may want to keep the file on your hard drive but not have Git track it anymore. This is particularly useful if you forgot to add something to your `.gitignore` file and accidentally added it, like a large log file or a bunch of `.a` compiled files. To do this, use the `--cached` option:
+أما إذا أردت إزالة الملف من منطقة التجهيز مع الحفاظ عليه في مجلد العمل (أي إزالته من تتبع git مع بقاءه على وسيطة التخزين) - وهو شيء مفيد إذا قمت بنسيان إضافة شيء ما إلى ملف `.gitignore` وأضفته عن طريق الخطأ ؛ كملف log كبير مثلاً - استخدم الخيار `--cached` مع الأمر `git rm` كالتالي:
 
 	$ git rm --cached readme.txt
 
-You can pass files, directories, and file-glob patterns to the `git rm` command. That means you can do things such as
+يمكنك تمرير أسماء ملفات، مجلدات، وأنماط glob للأمر `git rm`. وهذا يعني بأنه يمكننا عمل أشياء كالتالي:
 
 	$ git rm log/\*.log
 
-Note the backslash (`\`) in front of the `*`. This is necessary because Git does its own filename expansion in addition to your shell’s filename expansion. This command removes all files that have the `.log` extension in the `log/` directory. Or, you can do something like this:
+لاحظ الشرطة العكسية (`\`) قبل رمز النجمة `*`. إنّها ضرورية لأن git يقوم بعمل توسعة الأسماء الخاصة به بالإضافة إلى التوسعة الخاصة بسطر الأوامر. هذا الأمر يقوم بحذف كافة الملفات التي تملك اللاحقة `.log` في مجلد `/log`. أو يمكنك عمل شيء كالتالي:
 
 	$ git rm \*~
 
-This command removes all files that end with `~`.
+وهذا الأمر يقوم بحذف كافة الملفات المنتهية بالمحرف `~`.
 
-### Moving Files ###
+### نقل الملفات ###
 
-Unlike many other VCS systems, Git doesn’t explicitly track file movement. If you rename a file in Git, no metadata is stored in Git that tells it you renamed the file. However, Git is pretty smart about figuring that out after the fact — we’ll deal with detecting file movement a bit later.
+على خلاف أغلب أنظمة إدارة الإصدارات VCS الأخرى، لا يقوم git بتعقب حركة الملفات بشكل صريح. إذا قمت بإعادة تسمية ملف ضمن git، لايتم تسجيل أي بيانات وصفية metadata في git تقوم بأنك قمت بإعادة تسمية الملف. لكن، git ذكي جداً في استعياب ذلك - وسنقوم بمناقشة الأمر بعد قليل.
 
-Thus it’s a bit confusing that Git has a `mv` command. If you want to rename a file in Git, you can run something like
+إذا أردت القيام بإعادة تسمية ملف يمكنك استخدام أمر `mv` في git كالتالي:
 
 	$ git mv file_from file_to
 
-and it works fine. In fact, if you run something like this and look at the status, you’ll see that Git considers it a renamed file:
+إذا قمنا بتنفيذ الأمر والنظر إلى خرج أمر `git status`:
 
 	$ git mv README.txt README
 	$ git status
@@ -405,23 +405,23 @@ and it works fine. In fact, if you run something like this and look at the statu
 	#       renamed:    README.txt -> README
 	#
 
-However, this is equivalent to running something like this:
+وهو مكافئ للقيام بتنفيذ الأوامر التالي على التسلسل:
 
 	$ mv README.txt README
 	$ git rm README.txt
 	$ git add README
 
-Git figures out that it’s a rename implicitly, so it doesn’t matter if you rename a file that way or with the `mv` command. The only real difference is that `mv` is one command instead of three — it’s a convenience function. More important, you can use any tool you like to rename a file, and address the add/rm later, before you commit.
+يدرك git بأنك قمت بعملية إعادة تسمية، لذا فالإختلاف الوحيد بين الطريقتين هو أنّ `git mv` عبارة عن أمر واحد، وليس ثلاثة أوامر. يمكن الاستفادة من هذه الخاصة باستخدام أية أدوات للقيام بعمليات إعادة التسمية، واستخدام add/rm قبل القيام بعملية commit.
 
-## Viewing the Commit History ##
+## مراجعة تأريخ عمليات commit ##
 
-After you have created several commits, or if you have cloned a repository with an existing commit history, you’ll probably want to look back to see what has happened. The most basic and powerful tool to do this is the `git log` command.
+بعد قيامك بعدد من عمليات الاعتماد commit، أو استنساخ repository بسجل تأريخ، ربما ستود إلقاء نظرة على ما جرى. أبسط وأقوى أداة لعمل ذلك هي الأمر `git log`.
 
-These examples use a very simple project called simplegit that I often use for demonstrations. To get the project, run 
+هذه الأمثلة تستخدم مشروع بسيط جداً يدعى simplegit أقوم باستخدامه في عمليات العرض بأغلب الأحيان. للحصول على المشروع قم باستنساخه عن موقع github كالتالي:
 
 	git clone git://github.com/schacon/simplegit-progit.git
 
-When you run `git log` in this project, you should get output that looks something like this:
+عندما تقوم بعمل `git log` ضمن المشروع، سيظهر لديك خرج مشابه للتالي:
 
 	$ git log
 	commit ca82a6dff817ec66f44342007202690a93763949
@@ -442,11 +442,11 @@ When you run `git log` in this project, you should get output that looks somethi
 
 	    first commit
 
-By default, with no arguments, `git log` lists the commits made in that repository in reverse chronological order. That is, the most recent commits show up first. As you can see, this command lists each commit with its SHA-1 checksum, the author’s name and e-mail, the date written, and the commit message.
+بتنفيذ الأمر بدون بارمترات، يقوم git بعرض عمليات commit في repository بترتيب زمني معكوس - من الأحدث إلى الأقدم. كما يقوم بعرض بجانب كل commit هاش SHA-1 checksum الخاص بها، اسم وبريد الكاتب الإلكتروني، تاريخ الاعتماد، ورسالة الاعتماد.
 
-A huge number and variety of options to the `git log` command are available to show you exactly what you’re looking for. Here, we’ll show you some of the most-used options.
+يمكن إرفاق الأمر `git log` بعدد كبير من الخيارات للحصول على المعلومات التي نريدها بالضبط.. تجد في الأسفل مثالاً عن أكثر الخيارات استخداماً.
 
-One of the more helpful options is `-p`, which shows the diff introduced in each commit. You can also use `-2`, which limits the output to only the last two entries:
+أحد أهم الخيارات هو `-p`، والذي يقوم بإظهار الفوارق المستحدثة بين عمليات commit المختلفة. يمكن أيضاً استخدام الخيار `-2` ليحد خرج النتيجة إلى آخر عمليتين:
 
 	$ git log –p -2
 	commit ca82a6dff817ec66f44342007202690a93763949
@@ -486,8 +486,7 @@ One of the more helpful options is `-p`, which shows the diff introduced in each
 	-end
 	\ No newline at end of file
 
-This option displays the same information but with a diff directly following each entry. This is very helpful for code review or to quickly browse what happened during a series of commits that a collaborator has added.
-You can also use a series of summarizing options with `git log`. For example, if you want to see some abbreviated stats for each commit, you can use the `--stat` option:
+هذا الخيار يعرض نفس المعلومات بالإضافة خرج diff بعده مباشرة. فهو مهم جداً من أجل مراجعة الكود واستعراض ما الذي تغير بشكل سريع ضمن سلسلة من عمليات commit. يمكنك أيضاً استخدام خيارات للتلخيص مع أمر `git log`. على سبيل المثال، إذا أردت رؤية بعض الإحصاءات المختصرة لكل commit، يمكنك استخدام الخيار `stat`:
 
 	$ git log --stat 
 	commit ca82a6dff817ec66f44342007202690a93763949
@@ -519,43 +518,43 @@ You can also use a series of summarizing options with `git log`. For example, if
 	 lib/simplegit.rb |   25 +++++++++++++++++++++++++
 	 3 files changed, 54 insertions(+), 0 deletions(-)
 
-As you can see, the `--stat` option prints below each commit entry a list of modified files, how many files were changed, and how many lines in those files were added and removed. It also puts a summary of the information at the end.
-Another really useful option is `--pretty`. This option changes the log output to formats other than the default. A few prebuilt options are available for you to use. The oneline option prints each commit on a single line, which is useful if you’re looking at a lot of commits. In addition, the `short`, `full`, and `fuller` options show the output in roughly the same format but with less or more information, respectively:
+كما ترى باستخدام الخيار `--stat` يتم عرض قائمة من الملفات المعدلة، عدد الملفات التي تغيرت، وعدد الأسطر التي أضيفت أو أزيلت. كما يضع ملخصاً للمعلومات في النهاية.
+يوجد خيار مفيد آخر وهو `--pretty`. هذا الخيار يغير خرج السل إلى صيغ غير الافتراضية. يوجد بعضها مركب مسبقاً. مثلاً `oneline` يقوم بطباعة كل commit على سطر لوحدها، وهذا أمر مفيد في حال كنت تنظر إلى العديد من عمليات commit. بالإضافة إلى `short`، `full` و `fuller` والتي تعرض خرجاً تقريباً بنفس الصيغة مع معلومات أكثر أو أقل:
 
 	$ git log --pretty=oneline
 	ca82a6dff817ec66f44342007202690a93763949 changed the version number
 	085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7 removed unnecessary test code
 	a11bef06a3f659402fe7563abf99ad00de2209e6 first commit
 
-The most interesting option is `format`, which allows you to specify your own log output format. This is especially useful when you’re generating output for machine parsing — because you specify the format explicitly, you know it won’t change with updates to Git:
+أكثر الخيارات أهمية هو `format`، والذي يسمح لك بتحديد صيغة الخرج بشكل صريح بما يتناسب مع إعرابها آلياً - حيث أنك تعرف أنّه لن يتغير عند التحديث إلى git:
 
 	$ git log --pretty=format:"%h - %an, %ar : %s"
 	ca82a6d - Scott Chacon, 11 months ago : changed the version number
 	085bb3b - Scott Chacon, 11 months ago : removed unnecessary test code
 	a11bef0 - Scott Chacon, 11 months ago : first commit
 
-Table 2-1 lists some of the more useful options that format takes.
-
-	Option	Description of Output
-	%H	Commit hash
-	%h	Abbreviated commit hash
-	%T	Tree hash
-	%t	Abbreviated tree hash
-	%P	Parent hashes
-	%p	Abbreviated parent hashes
-	%an	Author name
-	%ae	Author e-mail
-	%ad	Author date (format respects the –date= option)
-	%ar	Author date, relative
-	%cn	Committer name
-	%ce	Committer email
-	%cd	Committer date
-	%cr	Committer date, relative
-	%s	Subject
-
-You may be wondering what the difference is between _author_ and _committer_. The author is the person who originally wrote the work, whereas the committer is the person who last applied the work. So, if you send in a patch to a project and one of the core members applies the patch, both of you get credit — you as the author and the core member as the committer. We’ll cover this distinction a bit more in Chapter 5.
-
-The oneline and format options are particularly useful with another `log` option called `--graph`. This option adds a nice little ASCII graph showing your branch and merge history, which we can see our copy of the Grit project repository:
+الجدول 2-1 يعرض بعض الخيارات المفيدة التي يمكن إضافتها إلى الصيغة.
+
+	الخيار	وصف الخرج
+	%H	Commit هاش
+	%h	الهاش الاعتمادي المختصر
+	%T	هاش الشجرة
+	%t	هاش الشجرة المختصر
+	%P	هاشات الوالد
+	%p	هاشات الوالد المختصرة
+	%an	اسم الكاتب
+	%ae	بريد الكاتب الإلكتروني
+	%ad	تاريخ الكاتب (يراعي الصيغة –date= option)
+	%ar	تاريخ الكاتب - نسبياً
+	%cn	اسم منفذ الاعتماد
+	%ce	بريد منفذ الاعتماد الإلكتروني
+	%cd	تاريخ منفذ الاعتماد
+	%cr	تاريخ منفذ الاعتماد - نسبياً
+	%s	العنوان
+
+قد تتسائل عن الاختلاف بين _الكاتب_ AUTHOR و _منفذ الاعتماد_ COMMITTER. الكاتب هو الشخص الذي كتب العمل بداية، بينما منفذ الاعتماد هو آخر شخص طبق العمل. لذا، إذا أرسلت باتشاً إلى مشروع وأحد المطورين الرئيسين قام بتطبيق الباتش، تأخذان كلاكما الاعتمادية - أنت ككاتب وهو كمنفذ اعتماد.
+
+وتكون هذه الخيارات مفيدة أكثر بالترافق مع الخيار `--graph`. حيث يضيف هذا الأمر غراف ASCII بسيط يوضح تأريخ الأفرع و الدمج، لاحظ التالي:
 
 	$ git log --pretty=format:"%h %s" --graph
 	* 2d3acf9 ignore errors from SIGCHLD on trap
@@ -569,17 +568,17 @@ The oneline and format options are particularly useful with another `log` option
 	* d6016bc require time for xmlschema
 	*  11d191e Merge branch 'defunkt' into local
 
-Those are only some simple output-formatting options to `git log` — there are many more. Table 2-2 lists the options we’ve covered so far and some other common formatting options that may be useful, along with how they change the output of the log command.
+يوجد مجموعة من الخيارات البسيطة مع أمر `git log`. يوضح الجدول 2-2 قائمة من الخيارات التي قمنا بتغطيتها حتى الآن وبعض صيغ التنسيق الشائعة والتي قد تكون مفيدة، وبجانبها شرح مبسط عن التغيير الذي تجريه على الخرج.
 
-	Option	Description
-	-p	Show the patch introduced with each commit.
-	--stat	Show statistics for files modified in each commit.
+	الخيار	الوصف
+	-p	يظهر الباتش المدخل مع كل عملية commit.
+	--stat	يظهر إحصاءات حول التعديلات التي حصلت على الملفات مع كل عملية commit.
 	--shortstat	Display only the changed/insertions/deletions line from the --stat command.
-	--name-only	Show the list of files modified after the commit information.
-	--name-status	Show the list of files affected with added/modified/deleted information as well.
-	--abbrev-commit	Show only the first few characters of the SHA-1 checksum instead of all 40.
+	--name-only	يظهر قائمة الملفات المعدلة.
+	--name-status	يظهر قائمة الملفات المعدلة عن طريق الإضافة والحذف وغير ذلك.
+	--abbrev-commit	يظهر أول مجموعة من هاش SHA-1 بدلاً عن كامل الأحرف 40.
 	--relative-date	Display the date in a relative format (for example, “2 weeks ago”) instead of using the full date format.
-	--graph	Display an ASCII graph of the branch and merge history beside the log output.
+	--graph	عرض غراف ASCII مع الخرج يظهر عمليات التفريع و الدمج.
 	--pretty	Show commits in an alternate format. Options include oneline, short, full, fuller, and format (where you specify your own format).
 
 ### Limiting Log Output ###

From 3bdbbf64bb91bb100eca3d955dd6a31328e1d310 Mon Sep 17 00:00:00 2001
From: "Ammar M. Zerouk" <ammarzerouk@outlook.com>
Date: Wed, 24 Sep 2014 05:51:00 +0300
Subject: [PATCH 641/690] [ar] translating 'limiting log output'

---
 ar/02-git-basics/01-chapter2.markdown | 30 +++++++++++++--------------
 1 file changed, 15 insertions(+), 15 deletions(-)

diff --git a/ar/02-git-basics/01-chapter2.markdown b/ar/02-git-basics/01-chapter2.markdown
index 8cbf79f6b..72948c863 100644
--- a/ar/02-git-basics/01-chapter2.markdown
+++ b/ar/02-git-basics/01-chapter2.markdown
@@ -581,30 +581,30 @@ Insert 18333fig0201.png
 	--graph	عرض غراف ASCII مع الخرج يظهر عمليات التفريع و الدمج.
 	--pretty	Show commits in an alternate format. Options include oneline, short, full, fuller, and format (where you specify your own format).
 
-### Limiting Log Output ###
+### تحديد خرج السجل ###
 
-In addition to output-formatting options, git log takes a number of useful limiting options — that is, options that let you show only a subset of commits. You’ve seen one such option already — the `-2` option, which show only the last two commits. In fact, you can do `-<n>`, where `n` is any integer to show the last `n` commits. In reality, you’re unlikely to use that often, because Git by default pipes all output through a pager so you see only one page of log output at a time.
+بالإضافة تحديد شكل الخرج، يسمح git بأخذ مجموعة جزئية فقط من الخرج. وقد قمت بمشاهدة ذلك مسبقاً - الخيار `-2` المستخدم لعرض آخر عمليتي commit. في الواقع يمكنك استخدام `-<n>` حيث `n` هي عدد صحيح لعرض آخر `n` عملية commit. في الحقيقة، لن تستخدمها على الغالب، لأن git يقوم بتمرير كامل الخرج لبرنامج تصفح لتتمكن من تصفح عمليات commit صفحة صفحة.
 
-However, the time-limiting options such as `--since` and `--until` are very useful. For example, this command gets the list of commits made in the last two weeks:
+من الخيارات الهامة جداً، المحددات الزمنية مثل `--since` و `--until`. على سبيل المثال، هذا الأمر يعطيك قائمة بعمليات commit التي حصلت في آخر أسبوعين:
 
 	$ git log --since=2.weeks
 
-This command works with lots of formats — you can specify a specific date (“2008-01-15”) or a relative date such as “2 years 1 day 3 minutes ago”.
+ويعمل هذا الأمر مع أنواع كثيرة من الصيغ - يمكنك تحديد تاريخ محدد ("2008-01-15") أو تاريخ نسبي مثل "2 years 1 day 3 minutes ago".
 
-You can also filter the list to commits that match some search criteria. The `--author` option allows you to filter on a specific author, and the `--grep` option lets you search for keywords in the commit messages. (Note that if you want to specify both author and grep options, you have to add `--all-match` or the command will match commits with either.)
+يكطمط أيضاً تصفية قائمة عمليات commit من خلال محددات البحث. مثلاً خيار `--author` يقوم بتصفية النتائج وفق كاتب محدد، و `--grep` يقوم بالفلترة عن طريق كلمة مفتاحية. (لاحظ أنّه إذا قمت بإضافة  خياراي author و grep، يجب عليك إضافة الخيار `--all-match` أو سيقوم git بعمل مطابقة مع أحدهما فقط).
 
-The last really useful option to pass to `git log` as a filter is a path. If you specify a directory or file name, you can limit the log output to commits that introduced a change to those files. This is always the last option and is generally preceded by double dashes (`--`) to separate the paths from the options.
+آخر الخيارات الهامة التي يمكن تمريرها إلى الأمر `git log` كمصناف هي المسار. إذا قمت بتحديد مجلد أو اسم ملف، يمكنك تحديد الخرج إلى عمليات commit التي آثرت في هذا المسار. ودائماً ما يكون آخر خيار  يوضع في `log` ويسبق بداشين double dashes (`--`) ليفصل المسارات عن الخيارات.
 
-In Table 2-3 we’ll list these and a few other common options for your reference.
+في الجدول 2-3 - نعرض الخيارات التي يمكن إضافتها مع log.
 
-	Option	Description
-	-(n)	Show only the last n commits
-	--since, --after	Limit the commits to those made after the specified date.
-	--until, --before	Limit the commits to those made before the specified date.
-	--author	Only show commits in which the author entry matches the specified string.
-	--committer	Only show commits in which the committer entry matches the specified string.
+	خيار	وصف
+	-(n)	يظهر آن n عملية commit.
+	--since, --after	تحديد عمليات commit بعد التاريخ الذي يتلوها.
+	--until, --before	تحديد عمليات commit حتى التاريخ الذي يتلوها.
+	--author	فقط أظهر عمليات commit التابعة لهذا الكاتب.
+	--committer	فقط أظهر عمليات commit التابعة لهذا المعتمد.
 
-For example, if you want to see which commits modifying test files in the Git source code history were committed by Junio Hamano and were not merges in the month of October 2008, you can run something like this:
+على سبيل المثال، إذا أردت رؤية أي عمليات commit عدلت ملفات الاختبار في تأريخ الكود المصدري والتي قام Junio Hamano بعملها ولم يتم دمجها في شهر أوكتوبر 2008، يمكن كتابة هذا الأمر:
 
 	$ git log --pretty="%h - %s" --author=gitster --since="2008-10-01" \
 	   --before="2008-11-01" --no-merges -- t/
@@ -615,7 +615,7 @@ For example, if you want to see which commits modifying test files in the Git so
 	51a94af - Fix "checkout --track -b newbranch" on detac
 	b0ad11e - pull: allow "git pull origin $something:$cur
 
-Of the nearly 20,000 commits in the Git source code history, this command shows the 6 that match those criteria.
+من بين 20 ألف عملية commit تقريباً في تأريخ git الخاص بهذا الكود المصدري، أظهر الأمر فقط عمليات الاعتماد الستة المطابقة لمحددات البحث.
 
 ### Using a GUI to Visualize History ###
 

From 4577559eb6f77e233b8d221d75fd4a2ebc1e0225 Mon Sep 17 00:00:00 2001
From: Franz Holzinger <franz.holzinger@fholzinger.com>
Date: Wed, 24 Sep 2014 07:24:52 +0200
Subject: [PATCH 642/690] Update 01-chapter2.markdown

Dateien, die bisher nocht nicht

==> 'noch nicht'
---
 de/02-git-basics/01-chapter2.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/de/02-git-basics/01-chapter2.markdown b/de/02-git-basics/01-chapter2.markdown
index c4be80626..bb13f3dbd 100644
--- a/de/02-git-basics/01-chapter2.markdown
+++ b/de/02-git-basics/01-chapter2.markdown
@@ -115,7 +115,7 @@ Sagen wir Du fügst eine neue `README` Datei zu Deinem Projekt hinzu. Wenn die D
 
 <!--You can see that your new `README` file is untracked, because it’s under the “Untracked files” heading in your status output. Untracked basically means that Git sees a file you didn’t have in the previous snapshot (commit); Git won’t start including it in your commit snapshots until you explicitly tell it to do so. It does this so you don’t accidentally begin including generated binary files or other files that you did not mean to include. You do want to start including README, so let’s start tracking the file.-->
 
-Alle Dateien, die in der Sektion „Untracked files“ aufgelistet werden, sind Dateien, die bisher nocht nicht versioniert sind. Dort wird jetzt auch die Datei `README` angezeigt. Mit anderen Worten, die Datei `README` wird in diesem Bereich gelistet, weil sie im letzen Snapshot (Commit) von Git nicht enthalten ist. Git nimmt eine solche Datei nicht automatisch in die Versionskontrolle auf, sondern man muss Git dazu ausdrücklich auffordern. Ansonsten würden generierte Binärdateien oder andere Dateien, die Du nicht in Deinem Repository haben willst, automatisch hinzugefügt werden. Das möchte man in den meisten Fällen vermeiden. Jetzt wollen wir aber Änderungen an der Datei `README` verfolgen und fügen sie deshalb zur Versionskontrolle hinzu.
+Alle Dateien, die in der Sektion „Untracked files“ aufgelistet werden, sind Dateien, die bisher noch nicht versioniert sind. Dort wird jetzt auch die Datei `README` angezeigt. Mit anderen Worten, die Datei `README` wird in diesem Bereich gelistet, weil sie im letzen Snapshot (Commit) von Git nicht enthalten ist. Git nimmt eine solche Datei nicht automatisch in die Versionskontrolle auf, sondern man muss Git dazu ausdrücklich auffordern. Ansonsten würden generierte Binärdateien oder andere Dateien, die Du nicht in Deinem Repository haben willst, automatisch hinzugefügt werden. Das möchte man in den meisten Fällen vermeiden. Jetzt wollen wir aber Änderungen an der Datei `README` verfolgen und fügen sie deshalb zur Versionskontrolle hinzu.
 
 <!--### Tracking New Files ###-->
 ### Neue Dateien zur Versionskontrolle hinzufügen ###

From c2c69ebe94d423458ef8d670bda7602a73436d4a Mon Sep 17 00:00:00 2001
From: Franz Holzinger <franz.holzinger@fholzinger.com>
Date: Wed, 24 Sep 2014 07:27:00 +0200
Subject: [PATCH 643/690] Update 01-chapter3.markdown

Mit anderen Worten kann Git den neuen Commit, durch verfolgen der Commitabfolge
==> "durch Verfolgen"
---
 de/03-git-branching/01-chapter3.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/de/03-git-branching/01-chapter3.markdown b/de/03-git-branching/01-chapter3.markdown
index fd2081a01..aa24fbd22 100644
--- a/de/03-git-branching/01-chapter3.markdown
+++ b/de/03-git-branching/01-chapter3.markdown
@@ -280,7 +280,7 @@ Mach Deine Tests, stell sicher das sich der Hotfix verhält wie erwartet und fü
 
 <!--You’ll notice the phrase "Fast forward" in that merge. Because the commit pointed to by the branch you merged in was directly upstream of the commit you’re on, Git moves the pointer forward. To phrase that another way, when you try to merge one commit with a commit that can be reached by following the first commit’s history, Git simplifies things by moving the pointer forward because there is no divergent work to merge together — this is called a "fast forward".-->
 
-Du wirst die Mitteilung „Fast Forward“ während des Zusammenführens bemerken. Da der neue Commit direkt von dem ursprünglichen Commit, auf den sich der nun eingebrachte Zweig bezieht, abstammt, bewegt Git einfach den Zeiger weiter. Mit anderen Worten kann Git den neuen Commit, durch verfolgen der Commitabfolge, direkt erreichen, dann bewegt es ausschließlich den Branch-Zeiger. Zu einer tatsächlichen Kombination der Commits besteht ja kein Anlass. Dieses Vorgehen wird „Fast Forward“ genannt.
+Du wirst die Mitteilung „Fast Forward“ während des Zusammenführens bemerken. Da der neue Commit direkt von dem ursprünglichen Commit, auf den sich der nun eingebrachte Zweig bezieht, abstammt, bewegt Git einfach den Zeiger weiter. Mit anderen Worten kann Git den neuen Commit, durch Verfolgen der Commitabfolge, direkt erreichen, dann bewegt es ausschließlich den Branch-Zeiger. Zu einer tatsächlichen Kombination der Commits besteht ja kein Anlass. Dieses Vorgehen wird „Fast Forward“ genannt.
 
 <!--Your change is now in the snapshot of the commit pointed to by the `master` branch, and you can deploy your change (see Figure 3-14).-->
 

From 22b36e13d62dad0a933f79a8fccb0c6f20c51791 Mon Sep 17 00:00:00 2001
From: Franz Holzinger <franz.holzinger@fholzinger.com>
Date: Wed, 24 Sep 2014 07:30:48 +0200
Subject: [PATCH 644/690] Update 01-chapter3.markdown

Um einen lokalen Branch mit einem anderem Namen als der Remote-Branch, kannst Du einfach die erste Varianten mit einem neuen lokalen Branch-Namen:

==> "Um einen lokalen Branch mit einem anderen Namen zu versehen als jenem im Remote-Branch, kannst Du einfach die erste Variante mit einem neuen lokalen Branch-Namen verwenden:"
---
 de/03-git-branching/01-chapter3.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/de/03-git-branching/01-chapter3.markdown b/de/03-git-branching/01-chapter3.markdown
index aa24fbd22..f37dca23d 100644
--- a/de/03-git-branching/01-chapter3.markdown
+++ b/de/03-git-branching/01-chapter3.markdown
@@ -724,7 +724,7 @@ Wenn Du ein Repository klonst, wird automatisch ein `master`-Branch erzeugt, wel
 
 <!--To set up a local branch with a different name than the remote branch, you can easily use the first version with a different local branch name:-->
 
-Um einen lokalen Branch mit einem anderem Namen als der Remote-Branch, kannst Du einfach die erste Varianten mit einem neuen lokalen Branch-Namen:
+Um einen lokalen Branch mit einem anderen Namen zu versehen als jenem im Remote-Branch, kannst Du einfach die erste Variante mit einem neuen lokalen Branch-Namen verwenden:
 
 	$ git checkout -b sf origin/serverfix
 	Branch sf set up to track remote branch serverfix from origin.

From d72851e87037b00dff48da717b5b205e4e050b6f Mon Sep 17 00:00:00 2001
From: Cheng Lian <lian.cs.zju@gmail.com>
Date: Sat, 27 Sep 2014 14:53:56 +0800
Subject: [PATCH 645/690] Update 01-chapter9.markdown

---
 zh/09-git-internals/01-chapter9.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/zh/09-git-internals/01-chapter9.markdown b/zh/09-git-internals/01-chapter9.markdown
index 0c29420fc..5b4e631bb 100644
--- a/zh/09-git-internals/01-chapter9.markdown
+++ b/zh/09-git-internals/01-chapter9.markdown
@@ -109,7 +109,7 @@ Git 初始化了 `objects` 目录，同时在该目录下创建了 `pack` 和 `i
 	100644 blob 8f94139338f9404f26296befa88755fc2598c289      Rakefile
 	040000 tree 99f1a6d12cb4b6f19c8655fca46c3ecf317074e0      lib
 
-`master^{tree}` 表示 `branch` 分支上最新提交指向的 tree 对象。请注意 `lib` 子目录并非一个 blob 对象，而是一个指向另一个 tree 对象的指针：
+`master^{tree}` 表示 `master` 分支上最新提交指向的 tree 对象。请注意 `lib` 子目录并非一个 blob 对象，而是一个指向另一个 tree 对象的指针：
 
 	$ git cat-file -p 99f1a6d12cb4b6f19c8655fca46c3ecf317074e0
 	100644 blob 47c6340d6459e05787f644c2447d2595f5d3a54b      simplegit.rb

From 978b7dd809ff21b02efe9af6c7deece97980dcbb Mon Sep 17 00:00:00 2001
From: Marco Buttu <marco.buttu@gmail.com>
Date: Tue, 30 Sep 2014 16:26:52 +0200
Subject: [PATCH 646/690] Fixed some typos in the section "Per Iniziare - Basi
 di Git"

---
 it/01-introduction/01-chapter1.markdown | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/it/01-introduction/01-chapter1.markdown b/it/01-introduction/01-chapter1.markdown
index 85216ff53..18a222ff6 100644
--- a/it/01-introduction/01-chapter1.markdown
+++ b/it/01-introduction/01-chapter1.markdown
@@ -41,7 +41,7 @@ Inoltre, molti di questi sistemi trattano bene l'avere più repository remoti su
 
 ## Una Breve Storia di Git ##
 
-Come per molte grandi cose della vita, Git è nato con un po' di distruzione creativa e polemiche infuocate. Il kernel di Linux è un progetto software open source di grande portata abbastanza. Per buona parte del tempo (1991-2002) della manutenzione del kernel Linux le modifiche al software venivano passate sotto forma di patch e file compressi. Nel 2002, il progetto del kernel Linux iniziò ad utilizzare un sistema DVCS proprietario chiamato BitKeeper.
+Come per molte grandi cose della vita, Git è nato con un po' di distruzione creativa e polemiche infuocate. Il kernel di Linux è un progetto software open source di grande portata. Per buona parte del tempo (1991-2002) della manutenzione del kernel Linux le modifiche al software venivano passate sotto forma di patch e file compressi. Nel 2002, il progetto del kernel Linux iniziò ad utilizzare un sistema DVCS proprietario chiamato BitKeeper.
 
 Nel 2005 il rapporto tra la comunità che sviluppa il kernel Linux e la società commerciale che aveva sviluppato BitKeeper si ruppe, e fu revocato l'uso gratuito di BitKeeper. Ciò indusse la comunità di sviluppo di Linux (e in particolare Linus Torvalds, il creatore di Linux) a sviluppare uno strumento proprio, basandosi su alcune delle lezioni apprese durante l'utilizzo di BitKeeper. Alcuni degli obiettivi del nuovo sistema erano i seguenti:
 
@@ -69,7 +69,7 @@ Git non considera i dati né li registra in questo modo. Git considera i propri
 Insert 18333fig0105.png 
 Figura 1-5.  Git immagazzina i dati come snapshot del progetto nel tempo.
 
-Questa è una distinzione importante tra Git e pressocché tutti gli altri VCS. Git riconsidera quasi tutti gli aspetti del controllo di versione che la maggior parte degli altri sistemi ha copiato dalle generazioni precedenti. Questo rende Git più simile a un mini filesystem con a dispoizione strumenti incredibilmente potenti che un semplice VCS. Esploreremo alcuni benefici che ottieni pensando in questo modo ai tuoi dati vedremo le ramificazioni (i _branch_) in Git nel Capitolo 3.
+Questa è una distinzione importante tra Git e pressocché tutti gli altri VCS. Git riconsidera quasi tutti gli aspetti del controllo di versione che la maggior parte degli altri sistemi ha copiato dalle generazioni precedenti. Questo rende Git più simile a un mini filesystem con a disposizione strumenti incredibilmente potenti che un semplice VCS. Esploreremo alcuni benefici che ottieni pensando in questo modo ai tuoi dati e vedremo le ramificazioni (i _branch_) in Git nel Capitolo 3.
 
 ### Quasi Tutte le Operazioni Sono Locali ###
 
@@ -81,13 +81,13 @@ Questo significa anche che sono pochissime le cose che non puoi fare se sei offl
 
 ### Git Ha Integrità ###
 
-Qualsiasi cosa in Git è controllata, tramite checksum, prima di essere salvata ed è referenziata da un checksum. Questo significa che è impossibile cambiare il contenuto di qualsiasi file o directory senza che Git lo sappia. Questa è una funzionalità interna di basso livello di Git ed è intrinseco della sua filosofia. Non può capira che delle informazioni in transito si perdano o che un file si corrompa senza che Git non sia in grado di accorgersene.
+Qualsiasi cosa in Git è controllata, tramite checksum, prima di essere salvata ed è referenziata da un checksum. Questo significa che è impossibile cambiare il contenuto di qualsiasi file o directory senza che Git lo sappia. Questa è una funzionalità interna di basso livello di Git ed è intrinseco della sua filosofia. Non può capitare che delle informazioni in transito si perdano o che un file si corrompa senza che Git non sia in grado di accorgersene.
 
 Il meccanismo che Git usa per fare questo checksum è un hash chiamato SHA-1. Si tratta di una stringa di 40-caratteri, composta da caratteri esadecimali (0–9 ed a–f) e calcolata in base al contenuto di file o della struttura della directory in Git. Un hash SHA-1 assomiglia a qualcosa come:
 
 	24b9da6552252987aa493b52f8696cd6d3b00373
 
-Vedrai questi hash dappertutto in Git perché li usa tantissimo. Infatti Git salva qualsiasi cosa non in base al nome del file, ma nel suo database indirizzabile per l'hash del suo contenuto.
+Vedrai questi hash dappertutto in Git perché li usa tantissimo. Infatti Git salva qualsiasi cosa nel suo database, e il riferimento ad un file non è basato sul nome del file, ma sull'hash del suo contenuto.
 
 ### Git Generalmente Aggiunge Solo Dati ###
 
@@ -97,7 +97,7 @@ Questo rende piaceole l'uso di Git perché sappiamo che possiamo sperimentare se
 
 ### I Tre Stati ###
 
-Ora, presta attenzione. La prima cosa da ricordare sempre di Git se vuoi affrontare al meglio il processo di apprendimento. I tuoi file in Git possono essere in tre stati: _committed_ (committati), _modified_ (modificati) e _staged_ (in stage). Committato significa che il file è al sicuro nel database locale. Modificato significa che il file è stato modificato, ma non è ancora stato committato nel database. In stage significa che hai contrassegnato un file, modificato nella versione corrente, perché venga inserito nello snapshot alla prossima commit.
+Ora, presta attenzione. La prima cosa da ricordare sempre di Git se vuoi affrontare al meglio il processo di apprendimento è che i tuoi file in Git possono essere in tre stati: _committed_ (committati), _modified_ (modificati) e _staged_ (in stage). Committato significa che il file è al sicuro nel database locale. Modificato significa che il file è stato modificato, ma non è ancora stato committato nel database. In stage significa che hai contrassegnato un file, modificato nella versione corrente, perché venga inserito nello snapshot alla prossima commit.
 
 Questo ci porta alle tre sezioni principali di un progetto Git: la directory di Git, la directory di lavoro e l'area di stage.
 
@@ -113,8 +113,8 @@ L'area di stage è un file, contenuto generalmente nella directory di Git, con t
 Il flusso di lavoro (_workflow_) di base in Git funziona così:
 
 1. Modifica i file nella tua directory di lavoro
-2. Fanno lo stage, aggiungendone le istantanee all'area di stage
-3. Committa, che salva i file nell'area di stage in un'istantanea (_snapshot_) permanente nella tua directory di Git.
+2. Fanne lo stage, aggiungendone le istantanee all'area di stage
+3. Committa, ovvero salva i file nell'area di stage in un'istantanea (_snapshot_) permanente nella tua directory di Git.
 
 Se una particolare versione di un file è nella directory git, viene considerata già committata. Se il file è stato modificato, ma è stato aggiunto all'area di staging, è _in stage_. E se è stato modificato da quando è stata estratto, ma non è _in stage_, è modificato.  Nel Capitolo 2, imparerai di più su questi stati e come trarne vantaggio o saltare la parte di staging.
 

From 1b9f2649f922747ff7c8927b1274070afbcdb0ba Mon Sep 17 00:00:00 2001
From: proSoHard <freeman2234@gmail.com>
Date: Wed, 1 Oct 2014 14:12:15 +0700
Subject: [PATCH 647/690] Corrected: decimal, not hex

---
 en/09-git-internals/01-chapter9.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/en/09-git-internals/01-chapter9.markdown b/en/09-git-internals/01-chapter9.markdown
index 07101cddd..c64266683 100644
--- a/en/09-git-internals/01-chapter9.markdown
+++ b/en/09-git-internals/01-chapter9.markdown
@@ -718,7 +718,7 @@ For example, say you run `git push origin master` in your project, and `origin`
 
 The `git-receive-pack` command immediately responds with one line for each reference it currently has — in this case, just the `master` branch and its SHA. The first line also has a list of the server’s capabilities (here, `report-status` and `delete-refs`).
 
-Each line starts with a 4-byte hex value specifying how long the rest of the line is. Your first line starts with 005b, which is 91 in hex, meaning that 91 bytes remain on that line. The next line starts with 003e, which is 62, so you read the remaining 62 bytes. The next line is 0000, meaning the server is done with its references listing.
+Each line starts with a 4-byte hex value specifying how long the rest of the line is. Your first line starts with 005b, which is 91 in decimal, meaning that 91 bytes remain on that line. The next line starts with 003e, which is 62, so you read the remaining 62 bytes. The next line is 0000, meaning the server is done with its references listing.
 
 Now that it knows the server’s state, your `send-pack` process determines what commits it has that the server doesn’t. For each reference that this push will update, the `send-pack` process tells the `receive-pack` process that information. For instance, if you’re updating the `master` branch and adding an `experiment` branch, the `send-pack` response may look something like this:
 

From 1db3e3d817cb71eccc8c1ba9586357e4f2f04d96 Mon Sep 17 00:00:00 2001
From: proSoHard <freeman2234@gmail.com>
Date: Wed, 1 Oct 2014 11:48:57 +0700
Subject: [PATCH 648/690] Windows guide to make ebooks epub mobi

---
 README.md | 14 +++++++++++++-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/README.md b/README.md
index 0230cddf5..b6556fd75 100644
--- a/README.md
+++ b/README.md
@@ -22,7 +22,7 @@ On Fedora (16 and later) you can run something like this::
     $ yum install ruby calibre rubygems ruby-devel rubygem-ruby-debug rubygem-rdiscount
     $ makeebooks en  # will produce a mobi
 
-On MacOS you can do like this::
+On MacOS you can do like this:
 	
 1. INSTALL ruby and rubygems
 2. `$ gem install rdiscount`
@@ -31,6 +31,18 @@ On MacOS you can do like this::
     * xelatex: http://tug.org/mactex/
 4. `$ makeebooks zh` #will produce a mobi
 
+On Windows you can do like this:
+	
+1. Install ruby and related tool from http://rubyinstaller.org/downloads/
+    * RubyInstaller (ruby & gem)
+    * Development Kit (to build rdiscount gem)
+2. Open `cmd` and `$ gem install rdiscount`
+3. Install Calibre for Windows from http://calibre-ebook.com/download
+4. `$ SET ebook_convert_path=c:\Program Files\Calibre2\ebook-convert.exe`. Modify to suit with your Calibre installed path.
+5. Make ebooks:
+    * `$ ruby makeebooks vi` #will produce a mobi
+    * `$ SET FORMAT=epub` then `$ ruby makeebooks vi` #will produce an epub
+
 ## Notes on pandoc
 
 Please use Pandoc version 1.11.1 or later as older versions (confirmed on 1.9.1.1) has a [bug](https://github.com/jgm/pandoc/issues/964) which hides a word after tilde `~`.  You can do `pandoc -v` to see which version you have installed.

From 8b5b4cf8895d4028c088ef96ebe0106638f5036f Mon Sep 17 00:00:00 2001
From: Marco Buttu <marco.buttu@gmail.com>
Date: Fri, 3 Oct 2014 16:15:56 +0200
Subject: [PATCH 649/690] fixed some typos

---
 it/02-git-basics/01-chapter2.markdown | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/it/02-git-basics/01-chapter2.markdown b/it/02-git-basics/01-chapter2.markdown
index b3621e6f9..2c519d965 100644
--- a/it/02-git-basics/01-chapter2.markdown
+++ b/it/02-git-basics/01-chapter2.markdown
@@ -192,7 +192,7 @@ Il pattern `**/` è disponibile in Git dalla version 1.8.2.
 
 Se `git status` è troppo vago per te - vuoi sapere cos'è stato effettivamente modificato e non solo quali file — puoi usare il comando `git diff`. Tratteremo più avanti `git diff` con maggior dettaglio, ma probabilmente lo userai molto spesso per rispondere a queste due domande: Cos'è che hai modificato ma non è ancora in `stage`? E cos'hai nello `stage` che non hai ancora committato? Sebbene `git status` risponda a queste domande in modo generico, `git diff` mostra le righe effettivamente aggiunte e rimosse — la patch così com'è.
 
-Supponiamo che tu habbia modificato nuovamente `README` e `benchmarks.rb` ma messo nello `stage` solo il primo. Se esegui il comando `status`, vedrai qualcosa come questo:
+Supponiamo che tu abbia modificato nuovamente `README` e `benchmarks.rb` ma messo nello `stage` solo il primo. Se esegui il comando `status`, vedrai qualcosa come questo:
 
 	$ git status
 	On branch master
@@ -611,7 +611,7 @@ Queste sono solo alcune opzioni semplici per la formattazione dell'output di `gi
 
 <!-- Messaggio per i traduttori: questa è una tabella dichiarativa.
 Le righe devono essere formattate come segue:
-<TAB><Prima colonna di testo><TAB><Seconda colunna di testo>
+<TAB><Prima colonna di testo><TAB><Seconda colonna di testo>
 -->
 
 	Opzione	Descrizione
@@ -717,7 +717,7 @@ Ci sono circa 20,000 commit nella cronologia dei sorgenti di git, questo comando
 
 ### Usare una GUI per visualizzare la cronologia ###
 
-Se vuoi usare uno strumento più grafico per visualizzare la cronologia delle tuoe commit, puoi provare un programma in Tck/Tk chiamato `gitk` che viene distribuito con Git. Gitk è fondamentalmente uno strumento grafico come `git log`, e accetta quasi tutte le opzioni di filtro supportate da `git log`. Se digiti `gitk` dalla riga di comando nel tuo progetto, dovresti vedere qualcosa di simile alla Figura 2-2.
+Se vuoi usare uno strumento più grafico per visualizzare la cronologia delle tue commit, puoi provare un programma in Tck/Tk chiamato `gitk` che viene distribuito con Git. Gitk è fondamentalmente uno strumento grafico come `git log`, e accetta quasi tutte le opzioni di filtro supportate da `git log`. Se digiti `gitk` dalla riga di comando nel tuo progetto, dovresti vedere qualcosa di simile alla Figura 2-2.
 
 Insert 18333fig0202.png
 Figura 2-2. Il grafico della cronologia con gitk.
@@ -983,7 +983,7 @@ Creare un'etichetta annotate in Git è semplice. Il modo più facile è specific
 	v1.3
 	v1.4
 
-`-m` specifica il messaggio per l'etichetta, che viene salvato con l'a stessa. Se non specifichi un messaggio per un'etichetta annotata, Git lancerà il tuo editor così da scriverla.
+`-m` specifica il messaggio per l'etichetta, che viene salvato con la stessa. Se non specifichi un messaggio per un'etichetta annotata, Git lancerà il tuo editor così da scriverla.
 
 Puoi vedere i dati dell'etichetta assieme alla commit etichettata con il comando `git show`:
 
@@ -1059,7 +1059,7 @@ Se ora lanci `git show` per questa etichetta, non vedrai altre informazioni aggi
 
 ### Verificare le etichette ###
 
-Per verificarele un'etichetta firmata, usa `git tag -v [nome-tag]`. Questo comando usa GPG per verificare la verifica. Affinché funzioni hai bisogno che la chiave pubblica del firmatario sia nel tuo portachiavi:
+Per verificare un'etichetta firmata, usa `git tag -v [nome-tag]`. Questo comando usa GPG per verificare la verifica. Affinché funzioni hai bisogno che la chiave pubblica del firmatario sia nel tuo portachiavi:
 
 	$ git tag -v v1.4.2.1
 	object 883653babd8ee7ea23e6a5c392bb739348b1eb61
@@ -1162,7 +1162,7 @@ Se usi una shell Bash, Git fornisce uno script carino per il completamento autom
 
 	source ~/.git-completion.bash
 
-Se vuoi che Git usi il comletamento automatico in Bash per tutti gli utenti, copia lo script nella directory `/opt/local/etc/bash_completion.d` sui sistemi Mac o in `/etc/bash_completion.d/` sui sistemi Linux. Questa è una directory di script che Bash carica automaticamente, per fornire il completamento automatico nella shell.
+Se vuoi che Git usi il completamento automatico in Bash per tutti gli utenti, copia lo script nella directory `/opt/local/etc/bash_completion.d` sui sistemi Mac o in `/etc/bash_completion.d/` sui sistemi Linux. Questa è una directory di script che Bash carica automaticamente, per fornire il completamento automatico nella shell.
 
 Se stai usando Windows con Git Bash, che è il predefinito quando installi Git su Windows con msysGit, il completamento automatico dovrebbe essere preconfigurato.
 

From e431db502444441473b1be7ef8d02ca86c42a628 Mon Sep 17 00:00:00 2001
From: Marco Buttu <marco.buttu@gmail.com>
Date: Fri, 3 Oct 2014 16:56:29 +0200
Subject: [PATCH 650/690] other typos in git basics

---
 it/02-git-basics/01-chapter2.markdown | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/it/02-git-basics/01-chapter2.markdown b/it/02-git-basics/01-chapter2.markdown
index 2c519d965..c2512d22b 100644
--- a/it/02-git-basics/01-chapter2.markdown
+++ b/it/02-git-basics/01-chapter2.markdown
@@ -79,7 +79,7 @@ Per iniziare a tracciare un nuovo file, si usa il comando `git add`. Per traccia
 
 	$ git add README
 
-Se lanci nuovamente il comando per lo stato, puoi vedere il tuo file `README` ora è tracciato e nell'area si `stage`:
+Se lanci nuovamente il comando per lo stato, puoi vedere che il tuo file `README` ora è tracciato e nell'area di `stage`:
 
 	$ git status
 	On branch master
@@ -109,7 +109,7 @@ Modifichiamo un file che è già tracciato. Se modifichi un file tracciato chiam
 	        modified:   benchmarks.rb
 	
 
-Il file benchmarks.rb appare nella sezione chiamata "Changes not staged for commit" — che significa che un file tracciato è stato modificato nella directory di lavoro ma non è ancora nello stage. Per farlo, esegui il comando `git add` (è un comando multifunzione — lo usi per iniziare a tracciare nuovi file, per fare lo stage dei file e per fare altre cose segnare come risolti i conflitti causati da un `merge`). Esegui `git add` per mettere in `stage` il file benchmarks.rb, e riesegui `git status`:
+Il file benchmarks.rb appare nella sezione chiamata "Changes not staged for commit" — che significa che un file tracciato è stato modificato nella directory di lavoro ma non è ancora nello stage. Per farlo, esegui il comando `git add` (è un comando multifunzione — lo usi per iniziare a tracciare nuovi file, per fare lo stage dei file e per fare altre cose, ad esempio per segnare come risolti i conflitti causati da un `merge`). Esegui `git add` per mettere in `stage` il file benchmarks.rb, e riesegui `git status`:
 
 	$ git add benchmarks.rb
 	$ git status
@@ -139,7 +139,7 @@ Entrambi i file sono nello `stage` e staranno nella prossima commit. A questo pu
 	        modified:   benchmarks.rb
 	
 
-Cos'è successo? Ora `benchmarks.rb` è elencato sia dentro che fuori lo `stage`. Come è possibile? È saltato fuori che Git ha messo in `stage` il file esattamente com'era quando hai eseguito `git add`. Se committi ora, la versione di `benchmarks.rb` che verrà committata sarà quella che avevi quando hai eseguito il `git add`, non la versione del file che trovi nella directory di lavoro quando esegui `git commit`. Se modifichi un file dopo che hai eseguito `git add`, ridevi eseguire `git add` per mettere nello `stage` l'ultima versione del file:
+Cos'è successo? Ora `benchmarks.rb` è elencato sia dentro che fuori lo `stage`. Come è possibile? È saltato fuori che Git ha messo in `stage` il file esattamente com'era quando hai eseguito `git add`. Se committi ora, la versione di `benchmarks.rb` che verrà committata sarà quella che avevi quando hai eseguito il `git add`, non la versione del file che trovi nella directory di lavoro quando esegui `git commit`. Se modifichi un file dopo che hai eseguito `git add`, devi rieseguire `git add` per mettere nello `stage` l'ultima versione del file:
 
 	$ git add benchmarks.rb
 	$ git status
@@ -153,7 +153,7 @@ Cos'è successo? Ora `benchmarks.rb` è elencato sia dentro che fuori lo `stage`
 
 ### Ignorare File ###
 
-Spesso hai un tipo di file che non vuoi che Git li aggiunga automaticamente e nemmeno te li mostri come tracciati. Generalmente si tratta di file generati automaticamente, come i log o quelli prodotti dal tuoi sistema di `build`. In questi casi puoi creare un file chiamato `.gitignore` con la lista di pattern dei file che vuoi ignorare. Questo è un `.gitignore` d'esempio:
+Spesso hai dei file che non vuoi che Git aggiunga automaticamente e nemmeno che te li mostri come tracciati. Generalmente si tratta di file generati automaticamente, come i log o quelli prodotti dal tuoi sistema di `build`. In questi casi puoi creare un file chiamato `.gitignore` con la lista di pattern dei file che vuoi ignorare. Questo è un `.gitignore` d'esempio:
 
 	$ cat .gitignore
 	*.[oa]
@@ -170,7 +170,7 @@ Queste sono le regole per i pattern che puoi usare in `.gitignore`:
 
 I `glob pattern` sono come espressioni regolari semplificate, usate dalla shell. L'asterisco (`*`) corrisponde a zero o più caratteri; `[abc]` corrisponde a ogni carattere all'interno delle parentesi (in questo caso `a`, `b`, o `c`); il punto interrogativo (`?`) corrisponden ad un carattere singolo; e i caratteri all'interno delle parentesi quadre separati dal segno meno (`[0-9]`) corrispondono ad ogni carattere all'interno dell'intervallo (in questo caso da 0 a 9).
 
-Questo è un altro esempio di file .gitignore:
+Questo è un altro esempio di file `.gitignore`:
 
 	# un commento - questo è ignorato
 	# escludi i file .a

From 7cdcc04dcd312f4844fb7cec07be75e0df2f7a5c Mon Sep 17 00:00:00 2001
From: Southparkfan <Southparkfan@users.noreply.github.com>
Date: Tue, 7 Oct 2014 18:21:00 +0200
Subject: [PATCH 651/690] Spelling - locale -> lokale

---
 nl/04-git-server/01-chapter4.markdown | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/nl/04-git-server/01-chapter4.markdown b/nl/04-git-server/01-chapter4.markdown
index 1068d2e82..ab47353e7 100644
--- a/nl/04-git-server/01-chapter4.markdown
+++ b/nl/04-git-server/01-chapter4.markdown
@@ -450,7 +450,7 @@ Je bent nu klaar voor de start. Als je alles juist hebt ingesteld, kun je nu met
 
 Dat betekent dat Gitosis je herkend heeft, maar je buitensluit omdat je geen Git commando's aan het doen bent. Dus, laten we een echt Git commando doen; je gaat de Gitosis beheer repository clonen:
 
-	# op je locale computer
+	# op je lokale computer
 	$ git clone git@gitserver:gitosis-admin.git
 
 Nu heb je een directory genaamd `gitosis-admin`, die twee hoofd gedeeltes heeft:
@@ -493,7 +493,7 @@ Wanneer je wijzigingen aan het `gitosis-admin` project maakt, moet je de verande
 	To git@gitserver:gitosis-admin.git
 	   fb27aec..8962da8  master -> master
 
-Je kunt je eerste push naar het nieuwe `iphone_project` doen door je server als een remote aan je locale versie van je project toe te voegen en te pushen. Je hoeft geen bare repositories handmatig meer te maken voor nieuwe projecten op de server — Gitosis maakt ze automatisch als het de eerste push ziet:
+Je kunt je eerste push naar het nieuwe `iphone_project` doen door je server als een remote aan je lokale versie van je project toe te voegen en te pushen. Je hoeft geen bare repositories handmatig meer te maken voor nieuwe projecten op de server — Gitosis maakt ze automatisch als het de eerste push ziet:
 
 	$ git remote add origin git@gitserver:iphone_project.git
 	$ git push origin master

From 8583ee115684941ab3b749a1f84a041bf538d698 Mon Sep 17 00:00:00 2001
From: nesrinkalender <nesrin.kalender@nesrinkalender.local>
Date: Wed, 8 Oct 2014 12:02:16 +0300
Subject: [PATCH 652/690] 3. chapter Summary translated

---
 tr/03-git-branching/01-chapter3.markdown | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tr/03-git-branching/01-chapter3.markdown b/tr/03-git-branching/01-chapter3.markdown
index a9a150577..d8105b75d 100644
--- a/tr/03-git-branching/01-chapter3.markdown
+++ b/tr/03-git-branching/01-chapter3.markdown
@@ -593,6 +593,6 @@ You have to merge that work in at some point so you can keep up with the other d
 
 If you treat rebasing as a way to clean up and work with commits before you push them, and if you only rebase commits that have never been available publicly, then you’ll be fine. If you rebase commits that have already been pushed publicly, and people may have based work on those commits, then you may be in for some frustrating trouble.
 
-## Summary ##
+## Özet ##
 
-We’ve covered basic branching and merging in Git. You should feel comfortable creating and switching to new branches, switching between branches and merging local branches together.  You should also be able to share your branches by pushing them to a shared server, working with others on shared branches and rebasing your branches before they are shared.
+Git'in temel branch ve merge işlemlerinden bahsettik. Artık rahatça yeni branch oluşturabilir, branchler arasından geçiş yapabilir ve local branchler ile merge işlemi yapabilirsiniz. Aynı zamanda branchlerinizi paylaşılan bir sunucuya göndererek paylaşabilmelisiniz ya da başkalarıyla ortak branchlerde çalışabilmeli ve branchlerinizi paylaşmadan önce rebase edebilmelisiniz.

From 6f19538993ca43f5c06ba7e6865c3c4a862b45ee Mon Sep 17 00:00:00 2001
From: nesrinkalender <nesrin.kalender@nesrinkalender.local>
Date: Thu, 9 Oct 2014 15:50:14 +0300
Subject: [PATCH 653/690] Add 4. chapter and translate until The SSH Protocol

---
 tr/04-git-server/01-chapter4.markdown | 47 +++++++++++++++++++++++++++
 1 file changed, 47 insertions(+)
 create mode 100644 tr/04-git-server/01-chapter4.markdown

diff --git a/tr/04-git-server/01-chapter4.markdown b/tr/04-git-server/01-chapter4.markdown
new file mode 100644
index 000000000..77290b36a
--- /dev/null
+++ b/tr/04-git-server/01-chapter4.markdown
@@ -0,0 +1,47 @@
+# Uzak Serverda Git #
+
+Şu anda, Git kullanırken günlük ihtiyacınız olacak işleri yapabiliyor olmalısınız. Ancak, Git üzerinde takım arkadaşlarınızla işbirliğinde bulunmak için bir uzak Git reposuna ihtiyacınız var. Diğer insanların yerel repoları üzerinde pull ya da push işlemleri yapmanız teknik olarak mümkün olsa da, bunu yapmak cesurcadır çünkü dikkatli olmazsanız insanların çalışmalarını karman çorman etmek oldukça kolaydır. Bunun dışında, ulaşmak istediğiniz Git reposunun sahibi offline olsa da ulaşabileceğiniz ve doğruluğu daha güvenilir ortak bir repo genellikle kullanışlı bir seçenektir. Bunun için, takım arkadaşlarıyla işbirliğinde tercih edilen en yaygın yöntem, takımdaki insanların yazma ve okuma izinlerinin olduğu ortak bir repo kullanmaktır. Bu ortak repoya bundan sonra "Git Sunucusu" diyeceğiz. Fakat yakında farkedeceğiniz üzere Git çok az sistem kaynağı kullanır ve bunun için bütün bir sunucu kullanmaya genelde gerek olmaz.
+
+Bir Git Suncusu çalıştırmak kolaydır. Öncelikle, sunucunuzla hangi protokollerden iletişim kuracağınızı belirlemelisiniz. Bu bölümün ilk kısmında mevcut protokoller ve bunları artıları/eksilerinden bahsedeceğiz. Gelecek bölümlerde ise bu protokollerı kullanarak bazı tipik kurulumlarla sunucunuzu nasıl ayağa kaldıracağınızı anlatacağız. Son olarak, bazı hosted(3. kişiler tarafından barındırılan) servislerden bahsedeceğiz. Eger kodunuzun başka insanların sunucularında barınması sizin için problem değilse ve bakım-kurulum işleri ile uğraşmak istemiyorsanız bu seçenekleri de değerlendirebilirsiniz.
+
+Eğer kendi sunucunuzu kurmak ile ilgilenmiyorsanız, doğrudan bu bölümün son kısmına geçebilir ve kullanabileceğiniz bazı servisleri görebilirsiniz. Sonrasında dağıtık kaynak kontrol ortamlarında çalışmanın getiri ve götürülerinden bahsedeceğimiz bir sonraki bölüme geçebilirsiniz.
+
+Bir uzak repo _çıplak(bare) repo_ genellikle hiç bir şey eklenmemiş, boş bir haldedir. Repo yalnızca işbirliği noktası olarak kullanılacağından, projenin disk üzerinde bir kopyasını tutmak anlamsızdır. Yalnızca Git bilgisi yeterlidir. En basit anlatımıyla, çıplak repo projeinizin yalnızca `.git` klasörünü içerir.
+
+## Protokoller ##
+
+Git data transferi için başlıca dört adet ağ protokolü kullanır: Local, Secure Shell (SSH), Git and HTTP. Burada bu protokoller nedir ve temel koşullarda hangisini kullanmalıyız ya da kullanmamalıyoz tartışacağız.
+
+Burada önemli olarak HTTP protokolünü ayrı tutacağız, çünkü Git kurulan bütün serverlerda HTTP protokolü bulunması gerekir.
+
+### Lokal Protokoller ###
+
+En temel olanı, uzak reponun diskimizdeki başka bir klasör olduğu lokal protokoldür. Bu genellikle ekibinizdeki herkes NFS mount vb. şeklinde paylaşılan dosyalara erişiyorsa veya az kullanılan bir yöntem olarak; işler herkesin kullanıcı girişi yaptığı bir bilgisayar üzerinde yürütülüyorsa kullanılır. İkincisi ideal olmaz, çünkü tüm repoların aynı bilgisayarda bulunması bir kayıpta felaket olurdu.
+
+Eğer paylaşılan bir dosya sisteminiz varsa, local file-based reponuzdan clone,push ve pull işlemlerini yapabilirsiniz. Bunları yapmak için URL olarak reponuzun klasör yolunu kullanmalısınız. Örneğin, lokal repo kolanlayım, böyle bir komut çalıştırabilirsiniz.
+
+	$ git clone /opt/git/project.git
+
+Ya da:
+
+	$ git clone file:///opt/git/project.git
+
+Eğer URL'inizin başında açıkça `file://` belirtirseniz, Git biraz farklı çalışır. Sadece yolu belirtirseniz; ve kaynak ile hedef aynı dosya sisteminde ise, Git ihtiyacı olan objeleri hardlink ile bağlamaya çalışır. Eğer aynı dosya sisteminde değillerse; gerekli ihtiyacı olan dosyaları üzerinde bulunduğu sistemin standart kopyalama fonksiyonalitesini kullanarak kopyalayacaktır. Eğer `file://`ı belirtirseniz; Git normalde dosyaları transfer etmek için kullandığı ve daha verimsiz olan ağ üzerinden transfer yöntemini kullanmaz. `file://`ı belirtmenin ana sebebi genellikle başka bir versiyon kontrol sisteminden içe aktarma gibi işlemler yapıldıktan sonra (bakım işlemleri ile ilgili 9. bölümü inceleyin) yabancı referanslar ve kalıntı objeler içeren reponuzun temiz bir kopyasını almaktır. Biz daha hızlı olduğu için burada normal yolu kullanacağız.
+
+Varolan bir Git projesine lokal repo eklemek için aşağıdaki gibi bir kod çalıştırmalısınız;
+
+	$ git remote add local_proj /opt/git/project.git
+
+Sonra, bir network üzerinden yapıyormuşsunuz gibi o remote üzerinde pull ve push yapabilirsiz.
+
+#### Artıları ####
+
+File-based depoların artıları basit olmaları ile mevcut dosya izinlerini ve ağ erişimini kullanabilir olmasıdır. Eğer paylaşılan bir dosya sisteminiz varsa, ekibiniz için bir repo kurmak çok kolay bir işlemdir. Herhangi diğer bir paylaşılan klasörde yaptığınız gibi, herkesin paylaşılan izinlerinin olduğu bare repo kopyasında kalırsınız ve yazma/okuma izinlerini ayarlayabilirsiniz. Bir sonraki bölümde “Serverda Git.” bare reponun kopyasını nasıl export alırız ele alacağız.
+
+Bu aynı zamanda başkasının reposundan çalışmasını hızlıca almak için güzel bir seçenek. Eğer siz ve arkadaşınız aynı projede çalışıyorsanız onlar sizin yaptıklarınızı kontrol etmek isteyeceklerdir, bunun için `git pull /home/john/project` gibi bir komut çalıştırmak genellikle servera push etmek ve pull etmekten daha kolaydır.
+
+#### Eksileri ####
+
+Bu yöntemin eksileri genellikle paylaşılan erişimi kurmak ve bir çok yerden erişmek temel ağ erişiminden daha zordur. Eğer evinizdeki bilgisiyarınızdan uzak diskinize push etmek istiyorsanız ağ tabanlı erişim zor ve yavaş olabilir.
+
+Eğer siz paylaşılan bir disk kullanıyorsanız hızlı olmasından söz edemeyiz. Eğer verilere hızlı erişiminiz varsa lokal reponuz hızlıdır. Aynı sunucuda NFS üzerindeki bir repo ile aynı sunucuda SSH üzerinden erişilen bir repoya göre genellikle daha yavaştır.
\ No newline at end of file

From 9e060121abb6708a1e5b0f772cf7c5057de8a118 Mon Sep 17 00:00:00 2001
From: nesrinkalender <nesrin.kalender@nesrinkalender.local>
Date: Thu, 9 Oct 2014 17:54:00 +0300
Subject: [PATCH 654/690] Add 4. chapter all

---
 tr/04-git-server/01-chapter4.markdown | 821 +++++++++++++++++++++++++-
 1 file changed, 820 insertions(+), 1 deletion(-)

diff --git a/tr/04-git-server/01-chapter4.markdown b/tr/04-git-server/01-chapter4.markdown
index 77290b36a..5ff831afb 100644
--- a/tr/04-git-server/01-chapter4.markdown
+++ b/tr/04-git-server/01-chapter4.markdown
@@ -44,4 +44,823 @@ Bu aynı zamanda başkasının reposundan çalışmasını hızlıca almak için
 
 Bu yöntemin eksileri genellikle paylaşılan erişimi kurmak ve bir çok yerden erişmek temel ağ erişiminden daha zordur. Eğer evinizdeki bilgisiyarınızdan uzak diskinize push etmek istiyorsanız ağ tabanlı erişim zor ve yavaş olabilir.
 
-Eğer siz paylaşılan bir disk kullanıyorsanız hızlı olmasından söz edemeyiz. Eğer verilere hızlı erişiminiz varsa lokal reponuz hızlıdır. Aynı sunucuda NFS üzerindeki bir repo ile aynı sunucuda SSH üzerinden erişilen bir repoya göre genellikle daha yavaştır.
\ No newline at end of file
+Eğer siz paylaşılan bir disk kullanıyorsanız hızlı olmasından söz edemeyiz. Eğer verilere hızlı erişiminiz varsa lokal reponuz hızlıdır. Aynı sunucuda NFS üzerindeki bir repo ile aynı sunucuda SSH üzerinden erişilen bir repoya göre genellikle daha yavaştır.
+
+### SSH Protokolü ###
+
+Git için en yaygın transfer protokolü SSH'dır. Çünkü SSH erişimi zaten bir çok yerde kuruludur, eğer kurulu değilse de kurulumu gayet kolaydır. SSH yalnızca ağ tabanlı bir protokoldür  kolayca okuyabilir ve yazabilirsiniz. Diğer iki ağ protokolü (HTTP ve Git) genellikle sadece okunur, bundan dolayı bunlar dışarıya açık olsa bile, kendi komutlarını yazmak için hala SSH'a ihtiyacı vardır. SSH doğrulanmış bir ağ protokolüdür. Çünkü her yerde bulunur ayrıca kurulumu ve kullanımı kolaydır.
+
+Git reposunu SSH üzerinden clonelarken, URL'i ssh:// şeklinde belirtmelisiniz. Örnek:
+
+	$ git clone ssh://user@server/project.git
+
+Ya da SSH için kısaca scp-like yazımını kullanabilirsiniz:
+
+	$ git clone user@server:project.git
+
+Siz bir kullanıcı belirlemezseniz, Git geçerli oturum açmış olan kullanıcıyı varsayar.
+
+#### Artıları ####
+
+SSH kullanmanızın çok fazla artıları vardır. İlk olarak, temelde kullandığınız bir ağ üzerinden doğrulanmış bir kimlik ile dosyalara yazma erişiminiz olur. İkincisi, SSH kurmak kolaydır, birçok ağ yöneticileri SHH ile ilgili deneyime sahiptir ve birçok işletim sistemi dağıtımlarının SSH kurmak ve yönetmek için araçları vardır. Bir diğre SSH üzerinden tüm veri transferi şifrelenir ve doğrulanır. Last, like the Git and Local protocols, SSH is efficient, making the data as compact as possible before transferring it.
+
+#### Eksileri ####
+
+Negatif yönlerinden bir tanesi reponuza anonim erişim sağlanamaz. İnsanların sizin open source projenize erişebilmesi için SSH üzerinden erişimleri olması gerekmektedir. If you’re using it only within your corporate network, SSH may be the only protocol you need to deal with. Eğer bir projeye anonim erişimi vermek istiyorsanız push ve pull işlerimleri için SSH kurmanız gerekecektir.
+
+### Git Protokolü ###
+
+Sonraki Git Protokolüdür. Git ile paketlenmiş olarak gelen servistir. SSH protokolüne benzer bir hizmet sunar 9418 portunu dinler fakat kimlik doğrulaması gerektirmez. In order for a repository to be served over the Git protocol, you must create the `git-daemon-export-ok` file — the daemon won’t serve a repository without that file in it — but other than that there is no security. Either the Git repository is available for everyone to clone or it isn’t. This means that there is generally no pushing over this protocol. You can enable push access; but given the lack of authentication, if you turn on push access, anyone on the internet who finds your project’s URL could push to your project. Suffice it to say that this is rare.
+
+#### Artıları ####
+
+Git Protokol'ü mevcut en hızlı transfer protokolüdür. Eğer kimlik doğrulaması gerektirmeyen büyük bir projeniz varsa Git protokolü kullanmak doğru seçim olacaktır. Git Protokol'ü şifreleme ve kimlik doğrulama olmadan aynı mekanızmayı kullanır.
+
+#### Eksileri ####
+
+Git Protokolü'nün olumsuz yönlerinden bir tanesi doğrulama olmamasıdır. Projeye tek erişim olması istenmeyen bir durumdur. Genellik push (yazma) erişimine sahip geliştiriciler için SSH ile eşleştirme gerekir ve herkes  `git://` kullanır.
+Muhtemelen kurulumu en zor olan protokoldür. It must run its own daemon, which is custom — bu bölümün kurulumuna “Gitosis” kısmında değineceğiz — it requires `xinetd` configuration or the like, which isn’t always a walk in the park. 9418 portuna erişebilmek için bir güvenlik duvarı karşınıza çıkacaktır bu port genellikle izin verilen bir port değildir. Büyük kurumların arkasındaki firewall'lar genellikle bu portu tanımaz ve bloke ederler.
+
+### HTTP / S Protokolü ###
+
+Son olarak HTTP / S Protokolü. Kurulum basitliği açısından en güzeli HTTP ya da HTTPS protokolüdür. Basically, all you have to do is put the bare Git repository under your HTTP document root and set up a specific `post-update` hook, and you’re done (Git hook hakkında bilgi için 7. bölüme bakınız). At that point, anyone who can access the web server under which you put the repository can also clone your repository. HTTP üzerinden reponuza erişim izni vermek için:
+
+	$ cd /var/www/htdocs/
+	$ git clone --bare /path/to/git_project gitproject.git
+	$ cd gitproject.git
+	$ mv hooks/post-update.sample hooks/post-update
+	$ chmod a+x hooks/post-update
+
+That’s all. The `post-update` hook that comes with Git by default runs the appropriate command (`git update-server-info`) to make HTTP fetching and cloning work properly. SSH üzerinden bir repo pushlamak için bu komut çalıştırılır, ardından diğer insanlarda bu komut ile clonelayabilir.
+
+	$ git clone http://example.com/gitproject.git
+
+In this particular case, we’re using the `/var/www/htdocs` path that is common for Apache setups, but you can use any static web server — just put the bare repository in its path. Git verileri statik dosyalar olarak tutulur. (detaylar için bölüm 9'a bakınız).
+
+HTTP üzerinden push yapmak mümkündür, yaygın olarak kullanılan bir teknik değildir ve karışık WebDAV gereksinimleri kurmayı gerektirir. Nadiren kullanıldığı için kitapta yer almıyor. Eğer HTTP ile push yapmak ile ilgileniyorsanız konu ile ilgili `http://www.kernel.org/pub/software/scm/git/docs/howto/setup-git-server-over-http.txt` linkini inceleyebilirsiniz. Bir diğer nokta eğer sunucunuz yazma ve güncelleme işlemleri için WebDAV destekliyorsa, belirli Git özellikleri olmadan, herhangi bir WebDAV sunucusu kullanabilirsiniz;
+
+#### Artıları ####
+
+En temel artısı kurulumu kolaydır. Sunduğu bir çok komut ile  Git reponuza ulşamak için kolaylıklar sağlar. Ve bunu yapmak sadece birkaç dakika sürer. HTTP protokolü sunucunuz üzerinde bir yoğunluk yapmaz. Çünkü genellikle statik bir HTTP sunucusu kullanır, bir Apache server saniye binlerce dosya transfer edebilir fakat küçük sunucular için bu zor olabilir.
+
+You can also serve your repositories read-only over HTTPS, which means you can encrypt the content transfer; or you can go so far as to make the clients use specific signed SSL certificates. Generally, if you’re going to these lengths, it’s easier to use SSH public keys; but it may be a better solution in your specific case to use signed SSL certificates or other HTTP-based authentication methods for read-only access over HTTPS.
+
+Bir diğer güzel üzelliği de HTTP protokolü firewall tarafından tanınan yaygın bir protokoldür.
+
+#### Eksileri ####
+
+HTTP üzerinden reponuz için hizmet almanızın olumsuz yanı verimsiz olmasıdır. Genellikle klonlama işlemleri uzun sürer ve diğer ağ protokollerinden daha fazla ağ hacmi vardır. Because it’s not as intelligent about transferring only the data you need — there is no dynamic work on the part of the server in these transactions — the HTTP protocol is often referred to as a _dumb_ protocol. HTTP protokolü ve diğer protokoller hakkında verimlilik karşılaştırmaları için bölüm )'a bakınız.
+
+## Server'da Git ##
+
+Başlangıçta bir Git serverını ayarlamak için; varolan bir  repoyu henuz hiç bir şey içermeyen, yeni bir repoya aktarmalısnız. 
+Yeni bir boş repo oluşturmak için, `--bare` seçeneği ile komutu çalıştırın. 
+
+	$ git clone --bare my_project my_project.git
+	Cloning into bare repository 'my_project.git'...
+	done.
+
+Şuan  `my_project.git` dizininde Git dizinin bir kopyası bulunmaktadır.
+
+Bu komutta aynı işlemi yapar
+
+	$ cp -Rf my_project/.git my_project.git
+
+Configrasyon dosyamızda birkaç küçük farklılık vardır; but for your purpose, this is close to the same thing. Bir çalışma dizini olmadan kendi başına Git deposunu alır, ve yalnız bunun için özel bir dizin oluşturur.
+
+### Server'a Boş Bir Dizin Oluşturmak ###
+
+Elimizde bol bir dizinimiz var, tüm yapmamız gereken bunu server'a koymak ve protokol ayarlarını yapmak. SSH erişimi olan ve `git.example.com` adında bir server kurduğumuzu varsayalım, ve `/opt/git` dizini altında tüm depolarımızı saklayalım. Boş reponuzu kopyalayarak yeni repo oluşturabilirsiniz:
+
+	$ scp -r my_project.git user@git.example.com:/opt/git
+
+Bu noktada `/opt/git` dizinine okuma ve SSH erişimi olan kullanıcılar aşağıdaki komut ile reponuzu klonlayabilir
+
+	$ git clone user@git.example.com:/opt/git/my_project.git
+
+Bir kullanıcnın server içinde SSHs ve `/opt/git/my_project.git` dizinine yazma erişimi varsa, otomatik olarak push yapma izni olacaktır. Eğer `git init` komutunu `--shared` seçeneği ile çalıştırırsanız Git uygun olarak izinleri verecektir.
+
+	$ ssh user@git.example.com
+	$ cd /opt/git/my_project.git
+	$ git init --bare --shared
+
+Git üzerinde boş bir repo oluşturmak ve SSH izinleri vermenin ne kadar kolay olduğunu gördünüz. Şimdi projelerde birlikte çalışabilirsiniz.
+
+It’s important to note that this is literally all you need to do to run a useful Git server to which several people have access — just add SSH-able accounts on a server, and stick a bare repository somewhere that all those users have read and write access to. You’re ready to go — nothing else needed.
+
+Önümüzdeki bölümlerde, daha sofistike kurulumları göreceğiz. Bunlar kullanıcı izinleri, web UI kurmak, Gitosis aracını kullanarak ve daha fazla, her kullanıcı için kullanıcı hesapları oluşturmak zorunda değiliz gibi konular. However, keep in mind that to collaborate with a couple of people on a private project, all you _need_ is an SSH server and a bare repository.
+
+### Küçük Ayarlar ###
+
+Eğer kuruluşunuza Git ile çalışıyorsanız ve birkaç developer varsa bu işler sizin için kolay olabilir. Bir Git sunucusu kurmanın en karmaşık yönlerinden biri, kullanıcı yönetimidir. Bazı repolar için belirli kullanıcılara okuma bazılarına okuma/yazma erişimi vermek istiyorsanız izinleri düzenlemek zor olabilir.
+
+#### SSH Erişimi ####
+
+Eğer mevcut server'ınıza tüm developerların SSH erişimi var ise ilk repo kurulumu için pek bir iş yapmanız gerekmiyor (son bolumde bahsettiğimiz gibi). Eğer daha complex erişim izinleri istiyorsanız, sunucuda çalışan işletim sisteminin normal dosya sistemi izinleri ile düzenleyebilirsiniz.
+
+If you want to place your repositories on a server that doesn’t have accounts for everyone on your team whom you want to have write access, o zaman onlar için SSH erişimi kurmanız gerekiyor. Biz bunu yapmak için SSH sunucusunun yüklü olduğu bir sunucunuz varsayalım.
+
+Takımdaki herkese erişim vermenin birkaç yolu vardır. İlki basittir ama biraz zahmetli olabilir, herkes için bir hesap oluşturmak. `adduser` çalıştırmak ve her kullanıcı için geçici parolalar oluşturmak istemeyebilirsiniz..
+
+İkinci method tek bir 'git' kullanıcısı oluşturmak, ask every user who is to have write access to send you an SSH public key, and add that key to the `~/.ssh/authorized_keys` file of your new 'git' user. Bu noktada, herkes 'git' kullanıcısı ile bu makineye erişebilecek. This doesn’t affect the commit data in any way — the SSH user you connect as doesn’t affect the commits you’ve recorded.
+
+Bunu yapmanın bir başka yolu, bir LDAP sunucusuna veya zaten kurdunuz bazı diğer merkezi kimlik doğrulama kaynağından SSH sunucusu kimlik doğrulamasına sahip olmaktır. Böylece her kullanıcı makine üzerinden shell erişimi alabilir.
+
+## SSH Key Oluşturmak ##
+
+Git serverlerda kimlik doğrulaması için SSH public keys kullanıyor. Eğer oluşturulmuş yoksa her kullanıcı için sistem bir key oluşturur. İlk olarak hazırda bir key var mı kontrol edilir. Varsayılan olarak, bir kullanıcının SSH anahtarları o kullanıcının ~ /. ssh dizininde depolanır. Eğer oluşturulmuş bir key varsa onu kolayca listeleyebilirsiniz.
+
+	$ cd ~/.ssh
+	$ ls
+	authorized_keys2  id_dsa       known_hosts
+	config            id_dsa.pub
+
+Dosyalarına baktığında iki şey arıyoruz something and something.pub, burada genellikle bir şey `id_dsa` or `id_rsa`.  `.pub` dosya ortak anahtardır, ve diğer dosyaların özel anahtarıdır. Eğer bu dosyalar yok ise (or you don’t even have a `.ssh` directory), `ssh-keygen` ile bu dosyaları oluşturabilirsiniz, Linux/Mac sistemlerinde SSH paketi Windows MSysGit paketi ile geliyor:
+ 
+	$ ssh-keygen
+	Generating public/private rsa key pair.
+	Enter file in which to save the key (/Users/schacon/.ssh/id_rsa):
+	Enter passphrase (empty for no passphrase):
+	Enter same passphrase again:
+	Your identification has been saved in /Users/schacon/.ssh/id_rsa.
+	Your public key has been saved in /Users/schacon/.ssh/id_rsa.pub.
+	The key fingerprint is:
+	43:c5:5b:5f:b1:f1:50:43:ad:20:a6:92:6a:1f:9a:3a schacon@agadorlaptop.local
+
+Eğer anahtarı kaydetmek isterseniz (`.ssh/id_rsa`) önce kaydetmek istediğiniz yeri sorar, ve sonra iki kez parolanızı sorar, eğer parolanızı yazmak istemiyorsanız boş geçin.
+
+Now, each user that does this has to send their public key to you or whoever is administrating the Git server (assuming you’re using an SSH server setup that requires public keys). Yapmaları gereken `.pub` dosyasının ve içeriğini kopyalamak olduğunu bunu e-posta atmak. Örnek public key:
+
+	$ cat ~/.ssh/id_rsa.pub
+	ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAklOUpkDHrfHY17SbrmTIpNLTGK9Tjom/BWDSU
+	GPl+nafzlHDTYW7hdI4yZ5ew18JH4JW9jbhUFrviQzM7xlELEVf4h9lFX5QVkbPppSwg0cda3
+	Pbv7kOdJ/MTyBlWXFCR+HAo3FXRitBqxiX1nKhXpHAZsMciLq8V6RjsNAQwdsdMFvSlVK/7XA
+	t3FaoJoAsncM1Q9x5+3V0Ww68/eIFmb1zuUFljQJKprrX88XypNDvjYNby6vw/Pb0rwert/En
+	mZ+AW4OZPnTPI89ZPmVMLuayrD2cE86Z/il8b+gw3r3+1nKatmIkjn2so1d01QraTlMqVSsbx
+	NrRFi9wrf+M7Q== schacon@agadorlaptop.local
+
+Birden fazla işletim sistemlerinde SSH key oluşturma ile ilgili kapsamlı bilgi için bknz: Github klavuzu SSH keys http://github.com/guides/providing-your-ssh-key.
+
+## Sunucu Kurma ##
+
+Şimdi baştan sona adım adım sunucu tarafına SSH erişimi kuralım. Bu örnekte, kullanıcılarınızı doğrulamak için `authorized_keys` methodu kullanacağız. Ayrıca Ubuntu gibi standart bir Linux dağıtımı kullanıyoruz varsayacağız. Öncelikle, bir 'git' kullanıcı ve bu kullanıcı için bir `.ssh` dizin oluşturun.
+
+	$ sudo adduser git
+	$ su git
+	$ cd
+	$ mkdir .ssh
+
+Sonra, you need to add some developer SSH public keys to the `authorized_keys` file for that user. Let’s assume you’ve received a few keys by e-mail and saved them to temporary files. Yine, public keyimiz aşağıdaki gibi olacaktır:
+
+	$ cat /tmp/id_rsa.john.pub
+	ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCB007n/ww+ouN4gSLKssMxXnBOvf9LGt4L
+	ojG6rs6hPB09j9R/T17/x4lhJA0F3FR1rP6kYBRsWj2aThGw6HXLm9/5zytK6Ztg3RPKK+4k
+	Yjh6541NYsnEAZuXz0jTTyAUfrtU3Z5E003C4oxOj6H0rfIF1kKI9MAQLMdpGW1GYEIgS9Ez
+	Sdfd8AcCIicTDWbqLAcU4UpkaX8KyGlLwsNuuGztobF8m72ALC/nLF6JLtPofwFBlgc+myiv
+	O7TCUSBdLQlgMVOFq1I2uPWQOkOWQAHukEOmfjy2jctxSDBQ220ymjaNsHT4kgtZg2AYYgPq
+	dAv8JggJICUvax2T9va5 gsg-keypair
+
+Sizin  `authorized_keys` dosyanıza sadece bunlar eklenecek:
+
+	$ cat /tmp/id_rsa.john.pub >> ~/.ssh/authorized_keys
+	$ cat /tmp/id_rsa.josie.pub >> ~/.ssh/authorized_keys
+	$ cat /tmp/id_rsa.jessica.pub >> ~/.ssh/authorized_keys
+
+Şimdi,boş bir repository oluşturmak için  `git init` komutunu `--bare` özelliği ile çalıştırın, which initializes the repository without a working directory:
+
+	$ cd /opt/git
+	$ mkdir project.git
+	$ cd project.git
+	$ git --bare init
+
+Sonra, John, Josie, or Jessica can push the first version of their project into that repository by adding it as a remote and pushing up a branch. Note that someone must shell onto the machine and create a bare repository every time you want to add a project. Let’s use `gitserver` as the hostname of the server on which you’ve set up your 'git' user and repository. If you’re running it internally, and you set up DNS for `gitserver` to point to that server, then you can use the commands pretty much as is:
+
+	# on Johns computer
+	$ cd myproject
+	$ git init
+	$ git add .
+	$ git commit -m 'initial commit'
+	$ git remote add origin git@gitserver:/opt/git/project.git
+	$ git push origin master
+
+Bu noktada, yapılan değişiklikler kolayca yedeklenir:
+
+	$ git clone git@gitserver:/opt/git/project.git
+	$ cd project
+	$ vim README
+	$ git commit -am 'fix for the README file'
+	$ git push origin master
+
+Bu method ile, kolayca Git server üzerinde okuma/yazma yapabilirsiniz.
+
+As an extra precaution, you can easily restrict the 'git' user to only doing Git activities with a limited shell tool called `git-shell` that comes with Git. If you set this as your 'git' user’s login shell, then the 'git' user can’t have normal shell access to your server. To use this, specify `git-shell` instead of bash or csh for your user’s login shell. To do so, you’ll likely have to edit your `/etc/passwd` file:
+
+	$ sudo vim /etc/passwd
+
+Alt kısımda bu şekilde bir çıktı görmelisiniz:
+
+	git:x:1000:1000::/home/git:/bin/sh
+
+Change `/bin/sh` to `/usr/bin/git-shell` (or run `which git-shell` to see where it’s installed). Satırınız böyle görünmelidir:
+
+	git:x:1000:1000::/home/git:/usr/bin/git-shell
+
+Şimdi, the 'git' user can only use the SSH connection to push and pull Git repositories and can’t shell onto the machine. If you try, you’ll see a login rejection like this:
+
+	$ ssh git@gitserver
+	fatal: What do you think I am? A shell?
+	Connection to gitserver closed.
+
+## Genel Erişim ##
+
+Peki projenize anonim olarak erişmek isterseniz? Perhaps instead of hosting an internal private project, you want to host an open source project. Or maybe you have a bunch of automated build servers or continuous integration servers that change a lot, and you don’t want to have to generate SSH keys all the time — you just want to add simple anonymous read access.
+
+Probably the simplest way for smaller setups is to run a static web server with its document root where your Git repositories are, and then enable that `post-update` hook we mentioned in the first section of this chapter. Let’s work from the previous example. Say you have your repositories in the `/opt/git` directory, and an Apache server is running on your machine. Again, you can use any web server for this; but as an example, we’ll demonstrate some basic Apache configurations that should give you an idea of what you might need.
+
+Öncelikle hook'u etkinleştirmemiz gerekiyor:
+
+	$ cd project.git
+	$ mv hooks/post-update.sample hooks/post-update
+	$ chmod a+x hooks/post-update
+
+Peki bu `post-update` hook ne yapar? Temelde şunları yapar:
+
+	$ cat .git/hooks/post-update
+	#!/bin/sh
+	#
+	# An example hook script to prepare a packed repository for use over
+	# dumb transports.
+	#
+	# To enable this hook, rename this file to "post-update".
+	#
+
+	exec git-update-server-info
+
+Bu SSH üzerinden sunucuya push yaptığınızda, Git HTTP almak için gereken dosyaları günceleyecek ve bu komutu çalıştıracak.
+
+Daha sonra, Apache sunucumuza VirtualHost girişi ekmemiz gerekecek. Here, we’re assuming that you have wildcard DNS set up to send `*.gitserver` to whatever box you’re using to run all this:
+
+	<VirtualHost *:80>
+	    ServerName git.gitserver
+	    DocumentRoot /opt/git
+	    <Directory /opt/git/>
+	        Order allow, deny
+	        allow from all
+	    </Directory>
+	</VirtualHost>
+
+You’ll also need to set the Unix user group of the `/opt/git` directories to `www-data` so your web server can read-access the repositories, çünkü CGI komut dosyası çalıştıran Apache örneği (varsayılan) kullanıcı olarak çalışıyor olacak.
+
+	$ chgrp -R www-data /opt/git
+
+Apache'yi yeniden başlattığınızda, sizin projeniz dizininizin altında oluşan URL ile clonelanabilir:
+
+	$ git clone http://git.gitserver/project.git
+
+This way, you can set up HTTP-based read access to any of your projects for a fair number of users in a few minutes. Another simple option for public unauthenticated access is to start a Git daemon, although that requires you to daemonize the process - we’ll cover this option in the next section, if you prefer that route.
+
+## GitWeb ##
+
+Now that you have basic read/write and read-only access to your project, you may want to set up a simple web-based visualizer. Git comes with a CGI script called GitWeb that is commonly used for this. You can see GitWeb in use at sites like `http://git.kernel.org` (see Figure 4-1).
+
+Insert 18333fig0401.png
+Figure 4-1. The GitWeb web-based user interface.
+
+If you want to check out what GitWeb would look like for your project, Git comes with a command to fire up a temporary instance if you have a lightweight server on your system like `lighttpd` or `webrick`. On Linux machines, `lighttpd` is often installed, so you may be able to get it to run by typing `git instaweb` in your project directory. If you’re running a Mac, Leopard comes preinstalled with Ruby, so `webrick` may be your best bet. To start `instaweb` with a non-lighttpd handler, you can run it with the `--httpd` option.
+
+	$ git instaweb --httpd=webrick
+	[2009-02-21 10:02:21] INFO  WEBrick 1.3.1
+	[2009-02-21 10:02:21] INFO  ruby 1.8.6 (2008-03-03) [universal-darwin9.0]
+
+That starts up an HTTPD server on port 1234 and then automatically starts a web browser that opens on that page. It’s pretty easy on your part. When you’re done and want to shut down the server, you can run the same command with the `--stop` option:
+
+	$ git instaweb --httpd=webrick --stop
+
+If you want to run the web interface on a server all the time for your team or for an open source project you’re hosting, you’ll need to set up the CGI script to be served by your normal web server. Some Linux distributions have a `gitweb` package that you may be able to install via `apt` or `yum`, so you may want to try that first. We’ll walk though installing GitWeb manually very quickly. First, you need to get the Git source code, which GitWeb comes with, and generate the custom CGI script:
+
+	$ git clone git://git.kernel.org/pub/scm/git/git.git
+	$ cd git/
+	$ make GITWEB_PROJECTROOT="/opt/git" \
+	        prefix=/usr gitweb
+	$ sudo cp -Rf gitweb /var/www/
+
+Notice that you have to tell the command where to find your Git repositories with the `GITWEB_PROJECTROOT` variable. Now, you need to make Apache use CGI for that script, for which you can add a VirtualHost:
+
+	<VirtualHost *:80>
+	    ServerName gitserver
+	    DocumentRoot /var/www/gitweb
+	    <Directory /var/www/gitweb>
+	        Options ExecCGI +FollowSymLinks +SymLinksIfOwnerMatch
+	        AllowOverride All
+	        order allow,deny
+	        Allow from all
+	        AddHandler cgi-script cgi
+	        DirectoryIndex gitweb.cgi
+	    </Directory>
+	</VirtualHost>
+
+Again, GitWeb can be served with any CGI capable web server; if you prefer to use something else, it shouldn’t be difficult to set up. At this point, you should be able to visit `http://gitserver/` to view your repositories online, and you can use `http://git.gitserver` to clone and fetch your repositories over HTTP.
+
+## Gitosis ##
+
+Keeping all users’ public keys in the `authorized_keys` file for access works well only for a while. When you have hundreds of users, it’s much more of a pain to manage that process. You have to shell onto the server each time, and there is no access control — everyone in the file has read and write access to every project.
+
+At this point, you may want to turn to a widely used software project called Gitosis. Gitosis is basically a set of scripts that help you manage the `authorized_keys` file as well as implement some simple access controls. The really interesting part is that the UI for this tool for adding people and determining access isn’t a web interface but a special Git repository. You set up the information in that project; and when you push it, Gitosis reconfigures the server based on that, which is cool.
+
+Installing Gitosis isn’t the simplest task ever, but it’s not too difficult. It’s easiest to use a Linux server for it — these examples use a stock Ubuntu 8.10 server.
+
+Gitosis requires some Python tools, so first you have to install the Python setuptools package, which Ubuntu provides as python-setuptools:
+
+	$ apt-get install python-setuptools
+
+Next, you clone and install Gitosis from the project’s main site:
+
+	$ git clone https://github.com/tv42/gitosis.git
+	$ cd gitosis
+	$ sudo python setup.py install
+
+That installs a couple of executables that Gitosis will use. Next, Gitosis wants to put its repositories under `/home/git`, which is fine. But you have already set up your repositories in `/opt/git`, so instead of reconfiguring everything, you create a symlink:
+
+	$ ln -s /opt/git /home/git/repositories
+
+Gitosis is going to manage your keys for you, so you need to remove the current file, re-add the keys later, and let Gitosis control the `authorized_keys` file automatically. For now, move the `authorized_keys` file out of the way:
+
+	$ mv /home/git/.ssh/authorized_keys /home/git/.ssh/ak.bak
+
+Next you need to turn your shell back on for the 'git' user, if you changed it to the `git-shell` command. People still won’t be able to log in, but Gitosis will control that for you. So, let’s change this line in your `/etc/passwd` file
+
+	git:x:1000:1000::/home/git:/usr/bin/git-shell
+
+back to this:
+
+	git:x:1000:1000::/home/git:/bin/sh
+
+Now it’s time to initialize Gitosis. You do this by running the `gitosis-init` command with your personal public key. If your public key isn’t on the server, you’ll have to copy it there:
+
+	$ sudo -H -u git gitosis-init < /tmp/id_dsa.pub
+	Initialized empty Git repository in /opt/git/gitosis-admin.git/
+	Reinitialized existing Git repository in /opt/git/gitosis-admin.git/
+
+This lets the user with that key modify the main Git repository that controls the Gitosis setup. Next, you have to manually set the execute bit on the `post-update` script for your new control repository.
+
+	$ sudo chmod 755 /opt/git/gitosis-admin.git/hooks/post-update
+
+You’re ready to roll. If you’re set up correctly, you can try to SSH into your server as the user for which you added the public key to initialize Gitosis. You should see something like this:
+
+	$ ssh git@gitserver
+	PTY allocation request failed on channel 0
+	ERROR:gitosis.serve.main:Need SSH_ORIGINAL_COMMAND in environment.
+	  Connection to gitserver closed.
+
+That means Gitosis recognized you but shut you out because you’re not trying to do any Git commands. So, let’s do an actual Git command — you’ll clone the Gitosis control repository:
+
+	# on your local computer
+	$ git clone git@gitserver:gitosis-admin.git
+
+Now you have a directory named `gitosis-admin`, which has two major parts:
+
+	$ cd gitosis-admin
+	$ find .
+	./gitosis.conf
+	./keydir
+	./keydir/scott.pub
+
+The `gitosis.conf` file is the control file you use to specify users, repositories, and permissions. The `keydir` directory is where you store the public keys of all the users who have any sort of access to your repositories — one file per user. The name of the file in `keydir` (in the previous example, `scott.pub`) will be different for you — Gitosis takes that name from the description at the end of the public key that was imported with the `gitosis-init` script.
+
+If you look at the `gitosis.conf` file, it should only specify information about the `gitosis-admin` project that you just cloned:
+
+	$ cat gitosis.conf
+	[gitosis]
+
+	[group gitosis-admin]
+	members = scott
+	writable = gitosis-admin
+
+It shows you that the 'scott' user — the user with whose public key you initialized Gitosis — is the only one who has access to the `gitosis-admin` project.
+
+Now, let’s add a new project for you. You’ll add a new section called `mobile` where you’ll list the developers on your mobile team and projects that those developers need access to. Because 'scott' is the only user in the system right now, you’ll add him as the only member, and you’ll create a new project called `iphone_project` to start on:
+
+	[group mobile]
+	members = scott
+	writable = iphone_project
+
+Whenever you make changes to the `gitosis-admin` project, you have to commit the changes and push them back up to the server in order for them to take effect:
+
+	$ git commit -am 'add iphone_project and mobile group'
+	[master 8962da8] add iphone_project and mobile group
+	 1 file changed, 4 insertions(+)
+	$ git push origin master
+	Counting objects: 5, done.
+	Compressing objects: 100% (3/3), done.
+	Writing objects: 100% (3/3), 272 bytes | 0 bytes/s, done.
+	Total 3 (delta 0), reused 0 (delta 0)
+	To git@gitserver:gitosis-admin.git
+	   fb27aec..8962da8  master -> master
+
+You can make your first push to the new `iphone_project` project by adding your server as a remote to your local version of the project and pushing. You no longer have to manually create a bare repository for new projects on the server — Gitosis creates them automatically when it sees the first push:
+
+	$ git remote add origin git@gitserver:iphone_project.git
+	$ git push origin master
+	Initialized empty Git repository in /opt/git/iphone_project.git/
+	Counting objects: 3, done.
+	Writing objects: 100% (3/3), 230 bytes | 0 bytes/s, done.
+	Total 3 (delta 0), reused 0 (delta 0)
+	To git@gitserver:iphone_project.git
+	 * [new branch]      master -> master
+
+Notice that you don’t need to specify the path (in fact, doing so won’t work), just a colon and then the name of the project — Gitosis finds it for you.
+
+You want to work on this project with your friends, so you’ll have to re-add their public keys. But instead of appending them manually to the `~/.ssh/authorized_keys` file on your server, you’ll add them, one key per file, into the `keydir` directory. How you name the keys determines how you refer to the users in the `gitosis.conf` file. Let’s re-add the public keys for John, Josie, and Jessica:
+
+	$ cp /tmp/id_rsa.john.pub keydir/john.pub
+	$ cp /tmp/id_rsa.josie.pub keydir/josie.pub
+	$ cp /tmp/id_rsa.jessica.pub keydir/jessica.pub
+
+Now you can add them all to your 'mobile' team so they have read and write access to `iphone_project`:
+
+	[group mobile]
+	members = scott john josie jessica
+	writable = iphone_project
+
+After you commit and push that change, all four users will be able to read from and write to that project.
+
+Gitosis has simple access controls as well. If you want John to have only read access to this project, you can do this instead:
+
+	[group mobile]
+	members = scott josie jessica
+	writable = iphone_project
+
+	[group mobile_ro]
+	members = john
+	readonly = iphone_project
+
+Now John can clone the project and get updates, but Gitosis won’t allow him to push back up to the project. You can create as many of these groups as you want, each containing different users and projects. You can also specify another group as one of the members (using `@` as prefix), to inherit all of its members automatically:
+
+	[group mobile_committers]
+	members = scott josie jessica
+
+	[group mobile]
+	members   = @mobile_committers
+	writable  = iphone_project
+
+	[group mobile_2]
+	members   = @mobile_committers john
+	writable  = another_iphone_project
+
+If you have any issues, it may be useful to add `loglevel=DEBUG` under the `[gitosis]` section. If you’ve lost push access by pushing a messed-up configuration, you can manually fix the file on the server under `/home/git/.gitosis.conf` — the file from which Gitosis reads its info. A push to the project takes the `gitosis.conf` file you just pushed up and sticks it there. If you edit that file manually, it remains like that until the next successful push to the `gitosis-admin` project.
+
+## Gitolite ##
+
+This section serves as a quick introduction to Gitolite, and provides basic installation and setup instructions.  It cannot, however, replace the enormous amount of [documentation][gltoc] that Gitolite comes with.  There may also be occasional changes to this section itself, so you may also want to look at the latest version [here][gldpg].
+
+[gldpg]: http://sitaramc.github.com/gitolite/progit.html
+[gltoc]: http://sitaramc.github.com/gitolite/master-toc.html
+
+Gitolite is an authorization layer on top of Git, relying on `sshd` or `httpd` for authentication.  (Recap: authentication is identifying who the user is, authorization is deciding if he is allowed to do what he is attempting to).
+
+Gitolite allows you to specify permissions not just by repository, but also by branch or tag names within each repository.  That is, you can specify that certain people (or groups of people) can only push certain "refs" (branches or tags) but not others.
+
+### Installing ###
+
+Installing Gitolite is very easy, even if you don’t read the extensive documentation that comes with it.  You need an account on a Unix server of some kind.  You do not need root access, assuming Git, Perl, and an OpenSSH compatible SSH server are already installed.  In the examples below, we will use the `git` account on a host called `gitserver`.
+
+Gitolite is somewhat unusual as far as "server" software goes — access is via SSH, and so every userid on the server is a potential "gitolite host".  We will describe the simplest install method in this article; for the other methods please see the documentation.
+
+To begin, create a user called `git` on your server and login to this user.  Copy your SSH public key (a file called `~/.ssh/id_rsa.pub` if you did a plain `ssh-keygen` with all the defaults) from your workstation, renaming it to `<yourname>.pub` (we'll use `scott.pub` in our examples).  Then run these commands:
+
+	$ git clone git://github.com/sitaramc/gitolite
+	$ gitolite/install -ln
+	    # assumes $HOME/bin exists and is in your $PATH
+	$ gitolite setup -pk $HOME/scott.pub
+
+That last command creates new Git repository called `gitolite-admin` on the server.
+
+Finally, back on your workstation, run `git clone git@gitserver:gitolite-admin`. And you’re done!  Gitolite has now been installed on the server, and you now have a brand new repository called `gitolite-admin` in your workstation.  You administer your Gitolite setup by making changes to this repository and pushing.
+
+### Customising the Install ###
+
+While the default, quick, install works for most people, there are some ways to customise the install if you need to.  Some changes can be made simply by editing the rc file, but if that is not sufficient, there’s documentation on customising Gitolite.
+
+### Config File and Access Control Rules ###
+
+Once the install is done, you switch to the `gitolite-admin` clone you just made on your workstation, and poke around to see what you got:
+
+	$ cd ~/gitolite-admin/
+	$ ls
+	conf/  keydir/
+	$ find conf keydir -type f
+	conf/gitolite.conf
+	keydir/scott.pub
+	$ cat conf/gitolite.conf
+
+	repo gitolite-admin
+	    RW+                 = scott
+
+	repo testing
+	    RW+                 = @all
+
+Notice that "scott" (the name of the pubkey in the `gitolite setup` command you used earlier) has read-write permissions on the `gitolite-admin` repository as well as a public key file of the same name.
+
+Adding users is easy.  To add a user called "alice", obtain her public key, name it `alice.pub`, and put it in the `keydir` directory of the clone of the `gitolite-admin` repo you just made on your workstation.  Add, commit, and push the change, and the user has been added.
+
+The config file syntax for Gitolite is well documented, so we’ll only mention some highlights here.
+
+You can group users or repos for convenience.  The group names are just like macros; when defining them, it doesn’t even matter whether they are projects or users; that distinction is only made when you *use* the "macro".
+
+	@oss_repos      = linux perl rakudo git gitolite
+	@secret_repos   = fenestra pear
+
+	@admins         = scott
+	@interns        = ashok
+	@engineers      = sitaram dilbert wally alice
+	@staff          = @admins @engineers @interns
+
+You can control permissions at the "ref" level.  In the following example, interns can only push the "int" branch.  Engineers can push any branch whose name starts with "eng-", and tags that start with "rc" followed by a digit.  And the admins can do anything (including rewind) to any ref.
+
+	repo @oss_repos
+	    RW  int$                = @interns
+	    RW  eng-                = @engineers
+	    RW  refs/tags/rc[0-9]   = @engineers
+	    RW+                     = @admins
+
+The expression after the `RW` or `RW+` is a regular expression (regex) that the refname (ref) being pushed is matched against.  So we call it a "refex"!  Of course, a refex can be far more powerful than shown here, so don’t overdo it if you’re not comfortable with Perl regexes.
+
+Also, as you probably guessed, Gitolite prefixes `refs/heads/` as a syntactic convenience if the refex does not begin with `refs/`.
+
+An important feature of the config file’s syntax is that all the rules for a repository need not be in one place.  You can keep all the common stuff together, like the rules for all `oss_repos` shown above, then add specific rules for specific cases later on, like so:
+
+	repo gitolite
+	    RW+                     = sitaram
+
+That rule will just get added to the ruleset for the `gitolite` repository.
+
+At this point you might be wondering how the access control rules are actually applied, so let’s go over that briefly.
+
+There are two levels of access control in Gitolite.  The first is at the repository level; if you have read (or write) access to *any* ref in the repository, then you have read (or write) access to the repository.  This is the only access control that Gitosis had.
+
+The second level, applicable only to "write" access, is by branch or tag within a repository.  The username, the access being attempted (`W` or `+`), and the refname being updated are known.  The access rules are checked in order of appearance in the config file, looking for a match for this combination (but remember that the refname is regex-matched, not merely string-matched).  If a match is found, the push succeeds.  A fallthrough results in access being denied.
+
+### Advanced Access Control with "deny" rules ###
+
+So far, we’ve only seen permissions to be one of `R`, `RW`, or `RW+`.  However, Gitolite allows another permission: `-`, standing for "deny".  This gives you a lot more power, at the expense of some complexity, because now fallthrough is not the *only* way for access to be denied, so the *order of the rules now matters*!
+
+Let us say, in the situation above, we want engineers to be able to rewind any branch *except* master and integ.  Here’s how to do that:
+
+	    RW  master integ    = @engineers
+	    -   master integ    = @engineers
+	    RW+                 = @engineers
+
+Again, you simply follow the rules top down until you hit a match for your access mode, or a deny.  Non-rewind push to master or integ is allowed by the first rule.  A rewind push to those refs does not match the first rule, drops down to the second, and is therefore denied.  Any push (rewind or non-rewind) to refs other than master or integ won’t match the first two rules anyway, and the third rule allows it.
+
+### Restricting pushes by files changed ###
+
+In addition to restricting what branches a user can push changes to, you can also restrict what files they are allowed to touch.  For example, perhaps the Makefile (or some other program) is really not supposed to be changed by just anyone, because a lot of things depend on it or would break if the changes are not done *just right*.  You can tell Gitolite:
+
+    repo foo
+        RW                      =   @junior_devs @senior_devs
+
+        -   VREF/NAME/Makefile  =   @junior_devs
+
+Users who are migrating from the older Gitolite should note that there is a significant change in behaviour with regard to this feature; please see the migration guide for details.
+
+### Personal Branches ###
+
+Gitolite also has a feature called "personal branches" (or rather, "personal branch namespace") that can be very useful in a corporate environment.
+
+A lot of code exchange in the Git world happens by "please pull" requests.  In a corporate environment, however, unauthenticated access is a no-no, and a developer workstation cannot do authentication, so you have to push to the central server and ask someone to pull from there.
+
+This would normally cause the same branch name clutter as in a centralised VCS, plus setting up permissions for this becomes a chore for the admin.
+
+Gitolite lets you define a "personal" or "scratch" namespace prefix for each developer (for example, `refs/personal/<devname>/*`); please see the documentation for details.
+
+### "Wildcard" repositories ###
+
+Gitolite allows you to specify repositories with wildcards (actually Perl regexes), like, for example `assignments/s[0-9][0-9]/a[0-9][0-9]`, to pick a random example.  It also allows you to assign a new permission mode (`C`) which enables users to create repositories based on such wild cards, automatically assigns ownership to the specific user who created it, allows him/her to hand out `R` and `RW` permissions to other users to collaborate, etc.  Again, please see the documentation for details.
+
+### Other Features ###
+
+We’ll round off this discussion with a sampling of other features, all of which, and many more, are described in great detail in the documentation.
+
+**Logging**: Gitolite logs all successful accesses.  If you were somewhat relaxed about giving people rewind permissions (`RW+`) and some kid blew away `master`, the log file is a life saver, in terms of easily and quickly finding the SHA that got hosed.
+
+**Access rights reporting**: Another convenient feature is what happens when you try and just ssh to the server.  Gitolite shows you what repos you have access to, and what that access may be.  Here’s an example:
+
+        hello scott, this is git@git running gitolite3 v3.01-18-g9609868 on git 1.7.4.4
+
+             R     anu-wsd
+             R     entrans
+             R  W  git-notes
+             R  W  gitolite
+             R  W  gitolite-admin
+             R     indic_web_input
+             R     shreelipi_converter
+
+**Delegation**: For really large installations, you can delegate responsibility for groups of repositories to various people and have them manage those pieces independently.  This reduces the load on the main admin, and makes him less of a bottleneck.
+
+**Mirroring**: Gitolite can help you maintain multiple mirrors, and switch between them easily if the primary server goes down.
+
+## Git Daemon ##
+
+For public, unauthenticated read access to your projects, you’ll want to move past the HTTP protocol and start using the Git protocol. The main reason is speed. The Git protocol is far more efficient and thus faster than the HTTP protocol, so using it will save your users time.
+
+Again, this is for unauthenticated read-only access. If you’re running this on a server outside your firewall, it should only be used for projects that are publicly visible to the world. If the server you’re running it on is inside your firewall, you might use it for projects that a large number of people or computers (continuous integration or build servers) have read-only access to, when you don’t want to have to add an SSH key for each.
+
+In any case, the Git protocol is relatively easy to set up. Basically, you need to run this command in a daemonized manner:
+
+	git daemon --reuseaddr --base-path=/opt/git/ /opt/git/
+
+`--reuseaddr` allows the server to restart without waiting for old connections to time out, the `--base-path` option allows people to clone projects without specifying the entire path, and the path at the end tells the Git daemon where to look for repositories to export. If you’re running a firewall, you’ll also need to punch a hole in it at port 9418 on the box you’re setting this up on.
+
+You can daemonize this process a number of ways, depending on the operating system you’re running. On an Ubuntu machine, you use an Upstart script. So, in the following file
+
+	/etc/event.d/local-git-daemon
+
+you put this script:
+
+	start on startup
+	stop on shutdown
+	exec /usr/bin/git daemon \
+	    --user=git --group=git \
+	    --reuseaddr \
+	    --base-path=/opt/git/ \
+	    /opt/git/
+	respawn
+
+For security reasons, it is strongly encouraged to have this daemon run as a user with read-only permissions to the repositories — you can easily do this by creating a new user 'git-ro' and running the daemon as them.  For the sake of simplicity we’ll simply run it as the same 'git' user that Gitosis is running as.
+
+When you restart your machine, your Git daemon will start automatically and respawn if it goes down. To get it running without having to reboot, you can run this:
+
+	initctl start local-git-daemon
+
+On other systems, you may want to use `xinetd`, a script in your `sysvinit` system, or something else — as long as you get that command daemonized and watched somehow.
+
+Next, you have to tell your Gitosis server which repositories to allow unauthenticated Git server-based access to. If you add a section for each repository, you can specify the ones from which you want your Git daemon to allow reading. If you want to allow Git protocol access for the `iphone_project`, you add this to the end of the `gitosis.conf` file:
+
+	[repo iphone_project]
+	daemon = yes
+
+When that is committed and pushed up, your running daemon should start serving requests for the project to anyone who has access to port 9418 on your server.
+
+If you decide not to use Gitosis, but you want to set up a Git daemon, you’ll have to run this on each project you want the Git daemon to serve:
+
+	$ cd /path/to/project.git
+	$ touch git-daemon-export-ok
+
+The presence of that file tells Git that it’s OK to serve this project without authentication.
+
+Gitosis can also control which projects GitWeb shows. First, you need to add something like the following to the `/etc/gitweb.conf` file:
+
+	$projects_list = "/home/git/gitosis/projects.list";
+	$projectroot = "/home/git/repositories";
+	$export_ok = "git-daemon-export-ok";
+	@git_base_url_list = ('git://gitserver');
+
+You can control which projects GitWeb lets users browse by adding or removing a `gitweb` setting in the Gitosis configuration file. For instance, if you want the `iphone_project` to show up on GitWeb, you make the `repo` setting look like this:
+
+	[repo iphone_project]
+	daemon = yes
+	gitweb = yes
+
+Now, if you commit and push the project, GitWeb will automatically start showing the `iphone_project`.
+
+## Hosted Git ##
+
+If you don’t want to go through all of the work involved in setting up your own Git server, you have several options for hosting your Git projects on an external dedicated hosting site. Doing so offers a number of advantages: a hosting site is generally quick to set up and easy to start projects on, and no server maintenance or monitoring is involved. Even if you set up and run your own server internally, you may still want to use a public hosting site for your open source code — it’s generally easier for the open source community to find and help you with.
+
+These days, you have a huge number of hosting options to choose from, each with different advantages and disadvantages. To see an up-to-date list, check out the following page:
+
+	https://git.wiki.kernel.org/index.php/GitHosting
+
+Because we can’t cover all of them, and because I happen to work at one of them, we’ll use this section to walk through setting up an account and creating a new project at GitHub. This will give you an idea of what is involved.
+
+GitHub is by far the largest open source Git hosting site and it’s also one of the very few that offers both public and private hosting options so you can keep your open source and private commercial code in the same place. In fact, we used GitHub to privately collaborate on this book.
+
+### GitHub ###
+
+GitHub is slightly different than most code-hosting sites in the way that it namespaces projects. Instead of being primarily based on the project, GitHub is user centric. That means when I host my `grit` project on GitHub, you won’t find it at `github.com/grit` but instead at `github.com/schacon/grit`. There is no canonical version of any project, which allows a project to move from one user to another seamlessly if the first author abandons the project.
+
+GitHub is also a commercial company that charges for accounts that maintain private repositories, but anyone can quickly get a free account to host as many open source projects as they want. We’ll quickly go over how that is done.
+
+### Setting Up a User Account ###
+
+The first thing you need to do is set up a free user account. If you visit the Pricing and Signup page at `http://github.com/plans` and click the "Sign Up" button on the Free account (see Figure 4-2), you’re taken to the signup page.
+
+Insert 18333fig0402.png
+Figure 4-2. The GitHub plan page.
+
+Here you must choose a username that isn’t yet taken in the system and enter an e-mail address that will be associated with the account and a password (see Figure 4-3).
+
+Insert 18333fig0403.png
+Figure 4-3. The GitHub user signup form.
+
+If you have it available, this is a good time to add your public SSH key as well. We covered how to generate a new key earlier, in the "Simple Setups" section. Take the contents of the public key of that pair, and paste it into the SSH Public Key text box. Clicking the "explain ssh keys" link takes you to detailed instructions on how to do so on all major operating systems.
+Clicking the "I agree, sign me up" button takes you to your new user dashboard (see Figure 4-4).
+
+Insert 18333fig0404.png
+Figure 4-4. The GitHub user dashboard.
+
+Next you can create a new repository.
+
+### Creating a New Repository ###
+
+Start by clicking the "create a new one" link next to Your Repositories on the user dashboard. You’re taken to the Create a New Repository form (see Figure 4-5).
+
+Insert 18333fig0405.png
+Figure 4-5. Creating a new repository on GitHub.
+
+All you really have to do is provide a project name, but you can also add a description. When that is done, click the "Create Repository" button. Now you have a new repository on GitHub (see Figure 4-6).
+
+Insert 18333fig0406.png
+Figure 4-6. GitHub project header information.
+
+Since you have no code there yet, GitHub will show you instructions for how create a brand-new project, push an existing Git project up, or import a project from a public Subversion repository (see Figure 4-7).
+
+Insert 18333fig0407.png
+Figure 4-7. Instructions for a new repository.
+
+These instructions are similar to what we’ve already gone over. To initialize a project if it isn’t already a Git project, you use
+
+	$ git init
+	$ git add .
+	$ git commit -m 'initial commit'
+
+When you have a Git repository locally, add GitHub as a remote and push up your master branch:
+
+	$ git remote add origin git@github.com:testinguser/iphone_project.git
+	$ git push origin master
+
+Now your project is hosted on GitHub, and you can give the URL to anyone you want to share your project with. In this case, it’s `http://github.com/testinguser/iphone_project`. You can also see from the header on each of your project’s pages that you have two Git URLs (see Figure 4-8).
+
+Insert 18333fig0408.png
+Figure 4-8. Project header with a public URL and a private URL.
+
+The Public Clone URL is a public, read-only Git URL over which anyone can clone the project. Feel free to give out that URL and post it on your web site or what have you.
+
+The Your Clone URL is a read/write SSH-based URL that you can read or write over only if you connect with the SSH private key associated with the public key you uploaded for your user. When other users visit this project page, they won’t see that URL—only the public one.
+
+### Importing from Subversion ###
+
+If you have an existing public Subversion project that you want to import into Git, GitHub can often do that for you. At the bottom of the instructions page is a link to a Subversion import. If you click it, you see a form with information about the import process and a text box where you can paste in the URL of your public Subversion project (see Figure 4-9).
+
+Insert 18333fig0409.png
+Figure 4-9. Subversion importing interface.
+
+If your project is very large, nonstandard, or private, this process probably won’t work for you. In Chapter 7, you’ll learn how to do more complicated manual project imports.
+
+### Adding Collaborators ###
+
+Let’s add the rest of the team. If John, Josie, and Jessica all sign up for accounts on GitHub, and you want to give them push access to your repository, you can add them to your project as collaborators. Doing so will allow pushes from their public keys to work.
+
+Click the "edit" button in the project header or the Admin tab at the top of the project to reach the Admin page of your GitHub project (see Figure 4-10).
+
+Insert 18333fig0410.png
+Figure 4-10. GitHub administration page.
+
+To give another user write access to your project, click the “Add another collaborator” link. A new text box appears, into which you can type a username. As you type, a helper pops up, showing you possible username matches. When you find the correct user, click the Add button to add that user as a collaborator on your project (see Figure 4-11).
+
+Insert 18333fig0411.png
+Figure 4-11. Adding a collaborator to your project.
+
+When you’re finished adding collaborators, you should see a list of them in the Repository Collaborators box (see Figure 4-12).
+
+Insert 18333fig0412.png
+Figure 4-12. A list of collaborators on your project.
+
+If you need to revoke access to individuals, you can click the "revoke" link, and their push access will be removed. For future projects, you can also copy collaborator groups by copying the permissions of an existing project.
+
+### Your Project ###
+
+After you push your project up or have it imported from Subversion, you have a main project page that looks something like Figure 4-13.
+
+Insert 18333fig0413.png
+Figure 4-13. A GitHub main project page.
+
+When people visit your project, they see this page. It contains tabs to different aspects of your projects. The Commits tab shows a list of commits in reverse chronological order, similar to the output of the `git log` command. The Network tab shows all the people who have forked your project and contributed back. The Downloads tab allows you to upload project binaries and link to tarballs and zipped versions of any tagged points in your project. The Wiki tab provides a wiki where you can write documentation or other information about your project. The Graphs tab has some contribution visualizations and statistics about your project. The main Source tab that you land on shows your project’s main directory listing and automatically renders the README file below it if you have one. This tab also shows a box with the latest commit information.
+
+### Projeleri Forklamak ###
+
+If you want to contribute to an existing project to which you don’t have push access, GitHub encourages forking the project. When you land on a project page that looks interesting and you want to hack on it a bit, you can click the "fork" button in the project header to have GitHub copy that project to your user so you can push to it.
+
+This way, projects don’t have to worry about adding users as collaborators to give them push access. People can fork a project and push to it, and the main project maintainer can pull in those changes by adding them as remotes and merging in their work.
+
+To fork a project, visit the project page (in this case, mojombo/chronic) and click the "fork" button in the header (see Figure 4-14).
+
+Insert 18333fig0414.png
+Figure 4-14. Get a writable copy of any repository by clicking the "fork" button.
+
+After a few seconds, you’re taken to your new project page, which indicates that this project is a fork of another one (see Figure 4-15).
+
+Insert 18333fig0415.png
+Figure 4-15. Your fork of a project.
+
+### GitHub Özeti ###
+
+That’s all we’ll cover about GitHub, but it’s important to note how quickly you can do all this. You can create an account, add a new project, and push to it in a matter of minutes. If your project is open source, you also get a huge community of developers who now have visibility into your project and may well fork it and help contribute to it. At the very least, this may be a way to get up and running with Git and try it out quickly.
+
+## Özet ##
+
+You have several options to get a remote Git repository up and running so that you can collaborate with others or share your work.
+
+Running your own server gives you a lot of control and allows you to run the server within your own firewall, but such a server generally requires a fair amount of your time to set up and maintain. If you place your data on a hosted server, it’s easy to set up and maintain; however, you have to be able to keep your code on someone else’s servers, and some organizations don’t allow that.
+
+It should be fairly straightforward to determine which solution or combination of solutions is appropriate for you and your organization.

From b1758890ccbafbe26f79b3b45b9fe1c1f69f9e15 Mon Sep 17 00:00:00 2001
From: nesrinkalender <nesrin.kalender@nesrinkalender.local>
Date: Fri, 10 Oct 2014 17:54:31 +0300
Subject: [PATCH 655/690] update SSH Protocol

---
 tr/04-git-server/01-chapter4.markdown | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/tr/04-git-server/01-chapter4.markdown b/tr/04-git-server/01-chapter4.markdown
index 5ff831afb..7308fc4aa 100644
--- a/tr/04-git-server/01-chapter4.markdown
+++ b/tr/04-git-server/01-chapter4.markdown
@@ -48,7 +48,7 @@ Eğer siz paylaşılan bir disk kullanıyorsanız hızlı olmasından söz edeme
 
 ### SSH Protokolü ###
 
-Git için en yaygın transfer protokolü SSH'dır. Çünkü SSH erişimi zaten bir çok yerde kuruludur, eğer kurulu değilse de kurulumu gayet kolaydır. SSH yalnızca ağ tabanlı bir protokoldür  kolayca okuyabilir ve yazabilirsiniz. Diğer iki ağ protokolü (HTTP ve Git) genellikle sadece okunur, bundan dolayı bunlar dışarıya açık olsa bile, kendi komutlarını yazmak için hala SSH'a ihtiyacı vardır. SSH doğrulanmış bir ağ protokolüdür. Çünkü her yerde bulunur ayrıca kurulumu ve kullanımı kolaydır.
+Git için en yaygın transfer protokolü SSH'dır. Çünkü SSH erişimi zaten bir çok yerde kuruludur, eğer kurulu değilse de kurulumu gayet kolaydır. SSH yalnızca ağ tabanlı bir protokoldür kolayca okuyabilir ve yazabilirsiniz. Diğer iki ağ protokolü (HTTP ve Git) genellikle sadece okunur, bundan dolayı bunlar dışarıya açık olsa bile, kendi komutlarını yazmak için hala SSH'a ihtiyacı vardır. SSH doğrulanmış bir ağ protokolüdür. Çünkü her yerde bulunur ayrıca kurulumu ve kullanımı kolaydır.
 
 Git reposunu SSH üzerinden clonelarken, URL'i ssh:// şeklinde belirtmelisiniz. Örnek:
 
@@ -62,11 +62,11 @@ Siz bir kullanıcı belirlemezseniz, Git geçerli oturum açmış olan kullanıc
 
 #### Artıları ####
 
-SSH kullanmanızın çok fazla artıları vardır. İlk olarak, temelde kullandığınız bir ağ üzerinden doğrulanmış bir kimlik ile dosyalara yazma erişiminiz olur. İkincisi, SSH kurmak kolaydır, birçok ağ yöneticileri SHH ile ilgili deneyime sahiptir ve birçok işletim sistemi dağıtımlarının SSH kurmak ve yönetmek için araçları vardır. Bir diğre SSH üzerinden tüm veri transferi şifrelenir ve doğrulanır. Last, like the Git and Local protocols, SSH is efficient, making the data as compact as possible before transferring it.
+SSH kullanmanızın çok fazla artıları vardır. İlk olarak, temelde kullandığınız bir ağ üzerinden doğrulanmış bir kimlik ile dosyalara yazma erişiminiz olur. İkincisi, SSH kurmak kolaydır, birçok ağ yöneticileri SHH ile ilgili deneyime sahiptir ve birçok işletim sistemi dağıtımlarının SSH kurmak ve yönetmek için araçları vardır. Bir diğeri SSH üzerinden tüm veri transferi şifrelenir ve doğrulanır. Son olarak SSH'ın bir artısı da verileri akatarmadan önce mümkün olduğunca kompakt hale getiriyor.
 
 #### Eksileri ####
 
-Negatif yönlerinden bir tanesi reponuza anonim erişim sağlanamaz. İnsanların sizin open source projenize erişebilmesi için SSH üzerinden erişimleri olması gerekmektedir. If you’re using it only within your corporate network, SSH may be the only protocol you need to deal with. Eğer bir projeye anonim erişimi vermek istiyorsanız push ve pull işlerimleri için SSH kurmanız gerekecektir.
+Negatif yönlerinden bir tanesi reponuza anonim erişim sağlanamaz. İnsanların sizin open source projenize erişebilmesi için SSH üzerinden erişimleri olması gerekmektedir.Yalnızca kurumsal ağ içerisinde bunu kullanıyorsanız SSH kullanmanız gereken protokollerden belki de tekidir. Eğer bir projeye anonim erişimi vermek istiyorsanız push ve pull işlerimleri için SSH kurmanız gerekecektir.
 
 ### Git Protokolü ###
 

From 11b94e362231f6a76a6eeadd6092660866bdb7a4 Mon Sep 17 00:00:00 2001
From: nesrinkalender <nesrin.kalender@nesrinkalender.local>
Date: Mon, 13 Oct 2014 14:10:48 +0300
Subject: [PATCH 656/690] add chapter 5 and translate until Commit Guideline

---
 tr/04-git-server/01-chapter4.markdown      | 795 +--------------------
 tr/05-distributed-git/01-chapter5.markdown | 215 ++++++
 2 files changed, 216 insertions(+), 794 deletions(-)
 create mode 100644 tr/05-distributed-git/01-chapter5.markdown

diff --git a/tr/04-git-server/01-chapter4.markdown b/tr/04-git-server/01-chapter4.markdown
index 7308fc4aa..a291eeba0 100644
--- a/tr/04-git-server/01-chapter4.markdown
+++ b/tr/04-git-server/01-chapter4.markdown
@@ -70,797 +70,4 @@ Negatif yönlerinden bir tanesi reponuza anonim erişim sağlanamaz. İnsanları
 
 ### Git Protokolü ###
 
-Sonraki Git Protokolüdür. Git ile paketlenmiş olarak gelen servistir. SSH protokolüne benzer bir hizmet sunar 9418 portunu dinler fakat kimlik doğrulaması gerektirmez. In order for a repository to be served over the Git protocol, you must create the `git-daemon-export-ok` file — the daemon won’t serve a repository without that file in it — but other than that there is no security. Either the Git repository is available for everyone to clone or it isn’t. This means that there is generally no pushing over this protocol. You can enable push access; but given the lack of authentication, if you turn on push access, anyone on the internet who finds your project’s URL could push to your project. Suffice it to say that this is rare.
-
-#### Artıları ####
-
-Git Protokol'ü mevcut en hızlı transfer protokolüdür. Eğer kimlik doğrulaması gerektirmeyen büyük bir projeniz varsa Git protokolü kullanmak doğru seçim olacaktır. Git Protokol'ü şifreleme ve kimlik doğrulama olmadan aynı mekanızmayı kullanır.
-
-#### Eksileri ####
-
-Git Protokolü'nün olumsuz yönlerinden bir tanesi doğrulama olmamasıdır. Projeye tek erişim olması istenmeyen bir durumdur. Genellik push (yazma) erişimine sahip geliştiriciler için SSH ile eşleştirme gerekir ve herkes  `git://` kullanır.
-Muhtemelen kurulumu en zor olan protokoldür. It must run its own daemon, which is custom — bu bölümün kurulumuna “Gitosis” kısmında değineceğiz — it requires `xinetd` configuration or the like, which isn’t always a walk in the park. 9418 portuna erişebilmek için bir güvenlik duvarı karşınıza çıkacaktır bu port genellikle izin verilen bir port değildir. Büyük kurumların arkasındaki firewall'lar genellikle bu portu tanımaz ve bloke ederler.
-
-### HTTP / S Protokolü ###
-
-Son olarak HTTP / S Protokolü. Kurulum basitliği açısından en güzeli HTTP ya da HTTPS protokolüdür. Basically, all you have to do is put the bare Git repository under your HTTP document root and set up a specific `post-update` hook, and you’re done (Git hook hakkında bilgi için 7. bölüme bakınız). At that point, anyone who can access the web server under which you put the repository can also clone your repository. HTTP üzerinden reponuza erişim izni vermek için:
-
-	$ cd /var/www/htdocs/
-	$ git clone --bare /path/to/git_project gitproject.git
-	$ cd gitproject.git
-	$ mv hooks/post-update.sample hooks/post-update
-	$ chmod a+x hooks/post-update
-
-That’s all. The `post-update` hook that comes with Git by default runs the appropriate command (`git update-server-info`) to make HTTP fetching and cloning work properly. SSH üzerinden bir repo pushlamak için bu komut çalıştırılır, ardından diğer insanlarda bu komut ile clonelayabilir.
-
-	$ git clone http://example.com/gitproject.git
-
-In this particular case, we’re using the `/var/www/htdocs` path that is common for Apache setups, but you can use any static web server — just put the bare repository in its path. Git verileri statik dosyalar olarak tutulur. (detaylar için bölüm 9'a bakınız).
-
-HTTP üzerinden push yapmak mümkündür, yaygın olarak kullanılan bir teknik değildir ve karışık WebDAV gereksinimleri kurmayı gerektirir. Nadiren kullanıldığı için kitapta yer almıyor. Eğer HTTP ile push yapmak ile ilgileniyorsanız konu ile ilgili `http://www.kernel.org/pub/software/scm/git/docs/howto/setup-git-server-over-http.txt` linkini inceleyebilirsiniz. Bir diğer nokta eğer sunucunuz yazma ve güncelleme işlemleri için WebDAV destekliyorsa, belirli Git özellikleri olmadan, herhangi bir WebDAV sunucusu kullanabilirsiniz;
-
-#### Artıları ####
-
-En temel artısı kurulumu kolaydır. Sunduğu bir çok komut ile  Git reponuza ulşamak için kolaylıklar sağlar. Ve bunu yapmak sadece birkaç dakika sürer. HTTP protokolü sunucunuz üzerinde bir yoğunluk yapmaz. Çünkü genellikle statik bir HTTP sunucusu kullanır, bir Apache server saniye binlerce dosya transfer edebilir fakat küçük sunucular için bu zor olabilir.
-
-You can also serve your repositories read-only over HTTPS, which means you can encrypt the content transfer; or you can go so far as to make the clients use specific signed SSL certificates. Generally, if you’re going to these lengths, it’s easier to use SSH public keys; but it may be a better solution in your specific case to use signed SSL certificates or other HTTP-based authentication methods for read-only access over HTTPS.
-
-Bir diğer güzel üzelliği de HTTP protokolü firewall tarafından tanınan yaygın bir protokoldür.
-
-#### Eksileri ####
-
-HTTP üzerinden reponuz için hizmet almanızın olumsuz yanı verimsiz olmasıdır. Genellikle klonlama işlemleri uzun sürer ve diğer ağ protokollerinden daha fazla ağ hacmi vardır. Because it’s not as intelligent about transferring only the data you need — there is no dynamic work on the part of the server in these transactions — the HTTP protocol is often referred to as a _dumb_ protocol. HTTP protokolü ve diğer protokoller hakkında verimlilik karşılaştırmaları için bölüm )'a bakınız.
-
-## Server'da Git ##
-
-Başlangıçta bir Git serverını ayarlamak için; varolan bir  repoyu henuz hiç bir şey içermeyen, yeni bir repoya aktarmalısnız. 
-Yeni bir boş repo oluşturmak için, `--bare` seçeneği ile komutu çalıştırın. 
-
-	$ git clone --bare my_project my_project.git
-	Cloning into bare repository 'my_project.git'...
-	done.
-
-Şuan  `my_project.git` dizininde Git dizinin bir kopyası bulunmaktadır.
-
-Bu komutta aynı işlemi yapar
-
-	$ cp -Rf my_project/.git my_project.git
-
-Configrasyon dosyamızda birkaç küçük farklılık vardır; but for your purpose, this is close to the same thing. Bir çalışma dizini olmadan kendi başına Git deposunu alır, ve yalnız bunun için özel bir dizin oluşturur.
-
-### Server'a Boş Bir Dizin Oluşturmak ###
-
-Elimizde bol bir dizinimiz var, tüm yapmamız gereken bunu server'a koymak ve protokol ayarlarını yapmak. SSH erişimi olan ve `git.example.com` adında bir server kurduğumuzu varsayalım, ve `/opt/git` dizini altında tüm depolarımızı saklayalım. Boş reponuzu kopyalayarak yeni repo oluşturabilirsiniz:
-
-	$ scp -r my_project.git user@git.example.com:/opt/git
-
-Bu noktada `/opt/git` dizinine okuma ve SSH erişimi olan kullanıcılar aşağıdaki komut ile reponuzu klonlayabilir
-
-	$ git clone user@git.example.com:/opt/git/my_project.git
-
-Bir kullanıcnın server içinde SSHs ve `/opt/git/my_project.git` dizinine yazma erişimi varsa, otomatik olarak push yapma izni olacaktır. Eğer `git init` komutunu `--shared` seçeneği ile çalıştırırsanız Git uygun olarak izinleri verecektir.
-
-	$ ssh user@git.example.com
-	$ cd /opt/git/my_project.git
-	$ git init --bare --shared
-
-Git üzerinde boş bir repo oluşturmak ve SSH izinleri vermenin ne kadar kolay olduğunu gördünüz. Şimdi projelerde birlikte çalışabilirsiniz.
-
-It’s important to note that this is literally all you need to do to run a useful Git server to which several people have access — just add SSH-able accounts on a server, and stick a bare repository somewhere that all those users have read and write access to. You’re ready to go — nothing else needed.
-
-Önümüzdeki bölümlerde, daha sofistike kurulumları göreceğiz. Bunlar kullanıcı izinleri, web UI kurmak, Gitosis aracını kullanarak ve daha fazla, her kullanıcı için kullanıcı hesapları oluşturmak zorunda değiliz gibi konular. However, keep in mind that to collaborate with a couple of people on a private project, all you _need_ is an SSH server and a bare repository.
-
-### Küçük Ayarlar ###
-
-Eğer kuruluşunuza Git ile çalışıyorsanız ve birkaç developer varsa bu işler sizin için kolay olabilir. Bir Git sunucusu kurmanın en karmaşık yönlerinden biri, kullanıcı yönetimidir. Bazı repolar için belirli kullanıcılara okuma bazılarına okuma/yazma erişimi vermek istiyorsanız izinleri düzenlemek zor olabilir.
-
-#### SSH Erişimi ####
-
-Eğer mevcut server'ınıza tüm developerların SSH erişimi var ise ilk repo kurulumu için pek bir iş yapmanız gerekmiyor (son bolumde bahsettiğimiz gibi). Eğer daha complex erişim izinleri istiyorsanız, sunucuda çalışan işletim sisteminin normal dosya sistemi izinleri ile düzenleyebilirsiniz.
-
-If you want to place your repositories on a server that doesn’t have accounts for everyone on your team whom you want to have write access, o zaman onlar için SSH erişimi kurmanız gerekiyor. Biz bunu yapmak için SSH sunucusunun yüklü olduğu bir sunucunuz varsayalım.
-
-Takımdaki herkese erişim vermenin birkaç yolu vardır. İlki basittir ama biraz zahmetli olabilir, herkes için bir hesap oluşturmak. `adduser` çalıştırmak ve her kullanıcı için geçici parolalar oluşturmak istemeyebilirsiniz..
-
-İkinci method tek bir 'git' kullanıcısı oluşturmak, ask every user who is to have write access to send you an SSH public key, and add that key to the `~/.ssh/authorized_keys` file of your new 'git' user. Bu noktada, herkes 'git' kullanıcısı ile bu makineye erişebilecek. This doesn’t affect the commit data in any way — the SSH user you connect as doesn’t affect the commits you’ve recorded.
-
-Bunu yapmanın bir başka yolu, bir LDAP sunucusuna veya zaten kurdunuz bazı diğer merkezi kimlik doğrulama kaynağından SSH sunucusu kimlik doğrulamasına sahip olmaktır. Böylece her kullanıcı makine üzerinden shell erişimi alabilir.
-
-## SSH Key Oluşturmak ##
-
-Git serverlerda kimlik doğrulaması için SSH public keys kullanıyor. Eğer oluşturulmuş yoksa her kullanıcı için sistem bir key oluşturur. İlk olarak hazırda bir key var mı kontrol edilir. Varsayılan olarak, bir kullanıcının SSH anahtarları o kullanıcının ~ /. ssh dizininde depolanır. Eğer oluşturulmuş bir key varsa onu kolayca listeleyebilirsiniz.
-
-	$ cd ~/.ssh
-	$ ls
-	authorized_keys2  id_dsa       known_hosts
-	config            id_dsa.pub
-
-Dosyalarına baktığında iki şey arıyoruz something and something.pub, burada genellikle bir şey `id_dsa` or `id_rsa`.  `.pub` dosya ortak anahtardır, ve diğer dosyaların özel anahtarıdır. Eğer bu dosyalar yok ise (or you don’t even have a `.ssh` directory), `ssh-keygen` ile bu dosyaları oluşturabilirsiniz, Linux/Mac sistemlerinde SSH paketi Windows MSysGit paketi ile geliyor:
- 
-	$ ssh-keygen
-	Generating public/private rsa key pair.
-	Enter file in which to save the key (/Users/schacon/.ssh/id_rsa):
-	Enter passphrase (empty for no passphrase):
-	Enter same passphrase again:
-	Your identification has been saved in /Users/schacon/.ssh/id_rsa.
-	Your public key has been saved in /Users/schacon/.ssh/id_rsa.pub.
-	The key fingerprint is:
-	43:c5:5b:5f:b1:f1:50:43:ad:20:a6:92:6a:1f:9a:3a schacon@agadorlaptop.local
-
-Eğer anahtarı kaydetmek isterseniz (`.ssh/id_rsa`) önce kaydetmek istediğiniz yeri sorar, ve sonra iki kez parolanızı sorar, eğer parolanızı yazmak istemiyorsanız boş geçin.
-
-Now, each user that does this has to send their public key to you or whoever is administrating the Git server (assuming you’re using an SSH server setup that requires public keys). Yapmaları gereken `.pub` dosyasının ve içeriğini kopyalamak olduğunu bunu e-posta atmak. Örnek public key:
-
-	$ cat ~/.ssh/id_rsa.pub
-	ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAklOUpkDHrfHY17SbrmTIpNLTGK9Tjom/BWDSU
-	GPl+nafzlHDTYW7hdI4yZ5ew18JH4JW9jbhUFrviQzM7xlELEVf4h9lFX5QVkbPppSwg0cda3
-	Pbv7kOdJ/MTyBlWXFCR+HAo3FXRitBqxiX1nKhXpHAZsMciLq8V6RjsNAQwdsdMFvSlVK/7XA
-	t3FaoJoAsncM1Q9x5+3V0Ww68/eIFmb1zuUFljQJKprrX88XypNDvjYNby6vw/Pb0rwert/En
-	mZ+AW4OZPnTPI89ZPmVMLuayrD2cE86Z/il8b+gw3r3+1nKatmIkjn2so1d01QraTlMqVSsbx
-	NrRFi9wrf+M7Q== schacon@agadorlaptop.local
-
-Birden fazla işletim sistemlerinde SSH key oluşturma ile ilgili kapsamlı bilgi için bknz: Github klavuzu SSH keys http://github.com/guides/providing-your-ssh-key.
-
-## Sunucu Kurma ##
-
-Şimdi baştan sona adım adım sunucu tarafına SSH erişimi kuralım. Bu örnekte, kullanıcılarınızı doğrulamak için `authorized_keys` methodu kullanacağız. Ayrıca Ubuntu gibi standart bir Linux dağıtımı kullanıyoruz varsayacağız. Öncelikle, bir 'git' kullanıcı ve bu kullanıcı için bir `.ssh` dizin oluşturun.
-
-	$ sudo adduser git
-	$ su git
-	$ cd
-	$ mkdir .ssh
-
-Sonra, you need to add some developer SSH public keys to the `authorized_keys` file for that user. Let’s assume you’ve received a few keys by e-mail and saved them to temporary files. Yine, public keyimiz aşağıdaki gibi olacaktır:
-
-	$ cat /tmp/id_rsa.john.pub
-	ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCB007n/ww+ouN4gSLKssMxXnBOvf9LGt4L
-	ojG6rs6hPB09j9R/T17/x4lhJA0F3FR1rP6kYBRsWj2aThGw6HXLm9/5zytK6Ztg3RPKK+4k
-	Yjh6541NYsnEAZuXz0jTTyAUfrtU3Z5E003C4oxOj6H0rfIF1kKI9MAQLMdpGW1GYEIgS9Ez
-	Sdfd8AcCIicTDWbqLAcU4UpkaX8KyGlLwsNuuGztobF8m72ALC/nLF6JLtPofwFBlgc+myiv
-	O7TCUSBdLQlgMVOFq1I2uPWQOkOWQAHukEOmfjy2jctxSDBQ220ymjaNsHT4kgtZg2AYYgPq
-	dAv8JggJICUvax2T9va5 gsg-keypair
-
-Sizin  `authorized_keys` dosyanıza sadece bunlar eklenecek:
-
-	$ cat /tmp/id_rsa.john.pub >> ~/.ssh/authorized_keys
-	$ cat /tmp/id_rsa.josie.pub >> ~/.ssh/authorized_keys
-	$ cat /tmp/id_rsa.jessica.pub >> ~/.ssh/authorized_keys
-
-Şimdi,boş bir repository oluşturmak için  `git init` komutunu `--bare` özelliği ile çalıştırın, which initializes the repository without a working directory:
-
-	$ cd /opt/git
-	$ mkdir project.git
-	$ cd project.git
-	$ git --bare init
-
-Sonra, John, Josie, or Jessica can push the first version of their project into that repository by adding it as a remote and pushing up a branch. Note that someone must shell onto the machine and create a bare repository every time you want to add a project. Let’s use `gitserver` as the hostname of the server on which you’ve set up your 'git' user and repository. If you’re running it internally, and you set up DNS for `gitserver` to point to that server, then you can use the commands pretty much as is:
-
-	# on Johns computer
-	$ cd myproject
-	$ git init
-	$ git add .
-	$ git commit -m 'initial commit'
-	$ git remote add origin git@gitserver:/opt/git/project.git
-	$ git push origin master
-
-Bu noktada, yapılan değişiklikler kolayca yedeklenir:
-
-	$ git clone git@gitserver:/opt/git/project.git
-	$ cd project
-	$ vim README
-	$ git commit -am 'fix for the README file'
-	$ git push origin master
-
-Bu method ile, kolayca Git server üzerinde okuma/yazma yapabilirsiniz.
-
-As an extra precaution, you can easily restrict the 'git' user to only doing Git activities with a limited shell tool called `git-shell` that comes with Git. If you set this as your 'git' user’s login shell, then the 'git' user can’t have normal shell access to your server. To use this, specify `git-shell` instead of bash or csh for your user’s login shell. To do so, you’ll likely have to edit your `/etc/passwd` file:
-
-	$ sudo vim /etc/passwd
-
-Alt kısımda bu şekilde bir çıktı görmelisiniz:
-
-	git:x:1000:1000::/home/git:/bin/sh
-
-Change `/bin/sh` to `/usr/bin/git-shell` (or run `which git-shell` to see where it’s installed). Satırınız böyle görünmelidir:
-
-	git:x:1000:1000::/home/git:/usr/bin/git-shell
-
-Şimdi, the 'git' user can only use the SSH connection to push and pull Git repositories and can’t shell onto the machine. If you try, you’ll see a login rejection like this:
-
-	$ ssh git@gitserver
-	fatal: What do you think I am? A shell?
-	Connection to gitserver closed.
-
-## Genel Erişim ##
-
-Peki projenize anonim olarak erişmek isterseniz? Perhaps instead of hosting an internal private project, you want to host an open source project. Or maybe you have a bunch of automated build servers or continuous integration servers that change a lot, and you don’t want to have to generate SSH keys all the time — you just want to add simple anonymous read access.
-
-Probably the simplest way for smaller setups is to run a static web server with its document root where your Git repositories are, and then enable that `post-update` hook we mentioned in the first section of this chapter. Let’s work from the previous example. Say you have your repositories in the `/opt/git` directory, and an Apache server is running on your machine. Again, you can use any web server for this; but as an example, we’ll demonstrate some basic Apache configurations that should give you an idea of what you might need.
-
-Öncelikle hook'u etkinleştirmemiz gerekiyor:
-
-	$ cd project.git
-	$ mv hooks/post-update.sample hooks/post-update
-	$ chmod a+x hooks/post-update
-
-Peki bu `post-update` hook ne yapar? Temelde şunları yapar:
-
-	$ cat .git/hooks/post-update
-	#!/bin/sh
-	#
-	# An example hook script to prepare a packed repository for use over
-	# dumb transports.
-	#
-	# To enable this hook, rename this file to "post-update".
-	#
-
-	exec git-update-server-info
-
-Bu SSH üzerinden sunucuya push yaptığınızda, Git HTTP almak için gereken dosyaları günceleyecek ve bu komutu çalıştıracak.
-
-Daha sonra, Apache sunucumuza VirtualHost girişi ekmemiz gerekecek. Here, we’re assuming that you have wildcard DNS set up to send `*.gitserver` to whatever box you’re using to run all this:
-
-	<VirtualHost *:80>
-	    ServerName git.gitserver
-	    DocumentRoot /opt/git
-	    <Directory /opt/git/>
-	        Order allow, deny
-	        allow from all
-	    </Directory>
-	</VirtualHost>
-
-You’ll also need to set the Unix user group of the `/opt/git` directories to `www-data` so your web server can read-access the repositories, çünkü CGI komut dosyası çalıştıran Apache örneği (varsayılan) kullanıcı olarak çalışıyor olacak.
-
-	$ chgrp -R www-data /opt/git
-
-Apache'yi yeniden başlattığınızda, sizin projeniz dizininizin altında oluşan URL ile clonelanabilir:
-
-	$ git clone http://git.gitserver/project.git
-
-This way, you can set up HTTP-based read access to any of your projects for a fair number of users in a few minutes. Another simple option for public unauthenticated access is to start a Git daemon, although that requires you to daemonize the process - we’ll cover this option in the next section, if you prefer that route.
-
-## GitWeb ##
-
-Now that you have basic read/write and read-only access to your project, you may want to set up a simple web-based visualizer. Git comes with a CGI script called GitWeb that is commonly used for this. You can see GitWeb in use at sites like `http://git.kernel.org` (see Figure 4-1).
-
-Insert 18333fig0401.png
-Figure 4-1. The GitWeb web-based user interface.
-
-If you want to check out what GitWeb would look like for your project, Git comes with a command to fire up a temporary instance if you have a lightweight server on your system like `lighttpd` or `webrick`. On Linux machines, `lighttpd` is often installed, so you may be able to get it to run by typing `git instaweb` in your project directory. If you’re running a Mac, Leopard comes preinstalled with Ruby, so `webrick` may be your best bet. To start `instaweb` with a non-lighttpd handler, you can run it with the `--httpd` option.
-
-	$ git instaweb --httpd=webrick
-	[2009-02-21 10:02:21] INFO  WEBrick 1.3.1
-	[2009-02-21 10:02:21] INFO  ruby 1.8.6 (2008-03-03) [universal-darwin9.0]
-
-That starts up an HTTPD server on port 1234 and then automatically starts a web browser that opens on that page. It’s pretty easy on your part. When you’re done and want to shut down the server, you can run the same command with the `--stop` option:
-
-	$ git instaweb --httpd=webrick --stop
-
-If you want to run the web interface on a server all the time for your team or for an open source project you’re hosting, you’ll need to set up the CGI script to be served by your normal web server. Some Linux distributions have a `gitweb` package that you may be able to install via `apt` or `yum`, so you may want to try that first. We’ll walk though installing GitWeb manually very quickly. First, you need to get the Git source code, which GitWeb comes with, and generate the custom CGI script:
-
-	$ git clone git://git.kernel.org/pub/scm/git/git.git
-	$ cd git/
-	$ make GITWEB_PROJECTROOT="/opt/git" \
-	        prefix=/usr gitweb
-	$ sudo cp -Rf gitweb /var/www/
-
-Notice that you have to tell the command where to find your Git repositories with the `GITWEB_PROJECTROOT` variable. Now, you need to make Apache use CGI for that script, for which you can add a VirtualHost:
-
-	<VirtualHost *:80>
-	    ServerName gitserver
-	    DocumentRoot /var/www/gitweb
-	    <Directory /var/www/gitweb>
-	        Options ExecCGI +FollowSymLinks +SymLinksIfOwnerMatch
-	        AllowOverride All
-	        order allow,deny
-	        Allow from all
-	        AddHandler cgi-script cgi
-	        DirectoryIndex gitweb.cgi
-	    </Directory>
-	</VirtualHost>
-
-Again, GitWeb can be served with any CGI capable web server; if you prefer to use something else, it shouldn’t be difficult to set up. At this point, you should be able to visit `http://gitserver/` to view your repositories online, and you can use `http://git.gitserver` to clone and fetch your repositories over HTTP.
-
-## Gitosis ##
-
-Keeping all users’ public keys in the `authorized_keys` file for access works well only for a while. When you have hundreds of users, it’s much more of a pain to manage that process. You have to shell onto the server each time, and there is no access control — everyone in the file has read and write access to every project.
-
-At this point, you may want to turn to a widely used software project called Gitosis. Gitosis is basically a set of scripts that help you manage the `authorized_keys` file as well as implement some simple access controls. The really interesting part is that the UI for this tool for adding people and determining access isn’t a web interface but a special Git repository. You set up the information in that project; and when you push it, Gitosis reconfigures the server based on that, which is cool.
-
-Installing Gitosis isn’t the simplest task ever, but it’s not too difficult. It’s easiest to use a Linux server for it — these examples use a stock Ubuntu 8.10 server.
-
-Gitosis requires some Python tools, so first you have to install the Python setuptools package, which Ubuntu provides as python-setuptools:
-
-	$ apt-get install python-setuptools
-
-Next, you clone and install Gitosis from the project’s main site:
-
-	$ git clone https://github.com/tv42/gitosis.git
-	$ cd gitosis
-	$ sudo python setup.py install
-
-That installs a couple of executables that Gitosis will use. Next, Gitosis wants to put its repositories under `/home/git`, which is fine. But you have already set up your repositories in `/opt/git`, so instead of reconfiguring everything, you create a symlink:
-
-	$ ln -s /opt/git /home/git/repositories
-
-Gitosis is going to manage your keys for you, so you need to remove the current file, re-add the keys later, and let Gitosis control the `authorized_keys` file automatically. For now, move the `authorized_keys` file out of the way:
-
-	$ mv /home/git/.ssh/authorized_keys /home/git/.ssh/ak.bak
-
-Next you need to turn your shell back on for the 'git' user, if you changed it to the `git-shell` command. People still won’t be able to log in, but Gitosis will control that for you. So, let’s change this line in your `/etc/passwd` file
-
-	git:x:1000:1000::/home/git:/usr/bin/git-shell
-
-back to this:
-
-	git:x:1000:1000::/home/git:/bin/sh
-
-Now it’s time to initialize Gitosis. You do this by running the `gitosis-init` command with your personal public key. If your public key isn’t on the server, you’ll have to copy it there:
-
-	$ sudo -H -u git gitosis-init < /tmp/id_dsa.pub
-	Initialized empty Git repository in /opt/git/gitosis-admin.git/
-	Reinitialized existing Git repository in /opt/git/gitosis-admin.git/
-
-This lets the user with that key modify the main Git repository that controls the Gitosis setup. Next, you have to manually set the execute bit on the `post-update` script for your new control repository.
-
-	$ sudo chmod 755 /opt/git/gitosis-admin.git/hooks/post-update
-
-You’re ready to roll. If you’re set up correctly, you can try to SSH into your server as the user for which you added the public key to initialize Gitosis. You should see something like this:
-
-	$ ssh git@gitserver
-	PTY allocation request failed on channel 0
-	ERROR:gitosis.serve.main:Need SSH_ORIGINAL_COMMAND in environment.
-	  Connection to gitserver closed.
-
-That means Gitosis recognized you but shut you out because you’re not trying to do any Git commands. So, let’s do an actual Git command — you’ll clone the Gitosis control repository:
-
-	# on your local computer
-	$ git clone git@gitserver:gitosis-admin.git
-
-Now you have a directory named `gitosis-admin`, which has two major parts:
-
-	$ cd gitosis-admin
-	$ find .
-	./gitosis.conf
-	./keydir
-	./keydir/scott.pub
-
-The `gitosis.conf` file is the control file you use to specify users, repositories, and permissions. The `keydir` directory is where you store the public keys of all the users who have any sort of access to your repositories — one file per user. The name of the file in `keydir` (in the previous example, `scott.pub`) will be different for you — Gitosis takes that name from the description at the end of the public key that was imported with the `gitosis-init` script.
-
-If you look at the `gitosis.conf` file, it should only specify information about the `gitosis-admin` project that you just cloned:
-
-	$ cat gitosis.conf
-	[gitosis]
-
-	[group gitosis-admin]
-	members = scott
-	writable = gitosis-admin
-
-It shows you that the 'scott' user — the user with whose public key you initialized Gitosis — is the only one who has access to the `gitosis-admin` project.
-
-Now, let’s add a new project for you. You’ll add a new section called `mobile` where you’ll list the developers on your mobile team and projects that those developers need access to. Because 'scott' is the only user in the system right now, you’ll add him as the only member, and you’ll create a new project called `iphone_project` to start on:
-
-	[group mobile]
-	members = scott
-	writable = iphone_project
-
-Whenever you make changes to the `gitosis-admin` project, you have to commit the changes and push them back up to the server in order for them to take effect:
-
-	$ git commit -am 'add iphone_project and mobile group'
-	[master 8962da8] add iphone_project and mobile group
-	 1 file changed, 4 insertions(+)
-	$ git push origin master
-	Counting objects: 5, done.
-	Compressing objects: 100% (3/3), done.
-	Writing objects: 100% (3/3), 272 bytes | 0 bytes/s, done.
-	Total 3 (delta 0), reused 0 (delta 0)
-	To git@gitserver:gitosis-admin.git
-	   fb27aec..8962da8  master -> master
-
-You can make your first push to the new `iphone_project` project by adding your server as a remote to your local version of the project and pushing. You no longer have to manually create a bare repository for new projects on the server — Gitosis creates them automatically when it sees the first push:
-
-	$ git remote add origin git@gitserver:iphone_project.git
-	$ git push origin master
-	Initialized empty Git repository in /opt/git/iphone_project.git/
-	Counting objects: 3, done.
-	Writing objects: 100% (3/3), 230 bytes | 0 bytes/s, done.
-	Total 3 (delta 0), reused 0 (delta 0)
-	To git@gitserver:iphone_project.git
-	 * [new branch]      master -> master
-
-Notice that you don’t need to specify the path (in fact, doing so won’t work), just a colon and then the name of the project — Gitosis finds it for you.
-
-You want to work on this project with your friends, so you’ll have to re-add their public keys. But instead of appending them manually to the `~/.ssh/authorized_keys` file on your server, you’ll add them, one key per file, into the `keydir` directory. How you name the keys determines how you refer to the users in the `gitosis.conf` file. Let’s re-add the public keys for John, Josie, and Jessica:
-
-	$ cp /tmp/id_rsa.john.pub keydir/john.pub
-	$ cp /tmp/id_rsa.josie.pub keydir/josie.pub
-	$ cp /tmp/id_rsa.jessica.pub keydir/jessica.pub
-
-Now you can add them all to your 'mobile' team so they have read and write access to `iphone_project`:
-
-	[group mobile]
-	members = scott john josie jessica
-	writable = iphone_project
-
-After you commit and push that change, all four users will be able to read from and write to that project.
-
-Gitosis has simple access controls as well. If you want John to have only read access to this project, you can do this instead:
-
-	[group mobile]
-	members = scott josie jessica
-	writable = iphone_project
-
-	[group mobile_ro]
-	members = john
-	readonly = iphone_project
-
-Now John can clone the project and get updates, but Gitosis won’t allow him to push back up to the project. You can create as many of these groups as you want, each containing different users and projects. You can also specify another group as one of the members (using `@` as prefix), to inherit all of its members automatically:
-
-	[group mobile_committers]
-	members = scott josie jessica
-
-	[group mobile]
-	members   = @mobile_committers
-	writable  = iphone_project
-
-	[group mobile_2]
-	members   = @mobile_committers john
-	writable  = another_iphone_project
-
-If you have any issues, it may be useful to add `loglevel=DEBUG` under the `[gitosis]` section. If you’ve lost push access by pushing a messed-up configuration, you can manually fix the file on the server under `/home/git/.gitosis.conf` — the file from which Gitosis reads its info. A push to the project takes the `gitosis.conf` file you just pushed up and sticks it there. If you edit that file manually, it remains like that until the next successful push to the `gitosis-admin` project.
-
-## Gitolite ##
-
-This section serves as a quick introduction to Gitolite, and provides basic installation and setup instructions.  It cannot, however, replace the enormous amount of [documentation][gltoc] that Gitolite comes with.  There may also be occasional changes to this section itself, so you may also want to look at the latest version [here][gldpg].
-
-[gldpg]: http://sitaramc.github.com/gitolite/progit.html
-[gltoc]: http://sitaramc.github.com/gitolite/master-toc.html
-
-Gitolite is an authorization layer on top of Git, relying on `sshd` or `httpd` for authentication.  (Recap: authentication is identifying who the user is, authorization is deciding if he is allowed to do what he is attempting to).
-
-Gitolite allows you to specify permissions not just by repository, but also by branch or tag names within each repository.  That is, you can specify that certain people (or groups of people) can only push certain "refs" (branches or tags) but not others.
-
-### Installing ###
-
-Installing Gitolite is very easy, even if you don’t read the extensive documentation that comes with it.  You need an account on a Unix server of some kind.  You do not need root access, assuming Git, Perl, and an OpenSSH compatible SSH server are already installed.  In the examples below, we will use the `git` account on a host called `gitserver`.
-
-Gitolite is somewhat unusual as far as "server" software goes — access is via SSH, and so every userid on the server is a potential "gitolite host".  We will describe the simplest install method in this article; for the other methods please see the documentation.
-
-To begin, create a user called `git` on your server and login to this user.  Copy your SSH public key (a file called `~/.ssh/id_rsa.pub` if you did a plain `ssh-keygen` with all the defaults) from your workstation, renaming it to `<yourname>.pub` (we'll use `scott.pub` in our examples).  Then run these commands:
-
-	$ git clone git://github.com/sitaramc/gitolite
-	$ gitolite/install -ln
-	    # assumes $HOME/bin exists and is in your $PATH
-	$ gitolite setup -pk $HOME/scott.pub
-
-That last command creates new Git repository called `gitolite-admin` on the server.
-
-Finally, back on your workstation, run `git clone git@gitserver:gitolite-admin`. And you’re done!  Gitolite has now been installed on the server, and you now have a brand new repository called `gitolite-admin` in your workstation.  You administer your Gitolite setup by making changes to this repository and pushing.
-
-### Customising the Install ###
-
-While the default, quick, install works for most people, there are some ways to customise the install if you need to.  Some changes can be made simply by editing the rc file, but if that is not sufficient, there’s documentation on customising Gitolite.
-
-### Config File and Access Control Rules ###
-
-Once the install is done, you switch to the `gitolite-admin` clone you just made on your workstation, and poke around to see what you got:
-
-	$ cd ~/gitolite-admin/
-	$ ls
-	conf/  keydir/
-	$ find conf keydir -type f
-	conf/gitolite.conf
-	keydir/scott.pub
-	$ cat conf/gitolite.conf
-
-	repo gitolite-admin
-	    RW+                 = scott
-
-	repo testing
-	    RW+                 = @all
-
-Notice that "scott" (the name of the pubkey in the `gitolite setup` command you used earlier) has read-write permissions on the `gitolite-admin` repository as well as a public key file of the same name.
-
-Adding users is easy.  To add a user called "alice", obtain her public key, name it `alice.pub`, and put it in the `keydir` directory of the clone of the `gitolite-admin` repo you just made on your workstation.  Add, commit, and push the change, and the user has been added.
-
-The config file syntax for Gitolite is well documented, so we’ll only mention some highlights here.
-
-You can group users or repos for convenience.  The group names are just like macros; when defining them, it doesn’t even matter whether they are projects or users; that distinction is only made when you *use* the "macro".
-
-	@oss_repos      = linux perl rakudo git gitolite
-	@secret_repos   = fenestra pear
-
-	@admins         = scott
-	@interns        = ashok
-	@engineers      = sitaram dilbert wally alice
-	@staff          = @admins @engineers @interns
-
-You can control permissions at the "ref" level.  In the following example, interns can only push the "int" branch.  Engineers can push any branch whose name starts with "eng-", and tags that start with "rc" followed by a digit.  And the admins can do anything (including rewind) to any ref.
-
-	repo @oss_repos
-	    RW  int$                = @interns
-	    RW  eng-                = @engineers
-	    RW  refs/tags/rc[0-9]   = @engineers
-	    RW+                     = @admins
-
-The expression after the `RW` or `RW+` is a regular expression (regex) that the refname (ref) being pushed is matched against.  So we call it a "refex"!  Of course, a refex can be far more powerful than shown here, so don’t overdo it if you’re not comfortable with Perl regexes.
-
-Also, as you probably guessed, Gitolite prefixes `refs/heads/` as a syntactic convenience if the refex does not begin with `refs/`.
-
-An important feature of the config file’s syntax is that all the rules for a repository need not be in one place.  You can keep all the common stuff together, like the rules for all `oss_repos` shown above, then add specific rules for specific cases later on, like so:
-
-	repo gitolite
-	    RW+                     = sitaram
-
-That rule will just get added to the ruleset for the `gitolite` repository.
-
-At this point you might be wondering how the access control rules are actually applied, so let’s go over that briefly.
-
-There are two levels of access control in Gitolite.  The first is at the repository level; if you have read (or write) access to *any* ref in the repository, then you have read (or write) access to the repository.  This is the only access control that Gitosis had.
-
-The second level, applicable only to "write" access, is by branch or tag within a repository.  The username, the access being attempted (`W` or `+`), and the refname being updated are known.  The access rules are checked in order of appearance in the config file, looking for a match for this combination (but remember that the refname is regex-matched, not merely string-matched).  If a match is found, the push succeeds.  A fallthrough results in access being denied.
-
-### Advanced Access Control with "deny" rules ###
-
-So far, we’ve only seen permissions to be one of `R`, `RW`, or `RW+`.  However, Gitolite allows another permission: `-`, standing for "deny".  This gives you a lot more power, at the expense of some complexity, because now fallthrough is not the *only* way for access to be denied, so the *order of the rules now matters*!
-
-Let us say, in the situation above, we want engineers to be able to rewind any branch *except* master and integ.  Here’s how to do that:
-
-	    RW  master integ    = @engineers
-	    -   master integ    = @engineers
-	    RW+                 = @engineers
-
-Again, you simply follow the rules top down until you hit a match for your access mode, or a deny.  Non-rewind push to master or integ is allowed by the first rule.  A rewind push to those refs does not match the first rule, drops down to the second, and is therefore denied.  Any push (rewind or non-rewind) to refs other than master or integ won’t match the first two rules anyway, and the third rule allows it.
-
-### Restricting pushes by files changed ###
-
-In addition to restricting what branches a user can push changes to, you can also restrict what files they are allowed to touch.  For example, perhaps the Makefile (or some other program) is really not supposed to be changed by just anyone, because a lot of things depend on it or would break if the changes are not done *just right*.  You can tell Gitolite:
-
-    repo foo
-        RW                      =   @junior_devs @senior_devs
-
-        -   VREF/NAME/Makefile  =   @junior_devs
-
-Users who are migrating from the older Gitolite should note that there is a significant change in behaviour with regard to this feature; please see the migration guide for details.
-
-### Personal Branches ###
-
-Gitolite also has a feature called "personal branches" (or rather, "personal branch namespace") that can be very useful in a corporate environment.
-
-A lot of code exchange in the Git world happens by "please pull" requests.  In a corporate environment, however, unauthenticated access is a no-no, and a developer workstation cannot do authentication, so you have to push to the central server and ask someone to pull from there.
-
-This would normally cause the same branch name clutter as in a centralised VCS, plus setting up permissions for this becomes a chore for the admin.
-
-Gitolite lets you define a "personal" or "scratch" namespace prefix for each developer (for example, `refs/personal/<devname>/*`); please see the documentation for details.
-
-### "Wildcard" repositories ###
-
-Gitolite allows you to specify repositories with wildcards (actually Perl regexes), like, for example `assignments/s[0-9][0-9]/a[0-9][0-9]`, to pick a random example.  It also allows you to assign a new permission mode (`C`) which enables users to create repositories based on such wild cards, automatically assigns ownership to the specific user who created it, allows him/her to hand out `R` and `RW` permissions to other users to collaborate, etc.  Again, please see the documentation for details.
-
-### Other Features ###
-
-We’ll round off this discussion with a sampling of other features, all of which, and many more, are described in great detail in the documentation.
-
-**Logging**: Gitolite logs all successful accesses.  If you were somewhat relaxed about giving people rewind permissions (`RW+`) and some kid blew away `master`, the log file is a life saver, in terms of easily and quickly finding the SHA that got hosed.
-
-**Access rights reporting**: Another convenient feature is what happens when you try and just ssh to the server.  Gitolite shows you what repos you have access to, and what that access may be.  Here’s an example:
-
-        hello scott, this is git@git running gitolite3 v3.01-18-g9609868 on git 1.7.4.4
-
-             R     anu-wsd
-             R     entrans
-             R  W  git-notes
-             R  W  gitolite
-             R  W  gitolite-admin
-             R     indic_web_input
-             R     shreelipi_converter
-
-**Delegation**: For really large installations, you can delegate responsibility for groups of repositories to various people and have them manage those pieces independently.  This reduces the load on the main admin, and makes him less of a bottleneck.
-
-**Mirroring**: Gitolite can help you maintain multiple mirrors, and switch between them easily if the primary server goes down.
-
-## Git Daemon ##
-
-For public, unauthenticated read access to your projects, you’ll want to move past the HTTP protocol and start using the Git protocol. The main reason is speed. The Git protocol is far more efficient and thus faster than the HTTP protocol, so using it will save your users time.
-
-Again, this is for unauthenticated read-only access. If you’re running this on a server outside your firewall, it should only be used for projects that are publicly visible to the world. If the server you’re running it on is inside your firewall, you might use it for projects that a large number of people or computers (continuous integration or build servers) have read-only access to, when you don’t want to have to add an SSH key for each.
-
-In any case, the Git protocol is relatively easy to set up. Basically, you need to run this command in a daemonized manner:
-
-	git daemon --reuseaddr --base-path=/opt/git/ /opt/git/
-
-`--reuseaddr` allows the server to restart without waiting for old connections to time out, the `--base-path` option allows people to clone projects without specifying the entire path, and the path at the end tells the Git daemon where to look for repositories to export. If you’re running a firewall, you’ll also need to punch a hole in it at port 9418 on the box you’re setting this up on.
-
-You can daemonize this process a number of ways, depending on the operating system you’re running. On an Ubuntu machine, you use an Upstart script. So, in the following file
-
-	/etc/event.d/local-git-daemon
-
-you put this script:
-
-	start on startup
-	stop on shutdown
-	exec /usr/bin/git daemon \
-	    --user=git --group=git \
-	    --reuseaddr \
-	    --base-path=/opt/git/ \
-	    /opt/git/
-	respawn
-
-For security reasons, it is strongly encouraged to have this daemon run as a user with read-only permissions to the repositories — you can easily do this by creating a new user 'git-ro' and running the daemon as them.  For the sake of simplicity we’ll simply run it as the same 'git' user that Gitosis is running as.
-
-When you restart your machine, your Git daemon will start automatically and respawn if it goes down. To get it running without having to reboot, you can run this:
-
-	initctl start local-git-daemon
-
-On other systems, you may want to use `xinetd`, a script in your `sysvinit` system, or something else — as long as you get that command daemonized and watched somehow.
-
-Next, you have to tell your Gitosis server which repositories to allow unauthenticated Git server-based access to. If you add a section for each repository, you can specify the ones from which you want your Git daemon to allow reading. If you want to allow Git protocol access for the `iphone_project`, you add this to the end of the `gitosis.conf` file:
-
-	[repo iphone_project]
-	daemon = yes
-
-When that is committed and pushed up, your running daemon should start serving requests for the project to anyone who has access to port 9418 on your server.
-
-If you decide not to use Gitosis, but you want to set up a Git daemon, you’ll have to run this on each project you want the Git daemon to serve:
-
-	$ cd /path/to/project.git
-	$ touch git-daemon-export-ok
-
-The presence of that file tells Git that it’s OK to serve this project without authentication.
-
-Gitosis can also control which projects GitWeb shows. First, you need to add something like the following to the `/etc/gitweb.conf` file:
-
-	$projects_list = "/home/git/gitosis/projects.list";
-	$projectroot = "/home/git/repositories";
-	$export_ok = "git-daemon-export-ok";
-	@git_base_url_list = ('git://gitserver');
-
-You can control which projects GitWeb lets users browse by adding or removing a `gitweb` setting in the Gitosis configuration file. For instance, if you want the `iphone_project` to show up on GitWeb, you make the `repo` setting look like this:
-
-	[repo iphone_project]
-	daemon = yes
-	gitweb = yes
-
-Now, if you commit and push the project, GitWeb will automatically start showing the `iphone_project`.
-
-## Hosted Git ##
-
-If you don’t want to go through all of the work involved in setting up your own Git server, you have several options for hosting your Git projects on an external dedicated hosting site. Doing so offers a number of advantages: a hosting site is generally quick to set up and easy to start projects on, and no server maintenance or monitoring is involved. Even if you set up and run your own server internally, you may still want to use a public hosting site for your open source code — it’s generally easier for the open source community to find and help you with.
-
-These days, you have a huge number of hosting options to choose from, each with different advantages and disadvantages. To see an up-to-date list, check out the following page:
-
-	https://git.wiki.kernel.org/index.php/GitHosting
-
-Because we can’t cover all of them, and because I happen to work at one of them, we’ll use this section to walk through setting up an account and creating a new project at GitHub. This will give you an idea of what is involved.
-
-GitHub is by far the largest open source Git hosting site and it’s also one of the very few that offers both public and private hosting options so you can keep your open source and private commercial code in the same place. In fact, we used GitHub to privately collaborate on this book.
-
-### GitHub ###
-
-GitHub is slightly different than most code-hosting sites in the way that it namespaces projects. Instead of being primarily based on the project, GitHub is user centric. That means when I host my `grit` project on GitHub, you won’t find it at `github.com/grit` but instead at `github.com/schacon/grit`. There is no canonical version of any project, which allows a project to move from one user to another seamlessly if the first author abandons the project.
-
-GitHub is also a commercial company that charges for accounts that maintain private repositories, but anyone can quickly get a free account to host as many open source projects as they want. We’ll quickly go over how that is done.
-
-### Setting Up a User Account ###
-
-The first thing you need to do is set up a free user account. If you visit the Pricing and Signup page at `http://github.com/plans` and click the "Sign Up" button on the Free account (see Figure 4-2), you’re taken to the signup page.
-
-Insert 18333fig0402.png
-Figure 4-2. The GitHub plan page.
-
-Here you must choose a username that isn’t yet taken in the system and enter an e-mail address that will be associated with the account and a password (see Figure 4-3).
-
-Insert 18333fig0403.png
-Figure 4-3. The GitHub user signup form.
-
-If you have it available, this is a good time to add your public SSH key as well. We covered how to generate a new key earlier, in the "Simple Setups" section. Take the contents of the public key of that pair, and paste it into the SSH Public Key text box. Clicking the "explain ssh keys" link takes you to detailed instructions on how to do so on all major operating systems.
-Clicking the "I agree, sign me up" button takes you to your new user dashboard (see Figure 4-4).
-
-Insert 18333fig0404.png
-Figure 4-4. The GitHub user dashboard.
-
-Next you can create a new repository.
-
-### Creating a New Repository ###
-
-Start by clicking the "create a new one" link next to Your Repositories on the user dashboard. You’re taken to the Create a New Repository form (see Figure 4-5).
-
-Insert 18333fig0405.png
-Figure 4-5. Creating a new repository on GitHub.
-
-All you really have to do is provide a project name, but you can also add a description. When that is done, click the "Create Repository" button. Now you have a new repository on GitHub (see Figure 4-6).
-
-Insert 18333fig0406.png
-Figure 4-6. GitHub project header information.
-
-Since you have no code there yet, GitHub will show you instructions for how create a brand-new project, push an existing Git project up, or import a project from a public Subversion repository (see Figure 4-7).
-
-Insert 18333fig0407.png
-Figure 4-7. Instructions for a new repository.
-
-These instructions are similar to what we’ve already gone over. To initialize a project if it isn’t already a Git project, you use
-
-	$ git init
-	$ git add .
-	$ git commit -m 'initial commit'
-
-When you have a Git repository locally, add GitHub as a remote and push up your master branch:
-
-	$ git remote add origin git@github.com:testinguser/iphone_project.git
-	$ git push origin master
-
-Now your project is hosted on GitHub, and you can give the URL to anyone you want to share your project with. In this case, it’s `http://github.com/testinguser/iphone_project`. You can also see from the header on each of your project’s pages that you have two Git URLs (see Figure 4-8).
-
-Insert 18333fig0408.png
-Figure 4-8. Project header with a public URL and a private URL.
-
-The Public Clone URL is a public, read-only Git URL over which anyone can clone the project. Feel free to give out that URL and post it on your web site or what have you.
-
-The Your Clone URL is a read/write SSH-based URL that you can read or write over only if you connect with the SSH private key associated with the public key you uploaded for your user. When other users visit this project page, they won’t see that URL—only the public one.
-
-### Importing from Subversion ###
-
-If you have an existing public Subversion project that you want to import into Git, GitHub can often do that for you. At the bottom of the instructions page is a link to a Subversion import. If you click it, you see a form with information about the import process and a text box where you can paste in the URL of your public Subversion project (see Figure 4-9).
-
-Insert 18333fig0409.png
-Figure 4-9. Subversion importing interface.
-
-If your project is very large, nonstandard, or private, this process probably won’t work for you. In Chapter 7, you’ll learn how to do more complicated manual project imports.
-
-### Adding Collaborators ###
-
-Let’s add the rest of the team. If John, Josie, and Jessica all sign up for accounts on GitHub, and you want to give them push access to your repository, you can add them to your project as collaborators. Doing so will allow pushes from their public keys to work.
-
-Click the "edit" button in the project header or the Admin tab at the top of the project to reach the Admin page of your GitHub project (see Figure 4-10).
-
-Insert 18333fig0410.png
-Figure 4-10. GitHub administration page.
-
-To give another user write access to your project, click the “Add another collaborator” link. A new text box appears, into which you can type a username. As you type, a helper pops up, showing you possible username matches. When you find the correct user, click the Add button to add that user as a collaborator on your project (see Figure 4-11).
-
-Insert 18333fig0411.png
-Figure 4-11. Adding a collaborator to your project.
-
-When you’re finished adding collaborators, you should see a list of them in the Repository Collaborators box (see Figure 4-12).
-
-Insert 18333fig0412.png
-Figure 4-12. A list of collaborators on your project.
-
-If you need to revoke access to individuals, you can click the "revoke" link, and their push access will be removed. For future projects, you can also copy collaborator groups by copying the permissions of an existing project.
-
-### Your Project ###
-
-After you push your project up or have it imported from Subversion, you have a main project page that looks something like Figure 4-13.
-
-Insert 18333fig0413.png
-Figure 4-13. A GitHub main project page.
-
-When people visit your project, they see this page. It contains tabs to different aspects of your projects. The Commits tab shows a list of commits in reverse chronological order, similar to the output of the `git log` command. The Network tab shows all the people who have forked your project and contributed back. The Downloads tab allows you to upload project binaries and link to tarballs and zipped versions of any tagged points in your project. The Wiki tab provides a wiki where you can write documentation or other information about your project. The Graphs tab has some contribution visualizations and statistics about your project. The main Source tab that you land on shows your project’s main directory listing and automatically renders the README file below it if you have one. This tab also shows a box with the latest commit information.
-
-### Projeleri Forklamak ###
-
-If you want to contribute to an existing project to which you don’t have push access, GitHub encourages forking the project. When you land on a project page that looks interesting and you want to hack on it a bit, you can click the "fork" button in the project header to have GitHub copy that project to your user so you can push to it.
-
-This way, projects don’t have to worry about adding users as collaborators to give them push access. People can fork a project and push to it, and the main project maintainer can pull in those changes by adding them as remotes and merging in their work.
-
-To fork a project, visit the project page (in this case, mojombo/chronic) and click the "fork" button in the header (see Figure 4-14).
-
-Insert 18333fig0414.png
-Figure 4-14. Get a writable copy of any repository by clicking the "fork" button.
-
-After a few seconds, you’re taken to your new project page, which indicates that this project is a fork of another one (see Figure 4-15).
-
-Insert 18333fig0415.png
-Figure 4-15. Your fork of a project.
-
-### GitHub Özeti ###
-
-That’s all we’ll cover about GitHub, but it’s important to note how quickly you can do all this. You can create an account, add a new project, and push to it in a matter of minutes. If your project is open source, you also get a huge community of developers who now have visibility into your project and may well fork it and help contribute to it. At the very least, this may be a way to get up and running with Git and try it out quickly.
-
-## Özet ##
-
-You have several options to get a remote Git repository up and running so that you can collaborate with others or share your work.
-
-Running your own server gives you a lot of control and allows you to run the server within your own firewall, but such a server generally requires a fair amount of your time to set up and maintain. If you place your data on a hosted server, it’s easy to set up and maintain; however, you have to be able to keep your code on someone else’s servers, and some organizations don’t allow that.
-
-It should be fairly straightforward to determine which solution or combination of solutions is appropriate for you and your organization.
+Sonraki Git Protokolüdür. Git ile paketlenmiş olarak gelen servistir. SSH protokolüne benzer bir hizmet sunar 9418 portunu dinler fakat kimlik doğrulaması gerektirmez. Bir reponun Git protokolü üzerinden sunulması için, 'git-daemon-export-ok' dosyasını oluşturmalısınız - Daemon, içinde bu dosya olmayan bir git reposunu sunmaz. - fakat bunun dışında, güvenlik yoktur. Ya clonelanabilir bir Git reposu mevcuttur ya da herkes clonelayamaz. Bu, genel olarak bu protokol üzerinden psuh yapıldığı anlamına gelir. Push erişimi sağlar; fakat eksik bir kimlik doğrulamada internet üzerinde projenizin URL'i bulunur ve push edilebilir. Fakat bu durum çok nadir olur.
\ No newline at end of file
diff --git a/tr/05-distributed-git/01-chapter5.markdown b/tr/05-distributed-git/01-chapter5.markdown
new file mode 100644
index 000000000..f65ed4a81
--- /dev/null
+++ b/tr/05-distributed-git/01-chapter5.markdown
@@ -0,0 +1,215 @@
+# Dağıtık Git #
+
+Artık tüm developerların kodunu paylaşacağı bir uzak git reposuna sahipsiniz ve yerel çalışma akışınızda kullanacağınız temel Git komutlarına aşinasınız. Artık Git'in size sağladığı bazı dağıtık çalışma akışlarını nasıl kullanacağımıza bakacacağız.
+
+Bu bölümde, dağıtık bir Git ortamında katılımcı ve koordinatör olarak nasıl çalışacağınızı göreceksiniz. Bir çok geliştiricinin çalıştığı projelere nasıl katkı sağlayacağınızı ve projenin sürdürülebilirliğini nasıl sağlayacağınızı öğreneceksiniz.
+
+## Dağıtık Çalışma Akışları ##
+
+Merkezi Versiyon Kontrol Sistemlerinden (CVCSs) farklı olarak, Git'in dağıtık yapısı geliştiricilerin projelerde nasıl işbirliği yapacağı konusunda daha esnek davranmanıza izin verir. Merkezi sistemlerde, her bir geliştirici merkez çevresinde az veya çok çalışan bir noktacıktır. Git'te ise; her bir geliştirici potansiyel olarak bir noktacık veya bir merkez olabilir. Her bir geliştirici başka repolar üzerindeki kodlara katkı sağlayabilir ve aynı zamanda başkalarının katkı sağladığı bir reponun koordinatörlüğünü üstlenebilir. Bu takımınıza ve projenize sonsuz sayıda çalışma akışı için imkan sağlar. Burada bu esnekliğin avantajlarını kullanan bazı çok kullanılan çalışma tasarım desenlerinden(pattern) bahsedeceğim. Her bir desenin güçlü ve zayıf yanlarının üzerinden geçeceğim. Böylece bunlardan birini seçebilirsiniz ya da ihtiyaçlarınıza göre şekillendirerek/karıştırarak kullanabilirsiniz.
+
+### Merkezi Çalışma Akışı (Centralized Workflow) ###
+
+Merkezi sistemlerde, genellikle tek bir katılım modeli vardır: Merkezi Çalışma Akışı. Kod katılımını kabul edebilen tek bir merkez veya repo bulunur ve herkes çalışmasını bu merkezle senkronize eder. Geliştiriciler bu merkezin çevresindeki noktacıklardır ve bu tek merkeze senkronize olurlar (Resim 5-1).
+
+Insert 18333fig0501.png
+Resim 5-1. Merkezi çalışma akışı.
+
+Bu şu anlama gelir; eğer iki geliştirici bir merkezden repoyu klonlar ve değişiklikler yapar, ardından ilk geliştirici değişikliklerini merkeze gönderirse herhangi bir sıkıntı olmaz. Ancak ikinci geliştirici ilk geliştiricinin değişiklilerinin üzerine yazmadığından emin olmak için değişikliklerini göndermeden önce merkezi reponun son halini kendisine almalı ve kendi değişiklikleriyle birleştirmelidir. Bu konsept Git ya da Subversion (ya da herhangi bir  CVCS)'de mevcuttur, ve Git'de çok iyi çalışır.
+
+Eğer küçük bir takımsanız veya merkezi çalışma akışından hali hazırda memnunsanız bu akışı Git ile kullanmaya devam edebilirsiniz. Tek bir repo oluşturun, ve takımdaki herkese bu repoya push edebilme izni verin; Git geliştiricilerin birbirlerinin değişikliklerini ezmesine izin vermeyecektir. Eğer bir geliştirici repoyu klonlar, değişiklikler yapar ve ardından değişikliklerini push etmeye çalışırsa ve o esnada başka bir geliştirici değişiklikler yapıp push ettiyse git sunucusu değişiklikleri reddedecektir. non-fast-forward(hızlı-ileri-olmayan?) değişiklikler yaptığı şeklinde bir hata alacak ve repodan fetch ve merge yapmadığı sürece değişikliklerini gönderemeyecektir.
+Bu paradigma birçok insanı kendine çeker çünkü birçok kişiye tanıdık gelen ve rahat olabildikleri bir konsepttir.
+
+### Entegrasyon Yöneticili Çalışma Akışı (Integration-Manager Workflow) ###
+
+Git birden çok uzak repoyla çalışmanıza izin verdiğinden, her geliştiricinin kendi reposuna yazma izni ve diğer tüm repolara okuma izni olan bir çalışma akışı mümkündür. Bu senaryoda genellikle projeyi "resmi" olarak temsil eden ve doğruluğndan emin olunan bir repo bulunur. Bu repoya katkıda bulunmak için reponun kendinize ait olan klonun oluşturur ve kendi reponuz üzerinde çalışırsınız. Sonrasında ana proje reposunu yöneten kişiye sizin reponuzdaki değişiklikleri ana repoya alması için bir istekte bulunursunuz. Yönetici sizin reponuzu kendisine uzak sunucu olarak ekler, değişikliklerinizi test eder, ana repodaki branch ile birleştirir ve ana repoya gönderir. Bu işlem aşağıdaki şu şekilde ilerler (Resim 5-2):
+
+1. Yönetici projenin genel reposuna push eder.
+2. Geliştirici o repoyu kendisine klonlar ve değişiklilerini yapar.
+3. Geliştirici değişikliklerini kendi reposuna gönderir.
+4. Geliştirici yöneticiye değişiklilerini çekmesi için bir istekte bulunur (email vs.).
+5. Yönetici geliştiricinin reposunu kendisine bir remote olarak ekler ve local olarak değişiklikleri birleştirir.
+6. Yönetici birleştirilmiş değişiklikleri ana repoya gönderir.
+
+Insert 18333fig0502.png
+Figure 5-2. Entegrasyon Yöneticili Çalışma Akışı
+
+Bir projeyi fork etmek ve o fork üzerinde çalışmak gibi işlemlerin kolay olduğu, Github gibi sitelerle birlikte bu çok kullanılan bir çalışma akışıdır. Bu yaklaşımın ana kazanımlarından biri geliştirici çalışmaya devam ederken yönetici geliştiricinin değişikliklerini herhangi bir zamanda ana repoya alabilir. Katılımcılar projenin kendi değişikliklerini dahil etmesini beklemek zorunda değildir. Herkes kendi alanında çalışabilir.
+
+### Diktatör ve Yüzbaşılar Çalışma Akışı (Dictator and Lieutenants Workflow) ###
+
+Bu çoklu repo çalışma akışının bir varyasyonudur. Genellikle yüzlerce katılımcının olduğu devasa projelerde kullanılır; meşhur bir örnek Linux çekirdeğidir. Bir çok entegrasyon yöneticisi projenin çeşitli yerlerinden sorumludur; bu kişiler yüzbaşılardır. Tüm yüzbaşıların üstünde ise 'iyiliksever diktatör' denilen tek bir entegrasyon yöneticisi vardır. İyiliksever diktatörün reposu tüm katılımcıların pull etmesi gereken referans repo konumundadır. Bu işlem aşağıdaki şu şekilde ilerler (Resim 5-3):
+
+1. Normal geliştiriciler kendi topic branch(konu dalı)lerinde çalışırlan ve değişikliklerini diktatörün master branchi üzerinde rebase ederler.
+2. Yüzbaşılar geliştiricilerin branchlerini kendi master branchlerine birleştirirler.
+3. Diktatör yüzbaşıların master branchini kendi master branchine birleştirir.
+4. Diktatör kendi master branchini referans repoya gönderir. Böylece diğer developerlar bunun üzerine rebase edebilirler.
+
+Insert 18333fig0503.png
+Resim 5-3. Diktatör ve Yüzbaşılar Çalışma Akışı.
+
+Bu tarz bir çalışma akışı çok yaygın değildir fakat büyük projelerde veya çok hiyerarşik ortamlarda kullanışlı olabilir. Çünkü bu akış proje liderine (diktatör) görevlerin çoğunu dağıtma ve büyük kod setlerini entegre etmeden önce toplama imkanı sunar.
+
+Bunlar Git gibi dağıtık sistemlerde mümkün olan çalışma akışlarından çok yaygın olan birkaçıydı. Sizin takım yapınıza ve çalışma şeklinize uygun olan daha başka yöntemler bulunabilir. Artık (umarım) hangi çalışma akışı kombinasyonunun size uyacağına karar verebilirsiniz. Şimdi daha özele inen bazı örneklerle değişik senaryolarda mümkün olabilecek rollerin çalışma akışlarından bahsedelim.
+
+## Bir Projeye Katılım Sağlamak ##
+
+Artık değişik çalışma akışlarını biliyor ve temel Git kullanımını iyice kavramış olmanız gerekiyor. Bu bölümde, bir projeye katkı sağlarken kullanılabilecek bazı genel pattern(desen)lardan bahsedeceğiz.
+
+Bu işlemi açıklamanın en zor tarafı, nasıl yapılacağı ile ilgili çok fazla sayıda varyasyon olmasıdır. Çünkü Git çok esnektir ve insanlar bir arada çok farklı şekillerde çalışabilirler ve her proje birbirinden farklıdır. Bu da bir projeye nasıl katılım sağlanacağı konusunu anlatmayı problemli bir hale getirmektedir. İlişkili bazı değişkenler; aktif katılımcı sayısı, seçilen çalışma akışı, commit erişiminiz ve belki dışarıdan katılım metodudur.
+
+İlk değişken; aktif katılımcı sayısı. Kaç kişi bu projeye ne sıklıkla kod katılımı sağlıyorlar? Birçok durumda iki-üç geliştiriciniz ve her geliştirici için günde birkaç commit olacaktır; atıl projeler için belki daha az. Fakat gerçekten büyük şirketler ve projeler için, binlerce geliştirici ve her gün düzinelerce hatta yüzlerce yama olabilir. Bu önemlidir çünkü geliştici sayısı arttıkça, kodunuzun temizce uygulanması ve kolayca birleştirilmesi konusunda daha çok sıkıntı yaşayacaksınız. Değişiklikleriniz, siz çalışırken veya değişikliklerinizin birleştirilmesini beklerken başka geliştiricilerin değişikliklerinin birleştirilmiş olmasından dolayı eski kalmış ya da kısmen/tamamen bozulmaya sebep olmuş olabilir. Peki kodunuzu nasıl düzenli olarak güncel ve değişikliklerinizi güncel tutacaksınız?
+
+Diğer değişken; projeniz için kullandığınız çalışma akışı. Her geliştiricinin kod üzerinde eşit yazma hakları olacak şekilde merkezi mi? Projede tüm yamaları kontrol eden bir entegrasyon yöneticisi var mı? Tüm yamalar başka geliştiriciler kontrol edilip mi onaylanıyor? Siz bu süreçte var mısınız? Bir yüzbaşı sistemi var ve öncelikle değişikliklerinizi onlara mı göndermek durumundasınız?
+
+Diğer bir sorun ise commit erişiminiz. Çünkü bir projeye doğrudan yazma izninizin olup olmaması o projede uygulanması gereken çalışma akışını çok etkiler. Eğer yazma izniniz yoksa, prje katılımcıların çalışmalarını ne şekilde kabul etmeyi tercih ediyor? Bir politikasi var mı? Tek seferde ne kadarlık bir katılım sağlıyorsunuz? Ne sıklıkla katılım sağlıyorsunuz?
+
+Tüm bu sorular nasıl verimli bir şekilde katılım sağlayacağınızı, sizin için ne şekilde çalışma akışları mevcut olacağını ve tercih edildiğini etkileyecektir. Bunların her birini ve yönlerini, basitten karmaşığa doğru giderek ve bir seri kullanım durumları halinde inceleyeceğiz. Sonrasında ihtiyaç duyduğunuz çalışma akışını bu örneklerden yola çıkarak oluşturabilirsiniz.
+
+### Commit Prensipleri ###
+
+Özel kullanım durumlarına bakmadan önce, commit mesajları hakkında küçük bir not düşelim. Commit oluşturmak ile ilgili iyi prensiplere sahip olmak ve bunlara uymayı sürdürmek Git ile çalışmayı ve diğer geliştiricilerle yapılan işbirliğini çok kolaylaştırır. Git projesinin kendisine gönderilen yamalar iyi commitler oluşturmak için bize birçok ipucu sunmaktadır. Aynı zamanda Git kaynak kodunda `Documentation/SubmittingPatches` dosyasını okuyabilirsiniz.
+
+Öncelikle, hiç bir beyaz-boşluk hatasını göndermek istemezsiniz. Git bunun kontrolü için kolay bir yol sunmaktadır. Commit etmeden önce `git diff --check` çalıştırırsanız, Git olası beyaz-boşluk hatalarını bulacak ve sizin için listeleyecektir. Bir örnek: (terminaldeki kırmızı renkler `X` ile değiştirilmiştir)
+
+	$ git diff --check
+	lib/simplegit.rb:5: trailing whitespace.
+	+    @git_dir = File.expand_path(git_dir)XX
+	lib/simplegit.rb:7: trailing whitespace.
+	+ XXXXXXXXXXX
+	lib/simplegit.rb:26: trailing whitespace.
+	+    def command(git_cmd)XXXX
+
+Eğer commit etmeden önce bu komutu çalıştırırsanız, neredeyse muhtemelen diğer geliştiricileri rahatsız edecek olan beyaz-boşlukları commit ediyor olduğunuzu görürsünüz.
+
+Her bir commit'i mantıklı bir biçimde ayrılmış olarak yapın. Yapabiliyorsanız, değişikliklerinizi olabildiğince hafif yapın. Yani tüm haftasonu 5 sorun üzerine çalışıp da Pazartesi günü hepsini tek bir devasa commit halinde göndermeyin. Haftasonu boyunca commit yapmadıysanız bile, Pazartesi günü staging alanını kullanarak çözdüğünüz sorunların her birini mantıklı mesajlar içeren ayrı commitler haline getirin. Eğer bazı değişiklikler aynı dosyayı etkiliyorsa `git add --patch` kullanarak dosyaları kısmı olarak staginge almaya çalışın (6. bölümde bahsedeceğiz). 5 commit ya da tek commit yaptığınızda projenin sonuçtaki hali değişmez. Ama sizinle birlikte çalışanların işlerini neden zorlaştıralım ki? Bu yaklaşım aynı zamanda gerekirse değişikliklerden birini ya da birkaçını çıkarmak ya da geri çevirmek gerektiğinde de çok işe yarayacaktır. 6. Bölüm geçmişi baştan yazmak ve dosyaları interaktif olarak stage etmek için gerekli olan birçok kullanışlı Git ipuçlarını içermektedir. Temiz ve anlaşılabilir bir geçmiş oluşturmak için bu araçları kullanın.
+
+Aklımızdan çıkarmamamız gereken son şey ise commit mesajıdır. Kaliteli ve anlaşılabilir commit mesajları yazmayı alışkanlık haline getirmek Git ile çalışmayı ve işbirliği yapmayı çok kolaylaştıracaktır. Genel bir kural olarak, mesajınız 50 karakterden uzun olmayan ve değişiklikleri kısaca anlatan bir satır ardından bir boş satır ve devamında ayrıntılı bir açıklama şeklinde olmalıdır. Git projesinde bu detaylı açıklamanızın sizi bu değişikliğe iten sebepleri ve sizin yaptığınızla önceki arasındaki farkları açıklamanız istenmektedir. Aşağıdaki örnek ilk olarak Tim Pope tarafından tpope.net'te İngilizce olarak yazılmıştır:
+
+	Kısa (50 ya da daha az karakter) bir özet
+
+	Gerekiyorsa, daha detaylı ve açıklayıcı bir metin. Satır uzunluğunu
+	72 karakter civarında tutmaya çalışın. İlk satırı bir e-mailin konusu
+	ve bu metni de mailin kendisi olarak düşünebilirsiniz. Boş satır
+	ise konu ve mailin metnini ayırmaktadır. Eğer detaylı metin yazıyorsanız
+	bu boş satır önemlidir çünkü kullanmadığınız durumlarda rebase gibi
+	araçlar karışık hale gelebilir.
+
+	Yeni paragraf yazmanız gerektiğinde yine boş bir satır bırakın.
+
+	 - Bullet listeler de kullanılabilir
+
+	 - Tipik olarak bir tire ya da yıldızı takip eden bir boşluk ve metin şeklinde
+	  liste elemanları oluşturulabilir.
+
+Eğer tüm commit mesajlarınız böyle görünürse, herşey siz ve birlikte çalıştığınız geliştiriciler için daha kolay olacaktır. Git projesinin kendisi çok iyi formatlanmış commit mesajlarına sahiptir. İyi formatlanmış commit mesajlarına sahip bir proje geçmişinin nasıl göründüğünü görmeniz için sizi, Git projesi üzerinde `git log --no-merges` komutunu çalıştırmaya davet ediyorum.
+
+Bu kitabın tamamı boyunca sadelik uğruna mesajları böyle güzel biçimde yazmayacağım. Bunun yerine `git commit` komutunu `-m` ayarı ile çağırarak mesajlarını yazacağım. İmamın dediğini yap, yaptığını yapma :)
+
+### Özel(dışarıya kapalı) Küçük Takım ###
+
+Muhtemelen karşılacağınız en temel senaryo, özel bir projeye üzerinde çalışan iki veya daha fazla geliştiricidir. Özel derken, kapalı kaynaklı ve proje dışındaki insanlar tarafından kaynağı görülemeyen projelerden bahsediyorum. Siz ve tüm geliştiriciler projeye yazma hakkına sahipler.
+
+Bu ortamda, Subversion ya da başka bir merkezi sistemde takip ettiğiniz çalışma akışını takip edebilirsiniz. Offline commit ve büyük ölçüde daha kolay olan branchler ve birleştirmenin avantajlarını halen kullanabilirsiniz. Ama çalışma akışı halen çok benzer olabilir, en temel fark ise birleştirmelerin sunucuda olması yerine istemci tarafında commit anında olmasıdır.
+İki geliştiricinin ortak bir repoda çalışmaya başlamasıyla ne olacağına bakalım. İlk geliştirici Burak repoyu klonlar, bir değişiklik yapar ve yerel olarak commit eder. (Örnekleri kısaltmak adına protokol mesajları yerine `...` yazıyorum)
+
+	# Burak's Machine
+	$ git clone john@githost:simplegit.git
+	Initialized empty Git repository in /home/burak/simplegit/.git/
+	...
+	$ cd simplegit/
+	$ vim lib/simplegit.rb
+	$ git commit -am 'geçersiz varsayılan değer kaldırıldı'
+	[master 738ee87] geçersiz varsayılan değer kaldırıldı
+	 1 files changed, 1 insertions(+), 1 deletions(-)
+
+İkinci geliştirici Nesrin de aynı şeyi yapar. Repoyu klonlar ve bir değişiklik commit eder:
+
+	# Nesrin's Machine
+	$ git clone nesrin@githost:simplegit.git
+	Initialized empty Git repository in /home/nesrin/simplegit/.git/
+	...
+	$ cd simplegit/
+	$ vim TODO
+	$ git commit -am 'sıfırlama görevi eklendi'
+	[master fbff5bc] sıfırlama görevi eklendi
+	 1 files changed, 1 insertions(+), 0 deletions(-)
+
+Şimdi Nesrin çalışmasını uzak sunucudaki repoya pushlar:
+
+	# Nesrin's Machine
+	$ git push origin master
+	...
+	To nesrin@githost:simplegit.git
+	   1edee6b..fbff5bc  master -> master
+
+Burak da kendi değişikliğini pushlamaya çalışır:
+
+	# Burak's Machine
+	$ git push origin master
+	To burak@githost:simplegit.git
+	 ! [rejected]        master -> master (non-fast forward)
+	error: failed to push some refs to 'burak@githost:simplegit.git'
+
+Burak'a izin verilmez çünkü o esnada Nesrin push yapmıştır. Eğer önceden Subversion kullandıysanız bunu anlamanız önemlidir. 2 geliştirici farklı dosyaları düzenlemiştir. Eğer farklı dosyalarda değişiklik yapıldıysa Subversion otomatik olarak sunucuda bir birleştirme yapacaktır. Git'te ise commitleri kendi yerelinizde birleştirmelisiniz. Burak push yapmadan önce Nesrin'in değişikliklerini kendisine çekmeli, ve kendi değişiklikleriyle birleştirmelidir:
+
+	$ git fetch origin
+	...
+	From burak@githost:simplegit
+	 + 049d078...fbff5bc master     -> origin/master
+
+Bu noktada Burak'ın yerel reposu Resım 5-4'teki gibi gorunecektir.
+
+Insert 18333fig0504.png
+Figure 5-4. Burak'ın baştakı reposu.
+
+Artık Burak Nesrin'in yaptığı değişikliklerin bir referansına sahip. Şimdi kendi değişiklikleri ile Nesrin'in değişikliklerini birleştirip sonrasında repoya push edebilir.
+
+	$ git merge origin/master
+	Merge made by recursive.
+	 TODO |    1 +
+	 1 files changed, 1 insertions(+), 0 deletions(-)
+
+Eğer birleştirme sorunsuz giderse Burak'ın commit geçmişi Resim 5-5deki gibi olacaktır.
+
+Insert 18333fig0505.png
+Figure 5-5. `origin/master` ile birleştirdikten sonra Burak'ın reposu.
+
+Şimdi, Burak herşeyin hala düzgün olduğundan emin olmak için test edip ardından değişikliklerini sunucuya gönderebilir:
+
+	$ git push origin master
+	...
+	To burak@githost:simplegit.git
+	   fbff5bc..72bbc59  master -> master
+
+Sonuç olarak Burak'ın commit geçmişi Resim 5-6daki gibi görünür.
+
+Insert 18333fig0506.png
+Figure 5-6. Origin sunucuya gönderdikten sonra Burak'ın commit geçmişi.
+
+Aynı esnada Nesrin de bir konu branchinde çalışmaktadır. `issue54` isminde bir branch oluşturmuş ve bu branche 3 commit yapmıştır ve henüz Burak'ın yaptığı değişiklileri kendisine çekmemiştir. Commit geçmişi Resim 5-7deki gibidir.
+
+Insert 18333fig0507.png
+Figure 5-7. Nesrin'in baştaki commit geçmişi.
+
+Nesrin Burak ile senkronize olmak ister ve fetch eder:
+
+	# Nesrin's Machine
+	$ git fetch origin
+	...
+	From nesrin@githost:simplegit
+	   fbff5bc..72bbc59  master     -> origin/master
+
+Bu Burak'ın pushladığı çalışmaları çeker. Jessica'nın geçmişi şimdi Resim 5-8deki gibidir.
+
+Insert 18333fig0508.png
+Figure 5-8. Burak'ın değişikliklerini fetch ettikten sonra Nesrin'in geçmişi.
+
+Nesrin kendi branchinin hazır olduğunu düşünür, fakat neleri birleştirmesi gerektiğini görmek istemektedir. `git log` çalıştırarak bunu görebilir:
+
+	$ git log --no-merges origin/master ^issue54
+	commit 738ee872852dfaa9d6634e0dea7a324040193016
+	Author: Burak Can <bcan@example.com>
+	Date:   Fri May 29 16:01:27 2009 -0700
+
+	    geçersiz varsayılan değer kaldırıldı
\ No newline at end of file

From 904748994541dd6967d88e1e1e848151551f9a1c Mon Sep 17 00:00:00 2001
From: Jean-Noel Avila <jn.avila@free.fr>
Date: Tue, 14 Oct 2014 22:50:52 +0200
Subject: [PATCH 657/690] Fix tab mistakes in tables

This fix is not totally bullet proof, because for cjk languages, the
characters have a double width. The script that transforms the tab
aligned values into a markdown table are not ready for double width characters.
---
 ko/02-git-basics/01-chapter2.markdown | 12 ++++++------
 nl/02-git-basics/01-chapter2.markdown |  2 +-
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/ko/02-git-basics/01-chapter2.markdown b/ko/02-git-basics/01-chapter2.markdown
index da62f4c31..58f792191 100644
--- a/ko/02-git-basics/01-chapter2.markdown
+++ b/ko/02-git-basics/01-chapter2.markdown
@@ -614,15 +614,15 @@ The lines must be formatted as follows
 <TAB><First column text><TAB><Second column text>
 -->
 
-	옵션  설명
+	옵션	설명
 	-p	각 커밋에 적용된 패치를 보여준다.
 	--word-diff	diff 결과를 단어 단위로 보여준다.
 	--stat	각 커밋에서 수정된 파일의 통계정보를 보여준다.
-	--shortstat	 `--stat` 명령의 결과 중에서 수정한 파일, 추가된 줄, 삭제된 줄만 보여준다.
-	--name-only	 커밋 정보중에서 수정된 파일의 목록만 보여준다.
-	--name-status	 수정된 파일의 목록을 보여줄 뿐만 아니라 파일을 추가한 것인지, 수정한 것인지, 삭제한 것인지도 보여준다.
-	--abbrev-commit	 40자 짜리 SHA-1 체크섬을 전부 보여주는 것이 아니라 처음 몇 자만 보여준다.
-	--relative-date	 정확한 시간을 보여주는 것이 아니라 `2 주전`처럼 상대적인 형식으로 보여준다.
+	--shortstat	`--stat` 명령의 결과 중에서 수정한 파일, 추가된 줄, 삭제된 줄만 보여준다.
+	--name-only	커밋 정보중에서 수정된 파일의 목록만 보여준다.
+	--name-status	수정된 파일의 목록을 보여줄 뿐만 아니라 파일을 추가한 것인지, 수정한 것인지, 삭제한 것인지도 보여준다.
+	--abbrev-commit	40자 짜리 SHA-1 체크섬을 전부 보여주는 것이 아니라 처음 몇 자만 보여준다.
+	--relative-date	정확한 시간을 보여주는 것이 아니라 `2 주전`처럼 상대적인 형식으로 보여준다.
 	--graph	브랜치와 머지 히스토리 정보까지 아스키 그래프로 보여준다.
 	--pretty	지정한 형식으로 보여준다. 이 옵션에는 oneline, short, full, fuller, format이 있다. format은 원하는 형식으로 출력하고자 할 때 사용한다.
 	--oneline	`--pretty=oneline --abbrev-commit` 옵션을 함께 사용한 것과 동일하다.
diff --git a/nl/02-git-basics/01-chapter2.markdown b/nl/02-git-basics/01-chapter2.markdown
index a87e88310..571dc9150 100644
--- a/nl/02-git-basics/01-chapter2.markdown
+++ b/nl/02-git-basics/01-chapter2.markdown
@@ -655,7 +655,7 @@ The lines must be formatted as follows
 	--name-status	Toon ook de lijst van bestanden die beïnvloed zijn door de toegevoegde/gewijzigde/verwijderde informatie.
 	--abbrev-commit	Toon alleen de eerste paar karakters van de SHA-1 checksum in plaats van alle 40.
 	--relative-date	Toon de datum in een relatief formaat (bijvoorbeeld, "2 weken geleden"), in plaats van het volledige datum formaat.
-	--graph		Toon een ASCII grafiek van de branch- en merge-geschiedenis naast de log output.
+	--graph	Toon een ASCII grafiek van de branch- en merge-geschiedenis naast de log output.
 	--pretty	Toon commits in een alternatief formaat. De opties bevatten oneline, short, full, fuller, en format (waarbij je je eigen formaat specificeert).
 	--oneline	Een gemaks-optie, staat voor `--pretty=oneline --abbrev-commit`.
 

From 0fed91962aa670319a2451f54540d7944b6e3eac Mon Sep 17 00:00:00 2001
From: Ryo Inoue <rinopo@users.noreply.github.com>
Date: Wed, 15 Oct 2014 00:51:25 +0900
Subject: [PATCH 658/690] Improve translation (Ch. 1.3)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

原文：
> Git stores and thinks about information much differently than these other systems, even though the user interface is fairly similar;
---
 ja/01-introduction/01-chapter1.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ja/01-introduction/01-chapter1.markdown b/ja/01-introduction/01-chapter1.markdown
index 8f779f48d..a02b234e4 100644
--- a/ja/01-introduction/01-chapter1.markdown
+++ b/ja/01-introduction/01-chapter1.markdown
@@ -57,7 +57,7 @@ Insert 18333fig0103.png
 ## Gitの基本 ##
 
 では、要するにGitとは何なのでしょうか。これは、Gitを吸収するには重要な節です。なぜならば、もしGitが何かを理解し、Gitがどうやって稼動しているかの根本を理解できれば、Gitを効果的に使う事が恐らくとても容易になるからです。
-Gitを学ぶときは、SubversionやPerforceのような他のVCSsに関してあなたが恐らく知っていることは、意識しないでください。このツールを使うときに、ちょっとした混乱を回避することに役立ちます。Gitは、ユーザー・インターフェイスがとてもよく似ているのにも関わらず、それら他のシステムとは大きく異なって、情報を格納して取り扱います（訳者注：「取り扱う」の部分はthinksなので、「見なします」と訳す方が原語に近い）。これらの相違を理解する事は、Gitを扱っている間の混乱を、防いでくれるでしょう。
+Gitを学ぶときは、SubversionやPerforceのような他のVCSsに関してあなたが恐らく知っていることは、意識しないでください。このツールを使うときに、ちょっとした混乱を回避することに役立ちます。ユーザー・インターフェイスがよく似ているにも関わらず、Gitの情報の格納の仕方や情報についての考え方は、それら他のシステムとは大きく異なっています。これらの相違を理解する事は、Gitを扱っている間の混乱を、防いでくれるでしょう。
 
 ### スナップショットで、差分ではない ###
 

From 04b3b3231c455cfc25716b72b46f013243c0d4bc Mon Sep 17 00:00:00 2001
From: Hiroshi Manabe <manabe.hiroshi@gmail.com>
Date: Thu, 16 Oct 2014 23:24:28 +0900
Subject: [PATCH 659/690] [ja] Revised the translation (chapter 01).

---
 ja/01-introduction/01-chapter1.markdown | 23 +++++++++++------------
 1 file changed, 11 insertions(+), 12 deletions(-)

diff --git a/ja/01-introduction/01-chapter1.markdown b/ja/01-introduction/01-chapter1.markdown
index a02b234e4..afdbfaa44 100644
--- a/ja/01-introduction/01-chapter1.markdown
+++ b/ja/01-introduction/01-chapter1.markdown
@@ -1,44 +1,43 @@
 # 使い始める #
 
-この章は、Gitを使い始めることに関してになります。まずはバージョン管理システムの背景に触れ、その後にGitをあなたのシステムで動かす方法、そしてGitで作業を始めるための設定方法について説明します。この章を読み終えるころには、なぜGitが広まっているか、なぜGitを使うべきなのか、それをするための準備が全て整っているだろうということを、あなたはきっと理解しているでしょう。
+この章は、Gitを使い始めることについてのものです。まずはバージョン管理システムの背景に触れ、次にGitをあなたのシステムで動かす方法、最後にGitで作業を始めるための設定方法について説明します。この章を読み終えるころには、なぜGitがあるのか、なぜGitを使うべきなのかを理解し、また使い始めるための準備が全て整っていることと思います。
 
 ## バージョン管理に関して ##
 
-バージョン管理とは何でしょうか、また、なぜそれを気にする必要があるのでしょうか？
-バージョン管理とは、変更を一つのファイル、もしくは時間を通じたファイルの集合に記録するシステムで、そのため後で特定バージョンを呼び出すことができます。現実にはコンピューター上のほとんどあらゆるファイルのタイプでバージョン管理を行なう事ができますが、本書の中の例では、バージョン管理されるファイルとして、ソフトウェアのソースコードを利用します。
+バージョン管理とは何でしょうか。また、なぜそれを気にする必要があるのでしょうか。バージョン管理とは、一つのファイルやファイルの集合に対して時間とともに加えられていく変更を記録するシステムで、後で特定バージョンを呼び出すことができるようにするためのものです。本書の例では、バージョン管理されるファイルとしてソフトウェアのソースコードを示していますが、実際にはコンピューター上のあらゆる種類のファイルをバージョン管理のもとに置くことができます。
 
-もしあなたが、グラフィックス・デザイナー、もしくはウェブ・デザイナーであって、（あなたが最も確実に望んでいるであろう）画像もしくはレイアウトの全てのバージョンを管理したいのであれば、バージョン管理システム（VCS）はとても賢く利用できるものです｡VCSを使ってできることとしては、ファイルを以前の状態まで戻したり、プロジェクト丸ごとを以前の状態に戻したり、過去の変更を見直したり、誰が最後に問題を引き起こすだろう何かを修正したか、誰が、何時、課題を導入したかを確認したりといった様々なことがあります。VCSを使うということはまた、一般的に、何かをもみくちゃにするか、ファイルを失うとしても、簡単に復活させることができることを意味します。加えて、とても僅かな諸経費で、それら全てを得ることができます。
+もしあなたがグラフィックス・デザイナーやウェブ・デザイナーで、画像やレイアウトの全てバージョンを保存しておきたいとすると（きっとそうしたいですよね）、バージョン管理システム（VCS）を使うというのはいい考えです。VCSを使うことで、ファイルを以前の状態まで戻したり、プロジェクト丸ごとを以前の状態に戻したり、過去の変更履歴を見直したり、問題が起こっているかもしれないものを誰が最後に修正したか、誰がいつ問題点を混入させたかを確認したりといった様々なことができるようになります。また、VCSを使うと、やっていることがめちゃくちゃになってしまったり、ファイルを失ったりしても、普通は簡単に復活させることができるようになります。それに、これらのことにかかるオーバーヘッドは僅かなものです。
 
 ### ローカル・バージョン管理システム ###
 
-多くの人々の選り抜きのバージョン管理手法は、他のディレクトリ（もし彼らが賢いのであれば、恐らく日時が書かれたディレクトリ）にファイルをコピーするというものです。このアプローチは、とても単純なためにすごく一般的ですが、信じられない間違い傾向もあります。どのディレクトリにいるのか忘れやすいですし、偶然に間違ったファイルに書き込んだり、意図しないファイルに上書きしたりします。
+多くの人々が使っているバージョン管理手法は、他のディレクトリ（気の利いた人であれば、日時のついたディレクトリ）にファイルをコピーするというものです。このアプローチはとても単純なので非常に一般的ですが、信じられないほど間違いが起こりやすいものです。どのディレクトリにいるのか忘れやすく、うっかり間違ったファイルに書き込んだり、上書きするつもりのないファイルを上書きしてしまったりします。
 
-この問題を扱うため、大昔にプログラマは、バージョン管理下で全ての変更をファイルに保持するシンプルなデータベースを持つ、ローカルなバージョン管理システムを開発しました（図1-1参照）。
+この問題を扱うため、はるか昔のプログラマは、ローカルのVCSを開発しました。それは、バージョン管理下のファイルに対する全ての変更を保持するシンプルなデータベースによるものでした（図1-1参照）。
 
 Insert 18333fig0101.png
 図1-1. ローカル・バージョン管理図解
 
-もっとも有名なVCSツールの一つが、RCSと呼ばれるシステムでした。今日でも依然として多くのコンピューターに入っています。人気のMac OS Xオペレーティング・システムさえも、開発者ツールをインストールしたときは、rcsコマンドを含みます。このツールは基本的に、ディスク上に特殊フォーマットで、一つのリビジョンからもう一つのリビジョンへのパッチ（これはファイル間の差分です）の集合を保持することで稼動します。そういうわけで、全てのパッチを積み上げることで、いつかは、あらゆる時点の、あらゆるファイルのように見えるものを再生成する事ができます。
+もっとも有名なVCSツールの一つは、RCSと呼ばれるシステムでした。今日でも、依然として多くのコンピューターに入っています。人気のMac OS Xオペレーティング・システムでも、開発者ツールをインストールするとrcsコマンドが入っています。このツールは基本的に、リビジョン間のパッチ（ファイル間の差分）の集合を特殊なフォーマットでディスク上に保持するという仕組みで動いています。こうすることで、任意のファイルについて、それが過去の任意の時点でどういうものだったかということを、パッチを重ね上げていくことで再現することができます。
 
 ### 集中バージョン管理システム ###
 
-次に人々が遭遇した大きな問題は、他のシステムの開発者と共同制作をする必要があることです。この問題に対処するために、集中バージョン管理システム（CVCSs）が開発されました。CVSやSubversion、Perforceのような、これらのシステムは、全てのバージョン管理されたファイルと、その中央の場所からファイルをチェック・アウトする多数のクライアントを含む単一のサーバーを持ちます。長年の間、これはバージョン管理の標準となって来ました（図1-2参照）。
+次に人々が遭遇した大きな問題は、他のシステムを使う開発者と共同作業をする必要があるということです。この問題に対処するために、集中バージョン管理システム（CVCSs）が開発されました。このようなシステムにはCVS、Subversion、Perforceなどがありますが、それらは全てのバージョン管理されたファイルを持つ一つのサーバーと、その中心点からファイルをチェックアウトする多数のクライアントからなっています。長年の間、これはバージョン管理の標準でした（図1-2参照）。
 
 Insert 18333fig0102.png
 図1-2. 集中バージョン管理図解
 
-この構成は、特にローカルVCSと比較して、多くの利点を提供します。例えば、全ての人は、プロジェクトのその他の全ての人々が何をしているのか、一定の程度は知っています。管理者は、誰が何をできるのかについて、きめ細かい統制手段を持ちます。このため、一つのCVCSを管理するということは、全てのクライアントのローカル・データベースを取り扱うより、はるかに容易です。
+この構成には、特にローカルVCSと比べると、多くの利点があります。例えば、プロジェクトのその他の全ての人々が何をしているのか、全員がある程度は知っています。管理者は、誰が何をできるのかについて、きめ細かくコントロールできます。それに、一つのCVCSを管理するのは、全てのクライアントのローカル・データベースを取り扱うより、はるかに容易です。
 
-しかしながら、この構成はまた、深刻な不利益も持ちます。もっとも明白なのは、中央サーバーで発生する単一障害点です。もし、そのサーバーが1時間の間停止すると、その1時間の間は誰も全く、共同作業や、彼らが作業を進めている全てに対してバージョン変更の保存をすることができなくなります。もし中央データベースがのっているハードディスクが破損し、適切なバックアップが保持されていないとすると、人々が偶然にローカル・マシンに持っていた幾らかの単一スナップショット（訳者注：ある時点のファイル、ディレクトリなどの編集対象の状態）を除いた、プロジェクト全体の履歴を失うことになります。ローカルVCSシステムも、これと同じ問題に悩まされます。つまり、単一の場所にプロジェクトの全体の履歴を持っているときはいつでも、全てを失う事を覚悟することになります。
+しかし、この構成には深刻なマイナス面もあります。もっとも明白なのは、中央サーバーという単一障害点です。そのサーバーが1時間の間停止すると、その1時間の間は全員が、共同作業も全くできず、作業中のものにバージョンをつけて保存をすることもできなくなります。もし中央データベースのあるハードディスクが破損し、適切なバックアップが保持されていなければ、完全に全てを失ってしまいます。プロジェクトの全ての履歴は失われ、残るのは個人のローカル・マシンにたまたまあった幾らかの単一スナップショット（訳者注：ある時点のファイル、ディレクトリなどの編集対象の状態）ぐらいです。ローカルVCSシステムも、これと同じ問題があります。つまり、一つの場所にプロジェクトの全体の履歴を持っていると、全てを失うリスクが常にあります。
 
 ### 分散バージョン管理システム ###
 
-ここから分散バージョン管理システム(DVCSs)に入ります。DVCS(Git、Mercurial、Bazaar、Darcsのようなもの)では、クライアントはファイルの最新スナップショットをチェックアウト（訳者注：バージョン管理システムから、作業ディレクトリにファイルやディレクトリをコピーすること）するだけではありません。リポジトリ（訳者注：バージョン管理の対象になるファイル、ディレクトリ、更新履歴などの一群）全体をミラーリングします。故にどのサーバーが故障したとして、故障したサーバーを介してそれらのDVCSが共同作業をしていたとしても、あらゆるクライアント・リポジトリは修復のためにサーバーにコピーして戻す事ができます。そのサーバーを介してコラボレーションしていたシステムは, どれか一つのクライアントのリポジトリからサーバー復旧の為バックアップをコピーすることができます. 全てのチェックアウトは、実は全データの完全バックアップなのです(図1-3を参照)。
+ここで分散バージョン管理システム(DVCSs)の出番になります。DVCS(Git、Mercurial、Bazaar、Darcsのようなもの)では、クライアントはファイルの最新スナップショットをチェックアウト（訳者注：バージョン管理システムから、作業ディレクトリにファイルやディレクトリをコピーすること）するだけではありません。リポジトリ（訳者注：バージョン管理の対象になるファイル、ディレクトリ、更新履歴などの一群）全体をミラーリングするのです。そのため、あるサーバーが故障して、DVCSがそのサーバーを介して共同作業をしていたとしても、どれでもいいのでクライアント・リポジトリの一つをサーバーにコピーすれば修復できます。チェックアウトは全て、実際は全データの完全バックアップなのです(図1-3を参照)。
 
 Insert 18333fig0103.png
 図1-3. 分散バージョン管理システムの図解
 
-そのうえ、これらのDVCSの多くは、 連携する複数のリモート・リポジトリを扱いながら大変よく機能するため、同一のプロジェクト内において、同時に異なった方法で、異なる人々のグループと共同作業が可能です。このことは、集中システムでは不可能であった階層モデルのような、幾つかの様式のワークフローを始めることを許します。
+さらに、これらのDVCSの多くは、複数のリモート・リポジトリで作業をするということがうまく扱えるようになっているので、異なった方法で異なる人々のグループと同時に同じプロジェクト内で共同作業することができます。このため、階層モデルなどの、集中システムでは不可能な幾つかのワークフローが構築できるようになっています。
 
 ## Git略史 ##
 

From 1e136d26f3beb70739a3eb3986a9a0afb48f9f42 Mon Sep 17 00:00:00 2001
From: Hiroshi Manabe <manabe.hiroshi@gmail.com>
Date: Fri, 17 Oct 2014 21:21:37 +0900
Subject: [PATCH 660/690] [ja] Fixed the translation according to the advices.

---
 ja/01-introduction/01-chapter1.markdown | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/ja/01-introduction/01-chapter1.markdown b/ja/01-introduction/01-chapter1.markdown
index afdbfaa44..97f5d508b 100644
--- a/ja/01-introduction/01-chapter1.markdown
+++ b/ja/01-introduction/01-chapter1.markdown
@@ -6,7 +6,7 @@
 
 バージョン管理とは何でしょうか。また、なぜそれを気にする必要があるのでしょうか。バージョン管理とは、一つのファイルやファイルの集合に対して時間とともに加えられていく変更を記録するシステムで、後で特定バージョンを呼び出すことができるようにするためのものです。本書の例では、バージョン管理されるファイルとしてソフトウェアのソースコードを示していますが、実際にはコンピューター上のあらゆる種類のファイルをバージョン管理のもとに置くことができます。
 
-もしあなたがグラフィックス・デザイナーやウェブ・デザイナーで、画像やレイアウトの全てバージョンを保存しておきたいとすると（きっとそうしたいですよね）、バージョン管理システム（VCS）を使うというのはいい考えです。VCSを使うことで、ファイルを以前の状態まで戻したり、プロジェクト丸ごとを以前の状態に戻したり、過去の変更履歴を見直したり、問題が起こっているかもしれないものを誰が最後に修正したか、誰がいつ問題点を混入させたかを確認したりといった様々なことができるようになります。また、VCSを使うと、やっていることがめちゃくちゃになってしまったり、ファイルを失ったりしても、普通は簡単に復活させることができるようになります。それに、これらのことにかかるオーバーヘッドは僅かなものです。
+もしあなたがグラフィックス・デザイナーやウェブ・デザイナーで、画像やレイアウトの全てのバージョンを保存しておきたいとすると（きっとそうしたいですよね）、バージョン管理システム（VCS）を使うというのはいい考えです。VCSを使うことで、ファイルを以前の状態まで戻したり、プロジェクト丸ごとを以前の状態に戻したり、過去の変更履歴を見直したり、問題が起こっているかもしれないものを誰が最後に修正したか、誰がいつ問題点を混入させたかを確認したりといった様々なことができるようになります。また、VCSを使うと、やっていることがめちゃくちゃになってしまったり、ファイルを失ったりしても、普通は簡単に復活させることができるようになります。それに、これらのことにかかるオーバーヘッドは僅かなものです。
 
 ### ローカル・バージョン管理システム ###
 
@@ -21,18 +21,18 @@ Insert 18333fig0101.png
 
 ### 集中バージョン管理システム ###
 
-次に人々が遭遇した大きな問題は、他のシステムを使う開発者と共同作業をする必要があるということです。この問題に対処するために、集中バージョン管理システム（CVCSs）が開発されました。このようなシステムにはCVS、Subversion、Perforceなどがありますが、それらは全てのバージョン管理されたファイルを持つ一つのサーバーと、その中心点からファイルをチェックアウトする多数のクライアントからなっています。長年の間、これはバージョン管理の標準でした（図1-2参照）。
+次に人々が遭遇した大きな問題は、他のシステムを使う開発者と共同作業をする必要があるということです。この問題に対処するために、集中バージョン管理システム（CVCSs）が開発されました。このようなシステムにはCVS、Subversion、Perforceなどがありますが、それらはバージョン管理されたファイルを全て持つ一つのサーバーと、その中心点からファイルをチェックアウトする多数のクライアントからなっています。長年の間、これはバージョン管理の標準でした（図1-2参照）。
 
 Insert 18333fig0102.png
 図1-2. 集中バージョン管理図解
 
-この構成には、特にローカルVCSと比べると、多くの利点があります。例えば、プロジェクトのその他の全ての人々が何をしているのか、全員がある程度は知っています。管理者は、誰が何をできるのかについて、きめ細かくコントロールできます。それに、一つのCVCSを管理するのは、全てのクライアントのローカル・データベースを取り扱うより、はるかに容易です。
+この構成には、特にローカルVCSと比べると、多くの利点があります。例えば、プロジェクトの他のみんなが何をしているのか、全員がある程度わかります。管理者は、誰が何をできるのかについて、きめ細かくコントロールできます。それに、一つのCVCSを管理するのは、全てのクライアントのローカル・データベースを取り扱うより、ずっと簡単です。
 
 しかし、この構成には深刻なマイナス面もあります。もっとも明白なのは、中央サーバーという単一障害点です。そのサーバーが1時間の間停止すると、その1時間の間は全員が、共同作業も全くできず、作業中のものにバージョンをつけて保存をすることもできなくなります。もし中央データベースのあるハードディスクが破損し、適切なバックアップが保持されていなければ、完全に全てを失ってしまいます。プロジェクトの全ての履歴は失われ、残るのは個人のローカル・マシンにたまたまあった幾らかの単一スナップショット（訳者注：ある時点のファイル、ディレクトリなどの編集対象の状態）ぐらいです。ローカルVCSシステムも、これと同じ問題があります。つまり、一つの場所にプロジェクトの全体の履歴を持っていると、全てを失うリスクが常にあります。
 
 ### 分散バージョン管理システム ###
 
-ここで分散バージョン管理システム(DVCSs)の出番になります。DVCS(Git、Mercurial、Bazaar、Darcsのようなもの)では、クライアントはファイルの最新スナップショットをチェックアウト（訳者注：バージョン管理システムから、作業ディレクトリにファイルやディレクトリをコピーすること）するだけではありません。リポジトリ（訳者注：バージョン管理の対象になるファイル、ディレクトリ、更新履歴などの一群）全体をミラーリングするのです。そのため、あるサーバーが故障して、DVCSがそのサーバーを介して共同作業をしていたとしても、どれでもいいのでクライアント・リポジトリの一つをサーバーにコピーすれば修復できます。チェックアウトは全て、実際は全データの完全バックアップなのです(図1-3を参照)。
+ここで分散バージョン管理システム(DVCSs)の出番になります。DVCS(Git、Mercurial、Bazaar、Darcsのようなもの)では、クライアントはファイルの最新スナップショットをチェックアウト（訳者注：バージョン管理システムから、作業ディレクトリにファイルやディレクトリをコピーすること）するだけではありません。リポジトリ（訳者注：バージョン管理の対象になるファイル、ディレクトリ、更新履歴などの一群）全体をミラーリングするのです。そのため、あるサーバーが故障して、DVCSがそのサーバーを介して連携していたとしても、どれでもいいのでクライアント・リポジトリの一つをサーバーにコピーすれば修復できます。チェックアウトは全て、実際は全データの完全バックアップなのです(図1-3を参照)。
 
 Insert 18333fig0103.png
 図1-3. 分散バージョン管理システムの図解

From 1ea1ef4bf15ce6488856653f3950e618bb30ca0a Mon Sep 17 00:00:00 2001
From: JuanLuM <julumogo@gmail.com>
Date: Tue, 21 Oct 2014 11:41:40 +0200
Subject: [PATCH 661/690] Improve understanding what git does

---
 es/03-git-branching/01-chapter3.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/es/03-git-branching/01-chapter3.markdown b/es/03-git-branching/01-chapter3.markdown
index 44f715729..f8aa9eb93 100644
--- a/es/03-git-branching/01-chapter3.markdown
+++ b/es/03-git-branching/01-chapter3.markdown
@@ -15,7 +15,7 @@ Para ilustrar esto, vamos a suponer, por ejemplo, que tienes una carpeta con tre
 	$ git add README test.rb LICENSE
 	$ git commit -m 'initial commit of my project'
 
-Cuando creas una confirmación con el comando `git commit`, Git realiza sumas de control de cada subcarpeta (en el ejemplo, solamente tenemos la carpeta principal del proyecto), y guarda en el repositorio Git una copia de cada uno de los archivos contenidos en ella/s. Después, Git crea un objeto de confirmación con los metadatos pertinentes y un apuntador al nodo correspondiente del árbol de proyecto. Esto permitirá poder regenerar posteriormente dicha instantánea cuando sea necesario.
+Cuando creas una confirmación con el comando `git commit`, Git realiza sumas de control de cada subcarpeta (en el ejemplo, solamente tenemos la carpeta principal del proyecto), y las guarda como objetos árbol en el repositorio Git. Después, Git crea un objeto de confirmación con los metadatos pertinentes y un apuntador al objeto árbol raiz del proyecto. Esto permitirá poder regenerar posteriormente dicha instantánea cuando sea necesario.
 
 En este momento, el repositorio de Git contendrá cinco objetos: un "blob" para cada uno de los tres archivos, un árbol con la lista de contenidos de la carpeta (más sus respectivas relaciones con los "blobs"), y una confirmación de cambios (commit) apuntando a la raiz de ese árbol y conteniendo el resto de metadatos pertinentes. Conceptualmente, el contenido del repositorio Git será algo parecido a la Figura 3-1
 

From 1a0218935d778012c845a04b890729410f9380ee Mon Sep 17 00:00:00 2001
From: JuanLuM <julumogo@gmail.com>
Date: Wed, 22 Oct 2014 09:03:21 +0200
Subject: [PATCH 662/690] Remove errata - 01-chapter3.markdown - es

---
 es/03-git-branching/01-chapter3.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/es/03-git-branching/01-chapter3.markdown b/es/03-git-branching/01-chapter3.markdown
index f8aa9eb93..cd69282b4 100644
--- a/es/03-git-branching/01-chapter3.markdown
+++ b/es/03-git-branching/01-chapter3.markdown
@@ -174,7 +174,7 @@ Ahora, los cambios realizados están ya en la instantánea (snapshot) de la conf
 Insert 18333fig0314.png 
 Figura 3-14. Tras la fusión (merge), la rama `master` apunta al mismo sitio que la rama `hotfix`.
 
-Tras haber resuelto el problema urgente que te habií interrumpido tu trabajo, puedes volver a donde estabas. Pero antes, es interesante borrar la rama `hotfix`. Ya que no la vamos a necesitar más, puesto que apunta exactamente al mismo sitio que la rama `master`. Esto lo puedes hacer con la opción `-d` del comando `git branch`:
+Tras haber resuelto el problema urgente que te había interrumpido tu trabajo, puedes volver a donde estabas. Pero antes, es interesante borrar la rama `hotfix`. Ya que no la vamos a necesitar más, puesto que apunta exactamente al mismo sitio que la rama `master`. Esto lo puedes hacer con la opción `-d` del comando `git branch`:
 
 	$ git branch -d hotfix
 	Deleted branch hotfix (3a0874c).

From 7c1a2498e37b5ee245c57ed54168a7d678901ca9 Mon Sep 17 00:00:00 2001
From: JuanLuM <julumogo@gmail.com>
Date: Wed, 22 Oct 2014 13:17:15 +0200
Subject: [PATCH 663/690] Reorganize to improve understanding

---
 es/03-git-branching/01-chapter3.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/es/03-git-branching/01-chapter3.markdown b/es/03-git-branching/01-chapter3.markdown
index cd69282b4..7ba3c8877 100644
--- a/es/03-git-branching/01-chapter3.markdown
+++ b/es/03-git-branching/01-chapter3.markdown
@@ -424,7 +424,7 @@ Si tienes una rama llamada `serverfix`, con la que vas a trabajar en colaboraci
 
 Esto es un poco como un atajo. Git expande automáticamente el nombre de rama `serverfix` a `refs/heads/serverfix:refs/heads/serverfix`, que significa: "coge mi rama local `serverfix` y actualiza con ella la rama `serverfix` del remoto". Volveremos más tarde sobre el tema de `refs/heads/`, viéndolo en detalle en el capítulo 9; aunque puedes ignorarlo por ahora. También puedes hacer `git push origin serverfix:serverfix`, que hace lo mismo; es decir: "coge mi `serverfix` y hazlo el `serverfix` remoto". Puedes utilizar este último formato para llevar una rama local a una rama remota con otro nombre distinto. Si no quieres que se llame `serverfix` en el remoto, puedes lanzar, por ejemplo, `git push origin serverfix:awesomebranch`; para llevar tu rama `serverfix` local a la rama `awesomebranch` en el proyecto remoto.
 
-La próxima vez que tus colaboradores recuperen desde el servidor, obtendrán una referencia a donde la versión de `serverfix` en el servidor esté bajo la rama remota `origin/serverfix`:
+La próxima vez que tus colaboradores recuperen desde el servidor, obtendrán bajo la rama remota `origin/serverfix` una referencia a donde esté la versión de `serverfix` en el servidor:
 
 	$ git fetch origin
 	remote: Counting objects: 20, done.

From 7192c2693d709c1492f11bdf6bdf0c73e39ff454 Mon Sep 17 00:00:00 2001
From: Christian Sauer <sauerc@gmail.com>
Date: Wed, 22 Oct 2014 10:24:38 -0400
Subject: [PATCH 664/690] Fix git stash-unapply example

The example for `git stash-unapply` starts with `git stash` which will
create a new stash and not apply a stash to the working copy.  The first
command should be either `git stash apply` (which is what I changed it
to) or `git stash apply stash@{0}` or a variant thereof.
---
 az/06-git-tools/01-chapter6.markdown    | 2 +-
 cs/06-git-tools/01-chapter6.markdown    | 2 +-
 de/06-git-tools/01-chapter6.markdown    | 2 +-
 en/06-git-tools/01-chapter6.markdown    | 2 +-
 fr/06-git-tools/01-chapter6.markdown    | 2 +-
 it/06-git-tools/01-chapter6.markdown    | 2 +-
 ja/06-git-tools/01-chapter6.markdown    | 2 +-
 ko/06-git-tools/01-chapter6.markdown    | 2 +-
 nl/06-git-tools/01-chapter6.markdown    | 2 +-
 no-nb/06-git-tools/01-chapter6.markdown | 2 +-
 pl/06-git-tools/01-chapter6.markdown    | 2 +-
 pt-br/06-git-tools/01-chapter6.markdown | 2 +-
 ru/06-git-tools/01-chapter6.markdown    | 2 +-
 zh-tw/06-git-tools/01-chapter6.markdown | 2 +-
 zh/06-git-tools/01-chapter6.markdown    | 2 +-
 15 files changed, 15 insertions(+), 15 deletions(-)

diff --git a/az/06-git-tools/01-chapter6.markdown b/az/06-git-tools/01-chapter6.markdown
index a6f0108af..2b18d87e0 100644
--- a/az/06-git-tools/01-chapter6.markdown
+++ b/az/06-git-tools/01-chapter6.markdown
@@ -501,7 +501,7 @@ Again, if you don’t specify a stash, Git assumes the most recent stash:
 You may want to create an alias and effectively add a `stash-unapply` command to your git. For example:
 
     $ git config --global alias.stash-unapply '!git stash show -p | git apply -R'
-    $ git stash
+    $ git stash apply
     $ #... work work work
     $ git stash-unapply
 
diff --git a/cs/06-git-tools/01-chapter6.markdown b/cs/06-git-tools/01-chapter6.markdown
index 768f9c2f9..516af28d3 100644
--- a/cs/06-git-tools/01-chapter6.markdown
+++ b/cs/06-git-tools/01-chapter6.markdown
@@ -518,7 +518,7 @@ Jestliže nespecifikujete konkrétní odklad, Git předpokládá odklad posledn
 Můžete si také vytvořit alias a do svého gitu přidat například příkaz `stash-unapply`:
 
     $ git config --global alias.stash-unapply '!git stash show -p | git apply -R'
-    $ git stash
+    $ git stash apply
     $ #... work work work
     $ git stash-unapply
 
diff --git a/de/06-git-tools/01-chapter6.markdown b/de/06-git-tools/01-chapter6.markdown
index 0a16b2f0a..69f395bde 100644
--- a/de/06-git-tools/01-chapter6.markdown
+++ b/de/06-git-tools/01-chapter6.markdown
@@ -660,7 +660,7 @@ An dieser Stelle noch einmal der Hinweis, dass Git den zuletzt erstellten Stash
 Wenn Du dieses Feature öfters benötigst, ist es wahrscheinlich sinnvoll, einen Alias `stash-unapply` in Git dafür anzulegen:
 
     $ git config --global alias.stash-unapply '!git stash show -p | git apply -R'
-    $ git stash
+    $ git stash apply
     $ #... work work work
     $ git stash-unapply
 
diff --git a/en/06-git-tools/01-chapter6.markdown b/en/06-git-tools/01-chapter6.markdown
index 18044f27e..39eb135f3 100644
--- a/en/06-git-tools/01-chapter6.markdown
+++ b/en/06-git-tools/01-chapter6.markdown
@@ -501,7 +501,7 @@ Again, if you don’t specify a stash, Git assumes the most recent stash:
 You may want to create an alias and effectively add a `stash-unapply` command to your Git. For example:
 
     $ git config --global alias.stash-unapply '!git stash show -p | git apply -R'
-    $ git stash
+    $ git stash apply
     $ #... work work work
     $ git stash-unapply
 
diff --git a/fr/06-git-tools/01-chapter6.markdown b/fr/06-git-tools/01-chapter6.markdown
index 81009134a..7be8d77ba 100644
--- a/fr/06-git-tools/01-chapter6.markdown
+++ b/fr/06-git-tools/01-chapter6.markdown
@@ -577,7 +577,7 @@ La création d'un alias permettra d'ajouter effectivement la commande `stash-una
 Par exemple :
 
     $ git config --global alias.stash-unapply '!git stash show -p | git apply -R'
-    $ git stash
+    $ git stash apply
     $ #... work work work
     $ git stash-unapply
 
diff --git a/it/06-git-tools/01-chapter6.markdown b/it/06-git-tools/01-chapter6.markdown
index e358907eb..1fc8f9db6 100644
--- a/it/06-git-tools/01-chapter6.markdown
+++ b/it/06-git-tools/01-chapter6.markdown
@@ -501,7 +501,7 @@ Di nuovo, se non specifichi un accantonamento, Git assume che sia l'ultimo:
 Puoi voler creare un alias per avere un comando `stash-unapply` nel tuo Git. Per esempio:
 
     $ git config --global alias.stash-unapply '!git stash show -p | git apply -R'
-    $ git stash
+    $ git stash apply
     $ #... work work work
     $ git stash-unapply
 
diff --git a/ja/06-git-tools/01-chapter6.markdown b/ja/06-git-tools/01-chapter6.markdown
index 40379d5ee..85bb6a482 100644
--- a/ja/06-git-tools/01-chapter6.markdown
+++ b/ja/06-git-tools/01-chapter6.markdown
@@ -496,7 +496,7 @@ apply オプションは、スタックに隠した作業を再度適用する
 次の例のようにエイリアスを作れば、Git に `stash-unapply` コマンドを追加したのと事実上同じことになります。
 
     $ git config --global alias.stash-unapply '!git stash show -p | git apply -R'
-    $ git stash
+    $ git stash apply
     $ #... 何か作業をして ...
     $ git stash-unapply
 
diff --git a/ko/06-git-tools/01-chapter6.markdown b/ko/06-git-tools/01-chapter6.markdown
index ae30bf7f2..d6ad75bad 100644
--- a/ko/06-git-tools/01-chapter6.markdown
+++ b/ko/06-git-tools/01-chapter6.markdown
@@ -497,7 +497,7 @@ Stash를 명시하지 않으면 Git은 가장 최근의 Stash를 사용한다:
 `stash-unapply`라는 alias를 만들고 편리하게 할 수도 있다:
 
 	$ git config --global alias.stash-unapply '!git stash show -p | git apply -R'
-	$ git stash
+	$ git stash apply
 	$ #... work work work
 	$ git stash-unapply
 
diff --git a/nl/06-git-tools/01-chapter6.markdown b/nl/06-git-tools/01-chapter6.markdown
index d4cc79d8f..6049137da 100644
--- a/nl/06-git-tools/01-chapter6.markdown
+++ b/nl/06-git-tools/01-chapter6.markdown
@@ -538,7 +538,7 @@ Nogmaals: als je geen stash specificeert gaat Git van de meest recente stash uit
 Wellicht wil je een alias maken en effectief een `stash-unapply` commando aan je Git toevoegen. Bijvoorbeeld:
 
     $ git config --global alias.stash-unapply '!git stash show -p | git apply -R'
-    $ git stash
+    $ git stash apply
     $ #... work work work
     $ git stash-unapply
 
diff --git a/no-nb/06-git-tools/01-chapter6.markdown b/no-nb/06-git-tools/01-chapter6.markdown
index eaa9b42a0..f7254cf30 100644
--- a/no-nb/06-git-tools/01-chapter6.markdown
+++ b/no-nb/06-git-tools/01-chapter6.markdown
@@ -501,7 +501,7 @@ Again, if you don’t specify a stash, Git assumes the most recent stash:
 You may want to create an alias and effectively add a `stash-unapply` command to your Git. For example:
 
     $ git config --global alias.stash-unapply '!git stash show -p | git apply -R'
-    $ git stash
+    $ git stash apply
     $ #... work work work
     $ git stash-unapply
 
diff --git a/pl/06-git-tools/01-chapter6.markdown b/pl/06-git-tools/01-chapter6.markdown
index 2bb6cb043..a00cf9ea0 100644
--- a/pl/06-git-tools/01-chapter6.markdown
+++ b/pl/06-git-tools/01-chapter6.markdown
@@ -683,7 +683,7 @@ Możesz chcieć stworzyć alias i dodać komendę `stash-unapply` do Gita. Na pr
 <!-- You may want to create an alias and effectively add a `stash-unapply` command to your git. For example: -->
 
     $ git config --global alias.stash-unapply '!git stash show -p | git apply -R'
-    $ git stash
+    $ git stash apply
     $ #... work work work
     $ git stash-unapply
 
diff --git a/pt-br/06-git-tools/01-chapter6.markdown b/pt-br/06-git-tools/01-chapter6.markdown
index 8b4da423a..1b4cefba7 100644
--- a/pt-br/06-git-tools/01-chapter6.markdown
+++ b/pt-br/06-git-tools/01-chapter6.markdown
@@ -497,7 +497,7 @@ Novamente, se você não especificar um stash, Git assume que é o stash mais re
 Você pode querer criar um alias e adicionar explicitamente um comando `stash-unapply` no seu git. Por exemplo:
 
     $ git config --global alias.stash-unapply '!git stash show -p | git apply -R'
-    $ git stash
+    $ git stash apply
     $ #... work work work
     $ git stash-unapply
 
diff --git a/ru/06-git-tools/01-chapter6.markdown b/ru/06-git-tools/01-chapter6.markdown
index 470168f78..05b60d68a 100644
--- a/ru/06-git-tools/01-chapter6.markdown
+++ b/ru/06-git-tools/01-chapter6.markdown
@@ -501,7 +501,7 @@ Insert 18333fig0601.png
 Если хотите, сделайте псевдоним и добавьте в свой Git команду `stash-unapply`. Например, так:
 
     $ git config --global alias.stash-unapply '!git stash show -p | git apply -R'
-    $ git stash
+    $ git stash apply
     $ #... work work work
     $ git stash-unapply
 
diff --git a/zh-tw/06-git-tools/01-chapter6.markdown b/zh-tw/06-git-tools/01-chapter6.markdown
index 9315aedd9..73c4ba300 100644
--- a/zh-tw/06-git-tools/01-chapter6.markdown
+++ b/zh-tw/06-git-tools/01-chapter6.markdown
@@ -500,7 +500,7 @@ apply 選項只嘗試應用儲藏的工作——儲藏的內容仍然在堆疊
 你可能會想要新建一個別名，在你的 git 增加一個 `stash-unapply` 命令，這樣更有效率。例如：
 
     $ git config --global alias.stash-unapply '!git stash show -p | git apply -R'
-    $ git stash
+    $ git stash apply
     $ #... work work work
     $ git stash-unapply
 
diff --git a/zh/06-git-tools/01-chapter6.markdown b/zh/06-git-tools/01-chapter6.markdown
index b0929d272..26bb33096 100644
--- a/zh/06-git-tools/01-chapter6.markdown
+++ b/zh/06-git-tools/01-chapter6.markdown
@@ -500,7 +500,7 @@ apply 选项只尝试应用储藏的工作——储藏的内容仍然在栈上
 你可能会想要新建一个別名，在你的 Git 里增加一个 `stash-unapply` 命令，这样更有效率。例如：
 
     $ git config --global alias.stash-unapply '!git stash show -p | git apply -R'
-    $ git stash
+    $ git stash apply
     $ #... work work work
     $ git stash-unapply
 

From 64c9194e3640c5f73f11ffebe07f56de8e1f2d28 Mon Sep 17 00:00:00 2001
From: Scott Chacon <dragon@github.com>
Date: Tue, 28 Oct 2014 09:37:41 +0100
Subject: [PATCH 665/690] Rename README.md to README.original.md

---
 README.md => README.original.md | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 rename README.md => README.original.md (100%)

diff --git a/README.md b/README.original.md
similarity index 100%
rename from README.md
rename to README.original.md

From 8e850958178917a3550aaf4a58c7177b3483ce38 Mon Sep 17 00:00:00 2001
From: Scott Chacon <dragon@github.com>
Date: Tue, 28 Oct 2014 09:40:48 +0100
Subject: [PATCH 666/690] Create new README

---
 README.md | 9 +++++++++
 1 file changed, 9 insertions(+)
 create mode 100644 README.md

diff --git a/README.md b/README.md
new file mode 100644
index 000000000..39d3f6dfa
--- /dev/null
+++ b/README.md
@@ -0,0 +1,9 @@
+# Pro Git, 1st Edition
+
+This is the source for the 1st edition of the Pro Git book. The second edition has since been released and is what will be maintained and published going forward. Please suggest any changes to that version instead. 
+
+You can find the new edition at:
+
+https://github.com/progit/progit2
+
+If you're looking for the original README content, it can be found in the [README.original.md](README.original.md) file.

From 160b086cb3dc241f1be66fb73020b2d5ae6cc743 Mon Sep 17 00:00:00 2001
From: Tom Schady <tschady@gmail.com>
Date: Tue, 16 Dec 2014 11:09:03 -0600
Subject: [PATCH 667/690] correct the branch name to distinguish from subdir

---
 az/06-git-tools/01-chapter6.markdown    | 2 +-
 cs/06-git-tools/01-chapter6.markdown    | 2 +-
 de/06-git-tools/01-chapter6.markdown    | 2 +-
 en/06-git-tools/01-chapter6.markdown    | 2 +-
 fr/06-git-tools/01-chapter6.markdown    | 2 +-
 it/06-git-tools/01-chapter6.markdown    | 2 +-
 ja/06-git-tools/01-chapter6.markdown    | 2 +-
 nl/06-git-tools/01-chapter6.markdown    | 2 +-
 no-nb/06-git-tools/01-chapter6.markdown | 2 +-
 pl/06-git-tools/01-chapter6.markdown    | 2 +-
 pt-br/06-git-tools/01-chapter6.markdown | 2 +-
 ru/06-git-tools/01-chapter6.markdown    | 2 +-
 zh-tw/06-git-tools/01-chapter6.markdown | 2 +-
 13 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/az/06-git-tools/01-chapter6.markdown b/az/06-git-tools/01-chapter6.markdown
index 2b18d87e0..ccf9797c0 100644
--- a/az/06-git-tools/01-chapter6.markdown
+++ b/az/06-git-tools/01-chapter6.markdown
@@ -1095,7 +1095,7 @@ Now you have the root of the Rack project in your `rack_branch` branch and your
 	$ ls
 	README
 
-You want to pull the Rack project into your `master` project as a subdirectory. You can do that in Git with `git read-tree`. You’ll learn more about `read-tree` and its friends in Chapter 9, but for now know that it reads the root tree of one branch into your current staging area and working directory. You just switched back to your `master` branch, and you pull the `rack` branch into the `rack` subdirectory of your `master` branch of your main project:
+You want to pull the Rack project into your `master` project as a subdirectory. You can do that in Git with `git read-tree`. You’ll learn more about `read-tree` and its friends in Chapter 9, but for now know that it reads the root tree of one branch into your current staging area and working directory. You just switched back to your `master` branch, and you pull the `rack_branch` branch into the `rack` subdirectory of your `master` branch of your main project:
 
 	$ git read-tree --prefix=rack/ -u rack_branch
 
diff --git a/cs/06-git-tools/01-chapter6.markdown b/cs/06-git-tools/01-chapter6.markdown
index 516af28d3..24e5a12d3 100644
--- a/cs/06-git-tools/01-chapter6.markdown
+++ b/cs/06-git-tools/01-chapter6.markdown
@@ -1136,7 +1136,7 @@ Nyní máte kořenový adresář s projektem Rack ve větvi `rack_branch` a vlas
 	$ ls
 	README
 
-Projekt Rack chcete do projektu `master` natáhnout jako podadresář. V systému Git k tomu slouží příkaz `git read-tree`. O příkazu `read-tree` a jeho příbuzných se více dočtete v kapitole 9, nyní však vězte, že načte kořenový strom jedné větve do vaší aktuální oblasti připravených změn a do pracovního adresáře. Přepnuli jste zpět na větev `master` a větev `rack` natáhnete do podadresáře `rack` své větve `master` hlavního projektu:
+Projekt Rack chcete do projektu `master` natáhnout jako podadresář. V systému Git k tomu slouží příkaz `git read-tree`. O příkazu `read-tree` a jeho příbuzných se více dočtete v kapitole 9, nyní však vězte, že načte kořenový strom jedné větve do vaší aktuální oblasti připravených změn a do pracovního adresáře. Přepnuli jste zpět na větev `master` a větev `rack_branch` natáhnete do podadresáře `rack` své větve `master` hlavního projektu:
 
 	$ git read-tree --prefix=rack/ -u rack_branch
 
diff --git a/de/06-git-tools/01-chapter6.markdown b/de/06-git-tools/01-chapter6.markdown
index 69f395bde..e0af3d441 100644
--- a/de/06-git-tools/01-chapter6.markdown
+++ b/de/06-git-tools/01-chapter6.markdown
@@ -1458,7 +1458,7 @@ Nach der Ausführung der drei Befehle befindet sich das Rack-Projekt in Deinem B
 
 <!--You want to pull the Rack project into your `master` project as a subdirectory. You can do that in Git with `git read-tree`. You’ll learn more about `read-tree` and its friends in Chapter 9, but for now know that it reads the root tree of one branch into your current staging area and working directory. You just switched back to your `master` branch, and you pull the `rack` branch into the `rack` subdirectory of your `master` branch of your main project:-->
 
-Jetzt möchten wir das Rack-Projekt in Deinen Branch `master` als Unterverzeichnis hinzufügen. Dies kann man in Git mit dem Befehl `git read-tree` durchführen. In Kapitel 9 werde ich den Befehl `read-tree` und dessen verwandte Befehle näher erläutern. Hier möchte ich nur erklären, dass der Befehl das Wurzelverzeichnis eines Branches in die aktuelle Staging-Area und in das Arbeitsverzeichnis packt. Damit hast Du jetzt zu Deinem Branch `master` zurückgewechselt, den Inhalt des Branches `rack` in das Unterverzeichnis `rack` im Branch `master` Deines Projekts hinterlegt:
+Jetzt möchten wir das Rack-Projekt in Deinen Branch `master` als Unterverzeichnis hinzufügen. Dies kann man in Git mit dem Befehl `git read-tree` durchführen. In Kapitel 9 werde ich den Befehl `read-tree` und dessen verwandte Befehle näher erläutern. Hier möchte ich nur erklären, dass der Befehl das Wurzelverzeichnis eines Branches in die aktuelle Staging-Area und in das Arbeitsverzeichnis packt. Damit hast Du jetzt zu Deinem Branch `master` zurückgewechselt, den Inhalt des Branches `rack_branch` in das Unterverzeichnis `rack` im Branch `master` Deines Projekts hinterlegt:
 
 	$ git read-tree --prefix=rack/ -u rack_branch
 
diff --git a/en/06-git-tools/01-chapter6.markdown b/en/06-git-tools/01-chapter6.markdown
index 39eb135f3..286ee7237 100644
--- a/en/06-git-tools/01-chapter6.markdown
+++ b/en/06-git-tools/01-chapter6.markdown
@@ -1119,7 +1119,7 @@ Now you have the root of the Rack project in your `rack_branch` branch and your
 	$ ls
 	README
 
-You want to pull the Rack project into your `master` project as a subdirectory. You can do that in Git with `git read-tree`. You’ll learn more about `read-tree` and its friends in Chapter 9, but for now know that it reads the root tree of one branch into your current staging area and working directory. You just switched back to your `master` branch, and you pull the `rack` branch into the `rack` subdirectory of your `master` branch of your main project:
+You want to pull the Rack project into your `master` project as a subdirectory. You can do that in Git with `git read-tree`. You’ll learn more about `read-tree` and its friends in Chapter 9, but for now know that it reads the root tree of one branch into your current staging area and working directory. You just switched back to your `master` branch, and you pull the `rack_branch` branch into the `rack` subdirectory of your `master` branch of your main project:
 
 	$ git read-tree --prefix=rack/ -u rack_branch
 
diff --git a/fr/06-git-tools/01-chapter6.markdown b/fr/06-git-tools/01-chapter6.markdown
index 7be8d77ba..07adf11d4 100644
--- a/fr/06-git-tools/01-chapter6.markdown
+++ b/fr/06-git-tools/01-chapter6.markdown
@@ -1316,7 +1316,7 @@ Si vous récupérez l'une puis l'autre branche, vous pouvez voir que vous avez d
 
 Pour tirer le projet Rack dans votre projet `master` comme un sous-répertoire, vous pouvez utiliser la commande `git read-tree`.
 Vous apprendrez davantage sur `read-tree` et compagnie dans le chapitre 9, mais pour le moment, sachez qu'il lit la racine d'une de vos branches et l'inscrit dans votre index et votre répertoire de travail.
-Vous venez juste de commuter vers votre branche `master` et vous tirez la branche `rack` vers le sous-répertoire `rack` de votre branche `master` de votre projet principal :
+Vous venez juste de commuter vers votre branche `master` et vous tirez la branche `rack_branch` vers le sous-répertoire `rack` de votre branche `master` de votre projet principal :
 
 	$ git read-tree --prefix=rack/ -u rack_branch
 
diff --git a/it/06-git-tools/01-chapter6.markdown b/it/06-git-tools/01-chapter6.markdown
index 1fc8f9db6..50559d39e 100644
--- a/it/06-git-tools/01-chapter6.markdown
+++ b/it/06-git-tools/01-chapter6.markdown
@@ -1120,7 +1120,7 @@ Ora hai la root del progetto Rack nel tuo branch `rack_branch` e il tuo progetto
 	$ ls
 	README
 
-Ora vuoi inviare il progetto Rack nel tuo progetto `master` come una sottodirectory e in Git puoi farlo con `git read-tree`. Conoscerai meglio `read-tree` e i suoi amici nel Capitolo 9, ma per ora sappi che legge la radice di un branch nella tua area di staging della tua directory di lavoro. Sei appena ritornato nel tuo branch `master` e hai scaricato il branch `rack` nella directory `rack` del branch `master` del tuo progetto principale:
+Ora vuoi inviare il progetto Rack nel tuo progetto `master` come una sottodirectory e in Git puoi farlo con `git read-tree`. Conoscerai meglio `read-tree` e i suoi amici nel Capitolo 9, ma per ora sappi che legge la radice di un branch nella tua area di staging della tua directory di lavoro. Sei appena ritornato nel tuo branch `master` e hai scaricato il branch `rack_branch` nella directory `rack` del branch `master` del tuo progetto principale:
 
 	$ git read-tree --prefix=rack/ -u rack_branch
 
diff --git a/ja/06-git-tools/01-chapter6.markdown b/ja/06-git-tools/01-chapter6.markdown
index 85bb6a482..ddf152a2f 100644
--- a/ja/06-git-tools/01-chapter6.markdown
+++ b/ja/06-git-tools/01-chapter6.markdown
@@ -1102,7 +1102,7 @@ Git でこれと同じことをするためのよい方法は、それぞれの
 	$ ls
 	README
 
-Rack プロジェクトを `master` プロジェクトのサブディレクトリとして取り込みたくなったときには、`git read-tree` を使います。`read-tree` とその仲間たちについては第 9 章で詳しく説明します。現時点では、とりあえず「あるブランチのルートツリーを読み込んで、それを現在のステージングエリアと作業ディレクトリに書き込むもの」だと認識しておけばよいでしょう。まず `master` ブランチに戻り、`rack` ブランチの内容を `master` ブランチの `rack` サブディレクトリに取り込みます。
+Rack プロジェクトを `master` プロジェクトのサブディレクトリとして取り込みたくなったときには、`git read-tree` を使います。`read-tree` とその仲間たちについては第 9 章で詳しく説明します。現時点では、とりあえず「あるブランチのルートツリーを読み込んで、それを現在のステージングエリアと作業ディレクトリに書き込むもの」だと認識しておけばよいでしょう。まず `master` ブランチに戻り、`rack_branch` ブランチの内容を `master` ブランチの `rack` サブディレクトリに取り込みます。
 
 	$ git read-tree --prefix=rack/ -u rack_branch
 
diff --git a/nl/06-git-tools/01-chapter6.markdown b/nl/06-git-tools/01-chapter6.markdown
index 6049137da..4309c372c 100644
--- a/nl/06-git-tools/01-chapter6.markdown
+++ b/nl/06-git-tools/01-chapter6.markdown
@@ -1146,7 +1146,7 @@ Nu heb je de root van het Rack project in je `rack_branch` branch en je eigen pr
 	$ ls
 	README
 
-Je gaat nu het Rack project in je `master` project pullen als een subdirectory. Je kunt dat in Git doen met `git read-tree`. Je zult meer over `read-tree` en zijn vriendjes leren in Hoofdstuk 9, maar weet voor nu dat het de roottree van een branch in je huidige staging area en werkdirectory leest. Je hebt zojuist teruggewisseld naar je `master` branch, en je pulled de `rack` branch in de `rack` subdirectory van de `master` branch van je hoofdproject:
+Je gaat nu het Rack project in je `master` project pullen als een subdirectory. Je kunt dat in Git doen met `git read-tree`. Je zult meer over `read-tree` en zijn vriendjes leren in Hoofdstuk 9, maar weet voor nu dat het de roottree van een branch in je huidige staging area en werkdirectory leest. Je hebt zojuist teruggewisseld naar je `master` branch, en je pulled de `rack_branch` branch in de `rack` subdirectory van de `master` branch van je hoofdproject:
 
 	$ git read-tree --prefix=rack/ -u rack_branch
 
diff --git a/no-nb/06-git-tools/01-chapter6.markdown b/no-nb/06-git-tools/01-chapter6.markdown
index f7254cf30..453854fb3 100644
--- a/no-nb/06-git-tools/01-chapter6.markdown
+++ b/no-nb/06-git-tools/01-chapter6.markdown
@@ -1113,7 +1113,7 @@ Now you have the root of the Rack project in your `rack_branch` branch and your
 	$ ls
 	README
 
-You want to pull the Rack project into your `master` project as a subdirectory. You can do that in Git with `git read-tree`. You’ll learn more about `read-tree` and its friends in Chapter 9, but for now know that it reads the root tree of one branch into your current staging area and working directory. You just switched back to your `master` branch, and you pull the `rack` branch into the `rack` subdirectory of your `master` branch of your main project:
+You want to pull the Rack project into your `master` project as a subdirectory. You can do that in Git with `git read-tree`. You’ll learn more about `read-tree` and its friends in Chapter 9, but for now know that it reads the root tree of one branch into your current staging area and working directory. You just switched back to your `master` branch, and you pull the `rack_branch` branch into the `rack` subdirectory of your `master` branch of your main project:
 
 	$ git read-tree --prefix=rack/ -u rack_branch
 
diff --git a/pl/06-git-tools/01-chapter6.markdown b/pl/06-git-tools/01-chapter6.markdown
index a00cf9ea0..9e4d7353a 100644
--- a/pl/06-git-tools/01-chapter6.markdown
+++ b/pl/06-git-tools/01-chapter6.markdown
@@ -1502,7 +1502,7 @@ Masz teraz zawartość projektu Rack w gałęzi `rack_branch`, a swój projekt w
 	$ ls
 	README
 
-Chcesz jednak, pobrać projekt Rack do swojej gałęzi `master` jako podkatalog. Możesz to zrobić, za pomocą komendy Gita `git read-tree`. Dowiesz się więcej na temat komendy `read-tree` i jej podobnych w rozdziale 9, ale na teraz wiedz, że odczytuje ona drzewo projektu w jednej gałęzi i włącza je do obecnego katalogu i przechowalni. Ponownie zmieniasz gałąź na `master` i pobierasz gałąź `rack` do podkatalogu `rack` w gałęzi `master` w projekcie:
+Chcesz jednak, pobrać projekt Rack do swojej gałęzi `master` jako podkatalog. Możesz to zrobić, za pomocą komendy Gita `git read-tree`. Dowiesz się więcej na temat komendy `read-tree` i jej podobnych w rozdziale 9, ale na teraz wiedz, że odczytuje ona drzewo projektu w jednej gałęzi i włącza je do obecnego katalogu i przechowalni. Ponownie zmieniasz gałąź na `master` i pobierasz gałąź `rack_branch` do podkatalogu `rack` w gałęzi `master` w projekcie:
 
 <!-- You want to pull the Rack project into your `master` project as a subdirectory. You can do that in Git with `git read-tree`. You’ll learn more about `read-tree` and its friends in Chapter 9, but for now know that it reads the root tree of one branch into your current staging area and working directory. You just switched back to your `master` branch, and you pull the `rack` branch into the `rack` subdirectory of your `master` branch of your main project: -->
 
diff --git a/pt-br/06-git-tools/01-chapter6.markdown b/pt-br/06-git-tools/01-chapter6.markdown
index 1b4cefba7..2f5916f52 100644
--- a/pt-br/06-git-tools/01-chapter6.markdown
+++ b/pt-br/06-git-tools/01-chapter6.markdown
@@ -1091,7 +1091,7 @@ Agora você tem a raiz do projeto Rack no seu branch `rack_branch` e o seu proje
     $ ls
     README
 
-Você quer colocar o projeto Rack no seu projeto `master` como um subdiretório. Você pode fazer isso no Git com `git read-tree`. Você irá aprender mais sobre `read-tree` e seus companheiros no Capítulo 9, mas por enquanto saiba que ele escreve a raiz da árvore de um branch na sua área de seleção e diretório de trabalho. Você volta para o branch `master`, você coloca o branch `rack` no subdiretório `rack` no branch `master` do seu projeto principal:
+Você quer colocar o projeto Rack no seu projeto `master` como um subdiretório. Você pode fazer isso no Git com `git read-tree`. Você irá aprender mais sobre `read-tree` e seus companheiros no Capítulo 9, mas por enquanto saiba que ele escreve a raiz da árvore de um branch na sua área de seleção e diretório de trabalho. Você volta para o branch `master`, você coloca o branch `rack_branch` no subdiretório `rack` no branch `master` do seu projeto principal:
 
     $ git read-tree --prefix=rack/ -u rack_branch
 
diff --git a/ru/06-git-tools/01-chapter6.markdown b/ru/06-git-tools/01-chapter6.markdown
index 05b60d68a..e6801beb6 100644
--- a/ru/06-git-tools/01-chapter6.markdown
+++ b/ru/06-git-tools/01-chapter6.markdown
@@ -1095,7 +1095,7 @@ Git решает эту задачу, используя подмодули (sub
 	$ ls
 	README
 
-Допустим, вы хотите поместить проект Rack в подкаталог своего проекта в ветке `master`. Вы можете сделать это в Git'е командой `git read-tree`. Вы узнаете больше про команду `read-tree` и её друзей в главе 9, а пока достаточно знать, что она считывает корень дерева одной ветки в индекс и рабочий каталог. Вам достаточно переключиться обратно на ветку `master` и вытянуть ветку `rack` в подкаталог `rack` основного проекта из ветки `master`:
+Допустим, вы хотите поместить проект Rack в подкаталог своего проекта в ветке `master`. Вы можете сделать это в Git'е командой `git read-tree`. Вы узнаете больше про команду `read-tree` и её друзей в главе 9, а пока достаточно знать, что она считывает корень дерева одной ветки в индекс и рабочий каталог. Вам достаточно переключиться обратно на ветку `master` и вытянуть ветку `rack_branch` в подкаталог `rack` основного проекта из ветки `master`:
 
 	$ git read-tree --prefix=rack/ -u rack_branch
 
diff --git a/zh-tw/06-git-tools/01-chapter6.markdown b/zh-tw/06-git-tools/01-chapter6.markdown
index 73c4ba300..d45286922 100644
--- a/zh-tw/06-git-tools/01-chapter6.markdown
+++ b/zh-tw/06-git-tools/01-chapter6.markdown
@@ -1108,7 +1108,7 @@ Git 通過子模組處理這個問題。子模組允許你將一個 Git 倉庫
 	$ ls
 	README
 
-要將 Rack 專案當作子目錄拉取到你的 `master` 專案中。你可以在 Git 中用 `git read-tree` 來實現。你會在第9章學到更多與 `read-tree` 和它的朋友相關的東西，目前你會知道它讀取一個分支的根目錄樹到當前的暫存區和工作目錄。你只要切換回你的 `master` 分支，然後拉取 `rack` 分支到你主專案的 `master` 分支的 `rack` 子目錄： 
+要將 Rack 專案當作子目錄拉取到你的 `master` 專案中。你可以在 Git 中用 `git read-tree` 來實現。你會在第9章學到更多與 `read-tree` 和它的朋友相關的東西，目前你會知道它讀取一個分支的根目錄樹到當前的暫存區和工作目錄。你只要切換回你的 `master` 分支，然後拉取 `rack_branch` 分支到你主專案的 `master` 分支的 `rack` 子目錄： 
 
 	$ git read-tree --prefix=rack/ -u rack_branch
 

From 940b5cc898e3dd929eaffb559f91f23842d30384 Mon Sep 17 00:00:00 2001
From: berniedurfee-ge <bernie.durfee@ge.com>
Date: Thu, 18 Dec 2014 15:34:38 -0500
Subject: [PATCH 668/690] Update 01-chapter1.markdown

Added install of more required Yum packages: perl-devel, asciidoc and xmlto
---
 en/01-introduction/01-chapter1.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/en/01-introduction/01-chapter1.markdown b/en/01-introduction/01-chapter1.markdown
index 9cd2d5620..62f97d3b9 100644
--- a/en/01-introduction/01-chapter1.markdown
+++ b/en/01-introduction/01-chapter1.markdown
@@ -129,7 +129,7 @@ If you can, it’s generally useful to install Git from source, because you’ll
 To install Git, you need to have the following libraries that Git depends on: curl, zlib, openssl, expat, and libiconv. For example, if you’re on a system that has yum (such as Fedora) or apt-get (such as a Debian based system), you can use one of these commands to install all of the dependencies:
 
 	$ yum install curl-devel expat-devel gettext-devel \
-	  openssl-devel zlib-devel
+	  openssl-devel zlib-devel perl-devel asciidoc xmlto
 
 	$ apt-get install libcurl4-gnutls-dev libexpat1-dev gettext \
 	  libz-dev libssl-dev

From 476339756aa1b9c66ed240ac4f193c8052569d80 Mon Sep 17 00:00:00 2001
From: jooneyp <parkjydev@gmail.com>
Date: Wed, 24 Dec 2014 01:34:57 +0900
Subject: [PATCH 669/690] Update 01-chapter4.markdown
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

오타 / 의역 수정.
---
 ko/04-git-server/01-chapter4.markdown | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/ko/04-git-server/01-chapter4.markdown b/ko/04-git-server/01-chapter4.markdown
index b093a204d..30b3c455a 100644
--- a/ko/04-git-server/01-chapter4.markdown
+++ b/ko/04-git-server/01-chapter4.markdown
@@ -62,7 +62,7 @@ SSH를 통해 Git 저장소를 Clone하려면 `ssh://`로 시작하는 URL을 
 
 #### 장점 ####
 
-SSH는 장점이 매우 많은 프로토콜이다. 첫째, 누가 리모트에서 저장소에 접근하는지 알고 싶다면 SSH를 사용해야 한다. 둘째, SSH는 상대적으로 설정하기 쉽다. SSH 데몬은 정말 흔하다. 네트워크 관리자은 SSH 데몬을 다루어본 경험이 있고 대부분의 OS 배포판에는 SSH 데몬과 관리도구가 모두 들어 있다. 셋째, SSH를 통해 접근하면 보안에 안전하다. 모든 데이터는 암호화되어 인증된 상태로 전송된다. 마지막으로 SSH는 전송 시 데이터를 가능한 압축하기 때문에 효율적이다.
+SSH는 장점이 매우 많은 프로토콜이다. 첫째, 누가 리모트에서 저장소에 접근하는지 알고 싶다면 SSH를 사용해야 한다. 둘째, SSH는 상대적으로 설정하기 쉽다. SSH 데몬은 정말 흔하다. 거의 모든 네트워크 관리자는 SSH 데몬을 다루어본 경험을 가지고 있을것이고, 대부분의 OS 배포판에는 SSH 데몬과 관리도구가 들어 있다. 셋째, SSH를 통해 접근하면 보안에 안전하다. 모든 데이터는 암호화되어 인증된 상태로 전송된다. 마지막으로 SSH는 전송 시 데이터를 가능한 압축하기 때문에 효율적이다.
 
 #### 단점 ####
 
@@ -70,7 +70,7 @@ SSH의 단점은 익명으로 접근할 수 없다는 것이다. 심지어 읽
 
 ### Git 프로토콜 ###
 
-Git 프로토콜은 Git에 포함된 데몬을 사용하는 방법이다. 포트는 9418이며 SSH 프로토콜과 비슷한 서비스를 제공하지만, 인증 메커니즘이 없다. 저장소에 git-export-daemon-ok 파일을 만들면 Git 프로토콜로 서비스할 수 있지만, 보안은 없다. 이 파일이 없는 저장소는 Git 프로토콜로 서비스할 수 없다. 이 저장소는 누구나 Clone할 수 있거나 아무도 Clone할 수 없거나 둘 중의 하나만 선택할 수 있다. 그래서 이 프로토콜로는 Push 가능하게 설정할 수 없다. 엄밀히 말해서 Push할 수 있도록 설정할 수 있지만, 인증하도록 할 수 없다. 그러니까 당신이 Push할 수 있으면 이 프로젝트의 URL을 아는 사람은 누구나 Push할 수 있다. 그냥 이런 것도 있지만 잘 안 쓴다고 알고 있으면 된다.
+Git 프로토콜은 Git에 포함된 데몬을 사용하는 방법이다. 포트는 9418이며 SSH 프로토콜과 비슷한 서비스를 제공하지만, 인증 메커니즘이 없다. 저장소에 git-export-daemon-ok 파일을 만들면 Git 프로토콜로 서비스할 수 있지만, 보안은 없다. 이 파일이 없는 저장소는 Git 프로토콜로 서비스할 수 없다. 이 저장소는 누구나 Clone할 수 있거나 아무도 Clone할 수 없거나 둘 중의 하나만 선택할 수 있다. 그래서 이 프로토콜로는 Push를 가능하게 설정할 수 없다. 엄밀히 말해서 Push할 수 있도록 설정할 수 있지만, 인증하도록 할 수 없다. 그러니까 당신이 Push할 수 있으면 이 프로젝트의 URL을 아는 사람은 누구나 Push할 수 있다. 그냥 이런 것도 있지만 잘 안 쓴다고 알고 있으면 된다.
 
 #### 장점 ####
 
@@ -96,7 +96,7 @@ post-update 훅은 Git에 포함되어 있으며 `git update-server-info`라는
 
 여기서는 Apache 서버가 기본으로 사용하는 `/var/www/htdocs`을 루트 디렉토리로 사용하지만 다른 웹 서버를 사용해도 된다. 단순히 Bare 저장소를 HTTP 문서 루트에 넣으면 된다. Git 데이터는 일반적인 정적 파일처럼 취급된다(*9장*에서 정확히 어떻게 처리하는지 다룰 것이다).
 
-HTTP를 통해서 Push하는 것도 가능하다. 단지 이 방법은 잘 사용하지 않는 WebDAV 환경을 완벽하게 구축해야 한다. 잘 사용하지 않기 때문에 이 책에서도 다루지 않는다. HTTP 프로토콜로 Push하고 싶으면 `http://www.kernel.org/pub/software/scm/git/docs/howto/setup-git-server-over-http.txt` 읽고 저장소를 만들면 된다. HTTP를 통해서 Push하는 방법의 좋은 점은 WebDAV 서버를 아무거나 골라 쓸 수 있다는 것이다. 그래서 WebDAV를 지원하는 웹 호스팅 업체를 이용하면 이 기능을 사용할 수 있다.
+HTTP를 통해서 Push하는 것도 가능하다. 단지 이 방법은 잘 사용하지 않는 WebDAV 환경을 완벽하게 구축해야 한다. 잘 사용하지 않기 때문에 이 책에서도 다루지 않는다. HTTP 프로토콜로 Push하고 싶으면 `http://www.kernel.org/pub/software/scm/git/docs/howto/setup-git-server-over-http.txt` 을 읽고 저장소를 만들면 된다. HTTP를 통해서 Push하는 방법의 좋은 점은 WebDAV 서버를 아무거나 골라 쓸 수 있다는 것이다. 그래서 WebDAV를 지원하는 웹 호스팅 업체를 이용하면 이 기능을 사용할 수 있다.
 
 #### 장점 ####
 

From a45874e65dc5aa34159ad9e5450781d882d7a96f Mon Sep 17 00:00:00 2001
From: Jeffrey Slort <mail@jeffreyslort.nl>
Date: Thu, 15 Jan 2015 23:11:13 +0100
Subject: [PATCH 670/690] lid woorden en aanwijzende voornaam woorden in gehele
 boek consistent gemaakt mbt het woord tool

---
 nl/02-git-basics/01-chapter2.markdown         |  4 ++--
 nl/06-git-tools/01-chapter6.markdown          |  4 ++--
 nl/07-customizing-git/01-chapter7.markdown    |  8 ++++----
 nl/08-git-and-other-scms/01-chapter8.markdown | 10 +++++-----
 nl/09-git-internals/01-chapter9.markdown      |  4 ++--
 5 files changed, 15 insertions(+), 15 deletions(-)

diff --git a/nl/02-git-basics/01-chapter2.markdown b/nl/02-git-basics/01-chapter2.markdown
index 571dc9150..4267aba69 100644
--- a/nl/02-git-basics/01-chapter2.markdown
+++ b/nl/02-git-basics/01-chapter2.markdown
@@ -459,9 +459,9 @@ Git komt er impliciet achter dat het om een hernoemd bestand gaat, dus het maakt
 
 ## De commit geschiedenis bekijken ##
 
-Nadat je een aantal commits gemaakt hebt, of als je een repository met een bestaande commit-geschiedenis gecloned hebt, zul je waarschijnlijk terug willen zien wat er gebeurd is. Het meest basale en krachtige tool om dit te doen is het `git log` commando.
+Nadat je een aantal commits gemaakt hebt, of als je een repository met een bestaande commit-geschiedenis gecloned hebt, zul je waarschijnlijk terug willen zien wat er gebeurd is. De meest basale en krachtige tool om dit te doen is het `git log` commando.
 
-Deze voorbeelden maken gebruik van een eenvoudig project genaamd simplegit dat ik vaak voor demonstraties gebruikt. Om het project op te halen, voer dit uit
+Deze voorbeelden maken gebruik van een eenvoudig project genaamd simplegit dat ik vaak voor demonstraties gebruik. Om het project op te halen, voer dit uit
 
 	git clone git://github.com/schacon/simplegit-progit.git
 
diff --git a/nl/06-git-tools/01-chapter6.markdown b/nl/06-git-tools/01-chapter6.markdown
index 4309c372c..ea741e603 100644
--- a/nl/06-git-tools/01-chapter6.markdown
+++ b/nl/06-git-tools/01-chapter6.markdown
@@ -585,7 +585,7 @@ Je moet wel oppassen met deze techniek, omdat het amenden de SHA-1 van de commit
 
 ### Meerdere commit berichten wijzigen ###
 
-Om een commit te wijzigen die verder terug in je geschiedenis zit, moet je meer complexe tools gebruiken. Git heeft geen geschiedenis-wijzig tool, maar je kunt het rebase tool gebruiken om een serie commits op de HEAD te rebasen waarop ze origineel gebaseerd, in plaats van ze naar een andere te verhuizen. Met het interactieve rebase tool kun je dan na iedere commit die je wilt wijzigen stoppen en het bericht wijzigen, bestanden toevoegen, of doen wat je ook maar wilt. Je kunt rebase interactief uitvoeren door de `-i` optie aan `git rebase` toe te voegen. Je moet aangeven hoe ver terug je commits wilt herschrijven door het commando te vertellen op welke commit het moet rebasen.
+Om een commit te wijzigen die verder terug in je geschiedenis zit, moet je meer complexe tools gebruiken. Git heeft geen geschiedenis-wijzig tool, maar je kunt de rebase tool gebruiken om een serie commits op de HEAD te rebasen waarop ze origineel gebaseerd, in plaats van ze naar een andere te verhuizen. Met de interactieve rebase tool kun je dan na iedere commit die je wilt wijzigen stoppen en het bericht wijzigen, bestanden toevoegen, of doen wat je ook maar wilt. Je kunt rebase interactief uitvoeren door de `-i` optie aan `git rebase` toe te voegen. Je moet aangeven hoe ver terug je commits wilt herschrijven door het commando te vertellen op welke commit het moet rebasen.
 
 Bijvoorbeeld, als je de laatste drie commit berichten wilt veranderen, of een van de commit berichten in die groep, dan geef je de ouder van de laatste commit die je wilt wijzigen mee als argument aan `git rebase -i`, wat `HEAD~2^` of `HEAD~3` is. Het kan makkelijker zijn om de `~3` te onthouden, omdat je de laatste drie commits probeert te wijzigen; maar houd in gedachten dat je eigenlijk vier commits terug aangeeft; de ouder van de laatste commit die je wilt veranderen:
 
@@ -671,7 +671,7 @@ Als je dan opslaat en de editor sluit, zal Git je branch terugzetten naar de oud
 
 ### Een commit samenpersen (squashing) ###
 
-Het is ook mogelijk een serie commits te pakken en ze in één enkele commit samen te persen (squash) met het interactieve rebase tool. Het script stopt behulpzame instructies in het rebase bericht:
+Het is ook mogelijk een serie commits te pakken en ze in één enkele commit samen te persen (squash) met de interactieve rebase tool. Het script stopt behulpzame instructies in het rebase bericht:
 
 	#
 	# Commands:
diff --git a/nl/07-customizing-git/01-chapter7.markdown b/nl/07-customizing-git/01-chapter7.markdown
index 53edfbce1..47f93a847 100644
--- a/nl/07-customizing-git/01-chapter7.markdown
+++ b/nl/07-customizing-git/01-chapter7.markdown
@@ -172,7 +172,7 @@ Zie de manpage van `git config` voor alle sub-instellingen die je kunt instellen
 
 ### Externe merge en diff tools ###
 
-Alhoewel Git een interne implementatie van diff heeft, deze heb je tot nu toe gebruikt, kan je in plaats daarvan een extern tool instellen. Je kunt ook een grafisch merge conflict-oplossings tool instellen, in plaats van handmatig de conflicten op te moeten lossen. Ik zal nu demonstreren hoe je het Perforce Visuele Merge Tool (P4Merge) in moet stellen, om je diff en merge oplossingen te doen, omdat het een fijn grafisch tool is en omdat het gratis is.
+Alhoewel Git een interne implementatie van diff heeft, deze heb je tot nu toe gebruikt, kan je in plaats daarvan een externe tool instellen. Je kunt ook een grafisch merge conflict-oplossings tool instellen, in plaats van handmatig de conflicten op te moeten lossen. Ik zal nu demonstreren hoe je het Perforce Visuele Merge Tool (P4Merge) in moet stellen, om je diff en merge oplossingen te doen, omdat het een fijne grafische tool is en omdat het gratis is.
 
 Als je dit wilt proberen, P4Merge werkt op alle grote platformen, dus je zou het moeten kunnen doen. Ik zal in de voorbeelden paden gebruiken die op Mac en Linux systemen werken; voor Windows moet je `/usr/local/bin` veranderen in een pad naar een uitvoerbaar bestand op jouw machine.
 
@@ -228,15 +228,15 @@ in plaats van de uitvoer van diff op de commando regel, wordt een instantie van
 Insert 18333fig0701.png
 Figuur 7-1. P4Merge.
 
-Als je twee branches probeert te mergen en je krijgt vervolgens merge conflicten, kan je het `git mergetool` commando uitvoeren. P4Merge wordt dan opgestart om je het conflict op te laten lossen met behulp van dat GUI tool.
+Als je twee branches probeert te mergen en je krijgt vervolgens merge conflicten, kan je het `git mergetool` commando uitvoeren. P4Merge wordt dan opgestart om je het conflict op te laten lossen met behulp van de GUI tool.
 
-Het aardige van deze wrapper opstelling is dat je de diff en merge tools eenvoudig aan kunt passen. Bijvoorbeeld, om je `extDiff` en `extMerge` tools in te stellen zodat ze bijvoorbeeld het KDiff3 tool uitvoeren, is het enige dat je moet doen het `extMerge` bestand aanpassen:
+Het aardige van deze wrapper opstelling is dat je de diff en merge tools eenvoudig aan kunt passen. Bijvoorbeeld, om je `extDiff` en `extMerge` tools in te stellen zodat ze bijvoorbeeld de KDiff3 tool uitvoeren, is het enige dat je moet doen het `extMerge` bestand aanpassen:
 
 	$ cat /usr/local/bin/extMerge
 	#!/bin/sh
 	/Applications/kdiff3.app/Contents/MacOS/kdiff3 $*
 
-Nu zal Git het KDiff3 tool gebruiken voor het tonen van diff en het oplossen van merge conflicten.
+Nu zal Git de KDiff3 tool gebruiken voor het tonen van diff en het oplossen van merge conflicten.
 
 Git is 'af fabriek' al ingesteld om een aantal andere mergeconflict-oplossings tools te gebruiken zonder dat je de cmd configuratie op hoeft te zetten. Je kunt je merge tool op kdiff3 instellen, opendiff, tkdiff, meld, xxdiff, emerge, vimdiff of gvimdiff. Als je niet geïnteresseerd bent in het gebruik van KDiff3 als diff, maar het liever alleen wilt gebruiken voor merge conflict oplossing, en het kdiff3 commando zit in je pad, dan kun je dit uitvoeren
 
diff --git a/nl/08-git-and-other-scms/01-chapter8.markdown b/nl/08-git-and-other-scms/01-chapter8.markdown
index 8a17493e8..c21fd812c 100644
--- a/nl/08-git-and-other-scms/01-chapter8.markdown
+++ b/nl/08-git-and-other-scms/01-chapter8.markdown
@@ -36,7 +36,7 @@ Veel succes en plezier bij het vertalen...
 <!-- SHA-1 of last checked en-version: 4cefec -->
 # Git en andere systemen #
 
-Het is geen perfecte wereld. Meestal kan je niet meteen elk project waar je mee in aanraking komt omzetten naar Git. Soms zit je vast op een project dat een ander VCS gebruikt, en vaak is dat systeem Subversion. In het eerste gedeelte van dit hoofdstuk zal je leren over `git svn`, het bidirectionele Subversion uitwissel tool van Git.
+Het is geen perfecte wereld. Meestal kan je niet meteen elk project waar je mee in aanraking komt omzetten naar Git. Soms zit je vast op een project dat een ander VCS gebruikt, en vaak is dat systeem Subversion. In het eerste gedeelte van dit hoofdstuk zal je leren over `git svn`, de bidirectionele Subversion uitwissel tool van Git.
 
 Op een gegeven moment zal je een bestaande project willen omzetten naar Git. Het tweede gedeelte van dit hoofdstuk beschrijft hoe je projecten naar Git kunt migreren: eerst uit Subversion, dan vanuit Perforce, en als laatste via een eigen import script voor een niet standaard import geval.
 
@@ -44,7 +44,7 @@ Op een gegeven moment zal je een bestaande project willen omzetten naar Git. Het
 
 Op dit moment maakt het merendeel van open source ontwikkelprojecten en een groot aantal bedrijfsprojecten gebruik van Subversion om hun broncode te beheren. Het is het populairste open source VCS en bestaat al bijna tien jaar. Het lijkt ook in veel aspecten op CVS, wat daarvoor de grootste speler was in de code-beheer wereld.
 
-Een van de beste features van Git is een bidirectionele brug naar Subversion genaamd `git svn`. Dit tool staat je toe om Git als een volwaardige client van een Subversion server te gebruiken, zodat je alle lokale eigenschappen van Git kunt gebruiken en daarna naar een Subversion server kunt pushen alsof je Subversion lokaal gebruikt. Dit houdt in dat je lokaal kunt branchen en mergen, het staging gebied gebruiken, kunt rebasen en cherry-picken enzovoorts, terwijl je medewerkers verder werken met de spreekwoordelijke griffel en leisteen. Het is een goede manier om Git in de bedrijfsomgeving binnen te smokkelen en je mede-ontwikkelaars te helpen efficiënter te worden terwijl jij lobbiet om de infrastructuur dusdanig te veranderen dat Git volledig gesupport kan worden. De Subversion brug is het uitwisselings-medicijn naar de DCVS wereld.
+Een van de beste features van Git is een bidirectionele brug naar Subversion genaamd `git svn`. Deze tool staat je toe om Git als een volwaardige client van een Subversion server te gebruiken, zodat je alle lokale eigenschappen van Git kunt gebruiken en daarna naar een Subversion server kunt pushen alsof je Subversion lokaal gebruikt. Dit houdt in dat je lokaal kunt branchen en mergen, het staging gebied gebruiken, kunt rebasen en cherry-picken enzovoorts, terwijl je medewerkers verder werken met de spreekwoordelijke griffel en leisteen. Het is een goede manier om Git in de bedrijfsomgeving binnen te smokkelen en je mede-ontwikkelaars te helpen efficiënter te worden terwijl jij lobbiet om de infrastructuur dusdanig te veranderen dat Git volledig gesupport kan worden. De Subversion brug is het uitwisselings-medicijn naar de DCVS wereld.
 
 ### git svn ###
 
@@ -123,7 +123,7 @@ Nu zou je een geldig Git repository moeten hebben, waar de branches en tags in g
 	  tags/release-2.0.2rc1
 	  trunk
 
-Het is belangrijk om op te merken dat dit tool je remote references een andere namespace heeft toebedeeld. Als je normaal een Git repository cloned, krijg je alle branches op die remote server lokaal beschikbaar in de vorm van `origin/[branch]` - waarbij in de namespace de naam van de remote wordt gebruikt. Echter, `git svn` gaat er vanuit dat je niet meerdere remotes hebt en bewaart alle referentie naar punten op de remote server zonder gebruik te maken van namespaces. Je kunt het Git plumbing commando `show-ref` gebruiken om al je volledige referentie namen te zien:
+Het is belangrijk om op te merken dat deze tool je remote references een andere namespace heeft toebedeeld. Als je normaal een Git repository cloned, krijg je alle branches op die remote server lokaal beschikbaar in de vorm van `origin/[branch]` - waarbij in de namespace de naam van de remote wordt gebruikt. Echter, `git svn` gaat er vanuit dat je niet meerdere remotes hebt en bewaart alle referentie naar punten op de remote server zonder gebruik te maken van namespaces. Je kunt het Git plumbing commando `show-ref` gebruiken om al je volledige referentie namen te zien:
 
 	$ git show-ref
 	1cbd4904d9982f386d87f88fce1c24ad7c0f0471 refs/heads/master
@@ -458,7 +458,7 @@ Het volgende systeem waar je naar gaat kijken om vanuit te importeren is Perforc
 	$ git clone git://git.kernel.org/pub/scm/git/git.git
 	$ cd git/contrib/fast-import
 
-In deze `fast-import` directory, zou je een uitvoerbaar Python script genaamd `git-p4` moeten vinden. Je moet Python en het `p4` tool geïnstalleerd hebben op je machine om deze import te laten werken. Als voorbeeld ga je het Jam project van de Perforce Public Depot importeren. Om je client in te stellen, moet je de P4PORT omgevingsvariabele laten wijzen naar het Perforce depot:
+In deze `fast-import` directory, zou je een uitvoerbaar Python script genaamd `git-p4` moeten vinden. Je moet Python en de `p4` tool geïnstalleerd hebben op je machine om deze import te laten werken. Als voorbeeld ga je het Jam project van de Perforce Public Depot importeren. Om je client in te stellen, moet je de P4PORT omgevingsvariabele laten wijzen naar het Perforce depot:
 
 	$ export P4PORT=public.perforce.com:1666
 
@@ -718,7 +718,7 @@ Hier heb je 't, een mooie, schone Git repository. Het is belangrijk om te op te
 	$ ls
 	file.rb  lib
 
-Je kunt nog veel meer doen met het `fast-import` tool: verschillende bestandsmodi verwerken, binaire gegevens, meerdere branches en mergen, tags, voortgangsindicatoren, enzovoorts. Een aantal voorbeelden voor complexe scenario's zijn voorhanden in de `contrib/fast-import` directory van de Git broncode, een van de betere is het `git-p4` script dat ik zojuist behandeld heb.
+Je kunt nog veel meer doen met de `fast-import` tool: verschillende bestandsmodi verwerken, binaire gegevens, meerdere branches en mergen, tags, voortgangsindicatoren, enzovoorts. Een aantal voorbeelden voor complexe scenario's zijn voorhanden in de `contrib/fast-import` directory van de Git broncode, een van de betere is het `git-p4` script dat ik zojuist behandeld heb.
 
 ## Samenvatting ##
 
diff --git a/nl/09-git-internals/01-chapter9.markdown b/nl/09-git-internals/01-chapter9.markdown
index ac6228145..24f23e8f6 100644
--- a/nl/09-git-internals/01-chapter9.markdown
+++ b/nl/09-git-internals/01-chapter9.markdown
@@ -896,7 +896,7 @@ Vervolgens, stel dat je verloren commit om een of andere reden niet in de reflog
 	$ git branch –D recover-branch
 	$ rm -Rf .git/logs/
 
-Omdat de reflog gegevens bewaard worden in de `.git/logs/` directory, heb je nu effectief geen reflog meer. Hoe kun je die commit nu herstellen? Één manier is om gebruik te maken van het `git fsck` tool, wat de integriteit van je gegevensbank controleert. Als je het met de `--full` optie uitvoert, dan toont het je alle objecten waarnaar niet gewezen wordt door een ander object:
+Omdat de reflog gegevens bewaard worden in de `.git/logs/` directory, heb je nu effectief geen reflog meer. Hoe kun je die commit nu herstellen? Één manier is om gebruik te maken van de `git fsck` tool, wat de integriteit van je gegevensbank controleert. Als je het met de `--full` optie uitvoert, dan toont het je alle objecten waarnaar niet gewezen wordt door een ander object:
 
 	$ git fsck --full
 	dangling blob d670460b4b4aece5915caf5c68d12f560a9fe3e4
@@ -1010,4 +1010,4 @@ De grootte van je ingepakte repository is omlaag gegaan naar 7 K, wat veel beter
 
 Je moet een redelijk goed begrip hebben van wat Git op de achtergrond doet en, tot een bepaalde hoogte, hoe het geimplementeerd is. Dit hoofdstuk heeft een aantal plumbing commando's besproken – commando's die op een lager niveau zitten en eenvoudige zijn dan de porcelain commando's waarover je in de rest van het boek gelezen hebt. Begrijpen hoe Git op een lager niveau werkt zou het makkelijker moeten maken om te begrijpen waarom het doet wat het doet en ook om je eigen applicaties te schrijven en hulp scripts om jouw specifieke workflow voor je te laten werken.
 
-Git is als een inhouds-toegankelijk bestandssysteem een zeer krachtig tool dat je eenvoudig als meer dan alleen een VCS kunt gebruiken. Ik hoop dat je deze nieuwe kennis van de werking van Git kunt gebruiken om je eigen coole applicatie te bouwen met deze technologie en dat je je prettig voelt bij het gebruik van Git op meer geavanceerde manieren.
+Git is als een inhouds-toegankelijk bestandssysteem een zeer krachtige tool dat je eenvoudig als meer dan alleen een VCS kunt gebruiken. Ik hoop dat je deze nieuwe kennis van de werking van Git kunt gebruiken om je eigen coole applicatie te bouwen met deze technologie en dat je je prettig voelt bij het gebruik van Git op meer geavanceerde manieren.

From 32cd1e5e9883fcc7eddd480e561e2251edee17b4 Mon Sep 17 00:00:00 2001
From: 8loser <8loser@users.noreply.github.com>
Date: Sun, 1 Feb 2015 01:14:26 +0800
Subject: [PATCH 671/690] Update 01-chapter2.markdown
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

"提供"->"提交"
---
 zh-tw/02-git-basics/01-chapter2.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/zh-tw/02-git-basics/01-chapter2.markdown b/zh-tw/02-git-basics/01-chapter2.markdown
index 7ffc67937..52d741749 100644
--- a/zh-tw/02-git-basics/01-chapter2.markdown
+++ b/zh-tw/02-git-basics/01-chapter2.markdown
@@ -331,7 +331,7 @@ A `**/` pattern is available in Git since version 1.8.2.
 
 現在讀者已建立第一個提交！ 讀者可從輸出的訊息看到此提交、放到哪個分支（`master`）、SHA-1查核碼（`463dc4f`）、有多少檔案被更動，以及統計此提交有多少列被新增及移除。
 
-記得提交記錄讀者放在暫存區的快照。 任何讀者未暫存的仍然保持在已被修改狀態；讀者可進行其它的提交，將它增加到歷史。 每一次讀者執行提供，都是記錄專案的快照，而且以後可用來比對或者復原。
+記得提交記錄讀者放在暫存區的快照。 任何讀者未暫存的仍然保持在已被修改狀態；讀者可進行其它的提交，將它增加到歷史。 每一次讀者執行提交，都是記錄專案的快照，而且以後可用來比對或者復原。
 
 ### 跳過暫存區域 ###
 

From 2eeff6aa43eddd143d0b496ed39c5b20041e52d2 Mon Sep 17 00:00:00 2001
From: Geno1024 <754097987@qq.com>
Date: Mon, 16 Feb 2015 11:06:46 +0800
Subject: [PATCH 672/690] Translate a few sentences into zh-CN

---
 zh/02-git-basics/01-chapter2.markdown | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/zh/02-git-basics/01-chapter2.markdown b/zh/02-git-basics/01-chapter2.markdown
index 2a95c60f4..dc4affb53 100644
--- a/zh/02-git-basics/01-chapter2.markdown
+++ b/zh/02-git-basics/01-chapter2.markdown
@@ -183,10 +183,10 @@ Insert 18333fig0201.png
 	build/
 	# 会忽略 doc/notes.txt 但不包括 doc/server/arch.txt
 	doc/*.txt
-	# ignore all .txt files in the doc/ directory
+	# 忽略 doc/ 目录下所有扩展名为 txt 的文件
 	doc/**/*.txt
 
-A `**/` pattern is available in Git since version 1.8.2.
+`**\`通配符从 Git 版本 1.8.2 以上已经可以使用。
 
 ### 查看已暂存和未暂存的更新 ###
 

From 6aa4e9e609e7a936cb10f95a1be692cebc703c03 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?J=C3=B6rg=20Ewald?=
 <Sternenstauner@users.noreply.github.com>
Date: Sat, 28 Feb 2015 00:10:25 +0100
Subject: [PATCH 673/690] Update 01-chapter3.markdown

---
 de/03-git-branching/01-chapter3.markdown | 134 +++++++++++------------
 1 file changed, 67 insertions(+), 67 deletions(-)

diff --git a/de/03-git-branching/01-chapter3.markdown b/de/03-git-branching/01-chapter3.markdown
index f37dca23d..fdcf42280 100644
--- a/de/03-git-branching/01-chapter3.markdown
+++ b/de/03-git-branching/01-chapter3.markdown
@@ -14,7 +14,7 @@ Manche Leute bezeichnen Gits Branching-Modell als dessen „Killer-Feature“, w
 
 <!--To really understand the way Git does branching, we need to take a step back and examine how Git stores its data. As you may remember from Chapter 1, Git doesn’t store data as a series of changesets or deltas, but instead as a series of snapshots.-->
 
-Um wirklich zu verstehen wie Git Branching durchführt, müssen wir einen Schritt zurück gehen und untersuchen wie Git die Daten speichert. Wie Du Dich vielleicht noch an Kapitel 1 erinnerst, speichert Git seine Daten nicht als Serie von Änderungen oder Unterschieden, sondern als Serie von Schnappschüssen.
+Um wirklich zu verstehen wie Git Branching durchführt, müssen wir einen Schritt zurück gehen und untersuchen, wie Git die Daten speichert. Wie Du Dich vielleicht noch an Kapitel 1 erinnerst, speichert Git seine Daten nicht als Serie von Änderungen oder Unterschieden, sondern als Serie von Schnappschüssen.
 
 <!--When you commit in Git, Git stores a commit object that contains a pointer to the snapshot of the content you staged, the author and message metadata, and zero or more pointers to the commit or commits that were the direct parents of this commit: zero parents for the first commit, one parent for a normal commit, and multiple parents for a commit that results from a merge of two or more branches.-->
 
@@ -33,7 +33,7 @@ Wenn Du einen Commit mit dem Kommando `git commit` erstellst, erzeugt Git für j
 
 <!--Your Git repository now contains five objects: one blob for the contents of each of your three files, one tree that lists the contents of the directory and specifies which file names are stored as which blobs, and one commit with the pointer to that root tree and all the commit metadata. Conceptually, the data in your Git repository looks something like Figure 3-1.-->
 
-Dein Git-Repository enthält nun fünf Objekte: einen Blob für den Inhalt jeder der drei Dateien, einen Baum, der den Inhalt des Verzeichnisses auflistet und spezifiziert welcher Dateiname zu welchem Blob gehört, sowie einen Zeiger, der auf die Wurzel des Projektbaumes und die Metadaten des Commits verweist. Prinzipiell sehen Deine Daten im Git Repository wie in Abbildung 3-1 aus.
+Dein Git-Repository enthält nun fünf Objekte: einen Blob für den Inhalt jeder der drei Dateien, einen Baum, der den Inhalt des Verzeichnisses auflistet und spezifiziert, welcher Dateiname zu welchem Blob gehört, sowie einen Zeiger, der auf die Wurzel des Projektbaumes und die Metadaten des Commits verweist. Prinzipiell sehen Deine Daten im Git Repository wie in Abbildung 3-1 aus.
 
 <!--Figure 3-1. Single commit repository data.-->
 
@@ -130,7 +130,7 @@ Abbildung 3-8. HEAD zeigt nach einem Checkout auf einen anderen Branch.
 
 <!--That command did two things. It moved the HEAD pointer back to point to the `master` branch, and it reverted the files in your working directory back to the snapshot that `master` points to. This also means the changes you make from this point forward will diverge from an older version of the project. It essentially rewinds the work you’ve done in your testing branch temporarily so you can go in a different direction.-->
 
-Das Kommando hat zwei Dinge veranlasst. Zum einen bewegt es den HEAD-Zeiger zurück zum `master`-Branch, zum anderen setzt es alle Dateien im Arbeitsverzeichnis auf den Bearbeitungsstand des letzte Commits in diesem Zweig zurück. Das bedeutet aber auch, dass nun alle Änderungen am Projekt vollkommen unabhängig von älteren Projektversionen erfolgen. Kurz gesagt, werden alle Änderungen aus dem `testing`-Zweig vorübergehend rückgängig gemacht und Du hast die Möglichkeit einen vollkommen neuen Weg in der Entwicklung einzuschlagen.
+Das Kommando hat zwei Dinge veranlasst. Zum einen bewegt es den HEAD-Zeiger zurück zum `master`-Branch, zum anderen setzt es alle Dateien im Arbeitsverzeichnis auf den Bearbeitungsstand des letzten Commits in diesem Zweig zurück. Das bedeutet aber auch, dass nun alle Änderungen am Projekt vollkommen unabhängig von älteren Projektversionen erfolgen. Kurz gesagt, werden alle Änderungen aus dem `testing`-Zweig vorübergehend rückgängig gemacht und Du hast die Möglichkeit, einen vollkommen neuen Weg in der Entwicklung einzuschlagen.
 
 <!--Let’s make a few changes and commit again:-->
 
@@ -141,7 +141,7 @@ Lass uns ein paar Änderungen machen und mit einem Commit festhalten:
 
 <!--Now your project history has diverged (see Figure 3-9). You created and switched to a branch, did some work on it, and then switched back to your main branch and did other work. Both of those changes are isolated in separate branches: you can switch back and forth between the branches and merge them together when you’re ready. And you did all that with simple `branch` and `checkout` commands.-->
 
-Nun verzweigen sich die Projektverläufe (siehe Abbildung 3-9). Du hast einen Branch erstellt und zu ihm gewechselt, hast ein bisschen gearbeitet, bist zu Deinem Haupt-Zweig zurückgekehrt und hast da was ganz anderes gemacht. Beide Arbeiten existieren vollständig unabhängig voneinander in zwei unterschiedlichen Branches. Du kannst beliebig zwischen den beiden Zweigen wechseln und sie zusammenführen, wenn Du meinst es wäre soweit. Und das alles hast Du mit simplen `branch` und `checkout`-Befehlen vollbracht.
+Nun verzweigen sich die Projektverläufe (siehe Abbildung 3-9). Du hast einen Branch erstellt und zu ihm gewechselt, hast ein bisschen gearbeitet, bist zu Deinem Haupt-Zweig zurückgekehrt und hast da was ganz anderes gemacht. Beide Arbeiten existieren vollständig unabhängig voneinander in zwei unterschiedlichen Branches. Du kannst beliebig zwischen den beiden Zweigen wechseln und sie zusammenführen, wenn Du meinst, es wäre soweit. Und das alles hast Du mit simplen `branch` und `checkout`-Befehlen vollbracht.
 
 <!--Figure 3-9. The branch histories have diverged.-->
 
@@ -150,7 +150,7 @@ Abbildung 3-9. Die Historie läuft auseinander.
 
 <!--Because a branch in Git is in actuality a simple file that contains the 40 character SHA-1 checksum of the commit it points to, branches are cheap to create and destroy. Creating a new branch is as quick and simple as writing 41 bytes to a file (40 characters and a newline).-->
 
-Branches können in Git spielend erstellt und entfernt werden, da sie nur kleine Dateien sind, die eine 40 Zeichen lange SHA-1 Prüfsumme der Commits enthalten, auf die sie verweisen. Einen neuen Zweig zu erstellen erzeugt ebenso viel Aufwand wie das Schreiben einer 41 Byte großen Datei (40 Zeichen und einen Zeilenumbruch).
+Branches können in Git spielend erstellt und entfernt werden, da sie nur kleine Dateien sind, die eine 40 Zeichen lange SHA-1 Prüfsumme der Commits enthalten, auf die sie verweisen. Einen neuen Zweig zu erstellen, erzeugt ebenso viel Aufwand wie das Schreiben einer 41 Byte großen Datei (40 Zeichen und einen Zeilenumbruch).
 
 <!--This is in sharp contrast to the way most VCS tools branch, which involves copying all of the project’s files into a second directory. This can take several seconds or even minutes, depending on the size of the project, whereas in Git the process is always instantaneous. Also, because we’re recording the parents when we commit, finding a proper merge base for merging is automatically done for us and is generally very easy to do. These features help encourage developers to create and use branches often.-->
 
@@ -172,7 +172,7 @@ Lass uns das Ganze an einem Beispiel durchgehen, dessen Workflow zum Thema Branc
 <!--3. Do some work in that branch.-->
 
 1. Arbeite an einer Webseite.
-2. Erstell einen Branch für irgendeine neue Geschichte, an der Du arbeitest.
+2. Erstelle einen Branch für irgendeine neue Geschichte, an der Du arbeitest.
 3. Arbeite in dem Branch.
 
 <!--At this stage, you’ll receive a call that another issue is critical and you need a hotfix. You’ll do the following:-->
@@ -185,7 +185,7 @@ In diesem Augenblick kommt ein Anruf, dass ein kritisches Problem aufgetreten is
 <!--4. Switch back to your original story and continue working.-->
 
 1. Schalte zurück zu Deinem „Produktiv“-Zweig.
-2. Erstelle eine Branch für den Hotfix.
+2. Erstelle einen Branch für den Hotfix.
 3. Nach dem Testen führst Du den Hotfix-Branch mit dem „Produktiv“-Branch zusammen.
 4. Schalte wieder auf Deine alte Arbeit zurück und werkel weiter.
 
@@ -203,7 +203,7 @@ Abbildung 3-10. Eine kurze, einfache Commit-Historie
 
 <!--You’ve decided that you’re going to work on issue #53 in whatever issue-tracking system your company uses. To be clear, Git isn’t tied into any particular issue-tracking system; but because issue #53 is a focused topic that you want to work on, you’ll create a new branch in which to work. To create a branch and switch to it at the same time, you can run the `git checkout` command with the `-b` switch:-->
 
-Du hast Dich dafür entschieden an dem Issue #53, des Issue-Trackers XY, zu arbeiten. Um eines klarzustellen, Git ist an kein Issue-Tracking-System gebunden. Da der Issue #53 allerdings ein Schwerpunktthema betrifft, wirst Du einen neuen Branch erstellen um daran zu arbeiten. Um in einem Arbeitsschritt einen neuen Branch zu erstellen und zu aktivieren kannst Du das Kommando `git checkout` mit der Option `-b` verwenden:
+Du hast Dich dafür entschieden, am Issue #53 des Issue-Trackers XY zu arbeiten. Um eines klarzustellen, Git ist an kein Issue-Tracking-System gebunden. Da der Issue #53 allerdings ein Schwerpunktthema betrifft, wirst Du einen neuen Branch erstellen, um daran zu arbeiten. Um in einem Arbeitsschritt einen neuen Branch zu erstellen und zu aktivieren, kannst Du das Kommando `git checkout` mit der Option `-b` verwenden:
 
 	$ git checkout -b iss53
 	Switched to a new branch 'iss53'
@@ -238,18 +238,18 @@ Abbildung 3-12. Der `iss53`-Branch hat mit Deiner Arbeit Schritt gehalten.
 
 <!--Now you get the call that there is an issue with the web site, and you need to fix it immediately. With Git, you don’t have to deploy your fix along with the `iss53` changes you’ve made, and you don’t have to put a lot of effort into reverting those changes before you can work on applying your fix to what is in production. All you have to do is switch back to your master branch.-->
 
-Nun bekommst Du einen Anruf, in dem Dir mitgeteilt wird, dass es ein Problem mit der Internet-Seite gibt, das Du umgehend beheben sollst. Mit Git musst Du Deine Fehlerkorrektur nicht zusammen mit den `iss53`-Änderungen einbringen. Und Du musst keine Zeit damit verschwenden Deine bisherigen Änderungen rückgängig zu machen, bevor Du mit der Fehlerbehebung an der Produktionsumgebung beginnen kannst. Alles was Du tun musst, ist zu Deinem MASTER-Branch wechseln.
+Nun bekommst Du einen Anruf, in dem Dir mitgeteilt wird, dass es ein Problem mit der Internet-Seite gibt, das Du umgehend beheben sollst. Mit Git musst Du Deine Fehlerkorrektur nicht zusammen mit den `iss53`-Änderungen einbringen. Und Du musst keine Zeit damit verschwenden, Deine bisherigen Änderungen rückgängig zu machen, bevor Du mit der Fehlerbehebung an der Produktionsumgebung beginnen kannst. Alles was Du tun musst, ist zu Deinem MASTER-Branch wechseln.
 
 <!--However, before you do that, note that if your working directory or staging area has uncommitted changes that conflict with the branch you’re checking out, Git won’t let you switch branches. It’s best to have a clean working state when you switch branches. There are ways to get around this (namely, stashing and commit amending) that we’ll cover later. For now, you’ve committed all your changes, so you can switch back to your master branch:-->
 
-Beachte jedoch, dass Dich Git den Branch nur wechseln lässt, wenn bisherige Änderungen in Deinem Arbeitsverzeichnis oder Deiner Staging-Area nicht in Konflikt mit dem Zweig stehen, zu dem Du nun wechseln möchtest. Am besten es liegt ein sauberer Status vor wenn man den Branch wechselt. Wir werden uns später mit Wegen befassen, dieses Verhalten zu umgehen (namentlich „Stashing“ und „Commit Ammending“). Vorerst aber hast Du Deine Änderungen bereits comitted, sodass Du zu Deinem MASTER-Branch zurückwechseln kannst.
+Beachte jedoch, dass Dich Git den Branch nur wechseln lässt, wenn bisherige Änderungen in Deinem Arbeitsverzeichnis oder Deiner Staging-Area nicht in Konflikt mit dem Zweig stehen, zu dem Du nun wechseln möchtest. Am besten es liegt ein sauberer Status vor, wenn man den Branch wechselt. Wir werden uns später mit Wegen befassen, dieses Verhalten zu umgehen (namentlich „Stashing“ und „Commit Ammending“). Vorerst aber hast Du Deine Änderungen bereits comitted, sodass Du zu Deinem MASTER-Branch zurückwechseln kannst.
 
 	$ git checkout master
 	Switched to branch 'master'
 
 <!--At this point, your project working directory is exactly the way it was before you started working on issue #53, and you can concentrate on your hotfix. This is an important point to remember: Git resets your working directory to look like the snapshot of the commit that the branch you check out points to. It adds, removes, and modifies files automatically to make sure your working copy is what the branch looked like on your last commit to it.-->
 
-Zu diesem Zeitpunkt befindet sich das Arbeitsverzeichnis des Projektes in exakt dem gleichen Zustand, in dem es sich befand, als Du mit der Arbeit an Issue #53 begonnen hast und Du kannst Dich direkt auf Deinen Hotfix konzentrieren. Dies ist ein wichtiger Moment um sich vor Augen zu halten, dass Git Dein Arbeitsverzeichnis auf den Zustand des Commits, auf den dieser Branch zeigt, zurücksetzt. Es erstellt, entfernt und verändert Dateien automatisch, um sicherzustellen, dass Deine Arbeitskopie haargenau so aussieht wie der Zweig nach Deinem letzten Commit.
+Zu diesem Zeitpunkt befindet sich das Arbeitsverzeichnis des Projektes in exakt dem gleichen Zustand, in dem es sich befand, als Du mit der Arbeit an Issue #53 begonnen hast und Du kannst Dich direkt auf Deinen Hotfix konzentrieren. Dies ist ein wichtiger Moment, um sich vor Augen zu halten, dass Git Dein Arbeitsverzeichnis auf den Zustand des Commits, auf den dieser Branch zeigt, zurücksetzt. Es erstellt, entfernt und verändert Dateien automatisch, um sicherzustellen, dass Deine Arbeitskopie haargenau so aussieht wie der Zweig nach Deinem letzten Commit.
 
 <!--Next, you have a hotfix to make. Let’s create a hotfix branch on which to work until it’s completed (see Figure 3-13):-->
 
@@ -269,7 +269,7 @@ Abbildung 3-13. Der Hotfix-Branch basiert auf dem zurückliegenden Master-Branch
 
 <!--You can run your tests, make sure the hotfix is what you want, and merge it back into your master branch to deploy to production. You do this with the `git merge` command:-->
 
-Mach Deine Tests, stell sicher das sich der Hotfix verhält wie erwartet und führe ihn mit dem Master-Branch zusammen, um ihn in die Produktionsumgebung zu integrieren. Das machst Du mit dem `git merge`-Kommando:
+Mach Deine Tests, stelle sicher, dass sich der Hotfix verhält wie erwartet und führe ihn mit dem Master-Branch zusammen, um ihn in die Produktionsumgebung zu integrieren. Das machst Du mit dem `git merge`-Kommando:
 
 	$ git checkout master
 	$ git merge hotfix
@@ -280,7 +280,7 @@ Mach Deine Tests, stell sicher das sich der Hotfix verhält wie erwartet und fü
 
 <!--You’ll notice the phrase "Fast forward" in that merge. Because the commit pointed to by the branch you merged in was directly upstream of the commit you’re on, Git moves the pointer forward. To phrase that another way, when you try to merge one commit with a commit that can be reached by following the first commit’s history, Git simplifies things by moving the pointer forward because there is no divergent work to merge together — this is called a "fast forward".-->
 
-Du wirst die Mitteilung „Fast Forward“ während des Zusammenführens bemerken. Da der neue Commit direkt von dem ursprünglichen Commit, auf den sich der nun eingebrachte Zweig bezieht, abstammt, bewegt Git einfach den Zeiger weiter. Mit anderen Worten kann Git den neuen Commit, durch Verfolgen der Commitabfolge, direkt erreichen, dann bewegt es ausschließlich den Branch-Zeiger. Zu einer tatsächlichen Kombination der Commits besteht ja kein Anlass. Dieses Vorgehen wird „Fast Forward“ genannt.
+Du wirst die Mitteilung „Fast Forward“ während des Zusammenführens bemerken. Da der neue Commit direkt von dem ursprünglichen Commit, auf den sich der nun eingebrachte Zweig bezieht, abstammt, bewegt Git einfach den Zeiger weiter. Mit anderen Worten kann Git den neuen Commit durch Verfolgen der Commitabfolge direkt erreichen, dann bewegt es ausschließlich den Branch-Zeiger. Zu einer tatsächlichen Kombination der Commits besteht ja kein Anlass. Dieses Vorgehen wird „Fast Forward“ genannt.
 
 <!--Your change is now in the snapshot of the commit pointed to by the `master` branch, and you can deploy your change (see Figure 3-14).-->
 
@@ -316,7 +316,7 @@ Abbildung 3-15. Dein `iss53`-Branch kann sich unabhängig weiterentwickeln.
 
 <!--It’s worth noting here that the work you did in your `hotfix` branch is not contained in the files in your `iss53` branch. If you need to pull it in, you can merge your `master` branch into your `iss53` branch by running `git merge master`, or you can wait to integrate those changes until you decide to pull the `iss53` branch back into `master` later.-->
 
-An dieser Stelle ist anzumerken, dass die Änderungen an dem `hotfix`-Branch nicht in Deinen `iss53`-Zweig eingeflossen sind. Falls nötig kannst Du den `master`-Branch allerdings mit dem Kommando `git merge master` mit Deinem Zweig kombinieren. Oder Du wartest, bis Du den `iss53`-Branch später in den Master-Zweig zurückführst.
+An dieser Stelle ist anzumerken, dass die Änderungen an dem `hotfix`-Branch nicht in Deinen `iss53`-Zweig eingeflossen sind. Falls nötig, kannst Du den `master`-Branch allerdings mit dem Kommando `git merge master` mit Deinem Zweig kombinieren. Oder Du wartest, bis Du den `iss53`-Branch später in den Master-Zweig zurückführst.
 
 <!--### Basic Merging ###-->
 
@@ -324,7 +324,7 @@ An dieser Stelle ist anzumerken, dass die Änderungen an dem `hotfix`-Branch nic
 
 <!--Suppose you’ve decided that your issue #53 work is complete and ready to be merged into your `master` branch. In order to do that, you’ll merge in your `iss53` branch, much like you merged in your `hotfix` branch earlier. All you have to do is check out the branch you wish to merge into and then run the `git merge` command:-->
 
-Angenommen Du entscheidest dich, dass Deine Arbeit an issue #53 getan ist und Du diese mit der `master` Branch zusammenführen möchtest. Das passiert, indem Du ein `merge` in die `iss53` Branch machst, ähnlich dem `merge` mit der `hotfix` Branch von vorhin. Alles was Du machen musst, ist ein `checkout` der Branch, in die Du das `merge` machen willst und das Ausführen des Kommandos `git merge`:
+Angenommen, Du entscheidest dich, dass Deine Arbeit an issue #53 getan ist und Du diese mit der `master` Branch zusammenführen möchtest. Das passiert, indem Du ein `merge` in die `iss53` Branch machst, ähnlich dem `merge` mit der `hotfix` Branch von vorhin. Alles was Du machen musst, ist ein `checkout` der Branch, in die Du das `merge` machen willst und das Ausführen des Kommandos `git merge`:
 
 	$ git checkout master
 	$ git merge iss53
@@ -335,7 +335,7 @@ Angenommen Du entscheidest dich, dass Deine Arbeit an issue #53 getan ist und Du
 
 <!--This looks a bit different than the `hotfix` merge you did earlier. In this case, your development history has diverged from some older point. Because the commit on the branch you’re on isn’t a direct ancestor of the branch you’re merging in, Git has to do some work. In this case, Git does a simple three-way merge, using the two snapshots pointed to by the branch tips and the common ancestor of the two. Figure 3-16 highlights the three snapshots that Git uses to do its merge in this case.-->
 
-Das sieht ein bisschen anders aus als das `hotfix merge` von vorhin. Hier läuft Deine Entwicklungshistorie auseinander. Ein `commit` auf Deine Arbeits-Branch ist kein direkter Nachfolger der Branch in die Du das `merge` gemacht hast, Git hat da einiges zu tun, es macht einen 3-Wege `merge`: es geht von den beiden `snapshots` der Branches und dem allgemeinen Nachfolger der beiden aus. Abbildung 3-16 zeigt die drei `snapshots`, die Git in diesem Fall für das `merge` verwendet.
+Das sieht ein bisschen anders aus als das `hotfix merge` von vorhin. Hier läuft Deine Entwicklungshistorie auseinander. Ein `commit` auf Deine Arbeits-Branch ist kein direkter Nachfolger der Branch, in die Du das `merge` gemacht hast, Git hat da einiges zu tun, es macht einen 3-Wege `merge`: es geht von den beiden `snapshots` der Branches und dem allgemeinen Nachfolger der beiden aus. Abbildung 3-16 zeigt die drei `snapshots`, die Git in diesem Fall für das `merge` verwendet.
 
 <!--Figure 3-16. Git automatically identifies the best common-ancestor merge base for branch merging.-->
 
@@ -403,7 +403,7 @@ Alles, was einen 'merge' Konflikt aufweist und nicht gelöst werden konnte, wird
 
 <!--This means the version in HEAD (your master branch, because that was what you had checked out when you ran your merge command) is the top part of that block (everything above the `=======`), while the version in your `iss53` branch looks like everything in the bottom part. In order to resolve the conflict, you have to either choose one side or the other or merge the contents yourself. For instance, you might resolve this conflict by replacing the entire block with this:-->
 
-Das heisst, die Version in HEAD (Deines 'master'-Branches, denn der wurde per 'checkout' aktiviert als Du das 'merge' gemacht hast) ist der obere Teil des Blocks (alles oberhalb von '======='), und die Version aus dem `iss53`-Branch sieht wie der darunter befindliche Teil aus. Um den Konflikt zu lösen, musst Du Dich entweder für einen der beiden Teile entscheiden oder Du ersetzt den Teil komplett:
+Das heißt, die Version in HEAD (Deines 'master'-Branches, denn der wurde per 'checkout' aktiviert als Du das 'merge' gemacht hast) ist der obere Teil des Blocks (alles oberhalb von '======='), und die Version aus dem `iss53`-Branch sieht wie der darunter befindliche Teil aus. Um den Konflikt zu lösen, musst Du Dich entweder für einen der beiden Teile entscheiden oder Du ersetzt den Teil komplett:
 
 	<div id="footer">
 	please contact us at email.support@github.com
@@ -412,8 +412,8 @@ Das heisst, die Version in HEAD (Deines 'master'-Branches, denn der wurde per 'c
 <!--This resolution has a little of each section, and I’ve fully removed the `<<<<<<<`, `=======`, and `>>>>>>>` lines. After you’ve resolved each of these sections in each conflicted file, run `git add` on each file to mark it as resolved. Staging the file marks it as resolved in Git.-->
 <!--If you want to use a graphical tool to resolve these issues, you can run `git mergetool`, which fires up an appropriate visual merge tool and walks you through the conflicts:-->
 
-Diese Lösung hat von beiden Teilen etwas und ich habe die Zeilen mit `<<<<<<<`, `=======`, und `>>>>>>>` komplett gelöscht. Nachdem Du alle problematischen Bereiche, in allen durch den Konflikt betroffenen Dateien, beseitigt hast, führe einfach `git add` für alle betroffenen Dateien aus und markieren sie damit als bereinigt. Dieses 'staging' der Dateien markiert sie für Git als bereinigt.
-Wenn Du ein grafischen Tool zur Bereinigung benutzen willst, dann verwende `git mergetool`. Das welches ein passendes grafisches 'merge'-Tool startet und Dich durch die Konfliktbereiche führt:
+Diese Lösung hat von beiden Teilen etwas und ich habe die Zeilen mit `<<<<<<<`, `=======`, und `>>>>>>>` komplett gelöscht. Nachdem Du alle problematischen Bereiche in allen von dem Konflikt betroffenen Dateien beseitigt hast, führe einfach `git add` für alle betroffenen Dateien aus und markiere sie damit als bereinigt. Dieses 'staging' der Dateien markiert sie für Git als bereinigt.
+Wenn Du ein grafisches Tool zur Bereinigung benutzen willst, dann verwende `git mergetool`, welches ein passendes grafisches 'merge'-Tool startet und Dich durch die Konfliktbereiche führt:
 
 	$ git mergetool
 
@@ -451,7 +451,7 @@ Du kannst `git status` erneut ausführen, um zu sehen, ob alle Konflikte gelöst
 
 <!--If you’re happy with that, and you verify that everything that had conflicts has been staged, you can type `git commit` to finalize the merge commit. The commit message by default looks something like this:-->
 
-Wenn Du zufrieden bist und Du geprüft hast, dass alle Konflikte beseitigt wurden, kannst Du `git commit` ausführen um den 'merge commit' abzuschliessen. Die Standardbeschreibung für diese Art 'commit' sieht wie folgt aus:
+Wenn Du zufrieden bist und Du geprüft hast, dass alle Konflikte beseitigt wurden, kannst Du `git commit` ausführen, um den 'merge commit' abzuschliessen. Die Standardbeschreibung für diese Art 'commit' sieht wie folgt aus:
 
 	Merge branch 'iss53'
 
@@ -466,7 +466,7 @@ Wenn Du zufrieden bist und Du geprüft hast, dass alle Konflikte beseitigt wurde
 
 <!--You can modify that message with details about how you resolved the merge if you think it would be helpful to others looking at this merge in the future — why you did what you did, if it’s not obvious.-->
 
-Wenn Du glaubst für zukünftige Betrachter des Commits könnte interessant sein warum Du getan hast, was Du getan hast, dann kannst Du der Commit-Beschreibung noch zusätzliche Informationen hinzufügen – sofern das nicht trivial erscheint.
+Wenn Du glaubst, für zukünftige Betrachter des Commits könnte interessant sein, warum Du getan hast, was Du getan hast, dann kannst Du der Commit-Beschreibung noch zusätzliche Informationen hinzufügen – sofern das nicht trivial erscheint.
 
 <!--## Branch Management ##-->
 ## Branch Management ##
@@ -522,25 +522,25 @@ Die Liste zeigt Dir den anderen Branch. Er enthält Arbeit, die noch nicht gemer
 
 <!--If you really do want to delete the branch and lose that work, you can force it with `-D`, as the helpful message points out.-->
 
-Wenn Du den Branch trotzdem löschen willst – und damit alle Änderungen dieses Branches verlieren – kannst Du das mit `git branch -D testing` machen.
+Wenn Du den Branch trotzdem löschen und damit alle Änderungen dieses Branches verlieren willst, kannst Du das mit `git branch -D testing` machen.
 
 <!--## Branching Workflows ##-->
 ## Branching Workflows ##
 
 <!--Now that you have the basics of branching and merging down, what can or should you do with them? In this section, we’ll cover some common workflows that this lightweight branching makes possible, so you can decide if you would like to incorporate it into your own development cycle.-->
 
-Jetzt da Du die Grundlagen von 'branching' und 'merging' kennst, fragst Du Dich sicher, was Du damit anfangen kannst. In diesem Abschnitt werden wir uns typische Workflows anschauen, die dieses leichtgewichtige 'branching' möglich macht. Und Du kannst dann entscheiden, ob Du es in Deinem eigene Entwicklungszyklus verwenden willst.
+Jetzt, da Du die Grundlagen von 'branching' und 'merging' kennst, fragst Du Dich sicher, was Du damit anfangen kannst. In diesem Abschnitt werden wir uns typische Workflows anschauen, die dieses leichtgewichtige 'branching' möglich macht. Und Du kannst dann entscheiden, ob Du es in Deinem eigene Entwicklungszyklus verwenden willst.
 
 <!--### Long-Running Branches ###-->
 ### Langfristige Branches ###
 
 <!--Because Git uses a simple three-way merge, merging from one branch into another multiple times over a long period is generally easy to do. This means you can have several branches that are always open and that you use for different stages of your development cycle; you can merge regularly from some of them into others.-->
 
-Da Git das einfachen 3-Wege-'merge' verwendet, ist häufiges Zusammenführen von einer Branch in eine andere über einen langen Zeitraum generell einfach zu bewerkstelligen. Das heisst, Du kannst mehrere Branches haben, die alle offen sind und auf unterschiedlichen Ebenen Deines Entwicklungszyklus verwendung finden, und diese regelmäßig ineinander zusammenführen.
+Da Git das einfache 3-Wege-'merge' verwendet, ist häufiges Zusammenführen von einer Branch in eine andere über einen langen Zeitraum generell einfach zu bewerkstelligen. Das heißt, Du kannst mehrere Branches haben, die alle offen sind und auf unterschiedlichen Ebenen Deines Entwicklungszyklus Verwendung finden, und diese regelmäßig ineinander zusammenführen.
 
 <!--Many Git developers have a workflow that embraces this approach, such as having only code that is entirely stable in their `master` branch — possibly only code that has been or will be released. They have another parallel branch named develop or next that they work from or use to test stability — it isn’t necessarily always stable, but whenever it gets to a stable state, it can be merged into `master`. It’s used to pull in topic branches (short-lived branches, like your earlier `iss53` branch) when they’re ready, to make sure they pass all the tests and don’t introduce bugs.-->
 
-Viele Git Entwickler verfolgen mit ihrem Workflow den Ansatz nur den stabilen Code in dem `master`-Branch zu halten – möglicherweise auch nur Code, der released wurde oder werden kann. Sie betreiben parallel einen anderen Branch zum Arbeiten oder Testen. Wenn dieser paralelle Zweig einen stabilen Status erreicht, kann er mit dem `master`-Branch zusammengeführt werden. Dies findet bei Themen bezogenen Branches (kurzfristigen Branches, wie der zuvor genante `iss53`-Branch) Anwendung, um sicherzustellen, dass dieser die Tests besteht und keine Fehler verursacht.
+Viele Git Entwickler verfolgen mit ihrem Workflow den Ansatz, nur den stabilen Code in dem `master`-Branch zu halten – möglicherweise auch nur Code, der released wurde oder werden kann. Sie betreiben parallel einen anderen Branch zum Arbeiten oder Testen. Wenn dieser parallele Zweig einen stabilen Status erreicht, kann er mit dem `master`-Branch zusammengeführt werden. Dies findet bei themenbezogenen Branches (kurzfristigen Branches, wie der zuvor genannte `iss53`-Branch) Anwendung, um sicherzustellen, dass dieser die Tests besteht und keine Fehler verursacht.
 
 <!--In reality, we’re talking about pointers moving up the line of commits you’re making. The stable branches are farther down the line in your commit history, and the bleeding-edge branches are farther up the history (see Figure 3-18).-->
 
@@ -553,7 +553,7 @@ Abbildung 3-18. Stabilere Branches sind generell weiter unten im Entwicklungsver
 
 <!--It’s generally easier to think about them as work silos, where sets of commits graduate to a more stable silo when they’re fully tested (see Figure 3-19).-->
 
-Es ist leichter sich die verschiedenen Branches als Arbeitsdepots vorzustellen, in denen Sätze von Commits in stabilere Depots aufsteigen, sobald sie ausreichend getestet wurden (siehe Abbildung 3-19).
+Es ist leichter, sich die verschiedenen Branches als Arbeitsdepots vorzustellen, in denen Sätze von Commits in stabilere Depots aufsteigen, sobald sie ausreichend getestet wurden (siehe Abbildung 3-19).
 
 <!--Figure 3-19. It may be helpful to think of your branches as silos.-->
 
@@ -563,24 +563,24 @@ Abbildung 3-19. Es könnte hilfreich sein, sich die Branches als Depots vorzuste
 <!--You can keep doing this for several levels of stability. Some larger projects also have a `proposed` or `pu` (proposed updates) branch that has integrated branches that may not be ready to go into the `next` or `master` branch. The idea is that your branches are at various levels of stability; when they reach a more stable level, they’re merged into the branch above them.-->
 <!--Again, having multiple long-running branches isn’t necessary, but it’s often helpful, especially when you’re dealing with very large or complex projects.-->
 
-Das lässt sich für beliebig viele Stabilitätsabstufungen umsetzen. Manche größeren Projekte haben auch einen `proposed` (Vorgeschlagen) oder `pu` (proposed updates – vorgeschlagene Updates) Zweig mit Branches die vielleicht noch nicht bereit sind in den `next`- oder `master`-Branch integriert zu werden. Die Idee dahinter ist, dass Deine Branches verschiedene Stabilitätsabstufungen repräsentieren. Sobald sie eine stabilere Stufe erreichen, werden sie in den nächsthöheren Branch vereinigt.
+Das lässt sich für beliebig viele Stabilitätsabstufungen umsetzen. Manche größeren Projekte haben auch einen `proposed` (vorgeschlagenen) oder `pu` (proposed updates – vorgeschlagene Updates) Zweig mit Branches, die vielleicht noch nicht bereit sind, in den `next`- oder `master`-Branch integriert zu werden. Die Idee dahinter ist, dass Deine Branches verschiedene Stabilitätsabstufungen repräsentieren. Sobald sie eine stabilere Stufe erreichen, werden sie mit dem nächsthöheren Branch zusammengeführt.
 
-Nochmal, langfristig verschiedene Branches paralell laufen zu lassen ist nicht notwendig, aber oft hilfreich. Insbesondere wenn man es mit sehr großen oder komplexen Projekten zu tun hat.
+Nochmal, langfristig verschiedene Branches parallel laufen zu lassen, ist nicht notwendig, aber oft hilfreich. Insbesondere wenn man es mit sehr großen oder komplexen Projekten zu tun hat.
 
 <!--### Topic Branches ###-->
 ### Themen-Branches ###
 
 <!--Topic branches, however, are useful in projects of any size. A topic branch is a short-lived branch that you create and use for a single particular feature or related work. This is something you’ve likely never done with a VCS before because it’s generally too expensive to create and merge branches. But in Git it’s common to create, work on, merge, and delete branches several times a day.-->
 
-Themen-Branches sind in jedem Projekt nützlich, egal bei welcher Größe. Ein Themen-Branch ist ein kurzlebiger Zweig der für eine spezielle Aufgabe oder ähnliche Arbeiten erstellt und benutzt wird. Das ist vielleicht etwas was Du noch nie zuvor mit einem Versionierungssystem gemacht hast, weil es normalerweise zu aufwändig und mühsam ist Branches zu erstellen und zusammenzuführen. Mit Git ist es allerdings vollkommen geläufig mehrmals am Tag Branches zu erstellen, an ihnen zu arbeiten, sie zusammenzuführen und sie anschließend wieder zu löschen.
+Themen-Branches sind in jedem Projekt nützlich, egal bei welcher Größe. Ein Themen-Branch ist ein kurzlebiger Zweig, der für eine spezielle Aufgabe oder ähnliche Arbeiten erstellt und benutzt wird. Das ist vielleicht etwas, was Du noch nie zuvor mit einem Versionierungssystem gemacht hast, weil es normalerweise zu aufwändig und mühsam ist, Branches zu erstellen und zusammenzuführen. Mit Git ist es allerdings vollkommen geläufig, mehrmals am Tag Branches zu erstellen, an ihnen zu arbeiten, sie zusammenzuführen und sie anschließend wieder zu löschen.
 
 <!--You saw this in the last section with the `iss53` and `hotfix` branches you created. You did a few commits on them and deleted them directly after merging them into your main branch. This technique allows you to context-switch quickly and completely — because your work is separated into silos where all the changes in that branch have to do with that topic, it’s easier to see what has happened during code review and such. You can keep the changes there for minutes, days, or months, and merge them in when they’re ready, regardless of the order in which they were created or worked on.-->
 
-Du hast das im letzten Abschnitt an den von Dir erstellten `iss53`- und `hotfix`-Branches gesehen. Du hast mehrere Commits auf sie angewendet und sie unmittelbar nach Zusammenführung mit Deinem Hauptzweig gelöscht. Diese Technik erlaubt es Dir schnell und vollständig den Kontext zu wechseln. Da Deine Arbeit in verschiedene Depots aufgeteilt ist, in denen alle Änderungen unter die Thematik dieses Branches fallen, ist es leichter nachzuvollziehen was bei Code-Überprüfungen und ähnlichem geschehen ist.
+Du hast das im letzten Abschnitt an den von Dir erstellten `iss53`- und `hotfix`-Branches gesehen. Du hast mehrere Commits auf sie angewendet und sie unmittelbar nach Zusammenführung mit Deinem Hauptzweig gelöscht. Diese Technik erlaubt es Dir, schnell und vollständig den Kontext zu wechseln. Da Deine Arbeit in verschiedene Depots aufgeteilt ist, in denen alle Änderungen unter die Thematik dieses Branches fallen, ist es leichter nachzuvollziehen, was bei Code-Überprüfungen und ähnlichem geschehen ist.
 
 <!--Consider an example of doing some work (on `master`), branching off for an issue (`iss91`), working on it for a bit, branching off the second branch to try another way of handling the same thing (`iss91v2`), going back to your master branch and working there for a while, and then branching off there to do some work that you’re not sure is a good idea (`dumbidea` branch). Your commit history will look something like Figure 3-20.-->
 
-Stell Dir vor, Du arbeitest ein bisschen (in `master`), erstellst mal eben einen Branch für einen Fehler (`iss91`), arbeitest an dem für eine Weile, erstellst einen zweiten Branch um eine andere Problemlösung für den selben Fehler auszuprobieren (`iss91v2`), wechselst zurück zu Deinem MASTER-Branch, arbeitest dort ein bisschen und machst dann einen neuen Branch für etwas, wovon Du nicht weißt ob's eine gute Idee ist (`dumbidea`-Branch). Dein Commit-Verlauf wird wie in Abbildung 3-20 aussehen.
+Stell Dir vor, Du arbeitest ein bisschen (in `master`), erstellst mal eben einen Branch für einen Fehler (`iss91`), arbeitest an dem für eine Weile, erstellst einen zweiten Branch, um eine andere Problemlösung für den selben Fehler auszuprobieren (`iss91v2`), wechselst zurück zu Deinem MASTER-Branch, arbeitest dort ein bisschen und machst dann einen neuen Branch für etwas, wovon Du nicht weißt, ob's eine gute Idee ist (`dumbidea`-Branch). Dein Commit-Verlauf wird wie in Abbildung 3-20 aussehen.
 
 <!--Figure 3-20. Your commit history with multiple topic branches.-->
 
@@ -589,7 +589,7 @@ Abbildung 3-20. Dein Commit-Verlauf mit verschiedenen Themen-Branches.
 
 <!--Now, let’s say you decide you like the second solution to your issue best (`iss91v2`); and you showed the `dumbidea` branch to your coworkers, and it turns out to be genius. You can throw away the original `iss91` branch (losing commits C5 and C6) and merge in the other two. Your history then looks like Figure 3-21.-->
 
-Nun, sagen wir Du hast Dich entschieden die zweite Lösung des Fehlers (`iss91v2`) zu bevorzugen, außerdem hast den `dumbidea`-Branch Deinen Mitarbeitern gezeigt und es hat sich herausgestellt das er genial ist. Du kannst also den ursprünglichen `iss91`-Branch (unter Verlust der Commits C5 und C6) wegschmeißen und die anderen Beiden vereinen. Dein Verlauf sieht dann aus wie in Abbildung 3-21.
+Nun, sagen wir, Du hast Dich entschieden, die zweite Lösung des Fehlers (`iss91v2`) zu bevorzugen, außerdem hast den `dumbidea`-Branch Deinen Mitarbeitern gezeigt und es hat sich herausgestellt, dass er genial ist. Du kannst also den ursprünglichen `iss91`-Branch (unter Verlust der Commits C5 und C6) wegwerfen und die anderen beiden vereinen. Dein Verlauf sieht dann aus wie in Abbildung 3-21.
 
 <!--Figure 3-21. Your history after merging in dumbidea and iss91v2.-->
 
@@ -598,22 +598,22 @@ Abbildung 3-21. Dein Verlauf nach Zusammenführung von `dumbidea` und `iss91v2`.
 
 <!--It’s important to remember when you’re doing all this that these branches are completely local. When you’re branching and merging, everything is being done only in your Git repository — no server communication is happening.-->
 
-Es ist wichtig sich daran zu erinnern, dass alle diese Branches nur lokal existieren. Wenn Du Verzweigungen schaffst (branchst) und wieder zusammenführst (mergest), findet dies nur in Deinem Git-Repository statt – es findet keine Server-Kommunikation statt.
+Es ist wichtig, sich daran zu erinnern, dass alle diese Branches nur lokal existieren. Wenn Du Verzweigungen schaffst (branchst) und wieder zusammenführst (mergest), findet dies nur in Deinem Git-Repository statt – es findet keine Server-Kommunikation statt.
 
 <!--## Remote Branches ##-->
 ## Externe Branches ##
 
 <!--Remote branches are references to the state of branches on your remote repositories. They’re local branches that you can’t move; they’re moved automatically whenever you do any network communication. Remote branches act as bookmarks to remind you where the branches on your remote repositories were the last time you connected to them.-->
 
-Externe (Remote) Branches sind Referenzen auf den Zustand der Branches in Deinen externen Repositorys. Es sind lokale Branches die Du nicht verändern kannst, sie werden automatisch verändert wann immer Du eine Netzwerkoperation durchführst. Externe Branches verhalten sich wie Lesezeichen, um Dich daran zu erinnern an welcher Position sich die Branches in Deinen externen Repositories befanden, als Du Dich zuletzt mit ihnen verbunden hattest.
+Externe (Remote) Branches sind Referenzen auf den Zustand der Branches in Deinen externen Repositorys. Es sind lokale Branches, die Du nicht verändern kannst, sie werden automatisch verändert, wann immer Du eine Netzwerkoperation durchführst. Externe Branches verhalten sich wie Lesezeichen, um Dich daran zu erinnern, an welcher Position sich die Branches in Deinen externen Repositorys befanden, als Du Dich zuletzt mit ihnen verbunden hattest.
 
 <!--They take the form `(remote)/(branch)`. For instance, if you wanted to see what the `master` branch on your `origin` remote looked like as of the last time you communicated with it, you would check the `origin/master` branch. If you were working on an issue with a partner and they pushed up an `iss53` branch, you might have your own local `iss53` branch; but the branch on the server would point to the commit at `origin/iss53`.-->
 
-Externe Branches besitzen die Schreibweise `(Repository)/(Branch)`. Wenn Du beispielsweise wissen möchtest wie der `master`-Branch in Deinem `origin`-Repository ausgesehen hat, als Du zuletzt Kontakt mit ihm hattest, dann würdest Du den `origin/master`-Branch überprüfen. Wenn Du mit einem Mitarbeiter an einer Fehlerbehebung gearbeitet hast, und dieser bereits einen `iss53`-Branch hochgeladen hat, besitzt Du möglicherweise Deinen eigenen lokalen `iss53`-Branch. Der Branch auf dem Server würde allerdings auf den Commit von `origin/iss53` zeigen.
+Externe Branches besitzen die Schreibweise `(Repository)/(Branch)`. Wenn Du beispielsweise wissen möchtest, wie der `master`-Branch in Deinem `origin`-Repository ausgesehen hat, als Du zuletzt Kontakt mit ihm hattest, dann würdest Du den `origin/master`-Branch überprüfen. Wenn Du mit einem Mitarbeiter an einer Fehlerbehebung gearbeitet hast und dieser bereits einen `iss53`-Branch hochgeladen hat, besitzt Du möglicherweise Deinen eigenen lokalen `iss53`-Branch. Der Branch auf dem Server würde allerdings auf den Commit von `origin/iss53` zeigen.
 
 <!--This may be a bit confusing, so let’s look at an example. Let’s say you have a Git server on your network at `git.ourcompany.com`. If you clone from this, Git automatically names it `origin` for you, pulls down all its data, creates a pointer to where its `master` branch is, and names it `origin/master` locally; and you can’t move it. Git also gives you your own `master` branch starting at the same place as origin’s `master` branch, so you have something to work from (see Figure 3-22).-->
 
-Das kann ein wenig verwirrend sein, lass uns also ein Besipiel betrachten. Nehmen wir an Du hättest in Deinem Netzwerk einen Git-Server mit der Adresse `git.ourcompany.com`. Wenn Du von ihm klonst, nennt Git ihn automatisch `origin` für dich, lädt all seine Daten herunter, erstellt einen Zeiger an die Stelle wo sein `master`-Branch ist und benennt es lokal `origin/master`; und er ist unveränderbar für dich. Git gibt Dir auch einen eigenen `master`-Branch mit der gleichen Ausgangsposition wie origins `master`-Branch, damit Du einen Punkt für den Beginn Deiner Arbeiten hast (siehe Abbildung 3-22).
+Das kann ein wenig verwirrend sein, lass uns also ein Besipiel betrachten. Nehmen wir an Du hättest in Deinem Netzwerk einen Git-Server mit der Adresse `git.ourcompany.com`. Wenn Du von diesem klonst, nennt Git ihn automatisch `origin` für Dich, lädt all seine Daten herunter, erstellt einen Zeiger zur der Stelle, wo sein `master`-Branch ist und benennt es lokal `origin/master`; und er ist unveränderbar für Dich. Git gibt Dir auch einen eigenen `master`-Branch mit der gleichen Ausgangsposition wie origins `master`-Branch, damit Du einen Punkt für den Beginn Deiner Arbeiten hast (siehe Abbildung 3-22).
 
 <!--Figure 3-22. A Git clone gives you your own master branch and origin/master pointing to origin’s master branch.-->
 
@@ -622,7 +622,7 @@ Abbildung 3-22. Ein 'git clone' gibt Dir Deinen eigenen `master`-Branch und `ori
 
 <!--If you do some work on your local master branch, and, in the meantime, someone else pushes to `git.ourcompany.com` and updates its master branch, then your histories move forward differently. Also, as long as you stay out of contact with your origin server, your `origin/master` pointer doesn’t move (see Figure 3-23).-->
 
-Wenn Du ein wenig an Deinem lokalen `master`-Branch arbeitest und unterdessen jemand etwas zu `git.ourcompany.com` herauflädt, verändert er damit dessen `master`-Branch und eure Arbeitsverläufe entwickeln sich unterschiedlich. Indes bewegt sich Dein `origin/master`-Zeiger nicht, solange Du keinen Kontakt mit Deinem `origin`-Server aufnimmst (siehe Abbildung 3-23).
+Wenn Du ein wenig an Deinem lokalen `master`-Branch arbeitest und unterdessen jemand etwas zu `git.ourcompany.com` herauflädt, verändert er damit dessen `master`-Branch und Eure Arbeitsverläufe entwickeln sich unterschiedlich. Indes bewegt sich Dein `origin/master`-Zeiger nicht, solange Du keinen Kontakt mit Deinem `origin`-Server aufnimmst (siehe Abbildung 3-23).
 
 <!--Figure 3-23. Working locally and having someone push to your remote server makes each history move forward differently.-->
 
@@ -631,7 +631,7 @@ Abbildung 3-23. Lokales Arbeiten, während jemand auf Deinen externen Server hoc
 
 <!--To synchronize your work, you run a `git fetch origin` command. This command looks up which server origin is (in this case, it’s `git.ourcompany.com`), fetches any data from it that you don’t yet have, and updates your local database, moving your `origin/master` pointer to its new, more up-to-date position (see Figure 3-24).-->
 
-Um Deine Arbeit abzugleichen, führe ein `git fetch origin`-Kommando aus. Das Kommando schlägt nach welcher Server `orgin` ist (in diesem Fall `git.ourcompany.com`), holt alle Daten die Dir bisher fehlen und aktualisiert Deine lokale Datenbank, indem es Deinen `orgin/master`-Zeiger auf seine neue aktuellere Position bewegt (siehe Abbildung 3-24).
+Um Deine Arbeit abzugleichen, führe ein `git fetch origin`-Kommando aus. Das Kommando schlägt nach, welcher Server `orgin` ist (in diesem Fall `git.ourcompany.com`), holt alle Daten, die Dir bisher fehlen und aktualisiert Deine lokale Datenbank, indem es Deinen `orgin/master`-Zeiger auf seine neue aktuellere Position bewegt (siehe Abbildung 3-24).
 
 <!--Figure 3-24. The git fetch command updates your remote references.-->
 
@@ -640,7 +640,7 @@ Abbildung 3-24. Das `git fetch`-Kommando aktualisiert Deine externen Referenzen.
 
 <!--To demonstrate having multiple remote servers and what remote branches for those remote projects look like, let’s assume you have another internal Git server that is used only for development by one of your sprint teams. This server is at `git.team1.ourcompany.com`. You can add it as a new remote reference to the project you’re currently working on by running the `git remote add` command as we covered in Chapter 2. Name this remote `teamone`, which will be your shortname for that whole URL (see Figure 3-25).-->
 
-Um zu demonstrieren wie Branches auf verschiedenen Remote-Servern aussehen, stellen wir uns vor, dass Du einen weiteren internen Git-Server besitzt, welcher nur von einem Deiner Sprint-Teams zur Entwicklung genutzt wird. Diesen Server erreichen wir unter `git.team1.ourcompany.com`. Du kannst ihn, mit dem Git-Kommando `git remote add` – wie in Kapitel 2 beschrieben, Deinem derzeitigen Arbeitsprojekt als weiteren Quell-Server hinzufügen. Gib dem Remote-Server den Namen `teamone`, welcher nun als Synonym für die ausgeschriebene Internetadresse dient (siehe Abbildung 3-25).
+Um zu demonstrieren, wie Branches auf verschiedenen Remote-Servern aussehen, stellen wir uns vor, dass Du einen weiteren internen Git-Server besitzt, welcher nur von einem Deiner Sprint-Teams zur Entwicklung genutzt wird. Diesen Server erreichen wir unter `git.team1.ourcompany.com`. Du kannst ihn, mit dem Git-Kommando `git remote add` – wie in Kapitel 2 beschrieben, Deinem derzeitigen Arbeitsprojekt als weiteren Quell-Server hinzufügen. Gib dem Remote-Server den Namen `teamone`, welcher nun als Synonym für die ausgeschriebene Internetadresse dient (siehe Abbildung 3-25).
 
 <!--Figure 3-25. Adding another server as a remote.-->
 
@@ -649,7 +649,7 @@ Abbildung 3-25. Einen weiteren Server als Quelle hinzufügen.
 
 <!--Now, you can run `git fetch teamone` to fetch everything the remote `teamone` server has that you don’t have yet. Because that server has a subset of the data your `origin` server has right now, Git fetches no data but sets a remote branch called `teamone/master` to point to the commit that `teamone` has as its `master` branch (see Figure 3-26).-->
 
-Nun kannst Du einfach `git fetch teamone` ausführen um alles vom Server zu holen was Du noch nicht hast. Da der Datenbestand auf dem Teamserver ein Teil der Informationen auf Deinem `origin`-Server ist, holt Git keine Daten, erstellt allerdings einen Remote-Branch namens `teamone/master`, der auf den gleichen Commit wie `teamone`s `master`-Branch zeigt (siehe Abbildung 3-26).
+Nun kannst Du einfach `git fetch teamone` ausführen, um alles vom Server zu holen, was Du noch nicht hast. Da der Datenbestand auf dem Teamserver ein Teil der Informationen auf Deinem `origin`-Server ist, holt Git keine Daten, erstellt allerdings einen Remote-Branch namens `teamone/master`, der auf den gleichen Commit wie `teamone`s `master`-Branch zeigt (siehe Abbildung 3-26).
 
 <!--Figure 3-26. You get a reference to teamone’s master branch position locally.-->
 
@@ -661,7 +661,7 @@ Abbildung 3-26. Du bekommst eine lokale Referenz auf `teamone`s `master`-Branch.
 
 <!--When you want to share a branch with the world, you need to push it up to a remote that you have write access to. Your local branches aren’t automatically synchronized to the remotes you write to — you have to explicitly push the branches you want to share. That way, you can use private branches for work you don’t want to share, and push up only the topic branches you want to collaborate on.-->
 
-Wenn Du einen Branch mit der Welt teilen möchtest, musst Du ihn auf einen externen Server laden, auf dem Du Schreibrechte besitzt. Deine lokalen Zweige werden nicht automatisch mit den Remote-Servern synchronisiert wenn Du etwas änderst – Du musst die zu veröffentlichenden Branches explizit hochladen (pushen). Auf diesem Weg kannst Du an privaten Zweigen arbeiten die Du nicht veröffentlichen möchtest, und nur die Themen-Branches replizieren an denen Du gemeinsam mit anderen entwickeln möchtest.
+Wenn Du einen Branch mit der Welt teilen möchtest, musst Du ihn auf einen externen Server laden, auf dem Du Schreibrechte besitzt. Deine lokalen Zweige werden nicht automatisch mit den Remote-Servern synchronisiert, wenn Du etwas änderst – Du musst die zu veröffentlichenden Branches explizit hochladen (pushen). Auf diesem Weg kannst Du an privaten Zweigen arbeiten, die Du nicht veröffentlichen möchtest, und nur die Themen-Branches replizieren, an denen Du gemeinsam mit anderen entwickeln möchtest.
 
 <!--If you have a branch named `serverfix` that you want to work on with others, you can push it up the same way you pushed your first branch. Run `git push (remote) (branch)`:-->
 
@@ -677,11 +677,11 @@ Wenn Du einen Zweig namens `serverfix` besitzt, an dem Du mit anderen arbeiten m
 
 <!--This is a bit of a shortcut. Git automatically expands the `serverfix` branchname out to `refs/heads/serverfix:refs/heads/serverfix`, which means, “Take my serverfix local branch and push it to update the remote’s serverfix branch.” We’ll go over the `refs/heads/` part in detail in Chapter 9, but you can generally leave it off. You can also do `git push origin serverfix:serverfix`, which does the same thing — it says, “Take my serverfix and make it the remote’s serverfix.” You can use this format to push a local branch into a remote branch that is named differently. If you didn’t want it to be called `serverfix` on the remote, you could instead run `git push origin serverfix:awesomebranch` to push your local `serverfix` branch to the `awesomebranch` branch on the remote project.-->
 
-Hierbei handelt es sich um eine Abkürzung. Git erweitert die `serverfix`-Branchbezeichnung automatisch zu `refs/heads/serverfix:refs/heads/serverfix`, was soviel bedeutet wie “Nimm meinen lokalen `serverfix`-Branch und aktualisiere damit den `serverfix`-Branch auf meinem externen Server”. Wir werden den `refs/heads/`-Teil in Kapitel 9 noch näher beleuchten, Du kannst ihn aber in der Regel weglassen. Du kannst auch `git push origin serverfix:serverfix` ausführen, was das gleiche bewirkt – es bedeutet “Nimm meinen `serverfix` und mach ihn zum externen `serverfix`”. Du kannst dieses Format auch benutzen um einen lokalen Zweig in einen externen Branch mit anderem Namen zu laden. Wenn Du ihn auf dem externen Server nicht `serverfix` nennen möchtest, könntest Du stattdessen `git push origin serverfix:awesomebranch` ausführen um Deinen lokalen `serverfix`-Branch in den `awesomebranch`-Zweig in Deinem externen Projekt zu laden.
+Hierbei handelt es sich um eine Abkürzung. Git erweitert die `serverfix`-Branchbezeichnung automatisch zu `refs/heads/serverfix:refs/heads/serverfix`, was soviel bedeutet wie “Nimm meinen lokalen `serverfix`-Branch und aktualisiere damit den `serverfix`-Branch auf meinem externen Server”. Wir werden den `refs/heads/`-Teil in Kapitel 9 noch näher beleuchten, Du kannst ihn aber in der Regel weglassen. Du kannst auch `git push origin serverfix:serverfix` ausführen, was das Gleiche bewirkt – es bedeutet “Nimm meinen `serverfix` und mach ihn zum externen `serverfix`”. Du kannst dieses Format auch benutzen, um einen lokalen Zweig in einen externen Branch mit anderem Namen zu laden. Wenn Du ihn auf dem externen Server nicht `serverfix` nennen möchtest, könntest Du stattdessen `git push origin serverfix:awesomebranch` ausführen, um Deinen lokalen `serverfix`-Branch in den `awesomebranch`-Zweig in Deinem externen Projekt zu laden.
 
 <!--The next time one of your collaborators fetches from the server, they will get a reference to where the server’s version of `serverfix` is under the remote branch `origin/serverfix`:-->
 
-Das nächste Mal wenn einer Deiner Mitarbeiter den aktuellen Status des Git-Projektes vom Server abruft, wird er eine Referenz, auf den externen Branch `origin/serverfix`, unter dem Namen `serverfix` erhalten:
+Das nächste Mal, wenn einer Deiner Mitarbeiter den aktuellen Status des Git-Projektes vom Server abruft, wird er eine Referenz auf den externen Branch `origin/serverfix` unter dem Namen `serverfix` erhalten:
 
 	$ git fetch origin
 	remote: Counting objects: 20, done.
@@ -693,11 +693,11 @@ Das nächste Mal wenn einer Deiner Mitarbeiter den aktuellen Status des Git-Proj
 
 <!--It’s important to note that when you do a fetch that brings down new remote branches, you don’t automatically have local, editable copies of them. In other words, in this case, you don’t have a new `serverfix` branch — you only have an `origin/serverfix` pointer that you can’t modify.-->
 
-Es ist wichtig festzuhalten, dass Du mit Abrufen eines neuen externen Branches nicht automatisch eine lokale, bearbeitbare Kopie derselben erhältst. Mit anderen Worten, in diesem Fall bekommst Du keinen neuen `serverfix`-Branch – sondern nur einen `origin/serverfix`-Zeiger den Du nicht verändern kannst.
+Es ist wichtig festzuhalten, dass Du mit Abrufen eines neuen externen Branches nicht automatisch eine lokale, bearbeitbare Kopie desselben erhältst. Mit anderen Worten, in diesem Fall bekommst Du keinen neuen `serverfix`-Branch – sondern nur einen `origin/serverfix`-Zeiger, den Du nicht verändern kannst.
 
 <!--To merge this work into your current working branch, you can run `git merge origin/serverfix`. If you want your own `serverfix` branch that you can work on, you can base it off your remote branch:-->
 
-Um diese referenzierte Arbeit mit Deinem derzeitigen Arbeitsbranch zusammenzuführen kannst Du `git merge origin/serverfix` ausführen. Wenn Du allerdings Deine eigene Arbeitskopie des `serverfix`-Branches erstellen möchtest, dann kannst Du diesen auf Grundlage des externen Zweiges erstellen:
+Um diese referenzierte Arbeit mit Deinem derzeitigen Arbeitsbranch zusammenzuführen, kannst Du `git merge origin/serverfix` ausführen. Wenn Du allerdings Deine eigene Arbeitskopie des `serverfix`-Branches erstellen möchtest, dann kannst Du diesen auf Grundlage des externen Zweiges erstellen:
 
 	$ git checkout -b serverfix origin/serverfix
 	Branch serverfix set up to track remote branch refs/remotes/origin/serverfix.
@@ -712,11 +712,11 @@ Dies erstellt Dir einen lokalen bearbeitbaren Branch mit der Grundlage des `orig
 
 <!--Checking out a local branch from a remote branch automatically creates what is called a _tracking branch_. Tracking branches are local branches that have a direct relationship to a remote branch. If you’re on a tracking branch and type `git push`, Git automatically knows which server and branch to push to. Also, running `git pull` while on one of these branches fetches all the remote references and then automatically merges in the corresponding remote branch.-->
 
-Das Auschecken eines lokalen Branches von einem Remote-Branch erzeugt automatisch einen sogenannten _Tracking-Branch_. Tracking Branches sind lokale Branches mit einer direkten Beziehung zu dem Remote-Zweig. Wenn Du Dich in einem Tracking-Branch befindest und `git push` eingibst, weiß Git automatisch zu welchem Server und Repository es pushen soll. Ebenso führt `git pull` in einem dieser Branches dazu, dass alle entfernten Referenzen gefetched und automatisch in den Zweig gemerged werden.
+Das Auschecken eines lokalen Branches von einem Remote-Branch erzeugt automatisch einen sogenannten _Tracking-Branch_. Tracking Branches sind lokale Branches mit einer direkten Beziehung zu dem Remote-Zweig. Wenn Du Dich in einem Tracking-Branch befindest und `git push` eingibst, weiß Git automatisch, zu welchem Server und Repository es pushen soll. Ebenso führt `git pull` in einem dieser Branches dazu, dass alle entfernten Referenzen gefetched und automatisch in den Zweig gemerged werden.
 
 <!--When you clone a repository, it generally automatically creates a `master` branch that tracks `origin/master`. That’s why `git push` and `git pull` work out of the box with no other arguments. However, you can set up other tracking branches if you wish — ones that don’t track branches on `origin` and don’t track the `master` branch. The simple case is the example you just saw, running `git checkout -b [branch] [remotename]/[branch]`. If you have Git version 1.6.2 or later, you can also use the `-\-track` shorthand:-->
 
-Wenn Du ein Repository klonst, wird automatisch ein `master`-Branch erzeugt, welcher `origin/master` verfolgt. Deshalb können `git push` und `git pull` ohne weitere Argumente aufgerufen werden. Du kannst natürlich auch eigene Tracking-Branches erzeugen – welche die nicht Zweige auf `origin` und dessen `master`-Branch verfolgen. Der einfachste Fall ist das bereits gesehene Beispiel in welchem Du `git checkout -b [branch] [remotename]/[branch]` ausführst. Mit der Git-Version 1.6.2 oder später kannst Du auch die `--track`-Kurzvariante nutzen:
+Wenn Du ein Repository klonst, wird automatisch ein `master`-Branch erzeugt, welcher `origin/master` verfolgt. Deshalb können `git push` und `git pull` ohne weitere Argumente aufgerufen werden. Du kannst natürlich auch eigene Tracking-Branches erzeugen – welche die nicht Zweige auf `origin` und dessen `master`-Branch verfolgen. Der einfachste Fall ist das bereits gesehene Beispiel, in welchem Du `git checkout -b [branch] [remotename]/[branch]` ausführst. Mit der Git-Version 1.6.2 oder später kannst Du auch die `--track`-Kurzvariante nutzen:
 
 	$ git checkout --track origin/serverfix
 	Branch serverfix set up to track remote branch serverfix from origin.
@@ -747,14 +747,14 @@ Stellen wir uns vor, Du bist fertig mit Deinem Remote-Branch – sagen wir Deine
 
 <!--Boom. No more branch on your server. You may want to dog-ear this page, because you’ll need that command, and you’ll likely forget the syntax. A way to remember this command is by recalling the `git push [remotename] [localbranch]:[remotebranch]` syntax that we went over a bit earlier. If you leave off the `[localbranch]` portion, then you’re basically saying, “Take nothing on my side and make it be `[remotebranch]`.”-->
 
-Boom. Kein Zweig mehr auf Deinem Server. Du möchtest Dir diese Seite vielleicht markieren, weil Du dieses Kommando noch benötigen wirst und man leicht dessen Syntax vergisst. Ein Weg sich an dieses Kommando zu erinnern führt über die `git push [remotename] [localbranch]:[remotebranch]`-Snytax, welche wir bereits behandelt haben. Wenn Du den `[localbranch]`-Teil weglässt, dann sagst Du einfach „Nimm nichts von meiner Seite und mach es zu `[remotebranch]`“.
+Boom. Kein Zweig mehr auf Deinem Server. Du möchtest Dir diese Seite vielleicht markieren, weil Du dieses Kommando noch benötigen wirst und man leicht dessen Syntax vergisst. Ein Weg, sich an dieses Kommando zu erinnern, führt über die `git push [remotename] [localbranch]:[remotebranch]`-Snytax, welche wir bereits behandelt haben. Wenn Du den `[localbranch]`-Teil weglässt, dann sagst Du einfach „Nimm nichts von meiner Seite und mach es zu `[remotebranch]`“.
 
 <!--## Rebasing ##-->
 ## Rebasing ##
 
 <!--In Git, there are two main ways to integrate changes from one branch into another: the `merge` and the `rebase`. In this section you’ll learn what rebasing is, how to do it, why it’s a pretty amazing tool, and in what cases you won’t want to use it.-->
 
-Es gibt in Git zwei Wege um Änderungen von einem Branch in einen anderen zu überführen: das `merge` und das `rebase`-Kommando. In diesem Abschnitt wirst Du kennenlernen was Rebasing ist, wie Du es anwendest, warum es ein verdammt abgefahrenes Werkzeug ist und wann Du es lieber nicht einsetzen möchtest.
+Es gibt in Git zwei Wege, um Änderungen von einem Branch in einen anderen zu überführen: das `merge` und das `rebase`-Kommando. In diesem Abschnitt wirst Du kennenlernen, was Rebasing ist, wie Du es anwendest, warum es ein verdammt abgefahrenes Werkzeug ist und wann Du es lieber nicht einsetzen möchtest.
 
 <!--### The Basic Rebase ###-->
 ### Der einfache Rebase ###
@@ -770,7 +770,7 @@ Abbildung 3-27. Deine initiale Commit-Historie zum Zeitpunkt der Aufteilung.
 
 <!--The easiest way to integrate the branches, as we’ve already covered, is the `merge` command. It performs a three-way merge between the two latest branch snapshots (C3 and C4) and the most recent common ancestor of the two (C2), creating a new snapshot (and commit), as shown in Figure 3-28.-->
 
-Der einfachste Weg um Zweige zusammenzuführen ist, wie bereits behandelt, das `merge`-Kommando. Es produziert einen Drei-Wege-Merge zwischen den beiden letzten Branch-Zuständen (C3 und C4) und ihrem wahrscheinlichsten Vorgänger (C2). Es produziert seinerseits einen Schnappschuss des Projektes (und einen Commit), wie in Abbildung 3-28 dargestellt.
+Der einfachste Weg, um Zweige zusammenzuführen, ist, wie bereits behandelt, das `merge`-Kommando. Es produziert einen Drei-Wege-Merge zwischen den beiden letzten Branch-Zuständen (C3 und C4) und ihrem wahrscheinlichsten Vorgänger (C2). Es produziert seinerseits einen Schnappschuss des Projektes (und einen Commit), wie in Abbildung 3-28 dargestellt.
 
 <!--Figure 3-28. Merging a branch to integrate the diverged work history.-->
 
@@ -779,7 +779,7 @@ Abbildung 3-28. Das Zusammenführen eines Branches um die verschiedenen Arbeitsf
 
 <!--However, there is another way: you can take the patch of the change that was introduced in C3 and reapply it on top of C4. In Git, this is called _rebasing_. With the `rebase` command, you can take all the changes that were committed on one branch and replay them on another one.-->
 
-Wie auch immer, es gibt noch einen anderen Weg: Du kannst den Patch der Änderungen – den wir in C3 eingeführt haben –  über C4 anwenden. Dieses Vorgehen nennt man in Git _rebasing_. Mit dem `rebase`-Kommando kannst Du alle Änderungen die auf einem Branch angewendet wurden auf einen anderen Branch erneut anwenden.
+Wie auch immer, es gibt noch einen anderen Weg: Du kannst den Patch der Änderungen – den wir in C3 eingeführt haben –  über C4 anwenden. Dieses Vorgehen nennt man in Git _rebasing_. Mit dem `rebase`-Kommando kannst Du alle Änderungen, die auf einem Branch angewendet wurden, auf einen anderen Branch erneut anwenden.
 
 <!--In this example, you’d run the following:-->
 
@@ -792,7 +792,7 @@ In unserem Beispiel würdest Du folgendes ausführen:
 
 <!--It works by going to the common ancestor of the two branches (the one you’re on and the one you’re rebasing onto), getting the diff introduced by each commit of the branch you’re on, saving those diffs to temporary files, resetting the current branch to the same commit as the branch you are rebasing onto, and finally applying each change in turn. Figure 3-29 illustrates this process.-->
 
-Dies funktioniert, indem Git zu dem gemeinsamen/allgemeinen Vorfahren [gemeinsamer Vorfahr oder der Ursprung der beiden Branches?] der beiden Branches (des Zweiges auf dem Du arbeitest und des Zweiges auf den Du _rebasen_ möchtest) geht, die Differenzen jedes Commits des aktuellen Branches ermittelt und temporär in einer Datei ablegt. Danach wird der aktuelle Branch auf den Schnittpunkt der beiden Zweige zurückgesetzt und alle zwischengespeicherte Commits nacheinander auf den Zielbranch angewendet. Die Abbildung 3-29 bildet diesen Prozess ab.
+Dies funktioniert, indem Git zu dem gemeinsamen Vorfahren [gemeinsamer Vorfahr oder der Ursprung der beiden Branches?] der beiden Branches (des Zweiges auf dem Du arbeitest und des Zweiges auf den Du _rebasen_ möchtest) geht, die Differenzen jedes Commits des aktuellen Branches ermittelt und temporär in einer Datei ablegt. Danach wird der aktuelle Branch auf den Schnittpunkt der beiden Zweige zurückgesetzt und alle zwischengespeicherten Commits nacheinander auf den Zielbranch angewendet. Die Abbildung 3-29 bildet diesen Prozess ab.
 
 <!--Figure 3-29. Rebasing the change introduced in C3 onto C4.-->
 
@@ -810,22 +810,22 @@ Abbildung 3-30. Fast-forward des Master-Branches.
 
 <!--Now, the snapshot pointed to by C3' is exactly the same as the one that was pointed to by C5 in the merge example. There is no difference in the end product of the integration, but rebasing makes for a cleaner history. If you examine the log of a rebased branch, it looks like a linear history: it appears that all the work happened in series, even when it originally happened in parallel.-->
 
-Nun ist der Schnappschuss, auf den C3' zeigt, exakt der gleiche, wie der auf den C5 in dem Merge-Beispiel gezeigt hat. Bei dieser Zusammenführung entsteht kein unterschiedliches Produkt, durch Rebasing ensteht allerdings ein sauberer Verlauf. Bei genauerer Betrachtung der Historie entpuppt sich der Rebased-Branch als linearer Verlauf – es scheint als sei die ganze Arbeit in einer Serie entstanden, auch wenn sie in Wirklichkeit parallel stattfand.
+Nun ist der Schnappschuss, auf den C3' zeigt, exakt der gleiche, wie der auf den C5 in dem Merge-Beispiel gezeigt hat. Bei dieser Zusammenführung entsteht kein unterschiedliches Produkt, durch Rebasing ensteht allerdings ein sauberer Verlauf. Bei genauerer Betrachtung der Historie entpuppt sich der Rebased-Branch als linearer Verlauf – es scheint, als sei die ganze Arbeit in einer Serie entstanden, auch wenn sie in Wirklichkeit parallel stattfand.
 
 <!--Often, you’ll do this to make sure your commits apply cleanly on a remote branch — perhaps in a project to which you’re trying to contribute but that you don’t maintain. In this case, you’d do your work in a branch and then rebase your work onto `origin/master` when you were ready to submit your patches to the main project. That way, the maintainer doesn’t have to do any integration work — just a fast-forward or a clean apply.-->
 
-Du wirst das häufig anwenden um sicherzustellen, dass sich Deine Commits sauber in einen Remote-Branch integrieren – möglicherweise in einem Projekt bei dem Du Dich beteiligen möchtest, Du jedoch nicht der Verantwortliche bist. In diesem Fall würdest Du Deine Arbeiten in einem eigenen Branch erledigen und im Anschluss Deine Änderungen auf `origin/master` rebasen. Dann hätte der Verantwortliche nämliche keinen Aufwand mit der Integration – nur einen Fast-Forward oder eine saubere Integration (= Rebase?).
+Du wirst das häufig anwenden um sicherzustellen, dass sich Deine Commits sauber in einen Remote-Branch integrieren – möglicherweise in einem Projekt, bei dem Du Dich beteiligen möchtest, Du jedoch nicht der Verantwortliche bist. In diesem Fall würdest Du Deine Arbeiten in einem eigenen Branch erledigen und im Anschluss Deine Änderungen auf `origin/master` rebasen. Dann hätte der Verantwortliche nämlich keinen Aufwand mit der Integration – nur einen Fast-Forward oder eine saubere Integration (= Rebase?).
 
 <!--Note that the snapshot pointed to by the final commit you end up with, whether it’s the last of the rebased commits for a rebase or the final merge commit after a merge, is the same snapshot — it’s only the history that is different. Rebasing replays changes from one line of work onto another in the order they were introduced, whereas merging takes the endpoints and merges them together.-->
 
-Beachte, dass der Schnappschuss nach dem letzten Commit, ob es der letzte der Rebase-Commits nach einem Rebase oder der finale Merge-Commit nach einem Merge ist, exakt gleich ist. Sie unterscheiden sich nur in ihrem Verlauf. Rebasing wiederholt einfach die Änderungen einer Arbeitslinie auf einer anderen, in der Reihenfolge in der sie entstanden sind. Im Gegensatz hierzu nimmt Merging die beiden Endpunkte der Arbeitslinien und führt diese zusammen.
+Beachte, dass der Schnappschuss nach dem letzten Commit, ob es der letzte der Rebase-Commits nach einem Rebase oder der finale Merge-Commit nach einem Merge ist, exakt der gleiche ist. Sie unterscheiden sich nur in ihrem Verlauf. Rebasing wiederholt einfach die Änderungen einer Arbeitslinie auf einer anderen, in der Reihenfolge in der sie entstanden sind. Im Gegensatz hierzu nimmt Merging die beiden Endpunkte der Arbeitslinien und führt diese zusammen.
 
 <!--### More Interesting Rebases ###-->
 ### Mehr interessante Rebases ###
 
 <!--You can also have your rebase replay on something other than the rebase branch. Take a history like Figure 3-31, for example. You branched a topic branch (`server`) to add some server-side functionality to your project, and made a commit. Then, you branched off that to make the client-side changes (`client`) and committed a few times. Finally, you went back to your server branch and did a few more commits.-->
 
-Du kannst Deinen Rebase auch auf einem anderen Branch als dem Rebase-Branch anwenden lassen. Nimm zum Beispiel den Verlauf in Abbildung 3-31. Du hattest einen Themen-Branch (`server`) eröffnet um ein paar serverseitige Funktionalitäten zu Deinem Projekt hinzuzufügen und einen Commit gemacht. Dann hast Du einen weiteren Branch abgezweigt um clientseitige Änderungen (`client`) vorzunehmen und dort ein paarmal committed. Zum Schluss hast Du wieder zu Deinem Server-Branch gewechselt und ein paar weitere Commits gebaut.
+Du kannst Deinen Rebase auch auf einem anderen Branch als dem Rebase-Branch anwenden lassen. Nimm zum Beispiel den Verlauf in Abbildung 3-31. Du hattest einen Themen-Branch (`server`) eröffnet, um ein paar serverseitige Funktionalitäten zu Deinem Projekt hinzuzufügen und einen Commit gemacht. Dann hast Du einen weiteren Branch abgezweigt, um clientseitige Änderungen (`client`) vorzunehmen und dort ein paarmal committed. Zum Schluss hast Du wieder zu Deinem Server-Branch gewechselt und ein paar weitere Commits gebaut.
 
 <!--Figure 3-31. A history with a topic branch off another topic branch.-->
 
@@ -834,13 +834,13 @@ Abbildung 3-31. Ein Verlauf mit einem Themen-Branch basierend auf einem weiteren
 
 <!--Suppose you decide that you want to merge your client-side changes into your mainline for a release, but you want to hold off on the server-side changes until it’s tested further. You can take the changes on client that aren’t on server (C8 and C9) and replay them on your master branch by using the `-\-onto` option of `git rebase`:-->
 
-Stell Dir vor, Du entscheidest Dich Deine clientseitigen Änderungen für einen Release in die Hauptlinie zu mergen, die serverseitigen Änderungen möchtest Du aber noch zurückhalten bis sie besser getestet wurden. Du kannst einfach die Änderungen am Client, die den Server nicht betreffen, (C8 und C9) mit der `--onto`-Option von `git rebase` erneut auf den Master-Branch anwenden:
+Stell Dir vor, Du entscheidest Dich, Deine clientseitigen Änderungen für einen Release in die Hauptlinie zu mergen, die serverseitigen Änderungen möchtest Du aber noch zurückhalten, bis sie besser getestet wurden. Du kannst einfach die Änderungen am Client, die den Server nicht betreffen, (C8 und C9) mit der `--onto`-Option von `git rebase` erneut auf den Master-Branch anwenden:
 
 	$ git rebase --onto master server client
 
 <!--This basically says, “Check out the client branch, figure out the patches from the common ancestor of the `client` and `server` branches, and then replay them onto `master`.” It’s a bit complex; but the result, shown in Figure 3-32, is pretty cool.-->
 
-Das bedeutet einfach “Checke den Client-Branch aus, finde die Patches heraus die auf dem gemeinsamen Vorfahr der `client`- und `server`-Branches basieren und wende sie erneut auf dem `master`-Branch an.” Das ist ein bisschen komplex, aber das Ergebnis – wie in Abbildung 3-32 – ist richtig cool.
+Das bedeutet einfach, “Checke den Client-Branch aus, finde die Patches heraus, die auf dem gemeinsamen Vorfahr der `client`- und `server`-Branches basieren und wende sie erneut auf dem `master`-Branch an.” Das ist ein bisschen komplex, aber das Ergebnis – wie in Abbildung 3-32 – ist richtig cool.
 
 <!--Figure 3-32. Rebasing a topic branch off another topic branch.-->
 
@@ -861,7 +861,7 @@ Abbildung 3-33. Fast-forwarding Deines Master-Branches um die Client-Branch-Änd
 
 <!--Let’s say you decide to pull in your server branch as well. You can rebase the server branch onto the master branch without having to check it out first by running `git rebase [basebranch] [topicbranch]` — which checks out the topic branch (in this case, `server`) for you and replays it onto the base branch (`master`):-->
 
-Lass uns annehmen, Du entscheidest Dich Deinen Server-Branch ebenfalls einzupflegen. Du kannst den Server-Branch auf den Master-Branch rebasen ohne diesen vorher auschecken zu müssen, indem Du das Kommando `git rebase [Basis-Branch] [Themen-Branch]` ausführst. Es macht für Dich den Checkout des Themen-Branches (in diesem Fall `server`) und wiederholt ihn auf dem Basis-Branch (`master`):
+Lass uns annehmen, Du entscheidest Dich, Deinen Server-Branch ebenfalls einzupflegen. Du kannst den Server-Branch auf den Master-Branch rebasen, ohne diesen vorher auschecken zu müssen, indem Du das Kommando `git rebase [Basis-Branch] [Themen-Branch]` ausführst. Es macht für Dich den Checkout des Themen-Branches (in diesem Fall `server`) und wiederholt ihn auf dem Basis-Branch (`master`):
 
 	$ git rebase master server
 
@@ -906,7 +906,7 @@ Ahh, aber der ganze Spaß mit dem Rebasing kommt nicht ohne seine Schattenseiten
 
 <!--If you follow that guideline, you’ll be fine. If you don’t, people will hate you, and you’ll be scorned by friends and family.-->
 
-Wenn Du diesem Ratschlag folgst ist alles in Ordnung. Falls nicht, werden die Leute Dich hassen und Du wirst von Deinen Freunden und Deiner Familie verachtet.
+Wenn Du diesem Ratschlag folgst, ist alles in Ordnung. Falls nicht, werden die Leute Dich hassen und Du wirst von Deinen Freunden und Deiner Familie verachtet.
 
 <!--When you rebase stuff, you’re abandoning existing commits and creating new ones that are similar but different. If you push commits somewhere and others pull them down and base work on them, and then you rewrite those commits with `git rebase` and push them up again, your collaborators will have to re-merge their work and things will get messy when you try to pull their work back into yours.-->
 
@@ -914,12 +914,12 @@ Wenn Du Zeug rebased, hebst Du bestehende Commits auf und erstellst stattdessen
 
 <!--Let’s look at an example of how rebasing work that you’ve made public can cause problems. Suppose you clone from a central server and then do some work off that. Your commit history looks like Figure 3-36.-->
 
-Lass uns mal ein Beispiel betrachten wie das Rebasen veröffentlichter Arbeit Probleme verursachen kann. Angenommen Du klonst von einem zentralen Server und werkelst ein bisschen daran rum. Dein Commit-Verlauf sieht wie in Abbildung 3-36 aus.
+Lass uns mal ein Beispiel betrachten, wie das Rebasen veröffentlichter Arbeit Probleme verursachen kann. Angenommen, Du klonst von einem zentralen Server und werkelst ein bisschen daran rum. Dein Commit-Verlauf sieht wie in Abbildung 3-36 aus.
 
 <!--Figure 3-36. Clone a repository, and base some work on it.-->
 
 Insert 18333fig0336.png
-Abbildung 3-36. Klon ein Repository und baue etwas darauf auf.
+Abbildung 3-36. Klone ein Repository und baue etwas darauf auf.
 
 <!--Now, someone else does more work that includes a merge, and pushes that work to the central server. You fetch them and merge the new remote branch into your work, making your history look something like Figure 3-37.-->
 
@@ -932,12 +932,12 @@ Abbildung 3-37. Fetche mehrere Commits und merge sie in Deine Arbeit.
 
 <!--Next, the person who pushed the merged work decides to go back and rebase their work instead; they do a `git push -\-force` to overwrite the history on the server. You then fetch from that server, bringing down the new commits.-->
 
-Als nächstes entscheidet sich die Person, welche den Merge hochgeladen hat diesen rückgängig zu machen und stattdessen die Commits zu rebasen. Sie macht einen `git push --force` um den Verlauf auf dem Server zu überschreiben. Du lädst Dir das Ganze dann mit den neuen Commits herunter.
+Als nächstes entscheidet sich die Person, welche den Merge hochgeladen hat, diesen rückgängig zu machen und stattdessen die Commits zu rebasen. Sie macht einen `git push --force`, um den Verlauf auf dem Server zu überschreiben. Du lädst Dir das Ganze dann mit den neuen Commits herunter.
 
 <!--Figure 3-38. Someone pushes rebased commits, abandoning commits you’ve based your work on.-->
 
 Insert 18333fig0338.png
-Abbildung 3-38. Jemand pusht rebased Commits und verwirft damit Commitd auf denen Deine Arbeit basiert.
+Abbildung 3-38. Jemand pusht rebased Commits und verwirft damit Commits, auf denen Deine Arbeit basiert.
 
 <!--At this point, you have to merge this work in again, even though you’ve already done so. Rebasing changes the SHA-1 hashes of these commits so to Git they look like new commits, when in fact you already have the C4 work in your history (see Figure 3-39).-->
 
@@ -950,15 +950,15 @@ Abbildung 3-39. Du mergst die gleiche Arbeit nochmals in einen neuen Merge-Commi
 
 <!--You have to merge that work in at some point so you can keep up with the other developer in the future. After you do that, your commit history will contain both the C4 and C4' commits, which have different SHA-1 hashes but introduce the same work and have the same commit message. If you run a `git log` when your history looks like this, you’ll see two commits that have the same author date and message, which will be confusing. Furthermore, if you push this history back up to the server, you’ll reintroduce all those rebased commits to the central server, which can further confuse people.-->
 
-Irgendwann musst Du seine Arbeit einmergen, damit Du auch zukünftig mit dem anderen Entwickler zusammenarbeiten kannst. Danach wird Dein Commit-Verlauf sowohl den C4 als auch den C4'-Commit enthalten, weche zwar verschiedene SHA-1-Hashes besitzen aber die gleichen Änderungen und die gleiche Commit-Beschreibung enthalten. Wenn Du so einen Verlauf mit `git log` betrachtest, wirst Du immer zwei Commits des gleichen Autors, zur gleichen Zeit und mit der gleichen Commit-Nachricht sehen. Was ganz schön verwirrend ist. Wenn Du diesen Verlauf außerdem auf den Server hochlädst, wirst Du dort alle rebasierten Commits einführen, was auch noch andere verwirren kann.
+Irgendwann musst Du seine Arbeit einmergen, damit Du auch zukünftig mit dem anderen Entwickler zusammenarbeiten kannst. Danach wird Dein Commit-Verlauf sowohl den C4 als auch den C4'-Commit enthalten, welche zwar verschiedene SHA-1-Hashes besitzen, aber die gleichen Änderungen und die gleiche Commit-Beschreibung enthalten. Wenn Du so einen Verlauf mit `git log` betrachtest, wirst Du immer zwei Commits des gleichen Autors, zur gleichen Zeit und mit der gleichen Commit-Nachricht sehen. Was ganz schön verwirrend ist. Wenn Du diesen Verlauf außerdem auf den Server hochlädst, wirst Du dort alle rebasierten Commits einführen, was auch noch andere verwirren kann.
 
 <!--If you treat rebasing as a way to clean up and work with commits before you push them, and if you only rebase commits that have never been available publicly, then you’ll be fine. If you rebase commits that have already been pushed publicly, and people may have based work on those commits, then you may be in for some frustrating trouble.-->
 
-Wenn Du rebasing als Weg behandelst um aufzuräumen und mit Commits zu arbeiten, bevor Du sie hochlädst und wenn Du nur Commits rebased, die noch nie publiziert wurden, dann fährst Du goldrichtig. Wenn Du Commits rebased die bereits veröffentlicht wurden und Leute vielleicht schon ihre Arbeit darauf aufgebaut haben, dann bist Du vielleicht für frustrierenden Ärger verantwortlich.
+Wenn Du rebasing als Weg behandelst, um aufzuräumen und mit Commits zu arbeiten, bevor Du sie hochlädst und wenn Du nur Commits rebased, die noch nie publiziert wurden, dann fährst Du goldrichtig. Wenn Du Commits rebased, die bereits veröffentlicht wurden und Leute vielleicht schon ihre Arbeit darauf aufgebaut haben, dann bist Du vielleicht für frustrierenden Ärger verantwortlich.
 
 <!--## Summary ##-->
 ## Zusammenfassung ##
 
 <!--We’ve covered basic branching and merging in Git. You should feel comfortable creating and switching to new branches, switching between branches and merging local branches together.  You should also be able to share your branches by pushing them to a shared server, working with others on shared branches and rebasing your branches before they are shared.-->
 
-Wir haben einfaches Branching und Merging mit Git behandelt. Du solltest nun gut damit zurecht kommen Branches zu erstellen, zwischen Branches zu wechseln und lokale Branches mit einem Merge zusammenzuführen. Ausserdem solltest Du in der Lage sein Deine Branches zu veröffentlichen indem Du sie auf einen zentralen Server lädst, mit anderen auf öffentlichen Branches zusammenzuarbeiten und Deine Branches zu rebasen bevor sie veröffentlicht werden.
+Wir haben einfaches Branching und Merging mit Git behandelt. Du solltest nun gut damit zurecht kommen, Branches zu erstellen, zwischen Branches zu wechseln und lokale Branches mit einem Merge zusammenzuführen. Außerdem solltest Du in der Lage sein, Deine Branches zu veröffentlichen, indem Du sie auf einen zentralen Server lädst, mit anderen auf öffentlichen Branches zusammenzuarbeiten und Deine Branches zu rebasen, bevor sie veröffentlicht werden.

From f0df512e7d71240cb72858c5cc84e78e9fc7135f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?J=C3=B6rg=20Ewald?=
 <Sternenstauner@users.noreply.github.com>
Date: Mon, 2 Mar 2015 15:52:47 +0100
Subject: [PATCH 674/690] Update 01-chapter3.markdown

Made some corrections (line 338 - three way merge and line 795 - rebase), furthermore grammar (punctuation) and a bit spelling.
---
 de/03-git-branching/01-chapter3.markdown | 128 +++++++++++------------
 1 file changed, 64 insertions(+), 64 deletions(-)

diff --git a/de/03-git-branching/01-chapter3.markdown b/de/03-git-branching/01-chapter3.markdown
index fdcf42280..6ff4380eb 100644
--- a/de/03-git-branching/01-chapter3.markdown
+++ b/de/03-git-branching/01-chapter3.markdown
@@ -3,18 +3,18 @@
 
 <!--Nearly every VCS has some form of branching support. Branching means you diverge from the main line of development and continue to do work without messing with that main line. In many VCS tools, this is a somewhat expensive process, often requiring you to create a new copy of your source code directory, which can take a long time for large projects.-->
 
-Nahezu jedes VCS unterstützt eine Form von Branching. Branching bedeutet, dass Du von der Hauptentwicklungslinie abzweigst und unabhängig von dem Hauptzweig weiterarbeitest. Bei vielen VCS ist das ein umständlicher und komplizierter Prozess. Nicht selten ist es notwendig, dass eine Kopie des kompletten Arbeitsverzeichnisses erstellt werden muss, was bei großen Projekten eine ganze Weile dauern kann.
+Nahezu jedes VCS unterstützt eine Form von Branching. Branching bedeutet, dass Du von der Hauptentwicklungslinie abzweigst und unabhängig vom Hauptzweig weiterarbeitest. Bei vielen VCS ist das ein ziemlch aufwendiger Prozess, welcher häufig erfordert, eine Kopie des kompletten Arbeitsverzeichnisses zu erstellen, was bei großen Projekten eine ganze Weile dauern kann.
 
 <!--Some people refer to the branching model in Git as its “killer feature”  , and it certainly sets Git apart in the VCS community. Why is it so special? The way Git branches is incredibly lightweight, making branching operations nearly instantaneous and switching back and forth between branches generally just as fast. Unlike many other VCSs, Git encourages a workflow that branches and merges often, even multiple times in a day. Understanding and mastering this feature gives you a powerful and unique tool and can literally change the way that you develop.-->
 
-Manche Leute bezeichnen Gits Branching-Modell als dessen „Killer-Feature“, was Git zweifellos von dem Rest der VCS-Community abhebt. Aber was macht es so besonders? Die Art und Weise, wie Git Branches behandelt, ist unglaublich leichtfüßig. Dies führt dazu, dass nahezu jede Branch-Operation verzögerungsfrei ausgeführt wird. Auch das Hin- und Herschalten zwischen einzelnen Entwicklungszweigen läuft genauso schnell ab. Im Gegensatz zu anderen VCS ermutigt Git zu einer Arbeitsweise mit häufigem Branching und Merging – oft mehrmals am Tag. Die Branching-Funktion zu verstehen und zu meistern gibt Dir ein mächtiges und einmaliges Werkzeug an die Hand und kann Deine Art zu entwickeln buchstäblich verändern.
+Manche Leute bezeichnen Gits Branching-Modell als dessen „Killer-Feature“, was Git zweifellos von dem Rest der VCS-Community abhebt. Was ist das Besondere daran? Die Art und Weise, wie Git Branches behandelt, ist unglaublich leichtgewichtig, wodurch Branch-Operationen nahezu verzögerungsfrei ausgeführt werden und auch das Hin- und Herschalten zwischen einzelnen Entwicklungszweigen im allgemeinen genauso schnell abläuft. Im Gegensatz zu anderen VCS ermutigt Git zu einer Arbeitsweise mit häufigem Branching und Merging – oft mehrmals am Tag. Wenn Du diese Funktion vertstehst und beherrschst, besitzt Du ein mächtiges und einmaliges Werkzeug, welches Deine Art zu entwickeln buchstäblich verändern.
 
 <!--## What a Branch Is ##-->
 ## Was ist ein Branch? ##
 
 <!--To really understand the way Git does branching, we need to take a step back and examine how Git stores its data. As you may remember from Chapter 1, Git doesn’t store data as a series of changesets or deltas, but instead as a series of snapshots.-->
 
-Um wirklich zu verstehen wie Git Branching durchführt, müssen wir einen Schritt zurück gehen und untersuchen, wie Git die Daten speichert. Wie Du Dich vielleicht noch an Kapitel 1 erinnerst, speichert Git seine Daten nicht als Serie von Änderungen oder Unterschieden, sondern als Serie von Schnappschüssen.
+Um wirklich zu verstehen, wie Git Branching durchführt, müssen wir einen Schritt zurück gehen und untersuchen, wie Git die Daten speichert. Wie Du Dich vielleicht noch an Kapitel 1 erinnerst, speichert Git seine Daten nicht als Serie von Änderungen oder Unterschieden, sondern als Serie von Schnappschüssen.
 
 <!--When you commit in Git, Git stores a commit object that contains a pointer to the snapshot of the content you staged, the author and message metadata, and zero or more pointers to the commit or commits that were the direct parents of this commit: zero parents for the first commit, one parent for a normal commit, and multiple parents for a commit that results from a merge of two or more branches.-->
 
@@ -29,11 +29,11 @@ Um das zu verdeutlichen, lass uns annehmen, Du hast ein Verzeichnis mit drei Dat
 
 <!--Running `git commit` checksums all project directories and stores them as `tree` objects in the Git repository. Git then creates a `commit` object that has the metadata and a pointer to the root project `tree` object so it can re-create that snapshot when needed.-->
 
-Wenn Du einen Commit mit dem Kommando `git commit` erstellst, erzeugt Git für jedes Projektverzeichnis eine Prüfsumme und speichert diese als sogenanntes `tree`-Objekt im Git Repository. Git erzeugt dann ein Commit Objekt, das die Metadaten und den Zeiger zum `tree`-Objekt des Wurzelverzeichnis enthält, um bei Bedarf den Snapshot erneut erzeugen zu können.
+Wenn Du einen Commit mit der Anweisung `git commit` erstellst, erzeugt Git für jedes Projektverzeichnis eine Prüfsumme und speichert diese als sogenanntes `tree`-Objekt im Git Repository. Git erzeugt dann ein Commit Objekt, das die Metadaten und den Zeiger zum `tree`-Objekt des Wurzelverzeichnis enthält, um bei Bedarf den Snapshot erneut erzeugen zu können.
 
 <!--Your Git repository now contains five objects: one blob for the contents of each of your three files, one tree that lists the contents of the directory and specifies which file names are stored as which blobs, and one commit with the pointer to that root tree and all the commit metadata. Conceptually, the data in your Git repository looks something like Figure 3-1.-->
 
-Dein Git-Repository enthält nun fünf Objekte: einen Blob für den Inhalt jeder der drei Dateien, einen Baum, der den Inhalt des Verzeichnisses auflistet und spezifiziert, welcher Dateiname zu welchem Blob gehört, sowie einen Zeiger, der auf die Wurzel des Projektbaumes und die Metadaten des Commits verweist. Prinzipiell sehen Deine Daten im Git Repository wie in Abbildung 3-1 aus.
+Dein Git-Repository enthält nun fünf Objekte: einen Blob für den Inhalt von jeder der drei Dateien, einen Baum, der den Inhalt des Verzeichnisses auflistet und spezifiziert, welcher Dateiname zu welchem Blob gehört, sowie einen Zeiger, der auf die Wurzel des Projektbaumes und die Metadaten des Commits verweist. Prinzipiell sehen Deine Daten im Git Repository wie in Abbildung 3-1 aus.
 
 <!--Figure 3-1. Single commit repository data.-->
 
@@ -60,7 +60,7 @@ Abbildung 3-3. Branch, der auf einen Commit in der Historie zeigt.
 
 <!--What happens if you create a new branch? Well, doing so creates a new pointer for you to move around. Let’s say you create a new branch called testing. You do this with the `git branch` command:-->
 
-Was passiert, wenn Du einen neuen Branch erstellst? Nun, zunächst wird ein neuer Zeiger erstellt. Sagen wir, Du erstellst einen neuen Branch mit dem Namen `testing`. Das machst Du mit dem `git branch` Befehl:
+Was passiert, wenn Du einen neuen Branch erstellst? Nun, zunächst wird ein neuer Zeiger erstellt. Sagen wir, Du erstellst einen neuen Branch mit dem Namen `testing`. Das machst Du mit der Anweisung `git branch`:
 
 	$ git branch testing
 
@@ -75,7 +75,7 @@ Abbildung 3-4. Mehrere Branches zeigen in den Commit-Verlauf
 
 <!--How does Git know what branch you’re currently on? It keeps a special pointer called HEAD. Note that this is a lot different than the concept of HEAD in other VCSs you may be used to, such as Subversion or CVS. In Git, this is a pointer to the local branch you’re currently on. In this case, you’re still on master. The git branch command only created a new branch — it didn’t switch to that branch (see Figure 3-5).-->
 
-Woher weiß Git, welchen Branch Du momentan verwendest? Dafür gibt es einen speziellen Zeiger mit dem Namen HEAD. Berücksichtige, dass dieses Konzept sich grundsätzlich von anderen HEAD-Konzepten anderer VCS, wie Subversion oder CVS, unterscheidet. Bei Git handelt es sich bei HEAD um einen Zeiger, der auf Deinen aktuellen lokalen Branch zeigt. In dem Fall bist Du aber immer noch auf dem `master`-Branch. Das `git branch` Kommando hat nur einen neuen Branch erstellt, aber nicht zu diesem gewechselt (siehe Abbildung 3-5).
+Woher weiß Git, welchen Branch Du momentan verwendest? Dafür gibt es einen speziellen Zeiger mit dem Namen HEAD. Berücksichtige, dass dieses Konzept sich grundsätzlich von anderen HEAD-Konzepten anderer VCS, wie Subversion oder CVS, unterscheidet. Bei Git handelt es sich bei HEAD um einen Zeiger, der auf Deinen aktuellen lokalen Branch zeigt. In dem Fall bist Du aber immer noch auf dem `master`-Branch. Die Anweisung `git branch` hat nur einen neuen Branch erstellt, aber nicht zu diesem gewechselt (siehe Abbildung 3-5).
 
 <!--Figure 3-5. HEAD file pointing to the branch you’re on.-->
 
@@ -84,7 +84,7 @@ Abbildung 3-5. Der HEAD-Zeiger verweist auf Deinen aktuellen Branch.
 
 <!--To switch to an existing branch, you run the `git checkout` command. Let’s switch to the new testing branch:-->
 
-Um zu einem anderen Branch zu wechseln, benutze das Kommando `git checkout`. Lass uns nun zu unserem neuen Branch `testing` wechseln:
+Um zu einem anderen Branch zu wechseln, benutze die Anweisung `git checkout`. Lass uns nun zu unserem neuen Branch `testing` wechseln:
 
 	$ git checkout testing
 
@@ -115,7 +115,7 @@ Abbildung 3-7. Der HEAD-Zeiger schreitet mit jedem weiteren Commit voran.
 
 <!--This is interesting, because now your testing branch has moved forward, but your `master` branch still points to the commit you were on when you ran `git checkout` to switch branches. Let’s switch back to the `master` branch:-->
 
-Das ist interessant, denn Dein Branch `testing` hat sich jetzt voranbewegt und Dein `master`-Branch zeigt immer noch auf seinen letzten Commit. Den Commit, den Du zuletzt bearbeitet hattest, bevor Du mit `git checkout` den aktuellen Zweig gewechselt hast. Lass uns zurück zu dem `master`-Branch wechseln:
+Das ist interessant, denn Dein Branch `testing` hat sich jetzt voranbewegt, während Dein `master`-Branch immer noch auf den Commit zeigt, welchen Du bearbeitet hast, bevor Du mit `git checkout` den aktuellen Zweig gewechselt hast. Lass uns zurück zu dem `master`-Branch wechseln:
 
 	$ git checkout master
 
@@ -130,7 +130,7 @@ Abbildung 3-8. HEAD zeigt nach einem Checkout auf einen anderen Branch.
 
 <!--That command did two things. It moved the HEAD pointer back to point to the `master` branch, and it reverted the files in your working directory back to the snapshot that `master` points to. This also means the changes you make from this point forward will diverge from an older version of the project. It essentially rewinds the work you’ve done in your testing branch temporarily so you can go in a different direction.-->
 
-Das Kommando hat zwei Dinge veranlasst. Zum einen bewegt es den HEAD-Zeiger zurück zum `master`-Branch, zum anderen setzt es alle Dateien im Arbeitsverzeichnis auf den Bearbeitungsstand des letzten Commits in diesem Zweig zurück. Das bedeutet aber auch, dass nun alle Änderungen am Projekt vollkommen unabhängig von älteren Projektversionen erfolgen. Kurz gesagt, werden alle Änderungen aus dem `testing`-Zweig vorübergehend rückgängig gemacht und Du hast die Möglichkeit, einen vollkommen neuen Weg in der Entwicklung einzuschlagen.
+Diese Anweisung hat zwei Dinge veranlasst. Zum einen bewegt es den HEAD-Zeiger zurück zum `master`-Branch, zum anderen setzt es alle Dateien im Arbeitsverzeichnis auf den Bearbeitungsstand des letzten Commits in diesem Zweig zurück. Das bedeutet aber auch, dass nun alle Änderungen am Projekt vollkommen unabhängig von älteren Projektversionen erfolgen. Kurz gesagt, werden alle Änderungen aus dem `testing`-Zweig vorübergehend rückgängig gemacht und Du hast die Möglichkeit, einen vollkommen neuen Weg in der Entwicklung einzuschlagen.
 
 <!--Let’s make a few changes and commit again:-->
 
@@ -141,7 +141,7 @@ Lass uns ein paar Änderungen machen und mit einem Commit festhalten:
 
 <!--Now your project history has diverged (see Figure 3-9). You created and switched to a branch, did some work on it, and then switched back to your main branch and did other work. Both of those changes are isolated in separate branches: you can switch back and forth between the branches and merge them together when you’re ready. And you did all that with simple `branch` and `checkout` commands.-->
 
-Nun verzweigen sich die Projektverläufe (siehe Abbildung 3-9). Du hast einen Branch erstellt und zu ihm gewechselt, hast ein bisschen gearbeitet, bist zu Deinem Haupt-Zweig zurückgekehrt und hast da was ganz anderes gemacht. Beide Arbeiten existieren vollständig unabhängig voneinander in zwei unterschiedlichen Branches. Du kannst beliebig zwischen den beiden Zweigen wechseln und sie zusammenführen, wenn Du meinst, es wäre soweit. Und das alles hast Du mit simplen `branch` und `checkout`-Befehlen vollbracht.
+Nun verzweigen sich die Projektverläufe (siehe Abbildung 3-9). Du hast einen Branch erstellt und zu ihm gewechselt, hast ein bisschen gearbeitet, bist zu Deinem Haupt-Zweig zurückgekehrt und hast da was ganz anderes gemacht. Beide Arbeiten existieren vollständig unabhängig voneinander in zwei unterschiedlichen Branches. Du kannst beliebig zwischen den beiden Zweigen wechseln und sie zusammenführen, wenn Du meinst, es wäre soweit. Und das alles hast Du mit simplen `branch` und `checkout`-Anweisungen vollbracht.
 
 <!--Figure 3-9. The branch histories have diverged.-->
 
@@ -203,7 +203,7 @@ Abbildung 3-10. Eine kurze, einfache Commit-Historie
 
 <!--You’ve decided that you’re going to work on issue #53 in whatever issue-tracking system your company uses. To be clear, Git isn’t tied into any particular issue-tracking system; but because issue #53 is a focused topic that you want to work on, you’ll create a new branch in which to work. To create a branch and switch to it at the same time, you can run the `git checkout` command with the `-b` switch:-->
 
-Du hast Dich dafür entschieden, am Issue #53 des Issue-Trackers XY zu arbeiten. Um eines klarzustellen, Git ist an kein Issue-Tracking-System gebunden. Da der Issue #53 allerdings ein Schwerpunktthema betrifft, wirst Du einen neuen Branch erstellen, um daran zu arbeiten. Um in einem Arbeitsschritt einen neuen Branch zu erstellen und zu aktivieren, kannst Du das Kommando `git checkout` mit der Option `-b` verwenden:
+Du hast Dich dafür entschieden, am Issue #53 des Issue-Trackers XY zu arbeiten. Um eines klarzustellen, Git ist an kein Issue-Tracking-System gebunden. Da der Issue #53 allerdings ein Schwerpunktthema betrifft, wirst Du einen neuen Branch erstellen, um daran zu arbeiten. Um in einem Arbeitsschritt einen neuen Branch zu erstellen und zu aktivieren, kannst Du die Anweisung `git checkout` mit der Option `-b` verwenden:
 
 	$ git checkout -b iss53
 	Switched to a new branch 'iss53'
@@ -238,11 +238,11 @@ Abbildung 3-12. Der `iss53`-Branch hat mit Deiner Arbeit Schritt gehalten.
 
 <!--Now you get the call that there is an issue with the web site, and you need to fix it immediately. With Git, you don’t have to deploy your fix along with the `iss53` changes you’ve made, and you don’t have to put a lot of effort into reverting those changes before you can work on applying your fix to what is in production. All you have to do is switch back to your master branch.-->
 
-Nun bekommst Du einen Anruf, in dem Dir mitgeteilt wird, dass es ein Problem mit der Internet-Seite gibt, das Du umgehend beheben sollst. Mit Git musst Du Deine Fehlerkorrektur nicht zusammen mit den `iss53`-Änderungen einbringen. Und Du musst keine Zeit damit verschwenden, Deine bisherigen Änderungen rückgängig zu machen, bevor Du mit der Fehlerbehebung an der Produktionsumgebung beginnen kannst. Alles was Du tun musst, ist zu Deinem MASTER-Branch wechseln.
+Nun bekommst Du einen Anruf, in dem Dir mitgeteilt wird, dass es ein Problem mit der Internet-Seite gibt, das Du umgehend beheben sollst. Bei Git musst Du Deine Fehlerkorrektur nicht zusammen mit den `iss53`-Änderungen einbringen. Und Du musst keine Zeit damit verschwenden, Deine bisherigen Änderungen rückgängig zu machen, bevor Du mit der Fehlerbehebung an der Produktionsumgebung beginnen kannst. Alles, was Du tun musst, ist, zu Deinem master-Branch wechseln.
 
 <!--However, before you do that, note that if your working directory or staging area has uncommitted changes that conflict with the branch you’re checking out, Git won’t let you switch branches. It’s best to have a clean working state when you switch branches. There are ways to get around this (namely, stashing and commit amending) that we’ll cover later. For now, you’ve committed all your changes, so you can switch back to your master branch:-->
 
-Beachte jedoch, dass Dich Git den Branch nur wechseln lässt, wenn bisherige Änderungen in Deinem Arbeitsverzeichnis oder Deiner Staging-Area nicht in Konflikt mit dem Zweig stehen, zu dem Du nun wechseln möchtest. Am besten es liegt ein sauberer Status vor, wenn man den Branch wechselt. Wir werden uns später mit Wegen befassen, dieses Verhalten zu umgehen (namentlich „Stashing“ und „Commit Ammending“). Vorerst aber hast Du Deine Änderungen bereits comitted, sodass Du zu Deinem MASTER-Branch zurückwechseln kannst.
+Beachte jedoch, dass Dich Git den Branch nur wechseln lässt, wenn bisherige Änderungen in Deinem Arbeitsverzeichnis oder Deiner Staging-Area nicht in Konflikt mit dem Zweig stehen, zu dem Du nun wechseln möchtest. Am besten ist es, wenn ein sauberer Arbeitsstand vorliegt, wenn man den Branch wechselt. Wir werden uns später mit Wegen befassen, dieses Verhalten zu umgehen (namentlich „Stashing“ und „Commit Ammending“). Vorerst aber hast Du Deine Änderungen bereits comitted, sodass Du zu Deinem master-Branch zurückwechseln kannst.
 
 	$ git checkout master
 	Switched to branch 'master'
@@ -253,7 +253,7 @@ Zu diesem Zeitpunkt befindet sich das Arbeitsverzeichnis des Projektes in exakt
 
 <!--Next, you have a hotfix to make. Let’s create a hotfix branch on which to work until it’s completed (see Figure 3-13):-->
 
-Nun hast Du einen Hotfix zu erstellen. Lass uns dazu einen Hotfix-Branch erstellen, an dem Du bis zu dessen Fertigstellung arbeitest (siehe Abbildung 3-13):
+Nun hast Du einen Hotfix zu erstellen. Lass uns dazu einen hotfix-Branch erstellen, an dem Du bis zu dessen Fertigstellung arbeitest (siehe Abbildung 3-13):
 
 	$ git checkout -b hotfix
 	Switched to a new branch 'hotfix'
@@ -265,11 +265,11 @@ Nun hast Du einen Hotfix zu erstellen. Lass uns dazu einen Hotfix-Branch erstell
 <!--Figure 3-13. hotfix branch based back at your master branch point.-->
 
 Insert 18333fig0313.png
-Abbildung 3-13. Der Hotfix-Branch basiert auf dem zurückliegenden Master-Branch.
+Abbildung 3-13. Der hotfix-Branch basiert auf dem zurückliegenden master-Branch.
 
 <!--You can run your tests, make sure the hotfix is what you want, and merge it back into your master branch to deploy to production. You do this with the `git merge` command:-->
 
-Mach Deine Tests, stelle sicher, dass sich der Hotfix verhält wie erwartet und führe ihn mit dem Master-Branch zusammen, um ihn in die Produktionsumgebung zu integrieren. Das machst Du mit dem `git merge`-Kommando:
+Du kannst Deine Tests durchführen und sicherstellen, dass der Hotfix seinen Zweck erfüllt und ihn dann mit dem master-Branch zusammenführen, um ihn in die Produktionsumgebung zu integrieren. Das machst Du mit der Anweisung `git merge`:
 
 	$ git checkout master
 	$ git merge hotfix
@@ -289,11 +289,11 @@ Deine Modifikationen befinden sich nun als Schnappschuss in dem Commit, auf den
 <!--Figure 3-14. Your master branch points to the same place as your hotfix branch after the merge.-->
 
 Insert 18333fig0314.png
-Abbildung 3-14. Der Master-Branch zeigt nach der Zusammenführung auf den gleichen Commit wie der Hotfix-Branch.
+Abbildung 3-14. Der master-Branch zeigt nach der Zusammenführung auf den gleichen Commit wie der hotfix-Branch.
 
 <!--After your super-important fix is deployed, you’re ready to switch back to the work you were doing before you were interrupted. However, first you’ll delete the `hotfix` branch, because you no longer need it — the `master` branch points at the same place. You can delete it with the `-d` option to `git branch`:-->
 
-Nachdem Dein superwichtiger Hotfix veröffentlicht wurde, kannst Du Dich wieder Deiner ursprünglichen Arbeit zuwenden. Vorher wird sich allerdings des nun nutzlosen Hotfix-Zweiges entledigt, schließlich zeigt der Master-Branch ebenfalls auf die aktuelle Version. Du kannst ihn mit der `-d`-Option von `git branch` entfernen:
+Nachdem Dein superwichtiger Hotfix veröffentlicht wurde, kannst Du Dich wieder Deiner ursprünglichen Arbeit zuwenden. Vorher wird sich allerdings des nun nutzlosen hotfix-Zweiges entledigt, schließlich zeigt der master-Branch ebenfalls auf die aktuelle Version. Du kannst ihn mit der `-d`-Option von `git branch` entfernen:
 
 	$ git branch -d hotfix
 	Deleted branch hotfix (was 3a0874c).
@@ -316,7 +316,7 @@ Abbildung 3-15. Dein `iss53`-Branch kann sich unabhängig weiterentwickeln.
 
 <!--It’s worth noting here that the work you did in your `hotfix` branch is not contained in the files in your `iss53` branch. If you need to pull it in, you can merge your `master` branch into your `iss53` branch by running `git merge master`, or you can wait to integrate those changes until you decide to pull the `iss53` branch back into `master` later.-->
 
-An dieser Stelle ist anzumerken, dass die Änderungen an dem `hotfix`-Branch nicht in Deinen `iss53`-Zweig eingeflossen sind. Falls nötig, kannst Du den `master`-Branch allerdings mit dem Kommando `git merge master` mit Deinem Zweig kombinieren. Oder Du wartest, bis Du den `iss53`-Branch später in den Master-Zweig zurückführst.
+An dieser Stelle ist anzumerken, dass die Änderungen an dem `hotfix`-Branch nicht in Deinen `iss53`-Branch eingeflossen sind. Falls nötig, kannst Du den `master`-Branch allerdings mit der Anweisung `git merge master` mit Deinem Branch kombinieren. Oder Du wartest, bis Du den `iss53`-Branch später in den `master`-Branch zurückführst.
 
 <!--### Basic Merging ###-->
 
@@ -324,7 +324,7 @@ An dieser Stelle ist anzumerken, dass die Änderungen an dem `hotfix`-Branch nic
 
 <!--Suppose you’ve decided that your issue #53 work is complete and ready to be merged into your `master` branch. In order to do that, you’ll merge in your `iss53` branch, much like you merged in your `hotfix` branch earlier. All you have to do is check out the branch you wish to merge into and then run the `git merge` command:-->
 
-Angenommen, Du entscheidest dich, dass Deine Arbeit an issue #53 getan ist und Du diese mit der `master` Branch zusammenführen möchtest. Das passiert, indem Du ein `merge` in die `iss53` Branch machst, ähnlich dem `merge` mit der `hotfix` Branch von vorhin. Alles was Du machen musst, ist ein `checkout` der Branch, in die Du das `merge` machen willst und das Ausführen des Kommandos `git merge`:
+Angenommen, Du hast entschieden, dass Deine Arbeiten an issue #53 abgeschlossen sind und das Ganze soweit ist, dass es mit dem `master` Branch zusammengeführt werden kann. Um das zu erreichen, wirst Du Deinen `iss53` Branch in den `master` Branch einfließen lassen, genauso wie Du es mit dem `hotfix` Branch zuvor getan hast. Du musst nur mit der Anweisung `checkout` zum dem Branch zu wechseln, in welchen Du etwas einfließen lassen möchtest und dann die Anweisung `git merge` ausführen:
 
 	$ git checkout master
 	$ git merge iss53
@@ -335,20 +335,20 @@ Angenommen, Du entscheidest dich, dass Deine Arbeit an issue #53 getan ist und D
 
 <!--This looks a bit different than the `hotfix` merge you did earlier. In this case, your development history has diverged from some older point. Because the commit on the branch you’re on isn’t a direct ancestor of the branch you’re merging in, Git has to do some work. In this case, Git does a simple three-way merge, using the two snapshots pointed to by the branch tips and the common ancestor of the two. Figure 3-16 highlights the three snapshots that Git uses to do its merge in this case.-->
 
-Das sieht ein bisschen anders aus als das `hotfix merge` von vorhin. Hier läuft Deine Entwicklungshistorie auseinander. Ein `commit` auf Deine Arbeits-Branch ist kein direkter Nachfolger der Branch, in die Du das `merge` gemacht hast, Git hat da einiges zu tun, es macht einen 3-Wege `merge`: es geht von den beiden `snapshots` der Branches und dem allgemeinen Nachfolger der beiden aus. Abbildung 3-16 zeigt die drei `snapshots`, die Git in diesem Fall für das `merge` verwendet.
+Das sieht ein bisschen anders aus als das `hotfix merge` von vorhin. Hier haben sich die Entwicklungsstränge schon zu einem früheren Zeitpunkt geteilt. Da der `commit` auf dem Branch, in dem Du Dich befindest, kein direkter Nachfolger von dem Branch ist, in den Du das `merge` machst, hat Git einiges zu tun. Dazu macht Git einen 3-Wege `merge`, wobei es die beiden Schnappschüsse verwendet, welche auf die Enden der Branches zeigen, und den gemeinsamen Vorfahren dieser beiden. Abbildung 3-16 zeigt die drei `snapshots`, die Git in diesem Fall für das `merge` verwendet.
 
 <!--Figure 3-16. Git automatically identifies the best common-ancestor merge base for branch merging.-->
 
 Insert 18333fig0316.png
-Abbildung 3-16. Git ermittelt automatisch die beste Nachfolgebasis für die Branchzusammenführung.
+Abbildung 3-16. Git erkennt automatisch den am besten geeigneten gemeinsamen Vorgänger für die Branchzusammenführung.
 
 <!--Instead of just moving the branch pointer forward, Git creates a new snapshot that results from this three-way merge and automatically creates a new commit that points to it (see Figure 3-17). This is referred to as a merge commit and is special in that it has more than one parent.-->
 
-Anstatt einfach den 'pointer' weiterzubewegen, erstellt Git einen neuen `snapshot`, der aus dem 3-Wege 'merge' resultiert und erzeugt einen neuen 'commit', der darauf verweist (siehe Abbildung 3-17). Dies wird auch als 'merge commit' bezeichnet und ist ein Spezialfall, weil es mehr als nur ein Elternteil hat.
+Anstatt einfach den Zeiger vorwärts zu bewegen, erstellt Git einen neuen `snapshot`, der aus dem 3-Wege 'merge' resultiert und erzeugt automatisch einen neuen `commit`, der darauf verweist (siehe Abbildung 3-17). Dies wird auch als `merge commit` bezeichnet und ist ein Spezialfall, weil es mehr als nur einen Elternteil hat.
 
 <!--It’s worth pointing out that Git determines the best common ancestor to use for its merge base; this is different than CVS or Subversion (before version 1.5), where the developer doing the merge has to figure out the best merge base for themselves. This makes merging a heck of a lot easier in Git than in these other systems.-->
 
-Es ist wichtig herauszustellen, dass Git den besten Nachfolger für die 'merge' Basis ermittelt, denn hierin unterscheidet es sich von CVS und Subversion (vor Version 1.5), wo der Entwickler die 'merge' Basis selbst ermitteln muss. Damit wird das Zusammenführen in Git um einiges leichter, als in anderen Systemen.
+Es ist wichtig herauszustellen, dass Git den am besten geeigneten gemeinsamen Vorgänger als Grundlage für das Zusammenführen bestimmt, denn hierin unterscheidet es sich von CVS und Subversion (vor Version 1.5), wo der Entwickler beim Zusammenführen die 'merge' Basis selbst ermitteln muss. In Git ist das Zusammenführen dadurch wesentlich einfacher, als in anderen Systemen.
 
 <!--Figure 3-17. Git automatically creates a new commit object that contains the merged work.-->
 
@@ -357,7 +357,7 @@ Abbildung 3-17. Git erstellt automatisch ein 'commit', dass die zusammengeführt
 
 <!--Now that your work is merged in, you have no further need for the `iss53` branch. You can delete it and then manually close the ticket in your ticket-tracking system:-->
 
-Jetzt da wir die Arbeit zusammengeführt haben, ist der `iss53`-Branch nicht mehr notwendig. Du kannst ihn löschen und das Ticket im Ticket-Tracking-System schliessen.
+Jetzt, da wir die Arbeit zusammengeführt haben, ist der `iss53`-Branch nicht mehr notwendig. Du kannst ihn löschen und das Ticket im Ticket-Tracking-System schließen.
 
 	$ git branch -d iss53
 
@@ -403,7 +403,7 @@ Alles, was einen 'merge' Konflikt aufweist und nicht gelöst werden konnte, wird
 
 <!--This means the version in HEAD (your master branch, because that was what you had checked out when you ran your merge command) is the top part of that block (everything above the `=======`), while the version in your `iss53` branch looks like everything in the bottom part. In order to resolve the conflict, you have to either choose one side or the other or merge the contents yourself. For instance, you might resolve this conflict by replacing the entire block with this:-->
 
-Das heißt, die Version in HEAD (Deines 'master'-Branches, denn der wurde per 'checkout' aktiviert als Du das 'merge' gemacht hast) ist der obere Teil des Blocks (alles oberhalb von '======='), und die Version aus dem `iss53`-Branch sieht wie der darunter befindliche Teil aus. Um den Konflikt zu lösen, musst Du Dich entweder für einen der beiden Teile entscheiden oder Du ersetzt den Teil komplett:
+Das heißt, die Version in HEAD (Deines 'master'-Branches, denn der wurde per 'checkout' aktiviert, als Du das 'merge' gemacht hast) ist der obere Teil des Blocks (alles oberhalb von '======='), und die Version aus dem `iss53`-Branch sieht wie der darunter befindliche Teil aus. Um den Konflikt zu lösen, musst Du Dich entweder für einen der beiden Teile entscheiden oder Du ersetzt den Teil komplett:
 
 	<div id="footer">
 	please contact us at email.support@github.com
@@ -431,7 +431,7 @@ Wenn Du ein grafisches Tool zur Bereinigung benutzen willst, dann verwende `git
 
 <!--If you want to use a merge tool other than the default (Git chose `opendiff` for me in this case because I ran the command on a Mac), you can see all the supported tools listed at the top after “... one of the following tools:”. Type the name of the tool you’d rather use. In Chapter 7, we’ll discuss how you can change this default value for your environment.-->
 
-Wenn Du ein anderes Tool anstelle des Standardwerkzeug für ein 'merge' verwenden möchtest (Git verwendet in meinem Fall `opendiff`, da ich auf einem Mac arbeite), dann kannst Du alle unterstützten Werkzeuge oben – unter „one of the following tools“ – aufgelistet sehen. Tippe einfach den Namen Deines gewünschten Werkzeugs ein. In Kapitel 7 besprechen wir, wie Du diesen Standardwert in Deiner Umgebung dauerhaft ändern kannst.
+Wenn Du ein anderes Tool anstelle des Standardwerkzeugs für ein 'merge' verwenden möchtest (Git verwendet in meinem Fall `opendiff`, da ich auf einem Mac arbeite), dann kannst Du alle unterstützten Werkzeuge oben – unter „one of the following tools“ – aufgelistet sehen. Tippe einfach den Namen Deines gewünschten Werkzeugs ein. In Kapitel 7 besprechen wir, wie Du diesen Standardwert in Deiner Umgebung dauerhaft ändern kannst.
 
 <!--After you exit the merge tool, Git asks you if the merge was successful. If you tell the script that it was, it stages the file to mark it as resolved for you.-->
 
@@ -451,7 +451,7 @@ Du kannst `git status` erneut ausführen, um zu sehen, ob alle Konflikte gelöst
 
 <!--If you’re happy with that, and you verify that everything that had conflicts has been staged, you can type `git commit` to finalize the merge commit. The commit message by default looks something like this:-->
 
-Wenn Du zufrieden bist und Du geprüft hast, dass alle Konflikte beseitigt wurden, kannst Du `git commit` ausführen, um den 'merge commit' abzuschliessen. Die Standardbeschreibung für diese Art 'commit' sieht wie folgt aus:
+Wenn Du zufrieden bist und Du geprüft hast, dass alle Konflikte beseitigt wurden, kannst Du `git commit` ausführen, um den 'merge commit' abzuschließen. Die Standardbeschreibung für diese Art 'commit' sieht wie folgt aus:
 
 	Merge branch 'iss53'
 
@@ -466,18 +466,18 @@ Wenn Du zufrieden bist und Du geprüft hast, dass alle Konflikte beseitigt wurde
 
 <!--You can modify that message with details about how you resolved the merge if you think it would be helpful to others looking at this merge in the future — why you did what you did, if it’s not obvious.-->
 
-Wenn Du glaubst, für zukünftige Betrachter des Commits könnte interessant sein, warum Du getan hast, was Du getan hast, dann kannst Du der Commit-Beschreibung noch zusätzliche Informationen hinzufügen – sofern das nicht trivial erscheint.
+Wenn Du glaubst, für zukünftige Betrachter des Commits könnte es hilfreich sein zu erklären, warum Du getan hast, was Du getan hast, dann kannst Du der Commit-Beschreibung noch zusätzliche Informationen hinzufügen, falls es nicht offensichtlich ist.
 
 <!--## Branch Management ##-->
 ## Branch Management ##
 
 <!--Now that you’ve created, merged, and deleted some branches, let’s look at some branch-management tools that will come in handy when you begin using branches all the time.-->
 
-Du weißt jetzt, wie Du Branches erstellen, mergen und löschen kannst. Wir schauen uns jetzt noch ein paar recht nützliche Tools für die Arbeit mit Branches an.
+Du weißt jetzt, wie Du Branches erstellen, zusammenfügen und löschen kannst. Wir schauen uns jetzt noch ein paar recht nützliche Tools für die Arbeit mit Branches an.
 
 <!--The `git branch` command does more than just create and delete branches. If you run it with no arguments, you get a simple listing of your current branches:-->
 
-Das Kommando `git branch` kann mehr, als nur Branches zu erstellen oder zu löschen. Wenn Du es ohne weitere Argumente ausführst, wird es Dir eine Liste mit Deinen aktuellen Branches anzeigen:
+Die Anweisung `git branch` kann mehr, als nur Branches zu erstellen oder zu löschen. Wenn Du es ohne weitere Argumente ausführst, wird es Dir eine Liste mit Deinen aktuellen Branches anzeigen:
 
 	$ git branch
 	  iss53
@@ -529,14 +529,14 @@ Wenn Du den Branch trotzdem löschen und damit alle Änderungen dieses Branches
 
 <!--Now that you have the basics of branching and merging down, what can or should you do with them? In this section, we’ll cover some common workflows that this lightweight branching makes possible, so you can decide if you would like to incorporate it into your own development cycle.-->
 
-Jetzt, da Du die Grundlagen von 'branching' und 'merging' kennst, fragst Du Dich sicher, was Du damit anfangen kannst. In diesem Abschnitt werden wir uns typische Workflows anschauen, die dieses leichtgewichtige 'branching' möglich macht. Und Du kannst dann entscheiden, ob Du es in Deinem eigene Entwicklungszyklus verwenden willst.
+Jetzt, da Du die Grundlagen von 'branching' und 'merging' kennst, fragst Du Dich sicher, was Du damit anfangen kannst. In diesem Abschnitt werden wir uns typische Workflows anschauen, die dieses leichtgewichtige 'branching' möglich macht. Und Du kannst dann entscheiden, ob Du es in Deinem eigenen Entwicklungszyklus verwenden willst.
 
 <!--### Long-Running Branches ###-->
 ### Langfristige Branches ###
 
 <!--Because Git uses a simple three-way merge, merging from one branch into another multiple times over a long period is generally easy to do. This means you can have several branches that are always open and that you use for different stages of your development cycle; you can merge regularly from some of them into others.-->
 
-Da Git das einfache 3-Wege-'merge' verwendet, ist häufiges Zusammenführen von einer Branch in eine andere über einen langen Zeitraum generell einfach zu bewerkstelligen. Das heißt, Du kannst mehrere Branches haben, die alle offen sind und auf unterschiedlichen Ebenen Deines Entwicklungszyklus Verwendung finden, und diese regelmäßig ineinander zusammenführen.
+Da Git das einfache 3-Wege-'merge' verwendet, ist häufiges Zusammenführen von einem Branch in einen anderen über einen langen Zeitraum generell einfach zu bewerkstelligen. Das heißt, Du kannst mehrere Branches haben, die immer offen sind und die Du für unterschiedliche Stadien Deines Entwicklungszyklus verwendest, und Du kannst regelmäßig welche von diesen mit anderen zusammenführen.
 
 <!--Many Git developers have a workflow that embraces this approach, such as having only code that is entirely stable in their `master` branch — possibly only code that has been or will be released. They have another parallel branch named develop or next that they work from or use to test stability — it isn’t necessarily always stable, but whenever it gets to a stable state, it can be merged into `master`. It’s used to pull in topic branches (short-lived branches, like your earlier `iss53` branch) when they’re ready, to make sure they pass all the tests and don’t introduce bugs.-->
 
@@ -544,7 +544,7 @@ Viele Git Entwickler verfolgen mit ihrem Workflow den Ansatz, nur den stabilen C
 
 <!--In reality, we’re talking about pointers moving up the line of commits you’re making. The stable branches are farther down the line in your commit history, and the bleeding-edge branches are farther up the history (see Figure 3-18).-->
 
-In Realität reden wir über sich bewegende Zeiger, die den Commit-Verlauf weiterwandern. Die stabilen Branches liegen unten und die bleeding-edge Branches weiter oben in der Zeitlinie (siehe Abbildung 3-18).
+Eigentlich reden wir gerade über Zeiger, die in der Reihe Deiner Commits aufsteigen. Die stabilen Branches liegen weiter unten und die bleeding-edge Branches weiter oben in diesem Verlauf (siehe Abbildung 3-18).
 
 <!--Figure 3-18. More stable branches are generally farther down the commit history.-->
 
@@ -565,7 +565,7 @@ Abbildung 3-19. Es könnte hilfreich sein, sich die Branches als Depots vorzuste
 
 Das lässt sich für beliebig viele Stabilitätsabstufungen umsetzen. Manche größeren Projekte haben auch einen `proposed` (vorgeschlagenen) oder `pu` (proposed updates – vorgeschlagene Updates) Zweig mit Branches, die vielleicht noch nicht bereit sind, in den `next`- oder `master`-Branch integriert zu werden. Die Idee dahinter ist, dass Deine Branches verschiedene Stabilitätsabstufungen repräsentieren. Sobald sie eine stabilere Stufe erreichen, werden sie mit dem nächsthöheren Branch zusammengeführt.
 
-Nochmal, langfristig verschiedene Branches parallel laufen zu lassen, ist nicht notwendig, aber oft hilfreich. Insbesondere wenn man es mit sehr großen oder komplexen Projekten zu tun hat.
+Nochmal, langfristig verschiedene Branches parallel laufen zu lassen, ist nicht notwendig, aber oft hilfreich,  insbesondere wenn man es mit sehr großen oder komplexen Projekten zu tun hat.
 
 <!--### Topic Branches ###-->
 ### Themen-Branches ###
@@ -576,11 +576,11 @@ Themen-Branches sind in jedem Projekt nützlich, egal bei welcher Größe. Ein T
 
 <!--You saw this in the last section with the `iss53` and `hotfix` branches you created. You did a few commits on them and deleted them directly after merging them into your main branch. This technique allows you to context-switch quickly and completely — because your work is separated into silos where all the changes in that branch have to do with that topic, it’s easier to see what has happened during code review and such. You can keep the changes there for minutes, days, or months, and merge them in when they’re ready, regardless of the order in which they were created or worked on.-->
 
-Du hast das im letzten Abschnitt an den von Dir erstellten `iss53`- und `hotfix`-Branches gesehen. Du hast mehrere Commits auf sie angewendet und sie unmittelbar nach Zusammenführung mit Deinem Hauptzweig gelöscht. Diese Technik erlaubt es Dir, schnell und vollständig den Kontext zu wechseln. Da Deine Arbeit in verschiedene Depots aufgeteilt ist, in denen alle Änderungen unter die Thematik dieses Branches fallen, ist es leichter nachzuvollziehen, was bei Code-Überprüfungen und ähnlichem geschehen ist.
+Du hast das im letzten Abschnitt an den von Dir erstellten `iss53`- und `hotfix`-Branches gesehen. Du hast mehrere Commits auf sie angewendet und sie unmittelbar nach Zusammenführung mit Deinem Hauptzweig gelöscht. Diese Technik erlaubt es Dir, schnell und vollständig den Kontext zu wechseln. Da Deine Arbeit in verschiedene Depots aufgeteilt ist, in denen alle Änderungen unter die Thematik dieses Branches fallen, ist es leichter nachzuvollziehen, was bei Code-Überprüfungen und ähnlichem geschehen ist. Du kannst die Änderungen darin für Minuten, Tage oder Monate aufbewahren und sie einfließen lassen, wenn diese fertig sind, ungeachtet der Reihenfolge, in welcher diese erstellt oder bearbeitet wurden.
 
 <!--Consider an example of doing some work (on `master`), branching off for an issue (`iss91`), working on it for a bit, branching off the second branch to try another way of handling the same thing (`iss91v2`), going back to your master branch and working there for a while, and then branching off there to do some work that you’re not sure is a good idea (`dumbidea` branch). Your commit history will look something like Figure 3-20.-->
 
-Stell Dir vor, Du arbeitest ein bisschen (in `master`), erstellst mal eben einen Branch für einen Fehler (`iss91`), arbeitest an dem für eine Weile, erstellst einen zweiten Branch, um eine andere Problemlösung für den selben Fehler auszuprobieren (`iss91v2`), wechselst zurück zu Deinem MASTER-Branch, arbeitest dort ein bisschen und machst dann einen neuen Branch für etwas, wovon Du nicht weißt, ob's eine gute Idee ist (`dumbidea`-Branch). Dein Commit-Verlauf wird wie in Abbildung 3-20 aussehen.
+Stell Dir vor, Du arbeitest ein bisschen (in `master`), erstellst mal eben einen Branch für einen Fehler (`iss91`), arbeitest an dem für eine Weile, erstellst einen zweiten Branch, um eine andere Problemlösung für den selben Fehler auszuprobieren (`iss91v2`), wechselst zurück zu Deinem master-Branch, arbeitest dort ein bisschen und machst dann einen neuen Branch für etwas, wovon Du nicht weißt, ob es eine gute Idee ist (`dumbidea`-Branch). Dein Commit-Verlauf wird wie in Abbildung 3-20 aussehen.
 
 <!--Figure 3-20. Your commit history with multiple topic branches.-->
 
@@ -589,7 +589,7 @@ Abbildung 3-20. Dein Commit-Verlauf mit verschiedenen Themen-Branches.
 
 <!--Now, let’s say you decide you like the second solution to your issue best (`iss91v2`); and you showed the `dumbidea` branch to your coworkers, and it turns out to be genius. You can throw away the original `iss91` branch (losing commits C5 and C6) and merge in the other two. Your history then looks like Figure 3-21.-->
 
-Nun, sagen wir, Du hast Dich entschieden, die zweite Lösung des Fehlers (`iss91v2`) zu bevorzugen, außerdem hast den `dumbidea`-Branch Deinen Mitarbeitern gezeigt und es hat sich herausgestellt, dass er genial ist. Du kannst also den ursprünglichen `iss91`-Branch (unter Verlust der Commits C5 und C6) wegwerfen und die anderen beiden vereinen. Dein Verlauf sieht dann aus wie in Abbildung 3-21.
+Nun, sagen wir, Du hast Dich entschieden, die zweite Lösung des Fehlers (`iss91v2`) zu bevorzugen, außerdem hast den `dumbidea`-Branch Deinen Mitarbeitern gezeigt und es hat sich herausgestellt, dass er genial ist. Du kannst also den ursprünglichen `iss91`-Branch (unter Verlust der Commits C5 und C6) wegwerfen und die anderen beiden einfließen lassen. Dein Verlauf sieht dann aus wie in Abbildung 3-21.
 
 <!--Figure 3-21. Your history after merging in dumbidea and iss91v2.-->
 
@@ -605,7 +605,7 @@ Es ist wichtig, sich daran zu erinnern, dass alle diese Branches nur lokal exist
 
 <!--Remote branches are references to the state of branches on your remote repositories. They’re local branches that you can’t move; they’re moved automatically whenever you do any network communication. Remote branches act as bookmarks to remind you where the branches on your remote repositories were the last time you connected to them.-->
 
-Externe (Remote) Branches sind Referenzen auf den Zustand der Branches in Deinen externen Repositorys. Es sind lokale Branches, die Du nicht verändern kannst, sie werden automatisch verändert, wann immer Du eine Netzwerkoperation durchführst. Externe Branches verhalten sich wie Lesezeichen, um Dich daran zu erinnern, an welcher Position sich die Branches in Deinen externen Repositorys befanden, als Du Dich zuletzt mit ihnen verbunden hattest.
+Externe (Remote) Branches sind Referenzen auf den Zustand der Branches in Deinen externen Repositorys. Sie sind lokale Branches, die Du nicht verändern kannst, sie werden automatisch verändert, wann immer Du eine Netzwerkoperation durchführst. Externe Branches verhalten sich wie Lesezeichen, um Dich daran zu erinnern, an welcher Position sich die Branches in Deinen externen Repositorys befanden, als Du Dich zum letzten Mal mit ihnen verbunden hattest.
 
 <!--They take the form `(remote)/(branch)`. For instance, if you wanted to see what the `master` branch on your `origin` remote looked like as of the last time you communicated with it, you would check the `origin/master` branch. If you were working on an issue with a partner and they pushed up an `iss53` branch, you might have your own local `iss53` branch; but the branch on the server would point to the commit at `origin/iss53`.-->
 
@@ -613,7 +613,7 @@ Externe Branches besitzen die Schreibweise `(Repository)/(Branch)`. Wenn Du beis
 
 <!--This may be a bit confusing, so let’s look at an example. Let’s say you have a Git server on your network at `git.ourcompany.com`. If you clone from this, Git automatically names it `origin` for you, pulls down all its data, creates a pointer to where its `master` branch is, and names it `origin/master` locally; and you can’t move it. Git also gives you your own `master` branch starting at the same place as origin’s `master` branch, so you have something to work from (see Figure 3-22).-->
 
-Das kann ein wenig verwirrend sein, lass uns also ein Besipiel betrachten. Nehmen wir an Du hättest in Deinem Netzwerk einen Git-Server mit der Adresse `git.ourcompany.com`. Wenn Du von diesem klonst, nennt Git ihn automatisch `origin` für Dich, lädt all seine Daten herunter, erstellt einen Zeiger zur der Stelle, wo sein `master`-Branch ist und benennt es lokal `origin/master`; und er ist unveränderbar für Dich. Git gibt Dir auch einen eigenen `master`-Branch mit der gleichen Ausgangsposition wie origins `master`-Branch, damit Du einen Punkt für den Beginn Deiner Arbeiten hast (siehe Abbildung 3-22).
+Das kann ein wenig verwirrend sein, lass uns also ein Besipiel betrachten. Nehmen wir an, Du hättest in Deinem Netzwerk einen Git-Server mit der Adresse `git.ourcompany.com`. Wenn Du von diesem klonst, nennt Git ihn automatisch `origin` für Dich, lädt all seine Daten herunter, erstellt einen Zeiger zur der Stelle, wo sein `master`-Branch ist und benennt es lokal `origin/master`; und er ist unveränderbar für Dich. Git gibt Dir auch einen eigenen `master`-Branch mit der gleichen Ausgangsposition wie origins `master`-Branch, damit Du einen Punkt für den Beginn Deiner Arbeiten hast (siehe Abbildung 3-22).
 
 <!--Figure 3-22. A Git clone gives you your own master branch and origin/master pointing to origin’s master branch.-->
 
@@ -622,25 +622,25 @@ Abbildung 3-22. Ein 'git clone' gibt Dir Deinen eigenen `master`-Branch und `ori
 
 <!--If you do some work on your local master branch, and, in the meantime, someone else pushes to `git.ourcompany.com` and updates its master branch, then your histories move forward differently. Also, as long as you stay out of contact with your origin server, your `origin/master` pointer doesn’t move (see Figure 3-23).-->
 
-Wenn Du ein wenig an Deinem lokalen `master`-Branch arbeitest und unterdessen jemand etwas zu `git.ourcompany.com` herauflädt, verändert er damit dessen `master`-Branch und Eure Arbeitsverläufe entwickeln sich unterschiedlich. Indes bewegt sich Dein `origin/master`-Zeiger nicht, solange Du keinen Kontakt mit Deinem `origin`-Server aufnimmst (siehe Abbildung 3-23).
+Wenn Du ein wenig an Deinem lokalen `master`-Branch arbeitest und in der Zwischenzeit ein anderer etwas zu `git.ourcompany.com` herauflädt und damit den `master`-Branch auf dem externen Server aktualisiert, dann entwickeln sich Eure Arbeitsverläufe unterschiedlich. Außerdem bewegt sich Dein `origin/master`-Zeiger nicht, solange Du keinen Kontakt mit Deinem `origin`-Server aufnimmst (siehe Abbildung 3-23).
 
 <!--Figure 3-23. Working locally and having someone push to your remote server makes each history move forward differently.-->
 
 Insert 18333fig0323.png
-Abbildung 3-23. Lokales Arbeiten, während jemand auf Deinen externen Server hochlädt, lässt jeden Änderungsverlauf unterschiedlich weiterentwickeln.
+Abbildung 3-23. Lokal zu arbeiten, während ein anderer auf Deinen externen Server hochlädt, führt zu unterschiedlichen Verläufen.
 
 <!--To synchronize your work, you run a `git fetch origin` command. This command looks up which server origin is (in this case, it’s `git.ourcompany.com`), fetches any data from it that you don’t yet have, and updates your local database, moving your `origin/master` pointer to its new, more up-to-date position (see Figure 3-24).-->
 
-Um Deine Arbeit abzugleichen, führe ein `git fetch origin`-Kommando aus. Das Kommando schlägt nach, welcher Server `orgin` ist (in diesem Fall `git.ourcompany.com`), holt alle Daten, die Dir bisher fehlen und aktualisiert Deine lokale Datenbank, indem es Deinen `orgin/master`-Zeiger auf seine neue aktuellere Position bewegt (siehe Abbildung 3-24).
+Um Deine Arbeit abzugleichen, führe die Anweisung `git fetch origin` aus. Die Anweisung schlägt nach, welcher Server `orgin` ist (in diesem Fall `git.ourcompany.com`), holt alle Daten, die Dir bisher fehlen und aktualisiert Deine lokale Datenbank, indem es Deinen `orgin/master`-Zeiger auf seine neue aktuellere Position bewegt (siehe Abbildung 3-24).
 
 <!--Figure 3-24. The git fetch command updates your remote references.-->
 
 Insert 18333fig0324.png
-Abbildung 3-24. Das `git fetch`-Kommando aktualisiert Deine externen Referenzen.
+Abbildung 3-24. Die Anweisung `git fetch` aktualisiert Deine externen Referenzen.
 
 <!--To demonstrate having multiple remote servers and what remote branches for those remote projects look like, let’s assume you have another internal Git server that is used only for development by one of your sprint teams. This server is at `git.team1.ourcompany.com`. You can add it as a new remote reference to the project you’re currently working on by running the `git remote add` command as we covered in Chapter 2. Name this remote `teamone`, which will be your shortname for that whole URL (see Figure 3-25).-->
 
-Um zu demonstrieren, wie Branches auf verschiedenen Remote-Servern aussehen, stellen wir uns vor, dass Du einen weiteren internen Git-Server besitzt, welcher nur von einem Deiner Sprint-Teams zur Entwicklung genutzt wird. Diesen Server erreichen wir unter `git.team1.ourcompany.com`. Du kannst ihn, mit dem Git-Kommando `git remote add` – wie in Kapitel 2 beschrieben, Deinem derzeitigen Arbeitsprojekt als weiteren Quell-Server hinzufügen. Gib dem Remote-Server den Namen `teamone`, welcher nun als Synonym für die ausgeschriebene Internetadresse dient (siehe Abbildung 3-25).
+Um zu demonstrieren, wie Branches auf verschiedenen Remote-Servern aussehen, stellen wir uns vor, dass Du einen weiteren internen Git-Server besitzt, welcher nur von einem Deiner Sprint-Teams zur Entwicklung genutzt wird. Diesen Server erreichen wir unter `git.team1.ourcompany.com`. Du kannst ihn mit der Git-Anweisung `git remote add`, wie in Kapitel 2 beschrieben, Deinem derzeitigen Arbeitsprojekt als weiteren Quell-Server hinzufügen. Gib dem Remote-Server den Namen `teamone`, welcher nun als Synonym für die ausgeschriebene Internetadresse dient (siehe Abbildung 3-25).
 
 <!--Figure 3-25. Adding another server as a remote.-->
 
@@ -724,7 +724,7 @@ Wenn Du ein Repository klonst, wird automatisch ein `master`-Branch erzeugt, wel
 
 <!--To set up a local branch with a different name than the remote branch, you can easily use the first version with a different local branch name:-->
 
-Um einen lokalen Branch mit einem anderen Namen zu versehen als jenem im Remote-Branch, kannst Du einfach die erste Variante mit einem neuen lokalen Branch-Namen verwenden:
+Um einen lokalen Branch zu erzeugen mit einem anderen Namen als dem des Remote-Branches, kannst Du einfach die erste Variante mit einem neuen lokalen Branch-Namen verwenden:
 
 	$ git checkout -b sf origin/serverfix
 	Branch sf set up to track remote branch serverfix from origin.
@@ -739,7 +739,7 @@ Nun wird Dein lokaler Branch `sf` automatisch push und pull auf `origin/serverfi
 
 <!--Suppose you’re done with a remote branch — say, you and your collaborators are finished with a feature and have merged it into your remote’s `master` branch (or whatever branch your stable codeline is in). You can delete a remote branch using the rather obtuse syntax `git push [remotename] :[branch]`. If you want to delete your `serverfix` branch from the server, you run the following:-->
 
-Stellen wir uns vor, Du bist fertig mit Deinem Remote-Branch – sagen wir Deine Mitarbeiter und Du, Ihr seid fertig mit einer neuen Funktion und habt sie in den entfernten `master`-Branch (oder in welchem Zweig Ihr sonst den stabilen Code ablegt) gemerged. Du kannst einen Remote-Branch mit der unlogischen Syntax `git push [remotename] :[branch]` löschen. Wenn Du Deinen `serverfix`-Branch vom Server löschen möchtest, führe folgendes aus:
+Stellen wir uns vor, Du bist fertig mit Deinem Remote-Branch – sagen wir Deine Mitarbeiter und Du, Ihr seid fertig mit einer neuen Funktion und habt sie in den entfernten `master`-Branch (oder in welchem Zweig Ihr sonst den stabilen Code ablegt) gemerged. Dann kannst Du den Remote-Branch löschen, indem Du die recht stumpfsinnige Syntax `git push [remotename] :[branch]` benutzt. Wenn Du Deinen `serverfix`-Branch vom Server löschen möchtest, führe folgendes aus:
 
 	$ git push origin :serverfix
 	To git@github.com:schacon/simplegit.git
@@ -747,21 +747,21 @@ Stellen wir uns vor, Du bist fertig mit Deinem Remote-Branch – sagen wir Deine
 
 <!--Boom. No more branch on your server. You may want to dog-ear this page, because you’ll need that command, and you’ll likely forget the syntax. A way to remember this command is by recalling the `git push [remotename] [localbranch]:[remotebranch]` syntax that we went over a bit earlier. If you leave off the `[localbranch]` portion, then you’re basically saying, “Take nothing on my side and make it be `[remotebranch]`.”-->
 
-Boom. Kein Zweig mehr auf Deinem Server. Du möchtest Dir diese Seite vielleicht markieren, weil Du dieses Kommando noch benötigen wirst und man leicht dessen Syntax vergisst. Ein Weg, sich an dieses Kommando zu erinnern, führt über die `git push [remotename] [localbranch]:[remotebranch]`-Snytax, welche wir bereits behandelt haben. Wenn Du den `[localbranch]`-Teil weglässt, dann sagst Du einfach „Nimm nichts von meiner Seite und mach es zu `[remotebranch]`“.
+Boom. Kein Zweig mehr auf Deinem Server. Du möchtest Dir diese Seite vielleicht markieren, weil Du diese Anweisung noch benötigen wirst und man leicht deren Syntax vergisst. Ein Weg, sich an diese Anweisung zu erinnern, führt über die `git push [remotename] [localbranch]:[remotebranch]`-Snytax, welche wir bereits behandelt haben. Wenn Du den `[localbranch]`-Teil weglässt, dann sagst Du einfach „Nimm nichts von meiner Seite und mach es zu `[remotebranch]`“.
 
 <!--## Rebasing ##-->
 ## Rebasing ##
 
 <!--In Git, there are two main ways to integrate changes from one branch into another: the `merge` and the `rebase`. In this section you’ll learn what rebasing is, how to do it, why it’s a pretty amazing tool, and in what cases you won’t want to use it.-->
 
-Es gibt in Git zwei Wege, um Änderungen von einem Branch in einen anderen zu überführen: das `merge` und das `rebase`-Kommando. In diesem Abschnitt wirst Du kennenlernen, was Rebasing ist, wie Du es anwendest, warum es ein verdammt abgefahrenes Werkzeug ist und wann Du es lieber nicht einsetzen möchtest.
+Es gibt in Git zwei Wege, um Änderungen von einem Branch in einen anderen zu überführen: `merge` und `rebase`. In diesem Abschnitt wirst Du erfahren, was Rebasing ist, wie Du es anwendest, warum es ein verdammt abgefahrenes Werkzeug ist und bei welchen Gelegenheiten Du es besser nicht einsetzen solltest.
 
 <!--### The Basic Rebase ###-->
 ### Der einfache Rebase ###
 
 <!--If you go back to an earlier example from the Merge section (see Figure 3-27), you can see that you diverged your work and made commits on two different branches.-->
 
-Wenn Du zu einem früheren Beispiel aus dem Merge-Kapitel zurückkehrst (siehe Abbildung 3-27), wirst Du sehen, dass Du Deine Arbeit auf zwei unterschiedliche Branches aufgeteilt hast.
+Wenn Du zu einem früheren Beispiel aus dem Merge-Kapitel zurückkehrst (siehe Abbildung 3-27), kannst Du sehen, dass Du Deine Arbeit aufgeteilt und Commits auf zwei unterschiedlichen Branches erstellt hast.
 
 <!--Figure 3-27. Your initial diverged commit history.-->
 
@@ -770,16 +770,16 @@ Abbildung 3-27. Deine initiale Commit-Historie zum Zeitpunkt der Aufteilung.
 
 <!--The easiest way to integrate the branches, as we’ve already covered, is the `merge` command. It performs a three-way merge between the two latest branch snapshots (C3 and C4) and the most recent common ancestor of the two (C2), creating a new snapshot (and commit), as shown in Figure 3-28.-->
 
-Der einfachste Weg, um Zweige zusammenzuführen, ist, wie bereits behandelt, das `merge`-Kommando. Es produziert einen Drei-Wege-Merge zwischen den beiden letzten Branch-Zuständen (C3 und C4) und ihrem wahrscheinlichsten Vorgänger (C2). Es produziert seinerseits einen Schnappschuss des Projektes (und einen Commit), wie in Abbildung 3-28 dargestellt.
+Der einfachste Weg, um Zweige zusammenzuführen, ist, wie bereits behandelt, die `merge`-Anweisung. Sie führt einen Drei-Wege-Merge durch zwischen den beiden letzten Branch-Zuständen (C3 und C4) und dem letzen gemeinsamen Vorgänger (C2) der beiden, erstellt einen neuen Schnappschuss (und einen Commit), wie in Abbildung 3-28 dargestellt.
 
 <!--Figure 3-28. Merging a branch to integrate the diverged work history.-->
 
 Insert 18333fig0328.png
-Abbildung 3-28. Das Zusammenführen eines Branches um die verschiedenen Arbeitsfortschritte zu integrieren.
+Abbildung 3-28. Zusammenführen von Branches, um die verschiedenen Arbeitsfortschritte zu integrieren.
 
 <!--However, there is another way: you can take the patch of the change that was introduced in C3 and reapply it on top of C4. In Git, this is called _rebasing_. With the `rebase` command, you can take all the changes that were committed on one branch and replay them on another one.-->
 
-Wie auch immer, es gibt noch einen anderen Weg: Du kannst den Patch der Änderungen – den wir in C3 eingeführt haben –  über C4 anwenden. Dieses Vorgehen nennt man in Git _rebasing_. Mit dem `rebase`-Kommando kannst Du alle Änderungen, die auf einem Branch angewendet wurden, auf einen anderen Branch erneut anwenden.
+Allerdings gibt es noch einen anderen Weg: Du kannst den Patch der Änderungen, den wir in C3 eingeführt haben, nehmen und erneut anwenden auf C4. Dieses Vorgehen nennt man in Git _rebasing_. Mit der `rebase`-Anweisung kannst Du alle Änderungen, die an einem Branch vorgenommen wurden, auf einen anderen Branch erneut anwenden.
 
 <!--In this example, you’d run the following:-->
 
@@ -792,12 +792,12 @@ In unserem Beispiel würdest Du folgendes ausführen:
 
 <!--It works by going to the common ancestor of the two branches (the one you’re on and the one you’re rebasing onto), getting the diff introduced by each commit of the branch you’re on, saving those diffs to temporary files, resetting the current branch to the same commit as the branch you are rebasing onto, and finally applying each change in turn. Figure 3-29 illustrates this process.-->
 
-Dies funktioniert, indem Git zu dem gemeinsamen Vorfahren [gemeinsamer Vorfahr oder der Ursprung der beiden Branches?] der beiden Branches (des Zweiges auf dem Du arbeitest und des Zweiges auf den Du _rebasen_ möchtest) geht, die Differenzen jedes Commits des aktuellen Branches ermittelt und temporär in einer Datei ablegt. Danach wird der aktuelle Branch auf den Schnittpunkt der beiden Zweige zurückgesetzt und alle zwischengespeicherten Commits nacheinander auf den Zielbranch angewendet. Die Abbildung 3-29 bildet diesen Prozess ab.
+Dies funktioniert, indem Git zum letzten gemeinsamen Vorfahren der beiden Branches (der, auf dem Du arbeitest, und jener, auf den Du _rebasen_ möchtest) geht, dann die Informationen zu den Änderungen (diffs) sammelt, welche seit dem bei jedem einzelen Commit des aktuellen Branches gemacht wurden, diese in temporären Dateien speichert, den aktuellen Branch auf den gleichen Commit setzt wie den Branch, auf den Du _rebasen_ möchtest und dann alle Änderungen erneut durchführt. Die Abbildung 3-29 bildet diesen Prozess ab.
 
 <!--Figure 3-29. Rebasing the change introduced in C3 onto C4.-->
 
 Insert 18333fig0329.png
-Abbildung 3-29. Rebasen der Änderungen durch C3 auf den Zweig C4.
+Abbildung 3-29. Rebasen der in C3 durchgeführten Änderungen auf C4.
 
 <!--At this point, you can go back to the master branch and do a fast-forward merge (see Figure 3-30).-->
 
@@ -818,14 +818,14 @@ Du wirst das häufig anwenden um sicherzustellen, dass sich Deine Commits sauber
 
 <!--Note that the snapshot pointed to by the final commit you end up with, whether it’s the last of the rebased commits for a rebase or the final merge commit after a merge, is the same snapshot — it’s only the history that is different. Rebasing replays changes from one line of work onto another in the order they were introduced, whereas merging takes the endpoints and merges them together.-->
 
-Beachte, dass der Schnappschuss nach dem letzten Commit, ob es der letzte der Rebase-Commits nach einem Rebase oder der finale Merge-Commit nach einem Merge ist, exakt der gleiche ist. Sie unterscheiden sich nur in ihrem Verlauf. Rebasing wiederholt einfach die Änderungen einer Arbeitslinie auf einer anderen, in der Reihenfolge in der sie entstanden sind. Im Gegensatz hierzu nimmt Merging die beiden Endpunkte der Arbeitslinien und führt diese zusammen.
+Beachte, dass der Schnappschuss, welche auf den letzten Commit zeigt, ob es nun der letzte der Rebase-Commits nach einem Rebase oder der finale Merge-Commit nach einem Merge ist, der selbe Schnappschuss ist, nur der Verlauf ist ein anderer. Rebasing wiederholt einfach die Änderungen einer Arbeitslinie auf einer anderen in der Reihenfolge, in der sie entstanden sind. Im Gegensatz hierzu nimmt Merging die beiden Endpunkte der Arbeitslinien und führt diese zusammen.
 
 <!--### More Interesting Rebases ###-->
 ### Mehr interessante Rebases ###
 
 <!--You can also have your rebase replay on something other than the rebase branch. Take a history like Figure 3-31, for example. You branched a topic branch (`server`) to add some server-side functionality to your project, and made a commit. Then, you branched off that to make the client-side changes (`client`) and committed a few times. Finally, you went back to your server branch and did a few more commits.-->
 
-Du kannst Deinen Rebase auch auf einem anderen Branch als dem Rebase-Branch anwenden lassen. Nimm zum Beispiel den Verlauf in Abbildung 3-31. Du hattest einen Themen-Branch (`server`) eröffnet, um ein paar serverseitige Funktionalitäten zu Deinem Projekt hinzuzufügen und einen Commit gemacht. Dann hast Du einen weiteren Branch abgezweigt, um clientseitige Änderungen (`client`) vorzunehmen und dort ein paarmal committed. Zum Schluss hast Du wieder zu Deinem Server-Branch gewechselt und ein paar weitere Commits gebaut.
+Du kannst Deinen Rebase auch auf einem anderen Branch als dem Rebase-Branch anwenden lassen. Nimm zum Beispiel den Verlauf in Abbildung 3-31. Du hattest einen Themen-Branch (`server`) angelegt, um ein paar serverseitige Funktionalitäten zu Deinem Projekt hinzuzufügen, und hast dann einen Commit gemacht. Dann hast Du einen weiteren Branch abgezweigt, um clientseitige Änderungen (`client`) vorzunehmen und dort ein paarmal committed. Zum Schluss hast Du wieder zu Deinem Server-Branch gewechselt und ein paar weitere Commits gebaut.
 
 <!--Figure 3-31. A history with a topic branch off another topic branch.-->
 
@@ -834,7 +834,7 @@ Abbildung 3-31. Ein Verlauf mit einem Themen-Branch basierend auf einem weiteren
 
 <!--Suppose you decide that you want to merge your client-side changes into your mainline for a release, but you want to hold off on the server-side changes until it’s tested further. You can take the changes on client that aren’t on server (C8 and C9) and replay them on your master branch by using the `-\-onto` option of `git rebase`:-->
 
-Stell Dir vor, Du entscheidest Dich, Deine clientseitigen Änderungen für einen Release in die Hauptlinie zu mergen, die serverseitigen Änderungen möchtest Du aber noch zurückhalten, bis sie besser getestet wurden. Du kannst einfach die Änderungen am Client, die den Server nicht betreffen, (C8 und C9) mit der `--onto`-Option von `git rebase` erneut auf den Master-Branch anwenden:
+Angenommen, Du entscheidest Dich, Deine clientseitigen Änderungen für einen Release in die Hauptlinie zu mergen, während Du die serverseitigen Änderungen noch zurückhalten möchtest, bis sie besser getestet wurden. Du kannst einfach die Änderungen am Client, die den Server nicht betreffen, (C8 und C9) mit der `--onto`-Option von `git rebase` erneut auf den Master-Branch anwenden:
 
 	$ git rebase --onto master server client
 
@@ -861,7 +861,7 @@ Abbildung 3-33. Fast-forwarding Deines Master-Branches um die Client-Branch-Änd
 
 <!--Let’s say you decide to pull in your server branch as well. You can rebase the server branch onto the master branch without having to check it out first by running `git rebase [basebranch] [topicbranch]` — which checks out the topic branch (in this case, `server`) for you and replays it onto the base branch (`master`):-->
 
-Lass uns annehmen, Du entscheidest Dich, Deinen Server-Branch ebenfalls einzupflegen. Du kannst den Server-Branch auf den Master-Branch rebasen, ohne diesen vorher auschecken zu müssen, indem Du das Kommando `git rebase [Basis-Branch] [Themen-Branch]` ausführst. Es macht für Dich den Checkout des Themen-Branches (in diesem Fall `server`) und wiederholt ihn auf dem Basis-Branch (`master`):
+Lass uns annehmen, Du entscheidest Dich, Deinen Server-Branch ebenfalls einzupflegen. Du kannst den Server-Branch auf den Master-Branch rebasen, ohne diesen vorher auschecken zu müssen, indem Du die Anweisung `git rebase [Basis-Branch] [Themen-Branch]` ausführst. Sie macht für Dich den Checkout des Themen-Branches (in diesem Fall `server`) und wiederholt ihn auf dem Basis-Branch (`master`):
 
 	$ git rebase master server
 
@@ -883,7 +883,7 @@ Dann kannst Du den Basis-Branch (`master`) fast-forwarden:
 
 <!--You can remove the `client` and `server` branches because all the work is integrated and you don’t need them anymore, leaving your history for this entire process looking like Figure 3-35:-->
 
-Du kannst den `client`- und `server`-Branch nun entfernen, da Du die ganze Arbeit bereits integriert wurde und Sie nicht mehr benötigst. Du hinterlässt den Verlauf für den ganzen Prozess wie in Abbildung 3-35:
+Du kannst den `client`- und `server`-Branch nun entfernen, da Du die ganze Arbeit bereits integriert wurde und sie nicht mehr benötigst. Du hinterlässt den Verlauf für den ganzen Prozess wie in Abbildung 3-35:
 
 	$ git branch -d client
 	$ git branch -d server
@@ -910,7 +910,7 @@ Wenn Du diesem Ratschlag folgst, ist alles in Ordnung. Falls nicht, werden die L
 
 <!--When you rebase stuff, you’re abandoning existing commits and creating new ones that are similar but different. If you push commits somewhere and others pull them down and base work on them, and then you rewrite those commits with `git rebase` and push them up again, your collaborators will have to re-merge their work and things will get messy when you try to pull their work back into yours.-->
 
-Wenn Du Zeug rebased, hebst Du bestehende Commits auf und erstellst stattdessen welche, die zwar ähnlich aber unterschiedlich sind. Wenn Du Commits irgendwohin hochlädst und andere ziehen sich diese herunter und nehmen sie als Grundlage für ihre Arbeit, dann müssen Deine Mitwirkenden ihre Arbeit jedesmal re-mergen, sobald Du Deine Commits mit einem `git rebase` überschreibst und verteilst. Und richtig chaotisch wird's wenn Du versuchst deren Arbeit in Deine Commits zu integrieren.
+Wenn Du Zeug rebased, hebst Du bestehende Commits auf und erstellst stattdessen welche, die zwar ähnlich aber unterschiedlich sind. Wenn Du Commits irgendwohin hochlädst und andere ziehen sich diese herunter und nehmen sie als Grundlage für ihre Arbeit, dann müssen Deine Mitwirkenden ihre Arbeit jedesmal re-mergen, sobald Du Deine Commits mit einem `git rebase` überschreibst und verteilst. Und richtig chaotisch wird es, wenn Du versuchst, deren Arbeit in Deine Commits zu integrieren.
 
 <!--Let’s look at an example of how rebasing work that you’ve made public can cause problems. Suppose you clone from a central server and then do some work off that. Your commit history looks like Figure 3-36.-->
 
@@ -950,11 +950,11 @@ Abbildung 3-39. Du mergst die gleiche Arbeit nochmals in einen neuen Merge-Commi
 
 <!--You have to merge that work in at some point so you can keep up with the other developer in the future. After you do that, your commit history will contain both the C4 and C4' commits, which have different SHA-1 hashes but introduce the same work and have the same commit message. If you run a `git log` when your history looks like this, you’ll see two commits that have the same author date and message, which will be confusing. Furthermore, if you push this history back up to the server, you’ll reintroduce all those rebased commits to the central server, which can further confuse people.-->
 
-Irgendwann musst Du seine Arbeit einmergen, damit Du auch zukünftig mit dem anderen Entwickler zusammenarbeiten kannst. Danach wird Dein Commit-Verlauf sowohl den C4 als auch den C4'-Commit enthalten, welche zwar verschiedene SHA-1-Hashes besitzen, aber die gleichen Änderungen und die gleiche Commit-Beschreibung enthalten. Wenn Du so einen Verlauf mit `git log` betrachtest, wirst Du immer zwei Commits des gleichen Autors, zur gleichen Zeit und mit der gleichen Commit-Nachricht sehen. Was ganz schön verwirrend ist. Wenn Du diesen Verlauf außerdem auf den Server hochlädst, wirst Du dort alle rebasierten Commits einführen, was auch noch andere verwirren kann.
+Irgendwann musst Du seine Arbeit mergen, damit Du auch zukünftig mit dem anderen Entwickler zusammenarbeiten kannst. Danach wird Dein Commit-Verlauf sowohl den C4 als auch den C4'-Commit enthalten, welche zwar verschiedene SHA-1-Hashes besitzen, aber die gleichen Änderungen und die gleiche Commit-Beschreibung enthalten. Wenn Du so einen Verlauf mit `git log` betrachtest, wirst Du immer zwei Commits des gleichen Autors, zur gleichen Zeit und mit der gleichen Commit-Nachricht sehen. Was ganz schön verwirrend sein wird. Wenn Du diesen Verlauf außerdem auf den Server hochlädst, wirst Du dort alle rebasierten Commits nochmals einführen, was die Leute noch mehr verwirren kann.
 
 <!--If you treat rebasing as a way to clean up and work with commits before you push them, and if you only rebase commits that have never been available publicly, then you’ll be fine. If you rebase commits that have already been pushed publicly, and people may have based work on those commits, then you may be in for some frustrating trouble.-->
 
-Wenn Du rebasing als Weg behandelst, um aufzuräumen und mit Commits zu arbeiten, bevor Du sie hochlädst und wenn Du nur Commits rebased, die noch nie publiziert wurden, dann fährst Du goldrichtig. Wenn Du Commits rebased, die bereits veröffentlicht wurden und Leute vielleicht schon ihre Arbeit darauf aufgebaut haben, dann bist Du vielleicht für frustrierenden Ärger verantwortlich.
+Wenn Du rebasing als einen Weg getrachtest, um aufzuräumen und mit Commits zu arbeiten, bevor Du sie hochlädst und wenn Du rebase nur auf Commits anwendest, die noch nie öffentlich zugänglich waren, dann fährst Du goldrichtig. Wenn Du rebase auf Commits anwendest, die bereits veröffentlicht wurden und Leute vielleicht schon ihre Arbeit darauf aufgebaut haben, dann kannst Du Dich auf frustrierenden Ärger gefasst machen.
 
 <!--## Summary ##-->
 ## Zusammenfassung ##

From d4b14239a056f334231f7d5ad407aa529a6d2d39 Mon Sep 17 00:00:00 2001
From: kocio-pl <daniel@xn--ko-wla.pl>
Date: Sat, 4 Apr 2015 22:37:21 +0200
Subject: [PATCH 675/690] gitzk -> gitk

---
 pl/02-git-basics/02-chapter2.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/pl/02-git-basics/02-chapter2.markdown b/pl/02-git-basics/02-chapter2.markdown
index ce2501c0b..a607b9c06 100644
--- a/pl/02-git-basics/02-chapter2.markdown
+++ b/pl/02-git-basics/02-chapter2.markdown
@@ -1121,7 +1121,7 @@ Możesz dzięki niemu łatwo zobaczyć ostatnią rewizję:
 
 Jak można zauważyć, Git zastępuje nowe polecenie czymkolwiek co do niego przypiszesz. Jednakże, możesz chcieć także uruchomić zewnętrzne polecenie zamiast polecenia Gita. Rozpocznij je wówczas znakiem wykrzyknika `!`. Przydaje się to podczas tworzenia własnego narzędzia, które współpracuje z repozytorium Gita. Możemy pokazać to na przykładzie aliasu `git visual` uruchamiającego `gitk`:
 
-	$ git config --global alias.visual "!gitzk"
+	$ git config --global alias.visual "!gitk"
 
 ## Podsumowanie ##
 

From 98fd080218b7929353d94fc4465159a448c3ebc7 Mon Sep 17 00:00:00 2001
From: Peter Dave Hello <hsu@peterdavehello.org>
Date: Sat, 11 Apr 2015 04:42:29 +0800
Subject: [PATCH 676/690] re-translate zh-tw

---
 zh-tw/01-introduction/01-chapter1.markdown    |   2 +-
 zh-tw/02-git-basics/01-chapter2.markdown      | 108 +++----
 zh-tw/03-git-branching/01-chapter3.markdown   | 146 ++++-----
 zh-tw/04-git-server/01-chapter4.markdown      | 282 +++++++++---------
 zh-tw/05-distributed-git/01-chapter5.markdown | 214 ++++++-------
 zh-tw/06-git-tools/01-chapter6.markdown       | 102 +++----
 zh-tw/07-customizing-git/01-chapter7.markdown | 174 +++++------
 .../01-chapter8.markdown                      |  88 +++---
 zh-tw/09-git-internals/01-chapter9.markdown   | 164 +++++-----
 9 files changed, 640 insertions(+), 640 deletions(-)

diff --git a/zh-tw/01-introduction/01-chapter1.markdown b/zh-tw/01-introduction/01-chapter1.markdown
index d594820ea..e215e94f3 100644
--- a/zh-tw/01-introduction/01-chapter1.markdown
+++ b/zh-tw/01-introduction/01-chapter1.markdown
@@ -104,7 +104,7 @@ Git用來計算查核碼的機制稱為SHA-1雜湊法。 它由40個十六進制
 Insert 18333fig0106.png
 圖1-6. 工作目錄、暫存區域及git目錄。
 
-Git目錄是Git用來儲存讀者的專案的元數據及物件資料庫。 這是Git最重要的部份，而且它是當讀者從其它電腦複製儲存庫時會複製過來的。
+Git目錄是Git用來儲存讀者的專案的metadata及物件資料庫。 這是Git最重要的部份，而且它是當讀者從其它電腦複製儲存庫時會複製過來的。
 
 工作目錄是專案被取出的某一個版本。 這些檔案從Git目錄內被壓縮過的資料庫中拉出來並放在磁碟機供讀者使用或修改。
 
diff --git a/zh-tw/02-git-basics/01-chapter2.markdown b/zh-tw/02-git-basics/01-chapter2.markdown
index 52d741749..62062a2eb 100644
--- a/zh-tw/02-git-basics/01-chapter2.markdown
+++ b/zh-tw/02-git-basics/01-chapter2.markdown
@@ -1,18 +1,18 @@
 # Git 基礎 #
 
-讀完這一章，你就可以開始使用Git了。本章節涵蓋大部份最常被使用的Git基本指令。 在讀完本章節後，讀者應該有能力組態及初始化一個儲存庫(repository)、開始及停止追蹤檔案(track)、暫存(stage)及提交(commit)更新。 本章還會提到如何讓Git忽略某些檔案、如何輕鬆且很快地救回失誤、如何瀏覽讀者的專案歷史及觀看各個已提交的更新之間的變更、以及如何從遠端儲存庫`拉`(pull)更新下來或將更新`推`(push)上去。
+讀完這一章，你就可以開始使用Git了。本章節涵蓋大部份最常被使用的Git基本指令。 在讀完本章節後，讀者應該有能力組態及初始化一個版本控制倉庫(repository)、開始及停止追蹤檔案(track)、暫存(stage)及提交(commit)更新。 本章還會提到如何讓Git忽略某些檔案、如何輕鬆且很快地救回失誤、如何瀏覽讀者的專案歷史及觀看各個已提交的更新之間的變更、以及如何從遠端版本控制倉庫`拉`(pull)更新下來或將更新`推`(push)上去。
 
-## 取得Git儲存庫 ##
+## 取得Git版本控制倉庫 ##
 
-讀者可使用兩種主要的方法取得一個Git儲存庫。 第一種是將現有的專案或者目錄匯入Git。 第二種從其它伺服器複製一份已存在的Git儲存庫。
+讀者可使用兩種主要的方法取得一個Git版本控制倉庫。 第一種是將現有的專案或者目錄匯入Git。 第二種從其它伺服器複製一份已存在的Git版本控制倉庫。
 
-### 在現有目錄初始化儲存庫 ###
+### 在現有目錄初始化版本控制倉庫 ###
 
 若讀者要開始使用 Git 追蹤現有的專案，只需要進入該專案的目錄並執行：
 
 	$ git init
 
-這個命令會建立名為 `.git` 的子目錄，該目錄包含一個Git儲存庫架構必要的所有檔案。 目前來說，專案內任何檔案都還沒有被追蹤。（關於.git目錄內有些什麼檔案，可參考第九章）
+這個命令會建立名為 `.git` 的子目錄，該目錄包含一個Git版本控制倉庫架構必要的所有檔案。 目前來說，專案內任何檔案都還沒有被追蹤。（關於.git目錄內有些什麼檔案，可參考第九章）
 
 若讀者想要開始對現有的檔案開始做版本控制（除了空的目錄以外），讀者也許應該開始追蹤這些檔案並做第一次的提交。 讀者能以少數的git add命令指定要追蹤的檔案，並將它們提交：
 
@@ -20,29 +20,29 @@
 	$ git add README
 	$ git commit -m 'initial project version'
 
-這些命令執行完畢大約只需要一分鐘。 現在，讀者已經有個追蹤部份檔案及第一次提交內容的Git儲存庫。
+這些命令執行完畢大約只需要一分鐘。 現在，讀者已經有個追蹤部份檔案及第一次提交內容的Git版本控制倉庫。
 
-### 複製現有的儲存庫 ###
+### 複製現有的版本控制倉庫 ###
 
-若讀者想要取得現有的Git儲存庫的複本（例如：讀者想要散佈的），那需要使用的命令是 `git clone`。 若讀者熟悉其它版本控制系統，例如：Subversion，讀者應該注意這個命令是複製(clone)，而不是取出特定版本(checkout)。 這一點非常重要，Git取得的是大部份伺服器端所有的資料複本。 該專案歷史中所有檔案的所有版本都在讀者執行過 `git clone` 後拉回來。 事實上，若伺服器的磁碟機損毀，讀者可使用任何一個客戶端的複本還原伺服器為當初取得該複本的狀態（讀者可能會遺失一些僅存於伺服器的攔截程式，不過所有版本的資料都健在），參考第四章取得更多資訊。
+若讀者想要取得現有的Git版本控制倉庫的複本（例如：讀者想要散佈的），那需要使用的命令是 `git clone`。 若讀者熟悉其它版本控制系統，例如：Subversion，讀者應該注意這個命令是複製(clone)，而不是取出特定版本(checkout)。 這一點非常重要，Git取得的是大部份伺服器端所有的資料複本。 該專案歷史中所有檔案的所有版本都在讀者執行過 `git clone` 後拉回來。 事實上，若伺服器的磁碟機損毀，讀者可使用任何一個客戶端的複本還原伺服器為當初取得該複本的狀態（讀者可能會遺失一些僅存於伺服器的攔截程式，不過所有版本的資料都健在），參考第四章取得更多資訊。
 
-讀者可以 `git clone [url]`，複製一個儲存庫。 例如：若讀者想複製名為Grit的Ruby Git程式庫，可以執行下列命令：
+讀者可以 `git clone [url]`，複製一個版本控制倉庫。 例如：若讀者想複製名為Grit的Ruby Git程式庫，可以執行下列命令：
 
 	$ git clone git://github.com/schacon/grit.git
 
-接下來會有個名為`grit`的目錄被建立，並在其下初始化名為`.git`的目錄。 拉下所有存在該儲存庫的所有資料，並取出最新版本為工作複本。 若讀者進入新建立的 `grit` 目錄，會看到專案的檔案都在這兒，且可使用。 若讀者想要複製儲存庫到grit以外其它名字的目錄，只需要在下一個參數指定即可：
+接下來會有個名為`grit`的目錄被建立，並在其下初始化名為`.git`的目錄。 拉下所有存在該版本控制倉庫的所有資料，並取出最新版本為工作複本。 若讀者進入新建立的 `grit` 目錄，會看到專案的檔案都在這兒，且可使用。 若讀者想要複製版本控制倉庫到grit以外其它名字的目錄，只需要在下一個參數指定即可：
 
 	$ git clone git://github.com/schacon/grit.git mygrit
 
 這個命令做的事大致如同上一個命令，只不過目的目錄名為mygrit。
 
-Git提供很多種協定給讀者使用。 上一個範例採用 `git://` 協定，讀者可能會看過 `http(s)://` 或者 `user@server:/path.git` 等使用 SSH 傳輸的協定。 在第四章會介紹設定存取伺服器上的 Git 儲存庫的所有可用的選項，以及它們的優點及缺點。
+Git提供很多種協定給讀者使用。 上一個範例採用 `git://` 協定，讀者可能會看過 `http(s)://` 或者 `user@server:/path.git` 等使用 SSH 傳輸的協定。 在第四章會介紹設定存取伺服器上的 Git 版本控制倉庫的所有可用的選項，以及它們的優點及缺點。
 
-## 提交更新到儲存庫 ##
+## 提交更新到版本控制倉庫 ##
 
-讀者現在有一個貨真價實的Git儲存庫，而且有一份已放到工作複本的該專案的檔案。 讀者需要做一些修改並提交這些更動的快照到儲存庫，當這些修改到達讀者想要記錄狀態的情況。
+讀者現在有一個貨真價實的Git版本控制倉庫，而且有一份已放到工作複本的該專案的檔案。 讀者需要做一些修改並提交這些更動的快照到版本控制倉庫，當這些修改到達讀者想要記錄狀態的情況。
 
-記住工作目錄內的每個檔案可能為兩種狀態的任一種：追蹤或者尚未被追蹤。 被追蹤的檔案是最近的快照；它們可被復原、修改，或者暫存。 未被追蹤的檔案則是其它未在最近快照也未被暫存的任何檔案。 當讀者第一次複製儲存器時，讀者所有檔案都是被追蹤且未被修改的。 因為讀者剛取出它們而且尚未更改做任何修改。
+記住工作目錄內的每個檔案可能為兩種狀態的任一種：追蹤或者尚未被追蹤。 被追蹤的檔案是最近的快照；它們可被復原、修改，或者暫存。 未被追蹤的檔案則是其它未在最近快照也未被暫存的任何檔案。 當讀者第一次複製保存器時，讀者所有檔案都是被追蹤且未被修改的。 因為讀者剛取出它們而且尚未更改做任何修改。
 
 只要讀者編輯任何已被追蹤的檔案。 Git將它們視為被更動的，因為讀者將它們改成與最後一次提交不同。 讀者暫存這些已更動檔案並提供所有被暫存的更新， 並重複此週期。 此生命週期如圖2-1所示。
 
@@ -93,7 +93,7 @@ Wokring directory clean意謂著目前的工作目錄沒有未被追蹤或已被
 
 ### 暫存已修改檔案 ###
 
-讓我們修改已被追蹤的檔案。 若讀者修改先前已被追蹤的檔案，名為`benchmarks.rb`，並檢查目前儲存庫的狀態。我們會看到類似以下文字：
+讓我們修改已被追蹤的檔案。 若讀者修改先前已被追蹤的檔案，名為`benchmarks.rb`，並檢查目前版本控制倉庫的狀態。我們會看到類似以下文字：
 
 	$ git status
 	On branch master
@@ -159,7 +159,7 @@ Wokring directory clean意謂著目前的工作目錄沒有未被追蹤或已被
 	*.[oa]
 	*~
 
-第一列告訴Git忽略任何檔名為`.o`或`.a`結尾的檔案，它們是可能是編譯系統建置讀者的程式碼時產生的目的檔及程式庫。 第二列告訴Git忽略所有檔名為~結尾的檔案，通常被很多文書編輯器，如：Emacs，使用的暫存檔案。 讀者可能會想一併將log、tmp、pid目錄及自動產生的文件等也一併加進來。 依據類推。在讀者要開始開發之前將`.gitignore`設定好，通常是一個不錯的點子。這樣子讀者不會意外地將真的不想追蹤的檔案提交到Git儲存庫。
+第一列告訴Git忽略任何檔名為`.o`或`.a`結尾的檔案，它們是可能是編譯系統建置讀者的程式碼時產生的目的檔及程式庫。 第二列告訴Git忽略所有檔名為~結尾的檔案，通常被很多文書編輯器，如：Emacs，使用的暫存檔案。 讀者可能會想一併將log、tmp、pid目錄及自動產生的文件等也一併加進來。 依據類推。在讀者要開始開發之前將`.gitignore`設定好，通常是一個不錯的點子。這樣子讀者不會意外地將真的不想追蹤的檔案提交到Git版本控制倉庫。
 
 編寫`.gitignore`檔案的規則如下：
 
@@ -299,7 +299,7 @@ A `**/` pattern is available in Git since version 1.8.2.
 
 ### 提交修改 ###
 
-現在讀者的暫存區域已被更新為讀者想要的，可開始提交變更的部份。 要記得任何尚未被暫存的新建檔案或已被修改但尚未使用git add暫存的檔案將不會被記錄在本次的提交中。 它們仍會以被修改的檔案的身份存在磁碟中。
+現在讀者的暫存區域已被更新為讀者想要的，可開始提交變更的部份。 要記得任何尚未被暫存的新增檔案或已被修改但尚未使用git add暫存的檔案將不會被記錄在本次的提交中。 它們仍會以被修改的檔案的身份存在磁碟中。
 在這情況下，最後一次執行`git status`，讀者會看到所有已被暫存的檔案，讀者也準備好要提交修改。 最簡單的提交是執行`git commit`：
 
 	$ git commit
@@ -399,13 +399,13 @@ A `**/` pattern is available in Git since version 1.8.2.
 
 ### 搬動檔案 ###
 
-Git並不像其它檔案控制系統一樣，明確地追蹤檔案的移動。 若將被Git追蹤的檔名更名，並沒有任何元數據儲存在Git中去標示此更名動作。 然而Git能很聰明地指出這一點。 稍後會介紹關於偵測檔案的搬動。
+Git並不像其它檔案控制系統一樣，明確地追蹤檔案的移動。 若將被Git追蹤的檔名重新命名，並沒有任何metadata保存在Git中去標示此重新命名動作。 然而Git能很聰明地指出這一點。 稍後會介紹關於偵測檔案的搬動。
 
-因此Git存在`mv`這個指令會造成一點混淆。 若想要在Git中更名某個檔案，可執行以下命令：
+因此Git存在`mv`這個指令會造成一點混淆。 若想要在Git中重新命名某個檔案，可執行以下命令：
 
 	$ git mv file_from file_to
 
-而且這命令可正常工作。 事實上，在執行完更名的動作後檢視一下狀態。 可看到Git認為該檔案被更名：
+而且這命令可正常工作。 事實上，在執行完重新命名的動作後檢視一下狀態。 可看到Git認為該檔案被重新命名：
 
 	$ git mv README.txt README
 	$ git status
@@ -422,13 +422,13 @@ Git並不像其它檔案控制系統一樣，明確地追蹤檔案的移動。 
 	$ git rm README.txt
 	$ git add README
 
-Git會在背後判斷檔案是否被更名，因此不管是用上述方法還是'mv'命令都沒有差別。 實際上唯一不同的是'mv'是一個命令，而不是三個。 使用上較方便。 更重要的是讀者可使用任何慣用的工具更名，再使用add/rm，接著才提交。
+Git會在背後判斷檔案是否被重新命名，因此不管是用上述方法還是'mv'命令都沒有差別。 實際上唯一不同的是'mv'是一個命令，而不是三個。 使用上較方便。 更重要的是讀者可使用任何慣用的工具重新命名，再使用add/rm，接著才提交。
 
 ## 檢視提交的歷史記錄 ##
 
-在提交數個更新，或者複製已有一些歷史記錄的儲存庫後。 或許會想希望檢視之前發生過什麼事。 最基本也最具威力的工具就是 `git log` 命令。
+在提交數個更新，或者複製已有一些歷史記錄的版本控制倉庫後。 或許會想希望檢視之前發生過什麼事。 最基本也最具威力的工具就是 `git log` 命令。
 
-以下採用非常簡單，名為 `simplegit` 的專案做展示。 欲取得此專案，執行以下命令：
+以下採用非常簡單，名為 `simplegit` 的專案做示範。 欲取得此專案，執行以下命令：
 
 	git clone git://github.com/schacon/simplegit-progit.git
 
@@ -453,7 +453,7 @@ Git會在背後判斷檔案是否被更名，因此不管是用上述方法還
 
 	    first commit
 
-在未加任何參數情況下，`git log`以新到舊的順序列出儲存庫的提交的歷史記錄。 也就是說最新的更新會先被列出來。 同時也會列出每個更新的 SHA-1 查核值、作者大名及電子郵件地址、及提交時輸入的訊息。
+在未加任何參數情況下，`git log`以新到舊的順序列出版本控制倉庫的提交的歷史記錄。 也就是說最新的更新會先被列出來。 同時也會列出每個更新的 SHA-1 查核值、作者大名及電子郵件地址、及提交時輸入的訊息。
 
 `git log`命令有很多樣化的選項，供讀者精確指出想搜尋的結果。 接下來會介紹一些常用的選項。
 
@@ -553,7 +553,7 @@ Git會在背後判斷檔案是否被更名，因此不管是用上述方法還
 	 lib/simplegit.rb |   25 +++++++++++++++++++++++++
 	 3 files changed, 54 insertions(+)
 
-如以上所示，`--stat`選項在每個更新項目的下方列出被更動的檔案、有多少檔案被更動，以及有多行列被加入或移出該檔案。 也會在最後印出摘要的訊息。
+如以上所示，`--stat`選項在每個更新專案的下方列出被更動的檔案、有多少檔案被更動，以及有多行列被加入或移出該檔案。 也會在最後印出摘要的訊息。
 其它實用的選項是 `--pretty`。 這個選項改變原本預設輸出的格式。 有數個內建的選項供讀者選用。 其中 `oneline` 選項將每一個更新印到單獨一行，對於檢視很多更新時很有用。 更進一步，`short`、`full`、`fuller` 選項輸出的格式大致相同，但會少一些或者多一些資訊。
 
 	$ git log --pretty=oneline
@@ -594,7 +594,7 @@ The lines must be formatted as follows
 
 讀者可能會好奇 __作者__ 與 __提交者__ 之間的差別。 __作者__ 是完成該工作的人，而 __提交者__ 則是最後將該工作提交出來的人。 因此，若讀者將某個專案的修補檔送出，而且該專案的核心成員中一員套用該更新，則讀者與該成員皆會被列入該更新。 讀者即 __作者__，而該成員則是 __提交者__。 在第五章會提到較多之間的差別。
 
-`oneline` 及 `format` 選項對於另一個名為 `--graph` 的選項特別有用。 該選項以 ASCII 畫出分支的分歧及合併的歷史。 可參考我們的 Grit 的儲存庫：
+`oneline` 及 `format` 選項對於另一個名為 `--graph` 的選項特別有用。 該選項以 ASCII 畫出分支的分歧及合併的歷史。 可參考我們的 Grit 的版本控制倉庫：
 
 	$ git log --pretty=format:"%h %s" --graph
 	* 2d3acf9 ignore errors from SIGCHLD on trap
@@ -704,7 +704,7 @@ Insert 18333fig0202.png
 
 ### 取消已被暫存的檔案 ###
 
-接下來兩節展示如何應付暫存區及工作目錄的復原。 用來判斷這兩個區域狀態的命令也以相當好的方式提示如何復原。 比如說已經修改兩個檔案，並想要以兩個不同的更新提交它們，不過不小心執行 `git add *` 將它們同時都加入暫存區。 應該如何將其中一個移出暫存區？ `git status` 命令已附上相關的提示：
+接下來兩節示範如何應付暫存區及工作目錄的復原。 用來判斷這兩個區域狀態的命令也以相當好的方式提示如何復原。 比如說已經修改兩個檔案，並想要以兩個不同的更新提交它們，不過不小心執行 `git add *` 將它們同時都加入暫存區。 應該如何將其中一個移出暫存區？ `git status` 命令已附上相關的提示：
 
 	$ git add .
 	$ git status
@@ -739,7 +739,7 @@ Insert 18333fig0202.png
 
 ### 復原已被更動的檔案 ###
 
-若讀者發現其者並不需要保留 `benchmarks.rb` 檔案被更動部份，應該如何做才能很容易的復原為最後一次提交的狀態（或者最初複製儲存庫時、或放到工作目錄時的版本）？ 很幸運的，`git status` 同樣也告訴讀者如何做。 在最近一次檢視狀態時，暫存區看起來應如下所示：
+若讀者發現其者並不需要保留 `benchmarks.rb` 檔案被更動部份，應該如何做才能很容易的復原為最後一次提交的狀態（或者最初複製版本控制倉庫時、或放到工作目錄時的版本）？ 很幸運的，`git status` 同樣也告訴讀者如何做。 在最近一次檢視狀態時，暫存區看起來應如下所示：
 
 	Changes not staged for commit:
 	  (use "git add <file>..." to update what will be committed)
@@ -748,7 +748,7 @@ Insert 18333fig0202.png
 	        modified:   benchmarks.rb
 	
 
-在這訊息中已很明確的說明如何拋棄所做的修改（至少需升級為 Git 1.6.1或更新版本。 若讀者使用的是舊版，強烈建議升級，以取得更好用的功能。） 讓我們依據命令執行：
+在這訊息中已很明確的說明如何放棄所做的修改（至少需升級為 Git 1.6.1或更新版本。 若讀者使用的是舊版，強烈建議升級，以取得更好用的功能。） 讓我們依據命令執行：
 
 	$ git checkout -- benchmarks.rb
 	$ git status
@@ -765,12 +765,12 @@ Insert 18333fig0202.png
 
 ## 與遠端協同工作 ##
 
-想要在任何Git控管的專案協同作業，需要瞭解如何管理遠端的儲存庫。 遠端儲存庫是置放在網際網路或網路其它地方中的專案版本。 讀者可設定多個遠端儲存庫，具備唯讀或可讀寫的權限。 與他人協同作業時，需要管理這些遠端儲存庫，並在需要分享工作時上傳或下載資料。
-管理遠端儲存庫包含瞭解如何新增遠端儲存庫、移除已失效的儲存庫、管理許多分支及定義是否要追蹤它們等等。 本節包含如何遠端管理的技巧。
+想要在任何Git控管的專案協同作業，需要瞭解如何管理遠端的版本控制倉庫。 遠端版本控制倉庫是置放在網際網路或網路其它地方中的專案版本。 讀者可設定多個遠端版本控制倉庫，具備唯讀或可讀寫的權限。 與他人協同作業時，需要管理這些遠端版本控制倉庫，並在需要分享工作時上傳或下載資料。
+管理遠端版本控制倉庫包含瞭解如何新增遠端版本控制倉庫、移除已失效的版本控制倉庫、管理許多分支及定義是否要追蹤它們等等。 本節包含如何遠端管理的技巧。
 
-### 顯示所有的遠端儲存庫 ###
+### 顯示所有的遠端版本控制倉庫 ###
 
-欲瞭解目前已加進來的遠端儲存庫，可執行 `git remote` 命令。 它會列出當初加入遠端儲存庫時指定的名稱。 若目前所在儲存庫是從其它儲存庫複製過來的，至少應該看到 *origin*，也就是 Git 複製儲存庫時預設名字：
+欲瞭解目前已加進來的遠端版本控制倉庫，可執行 `git remote` 命令。 它會列出當初加入遠端版本控制倉庫時指定的名稱。 若目前所在版本控制倉庫是從其它版本控制倉庫複製過來的，至少應該看到 *origin*，也就是 Git 複製版本控制倉庫時預設名字：
 
 	$ git clone git://github.com/schacon/ticgit.git
 	Cloning into 'ticgit'...
@@ -789,7 +789,7 @@ Insert 18333fig0202.png
 	origin  git://github.com/schacon/ticgit.git (fetch)
 	origin  git://github.com/schacon/ticgit.git (push)
 
-若有一個以上遠端儲存庫，此命令會全部列出。 例如：我的 Grit 儲存庫包含以下遠端儲存庫。
+若有一個以上遠端版本控制倉庫，此命令會全部列出。 例如：我的 Grit 版本控制倉庫包含以下遠端版本控制倉庫。
 
 	$ cd grit
 	$ git remote -v
@@ -799,11 +799,11 @@ Insert 18333fig0202.png
 	koke      git://github.com/koke/grit.git
 	origin    git@github.com:mojombo/grit.git
 
-這意謂著我可以很容易從這些伙伴的儲存庫取得最新的更新。 要留意的是只有 origin 遠端的 URL 是 SSH。 因此它是唯一我能上傳的遠端的儲存庫。（關於這部份將在第四章介紹） 
+這意謂著我可以很容易從這些伙伴的版本控制倉庫取得最新的更新。 要留意的是只有 origin 遠端的 URL 是 SSH。 因此它是唯一我能上傳的遠端的版本控制倉庫。（關於這部份將在第四章介紹） 
 
-### 新增遠端儲存庫 ###
+### 新增遠端版本控制倉庫 ###
 
-在先前章節已提到並示範如何新增遠端儲存庫，這邊會很明確的說明如何做這項工作。 欲新增遠端儲存庫並取一個簡短的名字，執行 `git remote add [shortname] [url]`： 
+在先前章節已提到並示範如何新增遠端版本控制倉庫，這邊會很明確的說明如何做這項工作。 欲新增遠端版本控制倉庫並取一個簡短的名字，執行 `git remote add [shortname] [url]`： 
 
 	$ git remote
 	origin
@@ -812,7 +812,7 @@ Insert 18333fig0202.png
 	origin	git://github.com/schacon/ticgit.git
 	pb	git://github.com/paulboone/ticgit.git
 
-現在可看到命令列中的 `pb` 字串取代了整個 URL。 例如，若想取得 Paul 上傳的且本地端儲存庫沒有的更新，可執行 `git fetch pb`：
+現在可看到命令列中的 `pb` 字串取代了整個 URL。 例如，若想取得 Paul 上傳的且本地端版本控制倉庫沒有的更新，可執行 `git fetch pb`：
 
 	$ git fetch pb
 	remote: Counting objects: 58, done.
@@ -825,7 +825,7 @@ Insert 18333fig0202.png
 
 現在可在本地端使用 `pb/master` 存取 Paul 的 master 分支。 讀者可將它合併到本地端任一分支、或者建立一個本地端的分支指向它，如果讀者想監看它。
 
-### 從遠端儲存庫擷取或合併 ###
+### 從遠端版本控制倉庫擷取或合併 ###
 
 如剛才所示，欲從遠端擷取資料，可執行：
 
@@ -833,21 +833,21 @@ Insert 18333fig0202.png
 
 此命令到該遠端專案將所有本地端沒有的資料拉下來。 在執行此動作後，讀者應該有參考到該遠端專案所有分支的參考點，可在任何時間點用來合併或監看。（在第三章將會提及更多關於如何使用分支的細節）
 
-若複製了一個儲存庫，會自動將該遠端儲存庫命令為 *origin*。 因此 `git fetch origin` 取出所有在複製或最後一下擷取後被上傳到該儲存庫的更新。 需留意的是 `fetch` 命令僅僅將資料拉到本地端的儲存庫，並未自動將它合併進來，也沒有修改任何目前工作的項目。 讀者得在必要時將它們手動合併進來。
+若複製了一個版本控制倉庫，會自動將該遠端版本控制倉庫命令為 *origin*。 因此 `git fetch origin` 取出所有在複製或最後一下擷取後被上傳到該版本控制倉庫的更新。 需留意的是 `fetch` 命令僅僅將資料拉到本地端的版本控制倉庫，並未自動將它合併進來，也沒有修改任何目前工作的專案。 讀者得在必要時將它們手動合併進來。
 
-若讀者設定一個會追蹤遠端分支的分支（參考下一節及第三章，取得更多資料），可使用 `git pull` 命令自動擷取及合併遠端分支到目錄的分支。 這對讀者來說或許是較合適的工作流程。 而且 `git clone` 命令預設情況下會自動設定本地端的 master 分支追蹤被複製的遠端儲存庫的 master 分支。（假設該儲存庫有 master 分支） 執行 `git pull` 一般來說會從當初複製時的來源儲存庫擷取資料並自動試著合併到目前工作的版本。
+若讀者設定一個會追蹤遠端分支的分支（參考下一節及第三章，取得更多資料），可使用 `git pull` 命令自動擷取及合併遠端分支到目錄的分支。 這對讀者來說或許是較合適的工作流程。 而且 `git clone` 命令預設情況下會自動設定本地端的 master 分支追蹤被複製的遠端版本控制倉庫的 master 分支。（假設該版本控制倉庫有 master 分支） 執行 `git pull` 一般來說會從當初複製時的來源版本控制倉庫擷取資料並自動試著合併到目前工作的版本。
 
-### 上傳到遠端儲存庫 ###
+### 上傳到遠端版本控制倉庫 ###
 
 當讀者有想分享出去的專案，可將更新上傳到上游。 執行此動作的命令很簡單：`git push [remote-name] [branch-name]`。 若想要上傳 master 分支到 `origin` 伺服器（再說一次，複製時通常自動設定此名字），接著執行以下命令即可上傳到伺服器：
 
 	$ git push origin master
 
-此命令只有在被複製的伺服器開放寫入權限給使用者，而且同一時間內沒有其它人在上傳。 若讀者在其它同樣複製該伺服器的使用者上傳一些更新後上傳到上游，該上傳動作將會被拒絕。 讀者必須先將其它使用者上傳的資料拉下來並整合進來後才能上傳。 參考第三章瞭解如何上傳到遠端儲存庫的細節。
+此命令只有在被複製的伺服器開放寫入權限給使用者，而且同一時間內沒有其它人在上傳。 若讀者在其它同樣複製該伺服器的使用者上傳一些更新後上傳到上游，該上傳動作將會被拒絕。 讀者必須先將其它使用者上傳的資料拉下來並整合進來後才能上傳。 參考第三章瞭解如何上傳到遠端版本控制倉庫的細節。
 
-### 監看遠端儲存庫 ###
+### 監看遠端版本控制倉庫 ###
 
-若讀者想取得遠端儲存庫某部份更詳盡的資料，可執行 `git remote show [remote-name]`。 若執行此命令時加上特定的遠端名字，比如說： `origin`。 會看到類似以下輸出：
+若讀者想取得遠端版本控制倉庫某部份更詳盡的資料，可執行 `git remote show [remote-name]`。 若執行此命令時加上特定的遠端名字，比如說： `origin`。 會看到類似以下輸出：
 
 	$ git remote show origin
 	* remote origin
@@ -858,7 +858,7 @@ Insert 18333fig0202.png
 	    master
 	    ticgit
 
-它將同時列出遠端儲存庫的URL位置和追蹤分支資訊。特別是告訴你如果你在master分支時用`git pull`時，會去自動抓取數據合併到本地的master分支。它也列出所有曾經被抓取過的遠端分支。
+它將同時列出遠端版本控制倉庫的URL位置和追蹤分支資訊。特別是告訴你如果你在master分支時用`git pull`時，會去自動抓取數據合併到本地的master分支。它也列出所有曾經被抓取過的遠端分支。
 
 當你使用Git更頻繁之後，你或許會想利用 `git remote show` 去看到更多的資訊。
 
@@ -886,9 +886,9 @@ Insert 18333fig0202.png
 
 這個指令顯示當你執行`git push`會自動推送的哪個分支(最後兩行)。它也顯示哪些遠端分支還沒被同步到本地端(在這個例子是caching)，哪些已同步到本地的遠端分支在遠端已被刪除(libwalker和walker2)，以及當執行`git pull`時會自動被合併的分支。
 
-### 移除或更名遠端儲存庫 ###
+### 移除或重新命名遠端版本控制倉庫 ###
 
-在新版 Git 中可以用 `git remote rename` 命令修改某個遠端儲存庫在本地的簡稱，舉例而言，想把 `pb` 改成 `paul`，可以執行下列指令：
+在新版 Git 中可以用 `git remote rename` 命令修改某個遠端版本控制倉庫在本地的簡稱，舉例而言，想把 `pb` 改成 `paul`，可以執行下列指令：
 
 
 	$ git remote rename pb paul
@@ -919,7 +919,7 @@ Insert 18333fig0202.png
 
 這個指令將以字母順序列出標籤；所以這個順序並不代表其重要性。
 
-你也可以用特定的字串規則去搜尋標籤。以Git本身的儲存庫為例，其中包含超過240個標籤。當你只對1.4.2感興趣時，你可以執行以下指令：
+你也可以用特定的字串規則去搜尋標籤。以Git本身的版本控制倉庫為例，其中包含超過240個標籤。當你只對1.4.2感興趣時，你可以執行以下指令：
 
 	$ git tag -l 'v1.4.2.*'
 	v1.4.2.1
@@ -1085,7 +1085,7 @@ Git使用兩大類的標籤：輕量級(lightweight)和含附註(annotated)。
 
 ### 分享標籤 ###
 
-在預設的情況下，`git push`指令並不會將標籤傳到遠端伺服器上。當建立新標籤後，你必須特別下指令才會將它推送到遠端儲存庫上。類似將分支推送到遠端的過程，透過`git push origin [tagname]`指令。
+在預設的情況下，`git push`指令並不會將標籤傳到遠端伺服器上。當建立新標籤後，你必須特別下指令才會將它推送到遠端版本控制倉庫上。類似將分支推送到遠端的過程，透過`git push origin [tagname]`指令。
 
 	$ git push origin v1.5
 	Counting objects: 50, done.
@@ -1109,7 +1109,7 @@ Git使用兩大類的標籤：輕量級(lightweight)和含附註(annotated)。
 	 * [new tag]         v1.4-lw -> v1.4-lw
 	 * [new tag]         v1.5 -> v1.5
 
-現在，當其他使用者clone或pull你的儲存庫時，他們也同時會取得所有你的標籤。
+現在，當其他使用者clone或pull你的版本控制倉庫時，他們也同時會取得所有你的標籤。
 
 ## 提示和技巧 ##
 
@@ -1121,7 +1121,7 @@ Git使用兩大類的標籤：輕量級(lightweight)和含附註(annotated)。
 
 	source ~/git-completion.bash
 
-如果你想為所有使用者都自動設置Bash shell的補齊功能，在Mac系統上將這個腳本複製到`/opt/local/etc/bash_completion.d`目錄，若你使用Linux系統複製到 `/etc/bash_completion.d/`目錄。這兩個目錄中的脚本，都會在 Bash 啟動時自動載入。
+如果你想為所有使用者都自動設定Bash shell的補齊功能，在Mac系統上將這個腳本複製到`/opt/local/etc/bash_completion.d`目錄，若你使用Linux系統複製到 `/etc/bash_completion.d/`目錄。這兩個目錄中的脚本，都會在 Bash 啟動時自動載入。
 
 如果你在Windows使用Git Bash，也就是利用Windows with msysGit安裝Git，自動補齊功能已預先設定好，可以直接使用。
 
@@ -1174,10 +1174,10 @@ Git使用兩大類的標籤：輕量級(lightweight)和含附註(annotated)。
 
 	    Signed-off-by: Scott Chacon <schacon@example.com>
 
-你可以發現，Git只是簡單地在命令中替換你設定的別名。然而，你不僅希望執行Git 的子命令，而想執行外部命令。在這個情形中，你可以加入`!`字元在所要執行的命令前。這將有助於設計運作於Git儲存庫的自製工具。這個範例藉由設定`git visual`別名去執行`gitk`：
+你可以發現，Git只是簡單地在命令中替換你設定的別名。然而，你不僅希望執行Git 的子命令，而想執行外部命令。在這個情形中，你可以加入`!`字元在所要執行的命令前。這將有助於設計運作於Git版本控制倉庫的自製工具。這個範例藉由設定`git visual`別名去執行`gitk`：
 
 	$ git config --global alias.visual '!gitk'
 
 ## 總結 ##
 
-至此，讀者已具備所有Git的本地端操作，包括：創建和複製儲存庫、建立修改、暫存和提交這些修改，以及檢視在儲存庫中所有修改歷史。接下來，我們將觸及Git的殺手級特性，也就是他的分支模型。
+至此，讀者已具備所有Git的本地端操作，包括：建立和複製版本控制倉庫、建立修改、暫存和提交這些修改，以及檢視在版本控制倉庫中所有修改歷史。接下來，我們將觸及Git的殺手級特性，也就是他的分支模型。
diff --git a/zh-tw/03-git-branching/01-chapter3.markdown b/zh-tw/03-git-branching/01-chapter3.markdown
index a4fe6b5e8..132fe4097 100644
--- a/zh-tw/03-git-branching/01-chapter3.markdown
+++ b/zh-tw/03-git-branching/01-chapter3.markdown
@@ -1,21 +1,21 @@
 # Git 分支 #
 
-幾乎每一種版本控制系統都以某種形式支援分支。使用分支意味著你可以從開發主線上分離開來，然後在不影響主線的同時繼續工作。在很多版本控制系統中，這是個昂貴的過程，常常需要創建一個原始程式碼目錄的完整副本，對大型項目來說會花費很長時間。
+幾乎每一種版本控制系統都以某種形式支援分支。使用分支意味著你可以從開發主線上分離開來，然後在不影響主線的同時繼續工作。在很多版本控制系統中，這是個昂貴的過程，常常需要建立一個原始程式碼目錄的完整副本，對大型專案來說會花費很長時間。
 
-有人把 Git 的分支模型稱為“必殺技特性”，而正是因為它，將 Git 從版本控制系統家族裡區分出來。Git 有何特別之處呢？Git 的分支可謂是難以置信的羽量級，它的新建操作幾乎可以在瞬間完成，並且在不同分支間切換起來也差不多一樣快。和許多其他版本控制系統不同，Git 鼓勵在工作流程中頻繁使用分支與合併，哪怕一天之內進行許多次都沒有關係。理解分支的概念並熟練運用後，你才會意識到為什麼 Git 是一個如此強大而獨特的工具，並從此真正改變你的開發方式。
+有人把 Git 的分支模型稱為“必殺技特性”，而正是因為它，將 Git 從版本控制系統家族裡區分出來。Git 有何特別之處呢？Git 的分支可謂是難以置信的羽量級，它的新增操作幾乎可以在瞬間完成，並且在不同分支間切換起來也差不多一樣快。和許多其他版本控制系統不同，Git 鼓勵在工作流程中頻繁使用分支與合併，哪怕一天之內進行許多次都沒有關係。理解分支的概念並熟練運用後，你才會意識到為什麼 Git 是一個如此強大而獨特的工具，並從此真正改變你的開發方式。
 
 ## 何謂分支 ##
 
-為了理解 Git 分支的實現方式，我們需要回顧一下 Git 是如何儲存資料的。或許你還記得第一章的內容，Git 保存的不是檔差異或者變化量，而只是一系列檔快照。
+為了理解 Git 分支的實現方式，我們需要回顧一下 Git 是如何保存資料的。或許你還記得第一章的內容，Git 保存的不是檔差異或者變化量，而只是一系列檔快照。
 
 在 Git 中提交時，會保存一個提交（commit）物件，該物件包含一個指向暫存內容快照的指標，包含本次提交的作者等相關附屬資訊，包含零個或多個指向該提交物件的父物件指標：首次提交是沒有直接祖先的，普通提交有一個祖先，由兩個或多個分支合併產生的提交則有多個祖先。
 
-為直觀起見，我們假設在工作目錄中有三個檔，準備將它們暫存後提交。暫存操作會對每一個檔計算校驗和（即第一章中提到的 SHA-1 雜湊字串），然後把當前版本的檔快照保存到 Git 倉庫中（Git 使用 blob 類型的物件存儲這些快照），並將校驗和加入暫存區域：
+為直觀起見，我們假設在工作目錄中有三個檔案，準備將它們暫存後提交。暫存操作會對每一個檔計算雜湊值（即第一章中提到的 SHA-1 雜湊字串），然後把目前版本的檔快照保存到 Git 倉庫中（Git 使用 blob 類型的物件存儲這些快照），並將雜湊值加入暫存區域：
 
 	$ git add README test.rb LICENSE
 	$ git commit -m 'initial commit of my project'
 
-當使用 `git commit` 新建一個提交物件前，Git 會先計算每一個子目錄（本例中就是專案根目錄）的校驗和，然後在 Git 倉庫中將這些目錄保存為樹（tree）物件。之後 Git 創建的提交物件，除了包含相關提交資訊以外，還包含著指向這個樹物件（專案根目錄）的指標，如此它就可以在將來需要的時候，重現此次快照的內容了。
+當使用 `git commit` 新建一個提交物件前，Git 會先計算每一個子目錄（本例中就是專案根目錄）的雜湊值，然後在 Git 倉庫中將這些目錄保存為樹（tree）物件。之後 Git 建立的提交物件，除了包含相關提交資訊以外，還包含著指向這個樹物件（專案根目錄）的指標，如此它就可以在將來需要的時候，重現此次快照的內容了。
 
 現在，Git 倉庫中有五個物件：三個表示檔快照內容的 blob 物件；一個記錄著目錄樹內容及其中各個檔對應 blob 物件索引的 tree 物件；以及一個包含指向 tree 物件（根目錄）的索引和其他提交資訊中繼資料的 commit 物件。概念上來說，倉庫中的各個物件保存的資料和相互關係看起來如圖 3-1 所示：
 
@@ -32,21 +32,21 @@ Insert 18333fig0302.png
 Insert 18333fig0303.png
 圖 3-3. 分支其實就是從某個提交物件往回看的歷史
 
-那麼，Git 又是如何創建一個新的分支的呢？答案很簡單，創建一個新的分支指標。比如新建一個 testing 分支，可以使用 `git branch` 命令：
+那麼，Git 又是如何建立一個新的分支的呢？答案很簡單，建立一個新的分支指標。比如新建一個 testing 分支，可以使用 `git branch` 命令：
 
 	$ git branch testing
 
-這會在當前 commit 物件上新建一個分支指標（見圖 3-4）。
+這會在目前 commit 物件上新建一個分支指標（見圖 3-4）。
 
 Insert 18333fig0304.png
 圖 3-4. 多個分支指向提交資料的歷史
 
-那麼，Git 是如何知道你當前在哪個分支上工作的呢？其實答案也很簡單，它保存著一個名為 HEAD 的特別指標。請注意它和你熟知的許多其他版本控制系統（比如 Subversion 或 CVS）裡的 HEAD 概念大不相同。在 Git 中，它是一個指向你正在工作中的本地分支的指標（譯注：將 HEAD 想像為當前分支的別名。）。運行 `git branch` 命令，僅僅是建立了一個新的分支，但不會自動切換到這個分支中去，所以在這個例子中，我們依然還在 master 分支裡工作（參考圖 3-5）。
+那麼，Git 是如何知道你目前在哪個分支上工作的呢？其實答案也很簡單，它保存著一個名為 HEAD 的特別指標。請注意它和你熟知的許多其他版本控制系統（比如 Subversion 或 CVS）裡的 HEAD 概念大不相同。在 Git 中，它是一個指向你正在工作中的本地分支的指標（譯注：將 HEAD 想像為目前分支的別名。）。執行 `git branch` 命令，僅僅是建立了一個新的分支，但不會自動切換到這個分支中去，所以在這個例子中，我們依然還在 master 分支裡工作（參考圖 3-5）。
 
 Insert 18333fig0305.png
-圖 3-5. HEAD 指向當前所在的分支
+圖 3-5. HEAD 指向目前所在的分支
 
-要切換到其他分支，可以執行 `git checkout` 命令。我們現在轉換到新建的 testing 分支：
+要切換到其他分支，可以執行 `git checkout` 命令。我們現在轉換到新增的 testing 分支：
 
 	$ git checkout testing
 
@@ -60,7 +60,7 @@ Insert 18333fig0306.png
 	$ vim test.rb
 	$ git commit -a -m 'made a change'
 
-圖 3-7 展示了提交後的結果。
+圖 3-7 示範了提交後的結果。
 
 Insert 18333fig0307.png
 圖 3-7. 每次提交後 HEAD 隨著分支一起向前移動
@@ -81,23 +81,23 @@ Insert 18333fig0308.png
 	$ vim test.rb
 	$ git commit -a -m 'made other changes'
 
-現在我們的項目提交歷史產生了分叉（如圖 3-9 所示），因為剛才我們創建了一個分支，轉換到其中進行了一些工作，然後又回到原來的主分支進行了另外一些工作。這些改變分別孤立在不同的分支裡：我們可以在不同分支裡反復切換，並在時機成熟時把它們合併到一起。而所有這些工作，僅僅需要 `branch` 和 `checkout` 這兩條命令就可以完成。
+現在我們的專案提交歷史產生了分叉（如圖 3-9 所示），因為剛才我們建立了一個分支，轉換到其中進行了一些工作，然後又回到原來的主分支進行了另外一些工作。這些改變分別孤立在不同的分支裡：我們可以在不同分支裡反覆切換，並在時機成熟時把它們合併到一起。而所有這些工作，僅僅需要 `branch` 和 `checkout` 這兩條命令就可以完成。
 
 Insert 18333fig0309.png
 圖 3-9. 不同流向的分支歷史
 
-由於 Git 中的分支實際上僅是一個包含所指物件校驗和（40 個字元長度 SHA-1 字串）的檔，所以創建和銷毀一個分支就變得非常廉價。說白了，新建一個分支就是向一個檔寫入 41 個位元組（外加一個分行符號）那麼簡單，當然也就很快了。
+由於 Git 中的分支實際上僅是一個包含所指物件雜湊值（40 個字元長度 SHA-1 字串）的檔，所以建立和銷毀一個分支就變得非常廉價。說白了，新建一個分支就是向一個檔寫入 41 個位元組（外加一個分行符號）那麼簡單，當然也就很快了。
 
-這和大多數版本控制系統形成了鮮明對比，它們管理分支大多採取備份所有專案檔案到特定目錄的方式，所以根據專案檔案數量和大小不同，可能花費的時間也會有相當大的差別，快則幾秒，慢則數分鐘。而 Git 的實現與項目複雜度無關，它永遠可以在幾毫秒的時間內完成分支的創建和切換。同時，因為每次提交時都記錄了祖先資訊（譯注：即 `parent` 物件），將來要合併分支時，尋找恰當的合併基礎（譯注：即共同祖先）的工作其實已經自然而然地擺在那裡了，所以實現起來非常容易。Git 鼓勵開發者頻繁使用分支，正是因為有著這些特性作保障。
+這和大多數版本控制系統形成了鮮明對比，它們管理分支大多採取備份所有專案檔案到特定目錄的方式，所以根據專案檔案數量和大小不同，可能花費的時間也會有相當大的差別，快則幾秒，慢則數分鐘。而 Git 的實現與專案複雜度無關，它永遠可以在幾毫秒的時間內完成分支的建立和切換。同時，因為每次提交時都記錄了祖先資訊（譯注：即 `parent` 物件），將來要合併分支時，尋找恰當的合併基礎（譯注：即共同祖先）的工作其實已經自然而然地擺在那裡了，所以實現起來非常容易。Git 鼓勵開發者頻繁使用分支，正是因為有著這些特性作保障。
 
 接下來看看，我們為什麼應該頻繁使用分支。
 
-## 分支的新建與合併 ##
+## 分支的新增與合併 ##
 
 現在讓我們來看一個簡單的分支與合併的例子，實際工作中大體也會用到這樣的工作流程：
 
 1. 開發某個網站。
-2. 為實現某個新的需求，創建一個分支。
+2. 為實現某個新的需求，建立一個分支。
 3. 在這個分支上開展工作。
 
 假設此時，你突然接到一個電話說有個很嚴重的問題需要緊急修補，那麼可以按照下面的方式處理：
@@ -107,14 +107,14 @@ Insert 18333fig0309.png
 3. 通過測試後，回到生產伺服器所在的分支，將修補分支合併進來，然後再推送到生產伺服器上。
 4. 切換到之前實現新需求的分支，繼續工作。
 
-### 分支的新建與切換 ###
+### 分支的新增與切換 ###
 
 首先，我們假設你正在專案中愉快地工作，並且已經提交了幾次更新（見圖 3-10）。
 
 Insert 18333fig0310.png
 圖 3-10. 一個簡短的提交歷史
 
-現在，你決定要修補問題追蹤系統上的 #53 問題。順帶說明下，Git 並不同任何特定的問題追蹤系統打交道。這裡為了說明要解決的問題，才把新建的分支取名為 iss53。要新建並切換到該分支，運行 `git checkout` 並加上 `-b` 參數：
+現在，你決定要修補問題追蹤系統上的 #53 問題。順帶說明下，Git 並不同任何特定的問題追蹤系統打交道。這裡為了說明要解決的問題，才把新增的分支取名為 iss53。要新建並切換到該分支，執行 `git checkout` 並加上 `-b` 參數：
 
 	$ git checkout -b iss53
 	Switched to a new branch 'iss53'
@@ -127,9 +127,9 @@ Insert 18333fig0310.png
 圖 3-11 示意該命令的執行結果。
 
 Insert 18333fig0311.png
-圖 3-11. 創建了一個新分支的指標
+圖 3-11. 建立了一個新分支的指標
 
-接著你開始嘗試修復問題，在提交了若干次更新後，`iss53` 分支的指標也會隨著向前推進，因為它就是當前分支（換句話說，當前的 `HEAD` 指標正指向 `iss53`，見圖 3-12）：
+接著你開始嘗試修復問題，在提交了若干次更新後，`iss53` 分支的指標也會隨著向前推進，因為它就是目前分支（換句話說，目前的 `HEAD` 指標正指向 `iss53`，見圖 3-12）：
 
 	$ vim index.html
 	$ git commit -a -m 'added a new footer [issue 53]'
@@ -137,16 +137,16 @@ Insert 18333fig0311.png
 Insert 18333fig0312.png
 圖 3-12. iss53 分支隨工作進展向前推進
 
-現在你就接到了那個網站問題的緊急電話，需要馬上修補。有了 Git ，我們就不需要同時發佈這個補丁和 `iss53` 裡作出的修改，也不需要在創建和發佈該補丁到伺服器之前花費大力氣來復原這些修改。唯一需要的僅僅是切換回 `master` 分支。
+現在你就接到了那個網站問題的緊急電話，需要馬上修補。有了 Git ，我們就不需要同時發佈這個修補檔和 `iss53` 裡作出的修改，也不需要在建立和發佈該修補檔到伺服器之前花費大力氣來復原這些修改。唯一需要的僅僅是切換回 `master` 分支。
 
-不過在此之前，留心你的暫存區或者工作目錄裡，那些還沒有提交的修改，它會和你即將檢出的分支產生衝突從而阻止 Git 為你切換分支。切換分支的時候最好保持一個清潔的工作區域。稍後會介紹幾個繞過這種問題的辦法（分別叫做 stashing 和 commit amending）。目前已經提交了所有的修改，所以接下來可以正常轉換到 `master` 分支：
+不過在此之前，留心你的暫存區或者工作目錄裡，那些還沒有提交的修改，它會和你即將檢出的分支產生衝突從而阻止 Git 為你切換分支。切換分支的時候最好保持一個乾淨的工作區域。稍後會介紹幾個繞過這種問題的辦法（分別叫做 stashing 和 commit amending）。目前已經提交了所有的修改，所以接下來可以正常轉換到 `master` 分支：
 
 	$ git checkout master
 	Switched to branch 'master'
 
-此時工作目錄中的內容和你在解決問題 #53 之前一模一樣，你可以集中精力進行緊急修補。這一點值得牢記：Git 會把工作目錄的內容恢復為檢出某分支時它所指向的那個提交物件的快照。它會自動添加、刪除和修改檔以確保目錄的內容和你當時提交時完全一樣。
+此時工作目錄中的內容和你在解決問題 #53 之前一模一樣，你可以集中精力進行緊急修補。這一點值得牢記：Git 會把工作目錄的內容恢復為檢出某分支時它所指向的那個提交物件的快照。它會自動增加、刪除和修改檔以確保目錄的內容和你當時提交時完全一樣。
 
-接下來，你得進行緊急修補。我們創建一個緊急修補分支 `hotfix` 來開展工作，直到搞定（見圖 3-13）：
+接下來，你得進行緊急修補。我們建立一個緊急修補分支 `hotfix` 來開展工作，直到搞定（見圖 3-13）：
 
 	$ git checkout -b hotfix
 	Switched to a new branch 'hotfix'
@@ -167,14 +167,14 @@ Insert 18333fig0313.png
 	 README | 1 -
 	 1 file changed, 1 deletion(-)
 
-請注意，合併時出現了“Fast forward”的提示。由於當前 `master` 分支所在的提交物件是要併入的 `hotfix` 分支的直接上游，Git 只需把 `master` 分支指標直接右移。換句話說，如果順著一個分支走下去可以到達另一個分支的話，那麼 Git 在合併兩者時，只會簡單地把指標右移，因為這種單線的歷史分支不存在任何需要解決的分歧，所以這種合併過程可以稱為快進（Fast forward）。
+請注意，合併時出現了“Fast forward”的提示。由於目前 `master` 分支所在的提交物件是要併入的 `hotfix` 分支的直接上游，Git 只需把 `master` 分支指標直接右移。換句話說，如果順著一個分支走下去可以到達另一個分支的話，那麼 Git 在合併兩者時，只會簡單地把指標右移，因為這種單線的歷史分支不存在任何需要解決的分歧，所以這種合併過程可以稱為快進（Fast forward）。
 
-現在最新的修改已經在當前 `master` 分支所指向的提交物件中了，可以部署到生產伺服器上去了（見圖 3-14）。
+現在最新的修改已經在目前 `master` 分支所指向的提交物件中了，可以部署到生產伺服器上去了（見圖 3-14）。
 
 Insert 18333fig0314.png
 圖 3-14. 合併之後，master 分支和 hotfix 分支指向同一位置。
 
-在那個超級重要的修補發佈以後，你想要回到被打擾之前的工作。由於當前 `hotfix` 分支和 `master` 都指向相同的提交物件，所以 `hotfix` 已經完成了歷史使命，可以刪掉了。使用 `git branch` 的 `-d` 選項執行刪除操作：
+在那個超級重要的修補發佈以後，你想要回到被打擾之前的工作。由於目前 `hotfix` 分支和 `master` 都指向相同的提交物件，所以 `hotfix` 已經完成了歷史使命，可以刪掉了。使用 `git branch` 的 `-d` 選項執行刪除操作：
 
 	$ git branch -d hotfix
 	Deleted branch hotfix (was 3a0874c).
@@ -195,7 +195,7 @@ Insert 18333fig0315.png
 
 ### 分支的合併 ###
 
-在問題 #53 相關的工作完成之後，可以合併回 `master` 分支。實際操作同前面合併 `hotfix` 分支差不多，只需回到 `master` 分支，運行 `git merge` 命令指定要合併進來的分支：
+在問題 #53 相關的工作完成之後，可以合併回 `master` 分支。實際操作同前面合併 `hotfix` 分支差不多，只需回到 `master` 分支，執行 `git merge` 命令指定要合併進來的分支：
 
 	$ git checkout master
 	$ git merge iss53
@@ -204,17 +204,17 @@ Insert 18333fig0315.png
 	 README | 1 +
 	 1 file changed, 1 insertion(+)
 
-請注意，這次合併操作的底層實現，並不同於之前 `hotfix` 的併入方式。因為這次你的開發歷史是從更早的地方開始分叉的。由於當前 `master` 分支所指向的提交物件（C4）並不是 `iss53` 分支的直接祖先，Git 不得不進行一些額外處理。就此例而言，Git 會用兩個分支的末端（C4 和 C5）以及它們的共同祖先（C2）進行一次簡單的三方合併計算。圖 3-16 用紅框標出了 Git 用於合併的三個提交對象：
+請注意，這次合併操作的底層實現，並不同於之前 `hotfix` 的併入方式。因為這次你的開發歷史是從更早的地方開始分叉的。由於目前 `master` 分支所指向的提交物件（C4）並不是 `iss53` 分支的直接祖先，Git 不得不進行一些額外處理。就此例而言，Git 會用兩個分支的末端（C4 和 C5）以及它們的共同祖先（C2）進行一次簡單的三方合併計算。圖 3-16 用紅框標出了 Git 用於合併的三個提交對象：
 
 Insert 18333fig0316.png
 圖 3-16. Git 為分支合併自動識別出最佳的同源合併點。
 
-這次，Git 沒有簡單地把分支指標右移，而是對三方合併後的結果重新做一個新的快照，並自動創建一個指向它的提交物件（C6）（見圖 3-17）。這個提交物件比較特殊，它有兩個祖先（C4 和 C5）。
+這次，Git 沒有簡單地把分支指標右移，而是對三方合併後的結果重新做一個新的快照，並自動建立一個指向它的提交物件（C6）（見圖 3-17）。這個提交物件比較特殊，它有兩個祖先（C4 和 C5）。
 
-值得一提的是 Git 可以自己裁決哪個共同祖先才是最佳合併基礎；這和 CVS 或 Subversion（1.5 以後的版本）不同，它們需要開發者手工指定合併基礎。所以此特性讓 Git 的合併操作比其他系統都要簡單不少。
+值得一提的是 Git 可以自己決定哪個共同祖先才是最佳合併基礎；這和 CVS 或 Subversion（1.5 以後的版本）不同，它們需要開發者手工指定合併基礎。所以此特性讓 Git 的合併操作比其他系統都要簡單不少。
 
 Insert 18333fig0317.png
-圖 3-17. Git 自動創建了一個包含了合併結果的提交物件。
+圖 3-17. Git 自動建立了一個包含了合併結果的提交物件。
 
 既然之前的工作成果已經合併到 `master` 了，那麼 `iss53` 也就沒用了。你可以就此刪除它，並在問題追蹤系統裡關閉該問題。
 
@@ -222,7 +222,7 @@ Insert 18333fig0317.png
 
 ### 遇到衝突時的分支合併 ###
 
-有時候合併操作並不會如此順利。如果在不同的分支中都修改了同一個檔的同一部分，Git 就無法乾淨地把兩者合到一起（譯注：邏輯上說，這種問題只能由人來裁決。）。如果你在解決問題 #53 的過程中修改了 `hotfix` 中修改的部分，將得到類似下面的結果：
+有時候合併操作並不會如此順利。如果在不同的分支中都修改了同一個檔的同一部分，Git 就無法乾淨地把兩者合到一起（譯注：邏輯上說，這種問題只能由人來決定。）。如果你在解決問題 #53 的過程中修改了 `hotfix` 中修改的部分，將得到類似下面的結果：
 
 	$ git merge iss53
 	Auto-merging index.html
@@ -253,13 +253,13 @@ Git 作了合併，但沒有提交，它會停下來等你解決衝突。要看
 	</div>
 	>>>>>>> iss53
 
-可以看到 `=======` 隔開的上半部分，是 `HEAD`（即 `master` 分支，在運行 `merge` 命令時所切換到的分支）中的內容，下半部分是在 `iss53` 分支中的內容。解決衝突的辦法無非是二者選其一或者由你親自整合到一起。比如你可以通過把這段內容替換為下面這樣來解決：
+可以看到 `=======` 隔開的上半部分，是 `HEAD`（即 `master` 分支，在執行 `merge` 命令時所切換到的分支）中的內容，下半部分是在 `iss53` 分支中的內容。解決衝突的辦法無非是二者選其一或者由你親自整合到一起。比如你可以通過把這段內容替換為下面這樣來解決：
 
 	<div id="footer">
 	please contact us at email.support@github.com
 	</div>
 
-這個解決方案各採納了兩個分支中的一部分內容，而且我還刪除了 `<<<<<<<`，`=======` 和 `>>>>>>>` 這些行。在解決了所有檔裡的所有衝突後，運行 `git add` 將把它們標記為已解決狀態（譯注：實際上就是來一次快照保存到暫存區域。）。因為一旦暫存，就表示衝突已經解決。如果你想用一個有圖形介面的工具來解決這些問題，不妨運行 `git mergetool`，它會調用一個視覺化的合併工具並引導你解決所有衝突：
+這個解決方案各採納了兩個分支中的一部分內容，而且我還刪除了 `<<<<<<<`，`=======` 和 `>>>>>>>` 這些行。在解決了所有檔裡的所有衝突後，執行 `git add` 將把它們標記為已解決狀態（譯注：實際上就是來一次快照保存到暫存區域。）。因為一旦暫存，就表示衝突已經解決。如果你想用一個有圖形介面的工具來解決這些問題，不妨執行 `git mergetool`，它會呼叫一個視覺化的合併工具並引導你解決所有衝突：
 
 	$ git mergetool
 
@@ -275,11 +275,11 @@ Git 作了合併，但沒有提交，它會停下來等你解決衝突。要看
 	  {remote}: modified file
 	Hit return to start merge resolution tool (opendiff):
 
-如果不想用默認的合併工具（Git 為我默認選擇了 `opendiff`，因為我在 Mac 上運行了該命令），你可以在上方"merge tool candidates"裡找到可用的合併工具列表，輸入你想用的工具名。我們將在第七章討論怎樣改變環境中的預設值。
+如果不想用預設的合併工具（Git 為我預設選擇了 `opendiff`，因為我在 Mac 上執行了該命令），你可以在上方"merge tool candidates"裡找到可用的合併工具列表，輸入你想用的工具名。我們將在第七章討論怎樣改變環境中的預設值。
 
-退出合併工具以後，Git 會詢問你合併是否成功。如果回答是，它會為你把相關檔暫存起來，以表明狀態為已解決。
+退出合併工具以後，Git 會詢問你合併是否成功。如果回答是，它會為你把相關檔暫存起來，以表示狀態為已解決。
 
-再運行一次 `git status` 來確認所有衝突都已解決：
+再執行一次 `git status` 來確認所有衝突都已解決：
 
 	$ git status
 	On branch master
@@ -302,27 +302,27 @@ Git 作了合併，但沒有提交，它會停下來等你解決衝突。要看
 	# and try again.
 	#
 
-如果想給將來看這次合併的人一些方便，可以修改該資訊，提供更多合併細節。比如你都作了哪些改動，以及這麼做的原因。有時候裁決衝突的理由並不直接或明顯，有必要略加注解。
+如果想給將來看這次合併的人一些方便，可以修改該資訊，提供更多合併細節。比如你都作了哪些改動，以及這麼做的原因。有時候決定衝突的理由並不直接或明顯，有必要略加注解。
 
 ## 分支的管理 ##
 
-到目前為止，你已經學會了如何創建、合併和刪除分支。除此之外，我們還需要學習如何管理分支，在日後的常規工作中會經常用到下面介紹的管理命令。
+到目前為止，你已經學會了如何建立、合併和刪除分支。除此之外，我們還需要學習如何管理分支，在日後的常規工作中會經常用到下面介紹的管理命令。
 
-`git branch` 命令不僅僅能創建和刪除分支，如果不加任何參數，它會給出當前所有分支的清單：
+`git branch` 命令不僅僅能建立和刪除分支，如果不加任何參數，它會給出目前所有分支的清單：
 
 	$ git branch
 	  iss53
 	* master
 	  testing
 
-注意看 `master` 分支前的 `*` 字元：它表示當前所在的分支。也就是說，如果現在提交更新，`master` 分支將隨著開發進度前移。若要查看各個分支最後一個提交物件的資訊，運行 `git branch -v`：
+注意看 `master` 分支前的 `*` 字元：它表示目前所在的分支。也就是說，如果現在提交更新，`master` 分支將隨著開發進度前移。若要查看各個分支最後一個提交物件的資訊，執行 `git branch -v`：
 
 	$ git branch -v
 	  iss53   93b412c fix javascript issue
 	* master  7a98805 Merge branch 'iss53'
 	  testing 782fd34 add scott to the author list in the readmes
 
-要從該清單中篩選出你已經（或尚未）與當前分支合併的分支，可以用 `--merged` 和 `--no-merged` 選項（Git 1.5.6 以上版本）。比如用 `git branch --merged` 查看哪些分支已被併入當前分支（譯注：也就是說哪些分支是當前分支的直接上游。）：
+要從該清單中篩選出你已經（或尚未）與目前分支合併的分支，可以用 `--merged` 和 `--no-merged` 選項（Git 1.5.6 以上版本）。比如用 `git branch --merged` 查看哪些分支已被併入目前分支（譯注：也就是說哪些分支是目前分支的直接上游。）：
 
 	$ git branch --merged
 	  iss53
@@ -345,11 +345,11 @@ Git 作了合併，但沒有提交，它會停下來等你解決衝突。要看
 
 ## 利用分支進行開發的工作流程 ##
 
-現在我們已經學會了新建分支和合併分支，可以（或應該）用它來做點什麼呢？在本節，我們會介紹一些利用分支進行開發的工作流程。而正是由於分支管理的便捷，才衍生出了這類典型的工作模式，你可以根據專案的實際情況選擇一種用用看。
+現在我們已經學會了新建分支和合併分支，可以（或應該）用它來做點什麼呢？在本節，我們會介紹一些利用分支進行開發的工作流程。而正是由於分支管理的方便，才衍生出了這類典型的工作模式，你可以根據專案的實際情況選擇一種用用看。
 
 ### 長期分支 ###
 
-由於 Git 使用簡單的三方合併，所以就算在較長一段時間內，反復多次把某個分支合併到另一分支，也不是什麼難事。也就是說，你可以同時擁有多個開放的分支，每個分支用於完成特定的任務，隨著開發的推進，你可以隨時把某個特性分支的成果並到其他分支中。
+由於 Git 使用簡單的三方合併，所以就算在較長一段時間內，反覆多次把某個分支合併到另一分支，也不是什麼難事。也就是說，你可以同時擁有多個開放的分支，每個分支用於完成特定的任務，隨著開發的推進，你可以隨時把某個特性分支的成果並到其他分支中。
 
 許多使用 Git 的開發者都喜歡用這種方式來開展工作，比如僅在 `master` 分支中保留完全穩定的代碼，即已經發佈或即將發佈的代碼。與此同時，他們還有一個名為 `develop` 或 `next` 的平行分支，專門用於後續的開發，或僅用於穩定性測試 — 當然並不是說一定要絕對穩定，不過一旦進入某種穩定狀態，便可以把它合併到 `master` 裡。這樣，在確保這些已完成的特性分支（短期分支，比如之前的 `iss53` 分支）能夠通過所有測試，並且不會引入更多錯誤之後，就可以並到主幹分支中，等待下一次的發佈。
 
@@ -363,20 +363,20 @@ Insert 18333fig0318.png
 Insert 18333fig0319.png
 圖 3-19. 想像成流水線可能會容易點。
 
-你可以用這招維護不同層次的穩定性。某些大專案還會有個 `proposed`（建議）或 `pu`（proposed updates，建議更新）分支，它包含著那些可能還沒有成熟到進入 `next` 或 `master` 的內容。這麼做的目的是擁有不同層次的穩定性：當這些分支進入到更穩定的水準時，再把它們合併到更高層分支中去。再次說明下，使用多個長期分支的做法並非必需，不過一般來說，對於特大型項目或特複雜的專案，這麼做確實更容易管理。
+你可以用這招維護不同層次的穩定性。某些大專案還會有個 `proposed`（建議）或 `pu`（proposed updates，建議更新）分支，它包含著那些可能還沒有成熟到進入 `next` 或 `master` 的內容。這麼做的目的是擁有不同層次的穩定性：當這些分支進入到更穩定的水準時，再把它們合併到更高層分支中去。再次說明下，使用多個長期分支的做法並非必需，不過一般來說，對於特大型專案或特複雜的專案，這麼做確實更容易管理。
 
 ### 特性分支 ###
 
-在任何規模的專案中都可以使用特性（Topic）分支。一個特性分支是指一個短期的，用來實現單一特性或與其相關工作的分支。可能你在以前的版本控制系統裡從未做過類似這樣的事情，因為通常創建與合併分支消耗太大。然而在 Git 中，一天之內建立、使用、合併再刪除多個分支是常見的事。
+在任何規模的專案中都可以使用特性（Topic）分支。一個特性分支是指一個短期的，用來實現單一特性或與其相關工作的分支。可能你在以前的版本控制系統裡從未做過類似這樣的事情，因為通常建立與合併分支消耗太大。然而在 Git 中，一天之內建立、使用、合併再刪除多個分支是常見的事。
 
-我們在上節的例子裡已經見過這種用法了。我們創建了 `iss53` 和 `hotfix` 這兩個特性分支，在提交了若干更新後，把它們合併到主幹分支，然後刪除。該技術允許你迅速且完全的進行語境切換 — 因為你的工作分散在不同的流水線裡，每個分支裡的改變都和它的目標特性相關，流覽代碼之類的事情因而變得更簡單了。你可以把作出的改變保持在特性分支中幾分鐘，幾天甚至幾個月，等它們成熟以後再合併，而不用在乎它們建立的順序或者進度。
+我們在上節的例子裡已經見過這種用法了。我們建立了 `iss53` 和 `hotfix` 這兩個特性分支，在提交了若干更新後，把它們合併到主幹分支，然後刪除。該技術允許你迅速且完全的進行語境切換 — 因為你的工作分散在不同的流水線裡，每個分支裡的改變都和它的目標特性相關，流覽代碼之類的事情因而變得更簡單了。你可以把作出的改變保持在特性分支中幾分鐘，幾天甚至幾個月，等它們成熟以後再合併，而不用在乎它們建立的順序或者進度。
 
 現在我們來看一個實際的例子。請看圖 3-20，由下往上，起先我們在 `master` 工作到 C1，然後開始一個新分支 `iss91` 嘗試修復 91 號缺陷，提交到 C6 的時候，又冒出一個解決該問題的新辦法，於是從之前 C4 的地方又分出一個分支 `iss91v2`，幹到 C8 的時候，又回到主幹 `master` 中提交了 C9 和 C10，再回到 `iss91v2` 繼續工作，提交 C11，接著，又冒出個不太確定的想法，從 `master` 的最新提交 C10 處開了個新的分支 `dumbidea` 做些試驗。
 
 Insert 18333fig0320.png
 圖 3-20. 擁有多個特性分支的提交歷史。
 
-現在，假定兩件事情：我們最終決定使用第二個解決方案，即 `iss91v2` 中的辦法；另外，我們把 `dumbidea` 分支拿給同事們看了以後，發現它竟然是個天才之作。所以接下來，我們準備拋棄原來的 `iss91` 分支（實際上會丟棄 C5 和 C6），直接在主幹中併入另外兩個分支。最終的提交歷史將變成圖 3-21 這樣：
+現在，假定兩件事情：我們最終決定使用第二個解決方案，即 `iss91v2` 中的辦法；另外，我們把 `dumbidea` 分支拿給同事們看了以後，發現它竟然是個天才之作。所以接下來，我們準備放棄原來的 `iss91` 分支（實際上會丟棄 C5 和 C6），直接在主幹中併入另外兩個分支。最終的提交歷史將變成圖 3-21 這樣：
 
 Insert 18333fig0321.png
 圖 3-21. 合併了 dumbidea 和 iss91v2 後的分支歷史。
@@ -399,26 +399,26 @@ Insert 18333fig0322.png
 Insert 18333fig0323.png
 圖 3-23. 在本地工作的同時有人向遠端倉庫推送內容會讓提交歷史開始分流。
 
-可以運行 `git fetch origin` 來同步遠端伺服器上的資料到本地。該命令首先找到 `origin` 是哪個伺服器（本例為 `git.ourcompany.com`），從上面獲取你尚未擁有的資料，更新你本地的資料庫，然後把 `origin/master` 的指針移到它最新的位置上（見圖 3-24）。
+可以執行 `git fetch origin` 來同步遠端伺服器上的資料到本地。該命令首先找到 `origin` 是哪個伺服器（本例為 `git.ourcompany.com`），從上面取得你尚未擁有的資料，更新你本地的資料庫，然後把 `origin/master` 的指針移到它最新的位置上（見圖 3-24）。
 
 Insert 18333fig0324.png
 圖 3-24. git fetch 命令會更新 remote 索引。
 
-為了演示擁有多個遠端分支（在不同的遠端伺服器上）的專案是如何工作的，我們假設你還有另一個僅供你的敏捷開發小組使用的內部伺服器 `git.team1.ourcompany.com`。可以用第二章中提到的 `git remote add` 命令把它加為當前專案的遠端分支之一。我們把它命名為 `teamone`，以便代替完整的 Git URL 以方便使用（見圖 3-25）。
+為了演示擁有多個遠端分支（在不同的遠端伺服器上）的專案是如何工作的，我們假設你還有另一個僅供你的敏捷開發小組使用的內部伺服器 `git.team1.ourcompany.com`。可以用第二章中提到的 `git remote add` 命令把它加為目前專案的遠端分支之一。我們把它命名為 `teamone`，以便代替完整的 Git URL 以方便使用（見圖 3-25）。
 
 Insert 18333fig0325.png
 圖 3-25. 把另一個伺服器加為遠端倉庫
 
-現在你可以用 `git fetch teamone` 來獲取小組伺服器上你還沒有的資料了。由於當前該伺服器上的內容是你 `origin` 伺服器上的子集，Git 不會下載任何資料，而只是簡單地創建一個名為 `teamone/master` 的遠端分支，指向 `teamone` 伺服器上 `master` 分支所在的提交物件 `31b8e`（見圖 3-26）。
+現在你可以用 `git fetch teamone` 來取得小組伺服器上你還沒有的資料了。由於目前該伺服器上的內容是你 `origin` 伺服器上的子集，Git 不會下載任何資料，而只是簡單地建立一個名為 `teamone/master` 的遠端分支，指向 `teamone` 伺服器上 `master` 分支所在的提交物件 `31b8e`（見圖 3-26）。
 
 Insert 18333fig0326.png
 圖 3-26. 你在本地有了一個指向 teamone 伺服器上 master 分支的索引。
 
 ### 推送本地分支 ###
 
-要想和其他人分享某個本地分支，你需要把它推送到一個你擁有寫許可權的遠端倉庫。你創建的本地分支不會因為你的寫入操作而被自動同步到你引入的遠端伺服器上，你需要明確地執行推送分支的操作。換句話說，對於無意分享的分支，你儘管保留為私人分支好了，而只推送那些協同工作要用到的特性分支。
+要想和其他人分享某個本地分支，你需要把它推送到一個你擁有寫許可權的遠端倉庫。你建立的本地分支不會因為你的寫入操作而被自動同步到你引入的遠端伺服器上，你需要明確地執行推送分支的操作。換句話說，對於無意分享的分支，你儘管保留為私人分支好了，而只推送那些協同工作要用到的特性分支。
 
-如果你有個叫 `serverfix` 的分支需要和他人一起開發，可以運行 `git push (遠端倉庫名) (分支名)`：
+如果你有個叫 `serverfix` 的分支需要和他人一起開發，可以執行 `git push (遠端倉庫名) (分支名)`：
 
 	$ git push origin serverfix
 	Counting objects: 20, done.
@@ -428,9 +428,9 @@ Insert 18333fig0326.png
 	To git@github.com:schacon/simplegit.git
 	 * [new branch]      serverfix -> serverfix
 
-這裡其實走了一點捷徑。Git 自動把 `serverfix` 分支名擴展為 `refs/heads/serverfix:refs/heads/serverfix`，意為“取出我在本地的 serverfix 分支，推送到遠端倉庫的 serverfix 分支中去”。我們將在第九章進一步介紹 `refs/heads/` 部分的細節，不過一般使用的時候都可以省略它。也可以運行 `git push origin serverfix:serverfix` 來實現相同的效果，它的意思是“上傳我本地的 serverfix 分支到遠端倉庫中去，仍舊稱它為 serverfix 分支”。通過此語法，你可以把本地分支推送到某個命名不同的遠端分支：若想把遠端分支叫作 `awesomebranch`，可以用 `git push origin serverfix:awesomebranch` 來推送數據。
+這裡其實走了一點捷徑。Git 自動把 `serverfix` 分支名擴展為 `refs/heads/serverfix:refs/heads/serverfix`，意為“取出我在本地的 serverfix 分支，推送到遠端倉庫的 serverfix 分支中去”。我們將在第九章進一步介紹 `refs/heads/` 部分的細節，不過一般使用的時候都可以省略它。也可以執行 `git push origin serverfix:serverfix` 來實現相同的效果，它的意思是“上傳我本地的 serverfix 分支到遠端倉庫中去，仍舊稱它為 serverfix 分支”。通過此語法，你可以把本地分支推送到某個命名不同的遠端分支：若想把遠端分支叫作 `awesomebranch`，可以用 `git push origin serverfix:awesomebranch` 來推送數據。
 
-接下來，當你的協作者再次從伺服器上獲取資料時，他們將得到一個新的遠端分支 `origin/serverfix`，並指向伺服器上 `serverfix` 所指向的版本：
+接下來，當你的協作者再次從伺服器上取得資料時，他們將得到一個新的遠端分支 `origin/serverfix`，並指向伺服器上 `serverfix` 所指向的版本：
 
 	$ git fetch origin
 	remote: Counting objects: 20, done.
@@ -442,19 +442,19 @@ Insert 18333fig0326.png
 
 值得注意的是，在 `fetch` 操作下載好新的遠端分支之後，你仍然無法在本地編輯該遠端倉庫中的分支。換句話說，在本例中，你不會有一個新的 `serverfix` 分支，有的只是一個你無法移動的 `origin/serverfix` 指標。
 
-如果要把該遠端分支的內容合併到當前分支，可以運行 `git merge origin/serverfix`。如果想要一份自己的 `serverfix` 來開發，可以在遠端分支的基礎上分化出一個新的分支來：
+如果要把該遠端分支的內容合併到目前分支，可以執行 `git merge origin/serverfix`。如果想要一份自己的 `serverfix` 來開發，可以在遠端分支的基礎上分化出一個新的分支來：
 
 	$ git checkout -b serverfix origin/serverfix
 	Branch serverfix set up to track remote branch serverfix from origin.
 	Switched to a new branch 'serverfix'
 
-這會切換到新建的 `serverfix` 本地分支，其內容同遠端分支 `origin/serverfix` 一致，這樣你就可以在裡面繼續開發了。
+這會切換到新增的 `serverfix` 本地分支，其內容同遠端分支 `origin/serverfix` 一致，這樣你就可以在裡面繼續開發了。
 
 ### 跟蹤遠端分支 ###
 
-從遠端分支 `checkout` 出來的本地分支，稱為 _跟蹤分支_ (tracking branch)。跟蹤分支是一種和某個遠端分支有直接聯繫的本地分支。在跟蹤分支裡輸入 `git push`，Git 會自行推斷應該向哪個伺服器的哪個分支推送資料。同樣，在這些分支裡運行 `git pull` 會獲取所有遠端索引，並把它們的資料都合併到本地分支中來。
+從遠端分支 `checkout` 出來的本地分支，稱為 _追蹤分支_ (tracking branch)。追蹤分支是一種和某個遠端分支有直接聯繫的本地分支。在追蹤分支裡輸入 `git push`，Git 會自行推斷應該向哪個伺服器的哪個分支推送資料。同樣，在這些分支裡執行 `git pull` 會取得所有遠端索引，並把它們的資料都合併到本地分支中來。
 
-在克隆倉庫時，Git 通常會自動創建一個名為 `master` 的分支來跟蹤 `origin/master`。這正是 `git push` 和 `git pull` 一開始就能正常工作的原因。當然，你可以隨心所欲地設定為其它跟蹤分支，比如 `origin` 上除了 `master` 之外的其它分支。剛才我們已經看到了這樣的一個例子：`git checkout -b [分支名] [遠端名]/[分支名]`。如果你有 1.6.2 以上版本的 Git，還可以用 `--track` 選項簡化：
+在克隆倉庫時，Git 通常會自動建立一個名為 `master` 的分支來跟蹤 `origin/master`。這正是 `git push` 和 `git pull` 一開始就能正常工作的原因。當然，你可以隨心所欲地設定為其它追蹤分支，比如 `origin` 上除了 `master` 之外的其它分支。剛才我們已經看到了這樣的一個例子：`git checkout -b [分支名] [遠端名]/[分支名]`。如果你有 1.6.2 以上版本的 Git，還可以用 `--track` 選項簡化：
 
 	$ git checkout --track origin/serverfix
 	Branch serverfix set up to track remote branch serverfix from origin.
@@ -470,7 +470,7 @@ Insert 18333fig0326.png
 
 ### 刪除遠端分支 ###
 
-如果不再需要某個遠端分支了，比如搞定了某個特性並把它合併進了遠端的 `master` 分支（或任何其他存放穩定代碼的分支），可以用這個非常無厘頭的語法來刪除它：`git push [遠程名] :[分支名]`。如果想在伺服器上刪除 `serverfix` 分支，運行下面的命令：
+如果不再需要某個遠端分支了，比如搞定了某個特性並把它合併進了遠端的 `master` 分支（或任何其他存放穩定代碼的分支），可以用這個非常無厘頭的語法來刪除它：`git push [遠端名] :[分支名]`。如果想在伺服器上刪除 `serverfix` 分支，執行下面的命令：
 
 	$ git push origin :serverfix
 	To git@github.com:schacon/simplegit.git
@@ -484,7 +484,7 @@ Insert 18333fig0326.png
 
 ### 基本的衍合操作 ###
 
-請回顧之前有關合併的一節（見圖 3-27），你會看到開發進程分叉到兩個不同分支，又各自提交了更新。
+請回顧之前有關合併的一節（見圖 3-27），你會看到開發行程分叉到兩個不同分支，又各自提交了更新。
 
 Insert 18333fig0327.png
 圖 3-27. 最初分叉的提交歷史。
@@ -494,16 +494,16 @@ Insert 18333fig0327.png
 Insert 18333fig0328.png
 圖 3-28. 通過合併一個分支來整合分叉了的歷史。
 
-其實，還有另外一個選擇：你可以把在 C3 裡產生的變化補丁在 C4 的基礎上重新打一遍。在 Git 裡，這種操作叫做_衍合（rebase）_。有了 `rebase` 命令，就可以把在一個分支裡提交的改變移到另一個分支裡重放一遍。
+其實，還有另外一個選擇：你可以把在 C3 裡產生的變化修補檔在 C4 的基礎上重新打一遍。在 Git 裡，這種操作叫做_衍合（rebase）_。有了 `rebase` 命令，就可以把在一個分支裡提交的改變移到另一個分支裡重放一遍。
 
-在上面這個例子中，運行：
+在上面這個例子中，執行：
 
 	$ git checkout experiment
 	$ git rebase master
 	First, rewinding head to replay your work on top of it...
 	Applying: added staged command
 
-它的原理是回到兩個分支最近的共同祖先，根據當前分支（也就是要進行衍合的分支 `experiment`）後續的歷次提交物件（這裡只有一個 C3），生成一系列檔補丁，然後以基底分支（也就是主幹分支 `master`）最後一個提交物件（C4）為新的出發點，逐個應用之前準備好的補丁檔，最後會生成一個新的合併提交物件（C3'），從而改寫 `experiment` 的提交歷史，使它成為 `master` 分支的直接下游，如圖 3-29 所示：
+它的原理是回到兩個分支最近的共同祖先，根據目前分支（也就是要進行衍合的分支 `experiment`）後續的歷次提交物件（這裡只有一個 C3），生成一系列檔修補檔，然後以基底分支（也就是主幹分支 `master`）最後一個提交物件（C4）為新的出發點，逐個應用之前準備好的修補檔檔，最後會生成一個新的合併提交物件（C3'），從而改寫 `experiment` 的提交歷史，使它成為 `master` 分支的直接下游，如圖 3-29 所示：
 
 Insert 18333fig0329.png
 圖 3-29. 把 C3 裡產生的改變到 C4 上重演一遍。
@@ -515,13 +515,13 @@ Insert 18333fig0330.png
 
 現在的 C3' 對應的快照，其實和普通的三方合併，即上個例子中的 C5 對應的快照內容一模一樣了。雖然最後整合得到的結果沒有任何區別，但衍合能產生一個更為整潔的提交歷史。如果視察一個衍合過的分支的歷史記錄，看起來會更清楚：仿佛所有修改都是在一根線上先後進行的，儘管實際上它們原本是同時並行發生的。
 
-一般我們使用衍合的目的，是想要得到一個能在遠端分支上乾淨應用的補丁 — 比如某些項目你不是維護者，但想幫點忙的話，最好用衍合：先在自己的一個分支裡進行開發，當準備向主專案提交補丁的時候，根據最新的 `origin/master` 進行一次衍合操作然後再提交，這樣維護者就不需要做任何整合工作（譯注：實際上是把解決分支補丁同最新主幹代碼之間衝突的責任，化轉為由提交補丁的人來解決。），只需根據你提供的倉庫位址作一次快進合併，或者直接採納你提交的補丁。
+一般我們使用衍合的目的，是想要得到一個能在遠端分支上乾淨應用的修補檔 — 比如某些專案你不是維護者，但想幫點忙的話，最好用衍合：先在自己的一個分支裡進行開發，當準備向主專案提交修補檔的時候，根據最新的 `origin/master` 進行一次衍合操作然後再提交，這樣維護者就不需要做任何整合工作（譯注：實際上是把解決分支修補檔同最新主幹代碼之間衝突的責任，化轉為由提交修補檔的人來解決。），只需根據你提供的倉庫位址作一次快進合併，或者直接採納你提交的修補檔。
 
 請注意，合併結果中最後一次提交所指向的快照，無論是通過衍合，還是三方合併，都會得到相同的快照內容，只不過提交歷史不同罷了。衍合是按照每行的修改次序重演一遍修改，而合併是把最終結果合在一起。
 
 ### 有趣的衍合 ###
 
-衍合也可以放到其他分支進行，並不一定非得根據分化之前的分支。以圖 3-31 的歷史為例，我們為了給伺服器端代碼添加一些功能而創建了特性分支 `server`，然後提交 C3 和 C4。然後又從 C3 的地方再增加一個 `client` 分支來對用戶端代碼進行一些相應修改，所以提交了 C8 和 C9。最後，又回到 `server` 分支提交了 C10。
+衍合也可以放到其他分支進行，並不一定非得根據分化之前的分支。以圖 3-31 的歷史為例，我們為了給伺服器端代碼增加一些功能而建立了特性分支 `server`，然後提交 C3 和 C4。然後又從 C3 的地方再增加一個 `client` 分支來對用戶端代碼進行一些相應修改，所以提交了 C8 和 C9。最後，又回到 `server` 分支提交了 C10。
 
 Insert 18333fig0331.png
 圖 3-31. 從一個特性分支裡再分出一個特性分支的歷史。
@@ -530,7 +530,7 @@ Insert 18333fig0331.png
 
 	$ git rebase --onto master server client
 
-這好比在說：“取出 `client` 分支，找出 `client` 分支和 `server` 分支的共同祖先之後的變化，然後把它們在 `master` 上重演一遍”。是不是有點複雜？不過它的結果如圖 3-32 所示，非常酷（譯注：雖然 `client` 裡的 C8, C9 在 C3 之後，但這僅表明時間上的先後，而非在 C3 修改的基礎上進一步改動，因為 `server` 和 `client` 這兩個分支對應的代碼應該是兩套檔，雖然這麼說不是很嚴格，但應理解為在 C3 時間點之後，對另外的檔所做的 C8，C9 修改，放到主幹重演。）：
+這好比在說：“取出 `client` 分支，找出 `client` 分支和 `server` 分支的共同祖先之後的變化，然後把它們在 `master` 上重演一遍”。是不是有點複雜？不過它的結果如圖 3-32 所示，非常酷（譯注：雖然 `client` 裡的 C8, C9 在 C3 之後，但這僅表示時間上的先後，而非在 C3 修改的基礎上進一步改動，因為 `server` 和 `client` 這兩個分支對應的代碼應該是兩套檔，雖然這麼說不是很嚴格，但應理解為在 C3 時間點之後，對另外的檔所做的 C8，C9 修改，放到主幹重演。）：
 
 Insert 18333fig0332.png
 圖 3-32. 將特性分支上的另一個特性分支衍合到其他分支。
@@ -547,7 +547,7 @@ Insert 18333fig0333.png
 
 	$ git rebase master server
 
-於是，`server` 的進度應用到 `master` 的基礎上，如圖 3-34 所示：
+於是，`server` 的進度套用到 `master` 的基礎上，如圖 3-34 所示：
 
 Insert 18333fig0334.png
 圖 3-34. 在 master 分支上衍合 server 分支。
@@ -557,7 +557,7 @@ Insert 18333fig0334.png
 	$ git checkout master
 	$ git merge server
 
-現在 `client` 和 `server` 分支的變化都已經集成到主幹分支來了，可以刪掉它們了。最終我們的提交歷史會變成圖 3-35 的樣子：
+現在 `client` 和 `server` 分支的變化都已經整合到主幹分支來了，可以刪掉它們了。最終我們的提交歷史會變成圖 3-35 的樣子：
 
 	$ git branch -d client
 	$ git branch -d server
@@ -569,11 +569,11 @@ Insert 18333fig0335.png
 
 呃，奇妙的衍合也並非完美無缺，要用它得遵守一條準則：
 
-**一旦分支中的提交物件發佈到公共倉庫，就千萬不要對該分支進行衍合操作。**
+**一旦分支中的提交物件發佈到公開倉庫，就千萬不要對該分支進行衍合操作。**
 
 如果你遵循這條金科玉律，就不會出差錯。否則，人民群眾會仇恨你，你的朋友和家人也會嘲笑你，唾棄你。
 
-在進行衍合的時候，實際上拋棄了一些現存的提交物件而創造了一些類似但不同的新的提交物件。如果你把原來分支中的提交物件發佈出去，並且其他人更新下載後在其基礎上開展工作，而稍後你又用 `git rebase` 拋棄這些提交物件，把新的重演後的提交物件發佈出去的話，你的合作者就不得不重新合併他們的工作，這樣當你再次從他們那裡獲取內容時，提交歷史就會變得一團糟。
+在進行衍合的時候，實際上放棄了一些現存的提交物件而創造了一些類似但不同的新的提交物件。如果你把原來分支中的提交物件發佈出去，並且其他人更新下載後在其基礎上開展工作，而稍後你又用 `git rebase` 放棄這些提交物件，把新的重演後的提交物件發佈出去的話，你的合作者就不得不重新合併他們的工作，這樣當你再次從他們那裡取得內容時，提交歷史就會變得一團糟。
 
 下面我們用一個實際例子來說明為什麼公開的衍合會帶來問題。假設你從一個中央伺服器克隆然後在它的基礎上搞了一些開發，提交歷史類似圖 3-36 所示：
 
@@ -601,4 +601,4 @@ C8 這一步的合併是遲早會發生的，因為只有這樣你才能和其
 
 ## 小結 ##
 
-讀到這裡，你應該已經學會了如何創建分支並切換到新分支，在不同分支間轉換，合併本地分支，把分支推送到共用伺服器上，使用共用分支與他人協作，以及在分享之前進行衍合。
+讀到這裡，你應該已經學會了如何建立分支並切換到新分支，在不同分支間轉換，合併本地分支，把分支推送到共用伺服器上，使用共用分支與他人協作，以及在分享之前進行衍合。
diff --git a/zh-tw/04-git-server/01-chapter4.markdown b/zh-tw/04-git-server/01-chapter4.markdown
index b9aa91489..a9596dfdf 100644
--- a/zh-tw/04-git-server/01-chapter4.markdown
+++ b/zh-tw/04-git-server/01-chapter4.markdown
@@ -1,24 +1,24 @@
 # 伺服器上的 Git #
 
-到目前為止，你應該已經學會了使用 Git 來完成日常工作。然而，如果想與他人合作，還需要一個遠端的 Git 倉庫。儘管技術上可以從個人的倉庫裡推送和拉取修改內容，但我們不鼓勵這樣做，因為一不留心就很容易弄混其他人的進度。另外，你也一定希望合作者們即使在自己不開機的時候也能從倉庫獲取資料 — 擁有一個更穩定的公共倉庫十分有用。因此，更好的合作方式是建立一個大家都可以訪問的共用倉庫，從那裡推送和拉取資料。我們將把這個倉庫稱為 "Git 伺服器"；代理一個 Git 倉庫只需要花費很少的資源，幾乎從不需要整個伺服器來支援它的運行。
+到目前為止，你應該已經學會了使用 Git 來完成日常工作。然而，如果想與他人合作，還需要一個遠端的 Git 倉庫。儘管技術上可以從個人的倉庫裡推送和拉取修改內容，但我們不鼓勵這樣做，因為一不留心就很容易弄混其他人的進度。另外，你也一定希望合作者們即使在自己不開機的時候也能從倉庫取得資料 — 擁有一個更穩定的公開倉庫十分有用。因此，更好的合作方式是建立一個大家都可以存取的共用倉庫，從那裡推送和拉取資料。我們將把這個倉庫稱為 "Git 伺服器"；代理一個 Git 倉庫只需要花費很少的資源，幾乎從不需要整個伺服器來支援它的執行。
 
-架設一台 Git 伺服器並不難。第一步是選擇與伺服器通訊的協定。本章第一節將介紹可用的協議以及各自優缺點。下面一節將介紹一些針對各個協議典型的設置以及如何在伺服器上實施。最後，如果你不介意在他人伺服器上保存你的代碼，又想免去自己架設和維護伺服器的麻煩，倒可以試試我們介紹的幾個倉庫託管服務。
+架設一台 Git 伺服器並不難。第一步是選擇與伺服器通訊的協定。本章第一節將介紹可用的協議以及各自優缺點。下面一節將介紹一些針對各個協議典型的設定以及如何在伺服器上實施。最後，如果你不介意在他人伺服器上保存你的代碼，又想免去自己架設和維護伺服器的麻煩，倒可以試試我們介紹的幾個倉庫託管服務。
 
-如果你對架設自己的伺服器沒興趣，可以跳到本章最後一節去看看如何申請一個代碼託管服務的帳戶然後繼續下一章，我們會在那裡討論分散式源碼控制環境的林林總總。
+如果你對架設自己的伺服器沒興趣，可以跳到本章最後一節去看看如何申請一個代碼託管服務的帳戶然後繼續下一章，我們會在那裡討論分散式原始碼控制環境的林林總總。
 
-遠端倉庫通常只是一個_裸倉庫（bare repository）_ — 即一個沒有當前工作目錄的倉庫。因為該倉庫只是一個合作媒介，所以不需要從硬碟上取出最新版本的快照；倉庫裡存放的僅僅是 Git 的資料。簡單地說，裸倉庫就是你工作目錄中 `.git` 子目錄內的內容。
+遠端倉庫通常只是一個_裸倉庫（bare repository）_ — 即一個沒有目前工作目錄的倉庫。因為該倉庫只是一個合作媒介，所以不需要從硬碟上取出最新版本的快照；倉庫裡存放的僅僅是 Git 的資料。簡單地說，裸倉庫就是你工作目錄中 `.git` 子目錄內的內容。
 
 ## 協議 ##
 
 Git 可以使用四種主要的協定來傳輸資料：本地傳輸，SSH 協定，Git 協定和 HTTP 協定。下面分別介紹一下哪些情形應該使用（或避免使用）這些協定。
 
-值得注意的是，除了 HTTP 協定外，其他所有協定都要求在伺服器端安裝並運行 Git。
+值得注意的是，除了 HTTP 協定外，其他所有協定都要求在伺服器端安裝並執行 Git。
 
 ### 本地協定 ###
 
-最基本的就是_本地協議（Local protocol）_，所謂的遠端倉庫在該協定中的表示，就是硬碟上的另一個目錄。這常見於團隊每一個成員都對一個共用的檔案系統（例如 NFS）擁有訪問權，或者比較少見的多人共用同一台電腦的情況。後面一種情況並不安全，因為所有代碼倉庫實例都儲存在同一台電腦裡，增加了災難性資料損失的可能性。
+最基本的就是_本地協議（Local protocol）_，所謂的遠端倉庫在該協定中的表示，就是硬碟上的另一個目錄。這常見於團隊每一個成員都對一個共用的檔案系統（例如 NFS）擁有存取權，或者比較少見的多人共用同一台電腦的情況。後面一種情況並不安全，因為所有代碼倉庫實例都保存在同一台電腦裡，增加了災難性資料損失的可能性。
 
-如果你使用一個共用的檔案系統，就可以在一個本地檔案系統中克隆倉庫，推送和獲取。克隆的時候只需要將遠端倉庫的路徑作為 URL 使用，比如下面這樣：
+如果你使用一個共用的檔案系統，就可以在一個本地檔案系統中克隆倉庫，推送和取得。克隆的時候只需要將遠端倉庫的路徑作為 URL 使用，比如下面這樣：
 
 	$ git clone /opt/git/project.git
 
@@ -26,64 +26,64 @@ Git 可以使用四種主要的協定來傳輸資料：本地傳輸，SSH 協定
 
 	$ git clone file:///opt/git/project.git
 
-如果在 URL 開頭明確使用 `file://` ，那麼 Git 會以一種略微不同的方式運行。如果你只給出路徑，Git 會嘗試使用硬連結或直接複製它所需要的檔。如果使用了 `file://` ，Git 會調用它平時通過網路來傳輸資料的工序，而這種方式的效率相對較低。使用 `file://` 首碼的主要原因是當你需要一個不包含無關引用或物件的乾淨倉庫副本的時候 — 一般指從其他版本控制系統導入的，或類似情形（參見第 9 章的維護任務）。我們這裡僅僅使用普通路徑，這樣更快。
+如果在 URL 開頭明確使用 `file://` ，那麼 Git 會以一種略微不同的方式執行。如果你只給出路徑，Git 會嘗試使用硬連結或直接複製它所需要的檔案。如果使用了 `file://` ，Git 會呼叫它平時通過網路來傳輸資料的工序，而這種方式的效率相對較低。使用 `file://` 首碼的主要原因是當你需要一個不包含無關引用或物件的乾淨倉庫副本的時候 — 一般指從其他版本控制系統導入的，或類似情形（參見第 9 章的維護任務）。我們這裡僅僅使用普通路徑，這樣更快。
 
-要添加一個本地倉庫作為現有 Git 項目的遠端倉庫，可以這樣做：
+要增加一個本地倉庫作為現有 Git 專案的遠端倉庫，可以這樣做：
 
 	$ git remote add local_proj /opt/git/project.git
 
-然後就可以像在網路上一樣向這個遠端倉庫推送和獲取資料了。
+然後就可以像在網路上一樣向這個遠端倉庫推送和取得資料了。
 
 #### 優點 ####
 
-基於檔倉庫的優點在於它的簡單，同時保留了現存檔的許可權和網路存取權限。如果你的團隊已經有一個全體共用的檔案系統，建立倉庫就十分容易了。你只需把一份裸倉庫的副本放在大家都能訪問的地方，然後像對其他共用目錄一樣設置讀寫許可權就可以了。我們將在下一節“在伺服器上部署 Git ”中討論如何匯出一個裸倉庫的副本。
+基於檔案庫的優點在於它的簡單，同時保留了現存檔案的許可權和網路存取權限。如果你的團隊已經有一個全體共用的檔案系統，建立倉庫就十分容易了。你只需把一份裸倉庫的副本放在大家都能存取的地方，然後像對其他共用目錄一樣設定讀寫許可權就可以了。我們將在下一節“在伺服器上部署 Git ”中討論如何匯出一個裸倉庫的副本。
 
-這也是從別人工作目錄中獲取工作成果的快捷方法。假如你和你的同事在一個項目中合作，他們想讓你檢出一些東西的時候，運行類似 `git pull /home/john/project` 通常會比他們推送到伺服器，而你再從伺服器獲取簡單得多。
+這也是從別人工作目錄中取得工作成果的快速方法。假如你和你的同事在一個專案中合作，他們想讓你檢出一些東西的時候，執行類似 `git pull /home/john/project` 通常會比他們推送到伺服器，而你再從伺服器取得簡單得多。
 
 #### 缺點 ####
 
-這種方法的缺點是，與基本的網路連接訪問相比，難以控制從不同位置來的存取權限。如果你想從家裡的筆記型電腦上推送，就要先掛載遠端硬碟，這和基於網路連接的訪問相比更加困難和緩慢。
+這種方法的缺點是，與基本的網路連接存取相比，難以控制從不同位置來的存取權限。如果你想從家裡的筆記型電腦上推送，就要先掛載遠端硬碟，這和基於網路連接的存取相比更加困難和緩慢。
 
-另一個很重要的問題是該方法不一定就是最快的，尤其是對於共用掛載的檔案系統。本地倉庫只有在你對資料存取速度快的時候才快。在同一個伺服器上，如果二者同時允許 Git 訪問本地硬碟，通過 NFS 訪問倉庫通常會比 SSH 慢。
+另一個很重要的問題是該方法不一定就是最快的，尤其是對於共用掛載的檔案系統。本地倉庫只有在你對資料存取速度快的時候才快。在同一個伺服器上，如果二者同時允許 Git 存取本地硬碟，通過 NFS 存取倉庫通常會比 SSH 慢。
 
 ### SSH 協議 ###
 
-Git 使用的傳輸協議中最常見的可能就是 SSH 了。這是因為大多數環境已經支持通過 SSH 對伺服器的訪問 — 即便還沒有，架設起來也很容易。SSH 也是唯一一個同時支持讀寫操作的網路通訊協定。另外兩個網路通訊協定（HTTP 和 Git）通常都是唯讀的，所以雖然二者對大多數人都可用，但執行寫操作時還是需要 SSH。SSH 同時也是一個驗證授權的網路通訊協定；而因為其普遍性，一般架設和使用都很容易。
+Git 使用的傳輸協議中最常見的可能就是 SSH 了。這是因為大多數環境已經支持通過 SSH 對伺服器的存取 — 即便還沒有，架設起來也很容易。SSH 也是唯一一個同時支持讀寫操作的網路通訊協定。另外兩個網路通訊協定（HTTP 和 Git）通常都是唯讀的，所以雖然二者對大多數人都可用，但執行寫操作時還是需要 SSH。SSH 同時也是一個驗證授權的網路通訊協定；而因為其普遍性，一般架設和使用都很容易。
 
 通過 SSH 克隆一個 Git 倉庫，你可以像下面這樣給出 ssh:// 的 URL：
 
 	$ git clone ssh://user@server/project.git
 
-或者不指明某個協定 — 這時 Git 會預設使用 SSH ：
+或者不指定某個協定 — 這時 Git 會預設使用 SSH ：
 
 	$ git clone user@server:project.git
 
-如果不指明用戶，Git 會默認使用當前登錄的用戶名連接伺服器。 
+如果不指定用戶，Git 會預設使用目前登錄的使用者名稱連接伺服器。 
 
 #### 優點 ####
 
-使用 SSH 的好處有很多。首先，如果你想擁有對網路倉庫的寫許可權，基本上不可能不使用 SSH。其次，SSH 架設相對比較簡單 — SSH 守護進程很常見，很多網路系統管理員都有一些使用經驗，而且很多作業系統都自帶了它或者相關的管理工具。再次，通過 SSH 進行訪問是安全的 — 所有資料傳輸都是加密和授權的。最後，和 Git 及本地協議一樣，SSH 也很高效，會在傳輸之前盡可能壓縮資料。
+使用 SSH 的好處有很多。首先，如果你想擁有對網路倉庫的寫許可權，基本上不可能不使用 SSH。其次，SSH 架設相對比較簡單 — SSH 服務很常見，很多網路系統管理員都有一些使用經驗，而且很多作業系統都自帶了它或者相關的管理工具。再次，通過 SSH 進行存取是安全的 — 所有資料傳輸都是加密和授權的。最後，和 Git 及本地協議一樣，SSH 也很高效，會在傳輸之前盡可能壓縮資料。
 
 #### 缺點 ####
 
-SSH 的限制在於你不能通過它實現倉庫的匿名訪問。即使僅為讀取資料，人們也必須在能通過 SSH 訪問主機的前提下才能訪問倉庫，這使得 SSH 不利於開源的項目。如果你僅僅在公司網路裡使用，SSH 可能是你唯一需要使用的協定。如果想允許對項目的匿名唯讀訪問，那麼除了為自己推送而架設 SSH 協定之外，還需要支援其他協定以便他人訪問讀取。
+SSH 的限制在於你不能通過它實現倉庫的匿名存取。即使僅為讀取資料，人們也必須在能通過 SSH 存取主機的前提下才能存取倉庫，這使得 SSH 不利於開源的專案。如果你僅僅在公司網路裡使用，SSH 可能是你唯一需要使用的協定。如果想允許對專案的匿名唯讀存取，那麼除了為自己推送而架設 SSH 協定之外，還需要支援其他協定以便他人存取讀取。
 
 ### Git 協議 ###
 
-接下來是 Git 協議。這是一個包含在 Git 套裝軟體中的特殊守護進程； 它會監聽一個提供類似於 SSH 服務的特定埠（9418），而無需任何授權。打算支援 Git 協定的倉庫，需要先創建 `git-daemon-export-ok` 檔 — 它是協定進程提供倉庫服務的必要條件 — 但除此之外該服務沒有什麼安全措施。要麼所有人都能克隆 Git 倉庫，要麼誰也不能。這也意味著該協議通常不能用來進行推送。你可以允許推送操作；然而由於沒有授權機制，一旦允許該操作，網路上任何一個知道專案 URL 的人將都有推送許可權。不用說，這是十分罕見的情況。
+接下來是 Git 協議。這是一個包含在 Git 套裝軟體中的特殊服務； 它會監聽一個提供類似於 SSH 服務的特定埠（9418），而無需任何授權。打算支援 Git 協定的倉庫，需要先建立 `git-daemon-export-ok` 檔 — 它是協定行程提供倉庫服務的必要條件 — 但除此之外該服務沒有什麼安全措施。要麼所有人都能克隆 Git 倉庫，要麼誰也不能。這也意味著該協議通常不能用來進行推送。你可以允許推送操作；然而由於沒有授權機制，一旦允許該操作，網路上任何一個知道專案 URL 的人將都有推送許可權。不用說，這是十分罕見的情況。
 
 #### 優點 ####
 
-Git 協定是現存最快的傳輸協議。如果你在提供一個有很大訪問量的公共專案，或者一個不需要對讀操作進行授權的龐大項目，架設一個 Git 守護進程來供應倉庫是個不錯的選擇。它使用與 SSH 協定相同的資料傳輸機制，但省去了加密和授權的開銷。
+Git 協定是現存最快的傳輸協議。如果你在提供一個有很大存取量的公開專案，或者一個不需要對讀操作進行授權的龐大專案，架設一個 Git 服務來供應倉庫是個不錯的選擇。它使用與 SSH 協定相同的資料傳輸機制，但省去了加密和授權的開銷。
 
 #### 缺點 ####
 
-Git 協議消極的一面是缺少授權機制。用 Git 協議作為訪問專案的唯一方法通常是不可取的。一般的做法是，同時提供 SSH 介面，讓幾個開發者擁有推送（寫）許可權，其他人通過 `git://` 擁有唯讀許可權。
-Git 協定可能也是最難架設的協議。它要求有單獨的守護進程，需要定制 — 我們將在本章的 “Gitosis” 一節詳細介紹它的架設 — 需要設定 `xinetd` 或類似的程式，而這些工作就沒那麼輕鬆了。該協議還要求防火牆開放 9418 埠，而企業級防火牆一般不允許對這個非標準埠的訪問。大型企業級防火牆通常會封鎖這個少見的埠。
+Git 協議消極的一面是缺少授權機制。用 Git 協議作為存取專案的唯一方法通常是不可取的。一般的做法是，同時提供 SSH 介面，讓幾個開發者擁有推送（寫）許可權，其他人通過 `git://` 擁有唯讀許可權。
+Git 協定可能也是最難架設的協議。它要求有單獨的服務，需要定制 — 我們將在本章的 “Gitosis” 一節詳細介紹它的架設 — 需要設定 `xinetd` 或類似的程式，而這些工作就沒那麼輕鬆了。該協議還要求防火牆開放 9418 埠，而企業級防火牆一般不允許對這個非標準埠的存取。大型企業級防火牆通常會封鎖這個少見的埠。
 
 ### HTTP/S 協議 ###
 
-最後還有 HTTP 協議。HTTP 或 HTTPS 協議的優美之處在於架設的簡便性。基本上，只需要把 Git 的裸倉庫檔放在 HTTP 的根目錄下，配置一個特定的 `post-update` 掛鉤（hook）就可以搞定（Git 掛鉤的細節見第 7 章）。此後，每個能訪問 Git 倉庫所在伺服器上 web 服務的人都可以進行克隆操作。下面的操作可以允許通過 HTTP 對倉庫進行讀取：
+最後還有 HTTP 協議。HTTP 或 HTTPS 協議的優美之處在於架設的簡便性。基本上，只需要把 Git 的裸倉庫檔放在 HTTP 的根目錄下，設定一個特定的 `post-update` 掛鉤（hook）就可以搞定（Git 掛鉤的細節見第 7 章）。此後，每個能存取 Git 倉庫所在伺服器上 web 服務的人都可以進行克隆操作。下面的操作可以允許通過 HTTP 對倉庫進行讀取：
 
 	$ cd /var/www/htdocs/
 	$ git clone --bare /path/to/git_project gitproject.git
@@ -91,7 +91,7 @@ Git 協定可能也是最難架設的協議。它要求有單獨的守護進程
 	$ mv hooks/post-update.sample hooks/post-update
 	$ chmod a+x hooks/post-update
 
-這樣就可以了。Git 附帶的 `post-update` 掛鉤會默認運行合適的命令（`git update-server-info`）來確保通過 HTTP 的獲取和克隆正常工作。這條命令在你用 SSH 向倉庫推送內容時運行；之後，其他人就可以用下面的命令來克隆倉庫：
+這樣就可以了。Git 附帶的 `post-update` 掛鉤會預設執行合適的命令（`git update-server-info`）來確保通過 HTTP 的取得和克隆正常工作。這條命令在你用 SSH 向倉庫推送內容時執行；之後，其他人就可以用下面的命令來克隆倉庫：
 
 	$ git clone http://example.com/gitproject.git
 
@@ -101,11 +101,11 @@ Git 協定可能也是最難架設的協議。它要求有單獨的守護進程
 
 #### 優點 ####
 
-使用 HTTP 協定的好處是易於架設。幾條必要的命令就可以讓全世界讀取到倉庫的內容。花費不過幾分鐘。HTTP 協議不會佔用過多伺服器資源。因為它一般只用到靜態的 HTTP 服務提供所有資料，普通的 Apache 伺服器平均每秒能支撐數千個檔的併發訪問 — 哪怕讓一個小型伺服器超載都很難。
+使用 HTTP 協定的好處是易於架設。幾條必要的命令就可以讓全世界讀取到倉庫的內容。花費不過幾分鐘。HTTP 協議不會佔用過多伺服器資源。因為它一般只用到靜態的 HTTP 服務提供所有資料，普通的 Apache 伺服器平均每秒能支撐數千個檔的併發存取 — 哪怕讓一個小型伺服器超載都很難。
 
-你也可以通過 HTTPS 提供唯讀的倉庫，這意味著你可以加密傳輸內容；你甚至可以要求用戶端使用特定簽名的 SSL 證書。一般情況下，如果到了這一步，使用 SSH 公共金鑰可能是更簡單的方案；不過也存在一些特殊情況，這時通過 HTTPS 使用帶簽名的 SSL 證書或者其他基於 HTTP 的唯讀連接授權方式是更好的解決方案。
+你也可以通過 HTTPS 提供唯讀的倉庫，這意味著你可以加密傳輸內容；你甚至可以要求用戶端使用特定簽名的 SSL 證書。一般情況下，如果到了這一步，使用 SSH 公開金鑰可能是更簡單的方案；不過也存在一些特殊情況，這時通過 HTTPS 使用帶簽名的 SSL 證書或者其他基於 HTTP 的唯讀連接授權方式是更好的解決方案。
 
-HTTP 還有個額外的好處：HTTP 是一個如此常見的協議，以至於企業級防火牆通常都允許其埠的通信。
+HTTP 還有個額外的好處：HTTP 是一個非常常見的協議，所以企業級防火牆通常都允許該連接埠的通訊。
 
 #### 缺點 ####
 
@@ -113,7 +113,7 @@ HTTP 協議的消極面在於，相對來說用戶端效率更低。克隆或者
 
 ## 在伺服器上部署 Git ##
 
-開始架設 Git 伺服器前，需要先把現有倉庫匯出為裸倉庫 — 即一個不包含當前工作目錄的倉庫。做法直截了當，克隆時用 `--bare` 選項即可。裸倉庫的目錄名一般以 `.git` 結尾，像這樣：
+開始架設 Git 伺服器前，需要先把現有倉庫匯出為裸倉庫 — 即一個不包含目前工作目錄的倉庫。做法直截了當，克隆時用 `--bare` 選項即可。裸倉庫的目錄名一般以 `.git` 結尾，像這樣：
 
 	$ git clone --bare my_project my_project.git
 	Cloning into bare repository 'my_project.git'...
@@ -125,57 +125,57 @@ HTTP 協議的消極面在於，相對來說用戶端效率更低。克隆或者
 
 	$ cp -Rf my_project/.git my_project.git
 
-但在設定檔中有若干小改動，不過對使用者來講，使用方式都一樣，不會有什麼影響。它僅取出 Git 倉庫的必要原始資料，存放在該目錄中，而不會另外創建工作目錄。
+但在設定檔中有若干小改動，不過對使用者來講，使用方式都一樣，不會有什麼影響。它僅取出 Git 倉庫的必要原始資料，存放在該目錄中，而不會另外建立工作目錄。
 
 ### 把裸倉庫移到伺服器上 ###
 
-有了裸倉庫的副本後，剩下的就是把它放到伺服器上並設定相關協定。假設一個功能變數名稱為 `git.example.com` 的伺服器已經架設好，並可以通過 SSH 訪問，我們打算把所有 Git 倉庫儲存在 `/opt/git` 目錄下。只要把裸倉庫複製過去：
+有了裸倉庫的副本後，剩下的就是把它放到伺服器上並設定相關協定。假設一個功能變數名稱為 `git.example.com` 的伺服器已經架設好，並可以通過 SSH 存取，我們打算把所有 Git 倉庫保存在 `/opt/git` 目錄下。只要把裸倉庫複製過去：
 
 	$ scp -r my_project.git user@git.example.com:/opt/git
 
-現在，所有對該伺服器有 SSH 存取權限，並可讀取 `/opt/git` 目錄的使用者都可以用下面的命令克隆該項目：
+現在，所有對該伺服器有 SSH 存取權限，並可讀取 `/opt/git` 目錄的使用者都可以用下面的命令克隆該專案：
 
 	$ git clone user@git.example.com:/opt/git/my_project.git
 
-如果某個 SSH 用戶對 `/opt/git/my_project.git` 目錄有寫許可權，那他就有推送許可權。如果到該專案目錄中運行 `git init` 命令，並加上 `--shared` 選項，那麼 Git 會自動修改該倉庫目錄的組許可權為可寫（譯注：實際上 `--shared` 可以指定其他行為，只是默認為將組許可權改為可寫並執行 `g+sx`，所以最後會得到 `rws`。）。
+如果某個 SSH 用戶對 `/opt/git/my_project.git` 目錄有寫許可權，那他就有推送許可權。如果到該專案目錄中執行 `git init` 命令，並加上 `--shared` 選項，那麼 Git 會自動修改該倉庫目錄的組許可權為可寫（譯注：實際上 `--shared` 可以指定其他行為，只是預設為將組許可權改為可寫並執行 `g+sx`，所以最後會得到 `rws`。）。
 
 	$ ssh user@git.example.com
 	$ cd /opt/git/my_project.git
 	$ git init --bare --shared
 
-由此可見，根據現有的 Git 倉庫創建一個裸倉庫，然後把它放上你和同事都有 SSH 訪問權的伺服器是多麼容易。現在已經可以開始在同一專案上密切合作了。
+由此可見，根據現有的 Git 倉庫建立一個裸倉庫，然後把它放上你和同事都有 SSH 存取權的伺服器是多麼容易。現在已經可以開始在同一專案上密切合作了。
 
 值得注意的是，這的的確確是架設一個少數人具有連接權的 Git 服務的全部 — 只要在伺服器上加入可以用 SSH 登錄的帳號，然後把裸倉庫放在大家都有讀寫許可權的地方。一切都準備停當，無需更多。
 
-下面的幾節中，你會瞭解如何擴展到更複雜的設定。這些內容包含如何避免為每一個用戶建立一個帳戶，給倉庫添加公共讀取許可權，架設網頁介面，使用 Gitosis 工具等等。然而，只是和幾個人在一個不公開的專案上合作的話，僅僅是一個 SSH 伺服器和裸倉庫就足夠了，記住這點就可以了。
+下面的幾節中，你會瞭解如何擴展到更複雜的設定。這些內容包含如何避免為每一個用戶建立一個帳戶，給倉庫增加公開讀取許可權，架設網頁介面，使用 Gitosis 工具等等。然而，只是和幾個人在一個不公開的專案上合作的話，僅僅是一個 SSH 伺服器和裸倉庫就足夠了，記住這點就可以了。
 
 ### 小型安裝 ###
 
-如果設備較少或者你只想在小型開發團隊裡嘗試 Git ，那麼一切都很簡單。架設 Git 服務最複雜的地方在於帳戶管理。如果需要倉庫對特定的使用者可讀，而給另一部分用戶讀寫許可權，那麼訪問和許可的安排就比較困難。
+如果設備較少或者你只想在小型開發團隊裡嘗試 Git ，那麼一切都很簡單。架設 Git 服務最複雜的地方在於帳戶管理。如果需要倉庫對特定的使用者可讀，而給另一部分用戶讀寫許可權，那麼存取和許可的安排就比較困難。
 
 #### SSH 連接 ####
 
-如果已經有了一個所有開發成員都可以用 SSH 訪問的伺服器，架設第一個伺服器將變得異常簡單，幾乎什麼都不用做（正如上節中介紹的那樣）。如果需要對倉庫進行更複雜的存取控制，只要使用伺服器作業系統的本地檔訪問許可機制就行了。
+如果已經有了一個所有開發成員都可以用 SSH 存取的伺服器，架設第一個伺服器將變得異常簡單，幾乎什麼都不用做（正如上節中介紹的那樣）。如果需要對倉庫進行更複雜的存取控制，只要使用伺服器作業系統的本地檔存取許可機制就行了。
 
-如果需要團隊裡的每個人都對倉庫有寫許可權，又不能給每個人在伺服器上建立帳戶，那麼提供 SSH 連接就是唯一的選擇了。我們假設用來共用倉庫的伺服器已經安裝了 SSH 服務，而且你通過它訪問伺服器。
+如果需要團隊裡的每個人都對倉庫有寫許可權，又不能給每個人在伺服器上建立帳戶，那麼提供 SSH 連接就是唯一的選擇了。我們假設用來共用倉庫的伺服器已經安裝了 SSH 服務，而且你通過它存取伺服器。
 
-有好幾個辦法可以讓團隊的每個人都有訪問權。第一個辦法是給每個人建立一個帳戶，直截了當但略過繁瑣。反復運行 `adduser` 並給所有人設定臨時密碼可不是好玩的。
+有好幾個辦法可以讓團隊的每個人都有存取權。第一個辦法是給每個人建立一個帳戶，直截了當但略過繁瑣。反覆執行 `adduser` 並給所有人設定臨時密碼可不是好玩的。
 
-第二個辦法是在主機上建立一個 `git` 帳戶，讓每個需要寫許可權的人發送一個 SSH 公開金鑰，然後將其加入 `git` 帳戶的 `~/.ssh/authorized_keys` 文件。這樣一來，所有人都將通過 `git` 帳戶訪問主機。這絲毫不會影響提交的資料 — 訪問主機用的身份不會影響提交物件的提交者資訊。
+第二個辦法是在主機上建立一個 `git` 帳戶，讓每個需要寫許可權的人發送一個 SSH 公開金鑰，然後將其加入 `git` 帳戶的 `~/.ssh/authorized_keys` 文件。這樣一來，所有人都將通過 `git` 帳戶存取主機。這絲毫不會影響提交的資料 — 存取主機用的身份不會影響提交物件的提交者資訊。
 
-另一個辦法是讓 SSH 伺服器通過某個 LDAP 服務，或者其他已經設定好的集中授權機制，來進行授權。只要每個人都能獲得主機的 shell 訪問權，任何可用的 SSH 授權機制都能達到相同效果。
+另一個辦法是讓 SSH 伺服器通過某個 LDAP 服務，或者其他已經設定好的集中授權機制，來進行授權。只要每個人都能獲得主機的 shell 存取權，任何可用的 SSH 授權機制都能達到相同效果。
 
 ## 生成 SSH 公開金鑰 ##
 
 大多數 Git 伺服器都會選擇使用 SSH 公開金鑰來進行授權。系統中的每個使用者都必須提供一個公開金鑰用於授權，沒有的話就要生成一個。生成公開金鑰的過程在所有作業系統上都差不多。
-首先先確認一下是否已經有一個公開金鑰了。SSH 公開金鑰預設儲存在帳戶的主目錄下的 `~/.ssh` 目錄。進去看看：
+首先先確認一下是否已經有一個公開金鑰了。SSH 公開金鑰預設保存在帳戶的主目錄下的 `~/.ssh` 目錄。進去看看：
 
 	$ cd ~/.ssh
 	$ ls
 	authorized_keys2  id_dsa       known_hosts
 	config            id_dsa.pub
 
-關鍵是看有沒有用 `something` 和 `something.pub` 來命名的一對檔，這個 `something` 通常就是 `id_dsa` 或 `id_rsa`。有 `.pub` 尾碼的檔就是公開金鑰，另一個檔則是金鑰。假如沒有這些檔，或者乾脆連 `.ssh` 目錄都沒有，可以用 `ssh-keygen` 來創建。該程式在 Linux/Mac 系統上由 SSH 包提供，而在 Windows 上則包含在 MSysGit 包裡：
+關鍵是看有沒有用 `something` 和 `something.pub` 來命名的一對檔，這個 `something` 通常就是 `id_dsa` 或 `id_rsa`。有 `.pub` 尾碼的檔就是公開金鑰，另一個檔則是金鑰。假如沒有這些檔，或者乾脆連 `.ssh` 目錄都沒有，可以用 `ssh-keygen` 來建立。該程式在 Linux/Mac 系統上由 SSH 包提供，而在 Windows 上則包含在 MSysGit 包裡：
 
 	$ ssh-keygen
 	Generating public/private rsa key pair.
@@ -203,14 +203,14 @@ HTTP 協議的消極面在於，相對來說用戶端效率更低。克隆或者
 
 ## 架設伺服器 ##
 
-現在我們過一邊伺服器端架設 SSH 訪問的流程。本例將使用 `authorized_keys` 方法來給用戶授權。我們還將假定使用類似 Ubuntu 這樣的標準 Linux 發行版本。首先，創建一個名為 'git' 的用戶，並為其創建一個 `.ssh` 目錄。
+現在我們過一邊伺服器端架設 SSH 存取的流程。本例將使用 `authorized_keys` 方法來給用戶授權。我們還將假定使用類似 Ubuntu 這樣的標準 Linux 發行版本。首先，建立一個名為 'git' 的用戶，並為其建立一個 `.ssh` 目錄。
 
 	$ sudo adduser git
 	$ su git
 	$ cd
 	$ mkdir .ssh
 
-接下來，把開發者的 SSH 公開金鑰添加到這個用戶的 `authorized_keys` 檔中。假設你通過電郵收到了幾個公開金鑰並存到了暫存檔案裡。重複一下，公開金鑰大致看起來是這個樣子：
+接下來，把開發者的 SSH 公開金鑰增加到這個用戶的 `authorized_keys` 檔中。假設你通過電子郵件收到了幾個公開金鑰並存到了暫存檔案裡。重複一下，公開金鑰大致看起來是這個樣子：
 
 	$ cat /tmp/id_rsa.john.pub
 	ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCB007n/ww+ouN4gSLKssMxXnBOvf9LGt4L
@@ -226,14 +226,14 @@ HTTP 協議的消極面在於，相對來說用戶端效率更低。克隆或者
 	$ cat /tmp/id_rsa.josie.pub >> ~/.ssh/authorized_keys
 	$ cat /tmp/id_rsa.jessica.pub >> ~/.ssh/authorized_keys
 
-現在可以用 `--bare` 選項運行 `git init` 來建立一個裸倉庫，這會初始化一個不包含工作目錄的倉庫。
+現在可以用 `--bare` 選項執行 `git init` 來建立一個裸倉庫，這會初始化一個不包含工作目錄的倉庫。
 
 	$ cd /opt/git
 	$ mkdir project.git
 	$ cd project.git
 	$ git --bare init
 
-這時，Join，Josie 或者 Jessica 就可以把它加為遠端倉庫，推送一個分支，從而把第一個版本的專案檔案上傳到倉庫裡了。值得注意的是，每次添加一個新專案都需要通過 shell 登入主機並創建一個裸倉庫目錄。我們不妨以 `gitserver` 作為 `git` 用戶及項目倉庫所在的主機名稱。如果在網路內部運行該主機，並在 DNS 中設定 `gitserver` 指向該主機，那麼以下這些命令都是可用的：
+這時，Join，Josie 或者 Jessica 就可以把它加為遠端倉庫，推送一個分支，從而把第一個版本的專案檔案上傳到倉庫裡了。值得注意的是，每次增加一個新專案都需要通過 shell 登入主機並建立一個裸倉庫目錄。我們不妨以 `gitserver` 作為 `git` 用戶及專案倉庫所在的主機名稱。如果在網路內部執行該主機，並在 DNS 中設定 `gitserver` 指向該主機，那麼以下這些命令都是可用的：
 
 	# 在 John 的電腦上
 	$ cd myproject
@@ -251,7 +251,7 @@ HTTP 協議的消極面在於，相對來說用戶端效率更低。克隆或者
 	$ git commit -am 'fix for the README file'
 	$ git push origin master
 
-用這個方法可以很快捷地為少數幾個開發者架設一個可讀寫的 Git 服務。
+用這個方法可以很快速地為少數幾個開發者架設一個可讀寫的 Git 服務。
 
 作為一個額外的防範措施，你可以用 Git 自帶的 `git-shell` 工具限制 `git` 用戶的活動範圍。只要把它設為 `git` 用戶登入的 shell，那麼該用戶就無法使用普通的 bash 或者 csh 什麼的 shell 程式。編輯 `/etc/passwd` 檔：
 
@@ -265,17 +265,17 @@ HTTP 協議的消極面在於，相對來說用戶端效率更低。克隆或者
 
 	git:x:1000:1000::/home/git:/usr/bin/git-shell
 
-現在 `git` 用戶只能用 SSH 連接來推送和獲取 Git 倉庫，而不能直接使用主機 shell。嘗試普通 SSH 登錄的話，會看到下面這樣的拒絕資訊：
+現在 `git` 用戶只能用 SSH 連接來推送和取得 Git 倉庫，而不能直接使用主機 shell。嘗試普通 SSH 登錄的話，會看到下面這樣的拒絕資訊：
 
 	$ ssh git@gitserver
 	fatal: What do you think I am? A shell?
 	Connection to gitserver closed.
 
-## 公共訪問 ##
+## 公開存取 ##
 
 匿名的讀取許可權該怎麼實現呢？也許除了內部私有的專案之外，你還需要託管一些開源專案。或者因為要用一些自動化的伺服器來進行編譯，或者有一些經常變化的伺服器群組，而又不想整天生成新的 SSH 金鑰 — 總之，你需要簡單的匿名讀取許可權。
 
-或許對小型的配置來說最簡單的辦法就是運行一個靜態 web 服務，把它的根目錄設定為 Git 倉庫所在的位置，然後開啟本章第一節提到的 `post-update` 掛鉤。這裡繼續使用之前的例子。假設倉庫處於 `/opt/git` 目錄，主機上運行著 Apache 服務。重申一下，任何 web 服務程式都可以達到相同效果；作為範例，我們將用一些基本的 Apache 設定來展示大體需要的步驟。
+或許對小型的設定來說最簡單的辦法就是執行一個靜態 web 服務，把它的根目錄設定為 Git 倉庫所在的位置，然後開啟本章第一節提到的 `post-update` 掛鉤。這裡繼續使用之前的例子。假設倉庫處於 `/opt/git` 目錄，主機上執行著 Apache 服務。重申一下，任何 web 服務程式都可以達到相同效果；作為範例，我們將用一些基本的 Apache 設定來示範大體需要的步驟。
 
 首先，開啟掛鉤：
 
@@ -296,9 +296,9 @@ HTTP 協議的消極面在於，相對來說用戶端效率更低。克隆或者
 	
 	exec git-update-server-info
 
-意思是當通過 SSH 向伺服器推送時，Git 將運行這個 `git-update-server-info` 命令來更新匿名 HTTP 訪問獲取資料時所需要的檔。
+意思是當通過 SSH 向伺服器推送時，Git 將執行這個 `git-update-server-info` 命令來更新匿名 HTTP 存取取得資料時所需要的檔案。
 
-接下來，在 Apache 設定檔中添加一個 VirtualHost 條目，把文檔根目錄設為 Git 專案所在的根目錄。這裡我們假定 DNS 服務已經配置好，會把對 `.gitserver` 的請求發送到這台主機：
+接下來，在 Apache 設定檔中增加一個 VirtualHost 條目，把文檔根目錄設為 Git 專案所在的根目錄。這裡我們假定 DNS 服務已經設定好，會把對 `.gitserver` 的請求發送到這台主機：
 
 	<VirtualHost *:80>
 	    ServerName git.gitserver
@@ -309,7 +309,7 @@ HTTP 協議的消極面在於，相對來說用戶端效率更低。克隆或者
 	    </Directory>
 	</VirtualHost>
 
-另外，需要把 `/opt/git` 目錄的 Unix 使用者組設定為 `www-data` ，這樣 web 服務才可以讀取倉庫內容，因為運行 CGI 腳本的  Apache 實例進程預設就是以該使用者的身份起來的：
+另外，需要把 `/opt/git` 目錄的 Unix 使用者組設定為 `www-data` ，這樣 web 服務才可以讀取倉庫內容，因為執行 CGI 腳本的  Apache 實例行程預設就是以該使用者的身份起來的：
 
 	$ chgrp -R www-data /opt/git
 
@@ -317,16 +317,16 @@ HTTP 協議的消極面在於，相對來說用戶端效率更低。克隆或者
 
 	$ git clone http://git.gitserver/project.git
 
-這一招可以讓你在幾分鐘內為相當數量的用戶架設好基於 HTTP 的讀取許可權。另一個提供非授權訪問的簡單方法是開啟一個 Git 守護進程，不過這將要求該進程作為後臺進程常駐 — 接下來的這一節就要討論這方面的細節。
+這一招可以讓你在幾分鐘內為相當數量的用戶架設好基於 HTTP 的讀取許可權。另一個提供未經授權存取的簡單方法是開啟一個 Git 服務，不過這將要求該行程作為後臺行程常駐 — 接下來的這一節就要討論這方面的細節。
 
 ## GitWeb ##
 
-現在我們的項目已經有了可讀可寫和唯讀的連接方式，不過如果能有一個簡單的 web 介面訪問就更好了。Git 自帶一個叫做 GitWeb 的 CGI 腳本，運行效果可以到 `http://git.kernel.org` 這樣的網站體驗下（見圖 4-1）。
+現在我們的專案已經有了可讀可寫和唯讀的連接方式，不過如果能有一個簡單的 web 介面存取就更好了。Git 自帶一個叫做 GitWeb 的 CGI 腳本，執行效果可以到 `http://git.kernel.org` 這樣的網站體驗下（見圖 4-1）。
 
 Insert 18333fig0401.png
 Figure 4-1. 基於網頁的 GitWeb 使用者介面
 
-如果想看看自己項目的效果，不妨用 Git 自帶的一個命令，可以使用類似 `lighttpd` 或 `webrick` 這樣羽量級的伺服器啟動一個臨時進程。如果是在 Linux 主機上，通常都預裝了 `lighttpd` ，可以到專案目錄中鍵入 `git instaweb` 來啟動。如果用的是 Mac ，Leopard 預裝了 Ruby，所以 `webrick` 應該是最好的選擇。如果要用 lighttpd 以外的程式來啟動 `git instaweb`，可以通過 `--httpd` 選項指定：
+如果想看看自己專案的效果，不妨用 Git 自帶的一個命令，可以使用類似 `lighttpd` 或 `webrick` 這樣羽量級的伺服器啟動一個臨時行程。如果是在 Linux 主機上，通常都預裝了 `lighttpd` ，可以到專案目錄中鍵入 `git instaweb` 來啟動。如果用的是 Mac ，Leopard 預裝了 Ruby，所以 `webrick` 應該是最好的選擇。如果要用 lighttpd 以外的程式來啟動 `git instaweb`，可以通過 `--httpd` 選項指定：
 
 	$ git instaweb --httpd=webrick
 	[2009-02-21 10:02:21] INFO  WEBrick 1.3.1
@@ -336,7 +336,7 @@ Figure 4-1. 基於網頁的 GitWeb 使用者介面
 
 	$ git instaweb --httpd=webrick --stop
 
-如果需要為團隊或者某個開源專案長期運行 GitWeb，那麼 CGI 腳本就要由正常的網頁服務來運行。一些 Linux 發行版本可以通過 `apt` 或 `yum` 安裝一個叫做 `gitweb` 的套裝軟體，不妨首先嘗試一下。我們將快速介紹一下手動安裝 GitWeb 的流程。首先，你需要 Git 的源碼，其中帶有 GitWeb，並能生成定制的 CGI 腳本：
+如果需要為團隊或者某個開源專案長期執行 GitWeb，那麼 CGI 腳本就要由正常的網頁服務來執行。一些 Linux 發行版本可以通過 `apt` 或 `yum` 安裝一個叫做 `gitweb` 的套裝軟體，不妨首先嘗試一下。我們將快速介紹一下手動安裝 GitWeb 的流程。首先，你需要 Git 的原始碼，其中帶有 GitWeb，並能生成定制的 CGI 腳本：
 
 	$ git clone git://git.kernel.org/pub/scm/git/git.git
 	$ cd git/
@@ -344,7 +344,7 @@ Figure 4-1. 基於網頁的 GitWeb 使用者介面
 	        prefix=/usr gitweb
 	$ sudo cp -Rf gitweb /var/www/
 
-注意，通過指定 `GITWEB_PROJECTROOT` 變數告訴編譯命令 Git 倉庫的位置。然後，設置 Apache 以 CGI 方式運行該腳本，添加一個 VirtualHost 配置：
+注意，通過指定 `GITWEB_PROJECTROOT` 變數告訴編譯命令 Git 倉庫的位置。然後，設定 Apache 以 CGI 方式執行該腳本，增加一個 VirtualHost 設定：
 
 	<VirtualHost *:80>
 	    ServerName gitserver
@@ -359,13 +359,13 @@ Figure 4-1. 基於網頁的 GitWeb 使用者介面
 	    </Directory>
 	</VirtualHost>
 
-不難想像，GitWeb 可以使用任何相容 CGI 的網頁服務來運行；如果偏向使用其他 web 伺服器，配置也不會很麻煩。現在，通過 `http://gitserver` 就可以線上訪問倉庫了，在 `http://git.server` 上還可以通過 HTTP 克隆和獲取倉庫的內容。
+不難想像，GitWeb 可以使用任何相容 CGI 的網頁服務來執行；如果偏向使用其他 web 伺服器，設定也不會很麻煩。現在，通過 `http://gitserver` 就可以線上存取倉庫了，在 `http://git.server` 上還可以通過 HTTP 克隆和取得倉庫的內容。
 
 ## Gitosis ##
 
 把所有用戶的公開金鑰保存在 `authorized_keys` 檔的做法，只能湊和一陣子，當用戶數量達到幾百人的規模時，管理起來就會十分痛苦。每次改刪用戶都必須登錄伺服器不去說，這種做法還缺少必要的許可權管理 — 每個人都對所有專案擁有完整的讀寫許可權。
 
-幸好我們還可以選擇應用廣泛的 Gitosis 項目。簡單地說，Gitosis 就是一套用來管理 `authorized_keys` 檔和實現簡單連接限制的腳本。有趣的是，用來添加用戶和設定許可權的並非通過網頁程式，而只是管理一個特殊的 Git 倉庫。你只需要在這個特殊倉庫內做好相應的設定，然後推送到伺服器上，Gitosis 就會隨之改變運行策略，聽起來就很酷，對吧？
+幸好我們還可以選擇應用廣泛的 Gitosis 專案。簡單地說，Gitosis 就是一套用來管理 `authorized_keys` 檔和實現簡單連接限制的腳本。有趣的是，用來增加用戶和設定許可權的並非通過網頁程式，而只是管理一個特殊的 Git 倉庫。你只需要在這個特殊倉庫內做好相應的設定，然後推送到伺服器上，Gitosis 就會隨之改變執行策略，聽起來就很酷，對吧？
 
 Gitosis 的安裝算不上傻瓜化，但也不算太難。用 Linux 伺服器架設起來最簡單 — 以下例子中，我們使用裝有 Ubuntu 8.10 系統的伺服器。
 
@@ -373,17 +373,17 @@ Gitosis 的工作依賴於某些 Python 工具，所以首先要安裝 Python 
 
 	$ apt-get install python-setuptools
 
-接下來，從 Gitosis 項目主頁克隆並安裝：
+接下來，從 Gitosis 專案主頁克隆並安裝：
 
 	$ git clone https://github.com/tv42/gitosis.git
 	$ cd gitosis
 	$ sudo python setup.py install
 
-這會安裝幾個供 Gitosis 使用的工具。預設 Gitosis 會把 `/home/git` 作為存儲所有 Git 倉庫的根目錄，這沒什麼不好，不過我們之前已經把項目倉庫都放在 `/opt/git` 裡面了，所以為方便起見，我們可以做一個符號連接，直接劃轉過去，而不必重新配置：
+這會安裝幾個供 Gitosis 使用的工具。預設 Gitosis 會把 `/home/git` 作為存儲所有 Git 倉庫的根目錄，這沒什麼不好，不過我們之前已經把專案倉庫都放在 `/opt/git` 裡面了，所以為方便起見，我們可以做一個符號連接，直接劃轉過去，而不必重新設定：
 
 	$ ln -s /opt/git /home/git/repositories
 
-Gitosis 將會幫我們管理用戶公開金鑰，所以先把當前控制檔改名備份，以便稍後重新添加，準備好讓 Gitosis 自動管理 `authorized_keys` 文件：
+Gitosis 將會幫我們管理用戶公開金鑰，所以先把目前控制檔改名備份，以便稍後重新增加，準備好讓 Gitosis 自動管理 `authorized_keys` 文件：
 
 	$ mv /home/git/.ssh/authorized_keys /home/git/.ssh/ak.bak
 
@@ -401,7 +401,7 @@ Gitosis 將會幫我們管理用戶公開金鑰，所以先把當前控制檔改
 	Initialized empty Git repository in /opt/git/gitosis-admin.git/
 	Reinitialized existing Git repository in /opt/git/gitosis-admin.git/
 
-這樣該公開金鑰的擁有者就能修改用於配置 Gitosis 的那個特殊 Git 倉庫了。接下來，需要手工對該倉庫中的 `post-update` 腳本加上可執行許可權：
+這樣該公開金鑰的擁有者就能修改用於設定 Gitosis 的那個特殊 Git 倉庫了。接下來，需要手工對該倉庫中的 `post-update` 腳本加上可執行許可權：
 
 	$ sudo chmod 755 /opt/git/gitosis-admin.git/hooks/post-update
 
@@ -412,7 +412,7 @@ Gitosis 將會幫我們管理用戶公開金鑰，所以先把當前控制檔改
 	ERROR:gitosis.serve.main:Need SSH_ORIGINAL_COMMAND in environment.
 	  Connection to gitserver closed.
 
-說明 Gitosis 認出了該用戶的身份，但由於沒有運行任何 Git 命令，所以它切斷了連接。那麼，現在運行一個實際的 Git 命令 — 克隆 Gitosis 的控制倉庫：
+說明 Gitosis 認出了該用戶的身份，但由於沒有執行任何 Git 命令，所以它切斷了連接。那麼，現在執行一個實際的 Git 命令 — 克隆 Gitosis 的控制倉庫：
 
 	# 在你本地電腦上
 	$ git clone git@gitserver:gitosis-admin.git
@@ -425,7 +425,7 @@ Gitosis 將會幫我們管理用戶公開金鑰，所以先把當前控制檔改
 	./keydir
 	./keydir/scott.pub
 
-`gitosis.conf` 檔是用來設置用戶、倉庫和許可權的控制檔。`keydir` 目錄則是保存所有具有存取權限用戶公開金鑰的地方— 每人一個。在 `keydir` 裡的檔案名（比如上面的 `scott.pub`）應該跟你的不一樣 — Gitosis 會自動從使用 `gitosis-init` 腳本導入的公開金鑰尾部的描述中獲取該名字。
+`gitosis.conf` 檔是用來設定用戶、倉庫和許可權的控制檔。`keydir` 目錄則是保存所有具有存取權限用戶公開金鑰的地方— 每人一個。在 `keydir` 裡的檔案名（比如上面的 `scott.pub`）應該跟你的不一樣 — Gitosis 會自動從使用 `gitosis-init` 腳本導入的公開金鑰尾部的描述中取得該名字。
 
 看一下 `gitosis.conf` 檔的內容，它應該只包含與剛剛克隆的 `gitosis-admin` 相關的資訊：
 
@@ -438,7 +438,7 @@ Gitosis 將會幫我們管理用戶公開金鑰，所以先把當前控制檔改
 
 它顯示使用者 `scott` — 初始化 Gitosis 公開金鑰的擁有者 — 是唯一能管理 `gitosis-admin` 專案的人。
 
-現在我們來添加一個新項目。為此我們要建立一個名為 `mobile` 的新段落，在其中羅列手機開發團隊的開發者，以及他們擁有寫許可權的專案。由於 'scott' 是系統中的唯一使用者，我們把他設為唯一用戶，並允許他讀寫名為 `iphone_project` 的新項目：
+現在我們來增加一個新專案。為此我們要建立一個名為 `mobile` 的新段落，在其中羅列手機開發團隊的開發者，以及他們擁有寫許可權的專案。由於 'scott' 是系統中的唯一使用者，我們把他設為唯一用戶，並允許他讀寫名為 `iphone_project` 的新專案：
 
 	[group mobile]
 	members = scott
@@ -457,7 +457,7 @@ Gitosis 將會幫我們管理用戶公開金鑰，所以先把當前控制檔改
 	To git@gitserver:gitosis-admin.git
 	   fb27aec..8962da8  master -> master
 
-在新工程 `iphone_project` 裡首次推送資料到伺服器前，得先設定該伺服器地址為遠端倉庫。但你不用事先到伺服器上手工創建該項目的裸倉庫— Gitosis 會在第一次遇到推送時自動創建：
+在新工程 `iphone_project` 裡首次推送資料到伺服器前，得先設定該伺服器地址為遠端倉庫。但你不用事先到伺服器上手工建立該專案的裸倉庫— Gitosis 會在第一次遇到推送時自動建立：
 
 	$ git remote add origin git@gitserver:iphone_project.git
 	$ git push origin master
@@ -468,9 +468,9 @@ Gitosis 將會幫我們管理用戶公開金鑰，所以先把當前控制檔改
 	To git@gitserver:iphone_project.git
 	 * [new branch]      master -> master
 
-請注意，這裡不用指明完整路徑（實際上，如果加上反而沒用），只需要一個冒號加項目名字即可 — Gitosis 會自動幫你映射到實際位置。
+請注意，這裡不用指定完整路徑（實際上，如果加上反而沒用），只需要一個冒號加專案名字即可 — Gitosis 會自動幫你映射到實際位置。
 
-要和朋友們在一個專案上協同工作，就得重新添加他們的公開金鑰。不過這次不用在伺服器上一個一個手工添加到 `~/.ssh/authorized_keys` 檔末端，而只需管理 `keydir` 目錄中的公開金鑰檔。文件的命名將決定在 `gitosis.conf` 中對使用者的標識。現在我們為 John，Josie 和 Jessica 添加公開金鑰：
+要和朋友們在一個專案上協同工作，就得重新增加他們的公開金鑰。不過這次不用在伺服器上一個一個手工增加到 `~/.ssh/authorized_keys` 檔末端，而只需管理 `keydir` 目錄中的公開金鑰檔。文件的命名將決定在 `gitosis.conf` 中對使用者的標識。現在我們為 John，Josie 和 Jessica 增加公開金鑰：
 
 	$ cp /tmp/id_rsa.john.pub keydir/john.pub
 	$ cp /tmp/id_rsa.josie.pub keydir/josie.pub
@@ -482,7 +482,7 @@ Gitosis 將會幫我們管理用戶公開金鑰，所以先把當前控制檔改
 	members = scott john josie jessica
 	writable = iphone_project
 
-如果你提交並推送這個修改，四個用戶將同時具有該項目的讀寫許可權。
+如果你提交並推送這個修改，四個用戶將同時具有該專案的讀寫許可權。
 
 Gitosis 也具有簡單的存取控制功能。如果想讓 John 只有讀許可權，可以這樣做：
 
@@ -494,7 +494,7 @@ Gitosis 也具有簡單的存取控制功能。如果想讓 John 只有讀許可
 	members = john
 	readonly = iphone_project
 
-現在 John 可以克隆和獲取更新，但 Gitosis 不會允許他向專案推送任何內容。像這樣的組可以隨意創建，多少不限，每個都可以包含若干不同的用戶和項目。甚至還可以指定某個組為成員之一（在組名前加上 `@` 首碼），自動繼承該組的成員：
+現在 John 可以克隆和取得更新，但 Gitosis 不會允許他向專案推送任何內容。像這樣的組可以隨意建立，多少不限，每個都可以包含若干不同的用戶和專案。甚至還可以指定某個組為成員之一（在組名前加上 `@` 首碼），自動繼承該組的成員：
 
 	[group mobile_committers]
 	members = scott josie jessica
@@ -507,7 +507,7 @@ Gitosis 也具有簡單的存取控制功能。如果想讓 John 只有讀許可
 	members   = @mobile_committers john
 	writable  = another_iphone_project
 
-如果遇到意外問題，試試看把 `loglevel=DEBUG` 加到 `[gitosis]` 的段落（譯注：把日誌設置為調試級別，記錄更詳細的運行資訊。）。如果一不小心搞錯了配置，失去了推送許可權，也可以手工修改伺服器上的 `/home/git/.gitosis.conf` 檔 — Gitosis 實際是從該檔讀取資訊的。它在得到推送資料時，會把新的 `gitosis.conf` 存到該路徑上。所以如果你手工編輯該檔的話，它會一直保持到下次向 `gitosis-admin` 推送新版本的配置內容為止。
+如果遇到意外問題，試試看把 `loglevel=DEBUG` 加到 `[gitosis]` 的段落（譯注：把日誌設定為調試級別，記錄更詳細的執行資訊。）。如果一不小心搞錯了設定，失去了推送許可權，也可以手工修改伺服器上的 `/home/git/.gitosis.conf` 檔 — Gitosis 實際是從該檔讀取資訊的。它在得到推送資料時，會把新的 `gitosis.conf` 存到該路徑上。所以如果你手工編輯該檔的話，它會一直保持到下次向 `gitosis-admin` 推送新版本的設定內容為止。
 
 ## Gitolite ##
 
@@ -518,13 +518,13 @@ This section serves as a quick introduction to Gitolite, and provides basic inst
 
 Gitolite is an authorization layer on top of Git, relying on `sshd` or `httpd` for authentication.  (Recap: authentication is identifying who the user is, authorization is deciding if he is allowed to do what he is attempting to).
 
-Gitolite 允許你定義訪問許可而不只作用於倉庫，而同樣於倉庫中的每個branch和tag name。你可以定義確切的人 (或一組人) 只能push特定的 "refs" (或者branches或者tags)而不是其他人。
+Gitolite 允許你定義存取許可而不只作用於倉庫，而同樣於倉庫中的每個branch和tag name。你可以定義確切的人 (或一組人) 只能push特定的 "refs" (或者branches或者tags)而不是其他人。
 
 ### 安裝 ###
 
-安裝 Gitolite非常簡單, 你甚至不用讀自帶的那一大堆文檔。你需要一個unix伺服器上的帳戶；許多linux變種和solaris 10都已經試過了。你不需要root訪問，假設git，perl，和一個openssh相容的ssh伺服器已經裝好了。在下面的例子裡，我們會用 `git` 帳戶在 `gitserver`上.
+安裝 Gitolite非常簡單, 你甚至不用讀自帶的那一大堆文檔。你需要一個unix伺服器上的帳戶；許多linux變種和solaris 10都已經試過了。你不需要root存取，假設git，perl，和一個openssh相容的ssh伺服器已經裝好了。在下面的例子裡，我們會用 `git` 帳戶在 `gitserver`上.
 
-Gitolite 是不同於 "server" 的軟體 -- 通過ssh訪問, 而且每個在伺服器上的userid都是一個潛在的 "gitolite host". We will describe the simplest install method in this article; for the other methods please see the documentation.
+Gitolite 是不同於 "server" 的軟體 -- 通過ssh存取, 而且每個在伺服器上的userid都是一個潛在的 "gitolite host". We will describe the simplest install method in this article; for the other methods please see the documentation.
 
 To begin, create a user called `git` on your server and login to this user.  Copy your SSH public key (a file called `~/.ssh/id_rsa.pub` if you did a plain `ssh-keygen` with all the defaults) from your workstation, renaming it to `<yourname>.pub` (we'll use `scott.pub` in our examples).  Then run these commands:
 
@@ -539,9 +539,9 @@ Finally, back on your workstation, run `git clone git@gitserver:gitolite-admin`.
 
 ### 定制安裝 ###
 
-默認快速安裝對大多數人都管用，還有一些定制安裝方法如果你用的上的話。Some changes can be made simply by editing the rc file, but if that is not sufficient, there’s documentation on customising Gitolite.
+預設快速安裝對大多數人都管用，還有一些定制安裝方法如果你用的上的話。Some changes can be made simply by editing the rc file, but if that is not sufficient, there’s documentation on customising Gitolite.
 
-### 設定檔和訪問規則 ###
+### 設定檔和存取規則 ###
 
 安裝結束後，你切換到 `gitolite-admin` 倉庫 (放在你的 HOME 目錄) 然後看看都有啥：
 
@@ -585,7 +585,7 @@ gitolite設定檔的語法在 `conf/example.conf`裡，我們只會提到一些
 
 在 `RW` or `RW+`之後的運算式是規則運算式 (regex) 對應著後面的push用的參考名字 (ref) 。所以我們叫它 "參考正則"（refex）！當然，一個 refex 可以比這裡表現的更強大，所以如果你對perl的規則運算式不熟的話就不要改過頭。
 
-同樣，你可能猜到了，Gitolite 字頭 `refs/heads/` 是一個便捷句法如果參考正則沒有用 `refs/`開頭。
+同樣，你可能猜到了，Gitolite 字頭 `refs/heads/` 是一個方便句法如果參考正則沒有用 `refs/`開頭。
 
 一個這個設定檔語法的重要功能是，所有的倉庫的規則不需要在同一個位置。你能報所有普通的東西放在一起，就像上面的對所有 `oss_repos` 的規則那樣，然後建一個特殊的規則對後面的特殊案例，就像：
 
@@ -596,13 +596,13 @@ gitolite設定檔的語法在 `conf/example.conf`裡，我們只會提到一些
 
 這次你可能會想要知道存取控制規則是如何應用的，我們簡要介紹一下。
 
-在gitolite裡有兩級存取控制。第一是在倉庫級別；如果你已經讀或者寫訪問過了任何在倉庫裡的參考，那麼你已經讀或者寫訪問倉庫了。
+在gitolite裡有兩級存取控制。第一是在倉庫級別；如果你已經讀或者寫存取過了任何在倉庫裡的參考，那麼你已經讀或者寫存取倉庫了。
 
-第二級，應用只能寫訪問，通過在倉庫裡的 branch或者 tag。用戶名如果嘗試過訪問 (`W` 或 `+`)，參考名被更新為已知。訪問規則檢查是否出現在設定檔裡，為這個聯合尋找匹配 (但是記得參考名是正則匹配的，不是字串匹配的)。如果匹配被找到了，push就成功了。不匹配的訪問會被拒絕。
+第二級，應用只能寫存取，通過在倉庫裡的 branch或者 tag。使用者名稱如果嘗試過存取 (`W` 或 `+`)，參考名被更新為已知。存取規則檢查是否出現在設定檔裡，為這個聯合尋找匹配 (但是記得參考名是正則匹配的，不是字串匹配的)。如果匹配被找到了，push就成功了。不匹配的存取會被拒絕。
 
 ### 帶'拒絕'的高級存取控制 ###
 
-目前，我們只看過了許可是 `R`, `RW`, 或者 `RW+`這樣子的。但是gitolite還允許另外一種許可：`-`，代表 "拒絕"。這個給了你更多的能力，當然也有一點複雜，因為不匹配並不是唯一的拒絕訪問的方法，因此規則的順序變得無關了！
+目前，我們只看過了許可是 `R`, `RW`, 或者 `RW+`這樣子的。但是gitolite還允許另外一種許可：`-`，代表 "拒絕"。這個給了你更多的能力，當然也有一點複雜，因為不匹配並不是唯一的拒絕存取的方法，因此規則的順序變得無關了！
 
 這麼說好了，在前面的情況中，我們想要工程師可以 rewind 任意 branch 除了master和 integ。 這裡是如何做到的
 
@@ -610,7 +610,7 @@ gitolite設定檔的語法在 `conf/example.conf`裡，我們只會提到一些
 	    -   master integ    = @engineers
 	    RW+                 = @engineers
 
-你再一次簡單跟隨規則從上至下知道你找到一個匹配你的訪問模式的，或者拒絕。非rewind push到 master或者 integ 被第一條規則允許。一個 rewind push到那些 refs不匹配第一條規則，掉到第二條，因此被拒絕。任何 push (rewind 或非rewind) 到參考或者其他 master 或者 integ不會被前兩條規則匹配，即被第三條規則允許。
+你再一次簡單跟隨規則從上至下知道你找到一個匹配你的存取模式的，或者拒絕。非rewind push到 master或者 integ 被第一條規則允許。一個 rewind push到那些 refs不匹配第一條規則，掉到第二條，因此被拒絕。任何 push (rewind 或非rewind) 到參考或者其他 master 或者 integ不會被前兩條規則匹配，即被第三條規則允許。
 
 ### 通過改變檔限制 push ###
 
@@ -627,23 +627,23 @@ gitolite設定檔的語法在 `conf/example.conf`裡，我們只會提到一些
 
 Gitolite 也支援一個叫 "個人分支"的功能 (或者叫, "個人分支命名空間") 在合作環境裡非常有用。
 
-在 git世界裡許多代碼交換通過 "pull" 請求發生。然而在合作環境裡，委任制的訪問是‘絕不’，一個開發者工作站不能認證，你必須push到中心伺服器並且叫其他人從那裡pull。
+在 git世界裡許多代碼交換通過 "pull" 請求發生。然而在合作環境裡，委任制的存取是‘絕不’，一個開發者工作站不能認證，你必須push到中心伺服器並且叫其他人從那裡pull。
 
-這個通常會引起一些 branch 名稱簇變成像 VCS裡一樣集中化，加上設置許可變成管理員的苦差事。
+這個通常會引起一些 branch 名稱簇變成像 VCS裡一樣集中化，加上設定許可變成管理員的苦差事。
 
-Gitolite讓你定義一個 "個人的" 或者 "亂七八糟的" 命名空間字首給每個開發人員 (比如，`refs/personal/<devname>/*`)；看在 `doc/3-faq-tips-etc.mkd`裡的 "personal branches" 一段獲取細節。
+Gitolite讓你定義一個 "個人的" 或者 "亂七八糟的" 命名空間字首給每個開發人員 (比如，`refs/personal/<devname>/*`)；看在 `doc/3-faq-tips-etc.mkd`裡的 "personal branches" 一段取得細節。
 
 ### "萬用字元" 倉庫 ###
 
-Gitolite 允許你定義帶萬用字元的倉庫 (其實還是 perl正則式), 比如隨便整個例子的話 `assignments/s[0-9][0-9]/a[0-9][0-9]`。 這是一個非常有用的功能，需要通過設置 `$GL_WILDREPOS = 1;` 在 rc文件中啟用。允許你安排一個新許可模式 ("C") 允許用戶創建倉庫基於萬用字元，自動分配擁有權對特定用戶 - 創建者，允許他交出 R和 RW許可給其他合作用戶等等。這個功能在`doc/4-wildcard-repositories.mkd`文檔裡
+Gitolite 允許你定義帶萬用字元的倉庫 (其實還是 perl正則式), 比如隨便整個例子的話 `assignments/s[0-9][0-9]/a[0-9][0-9]`。 這是一個非常有用的功能，需要通過設定 `$GL_WILDREPOS = 1;` 在 rc文件中啟用。允許你安排一個新許可模式 ("C") 允許用戶建立倉庫基於萬用字元，自動分配擁有權對特定用戶 - 建立者，允許他交出 R和 RW許可給其他合作用戶等等。這個功能在`doc/4-wildcard-repositories.mkd`文檔裡
 
 ### 其他功能 ###
 
 我們用一些其他功能的例子結束這段討論，這些以及其他功能都在 "faqs, tips, etc" 和其他文檔裡。
 
-**記錄**: Gitolite 記錄所有成功的訪問。如果你太放鬆給了別人 rewind許可 (`RW+`) 和其他孩子弄沒了 "master"， 記錄檔會救你的命，如果其他簡單快速的找到SHA都不管用。
+**記錄**: Gitolite 記錄所有成功的存取。如果你太放鬆給了別人 rewind許可 (`RW+`) 和其他孩子弄沒了 "master"， 記錄檔會救你的命，如果其他簡單快速的找到SHA都不管用。
 
-**訪問權報告**: 另一個方便的功能是你嘗試用ssh連接到伺服器的時候發生了什麼。Gitolite告訴你哪個 repos你訪問過，那個訪問可能是什麼。這裡是例子：
+**存取權報告**: 另一個方便的功能是你嘗試用ssh連接到伺服器的時候發生了什麼。Gitolite告訴你哪個 repos你存取過，那個存取可能是什麼。這裡是例子：
 
         hello scott, this is git@git running gitolite3 v3.01-18-g9609868 on git 1.7.4.4
 
@@ -659,19 +659,19 @@ Gitolite 允許你定義帶萬用字元的倉庫 (其實還是 perl正則式), 
 
 **鏡像**: Gitolite可以幫助你維護多個鏡像，如果主要伺服器掛掉的話在他們之間很容易切換。
 
-## Git 守護進程 ##
+## Git 服務 ##
 
-對於提供公共的，非授權的唯讀訪問，我們可以拋棄 HTTP 協議，改用 Git 自己的協議，這主要是出於性能和速度的考慮。Git 協定遠比 HTTP 協定高效，因而存取速度也快，所以它能節省很多用戶的時間。
+對於提供公開的，未經授權的唯讀存取，我們可以放棄 HTTP 協議，改用 Git 自己的協議，這主要是出於性能和速度的考慮。Git 協定遠比 HTTP 協定高效，因而存取速度也快，所以它能節省很多用戶的時間。
 
-重申一下，這一點隻適用於非授權的唯讀訪問。如果建在防火牆之外的伺服器上，那麼它所提供的服務應該只是那些公開的唯讀項目。如果是在防火牆之內的伺服器上，可用于支撐大量參與人員或自動系統（用於持續集成或編譯的主機）唯讀訪問的專案，這樣可以省去逐一配置 SSH 公開金鑰的麻煩。
+重申一下，這一點只適用於未經授權的唯讀存取。如果建在防火牆之外的伺服器上，那麼它所提供的服務應該只是那些公開的唯讀專案。如果是在防火牆之內的伺服器上，可用于支撐大量參與人員或自動系統（用於持續整合或編譯的主機）唯讀存取的專案，這樣可以省去逐一設定 SSH 公開金鑰的麻煩。
 
-但不管哪種情形，Git 協定的配置設定都很簡單。基本上，只要以守護進程的形式運行該命令即可：
+但不管哪種情形，Git 協定的設定設定都很簡單。基本上，只要以服務的形式執行該命令即可：
 
 	git daemon --reuseaddr --base-path=/opt/git/ /opt/git/
 
-這裡的 `--reuseaddr` 選項表示在重啟服務前，不等之前的連接逾時就立即重啟。而 `--base-path` 選項則允許克隆專案時不必給出完整路徑。最後面的路徑告訴 Git 守護進程允許開放給使用者訪問的倉庫目錄。假如有防火牆，則需要為該主機的 9418 埠設置為允許通信。
+這裡的 `--reuseaddr` 選項表示在重啟服務前，不等之前的連接逾時就立即重啟。而 `--base-path` 選項則允許克隆專案時不必給出完整路徑。最後面的路徑告訴 Git 服務允許開放給使用者存取的倉庫目錄。假如有防火牆，則需要為該主機的 9418 埠設定為允許通訊。
 
-以守護進程的形式運行該進程的方法有很多，但主要還得看用的是什麼作業系統。在 Ubuntu 主機上，可以用 Upstart 腳本達成。編輯該檔：
+以服務的形式執行該行程的方法有很多，但主要還得看用的是什麼作業系統。在 Ubuntu 主機上，可以用 Upstart 腳本達成。編輯該檔：
 
 	/etc/event.d/local-git-daemon
 
@@ -686,36 +686,36 @@ Gitolite 允許你定義帶萬用字元的倉庫 (其實還是 perl正則式), 
 	    /opt/git/
 	respawn
 
-出於安全考慮，強烈建議用一個對倉庫只有讀取許可權的使用者身份來運行該進程 — 只需要簡單地新建一個名為 `git-ro` 的用戶（譯注：新建用戶默認對倉庫檔不具備寫許可權，但這取決於倉庫目錄的許可權設定。務必確認 `git-ro` 對倉庫只能讀不能寫。），並用它的身份來啟動進程。這裡為了簡化，後面我們還是用之前運行 Gitosis 的用戶 'git'。
+出於安全考慮，強烈建議用一個對倉庫只有讀取許可權的使用者身份來執行該行程 — 只需要簡單地新建一個名為 `git-ro` 的用戶（譯注：新建用戶預設對倉庫檔不具備寫許可權，但這取決於倉庫目錄的許可權設定。務必確認 `git-ro` 對倉庫只能讀不能寫。），並用它的身份來啟動行程。這裡為了簡化，後面我們還是用之前執行 Gitosis 的用戶 'git'。
 
-這樣一來，當你重啟電腦時，Git 進程也會自動啟動。要是進程意外退出或者被殺掉，也會自行重啟。在設置完成後，不重啟電腦就啟動該守護進程，可以運行：
+這樣一來，當你重啟電腦時，Git 行程也會自動啟動。要是行程意外退出或者被殺掉，也會自行重啟。在設定完成後，不重啟電腦就啟動該服務，可以執行：
 
 	initctl start local-git-daemon
 
-而在其他作業系統上，可以用 `xinetd`，或者 `sysvinit` 系統的腳本，或者其他類似的腳本 — 只要能讓那個命令變為守護進程並可監控。
+而在其他作業系統上，可以用 `xinetd`，或者 `sysvinit` 系統的腳本，或者其他類似的腳本 — 只要能讓那個命令變為服務並可監控。
 
-接下來，我們必須告訴 Gitosis 哪些倉庫允許通過 Git 協議進行匿名唯讀訪問。如果每個倉庫都設有各自的段落，可以分別指定是否允許 Git 進程開放給使用者匿名讀取。比如允許通過 Git 協議訪問 iphone_project，可以把下面兩行加到 `gitosis.conf` 文件的末尾：
+接下來，我們必須告訴 Gitosis 哪些倉庫允許通過 Git 協議進行匿名唯讀存取。如果每個倉庫都設有各自的段落，可以分別指定是否允許 Git 行程開放給使用者匿名讀取。比如允許通過 Git 協議存取 iphone_project，可以把下面兩行加到 `gitosis.conf` 文件的末尾：
 
 	[repo iphone_project]
 	daemon = yes
 
-在提交和推送完成後，運行中的 Git 守護進程就會回應來自 9418 埠對該專案的訪問請求。
+在提交和推送完成後，執行中的 Git 服務就會回應來自 9418 埠對該專案的存取請求。
 
-如果不考慮 Gitosis，單單起了 Git 守護進程的話，就必須到每一個允許匿名唯讀訪問的倉庫目錄內，創建一個特殊名稱的空檔作為標誌：
+如果不考慮 Gitosis，單單起了 Git 服務的話，就必須到每一個允許匿名唯讀存取的倉庫目錄內，建立一個特殊名稱的空檔作為標誌：
 
 	$ cd /path/to/project.git
 	$ touch git-daemon-export-ok
 
-該檔的存在，表明允許 Git 守護進程開放對該專案的匿名唯讀訪問。
+該檔的存在，表示允許 Git 服務開放對該專案的匿名唯讀存取。
 
-Gitosis 還能設定哪些項目允許放在 GitWeb 上顯示。先打開 GitWeb 的設定檔 `/etc/gitweb.conf`，添加以下四行：
+Gitosis 還能設定哪些專案允許放在 GitWeb 上顯示。先打開 GitWeb 的設定檔 `/etc/gitweb.conf`，增加以下四行：
 
 	$projects_list = "/home/git/gitosis/projects.list";
 	$projectroot = "/home/git/repositories";
 	$export_ok = "git-daemon-export-ok";
 	@git_base_url_list = ('git://gitserver');
 
-接下來，只要配置各個專案在 Gitosis 中的 `gitweb` 參數，便能達成是否允許 GitWeb 用戶流覽該專案。比如，要讓 iphone_project 項目在 GitWeb 裡出現，把 `repo` 的設定改成下面的樣子：
+接下來，只要設定各個專案在 Gitosis 中的 `gitweb` 參數，便能達成是否允許 GitWeb 用戶流覽該專案。比如，要讓 iphone_project 專案在 GitWeb 裡出現，把 `repo` 的設定改成下面的樣子：
 
 	[repo iphone_project]
 	daemon = yes
@@ -725,7 +725,7 @@ Gitosis 還能設定哪些項目允許放在 GitWeb 上顯示。先打開 GitWeb
 
 ## Git 託管服務 ##
 
-如果不想經歷自己架設 Git 伺服器的麻煩，網路上有幾個專業的倉庫託管服務可供選擇。這樣做有幾大優點：託管帳戶的建立通常比較省時，方便專案的啟動，而且不涉及伺服器的維護和監控。即使內部創建並運行著自己的伺服器，同時為開源項目提供一個公共託管網站還是有好處的 — 讓開源社區更方便地找到該專案，並給予幫助。
+如果不想經歷自己架設 Git 伺服器的麻煩，網路上有幾個專業的倉庫託管服務可供選擇。這樣做有幾大優點：託管帳戶的建立通常比較省時，方便專案的啟動，而且不涉及伺服器的維護和監控。即使內部建立並執行著自己的伺服器，同時為開源專案提供一個公開託管網站還是有好處的 — 讓開源社區更方便地找到該專案，並給予幫助。
 
 目前，可供選擇的託管服務數量繁多，各有利弊。在 Git 官方 wiki 上的 Githosting 頁面有一個最新的託管服務清單：
 
@@ -733,28 +733,28 @@ Gitosis 還能設定哪些項目允許放在 GitWeb 上顯示。先打開 GitWeb
 
 由於本書無法全部一一介紹，而本人（譯注：指本書作者 Scott Chacon。）剛好在其中一家公司工作，所以接下來我們將會介紹如何在 GitHub 上建立新帳戶並啟動專案。至於其他託管服務大體也是這麼一個過程，基本的想法都是差不多的。
 
-GitHub 是目前為止最大的開源 Git 託管服務，並且還是少數同時提供公共代碼和私有代碼託管服務的網站之一，所以你可以在上面同時保存開源和商業代碼。事實上，本書就是放在 GitHub 上合作編著的。（譯注：本書的翻譯也是放在 GitHub 上廣泛協作的。）
+GitHub 是目前為止最大的開源 Git 託管服務，並且還是少數同時提供公開代碼和私有代碼託管服務的網站之一，所以你可以在上面同時保存開源和商業代碼。事實上，本書就是放在 GitHub 上合作編著的。（譯注：本書的翻譯也是放在 GitHub 上廣泛協作的。）
 
 ### GitHub ###
 
-GitHub 和大多數的代碼託管網站在處理專案命名空間的方式上略有不同。GitHub 的設計更側重於用戶，而不是完全基於專案。也就是說，如果我在 GitHub 上託管一個名為 `grit` 的項目的話，它的位址不會是 `github.com/grit`，而是按在用戶底下 `github.com/shacon/grit` （譯注：本書作者 Scott Chacon 在 GitHub 上的用戶名是 `shacon`。）。不存在所謂某個項目的官方版本，所以假如第一作者放棄了某個項目，它可以無縫轉移到其它用戶的名下。
+GitHub 和大多數的代碼託管網站在處理專案命名空間的方式上略有不同。GitHub 的設計更側重於用戶，而不是完全基於專案。也就是說，如果我在 GitHub 上託管一個名為 `grit` 的專案的話，它的位址不會是 `github.com/grit`，而是按在用戶底下 `github.com/shacon/grit` （譯注：本書作者 Scott Chacon 在 GitHub 上的使用者名稱是 `shacon`。）。不存在所謂某個專案的官方版本，所以假如第一作者放棄了某個專案，它可以無縫轉移到其它用戶的名下。
 
-GitHub 同時也是一個向使用私有倉庫的用戶收取費用的商業公司，但任何人都可以方便快捷地申請到一個免費帳戶，並在上面託管數量不限的開源項目。接下來我們快速介紹一下 GitHub 的基本使用。
+GitHub 同時也是一個向使用私有倉庫的用戶收取費用的商業公司，但任何人都可以方便快速地申請到一個免費帳戶，並在上面託管數量不限的開源專案。接下來我們快速介紹一下 GitHub 的基本使用。
 
 ### 建立新帳戶 ###
 
-首先註冊一個免費帳戶。訪問 "Plans and pricing" 頁面 `https://github.com/pricing` 並點擊 Free acount 裡的 Sign Up 按鈕（見圖 4-2），進入註冊頁面。
+首先註冊一個免費帳戶。存取 "Plans and pricing" 頁面 `https://github.com/pricing` 並點選 Free acount 裡的 Sign Up 按鈕（見圖 4-2），進入註冊頁面。
 
 Insert 18333fig0402.png
 圖 4-2. GitHub 服務簡介頁面
 
-選擇一個系統中尚未使用的用戶名，提供一個與之相關聯的電郵位址，並輸入密碼（見圖 4-3）：
+選擇一個系統中尚未使用的使用者名稱，提供一個與之相關聯的電子郵件位址，並輸入密碼（見圖 4-3）：
 
 Insert 18333fig0403.png
 圖 4-3. GitHub 用戶註冊表單
 
-如果方便，現在就可以提供你的 SSH 公開金鑰。我們在前文的"小型安裝" 一節介紹過生成新公開金鑰的方法。把新生成的公開金鑰複製粘貼到 SSH Public Key 文字方塊中即可。要是對生成公開金鑰的步驟不太清楚，也可以點擊 "explain ssh keys" 連結，會顯示各個主流作業系統上完成該步驟的介紹。
-點擊 "I agree，sign me up" 按鈕完成使用者註冊，並轉到該使用者的 dashboard 頁面（見圖 4-4）:
+如果方便，現在就可以提供你的 SSH 公開金鑰。我們在前文的"小型安裝" 一節介紹過生成新公開金鑰的方法。把新生成的公開金鑰複製粘貼到 SSH Public Key 文字方塊中即可。要是對生成公開金鑰的步驟不太清楚，也可以點選 "explain ssh keys" 連結，會顯示各個主流作業系統上完成該步驟的介紹。
+點選 "I agree，sign me up" 按鈕完成使用者註冊，並轉到該使用者的 dashboard 頁面（見圖 4-4）:
 
 Insert 18333fig0404.png
 圖 4-4. GitHub 的用戶面板
@@ -763,104 +763,104 @@ Insert 18333fig0404.png
 
 ### 建立新倉庫 ###
 
-點擊用戶面板上倉庫旁邊的 "create a new one" 連結，顯示 Create a New Repository 的表單（見圖 4-5）：
+點選用戶面板上倉庫旁邊的 "create a new one" 連結，顯示 Create a New Repository 的表單（見圖 4-5）：
 
 Insert 18333fig0405.png
 圖 4-5. 在 GitHub 上建立新倉庫
 
-當然，項目名稱是必不可少的，此外也可以適當描述一下專案的情況或者給出官方網站的位址。然後點擊 "Create Repository" 按鈕，新倉庫就建立起來了（見圖 4-6）：
+當然，專案名稱是必不可少的，此外也可以適當描述一下專案的情況或者給出官方網站的位址。然後點選 "Create Repository" 按鈕，新倉庫就建立起來了（見圖 4-6）：
 
 Insert 18333fig0406.png
 圖 4-6. GitHub 上各個專案的概要資訊
 
-由於尚未提交代碼，點擊專案位址後 GitHub 會顯示一個簡要的指南，告訴你如何新建一個專案並推送上來，如何從現有項目推送，以及如何從一個公共的 Subversion 倉庫導入項目（見圖 4-7）：
+由於尚未提交代碼，點選專案位址後 GitHub 會顯示一個簡要的指南，告訴你如何新建一個專案並推送上來，如何從現有專案推送，以及如何從一個公開的 Subversion 倉庫導入專案（見圖 4-7）：
 
 Insert 18333fig0407.png
 圖 4-7. 新倉庫指南
 
-該指南和本書前文介紹的類似，對於新的專案，需要先在本地初始化為 Git 專案，添加要管理的檔並作首次提交：
+該指南和本書前文介紹的類似，對於新的專案，需要先在本地初始化為 Git 專案，增加要管理的檔並作首次提交：
 
 	$ git init
 	$ git add .
 	$ git commit -m 'initial commit'
 
-然後在這個本地倉庫內把 GitHub 添加為遠端倉庫，並推送 master 分支上來：
+然後在這個本地倉庫內把 GitHub 增加為遠端倉庫，並推送 master 分支上來：
 
 	$ git remote add origin git@github.com:testinguser/iphone_project.git
 	$ git push origin master
 
-現在該項目就託管在 GitHub 上了。你可以把它的 URL 分享給每位對此項目感興趣的人。本例的 URL 是 `http://github.com/testinguser/iphone_project`。而在專案頁面的摘要部分，你會發現有兩個 Git URL 位址（見圖 4-8）：
+現在該專案就託管在 GitHub 上了。你可以把它的 URL 分享給每位對此專案感興趣的人。本例的 URL 是 `http://github.com/testinguser/iphone_project`。而在專案頁面的摘要部分，你會發現有兩個 Git URL 位址（見圖 4-8）：
 
 Insert 18333fig0408.png
-圖 4-8. 項目摘要中的公共 URL 和私有 URL
+圖 4-8. 專案摘要中的公開 URL 和私有 URL
 
 Public Clone URL 是一個公開的，唯讀的 Git URL，任何人都可以通過它克隆該專案。可以隨意散播這個 URL，比如發佈到個人網站之類的地方等等。
 
-Your Clone URL 是一個基於 SSH 協議的可讀可寫 URL，只有使用與上傳的 SSH 公開金鑰對應的金鑰來連接時，才能通過它進行讀寫操作。其他使用者訪問該專案頁面時只能看到之前那個公共的 URL，看不到這個私有的 URL。
+Your Clone URL 是一個基於 SSH 協議的可讀可寫 URL，只有使用與上傳的 SSH 公開金鑰對應的金鑰來連接時，才能通過它進行讀寫操作。其他使用者存取該專案頁面時只能看到之前那個公開的 URL，看不到這個私有的 URL。
 
-### 從 Subversion 導入項目 ###
+### 從 Subversion 導入專案 ###
 
-如果想把某個公共 Subversion 項目導入 Git，GitHub 可以幫忙。在指南的最後有一個指嚮導入 Subversion 頁面的連結。點擊它會看到一個表單，包含有關導入流程的資訊以及一個用來粘貼公共 Subversion 項目連接的文字方塊（見圖 4-9）：
+如果想把某個公開 Subversion 專案導入 Git，GitHub 可以幫忙。在指南的最後有一個指嚮導入 Subversion 頁面的連結。點選它會看到一個表單，包含有關導入流程的資訊以及一個用來粘貼公開 Subversion 專案連接的文字方塊（見圖 4-9）：
 
 Insert 18333fig0409.png
 圖 4-9. Subversion 導入介面
 
 如果專案很大，採用非標準結構，或者是私有的，那就無法借助該工具實現導入。到第 7 章，我們會介紹如何手工導入複雜工程的具體方法。
 
-### 添加協作開發者 ###
+### 增加協作開發者 ###
 
-現在把團隊裡的其他人也加進來。如果 John，Josie 和 Jessica 都在 GitHub 註冊了帳戶，要賦予他們對該倉庫的推送許可權，可以把他們加為專案協作者。這樣他們就可以通過各自的公開金鑰訪問我的這個倉庫了。
+現在把團隊裡的其他人也加進來。如果 John，Josie 和 Jessica 都在 GitHub 註冊了帳戶，要賦予他們對該倉庫的推送許可權，可以把他們加為專案協作者。這樣他們就可以通過各自的公開金鑰存取我的這個倉庫了。
 
-點擊專案頁面上方的 "edit" 按鈕或者頂部的 Admin 標籤，進入該專案的管理頁面（見圖 4-10）：
+點選專案頁面上方的 "edit" 按鈕或者頂部的 Admin 標籤，進入該專案的管理頁面（見圖 4-10）：
 
 Insert 18333fig0410.png
 圖 4-10. GitHub 的專案管理頁面
 
-為了給另一個用戶添加項目的寫許可權，點擊 "Add another collaborator" 連結，出現一個用於輸入用戶名的表單。在輸入的同時，它會自動跳出一個符合條件的候選名單。找到正確用戶名之後，點 Add 按鈕，把該使用者設為專案協作者（見圖 4-11）：
+為了給另一個用戶增加專案的寫許可權，點選 "Add another collaborator" 連結，出現一個用於輸入使用者名稱的表單。在輸入的同時，它會自動跳出一個符合條件的候選名單。找到正確使用者名稱之後，點 Add 按鈕，把該使用者設為專案協作者（見圖 4-11）：
 
 Insert 18333fig0411.png
-圖 4-11. 為專案添加協作者
+圖 4-11. 為專案增加協作者
 
-添加完協作者之後，就可以在 Repository Collaborators 區域看到他們的名單（見圖 4-12）：
+增加完協作者之後，就可以在 Repository Collaborators 區域看到他們的名單（見圖 4-12）：
 
 Insert 18333fig0412.png
 圖 4-12. 專案協作者名單
 
-如果要取消某人的訪問權，點擊 "revoke" 即可取消他的推送許可權。對於將來的專案，你可以從現有專案複製協作者名單，或者直接借用協作者群組。
+如果要取消某人的存取權，點選 "revoke" 即可取消他的推送許可權。對於將來的專案，你可以從現有專案複製協作者名單，或者直接借用協作者群組。
 
 ### 專案頁面 ###
 
-在推送或從 Subversion 導入項目之後，你會看到一個類似圖 4-13 的項目主頁：
+在推送或從 Subversion 導入專案之後，你會看到一個類似圖 4-13 的專案主頁：
 
 Insert 18333fig0413.png
-圖 4-13. GitHub 上的項目主頁
+圖 4-13. GitHub 上的專案主頁
 
-別人訪問你的專案時看到的就是這個頁面。它有若干導航標籤，Commits 標籤用於顯示提交歷史，最新的提交位於最上方，這和 `git log` 命令的輸出類似。Network 標籤展示所有派生了該專案並做出貢獻的用戶的關係圖譜。Downloads 標籤允許你上傳項目的二進位檔案，提供下載該項目各個版本的 tar/zip 包。Wiki 標籤提供了一個用於撰寫文檔或其他專案相關資訊的 wiki 網站。Graphs 標籤包含了一些視覺化的專案資訊與資料。預設打開的 Source 標籤頁面，則列出了該專案的目錄結構和概要資訊，並在下方自動展示 README 檔的內容（如果該檔存在的話），此外還會顯示最近一次提交的相關資訊。
+別人存取你的專案時看到的就是這個頁面。它有若干導航標籤，Commits 標籤用於顯示提交歷史，最新的提交位於最上方，這和 `git log` 命令的輸出類似。Network 標籤示範所有派生了該專案並做出貢獻的用戶的關係圖譜。Downloads 標籤允許你上傳專案的二進位檔案，提供下載該專案各個版本的 tar/zip 包。Wiki 標籤提供了一個用於撰寫文檔或其他專案相關資訊的 wiki 網站。Graphs 標籤包含了一些視覺化的專案資訊與資料。預設打開的 Source 標籤頁面，則列出了該專案的目錄結構和概要資訊，並在下方自動示範 README 檔的內容（如果該檔存在的話），此外還會顯示最近一次提交的相關資訊。
 
-### 派生項目 ###
+### 派生專案 ###
 
-如果要為一個自己沒有推送許可權的項目貢獻代碼，GitHub 鼓勵使用派生（fork）。到那個感興趣的項目主頁上，點擊頁面上方的 "fork" 按鈕，GitHub 就會為你複製一份該項目的副本到你的倉庫中，這樣你就可以向自己的這個副本推送資料了。
+如果要為一個自己沒有推送許可權的專案貢獻代碼，GitHub 鼓勵使用派生（fork）。到那個感興趣的專案主頁上，點選頁面上方的 "fork" 按鈕，GitHub 就會為你複製一份該專案的副本到你的倉庫中，這樣你就可以向自己的這個副本推送資料了。
 
 採取這種辦法的好處是，專案擁有者不必忙於應付賦予他人推送許可權的工作。隨便誰都可以通過派生得到一個專案副本並在其中展開工作，事後只需要專案維護者將這些副本倉庫加為遠端倉庫，然後提取更新合併即可。
 
-要派生一個專案，到原始專案的頁面（本例中是 mojombo/chronic）點擊 "fork" 按鈕（見圖 4-14）：
+要派生一個專案，到原始專案的頁面（本例中是 mojombo/chronic）點選 "fork" 按鈕（見圖 4-14）：
 
 Insert 18333fig0414.png
-圖 4-14. 點擊 "fork" 按鈕獲得任意專案的可寫副本
+圖 4-14. 點選 "fork" 按鈕獲得任意專案的可寫副本
 
-幾秒鐘之後，你將進入新建的專案頁面，會顯示該專案派生自哪一個項目（見圖 4-15）：
+幾秒鐘之後，你將進入新增的專案頁面，會顯示該專案派生自哪一個專案（見圖 4-15）：
 
 Insert 18333fig0415.png
-圖 4-15. 派生後得到的項目副本
+圖 4-15. 派生後得到的專案副本
 
 ### GitHub 小結 ###
 
-關於 GitHub 就先介紹這麼多，能夠快速達成這些事情非常重要（譯注：門檻的降低和完成基本任務的簡單高效，對於推動開源專案的協作發展有著舉足輕重的意義。）。短短幾分鐘內，你就能創建一個新帳戶，添加一個專案並開始推送。如果專案是開源的，整個龐大的開發者社區都可以立即訪問它，提供各式各樣的幫助和貢獻。最起碼，這也是一種 Git 新手立即體驗嘗試 Git 的捷徑。
+關於 GitHub 就先介紹這麼多，能夠快速達成這些事情非常重要（譯注：門檻的降低和完成基本任務的簡單高效，對於推動開源專案的協作發展有著舉足輕重的意義。）。短短幾分鐘內，你就能建立一個新帳戶，增加一個專案並開始推送。如果專案是開源的，整個龐大的開發者社區都可以立即存取它，提供各式各樣的幫助和貢獻。最起碼，這也是一種 Git 新手立即體驗嘗試 Git 的捷徑。
 
 ## 小結 ##
 
 我們討論並介紹了一些建立遠端 Git 倉庫的方法，接下來你可以通過這些倉庫同他人分享或合作。
 
-運行自己的伺服器意味著更多的控制權以及在防火牆內部操作的可能性，當然這樣的伺服器通常需要投入一定的時間精力來架設維護。如果直接託管，雖然能免去這部分工作，但有時出於安全或版權的考慮，有些公司禁止將商業代碼託管到協力廠商服務商。
+執行自己的伺服器意味著更多的控制權以及在防火牆內部操作的可能性，當然這樣的伺服器通常需要投入一定的時間精力來架設維護。如果直接託管，雖然能免去這部分工作，但有時出於安全或版權的考慮，有些公司禁止將商業代碼託管到協力廠商服務商。
 
 所以究竟採取哪種方案，並不是個難以取捨的問題，或者其一，或者相互配合，哪種合適就用哪種。
diff --git a/zh-tw/05-distributed-git/01-chapter5.markdown b/zh-tw/05-distributed-git/01-chapter5.markdown
index 655b22b01..6c1683e2e 100644
--- a/zh-tw/05-distributed-git/01-chapter5.markdown
+++ b/zh-tw/05-distributed-git/01-chapter5.markdown
@@ -2,11 +2,11 @@
 
 為了便於專案中的所有開發者分享代碼，我們準備好了一台伺服器存放遠端 Git 倉庫。經過前面幾章的學習，我們已經學會了一些基本的本地工作流程中所需用到的命令。接下來，我們要學習下如何利用 Git 來組織和完成分散式工作流程。
 
-特別是，當作為項目貢獻者時，我們該怎麼做才能方便維護者採納更新；或者作為專案維護者時，又該怎樣有效管理大量貢獻者的提交。
+特別是，當作為專案貢獻者時，我們該怎麼做才能方便維護者採納更新；或者作為專案維護者時，又該怎樣有效管理大量貢獻者的提交。
 
 ## 分散式工作流程 ##
 
-同傳統的集中式版本控制系統（CVCS）不同，開發者之間的協作方式因著 Git 的分散式特性而變得更為靈活多樣。在集中式系統上，每個開發者就像是連接在集線器上的節點，彼此的工作方式大體相像。而在 Git 網路中，每個開發者同時扮演著節點和集線器的角色，這就是說，每一個開發者都可以將自己的代碼貢獻到另外一個開發者的倉庫中，或者建立自己的公共倉庫，讓其他開發者基於自己的工作開始，為自己的倉庫貢獻代碼。於是，Git 的分散式協作便可以衍生出種種不同的工作流程，我會在接下來的章節介紹幾種常見的應用方式，並分別討論各自的優缺點。你可以選擇其中的一種，或者結合起來，應用到你自己的專案中。
+同傳統的集中式版本控制系統（CVCS）不同，開發者之間的協作方式因著 Git 的分散式特性而變得更為靈活多樣。在集中式系統上，每個開發者就像是連接在集線器上的節點，彼此的工作方式大體相像。而在 Git 網路中，每個開發者同時扮演著節點和集線器的角色，這就是說，每一個開發者都可以將自己的代碼貢獻到另外一個開發者的倉庫中，或者建立自己的公開倉庫，讓其他開發者基於自己的工作開始，為自己的倉庫貢獻代碼。於是，Git 的分散式協作便可以衍生出種種不同的工作流程，我會在接下來的章節介紹幾種常見的應用方式，並分別討論各自的優缺點。你可以選擇其中的一種，或者結合起來，套用到你自己的專案中。
 
 ### 集中式工作流 ###
 
@@ -17,38 +17,38 @@ Insert 18333fig0501.png
 
 如果兩個開發者從中心倉庫克隆代碼下來，同時作了一些修訂，那麼只有第一個開發者可以順利地把資料推送到共用伺服器。第二個開發者在提交他的修訂之前，必須先下載合併伺服器上的資料，解決衝突之後才能推送資料到共用伺服器上。在 Git 中這麼用也決無問題，這就好比是在用 Subversion（或其他 CVCS）一樣，可以很好地工作。
 
-如果你的團隊不是很大，或者大家都已經習慣了使用集中式工作流程，完全可以採用這種簡單的模式。只需要配置好一台中心伺服器，並給每個人推送資料的許可權，就可以開展工作了。但如果提交代碼時有衝突， Git 根本就不會讓用戶覆蓋他人代碼，它直接駁回第二個人的提交操作。這就等於告訴提交者，你所作的修訂無法通過快近（fast-forward）來合併，你必須先拉取最新資料下來，手工解決衝突合併後，才能繼續推送新的提交。
+如果你的團隊不是很大，或者大家都已經習慣了使用集中式工作流程，完全可以採用這種簡單的模式。只需要設定好一台中心伺服器，並給每個人推送資料的許可權，就可以開展工作了。但如果提交代碼時有衝突， Git 根本就不會讓用戶覆蓋他人代碼，它直接駁回第二個人的提交操作。這就等於告訴提交者，你所作的修訂無法通過快近（fast-forward）來合併，你必須先拉取最新資料下來，手工解決衝突合併後，才能繼續推送新的提交。
 絕大多數人都熟悉和瞭解這種模式的工作方式，所以使用也非常廣泛。
 
-### 集成管理員工作流 ###
+### 整合管理員工作流 ###
 
-由於 Git 允許使用多個遠端倉庫，開發者便可以建立自己的公共倉庫，往裡面寫資料並共用給他人，而同時又可以從別人的倉庫中提取他們的更新過來。這種情形通常都會有個代表著官方發佈的專案倉庫（blessed repository），開發者們由此倉庫克隆出一個自己的公共倉庫（developer public），然後將自己的提交推送上去，請求官方倉庫的維護者拉取更新合併到主項目。維護者在自己的本地也有個克隆倉庫（integration manager），他可以將你的公共倉庫作為遠端倉庫添加進來，經過測試無誤後合併到主幹分支，然後再推送到官方倉庫。工作流程看起來就像圖 5-2 所示：
+由於 Git 允許使用多個遠端倉庫，開發者便可以建立自己的公開倉庫，往裡面寫資料並共用給他人，而同時又可以從別人的倉庫中提取他們的更新過來。這種情形通常都會有個代表著官方發佈的專案倉庫（blessed repository），開發者們由此倉庫克隆出一個自己的公開倉庫（developer public），然後將自己的提交推送上去，請求官方倉庫的維護者拉取更新合併到主專案。維護者在自己的本地也有個克隆倉庫（integration manager），他可以將你的公開倉庫作為遠端倉庫增加進來，經過測試無誤後合併到主幹分支，然後再推送到官方倉庫。工作流程看起來就像圖 5-2 所示：
 
-1. 專案維護者可以推送資料到公共倉庫 blessed repository。
+1. 專案維護者可以推送資料到公開倉庫 blessed repository。
 2. 貢獻者克隆此倉庫，修訂或編寫新代碼。
-3. 貢獻者推送資料到自己的公共倉庫 developer public。
+3. 貢獻者推送資料到自己的公開倉庫 developer public。
 4. 貢獻者給維護者發送郵件，請求拉取自己的最新修訂。
-5. 維護者在自己本地的 integration manger 倉庫中，將貢獻者的倉庫加為遠程倉庫，合併更新並做測試。
+5. 維護者在自己本地的 integration manger 倉庫中，將貢獻者的倉庫加為遠端倉庫，合併更新並做測試。
 6. 維護者將合併後的更新推送到主倉庫 blessed repository。
 
 Insert 18333fig0502.png
-圖 5-2. 集成管理員工作流
+圖 5-2. 整合管理員工作流
 
-在 GitHub 網站上使用得最多的就是這種工作流。人們可以複製（fork 亦即克隆）某個項目到自己的列表中，成為自己的公共倉庫。隨後將自己的更新提交到這個倉庫，所有人都可以看到你的每次更新。這麼做最主要的優點在於，你可以按照自己的節奏繼續工作，而不必等待維護者處理你提交的更新；而維護者也可以按照自己的節奏，任何時候都可以過來處理接納你的貢獻。
+在 GitHub 網站上使用得最多的就是這種工作流。人們可以複製（fork 亦即克隆）某個專案到自己的列表中，成為自己的公開倉庫。隨後將自己的更新提交到這個倉庫，所有人都可以看到你的每次更新。這麼做最主要的優點在於，你可以按照自己的節奏繼續工作，而不必等待維護者處理你提交的更新；而維護者也可以按照自己的節奏，任何時候都可以過來處理接納你的貢獻。
 
 ### 司令官與副官工作流 ###
 
-這其實是上一種工作流的變體。一般超大型的專案才會用到這樣的工作方式，像是擁有數百協作開發者的 Linux 內核專案就是如此。各個集成管理員分別負責集成專案中的特定部分，所以稱為副官（lieutenant）。而所有這些集成管理員頭上還有一位負責統籌的總集成管理員，稱為司令官（dictator）。司令官維護的倉庫用於提供所有協作者拉取最新集成的項目代碼。整個流程看起來如圖 5-3 所示：
+這其實是上一種工作流的變體。一般超大型的專案才會用到這樣的工作方式，像是擁有數百協作開發者的 Linux 核心專案就是如此。各個整合管理員分別負責整合專案中的特定部分，所以稱為副官（lieutenant）。而所有這些整合管理員頭上還有一位負責統籌的總整合管理員，稱為司令官（dictator）。司令官維護的倉庫用於提供所有協作者拉取最新整合的專案代碼。整個流程看起來如圖 5-3 所示：
 
 1. 一般的開發者在自己的特性分支上工作，並不定期地根據主幹分支（dictator 上的 master）衍合。
 2. 副官（lieutenant）將普通開發者的特性分支合併到自己的 master 分支中。
 3. 司令官（dictator）將所有副官的 master 分支併入自己的 master 分支。
-4. 司令官（dictator）將集成後的 master 分支推送到共用倉庫 blessed repository 中，以便所有其他開發者以此為基礎進行衍合。
+4. 司令官（dictator）將整合後的 master 分支推送到共用倉庫 blessed repository 中，以便所有其他開發者以此為基礎進行衍合。
 
 Insert 18333fig0503.png
 圖 5-3. 司令官與副官工作流
 
-這種工作流程並不常用，只有當專案極為龐雜，或者需要多級別管理時，才會體現出優勢。利用這種方式，專案總負責人（即司令官）可以把大量分散的集成工作委託給不同的小組負責人分別處理，最後再統籌起來，如此各人的職責清晰明確，也不易出錯（譯注：此乃分而治之）。
+這種工作流程並不常用，只有當專案極為龐雜，或者需要多級別管理時，才會體現出優勢。利用這種方式，專案總負責人（即司令官）可以把大量分散的整合工作委託給不同的小組負責人分別處理，最後再統籌起來，如此各人的職責清晰明確，也不易出錯（譯注：此乃分而治之）。
 
 以上介紹的是常見的分散式系統可以應用的工作流程，當然不止於 Git。在實際的開發工作中，你可能會遇到各種為了滿足特定需求而有所變化的工作方式。我想現在你應該已經清楚，接下來自己需要用哪種方式開展工作了。下節我還會再舉些例子，看看各式工作流中的每個角色具體應該如何操作。
 
@@ -58,9 +58,9 @@ Insert 18333fig0503.png
 
 不過要說清楚整個協作過程真的很難，Git 如此靈活，人們的協作方式便可以各式各樣，沒有固定不變的範式可循，而每個專案的具體情況又多少會有些不同，比如說參與者的規模，所選擇的工作流程，每個人的提交許可權，以及 Git 以外貢獻等等，都會影響到具體操作的細節。
 
-首當其衝的是參與者規模。專案中有多少開發者是經常提交代碼的？經常又是多久呢？大多數兩至三人的小團隊，一天大約只有幾次提交，如果不是什麼熱門項目的話就更少了。可要是在大公司裡，或者大項目中，參與者可以多到上千，每天都會有十幾個上百個補丁提交上來。這種差異帶來的影響是顯著的，越是多的人參與進來，就越難保證每次合併正確無誤。你正在工作的代碼，可能會因為合併進來其他人的更新而變得過時，甚至受創無法運行。而已經提交上去的更新，也可能在等著審核合併的過程中變得過時。那麼，我們該怎樣做才能確保代碼是最新的，提交的補丁也是可用的呢？
+首當其衝的是參與者規模。專案中有多少開發者是經常提交代碼的？經常又是多久呢？大多數兩至三人的小團隊，一天大約只有幾次提交，如果不是什麼熱門專案的話就更少了。可要是在大公司裡，或者大專案中，參與者可以多到上千，每天都會有十幾個上百個修補檔提交上來。這種差異帶來的影響是顯著的，越是多的人參與進來，就越難保證每次合併正確無誤。你正在工作的代碼，可能會因為合併進來其他人的更新而變得過時，甚至受創無法執行。而已經提交上去的更新，也可能在等著審核合併的過程中變得過時。那麼，我們該怎樣做才能確保代碼是最新的，提交的修補檔也是可用的呢？
 
-接下來便是專案所採用的工作流。是集中式的，每個開發者都具有等同的寫許可權？專案是否有專人負責檢查所有補丁？是不是所有補丁都做過同行複閱（peer-review）再通過審核的？你是否參與審核過程？如果使用副官系統，那你是不是限定于只能向此副官提交？
+接下來便是專案所採用的工作流。是集中式的，每個開發者都具有等同的寫許可權？專案是否有專人負責檢查所有修補檔？是不是所有修補檔都做過同行複閱（peer-review）再通過審核的？你是否參與審核過程？如果使用副官系統，那你是不是限定于只能向此副官提交？
 
 還有你的提交許可權。有或沒有向主專案提交更新的許可權，結果完全不同，直接決定最終採用怎樣的工作流。如果不能直接提交更新，那該如何貢獻自己的代碼呢？是不是該有個什麼策略？你每次貢獻代碼會有多少量？提交頻率呢？
 
@@ -68,9 +68,9 @@ Insert 18333fig0503.png
 
 ### 提交指南 ###
 
-開始分析特定用例之前，先來瞭解下如何撰寫提交說明。一份好的提交指南可以説明協作者更輕鬆更有效地配合。Git 項目本身就提供了一份文檔（Git 專案原始程式碼目錄中 `Documentation/SubmittingPatches`），列數了大量提示，從如何編撰提交說明到提交補丁，不一而足。
+開始分析特定用例之前，先來瞭解下如何撰寫提交說明。一份好的提交指南可以説明協作者更輕鬆更有效地配合。Git 專案本身就提供了一份文檔（Git 專案原始程式碼目錄中 `Documentation/SubmittingPatches`），列數了大量提示，從如何編撰提交說明到提交修補檔，不一而足。
 
-首先，請不要在更新中提交多餘的白字元（whitespace）。Git 有種檢查此類問題的方法，在提交之前，先運行 `git diff --check`，會把可能的多餘白字元修正列出來。下面的示例，我已經把終端中顯示為紅色的白字元用 `X` 替換掉：
+首先，請不要在更新中提交多餘的白字元（whitespace）。Git 有種檢查此類問題的方法，在提交之前，先執行 `git diff --check`，會把可能的多餘白字元修正列出來。下面的示例，我已經把終端中顯示為紅色的白字元用 `X` 替換掉：
 
 	$ git diff --check
 	lib/simplegit.rb:5: trailing whitespace.
@@ -82,7 +82,7 @@ Insert 18333fig0503.png
 
 這樣在提交之前你就可以看到這類問題，及時解決以免困擾其他開發者。
 
-接下來，請將每次提交限定於完成一次邏輯功能。並且可能的話，適當地分解為多次小更新，以便每次小型提交都更易於理解。請不要在週末窮追猛打一次性解決五個問題，而最後拖到週一再提交。就算是這樣也請盡可能利用暫存區域，將之前的改動分解為每次修復一個問題，再分別提交和加注說明。如果針對兩個問題改動的是同一個檔，可以試試看 `git add --patch` 的方式將部分內容置入暫存區域（我們會在第六章再詳細介紹）。無論是五次小提交還是混雜在一起的大提交，最終分支末端的專案快照應該還是一樣的，但分解開來之後，更便於其他開發者複閱。這麼做也方便自己將來取消某個特定問題的修復。我們將在第六章介紹一些重寫提交歷史，同暫存區域交互的技巧和工具，以便最終得到一個乾淨有意義，且易於理解的提交歷史。
+接下來，請將每次提交限定於完成一次邏輯功能。並且可能的話，適當地分解為多次小更新，以便每次小型提交都更易於理解。請不要在週末窮追猛打一次性解決五個問題，而最後拖到週一再提交。就算是這樣也請盡可能利用暫存區域，將之前的改動分解為每次修復一個問題，再分別提交和加注說明。如果針對兩個問題改動的是同一個檔案，可以試試看 `git add --patch` 的方式將部分內容置入暫存區域（我們會在第六章再詳細介紹）。無論是五次小提交還是混雜在一起的大提交，最終分支末端的專案快照應該還是一樣的，但分解開來之後，更便於其他開發者複閱。這麼做也方便自己將來取消某個特定問題的修復。我們將在第六章介紹一些重寫提交歷史，同暫存區域交互的技巧和工具，以便最終得到一個乾淨有意義，且易於理解的提交歷史。
 
 最後需要謹記的是提交說明的撰寫。寫得好可以讓大家協作起來更輕鬆。一般來說，提交說明最好限制在一行以內，50 個字元以下，簡明扼要地描述更新內容，空開一行後，再展開詳細注解。Git 專案本身需要開發者撰寫詳盡注解，包括本次修訂的因由，以及前後不同實現之間的比較，我們也該借鑒這種做法。另外，提交說明應該用祈使現在式語態，比如，不要說成 “I added tests for” 或 “Adding tests for” 而應該用 “Add tests for”。
 下面是來自 tpope.net 的 Tim Pope 原創的提交說明格式模版，供參考：
@@ -99,15 +99,15 @@ Insert 18333fig0503.png
 	 - 可以使用這樣的條目列舉式。
 
 	 - 一般以單個空格緊跟短劃線或者星號作為每項條目的起始符。每個條目間用一空行隔開。
-	   不過這裡按自己項目的約定，可以略作變化。
+	   不過這裡按自己專案的約定，可以略作變化。
 
-如果你的提交說明都用這樣的格式來書寫，好多事情就可以變得十分簡單。Git 專案本身就是這樣要求的，我強烈建議你到 Git 專案倉庫下運行 `git log --no-merges` 看看，所有提交歷史的說明是怎樣撰寫的。（譯注：如果現在還沒有克隆 git 項目原始程式碼，是時候 `git clone git://git.kernel.org/pub/scm/git/git.git` 了。）
+如果你的提交說明都用這樣的格式來書寫，好多事情就可以變得十分簡單。Git 專案本身就是這樣要求的，我強烈建議你到 Git 專案倉庫下執行 `git log --no-merges` 看看，所有提交歷史的說明是怎樣撰寫的。（譯注：如果現在還沒有克隆 git 專案原始程式碼，是時候 `git clone git://git.kernel.org/pub/scm/git/git.git` 了。）
 
 為簡單起見，在接下來的例子（及本書隨後的所有演示）中，我都不會用這種格式，而使用 `-m` 選項提交 `git commit`。不過請還是按照我之前講的做，別學我這裡偷懶的方式。
 
 ### 私有的小型團隊 ###
 
-我們從最簡單的情況開始，一個私有專案，與你一起協作的還有另外一到兩位開發者。這裡說私有，是指原始程式碼不公開，其他人無法訪問項目倉庫。而你和其他開發者則都具有推送資料到倉庫的許可權。
+我們從最簡單的情況開始，一個私有專案，與你一起協作的還有另外一到兩位開發者。這裡說私有，是指原始程式碼不公開，其他人無法存取專案倉庫。而你和其他開發者則都具有推送資料到倉庫的許可權。
 
 這種情況下，你們可以用 Subversion 或其他集中式版本控制系統類似的工作流來協作。你仍然可以得到 Git 帶來的其他好處：離線提交，快速分支與合併等等，但工作流程還是差不多的。主要區別在於，合併操作發生在用戶端而非伺服器上。
 讓我們來看看，兩個開發者一起使用同一個共用倉庫，會發生些什麼。第一個人，John，克隆了倉庫，作了些更新，在本地提交。（下面的例子中省略了常規提示，用 `...` 代替以節約版面。）
@@ -150,7 +150,7 @@ John 也嘗試推送自己的工作上去：
 	 ! [rejected]        master -> master (non-fast forward)
 	error: failed to push some refs to 'john@githost:simplegit.git'
 
-John 的推送操作被駁回，因為 Jessica 已經推送了新的資料上去。請注意，特別是你用慣了 Subversion 的話，這裡其實修改的是兩個檔，而不是同一個檔的同一個地方。Subversion 會在伺服器端自動合併提交上來的更新，而 Git 則必須先在本地合併後才能推送。於是，John 不得不先把 Jessica 的更新拉下來：
+John 的推送操作被駁回，因為 Jessica 已經推送了新的資料上去。請注意，特別是你用慣了 Subversion 的話，這裡其實修改的是兩個檔案，而不是同一個檔的同一個地方。Subversion 會在伺服器端自動合併提交上來的更新，而 Git 則必須先在本地合併後才能推送。於是，John 不得不先把 Jessica 的更新拉下來：
 
 	$ git fetch origin
 	...
@@ -162,7 +162,7 @@ John 的推送操作被駁回，因為 Jessica 已經推送了新的資料上去
 Insert 18333fig0504.png
 圖 5-4. John 的倉庫歷史
 
-雖然 John 下載了 Jessica 推送到伺服器的最近更新（fbff5），但目前只是 `origin/master` 指標指向它，而當前的本地分支 `master` 仍然指向自己的更新（738ee），所以需要先把她的提交合併過來，才能繼續推送資料：
+雖然 John 下載了 Jessica 推送到伺服器的最近更新（fbff5），但目前只是 `origin/master` 指標指向它，而目前的本地分支 `master` 仍然指向自己的更新（738ee），所以需要先把她的提交合併過來，才能繼續推送資料：
 
 	$ git merge origin/master
 	Merge made by recursive.
@@ -186,7 +186,7 @@ Insert 18333fig0505.png
 Insert 18333fig0506.png
 圖 5-6. 推送後 John 的倉庫歷史
 
-而在這段時間，Jessica 已經開始在另一個特性分支工作了。她創建了 `issue54` 並提交了三次更新。她還沒有下載 John 提交的合併結果，所以提交歷史如圖 5-7 所示：
+而在這段時間，Jessica 已經開始在另一個特性分支工作了。她建立了 `issue54` 並提交了三次更新。她還沒有下載 John 提交的合併結果，所以提交歷史如圖 5-7 所示：
 
 Insert 18333fig0507.png
 圖 5-7. Jessica 的提交歷史
@@ -202,9 +202,9 @@ Jessica 想要先和伺服器上的資料同步，所以先下載資料：
 於是 Jessica 的本地倉庫歷史多出了 John 的兩次提交（738ee 和 72bbc），如圖 5-8 所示：
 
 Insert 18333fig0508.png
-圖 5-8. 獲取 John 的更新之後 Jessica 的提交歷史
+圖 5-8. 取得 John 的更新之後 Jessica 的提交歷史
 
-此時，Jessica 在特性分支上的工作已經完成，但她想在推送資料之前，先確認下要並進來的資料究竟是什麼，於是運行 `git log` 查看：
+此時，Jessica 在特性分支上的工作已經完成，但她想在推送資料之前，先確認下要並進來的資料究竟是什麼，於是執行 `git log` 查看：
 
 	$ git log --no-merges origin/master ^issue54
 	commit 738ee872852dfaa9d6634e0dea7a324040193016
@@ -213,7 +213,7 @@ Insert 18333fig0508.png
 
 	    removed invalid default value
 
-現在，Jessica 可以將特性分支上的工作並到 `master` 分支，然後再併入 John 的工作（`origin/master`）到自己的 `master` 分支，最後再推送回伺服器。當然，得先切回主分支才能集成所有資料：
+現在，Jessica 可以將特性分支上的工作並到 `master` 分支，然後再併入 John 的工作（`origin/master`）到自己的 `master` 分支，最後再推送回伺服器。當然，得先切回主分支才能整合所有資料：
 
 	$ git checkout master
 	Switched to branch "master"
@@ -241,7 +241,7 @@ Insert 18333fig0508.png
 Insert 18333fig0509.png
 圖 5-9. 合併 John 的更新後 Jessica 的提交歷史
 
-現在 Jessica 已經可以在自己的 `master` 分支中訪問 `origin/master` 的最新改動了，所以她應該可以成功推送最後的合併結果到伺服器上（假設 John 此時沒再推送新資料上來）：
+現在 Jessica 已經可以在自己的 `master` 分支中存取 `origin/master` 的最新改動了，所以她應該可以成功推送最後的合併結果到伺服器上（假設 John 此時沒再推送新資料上來）：
 
 	$ git push origin master
 	...
@@ -260,11 +260,11 @@ Insert 18333fig0511.png
 
 ### 私有團隊間協作 ###
 
-現在我們來看更大一點規模的私有團隊協作。如果有幾個小組分頭負責若干特性的開發和集成，那他們之間的協作過程是怎樣的。
+現在我們來看更大一點規模的私有團隊協作。如果有幾個小組分頭負責若干特性的開發和整合，那他們之間的協作過程是怎樣的。
 
-假設 John 和 Jessica 一起負責開發某項特性 A，而同時 Jessica 和 Josie 一起負責開發另一項功能 B。公司使用典型的集成管理員式工作流，每個組都有一名管理員負責集成本組代碼，及更新專案主倉庫的 `master` 分支。所有開發都在代表小組的分支上進行。
+假設 John 和 Jessica 一起負責開發某項特性 A，而同時 Jessica 和 Josie 一起負責開發另一項功能 B。公司使用典型的整合管理員式工作流，每個組都有一名管理員負責整合本組代碼，及更新專案主倉庫的 `master` 分支。所有開發都在代表小組的分支上進行。
 
-讓我們跟隨 Jessica 的視角看看她的工作流程。她參與開發兩項特性，同時和不同小組的開發者一起協作。克隆生成本地倉庫後，她打算先著手開發特性 A。於是創建了新的 `featureA` 分支，繼而編寫代碼：
+讓我們跟隨 Jessica 的視角看看她的工作流程。她參與開發兩項特性，同時和不同小組的開發者一起協作。克隆生成本地倉庫後，她打算先著手開發特性 A。於是建立了新的 `featureA` 分支，繼而編寫代碼：
 
 	# Jessica's Machine
 	$ git checkout -b featureA
@@ -274,14 +274,14 @@ Insert 18333fig0511.png
 	[featureA 3300904] add limit to log function
 	 1 files changed, 1 insertions(+), 1 deletions(-)
 
-此刻，她需要分享目前的進展給 John，於是她將自己的 `featureA` 分支提交到伺服器。由於 Jessica 沒有許可權推送資料到主倉庫的 `master` 分支（只有集成管理員有此許可權），所以只能將此分支推上去同 John 共用協作：
+此刻，她需要分享目前的進展給 John，於是她將自己的 `featureA` 分支提交到伺服器。由於 Jessica 沒有許可權推送資料到主倉庫的 `master` 分支（只有整合管理員有此許可權），所以只能將此分支推上去同 John 共用協作：
 
 	$ git push origin featureA
 	...
 	To jessica@githost:simplegit.git
 	 * [new branch]      featureA -> featureA
 
-Jessica 發郵件給 John 讓他上來看看 `featureA` 分支上的進展。在等待他的回饋之前，Jessica 決定繼續工作，和 Josie 一起開發 `featureB` 上的特性 B。當然，先創建此分支，分叉點以伺服器上的 `master` 為起點：
+Jessica 發郵件給 John 讓他上來看看 `featureA` 分支上的進展。在等待他的回饋之前，Jessica 決定繼續工作，和 Josie 一起開發 `featureB` 上的特性 B。當然，先建立此分支，分叉點以伺服器上的 `master` 為起點：
 
 	# Jessica's Machine
 	$ git fetch origin
@@ -328,7 +328,7 @@ Jessica 正準備推送自己的進展上去，卻收到 Josie 的來信，說
 
 我們稱此為_refspec_。更多有關於 Git refspec 的討論和使用方式會在第九章作詳細闡述。
 
-接下來，John 發郵件給 Jessica 告訴她，他看了之後作了些修改，已經推回伺服器 `featureA` 分支，請她過目下。於是 Jessica 運行 `git fetch` 下載最新資料：
+接下來，John 發郵件給 Jessica 告訴她，他看了之後作了些修改，已經推回伺服器 `featureA` 分支，請她過目下。於是 Jessica 執行 `git fetch` 下載最新資料：
 
 	$ git fetch origin
 	...
@@ -369,7 +369,7 @@ Jessica 稍做一番修整後同步到伺服器：
 Insert 18333fig0513.png
 圖 5-13. 在特性分支中提交更新後的提交歷史
 
-現在，Jessica，Josie 和 John 通知集成管理員伺服器上的 `featureA` 及 `featureBee` 分支已經準備好，可以併入主線了。在管理員完成集成工作後，主分支上便多出一個新的合併提交（5399e），用 fetch 命令更新到本地後，提交歷史如圖 5-14 所示：
+現在，Jessica，Josie 和 John 通知整合管理員伺服器上的 `featureA` 及 `featureBee` 分支已經準備好，可以併入主線了。在管理員完成整合工作後，主分支上便多出一個新的合併提交（5399e），用 fetch 命令更新到本地後，提交歷史如圖 5-14 所示：
 
 Insert 18333fig0514.png
 圖 5-14. 合併特性分支後的 Jessica 提交歷史
@@ -381,9 +381,9 @@ Insert 18333fig0515.png
 
 ### 公開的小型專案 ###
 
-上面說的是私有專案協作，但要給公開專案作貢獻，情況就有些不同了。因為你沒有直接更新主倉庫分支的許可權，得尋求其它方式把工作成果交給專案維護人。下面會介紹兩種方法，第一種使用 git 託管服務商提供的倉庫複製功能，一般稱作 fork，比如 repo.or.cz 和 GitHub 都支援這樣的操作，而且許多項目管理員都希望大家使用這樣的方式。另一種方法是通過電子郵件寄送檔補丁。
+上面說的是私有專案協作，但要給公開專案作貢獻，情況就有些不同了。因為你沒有直接更新主倉庫分支的許可權，得尋求其它方式把工作成果交給專案維護人。下面會介紹兩種方法，第一種使用 git 託管服務商提供的倉庫複製功能，一般稱作 fork，比如 repo.or.cz 和 GitHub 都支援這樣的操作，而且許多專案管理員都希望大家使用這樣的方式。另一種方法是通過電子郵件寄送檔修補檔。
 
-但不管哪種方式，起先我們總需要克隆原始倉庫，而後創建特性分支開展工作。基本工作流程如下：
+但不管哪種方式，起先我們總需要克隆原始倉庫，而後建立特性分支開展工作。基本工作流程如下：
 
 	$ git clone (url)
 	$ cd project
@@ -393,19 +393,19 @@ Insert 18333fig0515.png
 	$ (work)
 	$ git commit
 
-你可能想到用 `rebase -i` 將所有更新先變作單個提交，又或者想重新安排提交之間的差異補丁，以方便專案維護者審閱 -- 有關互動式衍合操作的細節見第六章。
+你可能想到用 `rebase -i` 將所有更新先變作單個提交，又或者想重新安排提交之間的差異修補檔，以方便專案維護者審閱 -- 有關互動式衍合操作的細節見第六章。
 
-在完成了特性分支開發，提交給專案維護者之前，先到原始專案的頁面上點擊“Fork”按鈕，創建一個自己可寫的公共倉庫（譯注：即下面的 url 部分，參照後續的例子，應該是 `git://githost/simplegit.git`）。然後將此倉庫添加為本地的第二個遠端倉庫，姑且稱為 `myfork`：
+在完成了特性分支開發，提交給專案維護者之前，先到原始專案的頁面上點選“Fork”按鈕，建立一個自己可寫的公開倉庫（譯注：即下面的 url 部分，參照後續的例子，應該是 `git://githost/simplegit.git`）。然後將此倉庫增加為本地的第二個遠端倉庫，姑且稱為 `myfork`：
 
 	$ git remote add myfork (url)
 
-你需要將本地更新推送到這個倉庫。要是將遠端 master 合併到本地再推回去，還不如把整個特性分支推上去來得乾脆直接。而且，假若項目維護者未採納你的貢獻的話（不管是直接合併還是 cherry pick），都不用回退（rewind）自己的 master 分支。但若維護者合併或 cherry-pick 了你的工作，最後總還可以從他們的更新中同步這些代碼。好吧，現在先把 featureA 分支整個推上去：
+你需要將本地更新推送到這個倉庫。要是將遠端 master 合併到本地再推回去，還不如把整個特性分支推上去來得乾脆直接。而且，假若專案維護者未採納你的貢獻的話（不管是直接合併還是 cherry pick），都不用回退（rewind）自己的 master 分支。但若維護者合併或 cherry-pick 了你的工作，最後總還可以從他們的更新中同步這些代碼。好吧，現在先把 featureA 分支整個推上去：
 
 	$ git push myfork featureA
 
-然後通知專案管理員，讓他來抓取你的代碼。通常我們把這件事叫做 pull request。可以直接用 GitHub 等網站提供的 “pull request” 按鈕自動發送請求通知；或手工把 `git request-pull` 命令輸出結果電郵給專案管理員。
+然後通知專案管理員，讓他來抓取你的代碼。通常我們把這件事叫做 pull request。可以直接用 GitHub 等網站提供的 “pull request” 按鈕自動發送請求通知；或手工把 `git request-pull` 命令輸出結果電子郵件給專案管理員。
 
-`request-pull` 命令接受兩個參數，第一個是本地特性分支開始前的原始分支，第二個是請求對方來抓取的 Git 倉庫 URL（譯注：即下面 `myfork` 所指的，自己可寫的公共倉庫）。比如現在Jessica 準備要給 John 發一個 pull requst，她之前在自己的特性分支上提交了兩次更新，並把分支整個推到了伺服器上，所以運行該命令會看到：
+`request-pull` 命令接受兩個參數，第一個是本地特性分支開始前的原始分支，第二個是請求對方來抓取的 Git 倉庫 URL（譯注：即下面 `myfork` 所指的，自己可寫的公開倉庫）。比如現在Jessica 準備要給 John 發一個 pull requst，她之前在自己的特性分支上提交了兩次更新，並把分支整個推到了伺服器上，所以執行該命令會看到：
 
 	$ git request-pull origin/master myfork
 	The following changes since commit 1edee6b1d61823a2de3b09c160d7080b8d1b3a40:
@@ -425,7 +425,7 @@ Insert 18333fig0515.png
 
 輸出的內容可以直接發郵件給管理者，他們就會明白這是從哪次提交開始旁支出去的，該到哪裡去抓取新的代碼，以及新的代碼增加了哪些功能等等。
 
-像這樣隨時保持自己的 `master` 分支和官方 `origin/master` 同步，並將自己的工作限制在特性分支上的做法，既方便又靈活，採納和丟棄都輕而易舉。就算原始主幹發生變化，我們也能重新衍合提供新的補丁。比如現在要開始第二項特性的開發，不要在原來已推送的特性分支上繼續，還是按原始 `master` 開始：
+像這樣隨時保持自己的 `master` 分支和官方 `origin/master` 同步，並將自己的工作限制在特性分支上的做法，既方便又靈活，採納和丟棄都輕而易舉。就算原始主幹發生變化，我們也能重新衍合提供新的修補檔。比如現在要開始第二項特性的開發，不要在原來已推送的特性分支上繼續，還是按原始 `master` 開始：
 
 	$ git checkout -b featureB origin/master
 	$ (work)
@@ -434,12 +434,12 @@ Insert 18333fig0515.png
 	$ (email maintainer)
 	$ git fetch origin
 
-現在，A、B 兩個特性分支各不相擾，如同竹筒裡的兩顆豆子，佇列中的兩個補丁，你隨時都可以分別從頭寫過，或者衍合，或者修改，而不用擔心特性代碼的交叉混雜。如圖 5-16 所示：
+現在，A、B 兩個特性分支各不相擾，如同竹筒裡的兩顆豆子，佇列中的兩個修補檔，你隨時都可以分別從頭寫過，或者衍合，或者修改，而不用擔心特性代碼的交叉混雜。如圖 5-16 所示：
 
 Insert 18333fig0516.png
 圖 5-16. featureB 以後的提交歷史
 
-假設項目管理員接納了許多別人提交的補丁後，準備要採納你提交的第一個分支，卻發現因為代碼基準不一致，合併工作無法正確乾淨地完成。這就需要你再次衍合到最新的 `origin/master`，解決相關衝突，然後重新提交你的修改：
+假設專案管理員接納了許多別人提交的修補檔後，準備要採納你提交的第一個分支，卻發現因為代碼基準不一致，合併工作無法正確乾淨地完成。這就需要你再次衍合到最新的 `origin/master`，解決相關衝突，然後重新提交你的修改：
 
 	$ git checkout featureA
 	$ git rebase origin/master
@@ -452,7 +452,7 @@ Insert 18333fig0517.png
 
 注意，此時推送分支必須使用 `-f` 選項（譯注：表示 force，不作檢查強制重寫）替換遠端已有的 `featureA` 分支，因為新的 commit 並非原來的後續更新。當然你也可以直接推送到另一個新的分支上去，比如稱作 `featureAv2`。
 
-再考慮另一種情形：管理員看過第二個分支後覺得思路新穎，但想請你改下具體實現。我們只需以當前 `origin/master` 分支為基準，開始一個新的特性分支 `featureBv2`，然後把原來的 `featureB` 的更新拿過來，解決衝突，按要求重新實現部分代碼，然後將此特性分支推送上去：
+再考慮另一種情形：管理員看過第二個分支後覺得思路新穎，但想請你改下具體實現。我們只需以目前 `origin/master` 分支為基準，開始一個新的特性分支 `featureBv2`，然後把原來的 `featureB` 的更新拿過來，解決衝突，按要求重新實現部分代碼，然後將此特性分支推送上去：
 
 	$ git checkout -b featureBv2 origin/master
 	$ git merge --no-commit --squash featureB
@@ -460,7 +460,7 @@ Insert 18333fig0517.png
 	$ git commit
 	$ git push myfork featureBv2
 
-這裡的 `--squash` 選項將目標分支上的所有更改全拿來應用到當前分支上，而 `--no-commit` 選項告訴 Git 此時無需自動生成和記錄（合併）提交。這樣，你就可以在原來代碼基礎上，繼續工作，直到最後一起提交。
+這裡的 `--squash` 選項將目標分支上的所有更改全拿來套用到目前分支上，而 `--no-commit` 選項告訴 Git 此時無需自動生成和記錄（合併）提交。這樣，你就可以在原來代碼基礎上，繼續工作，直到最後一起提交。
 
 好了，現在可以請管理員抓取 `featureBv2` 上的最新代碼了，如圖 5-18 所示：
 
@@ -469,9 +469,9 @@ Insert 18333fig0518.png
 
 ### 公開的大型專案 ###
 
-許多大型專案都會立有一套自己的接受補丁流程，你應該注意下其中細節。但多數專案都允許通過開發者郵寄清單接受補丁，現在我們來看具體例子。
+許多大型專案都會立有一套自己的接受修補檔流程，你應該注意下其中細節。但多數專案都允許通過開發者郵寄清單接受修補檔，現在我們來看具體例子。
 
-整個工作流程類似上面的情形：為每個補丁創建獨立的特性分支，而不同之處在於如何提交這些補丁。不需要創建自己可寫的公共倉庫，也不用將自己的更新推送到自己的伺服器，你只需將每次提交的差異內容以電子郵件的方式依次發送到郵寄清單中即可。
+整個工作流程類似上面的情形：為每個修補檔建立獨立的特性分支，而不同之處在於如何提交這些修補檔。不需要建立自己可寫的公開倉庫，也不用將自己的更新推送到自己的伺服器，你只需將每次提交的差異內容以電子郵件的方式依次發送到郵寄清單中即可。
 
 	$ git checkout -b topicA
 	$ (work)
@@ -479,13 +479,13 @@ Insert 18333fig0518.png
 	$ (work)
 	$ git commit
 
-如此一番後，有了兩個提交要發到郵寄清單。我們可以用 `git format-patch` 命令來生成 mbox 格式的檔然後作為附件發送。每個提交都會封裝為一個 `.patch` 尾碼的 mbox 檔，但其中只包含一封郵件，郵件標題就是提交消息（譯注：額外有首碼，看例子），郵件內容包含補丁正文和 Git 版本號。這種方式的妙處在於接受補丁時仍可保留原來的提交消息，請看接下來的例子：
+如此一番後，有了兩個提交要發到郵寄清單。我們可以用 `git format-patch` 命令來生成 mbox 格式的檔然後作為附件發送。每個提交都會封裝為一個 `.patch` 尾碼的 mbox 檔，但其中只包含一封郵件，郵件標題就是提交資訊（譯注：額外有首碼，看例子），郵件內容包含修補檔正文和 Git 版本號。這種方式的妙處在於接受修補檔時仍可保留原來的提交資訊，請看接下來的例子：
 
 	$ git format-patch -M origin/master
 	0001-add-limit-to-log-function.patch
 	0002-changed-log-output-to-30-from-25.patch
 
-`format-patch` 命令依次創建補丁文件，並輸出檔案名。上面的 `-M` 選項允許 Git 檢查是否有對檔重命名的提交。我們來看看補丁檔的內容：
+`format-patch` 命令依次建立修補檔文件，並輸出檔案名。上面的 `-M` 選項允許 Git 檢查是否有對檔重命名的提交。我們來看看修補檔檔的內容：
 
 	$ cat 0001-add-limit-to-log-function.patch
 	From 330090432754092d704da8e76ca5c05c198e71a8 Mon Sep 17 00:00:00 2001
@@ -515,11 +515,11 @@ Insert 18333fig0518.png
 	--
 	1.6.2.rc1.20.g8c5b.dirty
 
-如果有額外資訊需要補充，但又不想放在提交消息中說明，可以編輯這些補丁檔，在第一個 `---` 行之前添加說明，但不要修改下面的補丁正文，比如例子中的 `Limit log functionality to the first 20` 部分。這樣，其它開發者能閱讀，但在採納補丁時不會將此合併進來。
+如果有額外資訊需要補充，但又不想放在提交資訊中說明，可以編輯這些修補檔檔，在第一個 `---` 行之前增加說明，但不要修改下面的修補檔正文，比如例子中的 `Limit log functionality to the first 20` 部分。這樣，其它開發者能閱讀，但在採納修補檔時不會將此合併進來。
 
-你可以用郵件用戶端軟體發送這些補丁檔，也可以直接在命令列發送。有些所謂智慧的郵件用戶端軟體會自作主張幫你調整格式，所以粘貼補丁到郵件正文時，有可能會丟失分行符號和若干空格。Git 提供了一個通過 IMAP 發送補丁檔的工具。接下來我會演示如何通過 Gmail 的 IMAP 伺服器發送。另外，在 Git 原始程式碼中有個 `Documentation/SubmittingPatches` 檔，可以仔細讀讀，看看其它郵件程式的相關導引。
+你可以用郵件用戶端軟體發送這些修補檔檔，也可以直接在命令列發送。有些所謂智慧的郵件用戶端軟體會自作主張幫你調整格式，所以粘貼修補檔到郵件正文時，有可能會丟失分行符號和若干空格。Git 提供了一個通過 IMAP 發送修補檔檔的工具。接下來我會演示如何通過 Gmail 的 IMAP 伺服器發送。另外，在 Git 原始程式碼中有個 `Documentation/SubmittingPatches` 檔，可以仔細讀讀，看看其它郵件程式的相關導引。
 
-首先在 `~/.gitconfig` 檔中配置 imap 項。每個選項都可用 `git config` 命令分別設置，當然直接編輯檔添加以下內容更便捷：
+首先在 `~/.gitconfig` 檔中設定 imap 項。每個選項都可用 `git config` 命令分別設定，當然直接編輯檔增加以下內容更方便：
 
 	[imap]
 	  folder = "[Gmail]/Drafts"
@@ -529,8 +529,8 @@ Insert 18333fig0518.png
 	  port = 993
 	  sslverify = false
 
-如果你的 IMAP 伺服器沒有啟用 SSL，就無需配置最後那兩行，並且 host 應該以 `imap://` 開頭而不再是有 `s` 的 `imaps://`。
-保存設定檔後，就能用 `git send-email` 命令把補丁作為郵件依次發送到指定的 IMAP 伺服器上的資料夾中（譯注：這裡就是 Gmail 的 `[Gmail]/Drafts` 資料夾。但如果你的語言設置不是英文，此處的資料夾 Drafts 字樣會變為對應的語言。）：
+如果你的 IMAP 伺服器沒有啟用 SSL，就無需設定最後那兩行，並且 host 應該以 `imap://` 開頭而不再是有 `s` 的 `imaps://`。
+保存設定檔後，就能用 `git send-email` 命令把修補檔作為郵件依次發送到指定的 IMAP 伺服器上的資料夾中（譯注：這裡就是 Gmail 的 `[Gmail]/Drafts` 資料夾。但如果你的語言設定不是英文，此處的資料夾 Drafts 字樣會變為對應的語言。）：
 
 	$ cat *.patch |git imap-send
 	Resolving imap.gmail.com... ok
@@ -559,7 +559,7 @@ After this is done, you can use `git send-email` to send your patches:
 	Who should the emails be sent to? jessica@example.com
 	Message-ID to be used as In-Reply-To for the first email? y
 
-接下來，Git 會根據每個補丁依次輸出類似下面的日誌：
+接下來，Git 會根據每個修補檔依次輸出類似下面的日誌：
 
 	(mbox) Adding cc: Jessica Smith <jessica@example.com> from
 	  \line 'From: Jessica Smith <jessica@example.com>'
@@ -578,16 +578,16 @@ After this is done, you can use `git send-email` to send your patches:
 
 ### 小結 ###
 
-本節主要介紹了常見 Git 專案協作的工作流程，還有一些説明處理這些工作的命令和工具。接下來我們要看看如何維護 Git 項目，並成為一個合格的項目管理員，或是集成經理。
+本節主要介紹了常見 Git 專案協作的工作流程，還有一些説明處理這些工作的命令和工具。接下來我們要看看如何維護 Git 專案，並成為一個合格的專案管理員，或是整合經理。
 
 ## 專案的管理 ##
 
-既然是相互協作，在貢獻代碼的同時，也免不了要維護管理自己的專案。像是怎麼處理別人用 `format-patch` 生成的補丁，或是集成遠端倉庫上某個分支上的變化等等。但無論是管理代碼倉庫，還是幫忙審核收到的補丁，都需要同貢獻者約定某種長期可持續的工作方式。
+既然是相互協作，在貢獻代碼的同時，也免不了要維護管理自己的專案。像是怎麼處理別人用 `format-patch` 生成的修補檔，或是整合遠端倉庫上某個分支上的變化等等。但無論是管理代碼倉庫，還是幫忙審核收到的修補檔，都需要同貢獻者約定某種長期可持續的工作方式。
 
 ### 使用特性分支進行工作 ###
 
-如果想要集成新的代碼進來，最好局限在特性分支上做。臨時的特性分支可以讓你隨意嘗試，進退自如。比如碰上無法正常工作的補丁，可以先擱在那邊，直到有時間仔細核查修復為止。創建的分支可以用相關的主題關鍵字命名，比如 `ruby_client` 或者其它類似的描述性詞語，以幫助將來回憶。Git 專案本身還時常把分支名稱分置於不同命名空間下，比如 `sc/ruby_client` 就說明這是 `sc` 這個人貢獻的。
-現在從當前主幹分支為基礎，新建臨時分支：
+如果想要整合新的代碼進來，最好局限在特性分支上做。臨時的特性分支可以讓你隨意嘗試，進退自如。比如碰上無法正常工作的修補檔，可以先擱在那邊，直到有時間仔細核查修復為止。建立的分支可以用相關的主題關鍵字命名，比如 `ruby_client` 或者其它類似的描述性詞語，以幫助將來回憶。Git 專案本身還時常把分支名稱分置於不同命名空間下，比如 `sc/ruby_client` 就說明這是 `sc` 這個人貢獻的。
+現在從目前主幹分支為基礎，新建臨時分支：
 
 	$ git branch sc/ruby_client master
 
@@ -597,31 +597,31 @@ After this is done, you can use `git send-email` to send your patches:
 
 好了，現在已經準備妥當，可以試著將別人貢獻的代碼合併進來了。之後評估一下有沒有問題，最後再決定是不是真的要併入主幹。
 
-### 採納來自郵件的補丁 ###
+### 採納來自郵件的修補檔 ###
 
-如果收到一個通過電郵發來的補丁，你應該先把它應用到特性分支上進行評估。有兩種應用補丁的方法：`git apply` 或者 `git am`。
+如果收到一個通過電子郵件發來的修補檔，你應該先把它套用到特性分支上進行評估。有兩種應用修補檔的方法：`git apply` 或者 `git am`。
 
-#### 使用 apply 命令應用補丁 ####
+#### 使用 apply 命令應用修補檔 ####
 
-如果收到的補丁文件是用 `git diff` 或由其它 Unix 的 `diff` 命令生成，就該用 `git apply` 命令來應用補丁。假設補丁文件存在 `/tmp/patch-ruby-client.patch`，可以這樣運行：
+如果收到的修補檔文件是用 `git diff` 或由其它 Unix 的 `diff` 命令生成，就該用 `git apply` 命令來應用修補檔。假設修補檔文件存在 `/tmp/patch-ruby-client.patch`，可以這樣執行：
 
 	$ git apply /tmp/patch-ruby-client.patch
 
-這會修改當前工作目錄下的檔，效果基本與運行 `patch -p1` 打補丁一樣，但它更為嚴格，且不會出現混亂。如果是 `git diff` 格式描述的補丁，此命令還會相應地添加，刪除，重命名檔。當然，普通的 `patch` 命令是不會這麼做的。另外請注意，`git apply` 是一個事務性操作的命令，也就是說，要麼所有補丁都打上去，要麼全部放棄。所以不會出現 `patch` 命令那樣，一部分檔打上了補丁而另一部分卻沒有，這樣一種不上不下的修訂狀態。所以總的來說，`git apply` 要比 `patch` 嚴謹許多。因為僅僅是更新當前的檔，所以此命令不會自動生成提交物件，你得手工緩存相應檔的更新狀態並執行提交命令。
+這會修改目前工作目錄下的檔，效果基本與執行 `patch -p1` 打修補檔一樣，但它更為嚴格，且不會出現混亂。如果是 `git diff` 格式描述的修補檔，此命令還會相應地增加，刪除，重命名檔。當然，普通的 `patch` 命令是不會這麼做的。另外請注意，`git apply` 是一個事務性操作的命令，也就是說，要麼所有修補檔都打上去，要麼全部放棄。所以不會出現 `patch` 命令那樣，一部分檔打上了修補檔而另一部分卻沒有，這樣一種不上不下的修訂狀態。所以總的來說，`git apply` 要比 `patch` 嚴謹許多。因為僅僅是更新目前的檔，所以此命令不會自動生成提交物件，你得手工緩存相應檔的更新狀態並執行提交命令。
 
-在實際打補丁之前，可以先用 `git apply --check` 查看補丁是否能夠乾淨順利地應用到當前分支中：
+在實際打修補檔之前，可以先用 `git apply --check` 查看修補檔是否能夠乾淨順利地套用到目前分支中：
 
 	$ git apply --check 0001-seeing-if-this-helps-the-gem.patch
 	error: patch failed: ticgit.gemspec:1
 	error: ticgit.gemspec: patch does not apply
 
-如果沒有任何輸出，表示我們可以順利採納該補丁。如果有問題，除了報告錯誤資訊之外，該命令還會返回一個非零的狀態，所以在 shell 腳本裡可用於檢測狀態。
+如果沒有任何輸出，表示我們可以順利採納該修補檔。如果有問題，除了報告錯誤資訊之外，該命令還會返回一個非零的狀態，所以在 shell 腳本裡可用於檢測狀態。
 
-#### 使用 am 命令應用補丁 ####
+#### 使用 am 命令應用修補檔 ####
 
-如果貢獻者也用 Git，且擅於製作 `format-patch` 補丁，那你的合併工作將會非常輕鬆。因為這些補丁中除了檔內容差異外，還包含了作者資訊和提交消息。所以請鼓勵貢獻者用 `format-patch` 生成補丁。對於傳統的 `diff` 命令生成的補丁，則只能用 `git apply` 處理。
+如果貢獻者也用 Git，且擅於製作 `format-patch` 修補檔，那你的合併工作將會非常輕鬆。因為這些修補檔中除了檔內容差異外，還包含了作者資訊和提交資訊。所以請鼓勵貢獻者用 `format-patch` 生成修補檔。對於傳統的 `diff` 命令生成的修補檔，則只能用 `git apply` 處理。
 
-對於 `format-patch` 製作的新式補丁，應當使用 `git am` 命令。從技術上來說，`git am`  能夠讀取 mbox 格式的檔。這是種簡單的純文字檔，可以包含多封電郵，格式上用 From 加空格以及隨便什麼輔助資訊所組成的行作為分隔行，以區分每封郵件，就像這樣：
+對於 `format-patch` 製作的新式修補檔，應當使用 `git am` 命令。從技術上來說，`git am`  能夠讀取 mbox 格式的檔案。這是種簡單的純文字檔，可以包含多封電子郵件，格式上用 From 加空格以及隨便什麼輔助資訊所組成的行作為分隔行，以區分每封郵件，就像這樣：
 
 	From 330090432754092d704da8e76ca5c05c198e71a8 Mon Sep 17 00:00:00 2001
 	From: Jessica Smith <jessica@example.com>
@@ -630,14 +630,14 @@ After this is done, you can use `git send-email` to send your patches:
 
 	Limit log functionality to the first 20
 
-這是 `format-patch` 命令輸出的開頭幾行，也是一個有效的 mbox 檔案格式。如果有人用 `git send-email` 給你發了一個補丁，你可以將此郵件下載到本地，然後運行 `git am` 命令來應用這個補丁。如果你的郵件用戶端能將多封電郵匯出為 mbox 格式的檔，就可以用 `git am` 一次性應用所有匯出的補丁。
+這是 `format-patch` 命令輸出的開頭幾行，也是一個有效的 mbox 檔案格式。如果有人用 `git send-email` 給你發了一個修補檔，你可以將此郵件下載到本地，然後執行 `git am` 命令來應用這個修補檔。如果你的郵件用戶端能將多封電子郵件匯出為 mbox 格式的檔，就可以用 `git am` 一次性應用所有匯出的修補檔。
 
-如果貢獻者將 `format-patch` 生成的補丁檔上傳到類似 Request Ticket 一樣的任務處理系統，那麼可以先下載到本地，繼而使用 `git am` 應用該補丁：
+如果貢獻者將 `format-patch` 生成的修補檔檔上傳到類似 Request Ticket 一樣的任務處理系統，那麼可以先下載到本地，繼而使用 `git am` 應用該修補檔：
 
 	$ git am 0001-limit-log-function.patch
 	Applying: add limit to log function
 
-你會看到它被乾淨地應用到本地分支，並自動創建了新的提交物件。作者資訊取自郵件頭 `From` 和 `Date`，提交消息則取自 `Subject` 以及正文中補丁之前的內容。來看具體實例，採納之前展示的那個 mbox 電郵補丁後，最新的提交對象為：
+你會看到它被乾淨地套用到本地分支，並自動建立了新的提交物件。作者資訊取自郵件標頭 `From` 和 `Date`，提交資訊則取自 `Subject` 以及正文中修補檔之前的內容。來看具體實例，採納之前示範的那個 mbox 電子郵件修補檔後，最新的提交對象為：
 
 	$ git log --pretty=fuller -1
 	commit 6c5e70b984a60b3cecd395edd5b48a7575bf58e0
@@ -650,9 +650,9 @@ After this is done, you can use `git send-email` to send your patches:
 
 	   Limit log functionality to the first 20
 
-`Commit` 部分顯示的是採納補丁的人，以及採納的時間。而 `Author` 部分則顯示的是原作者，以及創建補丁的時間。
+`Commit` 部分顯示的是採納修補檔的人，以及採納的時間。而 `Author` 部分則顯示的是原作者，以及建立修補檔的時間。
 
-有時，我們也會遇到打不上補丁的情況。這多半是因為主幹分支和補丁的基礎分支相差太遠，但也可能是因為某些依賴補丁還未應用。這種情況下，`git am` 會報錯並詢問該怎麼做：
+有時，我們也會遇到打不上修補檔的情況。這多半是因為主幹分支和修補檔的基礎分支相差太遠，但也可能是因為某些依賴修補檔還未應用。這種情況下，`git am` 會報錯並詢問該怎麼做：
 
 	$ git am 0001-seeing-if-this-helps-the-gem.patch
 	Applying: seeing if this helps the gem
@@ -663,14 +663,14 @@ After this is done, you can use `git send-email` to send your patches:
 	If you would prefer to skip this patch, instead run "git am --skip".
 	To restore the original branch and stop patching run "git am --abort".
 
-Git 會在有衝突的檔裡加入衝突解決標記，這同合併或衍合操作一樣。解決的辦法也一樣，先編輯檔消除衝突，然後暫存檔，最後運行 `git am --resolved` 提交修正結果：
+Git 會在有衝突的檔裡加入衝突解決標記，這同合併或衍合操作一樣。解決的辦法也一樣，先編輯檔消除衝突，然後暫存檔，最後執行 `git am --resolved` 提交修正結果：
 
 	$ (fix the file)
 	$ git add ticgit.gemspec
 	$ git am --resolved
 	Applying: seeing if this helps the gem
 
-如果想讓 Git 更智慧地處理衝突，可以用 `-3` 選項進行三方合併。如果當前分支未包含該補丁的基礎代碼或其祖先，那麼三方合併就會失敗，所以該選項預設為關閉狀態。一般來說，如果該補丁是基於某個公開的提交製作而成的話，你總是可以通過同步來獲取這個共同祖先，所以用三方合併選項可以解決很多麻煩：
+如果想讓 Git 更智慧地處理衝突，可以用 `-3` 選項進行三方合併。如果目前分支未包含該修補檔的基礎代碼或其祖先，那麼三方合併就會失敗，所以該選項預設為關閉狀態。一般來說，如果該修補檔是基於某個公開的提交製作而成的話，你總是可以通過同步來取得這個共同祖先，所以用三方合併選項可以解決很多麻煩：
 
 	$ git am -3 0001-seeing-if-this-helps-the-gem.patch
 	Applying: seeing if this helps the gem
@@ -680,9 +680,9 @@ Git 會在有衝突的檔裡加入衝突解決標記，這同合併或衍合操
 	Falling back to patching base and 3-way merge...
 	No changes -- Patch already applied.
 
-像上面的例子，對於打過的補丁我又再打一遍，自然會產生衝突，但因為加上了 `-3` 選項，所以它很聰明地告訴我，無需更新，原有的補丁已經應用。
+像上面的例子，對於打過的修補檔我又再打一遍，自然會產生衝突，但因為加上了 `-3` 選項，所以它很聰明地告訴我，無需更新，原有的修補檔已經應用。
 
-對於一次應用多個補丁時所用的 mbox 格式檔，可以用 `am` 命令的交互模式選項 `-i`，這樣就會在打每個補丁前停住，詢問該如何操作：
+對於一次應用多個修補檔時所用的 mbox 格式檔，可以用 `am` 命令的交互模式選項 `-i`，這樣就會在打每個修補檔前停住，詢問該如何操作：
 
 	$ git am -3 -i mbox
 	Commit Body is:
@@ -691,13 +691,13 @@ Git 會在有衝突的檔裡加入衝突解決標記，這同合併或衍合操
 	--------------------------
 	Apply? [y]es/[n]o/[e]dit/[v]iew patch/[a]ccept all
 
-在多個補丁要打的情況下，這是個非常好的辦法，一方面可以預覽下補丁內容，同時也可以有選擇性的接納或跳過某些補丁。
+在多個修補檔要打的情況下，這是個非常好的辦法，一方面可以預覽下修補檔內容，同時也可以有選擇性的接納或跳過某些修補檔。
 
-打完所有補丁後，如果測試下來新特性可以正常工作，那就可以安心地將當前特性分支合併到長期分支中去了。
+打完所有修補檔後，如果測試下來新特性可以正常工作，那就可以安心地將目前特性分支合併到長期分支中去了。
 
 ### 檢出遠端分支 ###
 
-如果貢獻者有自己的 Git 倉庫，並將修改推送到此倉庫中，那麼當你拿到倉庫的訪問位址和對應分支的名稱後，就可以加為遠端分支，然後在本地進行合併。
+如果貢獻者有自己的 Git 倉庫，並將修改推送到此倉庫中，那麼當你拿到倉庫的存取位址和對應分支的名稱後，就可以加為遠端分支，然後在本地進行合併。
 
 比如，Jessica 發來一封郵件，說在她代碼庫中的 `ruby-client` 分支上已經實現了某個非常棒的新功能，希望我們能幫忙測試一下。我們可以先把她的倉庫加為遠端倉庫，然後抓取資料，完了再將她所說的分支檢出到本地來測試：
 
@@ -705,13 +705,13 @@ Git 會在有衝突的檔裡加入衝突解決標記，這同合併或衍合操
 	$ git fetch jessica
 	$ git checkout -b rubyclient jessica/ruby-client
 
-若是不久她又發來郵件，說還有個很棒的功能實現在另一分支上，那我們只需重新抓取下最新資料，然後檢出那個分支到本地就可以了，無需重複設置遠端倉庫。
+若是不久她又發來郵件，說還有個很棒的功能實現在另一分支上，那我們只需重新抓取下最新資料，然後檢出那個分支到本地就可以了，無需重複設定遠端倉庫。
 
-這種做法便於同別人保持長期的合作關係。但前提是要求貢獻者有自己的伺服器，而我們也需要為每個人建一個遠端分支。有些貢獻者提交代碼補丁並不是很頻繁，所以通過郵件接收補丁效率會更高。同時我們自己也不會希望建上百來個分支，卻只從每個分支取一兩個補丁。但若是用腳本程式來管理，或直接使用代碼倉庫託管服務，就可以簡化此過程。當然，選擇何種方式取決於你和貢獻者的喜好。
+這種做法便於同別人保持長期的合作關係。但前提是要求貢獻者有自己的伺服器，而我們也需要為每個人建一個遠端分支。有些貢獻者提交代碼修補檔並不是很頻繁，所以通過郵件接收修補檔效率會更高。同時我們自己也不會希望建上百來個分支，卻只從每個分支取一兩個修補檔。但若是用腳本程式來管理，或直接使用代碼倉庫託管服務，就可以簡化此過程。當然，選擇何種方式取決於你和貢獻者的喜好。
 
-使用遠端分支的另外一個好處是能夠得到提交歷史。不管代碼合併是不是會有問題，至少我們知道該分支的歷史分叉點，所以默認會從共同祖先開始自動進行三方合併，無需 `-3` 選項，也不用像打補丁那樣祈禱存在共同的基準點。
+使用遠端分支的另外一個好處是能夠得到提交歷史。不管代碼合併是不是會有問題，至少我們知道該分支的歷史分叉點，所以預設會從共同祖先開始自動進行三方合併，無需 `-3` 選項，也不用像打修補檔那樣祈禱存在共同的基準點。
 
-如果只是臨時合作，只需用 `git pull` 命令抓取遠端倉庫上的資料，合併到本地臨時分支就可以了。一次性的抓取動作自然不會把該倉庫位址加為遠程倉庫。
+如果只是臨時合作，只需用 `git pull` 命令抓取遠端倉庫上的資料，合併到本地臨時分支就可以了。一次性的抓取動作自然不會把該倉庫位址加為遠端倉庫。
 
 	$ git pull git://github.com/onetimeguy/project.git
 	From git://github.com/onetimeguy/project
@@ -722,7 +722,7 @@ Git 會在有衝突的檔裡加入衝突解決標記，這同合併或衍合操
 
 現在特性分支上已合併好了貢獻者的代碼，是時候決斷取捨了。本節將回顧一些之前學過的命令，以看清將要合併到主幹的是哪些代碼，從而理解它們到底做了些什麼，是否真的要併入。
 
-一般我們會先看下，特性分支上都有哪些新增的提交。比如在 `contrib` 特性分支上打了兩個補丁，僅查看這兩個補丁的提交資訊，可以用 `--not` 選項指定要遮罩的分支 `master`，這樣就會剔除重複的提交歷史：
+一般我們會先看下，特性分支上都有哪些新增的提交。比如在 `contrib` 特性分支上打了兩個修補檔，僅查看這兩個修補檔的提交資訊，可以用 `--not` 選項指定要遮罩的分支 `master`，這樣就會剔除重複的提交歷史：
 
 	$ git log contrib --not master
 	commit 5b6235bd297351589efc4d73316f0a68d484f118
@@ -737,13 +737,13 @@ Git 會在有衝突的檔裡加入衝突解決標記，這同合併或衍合操
 
 	    updated the gemspec to hopefully work better
 
-還可以查看每次提交的具體修改。請牢記，在 `git log` 後加 `-p` 選項將展示每次提交的內容差異。
+還可以查看每次提交的具體修改。請牢記，在 `git log` 後加 `-p` 選項將示範每次提交的內容差異。
 
-如果想看當前分支同其他分支合併時的完整內容差異，有個小竅門：
+如果想看目前分支同其他分支合併時的完整內容差異，有個小竅門：
 
 	$ git diff master
 
-雖然能得到差異內容，但請記住，結果有可能和我們的預期不同。一旦主幹 `master` 在特性分支創建之後有所修改，那麼通過 `diff` 命令來比較的，是最新主幹上的提交快照。顯然，這不是我們所要的。比方在 `master` 分支中某個檔裡添了一行，然後運行上面的命令，簡單的比較最新快照所得到的結論只能是，特性分支中刪除了這一行。
+雖然能得到差異內容，但請記住，結果有可能和我們的預期不同。一旦主幹 `master` 在特性分支建立之後有所修改，那麼通過 `diff` 命令來比較的，是最新主幹上的提交快照。顯然，這不是我們所要的。比方在 `master` 分支中某個檔裡添了一行，然後執行上面的命令，簡單的比較最新快照所得到的結論只能是，特性分支中刪除了這一行。
 
 這個很好理解：如果 `master` 是特性分支的直接祖先，不會產生任何問題；如果它們的提交歷史在不同的分叉上，那麼產生的內容差異，看起來就像是增加了特性分支上的新代碼，同時刪除了 `master` 分支上的新代碼。
 
@@ -755,19 +755,19 @@ Git 會在有衝突的檔裡加入衝突解決標記，這同合併或衍合操
 	36c7dba2c95e6bbb78dfa822519ecfec6e1ca649
 	$ git diff 36c7db
 
-但這麼做很麻煩，所以 Git 提供了便捷的 `...` 語法。對於 `diff` 命令，可以把 `...` 加在原始分支（擁有共同祖先）和當前分支之間：
+但這麼做很麻煩，所以 Git 提供了方便的 `...` 語法。對於 `diff` 命令，可以把 `...` 加在原始分支（擁有共同祖先）和目前分支之間：
 
 	$ git diff master...contrib
 
 現在看到的，就是實際將要引入的新代碼。這是一個非常有用的命令，應該牢記。
 
-### 代碼集成 ###
+### 代碼整合 ###
 
-一旦特性分支準備停當，接下來的問題就是如何集成到更靠近主線的分支中。此外還要考慮維護專案的總體步驟是什麼。雖然有很多選擇，不過我們這裡只介紹其中一部分。
+一旦特性分支準備停當，接下來的問題就是如何整合到更靠近主線的分支中。此外還要考慮維護專案的總體步驟是什麼。雖然有很多選擇，不過我們這裡只介紹其中一部分。
 
 #### 合併流程 ####
 
-一般最簡單的情形，是在 `master` 分支中維護穩定代碼，然後在特性分支上開發新功能，或是審核測試別人貢獻的代碼，接著將它併入主幹，最後刪除這個特性分支，如此反復。來看示例，假設當前代碼庫中有兩個分支，分別為 `ruby_client` 和 `php_client`，如圖 5-19 所示。然後先把 `ruby_client` 合併進主幹，再合併 `php_client`，最後的提交歷史如圖 5-20 所示。
+一般最簡單的情形，是在 `master` 分支中維護穩定代碼，然後在特性分支上開發新功能，或是審核測試別人貢獻的代碼，接著將它併入主幹，最後刪除這個特性分支，如此反覆。來看示例，假設目前代碼庫中有兩個分支，分別為 `ruby_client` 和 `php_client`，如圖 5-19 所示。然後先把 `ruby_client` 合併進主幹，再合併 `php_client`，最後的提交歷史如圖 5-20 所示。
 
 Insert 18333fig0519.png
 圖 5-19. 多個特性分支
@@ -775,7 +775,7 @@ Insert 18333fig0519.png
 Insert 18333fig0520.png
 圖 5-20. 合併特性分支之後
 
-這是最簡單的流程，所以在處理大一些的項目時可能會有問題。
+這是最簡單的流程，所以在處理大一些的專案時可能會有問題。
 
 對於大型專案，至少需要維護兩個長期分支 `master` 和 `develop`。新代碼（圖 5-21 中的 `ruby_client`）將首先併入 `develop` 分支（圖 5-22 中的 `C8`），經過一個階段，確認 `develop` 中的代碼已穩定到可發行時，再將 `master` 分支快進到穩定點（圖 5-23 中的 `C8`）。而平時這兩個分支都會被推送到公開的代碼庫。
 
@@ -793,7 +793,7 @@ Insert 18333fig0523.png
 
 #### 大專案的合併流程 ####
 
-Git 專案本身有四個長期分支：用於發佈的 `master` 分支、用於合併基本穩定特性的 `next` 分支、用於合併仍需改進特性的 `pu` 分支（pu 是 proposed updates 的縮寫），以及用於除錯維護的 `maint` 分支（maint 取自 maintenance）。維護者可以按照之前介紹的方法，將貢獻者的代碼引入為不同的特性分支（如圖 5-24 所示），然後測試評估，看哪些特性能穩定工作，哪些還需改進。穩定的特性可以併入 `next` 分支，然後再推送到公共倉庫，以供其他人試用。
+Git 專案本身有四個長期分支：用於發佈的 `master` 分支、用於合併基本穩定特性的 `next` 分支、用於合併仍需改進特性的 `pu` 分支（pu 是 proposed updates 的縮寫），以及用於除錯維護的 `maint` 分支（maint 取自 maintenance）。維護者可以按照之前介紹的方法，將貢獻者的代碼引入為不同的特性分支（如圖 5-24 所示），然後測試評估，看哪些特性能穩定工作，哪些還需改進。穩定的特性可以併入 `next` 分支，然後再推送到公開倉庫，以供其他人試用。
 
 Insert 18333fig0524.png
 圖 5-24. 管理複雜的並行貢獻
@@ -803,13 +803,13 @@ Insert 18333fig0524.png
 Insert 18333fig0525.png
 圖 5-25. 將特性併入長期分支
 
-併入 `master` 後的特性分支，已經無需保留分支索引，放心刪除好了。Git 專案還有一個 `maint` 分支，它是以最近一次發行版本為基礎分化而來的，用於維護除錯補丁。所以克隆 Git 項目倉庫後會得到這四個分支，通過檢出不同分支可以瞭解各自進展，或是試用前沿特性，或是貢獻代碼。而維護者則通過管理這些分支，逐步有序地併入協力廠商貢獻。
+併入 `master` 後的特性分支，已經無需保留分支索引，放心刪除好了。Git 專案還有一個 `maint` 分支，它是以最近一次發行版本為基礎分化而來的，用於維護除錯修補檔。所以克隆 Git 專案倉庫後會得到這四個分支，通過檢出不同分支可以瞭解各自進展，或是試用前沿特性，或是貢獻代碼。而維護者則通過管理這些分支，逐步有序地併入協力廠商貢獻。
 
 #### 衍合與挑揀（cherry-pick）的流程 ####
 
 一些維護者更喜歡衍合或者挑揀貢獻者的代碼，而不是簡單的合併，因為這樣能夠保持線性的提交歷史。如果你完成了一個特性的開發，並決定將它引入到主幹代碼中，你可以轉到那個特性分支然後執行衍合命令，好在你的主幹分支上（也可能是`develop`分支之類的）重新提交這些修改。如果這些代碼工作得很好，你就可以快進`master`分支，得到一個線性的提交歷史。
 
-另一個引入代碼的方法是挑揀。挑揀類似於針對某次特定提交的衍合。它首先提取某次提交的補丁，然後試著應用在當前分支上。如果某個特性分支上有多個commits，但你只想引入其中之一就可以使用這種方法。也可能僅僅是因為你喜歡用挑揀，討厭衍合。假設你有一個類似圖 5-26 的工程。
+另一個引入代碼的方法是挑揀。挑揀類似於針對某次特定提交的衍合。它首先提取某次提交的修補檔，然後試著應用在目前分支上。如果某個特性分支上有多個commits，但你只想引入其中之一就可以使用這種方法。也可能僅僅是因為你喜歡用挑揀，討厭衍合。假設你有一個類似圖 5-26 的工程。
 
 Insert 18333fig0526.png
 圖 5-26. 挑揀（cherry-pick）之前的歷史 
@@ -851,26 +851,26 @@ Insert 18333fig0527.png
 	$ gpg -a --export F721C45A | git hash-object -w --stdin
 	659ef797d181633c87ec71ac3f9ba29fe5775b92
 
-現在你的Git已經包含了這個key的內容了，可以通過不同的SHA-1值指定不同的key來創建標籤。
+現在你的Git已經包含了這個key的內容了，可以通過不同的SHA-1值指定不同的key來建立標籤。
 
 	$ git tag -a maintainer-pgp-pub 659ef797d181633c87ec71ac3f9ba29fe5775b92
 
-在運行`git push --tags`命令之後，`maintainer-pgp-pub`標籤就會公佈給所有人。如果有人想要校驗標籤，他可以使用如下命令導入你的key：
+在執行`git push --tags`命令之後，`maintainer-pgp-pub`標籤就會公佈給所有人。如果有人想要校驗標籤，他可以使用如下命令導入你的key：
 
 	$ git show maintainer-pgp-pub | gpg --import
 
-人們可以用這個key校驗你簽名的所有標籤。另外，你也可以在標籤資訊裡寫入一個操作嚮導，用戶只需要運行`git show <tag>`查看標籤資訊，然後按照你的嚮導就能完成校驗。
+人們可以用這個key校驗你簽名的所有標籤。另外，你也可以在標籤資訊裡寫入一個操作嚮導，用戶只需要執行`git show <tag>`查看標籤資訊，然後按照你的嚮導就能完成校驗。
 
 ### 生成內部版本號 ###
 
-因為Git不會為每次提交自動附加類似'v123'的遞增序列，所以如果你想要得到一個便於理解的提交號可以運行`git describe`命令。Git將會返回一個字串，由三部分組成：最近一次標定的版本號，加上自那次標定之後的提交次數，再加上一段所描述的提交的SHA-1值：
+因為Git不會為每次提交自動附加類似'v123'的遞增序列，所以如果你想要得到一個便於理解的提交號可以執行`git describe`命令。Git將會返回一個字串，由三部分組成：最近一次標定的版本號，加上自那次標定之後的提交次數，再加上一段所描述的提交的SHA-1值：
 
 	$ git describe master
 	v1.6.2-rc1-20-g8c5b85c
 
-這個字串可以作為快照的名字，方便人們理解。如果你的Git是你自己下載源碼然後編譯安裝的，你會發現`git --version`命令的輸出和這個字串差不多。如果在一個剛剛打完標籤的提交上運行`describe`命令，只會得到這次標定的版本號，而沒有後面兩項資訊。
+這個字串可以作為快照的名字，方便人們理解。如果你的Git是你自己下載原始碼然後編譯安裝的，你會發現`git --version`命令的輸出和這個字串差不多。如果在一個剛剛打完標籤的提交上執行`describe`命令，只會得到這次標定的版本號，而沒有後面兩項資訊。
 
-`git describe`命令只適用於有標注的標籤（通過`-a`或者`-s`選項創建的標籤），所以發行版本的標籤都應該是帶有標注的，以保證`git describe`能夠正確的執行。你也可以把這個字串作為`checkout`或者`show`命令的目標，因為他們最終都依賴於一個簡短的SHA-1值，當然如果這個SHA-1值失效他們也跟著失效。最近Linux內核為了保證SHA-1值的唯一性，將位數由8位擴展到10位，這就導致擴展之前的`git describe`輸出完全失效了。
+`git describe`命令只適用於有標注的標籤（通過`-a`或者`-s`選項建立的標籤），所以發行版本的標籤都應該是帶有標注的，以保證`git describe`能夠正確的執行。你也可以把這個字串作為`checkout`或者`show`命令的目標，因為他們最終都依賴於一個簡短的SHA-1值，當然如果這個SHA-1值失效他們也跟著失效。最近Linux核心為了保證SHA-1值的唯一性，將位數由8位擴展到10位，這就導致擴展之前的`git describe`輸出完全失效了。
 
 ### 準備發佈 ###
 
@@ -880,7 +880,7 @@ Insert 18333fig0527.png
 	$ ls *.tar.gz
 	v1.6.2-rc1-20-g8c5b85c.tar.gz
 
-這個壓縮包解壓出來的是一個資料夾，裡面是你項目的最新代碼快照。你也可以用類似的方法建立一個zip壓縮包，在`git archive`加上`--format=zip`選項：
+這個壓縮包解壓出來的是一個資料夾，裡面是你專案的最新代碼快照。你也可以用類似的方法建立一個zip壓縮包，在`git archive`加上`--format=zip`選項：
 
 	$ git archive master --prefix='project/' --format=zip > `git describe master`.zip
 
@@ -888,7 +888,7 @@ Insert 18333fig0527.png
 
 ### 製作簡報 ###
 
-是時候通知郵寄清單裡的朋友們來檢驗你的成果了。使用`git shortlog`命令可以方便快捷的製作一份修改日誌（changelog），告訴大家上次發佈之後又增加了哪些特性和修復了哪些bug。實際上這個命令能夠統計給定範圍內的所有提交;假如你上一次發佈的版本是v1.0.1，下面的命令將給出自從上次發佈之後的所有提交的簡介：
+是時候通知郵寄清單裡的朋友們來檢驗你的成果了。使用`git shortlog`命令可以方便快速的製作一份修改日誌（changelog），告訴大家上次發佈之後又增加了哪些特性和修復了哪些bug。實際上這個命令能夠統計給定範圍內的所有提交;假如你上一次發佈的版本是v1.0.1，下面的命令將給出自從上次發佈之後的所有提交的簡介：
 
 	$ git shortlog --no-merges master --not v1.0.1
 	Chris Wanstrath (8):
diff --git a/zh-tw/06-git-tools/01-chapter6.markdown b/zh-tw/06-git-tools/01-chapter6.markdown
index d45286922..619645ad7 100644
--- a/zh-tw/06-git-tools/01-chapter6.markdown
+++ b/zh-tw/06-git-tools/01-chapter6.markdown
@@ -6,15 +6,15 @@
 
 ## 選擇修訂版本 ##
 
-Git 允許你通過幾種方法來指明特定的或者一定範圍內的提交。瞭解它們並不是必需的，但是瞭解一下總沒壞處。 
+Git 允許你通過幾種方法來指定特定的或者一定範圍內的提交。瞭解它們並不是必需的，但是瞭解一下總沒壞處。 
 
 ### 單個修訂版本 ###
 
-顯然你可以使用給出的 SHA-1 值來指明一次提交，不過也有更加人性化的方法來做同樣的事。本節概述了指明單個提交的諸多方法。 
+顯然你可以使用給出的 SHA-1 值來指定一次提交，不過也有更加人性化的方法來做同樣的事。本節概述了指定單個提交的諸多方法。 
 
 ### 簡短的 SHA ###
 
-Git 很聰明，它能夠通過你提供的前幾個字元來識別你想要的那次提交，只要你提供的那部分 SHA-1 不短於四個字元，並且沒有歧義——也就是說，當前倉庫中只有一個物件以這段 SHA-1 開頭。 
+Git 很聰明，它能夠通過你提供的前幾個字元來識別你想要的那次提交，只要你提供的那部分 SHA-1 不短於四個字元，並且沒有歧義——也就是說，目前倉庫中只有一個物件以這段 SHA-1 開頭。 
 
 例如，想要查看一次指定的提交，假設你執行 `git log` 命令並找到你增加了功能的那次提交： 
 
@@ -51,7 +51,7 @@ Git 可以為你的 SHA-1 值生成出簡短且唯一的縮寫。如果你傳遞
 	085bb3b removed unnecessary test code
 	a11bef0 first commit
 
-通常在一個專案中，使用八到十個字元來避免 SHA-1 歧義已經足夠了。最大的 Git 專案之一，Linux 內核，目前也只需要最長 40 個字元中的 12 個字元來保持唯一性。 
+通常在一個專案中，使用八到十個字元來避免 SHA-1 歧義已經足夠了。最大的 Git 專案之一，Linux 核心，目前也只需要最長 40 個字元中的 12 個字元來保持唯一性。 
 
 ### 關於 SHA-1 的簡短說明 ###
 
@@ -61,16 +61,16 @@ Git 可以為你的 SHA-1 值生成出簡短且唯一的縮寫。如果你傳遞
 
 不過，你應該瞭解到，這種情況發生的概率是多麼微小。SHA-1 摘要長度是 20 位元組，也就是 160 位元。為了保證有 50% 的概率出現一次衝突，需要 2^80 個隨機雜湊的物件（計算衝突機率的公式是 p = (n(n-1)/2) * (1/2^160))。2^80 是 1.2 x 10^24，也就是一億億億，那是地球上沙粒總數的 1200 倍。 
 
-現在舉例說一下怎樣才能產生一次 SHA-1 衝突。如果地球上 65 億的人類都在程式設計，每人每秒都在產生相當於整個 Linux 內核歷史（一百萬個 Git 物件）的代碼，並將之提交到一個巨大的 Git 倉庫裡面，那將花費 5 年的時間才會產生足夠的物件，使其擁有 50% 的概率產生一次 SHA-1 物件衝突。這要比你程式設計團隊的成員同一個晚上在互不相干的意外中被狼襲擊並殺死的機率還要小。 
+現在舉例說一下怎樣才能產生一次 SHA-1 衝突。如果地球上 65 億的人類都在程式設計，每人每秒都在產生相當於整個 Linux 核心歷史（一百萬個 Git 物件）的代碼，並將之提交到一個巨大的 Git 倉庫裡面，那將花費 5 年的時間才會產生足夠的物件，使其擁有 50% 的概率產生一次 SHA-1 物件衝突。這要比你程式設計團隊的成員同一個晚上在互不相干的意外中被狼襲擊並殺死的機率還要小。 
 
 ### 分支引用 (Branch References) ###
 
-指明一次提交的最直接的方法是有一個指向它的分支引用。這樣，你就可以在任何需要一個提交物件或者 SHA-1 值的 Git 命令中使用該分支名稱了。如果你想要顯示一個分支的最後一次提交的物件，例如假設 topic1 分支指向 ca82a6d，那麼下面的命令是相等的： 
+指定一次提交的最直接的方法是有一個指向它的分支引用。這樣，你就可以在任何需要一個提交物件或者 SHA-1 值的 Git 命令中使用該分支名稱了。如果你想要顯示一個分支的最後一次提交的物件，例如假設 topic1 分支指向 ca82a6d，那麼下面的命令是相等的： 
 
 	$ git show ca82a6dff817ec66f44342007202690a93763949
 	$ git show topic1
 
-如果你想知道某個分支指向哪個特定的 SHA，或者想看任何一個例子中被簡寫的 SHA-1，你可以使用一個叫做 `rev-parse` 的 Git plumbing 工具。在第 9 章你可以看到關於 plumbing 工具的更多信息；簡單來說，`rev-parse` 是為了底層操作而不是日常操作設計的。不過，有時你想看 Git 現在到底處於什麼狀態時，它可能會很有用。現在，你可以對你的分支執行 `rev-parse`：
+如果你想知道某個分支指向哪個特定的 SHA，或者想看任何一個例子中被簡寫的 SHA-1，你可以使用一個叫做 `rev-parse` 的 Git plumbing 工具。在第 9 章你可以看到關於 plumbing 工具的更多資訊；簡單來說，`rev-parse` 是為了底層操作而不是日常操作設計的。不過，有時你想看 Git 現在到底處於什麼狀態時，它可能會很有用。現在，你可以對你的分支執行 `rev-parse`：
 
 	$ git rev-parse topic1
 	ca82a6dff817ec66f44342007202690a93763949
@@ -90,7 +90,7 @@ Git 可以為你的 SHA-1 值生成出簡短且唯一的縮寫。如果你傳遞
 	1c36188 HEAD@{5}: rebase -i (squash): updating HEAD
 	7e05da5 HEAD@{6}: rebase -i (pick): updating HEAD
 
-每次你的分支頂端因為某些原因被修改時，Git 就會為你將資訊保存在這個臨時歷史記錄裡面。你也可以使用這份資料來指明更早的分支。如果你想查看倉庫中 HEAD 在五次前的值，你可以使用引用日誌的輸出中的 @{n} 引用： 
+每次你的分支頂端因為某些原因被修改時，Git 就會為你將資訊保存在這個臨時歷史記錄裡面。你也可以使用這份資料來指定更早的分支。如果你想查看倉庫中 HEAD 在五次前的值，你可以使用引用日誌的輸出中的 @{n} 引用： 
 
 	$ git show HEAD@{5}
 
@@ -123,7 +123,7 @@ Git 可以為你的 SHA-1 值生成出簡短且唯一的縮寫。如果你傳遞
 
 ### 祖先引用 (Ancestry References) ###
 
-另一種指明某次提交的常用方法是通過它的祖先。如果你在引用最後加上一個 `^`，Git 將其理解為此次提交的父提交。 假設你的專案歷史是這樣的：
+另一種指定某次提交的常用方法是通過它的祖先。如果你在引用最後加上一個 `^`，Git 將其理解為此次提交的父提交。 假設你的專案歷史是這樣的：
 
 	$ git log --pretty=format:'%h %s' --graph
 	* 734713b fixed refs handling, added gc auto, updated tests
@@ -145,7 +145,7 @@ Git 可以為你的 SHA-1 值生成出簡短且唯一的縮寫。如果你傳遞
 
 	    Merge commit 'phedders/rdocs'
 
-你也可以在 `^` 後添加一個數字——例如，`d921970^2` 意思是「d921970 的第二父提交」。這種語法只在合併提交時有用，因為合併提交可能有多個父提交。第一父提交是你合併時所在分支，而第二父提交是你所合併進來的分支： 
+你也可以在 `^` 後增加一個數字——例如，`d921970^2` 意思是「d921970 的第二父提交」。這種語法只在合併提交時有用，因為合併提交可能有多個父提交。第一父提交是你合併時所在分支，而第二父提交是你所合併進來的分支： 
 
 	$ git show d921970^
 	commit 1c002dd4b536e7479fe34593e72e6c6c1819e53b
@@ -161,7 +161,7 @@ Git 可以為你的 SHA-1 值生成出簡短且唯一的縮寫。如果你傳遞
 
 	    Some rdoc changes
 
-另外一個指明祖先提交的方法是 `~`。這也是指向第一父提交，所以 `HEAD~` 和 `HEAD^` 是相等的。當你指定數字的時候就明顯不一樣了。`HEAD~2` 是指「第一父提交的第一父提交」，也就是「祖父提交」——它會根據你指定的次數檢索第一父提交。例如，在上面列出的歷史記錄裡面，`HEAD~3` 會是 
+另外一個指定祖先提交的方法是 `~`。這也是指向第一父提交，所以 `HEAD~` 和 `HEAD^` 是相等的。當你指定數字的時候就明顯不一樣了。`HEAD~2` 是指「第一父提交的第一父提交」，也就是「祖父提交」——它會根據你指定的次數檢索第一父提交。例如，在上面列出的歷史記錄裡面，`HEAD~3` 會是 
 
 	$ git show HEAD~3
 	commit 1c3618887afb5fbcbea25b7c013f4e2114448b8d
@@ -179,15 +179,15 @@ Git 可以為你的 SHA-1 值生成出簡短且唯一的縮寫。如果你傳遞
 
 	    ignore *.gem
 
-你也可以混合使用這些語法——你可以通過 `HEAD~3^2` 指明先前引用的第二父提交（假設它是一個合併提交），依此類推。 
+你也可以混合使用這些語法——你可以通過 `HEAD~3^2` 指定先前引用的第二父提交（假設它是一個合併提交），依此類推。 
 
 ### 提交範圍 ###
 
-現在你已經可以指明單次的提交，讓我們來看看怎樣指明一定範圍的提交。這在你管理分支的時候尤顯重要——如果你有很多分支，你可以指明範圍來圈定一些問題的答案，比如：「這個分支上我有哪些工作還沒合併到主分支的？」 
+現在你已經可以指定單次的提交，讓我們來看看怎樣指定一定範圍的提交。這在你管理分支的時候尤顯重要——如果你有很多分支，你可以指定範圍來圈定一些問題的答案，比如：「這個分支上我有哪些工作還沒合併到主分支的？」 
 
 #### 雙點 ####
 
-最常用的指明範圍的方法是雙點的語法。這種語法主要是讓 Git 區分出可從一個分支中獲得而不能從另一個分支中獲得的提交。例如，假設你有類似於圖 6-1 的提交歷史。 
+最常用的指定範圍的方法是雙點的語法。這種語法主要是讓 Git 區分出可從一個分支中獲得而不能從另一個分支中獲得的提交。例如，假設你有類似於圖 6-1 的提交歷史。 
 
 Insert 18333fig0601.png
 Figure 6-1. 範圍選擇的提交歷史實例
@@ -208,12 +208,12 @@ Figure 6-1. 範圍選擇的提交歷史實例
 
 	$ git log origin/master..HEAD
 
-這條命令顯示任何在你當前分支上而不在遠端 `origin` 上的 `master` 分支上的提交。如果你執行 `git push` 並且你的當前分支正在追蹤 `origin/master`，被 `git log origin/master..HEAD` 列出的提交就是將被傳輸到伺服器上的提交。
+這條命令顯示任何在你目前分支上而不在遠端 `origin` 上的 `master` 分支上的提交。如果你執行 `git push` 並且你的目前分支正在追蹤 `origin/master`，被 `git log origin/master..HEAD` 列出的提交就是將被傳輸到伺服器上的提交。
 你也可以省略語法中的一邊讓 Git 來假定它是 HEAD。例如，輸入 git log origin/master.. 將得到和上面的例子一樣的結果—— Git 使用 HEAD 來代替不存在的一邊。
 
 #### 多點 ####
 
-雙點語法就像速記一樣有用；但是你也許會想針對兩個以上的分支來指明修訂版本，比如查看哪些提交被包含在某些分支中的一個，但是不在你當前的分支上。Git 允許你在引用前使用 `^` 字元或者 `--not` 指明你不希望提交被包含其中的分支。因此下面三個命令是等同的： 
+雙點語法就像速記一樣有用；但是你也許會想針對兩個以上的分支來指定修訂版本，比如查看哪些提交被包含在某些分支中的一個，但是不在你目前的分支上。Git 允許你在引用前使用 `^` 字元或者 `--not` 指定你不希望提交被包含其中的分支。因此下面三個命令是等同的： 
 
 	$ git log refA..refB
 	$ git log ^refA refB
@@ -356,9 +356,9 @@ Git 提供了很多腳本來輔助某些命令列任務。這裡，你將看到
 
 通過這些基本命令，你可以使用互動式增加模式更加方便地處理暫存區。 
 
-### 暫存補丁 (Staging Patches) ###
+### 暫存修補檔 (Staging Patches) ###
 
-只讓 Git 將檔案的某些部分暫存，而忽略其他部份也是有可能的。例如，你對 simplegit.rb 檔作了兩處修改但是只想暫存其中一個而忽略另一個，在 Git 中實現這一點非常容易。在互動式的提示符下，輸入 `5` 或者 `p`（表示 patch，補丁）。Git 會詢問哪些檔你希望部分暫存；然後對於被選中檔案的每一節，他會逐個顯示檔案的差異區塊並詢問你是否希望暫存他們： 
+只讓 Git 將檔案的某些部分暫存，而忽略其他部份也是有可能的。例如，你對 simplegit.rb 檔作了兩處修改但是只想暫存其中一個而忽略另一個，在 Git 中實現這一點非常容易。在互動式的提示符下，輸入 `5` 或者 `p`（表示 patch，修補檔）。Git 會詢問哪些檔你希望部分暫存；然後對於被選中檔案的每一節，他會逐個顯示檔案的差異區塊並詢問你是否希望暫存他們： 
 
 	diff --git a/lib/simplegit.rb b/lib/simplegit.rb
 	index dd5ecc4..57399e0 100644
@@ -400,7 +400,7 @@ Git 提供了很多腳本來輔助某些命令列任務。這裡，你將看到
 	  2:        +1/-1      nothing index.html
 	  3:        +1/-1        +4/-0 lib/simplegit.rb
 
-simplegit.rb 的狀態非常有意思。它顯示有幾行被暫存了，有幾行沒有。你部分地暫存了這個檔。這時候，你可以退出互動式腳本然後執行 `git commit` 來提交部分暫存的檔。 
+simplegit.rb 的狀態非常有意思。它顯示有幾行被暫存了，有幾行沒有。你部分地暫存了這個檔案。這時候，你可以退出互動式腳本然後執行 `git commit` 來提交部分暫存的檔案。 
 
 最後，你也可以不通過互動式增加的模式來實現檔案部分暫存——你可以在命令列下使用 `git add -p` 或者 `git add --patch` 來啟動同樣的腳本。 
 
@@ -408,7 +408,7 @@ simplegit.rb 的狀態非常有意思。它顯示有幾行被暫存了，有幾
 
 經常有這樣的事情發生，當你正在進行專案中某一部分的工作，裡面的東西處於一個比較雜亂的狀態，而你想轉到其他分支上進行一些工作。問題是，你不想只為了待會要回到這個工作點，就把做到一半的工作進行提交。解決這個問題的辦法就是 `git stash` 命令。 
 
-「儲藏」可以獲取你工作目錄的 dirty state——也就是你修改過的被追蹤檔和暫存的變更——並將它保存到一個未完成變更的堆疊(stack)中，隨時可以重新應用。 
+「儲藏」可以取得你工作目錄的 dirty state——也就是你修改過的被追蹤檔和暫存的變更——並將它保存到一個未完成變更的堆疊(stack)中，隨時可以重新套用。 
 
 ### 儲藏你的工作 ###
 
@@ -448,7 +448,7 @@ simplegit.rb 的狀態非常有意思。它顯示有幾行被暫存了，有幾
 	stash@{1}: WIP on master: c264051 Revert "added file_size"
 	stash@{2}: WIP on master: 21d80a5 added number to log
 
-在這個案例中，之前已經進行了兩次儲藏，所以你可以取得三個不同的儲藏。你可以重新應用你剛剛的儲藏，所採用的命令就是原本 stash 命令輸出的輔助訊息裡提示的：`git stash apply`。如果你想應用較舊的儲藏，你可以通過名字指定它，像這樣：`git stash apply stash@{2}`。如果你不指明，Git 預設使用最近的儲藏並嘗試應用它： 
+在這個案例中，之前已經進行了兩次儲藏，所以你可以取得三個不同的儲藏。你可以重新套用你剛剛的儲藏，所採用的命令就是原本 stash 命令輸出的輔助訊息裡提示的：`git stash apply`。如果你想應用較舊的儲藏，你可以通過名字指定它，像這樣：`git stash apply stash@{2}`。如果你不指定，Git 預設使用最近的儲藏並嘗試應用它： 
 
 	$ git stash apply
 	# On branch master
@@ -459,9 +459,9 @@ simplegit.rb 的狀態非常有意思。它顯示有幾行被暫存了，有幾
 	#      modified:   lib/simplegit.rb
 	#
 
-你可以看到 Git 重新修改了你所儲藏的那些當時尚未提交的檔。在這個案例裡，你嘗試應用儲藏的工作目錄是乾淨的，並且屬於同一分支；但是一個乾淨的工作目錄和應用到相同的分支上並不是應用儲藏的必要條件。你可以在其中一個分支上保留一份儲藏，隨後切換到另外一個分支，再重新應用這些變更。在工作目錄裡包含已修改、未提交的檔時，你也可以應用儲藏——Git 會給出合併衝突，如果有任何變更無法乾淨地被應用。 
+你可以看到 Git 重新修改了你所儲藏的那些當時尚未提交的檔案。在這個案例裡，你嘗試應用儲藏的工作目錄是乾淨的，並且屬於同一分支；但是一個乾淨的工作目錄和套用到相同的分支上並不是應用儲藏的必要條件。你可以在其中一個分支上保留一份儲藏，隨後切換到另外一個分支，再重新套用這些變更。在工作目錄裡包含已修改、未提交的檔時，你也可以應用儲藏——Git 會給出合併衝突，如果有任何變更無法乾淨地被應用。 
 
-對檔案的變更被重新應用，但是被暫存的檔沒有重新被暫存。想那樣的話，你必須在執行 `git stash apply` 命令時帶上一個 `--index` 的選項來重新應用被暫存的變更。如果你是這麼做的，你應該已經回到你原來的位置：
+對檔案的變更被重新套用，但是被暫存的檔沒有重新被暫存。想那樣的話，你必須在執行 `git stash apply` 命令時帶上一個 `--index` 的選項來重新套用被暫存的變更。如果你是這麼做的，你應該已經回到你原來的位置：
 
 	$ git stash apply --index
 	# On branch master
@@ -485,11 +485,11 @@ apply 選項只嘗試應用儲藏的工作——儲藏的內容仍然在堆疊
 	$ git stash drop stash@{0}
 	Dropped stash@{0} (364e91f3f268f0900bc3ee613f9f733e82aaed43)
 
-你也可以執行 `git stash pop` 來重新應用儲藏，同時立刻將其從堆疊中移走。 
+你也可以執行 `git stash pop` 來重新套用儲藏，同時立刻將其從堆疊中移走。 
 
 ### 取消儲藏 (Un-applying a Stash) ###
 
-在某些使用情境下，你可能想要應用儲藏的變更，做一些工作，然後又要把來自原儲藏的變更取消。Git 並未提供類似 `stash unapply` 的命令，但是達成相同效果是可能的，只要取得該儲藏關連的補丁然後反向應用它就行了：
+在某些使用情境下，你可能想要應用儲藏的變更，做一些工作，然後又要把來自原儲藏的變更取消。Git 並未提供類似 `stash unapply` 的命令，但是達成相同效果是可能的，只要取得該儲藏關連的修補檔然後反向應用它就行了：
 
     $ git stash show -p stash@{0} | git apply -R
 
@@ -504,9 +504,9 @@ apply 選項只嘗試應用儲藏的工作——儲藏的內容仍然在堆疊
     $ #... work work work
     $ git stash-unapply
 
-### 從儲藏中創建分支 ###
+### 從儲藏中建立分支 ###
 
-如果你儲藏了一些工作，暫時不去理會，然後繼續在你儲藏工作的分支上工作，你在重新應用工作時可能會碰到一些問題。如果嘗試應用的變更是針對一個你那之後修改過的檔，你會碰到一個合併衝突並且必須去化解它。如果你想用更方便的方法來重新檢驗你儲藏的變更，你可以執行 `git stash branch`，這會創建一個新的分支，檢出你儲藏工作時所處的提交，重新應用你的工作，如果成功，將會丟棄儲藏。 
+如果你儲藏了一些工作，暫時不去理會，然後繼續在你儲藏工作的分支上工作，你在重新套用工作時可能會碰到一些問題。如果嘗試應用的變更是針對一個你那之後修改過的檔，你會碰到一個合併衝突並且必須去化解它。如果你想用更方便的方法來重新檢驗你儲藏的變更，你可以執行 `git stash branch`，這會建立一個新的分支，檢出你儲藏工作時所處的提交，重新套用你的工作，如果成功，將會丟棄儲藏。 
 
 	$ git stash branch testchanges
 	Switched to a new branch "testchanges"
@@ -541,15 +541,15 @@ apply 選項只嘗試應用儲藏的工作——儲藏的內容仍然在堆疊
 
 這會把你帶入文字編輯器，裡面包含了你最近一次提交的說明訊息，供你修改。當你保存並退出編輯器，這個編輯器會寫入一個新的提交，裡面包含了那個說明，並且讓它成為你的新的最後提交。
 
-如果你完成提交後又想修改被提交的快照，增加或者修改其中的檔案，可能因為你最初提交時，忘了添加一個新建的檔，這個過程基本上一樣。你通過修改檔案然後對其執行 `git add` 或對一個已被記錄的檔執行 `git rm`，隨後的 `git commit --amend` 會獲取你當前的暫存區並將它作為新提交對應的快照。 
+如果你完成提交後又想修改被提交的快照，增加或者修改其中的檔案，可能因為你最初提交時，忘了增加一個新增的檔，這個過程基本上一樣。你通過修改檔案然後對其執行 `git add` 或對一個已被記錄的檔執行 `git rm`，隨後的 `git commit --amend` 會取得你目前的暫存區並將它作為新提交對應的快照。 
 
 使用這項技術的時候你必須小心，因為修正會改變提交的SHA-1值。這個很像是一次非常小的 rebase——不要在你最近一次提交被推送後還去修正它。 
 
 ### 修改多個提交訊息 ###
 
-要修改歷史中更早的提交，你必須採用更複雜的工具。Git 沒有一個修改歷史的工具，但是你可以使用 rebase 工具來衍合一系列的提交到它們原來所在的 HEAD 上而不是移到新的上。依靠這個互動式的 rebase 工具，你就可以停留在每一次提交後，如果你想修改或改變說明、增加檔案或做任何事情。在 `git rebase` 增加 `-i` 選項可以對話模式執行 rebase。你必須告訴 rebase 命令要衍合到哪次提交，來指明你想要重寫的提交要回溯到多遠。 
+要修改歷史中更早的提交，你必須採用更複雜的工具。Git 沒有一個修改歷史的工具，但是你可以使用 rebase 工具來衍合一系列的提交到它們原來所在的 HEAD 上而不是移到新的上。依靠這個互動式的 rebase 工具，你就可以停留在每一次提交後，如果你想修改或改變說明、增加檔案或做任何事情。在 `git rebase` 增加 `-i` 選項可以對話模式執行 rebase。你必須告訴 rebase 命令要衍合到哪次提交，來指定你想要重寫的提交要回溯到多遠。 
 
-例如，你想修改最近三次的提交說明，或者其中任意一次，你必須給 `git rebase -i` 提供一個參數，指明你想要修改的提交的父提交，例如 `HEAD~2^` 或者 `HEAD~3`。可能記住 `~3` 更加容易，因為你想修改最近三次提交；但是請記住你事實上所指的是四次提交之前，即你想修改的提交的父提交。
+例如，你想修改最近三次的提交說明，或者其中任意一次，你必須給 `git rebase -i` 提供一個參數，指定你想要修改的提交的父提交，例如 `HEAD~2^` 或者 `HEAD~3`。可能記住 `~3` 更加容易，因為你想修改最近三次提交；但是請記住你事實上所指的是四次提交之前，即你想修改的提交的父提交。
 
 	$ git rebase -i HEAD~3
 
@@ -586,7 +586,7 @@ apply 選項只嘗試應用儲藏的工作——儲藏的內容仍然在堆疊
 	310154e updated README formatting and added blame
 	f7f3f6d changed my name a bit
 
-請注意這裡的順序是相反的。互動式的 rebase 給了你一個即將執行的腳本。它會從你在命令列上指明的提交開始(`HEAD~3`)然後自上至下重播每次提交裡引入的變更。它將最早的列在頂上而不是最近的，因為這是第一個需要重播的。 
+請注意這裡的順序是相反的。互動式的 rebase 給了你一個即將執行的腳本。它會從你在命令列上指定的提交開始(`HEAD~3`)然後自上至下重播每次提交裡引入的變更。它將最早的列在頂上而不是最近的，因為這是第一個需要重播的。 
 
 你需要修改這個腳本來讓它停留在你想修改的變更上。要做到這一點，你只要將你想修改的每一次提交前面的 pick 改為 edit。例如，只想修改第三次提交說明的話，你就像下面這樣修改文件：
 
@@ -658,7 +658,7 @@ apply 選項只嘗試應用儲藏的工作——儲藏的內容仍然在堆疊
 	squash 310154e updated README formatting and added blame
 	squash a5f4a0d added cat-file
 
-當你儲存並退出編輯器，Git 會應用全部三次變更然後將你送回編輯器來歸併三次提交說明。 
+當你保存並退出編輯器，Git 會應用全部三次變更然後將你送回編輯器來歸併三次提交說明。 
 
 	# This is a combination of 3 commits.
 	# The first commit's message is:
@@ -672,7 +672,7 @@ apply 選項只嘗試應用儲藏的工作——儲藏的內容仍然在堆疊
 
 	added cat-file
 
-當你儲存之後，你就擁有了一個包含前三次提交的全部變更的單一提交。 
+當你保存之後，你就擁有了一個包含前三次提交的全部變更的單一提交。 
 
 ### 拆分(Splitting) 提交 ###
 
@@ -682,7 +682,7 @@ apply 選項只嘗試應用儲藏的工作——儲藏的內容仍然在堆疊
 	edit 310154e updated README formatting and added blame
 	pick a5f4a0d added cat-file
 
-然後，這個腳本就將你帶入命令列，你重置那次提交，提取被重置的變更，從中創建多次提交。當你儲存並退出編輯器，Git 倒回到列表中第一次提交的父提交，應用第一次提交（`f7f3f6d`），應用第二次提交（`310154e`），然後將你帶到控制台。那裡你可以用 `git reset HEAD^` 對那次提交進行一次混合的重置，這將撤銷那次提交並且將修改的檔從暫存區撤回。此時你可以暫存並提交檔案，直到你擁有多次提交，結束後，執行 `git rebase --continue`。 
+然後，這個腳本就將你帶入命令列，你重置那次提交，提取被重置的變更，從中建立多次提交。當你保存並退出編輯器，Git 倒回到列表中第一次提交的父提交，應用第一次提交（`f7f3f6d`），應用第二次提交（`310154e`），然後將你帶到控制台。那裡你可以用 `git reset HEAD^` 對那次提交進行一次混合的重置，這將撤銷那次提交並且將修改的檔從暫存區撤回。此時你可以暫存並提交檔案，直到你擁有多次提交，結束後，執行 `git rebase --continue`。 
 
 	$ git reset HEAD^
 	$ git add README
@@ -715,9 +715,9 @@ Git 在腳本中應用了最後一次提交（`a5f4a0d`），你的歷史看起
 
 `--tree-filter` 選項會在每次 checkout 專案時先執行指定的命令然後重新提交結果。在這個例子中，你會在所有快照中刪除一個名叫 password.txt 的檔，無論它是否存在。如果你想刪除所有不小心提交上去的編輯器備份檔案，你可以執行類似 `git filter-branch --tree-filter "find * -type f -name '*~' -delete" HEAD` 的命令。 
 
-你可以觀察到 Git 重寫目錄樹並且提交，然後將分支指標移到末尾。一個比較好的辦法是在一個測試分支上做這件事，然後在你確定結果真的是你所要的之後，再 hard-reset 你的主分支。要在你所有的分支上運行 `filter-branch` 的話，你可以傳遞一個 `--all` 參數給該命令。 
+你可以觀察到 Git 重寫目錄樹並且提交，然後將分支指標移到末尾。一個比較好的辦法是在一個測試分支上做這件事，然後在你確定結果真的是你所要的之後，再 hard-reset 你的主分支。要在你所有的分支上執行 `filter-branch` 的話，你可以傳遞一個 `--all` 參數給該命令。 
 
-#### 將一個子目錄設置為新的根目錄 ####
+#### 將一個子目錄設定為新的根目錄 ####
 
 假設你完成了從另外一個代碼控制系統的導入工作，得到了一些沒有意義的子目錄（trunk, tags 等等）。如果你想讓 trunk 子目錄成為每一次提交的新的專案根目錄，`filter-branch` 也可以幫你做到： 
 
@@ -729,7 +729,7 @@ Git 在腳本中應用了最後一次提交（`a5f4a0d`），你的歷史看起
 
 #### 全域性地更換電子郵寄地址 ####
 
-另一個常見的案例是你在開始時忘了執行 `git config` 來設置你的姓名和電子郵寄地址，也許你想開源一個專案，把你所有的工作電子郵寄地址修改為個人位址。無論哪種情況你都可以用 `filter-branch` 來更換多次提交裡的電子郵寄地址。你必須小心一些，只改變屬於你的電子郵寄地址，所以你使用 `--commit-filter`： 
+另一個常見的案例是你在開始時忘了執行 `git config` 來設定你的姓名和電子郵寄地址，也許你想開源一個專案，把你所有的工作電子郵寄地址修改為個人位址。無論哪種情況你都可以用 `filter-branch` 來更換多次提交裡的電子郵寄地址。你必須小心一些，只改變屬於你的電子郵寄地址，所以你使用 `--commit-filter`： 
 
 	$ git filter-branch --commit-filter '
 	        if [ "$GIT_AUTHOR_EMAIL" = "schacon@localhost" ];
@@ -789,7 +789,7 @@ Git 也提供了一些工具來幫助你 debug 專案中遇到的問題。由於
 
 當你知道問題在哪裡的時候，標注檔案會有幫助。如果你不知道，並且自從上次程式碼可用的狀態之後已經經歷了上百次的提交，你可能就要求助於 `git bisect` 命令了。`bisect` 會在你的提交歷史中進行二分查找，來儘快地確定哪一次提交引入了錯誤。 
 
-例如你剛剛推送了一個代碼發佈版本到產品環境中，得到一些在你開發環境中沒有發生的錯誤報告，而你對代碼為什麼會表現成那樣百思不得其解。你回到你的代碼中，還好你可以重現那個錯誤，但是找不到問題在哪裡。你可以對代碼執行 `bisect` 來尋找。首先你執行 `git bisect start` 啟動，然後你用 `git bisect bad` 來告訴系統當前的提交已經有問題了。然後你必須告訴 bisect 已知的最後一次正常狀態是哪次提交，使用 `git bisect good [good_commit]`： 
+例如你剛剛推送了一個代碼發佈版本到產品環境中，得到一些在你開發環境中沒有發生的錯誤報告，而你對代碼為什麼會表現成那樣百思不得其解。你回到你的代碼中，還好你可以重現那個錯誤，但是找不到問題在哪裡。你可以對代碼執行 `bisect` 來尋找。首先你執行 `git bisect start` 啟動，然後你用 `git bisect bad` 來告訴系統目前的提交已經有問題了。然後你必須告訴 bisect 已知的最後一次正常狀態是哪次提交，使用 `git bisect good [good_commit]`： 
 
 	$ git bisect start
 	$ git bisect bad
@@ -797,7 +797,7 @@ Git 也提供了一些工具來幫助你 debug 專案中遇到的問題。由於
 	Bisecting: 6 revisions left to test after this
 	[ecb6e1bc347ccecc5f9350d878ce677feb13d3b2] error handling on repo
 
-Git 發現在你標記為正常的提交(v1.0)和當前的錯誤版本之間有大約12次提交，於是它 check out 中間的一個。在這裡，你可以進行測試，檢查問題是否存在於這次提交。如果是，那麼它是在這個中間提交之前的某一次引入的；如果否，那麼問題是在中間提交之後引入的。假設這裡是沒有錯誤的，那麼你就通過 `git bisect good` 來告訴 Git 然後繼續你的旅程：
+Git 發現在你標記為正常的提交(v1.0)和目前的錯誤版本之間有大約12次提交，於是它 check out 中間的一個。在這裡，你可以進行測試，檢查問題是否存在於這次提交。如果是，那麼它是在這個中間提交之前的某一次引入的；如果否，那麼問題是在中間提交之後引入的。假設這裡是沒有錯誤的，那麼你就通過 `git bisect good` 來告訴 Git 然後繼續你的旅程：
 
 	$ git bisect good
 	Bisecting: 3 revisions left to test after this
@@ -853,7 +853,7 @@ Git 通過子模組處理這個問題。子模組允許你將一個 Git 倉庫
 	Receiving objects: 100% (3181/3181), 675.42 KiB | 422 KiB/s, done.
 	Resolving deltas: 100% (1951/1951), done.
 
-現在你就在專案裡的 `rack` 子目錄下有了一個 Rack 專案。你可以進入那個子目錄，進行變更，加入你自己的遠端可寫倉庫來推送你的變更，從原始倉庫拉取(pull)和歸併等等。如果你在加入子模組後立刻運行 `git status`，你會看到下面兩項： 
+現在你就在專案裡的 `rack` 子目錄下有了一個 Rack 專案。你可以進入那個子目錄，進行變更，加入你自己的遠端可寫倉庫來推送你的變更，從原始倉庫拉取(pull)和歸併等等。如果你在加入子模組後立刻執行 `git status`，你會看到下面兩項： 
 
 	$ git status
 	# On branch master
@@ -884,9 +884,9 @@ Git 通過子模組處理這個問題。子模組允許你將一個 Git 倉庫
 	@@ -0,0 +1 @@
 	+Subproject commit 08d709f78b8c5b0fbeb7821e37fa53e69afcf433
 
-儘管 rack 是你工作目錄裡的子目錄，但 Git 把它視作一個子模組，當你不在那個目錄裡的時候，Git 並不會追蹤記錄它的內容。取而代之的是，Git 將它記錄成來自那個倉庫的一個特殊的提交。當你在那個子目錄裡修改並提交時，子專案會通知那裡的 HEAD 已經發生變更並記錄你當前正在工作的那個提交；通過那樣的方法，當其他人 clone 此專案，他們可以重新創建一致的環境。 
+儘管 rack 是你工作目錄裡的子目錄，但 Git 把它視作一個子模組，當你不在那個目錄裡的時候，Git 並不會追蹤記錄它的內容。取而代之的是，Git 將它記錄成來自那個倉庫的一個特殊的提交。當你在那個子目錄裡修改並提交時，子專案會通知那裡的 HEAD 已經發生變更並記錄你目前正在工作的那個提交；通過那樣的方法，當其他人 clone 此專案，他們可以重新建立一致的環境。 
 
-這是關於子模組的重要一點：你記錄他們當前確切所處的提交。你不能記錄一個子模組的 `master` 或者其他的符號引用(symbolic reference)。 
+這是關於子模組的重要一點：你記錄他們目前確切所處的提交。你不能記錄一個子模組的 `master` 或者其他的符號引用(symbolic reference)。 
 
 當你提交時，會看到類似如下： 
 
@@ -898,7 +898,7 @@ Git 通過子模組處理這個問題。子模組允許你將一個 Git 倉庫
 
 注意 rack 條目的 160000 模式。這在 Git 中是一個特殊模式，基本意思是你將一個提交記錄為一個目錄項而不是子目錄或者檔案。 
 
-你可以將 `rack` 目錄當作一個獨立的專案，保持一個指向子目錄的最新提交的指標然後反復地更新上層專案。所有的 Git 命令都在兩個子目錄裡獨立工作： 
+你可以將 `rack` 目錄當作一個獨立的專案，保持一個指向子目錄的最新提交的指標然後反覆地更新上層專案。所有的 Git 命令都在兩個子目錄裡獨立工作： 
 
 	$ git log -1
 	commit 0550271328a0038865aad6331e620cd7238601bb
@@ -972,7 +972,7 @@ Git 通過子模組處理這個問題。子模組允許你將一個 Git 倉庫
 	-Subproject commit 6c5e70b984a60b3cecd395edd5b48a7575bf58e0
 	+Subproject commit 08d709f78b8c5b0fbeb7821e37fa53e69afcf433
 
-事情就是這樣，因為你所擁有的子模組的指標，並沒有對應到子模組目錄的真實狀態。為了修復這一點，你必須再次運行 `git submodule update`： 
+事情就是這樣，因為你所擁有的子模組的指標，並沒有對應到子模組目錄的真實狀態。為了修復這一點，你必須再次執行 `git submodule update`： 
 
 	$ git submodule update
 	remote: Counting objects: 5, done.
@@ -985,7 +985,7 @@ Git 通過子模組處理這個問題。子模組允許你將一個 Git 倉庫
 
 每次你從主專案中拉取一個子模組的變更都必須這樣做。看起來很怪但是管用。 
 
-一個常見問題是當開發者對子模組做了一個本地的變更但是並沒有推送到公共伺服器。然後他們提交了一個指向那個非公開狀態的指標然後推送上層專案。當其他開發者試圖運行 `git submodule update`，那個子模組系統會找不到所引用的提交，因為它只存在于第一個開發者的系統中。如果發生那種情況，你會看到類似這樣的錯誤： 
+一個常見問題是當開發者對子模組做了一個本地的變更但是並沒有推送到公開伺服器。然後他們提交了一個指向那個非公開狀態的指標然後推送上層專案。當其他開發者試圖執行 `git submodule update`，那個子模組系統會找不到所引用的提交，因為它只存在于第一個開發者的系統中。如果發生那種情況，你會看到類似這樣的錯誤： 
 
 	$ git submodule update
 	fatal: reference isn’t a tree: 6c5e70b984a60b3cecd395edd5b48a7575bf58e0
@@ -1004,17 +1004,17 @@ Git 通過子模組處理這個問題。子模組允許你將一個 Git 倉庫
 
 ### 上層專案 ###
 
-有時候，開發者想按照他們的分組獲取一個大專案的子目錄的子集。如果你是從 CVS 或者 Subversion 遷移過來的話這個很常見，在那些系統中你已經定義了一個模組或者子目錄的集合，而你想延續這種類型的工作流程。
+有時候，開發者想按照他們的分組取得一個大專案的子目錄的子集。如果你是從 CVS 或者 Subversion 遷移過來的話這個很常見，在那些系統中你已經定義了一個模組或者子目錄的集合，而你想延續這種類型的工作流程。
 
-在 Git 中實現這個的一個好辦法是你將每一個子目錄都做成獨立的 Git 倉庫，然後創建一個上層專案的 Git 倉庫包含多個子模組。這個辦法的一個優勢是，你可以在上層專案中通過標籤和分支更為明確地定義專案之間的關係。 
+在 Git 中實現這個的一個好辦法是你將每一個子目錄都做成獨立的 Git 倉庫，然後建立一個上層專案的 Git 倉庫包含多個子模組。這個辦法的一個優勢是，你可以在上層專案中通過標籤和分支更為明確地定義專案之間的關係。 
 
 ### 子模組的問題 ###
 
-使用子模組並非沒有任何缺點。首先，你在子模組目錄中工作時必須相對小心。當你執行 `git submodule update`，它會 check out 專案的指定版本，但是不在分支內。這叫做獲得一個分離的頭(detached head)——這意味著 HEAD 檔直接指向一次提交，而不是一個符號引用(symbolic reference)。問題在於你通常並不想在一個分離的頭的環境下工作，因為太容易丟失變更了。如果你先執行了一次 `submodule update`，然後在那個子模組目錄裡不創建分支就進行提交，然後再次從上層專案裡執行 `git submodule update` 同時不進行提交，Git 會毫無提示地覆蓋你的變更。技術上講你不會丟失工作，但是你將失去指向它的分支，因此會很難取得。 
+使用子模組並非沒有任何缺點。首先，你在子模組目錄中工作時必須相對小心。當你執行 `git submodule update`，它會 check out 專案的指定版本，但是不在分支內。這叫做獲得一個分離的頭(detached head)——這意味著 HEAD 檔直接指向一次提交，而不是一個符號引用(symbolic reference)。問題在於你通常並不想在一個分離的頭的環境下工作，因為太容易丟失變更了。如果你先執行了一次 `submodule update`，然後在那個子模組目錄裡不建立分支就進行提交，然後再次從上層專案裡執行 `git submodule update` 同時不進行提交，Git 會毫無提示地覆蓋你的變更。技術上講你不會丟失工作，但是你將失去指向它的分支，因此會很難取得。 
 
-為了避免這個問題，當你在子模組目錄裡工作時應使用 `git checkout -b work` 或類似的命令來 創建一個分支。當你再次在子模組裡更新的時候，它仍然會覆蓋你的工作，但是至少你擁有一個可以回溯的指標。 
+為了避免這個問題，當你在子模組目錄裡工作時應使用 `git checkout -b work` 或類似的命令來 建立一個分支。當你再次在子模組裡更新的時候，它仍然會覆蓋你的工作，但是至少你擁有一個可以回溯的指標。 
 
-切換帶有子模組的分支同樣也很有技巧。如果你創建一個新的分支，增加了一個子模組，然後切換回不帶該子模組的分支，你仍然會擁有一個未被追蹤的子模組的目錄 ：
+切換帶有子模組的分支同樣也很有技巧。如果你建立一個新的分支，增加了一個子模組，然後切換回不帶該子模組的分支，你仍然會擁有一個未被追蹤的子模組的目錄 ：
 
 	$ git checkout -b rack
 	Switched to a new branch "rack"
@@ -1108,7 +1108,7 @@ Git 通過子模組處理這個問題。子模組允許你將一個 Git 倉庫
 	$ ls
 	README
 
-要將 Rack 專案當作子目錄拉取到你的 `master` 專案中。你可以在 Git 中用 `git read-tree` 來實現。你會在第9章學到更多與 `read-tree` 和它的朋友相關的東西，目前你會知道它讀取一個分支的根目錄樹到當前的暫存區和工作目錄。你只要切換回你的 `master` 分支，然後拉取 `rack_branch` 分支到你主專案的 `master` 分支的 `rack` 子目錄： 
+要將 Rack 專案當作子目錄拉取到你的 `master` 專案中。你可以在 Git 中用 `git read-tree` 來實現。你會在第9章學到更多與 `read-tree` 和它的朋友相關的東西，目前你會知道它讀取一個分支的根目錄樹到目前的暫存區和工作目錄。你只要切換回你的 `master` 分支，然後拉取 `rack_branch` 分支到你主專案的 `master` 分支的 `rack` 子目錄： 
 
 	$ git read-tree --prefix=rack/ -u rack_branch
 
diff --git a/zh-tw/07-customizing-git/01-chapter7.markdown b/zh-tw/07-customizing-git/01-chapter7.markdown
index a5ead4413..51f599bbf 100644
--- a/zh-tw/07-customizing-git/01-chapter7.markdown
+++ b/zh-tw/07-customizing-git/01-chapter7.markdown
@@ -2,32 +2,32 @@
 
 到目前為止，我闡述了 Git 基本的運作機制和使用方式，介紹了 Git 提供的許多工具來幫助你簡單且有效地使用它。在本章，我將會介紹 Git 的一些重要的組態設定(configuration)和鉤子(hooks)機制以滿足自訂的要求。通過這些工具，它能夠更容易地使 Git 按照你、你的公司或團隊所需要的方式去運作。 
 
-## Git 配置 ##
+## Git 設定 ##
 
-如第一章所言，用 `git config` 配置 Git，要做的第一件事就是設置名字和郵箱地址： 
+如第一章所言，用 `git config` 設定 Git，要做的第一件事就是設定名字和電子郵件信箱：
 
 	$ git config --global user.name "John Doe"
 	$ git config --global user.email johndoe@example.com
 
-從現在開始，你會瞭解到一些類似以上但更為有趣的設置選項來自訂 Git。 
+從現在開始，你會瞭解到一些類似以上但更為有趣的設定選項來自訂 Git。 
 
-先過一遍第一章中提到的 Git 配置細節。Git 使用一系列的設定檔來儲存你定義的偏好，它首先會查找 `/etc/gitconfig` 檔，該檔所含的設定值對系統上所有使用者都有效，也對他們所擁有的倉庫都有效（譯注：gitconfig 是全域設定檔）， 如果傳遞 `--system` 選項給 `git config` 命令， Git 會讀寫這個檔。 
+先過一遍第一章中提到的 Git 設定細節。Git 使用一系列的設定檔來保存你定義的偏好，它首先會查找 `/etc/gitconfig` 檔，該檔所含的設定值對系統上所有使用者都有效，也對他們所擁有的倉庫都有效（譯注：gitconfig 是全域設定檔）， 如果傳遞 `--system` 選項給 `git config` 命令， Git 會讀寫這個檔案。 
 
 接下來 Git 會尋找每個用戶的 `~/.gitconfig` 檔，它是針對個別使用者的，你可以傳遞 `--global` 選項讓 Git 讀寫該檔。 
 
-最後，Git 會尋找你目前使用中的倉庫 Git 目錄下的設定檔（`.git/config`），該文件中的設定值只對這個倉庫有效。以上闡述的三層配置從一般到特殊層層推進，如果定義的值有衝突，後面層級的設定會面寫前面層級的設定值，例如：在 `.git/config` 和 `/etc/gitconfig` 的較量中， `.git/config` 取得了勝利。雖然你也可以直接手動編輯這些設定檔，但是執行 git config 命令將會來得簡單些。
+最後，Git 會尋找你目前使用中的倉庫 Git 目錄下的設定檔（`.git/config`），該文件中的設定值只對這個倉庫有效。以上闡述的三層設定從一般到特殊層層推進，如果定義的值有衝突，後面層級的設定會面寫前面層級的設定值，例如：在 `.git/config` 和 `/etc/gitconfig` 的較量中， `.git/config` 取得了勝利。雖然你也可以直接手動編輯這些設定檔，但是執行 git config 命令將會來得簡單些。
 
-### 用戶端基本配置 ###
+### 用戶端基本設定 ###
 
-Git 能夠識別的配置項被分為了兩大類：用戶端和伺服器端，其中大部分屬於用戶端配置，這是基於你個人工作偏好所做的設定。儘管有數不盡的選項，但我只闡述其中經常使用、或者會對你的工作流程產生巨大影響的選項。許多選項只在極端的情況下有用，這裏就不多做介紹了。如果你想觀察你的 Git 版本能識別的選項清單，請執行 
+Git 能夠識別的設定項被分為了兩大類：用戶端和伺服器端，其中大部分屬於用戶端設定，這是基於你個人工作偏好所做的設定。儘管有數不盡的選項，但我只闡述其中經常使用、或者會對你的工作流程產生巨大影響的選項。許多選項只在極端的情況下有用，這裏就不多做介紹了。如果你想觀察你的 Git 版本能識別的選項清單，請執行 
 
 	$ git config --help
 
-`git config` 的手冊頁（譯注：以 man 命令的顯示方式）非常細緻地羅列了所有可用的配置項。 
+`git config` 的手冊頁（譯注：以 man 命令的顯示方式）非常細緻地羅列了所有可用的設定項。 
 
 #### core.editor ####
 
-預設情況下，Git 會使用你所設定的「預設文字編輯器」，否則會使用 Vi 來創建和編輯提交以及標籤資訊，你可以使用 `core.editor` 改變預設編輯器： 
+預設情況下，Git 會使用你所設定的「預設文字編輯器」，否則會使用 Vi 來建立和編輯提交以及標籤資訊，你可以使用 `core.editor` 改變預設編輯器： 
 
 	$ git config --global core.editor emacs
 
@@ -35,7 +35,7 @@ Git 能夠識別的配置項被分為了兩大類：用戶端和伺服器端，
 
 #### commit.template ####
 
-如果把這個項目指定為你系統上的一個檔，當你提交的時候，Git 會預設使用該檔定義的內容做為預設的提交訊息。例如：你創建了一個範本檔 `$HOME/.gitmessage.txt`，它看起來像這樣： 
+如果把這個專案指定為你系統上的一個檔案，當你提交的時候，Git 會預設使用該檔定義的內容做為預設的提交訊息。例如：你建立了一個範本檔 `$HOME/.gitmessage.txt`，它看起來像這樣： 
 
 	subject line
 
@@ -67,7 +67,7 @@ Git 能夠識別的配置項被分為了兩大類：用戶端和伺服器端，
 	~
 	".git/COMMIT_EDITMSG" 14L, 297C
 
-如果你對於提交訊息有特定的政策，那就在系統上創建一個範本檔，設定 Git 使用它做為預設值，這樣可以幫助提升你的政策經常被遵守的機會。 
+如果你對於提交訊息有特定的政策，那就在系統上建立一個範本檔，設定 Git 使用它做為預設值，這樣可以幫助提升你的政策經常被遵守的機會。 
 
 #### core.pager ####
 
@@ -79,7 +79,7 @@ core.pager 指定 Git 執行諸如 log、diff 等命令時所使用的分頁器
 
 #### user.signingkey ####
 
-如果你要創建經簽署的含附注的標籤(signed annotated tags)（正如第二章所述），那麼把你的 GPG 簽署金鑰設為配置項會更好，設置金鑰 ID 如下： 
+如果你要建立經簽署的含附注的標籤(signed annotated tags)（正如第二章所述），那麼把你的 GPG 簽署金鑰設為設定項會更好，設定金鑰 ID 如下： 
 
 	$ git config --global user.signingkey <gpg-key-id>
 
@@ -101,7 +101,7 @@ core.pager 指定 Git 執行諸如 log、diff 等命令時所使用的分頁器
 	Did you mean this?
 	     commit
 
-如果你把 help.autocorrect 設置成1（譯注：啟動自動修正），那麼在只有一個命令符合的情況下，Git 會自動執行該命令。 
+如果你把 help.autocorrect 設定成1（譯注：啟動自動修正），那麼在只有一個命令符合的情況下，Git 會自動執行該命令。 
 
 ### Git 中的著色 ###
 
@@ -109,42 +109,42 @@ Git 能夠為輸出到你終端(terminal)的內容著色，以便你可以憑直
 
 #### color.ui ####
 
-Git 會按照你的需要，自動為大部分的輸出加上顏色。你能明確地規定哪些需要著色、以及怎樣著色，設置 color.ui 為 true 來打開所有的預設終端著色：
+Git 會按照你的需要，自動為大部分的輸出加上顏色。你能明確地規定哪些需要著色、以及怎樣著色，設定 color.ui 為 true 來打開所有的預設終端著色：
 
 	$ git config --global color.ui true
 
-設置好以後，當輸出到終端時，Git 會為之加上顏色。其他的參數還有 false 和 always，false 意味著不為輸出著色，而 always 則表示在任何情況下都要著色 -- 即使 Git 命令被重定向到文件或 pipe 到另一個命令。Git 1.5.5 版本引進了此項配置，如果你的版本更舊，你必須對顏色有關選項各自進行詳細地設置。 
+設定好以後，當輸出到終端時，Git 會為之加上顏色。其他的參數還有 false 和 always，false 意味著不為輸出著色，而 always 則表示在任何情況下都要著色 -- 即使 Git 命令被重定向到文件或 pipe 到另一個命令。Git 1.5.5 版本引進了此項設定，如果你的版本更舊，你必須對顏色有關選項各自進行詳細地設定。 
 
 你會很少用到 `color.ui = always`，在大多數情況下，如果你想在被重定向的輸出中插入顏色碼，你可以傳遞 `--color` 旗標給 Git 命令來迫使它這麼做，`color.ui = true` 應該是你的首選。 
 
 #### `color.*` ####
 
-想要具體指定哪些命令輸出需要被著色，以及怎樣著色，或者 Git 的版本很舊，你就要用到和具體命令有關的顏色配置選項，它們都能被設為 true、false 或 always： 
+想要具體指定哪些命令輸出需要被著色，以及怎樣著色，或者 Git 的版本很舊，你就要用到和具體命令有關的顏色設定選項，它們都能被設為 true、false 或 always： 
 
 	color.branch
 	color.diff
 	color.interactive
 	color.status
 
-除此之外，以上每個選項都有子選項，可以被用來覆蓋其父設置，以達到為輸出的各個部分著色的目的。例如，要讓 diff 輸出的改變資訊 (meta information) 以粗體、藍色前景和黑色背景的形式顯示，你可以執行： 
+除此之外，以上每個選項都有子選項，可以被用來覆蓋其父設定，以達到為輸出的各個部分著色的目的。例如，要讓 diff 輸出的改變資訊 (meta information) 以粗體、藍色前景和黑色背景的形式顯示，你可以執行： 
 
 	$ git config --global color.diff.meta "blue black bold"
 
-你能設置的顏色值如下：normal、black、red、green、yellow、blue、magenta、cyan、white。正如以上例子設置的粗體屬性，想要設置字體屬性的話，你的選擇有：bold、dim、ul、blink、reverse。 
+你能設定的顏色值如下：normal、black、red、green、yellow、blue、magenta、cyan、white。正如以上例子設定的粗體屬性，想要設定字體屬性的話，你的選擇有：bold、dim、ul、blink、reverse。 
 
-如果你想配置子選項的話，可以參考 git config 幫助頁。 
+如果你想設定子選項的話，可以參考 git config 幫助頁。 
 
 ### 外部的合併與比較工具 ###
 
-雖然 Git 自己實做了 diff，而且到目前為止你一直在使用它，但你能夠設定一個外部的工具來替代它。你還可以設定用一個圖形化的工具來合併和解決衝突，而不必自己手動解決。有一個不錯且免費的工具可以被用來做比較和合併工作，它就是 P4Merge（譯注：Perforce 圖形化合併工具），我會展示它的安裝過程。 
+雖然 Git 自己實做了 diff，而且到目前為止你一直在使用它，但你能夠設定一個外部的工具來替代它。你還可以設定用一個圖形化的工具來合併和解決衝突，而不必自己手動解決。有一個不錯且免費的工具可以被用來做比較和合併工作，它就是 P4Merge（譯注：Perforce 圖形化合併工具），我會示範它的安裝過程。 
 
-所以如果你想試試看的話，因為 P4Merge 可以在所有主流平臺上運行，所以你應該可以嘗試看看。對於向你展示的例子，在 Mac 和 Linux 系統上，我會使用路徑名；在 Windows 上，`/usr/local/bin` 應該被改為你環境中的可執行路徑。 
+所以如果你想試試看的話，因為 P4Merge 可以在所有主流平臺上執行，所以你應該可以嘗試看看。對於向你示範的例子，在 Mac 和 Linux 系統上，我會使用路徑名；在 Windows 上，`/usr/local/bin` 應該被改為你環境中的可執行路徑。 
 
 你可以在這裏下載 P4Merge： 
 
 	http://www.perforce.com/product/components/perforce-visual-merge-and-diff-tools
 
-首先，你要設定一個外部包裝腳本(external wrapper scripts)來執行你要的命令，我會使用 Mac 系統上的路徑來指定該腳本的位置；在其他系統上，它應該被放置在二進位檔案 `p4merge` 所在的目錄中。創建一個 merge 包裝腳本，名字叫作 `extMerge`，讓它附帶所有參數呼叫 p4merge 二進位檔案： 
+首先，你要設定一個外部包裝腳本(external wrapper scripts)來執行你要的命令，我會使用 Mac 系統上的路徑來指定該腳本的位置；在其他系統上，它應該被放置在二進位檔案 `p4merge` 所在的目錄中。建立一個 merge 包裝腳本，名字叫作 `extMerge`，讓它附帶所有參數呼叫 p4merge 二進位檔案： 
 
 	$ cat /usr/local/bin/extMerge
 	#!/bin/sh
@@ -165,7 +165,7 @@ diff 包裝腳本首先確定傳遞過來7個參數，隨後把其中2個傳遞
 	$ sudo chmod +x /usr/local/bin/extMerge
 	$ sudo chmod +x /usr/local/bin/extDiff
 
-現在來設定使用你自訂的比較和合併工具吧。這需要許多自訂設置：`merge.tool` 通知 Git 使用哪個合併工具；`mergetool.*.cmd` 規定命令如何執行；`mergetool.trustExitCode` 會通知 Git 該程式的退出碼(exit code)是否指示合併操作成功；`diff.external` 通知 Git 用什麼命令做比較。因此，你可以執行以下4條配置命令： 
+現在來設定使用你自訂的比較和合併工具吧。這需要許多自訂設定：`merge.tool` 通知 Git 使用哪個合併工具；`mergetool.*.cmd` 規定命令如何執行；`mergetool.trustExitCode` 會通知 Git 該程式的退出碼(exit code)是否指示合併操作成功；`diff.external` 通知 Git 用什麼命令做比較。因此，你可以執行以下4條設定命令： 
 
 	$ git config --global merge.tool extMerge
 	$ git config --global mergetool.extMerge.cmd \
@@ -173,7 +173,7 @@ diff 包裝腳本首先確定傳遞過來7個參數，隨後把其中2個傳遞
 	$ git config --global mergetool.trustExitCode false
 	$ git config --global diff.external extDiff
 
-或者直接編輯 `~/.gitconfig` 文件如下： 
+或者直接編輯 `~/.gitconfig` 檔案如下： 
 
 	[merge]
 	  tool = extMerge
@@ -183,18 +183,18 @@ diff 包裝腳本首先確定傳遞過來7個參數，隨後把其中2個傳遞
 	[diff]
 	  external = extDiff
 
-設置完畢後，如果你像這樣執行 diff 命令： 
+設定完畢後，如果你像這樣執行 diff 命令： 
 
 	$ git diff 32d1776b1^ 32d1776b1
 
-不同於在命令列得到 diff 命令的輸出，Git 觸發了剛剛設置的 P4Merge，它看起來像圖7-1這樣： 
+不同於在命令列得到 diff 命令的輸出，Git 觸發了剛剛設定的 P4Merge，它看起來像圖7-1這樣： 
 
 Insert 18333fig0701.png
 Figure 7-1. P4Merge.
 
 當你設法合併兩個分支，結果卻有衝突時，執行 `git mergetool`，Git 會啟用 P4Merge 讓你通過圖形介面來解決衝突。 
 
-設置包裝腳本的好處是你能簡單地改變 diff 和 merge 工具，例如把 `extDiff` 和 `extMerge` 改成 KDiff3，要做的僅僅是編輯 `extMerge` 指令檔： 
+設定包裝腳本的好處是你能簡單地改變 diff 和 merge 工具，例如把 `extDiff` 和 `extMerge` 改成 KDiff3，要做的僅僅是編輯 `extMerge` 指令檔： 
 
 	$ cat /usr/local/bin/extMerge
 	#!/bin/sh
@@ -202,60 +202,60 @@ Figure 7-1. P4Merge.
 
 現在 Git 會使用 KDiff3 來做比較、合併和解決衝突。 
 
-Git 預先設置了許多其他的合併和解決衝突的工具，而你不必設置 cmd。可以把合併工具設置為：kdiff3、opendiff、tkdiff、meld、xxdiff、emerge、vimdiff、gvimdiff。如果你不想用 KDiff3 來做 diff，只是想用它來合併，而且 kdiff3 命令也在你的路徑裏，那麼你可以執行： 
+Git 預先設定了許多其他的合併和解決衝突的工具，而你不必設定 cmd。可以把合併工具設定為：kdiff3、opendiff、tkdiff、meld、xxdiff、emerge、vimdiff、gvimdiff。如果你不想用 KDiff3 來做 diff，只是想用它來合併，而且 kdiff3 命令也在你的路徑裏，那麼你可以執行： 
 
 	$ git config --global merge.tool kdiff3
 
-如果執行了以上命令，沒有設置 `extMerge` 和 `extDiff` 檔，Git 會用 KDiff3 做合併，讓平常內建的比較工具來做比較。 
+如果執行了以上命令，沒有設定 `extMerge` 和 `extDiff` 檔，Git 會用 KDiff3 做合併，讓平常內建的比較工具來做比較。 
 
 ### 格式化與空格 ###
 
-格式化與空格是許多開發人員在協同工作時，特別是在跨平臺情況下，遇到的令人頭疼的細小問題。在一些大家合作的工作或提交的補丁中，很容易因為編輯器安靜無聲地加入一些小空格，或者 Windows 程式師在跨平臺專案中的檔案行尾加入了回車分行符號(carriage return)。Git 的一些配置選項可以幫助解決這些問題。 
+格式化與空格是許多開發人員在協同工作時，特別是在跨平臺情況下，遇到的令人頭疼的細小問題。在一些大家合作的工作或提交的修補檔中，很容易因為編輯器安靜無聲地加入一些小空格，或者 Windows 程式師在跨平臺專案中的檔案行尾加入了Enter分行符號(carriage return)。Git 的一些設定選項可以幫助解決這些問題。 
 
 #### core.autocrlf ####
 
-如果你在 Windows 上寫程式，或者你不是用 Windows，但和其他在 Windows 上寫程式的人合作，在這些情況下，你可能會遇到換行符號的問題。這是因為 Windows 使用回車(carriage-return)和換行(linefeed)兩個字元來結束一行，而 Mac 和 Linux 只使用一個換行字元。雖然這是小問題，但它會極大地擾亂跨平臺協作。 
+如果你在 Windows 上寫程式，或者你不是用 Windows，但和其他在 Windows 上寫程式的人合作，在這些情況下，你可能會遇到換行符號的問題。這是因為 Windows 使用Enter(carriage-return)和換行(linefeed)兩個字元來結束一行，而 Mac 和 Linux 只使用一個換行字元。雖然這是小問題，但它會極大地擾亂跨平臺協作。 
 
-Git 可以在你提交時自動地把換行符號 CRLF 轉換成 LF，而在簽出代碼時把 LF 轉換成 CRLF。用 `core.autocrlf` 來打開此項功能，如果是在Windows 系統上，把它設置成 `true`，這樣當 check out 程式的時候，LF 會被轉換成 CRLF： 
+Git 可以在你提交時自動地把換行符號 CRLF 轉換成 LF，而在簽出代碼時把 LF 轉換成 CRLF。用 `core.autocrlf` 來打開此項功能，如果是在Windows 系統上，把它設定成 `true`，這樣當 check out 程式的時候，LF 會被轉換成 CRLF： 
 
 	$ git config --global core.autocrlf true
 
-Linux 或 Mac 系統使用 LF 作為行結束符，因此你不希望 Git 在 check out 檔案時進行自動的轉換；但是，當一個以 CRLF 做為換行符號的檔案不小心被引入時，你肯定希望 Git 可以修正它。你可以把 `core.autocrlf` 設置成 input 來告訴 Git 在提交時把 CRLF 轉換成 LF，check out 時不轉換： 
+Linux 或 Mac 系統使用 LF 作為行結束符，因此你不希望 Git 在 check out 檔案時進行自動的轉換；但是，當一個以 CRLF 做為換行符號的檔案不小心被引入時，你肯定希望 Git 可以修正它。你可以把 `core.autocrlf` 設定成 input 來告訴 Git 在提交時把 CRLF 轉換成 LF，check out 時不轉換： 
 
 	$ git config --global core.autocrlf input
 
 這樣會在 Windows 系統上的 check out 檔案中保留 CRLF，而在 Mac 和 Linux 系統上，以及倉庫中保留 LF。 
 
-如果你是 Windows 程式師，且正在開發僅運行在 Windows 上的專案，可以設置 `false` 取消此功能，把 carriage returns 記錄在倉庫中： 
+如果你是 Windows 程式師，且正在開發僅執行在 Windows 上的專案，可以設定 `false` 取消此功能，把 carriage returns 記錄在倉庫中： 
 
 	$ git config --global core.autocrlf false
 
 #### core.whitespace ####
 
-Git 預先設置了一些選項來探測和修正空格問題，其中有四個主要選項，有2個預設開啟，2個預設關閉，你可以自由地打開或關閉它們。 
+Git 預先設定了一些選項來探測和修正空格問題，其中有四個主要選項，有2個預設開啟，2個預設關閉，你可以自由地打開或關閉它們。 
 
 預設開啟的2個選項是：`trailing-space` 會查找每行結尾的空格，`space-before-tab` 會查找每行開頭的定位字元前的空格。 
 
 預設關閉的2個選項是：`indent-with-non-tab` 會查找8個以上空格（非定位字元）開頭的行，`cr-at-eol` 告訴 Git carriage returns 是合法的。 
 
-設置 `core.whitespace`，按照你的需要來打開或關閉選項，設定值之間以逗號分隔。從設定字串裏把設定值去掉，就可以關閉這個設定，或是在設定值前面加上減號 `-` 也可以。例如，如果你想要打開除了 cr-at-eol 之外的所有選項，你可以這麼做： 
+設定 `core.whitespace`，按照你的需要來打開或關閉選項，設定值之間以逗號分隔。從設定字串裏把設定值去掉，就可以關閉這個設定，或是在設定值前面加上減號 `-` 也可以。例如，如果你想要打開除了 cr-at-eol 之外的所有選項，你可以這麼做： 
 
 	$ git config --global core.whitespace \
 	    trailing-space,space-before-tab,indent-with-non-tab
 
-當你執行 `git diff` 命令且為輸出著色時，Git 會偵測這些問題，因此你有可能在提交前修復它們。當你用 `git apply` 打補丁時，它也同樣會使用這些設定值來幫助你。你可以要 Git 警告你，如果正準備運用的補丁有特別的空白問題： 
+當你執行 `git diff` 命令且為輸出著色時，Git 會偵測這些問題，因此你有可能在提交前修復它們。當你用 `git apply` 打修補檔時，它也同樣會使用這些設定值來幫助你。你可以要 Git 警告你，如果正準備運用的修補檔有特別的空白問題： 
 
 	$ git apply --whitespace=warn <patch>
 
-或者讓 Git 在打上補丁嘗試自動修正此問題：
+或者讓 Git 在打上修補檔嘗試自動修正此問題：
 
 	$ git apply --whitespace=fix <patch>
 
-這些選項也能運用於衍合。如果提交了有空格問題的檔但還沒推送到上游，你可以執行帶有 `--whitespace=fix` 選項的 `rebase` 來讓 Git 在重寫補丁時自動修正它們。
+這些選項也能運用於衍合。如果提交了有空格問題的檔但還沒推送到上游，你可以執行帶有 `--whitespace=fix` 選項的 `rebase` 來讓 Git 在重寫修補檔時自動修正它們。
 
-### 伺服器端配置 ###
+### 伺服器端設定 ###
 
-Git 伺服器端的配置選項並不多，但仍有一些有趣的選項值得你一看。
+Git 伺服器端的設定選項並不多，但仍有一些有趣的選項值得你一看。
 
 #### receive.fsckObjects ####
 
@@ -277,7 +277,7 @@ Git 預設情況下不會在推送期間檢查所有物件的一致性。Git 雖
 
 #### receive.denyDeletes ####
 
-避開 `denyNonFastForwards` 策略的方法之一就是使用者刪除分支，然後推回新的引用(reference)。在更新的 Git 版本中（從1.6.1版本開始），你可以把 receive.denyDeletes 設置為 true： 
+避開 `denyNonFastForwards` 策略的方法之一就是使用者刪除分支，然後推回新的引用(reference)。在更新的 Git 版本中（從1.6.1版本開始），你可以把 receive.denyDeletes 設定為 true： 
 
 	$ git config --system receive.denyDeletes true
 
@@ -285,29 +285,29 @@ Git 預設情況下不會在推送期間檢查所有物件的一致性。Git 雖
 
 ## Git 屬性 ##
 
-一些設定值(settings)也能指定到特定的路徑，這樣，Git 只對這個特定的子目錄或某些檔案應用這些設定值。這些針對特定路徑的設定值被稱為 Git 屬性(attributes)，可以在你目錄中的 `.gitattributes` 檔內進行設置（通常是你專案的根目錄），當你不想讓這些屬性檔和專案檔案一同提交時，也可以在 `.git/info/attributes` 檔進行設置。 
+一些設定值(settings)也能指定到特定的路徑，這樣，Git 只對這個特定的子目錄或某些檔案應用這些設定值。這些針對特定路徑的設定值被稱為 Git 屬性(attributes)，可以在你目錄中的 `.gitattributes` 檔內進行設定（通常是你專案的根目錄），當你不想讓這些屬性檔和專案檔案一同提交時，也可以在 `.git/info/attributes` 檔進行設定。 
 
 使用屬性，你可以對個別檔案或目錄定義不同的合併策略，讓 Git 知道怎樣比較非文字檔，在你提交或簽出(check out)前讓 Git 過濾內容。你將在這個章節裏瞭解到能在自己的專案中使用的屬性，以及一些實例。 
 
 ### 二進位檔案 ###
 
-你可以用 Git 屬性讓其知道哪些是二進位檔案（以防 Git 沒有識別出來），以及指示怎樣處理這些檔，這點很酷。例如，一些文字檔是由機器產生的，而且無法比較，而一些二進位檔案可以比較 — 你將會瞭解到怎樣讓 Git 識別這些檔。 
+你可以用 Git 屬性讓其知道哪些是二進位檔案（以防 Git 沒有識別出來），以及指示怎樣處理這些檔案，這點很酷。例如，一些文字檔是由機器產生的，而且無法比較，而一些二進位檔案可以比較 — 你將會瞭解到怎樣讓 Git 識別這些檔。 
 
 #### 識別二進位檔案 ####
 
-某些檔案看起來像是文字檔，但其實是看做為二進位資料。例如，在 Mac 上的 Xcode 專案含有一個以 `.pbxproj` 結尾的檔，它是由記錄設置項的 IDE 寫到磁碟的 JSON 資料集（純文字 javascript 資料類型）。雖然技術上看它是由 ASCII 字元組成的文字檔，但是你並不想這麼看它，因為它確實是一個輕量級資料庫 — 如果有兩個人改變了它，你沒辦法合併它們，diff 通常也幫不上忙，只有機器才能進行識別和操作，於是，你想把它當成二進位檔案。 
+某些檔案看起來像是文字檔，但其實是看做為二進位資料。例如，在 Mac 上的 Xcode 專案含有一個以 `.pbxproj` 結尾的檔，它是由記錄設定項的 IDE 寫到磁碟的 JSON 資料集（純文字 javascript 資料類型）。雖然技術上看它是由 ASCII 字元組成的文字檔，但是你並不想這麼看它，因為它確實是一個輕量級資料庫 — 如果有兩個人改變了它，你沒辦法合併它們，diff 通常也幫不上忙，只有機器才能進行識別和操作，於是，你想把它當成二進位檔案。 
 
 讓 Git 把所有 `pbxproj` 檔當成二進位檔案，在 `.gitattributes` 文件中加上下面這行： 
 
 	*.pbxproj -crlf -diff
 
-現在，Git 不會嘗試轉換和修正 CRLF（回車換行）問題；也不會當你在專案中執行 git show 或 git diff 時，嘗試比較不同的內容。在 Git 1.6 及之後的版本中，可以用一個巨集代替 `-crlf -diff`： 
+現在，Git 不會嘗試轉換和修正 CRLF（Enter換行）問題；也不會當你在專案中執行 git show 或 git diff 時，嘗試比較不同的內容。在 Git 1.6 及之後的版本中，可以用一個巨集代替 `-crlf -diff`： 
 
 	*.pbxproj binary
 
 #### Diffing Binary Files ####
 
-在 Git 1.6 及以上版本中，你能利用 Git 屬性來有效地比較二進位檔案。可以設置 Git 把二進位資料轉換成文本格式，然後用一般 diff 來做比較。 
+在 Git 1.6 及以上版本中，你能利用 Git 屬性來有效地比較二進位檔案。可以設定 Git 把二進位資料轉換成文本格式，然後用一般 diff 來做比較。 
 
 ##### MS Word files #####
 
@@ -322,7 +322,7 @@ Git 預設情況下不會在推送期間檢查所有物件的一致性。Git 雖
 
 	*.doc diff=word
 
-當你要看比較結果時，如果檔副檔名是 ”doc”，Git 會使用 ”word” 篩檢程式(filter)。什麼是 ”word” 篩檢程式呢？你必須設置它。下面你將設定 Git 使用 `strings` 程式，把 Word 文檔轉換成可讀的文字檔，之後再進行比較： 
+當你要看比較結果時，如果檔副檔名是 ”doc”，Git 會使用 ”word” 篩檢程式(filter)。什麼是 ”word” 篩檢程式呢？你必須設定它。下面你將設定 Git 使用 `strings` 程式，把 Word 文檔轉換成可讀的文字檔，之後再進行比較： 
 
 	$ git config diff.word.textconv catdoc
 
@@ -333,7 +333,7 @@ This command adds a section to your `.git/config` that looks like this:
 
 現在 Git 知道了，如果它要在在兩個快照之間做比較，而其中任何一個檔檔名是以 `.doc` 結尾，它應該要對這些檔執行 ”word” 篩檢程式，也就是定義為執行 `strings` 程式。這樣就可以在比較前把 Word 檔轉換成文字檔。 
 
-下面展示了一個實例，我把此書的第一章納入 Git 管理，在一個段落中加入了一些文字後保存，之後執行 `git diff` 命令，得到結果如下： 
+下面示範了一個實例，我把此書的第一章納入 Git 管理，在一個段落中加入了一些文字後保存，之後執行 `git diff` 命令，得到結果如下： 
 
 	$ git diff
 	diff --git a/chapter1.doc b/chapter1.doc
@@ -347,7 +347,7 @@ This command adds a section to your `.git/config` that looks like this:
 	-system for non-linear development.
 	+system for non-linear development (See Chapter 3).
 
-Git 成功且簡潔地顯示出我增加的文字 ”(See Chapter 3)”。雖然有些瑕疵 -- 在末尾顯示了一些隨機的內容 -- 但確實可以比較了。如果你能找到或自己寫個 Word 到純文字的轉換器的話，效果可能會更好。不過因為 `strings` 可以在大部分 Mac 和 Linux 系統上運行，所以在初次嘗試對各種二進位格式檔進行類似的處理，它是個不錯的選擇。 
+Git 成功且簡潔地顯示出我增加的文字 ”(See Chapter 3)”。雖然有些瑕疵 -- 在末尾顯示了一些隨機的內容 -- 但確實可以比較了。如果你能找到或自己寫個 Word 到純文字的轉換器的話，效果可能會更好。不過因為 `strings` 可以在大部分 Mac 和 Linux 系統上執行，所以在初次嘗試對各種二進位格式檔進行類似的處理，它是個不錯的選擇。 
 
 ##### OpenDocument Text files #####
 
@@ -402,7 +402,7 @@ Now `git diff` will be able to tell you what changed in `.odt` files.
 
 ##### Image files #####
 
-你還能用這個方法解決另一個有趣的問題：比較影像檔。方法之一是對 JPEG 檔執行一個篩檢程式，把 EXIF 資訊捉取出來 — EXIF 資訊是記錄在大部分圖像格式裏面的 metadata。如果你下載並安裝了 `exiftool` 程式，可以用它把圖檔的 metadata 轉換成文本，於是至少 diff 可以用文字呈現的方式向你展示發生了哪些修改： 
+你還能用這個方法解決另一個有趣的問題：比較影像檔。方法之一是對 JPEG 檔執行一個篩檢程式，把 EXIF 資訊捉取出來 — EXIF 資訊是記錄在大部分圖像格式裏面的 metadata。如果你下載並安裝了 `exiftool` 程式，可以用它把圖檔的 metadata 轉換成文本，於是至少 diff 可以用文字呈現的方式向你示範發生了哪些修改： 
 
 	$ echo '*.png diff=exif' >> .gitattributes
 	$ git config diff.exif.textconv exiftool
@@ -434,7 +434,7 @@ Now `git diff` will be able to tell you what changed in `.odt` files.
 
 使用 SVN 或 CVS 的開發人員經常要求關鍵字擴展。這在 Git 中主要的問題是，你無法在一個檔案被提交後再修改它，因為 Git 會先對該檔計算 checksum。然而，你可以在檔案 check out 之後注入(inject)一些文字，然後在提交前再把它移除。Git 屬性提供了兩種方式來進行。 
 
-首先，你可以把某個 blob 的 SHA-1 checksum 自動注入檔案的 $Id$ 欄位。如果在一個或多個檔案上設置了此欄位，當下次你 check out 該分支的時候，Git 會用 blob 的 SHA-1 值替換那個欄位。注意，這不是 commit 物件的 SHA，而是 blob 本身的： 
+首先，你可以把某個 blob 的 SHA-1 checksum 自動注入檔案的 $Id$ 欄位。如果在一個或多個檔案上設定了此欄位，當下次你 check out 該分支的時候，Git 會用 blob 的 SHA-1 值替換那個欄位。注意，這不是 commit 物件的 SHA，而是 blob 本身的： 
 
 	$ echo '*.txt ident' >> .gitattributes
 	$ echo '$Id$' > test.txt
@@ -448,7 +448,7 @@ Now `git diff` will be able to tell you what changed in `.odt` files.
 
 然而，這個結果的用處有限。如果你在 CVS 或 Subversion 中用過關鍵字替換，你可以包含一個日期值 -- 而這個 SHA 值沒什麼幫助，因為它相當地隨機，也無法區分某個 SHA 跟另一個 SHA 比起來是比較新或是比較舊。
 
-因此，你可以撰寫自己的篩檢程式，在提交或 checkout 文件時替換關鍵字。有兩種篩檢程式，”clean” 和 ”smudge”。在 `.gitattributes` 檔中，你能對特定的路徑設置一個篩檢程式，然後設置處理檔案的腳本，這些腳本會在檔案 check out 前（”smudge”，見圖 7-2）和提交前（”clean”，見圖7-3）被執行。這些篩檢程式能夠做各種有趣的事。 
+因此，你可以撰寫自己的篩檢程式，在提交或 checkout 文件時替換關鍵字。有兩種篩檢程式，”clean” 和 ”smudge”。在 `.gitattributes` 檔中，你能對特定的路徑設定一個篩檢程式，然後設定處理檔案的腳本，這些腳本會在檔案 check out 前（”smudge”，見圖 7-2）和提交前（”clean”，見圖7-3）被執行。這些篩檢程式能夠做各種有趣的事。 
 
 Insert 18333fig0702.png
 Figure 7-2. “smudge” filter 在 checkout 時執行
@@ -456,11 +456,11 @@ Figure 7-2. “smudge” filter 在 checkout 時執行
 Insert 18333fig0703.png
 Figure 7-3. “clean” filter 在檔案被 staged 的時候執行
 
-這裡舉一個簡單的例子：在提交前，用 indent（縮進）程式過濾所有C原始程式碼。在 `.gitattributes` 檔中設置 ”indent” 篩檢程式過濾 `*.c` 文件： 
+這裡舉一個簡單的例子：在提交前，用 indent（縮進）程式過濾所有C原始程式碼。在 `.gitattributes` 檔中設定 ”indent” 篩檢程式過濾 `*.c` 文件： 
 
 	*.c     filter=indent
 
-然後，通過以下配置，讓 Git 知道 ”indent” 篩檢程式在遇到 ”smudge” 和 ”clean” 時分別該做什麼： 
+然後，通過以下設定，讓 Git 知道 ”indent” 篩檢程式在遇到 ”smudge” 和 ”clean” 時分別該做什麼： 
 
 	$ git config --global filter.indent.clean indent
 	$ git config --global filter.indent.smudge cat
@@ -474,12 +474,12 @@ Figure 7-3. “clean” filter 在檔案被 staged 的時候執行
 	last_date = `git log --pretty=format:"%ad" -1`
 	puts data.gsub('$Date$', '$Date: ' + last_date.to_s + '$')
 
-該腳本從 `git log` 命令中得到最新提交日期，找到檔案中所有的 $Date$ 字串，最後把該日期填到 $Date$ 字串中 — 此腳本很簡單，你可以選擇你喜歡的程式設計語言來實現。把該腳本命名為 `expand_date`，放到正確的路徑中，之後需要在 Git 中設置一個篩檢程式（`dater`），讓它在 check ou 檔案時使用 `expand_date`，在提交時用 Perl 清除之： 
+該腳本從 `git log` 命令中得到最新提交日期，找到檔案中所有的 $Date$ 字串，最後把該日期填到 $Date$ 字串中 — 此腳本很簡單，你可以選擇你喜歡的程式設計語言來實現。把該腳本命名為 `expand_date`，放到正確的路徑中，之後需要在 Git 中設定一個篩檢程式（`dater`），讓它在 check ou 檔案時使用 `expand_date`，在提交時用 Perl 清除之： 
 
 	$ git config filter.dater.smudge expand_date
 	$ git config filter.dater.clean 'perl -pe "s/\\\$Date[^\\\$]*\\\$/\\\$Date\\\$/"'
 
-這個 Perl 小程式會刪除 $Date$ 字串裡多餘的字元，恢復 $Date$ 原貌。到目前為止，你的篩檢程式已經設置完畢，可以開始測試了。打開一個檔，在檔中輸入 $Date$ 關鍵字，然後設置 Git 屬性： 
+這個 Perl 小程式會刪除 $Date$ 字串裡多餘的字元，恢復 $Date$ 原貌。到目前為止，你的篩檢程式已經設定完畢，可以開始測試了。打開一個檔案，在檔中輸入 $Date$ 關鍵字，然後設定 Git 屬性： 
 
 	$ echo '# $Date$' > date_test.txt
 	$ echo 'date*.txt filter=dater' >> .gitattributes
@@ -501,17 +501,17 @@ Git 屬性在將專案匯出歸檔(archive)時也能發揮作用。
 
 #### export-ignore ####
 
-當產生一個 archive 時，可以告訴 Git 不要匯出某些檔案或目錄。如果你不想在 archive 中包含一個子目錄或檔案，但想將他們納入專案的版本管理中，你能對應地設置 `export-ignore` 屬性。
+當產生一個 archive 時，可以告訴 Git 不要匯出某些檔案或目錄。如果你不想在 archive 中包含一個子目錄或檔案，但想將他們納入專案的版本管理中，你能對應地設定 `export-ignore` 屬性。
 
 例如，在 `test/` 子目錄中有一些測試檔，在專案的壓縮包中包含他們是沒有意義的。因此，可以增加下面這行到 Git 屬性檔中： 
 
 	test/ export-ignore
 
-現在，當運行 git archive 來創建專案的壓縮包時，那個目錄不會在 archive 中出現。 
+現在，當執行 git archive 來建立專案的壓縮包時，那個目錄不會在 archive 中出現。 
 
 #### export-subst ####
 
-還能對 archives 做一些簡單的關鍵字替換。在第2章中已經可以看到，可以以 `--pretty=format` 形式的簡碼在任何檔中放入 `$Format:$` 字串。例如，如果想在專案中包含一個叫作 `LAST_COMMIT` 的檔，當運行 `git archive` 時，最後提交日期自動地注入進該檔，可以這樣設置： 
+還能對 archives 做一些簡單的關鍵字替換。在第2章中已經可以看到，可以以 `--pretty=format` 形式的簡碼在任何檔中放入 `$Format:$` 字串。例如，如果想在專案中包含一個叫作 `LAST_COMMIT` 的檔，當執行 `git archive` 時，最後提交日期自動地注入進該檔，可以這樣設定： 
 
 	$ echo 'Last commit date: $Format:%cd$' > LAST_COMMIT
 	$ echo "LAST_COMMIT export-subst" >> .gitattributes
@@ -527,7 +527,7 @@ Git 屬性在將專案匯出歸檔(archive)時也能發揮作用。
 
 通過 Git 屬性，還能對專案中的特定檔案使用不同的合併策略。一個非常有用的選項就是，當一些特定檔案發生衝突，Git 不會嘗試合併他們，而使用你這邊的來覆蓋別人的。 
 
-如果專案的一個分支有歧義或比較特別，但你想從該分支合併，而且需要忽略其中某些檔，這樣的合併策略是有用的。例如，你有一個資料庫設置檔 database.xml，在兩個分支中他們是不同的，你想合併一個分支到另一個，而不弄亂該資料庫檔，可以設置屬性如下： 
+如果專案的一個分支有歧義或比較特別，但你想從該分支合併，而且需要忽略其中某些檔，這樣的合併策略是有用的。例如，你有一個資料庫設定檔 database.xml，在兩個分支中他們是不同的，你想合併一個分支到另一個，而不弄亂該資料庫檔，可以設定屬性如下： 
 
 	database.xml merge=ours
 
@@ -545,7 +545,7 @@ Git 屬性在將專案匯出歸檔(archive)時也能發揮作用。
 
 ### 安裝一個 Hook ###
 
-掛鉤都被儲存在 Git 目錄下的 `hooks` 子目錄中，即大部分專案中預設的 `.git/hooks`。Git 預設會放置一些腳本範例在這個目錄中，除了可以作為掛鉤使用，這些樣本本身是可以獨立使用的。所有的樣本都是 shell 腳本，其中一些還包含了 Perl 的腳本，不過，任何正確命名的可執行腳本都可以正常使用 — 可以用 Ruby 或 Python，或其他。在 Git 1.6 版本之後，這些樣本檔名都是以 .sample 結尾，因此，你必須重新命名。在 Git 1.6 版本之前，這些樣本名都是正確的，但這些樣本不是可執行檔。 
+掛鉤都被保存在 Git 目錄下的 `hooks` 子目錄中，即大部分專案中預設的 `.git/hooks`。Git 預設會放置一些腳本範例在這個目錄中，除了可以作為掛鉤使用，這些樣本本身是可以獨立使用的。所有的樣本都是 shell 腳本，其中一些還包含了 Perl 的腳本，不過，任何正確命名的可執行腳本都可以正常使用 — 可以用 Ruby 或 Python，或其他。在 Git 1.6 版本之後，這些樣本檔名都是以 .sample 結尾，因此，你必須重新命名。在 Git 1.6 版本之前，這些樣本名都是正確的，但這些樣本不是可執行檔。 
 
 把一個正確命名且可執行的檔放入 Git 目錄下的 hooks 子目錄中，可以啟動該掛鉤腳本，之後他一直會被 Git 呼叫。隨後會講解主要的掛鉤腳本。 
 
@@ -555,47 +555,47 @@ Git 屬性在將專案匯出歸檔(archive)時也能發揮作用。
 
 #### 提交工作流程掛鉤 ####
 
-有四個掛鉤被用來處理提交的過程。`pre-commit` 掛鉤在鍵入提交資訊前運行，被用來檢查即將提交的快照，例如，檢查是否有東西被遺漏，確認測試是否運行，以及檢查代碼。當從該掛鉤返回非零值時，Git 放棄此次提交，但可以用 `git commit --no-verify` 來忽略。該掛鉤可以被用來檢查程式碼樣式（運行類似 lint 的程式），檢查尾部空白（預設掛鉤是這麼做的），檢查新方法（簡體中文版譯注：程式的函數）的說明。 
+有四個掛鉤被用來處理提交的過程。`pre-commit` 掛鉤在鍵入提交資訊前執行，被用來檢查即將提交的快照，例如，檢查是否有東西被遺漏，確認測試是否執行，以及檢查代碼。當從該掛鉤返回非零值時，Git 放棄此次提交，但可以用 `git commit --no-verify` 來忽略。該掛鉤可以被用來檢查程式碼樣式（執行類似 lint 的程式），檢查尾部空白（預設掛鉤是這麼做的），檢查新方法（簡體中文版譯注：程式的函數）的說明。 
 
-`prepare-commit-msg` 掛鉤在提交資訊編輯器顯示之前，預設資訊被創建之後執行。因此，可以有機會在提交作者看到預設資訊前進行編輯。該掛鉤接收一些選項：擁有提交資訊的檔案路徑，提交類型，以及提交的 SHA-1 (如果這是一個 amended 提交)。該掛鉤對通常的提交來說不是很有用，只在自動產生的預設提交資訊的情況下有作用，如提交資訊範本、合併、壓縮和 amended 提交等。可以和提交範本配合使用，以程式設計的方式插入資訊。 
+`prepare-commit-msg` 掛鉤在提交資訊編輯器顯示之前，預設資訊被建立之後執行。因此，可以有機會在提交作者看到預設資訊前進行編輯。該掛鉤接收一些選項：擁有提交資訊的檔案路徑，提交類型，以及提交的 SHA-1 (如果這是一個 amended 提交)。該掛鉤對通常的提交來說不是很有用，只在自動產生的預設提交資訊的情況下有作用，如提交資訊範本、合併、壓縮和 amended 提交等。可以和提交範本配合使用，以程式設計的方式插入資訊。 
 
-`commit-msg` 掛鉤接收一個參數，此參數是包含最近提交資訊的暫存檔路徑。如果該掛鉤腳本以非零退出，Git 會放棄提交，因此，可以用來在提交通過前驗證專案狀態或提交資訊。本章上一小節已經展示了使用該掛鉤核對提交資訊是否符合特定的模式。 
+`commit-msg` 掛鉤接收一個參數，此參數是包含最近提交資訊的暫存檔路徑。如果該掛鉤腳本以非零退出，Git 會放棄提交，因此，可以用來在提交通過前驗證專案狀態或提交資訊。本章上一小節已經示範了使用該掛鉤核對提交資訊是否符合特定的模式。 
 
-`post-commit` 掛鉤在整個提交過程完成後運行，他不會接收任何參數，但可以執行 `git log -1 HEAD` 來獲得最後的提交資訊。總之，該掛鉤是作為通知之類使用的。 
+`post-commit` 掛鉤在整個提交過程完成後執行，他不會接收任何參數，但可以執行 `git log -1 HEAD` 來獲得最後的提交資訊。總之，該掛鉤是作為通知之類使用的。 
 
-提交工作流程的用戶端掛鉤腳本可以在任何工作流程中使用，他們經常被用來實施某些策略，但值得注意的是，這些腳本在 clone 期間不會被傳送。可以在伺服器端實施策略來拒絕不符合某些策略的推送，但這完全取決於開發者在用戶端使用這些腳本的情況。所以，這些腳本對開發者是有用的，由他們自己設置和維護，而且在任何時候都可以覆蓋或修改這些腳本。 
+提交工作流程的用戶端掛鉤腳本可以在任何工作流程中使用，他們經常被用來實施某些策略，但值得注意的是，這些腳本在 clone 期間不會被傳送。可以在伺服器端實施策略來拒絕不符合某些策略的推送，但這完全取決於開發者在用戶端使用這些腳本的情況。所以，這些腳本對開發者是有用的，由他們自己設定和維護，而且在任何時候都可以覆蓋或修改這些腳本。 
 
 #### E-mail 工作流掛鉤 ####
 
-有三個可用的用戶端掛鉤用於 e-mail工作流。當運行 `git am` 命令時，會呼叫他們，因此，如果你沒有在工作流中用到此命令，可以跳過本節。如果你通過 e-mail 接收由 git `format-patch` 產生的補丁，這些掛鉤也許對你有用。 
+有三個可用的用戶端掛鉤用於 e-mail工作流。當執行 `git am` 命令時，會呼叫他們，因此，如果你沒有在工作流中用到此命令，可以跳過本節。如果你通過 e-mail 接收由 git `format-patch` 產生的修補檔，這些掛鉤也許對你有用。 
 
-首先執行的是 applypatch-msg 掛鉤，他接收一個參數：包含被建議提交資訊的暫存檔案名。如果該腳本以非零值退出，Git 將放棄此補丁。可以使用這個腳本確認提交資訊是否被正確格式化，或讓腳本把提交訊息編輯為正規化。
+首先執行的是 applypatch-msg 掛鉤，他接收一個參數：包含被建議提交資訊的暫存檔案名。如果該腳本以非零值退出，Git 將放棄此修補檔。可以使用這個腳本確認提交資訊是否被正確格式化，或讓腳本把提交訊息編輯為正規化。
 
-下一個當透過 `git am` 應用補丁時執行的是 `pre-applypatch` 掛鉤。該掛鉤不接收參數，在補丁被應用之後執行，因此，可以被用來在提交前檢查快照。你能用此腳本執行測試，檢查工作樹。如果有些什麼遺漏，或測試沒通過，腳本會以非零退出，放棄此次 `git am` 的運行，補丁不會被提交。
+下一個當透過 `git am` 應用修補檔時執行的是 `pre-applypatch` 掛鉤。該掛鉤不接收參數，在修補檔被應用之後執行，因此，可以被用來在提交前檢查快照。你能用此腳本執行測試，檢查工作樹。如果有些什麼遺漏，或測試沒通過，腳本會以非零退出，放棄此次 `git am` 的執行，修補檔不會被提交。
 
-最後在 `git am` 操作期間執行的掛鉤是 `post-applypatch`。你可以用他來通知一個小組或該補丁的作者，但無法使用此腳本阻止打補丁的過程。
+最後在 `git am` 操作期間執行的掛鉤是 `post-applypatch`。你可以用他來通知一個小組或該修補檔的作者，但無法使用此腳本阻止打修補檔的過程。
 
 #### 其他用戶端掛鉤 ####
 
 `pre-rebase` 掛鉤在衍合前執行，腳本以非零退出可以中止衍合的過程。你可以使用這個掛鉤來禁止衍合已經推送的提交物件，Git 所安裝的 `pre-rebase` 掛鉤範例就是這麼做的，不過它假定 next 是你定義的分支名。因此，你可能要修改樣本，把 next 改成你定義過且穩定的分支名。 
 
-在 `git checkout` 成功執行後會執行 `post-checkout` 掛鉤。他可以用來為你的專案環境設置合適的工作目錄。例如：放入大的二進位檔案、自動產生的文檔或其他一切你不想納入版本控制的檔。 
+在 `git checkout` 成功執行後會執行 `post-checkout` 掛鉤。他可以用來為你的專案環境設定合適的工作目錄。例如：放入大的二進位檔案、自動產生的文檔或其他一切你不想納入版本控制的檔案。 
 
 最後，在 `merge` 命令成功執行後會執行 `post-merge` 掛鉤。他可以用來在 Git 無法跟蹤的工作樹中恢復資料，例如許可權資料。該掛鉤同樣能夠驗證在 Git 控制之外的檔是否存在，當工作樹改變時，你希望可以複製進來的檔案。
 
 ### 伺服器端掛鉤 ###
 
-除了用戶端掛鉤，作為系統管理員，你還可以使用兩個伺服器端的掛鉤對專案實施各種類型的策略。這些掛鉤腳本可以在提交物件推送到伺服器前執行，也可以在推送到伺服器後執行。推送到伺服器前執行的掛鉤(pre hooks)可以在任何時候以非零退出，拒絕推送、傳回錯誤訊息給用戶端；還可以如你所願設置足夠複雜的推送策略。
+除了用戶端掛鉤，作為系統管理員，你還可以使用兩個伺服器端的掛鉤對專案實施各種類型的策略。這些掛鉤腳本可以在提交物件推送到伺服器前執行，也可以在推送到伺服器後執行。推送到伺服器前執行的掛鉤(pre hooks)可以在任何時候以非零退出，拒絕推送、傳回錯誤訊息給用戶端；還可以如你所願設定足夠複雜的推送策略。
 
 #### pre-receive and post-receive ####
 
-處理來自用戶端的推送（push）操作時最先執行的腳本就是 `pre-receive` 。它從標準輸入（stdin）獲取被推送的引用(references)列表；如果它退出時的返回值不是0，那麼所有推送內容都不會被接受。利用此掛鉤腳本可以實現類似保證被更新的索引(references)都不是 non-fast-forward 類型；抑或檢查執行推送操作的用戶擁有創建、刪除或者推送的許可權，或者他是否對將要修改的每一個檔都有存取權限。
+處理來自用戶端的推送（push）操作時最先執行的腳本就是 `pre-receive` 。它從標準輸入（stdin）取得被推送的引用(references)列表；如果它退出時的返回值不是0，那麼所有推送內容都不會被接受。利用此掛鉤腳本可以實現類似保證被更新的索引(references)都不是 non-fast-forward 類型；抑或檢查執行推送操作的用戶擁有建立、刪除或者推送的許可權，或者他是否對將要修改的每一個檔都有存取權限。
 
 `post-receive` 掛鉤在整個過程完結以後執行，可以用來更新其他系統服務或者通知使用者。它接受與 `pre-receive` 相同的標準輸入資料。應用實例包括給某郵寄清單發信，通知即時整合資料的伺服器，或者更新軟體專案的問題追蹤系統 —— 甚至可以通過分析提交資訊來決定某個問題是否應該被開啟、修改或結案。該腳本無法停止推送程序，不過用戶端在它完成之前將保持連接狀態；所以在用它作一些長時間的操作之前請三思。
 
 #### update ####
 
-update 腳本和 `pre-receive` 腳本十分類似，除了它會為推送者更新的每一個分支運行一次。假如推送者同時向多個分支推送內容，`pre-receive` 只執行一次，相較之下 update 則會為每一個更新的分支運行一次。它不會從標準輸入讀取內容，而是接受三個參數：索引(reference)的名字（分支），推送前索引指向的內容的 SHA-1 值，以及使用者試圖推送內容的 SHA-1 值。如果 update 腳本退出時返回非零值，只有相應的那一個索引會被拒絕；其餘的依然會得到更新。 
+update 腳本和 `pre-receive` 腳本十分類似，除了它會為推送者更新的每一個分支執行一次。假如推送者同時向多個分支推送內容，`pre-receive` 只執行一次，相較之下 update 則會為每一個更新的分支執行一次。它不會從標準輸入讀取內容，而是接受三個參數：索引(reference)的名字（分支），推送前索引指向的內容的 SHA-1 值，以及使用者試圖推送內容的 SHA-1 值。如果 update 腳本退出時返回非零值，只有相應的那一個索引會被拒絕；其餘的依然會得到更新。 
 
 ## Git 強制策略實例 ##
 
@@ -605,7 +605,7 @@ update 腳本和 `pre-receive` 腳本十分類似，除了它會為推送者更
 
 ### 服務端掛鉤 ###
 
-所有服務端的工作都在 hooks（掛鉤）目錄的 update（更新）腳本中制定。update 腳本為每一個得到推送的分支運行一次；它接受推送目標的索引(reference)、該分支原來指向的位置、以及被推送的新內容。如果推送是通過 SSH 進行的，還可以獲取發出此次操作的用戶。如果設定所有操作都通過公鑰授權的單一帳號（比如＂git＂）進行，就有必要通過一個 shell 包裝(wrapper)依據公鑰來判斷用戶的身份，並且設定環境變數來表示該使用者的身份。下面假設嘗試連接的使用者儲存在 `$USER` 環境變數裡，我們的 update 腳本首先搜集一切需要的資訊： 
+所有服務端的工作都在 hooks（掛鉤）目錄的 update（更新）腳本中制定。update 腳本為每一個得到推送的分支執行一次；它接受推送目標的索引(reference)、該分支原來指向的位置、以及被推送的新內容。如果推送是通過 SSH 進行的，還可以取得發出此次操作的用戶。如果設定所有操作都通過公鑰授權的單一帳號（比如＂git＂）進行，就有必要通過一個 shell 包裝(wrapper)依據公鑰來判斷用戶的身份，並且設定環境變數來表示該使用者的身份。下面假設嘗試連接的使用者保存在 `$USER` 環境變數裡，我們的 update 腳本首先搜集一切需要的資訊： 
 
 	#!/usr/bin/env ruby
 
@@ -618,9 +618,9 @@ update 腳本和 `pre-receive` 腳本十分類似，除了它會為推送者更
 
 #### 強制特定的提交資訊格式 ####
 
-我們的第一項任務是指定每一條提交資訊都必須遵循某種特殊的格式。只是設定一個目標，假定每一條資訊必須包含一條形似 “ref: 1234” 這樣的字串，因為我們需要把每一次提交連結到專案問題追蹤系統裏面的工作項目。我們要逐一檢查每一條推送上來的提交內容，看看提交資訊是否包含這麼一個字串，然後，如果該提交裡不包含這個字串，以非零返回值退出從而拒絕此次推送。
+我們的第一項任務是指定每一條提交資訊都必須遵循某種特殊的格式。只是設定一個目標，假定每一條資訊必須包含一條形似 “ref: 1234” 這樣的字串，因為我們需要把每一次提交連結到專案問題追蹤系統裏面的工作專案。我們要逐一檢查每一條推送上來的提交內容，看看提交資訊是否包含這麼一個字串，然後，如果該提交裡不包含這個字串，以非零返回值退出從而拒絕此次推送。
 
-把 `$newrev` 和 `$oldrev` 變數的值傳給一個叫做 `git rev-list` 的 Git plumbing 命令可以獲取所有提交內容 SHA-1 值的列表。`git rev-list` 基本上是個 `git log` 命令，但它預設只輸出 SHA-1 值而已，沒有其他資訊。所以要獲取由 SHA 值表示的從一次提交到另一次提交之間的所有 SHA 值，可以執行： 
+把 `$newrev` 和 `$oldrev` 變數的值傳給一個叫做 `git rev-list` 的 Git plumbing 命令可以取得所有提交內容 SHA-1 值的列表。`git rev-list` 基本上是個 `git log` 命令，但它預設只輸出 SHA-1 值而已，沒有其他資訊。所以要取得由 SHA 值表示的從一次提交到另一次提交之間的所有 SHA 值，可以執行： 
 
 	$ git rev-list 538c33..d14fc7
 	d14fc7c847ab946ec39590d87783c69b031bdfb7
@@ -667,9 +667,9 @@ update 腳本和 `pre-receive` 腳本十分類似，除了它會為推送者更
 
 #### 實現基於使用者的存取權限控制清單（ACL）系統 ####
 
-假設你需要添加一個使用存取權限控制列表 (access control list, ACL) 的機制來指定哪些使用者對專案的哪些部分有推送許可權。某些使用者具有全部的存取權，其他人只對某些子目錄或者某些特定的檔案具有推送許可權。要搞定這一點，所有的規則將被寫入一個位於伺服器的原始 Git 倉庫的 `acl` 檔。我們讓 update 掛鉤檢閱這些規則，審視推送的提交內容中需要修改的所有檔案，然後判定執行推送的用戶是否對所有這些檔案都有許可權。 
+假設你需要增加一個使用存取權限控制列表 (access control list, ACL) 的機制來指定哪些使用者對專案的哪些部分有推送許可權。某些使用者具有全部的存取權，其他人只對某些子目錄或者某些特定的檔案具有推送許可權。要搞定這一點，所有的規則將被寫入一個位於伺服器的原始 Git 倉庫的 `acl` 檔。我們讓 update 掛鉤檢閱這些規則，審視推送的提交內容中需要修改的所有檔案，然後判定執行推送的用戶是否對所有這些檔案都有許可權。 
 
-我們首先要創建這個列表。這裡使用的格式和 CVS 的 ACL 機制十分類似：它由若干行構成，第一欄的內容是 `avail` 或者 `unavail`；下一欄是由逗號分隔的使用者清單，列出這條規則會對哪些使用者生效；最後一欄是這條規則會對哪個目錄生效（空白表示開放訪問）。這些欄位由 pipe (`|`) 字元隔開。 
+我們首先要建立這個列表。這裡使用的格式和 CVS 的 ACL 機制十分類似：它由若干行構成，第一欄的內容是 `avail` 或者 `unavail`；下一欄是由逗號分隔的使用者清單，列出這條規則會對哪些使用者生效；最後一欄是這條規則會對哪個目錄生效（空白表示開放存取）。這些欄位由 pipe (`|`) 字元隔開。 
 
 下例中，我們指定幾個管理員，幾個對 `doc` 目錄具有許可權的文件作者，以及一個只對 `lib` 和 `tests` 目錄具有許可權的開發人員，ACL 檔看起來像這樣： 
 
@@ -678,7 +678,7 @@ update 腳本和 `pre-receive` 腳本十分類似，除了它會為推送者更
 	avail|schacon|lib
 	avail|schacon|tests
 
-首先把這些資料讀入到你所能使用的資料結構中。本例中，為保持簡潔，我們暫時只實做 `avail` 的規則（譯注：也就是省略了 unavail 部分）。下面這個 method 產生一個關聯式陣列，它的主鍵是用戶名，對應的值是一個該用戶有寫入許可權的所有目錄組成的陣列： 
+首先把這些資料讀入到你所能使用的資料結構中。本例中，為保持簡潔，我們暫時只實做 `avail` 的規則（譯注：也就是省略了 unavail 部分）。下面這個 method 產生一個關聯式陣列，它的主鍵是使用者名稱，對應的值是一個該用戶有寫入許可權的所有目錄組成的陣列： 
 
 	def get_acl_access_data(acl_file)
 	  # read in ACL data
@@ -744,7 +744,7 @@ update 腳本和 `pre-receive` 腳本十分類似，除了它會為推送者更
 
 	check_directory_perms
 
-以上的大部分內容應該還算容易理解。通過 `git rev-list` 獲取推送到伺服器的提交清單。然後，針對其中每一項，找出它試圖修改的檔案，然後確保執行推送的用戶對這些檔案具有許可權。一個不太容易理解的 Ruby 技巧是 `path.index(access_path) ==0` 這句，如果路徑以 `access_path` 開頭，它會回傳 True——這是為了確保 `access_path` 並不是只在允許的路徑之一，而是所有准許全選的目錄都在該目錄之下。
+以上的大部分內容應該還算容易理解。通過 `git rev-list` 取得推送到伺服器的提交清單。然後，針對其中每一項，找出它試圖修改的檔案，然後確保執行推送的用戶對這些檔案具有許可權。一個不太容易理解的 Ruby 技巧是 `path.index(access_path) ==0` 這句，如果路徑以 `access_path` 開頭，它會回傳 True——這是為了確保 `access_path` 並不是只在允許的路徑之一，而是所有准許全選的目錄都在該目錄之下。
 
 現在，如果提交資訊的格式不對的話，或是修改的檔案在允許的路徑之外的話，你的用戶就不能推送這些提交。 
 
@@ -873,7 +873,7 @@ update 腳本和 `pre-receive` 腳本十分類似，除了它會為推送者更
 
 	check_directory_perms
 
-這和服務端的腳本幾乎一樣，除了兩個重要區別。第一，ACL 檔的位置不同，因為這個腳本在當前工作目錄執行，而非 Git 目錄。ACL 檔的目錄必須由這個
+這和服務端的腳本幾乎一樣，除了兩個重要區別。第一，ACL 檔的位置不同，因為這個腳本在目前工作目錄執行，而非 Git 目錄。ACL 檔的目錄必須由這個
 
 	access = get_acl_access_data('acl')
 
@@ -881,7 +881,7 @@ update 腳本和 `pre-receive` 腳本十分類似，除了它會為推送者更
 
 	access = get_acl_access_data('.git/acl')
 
-另一個重要區別是獲取「被修改檔案清單」的方式。在服務端的時候使用了查看提交紀錄的方式，可是目前的提交都還沒被記錄下來呢，所以這個清單只能從暫存區域獲取。原來是這樣：
+另一個重要區別是取得「被修改檔案清單」的方式。在服務端的時候使用了查看提交紀錄的方式，可是目前的提交都還沒被記錄下來呢，所以這個清單只能從暫存區域取得。原來是這樣：
 
 	files_modified = `git log -1 --name-only --pretty=format:'' #{ref}`
 
@@ -889,13 +889,13 @@ update 腳本和 `pre-receive` 腳本十分類似，除了它會為推送者更
 
 	files_modified = `git diff-index --cached --name-only HEAD`
 
-不同的就只有這兩點——除此之外，該腳本完全相同。一個小陷阱在於它假設在本地執行的帳戶和推送到遠端服務端的相同。如果這二者不一樣，則需要手動設置一下 `$user` 變數。
+不同的就只有這兩點——除此之外，該腳本完全相同。一個小陷阱在於它假設在本地執行的帳戶和推送到遠端服務端的相同。如果這二者不一樣，則需要手動設定一下 `$user` 變數。
 
 最後一項任務是檢查確認推送內容中不包含非 fast-forward 類型的索引(reference)，不過這個需求比較少見。以下情況會得到一個非 fast-forward 類型的索引，要麼在某個已經推送過的提交上做衍合，要麼從本地不同分支推送到遠端相同的分支上。
 
 既然伺服器會告訴你不能推送非 fast-forward 內容，而且上面的掛鉤也能阻止強制的推送，唯一剩下的潛在問題就是衍合已經推送過的提交內容。
 
-下面是一個檢查這個問題的 pre-rabase 腳本的例子。它獲取一個所有即將重寫的提交內容的清單，然後檢查它們是否在遠端的索引(reference)裡已經存在。一旦發現某個提交可以從遠端索引裡衍變過來，它就放棄衍合操作：
+下面是一個檢查這個問題的 pre-rabase 腳本的例子。它取得一個所有即將重寫的提交內容的清單，然後檢查它們是否在遠端的索引(reference)裡已經存在。一旦發現某個提交可以從遠端索引裡衍變過來，它就放棄衍合操作：
 
 	#!/usr/bin/env ruby
 
@@ -929,4 +929,4 @@ update 腳本和 `pre-receive` 腳本十分類似，除了它會為推送者更
 
 ## 總結 ##
 
-你已經見識過絕大多數通過自訂 Git 用戶端和服務端來適應自己工作流程和專案內容的方式了。你已經學到了各種配置設定(configuration settings)、以檔案為基礎的屬性(file-based attributes)、以及事件掛鉤，你也建置了一個執行強制政策的伺服器。現在，差不多任何你能想像到的工作流程，你應該都能讓 Git 切合你的需要。
+你已經見識過絕大多數通過自訂 Git 用戶端和服務端來適應自己工作流程和專案內容的方式了。你已經學到了各種設定設定(configuration settings)、以檔案為基礎的屬性(file-based attributes)、以及事件掛鉤，你也建置了一個執行強制政策的伺服器。現在，差不多任何你能想像到的工作流程，你應該都能讓 Git 切合你的需要。
diff --git a/zh-tw/08-git-and-other-scms/01-chapter8.markdown b/zh-tw/08-git-and-other-scms/01-chapter8.markdown
index 150d7f5bd..c8879b6fb 100644
--- a/zh-tw/08-git-and-other-scms/01-chapter8.markdown
+++ b/zh-tw/08-git-and-other-scms/01-chapter8.markdown
@@ -6,7 +6,7 @@
 
 ## Git 與 Subversion ##
 
-當前，大多數開發中的開源專案以及大量的商業專案都使用 Subversion 來管理源碼。作為最流行的開源版本控制系統，Subversion 已經存在了接近十年的時間。它在許多方面與 CVS 十分類似，後者是前者出現之前代碼控制世界的霸主。 
+目前，大多數開發中的開源專案以及大量的商業專案都使用 Subversion 來管理原始碼。作為最流行的開源版本控制系統，Subversion 已經存在了接近十年的時間。它在許多方面與 CVS 十分類似，後者是前者出現之前代碼控制世界的霸主。 
 
 Git 最為重要的特性之一是名為 `git svn` 的 Subversion 雙向橋接工具。該工具把 Git 變成了 Subversion 服務的用戶端，從而讓你在本地享受到 Git 所有的功能，而後直接向 Subversion 伺服器推送內容，仿佛在本地使用了 Subversion 用戶端。也就是說，在其他人忍受古董的同時，你可以在本地享受分支合併，使用暫存區域，衍合以及單項挑揀(cherry-picking)等等。這是個讓 Git 偷偷潛入合作開發環境的好東西，在幫助你的開發同伴們提高效率的同時，它還能幫你勸說團隊讓整個專案框架轉向對 Git 的支持。這個 Subversion 之橋是通向分散式版本控制系統（DVCS, Distributed VCS ）世界的神奇隧道。 
 
@@ -20,14 +20,14 @@ Git 中所有 Subversion 橋接命令的基礎是 `git svn` 。所有的命令
 
 ### 初始設定 ###
 
-為了展示功能，先要一個具有寫入許可權的 SVN 倉庫。如果想嘗試這個範例，你必須複製一份其中的測試倉庫。比較簡單的做法是使用一個名為 `svnsync` 的工具。較新的 Subversion 版本中都帶有該工具，它將資料編碼為用於網路傳輸的格式。 
+為了示範功能，先要一個具有寫入許可權的 SVN 倉庫。如果想嘗試這個範例，你必須複製一份其中的測試倉庫。比較簡單的做法是使用一個名為 `svnsync` 的工具。較新的 Subversion 版本中都帶有該工具，它將資料編碼為用於網路傳輸的格式。 
 
 要嘗試本例，先在本地新建一個 Subversion 倉庫：
 
 	$ mkdir /tmp/test-svn
 	$ svnadmin create /tmp/test-svn
 
-然後，允許所有用戶修改 revprop —— 簡單的做法是添加一個總是以 0 作為傳回值的 pre-revprop-change 腳本： 
+然後，允許所有用戶修改 revprop —— 簡單的做法是增加一個總是以 0 作為傳回值的 pre-revprop-change 腳本： 
 
 	$ cat /tmp/test-svn/hooks/pre-revprop-change
 	#!/bin/sh
@@ -70,7 +70,7 @@ Git 中所有 Subversion 橋接命令的基礎是 `git svn` 。所有的命令
 	Checked out HEAD:
 	 file:///tmp/test-svn/branches/my-calc-branch r76
 
-這相當於針對所提供的 URL 運行了兩條命令—— `git svn init` 加上 `gitsvn fetch` 。可能會花上一段時間。我們所用的測試專案僅僅包含 75 次提交並且它的代碼量不算大，所以只有幾分鐘而已。不過，Git 仍然需要提取每一個版本，每次一個，再逐個提交。對於一個包含成百上千次提交的專案，花掉的時間則可能是幾小時甚至數天。 
+這相當於針對所提供的 URL 執行了兩條命令—— `git svn init` 加上 `gitsvn fetch` 。可能會花上一段時間。我們所用的測試專案僅僅包含 75 次提交並且它的代碼量不算大，所以只有幾分鐘而已。不過，Git 仍然需要提取每一個版本，每次一個，再逐個提交。對於一個包含成百上千次提交的專案，花掉的時間則可能是幾小時甚至數天。 
 
 `-T trunk -b branches -t tags` 告訴 Git 該 Subversion 倉庫遵循了基本的分支和標籤命名法則。如果你的主幹(譯注：trunk，相當於非分散式版本控制裡的 master 分支，代表開發的主線）分支或者標籤以不同的方式命名，則應做出相應改變。由於該法則的常見性，可以使用 `-s` 來代替整條命令，它意味著標準佈局（s 是 Standard layout 的首字母），也就是前面選項的內容。下面的命令有相同的效果： 
 
@@ -87,7 +87,7 @@ Git 中所有 Subversion 橋接命令的基礎是 `git svn` 。所有的命令
 	  tags/release-2.0.2rc1
 	  trunk
 
-值得注意的是，該工具分配命名空間時和遠端參照的方式不盡相同。clone 普通的 Git 倉庫時，可以用 `origin/[branch]` 的形式獲取遠端伺服器上所有可用的分支——分配到遠端服務的名稱下。然而 `git svn` 假定不存在多個遠端伺服器，所以把所有指向遠端服務的引用不加區分(no namespacing)的保存下來。可以用 Git 底層(plumbing)命令 `show-ref` 來查看所有引用的全名：
+值得注意的是，該工具分配命名空間時和遠端參照的方式不盡相同。clone 普通的 Git 倉庫時，可以用 `origin/[branch]` 的形式取得遠端伺服器上所有可用的分支——分配到遠端服務的名稱下。然而 `git svn` 假定不存在多個遠端伺服器，所以把所有指向遠端服務的引用不加區分(no namespacing)的保存下來。可以用 Git 底層(plumbing)命令 `show-ref` 來查看所有引用的全名：
 
 	$ git show-ref
 	1cbd4904d9982f386d87f88fce1c24ad7c0f0471 refs/heads/master
@@ -108,7 +108,7 @@ Git 中所有 Subversion 橋接命令的基礎是 `git svn` 。所有的命令
 
 這裡有兩個遠端伺服器：一個名為 `gitserver` ，具有一個 `master` 分支；另一個叫 `origin`，具有 `master` 和 `testing` 兩個分支。 
 
-注意本例中通過 `git svn` 導入的遠端參照，（Subversion 的)標籤是當作遠端分支添加的，而不是真正的 Git 標籤。導入的 Subversion 倉庫仿佛是有一個帶有不同分支的 tags 遠端伺服器。
+注意本例中通過 `git svn` 導入的遠端參照，（Subversion 的)標籤是當作遠端分支增加的，而不是真正的 Git 標籤。導入的 Subversion 倉庫仿佛是有一個帶有不同分支的 tags 遠端伺服器。
 
 ### 提交到 Subversion ###
 
@@ -129,7 +129,7 @@ Git 中所有 Subversion 橋接命令的基礎是 `git svn` 。所有的命令
 	No changes between current HEAD and refs/remotes/trunk
 	Resetting to the latest refs/remotes/trunk
 
-所有在原 Subversion 資料基礎上提交的 commit 會一一提交到 Subversion，然後你本地 Git 的 commit 將被重寫，加入一個特別標識。這一步很重要，因為它意味著所有 commit 的 SHA-1 指都會發生變化。這也是同時使用 Git 和 Subversion 兩種服務作為遠端服務不是個好主意的原因之一。檢視以下最後一個 commit，你會找到新添加的 `git-svn-id` （譯注：即本段開頭所說的特別標識）： 
+所有在原 Subversion 資料基礎上提交的 commit 會一一提交到 Subversion，然後你本地 Git 的 commit 將被重寫，加入一個特別標識。這一步很重要，因為它意味著所有 commit 的 SHA-1 指都會發生變化。這也是同時使用 Git 和 Subversion 兩種服務作為遠端服務不是個好主意的原因之一。檢視以下最後一個 commit，你會找到新增加的 `git-svn-id` （譯注：即本段開頭所說的特別標識）： 
 
 	$ git log -1
 	commit 938b1a547c2cc92033b74d32030e86468294a5c8
@@ -160,7 +160,7 @@ Git 中所有 Subversion 橋接命令的基礎是 `git svn` 。所有的命令
 	First, rewinding head to replay your work on top of it...
 	Applying: first user change
 
-現在，你做出的修改都在 Subversion 伺服器上，所以可以順利的運行 `dcommit` ：
+現在，你做出的修改都在 Subversion 伺服器上，所以可以順利的執行 `dcommit` ：
 
 	$ git svn dcommit
 	Committing to file:///tmp/test-svn/trunk ...
@@ -190,7 +190,7 @@ Git 中所有 Subversion 橋接命令的基礎是 `git svn` 。所有的命令
 
 這一點需要牢記，因為它的結果是推送之後專案處於一個不完整存在於任何主機上的狀態。如果做出的修改無法相容但沒有產生衝突，則可能造成一些很難確診的難題。這和使用 Git 伺服器是不同的——在 Git 世界裡，發佈之前，你可以在用戶端系統裡完整的測試專案的狀態，而在 SVN 永遠都沒法確保提交前後專案的狀態完全一樣。 
 
-即使還沒打算進行提交，你也應該用這個命令從 Subversion 伺服器拉取最新修改。你可以執行 `git svn fetch` 獲取最新的資料，不過 `git svn rebase` 才會在獲取之後在本地進行更新 。 
+即使還沒打算進行提交，你也應該用這個命令從 Subversion 伺服器拉取最新修改。你可以執行 `git svn fetch` 取得最新的資料，不過 `git svn rebase` 才會在取得之後在本地進行更新 。 
 
 	$ git svn rebase
 	       M      generate_descriptor_proto.sh
@@ -202,9 +202,9 @@ Git 中所有 Subversion 橋接命令的基礎是 `git svn` 。所有的命令
 
 ### Git 分支問題 ###
 
-習慣了 Git 的工作流程以後，你可能會創建一些特性分支，完成相關的開發工作，然後合併他們。如果要用 git svn 向 Subversion 推送內容，那麼最好是每次用衍合來併入一個單一分支，而不是直接合併。使用衍合的原因是 Subversion 只有一個線性的歷史而不像 Git 那樣處理合併，所以 Git svn 在把快照轉換為 Subversion 的 commit 時只能包含第一個祖先。 
+習慣了 Git 的工作流程以後，你可能會建立一些特性分支，完成相關的開發工作，然後合併他們。如果要用 git svn 向 Subversion 推送內容，那麼最好是每次用衍合來併入一個單一分支，而不是直接合併。使用衍合的原因是 Subversion 只有一個線性的歷史而不像 Git 那樣處理合併，所以 Git svn 在把快照轉換為 Subversion 的 commit 時只能包含第一個祖先。 
 
-假設分支歷史如下：創建一個 `experiment` 分支，進行兩次提交，然後合併到 `master` 。在 `dcommit` 的時候會得到如下輸出： 
+假設分支歷史如下：建立一個 `experiment` 分支，進行兩次提交，然後合併到 `master` 。在 `dcommit` 的時候會得到如下輸出： 
 
 	$ git svn dcommit
 	Committing to file:///tmp/test-svn/trunk ...
@@ -225,15 +225,15 @@ Git 中所有 Subversion 橋接命令的基礎是 `git svn` 。所有的命令
 	No changes between current HEAD and refs/remotes/trunk
 	Resetting to the latest refs/remotes/trunk
 
-在一個包含了合併歷史的分支上使用 `dcommit` 可以成功運行，不過在 Git 專案的歷史中，它沒有重寫你在 `experiment` 分支中的兩個 commit ——取而代之的是，這些改變出現在了 SVN 版本中同一個合併 commit 中。 
+在一個包含了合併歷史的分支上使用 `dcommit` 可以成功執行，不過在 Git 專案的歷史中，它沒有重寫你在 `experiment` 分支中的兩個 commit ——取而代之的是，這些改變出現在了 SVN 版本中同一個合併 commit 中。 
 
 在別人 clone 該專案的時候，只能看到這個合併 commit 包含了所有發生過的修改；他們無法獲知修改的作者和時間等提交資訊。 
 
 ### Subversion 分支 ###
 
-Subversion 的分支和 Git 中的不盡相同；避免過多的使用可能是最好方案。不過，用 git svn 創建和提交不同的 Subversion 分支仍是可行的。 
+Subversion 的分支和 Git 中的不盡相同；避免過多的使用可能是最好方案。不過，用 git svn 建立和提交不同的 Subversion 分支仍是可行的。 
 
-#### 創建新的 SVN 分支 ####
+#### 建立新的 SVN 分支 ####
 
 要在 Subversion 中建立一個新分支，可以執行 `git svn branch [分支名]`: 
 
@@ -248,9 +248,9 @@ Subversion 的分支和 Git 中的不盡相同；避免過多的使用可能是
 
 這相當於在 Subversion 中的 `svn copy trunk branches/opera` 命令並且對 Subversion 伺服器進行了相關操作。值得提醒的是它沒有檢出(check out)並轉換到那個分支；如果現在進行提交，將提交到伺服器上的 `trunk`， 而非 `opera`。 
 
-### 切換當前分支 ###
+### 切換目前分支 ###
 
-Git 通過搜尋提交歷史中 Subversion 分支的頭部(tip)來決定 dcommit 的目的地——而它應該只有一個，那就是當前分支歷史中最近一次包含 `git-svn-id` 的提交。 
+Git 通過搜尋提交歷史中 Subversion 分支的頭部(tip)來決定 dcommit 的目的地——而它應該只有一個，那就是目前分支歷史中最近一次包含 `git-svn-id` 的提交。 
 
 如果需要同時在多個分支上提交，可以通過導入 Subversion 上某個其他分支的 commit 來建立以該分支為 `dcommit` 目的地的本地分支。比如你想擁有一個並行維護的 `opera` 分支，可以執行
 
@@ -258,7 +258,7 @@ Git 通過搜尋提交歷史中 Subversion 分支的頭部(tip)來決定 dcommit
 
 然後，如果要把 `opera` 分支併入 `trunk` （本地的 `master` 分支），可以使用普通的 `git merge`。不過最好提供一條描述提交的資訊（通過 `-m`），否則這次合併的記錄會是「Merge branch opera」，而不是任何有用的東西。 
 
-記住，雖然使用了 `git merge` 來進行這次操作，並且合併過程可能比使用 Subversion 簡單一些（因為 Git 會自動找到適合的合併基礎），這並不是一次普通的 Git 合併提交。最終它將被推送回Subversion 伺服器上，而 Subversion 伺服器上無法處理包含多個祖先的 commit；因而在推送之後，它將變成一個包含了所有在其他分支上做出的改變的單一 commit。把一個分支合併到另一個分支以後，你沒法像在 Git 中那樣輕易的回到那個分支上繼續工作。提交時執行的 `dcommit` 命令擦掉了所有關於哪個分支被併入的資訊，因而以後的合併基礎計算將是不正確的—— dcommit 讓 `git merge` 的結果變得類似於 `git merge --squash`。不幸的是，我們沒有什麼好辦法來避免該情況—— Subversion 無法儲存這個資訊，所以在使用它作為伺服器的時候你將永遠為這個缺陷所困。為了不出現這種問題，在把本地分支（本例中的 `opera`）併入 trunk 以後應該立即將其刪除。 
+記住，雖然使用了 `git merge` 來進行這次操作，並且合併過程可能比使用 Subversion 簡單一些（因為 Git 會自動找到適合的合併基礎），這並不是一次普通的 Git 合併提交。最終它將被推送回Subversion 伺服器上，而 Subversion 伺服器上無法處理包含多個祖先的 commit；因而在推送之後，它將變成一個包含了所有在其他分支上做出的改變的單一 commit。把一個分支合併到另一個分支以後，你沒法像在 Git 中那樣輕易的回到那個分支上繼續工作。提交時執行的 `dcommit` 命令擦掉了所有關於哪個分支被併入的資訊，因而以後的合併基礎計算將是不正確的—— dcommit 讓 `git merge` 的結果變得類似於 `git merge --squash`。不幸的是，我們沒有什麼好辦法來避免該情況—— Subversion 無法保存這個資訊，所以在使用它作為伺服器的時候你將永遠為這個缺陷所困。為了不出現這種問題，在把本地分支（本例中的 `opera`）併入 trunk 以後應該立即將其刪除。 
 
 ### 對應 Subversion 的命令 ###
 
@@ -266,7 +266,7 @@ Git 通過搜尋提交歷史中 Subversion 分支的頭部(tip)來決定 dcommit
 
 #### SVN 風格的歷史紀錄 ####
 
-習慣了 Subversion 的人可能想以 SVN 的風格顯示歷史，運行 `git svn log` 可以讓提交歷史顯示為 SVN 格式： 
+習慣了 Subversion 的人可能想以 SVN 的風格顯示歷史，執行 `git svn log` 可以讓提交歷史顯示為 SVN 格式： 
 
 	$ git svn log
 	------------------------------------------------------------------------
@@ -308,7 +308,7 @@ Git 通過搜尋提交歷史中 Subversion 分支的頭部(tip)來決定 dcommit
 
 #### SVN 伺服器資訊 ####
 
-還可以使用 `git svn info` 來獲取與執行 `svn info` 類似的資訊： 
+還可以使用 `git svn info` 來取得與執行 `svn info` 類似的資訊： 
 
 	$ git svn info
 	Path: .
@@ -322,7 +322,7 @@ Git 通過搜尋提交歷史中 Subversion 分支的頭部(tip)來決定 dcommit
 	Last Changed Rev: 87
 	Last Changed Date: 2009-05-02 16:07:37 -0700 (Sat, 02 May 2009)
 
-它與 blame 和 log 的相同點在於離線運行以及只更新到最後一次與 Subversion 伺服器通信的狀態。 
+它與 blame 和 log 的相同點在於離線執行以及只更新到最後一次與 Subversion 伺服器通訊的狀態。 
 
 #### 忽略 Subversion 所忽略的 ####
 
@@ -336,16 +336,16 @@ Git 通過搜尋提交歷史中 Subversion 分支的頭部(tip)來決定 dcommit
 
 ### Git-Svn 總結 ###
 
-`git svn` 工具集在當前不得不使用 Subversion 伺服器或者開發環境要求使用 Subversion 伺服器的時候格外有用。不妨把它看成一個跛腳的 Git，然而，你還是有可能在轉換過程中碰到一些困惑你和合作者們的謎題。為了避免麻煩，試著遵守如下守則： 
+`git svn` 工具集在目前不得不使用 Subversion 伺服器或者開發環境要求使用 Subversion 伺服器的時候格外有用。不妨把它看成一個跛腳的 Git，然而，你還是有可能在轉換過程中碰到一些困惑你和合作者們的謎題。為了避免麻煩，試著遵守如下守則： 
 
 * 保持一個不包含由 `git merge` 產生的 commit 的線性提交歷史。將在主線分支外進行的開發通通衍合回主線；避免直接合併。 
-* 不要單獨建立和使用一個 Git 服務來搞合作。可以為了加速新開發者的 clone 進程建立一個，但是不要向它提供任何不包含 `git-svn-id` 條目的內容。甚至可以添加一個 `pre-receive` 掛鉤，在每一個提交資訊中檢查 `git-svn-id`，並拒絕提交那些不包含它的 commit。 
+* 不要單獨建立和使用一個 Git 服務來搞合作。可以為了加速新開發者的 clone 行程建立一個，但是不要向它提供任何不包含 `git-svn-id` 條目的內容。甚至可以增加一個 `pre-receive` 掛鉤，在每一個提交資訊中檢查 `git-svn-id`，並拒絕提交那些不包含它的 commit。 
 
 如果遵循這些守則，在 Subversion 上工作還可以接受。然而，如果能遷徙到真正的 Git 伺服器，則能為團隊帶來更多好處。 
 
 ## 遷移到 Git ##
 
-如果在其他版本控制系統(VCS)中保存了某專案的代碼而後決定轉而使用 Git，那麼該專案必須經歷某種形式的遷移。本節將介紹 Git 中包含的一些針對常見系統的導入腳本(importer)，並將展示編寫自訂的導入腳本的方法。
+如果在其他版本控制系統(VCS)中保存了某專案的代碼而後決定轉而使用 Git，那麼該專案必須經歷某種形式的遷移。本節將介紹 Git 中包含的一些針對常見系統的導入腳本(importer)，並將示範編寫自訂的導入腳本的方法。
 
 ### 導入 ###
 
@@ -355,7 +355,7 @@ Git 通過搜尋提交歷史中 Subversion 分支的頭部(tip)來決定 dcommit
 
 讀過前一節有關 `git svn` 的內容以後，你應該能輕而易舉的根據其中的指導來 `git svn clone` 一個倉庫了；然後，停止 Subversion 的使用，向一個新 Git server 推送，並開始使用它。想保留歷史記錄，所花的時間應該不過就是從 Subversion 伺服器拉取資料的時間（可能要等上好一會就是了）。 
 
-然而，這樣的匯入並不完美；而且還要花那麼多時間，不如乾脆一次把它做對！首當其衝的任務是作者資訊。在 Subversion，每個提交者都在主機上有一個用戶名，記錄在提交資訊中。上節例子中多處顯示了 schacon ，比如 `blame` 的輸出以及 `git svn log`。如果想讓這條資訊更好的映射到 Git 作者資料裡，則需要從 Subversion 用戶名到 Git 作者的一個映射關係。建立一個叫做 `user.txt` 的檔，用如下格式表示映射關係： 
+然而，這樣的匯入並不完美；而且還要花那麼多時間，不如乾脆一次把它做對！首當其衝的任務是作者資訊。在 Subversion，每個提交者都在主機上有一個使用者名稱，記錄在提交資訊中。上節例子中多處顯示了 schacon ，比如 `blame` 的輸出以及 `git svn log`。如果想讓這條資訊更好的映射到 Git 作者資料裡，則需要從 Subversion 使用者名稱到 Git 作者的一個映射關係。建立一個叫做 `user.txt` 的檔，用如下格式表示映射關係： 
 
 	schacon = Scott Chacon <schacon@geemail.com>
 	selse = Someo Nelse <selse@geemail.com>
@@ -365,9 +365,9 @@ Git 通過搜尋提交歷史中 Subversion 分支的頭部(tip)來決定 dcommit
 	$ svn log ^/ --xml | grep -P "^<author" | sort -u | \
 	      perl -pe 's/<author>(.*?)<\/author>/$1 = /' > users.txt
 
-它將輸出 XML 格式的日誌——你可以找到作者，建立一個單獨的列表，然後從 XML 中抽取出需要的資訊。（顯而易見，本方法要求主機上安裝了`grep`，`sort` 和 `perl`.）然後把輸出重定向到 user.txt 檔，然後就可以在每一項的後面添加相應的 Git 使用者資料。 
+它將輸出 XML 格式的日誌——你可以找到作者，建立一個單獨的列表，然後從 XML 中抽取出需要的資訊。（顯而易見，本方法要求主機上安裝了`grep`，`sort` 和 `perl`.）然後把輸出重定向到 user.txt 檔，然後就可以在每一項的後面增加相應的 Git 使用者資料。 
 
-為 `git svn` 提供該檔可以讓它更精確的映射作者資料。你還可以在 `clone` 或者 `init` 後面添加 `--no-metadata` 來阻止 `git svn` 包含那些 Subversion 的附加資訊。這樣 `import` 命令就變成了：
+為 `git svn` 提供該檔可以讓它更精確的映射作者資料。你還可以在 `clone` 或者 `init` 後面增加 `--no-metadata` 來阻止 `git svn` 包含那些 Subversion 的附加資訊。這樣 `import` 命令就變成了：
 
 	$ git svn clone http://my-project.googlecode.com/svn/ \
 	      --authors-file=users.txt --no-metadata -s my_project
@@ -392,7 +392,7 @@ Git 通過搜尋提交歷史中 Subversion 分支的頭部(tip)來決定 dcommit
 
 不僅作者一項乾淨了不少，`git-svn-id` 也就此消失了。 
 
-你還需要一點 post-import（導入後） 清理工作。最起碼的，應該清理一下 `git svn` 創建的那些怪異的索引結構。首先要移動標籤，把它們從奇怪的遠端分支變成實際的標籤，然後把剩下的分支移動到本地。 
+你還需要一點 post-import（導入後） 清理工作。最起碼的，應該清理一下 `git svn` 建立的那些怪異的索引結構。首先要移動標籤，把它們從奇怪的遠端分支變成實際的標籤，然後把剩下的分支移動到本地。 
 
 要把標籤變成合適的 Git 標籤，執行 
 
@@ -404,7 +404,7 @@ Git 通過搜尋提交歷史中 Subversion 分支的頭部(tip)來決定 dcommit
 
 	$ git for-each-ref refs/remotes | cut -d / -f 3- | grep -v @ | while read branchname; do git branch "$branchname" "refs/remotes/$branchname"; git branch -r -d "$branchname"; done
 
-現在所有的舊分支都變成真正的 Git 分支，所有的舊標籤也變成真正的 Git 標籤。最後一項工作就是把新建的 Git 伺服器添加為遠端伺服器並且向它推送。為了讓所有的分支和標籤都得到上傳，我們使用這條命令： 
+現在所有的舊分支都變成真正的 Git 分支，所有的舊標籤也變成真正的 Git 標籤。最後一項工作就是把新增的 Git 伺服器增加為遠端伺服器並且向它推送。為了讓所有的分支和標籤都得到上傳，我們使用這條命令： 
 
 	$ git remote add origin git@my-git-server:myrepository.git
 
@@ -417,12 +417,12 @@ Because you want all your branches and tags to go up, you can now run this:
 
 ### Perforce ###
 
-你將瞭解到的下一個被導入的系統是 Perforce. Git 發行的時候同時也附帶了一個 Perforce 導入腳本，不過它是包含在源碼的 `contrib` 部分——而不像 `git svn` 那樣預設就可以使用。執行它之前必須獲取 Git 的源碼，可以在 git.kernel.org 下載： 
+你將瞭解到的下一個被導入的系統是 Perforce. Git 發行的時候同時也附帶了一個 Perforce 導入腳本，不過它是包含在原始碼的 `contrib` 部分——而不像 `git svn` 那樣預設就可以使用。執行它之前必須取得 Git 的原始碼，可以在 git.kernel.org 下載： 
 
 	$ git clone git://git.kernel.org/pub/scm/git/git.git
 	$ cd git/contrib/fast-import
 
-在這個 `fast-import` 目錄下，應該有一個叫做 `git-p4` 的 Python 可執行腳本。主機上必須裝有 Python 和 `p4` 工具該導入才能正常進行。例如，你要從 Perforce 公共代碼倉庫（譯注： Perforce Public Depot，Perforce 官方提供的代碼寄存服務）導入 Jam 專案。為了設定用戶端，我們要把 P4PORT 環境變數 export 到 Perforce 倉庫： 
+在這個 `fast-import` 目錄下，應該有一個叫做 `git-p4` 的 Python 可執行腳本。主機上必須裝有 Python 和 `p4` 工具該導入才能正常進行。例如，你要從 Perforce 公開代碼倉庫（譯注： Perforce Public Depot，Perforce 官方提供的代碼寄存服務）導入 Jam 專案。為了設定用戶端，我們要把 P4PORT 環境變數 export 到 Perforce 倉庫： 
 
 	$ export P4PORT=public.perforce.com:1666
 
@@ -486,7 +486,7 @@ Because you want all your branches and tags to go up, you can now run this:
 
 ### 自定導入腳本 ###
 
-如果你的系統不是 Subversion 或 Perforce 之一，先上網找一下有沒有與之對應的導入腳本——導入 CVS，Clear Case，Visual Source Safe，甚至存檔目錄的導入腳本已經存在。假如這些工具都不適用，或者使用的工具很少見，抑或你需要導入過程具有更多可制定性，則應該使用 `git fast-import`。該命令從標準輸入讀取簡單的指令來寫入具體的 Git 資料。這樣創建 Git 物件比執行純 Git 命令或者手動寫物件要簡單的多（更多相關內容見第九章）。通過它，你可以編寫一個導入腳本來從導入來源讀取必要的資訊，同時在標準輸出直接輸出相關指令(instructions)。你可以執行該腳本並把它的輸出管道連接(pipe)到 `git fast-import`。 
+如果你的系統不是 Subversion 或 Perforce 之一，先上網找一下有沒有與之對應的導入腳本——導入 CVS，Clear Case，Visual Source Safe，甚至存檔目錄的導入腳本已經存在。假如這些工具都不適用，或者使用的工具很少見，抑或你需要導入過程具有更多可制定性，則應該使用 `git fast-import`。該命令從標準輸入讀取簡單的指令來寫入具體的 Git 資料。這樣建立 Git 物件比執行純 Git 命令或者手動寫物件要簡單的多（更多相關內容見第九章）。通過它，你可以編寫一個導入腳本來從導入來源讀取必要的資訊，同時在標準輸出直接輸出相關指令(instructions)。你可以執行該腳本並把它的輸出管道連接(pipe)到 `git fast-import`。 
 
 下面演示一下如何編寫一個簡單的導入腳本。假設你在進行一項工作，並且按時通過把工作目錄複寫為以時間戳記 back_YY_MM_DD 命名的目錄來進行備份，現在你需要把它們導入 Git 。目錄結構如下： 
 
@@ -497,9 +497,9 @@ Because you want all your branches and tags to go up, you can now run this:
 	back_2009_02_03
 	current
 
-為了導入到一個 Git 目錄，我們首先回顧一下 Git 儲存資料的方式。你可能還記得，Git 本質上是一個 commit 物件的鏈表，每一個物件指向一個內容的快照。而這裡需要做的工作就是告訴 `fast-import` 內容快照的位置，什麼樣的 commit 資料指向它們，以及它們的順序。我們採取一次處理一個快照的策略，為每一個內容目錄建立對應的 commit ，每一個 commit 與前一個 commit 建立連結。 
+為了導入到一個 Git 目錄，我們首先回顧一下 Git 保存資料的方式。你可能還記得，Git 本質上是一個 commit 物件的鏈表，每一個物件指向一個內容的快照。而這裡需要做的工作就是告訴 `fast-import` 內容快照的位置，什麼樣的 commit 資料指向它們，以及它們的順序。我們採取一次處理一個快照的策略，為每一個內容目錄建立對應的 commit ，每一個 commit 與前一個 commit 建立連結。 
 
-正如在第七章 “Git 執行策略一例” 一節中一樣，我們將使用 Ruby 來編寫這個腳本，因為它是我日常使用的語言而且閱讀起來簡單一些。你可以用任何其他熟悉的語言來重寫這個例子——它僅需要把必要的資訊列印到標準輸出而已。同時，如果你在使用 Windows，這意味著你要特別留意不要在換行的時候引入回車符（譯注：carriage returns，Windows 換行時加入的符號，通常說的 \r ）—— Git 的 fast-import 對僅使用分行符號（LF）而非 Windows 的回車符（CRLF）要求非常嚴格。 
+正如在第七章 “Git 執行策略一例” 一節中一樣，我們將使用 Ruby 來編寫這個腳本，因為它是我日常使用的語言而且閱讀起來簡單一些。你可以用任何其他熟悉的語言來重寫這個例子——它僅需要把必要的資訊列印到標準輸出而已。同時，如果你在使用 Windows，這意味著你要特別留意不要在換行的時候引入Enter符（譯注：carriage returns，Windows 換行時加入的符號，通常說的 \r ）—— Git 的 fast-import 對僅使用分行符號（LF）而非 Windows 的Enter符（CRLF）要求非常嚴格。 
 
 首先，進入目標目錄並且找到所有子目錄，每一個子目錄將作為一個快照被導入為一個 commit。我們將依次進入每一個子目錄並列印所需的命令來匯出它們。腳本的主迴圈大致是這樣： 
 
@@ -517,7 +517,7 @@ Because you want all your branches and tags to go up, you can now run this:
 	  end
 	end
 
-我們在每一個目錄裡執行 `print_export`，它會取出上一個快照的索引和標記並返回本次快照的索引和標記；由此我們就可以正確的把二者連接起來。”標記（mark）” 是 `fast-import` 中對 commit 識別字的叫法；在創建 commit 的同時，我們逐一賦予一個標記以便以後在把它連接到其他 commit 時使用。因此，在 `print_export` 方法中要做的第一件事就是根據目錄名產生一個標記： 
+我們在每一個目錄裡執行 `print_export`，它會取出上一個快照的索引和標記並返回本次快照的索引和標記；由此我們就可以正確的把二者連接起來。”標記（mark）” 是 `fast-import` 中對 commit 識別字的叫法；在建立 commit 的同時，我們逐一賦予一個標記以便以後在把它連接到其他 commit 時使用。因此，在 `print_export` 方法中要做的第一件事就是根據目錄名產生一個標記： 
 
 	mark = convert_dir_to_mark(dir)
 
@@ -551,7 +551,7 @@ Because you want all your branches and tags to go up, you can now run this:
 
 	$author = 'Scott Chacon <schacon@example.com>'
 
-我們差不多可以開始為導入腳本輸出提交資料了。第一項資訊指明我們定義的是一個 commit 物件以及它所在的分支，隨後是我們產生的標記、提交者資訊以及提交備註，然後是前一個 commit 的索引，如果有的話。程式碼大致像這樣： 
+我們差不多可以開始為導入腳本輸出提交資料了。第一項資訊指定我們定義的是一個 commit 物件以及它所在的分支，隨後是我們產生的標記、提交者資訊以及提交備註，然後是前一個 commit 的索引，如果有的話。程式碼大致像這樣： 
 
 	# print the import information
 	puts 'commit refs/heads/master'
@@ -560,12 +560,12 @@ Because you want all your branches and tags to go up, you can now run this:
 	export_data('imported from ' + dir)
 	puts 'from :' + last_mark if last_mark
 
-為了簡化，時區寫死(hardcode)為（-0700）。如果是從其他版本控制系統導入，則必須以變數的形式指明時區。
+為了簡化，時區寫死(hardcode)為（-0700）。如果是從其他版本控制系統導入，則必須以變數的形式指定時區。
 提交訊息必須以特定格式給出： 
 
 	data (size)\n(contents)
 
-該格式包含了「data」這個字、所讀取資料的大小、一個分行符號，最後是資料本身。由於隨後指明檔案內容的時候要用到相同的格式，我們寫一個輔助方法，`export_data`： 
+該格式包含了「data」這個字、所讀取資料的大小、一個分行符號，最後是資料本身。由於隨後指定檔案內容的時候要用到相同的格式，我們寫一個輔助方法，`export_data`： 
 
 	def export_data(string)
 	  print "data #{string.size}\n#{string}"
@@ -579,9 +579,9 @@ Because you want all your branches and tags to go up, you can now run this:
 	  inline_data(file)
 	end
 
-注意：由於很多系統把每次修訂看作一個 commit 到另一個 commit 的變化量，fast-import 也可以依據每次提交獲取一個命令來指出哪些檔被添加，刪除或者修改過，以及修改的內容。我們將需要計算快照之間的差別並且僅僅給出這項資料，不過該做法要複雜很多——還不如直接把所有資料丟給 Git 讓它自己搞清楚。假如前面這個方法更適用於你的資料，參考 `fast-import` 的 man 説明頁面來瞭解如何以這種方式提供資料。 
+注意：由於很多系統把每次修訂看作一個 commit 到另一個 commit 的變化量，fast-import 也可以依據每次提交取得一個命令來指出哪些檔被增加，刪除或者修改過，以及修改的內容。我們將需要計算快照之間的差別並且僅僅給出這項資料，不過該做法要複雜很多——還不如直接把所有資料丟給 Git 讓它自己搞清楚。假如前面這個方法更適用於你的資料，參考 `fast-import` 的 man 説明頁面來瞭解如何以這種方式提供資料。 
 
-列舉新檔內容或者指明帶有新內容的已修改檔的格式如下： 
+列舉新檔內容或者指定帶有新內容的已修改檔的格式如下： 
 
 	M 644 inline path/to/file
 	data (size)
@@ -595,13 +595,13 @@ Because you want all your branches and tags to go up, you can now run this:
 	  export_data(content)
 	end
 
-我們再次使用了前面定義過的 `export_data`，因為這裡和指明提交注釋的格式如出一轍。 
+我們再次使用了前面定義過的 `export_data`，因為這裡和指定提交注釋的格式如出一轍。 
 
-最後一項工作是回傳當前的標記以便下次迴圈的使用。 
+最後一項工作是回傳目前的標記以便下次迴圈的使用。 
 
 	return mark
 
-注意：如果你是在 Windows 上執行，一定記得添加一項額外的步驟。前面提過，Windows 使用 CRLF 作為換行字元而 Git fast-import 只接受 LF。為了避開這個問題來滿足 git fast-import，你需要讓 ruby 用 LF 取代 CRLF： 
+注意：如果你是在 Windows 上執行，一定記得增加一項額外的步驟。前面提過，Windows 使用 CRLF 作為換行字元而 Git fast-import 只接受 LF。為了避開這個問題來滿足 git fast-import，你需要讓 ruby 用 LF 取代 CRLF： 
 
 	$stdout.binmode
 
@@ -674,7 +674,7 @@ Because you want all your branches and tags to go up, you can now run this:
 
 	    imported from back_2009_02_03
 
-就這樣——一個乾淨整潔的 Git 倉庫。需要注意的是此時沒有任何內容被檢出(checked out)——剛開始目前的目錄裡沒有任何檔。要獲取它們，你得轉到 `master` 分支的所在： 
+就這樣——一個乾淨整潔的 Git 倉庫。需要注意的是此時沒有任何內容被檢出(checked out)——剛開始目前的目錄裡沒有任何檔。要取得它們，你得轉到 `master` 分支的所在： 
 
 	$ ls
 	$ git reset --hard master
@@ -682,7 +682,7 @@ Because you want all your branches and tags to go up, you can now run this:
 	$ ls
 	file.rb  lib
 
-`fast-import` 還可以做更多——處理不同的檔案模式、二進位檔案、多重分支與合併、標籤、進展標識(progress indicators)等等。一些更加複雜的實例可以在 Git 源碼的 `contib/fast-import` 目錄裡找到；較佳的其中之一是前面提過的 `git-p4` 腳本。 
+`fast-import` 還可以做更多——處理不同的檔案模式、二進位檔案、多重分支與合併、標籤、進展標識(progress indicators)等等。一些更加複雜的實例可以在 Git 原始碼的 `contib/fast-import` 目錄裡找到；較佳的其中之一是前面提過的 `git-p4` 腳本。 
 
 ## 總結 ##
 
diff --git a/zh-tw/09-git-internals/01-chapter9.markdown b/zh-tw/09-git-internals/01-chapter9.markdown
index d7fadb1b1..a5b5c0ec8 100644
--- a/zh-tw/09-git-internals/01-chapter9.markdown
+++ b/zh-tw/09-git-internals/01-chapter9.markdown
@@ -14,7 +14,7 @@
 
 本書前八章主要專門討論高層命令。本章將主要討論底層命令以理解 Git 的內部工作機制、演示 Git 如何及為何要以這種方式工作。這些命令主要不是用來從命令列手工使用的，更多的是用來為其他工具和自訂腳本服務的。 
 
-當你在一個新目錄或已有目錄內執行 `git init` 時，Git 會創建一個 `.git` 目錄，幾乎所有 Git 儲存和操作的內容都位於該目錄下。如果你要備份或複製一個倉庫，基本上將這一目錄拷貝至其他地方就可以了。本章基本上都討論該目錄下的內容。該目錄結構如下： 
+當你在一個新目錄或已有目錄內執行 `git init` 時，Git 會建立一個 `.git` 目錄，幾乎所有 Git 保存和操作的內容都位於該目錄下。如果你要備份或複製一個倉庫，基本上將這一目錄拷貝至其他地方就可以了。本章基本上都討論該目錄下的內容。該目錄結構如下： 
 
 	$ ls
 	HEAD
@@ -27,14 +27,14 @@
 	objects/
 	refs/
 
-該目錄下有可能還有其他檔，但這是一個全新的 `git init` 生成的倉庫，所以預設情況下這些就是你能看到的結構。新版本的 Git 不再使用 `branches` 目錄，`description` 檔僅供 GitWeb 程式使用，所以不用關心這些內容。`config` 檔包含了專案特有的配置選項，`info` 目錄保存了一份不希望在 .gitignore 檔中管理的忽略模式 (ignored patterns) 的全域可執行檔。`hooks` 目錄包含了第六章詳細介紹的用戶端或服務端鉤子腳本。 
+該目錄下有可能還有其他檔，但這是一個全新的 `git init` 生成的倉庫，所以預設情況下這些就是你能看到的結構。新版本的 Git 不再使用 `branches` 目錄，`description` 檔僅供 GitWeb 程式使用，所以不用關心這些內容。`config` 檔包含了專案特有的設定選項，`info` 目錄保存了一份不希望在 .gitignore 檔中管理的忽略模式 (ignored patterns) 的全域可執行檔。`hooks` 目錄包含了第六章詳細介紹的用戶端或服務端鉤子腳本。 
 
-另外還有四個重要的檔案或目錄：`HEAD` 及 `index` 檔，`objects` 及 `refs` 目錄。這些是 Git 的核心部分。`objects` 目錄存放所有資料內容，`refs` 目錄存放指向資料 (分支) 的提交物件的指標，`HEAD` 檔指向當前分支，`index` 檔保存了暫存區域資訊。馬上你將詳細瞭解 Git 是如何操縱這些內容的。
+另外還有四個重要的檔案或目錄：`HEAD` 及 `index` 檔，`objects` 及 `refs` 目錄。這些是 Git 的核心部分。`objects` 目錄存放所有資料內容，`refs` 目錄存放指向資料 (分支) 的提交物件的指標，`HEAD` 檔指向目前分支，`index` 檔保存了暫存區域資訊。馬上你將詳細瞭解 Git 是如何操縱這些內容的。
 
 ## Git 物件 ##
 
 Git 是一套內容定址檔案系統。很不錯。不過這是什麼意思呢？
-這種說法的意思是，從內部來看，Git 是簡單的 key-value 資料儲存。它允許插入任意類型的內容，並會回傳一個鍵值，通過該鍵值可以在任何時候再取出該內容。可以通過底層命令 `hash-object` 來示範這點，傳一些資料給該命令，它會將資料保存在 `.git` 目錄並回傳表示這些資料的鍵值。首先初使化一個 Git 倉庫並確認 `objects` 目錄是空的： 
+這種說法的意思是，從內部來看，Git 是簡單的 key-value 資料保存。它允許插入任意類型的內容，並會回傳一個鍵值，通過該鍵值可以在任何時候再取出該內容。可以通過底層命令 `hash-object` 來示範這點，傳一些資料給該命令，它會將資料保存在 `.git` 目錄並回傳表示這些資料的鍵值。首先初使化一個 Git 倉庫並確認 `objects` 目錄是空的： 
 
 	$ mkdir test
 	$ cd test
@@ -47,24 +47,24 @@ Git 是一套內容定址檔案系統。很不錯。不過這是什麼意思呢
 	$ find .git/objects -type f
 	$
 
-Git 初始化了 `objects 目錄`，同時在該目錄下創建了 `pack` 和 `info` 子目錄，但是該目錄下沒有其他常規檔。我們往這個 Git 資料庫裡儲存一些文本：
+Git 初始化了 `objects 目錄`，同時在該目錄下建立了 `pack` 和 `info` 子目錄，但是該目錄下沒有其他常規檔。我們往這個 Git 資料庫裡保存一些文本：
 
 	$ echo 'test content' | git hash-object -w --stdin
 	d670460b4b4aece5915caf5c68d12f560a9fe3e4
 
-參數 `-w` 指示 `hash-object` 命令儲存 (資料) 物件，若不指定這個參數該命令僅僅回傳鍵值。`--stdin` 指定從標準輸入裝置 (stdin) 來讀取內容，若不指定這個參數，`hash-object` 就需要指定一個要儲存的檔案路徑。該命令輸出長度為 40 個字元的校驗和(checksum hash)。這是個 SHA-1 雜湊值──其值為要儲存的資料加上你馬上會瞭解到的一種頭資訊(header)的校驗和。現在可以查看到 Git 已經儲存了資料： 
+參數 `-w` 指示 `hash-object` 命令保存 (資料) 物件，若不指定這個參數該命令僅僅回傳鍵值。`--stdin` 指定從標準輸入裝置 (stdin) 來讀取內容，若不指定這個參數，`hash-object` 就需要指定一個要保存的檔案路徑。該命令輸出長度為 40 個字元的雜湊值(checksum hash)。這是個 SHA-1 雜湊值──其值為要保存的資料加上你馬上會瞭解到的一種頭資訊(header)的雜湊值。現在可以查看到 Git 已經保存了資料： 
 
 	$ find .git/objects -type f
 	.git/objects/d6/70460b4b4aece5915caf5c68d12f560a9fe3e4
 
-可以在 `objects` 目錄下看到一個檔。這便是 Git 儲存資料內容的方式──為每份內容生成一個檔，取得該內容與頭資訊的 SHA-1 校驗和，創建以該校驗和前兩個字元為名稱的子目錄，並以 (校驗和) 剩下 38 個字元為檔命名 (保存至子目錄下)。 
+可以在 `objects` 目錄下看到一個檔案。這便是 Git 保存資料內容的方式──為每份內容生成一個檔案，取得該內容與頭資訊的 SHA-1 雜湊值，建立以該雜湊值前兩個字元為名稱的子目錄，並以 (雜湊值) 剩下 38 個字元為檔命名 (保存至子目錄下)。 
 
 通過 `cat-file` 命令可以將資料內容取回。該命令是查看 Git 對象的瑞士軍刀。傳入 `-p` 參數可以讓 `cat-file` 命令輸出資料內容的類型： 
 
 	$ git cat-file -p d670460b4b4aece5915caf5c68d12f560a9fe3e4
 	test content
 
-可以往 Git 中添加更多內容並取回了。也可以直接添加檔案。比方說可以對一個檔進行簡單的版本控制。首先，創建一個新檔，並把檔案內容儲存到資料庫中：
+可以往 Git 中增加更多內容並取回了。也可以直接增加檔案。比方說可以對一個檔進行簡單的版本控制。首先，建立一個新檔，並把檔案內容保存到資料庫中：
 
 	$ echo 'version 1' > test.txt
 	$ git hash-object -w test.txt
@@ -95,14 +95,14 @@ Git 初始化了 `objects 目錄`，同時在該目錄下創建了 `pack` 和 `i
 	$ cat test.txt
 	version 2
 
-需要記住的是幾個版本的檔 SHA-1 值可能與實際的值不同，其次，儲存的並不是檔案名而僅僅是檔案內容。這種物件類型稱為 blob 。通過傳遞 SHA-1 值給 `cat-file -t` 命令可以讓 Git 返回任何物件的類型： 
+需要記住的是幾個版本的檔 SHA-1 值可能與實際的值不同，其次，保存的並不是檔案名而僅僅是檔案內容。這種物件類型稱為 blob 。通過傳遞 SHA-1 值給 `cat-file -t` 命令可以讓 Git 返回任何物件的類型： 
 
 	$ git cat-file -t 1f7a7a472abf3dd9643fd615f6da379c4acb3e3a
 	blob
 
 ### Tree 物件 ###
 
-接下去來看 tree 物件，tree 物件可以儲存檔案名，同時也允許將一組檔案儲存在一起。Git 以一種類似 UNIX 檔案系統但更簡單的方式來儲存內容。所有內容以 tree 或 blob 物件儲存，其中 tree 物件對應於 UNIX 中的目錄，blob 物件則大致對應於 inodes 或檔案內容。一個單獨的 tree 物件包含一條或多條 tree 記錄，每一條記錄含有一個指向 blob 或子 tree 物件的 SHA-1 指標，並附有該物件的許可權模式 (mode)、類型和檔案名資訊。以 simplegit 專案為例，最新的 tree 可能是這個樣子： 
+接下去來看 tree 物件，tree 物件可以保存檔案名，同時也允許將一組檔案保存在一起。Git 以一種類似 UNIX 檔案系統但更簡單的方式來保存內容。所有內容以 tree 或 blob 物件保存，其中 tree 物件對應於 UNIX 中的目錄，blob 物件則大致對應於 inodes 或檔案內容。一個單獨的 tree 物件包含一條或多條 tree 記錄，每一條記錄含有一個指向 blob 或子 tree 物件的 SHA-1 指標，並附有該物件的許可權模式 (mode)、類型和檔案名資訊。以 simplegit 專案為例，最新的 tree 可能是這個樣子： 
 
 	$ git cat-file -p master^{tree}
 	100644 blob a906cb2a4a904a152e80877d4088654daad0c859      README
@@ -119,14 +119,14 @@ Git 初始化了 `objects 目錄`，同時在該目錄下創建了 `pack` 和 `i
 Insert 18333fig0901.png
 Figure 9-1. Git 物件模型的簡化版
 
-你可以自己創建 tree 。通常 Git 根據你的暫存區域或 index 來創建並寫入一個 tree 。因此要創建一個 tree 物件的話首先要通過將一些檔暫存從而創建一個 index 。可以使用 plumbing 命令 `update-index` 為一個單獨檔 ── test.txt 檔的第一個版本 ──　創建一個 index。通過該命令人工地將 test.txt 檔的首個版本加入到了一個新的暫存區域中。由於該檔原先並不在暫存區域中 (甚至就連暫存區域也還沒被創建出來呢)，必須傳入 `--add` 參數；由於要添加的檔並不在目前的目錄下而是在資料庫中，必須傳入 `--cacheinfo` 參數。同時指定檔案模式，SHA-1 值和檔案名：
+你可以自己建立 tree 。通常 Git 根據你的暫存區域或 index 來建立並寫入一個 tree 。因此要建立一個 tree 物件的話首先要通過將一些檔暫存從而建立一個 index 。可以使用 plumbing 命令 `update-index` 為一個單獨檔 ── test.txt 檔的第一個版本 ──　建立一個 index。通過該命令人工地將 test.txt 檔的首個版本加入到了一個新的暫存區域中。由於該檔原先並不在暫存區域中 (甚至就連暫存區域也還沒被建立出來呢)，必須傳入 `--add` 參數；由於要增加的檔並不在目前的目錄下而是在資料庫中，必須傳入 `--cacheinfo` 參數。同時指定檔案模式，SHA-1 值和檔案名：
 
 	$ git update-index --add --cacheinfo 100644 \
 	  83baae61804e65cc73a7201a7252750c76066a30 test.txt
 
-在本例中，指定了檔案模式為 `100644`，表明這是一個普通檔。其他可用的模式有：`100755` 表示可執行檔，`120000` 表示符號連結(symbolic link)。檔案模式是從一般的 UNIX 檔案模式中參考來的，但是沒有那麼靈活 ── 上述三種模式僅對 Git 中的檔案 (blobs) 有效 (雖然也有其他模式用於目錄和子模組)。 
+在本例中，指定了檔案模式為 `100644`，表示這是一個普通檔。其他可用的模式有：`100755` 表示可執行檔，`120000` 表示符號連結(symbolic link)。檔案模式是從一般的 UNIX 檔案模式中參考來的，但是沒有那麼靈活 ── 上述三種模式僅對 Git 中的檔案 (blobs) 有效 (雖然也有其他模式用於目錄和子模組)。 
 
-現在可以用 `write-tree` 命令將暫存區域的內容寫到一個 tree 物件了。無需 `-w` 參數 ── 如果目標 tree 不存在，呼叫 `write-tree` 會自動根據 index 狀態創建一個 tree 物件。 
+現在可以用 `write-tree` 命令將暫存區域的內容寫到一個 tree 物件了。無需 `-w` 參數 ── 如果目標 tree 不存在，呼叫 `write-tree` 會自動根據 index 狀態建立一個 tree 物件。 
 
 	$ git write-tree
 	d8329fc1cc938780ffdd9f94e0d364e0ea74f579
@@ -138,13 +138,13 @@ Figure 9-1. Git 物件模型的簡化版
 	$ git cat-file -t d8329fc1cc938780ffdd9f94e0d364e0ea74f579
 	tree
 
-再根據 test.txt 的第二個版本以及一個新檔創建一個新 tree 物件： 
+再根據 test.txt 的第二個版本以及一個新檔建立一個新 tree 物件： 
 
 	$ echo 'new file' > new.txt
 	$ git update-index test.txt
 	$ git update-index --add new.txt
 
-這時暫存區域中包含了 test.txt 的新版本及一個新檔 new.txt 。創建 (寫) 該 tree 物件 (將暫存區域或 index 狀態寫入到一個 tree 物件)，然後瞧瞧它的樣子： 
+這時暫存區域中包含了 test.txt 的新版本及一個新檔 new.txt 。建立 (寫) 該 tree 物件 (將暫存區域或 index 狀態寫入到一個 tree 物件)，然後瞧瞧它的樣子： 
 
 	$ git write-tree
 	0155eb4229851634a0f03eb265b69f5a2d56f341
@@ -162,16 +162,16 @@ Figure 9-1. Git 物件模型的簡化版
 	100644 blob fa49b077972391ad58037050f2a75f74e3671e92      new.txt
 	100644 blob 1f7a7a472abf3dd9643fd615f6da379c4acb3e3a      test.txt
 
-如果從剛寫入的新 tree 物件創建一個工作目錄，將得到位於工作目錄頂級的兩個檔和一個名為 `bak` 的子目錄，該子目錄包含了 test.txt 檔的第一個版本。可以將 Git 用來包含這些內容的資料想像成如圖 9-2 所示的樣子。 
+如果從剛寫入的新 tree 物件建立一個工作目錄，將得到位於工作目錄頂級的兩個檔和一個名為 `bak` 的子目錄，該子目錄包含了 test.txt 檔的第一個版本。可以將 Git 用來包含這些內容的資料想像成如圖 9-2 所示的樣子。 
 
 Insert 18333fig0902.png
-Figure 9-2. 當前 Git 資料的內容結構 
+Figure 9-2. 目前 Git 資料的內容結構 
 
 ### Commit 物件 ###
 
 你現在有三個 tree 物件，它們指向了你要跟蹤的專案的不同快照，可是先前的問題依然存在：必須記往三個 SHA-1 值以獲得這些快照。你也沒有關於誰、何時以及為何保存了這些快照的資訊。commit 物件為你保存了這些基本資訊。 
 
-要創建一個 commit 物件，使用 `commit-tree` 命令，指定一個 tree 的 SHA-1，如果有任何前繼提交物件，也可以指定。從你寫的第一個 tree 開始： 
+要建立一個 commit 物件，使用 `commit-tree` 命令，指定一個 tree 的 SHA-1，如果有任何前繼提交物件，也可以指定。從你寫的第一個 tree 開始： 
 
 	$ echo 'first commit' | git commit-tree d8329f
 	fdf4fc3344e67ab068f836878b6c4951e3b15f3d
@@ -185,7 +185,7 @@ Figure 9-2. 當前 Git 資料的內容結構
 
 	first commit
 
-commit 物件格式很簡單：指明了該時間點專案快照的頂層樹物件、作者/提交者資訊 (從 Git 組態設定的 `user.name` 和 `user.email` 中獲得) 以及當前時間戳記、一個空行，以及提交注釋資訊。
+commit 物件格式很簡單：指定了該時間點專案快照的頂層樹物件、作者/提交者資訊 (從 Git 組態設定的 `user.name` 和 `user.email` 中獲得) 以及目前時間戳記、一個空行，以及提交注釋資訊。
 
 接著再寫入另外兩個 commit 物件，每一個都指定其之前的那個 commit 物件： 
 
@@ -194,7 +194,7 @@ commit 物件格式很簡單：指明了該時間點專案快照的頂層樹物
 	$ echo 'third commit'  | git commit-tree 3c4e9c -p cac0cab
 	1a410efbd13591db07496601ebc7a059dd55cfe9
 
-每一個 commit 物件都指向了你創建的樹物件快照。出乎意料的是，現在已經有了真實的 Git 歷史了，所以如果執行 `git log` 命令並指定最後那個 commit 物件的 SHA-1 便可以查看歷史：
+每一個 commit 物件都指向了你建立的樹物件快照。出乎意料的是，現在已經有了真實的 Git 歷史了，所以如果執行 `git log` 命令並指定最後那個 commit 物件的 SHA-1 便可以查看歷史：
 
 	$ git log --stat 1a410e
 	commit 1a410efbd13591db07496601ebc7a059dd55cfe9
@@ -225,7 +225,7 @@ commit 物件格式很簡單：指明了該時間點專案快照的頂層樹物
 	 test.txt |    1 +
 	 1 files changed, 1 insertions(+), 0 deletions(-)
 
-真棒。你剛剛通過使用低級操作而不是那些普通命令創建了一個 Git 歷史。這基本上就是執行 `git add` 和 `git commit` 命令時 Git 進行的工作　──保存修改了的檔案的 blob，更新索引，創建 tree 物件，最後創建 commit 物件，這些 commit 物件指向了頂層 tree 物件以及先前的 commit 物件。這三類 Git 物件 ── blob，tree 以及 commit ── 都各自以檔案的方式保存在 `.git/objects` 目錄下。以下所列是目前為止範例目錄的所有物件，每個物件後面的注釋裡標明了它們保存的內容： 
+真棒。你剛剛通過使用低級操作而不是那些普通命令建立了一個 Git 歷史。這基本上就是執行 `git add` 和 `git commit` 命令時 Git 進行的工作　──保存修改了的檔案的 blob，更新索引，建立 tree 物件，最後建立 commit 物件，這些 commit 物件指向了頂層 tree 物件以及先前的 commit 物件。這三類 Git 物件 ── blob，tree 以及 commit ── 都各自以檔案的方式保存在 `.git/objects` 目錄下。以下所列是目前為止範例目錄的所有物件，每個物件後面的注釋裡標明了它們保存的內容： 
 
 	$ find .git/objects -type f
 	.git/objects/01/55eb4229851634a0f03eb265b69f5a2d56f341 # tree 2
@@ -244,20 +244,20 @@ commit 物件格式很簡單：指明了該時間點專案快照的頂層樹物
 Insert 18333fig0903.png
 Figure 9-3. Git 目錄下的所有物件
 
-### 物件儲存 ###
+### 物件保存 ###
 
-之前我提到當儲存資料內容時，同時會有一個檔頭被儲存起來。我們花些時間來看看 Git 是如何儲存物件的。你將看到如何通過 Ruby 指令碼語言儲存一個 blob 物件 (這裡以字串 “what is up, doc?” 為例) 。使用 `irb` 命令進入 Ruby 互動式模式： 
+之前我提到當保存資料內容時，同時會有一個檔頭被保存起來。我們花些時間來看看 Git 是如何保存物件的。你將看到如何通過 Ruby 指令碼語言保存一個 blob 物件 (這裡以字串 “what is up, doc?” 為例) 。使用 `irb` 命令進入 Ruby 互動式模式： 
 
 	$ irb
 	>> content = "what is up, doc?"
 	=> "what is up, doc?"
 
-Git 以物件類型為起始內容構造一個檔頭，本例中是一個 blob。然後添加一個空格，接著是資料內容的長度，最後是一個空位元組 (null byte)： 
+Git 以物件類型為起始內容構造一個檔頭，本例中是一個 blob。然後增加一個空格，接著是資料內容的長度，最後是一個空位元組 (null byte)： 
 
 	>> header = "blob #{content.length}\0"
 	=> "blob 16\000"
 
-Git 將檔頭與原始資料內容拼接起來，並計算拼接後的新內容的 SHA-1 校驗和。可以在 Ruby 中使用 `require` 語句導入 SHA1 digest 程式庫，然後呼叫 `Digest::SHA1.hexdigest()` 方法計算字串的 SHA-1 值： 
+Git 將檔頭與原始資料內容拼接起來，並計算拼接後的新內容的 SHA-1 雜湊值。可以在 Ruby 中使用 `require` 語句導入 SHA1 digest 程式庫，然後呼叫 `Digest::SHA1.hexdigest()` 方法計算字串的 SHA-1 值： 
 
 	>> store = header + content
 	=> "blob 16\000what is up, doc?"
@@ -273,7 +273,7 @@ Git 用 zlib 對資料內容進行壓縮，在 Ruby 中可以用 zlib 程式庫
 	>> zlib_content = Zlib::Deflate.deflate(store)
 	=> "x\234K\312\311OR04c(\317H,Q\310,V(-\320QH\311O\266\a\000_\034\a\235"
 
-最後將用 zlib 壓縮後的內容寫入磁片。需要指定保存物件的路徑 (SHA-1 值的頭兩個字元作為子目錄名稱，剩餘 38 個字元作為檔案名保存至該子目錄中)。在 Ruby 中，如果子目錄不存在可以用 `FileUtils.mkdir_p()` 函數創建它。接著用 `File.open` 方法打開檔案，並用 `write()` 方法將之前壓縮的內容寫入該檔： 
+最後將用 zlib 壓縮後的內容寫入磁片。需要指定保存物件的路徑 (SHA-1 值的頭兩個字元作為子目錄名稱，剩餘 38 個字元作為檔案名保存至該子目錄中)。在 Ruby 中，如果子目錄不存在可以用 `FileUtils.mkdir_p()` 函數建立它。接著用 `File.open` 方法打開檔案，並用 `write()` 方法將之前壓縮的內容寫入該檔： 
 
 	>> path = '.git/objects/' + sha1[0,2] + '/' + sha1[2,38]
 	=> ".git/objects/bd/9dbf5aae1a3862dd1526723246b20206e5fc37"
@@ -284,13 +284,13 @@ Git 用 zlib 對資料內容進行壓縮，在 Ruby 中可以用 zlib 程式庫
 	>> File.open(path, 'w') { |f| f.write zlib_content }
 	=> 32
 
-這就行了 ── 你已經創建了一個正確的 blob 物件。所有的 Git 物件都以這種方式儲存，惟一的區別是類型不同 ── 除了字串 blob，檔頭起始內容還可以是 commit 或 tree 。不過雖然 blob 幾乎可以是任意內容，commit 和 tree 的資料卻是有固定格式的。 
+這就行了 ── 你已經建立了一個正確的 blob 物件。所有的 Git 物件都以這種方式保存，惟一的區別是類型不同 ── 除了字串 blob，檔頭起始內容還可以是 commit 或 tree 。不過雖然 blob 幾乎可以是任意內容，commit 和 tree 的資料卻是有固定格式的。 
 
 ## Git References ##
 
 你可以執行像 `git log 1a410e` 這樣的命令來查看完整的歷史，但是這樣你就要記得 `1a410e` 是你最後一次提交，這樣才能在提交歷史中找到這些物件。你需要一個檔來用一個簡單的名字來記錄這些 SHA-1 值，這樣你就可以用這些指標而不是原來的 SHA-1 值去檢索了。 
 
-在 Git 中，這些我們稱之為「引用」（references 或者 refs，譯者注）。你可以在 `.git/refs` 目錄下面找到這些包含 SHA-1 值的檔。在這個專案裡，這個目錄還沒不包含任何檔，但是包含這樣一個簡單的結構： 
+在 Git 中，這些我們稱之為「引用」（references 或者 refs，譯者注）。你可以在 `.git/refs` 目錄下面找到這些包含 SHA-1 值的檔案。在這個專案裡，這個目錄還沒不包含任何檔，但是包含這樣一個簡單的結構： 
 
 	$ find .git/refs
 	.git/refs
@@ -299,11 +299,11 @@ Git 用 zlib 對資料內容進行壓縮，在 Ruby 中可以用 zlib 程式庫
 	$ find .git/refs -type f
 	$
 
-如果想要創建一個新的引用幫助你記住最後一次提交，技術上你可以這樣做： 
+如果想要建立一個新的引用幫助你記住最後一次提交，技術上你可以這樣做： 
 
 	$ echo "1a410efbd13591db07496601ebc7a059dd55cfe9" > .git/refs/heads/master
 
-現在，你就可以在 Git 命令中使用你剛才創建的引用而不是 SHA-1 值： 
+現在，你就可以在 Git 命令中使用你剛才建立的引用而不是 SHA-1 值： 
 
 	$ git log --pretty=oneline  master
 	1a410efbd13591db07496601ebc7a059dd55cfe9 third commit
@@ -314,7 +314,7 @@ Git 用 zlib 對資料內容進行壓縮，在 Ruby 中可以用 zlib 程式庫
 
 	$ git update-ref refs/heads/master 1a410efbd13591db07496601ebc7a059dd55cfe9
 
-基本上 Git 中的一個分支其實就是一個指向某個工作版本一條 HEAD 記錄的指標或引用。你可以用這條命令創建一個指向第二次提交的分支： 
+基本上 Git 中的一個分支其實就是一個指向某個工作版本一條 HEAD 記錄的指標或引用。你可以用這條命令建立一個指向第二次提交的分支： 
 
 	$ git update-ref refs/heads/test cac0ca
 
@@ -329,34 +329,34 @@ Git 用 zlib 對資料內容進行壓縮，在 Ruby 中可以用 zlib 程式庫
 Insert 18333fig0904.png
 Figure 9-4. 包含分支引用的 Git 目錄物件 
 
-每當你執行 `git branch (分支名稱)` 這樣的命令，Git 基本上就是執行 `update-ref` 命令，把你現在所在分支中最後一次提交的 SHA-1 值，添加到你要創建的分支的引用。 
+每當你執行 `git branch (分支名稱)` 這樣的命令，Git 基本上就是執行 `update-ref` 命令，把你現在所在分支中最後一次提交的 SHA-1 值，增加到你要建立的分支的引用。 
 
 ### HEAD 標記 ###
 
-現在的問題是，當你執行 `git branch (分支名稱)` 這條命令的時候，Git 怎麼知道最後一次提交的 SHA-1 值呢？答案就是 HEAD 檔。HEAD 檔是一個指向你當前所在分支的引用識別字。這樣的引用識別字——它看起來並不像一個普通的引用——其實並不包含 SHA-1 值，而是一個指向另外一個引用的指標。如果你看一下這個檔，通常你將會看到這樣的內容： 
+現在的問題是，當你執行 `git branch (分支名稱)` 這條命令的時候，Git 怎麼知道最後一次提交的 SHA-1 值呢？答案就是 HEAD 檔。HEAD 檔是一個指向你目前所在分支的引用識別字。這樣的引用識別字——它看起來並不像一個普通的引用——其實並不包含 SHA-1 值，而是一個指向另外一個引用的指標。如果你看一下這個檔案，通常你將會看到這樣的內容： 
 
 	$ cat .git/HEAD
 	ref: refs/heads/master
 
-如果你執行 `git checkout test`，Git 就會更新這個檔，看起來像這樣： 
+如果你執行 `git checkout test`，Git 就會更新這個檔案，看起來像這樣： 
 
 	$ cat .git/HEAD
 	ref: refs/heads/test
 
-當你再執行 `git commit` 命令，它就創建了一個 commit 物件，把這個 commit 物件的父級設置為 HEAD 指向的引用的 SHA-1 值。 
+當你再執行 `git commit` 命令，它就建立了一個 commit 物件，把這個 commit 物件的父級設定為 HEAD 指向的引用的 SHA-1 值。 
 
-你也可以手動編輯這個檔，但是同樣有一個更安全的方法可以這樣做：`symbolic-ref`。你可以用下面這條命令讀取 HEAD 的值： 
+你也可以手動編輯這個檔案，但是同樣有一個更安全的方法可以這樣做：`symbolic-ref`。你可以用下面這條命令讀取 HEAD 的值： 
 
 	$ git symbolic-ref HEAD
 	refs/heads/master
 
-你也可以設置 HEAD 的值： 
+你也可以設定 HEAD 的值： 
 
 	$ git symbolic-ref HEAD refs/heads/test
 	$ cat .git/HEAD
 	ref: refs/heads/test
 
-但是你不能設置成 refs 以外的形式： 
+但是你不能設定成 refs 以外的形式： 
 
 	$ git symbolic-ref HEAD test
 	fatal: Refusing to point HEAD outside of refs/
@@ -369,11 +369,11 @@ Figure 9-4. 包含分支引用的 Git 目錄物件
 
 	$ git update-ref refs/tags/v1.0 cac0cab538b970a37ea1e769cbbde608743bc96d
 
-這就是 lightweight tag 的全部 —— 一個永遠不會發生變化的分支。 annotated tag 要更複雜一點。如果你創建一個 annotated tag，Git 會創建一個 tag 物件，然後寫入一個 reference 指向這個 tag，而不是直接指向 commit。你可以這樣創建一個 annotated tag（`-a` 參數表明這是一個 annotated tag）： 
+這就是 lightweight tag 的全部 —— 一個永遠不會發生變化的分支。 annotated tag 要更複雜一點。如果你建立一個 annotated tag，Git 會建立一個 tag 物件，然後寫入一個 reference 指向這個 tag，而不是直接指向 commit。你可以這樣建立一個 annotated tag（`-a` 參數表示這是一個 annotated tag）： 
 
 	$ git tag -a v1.1 1a410efbd13591db07496601ebc7a059dd55cfe9 –m 'test tag'
 
-這是所創建物件的 SHA-1 值：
+這是所建立物件的 SHA-1 值：
 
 	$ cat .git/refs/tags/v1.1
 	9585191f37f7b0fb9444f35a9bf50de191beadc2
@@ -388,15 +388,15 @@ Figure 9-4. 包含分支引用的 Git 目錄物件
 
 	test tag
 
-值得注意的是這個物件指向你所標記的 commit 物件的 SHA-1 值。同時需要注意的是它並不是必須要指向一個 commit 物件；你可以標記任何 Git 物件。例如，在 Git 的原始程式碼裡，管理者添加了一個 GPG 公開金鑰（這是一個 blob 物件）對它做了一個標籤。你可以執行以下命令來查看 
+值得注意的是這個物件指向你所標記的 commit 物件的 SHA-1 值。同時需要注意的是它並不是必須要指向一個 commit 物件；你可以標記任何 Git 物件。例如，在 Git 的原始程式碼裡，管理者增加了一個 GPG 公開金鑰（這是一個 blob 物件）對它做了一個標籤。你可以執行以下命令來查看 
 
 	$ git cat-file blob junio-gpg-pub
 
-Git 原始程式碼裡的公開金鑰. Linux kernel 也有一個不是指向 commit 物件的 tag —— 第一個 tag 是在導入原始程式碼的時候創建的，它指向初始 tree （initial tree，譯者注）。
+Git 原始程式碼裡的公開金鑰. Linux kernel 也有一個不是指向 commit 物件的 tag —— 第一個 tag 是在導入原始程式碼的時候建立的，它指向初始 tree （initial tree，譯者注）。
 
 ### Remotes ###
 
-你將會看到的第三種 reference 是 remote reference（遠端參照，譯者注）。如果你添加了一個 remote 然後推送代碼過去，Git 會把你最後一次推送到這個 remote 的每個分支的值都記錄在 `refs/remotes` 目錄下。例如，你可以添加一個叫做 `origin` 的 remote 然後把你的 `master` 分支推送上去： 
+你將會看到的第三種 reference 是 remote reference（遠端參照，譯者注）。如果你增加了一個 remote 然後推送代碼過去，Git 會把你最後一次推送到這個 remote 的每個分支的值都記錄在 `refs/remotes` 目錄下。例如，你可以增加一個叫做 `origin` 的 remote 然後把你的 `master` 分支推送上去： 
 
 	$ git remote add origin git@github.com:schacon/simplegit-progit.git
 	$ git push origin master
@@ -407,7 +407,7 @@ Git 原始程式碼裡的公開金鑰. Linux kernel 也有一個不是指向 com
 	To git@github.com:schacon/simplegit-progit.git
 	   a11bef0..ca82a6d  master -> master
 
-然後查看 `refs/remotes/origin/master` 這個檔，你就會發現 `origin` remote 中的 `master` 分支就是你最後一次和伺服器的通信。 
+然後查看 `refs/remotes/origin/master` 這個檔案，你就會發現 `origin` remote 中的 `master` 分支就是你最後一次和伺服器的通訊。 
 
 	$ cat .git/refs/remotes/origin/master
 	ca82a6dff817ec66f44342007202690a93763949
@@ -431,7 +431,7 @@ Remote references 和分支(`refs/heads` references)的主要區別在於他們
 	.git/objects/fa/49b077972391ad58037050f2a75f74e3671e92 # new.txt
 	.git/objects/fd/f4fc3344e67ab068f836878b6c4951e3b15f3d # commit 1
 
-Git 用 zlib 壓縮檔案內容，因此這些檔並沒有佔用太多空間，所有檔加起來總共僅用了 925 位元組。接下去你將添加一些大檔以演示 Git 的一個很有意思的功能。將你之前用到過的 Grit 庫中的 repo.rb 檔加進去 ── 這個原始程式碼檔大小約為 12K： 
+Git 用 zlib 壓縮檔案內容，因此這些檔並沒有佔用太多空間，所有檔加起來總共僅用了 925 位元組。接下去你將增加一些大檔以演示 Git 的一個很有意思的功能。將你之前用到過的 Grit 庫中的 repo.rb 檔加進去 ── 這個原始程式碼檔大小約為 12K： 
 
 	$ curl -L https://raw.github.com/mojombo/grit/master/lib/grit/repo.rb > repo.rb
 	$ git add repo.rb
@@ -493,9 +493,9 @@ blob 物件與之前的已經不同了。這說明雖然只是往一個 400 行
 	.git/objects/pack/pack-7a16e4488ae40c7d2bc56ea2bd43e25212a66c45.idx
 	.git/objects/pack/pack-7a16e4488ae40c7d2bc56ea2bd43e25212a66c45.pack
 
-仍保留著的幾個物件是未被任何 commit 引用的 blob ── 在此例中是你之前創建的 “what is up, doc?” 和 “test content” 這兩個示例 blob。你從沒將他們添加至任何 commit，所以 Git 認為它們是懸而未決的，不會將它們打包進 packfile 。 
+仍保留著的幾個物件是未被任何 commit 引用的 blob ── 在此例中是你之前建立的 “what is up, doc?” 和 “test content” 這兩個示例 blob。你從沒將他們增加至任何 commit，所以 Git 認為它們是懸而未決的，不會將它們打包進 packfile 。 
 
-剩下的檔是新創建的 packfile 以及一個索引。packfile 檔包含了剛才從檔案系統中移除的所有物件。索引檔包含了 packfile 的偏移資訊(offset)，這樣就可以快速定位任意一個指定物件。有意思的是執行 `gc` 命令前磁片上的物件大小約為 8K ，而這個新生成的 packfile 僅為 4K 大小。通過打包物件減少了一半磁片使用空間。 
+剩下的檔是新建立的 packfile 以及一個索引。packfile 檔包含了剛才從檔案系統中移除的所有物件。索引檔包含了 packfile 的偏移資訊(offset)，這樣就可以快速定位任意一個指定物件。有意思的是執行 `gc` 命令前磁片上的物件大小約為 8K ，而這個新生成的 packfile 僅為 4K 大小。通過打包物件減少了一半磁片使用空間。 
 
 Git 是如何做到這點的？Git 打包物件時，會查找命名及尺寸相近的檔，並只保存檔案不同版本之間的差異內容。可以查看一下 packfile ，觀察它是如何節省空間的。`git verify-pack` 命令用於顯示已打包的內容： 
 
@@ -522,18 +522,18 @@ Git 是如何做到這點的？Git 打包物件時，會查找命名及尺寸相
 	chain length = 1: 1 object
 	pack-7a16e4488ae40c7d2bc56ea2bd43e25212a66c45.pack: ok
 
-如果你還記得的話, `9bc1d` 這個 blob 是 repo.rb 檔的第一個版本，這個 blob 引用了 `05408` 這個 blob，即該檔的第二個版本。命令輸出內容的第三欄顯示的是物件大小，可以看到 `05408` 佔用了 12K 空間，而 `9bc1d` 僅為 7 位元組。非常有趣的是第二個版本才是完整保存檔案內容的物件，而第一個版本是以差異方式保存的 ── 這是因為大部分情況下需要快速訪問的是檔案的最新版本。 
+如果你還記得的話, `9bc1d` 這個 blob 是 repo.rb 檔的第一個版本，這個 blob 引用了 `05408` 這個 blob，即該檔的第二個版本。命令輸出內容的第三欄顯示的是物件大小，可以看到 `05408` 佔用了 12K 空間，而 `9bc1d` 僅為 7 位元組。非常有趣的是第二個版本才是完整保存檔案內容的物件，而第一個版本是以差異方式保存的 ── 這是因為大部分情況下需要快速存取的是檔案的最新版本。 
 
 最妙的是可以隨時進行重新封包。Git 自動定期對倉庫進行重新封包以節省空間。當然也可以手動執行 `git gc` 命令來這麼做。 
 
 ## The Refspec ##
 
 這本書讀到這裡，你已經使用過一些簡單的遠端分支到本地引用的映射方式了，這種映射可以更為複雜。
-假設你像這樣添加了一項遠端倉庫： 
+假設你像這樣增加了一項遠端倉庫： 
 
 	$ git remote add origin git@github.com:schacon/simplegit-progit.git
 
-它在你的 `.git/config` 檔中添加了一節，指定了遠程的名稱 (`origin`), 遠程倉庫的 URL 地址，和用於獲取(fetch)操作的 Refspec: 
+它在你的 `.git/config` 檔中增加了一節，指定了遠端的名稱 (`origin`), 遠端倉庫的 URL 地址，和用於取得(fetch)操作的 Refspec: 
 
 	[remote "origin"]
 	       url = git@github.com:schacon/simplegit-progit.git
@@ -541,7 +541,7 @@ Git 是如何做到這點的？Git 打包物件時，會查找命名及尺寸相
 
 Refspec 的格式是一個可選的 `+` 號，接著是 `<src>:<dst>` 的格式，這裡 `<src>` 是遠端上的引用格式， `<dst>` 是將要記錄在本地的引用格式。可選的 `+` 號告訴 Git 在即使不能快速演進(fast-forward)的情況下，也去強制更新它。 
 
-預設情況下 refspec 會被 `git remote add` 命令所自動產生，Git 會獲取遠端伺服器上 `refs/heads/` 下面的所有引用，並將它寫入到本地的 `refs/remotes/origin/`. 所以，如果遠端伺服器上有一個 `master` 分支，你在本地可以通過下面這種方式來取得它的歷史記錄： 
+預設情況下 refspec 會被 `git remote add` 命令所自動產生，Git 會取得遠端伺服器上 `refs/heads/` 下面的所有引用，並將它寫入到本地的 `refs/remotes/origin/`. 所以，如果遠端伺服器上有一個 `master` 分支，你在本地可以通過下面這種方式來取得它的歷史記錄： 
 
 	$ git log origin/master
 	$ git log remotes/origin/master
@@ -557,7 +557,7 @@ Refspec 的格式是一個可選的 `+` 號，接著是 `<src>:<dst>` 的格式
 
 	$ git fetch origin master:refs/remotes/origin/mymaster
 
-你也可以在命令列上指定多個 refspec. 像這樣可以一次獲取遠端的多個分支： 
+你也可以在命令列上指定多個 refspec. 像這樣可以一次取得遠端的多個分支： 
 
 	$ git fetch origin master:refs/remotes/origin/mymaster \
 	   topic:refs/remotes/origin/topic
@@ -567,7 +567,7 @@ Refspec 的格式是一個可選的 `+` 號，接著是 `<src>:<dst>` 的格式
 
 在這個例子中， master 分支因為不是一個可以快速演進的引用而拉取操作被拒絕。你可以在 refspec 之前使用一個 `+` 號來 override 這種行為。 
 
-你也可以在設定檔中指定多個 refspec. 如你想在每次獲取時都獲取 master 和 experiment 分支，就添加兩行： 
+你也可以在設定檔中指定多個 refspec. 如你想在每次取得時都取得 master 和 experiment 分支，就增加兩行： 
 
 	[remote "origin"]
 	       url = git@github.com:schacon/simplegit-progit.git
@@ -578,14 +578,14 @@ Refspec 的格式是一個可選的 `+` 號，接著是 `<src>:<dst>` 的格式
 
 	fetch = +refs/heads/qa*:refs/remotes/origin/qa*
 
-但是你可以使用命名空間來達到這個目的。如果你有一個 QA 團隊，他們推送一系列分支，你想每次獲取 master 分支和 QA 團隊 的所有分支，你可以使用這樣的配置段落(config section)： 
+但是你可以使用命名空間來達到這個目的。如果你有一個 QA 團隊，他們推送一系列分支，你想每次取得 master 分支和 QA 團隊 的所有分支，你可以使用這樣的設定段落(config section)： 
 
 	[remote "origin"]
 	       url = git@github.com:schacon/simplegit-progit.git
 	       fetch = +refs/heads/master:refs/remotes/origin/master
 	       fetch = +refs/heads/qa/*:refs/remotes/origin/qa/*
 
-如果你的工作流程很複雜，有QA團隊推送的分支、開發人員推送的分支、和集成人員推送的分支，並且他們在遠端分支上協作，你可以採用這種方式為他們創建各自的命名空間。 
+如果你的工作流程很複雜，有QA團隊推送的分支、開發人員推送的分支、和整合人員推送的分支，並且他們在遠端分支上協作，你可以採用這種方式為他們建立各自的命名空間。 
 
 ### 推送 Refspecs ###
 
@@ -595,7 +595,7 @@ Refspec 的格式是一個可選的 `+` 號，接著是 `<src>:<dst>` 的格式
 
 	$ git push origin master:refs/heads/qa/master
 
-如果他們想讓 Git 每次運行 `git push origin` 時都這樣自動推送，他們可以在設定檔中添加 `push` 值： 
+如果他們想讓 Git 每次執行 `git push origin` 時都這樣自動推送，他們可以在設定檔中增加 `push` 值： 
 
 	[remote "origin"]
 	       url = git@github.com:schacon/simplegit-progit.git
@@ -618,11 +618,11 @@ Git 可以用兩種主要的方式跨越兩個倉庫傳輸資料：基於 HTTP 
 
 ### 啞協議 ###
 
-Git 基於 HTTP 之上傳輸通常被稱為啞協議，這是因為它在服務端不需要有針對 Git 特有的代碼。這個獲取過程僅僅是一系列 GET 請求，用戶端可以假定服務端的 Git 倉庫中的佈局。讓我們以 simplegit 倉庫為例來看看 `http-fetch` 的過程： 
+Git 基於 HTTP 之上傳輸通常被稱為啞協議，這是因為它在服務端不需要有針對 Git 特有的代碼。這個取得過程僅僅是一系列 GET 請求，用戶端可以假定服務端的 Git 倉庫中的佈局。讓我們以 simplegit 倉庫為例來看看 `http-fetch` 的過程： 
 
 	$ git clone http://github.com/schacon/simplegit-progit.git
 
-它做的第一件事情就是獲取 `info/refs` 檔。這個檔是在服務端運行了 `update-server-info` 所產生的，這也解釋了為什麼在服務端要想使用 HTTP 傳輸，必須要開啟 `post-receive` 鉤子(hook)： 
+它做的第一件事情就是取得 `info/refs` 檔。這個檔是在服務端執行了 `update-server-info` 所產生的，這也解釋了為什麼在服務端要想使用 HTTP 傳輸，必須要開啟 `post-receive` 鉤子(hook)： 
 
 	=> GET info/refs
 	ca82a6dff817ec66f44342007202690a93763949     refs/heads/master
@@ -632,13 +632,13 @@ Git 基於 HTTP 之上傳輸通常被稱為啞協議，這是因為它在服務
 	=> GET HEAD
 	ref: refs/heads/master
 
-這說明在完成獲取後，需要檢出(check out) `master` 分支。
-這時，已經可以開始漫遊操作(walking process)了。因為你的起點是在 `info/refs` 檔中所提到的 `ca82a6` commit 物件，你的開始操作就是獲取它： 
+這說明在完成取得後，需要檢出(check out) `master` 分支。
+這時，已經可以開始漫遊操作(walking process)了。因為你的起點是在 `info/refs` 檔中所提到的 `ca82a6` commit 物件，你的開始操作就是取得它： 
 
 	=> GET objects/ca/82a6dff817ec66f44342007202690a93763949
 	(179 bytes of binary data)
 
-然後你取回了這個物件 － 這在服務端是一個鬆散格式的物件，你使用的是靜態的 HTTP GET 請求獲取的。可以使用 zlib 解壓縮它，去除檔頭，查看它的 commmit 內容： 
+然後你取回了這個物件 － 這在服務端是一個鬆散格式的物件，你使用的是靜態的 HTTP GET 請求取得的。可以使用 zlib 解壓縮它，去除檔頭，查看它的 commmit 內容： 
 
 	$ git cat-file -p ca82a6dff817ec66f44342007202690a93763949
 	tree cfda3bf379e4f8dba8717dee55aab78aef7f4daf
@@ -648,7 +648,7 @@ Git 基於 HTTP 之上傳輸通常被稱為啞協議，這是因為它在服務
 
 	changed the version number
 
-這樣，就得到了兩個需要進一步獲取的物件 － `cfda3b` 是這個 commit 物件所對應的 tree 物件，和 `085bb3` 是它的父物件：
+這樣，就得到了兩個需要進一步取得的物件 － `cfda3b` 是這個 commit 物件所對應的 tree 物件，和 `085bb3` 是它的父物件：
 
 	=> GET objects/08/5bb3bcb608e1e8451d4b2432f8ecbe6306e7e7
 	(179 bytes of data)
@@ -663,7 +663,7 @@ Git 基於 HTTP 之上傳輸通常被稱為啞協議，這是因為它在服務
 	=> GET objects/info/http-alternates
 	(empty file)
 
-如果這回傳了幾個替代倉庫列表，那麼它會去那些地方檢查鬆散格式物件和檔案 － 這是一種在軟體分叉(forks)之間共用物件以節省磁碟的好方法。然而，在這個例子中，沒有替代倉庫。所以你所需要的物件肯定在某個打包檔中。要檢查服務端有哪些打包格式檔，你需要獲取 `objects/info/packs` 檔，這裡面包含有打包檔列表（是的，它也是被 `update-server-info` 所產生的）：
+如果這回傳了幾個替代倉庫列表，那麼它會去那些地方檢查鬆散格式物件和檔案 － 這是一種在軟體分叉(forks)之間共用物件以節省磁碟的好方法。然而，在這個例子中，沒有替代倉庫。所以你所需要的物件肯定在某個打包檔中。要檢查服務端有哪些打包格式檔，你需要取得 `objects/info/packs` 檔，這裡面包含有打包檔列表（是的，它也是被 `update-server-info` 所產生的）：
 
 	=> GET objects/info/packs
 	P pack-816a9b2334da9953e530f27bcac22082a9f5b835.pack
@@ -673,7 +673,7 @@ Git 基於 HTTP 之上傳輸通常被稱為啞協議，這是因為它在服務
 	=> GET objects/pack/pack-816a9b2334da9953e530f27bcac22082a9f5b835.idx
 	(4k of binary data)
 
-現在你有了這個打包檔的索引，你可以看看你要的物件是否在裡面 － 因為索引檔列出了這個打包檔所包含的所有物件的SHA值，和該物件存在於打包檔中的偏移量，所以你只需要簡單地獲取整個打包檔： 
+現在你有了這個打包檔的索引，你可以看看你要的物件是否在裡面 － 因為索引檔列出了這個打包檔所包含的所有物件的SHA值，和該物件存在於打包檔中的偏移量，所以你只需要簡單地取得整個打包檔： 
 
 	=> GET objects/pack/pack-816a9b2334da9953e530f27bcac22082a9f5b835.pack
 	(13k of binary data)
@@ -701,9 +701,9 @@ HTTP 方法是很簡單但效率不是很高。使用智慧協定是傳送資料
 
 #### 上傳資料 ####
 
-為了上傳資料至遠端，Git 使用 `send-pack` 和 `receive-pack` 程序。這個 `send-pack` 程序運行在用戶端上，它連接至遠端運行的 `receive-pack` 程序。 
+為了上傳資料至遠端，Git 使用 `send-pack` 和 `receive-pack` 程序。這個 `send-pack` 程序執行在用戶端上，它連接至遠端執行的 `receive-pack` 程序。 
 
-舉例來說，你在你的專案上執行了 `git push origin master`, 並且 `origin` 被定義為一個使用 SSH 協議的 URL。Git 會使用 `send-pack` 程序，它會啟動一個基於 SSH 的連接(connection)到伺服器。它嘗試像這樣透過 SSH 在服務端運行命令： 
+舉例來說，你在你的專案上執行了 `git push origin master`, 並且 `origin` 被定義為一個使用 SSH 協議的 URL。Git 會使用 `send-pack` 程序，它會啟動一個基於 SSH 的連接(connection)到伺服器。它嘗試像這樣透過 SSH 在服務端執行命令： 
 
 	$ ssh -x git@github.com "git-receive-pack 'schacon/simplegit-progit.git'"
 	005bca82a6dff817ec66f4437202690a93763949 refs/heads/master report-status delete-refs
@@ -720,7 +720,7 @@ HTTP 方法是很簡單但效率不是很高。使用智慧協定是傳送資料
 	00670000000000000000000000000000000000000000 cdfdb42577e2506715f8cfeacdbabc092bf63e8d refs/heads/experiment
 	0000
 
-這裡全部是’0’的SHA-1值表示之前沒有過這個物件 － 因為你是在添加新的 experiment 引用。如果你在刪除一個引用，你會看到相反的： 就是右邊全部是’0’。 
+這裡全部是’0’的SHA-1值表示之前沒有過這個物件 － 因為你是在增加新的 experiment 引用。如果你在刪除一個引用，你會看到相反的： 就是右邊全部是’0’。 
 
 Git 針對每個引用發送這樣一行資訊，就是舊的SHA值，新的SHA值，和將要更新的引用的名稱。第1行還會包含有用戶端的能力。下一步，用戶端會發送一個所有那些服務端所沒有的物件的一個打包檔。最後，服務端以成功(或者失敗)來回應： 
 
@@ -730,13 +730,13 @@ Git 針對每個引用發送這樣一行資訊，就是舊的SHA值，新的SHA
 
 當你在下載資料時，`fetch-pack` 和 `upload-pack` 程序就起作用了。用戶端啟動 `fetch-pack` 程序，連接至遠端的 `upload-pack` 程序，以協商後續資料傳輸過程。 
 
-在遠端倉庫有不同的方式啟動 `upload-pack` 程序。你可以使用與 `receive-pack` 相同的透過 SSH 管道的方式，也可以通過 Git 後臺來啟動這個進程，它預設監聽在 9418 號埠上。這裡 `fetch-pack` 程序在連接後像這樣向後臺發送資料： 
+在遠端倉庫有不同的方式啟動 `upload-pack` 程序。你可以使用與 `receive-pack` 相同的透過 SSH 管道的方式，也可以通過 Git 後臺來啟動這個行程，它預設監聽在 9418 號埠上。這裡 `fetch-pack` 程序在連接後像這樣向後臺發送資料： 
 
 	003fgit-upload-pack schacon/simplegit-progit.git\0host=myserver.com\0
 
 它也是以4位元組指定後續位元組長度的方式開始，然後是要執行的命令，和一個空位元組，然後是服務端的主機名稱，再跟隨一個最後的空位元組。Git 後臺程序會檢查這個命令是否可以執行，以及那個倉庫是否存在，以及是否具有公開許可權。如果所有檢查都通過了，它會啟動這個 `upload-pack` 程序並將用戶端的請求移交給它。 
 
-如果你透過 SSH 使用獲取(fetch)功能，`fetch-pack` 會像這樣運行： 
+如果你透過 SSH 使用取得(fetch)功能，`fetch-pack` 會像這樣執行： 
 
 	$ ssh -x git@github.com "git-upload-pack 'schacon/simplegit-progit.git'"
 
@@ -757,7 +757,7 @@ Git 針對每個引用發送這樣一行資訊，就是舊的SHA值，新的SHA
 	0000
 	0009done
 
-這是傳輸協議的一個很基礎的例子，在更複雜的例子中，用戶端可能會支援 `multi_ack` 或者 `side-band` 能力；但是這個例子中展示了智慧協議的基本交互過程。 
+這是傳輸協議的一個很基礎的例子，在更複雜的例子中，用戶端可能會支援 `multi_ack` 或者 `side-band` 能力；但是這個例子中示範了智慧協議的基本交互過程。 
 
 ## 維護及資料復原 ##
 
@@ -771,7 +771,7 @@ Git 會不定時地自動執行稱為「auto gc」的命令。大部分情況下
 
 	$ git gc --auto
 
-再次強調，這個命令一般什麼都不幹。如果有 7,000 個左右的鬆散對象或是 50 個以上的 packfile，Git 才會真正觸發 gc 命令。你可以修改配置中的 `gc.auto` 和 `gc.autopacklimit` 來調整這兩個設定值。 
+再次強調，這個命令一般什麼都不幹。如果有 7,000 個左右的鬆散對象或是 50 個以上的 packfile，Git 才會真正觸發 gc 命令。你可以修改設定中的 `gc.auto` 和 `gc.autopacklimit` 來調整這兩個設定值。 
 
 `gc` 還會將所有引用 (references) 併入一個單獨檔。假設倉庫中包含以下分支和標籤： 
 
@@ -791,7 +791,7 @@ Git 會不定時地自動執行稱為「auto gc」的命令。大部分情況下
 	9585191f37f7b0fb9444f35a9bf50de191beadc2 refs/tags/v1.1
 	^1a410efbd13591db07496601ebc7a059dd55cfe9
 
-當更新一個引用時，Git 不會修改這個檔，而是在 `refs/heads` 下寫入一個新檔。當查找一個引用的 SHA 時，Git 首先在 `refs` 目錄下查找，如果未找到則到 `packed-refs` 檔中去查找。因此如果在 `refs` 目錄下找不到一個引用，該引用可能存到 `packed-refs` 檔中去了。 
+當更新一個引用時，Git 不會修改這個檔案，而是在 `refs/heads` 下寫入一個新檔。當查找一個引用的 SHA 時，Git 首先在 `refs` 目錄下查找，如果未找到則到 `packed-refs` 檔中去查找。因此如果在 `refs` 目錄下找不到一個引用，該引用可能存到 `packed-refs` 檔中去了。 
 
 請留意檔最後以 `^` 開頭的那一行。這表示該行上一行的那個標籤是一個 annotated 標籤，而該行正是那個標籤所指向的 commit 。
 
@@ -799,7 +799,7 @@ Git 會不定時地自動執行稱為「auto gc」的命令。大部分情況下
 
 在使用 Git 的過程中，有時會不小心丟失 commit 資訊。這一般出現在以下情況下：強制刪除了一個分支而後又想重新使用這個分支，hard-reset 了一個分支從而丟棄了分支的部分 commit。如果這真的發生了，有什麼辦法把丟失的 commit 找回來呢？ 
 
-下面的例子演示了對 test 倉庫 master 分支進行 hard-reset 到一個老版本的 commit 的操作，然後恢復丟失的 commit 。首先查看一下當前的倉庫狀態： 
+下面的例子演示了對 test 倉庫 master 分支進行 hard-reset 到一個老版本的 commit 的操作，然後恢復丟失的 commit 。首先查看一下目前的倉庫狀態： 
 
 	$ git log --pretty=oneline
 	ab1afef80fac8e34258ff41fc1b867c702daa24b modified repo a bit
@@ -817,9 +817,9 @@ Git 會不定時地自動執行稱為「auto gc」的命令。大部分情況下
 	cac0cab538b970a37ea1e769cbbde608743bc96d second commit
 	fdf4fc3344e67ab068f836878b6c4951e3b15f3d first commit
 
-這樣就丟棄了最新的兩個 commit ── 包含這兩個 commit 的分支不存在了。現在要做的是找出最新的那個 commit 的 SHA，然後添加一個指向它的分支。關鍵在於找出最新的 commit 的 SHA ── 你不大可能記住了這個 SHA，是吧？ 
+這樣就丟棄了最新的兩個 commit ── 包含這兩個 commit 的分支不存在了。現在要做的是找出最新的那個 commit 的 SHA，然後增加一個指向它的分支。關鍵在於找出最新的 commit 的 SHA ── 你不大可能記住了這個 SHA，是吧？ 
 
-通常最快捷的辦法是使用 `git reflog` 工具。當你 (在一個倉庫下) 工作時，Git 會在你每次修改了 HEAD 時悄悄地將改動記錄下來。當你提交或修改分支時，reflog 就會更新。`git update-ref` 命令也可以更新 reflog，這是在本章前面的 “Git References” 部分我們使用該命令而不是手工將 SHA 值寫入 ref 文件的理由。任何時間執行 `git reflog` 命令可以查看當前的狀態： 
+通常最快速的辦法是使用 `git reflog` 工具。當你 (在一個倉庫下) 工作時，Git 會在你每次修改了 HEAD 時悄悄地將改動記錄下來。當你提交或修改分支時，reflog 就會更新。`git update-ref` 命令也可以更新 reflog，這是在本章前面的 “Git References” 部分我們使用該命令而不是手工將 SHA 值寫入 ref 文件的理由。任何時間執行 `git reflog` 命令可以查看目前的狀態： 
 
 	$ git reflog
 	1a410ef HEAD@{0}: 1a410efbd13591db07496601ebc7a059dd55cfe9: updating HEAD
@@ -844,7 +844,7 @@ Git 會不定時地自動執行稱為「auto gc」的命令。大部分情況下
 
 	     modified repo a bit
 
-看起來弄丟了的 commit 是底下那個，這樣在那個 commit 上創建一個新分支就能把它恢復過來。比方說，可以在那個 commit (ab1afef) 上創建一個名為 `recover-branch` 的分支： 
+看起來弄丟了的 commit 是底下那個，這樣在那個 commit 上建立一個新分支就能把它恢復過來。比方說，可以在那個 commit (ab1afef) 上建立一個名為 `recover-branch` 的分支： 
 
 	$ git branch recover-branch ab1afef
 	$ git log --pretty=oneline recover-branch
@@ -868,11 +868,11 @@ Git 會不定時地自動執行稱為「auto gc」的命令。大部分情況下
 	dangling tree aea790b9a58f6cf6f2804eeac9f0abbe9631e4c9
 	dangling blob 7108f7ecb345ee9d0084193f147cdad4d2998293
 
-本例中，可以從 dangling commit 找到丟失了的 commit。用相同的方法就可以恢復它，即創建一個指向該 SHA 的分支。 
+本例中，可以從 dangling commit 找到丟失了的 commit。用相同的方法就可以恢復它，即建立一個指向該 SHA 的分支。 
 
 ### 移除物件 ###
 
-Git 有許多過人之處，不過有一個功能有時卻會帶來問題：`git clone` 會將包含每一個檔的所有歷史版本的整個專案下載下來。如果專案包含的僅僅是原始程式碼的話這並沒有什麼壞處，畢竟 Git 可以非常高效地壓縮此類資料。不過如果有人在某個時刻往專案中添加了一個非常大的檔，即便他在後來的提交中將此檔刪掉了，所有的簽出都會下載這個大檔。因為歷史記錄中引用了這個檔，它會一直存在著。 
+Git 有許多過人之處，不過有一個功能有時卻會帶來問題：`git clone` 會將包含每一個檔的所有歷史版本的整個專案下載下來。如果專案包含的僅僅是原始程式碼的話這並沒有什麼壞處，畢竟 Git 可以非常高效地壓縮此類資料。不過如果有人在某個時刻往專案中增加了一個非常大的檔，即便他在後來的提交中將此檔刪掉了，所有的簽出都會下載這個大檔。因為歷史記錄中引用了這個檔案，它會一直存在著。 
 
 當你將 Subversion 或 Perforce 倉庫轉換導入至 Git 時這會成為一個很嚴重的問題。在此類系統中，(簽出時) 不會下載整個倉庫歷史，所以這種情形不大會有不良後果。如果你從其他系統導入了一個倉庫，或是發覺一個倉庫的尺寸遠超出預計，可以用下面的方法找到並移除大 (尺寸) 物件。 
 
@@ -918,14 +918,14 @@ Git 有許多過人之處，不過有一個功能有時卻會帶來問題：`git
 
 `size-pack` 是以 KB 為單位表示的 packfiles 的大小，因此已經使用了 2MB 。而在這次提交之前僅用了 2K 左右 ── 顯然在這次提交時刪除檔並沒有真正將其從歷史記錄中刪除。每當有人複製這個倉庫去取得這個小專案時，都不得不複製所有 2MB 資料，而這僅僅因為你曾經不小心加了個大檔。讓我們來解決這個問題。 
 
-首先要找出這個檔。在本例中，你知道是哪個文件。假設你並不知道這一點，要如何找出哪個 (些) 文件佔用了這麼多的空間？如果執行 `git gc`，所有物件會存入一個 packfile 檔；執行另一個底層命令 `git verify-pack` 以識別出大物件，對輸出的第三欄資訊即檔案大小進行排序，還可以將輸出定向(pipe)到 `tail` 命令，因為你只關心排在最後的那幾個最大的檔： 
+首先要找出這個檔案。在本例中，你知道是哪個文件。假設你並不知道這一點，要如何找出哪個 (些) 文件佔用了這麼多的空間？如果執行 `git gc`，所有物件會存入一個 packfile 檔；執行另一個底層命令 `git verify-pack` 以識別出大物件，對輸出的第三欄資訊即檔案大小進行排序，還可以將輸出定向(pipe)到 `tail` 命令，因為你只關心排在最後的那幾個最大的檔： 
 
 	$ git verify-pack -v .git/objects/pack/pack-3f8c0...bb.idx | sort -k 3 -n | tail -3
 	e3f094f522629ae358806b17daf78246c27c007b blob   1486 734 4667
 	05408d195263d853f09dca71d55116663690c27c blob   12908 3478 1189
 	7a9eb2fba2b1811321254ac360970fc169ba2330 blob   2056716 2056872 5401
 
-最底下那個就是那個大檔：2MB 。要查看這到底是哪個檔，可以使用第 7 章中已經簡單使用過的 `rev-list` 命令。若給 `rev-list` 命令傳入 `--objects` 選項，它會列出所有 commit SHA 值，blob SHA 值及相應的檔路徑。可以這樣查看 blob 的檔案名： 
+最底下那個就是那個大檔：2MB 。要查看這到底是哪個檔案，可以使用第 7 章中已經簡單使用過的 `rev-list` 命令。若給 `rev-list` 命令傳入 `--objects` 選項，它會列出所有 commit SHA 值，blob SHA 值及相應的檔路徑。可以這樣查看 blob 的檔案名： 
 
 	$ git rev-list --objects --all | grep 7a9eb2fb
 	7a9eb2fba2b1811321254ac360970fc169ba2330 git.tbz2
@@ -946,7 +946,7 @@ Git 有許多過人之處，不過有一個功能有時卻會帶來問題：`git
 
 `--index-filter` 選項類似於第 6 章中使用的 `--tree-filter` 選項，但這裡不是傳入一個命令去修改磁碟上 checked out 的檔，而是修改暫存區域或索引。不能用 `rm file` 命令來刪除一個特定檔，而是必須用 `git rm --cached` 來刪除它 ── 也就是說，從索引而不是從磁碟上刪除它。這樣做是出於速度考慮 ── 由於 Git 在執行你的 filter 之前無需將所有版本簽出到磁片上，這個操作會快得多。也可以用 `--tree-filter` 來完成相同的操作。`git rm` 的 `--ignore-unmatch` 選項指定當你試圖刪除的內容並不存在時不顯示錯誤。最後，因為你清楚問題是從哪個 commit 開始的，使用 `filter-branch` 重寫自 `6df7640` 這個 commit 開始的所有歷史記錄。不這麼做的話會重寫所有歷史記錄，花費不必要的更多時間。 
 
-現在歷史記錄中已經不包含對那個檔的引用了。不過 reflog 以及執行 `filter-branch` 時 Git 往 `.git/refs/original` 添加的一些 refs 中仍有對它的引用，因此需要將這些引用刪除並對倉庫進行 repack 操作。在進行 repack 前需要將所有對這些 commits 的引用去除： 
+現在歷史記錄中已經不包含對那個檔的引用了。不過 reflog 以及執行 `filter-branch` 時 Git 往 `.git/refs/original` 增加的一些 refs 中仍有對它的引用，因此需要將這些引用刪除並對倉庫進行 repack 操作。在進行 repack 前需要將所有對這些 commits 的引用去除： 
 
 	$ rm -Rf .git/refs/original
 	$ rm -Rf .git/logs/
@@ -968,7 +968,7 @@ Git 有許多過人之處，不過有一個功能有時卻會帶來問題：`git
 	prune-packable: 0
 	garbage: 0
 
-repack 後倉庫的大小減小到了 7K ，遠小於之前的 2MB 。從 size 值可以看出大檔物件還在鬆散物件中，其實並沒有消失，不過這沒有關係，重要的是在再進行推送或複製，這個物件不會再傳送出去。如果真的要完全把這個物件刪除，可以運行 `git prune --expire` 命令。 
+repack 後倉庫的大小減小到了 7K ，遠小於之前的 2MB 。從 size 值可以看出大檔物件還在鬆散物件中，其實並沒有消失，不過這沒有關係，重要的是在再進行推送或複製，這個物件不會再傳送出去。如果真的要完全把這個物件刪除，可以執行 `git prune --expire` 命令。 
 
 ## 總結 ##
 

From 773398477f78d1e9ec5a8d117604c0d6f707662d Mon Sep 17 00:00:00 2001
From: "william.lee" <william.lee@realtek.com>
Date: Fri, 17 Apr 2015 15:14:38 +0800
Subject: [PATCH 677/690] Fix "makepdfs zh-tw" error, remove reduntant bytes in
 chapter 7

---
 zh-tw/07-customizing-git/01-chapter7.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/zh-tw/07-customizing-git/01-chapter7.markdown b/zh-tw/07-customizing-git/01-chapter7.markdown
index a5ead4413..3562f7ee8 100644
--- a/zh-tw/07-customizing-git/01-chapter7.markdown
+++ b/zh-tw/07-customizing-git/01-chapter7.markdown
@@ -1,4 +1,4 @@
-# Git 客製化 #
+# Git 客製化 #
 
 到目前為止，我闡述了 Git 基本的運作機制和使用方式，介紹了 Git 提供的許多工具來幫助你簡單且有效地使用它。在本章，我將會介紹 Git 的一些重要的組態設定(configuration)和鉤子(hooks)機制以滿足自訂的要求。通過這些工具，它能夠更容易地使 Git 按照你、你的公司或團隊所需要的方式去運作。 
 

From 9c147eea17c62c8864882d4c001c6510fdce1810 Mon Sep 17 00:00:00 2001
From: Alan Wang <alan.wang@csr.com>
Date: Mon, 25 May 2015 14:47:15 +0800
Subject: [PATCH 678/690] Update 08-git-and-other-scms

Correct some typos
---
 zh/08-git-and-other-scms/01-chapter8.markdown | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/zh/08-git-and-other-scms/01-chapter8.markdown b/zh/08-git-and-other-scms/01-chapter8.markdown
index 0110dde53..dba2e0619 100644
--- a/zh/08-git-and-other-scms/01-chapter8.markdown
+++ b/zh/08-git-and-other-scms/01-chapter8.markdown
@@ -129,7 +129,7 @@ Git 中所有 Subversion 桥接命令的基础是 `git svn` 。所有的命令
 	No changes between current HEAD and refs/remotes/trunk
 	Resetting to the latest refs/remotes/trunk
 
-所有在原 Subversion 数据基础上提交的 commit 会一一提交到 Subversion，然后你本地 Git 的 commit 将被重写，加入一个特别标识。这一步很重要，因为它意味着所有 commit 的 SHA-1 指都会发生变化。这也是同时使用 Git 和 Subversion 两种服务作为远程服务不是个好主意的原因之一。检视以下最后一个 commit，你会找到新添加的 `git-svn-id` （译注：即本段开头所说的特别标识）：
+所有在原 Subversion 数据基础上提交的 commit 会一一提交到 Subversion，然后你本地 Git 的 commit 将被重写，加入一个特别标识。这一步很重要，因为它意味着所有 commit 的 SHA-1 值都会发生变化。这也是同时使用 Git 和 Subversion 两种服务作为远程服务不是个好主意的原因之一。检视以下最后一个 commit，你会找到新添加的 `git-svn-id` （译注：即本段开头所说的特别标识）：
 
 	$ git log -1
 	commit 938b1a547c2cc92033b74d32030e86468294a5c8
@@ -152,7 +152,7 @@ Git 中所有 Subversion 桥接命令的基础是 `git svn` 。所有的命令
 	out-of-date: resource out of date; try updating at /Users/schacon/libexec/git-\
 	core/git-svn line 482
 
-为了解决该问题，可以运行 `git svn rebase` ，它会拉取服务器上所有最新的改变，再次基础上衍合你的修改：
+为了解决该问题，可以运行 `git svn rebase` ，它会拉取服务器上所有最新的改变，在此基础上衍合你的修改：
 
 	$ git svn rebase
 	       M      README.txt
@@ -160,7 +160,7 @@ Git 中所有 Subversion 桥接命令的基础是 `git svn` 。所有的命令
 	First, rewinding head to replay your work on top of it...
 	Applying: first user change
 
-现在，你做出的修改都发生在服务器内容之后，所以可以顺利的运行 `dcommit` ：
+现在，你做出的修改都发生在服务器最新内容之后，所以可以顺利的运行 `dcommit` ：
 
 	$ git svn dcommit
 	Committing to file:///tmp/test-svn/trunk ...
@@ -339,7 +339,7 @@ Git 通过搜寻提交历史中 Subversion 分支的头部来决定 dcommit 的
 `git svn` 工具集在当前不得不使用 Subversion 服务器或者开发环境要求使用 Subversion 服务器的时候格外有用。不妨把它看成一个跛脚的 Git，然而，你还是有可能在转换过程中碰到一些困惑你和合作者们的迷题。为了避免麻烦，试着遵守如下守则：
 
 * 保持一个不包含由 `git merge` 生成的 commit 的线性提交历史。将在主线分支外进行的开发通通衍合回主线；避免直接合并。
-* 不要单独建立和使用一个 Git 服务来搞合作。可以为了加速新开发者的克隆进程建立一个，但是不要向它提供任何不包含 `git-svn-id` 条目的内容。甚至可以添加一个 `pre-receive` 挂钩来在每一个提交信息中查找 `git-svn-id` 并拒绝提交那些不包含它的 commit。
+* 不要单独建立和使用一个 Git 服务器来搞合作。可以为了加速新开发者的克隆进程建立一个，但是不要向它提供任何不包含 `git-svn-id` 条目的内容。甚至可以添加一个 `pre-receive` 挂钩来在每一个提交信息中查找 `git-svn-id` 并拒绝提交那些不包含它的 commit。
 
 如果遵循这些守则，在 Subversion 上工作还可以接受。然而，如果能迁徙到真正的 Git 服务器，则能为团队带来更多好处。
 
@@ -367,7 +367,7 @@ Git 通过搜寻提交历史中 Subversion 分支的头部来决定 dcommit 的
 
 它将输出 XML 格式的日志——你可以找到作者，建立一个单独的列表，然后从 XML 中抽取出需要的信息。（显而易见，本方法要求主机上安装了`grep`，`sort` 和 `perl`.）然后把输出重定向到 user.txt 文件，然后就可以在每一项的后面添加相应的 Git 用户数据。
 
-为 `git svn` 提供该文件可以然它更精确的映射作者数据。你还可以在 `clone` 或者 `init`后面添加 `--no-metadata` 来阻止 `git svn` 包含那些 Subversion 的附加信息。这样 `import` 命令就变成了：
+为 `git svn` 提供该文件可以让它更精确的映射作者数据。你还可以在 `clone` 或者 `init`后面添加 `--no-metadata` 来阻止 `git svn` 包含那些 Subversion 的附加信息。这样 `import` 命令就变成了：
 
 	$ git svn clone http://my-project.googlecode.com/svn/ \
 	      --authors-file=users.txt --no-metadata -s my_project
@@ -579,7 +579,7 @@ Git 通过搜寻提交历史中 Subversion 分支的头部来决定 dcommit 的
 	  inline_data(file)
 	end
 
-注意：由于很多系统把每次修订看作一个 commit 到另一个 commit 的变化量，fast-import 也可以依据每次提交获取一个命令来指出哪些文件被添加，删除或者修改过，以及修改的内容。我们将需要计算快照之间的差别并且仅仅给出这项数据，不过该做法要复杂很多——还如不直接把所有数据丢给 Git 然它自己搞清楚。假如前面这个方法更适用于你的数据，参考 `fast-import` 的 man 帮助页面来了解如何以这种方式提供数据。
+注意：由于很多系统把每次修订看作一个 commit 到另一个 commit 的变化量，fast-import 也可以依据每次提交获取一个命令来指出哪些文件被添加，删除或者修改过，以及修改的内容。我们将需要计算快照之间的差别并且仅仅给出这项数据，不过该做法要复杂很多——还不如直接把所有数据丢给 Git 让它自己搞清楚。假如前面这个方法更适用于你的数据，参考 `fast-import` 的 man 帮助页面来了解如何以这种方式提供数据。
 
 列举新文件内容或者指明带有新内容的已修改文件的格式如下：
 
@@ -686,4 +686,4 @@ Git 通过搜寻提交历史中 Subversion 分支的头部来决定 dcommit 的
 
 ## 总结 ##
 
-现在的你应该掌握了在 Subversion 上使用 Git 以及把几乎任何先存仓库无损失的导入为 Git 仓库。下一章将介绍 Git 内部的原始数据格式，从而是使你能亲手锻造其中的每一个字节，如果必要的话。
+现在的你应该掌握了在 Subversion 上使用 Git 以及把几乎任何现存仓库无损失的导入为 Git 仓库。下一章将介绍 Git 内部的原始数据格式，从而是使你能亲手锻造其中的每一个字节，如果必要的话。

From 44c854bc0afd38cd7c1e0e56bd4af9617a28c98f Mon Sep 17 00:00:00 2001
From: Alan Wang <alan_t@foxmail.com>
Date: Mon, 25 May 2015 19:36:18 +0800
Subject: [PATCH 679/690] Update 09-git-internals

Correct some typos
---
 zh/09-git-internals/01-chapter9.markdown | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/zh/09-git-internals/01-chapter9.markdown b/zh/09-git-internals/01-chapter9.markdown
index 5b4e631bb..4b0f72490 100644
--- a/zh/09-git-internals/01-chapter9.markdown
+++ b/zh/09-git-internals/01-chapter9.markdown
@@ -185,7 +185,7 @@ Insert 18333fig0902.png
 
 	first commit
 
-commit 对象有格式很简单：指明了该时间点项目快照的顶层树对象、作者/提交者信息（从 Git 设置的 `user.name` 和 `user.email`中获得)以及当前时间戳、一个空行，以及提交注释信息。
+commit 对象的格式很简单：指明了该时间点项目快照的顶层树对象、作者/提交者信息（从 Git 设置的 `user.name` 和 `user.email`中获得)以及当前时间戳、一个空行，以及提交注释信息。
 
 接着再写入另外两个 commit 对象，每一个都指定其之前的那个 commit 对象：
 
@@ -246,7 +246,7 @@ Insert 18333fig0903.png
 
 ### 对象存储 ###
 
-之前我提到当存储数据内容时，同时会有一个文件头被存储起来。我们花些时间来看看 Git 是如何存储对象的。你将看来如何通过 Ruby 脚本语言存储一个 blob 对象 (这里以字符串 "what is up, doc?" 为例) 。使用 `irb` 命令进入 Ruby 交互式模式：
+之前我提到当存储数据内容时，同时会有一个文件头被存储起来。我们花些时间来看看 Git 是如何存储对象的。你将看到如何通过 Ruby 脚本语言存储一个 blob 对象 (这里以字符串 "what is up, doc?" 为例) 。使用 `irb` 命令进入 Ruby 交互式模式：
 
 	$ irb
 	>> content = "what is up, doc?"
@@ -365,11 +365,11 @@ Insert 18333fig0904.png
 
 你刚刚已经重温过了 Git 的三个主要对象类型，现在这是第四种。Tag 对象非常像一个 commit 对象——包含一个标签，一组数据，一个消息和一个指针。最主要的区别就是 Tag 对象指向一个 commit 而不是一个 tree。它就像是一个分支引用，但是不会变化——永远指向同一个 commit，仅仅是提供一个更加友好的名字。
 
-正如我们在第二章所讨论的，Tag 有两种类型：annotated 和 lightweight 。你可以类似下面这样的命令建立一个 lightweight tag：
+正如我们在第二章所讨论的，Tag 有两种类型：annotated 和 lightweight 。你可以用类似下面这样的命令建立一个 lightweight tag：
 
 	$ git update-ref refs/tags/v1.0 cac0cab538b970a37ea1e769cbbde608743bc96d
 
-这就是 lightweight tag 的全部 —— 一个永远不会发生变化的分支。 annotated tag 要更复杂一点。如果你创建一个 annotated tag，Git 会创建一个 tag 对象，然后写入一个指向指向它而不是直接指向 commit 的 reference。你可以这样创建一个 annotated tag（`-a` 参数表明这是一个 annotated tag）：
+这就是 lightweight tag 的全部 —— 一个永远不会发生变化的分支。 annotated tag 要更复杂一点。如果你创建一个 annotated tag，Git 会创建一个 tag 对象，然后写入一个指向它而不是直接指向 commit 的 reference。你可以这样创建一个 annotated tag（`-a` 参数表明这是一个 annotated tag）：
 
 	$ git tag -a v1.1 1a410efbd13591db07496601ebc7a059dd55cfe9 -m 'test tag'
 
@@ -817,7 +817,7 @@ Git 会不定时地自动运行称为 "auto gc" 的命令。大部分情况下
 	cac0cab538b970a37ea1e769cbbde608743bc96d second commit
 	fdf4fc3344e67ab068f836878b6c4951e3b15f3d first commit
 
-这样就丢弃了最新的两个 commit ── 包含这两个 commit 的分支不存在了。现在要做的是找出最新的那个 commit 的 SHA，然后添加一个指它它的分支。关键在于找出最新的 commit 的 SHA ── 你不大可能记住了这个 SHA，是吧？
+这样就丢弃了最新的两个 commit ── 包含这两个 commit 的分支不存在了。现在要做的是找出最新的那个 commit 的 SHA，然后添加一个指向它的分支。关键在于找出最新的 commit 的 SHA ── 你不大可能记住了这个 SHA，是吧？
 
 通常最快捷的办法是使用 `git reflog` 工具。当你 (在一个仓库下) 工作时，Git 会在你每次修改了 HEAD 时悄悄地将改动记录下来。当你提交或修改分支时，reflog 就会更新。`git update-ref` 命令也可以更新 reflog，这是在本章前面的 "Git References" 部分我们使用该命令而不是手工将 SHA 值写入 ref 文件的理由。任何时间运行 `git reflog` 命令可以查看当前的状态：
 

From c18240eec30e733c3dc7b5eb405c652bd6c5e4be Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=E7=8B=82=E9=A3=99?= <zzjbcn@gmail.com>
Date: Tue, 16 Jun 2015 16:18:39 +0800
Subject: [PATCH 680/690] =?UTF-8?q?change=20all=20"=E8=A1=8D=E5=90=88"=20t?=
 =?UTF-8?q?o=20"=E5=8F=98=E5=9F=BA"?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 zh/03-git-branching/01-chapter3.markdown | 48 ++++++++++++------------
 1 file changed, 24 insertions(+), 24 deletions(-)

diff --git a/zh/03-git-branching/01-chapter3.markdown b/zh/03-git-branching/01-chapter3.markdown
index 56cb8b96b..ee91c1408 100644
--- a/zh/03-git-branching/01-chapter3.markdown
+++ b/zh/03-git-branching/01-chapter3.markdown
@@ -478,11 +478,11 @@ Insert 18333fig0326.png
 
 咚！服务器上的分支没了。你最好特别留心这一页，因为你一定会用到那个命令，而且你很可能会忘掉它的语法。有种方便记忆这条命令的方法：记住我们不久前见过的 `git push [远程名] [本地分支]:[远程分支]` 语法，如果省略 `[本地分支]`，那就等于是在说“在这里提取空白然后把它变成`[远程分支]`”。
 
-## 分支的衍合 ##
+## 分支的变基 ##
 
-把一个分支中的修改整合到另一个分支的办法有两种：`merge` 和 `rebase`（译注：`rebase` 的翻译暂定为“衍合”，大家知道就可以了。）。在本章我们会学习什么是衍合，如何使用衍合，为什么衍合操作如此富有魅力，以及我们应该在什么情况下使用衍合。
+把一个分支中的修改整合到另一个分支的办法有两种：`merge` 和 `rebase`。在本章我们会学习什么是变基，如何使用变基，为什么变基操作如此富有魅力，以及我们应该在什么情况下使用变基。
 
-### 基本的衍合操作 ###
+### 基本的变基操作 ###
 
 请回顾之前有关合并的一节（见图 3-27），你会看到开发进程分叉到两个不同分支，又各自提交了更新。
 
@@ -494,7 +494,7 @@ Insert 18333fig0327.png
 Insert 18333fig0328.png
 图 3-28. 通过合并一个分支来整合分叉了的历史。
 
-其实，还有另外一个选择：你可以把在 C3 里产生的变化补丁在 C4 的基础上重新打一遍。在 Git 里，这种操作叫做_衍合（rebase）_。有了 `rebase` 命令，就可以把在一个分支里提交的改变移到另一个分支里重放一遍。
+其实，还有另外一个选择：你可以把在 C3 里产生的变化补丁在 C4 的基础上重新打一遍。在 Git 里，这种操作叫做_变基（rebase）_。有了 `rebase` 命令，就可以把在一个分支里提交的改变移到另一个分支里重放一遍。
 
 在上面这个例子中，运行：
 
@@ -503,7 +503,7 @@ Insert 18333fig0328.png
 	First, rewinding head to replay your work on top of it...
 	Applying: added staged command
 
-它的原理是回到两个分支最近的共同祖先，根据当前分支（也就是要进行衍合的分支 `experiment`）后续的历次提交对象（这里只有一个 C3），生成一系列文件补丁，然后以基底分支（也就是主干分支 `master`）最后一个提交对象（C4）为新的出发点，逐个应用之前准备好的补丁文件，最后会生成一个新的合并提交对象（C3'），从而改写 `experiment` 的提交历史，使它成为 `master` 分支的直接下游，如图 3-29 所示：
+它的原理是回到两个分支最近的共同祖先，根据当前分支（也就是要进行变基的分支 `experiment`）后续的历次提交对象（这里只有一个 C3），生成一系列文件补丁，然后以基底分支（也就是主干分支 `master`）最后一个提交对象（C4）为新的出发点，逐个应用之前准备好的补丁文件，最后会生成一个新的合并提交对象（C3'），从而改写 `experiment` 的提交历史，使它成为 `master` 分支的直接下游，如图 3-29 所示：
 
 Insert 18333fig0329.png
 图 3-29. 把 C3 里产生的改变到 C4 上重演一遍。
@@ -513,15 +513,15 @@ Insert 18333fig0329.png
 Insert 18333fig0330.png
 图 3-30. master 分支的快进。
 
-现在的 C3' 对应的快照，其实和普通的三方合并，即上个例子中的 C5 对应的快照内容一模一样了。虽然最后整合得到的结果没有任何区别，但衍合能产生一个更为整洁的提交历史。如果视察一个衍合过的分支的历史记录，看起来会更清楚：仿佛所有修改都是在一根线上先后进行的，尽管实际上它们原本是同时并行发生的。
+现在的 C3' 对应的快照，其实和普通的三方合并，即上个例子中的 C5 对应的快照内容一模一样了。虽然最后整合得到的结果没有任何区别，但变基能产生一个更为整洁的提交历史。如果视察一个变基过的分支的历史记录，看起来会更清楚：仿佛所有修改都是在一根线上先后进行的，尽管实际上它们原本是同时并行发生的。
 
-一般我们使用衍合的目的，是想要得到一个能在远程分支上干净应用的补丁 — 比如某些项目你不是维护者，但想帮点忙的话，最好用衍合：先在自己的一个分支里进行开发，当准备向主项目提交补丁的时候，根据最新的 `origin/master` 进行一次衍合操作然后再提交，这样维护者就不需要做任何整合工作（译注：实际上是把解决分支补丁同最新主干代码之间冲突的责任，化转为由提交补丁的人来解决。），只需根据你提供的仓库地址作一次快进合并，或者直接采纳你提交的补丁。
+一般我们使用变基的目的，是想要得到一个能在远程分支上干净应用的补丁 — 比如某些项目你不是维护者，但想帮点忙的话，最好用变基：先在自己的一个分支里进行开发，当准备向主项目提交补丁的时候，根据最新的 `origin/master` 进行一次变基操作然后再提交，这样维护者就不需要做任何整合工作（译注：实际上是把解决分支补丁同最新主干代码之间冲突的责任，化转为由提交补丁的人来解决。），只需根据你提供的仓库地址作一次快进合并，或者直接采纳你提交的补丁。
 
-请注意，合并结果中最后一次提交所指向的快照，无论是通过衍合，还是三方合并，都会得到相同的快照内容，只不过提交历史不同罢了。衍合是按照每行的修改次序重演一遍修改，而合并是把最终结果合在一起。
+请注意，合并结果中最后一次提交所指向的快照，无论是通过变基，还是三方合并，都会得到相同的快照内容，只不过提交历史不同罢了。变基是按照每行的修改次序重演一遍修改，而合并是把最终结果合在一起。
 
-### 有趣的衍合 ###
+### 有趣的变基 ###
 
-衍合也可以放到其他分支进行，并不一定非得根据分化之前的分支。以图 3-31 的历史为例，我们为了给服务器端代码添加一些功能而创建了特性分支 `server`，然后提交 C3 和 C4。然后又从 C3 的地方再增加一个 `client` 分支来对客户端代码进行一些相应修改，所以提交了 C8 和 C9。最后，又回到 `server` 分支提交了 C10。
+变基也可以放到其他分支进行，并不一定非得根据分化之前的分支。以图 3-31 的历史为例，我们为了给服务器端代码添加一些功能而创建了特性分支 `server`，然后提交 C3 和 C4。然后又从 C3 的地方再增加一个 `client` 分支来对客户端代码进行一些相应修改，所以提交了 C8 和 C9。最后，又回到 `server` 分支提交了 C10。
 
 Insert 18333fig0331.png
 图 3-31. 从一个特性分支里再分出一个特性分支的历史。
@@ -533,7 +533,7 @@ Insert 18333fig0331.png
 这好比在说：“取出 `client` 分支，找出 `client` 分支和 `server` 分支的共同祖先之后的变化，然后把它们在 `master` 上重演一遍”。是不是有点复杂？不过它的结果如图 3-32 所示，非常酷（译注：虽然 `client` 里的 C8, C9 在 C3 之后，但这仅表明时间上的先后，而非在 C3 修改的基础上进一步改动，因为 `server` 和 `client` 这两个分支对应的代码应该是两套文件，虽然这么说不是很严格，但应理解为在 C3 时间点之后，对另外的文件所做的 C8，C9 修改，放到主干重演。）：
 
 Insert 18333fig0332.png
-图 3-32. 将特性分支上的另一个特性分支衍合到其他分支。
+图 3-32. 将特性分支上的另一个特性分支变基到其他分支。
 
 现在可以快进 `master` 分支了（见图 3-33）：
 
@@ -543,14 +543,14 @@ Insert 18333fig0332.png
 Insert 18333fig0333.png
 图 3-33. 快进 master 分支，使之包含 client 分支的变化。
 
-现在我们决定把 `server` 分支的变化也包含进来。我们可以直接把 `server` 分支衍合到 `master`，而不用手工切换到 `server` 分支后再执行衍合操作 — `git rebase [主分支] [特性分支]` 命令会先取出特性分支 `server`，然后在主分支 `master` 上重演：
+现在我们决定把 `server` 分支的变化也包含进来。我们可以直接把 `server` 分支变基到 `master`，而不用手工切换到 `server` 分支后再执行变基操作 — `git rebase [主分支] [特性分支]` 命令会先取出特性分支 `server`，然后在主分支 `master` 上重演：
 
 	$ git rebase master server
 
 于是，`server` 的进度应用到 `master` 的基础上，如图 3-34 所示：
 
 Insert 18333fig0334.png
-图 3-34. 在 master 分支上衍合 server 分支。
+图 3-34. 在 master 分支上变基 server 分支。
 
 然后就可以快进主干分支 `master` 了：
 
@@ -565,17 +565,17 @@ Insert 18333fig0334.png
 Insert 18333fig0335.png
 图 3-35. 最终的提交历史
 
-### 衍合的风险 ###
+### 变基的风险 ###
 
-呃，奇妙的衍合也并非完美无缺，要用它得遵守一条准则：
+呃，奇妙的变基也并非完美无缺，要用它得遵守一条准则：
 
-**一旦分支中的提交对象发布到公共仓库，就千万不要对该分支进行衍合操作。**
+**一旦分支中的提交对象发布到公共仓库，就千万不要对该分支进行变基操作。**
 
 如果你遵循这条金科玉律，就不会出差错。否则，人民群众会仇恨你，你的朋友和家人也会嘲笑你，唾弃你。
 
-在进行衍合的时候，实际上抛弃了一些现存的提交对象而创造了一些类似但不同的新的提交对象。如果你把原来分支中的提交对象发布出去，并且其他人更新下载后在其基础上开展工作，而稍后你又用 `git rebase` 抛弃这些提交对象，把新的重演后的提交对象发布出去的话，你的合作者就不得不重新合并他们的工作，这样当你再次从他们那里获取内容时，提交历史就会变得一团糟。
+在进行变基的时候，实际上抛弃了一些现存的提交对象而创造了一些类似但不同的新的提交对象。如果你把原来分支中的提交对象发布出去，并且其他人更新下载后在其基础上开展工作，而稍后你又用 `git rebase` 抛弃这些提交对象，把新的重演后的提交对象发布出去的话，你的合作者就不得不重新合并他们的工作，这样当你再次从他们那里获取内容时，提交历史就会变得一团糟。
 
-下面我们用一个实际例子来说明为什么公开的衍合会带来问题。假设你从一个中央服务器克隆然后在它的基础上搞了一些开发，提交历史类似图 3-36 所示：
+下面我们用一个实际例子来说明为什么公开的变基会带来问题。假设你从一个中央服务器克隆然后在它的基础上搞了一些开发，提交历史类似图 3-36 所示：
 
 Insert 18333fig0336.png
 图 3-36. 克隆一个仓库，在其基础上工作一番。
@@ -585,20 +585,20 @@ Insert 18333fig0336.png
 Insert 18333fig0337.png
 图 3-37. 抓取他人提交，并入自己主干。
 
-接下来，那个推送 C6 上来的人决定用衍合取代之前的合并操作；继而又用 `git push --force` 覆盖了服务器上的历史，得到 C4'。而之后当你再从服务器上下载最新提交后，会得到：
+接下来，那个推送 C6 上来的人决定用变基取代之前的合并操作；继而又用 `git push --force` 覆盖了服务器上的历史，得到 C4'。而之后当你再从服务器上下载最新提交后，会得到：
 
 Insert 18333fig0338.png
-图 3-38. 有人推送了衍合后得到的 C4'，丢弃了你作为开发基础的 C4 和 C6。
+图 3-38. 有人推送了变基后得到的 C4'，丢弃了你作为开发基础的 C4 和 C6。
 
-下载更新后需要合并，但此时衍合产生的提交对象 C4' 的 SHA-1 校验值和之前 C4 完全不同，所以 Git 会把它们当作新的提交对象处理，而实际上此刻你的提交历史 C7 中早已经包含了 C4 的修改内容，于是合并操作会把 C7 和 C4' 合并为 C8（见图 3-39）:
+下载更新后需要合并，但此时变基产生的提交对象 C4' 的 SHA-1 校验值和之前 C4 完全不同，所以 Git 会把它们当作新的提交对象处理，而实际上此刻你的提交历史 C7 中早已经包含了 C4 的修改内容，于是合并操作会把 C7 和 C4' 合并为 C8（见图 3-39）:
 
 Insert 18333fig0339.png
 图 3-39. 你把相同的内容又合并了一遍，生成一个新的提交 C8。
 
-C8 这一步的合并是迟早会发生的，因为只有这样你才能和其他协作者提交的内容保持同步。而在 C8 之后，你的提交历史里就会同时包含 C4 和 C4'，两者有着不同的 SHA-1 校验值，如果用 `git log` 查看历史，会看到两个提交拥有相同的作者日期与说明，令人费解。而更糟的是，当你把这样的历史推送到服务器后，会再次把这些衍合后的提交引入到中央服务器，进一步困扰其他人（译注：这个例子中，出问题的责任方是那个发布了 C6 后又用衍合发布 C4' 的人，其他人会因此反馈双重历史到共享主干，从而混淆大家的视听。）。
+C8 这一步的合并是迟早会发生的，因为只有这样你才能和其他协作者提交的内容保持同步。而在 C8 之后，你的提交历史里就会同时包含 C4 和 C4'，两者有着不同的 SHA-1 校验值，如果用 `git log` 查看历史，会看到两个提交拥有相同的作者日期与说明，令人费解。而更糟的是，当你把这样的历史推送到服务器后，会再次把这些变基后的提交引入到中央服务器，进一步困扰其他人（译注：这个例子中，出问题的责任方是那个发布了 C6 后又用变基发布 C4' 的人，其他人会因此反馈双重历史到共享主干，从而混淆大家的视听。）。
 
-如果把衍合当成一种在推送之前清理提交历史的手段，而且仅仅衍合那些尚未公开的提交对象，就没问题。如果衍合那些已经公开的提交对象，并且已经有人基于这些提交对象开展了后续开发工作的话，就会出现叫人沮丧的麻烦。
+如果把变基当成一种在推送之前清理提交历史的手段，而且仅仅变基那些尚未公开的提交对象，就没问题。如果变基那些已经公开的提交对象，并且已经有人基于这些提交对象开展了后续开发工作的话，就会出现叫人沮丧的麻烦。
 
 ## 小结 ##
 
-读到这里，你应该已经学会了如何创建分支并切换到新分支，在不同分支间转换，合并本地分支，把分支推送到共享服务器上，使用共享分支与他人协作，以及在分享之前进行衍合。
+读到这里，你应该已经学会了如何创建分支并切换到新分支，在不同分支间转换，合并本地分支，把分支推送到共享服务器上，使用共享分支与他人协作，以及在分享之前进行变基。

From 4b04063f03690e064272ddf33451a969cf8643c4 Mon Sep 17 00:00:00 2001
From: Bertram Scharpf <software@bertram-scharpf.de>
Date: Fri, 26 Jun 2015 14:57:42 +0200
Subject: [PATCH 681/690] [de] Fix typo

---
 de/04-git-server/01-chapter4.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/de/04-git-server/01-chapter4.markdown b/de/04-git-server/01-chapter4.markdown
index 432ee1436..2bdb6f996 100644
--- a/de/04-git-server/01-chapter4.markdown
+++ b/de/04-git-server/01-chapter4.markdown
@@ -300,7 +300,7 @@ Als erstes solltest Du überprüfen, ob Du nicht schon einen Schlüssel hast. St
 
 <!--You’re looking for a pair of files named something and something.pub, where the something is usually `id_dsa` or `id_rsa`. The `.pub` file is your public key, and the other file is your private key. If you don’t have these files (or you don’t even have a `.ssh` directory), you can create them by running a program called `ssh-keygen`, which is provided with the SSH package on Linux/Mac systems and comes with the MSysGit package on Windows:-->
 
-Du suchst nach Paar Dateien namens `irgendetwas` und `irgendetwas.pub`, die Datei `irgendetwas` heißt normalerweise `id_dsa` oder `id_rsa`. Die `.pub`-Datei ist Dein öffentlicher Schlüssel und die andere Datei ist Dein privater Schlüssel. Wenn Du diese Dateien nicht hast (oder gar kein `.ssh`-Verzeichnis hast), kannst Du sie mit dem Ausführen des Programms `ssh-keygen` erzeugen. Das Programm wird mit dem SSH-Paket auf Linux/Mac-Systemen mitgeliefert und kommt mit dem MSysGit-Paket unter Windows:
+Du suchst nach einem Dateienpaar namens `irgendetwas` und `irgendetwas.pub`, die Datei `irgendetwas` heißt normalerweise `id_dsa` oder `id_rsa`. Die `.pub`-Datei ist Dein öffentlicher Schlüssel, und die andere Datei ist Dein privater Schlüssel. Wenn Du diese Dateien nicht hast (oder gar kein `.ssh`-Verzeichnis hast), kannst Du sie mit dem Ausführen des Programms `ssh-keygen` erzeugen. Das Programm wird mit dem SSH-Paket auf Linux/Mac-Systemen mitgeliefert und kommt mit dem MSysGit-Paket unter Windows:
 
 	$ ssh-keygen
 	Generating public/private rsa key pair.

From 0d4f3ef51f52dd4ecb4c09064bc2ec46f1195d54 Mon Sep 17 00:00:00 2001
From: "P. Tamami" <tamami.oka@gmail.com>
Date: Fri, 17 Jul 2015 21:20:07 +0700
Subject: [PATCH 682/690] Update 01-chapter3.markdown

translate line 149
---
 id/03-git-branching/01-chapter3.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/id/03-git-branching/01-chapter3.markdown b/id/03-git-branching/01-chapter3.markdown
index 8c9184375..db3b55e30 100644
--- a/id/03-git-branching/01-chapter3.markdown
+++ b/id/03-git-branching/01-chapter3.markdown
@@ -146,7 +146,7 @@ Bagaimanapun, sebelum anda melakukannya, perhatikan bahwa jika dalam kandar kerj
 
 Saat ini, anda berada dalam kandar kerja dalam kondisi tepat seperti anda belum mengerjakan masalah #53, dan anda dapat konsentrasi mengerjakan perbaikannya. Hal yang perlu diingat adalah: Git mengkondisikan kandar kerja anda agar terlihat sebagaimana anda kembali ke titik pencabangan yang anda tuju. Git menambahkan, menghapus, dan mengubah berkas secara otomatis untuk memastikan bahwa anda bekerja pada pencabangan terakhir yang anda *commit*.
 
-Next, you have a hotfix to make. Let’s create a hotfix branch on which to work until it’s completed (see Figure 3-13):
+Selanjutnya, ada dapat membuat cabang *hotfix*. Mari kita buat cabang *hotfix* tempat kita bekerja sampai kondisinya selesai (lihat Gambar 3-13):
 
 	$ git checkout -b 'hotfix'
 	Switched to a new branch "hotfix"

From c5b3c8b0158cd28e2afa20c750a43d04420b47cb Mon Sep 17 00:00:00 2001
From: Nikolay Mishin <mi@ya.ru>
Date: Mon, 20 Jul 2015 07:27:32 +0300
Subject: [PATCH 683/690] =?UTF-8?q?=D0=BF=D0=BE=D0=BF=D1=80=D0=B0=D0=B2?=
 =?UTF-8?q?=D0=B8=D0=BB=20=D1=81=D0=BE=D0=B3=D0=BB=D0=B0=D1=81=D0=BE=D0=B2?=
 =?UTF-8?q?=D0=B0=D0=BD=D0=B8=D0=B5=20=D0=B2=D1=80=D0=B5=D0=BC=D0=B5=D0=BD?=
 =?UTF-8?q?=20=D1=81=D0=BB=D0=BE=D0=B2=D0=B0=20=D0=BA=D0=BE=D0=BC=D0=BC?=
 =?UTF-8?q?=D0=B8=D1=82?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 ru/07-customizing-git/01-chapter7.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ru/07-customizing-git/01-chapter7.markdown b/ru/07-customizing-git/01-chapter7.markdown
index 94009ba4a..9d0d23076 100644
--- a/ru/07-customizing-git/01-chapter7.markdown
+++ b/ru/07-customizing-git/01-chapter7.markdown
@@ -626,7 +626,7 @@ Insert 18333fig0703.png
 
 Первая наша задача — это заставить все сообщения коммитов обязательно придерживаться определённого формата. Просто чтобы было чем заняться, предположим, что каждое сообщение должно содержать строку вида "ref: 1234", так как мы хотим, чтобы каждый коммит был связан с некоторым элементом в нашей системе с карточками. Нам необходимо просмотреть все присланные коммиты, выяснить, есть ли такая строка в сообщении коммита, и, если строка отсутствует в каком-либо из этих коммитов, то завершить сценарий с ненулевым кодом, чтобы `push` был отклонён.
 
-Список значений SHA-1 для всех присланных коммитов можно получить, взяв значения `$newrev` и `$oldrev` и передав их служебной команде `git rev-list`. По сути, это команда `git log`, но по умолчанию она выводит только SHA-1 значения и больше ничего. Таким образом, чтобы получить список SHA для всех коммитов, сделанных между одним SHA коммита и другим, достаточно выполнить следующее:
+Список значений SHA-1 для всех присланных коммитов можно получить, взяв значения `$newrev` и `$oldrev` и передав их служебной команде `git rev-list`. По сути, это команда `git log`, но по умолчанию она выводит только SHA-1 значения и больше ничего. Таким образом, чтобы получить список SHA для всех коммитов, сделанных между одним SHA коммитом и другим, достаточно выполнить следующее:
 
 	$ git rev-list 538c33..d14fc7
 	d14fc7c847ab946ec39590d87783c69b031bdfb7

From 5e4ed290c1af04d798fb328616792aa87fa3aeba Mon Sep 17 00:00:00 2001
From: Nikolay Mishin <mi@ya.ru>
Date: Mon, 20 Jul 2015 07:36:25 +0300
Subject: [PATCH 684/690] delete SHA
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

здесь это слово не нужно
---
 ru/07-customizing-git/01-chapter7.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ru/07-customizing-git/01-chapter7.markdown b/ru/07-customizing-git/01-chapter7.markdown
index 9d0d23076..9c54f1f40 100644
--- a/ru/07-customizing-git/01-chapter7.markdown
+++ b/ru/07-customizing-git/01-chapter7.markdown
@@ -626,7 +626,7 @@ Insert 18333fig0703.png
 
 Первая наша задача — это заставить все сообщения коммитов обязательно придерживаться определённого формата. Просто чтобы было чем заняться, предположим, что каждое сообщение должно содержать строку вида "ref: 1234", так как мы хотим, чтобы каждый коммит был связан с некоторым элементом в нашей системе с карточками. Нам необходимо просмотреть все присланные коммиты, выяснить, есть ли такая строка в сообщении коммита, и, если строка отсутствует в каком-либо из этих коммитов, то завершить сценарий с ненулевым кодом, чтобы `push` был отклонён.
 
-Список значений SHA-1 для всех присланных коммитов можно получить, взяв значения `$newrev` и `$oldrev` и передав их служебной команде `git rev-list`. По сути, это команда `git log`, но по умолчанию она выводит только SHA-1 значения и больше ничего. Таким образом, чтобы получить список SHA для всех коммитов, сделанных между одним SHA коммитом и другим, достаточно выполнить следующее:
+Список значений SHA-1 для всех присланных коммитов можно получить, взяв значения `$newrev` и `$oldrev` и передав их служебной команде `git rev-list`. По сути, это команда `git log`, но по умолчанию она выводит только SHA-1 значения и больше ничего. Таким образом, чтобы получить список SHA для всех коммитов, сделанных между одним коммитом и другим, достаточно выполнить следующее:
 
 	$ git rev-list 538c33..d14fc7
 	d14fc7c847ab946ec39590d87783c69b031bdfb7

From 4528929859f6ab46b5d0edb6c04c6fd2bb861430 Mon Sep 17 00:00:00 2001
From: Nikolay Mishin <mi@ya.ru>
Date: Mon, 20 Jul 2015 07:47:06 +0300
Subject: [PATCH 685/690] delete comma
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

запятая после наречия 'Схематически' не нужна
---
 ru/09-git-internals/01-chapter9.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ru/09-git-internals/01-chapter9.markdown b/ru/09-git-internals/01-chapter9.markdown
index 7ec5b914b..874d32963 100644
--- a/ru/09-git-internals/01-chapter9.markdown
+++ b/ru/09-git-internals/01-chapter9.markdown
@@ -114,7 +114,7 @@ Git проинициализировал каталог `objects` и созда
 	$ git cat-file -p 99f1a6d12cb4b6f19c8655fca46c3ecf317074e0
 	100644 blob 47c6340d6459e05787f644c2447d2595f5d3a54b      simplegit.rb
 
-Схематически, данные, хранящиеся в Git'е, выглядят примерно так, как это изображено на рисунке 9-1.
+Схематически данные, хранящиеся в Git'е, выглядят примерно так, как это изображено на рисунке 9-1.
 
 Insert 18333fig0901.png 
 Рисунок 9-1. Упрощённая модель данных Git'а.

From 1a96ca10da73456518fcfc2d47f6accab37597f8 Mon Sep 17 00:00:00 2001
From: chusiang <chusiang.lai@gmail.com>
Date: Mon, 5 Oct 2015 12:36:08 +0800
Subject: [PATCH 686/690] fix typo: Fedpra -> Fedora.

---
 zh-tw/01-introduction/01-chapter1.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/zh-tw/01-introduction/01-chapter1.markdown b/zh-tw/01-introduction/01-chapter1.markdown
index e215e94f3..db3ba97f3 100644
--- a/zh-tw/01-introduction/01-chapter1.markdown
+++ b/zh-tw/01-introduction/01-chapter1.markdown
@@ -126,7 +126,7 @@ Git目錄是Git用來儲存讀者的專案的metadata及物件資料庫。 這
 
 若讀者有能力的話，從原始碼安裝是非常有用的。 因為讀者能取得最新版本。 每一版Git通常都會包含有用的UI改善。 因此取得最新版本通常是最好的，只要讀者覺得編譯軟體的原始碼是很容易的。 許多Linux發行套件通常都是附上非常舊的套件。 除非讀者使用的發行套件非常新或者使用向後相容的移植版本。 從原始碼安裝通常是最好的選擇。
 
-要安裝Git，讀者需要先安裝它需要的程式庫：curl、zlib、openssl、expat及libiconv。 例如：若讀者的系統有yum（如：Fedpra）或apt-get（如：以Debian為基礎的系統），讀者可使用下列任一命令安裝所有需要的程式庫：
+要安裝Git，讀者需要先安裝它需要的程式庫：curl、zlib、openssl、expat及libiconv。 例如：若讀者的系統有yum（如：Fedora）或apt-get（如：以Debian為基礎的系統），讀者可使用下列任一命令安裝所有需要的程式庫：
 
 	$ yum install curl-devel expat-devel gettext-devel \
 	  openssl-devel zlib-devel

From c7d739dd853ec56f75e0636bcb4b1436a26a1e55 Mon Sep 17 00:00:00 2001
From: chusiang <chusiang.lai@gmail.com>
Date: Mon, 5 Oct 2015 13:56:04 +0800
Subject: [PATCH 687/690] =?UTF-8?q?fix=20layout=20of=20space,=20=EF=BC=88,?=
 =?UTF-8?q?=20=EF=BC=89..?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 zh-tw/01-introduction/01-chapter1.markdown | 151 +++++++++++----------
 1 file changed, 76 insertions(+), 75 deletions(-)

diff --git a/zh-tw/01-introduction/01-chapter1.markdown b/zh-tw/01-introduction/01-chapter1.markdown
index db3ba97f3..cbb39a9db 100644
--- a/zh-tw/01-introduction/01-chapter1.markdown
+++ b/zh-tw/01-introduction/01-chapter1.markdown
@@ -1,132 +1,132 @@
 # 開始 #
 
-本章介紹Git的相關知識。 先從講解一些版本控制工具的背景知識開始，然後試著在讀者的系統將Git跑起來，最後則是設定它。 在本章結束後，讀者應瞭解為什麼Git如 此流行、為什麼讀者應該利用它、以及完成使用它的準備工作。
+本章介紹 Git 的相關知識。先從講解一些版本控制工具的背景知識開始，然後試著在讀者的系統將 Git 跑起來，最後則是設定它。在本章結束後，讀者應瞭解為什麼 Git 如此流行、為什麼讀者應該利用它、以及完成使用它的準備工作。
 
 ## 關於版本控制 ##
 
-什麼是版本控制？ 以及為什麼讀者會在意它？ 版本控制是一個能夠記錄一個或一組檔案在某一段時間的變更，使得讀者以後能取回特定版本的系統。 在本書的範例中，讀者會學到如何對軟體的原始碼做版本控制。 即使實際上讀者幾乎可以針對電腦上任意型態的檔案做版本控制。
+什麼是版本控制？以及為什麼讀者會在意它？版本控制是一個能夠記錄一個或一組檔案在某一段時間的變更，使得讀者以後能取回特定版本的系統。在本書的範例中，讀者會學到如何對軟體的原始碼做版本控制。即使實際上讀者幾乎可以針對電腦上任意型態的檔案做版本控制。
 
-若讀者是繪圖或網頁設計師且想要記錄每一版影像或版面配置（這也通常是讀者想要做的），採用版本控制系統（VCS）做這件事是非常明智的。 它允許讀者將檔案復原到原本的狀態、將整個專案復原到先前的狀態、比對某一段時間的修改、查看最後是誰在哪個時間點做了錯誤的修改導致問題發生，等。 使用版本控制系統一般也意謂著若讀者做了一些傻事或者遺失檔案，讀者能很容易地回復到原先的狀態。 更進一步，僅需付出很小的代價即可得到這些優點。
+若讀者是繪圖或網頁設計師且想要記錄每一版影像或版面配置 (這也通常是讀者想要做的) ，採用版本控制系統 (VCS) 做這件事是非常明智的。它允許讀者將檔案復原到原本的狀態、將整個專案復原到先前的狀態、比對某一段時間的修改、查看最後是誰在哪個時間點做了錯誤的修改導致問題發生，等。使用版本控制系統一般也意謂著若讀者做了一些傻事或者遺失檔案，讀者能很容易地回復到原先的狀態。更進一步，僅需付出很小的代價即可得到這些優點。
 
 ### 本地端版本控制 ###
 
-許多讀者採用複製檔案到其它目錄的方式來做版本控制（若他們夠聰明的話，或許會是有記錄時間戳記的目錄）。 因為它很簡單，這是個很常見的方法；但它也很容易出錯。 讀者很容易就忘記在哪個目錄，並不小心地把錯誤的檔案寫入、或者複製到不想要的檔案。
+許多讀者採用複製檔案到其它目錄的方式來做版本控制 (若他們夠聰明的話，或許會是有記錄時間戳記的目錄)。因為它很簡單，這是個很常見的方法；但它也很容易出錯。讀者很容易就忘記在哪個目錄，並不小心地把錯誤的檔案寫入、或者複製到不想要的檔案。
 
-為了解決這問題，程式設計師在很久以前開發了本地端的版本控制系統，具備簡單的資料庫，用來記載檔案的所有變更記錄（參考圖1-1）。
+為了解決這問題，程式設計師在很久以前開發了本地端的版本控制系統，具備簡單的資料庫，用來記載檔案的所有變更記錄 (參考圖 1-1)。
 
 Insert 18333fig0101.png
-圖1-1. 本地端版本控制流程圖。
+圖 1-1. 本地端版本控制流程圖。
 
-這種版本控制工具中最流行的是rcs，目前仍存在於許多電腦。 即使是流行的Mac OS X作業系統，都會在讀者安裝開發工具時安裝rcs命令。 此工具基本上以特殊的格式記錄修補集合（patch set，即檔案從一個版本變更到另一個版本所需資訊），並儲存於磁碟上。 它就可以藉由套用各修補集合産生各時間點的檔案內容。
+這種版本控制工具中最流行的是 rcs，目前仍存在於許多電腦。即使是流行的 Mac OS X 作業系統，都會在讀者安裝開發工具時安裝 rcs 命令。此工具基本上以特殊的格式記錄修補集合 (patch set，即檔案從一個版本變更到另一個版本所需資訊)，並儲存於磁碟上。它就可以藉由套用各修補集合産生各時間點的檔案內容。
 
 ### 集中式版本控制系統 ###
 
-接下來人們遇到的主要問題是需要在多種其它系統上的開發協同作業。 為了解決此問題，集中式版本控制系統(Centralized Version Control Systems，簡稱CVCSs)被發展出來。 此系統，如：CVS、Subversion及Perforce皆具備單一伺服器，記錄所有版本的檔案，且有多個客戶端從伺服器從伺服器取出檔案。 在多年後，這已經是版本控制系統的標準（參考圖1-2）。
+接下來人們遇到的主要問題是需要在多種其它系統上的開發協同作業。為了解決此問題，集中式版本控制系統 (Centralized Version Control Systems，簡稱CVCSs) 被發展出來。此系統，如：CVS, Subversion 及 Perforce 皆具備單一伺服器，記錄所有版本的檔案，且有多個客戶端從伺服器從伺服器取出檔案。在多年後，這已經是版本控制系統的標準 (參考圖1-2)。
 
 Insert 18333fig0102.png
-圖1-2. 集中式版本控制系統
+圖 1-2. 集中式版本控制系統
 
-這樣的配置提供了很多優點，特別是相較於本地端的版本控制系統來說。 例如：每個人皆能得知其它人對此專案做了些什麼修改有一定程度的瞭解。 管理員可調整存取權限，限制各使用者能做的事。 而且維護集中式版本控制系統也比維護散落在各使用者端的資料庫來的容易。
+這樣的配置提供了很多優點，特別是相較於本地端的版本控制系統來說。例如：每個人皆能得知其它人對此專案做了些什麼修改有一定程度的瞭解。管理員可調整存取權限，限制各使用者能做的事。而且維護集中式版本控制系統也比維護散落在各使用者端的資料庫來的容易。
 
-然而，這樣的配置也有嚴重的缺點。 最明顯的就是無法連上伺服器時。 如果伺服器當機一個小時，在這段時間中沒有人能進行協同開發的工作或者將變更的部份傳遞給其他使用者。 如果伺服器用來儲存資料庫的硬碟損毀，而且沒有相關的偏份資料。 除了使用者已取到本地端電腦的版本外，包含該專案開發的歷史的所有資訊都會遺失。 本地端版本控制系統也會有同樣的問題，只要使用者將整個專案的開發歷史都放在同一個地方，就有遺失所有資料的風險。
+然而，這樣的配置也有嚴重的缺點。最明顯的就是無法連上伺服器時。如果伺服器當機一個小時，在這段時間中沒有人能進行協同開發的工作或者將變更的部份傳遞給其他使用者。如果伺服器用來儲存資料庫的硬碟損毀，而且沒有相關的偏份資料。除了使用者已取到本地端電腦的版本外，包含該專案開發的歷史的所有資訊都會遺失。本地端版本控制系統也會有同樣的問題，只要使用者將整個專案的開發歷史都放在同一個地方，就有遺失所有資料的風險。
 
 ### 分散式版本控制系統 ###
 
-這就是分散式版本控制系統(Distributed Version Control Systems, 簡稱DVCSs)被引入的原因。 在分散式版本控制系統，諸如：Git、Mercurial、Bazaar、Darcs。 客戶端不只是取出最後一版的檔案，而是完整複製整個儲存庫。 即使是整個系統賴以運作的電腦損毀，皆可將任何一個客戶端先前複製的資料還原到伺服器。 每一次的取出動作實際上就是完整備份整個儲存庫。（參考圖1-3）
+這就是分散式版本控制系統 (Distributed Version Control Systems, 簡稱DVCSs) 被引入的原因。在分散式版本控制系統，諸如：Git, Mercurial, Bazaar、Darcs。 客戶端不只是取出最後一版的檔案，而是完整複製整個儲存庫。即使是整個系統賴以運作的電腦損毀，皆可將任何一個客戶端先前複製的資料還原到伺服器。每一次的取出動作實際上就是完整備份整個儲存庫。 (參考圖 1-3)
 
 Insert 18333fig0103.png
-圖1-3. 分散式版本控制系統
+圖 1-3. 分散式版本控制系統
 
-更進一步來說，許多這類型的系統皆能同時與數個遠端的機器同時運作。 因此讀者能同時與許多不同群組的人們協同開發同一個專案。 這允許讀者設定多種集中式系統做不到的工作流程，如：階層式模式。
+更進一步來說，許多這類型的系統皆能同時與數個遠端的機器同時運作。因此讀者能同時與許多不同群組的人們協同開發同一個專案。這允許讀者設定多種集中式系統做不到的工作流程，如：階層式模式。
 
 ## Git 的簡史 ##
 
-如同許多生命中美好的事物一樣，Git從有一點創造性的破壞及激烈的討論中誕生。 Linux kernel 是開放原始碼中相當大的專案。 在 Linux kernel 大部份的維護時間內（1991～2002），修改該軟體的方式通常以多個修補檔及壓縮檔流通。 在2002年，Linux kernel 開始採用名為 BitKeeper 的商業分散式版本控制系統。
+如同許多生命中美好的事物一樣，Git 從有一點創造性的破壞及激烈的討論中誕生。 Linux kernel 是開放原始碼中相當大的專案。在 Linux kernel 大部份的維護時間內 (1991 ~ 2002)，修改該軟體的方式通常以多個修補檔及壓縮檔流通。在 2002 年，Linux kernel 開始採用名為 BitKeeper 的商業分散式版本控制系統。
 
-在 2005年，開發 Linux kernel 的社群與開發 BitKeeper 的商業公司的關係走向決裂，也無法再免費使用該工具。 這告訴了 Linux 社群及 Linux 之父 Linus Torvalds，該是基於使用 BitKeeper 得到的經驗，開發自有的工具的時候。 這個系統必須達成下列目標：
+在 2005年，開發 Linux kernel 的社群與開發 BitKeeper 的商業公司的關係走向決裂，也無法再免費使用該工具。這告訴了 Linux 社群及 Linux 之父 Linus Torvalds，該是基於使用 BitKeeper 得到的經驗，開發自有的工具的時候。這個系統必須達成下列目標：
 
 *	快速
 *	簡潔的設計
-*	完整支援非線性的開發（上千個同時進行的分支）
+*	完整支援非線性的開發 (上千個同時進行的分支)
 *	完全的分散式系統
-*	能夠有效地處理像 Linux kernel 規模的專案（速度及資料大小）
+*	能夠有效地處理像 Linux kernel 規模的專案 (速度及資料大小)
 
-自從 2005 年誕生後，Git已相當成熟，也能很容易上手，並保持著最一開始的要求的品質。 它不可思議的快速、處理大型專案非常有效率、也具備相當優秀足以應付非線性開發的分支系統。（參考第三章）
+自從 2005 年誕生後，Git 已相當成熟，也能很容易上手，並保持著最一開始的要求的品質。它不可思議的快速、處理大型專案非常有效率、也具備相當優秀足以應付非線性開發的分支系統。(參考第三章)
 
 ## Git 基礎要點 ##
 
-那麼，簡單地說，Git是一個什麼樣的系統？ 這一章節是非常重要的。 若讀者瞭解Git的本質以及運作的基礎，那麼使用起來就會很輕鬆且有效率。 在學習之前，試著忘記以前所知道的其它版本控制系統，如：Subversion 及 Perforce。 這將會幫助讀者使用此工具時發生不必要的誤會。 Git儲存資料及運作它們的方式遠異於其它系統，即使它們的使用者介面是很相似的。 瞭解這些差異會幫助讀者更準確的使用此工具。
+那麼，簡單地說，Git 是一個什麼樣的系統？這一章節是非常重要的。若讀者瞭解 Git 的本質以及運作的基礎，那麼使用起來就會很輕鬆且有效率。在學習之前，試著忘記以前所知道的其它版本控制系統，如：Subversion 及 Perforce。 這將會幫助讀者使用此工具時發生不必要的誤會。Git 儲存資料及運作它們的方式遠異於其它系統，即使它們的使用者介面是很相似的。瞭解這些差異會幫助讀者更準確的使用此工具。
 
 ### 記錄檔案快照，而不是差異的部份 ###
 
-Git與其它版本控制系統（包含Subversion以及與它相關的）的差別是如何處理資料的方式。 一般來說，大部份其它系統記錄資訊是一連串檔案更動的內容。 如圖1-4所示。 這些系統（CVS、Subversion、Perforce、Bazaar等等）儲存一組基本的檔案以及對應這些檔案隨時間遞增的更動資料。
+Git 與其它版本控制系統 (包含 Subversion 以及與它相關的) 的差別是如何處理資料的方式。一般來說，大部份其它系統記錄資訊是一連串檔案更動的內容。如圖 1-4 所示。這些系統 (CVS, Subversion, Perforce, Bazaar 等等) 儲存一組基本的檔案以及對應這些檔案隨時間遞增的更動資料。
 
 Insert 18333fig0104.png
-圖1-4. 其它系統傾向儲存每個檔案更動的資料。
+圖 1-4. 其它系統傾向儲存每個檔案更動的資料。
 
-Git並不以此種方式儲存資料。 而是將其視為小型檔案系統的一組快照(Snapshot)。 每一次讀者提交更新時、或者儲存目前專案的狀態到Git時。 基本上它為當時的資料做一組快照並記錄參考到該快照的參考點。 為了講求效率，只要檔案沒有變更，Git不會再度儲存該檔案，而是記錄到前一次的相同檔案的連結。 Git的工作方式如圖1-5所示。
+Git 並不以此種方式儲存資料。而是將其視為小型檔案系統的一組快照 (Snapshot)。每一次讀者提交更新時、或者儲存目前專案的狀態到 Git 時。基本上它為當時的資料做一組快照並記錄參考到該快照的參考點。為了講求效率，只要檔案沒有變更，Git 不會再度儲存該檔案，而是記錄到前一次的相同檔案的連結。Git 的工作方式如圖 1-5 所示。
 
 Insert 18333fig0105.png
-圖1-5. Git儲存每次專案更新時的快照。
+圖 1-5. Git 儲存每次專案更新時的快照。
 
-這是Git與所有其它版本控制系統最重要的區別。 它完全顛覆傳統版本控制的作法。 這使用Git更像一個上層具備更強大工具的小型檔案系統，而不只是版本控制系統。 我們將會在第三章介紹分支時，提到採用此種作法的優點。
+這是 Git 與所有其它版本控制系統最重要的區別。它完全顛覆傳統版本控制的作法。這使用 Git 更像一個上層具備更強大工具的小型檔案系統，而不只是版本控制系統。我們將會在第三章介紹分支時，提到採用此種作法的優點。
 
 ### 大部份的操作皆可在本地端完成 ###
 
-大部份Git的操作皆只需要本地端的檔案及資源即可完成。 一般來說並需要到網路上其它電腦提取的資訊。 若讀者使用集中式版本控制系統，大部份的動作皆包含網路延遲的成本。 這項特點讓你覺得Git處理資料的速度飛快。 因為整個專案的歷史皆存在你的硬碟中，大部份的運作看起來幾乎都是馬上完成。
+大部份 Git 的操作皆只需要本地端的檔案及資源即可完成。一般來說並需要到網路上其它電腦提取的資訊。若讀者使用集中式版本控制系統，大部份的動作皆包含網路延遲的成本。這項特點讓你覺得 Git 處理資料的速度飛快。因為整個專案的歷史皆存在你的硬碟中，大部份的運作看起來幾乎都是馬上完成。
 
-例如：想要瀏覽專案的歷史時，Git不需要到伺服器下載歷史，而是從本地端的資料庫讀取並顯示即可。 這意謂著讀者幾乎馬上就可以看到專案的歷史。 若讀者想瞭解某個檔案一個月前的版本及現在版本的差別，Git可在本地端找出一個月前的檔案並在比對兩者的差異，而不是要求遠端的伺服器執行這項工作，或者從伺服器取回舊版本的檔案並在本地端比對。
+例如：想要瀏覽專案的歷史時，Gi t不需要到伺服器下載歷史，而是從本地端的資料庫讀取並顯示即可。這意謂著讀者幾乎馬上就可以看到專案的歷史。若讀者想瞭解某個檔案一個月前的版本及現在版本的差別，Git 可在本地端找出一個月前的檔案並在比對兩者的差異，而不是要求遠端的伺服器執行這項工作，或者從伺服器取回舊版本的檔案並在本地端比對。
 
-這意謂著即使讀者已離線，或者切斷VPN連線後，也很少有讀者無法執行的動作。 若讀者在飛機或火車上，並想要做一些工作，讀者在取得可上傳的網路前仍可很快樂地提交更新。 若讀者回到家且無法讓VPN連線程式正常運作，讀者仍然可繼續工作。 在許多其它系統幾乎是無法做這些事或者必須付出很大代價。 以Perforce為例，在無法連到伺服器時讀者做不了多少事。以Subversion及CVS為例，雖然讀者能編輯檔案，但因為資料庫此時是離線的，讀者無法提交更新到資料庫。 這看起來可能還不是什麼大問題，但讀者可能驚訝Git有這麼大的不同。
+這意謂著即使讀者已離線，或者切斷 VPN 連線後，也很少有讀者無法執行的動作。若讀者在飛機或火車上，並想要做一些工作，讀者在取得可上傳的網路前仍可很快樂地提交更新。若讀者回到家且無法讓 VPN 連線程式正常運作，讀者仍然可繼續工作。在許多其它系統幾乎是無法做這些事或者必須付出很大代價。以 Perforce 為例，在無法連到伺服器時讀者做不了多少事。以 Subversion 及 CVS 為例，雖然讀者能編輯檔案，但因為資料庫此時是離線的，讀者無法提交更新到資料庫。這看起來可能還不是什麼大問題，但讀者可能驚訝 Git 有這麼大的不同。
 
 ### Git能檢查完整性 ###
 
-在Git中所有的物件在儲存前都會被計算查核碼(`checksum`)並以查核碼檢索物件。 這意謂著Git不可能不清楚任何檔案或目錄的內容已被更動。 此功能內建在Git底層並整合到它的設計哲學。 Git能夠馬上察覺傳輸時的遺失或是檔案的毀損。
+在 Git 中所有的物件在儲存前都會被計算查核碼 (`checksum`) 並以查核碼檢索物件。這意謂著 Git 不可能不清楚任何檔案或目錄的內容已被更動。此功能內建在 Git 底層並整合到它的設計哲學。 Git 能夠馬上察覺傳輸時的遺失或是檔案的毀損。
 
-Git用來計算查核碼的機制稱為SHA-1雜湊法。 它由40個十六進制的字母(0–9 and a–f)組成的字串組成，基於Git的檔案內容或者目錄結構計算。 查核碼看起來如下所示：
+Git 用來計算查核碼的機制稱為 SHA-1 雜湊法。它由 40 個十六進制的字母 (0–9 and a–f) 組成的字串組成，基於 Git 的檔案內容或者目錄結構計算。 查核碼看起來如下所示：
 
 	24b9da6552252987aa493b52f8696cd6d3b00373
 
-讀者會Git中到處都看到雜湊值，因為它到處被使用。 事實上Git以檔案內容的雜湊值定址出檔案在資料庫的位址，而不是以檔案的名稱定址。
+讀者會 Git 中到處都看到雜湊值，因為它到處被使用。事實上 Git 以檔案內容的雜湊值定址出檔案在資料庫的位址，而不是以檔案的名稱定址。
 
 ### Git 通常只增加資料 ###
 
-當讀者使用Git，幾乎所有的動作只是增加資料到Git的資料庫。 很難藉此讓做出讓系統無法復原或者清除資料的動作。 在任何版本控制系統，讀者有可能會遺失或者搞混尚未提交的更新。 但是在提交快照到Git後，很少會有遺失的情況，特別是讀者定期將資料庫更新到其它儲存庫。
+當讀者使用 Git，幾乎所有的動作只是增加資料到 Git 的資料庫。很難藉此讓做出讓系統無法復原或者清除資料的動作。在任何版本控制系統，讀者有可能會遺失或者搞混尚未提交的更新。但是在提交快照到 Git 後，很少會有遺失的情況，特別是讀者定期將資料庫更新到其它儲存庫。
 
-這讓使用Git可輕鬆地像在玩一樣，因為我們知道我們可以進行任何實驗而不會破壞任何東西。 在第九章的“底層細節”中，我們會進一步討論Git如何儲存資料，以及讀者如何復原看似遺失的資料。
+這讓使用 Git 可輕鬆地像在玩一樣，因為我們知道我們可以進行任何實驗而不會破壞任何東西。在第九章的 “底層細節” 中，我們會進一步討論 Git 如何儲存資料，以及讀者如何復原看似遺失的資料。
 
 ### 三種狀態 ###
 
-現在，注意。 若讀者希望接下來的學習過程順利些，這是關於Git的重要且需記住的事項。 Git有三種表達檔案的狀態：已提交(committed)、已修改(modified)及已暫存(staged)。 已提交意謂著資料己安全地存在讀者的本地端資料庫。 己修改代表著讀者已修改檔案但尚未提交到資料庫。 已暫存意謂著讀者標記已修改檔案目前的版本到下一次提供的快照。
+現在，注意。 若讀者希望接下來的學習過程順利些，這是關於 Git 的重要且需記住的事項。Git 有三種表達檔案的狀態：已提交 (committed)、已修改 (modified) 及已暫存 (staged)。已提交意謂著資料己安全地存在讀者的本地端資料庫。己修改代表著讀者已修改檔案但尚未提交到資料庫。已暫存意謂著讀者標記已修改檔案目前的版本到下一次提供的快照。
 
-這帶領我們到Git專案的三個主要區域：Git目錄、工作目錄(working directory)以及暫存區域(staging area)。
+這帶領我們到 Git 專案的三個主要區域：Git 目錄、工作目錄 (working directory) 以及暫存區域 (staging area)。
 
 Insert 18333fig0106.png
-圖1-6. 工作目錄、暫存區域及git目錄。
+圖 1-6. 工作目錄、暫存區域及 Git 目錄。
 
-Git目錄是Git用來儲存讀者的專案的metadata及物件資料庫。 這是Git最重要的部份，而且它是當讀者從其它電腦複製儲存庫時會複製過來的。
+Git 目錄是 Git 用來儲存讀者的專案的 metadata 及物件資料庫。這是 Git 最重要的部份，而且它是當讀者從其它電腦複製儲存庫時會複製過來的。
 
-工作目錄是專案被取出的某一個版本。 這些檔案從Git目錄內被壓縮過的資料庫中拉出來並放在磁碟機供讀者使用或修改。
+工作目錄是專案被取出的某一個版本。這些檔案從 Git 目錄內被壓縮過的資料庫中拉出來並放在磁碟機供讀者使用或修改。
 
-暫存區域是一個單純的檔案，一般來說放在Git目錄，儲存關於下一個提交的資訊。 有時稱為索引，但現在將它稱為暫存區域已開始成為標準。
+暫存區域是一個單純的檔案，一般來說放在 Git 目錄，儲存關於下一個提交的資訊。有時稱為索引，但現在將它稱為暫存區域已開始成為標準。
 
-基本Git工作流程大致如下：
+基本 Git 工作流程大致如下：
 
 1. 讀者修改工作目錄內的檔案。
 2. 暫存檔案，將檔案的快照新增到暫存區域。
-3. 做提交的動作，這會讓存在暫存區域的檔案快照永久地儲存在Git目錄。
+3. 做提交的動作，這會讓存在暫存區域的檔案快照永久地儲存在 Git 目錄。
 
-在Git目錄內特定版本的檔案被認定為已提交。 若檔案被修改且被增加到暫存區域，稱為被暫存。 若檔案被取出後有被修改，但未被暫存，稱為被修改。 在第二章讀者會學到更多關於這些狀態以及如何利用它們的優點或者整個略過暫存步驟。
+在 Git 目錄內特定版本的檔案被認定為已提交。若檔案被修改且被增加到暫存區域，稱為被暫存。若檔案被取出後有被修改，但未被暫存，稱為被修改。在第二章讀者會學到更多關於這些狀態以及如何利用它們的優點或者整個略過暫存步驟。
 
-## 安裝Git ##
+## 安裝 Git ##
 
-讓我們開始使用Git。 首先讀者要做的事是安裝Git。 讀者有很多取得它們的方法。 主要的兩種分別是從原始碼安裝或者從讀者使用平台現存的套件安裝。
+讓我們開始使用 Git。首先讀者要做的事是安裝 Git。讀者有很多取得它們的方法。主要的兩種分別是從原始碼安裝或者從讀者使用平台現存的套件安裝。
 
 ### 從原始碼安裝 ###
 
-若讀者有能力的話，從原始碼安裝是非常有用的。 因為讀者能取得最新版本。 每一版Git通常都會包含有用的UI改善。 因此取得最新版本通常是最好的，只要讀者覺得編譯軟體的原始碼是很容易的。 許多Linux發行套件通常都是附上非常舊的套件。 除非讀者使用的發行套件非常新或者使用向後相容的移植版本。 從原始碼安裝通常是最好的選擇。
+若讀者有能力的話，從原始碼安裝是非常有用的。因為讀者能取得最新版本。每一版Git通常都會包含有用的 UI 改善。因此取得最新版本通常是最好的，只要讀者覺得編譯軟體的原始碼是很容易的。許多 Linux 發行套件通常都是附上非常舊的套件。除非讀者使用的發行套件非常新或者使用向後相容的移植版本。從原始碼安裝通常是最好的選擇。
 
-要安裝Git，讀者需要先安裝它需要的程式庫：curl、zlib、openssl、expat及libiconv。 例如：若讀者的系統有yum（如：Fedora）或apt-get（如：以Debian為基礎的系統），讀者可使用下列任一命令安裝所有需要的程式庫：
+要安裝 Git，讀者需要先安裝它需要的程式庫：curl, zlib, openssl, expat 及 libiconv。例如：若讀者的系統有 yum (如：Fedora) 或 apt-get (如：以 Debian 為基礎的系統)，讀者可使用下列任一命令安裝所有需要的程式庫：
 
 	$ yum install curl-devel expat-devel gettext-devel \
 	  openssl-devel zlib-devel
@@ -134,7 +134,7 @@ Git目錄是Git用來儲存讀者的專案的metadata及物件資料庫。 這
 	$ apt-get install libcurl4-gnutls-dev libexpat1-dev gettext \
 	  libz-dev libssl-dev
 
-當讀者安裝所有必要的程式庫，讀者可到Git的網站取得最新版本：
+當讀者安裝所有必要的程式庫，讀者可到 Git 的網站取得最新版本：
 
 	http://git-scm.com/download
 
@@ -145,79 +145,79 @@ Git目錄是Git用來儲存讀者的專案的metadata及物件資料庫。 這
 	$ make prefix=/usr/local all
 	$ sudo make prefix=/usr/local install
 
-在這些工作完成後，讀者也可以使用Git取得Git的更新版：
+在這些工作完成後，讀者也可以使用 Git 取得 Git 的更新版：
 
 	$ git clone git://git.kernel.org/pub/scm/git/git.git
 
-### 在Linux系統安裝 ###
+### 在 Linux 系統安裝 ###
 
-若讀者想使用二進位安裝程式安裝Git到Linux，一般來說讀者可經由發行套件提供的套件管理工具完成此工作。 若讀者使用Fedora，可使用`yum`：
+若讀者想使用二進位安裝程式安裝 Git 到 Linux，一般來說讀者可經由發行套件提供的套件管理工具完成此工作。若讀者使用 Fedora，可使用 `yum`：
 
 	$ yum install git-core
 
-若讀者在以Debian為基礎的發行套件，如：Ubuntu。 試試`apt-get`：
+若讀者在以 Debian 為基礎的發行套件，如：Ubuntu。 試試 `apt-get`：
 
 	$ apt-get install git
 
-### 在Mac系統安裝 ###
+### 在 Mac 系統安裝 ###
 
-有兩種很容易將Git安裝到Mac的方法。 最簡單的是使用圖形化界面的Git安裝程式，可從SourceForge下載）圖1－7）：
+有兩種很容易將 Git 安裝到 Mac 的方法。最簡單的是使用圖形化界面的 Git 安裝程式，可從 SourceForge 下載 (圖 1－7)：
 
 	http://sourceforge.net/projects/git-osx-installer/
 
 Insert 18333fig0107.png
 圖1-7. Git OS X 安裝程式。
 
-藉由MacPorts安裝Git是另一種主要的方法。 若讀者已安裝MacPorts，使用下列命令安裝Git
+藉由 MacPorts 安裝 Git 是另一種主要的方法。若讀者已安裝 MacPorts，使用下列命令安裝 Git
 
 	$ sudo port install git-core +svn +doc +bash_completion +gitweb
 
-讀者完全不需要安裝所有的額外套件，但讀者可能會想要加上`+svn`參數，以利於使用Git讀寫Subversion儲存庫（參考第8章）。
+讀者完全不需要安裝所有的額外套件，但讀者可能會想要加上 `+svn` 參數，以利於使用 Git 讀寫 Subversion 儲存庫 (參考第 8 章)。
 
-### 在Windows系統安裝 ###
+### 在 Windows 系統安裝 ###
 
-在Windows系統安裝Git相當地容易。 msysGit專案已提供相當容易安裝的程序。 只要從GitHub網頁下載安裝程式並執行即可：
+在 Windows 系統安裝 Git 相當地容易。msysGit 專案已提供相當容易安裝的程序。只要從 GitHub 網頁下載安裝程式並執行即可：
 
 	http://msysgit.github.com/
 
-在安裝完畢後，讀者同時會有命令列版本（包含SSH客戶端程式）及標準的圖形界面版本。
+在安裝完畢後，讀者同時會有命令列版本 (包含 SSH 客戶端程式) 及標準的圖形界面版本。
 
 Note on Windows usage: you should use Git with the provided msysGit shell (Unix style), it allows to use the complex lines of command given in this book. If you need, for some reason, to use the native Windows shell / command line console, you have to use double quotes instead of simple quotes (for parameters with spaces in them) and you must quote the parameters ending with the circumflex accent (^) if they are last on the line, as it is a continuation symbol in Windows.
 
-## 初次設定Git ##
+## 初次設定 Git ##
 
-現在讀者的系統已安裝了Git，讀者可能想要做一些客製化的動作。 讀者應只需要做這些工作一次。 這些設定在更新版本時會被保留下來。 讀者可藉由再度執行命令的方式再度修改這些設定。
+現在讀者的系統已安裝了 Git，讀者可能想要做一些客製化的動作。讀者應只需要做這些工作一次。這些設定在更新版本時會被保留下來。讀者可藉由再度執行命令的方式再度修改這些設定。
 
-Git附帶名為`git config`的工具，允許讀者取得及設定組態參數，可用來決定Git外觀及運作。 這些參數可存放在以下三個地方：
+Git 附帶名為 `git config` 的工具，允許讀者取得及設定組態參數，可用來決定 Git 外觀及運作。這些參數可存放在以下三個地方：
 
-*	檔案 `/etc/gitconfig`： 包含給該系統所有使用者的儲存庫使用的數值。 只要讀者傳遞 --system 參數給 git config，它就會讀取或者寫入參數到這個檔案
+*	檔案 `/etc/gitconfig`： 包含給該系統所有使用者的儲存庫使用的數值。 只要讀者傳遞 --system 參數給 git config，它就會讀取或者寫入參數到這個檔案。
 *	檔案 `~/.gitconfig`： 給讀者自己的帳號使用。 傳遞 --global 參數給 git config，它就會讀取或者寫入參數到這個檔案。
-*	儲存庫內的設定檔，也就是 `.git/config`： 僅給所在的儲存庫使用。 每個階級的設定會覆寫上一層的。 因此，`git/config`內的設定值的優先權高過`/etc/config`。
+*	儲存庫內的設定檔，也就是 `.git/config`： 僅給所在的儲存庫使用。 每個階級的設定會覆寫上一層的。 因此，`git/config` 內的設定值的優先權高過 `/etc/config`。
 
-在Windows系統，Git在`$HOME`目錄(對大部份使用者來說是`C:\Documents and Settings\$USER`)內尋找`.gitconfig`。 它也會尋找`/etc/gitconfig`，只不過它是相對於Msys根目錄，取決於讀者當初在Windows系統執行Git的安裝程式時安裝的目的地。
+在 Windows 系統，Git 在 `$HOME` 目錄 (對大部份使用者來說是 `C:\Documents and Settings\$USER`) 內尋找 `.gitconfig`。 它也會尋找 `/etc/gitconfig`，只不過它是相對於 Msys 根目錄，取決於讀者當初在 Windows 系統執行 Git 的安裝程式時安裝的目的地。
 
 ### 設定識別資料 ###
 
-讀者安裝Git後首先應該做的事是指定使用者名稱及電子郵件帳號。 這一點非常重要，因為每次Git提交會使用這些資訊，而且提交後不能再被修改：
+讀者安裝 Git 後首先應該做的事是指定使用者名稱及電子郵件帳號。這一點非常重要，因為每次 Git 提交會使用這些資訊，而且提交後不能再被修改：
 
 	$ git config --global user.name "John Doe"
 	$ git config --global user.email johndoe@example.com
 
-再說一次，若讀者有指定 `--global` 參數，只需要做這工作一次。 因為在此系統，不論Git做任何事都會採用此資訊。 若讀者想指定不同的名字或電子郵件給特定的專案， 只需要在該專案目錄內執行此命令，並確定未加上 `--global` 參數。
+再說一次，若讀者有指定 `--global` 參數，只需要做這工作一次。因為在此系統，不論 Git 做任何事都會採用此資訊。若讀者想指定不同的名字或電子郵件給特定的專案，只需要在該專案目錄內執行此命令，並確定未加上 `--global` 參數。
 
 ### 指定編輯器 ###
 
-現在讀者的識別資料已設定完畢，讀者可設定預設的文書編輯器，當Git需要讀者輸入訊息時會叫用它。 預設情況下，Git會使用系統預設的編輯器，一般來說是Vi或Vim。 若讀者想指定不同的編輯器，例如：Emacs。可執行下列指令：
+現在讀者的識別資料已設定完畢，讀者可設定預設的文書編輯器，當 Git 需要讀者輸入訊息時會叫用它。預設情況下，Git 會使用系統預設的編輯器，一般來說是 Vi 或 Vim。若讀者想指定不同的編輯器，例如：Emacs。可執行下列指令：
 
 	$ git config --global core.editor emacs
 
 ### 指定合併工具 ###
 
-另外一個對讀者來說有用的選項是設定解決合併失敗時，讀者慣用的合併工具。 假設讀者想使用vimdiff：
+另外一個對讀者來說有用的選項是設定解決合併失敗時，讀者慣用的合併工具。假設讀者想使用 vimdiff：
 
 	$ git config --global merge.tool vimdiff
 
-Git能接受kdiff3、tkdiff、meld、xxdiff、emerge、vimdiff、gvimdiff、ecmerge及opendiff做為合併工具。 讀者可設定自訂的工具。 詳情參考第七章。
+Git 能接受 kdiff3, tkdiff, meld, xxdiff, emerge, vimdiff, gvimdiff, ecmerge 及 opendiff 做為合併工具。讀者可設定自訂的工具。詳情參考第七章。
 
 ### 檢查讀者的設定 ###
 
@@ -232,28 +232,29 @@ Git能接受kdiff3、tkdiff、meld、xxdiff、emerge、vimdiff、gvimdiff、ecme
 	color.diff=auto
 	...
 
-讀者可能會看到同一個設定名稱出現多次，因為Git從不同的檔案讀到同一個設定名稱（例如：`/etc/gitconfig`及`~/.gitconfig`）。 在這情況下，Git會使用最後一個設定名稱的設定值。
+讀者可能會看到同一個設定名稱出現多次，因為 Git 從不同的檔案讀到同一個設定名稱 (例如：`/etc/gitconfig` 及 `~/.gitconfig`)。在這情況下，Git 會使用最後一個設定名稱的設定值。
 
-使用者也可以下列命令 `git config` 設定名稱，檢視Git認為該設定名稱的設定值：
+使用者也可以下列命令 `git config` 設定名稱，檢視 Git 認為該設定名稱的設定值：
 
 	$ git config user.name
 	Scott Chacon
 
 ## 取得說明文件 ##
 
-若讀者在使用Git時需要幫助，有三種方法取得任何Git命令的手冊：
+若讀者在使用 Git 時需要幫助，有三種方法取得任何 Git 命令的手冊：
 
 	$ git help <verb>
 	$ git <verb> --help
 	$ man git-<verb>
 
-例如：讀者可以下列命令取得config命令的手冊
+例如：讀者可以下列命令取得 config 命令的手冊
 
 	$ git help config
 
 這些命令對讀者是很有幫助的，因為讀者可在任意地方取得它們，即使已離線。
-若手冊及這本書不足以幫助讀者，且讀者需要更進一步的協助。 讀者可試著進入Freenode IRC伺服器（irc.freenode.net）的`#git`或`#github`頻道。 這些頻道平時都有上百位對Git非常瞭解的高手而且通常樂意協助。
+若手冊及這本書不足以幫助讀者，且讀者需要更進一步的協助。 讀者可試著進入 Freenode IRC 伺服器 (irc.freenode.net) 的 `#git` 或 `#github` 頻道。這些頻道平時都有上百位對 Git 非常瞭解的高手而且通常樂意協助。
 
 ## 總結 ##
 
-目前讀者應該對於Git有一些基本的瞭解，而且知道它與其它集中式版本控制系統的不同，其中有些可能是讀者正在使用的。 讀者的系統現在也應該有一套可動作的Git且已設定好讀者個人的識別資料。 現在正是學習一些Git基本操作的好時機。
+目前讀者應該對於 Git 有一些基本的瞭解，而且知道它與其它集中式版本控制系統的不同，其中有些可能是讀者正在使用的。讀者的系統現在也應該有一套可動作的 Git 且已設定好讀者個人的識別資料。現在正是學習一些 Git 基本操作的好時機。
+

From ecc68df6de090dd1e9b21646a638899f72bf8ec5 Mon Sep 17 00:00:00 2001
From: Marcelo Jorge Vieira <metal@alucinados.com>
Date: Sun, 23 Oct 2016 14:11:15 -0200
Subject: [PATCH 688/690] Fixed typos in
 pt-br/02-git-basics/01-chapter2.markdown
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Changes:

  * Replaced 'comanto' with 'comando';
  * Replaced 'aquivo' with 'arquivos';
  * Replaced 'commitar' with 'comitar'
  * Replaced 'commite' with 'comitar';
  * Replaced 'asterísco' with 'asterisco';
  * Replaced 'commitado' with 'comitado';
  * Replaced 'saida' with 'saída';
  * Replaced 'ferramente' with 'ferramenta'
  * Replaced 'simultâneamente' with 'simultâneamente';
  * Replaced 'commitada' with 'comitada';
  * Replaced 'sevidor' with 'servidor';
  * Replaced 'taggeado' with 'tagueado';
  * Replaced 'taggear' with 'taguear';
  * Replaced 'Taggeando' with 'Tagueando'.
---
 pt-br/02-git-basics/01-chapter2.markdown | 38 ++++++++++++------------
 1 file changed, 19 insertions(+), 19 deletions(-)

diff --git a/pt-br/02-git-basics/01-chapter2.markdown b/pt-br/02-git-basics/01-chapter2.markdown
index d4b0201cb..e687710b2 100644
--- a/pt-br/02-git-basics/01-chapter2.markdown
+++ b/pt-br/02-git-basics/01-chapter2.markdown
@@ -88,11 +88,11 @@ Se você rodar o comando status novamente, você pode ver que o seu arquivo `REA
     #    new file:   README
     #
 
-Você pode dizer que ele está selecionado pois está sob o cabeçalho “Changes to be committed”. Se você commitar neste ponto, a versão do arquivo no momento em que você rodou o comando `git add` é a que estará na captura (snapshot) do histórico. Você deve se lembrar que quando rodou o comando `git init` anteriormente, logo em seguida rodou o comando `git add (arquivos)` — fez isso para passar a monitorar os arquivos em seu diretório. O comando `git add` recebe um caminho de um arquivo ou diretório; se é de um diretório, o comando adiciona todos os arquivos do diretório recursivamente.
+Você pode dizer que ele está selecionado pois está sob o cabeçalho “Changes to be committed”. Se você comitar neste ponto, a versão do arquivo no momento em que você rodou o comando `git add` é a que estará na captura (snapshot) do histórico. Você deve se lembrar que quando rodou o comando `git init` anteriormente, logo em seguida rodou o comando `git add (arquivos)` — fez isso para passar a monitorar os arquivos em seu diretório. O comando `git add` recebe um caminho de um arquivo ou diretório; se é de um diretório, o comando adiciona todos os arquivos do diretório recursivamente.
 
 ### Selecionando Arquivos Modificados ###
 
-Vamos alterar um arquivo que já está sendo monitorado. Se você alterar um aquivo previamente monitorado chamado `benchmarks.rb` e então rodar o comando `status` novamente, você terá algo semelhante a:
+Vamos alterar um arquivo que já está sendo monitorado. Se você alterar um arquivo previamente monitorado chamado `benchmarks.rb` e então rodar o comando `status` novamente, você terá algo semelhante a:
 
     $ git status
     # On branch master
@@ -107,7 +107,7 @@ Vamos alterar um arquivo que já está sendo monitorado. Se você alterar um aqu
     #    modified:   benchmarks.rb
     #
 
-O arquivo `benchmarks.rb` aparece sob a seção chamada “Changes not staged for commit” — que significa que um arquivo monitorado foi modificado no diretório de trabalho, mas ainda não foi selecionado (staged). Para selecioná-lo, utilize o comando `git add` (é um comando com várias funções — você o utiliza para monitorar novos arquivos, selecionar arquivos, e para fazer outras coisas como marcar como resolvido aquivos com conflito). Agora vamos rodar o comando `git add` para selecionar o arquivo `benchmarks.rb`, e então rodar `git status` novamente:
+O arquivo `benchmarks.rb` aparece sob a seção chamada “Changes not staged for commit” — que significa que um arquivo monitorado foi modificado no diretório de trabalho, mas ainda não foi selecionado (staged). Para selecioná-lo, utilize o comando `git add` (é um comando com várias funções — você o utiliza para monitorar novos arquivos, selecionar arquivos, e para fazer outras coisas como marcar como resolvido arquivos com conflito). Agora vamos rodar o comando `git add` para selecionar o arquivo `benchmarks.rb`, e então rodar `git status` novamente:
 
     $ git add benchmarks.rb
     $ git status
@@ -119,7 +119,7 @@ O arquivo `benchmarks.rb` aparece sob a seção chamada “Changes not staged fo
     #    modified:   benchmarks.rb
     #
 
-Ambos os arquivos estão selecionados e serão consolidados no seu próximo commit. Neste momento, vamos supor que você lembrou de uma mudança que queria fazer no arquivo `benchmarks.rb` antes de commitá-lo. Você o abre novamente e faz a mudança, e então está pronto para commitar. No entanto, vamos rodar `git status` mais uma vez:
+Ambos os arquivos estão selecionados e serão consolidados no seu próximo commit. Neste momento, vamos supor que você lembrou de uma mudança que queria fazer no arquivo `benchmarks.rb` antes de commitá-lo. Você o abre novamente e faz a mudança, e então está pronto para comitar. No entanto, vamos rodar `git status` mais uma vez:
 
     $ vim benchmarks.rb
     $ git status
@@ -156,7 +156,7 @@ Muitas vezes, você terá uma classe de arquivos que não quer que o Git automat
     *.[oa]
     *~
 
-A primeira linha fala para o Git ignorar qualquer arquivo finalizado em `.o` ou `.a` — arquivos *objetos* e *archive* (compactados) que devem ter produto da construção (build) de seu código. A segunda linha fala para o Git ignorar todos os arquivos que terminam com um til (`~`), os quais são utilizados por muitos editores de texto como o Emacs para marcar arquivos temporários. Você também pode incluir um diretório `log`, `tmp` ou `pid`; documentação gerada automaticamente; e assim por diante. Configurar um arquivo `.gitignore` antes de começar a trabalhar, normalmente é uma boa ideia, pois evita que você commite acidentalmente arquivos que não deveriam ir para o seu repositório Git.
+A primeira linha fala para o Git ignorar qualquer arquivo finalizado em `.o` ou `.a` — arquivos *objetos* e *archive* (compactados) que devem ter produto da construção (build) de seu código. A segunda linha fala para o Git ignorar todos os arquivos que terminam com um til (`~`), os quais são utilizados por muitos editores de texto como o Emacs para marcar arquivos temporários. Você também pode incluir um diretório `log`, `tmp` ou `pid`; documentação gerada automaticamente; e assim por diante. Configurar um arquivo `.gitignore` antes de começar a trabalhar, normalmente é uma boa ideia, pois evita que você comitar acidentalmente arquivos que não deveriam ir para o seu repositório Git.
 
 As regras para os padrões que você pode pôr no arquivo `.gitignore` são as seguintes:
 
@@ -165,7 +165,7 @@ As regras para os padrões que você pode pôr no arquivo `.gitignore` são as s
 * Você pode terminar os padrões com uma barra (`/`) para especificar diretórios.
 * Você pode negar um padrão ao iniciá-lo com um ponto de exclamação (`!`).
 
-Padrões glob são como expressões regulares simples que os shells usam. Um asterísco (`*`) significa zero ou mais caracteres; `[abc]` condiz com qualquer um dos caracteres de dentro dos colchetes (nesse caso, a, b, ou c); um ponto de interrogação (`?`) condiz com um único caractere; e os caracteres separados por hífen dentro de colchetes (`[0-9]`) condizem à qualquer um dos caracteres entre eles (neste caso, de 0 à 9).
+Padrões glob são como expressões regulares simples que os shells usam. Um asterisco (`*`) significa zero ou mais caracteres; `[abc]` condiz com qualquer um dos caracteres de dentro dos colchetes (nesse caso, a, b, ou c); um ponto de interrogação (`?`) condiz com um único caractere; e os caracteres separados por hífen dentro de colchetes (`[0-9]`) condizem à qualquer um dos caracteres entre eles (neste caso, de 0 à 9).
 
 Segue um outro exemplo de arquivo `.gitignore`:
 
@@ -183,7 +183,7 @@ Segue um outro exemplo de arquivo `.gitignore`:
 
 ### Visualizando Suas Mudanças Selecionadas e Não Selecionadas ###
 
-Se o comando `git status` for muito vago — você quer saber exatamente o que você alterou, não apenas quais arquivos foram alterados — você pode utilizar o comando `git diff`. Nós trataremos o comando `git diff` em mais detalhes posteriormente; mas provavelmente você vai utilizá-lo com frequência para responder estas duas perguntas: O que você alterou, mas ainda não selecionou (stage)? E o que você selecionou, que está para ser commitado? Apesar do comando `git status` responder essas duas perguntas de maneira geral, o `git diff` mostra as linhas exatas que foram adicionadas e removidas — o patch, por assim dizer.
+Se o comando `git status` for muito vago — você quer saber exatamente o que você alterou, não apenas quais arquivos foram alterados — você pode utilizar o comando `git diff`. Nós trataremos o comando `git diff` em mais detalhes posteriormente; mas provavelmente você vai utilizá-lo com frequência para responder estas duas perguntas: O que você alterou, mas ainda não selecionou (stage)? E o que você selecionou, que está para ser comitado? Apesar do comando `git status` responder essas duas perguntas de maneira geral, o `git diff` mostra as linhas exatas que foram adicionadas e removidas — o patch, por assim dizer.
 
 Vamos dizer que você edite e selecione o arquivo `README` de novo e então edite o arquivo `benchmarks.rb` sem selecioná-lo. Se você rodar o comando `status`, você novamente verá algo assim:
 
@@ -312,7 +312,7 @@ O editor mostra o seguinte texto (este é um exemplo da tela do Vim):
 
 Você pode ver que a mensagem default do commit contém a última saída do comando `git status` comentada e uma linha vazia no início. Você pode remover estes comentários e digitar sua mensagem de commit, ou pode deixá-los ai para ajudar a lembrar o que está commitando. (Para um lembrete ainda mais explícito do que foi modificado, você pode passar a opção `-v` para o `git commit`. Ao fazer isso, aparecerá a diferença (diff) da sua mudança no editor para que possa ver exatamente o que foi feito.) Quando você sair do editor, o Git criará o seu commit com a mensagem (com os comentários e o diff retirados).
 
-Alternativamente, você pode digitar sua mensagem de commit junto ao comanto `commit` ao especificá-la após a flag `-m`, assim:
+Alternativamente, você pode digitar sua mensagem de commit junto ao comando `commit` ao especificá-la após a flag `-m`, assim:
 
     $ git commit -m "Story 182: Fix benchmarks for speed"
     [master]: created 463dc4f: "Fix benchmarks for speed"
@@ -344,7 +344,7 @@ Note que, neste caso, você não precisa rodar o `git add` no arquivo `benchmark
 
 Para remover um arquivo do Git, você tem que removê-lo dos arquivos que estão sendo monitorados (mais precisamente, removê-lo da sua área de seleção) e então fazer o commit. O comando `git rm` faz isso e também remove o arquivo do seu diretório para você não ver ele como arquivo não monitorado (untracked file) na próxima vez.
 
-Se você simplesmente remover o arquivo do seu diretório, ele aparecerá em “Changes not staged for commit” (isto é, fora da sua área de seleção ou _unstaged_) na saida do seu `git status`:
+Se você simplesmente remover o arquivo do seu diretório, ele aparecerá em “Changes not staged for commit” (isto é, fora da sua área de seleção ou _unstaged_) na saída do seu `git status`:
 
     $ rm grit.gemspec
     $ git status
@@ -416,7 +416,7 @@ O Git descobre que o arquivo foi renomeado implicitamente, então ele não se im
 
 ## Visualizando o Histórico de Commits ##
 
-Depois que você tiver criado vários commits, ou se clonou um repositório com um histórico de commits existente, você provavelmente vai querer ver o que aconteceu. A ferramente mais básica e poderosa para fazer isso é o comando `git log`.
+Depois que você tiver criado vários commits, ou se clonou um repositório com um histórico de commits existente, você provavelmente vai querer ver o que aconteceu. A ferramenta mais básica e poderosa para fazer isso é o comando `git log`.
 
 Estes exemplos usam um projeto muito simples chamado `simplegit`, que eu frequentemente uso para demonstrações. Para pegar o projeto, execute:
 
@@ -593,7 +593,7 @@ No entanto, as opções de limites de tempo como `--since` e `--until` são muit
 
 Este comando funciona com vários formatos — você pode especificar uma data específica(“2008-01-15”) ou uma data relativa como “2 years 1 day 3 minutes ago”.
 
-Você pode ainda filtrar a lista de commits que casam com alguns critérios de busca. A opção `--author` permite que você filtre por algum autor específico, e a opção `--grep` deixa você buscar por palavras chave nas mensagens dos commits. (Note que se você quiser especificar ambas as opções author e grep simultâneamente, você deve adicionar `--all-match`, ou o comando considerará commits que casam com qualquer um.)
+Você pode ainda filtrar a lista de commits que casam com alguns critérios de busca. A opção `--author` permite que você filtre por algum autor específico, e a opção `--grep` deixa você buscar por palavras chave nas mensagens dos commits. (Note que se você quiser especificar ambas as opções author e grep simultaneamente, você deve adicionar `--all-match`, ou o comando considerará commits que casam com qualquer um.)
 
 A última opção realmente útil para passar para `git log` como um filtro, é o caminho. Se você especificar um diretório ou um nome de arquivo, você pode limitar a saída a commits que modificaram aqueles arquivos. Essa é sempre a última opção, e geralmente é precedida por dois traços (`--`) para separar caminhos das opções.
 
@@ -606,7 +606,7 @@ Na Tabela 2-3 nós listamos estas e outras opções comuns para sua referência.
 	--author	Somente mostra commits que o autor casa com a string especificada.
 	--committer	Somente mostra os commits em que a entrada do commiter bate com a string especificada.
 
-Por exemplo, se você quer ver quais commits modificaram arquivos de teste no histórico do código fonte do Git que foram commitados por Julio Hamano em Outubro de 2008, e não foram merges, você pode executar algo como:
+Por exemplo, se você quer ver quais commits modificaram arquivos de teste no histórico do código fonte do Git que foram comitados por Julio Hamano em Outubro de 2008, e não foram merges, você pode executar algo como:
 
     $ git log --pretty="%h - %s" --author=gitster --since="2008-10-01" \
        --before="2008-11-01" --no-merges -- t/
@@ -708,7 +708,7 @@ Ele diz explicitamente como descartar as modificações que você fez (pelo meno
 
 Você pode ver que as alterações foram revertidas. Perceba também que esse comando é perigoso: qualquer alteração que você fez nesse arquivo foi desfeita — você acabou de copiar outro arquivo sobre ele. Nunca use esse comando a menos que você tenha certeza absoluta que não quer o arquivo. Se você só precisa tirá-lo do caminho, vamos falar sobre stash e branch no próximo capítulo; geralmente essas são maneiras melhores de agir.
 
-Lembre-se, qualquer coisa que foi incluída com um commit no Git quase sempre pode ser recuperada. Até mesmo commits que estavam em branches que foram apagados ou commits que foram sobrescritos com um commit `--amend` podem ser recuperados (consulte o *Capítulo 9* para recuperação de dados). No entanto, qualquer coisa que você perder que nunca foi commitada, provavelmente nunca mais será vista novamente.
+Lembre-se, qualquer coisa que foi incluída com um commit no Git quase sempre pode ser recuperada. Até mesmo commits que estavam em branches que foram apagados ou commits que foram sobrescritos com um commit `--amend` podem ser recuperados (consulte o *Capítulo 9* para recuperação de dados). No entanto, qualquer coisa que você perder que nunca foi comitada, provavelmente nunca mais será vista novamente.
 
 ## Trabalhando com Remotos ##
 
@@ -786,7 +786,7 @@ Se você tem um branch configurado para acompanhar um branch remoto (veja a pró
 
 ### Pushing Para Seus Remotos ###
 
-Quando o seu projeto estiver pronto para ser compartilhado, você tem que enviá-lo para a fonte. O comando para isso é simples: `git push [nome-remoto] [branch]`. Se você quer enviar o seu branch master para o servidor `origin` (novamente, clonando normalmente define estes dois nomes para você automaticamente), então você pode rodar o comando abaixo para enviar o seu trabalho para o sevidor:
+Quando o seu projeto estiver pronto para ser compartilhado, você tem que enviá-lo para a fonte. O comando para isso é simples: `git push [nome-remoto] [branch]`. Se você quer enviar o seu branch master para o servidor `origin` (novamente, clonando normalmente define estes dois nomes para você automaticamente), então você pode rodar o comando abaixo para enviar o seu trabalho para o servidor:
 
     $ git push origin master
 
@@ -888,7 +888,7 @@ Criando uma tag anotada em Git é simples. O jeito mais fácil é especificar `-
 
 O parâmetro `-m` define uma mensagem, que é armazenada com a tag. Se você não especificar uma mensagem para uma tag anotada, o Git vai rodar seu editor de texto para você digitar alguma coisa.
 
-Você pode ver os dados da tag junto com o commit que foi taggeado usando o comando `git show`:
+Você pode ver os dados da tag junto com o commit que foi tagueado usando o comando `git show`:
 
     $ git show v1.4
     tag v1.4
@@ -903,7 +903,7 @@ Você pode ver os dados da tag junto com o commit que foi taggeado usando o coma
 
         Merge branch 'experiment'
 
-O comando mostra a informação da pessoa que criou a tag, a data de quando o commit foi taggeado, e a mensagem antes de mostrar a informação do commit.
+O comando mostra a informação da pessoa que criou a tag, a data de quando o commit foi tagueado, e a mensagem antes de mostrar a informação do commit.
 
 ### Tags Assinadas ###
 
@@ -940,7 +940,7 @@ Um pouco mais pra frente você aprenderá como verificar tags assinadas.
 
 ### Tags Leves ###
 
-Outro jeito para taggear commits é com a tag leve. Esta é basicamente a chave de verificação armazenada num arquivo — nenhuma outra informação é armazenada. Para criar uma tag leve, não informe os parâmetros `-a`, `-s`, ou `-m`:
+Outro jeito para taguear commits é com a tag leve. Esta é basicamente a chave de verificação armazenada num arquivo — nenhuma outra informação é armazenada. Para criar uma tag leve, não informe os parâmetros `-a`, `-s`, ou `-m`:
 
     $ git tag v1.4-lw
     $ git tag
@@ -984,9 +984,9 @@ Se você não tiver a chave pública, você receberá algo parecido com a respos
     gpg: Can't check signature: public key not found
     error: could not verify the tag 'v1.4.2.1'
 
-### Taggeando Mais Tarde ###
+### Tagueando Mais Tarde ###
 
-Você também pode taggear commits mais tarde. Vamos assumir que o seu histórico de commits seja assim:
+Você também pode taguear commits mais tarde. Vamos assumir que o seu histórico de commits seja assim:
 
     $ git log --pretty=oneline
     15027957951b64cf874c3557a0f3547bd83b3ff6 Merge branch 'experiment'

From 8fabfa132ee95657f17fd666a21998004af1bfd0 Mon Sep 17 00:00:00 2001
From: Manuel Schneider <manuelschneid3r@gmail.com>
Date: Sun, 6 Nov 2016 02:18:00 +0100
Subject: [PATCH 689/690] Fix typo.

---
 de/06-git-tools/01-chapter6.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/de/06-git-tools/01-chapter6.markdown b/de/06-git-tools/01-chapter6.markdown
index e0af3d441..22435d8d2 100644
--- a/de/06-git-tools/01-chapter6.markdown
+++ b/de/06-git-tools/01-chapter6.markdown
@@ -1499,4 +1499,4 @@ Um Dein Verzeichnis `rack` mit dem letzten Stand des Branches `master` auf dem S
 
 <!--You’ve seen a number of advanced tools that allow you to manipulate your commits and staging area more precisely. When you notice issues, you should be able to easily figure out what commit introduced them, when, and by whom. If you want to use subprojects in your project, you’ve learned a few ways to accommodate those needs. At this point, you should be able to do most of the things in Git that you’ll need on the command line day to day and feel comfortable doing so.-->
 
-In diesem Kapitel hast Du viele ausgeklügelte Werzeuge kennengelernt, die es Dir ermöglichen, Commits und die Staging-Area nach Deinen Vorstellungen zu beeinflussen. Wenn ein Problem in Deinem Projekt auftaucht, solltest Du jetzt leicht bestimmen können, welcher Commit den Fehler verursacht hat, sowie wann und von wem der Fehler begangen wurde. Wenn Du andere Projekte in Deinem Projekt verwenden möchtest, hast Du jetzt mehrere Möglichkeiten kennengelernt, wie Du dies handhaben kannst. An dieser Stelle solltest Du jetzt in der Lage sein, die meisten Dinge, die Du bei der täglichen Arbeit benötigst, in der Kommandozeile durchzuführen, ohne dass Dir dabei Schweißperlen auf der Stirn stehen.
+In diesem Kapitel hast Du viele ausgeklügelte Werkzeuge kennengelernt, die es Dir ermöglichen, Commits und die Staging-Area nach Deinen Vorstellungen zu beeinflussen. Wenn ein Problem in Deinem Projekt auftaucht, solltest Du jetzt leicht bestimmen können, welcher Commit den Fehler verursacht hat, sowie wann und von wem der Fehler begangen wurde. Wenn Du andere Projekte in Deinem Projekt verwenden möchtest, hast Du jetzt mehrere Möglichkeiten kennengelernt, wie Du dies handhaben kannst. An dieser Stelle solltest Du jetzt in der Lage sein, die meisten Dinge, die Du bei der täglichen Arbeit benötigst, in der Kommandozeile durchzuführen, ohne dass Dir dabei Schweißperlen auf der Stirn stehen.

From caa3abff1dc7581e852935d1d18e85116fa5878d Mon Sep 17 00:00:00 2001
From: Jakub Brylak <brylakjakub@gmail.com>
Date: Wed, 13 Sep 2017 21:38:43 +0200
Subject: [PATCH 690/690] Removed redundant 'najbardziej' word as used in
 expresion 'najbardziej optymalny' is pleonasm in polish

---
 pl/04-git-server/01-chapter4.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/pl/04-git-server/01-chapter4.markdown b/pl/04-git-server/01-chapter4.markdown
index 28e41f0fe..4f650fddb 100644
--- a/pl/04-git-server/01-chapter4.markdown
+++ b/pl/04-git-server/01-chapter4.markdown
@@ -62,7 +62,7 @@ Możesz także określić użytkownika - Git zakłada użytkownika na którego j
 
 #### Zalety ####
 
-Istnieje wiele zalet korzystania z SSH. Po pierwsze, w zasadzie nie ma innego wyjścia, jeśli wymagany jest uwierzytelniony dostęp podczas zapisu do repozytorium przez sieć. Po drugie - demony SSH są powszechnie wykorzystywane, wielu administratorów sieciowych jest doświadczonych w ich administracji, a wiele systemów operacyjnych posiada je zainstalowane standardowo, bądź zawiera niezbędne do ich zarządzania narzędzia. Dodatkowo, dostęp po SSH jest bezpieczny - cała transmisja jest szyfrowana i uwierzytelniona. Wreszcie, podobnie jak w protokołach Git i lokalnym, SSH jest protokołem efektywnym i pozwalającym na najbardziej optymalny transfer danych z punktu widzenia przepustowości.
+Istnieje wiele zalet korzystania z SSH. Po pierwsze, w zasadzie nie ma innego wyjścia, jeśli wymagany jest uwierzytelniony dostęp podczas zapisu do repozytorium przez sieć. Po drugie - demony SSH są powszechnie wykorzystywane, wielu administratorów sieciowych jest doświadczonych w ich administracji, a wiele systemów operacyjnych posiada je zainstalowane standardowo, bądź zawiera niezbędne do ich zarządzania narzędzia. Dodatkowo, dostęp po SSH jest bezpieczny - cała transmisja jest szyfrowana i uwierzytelniona. Wreszcie, podobnie jak w protokołach Git i lokalnym, SSH jest protokołem efektywnym i pozwalającym na optymalny transfer danych z punktu widzenia przepustowości.
 
 #### Wady ####