Blog

Willkommen zurück bei GitHub für Anfänger. Bisher haben wir GitHub-Probleme und -Projekte, GitHub-Aktionen, Sicherheit, GitHub-Seiten und Markdown. Dieses Mal werden wir über Open-Source-Software sprechen und darüber, wie man zu dieser Community beitragen kann. Am Ende dieses Beitrags wissen Sie, was Open Source ist, wie Sie Projekte finden, an denen Sie arbeiten können, wie Sie ein Open Source-Repository lesen und mit dem Einbringen Ihrer ersten Beiträge beginnen können. Also fangen wir an!

Wenn Sie sich das Video lieber ansehen oder darauf verweisen möchten, haben wir wie immer alle unsere GitHub for Beginners-Episoden auf YouTube verfügbar.

Was ist Open Source?

Open-Source-Software (OSS) bezieht sich auf Software, die über frei verfügbaren Quellcode verfügt. Im Gegensatz zu „Closed-Source-Software“ ist OSS öffentlich verfügbar und kann von jedem genutzt und darauf aufgebaut werden. Das bedeutet, dass die gesamte Arbeit, einschließlich der Codebasis und der Kommunikation zwischen Benutzern, für jeden sichtbar ist.

Wenn Sie gerade erst in die Welt der Softwareentwicklung einsteigen, ist das Durchsuchen und Mitwirken an Open-Source-Projekten eine großartige Möglichkeit, in große, wirkungsvolle Projekte einzutauchen, die von unzähligen Benutzern weltweit genutzt werden.

GitHub ist die Heimat für Open-Source-Software. Schauen wir uns also an, wie Sie Projekte finden, zu denen Sie beitragen können.

So finden Sie OSS-Projekte, an denen Sie arbeiten können

Der erste Beitrag zu einem Open-Source-Softwareprojekt kann entmutigend sein – das kennen wir alle! Der erste Schritt besteht darin, nach Projekten in einer Ihnen bekannten Sprache zu suchen, die neue Mitwirkende aufnehmen. Eine Möglichkeit, dies zu tun, besteht darin, GitHub Copilot Chat um Hilfe zu bitten.

• Navigieren Sie zu github.com und wählen Sie das Copilot-Symbol aus, um ein Chat-Fenster zu öffnen.
• Verwenden Sie in der unteren linken Ecke des Chat-Fensters das Kombinationsfeld, um Fragen auszuwählen.
• Geben Sie eine Eingabeaufforderung wie die folgende ein, aber denken Sie daran, sie auf eine Sprache zu aktualisieren, mit der Sie vertraut sind.

Ich suche nach einer Liste von in TypeScript geschriebenen Open-Source-Projekten, die neue Mitwirkende akzeptieren. Durchsuchen Sie GitHub und grenzen Sie die Liste auf Repositories ein, die das Label „Gute Erstausgabe“ verwenden und über 100 Sterne auf GitHub haben. 

Copilot führt eine Suche durch und gibt eine Liste von Projekten zurück, die Sie erkunden können, gefiltert nach dem Label gute erste Ausgabe. Dieses Label weist darauf hin, dass eine Ausgabe für Anfänger geeignet und ein guter Ausgangspunkt für neue Mitwirkende ist. Dieses Label ist eine großartige Möglichkeit, Probleme in einem Projekt zu finden, an dem Sie arbeiten können.

Angenommen, Sie möchten zum vscode-Repository beitragen.

1. Navigieren Sie zum vscode-Repository.
2. Wählen Sie oben im Repository die Registerkarte Probleme aus.
3. Klicken Sie auf der Seite „Probleme“ auf das Feld Beschriftungen, um das Dropdown-Menü zu öffnen.
4. Geben Sie im Textfeld des Dropdown-Menüs „gut“ ein, bis Sie die Option „gute erste Ausgabe“ sehen.
5. Wählen Sie das Label gute erste Ausgabe aus.

