git - 高度耦合的 git 子模块

Question

我有一个项目需要分成两个存储库:一组通用模型和基于这些模型的模拟，以及附加代码。最终可能会有使用同一组模型的多个模拟，因此将它们放在单独的存储库中是一个明确的要求。显而易见的解决方案是将通用模型作为模拟的子模块。

不幸的是，这两个存储库将非常高度耦合。人们会非常频繁地向他们的通用模型添加一些东西，然后立即在模拟中使用它。我想这会在模拟 repo 的集成过程中造成很多麻烦。为了在模拟中 merge 来自许多开发人员的更改，集成商将不得不在通用模型子模块中进行并行 merge 。另一方面，它也使得使用子模块变得必不可少 - 模拟确实需要知道它应该使用哪个版本的通用模型。

该项目由相当多的人参与。大多数开发人员对 git 的了解都非常粗略:他们经常添加文件、提交和从 origin pull ，并希望有一个开发和稳定的分支。集成商自然学到了很多，但任何涉及子模块的东西对他来说肯定是新的。额外的好处:我即将休假一个月，所以我无法扑灭任何火灾。结果是，有很多动机让工作流真的难以搞砸，并尽量减少与人们以前工作流的差异。

所以，我的问题是:我会后悔建议我们为此使用子模块吗？ (有更好的主意吗？)我可以预料到人们会犯什么样的错误，以便我可以提前警告他们？有什么好的工作流程策略需要牢记吗？

编辑:我刚刚遇到 git slave ，在这种情况下也值得一看。尚不能对超出其网站上内容的能力/限制进行很好的评估。

Answer 1

给遇到这件事的其他人的一些注意事项!

新手们会犯的最大错误是在完成子模块更新后，在子模块中使用分离的 HEAD 进行提交。我将尝试通过来自钩子(Hook)的强烈警告来解决这个问题。

下一个最大的问题可能是在完成需要更新的 checkout 后无法进行子模块更新。同样，钩子(Hook)可以检查这一点并发出警告。

至于开发过程，这种设置使得在子模块中拥有良好的测试基础设施变得更加重要，这样如果可能的话你可以在其中工作而不必在父模块中工作，并完全避免这个问题。

我将尝试从我最终使用的钩子(Hook)中发布示例代码，并在一个月后跟进(希望不要太多)真实的恐怖故事。

编辑:

这是钩子(Hook)的初稿。请记住，这是一项紧急工作，对我来说放轻松!

在父仓库中:

对于 merge 后和 checkout 后，如果子模块不同步，我们会警告用户。 ( merge 后特别包含在快进 merge 中，从原点 pull 出)还要注意他们会想要 checkout 一个分支，尽 pipe 模块的 checkout 后 Hook 在他们运行子模块更新时也会这样做。提醒越多越好。

#!/bin/bash
if git submodule status | grep '^+' > /dev/null; then
    echo "WARNING: common model submodule now out of sync. You probably want to run" 1>&2
    echo "         git submodule update, then make sure to check out an appropriate branch" 1>&2
    echo "         in the submodule." 1>&2
fi

对于提交后，如果有子模块更改，我们会警告用户他们可能忘记将它们包含在他们的提交中。在这种高度耦合的情况下，这是一个很好的猜测。用户不太可能分别修改模拟和通用模型。

#!/bin/bash
if git submodule status | grep '^+' > /dev/null; then
    echo "WARNING: common model submodule has changes. If the commit you just made depends" 1>&2
    echo "         on those changes, you must run git add on the submodule, and then run" 1>&2
    echo "         git commit --amend to fix your commit." 1>&2
fi

在子模块中，一个 checkout 后 Hook 强烈警告分离的 HEAD:

#!/bin/bash

get_ppid() {
    ps --no-headers -o ppid $1
}

# Check to see if this checkout is part of a submodule update
# git submodule calls git checkout, which calls this script, so we need to
# check the grandparent process.
if ps --no-headers -o command $(get_ppid $(get_ppid $$)) | grep 'submodule update' &> /dev/null; then
    if ! git symbolic-ref HEAD &> /dev/null; then
        echo "WARNING: common model submodule entering detached HEAD state. If you don't know" 1>&2
        echo "         what this means, and you just ran 'git submodule update', you probably" 1>&2
        echo "         want to check out an appropriate branch in the submodule repository." 1>&2
        echo
        # escape the asterisk from SO's syntax highlighting (it sees C comments)
        branches=($(git for-each-ref --format='%(objectname) %(refname:short)' refs/heads/\* | grep ^$(git rev-parse HEAD) | cut -d\  -f2))
        case ${#branches} in
            0 )
                ;;
            1 ) 
                echo "Branch '${branches[0]}' is at HEAD"
                ;;
            * )
                echo "The following branches are at HEAD: ${branches[@]}"
                ;;
        esac
    fi
    echo
fi

我还添加了一个预提交 Hook ，以简单地中止使用分离的 HEAD 进行的提交(除非它是 rebase )。我非常害怕收到经典的“我所有的提交都消失了” panic 的提示。如果您知道自己在做什么，可以随时使用 --no-verify 绕过它。