DEV Community: Deepanshu Jangra

Two GitHub Accounts, One Laptop, Zero Regrets

Deepanshu Jangra — Tue, 04 Aug 2026 10:05:18 +0000

There's a specific flavor of embarrassment that only developers know.

It's 11 PM. You've just finished a weekend project you're genuinely proud of. You push it to your personal GitHub, open the repo in your browser to admire it, and there it is at the top of the commit list:

developer@company.com committed 2 minutes ago

Your work email. On your personal project. Sitting in a public repo. Forever.

Nobody's going to fire you over it. But it looks sloppy, it quietly announces which company you work at to every stranger who reads your code, and — the part that actually stings — it means the commit doesn't show up on your personal contribution graph. All those little green squares you earned at midnight? They went to an account that doesn't even know they exist.

I did this for about two years before I fixed it. Here's the fix, and more importantly, here's every way I managed to get it wrong first.

Why this happens

Git has exactly one global identity, stored in ~/.gitconfig. When you set it up on day one at a new job, you type in your work email, and Git dutifully stamps that on every commit you make on that machine for the rest of time.

Git does not know the difference between ~/work/critical-production-service and ~/study/thing-i-made-at-2am. It's a version control system, not a mind reader. To Git, it's all just directories.

So we have to tell it.

Step 1: Teach Git to read the room

Git has a feature called conditional includes, and it is the single most underrated thing in the entire tool. It lets you say: "if the repo lives in this folder, use a different identity."

First, make a file for your personal identity. Call it ~/.gitconfig-personal:

[user]
    name = Your Name
    email = your.personal@gmail.com

Then, at the bottom of your existing ~/.gitconfig, add:

[includeIf "gitdir:~/study/"]
    path = ~/.gitconfig-personal

Replace ~/study/ with wherever your personal projects live. Mine is ~/study/, because I started that folder to learn things and never renamed it.

Two details that will bite you if you skip them:

The trailing slash matters. gitdir:~/study/ means "this folder and everything inside it." Without the slash, Git gets picky in ways you don't want to debug at midnight.

It must go at the bottom. Git reads the config top to bottom, and the last value wins. If you paste the includeIf block above your [user] section, your work email will override the personal one and you'll spend twenty minutes convinced the feature is broken. It is not broken. You are just at the wrong altitude in the file. (Ask me how I know.)

Verify it worked

cd ~/study/any-project
git config user.email     # should print your personal email

cd ~/work/any-project
git config user.email     # should print your work email

If the personal folder still shows work email, check two things: is the includeIf at the bottom, and is that folder actually a Git repo? Conditional includes evaluate against a repository's location. Run it in a folder with no .git in it and Git shrugs and gives you the global default. This confused me for a solid ten minutes.

Step 2: The keys to two kingdoms

Identity is only half the problem. The other half is authentication — proving to GitHub that you're allowed to push.

Your laptop has one SSH key. GitHub has a rule: one key, one account. You cannot add the same public key to two different GitHub accounts. GitHub will look at it, recognize it, and tell you it's already in use, in the tone of a bouncer who remembers your face.

So: second key.

ssh-keygen -t ed25519 -C "your.personal@gmail.com" -f ~/.ssh/id_ed25519_personal

Note the -f flag. It gives the key a specific name instead of overwriting ~/.ssh/id_rsa. Do not skip this. Your existing key probably has access to production servers, deploy targets, and other things that are extremely annoying to re-provision because you were typing fast.

Copy the public half:

pbcopy < ~/.ssh/id_ed25519_personal.pub

Then go to GitHub → Settings → SSH and GPG keys → New SSH key, and paste it in. Make sure you're logged into your personal account. If you add your personal key to your work account, everything will appear to work until it very much doesn't.

Step 3: The alias that makes it all click

Here's the clever bit. You now have two keys, but when you run git push, SSH has no idea which one to use. It'll just offer them in order and hope.

So you invent a hostname that doesn't exist.

Add this to ~/.ssh/config:

