Question

在git存储库中使用嵌套式repos而不是子模块可能是一个合理的工作流程？我的想法是，在不使用git子模块的情况下解耦大型仓库的各个部分，但不会增加太多复杂功能。

是否可以通过简单地嵌套具有自己遥控器的回购来实现，同时仍然可以实现理智的工作流程？

Answer 1

这将被称为git子树（请参阅“The power of Git subtree”和“Alternatives To Git Submodule: Git Subtree ”）。

I illustrate one git subtree workflow in this answer

它使用git read-tree和git merge --squash –s subtree

Answer 2

子模块正在恶化，根据我的经验，通常是个坏主意。我在一些项目中所做的是组合嵌套存储库和.gitignore条目。因此，外部容器仓库会忽略嵌套的仓库，但我根本不必为子模块烦恼。

在我的情况下，我通常使用自己的脚本来处理克隆，更新和清理嵌套的repos等内容。烹饪这样的东西并不难。

这是我用来管理Vim插件作为嵌套存储库的Perl示例。这个网址的完整脚本，下面的代码段。

https://github.com/tangledhelix/dotfiles/blob/master/install.pl

# install or update vim bundles
sub vim_bundle_installer {
    my $bundle_path = "$ENV{HOME}/.vim/bundle";
    mkdir $bundle_path unless -d $bundle_path;

    foreach my $bundle (keys %vim_bundles) {
        my $repo = $vim_bundles{$bundle};
        unless ($repo =~ /^(https?|git):\/\//) {
            if ($use_ssh) {
                $repo = "git\@github.com:$repo.git";
            } else {
                $repo = "https://github.com/$repo.git";
            }
        }
        my $this_bundle_path = "$bundle_path/$bundle";
        if (-d $this_bundle_path) {
            next if $vim_newmods_only;
            if ($vim_do_updates) {
                print "    updating vim bundle $bundle\n";
                system "cd $this_bundle_path && git pull";
            } else {
                print "    skipping vim bundle $bundle (already exists)\n";
            }
        } else {
            print "    cloning vim bundle $bundle\n";
            system "git clone $repo $this_bundle_path";
        }
    }

}

sub vim_newmods_installer {
    $vim_newmods_only = 1;
    vim_bundle_installer();
}

sub vim_bundle_updater {
    $vim_do_updates = 1;
    vim_bundle_installer();
}

用嵌套的repos工作流替换git子模块

2 个答案: