2

我意识到这是一个非常具体的问题，有些事情甚至可能会让顽固的 git 用户不寒而栗，但请耐心等待……</p>

我们正在实现一个虚拟数据仓库，它生成元数据（类似 SQL 的代码）。产品 ( Denodo ) 可以连接到 VCS (例如 git) 以将更改保持在版本控制之下。

在内部，有虚拟数据库，Denodo 也将其代码组织到与这些数据库对应的文件夹中。因此，在 git 中你会得到类似的东西：

Root
 \- Orders
 \- Customers
 \- Invoices

在每个数据库文件夹下，将有几个代码文件构成元数据。

在 Denodo 中提交和推送代码总是在数据库级别完成，即使 git 存储库没有这种区别并且提交对于存储库来说是全局的。

开发人员在他们的个人数据库上本地工作，并将定期提交代码更改。所有这些更改都被拉入开发服务器。到目前为止，一切都很好。

迟早，开发中引入的更改需要找到进入 QA 和生产的方式。但是，如果我们要将开发分支 ( develop) 中的当前状态合并到 QA 分支 ( release) 中，我们可能会得到一些尚未准备好进入黄金时段的不需要的（破坏性）更改。

因此，我们需要挑选. 并且使用git log，我们可以看到哪些提交尚未提升为 QA。develop但是如果我们从分支中挑选单个提交到release分支中，他们将获得一个新的 SHA，并且下次我们git log执行比较时，之前挑选的提交仍然会出现。

另外，请记住，存储库是按数据库组织的。这也意味着：

  • 我已经报告了在每个与数据库相关的文件夹中所做的提交
  • 决定要提升的每个数据库的最后一次提交
  • 对于每个数据库：挑选自上次合并以来最旧的提交，直到上一步中选择的提交。

这个范围不一定是连续的。你可能有这样的东西（按日期排序）。

| To be promoted | Commit | Database  | Change              |
|----------------|--------|-----------|---------------------|
|                | da39a3 | Orders    | Created views       |
|        X       | ee5e6b | Customers | Bug fix             |
|        X       | 4b0d32 | Invoices  | Removed data source |
|                | 053e2d | Invoices  | Updated credentials |
|        X       | 956018 | Orders    | Created data source |

在这个例子中，我们会挑选提交ee5e6b（客户）、4b0d32& 053e2d（发票）和956018（订单）。我也必须选择053e2d订单的原因是，最新的元数据可能建立在之前签入的更改之上（由于数据库内的依赖关系）。几乎没有数据库间的依赖关系。

要求：

  • 每次计划进行促销时，我都必须能够概述正在开发但不在 QA 中的提交。

  • 我必须能够在数据库级别选择某些更改（最多），这些更改可以合并到release分支以提升到 QA。

限制：

  • 提交发生在 Denodo 内部，并且 VCS 支持并不是那么好（例如，不真正支持更改分支）。这也意味着我们无法实现功能分支以隔离重大更改或长期开发。

  • 虽然我们在数据库级别评估要推广的内容，但这些提交不是连续的。

对于这个冗长的问题，我深表歉意，但这并不是一个典型的场景，需要更多的背景信息。我也不是 git 专家（绝对不是），所以请不要使用干草叉或火炬。谢谢！

4

0 回答 0