I started on a complete answer, but it got way too long.
To answer just a few specifics, your concerns are real but slightly misguided (not your fault as much Git documentation is terrible). The crucial issue is not so much what git fetch fetches,1 it's what is in the commit graph of the commits you merge with git merge; and which commits get copied when you choose to run git rebase, which depend, again, on the commit graph, and on the arguments you supply to git rebase.
The key concept is reachability. Names like origin/master (which git fetch updates) make commits reachable, but commits (which git fetch brings in) also make other commits reachable. A reachable commit makes the entire chain of commits "before" that commit reachable. Merge commits, which list more than one parent commit ID, make two (or more) chains of commits reachable.
1Of course, what git fetch doesn't fetch, can't possibly be reached (in your copy of the repo), since it does not exist (in your copy of the repo). I suspect that's what you are aiming for here, but it's difficult to achieve in general, and unnecessary anyway.
Remember that (1) each commit is identified by its SHA-1 hash ID, (2) each commit contains the hash ID(s) of its parent commit(s), and (3) branch names are just names for one commit ID. The branch name gets a new ID stuffed into it frequently, to grow the branch (to add a regular or merge commit), or to point to commits copied by rebase.
Then, remember that git rebase works by copying commits. The copies have new, different IDs:
A--B--C [original mybranch, before rebase]
/
...--o--o
\
o--o <-- origin/theirbranch
\
A'-B'-C' <-- mybranch [after rebase]
This is guaranteed to be fine as long as no one else has names (branch or tag names) or commits that point to any of the original commits A, B, or C. If they do have such names, those existing names may—or may not—continue to point back to the originals, not to the new copies. Even that is fine as long as you don't use them now. If and when the names are updated to point to new commits, the old ones become irrelevant as long as no still-reachable commits point to the old commits. If existing commits point to "outdated" commits, though, those commits will continue to point to them forever, since commits are permanent.2
2No Git object can ever change. This is a fundamental guarantee that Git makes. However, all Git objects, including commits, that are completely unreachable are eventually removed. Git has a "garbage collector", git gc, that does this. It's a bit complicated as there are numerous grace period tricks to keep objects around: everything gets 14 days by default, and references—including branch, tag, and remote-tracking branch names—may have reflog entries, which make otherwise-unreachable commits reachable again. The reflog entries themselves persist for either 30 days or 90 days by default, depending on yet another reachability computation, comparing the current hash value in the reference to the hash in the reflog entry. The garbage collector is normally invoked automatically whenever Git thinks this might be a good idea.
On fetch
For instance, suppose that your git fetch brings in, to your repository, origin/BobsBranch and it points to some commits:
B1-B2-B3 <-- origin/BobsBranch
/
...--o--o <-- origin/develop
\
C1-C2-C3 <-- my_independent_work
You can rebase your work whenever you like. Meanwhile Bob can rebase BobsBranch (though he may need to force-push the result to the server). Let's say he throws out those three commits entirely in favor of one new B4 commit. You run git fetch and pick up a new, different origin/BobsBranch; your repository now has:
B4 <-- origin/BobsBranch
/
| B1-B2-B3 [a reflog entry for origin/BobsBranch]
|/
...--o--o <-- origin/develop
\
C1-C2-C3 <-- my_independent_work
The reflog-only commits won't show up in git log --all or gitk --all views, and as long as you never use any of these B* commits, they do not harm you in any way (well, they do take up a bit of space in your repository).
To avoid bringing them over even though they are harmless, you can run git fetch with instructions to avoid bringing them over. When you run the git pull convenience command, git pull runs git fetch with instructions to bring over only one origin/whatever branch's reachable commits, so that usually avoids bringing them over—unless, of course, they're reachable from something your Git does need, based on the one branch tip.
On merge
A "bad" case occurs when you merge in a commit that "reaches" a commit that is later copied by rebase. For instance, suppose you have this:
...--o--o--A--B <-- origin/feature_X
\
C--D <-- feature_Y
Now you decide it is time to merge origin/feature_X's commits (A and B) into your feature_Y, so you make a merge commit:
...--o--o--A--B <-- origin/feature_X
\ \
C--D--o <-- feature_Y
If someone else (upstream) decides to rebase and force-push their feature_X, so that your origin/feature_X points to new copies, you end up with this:
o--A'-B' <-- origin/feature_X
/
...--o--o--A--B
\ \
C--D--o <-- feature_Y
That can happen even if there was no name attached to the rebase-copied commits, if you picked up something else by its name. For instance, if someone else pushed feature_F and promised it was done:
A----B
/ \
...--o--o--E--F <-- origin/feature_F
\
C--D <-- feature_Y
and you then merge it, you get this:
A----B
/ \
...--o--o--E--F <-- origin/feature_F
\ \
C--D--o <-- feature_Y
Now suppose they, or a third person, then rebase a branch they have that points to B, without realizing / remembering that commit F itself also points to B. That is, they start with this (note that they do not have your feature_Y):
A----B <-- myhacks
/ \
...--o--o--E--F <-- feature_F, origin/feature_F
Then then decide that it would be better to rebase myhacks onto commit E, so they run:
$ git checkout myhacks
$ git rebase 123e4567 # <id-of-E>
which produces:
A----B
/ \
...--o--o--E--F <-- feature_F, origin/feature_F
\
A'-B' <-- myhacks
Eventually, when you fetch (perhaps via git pull) and get their final version of myhacks—whether or not it has a name at that time, as long as it has commits A' and B'—you will have (and retain) the original A--B commits, through commit F, and add the A'-B' chain, even though you may never have seen their branch-name myhacks.
Conclusion
The "bad" case we saw above happened when git fetch brought in commit F, via the name (in the repository you're fetching from, presumably one stored on a central server) feature_F. (You and your Git renamed this origin/feature_F.) The problem was not feature_F (or origin/feature_F) itself, though, but rather myhacks: a name neither you, nor the central server, ever saw! The person who did have that name—or maybe even made it up after the fact—used it to copy commits A and B, without thinking about who had the originals. He then pushed the copies, maybe under yet another name.
The names matter at fetch and push time because git fetch and git push transfer commits by refspecs (mostly just pairs of reference names, plus some ancillary stuff). Before and after that point, though, the names are mainly distractions: it's the set of commits, as named by their IDs, and their reachability status, that matters.
featureondevelopor mergingdevelopintofeaturewill have the same end result with regard to any new changes fromdevelopbeing brought into yourfeaturebranch. By the way, you casually mentioned rebasing without giving a compelling reason for using it over merging. Rebasing is useful when you want to keep the history ofdeveloplinear, but you may not have a need for this. - Tim Biegeleisenwe will merge with a non fast forward commit... the whole point of rebasingfeatureondevelopis so that you can fast forwarddevelopwith all the new commits fromfeature. Otherwise, you might as well just merge. - Tim Biegeleisen