Translate Chapter7 "Git Tools"

book/07-git-tools/1-git-tools.asc

@@ -1,10 +1,20 @@
 [[_git_tools]]
+//////////////////////////
 == Git Tools
+//////////////////////////
+== Git のさまざまなツール
 
+//////////////////////////
 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.
+//////////////////////////
+Git を使ったソースコード管理のためのリポジトリの管理や保守について、日々使用するコマンドやワークフローの大半を身につけました。
+ファイルの追跡やコミットといった基本的なタスクをこなせるようになっただけではなくステージングエリアの威力もいかせるようになりました。また気軽にトピックブランチを切ってマージする方法も知りました。
 
+//////////////////////////
 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.
+//////////////////////////
+では、Git の非常に強力な機能の数々をさらに探っていきましょう。日々の作業でこれらを使うことはあまりありませんが、いつかは必要になるかもしれません。
 
 include::sections/revision-selection.asc[]
 
@@ -34,9 +44,18 @@ include::sections/replace.asc[]
 
 include::sections/credentials.asc[]
 
+//////////////////////////
 === Summary
+//////////////////////////
+=== まとめ
 
+//////////////////////////
 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 how 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.
+//////////////////////////
+さまざまな高度な道具を使い、コミットやステージングエリアをより細やかに操作できる方法をまとめました。
+何か問題が起こったときには、いつ誰がどのコミットでそれを仕込んだのかを容易に見つけられるようになったことでしょう。
+また、プロジェクトの中で別のプロジェクトを使いたくなったときのための方法も紹介しました。
+Git を使った日々のコマンドラインでの作業の大半を、自信を持ってできるようになったことでしょう。

book/07-git-tools/sections/bundling.asc

@@ -1,13 +1,28 @@
 [[_bundling]]
+//////////////////////////
 === Bundling
+//////////////////////////
+=== バンドルファイルの作成
 
+//////////////////////////
 Though we've covered the common ways to transfer Git data over a network (HTTP, SSH, etc), there is actually one more way to do so that is not commonly used but can actually be quite useful.
+//////////////////////////
+Git データをネットワーク越しに転送する方法（HTTP や SSH など）についてはすでに触れましたが、まだ紹介していない方法があります。あまり使われてはいませんが、とても便利な方法です。
 
+//////////////////////////
 Git is capable of ``bundling'' it's data into a single file. This can be useful in various scenarios. Maybe your network is down and you want to send changes to your co-workers. Perhaps you're working somewhere offsite and don't have access to the local network for security reasons. Maybe your wireless/ethernet card just broke.  Maybe you don't have access to a shared server for the moment, you want to email someone updates and you don't want to transfer 40 commits via `format-patch`.
+//////////////////////////
+Git では、データを「バンドルファイル」という1つのファイルにまとめられます。これが便利な場面はいくつもあるでしょう。例えば、ネットワークが落ちていて同僚に変更を送れないような場合。あるいは、いつもとは違う場所で仕事をしていて、セキュリティ上の理由によってネットワークへのアクセスが禁止されているのかもしれません。無線/有線LAN用のカードが壊れてしまったとか。もしくは、共有サーバーにはアクセス出来ないので作業内容をメールで送りたいけれど、かといって40ものコミットを `format-patch` を使って送りたくはない、ということかもしれません。
 
+//////////////////////////
 This is where the `git bundle` command can be helpful. The `bundle` command will package up everything that would normally be pushed over the wire with a `git push` command into a binary file that you can email to someone or put on a flash drive, then unbundle into another repository.
+//////////////////////////
+そんなとき、`git bundle` コマンドが役に立つでしょう。このコマンドを使うと、`git push` コマンドで転送されるのと同内容のデータを単一のバイナリファイルにまとめてくれます。あとは、そのファイルをメールで送るか USB メモリに入れるなどしておいて、別のリポジトリ上で展開すればいいのです。
 
+//////////////////////////
 Let's see a simple example. Let's say you have a repository with two commits:
+//////////////////////////
+コミットが2つあるリポジトリを使って、簡単な例を紹介します。
 
 [source,console]
 ----
@@ -25,7 +40,10 @@ Date:   Wed Mar 10 07:34:01 2010 -0800
     first commit
 ----
 
+//////////////////////////
 If you want to send that repository to someone and you don't have access to a repository to push to, or simply don't want to set one up, you can bundle it with `git bundle create`.
+//////////////////////////
+このリポジトリを相手に送りたいのだけど、プッシュすべきリポジトリの書き込み権限が付与されていないとしましょう（あるいは、わざわざ権限を設定したくなかったのかもしれません）。そういった場合には、`git bundle create` コマンドを使うとそのリポジトリをまとめられます。
 
 [source,console]
 ----
