git子模块的使用

Posted 2023-04-18

参考技术A git子模块可以用于项目包含另一个项目的情况，也许是第三方库或被多个项目引用的基础框架。
此次学习子模块就是因为公司的基础框架在多个不同的项目上的使用，同时又想当在开发项目过程中对基础框架有改动时，其他项目也能同时更新到改动的部分，而子模块允许我们将一个git仓库作为另一个git仓库的子目录，同时还能保持提交独立，正好满足原来设想的需求。

git submodule add https://github.com/yangmin1234/test1.git

当我们运行 git submodule update 从子模块仓库中抓取修改时，Git 将会获得这些改动并 更新子目录中的文件，但是会将子仓库留在一个称作 “游离的 HEAD” 的状态。 这意味着没有本 地工作分支（例如 “master”）跟踪改动。 所以你做的任何改动都不会被跟踪。

git checkout stable 进入子模块并检出相应的工作分支
git submodule update --remote 从上游拉取数据
git submodule update --remote --merge 从上游拉取数据并合并
发布子模块改动

如果我们在主项目中提交并推送但并不推送子模块上的改动，其他尝试检出我们修改的人会遇到 麻烦，因为他们无法得到依赖的子模块改动。 那些改动只存在于我们本地的拷贝中。

为了确保这不会发生，你可以让 Git 在推送到主项目前检查所有子模块是否已推送。 git push 命令接受可以设置为 check 或 on-demand 的 --recurse-submodules 参数。 如果任何提交的子模块改动没有推送那么 check 选项会直接使 push 操作失败。

提交主项目时自动检测子模块是否有未提交的改动

git push --recurse-submodules=check

提交主项目时，尝试自动推送一改动的子模块

git push --recurse-submodules=on-demand

子模块技巧
子模块遍历
有一个 foreach 子模块命令，它能在每一个子模块中运行任意命令。 如果项目中包含了大量子模块，这会非常有用。

有用的别名
你可能想为其中一些命令设置别名，因为它们可能会非常长而你又不能 设置选项作为它们的默认选项。

子模块的问题
例如在有子模块的项目中切换分支可能会造成麻烦。 如果你创建一个新分支， 在其中添加一个子模块，之后切换到没有该子模块的分支上时，你仍然会有一个还未跟踪的子模块目录。

子模块操作
git submodule add https://github.com/yangmin1234/test.git #将一个git仓库作为本仓库的一个子目录

git clone https://github.com/yangmin1234/test2.git clone带子模块的项目
git submodule init
git submodule update

git push --recurse-submodules=check 提交主项目时自动检测子模块是否有未提交的改动
git push --recurse-submodules=on-demand 提交主项目时，尝试自动推送一改动的子模块

使用Capistrano 3部署git子模块

我的项目回购包括Wordpress作为git子模块。通过Capistrano 3进行部署时，子模块目录是贫瘠的。

project
--wordpress
--images

我正在使用git和:deploy_via, :remote_cache

如何告诉Capistrano还部署子模块？

答案

我找到了一个来自corny的优秀脚本，它覆盖了Capistrano中的git任务。

将此脚本放在lib/capistrano/tasks/git.cap中并正常使用cap stage deploy。

https://gist.github.com/corny/7459729

# Save this file as lib/capistrano/tasks/git.cap

namespace :git do
  desc 'Copy repo to releases'
  task create_release: :'git:update' do
    on roles(:all) do
      with fetch(:git_environmental_variables) do
        within repo_path do
          execute :git, :clone, '-b', fetch(:branch), '--recursive', '.', release_path
        end
      end
    end
  end
end

另一答案

可能与capistrano v3 deploy git repository and its submodules重复。

在capistrano 3.1.x及更高版本中，您可以实现自己的SCM策略。有一个可用的宝石，有助于git子模块，请参阅：https://github.com/i-ekho/capistrano-git-submodule-strategy。

注意：如果您已尝试使用默认的git策略，则repo文件夹可能有问题。只需转到deploy目录并将其删除，然后再次运行cap deploy来修复它。