概要
これにより、さまざまなGitの機能を、APIを介して再実装することができます。Raw形式オブジェクトのオブジェクトをデータベースに直接作成し、ブランチリファレンスを更新することにより、Gitをインストールしなくても、Gitができることのほとんどを行えるのです。
Git Database API関数は、Gitリポジトリが空または利用できない場合、409 Conflictを返します。 リポジトリが利用できないということは、通常、GitHub Enterprise Serverがリポジトリを作成処理中であるということです。 空のリポジトリの場合は、「ファイルコンテンツの作成または更新」エンドポイントを使用してコンテンツを作成し、リポジトリを初期化してGit Database APIを使用できるようにすることができます。 このレスポンスステータスが継続している場合は、your site administratorまでご連絡ください。
Gitオブジェクトデータベースについての詳細は、Pro GitブックのGitの内側の章を参照してください。
例として、リポジトリのファイルに変更をコミットしたい場合は、次のようにします。
- 現在のコミットオブジェクトを取得する
- ポイントするツリーを取得する
- 特定のファイルパスに対してツリーが持つblobオブジェクトのコンテンツを取得する
- 何らかの方法でコンテンツを変更し、新しいコンテンツで新しいblobオブジェクトをPOSTし、blob SHAを再取得する
- ファイルパスポインタが新しいblob SHAに置き換えられたツリーオブジェクトをPOSTし、ツリーSHAを再取得する
- 現在のコミットSHAを親とする新しいコミットオブジェクトと、新しいツリーSHAを作成し、コミットSHAを再取得する
- ブランチのリファレンスを、新しいコミットSHAを指すように更新する
複雑に見えるかもしれませんが、実際にはモデルを理解していれば非常に単純で、理解することによりAPIでできることが広がるでしょう。
プルリクエストのマージ可能性を確認
警告: 更新でGit refをmergeするために直接Gitを使用したり、GET /repos/{owner}/{repo}/git/refs/{ref}を使用したりしないでください。こうしたコンテンツが古くて使えなくなっても警告されません。
testマージコミットを作成するには、使用するAPIは、明示的にプルリクエストを要求する必要があります。 testマージコミットは、UIでプルリクエストを表示して [Merge] ボタンが表示されるか、REST APIを使ってプルリクエストを取得、作成、または編集した際に作成されます。 このリクエストがなければ、merge Git refは次に誰かがプルリクエストを表示するまで期限切れになります。
期限切れのmerge Git refを生成するポーリングメソッドを現在使用している場合、GitHubでは以下のステップに従い、デフォルトブランチ から最新の変更を取得することをお勧めします。
- プルリクエストwebhookを受け取ります。
GET /repos/{owner}/{repo}/pulls/{pull_number}を呼び出し、マージコミット候補を作成するためのバックグラウンドジョブを開始します。mergeable属性がtrueかfalseかを判断するため、GET /repos/{owner}/{repo}/pulls/{pull_number}を使用してリポジトリをポーリングします。 更新でGit refをmergeするために直接Gitを、またはGET /repos/{owner}/{repo}/git/refs/{ref}を使用できるのは、前の手順を実行した場合のみです。