企业官网建设流程全解析

场景流程图：

需求分析：

1、你在主分支（master）的基础上创建了自己的dev-zhuzhu开发分支，当你开发完毕后，别人已经开发了2个功能，并合并到主分支（master）了，
2、所有你需要切换回主分支（master）拉取最新代码，注意!!此时你直接切换可能会丢失你开发的代码
3、所有要用到git的暂存功能：

代码暂存

1、在你的dev-zhuzhu分支上做下面的暂存
2、再切回主分支 master 拉新代码

代码恢复

3、再切回自己的 dev-zhuzhu 分支，按照下面的操作恢复代码
4.在rebase 选择 master，把 张三 李四提交代码rebase 到你当前分支，（可能会有冲突，解决冲突）
5、然后在提交代码。
6、登录 gitlab 发起 dev-zhuzhu 合并到 master的请求。

详细教程

一、核心结论：未提交代码切换分支，大概率不会丢失，但有风险（易覆盖/冲突）

IDEA（Git底层）的机制是：

• 如果你在dev-zhuzhu上修改了文件但未提交（未git add/git commit），切换到master时：
  1. 如果master上这些文件没有被其他人修改：Git会把你未提交的修改“带过去”（工作区内容保留），切换后master的工作区会显示你改的20个文件；
  2. 如果master上这些文件有其他人的新提交：Git会提示“本地修改会被切换分支覆盖”，直接拒绝切换（保护你的代码）；
  3. 极端情况（强制切换）：如果用git checkout -f master强制切换，未提交的修改会被覆盖，代码直接丢失！

所以不建议在未提交代码时切换分支，哪怕不会丢，也会导致master工作区混入你的开发代码，容易误操作。

二、正确实操步骤（结合IDEA，安全无风险）

步骤1：先把dev-zhuzhu的本地修改“暂存/提交”（核心：先保存自己的代码）

这是最关键的一步，避免切换分支时的任何风险，有两种方式：

• 方式A（推荐，临时保存）：用stash暂存未完成的修改（适合功能没开发完，不想正式提交）

  1. IDEA操作：顶部菜单 →Git→Stash Changes→ 输入暂存备注（比如“dev-zhuzhu功能开发中”）→ 点击Create Stash；
  2. 效果：工作区恢复到干净状态，修改被临时存到Git的stash栈里，切换分支无任何影响。

• 方式B（正式提交）：如果功能开发完了，直接提交到dev-zhuzhu

  1. IDEA操作：
     • 右侧Git面板 → 勾选所有修改的20个文件 → 输入提交信息（比如“完成XX功能开发”）→ 点击Commit（只Commit，不Push）；
  2. 效果：修改被提交到本地dev-zhuzhu分支，工作区干净。

步骤2：切换到本地master，拉取最新代码

1. IDEA操作：
   • 右下角分支选择框 → 选master→ 确认切换（此时工作区干净，切换无任何问题）；
   • 顶部菜单 →Git→Pull→ 确认拉取远程origin/master的最新代码（同步别人的提交）。

步骤3：切回dev-zhuzhu，恢复暂存/基于最新master变基

• 如果是方式A（stash暂存）：
  1. 切换回dev-zhuzhu分支；
  2. IDEA操作：顶部菜单 →Git→Unstash Changes→ 选择你刚才的stash记录 → 点击Apply Stash（恢复修改到工作区）；
• 如果是方式B（已提交）：直接切换回dev-zhuzhu即可。

步骤4：对dev-zhuzhu执行rebase（基于最新master）

IDEA可视化操作（比命令行更直观，避免冲突混乱）：

1. 确保当前分支是dev-zhuzhu；
2. 右侧Git面板 → 切换到Branches标签 → 找到origin/master→ 右键 → 选择Rebase onto；
3. 此时Git会先把你的dev-zhuzhu提交“暂存”，然后同步master的最新代码，再尝试把你的提交“接”到master最新提交之后；
4. 解决冲突：
   • 如果有冲突，IDEA会弹出冲突提示，标注冲突文件（红色标记）；
   • 打开冲突文件，IDEA会用不同颜色区分“你的代码”和“master的代码”，手动选择保留的逻辑（删除冲突标记<<<<<<</=======/>>>>>>>）；
   • 解决完一个文件的冲突后，点击文件右键 →Git→Add（标记为已解决）；
   • 所有冲突解决完后，点击顶部Git→Continue Rebase（继续rebase流程）；
   • 如果需要放弃rebase，点击Abort Rebase。

步骤5：推送dev-zhuzhu（如果需要合入master）

• 如果是自己的远程分支：rebase完成后，点击Push（如果是rebase后的提交，IDEA可能提示需要Force Push，仅在自己的分支上强制推送，绝对不要强制推master）；
• 如果要合入master：通过MR/PR（比如GitLab/GitHub）提交合并请求，或本地切回master后merge dev-zhuzhu（rebase后的分支merge无冲突）。

三、实战避坑要点（关键！）

1. 绝对不要在未提交/未stash的情况下切换分支：哪怕Git允许，也会导致工作区混乱，容易误删/覆盖代码；
2. rebase只用于自己的分支：不要对公共分支（如master）执行rebase，会打乱提交历史；
3. 冲突解决原则：以业务逻辑为准，优先和提交master的同事确认逻辑，避免保留错误代码；
4. 定期拉取master：开发过程中每隔1-2小时拉一次master，减少最终合并时的冲突量（冲突越少，解决越简单）；
5. 备份关键修改：如果修改涉及核心逻辑，可先复制一份到本地文件夹（双重保险）；
6. 慎用Force Push：仅在自己的dev-zhuzhu分支rebase后使用，强制推送会覆盖远程分支的提交历史，多人协作的分支需提前沟通。

四、总结流程（极简版）

dev-zhuzhu：stash/commit → 切master → pull master → 切回dev-zhuzhu → unstash（如有） → rebase onto master → 解决冲突 → continue rebase → push dev-zhuzhu → 合入master

按这个流程操作，既不会丢失代码，又能保证你的提交基于最新的master，合并时无冲突（或最小冲突），是Java团队协作中最规范的方式。如果用命令行更顺手，也可以参考对应指令，但IDEA的可视化操作对冲突处理更友好，适合日常开发。