例如，Git中的默认行为是只同步一个分支，而Fossil中唯一的同步选项是同步整个DAG。Git命令、GitHub和GitLab往往在ata时间只显示一个分支，而Fossil通常同时显示所有并行分支。Git有如下命令"；再基地"；这有助于将所有相关的变化保持在一个分支上，而化石鼓励了许多并发分支不断涌现出来的风格，在几天或几周的时间里并行进行积极的发展，然后重新融入主线并消失。这种侧重点的差异源于两个系统的不同目的。Git专注于单个分支，因为对于高度分布式的集市式项目（如Linux），这正是您想要的。Linus Torvalds不希望看到Linux的每个贡献者的每一次检查，因为这样的极端可见性不适合scalewell。但化石是为大教堂风格的SQLite项目编写的，只有少数活跃的提交者。一次看到所有分支上的所有变化，有助于使整个团队与其他人的工作保持同步，从而实现更集中、更连贯的实施。因为Git将存储库数据与该存储库的初始签出混合在一起，所以Git中的默认操作模式是坚持使用单一的工作/回购树，即使是'；这是一种短视的工作方式。化石没有'；我不能那样做。化石存储库是一个SQLite数据库文件，通常存储在工作签出目录之外。你可以在任意数量的工作目录中多次打开化石存储库。一种常见的使用模式是，每个活动工作分支都有一个工作目录，因此切换分支是通过cd命令完成的，而不是通过在单个工作目录中依次检出分支。Fossil确实允许您在工作签出目录中切换分支，这也是经常做的。简单地说，化石中的任何一种选择都不会像Git中的选择那样受到严重的惩罚。标准建议是，当切换分支的干扰很小时，在Fossil中使用就地切换工作流，当存在不同的长期工作分支时，使用多个就地切换工作流，尽管就地切换会造成中断。虽然你可以使用化石风格的Git，但Git'；工作目录和pository之间的默认连接意味着使用Git回购的标准方法是只使用一个工作目录。大多数Git教程都教授这种风格，所以大多数人都是这样学习使用Git的。由于使用Git的人相对较少，每个存储库都有多个工作目录，因此这种工作方式存在一些已知的问题，这些问题不会'；化石中不会发生这种情况，因为化石存储库和每个工作目录之间存在明显的分离。这种区别很重要，因为在单个工作目录中切换分支会丢失每个交换机上的本地上下文。例如，在任何必须从源文件生成可运行程序的软件项目中，都会使每个开关上的生成对象无效，人为地增加切换版本所需的时间。最明显的是，这会影响用C、Java和Haskell等静态编译编程语言编写的软件，但它甚至会影响用JavaScript等动态语言编写的程序。一个典型的SPA构建过程涉及几个过程：Browserify转换节点包，使其'；我会在网络浏览器中运行，从SASS到CSS的翻译，从Typescript到JavaScript的转换，uglification等等。一旦所有的处理工作都完成了，在一个给定的工作目录中，一个给定的输入文件，为什么要重新工作，只切换版本？如果不同版本之间的大多数文件没有'；通常，通过使用cd切换分支，而不是在workingcheckout目录中就地交换版本，可以节省大量时间。例如，您可能有一个长期运行的活动测试正在工作目录中运行，然后接到一个客户的电话，要求您切换到一个稳定的分支，以回答有关客户正在运行的版本的问题。你没有'；I don’我不想为了把你的工作目录切换到稳定的分支而停止测试。磁盘空间很便宜。拥有多个工作目录，每个目录都有自己的本地状态，这使得切换版本既便宜又快捷。此外，cd比git checkout或fossilupdate打字更快。Git非常重视维护a"；清洁"；登记历史。独立开发人员的无关分支和实验分支通常不会进入主存储库。分支在被推动之前可能会被重新设定，使其看起来像是线性发展，或"；压扁"；让我觉得多个提交都是作为一个提交进行的。Git中还有其他历史重写机制。Git努力记录一个项目的开发应该是什么样子的，如果没有任何风险的话。相比之下，化石更强调准确记录所发生的事情，包括所有混乱的错误、死胡同、实验分支等等。有人可能会说，这创造了一个化石项目的历史#34；凌乱"；但另一种观点是，这创造了历史#34；准确" 在实际操作中，化石中可用的高级报告工具意味着增加了"；混乱"；这不是一个因素。与Git一样，Fossil也有一个用于修改先前提交的修正命令，但与Git不同的是，这不是通过替换存储库中的数据来实现的，而是通过向存储库添加一条修正记录来实现的，该记录会影响以后的Fossil操作如何呈现修正后的数据。旧信息仍在存储库中，只是从修改点开始被覆盖。Fossil几乎没有上面链接的Git文档页面上列出的所有其他历史重写机制。化石中有norebase，因此无法在提交哈希树中重新排序或复制CommitsRound。化石中没有提交元素的提交挤压、删除或基于交互补丁的樱桃采摘。没有什么能比得上Git'；化石中的滤器分支。唯一的例外是删除提交。化石有两种方法可以做到这一点，这两种方法都有严格的限制。首先是回避。有关详细信息，请参阅该文档，但简单地说，对于单个存储库中的请求，您只能获得强制遵从性。请求不会在存储库克隆之间自动传播。化石存储管理员可以合作进行另一次存储'；s sun requests跨越同步边界，这样两个管理员就可以聚在一起并同意运行某些已提交的工件，但是如果没有对接收的repo进行管理员级别的控制，一个人不能将其localsun请求强制进入另一个repo。化石'；s-sun特征不是'；t用于纠正每天的不良行为，它'；处理极端情况的方法：公开提交机密材料、罚单/维基/论坛垃圾信息、执法部门采取行动的要求等。此外还有实验性的purgecommand，它与回避的方式不同，后者不是'；在本文件中尤其重要。在30000英尺的高度，只有当你'；我关掉了化石'；sautosync功能，并希望在推送工件之前将其从哈希树中取出。从这个意义上说，它'；这和git rebase差不多——我，放下。然而，考虑到Fossil默认启用自动同步是有充分理由的，清除命令是'；这在实践中不是很有用：一旦一个提交被推到另一个回购协议中，如果你需要从历史中删除它，那么回避就更有用了。如果你觉得这些适应措施与化石'不一致；s关于持久不变的提交的理念，认识到如果从Fossil中删除了回避和清除，您仍然可以使用SQL DELETE语句从存储库中删除artifacts；毕竟，存储数据库文件是可直接修改的，用户可以编写。化石哲学真正占据主导地位的地方在于，很难破坏哈希树的完整性。它'；这有点牵强，但文件"；Fossila是区块链吗" 涉及这个和相关的话题。一位评论员将Git描述为根据胜利者记录历史，而化石记录的是实际发生的历史。Git中的一件事'；commitfrom push的默认分离是，在可能测试更改之前，有几个Git子命令直接跳到提交步骤。相比之下，Fossil只对本地工作签出进行了等效的更改，需要单独的签入步骤来提交更改。这种设计上的差异自然来自化石#39；它的默认启用DautoSync功能及其不提供历史重写功能的理念。Git中的一个主要例子是重定基址：如果成功，localrepository会立即发生更改，即使您没有'；我还没测试过这种变化。它'；在Git这样的工具中，这样的设计是有可能的，因为它没有自动同步功能，因为在将本地更改推送到父回购之前，您仍然可以测试更改，但同时您'；我对本地Git存储库进行了持久的更改。你必须做一些激烈的事情，比如git reset——如果重新基址导致问题，在推之前很难恢复该基址或重写历史。如果你在没有先测试的情况下将你的重定基本地回购推高给母公司，你就无法在不违反重定基金规则的情况下修复它。较小的例子是Git merge、cherry pick和revert命令，所有这些命令都将工作从一个分支应用到另一个分支，并且所有这些命令都会立即将其更改提交到本地存储库，而不给您先测试更改的机会，除非您给出--no commit选项。否则，你'；我们回到了同一条船上：重置本地存储库或重写历史以修复问题，然后再尝试。Fossil无法明智地以这种方式工作，因为它默认的enabledautosync功能及其故意缺少命令