GitHub/github

24 posts

github

Using the GitHub Copilot SDK for Java (opens in new tab)

Ed Burns is a Principal Software Engineer focused on bringing idiomatic Java experiences to Microsoft and GitHub technologies. He has worked with Java since 1997 across client, server, cloud, and artificial intelligence applications. ## Professional Focus - Works at Microsoft and GitHub. - Concentrates on making Java development feel natural and idiomatic within their technologies. ## Experience - Has used Java since 1997. - His experience spans: - Client-side development - Server-side systems - Cloud technologies - Artificial intelligence No specific blog topic or technical argument is included in the provided content.

github

How we took malware advisories beyond npm (opens in new tab)

Ankit is a Senior Engineering Manager at GitHub and leads the Dependabot team within the Supply Chain Security organization. His work involves protecting more than 30 million repositories across over 34 package ecosystems, giving him extensive exposure to software supply-chain risks and attacks. ## Role and Responsibilities - Leads the Dependabot team at GitHub. - Works within GitHub’s Supply Chain Security organization. - Oversees systems monitoring 30M+ repositories. - Supports more than 34 package ecosystems. ## Security Perspective - The scale of Dependabot’s coverage exposes Ankit to a wide range of supply-chain threats. - This responsibility has made him particularly vigilant about software supply-chain attacks.

github

Turn one giant AI-generated pull request to a reviewable stack (opens in new tab)

Coding agents can rapidly produce complete features, but they often deliver them as enormous, shallow pull requests that are difficult to review and slow to merge. GitHub’s stacked pull requests address this by decomposing a feature into small, dependency-ordered layers. The result is a reviewable chain of changes that preserves context while reducing maintenance and merge conflicts. ## The Problem with Giant AI-Generated Pull Requests - A seemingly simple product-search feature may include: - A data model and seed data - An API route and validation - Client integration and UI states - Coding agents commonly generate all of this in a single 1,000-plus-line pull request. - Large pull requests: - Become difficult to review thoroughly - Cause reviewers to lose context - Receive lower-quality feedback - Take longer to merge - Are more likely to land under-reviewed Traditional alternatives are also imperfect: one large pull request harms reviewability, while a manually maintained chain of smaller pull requests creates synchronization work and conflict-management overhead. ## Stacked Pull Requests - Stacked pull requests break a feature into logical, dependent layers. - Each pull request focuses on one concern and remains small enough for reviewers to understand. - Later layers build naturally on earlier, already-reviewed work. - Different layers can be assigned to specialized reviewers, such as data or UI owners. For the product-search example, the proposed stack is: - **L1 – `feat/catalog-data`**: Typed catalog, seed data, validation, and data access; based on `main` - **L2 – `feat/search-api`**: Validated `/api/products/search` endpoint; based on L1 - **L3 – `feat/chat-grounding`**: Connects chat to the API and real product data; based on L2 - **L4 – `feat/grounded-ui`**: Adds product citation cards and UI states; based on L3 ## Setting Up the Stack - Choose the stack base first, because CI checks and merge rules are evaluated against it. - Place foundational work closest to the base and dependent work above it. - Install GitHub’s CLI extension: ```bash gh extension install github/gh-stack ``` - Teach coding agents how to create and manage stacks: ```bash gh skill install github/gh-stack ``` Alternatively: ```bash npx skills add github/gh-stack ``` - Ensure CI is configured, since every pull request layer is checked against the stack base. ## Assigning Agents to Layers The example uses separate agents with strict scope boundaries: - **L1:** Data modeler agent - **L2:** Backend agent - **L3:** Frontend agent - **L4:** Frontend agent This division encourages each agent to produce a focused pull request rather than reconstructing the entire feature in one pass. ## Recommended Workflow The development process starts with the foundational catalog layer and proceeds upward through the dependency chain. Agents work autonomously within their assigned scope, while each completed layer can be reviewed independently before subsequent layers are evaluated. Stacked pull requests are a practical way to preserve the productivity benefits of coding agents without sacrificing review quality. Teams should define clear layer boundaries, establish the stack base, assign appropriate reviewers or agents, and run CI for every layer.

github

GitHub Copilot app for Beginners: Getting started (opens in new tab)

