定期拉取上游开源代码时如何持久保留本地固定自定义修改？

针对你需要每三个月同步上游开源代码、同时保留少量本地适配修改的场景，最优方案是基于变基（rebase）维护独立的自定义修改分支，操作流程固定可控，冲突处理成本低，分支历史干净。

首次初始化配置 #

1. 配置上游远程仓库地址：
   执行git remote -v查看现有远程仓库，如果没有指向原开源项目的upstream源，执行以下命令添加：

   git remote add upstream 原开源项目的Git仓库地址
   

2. 创建本地自定义修改分支：
   基于最新的上游默认分支创建独立的自定义分支，用于存放你对构建路径的适配修改：

   # 拉取上游最新的默认分支代码
   git checkout master
   git pull upstream master
   # 创建并切换到自定义分支
   git checkout -b local/adapt
   

3. 在local/adapt分支中完成所有本地适配修改，提交为1个或少量几个语义清晰的commit（例如commit信息写「本地构建路径适配」），方便后续识别处理。

定期同步上游的标准操作流程 #

每三个月需要同步上游更新时，只需按以下固定步骤执行，操作复杂度极低：

• 拉取上游最新代码到本地默认分支：

  git checkout master
  git pull upstream master
  

• 将自定义分支的修改重定位到最新的上游代码之上：

  git checkout local/adapt
  git rebase master
  

• 若出现冲突（仅当上游修改了你也调整过的构建文件行时才会触发，你当前的场景冲突概率极低），只需按终端提示修改冲突文件，修改完成后执行git add 冲突文件名，再执行git rebase --continue即可完成同步。

其他备选方案的弊端说明 #

你提到的三个方案都存在不同程度的缺陷，不推荐长期使用：

• 主分支合并自定义分支的方案：每次合并都会生成冗余的合并提交，同步次数多了后分支历史会极度混乱，容易出现误操作，排查问题成本极高
• Git patch方案：适合临时修改的单次复用，长期维护固定修改的场景下，需要每次手动导出、导入补丁，修改调整时还要重新生成补丁，维护成本远高于分支管理方案
• 自定义分支直接pull上游更新的方案：本质等同于在自定义分支合并上游代码，和第一个方案的问题一致，会生成大量合并提交，分支历史杂乱，容易出错

可选优化方案 #

如果项目的构建系统支持独立的本地配置文件（例如很多项目支持忽略.local后缀的配置文件，且本地配置优先级高于默认配置），可以把你的路径适配调整写到不纳入版本控制的本地配置文件中，无需维护自定义分支，每次直接在默认分支拉取上游更新即可，不会覆盖本地配置。

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