Dimensional Data

Protected branches have been around for a while, and we’ve made numerous improvements over time. We’ve added new rules to protect multiple branches and introduced additional permissions. However, it’s still challenging to consistently protect branches and tags throughout organizations. Managing scripts, cron jobs, various API calls, or third-party tooling to have consistent branch protections is not only annoying but also time-consuming. You won’t know the rules in place as an engineer until you encounter a pull request. It’s time for a new approach We’re excited to announce the general availability of repository rules. Repository rules enable you to easily define branch protections in your public repositories. With flexible targeting options, you can protect multiple branch patterns using a single ruleset. Layering makes bypass scenarios dynamic; a GitHub App can skip status checks with no additional permissions, and administrators can bypass pull requests while still requiring the important CodeQL checks to run. In line with our mission to be the home for all developers, we have integrated GitHub Repository Rules to ensure that everyone collaborating on a repository knows the rules in play for them. An overview page provides visibility on rules applicable to a branch. Relevant information about rule enforcement is available at multiple touchpoints on GitHub.com, Git, and the GitHub CLI. There are also helpful prompts on ensuring the responsible use of bypass permissions. Twilio has been using GitHub Repository Rules to balance developer experience and security. At Twilio, we value the autonomy of our engineering teams, including the ability to manage their own GitHub repositories. However, this autonomy makes compliance and security more challenging. We have successfully used GitHub Repository Rules to help us meet our compliance and security requirements while maintaining team autonomy. – David Betts, Senior Engineering Manager // Twilio GitHub Enterprise Cloud customers can enforce these rules across all or a subset of their repositories in an organization. No more tedious audits checking to see if a rule existed; now, you can ensure consistency in one location. If you’re not ready to commit to a ruleset, you can trial them in evaluate mode. Rule insights allow you to see what could happen if you dismiss stale reviews or enable linear merge history. No more guessing and no more testing in “production.” Policy enforcement is a big reason Thomson Reuters has been an early adopter of repository rules across their organization. Compliance and security controls are fundamental to keeping applications safe. At Thomson Reuters, it’s important we properly enforce these policies. With repository rules, GitHub gives us the confidence to know we are enforcing our policies across an organization effectively, keeping our applications safe for end customers. – Darren Trzynka. Senior Cloud Architect // Thomson Reuters Regarding consistency, repository rules can deliver that with new metadata rules. Branch names, commit messages, and author email addresses of the commit can be governed to help ensure organizational standards. So, set all those protected tags to use SemVer and commit messages on the Emoji-Log standard. Let’s jump in with a few scenarios where repository rules can help level up your code integrity. We’re just normal repositories. Typical rules for production repositories. Setting up repository rules can help maintain code quality, prevent mistakes, and improve collaboration. There are numerous decisions to make about the security goals of a repository, let […]

First introduced as a technical preview in June 2021, GitHub Copilot quickly emerged as the world’s first at-scale generative AI coding tool when it became generally available in June 2022. Since then, it’s played a critical role in redefining the developer experience and underscoring the impact of developer productivity and satisfaction on business outcomes. In our latest survey, we found that 92% of U.S.-based developers are already using AI coding tools both in and outside of work—which shows that most companies are already using AI, whether they know it or not. As the creators of the world’s most widely adopted generative AI coding tool, we want to empower other organizations to accelerate their innovation, while ensuring they have the transparency they need to understand and feel confident using Github Copilot. That’s why we’re launching the GitHub Copilot Trust Center. We often field questions about how GitHub Copilot protects user privacy and if the code that GitHub Copilot suggests is secure. Those questions, and many others regarding security, privacy, compliance, and intellectual property can be easily found and clearly answered on the GitHub Copilot Trust Center. When developers use GitHub Copilot, they can augment their capabilities and tackle large, complex problems in a way they couldn’t before. By following good coding practices and taking advantage of GitHub Copilot’s built-in safeguards, they can feel confident in the code they’re contributing. As organizations take note of AI’s transformative potential, GitHub aims to share guidance on how best to use these tools—and bring greater transparency to how GitHub Copilot for Business works. What you’ll find on the GitHub Copilot Trust Center AI is here to stay—and it’s already transforming how developers approach their day-to-day work. But just like any disruptive technology throughout history, AI brings important questions around its use and implications. To understand GitHub Copilot’s capabilities and proactively build policies that enable its use, organizations can reference the Copilot Trust Center to responsibly and effectively equip their developers with the AI pair programmer. Here are a few frequently asked questions to get you started: What personal data is used by GitHub Copilot for Business and how? Copilot for Business collects three kinds of personal data: user engagement data, prompts, and suggestions. User engagement data is information about events that are generated when iterating with a code editor. A prompt is a compilation of IDE code and relevant context (IDE comments and code in open files) that the GitHub Copilot extension sends to the AI model to generate suggestions. A suggestion is one or more lines of proposed code and other output returned to the GitHub Copilot extension after a prompt is received and processed by the GitHub Copilot model. Copilot for Business uses the source code in your IDE only to generate a suggestion. It also performs several scans to identify and remove certain information within a prompt. Prompts are only transmitted to the AI model to generate suggestions in real-time and are deleted once the suggestions are generated. Copilot for Business also does not use your code to train the Azure OpenAI model. GitHub Copilot for Individual users, however, can opt in and explicitly provide consent for their code to be used as training data. User engagement data is used to improve the performance of the Copilot Service; specifically, it’s used to […]

