GitHub AE release notes

Enterprise owners can join organizations on GitHub AE as a member or owner from the enterprise account's Organizations page. For more information, see "Managing your role in an organization owned by your enterprise."

Custom repository roles are generally available. With custom repository roles, organization owners now have more granular control over the repository access permissions they can grant to users. Custom repository roles are also fully supported by the REST API. For more information, see "Managing custom repository roles for an organization" and "Organizations" in the REST API documentation.

Enterprise owners can prevent organization owners from inviting collaborators to GitHub AE repositories. For more information, see "Enforcing a policy for inviting collaborators to repositories."

Users can opt to receive a webhook event that triggers when someone enables or disables a code security or analysis feature for an organization or repository. For more information, see the following documentation.

• "Webhook events and payloads" in the webhook documentation
• "Managing security and analysis settings for your organization"
• "Managing security and analysis features for your repository"

Enterprise owners and users can view secret scanning alerts and bypasses of secret scanning's push protection in the enterprise and organization audit logs, and via the REST API. For more information, see the following documentation.

• "Protecting pushes with secret scanning"
• "Audit log events for your enterprise"
• "Reviewing the audit log for your organization"
• "Secret Scanning" in the REST API documentation

Organization owners can now configure two new permissions for secret scanning when managing custom repository roles.

• View secret scanning results
• Dismiss or reopen secret scanning results

For more information, see "Managing custom repository roles for an organization."

Users can execute a dry run of custom secret scanning patterns at the enterprise, organization, or repository level, depending on their access. Dry runs allow users to review and hone their patterns before publishing them and generating alerts. You can compose a pattern, then use Save and dry run to retrieve results. The scans typically take just a few seconds, but GitHub AE will also notify users via email when dry run results are ready. For more information, see "About secret scanning" and "Defining custom patterns for secret scanning."

Users can enable secret scanning for archived repositories using the UI or API. For more information, see "About secret scanning," "About archived repositories," and "Repositories" in the REST API documentation.

Secret scanning prevents the leak of secrets in the web editor. For more information, see "Protecting pushes with secret scanning."

Code scanning now detects a larger number of CWEs, and CodeQL code scanning fully supports the standard language features in the following language releases.

• C# 10 / .NET 6
• Python 3.10
• Java 17
• TypeScript 4.5

For more information, see the GitHub Blog.

Organization owners and security managers can view code scanning alerts in an organization's Security tab. For more information, see "About the security overview."

The code scanning alert page now always shows the alert status and information for the default branch. There is a new "Affected branches" panel in the sidebar where you can see the status of the alert in other branches. If the alert does not exist in your default branch, the alert page will show the status as "In branch" or "In pull request" for the location where the alert was last seen. This improvement makes it easier to understand the status of alerts which have been introduced into the code base. For more information, see "About code scanning alerts." The alert list page is not changed and can be filtered by branch. You can use the code scanning API to retrieve more detailed branch information for alerts. For more information, see "Code Scanning" in the REST API documentation.

Code scanning now shows the details of the analysis origin of an alert. If an alert has more than one analysis origin, it is shown in the "Affected branches" sidebar and in the alert timeline. Users can hover over the analysis origin icon in the "Affected branches" sidebar to see the alert status in each analysis origin. If an alert only has a single analysis origin, no information about analysis origins is displayed on the alert page. These improvements will make it easier to understand alerts. In particular, it will help users understand those that have multiple analysis origins. This is especially useful for setups with multiple analysis configurations, such as monorepos. For more information, see "About code scanning alerts."

Users can use sort and direction parameters in the REST API when retrieving secret scanning alerts, and sort based on the alert’s created or updated fields. The new parameters are available for all of your GitHub AE deployment, or for individual organizations or repositories. For more information, see the following documentation.

• "List secret scanning alerts for an enterprise"
• "List secret scanning alerts for an organization"
• "List secret scanning alerts for a repository"
• "Secret Scanning" in the REST API documentation

Users can opt to receive a webhook that triggers when a secret is detected in a new location. The secret_scanning_alert_location webhook event includes location details, like the commit SHA, and the associated alert for the detection. A location is created for every new file path containing the detected secret. For more information, see "Webhook events and payloads."

Users can optionally add a comment when dismissing a code scanning alert in the web UI or via the REST API. Dismissal comments appear in the event timeline. Users can also add or retrieve a dismissal comment via the REST API. For more information, see "Triaging code scanning alerts in pull requests" and "Code Scanning" in the REST API documentation.

Users can now retrieve code scanning alerts for an organization using the REST API. This new API endpoint supplements the existing endpoint for repositories. For more information, see "Code Scanning" in the REST API documentation.

The contents of the github/codeql-go repository have moved to the github/codeql repository, to live alongside similar libraries for all other programming languages supported by CodeQL. The open-source CodeQL queries, libraries, and extractor for analyzing codebases written in the Go programming language with GitHub's CodeQL code analysis tools can now be found in the new location. For more information, including guidance on migrating your existing workflows, see github/codeql-go#741.

Enterprise owners can see an overview of Dependabot alerts across the GitHub AE deployment, including a repository-centric view of application security risks, and an alert-centric view of all secret scanning and Dependabot alerts. The views are in beta and subject to change. For more information, see "Viewing the security overview."

Organization owners and security managers can view Dependabot alerts in an organization's Security tab. For more information, see "About the security overview."

Users can reopen a dismissed Dependabot alert using the web UI. This does not affect Dependabot pull requests or the GraphQL API. For more information, see "About Dependabot alerts."

Users can view fixed alerts from Dependabot with the GraphQL API. Users can also access and filter by state, as well as by unique numeric identifier, and filter by state on the vulnerability alert object. The following fields now exist for a RepositoryVulnerabilityAlert.

• number
• fixed_at
• fix_reason
• state

For more information, see "Objects" in the GraphQL API documentation.

Organization owners and security managers can use the security overview for an organization to view a repository-centric view of application security risks, or an alert-centric view of all code scanning, Dependabot, and secret scanning alerts for all repositories in an organization. For more information, see "About the security overview."

GitHub Actions can enforce dependency reviews on users' pull requests by scanning for dependencies, and will warn users about associated security vulnerabilities. The dependency-review-action action is supported by a new API endpoint that diffs the dependencies between any two revisions. For more information, see "About dependency review."

The dependency graph detects YAML files for GitHub Actions workflows. GitHub AE will display the workflow files within the Insights tab's dependency graph section. Repositories that publish actions will also be able to see the number of repositories that depend on that action from the "Used By" control on the repository homepage. For more information, see "About the dependency graph."

