Skip to content
This repository

[de] Synchronize with En version #671

Merged
merged 2 commits into from 2 months ago

2 participants

Yue Lin Ho Jean-Noël Avila
Yue Lin Ho

No description provided.

Jean-Noël Avila jnavila merged commit 20c9a28 into from February 11, 2014
Jean-Noël Avila jnavila closed this February 11, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
This page is out of date. Refresh to see the latest.
4  de/01-introduction/01-chapter1.markdown
Source Rendered
@@ -252,8 +252,8 @@ Nachdem Du die genannten Bibliotheken installiert hast, besorge Dir die aktuelle
252 252
 
253 253
 Danach kannst Du dann Git kompilieren und installieren:
254 254
 
255  
-	$ tar -zxf git-1.6.0.5.tar.gz
256  
-	$ cd git-1.6.0.5
  255
+	$ tar -zxf git-1.7.2.2.tar.gz
  256
+	$ cd git-1.7.2.2
257 257
 	$ make prefix=/usr/local all
258 258
 	$ sudo make prefix=/usr/local install
259 259
 
297  de/02-git-basics/01-chapter2.markdown
Source Rendered
@@ -92,8 +92,8 @@ Bild 2-1. Zyklus der Grundzustände Deiner Dateien
92 92
 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:
93 93
 
94 94
 	$ git status
95  
-	# On branch master
96  
-	nothing to commit (working directory clean)
  95
+	On branch master
  96
+	nothing to commit, working directory clean
97 97
 
98 98
 <!--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.-->
99 99
 
@@ -105,11 +105,12 @@ Sagen wir Du fügst eine neue `README` Datei zu Deinem Projekt hinzu. Wenn die D
105 105
 
106 106
 	$ vim README
107 107
 	$ git status
108  
-	# On branch master
109  
-	# Untracked files:
110  
-	#   (use "git add <file>..." to include in what will be committed)
111  
-	#
112  
-	#	README
  108
+	On branch master
  109
+	Untracked files:
  110
+	  (use "git add <file>..." to include in what will be committed)
  111
+	
  112
+	        README
  113
+
113 114
 	nothing added to commit but untracked files present (use "git add" to track)
114 115
 
115 116
 <!--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
130 131
 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):
131 132
 
132 133
 	$ git status
133  
-	# On branch master
134  
-	# Changes to be committed:
135  
-	#   (use "git reset HEAD <file>..." to unstage)
136  
-	#
137  
-	#	new file:   README
138  
-	#
  134
+	On branch master
  135
+	Changes to be committed:
  136
+	  (use "git reset HEAD <file>..." to unstage)
  137
+	
  138
+	        new file:   README
  139
+	
139 140
 
140 141
 <!--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.-->
141 142
 
@@ -149,17 +150,18 @@ Dass die Datei für den nächsten Commit vorgemerkt ist, siehst Du daran, dass s
149 150
 Wenn Du eine bereits versionierte Datei `benchmarks.rb` änderst und den `git status` Befehl ausführst, erhältst Du folgendes:
150 151
 
151 152
 	$ git status
152  
-	# On branch master
153  
-	# Changes to be committed:
154  
-	#   (use "git reset HEAD <file>..." to unstage)
155  
-	#
156  
-	#	new file:   README
157  
-	#
158  
-	# Changes not staged for commit:
159  
-	#   (use "git add <file>..." to update what will be committed)
160  
-	#
161  
-	#	modified:   benchmarks.rb
162  
-	#
  153
+	On branch master
  154
+	Changes to be committed:
  155
+	  (use "git reset HEAD <file>..." to unstage)
  156
+	
  157
+	        new file:   README
  158
+
  159
+	Changes not staged for commit:
  160
+	  (use "git add <file>..." to update what will be committed)
  161
+	  (use "git checkout -- <file>..." to discard changes in working directory)
  162
+	
  163
+	        modified:   benchmarks.rb
  164
+	
163 165
 
164 166
 <!--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:-->
165 167
 
@@ -167,13 +169,13 @@ Die Datei `benchmarks.rb` erscheint in der Sektion „Changes not staged for com
167 169
 
168 170
 	$ git add benchmarks.rb
169 171
 	$ git status
170  
-	# On branch master
171  
-	# Changes to be committed:
172  
-	#   (use "git reset HEAD <file>..." to unstage)
173  
-	#
174  
-	#	new file:   README
175  
-	#	modified:   benchmarks.rb
176  
-	#
  172
+	On branch master
  173
+	Changes to be committed:
  174
+	  (use "git reset HEAD <file>..." to unstage)
  175
+	
  176
+	        new file:   README
  177
