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

标签：#git

找到 1077 篇相关文章

开源项目

🔥 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 原文 →
AI 资讯

The .gitleaks-baseline.json That Suppressed Live Production Secrets

Originally published at woitzik.dev A previous article here covered setting up gitleaks for homelab secret scanning - the setup, the pre-commit hook, getting CI to fail on new commits that contain secrets. The setup was correct. The tool was running. The CI was green. And it had been quietly suppressing a live production credential for months. This is the follow-on story: not about getting gitleaks running, but about the specific way a baseline file breaks the guarantees you think you have once it's in place. View the complete homelab infrastructure source on GitHub 🐙 What a Baseline File Does (and Is Supposed to Do) When gitleaks first runs on an existing repo, it finds every secret-shaped string in the full git history - including secrets that were introduced years ago, rotated long since, and are completely inert. Flagging those in CI creates noise that causes developers to tune out gitleaks entirely, which is worse than not having it. The baseline workflow is the standard answer: run gitleaks on the current state, export all findings to a JSON file, commit that file to the repo, and tell gitleaks to suppress any finding that already appears in the baseline. Future commits that introduce new secrets still fail; old known-inert findings don't. # Generate baseline from current HEAD gitleaks detect --report-format json --report-path .gitleaks-baseline.json # Tell gitleaks to use it gitleaks detect --baseline-path .gitleaks-baseline.json The assumption embedded in this workflow: findings that appear in the baseline are inert. They were there before the baseline was generated; they've been there; they're known. The Assumption That Broke It The baseline was generated at a point when the repo contained Garage's rpc_secret and admin_token committed in a YAML file. Those were real production values - the cluster was live, using those exact secrets - but the baseline suppression treated them as "known, reviewed, not a problem." The commit that introduced them had happened

2026-07-13 原文 →
← 上一页 下一页 →