对于我的硕士论文,我正在使用开源 CFD 模拟工具 OpenFOAM。对于那些不熟悉它的结构的人:
您通常为每个模拟案例创建一个目录。该目录由几个子目录组成,其中存储了几个 ascii 配置文件。这些定义了网格、求解器的选项等...根据模拟的复杂性,在很多文件中可能会有很多设置。
由于它通常需要进行一些试验,直到您找到一个可行的设置,所以对这些配置文件中的版本控制更改以及能够切换回以前的状态将非常有帮助。每个版本控制软件都应提供此基本功能。
我发现这篇关于使用 git 跟踪 OpenFOAM 配置文件更改的博客条目。在我自己设置之后,我可以确认 git 在这种情况下确实工作得很好。
但是,该条目还讨论了在单个案例中使用分支来进行参数变化。很多时候,我需要为我的案例创建稍微修改的副本,例如检查不同边界条件对我的模拟的影响。
在这里使用不同的分支是不够的,因为我需要比较不同修改的结果,因此每个模拟都需要自己的工作目录!
我对此的解决方案是为每个修改过的案例克隆我原来的 git-case 存储库。但是现在它变得非常麻烦,一旦我想对这个“案例族”进行一般性的改变。考虑以下场景:
- 有一个“通用”案例文件夹
- 我创建了几个“通用”的克隆,然后稍微修改了每个案例
- 我意识到我搞砸了“通用”中的设置,修复它,然后希望所有克隆也得到更新。
由于 git 不允许“向下游推送”(因为“通用”回购不知道它的“孩子”),我必须在每个克隆中手动拉取。
我的理想设置如下所示:
- 一系列案例的一个存储库
- 我的案例有一个“通用”设置(很可能以“主”分支的形式)
- 我的“通用”设置中的更改将自动集成到所有修改的(子)案例中
- 当我需要运行和比较几个版本时,我只能将它们“外包”到单独的工作目录中,其中仍然会自动与“通用”的更改同步
换句话说,与 git 背后的原始概念不同(在子分支上工作并缓慢地将更改向上游移动到 master),在我的场景中,该概念更类似于面向对象编程中的“更改继承”。
这可能吗,或者有没有办法比我目前的 git 设置更接近这个,这涉及到很多推拉?由于我是唯一一个在本地机器上工作的人,我是否应该改用像 subversion 这样的集中式版本控制工具?
更新:
多亏了这些建议,我取得了一些进展。我发现git-new-workdir 脚本几乎可以满足我关于共享配置文件和工作目录“外包”的所有要求,而无需在目录之间推送和拉取所有更改(我也知道这已经包含在 git最新版本的核心功能)。
关于“更改的继承”部分,我可以通过让所有派生分支跟踪其本地上游分支中的更改来涵盖大多数设置。合并很可能通过 post-commit 钩子实现自动化。
唯一不足的情况是一个分支是由几个“父”分支派生的。示例设置:
modified geometry <--- generic ---> generic 2D
\ /
\ /
> modified geometry 2D <
我是否可以假设 git 只能为每个分支管理一个上游分支,并且不可能从两个上游分支自动合并?