-
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 - プロジェクトの管理
プロジェクトの管理
プロジェクトへの貢献に慣れてきたところで、もう一方の側面、つまり独自のプロジェクトを作成し、保守し、管理する方法を見てみましょう。
新しいリポジトリの作成
プロジェクトのコードを共有するための新しいリポジトリを作成しましょう。ダッシュボードの右側にある「New repository」ボタンをクリックするか、ユーザー名の隣にあるトップツールバーの+ボタンから開始します（「New repository」ドロップダウン参照）。
これにより、「new repository」フォームが表示されます。
ここで実際に行う必要があるのは、プロジェクト名を提供することだけです。残りのフィールドはすべて任意です。今のところ、「Create Repository」ボタンをクリックするだけで、<user>/<project_name>という名前の新しいリポジトリがGitHubに作成されます。
まだコードがないため、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でもあります。 |
コラボレーターの追加
コミットアクセスを与えたい他の人と作業している場合は、彼らを「コラボレーター」として追加する必要があります。Ben、Jeff、Louiseが全員GitHubでアカウントを登録し、あなたが彼らにリポジトリへのプッシュアクセスを与えたい場合、彼らをプロジェクトに追加することができます。そうすることで、彼らは「プッシュ」アクセス権を得て、プロジェクトとGitリポジトリの両方に対する読み取りと書き込みのアクセス権を持つことになります。
右側のサイドバーの下部にある「Settings」リンクをクリックします。
次に、左側のメニューから「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サイトの「Merge」ボタンをクリックするだけでも構いません。これにより、「ノンファストフォワード」マージが実行され、ファストフォワードマージが可能であった場合でもマージコミットが作成されます。つまり、マージボタンをクリックするたびに、必ずマージコミットが作成されます。マージボタンとプルリクエストを手動でマージする手順でわかるように、ヒントリンクをクリックすると、GitHubがこのすべての情報を提供します。
マージしたくないと判断した場合は、プルリクエストを閉じるだけで、プルリクエストを開いた人に通知されます。
プルリクエストのRef
多くのプルリクエストを扱っていて、たくさんのリモートを追加したり、毎回一度だけプルしたりしたくない場合は、GitHubが提供する便利なトリックがあります。これは少し高度なトリックで、これについてはRefspecでさらに詳しく説明しますが、非常に役立つことがあります。
GitHubは、実際にはリポジトリのプルリクエストブランチを、サーバー上の擬似ブランチとして公開しています。デフォルトでは、クローン時にこれらは取得されませんが、隠された形で存在し、非常に簡単にアクセスできます。
これを実証するために、低レベルのコマンド（「plumbing」コマンドと呼ばれ、PlumbingとPorcelainで詳しく説明します）である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ブランチはありません（それは彼らのフォークにあるため）が、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という参照もあり、これはサイトで「merge」ボタンを押した場合に結果として生じるコミットを表します。これにより、ボタンを押す前にマージをテストできます。
プルリクエストに対するプルリクエスト
メインまたはmasterブランチをターゲットとするプルリクエストを開くだけでなく、ネットワーク内の任意のブランチをターゲットとするプルリクエストを開くこともできます。実際、別のプルリクエストをターゲットにすることもできます。
正しい方向に向かっているプルリクエストを見つけ、それに依存する変更のアイデアがある場合、またはそれが良いアイデアかどうかわからない場合、あるいはターゲットブランチへのプッシュアクセスがないだけの場合でも、直接それに対してプルリクエストを開くことができます。
プルリクエストを開くと、ページの上部に、どのブランチにプルをリクエストしているか、どのブランチからプルをリクエストしているかを指定するボックスがあります。そのボックスの右側にある「Edit」ボタンをクリックすると、ブランチだけでなくフォークも変更できます。
ここでは、新しいブランチを別のプルリクエストまたはプロジェクトの別のフォークにマージするように非常に簡単に指定できます。
メンションと通知
GitHubには非常に優れた通知システムも組み込まれており、特定の個人やチームからの質問やフィードバックが必要な場合に非常に便利です。
コメントのどこでも@文字を入力し始めると、プロジェクトのコラボレーターや貢献者の名前とユーザー名のオートコンプリートが開始されます。
そのドロップダウンにないユーザーをメンションすることもできますが、多くの場合、オートコンプリート機能によってより迅速に行うことができます。
ユーザーメンションを含むコメントを投稿すると、そのユーザーに通知が送信されます。これは、人々をポーリングさせるのではなく、会話に引き込む非常に効果的な方法となり得ます。GitHubのプルリクエストでは、人々がチームの他のメンバーや会社の他のメンバーを引っ張ってきて、Issueやプルリクエストをレビューさせることが非常によくあります。
誰かがプルリクエストやIssueでメンションされると、彼らはそれに「購読」され、そこで何らかのアクティビティが発生するたびに通知を受け取り続けます。また、あなたがそれを開いた場合、リポジトリをウォッチしている場合、または何かについてコメントした場合も、それに購読されます。通知を受け取りたくなくなった場合は、ページにある「Unsubscribe」ボタンをクリックして、その更新の受信を停止できます。
通知ページ
ここでGitHubに関して「通知」と述べる場合、それはGitHubがイベント発生時にあなたに連絡を取ろうとする特定の方法を意味し、いくつかの異なる設定方法があります。設定ページの「Notification center」タブに移動すると、利用可能なオプションの一部を確認できます。
2つの選択肢は、「Email」と「Web」で通知を受け取ることで、積極的に参加しているものと、ウォッチしているリポジトリのアクティビティについて、どちらか、どちらでもない、または両方を選択できます。
ウェブ通知
ウェブ通知は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>形式ですべてのデータを提供します。例えば、これがissueだった場合、<type>フィールドは「pull」ではなく「issues」になっていたでしょう。
List-PostとList-Unsubscribeフィールドは、これらを理解するメールクライアントがあれば、リストに簡単に投稿したり、スレッドから「購読解除」したりできることを意味します。これは、通知のWebバージョンで「ミュート」ボタンをクリックしたり、Issueまたはプルリクエストページ自体で「Unsubscribe」をクリックしたりするのと本質的に同じです。
また、メール通知とウェブ通知の両方を有効にしていて、メールクライアントで画像が許可されている場合、メール版の通知を読むと、ウェブ版も既読としてマークされることにも注意してください。
特殊なファイル
GitHubは、リポジトリに存在する場合に認識するいくつかの特殊なファイルがあります。
README
一つ目はREADMEファイルで、GitHubが散文として認識するほぼあらゆる形式が可能です。例えば、README、README.md、README.asciidocなどです。GitHubがソースコード内にREADMEファイルを見つけると、それをプロジェクトのランディングページにレンダリングします。
多くのチームは、このファイルを使用して、リポジトリやプロジェクトに不慣れな人にとって関連するすべてのプロジェクト情報を保持しています。これには通常、次のようなものが含まれます。
-
プロジェクトの目的
-
設定とインストール方法
-
使用例または実行方法の例
-
プロジェクトが提供されるライセンス
-
貢献方法
GitHubはこのファイルをレンダリングするため、理解を深めるために画像やリンクを埋め込むことができます。
CONTRIBUTING
GitHubが認識するもう一つの特殊ファイルはCONTRIBUTINGファイルです。任意のファイル拡張子を持つCONTRIBUTINGという名前のファイルがある場合、誰かがプルリクエストを開き始めると、GitHubはCONTRIBUTINGファイルが存在する場合のプルリクエストのオープンを表示します。
ここでのアイデアは、プロジェクトに送信されるプルリクエストに含めてほしい、あるいは含めてほしくない特定の事項を指定できることです。これにより、人々はプルリクエストを開く前に実際にガイドラインを読むかもしれません。
プロジェクト管理
一般的に、単一のプロジェクトでできる管理上のことは多くありませんが、いくつか興味深い項目があります。
デフォルトブランチの変更
「master」以外のブランチをデフォルトブランチとして使用していて、人々がプルリクエストを開いたり、デフォルトで表示したりしたい場合は、リポジトリの設定ページの「Options」タブで変更できます。
ドロップダウンでデフォルトブランチを変更するだけで、それ以降のすべての主要な操作のデフォルトブランチになります。これには、誰かがリポジトリをクローンしたときにデフォルトでチェックアウトされるブランチも含まれます。
プロジェクトの転送
プロジェクトを別のユーザーまたはGitHub内の組織に転送したい場合は、リポジトリ設定ページの同じ「Options」タブの下部に「Transfer ownership」オプションがあり、これを行うことができます。
これは、プロジェクトを放棄して誰かに引き継いでもらいたい場合や、プロジェクトが大きくなり組織に移行したい場合に役立ちます。
これにより、リポジトリとそのすべてのウォッチャーとスターが別の場所に移動するだけでなく、元のURLから新しい場所へのリダイレクトも設定されます。Webリクエストだけでなく、Gitからのクローンやフェッチもリダイレクトされます。
