并发git checkout / add / commit

Question

我正在开发一个使用Git作为数据库的应用程序。我当前的方法是调用git shell命令，以便在应用程序发生更改时构造新的提交。这很简单，但一个很大的缺点是它不允许对数据库进行任何并发写入：两个线程不能同时构造一个提交，因为只有一个HEAD，一个index，一份工作副本。

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

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

Answer 1

自2014年以来，已经提出了一些倡议来提议一个“类似Git的”数据库：

最新的是liquidata-inc/dolt：“为数据而战”

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

它也具有在表单元格级别运行的版本控制原语。因此，Dolt是一个支持细粒度的按值版本控制的数据库，所有对数据和架构的更改都存储在提交日志中。

---

之前，采用不同的方法：SOM-Research/Gitana（2017年）。

请参见A conceptual and database schema for Git via Gitana（Valerio Cosentino）的“ Twitter”

---

更接近您正在寻找的是src-d/gitbase

G语言存储库的SQL接口，用G语言编写

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

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

---

还要注意，最新版本的Git（包括即将发布的2020年第二季度Git 2.27）已经改善了git push --atomic。

同一Git 2.27正在跨多个存储库实现两阶段提交样式的原子ref更新：请参见“ Is it possible to manage multiple repositories coherently?”。

Answer 2

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

但这可能会有一些问题：

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