我练习代码的仓库，主分支main和我常使用的master分支，落后太多版本了，如何将master分支内容合并到main分支，main分支再推送到远端仓库呢？（我本地的名称和远端一致）。

新建main分支并签出到main分支。Git命令是

git checkout -b main

然后就是将master分支合并到main分支中，具体命令就是

git merge master

然后检查发现main分支的内容都同步的和master一样了。

最后把，内容推送到远端的main中就行，Git命令是

git push origin main

由于是从最新的代码中签出的，所以，想要合并，推送就很容易。但是，如果出现冲突呢？看我下一篇文章

具体来说，遇到的问题本质是：

• 本地main分支的基础版本落后于远端main分支（远端有其他提交）。

• 你本地也有自己的提交（可能是之前未推送的改动）。

• 直接git push会被拒绝，因为 Git 要求本地必须是远端的直接后继（fast-forward）。

个人开发或者小团体：

# 1. 拉取远端代码，并将你本地的提交“垫”到远端最新提交之后 git pull --rebase origin main # 2. 如果变基过程中出现冲突，解决冲突后执行： git add . git rebase --continue # 3. 推送（由于变基改变了历史，可能需要强制推送） git push origin main --force-with-lease

企业开发：

git pull origin main # 这会自动 merge，产生一个合并提交 git push origin main

解决方案（rebase）的思路是：

1. 用git pull --rebase将远端的提交先拉下来，然后把你本地的提交逐个“垫”到远端最新提交的后面。

2. 这样，你的本地历史就变成了“基于远端最新提交之上”的样子，相当于你是在远端的最新基础上做的修改。

3. 此时本地分支已经是远端的直接后继，理论上可以正常推送。但因为 rebase 改变了提交哈希，Git 仍然认为这不是快进（因为远端记录的哈希和本地不同），所以需要用--force-with-lease来“告诉” Git：我知道历史变了，但我确认远端没有其他新提交，请覆盖。

另一种思路（merge）：

1. 使用git pull --no-rebase（即默认的git pull）会将远端的提交和本地的提交合并成一个新的合并提交，形成分叉再合并的历史。

2. 这样本地分支仍然是远端的后代（因为有合并提交作为桥梁），可以直接git push而不需要强制推送。

3. 代价是多了一个合并提交，历史图会显得不那么线性。