@@ -37,11 +55,20 @@ Writing objects: 100% (6/6), 441 bytes, done.
 Total 6 (delta 0), reused 0 (delta 0)
 ----
 
+//////////////////////////
 Now you have a file named `repo.bundle` that has all the data needed to re-create the repository's `master` branch. With the `bundle` command you need to list out every reference or specific range of commits that you want to be included. If you intend for this to be cloned somewhere else, you should add HEAD as a reference as well as we've done here.
+//////////////////////////
+これで、`repo.bundle` というファイルが生成されました。対象リポジトリの `master` ブランチを復元できるだけのデータが含まれたファイルです。この `bundle` コマンドを使うには、まとめたい対象を範囲指定されたコミットや参照の形で指定する必要があります。クローン元となる予定であれば、HEAD を参照として追加しておくほうがよいでしょう（上記の例と同様）。
 
+//////////////////////////
 You can email this `repo.bundle` file to someone else, or put it on a USB drive and walk it over.
+//////////////////////////
+この `repo.bundle` ファイルはメールで送ってもいいですし、USB メモリに入れて持っていってもかまいません。
 
+//////////////////////////
 On the other side, say you are sent this `repo.bundle` file and want to work on the project. You can clone from the binary file into a directory, much like you would from a URL.
+//////////////////////////
+では、この `repo.bundle` ファイルを受け取った側はどうなるのでしょうか。該当のプロジェクトで作業をしたいとします。その場合、このバイナリファイルをディレクトリ上にクローンできます。URL を指定してクローンするのとなんら変わりありません。
 
 [source,console]
 ----
@@ -53,9 +80,16 @@ $ git log --oneline
 b1ec324 first commit
 ----
 
+//////////////////////////
 If you don't include HEAD in the references, you have to also specify `-b master` or whatever branch is included because otherwise it won't know what branch to check out.
+//////////////////////////
+まとめる対象として HEAD が含まれていないと、ここで、 `-b master` のように、なんらかのブランチを指定しなければなりません。そうしないと、どのブランチをチェックアウトすべきか、判断する術がないからです。
 
+//////////////////////////
 Now let's say you do three commits on it and want to send the new commits back via a bundle on a USB stick or email.
+//////////////////////////
+続いて、さきほど受け取ったリポジトリにコミットを3つ追加しました。バンドルファイルを作成して、USB メモリかメールで送り返してみましょう。
+
 
 [source,console]
 ----
@@ -67,9 +101,15 @@ c99cf5b fourth commit - second repo
 b1ec324 first commit
 ----
 
+//////////////////////////
 First we need to determine the range of commits we want to include in the bundle. Unlike the network protocols which figure out the minimum set of data to transfer over the network for us, we'll have to figure this out manually.  Now, you could just do the same thing and bundle the entire repository, which will work, but it's better to just bundle up the difference - just the three commits we just made locally.
+//////////////////////////
+それには、バンドルファイルにまとめたいコミット範囲をまず決めます。ネットワークを使った方法であれば転送すべき範囲を最小限に自動で絞り込んでくれますが、ここでは手動で絞りこまねばなりません。最初にバンドルファイルを作ったときのようにリポジトリ全体をまとめてもかまいませんが、差分（この場合は追加したコミット3つ）だけをまとめるほうがよいでしょう。
 
+//////////////////////////
 In order to do that, you'll have to calculate the difference. As we described in <<_commit_ranges>>, you can specify a range of commits in a number of ways. To get the three commits that we have in our master branch that weren't in the branch we originally cloned, we can use something like `origin/master..master` or `master ^origin/master`. You can test that with the `log` command.
+//////////////////////////
+そうするには、差分を割り出す必要があります。<<_commit_ranges>> で解説したとおり、コミット範囲を指定する方法はたくさんあります。手元の master ブランチにはあってクローン元のブランチにはないコミット3つを指定するには、`origin/master..master` や `master ^origin/master` などとするとよいでしょう。記述をテストするには、`log` コマンドを使います。
 
 [source,console]
 ----
@@ -79,7 +119,10 @@ c99cf5b fourth commit - second repo
 7011d3d third commit - second repo
 ----
 
+//////////////////////////
 So now that we have the list of commits we want to include in the bundle, let's bundle them up. We do that with the `git bundle create` command, giving it a filename we want our bundle to be and the range of commits we want to go into it.
