-
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 スマートHTTP
- 4.7 GitWeb
- 4.8 GitLab
- 4.9 サードパーティホスティングオプション
- 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ツール
-
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内部
-
A1. 付録A: 他の環境でのGit
- A1.1 グラフィカルインターフェース
- A1.2 Visual StudioでのGit
- A1.3 Visual Studio CodeでのGit
- A1.4 IntelliJ / PyCharm / WebStorm / PhpStorm / RubyMineでのGit
- A1.5 Sublime TextでのGit
- A1.6 BashでのGit
- A1.7 ZshでのGit
- A1.8 PowerShellでのGit
- A1.9 まとめ
-
A2. 付録B: アプリケーションへのGitの組み込み
- A2.1 コマンドラインGit
- A2.2 Libgit2
- A2.3 JGit
- A2.4 go-git
- A2.5 Dulwich
-
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.8 サーバー上のGit - GitLab
GitLab
GitWebは非常にシンプルです。もしモダンでフル機能のGitサーバーを探しているのであれば、代わりにインストールできるオープンソースソリューションがいくつかあります。GitLabはその人気のあるものの一つなので、ここでは例としてそのインストールと使用について説明します。これはGitWebのオプションよりも難しく、より多くのメンテナンスが必要ですが、フル機能のオプションです。
インストール
GitLabはデータベースをバックエンドとするWebアプリケーションであるため、他のGitサーバーと比較してインストールが複雑です。幸いなことに、このプロセスは十分に文書化されており、サポートも充実しています。GitLabは、公式のOmnibus GitLabパッケージを使用してサーバーにGitLabをインストールすることを強く推奨しています。
その他のインストールオプションは以下の通りです。
-
Kubernetesで使用するGitLab Helmチャート。
-
Dockerで使用するDockerized GitLabパッケージ。
-
ソースファイルから。
-
AWS、Google Cloud Platform、Azure、OpenShift、Digital Oceanなどのクラウドプロバイダー。
詳細については、GitLab Community Edition (CE) readmeをお読みください。
管理
GitLabの管理インターフェースはウェブ経由でアクセスします。ブラウザでGitLabがインストールされているホスト名またはIPアドレスを指定し、`root`ユーザーとしてログインするだけです。パスワードはインストールタイプによって異なりますが、デフォルトでは、Omnibus GitLabは自動的にパスワードを生成し、少なくとも24時間`/etc/gitlab/initial_root_password`に保存します。詳細についてはドキュメントを参照してください。ログイン後、右上メニューの「Admin area」アイコンをクリックしてください。
ユーザー
GitLabサーバーを使用するすべてのユーザーは、ユーザーアカウントを持つ必要があります。ユーザーアカウントは非常にシンプルで、主にログインデータに紐付けられた個人情報を含みます。各ユーザーアカウントには、そのユーザーに属するプロジェクトの論理的なグループであるネームスペースがあります。もしユーザー「jane」が「project」という名前のプロジェクトを持っていた場合、そのプロジェクトのURLはhttp://server/jane/project
となります。

ユーザーアカウントは2つの方法で削除できます。「ブロック」すると、ユーザーはGitLabインスタンスにログインできなくなりますが、そのユーザーのネームスペース下のすべてのデータは保持され、そのユーザーのメールアドレスで署名されたコミットは引き続きそのプロファイルにリンクされます。
一方、「破棄」すると、データベースとファイルシステムから完全に削除されます。そのネームスペース内のすべてのプロジェクトとデータは削除され、そのユーザーが所有するグループもすべて削除されます。これは明らかに、より永続的で破壊的な操作であり、めったに必要となることはないでしょう。
グループ
GitLabグループは、プロジェクトの集合体であり、ユーザーがそれらのプロジェクトにアクセスする方法に関するデータも含まれます。各グループはプロジェクトネームスペースを持ち(ユーザーの場合と同じように)、例えばグループ「training」がプロジェクト「materials」を持っている場合、そのURLはhttp://server/training/materials
となります。

