概要
これにより、多くの Git 機能を、REST API を使って再実装することができます。Raw 形式オブジェクトをデータベースに直接作成し、ブランチ リファレンスを更新することにより、Git をインストールしなくても、Git ができることのほとんどを行えるのです。
REST API は、Git リポジトリが空であるか、利用できない場合、409 Conflict
を返します。 リポジトリが利用できないということは、通常、GitHub Enterprise Serverがリポジトリを作成処理中であるということです。 空のリポジトリの場合、PUT /repos/{owner}/{repo}/contents/{path}
REST API エンドポイントを使用してコンテンツを作成し、リポジトリを初期化すると、API を使用して Git データベースを管理できるようになります。 このレスポンスステータスが継続している場合は、サイト管理者までご連絡ください。
Git オブジェクト データベースの詳細については、Pro Git ブックの「Git Internals (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 でプルリクエストを表示して [マージ] ボタンが表示されたとき、または REST API を使用してプルリクエストを取得、作成、または編集するときに作成されます。 このリクエストがなければ、merge
Git ref は次に誰かがプルリクエストを表示するまで期限切れになります。
期限切れの merge
Git ref を生成するポーリング メソッドを現在使用している場合、GitHub では以下の手順を使用して、デフォルトブランチから最新の変更を取得することをお勧めします。
- プルリクエストwebhookを受け取ります。
- マージ コミットの候補を作成するためのバックグラウンド ジョブを開始するために
GET /repos/{owner}/{repo}/pulls/{pull_number}
を呼び出します。 GET /repos/{owner}/{repo}/pulls/{pull_number}
を使用してリポジトリをポーリングし、mergeable
属性がtrue
またはfalse
のいずれであるかを確認します。 前の手順を実行した後にのみ、Git ref をmerge
するための更新に Git を直接使用したり、GET /repos/{owner}/{repo}/git/refs/{ref}
を使用したりすることができます。