CI:一个git存储库适合它吗?或者:多个项目的gitflow

时间:2014-01-12 07:36:30

标签: git continuous-integration git-flow

到目前为止,我和我的团队一直没有像生产中的自动交付流程那样。对于一些人来说这可能听起来令人惊讶,但它对我们的日常工作似乎并不重要。至少我们这么认为。我非常确定它类似于汽车导航系统或自动洗碗机 - 如果你刚刚开始使用它,你会死的。

然而,由于我们计划在未来几周内启动一个不那么小的项目,我想要注意我们不仅能够生产,而且还能尽可能快地生成更新。而且我常常每周一次,但一天多次。

我仍然不确定的是底层git存储库/存储库的组织。我们目前使用gitflow作为分支模型的单个存储库。存储库包含以下部分:

  • API
  • CDN
  • 网站
  • iPhone App

目前我们正在使用标记来标记主分支中的新版本,因为我们不能说每个提交到新版本的主结果,因为它可能与iPhone App或其中一个服务器端应用程序相关好。由于您无法将新版本的应用程序发布到Universe,因此它始终是异步的。

将所有这些应用程序放在一个存储库中的优点是对我们所有人来说都是一个非常简单的初始设置,并保证iPhone应用程序和API一起正常工作,只要开发人员在两者上使用相同的分支开发/测试时服务器(Windows)和应用程序开发环境(Mac)。

然而,感觉不对。如上所述,我们被迫使用git标签来区分应用程序和服务器应用程序的新“构建”。最重要的是,我们总是必须发布所有三个Web应用程序,即使只修复或添加其中一个应用程序。

我们可以做的是为每个应用程序引入开发和主分支。这将允许我们放弃使用标签(无论如何都不会扩展)并启动新的交付流程,每次提交到一个主分支。

我担心这会直接导致混乱,因为至少有8个“基础”分支和无数的修补程序和功能分支。

所以我的首选方案是另一个选项:将其拆分为5个存储库。每个应用程序一个,一个用于实用程序和其他与其中一个不直接相关的东西。

你的意思是什么意思?你好吗?它如何最适合你?感谢您的反馈。

1 个答案:

答案 0 :(得分:2)

  

将所有这些应用程序放在一个存储库中的优势是为我们所有人提供了一个非常简单的初始设置,并保证iPhone应用程序和API能够很好地协同工作。

     

将其拆分为5个存储库。每个应用程序一个,一个用于实用程序和其他与其中一个不直接相关的东西。

看起来像 submodules ,您仍然可以在one unique parent repo中引用所述子模块,以便于初始设置。
这也更接近于组件方法recommended here,请参阅the criteria for switching to one),它允许5个回购按自己的步调进化,并使用自己的一组分支和标签

相关问题