+	        modified:   benchmarks.rb
  178
+	
177 179
 
178 180
 <!--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:-->
179 181
 
@@ -181,18 +183,19 @@ Beide Dateien sind nun für den nächsten Commit vorgemerkt. Nehmen wir an, Du w
181 183
 
182 184
 	$ vim benchmarks.rb
183 185
 	$ git status
184  
-	# On branch master
185  
-	# Changes to be committed:
186  
-	#   (use "git reset HEAD <file>..." to unstage)
187  
-	#
188  
-	#	new file:   README
189  
-	#	modified:   benchmarks.rb
190  
-	#
191  
-	# Changes not staged for commit:
192  
-	#   (use "git add <file>..." to update what will be committed)
193  
-	#
194  
-	#	modified:   benchmarks.rb
195  
-	#
  186
+	On branch master
  187
+	Changes to be committed:
  188
+	  (use "git reset HEAD <file>..." to unstage)
  189
+	
  190
+	        new file:   README
  191
+	        modified:   benchmarks.rb
  192
+	
  193
+	Changes not staged for commit:
  194
+	  (use "git add <file>..." to update what will be committed)
  195
+	  (use "git checkout -- <file>..." to discard changes in working directory)
  196
+	
  197
+	        modified:   benchmarks.rb
  198
+	
196 199
 
197 200
 <!--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:-->
198 201
 
@@ -200,13 +203,13 @@ Huch, was ist das? Jetzt wird `benchmarks.rb` sowohl in der Staging Area als auc
200 203
 
201 204
 	$ git add benchmarks.rb
202 205
 	$ git status
203  
-	# On branch master
204  
-	# Changes to be committed:
205  
-	#   (use "git reset HEAD <file>..." to unstage)
206  
-	#
207  
-	#	new file:   README
208  
-	#	modified:   benchmarks.rb
209  
-	#
  206
+	On branch master
  207
+	Changes to be committed:
  208
+	  (use "git reset HEAD <file>..." to unstage)
  209
+	
  210
+	        new file:   README
  211
+	        modified:   benchmarks.rb
  212
+	
210 213
 
211 214
 <!--### Ignoring Files ###-->
212 215
 ### Dateien ignorieren ###
@@ -289,17 +292,18 @@ Wenn Dir die Ausgabe des Befehl `git status` nicht aussagekräftig genug ist, we
289 292
 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:
290 293
 
291 294
 	$ git status
292  
-	# On branch master
293  
-	# Changes to be committed:
294  
-	#   (use "git reset HEAD <file>..." to unstage)
295  
-	#
296  
-	#	new file:   README
297  
-	#
298  
-	# Changes not staged for commit:
299  
-	#   (use "git add <file>..." to update what will be committed)
300  
-	#
301  
-	#	modified:   benchmarks.rb
302  
-	#
  295
+	On branch master
  296
+	Changes to be committed:
  297
+	  (use "git reset HEAD <file>..." to unstage)
  298
+	
  299
+	        new file:   README
  300
+	
  301
+	Changes not staged for commit:
  302
+	  (use "git add <file>..." to update what will be committed)
  303
+	  (use "git checkout -- <file>..." to discard changes in working directory)
  304
+	
  305
+	        modified:   benchmarks.rb
  306
+	
303 307
 
304 308
 <!--To see what you’ve changed but not yet staged, type `git diff` with no other arguments:-->
305 309
 
@@ -354,16 +358,18 @@ Ein anderes Beispiel: Wenn Du Änderungen an der Datei `benchmarks.rb` bereits z
354 358
 	$ git add benchmarks.rb
355 359
 	$ echo '# test line' >> benchmarks.rb
356 360
 	$ git status
357  
-	# On branch master
358  
-	#
359  
-	# Changes to be committed:
360  
-	#
361  
-	#	modified:   benchmarks.rb
362  
-	#
363  
-	# Changes not staged for commit:
364  
-	#
365  
-	#	modified:   benchmarks.rb
366  
-	#
  361
+	On branch master
  362
+	Changes to be committed:
  363
+	  (use "git reset HEAD <file>..." to unstage)
  364
+	
  365
+	        modified:   benchmarks.rb
  366
+	
  367
+	Changes not staged for commit:
  368
+	  (use "git add <file>..." to update what will be committed)
  369
+	  (use "git checkout -- <file>..." to discard changes in working directory)
  370
+	
  371
+	        modified:   benchmarks.rb
  372
+	
367 373
 
368 374
 <!--Now you can use `git diff` to see what is still unstaged-->
369 375
 
