背景：开源与内部定制的挑战

在企业内部基于 GitHub 等平台上的优秀开源项目进行二次开发是非常常见的实践。这带来了代码的高起点和快速迭代，但也引入了一个关键的 Git 管理挑战：

1. 代码来源多样化： 我们基于 GitHub 上的开源仓库 (Upstream)，同时在 公司内部 Git 仓库 (Origin) 中进行定制化开发。
2. 更新同步需求： 必须能够定期、安全地将上游开源仓库的最新功能和安全补丁应用到我们的内部项目中。
3. 开发连续性： 日常的开发工作需要稳定地基于公司内部仓库进行。

本文将介绍一个从搭建到同步的完整工作流，确保在高效同步更新的同时，保持内部开发历史的整洁和稳定。

第一步：环境搭建与仓库设置

为了实现日常开发基于公司仓库，更新同步来自 GitHub 的目标，我们需要在本地仓库中设置两个远程仓库（Remotes）。

1. 克隆公司内部仓库

首先，将公司内部的 Git 仓库克隆到本地。这会自动将公司仓库设置为 origin。

# 克隆公司内部的 Git 仓库
git clone <公司内部 Git 仓库的 URL>
cd <你的项目目录>

2. 添加 GitHub 仓库为 upstream

接下来，将 GitHub 上的开源项目添加为另一个远程仓库，通常命名为 upstream。这个仓库只用于拉取（fetch）更新。

# 将 GitHub 上的开源项目添加为一个新的远程仓库，命名为 'upstream'
git remote add upstream <GitHub 项目的 URL>

3. 验证设置

运行以下命令确认你已经有两个远程仓库：origin (公司) 和 upstream (GitHub)。

git remote -v

输出应该包含两个不同的 URL：

origin  <公司内部 Git 仓库的 URL> (fetch)
origin  <公司内部 Git 仓库的 URL> (push)
upstream <GitHub 项目的 URL> (fetch)
upstream <GitHub 项目的 URL> (push)

至此，基础设置完成。日常开发工作请始终针对 origin 仓库。

---

第二步：使用 Rebase 和临时分支隔离风险（同步更新）

我们的核心策略是利用 Git 的 rebase (变基) 操作来保持历史记录的线性，并借助一个临时合并分支来隔离冲突和测试风险。

使用Rebase也是有条件的，详情可以参考这篇文章：[基于 GitHub 开源项目二次开发：Upstream 同步、Merge / Rebase 边界与实践](https://blog.csdn.net/Garfield2005/article/details/160377237)

优势分析：为什么选择这种方法？

1. 历史记录的线性： 使用 rebase 避免了大量的合并提交 (Merge Commit)，使得你的 Git 历史记录像一条直线，更容易追溯和调试。
2. 风险隔离： 所有的冲突解决和测试都发生在独立的 github_merge 分支上，确保主分支 (master) 在操作完成前始终保持稳定和可用。

具体操作步骤

假设你需要将 upstream/main 分支的最新内容同步到你本地的 master 分支。

阶段一：准备工作与获取更新

# 1. 确保在主分支上，并同步公司仓库的最新代码
git checkout master
git pull origin master 

# 2. 从主分支创建一个临时合并分支
# 所有合并操作和冲突解决都将在这个分支上完成
git checkout -b github_merge

# 3. 从 GitHub 仓库下载最新代码 (只下载，不合并)
git fetch upstream 

阶段二：执行变基和解决冲突

# 4. 执行变基操作：将本地（公司）的定制提交，移动到 'upstream/main' 的最前面
# 注意：请将 'main' 替换为 GitHub 仓库的实际主分支名
git rebase upstream/main

变基过程中，Git 可能会暂停并提示冲突。

A. 如果遇到冲突 (Conflict)：

1. 手动解决文件中的冲突标记 (<<<<<<<, =======, >>>>>>>)。
2. 使用 git add . 标记冲突已解决的文件。
3. 继续变基操作：git rebase --continue 【注意：不要git commit】

B. 如果变基完成：

1. 运行完整的测试套件，确保所有功能和公司定制代码都能在最新的开源代码上正常工作。

阶段三：合并、清理与推送

# 5. 切换回你的主开发分支
git checkout master

# 6. 将临时分支快速合并到 master
# 此时 github_merge 是 master 的上游，因此会是 Fast-Forward (快进)
git merge github_merge --ff-only

# 7. (可选) 删除临时合并分支，完成清理
git branch -d github_merge

# 8. 将最终的更新推送到公司内部仓库
git push origin master 

通过这套完整的工作流，企业项目不仅能高效、安全地获取上游开源项目的更新，还能保持一个干净、线性的 Git 历史记录，极大地提高了项目的可维护性。

---

Git 场景问题 Q\&A 总结

Q1: 为什么我的本地分支 github_merge 提示与远程分支 分叉 (diverged)？

Your branch and 'origin/merge_github' have diverged,
and have 98 and 122 different commits each, respectively.
  (use "git pull" to merge the remote branch into yours)

A1: 这是因为您在本地执行了 git rebase upstream/main 操作。

• git rebase 的本质是 重写（rewrite） 提交历史。它将您本地的提交“移动”到新的基点上。
• 重写历史会导致这些提交的 SHA-1 ID 发生变化。
• 远程分支 origin/github_merge 仍指向旧的、未重写的历史。
• Git 发现本地是新历史，远程是旧历史，且它们拥有不同的“头”，因此判定它们已 分叉。

---

Q2: 面对“分支分叉”的提示，我应该执行 git pull 吗？

A2: 不应该。

• 执行 git pull（即 git fetch + git merge）会尝试将远程的旧历史 合并 到您本地的新历史中。
• 这将导致一个额外的 合并提交，并重新引入您通过 Rebase 努力移除的旧历史，使提交图变得混乱。
• 在 Rebase 场景中，您应该使用 强制推送 (git push --force-with-lease) 来用本地的新历史 覆盖 远程的旧历史。

---

Q3: 我在 Rebase 冲突解决后，错误地使用了 git commit 而非 git rebase --continue，导致 Rebase 中断。我该如何保留当前分支上的最新代码？

A3: 您的 git commit 操作 结束了 Rebase 进程，并创建了一个 新的提交（可能是合并提交或普通提交），这个提交包含了您解决冲突后的最终结果。

您现在可以使用以下 两种策略 将这个最新代码合并到 dev 分支，同时保留您解决冲突后的成果：

⭐ 策略一：使用 git merge (推荐)

这是最简单且最安全的做法，它会保留您在 github_merge 上的所有历史，并将其合并到 dev。

1. 切换到目标分支：git checkout dev
2. 执行合并：git merge github_merge
   • 结果： dev 分支会创建一个 合并提交，包含 github_merge 分支上所有最新的更改。

⭐ 策略二：使用 git cherry-pick (如果只想引入单个提交)

如果您只想将您解决冲突后创建的 那一个最新提交 引入到 dev 分支：

1. 在 github_merge 上找到该提交的 ID：git log --oneline (假设 ID 为 $A1B2C3D4$)
2. 切换到目标分支：git checkout dev
3. 应用该提交：git cherry-pick A1B2C3D4
   • 结果： dev 分支上会创建一个 内容相同但 ID 不同 的新提交，实现代码的转移。

---

Q4: 如果我决定使用强制推送，推荐的命令是什么？

A4: 推荐使用更安全的强制推送命令：

git push origin github_merge --force-with-lease

• --force-with-lease 会检查远程分支是否在您 Rebase 期间被其他人更新过。如果没有，它才会强制覆盖；如果有，它会失败并提醒您，从而 避免您不小心覆盖了他人的工作。