GitLab Flow单仓长生命周期环境分支PR冗余提交问题咨询

你遇到的冗余提交问题，核心原因是feature分支的基线落后于目标分支：

• 你的feature分支从Production拉取时，Production是某个旧版本；后续其他feature合并到Production，导致Development/Staging分支同步了这些新提交
• 当你用旧基线的feature分支向Development/Staging提交PR时，Git会把两个分支分叉点之后的所有提交都列出来，其中就包括那些已经合并到Production、且同步到目标分支的冗余提交。

结合你的monorepo约束（不能用dev→staging→prod的线性合并，需保留各环境分支代码），给出三个可行方案：

方案1：PR前合并目标分支最新代码到feature分支 #

每次准备向某个环境分支（比如Development）提交PR前，先将该环境分支的最新代码合并到你的feature分支，让feature分支的基线与目标分支对齐：

# 切换到你的feature分支
git checkout feature/your-service-update
# 拉取目标分支（比如Development）的最新代码
git pull origin development
# 手动解决代码冲突
git add .
git commit -m "合并development分支最新代码"
# 推送更新后的feature分支
git push origin feature/your-service-update

这样操作后，PR里只会显示你的feature分支独有的提交，冗余提交会被自动过滤。

方案2：用Rebase替代合并，保持feature分支历史整洁 #

如果不想让feature分支历史里有大量合并记录，可以用rebase将feature分支的提交重新基于目标分支的最新版本：

git checkout feature/your-service-update
# 将feature分支rebase到development的最新代码
git pull origin development --rebase
# 遇到冲突时，解决后执行以下命令继续rebase
git rebase --continue
# 推送rebase后的分支（需要--force-with-lease避免覆盖他人提交）
git push origin feature/your-service-update --force-with-lease

⚠️ 注意：rebase会改写分支历史，如果你的feature分支是多人协作开发的，一定要提前和团队成员沟通，避免代码丢失。

方案3：调整feature分支的创建基线 #

不要固定从Production拉取feature分支，而是根据feature的部署路径选择基线：

• 如果feature首先部署到Development，直接从Development分支拉取feature分支；
• 当需要将该feature部署到Staging时，再从Staging分支拉取一个新的feature分支（或者基于原feature分支合并Staging的最新代码）；
• 最终部署到Production时，从Production分支拉取对应的feature分支（或合并Production最新代码）。
  这种方式能让feature分支的基线始终与目标环境分支保持一致，从根源上避免冗余提交。

因为你用的是monorepo，多个Web Service共存，可以在PR中使用路径过滤（Azure Repos支持该功能），只关注当前feature修改的Web Service相关文件，即使PR里有其他提交，也能快速定位自己的变更内容。

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