Das Fenster wird aktualisiert und zeigt eine Liste guter erster Probleme an, an denen Sie arbeiten können. Aber bevor Sie loslegen, sollten Sie den Leitfaden für Mitwirkende im Repository des Projekts lesen. Die meisten gut gepflegten Open-Source-Projekte verfügen über eine.

Ein Open-Source-Projekt verstehen

Wie wir gerade angedeutet haben, haben die meisten Open-Source-Projekte einige Gemeinsamkeiten, wenn sie gut gepflegt werden. Dies sind die folgenden Elemente:

• Eine gut dokumentierte README-Datei mit Installationsanweisungen.
• Ein Leitfaden für Mitwirkende, der erklärt, wie man einen Beitrag leistet.
• Eine Open-Source-Lizenz, sodass jeder weiß, dass die Nutzung des Projekts kostenlos ist.
• Mindestens 100 GitHub-Sterne, um zu zeigen, dass es in der Community verwendet wird.
• Aktive Entwicklung, damit Sie wissen, dass ein Betreuer des Quellcodes Ihre Beiträge überprüfen kann.
• Ein Gute erste Ausgabe-Label, das darauf hinweist, dass es für neue Mitwirkende offen ist.

Wenn Sie nach einem Projekt suchen, zu dem Sie beitragen können, sollten Sie in einem Repository nach diesen Dingen suchen.

💡 Weitere Dokumentation zum Finden eines guten Open-Source-Projekts finden Sie unter gh.io/gfb-oss, um mehr über das Finden guter Erstausgaben zu erfahren.

Einen OSS-Beitrag leisten

Schauen wir uns nun ein konkretes Projekt an und überlegen, wie Sie Ihre erste Ausgabe einreichen würden. Werfen Sie für diese Demo einen Blick auf das gitfolio-Repository. Anhand der obigen Aufzählungspunkte möchten wir sehen, ob dies ein gutes Projekt für die Arbeit wäre.

• Das Projekt verfügt über eine gut dokumentierte README-Datei.
• Das Projekt verfügt über einen Leitfaden für Mitwirkende: CONTRIBUTING.md.
• Sie können die Open-Source-Lizenz sehen: LIZENZ.
• Es hat mehrere tausend Sterne und liegt damit weit über unserem 100er-Benchmark.
• Oben in der Dateiliste sehen Sie den letzten Check-in, der relativ aktuell sein sollte. Während ich dies schreibe, war der letzte Check-in gestern, was darauf hindeutet, dass das Projekt aktiv gepflegt wird.

Auf der Grundlage dieser Punkte ist dies ein gutes Repository, zu dem Sie beitragen können, sofern Sie mit TypeScript vertraut sind. Sie müssen jedoch nicht mit TypeScript vertraut sein, um der Demo folgen zu können.

Jetzt möchten Sie einen Zweig des Repositorys erstellen. Ein Fork ist eine Kopie des Repositorys, mit der wir frei experimentieren und Änderungen vornehmen können, ohne das ursprüngliche Projekt zu beeinträchtigen. Normalerweise verwenden wir Forks für Open-Source-Beiträge. Wenn Sie eine Auffrischung zum Forken eines Repositorys benötigen, schauen Sie sich diesen vorherigen GitHub for Beginners-Blog an.

1. Navigieren Sie zur Startseite des Projekts, falls Sie noch nicht dort sind.
2. Klicken Sie oben im Projekt auf die Schaltfläche Fork.
3. Belassen Sie sich im neuen Fenster als Eigentümer und stellen Sie sicher, dass der „Repository-Name“ mit dem ursprünglichen Repository übereinstimmt (d. h. „gitfolio“).
4. Wählen Sie unten im Fenster Fork erstellen aus.
5. Klicken Sie in Ihrer abgezweigten Kopie des Repositorys in der Liste der Dateien auf README.md.
6. Ändern Sie die Datei, indem Sie etwas Text hinzufügen.
7. Wählen Sie oben rechts die Option Änderungen übernehmen…