The GitHub Copilot app is designed as a development workspace rather than a single AI chat window. It connects agent sessions to projects, supports parallel tasks, provides an interactive browser canvas for UI work, and helps manage pull requests through Agent Merge. Together, these features aim to support the full workflow from exploration to shipping. ## Project-Based Agent Sessions - Each session is connected to a specific project and its repository context. - Projects can be selected from GitHub or added from a local machine. - Copilot can inspect the codebase, identify relevant files, implement changes, and run tests. - This reduces the setup required before beginning a development task. ## Managing Multiple Work Threads - Users can create separate sessions for different tasks without interrupting ongoing work. - **Quick Chat** provides a lightweight way to: - Ask questions about Copilot or the codebase - Explore implementation options - Investigate unfamiliar parts of an application - Gather context before making changes - Returning to an existing session preserves its history and allows work to continue from where it stopped. ## Interactive UI Work with Canvas - The app includes a browser canvas for previewing applications alongside the AI conversation. - Canvas can be created with the `/create-canvas` slash command. - **Enable Canvas Dev Mode** and **Pick & Polish** allow users to select page elements directly and use them as context for refinement requests. - This supports an iterative workflow in which developers can inspect the visual result, identify problems, and ask Copilot to adjust specific UI elements. ## Pull Request Assistance with Agent Merge - **Agent Merge** extends Copilot’s role beyond implementation into code review and delivery. - It can be enabled from a pull request’s options in the Copilot app. - Developers choose which actions it may perform, including: - Addressing review feedback - Helping resolve CI failures - Handling merge conflicts - Agent Merge monitors the pull request while checks and reviews are in progress, preparing it for merge once requirements are satisfied. The Copilot app is intended to centralize development activities in one workspace: start with a project, separate work into focused sessions, visually refine applications through canvas, and use Agent Merge to help complete the pull request process. Developers can learn the workflow by applying it to an existing backlog task.

github

GitHub for Beginners: Your roadmap to mastering the GitHub essentials (opens in new tab)

GitHub for Beginners presents a step-by-step roadmap from understanding version control to collaborating on projects through GitHub. It explains the essential Git concepts, account setup, repository creation, Markdown, and the GitHub flow. The central message is that beginners can master GitHub by learning a small set of practical tools and following a repeatable workflow. ## Understanding Version Control and Git - Version control tracks file changes over time, allowing developers to see what changed, when, and why. - Git replaces confusing file copies such as `final_v2` or `FINAL_actually` with a complete change history. - Git uses three main areas: - **Working directory:** where files are edited - **Staging area:** where changes are prepared for saving - **Local repository:** where committed history is stored - Core commands include: - `git status` to inspect changes - `git add` to stage changes - `git commit` to save a snapshot - “Pushing” code means uploading local commits to GitHub. ## Securing and Personalizing a GitHub Account - A GitHub account acts as a developer identity and should be protected with two-factor authentication. - 2FA can be enabled under **Settings → Password and authentication**. - Recovery codes should be downloaded and stored securely, such as in a password manager. - A profile README can serve as a public portfolio describing skills, projects, and interests. - The README appears on the profile when stored in a public repository named after the user’s GitHub username. ## Essential Git Commands - Beginners do not need to memorize all of Git; a small group of commands supports most daily workflows. - Important commands include: - `git config --global user.name "..."` to identify commits - `git init` to create a repository - `git clone <url>` to copy a remote repository locally - `git add .` to stage changes - `git commit -m "message"` to save changes - `git switch -c <branch>` to create and enter a branch - `git push` to upload commits - `git pull` to retrieve and merge remote changes - `git merge <branch>` to integrate another branch ## Creating a First Repository - A repository is a project’s home base: it stores files, tracks history, and supports collaboration. - To create one: - Select **New** from the GitHub dashboard - Choose a name - Set it as public or private - Optionally initialize it with a README - A `.gitignore` file excludes generated files, dependencies, system files, and temporary build output from version control. - A license communicates how others may use or share the project. ## Writing with Markdown - Markdown is a lightweight text-formatting language used throughout GitHub. - It powers READMEs, issues, pull requests, and comments. - Simple symbols and optional HTML tags can create readable documentation without complex tools. ## Following the GitHub Flow - GitHub flow provides a repeatable process for contributing safely: 1. Clone the repository 2. Create a branch 3. Make changes 4. Commit the work 5. Push the branch to GitHub 6. Open a pull request - Pull requests let colleagues review changes before they are merged. - The workflow applies to many shared projects, including repositories containing reusable AI prompts or other collaborative resources. Start with the basic Git commands, protect and document your GitHub profile, then practice the branch-and-pull-request workflow on a small repository. These fundamentals provide a practical foundation for contributing to larger team projects and open source.