Host github-personal
    HostName github.com
    User git
    IdentityFile ~/.ssh/id_ed25519_personal
    IdentitiesOnly yes

Read that carefully, because it's doing something sneaky. github-personal isn't a real domain. It's a nickname. When you tell Git to connect to github-personal, SSH looks it up in this config, sees "oh, that means github.com, and use this specific key," and does the right thing.

IdentitiesOnly yes is the load-bearing line. Without it, SSH helpfully offers every key it knows about, starting with your work one. GitHub accepts the first valid key it sees, so you authenticate as the wrong account and get a confusing permission error about a repo you're literally staring at in your browser.

Now use the alias in your remote URL:

git remote add origin git@github-personal:yourusername/your-repo.git

Everything after the colon is normal. Only the host part changed.

Test it:

ssh -T git@github-personal

You want: Hi yourusername! You've successfully authenticated...

If it greets you by your work username, IdentitiesOnly is missing or misspelled.

The four errors you are about to hit

I hit all of these. In order. Consider this the walkthrough.

`ssh: Could not resolve hostname github-personal`

You used the alias before creating it. SSH looked for a real server called github-personal, found nothing, and gave up. Go back and add the Host block to ~/.ssh/config.

The reason this error is confusing is that it sounds like a network problem. It isn't. It's a "you invented a nickname and forgot to write it down" problem.

`fatal: refusing to merge unrelated histories`

You created the repo on GitHub with the "Add a README" checkbox ticked, so GitHub made a commit. Meanwhile you made your own first commit locally. Two separate histories, no common ancestor, and Git — reasonably — refuses to guess.

If the remote only contains GitHub's auto-generated stub:

git push -u origin main --force

If there's anything on the remote you actually care about:

git pull origin main --allow-unrelated-histories

...and then resolve the conflict like an adult. Check git log origin/main before you force anything. Force pushes are permanent, and "I thought it was empty" is not a recovery strategy.

`remote: Permission to user/repo.git denied`

Wrong key got offered. Either IdentitiesOnly yes is missing, or you added the public key to the wrong GitHub account.

The HTTPS trap

This one is the sneakiest, because nothing errors — it just silently does the wrong thing.

If your remote starts with https://github.com/... instead of git@..., none of your SSH setup applies. On macOS, Git pulls credentials from the Keychain, where your work account's token has been quietly living since your first day. It'll use that. Every time.

Check your remotes:

git remote -v

If you see https://, switch it:

git remote set-url origin git@github-personal:yourusername/your-repo.git

And if you need to evict the stored credential:

printf 'protocol=https\nhost=github.com\n\n' | git credential-osxkeychain erase

Was it worth it?

Fifteen minutes of setup. Then it just... works. Forever. Silently.

I clone a personal project into ~/study/, and it's me. I clone a work repo anywhere else, and it's work me. I have never once had to think about it since, which is the highest compliment you can pay to any piece of configuration.

The green squares go to the right account now. My work email isn't scattered across public repos. And when a recruiter opens my GitHub, they see a person with side projects — not a person who apparently does side projects on company time.

That last one wasn't even true. But it sure looked like it.

If this saved you from an awkward commit history, drop a heart. If you're reading this because you already pushed with the wrong email — git commit --amend --author="Name <email>" fixes the last one, and git rebase fixes the rest, but that's a whole other article and honestly, sometimes you just start a fresh repo and move on with your life.

How to Install NVM and Node on macOS M1 Silicon in 2023

Deepanshu Jangra — Sun, 01 Oct 2023 08:40:10 +0000

As a software engineer working on a Mac with an M1 Silicon chip, having NVM (Node Version Manager) and Node.js installed is crucial. In 2023, setting up your development environment for Node.js on an M1 Mac is easier than ever. In this guide, we'll walk you through the steps to install NVM and Node.js, enabling you to streamline your development workflow.

Step 1: Get NVM

Check for .zshrc Profile: Open a new terminal window and run the following command to check if you already have a .zshrc profile:

   $ ls -a

