Can I cache git credentials on a per-project basis?

I couldn't find an option to match exactly what you're after, so I wrote one: a git credential helper that stores credentials on a per-shell basis.

It sets up a temporary encryption key and a temporary directory for data on login, uses them to store the username and password given by git in the store phase of the credential helper process, then gives them back in the get phase.

Caveats:

1. I've tested it but only in a fairly limited way. It works: two separate login shells for the same user can have separate cached credentials.
2. It's fairly naive: it ignores any username and repo URL given by git when storing and retrieving credentials.
3. It will leave behind a temp directory with a few small files for every login.
4. It stores credentials encrypted, but I make no claims about how secure this is in practice.
5. It requires Python 3.6, pycrypto, and bash; I've tested it on linux and macOS. It should be fairly easy to adapt for other setups.

Open an issue if you run into any trouble and I'll see what I can do.

Here are two possible solutions to your problem:

1 - have one OS user per developer.

This is the cleaner option: Each of the developers would connect to a different user account. Add these users to the group www-data and set the file options accordingly: allow read and write by the group members.

Each users's authentication will then be managed independently.

2 - store the configuration per project

Currently, the --global storage of user credentials is done at OS user level. Instead, you may use --local, in order to store the credentials at project level.

This will solve the described problem between users 1 and 2. However, you still may lack some traceability working this way: in case two developers work on the same project, if user2 pushes some changes shortly after user1, user1's authentication details will be used, and it will look like she is the person who did the push - whereas it's user2.

Read git config --help for detailed information about the --local option and data storage locations.

One mitigating solution I have seen in that kind of shared environment is to have a wrapper shell script named 'git' which will:

• overshadow the actual git command
• be launched by a dedicated account (through sudo -u xxx)
• read credentials from a temp file named after the ps id (file owned by xxx, not readable by the original user)
• if that temp file does not exist (on the first git call), creates it and store username/password.
• use that "store" helper for pull/push/clone commands, with a command-local config /usr/bin/git -c credential.helper 'store --file=/path/to/temp/credentials' ..., again executed by the wrapper as xxx.

That same script can not only ask for credential, but also ask for the authorname/email, and add that to its git command, settings local GIT_AUTHOR_NAME/EMAIL for each /usr/bin/git calls.

The idea is to do git command with local configs (local to the git command itself)