rbenv でインストールした ruby にバージョン指定した rdiscount を導入する
$ rbenv version
1.9.3-p194 (set by /home/ubuntu/progit/.ruby-version)
$ gem install rdiscount --version 1.6.8
$ gem list --local
rdiscount (1.6.8)
$ apt-cache show ruby-rdiscount
Version: 1.6.8-2
$ gem list --local rdiscount
*** LOCAL GEMS ***
rdiscount (2.1.6)
| diff --git a/progit.ja.html b/progit.ja.html | |
| index 2d1aacb..d51db98 100644 | |
| --- a/progit.ja.html | |
| +++ b/progit.ja.html | |
| @@ -193,7 +193,7 @@ $ sudo make prefix=/usr/local install | |
| <p>インストール後、コマンドライン版（後で役に立つSSHクライアントを含む）とスタンダードGUI版の両方を使う事ができます。</p> | |
| -<p>Windows利用時の注意点: この本で紹介されている複雑なコマンドを使えるので､GitはmsysGit shell(Unixスタイル)で使うようにしましょう｡Windowsのシェル/コマンドラインコンソールを使わざるを得ない場合､空白を含むパラメーターを囲むための記号はダブルクオーテーション(シングルクォーテーションは使えない)を使用する必要があります｡同様に､サーカムフレックス記号(<sup>)が行末に来る場合はダブルクオーテーションで囲まなければなりません｡同記号はWindowsにおいて｢次行に続く｣を意味する記号だからです｡</sup></p> | |
| +<p>Windows利用時の注意点: この本で紹介されている複雑なコマンドを使えるので､GitはmsysGit shell(Unixスタイル)で使うようにしましょう｡Windowsのシェル/コマンドラインコンソールを使わざるを得ない場合､空白を含むパラメーターを囲むための記号はダブルクオーテーション(シングルクォーテーションは使えない)を使用する必要があります｡同様に､サーカムフレックス記号(^)が行末に来る場合はダブルクオーテーションで囲まなければなりません｡同記号はWindowsにおいて｢次行に続く｣を意味する記号だからです｡</p> | |
| <h2>最初のGitの構成</h2> | |
| @@ -293,7 +293,7 @@ $ man git-<verb> | |
| <pre><code>$ git init | |
| </code></pre> | |
| -<p>これを実行すると <code>.git</code> という名前の新しいサブディレクトリが作られ、リポジトリに必要なすべてのファイル (Git リポジトリのスケルトン) がその中に格納されます。この時点では、まだプロジェクト内のファイルは一切管理対象になっていません (今作った <code>.git</code> ディレクトリに実際のところどんなファイルが含まれているのかについての詳細な情報は、<em>第 9 章</em> を参照ください)。</p> | |
| +<p>これを実行すると <code>.git</code> という名前の新しいサブディレクトリが作られ、リポジトリに必要なすべてのファイル (Git リポジトリのスケルトン) がその中に格納されます。この時点では、まだプロジェクト内のファイルは一切管理対象になっていません (今作った <code>.git</code> ディレクトリに実際のところどんなファイルが含まれているのかについての詳細な情報は、*第 9 章* を参照ください)。</p> | |
| <p>空のディレクトリではなくすでに存在するファイルのバージョン管理を始めたい場合は、まずそのファイルを監視対象に追加してから最初のコミットをすることになります。この場合は、追加したいファイルについて <code>git add</code> コマンドを実行したあとでコミットを行います。</p> | |
| @@ -306,7 +306,7 @@ $ git commit -m 'initial project version' | |
| <h3>既存のリポジトリのクローン</h3> | |
| -<p>既存の Git リポジトリ (何か協力したいと思っているプロジェクトなど) のコピーを取得したい場合に使うコマンドが、<code>git clone</code> です。Subversion などの他の VCS を使っている人なら「<code>checkout</code> じゃなくて <code>clone</code> なのか」と気になることでしょう。これは重要な違いです。Git は、サーバーが保持しているデータをほぼすべてコピーするのです。そのプロジェクトのすべてのファイルのすべての歴史が、<code>git clone</code> で手元にやってきます。実際、もし仮にサーバーのディスクが壊れてしまったとしても、どこかのクライアントに残っているクローンをサーバーに戻せばクローンした時点まで復元することができます (サーバーサイドのフックなど一部の情報は失われてしまいますが、これまでのバージョン管理履歴はすべてそこに残っています。<em>第 4 章</em> で詳しく説明します)。</p> | |
| +<p>既存の Git リポジトリ (何か協力したいと思っているプロジェクトなど) のコピーを取得したい場合に使うコマンドが、<code>git clone</code> です。Subversion などの他の VCS を使っている人なら「<code>checkout</code> じゃなくて <code>clone</code> なのか」と気になることでしょう。これは重要な違いです。Git は、サーバーが保持しているデータをほぼすべてコピーするのです。そのプロジェクトのすべてのファイルのすべての歴史が、<code>git clone</code> で手元にやってきます。実際、もし仮にサーバーのディスクが壊れてしまったとしても、どこかのクライアントに残っているクローンをサーバーに戻せばクローンした時点まで復元することができます (サーバーサイドのフックなど一部の情報は失われてしまいますが、これまでのバージョン管理履歴はすべてそこに残っています。*第 4 章* で詳しく説明します)。</p> | |
| <p>リポジトリをクローンするには <code>git clone [url]</code> とします。たとえば、Ruby の Git ライブラリである Grit をクローンする場合は次のようになります。</p> | |
| @@ -320,15 +320,15 @@ $ git commit -m 'initial project version' | |
| <p>このコマンドは先ほどと同じ処理をしますが、ディレクトリ名は <code>mygrit</code> となります。</p> | |
| -<p>Git では、さまざまな転送プロトコルを使用することができます。先ほどの例では <code>git://</code> プロトコルを使用しましたが、<code>http(s)://</code> や <code>user@server:/path.git</code> といった形式を使うこともできます。これらは SSH プロトコルを使用します。<em>第 4 章</em> で、サーバー側で準備できるすべてのアクセス方式についての利点と欠点を説明します。</p> | |
| +<p>Git では、さまざまな転送プロトコルを使用することができます。先ほどの例では <code>git://</code> プロトコルを使用しましたが、<code>http(s)://</code> や <code>user@server:/path.git</code> といった形式を使うこともできます。これらは SSH プロトコルを使用します。*第 4 章* で、サーバー側で準備できるすべてのアクセス方式についての利点と欠点を説明します。</p> | |
| <h2>変更内容のリポジトリへの記録</h2> | |
| <p>これで、れっきとした Git リポジトリを準備して、そのプロジェクト内のファイルの作業コピーを取得することができました。次は、そのコピーに対して何らかの変更を行い、適当な時点で変更内容のスナップショットをリポジトリにコミットすることになります。</p> | |
| -<p>作業コピー内の各ファイルには <em>追跡されている(tracked)</em> ものと <em>追跡されてない(untracked)</em> ものの二通りがあることを知っておきましょう。<em>追跡されている</em> ファイルとは、直近のスナップショットに存在したファイルのことです。これらのファイルについては変更されていない(unmodified)」「変更されている(modified)」「ステージされている(staged)」の三つの状態があります。追跡されていないファイルは、そのどれでもありません。直近のスナップショットには存在せず、ステージングエリアにも存在しないファイルのことです。最初にプロジェクトをクローンした時点では、すべてのファイルは「追跡されている」かつ「変更されていない」状態となります。チェックアウトしただけで何も編集していない状態だからです。</p> | |
| +<p>作業コピー内の各ファイルには *追跡されている(tracked)<em> ものと *追跡されてない(untracked)</em> ものの二通りがあることを知っておきましょう。*追跡されている* ファイルとは、直近のスナップショットに存在したファイルのことです。これらのファイルについては変更されていない(unmodified)」「変更されている(modified)」「ステージされている(staged)」の三つの状態があります。追跡されていないファイルは、そのどれでもありません。直近のスナップショットには存在せず、ステージングエリアにも存在しないファイルのことです。最初にプロジェクトをクローンした時点では、すべてのファイルは「追跡されている」かつ「変更されていない」状態となります。チェックアウトしただけで何も編集していない状態だからです。</p> | |
| -<p>ファイルを編集すると、Git はそれを「変更された」とみなします。直近のコミットの後で変更が加えられたからです。変更されたファイルを <em>ステージ</em> し、それをコミットする。この繰り返しです。ここまでの流れを図 2-1 にまとめました。</p> | |
| +<p>ファイルを編集すると、Git はそれを「変更された」とみなします。直近のコミットの後で変更が加えられたからです。変更されたファイルを *ステージ* し、それをコミットする。この繰り返しです。ここまでの流れを図 2-1 にまとめました。</p> | |
| <p><img src="figures/2.1.png" title="2.1 ファイルの状態の流れ" alt="2.1 ファイルの状態の流れ" /></p> | |
| @@ -599,7 +599,7 @@ index 3cb747f..e445e28 100644 | |
| <pre><code>$ git commit | |
| </code></pre> | |
| -<p>これを実行すると、指定したエディタが立ち上がります (シェルの <code>$EDITOR</code> 環境変数で設定されているエディタ。通常は vim あるいは emacs でしょう。しかし、それ以外にも <em>第 1 章</em> で説明した <code>git config --global core.editor</code> コマンドでお好みのエディタを指定することもできます)。</p> | |
| +<p>これを実行すると、指定したエディタが立ち上がります (シェルの <code>$EDITOR</code> 環境変数で設定されているエディタ。通常は vim あるいは emacs でしょう。しかし、それ以外にも *第 1 章* で説明した <code>git config --global core.editor</code> コマンドでお好みのエディタを指定することもできます)。</p> | |
| <p>エディタには次のようなテキストが表示されています (これは Vim の画面の例です)。</p> | |
| @@ -653,7 +653,7 @@ $ git commit -a -m 'added new benchmarks' | |
| <p>ファイルを Git から削除するには、追跡対象からはずし (より正確に言うとステージングエリアから削除し)、そしてコミットします。<code>git rm</code> コマンドは、この作業を行い、そして作業ディレクトリからファイルを削除します。つまり、追跡されていないファイルとして残り続けることはありません。</p> | |
| -<p>単に作業ディレクトリからファイルを削除しただけの場合は、<code>git status</code> の出力の中では “Changes not staged for commit” (つまり <em>ステージされていない</em>) 欄に表示されます。</p> | |
| +<p>単に作業ディレクトリからファイルを削除しただけの場合は、<code>git status</code> の出力の中では “Changes not staged for commit” (つまり _ステージされていない_) 欄に表示されます。</p> | |
| <pre><code>$ rm grit.gemspec | |
| $ git status | |
| @@ -907,7 +907,7 @@ The lines must be formatted as follows | |
| %s 件名 | |
| </code></pre> | |
| -<p><em>author</em> と <em>committer</em> は何が違うのか気になる方もいるでしょう。<em>author</em> とはその作業をもともと行った人、<em>committer</em> とはその作業を適用した人のことを指します。あなたがとあるプロジェクトにパッチを送り、コアメンバーのだれかがそのパッチを適用したとしましょう。この場合、両方がクレジットされます (あなたが author、コアメンバーが committer です)。この区別については <em>第 5 章</em> でもう少し詳しく説明します。</p> | |
| +<p><em>author</em> と <em>committer</em> は何が違うのか気になる方もいるでしょう。<em>author</em> とはその作業をもともと行った人、<em>committer</em> とはその作業を適用した人のことを指します。あなたがとあるプロジェクトにパッチを送り、コアメンバーのだれかがそのパッチを適用したとしましょう。この場合、両方がクレジットされます (あなたが author、コアメンバーが committer です)。この区別については *第 5 章* でもう少し詳しく説明します。</p> | |
| <p>oneline オプションおよび format オプションは、<code>log</code> のもうひとつのオプションである <code>--graph</code> と組み合わせるとさらに便利です。このオプションは、ちょっといい感じのアスキーグラフでブランチやマージの歴史を表示します。Grit プロジェクトのリポジトリならこのようになります。</p> | |
| @@ -1085,7 +1085,7 @@ $ git status | |
| <p>変更が取り消されたことがわかります。また、これが危険なコマンドであることも知っておかねばなりません。あなたがファイルに加えた変更はすべて消えてしまいます。変更した内容を、別のファイルで上書きしたのと同じことになります。そのファイルが不要であることが確実にわかっているとき以外は、このコマンドを使わないようにしましょう。単にファイルを片付けたいだけなら、次の章で説明する stash やブランチを調べてみましょう。一般にこちらのほうがおすすめの方法です。</p> | |
| -<p>Git にコミットした内容のすべては、ほぼ常に取り消しが可能であることを覚えておきましょう。削除したブランチへのコミットや <code>--amend</code> コミットで上書きされた元のコミットでさえも復旧することができます (データの復元方法については <em>第 9 章</em> を参照ください)。しかし、まだコミットしていない内容を失ってしまうと、それは二度と取り戻せません。</p> | |
| +<p>Git にコミットした内容のすべては、ほぼ常に取り消しが可能であることを覚えておきましょう。削除したブランチへのコミットや <code>--amend</code> コミットで上書きされた元のコミットでさえも復旧することができます (データの復元方法については *第 9 章* を参照ください)。しかし、まだコミットしていない内容を失ってしまうと、それは二度と取り戻せません。</p> | |
| <h2>リモートでの作業</h2> | |
| @@ -1125,7 +1125,7 @@ koke git://github.com/koke/grit.git | |
| origin git@github.com:mojombo/grit.git | |
| </code></pre> | |
| -<p>つまり、これらのユーザーによる変更を容易にプルして取り込めるということです。ここで、origin リモートだけが SSH の URL であることに注目しましょう。私がプッシュできるのは origin だけだということになります (なぜそうなるのかについては <em>第 4 章</em> で説明します)。</p> | |
| +<p>つまり、これらのユーザーによる変更を容易にプルして取り込めるということです。ここで、origin リモートだけが SSH の URL であることに注目しましょう。私がプッシュできるのは origin だけだということになります (なぜそうなるのかについては *第 4 章* で説明します)。</p> | |
| <h3>リモートリポジトリの追加</h3> | |
| @@ -1160,11 +1160,11 @@ From git://github.com/paulboone/ticgit | |
| <pre><code>$ git fetch [remote-name] | |
| </code></pre> | |
| -<p>このコマンドは、リモートプロジェクトのすべてのデータの中からまだあなたが持っていないものを引き出します。実行後は、リモートにあるすべてのブランチを参照できるようになり、いつでもそれをマージしたり中身を調べたりすることが可能となります (ブランチとは何なのか、どのように使うのかについては、<em>第 3 章</em> でより詳しく説明します)。</p> | |
| +<p>このコマンドは、リモートプロジェクトのすべてのデータの中からまだあなたが持っていないものを引き出します。実行後は、リモートにあるすべてのブランチを参照できるようになり、いつでもそれをマージしたり中身を調べたりすることが可能となります (ブランチとは何なのか、どのように使うのかについては、*第 3 章* でより詳しく説明します)。</p> | |
| <p>リポジトリをクローンしたときには、リモートリポジトリに対して自動的に <em>origin</em> という名前がつけられます。つまり、<code>git fetch origin</code> とすると、クローンしたとき (あるいは直近でフェッチを実行したとき) 以降にサーバーにプッシュされた変更をすべて取得することができます。ひとつ注意すべき点は、<code>fetch</code> コマンドはデータをローカルリポジトリに引き出すだけだということです。ローカルの環境にマージされたり作業中の内容を書き換えたりすることはありません。したがって、必要に応じて自分でマージをする必要があります。</p> | |
| -<p>リモートブランチを追跡するためのブランチを作成すれば (次のセクションと <em>第 3 章</em> で詳しく説明します)、<code>git pull</code> コマンドを使うことができます。これは、自動的にフェッチを行い、リモートブランチの内容を現在のブランチにマージします。おそらくこのほうが、よりお手軽で使いやすいことでしょう。またデフォルトで、<code>git clone</code> コマンドはローカルの master ブランチが (取得元サーバー上の) リモートの master ブランチを追跡するよう自動設定します (リモートに master ブランチが存在することを前提としています)。<code>git pull</code> を実行すると、通常は最初にクローンしたサーバーからデータを取得し、現在作業中のコードへのマージを試みます。</p> | |
| +<p>リモートブランチを追跡するためのブランチを作成すれば (次のセクションと *第 3 章* で詳しく説明します)、<code>git pull</code> コマンドを使うことができます。これは、自動的にフェッチを行い、リモートブランチの内容を現在のブランチにマージします。おそらくこのほうが、よりお手軽で使いやすいことでしょう。またデフォルトで、<code>git clone</code> コマンドはローカルの master ブランチが (取得元サーバー上の) リモートの master ブランチを追跡するよう自動設定します (リモートに master ブランチが存在することを前提としています)。<code>git pull</code> を実行すると、通常は最初にクローンしたサーバーからデータを取得し、現在作業中のコードへのマージを試みます。</p> | |
| <h3>リモートへのプッシュ</h3> | |
| @@ -1173,7 +1173,7 @@ From git://github.com/paulboone/ticgit | |
| <pre><code>$ git push origin master | |
| </code></pre> | |
| -<p>このコマンドが動作するのは、自分が書き込みアクセス権を持つサーバーからクローンし、かつその後だれもそのサーバーにプッシュしていない場合のみです。あなた以外の誰かが同じサーバーからクローンし、誰かが上流にプッシュした後で自分がプッシュしようとすると、それは拒否されます。拒否された場合は、まず誰かがプッシュした作業内容を引き出してきてローカル環境で調整してからでないとプッシュできません。リモートサーバーへのプッシュ方法の詳細については <em>第 3 章</em> を参照ください。</p> | |
| +<p>このコマンドが動作するのは、自分が書き込みアクセス権を持つサーバーからクローンし、かつその後だれもそのサーバーにプッシュしていない場合のみです。あなた以外の誰かが同じサーバーからクローンし、誰かが上流にプッシュした後で自分がプッシュしようとすると、それは拒否されます。拒否された場合は、まず誰かがプッシュした作業内容を引き出してきてローカル環境で調整してからでないとプッシュできません。リモートサーバーへのプッシュ方法の詳細については *第 3 章* を参照ください。</p> | |
| <h3>リモートの調査</h3> | |
| @@ -1993,7 +1993,7 @@ Switched to a new branch "serverfix" | |
| <h3>追跡ブランチ</h3> | |
| -<p>リモートブランチからローカルブランチにチェックアウトすると、<em>追跡ブランチ (tracking branch)</em> というブランチが自動的に作成されます。追跡ブランチとは、リモートブランチと直接のつながりを持つローカルブランチのことです。追跡ブランチ上で <code>git push</code> を実行すると、Git は自動的にプッシュ先のサーバーとブランチを判断します。また、追跡ブランチ上で <code>git pull</code> を実行すると、リモートの参照先からすべてのデータを取得し、対応するリモートブランチの内容を自動的にマージします。</p> | |
| +<p>リモートブランチからローカルブランチにチェックアウトすると、_追跡ブランチ (tracking branch)_ というブランチが自動的に作成されます。追跡ブランチとは、リモートブランチと直接のつながりを持つローカルブランチのことです。追跡ブランチ上で <code>git push</code> を実行すると、Git は自動的にプッシュ先のサーバーとブランチを判断します。また、追跡ブランチ上で <code>git pull</code> を実行すると、リモートの参照先からすべてのデータを取得し、対応するリモートブランチの内容を自動的にマージします。</p> | |
| <p>あるリポジトリをクローンしたら、自動的に <code>master</code> ブランチを作成し、<code>origin/master</code> を追跡するようになります。これが、<code>git push</code> や <code>git pull</code> が引数なしでもうまく動作する理由です。しかし、必要に応じてそれ以外の追跡ブランチを作成し、<code>origin</code> 以外にあるブランチや <code>master</code> 以外のブランチを追跡させることも可能です。シンプルな方法としては、<code>git checkout -b [branch] [remotename]/[branch]</code> を実行します。Git バージョン 1.6.2 以降では、より簡単に <code>--track</code> を使うことができます。</p> | |
| @@ -2036,7 +2036,7 @@ To git@github.com:schacon/simplegit.git | |
| <p><img src="figures/3.28.png" title="3.28 分岐した作業履歴をひとつに統合する" alt="3.28 分岐した作業履歴をひとつに統合する" /></p> | |
| -<p>しかし、別の方法もあります。C3 で行った変更のパッチを取得し、それを C4 の先端に適用するのです。Git では、この作業のことを <em>リベース (rebasing)</em> と呼んでいます。<code>rebase</code> コマンドを使用すると、一方のブランチにコミットされたすべての変更をもう一方のブランチで再現することができます。</p> | |
| +<p>しかし、別の方法もあります。C3 で行った変更のパッチを取得し、それを C4 の先端に適用するのです。Git では、この作業のことを _リベース (rebasing)_ と呼んでいます。<code>rebase</code> コマンドを使用すると、一方のブランチにコミットされたすべての変更をもう一方のブランチで再現することができます。</p> | |
| <p>今回の例では、次のように実行します。</p> | |
| @@ -2147,7 +2147,7 @@ $ git branch -d server | |
| <p>自前でサーバーを立てることには興味がないという人は、この章は最後のセクションまで読み飛ばし、ホスティングサービスに関する情報だけを読めばよいでしょう。そして次の章に進み、分散ソース管理環境での作業について学びます。</p> | |
| -<p>リモートリポジトリは、一般的に <em>ベアリポジトリ</em> となります。これは、作業ディレクトリをもたない Git リポジトリのことです。このリポジトリは共同作業の中継地点としてのみ用いられるので、ディスク上にスナップショットをチェックアウトする必要はありません。単に Git のデータがあればそれでよいのです。端的に言うと、ベアリポジトリとはそのプロジェクトの <code>.git</code> ディレクトリだけで構成されるもののことです。</p> | |
| +<p>リモートリポジトリは、一般的に _ベアリポジトリ_ となります。これは、作業ディレクトリをもたない Git リポジトリのことです。このリポジトリは共同作業の中継地点としてのみ用いられるので、ディスク上にスナップショットをチェックアウトする必要はありません。単に Git のデータがあればそれでよいのです。端的に言うと、ベアリポジトリとはそのプロジェクトの <code>.git</code> ディレクトリだけで構成されるもののことです。</p> | |
| <h2>プロトコル</h2> | |
| @@ -2256,7 +2256,7 @@ $ chmod a+x hooks/post-update | |
| <h4>欠点</h4> | |
| -<p>HTTP によるリポジトリの提供の問題点は、クライアント側から見て非効率的だということです。リポジトリのフェッチやクローンには非常に時間がかかります。また、他のネットワークプロトコルにくらべてネットワークのオーバーヘッドや転送量が非常に増加します。必要なデータだけをやりとりするといった賢い機能はない (サーバー側で転送時になんらかの作業をすることができない) ので、HTTP はよく <em>ダム (dumb)</em> プロトコルなどと呼ばれています。HTTP とその他のプロトコルの間の効率の違いに関する詳細な情報は、第 9 章を参照ください。</p> | |
| +<p>HTTP によるリポジトリの提供の問題点は、クライアント側から見て非効率的だということです。リポジトリのフェッチやクローンには非常に時間がかかります。また、他のネットワークプロトコルにくらべてネットワークのオーバーヘッドや転送量が非常に増加します。必要なデータだけをやりとりするといった賢い機能はない (サーバー側で転送時になんらかの作業をすることができない) ので、HTTP はよく _ダム (dumb)_ プロトコルなどと呼ばれています。HTTP とその他のプロトコルの間の効率の違いに関する詳細な情報は、第 9 章を参照ください。</p> | |
| <h2>サーバー用の Git の取得</h2> | |
| @@ -2298,7 +2298,7 @@ $ git init --bare --shared | |
| <p>複数名が使用する Git サーバーをたったこれだけの作業で用意できるというのは特筆すべきことです。サーバー SSH アクセス可能なアカウントを作成し、ベアリポジトリをサーバーのどこかに置き、そこに読み書き可能なアクセス権を設定する。これで準備OK。他には何もいりません。</p> | |
| -<p>次のいくつかのセクションでは、より洗練された環境を作るための方法を説明します。いちいちユーザーごとにアカウントを作らなくて済む方法、一般向けにリポジトリへの読み込みアクセスを開放する方法、ウェブ UI の設定、Gitosis の使い方などです。しかし、数名のメンバーで閉じたプロジェクトでの作業なら、SSH サーバーとベアリポジトリ <em>さえ</em> あれば十分なことは覚えておきましょう。</p> | |
| +<p>次のいくつかのセクションでは、より洗練された環境を作るための方法を説明します。いちいちユーザーごとにアカウントを作らなくて済む方法、一般向けにリポジトリへの読み込みアクセスを開放する方法、ウェブ UI の設定、Gitosis の使い方などです。しかし、数名のメンバーで閉じたプロジェクトでの作業なら、SSH サーバーとベアリポジトリ _さえ_ あれば十分なことは覚えておきましょう。</p> | |
| <h3>ちょっとしたセットアップ</h3> | |
| @@ -2747,7 +2747,7 @@ repo testing | |
| <p>Gitolite の設定ファイルの構文はドキュメントに詳しく書かれているので、ここでは大事なところに絞って説明します。</p> | |
| -<p>ユーザやリポジトリをグループにまとめることもできます。グループ名は単なるマクロのようなものです。グループを定義する際には、それがユーザであるかプロジェクトであるかは無関係です。実際にその「マクロ」を <em>使う</em> 段階になって初めてそれらを区別することになります。</p> | |
| +<p>ユーザやリポジトリをグループにまとめることもできます。グループ名は単なるマクロのようなものです。グループを定義する際には、それがユーザであるかプロジェクトであるかは無関係です。実際にその「マクロ」を *使う* 段階になって初めてそれらを区別することになります。</p> | |
| <pre><code>@oss_repos = linux perl rakudo git gitolite | |
| @secret_repos = fenestra pear | |
| @@ -2781,7 +2781,7 @@ repo testing | |
| <p>で、実際のアクセス制御ルールはどのように書けばいいの? と思われたことでしょう。簡単に説明します。</p> | |
| -<p>Gitolite のアクセス制御には二段階のレベルがあります。まず最初はリポジトリレベルのアクセス制御です。あるリポジトリへの読み込み (書き込み) アクセス権を持っているということは、そのリポジトリの <em>すべての</em> ref に対する読み込み (書き込み) 権限を持っていることを意味します。Gitosisにはこのレベルのアクセス制御しかありませんでした｡</p> | |
| +<p>Gitolite のアクセス制御には二段階のレベルがあります。まず最初はリポジトリレベルのアクセス制御です。あるリポジトリへの読み込み (書き込み) アクセス権を持っているということは、そのリポジトリの *すべての* ref に対する読み込み (書き込み) 権限を持っていることを意味します。Gitosisにはこのレベルのアクセス制御しかありませんでした｡</p> | |
| <p>もうひとつのレベルは "書き込み" アクセス権だけを制御するものですが、リポジトリ内のブランチやタグ単位で設定できます。ユーザ名、試みられるアクセス (<code>W</code> あるいは <code>+</code>)、そして更新される refname が既知となります。アクセスルールのチェックは、設定ファイルに書かれている順に行われ、この組み合わせにマッチ (単なる文字列マッチではなく正規表現によるマッチであることに注意しましょう) するものを探していきます。マッチするものが見つかったら、プッシュが成功します。マッチしなかった場合は、アクセスが拒否されます。</p> | |
| @@ -2789,7 +2789,7 @@ repo testing | |
| <p>これまでに見てきた権限は <code>R</code>、<code>RW</code> あるいは <code>RW+</code> だけでした。しかし、Gitolite にはそれ以外の権限もあります。それが <code>-</code> で、"禁止" をあらわすものです。これを使えばより強力なアクセス制御ができるようになりますが、少し設定は複雑になります。マッチしなければアクセスを拒否するというだけでなく、ルールを書く順番もからんでくることになるからです。</p> | |
| -<p>上の例で、エンジニアは master と integ <em>以外</em> のすべてのブランチを巻き戻せるように設定しようとすると、次のようになります。</p> | |
| +<p>上の例で、エンジニアは master と integ *以外* のすべてのブランチを巻き戻せるように設定しようとすると、次のようになります。</p> | |
| <pre><code> RW master integ = @engineers | |
| - master integ = @engineers | |
| @@ -5128,7 +5128,7 @@ README rack | |
| <h2>サブツリーマージ</h2> | |
| -<p>サブモジュールの仕組みに関する問題を見てきました。今度は同じ問題を解決するための別の方法を見ていきましょう。Git でマージを行うときには、何をマージしなければならないのかを Git がまず調べてそれに応じた適切なマージ手法を選択します。ふたつのブランチをマージするときに Git が使うのは、<em>再帰 (recursive)</em> 戦略です。三つ以上のブランチをマージするときには、Git は <em>たこ足 (octopus)</em> 戦略を選択します。どちらの戦略を使うかは、Git が自動的に選択します。再帰戦略は複雑な三方向のマージ (共通の先祖が複数あるなど) もこなせますが、ふたつのブランチしか処理できないからです。たこ足マージは三つ以上のブランチを扱うことができますが、難しいコンフリクトを避けるためにより慎重になります。そこで、三つ以上のブランチをマージするときのデフォルトの戦略として選ばれています。しかし、それ以外にも選べる戦略があります。そのひとつが <em>サブツリー (subtree)</em> マージで、これを使えば先ほどのサブプロジェクト問題に対応することができます。先ほどのセクションと同じような rack の取り込みを、サブツリーマージを用いて行う方法を紹介しましょう。</p> | |
| +<p>サブモジュールの仕組みに関する問題を見てきました。今度は同じ問題を解決するための別の方法を見ていきましょう。Git でマージを行うときには、何をマージしなければならないのかを Git がまず調べてそれに応じた適切なマージ手法を選択します。ふたつのブランチをマージするときに Git が使うのは、_再帰 (recursive)<em> 戦略です。三つ以上のブランチをマージするときには、Git は _たこ足 (octopus)</em> 戦略を選択します。どちらの戦略を使うかは、Git が自動的に選択します。再帰戦略は複雑な三方向のマージ (共通の先祖が複数あるなど) もこなせますが、ふたつのブランチしか処理できないからです。たこ足マージは三つ以上のブランチを扱うことができますが、難しいコンフリクトを避けるためにより慎重になります。そこで、三つ以上のブランチをマージするときのデフォルトの戦略として選ばれています。しかし、それ以外にも選べる戦略があります。そのひとつが _サブツリー (subtree)_ マージで、これを使えば先ほどのサブプロジェクト問題に対応することができます。先ほどのセクションと同じような rack の取り込みを、サブツリーマージを用いて行う方法を紹介しましょう。</p> | |
| <p>サブツリーマージの考え方は、ふたつのプロジェクトがあるときに一方のプロジェクトをもうひとつのプロジェクトのサブディレクトリに位置づけたりその逆を行ったりするというものです。サブツリーマージを指定すると、Git は一方が他方のサブツリーであることを理解して適切にマージを行います。驚くべきことです。</p> | |