aus

8. Stellen Sie sicher, dass Sie unten die Option Neuen Zweig aus diesem Commit erstellen auswählen und eine Pull-Anfrage starten.
9. Wählen Sie Änderungen vorschlagen.
10. Klicken Sie im folgenden Fenster auf die Schaltfläche Pull-Anfrage erstellen. Dadurch können Sie von Ihrem Zweig aus eine Pull-Anfrage an das Haupt-Repository mit den Änderungen erstellen.
11. Wählen Sie oben im Fenster „Pull-Anfrage öffnen“ die Option Vergleich zwischen Forks aus. Dadurch werden die Änderungen Ihres Forks im Vergleich zum Original-Repository angezeigt.
12. Wenn Sie eine tatsächliche Änderung an das Repository übermitteln würden und nicht nur eine Demo durchgehen würden, würden Sie Ihrer Pull-Anfrage hier einen Titel und eine Beschreibung geben. Sie möchten in der Beschreibung der Pull-Anfrage auch einen Link zu dem Problem angeben, das Sie gelöst haben.

An diesem Punkt können Sie Ihre Pull-Anfrage senden, indem Sie auf die Schaltfläche unten im Fenster klicken. Sobald Sie dies jedoch tun, handelt es sich nicht mehr nur um eine Änderung in Ihrem Fork, sondern um ein angefordertes Update des ursprünglichen Repositorys. Aus diesem Grund ist es in den obigen Schritten nicht enthalten. Wenn Sie Ihre Pull-Anfrage einreichen, ist sie verfügbar und kann von einem Betreuer überprüft und hoffentlich genehmigt werden!

Nach der Genehmigung und Zusammenführung übernimmt GitHub die Änderungen von Ihrem Fork automatisch in den Hauptzweig des ursprünglichen Repositorys, der offiziellen Quelle der Wahrheit für die Codebasis.

Was kommt als nächstes?

Herzlichen Glückwunsch! Sie haben gelernt, wie Sie eigene Beiträge zu Open-Source-Software leisten können. Ich hoffe, es inspiriert Sie, zu Ihren Lieblingsprojekten beizutragen.

Und wenn Sie weitere Informationen suchen, haben wir zahlreiche Dokumentationen, die Ihnen weiterhelfen können. Hier sind ein paar Links zur Information:

• Möglichkeiten finden, zu Open Source auf GitHub beizutragen
• Beitrag zu Open-Source-Projekten
• Beitrag zu einem Projekt durch Forking

Viel Spaß beim Codieren!

Der Beitrag GitHub für Anfänger: Erste Schritte mit OSS-Beiträgen erschien zuerst auf dem GitHub-Blog.

Zur Originalquelle gehen

Welcome back to GitHub for Beginners. So far, we’ve discussed GitHub Issues and Projects, GitHub Actions, security, GitHub Pages, and Markdown. This time we’re going to talk about open source software and how to contribute to that community. By the end of this post, you’ll know what open source is, how to find projects to work on, how to read an open source repository, as well as start making your first contributions. So let’s get started!

As 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.

What is open source?

Open source software (OSS) refers to software that features freely available source code. In contrast with “closed source software,” OSS is publicly available for anyone to use and build upon. This means that all of the work, including the codebase and communication between users, is available for everyone to see.

If you’re just getting started in the world of software development, browsing and contributing to open source projects is a great way to dip your toes into large, impactful projects used by countless users worldwide.

GitHub is the home for open source software, so let’s look at how to find projects you can contribute to.

How to find OSS projects to work on

Contributing to an open source software project for the first time can be daunting—we’ve all been there! The first step is to look for projects in a language that you know which are accepting new contributors. One of the ways you can do this is to ask GitHub Copilot Chat for help.

• Navigate to github.com and select the Copilot icon to open a chat window.
• In the bottom-left corner of the chat window, use the combo box to select Ask.
• Enter a prompt like the following, but remember to update it for a language you’re comfortable with.

