我意识到这是一个非常具体的问题，有些事情甚至可能使加固的git用户不寒而栗，但请忍受...
我们正在实现一个虚拟数据仓库，该仓库将生成元数据（类似SQL的代码）。产品（Denodo）可以连接到VCS（例如git），以使更改受版本控制。
内部有虚拟数据库，并且Denodo还将其代码组织到与这些数据库相对应的文件夹中。因此，在git中，您将得到类似的东西：
Root
\- Orders
\- Customers
\- Invoices
在每个这些数据库文件夹下，将有几个组成元数据的代码文件。
在git仓库中提交和推送代码总是在数据库级上完成，即使git repo没有这种区别并且提交是全局的。
开发人员在各自的数据库上本地工作，并将定期提交代码更改。所有这些更改都被拉入开发服务器。到目前为止一切顺利。
或早或晚，引入开发的变更需要找到进入质量检查和生产的方式。但是，如果我们要将开发部门（develop）的当前状态合并到质量检查部门（release）中，可能会得到一些不需要的（重大的）更改，这些更改尚未准备就绪，时间到了。
因此，我们需要 pickry 。并使用git log，我们可以看到哪些提交尚未提交到质量检查中。但是，如果我们将单个提交从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分支中以晋升为质量检查人员。
限制：
提交是在Denodo内部进行的，VCS支持并不那么出色（例如，实际上不支持更改分支）。这也意味着我们不能实现功能分支以隔离重大变化或长期发展。
虽然我们在数据库级别评估要提升的内容，但这些提交不是顺序的。
我对这个长期待解决的问题表示歉意，但这并不是典型的情况，需要更多上下文。我也不是git专家（不是很远），所以请不要使用干草叉或火把。谢谢！