git checkout master path/to/default.aspx.cs

Before doing this, you probably have to : git checkout redesign

So, just git checkout FROM_BRANCH_NAME path/to/file

You can use the 'ours' merge strategy:

$ git checkout staging
$ git merge -s ours email # Merge branches, but use our (=staging) branch head
$ git checkout email
$ git merge staging

The question requires the commits of the email branch to be kept. They must not be made unreachable, which rules out any reset-based approaches or deleting and recreating the branch.

I no longer need the old changes in email branch, yet I don't want to delete them.

To keep commits of both branches reachable, one or more references must exist that point to those commits. You can always keep two references (staging and email), but the question asks to get rid of one of the refs. Therefore, the branches need to be merged somehow.

EDIT 2020-07-30:

I thought a bit more about this question and possible solutions. If you absolutely require the merge parents in the correct order, need to perform this action with a single command line invocation, and don't mind running plumbing commands, you can do the following:

$ git checkout A
$ git merge --ff-only $(git commit-tree -m "Throw away branch 'A'" -p A -p B B^{tree})

This basically acts like the (non-existent) merge -s theirs strategy. You can find the resulting history in the plumbing branch of the demo repository

Not very readable and not as easy to remember compared to the -s ours switch, but it does the job. The resulting tree is again the same as branch B:

$ git rev-parse A^{tree} B^{tree} HEAD^{tree}
3859ea064e85b2291d189e798bfa1bff87f51f3e
0389f8f2a3e560b639d82597a7bc5489a4c96d44
0389f8f2a3e560b639d82597a7bc5489a4c96d44

EDIT 2020-07-29:

There seems to be a lot of confusion as to what the difference between -s ours and -X ours (the latter being equivalent to -s recursive --strategy-option ours) is. Here's a small example to show the two results from using these two methods. I also recommend reading the question and answers of (Git Merging) When to use 'ours' strategy, 'ours' option and 'theirs' option?

First, setup a repository with 2 branches and 3 commits (1 base commit, and 1 commit per branch). You can find the sample repository on GitHub

$ git init
$ echo 'original' | tee file1 file2 file3
$ git commit -m 'initial commit'
$ git branch A
$ git branch B
$ git checkout A
$ echo 'A' > file1
$ git commit -m 'change on branch A' file1
$ git checkout B
$ echo 'B' > file2
$ git commit -m 'change on branch B' file2

Now, let's try the strategy option (doesn't really matter if we use theirs or ours for this explanation):

$ git merge -X ours A
$ cat file*
A
B
original

We end up with a merge of both branches' contents (branch "strategy-option" in the sample repo). Compare that to using the merge strategy (re-init your repository or reset branch, before executing the next steps):

$ git merge -s ours A
$ cat file*
original
B
original

The result is quite different (branch "merge-strategy" in the sample repo). With the strategy option, we get a merge result of both branches, with the strategy we throw away any changes which happened in the other branch.

You will also notice that the commit created by the merge-strategy in fact points to the exact same tree as the latest commit of "our" branch, while the strategy-option created a new, previously-unseen tree:

$ git rev-parse A^{tree} B^{tree} merge-strategy^{tree} strategy-option^{tree}
3859ea064e85b2291d189e798bfa1bff87f51f3e
0389f8f2a3e560b639d82597a7bc5489a4c96d44
0389f8f2a3e560b639d82597a7bc5489a4c96d44
5b09d34a37a183723b409d25268c8cb4d073206e

OP indeed asked for "I no longer need the old changes in […] branch" and "So I just want to dump all the contents of [A] into [B]", which is not possible to do with a strategy option. Using the 'ours' merge strategy is one possibility of many, but likely the easiest (other possibilities include using low level commands of Git such as write-tree and commit-tree).

You can bring over the file exactly as it is in another branch like this:

git checkout the-other-branch -- the-file

Then you can commit it if you want. It will hold no metadata about where it is coming from, just in case.

If what you want is copy a file so that it is saved with a different name, then it is like this:

git show the-other-branch:the-file > file-name-i-want
git add filename-i-want

Then you can commit. Then, just like in my previous example, there will be no metadata about where the file is coming from. It is just like you had written that file from scratch without help from git and then added/committed it.

If you want all changes from master in dev_branch, then:

git switch dev_branch
git reset --hard master

If you have dev_branch pushed to a remote already, you have to do:

git push --force

To force-push the branch to the remote. Warning: This will break the history of the branch for people who cloned it before! Then, other people will have to do a git pull --rebase on the dev_branch to get the changes.

You can also rename the dev branch to something old and then make a new branch from master with the same name:

git branch -m dev_branch old_dev_branch
git branch -m master dev_branch

Or, use the ours strategy — not sure why it wouldn't work for you:

git checkout master
git merge -s ours dev_branch
git checkout dev_branch
git merge master

It sounds like what you want is to have the passed branch point to the exact same commit as develop once the tests have passed.

You can do it with git branch --force:

git branch --force passed develop

Here's from the git branch documentation:

-f
--force
Reset <branchname> to <startpoint> if <branchname> exists already. Without -f git branch refuses to change an existing branch.

I want my feature branch HEAD to be 42bb

git checkout feature 
# standard warning about reset --hard being working directory unsafe 
git reset --hard HEAD

may be a new commit on feature branch which is equal to 42bb commit

This one is a little more complex.

git commit-tree -p feature -m "commit msg" 42bb^{tree}

That will create a commit parented by 161a with the tree contents of 42bb. You'd need to update feature branch to point to the returned SHA with git update-ref

git checkout main                 # first get back to main
git checkout experiment -- app.js # then copy the version of app.js 
                                  # from branch "experiment"

See also Undo working copy modifications of one file in Git.

Update August 2019, Git 2.23

With the new git switch and git restore commands, that would be:

git switch main
git restore --source experiment -- app.js

By default, only the working tree is restored.
If you want to update the index as well (meaning restore the file content, and add it to the index in one command):

git restore --source experiment --staged --worktree -- app.js
# shorter:
git restore -s experiment -SW -- app.js

As Jakub Narębski mentions in the comments:

git show experiment:path/to/app.js > path/to/app.js

works too, except that, as detailed in the SO question "How to retrieve a single file from specific revision in Git?", you need to use the full path from the root directory of the repo.
Hence the path/to/app.js used by Jakub in his example.

As Frosty mentions in the comment:

you will only get the most recent state of app.js

But, for git checkout or git show, you can actually reference any revision you want, as illustrated in the SO question "git checkout revision of a file in git gui":

$ git show $REVISION:$FILENAME
$ git checkout $REVISION -- $FILENAME

would be the same is $FILENAME is a full path of a versioned file.

$REVISION can be as shown in git rev-parse:

experiment@{yesterday}:app.js # app.js as it was yesterday 
experiment^:app.js            # app.js on the first commit parent
experiment@{2}:app.js         # app.js two commits ago

and so on.

schmijos adds in the comments:

you also can do this from a stash:

git checkout stash -- app.js

This is very useful if you're working on two branches and don't want to commit.

You can reset it into the feature branch you want to continue.

1. Fetch and pull (It is optional but gives you an essence of current code state)

   git fetch
   # Usually develop is the default develop branch in git flow
   # Change into the appropriate name that indicated the branch for development
   git checkout develop
   git git pull origin develop
   

2. Create a new branch (Skip if you already done this step)

   git flow feature MYPROJECT_2311
   

3. reset in to the feature branch you want to continue

   git reset --hard feature/MYPROJECT_2322
   

4. (Optionally but due to slow deployments you may want to merge anything to latest changes)

   git merge develop
   

   In this case you may have some conflicts that you'll need to fix by yourself.