In general, you can use the --strategy option to specify how conflicts should be handled. The strategy theirs blindly replaces files.

However, in your case, you've only got a single file. You really won't want to use the theirs strategy for all files. Instead, after you get the message to resolve the conflict, you can checkout that one specific file from the branch:

git checkout <branch> yourfile

(At that point, <branch> still refers to the branch as it was before the rebase started.)

It sounds like your working directory was dirty at the time you did your rebase. You should probably be prepared for your working directory and stage to be wiped when you do a rebase. As a workaround, if you find yourself with a non empty working directory and/or stage, but you need to rebase to the latest other branch, you could do a stash, i.e.

git stash

Git will make 2 (or even 3) commits to preserve your working directory and stage as they currently are. After the rebase is complete, you can get these changes back by applying the stash:

git stash apply

I think in some cases Git would not even allow you to do a merge or rebase depending on the state of your working directory and stage. But in any case, it might be a good idea to make sure they are clean before rebasing.

⚠ Warning:

Any uncommitted local change to tracked files will be lost, even if staged.

But any local file that's not tracked by Git will not be affected.

First, update all origin/<branch> refs to latest:

git fetch --all

Backup your current branch (e.g. main):

git branch backup-main

Jump to the latest commit on origin/main and checkout those files:

git reset --hard origin/main

Explanation:

git fetch downloads the latest from remote without trying to merge or rebase anything.

git reset resets the master branch to what you just fetched. The --hard option changes all the files in your working tree to match the files in origin/main.

Maintain current local commits

^[*]: It's worth noting that it is possible to maintain current local commits by creating a branch from main before resetting:

git checkout main
git branch new-branch-to-save-current-commits
git fetch --all
git reset --hard origin/main

After this, all of the old commits will be kept in new-branch-to-save-current-commits.

Uncommitted changes

Uncommitted changes, even if staged (with git add), will be lost. Make sure to stash or commit anything you need. For example, run the following:

git stash

And later (after git reset), reapply these uncommitted changes:

git stash pop

Which may create merge conflicts.

You generally never rebase master on top of another branch (which was most likely created from master)

so it is completely replaced by my dev branch?

The git reset --hard origin/dev should be enough (assuming you are on master), followed by a git push --force, provided you clearly communicate to any user of that repo they need to reset they own local master to the new history.

Make sure you don't have any pending modification.