Git Extensions 7.2.0 已发布。这个版本没有改变其核心定位：它仍是一款独立的 Git 仓库桌面管理工具，但运行环境已经升级到 .NET 10，同时补充了 RevisionGrid 的 ahead/behind 信息、翻译更新、RC1 阶段错误修复和若干小幅改进。对准备升级的团队来说，真正需要提前处理的是运行时和 Git 客户端版本，而不是界面本身。
升级前先核对两个版本
Git Extensions 7.2.0 要求安装 .NET 10.0 Desktop Runtime 10.0.9 x64 或更高的 10.x 版本，并推荐使用 Git 2.53.0 或更高版本。
这里有两个容易混淆的地方：
- 需要的是 Desktop Runtime，仅安装普通 .NET Runtime 不一定满足 Windows 桌面应用的运行要求。
- 运行时架构应为 x64。在装有多个 .NET 运行时的开发机上，不要只看
dotnet命令是否存在，还要检查实际安装清单。
可以在 PowerShell 中执行以下命令进行升级前检查：
$ErrorActionPreference = "Stop"
Write-Host "Git version:"
git --version
Write-Host "`nInstalled .NET runtimes:"
dotnet --list-runtimes
Write-Host "`nRelevant .NET Desktop runtimes:"
dotnet --list-runtimes |
Select-String "Microsoft.WindowsDesktop.App 10\.0\."
预期结果中应出现类似下面的条目，具体补丁版本可以更高：
Microsoft.WindowsDesktop.App 10.0.9 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
还可以用一段可直接运行的 PowerShell 脚本完成基础判定：
$desktopRuntime = dotnet --list-runtimes |
Select-String "Microsoft.WindowsDesktop.App 10\.0\." |
ForEach-Object {
if ($_ -match "Microsoft\.WindowsDesktop\.App (\d+\.\d+\.\d+)") {
[version]$Matches[1]
}
} |
Where-Object { $_ -ge [version]"10.0.9" } |
Select-Object -First 1
if (-not $desktopRuntime) {
Write-Error "Missing Microsoft.WindowsDesktop.App 10.0.9 x64 or a newer 10.x runtime."
}
$gitText = git --version
if ($gitText -notmatch "(\d+\.\d+\.\d+)") {
Write-Error "Unable to detect the Git version."
}
$gitVersion = [version]$Matches[1]
if ($gitVersion -lt [version]"2.53.0") {
Write-Warning "Detected Git $gitVersion; Git 2.53.0 or newer is recommended."
} else {
Write-Host "Environment check passed: Desktop Runtime $desktopRuntime, Git $gitVersion"
}
这段脚本假设 dotnet 和 git 已加入 PATH。它适合改造成企业软件分发前的检测脚本，但不能单独证明运行时为 x64；在混合架构环境中，还应确认命令来自 C:\Program Files\dotnet\dotnet.exe，而不是 32 位安装目录。
RevisionGrid 中的 ahead/behind 有什么用
此次更新明确提到，RevisionGrid 会绘制 ahead/behind 信息。它描述的是两个引用之间尚未共享的提交数量：
ahead：本地分支拥有、对比分支尚未拥有的提交数。behind：对比分支拥有、本地分支尚未拥有的提交数。
过去，开发者常常需要切到终端执行 git status 或比较提交范围，才能判断当前分支是否应该推送、拉取或变基。把这组信息放进修订历史视图后，查看提交图时就能更快识别分支偏离状态。
即使暂时没有升级，也可以用 Git 命令核对 UI 中的数字。以下示例比较当前分支和其上游分支：
git fetch --prune
git rev-list --left-right --count HEAD...@{upstream}
输出示例：
3 2
在这个比较方向中，左侧表示当前分支独有的提交数，也就是 ahead；右侧表示上游分支独有的提交数，也就是 behind。为了避免读取旧的远端引用，比较前应先执行 git fetch。
也可以显式比较两个分支：
git rev-list --left-right --count feature/login...origin/main
需要注意，ahead/behind 只反映提交图关系，并不直接说明哪一侧的代码“更新”或“正确”。一次 rebase、force push 或远端历史重写都可能显著改变数字。看到 behind 不等于应该直接执行 git pull，团队仍需根据合并、变基和受保护分支策略选择操作。
翻译、修复与小改进的实际价值
7.2.0 包含许多新增或更新的翻译，并吸收了 RC1 阶段的错误修复。摘要没有列出每项修复的细节，因此不宜推断具体缺陷已经解决；更稳妥的做法是在团队常用流程中进行一次短回归测试。
建议至少覆盖这些操作：
- 打开包含多个 remote 和大量提交的仓库，确认 RevisionGrid 能正常加载。
- 执行 fetch，检查 ahead/behind 是否随远端引用更新。
- 创建提交并完成 push，确认提交、凭据和远端交互正常。
- 检查 diff、分支切换、merge 或 rebase 等团队高频操作。
- 切换团队使用的界面语言，确认菜单和对话框没有影响操作的截断或歧义。
对于大型仓库，还应记录升级前后的提交图加载时间。小幅界面改进通常风险较低，但运行时主版本变化可能与终端安全软件、企业应用白名单或集中部署策略发生关联。
团队采用建议
个人开发机可以先完成 .NET Desktop Runtime 和 Git 的版本检查，再安装 Git Extensions 7.2.0。企业环境则更适合分批部署：先选择少量包含大型仓库、多远端和复杂分支历史的机器验证，再扩大范围。
升级清单可以压缩为四项：
- 安装 .NET 10.0 Desktop Runtime 10.0.9 x64 或更高的 10.x 版本。
- 将 Git 升级到推荐的 2.53.0 或更高版本。
- 在执行
git fetch后核对 RevisionGrid 的 ahead/behind 数字。 - 保留旧版安装包或组织的软件回退渠道，直到核心工作流验证完成。
这次发布最直接的收益，是让分支偏离状态更早出现在开发者查看历史的地方。不过，ahead/behind 是判断依据，不是自动操作指令；把它与团队既有的 fetch、merge、rebase 和 force-push 规则结合起来，才能真正减少误操作。