@@ -423,10 +429,9 @@ Der Editor zeigt in etwa folgenden Text an (dies ist ein Beispiel mit vim):
423 429
 	# with '#' will be ignored, and an empty message aborts the commit.
424 430
 	# On branch master
425 431
 	# Changes to be committed:
426  
-	#   (use "git reset HEAD <file>..." to unstage)
427  
-	#
428 432
 	#       new file:   README
429 433
 	#       modified:   benchmarks.rb
  434
+	#
430 435
 	~
431 436
 	~
432 437
 	~
@@ -441,8 +446,8 @@ Du siehst, dass die vorausgefüllte Commit Meldung die Ausgabe des letzten `git
441 446
 Alternativ kannst Du die Commit Meldung direkt mit dem Befehl `git commit` angeben, indem Du die Option `-m` wie folgt verwendest:
442 447
 
443 448
 	$ git commit -m "Story 182: Fix benchmarks for speed"
444  
-	[master]: created 463dc4f: "Fix benchmarks for speed"
445  
-	 2 files changed, 3 insertions(+), 0 deletions(-)
  449
+	[master 463dc4f] Fix benchmarks for speed
  450
+	 2 files changed, 3 insertions(+)
446 451
 	 create mode 100644 README
447 452
 
448 453
 <!--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
461 466
 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:
462 467
 
463 468
 	$ git status
464  
-	# On branch master
465  
-	#
466  
-	# Changes not staged for commit:
467  
-	#
468  
-	#	modified:   benchmarks.rb
469  
-	#
  469
+	On branch master
  470
+	Changes not staged for commit:
  471
+	  (use "git add <file>..." to update what will be committed)
  472
+	  (use "git checkout -- <file>..." to discard changes in working directory)
  473
+	
  474
+	        modified:   benchmarks.rb
  475
+	
  476
+	no changes added to commit (use "git add" and/or "git commit -a")
470 477
 	$ git commit -a -m 'added new benchmarks'
471 478
 	[master 83e38c7] added new benchmarks
472  
-	 1 files changed, 5 insertions(+), 0 deletions(-)
  479
+	 1 files changed, 5 insertions(+)
473 480
 
474 481
 <!--Notice how you don’t have to run `git add` on the `benchmarks.rb` file in this case before you commit.-->
475 482
 
@@ -488,13 +495,14 @@ Wenn Du einfach nur eine Datei aus dem Arbeitsverzeichnis löschst, wird sie in
488 495
 
489 496
 	$ rm grit.gemspec
490 497
 	$ git status
491  
-	# On branch master
492  
-	#
493  
-	# Changes not staged for commit:
494  
-	#   (use "git add/rm <file>..." to update what will be committed)
495  
-	#
496  
-	#       deleted:    grit.gemspec
497  
-	#
  498
+	On branch master
  499
+	Changes not staged for commit:
  500
+	  (use "git add/rm <file>..." to update what will be committed)
  501
+	  (use "git checkout -- <file>..." to discard changes in working directory)
  502
+	
  503
+	        deleted:    grit.gemspec
  504
+	
  505
+	no changes added to commit (use "git add" and/or "git commit -a")
498 506
 
499 507
 <!--Then, if you run `git rm`, it stages the file’s removal:-->
500 508
 
@@ -503,13 +511,12 @@ Wenn Du jetzt `git rm` ausführst, wird diese Änderung für den nächsten Commi
503 511
 	$ git rm grit.gemspec
504 512
 	rm 'grit.gemspec'
505 513
 	$ git status
506  
-	# On branch master
507  
-	#
508  
-	# Changes to be committed:
509  
-	#   (use "git reset HEAD <file>..." to unstage)
510  
-	#
511  
-	#       deleted:    grit.gemspec
512  
-	#
  514
+	On branch master
  515
+	Changes to be committed:
  516
+	  (use "git reset HEAD <file>..." to unstage)
  517
+	
  518
+	        deleted:    grit.gemspec
  519
+	
513 520
 
514 521
 <!--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.-->
515 522
 
@@ -556,14 +563,12 @@ Das funktioniert einwandfrei. Wenn Du diesen Befehl ausführst und danach den `g
556 563
 
557 564
 	$ git mv README.txt README
558 565
 	$ git status
559  
-	# On branch master
560  
-	# Your branch is ahead of 'origin/master' by 1 commit.
561  
-	#
562  
-	# Changes to be committed:
563  
-	#   (use "git reset HEAD <file>..." to unstage)
564  
-	#
565  
-	#       renamed:    README.txt -> README
566  
-	#
  566
+	On branch master
  567
+	Changes to be committed:
  568
+	  (use "git reset HEAD <file>..." to unstage)
  569