各グループは複数のユーザーと関連付けられており、それぞれのユーザーはグループのプロジェクトおよびグループ自体に対するアクセス許可レベルを持っています。これには「ゲスト」(課題とチャットのみ)から「オーナー」(グループ、メンバー、プロジェクトの完全な制御)までが含まれます。権限の種類は多すぎてここには列挙できませんが、GitLabの管理画面には役立つリンクがあります。
プロジェクト
GitLabのプロジェクトは、おおよそ単一のGitリポジトリに対応します。すべてのプロジェクトは、ユーザーまたはグループのいずれか単一のネームスペースに属します。プロジェクトがユーザーに属する場合、プロジェクトのオーナーは、誰がプロジェクトにアクセスできるかを直接制御します。プロジェクトがグループに属する場合、グループのユーザーレベルの権限が適用されます。
各プロジェクトには可視性レベルがあり、そのプロジェクトのページとリポジトリへの読み取りアクセス権を制御します。プロジェクトがPrivateの場合、プロジェクトのオーナーは特定のユーザーに明示的にアクセス権を付与する必要があります。Internalプロジェクトは、ログインしているすべてのユーザーに表示され、Publicプロジェクトは誰でも表示できます。これは、git fetch
アクセスと、そのプロジェクトのWeb UIへのアクセスの両方を制御することに注意してください。
フック
GitLabは、プロジェクトレベルとシステムレベルの両方でフックをサポートしています。どちらの場合も、関連するイベントが発生すると、GitLabサーバーは記述的なJSONを含むHTTP POSTを実行します。これは、CIサーバー、チャットルーム、デプロイツールなど、GitリポジトリとGitLabインスタンスを開発自動化の残りの部分に接続する優れた方法です。
基本的な使い方
GitLabで最初に行いたいことは、新しいプロジェクトを作成することです。ツールバーの「+」アイコンをクリックしてこれを行うことができます。プロジェクトの名前、それが属すべきネームスペース、そしてその可視性レベルを尋ねられます。ここで指定することのほとんどは永続的なものではなく、後で設定インターフェースから変更できます。「プロジェクトを作成」をクリックすると、完了です。
プロジェクトが存在したら、それをローカルのGitリポジトリに接続したくなるでしょう。各プロジェクトはHTTPSまたはSSH経由でアクセスでき、どちらもGitリモートを設定するために使用できます。URLはプロジェクトのホームページの上部に表示されています。既存のローカルリポジトリの場合、次のコマンドでホストされた場所にgitlab
という名前のリモートが作成されます。
$ git remote add gitlab https://server/namespace/project.git
リポジトリのローカルコピーがない場合は、単にこれを行うことができます。
$ git clone https://server/namespace/project.git
ウェブUIは、リポジトリ自体のいくつかの便利なビューへのアクセスを提供します。各プロジェクトのホームページには最近のアクティビティが表示され、上部のリンクからプロジェクトのファイルとコミットログのビューに移動できます。
共同作業
GitLabプロジェクトで共同作業を行う最も簡単な方法は、各ユーザーにGitリポジトリへの直接プッシュアクセスを付与することです。ユーザーをプロジェクトに追加するには、そのプロジェクトの設定の「メンバー」セクションに移動し、新しいユーザーをアクセスレベルに関連付けます(異なるアクセスレベルについてはグループで少し説明されています)。ユーザーに「開発者」以上のアクセスレベルを付与すると、そのユーザーはコミットとブランチをリポジトリに直接プッシュできます。
もう一つの、より疎結合なコラボレーションの方法は、マージリクエストを使用することです。この機能により、プロジェクトを見ることができるすべてのユーザーが、制御された方法でプロジェクトに貢献できます。直接アクセス権を持つユーザーは、単純にブランチを作成し、そこにコミットをプッシュし、自分のブランチから`master`または他のブランチへのマージリクエストを開くことができます。リポジトリへのプッシュ権限を持たないユーザーは、それを「フォーク」して自分のコピーを作成し、自分のコピーにコミットをプッシュし、自分のフォークからメインプロジェクトへのマージリクエストを開くことができます。このモデルにより、オーナーはリポジトリに何がいつ投入されるかを完全に制御しつつ、信頼できないユーザーからの貢献も受け入れることができます。
マージリクエストとイシューは、GitLabにおける長期的な議論の主要な単位です。各マージリクエストでは、提案された変更について行ごとに議論することができ(軽量なコードレビューのようなものをサポートします)、一般的な全体的な議論のスレッドも提供されます。どちらもユーザーに割り当てたり、マイルストーンに整理したりできます。
このセクションは主にGitLabのGit関連機能に焦点を当てていますが、成熟したプロジェクトとして、プロジェクトwikiやシステムメンテナンスツールなど、チームの共同作業を支援する多くの他の機能を提供しています。GitLabの利点の1つは、サーバーがセットアップされ稼働していれば、設定ファイルを微調整したりSSH経由でサーバーにアクセスしたりする必要がめったにないことです。ほとんどの管理と一般的な使用は、ブラウザ内のインターフェースを介して行うことができます。