Avoiding the problem
The best way to avoid pushing either the wrong branch or to the wrong destination is to establish the habit of ALWAYS using the two arguments form of push:
git push <repository> <refspec>
(where refspec 99% of the time is a branch name). This way you always will specify exactly what you are pushing, and exactly where you are pushing it. There is no room for any surprises1.
Number of remotes
Now with regards to disassociate your code from the upstream source where it originated from, there is no need to do that and normally it is beneficial to keep traces of the lineage.
Git supports having as many remotes associated with a repository as you like, and when you always push by explicitly specifying the remote destination, then it does not matter if you have dozens of other potential remote destinations.
From git's perspective the names of the remotes are without any specific meaning, but from a mental perspective it is best to be consistent and use origin as the remote you want to push thing to instead of using different names in different repositories. I use the remote name upstream for the repository that is the source for a fork. And if add additional forks I normally use the userhandle (e.g. from https://github.com/userhandle/...) as remote name.
Example
I have a fork of Michael's git-test repository and when I run git remote -v inside my local clone I get
origin git@github.com:hlovdal/git-test.git (fetch)
origin git@github.com:hlovdal/git-test.git (push)
upstream https://github.com/mhagger/git-test (fetch)
upstream https://github.com/mhagger/git-test (push)
So whenever I have some branch I have been working on and want to push to my fork I run git push origin documentation_update or similar (if I ever wanted to push something directly to his repository the command would be git push upstream documentation_update, although I cannot see any use case for this).
What having the upstream remote available allows me to do is to get updates from the upstream project and incorporate into my fork, e.g.
git fetch upstream
git checkout master
git merge --ff upstream/master
git push origin master
git rebase master documentation_update
So having the fork source as a remote is normally very beneficial, I would not recommend skipping this.
Remedy
Now back to your situation with your angular-university repo. Assuming the following:
Given that, then there is no need to do anything as drastic as cloning your fork and start all over from a new clone.
Since you have cloned angular-university's repo it will by default end up as the origin remote, e.g. when you run git remote -v it will show
origin https://github.com/angular-university (fetch)
origin https://github.com/angular-university (push)
No problem, just rename it:
git remote rename origin upstream
and then add your fork:
git remote add origin git@github.com:apex2022/angular-course.git
Now your repository's origin remote points to your for like you want to, and you have access to the upstream repo for updates.
If you find having the upstream remote makes the view in gitk --all too noisy, you can always just delete it with git remote remove upstream, and when you want it back just run git remote add upstream https://github.com/angular-university.
One last thing to check is if any of your branches is set to track upstream instead of origin. Review them with
git config -l | grep '^branch.*remote='
and then if you want to change then run
git branch --set-upstrem-to=origin/my_branch_name my_branch_name
1 For the same reason I NEVER run rebase with anything less that two arguments (e.g. git rebase onto_ref branch_to_be_rebased, sometimes three: git rebase --onto onto_ref starting_ref branch_to_be_rebased).
