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

gdRow

我当前的环境分支

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

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

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

问题

  • 每次我必须构建功能时,都必须在master分支上再次提交仅用于切换子模块的提交有更好的合并策略吗?谢谢
丹尼尔·霍尼克(Daniel Hornik)

工作流程的问题是,您将SMDev分支用于子模块。git的行为是正确和预期的。

如果feature要从dev创建分支,那么您将拥有从dev到合并到master的所有更改。

樱桃采摘

如果要保留工作流程,那么第一个解决方案是cherry-pick合并而不是合并,但这不是git设计成如何工作的...

更新工作流程

您是否需要SMDev分支来使用此工作流程来进行子模块的工作:

  1. 创建新的feature主分支
  2. 更新子模块,但不要提交。跳过git add子模块命令。
  3. 合并featuredev
  4. 在开发人员中正确测试
  5. 合并feature掌握

它为开发人员介绍了一些手动工作

prepare-commit-msg钩子

您可以设置一些挂钩,这些挂钩可以在与主站点合并时更改子模块分支。有关更多信息,请参见以下页面:https : //mirrors.edge.kernel.org/pub/software/scm/git/docs/githooks.html#_prepare_commit_msg

本文收集自互联网,转载请注明来源。

如有侵权,请联系 [email protected] 删除。

编辑于
0

我来说两句

0 条评论
登录 后参与评论

相关文章