私は2本の枝を持っている、emailとstaging。stagingは最新のものであり、emailブランチの古い変更は不要になりましたが、削除したくありません。

私はただのすべての内容をダンプするようstagingにemailので、彼らは同じに両方のポイントコミットしていること。それは可能ですか？

「ours」マージ戦略を使用できます。

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

2つのブランチ「email」と「staging」を同じにしたい場合は、「email」ブランチにタグを付けてから、「email」ブランチを「staging」ブランチにリセットします。

$ git checkout email
$ git tag old-email-branch
$ git reset --hard staging

'staging'ブランチを 'email'ブランチにリベースすることもできます。ただし、結果には2つのブランチの変更が含まれます。

私はいくつかの回答を見てきましたが、これが競合なしに修正できる唯一の手順です。

branch_oldのbranch_newからのすべての変更が必要な場合：

git checkout branch_new
git merge -s ours branch_old
git checkout branch_old
git merge branch_new

これらの4つのコマンドを適用すると、問題なくbranch_oldをプッシュできます。

他の答えは私に正しい手がかりを与えましたが、それらは完全に助けにはなりませんでした。

これが私のために働いたものです：

$ git checkout email
$ git tag old-email-branch # This is optional
$ git reset --hard staging
$
$ # Using a custom commit message for the merge below
$ git merge -m 'Merge -s our where _ours_ is the branch staging' -s ours origin/email
$ git push origin email

私たちの戦略とマージする4番目のステップがないと、プッシュは早送りではないと見なされ、拒否されます（GitHubによって）。

あなたが私のようなものであり、マージに対処したくない場合は、上記の手順を実行できますが、マージの代わりにforceを使用します。

git checkout email
git reset --hard staging
git push origin email --force

注：これは、本当にメールの内容を二度と見たくない場合のみです。

2つのブランチをマージして、すべてのコンテンツをのコンテンツでold_branch更新したかったnew_branch

私にとってこれは魅力のように機能しました：

$ git checkout new_branch
$ git merge -m 'merge message' -s ours origin/old_branch
$ git checkout old_branch
$ git merge new_branch
$ git push origin old_branch

どうですか：

git branch -D email
git checkout staging
git checkout -b email
git push origin email --force-with-lease

他の回答は不完全に見えました。
私は完全に以下を試しました、そしてそれはうまくいきました。

注意：
1.安全のため、以下を試す前にリポジトリのコピーを作成してください。

詳細：
1.すべての開発はdevブランチで行われます
2. qaブランチはdevの同じコピーです
3.時々、コードはqaブランチに移動/上書きする必要があります

したがって、開発ブランチからqaブランチを上書きする必要があります

パート1：
以下のコマンドで、古いqaが新しい開発に更新されました：

git checkout dev
git merge -s ours qa
git checkout qa
git merge dev
git push

最後のプッシュの自動コメントは以下になります：

// Output:
//  *<MYNAME> Merge branch 'qa' into dev,*  

上記のシーケンスも逆に見えるため、このコメントは逆に見えます

パート2：

以下は、devでの予期しない新しいローカルコミットであり、不要なものである
ので、捨てて、devをそのままにする必要があります。

git checkout dev

// Output:
//  Switched to branch 'dev'  
//  Your branch is ahead of 'origin/dev' by 15 commits.  
//  (use "git push" to publish your local commits)


git reset --hard origin/dev  

//  Now we threw away the unexpected commits

パート3：
すべてが期待どおりであることを確認します。

git status  

// Output:
//  *On branch dev  
//  Your branch is up-to-date with 'origin/dev'.  
//  nothing to commit, working tree clean*  

それで全部です。
1.古いqaが新しいdevブランチコードによって上書きされるようになりました
2.ローカルがクリーンです（リモートorigin / devはそのままです）

それを行う最も簡単な方法：

//the branch you want to overwrite
git checkout email 

//reset to the new branch
git reset --hard origin/staging

// push to remote
git push -f

これで、メールブランチとステージングは​​同じです。

git checkout email
git merge -m "Making email same as staging disregarding any conflicts from email in the process" -s recursive -X theirs staging

これは元の新しいブランチを変更せず、最終的なコミットの前にさらに変更を加える機会を与えます。

git checkout new -b tmp
git merge -s ours old -m 'irrelevant'
git checkout old
git merge --squash tmp
git branch -D tmp
#do any other stuff you want
git add -A; git commit -m 'foo' #commit (or however you like)