I'm looking for a list of open source projects written in TypeScript that are accepting new contributors. Search GitHub and narrow down the list to repositories that use the good first issue label and have over 100 stars on GitHub. 

Copilot will do some searching and return a list of projects you can explore filtered by the good first issue label. This label indicates that an issue is beginner friendly, and a great starting point for new contributors. This label is a great way to find issues in a project you can work on.

For example, let’s say that you wanted to contribute to the vscode repository.

1. Navigate to the vscode repository.
2. At the top of the repository, select the Issues tab.
3. On the Issues page, click the Labels box to open the drop down menu.
4. In the text box on the drop down menu, start typing “good” until you see the option for good first issue.
5. Select the good first issue label.

The window will update and display a list of good first issues for you to work on. But before jumping in, you should read the contributor’s guide in the project’s repository. Most well-maintained open source projects will have one.

Understanding an open source project

As we just alluded to, most open source projects have a few things in common if they’re well maintained. These are the following items:

• A well-documented README with installation instructions.
• A contributor’s guide that explains how to contribute.
• An open source license, so everyone knows the project is free to use.
• At least 100 GitHub stars to show it’s used in the community.
• Active development so that you know a maintainer of the source code will be able to review your contributions.
• A good first issue label to indicate its open to new contributors.

When you’re looking for a project to contribute to, these are the things you should be looking for in a repository.

💡 For more documentation on finding a good open source project, go to gh.io/gfb-oss to learn more about finding good first issues.

Making an OSS contribution

Now let’s look at an actual project and work on how you would submit your first issue. For this demo, take a look at the gitfolio repository. Using the bullet points above, we want to see if this would be a good project to work on.

• The project does have a well-documented README file.
• The project has a contributor’s guide: CONTRIBUTING.md.
• You can see the open source license: LICENSE.
• It has several thousands of stars, so well over our 100 benchmark.
• At the top of the file list, you can see the most recent check in which should be fairly recent. While writing this, the last check in was yesterday, indicating the project is being actively maintained.

Based on these points, as long as you are familiar with TypeScript, this is a good repository to contribute to. However, you don’t need to be familiar with TypeScript to continue following along in the demo.

Now you want to create a fork of the repository. A fork is a copy of the repository that we can freely experiment on and make changes in without affecting the original project. We usually use forks for open source contributions. If you need a refresher on forking a repository, check out this previous GitHub for Beginners blog.

1. Navigate to the home page of the project if you are not already there.
2. At the top of the project, click the Fork button.
3. In the new window, leave yourself as the owner and make sure the “Repository name” is the same as the original repository (i.e., “gitfolio”).
4. At the bottom of the window, select Create fork.
5. In your forked copy of the repository, click README.md in the list of files.
6. Change the file by adding some text.
7. In the top-right, select Commit changes…
8. Make sure to select the option at the bottom for Create a new branch from this commit and start a pull request.
9. Select Propose changes.
10. On the following window, click the Create pull request button. This will let you create a pull request to the main repository from your branch with the changes.
11. At the top of the “Open a pull request” window, select compare across forks. This will show your fork’s changes compared to the original repository.
12. If you were submitting an actual change to the repository—not just walking through a demo—this is where you would give your pull request a title and a description. You’d also want to provide a link to the issue that you were solving in the description of the pull request.

At this point, you’d be ready to submit your pull request by clicking the button at the bottom of the window. However, once you do that, it no longer becomes just a change in your fork and will be a requested update on the original repository. That’s why it isn’t included in the steps above. When you do submit your pull request, it will be available and ready for a maintainer to review and, hopefully, approve!

Once approved and merged, GitHub automatically applies the changes from your fork into the main branch of the original repository, the official source of truth for the codebase.

What’s next?

Congratulations! You’ve learned how to make your own contributions to open source software. I hope it inspires you to contribute to your favorite projects.