If you see .zshrc in the list, you can skip this step. However, if it's not there, you need to create one:

   $ touch .zshrc

Install NVM: Now that you have a .zshrc profile, it's time to install NVM. Visit the official NVM GitHub repository [here] to find the NVM cURL install command. The command should look something like this:

   $ curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.1/install.sh | bash

Copy this command and paste it into your terminal. This will download and install NVM, making it available for use.

Refresh .zshrc: As this installation affects your .zshrc profile, you should run the following command to update it:

   $ source .zshrc

Congratulations, you now have NVM installed on your Mac!

Step 2: Get Node

Install Node: To install Node.js using NVM, simply run this command in your terminal:

   $ nvm install node

This command will download and install the latest version of Node.js.

Activate Node: While Node.js is now downloaded, you need to activate it to use it. Run the following command:

   $ nvm use node

This command sets the recently installed Node.js version as the active one.

Conclusion:
You've successfully set up NVM and installed Node.js on your macOS M1 Silicon-based machine. This streamlined process ensures you have the tools necessary for your development tasks in 2023. With NVM and Node.js at your disposal, you can easily manage Node.js versions and enjoy a smooth development experience on your M1 Mac.

By following these steps, you'll be well-prepared to tackle your software development projects on your Mac with confidence. Happy coding!

Installing Homebrew on Apple Silicon: A Step-by-Step Guide

Deepanshu Jangra — Sun, 01 Oct 2023 08:29:18 +0000

As a software developer, having the right tools at your disposal is essential. Homebrew is a popular package manager for macOS that simplifies the process of installing and managing software packages. If you're using an Apple Silicon-based Mac, you might encounter some specific steps during the installation process. In this guide, we'll walk you through the steps to install Homebrew on Apple Silicon, ensuring a smooth and hassle-free experience.

Step 1: Open a Terminal Window

To get started, open a terminal window. Make sure you're using the zsh shell, which is the default shell on macOS.

Step 2: Run the Installation Command

Copy and paste the following command into your terminal and press Enter:

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
This command will begin the Homebrew installation process. During the installation, if you encounter any errors, don't worry; we'll address them shortly.

Step 3: Handle Installation Errors

In some cases, you might encounter errors during the installation process. If this happens, you can try running the installation command again. In most cases, running it a second time resolves the issue.

After successful installation, you will likely see a message indicating "Installation successful!" However, you may also see a warning that "/opt/homebrew/bin is not in your PATH." We'll fix this in the next steps.

Step 4: Create the .zshrc File

If you don't already have a .zshrc file in your home directory, you can create one by running the following command:

touch ~/.zshrc

This command will create the .zshrc file if it doesn't already exist.

Step 5: Edit the .zshrc File

Open the .zshrc file for editing using your preferred text editor. You can use TextEdit or any text editor of your choice. The .zshrc file is a hidden file, so you can reveal hidden files in Finder by pressing Shift + Command + Period (⇧⌘.).

Add the following line at the end of the .zshrc file:

export PATH=/opt/homebrew/bin:$PATH

This line adds the Homebrew bin directory to your PATH environment variable, allowing you to use Homebrew commands system-wide.

Step 6: Source the .zshrc File

To make the changes in your .zshrc file take effect, run the following command in your terminal:

source ~/.zshrc

This command reloads your shell configuration with the updated PATH variable.

Step 7: Verify Homebrew Installation

To ensure that Homebrew is correctly installed and configured, run the following command:

brew help

If Homebrew is installed and set up correctly, you will see a list of available Homebrew commands and options.

Conclusion:

Congratulations! You've successfully installed Homebrew on your Apple Silicon-based Mac and configured it to work seamlessly. Now you can use Homebrew to install and manage software packages with ease, making your development tasks more efficient.

By following these steps, you'll have Homebrew up and running, ready to help you with your software development projects. Enjoy the convenience of package management on your Apple Silicon Mac!