Git Feature分支工作流及本地配置相关问题咨询

问题1：本地fork仓库的main/master分支是否应保持未修改并同步原仓库？ #

是的，这是业内通用的最佳实践，原因如下：

• 保持main/master分支干净且与原仓库完全同步，能大幅降低后续向原仓库提交PR时的冲突概率——毕竟PR的基线是原仓库的最新main分支，从同步后的本地main切功能分支，代码起点和原仓库一致。
• 同步操作步骤：先给原仓库添加上游远程（git remote add upstream <原仓库URL>），之后定期执行：
  • git checkout main && git pull upstream main：拉取原仓库最新代码到本地main
  • git push origin main：把同步后的本地main推送到自己的fork仓库

问题2：本地配置与功能分支的管理方案 #

你的思路方向是对的，再补充一些更顺畅的细节：

• 核心原则：功能分支只存纯粹的功能代码，本地配置单独隔离，绝不推送到远程fork。
• 具体操作：
  • 从干净的main分支切出feature分支，所有功能开发、代码提交都在这个分支里，全程不碰本地配置相关内容。
  • 单独维护local-config分支，只存放本地运行必需的配置修改（比如Flutter的设备适配配置、本地环境变量文件等），这个分支只在本地保留，永远不要推送到GitHub的fork仓库。
  • 测试时，把local-config分支变基到当前的feature分支上（git checkout local-config && git rebase feature），这样就能得到一个带本地配置的测试分支，直接用来本地构建测试即可。
• 额外处理被意外追踪的配置文件：
  • 如果发现有本该被.gitignore忽略但被原作者加入追踪的文件，先在本地执行git rm --cached <文件名>移除Git追踪（不会删除本地文件），然后更新.gitignore把该文件加入忽略规则。注意：这个.gitignore的修改要放到local-config分支里，不要加到feature分支中，避免影响PR的纯净度。

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