今日已更新 339 条资讯 | 累计 19899 条内容
关于我们

标签：#git

找到 1065 篇相关文章

AI 资讯

Dependabot learns to wait: version-update PRs now sit for three days by default

Every time your bot merges a two-hour-old release into main, you are trusting a stranger's freshly published tarball to be the same one everyone else is looking at. Sometimes that release is a real bugfix. Sometimes it is a maintainer who fat-fingered a token, or an attacker who did not, and either way your CI cheerfully rebases against it before anyone had a chance to notice. On 2026-07-14, GitHub added a pause. Not a big one. But a real one. The actual change Dependabot version updates now sit on their hands for three days after a package is published. According to the GitHub Changelog, a release has to have been available on its registry for at least that long before Dependabot will open a version-update pull request against your repository. The cooldown is on by default and requires no configuration. It applies across every ecosystem Dependabot supports on github.com, and GitHub Enterprise Server picks it up in GHES 3.23. Security updates are exempt. If a fix for a known vulnerability lands, Dependabot will still open the PR the moment it can, because a three-day delay on the patch defeats the entire point of shipping the patch. That single carve-out is the whole design. Why three days is doing so much work Three days is not enough time to audit a package. Nobody is pretending otherwise. What three days is enough for is someone else to notice. Most malicious releases that end up on a public registry get pulled quickly once security researchers, downstream maintainers, or the registry's own scanners spot the pattern. The typosquats, the hijacked accounts, the crypto miners buried in a postinstall script: they all rely on being pulled into build automation before the pattern is visible. Dependabot's old default was to be that automation. Its new default is to let the pattern show up first. You can read this change as GitHub quietly admitting that "always up to date" was the wrong marketing promise for a supply-chain tool. The knob, and what shifted about it Cooldo

2026-07-15 原文 →
开源项目

🔥 songquanpeng / one-api - LLM API 管理 & 分发系统，支持 OpenAI、Azure、Anthropic Claude、Google Ge

GitHub热门项目 | LLM API 管理 & 分发系统，支持 OpenAI、Azure、Anthropic Claude、Google Gemini、DeepSeek、字节豆包、ChatGLM、文心一言、讯飞星火、通义千问、360 智脑、腾讯混元等主流模型，统一 API 适配，可用于 key 管理与二次分发。单可执行文件，提供 Docker 镜像，一键部署，开箱即用。LLM API management & key redistribution system, unifying multiple providers under a single API. Single binary, Docker-ready, with an English UI. | Stars: 35,709 | 30 stars today | 语言: JavaScript

2026-07-14 原文 →
AI 资讯

Why `git pull` Says "Repository Not Found" (When the Repo Exists)

The error looks like a typo in the remote URL. Usually it isn't. On a machine with more than one GitHub account signed in, this message is GitHub's way of saying wrong identity, not wrong address. The symptom A repo clone that has worked for months suddenly can't fetch or pull. The remote URL hasn't changed. The repo hasn't been renamed or deleted; you can open it in the browser just fine. Yet the command line insists otherwise: $ git pull remote: Repository not found. fatal: repository 'https://github.com/<org> /<repo>.git/ ' not found Why GitHub's error is misleading For a private repository, GitHub won't confirm or deny that the repo exists to a caller who isn't authorized to see it. Confirming would leak information about private repos to anyone probing URLs. So instead of a clear 403 Forbidden , an unauthorized request gets treated the same as a repo that truly doesn't exist: a 404 , which git renders as Repository not found . "Repository not found" on a private repo almost always means the credential attached to this request can't see it. It's rarely a wrong URL. The usual cause: two accounts, one keychain This shows up most on machines used for both personal and organization-owned work: a personal GitHub account for side projects, and a separate account (or SSO identity) that actually holds access to the org's private repos. Credential helpers cache one token per host. If the cached token belongs to the personal account, every git operation silently authenticates as that account, including ones against the org repo it has no rights to. personal-account --(switch)--> org-account Active, no repo access Has repo access Diagnose it First, confirm the remote itself is fine. $ git remote -v If the URL opens in a browser while logged into the right account, the remote isn't the problem. Next, check which credential is actually cached. On macOS with the default helper: $ git credential-osxkeychain get <<< $'protocol=https \n host=github.com' username=personal-account

2026-07-14 原文 →
下一页 →