There are many terms in Git that are confusing, and though it's obvious what you mean from your question, based on the discussion in the comments I think it's important to get the proper terminology.
You used the term "parent branch" to mean develop because that's the branch you created your branch myBranch from, which makes sense in "English". In Git though, branches are just pointers to a commit. So it's better to think, "I created myBranch from commit X." Or, "I created myBranch from develop when develop was pointing to commit X." It's actually the commit X that matters, not develop. This is why the concept of "parent branch" doesn't exist in Git.
The next thing to understand is your local branch develop doesn't stop pointing to it's tip commit until you tell it to. This is why when you tried to update myBranch by merging in develop it didn't work, as you explained:
git merge develop just gives me an "Already up to date" message.
Usually people update their own copy of develop by doing something like this:
git checkout develop
git pull
And at that point your local copy of develop will be the same as your copy of origin/develop which will be the same as the remote version of develop. After doing that you can then merge develop into your branch to bring in the desired changes.
Note, I personally recommend not using develop anymore for this very reason- because it goes out of date quickly and you'll surely forget to keep updating it. Instead you can regularly use git fetch to update your "remote tracking branches" (those that start with origin/*) and then you can create all of your new branches from origin/develop instead, like this:
git fetch
git switch -c myNewBranch origin/develop --no-track
When it's time to update your branch, like you wish to do now, you can use:
git checkout myBranch
git fetch
git merge origin/develop
If you're willing to start doing that you can just delete your local copy of develop and always use origin/develop from now on.
As for the other way of updating your branch, using rebase, the way it's phrased:
rebase myBranch onto the lastest develop branch
does make it seem like you are updating the develop branch, but you are actually just going to update your own branch. The reason the word "onto" is used is because with rebase, you are going to take some range of commits from your branch, and "replay" them "onto" some other commit. (Note when we say "replay" you can think of this as "rewrite" those commits to make brand new commits with new IDs.)
To rebase, you could do this:
git checkout myBranch
git fetch
git rebase origin/develop
Or, a shorthand that automatically does the checkout for you:
git fetch
git rebase origin/develop myBranch
In words, that says:
Take all of the commits on myBranch that are not reachable by origin/develop and replay all of them, one by one, onto origin/develop.
The end result is myBranch will be rewritten to look like you just branched off of the latest develop right now and made your commits, with the exception that your commits will keep their original author and author dates, so those dates might actually be older than the latest commits showing on your branch after those. (But every commit actually has 2 dates, so the committer dates will be "now".)
So now we know you can update your branch by merging in the latest develop, or by rebasing onto the latest develop. For completeness, note you can also do both of these by using the pull command if you wish:
git checkout myBranch
# do the same as fetch, and then merge in origin/develop
# This assumes you did not override the default behavior of the "pull" command,
# which is "merge" by default.
git pull origin develop
# OR
# do the same as fetch and rebase
git pull --rebase origin develop
Note the first option is what has already been provided by Sutariya Sumit's answer. This is a fine way to accomplish what you want, and is why:
My coworkers are telling me to "pull the changes onto my branch."
That being said, my personal preference is not to use the pull command, but instead use the explicit merge or rebase commands provided above, as you can inspect what you got with the fetch before doing the merge or rebase.
