The easiest way, by far, is: don't. That is, don't try to do this, this way, at all. Do it another way.
If you have Git version 2.15 or later—or even 2.5 or later—you have a command, git worktree, with sub-commands. One of the sub-commands is git worktree add. This needs the name of another branch, e.g., other-branch, as an argument, and also the name of a place to create a new work-tree, in the other order:
git worktree add ../auxiliary other-branch
(assuming ../auxiliary gets you to a place where Git can mkdir auxiliary outside of your existing work-tree; /home/user/another-workdir/ is probably fine as well).
So: use git worktree add to create a new work-tree as shown here. This new work-tree is all new, so there are no files that you could overwrite. The new work-tree gets a new index, too, so that the index/work-tree pair that cover your main work-tree, the one where you're on branch master, is totally independent of the new index/work-tree pair for this other branch.
You can now start a new shell window, or pushd ../auxiliary, or whatever you like to get into the new work-tree that's on the independent branch.1 Here, you can copy the files from the main work-tree, git add, and git commit. It's like having a separate repository, except that the commit goes into the (shared) repository, updating the (shared) branch name other-branch in the main repository automatically, with no separate git fetch step required.
If you have a Git that is >= 2.5 but < 2.15, finish all this work and then go back to the main repository within 14 days, and use rm -rf ../auxiliary (or wherever you stored the repository) and git worktree prune. This will sidestep a nasty bug: these versions of Git fail to check for references in the added work-trees and can discard objects that are in use when running a git gc (from either work-tree!). If your Git is 2.15 or later, the bug is fixed and there's no need to clean up, although you might want to anyway.
1"Orphan branch" is not a great term for this, as Git uses it specifically to talk about the setup in which you are on a branch name that does not exist, made by running git checkout --orphan. That name ceases to be an "orphan" as soon as you commit from this state. The checkout command calls it an orphan branch and git status calls it a an unborn branch, so Git itself is a little confused as to what the right term is.
In your case, though, the branch name other-branch does exist, and points to some existing commit. It's just that the commit to which the branch name points, and all of its ancestors, lead back to a different root commit and not to a root commit shared with the tip commit of master. So, "unrelated" might be a good term, or "independent" as I used here, or "differently-DAG-ged" to be a bit technical.
