{"meta":{"title":"Pull-Request-Zusammenführungen","intro":"Erfahren Sie mehr über Strategien zum Zusammenführen von Pull Requests, einschließlich Merge-Commits, Squash-Merges und Rebase-Vorgängen, um den Repository-Verlauf effektiv zu verwalten.","product":"Pull Requests","breadcrumbs":[{"href":"/de/pull-requests","title":"Pull Requests"},{"href":"/de/pull-requests/reference","title":"Referenz"},{"href":"/de/pull-requests/reference/pull-request-merges","title":"Pull-Request-Zusammenführungen"}],"documentType":"article"},"body":"# Pull-Request-Zusammenführungen\n\nErfahren Sie mehr über Strategien zum Zusammenführen von Pull Requests, einschließlich Merge-Commits, Squash-Merges und Rebase-Vorgängen, um den Repository-Verlauf effektiv zu verwalten.\n\nPullanforderungen können auf unterschiedliche Weise zusammengeführt werden. Die beste Strategie hängt davon ab, wie der Repository-Verlauf für Ihr Team aussehen soll und wie viele Details Sie aus dem Pull-Request-Branch beibehalten möchten.\n\n| Strategy                     | Result                                                                                               | Auswählen, wann                                                                                                      |\n| ---------------------------- | ---------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------- |\n| Zusammenführen des Commits   | Behält jeden Commit aus dem Pull-Request-Branch bei und fügt einen expliziten Merge-Punkt hinzu.     | Ihr Team legt Wert auf eine vollständige Historie, oder die einzelnen Commits sind für sich genommen aussagekräftig. |\n| Squashen und Zusammenführen  | Fasst alle Commits im Pull Request zu einem einzigen Commit im Basiszweig zusammen.                  | Eine Pullanforderung stellt eine logische Änderung dar, insbesondere bei vielen kleinen Fixup-Commits.               |\n| Neubasis und Zusammenführung | Wendet jeden Commit ohne Merge-Commit auf den Basis-Branch an, sodass ein linearer Verlauf entsteht. | Ihr Team möchte eine lineare Historie, und die Commits sind bereits klar organisiert.                                |\n\n## Zusammenführen Ihrer Commits\n\nWenn Sie in einem Pull Request auf die standardmäßige Option **Pull Request mergen** klicken, werden alle Commits aus dem Featurebranch dem Basisbranch in einem Mergecommit hinzugefügt. Der Pull Request wird über die [`--no-ff`-Option](https://git-scm.com/docs/git-merge#_fast_forward_merge) gemergt.\n\nUm Pull Requests mergen zu können, musst du über [Schreibberechtigungen](/de/organizations/managing-user-access-to-your-organizations-repositories/managing-repository-roles/repository-roles-for-an-organization) im Repository verfügen.\n\n![Diagramm des Standardablaufs für Merge- und Commitvorgänge, bei dem Commits aus einem Featurebranch und ein zusätzlicher Mergecommit zu main hinzugefügt werden](/assets/images/help/pull_requests/standard-merge-commit-diagram.png)\n\nEin Merge-Commit bewahrt den vollständigen Commit-Verlauf des Pull-Request-Branches. Dadurch wird es einfacher, jeden Commit zu sehen, der zu der endgültigen Änderung geführt hat, einschließlich Korrekturen und Zwischenarbeiten. Außerdem wird ein expliziter Zusammenführungspunkt im Basiszweigverlauf erstellt.\n\nWählen Sie diese Strategie, wenn Ihr Team großen Wert auf eine vollständige Historie legt oder wenn die einzelnen Commits in einem Pull Request für sich genommen aussagekräftig sind.\n\n## Squashen und Mergen von Commits\n\nWenn Sie die Option **Squash und Merge** in einem Pull Request auswählen, werden die Commits des Pull Requests in einem einzigen Commit zusammengefasst. Anstatt dass alle einzelnen Commits eines Mitarbeiters aus einem Themen-Branch angezeigt werden, werden die Commits in einem Commit kombiniert und in den Standardbranch zusammengeführt. Pull Request mit so zusammengefassten Commits werden mithilfe der [Vorlaufoption](https://git-scm.com/docs/git-merge#_fast_forward_merge) gemergt.\n\nZum Squashmergen von Pull Requests musst du über [Schreibberechtigungen](/de/organizations/managing-user-access-to-your-organizations-repositories/managing-repository-roles/repository-roles-for-an-organization) im Repository verfügen, und das Repository muss das [Squashmergen zulassen](/de/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/configuring-commit-squashing-for-pull-requests).\n\n![Diagramm des Commit-Squashings, bei dem mehrere Commits aus einem Featurebranch zu einem einzigen Commit zusammengefasst werden, der zu main hinzugefügt wird.](/assets/images/help/pull_requests/commit-squashing-diagram.png)\n\nMittels Squash und Merge kannst du einen optimierteren Git-Verlauf in deinem Repository erstellen. In Arbeit befindliche Commits sind hilfreich, wenn du auf einem Feature-Branch arbeitest, sie müssen aber nicht unbedingt im Git-Verlauf beibehalten werden. Wenn du diese Commits beim Mergen mit dem Standardbranch squashst, werden die Änderungen konsolidiert, was zu einem übersichtlichen Git-Verlauf führt.\n\nBeim Squashen werden alle Commits im Pull Request zu einem einzigen Commit auf dem Basis-Branch zusammengefasst. Dadurch bleibt der Standardmäßige Verzweigungsverlauf präzise und kann das Scannen später vereinfachen. Der Nachteil dabei ist, dass die zwischenzeitlichen Commits aus dem Pull Request im Basis-Branch nicht als separate Commits erhalten bleiben.\n\nWählen Sie diese Strategie aus, wenn eine Pullanforderung eine logische Änderung darstellt, insbesondere, wenn die Verzweigung viele kleine Fixup-Commits enthält.\n\n### Meldung zur Zusammenführung eines Squash-Merge\n\nWenn Sie squashen und zusammenführen, generiert GitHub eine Standard-Commit-Nachricht, die Sie bearbeiten können. Die Standardnachricht kann den Titel der Pullanforderung, die Beschreibung der Pullanforderung oder commit-Informationen enthalten, je nach Repositoryeinstellungen und der Anzahl der Commits in der Pullanforderung.\n\nMaintainer und Administratoren können die Standardnachricht für Squash-Commits konfigurieren. Siehe [Commit-Squashing für Pull-Requests konfigurieren](/de/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/configuring-commit-squashing-for-pull-requests).\n\n### Squashing und Zusammenführen eines langfristig bearbeiteten Branches\n\nSquash-Merging funktioniert am besten für kurzlebige Branches. Wenn Sie nach einem Squash-Merge weiterhin am selben Head-Branch arbeiten, können spätere Pull Requests Commits enthalten, die bereits per Squash-Merge in den Basis-Branch zusammengeführt wurden. Dies kann dazu führen, dass Zusammenführungskonflikte wahrscheinlicher sind und Sie zwingen können, dieselben Konflikte mehrmals aufzulösen.\n\nErwägen Sie bei langlebigen Branches, einen Merge-Commit zu verwenden oder den Branch neu zu basieren, bevor Sie den nächsten Pull Request öffnen.\n\n## Rebasing und Merging von Commits\n\nWenn Sie bei einem Pull Request die Option **Rebase and merge** auswählen, werden alle Commits aus dem Topic-Branch (oder Head-Branch) einzeln auf den Basis-Branch angewendet, ohne einen Merge-Commit zu erstellen. Auf diese Weise ähnelt das Verhalten von Rebase und Merge einem [Fast-Forward-Merge](https://git-scm.com/docs/git-merge#_fast_forward_merge), da ein linearer Projektverlauf beibehalten wird. Ein Rebase erreicht dies jedoch durch erneutes Schreiben des Commitverlaufs auf dem Basisbranch mit neuen Commits.\n\nDas Rebase- und Merge-Verhalten auf GitHub weicht außerhalb von `git rebase` geringfügig von GitHub ab. Rebase und zusammenführen auf GitHub:\n\n* Aktualisiert immer die Committerinformationen und erstellt neue Commit-SHAs, während `git rebase` die Committerinformationen nicht ändert, wenn das Rebase auf einem Vorgängercommit erfolgt.\n* Verwirft Commits, die von Anfang an leer waren, wie z. B. solche, die mit `git commit --allow-empty` erstellt wurden, während `git rebase` ursprünglich leere Commits standardmäßig beibehält.\n\nWeitere Informationen zu `git rebase` finden Sie unter [git-rebase](https://git-scm.com/docs/git-rebase) in der Git-Dokumentation.\n\nZum Ausführen von „Rebase und Merge“ für Pull Requests musst du im Repository über [Schreibberechtigungen](/de/organizations/managing-user-access-to-your-organizations-repositories/managing-repository-roles/repository-roles-for-an-organization) verfügen, und das Repository muss [Rebase und Merge zulassen](/de/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/configuring-commit-rebasing-for-pull-requests).\n\nEine visuelle Darstellung von `git rebase` finden Sie im [Kapitel „Git Branching – Rebasing“ aus dem *Pro Git*-Buch](https://git-scm.com/book/en/v2/Git-Branching-Rebasing).\n\nBei einem Rebase wird jeder Commit aus dem Pull-Request-Branch auf den Basis-Branch angewendet, ohne einen Merge-Commit zu erstellen. Dies erzeugt einen linearen Verlauf, wobei die einzelnen Commits aus dem Pull-Request beibehalten werden.\n\nWählen Sie diese Strategie aus, wenn Ihr Team einen linearen Verlauf wünscht und die Pull-Anforderungs-Commits bereits klar organisiert sind. Wenn GitHub für die Pull-Anforderung nicht sicher automatisch einen Rebase durchführen kann, können Sie den Rebase lokal durchführen, Konflikte beheben und den aktualisierten Branch pushen. Siehe [Einen Mergekonflikt über die Befehlszeile beheben](/de/pull-requests/how-tos/merge-and-close-pull-requests/resolving-a-merge-conflict-using-the-command-line) und [Einen Pull Request zusammenführen](/de/pull-requests/how-tos/merge-and-close-pull-requests/merging-a-pull-request).\n\n## Indirekte Zusammenführungen\n\nEine Pull-Anforderung kann als zusammengeführt markiert werden, wenn ihre Head Branch-Commits von der Basis-Verzweigung außerhalb dieser Pullanforderung erreichbar werden können. Dies kann passieren, wenn dieselben Commits über einen anderen Pull Request zusammengeführt oder direkt in den Standard-Branch gepusht werden.\n\nIndirekte Zusammenführungen sind ungewöhnlich, können sich jedoch auf Automatisierungs- und Zweigschutzerwartungen auswirken. Zusammengeführte Pullanforderungen werden indirekt als `merged` auch dann markiert, wenn Verzweigungsschutzregeln für diese Pullanforderung nicht erfüllt waren.\n\n## Weiterführende Lektüre\n\n* [Pull-Anfragen](/de/pull-requests/reference/pull-requests)\n* [Pull Requests zusammenführen und schließen](/de/pull-requests/how-tos/merge-and-close-pull-requests)"}