The dependency graph detects Cargo.toml and Cargo.lock files for Rust. These files will be displayed in the Dependency graph section of the Insights tab. Users will receive Dependabot alerts and updates for vulnerabilities associated with their Rust dependencies. Package metadata, including mapping packages to repositories, will be added at a later date. For more information, see "About the dependency graph."

If GitHub Connect is enabled for GitHub AE, users can contribute an improvement to a security advisory in the GitHub Advisory Database. To contribute, click Suggest improvements for this vulnerability while viewing an advisory's details. For more information, see the following articles.

• "Managing GitHub Connect"
• "Browsing security vulnerabilities in the GitHub Advisory Database" in the GitHub Enterprise Cloud documentation
• "About GitHub Security Advisories for repositories" in the GitHub Enterprise Cloud documentation
• "Editing security advisories in the GitHub Advisory Database" in the GitHub Enterprise Cloud documentation

People who maintain self-hosted runners now have more control over when the runners perform software updates. If you specify the --disableupdate flag to the runner, the runner will not try to perform an automatic software update if a newer version of the runner software is available. This allows updates to the self-hosted runner on a custom schedule, and is especially convenient if a self-hosted runner is in a container. For compatibility with the GitHub Actions service, runner software must be updated within 30 days of a new runner version being available. For more information about installation of the latest runner version, see the installation instructions for the latest release in actions/runner.

When using GitHub Actions, to reduce the risk of merging a change that was not reviewed by another person into a protected branch, enterprise owners and repository administrators can prevent Actions from creating pull requests. Organization owners could previously enable this restriction. For more information, see the following articles.

• "Enforcing policies for GitHub Actions in your enterprise"
• "Disabling or limiting GitHub Actions for your organization"
• "Managing GitHub Actions settings for a repository"

Organization owners can increase the security of CI/CD workflows on self-hosted runners by choosing which workflows can access a runner group. Previously, any workflow in a repository, such as an issue labeler, could access the self-hosted runners available to an organization. For more information, see "Managing access to self-hosted runners using groups" and the GitHub Blog.

Organization owners can control whether GitHub Actions can approve pull requests. This feature protects against a user using GitHub Actions to satisfy the "Required approvals" branch protection requirement and merging a change that was not reviewed by another user. To prevent breaking existing workflows, Allow GitHub Actions reviews to count towards required approval is enabled by default. Organization owners can disable the feature in the organization's GitHub Actions settings. For more information, see "Disabling or limiting GitHub Actions for your organization."

Users can write a single workflow triggered by workflow_dispatch and workflow_call, and use the inputs context to access input values. Previously, workflow_dispatch inputs were in the event payload, which increased difficulty for workflow authors who wanted to write one workflow that was both reusable and manually triggered. For workflows triggered by workflow_dispatch, inputs are still available in the github.event.inputs context to maintain compatibility. For more information, see "Contexts."

Users can now re-run only failed jobs or an individual job in a GitHub Actions workflow run. For more information, see "Re-running workflows and jobs."

To summarize the result of a job, users can generate Markdown and publish the contents as a job summary. For example, after running tests with GitHub Actions, a summary can provide an overview of passed, failed, or skipped tests, potentially reducing the need to review the full log output. For more information, see "Workflow commands for GitHub Actions."

To more easily diagnose job execution failures during a workflow re-run, users can enable debug logging, which outputs information about a job's execution and environment. For more information, see "Re-running workflows and jobs" and "Using workflow run logs."

If you manage self-hosted runners for GitHub Actions, you can ensure a consistent state on the runner itself before and after a workflow run by defining scripts to execute. By using scripts, you no longer need to require that users manually incorporate these steps into workflows. Pre- and post-job scripts are in beta and subject to change. For more information, see "Running scripts before or after a job."

Enterprise owners can configure a policy to control whether people's usernames or full names are displayed within internal repositories. For more information, see "Enforcing repository management policies in your enterprise."

Organization owners can pin a repository to an organization's profile directly from the repository via the new Pin repository dropdown.

While creating a fork, users can customize the fork's name. For more information, see "Fork a repo."

Users can delete a branch that's associated with an open pull request. For more information, see "Creating and deleting branches within your repository."

CODEOWNERS has received the following improvements.

• Syntax errors are now surfaced when viewing a CODEOWNERS file from the web UI. Previously, when a line in a CODEOWNERS file had a syntax error, the error would be ignored or in some cases cause the entire CODEOWNERS file to not load. GitHub Apps and Actions can access the same list of errors using new REST and GraphQL APIs. For more information, see "Repositories" in the REST API documentation or "Objects" in the GraphQL API documentation.
• After someone creates a new pull request or pushes new changes to a draft pull request, any code owners that will be requested for review are now listed in the pull request under "Reviewers". This feature gives you an early look at who will be requested to review once the pull request is marked ready for review.
• Comments in CODEOWNERS files can now appear at the end of a line, not just on dedicated lines.

For more information, see "About code owners."

When a user renames or moves a file to a new directory, if at least half of the file's contents are identical, the commit history indicates that the file was renamed, similar to git log --follow. For more information, see the GitHub Blog.

Users can require a successful deployment of a branch before anyone can merge the pull request associated with the branch. For more information, see "About protected branches" and "Managing a branch protection rule."

Repository administrators can now configure tag protection rules to protect a repository's tags. Once protected by a tag protection rule, tags matching a specified name pattern can only be created and deleted by users with maintain or admin access to the repository. For more information, see "Configuring tag protection rules."

Users can ignore revisions in the blame view by creating a .git-blame-ignore-revs file in the root of a repository. For more information, see "Viewing a file."

Users can grant exceptions to GitHub Apps for any branch protection rule that supports exceptions. For more information, see "About apps" and "Managing a branch protection rule."

For public GPG signing keys that are expired or revoked, GitHub AE verifies Git commit signatures and show commits as verified if the user made the commit while the key was still valid. Users can also upload expired or revoked GPG keys. For more information, see "About commit signature verification."

To affirm that a commit complies with the rules and licensing governing a repository, organization owners and repository administrators can now require developers to sign off on commits made through the web interface. For more information, see "Managing the commit signoff policy for your organization" and "Managing the commit signoff policy for your repository."

Using the file tree located in the Files changed tab of a pull request, users can navigate modified files, understand the size and scope of changes, and focus reviews. The file tree appears if a pull request modifies at least two files, and the browser window is sufficiently wide. For more information, see "Reviewing proposed changes in a pull request" and "Filtering files in a pull request."