+//////////////////////////
+対象のコミットがわかったので、ひとつにまとめてみましょう。バンドルファイルのファイル名と対象のコミット範囲を指定して `git bundle create` コマンドを実行します。
 
 [source,console]
 ----
@@ -91,9 +134,15 @@ Writing objects: 100% (9/9), 775 bytes, done.
 Total 9 (delta 0), reused 0 (delta 0)
 ----
 
+//////////////////////////
 Now we have a `commits.bundle` file in our directory. If we take that and send it to our partner, she can then import it into the original repository, even if more work has been done there in the meantime.
+//////////////////////////
+このようにすると、リポジトリ内に `commits.bundle` ファイルが生成されます。そのファイルを送り返すと、受け取った相手は元のリポジトリにその内容を取り込めます。そのリポジトリに他の作業内容が追加されていたとしても問題にはなりません。
 
+//////////////////////////
 When she gets the bundle, she can inspect it to see what it contains before she imports it into her repository.  The first command is the `bundle verify` command that will make sure the file is actually a valid Git bundle and that you have all the necessary ancestors to reconstitute it properly.
+//////////////////////////
+バンドルファイルを受け取った側は、それを検査して中身を確認できます。その後、元のリポジトリに取り込めばよいのです。そのためのコマンドが `bundle verify` で、これを実行すると、そのファイルが Git のバンドルファイルであること、そのバンドルファイルを取り込むのに必要となる祖先が手元のリポジトリにあるかどうかを検査できます。
 
 [source,console]
 ----
@@ -105,7 +154,10 @@ The bundle requires these 1 ref
 ../commits.bundle is okay
 ----
 
+//////////////////////////
 If the bundler had created a bundle of just the last two commits they had done, rather than all three, the original repository would not be able to import it, since it is missing requisite history.  The `verify` command would have looked like this instead:
+//////////////////////////
+バンドルファイルを作る側が、追加されたコミット3つのうち2つしかバンドルファイルに含めなかったとしたらどうなるのでしょうか。その場合、元のリポジトリはそれを取り込めません。歴史を再構成するために必要なデータが揃っていないからです。もし `verify` コマンドを実行すれば、以下のようになるでしょう。
 
 [source,console]
 ----
@@ -114,15 +166,21 @@ error: Repository lacks these prerequisite commits:
 error: 7011d3d8fc200abe0ad561c011c3852a4b7bbe95 third commit - second repo
 ----
 
+//////////////////////////
 However, our first bundle is valid, so we can fetch in commits from it.  If you want to see what branches are in the bundle that can be imported, there is also a command to just list the heads:
+//////////////////////////
+この例では、1つめに検査したバンドルファイルは有効だったので、コミットを取り出せます。バンドルファイルに含まれている取り込み可能なブランチを知りたければ、ブランチ参照をリストアップするためのコマンドもあります。
 
 [source,console]
 ----
 $ git bundle list-heads ../commits.bundle
 71b84daaf49abed142a373b6e5c59a22dc6560dc refs/heads/master
 ----
 
+//////////////////////////
 The `verify` sub-command will tell you the heads as well.  The point is to see what can be pulled in, so you can use the `fetch` or `pull` commands to import commits from this bundle.  Here we'll fetch the 'master' branch of the bundle to a branch named 'other-master' in our repository:
+//////////////////////////
+`verify` サブコマンドを使っても、同様にブランチ参照をリストアップできます。大事なのは、何が取り込めるのかを確認する、ということです。そうすれば、`fetch` や `pull` コマンドを使ってバンドルファイルからコミットを取り込めるからです。ここでは、バンドルファイルの 'master' ブランチを、手元のリポジトリの 'other-master' ブランチに取り込んでみましょう。
 
 [source,console]
 ----
@@ -131,7 +189,10 @@ From ../commits.bundle
  * [new branch]      master     -> other-master
 ----
 
+//////////////////////////
 Now we can see that we have the imported commits on the 'other-master' branch as well as any commits we've done in the meantime in our own 'master' branch.
+//////////////////////////
+そうすると、'master' ブランチに追加したコミットはそのままで、'other-master' ブランチ上にバンドルファイルからコミットが取り込まれていることがわかります。
 
 [source,console]
 ----
@@ -145,4 +206,7 @@ $ git log --oneline --decorate --graph --all
 * b1ec324 first commit
 ----
 
+//////////////////////////
 So, `git bundle` can be really useful for sharing or doing network-type operations when you don't have the proper network or shared repository to do so.
+//////////////////////////
+このように、データの共有やネットワークを使う作業に `git bundle` はとても便利なコマンドです。特にネットワーク環境や共有リポジトリがない状態ではそれを実感できるでしょう。