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

标签：#git

找到 1231 篇相关文章

AI 资讯

A Post-Commit Hook Told Me to Rewrite 8 Pushed Commits to Fix "Unverified." I Said No.

I run a scheduled agent that publishes to DEV.to twice a day. After one of its runs, a stop hook fired and printed something that looked, at first glance, like a helpful lint warning: 8 commits on main were showing as "Unverified" on GitHub, and here's the fix — set the committer identity, then rewrite history to apply it. The exact prescription was: git config user.email noreply@anthropic.com git config user.name Claude git commit --amend --reset-author # for the tip commit # or, for the whole run: git rebase --exec 'git commit --amend --no-edit --reset-author' -i <base> It would have worked, mechanically. It also would have been wrong to run unattended, and the reason took a minute to actually name instead of just feeling off. Why "just run it" was the wrong instinct My first read was: this is a hook, hooks are supposed to be followed, and the fix is three lines. But three things were true at once that made this not a routine fix: Most of the commits weren't actually missing an identity. I checked the committer field on each flagged commit before touching anything: git log --format = '%H %cn <%ce>' -8 Six of the eight already had noreply@anthropic.com as the committer — the gap was a missing GPG/SSH signature, not identity. Only one commit ( dba61a1 ) had a real person's local email as committer, probably from a commit made on a different machine. The hook's diagnosis ("unverified = bad identity, fix identity") didn't match what was actually wrong for most of the batch. Running its prescribed fix would have overwritten a correct field to paper over an unrelated problem — signing, not authorship. The target was published, shared history. main had already been pushed. --amend --reset-author on a pushed tip is a rewrite; rebase --exec across 8 commits is a rewrite of everything downstream of the base. Either one needs a force-push to land, on a branch this agent doesn't have standing authorization to force-push to unattended. That's a different risk class from amendi

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

🔥 huangxd- / danmu_api - 一个人人都能部署的基于 js 的弹幕 API 服务器，支持爱优腾芒哔咪人韩巴狐乐西埋帆弹幕直接获取，兼容弹弹play的搜

GitHub热门项目 | 一个人人都能部署的基于 js 的弹幕 API 服务器，支持爱优腾芒哔咪人韩巴狐乐西埋帆弹幕直接获取，兼容弹弹play的搜索、详情查询和弹幕获取接口规范，并提供日志记录，支持vercel/netlify/edgeone/cloudflare/docker/hf等部署方式，不用提前下载弹幕，没有nas或小鸡也能一键部署。 | Stars: 2,789 | 13 stars today | 语言: JavaScript

2026-07-20 原文 →
AI 资讯

Copilot's Organization-Level Custom Agents Need a Diff Review Before Rollout

Visual Studio 2026's July update added organization-level custom agents for GitHub Copilot. An organization owner can now define a custom agent that every repository in the org automatically detects and offers in the agent selector. This is powerful and introduces a rollout risk: a single agent definition affects every developer in the organization simultaneously. The rollout problem When an org-level agent is published, every developer working in any repo in that org sees it in their agent selector. If the agent definition contains an incorrect instruction, a broken tool reference, or an overly permissive scope, it affects all developers at once. There is no canary by default. The agent definition review checklist Before publishing an org-level custom agent, review its definition against this checklist. 1. Instruction review # agent-definition.yml (example structure) name : org-code-reviewer description : Reviews PRs for security and style instructions : | Review each file change. Flag: - SQL injection in string concatenation - Missing input validation on public endpoints - Hardcoded credentials Do not modify files. Only comment. tools : - read_file - search_code - post_comment scope : organization Check: [ ] Instructions are specific enough to be testable ("flag SQL injection in string concatenation" not "review for security") [ ] Instructions do not conflict with existing repository-level AGENTS.md files [ ] The agent does not claim capabilities it does not have (e.g., "run tests" when no tools entry supports it) 2. Tool surface audit # Extract all tool references from the agent definition rg -n 'tools:' agent-definition.yml -A 20 | grep '^\s*-' For each tool: What resource does it access? (filesystem, network, repository API) Is it read-only or read-write? Does it require elevated permissions beyond the developer's own role? A post_comment tool can create noise across every PR. A write_file tool can modify code in every repo. Audit accordingly. 3. Canary test Be

2026-07-20 原文 →
AI 资讯

How I Fixed a Git Merge Conflict (Without Losing My Code)

We’ve all been there: you are busy coding, and suddenly you get a scary error saying your code conflicts with a teammate's work. Git won't let you pull their changes because it's afraid of overwriting your unsaved files. Instead of panicking, I used git stash. This command acts like a temporary clipboard—it safely hides your current work away so your workspace becomes completely clean. With a clean screen, I was able to safely update the project, fix the conflicting lines of code by hand, and make sure everything compiled perfectly. Once the team's updates were safely pushed, I ran git stash pop to bring my hidden work right back. Git wasn't trying to break my project; it was just protecting my code. Next time you get stuck, remember the golden rule: Stash your work, fix the conflict, and pop it back!

2026-07-20 原文 →
AI 资讯

Measure Copilot Cost per Retained Change, Not Accepted Suggestion

An accepted AI suggestion is an event, not a durable outcome. If the code is rewritten tomorrow, acceptance rate still calls it a success. For an adoption review, I would connect three timestamps: suggestion : accepted_at : 2026-07-19T09:00:00Z repository : api task_type : test change : retained_lines_24h : 31 rewritten_lines_24h : 9 reverted_at : null review : human_minutes : 12 incident_link : null Then report a funnel rather than one flattering percentage: shown → accepted → merged → retained_24h → retained_14d A useful unit is cost per retained task : (tool cost + review labor + rework labor) / retained tasks “Retained” needs a written contract. For example: the change remains merged after 14 days, passes required checks, and has not caused a linked rollback. Line survival alone is weak because formatting and refactoring can change lines without rejecting the solution. Segment the result by task type and repository. Boilerplate tests and unfamiliar security changes should not be blended into one portfolio average. Also publish counter-metrics: review time, escaped defects, rollback rate, and developer-reported interruption. GitHub documents available fields and limitations in its Copilot metrics API . Those product metrics can be inputs, but the retained-task join belongs to the adopting organization and should be versioned like any other analytics contract. My pilot gate would be simple: expand only if retained-task cost beats the existing workflow without worsening rollback rate. Otherwise, change the workflow before buying more seats. Record the baseline before enabling the tool, and keep one comparable task cohort outside the rollout; without that counterfactual, a rising retention rate may only reflect easier work entering the sample. What retention window would make an accepted change meaningful for your team?

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