Skip to main content
Wir veröffentlichen regelmäßig Aktualisierungen unserer Dokumentation, und die Übersetzung dieser Seite ist möglicherweise noch nicht abgeschlossen. Aktuelle Informationen findest du in der englischsprachigen Dokumentation.
GitHub AE ist derzeit begrenzt freigegeben.

GitHub AE release notes

GitHub AE 3.6

GitHub begann mit dem Rollout dieser Änderungen für Unternehmen am February 16, 2023.

3.6.0: Features

  • Administrator experience

  • 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."

  • Identity and access management

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

  • Policies

  • 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."

  • GitHub Advanced Security

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

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

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

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

  • Dependabot

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

  • Code security

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

  • GitHub Actions

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

  • 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."

  • Community experience

  • 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."

  • Organizations

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

  • Repositories

  • 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."

  • Commits

  • 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."

  • Pull requests

  • 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."
  • Releases

  • 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."

  • Gist

  • 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."

  • Markdown

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

  • Accessibility

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

3.6.0: Changes

  • 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."

3.6.0: Deprecations

GitHub AE 3.4

GitHub begann mit dem Rollout dieser Änderungen für Unternehmen am October 25, 2022.

3.4.0: Features

  • Sicherheits- und Zugriffsverwaltung

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

  • Verwaltung

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

  • GitHub Actions

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

  • GitHub Advanced Security

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

  • Dependabot

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

  • Codesicherheit

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

  • 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 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.
  • Benachrichtigungen

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

  • Organisationen

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

  • Repositorys

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

  • Pull Requests

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

  • Releases

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

  • Gists

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

  • Markdown

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

  • Entwicklerumgebung

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

  • Zugriff

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

  • GitHub Apps

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

  • webhooks

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

3.4.0: Changes

  • Wenn Benutzer*innen zu einem privaten Repository eingeladen werden, wird beim Navigieren zur URL des privaten Repositorys anstelle eines 404-Fehlers eine Aufforderung angezeigt, dem Repository beizutreten.

  • Einladungen zu privaten Repositorys werden in den Benachrichtigungen angezeigt.

  • Wenn Benutzerinnen auf der Webbenutzeroberfläche @ eingeben, um andere Benutzerinnen zu erwähnen, werden Teilnehmende an Issues, Pull Requests und Diskussionen in der Liste höher eingestuft. Dadurch ist es wahrscheinlicher, dass die gesuchte Person zuerst aufgeführt wird.

  • Um zu verhindern, dass potenziell schädlicher Code in einem Workflow mit erhöhten Rechten ausgeführt wird, gelten die folgenden Änderungen für GitHub Actions-Workflows, die von Dependabot ausgelöst werden.

    • Workflowausführungen, die für die Ereignisse create, deployment und deployment_status ausgelöst werden, erhalten immer ein schreibgeschütztes Token, aber keine Geheimnisse. - Workflowausführungen, die für das pull_request_target-Ereignis bei Pull Requests ausgelöst werden und deren Basisreferenz von Dependabot erstellt wurde, erhalten immer ein schreibgeschütztes Token, aber keine Geheimnisse. - Workflowausführungen für die von Dependabot ausgelösten Ereignisse push und pull_request respektieren die in deinen Workflows angegebenen permissions. Die Standardtokenberechtigungen sind weiterhin schreibgeschützt.
  • Die Einstellung zum Ausblenden von Leerzeichenänderungen auf der Registerkarte Dateien geändert eines Pull Requests wird für alle Pull Requests beibehalten.

  • Die API „Aktualisieren eines Pull Requests-Branchs“ für GitHub-Apps erfordert jetzt, dass die aufrufenden Benutzerinnen oder Anwendungen Schreibzugriff auf das Headrepository haben. Wenn die Aufruferinnen keinen Schreibzugriff haben, gibt die API als Antwort 403 Forbidden zurück. Weitere Informationen findest du in der REST-API-Dokumentation unter Pulls.

GitHub AE 3.3

GitHub begann mit dem Rollout dieser Änderungen für Unternehmen am May 17, 2022.

