Git tag release build files and reset to commit without
It's a very nicely written script.


  It's working great, but is having a tag that refers to an overridden commit a good idea?


It doesn't sound great, but I don't have a better idea either.
In any case, I don't see any harm in doing this.
The content of these commits don't pollute the history because they are not really part of it.

If repository storage becomes a problem later,
you can always wipe out the obsolete tags.
(As you mentioned in a comment, this might not be such a good idea if package managers (like bower) rely on git tags for dependencies...)

Error handling

What if gulp fails? The script will happily go ahead and publish something broken or half-baked.
It would be good to add some error handling here, for example:

if ! gulp; then
    echo "Fatal: gulp failed, aborting..."
    exit 1
fi


Code duplication

This line appears twice:


newver=$(npm --no-git-tag-version version $1)



As it's a non-trivial command,
it would be good to put it in a function, for example:

set_newver() {
    newver=$(npm --no-git-tag-version version $1)
}


Naming

It's good to give command line parameters a proper name early on,
and refer to them by that name throughout the script,
instead of a meaningless $1. For example version.

This may be subjective, but I find newver a bit awkward,
and perhaps npm_version would be better. I leave that up to you.