10章「Gitの内側」の品質向上

book/10-git-internals/1-git-internals.asc

@@ -10,25 +10,31 @@ We found that learning this information was fundamentally important to understan
 Thus, we've made this discussion the last chapter in the book so you could read it early or later in your learning process.
 We leave it up to you to decide.
 //////////////////////////
-あなたは前の章を飛ばしてこの章に来たのでしょうか、あるいは、この本の他の部分を読んだ後で来たのでしょうか。いずれにせよ、この章ではGit の内部動作と実装を辿っていくことになります。内部動作と実装を学ぶことは、Git がどうしてこんなに便利で有効なのかを根本的に理解するのに重要です。しかし初心者にとっては不必要に複雑で混乱を招いてしまうという人もいました。そのため、遅かれ早かれ学習の仕方に合わせて読めるように、この話題を最後の章に配置しました。いつ読むかって？　それは読者の判断にお任せします。
+どこかの章からここに飛んできたのか、本書の他の部分を読み終えてからここにたどり着いたのか – いずれにせよ、この章ではGitの内部動作と実装を詳細に見ていきます。
+我々は、Gitがいかに便利で強力かを理解するには、その内部動作と実装を学ぶことが根本的に重要であると考えました。一方で、そういった内容は、初心者にとっては不必要に複雑で、かえって混乱を招くおそれがあると主張する人もいました。
+そこで我々は、この話題を本書の最後の章にして、読者の学習プロセスの最初の方で読んでも最後の方で読んでもいいようにしました。
+いつ読むかって？　それは読者の判断にお任せします。
 
 //////////////////////////
 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.
 //////////////////////////
-もう既にあなたはこの章を読んでいますので、早速、開始しましょう。まず、基本的にGit は連想記憶ファイル・システム（content-addressable filesystem）であり、その上にVCS ユーザー・インターフェイスが記述されているのです。これが意味することを、もう少し見て行きましょう。
+もう既にあなたはこの章を読んでいますので、早速、開始しましょう。
+まず最初に明確にしておきたいのですが、Gitの実態は内容アドレスファイルシステム（content-addressable filesystem）であり、その上にVCSのユーザーインターフェイスが実装されています。
+これが何を意味するかについては、すぐ後で学びます。
 
 //////////////////////////
 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.
 //////////////////////////
-初期のGit（主として1.5以前）は、洗練されたVCS というよりもむしろファイル・システムであることを（Gitの特徴として）強調しており、それ故に、ユーザー・インターフェイスは今よりも複雑なものでした。ここ数年の間に、世の中のどのシステムにも劣らないほどGit のユーザー・インターフェイスはシンプルで扱いやすいものに改良されました。しかし、複雑で学習するのが難しいという初期のGit に対する型にはまったイメージはまだ残っています。
+初期（主に1.5より古いバージョン）のGitのユーザーインターフェイスは、今よりずっと複雑でした。これは、当時のGitが、洗練されたVCSであることよりも、このファイルシステムの方を重要視していたためです。
+ここ数年で、Gitのユーザーインターフェイスは改良されて、世の中にある他のシステムと同じくらいシンプルで扱いやすいものになりました。しかし、複雑で学習するのが難しいという、初期のGitのUIに対するステレオタイプはいまだに残っています。
 
 //////////////////////////
 The content-addressable filesystem layer is amazingly cool, so we'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.
 //////////////////////////
-連想記憶ファイル・システム層は驚くほど素晴らしいので、この章の最初にそれをカバーすることにします。その次に転送メカニズムと、今後あなたが行う必要があるかもしれないリポジトリの保守作業について学習することにします。
+内容アドレスファイルシステムの層は驚くほど素晴らしいので、この章の最初で取り上げます。その次に転送メカニズムと、今後あなたが行う必要があるかもしれないリポジトリの保守作業について学習することにします。
 
 include::sections/plumbing-porcelain.asc[]
 