The magic of GitHub Copilot just got even better with an improved AI model and enhanced contextual filtering. These improvements give developers more tailored code suggestions that better align with their specific needs, and are available for both GitHub Copilot for Individuals and GitHub Copilot for Business. Read on to learn more about these exciting updates and how they can help you take your coding skills to the next level. Improved AI model goes beyond Codex for even faster suggestions The improved AI model behind GitHub Copilot goes beyond the previous OpenAI Codex model, offering even faster code suggestions to developers. It was developed through a collaboration between OpenAI, Microsoft Azure AI, and GitHub, and offers a 13% latency improvement over the previous model. This means that GitHub Copilot generates code suggestions for developers faster than ever, which promises to drive a substantial increase in overall productivity. Enhanced Contextual Filtering for more tailored code suggestions In addition to the improved AI model, we’ve implemented more sophisticated context filtering that takes into account a wider range of a developer’s context and usage patterns. With the update, GitHub Copilot filters prompts and suggestions more intelligently, so developers get more relevant code completions for their specific coding tasks. This has resulted in a +6% relative improvement in code acceptance rate, allowing developers to focus even more on the creative aspects of their work rather than getting bogged down in tedious coding tasks. The productivity gain also allows developers to tackle more ambitious projects and bring their ideas to life more quickly. Unlock new levels of productivity and satisfaction with GitHub Copilot The improved AI model and the new context filtering offer 13% latency improvement and 6% relative improvement in code acceptance rate, building upon the productivity gains developers have come to expect while using GitHub Copilot. With these improvements, developers can expect to stay in the flow and work more efficiently than ever, leading to faster innovation with better code. They’ll also find more satisfaction with their work, given research that shows minimizing disruptions and staying in the flow have a tangible impact on developer happiness. At GitHub, we’re committed to continuing to improve the developer experience with GitHub Copilot. We have some exciting plans in the works and will continue to share news on our blog and Changelog. Whether you’re a seasoned pro or just starting out, GitHub Copilot can help you take your coding skills to the next level–and we can’t wait to see what you’ll build with it!

