Skip to content
This repository
Browse code

Minor touch-ups.

  • Loading branch information...
commit c4b3698ce7f0b06ab0a7ab60175cbb5a3f5928b5 1 parent 89eb716
Ben Lynn authored September 19, 2010
17  de/basic.txt
... ...
@@ -1,13 +1,12 @@
1 1
 == Grundlegendes ==
2 2
 
3  
-
4 3
 Bevor wir uns in ein Meer von Git-Befehlen stürzen, schauen wir uns ein paar einfache Beispiele
5 4
 an. Obwohl "einfach", sind alle davon wichtig und nützlich.
6 5
 Um erhlich zu sein, meine ersten Monate mit Git brauchte ich nicht mehr als in diesem Kapitel beschrieben steht.
7 6
 
8 7
 === Abspeichern ===
9 8
 
10  
-Hast du irgendetwas dramatisches vor? 
  9
+Hast du irgendetwas dramatisches vor?
11 10
 Nur zu, aber speichere deinen aktuellen Stand lieber nochmal ab:
12 11
 
13 12
  $ git init
@@ -33,7 +32,7 @@ Falls git eine Datei "Vergessen" soll:
33 32
 
34 33
  $ git rm ALTE_DATEI...
35 34
 
36  
-Eine Datei umzubenennen bedeutet im Endeffekt dasselbe wie sie zu löschen und unter neuem Namen hinzuzufügen. Git benutzt hierzu mv (selber syntax wie mv (1) 
  35
+Eine Datei umzubenennen bedeutet im Endeffekt dasselbe wie sie zu löschen und unter neuem Namen hinzuzufügen. Git benutzt hierzu mv (selber syntax wie mv (1)
37 36
 
38 37
  $ git mv ALTER_NAME NEUER_NAME
39 38
 
@@ -66,14 +65,14 @@ Um uns wieder der Computerspiel-analogie zuzuwenden:
66 65
 
67 66
 - *`git reset --hard`*: Ein alten Stand laden und alle neueren Stände wegwerfen.
68 67
 
69  
-- *`git checkout`*: Einen alten Spielstand laden. Wenn du hier weiterspielst, weichst du von der bisherigen Realität ab und kommst in ein paraleluniversum (branch, reden wir später drüber) 
  68
+- *`git checkout`*: Einen alten Spielstand laden. Wenn du hier weiterspielst, weichst du von der bisherigen Realität ab und kommst in ein paraleluniversum (branch, reden wir später drüber)
70 69
 
71 70
 Du kannst auch nur einzelne Dateien oder Verzeichnisse wiederherstellen indem du sie an den Befehl anhängst:
72 71
 
73 72
  $ git checkout SHA1_HASH eine.datei nocheine.datei
74 73
 
75 74
 Aber sein Vorsichtig! diese art des Checkouts kann dateien überschreiben ohne das du etwas merkst.
76  
-Um Unfälle zu vermeiden solltest du immer commiten befor du ein Checkout machst. 
  75
+Um Unfälle zu vermeiden solltest du immer commiten befor du ein Checkout machst.
77 76
 Allgemein gilt: Im zweifel erst commiten, besonders am Anfang wenn du Git noch nicht so genau kennst.
78 77
 
79 78
 Keine lust immer Hashes einzutippen? Nutze:
@@ -81,7 +80,7 @@ Keine lust immer Hashes einzutippen? Nutze:
81 80
  $ git checkout :/"Mein erster Co"
82 81
 
83 82
 um zu einem Commit zu springen dessen nachricht so anfängt
84  
-Du kannst auch nach dem 5. letzten Commit fragen: 
  83
+Du kannst auch nach dem 5. letzten Commit fragen:
85 84
 
86 85
  $ git checkout master~5
87 86
 
@@ -121,7 +120,7 @@ Wenn du schon eine Kopie eines Projektes hast, und dieses auf die letzte Version
121 120
 
122 121
 === Unverzügliches Veröffentlichen ===
123 122
 
124  
-Nehmen wir an du hast ein Script geschrieben und möchtest es anderen zugänglich machen. Du könntest sie einfach bitten es immer von deinem Computer herunterzuladen, aber falls sie das tun während du experimentierst oder das Script verbessert könnten sie eine fehlerhafte Version bekommen. Genau deswegen gibt es Releasezyklen. Entwickler arbeiten regelmäßig an einem Projekt, veröffentlichen den Code 
  123
+Nehmen wir an du hast ein Script geschrieben und möchtest es anderen zugänglich machen. Du könntest sie einfach bitten es immer von deinem Computer herunterzuladen, aber falls sie das tun während du experimentierst oder das Script verbessert könnten sie eine fehlerhafte Version bekommen. Genau deswegen gibt es Releasezyklen. Entwickler arbeiten regelmäßig an einem Projekt, veröffentlichen den Code
125 124
 aber nur wenn sie ihn für vorzeigbar halten.
126 125
 Um dies in Git zu tun, gehe ins Verzeichniss in dem das script liegt:
127 126
 
@@ -133,7 +132,7 @@ Dann sage deinen Nutzern:
133 132
 
134 133
  $ git clone dein.computer:/pfad/zum/script
135 134
 
136  
-um dein Script zu Downloaden. Das Funtioniert nur wenn sie SSH-Zugriff haben, falls nicht, führe *git deamon* aus und 
  135
+um dein Script zu Downloaden. Das Funtioniert nur wenn sie SSH-Zugriff haben, falls nicht, führe *git deamon* aus und
137 136
 sage den nutzern folgendes:
138 137
 
139 138
  $ git clone git://dein.computer/pfad/zum/script
@@ -194,5 +193,5 @@ Wir sind bei D:
194 193
 
195 194
    $ git revert B
196 195
 
197  
-Welche ist die beste Lösung? Die die Dir am besten gefällt. 
  196
+Welche ist die beste Lösung? Die die Dir am besten gefällt.
198 197
 Es ist einfach mit git das zu bekommen was du willst. und oft führen mehre Wege nach Rom.
22  en/branch.txt
@@ -59,7 +59,7 @@ What if you wanted to save the temporary changes after all? Easy:
59 59
 
60 60
  $ git checkout -b dirty
61 61
 
62  
-and commit before switching back to the master branch. Whenever you want to return to the dirty changes, simply type
  62
+and commit before switching back to the master branch. Whenever you want to return to the dirty changes, simply type:
63 63
 
64 64
  $ git checkout dirty
65 65
 
@@ -98,7 +98,11 @@ With some version control systems, creating branches is easy but merging them
98 98
 back together is tough. With Git, merging is so trivial that you might be
99 99
 unaware of it happening.
100 100
 
101  
-Indeed, though we have just introduced *git merge*, we encountered merging long ago. The *pull* command in fact fetches commits and then merges them into your current branch. If you have no local changes, then the merge is a 'fast forward', a degenerate case akin to fetching the latest version in a centralized version control system. But if you do have local changes, Git will automatically merge, and report any conflicts.
  101
+We actually encountered merging long ago. The *pull* command in fact 'fetches'
  102
+commits and then merges them into your current branch. If you have no local
  103
+changes, then the merge is a 'fast forward', a degenerate case akin to fetching
  104
+the latest version in a centralized version control system. But if you do have
  105
+local changes, Git will automatically merge, and report any conflicts.
102 106
 
103 107
 Ordinarily, a commit has exactly one 'parent commit', namely, the previous
104 108
 commit. Merging branches together produces a commit with at least two parents.
@@ -106,9 +110,9 @@ This begs the question: what commit does `HEAD~10` really refer to? A commit
106 110
 could have multiple parents, so which one do we follow?
107 111
 
108 112
 It turns out this notation chooses the first parent every time. This is
109  
-desirable because commits in the current branch become the first parents during
110  
-a merge; frequently you're only concerned with the changes you made in the
111  
-current branch, as opposed to changes merged in from other branches.
  113
+desirable because the current branch becomes the first parent during a merge;
  114
+frequently you're only concerned with the changes you made in the current
  115
+branch, as opposed to changes merged in from other branches.
112 116
 
113 117
 You can refer to a specific parent with a caret. For example, to show
114 118
 the logs from the second parent:
@@ -148,15 +152,15 @@ and often you'll want to go back and fix something in Part I.
148 152
 If you're lucky, or very good, you can skip these lines.
149 153
 
150 154
  $ git checkout master  # Go back to Part I.
151  
- $ edit files           # Fix Part I.
  155
+ $ fix_problem
  156
+ $ git commit -a        # Commit the fixes.
152 157
  $ git checkout part2   # Go back to Part II.
153 158
  $ git merge master     # Merge in those fixes.
154 159
 
155 160
 Eventually, Part I is approved:
156 161
 
157 162
  $ git checkout master  # Go back to Part I.
158  
- $ some_command         # Some command you're supposed to run when the
159  
-                        # current working directory is officially ready.
  163
+ $ submit files         # Release to the world!
160 164
  $ git merge part2      # Merge in Part II.
161 165
  $ git branch -d part2
162 166
 
@@ -237,7 +241,7 @@ commands.
237 241
 Consider web browsers. Why support multiple tabs as well as multiple windows?
238 242
 Because allowing both accommodates a wide variety of styles. Some users like to
239 243
 keep only one browser window open, and use tabs for multiple webpages. Others
240  
-might insist on the other extreme: multiple windows with no extra tabs anywhere.
  244
+might insist on the other extreme: multiple windows with no tabs anywhere.
241 245
 Others still prefer something in between.
242 246
 
243 247
 Branching is like tabs for your working directory, and cloning is like opening
33  en/grandmaster.txt
@@ -164,7 +164,7 @@ One popular resident is +workdir/git-new-workdir+. Via clever symlinking, this s
164 164
 
165 165
   $ git-new-workdir an/existing/repo new/directory
166 166
 
167  
-The new directory and the files within can be thought of as a clone, except since the history is shared, the two trees automatically stay in sync. There's no need to merge, push or pull.
  167
+The new directory and the files within can be thought of as a clone, except since the history is shared, the two trees automatically stay in sync. There's no need to merge, push, or pull.
168 168
 
169 169
 === Daring Stunts ===
170 170
 
@@ -205,23 +205,12 @@ Next time, that pesky command will work!
205 205
 
206 206
 === Preventing Bad Commits ===
207 207
 
208  
-Stupid mistakes abound in the histories of many of my projects. The most
209  
-frightening are missing files due to a forgotten *git add*. Luckily I
210  
-have yet to lose crucial data though accidental omission because I rarely
211  
-delete original working directories. I typically notice the error a few commits
212  
-later, so the only damage is a bit of missing history and a sheepish admission
213  
-of guilt.
214  
-
215  
-I also regularly commit (literally and git-erally) the lesser transgression of
216  
-trailing whitespace. Though harmless, I wish these also never appeared on the
  208
+Stupid mistakes pollute my repositories. Most frightening are missing files due
  209
+to a forgotten *git add*. Lesser transgressions are trailing whitespace and
  210
+unresolved merge conflicts: though harmless, I wish these never appeared on the
217 211
 public record.
218 212
 
219  
-In addition, though unscathed so far, I worry about leaving merge conflicts
220  
-unresolved. Usually I catch them when I build a project, but there are some
221  
-cases this can overlook.
222  
-
223  
-If only I had bought idiot insurance by using a _hook_ to alert me about these
224  
-problems:
  213
+If only I had bought idiot insurance by using a _hook_ to alert me about these problems:
225 214
 
226 215
  $ cd .git/hooks
227 216
  $ cp pre-commit.sample pre-commit  # Older Git versions: chmod +x pre-commit
@@ -237,11 +226,7 @@ For this guide, I eventually added the following to the beginning of the
237 226
    exit 1
238 227
  fi
239 228
 
240  
-Several git operations support hooks; see *git help hooks*. One can write hooks
241  
-to complain about spelling mistakes in commit messages, add new files, indent
242  
-paragraphs, append an entry to a webpage, play a sound, and so on.
243  
-
244  
-We activated the sample *post-update* hook earlier when discussing Git over
245  
-HTTP; this causes Git to run this script whenever the head has moved. The
246  
-sample post-update script updates a few files Git needs for communication over
247  
-Git-agnostic transports such as HTTP.
  229
+Several git operations support hooks; see *git help hooks*. We activated the
  230
+sample *post-update* hook earlier when discussing Git over HTTP. This runs
  231
+whenever the head moves. The sample post-update script updates files Git needs
  232
+for communication over Git-agnostic transports such as HTTP.
2  en/history.txt
@@ -8,7 +8,7 @@ differs to yours, you will have trouble reconciling when your trees interact.
8 8
 
9 9
 Some developers strongly feel history should be immutable, warts and all.
10 10
 Others feel trees should be made presentable before they are unleashed in
11  
-public. Git accommodates both viewpoints. Like cloning, branching and merging,
  11
+public. Git accommodates both viewpoints. Like cloning, branching, and merging,
12 12
 rewriting history is simply another power Git gives you. It is up to you
13 13
 to use it wisely.
14 14
 
4  en/preface.txt
@@ -31,8 +31,8 @@ Dustin Sallings, Alberto Bertogli, James Cameron, Douglas Livingstone, Michael B
31 31
 François Marier maintains the Debian package originally created by Daniel
32 32
 Baumann.
33 33
 
34  
-JunJie, Meng, JiangWei, Rodrigo Toledo, and Leonardo Siqueira Rodrigues
35  
-worked on translations of this guide.
  34
+JunJie, Meng, JiangWei, Rodrigo Toledo, Leonardo Siqueira Rodrigues, and
  35
+Benjamin Bellee worked on translations of this guide.
36 36
 
37 37
 My gratitude goes to many others for your support and praise. I'm tempted to
38 38
 quote you here, but it might raise expectations to ridiculous heights.
10  en/secrets.txt
@@ -33,12 +33,10 @@ For every tracked file, Git records information such as its size, creation time
33 33
 Since stat calls are considerably faster than file reads, if you only edit a
34 34
 few files, Git can update its state in almost no time.
35 35
 
36  
-We stated earlier that the index is a staging area. Then how can the index
37  
-just be a bunch of file stats?
38  
-
39  
-The index can be thought of as a staging area because the add command puts
40  
-files into Git's database and updates the index accordingly, while the commit
41  
-command, without options, creates a commit based on the state of the index.
  36
+We stated earlier that the index is a staging area. Why is a bunch of file
  37
+stats a staging area? Because the add command puts files into Git's database
  38
+and updates these stats, while the commit command, without options, creates a
  39
+commit based only on these stats and the files already in the database.
42 40
 
43 41
 === Git's Origins ===
44 42
 

0 notes on commit c4b3698

Please sign in to comment.
Something went wrong with that request. Please try again.