+	
  570
+	        renamed:    README.txt -> README
  571
+	
567 572
 
568 573
 <!--However, this is equivalent to running something like this:-->
569 574
 Allerdings kannst Du genauso folgendes tun:
@@ -704,7 +709,7 @@ Außerdem gibt es verschiedene Optionen, die nützlich sind, um Dinge zusammenzu
704 709
 	    changed the version number
705 710
 
706 711
 	 Rakefile |    2 +-
707  
-	 1 files changed, 1 insertions(+), 1 deletions(-)
  712
+	 1 file changed, 1 insertion(+), 1 deletion(-)
708 713
 
709 714
 	commit 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7
710 715
 	Author: Scott Chacon <schacon@gee-mail.com>
@@ -713,7 +718,7 @@ Außerdem gibt es verschiedene Optionen, die nützlich sind, um Dinge zusammenzu
713 718
 	    removed unnecessary test code
714 719
 
715 720
 	 lib/simplegit.rb |    5 -----
716  
-	 1 files changed, 0 insertions(+), 5 deletions(-)
  721
+	 1 file changed, 5 deletions(-)
717 722
 
718 723
 	commit a11bef06a3f659402fe7563abf99ad00de2209e6
719 724
 	Author: Scott Chacon <schacon@gee-mail.com>
@@ -724,7 +729,7 @@ Außerdem gibt es verschiedene Optionen, die nützlich sind, um Dinge zusammenzu
724 729
 	 README           |    6 ++++++
725 730
 	 Rakefile         |   23 +++++++++++++++++++++++
726 731
 	 lib/simplegit.rb |   25 +++++++++++++++++++++++++
727  
-	 3 files changed, 54 insertions(+), 0 deletions(-)
  732
+	 3 files changed, 54 insertions(+)
728 733
 
729 734
 <!--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.-->
730 735
 <!--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
960 965
 
961 966
 	$ git add .
962 967
 	$ git status
963  
-	# On branch master
964  
-	# Changes to be committed:
965  
-	#   (use "git reset HEAD <file>..." to unstage)
966  
-	#
967  
-	#       modified:   README.txt
968  
-	#       modified:   benchmarks.rb
969  
-	#
  968
+	On branch master
  969
+	Changes to be committed:
  970
+	  (use "git reset HEAD <file>..." to unstage)
  971
+	
  972
+	        modified:   README.txt
  973
+	        modified:   benchmarks.rb
  974
+	
970 975
 
971 976
 <!--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:-->
972 977
 
973 978
 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:
974 979
 
975 980
 	$ git reset HEAD benchmarks.rb
976  
-	benchmarks.rb: locally modified
  981
+	Unstaged changes after reset:
  982
+	M       benchmarks.rb
977 983
 	$ git status
978  
-	# On branch master
979  
-	# Changes to be committed:
980  
-	#   (use "git reset HEAD <file>..." to unstage)
981  
-	#
982  
-	#       modified:   README.txt
983  
-	#
984  
-	# Changes not staged for commit:
985  
-	#   (use "git add <file>..." to update what will be committed)
986  
-	#   (use "git checkout -- <file>..." to discard changes in working directory)
987  
-	#
988  
-	#       modified:   benchmarks.rb
989  
-	#
  984
+	On branch master
  985
+	Changes to be committed:
  986
+	  (use "git reset HEAD <file>..." to unstage)
  987
+	
  988
+	        modified:   README.txt
  989
+	
  990
+	Changes not staged for commit:
  991
+	  (use "git add <file>..." to update what will be committed)
  992
+	  (use "git checkout -- <file>..." to discard changes in working directory)
  993
+	
  994
+	        modified:   benchmarks.rb
  995
+	
990 996
 
991 997
 <!--The command is a bit strange, but it works. The `benchmarks.rb` file is modified but once again unstaged.-->
992 998
 
@@ -999,12 +1005,12 @@ Der Befehl liest sich zunächst vielleicht etwas merkwürdig, aber wie Du siehst
999 1005
 
1000 1006
 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:
1001 1007
 
1002  
-	# Changes not staged for commit:
1003  
-	#   (use "git add <file>..." to update what will be committed)
1004  
-	#   (use "git checkout -- <file>..." to discard changes in working directory)
1005  
-	#
1006  
-	#       modified:   benchmarks.rb
1007  
-	#
  1008
+	Changes not staged for commit:
  1009
+	  (use "git add <file>..." to update what will be committed)
  1010
+	  (use "git checkout -- <file>..." to discard changes in working directory)
  1011
+	
  1012
+	        modified:   benchmarks.rb
  1013