Make more informed decisions about the code you use. In the rare case where a GitHub Copilot suggestion matches public code, this update will show a list of repositories where that code appears and their licenses. Sign up for the private beta today. Over the course of the last year, GitHub Copilot, the world’s first at-scale AI pair programmer trained on billions of lines of public code, has attracted more than 1 million developers and helped over 27,000 organizations build faster and more productively. During that time, many developers told us they want to see when GitHub Copilot’s suggestions match public code. Today, we’re announcing a private beta of GitHub Copilot with code referencing that includes an updated filter which detects and shows context of code suggestions matching public code on GitHub. When the filter is enabled, GitHub Copilot checks code suggestions with surrounding code of about 150 characters and compares it against an index of all the public code on GitHub.com. Matches—along with information about every repository in which they appear—are displayed right in the editor. Developers can now choose whether to block suggestions containing matching code, or allow those suggestions with information about matches. Why? Some want to learn from others’ work, others may want to take a dependency rather than introduce new app logic, and still others want to give or receive credit for similar work. Whatever the reason, it’s nice to know when similar code is out there. Let’s see how it works. How GitHub Copilot code referencing works With billions of files to index and a latency budget of only 10-20ms, it’s a miracle of engineering that this is even possible. Still, if there’s a match, a notification appears in the editor showing: (1) the matching code, (2) the repositories where that code appears, and (3) the license governing each repository. Why code referencing matters In our journey to create a code referencing tool, we discovered a few interesting things: First, our previous research suggests that matches occur in less than one percent of GitHub Copilot suggestions. But that one percent isn’t evenly distributed across all use cases. In the context of an existing application with surrounding code, we almost never see a match. But in an empty or nearly empty file, we see matches far more often. Suggestions are heavily biased toward the prompt so GitHub Copilot can provide suggestions tailor-made for your current task. That means, in an existing app with lots of context, you’ll get a suggestion customized for your code. But in an empty, or nearly empty file, there’s little to no context. So, you’re more likely to get a suggestion that matches public code. We’ve also found that when suggestions match public code, those matches frequently appear in dozens, if not hundreds of repositories. In some ways, this isn’t surprising because the models that power GitHub Copilot are akin to giant probability machines. A code fragment that appears in many repositories is more likely to be a “pattern” detected by the model—similar to the patterns we see elsewhere in public code. For example, research on Java projects finds that up to 11% of repositories may contain code that resembles solutions posted to Stack Overflow, and the vast majority of those snippets appear without attribution. Another study on Python found that many […]

Want the TL;DR, or you’ve already been using GitHub for awhile? Skip to the end for a printable checklist that you can use to ensure that you’ve covered all aspects of making your repository collaboration-ready. My daughter has a pair of pet gerbils. They’re awesome, but not the most complex creatures to care for. They need their cage cleaned occasionally, their food and water refilled, and may need a neighbor to check in on them if we’re away for a while. But someday, she may have a pet that requires more care and attention–a cat or dog perhaps, which needs to be played with and nurtured every day–so she’ll want to have a few good friends who know her pet and can be their companion whenever she’s away. And someday, she may even have a child of her own, making her connections to community and family ever more important. As the saying goes, it takes a village to raise a child. So it goes with code projects. My colleagues and I often refer to our projects as “pets” or even “children” (sometimes jokingly, sometimes obsessively). We pour a lot of our own care and attention into them, but it can be easy to forget how important the community’s contributions can be to their success. In the world of software development, collaboration can make the difference between a brittle last-minute release and a reliable, maintainable, pain-free project. Whether you’ve been coding for a day or a decade, your colleagues are there to help strengthen your work. But they can only help if you’ve given them the tools to do so. Your primary responsibility as the creator or maintainer of a repository is to ensure that others can appropriately use, understand, and even contribute to the project. GitHub is here to support that mission, but ensuring that a repository is collaboration-ready takes a bit more effort than using git clone. So read on to learn the settings, content, and behaviors that will help you succeed. 1. Repository settings The settings of your repository lay the foundation for collaboration. They determine who can see and contribute to your project, how contributions are reviewed, and what happens to those contributions once they are submitted. Properly used, they can foster an environment in which contributors across the globe will find, make use of, and help build your project. In a corporate setting, they help shift developers from a siloed way of thinking and building to a “search-first, collaborate-first” mindset. This practice, known as innersourcing, reduces redundant work and accelerates the whole company. Visibility You’re aiming to maximize contributions and reuse, but that doesn’t always mean making your repository public, especially in a corporate setting where information privacy is a consideration. You have several options available in the “Settings” tab of your repository. Public lets anyone in the world see and copy your code, and generally allows them to create issues or pull requests, so they can provide feedback about whether it works well, or even suggest (but not force) changes to improve it. This is generally great for personal projects containing no protected information (those tokens are all stored separately, right?) but only for certain “blessed” company projects. Internal is a special visibility level used by GitHub Enterprise, allowing anyone inside your organization to see […]