Users can default to using pull requests titles as the commit message for all squash merges. For more information, see "Configuring commit squashing for pull requests."

The Update branch button on the pull request page lets users update a pull request's branch with the latest changes from the base branch. This is useful for verifying that the pull request's changes are compatible with the current version of the base branch before you merge. Two enhancements provide more ways to keep a branch up to date.

• When a pull request's topic branch is out of date with the base branch, users can update the branch by rebasing on the latest version of the base branch. Rebasing applies the changes from the topic branch onto the latest version of the base branch, resulting in a branch with a linear history since no merge commit is created. To update by rebasing, click the drop-down menu next to the Update Branch button, click Update with rebase, and then click Rebase branch. Previously, Update branch performed a traditional merge that always resulted in a merge commit in your pull request branch. This option is still available, but now users have the choice. For more information, see "Keeping your pull request in sync with the base branch."
• A new repository setting allows the Update branch button to always be available when a pull request's topic branch is not up to date with the base branch. Previously, this button was only available when the Require branches to be up to date before merging branch protection setting was enabled. People with admin or maintainer access can manage the Always suggest updating pull request branches setting from the Pull Requests section in repository settings. For more information, see "Managing suggestions to update pull request branches."

When viewing the details for a particular release, users can see the creation date for each release asset. For more information, see "Viewing your repository's releases and tags."

While creating a release with automatically generated release notes, users can see the tag identified as the previous release, then choose to select a different tag to specify as the previous release. For more information, see "Automatically generated release notes."

Gists now only show the 30 most recent comments when first displayed. Users can click Load earlier comments... to view more. This allows gists that have many comments to appear more quickly. For more information, see "Editing and sharing content with gists."

Editing Markdown in the web interface has been improved.

• After a user selects text and pastes a URL, the selected text will become a Markdown link to the pasted URL.
• When a user pastes spreadsheet cells or HTML tables, the resulting text will render as a table.
• When a user copies text containing links, the pasted text will include the link as a Markdown link.

For more information, see "Basic writing and formatting syntax."

When editing a Markdown file in the web interface, clicking the Preview tab will automatically scroll to the place in the preview that you were editing. The scroll location is based on the position of the cursor before clicking the Preview tab.

A light high-contrast theme, with greater contrast between foreground and background elements, is now available. For more information, see "Managing your theme settings."

Lists of repositories owned by a user or organization now have an additional filter option, "Templates", making it easier to find template repositories.

GitHub AE can display several common image formats, including PNG, JPG, GIF, PSD, and SVG, and provides several ways to compare differences between versions. When reviewing added or changed images in a pull request, previews of those images are now shown by default. Previously, users would see a message indicating that binary files could not be shown, and would need to toggle the "Display rich diff" option. For more information, see "Working with non-code files."

Settings pages for users, organizations, repositories, and teams have been redesigned, grouping similar settings pages into sections for improved information architecture and discoverability. For more information, see the GitHub Changelog.

Interactive elements in the web interface such as links and buttons show a visible outline when focused with a keyboard, to help users find the current position on a page. In addition, when focused, form fields have a higher contrast outline.

Focusing or hovering over a label now displays a tooltip with the label's description.

If a user refreshes the page while creating a new issue or pull request, the assignees, reviewers, labels, and projects will all be preserved.

To use the device authorization flow for OAuth and GitHub Apps, app authors must manually enable the feature. This change reduces the likelihood of apps being used in phishing attacks against GitHub AE users by ensuring integrators are aware of the risks and make a conscious choice to support this form of authentication. Users who own or manage an OAuth App or GitHub App and want to use the device flow can enable it for an app via the app's settings page. The device flow API endpoints will respond with status code 400 to apps that have not enabled this feature. For more information, see "Authorizing OAuth Apps."

Benutzerinnen mit Administratorzugriff auf ein Repository können besser verstehen, wer Zugriff auf das Repository hat und welche Zugriffsebene die einzelnen Benutzerinnen haben, und sie können den Zugriff auf das Repository einfacher verwalten. Benutzer*innen können z. B. die folgenden Aufgaben ausführen.

• Suchen nach allen Mitgliedern, Teams und Projektmitarbeiter*innen, die Zugriff auf das Repository haben
• Anzeigen, wenn Mitglieder über kombinierte Rollenzuweisungen verfügen, die ihnen direkt als Einzelpersonen oder indirekt über ein Team erteilt wurden: Eine neue Warnung zu „gemischten Rollen“ zeigt die Rolle der höchsten Ebene an, die Benutzer*innen gewährt wurde, wenn ihr Zugriff höher als die zugewiesene Rolle ist.

Weitere Informationen findest du unter Teams und Personen mit Zugriff auf dein Repository verwalten.

Unternehmensbesitzerinnen können jetzt zusätzliche Links zu Unternehmensmitgliedern und Projektmitarbeiterinnen in einer benutzerdefinierten Fußzeile anzeigen. Weitere Informationen findest du unter Konfigurieren von benutzerdefinierten Fußzeilen.

Benutzer*innen können einen Workflow mit einer einzigen Konfigurationszeile wiederverwenden. Wiederverwendbare Workflows sparen Zeit und Wartungsaufwand, da das Kopieren und Einfügen von Workflowdefinitionen zwischen Repositorys entfällt. Wiederverwendbare Workflows befinden sich in der Betaphase, und Änderungen sind vorbehalten. Weitere Informationen findest du unter Wiederverwenden von Workflows.

Die aktualisierte Verwaltungsoberfläche für selbstgehostete Runner vereinfacht die Verwaltung von Runnergruppen und bietet dir eine verbesserte Übersicht über deine Runner. Weitere Informationen findest du unter Informationen zu selbstgehosteten Runnern und Verwalten des Zugriffs auf selbstgehostete Runner mithilfe von Gruppen.

Dependabot teilt nun Geheimnisse mit GitHub Actions, wenn Dependabot eine Workflowausführung auslöst. Damit haben Benutzer*innen jetzt die Möglichkeit, Pulls aus privaten Paketregistrierungen in CI-Pipelines mithilfe der Geheimnisse von Dependabot auszuführen. Weitere Informationen findest du unter Verwalten verschlüsselter Geheimnisse für Dependabot.

Benutzer*innen können eine if-Bedingung verwenden, um zu verhindern, dass bestimmte Schritte in einer zusammengesetzten Aktion ausgeführt werden, wenn eine Bedingung nicht erfüllt ist. Wie bei Schritten, die in Workflows definiert sind, kannst du eine Bedingung mit jedem unterstützten Kontext und Ausdruck erstellen. Weitere Informationen zu zusammengesetzten Aktionen findest du unter Erstellen einer zusammengesetzten Aktion.

