如何将相关的应用程序组织成gitrepo？-HowtoOrganizerelatedapplicationsintogitrepo's?

What is the decision tree to know when to split a suite of related and/or cohesive applications into git repo's and/or branches? Should I keep each app in a repo? Or all app's & dependencies in a single repo? Or something in-between?

什么是决策树知道何时将一套相关和/或有凝聚力的应用程序拆分为git repo和/或分支?我应该将每个应用程序保存在回购中吗?或者单个仓库中的所有应用程序和依赖项?或介于两者之间?

answer How should I organize multiple related applications using git? claims that a repository per project is appropriate, but does not give clues as to what a project would be.

回答我应该如何使用git组织多个相关的应用程序?声称每个项目的存储库是合适的,但没有提供关于项目将是什么的线索。

And then there's the question of dev, test, integration test, and production checkouts when the git repo's are split. Answer how do you organize your programming work lists some branch/tag options, but ignores the multi-app details.

当git repo被拆分时,存在开发,测试,集成测试和生产检查的问题。回答如何组织编程工作列出一些分支/标记选项,但忽略多应用程序详细信息。

There's also the DB schema! incremental definition of the schema helps, but again, where would one keep this definition if the DB spans back-end and front-end app's?

还有DB架构!模式的增量定义有帮助,但是,如果数据库跨越后端和前端应用程序,那么在哪里可以保留此定义?

Some examples I've been pondering:

我一直在思考的一些例子:

1. a front-end web app and it's back-end CGI/DB: one repo or two?

一个前端Web应用程序和它的后端CGI / DB:一个或两个回购?

2. a set of web back-ends that use features from other back-ends

一组使用其他后端功能的Web后端

3. a set of front-end app's that share CSS and jquery plug-ins

一组共享CSS和jquery插件的前端应用程序

4. selenium scripts that test front-end features across dependent code - in the front-end app repo or the dependent code repo?

selenium脚本测试跨依赖代码的前端功能 - 在前端应用程序仓库或从属代码仓库?

If I want to work on a single app, it's hard (well, tedious and error prone) to check out a directory of a repo, so I have to check out the entire git tree (or at least clone the whole tree), so that implies that git is not really built for keeping all the app's & dependencies in a single tree.

如果我想在一个应用程序上工作,那么检查一个repo的目录是很困难的(好的,乏味的,容易出错的),所以我必须检查整个git树(或者至少克隆整个树),所以这意味着git并非真正用于将所有应用程序和依赖项保存在单个树中。

But if I want to keep each of the projects (app's, frameworks, dependencies, doc trees, CSS) in it's own repo, then I run into chasing my tail for dependency resolution, that is, I don't know which version of each app are compatible. I think git tags are a good way to go, if only I could move them to newer versions that maintain compatibility.

但是,如果我想将每个项目(应用程序,框架,依赖项,文档树,CSS)保留在它自己的仓库中,那么我会追逐我的尾巴以进行依赖性解析,也就是说,我不知道每个项目的版本应用程序兼容。我认为git标签是一个很好的方法,只要我能将它们移动到保持兼容性的新版本。

When app's split or merge -- as happens often with refactoring models down to baser models -- can i move the git history of just those files to another git? I don't see how to do this, so that leans towards a single repo for it all.

当应用程序拆分或合并时 - 通常将重构模型转换为baser模型 - 我可以将这些文件的git历史记录移动到另一个git吗?我不知道如何做到这一点,所以倾向于单一的回购。

If I develop a new feature across app's, it would be nice for branches to represent features.

如果我跨应用程序开发一个新功能,那么分支代表功能会很好。

I think I want a repo of repo's -- does that exist?

我想我想要一个回购的回购 - 那存在吗?

1 个解决方案