历史与动机

Zephyr 项目引入 west，是为了满足两个基本需求：

在 west 开发过程中，确定了一组设计约束，以避免此类工具常见的问题。

要求

将 Zephyr 代码拆分到多个仓库的动机不在本页讨论范围内，但基本需求，以及不采用现有工具而选择开发新工具的明确理由，应在此说明。

基本需求如下：

West 的部分功能与 Git Submodules 和 Google 的 repo 类似。

在 west 最初设计和开发时，曾评估现有工具，但没有找到满足 Zephyr 需求的工具。具体而言，详细考察了以下工具：

Google repo
- 无法良好支持将 zephyr 用作清单仓库（R4）
- 仅支持 Python 2
- 与 Windows 配合不佳
- 假定使用 Gerrit 进行代码审查
Git 子模块
- 不能完全满足 R1，因为外部维护的仓库仍需位于主 zephyr Git 树中
- 不支持 R3，因为下游副本需要删除或替换子模块定义
- 不支持持续跟踪外部仓库最新的 HEAD （R4）
- 要求硬编码外部仓库的路径或位置

Zephyr 旨在提供部署复杂物联网应用所需的全部构建组件。因此，Zephyr 项目远不止一个 RTOS 内核，而是一组协同工作的组件。在此背景下，项目需要以标准化方式操作多个 Git 仓库，原因包括：

有关 west 工作区如何管理多个 Git 仓库，参见基础知识。

West 具有以下特性：

可选：始终可以退回使用“原生”命令行工具，也就是不使用 west 来使用 Zephyr（不过可能仍需安装 west，并让构建系统能够找到它）。但这样做未必总是方便。（如果 west 的全部功能都已有便捷的现成实现，就没有必要开发它。）
兼容 CMake：构建、烧录、调试和仿真器支持，始终保持与直接使用 CMake 的方式兼容。
跨平台：West 使用 Python 3 编写，可在 Zephyr 支持的所有平台上运行。
可作为库使用：只要可能，west 的功能就实现为可供其他程序独立使用的库，再提供包装这些库的独立命令行接口。West 本身是名为 west 的 Python 包，其库实现为子包。
审慎增加功能：没有充分且有说服力的动机，就不会接受新功能。
行为明确：West 包装其他命令时，其行为都有明确规定和文档。这既支持与第三方工具互操作，也意味着 Zephyr 开发者始终可以了解使用 west 时“底层”发生了什么。

更多详情和讨论见 Zephyr issue #6205。

更新流程中使用分离的 Git HEAD 修订版本的做法，让一些用户感到困惑，甚至不满。

具体来说，用户经常问：为什么 west update 默认不让已有本地分支保持检出状态？

本节解释 west update 默认行为的原因，并介绍如何用其他选项管理有本地修改的项目。

west update 有两个核心要求：

使用分离的 HEAD 有助于保证安全性。如更新流程所述，对已更新项目运行 git checkout --detach 以获得分离的 HEAD，通常是不会丢失用户工作的安全操作：

分离的 HEAD 也有助于保证确定性：

必须准确检出清单文件指定的项目修订版本，才能确保工作区文件符合主清单的规定。如果 west 默认不检出清单指定的修订版本，工作区就可能在不知不觉中偏离工作副本中清单文件所描述的预期状态。更糟的是，差异还会取决于运行 west update 之前分支中的具体内容。
这与清单导入之间存在微妙的相互影响。如果项目本身包含一个或多个由 west update 导入的清单文件，west 就需要将这些文件检出到工作树中，才能解析完整的导入清单。如果 west update 让项目中的分支保持检出状态，工作树中的清单文件可能已过时。若 west 再使用这些旧文件完成导入，过程可能意外失败，或产生其他不确定结果。

West 不会直接检出 manifest-rev 分支，原因已在该分支的文档中说明。

此默认行为很早就已确定，用户已经依赖它，因此现在无法再更改。但如果默认行为不适合你，仍可使用其他方式运行 west update。运行 west help update 并阅读 checked out branch behavior 选项组说明，即可了解详情。例如：

如果希望在工作区中为其中某个命令设置更简短的输入方式，可以使用 West 别名。也可以向以下地址提交拉取请求，为此选项组贡献新选项：