@@ -49,18 +55,20 @@ include::sections/environment.asc[]
 //////////////////////////
 === Summary
 //////////////////////////
-=== 要約
+=== まとめ
 
 //////////////////////////
 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.
 //////////////////////////
-Git がバックグラウンドで何を行うのかについて、また、ある程度までの Git の実装の方法について、かなり良い理解が得られたことでしょう。この章では幾つかの配管コマンドを取り扱いました。このコマンドは、本書の残りで学んだ磁器コマンドよりもシンプルでもっと下位レベルのコマンドです。下位レベルで Git がどのように機能するのかを理解することは、なぜ行うのか、何を行うのかを理解して、さらに、あなた自身でツールを書いて、あなた固有のワークフローが機能するようにスクリプト利用することをより容易にします。
+Git がバックグラウンドで行っている処理について、とてもよく理解できたことと思います。また、その実装の方法についても、ある程度の理解が得られたと思います。
+この章では、各種の配管コマンド – 本書の他の章で学んだ磁器コマンドよりも、低レベルでシンプルなコマンド – を何度も使いました。
+Gitがどのように機能しているのかを、より低いレベルで理解すれば、なぜそのようなことを行うのかも容易に理解できるようになるでしょうし、自分のワークフローがうまく機能するように自前のツールや補助スクリプトを書くのもより楽になるはずです。
 
 //////////////////////////
 Git as a content-addressable filesystem is a very powerful tool that you can easily use as more than just a VCS.
 We 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 は単なるバージョン管理システム（VCS）以上のものとして簡単に使用できる、とても強力なツールです。望むらくは、あなたが Git の内側で見つけた新しい知識を使うことです。その知識は、このテクノロジーを利用するあなた自身の素晴らしいアプリケーションを実装するための知識、また、より進歩した方法で Git を使うことをより快適に感じるための知識です。
-
+内容アドレスファイルシステムとしてのGitは、とても強力なツールで、単なるバージョン管理システム以上のものとして使うことも簡単にできます。
+この技術を使って自前の素晴らしいアプリケーションを実装したり、Gitの進んだ使い方をより気楽に利用したりするのに、この章で得たGitの内部に関する知識が役立つことを願っています。

book/10-git-internals/sections/maintenance.asc

@@ -7,7 +7,8 @@
 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.
 //////////////////////////
-時々、幾らかのお掃除をする必要があるかもしれません。つまり、レポジトリをよりコンパクトにすること、インポートしたリポジトリをクリーンアップすること、あるいは失った作業をもとに戻すことです。このセクションではこれらのシナリオの幾つかをカバーします。
+たまには、ちょっとしたお掃除 – リポジトリを圧縮したり、インポートしたリポジトリをクリーンアップしたり、失われた成果物をもとに戻したり – が必要になるかもしれません。
+このセクションではこれらのシナリオのいくつかについて取り上げます。
 
 [[_git_gc]]
 //////////////////////////
@@ -215,7 +216,7 @@ 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:
 //////////////////////////
-なぜなら reflog データは `.git/logs/` ディレクトリに残っているため、あなたは効率的に reflog を持たない状態です。この時点でそのコミットをどうやって復元できるのでしょうか? ひとつの方法は `git fsck` ユティリティーを使用することです。それはあなたのデータベースの完全性（integrity）をチェックします。もし `--full` オプションを付けて実行すると、別のオブジェクトによってポイントされていないすべてのオブジェクトを表示します。
+なぜなら reflog データは `.git/logs/` ディレクトリに残っているため、あなたは効率的に reflog を持たない状態です。この時点でそのコミットをどうやって復元できるのでしょうか? ひとつの方法は `git fsck` ユーティリティーを使用することです。それはあなたのデータベースの完全性（integrity）をチェックします。もし `--full` オプションを付けて実行すると、別のオブジェクトによってポイントされていないすべてのオブジェクトを表示します。
 
 [source,console]
 ----
