听起来你的历史是这样的：
...---o---A---o---...---o---o---B master
\
o---o---...---o---C verydifferentbranch
你说你担心强推会丢失历史verydifferentbranch to master。这样的操作实际上会丢弃之后的所有内容A直至B.
您可以通过合并历史记录来保留历史记录，或者只是在废弃的分支尖端放置一个标签并使其不合并。
使用合并
合并将允许您保留历史记录的双方：
...---o---A---o---...---o---o---B
\ \
o---o---...---o---C---M master
您执行的合并类型将决定为提交 M 创建的内容。正常合并（使用recursive合并策略）听起来会在您的情况下产生大量冲突。如果您确实需要合并来自A..B提交后，除了解决合并或变基带来的冲突之外，别无他法。（如果您可以更频繁地合并或变基以处理出现的冲突，将来您可能会遇到更少的问题。）但是，如果您只是想M具有相同的内容C（即您想忽略由A..B提交），那么你可以使用ours合并策略。
git 合并(1) http://www.kernel.org/pub/software/scm/git/docs/git-merge.html描述了ours合并策略：
这可以解析任意数量的头，但合并的结果树始终是当前分支头的树，从而有效地忽略来自所有其他分支的所有更改。它旨在用于取代侧分支的旧开发历史。请注意，这与递归合并策略的 -Xours 选项不同。
您可以使用以下消息生成 MMerge commit 'abandoned/foo-features'像这样：
git tag -m 'describe reason for abandonment here...' \
abandoned/foo-features master # tag abandoned branch tip
git checkout verydifferentbranch # checkout dominant branch
git branch -M verydifferentbranch master # replace master
git merge -s ours abandoned/foo-features # merge only other's history
git tag -d abandoned/foo-features # optional: delete the tag
git push wherever master tag abandoned/foo-features # publish them
这些命令的变化将为您提供略有不同的自动提交消息M（你可以随时提供自己的git merge -m或修改为git commit --amend然后）。
要点是由此产生的master将有两条历史记录，但与原始版本相比没有任何变化master侧面（这些更改仍然在历史记录中，它们只是没有在提交引用的树中表示M).
让它悬挂起来
如果“重写”可以接受master（即没有基于任何提交的其他工作A..B，或者所涉及的用户不介意这样做所需要的工作从重写中恢复 http://git-scm.com/docs/git-rebase#_recovering_from_upstream_rebase），那么你可以在当前的提示处留下一个标签master并替换master with verydifferentbranch.
...---o---A---o---...---o---o---B (tag: abandoned/foo-features)
\
o---o---...---o---C master
像这样安排：
git tag -m 'describe reason for abandonment here...' \
abandoned/foo-features master # tag abandoned branch tip
git branch -M verydifferentbranch master # replace master
git push wherever +master tag abandoned/foo-features # publish them
