GitHub AE release notes

Unternehmensbesitzerinnen können Organisationen in GitHub AE über die Seite Organisationen des Unternehmenskontos als Mitglieder oder Besitzerinnen beitreten. Weitere Informationen findest du unter Verwalten deiner Rolle in einer Organisation im Besitz deines Unternehmens.

Benutzerdefinierte Repositoryrollen allgemein verfügbar. Mithilfe von benutzerdefinierten Repositoryrollen können Organisationsbesitzerinnen die den Benutzerinnen gewährten Zugriffsberechtigungen für ein Repository jetzt noch präziser steuern. Benutzerdefinierte Repositoryrollen werden auch von der REST-API vollständig unterstützt. Weitere Informationen findest du unter Verwalten von benutzerdefinierten Repositoryrollen für eine Organisation und Organisationen in der REST-API-Dokumentation.

Unternehmensbesitzerinnen können verhindern, dass Organisationsbesitzerinnen Projektmitarbeiterinnen zur Zusammenarbeit an GitHub AE-Repositorys einladen. Weitere Informationen findest du unter [Erzwingen einer Richtlinie zum Einladen von Projektmitarbeiterinnen zu Repositorys](/admin/policies/enforcing-policies-for-your-enterprise/enforcing-repository-management-policies-in-your-enterprise#enforcing-a-policy-for-inviting-collaborators-to-repositories).

Benutzer*innen können sich für den Empfang eines Webhookereignisses entscheiden, das ausgelöst wird, wenn jemand ein Feature zur Codesicherheit oder -analyse für eine Organisation oder ein Repository aktiviert oder deaktiviert. Weitere Informationen findest du in der folgenden Dokumentation.

• Webhookereignisse und Nutzdaten in der Webhookdokumentation
• Verwalten von Sicherheits- und Analyseeinstellungen für deine Organisation
• Verwalten von Sicherheits- und Analysefunktionen für dein Repository

Unternehmensbesitzerinnen und Benutzerinnen können Warnungen der Geheimnisüberprüfung und Umgehungen des Pushschutzes der Geheimnisüberprüfung in den Überwachungsprotokollen des Unternehmens und der Organisation und über die REST-API anzeigen. Weitere Informationen findest du in der folgenden Dokumentation.

• Schützen von Pushes mit der Geheimnisüberprüfung
• Überwachungsprotokollereignisse für dein Unternehmen
• Überprüfen des Auditprotokolls deiner Organisation
• Geheimnisüberprüfung in der REST-API-Dokumentation

Beim Verwalten von benutzerdefinierten Repositoryrollen können Organisationsbesitzer*innen ab sofort zwei neue Berechtigungen für die Geheimnisüberprüfung konfigurieren.

• Ergebnisse von Geheimnisüberprüfungen anzeigen
• Ergebnisse von Geheimnisüberprüfungen verwerfen oder erneut öffnen

Weitere Informationen findest du unter Verwalten benutzerdefinierter Repositoryrollen für eine Organisation.

Benutzerinnen können je nach Zugriff einen Probelauf mit benutzerdefinierten Überprüfungsmustern für Geheimnisse auf Unternehmens-, Organisations- oder Repositoryebene ausführen. Probeläufe ermöglichen Benutzerinnen, ihre Muster zu überprüfen und zu verfeinern, bevor sie diese veröffentlichen und Warnungen generieren. Du kannst ein Muster zusammenstellen und dann Speichern und Probelauf verwenden, um die Ergebnisse abzurufen. Die Überprüfungen dauern in der Regel nur wenige Sekunden, aber GitHub AE benachrichtigt Benutzer*innen auch per E-Mail, wenn die Ergebnisse des Probelaufs vorliegen. Weitere Informationen findest du unter Informationen zu Geheimnisüberprüfungen und Definieren benutzerdefinierter Muster für Geheimnisüberprüfungen.

Benutzer*innen können die Geheimnisüberprüfung für archivierte Repositorys über die Benutzeroberfläche oder die API aktivieren. Weitere Informationen findest du unter Informationen zur Geheimnisüberprüfung, Informationen zu archivierten Repositorys und Repositorys in der REST-API-Dokumentation.

Die Geheimnisüberprüfung verhindert die Offenlegung von Geheimnissen im Web-Editor. Weitere Informationen findest du unter Schützen von Pushs mit Geheimnisüberprüfung.

Die Codeüberprüfung erkennt ab sofort eine größere Anzahl von CWEs (Common Weakness Enumeration), und die CodeQL-Codeüberprüfung unterstützt die Standardsprachfunktionen in den folgenden Sprachversionen vollständig.

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

Weitere Informationen findest du im GitHub-Blog.

Organisationsbesitzerinnen und Sicherheitsmanagerinnen können Warnungen von der Codeüberprüfung auf der Registerkarte Sicherheit einer Organisation anzeigen. Weitere Informationen findest du unter Informationen zur Sicherheitsübersicht.

Auf der Seite für Codeüberprüfungswarnungen werden jetzt immer der Warnstatus und die Informationen für den Standardbranch angezeigt. Es gibt einen neuen Bereich „Betroffene Branches“ in der Seitenleiste, in dem du den Status der Warnung in anderen Branches sehen kannst. Wenn die Warnung nicht in deinem Standardbranch vorhanden ist, wird auf der Warnungsseite der Status „In Branch“ oder „In Pull Request“ für den Standort angezeigt, an dem die Warnung zuletzt ausgegeben wurde. Diese Verbesserung macht es einfacher, den Status von Warnungen zu verstehen, die in die Codebasis aufgenommen wurden. Weitere Informationen findest du unter Informationen zu Codeüberprüfungswarnungen. Die Seite mit der Warnungsliste wird nicht geändert und kann nach branch gefiltert werden. Du kannst die Codeüberprüfungs-API verwenden, um detailliertere Branchinformationen für Warnungen abzurufen. Weitere Informationen findest du in der REST-API-Dokumentation unter Codeüberprüfung.

Bei der Codeüberprüfung werden jetzt Details zur Analysequelle einer Warnung angezeigt. Wenn eine Warnung mehr als einen Analyseursprung hat, wird dies in der Seitenleiste „Betroffene Branches“ und in der Zeitleiste der Warnung angezeigt. Du kannst auf der Randleiste „Betroffene Branches“ mit dem Mauszeiger auf das Symbol des Analyseursprungs zeigen, um den Warnungsstatus in jedem Analyseursprung anzuzeigen. Wenn eine Warnung nur einen einzigen Analyseursprung hat, werden auf der Warnungsseite keine Informationen zum Analyseursprung angezeigt. Diese Verbesserungen erhöhen die Verständlichkeit von Warnmeldungen. Insbesondere können Benutzer*innen damit Warnungen mit mehreren Analyseursprüngen besser nachvollziehen. Dies ist besonders nützlich für Setups mit mehreren Analysekonfigurationen, wie z. B. Monorepositorys. Weitere Informationen findest du unter Informationen zu Codeüberprüfungswarnungen.

Benutzer*innen können beim Abrufen von Warnungen zur Geheimnisüberprüfung die Parameter sort und direction in der REST-API verwenden und die Warnungen nach den Feldern created und updated sortieren. Die neuen Parameter sind für alle deine GitHub AE-Bereitstellungen oder für einzelne Organisationen oder Repositorys verfügbar. Weitere Informationen findest du in der folgenden Dokumentation.

• Auflisten von Warnungen zur Geheimnisüberprüfung für ein Unternehmen
• Auflisten von Warnungen zur Geheimnisüberprüfung für eine Organisation
• Auflisten von Warnungen zur Geheimnisüberprüfung für ein Repository
• Geheimnisüberprüfung in der REST-API-Dokumentation

Benutzer*innen können einen Webhook abonnieren, der ausgelöst wird, wenn ein Geheimnis an einem neuen Standort erkannt wird. Das secret_scanning_alert_location-Webhookereignis enthält Standortdetails, z. B. den Commit-SHA, sowie die zugehörige Warnung für die Erkennung. Es wird ein Standort für jeden neuen Dateipfad erstellt, der das erkannte Geheimnis enthält. Weitere Informationen findest du unter Webhookereignisse und Nutzdaten.

Benutzer*innen können optional einen Kommentar hinzufügen, wenn sie eine Warnung zur Codeüberprüfung auf der Webbenutzeroberfläche oder über die REST-API schließen. Kommentare zum Schließen werden in der Zeitleiste des Ereignisses aufgeführt. Zudem können Benutzer einen Kommentar zum Schließen über die REST-API hinzufügen oder abrufen. Weitere Informationen findest du in der REST-API-Dokumentation unter Filtern von Codeüberprüfungswarnungen in Pull Requests und unter Codeüberprüfung.

Benutzer*innen können jetzt über die REST-API Codeüberprüfungswarnungen für eine Organisation abrufen. Dieser neue API-Endpunkt ergänzt den vorhandenen Endpunkt für Repositorys. Weitere Informationen findest du in der REST-API-Dokumentation unter Codeüberprüfung.

Der Inhalt des Repositorys github/codeql-go wurde in das Repository github/codeql verschoben, damit es neben ähnlichen Bibliotheken für alle übrigen Programmiersprachen zu finden ist, die von CodeQL unterstützt werden. Die Open-Source-CodeQL-Abfragen, -Bibliotheken und -Extraktionsfunktionen zur Analyse von Codebasen, die in der Go-Programmiersprache mit den CodeQL-Codeanalysetools von GitHub geschrieben wurden, befinden sich jetzt am neuen Speicherort. Weitere Informationen, einschließlich Leitfäden zur Migration deiner vorhandenen Workflows, findest du unter github/codeql-go#741.

Unternehmensbesitzer*innen können eine Übersicht über Dependabot-Warnungen für die GitHub AE-Bereitstellung anzeigen, einschließlich einer repositorybezogenen Ansicht von Risiken für die Anwendungssicherheit sowie einer warnungsbezogenen Ansicht aller Warnungen der Geheimnisüberprüfung und der Dependabot-Warnungen. Die Ansichten befinden sich in der Betaphase und können sich ändern. Weitere Informationen findest du unter Informationen zur Sicherheitsübersicht.

Organisationsbesitzerinnen und Sicherheitsmanagerinnen können Dependabot-Warnungen auf der Registerkarte Sicherheit einer Organisation anzeigen. Weitere Informationen findest du unter Informationen zur Sicherheitsübersicht.

Benutzer*innen können eine verworfene Dependabot-Warnung über die Webbenutzeroberfläche erneut öffnen. Dies hat keine Auswirkungen auf Dependabot-Pull Requests oder die GraphQL-API. Weitere Informationen findest du unter Informationen zu Dependabot-Warnungen."

Benutzerinnen können ab sofort mithilfe der GraphQL-API behobene Dependabot-Warnungen anzeigen. Außerdem können Benutzerinnen nach Zustand und eindeutigem numerischen Bezeichner suchen und filtern und nach dem Zustand des Objekts für die Sicherheitsrisikowarnung filtern. Die folgenden Felder sind jetzt für eine RepositoryVulnerabilityAlert verfügbar.

• number
• fixed_at
• fix_reason
• state

Weitere Informationen findest du in der GraphQL-API-Dokumentation unter Objekte.

Organisationsbesitzerinnen und Sicherheitsmanagerinnen können ab sofort die Sicherheitsübersicht für eine Organisation nutzen, um eine auf das Repository bezogene Ansicht der Anwendungssicherheitsrisiken oder eine warnungsbezogene Ansicht aller Warnungen von Codeüberprüfungen, Dependabot und Geheimnisüberprüfungen für alle Repositorys in einer Organisation anzuzeigen. Weitere Informationen findest du unter Informationen zur Sicherheitsübersicht.

GitHub Actions kann Abhängigkeitsüberprüfungen für Pull Requests von Benutzern durch das Überprüfen auf Abhängigkeiten erzwingen und informiert Benutzer über damit verbundene Sicherheitsrisiken. Die Aktion dependency-review-action wird von einem neuen API-Endpunkt unterstützt, der die Abhängigkeiten zwischen zwei beliebigen Revisionen vergleicht. Weitere Informationen findest du unter Informationen zur Abhängigkeitsprüfung.

Das Abhängigkeitsdiagramm erkennt YAML-Dateien für GitHub Actions-Workflows. GitHub AE zeigt die Workflowdateien im Abschnitt mit dem Abhängigkeitsdiagramm auf der Registerkarte Erkenntnisse an. Repositorys, die Aktionen veröffentlichen, können zudem über das Kontrollkästchen „Verwendet von“ auf der Startseite des Repositorys die Anzahl der Repositorys anzeigen, die von dieser Aktion abhängen. Weitere Informationen findest du unter Informationen zum Abhängigkeitsdiagramm.

Das Abhängigkeitsdiagramm erkennt die Dateien Cargo.toml und Cargo.lock für Rust. Diese Dateien werden im Abschnitt Abhängigkeitsdiagramm auf der Registerkarte Erkenntnisse angezeigt. Benutzer*innen erhalten Dependabot-Warnungen und Updates zu Sicherheitsrisiken im Zusammenhang mit ihren Rust-Abhängigkeiten. Paketmetadaten, einschließlich Zuordnungspaketen für Repositorys, werden zu einem späteren Zeitpunkt hinzugefügt. Weitere Informationen findest du unter Informationen zum Abhängigkeitsdiagramm.

Wenn GitHub Connect für GitHub AE aktiviert ist, können Benutzer*innen eine Verbesserung für eine Sicherheitsempfehlung in der GitHub Advisory Database beitragen. Klicke hierzu in den Details einer Empfehlung auf Verbesserungen für dieses Sicherheitsrisiko vorschlagen. Weitere Informationen findest du in den folgenden Artikeln.

• Verwalten von GitHub Connect
• Durchsuchen von Sicherheitsrisiken in der GitHub Advisory Database in der GitHub Enterprise Cloud-Dokumentation
• Informationen zu GitHub-Sicherheitsempfehlungen für Repositorys in der GitHub Enterprise Cloud-Dokumentation
• Bearbeiten von Sicherheitsempfehlungen in der GitHub Advisory Database in der GitHub Enterprise Cloud-Dokumentation

Personen, die selbstgehostete Runner verwalten, haben jetzt mehr Kontrolle darüber, wann die Runner Softwareupdates durchführen. Wenn du dem Runner das Flag --disableupdate zuweist, wird bei Verfügbarkeit einer neueren Version des Runners kein automatisches Softwareupdate durchgeführt. So kannst du den selbstgehosteten Runner nach deinem eigenen Zeitplan aktualisieren. Dies ist besonders praktisch, wenn sich dein selbstgehosteter Runner in einem Container befindet. Um Kompatibilität mit dem GitHub Actions-Dienst zu gewährleisten, musst die Runnersoftware innerhalb von 30 Tagen nach der Veröffentlichung einer neuen Runnerversion aktualisiert werden. Weitere Informationen zur Installation der neuesten Runnerversion findest du in den Installationsanweisungen für das neueste Release in actions/runner.

Um bei Verwendung von GitHub Actions das Risiko zu verringern, dass eine nicht von einer weiteren Person überprüfte Änderung in einen geschützten Branch gemergt wird, können Unternehmensbesitzer und Repositoryadministratoren die Erstellung von Pull Requests in Actions verhindern. Organisationsbesitzer konnten diese Einschränkung zuvor aktivieren. Weitere Informationen findest du in den folgenden Artikeln.

• Erzwingen von Richtlinien für GitHub Actions in deinem Unternehmen
• Deaktivieren oder Einschränken von GitHub Actions für deine Organisation
• Verwalten von GitHub Actions-Einstellungen für ein Repository

Organisationsbesitzer*innen können die Sicherheit von CI/CD-Workflows für selbstgehostete Runner erhöhen, indem sie festlegen, welche Workflows auf eine Runnergruppe zugreifen dürfen. Bisher konnte jeder Workflow in einem Repository, z. B. ein Workflow zur Kennzeichnung von Issues, auf die selbstgehosteten Runner zugreifen, die einer Organisation zur Verfügung stehen. Weitere Informationen findest du unter Verwalten des Zugriffs auf selbstgehostete Runner mithilfe von Gruppen und im GitHub-Blog.

Organisationsbeistzer*innen können steuern, ob GitHub Actions Pull Requests genehmigen kann. Mit dieser Funktion wird verhindert, dass ein Benutzer GitHub Actions nutzt, um die Anforderung erforderlicher Genehmigungen zum Branchschutz zu erfüllen und eine Änderung mergen kann, die nicht von einem anderen Benutzer geprüft wurde. Um Breaking Changes für vorhandene Workflows zu vermeiden, ist standardmäßig die Option Anrechnung von GitHub Actions-Reviews auf die erforderliche Genehmigung zulassen aktiviert. Organisationsbesitzer können das Feature in den GitHub Actions-Einstellungen der Organisation deaktivieren. Weitere Informationen findest du unter Deaktivieren oder Einschränken von GitHub Actions für deine Organisation.

Benutzerinnen können einen einzelnen Workflow schreiben, der von workflow_dispatch und workflow_call ausgelöst wird, und den inputs-Kontext verwenden, um auf Eingabewerte zuzugreifen. Zuvor befanden sich die workflow_dispatch-Eingaben in den Ereignisnutzdaten. Dies machte es für Workflowautorinnen schwieriger, einen Workflow zu schreiben, der sowohl wiederverwendbar als auch manuell auslösbar war. Für Workflows, die mit workflow_dispatch ausgelöst werden, sind Eingaben weiterhin im github.event.inputs-Kontext verfügbar, um die Kompatibilität zu gewährleisten. Weitere Informationen findest du unter Kontexte.

Ab sofort können Benutzer*innen nur die fehlerhaften Aufträge oder einen einzelnen Auftrag in einem GitHub Actions-Workflow erneut ausführen. Weitere Informationen findest du unter Erneutes Ausführen von Workflows und Aufträgen.

Um das Ergebnis eines Auftrags zusammenzufassen, können Benutzer Markdown generieren und die Inhalte als Auftragszusammenfassung veröffentlichen. Beispielsweise kann eine Zusammenfassung nach der Ausführung von Tests mit GitHub Actions eine Übersicht über erfolgreiche, fehlerhafte oder übersprungene Tests bieten, sodass möglicherweise nicht mehr die gesamte Protokollausgabe überprüft werden muss. Weitere Informationen findest du unter Workflowbefehle für GitHub Actions.

Zur einfacheren Diagnose von Auftragsausführungsfehlern bei der erneuten Ausführung eines Workflows können Benutzern die Debugprotokollierung aktivieren, die Informationen zur Ausführung und Umgebung eines Auftrags ausgibt. Weitere Informationen findest du unter Erneutes Ausführen von Workflows und Aufträgen und unter Verwenden von Workflowausführungsprotokollen.

Bei der Verwaltung selbstgehosteter Runner für GitHub Actions kannst du für den Runner selbst einen konsistenten Zustand vor und nach einer Workflowausführung sicherstellen, indem du Skripts zur Ausführung definierst. Durch die Verwendung von Skripts musst du nicht länger die Benutzer zur manuellen Implementierung dieser Skripts in Workflows auffordern. Skripts zur Ausführung vor und nach dem Auftrag befinden sich in der Betaphase und können noch geändert werden. Weitere Informationen findest du unter Ausführen von Skripts vor oder nach einem Auftrag.

Unternehmensbesitzer*innen können eine Richtlinie konfigurieren, um zu steuern, ob die Benutzernamen oder die vollständigen Namen von Personen in internen Repositorys angezeigt werden. Weitere Informationen findest du unter Erzwingen von Repositoryverwaltungsrichtlinien in deinem Unternehmen.

Organisationsbesitzer*innen können ein Repository mithilfe des neuen Dropdownfelds Repository anheften direkt über das Repository an das Profil einer Organisation anheften.

Beim Erstellen eines Forks können Benutzer den Namen des Forks anpassen. Weitere Informationen findest du unter Forken eines Repositorys.

Benutzer können einen Branch löschen, der einem offenen Pull Request zugeordnet ist. Weitere Informationen findest du unter Erstellen und Löschen von Branches innerhalb deines Repositorys.

An CODEOWNERS wurden die folgenden Verbesserungen vorgenommen.

• Syntaxfehler werden jetzt angezeigt, wenn du eine CODEOWNERS-Datei auf der Webbenutzeroberfläche anzeigst. Bisher wurden Syntaxfehler in einer Zeile einer CODEOWNERS-Datei ignoriert oder führten in manchen Fällen dazu, dass die gesamte CODEOWNERS-Datei nicht geladen wurde. GitHub-Apps und -Aktionen können über neue REST- und GraphQL-APIs auf diese Fehlerliste zugreifen. Weitere Informationen findest du in der REST-API-Dokumentation unter Repositorys und in der GraphQL-API-Dokumentation unter Objekte.
• Wenn jemand einen neuen Pull Request erstellt oder neue Änderungen an einem Pull Request-Entwurf pusht, werden jetzt alle Codebesitzer*innen, die zum Review aufgefordert werden, im Pull Request unter „Reviewer“ aufgeführt. Mit diesem Feature kannst du frühzeitig sehen, wer zum Review aufgefordert wird, sobald der Pull Request als prüfungsbereit markiert wird.
• Kommentare in CODEOWNERS-Dateien können jetzt am Ende einer Zeile, nicht nur auf dedizierten Zeilen angezeigt werden.

Weitere Informationen findest du unter Informationen zu Codebesitzern.

Wenn Benutzer*innen eine Datei umbenennen oder in ein neues Verzeichnis verschieben und mindestens die Hälfte des Dateiinhalts identisch ist, zeigt der Commitverlauf ähnlich wie bei git log --follow an, dass die Datei umbenannt wurde. Weitere Informationen findest du im GitHub-Blog.

Benutzer können die erfolgreiche Bereitstellung eines Branchs anfordern, bevor der dem Branch zugeordnete Pull Request gemergt werden kann. Weitere Informationen findest du unter Informationen zu geschützten Branches und Verwalten von Branchschutzregeln.

Repositoryadministratorinnen können ab sofort Tagschutzregeln konfigurieren, um die Tags eines Repositorys zu schützen. Wenn Tags durch eine Tagschutzregel geschützt wurden, können Tags mit einem bestimmten Namensmuster nur noch von Benutzerinnen mit Maintainer- oder Administratorzugriff auf das Repository erstellt und gelöscht werden. Weitere Informationen findest du unter Konfigurieren von Tagschutzregeln.

Benutzer*innen können Revisionen in der Blame-Ansicht ignorieren, indem sie eine Datei .git-blame-ignore-revs im Stammverzeichnis eines Repositorys erstellen. Weitere Informationen findest du unter Anzeigen einer Datei.

Benutzer können GitHub Apps Ausnahmen für Branchschutzregeln gewähren, die Ausnahmen unterstützen. Weitere Informationen findest du unter Informationen zu Apps und unter Verwalten von Branchschutzregeln.

Für öffentliche GPG-Signaturschlüssel, die abgelaufen sind oder widerrufen wurden, werden Git-Commitsignaturen von GitHub AE verifiziert. Die Commits werden als verifiziert angezeigt, wenn die Benutzer*innen den Commit ausgeführt haben, während der Schlüssel noch gültig war. Benutzer können auch abgelaufene oder widerrufene GPG-Schlüssel hochladen. Weitere Informationen findest du unter Informationen zur Commitsignaturverifizierung.

Um zu bestätigen, dass ein Commit den Regeln und Lizenzen für ein Repository entspricht, können Organisationsbesitzer und Repositoryadministratoren Entwickler jetzt dazu auffordern, über die Weboberfläche durchgeführte Commits zu signieren. Weitere Informationen findest du unter Verwalten der Richtlinie für das Abzeichnen von Commits für deine Organisation und unter Verwalten der Richtlinie für das Abzeichnen von Commits für dein Repository.

Über die Dateistruktur auf der Registerkarte Geänderte Dateien eines Pull Requests können Benutzer*innen durch geänderte Dateien navigieren, die Größe und den Umfang von Änderungen verstehen und sich auf Reviews konzentrieren. Die Dateistruktur wird angezeigt, wenn durch einen Pull Request mindestens zwei Dateien geändert werden und das Browserfenster ausreichend breit ist. Weitere Informationen findest du unter Überprüfen der vorgeschlagenen Änderungen in einem Pull Request und unter Filtern der Dateien in einem Pull Request.

Benutzer können standardmäßig die Titel von Pull Requests als Commitnachricht für alle Squashmerges verwenden. Weitere Informationen findest du unter Konfigurieren von Commit-Squashing für Pull Requests.

Mit der Schaltfläche Branch aktualisieren auf der Pull Request-Seite können Benutzer*innen den Branch deines Pull Requests mit den neuesten Änderungen aus dem Basisbranch aktualisieren. Dies ist nützlich, um vor dem Mergen sicherzustellen, dass Änderungen durch den Pull Request mit der aktuellen Version des Basisbranches kompatibel sind. Zwei Verbesserungen bieten weitere Möglichkeiten, einen Branch auf dem neuesten Stand zu halten.

• Wenn der Topic-Branch eines Pull Requests nicht mehr mit dem Basisbranch übereinstimmt, können Benutzerinnen ihn jetzt aktualisieren, indem sie ein Rebase auf die neueste Version des Basisbranches ausführen. Beim Rebase werden die Änderungen aus dem Topic-Branch auf die neueste Version des Basisbranchs angewandt, was zu einem Branch mit linearem Verlauf führt, da kein Mergecommit erstellt wird. Wähle zur Aktualisierung per Rebase im Dropdownmenü neben der Schaltfläche Branch aktualisieren die Option Durch Rebase aktualisieren und dann Rebase für Branch ausführen aus. Bisher wurde über Branch aktualisieren ein herkömmlicher Mergevorgang ausgeführt, der immer zu einem Mergecommit in deinem Pull Request-Branch führte. Diese Option ist weiterhin verfügbar, aber Benutzerinnen haben jetzt die Wahl. Weitere Informationen findest du unter Synchronisieren eines Pull Requests mit dem Basisbranch.
• Eine neue Repositoryeinstellung ermöglicht es, dass die Schaltfläche Branch aktualisieren immer dann verfügbar ist, wenn der Topic-Branch eines Pull Requests nicht auf demselben Stand ist wie der Basisbranch. Bisher war diese Schaltfläche nur verfügbar, wenn die Branchschutzeinstellung Aktualität der Branches vor dem Mergen erforderlich aktiviert war. Benutzer*innen mit Administrator- oder Maintainerzugriff können die Einstellung Immer Aktualisierung von Pull Request-Branches vorschlagen im Abschnitt Pull Requests in den Repositoryeinstellungen verwalten. Weitere Informationen findest du unter Verwalten von Vorschlägen zum Aktualisieren von Pull Request-Branches.

Wenn sie die Details für ein bestimmtes Release anzeigen, können Benutzer das Erstellungsdatum für die einzelnen Releaseressourcen einsehen. Weitere Informationen findest du unter Anzeigen der Releases und Tags deines Repositorys.

Beim Erstellen eines Release mit automatisch generierten Versionshinweisen können Benutzer das Tag anzeigen, das als vorheriges Release aufgeführt wird, und dann ein anderes Tag auswählen, das als vorheriges Release angegeben werden soll. Weitere Informationen findest du unter Automatisch generierte Versionshinweise.

Gists zeigen bei der erstmaligen Anzeige jetzt nur noch die 30 neuesten Kommentare an. Benutzer*innen können Frühere Kommentare laden auswählen, um weitere Kommentare anzuzeigen. So können Gists mit vielen Kommentaren schneller angezeigt werden. Weitere Informationen findest du unter Bearbeiten und Freigeben von Inhalten mit Gists.

Das Bearbeiten von Markdown in der Weboberfläche wurde verbessert.

• Sobald Benutzer*innen Text auswählen und eine URL einfügen, wird der ausgewählte Text in einen Markdownlink zur eingefügten URL umgewandelt.
• Wenn Benutzer*innen Tabellenzellen oder HTML-Tabellen einfügen, wird der resultierende Text als Tabelle gerendert.
• Wenn Benutzer*innen Text mit Links kopieren, enthält der eingefügte Text den Link als Markdownlink.

Weitere Informationen findest du unter Grundlegende Schreib- und Formatierungssyntax.

Beim Bearbeiten einer Markdowndatei auf der Weboberfläche wird durch Klicken auf die Registerkarte Vorschau automatisch zu der Stelle in der Vorschau gescrollt, die du gerade bearbeitet hast. Die Scrollposition beruht auf der Position des Cursors vor dem Auswählen der Registerkarte Vorschau.

Ab sofort ist ein helles Design mit hohem Kontrast verfügbar, bei dem der Kontrast zwischen Vorder- und Hintergrundelementen verstärkt wurde. Weitere Informationen findest du unter Verwalten deiner Designeinstellungen.

Listen mit Repositorys, die einem Benutzer oder einer Organisation gehören, verfügen jetzt über eine zusätzliche Filteroption „Vorlagen“, die das Auffinden von Vorlagenrepositorys erleichtert.

GitHub AE kann zahlreiche gängige Bildformate anzeigen, darunter PNG, JPG, GIF, PSD und SVG, und bietet verschiedene Möglichkeiten, Unterschiede zwischen Versionen zu vergleichen. Wenn du hinzugefügte oder geänderte Bilder in einem Pull Request überprüfst, wird jetzt standardmäßig eine Vorschau für diese Bilder angezeigt. Bisher wurde in einer Meldung darauf hingewiesen, dass Binärdateien nicht angezeigt werden können und dass die Option „Rich-Diff anzeigen“ umgeschaltet werden muss. Weitere Informationen findest du unter Arbeiten mit Nicht-Codedateien.

Die Einstellungsseiten für Benutzer, Organisationen, Repositorys und Teams wurden neu gestaltet und gruppieren ähnliche Einstellungsseiten in Abschnitte, um die Informationsarchitektur und Auffindbarkeit zu verbessern. Weitere Informationen findest du im GitHub-Änderungsprotokoll.

Interaktive Elemente in der Weboberfläche, z. B. Links oder Schaltflächen, weisen eine sichtbare Kontur auf, wenn sie über die Tastatur den Fokus erhalten, damit Benutzer einfacher die aktuelle Position auf einer Seite finden können. Außerdem sind Formularfelder, auf denen der Fokus liegt, durch eine Kontur mit stärkerem Kontrast gekennzeichnet.

Wenn du mit dem Mauszeiger auf eine Beschriftung zeigst, wird jetzt eine QuickInfo mit einer Beschreibung der Beschriftung angezeigt.

Wenn Benutzer*innen beim Erstellen eines neuen Issues oder Pull Requests die Seite aktualisieren, bleiben alle zugewiesenen Personen, Reviewer, Bezeichnungen und Projekte erhalten.

Um den Geräteautorisierungsflow für OAuth und GitHub-Apps zu nutzen, müssen Erstellerinnen das Feature manuell aktivieren. Diese Änderung verringert die Wahrscheinlichkeit, dass Apps für Phishingangriffe gegen GitHub AE-Benutzerinnen verwendet werden, da die Integratorinnen sich der Risiken bewusst sind und sich bewusst für diese Form der Authentifizierung entscheiden. Wenn Benutzerinnen eine OAuth-App oder GitHub-App besitzen oder verwalten und den Geräteflow nutzen möchten, können sie ihn für eine App über die Einstellungsseite der App aktivieren. Die Endpunkte der Geräteflow-API reagieren mit dem Statuscode 400 auf Apps, bei denen dieses Feature nicht aktiviert ist. Weitere Informationen findest du unter Autorisieren von 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.