git-credential

Display credential information, retrieving the username and password from configuration files

$ echo "[url=http://example.com]" | git credential fill

$ echo "[url=http://example.com]" | git credential approve

$ echo "[url=http://example.com]" | git credential reject

git credential <subcommand>

approve
    Approves credentials previously requested by git credential fill. This informs the credential helper that the credentials provided by a prior `get` operation were successfully used and should be stored for future use.

reject
    Rejects credentials previously requested by git credential fill. This informs the credential helper that the credentials provided by a prior `get` operation failed, and should be erased or marked as invalid.

fill
    Requests credentials from the configured helper and prints them to standard output. This subcommand is largely deprecated in modern Git versions, as Git now interacts directly with the credential helper using the `get` protocol, but it remains for compatibility.

The git-credential command provides an interface for Git to securely store and retrieve user credentials, such as usernames and passwords, required for authenticating with remote repositories over HTTP/HTTPS. It is not typically invoked directly by users but is instead called by Git itself when it needs authentication information.

This system allows Git to interact with various credential helpers (like store, cache, osxkeychain, wincred, or libsecret) that manage the actual storage and retrieval of credentials. By standardizing the communication protocol (using stdin/stdout for `get`, `store`, and `erase` operations), git-credential ensures a consistent and extensible way for Git to handle authentication seamlessly across different platforms and security requirements, avoiding repetitive credential prompts.

When Git needs credentials, it asks the configured helper to `get` them. When credentials are successfully used, Git tells the helper to `store` them. If credentials fail, Git tells the helper to `erase` them.

git-credential is primarily an internal interface; direct user invocation is rare. Most interactions are managed by Git automatically based on the `credential.helper` configuration.

Security implications vary greatly depending on the chosen credential helper. Some helpers store credentials in plain text (e.g., store), while others leverage OS-level secure storage (e.g., osxkeychain, wincred, libsecret). Users should choose a helper that aligns with their security requirements.

The `fill` subcommand is deprecated; Git now communicates directly with credential helpers via the `get` protocol for better control and flexibility.

The git-credential interface operates on a simple text-based protocol over standard input/output. Git passes key-value pairs (like `protocol=https`, `host=github.com`, `username=myuser`, `path=/repo.git`) to the helper on stdin. The helper responds on stdout with requested information or status. The primary operations are:

• get: Git asks the helper for credentials. The helper prints `username=...` and `password=...` to stdout if found.
• store: Git provides credentials (e.g., after a successful authentication) for the helper to save.
• erase: Git asks the helper to remove stored credentials (e.g., after an authentication failure).

The behavior of the credential system is controlled by the `credential.helper` configuration variable in Git. This variable specifies which credential helper Git should use. For example:
git config --global credential.helper store
This command sets the global credential helper to `store`, which saves credentials in a plain-text file. Other options include `cache` (stores in memory for a short duration), `osxkeychain`, `wincred`, or `libsecret` for more secure system-level storage.

The Git credential system was introduced around Git version 1.7.9 (released in 2012) to provide a standardized, pluggable mechanism for handling authentication details. Prior to this, users often relied on manually managing credentials in `~/.netrc` files or being prompted repeatedly.

The initial implementations included simple helpers like `store` and `cache`. Over time, more secure and platform-specific helpers (like `osxkeychain`, `wincred`, and `libsecret`) were developed to integrate with native operating system credential managers, significantly enhancing security and user experience. The internal `fill` subcommand, while still available, has been largely superseded by Git's direct communication with helpers for improved protocol control.

git-config(1), git-credential-store(1), git-credential-cache(1), git-credential-osxkeychain(1), git-credential-wincred(1), git-credential-libsecret(1)