Git 分支：直觉与现实
Git 的分支模型常常与开发者的直觉相冲突，因为很多人想象中的树状“历史线”，实际上只是一个 DAG 快照图中的可移动提交指针。评论者争论 Git 的强大与内部一致性是否足以证明其臭名昭著、繁复的界面是合理的，并就问题究竟更多来自错误的心智模型、糟糕的教程，还是 Git 本身的设计展开讨论。许多人主张从“底层”学习 Git（提交、引用、快照），并使用 reflog、rebase 和可视化 UI 之类的工具；也有人希望有更高层的工作流，或者替代性的 VCS，更贴近人们对版本控制的自然理解。
分支语义与心智模型
- 强调在 Git 中，分支只是指向某个提交的一个可移动指针（“标签”或“游走的标记”），而不是提交的容器，也不是字面意义上的树枝结构。
- HEAD 是另一个指针，表示“你现在在哪里”；它可以指向任意提交，不一定是某个分支的顶端，这使得“detached HEAD”这个名字显得有些令人困惑。
- 几位评论者指出，日常使用中的“树”隐喻（树干/分支）会误导人们对分支“从哪里开始”以及合并应该如何表现产生错误期待。
- 还有人强调，每个分支的历史最终都会回到仓库根部；“main”只是在约定上特殊，并不是 Git 模型本身赋予它特殊性。
可用性、直觉与设计
- 对 Git 是否直观存在分歧：有人说一旦把分支看成指针后就“顺理成章”；也有人认为，大量糟糕的博客文章和普遍的困惑证明这种模型和 UI 并不直观。
- 争论工具应当迎合朴素直觉，还是应当教用户使用更强大但不那么显而易见的模型。
- 批评指出，Git 的 UI 繁复、命令负担过重（尤其是
checkout），而且 Git 解决了许多用户并不需要的问题，提高了认知负担。 - 反方观点认为，Git 的强大和一致性足以证明其复杂性是合理的；更简单的 UI 或集中式 VCS 会牺牲灵活性和工作流。
工作流与命令使用
- 许多人表示，只靠很小一部分命令（
pull、checkout/switch、merge、commit、push、add、status）也能应付。 - 也有人认为专业人士必须了解更多：
rebase（通常是交互式）、reset、stash、reflog、log、diff、blame、cherry-pick、tag。 - 很多人强烈支持 rebase 和 squash，以保持线性、易读的 main 历史；另一些人则警告重写历史的风险，并更偏好 merge commit。
reset --hard和 stash 被一些人高频使用，因其强大而受赞赏，但也承认在存在未提交改动时很危险。
历史、重命名与内部机制
- 有几种解释指出，Git 在 DAG/Merkle 树中存储不可变的快照提交；diff 和重命名是之后再计算出来的。
- 文件移动/重命名不是一等历史信息；它是通过内容相似度启发式推断出来的，有人认为这很优雅，也有人觉得与显式记录重命名的 VCS 相比，这是一种实际上的弱点。
- 讨论还提到合并提交拥有多个父提交、快进合并、彼此断开的提交图，以及没有存储“父分支”或分支谱系这一点。
学习与教授 Git
- 多次建议从底层学起 Git（对象、引用、DAG），然后再去记忆 porcelain 命令。
- 许多链接和参考资料（交互式分支可视化工具、“commits are snapshots”的解释、Git book/用户手册）被认为特别有帮助。
- 持续存在的张力在于：很多人觉得反复的“RTFM”建议忽视了一个事实，即即使是聪明的用户也会遇到困难，这说明问题可能是实际的 UX/设计问题，而不只是文档缺失。