Setting your branch to exactly match the remote branch can be done in two steps:

git fetch origin
git reset --hard origin/master

If you want to save your current branch's state before doing this (just in case), you can do:

git commit -a -m "Saving my work, just in case"
git branch my-saved-work

Now your work is saved on the branch "my-saved-work" in case you decide you want it back (or want to look at it later or diff it against your updated branch).

Note: the first example assumes that the remote repo's name is origin and that the branch named master in the remote repo matches the currently checked-out branch in your local repo, since that is in line with the example given in the question. If you are trying to reset to the default branch in a more recent repository, it is likely that it will be main.

BTW, this situation that you're in looks an awful lot like a common case where a push has been done into the currently checked out branch of a non-bare repository. Did you recently push into your local repo? If not, then no worries -- something else must have caused these files to unexpectedly end up modified. Otherwise, you should be aware that it's not recommended to push into a non-bare repository (and not into the currently checked-out branch, in particular).

First, view the existing remotes to verify which URL is currently set:

git remote -v

Then, you can set it with:

git remote set-url origin <NEW_GIT_URL_HERE>

See git help remote. You also can edit .git/config and change the URLs there.

You're not in any danger of losing history unless you do something very silly (and if you're worried, just make a copy of your repo, since your repo is your history.)

Updating the (push) entry:

When running git remote -v you'll usually see 2 entries that look like this:

origin  git@github.com:username/repo_name.git (fetch)
origin  git@github.com:username/repo_name.git (push)

You can optionally update the (push) URI by running:

git remote set-url --push origin <NEW_GIT_URL_HERE>

After updating, you'll have 2 different URIs for the 2 entries so you'll be fetching/pulling from one source and pushing to another source:

origin  git@github.com:username/repo_name.git (fetch)
origin  git@github.com:another_username/another_repo_name.git (push)

Assuming that your branch is called master both here and remotely, and that your remote is called origin you could do:

 git reset --hard <commit-hash>
 git push -f origin master

However, you should avoid doing this if anyone else is working with your remote repository and has pulled your changes. In that case, it would be better to revert the commits that you don't want, then push as normal.

Update: you've explained below that other people have pulled the changes that you've pushed, so it's better to create a new commit that reverts all of those changes. There's a nice explanation of your options for doing this in this answer from Jakub Narębski. Which one is most convenient depends on how many commits you want to revert, and which method makes most sense to you.

Since from your question it's clear that you have already used git reset --hard to reset your master branch, you may need to start by using git reset --hard ORIG_HEAD to move your branch back to where it was before. (As always with git reset --hard, make sure that git status is clean, that you're on the right branch and that you're aware of git reflog as a tool to recover apparently lost commits.) You should also check that ORIG_HEAD points to the right commit, with git show ORIG_HEAD.

Troubleshooting:

If you get a message like "! [remote rejected] a60f7d85 -> master (pre-receive hook declined)"

then you have to allow branch history rewriting for the specific branch. In BitBucket for example it said "Rewriting branch history is not allowed". There is a checkbox named Allow rewriting branch history which you have to check.

If you haven't pushed to origin yet, you can reset your branch to the upstream branch with:

git checkout mybranch
git reset --hard origin/mybranch

(Make sure that you reference your latest commit in a separate branch, like you mention in your question)

Note that just after the reset, mybranch@{1} refers to the old commit, before reset.

But if you had already pushed, see "Create git branch, and revert original to upstream state" for other options.

With Git 2.23 (August 2019), that would be one command: git switch.
Namely: git switch -C mybranch origin/mybranch

Example

C:\Users\vonc\git\git>git switch -C master origin/master
Reset branch 'master'
Branch 'master' set up to track remote branch 'master' from 'origin'.
Your branch is up to date with 'origin/master'.

That restores the index and working tree, like a git reset --hard would.

As commented by Brad Herman, a reset --hard would remove any new file or reset modified file to HEAD.

Actually, to be sure you start from a "clean slate", a git clean -f -d after the reset would ensure a working tree exactly identical to the branch you just reset to.

This blog post suggests those aliases (for master branch only, but you can adapt/extend those):

[alias]
   resetorigin = !git fetch origin && git reset --hard origin/master && git clean -f -d
   resetupstream = !git fetch upstream && git reset --hard upstream/master && git clean -f -d

Then you can type:

git resetupstream

or

git resetorigin

Git supports this command:

git checkout -B master origin/master

Check out the origin/master branch and then reset master branch there.

UPDATE:
Or you can use new switch command for that

git switch -C master origin/master