# The Git Credential Manager (GCM) is indeed a vital component in the modern developer's toolkit, particularly for those working with Git repositories. Its primary function is to facilitate a smoother workflow by securely managing authentication credentials. This means developers can focus more on their code rather than on repeatedly entering passwords. The GCM's versatility is one of its strongest points, offering support for a range of authentication protocols such as OAuth, Personal Access Tokens, and the classic username and password combination. This flexibility ensures that it can cater to various platforms and services, including
Git Credential Manager (GCM) is a secure Git credential helper built on .NET that runs on Windows, macOS, and Linux. It aims to provide a consistent and secure authentication experience, including multi-factor auth, to every major source control hosting service and platform.
GCM supports (in alphabetical order) Azure DevOps, Azure DevOps Server (formerly Team Foundation Server), Bitbucket, GitHub, and GitLab. Compare to Git's built-in credential helpers (Windows: wincred, macOS: osxkeychain, Linux: gnome-keyring/libsecret), which provide single-factor authentication support for username/password only.
GCM replaces both the .NET Framework-based Git Credential Manager for Windows and the Java-based Git Credential Manager for Mac and Linux.
See the installation instructions for the current version of GCM for install options for your operating system.
Git Credential Manager is currently available for Windows, macOS, and Linux*. GCM only works with HTTP(S) remotes; you can still use Git with SSH:
| Feature | Windows | macOS | Linux* |
|---|---|---|---|
| Installer/uninstaller | ✓ | ✓ | ✓ |
| Secure platform credential storage (see more) | ✓ | ✓ | ✓ |
| Multi-factor authentication support for Azure DevOps | ✓ | ✓ | ✓ |
| Two-factor authentication support for GitHub | ✓ | ✓ | ✓ |
| Two-factor authentication support for Bitbucket | ✓ | ✓ | ✓ |
| Two-factor authentication support for GitLab | ✓ | ✓ | ✓ |
| Windows Integrated Authentication (NTLM/Kerberos) support | ✓ | N/A | N/A |
| Basic HTTP authentication support | ✓ | ✓ | ✓ |
| Proxy support | ✓ | ✓ | ✓ |
amd64 support |
✓ | ✓ | ✓ |
x86 support |
✓ | N/A | ✗ |
arm64 support |
best effort | ✓ | best effort, no packages |
armhf support |
N/A | N/A | best effort, no packages |
(*) GCM guarantees support only for the Linux distributions that are officially supported by dotnet.
Git Credential Manager tries to be compatible with the broadest set of Git versions (within reason). However there are some know problematic releases of Git that are not compatible.
-
Git 1.x
The initial major version of Git is not supported or tested with GCM.
-
Git 2.26.2
This version of Git introduced a breaking change with parsing credential configuration that GCM relies on. This issue was fixed in commit
12294990of the Git project, and released in Git 2.27.0.
Once it's installed and configured, Git Credential Manager is called implicitly
by Git. You don't have to do anything special, and GCM isn't intended to be
called directly by the user. For example, when pushing (git push) to
Azure DevOps, Bitbucket, or GitHub, a
window will automatically open and walk you through the sign-in process. (This
process will look slightly different for each Git host, and even in some cases,
whether you've connected to an on-premises or cloud-hosted Git host.) Later Git
commands in the same repository will re-use existing credentials or tokens that
GCM has stored for as long as they're valid.
Read full command line usage here.
See detailed information here.
See the documentation index for links to additional resources.
Curious about what's coming next in the GCM project? Take a look at the project roadmap! You can find more details about the construction of the roadmap and how to interpret it here.
This project welcomes contributions and suggestions. See the contributing guide to get started.
This project follows GitHub's Open Source Code of Conduct.
We're MIT licensed. When using GitHub logos, please be sure to follow the GitHub logo guidelines.