Benutzerinnen können Benutzerinnen eines Workflows die Arbeit vereinfachen, indem sie Eingabetypen für manuell ausgelöste Workflows angeben. Workflows unterstützen jetzt choice, boolean und environment. Weitere Informationen findest du unter Workflowsyntax für GitHub Actions.

Der erste verfügbare übereinstimmende Runner auf Repository-, Organisations- oder Unternehmensebene führt in allen Fällen jeden Auftrag aus. Dadurch können Aufträge jetzt deutlich schneller an selbstgehostete Runner gesendet werden. Dies gilt insbesondere für Organisationen und Unternehmen mit einer großen Anzahl von selbstgehosteten Runnern. Bei der Ausführung eines Auftrags, für den ein selbstgehosteter Runner erforderlich war, hat GitHub Actions früher im Repository, in der Organisation und im Unternehmen (in dieser Reihenfolge) nach selbstgehosteten Runnern gesucht. Weitere Informationen findest du unter Verwenden von selbstgehosteten Runnern in einem Workflow.

Benutzer*innen können angeben, dass eine JavaScript-Aktion in Node.js 16 ausgeführt werden soll, indem sie für runs.using den Wert node16 angeben. Node.js 16-Unterstützung ergänzt die bestehende Unterstützung für Node.js 12. Für Runner muss Version 2.285.0 oder höher des GitHub Actions-Runners installiert sein. Weitere Informationen findest du unter Metadatensyntax für GitHub Actions und im Repository actions/runner.

Benutzer*innen können Bezeichnungen für selbstgehostete Runner mithilfe der REST-API hinzufügen, auflisten und entfernen. Weitere Informationen findest du in der REST-API-Dokumentation unter Selbstgehostete Runner.

Benutzerinnen können die Sicherheit von Diensten und Tools, die mit Ruby erstellt wurden, mithilfe der CodeQL-Codeüberprüfung verbessern. Für alle gängigen Ruby-Versionen bis einschließlich Version 3.02 kann CodeQL häufige Probleme erkennen, z. B. SQL-Einschleusung, ReDoS, Einschleusung von Betriebssystembefehlen und Argumenten, XML-Entitätserweiterung, reflektiertes Cross-Site Scripting (XSS), gespeichertes XSS, unsichere Deserialisierung und hartcodierte Anmeldeinformationen. Um die Ruby-Analyse zu aktivieren, müssen Benutzerinnen eine vorhandene Workflowdatei für die CodeQL-Codeüberprüfung aktualisieren. Die Ruby-Unterstützung für CodeQL befindet sich in der Betaphase und kann geändert werden. Weitere Informationen findest du unter Konfigurieren der Codeüberprüfung und in der CodeQL-Dokumentation. Weitere Informationen zur Codeüberprüfung mit CodeQL findest du unter Informationen zur Codeüberprüfung mit CodeQL.

Die Python-Analyse von CodeQL unterstützt zusätzliche Frameworks und kann mehr potenzielle Quellen für nicht vertrauenswürdige Benutzerdaten, Schritte, durch die diese Daten fließen, und potenziell gefährliche Senken erkennen, in die diese Daten gelangen könnten. Weitere Informationen findest du unter Unterstützte Sprachen und Frameworks in der CodeQL-Dokumentation.

Benutzer*innen können mithilfe der REST-API Commitdetails von Geheimnissen abrufen, die bei Überprüfungen privater Repositorys erkannt wurden. Der neue Endpunkt gibt Details zum ersten Vorkommen eines Geheimnisses innerhalb einer Datei zurück (einschließlich Position des Geheimnisses und Commit-SHA). Weitere Informationen findest du in der REST-API-Dokumentation unter Informationen zur Geheimnisüberprüfung und Geheimnisüberprüfung.

Die Codeüberprüfungs-API bietet die folgenden Verbesserungen.

• Warnungen enthalten den Zeitstempel fixed_at, der den ersten Zeitpunkt angibt, zu dem die Warnung in einer Analyse nicht mehr ermittelt wurde. Benutzer*innen können diese Daten verwenden, um besser zu verstehen, wann Warnungen der Codeüberprüfung behoben wurden.
• Benutzer*innen können die wichtigsten Warnungsergebnisse mithilfe von sort und direction nach created, updated oder number sortieren. Weitere Informationen findest du in der REST-API-Dokumentation unter Codeüberprüfung.
• Die Warnungen und die Antworten vom Warnungsendpunkt enthalten einen Last-Modified-Header. Weitere Informationen findest du in der Mozilla-Dokumentation unter Last-Modified.
• SARIF-Antworten für Codeüberprüfungsanalysen umfassen relatedLocations. Diese können Standorte enthalten, die nicht der primäre Standort der Warnung sind. Ein Beispiel findest du in der SARIF-Spezifikation. Weitere Informationen findest du in der REST-API-Dokumentation unter Codeüberprüfung.
• Das Warnungsregelobjekt der Webhookantwort enthält help- und tags-Daten. Weitere Informationen findest du unter Webhookereignisse und Nutzdaten.

Organisationsbesitzerinnen und Sicherheitsmanagerinnen können mithilfe der REST-API die Ergebnisse der Geheimnisüberprüfung privater Repositorys auf Unternehmensebene abrufen. Weitere Informationen findest du in der REST-API-Dokumentation unter Informationen zur Geheimnisüberprüfung und Geheimnisüberprüfung.

Benutzer*innen können Dependabot-Warnungen über die GraphQL-API schließen. Weitere Informationen findest du in der GraphQL-API-Dokumentation unter Mutationen.

Das Abhängigkeitsdiagramm erkennt Python-Abhängigkeiten in Repositorys, die den Poetry-Paket-Manager verwenden. Abhängigkeiten werden in den Manifestdateien pyproject.toml und poetry.lock erkannt. Weitere Informationen findest du unter Informationen zum Abhängigkeitsdiagramm.

Entwicklerinnen und Sicherheitsforscherinnen können mit CodeQL Datenbanken erstellen und Code auf Computern analysieren, die über Apple Silicon-Chips wie den M1 verfügen. Sowohl die CodeQL-CLI als auch die VS Code-Erweiterung unterstützen Apple Silicon. Um die CodeQL-CLI oder die VS Code-Erweiterung auf Apple Silicon verwenden zu können, müssen die Xcode-Befehlszeilen-Entwicklertools und Rosetta 2 installiert werden. Die CodeQL-Unterstützung für Apple Silicon befindet sich in der Betaphase und kann geändert werden.

