1

我们的结构类似于Git 存储库的最佳实践，在传统的 n 层设计中具有多个项目，具有以下存储库：

  Shared
  ProjA
  ProjB

由2-3人的独立团队开发，使用ProjA并ProjB有时为Shared.

我们想到了一个不需要子树或子模块的简单模型，因为我们读到了很多关于这 2 的恐惧。你能回顾一下并告诉我们这样的事情是否可行吗？

  • 遵循 gitflow 模型，每个Proj和每个都存在于单独的存储库中Shared
  • Jenkins 将使用develop所有 3 个 repos 的分支中的最新版本进行构建
  • release.shof aProj将合并到masterof both Projand Shared，在两者上创建一个标签，Jenkins 将从master.

这能行吗？请记住，我们只有 8 个人，而且我们只是迁移到 git，所以我们希望让事情尽可能简单，所以如果我们可以避免子模块和子树的学习曲线，我们会更开心。或者我们会？

4

2 回答 2

1

它可以工作ProjA，只要ProjB将git notes.Shared

构建调度器背后的想法是可重现性：这样的工具需要能够重现用于给定构建的确切配置（即 SHA1 引用列表）。
这允许稍后重新访问构建。

于 2013-02-26T10:04:35.730 回答
1

我觉得你的问题不是 git 结构，而是项目的依赖关系，例如 SVN 不会让你的生活更轻松。

如果您有两个项目依赖于一个共享项目，我相信您不应该逃避指定。

如果团队 B 中的某个人在项目 A 发布之前更改了共享怎么办？您可能会对项目 A 进行不必要的更改。

为了克服你应该使用项目版本控制，这里 git submodules 来救援，子模块是项目 X 和shared的特定时间点之间的依赖关系。

git 子模块的替代方案是工件版本感知依赖项，在大多数（所有？）现代语言中，您都可以做到这一点。例如，在 Java 中，您将使用 maven/ivy/gradle 来定义项目依赖项。（您需要将共享上传到一些工件存储库）

我不会说替代方案比 git 子模块更简单，但是当项目结构变得越来越复杂且许多工件相互依赖时，这是（必须？）的方式。

于 2013-03-01T18:58:06.123 回答