我们有几个正在进行的项目,它们共享大部分代码/配置文件。我们使用的框架具有某些目录和文件依赖性,这限制了我们对公共代码进行隔离的程度。例如,在“common”、“projectA”和“projectB”之间,我们可能会有以下内容:
/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
我们目前使用3个Git项目来管理此结构:“common”、“projectA”和“projectB”,将公共文件分开放置在“common”中,将特定于项目的文件放置在各自的项目中。“projectA”和“projectB”都有一个.gitignore文件,其中包含每个共享目录下所有公共目录和所有公共文件的条目。一个脚本将“common”复制到您想要工作的项目中,并在那里进行开发。完成更改后,另一个脚本将所有公共目录和公共文件复制回“common”。然后可以通过“git status”查看对“common”和项目的更改。
显然,这种方法存在着来回复制“common”的麻烦,需要保持.gitignore的准确性,并在“projectA”和“projectB”之间切换分支等问题。然而,随着我们计划进行“projectC-F”,这种方法似乎很好,因为我们可以避免将公共更改合并到N个项目中。
寻求如何更好地维护此类型结构的建议。子模块似乎不可行,因为缺乏隔离,除非我们使用大量子模块。我看到了一些有前途的使用符号链接的替代方案,但这也会带来问题。任何建议将不胜感激。
/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
我们目前使用3个Git项目来管理此结构:“common”、“projectA”和“projectB”,将公共文件分开放置在“common”中,将特定于项目的文件放置在各自的项目中。“projectA”和“projectB”都有一个.gitignore文件,其中包含每个共享目录下所有公共目录和所有公共文件的条目。一个脚本将“common”复制到您想要工作的项目中,并在那里进行开发。完成更改后,另一个脚本将所有公共目录和公共文件复制回“common”。然后可以通过“git status”查看对“common”和项目的更改。
显然,这种方法存在着来回复制“common”的麻烦,需要保持.gitignore的准确性,并在“projectA”和“projectB”之间切换分支等问题。然而,随着我们计划进行“projectC-F”,这种方法似乎很好,因为我们可以避免将公共更改合并到N个项目中。
寻求如何更好地维护此类型结构的建议。子模块似乎不可行,因为缺乏隔离,除非我们使用大量子模块。我看到了一些有前途的使用符号链接的替代方案,但这也会带来问题。任何建议将不胜感激。