Git 设计问题
尽管 Git 被广大程序员所推崇，但它并非完美无缺，也不适用于所有场景。
命令繁多且易混淆
- Git 至少有 157 个命令，常用的可能仅有十个。
- 更麻烦的是，你可能会发现经常使用的命令与实际操作不完全对应，这会增加认知负担。通常，你需要组合多个命令来实现目标，说明 Git 的命令设计过于底层。
暂存区（staging area）
暂存区是 Git 仓库的关键部分，负责协调和管理文件变更。优点：
暂存变更：当你修改文件后，Git 会将变更暂存在暂存区，而非直接应用到仓库。这样，你可以在提交前查看和验证变更，确保符合预期。
控制提交：暂存区有助于有目的地进行提交。如果没有暂存区，每次修改文件，Git 都会自动提交变更，可能导致频繁提交，难以回滚。使用暂存区，你可以更有意识地管理提交，避免不必要的冲突和错误。
简化提交操作：暂存区使得提交过程更简单。只需将所需更改暂存，然后一次性提交到仓库。减少多次提交操作，提高工作效率。
便于回滚：暂存区让你在提交变更前查看和修复问题。若在暂存区发现问题，可直接回滚到之前版本，无需担心之前的修改。降低错误影响，加快修复速度。
版本控制：暂存区有助于更好地进行版本控制。开发过程中，可以将暂存区的变更与特定版本关联，便于需要时回滚到之前版本。对大型项目尤为重要，保持项目稳定性，同时允许团队成员进行实验性开发。
缺点：
复杂性增加：对于初学者，暂存区的概念可能较难理解。
全新工具助力 git
许多新工具致力于改进 git 的用户体验，根据我个人的观察，这些改进主要集中在简化命令、清除暂存区、推崇单一主干分支理念以及 stack 工作流。其中，stack 工作流尤为值得一提，下面将以 meta 的 sapling 为例进行讲解。
stack 工作流
使用过 git 的朋友们应该都能体会到 rebase 的优势，但在实际操作中，人们往往感到困惑。以下是一个典型场景：
首先，a 基于 AB 进行开发。
随后，需求 b 基于 AB 中的 B 部分展开。
原本计划发布的 a 推迟了，导致 b 希望尽早发布。
此时，人们希望将 AB 拆分为 A 和 B 的最小改动，让 b 从 B 进行 rebase。
最后，我们可以以最小影响发布 b + B。
图片
在这个过程中，git 的操作显得不那么友好，提交是线性维度的。要更好地控制 git，只能开启新分支，而若要从中间拆分分支，则需要手动处理大量后续节点。sapling 就在这方面提供了 stack 工作流的支持。
仅关注相关仓库和提交，无关提交不显示无关仓库甚至无需下载。
本地分支甚至无需命名，全自动化管理，自然也省去了暂存区。
无需使用 rebase，而是提供了 split fold 等操作，遵循一个命令只完成一个任务且能 undo 的思路，精心设计。
增加了 git 所不具备的变更记录，便于进行自动化操作，例如，在 A-B-C 提交中，将 A 合入 master。sapling 能根据新增的 A-master 记录，自动将 B-C rebase 到 master。
在多人合作开发中，很多团队可能无法直接进入主干开发模式，更多的情况是：
基建 AB 需要进一步拆分为更多层级，以合理维护依赖链。
由于一直未合入，新需求 c 加入，需要从 AB 再次拆分为依赖 AB-C 的复杂形式。
同样，由于无法合入，a、b、c 均需单独提测。此时，git 中很可能面临数百个提交、数千个变更的混乱局面，几乎失控。若要坚持多个分支 rebase，每次更新链路需执行数十甚至上百个命令。
sapling 针对这种情况进行了专门设计，实现单个链路自动化 rebase，code review、合并、测试等环节优雅无缝！
图片
最后，如果 sapling 对你来说改动过大（暂不兼容 gitlab），可以尝试另一个开源项目 git town，它也是 stack 工作流的一部分。
https://www.highflux.io/blog/highflux-method https://sapling-scm.com/docs/introduction/differences-git https://www.git-town.com/
