# Fehlerbehebung von erforderlichen Statuschecks Beheben Sie häufige Fehler und heben Sie Blockierungen beim Zusammenführen oder Pushen in geschützte Branches auf, indem Sie Fehler bei den erforderlichen Statusprüfungen beheben. Verwenden Sie diese Prüfungen, wenn eine erforderliche Statusprüfung das Zusammenführen oder Pushen in einen geschützten Branch blockiert. Siehe [Status checks](/de/pull-requests/reference/status-checks). * Eine erforderliche Statusüberprüfung muss in den letzten sieben Tagen erfolgreich im ausgewählten Repository abgeschlossen sein. * Wenn eine Überprüfung und ein Commit-Status denselben Namen haben, müssen beide erfolgreich sein, wenn dieser Name erforderlich ist. Siehe [REST-API-Endpunkte für Prüfungen](/de/rest/checks). * Wenn der Branch-Schutz erfordert, dass Ihr Branch auf dem neuesten Stand ist, mergen Sie den Basis-Branch in Ihren Branch oder rebasen Sie Ihren Branch auf den Basis-Branch. Siehe [Informationen zu geschützten Branches](/de/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches#require-status-checks-before-merging) und [Informationen zu Git-Rebase](/de/get-started/using-git/about-git-rebase). Wenn die erforderlichen Statusprüfungen nicht erfolgreich waren, wird beim Pushen in einen geschützten Branch ein ähnlicher Fehler zurückgegeben. ```shell remote: error: GH006: Protected branch update failed for refs/heads/main. remote: error: Required status check "ci-build" is failing ``` > \[!NOTE] > Pull-Requests, die auf dem neuesten Stand sind und die erforderlichen Status-Prüfungen bestehen, können lokal zusammengeführt und an den geschützten Branch gepusht werden. Sie können dies tun, ohne Statusüberprüfungen für den Zusammenführungsvorgang selbst auszuführen. ## Erforderliche Überprüfung muss für den neuesten Commit-SHA erfolgreich abgeschlossen werden Überprüfen Sie Folgendes, wenn eine erforderliche Prüfung weiterhin eine Pullanforderung blockiert. * Erforderliche Prüfungen müssen auf dem neuesten Commit-SHA erfolgreich sein. Prüfungen aus früheren Commits erfüllen die Anforderung nicht. * Erfolgreiche Überprüfungsstatus sind `success`, `skipped`und `neutral`. Siehe [Status checks](/de/pull-requests/reference/status-checks). ## Konflikte zwischen dem Head-Commit und dem Test-Merge-Commit Verwenden Sie das Kontrollkästchen für die Pull-Request-Statusprüfungen, um zu ermitteln, welcher Commit die Prüfungen bestehen muss. | Statusüberprüfungsquelle | Was muss passieren? | Was Sie möglicherweise sehen können | | --------------------------------------- | --------------------- | ------------------------------------- | | Test-Merge-Commit hat einen Status | Der Test-Merge-Commit | `Showing checks for the merge commit` | | Der Test-Merge-Commit hat keinen Status | Der neueste Commit | Prüft den neuesten HEAD-Commit | Siehe [REST-API-Endpunkte für Pullanforderungen](/de/rest/pulls/pulls#get-a-pull-request). ## Verwaltung von übersprungenen, aber erforderlichen Überprüfungen | Ursache | Result | Beheben oder prüfen | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Ein Workflow wird durch [Pfadfilterung](/de/actions/reference/workflows-and-actions/workflow-syntax#onpushpull_requestpull_request_targetpathspaths-ignore), [Verzweigungsfilterung](/de/actions/reference/workflows-and-actions/workflow-syntax#onpull_requestpull_request_targetbranchesbranches-ignore) oder [Commitnachricht übersprungen](/de/actions/how-tos/manage-workflow-runs/skip-workflow-runs). | Zugehörige Prüfungen verbleiben im Status „Ausstehend“ und blockieren das Zusammenführen | Vermeiden Sie, dass Workflows übersprungen werden können. | | Ein Auftrag wird durch eine Bedingung übersprungen. | Der Job meldet "Erfolg" | Siehe [Steuern der Auftragsausführung mithilfe von Bedingungen](/de/actions/how-tos/write-workflows/choose-when-workflows-run/control-jobs-with-conditions). | | Ein Auftrag hängt von einem fehlgeschlagenen Auftrag ab. | Der abhängige Auftrag wird übersprungen und kann das Zusammenführen nicht blockieren. | Verwenden Sie `always()` mit `needs` für erforderliche Prüfungen, die von anderen Jobs abhängen. Siehe [Verwenden von Aufträgen in einem Workflow](/de/actions/how-tos/write-workflows/choose-what-workflows-do/use-jobs#defining-prerequisite-jobs). | ### Example Dieser Workflow erfordert einen erfolgreichen `build` Job, wird jedoch nur ausgeführt, wenn ein Pull Request Dateien in `scripts` ändert. ```yaml name: ci on: pull_request: paths: - 'scripts/**' jobs: build: runs-on: ubuntu-latest strategy: matrix: node-version: [12.x, 14.x, 16.x] steps: - uses: actions/checkout@v6 - name: Use Node.js ${{ matrix.node-version }} uses: actions/setup-node@v4 with: node-version: ${{ matrix.node-version }} cache: 'npm' - run: npm ci - run: npm run build --if-present - run: npm test ``` Eine Pullanforderung, die nur eine Datei im Repositorystamm ändert, löst diesen Workflow nicht aus. Wenn `build` erforderlich ist, wird der Pull Request mit „Warten auf Statusmeldung.“ blockiert. ### Statusprüfungen mit GitHub Actions und Merge-Warteschlange Wenn eine Merge-Warteschlange eine GitHub Actions Prüfung erfordert, lösen Sie den Workflow mit dem Ereignis `merge_group` aus. > \[!NOTE] > Wenn Ihr Repository GitHub Actions verwendet, um erforderliche Prüfungen für Pull Requests in Ihrem Repository benötigen, müssen Sie die Workflows aktualisieren, um das `merge_group` Ereignis als zusätzlichen Auslöser einzubeziehen. Andernfalls werden Statusüberprüfungen nicht ausgelöst, wenn du einer Mergewarteschlange einen Pull Request hinzufügst. Der Merge ist nicht erfolgreich, da die erforderliche Statusüberprüfung nicht gemeldet wird. Das `merge_group`-Ereignis ist von den Ereignissen `pull_request` und `push` getrennt. Beispiel für die Triggerkonfiguration: ```yaml on: pull_request: merge_group: ``` Siehe [Ereignisse zum Auslösen von Workflows](/de/actions/reference/workflows-and-actions/events-that-trigger-workflows#merge_group). ## Erforderliche Statusüberprüfungen aus unerwarteten Quellen Eine geschützte Verzweigung kann auch eine Statusüberprüfung eines bestimmten GitHub AppTyps erfordern. Wenn eine Meldung wie die folgende angezeigt wird, überprüfen Sie, ob die im Zusammenführungsfeld aufgeführte Überprüfung von der erwarteten App festgelegt wurde. ```text Required status check "build" was not set by the expected GitHub App. ```