Git 保持主分支(master)和开发分支(develop)同步

为什么要同步这两个分支？#

在 Git Flow 工作流中，我们通常会创建一个开发分支，用于并行开发新特性和修复Bug。

master 分支通常用于生产环境，包含稳定可发布的代码；

develop 分支则是开发的主干，所有新功能都从这里合并；

如果不及时同步，时间一长，两个分支的差异会越来越大，合并时可能面临大量冲突，甚至需要重新梳理整个历史。

从 master 同步到 develop#

当 master 分支有新的提交需要同步到 develop 时：

1
# 1. 切换到 develop 分支
2
git checkout develop
3

4
# 2. 拉取最新的 develop 代码（如果有远程仓库）
5
git pull origin develop
6

7
# 3. 合并 master 分支的更新
8
git merge master

如果遇到冲突，解决冲突后继续：

1
# 解决冲突后
2
git add .
3
git commit -m "同步 master 分支的修复到 develop"

从 develop 同步到 master#

当 develop 分支的功能开发完成，准备发布到生产环境时：

1
# 1. 切换到 master 分支
2
git checkout master
3

4
# 2. 拉取最新的 master 代码
5
git pull origin master
6

7
# 3. 合并 develop 分支
8
git merge develop
9

10
# 4. 推送到远程仓库
11
git push origin master

使用 rebase 保持线性历史（适合小团队）#

如果你希望保持提交历史的线性，可以使用 rebase：

1
# 切换到 develop 分支
2
git checkout develop
3

4
# 将 master 的提交应用到 develop 之上
5
git rebase master

注意：rebase 会改写提交历史，如果 develop 已经推送到远程且多人协作，可能会影响其他人的工作。建议只在本地分支或确认团队成员了解的情况下使用。

实际遇到的问题和解决方案#

问题 1：合并时出现大量冲突#

场景：两个分支长时间未同步，合并时提示有几十个文件冲突。

解决方法：

先查看差异：git diff master..develop 了解具体变化
使用三路合并工具：git mergetool 可以调用配置的合并工具（如 VS Code、Beyond Compare）
如果冲突太多，考虑分批处理，先合并关键修复，再逐步同步其他更改

问题 2：合并后想撤销#

如果不小心合并错了，可以使用：

1
# 撤销最后一次合并（如果还没推送）
2
git reset --hard HEAD~1
3

4
# 如果已经推送，需要强制推送（谨慎使用）
5
git push origin develop --force

问题 3：只想同步特定的提交#

有时候 master 上有很多提交，但只想同步某个 bug 修复，可以使用 cherry-pick：

1
# 查看 master 的提交历史
2
git log master --oneline
3

4
# 只应用特定的提交到 develop
5
git checkout develop
6
git cherry-pick <commit-hash>