3.3.0: Features

  • GitHub Advanced Security-Features sind allgemein verfügbar

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

  • Anzeigen aller Warnungen der Codeüberprüfung für einen Pull Request

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

  • Sicherheitsübersicht für Organisationen

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

    Screenshot der Sicherheitsübersicht

  • Abhängigkeitsdiagramm

  • 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

  • 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 %}.

  • Rolle „Sicherheits-Manager“ für Organisationen

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

  • Kurzlebige Runner und Webhooks zur automatischen Skalierung für GitHub Actions

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

  • Zusammengesetzte Aktionen für GitHub Actions

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

  • Neuer Tokenbereich für die Verwaltung selbstgehosteter Runner

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

  • Überwachungsprotokoll über REST-API zugänglich

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

  • Ablaufdaten für persönliche Zugriffstoken

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

  • Exportieren einer Liste der Personen mit Zugriff auf ein Repository

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

  • Verbesserte Verwaltung von Code Review-Zuweisungen

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

  • Neue Designs

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

  • Markdownverbesserungen

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

3.3.0: Changes

  • Leistung

  • Aufträge sowie das Laden von Seiten sind nun für Repositorys mit vielen Git-Verweisen deutlich schneller.

  • Verwaltung

  • Der Vorgang für den Identitätswechsel wurde verbessert. Für eine Identitätswechselsitzung muss nun eine Begründung vorliegen, und die Aktionen werden im Überwachungsprotokoll als von einem imitierten Benutzer ausgeführt aufgezeichnet. Der imitierte Benutzer empfängt zudem eine E-Mail-Benachrichtigung, dass ein Unternehmensbesitzer seine Identität angenommen hat. Weitere Informationen findest du unter Annehmen der Identität anderer Benutzer*innen.

  • GitHub Actions

  • Um Man-in-the-Middle-Angriffe durch Insider*innen bei Verwendung von Aktionen zu entschärfen, die durch GitHub Connect über GitHub AE in aufgelöst werden, wird der Aktionsnamespace (OWNER/NAME) von GitHub AE bei Verwendung außer Betrieb genommen. Durch die Außerbetriebnahme des Namespace wird verhindert, dass dieser Namespace in deinem Unternehmen erstellt wird. So wird sichergestellt, dass die Aktion von allen darauf verweisenden Workflows von heruntergeladen wird. Weitere Informationen findest du unter Aktivieren des automatischen Zugriffs auf GitHub Actions mit GitHub Connect.

  • Das Überwachungsprotokoll umfasst jetzt zusätzliche Ereignisse für GitHub Actions. GitHub AE zeichnet jetzt Überwachungsprotokolleinträge für die folgenden Ereignisse auf.

    • Ein selbstgehosteter Runner wird registriert oder entfernt.
    • Ein selbstgehosteter Runner wird einer Runnergruppe hinzugefügt oder aus einer Runnergruppe entfernt.
    • Eine Runnergruppe wird erstellt oder entfernt.
    • Eine Workflowausführung wird erstellt oder abgeschlossen.
    • Ein Workflowauftrag wird vorbereitet. Wichtig: Dieses Protokoll enthält die Liste der Geheimnisse, die dem Runner bereitgestellt wurden.

    Weitere Informationen findest du unter Sicherheitshärtung für GitHub Actions.

  • GitHub Advanced Security

  • Bei der Codeüberprüfung werden jetzt Warnungen, die in on:push-Workflows identifiziert werden, nach Möglichkeit so zugeordnet, dass sie in Pull Requests angezeigt werden. Bei den im Pull Request angezeigten Warnungen handelt es sich um Warnungen, die durch den Vergleich der vorhandene Analyse des Branchkopfs mit der Analyse für den Zielbranch, für den der Merge erfolgt, identifiziert werden. Hinweis: Wenn der Mergecommit des Pull Requests nicht verwendet wird, sind Warnungen möglicherweise weniger genau im Vergleich zu dem Ansatz, bei dem on:pull_request-Trigger verwendet werden. Weitere Informationen findest du unter Informationen zu Codeüberprüfungswarnungen mit CodeQL.

    Manche CI/CD-Systeme können so konfiguriert werden, dass eine Pipeline nur beim Pushen von Code an einen Branch ausgelöst wird, oder sie können sogar exklusiv für jeden Commit konfiguriert werden. Wenn eine solche Analysepipeline ausgelöst wird und die Ergebnisse in die SARIF-API hochgeladen werden, versucht die Codeüberprüfung, die Analyseergebnisse mit einem offenen Pull Request abzugleichen. Wenn ein offener Pull Request gefunden wird, werden die Ergebnisse wie oben beschrieben veröffentlicht. Weitere Informationen findest du unter Hochladen einer SARIF-Datei in GitHub.

  • GitHub AE erkennt jetzt Geheimnisse von weiteren Anbietern. Weitere Informationen findest du unter Muster bei der Geheimnisüberprüfung.

  • Pull Requests

  • Die Zeitachse und die Randleiste „Reviewer“ auf der Pull Request-Seite geben nun an, ob eine Reviewanforderung automatisch einem oder mehreren Teammitgliedern zugewiesen wurde, weil das jeweilige Team die Code Review-Zuweisung verwendet.

    Screenshot des Indikators für die automatische Zuweisung von Code Reviews

  • Du kannst Pull Request-Suchen jetzt nach Pull Requests filtern, für deren Review du angefragt wurdest, indem du Wartet auf deinen Review auswählst. Weitere Informationen findest du unter Durchsuchen von Issues und Pull Requests.

  • Wenn du den exakten Namen eines Branchs im Branchauswahlmenü angibst, wird das Ergebnis nun ganz oben in der Liste der übereinstimmenden Branches angezeigt. Zuvor konnte es passieren, dass exakt übereinstimmende Branchnamen ganz unten auf der Liste angezeigt wurden.

  • Bei der Anzeige eines Branchs mit einem zugehörigen offenen Pull Request enthält GitHub AE nun einen direkten Link zum Pull Request. Zuvor wurden Benutzer aufgefordert, über einen Branchvergleich beizutragen oder einen neuen Pull Request zu öffnen.

  • Die vollständigen, unformatierten Inhalte einer Datei können jetzt per Klick auf eine Schaltfläche in die Zwischenablage kopiert werden. Zuvor musste die Rohdatendatei geöffnet werden, und dann mussten alle Inhalte ausgewählt und kopiert werden. Um den Inhalt einer Datei zu kopieren, navigierst du zur Datei und klickst auf die Symbolleiste. Das Feature ist derzeit nur in manchen Browsern verfügbar.

  • Beim Anzeigen einer Datei, die bidirektionalen Unicode-Text enthält, wird jetzt eine Warnung angezeigt. Bidirektionaler Unicode-Text kann jetzt anders als er auf der Benutzeroberfläche angezeigt wird interpretiert oder kompiliert werden. Beispielsweise können ausgeblendete bidirektionale Unicode-Zeichen verwendet werden, um Textsegmente in einer Datei auszutauschen. Weitere Informationen zum Ersetzen dieser Zeichen findest du im GitHub-Änderungsprotokoll.

  • Repositorys

  • GitHub AE bietet jetzt erweiterte Unterstützung für CITATION.cff-Dateien. CITATION.cff-Dateien sind Nur-Text-Dateien mit von Personen und Computern lesbaren Informationen zum Zitieren. GitHub AE parst diese Informationen in praktische Formate wie APA und BibTeX, die von anderen kopiert werden können. Weitere Informationen findest du unter Informationen zu CITATION-Dateien.

  • Jetzt kannst du automatische Verknüpfungen in der Repository-API über den Endpunkt „Autolinks“ hinzufügen, löschen oder anzeigen. Weitere Informationen findest du unter Automatisch verknüpfte Verweise und URLs und Repositorys in der REST-API-Dokumentation.

  • Releases

  • Die Tagauswahlkomponente für GitHub-Releases ist jetzt eher ein Dropdownmenü als ein Textfeld. Weitere Informationen findest du unter Verwalten von Releases in einem Repository.

  • Markdown

  • Wenn du Dateien wie Bilder und Videos per Drag & Drop in einen Markdown-Editor einfügst, verwendet GitHub AE nun die Position des Mauszeigers anstelle der des Cursors beim Einfügen der Datei.


  • Vorschauversionen der REST-API sind nun offizielle Bestandteile der API. Für REST-API-Endpunkte sind keine Vorschauheader mehr erforderlich. Sie funktionieren jedoch weiterhin wie erwartet, wenn du eine ehemalige Vorschauversion weiterhin im Accept-Header einer Anforderung angibst.

