企业官网建设流程全解析

1. 为什么需要掌握Rebase的冲突解决？

第一次用Sourcetree做Rebase时，我盯着冲突文件里的"Theirs"和"Mine"愣了半天——这跟平时Merge时的指向完全相反！后来在开源项目提交PR时，因为没处理好Rebase冲突被维护者要求重改，才意识到这真是个必须跨过去的坎。

Rebase的本质是重新演播提交记录。想象你正在拍电影，Merge是把两个版本的胶片粘在一起，而Rebase是把你的戏份重新拍摄到最新剧本上。这种"重拍"过程必然会产生场景冲突：主角台词改了、场景布置变了，都需要你手动调整表演。这就是为什么几乎所有复杂点的Rebase都会遇到冲突，尤其在多人协作的分支上。

与Merge相比，Rebase冲突有两个特殊点：一是冲突可能多次出现（每个被重新应用的提交都可能触发），二是代码归属标识相反。很多开发者在这里栽跟头，用Merge的习惯处理Rebase冲突，结果把代码归属完全搞反。有次我团队的新人就这样把别人的代码全覆盖了，最后不得不从reflog里抢救提交记录。

2. 图解Rebase冲突解决全流程

2.1 准备阶段的关键检查点

在点击Rebase按钮前，务必完成三个检查：

1. 分支状态：确保当前在要变基的分支（比如feature/login）
2. 代码同步：两个分支都执行过git pull（比如develop和feature/login）
3. 工作目录：没有未提交的修改（stash或commit掉）

我习惯用Sourcetree的状态面板确认这些信息。右侧的"未暂存文件"区域应该空白，分支图显示两个分支都是最新状态。上周就遇到个案例：同事在本地develop分支有未推送的提交，结果Rebase后这些提交神秘消失了，其实是被"重播"到了feature分支上。

2.2 冲突界面中的代码归属解密

当冲突弹窗出现时，关键要理解这两个按钮：

• Resolve using 'Mine'：保留当前分支的代码（在Rebase中这是目标分支的代码）
• Resolve using 'Theirs'：保留被重新应用的提交的代码（你的特性分支代码）

这个逻辑与Merge完全相反！有个记忆诀窍：Rebase时你是"搬家"的人，Theirs指你搬家的行李（原分支），Mine是新家的规矩（目标分支）。我通常在解决第一个冲突时，会故意选错一次看看差异，确认理解正确再继续。

2.3 命令行与GUI的协同作战

解决完所有冲突文件后，Sourcetree的界面会变得有点迷惑——没有明显的继续按钮。这时需要切换到命令行：

git rebase --continue

如果还有未解决的冲突，Git会明确告诉你哪些文件需要处理。我习惯在Sourcetree的"操作"面板里打开终端，这样不用切换窗口。遇到过最棘手的情况是一个冲突反复出现5次，其实是同一个文件在不同提交中被修改，需要耐心处理每个版本。

3. 强推（Force Push）的安全策略

3.1 何时必须使用--force

完成本地Rebase后，分支历史已经改变，常规git push会被拒绝。这时需要：

git push --force-with-lease

这个比--force更安全的变体会检查远端分支是否被他人更新过。有次我在强推前没pull，不小心覆盖了同事刚推送的提交，后来团队就强制要求用--force-with-lease。

3.2 危险操作的防护措施

强推前建议：

1. 创建备份分支：git branch backup/feature-login
2. 通知团队频道："我要强推feature/login分支"
3. 使用Sourcetree的"强制推送"选项（会自动添加--force-with-lease）

对于关键分支（如main），更好的做法是禁用强推，通过PR合并。我们团队用GitHub的branch protection规则，要求main分支必须通过PR且CI通过才能更新。

4. 高频问题场景解决方案

4.1 复杂Merge后的Rebase困境

遇到过最头疼的情况是：feature分支已经merge过多次develop，现在要rebase。这时可以：

1. 基于当前feature创建临时分支
2. 在feature分支执行git reset --hard develop（危险操作！确保有备份）
3. 用cherry-pick把特性提交一个个应用到干净的feature分支
4. 重新rebase

4.2 交互式Rebase的妙用

在Sourcetree中右键提交选择"Rebase children interactively"，可以：

• 合并多余提交（Squash）
• 修改提交信息（Reword）
• 调整提交顺序（直接拖拽）

有个项目我误提交了API密钥，就是用交互式Rebase删除的。操作前切记备份，误操作可以用git reflog找回丢失的提交。

4.3 跨团队协作时的Rebase礼仪

当多人共用特性分支时，强推会破坏他人工作流。我们的约定：

• 分支命名带作者前缀（如feat/xx-login）
• Rebase前在群聊里@相关成员
• 推送后提醒大家git fetch && git reset --hard origin/branch

有次没遵守这个流程，导致团队三人花了半天解决冲突。现在我们的README.md里专门有Rebase规范章节。