Today, GitHub is releasing a public beta for the new, Apple silicon powered M1 macOS larger runner for GitHub Actions. Apple silicon powered M1 macOS larger runners Apple developers require the latest chipset to take advantage of features in the latest versions of iOS and macOS. They also want increased performance by leveraging the on-chip GPU capabilities of the M1 processor. The M1 macOS runner comes with GPU hardware acceleration enabled by default. Workloads are transferred from the CPU to the GPU for improved performance and efficiency. The runner is equipped with a 6-core CPU, 8-core GPU, 14 GB of RAM, and 14 GB of storage. It can reduce build times by up to 80% compared to the existing 3-core Intel standard runner, and up to 43% compared to the existing 12-core Intel runner. How GitHub uses the M1 runner to build GitHub mobile for iOS The GitHub mobile iOS team leverages the new M1 runner for 10k+ minutes to deliver updates of the GitHub iOS app to the Apple App Store every week. The transition from the 12-core Intel runner to the M1 runner resulted in a 44% build time improvement, from 42 minutes to 23 minutes. While the time spent testing the binary remained constant for single target runs, code compilation improved by 51%, along with UI tests improving by 55% across the entire GitHub mobile test suite. The transition to the M1 runner was seamless, with updating the YAML workflow label being the only requirement to access it. However, due to differences in UI rendering between M1 Macs and Intel Macs, the team had to re-record images for snapshot tests, which compare new UI images with recorded reference images on a pixel-by-pixel basis. The M1 runner has proven to be advantageous for iOS teams, as it provides access to the VMs GPU and speeds up the App Store review process. Faster approval and publishing of apps can be achieved, which reduces the time spent on submitting to the Apple app store. How to use the runner To try the new Apple silicon macOS larger runner, update the runs-on: key in your GitHub Actions YAML workflow YAML file to target macos-latest-xlarge or macos-13-xlarge. The 12-core macOS larger runner is moving from xlarge to large, and is still available by updating the runs-on: key to macos-latest-large, macos-12-large, or macos-13-large. There is no sign-up required for the beta and the runner is immediately available to all developers, teams, and enterprises. New macOS runner pricing As part of GitHub’s continued commitment to deliver the best developer experience we are excited to share with you that we will be decreasing the price of our macOS larger runners. We understand the importance of achieving both cost-efficiency and high performance and this price decrease reflects our dedication to supporting your success. With today’s launch, our macOS larger runners will be priced at $0.16/minute for XL and $0.12/minute for large. To learn more about runner per job minute pricing, check out the docs. Additionally, if you’re interested in using larger macOS runners and understanding the difference between them and larger Linux and Windows runners, you can find more details in the “About larger runners” section of our documentation. What’s next? You can track progress towards the general availability of macOS larger runners by following this […]

In July, we introduced a public beta of GitHub Copilot Chat, a pivotal component of our vision for the future of AI-powered software development, for all GitHub Copilot for Business users. Today, we’re thrilled to take the next step forward in our GitHub Copilot X journey by releasing a public beta of GitHub Copilot Chat for all GitHub Copilot individual users across Visual Studio and VS Code. Integrated together, GitHub Copilot Chat and the GitHub Copilot pair programmer form a powerful AI-assistant capable of helping every developer build at the speed of their minds in the natural language of their choice. We believe this cohesion will form the new centerpiece of the software development experience, fundamentally reducing boilerplate work and designating natural language as a new universal programming language for every developer on the planet. Let’s jump in and take a deeper look into what this announcement means for individual developers and how you can get started. How developers can access GitHub Copilot Chat beta GitHub Copilot Chat beta has been enabled for all Copilot for Individual users for free. Currently, GitHub Copilot Chat is supported in both Visual Studio and Visual Studio Code editors. GitHub Copilot for Individual users will also receive an email notification to guide them on the next steps. If you’re not already part of our beta program and would like to get started, please refer to our comprehensive getting started guide, which is conveniently linked in your email notification. What GitHub Copilot Chat can do for you Now, anyone signed up for GitHub Copilot for individuals can access the powerful AI assistant that major enterprises are leveraging to turbocharge developer productivity and happiness. Now, teams of developers and individuals alike can use GitHub Copilot Chat to learn new languages or frameworks, troubleshoot bugs, or get answers to coding questions in simple, natural language outputs—all without leaving the IDE. By reducing the need for context switching, it streamlines the development process, which helps developers maintain their focus and momentum. GitHub Copilot Chat also empowers individual contributors to suggest security patches, enhancing the overall security of open-source projects—and we think that’s pretty exciting news for the developer community. Here are some of GitHub Copilot Chat’s other powerful features: Real-time guidance. GitHub Copilot Chat can suggest best practices, tips, and solutions tailored to specific coding challenges—all in real time. Developers can use GitHub Copilot Chat to learn a new language or upskill at speed. Code analysis. With GitHub Copilot Chat, you can break down complex concepts and get explanations of code snippets. Fixing security issues. GitHub Copilot Chat can make suggestions for remediation and help reduce the number of vulnerabilities found during security scans. Simple troubleshooting. Trying to debug code? GitHub Copilot Chat not only identifies issues, but also offers suggestions, explanations, and alternative approaches. Democratizing software development for a new generation Today, developers are no longer just people building software for technology companies. They’re an increasingly diverse and global group of folks across industries, who are tinkering with code, design, and documentation in their free time; contributing to open source projects; conducting scientific research; and more. Whether you are a young developer in Brazil learning how to execute a unit test for the first time or a professor in Germany who needs help documenting data, GitHub Copilot […]