• Weitere Informationen zur Konfiguration der CodeQL-CLI auf unterstützten Plattformen findest du in der CodeQL-Dokumentation unter Verwenden der CodeQL-CLI.
• Weitere Informationen zu CodeQL findest du in der CodeQL-Dokumentation unter Informationen zu CodeQL und unter Informationen zur Codeüberprüfung.

Benutzerinnen der CodeQL-CLI-Versionen 2.7.1 und höher können Abfragehilfe in SARIF-Dateien als Markdown einschließen. Der Hilfetext wird dann auf der Benutzeroberfläche zur Codeüberprüfung von GitHub AE angezeigt. Benutzerinnen können die Abfragehilfe als Markdowndatei mit demselben Namen wie die zugehörige Abfragedatei einschließen. Wenn deine Abfragedatei beispielsweise MyCustomQuery.ql heißt, lautet der Name der Abfragehilfedatei MyCustomQuery.md. Weitere Informationen zum Erstellen einer Abfragehilfe für benutzerdefinierte CodeQL-Abfragen findest du im Leitfaden zur Abfragehilfe.

• Benutzer*innen, die nicht GitHub Actions für CI/CD und Codeüberprüfungen verwenden, müssen beim Ausführen des Befehls codeql database analyze das Einfügen der Abfragehilfe angeben, indem sie das --sarif-add-query-help-Flag einschließen. Weitere Informationen findest du in der CodeQL-Dokumentation unter Analysieren von Datenbanken mit der CodeQL-CLI.

Benutzerinnen können alle Repositorys abbestellen, die bestimmten Benutzerinnen oder Organisationen gehören. Weitere Informationen findest du unter Verwalten deiner Abonnements.

Organisationsbesitzer*innen können E-Mail-Benachrichtigungen abbestellen, wenn Repositorys, die ihren Organisationen gehören, neue Bereitstellungsschlüssel hinzugefügt werden. Weitere Informationen findest du unter Konfigurieren von Benachrichtigungen.

