go-git の Plainclone 機能を使用すると、git リポジトリ URL に /git-upload-pack が追加されます。

#php エディター Baicao は、go-git の Plainclone 機能を使用するときに、git リポジトリの URL を指定すると、/git-upload-pack が自動的に追加されることを紹介しました。これは、git-upload-pack が、リモート リポジトリのクローンを作成してプルするために git プロトコルで使用されるコマンドであるためです。この機能を使用すると、/git-upload-pack を手動で追加することなく、リモート リポジトリのクローンを簡単に作成してプルできます。このように、go-git を使用すると、Git 操作をより便利に実行し、作業効率を向上させることができます。

質問内容

Azure Devopsからリポジトリのクローンを作成してみます。

このコードを実行すると、リポジトリ URL の末尾に /git-upload-pack ("https://<リポジトリへのパス>/git-upload-pack") が追加されるため、クローンはステータス コード 400 で失敗します。 なぜこれが追加されるのか理解できません。

解決策

HTTP ベースの Git プロトコルは、使用するプロトコルのバージョンに応じて 2 つのステップで構成されます。 v0 と v1 では、最初のリクエストは /info/refs に対して行われ、使用中の参照を読み取ります。次に 2 番目のリクエストは /git-upload-pack に対して行われます (取得とクローン用)。 ) または /git-receive-pack (プッシュ用)。 v2 ではエンドポイントは同じですが、最初は機能リクエスト、次に ref リクエストと 2 番目のエンドポイントへのデータ転送です。

これらすべての場合、指定した URL はパスを追加するための単なる基礎となります。パスが異なると、nginx や Apache などの背後にある単純な Git サーバーへのアクセスを制御しやすくなります。これが、URL コンポーネントが 1 つだけではない理由です。

つまり、生成された URL は実際には正しいということになります。 400 が表示される理由は、問題があります Azure DevOps では、クライアントが multi_ack 機能をサポートする必要がありますが、go-git はこの機能をサポートしていません。技術的には、サーバーはサポートを希望しないクライアントに対してサポートを提供する必要はありませんが、Git Smart HTTP プロトコルは通常、正常に機能を低下させるように設計されているため、クライアントが必ずしも特定のセットをサポートするとは安全な想定ではありません。 Azure DevOps では、このような仮定を避ける必要があります。

リンクされた問題には、一部 (すべてではありません) の場合に問題を解決するプル リクエストへのリンクが含まれています。ただし、これを利用するには、より高いバージョンに更新する必要がある場合があります。

以上がgo-git の Plainclone 機能を使用すると、git リポジトリ URL に /git-upload-pack が追加されます。の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。