I think at this point (based on discussion above) that you're getting a bit mixed up with what it means to be "on a branch", etc.
Deep inside git, when you do a
git checkout NAME, git resolves
NAME to a particular, specific commit. That commit is attached to a "tree"—a directory tree full of files—and checkout attempts to get that specific tree into your work-tree (while not clobbering any unsaved files, etc., but let's assume that your work tree is pristine in all cases, to simplify things here).
The other thing
checkout does is, if the name is one of your own branch-names, it records your "current branch" as the
HEAD. However, it's possible for that name not to name "your" branch. This is true if you check out an explicit "remote" branch:
$ git checkout remotes/origin/master
Note: checking out 'remotes/origin/master'.
You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.
If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:
git checkout -b new_branch_name
HEAD is now at fb4a1b2... (some commit message)
This is also what happens if you check out an explicit tag:
$ git checkout v1.0
Previous HEAD position was fb4a1b2... (some commit message)
HEAD is now at cfb9904... (another commit message)
In all of these cases, you have a perfectly good work tree that is what is represented by those particular commit IDs. You are just no longer "on a branch" at all ('detached HEAD' state). (You can "get back on a branch" by checking out some local branch, or by creating a new local branch with
git checkout -b newname whose tip is then what
HEAD is now at ...)
Now, say you have some "remote branch" that you are intentionally tracking:
$ git checkout GRONKLE # my local branch, which tracks remotes/origin/GRONKLE
$ git pull
The "pull" here consists of a fetch plus a merge. The "fetch" step uses the appropriate underlying transport to bring over any new commits on the remote branch. That gets you "what they did". The "merge" step then tries to apply "what they did" to "what you have" in your local branch.
Let's say, for example, that "what you have" was completely in sync with "what they did" yesterday. Then, today, you changed dir1/file1 and dir1/file2 (and committed that). Meanwhile, "they" changed dir2/file3 (and committed that into your remotes/origin repo). When you do a "git fetch", that gets their updates to dir2/file3 and makes
remotes/origin/GRONKLE name "what they have". Your branch is now
behind ... by 1 commit.
When you continue on to do a "git merge", however, that applies their changes to dir2/file3, but also keeps your changes to dir1/file1 and dir1/file2. This gives you a new commit, which is the "merge commit". Your branch is now ahead by one commit.
If you want to build "what they have"—which is what you said in the original question—then you don't want your changes to dir1/file1 and dir1/file2 sitting around. You can simply check out
remotes/origin/GRONKLE (in this example) and you will have precisely what they gave you, no more and no less.
If you want to build "what they have, plus what I have", then you need to merge and/or rebase, as @Adam Dymitruk said. But that's not "what they have". And—in response to your response to him—you're never "on a tag" at all. A tag is just the name of a specific commit, and if you check out that tag, you're in that same "detached HEAD" state yet again. If you want to make changes to "a new branch that begins where that tag begins" (see footnote), you need to create said new branch, starting from that tag.
If you want to create a new (local) branch starting from some given commit, there are two easy ways:
$ git checkout <commit>
(you're now on that commit and can look around and see if that's really the one you want) followed by:
$ git checkout -b new_local_branch
Or, if you're sufficiently sure of your starting point:
$ git checkout -b new_local_branch <commit>
(and about a half dozen more ways, using
git branch, but the above two suffice).
Footnote: branches don't really "begin" anywhere, after all is said and done. More precisely, you get yourself a starting point—by checking out some particular commit-ID—and do any work you like from there forward, making new commits, etc., but once you put a branch label to remember that work, the branch label simply follows the "tip" of that work. Until then, if you're in "detached HEAD" state, the primary reference to any new commits you make is your detached HEAD. It's easy to "lose hold" of that reference, though, if you
make a new branch, although if you poke around inside git you can find all the extra places it saves things for you, typically for up to three months.