-
1. Gitを始めるにあたって
- 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ツール
- 7.1 リビジョンの選択
- 7.2 インタラクティブステージング
- 7.3 スタッシュとクリーン
- 7.4 作業に署名する
- 7.5 検索
- 7.6 履歴の書き換え
- 7.7 Resetの解明
- 7.8 高度なマージ
- 7.9 Rerere
- 7.10 Gitを使ったデバッグ
- 7.11 サブモジュール
- 7.12 バンドル
- 7.13 置換
- 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 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 Plumbingコマンド
6.3 GitHub - プロジェクトの管理
プロジェクトの管理
プロジェクトへの貢献に慣れてきたところで、別の側面、つまり自分のプロジェクトを作成、管理、運営することを見ていきましょう。
新しいリポジトリの作成
プロジェクトコードを共有するための新しいリポジトリを作成しましょう。ダッシュボードの右側にある「新しいリポジトリ」ボタンをクリックするか、ユーザー名の横にある上部のツールバーの `+` ボタンから開始します（「新しいリポジトリ」ドロップダウンを参照）。
これにより、「新しいリポジトリ」フォームに移動します。
ここで実際に必要なのはプロジェクト名を入力することだけで、残りのフィールドは完全にオプションです。とりあえず、「リポジトリを作成」ボタンをクリックすると、GitHub上に新しいリポジトリ `<user>/<project_name>` が作成されます。
まだそこにコードがないため、GitHubは新しいGitリポジトリを作成する方法、または既存のGitプロジェクトを接続する方法の手順を表示します。ここではこれについて詳しく説明しません。復習が必要な場合は、Gitの基本をご覧ください。
プロジェクトがGitHubでホストされたので、プロジェクトを共有したい人にURLを渡すことができます。GitHub上のすべてのプロジェクトは、HTTPSでは `https://github.com/<user>/<project_name>` として、SSHでは `git@github.com:<user>/<project_name>` としてアクセスできます。Gitはこれらの両方のURLからフェッチおよびプッシュできますが、アクセスは接続するユーザーの認証情報に基づいて制御されます。
|
注
|
パブリックプロジェクトの場合、ユーザーがGitHubアカウントを持っていなくてもクローンアクセスできるため、HTTPSベースのURLを共有することがよく推奨されます。SSH URLを提供した場合、ユーザーはアカウントとアップロードされたSSHキーを持っていなければプロジェクトにアクセスできません。HTTPSのURLは、ブラウザに貼り付けてプロジェクトを表示するのと同じURLでもあります。 |
共同作業者の追加
コミットアクセスを許可したい他の人々と作業している場合は、彼らを「共同作業者」として追加する必要があります。ベン、ジェフ、ルイーズが全員GitHubにアカウントを登録しており、あなたが彼らにリポジトリへのプッシュアクセスを許可したい場合、彼らをプロジェクトに追加できます。そうすることで、彼らは「プッシュ」アクセス権を得て、プロジェクトとGitリポジトリへの読み取りおよび書き込みアクセス権の両方を持つことになります。
右側のサイドバーの下部にある「設定」リンクをクリックします。
次に、左側のメニューから「Collaborators」を選択します。その後、ボックスにユーザー名を入力し、「Add collaborator」をクリックするだけです。好きなだけこれを繰り返して、好きな人にアクセスを許可できます。アクセスを取り消す必要がある場合は、その行の右側にある「X」をクリックするだけです。
プルリクエストの管理
コードが含まれるプロジェクトと、場合によってはプッシュアクセスを持つ共同作業者が何人かいる場合、プルリクエストを受け取ったときに何をすべきかを見ていきましょう。
プルリクエストは、リポジトリのフォーク内のブランチから来ることもあれば、同じリポジトリ内の別のブランチから来ることもあります。唯一の違いは、フォーク内のものは、多くの場合、あなたのブランチにプッシュできず、彼らのブランチにプッシュできない人々からのものであるのに対し、内部のプルリクエストでは通常、両方の関係者がブランチにアクセスできることです。
これらの例では、あなたが「tonychacon」であり、「fade」という新しいArduinoコードプロジェクトを作成したと仮定しましょう。
メール通知
誰かがあなたのコードに変更を加えてプルリクエストを送信してきました。新しいプルリクエストに関する通知メールが届くはずで、それは新しいプルリクエストのメール通知のようになります。
このメールにはいくつか注目すべき点があります。プルリクエストで変更されたファイルのリストと変更量を示す小さなdiffstatが示されます。GitHub上のプルリクエストへのリンクも提供されます。また、コマンドラインから使用できるいくつかのURLも示されます。
`git pull <url> patch-1` と書かれた行に注目してください。これは、リモートを追加せずにリモートブランチをマージする簡単な方法です。これについては、リモートブランチのチェックアウトで簡単に説明しました。必要であれば、トピックブランチを作成して切り替えてから、このコマンドを実行してプルリクエストの変更をマージできます。
その他の興味深いURLは`.diff`と`.patch`のURLで、推測できるとおり、プルリクエストの統合されたdiffとパッチのバージョンを提供します。技術的には、このようなものでプルリクエストの作業をマージできます。
$ curl https://github.com/tonychacon/fade/pull/1.patch | git amプルリクエストでの共同作業
GitHubフローで説明したように、プルリクエストを開いた人と会話できるようになりました。GitHub Flavored Markdownをどこでも使用して、特定のコード行、コミット全体、またはプルリクエスト自体全体にコメントできます。
誰かがプルリクエストにコメントするたびに、引き続きメール通知が届くので、アクティビティがあることがわかります。それぞれの通知には、アクティビティが発生しているプルリクエストへのリンクが含まれており、メールに直接返信してプルリクエストのスレッドにコメントすることもできます。
コードが気に入った場所にあり、マージしたい場合は、前に見た `git pull <url> <branch>` 構文を使用するか、フォークをリモートとして追加してフェッチおよびマージすることで、コードをプルダウンしてローカルでマージできます。
マージが単純な場合は、GitHubサイトの「マージ」ボタンをクリックするだけでも可能です。これにより、「非高速転送」マージが実行され、高速転送マージが可能であってもマージコミットが作成されます。これは、マージボタンをクリックするたびに、必ずマージコミットが作成されることを意味します。プルリクエストを手動でマージするためのマージボタンと指示で示されているように、ヒントリンクをクリックすると、GitHubがこのすべての情報を提供します。
マージしたくないと判断した場合は、プルリクエストを閉じるだけで、開いた人に通知されます。
プルリクエストのリファレンス
**非常に多くの**プルリクエストを扱っていて、いちいちたくさんのリモートを追加したり、一度だけプルしたりしたくない場合、GitHubには便利な裏技があります。これは少し高度なテクニックで、これについてはリフスペルで詳しく説明しますが、非常に役立つ場合があります。
GitHubは実際には、リポジトリのプルリクエストブランチを、サーバー上の擬似ブランチとして宣伝しています。デフォルトでは、クローン時には取得されませんが、隠された形で存在し、非常に簡単にアクセスできます。
これを実演するために、`ls-remote` と呼ばれる低レベルのコマンド（しばしば「配管」コマンドと呼ばれ、これについてはPlumbingとPorcelainで詳しく説明します）を使用します。このコマンドは通常、日常のGit操作では使用されませんが、サーバーにどのような参照が存在するかを示すのに役立ちます。
以前使用していた「blink」リポジトリに対してこのコマンドを実行すると、リポジトリ内のすべてのブランチ、タグ、その他の参照のリストが表示されます。
$ git ls-remote https://github.com/schacon/blink
10d539600d86723087810ec636870a504f4fee4d HEAD
10d539600d86723087810ec636870a504f4fee4d refs/heads/master
6a83107c62950be9453aac297bb0193fd743cd6e refs/pull/1/head
afe83c2d1a70674c9505cc1d8b7d380d5e076ed3 refs/pull/1/merge
3c8d735ee16296c242be7a9742ebfbc2665adec1 refs/pull/2/head
15c9f4f80973a2758462ab2066b6ad9fe8dcf03d refs/pull/2/merge
a5a7751a33b7e86c5e9bb07b26001bb17d775d1a refs/pull/4/head
31a45fc257e8433c8d8804e3e848cf61c9d3166c refs/pull/4/mergeもちろん、リポジトリ内で `git ls-remote origin` やチェックしたいリモートを実行すると、これと似たようなものが表示されます。
リポジトリがGitHubにあり、開かれているプルリクエストがある場合、`refs/pull/`で始まる参照が表示されます。これらは基本的にブランチですが、`refs/heads/`の下にないため、通常はサーバーからクローンしたりフェッチしたりしても取得されません。フェッチのプロセスは通常、これらを無視します。
プルリクエストごとに2つの参照があります。`pull/<pr#>/head` で終わるものは、プルリクエストブランチの最後のコミットとまったく同じコミットを指します。したがって、誰かが私たちのリポジトリでプルリクエストを開き、そのブランチが `bug-fix` と名付けられ、コミット `a5a775` を指している場合、**私たちの**リポジトリには `bug-fix` ブランチはありませんが（それは彼らのフォークにあるため）、`pull/<pr#>/head` は `a5a775` を指します。これは、たくさんのリモートを追加することなく、すべてのプルリクエストブランチを一度に簡単にプルダウンできることを意味します。
さて、参照を直接フェッチするようなこともできます。
$ git fetch origin refs/pull/958/head
From https://github.com/libgit2/libgit2
* branch refs/pull/958/head -> FETCH_HEADこれはGitに、「`origin` リモートに接続し、`refs/pull/958/head` という名前の参照をダウンロードせよ」と伝えています。Gitは喜んで従い、その参照を構築するために必要なものをすべてダウンロードし、`.git/FETCH_HEAD` の下に目的のコミットへのポインタを置きます。その後に `git merge FETCH_HEAD` を実行して、テストしたいブランチにマージできますが、そのマージコミットメッセージは少し奇妙に見えます。また、**多くの**プルリクエストをレビューしている場合は、これが退屈になります。
すべてのプルリクエストをフェッチし、リモートに接続するたびにそれらを最新の状態に保つ方法もあります。お気に入りのエディタで `.git/config` を開き、`origin` リモートを探します。それは次のようになっているはずです。
[remote "origin"]
url = https://github.com/libgit2/libgit2
fetch = +refs/heads/*:refs/remotes/origin/*`fetch =` で始まる行は「refspec」です。これは、リモート上の名前をローカルの `.git` ディレクトリ内の名前とマッピングする方法です。この特定のものはGitに、「リモート上の `refs/heads` の下にあるものは、ローカルリポジトリの `refs/remotes/origin` の下に行くべきだ」と伝えています。このセクションを変更して、別のrefspecを追加できます。
[remote "origin"]
url = https://github.com/libgit2/libgit2.git
fetch = +refs/heads/*:refs/remotes/origin/*
fetch = +refs/pull/*/head:refs/remotes/origin/pr/*その最後の行はGitに、「`refs/pull/123/head` のように見えるすべての参照は、`refs/remotes/origin/pr/123` のようにローカルに保存されるべきだ」と伝えています。これで、そのファイルを保存し、`git fetch` を実行すると、
$ git fetch
# …
* [new ref] refs/pull/1/head -> origin/pr/1
* [new ref] refs/pull/2/head -> origin/pr/2
* [new ref] refs/pull/4/head -> origin/pr/4
# …これで、すべてのリモートプルリクエストがローカルで追跡ブランチのように機能する参照で表されます。これらは読み取り専用で、フェッチすると更新されます。これにより、プルリクエストのコードをローカルで試すのが非常に簡単になります。
$ git checkout pr/2
Checking out files: 100% (3769/3769), done.
Branch pr/2 set up to track remote branch pr/2 from origin.
Switched to a new branch 'pr/2'目の肥えた読者の方なら、refspecのリモート部分の最後に`head`があることに気づくでしょう。GitHub側には`refs/pull/#/merge`という参照もあり、これはサイトで「マージ」ボタンを押した場合に生じるコミットを表します。これにより、ボタンを押す前にマージをテストできます。
プルリクエスト上のプルリクエスト
メインまたは `master` ブランチをターゲットとするプルリクエストを開くだけでなく、ネットワーク内の任意のブランチをターゲットとするプルリクエストを実際に開くことができます。実際、別のプルリクエストをターゲットにすることさえ可能です。
正しい方向に進んでいるプルリクエストを見つけて、それに依存する変更のアイデアがある場合、またはそれが良いアイデアかどうかわからない場合、あるいはターゲットブランチへのプッシュアクセスがない場合は、直接プルリクエストを開くことができます。
プルリクエストを開く際に、ページの上部に、どのブランチにプルリクエストを要求しているか、どのブランチからプルリクエストを要求しているかを指定するボックスがあります。そのボックスの右側にある「編集」ボタンをクリックすると、ブランチだけでなくフォークも変更できます。
ここでは、新しいブランチを別のプルリクエストまたはプロジェクトの別のフォークにマージすることをかなり簡単に指定できます。
メンションと通知
GitHubには、特定の個人やチームからの質問やフィードバックが必要な場合に便利な通知システムが組み込まれています。
コメント内で `@` 文字を入力し始めると、プロジェクトのコラボレーターや貢献者の名前とユーザー名が自動補完され始めます。
ドロップダウンにないユーザーをメンションすることもできますが、オートコンプリート機能を使うとより速くできます。
ユーザーメンションを含むコメントを投稿すると、そのユーザーに通知されます。これは、人々を投票させるのではなく、会話に引き込む非常に効果的な方法となります。GitHubのプルリクエストでは、プロジェクトに関わる他のチームメンバーや社内の人を招いて、課題やプルリクエストをレビューしてもらうことが非常によくあります。
プルリクエストや課題で誰かが言及された場合、その人は「購読」され、その上で何らかのアクティビティが発生するたびに通知を受け取り続けます。また、あなたがそれを開いた場合、リポジトリを監視している場合、または何かについてコメントした場合も、それに購読されます。通知を受け取りたくない場合は、ページにある「購読解除」ボタンをクリックして、更新の受信を停止できます。
通知ページ
ここでGitHubに関する「通知」について言及する場合、GitHubがイベント発生時にあなたに連絡を取ろうとする特定の方法を意味し、それを設定する方法はいくつかあります。設定ページの「通知センター」タブに移動すると、利用可能なオプションの一部を確認できます。
2つの選択肢は「メール」と「ウェブ」で通知を受け取ることで、あなたが積極的に参加する活動とあなたがウォッチしているリポジトリでの活動の両方について、どちらか、どちらでもない、または両方を選択できます。
ウェブ通知
ウェブ通知はGitHub上でのみ存在し、GitHub上でしか確認できません。このオプションを環境設定で選択している場合、通知がトリガーされると、通知センターで示されているように、画面上部の通知アイコンの上に小さな青い点が表示されます。
それをクリックすると、通知されたすべての項目がプロジェクトごとにグループ化されてリスト表示されます。左側のサイドバーでプロジェクト名をクリックすると、特定のプロジェクトの通知に絞り込むことができます。また、通知の横にあるチェックマークアイコンをクリックして通知を既読にしたり、グループの上部にあるチェックマークをクリックしてプロジェクト内の**すべて**の通知を既読にすることもできます。各チェックマークの横にはミュートボタンもあり、それをクリックするとその項目に関するそれ以上の通知を受け取らないようにできます。
これらのツールはすべて、大量の通知を処理するのに非常に役立ちます。多くのGitHubパワーユーザーは、メール通知を完全にオフにし、この画面ですべての通知を管理しています。
メール通知
メール通知は、GitHubを通じて通知を処理するもう一つの方法です。これをオンにしている場合、各通知に対してメールが届きます。これについては、メール通知として送信されるコメントと新しいプルリクエストのメール通知で例を見ました。メールは適切にスレッド化されるので、スレッド対応のメールクライアントを使用している場合は便利です。
GitHubが送信するメールのヘッダーには、カスタムフィルターやルールを設定する際に非常に役立つ豊富なメタデータも埋め込まれています。
例えば、新しいプルリクエストのメール通知で示されたメールでTonyに送られた実際のメールヘッダーを見ると、送信された情報の中に次のものが含まれていることがわかります。
To: tonychacon/fade <fade@noreply.github.com>
Message-ID: <tonychacon/fade/pull/1@github.com>
Subject: [fade] Wait longer to see the dimming effect better (#1)
X-GitHub-Recipient: tonychacon
List-ID: tonychacon/fade <fade.tonychacon.github.com>
List-Archive: https://github.com/tonychacon/fade
List-Post: <mailto:reply+i-4XXX@reply.github.com>
List-Unsubscribe: <mailto:unsub+i-XXX@reply.github.com>,...
X-GitHub-Recipient-Address: tchacon@example.comいくつか興味深い点があります。この特定のプロジェクト、あるいはプルリクエストへのメールを強調表示したり、ルーティングしたりしたい場合、`Message-ID` の情報には `<user>/<project>/<type>/<id>` 形式ですべてのデータが含まれています。これがイシューであった場合、例えば `<type>` フィールドは「pull」ではなく「issues」になっていたでしょう。
`List-Post` と `List-Unsubscribe` フィールドは、それらを理解するメールクライアントを使用している場合、リストに簡単に投稿したり、スレッドから「購読解除」したりできることを意味します。これは、通知のウェブ版で「ミュート」ボタンをクリックするのと本質的に同じか、課題またはプルリクエストのページ自体で「購読解除」するのと同じです。
また、メールとウェブ通知の両方を有効にしていて、メールクライアントで画像が許可されている場合、メール版の通知を読んだ場合、ウェブ版も既読としてマークされることにも注意してください。
特別なファイル
GitHubは、リポジトリに特定の特殊ファイルが存在する場合にそれを認識します。
README
最初のファイルは `README` ファイルで、GitHubが散文として認識するほぼすべての形式で構いません。例えば、`README`、`README.md`、`README.asciidoc` などです。GitHubはソースに `README` ファイルを見つけると、プロジェクトのランディングページにそれをレンダリングします。
多くのチームは、このファイルを使って、リポジトリやプロジェクトに不慣れな人にとって関連するすべてのプロジェクト情報を保持しています。これには通常、次のようなものが含まれます。
-
プロジェクトの目的
-
設定方法とインストール方法
-
使用方法または実行方法の例
-
プロジェクトが提供されるライセンス
-
貢献方法
GitHubはこのファイルをレンダリングするため、理解を深めるために画像やリンクを埋め込むことができます。
CONTRIBUTING
GitHubが認識するもう一つの特殊なファイルは `CONTRIBUTING` ファイルです。ファイル拡張子を問わず `CONTRIBUTING` という名前のファイルがある場合、誰かがプルリクエストを開き始めると、GitHubはCONTRIBUTINGファイルが存在する場合のプルリクエストの作成を表示します。
ここでのアイデアは、プロジェクトに送信されるプルリクエストで必要とするものと不要なものを具体的に指定できるというものです。これにより、人々はプルリクエストを開く前に実際にガイドラインを読むかもしれません。
プロジェクトの管理
一般的に、単一のプロジェクトでできる管理作業は多くありませんが、いくつか興味深い項目があります。
デフォルトブランチの変更
「master」以外のブランチをデフォルトブランチとして使用しており、そのブランチでプルリクエストをオープンさせたり、デフォルトで表示させたりしたい場合は、リポジトリの設定ページの「オプション」タブで変更できます。
ドロップダウンでデフォルトブランチを変更するだけで、それ以降のすべての主要な操作（誰かがリポジトリをクローンしたときにデフォルトでチェックアウトされるブランチを含む）のデフォルトが変更されます。
プロジェクトの転送
プロジェクトをGitHubの別のユーザーまたは組織に転送したい場合、リポジトリ設定ページの同じ「オプション」タブの下部にある「所有権を転送」オプションを使用することで、これを行うことができます。
これは、プロジェクトを放棄して誰かに引き継いでもらいたい場合や、プロジェクトが大きくなり組織に移したい場合に役立ちます。
これにより、リポジトリはすべてのウォッチャーやスターとともに別の場所に移動するだけでなく、元のURLから新しい場所へのリダイレクトも設定されます。Webリクエストだけでなく、Gitからのクローンやフェッチもリダイレクトされます。
