-
1. 使い始める
- 1.1 バージョン管理に関して
- 1.2 Git略史
- 1.3 Gitの基本
- 1.4 コマンドライン
- 1.5 Gitのインストール
- 1.6 最初のGitの構成
- 1.7 ヘルプを見る
- 1.8 まとめ
-
2. Git の基本
- 2.1 Git リポジトリの取得
- 2.2 変更内容のリポジトリへの記録
- 2.3 コミット履歴の閲覧
- 2.4 作業のやり直し
- 2.5 リモートでの作業
- 2.6 タグ
- 2.7 Git エイリアス
- 2.8 まとめ
-
3. Git のブランチ機能
- 3.1 ブランチとは
- 3.2 ブランチとマージの基本
- 3.3 ブランチの管理
- 3.4 ブランチでの作業の流れ
- 3.5 リモートブランチ
- 3.6 リベース
- 3.7 まとめ
-
4. Gitサーバー
- 4.1 プロトコル
- 4.2 サーバー用の Git の取得
- 4.3 SSH 公開鍵の作成
- 4.4 サーバーのセットアップ
- 4.5 Git デーモン
- 4.6 Smart HTTP
- 4.7 GitWeb
- 4.8 GitLab
- 4.9 サードパーティによる Git ホスティング
- 4.10 まとめ
-
5. Git での分散作業
- 5.1 分散作業の流れ
- 5.2 プロジェクトへの貢献
- 5.3 プロジェクトの運営
- 5.4 まとめ
-
6. GitHub
- 6.1 アカウントの準備と設定
- 6.2 プロジェクトへの貢献
- 6.3 プロジェクトのメンテナンス
- 6.4 組織の管理
- 6.5 スクリプトによる GitHub の操作
- 6.6 まとめ
-
7. Git のさまざまなツール
- 7.1 リビジョンの選択
- 7.2 対話的なステージング
- 7.3 作業の隠しかたと消しかた
- 7.4 作業内容への署名
- 7.5 検索
- 7.6 歴史の書き換え
- 7.7 リセットコマンド詳説
- 7.8 高度なマージ手法
- 7.9 Rerere
- 7.10 Git によるデバッグ
- 7.11 サブモジュール
- 7.12 バンドルファイルの作成
- 7.13 Git オブジェクトの置き換え
- 7.14 認証情報の保存
- 7.15 まとめ
-
8. Git のカスタマイズ
- 8.1 Git の設定
- 8.2 Git の属性
- 8.3 Git フック
- 8.4 Git ポリシーの実施例
- 8.5 まとめ
-
9. Gitとその他のシステムの連携
- 9.1 Git をクライアントとして使用する
- 9.2 Git へ移行する
- 9.3 まとめ
-
10. Gitの内側
- 10.1 配管(Plumbing)と磁器(Porcelain)
- 10.2 Gitオブジェクト
- 10.3 Gitの参照
- 10.4 Packfile
- 10.5 Refspec
- 10.6 転送プロトコル
- 10.7 メンテナンスとデータリカバリ
- 10.8 環境変数
- 10.9 まとめ
-
A1. 付録 A: その他の環境でのGit
- A1.1 グラフィカルインタフェース
- A1.2 Visual StudioでGitを使う
- A1.3 EclipseでGitを使う
- A1.4 BashでGitを使う
- A1.5 ZshでGitを使う
- A1.6 PowershellでGitを使う
- A1.7 まとめ
-
A2. 付録 B: Gitをあなたのアプリケーションに組み込む
- A2.1 Gitのコマンドラインツールを使う方法
- A2.2 Libgit2を使う方法
- A2.3 JGit
-
A3. 付録 C: Gitのコマンド
- A3.1 セットアップと設定
- A3.2 プロジェクトの取得と作成
- A3.3 基本的なスナップショット
- A3.4 ブランチとマージ
- A3.5 プロジェクトの共有とアップデート
- A3.6 検査と比較
- A3.7 デバッグ
- A3.8 パッチの適用
- A3.9 メール
- A3.10 外部システム
- A3.11 システム管理
- A3.12 配管コマンド
4.2 Gitサーバー - サーバー用の Git の取得
サーバー用の Git の取得
さて、これまでに説明してきたプロトコルを使って Git サーバーを構築する方法を見ていきましょう。
注記
|
ここで提示するコマンドや手順は、標準的な構成を Linux サーバーにインストールする場合のものです。また、これらは Mac や Windows のサーバーにも応用できます。 ただし、サーバーをプロダクション用にセットアップするときには、セキュリティの観点、OS のツール類などで違いが出るのは当然です。とはいえ、この節を読めば必要なものについて概ね把握できるでしょう。 |
Git サーバーを立ち上げるには、既存のリポジトリをエクスポートして新たなベアリポジトリ (作業ディレクトリを持たないリポジトリ) を作らなければなりません。
これは簡単にできます。
リポジトリをクローンして新たにベアリポジトリを作成するには、clone コマンドでオプション --bare
を指定します。
慣例により、ベアリポジトリのディレクトリ名の最後は .git
とすることになっています。
$ git clone --bare my_project my_project.git
Cloning into bare repository 'my_project.git'...
done.
そうすると、Git ディレクトリのデータを my_project.git
ディレクトリにコピーできます。
これは、おおざっぱに言うと次の操作と同じようなことです。
$ cp -Rf my_project/.git my_project.git
設定ファイルにはちょっとした違いもありますが、ほぼこんなものです。 作業ディレクトリなしで Git リポジトリを受け取り、それ単体のディレクトリを作成しました。
ベアリポジトリのサーバー上への設置
ベアリポジトリを取得できたので、あとはそれをサーバー上においてプロトコルを準備するだけです。
ここでは、git.example.com
というサーバーがあってそこに SSH でアクセスできるものと仮定しましょう。Git リポジトリはサーバー上の /opt/git
ディレクトリに置く予定です。
/opt/git
ディレクトリが作成済みであれば、新しいリポジトリを作成するには、ベアリポジトリを次のようにコピーします。
$ scp -r my_project.git user@git.example.com:/opt/git
この時点で、同じサーバーに SSH でアクセスできてかつ /opt/git
ディレクトリへの読み込みアクセス権限がある人なら、次のようにしてこのリポジトリをクローンできるようになりました。
$ git clone user@git.example.com:/opt/git/my_project.git
ユーザーが SSH でアクセスでき、かつ /opt/git/my_project.git
ディレクトリへの書き込みアクセス権限があれば、すでにプッシュもできる状態になっています。
git init
コマンドで --shared
オプションを指定すると、リポジトリに対するグループ書き込みパーミッションを自動的に追加することができます。
$ ssh user@git.example.com
$ cd /opt/git/my_project.git
$ git init --bare --shared
既存の Git リポジトリからベアリポジトリを作成し、メンバーが SSH でアクセスできるサーバーにそれを配置するだけ。簡単ですね。 これで、そのプロジェクトでの共同作業ができるようになりました。
複数名が使用する Git サーバーをたったこれだけの作業で用意できるというのは特筆すべきことです。 サーバーにSSHでアクセス可能なアカウントを作成し、ベアリポジトリをサーバーのどこかに置き、そこに読み書き可能なアクセス権を設定する。 これで準備OK。他には何もいりません。
次のいくつかのセクションでは、より洗練された環境を作るための方法を説明します。いちいちユーザーごとにアカウントを作らなくて済む方法、一般向けにリポジトリへの読み込みアクセスを開放する方法、ウェブ UI の設定などです。しかし、数名のメンバーで閉じたプロジェクトでの作業なら、SSH サーバーとベアリポジトリ さえ あれば十分なことは覚えておきましょう。
ちょっとしたセットアップ
小規模なグループ、あるいは数名の開発者しかいない組織で Git を使うなら、すべてはシンプルに進められます。 Git サーバーを準備する上でもっとも複雑なことのひとつは、ユーザー管理です。 同一リポジトリに対して「このユーザーは読み込みのみが可能、あのユーザーは読み書きともに可能」などと設定したければ、アクセス権とパーミッションの設定は、設定しない場合と比べて少しですが難しくなります。
SSH アクセス
開発者全員が SSH でアクセスできるサーバーがすでにあるのなら、リポジトリを用意するのは簡単です。先ほど説明したように、ほとんど何もする必要はないでしょう。 より複雑なアクセス制御をリポジトリ上で行いたい場合は、そのサーバーの OS 上でファイルシステムのパーミッションを設定するとよいでしょう。
リポジトリに対する書き込みアクセスをさせたいメンバーの中にサーバーのアカウントを持っていない人がいる場合は、新たに SSH アカウントを作成しなければなりません。 あなたがサーバーにアクセスできているということは、すでに SSH サーバーはインストールされているということです。
その状態で、チームの全員にアクセス権限を与えるにはいくつかの方法があります。
ひとつは全員分のアカウントを作成すること。直感的ですがすこし面倒です。
ひとりひとりに対して adduser
を実行して初期パスワードを設定するという作業をしなければなりません。
もうひとつの方法は、git ユーザーをサーバー上に作成し、書き込みアクセスが必要なユーザーには SSH 公開鍵を用意してもらってそれを git ユーザーの ~/.ssh/authorized_keys
に追加します。
これで、全員が git ユーザーでそのマシンにアクセスできるようになりました。これがコミットデータに影響を及ぼすことはありません。
SSH で接続したときのユーザーとコミットするときに記録されるユーザーとは別のものだからです。
あるいは、SSH サーバーの認証を LDAP サーバーやその他の中央管理形式の仕組みなど既に用意されているものにするとこもできます。 各ユーザーがサーバー上でシェルへのアクセスができさえすれば、どんな仕組みの SSH 認証であっても動作します。