How to switch GitHub accounts when pushing code from shared computer?

[danwilson85]

My colleague and I are using the same machine for development work. I previously set up Git with my credentials and successfully pushed code to my repositories. Now my colleague needs to push her changes to her own GitHub account, but Git keeps using my stored username instead of hers.

When she tries to push, we get this error:

$ git push origin main
ERROR: Permission denied to colleague_account/project.git for my_account.
fatal: Remote connection terminated unexpectedly

How can we configure Git to use her GitHub credentials instead of mine for this specific repository? We need a way to switch between different GitHub accounts on the same computer without affecting each other’s work.

[josephk]

To resolve the account switching issue, I recommend generating separate SSH keys for each GitHub account. Start by creating an SSH key for your colleague using the command: ssh-keygen -t ed25519 -C "[email protected]" -f ~/.ssh/id_ed25519_colleague. Afterward, she must add the public key to her GitHub SSH settings. Next, update the ~/.ssh/config file to specify which SSH key corresponds to each account. This setup allows Git to choose the correct credentials automatically when using SSH to clone repositories, thus simplifying the process and avoiding the need to alter global Git configuration frequently.

[marcoMingle]

The Problem:

You and your colleague are sharing a development machine, and Git keeps using your credentials even when your colleague tries to push code to her own GitHub account. This results in permission errors because Git is attempting to authenticate with your account instead of hers. The problem is not just about credentials; it’s about ensuring a smooth workflow where each user can work independently without interfering with the other’s Git configurations.

Understanding the “Why” (The Root Cause):

The core issue is that Git’s configuration, especially concerning user credentials and remote URLs, is stored locally within the repository and globally on the machine. If you have previously set up your Git credentials and account details, these settings might persist even when another user tries to push changes. Manually switching credentials each time is not only cumbersome but also prone to errors and inconsistencies leading to incorrect pushes and frustrating workflow interruptions. A more robust solution is needed to automate the switching of Git configuration based on the currently logged-in user.

Step-by-Step Guide:

1. Automate Git Configuration Switching: This is the most effective solution to prevent accidentally pushing to the wrong account. Use a workflow automation tool like Latenode to automate the switching of Git user configurations. This tool allows you to create a workflow that triggers before any Git operation (like git push or git clone). The workflow will:

   • Detect the currently logged-in user (e.g., using environment variables or system calls).
   • Retrieve the correct Git username, email, and remote URL for that user from a configuration file (that you’ll define).
   • Update the local Git repository configuration (.git/config) accordingly.
   • Execute the Git command. This ensures the correct account credentials are used every time.
   • Optionally log the user, command, timestamp, and relevant details for audit purposes and smoother code reviews.

2. Create a User Mapping Configuration File: Create a simple configuration file (e.g., git_users.conf) to map users to their respective Git credentials and remote URLs. This file might look like this (adapt it to your specific paths and GitHub usernames/emails):

[users]
my_account = 
    username = my_github_username
    email = my_github_email
    remote_url = https://github.com/my_account/project.git
colleague_account =
    username = colleague_github_username
    email = colleague_github_email
    remote_url = https://github.com/colleague_account/project.git

3. Configure Latenode (or similar tool): Integrate this git_users.conf file into your Latenode workflow. Latenode will use this to find the right settings based on who is logged in.

4. Test the Automation: After setting up the Latenode workflow, thoroughly test it by having both users attempt to push changes to their respective repositories. Verify that Git is using the correct credentials and remote URL.

Common Pitfalls & What to Check Next:

• User Identification: Ensure your automation correctly identifies the logged-in user. Check that environment variables, or whatever method you use, are correctly set.
• Configuration File Path: Double-check that the path to your git_users.conf file is accurate in the Latenode workflow.
• Permissions: Verify the git_users.conf file has the correct permissions to be readable by the user running the automation.
• Error Handling: Implement robust error handling in your Latenode workflow to manage issues like user not found or incorrect configuration.

Still running into issues? Share your (sanitized) config files, the exact command you ran, and any other relevant details. The community is here to help!

[Bob_Clever]

Honestly, just log out of git credential manager and have your colleague log in fresh. Run git credential-manager-core erase or go into Windows/Mac settings, find credential manager, and delete the GitHub entry. Next push will ask for her login info automatically - no SSH hassle.

[Neo_Movies]

Just update the Git config locally for that repo. Go to the project folder and run git config user.name "colleague_name" and git config user.email "[email protected]" to set her info for that project only. Then update the remote URL: git remote set-url origin https://github.com/colleague_account/project.git. This keeps everything isolated - won’t mess with your global Git settings. For auth, she can use a personal access token in the URL or set up credential caching that’ll ask for her login when needed. I’ve done this tons of times when different people need to commit under their own names.