Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
Browse files

Minor touch-ups.

  • Loading branch information...
commit c4b3698ce7f0b06ab0a7ab60175cbb5a3f5928b5 1 parent 89eb716
@blynn authored
View
17 de/basic.txt
@@ -1,13 +1,12 @@
== Grundlegendes ==
-
Bevor wir uns in ein Meer von Git-Befehlen stürzen, schauen wir uns ein paar einfache Beispiele
an. Obwohl "einfach", sind alle davon wichtig und nützlich.
Um erhlich zu sein, meine ersten Monate mit Git brauchte ich nicht mehr als in diesem Kapitel beschrieben steht.
=== Abspeichern ===
-Hast du irgendetwas dramatisches vor?
+Hast du irgendetwas dramatisches vor?
Nur zu, aber speichere deinen aktuellen Stand lieber nochmal ab:
$ git init
@@ -33,7 +32,7 @@ Falls git eine Datei "Vergessen" soll:
$ git rm ALTE_DATEI...
-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)
+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)
$ git mv ALTER_NAME NEUER_NAME
@@ -66,14 +65,14 @@ Um uns wieder der Computerspiel-analogie zuzuwenden:
- *`git reset --hard`*: Ein alten Stand laden und alle neueren Stände wegwerfen.
-- *`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)
+- *`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)
Du kannst auch nur einzelne Dateien oder Verzeichnisse wiederherstellen indem du sie an den Befehl anhängst:
$ git checkout SHA1_HASH eine.datei nocheine.datei
Aber sein Vorsichtig! diese art des Checkouts kann dateien überschreiben ohne das du etwas merkst.
-Um Unfälle zu vermeiden solltest du immer commiten befor du ein Checkout machst.
+Um Unfälle zu vermeiden solltest du immer commiten befor du ein Checkout machst.
Allgemein gilt: Im zweifel erst commiten, besonders am Anfang wenn du Git noch nicht so genau kennst.
Keine lust immer Hashes einzutippen? Nutze:
@@ -81,7 +80,7 @@ Keine lust immer Hashes einzutippen? Nutze:
$ git checkout :/"Mein erster Co"
um zu einem Commit zu springen dessen nachricht so anfängt
-Du kannst auch nach dem 5. letzten Commit fragen:
+Du kannst auch nach dem 5. letzten Commit fragen:
$ git checkout master~5
@@ -121,7 +120,7 @@ Wenn du schon eine Kopie eines Projektes hast, und dieses auf die letzte Version
=== Unverzügliches Veröffentlichen ===
-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
+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
aber nur wenn sie ihn für vorzeigbar halten.
Um dies in Git zu tun, gehe ins Verzeichniss in dem das script liegt:
@@ -133,7 +132,7 @@ Dann sage deinen Nutzern:
$ git clone dein.computer:/pfad/zum/script
-um dein Script zu Downloaden. Das Funtioniert nur wenn sie SSH-Zugriff haben, falls nicht, führe *git deamon* aus und
+um dein Script zu Downloaden. Das Funtioniert nur wenn sie SSH-Zugriff haben, falls nicht, führe *git deamon* aus und
sage den nutzern folgendes:
$ git clone git://dein.computer/pfad/zum/script
@@ -194,5 +193,5 @@ Wir sind bei D:
$ git revert B
-Welche ist die beste Lösung? Die die Dir am besten gefällt.
+Welche ist die beste Lösung? Die die Dir am besten gefällt.
Es ist einfach mit git das zu bekommen was du willst. und oft führen mehre Wege nach Rom.
View
22 en/branch.txt
@@ -59,7 +59,7 @@ What if you wanted to save the temporary changes after all? Easy:
$ git checkout -b dirty
-and commit before switching back to the master branch. Whenever you want to return to the dirty changes, simply type
+and commit before switching back to the master branch. Whenever you want to return to the dirty changes, simply type:
$ git checkout dirty
@@ -98,7 +98,11 @@ With some version control systems, creating branches is easy but merging them
back together is tough. With Git, merging is so trivial that you might be
unaware of it happening.
-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.
+We actually 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.
Ordinarily, a commit has exactly one 'parent commit', namely, the previous
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
could have multiple parents, so which one do we follow?
It turns out this notation chooses the first parent every time. This is
-desirable because commits in the current branch become the first parents during
-a merge; frequently you're only concerned with the changes you made in the
-current branch, as opposed to changes merged in from other branches.
+desirable because the current branch becomes the first parent during a merge;
+frequently you're only concerned with the changes you made in the current
+branch, as opposed to changes merged in from other branches.
You can refer to a specific parent with a caret. For example, to show
the logs from the second parent:
@@ -148,15 +152,15 @@ and often you'll want to go back and fix something in Part I.
If you're lucky, or very good, you can skip these lines.
$ git checkout master # Go back to Part I.
- $ edit files # Fix Part I.
+ $ fix_problem
+ $ git commit -a # Commit the fixes.
$ git checkout part2 # Go back to Part II.
$ git merge master # Merge in those fixes.
Eventually, Part I is approved:
$ git checkout master # Go back to Part I.
- $ some_command # Some command you're supposed to run when the
- # current working directory is officially ready.
+ $ submit files # Release to the world!
$ git merge part2 # Merge in Part II.
$ git branch -d part2
@@ -237,7 +241,7 @@ commands.
Consider web browsers. Why support multiple tabs as well as multiple windows?
Because allowing both accommodates a wide variety of styles. Some users like to
keep only one browser window open, and use tabs for multiple webpages. Others
-might insist on the other extreme: multiple windows with no extra tabs anywhere.
+might insist on the other extreme: multiple windows with no tabs anywhere.
Others still prefer something in between.
Branching is like tabs for your working directory, and cloning is like opening
View
33 en/grandmaster.txt
@@ -164,7 +164,7 @@ One popular resident is +workdir/git-new-workdir+. Via clever symlinking, this s
$ git-new-workdir an/existing/repo new/directory
-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.
+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.
=== Daring Stunts ===
@@ -205,23 +205,12 @@ Next time, that pesky command will work!
=== Preventing Bad Commits ===
-Stupid mistakes abound in the histories of many of my projects. The most
-frightening are missing files due to a forgotten *git add*. Luckily I
-have yet to lose crucial data though accidental omission because I rarely
-delete original working directories. I typically notice the error a few commits
-later, so the only damage is a bit of missing history and a sheepish admission
-of guilt.
-
-I also regularly commit (literally and git-erally) the lesser transgression of
-trailing whitespace. Though harmless, I wish these also never appeared on the
+Stupid mistakes pollute my repositories. Most frightening are missing files due
+to a forgotten *git add*. Lesser transgressions are trailing whitespace and
+unresolved merge conflicts: though harmless, I wish these never appeared on the
public record.
-In addition, though unscathed so far, I worry about leaving merge conflicts
-unresolved. Usually I catch them when I build a project, but there are some
-cases this can overlook.
-
-If only I had bought idiot insurance by using a _hook_ to alert me about these
-problems:
+If only I had bought idiot insurance by using a _hook_ to alert me about these problems:
$ cd .git/hooks
$ 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
exit 1
fi
-Several git operations support hooks; see *git help hooks*. One can write hooks
-to complain about spelling mistakes in commit messages, add new files, indent
-paragraphs, append an entry to a webpage, play a sound, and so on.
-
-We activated the sample *post-update* hook earlier when discussing Git over
-HTTP; this causes Git to run this script whenever the head has moved. The
-sample post-update script updates a few files Git needs for communication over
-Git-agnostic transports such as HTTP.
+Several git operations support hooks; see *git help hooks*. We activated the
+sample *post-update* hook earlier when discussing Git over HTTP. This runs
+whenever the head moves. The sample post-update script updates files Git needs
+for communication over Git-agnostic transports such as HTTP.
View
2  en/history.txt
@@ -8,7 +8,7 @@ differs to yours, you will have trouble reconciling when your trees interact.
Some developers strongly feel history should be immutable, warts and all.
Others feel trees should be made presentable before they are unleashed in
-public. Git accommodates both viewpoints. Like cloning, branching and merging,
+public. Git accommodates both viewpoints. Like cloning, branching, and merging,
rewriting history is simply another power Git gives you. It is up to you
to use it wisely.
View
4 en/preface.txt
@@ -31,8 +31,8 @@ Dustin Sallings, Alberto Bertogli, James Cameron, Douglas Livingstone, Michael B
François Marier maintains the Debian package originally created by Daniel
Baumann.
-JunJie, Meng, JiangWei, Rodrigo Toledo, and Leonardo Siqueira Rodrigues
-worked on translations of this guide.
+JunJie, Meng, JiangWei, Rodrigo Toledo, Leonardo Siqueira Rodrigues, and
+Benjamin Bellee worked on translations of this guide.
My gratitude goes to many others for your support and praise. I'm tempted to
quote you here, but it might raise expectations to ridiculous heights.
View
10 en/secrets.txt
@@ -33,12 +33,10 @@ For every tracked file, Git records information such as its size, creation time
Since stat calls are considerably faster than file reads, if you only edit a
few files, Git can update its state in almost no time.
-We stated earlier that the index is a staging area. Then how can the index
-just be a bunch of file stats?
-
-The index can be thought of as a staging area because the add command puts
-files into Git's database and updates the index accordingly, while the commit
-command, without options, creates a commit based on the state of the index.
+We stated earlier that the index is a staging area. Why is a bunch of file
+stats a staging area? Because the add command puts files into Git's database
+and updates these stats, while the commit command, without options, creates a
+commit based only on these stats and the files already in the database.
=== Git's Origins ===
Please sign in to comment.
Something went wrong with that request. Please try again.