Visual Studio 2022中Git Changes、Git Repo为何位于View而非Git下拉菜单

这个菜单排布是Visual Studio团队沿用了二十多年的交互分类规则下的结果，并非随意设置，核心设计逻辑有三点：

• 首先两个顶层菜单的定位边界从VS初代产品开始就非常清晰：Git菜单从2019版本替换原Team Explorer菜单起，定位就固定为Git操作命令集合，里面收纳的全是点击后直接执行具体动作的功能：比如提交、拉取、推送、分支新建/切换、远程仓库配置、冲突解决这类主动操作命令，本身不承担工具窗口显隐控制的职能。而View菜单从产品诞生之初，就是所有可停靠工具面板的统一显隐入口——不管是解决方案资源管理器、输出窗口、错误列表、属性窗口这类通用面板，还是和特定功能绑定的测试资源管理器、云资源面板、Git Changes、Git Repo面板，本质都是可自由停靠、隐藏、拖动位置的工具窗口，统一归到View菜单是为了保持交互逻辑的一致性，老用户遇到某个面板找不到的情况，第一反应去View菜单翻就不会出错。
• 其次VS从来没有“一个功能入口只能放在一个菜单”的设计：Git相关面板并不是只能从View菜单打开，Git菜单的顶部默认选项点击后就会直接唤起Git Changes面板，Git菜单下也提供了Git Repository（即你说的Git Repo）面板的直接入口，日常做Git操作的时候根本不需要绕到View菜单里找入口。View菜单里保留这两个入口，只是遵循“所有工具窗口都能在View菜单找到”的通用规则，照顾不同操作习惯的用户。
• 最后这个设计是为了避免菜单分类混乱：如果打破规则把Git相关的工具窗口放到Git菜单，按照同样的逻辑，解决方案资源管理器就该放到Project菜单、测试资源管理器就该放到Test菜单、NuGet包管理器面板就该放到依赖项相关的功能菜单下，最后每个功能菜单都会堆满自己对应的面板入口，用户找丢失的面板时根本不知道该去哪个菜单翻，反而会大幅提升查找成本。

不少刚从其他IDE转用VS的用户一开始都会觉得这个排布不符合功能关联的直觉，但用久了熟悉了VS这套“所有窗口显隐找View、所有操作找对应功能菜单”的固定逻辑，反而会觉得比把入口散在各个菜单里找起来省事。

内容的提问来源于stack exchange，提问作者Michael