+	
1008 1014
 
1009 1015
 <!--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:-->
1010 1016
 
@@ -1012,12 +1018,12 @@ Das sagt ziemlich klar, was wir zu tun haben um die Änderungen an der Datei zu
1012 1018
 
1013 1019
 	$ git checkout -- benchmarks.rb
1014 1020
 	$ git status
1015  
-	# On branch master
1016  
-	# Changes to be committed:
1017  
-	#   (use "git reset HEAD <file>..." to unstage)
1018  
-	#
1019  
-	#       modified:   README.txt
1020  
-	#
  1021
+	On branch master
  1022
+	Changes to be committed:
  1023
+	  (use "git reset HEAD <file>..." to unstage)
  1024
+	
  1025
+	        modified:   README.txt
  1026
+	
1021 1027
 
1022 1028
 <!--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.-->
1023 1029
 
@@ -1043,12 +1049,12 @@ Um mit anderen via Git zusammenzuarbeiten, musst Du wissen, wie Du auf externe (
1043 1049
 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:
1044 1050
 
1045 1051
 	$ git clone git://github.com/schacon/ticgit.git
1046  
-	Initialized empty Git repository in /private/tmp/ticgit/.git/
1047  
-	remote: Counting objects: 595, done.
1048  
-	remote: Compressing objects: 100% (269/269), done.
1049  
-	remote: Total 595 (delta 255), reused 589 (delta 253)
1050  
-	Receiving objects: 100% (595/595), 73.31 KiB | 1 KiB/s, done.
1051  
-	Resolving deltas: 100% (255/255), done.
  1052
+	Cloning into 'ticgit'...
  1053
+	remote: Reusing existing pack: 1857, done.
  1054
+	remote: Total 1857 (delta 0), reused 0 (delta 0)
  1055
+	Receiving objects: 100% (1857/1857), 374.35 KiB | 193.00 KiB/s, done.
  1056
+	Resolving deltas: 100% (772/772), done.
  1057
+	Checking connectivity... done.
1052 1058
 	$ cd ticgit
1053 1059
 	$ git remote
1054 1060
 	origin
@@ -1282,6 +1288,7 @@ Die Option `-m` gibt dabei wiederum die Meldung an, die zum Tag hinzugefügt wir
1282 1288
 	Date:   Mon Feb 9 14:45:11 2009 -0800
1283 1289
 
1284 1290
 	my version 1.4
  1291
+
1285 1292
 	commit 15027957951b64cf874c3557a0f3547bd83b3ff6
1286 1293
 	Merge: 4a447f7... a6b4c97...
1287 1294
 	Author: Scott Chacon <schacon@gee-mail.com>
94  de/03-git-branching/01-chapter3.markdown
Source Rendered
@@ -206,7 +206,7 @@ Abbildung 3-10. Eine kurze, einfache Commit-Historie
206 206
 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:
207 207
 
208 208
 	$ git checkout -b iss53
209  
-	Switched to a new branch "iss53"
  209
+	Switched to a new branch 'iss53'
210 210
 
211 211
 <!--This is shorthand for:-->
212 212
 
@@ -245,7 +245,7 @@ Nun bekommst Du einen Anruf, in dem Dir mitgeteilt wird, dass es ein Problem mit
245 245
 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.
246 246
 
247 247
 	$ git checkout master
248  
-	Switched to branch "master"
  248
+	Switched to branch 'master'
249 249
 
250 250
 <!--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.-->
251 251
 
@@ -256,11 +256,11 @@ Zu diesem Zeitpunkt befindet sich das Arbeitsverzeichnis des Projektes in exakt
256 256
 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):
257 257
 
258 258
 	$ git checkout -b hotfix
259  
-	Switched to a new branch "hotfix"
  259
+	Switched to a new branch 'hotfix'
260 260
 	$ vim index.html
261 261
 	$ git commit -a -m 'fixed the broken email address'
262  
-	[hotfix]: created 3a0874c: "fixed the broken email address"
263  
-	 1 files changed, 0 insertions(+), 1 deletions(-)
  262
+	[hotfix 3a0874c] fixed the broken email address
  263
+	 1 files changed, 1 deletion(-)
264 264
 
265 265
 <!--Figure 3-13. hotfix branch based back at your master branch point.-->
266 266
 
@@ -274,9 +274,9 @@ Mach Deine Tests, stell sicher das sich der Hotfix verhält wie erwartet und fü
274 274
 	$ git checkout master
275 275
 	$ git merge hotfix
276 276
 	Updating f42c576..3a0874c
