Git 子模块不同分支的合并策略

Question

我目前的环境分支

• master 包含子模块 SMMaster
• dev 包含子模块 SMDev

开发功能时我当前的合并策略

1. 从 dev
创建分支 feature
2. 将提交添加到 feature
3. 将 feature 合并到 dev 并提交审核
4. 接受后，将 feature 合并到 master
5. 现在 master 包含子模块 SMDEV
6. 所以我将子模块更改为 SMMaster 并提交到 master

问题

• 每次我必须构建一个功能时，我必须在 master 分支上再次提交以切换子模块。有更好的合并策略吗？谢谢

Answer 1

您的工作流程存在问题，您将 SMDev 分支用于子模块。 git 的行为是正确的，符合预期。

如果您正在从 dev 创建 feature 分支，那么您将所有更改从 dev 合并到 master。

解决方案

摘樱桃

如果您要继续使用您的工作流程，第一个解决方案是 cherry-pick 而不是合并，但这不是 git 设计的工作方式...

更新工作流程

您是否需要 SMDev 分支来处理此工作流程的子模块：

1. 创建新的 feature 主分支
2. 更新子模块，但从不提交。跳过子模块的 git add 命令。
3. 将 feature 合并到 dev
4. 在开发中正确测试
5. 将 feature 合并到 master

它为开发人员引入了一些手动工作

准备提交消息挂钩

你可以设置一些钩子，当你合并到主模块时，这些钩子可以改变你的子模块分支。有关详细信息，请参阅此页面：https://mirrors.edge.kernel.org/pub/software/scm/git/docs/githooks.html#_prepare_commit_msg