Muk*_*ell 5 git workflow dependencies repository git-submodules
我一直在研究git子树和git子模块的其他替代方法.我的项目有超过100个子模块,管理它们非常笨拙.
任何人都可以推荐一个工作流程,它可以很好地处理需要保持同步的大量存储库.
如果你的项目有超过100个git子模块的组件和依赖项,无论你使用哪种方法,它们的管理都会很笨重:-)我建议寻找方法来编写尽可能多的部分脚本和自动化.相信我,对于大多数人来说,使用和链接git命令的新颖性很快就会消失,特别是在截止日期临近时.关于管理git子项目的不同方法的比较,这里已经有了一个非常好的答案.
关于工作流程,我将首先将您控制的存储库与不是第三方存储库的存储库分开.
对于不经常更改的第三方存储库(通过合并或上游PR),您仍然可以使用子模块.通常,您会将这些子模块指向某些稳定标记的HEAD.同步它们只是运行(或脚本)的问题git submodule update --recursive --remote.如果可以在包管理工具(如ruby项目)中指定这些第三方依赖项,则有助于简化子项目管理.
对于您自己和经常更改的存储库,gitslave或git-subtree是两种选择,具体取决于您团队的偏好.
gitslave将git操作多路复用到多个分支中.IOW,当你分支,合并,提交,推送,拉动等时,每个命令将依次在父项目和所有从属项上运行.这要求团队以自上而下的方式工作,从超级项目到奴隶.
gitsubtree使用Git的subtree merge功能来实现与子模块类似的效果,方法是将文件实际存储在主存储库中,并将更改直接合并到该存储库中.最终结果是一个规范的存储库,可以选择包含所有子项目的历史记录.在某种程度上,这允许团队成员更多地关注他们负责的子树,但是需要额外的工作才能合并回父树.
作为开发人员,我倾向于在较低的子项目级别工作(执行"红色,绿色,重构"循环),并仅在必要时触摸父项目.但无论您选择自上而下还是自下而上的工作流程,都要尝试在分支和合并策略中识别重复的容易出错的步骤,并尽可能地编写脚本.