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

标签：#git

找到 1246 篇相关文章

AI 资讯

AI Attribution Governance: Enforcing AI Disclosure Policies at the CI Level

The open-source ecosystem is converging on a hard question: when a commit is written with AI assistance, how do we know — and how do we enforce the disclosure policy? Python's discourse, Linux kernel's Assisted-by trailer, Fedora's AI policy, Apache's disclosure guidelines — every major project is grappling with this. But until now, there has been no tool at the CI level to enforce whatever policy a project chooses. Commit Check v2.11.0 introduces AI Attribution Governance — a new feature that detects known AI tool signatures in commit messages and lets projects decide whether to forbid them outright. To our knowledge, no existing tool enforces this kind of policy at the CI level. The industry need The conversation around AI disclosure is no longer theoretical: The Linux kernel standardized on the Assisted-by: trailer format — but deliberately stopped short of CI enforcement. As Sasha Levin noted at the Maintainers Summit, the kernel sets the convention, not the gate. The Python community is actively discussing whether Claude Code usage should be documented VS Code issue #313962 proposes replacing Co-authored-by with Assisted-by for AI agents Fedora requires AI disclosure (recommends the Assisted-by trailer). QEMU and Gentoo go further and forbid AI-generated contributions entirely. Each community defines its own policy — but none provides a neutral enforcement layer. That is the gap Commit Check fills. Configuration: a single toggle Commit Check keeps it simple. One configuration value, three ways to set it. TOML ( cchk.toml ): [commit] ai_attribution = "forbid" CLI: commit-check --message --ai-attribution = forbid Environment variable: CCHK_AI_ATTRIBUTION = forbid commit-check --message Two modes: Mode Behavior "ignore" No validation (default, backward compatible) "forbid" Rejects any commit containing known AI tool signatures There is no require mode in this release — only ignore and forbid . The reason is pragmatic: requiring an Assisted-by or similar trailer is

2026-07-07 原文 →
AI 资讯

How to Set Up Claude Code for a Project with Skills, Agents, Hooks, and a Secure GitHub Repository

How to Set Up Claude Code for a Project with Skills, Agents, Hooks, and a Secure GitHub Repository AI coding tools work best when they understand the project around the code. A fresh Claude Code session can answer questions and edit files, but it does not automatically know your architecture decisions, coding standards, security expectations, testing rules, pull request format, or operational constraints. That context needs to live somewhere predictable. This guide walks through a full Claude Code project setup using a reusable repository owned by desertfox33 : Reference repository: https://github.com/desertfox33/claude-code-project-template The goal is not just to create folders. The goal is to make Claude Code behave consistently across real project work: reviewing code, writing tests, preparing pull requests, checking security concerns, and following project-specific rules. Before using this setup in a production environment, verify current Claude Code behavior against the latest official documentation. Tooling, configuration names, and feature behavior can change. What We Are Building The repository uses this structure: claude-code-project-template/ ├── CLAUDE.md ├── CLAUDE.local.md.example ├── AGENTS.md ├── .mcp.example.json ├── .gitignore ├── SECURITY.md ├── CONTRIBUTING.md ├── .github/ │ ├── CODEOWNERS │ ├── dependabot.yml │ └── pull_request_template.md ├── .claude/ │ ├── settings.json │ ├── settings.local.json.example │ ├── rules/ │ │ ├── code-style.md │ │ ├── api-conventions.md │ │ ├── testing-standard.md │ │ └── pr.md │ ├── commands/ │ │ ├── review.md │ │ ├── deploy.md │ │ ├── scaffold.md │ │ ├── test.md │ │ └── pr.md │ ├── skills/ │ │ ├── code-review/ │ │ │ ├── SKILL.md │ │ │ └── review-checklist.md │ │ ├── testing-patterns/ │ │ │ ├── SKILL.md │ │ │ └── test-strategy.md │ │ ├── pr-description/ │ │ │ ├── SKILL.md │ │ │ └── template.md │ │ └── security-review/ │ │ └── SKILL.md │ ├── agents/ │ │ ├── security-reviewer.md │ │ ├── test-writer.md │ │ └── researc

2026-07-06 原文 →
AI 资讯

Why Developers Don't Read READMEs