277  
-	Fast forward
278  
-	 README |    1 -
279  
-	 1 files changed, 0 insertions(+), 1 deletions(-)
  277
+	Fast-forward
  278
+	 README | 1 -
  279
+	 1 file changed, 1 deletion(-)
280 280
 
281 281
 <!--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".-->
282 282
 
@@ -296,18 +296,18 @@ Abbildung 3-14. Der Master-Branch zeigt nach der Zusammenführung auf den gleich
296 296
 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:
297 297
 
298 298
 	$ git branch -d hotfix
299  
-	Deleted branch hotfix (3a0874c).
  299
+	Deleted branch hotfix (was 3a0874c).
300 300
 
301 301
 <!--Now you can switch back to your work-in-progress branch on issue #53 and continue working on it (see Figure 3-15):-->
302 302
 
303 303
 Nun kannst Du zu Deinem Issue #53-Branch zurückwechseln und mit Deiner Arbeit fortfahren (Abbildung 3-15):
304 304
 
305 305
 	$ git checkout iss53
306  
-	Switched to branch "iss53"
  306
+	Switched to branch 'iss53'
307 307
 	$ vim index.html
308 308
 	$ git commit -a -m 'finished the new footer [issue 53]'
309  
-	[iss53]: created ad82d7a: "finished the new footer [issue 53]"
310  
-	 1 files changed, 1 insertions(+), 0 deletions(-)
  309
+	[iss53 ad82d7a] finished the new footer [issue 53]
  310
+	 1 file changed, 1 insertion(+)
311 311
 
312 312
 <!--Figure 3-15. Your iss53 branch can move forward independently.-->
313 313
 
@@ -328,9 +328,10 @@ Angenommen Du entscheidest dich, dass Deine Arbeit an issue #53 getan ist und Du
328 328
 
329 329
 	$ git checkout master
330 330
 	$ git merge iss53
331  
-	Merge made by recursive.
332  
-	 README |    1 +
333  
-	 1 files changed, 1 insertions(+), 0 deletions(-)
  331
+	Auto-merging README
  332
+	Merge made by the 'recursive' strategy.
  333
+	 README | 1 +
  334
+	 1 file changed, 1 insertion(+)
334 335
 
335 336
 <!--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.-->
336 337
 
@@ -376,27 +377,29 @@ Gelegentlich verläuft der Prozess nicht ganz so glatt. Wenn Du an den selben St
376 377
 
