gaspersic/freeCodeCamp
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

docs(i18n): updated German translation of PR guidelines (#37581)

Browse Source
This commit is contained in:
Dominic Fleckner 2020-03-12 17:55:56 +01:00 committed by GitHub
parent b27d9ce770
commit 814256ca56
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 22 additions and 23 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

45
docs/i18n-languages/german/how-to-open-a-pull-request.md
View File

@ -3,47 +3,46 @@
|-|
<!-- do not translate this -->
# So erstellst du eine Pull Request
# So erstellst du einen Pull Request bei uns
## Wie man einen guten Pull Request Titel vorbereitet:
## Die richtige Titel-Formatierung für einen guten Pull Request
Wenn du eine Pull Request(PR) erstellst, verwende die folgende Tabelle, um zu entscheiden, wie du deine PR im folgenden Format benennen möchtest:
`fix/feat/chore/refactor/docs/perf (scope): PR Title`
Wenn du einen Pull Request (PR) erstellst, verwende das folgende Format für den Titel:
`Änderung(Bereich): PR-Titel`
Ein Beispiel ist `fix(learn): Fixed tests for the do...while loop challenge`.
Arten von Änderungen: 'fix', 'feat', 'chore', 'refactor', 'docs' oder 'perf'
| Thema | Dokumentation |
| Bereich | Erklärung |
|---|---|
| `learn`,`curriculum` | Für Pull-Requests, die Änderungen an den Herausforderungen des Curriculums vornehmen. |
| `client` | Für Pull-Requests, die Änderungen an der Logik der Clientplattform oder der Benutzeroberfläche vornehmen. |
| `guide` | Für Pull-Requests, die Änderungen an dem Leitfaden vornehmen. |
| `docs` | Für Pull-Requests, die Änderungen an der Projektdokumentation vornehmen. |
| `learn`,`curriculum` | Für Pull Requests, die Änderungen an den Herausforderungen des Curriculums vornehmen. |
| `client` | Für Pull Requests, die Änderungen an der Logik der Clientplattform oder der Benutzeroberfläche vornehmen. |
| `guide` | Für Pull Requests, die Änderungen an dem Leitfaden vornehmen. |
| `docs` | Für Pull Requests, die Änderungen an der Projektdokumentation vornehmen. |
## Vorschlag für eine Pull-Request (PR)
Ein Beispiel: `fix(learn): Fixed tests for the do...while loop challenge`
1. Sobald die Änderungen bestätigt wurden, wirst du aufgefordert, eine Pull Request auf der GitHub-Seite deines Forks zu erstellen.
## Wichtige Schritte
1. Sobald du die Änderungen committet hast, wirst du aufgefordert, einen Pull Request auf der GitHub-Seite deines Forks zu erstellen.
![Image - Compare pull request prompt on GitHub](/docs/images/github/compare-pull-request-prompt.png)
2. Standardmäßig sollten alle Pull-Requests gegen den `master` Zweig des Hauptrepositories von freeCodeCamp, gerichtet sein.
2. Standardmäßig sollten alle Pull Requests gegen den `master` Zweig des Hauptrepositories von freeCodeCamp gerichtet sein.
Stelle sicher, dass dein `base fork:` auf freeCodeCamp/freeCodeCamp eingestellt ist, wenn du eine Pull-Request auslöst.
Stelle sicher, dass dein `base fork:` auf freeCodeCamp/freeCodeCamp eingestellt ist, wenn du einen Pull Request eingibst.
![Image - Comparing forks when making a pull request](/docs/images/github/comparing-forks-for-pull-request.png)
3. Sende die Pull-Request aus deinem Zweig an den `master` Zweig von freeCodeCamp.
3. Sende den Pull Request aus deinem Zweig an den `master` Zweig von freeCodeCamp.
4. Füge im Text deiner PR eine detailliertere Zusammenfassung der von dir vorgenommen Änderungen und den Grund dafür hinzu.
4. Füge im Text deines PR eine detailliertere Zusammenfassung der von dir vorgenommen Änderungen und den Grund dafür hinzu.
- Es wird dir eine Pull Request Vorlage angezeigt. Dies ist eine Checkliste, die du vor dem Öffnen der Pull-Request hättest befolgen sollen.
- Es wird dir eine PR-Vorlage mit Checkliste angezeigt. Fülle sie aus und prüfe nochmal, ob du an alles gedacht hast.
- Fülle die Details aus, wie es dir passt. Diese Informationen werden überprüft und entschieden, ob deine Pull-Request akzeptiert wird oder nicht.
- Diese Informationen werden überprüft und als Basis für die Entscheidung herangezogen, ob dein Pull Request akzeptiert wird oder nicht.
- Wenn die PR einen bestehenden Bug/Fehler beheben soll, dann füge am Ende von
der Beschreibung deiner Pull Request, das Schlüsselwort `closes` und #xxxx an (wobei xxxx
die Problemnummer darstellt). Beispiel: `closes #1337`. Dies teilt GitHub mit, dass er
automatisch das bestehende Problem schließt, wenn die PR akzeptiert und zusammengeführt wird.
- Wenn der PR einen bestehenden Bug/Fehler beheben soll, dann füge am Ende der Beschreibung das Schlüsselwort `closes` und #xxxx an (wobei xxxx die 'Issue'-Nr. darstellt). Beispiel: `closes #1337`. Dadurch schließt GitHub automatisch das bestehende Issue, wenn die PR akzeptiert und zusammengeführt wird.
5. Gebe an, ob du auf einer lokalen Kopie der Website getestet hast oder nicht.
Das ist sehr wichtig, wenn du Änderungen vornimmst, die nicht nur Änderungen an Textinhalten vornehmen, wie z.B. eine Leitartikelwortwahl. Beispiele für Änderungen, die lokale Tests erfordern, sind JavaScript, CSS oder HTML, die die Funktionalität oder das Layout einer Seite ändern können.
Das ist sehr wichtig, wenn du Änderungen vornimmst, die nicht die Dokumentation sondern den Code selbst betreffen. Beispiele für Änderungen, die lokale Tests erfordern, sind: JavaScript, CSS und HTML. Diese könnten die Funktionalität oder das Layout einer Seite verändern und müssen daher getestet werden.