这就是我所说的“两个维度”：通常Git跟踪一段时间内文件集合的变化（时间=单一维度）。
我想要做的是拥有一系列“步骤”，这些步骤是离散地表示的，并且这些步骤也会随着时间的推移而被跟踪。
我确信这仍然令人困惑，所以请允许我进一步澄清并提供我试图解决的用例。
我想跟踪编码教程作为Git存储库，跟踪相同代码的多个“版本”。本教程是累积性的，每个步骤都基于上一步的代码。
所以教程可能如下所示：
步骤1
第2步
第3步
在任何特定时刻，我都希望能够在教程中的任意“步骤”上结账。
现在如果教程永远不会改变，你可以简单地让每个Step在同一个分支上串行提交，然后在提交之间来回跳转。
问题是该教程很复杂并且随着时间的推移而发生变化，我希望对步骤2中引入的文件进行错误修复，以便在步骤2之后的所有步骤中更新该文件的相应部分。
现在我已经尝试在StackExchange上发布问题之前解决我的用例，但它有点胡思乱想，我希望有更好的解决方案。
我目前正在做的是为每个“步骤”使用一个分支，所以我有这样的分支：
每当我更新一个如下所示的分支时，我都会运行一个脚本：
git checkout step-1 && git rebase master && git checkout step-2 && git rebase step-1 ...
你明白了。我正在使用Git跟踪分支随着时间的推移（第一维）并使用脚本来控制我的第二个维度（按特定顺序跨分支进行级联更改）。
目前的问题是我经常遇到合并冲突，我担心所有的变基将使得回购难以公开分享。
是否有更好/更优雅的方法来解决这个用例？
有趣的问题！
目前的问题是我经常遇到合并冲突
没有办法解决这个问题。工具没有足够的信息来自动解决如何做到这一点。如果你走这条路，尽量保持增量非常小，即使这意味着更多的提交。
此外，您可以构建一个程序，知道如何从最少的信息集构建每个步骤/文档，而不是使用分支。例如，即应用增量/差异或类似的脚本。尽管如此，我认为您不会提供额外的启发式/知识，以避免与您的解决方案一样产生相同的冲突顺序;鉴于我们正在讨论的文本类型（代码，即编码教程中的很多内容），但它可能是其他类型文本/项目的一个很好的解决方案。
现在，我认为最好的（也是最简单的）是将这些步骤独立存储为不同的文件夹，但保持Git仓库中记录的步骤的差异。现在，无论何时进行更改，您都可以通过检查差异的差异来轻松验证是否已正确更新所有步骤。制作一些小脚本来自动执行这些比较/更新，然后就可以了。看看最新版本的Git中的range-diff，看看差异的差异是什么样的以及如何着色它。