Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

[de] Synchronize with En version #671

Merged
merged 2 commits into from

2 participants

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Commits on Feb 11, 2014
  1. @YueLinHo
  2. @YueLinHo

    Synchronize with de version

    YueLinHo authored
This page is out of date. Refresh to see the latest.
View
4 de/01-introduction/01-chapter1.markdown
@@ -252,8 +252,8 @@ Nachdem Du die genannten Bibliotheken installiert hast, besorge Dir die aktuelle
Danach kannst Du dann Git kompilieren und installieren:
- $ tar -zxf git-1.6.0.5.tar.gz
- $ cd git-1.6.0.5
+ $ tar -zxf git-1.7.2.2.tar.gz
+ $ cd git-1.7.2.2
$ make prefix=/usr/local all
$ sudo make prefix=/usr/local install
View
297 de/02-git-basics/01-chapter2.markdown
@@ -92,8 +92,8 @@ Bild 2-1. Zyklus der Grundzustände Deiner Dateien
Das wichtigste Hilfsmittel, um den Zustand zu überprüfen, in dem sich die Dateien in Deinem Repository gerade befinden, ist der Befehl `git status`. Wenn Du diesen Befehl unmittelbar nach dem Klonen eines Repositorys ausführst, sollte er folgende Ausgabe liefern:
$ git status
- # On branch master
- nothing to commit (working directory clean)
+ On branch master
+ nothing to commit, working directory clean
<!--This means you have a clean working directory — in other words, no tracked files are modified. Git also doesn’t see any untracked files, or they would be listed here. Finally, the command tells you which branch you’re on. For now, that is always `master`, which is the default; you won’t worry about it here. The next chapter will go over branches and references in detail.-->
@@ -105,11 +105,12 @@ Sagen wir Du fügst eine neue `README` Datei zu Deinem Projekt hinzu. Wenn die D
$ vim README
$ git status
- # On branch master
- # Untracked files:
- # (use "git add <file>..." to include in what will be committed)
- #
- # README
+ On branch master
+ Untracked files:
+ (use "git add <file>..." to include in what will be committed)
+
+ README
+
nothing added to commit but untracked files present (use "git add" to track)
<!--You can see that your new `README` file is untracked, because it’s under the “Untracked files” heading in your status output. Untracked basically means that Git sees a file you didn’t have in the previous snapshot (commit); Git won’t start including it in your commit snapshots until you explicitly tell it to do so. It does this so you don’t accidentally begin including generated binary files or other files that you did not mean to include. You do want to start including README, so let’s start tracking the file.-->
@@ -130,12 +131,12 @@ Um eine neue Datei zur Versionskontrolle hinzuzufügen, verwendest Du den Befehl
Wenn Du den `git status` Befehl erneut ausführst, siehst Du, dass sich Deine `README` Datei jetzt unter Versionskontrolle befindet und für den nächsten Commit vorgemerkt ist (gestaged ist):
$ git status
- # On branch master
- # Changes to be committed:
- # (use "git reset HEAD <file>..." to unstage)
- #
- # new file: README
- #
+ On branch master
+ Changes to be committed:
+ (use "git reset HEAD <file>..." to unstage)
+
+ new file: README
+
<!--You can tell that it’s staged because it’s under the “Changes to be committed” heading. If you commit at this point, the version of the file at the time you ran `git add` is what will be in the historical snapshot. You may recall that when you ran `git init` earlier, you then ran `git add (files)` — that was to begin tracking files in your directory. The `git add` command takes a path name for either a file or a directory; if it’s a directory, the command adds all the files in that directory recursively.-->
@@ -149,17 +150,18 @@ Dass die Datei für den nächsten Commit vorgemerkt ist, siehst Du daran, dass s
Wenn Du eine bereits versionierte Datei `benchmarks.rb` änderst und den `git status` Befehl ausführst, erhältst Du folgendes:
$ git status
- # On branch master
- # Changes to be committed:
- # (use "git reset HEAD <file>..." to unstage)
- #
- # new file: README
- #
- # Changes not staged for commit:
- # (use "git add <file>..." to update what will be committed)
- #
- # modified: benchmarks.rb
- #
+ On branch master
+ Changes to be committed:
+ (use "git reset HEAD <file>..." to unstage)
+
+ new file: README
+
+ Changes not staged for commit:
+ (use "git add <file>..." to update what will be committed)
+ (use "git checkout -- <file>..." to discard changes in working directory)
+
+ modified: benchmarks.rb
+
<!--The `benchmarks.rb` file appears under a section named “Changes not staged for commit” — which means that a file that is tracked has been modified in the working directory but not yet staged. To stage it, you run the `git add` command (it’s a multipurpose command — you use it to begin tracking new files, to stage files, and to do other things like marking merge-conflicted files as resolved). Let’s run `git add` now to stage the `benchmarks.rb` file, and then run `git status` again:-->
@@ -167,13 +169,13 @@ Die Datei `benchmarks.rb` erscheint in der Sektion „Changes not staged for com
$ git add benchmarks.rb
$ git status
- # On branch master
- # Changes to be committed:
- # (use "git reset HEAD <file>..." to unstage)
- #
- # new file: README
- # modified: benchmarks.rb
- #
+ On branch master
+ Changes to be committed:
+ (use "git reset HEAD <file>..." to unstage)
+
+ new file: README
+ modified: benchmarks.rb
+
<!--Both files are staged and will go into your next commit. At this point, suppose you remember one little change that you want to make in `benchmarks.rb` before you commit it. You open it again and make that change, and you’re ready to commit. However, let’s run `git status` one more time:-->
@@ -181,18 +183,19 @@ Beide Dateien sind nun für den nächsten Commit vorgemerkt. Nehmen wir an, Du w
$ vim benchmarks.rb
$ git status
- # On branch master
- # Changes to be committed:
- # (use "git reset HEAD <file>..." to unstage)
- #
- # new file: README
- # modified: benchmarks.rb
- #
- # Changes not staged for commit:
- # (use "git add <file>..." to update what will be committed)
- #
- # modified: benchmarks.rb
- #
+ On branch master
+ Changes to be committed:
+ (use "git reset HEAD <file>..." to unstage)
+
+ new file: README
+ modified: benchmarks.rb
+
+ Changes not staged for commit:
+ (use "git add <file>..." to update what will be committed)
+ (use "git checkout -- <file>..." to discard changes in working directory)
+
+ modified: benchmarks.rb
+
<!--What the heck? Now `benchmarks.rb` is listed as both staged and unstaged. How is that possible? It turns out that Git stages a file exactly as it is when you run the `git add` command. If you commit now, the version of `benchmarks.rb` as it was when you last ran the `git add` command is how it will go into the commit, not the version of the file as it looks in your working directory when you run `git commit`. If you modify a file after you run `git add`, you have to run `git add` again to stage the latest version of the file:-->
@@ -200,13 +203,13 @@ Huch, was ist das? Jetzt wird `benchmarks.rb` sowohl in der Staging Area als auc
$ git add benchmarks.rb
$ git status
- # On branch master
- # Changes to be committed:
- # (use "git reset HEAD <file>..." to unstage)
- #
- # new file: README
- # modified: benchmarks.rb
- #
+ On branch master
+ Changes to be committed:
+ (use "git reset HEAD <file>..." to unstage)
+
+ new file: README
+ modified: benchmarks.rb
+
<!--### Ignoring Files ###-->
### Dateien ignorieren ###
@@ -289,17 +292,18 @@ Wenn Dir die Ausgabe des Befehl `git status` nicht aussagekräftig genug ist, we
Nehmen wir an, Du hast die Datei `README` geändert und für einen Commit in der Staging Area vorgemerkt. Dann änderst Du außerdem die Datei `benchmarks.rb`, fügst sie aber noch nicht zur Staging Area hinzu. Wenn Du den `git status` Befehl dann ausführst, zeigt er Dir in etwa Folgendes an:
$ git status
- # On branch master
- # Changes to be committed:
- # (use "git reset HEAD <file>..." to unstage)
- #
- # new file: README
- #
- # Changes not staged for commit:
- # (use "git add <file>..." to update what will be committed)
- #
- # modified: benchmarks.rb
- #
+ On branch master
+ Changes to be committed:
+ (use "git reset HEAD <file>..." to unstage)
+
+ new file: README
+
+ Changes not staged for commit:
+ (use "git add <file>..." to update what will be committed)
+ (use "git checkout -- <file>..." to discard changes in working directory)
+
+ modified: benchmarks.rb
+
<!--To see what you’ve changed but not yet staged, type `git diff` with no other arguments:-->
@@ -354,16 +358,18 @@ Ein anderes Beispiel: Wenn Du Änderungen an der Datei `benchmarks.rb` bereits z
$ git add benchmarks.rb
$ echo '# test line' >> benchmarks.rb
$ git status
- # On branch master
- #
- # Changes to be committed:
- #
- # modified: benchmarks.rb
- #
- # Changes not staged for commit:
- #
- # modified: benchmarks.rb
- #
+ On branch master
+ Changes to be committed:
+ (use "git reset HEAD <file>..." to unstage)
+
+ modified: benchmarks.rb
+
+ Changes not staged for commit:
+ (use "git add <file>..." to update what will be committed)
+ (use "git checkout -- <file>..." to discard changes in working directory)
+
+ modified: benchmarks.rb
+
<!--Now you can use `git diff` to see what is still unstaged-->
@@ -423,10 +429,9 @@ Der Editor zeigt in etwa folgenden Text an (dies ist ein Beispiel mit vim):
# with '#' will be ignored, and an empty message aborts the commit.
# On branch master
# Changes to be committed:
- # (use "git reset HEAD <file>..." to unstage)
- #
# new file: README
# modified: benchmarks.rb
+ #
~
~
~
@@ -441,8 +446,8 @@ Du siehst, dass die vorausgefüllte Commit Meldung die Ausgabe des letzten `git
Alternativ kannst Du die Commit Meldung direkt mit dem Befehl `git commit` angeben, indem Du die Option `-m` wie folgt verwendest:
$ git commit -m "Story 182: Fix benchmarks for speed"
- [master]: created 463dc4f: "Fix benchmarks for speed"
- 2 files changed, 3 insertions(+), 0 deletions(-)
+ [master 463dc4f] Fix benchmarks for speed
+ 2 files changed, 3 insertions(+)
create mode 100644 README
<!--Now you’ve created your first commit! You can see that the commit has given you some output about itself: which branch you committed to (`master`), what SHA-1 checksum the commit has (`463dc4f`), how many files were changed, and statistics about lines added and removed in the commit.-->
@@ -461,15 +466,17 @@ Denke daran, dass jeder neue Commit denjenigen Snapshot aufzeichnet, den Du in d
Obwohl die Staging Area unglaublich nützlich ist, um genau diejenigen Commits anzulegen, die Du in Deiner Projekt Historie haben willst, ist sie manchmal auch ein bisschen umständlich. Git stellt Dir deshalb eine Alternative zur Verfügung, mit der Du die Staging Area überspringen kannst. Wenn Du den Befehl `git commit` mit der Option `-a` ausführst, übernimmt Git automatisch alle Änderungen an dejenigen Dateien, die sich bereits unter Versionskontrolle befinden, in den Commit – sodass Du auf diese Weise den Schritt `git add` weglassen kannst:
$ git status
- # On branch master
- #
- # Changes not staged for commit:
- #
- # modified: benchmarks.rb
- #
+ On branch master
+ Changes not staged for commit:
+ (use "git add <file>..." to update what will be committed)
+ (use "git checkout -- <file>..." to discard changes in working directory)
+
+ modified: benchmarks.rb
+
+ no changes added to commit (use "git add" and/or "git commit -a")
$ git commit -a -m 'added new benchmarks'
[master 83e38c7] added new benchmarks
- 1 files changed, 5 insertions(+), 0 deletions(-)
+ 1 files changed, 5 insertions(+)
<!--Notice how you don’t have to run `git add` on the `benchmarks.rb` file in this case before you commit.-->
@@ -488,13 +495,14 @@ Wenn Du einfach nur eine Datei aus dem Arbeitsverzeichnis löschst, wird sie in
$ rm grit.gemspec
$ git status
- # On branch master
- #
- # Changes not staged for commit:
- # (use "git add/rm <file>..." to update what will be committed)
- #
- # deleted: grit.gemspec
- #
+ On branch master
+ Changes not staged for commit:
+ (use "git add/rm <file>..." to update what will be committed)
+ (use "git checkout -- <file>..." to discard changes in working directory)
+
+ deleted: grit.gemspec
+
+ no changes added to commit (use "git add" and/or "git commit -a")
<!--Then, if you run `git rm`, it stages the file’s removal:-->
@@ -503,13 +511,12 @@ Wenn Du jetzt `git rm` ausführst, wird diese Änderung für den nächsten Commi
$ git rm grit.gemspec
rm 'grit.gemspec'
$ git status
- # On branch master
- #
- # Changes to be committed:
- # (use "git reset HEAD <file>..." to unstage)
- #
- # deleted: grit.gemspec
- #
+ On branch master
+ Changes to be committed:
+ (use "git reset HEAD <file>..." to unstage)
+
+ deleted: grit.gemspec
+
<!--The next time you commit, the file will be gone and no longer tracked. If you modified the file and added it to the index already, you must force the removal with the `-f` option. This is a safety feature to prevent accidental removal of data that hasn’t yet been recorded in a snapshot and that can’t be recovered from Git.-->
@@ -556,14 +563,12 @@ Das funktioniert einwandfrei. Wenn Du diesen Befehl ausführst und danach den `g
$ git mv README.txt README
$ git status
- # On branch master
- # Your branch is ahead of 'origin/master' by 1 commit.
- #
- # Changes to be committed:
- # (use "git reset HEAD <file>..." to unstage)
- #
- # renamed: README.txt -> README
- #
+ On branch master
+ Changes to be committed:
+ (use "git reset HEAD <file>..." to unstage)
+
+ renamed: README.txt -> README
+
<!--However, this is equivalent to running something like this:-->
Allerdings kannst Du genauso folgendes tun:
@@ -704,7 +709,7 @@ Außerdem gibt es verschiedene Optionen, die nützlich sind, um Dinge zusammenzu
changed the version number
Rakefile | 2 +-
- 1 files changed, 1 insertions(+), 1 deletions(-)
+ 1 file changed, 1 insertion(+), 1 deletion(-)
commit 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7
Author: Scott Chacon <schacon@gee-mail.com>
@@ -713,7 +718,7 @@ Außerdem gibt es verschiedene Optionen, die nützlich sind, um Dinge zusammenzu
removed unnecessary test code
lib/simplegit.rb | 5 -----
- 1 files changed, 0 insertions(+), 5 deletions(-)
+ 1 file changed, 5 deletions(-)
commit a11bef06a3f659402fe7563abf99ad00de2209e6
Author: Scott Chacon <schacon@gee-mail.com>
@@ -724,7 +729,7 @@ Außerdem gibt es verschiedene Optionen, die nützlich sind, um Dinge zusammenzu
README | 6 ++++++
Rakefile | 23 +++++++++++++++++++++++
lib/simplegit.rb | 25 +++++++++++++++++++++++++
- 3 files changed, 54 insertions(+), 0 deletions(-)
+ 3 files changed, 54 insertions(+)
<!--As you can see, the `-\-stat` option prints below each commit entry a list of modified files, how many files were changed, and how many lines in those files were added and removed. It also puts a summary of the information at the end.-->
<!--Another really useful option is `-\-pretty`. This option changes the log output to formats other than the default. A few prebuilt options are available for you to use. The `oneline` option prints each commit on a single line, which is useful if you’re looking at a lot of commits. In addition, the `short`, `full`, and `fuller` options show the output in roughly the same format but with less or more information, respectively:-->
@@ -960,33 +965,34 @@ Die nächsten zwei Abschnitte gehen darauf ein, wie Du Änderungen in der Stagin
$ git add .
$ git status
- # On branch master
- # Changes to be committed:
- # (use "git reset HEAD <file>..." to unstage)
- #
- # modified: README.txt
- # modified: benchmarks.rb
- #
+ On branch master
+ Changes to be committed:
+ (use "git reset HEAD <file>..." to unstage)
+
+ modified: README.txt
+ modified: benchmarks.rb
+
<!--Right below the “Changes to be committed” text, it says "use `git reset HEAD <file>...` to unstage". So, let’s use that advice to unstage the `benchmarks.rb` file:-->
Direkt unter der Zeile „Changes to be committed“ findest Du den Hinweis „use `git reset HEAD <file>...` to unstage“, d.h. „aus der Staging Area zu entfernen“. Wir verwenden nun also diesen Befehl, um die Änderungen an der Datei `benchmarks.rb` aus der Staging Area zu nehmen:
$ git reset HEAD benchmarks.rb
- benchmarks.rb: locally modified
+ Unstaged changes after reset:
+ M benchmarks.rb
$ git status
- # On branch master
- # Changes to be committed:
- # (use "git reset HEAD <file>..." to unstage)
- #
- # modified: README.txt
- #
- # Changes not staged for commit:
- # (use "git add <file>..." to update what will be committed)
- # (use "git checkout -- <file>..." to discard changes in working directory)
- #
- # modified: benchmarks.rb
- #
+ On branch master
+ Changes to be committed:
+ (use "git reset HEAD <file>..." to unstage)
+
+ modified: README.txt
+
+ Changes not staged for commit:
+ (use "git add <file>..." to update what will be committed)
+ (use "git checkout -- <file>..." to discard changes in working directory)
+
+ modified: benchmarks.rb
+
<!--The command is a bit strange, but it works. The `benchmarks.rb` file is modified but once again unstaged.-->
@@ -999,12 +1005,12 @@ Der Befehl liest sich zunächst vielleicht etwas merkwürdig, aber wie Du siehst
Was aber, wenn Du die Änderungen an der Datei `benchmarks.rb` überhaupt nicht beibehalten willst? D.h., wenn Du sie in den Zustand zurückversetzen willst, in dem sie sich befand, als Du den letzten Commit angelegt hast (oder das Repository geklont hast). Das ist einfach, und glücklicherweise zeigt der `git status` Befehl ebenfalls bereits einen Hinweis dafür an. Die obige Ausgabe enthält den folgenden Text:
- # Changes not staged for commit:
- # (use "git add <file>..." to update what will be committed)
- # (use "git checkout -- <file>..." to discard changes in working directory)
- #
- # modified: benchmarks.rb
- #
+ Changes not staged for commit:
+ (use "git add <file>..." to update what will be committed)
+ (use "git checkout -- <file>..." to discard changes in working directory)
+
+ modified: benchmarks.rb
+
<!--It tells you pretty explicitly how to discard the changes you’ve made (at least, the newer versions of Git, 1.6.1 and later, do this — if you have an older version, we highly recommend upgrading it to get some of these nicer usability features). Let’s do what it says:-->
@@ -1012,12 +1018,12 @@ Das sagt ziemlich klar, was wir zu tun haben um die Änderungen an der Datei zu
$ git checkout -- benchmarks.rb
$ git status
- # On branch master
- # Changes to be committed:
- # (use "git reset HEAD <file>..." to unstage)
- #
- # modified: README.txt
- #
+ On branch master
+ Changes to be committed:
+ (use "git reset HEAD <file>..." to unstage)
+
+ modified: README.txt
+
<!--You can see that the changes have been reverted. You should also realize that this is a dangerous command: any changes you made to that file are gone — you just copied another file over it. Don’t ever use this command unless you absolutely know that you don’t want the file. If you just need to get it out of the way, we’ll go over stashing and branching in the next chapter; these are generally better ways to go.-->
@@ -1043,12 +1049,12 @@ Um mit anderen via Git zusammenzuarbeiten, musst Du wissen, wie Du auf externe (
Der `git remote` Befehl zeigt Dir an, welche externen Server Du für Dein Projekt lokal konfiguriert hast, und listet die Kurzbezeichnungen für diese Remote Repository auf. Wenn Du ein Repository geklont hast, solltest Du mindestens `origin` sehen – welches der Standardname ist, den Git für denjenigen Server vergibt, von dem Du geklont hast:
$ git clone git://github.com/schacon/ticgit.git
- Initialized empty Git repository in /private/tmp/ticgit/.git/
- remote: Counting objects: 595, done.
- remote: Compressing objects: 100% (269/269), done.
- remote: Total 595 (delta 255), reused 589 (delta 253)
- Receiving objects: 100% (595/595), 73.31 KiB | 1 KiB/s, done.
- Resolving deltas: 100% (255/255), done.
+ Cloning into 'ticgit'...
+ remote: Reusing existing pack: 1857, done.
+ remote: Total 1857 (delta 0), reused 0 (delta 0)
+ Receiving objects: 100% (1857/1857), 374.35 KiB | 193.00 KiB/s, done.
+ Resolving deltas: 100% (772/772), done.
+ Checking connectivity... done.
$ cd ticgit
$ git remote
origin
@@ -1282,6 +1288,7 @@ Die Option `-m` gibt dabei wiederum die Meldung an, die zum Tag hinzugefügt wir
Date: Mon Feb 9 14:45:11 2009 -0800
my version 1.4
+
commit 15027957951b64cf874c3557a0f3547bd83b3ff6
Merge: 4a447f7... a6b4c97...
Author: Scott Chacon <schacon@gee-mail.com>
View
94 de/03-git-branching/01-chapter3.markdown
@@ -206,7 +206,7 @@ Abbildung 3-10. Eine kurze, einfache Commit-Historie
Du hast Dich dafür entschieden an dem Issue #53, des Issue-Trackers XY, zu arbeiten. Um eines klarzustellen, Git ist an kein Issue-Tracking-System gebunden. Da der Issue #53 allerdings ein Schwerpunktthema betrifft, wirst Du einen neuen Branch erstellen um daran zu arbeiten. Um in einem Arbeitsschritt einen neuen Branch zu erstellen und zu aktivieren kannst Du das Kommando `git checkout` mit der Option `-b` verwenden:
$ git checkout -b iss53
- Switched to a new branch "iss53"
+ Switched to a new branch 'iss53'
<!--This is shorthand for:-->
@@ -245,7 +245,7 @@ Nun bekommst Du einen Anruf, in dem Dir mitgeteilt wird, dass es ein Problem mit
Beachte jedoch, dass Dich Git den Branch nur wechseln lässt, wenn bisherige Änderungen in Deinem Arbeitsverzeichnis oder Deiner Staging-Area nicht in Konflikt mit dem Zweig stehen, zu dem Du nun wechseln möchtest. Am besten es liegt ein sauberer Status vor wenn man den Branch wechselt. Wir werden uns später mit Wegen befassen, dieses Verhalten zu umgehen (namentlich „Stashing“ und „Commit Ammending“). Vorerst aber hast Du Deine Änderungen bereits comitted, sodass Du zu Deinem MASTER-Branch zurückwechseln kannst.
$ git checkout master
- Switched to branch "master"
+ Switched to branch 'master'
<!--At this point, your project working directory is exactly the way it was before you started working on issue #53, and you can concentrate on your hotfix. This is an important point to remember: Git resets your working directory to look like the snapshot of the commit that the branch you check out points to. It adds, removes, and modifies files automatically to make sure your working copy is what the branch looked like on your last commit to it.-->
@@ -256,11 +256,11 @@ Zu diesem Zeitpunkt befindet sich das Arbeitsverzeichnis des Projektes in exakt
Nun hast Du einen Hotfix zu erstellen. Lass uns dazu einen Hotfix-Branch erstellen, an dem Du bis zu dessen Fertigstellung arbeitest (siehe Abbildung 3-13):
$ git checkout -b hotfix
- Switched to a new branch "hotfix"
+ Switched to a new branch 'hotfix'
$ vim index.html
$ git commit -a -m 'fixed the broken email address'
- [hotfix]: created 3a0874c: "fixed the broken email address"
- 1 files changed, 0 insertions(+), 1 deletions(-)
+ [hotfix 3a0874c] fixed the broken email address
+ 1 files changed, 1 deletion(-)
<!--Figure 3-13. hotfix branch based back at your master branch point.-->
@@ -274,9 +274,9 @@ Mach Deine Tests, stell sicher das sich der Hotfix verhält wie erwartet und fü
$ git checkout master
$ git merge hotfix
Updating f42c576..3a0874c
- Fast forward
- README | 1 -
- 1 files changed, 0 insertions(+), 1 deletions(-)
+ Fast-forward
+ README | 1 -
+ 1 file changed, 1 deletion(-)
<!--You’ll notice the phrase "Fast forward" in that merge. Because the commit pointed to by the branch you merged in was directly upstream of the commit you’re on, Git moves the pointer forward. To phrase that another way, when you try to merge one commit with a commit that can be reached by following the first commit’s history, Git simplifies things by moving the pointer forward because there is no divergent work to merge together — this is called a "fast forward".-->
@@ -296,18 +296,18 @@ Abbildung 3-14. Der Master-Branch zeigt nach der Zusammenführung auf den gleich
Nachdem Dein superwichtiger Hotfix veröffentlicht wurde, kannst Du Dich wieder Deiner ursprünglichen Arbeit zuwenden. Vorher wird sich allerdings des nun nutzlosen Hotfix-Zweiges entledigt, schließlich zeigt der Master-Branch ebenfalls auf die aktuelle Version. Du kannst ihn mit der `-d`-Option von `git branch` entfernen:
$ git branch -d hotfix
- Deleted branch hotfix (3a0874c).
+ Deleted branch hotfix (was 3a0874c).
<!--Now you can switch back to your work-in-progress branch on issue #53 and continue working on it (see Figure 3-15):-->
Nun kannst Du zu Deinem Issue #53-Branch zurückwechseln und mit Deiner Arbeit fortfahren (Abbildung 3-15):
$ git checkout iss53
- Switched to branch "iss53"
+ Switched to branch 'iss53'
$ vim index.html
$ git commit -a -m 'finished the new footer [issue 53]'
- [iss53]: created ad82d7a: "finished the new footer [issue 53]"
- 1 files changed, 1 insertions(+), 0 deletions(-)
+ [iss53 ad82d7a] finished the new footer [issue 53]
+ 1 file changed, 1 insertion(+)
<!--Figure 3-15. Your iss53 branch can move forward independently.-->
@@ -328,9 +328,10 @@ Angenommen Du entscheidest dich, dass Deine Arbeit an issue #53 getan ist und Du
$ git checkout master
$ git merge iss53
- Merge made by recursive.
- README | 1 +
- 1 files changed, 1 insertions(+), 0 deletions(-)
+ Auto-merging README
+ Merge made by the 'recursive' strategy.
+ README | 1 +
+ 1 file changed, 1 insertion(+)
<!--This looks a bit different than the `hotfix` merge you did earlier. In this case, your development history has diverged from some older point. Because the commit on the branch you’re on isn’t a direct ancestor of the branch you’re merging in, Git has to do some work. In this case, Git does a simple three-way merge, using the two snapshots pointed to by the branch tips and the common ancestor of the two. Figure 3-16 highlights the three snapshots that Git uses to do its merge in this case.-->
@@ -376,27 +377,29 @@ Gelegentlich verläuft der Prozess nicht ganz so glatt. Wenn Du an den selben St
Git hat hier keinen 'merge commit' erstellt. Es hat den Prozess gestoppt, damit Du den Konflikt beseitigen kannst. Wenn Du sehen willst, welche Dateien 'unmerged' aufgrund eines 'merge' Konflikts sind, benutze einfach `git status`:
- [master*]$ git status
- index.html: needs merge
- # On branch master
- # Changes not staged for commit:
- # (use "git add <file>..." to update what will be committed)
- # (use "git checkout -- <file>..." to discard changes in working directory)
- #
- # unmerged: index.html
- #
+ $ git status
+ On branch master
+ You have unmerged paths.
+ (fix conflicts and run "git commit")
+
+ Unmerged paths:
+ (use "git add <file>..." to mark resolution)
+
+ both modified: index.html
+
+ no changes added to commit (use "git add" and/or "git commit -a")
<!--Anything that has merge conflicts and hasn’t been resolved is listed as unmerged. Git adds standard conflict-resolution markers to the files that have conflicts, so you can open them manually and resolve those conflicts. Your file contains a section that looks something like this:-->
Alles, was einen 'merge' Konflikt aufweist und nicht gelöst werden konnte, wird als 'unmerged' aufgeführt. Git fügt den betroffenen Dateien Standard-Konfliktlösungsmarker hinzu, sodass Du diese öffnen und den Konflikt manuell lösen kannst. Deine Datei enthält einen Bereich, der so aussehen könnte:
- <<<<<<< HEAD:index.html
+ <<<<<<< HEAD
<div id="footer">contact : email.support@github.com</div>
=======
<div id="footer">
please contact us at support@github.com
</div>
- >>>>>>> iss53:index.html
+ >>>>>>> iss53
<!--This means the version in HEAD (your master branch, because that was what you had checked out when you ran your merge command) is the top part of that block (everything above the `=======`), while the version in your `iss53` branch looks like everything in the bottom part. In order to resolve the conflict, you have to either choose one side or the other or merge the contents yourself. For instance, you might resolve this conflict by replacing the entire block with this:-->
@@ -413,12 +416,17 @@ Diese Lösung hat von beiden Teilen etwas und ich habe die Zeilen mit `<<<<<<<`,
Wenn Du ein grafischen Tool zur Bereinigung benutzen willst, dann verwende `git mergetool`. Das welches ein passendes grafisches 'merge'-Tool startet und Dich durch die Konfliktbereiche führt:
$ git mergetool
- merge tool candidates: kdiff3 tkdiff xxdiff meld gvimdiff opendiff emerge vimdiff
- Merging the files: index.html
+
+ This message is displayed because 'merge.tool' is not configured.
+ See 'git mergetool --tool-help' or 'git help config' for more details.
+ 'git mergetool' will now attempt to use one of the following tools:
+ opendiff kdiff3 tkdiff xxdiff meld tortoisemerge gvimdiff diffuse diffmerge ecmerge p4merge araxis bc3 codecompare vimdiff emerge
+ Merging:
+ index.html
Normal merge conflict for 'index.html':
- {local}: modified
- {remote}: modified
+ {local}: modified file
+ {remote}: modified file
Hit return to start merge resolution tool (opendiff):
<!--If you want to use a merge tool other than the default (Git chose `opendiff` for me in this case because I ran the command on a Mac), you can see all the supported tools listed at the top after “merge tool candidates”. Type the name of the tool you’d rather use. In Chapter 7, we’ll discuss how you can change this default value for your environment.-->
@@ -434,12 +442,12 @@ Wenn Du das 'merge' Werkzeug beendest, fragt Dich Git, ob das Zusammenführen er
Du kannst `git status` erneut ausführen, um zu sehen, ob alle Konflikte gelöst sind:
$ git status
- # On branch master
- # Changes to be committed:
- # (use "git reset HEAD <file>..." to unstage)
- #
- # modified: index.html
- #
+ On branch master
+ Changes to be committed:
+ (use "git reset HEAD <file>..." to unstage)
+
+ modified: index.html
+
<!--If you’re happy with that, and you verify that everything that had conflicts has been staged, you can type `git commit` to finalize the merge commit. The commit message by default looks something like this:-->
@@ -450,9 +458,9 @@ Wenn Du zufrieden bist und Du geprüft hast, dass alle Konflikte beseitigt wurde
Conflicts:
index.html
#
- # It looks like you may be committing a MERGE.
+ # It looks like you may be committing a merge.
# If this is not correct, please remove the file
- # .git/MERGE_HEAD
+ # .git/MERGE_HEAD
# and try again.
#
@@ -509,7 +517,7 @@ Um alle Branches zu sehen, welche noch nicht gemergte Änderungen enthalten, kan
Die Liste zeigt Dir den anderen Branch. Er enthält Arbeit, die noch nicht gemergt wurde. Der Versuch, den Branch mit `git branch -d` zu löschen schlägt fehl:
$ git branch -d testing
- error: The branch 'testing' is not an ancestor of your current HEAD.
+ error: The branch 'testing' is not fully merged.
If you are sure you want to delete it, run 'git branch -D testing'.
<!--If you really do want to delete the branch and lose that work, you can force it with `-D`, as the helpful message points out.-->
@@ -711,16 +719,16 @@ Das Auschecken eines lokalen Branches von einem Remote-Branch erzeugt automatisc
Wenn Du ein Repository klonst, wird automatisch ein `master`-Branch erzeugt, welcher `origin/master` verfolgt. Deshalb können `git push` und `git pull` ohne weitere Argumente aufgerufen werden. Du kannst natürlich auch eigene Tracking-Branches erzeugen – welche die nicht Zweige auf `origin` und dessen `master`-Branch verfolgen. Der einfachste Fall ist das bereits gesehene Beispiel in welchem Du `git checkout -b [branch] [remotename]/[branch]` ausführst. Mit der Git-Version 1.6.2 oder später kannst Du auch die `--track`-Kurzvariante nutzen:
$ git checkout --track origin/serverfix
- Branch serverfix set up to track remote branch refs/remotes/origin/serverfix.
- Switched to a new branch "serverfix"
+ Branch serverfix set up to track remote branch serverfix from origin.
+ Switched to a new branch 'serverfix'
<!--To set up a local branch with a different name than the remote branch, you can easily use the first version with a different local branch name:-->
Um einen lokalen Branch mit einem anderem Namen als der Remote-Branch, kannst Du einfach die erste Varianten mit einem neuen lokalen Branch-Namen:
$ git checkout -b sf origin/serverfix
- Branch sf set up to track remote branch refs/remotes/origin/serverfix.
- Switched to a new branch "sf"
+ Branch sf set up to track remote branch serverfix from origin.
+ Switched to a new branch 'sf'
<!--Now, your local branch `sf` will automatically push to and pull from `origin/serverfix`.-->
View
42 de/04-git-server/01-chapter4.markdown
@@ -202,7 +202,8 @@ Um zunächst einen beliebigen Git Server einzurichten, musst Du ein existierende
Um zunächst Dein Repository zu klonen, um ein neues einfaches Repository anzulegen, führst Du den Klonen-Befehl mit der `--bare` Option aus. Per Konvention haben einfache Repository Verzeichnisse die Endung `.git`, wie hier:
$ git clone --bare my_project my_project.git
- Initialized empty Git repository in /opt/projects/my_project.git/
+ Cloning into bare repository 'my_project.git'...
+ done.
<!--The output for this command is a little confusing. Since `clone` is basically a `git init` then a `git fetch`, we see some output from the `git init` part, which creates an empty directory. The actual object transfer gives no output, but it does happen. You should now have a copy of the Git directory data in your `my_project.git` directory.-->
@@ -453,6 +454,13 @@ Welche Aufgabe hat der `post-update` Hook? Er enthält in etwa folgendes:
$ cat .git/hooks/post-update
#!/bin/sh
+ #
+ # An example hook script to prepare a packed repository for use over
+ # dumb transports.
+ #
+ # To enable this hook, rename this file to "post-update".
+ #
+
exec git-update-server-info
<!--This means that when you push to the server via SSH, Git will run this command to update the files needed for HTTP fetching.-->
@@ -618,7 +626,7 @@ Jetzt kann es losgehen. Wenn Du alles richtig eingerichtet hast, kannst Du jetzt
$ ssh git@gitserver
PTY allocation request failed on channel 0
- fatal: unrecognized command 'gitosis-serve schacon@quaternion'
+ ERROR:gitosis.serve.main:Need SSH_ORIGINAL_COMMAND in environment.
Connection to gitserver closed.
<!--That means Gitosis recognized you but shut you out because you’re not trying to do any Git commands. So, let’s do an actual Git command — you’ll clone the Gitosis control repository:-->
@@ -650,8 +658,8 @@ Wenn Du Dir die Datei `gitosis.conf` anschaust, sollten lediglich Daten für das
[gitosis]
[group gitosis-admin]
- writable = gitosis-admin
members = scott
+ writable = gitosis-admin
<!--It shows you that the 'scott' user — the user with whose public key you initialized Gitosis — is the only one who has access to the `gitosis-admin` project.-->
@@ -662,22 +670,22 @@ In dieser Datei wird Dir angezeigt, dass nur der Benutzer ‚scott‘ — das is
Lass uns jetzt für Dich ein neues Projekt hinzufügen. Dazu fügen wir eine neue Sektion mit dem Namen `mobile` hinzu, in der wir alle Teammitglieder aus dem „Mobile“-Team und alle Repositorys, die von Ihnen benötigt werden, auflisten. Da ‚scott‘ bisher der einzige Benutzer im System ist, werden wir ihn als einziges Teammitglied hinzufügen. Das erste von uns erzeugte Projekt mit dem wir anfangen, nennt sich `iphone_project`:
[group mobile]
- writable = iphone_project
members = scott
+ writable = iphone_project
<!--Whenever you make changes to the `gitosis-admin` project, you have to commit the changes and push them back up to the server in order for them to take effect:-->
Immer wenn Du Änderungen im Projekt `gitosis-admin` durchführst, musst Du diese Änderungen auch einchecken und auf den Server pushen, damit diese auch eine Wirkung zeigen:
$ git commit -am 'add iphone_project and mobile group'
- [master]: created 8962da8: "changed name"
- 1 files changed, 4 insertions(+), 0 deletions(-)
- $ git push
+ [master 8962da8] add iphone_project and mobile group
+ 1 file changed, 4 insertions(+)
+ $ git push origin master
Counting objects: 5, done.
- Compressing objects: 100% (2/2), done.
- Writing objects: 100% (3/3), 272 bytes, done.
- Total 3 (delta 1), reused 0 (delta 0)
- To git@gitserver:/opt/git/gitosis-admin.git
+ Compressing objects: 100% (3/3), done.
+ Writing objects: 100% (3/3), 272 bytes | 0 bytes/s, done.
+ Total 3 (delta 0), reused 0 (delta 0)
+ To git@gitserver:gitosis-admin.git
fb27aec..8962da8 master -> master
<!--You can make your first push to the new `iphone_project` project by adding your server as a remote to your local version of the project and pushing. You no longer have to manually create a bare repository for new projects on the server — Gitosis creates them automatically when it sees the first push:-->
@@ -688,7 +696,7 @@ Du kannst Deinen ersten Push für das neue Projekt `iphone_project` ausführen,
$ git push origin master
Initialized empty Git repository in /opt/git/iphone_project.git/
Counting objects: 3, done.
- Writing objects: 100% (3/3), 230 bytes, done.
+ Writing objects: 100% (3/3), 230 bytes | 0 bytes/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To git@gitserver:iphone_project.git
* [new branch] master -> master
@@ -710,8 +718,8 @@ Da Du an diesem Projekt nicht alleine, sondern mit Deinen Freunden, arbeiten wil
Damit diese Personen Lese- und Schreibzugriff auf das Projekt `iphone_project` haben, musst Du sie dem ‚mobile‘-Team hinzufügen:
[group mobile]
- writable = iphone_project
members = scott john josie jessica
+ writable = iphone_project
<!--After you commit and push that change, all four users will be able to read from and write to that project.-->
@@ -722,12 +730,12 @@ Nachdem Du diese Änderung commitet und gepusht hast, können alle vier Benutzer
Mit Gitosis kann man auch einfache Zugriffsberechtigungen setzen. Wenn John nur Lesezugriff zum Projekt haben soll, dann kannst Du stattdessen folgendes angeben:
[group mobile]
- writable = iphone_project
members = scott josie jessica
+ writable = iphone_project
[group mobile_ro]
- readonly = iphone_project
members = john
+ readonly = iphone_project
<!--Now John can clone the project and get updates, but Gitosis won’t allow him to push back up to the project. You can create as many of these groups as you want, each containing different users and projects. You can also specify another group as one of the members (using `@` as prefix), to inherit all of its members automatically:-->
@@ -737,12 +745,12 @@ Mit dieser Konfiguration kann John das Projekt klonen und kann neue Stände heru
members = scott josie jessica
[group mobile]
- writable = iphone_project
members = @mobile_committers
+ writable = iphone_project
[group mobile_2]
- writable = another_iphone_project
members = @mobile_committers john
+ writable = another_iphone_project
<!--If you have any issues, it may be useful to add `loglevel=DEBUG` under the `[gitosis]` section. If you’ve lost push access by pushing a messed-up configuration, you can manually fix the file on the server under `/home/git/.gitosis.conf` — the file from which Gitosis reads its info. A push to the project takes the `gitosis.conf` file you just pushed up and sticks it there. If you edit that file manually, it remains like that until the next successful push to the `gitosis-admin` project.-->
View
2  en/09-git-internals/01-chapter9.markdown
@@ -456,7 +456,7 @@ You can then check how big is that object on your disk:
Now, modify that file a little, and see what happens:
- $ echo '# testing' >> repo.rb
+ $ echo '# testing' >> repo.rb
$ git commit -am 'modified repo a bit'
[master ab1afef] modified repo a bit
1 files changed, 1 insertions(+), 0 deletions(-)
Something went wrong with that request. Please try again.