Die Betreffzeile für E-Mail-Benachrichtigungen für Issues und Pull Requests enthält „(Issue #NUMMER)“ oder „(PR #NUMMER)“, damit Benutzer*innen einfacher zwischen den beiden Benachrichtigungstypen unterscheiden können.

Der Link Auf GitHub anzeigen unten in E-Mail-Benachrichtigungen ist in Gmail nicht mehr standardmäßig ausgeblendet.

Organisationsmitglieder können jetzt eine Liste der Unternehmensbesitzerinnen anzeigen. Wenn ein Organisationsmitglied auf eine Aufforderung zur Kontaktaufnahme mit Unternehmensbesitzerinnen stößt, wird es über einen Link zu dieser Liste weitergeleitet. Auf die Liste kann auch über das Organization-Objekt der GraphQL-API am enterpriseOwners-Endpunkt zugegriffen werden. Weitere Informationen findest du unter Anzeigen der Rollen von Personen in einer Organisation.

Benutzer*innen mit Administratorzugriff auf ein Repository können Branches umbenennen, die durch Branchschutzregeln geschützt sind. Weitere Informationen findest du unter Umbenennen von Branches und Verwalten von Branchschutzregeln.

Anstatt zuzulassen, dass alle oder keine Benutzer*innen Pushvorgänge ausführen, können Personen mit Administratorzugriff auf ein Repository erzwingen, wer in das Repository pushen kann. Weitere Informationen findest du unter Informationen zu geschützten Branches und Verwalten von Branchschutzregeln.

Benutzer*innen mit Administratorzugriff auf ein Repository können erzwingen, dass alle Änderungen an einem geschützten Branch über einen Pull Request vorgenommen werden, ohne dass Reviews erforderlich sind. Weitere Informationen findest du unter Informationen zu geschützten Branches und Verwalten von Branchschutzregeln.

Benutzerinnen mit Administratorzugriff auf ein Repository können bestimmten Benutzerinnen und Teams erlauben, Pull Request-Anforderungen zu umgehen. Weitere Informationen findest du unter Informationen zu Branchschutzregeln.

Benutzer*innen können jetzt Präfixe aus einem einzelnen Zeichen für benutzerdefinierte automatische Verknüpfungen verwenden. Außerdem sind bei Präfixen für automatische Verknüpfungen jetzt alphanumerische Zeichen sowie die folgenden Zeichen zulässig: ., -, _, +, =, :, / und #. Weitere Informationen findest du unter Konfigurieren von Autolinks zum Verweisen auf externe Ressourcen.

Benutzerinnen können Nur angeforderte Teammitglieder benachrichtigen unabhängig von Automatische Zuweisung aktivieren in den Codeüberprüfungseinstellungen des Teams aktivieren, sodass Benutzerinnen das Team zur Überprüfung anfordern können, ohne jedoch jedes Mal das gesamte Team unnötigerweise zu benachrichtigen. Weitere Informationen findest du unter Verwalten von Code-Review-Einstellungen für dein Team.

Die Benutzeroberfläche für Releases wurde verbessert und bietet mehr Klarheit darüber, was in einem bestimmten Release enthalten ist und welche Mitwirkenden Anerkennung für das Release erhalten haben. Die Paginierung wurde verbessert, und es sind neue Suchfunktionen verfügbar.

Benutzer*innen können automatisch Versionshinweise generieren, die eine Zusammenfassung aller Pull Requests für das jeweilige Release enthalten. Weitere Informationen findest du unter Automatisch generierte Versionshinweise.

Benutzer*innen können Renderings von Markdowndateien in Gists in einer Vorschau anzeigen. Beim Erstellen oder Bearbeiten einer Gist-Datei mit der Markdowndateierweiterung (.md) kannst du jetzt auf der Registerkarte Vorschau oder Vorschauänderungen ein Markdownrendering der Dateiinhalte anzeigen. Weitere Informationen zu Gists findest du unter Bearbeiten und Freigeben von Inhalten mit Gists.

Benutzer*innen können eine Schriftart mit fester Breite in Markdownfeldern verwenden (z. B. in Kommentaren zu Issues und Pull Requests). Weitere Informationen findest du unter Informationen zum Schreiben und Formatieren auf GitHub.

Benutzer*innen können das Design angeben, für das ein Bild in Markdown angezeigt wird. Weitere Informationen findest du unter Grundlegende Schreib- und Formatierungssyntax.

Benutzer*innen können schnell einen Markdownlink erstellen, während sie Text in Markdownfeldern wie Kommentaren zu Issues oder Pull Requests bearbeiten, indem sie Text auswählen und dann eine URL einfügen.

HTML-Links, die Benutzer*innen in Markdownfelder einfügen, werden automatisch in Markdownlinks konvertiert. Um HTML-Links als reinen Text einzufügen, drückst du ⌘/STRG + UMSCHALT + V.

Von rechts nach links geschriebene Sprachen werden nativ in Markdowndateien und Kommentaren in Issues und Pull Requests und Diskussionen unterstützt.

Benutzer*innen können eine bevorzugte Tabulatorgröße festlegen. Der gesamte Code in GitHub AE mit Tabulatoren wird dann mithilfe der bevorzugten Tabulatorgröße gerendert. Weitere Informationen findest du unter Verwalten der Renderingeinstellungen für die Tabulatorgröße.

Benutzer*innen können Tastenkombinationen mit den neuen Barrierefreiheitseinstellungen von GitHub AE verwalten und Tastenkombinationen deaktivieren, die nur einzelne Zeichen verwenden, z. B. s, g c und . (der Punkt). Weitere Informationen findest du unter Verwalten von Barrierefreiheitseinstellungen.

Um sicherzustellen, dass alle Änderungen von der beabsichtigten App überprüft werden, können Benutzerinnen jetzt steuern, von welcher GitHub-App eine erforderliche Statusüberprüfung bereitgestellt wird. Wenn dann ein Status von einer anderen App oder über einen Commitstatus von anderen Benutzerinnen bereitgestellt wird, wird der Merge verhindert. Vorhandene erforderliche Statusüberprüfungen akzeptieren weiterhin den Status einer beliebigen App, können jedoch aktualisiert werden, damit sie nur noch den Status einer bestimmten App akzeptieren. Neu hinzugefügte erforderliche Statusüberprüfungen werden standardmäßig auf die App festgelegt, die den Status zuletzt gemeldet hat. Du kannst jedoch eine andere App auswählen oder einer beliebigen App erlauben, den Status anzugeben. Weitere Informationen findest du unter Informationen zu geschützten Branches und Bearbeiten von Branchschutzregeln.

Organisationsbesitzerinnen und Benutzerinnen mit Administratorzugriff auf ein Repository können Webhooks auslösen, um auf Änderungen an Branchschutzregeln zu lauschen. Weitere Informationen findest du unter Webhookereignisse und Nutzdaten.

Die Codeüberprüfung und die Geheimnisüberprüfung sind für GitHub AE jetzt allgemein verfügbar. Weitere Informationen findest du unter Informationen zu Codescans und unter Informationen zur Geheimnisüberprüfung.

Benutzerdefinierte Muster für die Geheimnisüberprüfung sind jetzt allgemein verfügbar. Weitere Informationen finden Sie unter Definieren von benutzerdefinierten Mustern für die Geheimnisüberprüfung.

Jetzt findest du alle Codeüberprüfungswarnungen im Zusammenhang mit deinem Pull Request mithilfe des neuen Pull Request-Filters auf der Seite mit den Codeüberprüfungswarnungen. Die Seite mit den Pull Request-Überprüfungen zeigt die Warnungen an, die durch einen Pull Request eingeführt wurden, jedoch keine vorhandenen Warnungen für den Pull Request-Branch. Der neue Link „Alle Branchwarnungen anzeigen“ auf der Seite „Überprüfungen“ leitet dich auf die Seite mit Codeüberprüfungswarnungen, auf die der spezifische Pull Request-Filter bereits angewendet wurde, sodass alle Warnungen im Zusammenhang mit deinem Pull Request angezeigt werden. Dies kann hilfreich sein, um zahlreiche Warnungen zu verwalten und detailliertere Informationen für einzelne Warnungen anzuzeigen. Weitere Informationen findest du unter Verwalten von Codeüberprüfungswarnungen für dein Repository.

GitHub Advanced Security bietet jetzt eine Ansicht auf Organisationsebene für die Anwendungssicherheitsrisiken, die von der Codeüberprüfung, Dependabot und der Geheimnisüberprüfung erkannt werden. Die Sicherheitsübersicht zeigt den Aktivierungsstatus der Sicherheitsfeatures für jedes Repository sowie die Anzahl der erkannten Warnungen an.

Darüber hinaus listet die Sicherheitsübersicht alle Warnungen der Geheimnisüberprüfung auf Organisationsebene auf. Ähnliche Ansichten für Dependabot und Codeüberprüfungswarnungen sind für zukünftige Releases geplant. Weitere Informationen findest du unter Informationen zur Sicherheitsübersicht.

Das Abhängigkeitsdiagramm ist jetzt in GitHub AE verfügbar. Mithilfe des Abhängigkeitsdiagramm kannst du die Open-Source-Software ermitteln, zu der Abhängigkeiten bestehen. Zu diesem Zweck werden die in Repositorys eingecheckten Abhängigkeitsmanifeste geparst. Weitere Informationen findest du unter Informationen zum Abhängigkeitsdiagramm.

Dependabot-Warnungen können dich jetzt über Sicherheitsrisiken in deinen Abhängigkeiten von GitHub AE benachrichtigen. Du kannst Dependabot-Warnungen aktivieren, indem du das Abhängigkeitsdiagramm aktivierst, GitHub Connect aktivierst und die Sicherheitsrisiken aus der GitHub Advisory Database synchronisierst. Dieses Feature befindet sich in der Betaversion und kann noch geändert werden. Weitere Informationen findest du unter Informationen zu Dependabot-Warnungen."

Nachdem du Dependabot-Warnungen aktiviert hast, erhalten Mitglieder deiner Organisation Benachrichtigungen, sobald der GitHub Advisory Database ein neues Sicherheitsrisiko mit Auswirkungen auf die Abhängigkeiten oder dem Manifest eine anfällige Abhängigkeit hinzugefügt wird. Mitglieder können die Benachrichtigungseinstellungen anpassen. Weitere Informationen findest du unter Konfigurieren von Benachrichtigungen für % data variables.product.prodname_dependabot_alerts %}.

Organisationen können Teams jetzt die Berechtigung zur Verwaltung von Sicherheitswarnungen und -einstellungen für all ihre Repositorys erteilen. Die Rolle „Sicherheits-Manager“ kann jedem Team zugewiesen werden. Dadurch erhalten die Teammitglieder die folgenden Berechtigungen.

• Lesezugriff auf alle Repositorys in der Organisation
• Schreibzugriff auf alle Sicherheitswarnungen in der Organisation
• Zugriff auf die Registerkarte „Sicherheit“ auf Organisationsebene
• Schreibzugriff auf Sicherheitseinstellungen auf Organisationsebene
• Schreibzugriff auf Sicherheitseinstellungen auf Repositoryebene