github

How GitHub gave every repository a durable owner (opens in new tab)

Michael Recachinas is a Staff Security Engineer at GitHub who leads large-scale security initiatives. His work focuses on vulnerability management, secure development lifecycle tooling, and developer-first security automation. Throughout his career, he has built scalable systems designed to make secure choices easier for development teams. ## Professional Focus - Leads security programs at GitHub. - Specializes in: - Vulnerability management - Secure development lifecycle tooling - Security automation designed for developers ## Engineering Approach - Builds systems that operate at large scale. - Focuses on integrating security into developers’ workflows. - Aims to make secure practices the easiest and most natural choice. Overall, the passage presents Recachinas as a security engineering leader focused on scalable, practical, and developer-friendly solutions.

github

How GitHub used secret scanning to reach inbox zero (opens in new tab)

Michael Recachinas is a Staff Security Engineer at GitHub who leads large-scale security initiatives. His work centers on vulnerability management, secure development lifecycle tooling, and automation that helps developers make secure choices more easily. ### Professional Focus - Leads security programs at scale. - Focuses on: - Vulnerability management - Secure development lifecycle tools - Developer-first security automation ### Experience and Approach - Has built systems designed to operate reliably at large scale. - Emphasizes making secure behavior the easiest option for development teams. The provided text is a professional biography rather than a full technical blog post, so it does not include a specific argument, technical sections, or conclusion to summarize.

github

Inside the Advisory Database and what happens when vulnerability volume breaks records (opens in new tab)

Madison Ficorilli is a vulnerability transparency advocate and senior security manager at GitHub. She leads the advisory database curation team and contributes to vulnerability reporting, response, and disclosure through several industry organizations. Her perspective combines current leadership experience with prior roles in incident response and vulnerability coordination. ## Leadership at GitHub - Leads GitHub’s advisory database curation team. - Focuses on improving vulnerability transparency and the quality of security advisory information. ## Industry and Open Source Security Work - Co-chairs a relevant Open Source Security Foundation (OpenSSF) working group. - Serves on the CVE Program Board. - Advocates for effective vulnerability reporting, response, and disclosure practices. ## Professional Background - Previously worked as a product incident response analyst at GitHub. - Served as a vulnerability coordinator at the CERT Coordination Center at Carnegie Mellon University’s Software Engineering Institute. Her career reflects deep expertise across vulnerability coordination, incident response, database curation, and security disclosure policy.

github

Transitioning as a hubber (opens in new tab)

Arthur Searle describes transitioning at GitHub as a largely smooth experience, enabled by an inclusive, remote-first culture and strong workplace support. Using handles, written communication, flexible avatars, and gender-affirming benefits reduced many common sources of stress. His experience shows that transition can involve both bureaucratic challenges and profound joy when colleagues respond with acceptance and care. ## A Career Built at GitHub - Searle began in IT support and operations before teaching himself to code. - He joined GitHub’s IT Engineering team after a colleague’s referral and moved to Enterprise Security six months later. - His work has included: - Helping migrate GitHub’s main SaaS platform to infrastructure as code. - Speaking at Oxford University about version control. - Throughout his transition, his handle—“gleeblezoid”—remained constant, providing continuity at work. ## How GitHub’s Culture Supported Transition - GitHub’s remote-first structure reduced anxiety around appearance, commuting, and in-person interactions. - Much of Searle’s work happened through written communication in Slack and GitHub, limiting the pressure of speaking while undergoing voice training and hormone-related voice changes. - Employees commonly use handles and informal avatars, making gender assumptions based on appearance less central. - Searle was able to update his name and pronouns in internal systems, with colleagues consistently using them. ## Gender-Affirming Benefits - GitHub covered gender-affirming healthcare for employees. - Benefits included reimbursement for: - Voice training. - Hormone replacement therapy prescriptions. - Therapy. - The main remaining difficulty was ordinary administrative friction, such as changing his legal name in payroll systems. ## Acceptance, Joy, and Belonging - Searle contrasts his experience with people who remain closeted, repeatedly come out to new coworkers, or face extensive bureaucracy. - Colleagues treated his transition as a normal part of his life and expressed genuine happiness for him. - Small gestures had a major emotional impact, including hearing his name and pronouns used at work for the first time and receiving a shaving kit from a teammate. - He emphasizes that being trans is not defined only by hardship; there is also joy in living openly and being supported by others. GitHub’s example suggests that inclusive policies, flexible communication practices, and everyday respect can make workplace transition significantly safer and more affirming. For organizations, support should extend beyond formal benefits to the culture and systems employees use every day.

