diff --git a/book/01-introduction/sections/about-version-control.asc b/book/01-introduction/sections/about-version-control.asc
index 09c0d090..cf9cdd45 100644
--- a/book/01-introduction/sections/about-version-control.asc
+++ b/book/01-introduction/sections/about-version-control.asc
@@ -57,7 +57,7 @@ Even the popular Mac OS X operating system includes the `rcs` command when you i
 RCS works by keeping patch sets (that is, the differences between files) 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.
 //////////////////////////
 もっとも有名なVCSツールの一つは、RCSと呼ばれるシステムでした。今日でも、依然として多くのコンピューターに入っています。
-人気のMac OS Xオペレーティング・システムでも、開発者ツールをインストールすると`rcs`コマンドが入っています。
+人気のMac OS Xオペレーティング・システムでも、開発者ツールをインストールすると `rcs` コマンドが入っています。
 このツールは基本的に、リビジョン間のパッチ（ファイル間の差分）の集合を特殊なフォーマットでディスク上に保持するという仕組みで動いています。こうすることで、任意のファイルについて、それが過去の任意の時点でどういうものだったかということを、パッチを重ね上げていくことで再現することができます。
 
 //////////////////////////
diff --git a/book/01-introduction/sections/first-time-setup.asc b/book/01-introduction/sections/first-time-setup.asc
index 12ccf95f..5f674b1e 100644
--- a/book/01-introduction/sections/first-time-setup.asc
+++ b/book/01-introduction/sections/first-time-setup.asc
@@ -17,7 +17,7 @@ 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.(((git commands, config)))
 These variables can be stored in three different places:
 //////////////////////////
-Gitには、`git config`と呼ばれるツールが付属します。これで、どのようにGitが見えて機能するかの全ての面を制御できる設定変数を取得し、設定することができます。(((git commands, config)))
+Gitには、`git config` と呼ばれるツールが付属します。これで、どのようにGitが見えて機能するかの全ての面を制御できる設定変数を取得し、設定することができます。(((git commands, config)))
 これらの変数は三つの異なる場所に格納されうります：
 
 //////////////////////////
@@ -28,15 +28,15 @@ Gitには、`git config`と呼ばれるツールが付属します。これで
 3. `config` file in the Git directory (that is, `.git/config`) of whatever repository you're currently using: Specific to that single repository.
 //////////////////////////
 1. `/etc/gitconfig` ファイル: システム上の全てのユーザーと全てのリポジトリに対する設定値を保持します。
-  もし`--system`オプションを`git config`に指定すると、明確にこのファイルに読み書きを行ないます。
+  もし `--system` オプションを `git config` に指定すると、明確にこのファイルに読み書きを行ないます。
 2. `~/.gitconfig` か `~/.config/git/config` ファイル: 特定のユーザーに対する設定値を保持します。
-  `--global`オプションを指定することで、Gitに、明確にこのファイルに読み書きを行なわせることができます。
-3. 現在使っているリポジトリのGitディレクトリにある`config`ファイル(`.git/config`のことです): 特定の単一リポジトリに対する設定値を保持します。
+  `--global` オプションを指定することで、Gitに、明確にこのファイルに読み書きを行なわせることができます。
+3. 現在使っているリポジトリのGitディレクトリにある `config` ファイル(`.git/config` のことです): 特定の単一リポジトリに対する設定値を保持します。
 
 //////////////////////////
 Each level overrides values in the previous level, so values in `.git/config` trump those in `/etc/gitconfig`.
 //////////////////////////
-それぞれのレベルの値は以前のレベルの値を上書きするため、`.git/config`の中の設定値は`/etc/gitconfig`の設定値に優先されます。
+それぞれのレベルの値は以前のレベルの値を上書きするため、`.git/config` の中の設定値は `/etc/gitconfig` の設定値に優先されます。
 
 //////////////////////////
 On Windows systems, Git looks for the `.gitconfig` file in the `$HOME` directory (`C:\Users\$USER` for most people).
@@ -73,8 +73,8 @@ Again, you need to do this only once if you pass the `--global` option, because
 <<<<<<< HEAD
 If you want to override this with a different name or email address for specific projects, you can run the command without the `--global` option when you're in that project.
 //////////////////////////
-また、もし`--global`オプションを指定するのであれば、Gitはその後、そのシステム上で行なう（訳者注：あるユーザーの）全ての操作に対して常にこの情報を使うようになるため、この操作を行なう必要はたった一度だけです。
-もし、違う名前とEmailアドレスを特定のプロジェクトで上書きしたいのであれば、そのプロジェクトの（訳者注：Gitディレクトリの）中で、`--global`オプション無しでこのコマンドを実行することができます。
+また、もし `--global` オプションを指定するのであれば、Gitはその後、そのシステム上で行なう（訳者注：あるユーザーの）全ての操作に対して常にこの情報を使うようになるため、この操作を行なう必要はたった一度だけです。
+もし、違う名前とEmailアドレスを特定のプロジェクトで上書きしたいのであれば、そのプロジェクトの（訳者注：Gitディレクトリの）中で、`--global` オプション無しでこのコマンドを実行することができます。
 
 //////////////////////////
 Many of the GUI tools will help you do this when you first run them.
@@ -154,7 +154,7 @@ Git用のエディターを設定していなくて、Gitを使っている最
 //////////////////////////
 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が見つけられる全ての設定を一覧するコマンドである`git config --list`を使う事ができます：
+設定を確認したい場合は、その時点でGitが見つけられる全ての設定を一覧するコマンドである `git config --list` を使う事ができます：
 
 [source,console]
 ----