Weitere Informationen findest du unter Verwalten von Sicherheitsmanagern in deiner Organisation.

GitHub AE unterstützt jetzt kurzlebige selbstgehostete Runner (für Einzelaufträge) und den neuen Webhook workflow_job, um die Verwendung von Runnern für die Autoskalierung zu vereinfachen.

Kurzlebige Runner sind ideal für selbstverwaltete Umgebungen, in denen jeder Auftrag in einem bereinigten Image ausgeführt werden muss. Nach der Ausführung eines Auftrags wird die Registrierung der kurzlebigen Runner bei GitHub AE automatisch aufgehoben, sodass du nach dem Auftrag anstehende Verwaltungsvorgänge erledigen kannst.

Du kannst kurzlebige Runner mit dem neuen Webhook workflow_job kombinieren, um selbstgehostete Runner als Reaktion auf GitHub Actions-Auftragsanforderungen automatisch zu skalieren.

Weitere Informationen findest du unter Automatische Skalierung mit selbstgehosteten Runnern und Webhookereignisse und Nutzdaten.

Du kannst die Duplizierung in deinen Workflows reduzieren, indem du die Zusammensetzung für Verweise auf andere Aktionen verwendest. Zuvor konnten in YAML geschriebene Aktionen nur Skripts verwenden. Weitere Informationen findest du unter Erstellen einer zusammengesetzten Aktion.

Für die Verwaltung selbstgehosteter Runner auf Unternehmensebene sind keine persönlichen Zugriffstoken mit dem Bereich admin:enterprise mehr nötig. Stattdessen kann der neue Bereich new manage_runners:enterprise verwendet werden, um die Berechtigungen für Token einzuschränken. Token mit diesem Bereich können sich bei vielen REST-API-Endpunkten authentifizieren, um die selbstgehosteten Runner deines Unternehmens zu verwalten.

Jetzt kannst du über die REST-API programmgesteuert mit dem Überwachungsprotokoll interagieren. Bei der Weiterleitung von Überwachungsprotokollen ist es zwar möglich, Daten aufzubewahren, mit einem eigenen Toolkit zu analysieren und die Muster im Zeitverlauf zu bestimmen, doch die neue REST-API kann dabei behilflich sein, begrenzte Analysen für relevante Ereignisse durchzuführen, die erst kürzlich stattgefunden haben. Weitere Informationen findest du unter Überprüfen des Überwachungsprotokolls deiner Organisation.

Für neue und vorhandene persönliche Zugriffstoken kann jetzt ein Ablaufdatum festgelegt werden. GitHub AE sendet dir eine E-Mail, wenn ein bald ablaufendes Token erneuert werden muss. Abgelaufene Token können erneut generiert werden, wodurch du ein Tokenduplikat mit denselben Eigenschaften wie das Original erhältst. Wenn du ein Token mit der GitHub AE-API verwendest, wird dir der neue Header GitHub-Authentication-Token-Expiration mit dem Ablaufdatum des Tokens angezeigt. Dieses kannst du in Skripts verwenden, um beispielsweise bei Näherrücken des Ablaufdatums eine Warnmeldung zu protokollieren. Weitere Informationen findest du unter Erstellen eines persönlichen Zugriffstokens und Erste Schritte mit der REST-API.

Organisationsbesitzer können jetzt eine Liste der Personen mit Zugriff auf ein Repository im CSV-Format exportieren. Weitere Informationen findest du unter Anzeigen von Personen mit Zugriff auf dein Repository.

Neue Einstellungen zum Verwalten der Code Review-Zuweisung bieten Unterstützung beim Verteilen des Pull Request-Reviews eines Teams auf die Teammitglieder, damit Reviews nicht nur in der Zuständigkeit von einem oder zwei Teammitgliedern liegen.

• Untergeordnete Teammitglieder: Die Zuweisung ist nur zu direkten Teammitgliedern möglich. Zuvor konnten Teamreviewanforderungen direkten Teammitgliedern oder Mitgliedern untergeordneter Teams zugewiesen werden.
• Berücksichtigen vorhandener Anforderungen: Die automatische Zuweisung ist möglich, auch wenn eines oder mehrere Teammitglieder bereits angefragt wurden. Zuvor wurde ein Teammitglied, das bereits angefragt wurde, als eine der automatischen Reviewanforderungen des Teams gezählt.
• Teamreviewanforderung: Der Review bleibt dem Team zugewiesen, auch wenn neue Mitglieder zugewiesen wurden.

Weitere Informationen findest du unter Verwalten von Code-Review-Einstellungen für dein Team.

Für die GitHub AE-Webbenutzeroberfläche stehen zwei neue Designs zur Verfügung.

• Ein dunkles Design mit hohem Kontrast, bei dem der Kontrast zwischen Vorder- und Hintergrundelementen verstärkt wurde
• Ein helles und dunkles Design für Farbenblindheit, bei dem Farben wie Rot und Grün durch Orange und Blau ausgetauscht werden

Weitere Informationen findest du unter Verwalten deiner Designeinstellungen.

Jetzt kannst du die Fußnotensyntax in einem Markdownfeld verwenden, um auf relevante Informationen zu verweisen, ohne den Fließtext zu unterbrechen. Fußnoten werden als hochgestellte Links angezeigt. Klicke auf eine Fußnote, um zu dem Verweis zu springen, der in einem neuen Abschnitt im unteren Dokumentbereich angezeigt wird. Weitere Informationen findest du unter Grundlegende Schreib- und Formatierungssyntax.

Jetzt kannst du über die Webbenutzeroberfläche zwischen der Quellcodeansicht und der gerenderten Markdownansicht wechseln, indem du oben in einer Markdowndatei auf die Schaltfläche klickst, um die Quellunterschiede anzuzeigen. Zuvor musste die Blame-Ansicht verwendet werden, um die jeweiligen Zeilennummern in der Quelle einer Markdowndatei zu verknüpfen.

GitHub AE generiert jetzt auf Grundlage der Überschriften automatisch Inhaltsverzeichnisse für Wikis.

GitHub Actions ist eine leistungsstarke, flexible Lösung für CI/CD und die Workflowautomatisierung. Weitere Informationen findest du unter Grundlegendes zu GitHub Actions.

Beachte, dass in dein Unternehmen zwei Organisationen namens „GitHub Actions“ (@actions und @github) angezeigt werden, wenn GitHub Actions während dieses Updates aktiviert ist. Diese Organisationen werden von GitHub Actions vorausgesetzt. Als Erstellerinnen dieser Organisationen werden im Überwachungsprotokoll die Benutzerinnen @ghost und @actions aufgeführt.

