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

Question

我当前的环境分支

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

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

1. 从 feature 创建分支 dev
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

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

prepare-commit-msg 钩子

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