一、不合并文件的情况下推送代码 #

如果你不想整合远程变更就推送，得根据场景选合适的方法，但一定要注意强制类操作的风险，尤其是多人协作的仓库：

1. 强制推送（覆盖远程分支） #

如果你确定本地版本是最终正确的，且这个分支没有其他开发者在协作，可以用强制推送直接覆盖远程分支：

git push -f origin master

⚠️ 重要提醒：这个操作会彻底抹掉远程分支的现有历史，多人协作时绝对不能随便用，会导致队友的代码丢失。

2. 变基后推送（保持线性历史，无合并提交） #

如果远程有新提交，但你不想生成冗余的合并提交，想让本地提交“排在”远程最新提交的后面，可以用变基：

# 拉取远程变更并变基到本地分支
git pull --rebase origin master
# 变基完成后，直接推送即可（此时通常是fast-forward，无需强制）
git push origin master

变基会把你的本地提交重新应用在远程最新提交之上，让提交历史更简洁线性，也避免了合并带来的冗余文件问题。

3. 推送到新分支 #

如果不想影响原分支的远程版本，也可以把本地代码推送到一个全新的远程分支：

git push origin master:new-feature-branch

这样原分支的远程状态不会被修改，你可以在新分支上继续开发，之后再通过PR（Pull Request）的方式合并到主分支。

二、修复non-fast-forward错误及pull后的旧文件问题 #

你遇到的报错本质是：远程分支的提交进度比你的本地分支要新，Git为了避免覆盖他人的修改，拒绝了你的推送请求。而执行git pull后出现旧文件问题，是因为默认的git pull会执行合并操作，把远程分支里你已经处理过的旧文件又合并回了本地。

具体解决步骤： #

1. 撤销错误的git pull（如果还没提交合并结果）
   如果git pull之后你还没提交合并产生的变更，可以用这条命令回到pull前的状态，丢弃合并带来的冗余文件：

git reset --hard HEAD@{1}

2. 用变基代替合并拉取远程变更
   重新拉取远程代码，但这次用变基模式，避免生成合并提交，也不会带回不需要的旧文件：

git pull --rebase origin master

如果变基过程中出现冲突，Git会提示你手动解决冲突，解决后执行：

git add .
git rebase --continue

要是中途想放弃变基，执行：

git rebase --abort

3. 正常推送代码
   变基完成后，本地分支就会基于远程最新提交，此时直接推送即可：

git push origin master

为什么变基能避免旧文件问题？ #

变基是将你的本地提交“重演”在远程最新提交的后面，而不是简单地把两个分支合并。这样Git会更智能地识别你已经处理过的文件变更，不会重复添加那些你已经删除或修改过的旧文件。

内容的提问来源于stack exchange，提问作者karoltyk