And if you’re looking for more information, we have lots of documentation that can help. Here are a few links to get you stated:

• Finding ways to contribute to open source on GitHub
• Contributing to open source projects
• Contributing to a project through forking

Happy coding!

The post GitHub for Beginners: Getting started with OSS contributions appeared first on The GitHub Blog.

Go to Original Source

Welcome back to GitHub for Beginners. So far, we’ve discussed GitHub Issues and Projects, GitHub Actions, security, GitHub Pages, and Markdown. This time we’re going to talk about open source software and how to contribute to that community. By the end of this post, you’ll know what open source is, how to find projects to work on, how to read an open source repository, as well as start making your first contributions. So let’s get started!

As 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.

What is open source?

Open source software (OSS) refers to software that features freely available source code. In contrast with “closed source software,” OSS is publicly available for anyone to use and build upon. This means that all of the work, including the codebase and communication between users, is available for everyone to see.

If you’re just getting started in the world of software development, browsing and contributing to open source projects is a great way to dip your toes into large, impactful projects used by countless users worldwide.

GitHub is the home for open source software, so let’s look at how to find projects you can contribute to.

How to find OSS projects to work on

Contributing to an open source software project for the first time can be daunting—we’ve all been there! The first step is to look for projects in a language that you know which are accepting new contributors. One of the ways you can do this is to ask GitHub Copilot Chat for help.

• Navigate to github.com and select the Copilot icon to open a chat window.
• In the bottom-left corner of the chat window, use the combo box to select Ask.
• Enter a prompt like the following, but remember to update it for a language you’re comfortable with.

I’m looking for a list of open source projects written in TypeScript that are accepting new contributors. Search GitHub and narrow down the list to repositories that use the good first issue label and have over 100 stars on GitHub. 

Copilot will do some searching and return a list of projects you can explore filtered by the good first issue label. This label indicates that an issue is beginner friendly, and a great starting point for new contributors. This label is a great way to find issues in a project you can work on.

For example, let’s say that you wanted to contribute to the vscode repository.

1. Navigate to the vscode repository.
2. At the top of the repository, select the Issues tab.
3. On the Issues page, click the Labels box to open the drop down menu.
4. In the text box on the drop down menu, start typing “good” until you see the option for good first issue.
5. Select the good first issue label.

The window will update and display a list of good first issues for you to work on. But before jumping in, you should read the contributor’s guide in the project’s repository. Most well-maintained open source projects will have one.

Understanding an open source project

As we just alluded to, most open source projects have a few things in common if they’re well maintained. These are the following items:

• A well-documented README with installation instructions.
• A contributor’s guide that explains how to contribute.
• An open source license, so everyone knows the project is free to use.
• At least 100 GitHub stars to show it’s used in the community.
• Active development so that you know a maintainer of the source code will be able to review your contributions.
• A good first issue label to indicate its open to new contributors.

When you’re looking for a project to contribute to, these are the things you should be looking for in a repository.

💡 For more documentation on finding a good open source project, go to gh.io/gfb-oss to learn more about finding good first issues.

Making an OSS contribution

Now let’s look at an actual project and work on how you would submit your first issue. For this demo, take a look at the gitfolio repository. Using the bullet points above, we want to see if this would be a good project to work on.

• The project does have a well-documented README file.
• The project has a contributor’s guide: CONTRIBUTING.md.
• You can see the open source license: LICENSE.
• It has several thousands of stars, so well over our 100 benchmark.
• At the top of the file list, you can see the most recent check in which should be fairly recent. While writing this, the last check in was yesterday, indicating the project is being actively maintained.

Based on these points, as long as you are familiar with TypeScript, this is a good repository to contribute to. However, you don’t need to be familiar with TypeScript to continue following along in the demo.

Now you want to create a fork of the repository. A fork is a copy of the repository that we can freely experiment on and make changes in without affecting the original project. We usually use forks for open source contributions. If you need a refresher on forking a repository, check out this previous GitHub for Beginners blog.