@@ -172,12 +172,12 @@ 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/gitconfig`と`~/.gitconfig`)から同一のキーを読み込むため、同一のキーを1度以上見ることになるでしょう。この場合、Gitは見つけたそれぞれ同一のキーに対して最後の値を用います。
+Gitは異なったファイル(例えば `/etc/gitconfig` と `~/.gitconfig`)から同一のキーを読み込むため、同一のキーを1度以上見ることになるでしょう。この場合、Gitは見つけたそれぞれ同一のキーに対して最後の値を用います。
 
 //////////////////////////
 You can also check what Git thinks a specific key's value is by typing `git config <key>`:(((git commands, config)))
 //////////////////////////
-また、Gitに設定されている特定のキーの値を、`git config <key>`とタイプすることで確認することができます：(((git commands, config)))
+また、Gitに設定されている特定のキーの値を、`git config <key>` とタイプすることで確認することができます：(((git commands, config)))
 
 [source,console]
 ----
diff --git a/book/01-introduction/sections/help.asc b/book/01-introduction/sections/help.asc
index aa28908e..c026e918 100644
--- a/book/01-introduction/sections/help.asc
+++ b/book/01-introduction/sections/help.asc
@@ -32,5 +32,5 @@ If the manpages and this book aren't enough and you need in-person help, you can
 These channels are regularly filled with hundreds of people who are all very knowledgeable about Git and are often willing to help.(((IRC)))
 //////////////////////////
 これらのコマンドは、オフラインのときでさえ、どこでも見る事ができるので、すばらしいです。
-もしmanpageとこの本が十分でなく、人の助けが必要であれば、フリーノードIRCサーバー（irc.freenode.net）の`#git`もしくは`#github`チャンネルにアクセスしてみてください。
+もしmanpageとこの本が十分でなく、人の助けが必要であれば、フリーノードIRCサーバー（irc.freenode.net）の `#git` もしくは `#github` チャンネルにアクセスしてみてください。
 これらのチャンネルはいつも、Gitに関してとても知識があり、よく助けてくれようとする数百人の人々でいっぱいです。(((IRC)))
