如何避免每次提交新合并请求时都硬重置fork的Git仓库？

• 上游团队合入MR时未使用快进合并（Fast-Forward Merge），而是采用了默认的三方合并生成新提交、压缩合并（Squash Merge）或变基合并（Rebase Merge）策略，这几类操作都会导致最终合入upstream的提交ID与你origin上的原始提交ID不一致
• 执行rebase操作时，Git无法识别这些已合入但ID发生变更的旧提交，会将其判定为未合入的新提交纳入rebase序列，最终要么出现冲突，要么重复出现在新的MR中
• 团队持续向origin主分支提交新代码的操作会进一步扩大origin主分支与upstream主分支的提交分叉，提升rebase冲突的概率

1. 核心工作流调整（最关键） #

永远不要直接向origin的主分支（如main/master）提交代码，所有开发工作都在独立功能分支上完成：

• 每个待提交到upstream的MR对应一个单独的功能分支，功能分支与MR一一绑定，MR合入后即可删除该分支
• origin主分支仅承载与upstream主分支同步的操作，不存放任何开发提交

2. 定期同步origin主分支 #

每次启动新功能开发前，先将origin主分支同步到upstream最新状态，操作如下：

# 拉取upstream最新代码
git fetch upstream
# 切换到本地主分支
git checkout main
# 快进合并到upstream最新状态，无额外提交生成
git merge --ff-only upstream/main
# 推送至origin主分支，无需--force参数
git push origin main

如果提示无法快进，说明origin主分支存在未同步到upstream的提交，此时仅需执行一次硬重置即可，该操作一个开发周期仅需执行一次，不会影响其他功能分支：

git reset --hard upstream/main
git push --force origin main

3. 功能分支提交流程 #

• 基于最新的本地主分支创建功能分支：git checkout -b feature/xxx main
• 功能分支开发完成后推送至origin，再基于该功能分支向上游提交MR
• MR等待审核期间如果有新功能需要开发，直接从本地主分支拉取新的功能分支开发，不要在旧功能分支上叠加提交
• 旧MR需要调整时，直接在对应功能分支上修改后推送，MR会自动更新
• 旧MR被上游合入后，直接删除本地和origin上的对应功能分支即可

4. 待审核MR同步上游更新操作 #

如果MR仍在审核中，需要同步上游主分支的最新代码，执行以下操作：

git fetch upstream
git checkout feature/xxx
# 变基到upstream最新主分支，仅处理当前功能分支的独有提交，不会出现旧提交重复问题
git rebase upstream/main
# 解决冲突后推送到origin对应功能分支，--force-with-lease比--force更安全，不会覆盖他人提交
git push --force-with-lease origin feature/xxx

调整为上述工作流后，无需每次MR合入后都硬重置origin主分支，也不会出现新MR携带已合入旧提交的问题。

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