セットアップと設定
プロジェクトの取得と作成
基本的なスナップショット
ブランチとマージ
プロジェクトの共有と更新
検査と比較
パッチ
デバッグ
メール
外部システム
サーバー管理
- 2.46.1 → 2.47.0 変更なし
-
2.46.0
07/29/24
- 2.43.1 → 2.45.2 変更なし
-
2.43.0
11/20/23
- 2.42.1 → 2.42.3 変更なし
-
2.42.0
08/21/23
- 2.41.1 → 2.41.2 変更なし
-
2.41.0
06/01/23
- 2.40.1 → 2.40.3 変更なし
-
2.40.0
03/12/23
- 2.39.1 → 2.39.5 変更なし
-
2.39.0
12/12/22
- 2.35.1 → 2.38.5 変更なし
-
2.35.0
01/24/22
- 2.32.1 → 2.34.8 変更なし
-
2.32.0
06/06/21
- 2.27.1 → 2.31.8 変更なし
-
2.27.0
06/01/20
- 2.25.1 → 2.26.3 変更なし
-
2.25.0
01/13/20
- 2.1.4 → 2.24.4 変更なし
-
2.0.5
12/17/14
説明
Git は、システム固有のヘルパーから認証情報を保存および取得するための内部インターフェースを備えているほか、ユーザーにユーザー名とパスワードの入力を求める機能も備えています。git-credential コマンドは、Git と同じ方法で認証情報を取得、保存、または入力を求める必要があるスクリプトに対して、このインターフェースを公開します。このスクリプト可能なインターフェースの設計は、内部の C API をモデル化しています。概念の詳細については、credential.h を参照してください。
git-credential は、コマンドラインで「アクション」オプション(fill
、approve
、またはreject
のいずれか)を受け取り、標準入力から認証情報の記述を読み取ります(入力/出力形式を参照)。
アクションがfill
の場合、git-credential は、設定ファイルの読み取り、設定された認証ヘルパーへの接続、またはユーザーへの入力を求めることによって、記述に「username」属性と「password」属性を追加しようとします。認証情報の記述の username 属性と password 属性は、すでに提供されている属性とともに標準出力に出力されます。
アクションがapprove
の場合、git-credential は、設定された認証ヘルパーに記述を送信します。ヘルパーは、後で使用する認証情報を保存する場合があります。
アクションがreject
の場合、git-credential は、設定された認証ヘルパーに記述を送信します。ヘルパーは、記述に一致する保存済みの認証情報を消去する場合があります。
アクションがcapability
の場合、git-credential は、サポートする機能を標準出力に発表します。
アクションがapprove
またはreject
の場合、出力は生成されません。
git credential の一般的な使用方法
git-credential を使用するアプリケーションは、通常、次の手順に従ってgit credential
を使用します。
-
コンテキストに基づいて認証情報の記述を生成します。
たとえば、
https://example.com/foo.git
のパスワードが必要な場合、次の認証情報の記述を生成できます(最後の空行を忘れないでください。これにより、git credential
にアプリケーションがすべての情報を供給し終えたことが伝えられます)。protocol=https host=example.com path=foo.git
-
git credential fill
を実行し、ステップ(1)からの記述を標準入力に供給して、この記述のユーザー名とパスワードを取得するように git-credential に指示します。完全な認証情報の記述(認証情報自体、つまりログインとパスワードを含む)が標準出力に出力されます。例:protocol=https host=example.com username=bob password=secr3t
ほとんどの場合、入力で与えられた属性は出力で繰り返されますが、Git は、プロトコルが HTTP(s) であり、
credential.useHttpPath
が false の場合にpath
属性を削除するなど、認証情報の記述を変更する場合もあります。git credential
がパスワードを知っていた場合、この手順では、ユーザーが実際にパスワードを入力する必要がない場合があります(ユーザーはキーチェーンのロックを解除するためにパスワードを入力した可能性があり、キーチェーンがすでにロック解除されていた場合はユーザー操作は行われなかった可能性があります)。password=secr3t
が返される前)。 -
認証情報を使用し(例:ステップ(2)のユーザー名とパスワードを使用して URL にアクセスし)、それが受け入れられるかどうかを確認します。
-
パスワードの成功または失敗を報告します。認証情報によって操作が正常に完了した場合、次の呼び出しで再利用するように
git credential
に指示するために、「approve」アクションでマークできます。操作中に認証情報が拒否された場合は、「reject」アクションを使用すると、git credential
は次の呼び出しで新しいパスワードを要求します。いずれの場合も、git credential
には、ステップ(2)で取得した認証情報の記述(ステップ(1)で提供されたフィールドも含まれます)を供給する必要があります。
入力/出力形式
git credential
は、標準入力/出力で認証情報を(使用されるアクションに応じて)読み書きします。この情報は、git credential
がログイン情報(例:ホスト、プロトコル、パス)を取得するキー、または取得する実際の認証情報データに対応する場合があります。
認証情報は、名前付き属性のセットに分割され、属性ごとに1行あります。各属性は、=
(等号)で区切られたキーと値のペアで指定され、改行が続きます。
キーには、=
、改行、または NUL を除く任意のバイトを含めることができます。値には、改行または NUL を除く任意のバイトを含めることができます。実装が効率的に解析できるように、末尾の改行を含む行の長さは 65535 バイトを超えてはなりません。
C スタイルの配列ブラケット[]
で終わるキーを持つ属性には、複数の値を持つことができます。多値属性の各インスタンスは、値の順序付けられたリストを形成します。繰り返される属性の順序によって値の順序が決定されます。空の多値属性(key[]=\n
)は、以前のエントリをクリアし、リストをリセットします。
いずれの場合も、すべてのバイトはそのまま扱われます(つまり、引用符はなく、改行または NUL を含む値を送信することはできません)。属性のリストは、空行またはファイルの終わりで終了します。
Git は次の属性を理解します。
-
protocol
-
認証情報が使用されるプロトコル(例:
https
)。 -
host
-
ネットワーク認証情報の遠隔ホスト名。指定されたポート番号が含まれる場合もあります(例:「example.com:8088」)。
-
path
-
認証情報が使用されるパス。例:リモート https リポジトリにアクセスする場合、これはサーバー上のリポジトリのパスになります。
-
username
-
すでに持っている場合の認証情報のユーザー名(例:URL、設定、ユーザー、または以前に実行されたヘルパーからのユーザー名)。
-
password
-
保存するように要求されている場合の認証情報のパスワード。
-
password_expiry_utc
-
OAuth アクセストークンなどの生成されたパスワードには、有効期限がある場合があります。ヘルパーから認証情報を読み取るとき、
git credential fill
は期限切れのパスワードを無視します。1970 年からの秒数で表される Unix 時間 UTC。 -
oauth_refresh_token
-
OAuth 更新トークンは、OAuth アクセストークンであるパスワードに付随する場合があります。ヘルパーは、この属性をパスワード属性と同様に機密として扱う必要があります。Git 自体は、この属性に対して特別な動作はありません。
-
url
-
この特別な属性が
git credential
によって読み取られると、その値は URL として解析され、その構成要素が読み取られたかのように扱われます(例:url=https://example.com
は、protocol=https
とhost=example.com
が提供されたかのように動作します)。これにより、呼び出し元は URL を自分で解析する手間を省くことができます。プロトコルの指定は必須です。URLにホスト名(例:「cert:///path/to/file」)が指定されていない場合、資格情報は空文字列のホスト名属性を含みます。
URLに存在しないコンポーネント(例:上記の例にはユーザー名が含まれていない)は、設定されません。
-
authtype
-
これは、該当する認証スキームを使用する必要があることを示します。HTTPとHTTPSの一般的な値には、
basic
、bearer
、digest
が含まれますが、digest
は安全ではないため使用しないでください。credential
が使用される場合、これは問題のプロトコル(通常はHTTP)に適した任意の文字列に設定できます。適切な機能(下記参照)が入力として提供されない限り、この値を送信しないでください。
-
credential
-
問題のプロトコル(通常はHTTP)に適した、事前にエンコードされた資格情報です。このキーが送信される場合、
authtype
は必須であり、username
とpassword
は使用されません。HTTPの場合、Gitはauthtype
値とこの値をスペース1つで連結して、Authorization
ヘッダーを決定します。適切な機能(下記参照)が入力として提供されない限り、この値を送信しないでください。
-
ephemeral
-
このブール値は、trueの場合、
credential
フィールドの値を資格情報ヘルパーが保存すべきではないことを示します。これは、その有用性が時間的に限定されるためです。たとえば、HTTPダイジェストcredential
値はノンスを使用して計算され、再利用しても認証は成功しません。これは、短期間(例:24時間)の資格情報の場合にも使用できます。デフォルト値はfalseです。資格情報ヘルパーは、
store
またはerase
を使用して引き続き呼び出されるため、操作が成功したかどうかを判断できます。適切な機能(下記参照)が入力として提供されない限り、この値を送信しないでください。
-
state[]
-
この値は、再度呼び出された場合にこのヘルパーに返される不透明な状態を提供します。各異なる資格情報ヘルパーはこれを一度指定できます。この値には、資格情報ヘルパーに固有のプレフィックスを含める必要があり、そのプレフィックスと一致しない値は無視する必要があります。
適切な機能(下記参照)が入力として提供されない限り、この値を送信しないでください。
-
continue
-
これはブール値で、有効な場合、この認証が複数段階の認証ステップの最終段階ではないことを示します。これは、クライアント認証の2ラウンドが必要なNTLMやKerberosなどのプロトコルで一般的であり、このフラグを設定することで、資格情報ヘルパーは複数段階の認証ステップを実装できます。このフラグは、さらに段階が必要な場合(つまり、別の認証ラウンドが予想される場合)のみ送信する必要があります。
適切な機能(下記参照)が入力として提供されない限り、この値を送信しないでください。この属性は、資格情報ヘルパーからGit(または
git credential
を呼び出す他のプログラム)に情報を渡すための一方向です。 -
wwwauth[]
-
Gitが1つ以上のWWW-Authenticate認証ヘッダーを含むHTTP応答を受信した場合、これらはGitから資格情報ヘルパーに渡されます。
各WWW-Authenticateヘッダー値は、多値属性wwwauth[]として渡され、属性の順序はHTTP応答に表示される順序と同じです。この属性は、追加情報を資格情報ヘルパーに渡すためのGitからの一方向です。
-
capability[]
-
これは、Gitまたはヘルパーが適切な機能をサポートしていることを示します。これは、プロトコルの部分としてより良い、より具体的なデータを提供するために使用できます。
capability[]
ディレクティブは、それに依存する値の前に置く必要があり、これらのディレクティブはプロトコルで最初に発表されるべきです。現在サポートされている機能は2つあります。最初のものは
authtype
で、authtype
、credential
、ephemeral
の値が理解されていることを示します。2番目はstate
で、state[]
とcontinue
の値が理解されていることを示します。機能がサポートされているからといって、追加機能を使用する必要はありませんが、機能なしで提供するべきではありません。
認識されない属性と機能は、黙って破棄されます。
機能の入力/出力形式
git credential capability
の場合、形式がわずかに異なります。最初に、プロトコルの現在のバージョンを示すversion 0
のアナウンスが行われ、次にcapability authtype
のような行で各機能がアナウンスされます。資格情報ヘルパーもこの形式を実装できますが、これもcapability
引数を使用します。将来、追加の行が追加される可能性があります。呼び出し側は、理解できない行を無視する必要があります。
これは資格情報ヘルパープロトコルの新しい部分であるため、古いバージョンのGitと一部の資格情報ヘルパーはこれをサポートしていない可能性があります。ゼロ以外の終了ステータスが受信された場合、または最初の行が「version」という単語とスペースで始まらない場合、呼び出し側は機能がサポートされていないと想定する必要があります。
この形式の目的は、資格情報の出力と明確に区別することです。常に同じ出力を生成する非常に単純な資格情報ヘルパー(例:インラインシェルスクリプト)を使用できます。異なる形式を使用することで、ユーザーは機能のアドバタイズメントを正しく実装したり、誤って呼び出し側をクエリして機能を混乱させることを心配することなく、この構文を引き続き使用できます。
Git
git[1]スイートの一部