After three-plus years of concepting, designing, and shipping AI-driven developer tools, GitHub is continuing to explore new ways to bring powerful AI models into the developer workflow. Along the way, we’ve learned that the most important aspect of designing AI-driven products is to focus extensively on the developer experience (DevEx). While it can now feel like there’s a new AI announcement from every company every week, we’re here to reflect on what it takes to build an AI product from scratch—not just to integrate an LLM into an existing product. In this article, we’ll share 10 tips for designing AI products and developer tools, and lessons we learned first-hand from designing, iterating, and extending GitHub Copilot. Let’s jump in. Tip 1: Build on the creative power of natural language “The hottest new design system is natural language,” reports the team designing GitHub Copilot. According to them, the most important tools to develop right now are ones that will allow people to describe, in their respective natural languages, what they want to create, and then get the output that they want. Leveraging the creative power of natural language in AI coding tools will shift the way developers write code and solve complex problems, fueling creativity and democratizing software development. Idan Gazit, Senior Director of Research for GitHub Next, identifies new modalities of interaction, or patterns in the way code is expressed to and written by developers. One of those is iteration, which is most often seen in chat functionalities. Developers can ask the model for an answer, and if it isn’t quite right, refine the suggestions through experimentation. He says, “When it comes to building AI applications today, the place to really distinguish the quality of one tool from another is through the tool’s DevEx.” To show how GitHub Copilot can help developers build more efficiently, here’s an example of a developer learning how to prompt the AI pair programmer to generate her desired result. A vague prompt like, “Draw an ice cream cone with ice cream using p5.js,” resulted in an image that looked like a bulls-eye target sitting on top of a stand: An example of GitHub Copilot responding to a vague prompt to draw an ice cream cone using p5.js and generating an image that looks like a bulls-eye target A revised prompt that specified details about the desired image, like “The ice cream cone will be a triangle with the point facing down, wider point at the top,” helped the developer to generate her intended result, and saved her from writing code from scratch: An example of a GitHub Copilot responding to a specific prompt to draw an ice cream cone using p5.js and generating the developer’s desired result Tip 2: Identify and define a developer’s pain points Designing for developers means placing their needs, preferences, and workflows at the forefront. Adrián Mato, who leads GitHub Copilot’s design team, explains, “It’s hard to design a good product if you don’t have an opinion. That’s why you need to ask questions, embrace user feedback, and do the research to fully understand the problem space you’re working in, and how developers think and operate.” Keeping devs in the flow For example, when designing GitHub Copilot, our designers had to make decisions about optionality, which is when an AI model […]

