2

在我的公司享受从 SVN 到Git的过渡,我们正在重新考虑我们的工作流程和开发过程以提高效率。

以下是我们项目之间依赖关系的描述:

first_app/
└── first_specific_dep
    └── common_dep

second_app/
└── second_specific_dep
    └── common_dep
  • 这两个应用程序是相互依赖的,因此单个用户故事可以涉及两个项目的开发。
  • 可以同时实现多个开发,因此功能分支似乎是一个好主意。
  • 同时,一级应用程序的开发可能涉及一个或两个依赖项的开发。

我们正在寻找更好的方式来表示 Git 内部的依赖关系,尤其是在从一个分支切换到另一个分支时。

为了在整个开发过程中保持舒适,希望根项目中的git checkout自动执行子项目中的所有其他检查,这样测试人员就不必担心依赖项的分支是什么。

4

1 回答 1

1

不幸的是,在这种情况下没有灵丹妙药。有些人试图使用 Git 子模块来解决这个问题,但据我所知,成功率参差不齐。(但是,我自己没有经验,所以我欢迎其他选择。)

在我现在的公司,我们刚刚从 CVS 过渡到 Git,我们面临着同样的挑战。我们学到了两条实用的指导方针:

  • 如果您的功能分支经常涉及多个存储库,您应该考虑合并存储库或重新组织代码。作为粗略的指导方针,您的目标应该是在一个分支上完成 90% 以上的开发。否则,功能要么太大,要么组件(存储库后面)没有很好地分离。

  • 实用功能确实是一个问题,因为您无法避免在项目之间共享它们(这就是它们的目的)。但是,大多数时候,它们应该是相对稳定的。当您在功能分支中进行开发时,您需要修改实用功能的情况相对较少。

换句话说,代码的逻辑结构越好,遇到问题的几率就越小。

最后,当不确定是否要拆分存储库时,我建议将其保留在一个存储库中。但是,如果你有一个庞大的代码库,不建议使用一个大的存储库,你的推送通常会因为非快进而被拒绝。

我们还在 Git 上构建了几个脚本,以便更轻松地检查项目及其所有依赖项,但同样,这在很大程度上取决于您的环境。

于 2013-01-18T18:58:02.827 回答