github

I automated my job (and it made me a better leader) (opens in new tab)

Ashley Willis is GitHub’s Senior Director of Developer Relations, where she focuses on open source, community, and developer advocacy. Her work combines leadership, accessibility, and inclusion, with an emphasis on making technology more human and building resilient teams. ### Leadership and Advocacy - Leads developer relations at GitHub. - Advocates for developers and open-source contributors. - Amplifies underrepresented voices in technology. ### Community and Accessibility - Builds supportive, inclusive spaces for contributors. - Focuses on creating tools that genuinely serve their users. - Works at the intersection of leadership, advocacy, and accessibility. Overall, Willis’s career centers on strengthening developer communities and making technology more inclusive, accessible, and human.

github

Accelerating researchers and developers building multilingual AI with a new open dataset (opens in new tab)

GitHub has released the GitHub Multilingual Repositories Dataset, an open metadata resource for finding public repositories containing non-English developer content. Covering more than 40 million repositories, it classifies language use in READMEs, issues, and pull requests, helping researchers build multilingual AI tools and study representation in open source. GitHub emphasizes that the dataset is a discovery tool—not definitive language ground truth—and releases it under CC0-1.0. ## Dataset Scope and Contents - Contains over 80 million classification rows across more than 40 million public repositories. - Classifies: - READMEs - The most-commented issue - The most-commented pull request - Uses the first 150 characters of each text source, excluding samples shorter than 20 characters. - Includes classifications and confidence scores from: - fastText - Google’s CLD3 - lingua-py - Only classifications with confidence above 0.5 are included. - Repository metadata includes creation date, disk usage, stars, forks, primary language, SPDX license, issue and pull request counts, and snapshot date. ## Why Multiple Classifiers Are Exposed - GitHub does not combine the three classifiers into one definitive language label. - Classifiers differ in language coverage and confidence calibration, particularly for lower-resource languages. - Users can choose their own precision and recall strategy: - Require agreement among all classifiers for high-precision research. - Use a single classifier for broader exploratory studies. ## Language Patterns in Developer Content - Language distribution varies by repository content type. - Korean is the most common non-English language in issue text but ranks only fifth in README classifications. - Portuguese is the leading non-English README language, appearing in more than 3 million repositories. - These differences show that developer communities may use different languages for documentation, issue discussions, and code collaboration. ## Potential Applications - Find repositories with documentation or collaboration in particular languages. - Study how multilingual communities use READMEs, issues, and pull requests. - Create evaluation datasets for coding assistants, documentation generators, and code review tools. - Measure representation of European and other underrepresented languages in open source. - Provide evidence for expanding language support in developer tools and AI systems. ## Limitations and Responsible Use - Repository text is often short and may contain badges, commands, code, usernames, templates, or multiple languages. - A 150-character sample may not represent the language of an entire repository. - Classifier performance varies, especially for lower-resource languages. - The dataset should not be treated as a ground-truth language-identification benchmark. - It provides repository-level signals and should not be used to infer sensitive characteristics of repository owners, contributors, or communities. ## Importance for Multilingual AI - Many European languages are underrepresented in the data used to train and evaluate AI systems. - Developer content provides domain-specific examples of software collaboration, including installation guidance, bug reports, feature requests, and code reviews. - The dataset can help identify language gaps, improve evaluation, and support more inclusive AI tools for developers worldwide. GitHub recommends using the CC0-licensed dataset to conduct research, build evaluation sets, develop tools, and improve its classifications. Its transparency and multiple confidence signals allow users to tailor the data to their own research needs while accounting for its limitations.

