Store Git Credentials on Disk with git-credential-store

You are tired of typing a token every push, and git-credential-store will make Git remember it, but the trade-off is blunt. This guide configures the file-based helper, checks where the file lands, and shows how to remove it again. The secret sits unencrypted, protected only by filesystem permissions; if that will not do, use an operating-system keychain helper or the short-lived git-credential-cache instead.

Allow about ten minutes. You need Git and an HTTPS remote. The examples use Git 2.43.0 from the installed git-man package on this machine. No command here needs sudo.

1. Check the version and existing helper

Read the current configuration before changing it. This is an ordinary, read-only check:

$ git --version
git version 2.43.0
$ git config --global --get-all credential.helper

The second command may print nothing. If it lists an existing helper, decide whether adding a persistent plaintext store is really what you want. Git tries several configured helpers in turn, so adding store can weaken an otherwise safer setup.

2. Understand what will be stored

Git calls this helper itself, not you directly, and sends it operations such as get, store and erase over standard input. A stored entry is a URL-shaped line holding the protocol, username, password and host, for example:

https://USER:[email protected]

That is plaintext. A personal access token used as the password is still a credential: anyone who can read the file can use it until the hosting service revokes or expires it.

By default, lookups check ~/.git-credentials first, then $XDG_CONFIG_HOME/git/credentials. If XDG_CONFIG_HOME is empty or unset, the second location is ~/.config/git/credentials. A write uses the first existing file, or creates ~/.git-credentials if neither exists.

3. Enable the helper deliberately

To enable the default file location for your user, run:

$ git config --global --add credential.helper store

This changes your user Git configuration. It does not ask for a credential or create the credentials file immediately. The next HTTPS operation that needs authentication asks for a username and password or token, then the helper saves what Git approves.

If you only want the setting in one repository, omit --global and run the command from that repository:

$ git config --add credential.helper store

Repository-local configuration is easier to scope, but it still points at a user-readable plaintext store by default. It is not a substitute for secure storage.

Verify the setting without printing a secret:

$ git config --global --get-all credential.helper
store

4. Perform one real HTTPS operation

Use the operation you already need, such as a push to an HTTPS remote:

$ git push https://example.invalid/OWNER/REPOSITORY.git BRANCH
Username: YOUR_USERNAME
Password: YOUR_ACCESS_TOKEN

Replace each uppercase value with your real remote details. The example host is intentionally invalid, so do not run it as a connectivity test. On a real remote, Git passes the entered credential to the configured helper after successful authentication. Later operations matching the same protocol, host and username can use the saved entry without prompting.

5. Check the file without exposing its contents

Confirm which default file exists and inspect its mode. These commands reveal names and permissions, not the credential text:

$ if test -f "$HOME/.git-credentials"; then
>     stat -c '%a %n' "$HOME/.git-credentials"
> elif test -f "${XDG_CONFIG_HOME:-$HOME/.config}/git/credentials"; then
>     stat -c '%a %n' "${XDG_CONFIG_HOME:-$HOME/.config}/git/credentials"
> else
>     printf '%s\n' 'No credential file has been created yet'
> fi
600 /home/YOUR_USER/.git-credentials

The installed helper sets a created or used file to mode 600, meaning only its owner can read and write it. Treat that as a minimum safeguard, not encryption. If the path is a symlink or the directory is shared, stop and investigate before storing anything.

6. Handle matching and path surprises

Matching normally considers the protocol, hostname and username when one is already known. A credential stored for one HTTPS host is not automatically a credential for another host.

By default, Git does not distinguish repository paths on the same HTTP(S) host, so a stored entry for one repository can be reused for another repository on that host. If that boundary matters, review the credential.useHttpPath setting before storing a token.

When both default files exist, the home-directory file wins a matching lookup, and an erase operation removes matching credentials from all default files. This is why moving an entry by hand is a poor recovery method: use Git's credential operation, or revoke the token at the hosting service if you suspect disclosure.

7. Remove the helper and recover

Before removing the helper, check whether the global value is exactly the one you added:

$ git config --global --get-all credential.helper
store

Remove only matching store entries:

$ git config --global --unset credential.helper store

This stops Git selecting the global store helper; it does not delete credentials already on disk. To remove the stored credential, use the helper's erase operation with the relevant protocol and host:

$ printf '%s\n' \
    'protocol=https' \
    'host=HOSTNAME' \
    '' | git credential-store erase

Replace HOSTNAME with the real host. The command may erase matching entries in both default files.

If you had another helper before this change, restore that exact value with the command recorded in step 1, for example git config --global --add credential.helper YOUR_PREVIOUS_HELPER. Check the result with git config --global --get-all credential.helper.