In fact, it's rather awkward to have separate fetch and push URLs for same remote (you can do it, but it's not the typical way to achieve what you're asking for). Typically you'd add another remote, and then push to that remote.
git remote set-url origin https://gitlab.com/myName/railsgoat.git
git remote add upstream https://github.com/OWASP/railsgoat.git
then you will use
git fetch upstream
to get changes from upstream repo and
git push origin
to push to your fork.
The names upstream
and origin
are not set in stone, though these are typical names used by the community. You can name upstream
something else, it's just an identifier. origin
is the name of remote given to the one from which you originally cloned.
The convention is to use origin
for something you control (your fork), and upstream
for something you don't control (central repo).
Then, the next concept is the "upstream branch" for a given branch (the naming is confusing).
Basically, git push
needs to know to which branch you want to push from and to (git is overly flexible in this case which can be daunting at the beginning).
Say you want to push from master
to origin/master
, and you always want git push
in the future (when in master
) to do the same, you'd do:
git push -u origin master
(-u
is a shorthand for --set-upstream
, which you can later edit via --set-upstream-to
, which makes git remember that the branch you push to right now is the default branch to be used in the future).
Once done, you can in the future use just
git push
One more note, if for some reason you're using git 1.x still, it's recommended to execute this
git config --global push.default simple
to change the behavior of what git push
does (read more here)
To do the exact thing you were asking for, you'd do
git remote set-url --push origin https://gitlab.com/myName/railsgoat.git