![\"Three](\"https://github.blog/wp-content/uploads/2026/04/record-accelleration-1920x1080-2.png?resize=1920%2C1080\")
What maintainers are telling us, what we've shipped, and how to celebrate the people behind open source.
\nThe post Welcome to Maintainer Month: Celebrating the people behind the code appeared first on The GitHub Blog.
\n","@content":"\nAt a Maintainer Unconference in Brussels this year, a breakout session had maintainers jotting down thoughts on the future of open source. One sticky note stood out:
\n\n\n\n\n\n\n\n\nAs AI gets better at writing code, human work around code becomes more important and more invisible.
\n
Mentoring new contributors, building trust across a community, making the judgement calls that shape a project’s direction: that’s the work that turns a repository into a living collaboration. And with the speed of AI, the people doing the work are carrying more than ever. Pull requests merged on GitHub have nearly doubled year over year, and agentic workflows are accelerating the pace even further. As one maintainer put it:
\n\n\n\n\n\n\n\n\nHow much time should I spend on something that you didn’t spend any time on?
\n
I’ve been part of Maintainer Month for five years now. The conversations I’m having with maintainers this year feel different—there’s a weariness, but there’s also innovation. Maintainers are converging on standards like agents.md, building trust systems, and designing workflows that put them back in control. In February, Ashley Wolf named the influx of low-quality contributions open source’s Eternal September. Maintainers told us exactly what they needed. We took notes.
\n\n\n\nSix years ago we started Maintainer Month because the people behind open source deserve better tools, real resources, and community. This year, we’re going bigger on all three.
\n\n\n\nMaintainers need better ways to manage who contributes, how, and at what volume. In the Eternal September post, we shared some of the directions we were exploring. Here’s where things stand.
\n\n\n\nGranular contribution limits: This one’s for every maintainer who’s watched their pull request queue turn into a firehose. This gives maintainers the ability to introduce limits on how many pull requests a new or unknown user can make in your project. No more choosing between closing the doors and opening the floodgates. You control how much you let in.
\n\n\n\nPull request archiving pairs with it. Sweep spam pull requests out of public view. No more emailing support to clean up your repo.
\n\n\n\nAnd there’s a brand new accessibility best practices guide on opensource.guide. Practical steps to make your project usable by everyone.
\n\n\n\nAnd we haven’t been waiting around. Since February, we’ve also shipped:
\n\n\n\nWe’re building these because maintainers asked for them. Specifically, repeatedly…and often loudly! We hear you, and we’re going to keep shipping. Please keep flagging.
\n\n\n\nWe asked companies and foundations across the ecosystem to show up for Maintainer Month. And they did! Sentry, OpenJS Foundation, Daytona, and more partners are putting real resources behind maintainers: free tools, compute credits, threat intelligence, conference tickets, and more.
\n\n\n\n\n\n\n\n\nOpen source runs on maintainers, and we’re proud to partner with GitHub to celebrate and support them. As the ecosystem scales, maintainers are doing more than ever to keep projects secure and reliable. Maintainer Month is a chance to connect, share knowledge, and remind them they’re not doing this alone.
\nRobin Ginn, OpenJS Foundation
Partners across the ecosystem are offering real resources for maintainers. Here’s what’s available:
\n\n\n\nLast year, Sentry celebrated companies that fund open source on a Times Square billboard for Maintainer Month. That’s the energy we’re looking for.
\n\n\n\nWant to join them? Whether you’re a company that depends on open source, a startup, or an educator—reach out about the Partner Pack or explore the GitHub Partner Program for more ways to get involved.
\n\n\n\nMaintainers, here’s where you can claim your Partner Pack benefits.
\n\n\n\nAnd if you maintain open source tools for science: the new Open Source for Science Fund just launched with $20 million in funding. Grants up to $1 million for projects supporting data-intensive research. Letters of intent open May 11.
\n\n\n\nThere are 20+ events and streams (and counting!) scheduled throughout Maintainer Month. Here are a few we’re excited about:
\n\n\n\nWe’d love to see you there, whether you maintain a project with millions of users or you’re just getting started.
\n\n\n\n\n\n\n\nOne thing we heard over and over from maintainers this year: they want to be ”part of something bigger and not just being a solo maintainer.” If you maintain an open source project and want to connect with others who get it, request to join the Maintainer Community, a vetted space to share experiences, get support, and have honest conversations. It’s where the “how are you handling this?” sharing of best practices is happening.
\n\n\n\nCommunity members also get access to an exclusive tier of the Partner Pack, with deeper discounts, higher credit limits, and offers you won’t find in the public pack.
\n\n\n\n\n\n\n\nOpen source is changing fast. What hasn’t changed is that real people wake up every day and choose to maintain the software the world runs on. They do it because they believe in it, and millions of us depend on that choice.
\n\n\n\nThis month is for them. Show up, pitch in, say thank you. Let’s make it count.
\n\n\n\nSee everything happening this Maintainer Month >
\n\nThe post Welcome to Maintainer Month: Celebrating the people behind the code appeared first on The GitHub Blog.
\n"},{"json_class":"Feedjira::Parser::AtomEntry","@author":"Lee Reilly","@title_type":"html","@raw_title":"Register now for OpenClaw: After Hours @ GitHub","@url":"https://github.blog/open-source/register-now-for-openclaw-after-hours-github/","@links":["https://github.blog/open-source/register-now-for-openclaw-after-hours-github/"],"@entry_id":"https://github.blog/?p=95662","@updated":{"json_class":"Time","s":1777659905,"n":0},"@published":{"json_class":"Time","s":1777906800,"n":0},"@categories":["AI & ML","Open Source","open source"],"@summary":"OpenClaw builders will gather at GitHub HQ during Microsoft Build 2026 for demos and conversations. Join in person, or watch the livestream on Twitch.
\nThe post Register now for OpenClaw: After Hours @ GitHub appeared first on The GitHub Blog.
\n","@content":"\nOpenClaw, one of the fastest-growing open source projects, has already picked up over 350,000 stars and an early community of builders exploring what agentic systems can actually do in practice.
\n\n\n\nThat’s why, on June 3, 2026, we are hosting OpenClaw: After Hours at GitHub HQ in San Francisco. The event will take place during Microsoft Build 2026.
\n\n\n\nThis evening is a chance to bring the OpenClaw community together into the same room.
\n\n\n\nWe’ll kick things off in the early evening with a fireside conversation featuring Peter Steinberger, the ClawFather and creator of OpenClaw, followed by a panel with OpenClaw maintainers and ecosystem builders sharing what’s working—and what’s not—when shipping real agentic systems.
\n\n\n\nLater in the evening, we’ll move into a series of fast-paced lightning talks and close things out with a relaxed happy hour to connect with other builders.
\n\n\n\nIf you have been following the project or building with it yourself, this is a good chance to meet others, trade notes, and get your claws into what people are actually shipping.
\n\n\n\n👉 For the full agenda and speaker lineup, please see the registration page.
\n\n\n\n📍 GitHub HQ, 275 Brannan St., San Francisco
🗓 June 3, 5:30 p.m. – 9 p.m.
📺 Livestream: twitch.tv/github
Drinks and snacks will be provided. There will be a lot here to chew on. No shellfish behavior please. And bring your sharp ideas!
\n\n\n\n\n\n\n\nSpots are limited, so register early and come ready to share what you are working on.
\n\n\n\n‼️ Please note: Submitting a registration does not guarantee attendance. We’ll follow up to confirm successful registrations.
\n\n\n\n\n\n\n\nOpenClaw is an open source framework for building and running agentic systems, focused on giving developers real control over how agents execute tasks in the wild. It provides the core pieces for orchestrating tools, managing state, and handling long running workflows, so you can move beyond prompt demos and ship systems that actually do work. It’s also probably convinced more than a few people to buy a Mac Mini just to run “one small experiment” that somehow turned into a permanent setup.
\n\n\n\nHear more about OpenClaw from the creator himself, Peter Steinberger:
\n\n\n\nThe post Register now for OpenClaw: After Hours @ GitHub appeared first on The GitHub Blog.
\n"},{"json_class":"Feedjira::Parser::AtomEntry","@author":"Kayla Cinnamon","@title_type":"html","@raw_title":"GitHub Copilot CLI for Beginners: Interactive v. non-interactive mode","@url":"https://github.blog/ai-and-ml/github-copilot/github-copilot-cli-for-beginners-interactive-v-non-interactive-mode/","@links":["https://github.blog/ai-and-ml/github-copilot/github-copilot-cli-for-beginners-interactive-v-non-interactive-mode/"],"@entry_id":"https://github.blog/?p=95654","@updated":{"json_class":"Time","s":1777565345,"n":0},"@published":{"json_class":"Time","s":1777565342,"n":0},"@categories":["AI & ML","Generative AI","GitHub Copilot","GitHub Copilot CLI","GitHub Copilot CLI for Beginners"],"@summary":"Learn the difference between CLI interactive v. non-interactive modes.
\nThe post GitHub Copilot CLI for Beginners: Interactive v. non-interactive mode appeared first on The GitHub Blog.
\n","@content":"\nWelcome to GitHub Copilot CLI for Beginners! In this series (available in video and blog format), we’ll give you everything you need to get started using GitHub Copilot CLI, from your first prompt to tips for navigating the command line like a pro!
\n\n\n\nIn this blog, we’ll cover the two main modes of the CLI: interactive and non-interactive. You’ll learn the differences between the two modes, how to enter them, and what they’re most useful for.
\n\n\n\nLet’s dive in!
\n\n\n\nInteractive mode is a back-and-forth, chat-like experience. When you launch Copilot CLI with Copilot, you’re already in interactive mode—that’s the default. Non-interactive mode is a separate option for when you want a quick, one-off answer without entering a session. (More on non-interactive mode later!)
\n\n\n\nIn interactive mode, you can ask GitHub Copilot a question, review its response, and then either follow up with questions or another prompt—all within the same session. This is the mode for those who want to work hands-on with Copilot and iterate as you go.
\n\n\n\nHere’s how to enter interactive mode:
\n\n\n\ncopilot and hit Enter.On the other hand, non-interactive mode is designed for speed and simplicity. Instead of having to enter a full session, you pass a single prompt right in the command line and get a response almost immediately, without needing to follow up with Copilot.
\n\n\n\nDesigned as an in-line experience, this mode is perfect for quick, one-shot prompts like summarizing a repository, generating code snippets, or plugging Copilot into automated workflows, without leaving your shell context. Once you get an answer, you’re right back in your terminal flow.
\n\n\n\nHere’s how to enter non-interactive mode:
\n\n\n\ncopilot -p and prompt the agent with something like “Quickly summarize what this repository does and the key folders.”Together, these two modes help you tackle all kinds of projects efficiently: interactive for explorative, deeper work, and non-interactive for fast, focused results when you already know exactly what you need.
\n\n\n\nSometimes, you may want to pick up right where you left off in a previous Copilot session, while retaining all the context from that conversation.
\n\n\n\nIf you’re in interactive mode, you can type /resume into the command line and Copilot will let you choose a previous session from a list. If you want to launch directly into the previous session picker from non-interactive mode, use copilot --resume.
It only takes one command to pick back up with Copilot, which is super useful if you already know what session you want to work in.
\n\n\n\nTake this with you GitHub Copilot CLI interactive and non-interactive modes are the fastest ways to prompt Copilot directly from your terminal. Having the option to pick between back-and-forth coding and quick prompting means you can work with Copilot, the way you want.
\n\n\n\nKeep an eye out for more videos in the GitHub Copilot CLI for Beginners series, where we’ll explore:
\n\n\n\nHappy coding!
\n\n\n\nLooking to try GitHub Copilot CLI? Read the Docs and get started today.
\nThe post GitHub Copilot CLI for Beginners: Interactive v. non-interactive mode appeared first on The GitHub Blog.
\n"},{"json_class":"Feedjira::Parser::AtomEntry","@author":"Kedasha Kerr","@title_type":"html","@raw_title":"GitHub for Beginners: Getting started with Markdown","@url":"https://github.blog/developer-skills/github/github-for-beginners-getting-started-with-markdown/","@links":["https://github.blog/developer-skills/github/github-for-beginners-getting-started-with-markdown/"],"@entry_id":"https://github.blog/?p=95615","@updated":{"json_class":"Time","s":1777326321,"n":0},"@published":{"json_class":"Time","s":1777399200,"n":0},"@categories":["Developer skills","GitHub","GitHub for beginners","Markdown"],"@summary":"Discover how to format and edit your comments and posts using Markdown.
\nThe post GitHub for Beginners: Getting started with Markdown appeared first on The GitHub Blog.
\n","@content":"\nWelcome back to GitHub for Beginners. We’ve covered a wide range of topics so far this season, including GitHub Issues and Projects, GitHub Actions, security, and GitHub Pages. Now we’re going to teach you everything you need to know to get started with Markdown, the markup language used across GitHub.
\n\n\n\nOnce you learn the basics of how to use Markdown, you’ll develop an essential skill that will transform how you write READMEs as well as how to format issues, pull requests, and your agent instruction files. By the end of this post, you’ll have the knowledge you need to make your projects and contributions easier for others to explore.
\n\n\n\nAs always, if you prefer to watch the video or want to reference it, we have all of our GitHub for Beginners episodes available on YouTube.
\n\n\n\nMarkdown is a lightweight language for formatting plain text. You can use Markdown syntax, along with some additional HTML tags, to format your writing on GitHub. You can do this in repository READMEs, issue and pull request descriptions, and comments on issues and pull requests.
\n\n\n\nMarkdown gives you the ability to create clear, readable documentation. Having a clean README in your project or a well-formatted issue can make a huge difference when someone lands on your content for the first time.
\n\n\n\nAnd one of the best parts is that when you get the syntax down, you’ll find yourself using it in almost every project you work on!
\n\n\n\nThe most common place where you’ll encounter Markdown is in your repository’s README file. But you’ll also find yourself using it in issues, pull requests, discussions, and even wikis. Any time you write or communicate on GitHub, Markdown is behind the scenes, helping your text look clean and consistent.
\n\n\n\nMarkdown extends beyond GitHub to modern note-taking apps, blog platforms, and documentation tools. It’s a widely adopted language used across the technical space, so learning how to use it can benefit you beyond just how you interact with GitHub.
\n\n\n\nWe’re going to start with the common features that you’ll use the most. While we’re going through these, you can try them out to see how they work. The easiest way to do this is by opening a markdown file on your repository.
\n\n\n\n.md (e.g., markdownTestFile.md).You can see what the Markdown text you enter will look like by selecting the Preview button; there’s no need to make a commit unless you want to save your test file. Just select the Edit button to go back to editing so you can enter more Markdown text.
\n\n\n\nNow that you know how to try it out, let’s get started with the syntax. First up are headers. These are your title and section names. You create them by adding pound signs (#), also known as hashtags, in front of your text. One pound sign indicates a header, two will create a subheader, and so on.
# GitHub for Beginners \n\n \n\n## Basic Markdown syntax \n\n \n\n### Headers If you want to emphasize your text, you can use bold and italic fonts. You create these by using either asterisks (*) or underscores (_). Either of these symbols work in the same way, you just have to make sure to pair them up appropriately. A single character makes text italic, a double character makes text bold, and a triple character makes it both bold and italic. You can emphasize characters within a string or multiple strings within a line of text.
Here is some *italic text* \n\nHere is some **bold text** \n\n___Here is both bold and italic text \n\nOver multiple lines___Sometimes you may want to quote important text. To do this, add the greater than (>) symbol as the first character in a line of text. If you would like to quote something that spans multiple lines, you need to add the greater than symbol at the start of each individual line.
> No design skills required. \n\n> \n\n> No overthinking allowed. \n> \n\n> Just ship your work.Now let’s get into something a little more involved: lists.
\n\n\n\nLists are a common way to express your steps and procedures in an ordered and unordered manner. To create an ordered list, number each element in the list (i.e. 1., 2., 3., etc.).
While this can be clear to read, what if you want to add an element between two consecutive numbers? The good news is that you don’t need to renumber the entire list. Markdown interpreters allow you to order your items with any number, and they automatically interpret it as an ordered list from first to last.
\n\n\n1. Click the \"Use this template” button at the top of this repo. \n\n1. Name your new repository (e.g., my-portfolio). \n\n1. Clone your new repo and start customizing!For an unordered list, start a line with either a hyphen (-), asterisk (*), or a plus sign (+). Markdown will render any of these characters as the start of an unordered list.
* Click the \"Use this template” button at the top of this repo. \n\n* Name your new repository (e.g., my-portfolio). \n\n* Clone your new repo and start customizing!If you would like to create nested lists, indent four spaces to start a new indented list. You can do this with both ordered and unordered list items.
\n\n\n1. Click the \"Use this template” button. \n\n - Located at the top of the repo. \n\n - This will create a new repository using this template. \n\n1. Name your new repository. \n\n - e.g., my-portfolio \n\n - This can be created under your personal GitHub account. \n\n1. Clone your new repo and start customizing!When you’re done with your list, hit Enter twice to go back to plain text.
\n\n\n\n\n\n\n\nSometimes you may want to display a snippet of code in your Markdown as an example. This could be for steps in a procedure or as part of your project’s installation process. Many Markdown interpreters render code snippets with formatting and syntax highlighting. You can denote code in Markdown by surrounding it with a backtick (`) character.
`git clone https://github.com/YOUR_USERNAME/YOUR_REPO_NAME.git` If you have code that spans multiple lines, you can use three backtick characters to create a code block. Any characters between these triple backticks, including spaces and new lines, will render as code.
\n\n\n```bash \n\n# Clone the repository \n\ngit clone https://github.com/YOUR_USERNAME/YOUR_REPO_NAME.git \n\ncd YOUR_REPO_NAME \n\n \n\n# Install dependencies \n\nnpm install \n\n \n\n# Start the development server \n\nnpm run dev \n\n``` Now let’s learn how to spice up our Markdown files. We’ll start with links. Links allow you to point people to helpful resources, documentation, or other pages in your project. They’re written using brackets ([]) and parentheses (()). Place the text you want to display in the brackets, followed immediately by the URL in parentheses, with no space between the two. This keeps your writing clean and easy to follow.
Open [your local host](http://localhost:3000) to see your portfolio. Images work in almost the same way, but with one small difference: you need to add an exclamation point (!) at the beginning. This is perfect for adding screenshots, diagrams, or even a project logo to your README.
 To make things even easier, on GitHub, you can just drag-and-drop an image into an issue or pull request, and it automatically generates the right Markdown for you.
\n\n\n\nWhether you’re linking out to a tutorial or showing off a screenshot, links and images help you add that extra bit of personality and clarity to your Markdown.
\n\n\n\nYou now know the basics of Markdown, including what it is, why it matters, where you can use it, and how to start writing it with confidence. With just a few techniques, you can create clean, readable documentation that makes your GitHub projects stand out.
\n\n\n\nWhether you’re building a README, opening an issue, or writing project notes, Markdown is going to be one of the tools you use the most.
\n\n\n\nIf you want to learn more about Markdown, here are some good places to get started:
\n\n\n\nHappy coding!
\n\nThe post GitHub for Beginners: Getting started with Markdown appeared first on The GitHub Blog.
\n"},{"json_class":"Feedjira::Parser::AtomEntry","@author":"Alexis Wales","@title_type":"html","@raw_title":"Securing the git push pipeline: Responding to a critical remote code execution vulnerability","@url":"https://github.blog/security/securing-the-git-push-pipeline-responding-to-a-critical-remote-code-execution-vulnerability/","@links":["https://github.blog/security/securing-the-git-push-pipeline-responding-to-a-critical-remote-code-execution-vulnerability/"],"@entry_id":"https://github.blog/?p=95594","@updated":{"json_class":"Time","s":1777474756,"n":0},"@published":{"json_class":"Time","s":1777390200,"n":0},"@categories":["Security","CVE","GHES"],"@summary":"How we validated, fixed, and investigated a critical vulnerability in under two hours, and confirmed no exploitation.
\nThe post Securing the git push pipeline: Responding to a critical remote code execution vulnerability appeared first on The GitHub Blog.
\n","@content":"\nOn March 4, 2026, we received a vulnerability report through our Bug Bounty program from researchers at Wiz describing a critical remote code execution vulnerability affecting github.com, GitHub Enterprise Cloud, GitHub Enterprise Cloud with Data Residency, GitHub Enterprise Cloud with Enterprise Managed Users, and GitHub Enterprise Server.
\n\n\n\nIn less than two hours we had validated the finding, deployed a fix to github.com, and begun a forensic investigation that concluded there was no exploitation.
\n\n\n\nIn this post, we want to share what happened, how we responded, and what we are doing to prevent similar issues in the future.
\n\n\n\nThe bug bounty report described a way for any user with push access to a repository, including a repository they created themselves, to achieve arbitrary command execution on the GitHub server handling their git push operation. The attack required only a single command: git push with a crafted push option that leveraged an unsanitized character.
Our security team immediately began validating the bug bounty report. Within 40 minutes, we had reproduced the vulnerability internally and confirmed the severity. This was a critical issue that required immediate action.
\n\n\n\nWhen a user pushes code to GitHub, the operation passes through multiple internal services. As part of this process, metadata about the push, such as the repository type and the environment it should be processed in, is passed between services using an internal protocol.
\n\n\n\nThe vulnerability leveraged how user-supplied git push options were handled within this metadata. Push options are an intentional feature of git that allow clients to send key-value strings to the server during a push. However, the values provided by the user were incorporated into the internal metadata without sufficient sanitization. Because the internal metadata format used a delimiter character that could also appear in user input, an attacker could inject additional fields that the downstream service would interpret as trusted internal values.
\n\n\n\nBy chaining several injected values together, the researchers demonstrated that an attacker could override the environment the push was processed in, bypass sandboxing protections that normally constrain hook execution, and ultimately execute arbitrary commands on the server.
\n\n\n\nWith the root cause identified on March, 4, 2026, at 5:45 p.m. UTC, our engineering team developed and deployed a fix to github.com at 7:00 p.m. UTC that same day. The fix ensures that user-supplied push option values are properly sanitized and can no longer influence internal metadata fields.
\n\n\n\nFor GitHub Enterprise Server, we prepared patches across all supported releases (3.14.25, 3.15.20, 3.16.16, 3.17.13, 3.18.7, 3.19.4, 3.20.0, or later) and published CVE-2026-3854. These are available today and we strongly recommend that all GHES customers upgrade immediately.
\n\n\n\nWith the immediate fix in place on github.com, we moved to the pressing question of whether anyone else found and exploited this vulnerability before the researchers reported it.
\n\n\n\nA key property of this vulnerability gave us confidence in our ability to answer that question. The exploit forces the server to take a code path that is never used during normal operations on github.com. This is not something an attacker can avoid or suppress, as it is an inherent consequence of how the injection works.
\n\n\n\nWe logged this path and queried our telemetry for any instance of this anomalous code path being executed. The results were clear:
\n\n\n\nFor GHES customers, exploitation would require an authenticated user with push access on your instance. We recommend reviewing your access logs out of an abundance of caution.
\n\n\n\nBeyond fixing the immediate input sanitization issue, our investigation surfaced an additional finding worth sharing.
\n\n\n\nThe exploit worked in part because the server had access to a code path that was not intended for the environment it was running in. This code path existed on disk as part of the server’s container image, even though it was only meant to be used in a different product configuration. An older deployment method had correctly excluded this code, but when the deployment model changed, the exclusion was not carried forward.
\n\n\n\nThis is a useful reminder that defense in depth matters. The input sanitization fix is the primary remediation, but we have also removed the unnecessary code path from environments where it should not exist. Even if a similar injection vulnerability were discovered in the future, this additional hardening would limit what an attacker could do with it.
\n\n\n\nGitHub Enterprise Cloud, GitHub Enterprise Cloud with Enterprise Managed Users, GitHub Enterprise Cloud with Data Residency, and github.com were patched on March 4, 2026. No action is required from users of any of these.
\n\n\n\nAs mentioned previously, exploitation on GitHub Enterprise Server requires an authenticated user with push access on your instance. We recommend that you review /var/log/github-audit.log for push operations containing ; in push options. Updates are available in the following releases:
We strongly recommend upgrading to the latest patch release as soon as possible. See the GHES release notes for details.
\n\n\n\nThis vulnerability has been assigned CVE-2026-3854.
\n\n\n\nThis vulnerability was discovered and responsibly disclosed by researchers at Wiz. Their report was thorough, clearly demonstrated the impact, and enabled us to move quickly from validation to remediation. This finding will receive one of the highest rewards in the history of our Bug Bounty program, which has been a cornerstone of our security program for over a decade.
\n\nThe post Securing the git push pipeline: Responding to a critical remote code execution vulnerability appeared first on The GitHub Blog.
\n"},{"json_class":"Feedjira::Parser::AtomEntry","@author":"Vlad Fedorov","@title_type":"html","@raw_title":"An update on GitHub availability","@url":"https://github.blog/news-insights/company-news/an-update-on-github-availability/","@links":["https://github.blog/news-insights/company-news/an-update-on-github-availability/"],"@entry_id":"https://github.blog/?p=95627","@updated":{"json_class":"Time","s":1777391404,"n":0},"@published":{"json_class":"Time","s":1777370497,"n":0},"@categories":["Company news","News & insights"],"@summary":"Here’s what we’ve done—and what we’re still doing—to improve our availability and reliability.
\nThe post An update on GitHub availability appeared first on The GitHub Blog.
\n","@content":"\nI wanted to give an update on GitHub’s availability in light of two recent incidents. Both of those incidents are not acceptable, and we are sorry for the impact they had on you. I wanted to share some details on them, as well as explain what we’ve done and what we’re doing to improve our reliability.
\n\n\n\nWe started executing our plan to increase GitHub’s capacity by 10X in October 2025 with a goal of substantially improving reliability and failover. By February 2026, it was clear that we needed to design for a future that requires 30X today’s scale.
\n\n\n\nThe main driver is a rapid change in how software is being built. Since the second half of December 2025, agentic development workflows have accelerated sharply. By nearly every measure, the direction is already clear: repository creation, pull request activity, API usage, automation, and large-repository workloads are all growing quickly.
\n\n\n\nThis exponential growth does not stress one system at a time. A pull request can touch Git storage, mergeability checks, branch protection, GitHub Actions, search, notifications, permissions, webhooks, APIs, background jobs, caches, and databases. At high scale, small inefficiencies compound: queues deepen, cache misses become database load, indexes fall behind, retries amplify traffic, and one slow dependency can affect several product experiences.
\n\n\n\nOur priorities are clear: availability first, then capacity, then new features. We are reducing unnecessary work, improving caching, isolating critical services, removing single points of failure, and moving performance-sensitive paths into systems designed for these workloads. This is distributed systems work: reducing hidden coupling, limiting blast radius, and making GitHub degrade gracefully when one subsystem is under pressure. We’re making progress quickly, but these incidents are examples of where there’s still work to do.
\n\n\n\nShort term, we had to resolve a variety of bottlenecks that appeared faster than expected from moving webhooks to a different backend (out of MySQL), redesigning user session cache to redoing authentication and authorization flows to substantially reduce database load. We also leveraged our migration to Azure to stand up a lot more compute.
\n\n\n\nNext we focused on isolating critical services like git and GitHub Actions from other workloads and minimizing the blast radius by minimizing single points of failure. This work started with careful analysis of dependencies and different tiers of traffic to understand what needs to be pulled apart and how we can minimize impact on legitimate traffic from various attacks. Then we addressed those in order of risk. Similarly, we accelerated parts of migrating performance or scale sensitive code out of Ruby monolith into Go.
\n\n\n\nWhile we were already in progress of migrating out of our smaller custom data centers into public cloud, we started working on path to multi cloud. This longer-term measure is necessary to achieve the level of resilience, low latency, and flexibility that will be needed in the future.
\n\n\n\nThe number of repositories on GitHub is growing faster than ever, but a much harder scaling challenge is the rise of large monorepos. For the last three months, we’ve been investing heavily in response to this trend both within git system and in the pull request experience.
\n\n\n\nWe will have a separate blog post soon describing extensive work we’ve done and the new upcoming API design for greater efficiency and scale. As part of this work, we have invested in optimizing merge queue operations, since that is key for repos that have many thousands of pull requests a day.
\n\n\n\nThe two recent incidents were different in cause and impact, but both reflect why we are increasing our focus on availability, isolation, and blast-radius reduction.
\n\n\n\nOn April 23, pull requests experienced a regression affecting merge queue operations.
\n\n\n\nPull requests merged through merge queue using the squash merge method produced incorrect merge commits when a merge group contained more than one pull request. In affected cases, changes from previously merged pull requests and prior commits were inadvertently reverted by subsequent merges.
\n\n\n\nDuring the impact window, 658 repositories and 2,092 pull requests were affected. We initially shared slightly higher numbers because our first assessment was intentionally conservative. The issue did not affect pull requests merged outside merge queue, nor did it affect merge queue groups using merge or rebase methods.
\n\n\n\nThere was no data loss: all commits remained stored in Git. However, the state of affected default branches was incorrect, and we could not safely repair every repository automatically. More details are available in the incident root cause analysis.
\n\n\n\nThis incident exposed multiple process failures, and we are changing those processes to prevent this class of issue from recurring.
\n\n\n\nOn April 27, an incident affected our Elasticsearch subsystem, which powers several search-backed experiences across GitHub, including parts of pull requests, issues, and projects.
\n\n\n\nWe are still completing the root cause analysis and will publish it shortly. What we know now is that the cluster became overloaded (likely due to a botnet attack) and stopped returning search results. There was no data loss, and Git operations and APIs were not impacted. However, parts of the UI that depended on search showed no results, which caused a significant disruption.
\n\n\n\nThis is one of the systems we had not yet fully isolated to eliminate as a single point of failure, because other areas had been higher in our risk-prioritized reliability work. That impact is unacceptable, and we are using the same dependency and blast-radius analysis described above to reduce the likelihood and impact of this type of failure in the future.
\n\n\n\nWe have also heard clear feedback that customers need greater transparency during incidents.
\n\n\n\nWe recently updated the GitHub status page to include availability numbers. We have also committed to statusing incidents both large and small, so you do not have to guess whether an issue is on your side or ours.
\n\n\n\nWe are continuing to improve how we categorize incidents so that the scale and scope are easier to understand. We are also working on better ways for customers to report incidents and share signals with us during disruptions.
\n\n\n\nGitHub’s role has always been to support developers on an open and extensible platform.
\n\n\n\nThe team at GitHub is incredibly passionate about our work. We hear the pain you’re experiencing. We read every email, social post, support ticket, and we take it all to heart. We’re sorry.
\n\n\n\nWe are committed to improving availability, increasing resilience, scaling for the future of software development, and communicating more transparently along the way.
\n\n\n\nEditor’s note: This post was updated on April 28, 2026, to update the number of repos affected during the April 23 incident.
\n\nThe post An update on GitHub availability appeared first on The GitHub Blog.
\n"},{"json_class":"Feedjira::Parser::AtomEntry","@author":"Mario Rodriguez","@title_type":"html","@raw_title":"GitHub Copilot is moving to usage-based billing","@url":"https://github.blog/news-insights/company-news/github-copilot-is-moving-to-usage-based-billing/","@links":["https://github.blog/news-insights/company-news/github-copilot-is-moving-to-usage-based-billing/"],"@entry_id":"https://github.blog/?p=95572","@updated":{"json_class":"Time","s":1777325983,"n":0},"@published":{"json_class":"Time","s":1777305502,"n":0},"@categories":["Company news","News & insights"],"@summary":"Starting June 1, your Copilot usage will consume GitHub AI Credits.
\nThe post GitHub Copilot is moving to usage-based billing appeared first on The GitHub Blog.
\n","@content":"\nTL;DR: Today, we are announcing that all GitHub Copilot plans will transition to usage-based billing on June 1, 2026.
\n\n\n\nInstead of counting premium requests, every Copilot plan will include a monthly allotment of GitHub AI Credits, with the option for paid plans to purchase additional usage. Usage will be calculated based on token consumption, including input, output, and cached tokens, using the listed API rates for each model.
\n\n\n\nThis change aligns Copilot pricing with actual usage and is an important step toward a sustainable, reliable Copilot business and experience for all users.
\n\n\n\nTo help customers prepare, we are also launching a preview bill experience in early May, giving users and admins visibility into projected costs before the June 1 transition. This will be available to users via their Billing Overview page when they log in to github.com.
\n\n\n\nCopilot is not the same product it was a year ago.
\n\n\n\nIt has evolved from an in-editor assistant into an agentic platform capable of running long, multi-step coding sessions, using the latest models, and iterating across entire repositories. Agentic usage is becoming the default, and it brings significantly higher compute and inference demands.
\n\n\n\nToday, a quick chat question and a multi-hour autonomous coding session can cost the user the same amount. GitHub has absorbed much of the escalating inference cost behind that usage, but the current premium request model is no longer sustainable.
\n\n\n\nUsage-based billing fixes that. It better aligns pricing with actual usage, helps us maintain long-term service reliability, and reduces the need to gate heavy users.
\n\n\n\nStarting June 1, premium request units (PRUs) will be replaced by GitHub AI Credits.
\n\n\n\nCredits will be consumed based on token usage, including input, output, and cached tokens, according to the published API rates for each model.
\n\n\n\nA few important details:
\n\n\n\nLast week, we also rolled out temporary changes to Copilot Individual plans, including Free, Pro, Pro+, and Student, and paused self-serve Copilot Business plan purchases. These were reliability and performance measures as we prepare for the broader transition to usage-based billing. We will loosen usage limits once usage-based billing is in effect.
\n\n\n\nCopilot Pro and Pro+ monthly subscriptions will include monthly AI Credits aligned to their current subscription prices:
\n\n\n\nUsers on a monthly Pro or Pro+ plan will automatically migrate to usage-based billing on June 1, 2026.
Users on annual Pro or Pro+ plans will remain on their existing plan with premium request-based pricing until their plan expires. Model multipliers will increase on June 1 (see table) for annual plan subscribers only. At expiration, they will transition to Copilot Free with the option to upgrade to a paid monthly plan. Alternatively, they may convert to a monthly paid plan before their annual plan expires, and we will provide prorated credits for the remaining value of their annual plan.
Copilot Business and Copilot Enterprise monthly seat pricing remains unchanged:
\n\n\n\nTo support the transition, existing Copilot Business and Copilot Enterprise customers will automatically receive promotional included usage for June, July, and August:
\n\n\n\nWe are also introducing pooled included usage across a business, which helps eliminate stranded capacity. Instead of each user’s unused included usage being isolated, credits can be pooled across the organization.
\n\n\n\nAdmins will also have new budget controls. They will be able to set budgets at the enterprise, cost center, and user levels. When the included pool is exhausted, organizations can choose whether to allow additional usage at published rates or cap spend.
\n\n\n\nPlan prices aren’t changing. You’ll have full control over what you spend, tools to track your usage, and the option to purchase more AI Credits if and when you need them.
\n\n\n\nIf you have questions, visit our documentation for individuals and for businesses and enterprises, and our FAQ and related discussion.
\n\nThe post GitHub Copilot is moving to usage-based billing appeared first on The GitHub Blog.
\n"},{"json_class":"Feedjira::Parser::AtomEntry","@author":"Joe Binder","@title_type":"html","@raw_title":"Changes to GitHub Copilot Individual plans","@url":"https://github.blog/news-insights/company-news/changes-to-github-copilot-individual-plans/","@links":["https://github.blog/news-insights/company-news/changes-to-github-copilot-individual-plans/"],"@entry_id":"https://github.blog/?p=95440","@updated":{"json_class":"Time","s":1777497938,"n":0},"@published":{"json_class":"Time","s":1776708928,"n":0},"@categories":["Company news","News & insights"],"@summary":"We're making these changes to ensure a reliable and predictable experience for existing customers.
\nThe post Changes to GitHub Copilot Individual plans appeared first on The GitHub Blog.
\n","@content":"\nToday we’re making the following changes to GitHub Copilot’s Individual plans to protect the experience for existing customers: pausing new sign-ups, tightening usage limits, and adjusting model availability. We know these changes are disruptive, and we want to be clear about why we’re making them and how they will affect you.
\n\n\n\nAgentic workflows have fundamentally changed Copilot’s compute demands. Long-running, parallelized sessions now regularly consume far more resources than the original plan structure was built to support. As Copilot’s agentic capabilities have expanded rapidly, agents are doing more work, and more customers are hitting usage limits designed to maintain service reliability. Without further action, service quality degrades for everyone.
\n\n\n\nWe’ve heard your frustrations about usage limits and model availability, and we need to do a better job communicating the guardrails we are adding—here’s what’s changing and why.
\n\n\n\nThese changes are necessary to ensure we can serve existing customers with a predictable experience. If you hit unexpected limits or these changes just don’t work for you, you can cancel your Pro or Pro+ subscription and receive a refund for the time remaining on your current subscription by visiting your Billing settings before May 20.
\n\n\n\nGitHub Copilot has two usage limits today: session and weekly (7 day) limits. Both limits depend on two distinct factors—token consumption and the model’s multiplier.
\n\n\n\nThe session limits exist primarily to ensure that the service is not overloaded during periods of peak usage. They’re set so most users shouldn’t be impacted. Over time, these limits will be adjusted to balance reliability and demand. If you do encounter a session limit, you must wait until the usage window resets to resume using Copilot.
\n\n\n\nWeekly limits represent a cap on the total number of tokens a user can consume during the week. We introduced weekly limits recently to control for parallelized, long-trajectory requests that often run for extended periods of time and result in prohibitively high costs.
\n\n\n\nThe weekly limits for each plan are also set so that most users will not be impacted. If you hit a weekly limit and have premium requests remaining, you can continue to use Copilot with Auto model selection. Model choice will be reenabled when the weekly period resets. If you are a Pro user, you can upgrade to Pro+ to increase your weekly limits. Pro+ includes over 5X the limits of Pro.
\n\n\n\nUsage limits are separate from your premium request entitlements. Premium requests determine which models you can access and how many requests you can make. Usage limits, by contrast, are token-based guardrails that cap how many tokens you can consume within a given time window. You can have premium requests remaining and still hit a usage limit.
\n\n\n\nStarting today, VS Code and Copilot CLI both display your available usage when you’re approaching a limit. These changes are meant to help you avoid a surprise limit.
\n\n\n\n![\"Screenshot](\"https://github.blog/wp-content/uploads/2026/04/Screenshot-2026-04-20-at-2.05.12-PM.png?resize=1024%2C898\")
![\"A](\"https://github.blog/wp-content/uploads/2026/04/image-20.png?resize=1024%2C662\")
If you are approaching a limit, there are a few things you can do to help reduce the chances of hitting it:
\n\n\n\n/fleet will result in higher token consumption and should be used sparingly if you are nearing your limits.We’ve seen usage intensify for all users as they realize the value of agents and subagents in tackling complex coding problems. These long-running, parallelized workflows can yield great value, but they have also challenged our infrastructure and pricing structure: it’s now common for a handful of requests to incur costs that exceed the plan price! These are our problems to solve. The actions we are taking today enable us to provide the best possible experience for existing users while we develop a more sustainable solution.
\n\n\n\nEditor’s note: Updated April 21, 2026, to clarify the refund policy.
\n\nThe post Changes to GitHub Copilot Individual plans appeared first on The GitHub Blog.
\n"},{"json_class":"Feedjira::Parser::AtomEntry","@author":"Taylor Blau","@title_type":"html","@raw_title":"Highlights from Git 2.54","@url":"https://github.blog/open-source/git/highlights-from-git-2-54/","@links":["https://github.blog/open-source/git/highlights-from-git-2-54/"],"@entry_id":"https://github.blog/?p=95374","@updated":{"json_class":"Time","s":1777327403,"n":0},"@published":{"json_class":"Time","s":1776703437,"n":0},"@categories":["Git","Open Source"],"@summary":"The open source Git project just released Git 2.54. Here is GitHub’s look at some of the most interesting features and changes introduced since last time.
\nThe post Highlights from Git 2.54 appeared first on The GitHub Blog.
\n","@content":"\nThe open-source Git project just released Git 2.54 with features and bug fixes from over 137 contributors, 66 of them new. We last caught up with you on the latest in Git back when 2.52 was released.
\n\n\n\nTo celebrate this most recent release, here is GitHub’s look at some of the most interesting features and changes introduced since last time.
\n\n\n\n\n\n\n\n💡 Since the last Git release we wrote about was Git 2.52, this blog post covers the highlights from both the 2.53 and 2.54 releases.
git historyThe Git project has a long history of providing tools to rewrite your repository’s history. git rebase –i is the most well-known, and it’s remarkably flexible: you can reorder, squash, edit, and drop commits. But that flexibility comes with complexity: an interactive rebase operates on a range of commits, updates your working tree and index as it goes, and can leave you in a conflicted state that you need to resolve before proceeding.
For simpler cases, all of that machinery can feel like overkill. If all you want to do is fix a typo in a commit message three commits back, or split one commit into two, an interactive rebase works, but requires you to set up a to-do list, mark the right commit for editing, and then drive the rebase to completion.
\n\n\n\nGit 2.54 introduces a new experimental command that is designed for exactly these simpler cases: git history. The history command currently supports two operations: reword and split.
git history reword <commit> opens your editor with the specified commit’s message and rewrites it in place, updating any branches that descend from that commit. Unlike git rebase, it doesn’t touch your working tree or index, and it can even operate in a bare repository.
git history split <commit> lets you interactively split a commit into two by selecting which hunks should be carved out into a new parent commit. The interface will look familiar if you’ve ever used add in interactive mode via git add –p:
$ git history split HEAD\ndiff --git a/bar b/bar\nnew file mode 100644\nindex 0000000..50810a5\n--- /dev/null\n+++ b/bar\n@@ -0,0 +1 @@\n+bar\n(1/1) Stage addition [y,n,q,a,d,p,?]? y After selecting hunks, Git creates a new commit with those changes as the parent of the original commit (which retains whatever hunks you didn’t select) and rewrites any descendent branches to point at the updated history.
\n\n\n\nThere are a couple of intentional limitations worth noting. The history command does not support histories that contain merge commits, and it will refuse to perform any operation that would result in a merge conflict. By design, git history is meant for targeted, non-interactive rewrites, not the kind of open-ended history rewriting typically relegated to git rebase –i.
The history command is built on top of git replay‘s core machinery, which was itself extracted into a library as part of this work. That foundation means that git history benefits from replay‘s ability to operate without touching the working tree, making it a natural fit for scripting and automation in addition to interactive use.
This command is still marked as experimental, so its interface may evolve. Give it a try with git history reword and git history split, available in Git 2.54.
[source, source, source, source, source]
\n\n\n\nIf you’ve ever wanted to share a Git hook across multiple repositories, you’ve probably had to reach for a third-party hook manager, or manually symlink scripts into each repository’s $GIT_DIR/hooks directory. That’s because, historically, Git hooks could only be defined as executable scripts living in one place: the hooks subdirectory of your .git directory (or whatever core.hooksPath points to).
That meant that if you wanted to run a linter before every commit across all of your repositories, you had to copy the script into each repository, which can be tedious and error-prone. Alternatively, you could set core.hooksPath to point to a shared directory, but that causes all of your repositories to share the exact same set of hooks, with no way to mix and match.
Git 2.54 introduces a new way to define hooks: in your configuration files. Instead of placing a script at .git/hooks/pre-commit, you can now write:
[hook \"linter\"]\n event = pre-commit\n command = ~/bin/linter --cpp20 The hook.<name>.command key specifies the command to run, and hook.<name>.event specifies which hook event should trigger it. Since this is just configuration, it can live in your per-user ~/.gitconfig, a system-wide /etc/gitconfig, or in a repository’s local config. That makes it straightforward to define a set of hooks centrally and have them apply everywhere.
Even better, you can now run multiple hooks for the same event. If you want both a linter and a secrets scanner to run before every commit, you can configure them independently:
\n\n\n[hook \"linter\"]\n event = pre-commit\n command = ~/bin/linter --cpp20\n\n[hook \"no-leaks\"]\n event = pre-commit\n command = ~/bin/leak-detectorGit will run them in the order it encounters their configuration. The traditional hook script in $GIT_DIR/hooks still works, and runs last, so existing hooks are unaffected. You can see which hooks are configured (and where they come from) with git hook list:
$ git hook list pre-commit\nglobal linter ~/bin/linter --cpp20\nlocal no-leaks ~/bin/leak-detector Individual hooks can be disabled without removing their configuration by setting hook.<name>.enabled = false, which is particularly handy when a hook is defined in a system-level config but you need to opt a specific repository out.
Along the way, Git’s internal handling of hooks has been modernized. Many built-in hooks that were previously invoked through ad-hoc code paths (like pre-push, post-rewrite, and the various receive-pack hooks) have been migrated to use the new hook API, meaning they all benefit from the new configuration-based hook machinery.
Returning readers of this series may recall our coverage of the new geometric strategy within git maintenance, which was introduced in Git 2.52. That strategy works by inspecting the contents of your repository to determine if some number of packfiles can be combined to form a geometric progression by object count. If they can, Git performs a geometric repack, condensing the contents of your repository without needing to perform a full garbage collection.
In 2.52, the geometric strategy was available as an opt-in choice via the maintenance.strategy configuration. In 2.54, it becomes the default strategy for manual maintenance. That means when you run git maintenance run without specifying a strategy, Git will now use the geometric approach instead of the traditional gc task.
In practice, this means that your repositories will be maintained more efficiently out of the box. The geometric strategy avoids the expensive all-into-one repacks that gc performs, instead combining packs incrementally when possible and falling back to a full gc only when it would consolidate the entire repository into a single pack. Along the way, it keeps your commit-graph, reflogs, and other auxiliary data structures up to date.
If you were already using maintenance.strategy = geometric in your configuration, nothing changes. If you hadn’t set a strategy (or were relying on the old gc default), you’ll start seeing the benefits of geometric repacking automatically. The gc strategy is still available if you prefer it and can be selected with maintenance.strategy = gc.
[source]
\n\n\n\nNow that we’ve covered some of the larger changes in more detail, let’s take a closer look at a selection of some other new features and updates in this release.
\n\n\n\nThe git add –p command, Git’s tool for interactively staging individual hunks, received a handful of usability improvements in this release. When navigating between hunks with the J and K keys, Git now shows whether you’ve previously accepted or skipped each hunk, so you don’t have to remember your earlier decisions.
Separately, a new --no-auto-advance flag changes how git add –p handles the transition between files. Normally, once you’ve made a decision on every hunk in a file, the session automatically moves on to the next one. With --no-auto-advance, the session stays put after you’ve decided on the last hunk, letting you use < and > to move between files at your own pace. This can be useful when you want to review your decisions holistically before committing to them.
git replay, the experimental command for replaying commits onto a new base without touching the working tree, continues to mature. This release brings several improvements: replay now performs atomic reference updates by default (instead of printing update-ref commands to stdout), has learned a new --revert mode that reverses the changes from a range of commits, can now drop commits that become empty during replay, and supports replaying all the way down to the root commit.
Git’s HTTP transport now handles HTTP 429 “Too Many Requests” responses. Previously, a 429 from the server would be treated as a fatal error. Git can now retry the request, honoring the server’s Retry-After header when present, or fall back to a configurable delay via the new http.retryAfter setting. The new http.maxRetries and http.maxRetryTime configuration options provide control over how many times to retry and how long to wait, respectively.
[source]
git log –L, which traces the history of a range of lines within a file, has historically used its own custom output path that bypassed much of Git’s standard diff machinery. As a result, it was incompatible with several useful options, including the -S and -G “pickaxe” options for searching by content changes.
This release reworks git log –L to route its output through the standard diff pipeline, making it compatible with patch formatting options and pickaxe searches for the first time.
Say you want to trace the history of strbuf_addstr() in strbuf.c, but only see commits where len was added or removed within that function:
$ git log -L :strbuf_addstr:strbuf.c -S len --oneline -1\na70f8f19ad2 strbuf: introduce strbuf_addstrings() to repeatedly add a string\n\ndiff --git a/strbuf.c b/strbuf.c\n--- a/strbuf.c\n+++ b/strbuf.c\n@@ -316,0 +316,9 @@\n+void strbuf_addstrings(struct strbuf *sb, const char *s, size_t n)\n+{\n+ size_t len = strlen(s);\n+\n+ strbuf_grow(sb, st_mult(len, n));\n+ for (size_t i = 0; i < n; i++)\n+ strbuf_add(sb, s, len);\n+}Prior to this release, options like -S, (and -G, --word-diff, along with --color-moved) were silently ignored when used with -L. Now they work together naturally: -L scopes the output to the function you care about, and -S filters down to just the commits that touched the symbol you’re searching for within it.
[source]
Incremental multi-pack indexes, which we first covered in our discussion of Git 2.47 and followed up on in Git 2.50, received further work in this release. The MIDX machinery now supports compaction, which merges smaller MIDX layers together (along with their associated reachability bitmaps) to keep the number of layers in the chain manageable. This is an important step toward making incremental MIDXs practical for long-lived repositories that accumulate many layers over time.
[source]
git status learned a new status.compareBranches configuration option. By default, git status shows how your current branch compares to its configured upstream (e.g., “Your branch is ahead of ‘origin/main’ by 3 commits”). With status.compareBranches, you can ask it to also compare against your push remote, or both:
[status]\n compareBranches = @{upstream} @{push}This is useful if your push destination differs from your upstream, as is common in triangular workflows where you fetch from one remote and push to another (like a fork).
[source]
Say you have a series of commits, and want to add a trailer to each one of them. You could do this manually, or automate it with something like: git rebase -x ‘git commit --amend --no-edit --trailer=”Reviewed-by: A U Thor <a href=\"mailto:<author@example.com>”’, but that’s kind of a mouthful.
In Git 2.54, git rebase learned a new --trailer option, which appends a trailer to every rebased commit via the interpret-trailers machinery. Instead of the monstrosity above, we can now write git rebase --trailer \"Reviewed-by: A <a href=\"mailto:<a@example.com>\" and achieve the same effect.
[source]
When signing commits, a signature remains valid even when it was signed with a GPG key that has since expired. Previously, Git displayed these signatures with a scary red color, which could be misleading and lead you to interpret the signature itself as invalid. Git now correctly treats a valid signature made with a since-expired key as a good signature.
[source]
git blame learned a new --diff-algorithm option, allowing you to select which diff algorithm (e.g., histogram, patience, or minimal) is used when computing blame. This can sometimes produce meaningfully different (and more useful) blame output, depending on the nature of the changes in your repository’s history.
[source]
Under the hood, a significant amount of work went into restructuring Git’s object database (ODB) internals. The ODB source API has been refactored to use a pluggable backend design, with individual functions like read_object(), write_object(), and for_each_object() now dispatched through function pointers on a per-source basis. While none of this is user-visible today, it lays the groundwork for future features like alternative storage backends or more flexible object database configurations.
git backfill, the experimental command for downloading missing blobs in a partial clone, learned to accept revision and pathspec arguments. Previously, backfill would always download blobs reachable from HEAD across the entire tree. You can now scope it to a particular range of history (e.g., git backfill main~100..main) or a subset of paths (e.g., git backfill -- '*.c'), including pathspecs with wildcards.
This makes backfill much more practical for large partial clones where you only need historical blobs for a specific area of the repository.
[source]
Git’s alias configuration has historically been limited to ASCII alphanumeric characters and hyphens. That meant alias names like “hämta” (Swedish for “fetch”) or “状態” (Japanese for “status”) were off-limits. Git 2.54 lifts that restriction with a new subsection-based syntax:
[alias \"hämta\"]\n command = fetch\nThe traditional [alias] co = checkout syntax continues to work for ASCII names. The new subsection form supports any characters (except newlines and NUL bytes), is matched case-sensitively as raw bytes, and uses a command key for the alias definition. Shell completion has been updated to handle these aliases as well.
The histogram diff algorithm received a fix for a subtle output quality issue. After any diff algorithm runs, Git performs a “compaction” phase that shifts and merges change groups to produce cleaner output. In some cases, this shifting could move a change group across the anchor lines that the histogram algorithm had chosen, producing a diff that was technically correct but visually redundant. Git now detects when this happens and re-diffs the affected region, resulting in tighter output that better matches what you would expect.
[source]
That’s just a sample of changes from the latest release. For more, check out the release notes for 2.53 and 2.54, or any previous version in the Git repository.
\n\nThe post Highlights from Git 2.54 appeared first on The GitHub Blog.
\n"},{"json_class":"Feedjira::Parser::AtomEntry","@author":"Cassidy Williams","@title_type":"html","@raw_title":"Building an emoji list generator with the GitHub Copilot CLI","@url":"https://github.blog/ai-and-ml/github-copilot/building-an-emoji-list-generator-with-the-github-copilot-cli/","@links":["https://github.blog/ai-and-ml/github-copilot/building-an-emoji-list-generator-with-the-github-copilot-cli/"],"@entry_id":"https://github.blog/?p=95403","@updated":{"json_class":"Time","s":1776446831,"n":0},"@published":{"json_class":"Time","s":1776448800,"n":0},"@categories":["AI & ML","GitHub Copilot","GitHub Copilot CLI"],"@summary":"See how we created an emoji list generator during the Rubber Duck Thursday stream.
\nThe post Building an emoji list generator with the GitHub Copilot CLI appeared first on The GitHub Blog.
\n","@content":"\nEvery week, the GitHub team runs a stream called Rubber Duck Thursdays, where we build projects live, cowork with our community, and answer questions!
\n\n\n\nThis week, we built a very fun project together using the GitHub Copilot CLI! Let me tell you about it.
\n\n\n\n💡 New to GitHub Copilot CLI? Here’s how to get started.
\n\n\n\nIn a lot of social media tweets and launches, you often see accounts post things like:
\n\n\nWe shipped the most amazing emoji list generator ever. It:\n\n💻 Works in the CLI\n🤖 Uses the Copilot SDK to intelligently convert your bullet points to relevent emoji\n📋 Copies the result to the clipboardIt’s beautiful. But coming up with the perfect emoji is far too slow for me in this “move fast and break things” world. I have projects to build! Repos to vibe! Pull requests to merge! I can’t be thinking about emojis!
\n\n\n\nAnd thus, on the stream, we build an emoji list generator (very descriptively called Emoji List Generator) that:
\n\n\n\n🖥️ Runs in the terminal
📋 You paste or write a list
⌨️ You hit Ctrl + S
📎 You get the list on your clipboard
(Can you tell I’m dogfooding the product here?)
\n\n\n\nWe used a few cool technologies for this project:
\n\n\n\n🖥️ @opentui/corefor the terminal UI
🤖 @github/copilot-sdkfor the AI brain
📋 clipboardyfor clipboard access
To start the project off, we opened up the GitHub Copilot CLI.
\n\n\n\nIn plan mode using Claude Sonnet 4.6, we wrote:
\n\n\nI want to create an AI-powered markdown emoji list generator. Where, in this CLI app, if I paste in or write in some bullet points, it will replace those bullet points with relevant emojis to the given point in that list, and copies it to my clipboard. I'd like it to use GitHub Copilot SDK for the AI juiciness.Copilot asked me a bunch of clarifying questions, for example around the tech stack and what libraries we should use (shoutout to Gabor in the chat for suggesting OpenTUI), and from there, we had a fully thought-out plan.mdfile for me to review and use!
We implemented the plan using Claude Opus 4.7 (which was recently released!) and a few minutes later, voilà, we had a fun little terminal UI to work with!
\n\n\n\n![\"Screenshot](\"https://github.blog/wp-content/uploads/2026/04/list.png?resize=1869%2C1944\")
The project was small but mighty. In the CLI, we used some really cool tools all together:
\n\n\n\n📋 Plan mode
🤖 Autopilot mode
🔀 Multi-model workflow
🚩 The allow-alltools flag
🐙 The GitHub MCP server
If you’d like to build a project like this yourself, you can check out the docs for the GitHub Copilot CLI and the GitHub Copilot SDK today!
\n\n\n\nThe emoji list generator is free and open source, just for you.
\n\n\n\nHappy building!
\n\nThe post Building an emoji list generator with the GitHub Copilot CLI appeared first on The GitHub Blog.
\n"}]}