GitHub Projects has been adopted by program managers, OSS maintainers, enterprises, and individual developers alike for its user-friendly design and efficiency. We all know that managing issues and pull requests in our repositories can be challenging. To help you optimize your usage of GitHub Projects to plan and track your work from start to finish, I’ll be sharing 10 things you can do with GitHub Projects to make it easier to keep track of your issues and pull requests. 1. Manage your projects with the CLI If you prefer to work from your terminals, we’ve made it more convenient for you to manage and automate your project workflows with the GitHub CLI project command. This essentially allows you to work more collaboratively with your team to keep your projects updated with your existing toolkit. For example, if I wanted to add a draft issue to my project “Learning Ruby,” I would do this by first ensuring that I have the CLI installed and I’m authenticated with the project scope. Once authenticated, I need to find the number of the project I want to manage with the CLI. You can find the project number by looking at the project URL. For example, https://github.com/orgs/That-Lady-Dev/projects/4 the project number here is “4.” Now that we have the project number, we can use it to add a draft issue to the project! The command will look like this: gh project item-create 4 –owner That-Lady-Dev –title “Test Adding Draft” –body “I added this draft issue with GitHub CLI” When we run this, a new draft issue is added to the project: You can do a lot more with the GitHub CLI and GitHub projects. Check out our documentation to see all the possibilities of interacting with your projects from the terminal. 2. Export your projects to TSV If you ever need your project data, you can export your project view to a file, which can then be imported into Figjam, Google Sheets, Excel, or any other platform that supports TSV files. Go to any view of your project and click the arrow next to the view name, then select Export view data. This will give you a TSV file that you can use. Though TSV offers much better formatting than a CSV file, you can ask GitHub Copilot Chat how to convert a TSV file to a CSV file, copy the code, run it, and get your new CSV document, if CSV is your jam. Here’s a quick gist of how I converted a TSV to a CSV with GitHub Copilot Chat! 3. Create reusable project templates If you often find yourself recreating projects with similar content and structure, you can set a project as a template so you and others can use it as a base when creating new projects. To set your project as a template, navigate to the project “Settings” page, and under the “Templates” section toggle on Make template. This will turn the project into a template that can be used with the green Use this template button at the top of your project, or when creating a new project. Building a library of templates that can be reused across your organization can help you and your teams share best practices and inspiration when getting started with a project! 4. Make a […]

GitHub Enterprise Server 3.10 is now generally available. With this version, organizations are able to give developers and administrators more control over their repositories with enhanced security and compliance controls, and ensure secure development is a top priority. Highlights of this release include: GitHub Projects is generally available, with additions that help teams manage large projects (#650) Always deploy safely, with custom deployment protection rules for GitHub Actions (#199) and new policy control over runners Start finding vulnerabilities in all your repositories, in just a few clicks with a new default setup experience for GitHub Advanced Security code scanning (#642), and track security coverage and risk at the enterprise level (#766) Fine-grained personal access tokens (PATs) bring granular control to PATs (#184) Branch protections meet more compliance needs with more control over merge policies Backup instances faster and more incrementally, for more confident operations Download GitHub Enterprise Server 3.10 now. For help upgrading, use the Upgrade Assistant to find the upgrade path from your current version of GHES to this new version. GitHub Projects is generally available Organize and track your team’s work directly on GitHub using the new Projects, now generally available on Enterprise Server. Built like a spreadsheet, project tables give you a live workspace to filter, sort, and group issues and pull requests. This gives administrators greater visibility across everything that’s happening, and development teams can collaborate and stay in flow more efficiently. Before GitHub Projects, I would have needed two or more tools to get context from interdisciplinary teams on their projects. Now I can get context at a glance all in one place, so teams can be efficient and stay in the flow. – Lisa Vanderschuit, Engineering Program Manager, Office of the CTO, Shopify Always deploy safely, with custom deployment protection rules for GitHub Actions Shipping software faster means knowing you’re doing so safely. That means deployments need to be both governed and automated. Teams using GitHub Actions for continuous deployment have long been able to protect specific environments to enforce deployment protection rules, such as requiring approval from specific team members. With GitHub Enterprise Server 3.10, teams can create their own custom deployment protection rules (beta) to set up rigorous guardrails that ensure only the deployments that pass all quality, security, and manual approval requirements make it to production. What’s more, this release also gives administrators new control over the security and management of runners for GitHub Actions. Centrally managing self-hosted runners is a best practice that helps companies ensure that runners aren’t compromised by untrusted code in a workflow. Now, enterprise administrators can disable repository level self-hosted runners across organizations and user namespaces, ensuring that all jobs are hosted on centrally governed machines. Start finding vulnerabilities in all your repositories, in just a few clicks We’re always looking for ways to make it easier for developers to secure their code. This means building security tools that provide a frictionless experience for developers so they can focus on innovation. With code scanning, automated security checks are run with every pull request, surfacing issues in the context of the development workflow and empowering developers to fix 48% of vulnerabilities in real time and 72% within 28 days. In this release, we’re making it easier for all developers to realize these results with seamless enablement. Developers […]