377 378
 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`:
378 379
 
379  
-	[master*]$ git status
380  
-	index.html: needs merge
381  
-	# On branch master
382  
-	# Changes not staged for commit:
383  
-	#   (use "git add <file>..." to update what will be committed)
384  
-	#   (use "git checkout -- <file>..." to discard changes in working directory)
385  
-	#
386  
-	#	unmerged:   index.html
387  
-	#
  380
+	$ git status
  381
+	On branch master
  382
+	You have unmerged paths.
  383
+	  (fix conflicts and run "git commit")
  384
+	
  385
+	Unmerged paths:
  386
+	  (use "git add <file>..." to mark resolution)
  387
+	
  388
+	        both modified:      index.html
  389
+	
  390
+	no changes added to commit (use "git add" and/or "git commit -a")
388 391
 
389 392
 <!--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:-->
390 393
 
391 394
 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:
392 395
 
393  
-	<<<<<<< HEAD:index.html
  396
+	<<<<<<< HEAD
394 397
 	<div id="footer">contact : email.support@github.com</div>
395 398
 	=======
396 399
 	<div id="footer">
397 400
 	  please contact us at support@github.com
398 401
 	</div>
399  
-	>>>>>>> iss53:index.html
  402
+	>>>>>>> iss53
400 403
 
401 404
 <!--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:-->
402 405
 
@@ -413,12 +416,17 @@ Diese Lösung hat von beiden Teilen etwas und ich habe die Zeilen mit `<<<<<<<`,
413 416
 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:
414 417
 
415 418
 	$ git mergetool
416  
-	merge tool candidates: kdiff3 tkdiff xxdiff meld gvimdiff opendiff emerge vimdiff
417  
-	Merging the files: index.html
  419
+
  420
+	This message is displayed because 'merge.tool' is not configured.
  421
+	See 'git mergetool --tool-help' or 'git help config' for more details.
  422
+	'git mergetool' will now attempt to use one of the following tools:
  423
+	opendiff kdiff3 tkdiff xxdiff meld tortoisemerge gvimdiff diffuse diffmerge ecmerge p4merge araxis bc3 codecompare vimdiff emerge
  424
+	Merging:
  425
+	index.html
418 426
 
419 427
 	Normal merge conflict for 'index.html':
420  
-	  {local}: modified
421  
-	  {remote}: modified
  428
+	  {local}: modified file
  429
+	  {remote}: modified file
422 430
 	Hit return to start merge resolution tool (opendiff):
423 431
 
424 432
 <!--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
434 442
 Du kannst `git status` erneut ausführen, um zu sehen, ob alle Konflikte gelöst sind:
435 443
 
436 444
 	$ git status
437  
-	# On branch master
438  
-	# Changes to be committed:
439  
-	#   (use "git reset HEAD <file>..." to unstage)
440  
-	#
441  
-	#	modified:   index.html
442  
-	#
  445
+	On branch master
  446
+	Changes to be committed:
  447
+	  (use "git reset HEAD <file>..." to unstage)
  448
+	
  449
+	        modified:   index.html
  450
+	
443 451
 
444 452
 <!--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:-->
445 453
 
@@ -450,9 +458,9 @@ Wenn Du zufrieden bist und Du geprüft hast, dass alle Konflikte beseitigt wurde
450 458
 	Conflicts:
451 459
 	  index.html
452 460
 	#
453  
-	# It looks like you may be committing a MERGE.
  461
+	# It looks like you may be committing a merge.
454 462
 	# If this is not correct, please remove the file
455  
-	# .git/MERGE_HEAD
  463
+	#       .git/MERGE_HEAD
456 464
 	# and try again.
457 465
 	#
458 466
 
@@ -509,7 +517,7 @@ Um alle Branches zu sehen, welche noch nicht gemergte Änderungen enthalten, kan
509 517
 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:
510 518
 
511 519
 	$ git branch -d testing
512  
-	error: The branch 'testing' is not an ancestor of your current HEAD.
  520
+	error: The branch 'testing' is not fully merged.
513 521
 	If you are sure you want to delete it, run 'git branch -D testing'.
514 522
 
515 523
 <!--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
711 719
 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:
712 720
 
713 721
 	$ git checkout --track origin/serverfix
714  
-	Branch serverfix set up to track remote branch refs/remotes/origin/serverfix.
715  
-	Switched to a new branch "serverfix"
  722
+	Branch serverfix set up to track remote branch serverfix from origin.
  723
+	Switched to a new branch 'serverfix'
716 724
 
717 725
 <!--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:-->
718 726
 
719 727
 Um einen lokalen Branch mit einem anderem Namen als der Remote-Branch, kannst Du einfach die erste Varianten mit einem neuen lokalen Branch-Namen:
720 728
 
721 729
 	$ git checkout -b sf origin/serverfix
722  
-	Branch sf set up to track remote branch refs/remotes/origin/serverfix.
723  
-	Switched to a new branch "sf"
  730
+	Branch sf set up to track remote branch serverfix from origin.
  731
+	Switched to a new branch 'sf'
724 732
 
725 733
 <!--Now, your local branch `sf` will automatically push to and pull from `origin/serverfix`.-->
726 734
 
42  de/04-git-server/01-chapter4.markdown
Source Rendered
@@ -202,7 +202,8 @@ Um zunächst einen beliebigen Git Server einzurichten, musst Du ein existierende
202 202
 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:
203 203
 
204 204
 	$ git clone --bare my_project my_project.git
205  
-	Initialized empty Git repository in /opt/projects/my_project.git/
  205
+	Cloning into bare repository 'my_project.git'...
  206
+	done.
206 207
 
207 208
 <!--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.-->
208 209
 
@@ -453,6 +454,13 @@ Welche Aufgabe hat der `post-update` Hook? Er enthält in etwa folgendes:
453 454
 
454 455
 	$ cat .git/hooks/post-update
455 456
 	#!/bin/sh
  457
+	#
  458
+	# An example hook script to prepare a packed repository for use over
  459
+	# dumb transports.
  460
+	#
  461
+	# To enable this hook, rename this file to "post-update".
  462
+	#
  463
+	
456 464
 	exec git-update-server-info
457 465
 
458 466
 <!--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
618 626
 
619 627
 	$ ssh git@gitserver
620 628
 	PTY allocation request failed on channel 0
621  
-	fatal: unrecognized command 'gitosis-serve schacon@quaternion'
  629
+	ERROR:gitosis.serve.main:Need SSH_ORIGINAL_COMMAND in environment.
622 630
 	  Connection to gitserver closed.
623 631
 
624 632
 <!--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
650 658
 	[gitosis]
651 659
 
652 660
 	[group gitosis-admin]
653  
-	writable = gitosis-admin
654 661
 	members = scott
  662
+	writable = gitosis-admin
655 663
 
656 664
 <!--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.-->
657 665
 
@@ -662,22 +670,22 @@ In dieser Datei wird Dir angezeigt, dass nur der Benutzer ‚scott‘ — das is
662 670
 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`:
