レベル: 中級 William von Hagen, Systems Administrator, Writer, WordSmiths
2009年 8月 25日 アプリケーション、Web サイト、オペレーティング・システムのどれを作成する場合であれ、バージョン管理システムは大部分の開発プロジェクトのコア・コンポーネントです。ほとんどのプロジェクトには複数の開発者が関係し、また多くの場合、そうした人達は物理的に遠く離れた場所で作業を行います。分散型のバージョン管理システムは決して新しいものではありませんが、Git バージョン管理システムは開発者同士のやり取りや共同作業をサポートする独特の機能を持っています。
VCS (Version Control System: バージョン管理システム) はプロジェクト内の一連のファイルに変更を適用して管理するためのメカニズムであり、ソフトウェア、ドキュメント、その他のオンライン開発プロジェクトをチームで行う場合に一般的に使われています。開発プロジェクトにとって、VCS はシステムのバックアップと同じくらい重要です。VCS を使うことによって、複数のユーザーが同じファイル群またはプロジェクトに変更を加えることができ、1 人の開発者による変更が他の人による変更を誤って上書きしてしまう事態を防止することができるからです。
 | よく使われる頭字語
- CSS: Cascading Style Sheet
- GUI: Graphical User Interface
- HTML: HyperText Markup Language
- HTTP: HyperText Transfer Protocol
|
|
もし Linus Torvalds が Linux® オペレーティング・システムのカーネルを開発しなかったとしても、彼は Git VCS を作成したことで、今と同じくらい有名になっていたはずです。Linux のように複雑なプロジェクトは VCS に対する究極的なシステム・テストになります。そのため、Git が強力かつ柔軟で安定しているシステムへと急速に進化していったことは驚くに当たりません。
Linux システムと UNIX® システムは VCS と深く関係しており、VCS には RCS (Revision Control System) や CVS (Concurrent Versions System) といった非常に古いものから、最近のシステムである Subversion、Mercurial、Bazaar、Arch、Darcs に至るまで、非常にたくさんの種類があります。皮肉なことに (Linux の領域では特に皮肉なことに)、Git は BitKeeper という商用の VCS に置き換わるものとして開発されました。BitKeeper はユニークで強力な機能を持つと同時に、無料のバージョンもありました。BitKeeper は今でもなお強力ですが、ライセンス条件の変更から、やがて Torvalds は他の手段を探すようになりました。そして無料ソフトウェアの最高の伝統に従い、彼は結局、自分自身で作成することを決めたのです。Linux カーネルと同様、Git は今や、無数のオープンソース開発者による機能強化、バグ修正等々の貢献の産物となっています。
Git の魅力は、その強力さと、無料のソフトウェアであることによりコストの節約が可能であるという点にあり、多くのオープンソース・ソフトウェア・プロジェクト、学術機関、さまざまな組織などで急速に Git が採用されつつあります。いったん企業環境や学術環境に採用されると、VCS であると同時に共同作業のプラットフォームでもあるという Git のメリットから、従来の「ソース・コード」を作業対象とするプロジェクト以外にも、さまざまなプロジェクトで Git が採用されるようになっています。この記事で説明するように、Git は複雑な分散型の Web 開発プロジェクトで特に有用です。そうしたプロジェクトにはコンテンツに関する要件と開発に関する要件があり、さまざまな人々が最新情報に基づいてやり取りする必要があるからです。
単なる VCS を超える Git
Git は何千人もの開発者が作業を行う分散型の開発を支援するために設計されました。分散型の開発では、作業は多くの異なる場所に分散し、インターネット接続環境も異なりますが、それでもパフォーマンスやアクセス面で重大なボトルネックを生じてはなりません。Git にはこうした基本的な要件をサポートする上で重要となる以下の側面があります。
- 中央リポジトリーを使用しますが、プロジェクトの各開発者に対して、そのプロジェクトのソース・コードの完全なコピーを提供します。こうすることによって、すべての開発者は現在の接続性とは無関係に確実に作業を行うことができます。
- ソフトウェア・プロジェクトの中で、さまざまなワーキング・セット (ブランチと呼ばれます) の作成や、ワーキング・セットの間での変更の共有 (マージと呼ばれます) を高い信頼性のもと、迅速に行えます。ブランチによって、ソフトウェア・パッケージのさまざまなバージョンを容易にサポートすることができ、そうしたバージョンが永久的なものか実験的に作成されたものかを気にする必要はありません。マージは一般にソース・コード管理システムの重要な側面ですが、ブランチ指向の VCS ではとりわけ一般的な機能です。
- 作成途中のブランチやコード変更を一部の開発者の間で容易に共有することができ、そうした変更を最初から中央リポジトリーにチェックインする必要がありません。
こうした設計判断や、そうした判断の実際の実装が、Git の成功と使いやすさの重要な要素となっています。もちろん、Git は不変性やアカウンタビリティーなど、VCS に関する標準的な要件も満たしています。不変性というのは、いったん変更がリポジトリーにコミットされると、それらの変更はプロジェクトの履歴の一部として永久に残るという意味です。それらの変更は結果的に取り消し (リバートと呼ばれます) されるかもしれませんが、それらの変更自体と、それらの変更を取り消した置き換えコードは、プロジェクトの履歴の一部として永久に残ります。アカウンタビリティーというのは、ある特定の変更を誰が行ったのか、またその変更がいつ行われたのかを容易に判断できるという意味です。ある変更がなぜ行われたのかは、それでも謎かもしれませんが (ただし変更をコミットする場合には必ず何らかのコメントが要求されます)、少なくとも誰に尋ねればよいかを知ることができます。
Git はリポジトリーの中にあるファイルやディレクトリーの状態を、内部インデックスを使って追跡します。また Git は、後で容易に更新を行えるように、そうしたファイルやディレクトリーへの変更を反映するオブジェクトを保存します。Gix のインデックスと、これらのオブジェクトは、ローカル・リポジトリーの中にある実際のファイルやディレクトリーとは明確に区別されます。このモデルによって、ファイルやディレクトリーのうち、ローカルで変更されたものの、まだローカル・リポジトリーやリモートの中央リポジトリー (中央リポジトリーが存在する場合) にはコミットされていないものを、容易に識別することができます。Git コマンドのうち、一部はインデックスを操作し、それ以外のコマンドはファイルやディレクトリーの実際の内容を操作します。このことは、誤ったコマンドを使用してしまい、ファイルが更新されない理由がわからない場合、混乱の元になることがあります。
Git を入手する
ほとんどの Linux ディストリビューションには、パッケージ・リポジトリーの中に Git 用のパッケージが用意されています。.deb パッケージ・フォーマットを使用する Ubuntu や Debian などのシステムでは、git-core パッケージをインストールする必要があります。Fedora、Red Hat、Centos、SUSE、Mandriva など RPM ベースのシステムでは、メインの Git パッケージは単純に git と呼ばれます。基本的な Git パッケージの場合、Perl、暗号化とエラー処理のための Perl ライブラリー、そしてパッチ・ユーティリティーもシステムにインストールしておく必要があります。
Linux システム用の最新で最高のバージョンの Git が必要な場合のために、Git の Web サイトにはパッケージ済みの .deb パッケージと RPM パッケージへのリンクがあり、また (独自のバージョンをビルドしたい場合のために) Git の最新のソース・コードへのリンクもあります。また Git のサイトには、Mac® OS X、ネイティブの Windows®、Windows システムでのCygwin、Sun/Oracle Solaris® システムのための、コンパイル済みバージョンの Git へのリンクもあります。現状では、IBM® AIX® や Hewlett-Packard® HP-UX のシステム管理者は、自分達のプラットフォームに合わせてソース・コードから Git をビルドする必要があります。プラットフォームに合わせて Git を入手する方法やビルドする方法については「参考文献」を参照してください。
Git のメインのパッケージには、git の実行可能ファイルと、いくつかの補助的な Git アプリケーションが含まれています。ご想像のとおり、Git に関連するパッケージは他にも大量にあります。以下は最もよく使われる Git 関連パッケージの一例です。
- git-cola: Git リポジトリーの中にあるファイルやディレクトリーを扱うための GUI
- git-doc: Git のユーザー・マニュアル、チュートリアル、ドキュメントをローカルにインストールします。
- git-gui: Git リポジトリーをブラウズし、操作するための GUI (gitk パッケージを使います)
- git-web: Git リポジトリーに対する Web ベースのグラフィカル・インターフェース
- gitk: Git リポジトリーをブラウズし、操作するための単純な GUI
- qgit: Git リポジトリーを表示し、利用するための、Qt ベースのグラフィカル・アプリケーション
git-gui パッケージ、git-web パッケージ、gitk パッケージ、qgit パッケージは同じような機能を持ち、git-web が Web ベースである以外はどれもローカルで実行されます。これらのパッケージはどれも Git を使って作業を始める際には有用ですが、分散環境ではおそらく git-web パッケージが最適な選択肢です。
Git を試してみたいものの、既に別の VCS を使うことが決まっている場合には、以下のパッケージが役立ちます。
- git-cvs: このパッケージによって、Git のリポジトリーと CVS のリポジトリーとを相互運用することができます。例えば CVS のリポジトリーと変更履歴を Git にインポートして Git で作業を行い、変更をマージして CVS のリポジトリーに戻し、CVS のリポジトリーから更新をインポートすることができます。
- git-svn: このパッケージによって、Git のリポジトリーと Subversion のリポジトリーとを相互運用することができます。例えば Subversion のリポジトリーと変更履歴を Git にインポートして Git で作業を行い、変更をマージして Subversion のリポジトリーに戻し、Subversion のリポジトリーから更新をインポートすることができます。
Git の一般的なコマンド
Git は、いわゆるコマンド・スイートです。つまり基本的なコマンドとして git を使用し、コマンドラインの最初の引数は実行すべき特定の Git コマンドを示します。
| Git の仲間
古いバージョンの Git では、Git コマンドに似た多くのコマンドも git-command (command は特定の Git コマンド) の形式でインストールされていました。そのため、例えば git push または git-push などの形式で Git コマンドを実行することができました。この機能は、多くの補助的な Git コマンドが精力的に開発されていた初期の Git には便利でした。こうすることで、メインの Git バイナリーに含まれる Git コマンドや、まだ外部コマンドであった Git コマンドに対するコマンド構文を実現できたからです。しかし今や Git は成熟したため、これらは必要なくなりました。
|
|
一般的な Git コマンドの一覧は、何も引数を付けずに git コマンドを実行することで、いつでも見ることができます。コマンド・リストの一部を以下に挙げます。
add: Git のインデックスに新しいファイルを追加します。このファイルの内容を Git リポジトリーに実際に追加するためには、やはりこのファイルをコミットする必要があります。branch: このコマンドを使うと、チェックアウトしたブランチを一覧表示したり、現在作業中のブランチを特定したり、新しいブランチを作成したり、あるいは作成またはチェックアウトしたブランチのローカル・コピーを削除したりすることができます。このコマンドを使って他のブランチに切り換えることはできません。ブランチを切り換えるためには Git の checkout コマンドを使います。checkout: 指定されたブランチまたはファイルやディレクトリーをチェックアウトします。ブランチをチェックアウトすると、そのブランチがワーキング・ブランチになります。ある特定のファイルまたはディレクトリーを指定すると、そのファイルまたはディレクトリーは、現在作業中のブランチのリポジトリーにチェックインされている現行のバージョンと一致するように更新されます。またこのコマンドを使うことで、指定された既存のブランチをベースとする新しいブランチを作成することもでき、指定の既存ブランチへの変更追跡機能を、この新しいブランチにオプションとして持たせることもできます。commit: ファイルやディレクトリーへの変更を Git のインデックスに記録します。変更のコミットが必要なファイルやディレクトリーを指定することも、Git が追跡しているファイルに対して処理中のすべての変更を -a オプションを使用して追加することも、あるいは --interactive オプションを使用して、一緒にコミットする必要のあるファイルやディレクトリーの変更を選択することもできます。(この最後のケースは、大量のファイルが関係するいくつかの異なるタスクを処理している場合で特定の変更群を一緒にコミットしたい場合に、特に便利です。コミットはローカル・リポジトリーに対して行われます。リモートの中央リポジトリーを使用している場合には、やはり Git の push コマンドを使ってローカルの変更をリモートのリポジトリーにプッシュする必要があります。)diff: ローカル・ファイルと他のコミットとの間の違い、あるいは 2 つの異なるコミットの間の違いを表示します。このコマンドの最も一般的な使い方として、単純にファイル名を指定します。すると、指定されたファイルと、そのファイルを現在のブランチのリポジトリーにコミットしたバージョンとの違いが表示されます。fetch: 別のリポジトリーからインデックスの更新を取得します。更新を取得することによって、作成された新しいタグを識別したり、そのリポジトリーにコミットされたファイルまたはディレクトリーの変更のうち、まだローカルには存在していないものに関する情報を得たりすることができます。すると、その別のリポジトリーにコミットされたファイルまたはディレクトリーの変更を git log コマンドを使って検証することができます。fetch の後、関連するファイルの変更を実際に取得するためには、git pull コマンドまたは git rebase コマンドを使います。grep: 現在のブランチのファイル群の中で、あるパターンに一致するものを検索して表示します。このコマンドでは、おなじみの GNU grep のオプションの大部分を使用することができます。log: 現在のブランチに対する、または現在のブランチの中にある指定されたファイルに対する、コミットのログ情報を表示します。merge: 1 つのブランチから別のブランチへ変更をマージします。このコマンドには、マージされた変更を自動的にコミットできるかどうかを判断できるオプションがあるため、そうした変更を実際に受け入れる前に、マージによる影響を調べることができます。mv: Git が現在追跡中のファイル、ディレクトリー、あるいはシンボリック・リンクをリネームします。pull: 別のリポジトリーからインデックスの更新を取得し、それらの更新を現在のブランチのファイルやディレクトリーにマージします。push: ローカルのインデックスとオブジェクトの変更情報によってリモート・リポジトリーを更新します。rebase: 現在のブランチを更新してリモートのブランチと一致させ、まだリモート・ブランチにプッシュされていないローカル・コミットをすべて変更します。こうすることで、そのリモート・ブランチの現在の状態にローカル・コミットを適用することができます。これは強力なコマンドですが、危険性もあるコマンドです。必要に応じて文字通りコミットを作り直し、マージさせてしまうことができるからです。リモート・リポジトリーに対する変更の頻度と範囲にもよりますが、単純に git pull コマンドを使う方が魅力的な選択肢であることが多いものです。rm: Git が現在追跡中のファイル、ディレクトリー、あるいはシンボリック・リンクを削除します。stash: 現在の変更を一時的にスタックにプッシュし、現在のチェックアウトを「何も手を加えていない」状態に戻します。git stash save コマンドは現在の変更をローカル・スタックに保存し、一方 git stash apply はローカル・スタックに保存された変更を再度取得して再度適用します。これは、進行中の変更を永久的にコミットせずにリモートの変更を取得したい場合、あるいは rebase を行いたい場合に便利です。status: 現在のブランチの状態を表示し、まだコミットされていない変更、追跡されていないファイル、等々を特定します。
すべての Git コマンドは --help オプションを受け付けます。--help オプションは、これらのコマンドのいずれかに関する詳細な情報が必要な場合や、それぞれのコマンドが受け付けるコマンドライン・オプションを表示したい場合に非常に便利です。また git help command という形式でコマンドを実行すると、任意の Git コマンドのヘルプを表示することもできます。
Git コマンドの完全なリストが必要な場合には、man git コマンドを実行すると Git のオンライン・リファレンス情報が表示されます。
新しい Git プロジェクトをセットアップする
どのバージョン管理システムも使用していない既存のプロジェクトで Git を使い始めるためには、以下のステップを実行します。
- そのプロジェクトのソース・コードを含むディレクトリーにカレント・ディレクトリーを変更します。
$ cd www.move2linux.com
$ ls
greenbar_wide.gif images index.html legacy.html services.html
|
git init コマンドを使ってカレント・ディレクトリーに空のリポジトリーを作成します。
$ git init
Initialized empty Git repository in .git/
|
- オプションとして、
git status コマンドを使って新しいプロジェクトの状態をチェックします。
このコマンドによって、カレント・ディレクトリーの中にあるすべてのファイルとディレクトリーが untracked として表示されます。これは、Git はそれらの存在を認識しており、ただしファイルを追跡するよう指示をまだ受けていないことを意味します。
$ git status
# On branch master
#
# Initial commit
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# greenbar_wide.gif
# images/
# index.html
# legacy.html
# services.html
nothing added to commit but untracked files present...
|
- そのプロジェクトのファイルとディレクトリーを新しい Git リポジトリーに追加します。
ファイルやディレクトリーを明示的に指定することも、あるいは下記のように、「カレント・ディレクトリーの内容」を意味する昔ながらのショートカットである、ピリオド (.) を使うこともできます。
git status コマンドを再度実行し、カレント・ディレクトリーの中にあるすべてのファイルとすべてのサブディレクトリーが新しいプロジェクトに追加されたことを確認します。
$ git status
# On branch master
#
# Initial commit
#
# Changes to be committed:
# (use "git rm --cached <file>..." to unstage)
#
# new file: greenbar_wide.gif
# new file: images/digits/b/0.gif
# new file: images/digits/b/1.gif
# new file: images/digits/b/4.gif
# new file: images/digits/b/5.gif
# new file: images/digits/b/6.gif
# new file: images/digits/b/7.gif
# new file: images/digits/b/8.gif
# new file: images/digits/b/9.gif
# new file: index.html
# new file: legacy.html
# new file: services.html
#
|
git commit コマンドを実行し、初期ファイルをチェックインします。
コマンドラインで -m "<コミット・メッセージ>" オプションを使ってコミット・メッセージを指定した場合を除き、このコマンドによってデフォルトのエディターが起動します。このエディターに、コミットと関連付けるコメントを入力します。コメントを保存してエディターを終了すると、Git はこの変更に関連付けられたファイルをチェックインし、そのコミットと関連ファイルの情報を表示します。
$ git commit
Created initial commit dfbd6cc: Initial checkin
12 files changed, 285 insertions(+), 0 deletions(-)
...
|
これで上記のコマンドを使うための準備は終わり、Git を使ってプロジェクトのファイルを扱うことができます。
| 中央リポジトリーをセットアップする
このセクションで説明したリポジトリーを作成するためには、この同じリポジトリーで作業を行っている他のユーザーによる変更をプルするか、1 人のユーザーのブランチに他のユーザー達が変更をプッシュした後でそのブランチをチェックアウトする必要があります。「Git を利用した分散型の Web 開発」セクションには、中央リポジトリーのセットアップ方法として、すべてのファイルの作業コピーのホストはしない方法 (従ってこの問題のない方法) を説明してあります。
|
|
既存の Git プロジェクトを変更する
誰か他の人が既に作成した Git プロジェクトに独自の変更を加えたい場合には、作業はさらに簡単です。単純に git clone コマンドを使用して、その Git プロジェクトの作業コピーを作成します。
$ git clone /home/jake/src/maps
|
この例では、カレント作業ディレクトリーに Git maps プロジェクトのコピーを作成します。次にディレクトリーを maps プロジェクトのコピーに変更し、このプロジェクトのファイルに対する作業を先ほど説明したコマンドを使って Git の中で開始します。
Git プロジェクトを複製する
別のマシン上にある Git プロジェクトの複製も同じくらい簡単です。Git はセキュア・シェル (SSH) プロトコルと HTTP プロトコルをデフォルトでサポートしている一方で、(Git デーモンがリモート・システムで実行されており、対象のプロジェクトをエクスポートする場合には) Git 独自の非常に効率的な git プロトコルを使うこともできます。Git はデフォルトで SSH を使用するため、SSH を使ってリポジトリーを複製するための構文は、ご想像のとおり以下のようになります。
$ git clone remote-machine:/home/jake/src/maps
$ git clone ssh://remote-machine/home/jake/src/maps
|
注意: SSH を利用して Git プロジェクトを複製するためには、リモート・システムにアクセスできる権限が必要です。この点から、git プロトコルを使うことには十分意味があります (ただしそのためには Git デーモンを実行する必要があります)。
Git を利用した分散型の Web 開発
上記で作成したようなリポジトリーには、Git プロジェクトのすべてのファイルの作業コピーと、Git が変更やブランチ、タグ等々を追跡するために必要な、すべてのファイルが含まれています。デフォルトで、プロジェクトのファイルの作業コピーを含む Git リポジトリーにプッシュしても、そのプロジェクトのインデックスが更新されるだけであり、そのプロジェクトの実際のファイルが更新されるわけではありません。これは、ファイル自体を更新しようとすると、同じファイルに対して同時に作業を行っている場合にマージの競合が起こる可能性があるためです。
プッシュ先となる Git プロジェクトを作成するためには、ベア・リポジトリーと呼ばれるものを作成する必要があります。ベア・リポジトリーというのは、ファイルの作業コピーは含まず、ただし Git のインデックスや、そのインデックスへの更新を反映したオブジェクト、その他 Git が必要とするファイルを含むリポジトリーです。ベア・リポジトリーはファイルの作業コピーを含まないため、実際の作業の対象ではなく、このリポジトリーに含まれるプロジェクトで作業を行う開発者全員のための集合ポイントとして機能します。
以下のステップを実行して Web サーバー上に Git リポジトリーを作成します。このリポジトリーは Web サイトのコンテンツを含み、開発者はこのリポジトリーに対してプッシュします。この手順によって、既存の Web コンテンツのディレクトリーは、新しい Git リポジトリーをチェックアウトしたバージョンを含むディレクトリーで置き換えられます。このディレクトリーは、その共有 Git リポジトリーにファイルがプッシュされるごとに自動的に更新されます。これを実現する方法はたくさんあります。ここで説明する例は理解しやすいように設計してあり、従って Web サイトの HTML コンテンツしか扱いません。この説明と同じ原則に従えば、Web サイトの任意の部分の作業を行うことができます。
- Web サーバー上で SSH を使用し、Web コンテンツを含むディレクトリーに変更します。
まだその Web コンテンツを Git が追跡していない場合には、この前のセクションで説明した手順に従って、そのディレクトリーに Git リポジトリーをセットアップします。例えば次のようにします。
$ ssh somehost
$ cd /var/www/html
$ git init
$ git add .
$ git commit -m "Initial commit"
|
- カレント・ディレクトリーを 1 つ上のディレクトリーに変更し、上記で Web コンテンツ用に作成したプロジェクトを複製して Git ベア・リポジトリーを作成します。
$ cd ..
$ git clone --bare html html.git
|
適切な習慣として、ベア・リポジトリーを作成する際には .git 拡張子を付け、gitweb などのツールで表示できるようにします (gitweb で表示するためには .git 拡張子が付いている必要があります)。
- 既存の Web ディレクトリーをリネームします。そしてベア・リポジトリーを複製することで、そのリネームした名前と同じ名前で新しい Git プロジェクトを作成します。
$ mv html html.OLD && git clone html.git html
|
新しいプロジェクトのディレクトリーには、Git プロジェクト内のすべてのファイルをチェックアウトしたものが含まれており、それらは Web サーバーのコンテンツに対応しています。
- ベア・リポジトリーの hooks サブディレクトリーの中で、post-update スクリプトを編集 (または作成) します。このスクリプトによって、Web コンテンツをチェックアウトしたファイルを含む新しいプロジェクト・ディレクトリーに変更がプッシュされます。
このスクリプトは、ベア・リポジトリーによって追跡されているファイルのどれかが更新されるたびに実行されます。このスクリプトが実行可能であることを確認します。
$ pushd html.git/hooks
$ emacs post-update
$ chmod 755 post-update
|
この post-update スクリプトはリスト 1 のようなものになるはずです。
リスト 1. post-update スクリプト
#!/bin/bash
#
WEB_DIR="/var/www/html"
export GIT_DIR="$WEB_DIR/.git"
pushd $WEB_DIR > /dev/null
git pull
popd > /dev/null
|
シェルの組み込みコマンド pushd と popd を使えるように、このスクリプトではインタープリターとして /bin/bash を使う必要があることに注意してください。post-update ファイルが既に存在している場合には、インタープリターを検証した後、このスクリプトの残り部分をそのファイルに単純に追加します。また、既存の post-update スクリプトの中にある既存のどのコマンドも、exec コマンドよりも前にあることも確認する必要があります。exec コマンドの方が前にあると、ファイルの中で exec コマンドよりも後にある行が実行されてしまいます。
この時点で、任意の開発者が Web サーバー上にベア・リポジトリーを複製して Web サイトに関する作業を開始することができます。そうすると、Web サイトを構成するファイル群に対して誰もが一緒に作業を行えるようになります。そうした作業には以下のようなものがあります。
- Web サイトからチェックアウトしたファイルに対して作業を行い、それらのファイルを共有の中央リポジトリーに直接プッシュする。
- Web サイトからチェックアウトしたファイルに対して作業を行い、コミットされた変更を 1 人の作業者のチェックアウトからプルして別の作業者のチェックアウトに入れる。こうすることによって、ファイル群に対して共同で作業を行うことができ、その後、そうしたファイル群を共有の中央リポジトリー (つまり Web サイト) にプッシュすることができます。
Git は大部分の VCS よりもはるかに高速ですが、大規模で複雑な使用頻度の非常に高いサイトに対して作業を行う場合には、その Web サイトのディレクトリーの中で直接作業することは現実的ではないかもしれません。例えばサイトの訪問者が一部のファイルの更新を誤って受信してしまい、その時にはまだ他のファイルが更新されていないかもしれません。これが特に問題になるのは、CSS の更新が受信される前に、その CSS を使用する更新ページがロードされてしまう場合です。この問題が起きるのを防ぐためによく使われる方法として、Web サーバーのシンボリック・リンクが実際のコンテンツ・ディレクトリーを指すようにし、更新されたコンテンツを公開する段階でシンボリック・リンクを切り換える方法や、Web サーバーの構成ファイルを変更して別のディレクトリーを指すようにし、コンテンツを公開する段階で Web サーバーをグレースフル・リスタートさせる方法などがあります。
まとめ
Git は強力で柔軟な VCS であり、共同作業のための多くの機能を備えています。これは Git が分散型で使用されることを想定して設計されているためです。Git によって、例えば Web サイトや Web ベースのアプリケーションなどを共有環境で開発するなど、さまざまな新しい方法で共同作業による開発を行えるようになります。また、時間をかけて Git の内部動作を理解し、よく使用する Git コマンドのサブセットを学ぶことには大きな価値があります。
参考文献 学ぶために
製品や技術を入手するために
- Cygwin、Linux、Mac OS X、Solaris、Windows の各バージョンに合った Git をダウンロードしてください。
- IBM 製品の試用版を今すぐダウンロードし、DB2® や Lotus®、Rational®、Tivoli®、WebSphere® などが提供するアプリケーション開発ツールやミドルウェア製品をお試しください。
著者について | | | William (Bill) von Hagen は、20 年以上の執筆活動および UNIX システム管理者としての経歴を積んでいます。1993年以来 Linux の支持者である彼は著者または共著者として、Ubuntu Linux、Xen 仮想化、GCC (GNU Compiler Collection)、SUSE Linux、Mac OS X、Linux ファイルシステム、 SGML などについての本を書いています。また、Linux および Mac OS X の出版物や Web サイトにも多数の記事を載せています。 |
記事の評価
| 