github

GitHub for Beginners: Answers to some common questions (opens in new tab)

The post is a beginner-friendly guide to common GitHub questions, focusing on SSH authentication and Personal Access Tokens (PATs). It explains how to securely connect a computer to GitHub, create credentials for command-line and API access, and limit those credentials appropriately. The provided excerpt ends just as it introduces merging versus rebasing. ## SSH Keys and GitHub Authentication - An SSH key consists of: - A private key that stays on the computer and must never be shared. - A public key uploaded to GitHub. - Git uses the matching key pair to verify identity when pushing and pulling code. - To create an Ed25519 key pair, run `ssh-keygen` with the email associated with the GitHub account. - Users can accept the default file location and protect the key with a passphrase. - `ssh-agent` securely stores the key so the passphrase does not need to be entered repeatedly. - The public key can be copied with `cat ~/.ssh/id_ed25519.pub` and added through **Settings → SSH and GPG keys → New SSH key**. - A descriptive title, such as “work-laptop,” helps identify the device later. ## Personal Access Tokens - A PAT is a GitHub-managed credential for authenticating command-line tools and API requests. - Tokens can be revoked and configured with limited permissions. - GitHub offers: - **Fine-grained tokens**, which can be restricted to specific repositories and individual read or write permissions. - **Classic tokens**, which use broader predefined scopes. - When creating a fine-grained token, users choose: - A name and description. - An expiration date. - Repository access. - Specific permissions and whether each is read-only or read/write. - Classic tokens are created through **Developer settings → Personal access tokens → Tokens (classic)** and use scopes to define access. - GitHub displays a token only once, so it should be copied immediately and stored securely, such as in a password manager. - A PAT can be supplied instead of a password when Git prompts for credentials in a terminal. ## Merging and Rebasing - The excerpt begins introducing the difference between merging and rebasing and how to resolve merge-related problems. - The supplied content ends before that explanation is provided. Use SSH keys for secure Git operations from a trusted device, and use narrowly scoped, expiring PATs when tools or APIs require token-based authentication. Never share private keys or tokens, and store credentials securely.

github

GitHub for Beginners: Getting started with Git and GitHub in VS Code (opens in new tab)

VS Code provides an integrated way to manage Git and GitHub without leaving the editor, reducing context switching and simplifying common version-control tasks. The post walks beginners through initializing a repository, staging and committing files, creating branches, tracking edits, and reviewing diffs. It emphasizes that Git manages source code locally, while GitHub hosts repository copies remotely. ## Git, GitHub, and VS Code - **Git** is the program used to manage source code and version history. - **GitHub** hosts copies of Git repositories. - **VS Code** uses Git to provide a graphical workflow for managing code and synchronizing it with GitHub. - Following along requires installing both Git and VS Code. ## Initializing a Repository - Open a project folder in VS Code through the **Explorer** panel. - Select **Source Control** and click **Initialize Repository**. - VS Code creates a local Git repository, initially using the `main` branch. - The branch can be renamed through the Command Palette: - macOS: `Shift-Command-P` - Windows/Linux: `Ctrl-Shift-P` - Choose **Git: Rename Branch**. ## Staging and Committing Files - Newly detected files appear with a **U**, meaning “untracked.” - Click the plus sign beside a file—or beside **CHANGES** to stage everything. - Staged files receive an **A** indicator. - Enter a commit message in the Source Control panel and click **Commit**. - Git commits changes locally; they are not uploaded to GitHub until they are pushed. ## Creating and Switching Branches - Use the Command Palette and select **Git: Create Branch…**. - Enter a branch name such as `new-features`. - VS Code creates the branch and automatically switches to it. - The active branch is displayed in the bottom-left status bar. - Branches allow developers to work on features separately from `main`. ## Understanding Change Indicators VS Code displays edits directly in the editor gutter: - A green line marks newly added code. - A blue patterned line marks modified existing code. - A red arrow marks deleted code. - Modified files appear under **CHANGES** in the Source Control panel. - Hovering over a file provides controls to open it, discard changes, or stage it. - The **CHANGES** header also provides actions for reviewing, discarding, or staging changes across all files. ## Reviewing Diffs - Clicking a changed file opens a side-by-side comparison of the current and previous versions. - The diff menu’s **Inline View** option displays changes in a single editor pane. - Inline diffs can also be edited directly, allowing corrections before staging or committing. VS Code’s Source Control integration gives beginners a practical, visual workflow for Git. A typical process is to initialize a folder, create a working branch, inspect edits, stage selected files, commit them with a descriptive message, and then push the commits to GitHub.