1. Navigate to the home page of the project if you are not already there.
2. At the top of the project, click the Fork button.
3. In the new window, leave yourself as the owner and make sure the “Repository name” is the same as the original repository (i.e., “gitfolio”).
4. At the bottom of the window, select Create fork.
5. In your forked copy of the repository, click README.md in the list of files.
6. Change the file by adding some text.
7. In the top-right, select Commit changes…
8. Make sure to select the option at the bottom for Create a new branch from this commit and start a pull request.
9. Select Propose changes.
10. On the following window, click the Create pull request button. This will let you create a pull request to the main repository from your branch with the changes.
11. At the top of the “Open a pull request” window, select compare across forks. This will show your fork’s changes compared to the original repository.
12. If you were submitting an actual change to the repository—not just walking through a demo—this is where you would give your pull request a title and a description. You’d also want to provide a link to the issue that you were solving in the description of the pull request.

At this point, you’d be ready to submit your pull request by clicking the button at the bottom of the window. However, once you do that, it no longer becomes just a change in your fork and will be a requested update on the original repository. That’s why it isn’t included in the steps above. When you do submit your pull request, it will be available and ready for a maintainer to review and, hopefully, approve!

Once approved and merged, GitHub automatically applies the changes from your fork into the main branch of the original repository, the official source of truth for the codebase.

What’s next?

Congratulations! You’ve learned how to make your own contributions to open source software. I hope it inspires you to contribute to your favorite projects.

And if you’re looking for more information, we have lots of documentation that can help. Here are a few links to get you stated:

• Finding ways to contribute to open source on GitHub
• Contributing to open source projects
• Contributing to a project through forking

Happy coding!

The post GitHub for Beginners: Getting started with OSS contributions appeared first on The GitHub Blog.

Orijinal Kaynağa Git

Nous avons entendu vos questions quant à savoir si l’utilisation incluse dans chaque plan GitHub Copilot ira assez loin lorsque nous passerons à la facturation basée sur l’utilisation le 1er juin. Des exécutions d’agents plus longues, un travail en plusieurs étapes et des modèles plus performants exerceront tous une pression sur les quantités d’utilisation détaillées dans notre annonce originale.

Nous mettons à jour la programmation individuelle en fonction de ces commentaires. Pro et Pro+ incluront une utilisation plus totale au même prix grâce à une nouvelle allocation flexible, et nous introduisons Max, un nouveau plan pour un travail copilote soutenu et à volume élevé.

Ce qui est inclus

La gamme Copilot individuelle comprendra Free, Pro, Pro+ et Max, avec une facturation basée sur l’utilisation pour tous les forfaits. Free continuera d’inclure un nombre limité d’achèvements de code chaque mois, ainsi qu’une utilisation limitée du chat et des agents avec le mode automatique.

Pour les forfaits payants, l’utilisation mensuelle incluse se divise en deux parties :

• Crédits de base : correspond à 1:1 au prix de votre abonnement. Ceux-ci ne changent jamais. 
• Allocation Flex : utilisation supplémentaire variable en plus de votre base. Les allocations flexibles varient au fil du temps.

Vous trouverez ci-dessous les plans individuels au 1er juin 2026 :

Comment ça marche

Vos crédits de base sont utilisés en premier. Si vous dépassez votre base, l’allocation flexible est appliquée automatiquement aux mêmes tarifs dans votre IDE, github.com et la CLI. Vous n’avez pas besoin d’activer quoi que ce soit ni de gérer un compartiment séparé ; Votre tableau de bord affichera ce qui est disponible et ce que vous avez utilisé. Et si vous utilisez tout ce qui est inclus dans votre forfait, vous pouvez acheter davantage d’utilisations et continuer.

Les complétions de code et les suggestions de prochaines modifications restent illimitées sur les forfaits payants et ne consomment pas de crédits.

Pourquoi la flexibilité peut changer

