-
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ツール
- 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 置換
- 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の内部
-
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 配管コマンド
6.3 GitHub - プロジェクトの保守
プロジェクトの保守
これでプロジェクトへの貢献に慣れてきたので、次は自分でプロジェクトを作成、保守、管理する方法を見ていきましょう。
新しいリポジトリの作成
プロジェクトコードを共有するための新しいリポジトリを作成しましょう。ダッシュボードの右側にある「New repository」ボタンをクリックするか、「New repository」ドロップダウンで表示されているように、ユーザー名の横にある上部のツールバーの+ボタンから開始します。
これにより、「新しいリポジトリ」フォームが表示されます。
ここで本当に必要なのはプロジェクト名を入力することだけです。残りのフィールドは完全にオプションです。とりあえず、「Create Repository」ボタンをクリックすると、<user>/<project_name>という名前の新しいリポジトリがGitHubに作成されます。
まだコードがないため、GitHubには、真新しいGitリポジトリを作成する方法、または既存のGitプロジェクトを接続する方法の手順が表示されます。ここでは詳しく説明しません。復習が必要な場合は、Gitの基本を確認してください。
これでプロジェクトがGitHubでホストされたため、プロジェクトを共有したい人にURLを渡すことができます。GitHubのすべてのプロジェクトは、https://github.com/<user>/<project_name>としてHTTPS経由で、git@github.com:<user>/<project_name>としてSSH経由でアクセスできます。Gitはこれらの両方のURLからフェッチおよびプッシュできますが、それらに接続するユーザーの認証情報に基づいてアクセス制御されます。
|
注記
|
パブリックプロジェクトでは、クローンするためにユーザーがGitHubアカウントを持っている必要がないため、HTTPSベースのURLを共有する方が望ましいことが多いです。SSH URLを共有した場合、ユーザーはプロジェクトにアクセスするために、アカウントとアップロードされたSSHキーが必要になります。HTTPSのURLは、ブラウザでプロジェクトを表示するために貼り付けるURLとまったく同じです。 |
共同作業者の追加
コミット権限を与えたい他の人と共同作業している場合は、その人を「共同作業者」として追加する必要があります。Ben、Jeff、LouiseがGitHubでアカウントを作成し、リポジトリへのプッシュアクセスを許可したい場合は、彼らをプロジェクトに追加できます。これにより、彼らに「プッシュ」アクセス権が付与され、プロジェクトとGitリポジトリへの読み取りおよび書き込みアクセス権を持つことになります。
右側のサイドバーの下部にある「Settings（設定）」リンクをクリックします。
次に、左側のメニューから「Collaborators（共同作業者）」を選択します。次に、ボックスにユーザー名を入力し、「Add collaborator（共同作業者を追加）」をクリックします。必要な回数だけこれを繰り返して、アクセス権を付与できます。アクセス権を取り消す必要がある場合は、該当する行の右側にある「X」をクリックします。
プルリクエストの管理
コードがいくつか含まれるプロジェクトがあり、プッシュアクセス権を持つ共同作業者がいる場合もあるので、プルリクエストを受け取ったときの対処法について説明します。
プルリクエストは、リポジトリのフォークのブランチから発生する場合と、同じリポジトリの別のブランチから発生する場合があります。唯一の違いは、フォークにあるものは、プッシュできないブランチから来ることが多く、一方、内部プルリクエストでは、通常、両方の当事者がブランチにアクセスできるという点です。
これらの例では、「tonychacon」であり、「fade」という名前の新しいArduinoコードプロジェクトを作成したと想定します。
メール通知
誰かがあなたのコードを変更してプルリクエストを送信すると、新しいプルリクエストに関する通知メールが届きます。それは新しいプルリクエストのメール通知のようなものになります。
このメールについて、注目すべき点がいくつかあります。メールには、プルリクエストで変更されたファイルと変更量を示す簡単なdiffstat（差分統計）が表示されます。また、GitHub上のプルリクエストへのリンクも表示されます。さらに、コマンドラインから使用できるいくつかのURLも表示されます。
git pull <url> patch-1という行に注目してください。これは、リモートを追加せずにリモートブランチをマージする簡単な方法です。リモートブランチのチェックアウトでこれについて簡単に説明しました。必要に応じて、トピックブランチを作成して切り替え、このコマンドを実行してプルリクエストの変更をマージできます。
もう1つの興味深いURLは、.diffと.patchのURLです。ご推測のとおり、プルリクエストの統一差分とパッチバージョンを提供します。技術的には、次のようなものを使用してプルリクエストの作業をマージできます。
$ curl https://github.com/tonychacon/fade/pull/1.patch | git amプルリクエストでの共同作業
GitHubフローで説明したように、プルリクエストを開いた人と会話できるようになりました。特定のコード行にコメントしたり、コミット全体にコメントしたり、GitHub Flavored Markdownを使用してプルリクエスト全体にコメントしたりできます。
他の誰かがプルリクエストにコメントするたびに、アクティビティが発生していることを知るためにメール通知が届き続けます。各通知には、アクティビティが発生しているプルリクエストへのリンクがあり、メールに直接返信してプルリクエストのスレッドにコメントすることもできます。
コードが自分が気に入った状態になり、マージしたい場合は、コードをプルダウンしてローカルでマージできます。これには、前に見たgit pull <url> <branch>構文を使用するか、フォークをリモートとして追加してフェッチおよびマージします。
マージが簡単な場合は、GitHubサイトの「Merge（マージ）」ボタンをクリックすることもできます。これにより、「非高速フォワード」マージが実行され、高速フォワードマージが可能であったとしてもマージコミットが作成されます。これは、マージボタンをクリックするたびに、マージコミットが作成されることを意味します。マージボタンとプルリクエストを手動でマージする手順でわかるように、GitHubでは、ヒントリンクをクリックするとこの情報がすべて提供されます。
マージしたくない場合は、プルリクエストを閉じることもできます。その場合、プルリクエストを開いた人に通知されます。
プルリクエストの参照
大量のプルリクエストを処理していて、リモートを多数追加したり、毎回1回限りのプルを実行したりしたくない場合は、GitHubで実行できる便利なトリックがあります。これは少し高度なトリックであり、参照仕様で詳細について説明しますが、非常に役立つ可能性があります。
GitHubは、リポジトリのプルリクエストブランチを、サーバー上の擬似ブランチのようなものとして実際にアドバタイズします。デフォルトでは、クローンするときにそれらは取得されませんが、それらは不明瞭な方法で存在しており、非常に簡単にアクセスできます。
これを説明するために、ls-remoteと呼ばれる低レベルコマンド（「配管」コマンドとも呼ばれ、配管と磁器で詳しく説明します）を使用します。このコマンドは、通常、日常的な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つの参照があります。/headで終わる参照は、プルリクエストブランチの最後のコミットとまったく同じコミットを指します。したがって、誰かがリポジトリでプルリクエストを開き、そのブランチの名前がbug-fixで、コミットa5a775を指している場合、私たちのリポジトリにはbug-fixブランチはありません（それは彼らのフォークにあるため）が、a5a775を指すpull/<pr#>/headはあります。これは、多数のリモートを追加せずに、すべてのプルリクエストブランチを一度に簡単にプルダウンできることを意味します。
これで、参照を直接フェッチするようなことができます。
$ 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 =で始まる行は、「参照仕様」です。これは、リモートの名前をローカルの.gitディレクトリの名前とマッピングする方法です。この特定の行はGitに、「refs/headsの下にあるリモートのものは、ローカルリポジトリのrefs/remotes/originの下に配置する必要がある」と伝えます。このセクションを変更して、別の参照仕様を追加できます。
[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'注意深い人は、参照仕様のリモート部分の末尾にあるheadに気付くでしょう。GitHub側には、サイトの「マージ」ボタンを押した場合の結果となるコミットを表すrefs/pull/#/merge参照もあります。これにより、ボタンを押す前にマージをテストできます。
プルリクエストに対するプルリクエスト
mainまたはmasterブランチを対象とするプルリクエストを開くことができるだけでなく、ネットワーク内の任意のブランチを対象とするプルリクエストを実際に開くこともできます。実際、別のプルリクエストをターゲットにすることもできます。
プルリクエストが正しい方向に進んでいるのを見て、それに依存する変更のアイデアがある場合、それが良いアイデアかどうか確信がない場合、またはターゲットブランチへのプッシュアクセスがない場合は、直接プルリクエストを開くことができます。
プルリクエストを開くときに、ページの上部に、プルするブランチとプルするブランチを指定するボックスがあります。そのボックスの右側にある「Edit（編集）」ボタンをクリックすると、ブランチだけでなく、フォークも変更できます。
ここで、新しいブランチを別のプルリクエストまたはプロジェクトの別のフォークにマージすることをかなり簡単に指定できます。
メンションと通知
GitHubには、特定の個人またはチームからの質問やフィードバックが必要な場合に役立つ、非常に優れた組み込みの通知システムもあります。
任意のコメントで@文字を入力し始めると、プロジェクトの共同作業者または貢献者の名前とユーザー名が自動的に補完されます。
ドロップダウンに表示されないユーザーをメンションすることもできますが、自動補完機能を使用すると高速になることがよくあります。
ユーザーメンションを含むコメントを投稿すると、そのユーザーに通知されます。これは、ユーザーをポーリングするのではなく、会話に引き込む非常に効果的な方法になる可能性があることを意味します。GitHubのプルリクエストでは、チームや会社の人々をプルリクエストやIssueのレビューに引き込むことがよくあります。
誰かがプルリクエストまたはIssueでメンションされると、その人は「サブスクライブ」され、アクティビティが発生するたびに通知を受け取り続けます。また、開いた場合、リポジトリを監視している場合、または何かにコメントした場合もサブスクライブされます。通知の受信を希望しなくなった場合は、ページにある「Unsubscribe（サブスクライブ解除）」ボタンをクリックして、その通知の更新を停止できます。
通知ページ
ここでGitHubに関して「通知」と言う場合、GitHubがイベントが発生したときに連絡を取ろうとする特定の方法を指しており、それらを構成できるいくつかの異なる方法があります。設定ページから「Notification center（通知センター）」タブに移動すると、利用可能なオプションの一部が表示されます。
通知を受け取る方法は、「メール」と「ウェブ」の2つがあり、自分が積極的に参加している場合と、ウォッチしているリポジトリでのアクティビティの場合で、どちらか一方、どちらでもない、または両方を選択できます。
ウェブ通知
ウェブ通知はGitHub上でのみ存在し、GitHubでのみ確認できます。設定でこのオプションを選択している場合、通知がトリガーされると、画面上部の通知アイコンに小さな青い点が表示されます（通知センターを参照）。
それをクリックすると、通知されたすべての項目がプロジェクトごとにグループ化されて表示されます。左側のサイドバーでプロジェクト名をクリックすると、特定のプロジェクトの通知をフィルタリングできます。また、通知の横にあるチェックマークアイコンをクリックして通知を承認したり、グループの上部にあるチェックマークをクリックしてプロジェクト内のすべての通知を承認したりできます。各チェックマークの横にはミュートボタンもあり、クリックするとその項目に関する今後の通知を受け取らないようにすることができます。
これらのツールはすべて、大量の通知を処理するのに非常に役立ちます。GitHubのパワーユーザーの多くは、メール通知を完全にオフにして、この画面ですべての通知を管理します。
メール通知
メール通知は、GitHubで通知を処理するもう1つの方法です。これをオンにしていると、通知ごとにメールが届きます。メール通知として送信されたコメントおよび新規プルリクエストのメール通知でこの例を見ました。メールは適切にスレッド化されるため、スレッド対応のメールクライアントを使用している場合は便利です。
また、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の情報は、<ユーザー>/<プロジェクト>/<タイプ>/<ID>形式ですべてのデータを提供します。たとえば、これが問題であった場合、<タイプ>フィールドは「プル」ではなく「イシュー」になっていたはずです。
List-PostおよびList-Unsubscribeフィールドは、それらを理解するメールクライアントを使用している場合は、リストに簡単に投稿したり、スレッドから「登録解除」したりできることを意味します。これは、ウェブ版の通知で「ミュート」ボタンをクリックしたり、イシューまたはプルリクエストページ自体で「登録解除」をクリックしたりするのとほぼ同じです。
メールとウェブの両方の通知が有効になっていて、メール版の通知を読んだ場合、メールクライアントで画像が許可されていると、ウェブ版も既読としてマークされることにも注意してください。
特別なファイル
リポジトリに存在する場合、GitHubが認識する特別なファイルがいくつかあります。
README
1つ目はREADMEファイルです。これは、GitHubが文章として認識するほぼすべての形式にできます。たとえば、README、README.md、README.asciidocなどです。GitHubがソース内にREADMEファイルを見つけると、プロジェクトのランディングページにレンダリングします。
多くのチームは、このファイルを使用して、リポジトリまたはプロジェクトに不慣れな人のための関連プロジェクト情報をすべて保持しています。これには通常、次のようなものが含まれます。
-
プロジェクトの目的
-
構成とインストール方法
-
使用方法または実行方法の例
-
プロジェクトが提供されるライセンス
-
貢献方法
GitHubはこのファイルをレンダリングするため、理解を深めるために画像やリンクを埋め込むことができます。
CONTRIBUTING
GitHubが認識するもう1つの特別なファイルは、CONTRIBUTINGファイルです。任意のファイル拡張子を持つCONTRIBUTINGという名前のファイルがある場合、GitHubは誰かがプルリクエストを開き始めると、CONTRIBUTINGファイルが存在する場合のプルリクエストの開始を表示します。
ここでのアイデアは、プロジェクトに送信されるプルリクエストで必要なこと、または必要でないことを具体的に指定できるということです。これにより、人々は実際にプルリクエストを開く前にガイドラインを読む可能性があります。
プロジェクト管理
一般的に、単一のプロジェクトで実行できる管理上のことは多くありませんが、いくつか興味深い項目があるかもしれません。
デフォルトブランチの変更
プルリクエストを開いたり、デフォルトで表示したりする場合に、「master」以外のブランチをデフォルトブランチとして使用している場合は、リポジトリの設定ページの「オプション」タブで変更できます。
ドロップダウンでデフォルトブランチを変更するだけで、リポジトリをクローンするときにデフォルトでチェックアウトされるブランチなど、それ以降のすべての主要な操作のデフォルトになります。
プロジェクトの転送
GitHubでプロジェクトを別のユーザーまたは組織に転送する場合は、リポジトリの設定ページの同じ「オプション」タブの下部に「所有権の転送」オプションがあり、これを行うことができます。
これは、プロジェクトを放棄していて、誰かが引き継ぎたい場合や、プロジェクトが大きくなっていて、組織に移動したい場合に役立ちます。
これにより、リポジトリがすべてのウォッチャーとスターとともに別の場所に移動するだけでなく、URLから新しい場所へのリダイレクトも設定されます。Webリクエストだけでなく、Gitからのクローンとフェッチもリダイレクトされます。