GitHub Packages ist ein Pakethostingdienst, der nativ mit GitHub Actions, APIs und Webhooks integriert ist. Erstelle einen vollständigen DevOps-Workflow, der deinen Code, Continuous Integration und Bereitstellungslösungen umfasst. Während dieser Betaphase ist GitHub Packages für GitHub AE-Kunden kostenlos verfügbar.

GitHub Advanced Security ist als Betaversion verfügbar und enthält die Features „Codeüberprüfung“ und „Geheimnisüberprüfung“. Während dieser Betaphase sind GitHub Advanced Security-Features für GitHub AE-Kunden kostenlos verfügbar. Repository- und Organisationsadministrator*innen können GitHub Advanced Security in den Einstellungen auf der Registerkarte „Sicherheit und Analyse“ deaktivieren.

Weitere Informationen zu Codeüberprüfungen und Geheimnisüberprüfungen in GitHub Advanced Security findest du unter GitHub AE.

SCIM-Kunden (System for Cross-domain Identity Management) können nun Sicherheitsgruppen in Azure Active Directory mit GitHub-Teams synchronisieren. Sobald ein Team mit einer Sicherheitsgruppe verknüpft wurde, wird die Mitgliedschaft in GitHub AE automatisch aktualisiert, wenn Benutzer*innen zu ihrer zugewiesenen Sicherheitsgruppe hinzugefügt oder daraus entfernt werden.

GitHub-Listen zugelassener IP-Adressen bieten die Möglichkeit, Datenverkehr aus von Administrator*innen angegebenen IP-Bereichen zu filtern, die mit CIDR-Notation definiert sind. Diese Zulassungsliste wird unter „Sicherheit“ > „Einstellungen“ für ein ganzes Unternehmen oder ein Organisationskonto definiert. Der gesamte Datenverkehr, der an Ressourcen innerhalb des Unternehmenskontos und der Organisationen zugestellt werden soll, wird von den Zulassungslisten gefiltert. Diese Funktionalität wird zusätzlich zu der Möglichkeit bereitgestellt, Änderungen an Netzwerksicherheitsgruppen zu beantragen, die Datenverkehr an gesamten GHAE-Mandanten filtern.

Organisationsbesitzer*innen können die Veröffentlichung von GitHub Pages-Websites aus Repositorys in der Organisation nun deaktivieren. Die Veröffentlichung bestehender Websites wird dadurch nicht aufgehoben.

Repositorys, die GitHub Pages verwenden, können jetzt von jedem Branch aus erstellt und bereitgestellt werden.

Beim Verfassen eines Issues oder Pull Requests wird die Listensyntax für Aufzählungspunkte, Nummern und Aufgaben automatisch vervollständigt, wenn du return oder enter drückst.

Verzeichnisse in Repositorys können jetzt über die Repositoryseite gelöscht werden. Wenn du ein Verzeichnis öffnest. kannst du es über ein neues Hamburgermenü neben der Schaltfläche „Datei hinzufügen“ löschen.

Es ist jetzt einfacher und schneller möglich, auf Issues oder Pull Requests zu verweisen, indem du die Suche über mehrere Wörter nach dem „#“ durchführst.

Unternehmensinhaberinnen können jetzt Pflichtnachrichten veröffentlichen. Diese Nachrichten werden allen Benutzerinnen angezeigt, und sie müssen den Empfang bestätigen. In diesen Nachrichten können wichtige Informationen, Vertragsbedingungen oder Richtlinien kommuniziert werden.

Die GitHub App-Berechtigung für einen einzelnen Dateipfad unterstützt jetzt bis zu zehn Dateien.

Beim Konfigurieren einer GitHub App ist die Autorisierungsrückruf-URL ein Pflichtfeld. Nun erlauben wir dem/der Integrator*in, mehrere Rückruf-URLs anzugeben. GitHub AE verweigert die Autorisierung, wenn die Rückruf-URL der Anforderung nicht aufgeführt ist.

Durch einen neuen API-Endpunkt kann ein Benutzer-zu-Server-Token durch ein Benutzer-zu-Server-Token ausgetauscht werden, das auf bestimmte Repositorys beschränkt ist.

Im Überwachungsprotokoll werden jetzt Ereignisse zur Hochstufung von Teammitgliedern auf Teambetreuerinnen und Herabstufung von Teambetreuerinnen auf Teammitglieder protokolliert.

Der OAuth-Geräteautorisierungsflow wird jetzt unterstützt. Dies ermöglicht es allen CLI-Clients oder Entwicklungstools, sich mithilfe eines sekundären Systems zu authentifizieren.

Benutzer*innen können ihr Konto nicht mehr löschen, wenn die SCIM-Bereitstellung aktiviert ist.

Unternehmens- und Organisationsinhaberinnen können nun den Standardbranchnamen für neue Repositorys ändern. Unternehmensinhaberinnen können außerdem den Standardbranchnamen ihrer Wahl für alle Organisationen durchsetzen oder es einzelnen Organisationen erlauben, einen eigenen Standardbranchnamen zu wählen.

Diese Einstellungen haben keine Auswirkungen auf bestehende Repositorys, und ihr Standardbranchname wird nicht geändert.

Diese Änderung ist eine von vielen in GitHub, um Projekte und Maintainer*innen zu unterstützen, die ihren Standardbranch umbenennen möchten. Weitere Informationen findest du unter github/renaming.

Benutzer*innen können keine Sicherungs-E-Mail-Adresse in ihrem Profil angeben. Deine E-Mail-Adresse wird nur vom Identitätsanbieter festgelegt.

Die zweistufige Authentifizierung kann nicht mehr aktiviert werden, nachdem die Authentifizierung über deinen Identitätsanbieter eingerichtet wurde.

GitHub AE kann jetzt mit Azure Boards verbunden werden.

In den APIs fehlten Versionsheader. Diese wurden jetzt auf „GitHub AE“ festgelegt.

Links zur Dokumentation wurden korrigiert.

Die Konfiguration der Überwachungsprotokollweiterleitung innerhalb der Unternehmenseinstellungen schlug fehl.

Die Navigation zu Gists konnte zu einem 500-Fehler führen.

Die Support-E-Mail-Adresse oder -URL konnte nicht gespeichert werden. Nun wird sie nach wenigen Minuten gespeichert.

Organisationsvorlagen für Pull Request wurden nicht auf alle Pull Requests in der Organisation angewendet.