diff --git a/C-git-commands.asc b/C-git-commands.asc index fcbb9a0f..99e6a49b 100644 --- a/C-git-commands.asc +++ b/C-git-commands.asc @@ -390,7 +390,7 @@ It can list the branches you have, create a new branch, delete branches and rena Most of <> is dedicated to the `branch` command and it's used throughout the entire chapter. We first introduce it in <> and we go through most of its other features (listing and deleting) in <>. ////////////////////////// -<> のほとんどは `branch` コマンドに費やされており、この章の全体に渡って`branch` コマンドが使用されています。最初にこのコマンドを紹介したのは <> で、そこで扱った以外の機能（一覧表示と削除）のほとんどは <> で見てきました。 +<> のほとんどは `branch` コマンドに費やされており、この章の全体に渡って `branch` コマンドが使用されています。最初にこのコマンドを紹介したのは <> で、そこで扱った以外の機能（一覧表示と削除）のほとんどは <> で見てきました。 ////////////////////////// In <> we use the `git branch -u` option to set up a tracking branch. @@ -456,7 +456,7 @@ We covered how to do a squashed merge (where Git merges the work but pretends li ////////////////////////// We went over a lot about the merge process and command, including the `-Xignore-space-change` command and the `--abort` flag to abort a problem merge in <>. ////////////////////////// -<> では、マージのプロセスとコマンドについて多くを見てきました。これには、-Xignore-space-change` コマンドや、 `--abort` フラグを使って問題のあるマージを中断する方法が含まれます。 +<> では、マージのプロセスとコマンドについて多くを見てきました。これには、`-Xignore-space-change` コマンドや、 `--abort` フラグを使って問題のあるマージを中断する方法が含まれます。 ////////////////////////// We learned how to verify signatures before merging if your project is using GPG signing in <>. @@ -550,7 +550,7 @@ This is basically entirely covered in <>. The `git tag` command is used to give a permanent bookmark to a specific point in the code history. Generally this is used for things like releases. ////////////////////////// -`git tag`コマンドは、コードの歴史の中で、特定のポイントに永続的なブックマークを付与するのに使用されます。一般的には、このコマンドはリリース作業などで使用されます。 +`git tag` コマンドは、コードの歴史の中で、特定のポイントに永続的なブックマークを付与するのに使用されます。一般的には、このコマンドはリリース作業などで使用されます。 ////////////////////////// This command is introduced and covered in detail in <> and we use it in practice in <>. @@ -642,7 +642,7 @@ Here we cover the basics of pushing a branch to a remote repository. In <> we go a little deeper into pushing specific branches and in <> we see how to set up tracking branches to automatically push to. In <> we use the `--delete` flag to delete a branch on the server with `git push`. ////////////////////////// -最初に `git push` コマンドについて見たのは <> でした。ここでは、ブランチをリモートリポジトリへプッシュする基本に触れました。<> では、特定のブランチをプッシュする方法について少し詳細に見てきました。 <> では、自動的にプッシュをするために、追跡ブランチを設定する方法を見てきました。<> では、`git push` でサーバ上のブランチを削除するために、`--delete`フラグを使用しました。 +最初に `git push` コマンドについて見たのは <> でした。ここでは、ブランチをリモートリポジトリへプッシュする基本に触れました。<> では、特定のブランチをプッシュする方法について少し詳細に見てきました。 <> では、自動的にプッシュをするために、追跡ブランチを設定する方法を見てきました。<> では、`git push` でサーバ上のブランチを削除するために、 `--delete` フラグを使用しました。 ////////////////////////// Throughout <> we see several examples of using `git push` to share work on branches through multiple remotes. @@ -900,7 +900,7 @@ Git自体を含め、多くのGitプロジェクトは、もっぱらメーリ The `git apply` command applies a patch created with the `git diff` or even GNU diff command. It is similar to what the `patch` command might do with a few small differences. ////////////////////////// -`git apply` コマンドは、`git diff` コマンドまたはGNU diffコマンドで作成したパッチを適用します。ほんの少しの違いを除けば、これは`patch` コマンドが行うであろう処理と同様のものです。 +`git apply` コマンドは、`git diff` コマンドまたはGNU diffコマンドで作成したパッチを適用します。ほんの少しの違いを除けば、これは `patch` コマンドが行うであろう処理と同様のものです。 ////////////////////////// We demonstrate using it and the circumstances in which you might do so in <>. @@ -918,7 +918,7 @@ This is useful for receiving patches over email and applying them to your projec ////////////////////////// We covered usage and workflow around `git am` in <> including using the `--resolved`, `-i` and `-3` options. ////////////////////////// -<> では、`--resolved、, `-i` および `-3` オプションの使い方を含め、 `git am` コマンドの使い方とワークフローを取り上げました。 +<> では、`--resolved` 、 `-i` および `-3` オプションの使い方を含め、 `git am` コマンドの使い方とワークフローを取り上げました。 ////////////////////////// There are also a number of hooks you can use to help with the workflow around `git am` and they are all covered in <>. diff --git a/TRANSLATION_NOTES.asc b/TRANSLATION_NOTES.asc index 012457e6..1c53a458 100644 --- a/TRANSLATION_NOTES.asc +++ b/TRANSLATION_NOTES.asc @@ -40,5 +40,5 @@ https://github.com/progit/progit2-ja/releases[Releases] に掲載されている 以下の作業を行ってください。 -1. `status.json`の更新（コンテンツ自動生成時に使用されます） +1. `status.json` の更新（コンテンツ自動生成時に使用されます） 1. 作業完了の意思表示（該当のissueやPull Requestにコメントする） \ No newline at end of file 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..b3996102 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 `:(((git commands, config))) ////////////////////////// -また、Gitに設定されている特定のキーの値を、`git config `とタイプすることで確認することができます：(((git commands, config))) +また、Gitに設定されている特定のキーの値を、 `git config ` とタイプすることで確認することができます：(((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..583bd54f 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..ac6af154 100644 --- a/book/02-git-basics/sections/recording-changes.asc +++ b/book/02-git-basics/sections/recording-changes.asc @@ -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 <>. ////////////////////////// -今のところは、`git reset`については上記の魔法の呪文を知っておけば十分でしょう。<>で、より詳細に、`reset`の役割と使いこなし方について説明します。色々とおもしろいことができるようになりますよ。 +今のところは、`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..594ee7f7 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` の出力フォーマット指定のほんの一部でしかありません。 まだまだオプションはあります。 <> に、今まで取り上げたオプションやそれ以外によく使われるオプション、 -そしてそれぞれが`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 <> 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/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..0591de1e 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] @@ -492,7 +492,7 @@ 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`ファイルを +例えば、`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/08-customizing-git/sections/hooks.asc b/book/08-customizing-git/sections/hooks.asc index ea697695..dca31188 100644 --- a/book/08-customizing-git/sections/hooks.asc +++ b/book/08-customizing-git/sections/hooks.asc @@ -91,7 +91,7 @@ This hook takes a few parameters: the path to the file that holds the commit mes This hook generally isn't useful for normal commits; rather, it's good for commits where the default message is auto-generated, such as templated commit messages, merge commits, squashed commits, and amended commits. You may use it in conjunction with a commit template to programmatically insert information. ////////////////////////// -`prepare-commit-msg`フックは、コミットメッセージエディターが起動する直前、デフォルトメッセージが生成された直後に実行されます。 +`prepare-commit-msg` フックは、コミットメッセージエディターが起動する直前、デフォルトメッセージが生成された直後に実行されます。 このフックでは、デフォルトメッセージを、コミットの作者の目に触れる前に編集できます。 このフックにはパラメータがあり、その時点でのコミットメッセージを保存したファイルへのパス、コミットのタイプ、さらにamendされたコミットの場合はコミットの SHA-1 をパラメータとして取ります。 このフックは普段のコミットにおいてはあまり有用ではありませんが、テンプレートが用意されているコミットメッセージ・mergeコミット・squashコミット・amendコミットのような、デフォルトメッセージが自動生成されるコミットにおいて効果を発揮します。 @@ -111,7 +111,7 @@ After the entire commit process is completed, the `post-commit` hook runs. It doesn't take any parameters, but you can easily get the last commit by running `git log -1 HEAD`. Generally, this script is used for notification or something similar. ////////////////////////// -コミットプロセスが全て完了した後には、`post-commit`フックが実行されます。 +コミットプロセスが全て完了した後には、`post-commit` フックが実行されます。 このフックはパラメータを取りませんが、 `git log -1 HEAD` を実行することで直前のコミットを簡単に取り出すことができます。 一般的にこのスクリプトは何かしらの通知といった目的に使用されます。 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..c076a13a 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/10-git-internals/sections/objects.asc b/book/10-git-internals/sections/objects.asc index eded9f1f..c8a3f24e 100644 --- a/book/10-git-internals/sections/objects.asc +++ b/book/10-git-internals/sections/objects.asc @@ -235,10 +235,10 @@ Then, you specify the mode, SHA-1, and filename: 自前でツリーを作るのも非常に簡単です。 Gitは通常、ステージングエリアやインデックスの状態を取得してツリーを作成し、そのツリーをもとに一連のツリーオブジェクトを書き込みます。 そのため、ツリーオブジェクトを作るには、まずファイルをステージングしてインデックスを作成しなければなりません。 -単一のエントリー – ここでは`test.txt`ファイルの最初のバージョン – からインデックスを作るには、`update-index` という配管コマンドを使います。 -このコマンドは、前のバージョンの`test.txt`ファイルをあえて新しいステージングエリアに追加する際に使用します。 +単一のエントリー – ここでは `test.txt` ファイルの最初のバージョン – からインデックスを作るには、`update-index` という配管コマンドを使います。 +このコマンドは、前のバージョンの `test.txt` ファイルをあえて新しいステージングエリアに追加する際に使用します。 ファイルはまだステージングエリアには存在しない（まだステージングエリアをセットアップさえしていない）ので、`--add` オプションを付けなければなりません。 -また、追加しようとしているファイルはディレクトリには無くデータベースにあるので、`--cacheinfo`オプションを付ける必要があります。 +また、追加しようとしているファイルはディレクトリには無くデータベースにあるので、`--cacheinfo` オプションを付ける必要があります。 その次に、モード、SHA-1、ファイル名を指定します。 [source,console] @@ -285,7 +285,7 @@ tree ////////////////////////// You'll now create a new tree with the second version of `test.txt` and a new file as well: ////////////////////////// -今度は、2つめのバージョンの`test.txt`と、新規作成したファイルから、新しくツリーを作ります。 +今度は、2つめのバージョンの `test.txt` と、新規作成したファイルから、新しくツリーを作ります。 [source,console] ---- @@ -298,7 +298,7 @@ $ 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: ////////////////////////// -これでステージングエリアには、`new.txt`という新しいファイルに加えて、新しいバージョンの`test.txt`も登録されました。 +これでステージングエリアには、`new.txt` という新しいファイルに加えて、新しいバージョンの `test.txt` も登録されました。 このツリーを書き出して（ステージングエリアまたはインデックスの状態をツリーオブジェクトとして記録して）、どのようになったか見てみましょう。 [source,console] @@ -316,7 +316,7 @@ 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`: ////////////////////////// -このツリーに両方のファイルエントリがあること、また、`test.txt`のSHA-1が先ほどの ``version 2'' のSHA-1（`1f7a7a`）であることに注意してください。 +このツリーに両方のファイルエントリがあること、また、`test.txt` のSHA-1が先ほどの ``version 2'' のSHA-1（`1f7a7a`）であることに注意してください。 ちょっと試しに、最初のツリーをサブディレクトリとしてこの中に追加してみましょう。 `read-tree` を呼ぶことで、ステージングエリアの中にツリーを読み込むことができます。 このケースでは、`--prefix` オプションを付けて `read-tree` コマンドを使用することで、ステージングエリアの中に、既存のツリーをサブツリーとして読み込むことができます。 @@ -336,7 +336,7 @@ $ git cat-file -p 3c4e9cd789d88d8d89c1073707c3585e41b0e614 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 this: ////////////////////////// -先ほど書き込んだ新しいツリーから作業ディレクトリを作っていれば、作業ディレクトリの直下にファイルが2つと、最初のバージョンの`test.txt`ファイルが含まれている `bak` という名前のサブディレクトリが入ります。 +先ほど書き込んだ新しいツリーから作業ディレクトリを作っていれば、作業ディレクトリの直下にファイルが2つと、最初のバージョンの `test.txt` ファイルが含まれている `bak` という名前のサブディレクトリが入ります。 このような構成に対し、Gitが格納するデータのイメージは次のようになります。 ////////////////////////// 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.