“旧版”团队资源管理器做了很多好事,但是对于其他工具供应商来说,它也非常难以集成。通过新的 Git 体验,Visual Studio 团队选择了更为不可知论的方法。
旧版 Team Explorer 是用 .NET 4 编写的,并且非常适合与 Azure DevOps 集成。它起源于 2005 年 Team Foundation Server 首次发布时。随着时间的推移,其他供应商通过未记录和不支持的方式潜入 Team Explorer,但这在过去引起了许多有趣的问题。Team Explorer 窗口的概念也不理想,无法托管 GitHub、Azure DevOps、BitBucket 和每个想要列出的其他工具供应商,用户几乎没有控制元素顺序或隐藏某些瓷砖的方式。因此,它是错误的温床,需要将其移植到 .NET Core 和 x64,并支持进程外可扩展性,以正确支持 Visual Studio 2022。
因此,Team Explorer 及其旧的未记录的可扩展性点被删除,新的 Git 窗口诞生了。该窗口是一个纯 git 客户端,它是供应商不可知的。供应商可以向顶级菜单添加菜单项,但目前无法扩展新的 git 窗口。
同时,Visual Studio 2022不再支持内置浏览器窗口,该窗口占用大量内存,加载IE11,并且需要完全重新调整以支持Visual Studio 2022现在要求的x64外部进程加载。
所有这些工作现在使Visual Studio可以使用更多的内存,它更快,并通过将扩展程序移出进程,极大地提高了Visual Studio平台的性能和稳定性。不幸的是,所有这些都是以某些功能为代价的。
新的Git体验不再受限于Team Explorer窗口,成为Visual Studio中的顶级工具,并且终于可以使用更容易记忆的键盘快捷键。它也更快了,新架构使团队能够构建交互式变基、多仓库支持、子模块支持等功能。但是他们长期以来的重点一直在高级Git场景中,而不是构建供应商特定问题集成的支持。不过看起来这种情况可能正在改变。在Visual Studio 17.5预览版中,现在支持#...
的自动完成:
未来,一些工具供应商可能会投资于原生集成到Visual Studio中。许多旧扩展在VS2022中已不再可用,或者作者仍在开发符合新要求的新版本。
另一方面,你有VS Code,它被GitHub自己内部使用,在浏览器中运行,powers github.dev和github codespaces,并且不带有Visual Studio 2022的遗留问题。这不是微软,而是GitHub扩展了vscode,并通过扩展和对编辑器的开源贡献为其平台添加了支持。GitHub在vscode中有不同的利益,他们拥有工程人员,知道如何扩展基于Atom的应用程序(他们基本上构建了这项技术),因此,他们的功能已经添加到vscode中。
这公平吗?我们是否也想要它在大型VS中?当然,但不幸的是,目前资金并没有花在这个方面。
有几种方法可以实现你想要的内容。但没有一种完全符合你的要求。
网络
主要的方法是从浏览器开始工作。在每个问题上,都有一个开发部分,您可以从中创建一个分支或从相关分支启动拉取请求:
然后,您可以立即在本地进行检查
或者导航到分支的代码面板,然后单击“在 Visual Studio 中打开”链接。这将使用您选择的存储库在正确的上下文中启动 Visual Studio,并为您本地检出分支以供开始工作。
在此分支上进行的任何提交都会自动与问题相关联,因此每次无需传递#issuenumber
。
命令行界面
除了从浏览器中工作外,另一种选择是使用CLI。如果您已安装GitHub CLI,则它将从远程列表中获取您的存储库的上下文,并且您可以直接从Visual Studio内置终端执行快速命令。
gh pr create
创建一个新的 PR。
gh issue list
快速列出您的未解决问题
gh issue develop
在远程创建一个分支,将其与您的问题关联并在本地检出该分支。
需要一点时间来熟悉命令,但如果您喜欢CLI,这是一种快速的工作方式。
在Visual Studio中
您可以从当前状态创建拉取请求,然后将您带到浏览器,并填充大部分数据。从那时起,问题自动完成也可以在浏览器中工作。
为了获得你想要的其他功能,你必须安装扩展。不幸的是,由于大部分功能已经移入到 Visual Studio 中,GitHub 已经停止对旧版 Visual Studio 扩展的开发。构建并维护适用于多个版本的 Visual Studio 扩展并不容易,因此我不认为这将重新启动。
我依赖于
Git Web links extension 来在工作文件上下文中快速切换到 Web 和 Visual Studio。
在设置中,您可以将默认行为设置为不复制,而是在浏览器中打开。
目前,通过公开列出的扩展名无法获得其他所需功能。Azure DevOps本身已删除或弃用了大部分这些功能,因此我不指望Visual Studio团队急于重新添加对问题跟踪的一流支持。