663 671
 
664 672
 	[group mobile]
665  
-	writable = iphone_project
666 673
 	members = scott
  674
+	writable = iphone_project
667 675
 
668 676
 <!--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:-->
669 677
 
670 678
 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:
671 679
 
672 680
 	$ git commit -am 'add iphone_project and mobile group'
673  
-	[master]: created 8962da8: "changed name"
674  
-	 1 files changed, 4 insertions(+), 0 deletions(-)
675  
-	$ git push
  681
+	[master 8962da8] add iphone_project and mobile group
  682
+	 1 file changed, 4 insertions(+)
  683
+	$ git push origin master
676 684
 	Counting objects: 5, done.
677  
-	Compressing objects: 100% (2/2), done.
678  
-	Writing objects: 100% (3/3), 272 bytes, done.
679  
-	Total 3 (delta 1), reused 0 (delta 0)
680  
-	To git@gitserver:/opt/git/gitosis-admin.git
  685
+	Compressing objects: 100% (3/3), done.
  686
+	Writing objects: 100% (3/3), 272 bytes | 0 bytes/s, done.
  687
+	Total 3 (delta 0), reused 0 (delta 0)
  688
+	To git@gitserver:gitosis-admin.git
681 689
 	   fb27aec..8962da8  master -> master
682 690
 
683 691
 <!--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,
688 696
 	$ git push origin master
689 697
 	Initialized empty Git repository in /opt/git/iphone_project.git/
690 698
 	Counting objects: 3, done.
691  
-	Writing objects: 100% (3/3), 230 bytes, done.
  699
+	Writing objects: 100% (3/3), 230 bytes | 0 bytes/s, done.
692 700
 	Total 3 (delta 0), reused 0 (delta 0)
693 701
 	To git@gitserver:iphone_project.git
694 702
 	 * [new branch]      master -> master
@@ -710,8 +718,8 @@ Da Du an diesem Projekt nicht alleine, sondern mit Deinen Freunden, arbeiten wil
710 718
 Damit diese Personen Lese- und Schreibzugriff auf das Projekt `iphone_project` haben, musst Du sie dem ‚mobile‘-Team hinzufügen:
711 719
 
712 720
 	[group mobile]
713  
-	writable = iphone_project
714 721
 	members = scott john josie jessica
  722
+	writable = iphone_project
715 723
 
716 724
 <!--After you commit and push that change, all four users will be able to read from and write to that project.-->
717 725
 
@@ -722,12 +730,12 @@ Nachdem Du diese Änderung commitet und gepusht hast, können alle vier Benutzer
722 730
 Mit Gitosis kann man auch einfache Zugriffsberechtigungen setzen. Wenn John nur Lesezugriff zum Projekt haben soll, dann kannst Du stattdessen folgendes angeben:
723 731
 
724 732
 	[group mobile]
725  
-	writable = iphone_project
726 733
 	members = scott josie jessica
  734
+	writable = iphone_project
727 735
 
728 736
 	[group mobile_ro]
729  
-	readonly = iphone_project
730 737
 	members = john
  738
+	readonly = iphone_project
731 739
 
732 740
 <!--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:-->
733 741
 
@@ -737,12 +745,12 @@ Mit dieser Konfiguration kann John das Projekt klonen und kann neue Stände heru
737 745
 	members = scott josie jessica
738 746
 
739 747
 	[group mobile]
740  
-	writable  = iphone_project
741 748
 	members   = @mobile_committers
  749
+	writable  = iphone_project
742 750
 
743 751
 	[group mobile_2]
744  
-	writable  = another_iphone_project
745 752
 	members   = @mobile_committers john
  753
+	writable  = another_iphone_project
746 754
 
747 755
 <!--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.-->
748 756
 
2  en/09-git-internals/01-chapter9.markdown
Source Rendered
@@ -456,7 +456,7 @@ You can then check how big is that object on your disk:
456 456
 
457 457
 Now, modify that file a little, and see what happens:
458 458
 
459  
-	$ echo '# testing' >> repo.rb 
  459
+	$ echo '# testing' >> repo.rb
460 460
 	$ git commit -am 'modified repo a bit'
461 461
 	[master ab1afef] modified repo a bit
462 462
 	 1 files changed, 1 insertions(+), 0 deletions(-)
Commit_comment_tip

Tip: You can add notes to lines in a file. Hover to the left of a line to make a note

Something went wrong with that request. Please try again.