开发工具桌面应用【免费下载链接】desktopFork of GitHub Desktop to support various Linux distributions项目地址https://gitcode.com/gh_mirrors/des/desktop点击查看免费下载本篇指南基于 GitHub Desktop含支持多种 Linux 发行版的 fork 版本的 docs/known-issues.md 文档系统梳理三大平台macOS、Windows、Linux上已确认存在的已知问题、报错现象与官方认可的变通方案workaround。阅读本文后你将掌握如何排查登录鉴权、窗口位置、证书校验、硬件加速、shell 检测、OAuth 组织访问受限等典型故障并能在官方 issue 与仓库源码中快速定位对应实现为复现、规避与二次开发提供依据。文档定位与使用方式known-issues.md是 GitHub Desktop 官方维护的“已知问题清单”用于收录那些已确认存在、但尚未在产品层面修复的问题并尽可能给出社区验证过的临时解决办法。文档开头明确了三种使用场景遇到清单中已列出的问题先亲自验证文档给出的 workaround确认它是否能解决你的问题对某个已知问题有更多疑问每个问题都关联了对应的 GitHub issue可以前往该 issue 补充评论与反馈你的问题不在清单中先去 issue 跟踪器中检索带bug标签的开启/关闭的 issue找不到或不确定时再新建 bug 报告。从仓库结构看该文档与 README.md 的 “Known issues” 一节直接互链——README 明确建议遇到问题先查阅本文档并特别提醒如果包管理器仍试图访问已关闭的 PackageCloud 源应参照本文档中的清理指引迁移。macOS 平台已知问题登录后报错“The username or passphrase you entered is not correct”关联 issue#3263该错误疑似由 macOS 系统“钥匙串Keychain”处于无效状态导致会影响所有尝试通过钥匙串存取凭据的应用。已报告的复现范围从 macOS High Sierra 10.13 (17A365) 一直到 macOS Mojave 10.14.5 (18F132)。变通方案打开钥匙串访问Keychain Access.app右键点击login钥匙串尝试“锁定”再次右键点击login钥匙串尝试“解锁”重新登录你的 GitHub 账号。该问题本质上属于系统级凭据存储异常而非应用本身的逻辑缺陷因此修复手段也聚焦于重置钥匙串状态。检查更新时提示“Could not create temporary directory: Permission denied”关联 issue#4115该问题由~/Library/Caches/com.github.GitHubClient.ShipIt目录缺少写权限引起。这是 GitHub Desktop 在更新应用时用于创建和解压临时文件的目录ShipIt 是 GitHub Desktop 的自动更新模块。变通方案关闭 GitHub Desktop在 Finder 中进入~/Library/Caches/右键点击com.github.GitHubClient.ShipIt选择显示简介Get Info展开共享与权限Sharing Permissions区域如果没有显示“你可以读与写”的提示就把自己添加为“读与写”权限重新启动 GitHub Desktop 并检查更新。频繁弹出管理员密码以安装 helper 工具关联 issue#13956使用 macOS “迁移助理Migration Assistant”迁移数据到新电脑的用户容易遇到此问题原因是迁移过程会把/Applications/GitHub Desktop.app目录的所有者改成了root。GitHub Desktop 的自动更新机制需要改写/Applications/GitHub Desktop.app目录内容因此必须拥有该目录的写权限。如果目录所有者不是当前用户每次尝试自更新都会触发管理员密码弹窗。变通方案将应用目录的所有权与权限恢复给当前用户。若应用位于/Applications/GitHub Desktop.app在终端中执行sudo chown -R ${USER}:staff /Applications/GitHub\ Desktop.app chmod -R gw /Applications/GitHub\ Desktop.app第一条命令递归地把目录所有者改回当前用户、属组设为staff第二条命令为属组追加写权限使自更新能够顺利进行。Windows 平台已知问题拔掉副显示器后窗口“消失”关联 issue#2107GitHub Desktop 会在启动之间记录窗口位置坐标与尺寸但不会感知显示配置的变化——例如你上次把窗口放在副显示器上这次拔掉该显示器后再启动窗口就会落到不可见区域。从源码可以确认这一机制主进程通过 app-window.ts 中的windowStateKeeper来自electron-window-state库读取上次保存的窗口状态用x、y、width、height构造BrowserWindow保存的窗口状态文件正是下文提到的window-state.json。而窗口状态的实时传递则由 window-state.ts 的getWindowState与registerWindowStateChangedEvents完成监听enter-full-screen、maximize、minimize、hide、show等事件并同步到渲染进程。变通方案删除%APPDATA%\GitHub Desktop\window-state.json重启 GitHub Desktop窗口会以默认尺寸与位置重新创建。证书吊销检查失败Certificate revocation check fails关联 issue#3326在企业网络环境中使用 GitHub Desktop 时可能遇到如下报错fatal: unable to access https://github.com/owner/name.git/: schannel: next InitializeSecurityContext failed: Unknown error (0x80092012) - The revocation function was unable to check revocation for the certificate.GitHub Desktop 在 Windows 上默认使用 Windows Secure ChannelSChannelAPI校验服务器证书。部分网络会拦截 Windows 对证书吊销状态的检查请求导致整个 Git 操作报错。仓库源码同样印证了这一设计取向resolve-git-proxy.ts 中注明“在 Windows 上 GitHub Desktop 依赖schannel作为http.sslBackend”。变通方案谨慎使用不推荐在常规 Git 使用中设置该配置项。它只是网络管理员限制 SChannel API 正常使用时的一个“逃生舱escape hatch”。在 Git shell 中执行以下命令以关闭吊销检查$ git config --global http.schannelCheckRevoke false使用“文件夹重定向Folder Redirection”配置的仓库关联 issue#2972Folder Redirection 是 Windows 面向管理员的特性用于把文件和文件夹统一托管到网络服务器上。GitHub Desktop 不支持这种配置因为 Git 无法正确解析 UNC 形式的工作目录克隆时会报错2017-09-21T23:16:05.933Z - error: [ui] git -c credential.helper lfs clone --recursive --progress --progress -- https://github.com/owner/name.git \\harvest\Redirected\andrewd\My Documents\GitHub\name exited with an unexpected code: 2. Cloning into \\harvest\Redirected\andrewd\My Documents\GitHub\name... remote: Counting objects: 4, done. remote: Compressing objects: 33% (1/3) remote: Compressing objects: 66% (2/3) remote: Compressing objects: 100% (3/3) remote: Compressing objects: 100% (3/3), done. remote: Total 4 (delta 1), reused 4 (delta 1), pack-reused 0 fatal: unable to get current working directory: No such file or directory warning: Clone succeeded, but checkout failed. You can inspect what was checked out with git status and retry the checkout with git checkout -f HEAD Error(s) during clone: git clone failed: exit status 128错误日志的核心是fatal: unable to get current working directory: No such file or directory——即 Git 无法把重定向后的网络路径当作有效工作目录。结论不支持请勿将仓库置于 Folder Redirection 管理的路径下。启用“强制 ASLRMandatory ASLR”触发 cygheap 错误关联 issue#3096Windows 10 Fall Creators Edition1709 及更高版本增强了“增强缓解体验工具包EMET”其中一项就是“强制 ASLR”。该设置会影响 GitHub Desktop 内置的 Git产生如下错误1 [main] sh (2072) C:\Users\bdorrans\AppData\Local\GitHubDesktop\app-1.0.4\resources\app\git\usr\bin\sh.exe: *** fatal error - cygheap base mismatch detected - 0x2E07408/0x2EC7408. This problem is probably due to using incompatible versions of the cygwin DLL. Search for cygwin1.dll using the Windows Start-Find/Search facility and delete all but the most recent version. The most recent version *should* reside in x:\cygwin\bin, where x is the drive on which you have installed the cygwin distribution. Rebooting is also suggested if you are unable to find another cygwin DLL.根因强制 ASLR 影响 MSYS2 核心库而 Git for Windows 正是依赖 MSYS2 来模拟进程 fork 的。因此这是MSYS2 的上游限制官方不支持规避建议要么关闭强制 ASLR要么显式放行Git\usr\bin下所有依赖 MSYS2 的可执行文件。启动时出现黑屏Black screen关联 issue#3921Electron 默认开启硬件加速图形渲染但部分显卡对硬件加速支持不佳导致应用能启动却只显示黑屏。变通方案设置环境变量GITHUB_DESKTOP_DISABLE_HARDWARE_ACCELERATION任意非空值即可后重新启动即可在启动时禁用硬件加速。在 PowerShell 中的操作步骤打开 PowerShell执行命令$env:GITHUB_DESKTOP_DISABLE_HARDWARE_ACCELERATION1启动 GitHub Desktop。该环境变量在源码中有直接实现main-process/main.ts 在应用主进程启动阶段检测到该变量后调用app.disableHardwareAcceleration()并记录一条日志。值得注意的是该变量还会连带影响凭据辅助进程在 trampoline-credential-helper.ts 中设置它会同时为 Git Credential Manager 注入GCM_GUI_SOFTWARE_RENDERING: 1让 GCM 的 GUI 也走软件渲染避免同样的黑屏问题。更新后报错“Failed to open CA file”关联 issue#4832一次 Git for Windows 的升级改变了其对http.sslCAInfo的使用方式典型报错如下fatal: unable to access https://github.com/owner/repo.git/: schannel: failed to open CA file C:/Users/account/AppData/Local/GitHubDesktop/app-1.2.2/resources/app/git/mingw64/bin/curl-ca-bundle.crt: No such file or directory成因部分用户机器上已存在的 Git for Windows 安装会在C:\ProgramData\Git\config中写入特殊配置其中可能包含http.sslCAInfo条目而该条目会被 GitHub Desktop 继承。这里存在两个问题Desktop 的 Git 操作不需要自定义证书——它默认使用 SChannel即通过 Windows 证书存储区验证服务器证书该http.sslCAInfo配置值解析到的路径/文件在 Desktop 自带的 Git 安装中并不存在。变通方案用下面的命令确认问题配置确实存在 git config -l --show-origin输出中应出现类似条目file:C:\ProgramData/Git/config http.sslcainfo[some value here]以管理员权限打开C:\ProgramData\Git\config删除形如以下的配置行[http] sslCAInfo [some value here]注册表条目被修改导致认证失败关联 issue#2623如果用户或其他应用程序修改了Command Processor注册表条目可能导致 GitHub Desktop 抛出Authentication failed错误。检查方法打开注册表编辑器regedit.exe依次导航到HKEY_CURRENT_USER\Software\Microsoft\Command Processor\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Command Processor\检查上述位置是否存在Autorun值。如果存在删除该值即可解决Authentication failed错误——因为Autorun会在每次启动命令处理器时执行额外的命令从而干扰认证流程。登录时提示“Not enough resources”资源不足关联 issue#15217登录时出现“Not enough resources are available to process this command”错误很可能是 Windows 凭据管理器中存储了过多凭据。变通方案打开“凭据管理器Credential Manager”点击“Windows 凭据”逐条检查列表删除不再需要的凭据项。Linux 平台已知问题本仓库是 GitHub Desktop 面向多种 Linux 发行版的 fork因此 Linux 部分的问题具有鲜明的发行版与打包生态特征其中部分问题与上游 Windows/macOS 版本的表现不同。PackageCloud 软件源已停用含 APT / RPM 清理指引PackageCloud 软件源已被关闭。如果安装或更新时仍出现与该源相关的报错需要删除旧源配置并按 README.md 中的新设置接入新的软件源。APT 配置清理sudo rm /etc/apt/trusted.gpg.d/shiftkey-desktop.asc sudo rm /etc/apt/sources.list.d/packagecloud-shiftkey-desktop.listRPM 配置清理sudo rm /etc/apt/sources.list.d/packagecloud-shiftkey-desktop.list清理完成后Debian/Ubuntu 用户可参照 README 中新的仓库配置例如deb-get install github-desktop或新 package feed重新接入。README 也把“包管理器仍尝试访问 PackageCloud”的用户直接导向本文档的清理小节说明这是 Linux 侧最需要优先处理的迁移类问题。启动时出现白屏White screen与 Windows 黑屏同理Electron 默认开启硬件加速部分显卡驱动存在问题会导致启动后白屏在 Parallels Desktop 等虚拟化软件中运行时硬件加速图形可能根本不可用。变通方案设置环境变量GITHUB_DESKTOP_DISABLE_HARDWARE_ACCELERATION任意非空值后重新启动应用即可在软件渲染模式下正常工作。该环境变量的底层实现在 main-process/main.ts与前文 Windows 黑屏问题完全一致。无法访问组织下的仓库GitHub Desktop 本质是一个 OAuth 应用但这个 fork 没有获得与 Windows/macOS 版本同等的权限具体表现为“Clone a Repository克隆仓库”视图中不会显示全部组织仓库向组织拥有的仓库推送时可能被拒绝并返回通用错误信息。根因组织默认开启了“OAuth App access restrictionsOAuth 应用访问限制”这会拦截本 fork 使用的 GitHub Desktop 开发应用。变通方案请组织管理员为 GitHub Desktop 开发应用批准访问权限。如果尚未向该组织发起过 GitHub Desktop 开发应用的访问请求需要先按官方指引提交申请。shell/终端检测不到一直停留在“GNOME Terminal”在非 GNOME 桌面环境下即使应用设置中已经选中了某个 shellGitHub Desktop 也可能无法正确设置环境的 shell从应用内启动 shell 时会报错 “cannot read property path of undefined”。从源码可以理解其成因Linux 侧的 shell 支持列表定义在 shells/linux.ts默认值即为Shell.GnomeGNOME Terminal随后通过getAvailableShells逐个探测/usr/bin/gnome-terminal、/usr/bin/mate-terminal、/usr/bin/tilix、/usr/bin/terminator、/usr/bin/konsole、/usr/bin/xterm、/usr/bin/alacritty、/usr/bin/kitty等二进制是否存在shells/linux.ts。当探测结果与用户选择不一致、或所选 shell 的路径解析失败时就会出现上述“卡在 GNOME Terminal / path of undefined”的现象。两种变通方案方案 1先安装第二个不同的终端切换到它再切回你想要使用的终端最后卸载第二个终端——通过触发重新探测来刷新 shell 状态方案 2打开应用的开发者工具逐步执行 JS 调用以正确设置 shell具体细节可参考关联 issueshiftkey/desktop仓库 issue #344 的评论。排查建议与总结综合三大平台的全部已知问题可以提炼出几条通用的排查思路凭据与认证类问题macOS Keychain 异常、Windows 注册表Autorun、凭据管理器堆积、Linux 组织 OAuth 受限优先检查系统级凭据存储状态与 OAuth 应用权限它们通常与网络代理、证书无关证书与网络类问题SChannel 吊销检查失败、http.sslCAInfo指向失效文件优先检查 Git 全局/系统级配置与公司网络策略必要时才动用http.schannelCheckRevoke false这类“逃生舱”配置显示与渲染类问题Windows 黑屏、Linux 白屏统一通过GITHUB_DESKTOP_DISABLE_HARDWARE_ACCELERATION环境变量走软件渲染源码实现位于 main-process/main.ts窗口与文件系统类问题副显示器消失、Folder Redirection、ShipIt 缓存目录权限本质是窗口状态持久化与路径解析能力受限前者可删除%APPDATA%\GitHub Desktop\window-state.json后者只能规避不使用重定向路径发行版生态类问题PackageCloud 停用、GNOME Terminal 卡死优先按本文档的清理与刷新步骤操作并关注 fork 仓库 README 中持续更新的安装指引。对于未收录在本清单中的问题建议回到 issue 跟踪器搜索bug标签下的历史记录或新建 bug 报告对于已收录的问题先按文档给出的 workaround 在本地验证再将结果反馈到对应 issue帮助维护者完善文档与产品。赞分享开发工具桌面应用【免费下载链接】desktopFork of GitHub Desktop to support various Linux distributions项目地址https://gitcode.com/gh_mirrors/des/desktop点击查看免费下载相关推荐GitHub Desktop 已知问题清单Known Issues实战指南macOS 与 Windows 常见故障排查与官方规避方案GitHub Desktop 已知问题清单Known Issues实战指南macOS 与 Windows 常见故障排查与官方规避方案 本文以 GitHub桌面应用版本控制开发工具VSCodium 故障排查完全指南Linux 与 Windows 常见问题与解决方案VSCodium 故障排查完全指南Linux 与 Windows 常见问题与解决方案 本指南以 VSCodium 官方 docs/troubleshootin开发工具CopyQ 已知问题排查手册Windows、macOS、GNOME 与 Wayland 场景故障解决指南CopyQ 已知问题排查手册Windows、macOS、GNOME 与 Wayland 场景故障解决指南 CopyQ 是一款功能强大的剪贴板管理器但其在 W桌面应用创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考