Skip to content

Commit 284c2fe

Browse files
rockylinux-autorockylinux-auto
authored
New Crowdin updates (#2931)
* New translations tracking_and_nontracking_branch.md (German) * New translations git_pull_vs_git_fetch.md (German) * New translations git_remote_add.md (German) * New translations git_pull_vs_git_fetch.md (German)
1 parent d9a16ff commit 284c2fe

File tree

3 files changed

+221
-0
lines changed

3 files changed

+221
-0
lines changed

‎docs/gemstones/git/git_pull_vs_git_fetch.de.md‎

Lines changed: 70 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,70 @@
1+
---
2+
title: "`git pull` und `git fetch` im Vergleich"
3+
author: Wale Soyinka
4+
contributors: Ganna Zhyrnova
5+
tags:
6+
- Git
7+
- git pull
8+
- git fetch
9+
---
10+
11+
## Einleitung
12+
13+
Dieses Gemstone erklärt die Unterschiede zwischen den Befehlen `git pull` und `git fetch`. Außerdem wird erläutert, wann welcher Befehl angemessen verwendet werden sollte.
14+
15+
## Git Fetch versus Git Pull
16+
17+
### Git Fetch
18+
19+
`git fetch` lädt Änderungen aus einem Remote-Repository herunter, integriert sie jedoch nicht in Ihren lokalen Zweig.
20+
21+
Es ist hilfreich zu sehen, was andere mit `commit` eingereicht haben, ohne diese Änderungen mit `merge` in Ihren lokalen Zweig zu übernehmen.
22+
23+
1. Listet den aktuell ausgecheckten Zweig auf
24+
25+
```bash
26+
git branch
27+
```
28+
29+
2. Rufen Sie Änderungen aus dem Hauptzweig eines Remote-Repos namens `origin` mit `fetch` ab. Geben Sie bitte Folgendes ein:
30+
31+
```bash
32+
git fetch origin main
33+
```
34+
35+
3. Vergleichen Sie die Änderungen zwischen dem HEAD Ihres lokalen Repo und dem Remote-`origin/main`-Repo.
36+
37+
```bash
38+
git log HEAD..origin/main
39+
```
40+
41+
### Git Pull
42+
43+
`git pull` lädt Änderungen herunter und führt sie in Ihren aktuellen Branch zusammen.
44+
Es ist nützlich, um Ihren lokalen Zweig schnell mit Änderungen aus dem Remote-Repository zu aktualisieren.
45+
46+
1. **Änderungen abrufen und zusammenführen**:
47+
48+
```bash
49+
git pull origin main
50+
```
51+
52+
2. **Mit `merge` zusammengeführte Änderungen Revue passieren**:
53+
54+
```bash
55+
git log
56+
```
57+
58+
## Zusätzliche Anmerkungen
59+
60+
- **Verwenden Sie `git fetch`**:
61+
\-- Wenn Sie Änderungen vor dem Zusammenführen überprüfen müssen.
62+
– Um unerwünschte Änderungen oder Konflikte in Ihrem lokalen Branch zu vermeiden.
63+
64+
- **Verwenden Sie `git pull`**:
65+
\-- Wenn Sie Ihren lokalen Branch mit den neuesten Commits aktualisieren möchten.
66+
– Für schnelle, unkomplizierte Updates, ohne dass Änderungen vorher überprüft werden müssen.
67+
68+
## Zusammenfassung
69+
70+
Für ein effektives Git-Workflow-Management ist es wichtig, die Unterschiede zwischen `git fetch` und `git pull` zu verstehen. Die Auswahl des richtigen Befehls basierend auf Ihren Anforderungen ist wichtig, wenn Sie über Versionskontrollsysteme wie GitHub, GitLab, Gitea usw. arbeiten oder zusammenarbeiten.

‎docs/gemstones/git/git_remote_add.de.md‎

Lines changed: 78 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,78 @@
1+
---
2+
title: Hinzufügen eines Remote-Repositorys mithilfe der Git-CLI
3+
author: Wale Soyinka
4+
contributors: Ganna Zhyrnova
5+
tags:
6+
- GitHub
7+
- git
8+
- git remote
9+
- git fetch
10+
---
11+
12+
## Einleitung
13+
14+
Dieses Gemstone veranschaulicht, wie mithilfe der Git-Befehlszeilenschnittstelle ein bestimmtes Remote-Repository zu einem vorhandenen lokalen Klon eines FOSS-Projekts hinzugefügt wird.
15+
Wir verwenden das Repository des Rocky Linux-Dokumentationsprojekts als Beispiel für unser FOSS-Projekt - <https://github.com/rocky-linux/documentation.git>
16+
17+
## Voraussetzungen
18+
19+
- Ein Github-Konto.
20+
- „git“ ist auf Ihrem System installiert.
21+
- Ein lokaler Klon eines FOSS-Projekt-Repositorys.
22+
23+
## Prozedur
24+
25+
1. Öffnen Sie ein Terminal und ändern Sie Ihr Arbeitsverzeichnis in den Ordner, der Ihren lokalen Klon des Projekts enthält.
26+
Wenn Sie beispielsweise das GitHub-Repository nach `~/path/to/your/rl-documentation-clone` geklont haben, geben Sie Folgendes ein
27+
28+
```bash
29+
cd ~/path/to/your/rl-documentation-clone
30+
```
31+
32+
2. Bevor Sie Änderungen vornehmen, listen Sie die von Ihnen konfigurierten Remotes auf. Geben Sie bitte Folgendes ein:
33+
34+
```bash
35+
git remote -vv
36+
```
37+
38+
Wenn es sich um ein frisch geklontes Repo handelt, sehen Sie in Ihrer Ausgabe wahrscheinlich ein einzelnes Remote mit dem Namen `origin`.
39+
40+
3. Fügen Sie das Rocky Linux Documentation Repository (`https://github.com/rocky-linux/documentation.git`) als neues Remote zu Ihrem lokalen Repository hinzu. Hier weisen wir `upstream` als Namen für dieses bestimmte `Remote` zu. Geben Sie bitte Folgendes ein:
41+
42+
```bash
43+
git remote add upstream https://github.com/rocky-linux/documentation.git
44+
```
45+
46+
4. To further emphasize that the names assigned to remote repositories are arbitrary, create another remote named rocky-docs that points to the same repo by running:
47+
48+
```bash
49+
git remote add rocky-docs https://github.com/rocky-linux/documentation.git
50+
```
51+
52+
5. Bestätigen Sie, dass das neue Remote-Repository erfolgreich hinzugefügt wurde:
53+
54+
```bash
55+
git remote -v
56+
```
57+
58+
Sie sollten `upstream` zusammen mit seiner URL aufgelistet sehen.
59+
60+
6. Optional können Sie Daten aus dem neu hinzugefügten Remote abrufen, bevor Sie mit Änderungen an Ihrem lokalen Repo beginnen.
61+
Rufen Sie mit `fetch` Zweige und Commits vom neu hinzugefügten Remote ab, indem Sie Folgendes ausführen:
62+
63+
```bash
64+
git fetch upstream
65+
```
66+
67+
## Zusätzliche Anmerkungen
68+
69+
- _origin_: Dies ist der Standardname, den Git dem Remote-Repository gibt, von dem Sie geklont haben. Es ist wie ein Spitzname für die Repository-URL. Wenn Sie ein Repository klonen, wird dieses Remote-Repository in Ihrer lokalen Git-Konfiguration automatisch als `origin` festgelegt. Der Name ist beliebig, soll aber gewissen Konventionen befolgen.
70+
71+
- _upstream_: Dies bezieht sich oft auf das ursprüngliche Repository, wenn Sie ein Projekt geforkt haben.
72+
Wenn Sie in Open-Source-Projekten ein Repository forken, um Änderungen vorzunehmen, ist das geforkte Repository Ihr `origin` und das ursprüngliche Repository wird normalerweise als `upstream` bezeichnet. Der Name ist beliebig, soll aber gewissen Konventionen befolgen.
73+
74+
Diese subtile Unterscheidung zwischen der Verwendung/Zuweisung von `origin` und `remote` ist entscheidend, um durch Pull Requests zum ursprünglichen Projekt beizutragen.
75+
76+
## Zusammenfassung
77+
78+
Mit dem Dienstprogramm `git CLI` können Sie ganz einfach einen beschreibenden Namen verwenden und einem lokalen Klon eines FOSS-Projekts ein bestimmtes Remote-Repository hinzufügen. Auf diese Weise können Sie effektiv mit verschiedenen Repositorys synchronisieren und zu ihnen beitragen.

‎docs/gemstones/git/tracking_and_nontracking_branch.de.md‎

Lines changed: 73 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,73 @@
1+
---
2+
title: Tracking- vs. Non-Tracking-Branch in Git
3+
author: Wale Soyinka
4+
contributors:
5+
tags:
6+
- git
7+
- git branch
8+
- Tracking Branch
9+
- Non-Tracking Branch
10+
---
11+
12+
## Einleitung
13+
14+
Dieses Gemstone befasst sich mit Tracking- und Non-Tracking-Zweigen in Git. Es enthält auch Schritte zum Überprüfen und Konvertieren zwischen den Zweigtypen.
15+
16+
## Tracking Branch
17+
18+
Ein Tracking-Branch ist ein Zweig, der mit einem Remote-Branch verknüpft ist.
19+
20+
1. Erstellen Sie einen neuen Branch mit dem Namen `my-local-branch`. Sorgen Sie dafür, dass der neue lokale Zweig den Hauptzweig des Remote-Repositorys mit dem Namen `origin` verfolgt. Geben Sie bitte Folgendes ein:
21+
22+
```bash
23+
git checkout -b my-local-branch origin/main
24+
```
25+
26+
2. Verwenden Sie den Befehl `git branch -vv`, um zu überprüfen, ob es sich bei dem Zweig um einen Tracking-Zweig handelt. Geben Sie bitte Folgendes ein:
27+
28+
```bash
29+
git branch -vv
30+
```
31+
32+
Suchen Sie nach Zweigen mit `[origin/main]`, was darauf hinweist, dass sie `origin/main` verfolgen.
33+
34+
## Non-Tracking Branch
35+
36+
Ein `Non-Tracking-Branch` ist ein Zweig, der unabhängig von `Remote-Branch`es arbeitet.
37+
38+
1. Erstellen Sie einen neuen lokalen Zweig ohne Nachverfolgung mit dem Namen `my-feature-branch`. Geben Sie bitte Folgendes ein:
39+
40+
```bash
41+
git checkout -b my-feature-branch
42+
```
43+
44+
2. `Non-Tracking-Branches` zeigen in der Ausgabe von `git branch -vv` keinen `Remote-Branch` daneben an. Überprüfen Sie, ob `my-feature-branch` ein `Non-Tracking-Branch` ist.
45+
46+
## Konvertierung von Non-Tracking in Tracking
47+
48+
1. Stellen Sie optional zunächst sicher, dass die neuesten Änderungen aus dem Hauptzweig in den Zielzweig integriert werden. Geben Sie bitte Folgendes ein:
49+
50+
```bash
51+
git checkout my-feature-branch
52+
git merge main
53+
```
54+
55+
2. Richten Sie das Tracking für ein Remote-Branch ein:
56+
57+
```bash
58+
git branch --set-upstream-to=origin/main my-feature-branch
59+
```
60+
61+
Ergebnis: `Branch 'my-feature-branch' set up to track remote branch 'main' from 'origin'.`
62+
63+
3. Änderung prüfen. Geben Sie bitte Folgendes ein:
64+
65+
```bash
66+
git branch -vv
67+
```
68+
69+
Jetzt sollte `my-feature-branch` `[origin/main]` anzeigen, was darauf hinweist, dass es sich um ein Tracking handelt.
70+
71+
## Zusammenfassung
72+
73+
Das Verständnis der Nuancen zwischen Tracking- und Nicht-Tracking-Branches ist in Git von entscheidender Bedeutung. Dieses Gemstone verdeutlicht diese Konzepte und zeigt auch, wie diese Branch-Typen identifiziert und zwischen ihnen konvertiert werden, um ein optimales Git-Workflow-Management zu gewährleisten.

0 commit comments

Comments
 (0)