使用通用代码的Git项目 [英] Git Projects With Common Code

问题描述

我们有几个项目共享大部分代码/配置文件。我们使用的框架具有特定的目录和文件依赖性，这限制了我们可以分离通用代码的程度。例如，在'common'，'projectA'和'projectB'之间，我们可能会有：

/ projectA

• / shared_dir1
  
  
  
  • common1
  
  
  • fileA1
  
  
  • fileA2
  
  


• / common_dir2
  
  
  
  • common2
  
  ul>
  
  • / dir3
    
    
    
    • fileA3
    
    
  
  
  • common3
  
  
  • fileA4
  
  
  
  
  

  / projectB

  
  
  
  
  
  • / shared_dir1
    
    
    
    • common1
    
    
    • fileB1
    
    $ b
    • / dir3
      
      
      
      • fileB2
      
      
      • fileB3
      
      
    
    
    • common3
    
    
    • fileB4
    
    
    • fileB5
    
    
    
    
    

    我们目前使用3个Git项目来管理这个项目：'common'，'projectA'和'projectB'，并将常见文件分隔为'common'和项目特定的文件TS。 'projectA'和'projectB'有一个.gitignore，其中包含所有常见目录的条目和每个共享目录下的所有常见文件。脚本将'common'复制到您想要工作的项目中，并在那里完成开发。一旦完成更改，另一个脚本会将所有常见目录和常用文件复制回常用。然后，通过'git status'可以看到'common'和项目的变化。

    
    
    

    这显然伴随着在'普通'之间来回拷贝的麻烦，保持.gitignore准确，并在'projectA'和'projectB'内切换分支。然而，当我们计划'projectC-F'时，这种方法看起来不错，因为我们可以避免将常见变更合并到N个项目中。

    
    
    

    寻找如何更好地维护这种类型的结构。鉴于没有隔离，子模块似乎是可撤销的，除非我们做了大量的隔离。我已经看到了一些使用符号链接的有希望的替代方案，但是它也带有问题。任何建议将不胜感激。

    解决方案

    你有没有考虑过git子树？

    
    
    <可以这样做：

      git remote add common git：//server/common.git 
     git fetch common 
     git checkout -b common_branch common / master 
     git checkout master 
     git read-tree --prefix = common / -u common_branch 
      
     
     
     
    请阅读下面的链接：
     
     
     
      http://www.kernel.org/pub/software/scm/git/docs /howto/using-merge-subtree.html  
     
     
     
      http://progit.org/book/ch6-7.html  
     
    We have several projects in the works that share a majority of their code/config files.  The framework we're using has certain directory and file dependencies that limit us to how much we can segregate common code.  For example, between 'common', 'projectA', and 'projectB' we might have:
    
    /projectA
    
    
    /shared_dir1
    
    common1
    fileA1
    fileA2
    
    /common_dir2
    
    common2
    
    /dir3
    
    fileA3
    
    common3
    fileA4
    
    
    /projectB
    
    
    /shared_dir1
    
    common1
    fileB1
    
    /common_dir2
    
    common2
    
    /dir3
    
    fileB2
    fileB3
    
    common3
    fileB4
    fileB5
    
    
    We currently manage this with 3 Git projects: 'common', 'projectA', and 'projectB', with common files separated out into 'common' and project specific files in their own projects.  'projectA' and 'projectB' have a .gitignore with entries for all common dirs and all common files under each shared dir.  A script copies 'common' into the project you want to work in and development is done there.  Once a change is done, another script copies all common dirs and common files back into 'common'.  Changes to 'common' and to the project can then be seen via 'git status'.
    
    This obviously comes with its headaches of copying back and forth between 'common', keeping .gitignore accurate, and switching branches within 'projectA' and 'projectB'.  As we plan for 'projectC-F', though, this approach seems nice as we can avoid merging common changes to N projects.
    
    Looking for advice on how to better maintain this type of structure.  Submodules seem undoable given the lack of segregation, unless we did a large number of them.  I've seen some promising alternatives using symlinks, but that also comes with it's issues.  Any advice would be appreciated.
    解决方案
    Have you considered git subtree?
    
    Something like this can be done:
    git remote add common git://server/common.git
    git fetch common
    git checkout -b common_branch common/master
    git checkout master
    git read-tree --prefix=common/ -u common_branch
    Read more in the links below:
    
    http://www.kernel.org/pub/software/scm/git/docs/howto/using-merge-subtree.html
    
    http://progit.org/book/ch6-7.html
    
                            
    这篇关于使用通用代码的Git项目的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！