小型团队克隆项目Git工作流：如何顺畅同步上游main分支

一、规范上游同步的操作流程 #

• 先确保本地dev分支无未提交修改，拉取上游main分支最新代码：
  git fetch upstream main
• 切换到本地dev分支，用**变基（rebase）**替代普通合并同步上游：
  git rebase upstream/main
  变基会把你的定制提交排在上游最新提交之后，历史更线性，冲突位置更清晰，还能减少后续重复冲突。冲突解决后执行git rebase --continue，不想处理可通过git rebase --abort回退到操作前状态。

二、降低上游文件修改的冲突概率 #

• 尽量避免直接修改上游核心文件，非改不可时，把修改拆成最小单元提交——每个提交只对应一个明确的小改动，冲突时能快速定位和调整。
• 用补丁或自定义配置替代直接修改：比如上游有个配置文件，不要硬改源码，新增自定义配置覆盖默认值；或者用git diff > custom.patch生成补丁，每次同步上游后重新应用补丁（git apply custom.patch），大幅减少直接修改带来的冲突。
• 给定制提交写清晰注释，比如feat: 适配定制需求，调整上游支付模块超时参数，同步时能快速回忆修改目的，解决冲突更高效。

三、优化分支管理习惯 #

• 新特性分支必须基于最新的dev分支创建：每次开新分支前，先同步dev到上游最新，再切分支：
  git checkout dev && git rebase upstream/main && git checkout -b feature/xxx
  从根源减少特性分支合并到dev时的冲突。
• 合并特性分支到dev时，用git merge --no-ff feature/xxx，保留分支历史，既方便后续排查问题，也让dev的提交结构更清晰。
• 绝对不要在dev分支直接开发，所有修改都在特性分支完成后再合并到dev，保证dev分支始终相对干净，同步上游时冲突更少。

四、高效处理冲突的技巧 #

• 冲突发生时，先用git status定位冲突文件，优先处理你修改过的上游文件——对比上游最新版本和你的定制逻辑，尽量在适配上游变更的同时保留自己的需求。
• 用可视化冲突工具辅助：配置git mergetool调用VS Code、Beyond Compare等工具，直观对比三方差异（你的版本、上游版本、共同祖先），减少手动修改的错误。
• 若某文件冲突频繁，把定制部分抽离成独立模块/插件：比如上游的核心逻辑你改了一部分，就把这部分逻辑做成插件，上游更新时只需要调整插件的调用接口，不用动原文件。

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