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