L’allocation flexible est une partie variable de votre utilisation incluse ; il est conçu pour s’adapter à mesure que l’économie de l’IA évolue, y compris la tarification des modèles, les nouveaux modèles et les améliorations de l’efficacité. Vos crédits de base, qui correspondent à 1:1 par rapport au prix de votre abonnement, resteront toujours les mêmes.

Que faire

Rien. Si vous disposez d’un forfait mensuel Pro ou Pro+, l’utilisation supplémentaire arrive automatiquement le 1er juin lorsque vous passez à la facturation basée sur l’utilisation.

Le message Plans individuels GitHub Copilot : introduction des allocations flexibles dans Pro et Pro+, et un nouveau plan Max est apparu en premier sur Le blog GitHub.

Aller à la source d’origine

Wir haben Ihre Fragen dazu gehört, ob die in jedem GitHub Copilot-Plan enthaltene Nutzung weit genug reicht, wenn wir am 1. Juni auf nutzungsbasierte Abrechnung umstellen. Längere Agentenlaufzeiten, mehrstufige Arbeit und leistungsfähigere Modelle werden Druck auf die Nutzungsmengen ausüben, die in unserer ursprünglichen Ankündigung aufgeführt sind.

Wir aktualisieren die individuelle Aufstellung basierend auf diesem Feedback. Pro und Pro+ werden durch ein neues Flex-Kontingent mehr Gesamtnutzung zum gleichen Preis beinhalten, und wir führen Max ein, einen neuen Plan für nachhaltige, hochvolumige Copilot-Arbeit.

Was ist enthalten

Das individuelle Copilot-Angebot umfasst Free, Pro, Pro+ und Max, mit nutzungsbasierter Abrechnung für alle Pläne. Die kostenlose Version umfasst weiterhin eine begrenzte Anzahl von Code-Vervollständigungen pro Monat sowie eine begrenzte Chat- und Agentennutzung im automatischen Modus.

Bei kostenpflichtigen Plänen besteht die monatliche Inklusivnutzung aus zwei Teilen:

• Basisguthaben: werden 1:1 mit Ihrem Abonnementpreis abgeglichen. Diese ändern sich nie. 
• Flex-Kontingent: variable zusätzliche Nutzung zusätzlich zu Ihrer Basis. Flex-Kontingente können im Laufe der Zeit variieren.

Unten sind die einzelnen Pläne mit Stand vom 1. Juni 2026:

Wie es funktioniert

Ihre Basis-Credits werden zuerst verwendet. Wenn Sie über Ihre Basis hinausgehen, wird das Flex-Kontingent automatisch zu den gleichen Sätzen auf Ihre IDE, github.com und die CLI angewendet. Sie müssen nichts einschalten oder einen separaten Bucket verwalten; Ihr Dashboard zeigt, was verfügbar ist und was Sie verwendet haben. Und wenn Sie alles nutzen, was in Ihrem Plan enthalten ist, können Sie mehr Nutzung erwerben und weitermachen.

Codevervollständigungen und Vorschläge für die nächste Bearbeitung bleiben bei kostenpflichtigen Plänen unbegrenzt und verbrauchen keine Credits.

Warum sich Flex ändern kann

Das Flex-Kontingent ist ein variabler Teil Ihrer inbegriffenen Nutzung; Es ist so konzipiert, dass es sich an die Weiterentwicklung der wirtschaftlichen Aspekte der KI anpasst, einschließlich Modellpreisen, neuen Modellen und Effizienzsteigerungen. Ihr Grundguthaben, das 1:1 zu Ihrem Abonnementpreis beträgt, bleibt immer gleich.

Was zu tun ist

Nichts. Wenn Sie einen monatlichen Pro- oder Pro+-Plan haben, landet die zusätzliche Nutzung automatisch am 1. Juni, wenn Sie zur nutzungsbasierten Abrechnung migrieren.

