如何解决不同子模块分支的Git合并策略 樱桃采摘更新工作流程prepare-commit-msg 钩子
我当前的环境分支
-
master包含子模块SMMaster -
dev包含子模块SMDev
我当前开发功能时的合并策略
- 从
feature创建分支dev - 向
feature添加提交 - 将
feature合并到dev并提交审核 - 一旦接受，将
feature合并到master - 现在
master包含子模块SMDEV - 所以我将子模块更改为
SMMaster并提交到master
问题
- 每次我必须构建一个功能时，我都必须在
master分支上再次提交，只是为了切换子模块。有没有更好的合并策略？谢谢
解决方法
您的工作流程的问题是，您将 SMDev 分支用于子模块。 git 的行为是正确且符合预期的。
如果您从 dev 创建 feature 分支，那么您将拥有从 dev 到合并到 master 的所有更改。
解决方案
樱桃采摘
如果您要保持工作流程的第一个解决方案是 cherry-pick 而不是合并，但这不是 git 的设计方式...
更新工作流程
您是否需要 SMDev 分支才能使用此工作流程进行子模块工作：
- 从主节点创建新的
feature分支 - 更新子模块，但永远不要提交。跳过子模块的
git add命令。 - 将
feature合并到dev - 在开发中正确测试
- 将
feature合并到 master
它为开发人员引入了一些手动工作
prepare-commit-msg 钩子
你可以设置一些钩子，当你合并到 master 时，这些钩子可以改变你的子模块分支。有关详细信息，请参阅此页面：https://mirrors.edge.kernel.org/pub/software/scm/git/docs/githooks.html#_prepare_commit_msg
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。