現在のソフトウェア開発プロジェクトでソフトウェア開発を効果的に行うには、他のプロジェクト参加者と同時に開発できる必要があります。SCM (source code management : ソース・コード管理) システムは新しい考えではありません。ソフトウェア・プロジェクトをより迅速かつ簡単に開発できるようなソフトウェアを作成するために、さまざまな試みがなされてきました。最新のソース・コード管理ソリューションには、リビジョン・コントロール・システムが含まれていて、あるソース・コードがプロジェクトに悪影響を与えることがわかった場合に、そのソース・コードの変更を取り消すことができたり、誰がコードの何行目を変更したのかを単に追跡できたりします。リビジョン・コントロール・システムは、開発者がファイルを同時に変更しようとした場合に、お互いの変更箇所を上書きできないようにして問題に対処します。現在普及しているソース・コード管理ソリューションの多くは、以前の SCM ソリューションが抱えていた問題に対処しようとします。
集中リビジョン・コントロール・システムは、一般的に次の 2 つの方法のいずれかで機能します。
- 一部のシステムは、同時アクセスを防ぐためにファイル・ロック機能を提供します。このようなシステムは、一度に 1 人の開発者のみが集中リポジトリーへの書き込みアクセス権限を持つように、ファイルをロックします。
- CVS などの他のシステムでは、複数の開発者が同時に同じファイルを編集でき、後から変更をマージするための機能があります。
よく使われているリビジョン・コントロール・システムには、次のようなものがあります。
- CVS
- Subversion
- Arch
- Bazaar
- BitKeeper
Git とは何か？
簡単に言うと、Git は Linus Torvalds が最近インプリメントしたソース・コード管理ソフトウェアです。付属の資料によると、「Git は、高速かつスケーラブルな分散リビジョン・コントロール・システムで、かつてないほど豊富なコマンド・セットによって、高度な操作と内部へのフル・アクセスができるようになっています。」とされています。
Torvalds は、以前は世界中の Linux カーネル開発者が使っていた主要なソース・コード・ツール BitKeeper に代わる暫定のソリューションとして Git の開発を開始しました。オープン・ソース・コミュニティーの一部のメンバーは、BitKeeper のライセンスがオープン・ソース界にとって最適ではないと感じていたため、Torvalds はより寛容なライセンスを持つリビジョン・コントロール・システムを研究することにしたのです。当初は Linux カーネル開発プロセスを支援するために開発された Git ですが、他のフリー・ソフトウェア・プロジェクトでも新たな用途が見出されています。例えば、Freedesktop.org プロジェクトを多数抱える X.org は、最近 Git に切り替えました。
最新版の Git は主に、CVS に取って代わるものや独自のコード管理ソリューションを探しているソフトウェア開発者が使えるように意図しています。Git は、次のような多くの点で CVS と異なります。
- ブランチが高速で簡単である。
- オフライン作業がサポートされる。ローカル・コミットを後で実行できる。
- Git のコミットは、CVS のようにファイル単位ではなく、アトミックでプロジェクト全体にわたっています。
- Git でのすべての作業ツリーに、完全なプロジェクト履歴を持つリポジトリーが含まれている。
- 他のリポジトリーよりも本質的に重要な Git リポジトリーはない。
上に戻る
インストール
どのように重要なのは、証言台で真実を語っている
最新リリースの Git をインストールするには、Linux ディストリビューションに付属のベンダー提供のパッケージを使用するか、最新の安定版スナップショットから手動でコンパイルすることができます。Git ソース・コードの最新の安定版スナップショットを収容した tarball をダウンロードすることをお勧めします。この記事の執筆時のリリースは v1.4.0 です。リンクは、以下の参考文献セクションにあります。
この tarball を入手したら、初期インストールに適した依存関係があることを確認してください。システムには、次のパッケージおよびそれぞれの開発ヘッダーが必要です。
- zlib
- libcurl
- libcrypto (OpenSSL)
- rsync (バージョン 2.6.0 以降)
依存関係を満たしている場合は、Git の初期インストールのビルドを開始することができます。プロセスは、以前に Linux を使用したことがあるほとんどの開発者に馴染みがあるものです。まずは、ダウンロードしたパッケージに適した解凍方法で、パッケージを untar します。
$ tar -jxvf git-1.4.0.tar.bz2 |
または
$ tar -zxvf git-1.4.0.tar.gz |
次に、適切なディレクトリーに変更して、make コマンドを使用します。(ディレクトリー名は、ダウンロードしたスナップショットの日付によって異なることに注意してください。)
$ cd git-1.4.0/ $ make prefix=/usr/local install $ sudo make prefix=/usr/local install |
インストールを続行するには、sudo パスワードを入力するよう促されます。これで、Git ツールを使用する準備ができました。
上に戻る
最新のカーネル・ソース・ツリーを入手する
Git を使ってソース・コード・リポジトリーを管理する場合は、主に 2 つの方法で始めることができます。既存のコードのローカル・ディレクトリーを使用して、そこからリポジトリーを作成するか、他の誰かが公開しているリポジトリーをミラーリングすることができます。
この記事では、Torvalds が公開している Git リポジトリーのミラーを取得します。次のコマンドは、linux-2.6 という Git リポジトリー・ディレクトリーを作成します。このディレクトリーには、.git/ という非表示の dotfile ディレクトリーが含まれています。
$ git-clone \ git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git \ linux-2.6 |
Git が kernel.org からローカル・マシンにカーネル・ソース (サイズは何百メガバイトにもなります) を転送するため、このステップは長時間かかります。出力はかなり見にくく、インターネット接続が高速な場合は、相当早くスクロールするはずです。出力は図 1 のようになります。
図 1. カーネル・ソース・ツリーのダウンロード時に生成される出力
今度は、新たにダウンロードしたカーネルが収容されているディレクトリーに変更します。
この時点で、ローカル・マシンに作業用の Linux 2.6 リポジトリーがあるはずです。それでは、このリポジトリーでの基本的な操作に進みましょう。
上に戻る
ローカル Git リポジトリーを更新する
どのような実際に戦争がある
通常、Git の使用時には、ご使用のリポジトリーは kernel.org に置かれているリポジトリーより少し古くなっていると考えることができます。そのため、一般的には、最初にリポジトリーを最新のアップストリームのカーネル・ツリーに更新することから始めます。このプロセスは、高速順方向マージと呼ばれることがあります。厳密に言うと、リポジトリーをインストールしたばかりで、古いはずはないので、今はこの作業を実行する必要はありません。しかし、念のため確認しておきましょう。
$ cd linux-2.6 $ git-pull git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git ... |
正常に実行された場合は、次のような出力が表示されます。
receiving file list ... done sent 130 bytes received 21677 bytes 14538.00 bytes/sec total size is 127865858 speedup is 5863.52 Already up-to-date. $> |
リポジトリーが最新ではない場合は、一部のコンテンツがネットワーク経由でローカル・マシンに転送されるのがわかるでしょう。
上に戻る
リポジトリーからファイルをチェックアウトする
ハッキングを開始するには、Git リポジトリーからから作業ディレクトリーにファイル (隠しファイルの内容) をチェックアウトする必要があります。次のコマンドは、Linux ソース・コードが入ったディレクトリーを現行ディレクトリーに入れます。
ローカル変更を上書きしたい場合は、-f オプションを使ってもう一度チェックアウトを行い、白紙の状態に戻すことができます。
この時点で、現行作業ディレクトリーに Linux ソース・コードの見慣れたディレクトリー構造が表示されているはずで、ソースへの変更を開始することができます。
上に戻る
既存のファイルを変更する
これで、選択した任意のファイルを変更できるようになりました。簡単な例として、docs ディレクトリーで何かを変更してみます。例えば、後で簡単に認識できるメッセージを追加します。わかりやすい例にするために、ここではコードを変更しないことにしましたが、その気があればカーネル・サブシステム全体の再作成に挑戦してもよいでしょう。
まず、エディターでファイルを開きます。
$ vi ./Documentation/ManagementStyle |
おわかりのように、ここでは vi を使用していますが、もちろん好みのエディターを使用して、作業を行うことができます。ファイルの編集時に、最初のパラグラフの前に次の内容の 1 行を追加しました。「Eli shall be in charge of managing sandwich consumption. See Documentation/Sandwiches for more.」
行った変更に納得して、変更をリポジトリーの永続部分にする準備ができたら、後は次のコマンドを使って、変更をチェックインするだけです。
$ git-commit Documentation/ManagementStyle |
すると、コミット・メッセージを作成するよう促されます。コミット・メッセージは、ユーザーが作成するコメントのことで、先ほど行った変更の正確な内容について他の開発者が (またはあとで自分が) 理解できるようにするためのものです。この例でのコミット・メッセージは、資料に先ほど行った変更を説明するセンテンスです。
これまでの作業の状況を確認したい場合は、git-log を実行して、ローカル・リポジトリー (複製したリポジトリーの情報を継承しています) の履歴を表示することができます。コミット・メッセージは、ログの上部にあります。
上に戻る
ファイルを追加または除去する
DCエリアの観光名所
でもちょっと待ってください！まだ Documentation/Sandwiches ファイルを追加していません。このファイルを作業ディレクトリーに追加して、作業が完了したら Git に伝える必要があります。これは簡単な例なので、echo コマンドを使用して、追加するファイルを作成しました。この場合もやはり、どのような方法を使ってもかまいません。
$ echo "Turkey is superior" > Documentation/Sandwiches |
これで、ファイルが追加されたので、このファイルを Git に追加してからリビジョンをコミットすることで、Git にこの変更を通知する必要があります。これらの作業を行うには、次のコマンドを実行します。
$ git-add Documentation/Sandwiches $ git-commit Documentation/Sandwiches |
複数のファイルを追加した場合は、1 つずつ追加する必要はなく、git-add コマンドの後に続けて 1 行にリストすることができます。ファイルを除去しなければならないときには、git-add のような特別なコマンドはありません。単にファイルを除去してから、コミットします。
準備ができたので、今までに行った作業が正しいことを確認するために、git-log でチェックインします。今回は、-p オプションを使って、個々のパッチ・フォーマットでログを表示します。
上に戻る
diff を作成する
最後に、変更済みのソースとオリジナルの差分のみを含んだテキスト・ファイルを作りたくなるでしょう。このファイルは通常、diff ユーティリティーを使って作成され、diff と呼ばれています。diff は、パッチ・ファイルの作成に役立ちます。パッチ・ファイルは、数多くのオープン・ソース・プロジェクトにコードを送信する場合に推奨される方法です。diff について詳しくは、以下の参考文献にある Kernel.org へのリンクを参照してください。
上に戻る
Git が他にできることは？
Git を使うと、他の誰かの作業をミラーリングせずにローカル・リポジトリーを管理することができます。例えば、Git を使用して、オープン・ソース・プロジェクトに対する個人的な貢献を管理する場合は、まずプロジェクト・スナップショットから Git リポジトリーを作成することから始めます。
release.tar.gz という名前の標準リリースの tarball がある場合は、次のコマンドを実行して、ローカルの Git リポジトリーを作成することができます。
$ tar -zxvf release.tar.gz $ cd release $ git init-db |
Git が「デフォルトではローカル・ストレージ域が使用される」ことを示すメッセージが表示されることがあります。これらのメッセージは正常であり、Git リポジトリーが適切な場所にあることを示しています。
これで、作業ディレクトリーが初期化されました。プロジェクト・ディレクトリー内に新規ディレクトリー .git が表示されるはずです。プロジェクト・ディレクトリー内のそれぞれのファイルを追跡することを Git に通知するには、次のコマンドを実行します。
最後に、次のコマンドを使って、モニター対象ファイルをリポジトリーにコミットします。
再度、コミット・メッセージを入力するよう促されます。これ以降は、Git が提供するすべての機能を使って、Git リポジトリー内で作業することができ、試験的な機能のためのブランチ、レグレッションを追跡するための分岐、および通常のリビジョン履歴機能の実行などができます。
ブランチの管理や Git のその他の興味深い機能について詳しくは、Kernel.org で Git の役に立つチュートリアルを確認してください (リンクについては、参考文献を参照してください)。
上に戻る
まとめ
これで、Git を使って、Linux カーネル・ソースとその他の Git 管理対象プロジェクトの両方を取得する方法がわかりましたので、皆さんの中には次の開発プロジェクトの管理に Git を使うことにした方もいらっしゃるかもしれません。Git はまだ比較的新しく、開発途上にあります。さらに一層使いやすくするために、追加のスクリプトやツールがインプリメントされています。参考文献の例を参照してください。
参考文献
学ぶために
製品や技術を入手するために
- Git ソース・コードをダウンロードしてください。
- QGit は、QT ベースの Git GUI です。
- SEK for Linux を注文してください。これは、DB2®、Lotus®、Rational®、Tivoli®、および WebSphere® からの Linux 用の最新の IBM trial software が入った 2 枚セットの DVD です。
- Linux での次の開発プロジェクトの構築に、developerWorks から直接ダウンロードできる IBM trial softwareをご利用ください。
議論するために
著者について
Eli M. Dow は、ニューヨーク州ポキプシーにある、IBM Test and Integration Center for Linux のソフトウェア技術者です。Clarkson University にてコンピューター・サイエンスと心理学で学位を、またコンピューター・サイエンスで修士号を取得しました。彼は、Clarkson Open Source Institute の卒業生です。関心のある分野は、GNOME デスクトップ、マン・マシン・インターフェース、仮想化、および Linux システム・プログラミングなどです。「IBM Redbook Linux for IBM System z9 and IBM zSeries」の共著者です。
この記事を評価する
コメント
上に戻る
0 件のコメント:
コメントを投稿