标签: git-slave

我觉得使用Git子模块对于我的开发工作流程来说有点麻烦.我听说过Git子树和Gitslave.

• 是否有更多工具用于多个存储库项目以及它们如何比较？
• 这些工具可以在Windows上运行吗？

我们有一个包含N个文件夹的git存储库.

Repo
|-Folder1
|-Folder2
|- ...
|-FolderN

我们希望与不同的合作者共享不同的文件夹.每个协作者只能访问其允许的文件夹子集.使用git实现这一目标的"好"方法是什么？

答案是使用git submodules.但在我读完这篇文章之后:https: //codingkilledthecat.wordpress.com/2012/04/28/why-your-company-shouldnt-use-git-submodules/ 我明白你需要掌握好git(这不是我们的合作者的情况),以便在使用时没有问题git submodules.

我读到了一些可能的替代品,比如gitslave,和git subtree.gitslave似乎是一个很好的解决方案,但在我看来仍然是一个复杂的解决方案

这是我的简单解决方案,我想知道它是否有一些非常糟糕的缺点:

- 为每个文件夹和Repo存储库提供一个简单的存储库.然后在主Repo中添加Folder1,...,FolderN中的所有文件.

-globalpush脚本:

function globalpush(){
REPOS="$HOME/Repo/
       $HOME/Repo/Folder1
       $HOME/Repo/Folder2
       $HOME/Repo/Folder3
       # ...
       $HOME/Repo/FolderN"   

#do not show untracked files
git config status.showuntrackedfiles no

read -p "Commit description: " description

for repo in ${REPOS}
do
    # if the repo folder exists
    if [ -d $repo ]
    then
        # Go inside the repo
        cd $repo
        echo …

我有大约20个不同的存储库.许多是独立的并且编译为库,但是其他一些在它们之间具有依赖性.依赖性解析和分支很复杂.

假设我有一个只聚合所有其他存储库的超级项目.它专门用于运行测试 - 这里没有真正的发展.

/superproject  [master, HEAD]
    /a         [master, HEAD]
    /b         [master, HEAD]
    /c         [master, HEAD]
    /...

现在,为每个(a)开发特定的功能或修复,特别是需要特定版本的项目编译或运行的那些(b v2.0和c 3.0)我必须创建一个新的分支:

/superproject  [branch-a, HEAD]  <-- branch for 'a' project
    /a         [master]  <-- new commits here
    /b         [v2.0]
    /c         [v3.0]

因为b,可能需要其他东西,比如a v0.9和c v3.1:

/superproject  [branch-b, HEAD]  <-- branch for 'b' project
    /a         [v0.9]   <-- older version than 'a'
    /b         [master] <-- new commits go here
    /c         [v3.1]   <-- …

在工作中,我们正在处理十几个Java OSGi包,每个包都有自己的git存储库.从长远来看,所有捆绑包都是相互独立的,这证明了各个存储库的合理性 - 尽管现在我们仍然经常同时修改其中的几个.

当我们进行产品发布(由所有包组成)时,会在每个包中创建一个新分支,这有点痛苦.因此我们考虑使用git-submodule来缓解疼痛(类似的事情git submodule foreach <cmd>).

因此,我们所需的设置将是一个主项目Product,以及每个包的子模块:

Project/
  BundleA/
  BundleB/
  BundleC/

现在,我花了几个小时阅读所有关于子模块的内容,我明白如果我修改内容BundleA,我必须提交BundleA,推送,然后提交子模块更改Project并再次推送.

这听起来好像不是git-submodule设计为首先使用的方式.这样使用它是违反最佳做法的吗？或者听起来像一个替代选择的情况？

• 裸机git-submodule用法
• 使用现有的"git包装器":
  • GitSlave
  • 谷歌回购
• 编写我自己的简单bash脚本来批量处理OSGi包

任何其他建议欢迎.