Developers are the world's most efficient skimmers. When someone lands on your repo, they're running a rapid mental triage: What does this do? (5 seconds) Can I run it? (10 seconds) Should I trust it? (5 seconds) If they can't answer all three within 20 seconds, they close the tab and move on. They don't owe you a careful read. They're choosing between your project and ten others. Most READMEs fail the triage test because they're written from the author's perspective, not the reader's. The author knows how it works, so they explain how it works. The reader doesn't know if it works at all, so they need to know what it does first. That's the gap. Let's close it. The README That Passes the 20-Second Test Every high-performing README follows a version of the same structure. The order is not arbitrary — it mirrors the reader's decision-making process. 1. One-Line Description (Not Your Project's Name) The name is already in the repo title. The first line of your README should be a plain-language sentence of what this thing does . ❌ SuperCache v2.0 ✅ A zero-config in-memory cache for Node.js that cuts database eat time by 60%. If your one-liner doesn't tell me what problem you're solving, I'm already skimming toward the exit. 2. A 30-Second "Why This Exists" Paragraph Two to four sentences. What problem does this solve? Who is it for? Why this over the alternatives? This is not a marketing pitch. It's a fast filter. You want the right people to know immediately that this is for them — and the wrong people to know it's not. 3. Demo / Screenshot First — Before Installation This is the most skipped section in most READMEs. It shouldn't be. A GIF, screenshot, or three-line code output does more work than five paragraphs of description. Show me what success looks like before you tell me how to get there. If I can see that your output solves my problem, I'll read every word of your installation guide. 4. Installation — Zero Assumptions Assume your reader is smart but unfamiliar

2026-07-06 原文 →
开发者

The Helm Chart Is a Platform Contract — Not a Template

Early in building our cloud infrastructure, we had a problem nobody talks about — because it happens so slowly you almost don't notice it. We had eight separate Helm charts. One for services that needed KEDA scaling. One for standard HPA. One for backends that exposed HTTP. One for workers that didn't. One for Azure Functions. One for frontends. Eight charts, all living in the same repository, all drifting apart from each other. The charts started as copies of each other. Over time each one picked up its own fixes, its own conventions, its own slightly-different take on security contexts and ServiceAccount annotations and rolling update strategy. Nobody made a decision to diverge. It just happened. Every time we fixed something in one chart — say, wiring up Azure Workload Identity to every ServiceAccount — we had to remember to propagate that fix to seven others. Sometimes we did. Sometimes we didn't. We'd find out when something broke in an unexpected way six weeks later. Helm chart drift is more dangerous than dependency drift. At least with a dependency, you know what version you're on. With eight loosely related charts, you just don't know what you don't know. This is the story of how we replaced all eight with a single versioned chart, published to an OCI registry, and consumed by 70+ services through ArgoCD multi-source Applications — and what that structure forced us to think clearly about. The Two-Questions Framework The first thing we had to do was figure out why we had eight charts in the first place. What was actually different between services that justified a different chart? We landed on two questions: Does it expose HTTP? — This determines whether it needs an ingress, a Service, liveness/readiness probes on an HTTP path. What drives its scaling? — Standard CPU/memory HPA, or event-driven scaling via KEDA (Azure Service Bus, Event Hubs)? That's it. Everything else — security contexts, Workload Identity, pod anti-affinity, rolling update strategy, how s

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

🔥 OthmanAdi / planning-with-files - Persistent file-based planning for AI coding agents and long

GitHub热门项目 | Persistent file-based planning for AI coding agents and long-running agentic tasks. Crash-proof markdown plans that survive context loss and /clear, plus a deterministic completion gate and multi-agent shared state on disk. Manus-style. Works with Claude Code, Codex CLI, Cursor, Kiro, OpenCode and 60+ agents via the SKILL.md standard. | Stars: 24,557 | 61 stars today | 语言: Python

2026-07-05 原文 →
AI 资讯

Securing Your Terraform Infrastructure with Checkov and GitHub Actions

Infrastructure as Code (IaC) has revolutionized how we provision and manage cloud resources. Tools like Terraform, Pulumi, and OpenTofu allow us to define infrastructure using code, making it versionable, repeatable, and scalable. However, with great power comes great responsibility. Misconfigurations in IaC can lead to massive security breaches, such as publicly exposed data storage or overly permissive access roles. This is where Static Application Security Testing (SAST) comes in. SAST tools analyze your source code to find security vulnerabilities before the code is deployed. In this article, we'll explore how to apply SAST to a Terraform project using Checkov , a popular open-source static analysis tool for IaC, and how to automate this process using GitHub Actions. (Note: We are intentionally avoiding tfsec for this demonstration to explore other powerful alternatives). Why Checkov? Checkov, created by Bridgecrew (now part of Prisma Cloud), is a static code analysis tool for IaC. It scans cloud infrastructure provisioned using Terraform, Terraform plan, Cloudformation, Kubernetes, Dockerfile, Serverless, or ARM Templates and detects security and compliance misconfigurations. It includes hundreds of built-in policies covering security and compliance best practices for AWS, Azure, and Google Cloud. The Demo Scenario: A Vulnerable S3 Bucket Let's start by creating a simple Terraform configuration for an AWS S3 bucket. We will intentionally introduce a security misconfiguration: making the bucket public without encryption. Create a file named main.tf : # main.tf provider "aws" { region = "us-east-1" } resource "aws_s3_bucket" "my_vulnerable_bucket" { bucket = "my-company-public-data-bucket-12345" } # Misconfiguration 1: Public Read Access resource "aws_s3_bucket_acl" "example" { bucket = aws_s3_bucket . my_vulnerable_bucket . id acl = "public-read" } If we were to deploy this, anyone on the internet could read the contents of this bucket. Let's see how Checkov can

2026-07-05 原文 →
AI 资讯

How Git Actually Works Under the Hood

Most developers use Git every day and understand almost none of it. That's not an insult, it's just the reality of how most people learn tools. You pick up the commands that get you through the day, you memorize the ones that fix the situations you keep breaking, and you build a working mental model that is almost entirely wrong at the mechanical level. The mental model most people carry looks something like this: Git tracks changes to files. When you commit, it saves a snapshot of what changed. Branches are pointers to different lines of work. That's roughly correct at a surface level, but it skips over the actual machinery in a way that leaves you confused every time something unexpected happens. Why does rebasing rewrite history? Why are commits immutable? Why does detached HEAD state exist? Why can you lose work in ways that feel impossible if Git is just tracking changes? The answers are all in the object model, and the object model is surprisingly simple once you sit with it. Git is a content-addressable filesystem Before any of the version control concepts, Git is a key-value store. You put content in, you get a hash back. You use that hash later to retrieve the content. That's the entire foundation, and everything else is built on top of it. The hash Git uses is SHA-1, producing a 40-character hexadecimal string. When you run git hash-object on a file, Git takes the content, prepends a small header describing the object type and size, and runs SHA-1 over the whole thing. The resulting hash is both the key and the identity of that content. Two files with identical content will always produce the same hash. A file whose content changes even slightly will produce a completely different hash. This is the first thing that breaks people's mental models. In most storage systems, identity is location: a file is "that file" because it lives at that path. In Git's object store, identity is content. The path a file lives at is separate metadata, not the file's identity

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