github

Investigating unauthorized access to GitHub-owned repositories (opens in new tab)

Alexis Wales is GitHub’s Chief Information Security Officer, responsible for protecting the platform, its products, and the open source community. With two decades of experience defending critical networks, she combines public- and private-sector expertise to address major cybersecurity challenges affecting modern technology. ## Leadership at GitHub - Leads a team of security professionals at GitHub. - Focuses on safeguarding GitHub’s platform and products. - Supports more than 150 million developers building and deploying software securely. - Helps protect the broader open source community. ## National Cybersecurity Experience - Has 20 years of experience defending critical national and private-sector networks. - Previously worked with the Department of Defense. - Served at the Department of Homeland Security’s Cybersecurity and Infrastructure Security Agency (CISA). ## Public-Private Collaboration - Her government experience shaped a strong interest in cooperation between public and private organizations. - Advocates collaboration to solve complex security threats affecting widely used technology. Overall, Wales’s work combines large-scale platform security with cross-sector cooperation to strengthen cybersecurity for developers and the broader technology ecosystem.

github

Raising the bar: Quality, shared responsibility, and the future of GitHub&#8217;s bug bounty program (opens in new tab)

GitHub is reaffirming its commitment to external security researchers while tightening bug bounty submission standards. Rising report volumes—partly driven by AI and other tools—have increased both valuable findings and unvalidated noise. GitHub’s central message is that tools are welcome, but researchers remain responsible for validating vulnerabilities, demonstrating impact, and understanding the platform’s shared security boundaries. ## Rising Submission Volume - New tools, including AI, have lowered the barrier to security research and expanded the number of people examining attack surfaces. - GitHub has also seen more reports that: - Lack a working proof of concept - Describe only theoretical attack scenarios - Concern categories already listed as ineligible - Because this challenge affects the wider industry, some bug bounty programs have shut down; GitHub instead plans to improve its program. ## Requirements for Strong Reports - Submissions must include a working proof of concept demonstrating concrete security impact. - Researchers should show what an attacker can actually accomplish, rather than merely describing a possible attack path. - Reports must respect GitHub’s published scope and ineligible findings list. Examples of generally ineligible issues include: - DMARC, SPF, or DKIM configuration problems - User enumeration - Missing security headers without a demonstrated attack path - Scanner, static-analysis, or AI-generated findings must be manually validated before submission. - Unverified false positives create unnecessary triage work and may affect a researcher’s HackerOne Signal and reputation. ## AI Is Welcome, but Validation Is Required - GitHub supports the use of AI in security research and uses AI internally. - AI-assisted reports are acceptable when findings are reproduced, verified, and supported by a working proof of concept. - Researchers remain accountable for the accuracy of their submissions, regardless of which tools produced them. - GitHub recommends a concise report structure: - A short issue summary - Clear reproduction steps and evidence, such as screenshots, HTTP requests, or terminal output - An impact statement explaining what an attacker can achieve - Lengthy theoretical explanations and AI-generated filler can obscure the actual vulnerability and slow triage. ## Shared Responsibility and GitHub’s Security Boundary - GitHub protects users through automated scanning, manual review, and other systems for detecting malicious content. - Users are still responsible for deciding what repositories, issues, code, and scripts to trust. - Users should review content before executing or interacting with it. - Cloning a repository is considered an act of trust because Git hooks, build scripts, and other automation may run locally. - Users must also secure their own environments, including tokens, credentials, and local security settings. - Scenarios generally do not bypass GitHub’s security controls when they require victims to deliberately engage with attacker-controlled content. ## Common Shared-Responsibility Scenarios - Prompt injection in content a user intentionally provides to an AI tool - Git hooks or filters executing code from a repository the user checked out - Malicious content in a repository the user chose to clone - Unexpected LLM output caused by untrusted input supplied by the user Research into these areas remains useful when it identifies a way to bypass an actual GitHub security control without requiring the user to actively trust malicious content.