diff --git a/book/01-introduction/sections/installing.asc b/book/01-introduction/sections/installing.asc
index 7ab12ebf..a9c27513 100644
--- a/book/01-introduction/sections/installing.asc
+++ b/book/01-introduction/sections/installing.asc
@@ -156,7 +156,7 @@ $ sudo apt-get install libcurl4-gnutls-dev libexpat1-dev gettext \
 //////////////////////////
 In order to be able to add the documentation in various formats (doc, html, info), these additional dependencies are required (Note: users of RHEL and RHEL-derivatives like CentOS and Scientific Linux will have to https://fedoraproject.org/wiki/EPEL#How_can_I_use_these_extra_packages.3F[enable the EPEL repository] to download the `docbook2X` package):
 //////////////////////////
-なお、ドキュメントを doc、html、info 形式等で出力したい場合は、以下の依存ライブラリも必要になります（RHELやRHEL派生のディストリビューション（CentOS・Scientific Linuxなど）では、 https://fedoraproject.org/wiki/EPEL#How_can_I_use_these_extra_packages.3F[EPELリポジトリを有効] にしてください。`docbook2X`パッケージをダウンロードするのに必要になります）。
+なお、ドキュメントを doc、html、info 形式等で出力したい場合は、以下の依存ライブラリも必要になります（RHELやRHEL派生のディストリビューション（CentOS・Scientific Linuxなど）では、 https://fedoraproject.org/wiki/EPEL#How_can_I_use_these_extra_packages.3F[EPELリポジトリを有効] にしてください。`docbook2X` パッケージをダウンロードするのに必要になります）。
 
 [source,console]
 ----
diff --git a/book/02-git-basics/sections/recording-changes.asc b/book/02-git-basics/sections/recording-changes.asc
index 2f75c7d4..62bc35ad 100644
--- a/book/02-git-basics/sections/recording-changes.asc
+++ b/book/02-git-basics/sections/recording-changes.asc
@@ -181,7 +181,7 @@ It may be helpful to think of it more as ``add this content to the next commit''
 Let's run `git add` now to stage the `CONTRIBUTING.md` file, and then run `git status` again:
 //////////////////////////
 `CONTRIBUTING.md` ファイルは ``Changed but not staged for commit'' という欄に表示されます。これは、追跡対象のファイルが作業ディレクトリ内で変更されたけれどもまだステージされていないという意味です。
-ステージするには `git add` コマンドを実行します。 `git add` にはいろんな意味合いがあり、新しいファイルの追跡開始・ファイルのステージング・マージ時に衝突が発生したファイルに対する「解決済み」マーク付けなどで使用します。``指定したファイルをプロジェクトに追加(add)する''コマンド、というよりは、``指定した内容を次のコミットに追加(add)する''コマンド、と捉えるほうがわかりやすいかもしれません。(((git commands, add)))
+ステージするには `git add` コマンドを実行します。 `git add` にはいろんな意味合いがあり、新しいファイルの追跡開始・ファイルのステージング・マージ時に衝突が発生したファイルに対する「解決済み」マーク付けなどで使用します。``指定したファイルをプロジェクトに追加(add)する'' コマンド、というよりは、``指定した内容を次のコミットに追加(add)する'' コマンド、と捉えるほうがわかりやすいかもしれません。(((git commands, add)))
 では、`git add` で `CONTRIBUTING.md` をステージしてもういちど `git status` を実行してみましょう。
 
 [source,console]
@@ -236,7 +236,7 @@ If you commit now, the version of `CONTRIBUTING.md` as it was when you last ran
 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:
 //////////////////////////
 これはどういうことでしょう?
-`CONTRIBUTING.md` が、ステージされているほうとステージされていないほうの_両方に_登場しています。
+`CONTRIBUTING.md` が、ステージされているほうとステージされていないほうの _両方に_ 登場しています。
 こんなことってありえるんでしょうか?
 要するに、Git は「`git add` コマンドを実行した時点の状態のファイル」をステージするということです。
 ここでコミットをすると、実際にコミットされるのは `git add` を実行した時点の `CONTRIBUTING.md` であり、`git commit` した時点の作業ディレクトリにある内容とは違うものになります。
@@ -266,7 +266,7 @@ If you run `git status -s` or `git status --short` you get a far more simplified
 //////////////////////////
 `git status` の出力はとてもわかりやすいですが、一方で冗長でもあります。
 Gitにはそれを簡略化するためのオプションもあり、変更点をより簡潔に確認できます。
-`git status -s`や`git status --short`コマンドを実行して、簡略化された状態表示を見てみましょう。
+`git status -s` や `git status --short` コマンドを実行して、簡略化された状態表示を見てみましょう。
 
 [source,console]
 ----
@@ -284,11 +284,11 @@ There are two columns to the output - the left hand column indicates that the fi
 So for example in that output, the `README` file is modified in the working directory but not yet staged, while the `lib/simplegit.rb` file is modified and staged.
 The `Rakefile` was modified, staged and then modified again, so there are changes to it that are both staged and unstaged.
 //////////////////////////
-まだ追跡されていない新しいファイルには`??`が、ステージングエリアに追加されたファイルには`A`が、変更されたファイルには`M`が、といったように、ファイル名の左側に文字列が表示されます。
+まだ追跡されていない新しいファイルには `??` が、ステージングエリアに追加されたファイルには `A` が、変更されたファイルには `M` が、といったように、ファイル名の左側に文字列が表示されます。
 内容は2文字の組み合わせです。1文字目はステージされたファイルの状態を、2文字はファイルが変更されたかどうかを示しています。
-この例でいうと、`README`ファイルは作業ディレクトリ上にあって変更されているけれどステージされてはいません。
-`lib/simplegit.rb`ファイルは変更済みでステージもされています。
-`Rakefile`のほうはどうかというと、変更されステージされたあと、また変更された、という状態です。変更の内容にステージされたものとそうでないものがあることになります。
+この例でいうと、`README` ファイルは作業ディレクトリ上にあって変更されているけれどステージされてはいません。
+`lib/simplegit.rb` ファイルは変更済みでステージもされています。
+`Rakefile` のほうはどうかというと、変更されステージされたあと、また変更された、という状態です。変更の内容にステージされたものとそうでないものがあることになります。
 
 [[r_ignoring]]
 //////////////////////////
@@ -352,7 +352,7 @@ glob パターンとは、シェルで用いる簡易正規表現のようなも
 また、ハイフン区切りの文字を角括弧で囲んだ形式 (`[0-9]`) は、
 ふたつの文字の間の任意の文字 (この場合は 0 から 9 までの間の文字) にマッチします。
 アスタリクスを2つ続けて、ネストされたディレクトリにマッチさせることもできます。
-`a/**/z` のように書けば、`a/z`、`a/b/z`、`a/b/c/z`などにマッチします。
+`a/**/z` のように書けば、`a/z`、`a/b/z`、`a/b/c/z` などにマッチします。
 
 //////////////////////////
 Here is another example .gitignore file:
@@ -577,10 +577,10 @@ Run `git difftool --tool-help` to see what is available on your system.
 //////////////////////////
 .GitのDiffを他のツールで見る
 ====
-この本では、引き続き`git diff`コマンドを様々な方法で使っていきます。
+この本では、引き続き `git diff` コマンドを様々な方法で使っていきます。
 一方、このコマンドを使わずに差分を見る方法も用意されています。GUIベースだったり、他のツールが好みの場合、役に立つでしょう。
-`git diff`の代わりに`git difftool`を実行してください。そうすれば、emerge、vimdiffなどのツールを使って差分を見られます（商用のツールもいくつもあります）。
-また、`git difftool --tool-help`を実行すれば、利用可能なdiffツールを確認することもできます。
+`git diff` の代わりに `git difftool` を実行してください。そうすれば、emerge、vimdiffなどのツールを使って差分を見られます（商用のツールもいくつもあります）。
+また、`git difftool --tool-help` を実行すれば、利用可能なdiffツールを確認することもできます。
 ====
 
 [[r_committing_changes]]
diff --git a/book/02-git-basics/sections/undoing.asc b/book/02-git-basics/sections/undoing.asc
index 89e87eb0..d184be4e 100644
--- a/book/02-git-basics/sections/undoing.asc
+++ b/book/02-git-basics/sections/undoing.asc
@@ -131,7 +131,7 @@ Calling `git reset` without an option is not dangerous - it only touches your st
 =====
 //////////////////////////
 =====
-`git reset` は、危険なコマンドに_なりえます_。その条件は、「`--hard`オプションをつけて実行すること」です。
+`git reset` は、危険なコマンドに_なりえます_。その条件は、「`--hard` オプションをつけて実行すること」です。
 ただし、上述の例はそうしておらず、作業ディレクトリにあるファイルに変更は加えられていません。
 `git reset` をオプションなしで実行するのは危険ではありません。
 ステージングエリアのファイルに変更が加えられるだけなのです。
@@ -141,7 +141,7 @@ Calling `git reset` without an option is not dangerous - it only touches your st
 For now this magic invocation is all you need to know about the `git reset` command.
 We'll go into much more detail about what `reset` does and how to master it to do really interesting things in <<ch07-git-tools#r_git_reset>>.
 //////////////////////////
-今のところは、`git reset`については上記の魔法の呪文を知っておけば十分でしょう。<<ch07-git-tools#r_git_reset>>で、より詳細に、`reset`の役割と使いこなし方について説明します。色々とおもしろいことができるようになりますよ。
+今のところは、`git reset` については上記の魔法の呪文を知っておけば十分でしょう。<<ch07-git-tools#r_git_reset>>で、より詳細に、`reset` の役割と使いこなし方について説明します。色々とおもしろいことができるようになりますよ。
 
 //////////////////////////
 ==== Unmodifying a Modified File
@@ -201,7 +201,7 @@ Don't ever use this command unless you absolutely know that you don't want the f
 =====
 //////////////////////////
 =====
-ここで理解しておくべきなのが、`git checkout -- [file]`は危険なコマンドだ、ということです。
+ここで理解しておくべきなのが、`git checkout -- [file]` は危険なコマンドだ、ということです。
 あなたがファイルに加えた変更はすべて消えてしまいます。変更した内容を、別のファイルで上書きしたのと同じことになります。そのファイルが不要であることが確実にわかっているとき以外は、このコマンドを使わないようにしましょう。
 =====
 
diff --git a/book/02-git-basics/sections/viewing-history.asc b/book/02-git-basics/sections/viewing-history.asc
index c828a5cf..c3ba4fa0 100644
--- a/book/02-git-basics/sections/viewing-history.asc
+++ b/book/02-git-basics/sections/viewing-history.asc
@@ -270,7 +270,7 @@ authorとはその作業をもともと行った人、committerとはその作
 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:
 //////////////////////////
-`oneline`オプションおよび`format`オプションは、`log` のもうひとつのオプションである `--graph` と組み合わせるとさらに便利です。
+`oneline` オプションおよび `format` オプションは、`log` のもうひとつのオプションである `--graph` と組み合わせるとさらに便利です。
 このオプションは、ちょっといい感じのアスキーグラフでブランチやマージの歴史を表示します。
 
 [source,console]
@@ -300,7 +300,7 @@ Those are only some simple output-formatting options to `git log` – there are
 これらは `git log` の出力フォーマット指定のほんの一部でしかありません。
 まだまだオプションはあります。
 <<rlog_options>> に、今まで取り上げたオプションやそれ以外によく使われるオプション、
-そしてそれぞれが`log`の出力をどのように変えるのかをまとめました。
+そしてそれぞれが `log` の出力をどのように変えるのかをまとめました。
 
 [[rlog_options]]
 //////////////////////////
@@ -319,7 +319,7 @@ Those are only some simple output-formatting options to `git log` – there are
 | `--pretty`        | Show commits in an alternate format. Options include oneline, short, full, fuller, and format (where you specify your own format).
 |================================
 //////////////////////////
-.`git log`のよく使われるオプション
+.`git log` のよく使われるオプション
 [cols="1,4",options="header"]
 |================================
 | オプション        | 説明
@@ -371,7 +371,7 @@ $ git log --since=2.weeks
 This command works with lots of formats – you can specify a specific date like `"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"`のように指定することも可能です。
+相対日付を `"2 years 1 day 3 minutes ago"` のように指定することも可能です。
 
 //////////////////////////
 You can also filter the list to commits that match some search criteria.
@@ -381,14 +381,14 @@ The `--author` option allows you to filter on a specific author, and the `--grep
 コミット一覧から検索条件にマッチするものだけを取り出すこともできます。
 `--author` オプションは特定のauthorのみを抜き出し、
 `--grep` オプションはコミットメッセージの中のキーワードを検索します
-（author と grep を両方指定する場合は、`--all-match`オプションも一緒に使ってください。
+（author と grep を両方指定する場合は、`--all-match` オプションも一緒に使ってください。
 そうしないと、どちらか一方にだけマッチするものも対象になってしまいます）。
 
 //////////////////////////
 Another really helpful filter is the `-S` option which takes a string and only shows the commits that introduced a change to the code that added or removed that string.
 For instance, if you wanted to find the last commit that added or removed a reference to a specific function, you could call:
 //////////////////////////
-もうひとつ、`-S`オプションというとても便利なフィルタがあります。
+もうひとつ、`-S` オプションというとても便利なフィルタがあります。
 このオプションは任意の文字列を引数にでき、その文字列が追加・削除されたコミットのみを抜き出してくれます。
 仮に、とある関数の呼び出しをコードに追加・削除したコミットのなかから、最新のものが欲しいとしましょう。こうすれば探すことができます。
 
@@ -427,7 +427,7 @@ In <<rlimit_options>> we'll list these and a few other common options for your r
 | `-S`                  | Only show commits adding or removing code matching the string
 |================================
 //////////////////////////
-.`git log`の出力を制限するためのオプション
+.`git log` の出力を制限するためのオプション
 [cols="2,4",options="header"]
 |================================
 | オプション            | 説明
diff --git a/book/03-git-branching/sections/basic-branching-and-merging.asc b/book/03-git-branching/sections/basic-branching-and-merging.asc
index b4e94c17..c412113f 100644
--- a/book/03-git-branching/sections/basic-branching-and-merging.asc
+++ b/book/03-git-branching/sections/basic-branching-and-merging.asc
@@ -207,8 +207,8 @@ Your change is now in the snapshot of the commit pointed to by the `master` bran
 .`master` is fast-forwarded to `hotfix`
 image::images/basic-branching-5.png[`master` is fast-forwarded to `hotfix`.]
 //////////////////////////
-.`master`が`hotfix`にfast-forwardされた
-image::images/basic-branching-5.png[`master`が`hotfix`にfast-forwardされた]
+.`master` が `hotfix` にfast-forwardされた
+image::images/basic-branching-5.png[`master` が `hotfix` にfast-forwardされた]
 
 //////////////////////////
 After your super-important fix is deployed, you're ready to switch back to the work you were doing before you were interrupted.
diff --git a/book/03-git-branching/sections/remote-branches.asc b/book/03-git-branching/sections/remote-branches.asc
index 22509042..92343fdb 100644
--- a/book/03-git-branching/sections/remote-branches.asc
+++ b/book/03-git-branching/sections/remote-branches.asc
@@ -265,7 +265,7 @@ Checking out a local branch from a remote-tracking branch automatically creates
 Tracking branches are local branches that have a direct relationship to a remote branch.
 If you're on a tracking branch and type `git pull`, Git automatically knows which server to fetch from and branch to merge into.
 //////////////////////////
-リモート追跡ブランチからローカルブランチにチェックアウトすると、``追跡ブランチ''  というブランチが自動的に作成されます(そしてそれが追跡するブランチを``上流ブランチ''といいます)。
+リモート追跡ブランチからローカルブランチにチェックアウトすると、``追跡ブランチ'' というブランチが自動的に作成されます(そしてそれが追跡するブランチを ``上流ブランチ'' といいます)。
 追跡ブランチとは、リモートブランチと直接のつながりを持つローカルブランチのことです。
 追跡ブランチ上で `git pull` を実行すると、Git は自動的に取得元のサーバーとブランチを判断します。
 
diff --git a/book/04-git-server/sections/setting-up-server.asc b/book/04-git-server/sections/setting-up-server.asc
index 585d08db..3dfcbd6a 100644
--- a/book/04-git-server/sections/setting-up-server.asc
+++ b/book/04-git-server/sections/setting-up-server.asc
@@ -166,6 +166,6 @@ For instance, you can restrict the Git commands that the server will accept or y
 Run `git help shell` for more information on customizing the shell.(((git commands, help)))
 //////////////////////////
 この状態でも Git のネットワーク関連のコマンドは機能しますが、通常のシェルアクセスはできなくなっています。
-また、コマンド出力にもあるように、`git` ユーザーのホームディレクトリ配下にディレクトリを作って、`git-shell`をカスタマイズすることもできます。
+また、コマンド出力にもあるように、`git` ユーザーのホームディレクトリ配下にディレクトリを作って、`git-shell` をカスタマイズすることもできます。
 具体的には、サーバー上で実行可能な Git コマンドの制限や、ユーザーが SSH でどこかに接続しようとしたときに表示するメッセージを変更できます。
 `git help shell` を実行すると、シェルのカスタマイズについての詳細が確認できます。(((git commands, help)))
diff --git a/book/05-distributed-git/sections/contributing.asc b/book/05-distributed-git/sections/contributing.asc
index 7d099665..74522a8c 100644
--- a/book/05-distributed-git/sections/contributing.asc
+++ b/book/05-distributed-git/sections/contributing.asc
@@ -1269,7 +1269,7 @@ 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サーバー経由で送信することもできます。
-設定方法についてはIMAPサーバーの場合と同様に、`git config`コマンドを使って設定項目を個別に入力してもいいですし、`~/.gitconfig`ファイルのsendemailセクションを直接編集してもかまいません。
+設定方法についてはIMAPサーバーの場合と同様に、`git config` コマンドを使って設定項目を個別に入力してもいいですし、`~/.gitconfig` ファイルのsendemailセクションを直接編集してもかまいません。
 
 [source,ini]
 ----
@@ -1283,7 +1283,7 @@ As before, you can set each value separately with a series of `git config` comma
 //////////////////////////
 After this is done, you can use `git send-email` to send your patches:
 //////////////////////////
-設定が終われば、`git send-email`コマンドを使ってパッチを送信できます。
+設定が終われば、`git send-email` コマンドを使ってパッチを送信できます。
 
 [source,console]
 ----
diff --git a/book/06-github/sections/2-contributing.asc b/book/06-github/sections/2-contributing.asc
index b44439c1..08577ca7 100644
--- a/book/06-github/sections/2-contributing.asc
+++ b/book/06-github/sections/2-contributing.asc
@@ -233,7 +233,7 @@ It is almost always worthwhile to put some effort into this, since a good descri
 //////////////////////////
 We also see a list of the commits in our topic branch that are ``ahead'' of the `master` branch (in this case, just the one) and a unified diff of all the changes that will be made should this branch get merged by the project owner.
 //////////////////////////
-この画面では、トピックブランチ内のコミットのうち、`master`よりも先行しているコミットの一覧 (今回の場合はひとつだけ) も確認できます。
+この画面では、トピックブランチ内のコミットのうち、`master` よりも先行しているコミットの一覧 (今回の場合はひとつだけ) も確認できます。
 また、このブランチをオーナーがマージしたときに適用される変更の、unified形式の差分も表示されます。
 
 //////////////////////////
diff --git a/book/07-git-tools/sections/rewriting-history.asc b/book/07-git-tools/sections/rewriting-history.asc
index 2894b625..895173ed 100644
--- a/book/07-git-tools/sections/rewriting-history.asc
+++ b/book/07-git-tools/sections/rewriting-history.asc
@@ -361,7 +361,7 @@ Now you can stage and commit files until you have several commits, and run `git
 続いて、コマンドラインに戻ってコミットをリセットし、その内容を使ってコミットを複数に分割していきます。
 まず、変更を保存してエディタを終了すると、Git はリストの最初のコミットの親まで処理を巻き戻します。そして最初のコミット (`f7f3f6d`) と二番目のコミット (`310154e`) を適用してからコンソールに戻ります。
 コミットをリセットするには `git reset HEAD^` を実行します。これはコミット自体を取り消し、変更されたファイルはステージしていない状態にします。
-そして、その状態から一連のコミットを作ったら、以下のように`git rebase --continue` を実行しましょう｡
+そして、その状態から一連のコミットを作ったら、以下のように `git rebase --continue` を実行しましょう｡
 
 [source,console]
 ----
@@ -461,7 +461,7 @@ Git がツリーを書き換えてコミットし、ブランチのポインタ
 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:
 //////////////////////////
-別のソース管理システムからのインポートを終えた後、無意味なサブディレクトリ (`trunk`、`tags`など) が残っている状態を想定しましょう。
+別のソース管理システムからのインポートを終えた後、無意味なサブディレクトリ (`trunk`、`tags` など) が残っている状態を想定しましょう。
 すべてのコミットの `trunk` ディレクトリを新たなプロジェクトルートとしたい場合にも、`filter-branch` が助けになります。
 
 [source,console]
diff --git a/book/07-git-tools/sections/submodules.asc b/book/07-git-tools/sections/submodules.asc
index 9229c891..64e6ce37 100644
--- a/book/07-git-tools/sections/submodules.asc
+++ b/book/07-git-tools/sections/submodules.asc
@@ -437,7 +437,7 @@ Submodules changed but not updated:
 //////////////////////////
 At this point if you run `git diff` we can see both that we have modified our `.gitmodules` file and also that there are a number of commits that we've pulled down and are ready to commit to our submodule project.
 //////////////////////////
-この段階で`git diff` を実行すると、`.gitmodules` ファイルが変更されていることがわかります。
+この段階で `git diff` を実行すると、`.gitmodules` ファイルが変更されていることがわかります。
 また、サブモジュールについては、上流からコミットがすでにいくつも取得されていて、手元のリポジトリでコミット待ちの状態になっていることがわかります。
 
 [source,console]
@@ -517,7 +517,7 @@ This means that there is no local working branch (like ``master'', for example)
 With no working branch tracking changes, that means even if you commit changes to the submodule, those changes will quite possibly be lost the next time you run `git submodule update`. You have to do some extra steps if you want changes in a submodule to be tracked.
 //////////////////////////
 これまでの例では、`git submodule update` コマンドを実行してサブモジュールのリモートリポジトリの変更内容を取得すると、サブモジュール用ディレクトリ内のファイルは更新されますが、手元のサブモジュール用リポジトリの状態は「切り離された HEAD (detached HEAD)」になってしまっていました。つまり、作業中のブランチ（``master'' など）は存在せず、変更も追跡されない、ということです。
-このままでは、たとえサブモジュールになにかコミットを追加したとしても、`git submodule update`を実行したタイミングで追加した内容はなくなってしまうことになります。そういった事態を避け、サブモジュールに追加した内容をちゃんと記録するには、事前準備が必要なのです。
+このままでは、たとえサブモジュールになにかコミットを追加したとしても、`git submodule update` を実行したタイミングで追加した内容はなくなってしまうことになります。そういった事態を避け、サブモジュールに追加した内容をちゃんと記録するには、事前準備が必要なのです。
 
 //////////////////////////
 In order to set up your submodule to be easier to go in and hack on, you need do two things.
diff --git a/book/08-customizing-git/sections/attributes.asc b/book/08-customizing-git/sections/attributes.asc
index 40d41ba0..dc6fcdc4 100644
--- a/book/08-customizing-git/sections/attributes.asc
+++ b/book/08-customizing-git/sections/attributes.asc
@@ -104,7 +104,7 @@ Put the following line in your `.gitattributes` file:
 //////////////////////////
 これでは、2つのバージョンをチェックアウトして、目視で見比べなくては、比較はできませんよね？
 Gitの属性を使えば、これをうまく解決できます。
-`.gitattributes`に次の行を追加して下さい。
+`.gitattributes` に次の行を追加して下さい。
 
 [source,ini]
 ----
@@ -130,7 +130,7 @@ Create a file that's somewhere in your path called `docx2txt`, and add these con
 //////////////////////////
 まず、 `docx2txt` をインストールする必要があります。 http://docx2txt.sourceforge.net[] からダウンロードしたら、 `INSTALL` ファイルの指示に従って、シェルから見える場所にファイルを置いてください。
 次に、出力を Git に合わせて変換するラッパースクリプトを作成します。
-パスの通った場所に、 `docx2txt`という名前のファイルを次の内容で作成してください。
+パスの通った場所に、 `docx2txt` という名前のファイルを次の内容で作成してください。
 
 [source,console]
 ----
@@ -198,8 +198,8 @@ Put the following line in your `.gitattributes` file:
 //////////////////////////
 その他の興味深い問題としては、画像ファイルの差分があります。
 ひとつの方法として、EXIF情報（多くのファイル形式で使用されているメタデータ）を抽出するフィルタを使う方法があります。
-`exiftool`をダウンロードしてインストールすれば、画像データを、メタデータを表すテキストデータへ変換できます。これによって、 diff では少なくとも、変更内容をテキスト形式で表示できるようになります。
-ではここで、以下の行を`.gitattributes`に追加してみましょう。
+`exiftool` をダウンロードしてインストールすれば、画像データを、メタデータを表すテキストデータへ変換できます。これによって、 diff では少なくとも、変更内容をテキスト形式で表示できるようになります。
+ではここで、以下の行を `.gitattributes` に追加してみましょう。
 
 [source,ini]
 ----
@@ -275,7 +275,7 @@ Put the following line in your `.gitattributes` file:
 ひとつめの方法として、ファイルの `$Id$` フィールドへ、 blob の SHA-1 チェックサムを自動的に挿入できます。
 あるファイル、もしくはいくつかのファイルに対してこの属性を設定すれば、次にそのブランチをチェックアウトする時、Gitはこの置き換えを行うようになります。
 ただし、挿入されるチェックサムはコミットに対するものではなく、対象となるblobのものであるという点に注意して下さい。
-ではここで、以下の行を`.gitattributes`に追加してみましょう。
+ではここで、以下の行を `.gitattributes` に追加してみましょう。
 
 [source,ini]
 ----
@@ -285,7 +285,7 @@ Put the following line in your `.gitattributes` file:
 //////////////////////////
 Add an `$Id$` reference to a test file:
 //////////////////////////
-続いて、`$Id$`への参照をテスト用ファイルに追加します。
+続いて、`$Id$` への参照をテスト用ファイルに追加します。
 
 [source,console]
 ----
@@ -344,7 +344,7 @@ The original commit message for this feature gives a simple example of running a
 You can set it up by setting the filter attribute in your `.gitattributes` file to filter `*.c` files with the ``indent'' filter:
 //////////////////////////
 この機能に対してオリジナルのコミットメッセージは簡単な例を与えてくれています。それはコミット前にCのソースコードを `indent` プログラムに通すというものです。
-`*.c` ファイルに対してこのフィルタを実行するように、`.gitattributes`ファイルにfilter属性を設定できます。
+`*.c` ファイルに対してこのフィルタを実行するように、`.gitattributes` ファイルにfilter属性を設定できます。
 
 [source,ini]
 ----
@@ -368,7 +368,7 @@ The `cat` program does essentially nothing: it spits out the same data that it c
 This combination effectively filters all C source code files through `indent` before committing.
 //////////////////////////
 このケースでは、 `*.c` にマッチするファイルをコミットした時、Gitはステージング前にindentプログラムにファイルを通し、チェックアウトする前には `cat` を通すようにします。
-`cat`は基本的に何もしません。入力されたデータと同じデータを吐き出すだけです。
+`cat` は基本的に何もしません。入力されたデータと同じデータを吐き出すだけです。
 この組み合わせを使えば、Cのソースコードのコミット前に、効果的に `indent` を通せます。
 
 //////////////////////////
@@ -395,8 +395,8 @@ Now, you need to set up a filter in Git (call it `dater`) and tell it to use you
 You'll use a Perl expression to clean that up on commit:
 //////////////////////////
 このスクリプトは、`git log` コマンドの出力から最新のコミットの日付を取得し、標準入力中のすべての `$Date$` 文字列にその日付を追加し、結果を出力します。お気に入りのどんな言語で書くにしても、簡単なスクリプトになるでしょう。
-このスクリプトファイルに`expand_date`と名前をつけ、実行パスのどこかに置きます。
-次に、Git にフィルタ（ここでは `dater`とします）を設定し、チェックアウト時に smudge で `expand_date` フィルタを使うように指定します。
+このスクリプトファイルに `expand_date` と名前をつけ、実行パスのどこかに置きます。
+次に、Git にフィルタ（ここでは `dater` とします）を設定し、チェックアウト時に smudge で `expand_date` フィルタを使うように指定します。
 コミット時に日付を削除するのには、 Perl の正規表現が使えます。
 
 [source,console]
@@ -470,7 +470,7 @@ If there is a subdirectory or file that you don't want to include in your archiv
 For example, say you have some test files in a `test/` subdirectory, and it doesn't make sense to include them in the tarball export of your project.
 You can add the following line to your Git attributes file:
 //////////////////////////
-例えば、プロジェクトをエクスポートする際に tarball に含めたくないテストファイルが、 `test/`ディレクトリ以下に入っているとしましょう。
+例えば、プロジェクトをエクスポートする際に tarball に含めたくないテストファイルが、 `test/` ディレクトリ以下に入っているとしましょう。
 その場合、次の1行をGitの属性ファイルに追加します。
 
 [source,ini]
@@ -491,8 +491,8 @@ When exporting files for deployment you can apply `git log`'s formatting and key
 
 For instance, if you want to include a file named `LAST_COMMIT` in your project, and have metadata about the last commit automatically injected into it when `git archive` runs, you can for example set up your `.gitattributes` and `LAST_COMMIT` files like this:
 //////////////////////////
-デプロイ用にファイルをエクスポートする際に、`export-subst` 属性のついたファイルを指定して `git log` のログ書式指定機能とキーワード展開機能で生成した内容をファイルに付与できます。
-例えば、`LAST_COMMIT`という名前のファイルをプロジェクトに追加し、`git archive`を実行した時にそのファイルのメタデータを最新コミットと同じ内容に変換したい場合、`.gitattributes`ファイルと`LAST_COMMIT`ファイルを
+デプロイ用にファイルをエクスポートする際に、 `export-subst` 属性のついたファイルを指定して `git log` のログ書式指定機能とキーワード展開機能で生成した内容をファイルに付与できます。
+例えば、`LAST_COMMIT` という名前のファイルをプロジェクトに追加し、`git archive` を実行した時にそのファイルのメタデータを最新コミットと同じ内容に変換したい場合、`.gitattributes` ファイルと `LAST_COMMIT` ファイルを
 次のように設定します。
 
 [source,ini]
diff --git a/book/08-customizing-git/sections/config.asc b/book/08-customizing-git/sections/config.asc
index 06551fcf..7ba37e7a 100644
--- a/book/08-customizing-git/sections/config.asc
+++ b/book/08-customizing-git/sections/config.asc
@@ -361,7 +361,7 @@ $ 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` (underline), `blink`, and `reverse` (swap foreground and background).
 //////////////////////////
-色として指定できる値は `normal`、 `black`、 `red、 `green`、 `yellow`、 `blue`、 `magenta`、 `cyan`、 `white` のいずれかです。先ほどの例の bold のように属性も指定できます。`bold`、 `dim`、 `ul` （下線つき）、 `blink`、 `reverse` （文字と背景の色を逆にする）のいずれかを指定できます。
+色として指定できる値は `normal`、 `black`、 `red`、 `green`、 `yellow`、 `blue`、 `magenta`、 `cyan`、 `white` のいずれかです。先ほどの例の bold のように属性も指定できます。`bold`、 `dim`、 `ul` （下線つき）、 `blink`、 `reverse` （文字と背景の色を逆にする）のいずれかを指定できます。
 
 [[r_external_merge_tools]]
 //////////////////////////
diff --git a/book/09-git-and-other-scms/sections/import-svn.asc b/book/09-git-and-other-scms/sections/import-svn.asc
index 2db8b809..96fb529a 100644
--- a/book/09-git-and-other-scms/sections/import-svn.asc
+++ b/book/09-git-and-other-scms/sections/import-svn.asc
@@ -133,7 +133,7 @@ $ rm -Rf .git/refs/remotes/origin
 //////////////////////////
 It may happen that you'll see some extra branches which are suffixed by `@xxx` (where xxx is a number), while in Subversion you only see one branch. This is actually a Subversion feature called "peg-revisions", which is something that Git simply has no syntactical counterpart for. Hence, `git svn` simply adds the svn version number to the branch name just in the same way as you would have written it in svn to address the peg-revision of that branch. If you do not care anymore about the peg-revisions, simply remove them using `git branch -d`.
 //////////////////////////
-このとき、Subversionではブランチが1つだったのにもかかわらず、名前が`@xxx`（xxxは数字）で終わる余分なブランチがいくつか出来てしまうことがあります。Subversionの「ペグ・リビジョン」という機能が原因なのですが、Gitにはこれと同等の機能は存在しません。よって、`git svn`コマンドはブランチ名にsvnのバージョン番号をそのまま追加します。svnでペグ・リビジョンをブランチに設定するときとまさに同じやり方です。もうペグ・リビジョンがいらないのであれば、`git branch -d`コマンドで削除してしまいましょう。
+このとき、Subversionではブランチが1つだったのにもかかわらず、名前が `@xxx`（xxxは数字）で終わる余分なブランチがいくつか出来てしまうことがあります。Subversionの「ペグ・リビジョン」という機能が原因なのですが、Gitにはこれと同等の機能は存在しません。よって、`git svn` コマンドはブランチ名にsvnのバージョン番号をそのまま追加します。svnでペグ・リビジョンをブランチに設定するときとまさに同じやり方です。もうペグ・リビジョンがいらないのであれば、`git branch -d` コマンドで削除してしまいましょう。
 
 //////////////////////////
 Now all the old branches are real Git branches and all the old tags are real Git tags.
@@ -143,7 +143,7 @@ Now all the old branches are real Git branches and all the old tags are real Git
 //////////////////////////
 There's one last thing to clean up. Unfortunately, `git svn` creates an extra branch named `trunk`, which maps to Subversion's default branch, but the `trunk` ref points to the same place as `master`. Since `master` is more idiomatically Git, here's how to remove the extra branch:
 //////////////////////////
-最後に後始末についてです。残念なことに、`git svn`は`trunk`という名前の余計なブランチを生成してしまいます。Subversionにおけるデフォルトブランチではあるのですが、`trunk`の参照が指す場所は`master`と同じです。`master`のほうが用語としてもGitらしいですから、余分なブランチは削除してしまいましょう。
+最後に後始末についてです。残念なことに、`git svn` は `trunk` という名前の余計なブランチを生成してしまいます。Subversionにおけるデフォルトブランチではあるのですが、`trunk` の参照が指す場所は `master` と同じです。`master` のほうが用語としてもGitらしいですから、余分なブランチは削除してしまいましょう。
 
 [source,console]
 ----
diff --git a/book/A-git-in-other-environments/sections/guis.asc b/book/A-git-in-other-environments/sections/guis.asc
index 026a964f..f5650316 100644
--- a/book/A-git-in-other-environments/sections/guis.asc
+++ b/book/A-git-in-other-environments/sections/guis.asc
@@ -74,8 +74,8 @@ Gitkのインターフェイスは次のようになっています。
 .The `gitk` history viewer.
 image::images/gitk.png[The `gitk` history viewer.]
 //////////////////////////
-.`gitk`の歴史ビューアー
-image::images/gitk.png[`gitk`の歴史ビューアー]
+.`gitk` の歴史ビューアー
+image::images/gitk.png[`gitk` の歴史ビューアー]
 
 //////////////////////////
 On the top is something that looks a bit like the output of `git log --graph`; each dot represents a commit, the lines represent parent relationships, and refs are shown as colored boxes.
diff --git a/book/A-git-in-other-environments/sections/powershell.asc b/book/A-git-in-other-environments/sections/powershell.asc
index 2c8de9e3..c3b897f9 100644
--- a/book/A-git-in-other-environments/sections/powershell.asc
+++ b/book/A-git-in-other-environments/sections/powershell.asc
@@ -50,4 +50,4 @@ Windows用GitHubクライアントのユーザでない場合は、 (https://git
 //////////////////////////
 This will add the proper line to your `profile.ps1` file, and posh-git will be active the next time you open your prompt.
 //////////////////////////
-これで `profile.ps1`ファイルに適切な内容が追加されます。次にプロンプトを開いた時に、 posh-git が有効になります。
+これで `profile.ps1` ファイルに適切な内容が追加されます。次にプロンプトを開いた時に、 posh-git が有効になります。
diff --git a/book/A-git-in-other-environments/sections/zsh.asc b/book/A-git-in-other-environments/sections/zsh.asc
index f92f1708..491280b5 100644
--- a/book/A-git-in-other-environments/sections/zsh.asc
+++ b/book/A-git-in-other-environments/sections/zsh.asc
@@ -10,7 +10,7 @@ To use it, simply run `autoload -Uz compinit && compinit` in your `.zshrc`.
 Zsh's interface is a bit more powerful than Bash's:
 //////////////////////////
 Zshには、Git用のタブ補完ライブラリも同梱されています。
-`.zshrc`に`autoload -Uz compinit && compinit`という行を追加するだけで、使えるようになります。
+`.zshrc` に `autoload -Uz compinit && compinit` という行を追加するだけで、使えるようになります。
 Zshのインターフェイスは、Bashよりさらに強力です。
 
 [source,console]
@@ -70,14 +70,14 @@ For more information on vcs_info, check out its documentation
         in the `zshcontrib(1)` manual page,
         or online at http://zsh.sourceforge.net/Doc/Release/User-Contributions.html#Version-Control-Information[].
 //////////////////////////
-vcs_infoについての詳細は、`zshcontrib(1)`マニュアルにあるドキュメントか、オンラインであれば http://zsh.sourceforge.net/Doc/Release/User-Contributions.html#Version-Control-Information[] を確認してみてください。
+vcs_infoについての詳細は、`zshcontrib(1)` マニュアルにあるドキュメントか、オンラインであれば http://zsh.sourceforge.net/Doc/Release/User-Contributions.html#Version-Control-Information[] を確認してみてください。
 
 //////////////////////////
 Instead of vcs_info, you might prefer the prompt customization script that ships with Git, called `git-prompt.sh`; see https://github.com/git/git/blob/master/contrib/completion/git-prompt.sh[] for details.
 `git-prompt.sh` is compatible with both Bash and Zsh.
 //////////////////////////
-一方、Gitに同梱されている`git-prompt.sh`というスクリプトでも、プロンプトをカスタマイズすることができます。vcs_infoよりも気に入るかもしれませんね。詳しくは https://github.com/git/git/blob/master/contrib/completion/git-prompt.sh[] を確認してみてください。
-`git-prompt.sh`はBashとZshの両方に対応しています。
+一方、Gitに同梱されている `git-prompt.sh` というスクリプトでも、プロンプトをカスタマイズすることができます。vcs_infoよりも気に入るかもしれませんね。詳しくは https://github.com/git/git/blob/master/contrib/completion/git-prompt.sh[] を確認してみてください。
+`git-prompt.sh` はBashとZshの両方に対応しています。
 
 //////////////////////////
 Zsh is powerful enough that there are entire frameworks dedicated to making it better.
diff --git a/book/B-embedding-git/sections/jgit.asc b/book/B-embedding-git/sections/jgit.asc
index d55fcde4..fc3e9f0c 100644
--- a/book/B-embedding-git/sections/jgit.asc
+++ b/book/B-embedding-git/sections/jgit.asc
@@ -277,7 +277,7 @@ In this case, we're asking the `origin` remote for tags, but not heads.
 Also notice the use of a `CredentialsProvider` object for authentication.
 //////////////////////////
 これはGitクラスを使うときによくあるパターンです。メソッドがコマンドオブジェクトを返すので、パラメータを設定するメソッドチェーンを繋げていき、最後に `.call()` メソッドを呼び出すとそれらがまとめて実行されます。
-このケースでは、タグを取得する際に、HEADではなく`origin`リモートを要求しています。
+このケースでは、タグを取得する際に、HEADではなく `origin` リモートを要求しています。
 また、`CredentialsProvider` オブジェクトを使って認証を行っていることにも注意してください。
 
 //////////////////////////