如何在未合并dev分支时向main提交内容，后续合并dev不被覆盖？

第一步：处理当前dev分支的未完成工作 #

dev分支上有未完成的f1改动，直接切换分支会导致冲突或改动丢失，先暂存改动：

• 在dev分支执行 git stash，将f1的未完成修改暂存到Git栈中
• 切换回main分支：git checkout main（新版Git可使用 git switch main）

第二步：开发功能f2（推荐用独立分支） #

为避免直接污染main分支，基于main创建dev2分支开发f2：

• 创建并切换到dev2分支：git checkout -b dev2（或 git switch -c dev2）
• 在dev2上完成f2开发后提交改动：

  git add .
  git commit -m "完成功能f2开发"
  

• 将dev2合并回main分支：

  git checkout main
  git merge dev2
  

  这一步不会产生冲突，因为dev2完全基于最新的main分支开发

第三步：回到dev分支继续开发f1 #

• 切换回dev分支：git checkout dev
• 恢复之前暂存的f1改动：git stash pop，继续完成f1开发

后续合并dev到main的冲突处理 #

当f1开发完成后，合并dev到main时，Git会自动检测文件A的差异，不会直接覆盖f2内容，只需手动解决冲突：

• 切换到main分支：git checkout main
• 执行合并：git merge dev，此时Git会提示文件A存在冲突
• 打开文件A，找到冲突标记（<<<<<<< HEAD 对应main的f2改动，======= 为分隔符，>>>>>>> dev 对应dev的f1改动），手动合并两处逻辑，同时保留f1和f2的内容
• 解决冲突后提交：git add A → git commit（Git会自动生成合并提交信息）

额外建议 #

• 尽量避免直接在main分支开发功能，使用独立分支（如dev2）更便于版本管理和回滚
• 开发f1的过程中，定期将main的最新代码合并到dev：git checkout dev → git merge main，提前解决冲突，减少后续合并的复杂度
• 如果不想用stash，也可以在dev分支提交未完成的f1（标记为WIP: 功能f1开发中），后续回到dev继续修改，合并时可通过git rebase -i squash提交记录，保持提交历史整洁

内容的提问来源于stack exchange，提问作者BeeFriedman