Git Credential Manager: a cross-platform credential helper for Git over HTTPS
Secure, cross-platform Git credential storage with authentication to GitHub, Azure Repos, and other popular Git hosting services.
At a glance
- What is it?
- GCM replaces Git's built-in username/password stores with OAuth and multi-factor authentication for GitHub, Azure DevOps, Bitbucket and GitLab. It is a helper Git calls on its own, not a tool you run by hand.
- Who is it for?
- Adopt GCM if your team uses HTTPS remotes against GitHub, Azure DevOps, Bitbucket or GitLab and you want multi-factor sign-in handled by a helper rather than long-lived personal access tokens pasted into a store. Skip it if your remotes are SSH, since the README points SSH users at their host's own documentation, or if you are pinned to Git 1.x or Git 2.26.2, both of which the README lists as problematic.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository last received commits 2 days ago.
- What is it written in?
- Mainly C#, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 30, 2026, and from our analysis. They are not legal advice.
Editorial analysis
What problem GCM solves, and who it is for
Git's built-in credential helpers store a username and password. On Windows that is wincred, on macOS osxkeychain, on Linux gnome-keyring or libsecret. The README describes them as single-factor authentication support for username/password only. That model breaks down once a host requires multi-factor auth or hands out short-lived tokens instead of passwords.
Git Credential Manager is a credential helper built on .NET that runs on Windows, macOS and Linux and targets Azure DevOps, Azure DevOps Server (formerly Team Foundation Server), Bitbucket, GitHub and GitLab. The README states the goal directly: a consistent and secure authentication experience, including multi-factor auth, to every major source control hosting service and platform.
The audience is developers and build engineers using HTTP(S) remotes. GCM replaces two older projects, the .NET Framework-based Git Credential Manager for Windows and the Java-based Git Credential Manager for Mac and Linux. If you never touch a credential prompt because your remotes are SSH, this project is not aimed at you.
How GCM hooks into Git and where credentials live
GCM is a Git credential helper, so Git invokes it through the credential helper protocol rather than a user-facing command. The README is explicit that GCM is called implicitly by Git and is not intended to be called directly by the user. When you push to Azure DevOps, Bitbucket or GitHub, a window opens and walks you through sign-in.
The flow differs by host and by whether the host is on-premises or cloud-hosted. Later Git commands in the same repository reuse stored credentials or tokens for as long as they remain valid. That reuse is the whole point of a helper: one interactive sign-in, then silent authentication until the token expires.
The storage layer is platform-specific. The README links a dedicated credential stores document and lists secure platform credential storage as supported on all three operating systems. The README also lists Entra authentication with broker support on Windows, macOS and Linux, Windows Integrated Authentication (NTLM/Kerberos) on Windows only, generic OAuth authentication, basic HTTP authentication and network proxies. Architecture coverage is uneven by design: x86 is Windows-only, arm64 is full on macOS and Linux but best effort on Windows, and armhf appears only for Linux.
Installing Git Credential Manager and completing a first sign-in
The README does not inline install commands. It points to the installation instructions for the current version of GCM, with options per operating system. The repository also ships a docs directory and a docs/README.md index that the README calls the documentation index. Fetch the installer for your platform from those instructions, run it, and Git will pick up the helper.
Once installed, the helper is registered in Git configuration. The README does not reproduce that registration command; it links a command line usage document at docs/usage.md for the full surface, and the related searches around git-credential-manager configure point at the same step. Register the helper per that document, then clone or push over HTTPS as usual. On the first authenticated operation the README says a window opens and walks you through the sign-in process.
Sign in through the window, and the credential is stored. A second push in the same repository should not prompt again, because GCM reuses the stored token while it is valid. The README notes that Git 2.26.2 broke credential configuration parsing that GCM relies on; that was fixed in the Git project and released in 2.27.0, so check your Git version before debugging anything else. Git 1.x is listed as unsupported and untested.
Where GCM is the wrong tool
The README scopes GCM to HTTP(S) remotes. SSH is out of scope: it directs readers to their host's own SSH documentation for Azure DevOps, GitHub and Bitbucket. If your workflow is SSH keys plus ssh-agent, installing GCM adds a component that will sit unused.
Operating system support is a second boundary. GCM supports Windows 10 and later including Windows Server 2016 and later, macOS 14 and later, and only the Linux distributions officially supported by .NET. On Linux the README does not enumerate distributions itself; it defers to the .NET support matrix, which means your distro's status is defined by another project's release notes.
Windows 7 and Windows 8.x are a special case. As of GCM 3.x they are no longer supported. The maint-v2 and releases/v2 branches exist to allow security patches and releases for GCM v2.x on those systems only, and the README states those branches will not receive new features. If you are still on Windows 7, you are on a security-only track, not a maintained feature line.
Architecture is the third constraint. x86 is unsupported on Linux, arm64 on Windows is best effort rather than a guarantee, and armhf exists only on Linux. A team standardising on 32-bit Linux or on Windows on ARM should read those rows before assuming parity.
How GCM differs from Git's built-in credential helpers
The comparison the README draws is with Git's own storage helpers: wincred on Windows, osxkeychain on macOS, gnome-keyring or libsecret on Linux. The difference is not storage quality but the authentication model. Those helpers hold a username and password and replay it. GCM performs the host-specific sign-in flow, which is where multi-factor auth and OAuth token issuance happen, then stores the resulting credential.
A practical consequence: with a built-in helper, rotating a password or being forced into MFA means the stored secret stops working and you re-enter it. With GCM, the interactive step is a browser or broker flow the host controls, and the stored artifact is a token with its own lifetime. The README's statement that later commands reuse credentials for as long as they are valid is the operational summary.
The trade-off is a heavier dependency. GCM is a .NET application with platform-specific credential storage and, on Windows, a broker for Entra authentication. A minimal container image or a stripped-down CI runner that only needs to read a public repository does not gain anything from that machinery. The built-in helpers, or no helper at all for anonymous clones, are simpler there.
Maintenance, release cadence and licence
The repository is not archived and the last push was on 2026-09-21. Recent releases listed are v2.9.1 and v2.9.0, both dated 2026-07-14, and v2.8.0 dated 2026-04-28. That is a steady release line rather than a burst. The README also links a project roadmap and a separate document explaining how to read it, so forward plans are published rather than inferred from commit history.
The README states the project is MIT licensed, and the repository carries a LICENSE file plus a NOTICE file at the top level. Note that the repository metadata reports the licence as NOASSERTION while the README says MIT; if licence terms matter to your legal review, read the LICENSE file itself rather than either summary. Nothing here is legal advice.
Upgrade cost is mostly environmental. The README says the project aims to target and update to the latest current .NET LTS version as they become generally available, which means the supported OS matrix can shift with a .NET release. Pinning a GCM version on an older distribution buys time but eventually runs into the same matrix. On Windows 7 and 8.x the only path offered is the v2.x security branches, which the README says will not receive new features.
Editorial conclusion
Adopt GCM if your team uses HTTPS remotes against GitHub, Azure DevOps, Bitbucket or GitLab and you want multi-factor sign-in handled by a helper rather than long-lived personal access tokens pasted into a store. Skip it if your remotes are SSH, since the README points SSH users at their host's own documentation, or if you are pinned to Git 1.x or Git 2.26.2, both of which the README lists as problematic. Before rolling it out, verify your Git version, your OS support level, and which credential store GCM will use on each platform.
Frequently asked questions
Is Git Credential Manager safe?
The README describes GCM as a secure credential helper and lists secure platform credential storage as supported on Windows, macOS and Linux, with storage details in a dedicated credential stores document. It also supports Entra authentication with broker support on all three platforms. The security properties depend on the credential store your platform uses.
Where is Git Credential Manager installed?
The README does not give install paths. It points to the installation instructions for the current version of GCM, which list the options per operating system, and the repository keeps platform-specific documentation under the docs directory indexed by docs/README.md.
Why does Git Credential Manager keep popping up?
The README says a sign-in window opens when you push to a supported host, and that later Git commands in the same repository re-use stored credentials or tokens for as long as they are valid. Repeated prompts therefore point at credentials that are not being stored or have expired, which the credential stores documentation covers.
How do I use Git Credential Manager on Windows?
Install it from the installation instructions, then use Git normally over HTTP(S). The README states GCM is called implicitly by Git and is not intended to be called directly by the user, and that it supports Windows 10 and later including Windows Server 2016 and later. Windows Integrated Authentication (NTLM/Kerberos) is listed as Windows-only.
How do I install Git Credential Manager on Ubuntu?
The README does not list distributions itself. It states that GCM provides support only for the Linux distributions officially supported by .NET and links the .NET support matrix, so check your Ubuntu release against that matrix, then follow the installation instructions for Linux.
Does Git Credential Manager work in WSL?
The README has a Windows Subsystem for Linux section and links detailed WSL information at docs/wsl.md. It does not summarise the WSL setup in the main README, so that document is the place to check before configuring anything.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/git-ecosystem-git-credential-manager)