并发 git checkout/add/commit

Question

我正在开发一个使用 Git 作为数据库的应用程序。我目前的方法是在应用程序更改某些内容时调用git shell 命令来构造一个新的提交。这很简单，但一个很大的缺点是它不允许任何并发写入数据库：两个线程不能同时构造一个提交，因为有一个HEAD，一个index，和一个工作副本.

但是，由于提交、树和 blob 都是内容寻址的，我认为应该可以同时构造所有这些。推荐的方法是什么？也许：

• git add、git commit 等的命令行标志，明确指定要使用的不同HEAD 和index 文件。据我所知，这样的事情是不存在的。
• 对所有操作使用 git 管道命令。但是，我不是他们的专家，也不完全确定哪些是线程安全的。
• 一种 Git 服务，可以连接到传统的数据库连接，这将提供对 Git 存储库的事务性并发访问。据我所知，这样的事情是不存在的。我考虑过写一篇。
• 放弃并做一个git clone 为每个并发用户获取一个全新的工作副本。这非常昂贵。

Answer 1

自 2014 年以来，已有多项倡议提出“类 Git”数据库：

最新的是liquidata-inc/dolt: "Git for data"

Dolt 是一个关系型数据库，即它有表，您可以对这些表执行 SQL 查询。

它还具有在表格单元格级别操作的版本控制原语。因此，Dolt 是一个支持细粒度值明智版本控制的数据库，其中对数据和模式的所有更改都存储在提交日志中。

---

之前，采用不同的方法：SOM-Research/Gitana (2017)。

参见Valerio Cosentino (Twitter) 的“A conceptual and database schema for Git via Gitana”

---

更接近你要找的是src-d/gitbase

到 git 存储库的 SQL 接口，用 G 编写

它可用于执行有关 Git 历史记录和代码本身的Universal AST 的 SQL 查询。

所有三个项目都可以包含有关如何将 Git 用于这种数据库用途的想法。

---

另请注意，最新版本的 Git（包括即将推出的 2020 年第二季度 Git 2.27）改进了 git push --atomic。

相同的 Git 2.27 正在跨多个存储库实施两阶段提交式原子引用更新：请参阅“Is it possible to manage multiple repositories coherently?”。

Answer 2

另一个可能的选择是每个并发用户创建（和签出）一个新分支并提交到该分支，然后定期将分支合并到主分支。

这可能有一些问题：

1. 合并可能会失败，需要交互式干预才能解决冲突。
2. 在定期合并发生之前，用户 Y 不会看到用户 X 提交的更改。