在版本控制方面，我们能做得比 Git 更好吗？
你认为有可能做出比 Git 更好的版本控制系统吗？
还是说问题已经解决，Git 就是版本控制系统的终结者？
你也许感兴趣的：
- 理解 git blame：一篇简介
- 【外评】为什么 Facebook 不使用 Git
- 【外评】Git 的故事：这次没那么有趣
- 【程序员搞笑图片】最刺激的话
- BitKeeper、Linux 和许可纠纷：Linus 如何在 14 天内写出 Git
- 【程序员搞笑图片】Git 音乐播放清单
- 您应该使用的现代 Git 命令和功能
- Git 2.40 发布，包括 git jump 工具的更新、cat-file 工具的增强以及提高 Windows 上响应速度
- 告别SVN，Git成“独苗”：GitHub 在 13 年后宣布淘汰Subversion支持
- Google 和 Facebook 为什么不用 Git 管理源码？
如今，很多人都是第一次也是唯一一次接触 VCS，就把 Git 扔进了火坑。
我虽然没那么老，但也用过 RCS、CVS、SVN，最后是 Git。我很早就开始使用 Git，那时 GitHub 还没出现。你可能不相信我，但 Git 解决了我所有的问题。之前的那些系统都有根本性的架构缺陷，这让它们在团队中用于任何严肃的工作时，都是一场彻头彻尾的噩梦。
而 Git 就没有这样的问题。它没有做不到的事。相反，唯一的限制在于用户是否知道如何让 Git 做他们想做的事。值得庆幸的是，只要快速阅读文档或进行网络搜索，问题总是可以迎刃而解的。
我明白，既然用户界面如此复杂，人们可能会想让它变得更简单，但这是行不通的。如果抽象掉用户界面的复杂性，就必然会抽象掉它的强大功能。如果你抽象掉了功能，你就不再能解决 Git 所解决的所有问题。人们只是没有意识到Git解决了什么问题，因为他们从未经历过以前的VCS所带来的问题。
你知道有什么比创建一个比 Git 更好的新 VCS 更简单吗？你知道有什么比使用与世界其他地方不同的 VCS 更容易吗？你知道什么比在 Git 的基础上设计一个神奇的抽象更容易吗？
学习 Git。
无论你花了多少精力去寻找或建立一个替代方案，不如把这些精力用在成为 Git 专家上。这将事半功倍。请相信我。无论对你的职业生涯还是个人计算生活，这都是值得的。
虽然我觉得这对大多数程序员和知识工作者来说都是正确的，但 Git 绝对不适合一些行业的工作流程，包括我所从事的游戏行业。
使用虚幻引擎（Unreal Engine）这样的引擎开发任何规模的项目，都需要处理成千上万的活动文件（我当前项目的仓库 HEAD 有大约 40 万）和成百上千 GB 的活动文件，其中很多文件本身就有好几 GB。我们的版本库（在 perforce 中）目前大约有 10TB 大小。
在这种规模下，即使使用 LFS、部分克隆、浅层拷贝和 fsnotify，Git 也会崩溃。再加上技术含量较低的人（艺术家、设计师、视觉特效师、音频师等）使用 Git 的必要性，Git 真的是一个不入流的工具。
我非常讨厌 Perforce（自 2007 年以来，我一直在使用它，偶尔也对它进行专业管理），但我勉强承认，它是目前唯一能以实用方式满足该行业所有要求的公开可用 VCS。Plastic 和其他 VCS 还没有做到这一点。
这个问题在 git 上已经解决了。我做过比你更大的项目，其历史记录大到你想克隆都克隆不了。我明天会记下要在谷歌上搜索的内容，但基本上历史记录是完全可用的，只是 git 知道如何通过网络查询。当你打开一个文件时，它会通过网络加载它。远程构建系统会完成你的构建。
其中大部分都是微软为在 Windows 上使用 git 而构建的。
我们在 2010 年代末从 SVN 迁移过来，天哪，这改变了我们的工作流程。我们不再是在团队中传阅补丁文件进行代码审查，而是像在 GitHub 上一样实际审查代码。这真是太神奇了。
微软有很多解决方案来处理他们庞大的 Windows 仓库：现在，它在官方 git 客户端的基础上又打上了一堆 MS 专用的补丁，但显然这也不再需要了，因为部分克隆现在在 azure 上也得到了支持（这是微软员工在 GitHub 和上游 git 上的另一种实现）。
是的，问题解决了，多亏了微软。事实上，这个问题已经解决了多次，而且因为是微软，所以并不是所有的 Linux 安装程序都支持：https://github.com/microsoft/scalar/issues/323#issuecomment-…
https://github.blog/2020-01-17-bring-your-monorepo-down-to-s…
https://devblogs.microsoft.com/devops/introducing-scalar/
https://github.com/microsoft/git
https://devblogs.microsoft.com/devops/git-partial-clone-now-…
谢谢！
>其中大部分是微软为在 Windows 上使用 git 而构建的。
在我看来，把 git 黑客化并不能算是学会使用 git。
显然，git 并不能解决所有问题，而探索其他选择、构建新系统来填补其他空白，才是真正的价值所在。
它还是 Git。Git 基本上是内容可寻址存储，上面还有几层（头/标签/树），本身就是内容可寻址存储。如果你能把存储卸载到远程，那么你仍然拥有 Git……并能像以前一样使用 Git。难点在于如何让人感觉存储是本地的、自己的，而不是共享的。
只有在你需要的时候，你才会需要它。坚持使用 vanilla git，你可以走很长一段路（数百名程序员近十年的日常提交）。
> 此外，技术含量较低的人（艺术家、设计师、视觉特效师、音频师等）也有必要使用它。
Git 如何解决这个问题？
也许他们只是需要遵循由更多技术人员精心编写的说明？
这招什么时候管用过？为什么这对你来说是一个解决方案，而不是一个糟糕的变通办法？
阅读和遵循手册有什么用？比如，永远？别再假装有简单的解决办法了。人们只需要动动脑子。无论是编写手册的人，还是阅读手册的人。
实际上，对于非技术人员来说，已经有了一种更简单的解决方案，它叫 Perforce，很多游戏工作室都在使用它。
但我相信你比整个行业都要聪明，所以你可能知道得更多。
嘿，聪明人，这是一个关于 git 而不是 perforce 的主题。仅供参考。
直到永远？人们又不是生来就对任何软件的工作原理了如指掌。
手册/指南/教程是教人们做任何事情的最有效方法。
回忆起使用 SVN 时的痛苦，我流下了眼泪
这就是为什么你需要 Artifactory 这样的二进制版本库，而不是将大文件存储在 Git 中。不过，您仍然可以在 Git 中跟踪它们，并将大文件保存在 Artifactory 这样的二进制版本库中。
如果你的工具集成了引用而非拷贝功能，这个问题就能迎刃而解。例如，依赖项可以用源代码/名称和版本来引用。为了确保可用性，所有这些使用过的 blob 都可以有效地存储在其他地方并进行版本控制。
Perforce 能正常工作真是太好了，我听说图形领域的其他人也在使用它，因此它满足了我们的需求。不知道 GitHub 用户是否或何时会有这种普遍需求。
这听起来像是把 excel 用作数据库。用锤子敲它的头，宣布它不适合正常人使用。
我也从事游戏工作，我认识的所有人都使用 Perforce，原因如上所述
你有没有想过，也许他们的用例与你不同？
我的意思是，从来没有人说过 git 是用来直接保存大宗资产和资源的，所以这么做是在用锤子而不是不痛不痒的画笔作画。
是的，它们当然有不同的用例。这只是同一件事的另一种说法而已。
这篇文章的想象力太差了，会让人因为 C 语言比汇编语言好得多而停止开发 C 语言。
如果你对 Git 没有意见，那我为你感到高兴。我当然对 Git 有意见，比如它无法有意义地处理大型版本库（享受 Chromium 签出吧！）、神秘的 CLI 命令、在分支间移动提交时的 “睁一只眼闭一只眼 “以及其他锋芒毕露之处。
Git 之所以能保持如此顽强的生命力，很大程度上得益于托瓦尔兹的编写和 GitHub 的网络效应。这并不是因为其他 VCS 方法缺乏更好/同样好的功能。
我认为创造一个比 git 更好的 CLI 绝对是有可能的，但我认为大多数不满意 git 的用户在要求更好的用户界面时所想象的，都会把事情过于简单化，最终会去掉很多有价值的功能。这些功能可能并不适合非技术人员使用，但我相信对于专业软件开发人员来说，它们应该是管理软件开发生命周期的利器，超越了特定的语言或领域。
以你提到的在分支间移动提交为例，git rebase 参数和 –onto 标志肯定会让人感到困惑，但只要理解了它们，每一个都是清晰而必要的。CLI 可以重构得更清晰，但最难的部分是理解每一个参数的含义，即使有更好的 CLI，你也需要这样做。显然，我们可以绕过这些知识空白，但一旦理解了它们，它们就会在我们的整个职业生涯中发挥作用，而相对于具有强大功能和坚如磐石的架构权衡的 git 工具，这些缺陷的重要性就会逐渐减弱。
git 在处理大量文件时仍有问题。我把 sec Edgar 数据库下载成了文件，我想这将是存储和观察更改的好方法。
没有。
太慢了。它不喜欢数以百万计的文件。我所有能 “快速 “查看 git 状态的工具都锁住了终端和代码等。
您试过 git 内置的文件系统守护进程（git fsmonitor–daemon start）吗？
有一个很大的误解，以为 “提交 “是移动的。实际上，git 历史记录中的每个提交都是指一个特定的目录状态及其父级提交。你无法直接 “移动 “一个提交。樱桃挑拣和重置的作用是
1.客户端会将您的提交内容与之前的提交内容进行比较。2.在另一个提交的内容上应用这种差异。3.使用步骤 1 中的旧提交信息/作者创建新提交。
这也是让每个人都能使用 git 的原因，因为它只是一个包含了大量 new_new_updated_project 类固醇的目录。至于怎么处理，就看你的了。
> 无法有效处理大型软件源
出于好奇，还有哪些 SCM 工具能更好地做到这一点？
我还没玩过很多，因为工作（谷歌的 Piper 和 Git）和孩子让我根本没有时间。Piper 处理 monorepo 的方式是，只有当文件系统在指定提交时提出请求时才提供文件（这可能是一种粗略甚至不正确的简化，但它就是这样呈现给用户的）。
我们有充分的理由保留整个提交历史，以发布真相来源，但与此同时，如果我们要完全信任 GitHub 这样的网站（很多人都这么做），也没有理由不完全信任提供 Piper 模型的类似网站，因为它提供了某种机制，可以请求将多个提交带入本地存储（以获得更多真相来源）。
归根结底，大型 repo 签出会受到网络、CPU/存储空间的限制，无法执行存档扩展，或者经常是两者兼而有之。我的印象是，Android 和 Chromium 的扩展速度要快于其他方面的改进速度，但没有数据可以证明这一点。
几乎所有大型游戏工作室都在使用 Perforce
> 神秘的 CLI 命令
是命令的语法有问题，还是所有 CLI 命令对你来说都很复杂？如果由你来设计，你会建议使用什么样的命令语法？
>我明白，由于用户界面非常复杂，人们可能想让它变得更简单，但这是行不通的。如果抽象掉用户界面的复杂性，就必然会抽象掉它的强大功能。
我不同意，真的。
在 98% 的情况下，用户界面都是友好的，而在这 2% 的情况下，用户界面都是 “高级 “的，这并不是根本原因。
就像图形用户界面有 “高级 “设置一样，CLI 也可以有精心设计的 10 条命令，先教新手基本用法，然后再教高级用法。
问题是，对于 99.99% 的人来说，他们的正确答案是 “别争了，学学 git 吧”，因为没有比 git 更好的了。他们需要停止思考 git 有多烂，因为那只会阻碍他们实现职业目标，是一种自我毁灭。
而且，如果有人真的想取代 git，无论如何都得先了解 git 的工作原理，达到高级专家的水平。到那时，你们就可以讨论如何让 git 更好地支持 LFS/monorepo，拥有更舒适的用户界面/用户体验等等。
1.这就是所谓的 “斯德哥尔摩综合症”。
2.从字面上看，任何相关的职业目标都不会因为 git 熟练程度较低而受到明显阻碍。
什么？也许我误解了您的意思，您是说缺乏 git 知识不会影响职业发展吗？我想这取决于工作的类型。
git 不也是这样吗？如果你只做基本的工作，我想你不需要超过 10 个命令。如果你想更进一步，你还可以使用其他命令和标志。为了方便新手，Git 还增加了一些新命令，比如`switch`。
那就做吧。很多人都试过了。都失败了。空谈误国。
我认为 Mercurial 的用户体验比 Git 更简单，但功能并不弱。我认为我创办的 Jujutsu（见这里的其他帖子）也有更简单的用户体验，而且在很多方面比 Git 更强大。你看过这两个软件吗？
大约十年前，我尝试过 mercurial 和 Git，当时我只有 subversion 知识。我记得我发现 mercurial 非常令人困惑，而 git 则非常简单，但不记得 mercurial 为何令人困惑的细节了。
相反，我很高兴 Mercurial 的出现让我不再需要处理 Git 的暂存区（对我来说，Mercurial 的交互式提交也能达到同样的目的）。
Magit 很不错。所以并不是所有人都失败了。
但你说的 “这是不可能的，相信我 “更便宜，因为它是一个更有力的主张
>那就去做吧。很多人都试过。都失败了。空谈误国。
我和很多人一样，都在用 GitHub Desktop（或 Git Kraken 或 Git Extension，但我不喜欢这个）
当我在图形用户界面环境中工作时，这证明它是可行的。
创建 CLI 封装的第三方工具的问题在于，你无法依赖系统是否安装了该工具。
这就是为什么这类解决方案通常会失败–因为你有可能依赖于那些可能不会被广泛使用的东西，从长远来看，你最好还是坚持使用 “官方 “语法。
在此，我想分享一下我对 GitExtensions（Windows 上）的积极看法。它确实帮助我更好地使用和理解 Git，同时也帮助我定义工作流程并与同事分享。
其他图形用户界面，如 VisualStudio、VSCode 或 Rider 中的嵌入式图形用户界面，都试图把跳过某些操作的认知步骤说成是简化或加快了开发流程。我觉得它们只是提供了额外的（超越 git 本身提供的）方法，让你自寻烦恼。
gitk 还能和 git 一起使用吗？功能没那么齐全，但非常适合查看，而且可以处理很多提交/文件。
是的
很多人都是这样！
> 我明白，由于用户界面非常复杂，人们可能想让它变得更简单，但这是行不通的。如果抽象掉用户界面的复杂性，就必然会抽象掉它的强大功能。
Git 的用户界面就有很多 “无用 “的复杂性。命令的命名和底层概念很不一致。命令本身也不一致。即使是 Git 的粉丝，也很少有人质疑用户界面远非最佳。而用户界面中的缺陷正在得到改善。
当你习惯了这些界面缺陷后，它们就会变得无影无踪，但在教授 git 的时候，它们又会变得显而易见。
git 的底层架构非常简单，而正是这种简单造就了 git 的强大。强大的工具并不一定需要复杂的界面。事实上，强大的功能往往来自于简单的界面。
我们可以把别名慢慢融入 git。比方说，用 git undo 代替 git reflog，或者类似的东西。支持几个做同样事情的名字，让人们使用自己喜欢的那个，这并不难。
我们正在慢慢实现这些。例如，现在有了 git restore（和 git switch）来解决超负荷签出的问题。
当你的 repo 进入需要 reflog 的状态时，很可能无法使用非常直接的命令。更大的问题是，进入这种状态有点 “太容易 “了。
最初的 git 界面并不是真正为了 “通用 “而设计的，在低级的 “管道 “之上应该有更友好的 “瓷器”。但人们开始直接使用管道，”瓷器 “就没出现过。
git 模型有其根本的局限性，因为它保存的是快照而非变更，而且无法捕捉重命名等元数据变更。像 Darcs 这样的工具或它的后代会比 git 产生更少的合并冲突。
不过我完全同意你的主要观点。切换的好处远低于成本。
>它保存的是快照而不是更改
一旦你明白了这一点，GIT 就变得更有意义了。合并失败的问题是 GIT 试图让自己看起来像是在追踪三角洲。当你是产品的唯一程序员（但有多台电脑）时，合并冲突会让你抓狂。
在了解到这个简单的事实之前，我曾不止一次因为无法解决合并冲突而毁掉 .git 和里面的所有东西，重启版本库。
我从软盘上的源代码 .zip 文件到 SVN，再到 Mercurial，最后到 GIT。虽然 GIT 的用户界面让人头疼，但大多数人都同意，GIT 确实很棒。
不仅是合并冲突，我发现如果你需要管理多个分支，这也会带来麻烦。一般来说，你会看到这样的模式：1. 创建补丁 2.合并到主分支 3.回传一个选取。
但没有机器可读的元数据来证明这两种情况下的提交是相同的。在简单的情况下，你可以根据合并基础打补丁来解决这个问题，但如果存在冲突，就不好办了。
这样做的结果是，这两个不同但逻辑上相同的提交会导致未来的合并冲突，并使 “这个分支是否有这个补丁 “之类的问题变得更加难以回答。
我认为 https://pijul.org/ 在这方面做得很好。他们的基本单元是一个补丁，可以应用到多个地方。你也可以有快照，快照在逻辑上是补丁的集合。
> 不能捕获某些元数据变化，如重命名
如果你用 git 重命名了文件，而这是文件中唯一的变化，那么它就能正常工作：
git mv oldfile newfile
提交该改动，重命名就会出现在历史记录中。
git mv “是 “git rm “和 “git add “的简写。Git 只知道以前有一个叫 `oldfile` 的文件，现在有一个叫 `newfile` 的文件，以及它们是否有相似的内容或文件名。只有当你运行 `git status` 或 `git diff` 或其他程序时，它才会真正尝试猜测是否有任何东西被重命名了。所以你看到的并不是重命名被记录在历史中，而只是猜测是否正确。如果你做了一些非同小可的改动，或者有多个类似的文件，它就很容易变得不正确。
上一条评论的建议是逐一提交这些改动，这样可以保证检测算法正确无误。不过这肯定会污染你的历史记录。
重命名不会出现在历史记录中，因为树和提交对象不支持重命名
工具会根据没有内容更改来推断重命名
有区别吗？
完全正确。在移动和编辑的情况下，git 有时会根据本地版本、设置和编辑细节推断重命名，有时则不会。如果推断失败，你可能会更难解决合并冲突、执行筛选等问题。
所以只要确保移动和编辑在不同的提交中就可以了？
是的，这是标准的解决方法。
完全正确，这种推论是基于一套启发式方法，而且经常是完全错误的。
我遇到过一两次非常烦人的合并，就是因为重命名而变得复杂。多亏了这些回复，我才知道这其实不是重命名。
> 如果您使用 git
什么也做不了。Git 不会记得你重命名过。
> 而这是文件中唯一的改动
这总是有效的，但这意味着你需要在不稳定的重命名检测和可能无法编译的奇怪的额外重命名提交之间做出选择。
> … 因为它保存的是快照而不是更改…
我可能记错了技术细节，但不是只有在没有打包文件的 git 仓库中才会这样吗？
我承认，当一个文件在重构的同时被大量重构时，重命名时缺乏元数据可能是个问题。
https://en.m.wikibooks.org/wiki/Understanding_Darcs/Patch_th…
快照不是比没有快照快得多吗？
> Git 没有这样的问题。没有它做不到的事。
它不能显示我正在工作的分支，从分支开始的提交开始，直到最后一次提交。(就算能，我也不知道怎么做）。
这不是功能问题，而是概念问题。从根本上说，Git 对分支的理解与我不同。(对我来说，一个分支从……我分支它的时候就开始了。对 Git 而言，分支始于……版本库中的第一次提交，因为他们认为在分支点之前的提交仍是分支的一部分。对 git 来说，分支点不过是另一个提交，甚至不是他们认为重要到需要强调的提交。但如果不能清楚地识别分支点，你就会经常发现自己在林林总总的提交中寻找与真正搜索内容无关的内容。
前几天，我花了一个多小时的时间试图找出如何识别分支点。(顺便说一句，我最终找到的最佳解决方案是：cat .git/refs/heads/<branch name>）。当然，这只是我的一知半解，但在我看来，这太荒唐了–与其他 VCS 相比，这是 git 的一大功能差距/用户友好性问题。
在我看来，git 只是 VCS 进化过程中的又一步，甚至不一定是更好的 VCS 之一。它的概念、功能和特性集主要集中在分布式开发和多人维护不同的源代码树上……这对于 Linux 内核和其他大量使用这种情况的项目来说还不错。但许多/大多数项目并不是这样工作的，对他们来说，集中式 VCS 就足够了。我毫不怀疑，总有一天会有更好的 VCS 出现并取代 git。
git log <base-branch>..<branch>
我经常需要提交的次数，通常是为了构建 ID、
git rev-list –count <branch> ^<base-branch>
我通常用 gitk 来查看分支提交。CLI 相当于
git log –graph –oneline –all
他是说找到 <base-branch> 太难了。也许 git merge-base 或 git show-branch 有什么神奇之处，但我对它们还不太了解，所以做不到
Git 会将整个历史记录保存在本地机器上，如果项目增长到几百 GB（在游戏开发中并不罕见），这就成了问题。即使是 SVN 也更适合处理大型版本库，你只需要一个大服务器。对于 “只有源代码的项目 “来说，Git 还是不错的。
这是事实，但从技术上讲，这是一个实现问题。Git 支持浅克隆和窄克隆。数据模型在只有部分本地知识的情况下也能正常工作。尽管如此，”将所有文件检出到磁盘 “的方法在许多操作上确实存在根本限制。它是极少数与树大小呈线性关系的操作之一，但对于 Git 的抽象模型来说，它并不是最基本的。为了解决这个问题，类似于虚拟文件系统这样根据需要获取新数据并跟踪更改文件的方法，可以使几乎所有的日常操作随着补丁的大小而不是树的大小扩展。这种跟踪变更的数据模型基本上等同于 Git 的索引结构，只是应用于工作树，而不是把工作树留在通用文件系统上。
尽管如此，不幸的事实是，很多很多 Git 用户都依赖于作为 API 的实现，直接读写 `.git` 目录的各个角落。因此，即使核心命令可以支持这样的功能（或提供一个封装器），也可能会遇到很多工具问题。
为了解决这个问题，微软创建了 git 虚拟文件系统，以便将 Windows 迁移到 git 上。后来它被 “Scalar “所取代。
https://learn.microsoft.com/en-us/previous-versions/azure/de… https://github.com/microsoft/scalar
我有很多庞大的文件，因此使用 SVN。它的托管费用很低，几乎不需要内存，而且因为是在 WebDAV 基础上构建的，所以还自带网页用户界面。你完全可以在浏览器中打开 repo。
唯一的缺点是每个文件的版本控制，更新需要在顶层目录运行，否则会出现有趣的问题。
git 支持浅克隆。
Git LFS 能解决这个问题吗？
总的来说，LFS 给人的感觉是一个非常笨拙的附加解决方案，而且还有缺陷。
如果误将某些文件添加到 LFS，Git LFS 就会变得非常可怕。
恢复到无 LFS 状态应该很容易，但总是很痛苦。
应该有办法告诉 repo：我不想要任何 LFS。在实践中，这样做很痛苦，而启动一个新的 repo 更容易….。
此外，出于某种原因，Github/Microsoft 决定将 LFS “货币化”。托管和传输的免费限制都是 1GB！然后收费就变得非常昂贵了。
我不知道为什么 Github LFS 的定价像 AWS S3 计划而不是 OneDrive 计划。
GitHub 对 LFS 收费，在微软介入之前，GitHub 就已经开始收费了。此外，定价模式正在发生变化，将包括至少 10GiB 的免费服务（团队/企业客户为 250GiB）。不过，这只是成本回收和防止滥用，并不是什么邪恶的计划。你提到 AWS S3 还真有意思……GitHub 可能要收回哪些成本？）
微软的本土 LFS 实施（Azure DevOps 中）不会也从未收取 LFS 费用。有云 blob 存储服务的朋友真好！
资料来源：微软我曾是 Azure Repos LFS 服务器的产品经理，目前是 GitHub 所有 Git 事务的产品经理。
我曾目睹多个团队在使用 LFS 时出现重大问题–为了保持艺术团队的工作效率，支持工作变得相当繁重。
没错，就是这个问题。Git LFS 应该能解决这个问题，但我也没见过它能完美运行。
有趣的是，我在使用 Git LFS 为我的个人网站存储图片时也遇到过问题。我以为我只是不知道如何正确使用它…
不是 Git LFS，而是 Git VFS，现已被 “Scalar “取代：
https://github.com/microsoft/scalar
完全同意。
从 SVN 到 Mercurial 是一次日以继夜的体验。从 Mercurial 到 Git，最初只是微不足道的改进，但长期而言却是持久的变化。
还有一些 “可视化 “的 VCS，比如 Rational 和 TFS，它们被设计为只能在集成开发环境中工作，要想了解它们，就得翻阅数百页的公司技术文档。
在使用 Git 之前，VCS（至少我使用过的 VCS）一般都很糟糕。
所有软件构建都涉及基本任务，即构建构成抽象软件实体的复杂概念结构，以及意外任务，即用编程语言表示这些抽象实体，并在空间和速度受限的情况下将这些实体映射到机器语言中。
Git 解决了分布式版本控制这一极其复杂的问题。大多数对 Git 的抱怨实际上是对问题本质复杂性的抱怨，而不是对用于解决问题的工具的偶然复杂性的抱怨。
我完全同意，人们花了太多时间抱怨 git 的解决方案，但对它 99% 的时间都在解决错误问题的事实却批评不够。
我想与一位同事分享 5k LOC。任何认为这需要在 2023 年采用分散式解决方案的人都是不健康的。
我最近浪费了几个小时，就是因为在运行某些代码前忘了取数据。当然，用户界面可以做得更好（如果你很累，而别人告诉你已经更新了，你就会愚蠢地相信），但从根本上说，导致这个问题的 “功能 “我永远不会使用。我总是要通过连接互联网来编写代码。我不需要在脑子里跟踪本地和远程的区别，因为这种区别根本就不存在。
你不明白的是，在所有关于去中心化的讨论之外，保持本地状态是一项巨大的性能优化。过去，标记一棵大的 CVS 树要花上好几分钟，因为它会就每个文件分别与远程服务器进行对话。在 Git 中，浏览历史记录和分段是一件非常愉快的事，因为本地计算机已经掌握了所有信息，只需将其呈现给你即可。
你仍然可以在本地缓存东西，只是用户不需要知道而已。我现在输入的内容并不是每次按键都会立即传送到中央服务器，本地状态仍然存在，但它仍然是一个客户端-服务器架构。
我工作的版本库通常比普通网页还要小，我真的不相信在高清流媒体时代，带宽问题会是一个问题。
顺便说一句，我所工作过的团队中没有一个使用过类似 bisect 这样的 git 功能。对 git 的崇拜意味着每个人都必须使用 git，尽管对大多数人来说，使用 git 只意味着浪费大量时间上网搜索，却毫无用处（就许多团队的使用情况而言，使用 git 完全不如通过网络硬盘共享文件）。
缓存比去中心化更棘手，因为很难知道缓存何时有效。而 Fetch/push 则明确了这一点，这与 git 无关。
与此同时，还有人在飞机上和树林里工作。
不使用 git bisect 是你的损失。我很高兴它的存在，也不会用 git 来交换网络硬盘上的文件。
是的，把 “何时更新到服务器/从服务器更新 “的问题推给用户正是我所抱怨的。我使用的其他软件都不会这么做。如今，即使是原本在本地运行的软件，也可以无缝更新到服务器或从服务器更新（例如，在 Word 中处理云文档）。而且，任何从一开始就能做到这一点的软件往往都会有很好的用户体验（例如 Figma）。
你完全可以建立一个系统，在 git 远程文件更新时获取它，只是需要某种通知/订阅系统来知道何时触发它。
你完全可以建立一个系统，在每次提交时推送（部分？
对我个人来说，这样会很烦人；每次我和 git 服务器对话时，我都想坚持用 Yubikey touch。
“在 Git 中，历史浏览和分段是非常令人愉快的，因为本地计算机已经掌握了所有信息，只需将其呈现给你即可”。
这可能是唯一一件让我不那么怀念 SVN 的事了。
对 git 的大多数抱怨都与该工具的设计理念有关。虽然分布式版本控制存在复杂的边缘情况，但人们实际遇到的绝大多数情况并没有那么复杂。但由于 git 优先考虑的是最坏的情况，而非典型情况，因此它的可用性大打折扣。
这也是我喜欢 git 的地方。它给人的感觉就像一个功能强大、随时可用的工具。CVS 和 SVN 更官僚、更慢、更有限。我只用了零点一秒就放弃了其他所有工具。
底层模型对很多人来说都是陌生的，有时需要非黑盒的方法才能摆脱困境，但对我来说，这总是值得了解的。
关于 git，我唯一不喜欢的是焊接中转区的想法。大多数人一天要堆栈 109 次是有原因的，而我认为将两者合并是一个好主意。
我基本同意 Git 几乎能做任何事（但也看到了其他人提出的限制），不过这种说法很容易被推翻：
不管你花了多少精力去寻找或构建一个替代方案，不如把精力放在成为一个 Git 专家上。
建立一个替代方案自然比一个人学习 Git 要花费更多精力，但并非每个人都需要这么做。
我想说的是，重建 Git 并不能解决问题：
git 之所以好，是因为它强大而灵活。
这种强大和灵活必然会让 Git 变得更加复杂和难用。
你可以构建一个更简单的系统，但现在一半的 Git 用户将无法使用它，因为它没有他们需要的功能。
如果一个系统既拥有现在 git 的所有功能，又能解决目前存在的问题，那么它将会更加复杂，使用起来也会更加困难。
最好的办法可能是有一个具备所有功能和灵活性的通用后台，以及多个不同的前端，这些前端经过简化，只提供特定工作流程所需的功能。
> 我用过 RCS、CVS、SVN，最后是 Git
我用过 CVS、SVN，后来又用过一点 Git。
我记得从 CVS 到 SNV 的最大卖点是 “你可以在里面放二进制文件！”。……但我们从来没这么做过。
而现在，我看到从 SNV 到 Git 的卖点是 “你可以做一些非常复杂的事情，比如重新加载”….，而我们从来没做过。
对于一个只做日常分布式版本控制工作（提交、差异、指责、冲突解决）的团队来说，你能解释一下为什么 Git 比 SVN 有这么大的优势吗？
SVN 并不能很好地解决冲突。尤其是当有多人在多个分支上工作，而他们又可能想合并彼此的某些工作时，这就更成问题了。除此以外，git 还提供了更多高级功能来改进分支和历史管理。
很好的评论。
Git 真的需要一个好的 git 家教游戏。
就像 vim tutor 或任何一款 n*x/shell 游戏一样。
您希望 VCS 在哪方面比 git 更 “优秀”？
举例来说，git 的 cli 用户界面非常畸形（是的，我知道，你个人已经记住了 800 条 cli 命令，而且每次都能正确使用，但这并不能说明它 “好”）。从一开始，git 的维护者们就认为 “让所有 cli 标志的行为和交互都保持一致太费事了”，所以他们没有这么做。这让 git 得以快速发展，却牺牲了 cli 的用户体验。
话虽如此，但 git 的规模已经足够大，以至于多家公司都 “解决 “了 git 的用户界面问题。这些售后用户界面层没有一个是完美的，但它们的数量足够多，差异也足够大，无论你个人对 git 用户界面有多不满意，都能找到一个适合自己的（例如 [0]、[1]、[2]，它们解决的用户工作流程问题截然不同）。
[0] https://git-fork.com/
[1] https://graphite.dev/
[2] https://news.ycombinator.com/item?id=7565885
在 Windows/.NET 开发领域，我通常听不到太多对 GIT 的抱怨，这可能是因为有很好的用户界面前端，而且坚持使用 CLI 也没有那么多 “硬汉 “的威信。Visual Studio 在抽象 GIT 的细微差别方面做得不错，但我个人使用的是 GIT 扩展，它在 Windows 上的外观和感觉都比其他跨平台用户界面要好得多。
我偶尔也会使用 CLI，尤其是多步骤或自动化脚本，但你可以从我手中撬开一个漂亮的可视化提交图和功能齐全的集成差异查看器。GIT 功能强大，选项繁多，是用户界面辅助发现的完美工具。CLI 感觉就像在文本编辑器中编程，而不是真正的集成开发环境
> Visual Studio 在抽象 GIT 的细微差别方面做得不错，但我个人使用 GIT 扩展，它在 Windows 上的外观和感觉比其他跨平台用户界面要好得多。
集成开发环境和文本编辑器有时会在用户界面中集成 Git，但我想要的是独立的软件，可以用于各种编程项目、游戏开发项目（使用 Git LFS）或任意文档。
最后，我花了点钱买了 GitKraken，它相当不错，尤其是在同一平台上有多个账户时，切换起来非常方便：https://www.gitkraken.com/。
还有我之前用过的 Sourcetree，有点慢，但功能齐全：https://www.sourcetreeapp.com/
对于更轻量级的软件，我还喜欢在各种操作系统上使用 Git Cola：https://git-cola.github.io/ 甚至 Git 文档都有一个页面介绍现有的软件，其中很多都是免费的，并有很好的平台支持：https://git-scm.com/downloads/guis
坦率地说，我现在 90% 的时间都在使用 GUI 界面，因为我想轻松地合并一些东西，或在提交中包含多个文件的特定代码块，或处理其他大多数常见操作。当然，有时也需要使用 CLI，但你说得没错，一些图形用户界面软件确实提高了可用性。
> 使用 CLI 就没有那么多 “硬汉 “的称号了。
这可能就是这些讨论的全部内容，好的技术官僚沙文主义：)
Vs 代码 + git 图形 + git 镜头，这就是快乐的 git 体验所需要的一切。
这个！任何不能同时显示所有分支的 git 图形历史记录都是垃圾。(Git Graph 中的交互式回溯编辑器也很不错。
我还喜欢在 VS Code 的 git CLI 和图形用户界面之间流畅地跳转。
我得看看如何在 Git Lens 中比较任意提交，以及免费版中是否有这个功能。这是我仍然依赖 TortoiseGit 的一个原因。
差异和冲突解决是如何进行的？
[不是你要回复的人］
Vscode 有一个内置的（相当不错的）三向合并编辑器和一个出色的可编辑差异视图。GitLens 也能轻松地在 vscode 中对任意两个参考源进行差异分析。
谢谢！
Windows 上的 TortoiseGIT 是杀手级的。没有它，我很难编写代码。
我也是一个狂热的 GitExtensions 使徒。
我真希望 4.* 版能支持深色主题，这是我使用 3.* 版的唯一原因，我害怕有一天会因为某种原因而不得不更换…
我只是想重复马丁的话，但是：如果你能显示造成这种情况的版本库，或者至少截图（或其他）显示你看到的情况，并把它发布到 GitHub 上，我们中至少有人能帮你找出问题所在。
我已经创建了一个讨论。谢谢两位
https://github.com/martinvonz/jj/discussions/2691
根据描述，我无法判断问题出在哪里。请随时提交错误报告，或在 GitHub 上发起讨论，或在 Discord 上提问。
Jujutsu 版本控制系统汇集了其他 DVCS 的精华，并在各种概念上进行了创新，看起来很有前途。HN 上曾多次讨论过它。
[0] https://github.com/martinvonz/jj
[1] 4 个月前，261 条评论 https://news.ycombinator.com/item?id=36952796
[2] 2 年前, 228 条评论 https://news.ycombinator.com/item?id=30398662
约翰-维勒
我试过这个，非常喜欢。它与我的工作流程配合得非常好。
也许作者可以解释一下–当你用
jj git clone
会拉下一个自动生成的分支，如 pull-(hash)
我不知道如何才能不损坏这个分支，所以当我做 jj 日志时，我得到了非常奇怪的分支或头部，我也不知道是什么。
另一种说法是，在我从另一台机器上拉下 repo 之前，一切都很正常，但之后的分支历史就和我想象的不一样了。我无法理解它，也无法让它与我的预期相符。
实际上，我创建了一个自定义的 GPT，并向它提供了 jj 代码和文档，试图让它向我解释，但毫无效果。Jj 是如此优秀，如果能解决这个问题，我愿意放弃集成开发环境与 git 的集成。
很惊讶这竟然是在 Rust 中完成的。我无法想象不在 Python 或类似语言中完成这样的 v1,以便能够快速更改。也许设计者的思路非常清晰。
谷歌目前的 DVCS 解决方案是基于 Mercurial 的，而 Mercurial 是用 Python 写的。我曾在 Mercurial 上工作多年，因此不想用 Python 编写 jj。我们在当前解决方案的性能方面遇到了问题。此外，正如其他人在兄弟姐妹的回复中所说，由于缺乏静态类型，重构 Python 并不有趣（我知道情况已经有所改善）。
我在 Python 中的工作效率并不高。代码写得比较快，但对于大写编程来说，它是一种相对较弱的语言–缺乏类型意味着要经常重复和检查自己。
我的感觉恰恰相反。
尽管 Python 是我用得最多的语言，但我还是不想用它来做不确定性很大、会有很多变化的事情。类型系统能让我们更容易在早期改变一些东西，而不会破坏一切。我可能会选择 F# 或类似的语言。
其实 F# 中也有类似的项目：https://github.com/ScottArbeit/Grace
Rust 是一种非常适合重构的语言。强类型和完全匹配使得在进行修改时几乎完全不可能遗漏任何地方。
除了静态类型的争论之外，其他回复还有其他优势。对高效版本控制系统的需求是一场持续不断的战斗；你可以选择正确的数据结构（例如，Git 在大文件方面的问题与其说是原始效率问题，不如说是数据结构问题），但归根结底，Python 在原始性能方面往往会落后。我们希望 Rust 能让我们把 Jujutsu 库嵌入到其他语言中，而这在今天的 Git 中只能通过 libgit2 来实现。最后，我们可以使用的许多基础架构，如 nextest 和 cargo-insta 都非常棒，尽管我对 Cargo 有一些保留意见。
包括我在内的大多数开发人员（其中一些人曾是 Mercurial 和 Git 开发人员）似乎都很喜欢它。根据我自己的经验，我认为 Cargo 是一个相当不错的选择，但作为一个死硬的 Haskell/C 程序员，我还是希望它能快速处理各种类型。
Python 当然能让你快速改变事物，因为它不会让你自动执行任何不变式；这也是为什么它能让你如此轻易地进入非同寻常的不一致状态！我个人永远无法想象因为 “这是 v1,我会正确地做成 v2 “而试图用果冻做拼图。
是的。从 Sqlite 的创造者那里，你得到了 Fossil。
Fossil 最神奇的地方之一是，你不仅能追踪文件的历史，还能向前追踪，而这在 git 中是很难做到的。
https://www.fossil-scm.org
我最近开始使用它的服务器 api，将用户的反馈从 web 直接转到 fossils 的票务系统。它非常成熟，功能齐全，我真心希望有一天它能像 sqlite 一样得到广泛认可。
> 您实际上可以进入 sqlite 数据库并更改内容
任何与历史相关的东西都不能通过操作化石数据库来改变。就数据库记录而言，相对于空间而言，数据库大约 80-90% 是数据的瞬时缓存，由剩余的（100% 不可变的）数据生成。你对暂存数据所做的任何更改，都会在下一次缓存被丢弃和重建时丢失。更详细的解释请参见
https://fossil-scm.org/home/doc/trunk/www/fossil-is-not-rela…
谢谢你的澄清！我还是想买一件化石 T 恤 🙂
是的，一定有更好的解决方案。Git （通常）比其他替代方案要好，但还远远不够。尤其是其功能的可发现性，简直是一团糟–神秘的命令行咒语、神奇的进程。有时，在绝望地运行你在 stackoverflow 上找到的第 12 个命令之前，只有祈祷才能帮上忙。一旦你离开了 “拉-提交-推-合并-基数 “的圈子，你就得寄希望于上帝的帮助，因为没有人会帮助你（或者更像是没有人能帮助你）。
当然，除非你花时间学习 git，但它的复杂性已经快赶上 C++ 了。而使用 VCS 不应该需要那么多精力。它只需要让路（我必须承认，只要你只使用基本命令，git 通常都能让路……但当它挡路的时候，乐趣就开始了）
git 的内部运作并不复杂。真正的问题在于，git 只是在内部运作的基础上提供了一个薄层。需要替换的不是 git，（它只是在保存大量数据）而是上面的用户界面。简化用户界面的问题在于，抽象掉复杂性是一件超级困难的事。
亚琛
Git 给我的感觉很像 pgp：不知何故，即使只需要几个按钮和输入框，我们也没能把事情做得足够简单，以方便大众使用。
两者之间还是有区别的，比如 pgp 在引擎盖下更为复杂，而且它是一个需要万无一失的加密系统，而在 git 中，你可以在大多数情况下对数据进行 nuke 和 re-clone，而不会丢失数据，更不用说机密性/完整性丢失了。感觉很相似的一点是，只有专家用户才能正确使用它，而大多数可以使用它的人却懒得学习，因为可用的界面太费劲了（无论如何，除了基本操作）。
我不确定是否所有问题都能通过更简单的用户界面来解决，或者是否需要一个更简单的底层系统来进行更简单的标准操作。
在我看来，Git 确实有一个很大的架构问题–原生存储单元是 blob，而不是 diff。如果存储模型是 “diffs “而不是 “blob”，那么像 rebase、cherry-pick、3-way merge 等操作就会容易得多。这样一来，CLI 工具就会更简单，陷阱也会更少。
二者可以互换；计算机可以用二者中的一种制造出另一种。存储 deltas 会降低普通操作的速度，因为获取文件内容需要重放历史上的所有 deltas。
我不知道有多少命名和定位都很糟糕的文件存在于软件源中，因为人们不想破坏历史记录。
不是太复杂，但超级难以抽象，这有点矛盾。也许内部工作原理很复杂，但一旦你理解了它们，要正确实施并不复杂。
我想我们已经有了，化石。不幸的是，网络效应很难克服。但有了 Fossil，你就能得到一个架构优雅的系统，其中包括大量的锻造工具，而这些工具的缺失导致 git 仓库集中在 github 等地方。它更简单、更理智、更小巧、更强大。
我不知道有什么更好的解决方案，但可能有更好的界面。我最喜欢的理论是，更多地关注 repo 是一个有向图这一事实会有所帮助。让语言更像图形（少一些 “提交”，多一些 “节点”；少一些 “分支”，多一些 “路径”；少一些 “版本库”，多一些 “图形”）。我认为，这种思维会暴露出更多应该更明确地呈现出来的原型（在 git 中，很多事情都是 “可能但不容易 “的），也会让有数学背景的人更容易学习。网络搜索也会变得更容易。
(我肯定我以前说过这些，但都被否决了，所以……）。
是的，这里是 git 最糟糕的地方：
* 用户体验，很明显。
* 大文件（LFS 是一个集成度不高的黑客工具）
* 超大型项目（大公司代码库）。对稀疏/部分签出、有状态操作的支持较差（例如，在 Linux 上，git status 每次仍会扫描整个 repo），对子模块的支持较差且漏洞较多。
* 冲突解决。这已经是最基本的了。例如，即使是 zdiff3 也不能提供足够的信息来解决某些冲突（你需要的是引入冲突的变更的差异）。所有的差异算法都很快，但都很笨。基于补丁的 VCS 系统（Darcs、Pijul）在这方面显然更胜一筹。
在我看来，Jujitsu 和 Pijul 是试图解决这些问题的最有趣的项目（可惜不是全部）。
> 差分算法都很快，但很笨。基于补丁的 VCS 系统（Darcs、Pijul）在这方面显然更胜一筹。
git 的核心功能之一不就是基于补丁的系统吗？
我的理解是（如果我说错了，请指正），Linux 补丁可以通过邮件列表以 diff 的形式提交。这样一来，提交者就与修改的所有者不同了（这也反映在 git 的设计中）？Darcs 和 Pijul 是否只是在原始源文件上打了一串补丁？
Got 可以打补丁，没错。但我指的是当它有两个提交（是快照，不是补丁），并使用差异算法在它们之间合成一个补丁时。
从计算机科学的角度看，它使用的算法很好（算法复杂度低、长度最小等），但从语义学的角度看（分割代码块等）却很糟糕。
有一些尝试（DiffSitter、Difftastic）可以改进这种算法，但它们尚未与图形用户界面集成。
据我所知，Pijul[0] 的目标是更好地解决冲突和保证合并的正确性。我对理论不是很懂，所以不能很好地解释它，但它看起来很有前途。
[0] https://pijul.org/
我唯一希望 git 能更好地处理大型/二进制资产的问题，无需任何标记/设置。
LFS 虽然还行，但对我来说仍然是个小玩意儿。
我对 cli 并不感冒，因为有很多工具都提供了替代/覆盖/用户界面。我并不是说它很完美，甚至也不是说它很好，但至少对我来说，它已经足够好了。
我只希望二进制支持是 Git 本身的一部分。
老实说，将大型二进制文件保留为松散对象也不错，除了性能问题，这应该可以通过牛文件系统来改善（LFS 确实使用了牛文件系统，但受限于 Git 的实现所能支持的范围）
也可能只需要逐步改进 lfs 就够了，我确实看到了对 ssh 的支持，这可能会有点帮助。
sqlite 的 Fossil 和 Facebook 的 Sapling 也这么认为 https://sapling-scm.com
Subversion 真的很不错。它并不完美，但却相对轻松。
相反，每个人都改用了 “分布式 “版本控制系统，这种系统非常麻烦，现在全部由一家公司托管。
托瓦尔兹喜欢在飞机上写代码，那时候你还不能使用互联网，而这是我听说过的唯一一个我同意分布式有意义的用例。
现在的孩子没有 chat-GPT 根本无法编码，无论如何都要有一个托管 git repo 的中央服务器，整个架构就像是为拨号上网而设计的。
除了客户端-服务器源代码控制之外，我想不出有什么在 30 年前可以在计算和带宽方面做到，而现在却因为性能原因而做不到的事情了。
我的第一份工作使用 SVN，与 git 相比，它限制了工作流程。分支的成本更高，因此人们需要调整工作流程。我在那份工作中使用的是 git-svn，它允许我在本地进行重构；一旦推送，我或其他人就无法使用这项功能了。
我的同事评估过 git，认为它太复杂了。几年后，他们都用上了 git。我不知道这是否是来自足够多的年轻新员工的同侪压力，但结论是明确的：git 比 SVN 更好。
除了 github 之外，许多公司都在托管 git（例如 gitlab 和 bitbucket 这两家），你也可以在自己的硬件上或私有云 vps 上，在 1 分钟内架设一个自己的 git。
Github 服务器比 subversion 服务器更容易设置。人们使用 Github 的原因是它免费，而且它有问题跟踪、维基和分叉功能，而普通 Git 对此一无所知。
如今，GitHub 提供了更多的功能，如 GHAS、代码空间、Copilot、操作和工作流等，以至于那些根深蒂固的公司如果要从 GitHub 迁移到其他公司，就需要六七个不同的供应商来提供这些功能。
总的来说，我觉得他们的 gh cli 工具没有得到足够的赞誉。能在 shell 脚本（或终端）中进行简单的 API 调用和查询非常棒，而 gh copilot 偶尔也能帮助你复习命令语法，或破译一些网上找到的奇怪 git 命令。
这是个巨大的难题，很少有人有理由去解决它。我不认为有任何东西能像 git 一样与之抗衡。要打破 git 的统治地位，需要范式的转变和全新的版本控制产品/方法。
> Github 服务器比 subversion 服务器更容易设置。
你无法设置 GitHub 服务器。
@dreamcompiler 给我的建议是 “git 服务器比 subversion 服务器更容易架设”，我觉得确实如此。
不，这不是真的。使用 “svnserve “部署 SVN 服务器只需几分钟。
https://svnbook.red-bean.com/en/1.8/svn.serverconfig.svnserv…
是的，我打错了。
不过……你可以在内部服务器上架设 Github，至少以前是这样。请咨询 Github 销售人员，并准备好开支票。
你可以从他们的网站下载虚拟机镜像
你完全可以在自己的机器上安装 vanilla Git，但请先试用一周。在谷歌上搜索了一下，Github 占据了版本控制领域 80% 的市场份额，剩下的则是 Dollar Store Github（Gitlab）。每个人都在使用建立在它之上的漂亮工具栈，因为它过于复杂。Git 并没有添加任何其他 VCS 无法添加的功能。
> Github 服务器比 subversion 服务器更容易设置。
又来了。你错了，我的朋友。启动一个基本的 SVN 服务器只需几分钟。你只需运行几个简单的命令即可。
我的第一份编程工作使用的就是 Subversion。即使作为一个刚出道的程序员，我也知道我们完全用错了。
我的第一项任务就是花几天时间，从两个相差将近六个月的分支中挑出一个极其糟糕的合并冲突。这对我来说是一件非常愚蠢的事情，因为我这双白痴的手正在为一个重大的重构工作祈福。
管理层不知道他们想如何维护主/生产分支。
我们的 “主干 “是开发分支，任何时候我们都想推送到生产….。我们都会删除主分支并复制一个开发分支。主分支没有历史记录，你必须追溯到开发分支，并希望能从那里找到踪迹。
那是一段非常糟糕的时期，我们留下了一个非常糟糕的产品。我离开的时候，代码库已经腐朽不堪，我们已经放弃了修复更深层次问题的所有希望。
我真的很讨厌 subversion，但主要原因是公司管理不善。我相信你能以理智的方式使用 SVN，但不是像这样
我最近开始了一份使用 SVN 的新工作，但有一件事让我很头疼，那就是 SVN 不能自动添加新文件。有没有什么简单的窍门可以让 SVN 自动递归跟踪文件夹下的所有文件？
你用的是 CLI 还是 TortoiseSVN？Tortoise 有一个相当直观的用户界面，可以在提交时添加未跟踪的文件。
拜托，Github 可不仅仅是 git 托管。如果 Github 只提供源代码托管服务，那就没人会喜欢它了。
Github 并不全是 git，但所有 git 都是 Github。
假的。我现在正在用 git 做两个大型分布式项目。这两个项目都与 Github 无关。
我觉得你这句话的意思是，GitHub 的功能是 Git 功能的超集，这似乎没错？
“Github 并不全是 Git [GitHub 的某些功能并不在 Git 中]，但所有的 Git 都是 Github [但 Git 的所有功能都在 GitHub 中]”。
也许我的理解有误？
除了大家都在谈论的 git 前端问题，后台也有待改进。它现在是面向行的。如果它知道你所写的语言的语义，就能显示语义上的差异，那就更有用了。这样还能为二进制文件提供一种模式，而 Git 现在还不能很好地处理二进制文件。
事实上，后端不是以行为导向的，而是前端。后端不会剖析文件，哪怕只有一行有改动，它也会存储整个新文件，并依靠对象压缩来查找其余部分的相似性。
在获得能理解语义差异的 vcs 之前，我们需要一种沟通语义差异的方法。这样，每种文件类型都可以有自己的 “语义差异”。就像语言服务器帮助集成开发环境抽象出差异一样
你们都知道可以更改 git 使用的差异查看器吧？
当然可以。但差异仍是以行为导向的。
如果你使用的差分工具不是基于行的变化，差分就不必以行为导向。
Git 本身只是存储文件的快照，然后你就可以使用自己的差分工具，它可以以任何你想要的方式工作，并不局限于基于行的差分。
您已经可以更改。Git-lfs 已经使用了这种机制
不，他们没有。
你可以使用 .vscode 文件夹中的共享配置来设置很多配置，然后使用你选择的任何规则集和任何方式来执行。我们使用自动保存、Typescript 的漂亮引擎、C# 的 C# 引擎、C++ 的标准 VSC 引擎、Rust 的 Rust 插件等等。从技术上讲，不同的开发人员采用不同的方式会更自由一些，因为如果你想不使用我们的 “标准 “也很容易，但如果你不遵循我们为语言定义的语法，它很可能无法通过我们的 CI/CD 管道，或者在少数情况下（如缩进、行结束）会被简单地修改为标准。
我同意你关于不同集成开发环境的观点，但我认为 VSC 实际上是帮助开发团队统一编码方式的更好工具之一。话又说回来，我们所有的开发人员都使用 VSC，只有一个人例外，他还停留在普通的 VS 中，而且经常因此说一大堆脏话。我自己使用普通 VS 也有 10 年了，这几乎就是普通 VS 的传统经验。使用某些插件后，VS 的运行速度变得如此缓慢，各种模板也是如此臃肿，这仍然让我感到惊讶。不过，他用得很开心，也很生气。
如果您使用的是 PHP 或 Java 或类似语言，情况可能会有些不同，VSC 可以说比竞争对手差很多，但仍可能有一些开发人员喜欢使用 VSC，因为他们也使用其他语言。或者在使用 Python 较多的环境中，也有很多优秀的集成开发环境可以用于 ML/AI/BI 方面的工作。
Codice Software 是一家西班牙公司，该公司在被 Unity 收购后将其扼杀……
对于非程序员，您有什么建议？
举例说明：- 使用标记符/静态网站生成器出版书籍的作者。使用 Typora 等可视化编辑器。- 开源硬件的产品设计师。使用各种设计文件、SVG 等。
我曾尝试过 “仅使用图形用户界面 “的 git 流程–只是想看看有什么可能，好把这个概念介绍给其他人。
我发现 GitHub 桌面应用 (https://desktop.github.com/) 在直观展示 git 流程和功能方面做得很好，但对于非技术/编程人员来说，这个工具会让人望而生畏。
我很好奇您建议的技术堆栈是怎样的–除了终端……
我可能会推荐 Mercurial，比如像 TortoiseHq 这样的用户界面。它拥有 git 90% 的价值，而且界面更好。
Github?你可以在线编辑和提交。你可能永远不需要分支或合并
Git 将代码库视为可变的。它能很好地修改历史记录，以反映你希望的结果。这对大型团队的开发工作很有必要–这意味着历史记录大多是对功能或代码结构的一系列原子变化，当 CI 判定补丁不足时会有一些还原。
Fossil 将历史记录视为不可更改的。你的错误、迭代、失败的实验都会被认真记录下来。我喜欢这样，这意味着我以后可以重新审视错误的步骤和被放弃的分支。不过，这显然是一种扩展危险。我不希望看到成千上万的其他人在黑客的帮助下不断增量。我也不想禁止这种探索。
我的个人工作都在化石仓库中进行，十年来我在不同的操作系统和化石版本中工作。它从未让我失望过。
一个明显需要改进的地方是语义版本控制。
如果 VCS 不仅能了解更改了什么，还能了解更改对代码的影响，那么它就能推断出许多关于提交块的有趣事实。
比如忽略简单的重构（如重命名）、减少合并冲突等。
是的，它会被取代。新东西会 “更好 “吗？我想这取决于衡量标准和需求。”ls “已经完成了，但 exa/eza 出现了，而且它们拥有用户。
思来想去，我能想到的大多数简单事情其实都是 Git 上的工作流程问题。Git 并没有完全强制执行所有这些问题，所以如果无法适应，也许更紧密的集成会成为改变 Git 的一个理由。除此以外，很难想象新一代工程师会为了做新事情而不做新事情；会有一篇 “认为 git 有害 “的文章，或者会有一个 “现代 “的 git 替代品。
我个人认为，Fossil 就是一个很好的例子，它在一些严肃的项目中得到了广泛应用。还有一个叫 pijul 的，理论上看起来也不错，但我还没使用过。我认为在软件层面之前，版本控制总体上就已经有些问题了，但这两个项目正在解决其中的一些问题。我认为，Fossil 更适合大多数人的操作规模。
Perforce
至于 DVCS，我用过的最好的是 Darcs: https://darcs.net/ 但它也有一些缺陷（特别是指数时间冲突解决），阻碍了它的采用。
幸好有了 Pijul，它与 Darcs 类似，但 a) 解决了这个问题；b) 是用 Rust 编写的！这大概就是完美的 DVCS 吧！https://pijul.org/
当然，还有改进的余地…最大的问题之一是可用性/用户体验：pull、fetch、checkout、commit、push、rebase–这些都是什么？我的工作需要简单的英语术语，比如更新和保存，仅此而已。我为什么要担心实现细节和术语呢？如果我不能向我妻子解释清楚，那么我就不能用它来处理她需要存储在 repo 中的二进制文档……在这种情况下，Subversion 对她的文档来说是一个更好的版本控制系统……只需 SVN 更新/SVN 提交–Subversion 没有什么可学的了…
想象一下，一个电子工程师抱怨示波器不好用，因为他无法向妻子解释那些旋钮的作用。我们是专业人士，我们的工具应该为高级用户提供强大的功能，而不是为初学者提供方便。
一个工具既要对初学者友好，又要对高级用户强大。
就您的比喻而言，大多数软件开发人员所扮演的角色并不是对示波器感到疑惑的工程师，而是对安装电气设备的建筑工人感到疑惑的电缆夹为什么会有如此奇怪的接口。无论是办公室里的示波器工程师，还是在现场工作的工人，都会因为拥有一款简单可靠的工具而受益匪浅。
当然，有能力和 “适当的 “软件工程需要特殊的工具和详细的培训，但我认为这是一个利基市场，由自己制作工具的人来填补。
在我看来，当今大多数开发人员都在从事砌砖工作（这当然需要技能，我并没有低估它），如果有更简单的工具，他们会受益匪浅–他们根本不需要知道如何使用示波器。
> 在我看来，当今大多数开发人员都在从事砌砖工作（这当然需要技术，我并没有低估它），如果有更简单的工具，他们会受益匪浅–他们根本不需要知道如何使用示波器。
他们是在做砌砖的工作，直到不做为止。大多数问题都很容易解决，不需要大惊小怪。专业知识在于了解哪些问题值得大惊小怪，哪些不值得。
技术在我们的生活中越来越多，而不是越来越少。
将软件工程降格为低技能行业，而事实上，软件工程的复杂性堆积如山。而在很多方面，它已经是这样了。
> 将软件工程降格为低技能行业，而事实上，软件工程的复杂性堆积如山。在很多方面，它已经是这样了。
我完全同意这一观点，但现实情况就是如此。
如今，软件质量对大多数软件来说根本不重要。只要计费工作正常，管理层就会乐于看到你的网站勉强运行–反正钱都到手了，还管什么质量。
这样的软件成本低得多，砌砖工人就能砌好。
人们一直在推动软件工程的商品化。不幸的是，这导致了一窝蜂地想拿开发人员的薪水，却没有工作或专业知识。
Git 确实有一些缺点，但你说得没错。它是一款供专家和专业人士使用的行业工具。版本控制问题本身就存在一定的复杂性。
学习如何使用工具是任何行业的必修课。
>它是供专家和专业人士使用的行业工具。
如果你说的是 Kubernetes、LLVM、Ghidra 等工具，我会同意。
但不是 git。这不是什么专家工具。
这个工具的目的只是管理角色的历史，仅此而已。
其他任何与文字打交道的职业都可以使用 Git，比如文章作者、书籍作者等等。
> 这个工具的作用就是管理角色的历史记录，仅此而已。
是的，但你似乎严重低估了问题的复杂性和 git 所能解决的用例数量。
我不同意。任何事情都有可学之处，但我们生活在一个时间有限、资源有限的世界。所以，你可以把时间花在学习 git 上，也可以把时间花在实际工作上。
专家和专业人士使用 git 并不能成为用户体验不佳的借口。专家和专业人士几乎从来不是 Git 专家或专业人士。我每天都在用车，但这并不代表我就是个机械师。必须了解一个工具的内部运作是设计不佳的表现，而不是我们应该努力维护的把关。
我认为这里有两件事被混淆了。
一个是：如何有效管理代码库的长期变更？Git 有一个模型，在日常使用中，它有 “提交”、”分支 “和 “标记 “等原语。此外，你还必须了解工作副本、暂存提交和历史上任何其他提交之间的区别。将这些元素与你可以使用它们进行的操作结合起来，实际上有些复杂。这就是我所说的人们需要学习的东西。而人们却经常抱怨这一点。
另一个问题是 git 的组织结构、每个子命令的参数和标志，以及如何向用户展示。我认为 git 在这方面还有很大的改进空间。尽管如此，该工具仍然存在。所以，你可以选择完全使用另一个 VCS，使用另一个前端，或者学习如何按原样使用 git。
如果你选择使用 git，却刻意回避学习例如什么是 rebase 以及它的用处，那你就是在选择做一个低效的开发者。它在某些方面会更好吗？是的，但事实并非如此。
我不认为汽车的比喻特别有说服力。汽车的 “基本原理 “已经比 git 的简单得多。汽车的基本原理是 “开快点 “和 “开慢点”，以及一些辅助性的东西，比如管理大灯、挡风玻璃除霜、雨刷和喇叭。
虽然汽车上正在添加更多的工具（如倒车摄像头或碰撞检测），使其更加安全，但这些工具的复杂性也在迅速增加，使其更容易发生故障。驾驶员绝对不能因为其中一个安全工具失灵就可以免于造成事故。您仍然必须知道如何在各种情况下安全驾驶车辆。
我经常从学术界学习 LaTeX 的人那里听到这种说法。这很难，我没有时间学习。有人花了多年时间掌握高等数学，有人花了多年时间学习如何构建和操作最先进的实验装置。但出于某种原因，却从来没有时间学习软件工具。
是的，但如果示波器上有一些按钮，一旦按错就会毁掉整个公司的代码库。
如果整个公司的工作都被编排到一个原型中，那么示波器确实有这样的按钮：)
>我们是专业人士，我们的工具应该为高级用户提供强大功能，而不是为初学者提供方便。
您可以两者兼得–功能强大且用户友好。
认为工程师的工具必须是一团糟，只要能做事就可以的想法是愚蠢的。
每当讨论 C 或 C++ 与 Rust 时，都会重复同样的论点
“只要学好 C 和内存管理（以及所有怪癖）就行”。
“只要使用这种新的语言结构就可以了……”
而实际上，我们最终发现了大量的 CVE – Chrome 浏览器和 Windows 中 70% 的 CVE 都与内存问题有关。
完全没有理由 git 的 CLI 不能比现在更好。再说一遍–没有理由。
证据？有 CLI 封装程序，甚至 GitHub Desktop 这样的图形用户界面，都能让整个体验变得更好。
同意。想象一下，一名飞行员抱怨操控不够简单。
老实说，我甚至无法想象你想象中的 “git 保存 “和 “git 更新 “在另一个宇宙中会有什么作用。
这很有趣，因为在以 PR 为导向的开发中，我开始用 IDE 中的 “保存 “来处理提交、
它只是当前状态的备份，带有无关的提交信息。在 PR 的描述中，所有内容都会在工作结束时进行描述，然后进行合并。
将巨型 PR 压缩到一个提交中是一种反模式。每个提交都应包含一个逻辑变更和一个描述性的提交信息。
遗憾的是，业界有很多人都没有做到这一点。
如果你曾在一个有提交纪律的项目中工作过，你就会知道这样做有很多价值（重排序变得更容易，你可以释放 bisect 的威力，log 其实也很有用）。
这个
此外，如果每个提交都在逻辑上自成一体，并附有漂亮的提交信息，那么做 PR 代码审查时就会舒服多了。
但这样一来，你就不能用 blame 来查看当前的代码状态了。而且，要还原自己的改动也会变成一场噩梦。
刚开始使用 Git 时，我做了一个别名，立即执行 “git add . && git commit -m ‘lazy’ && git push”，这样就能方便地保存我的工作，并确保它也在服务器上。
我觉得 git 保存就是提交，而更新就是拉取？
我觉得他们只是想用自己喜欢的替代词来替换其中的一些词。因为总有一天会有人认为，update 应该是 syncronise 而不是 pull，save 应该是 push，因此 git 是最糟糕的。
那你最好还是用 Subversion 这样的工具。
Git 是分布式的，这意味着你无法摆脱推、拉和获取，无论你怎么称呼它们。
如果你想要的只是一种避免制作 “New New Presentation FINAL 2 “的方法，那么大多数源码控制系统的几乎所有功能都是多余的。
对我来说，这并不意味着 Git 需要修正，而是意味着它绝对不是适合你工作的工具。
如果问题出在使用的特定词语上，使用别名是一种直接的解决方法。不过，如果是为他人使用别名，就会破坏在线搜索帮助的可能性。
在我看来，Git 一直缺少的功能就是分支的版本控制。当然，这样做的直接后果是你可以回滚对分支的修改，但也会带来一些更根本的后果。我敢肯定，Git 的图形用户界面（GUI）/封装程序之所以会出现一些问题，就是因为没有对分支/标签进行跟踪。
除此之外，如果只考虑它要解决的功能，在我看来它几乎就是终结者。如果有一天另一个 “更好的 “VCS流行起来，我觉得这必须是对VCS工作方式的巨大改变，甚至比从SVN到Git的改变还要巨大。Git 中的一些缺陷或许可以被剔除，从而在理论上让 Git 变得更好，但在现实世界中，这永远不会发生（除非我们被其他行业或平台抢了先机）。
Phabricator 和 Gerrit 在这方面都做得很好。在我看来，Git 作为一个纯粹的 “版本控制系统 “运行良好，但在分支合并到共享分支之前的协作过程似乎超出了版本控制的范围–这正是更高层工具的理想用途。
你能说清楚 “分支的版本控制 “是什么意思吗？Git 中的分支只是对象的标签。你说的是像 reflog 那样，记录某个分支之前标注过哪些对象？
是的，我觉得 reflog 更像是对 Git 仓库进行自省的工具，而不是协作工具。这是我觉得 Git 所缺少的东西。如果你在看一个仓库的主分支，那么这个分支的上一个版本是什么？
我们解决这个问题的方法就是给提交打上标签，这样我们就不会忘记某个版本是在哪个版本发布的。一连串的发布标签基本上就是一个元分支，是发布分支的历史记录，但不是通过 git 而是手动管理的。
如果使用合并提交，这个问题就能迎刃而解。
在本地的 “git reflog “中，有一种对分支进行版本控制的方法，你可以看到分支别名是如何被移动的
可以。git 的缺点是不能很好地处理二进制文件，也不能克隆一个 repo 的片段。
像这样吗？https://github.blog/2020-12-21-get-up-to-speed-with-partial-…
我看到过。浅克隆有太多升级到完整克隆的理由，而且会给服务器造成额外负担，所以并不完全有用。部分克隆（目前）还不能让我直接检出版本库的子目录，而检出根植于该子目录。
mercurial或perforce在很多方面都优于git，而且像谷歌和Meta这样的大公司已经对他们最初使用的系统进行了大量的黑客攻击，以至于很难说他们仍然是perforce/hg。虽然有一些缺点，但在我看来，更好的系统显然是可能的。在我看来，真正的问题在于 GitHub 是否是终结者。
我相信这是可能的，至少在 API（cli）层面。
虽然 git 在引擎盖下运行良好，但它的用户界面并不友好。
此外，GitHub 的成功也让 Git 受益匪浅，这让我们与 Git 结下了不解之缘：(
我在这里写过 https://trolololo.xyz/github – GitHub确实不错，但有个小问题
是的，你或许可以做得更好。但如果要做得更好，我希望他们能先真正学会 git。
很多替代工具的出现都是因为编写者不愿意学习 git。只有几个概念和几条命令，仅此而已。
而一旦有人彻底学会了 git，他们通常就会发现它其实已经足够好了，也就不会再费心去做新东西了。
> 也就懒得再做新东西了。
他们甚至懒得添加目录跟踪功能；)
我的经验是，任何技术的威力都是循序渐进的–对于 git 来说，好吧，让我们掌握单个用户在单个服务器上使用单个仓库的命令，直到达到一定的充分程度。然后（根据需要），在同一台服务器上为同一个用户添加多个仓库。然后添加多个服务器（包括 git 远程服务器）。然后添加多个用户……等等……当然，git 的神奇之处在于，你可以按照任意顺序展开这些需求。通常，当我发现自己不理解某些事情（我以为我理解了）时，我会回到之前的展开范围，排除其他因素。
我相信 git 可以改进，但我认为最大的改进来自于用户对功能范围理解的提高。在众多的 git 教程中，我还没有看到过这方面的好教程。这让我想起了 “哈佛大学教授分 5 级难度讲解算法 “的视频（非常精彩）[1]。
[1] https://www.youtube.com/watch?v=fkIvmfqX-t0
我真希望能有一个以这个为主题的频道–分五个难度讲解所有内容。
既然如此，在 git 的 “5 个难度级别 “中，是否都有需要改进的地方呢？我相信肯定有。把答案集中在每一个级别上会更好。
Git 是工程师而非设计师的产物。工程师会把各个部分粘合在一起，使其发挥作用，而设计师则会审视各个部分，质疑它们是否符合设计意图和逻辑。
我认为，在经过设计师的完善之前，Git 就已经走向了大众。用户需要了解粘合剂，并用粘合剂语言与 git 交流，使其发挥作用。
但我最近接触到了 Graphite (https://graphite.dev/)，虽然它在引擎盖下仍然是 Git，但它抽象掉了许多常见的痛点（堆叠 PR、重新排序），并与 GitHub 和 VS Code 进行了很好的集成。
这真的很有趣。你以前试过吗？喜欢吗？
嘿，我才刚刚开始使用它。我的同事对它赞不绝口，所以我才知道了它。
我认为它并不神奇，我们仍然需要自己解决合并冲突，但我感觉它确实简化了重复操作。
希望对你有所帮助！
也许在某些领域，你显然可以做得更好。就拿艺术家想要对图片进行版本控制来说，我可以想象专门的工具可以做得更好。在编程方面，也许可以改进协同工作的软件源组的版本控制。
至于标准需求，可能会比较困难。
我或多或少认为这个问题已经解决了。
你在这里听到的大多是对 Git 感到厌烦的人，或者是对版本控制这个话题比一般开发者更感兴趣的人。对我来说，我认为 Git 提供了一套相当强大且经过深思熟虑的基元，然后再将它们向上组合，就像我们所期望的那样好。
有些东西显然没有得到很好的支持。使用同一个 Git 仓库来保存大型二进制文件和源代码就得不到很好的支持，除非你使用 LFS，这是我认为最大的缺点。
我的下一个选择是 Fossil。我正等着有人创建一个 archaeology.co 来与 GitHub.com 竞争。
>我认为它提供了一套相当强大且经过深思熟虑的基元
中转区的存在是设计中考虑不周的部分。其他 VCS 都没有使用它，因为它是个馊主意，让简单的换向变化变得更加复杂。
>化石是我的下一个选择。我正等着有人创建一个考古学网站（archaeology.co），与 GitHub.com 相媲美。
这正是化石不会成为下一个大 VCS 的原因。无视 Github 上的所有项目，强迫人们为了使用一个新的源码控制系统而迁移到一个功能较少、集成度较低、家族化程度较低的 forge，这种做法很难让人接受。Sapling 和 Jujutsu 支持 Git 协议，因此可以在 Github 上使用，这将使它们更容易被采用，因为它可以逐步取代 Git。
git 的用户界面可以友好千百倍，但它过于以命令行为中心，因此工作流程仅限于复杂的 “子工具调用”。git 的图形用户界面是存在的，但它们为简单的工作流程增加了极大的开销，也许应该优先考虑一些 “标准网络接口 “后端（Github 因其用户界面而广受欢迎）。另一个替代方案是简化繁琐的命令调用，我希望用 “git workflow_commandX file_target “来代替大量的开关和参数。这样的 “标准快捷命令 “应该有数百条，以减少错误。
是的，看看 Mercurial
是的。
在我看来，下一个 VCS 模式应该遵循集中优先、分散可选的模式。这是对 git 分散优先模式的翻转。
我还认为，GitHub 处于一个独特的位置，可以在 git 上进行真正的创新，可惜他们没有。
举个例子，我不应该为了提交 PR 而创建一个 fork。这太荒唐了，GitHub 服务器应该能根据推送身份应用 ACL。
我能想到的建议还有很多，但没错，GitHub 应该在这方面做得更多。
我认为目前实现的分叉存在一些严重的人体工程学问题。不过，我很好奇你的意图是什么：
> GitHub 服务器应能根据推送身份应用 ACL
这正是 GitHub fork _is_ 的本质–你可以控制的一组 ACL 的 refs，与上游的 refs 分开。我想，你有什么不同的建议？
透露一下，我在 GitHub 工作，是 Git 产品经理。
哦，太棒了，谢谢你的澄清！
当我克隆了某个上游版本库并在我的机器上做了错误修复后，为什么我还需要再叉一次该版本库并先将提交推送到我的叉库，然后再做 PR 呢？
例如，GitHub 服务器可以在源/上游上伪造我的分支。它不需要真正在上游创建分支，而可以聪明地创建一个不稳定的 fork，并准备将修改变成 PR。
基本上，既然服务器知道我的身份，也知道我能不能在上游版本库上创建分支，它就能为我处理创建分叉的模板。
我希望 GitHub 能在开发者和版本库之间建立一个权威的服务器。
如果是同一个底层仓库，那么就不需要两个 Git 远程登录（原始仓库 + fork）了。但如何做到这一点，我也不太清楚。
免责声明：我正在努力。
不过，是的，我想我们可以。
几乎所有事情都可以做得更好：
* 合并/基地/分支管理。
* 项目管理。
* 差分
* 大文件
* 用户管理
* 部分签出
* ACID 语义
* 二进制文件管理
* 用户体验，包括让非技术人员也能使用。
* 其他许多方面。
语义上的差异将是一个迟来的改变，也是一个非常受欢迎的改变。
我同意。
它的难点在于每种语言都不一样，所以要支持一种语言，就必须为该语言实现 diff。
我希望能从需要这些语言的公司身上赚钱。
从开发者的经验来看，Mercurial 和 Facebook 的小树苗比 Git 好得多。Git 在很多地方都有问题，但它之所以成为标准，只是因为 GitHub 的普及和开发社区的崛起，他们喜欢接受大公司给他们的任何东西。现在的普通开发者不喜欢花时间研究那些不容易赚快钱的东西。
Git 是记录逻辑历史的好工具，但我个人认为它缺少处理物理历史的工具。Reflog 是朝着正确方向迈出的一步，但它的容量有限，而且目前还无法在克隆之间共享 reflog。因此，”cp -r repo repo.backup “是最好的选择。
当然，只要你只通过提交/合并/还原进行添加性修改，逻辑历史记录就等同于物理历史记录，但 rebase 等命令打破了这种模式。尽管 rebase 工作流程有很多缺陷，但有时它却是最佳选择，比如在维护 fork 时。
出乎我意料的是，Vim 其实也有类似的功能–逻辑历史与撤消/重做，物理历史与 g+/g-/:earlier/:later
我还希望能有办法将多个小提交 “折叠 “成一个大提交（仅用于显示目的），这样我就能将大差异拆分成最小的、自成一体的提交，同时保持合理的 git 历史记录。
生理史和逻辑史有什么区别？
非常感谢
简单的解释：逻辑历史 – 当您执行 “git log –all “时看到的内容。物理历史–每次版本库更新时都执行 “git log–all”，然后将每次输出作为一个条目存储到另一个历史日志中。有点像 “历史的历史”。
复杂的解释是：一个特定时间的 git 仓库（主要）由一个提交图组成。该图代表了仓库中代码更改的逻辑历史。该图可以只以追加方式更新（使用提交/合并/还原），也可以像 rebase 和 reset 那样以破坏性方式更新。物理历史只是图形随时间变化的历史。
换句话说，图形的历史就是物理历史
而逻辑历史则是文件集，它们是图中的节点，是提交的分支序列
问题在于，”逻辑历史 “是 Git 被创建的原因
而在我看来，”物理历史 “之所以可行，是因为我们有正规的 git 提交序列
角度不同：我们绝对能比 git 做得更好……对于无法合并或存储为差异序列的非文本文件而言
我曾经（简短地）研究过用 git 代替 PDM 来处理 solidworks CAD 文件，结果发现 git 绝对不适合这种情况。这并不奇怪，因为它根本就不是为此而设计的。
不过我还是想说，世界需要一个更好的版本控制系统，类似于 git，但能处理非文本文件，因为我尝试过的实际解决方案都比 git 的体验差远了。
软件工程师真幸运，能免费获得如此强大的工具，而机械工程师或他们的公司却要花数万美元购买比这差得多的版本控制软件
PDM 不仅仅是版本控制，但版本控制才是我的公司想要的，但它太痛苦了
Git 是完美的，只是需要一个好的用户界面。
在我看来，最好的用户界面是 sourcetree，但 linux 上没有。
我多年前使用过 sourcetree（去年改用 Linux，并使用 smartgit 客户端），我不知道它的现状如何，但旧版本可以下载，而且不需要阿特拉斯账户。
我可以建议的改进包括修改非最后提交的提交（当然也不能推送）。
目前，如果你想修改倒数第三个提交，你必须软重置最后一个提交，将其推送到收藏夹，再次重置新的最后一个提交并将其推送到收藏夹，修改更改，然后弹出前两个收藏夹并逐一提交。这很容易实现自动化。
我不确定我们是否能用其他东西取代 git。对于大多数开发者来说，git 已经无处不在，而且已经 “足够好 “了。因此，我认为唯一的解决方案就是建立一个完全向后兼容 git 的版本控制系统，或许只是在 git 的基础上建立一个更好的 API 层。Facebook 在 Sapling 上也做过类似的尝试。
对于新的版本系统，我们不需要二十种不同的选择。我们需要一个免费、开放、可靠且人人都能使用的解决方案。
业界的主要领导者应该成立一个小组来定义这一标准。这将是他们真正让世界（稍微）变得更好的机会。
> 它无处不在
直到 2011 年，Subversion 在 Eclipse 社区调查中的市场份额才跌破 50%。新的闪亮的东西会出现并取代 git。
我记得 HN 上有篇文章说 YAML 是一种糟糕的序列化格式。如果有一个更严格的 YAML 子集（如 StrictYaml），就能解决其中提到的所有问题。
同样，git 的解决方案也是 git 的子集（严格 git）。
Git 的问题在于它过于强大，并假定用户都是 Git 专家。你应该能以 “简单模式 “运行 git。添加、提交、签出新分支、还原、粉碎合并。这就是 90% 的人所需要的。
然后，中级用户可以用模式 2 运行它，增加重置、重置头、cherry pick、还原、隐藏等功能。这涵盖了接下来的 9%。
最后 1%的人可以用模式 3 来满足其余需求。
一旦消除了对自己可能造成的破坏的恐惧，Git 就不再那么可怕了。
我用过 CVS、SVN、Arch 和 Git。Git 的主要优势似乎是性能和原子性。Arch 是个垃圾。CVS 的工作对象是文件而不是目录。Git 比 SVN 快一些或快很多。尽管如此，当版本库中有大文件时，Git 的速度会慢很多。
Git 比 SVN 难用得多。尤其是在解决冲突方面，工程师们会很费劲。
Git 的一个好处是去中心化，但现在 Git 变成了 Github，又变成了中心化。
构建、集成开发环境、编程语言都应该是一等公民。我可不想和 .gitattributes 或 .gitignore 计较什么。
有什么更好的办法？
– 处理大文件更快。- 更简单。- 改进提交元数据。
更好的东西应能跟踪移动，而不仅仅是存储状态。文件的移动，甚至是（文本）文件中部分内容的移动。不幸的是，这需要与编辑器紧密结合，所以我怀疑这是否会实现。
我们一直在开发一个名为 “oxen “的数据版本控制系统，该系统针对大型非结构化数据集进行了优化。
这些数据集中有很多图片、视频、音频文件、文本以及结构化的表格数据集，而 git 或 git-lfs 在这些数据集上的表现平平。
我希望大家都来试试，并告诉我们你们的想法：
https://github.com/Oxen-AI/oxen-release
这些命令是 git 的镜像，因此很容易上手，但针对较大的数据集进行了引擎盖优化。
大约十年前，我从 Accurev 和 Perforce 开始使用 Git。这些 VCS 的配置工作有点繁重，但它们的用户界面允许同时进行大量复杂而简单的工作流。
Git 因免费而胜出，因为很多人认为使用终端会更好，但在用户体验和功能方面，我们本可以做得更好。命令行程序让你不得不在脑海中构思大量的上下文，如果 Git 能设计出用户界面，可能对每个人都会更好。
我仍然希望能有更好的工具，但它们很可能是基于 Git 的，只是有更好的默认流程。
我不认为 Git 有那么糟糕，以至于我们需要不同的东西。它有时确实很笨拙，但它主要是个辅助工具：当你想到自己是个开发者时，你不会想到它，但每个开发者都在使用它。
我猜大多数人日常使用的只是 git 的一小部分，其他的都是在谷歌上搜索到的。
正因如此，我认为如果 git 被取代，并不是因为新出现的东西客观上会更好，而是因为一些大多数人并不理解但却愿意重复的理由被鼓吹出来，并在替代品背后形成了一些势头。
Theo 描述了如何在 git（和 Github）之上构建石墨以改进 DX：https://youtu.be/I88z3zX3lMY
主要的创新似乎是
– 堆栈 “的概念介于提交和分支之间，是一组提交。
– 更好的用户界面，尤其是 Github 通知。
最终的结果是，他在使用先进的 Git 功能时感觉更安全，工作进度也更快，尤其是在多个开发人员组成的团队中工作时。
> 堆栈 “的概念介于提交和分支之间，是一组提交。
这似乎只是分支命名和重排序的一些约定。最有价值的似乎是 Graphite 将该状态同步到 Github PR 中。
这些人（如本视频的旁白）认为这很新奇，这说明了很多问题。甚至在 Git 出现之前，Linux 内核社区就已经有了 “堆叠提交”。
除非是关于网络开发的视频，否则就不存在 “堆叠提交”？
这取决于 “什么”。
我使用的维基内部使用 RCS，但你从未见过它。我知道它的唯一原因是，我需要扫描一些资产的旧版本，这比使用 Git 要简单得多。(其他奖励、附件和元页面都存储为实际文件）。只需一点点代码，你就能为实物资产等拼凑出一个自动页面生成器）。
我认为 rsync –link-dest 就是一个版本控制系统。
“解决 “这个词用得太重了。对大多数人来说，尤其是在 git-forges 如此流行的今天，是的。
但如果你在做二进制文件，因为你是艺术家/做 3D 建模，你可能还是会使用 svn。
我仍然时不时地登录 https://pijul.org/。
是的，我认为我们可以做得更好，而不是把纯文本作为真相的来源，因此 git 可能需要改变。
有很多语言都不是基于文本的，有些语言有自己的编辑器或工具来管理文本的规范表示，这将使它们对 Git 更友好。
– https://github.com/yairchu/awesome-structure-editors/blob/main/README.md
在我看来，Git 的核心技术在于磁盘空间越来越便宜，你可以在本地拥有整个版本库的副本和所有历史记录。我不知道下一个迭代会是什么……也许是永远在线的网络，这样你就可以不断从所有合作者那里获取修改，而无需手动拉取？我们能用这些信息做些什么？
我觉得 git 的设计很糟糕。如果有一群兢兢业业的聪明人着手建立一个版本控制系统，我怀疑他们最终会用 git。
是的，但由于它的简单性、可扩展性和广泛应用，如果 100 多年后我们还在使用 Git，我也不会感到惊讶。
目前的趋势（最流行也最有可能成功的趋势）是在 Git 的基础上开发工具（”层”），比如更直观的用户界面/模式（https://github.com/jesseduffield/lazygit, https://github.com/arxanas/git-branchless）和智能合并解析器（https://github.com/Symbolk/IntelliMerge, https://docs.plasticscm.com/semanticmerge/how-to-configure/s……）。Git 非常灵活，即使是默认情况下处理得非常糟糕的事情，它也能通过 “层 “很好地处理：例如，通过 git-lfs (https://git-lfs.com) 处理大型二进制文件，通过定制的合并解析器（如 Unity 的合并解析器）处理非文本文件中的合并冲突 (https://flashg.github.io/GitMerge-for-Unity/)。
也许在未来，几乎每个人都会继续使用 Git 的核心，但为了让它更直观、提供更好的合并效果，会有如此多的层级，以至于他们所使用的几乎与 Git 毫无二致。这种灵活性，以及几乎所有东西都是为 Git 设计并与 Git 集成的事实，是我怀疑 Git 是否会消失的原因。
一些供思考的替代方案
– pijul (https://pijul.org)，一个完全不同的 VCS，据说有更好的合并/基础。目前还在测试阶段，但我现在很少听到关于它的消息，而且听到的坏消息多于好消息。我不认为我们能在 Git 中实现这种交替重用，但也许我们不需要；即使读了网站，我也不明白为什么 pijul 的合并更好，尤其是我想不出具体的例子，pijul 也没有提供。
– Unison (https://www.unison-lang.org)。这不是一种 VCS，而是一种采用激进方法来表示代码的语言：代码不是存储在文件中的文本，而是通过哈希值引用的 AST，并且基本上存储在数据库中。除其他优点外，最主要的一点是您可以重命名符号，而且重命名会自动传播到依赖关系中，因为符号是通过哈希值而不是名称来引用的。我相信这种自动重命名在未来会很常见，不管是通过 Git 上的一个层实现，还是通过 Unison 这样的替代代码表示法实现（需要说明的是，Unison 的代码库是为与 Git 协同工作而设计的，Unison 项目本身也存储在 Git repos 中）。
– SVN 是另一种广泛使用的 VCS。谷歌或在 ChatGPT 上询问 “Git vs SVN”，你会得到这样的答案（https://www.linode.com/docs/guides/svn-vs-git/, https://stackoverflow.com/a/875）。基本上，SVN 更容易理解，处理大文件的能力更强，而 Git 则是去中心化的，更受欢迎。但那些无法通过层级来解决的差异呢，比如直觉上的 lazygit 和大文件上的 git-lfs？在我看来，即使是拥有集中式私有仓库的公司也会使用 Git，这意味着 Git 可能会长期胜出，但我并不在这些公司工作，所以我也不太清楚。
– Mercurial和Fossil是其他广泛使用的VCS。它们似乎与 Git 更为相似，主要区别在于底层实现（https://stackoverflow.com/a/892688,https://fossil-scm.org/home/doc/trunk/www/fossil-v-git.wiki#….）。实际上，与Git相比，大多数人似乎更喜欢Mercurial和Fossil，如果它们的受欢迎程度相同，或者至少它们有Git的受欢迎程度，而Git有Mercury或Fossil的受欢迎程度，那么大多数人都会使用它们。不过，这些 VCS 又是如此相似，只要多加几层，你或许就能创造出一种既有它们的优点，又几乎复制了它们的用户界面的 Git 体验。
Git 的 “递归 “功能不可能实现的典型合并示例是：以 “AB “为基数（每个字符都在一行中，但为简洁起见我省略了换行符），分支 1 是包含 “AXB “的提交，分支 2 是提交 “GAB “后的另一个提交 “ABGAB”。递归合并这两个分支时，无法判断分支 1 中的 X 应该插入到分支 2 中的哪个 AB 对中，因为它永远看不到分支 2 的第一个提交，而该提交告诉你 “原始 “AB 是 G 后面的那个。查看每次提交的合并算法可以知道 “ABGAXB “更忠实于事件的实际顺序，因为它知道 X 被插入到分支 1 的哪个 AB 对中。
(当然，另一个看似正确的答案是 “AXBGAXB”，但`递归`同样不知道足够的信息来猜测这个答案）。
很多人尝试过，但成功者寥寥无几。SVN – 客户端-服务器原理，但不擅长合并分支 mercurial – linix 内核开发者寻找新版本控制系统后的竞争者之一，由于 git 更受欢迎，其用户逐渐减少，与 git 非常相似 bazaar – 主要用于 ubuntu，因为 launchpad 只提供 bazaar 作为 vcs
多年前，Launchpad 就加入了对 Git 的支持。另外，bzr 也比 Git 早了一点点。但很遗憾，Git 赢了。
我从 2016 年开始使用 git。我想我一定不是一个强大的用户，因为除了使用六条命令之外，我从未遇到过任何问题，也从未觉得我的工作流程被打断了。
您认为有哪些功能需要改进？从纯粹的用户体验角度来说，我认为 git 可能是我用过的最好的软件。它就是好用。
Git 虽然也有问题，但大部分时候还是不错的。
GitHub 和 gitlab 所使用的 Git 在很多时候都很糟糕。
我相信我们能做到，问题是，我们能做一个 GitHub 的替代品吗？如果已经有几个更好的替代方案，我也不会感到惊讶，但我从来没找过，因为我已经了解 Git，说服别人使用更好的替代方案的几率似乎很低，而且它们似乎很少有那么大的生态系统。
如果它没有多个云提供商提供拉取请求，而且其中至少有一个云提供商不是巨型企业，那么它可能不会是安全的无聊选择，除非它是完全的 P2P。
它需要被打包到发行版中，拥有图形用户界面集成等。
Fossil 看起来很酷，我很喜欢他们整合维基和问题的方式。但我不认识使用它的人，而且云提供商似乎都是 “随时可能消失 “的小公司。
我从来没有真正研究过其他 VCS，因为它们似乎都不会成为真正的竞争对手。
我对增强 Git 更感兴趣，但似乎很多最有趣的 Git 插件和扩展都没有更新，比如 GitTorrent。
关于GitHub 的替代方案，我已经考虑了一段时间，因为我不想把所有东西都集中在一起，而微软又很难成为最值得信赖的公司…
有一些类似 GithHub 的东西，最明显的是 GitLab，你也可以自己托管，但 GitHub 免费提供的所有（或至少部分）额外功能都在付费墙后面。
我目前最喜欢的是 Codeberg，它使用 Forgejo 作为底层（Forgejo 是 Gitea 的分叉，Gitea 本身也是 Gogs 的分叉，所有这些都可以自行托管）。Codeberg 由非营利组织运营，与我的理想非常一致。他们还在慢慢添加一些不错的功能，比如啄木鸟 CI。
SourceHut（也支持 Mercurial）是一个越来越受欢迎的平台，它不那么 “GitHub-y”。
主要问题在于，GitHub 已经真正占领了市场。他们提供的免费服务之多，其他公司难以望其项背，而且 GitHub 已经成为事实上的项目托管地。这就意味着，如果人们不想注册账户，也不知道如何处理你正在使用的锻造工具，那么托管在 GitHub 以外的其他地方就会限制人们的发现和贡献。
不过，即将推出的锻造联盟或许能缓解这种情况，它将允许你从 “主 “锻造与不同的锻造进行交互–希望这能避免你需要注册账户才能发布公关或提出问题。
编辑：我现在看到了你的另一条评论，有什么更好的 GitHub 可以支持比 Git 更好的 VCS 呢？以前确实有一些地方可以托管 Darcs 项目，比如 Darcs Hub，但我不知道像 Pijul 或 Jujutsu 这样的新项目是否有任何 forge 支持。
编辑2：哦，Pijul似乎有 “The Nest “托管。
因为 Jujutsu 与 Git 兼容，所以有很多支持的锻造器（GitHub、GitLab 等）。
目前还没有原生的锻造器。
是的，我知道它能与 git 后台一起工作，但还是不确定原生后台能带来什么，相关文档似乎非常少。
说得好，我们也许应该记录一下。顺便说一下，我自己曾称之为 “原生后端 “和 “原生锻造”，但也许这两个词并不合适，因为有很多可能的原生后端/锻造。
例如，我们在谷歌的 “Piper “后端就是一个原生后端，因为它将所有数据都存储在自己的数据库中。我认为该后端最令人兴奋的地方在于它是基于云的，因此用户无需推送就能访问彼此的提交（例如，`jj show <commit id from chat>`）。
> 问题是，我们能做一个 GitHub 的替代品吗？如果已经有几个更好的，我也不会感到惊讶，但我从来没找过，因为我已经知道 Git了
什么？
如果你想知道我们能不能做出比 GitHub 更好的东西，那么你可能会更喜欢 Forgejo 和 GitLab 等几十个 git 托管替代品。
如果你说：”但我已经知道 Git 了”，那么还有几十个替代托管网站或方法！
GitHub 是大家都在用的网站，这意味着你可以在一个地方拥有所有东西，所以他们有优势。
我想我应该说的是 “我们能不能为假想的更好的非 Git VCS 做一些比 GitHub 更好的东西”，因为如果不能做到这一点，就很难想象除了 Git 还能用什么。
可以肯定的是，替代 Git 的服务仍然比替代源码控制系统要大，但 OP 询问的是替代 Git 的服务，而替代 Git 的服务会更小。问题的关键在于，这个人想用别的东西。如果你的论点是微软 GitHub 是最大的，因此也是最好的，那这就是循环论证，而且永远不会改变。
如果 Facebook 是最好的，我们也应该继续使用它，因为每个人都在使用 Facebook，网络效应会带来好处；但不知何故，人们似乎比这更理智，我们其实可以转而使用更符合我们需求的小型服务。
我认识的人几乎都还在用 Facebook，而且我感觉他们都没兴趣换，所以……我也在用它，尽管算法策划的东西真的很糟糕。
我可以想象，如果有人制作了另一个具有杀手级应用的网站，并用一百万美元的广告来推广它，人们就会转用它，但是……目前，替代品唯一关注的功能通常是隐私，这显然不足以让普通人更换。
网络效应并不是唯一重要的因素，只是对大多数人来说是一个非常重要的因素。
但愿如此！在使用 git 多年之后，我认为它远不是一个好的解决方案。可以说，它还不如被它取代的某些 vcs。希望未来会有更好的解决方案出现。
在简单性、功能性和可用性之间有一个甜蜜点。我认为 git 正好处于中间位置，只是需要一点学习曲线。
本主题中的很多建议都会改善其中一个，但却会对其他方面造成巨大损害。
很难摆脱网络效应。就像我们只能使用 SMTP、JavaScript、PDF、HTML 等一样。
我认为唯一能改变它的方法就是我们的模式发生彻底转变。这就是从 SVN 到 Git（集中式到分布式）的转变。
SVN 只比 Git 早了 5 年，虽然 Git 是分布式的，但现在人们基本上把它当成集中式 VCS 来使用。
是的！在我的泡沫中，我们只需要 “代码快照 “或版本控制，但不是针对整个版本库，而是针对每个函数或文件。要让后辈们融入 git 真是出乎意料的难，因为总是会出现很多令人抓狂的情况。
事实上，git 提交就是代码快照……
git 根本就不存储差异。它存储的只是所有目录内容的快照。git 给你看的差异其实是即时生成的。如果你在做 ci，不需要完整的历史记录，你甚至可以只克隆一个提交，然后从中获取内容。
我认为现在 git 已成为标准。当我需要为一个产品实施自定义版本控制系统时，我使用了 git 作为参考点。此外，很多东西都可以建立在 git 的基础上，比如 GitHub
我打赌我们也许可以
但作为一个操作系统，你也可以做得比 Linux 或 OSX 更好，但那里的思想份额和行业投资是如此之大，转向一个新事物是一项艰巨的任务
我觉得这个术语应该更好一些，这样技术人员就不会用得太多。在本质上是保存的情况下称之为 “提交 “是个好的开始。是的，我知道它与保存并不完全相同，但谁会在乎呢。
我想要一个比 git 更简单的东西，功能更少，命令更少，但使用更方便，能覆盖 99% 的使用场景，最好是图形用户界面。(不，简单的 Git Guis 是不存在的）。
很好用。我的主要痛点是二进制文件。虽然有 git LFS，但它不是默认的，需要一些配置。
相关 https://news.ycombinator.com/item?id=15206339
压扁的盛行是某种问题的症状，我们需要一种破坏性较小的解决方案。
我听说一些FAANG（Meta、Google……）在向Mercurial迁移。这有什么好处吗？
是的，Mercurial 和 GitHub 都进行了扩展，并拥有可与 GitHub/git 服务器兼容的版本。
来自 meta 的小树苗 scm 有我认为最好的客户端和 VS 代码用户体验 https://sapling-scm.com/
谷歌的 jj 也是 mercurial 衍生版本，具有与 histedit 非常相似的 cli 功能，并支持延迟冲突解决 https://github.com/martinvonz/jj
要说明的是，jj 并非源自 Mercurial，而是深受其启发。不过，谷歌目前的 DVCS 解决方案（名为 Fig）是基于 Mercurial 的。但我们希望用 jj 取代它。
git : 版本控制 :: vim : 编辑器
初学者友好的用户界面/用户体验绝对是大有可为的。朱莉娅-埃文斯（Julia Evans）最近发表了一篇关于 git 容易混淆的文章。版本控制大文件的功能（如 git-lfs）将是一个很好的补充。
> 还是说问题已经解决，Git 就是 VCS 的终结者？
我读过很多大意为 “X 是一个已解决的问题 “的评论，但它显然不是，以至于我得出结论，这句话的意思与其表面价值恰恰相反…
我很确定 Git 并不是 VCS 的终结者。至于我会不会再换VCS，这完全是另外一个问题。我用过很多 VCS（RCS；用过一点 CVS；用过一点 Subversion，它承诺自己是没有缺点的 CVS，但其实不是；Mercurial，因为它是用 Python 写的，所以一定很好，对吧？最后是 Git；当然还有常见的 “report-v4-revision-good-one.doc “重命名游戏；再加上大量的备份解决方案，其中不乏非常糟糕的解决方案）–这么多解决方案中，我最不愿意换的就是 Fossil，我差点就换了。
是的，我已经完全忘记 https://fossil-scm.org 了；它之所以没有成为我的首选解决方案，可能主要是 github.com 的错，我觉得它好得不能再好了，我不想在我的系统和他们的系统之间出现 “阻抗失配”。但也许这是可行的，也许 Fossil 足够好，值得一试；无论如何，去读读他们的文档吧，尤其是他们直接将自己与 Git 进行比较，并为自己的做事方式给出了很多很好的理由。他们也是做 SQLite 的人，所以我认为这是一个值得信赖的高质量软件来源。
除此之外，我个人处理 Git 复杂性的方法是避免使用我不需要或不太了解的部分（即几乎全部）。我用它来签入改动，给出一行注释，然后上传到 github.com；当然，克隆和更新现有版本库以及建立新版本库也在我的技能范围之内。分支和合并就没那么简单了。因此，它就像 “git “加上 “克隆”、”添加”、”提交”、”推送”，仅此而已；此外，我还使用 Sublime Merge 来完成其中的一部分（审查更改、添加相关的更改块、提交），我必须向大家推荐这款优秀的软件。
我也曾尝试过 gitless（我想它的名字应该是 gitless），它承诺是 Git，但对于简单的东西来说更简单，而且在需要的地方可以随时返回到 Git 本身；我发现这是个我喜欢的好提议（Markdown：返回到 HTML；CoffeeScript：返回到 JavaScript），但不知为什么，我对 gitless 没有什么兴趣；我猜这是因为我已经把 Git 的使用率降到了近乎绝对零度，剩下的就靠命令行历史记录和 Sublime Merge 了。
> github.com…..我不希望我的系统和他们的系统之间出现 “阻抗失配
所以，在你的 Fossil 实例上为你的贡献者提供开发者账户吧。Fossil 实例的设置成本超低，它是一个二进制文件，外部依赖性几乎为零。(我的容器化构建是一个单一的静态二进制文件，压缩后总大小约为 3.5 MB。
如果你担心互联网上的无名小卒会轻易发布 PR，那我就要质疑你的前提了。我的经验是，在项目受欢迎程度低于某一水平时，即使算上所有可能的外部提交者，项目上的全职开发人员也不足一人。在这个阈值以下，为什么要优化外部贡献者呢？如果有人有足够有价值的补丁，他们可以通过获取 Fossil repo 登录或发送补丁来解决。
我维护一个软件已经快二十年了，这个软件在所有流行的软件包仓库中都有，但我从未通过 GitHub 收到过任何有价值的 PR。我花了更多时间使用他们的代码注释功能，解释为什么这样、这样、这样的改动是不可接受的，然后 PR 提交者就会离开，而不是修复他们的补丁。这完全是浪费时间。
我曾经也得到过高质量的外部贡献，但那是在项目由 Subversion 托管的时候，发布补丁比发布 GH PR 更费事也无所谓。对项目有足够价值的人都会忍受一定程度的仪式，以便把他们的代码放到上游项目中。
(平心而论，我认为外部贡献质量不高的原因在于该项目在某种意义上已经 “大功告成”，只需偶尔修正一下就能跟踪平台变化）。
如果你足够幸运，拥有一批愿意提供高质量贡献的外部用户，那么 Fossil 确实有一个比统一差异更好的补丁选项。请参阅 “patch “和 “bundle “命令。这可以让外部人员发送包含注释、文件重命名/删除等内容的完整提交分支。
……有点像 PR。）
如果你绝对需要与基于 Git 的工具集成，Fossil 可以轻松地将你的 repo 镜像到 GitHub，你可以将其视为只读。
>Mercurial，因为它是用 Python 写的，所以肯定不错，对吧？
我不能说这就是原因，不过是的。Mercurial 非常棒。
也许是现在的原因，但我在以前（相当长的时间，>>10年前）遇到过一些障碍/错误
对我来说，”有没有比 git 更好的东西 “并不是最重要的问题。
重要的是 git 是否足够好。
或者更具体地说，当 X 是实际正在做的事情时，git 对 X 是否足够好。
我的意思是，对于我和比我有更复杂需求的人（比如 Linux 团队）来说，git 已经足够好了。而且我对 git 的了解比其他任何 VCS 都多（部分原因是学习 git 的资源比其他任何 VCS 都多），为了学习其他 VCS 而学习其他 VCS 对我完成任何工作都没有帮助。
这并不意味着 git 就能满足你的需求，但从统计学角度来看，它很可能能满足你的需求，因为从统计学角度来看，使用 git 遇到的大多数困难都与培训和知识有关，因为 git 的数学基础（据我所知）都很完善。
这也意味着（并非偶然），要想比 git 做得更好，就需要有比 git 更好的资源来学习新的 VCS，而这是一个非常高的要求。
祝你好运
Git 的最大特点是它几乎无处不在。我并不关心别的，我只知道如果一个软件仓库没有使用 Git，我就不会为它做贡献。
是的，它叫 mercurial
不，git 完全没问题。就像我们在工作中使用的其他工具一样，你需要学习才能掌握它。
好 “不是 “最佳”。仅凭某样东西能完成工作这一事实，并不能说明它就是完成工作的最佳选择。
Git 出问题的最微不足道的例子就是 “一旦产生冲突，在修复冲突或还原之前，不能执行任何其他版本控制操作”。尤其是，比如说，你不能提交冲突的部分解决方案：你只能放弃，并尝试把你的历史记录放到合并算法更容易接受的状态，然后再试一次。
也许你想要更多的本地克隆（git clone -l -s），或者使用工作树，这样你就可以在其中一个工作树中保留待处理的合并冲突？
Git 并没有 “存储部分已解决冲突 “的方式来记住尚未解决的冲突。如果你真的想这样做，也许你只想提交冲突标记，然后稍后再回来，等全部完成后再一起重新提交。
> Git 没有办法 “存储部分解决的冲突”，无法记住冲突尚未解决。
这正是我要说的：这是 Git 的一个基本限制，没有很好的解决方法。这不是领域固有的问题，而是 Git 的限制。例如 Pijul 就认为冲突状态是正常的。
这与其说是基本限制，不如说是尚未编程的东西。请随意。
我愿意，谢谢！(但冲突永远不会用 Git 来建模，除非在 Git 的基础上用注释或其他方式建立一个更有表现力的数据库，否则我认为称由此产生的系统为 “Git “并不合理）。
Git 对象系统的基础是拥有类型的对象。曾几何时，”tag”对象类型还不存在。那时和现在的唯一区别就是安装的基数不同。