Git Credential Manager is the key to ditching those repetitive password prompts when interacting with Git remotes.
Let’s see it in action. Imagine you’re cloning a private GitHub repository. Normally, you’d be prompted for your username and password. With GCM set up, this command just works:
git clone git@github.com:your-username/your-private-repo.git
Or, if you’re pushing changes:
git push origin main
No prompts. Just smooth sailing.
The core problem GCM solves is securely storing and retrieving your authentication credentials (like usernames, passwords, or personal access tokens) so Git doesn’t have to ask you every single time. It acts as an intermediary between Git and your remote hosting service (GitHub, GitLab, Bitbucket, Azure Repos, etc.). When Git needs to authenticate, it asks GCM. GCM then checks its secure storage for valid credentials for that host. If found, it hands them back to Git. If not, it might prompt you once to get them, and then it stores them for future use.
Internally, GCM works by registering itself as a credential helper for Git. This is configured in your global Git configuration file (~/.gitconfig). When you run a Git command that requires authentication (like clone, push, pull, fetch), Git consults its configuration to find a credential helper. If GCM is registered, Git passes the hostname and other relevant information to GCM. GCM then uses the underlying operating system’s secure credential storage (like Windows Credential Manager, macOS Keychain, or Linux secret-service/gnome-keyring) to find or store the credentials. This ensures your sensitive information is never stored in plain text in your Git configuration or command history.
The primary lever you control is which credential helper Git uses. GCM is usually installed as part of Git for Windows or can be installed separately on macOS and Linux. Once installed, you configure Git to use it.
The most common configuration looks like this in your ~/.gitconfig file:
[credential]
helper = manager
Or, if you’re on macOS and have installed it via Homebrew:
[credential]
helper = osxkeychain
On Linux, it might be:
[credential]
helper = /usr/bin/git-credential-manager
The manager option is GCM’s generic identifier, and it figures out the best OS-specific mechanism. If you’re having trouble, explicitly specifying manager or the OS-specific helper can sometimes resolve issues.
The magic happens when GCM first needs to authenticate. Let’s say you git clone a private repo on a fresh machine. Git will ask GCM for credentials. GCM won’t have any. It will then typically pop up a GUI or a command-line prompt asking for your username and password (or, more securely, a Personal Access Token). Once you provide these, GCM stores them securely in your OS’s credential manager. The next time Git needs to authenticate to that same host, GCM retrieves those stored credentials without you seeing a prompt. For services like GitHub and GitLab, using a Personal Access Token (PAT) with appropriate scopes is strongly recommended over your main account password. You can generate PATs in your account security settings on those platforms.
A common point of confusion is understanding when GCM will prompt you versus when it will silently authenticate. GCM prompts you only when it doesn’t have valid, stored credentials for the specific host and protocol (HTTPS vs. SSH) that Git is trying to use. If you’ve previously authenticated via HTTPS and GCM stored those, subsequent HTTPS operations will be passwordless. If you then switch to SSH, GCM won’t have SSH keys stored, and you’ll need to set those up separately (which GCM can also help with, but it’s a distinct credential type).
Many people don’t realize that GCM can manage credentials for multiple Git hosting providers simultaneously. You don’t need a separate tool for GitHub and GitLab. As long as you’ve authenticated to each at least once and GCM has stored the credentials, it will handle them all seamlessly based on the remote URL Git is using.
The next hurdle you’ll often encounter is understanding how GCM interacts with SSH keys for passwordless authentication, as SSH keys are a separate mechanism from username/password or PATs.