GitHub AE 3.2

GitHub begann mit dem Rollout dieser Änderungen für Unternehmen am December 06, 2021.

3.2.0: Features

  • Administration

  • Customers with active or trial subscriptions for GitHub AE can now provision GitHub AE resources from the Azure Portal. Your Azure subscription must be feature-flagged to access GitHub AE resources in the portal. Contact your account manager or Vertriebsteam von GitHub to validate your Azure subscription's eligibility. For more information, see "Bereitstellen von GitHub AE."

  • GitHub Actions

  • GitHub Actions is now generally available for GitHub AE. GitHub Actions is a powerful, flexible solution for CI/CD and workflow automation. For more information, see "Grundlegendes zu GitHub Actions."

  • Self-hosted runners are the default type of runner system on GitHub AE, and are now generally available for GitHub Actions. With self-hosted runners, you can manage your own machines or containers for the execution of GitHub Actions jobs. For more information, see "About self-hosted runners" and "Selbst-gehostete Runner hinzufügen."

  • Environments, environment protection rules, and environment secrets are now generally available for GitHub Actions on GitHub AE. For more information, see "Verwenden von Umgebungen für die Bereitstellung."

  • GitHub Actions can now generate a visual graph of your workflow on every run. With workflow visualization, you can achieve the following.

    • View and understand complex workflows.
    • Track progress of workflows in real-time.
    • Troubleshoot runs quickly by easily accessing logs and jobs metadata.
    • Monitor progress of deployment jobs and easily access deployment targets.

    For more information, see "Using the visualization graph."

  • GitHub Actions now lets you control the permissions granted to the GITHUB_TOKEN secret. The GITHUB_TOKEN is an automatically generated secret that lets you make authenticated calls to the API for GitHub AE in your workflow runs. GitHub Actions generates a new token for each job and expires the token when a job completes. The token has write permissions to a number of API endpoints except in the case of pull requests from forks, which are always read. These new settings allow you to follow a principle of least privilege in your workflows. For more information, see "Authentication in a workflow."

  • GitHub Actions now supports skipping push and pull_request workflows by looking for some common keywords in your commit message.

  • GitHub CLI 1.9 and later allows you to work with GitHub Actions in your terminal. For more information, see the GitHub Blog.

  • Code scanning

  • Code scanning is now in beta for GitHub AE. For more information, see "About code scanning."

  • Secret scanning

  • You can now specify your own patterns for secret scanning with the beta of custom patterns on GitHub AE. You can specify patterns for repositories, organizations, and your entire enterprise. When you specify a new pattern, secret scanning searches a repository's entire Git history for the pattern, as well as any new commits. For more information, see "Defining custom patterns for secret scanning."

  • GitHub Connect

  • GitHub Connect is now available in beta for GitHub AE. GitHub Connect brings the power of the world's largest open source community to dein Unternehmen. You can allow users to view search results from on GitHub AE, show contribution counts from GitHub AE on, and use GitHub Actions from For more information, see "Managing connections between your enterprise accounts."

  • GitHub Packages

  • You can now delete any package or package version for GitHub Packages from GitHub AE's web UI. You can also undo the deletion of any package or package version within 30 days. For more information, see "Deleting and restoring a package."

  • The npm registry for GitHub Packages and no longer returns a time value in metadata responses, providing substantial performance improvements. GitHub will continue returning the time value in the future.

  • Audit logging

  • Events for pull requests and pull request reviews are now included in the audit log for both enterprises and organizations. These events help administrators better monitor pull request activity and ensure security and compliance requirements are being met. Events can be viewed from the web UI, exported as CSV or JSON, or accessed via REST API. You can also search the audit log for specific pull request events.

  • Additional events for GitHub Actions are now included in the audit log for both enterprises and organizations.

    • A workflow is deleted or re-run.
    • A self-hosted runner's version is updated.
  • Authentication

  • GitHub AE now officially supports Okta for SAML single sign-on (SSO) and user provisioning with SCIM. You can also map groups in Okta to teams on GitHub AE. For more information, see "Configuring authentication and provisioning for your enterprise using Okta" and "Mapping Okta groups to teams."

  • The format of authentication tokens for GitHub AE has changed. The change affects the format of personal access tokens and access tokens for OAuth Apps, as well as user-to-server, server-to-server, and refresh tokens for GitHub Apps. GitHub recommends updating existing tokens as soon as possible to improve security and allow secret scanning to detect the tokens. For more information, see "About authentication to GitHub" and "About secret scanning."

  • You can now authenticate SSH connections to GitHub AE using a FIDO2 security key by adding an SSH key to your account. SSH security keys store secret key material on a separate hardware device that requires verification, such as a tap, to operate. Storing the key on separate hardware and requiring physical interaction for your SSH key offers additional security. Since the key is stored on hardware and is non-extractable, the key can't be read or stolen by software running on the computer. The physical interaction prevents unauthorized use of the key since the security key will not operate until you physically interact with it. For more information, see "Generating a new SSH key and adding it to the ssh-agent."

  • Git Credential Manager (GCM) Core versions 2.0.452 and later now provide secure credential storage and multi-factor authentication support for GitHub AE. GCM Core with support for GitHub AE is included with Git for Windows versions 2.32 and later. GCM Core is not included with Git for macOS or Linux, but can be installed separately. For more information, see the latest release and installation instructions in the microsoft/Git-Credential-Manager-Core repository.

  • Notifications

  • You can now configure which events you would like to be notified about on GitHub AE. From any repository, select the Watch drop-down, then click Custom. For more information, see "Configuring notifications."

  • Issues and pull requests

  • With the latest version of Octicons, the states of issues and pull requests are now more visually distinct so you can scan status more easily. For more information, see the GitHub Blog.

  • You can now see all pull request review comments in the Files tab for a pull request by selecting the Conversations drop-down. You can also require that all pull request review comments are resolved before anyone merges the pull request. For more information, see "About pull request reviews" and "About protected branches." For more information about management of branch protection settings with the API, see "Branches" in the REST API documentation and "Mutations" in the GraphQL API documentation.

  • You can now upload video files everywhere you write Markdown on GitHub AE. Share demos, show reproduction steps, and more in issue and pull request comments, as well as in Markdown files within repositories, such as READMEs. For more information, see "Attaching files."

  • GitHub AE now shows a confirmation dialog when you request a review from a team with more than 100 members, allowing you to prevent unnecessary notifications for large teams.

  • When an issue or pull request has fewer than 30 possible assignees, the assignees control will list all potential users rather than a limited set of suggestions. This behavior helps people in small organizations to quickly find the right user. For more information about assigning users to issues and pull requests, see "Assigning issues and pull requests to other GitHub users."

  • You can now include multiple words after the # in a comment for an issue or pull request to further narrow your search. To dismiss the suggestions, press <kbd>Esc</kbd>.

  • To prevent the merge of unexpected changes after you enable auto-merge for a pull request, auto-merge is now disabled automatically when new changes are pushed by a user without write access to the repository. Users without write access can still update the pull request with changes from the base branch when auto-merge is enabled. To prevent a malicious user from using a merge conflict to introduce unexpected changes to the pull request, GitHub AE will disable auto-merge for the pull request if the update causes a merge conflict. For more information about auto-merge, see "Automatically merging a pull request."

  • People with maintain access can now manage the repository-level "Allow auto-merge" setting. This setting, which is off by default, controls whether auto-merge is available on pull requests in the repository. Previously, only people with admin access could manage this setting. Additionally, this setting can now by controlled using the "Create a repository" and "Update a repository" REST APIs. For more information, see "Managing auto-merge for pull requests in your repository."

  • The assignees selection for issues and pull requests now supports type ahead searching so you can find users in your organization faster. Additionally, search result rankings have been updated to prefer matches at the start of a person's username or profile name.

  • Repositories

  • When viewing the commit history for a file, you can now click to view the file at the specified time in the repository's history.

  • You can now use the web UI to synchronize an out-of-date branch for a fork with the fork's upstream branch. If there are no merge conflicts between the branches, GitHub AE updates your branch either by fast-forwarding or by merging from upstream. If there are conflicts, GitHub AE will prompt you to open pull request to resolve the conflicts. For more information, see "Syncing a fork."

  • You can now sort the repositories on a user or organization profile by star count.

  • The Repositories REST API's "compare two commits" endpoint, which returns a list of commits reachable from one commit or branch, but unreachable from another, now supports pagination. The API can also now return the results for comparisons over 250 commits. For more information, see the "Commits" REST API documentation and "Traversing with pagination."

  • When you define a submodule in dein Unternehmen with a relative path, the submodule is now clickable in the web UI. Clicking the submodule in the web UI will take you to the linked repository. Previously, only submodules with absolute URLs were clickable. Relative paths for repositories with the same owner that follow the pattern <code>../<em>REPOSITORY</em></code> or relative paths for repositories with a different owner that follow the pattern <code>../<em>OWNER</em>/<em>REPOSITORY</em></code> are supported. For more information about working with submodules, see Working with submodules on the GitHub Blog.

  • By precomputing checksums, the amount of time a repository is under lock has reduced dramatically, allowing more write operations to succeed immediately and improving monorepo performance.

  • Releases

  • You can now react with emoji to all releases on GitHub AE. For more information, see "About releases."

  • Themes

  • Dark and dark dimmed themes are now available for the web UI. GitHub AE will match your system preferences when you haven't set theme preferences in GitHub AE. You can also customize the themes that are active during day and night. For more information, see "Managing your theme settings."

  • Markdown

  • Markdown files in your repositories now automatically generate a table of contents in the header the file has two or more headings. The table of contents is interactive and links to the corresponding section. All six Markdown heading levels are supported. For more information, see "About READMEs."

  • code markup is now supported in titles for issues and pull requests. Text within backticks (`) will appear rendered in a fixed-width font anywhere the issue or pull request title appears in the web UI for GitHub AE.

  • While editing Markdown in files, issues, pull requests, or comments, you can now use a keyboard shortcut to insert a code block. The keyboard shortcut is <kbd>command</kbd> + <kbd>E</kbd> on a Mac or <kbd>Ctrl</kbd> + <kbd>E</kbd> on other devices. For more information, see "Basic writing and formatting syntax."

  • You can append ?plain=1 to the URL for any Markdown file to display the file without rendering and with line numbers. You can use the plain view to link other users to specific lines. For example, appending ?plain=1#L52 will highlight line 52 of a plain text Markdown file. For more information, "Creating a permanent link to a code snippet."

  • GitHub Apps

  • API requests to create an installation access token now respect IP allow lists for an enterprise or organization. Any API requests made with an installation access token for a GitHub App installed on your organization already respect IP allow lists. This feature does not currently consider any Azure network security group (NSG) rules that GitHub Support has configured for dein Unternehmen. For more information, see "Restricting network traffic to your enterprise," "Managing allowed IP addresses for your organization," and "Apps" in the REST API documentation.

  • Webhooks

  • You can now programmatically resend or check the status of webhooks through the REST API. For more information, see "Repositories," "Organizations," and "Apps" in the REST API documentation.

GitHub AE 3.1

GitHub begann mit dem Rollout dieser Änderungen für Unternehmen am March 03, 2021.

3.1.0: Features

  • GitHub Actions (Betaversion)

  • 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 (Betaversion)

  • 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 (Betaversion)

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

  • Verwalten von Teams über deinen Identitätsanbieter

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

  • IP-Zulassungslisten (Betaversion)

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

3.1.0: Changes

  • Entwickleränderungen

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

  • Verwaltungsänderungen

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

  • Ändern des Standardnamens von Branches

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

3.1.0: Bug fixes

  • Behebung von Programmfehlern

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

3.1.0: Known issues

  • Bekannte Probleme

  • Geografische Standortdaten werden nicht im Überwachungsprotokoll angezeigt. Standortinformationen können anderweitig auf der IP-Adresse des jeweiligen Ereignisses herausgelesen werden.

  • Die Verknüpfung mit GitHub Packages auf einer Repositoryseite führt zu einer falschen Suchseite, wenn das Repository keine Pakete enthält.