you should run this:
git config --global url.git@github.com:.insteadOf https://github.com/
why? let me tell you a tale of 2FA and submodules
2FA
You should set up 2FA on GitHub. You should, it's the virtuous, objectively correct decision as long as you own a phone. It increases the security of your account, and if you ever work a job that uses GitHub to manage their projects they will invariably require you to do so if they have a hint of sense.
The problem with this, is that GitHub 2FA (understandably) disables HTTPS write-access for git. No longer can git push to a remote using an HTTPS URI simply prompt you for your password, because you don't just have a password anymore! You have a 2FA code, and if they just ignored that for git pushes it'd be pretty dang useless.
Git Submodules
Look, you've probably heard a lot of things about git submodules. That they're dangerous, that they'll ruin your project if you use them wrong. That you should always use subtrees instead (this is a dumb opinion, please come to class with a better one tomorrow).
The fact is, submodules are dead useful. Maybe in an older version of git they were much scarier, maybe they do still have some sharp edges I just haven't bumped into too badly yet, but if you want to be able to iterate on a dependency at the same time as the project depending on it, they just work in so many ways.
Plus, for some languages you kind of need them to manage dependencies sanely (I am eagerly awaiting the Zig package manager. No, I will not use gyro).
The problem is, for submodules anyone who clones your repo and pulls the submodules will attempt to pull each submodule with the exact URI that you use to initialize the submodule. This means, if you initialize a submodule with git@github.com:repo/path.git then someone without a GitHub account or without SSH set up on GitHub will fail to pull the submodule.
WOMP WOMP
Since you, an enlightened GitHub 2FA user, can't actually push to an HTTPS remote, this presents a slight problem if you, y'know, actually want to work on any of the submodules.
Now, of course, there are steps a cloning user can take to resolve this. The command I show above but reversed is actually a somewhat common step taken to fix this issue. Unfortunately this command (and all other mitigating solutions I'm aware of) are fairly advanced git usage.
Do you want someone to have to be an advanced user to clone your repository? I don't.
Return with the Elixir
So. So, so, so, so, so. You have all the pieces now. You've drawn all 5 pieces of Exodia. You stand at the precipice of Mount Doom, ring in hand.
Do you see it yet? Have you divined the truth? Witnessed the four base elements at work and meditated upon the concept of aether?
It's simple. You run
git config --global url.git@github.com:.insteadOf https://github.com/
in your shell, and always add submodules with the HTTPS URL.
On your system, the HTTPS URL is rewritten to an SSH URI. You can push freely, like a bird in flight. On the cloning user's system, they call pull freely, grounded by the solid foundation of an HTTPS URL.
The chains shatter. You are free. You hold all of the power of submodules in your hands and none of the drawbacks.
...other than that one bit where you always forget to add --recurse-submodules to the git clone command. What a pain, yeah?