Der Beitrag GitHub Copilot-Einzelpläne: Einführung von Flex-Zuteilungen in Pro und Pro+ und ein neuer Max-Plan erschien zuerst auf Der GitHub-Blog.

Zur Originalquelle gehen

We’ve heard your questions about whether the included usage in each GitHub Copilot plan will go far enough when we transition to usage-based billing on June 1st. Longer agent runs, multi-step work, and more capable models will all put pressure on the usage amounts detailed in our original announcement.

We’re updating the individual lineup based on that feedback. Pro and Pro+ will include more total usage at the same price through a new flex allotment, and we’re introducing Max, a new plan for sustained, high-volume Copilot work.

What’s included

The individual Copilot lineup will span Free, Pro, Pro+, and Max, with usage-based billing across all plans. Free will continue to include a limited number of code completions each month, plus limited chat and agent usage with auto mode.

For paid plans, monthly included usage comes in two parts:

• Base credits: matched 1:1 with your subscription price. These never change. 
• Flex allotment: variable additional usage on top of your base. Flex allotments will vary over time.

Below are the individual plans as of June 1, 2026:

How it works

Your base credits are used first. If you go beyond your base, the flex allotment is applied automatically at the same rates across your IDE, github.com, and the CLI. You don’t need to turn anything on or manage a separate bucket; Your dashboard will show what’s available and what you’ve used. And if you use everything included in your plan, you can purchase more usage and keep going.

Code completions and next edit suggestions remain unlimited on paid plans and don’t consume credits.

Why flex can change

The flex allotment is a variable part of your included usage; it is designed to adapt as the economics of AI evolve, including model pricing, new models, and improvements in efficiency. Your base credits, which are 1:1 to your subscription price, will always stay the same.

What to do

Nothing. If you’re on a monthly Pro or Pro+ plan, the additional usage lands automatically on June 1 when you migrate to usage-based billing.

The post GitHub Copilot individual plans: Introducing flex allotments in Pro and Pro+, and a new Max plan appeared first on The GitHub Blog.

Go to Original Source

We’ve heard your questions about whether the included usage in each GitHub Copilot plan will go far enough when we transition to usage-based billing on June 1st. Longer agent runs, multi-step work, and more capable models will all put pressure on the usage amounts detailed in our original announcement.

We’re updating the individual lineup based on that feedback. Pro and Pro+ will include more total usage at the same price through a new flex allotment, and we’re introducing Max, a new plan for sustained, high-volume Copilot work.

What’s included

The individual Copilot lineup will span  Free, Pro, Pro+, and Max, with usage-based billing across all plans. Free will continue to include a limited number of code completions each month, plus limited chat and agent usage with auto mode.

For paid plans, monthly included usage comes in two parts:

• Base credits: matched 1:1 with your subscription price. These never change. 
• Flex allotment: variable additional usage on top of your base. Flex allotments will vary over time.

Below are the individual plans as of June 1, 2026:

How it works

Your base credits are used first. If you go beyond your base, the flex allotment is applied automatically at the same rates across your IDE, github.com, and the CLI. You don’t need to turn anything on or manage a separate bucket; your dashboard will show what’s available and what you’ve used. And if you use everything included in your plan, you can purchase more usage and keep going.

Code completions and next edit suggestions remain unlimited on paid plans and don’t consume credits.

Why flex can change

The flex allotment is a variable part of your included usage; it is designed to adapt as the economics of AI evolve, including model pricing, new models, and improvements in efficiency. Your base credits, which are 1:1 to your subscription price, will always stay the same.

What to do

Nothing. If you’re on a monthly Pro or Pro+ plan, the additional usage lands automatically on June 1 when you migrate to usage-based billing.

The post GitHub Copilot individual plans: Introducing flex allotments in Pro and Pro+, and a new Max plan appeared first on The GitHub Blog.

Orijinal Kaynağa Git

Commentaires

Accéder à la source originale

Kommentare

Zur Originalquelle gehen