@@ -262,7 +263,7 @@ If you do this immediately after an import, before anyone has started to base wo
 //////////////////////////
 *注意: このテクニックはあなたのコミット履歴を壊すことになります。*
 大きなファイルへの参照を取り除くために修正が必要な一番前のツリーからすべてのコミットオブジェクトに再書き込みをします。
-もしインポートした後そのコミット上での作業を誰かが開始する前にすぐにこれを行った場合は問題ないです。その他の場合は、あなたの新しいコミット上に作業をリベースしなければならないことをすべての関係者（contributors）に知らせる必要があります。
+もしインポートした後そのコミット上での作業を誰かが開始する前にすぐにこれを行った場合は問題ありません。その他の場合は、あなたの新しいコミット上に作業をリベースしなければならないことをすべての関係者（contributors）に知らせる必要があります。
 
 //////////////////////////
 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.

book/10-git-internals/sections/plumbing-porcelain.asc

@@ -52,4 +52,4 @@ 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.
 //////////////////////////
-残りの4つ（`HEAD` ファイルとまだ作成されていない `index` ファイル、また、`objects` ディレクトリと `refs` ディレクトリ）は重要なエントリです。これらは、Git の中核（コア）の部分に相当します。`objects` ディレクトリはあなたのデータベースのすべてのコンテンツを保管します。`refs` ディレクトリは、そのデータ（ブランチ）内のコミットオブジェクトを指すポインターを保管します。`HEAD` ファイルは、現在チェックアウトしているブランチを指します。`index` ファイルは、Git がステージングエリアの情報の保管する場所を示します。これから各セクションで、Git がどのような仕組みで動くのかを詳細に見ていきます。
+残りの4つ（`HEAD` ファイルとまだ作成されていない `index` ファイル、また、`objects` ディレクトリと `refs` ディレクトリ）は重要なエントリです。これらは、Git の中核（コア）の部分に相当します。`objects` ディレクトリはあなたのデータベースのすべてのコンテンツを保管します。`refs` ディレクトリは、そのデータ（ブランチ）内のコミットオブジェクトを指すポインターを保管します。`HEAD` ファイルは、現在チェックアウトしているブランチを指します。`index` ファイルは、Git がステージングエリアの情報を保管する場所を示します。これから各セクションで、Git がどのような仕組みで動くのかを詳細に見ていきます。

book/10-git-internals/sections/refs.asc

@@ -266,7 +266,7 @@ 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:
 //////////////////////////
-これから見ていく三つ目の参照のタイプはリモート参照です。リモートを追加してそれにプッシュを実行すると、Git は追加したリモートにあなたが最後にプッシュした値をを格納します。そのリモートは `refs/remotes` ディレクトリにある各ブランチを参照します。例えば、`origin` と呼ばれるリモートを追加して、それを `master` ブランチにプッシュすることができます。
+これから見ていく三つ目の参照のタイプはリモート参照です。リモートを追加してそれにプッシュを実行すると、Git は追加したリモートにあなたが最後にプッシュした値を格納します。そのリモートは `refs/remotes` ディレクトリにある各ブランチを参照します。例えば、`origin` と呼ばれるリモートを追加して、それを `master` ブランチにプッシュすることができます。
 
 [source,console]
 ----

book/10-git-internals/sections/refspec.asc

@@ -188,7 +188,7 @@ Again, this will cause a `git push origin` to push the local `master` branch to
 //////////////////////////
 You can also use the refspec to delete references from the remote server by running something like this:
 //////////////////////////
-また、リモートサーバーから以下のように実行することによって、参照仕様を参照を削除する目的で使用することもできます。
+また、参照仕様を使ってリモートサーバーから参照を削除することもできます。削除するには以下のコマンドを実行します。
 
 [source,console]
 ----
@@ -199,4 +199,3 @@ $ 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.
 //////////////////////////
 参照仕様は `<src>:<dst>` という形式であり、`<src>` の部分を取り除くことは、要するに何もないブランチをリモート上に作ることであり、それを削除することになるのです。
-