You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: TRANSLATION_NOTES_DE.asc
+2Lines changed: 2 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -81,6 +81,8 @@ Commit-ID; Singular: die Commit-ID; Plural: die Commit-IDs
81
81
Commit-Beschreibung; Singular: die Commit-Beschreibung; Plural: die Commit-Beschreibungen; Alternativ: die Commit-Nachricht
82
82
|Contributor|
83
83
Mitwirkender; Beitragender
84
+
|to debug|
85
+
debuggen; er/sie debuggt; wir debuggen. (https://konjugator.reverso.net/konjugation-deutsch-verb-debuggen.html[Komplette Konjugationstabelle])
84
86
|Diff|
85
87
Diff; Singular: der Diff; Plural: die Diffs; Vorzugsweise die englische Version nutzen, alternativ kann auch die deutsche Übersetzung 'Vergleich oder Ausgabe eines Vergleichs' verwendet werden.
In addition to being primarily for version control, Git also provides a couple commands to help you debug your source code projects.
4
-
Because Git is designed to handle nearly any type of content, these tools are pretty generic, but they can often help you hunt for a bug or culprit when things go wrong.
3
+
Zusätzlich zu der primären Funktion der Versionskontrolle bietet Git auch ein paar Befehle, die Ihnen beim Debuggen Ihrer Quellcode-Projekte helfen.
4
+
Da Git für fast jede Art von Inhalt entwickelt wurde, sind diese Werkzeuge ziemlich allgemein, aber sie können Ihnen oft helfen, nach einem Fehler oder Schuldigen zu suchen, wenn etwas schief läuft.
5
5
6
6
[[_file_annotation]]
7
-
==== File Annotation
7
+
==== Datei-Annotationen
8
8
9
-
If you track down a bug in your code and want to know when it was introduced and why, file annotation is often your best tool.
10
-
It shows you what commit was the last to modify each line of any file.
11
-
So if you see that a method in your code is buggy, you can annotate the file with `git blame` to determine which commit was responsible for the introduction of that line.
9
+
Wenn Sie einen Fehler in Ihrem Code finden und wissen wollen, wann und warum er eingeführt wurde, ist die Datei-Annotation oft Ihr bestes Werkzeug.
10
+
Es zeigt Ihnen, welcher Commit als letzter jede Zeile einer Datei geändert hat.
11
+
Wenn Sie also sehen, dass eine Methode in Ihrem Code fehlerhaft ist, können Sie die Datei mit `git blame` annotieren, um festzustellen, welcher Commit für die Einführung dieser Zeile verantwortlich war.
12
12
13
-
The following example uses `git blame` to determine which commit and committer was responsible for lines in the top-level Linux kernel `Makefile` and, further, uses the `-L` option to restrict the output of the annotation to lines 69 through 82 of that file:
13
+
Das folgende Beispiel verwendet `git blame`, um zu bestimmen, welcher Commit und Committer für die Zeilen im `Makefile` des Linux-Kernels der obersten Ebene verantwortlich war. Außerdem verwendet es die Option `-L`, um die Ausgabe der Annotation auf die Zeilen 69 bis 82 dieser Datei zu beschränken:
066b7ed955808 (Michal Marek 2014-07-04 14:29:30 +0200 82) endif
32
32
----
33
33
34
-
Notice that the first field is the partial SHA-1 of the commit that last modified that line.
35
-
The next two fields are values extracted from that commit -- the author name and the authored date of that commit -- so you can easily see who modified that line and when.
36
-
After that come the line number and the content of the file.
37
-
Also note the `^1da177e4c3f4` commit lines, where the `^` prefix designates lines that were introduced in the repository's initial commit and have remained unchanged ever since.
38
-
This is a tad confusing, because now you've seen at least three different ways that Git uses the `^` to modify a commit SHA-1, but that is what it means here.
34
+
Beachten Sie, dass das erste Feld der partielle SHA-1 des Commits ist, der diese Zeile zuletzt geändert hat.
35
+
Die nächsten beiden Felder sind Werte, die aus diesem Commit extrahiert wurden -- der Name des Autors und das Datum dieses Commits -- so dass Sie leicht sehen können, wer diese Zeile wann geändert hat.
36
+
Danach folgen die Zeilennummer und der Inhalt der Datei.
37
+
Beachten Sie auch die `^1da177e4c3f4` Commit-Zeilen, wobei das `^`-Präfix Zeilen bezeichnet, die beim ersten Commit des Repositorys eingeführt wurden und seitdem unverändert geblieben sind.
38
+
Das ist ein bisschen verwirrend, denn jetzt haben Sie mindestens drei verschiedene Möglichkeiten gesehen, wie Git das Zeichen `^` verwendet, um einen Commit SHA-1 zu modifizieren, aber das ist es, was es hier bedeutet.
39
39
40
-
Another cool thing about Git is that it doesn't track file renames explicitly.
41
-
It records the snapshots and then tries to figure out what was renamed implicitly, after the fact.
42
-
One of the interesting features of this is that you can ask it to figure out all sorts of code movement as well.
43
-
If you pass `-C` to `git blame`, Git analyzes the file you're annotating and tries to figure out where snippets of code within it originally came from if they were copied from elsewhere.
44
-
For example, say you are refactoring a file named `GITServerHandler.m` into multiple files, one of which is `GITPackUpload.m`.
45
-
By blaming `GITPackUpload.m` with the `-C` option, you can see where sections of the code originally came from:
40
+
Eine weitere coole Sache an Git ist, dass es Dateiumbenennungen nicht explizit verfolgt.
41
+
Es zeichnet die Snapshots auf und versucht dann im Nachhinein herauszufinden, was implizit umbenannt wurde.
42
+
Eines der interessanten Features ist, dass man Git bitten kann, auch alle Arten von Codebewegungen herauszufinden.
43
+
Wenn Sie `-C` an `git blame` übergeben, analysiert Git die Datei, die Sie annotieren, und versucht herauszufinden, woher die Codeschnipsel darin ursprünglich kamen, wenn sie von woanders kopiert wurden.
44
+
Nehmen wir an, Sie zerlegen eine Datei namens `GITServerHandler.m` in mehrere Dateien, von denen eine `GITPackUpload.m` ist.
45
+
Indem Sie `GITPackUpload.m` mit `git blame -C` aufrufen, können Sie sehen, wo Abschnitte des Codes ursprünglich herkamen:
Normally, you get as the original commit the commit where you copied the code over, because that is the first time you touched those lines in this file.
67
-
Git tells you the original commit where you wrote those lines, even if it was in another file.
65
+
Das ist wirklich nützlich.
66
+
Normalerweise erhalten Sie als Original-Commit den Commit, wo Sie den Code hinüber kopiert haben, denn das ist das erste Mal, dass Sie diese Zeilen in dieser Datei berührt haben.
67
+
Mit der Option `-C` gibt Ihnen Git den ursprünglichen Commit, in dem Sie diese Zeilen geschrieben haben, auch wenn das in einer anderen Datei war.
68
68
69
69
[[_binary_search]]
70
-
==== Binary Search
70
+
==== Binärsuche
71
71
72
-
Annotating a file helps if you know where the issue is to begin with.
73
-
If you don't know what is breaking, and there have been dozens or hundreds of commits since the last state where you know the code worked, you'll likely turn to `git bisect` for help.
74
-
The `bisect` command does a binary search through your commit history to help you identify as quickly as possible which commit introduced an issue.
72
+
Das Annotieren einer Datei hilft, wenn Sie wissen, wo das Problem liegt.
73
+
Wenn Sie nicht wissen, was kaputt ist, und es gab Dutzende oder Hunderte von Commits seit dem letzten Zustand, von dem Sie wissen, dass der Code funktioniert hat, werden Sie sich wahrscheinlich an `git bisect` wenden, um Hilfe zu holen.
74
+
Der Befehl `bisect` führt eine binäre Suche durch Ihre Commit-Historie durch, um Ihnen zu helfen, so schnell wie möglich zu identifizieren, welcher Commit ein Problem eingeführt hat.
75
75
76
-
Let's say you just pushed out a release of your code to a production environment, you're getting bug reports about something that wasn't happening in your development environment, and you can't imagine why the code is doing that.
77
-
You go back to your code, and it turns out you can reproduce the issue, but you can't figure out what is going wrong.
78
-
You can _bisect_ the code to find out.
79
-
First you run `git bisect start` to get things going, and then you use `git bisect bad` to tell the system that the current commit you're on is broken.
80
-
Then, you must tell bisect when the last known good state was, using `git bisect good <good_commit>`:
76
+
Nehmen wir an, Sie haben gerade eine Version Ihres Codes in eine Produktionsumgebung ausgelagert, Sie erhalten Fehlerberichte über etwas, das nicht in Ihrer Entwicklungsumgebung passiert ist, und Sie können sich nicht vorstellen, warum der Code das tut.
77
+
Sie gehen zurück zu Ihrem Code und es stellt sich heraus, dass Sie den Fehler reproduzieren können, aber Sie können nicht herausfinden, was schief läuft.
78
+
Sie können den Code _halbieren_ (engl. bisect), um es herauszufinden.
79
+
Zuerst rufen Sie `git bisect start` auf, um die Dinge zum Laufen zu bringen. Dann benutzen Sie `git bisect bad`, um dem System mitzuteilen, dass der aktuelle Commit, auf dem Sie sind, nicht funktioniert.
80
+
Dann müssen Sie git bisect sagen, wann der letzte bekannte gute (funktionierende) Zustand war, indem Sie `git bisect good <good_commit>` verwenden:
81
81
82
82
[source,console]
83
83
----
@@ -88,10 +88,10 @@ Bisecting: 6 revisions left to test after this
88
88
[ecb6e1bc347ccecc5f9350d878ce677feb13d3b2] error handling on repo
89
89
----
90
90
91
-
Git figured out that about 12 commits came between the commit you marked as the last good commit (v1.0) and the current bad version, and it checked out the middle one for you.
92
-
At this point, you can run your test to see if the issue exists as of this commit.
93
-
If it does, then it was introduced sometime before this middle commit; if it doesn't, then the problem was introduced sometime after the middle commit.
94
-
It turns out there is no issue here, and you tell Git that by typing `git bisect good` and continue your journey:
91
+
Git hat herausgefunden, dass etwa 12 Commits zwischen dem Commit, den Sie als letzten guten Commit (v1.0) markiert haben, und der aktuellen schlechten Version liegen, und ist für Sie zu dem mittleren Commit gewechselt (interner `git checkout`).
92
+
An diesem Punkt können Sie Ihren Test durchführen, um zu sehen, ob der Fehler zum Zeitpunkt dieses Commits existiert.
93
+
Wenn ja, dann wurde er irgendwann vor diesem mittleren Commit eingeführt; wenn nicht, dann wurde das Problem irgendwann nach dem mittleren Commit eingeführt.
94
+
In diesem Beispiel stellt sich heraus, dass es hier kein Problem gibt, und Sie sagen Git das, indem Sie `git bisect good` tippen und Ihre Reise fortsetzen:
95
95
96
96
[source,console]
97
97
----
@@ -100,8 +100,8 @@ Bisecting: 3 revisions left to test after this
100
100
[b047b02ea83310a70fd603dc8cd7a6cd13d15c04] secure this thing
101
101
----
102
102
103
-
Now you're on another commit, halfway between the one you just tested and your bad commit.
104
-
You run your test again and find that this commit is broken, so you tell Git that with `git bisect bad`:
103
+
Jetzt sind Sie auf einem anderen Commit, auf halbem Weg zwischen dem, den Sie gerade getestet haben und Ihrem schlechten Commit.
104
+
Sie führen Ihren Test noch einmal durch und stellen fest, dass dieser Commit fehlerhaft ist. Also sagen Sie Git das mit `git bisect bad`:
105
105
106
106
[source,console]
107
107
----
@@ -110,8 +110,8 @@ Bisecting: 1 revisions left to test after this
110
110
[f71ce38690acf49c1f3c9bea38e09d82a5ce6014] drop exceptions table
111
111
----
112
112
113
-
This commit is fine, and now Git has all the information it needs to determine where the issue was introduced.
114
-
It tells you the SHA-1 of the first bad commit and show some of the commit information and which files were modified in that commit so you can figure out what happened that may have introduced this bug:
113
+
Dieser Commit ist in Ordnung, und jetzt hat Git alle Informationen, die es braucht, um festzustellen, wo das Problem eingeführt wurde.
114
+
Es gibt Ihnen den SHA-1 des ersten fehlerhaften Commits und zeigt einige der Commit-Informationen und welche Dateien in diesem Commit verändert wurden, so dass Sie herausfinden können, was diesen Fehler eingeführt haben könnte:
When you're finished, you should run `git bisect reset` to reset your HEAD to where you were before you started, or you'll end up in a weird state:
130
+
Wenn Sie fertig sind, sollten Sie `git bisect reset` ausführen, um Ihren HEAD wieder auf den Stand vor dem Start zurückzusetzen (ansonsten landen Sie in einem seltsamen Zustand):
131
131
132
132
[source,console]
133
133
----
134
134
$ git bisect reset
135
135
----
136
136
137
-
This is a powerful tool that can help you check hundreds of commits for an introduced bug in minutes.
138
-
In fact, if you have a script that will exit 0 if the project is good or non-0 if the project is bad, you can fully automate `git bisect`.
139
-
First, you again tell it the scope of the bisect by providing the known bad and good commits.
140
-
You can do this by listing them with the `bisect start` command if you want, listing the known bad commit first and the known good commit second:
137
+
Dies ist ein mächtiges Werkzeug, das Ihnen helfen kann, hunderte von Commits in Minuten auf einen eingeführten Fehler zu überprüfen.
138
+
Tatsächlich können Sie `git bisect` vollständig automatisieren, falls Sie ein Skript haben, das mit einer Ausgabe von 0 beendet, wenn das Projekt funktioniert und mit einer Ausgabe ungleich 0 beendet, wenn das Projekt nicht funktioniert.
139
+
Zuerst teilen Sie Git wieder den Umfang der Bisektion mit, indem Sie die bekannten schlechten und guten Commits angeben.
140
+
Sie können dies tun, indem Sie sie dem `bisect start`-Befehl den bekannten schlechten Commit zuerst und den bekannten guten Commit als zweiten Parameter geben:
141
141
142
142
[source,console]
143
143
----
144
144
$ git bisect start HEAD v1.0
145
145
$ git bisect run test-error.sh
146
146
----
147
147
148
-
Doing so automatically runs `test-error.sh` on each checked-out commit until Git finds the first broken commit.
149
-
You can also run something like `make` or `make tests` or whatever you have that runs automated tests for you.
148
+
Dabei wird automatisch `test-error.sh` bei jedem ausgecheckten Commit ausgeführt, bis Git den ersten fehlerhaften Commit findet.
149
+
Sie können auch etwas wie `make` or `make tests` oder was auch immer Sie haben, das automatische Tests für Sie ausführt, nutzen.
0 commit comments