-
Notifications
You must be signed in to change notification settings - Fork 2
/
ch01.html
1254 lines (1239 loc) · 56.9 KB
/
ch01.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<title>Kapitel 1. Einführung und erste Schritte</title>
<link rel="stylesheet" type="text/css" href="gitbuch.css" />
<meta name="generator" content="DocBook XSL Stylesheets V1.78.1" />
<link rel="home" href="index.html" title="Git" />
<link rel="up" href="index.html" title="Git" />
<link rel="prev" href="pr01.html" title="Vorwort" />
<link rel="next" href="ch02.html" title="Kapitel 2. Grundlagen" />
<meta xmlns="" name="language" content="de" />
<script xmlns="" src="http://hyphenator.googlecode.com/svn/trunk/Hyphenator.js" type="text/javascript"></script>
<script xmlns="" type="text/javascript">
Hyphenator.run();
</script>
</head>
<body class="hyphenate">
<div xmlns="" class="toc">
<p><a href="index.html">Startseite</a></p>
<dl class="toc">
<dt>
<span class="preface">
<a href="pr01.html">Vorwort</a>
</span>
</dt>
<dd>
<dl>
<dt>
<span class="section">
<a href="pr01.html#sec.leser">1. An wen richtet sich dieses Buch?</a>
</span>
</dt>
<dt>
<span class="section">
<a href="pr01.html#sec.struktur">2. Wie ist das Buch zu lesen?</a>
</span>
</dt>
<dt>
<span class="section">
<a href="pr01.html#sec.konventionen">3. Konventionen</a>
</span>
</dt>
<dt>
<span class="section">
<a href="pr01.html#sec.install-git-repo">4. Installation und „das Git-Repository“</a>
</span>
</dt>
<dt>
<span class="section">
<a href="pr01.html#sec.doku">5. Dokumentation und Hilfe</a>
</span>
</dt>
<dt>
<span class="section">
<a href="pr01.html#sec.kontakt">6. Downloads und Kontakt</a>
</span>
</dt>
<dt>
<span class="section">
<a href="pr01.html#sec.dank">7. Danksagungen</a>
</span>
</dt>
<dt>
<span class="section">
<a href="pr01.html#chap.vorwort-2te-auflage">8. Vorwort zur 2. Auflage</a>
</span>
</dt>
<dt>
<span class="section">
<a href="pr01.html#chap.vorwort-cc-ausgabe">9. Vorwort zur CreativeCommons-Ausgabe</a>
</span>
</dt>
</dl>
</dd>
<dt>
<span class="chapter">
<a href="ch01.html">1. Einführung und erste Schritte</a>
</span>
</dt>
<dd>
<dl>
<dt>
<span class="section">
<a href="ch01.html#sec.begriffe">1.1. Grundbegriffe</a>
</span>
</dt>
<dt>
<span class="section">
<a href="ch01.html#sec.erste-schritte">1.2. Erste Schritte mit Git</a>
</span>
</dt>
<dt>
<span class="section">
<a href="ch01.html#chap.git-config">1.3. Git konfigurieren</a>
</span>
</dt>
</dl>
</dd>
<dt>
<span class="chapter">
<a href="ch02.html">2. Grundlagen</a>
</span>
</dt>
<dd>
<dl>
<dt>
<span class="section">
<a href="ch02.html#sec.grundlagen">2.1. Git-Kommandos</a>
</span>
</dt>
<dt>
<span class="section">
<a href="ch02.html#sec.objektmodell">2.2. Das Objektmodell</a>
</span>
</dt>
</dl>
</dd>
<dt>
<span class="chapter">
<a href="ch03.html">3. Praktische Versionsverwaltung</a>
</span>
</dt>
<dd>
<dl>
<dt>
<span class="section">
<a href="ch03.html#sec.branches">3.1. Referenzen: Branches und Tags</a>
</span>
</dt>
<dt>
<span class="section">
<a href="ch03.html#sec.undo">3.2. Versionen wiederherstellen</a>
</span>
</dt>
<dt>
<span class="section">
<a href="ch03.html#sec.merge">3.3. Branches zusammenführen: Merges</a>
</span>
</dt>
<dt>
<span class="section">
<a href="ch03.html#sec.merge-conflicts">3.4. Merge-Konflikte lösen</a>
</span>
</dt>
<dt>
<span class="section">
<a href="ch03.html#sec.cherry-pick">3.5. Einzelne Commits übernehmen: Cherry-Pick</a>
</span>
</dt>
<dt>
<span class="section">
<a href="ch03.html#sec.visualization">3.6. Visualisierung von Repositories</a>
</span>
</dt>
<dt>
<span class="section">
<a href="ch03.html#sec.reflog">3.7. Reflog</a>
</span>
</dt>
</dl>
</dd>
<dt>
<span class="chapter">
<a href="ch04.html">4. Fortgeschrittene Konzepte</a>
</span>
</dt>
<dd>
<dl>
<dt>
<span class="section">
<a href="ch04.html#sec.rebase">4.1. Commits verschieben – Rebase</a>
</span>
</dt>
<dt>
<span class="section">
<a href="ch04.html#sec.rebase-i">4.2. Die Geschichte umschreiben – Interaktives Rebase</a>
</span>
</dt>
<dt>
<span class="section">
<a href="ch04.html#sec.blame">4.3. Wer hat diese Änderungen gemacht? – git blame</a>
</span>
</dt>
<dt>
<span class="section">
<a href="ch04.html#sec.ignore">4.4. Dateien ignorieren</a>
</span>
</dt>
<dt>
<span class="section">
<a href="ch04.html#sec.stash">4.5. Veränderungen auslagern – git stash</a>
</span>
</dt>
<dt>
<span class="section">
<a href="ch04.html#sec.notes">4.6. Commits annotieren – git notes</a>
</span>
</dt>
<dt>
<span class="section">
<a href="ch04.html#sec.multi-root">4.7. Mehrere Root-Commits</a>
</span>
</dt>
<dt>
<span class="section">
<a href="ch04.html#sec.bisect">4.8. Regressionen finden – git bisect</a>
</span>
</dt>
</dl>
</dd>
<dt>
<span class="chapter">
<a href="ch05.html">5. Verteiltes Git</a>
</span>
</dt>
<dd>
<dl>
<dt>
<span class="section">
<a href="ch05.html#sec.verteilte_systeme">5.1. Wie funktioniert verteilte Versionsverwaltung?</a>
</span>
</dt>
<dt>
<span class="section">
<a href="ch05.html#sec.clone">5.2. Repositories klonen</a>
</span>
</dt>
<dt>
<span class="section">
<a href="ch05.html#sec.git_fetch">5.3. Commits herunterladen</a>
</span>
</dt>
<dt>
<span class="section">
<a href="ch05.html#sec.hochladen">5.4. Commits hochladen: git push</a>
</span>
</dt>
<dt>
<span class="section">
<a href="ch05.html#sec.remotes-check">5.5. Remotes untersuchen</a>
</span>
</dt>
<dt>
<span class="section">
<a href="ch05.html#sec.multi-remote">5.6. Verteilter Workflow mit mehreren Remotes</a>
</span>
</dt>
<dt>
<span class="section">
<a href="ch05.html#sec.remotes-verwalten">5.7. Remotes verwalten</a>
</span>
</dt>
<dt>
<span class="section">
<a href="ch05.html#sec.remote-tags">5.8. Tags austauschen</a>
</span>
</dt>
<dt>
<span class="section">
<a href="ch05.html#sec.patch-queue">5.9. Patches per E-Mail</a>
</span>
</dt>
<dt>
<span class="section">
<a href="ch05.html#sec.dictator">5.10. Ein verteilter, hierarchischer Workflow</a>
</span>
</dt>
<dt>
<span class="section">
<a href="ch05.html#sec.subprojects">5.11. Unterprojekte verwalten</a>
</span>
</dt>
</dl>
</dd>
<dt>
<span class="chapter">
<a href="ch06.html">6. Workflows</a>
</span>
</dt>
<dd>
<dl>
<dt>
<span class="section">
<a href="ch06.html#sec.workflows-user">6.1. Anwender</a>
</span>
</dt>
<dt>
<span class="section">
<a href="ch06.html#sec.branch-modell">6.2. Ein Branching-Modell</a>
</span>
</dt>
<dt>
<span class="section">
<a href="ch06.html#sec.releases-management">6.3. Releases-Management</a>
</span>
</dt>
</dl>
</dd>
<dt>
<span class="chapter">
<a href="ch07.html">7. Git auf dem Server</a>
</span>
</dt>
<dd>
<dl>
<dt>
<span class="section">
<a href="ch07.html#sec.server">7.1. Einen Git-Server hosten</a>
</span>
</dt>
<dt>
<span class="section">
<a href="ch07.html#sec.gitolite">7.2. Gitolite: Git einfach hosten</a>
</span>
</dt>
<dt>
<span class="section">
<a href="ch07.html#sec.git-daemon">7.3. Git-Daemon: Anonymer, lesender Zugriff</a>
</span>
</dt>
<dt>
<span class="section">
<a href="ch07.html#sec.gitweb">7.4. Gitweb: Das integrierte Web-Frontend</a>
</span>
</dt>
<dt>
<span class="section">
<a href="ch07.html#sec.cgit">7.5. CGit – CGI for Git</a>
</span>
</dt>
</dl>
</dd>
<dt>
<span class="chapter">
<a href="ch08.html">8. Git automatisieren</a>
</span>
</dt>
<dd>
<dl>
<dt>
<span class="section">
<a href="ch08.html#sec.attributes">8.1. Git-Attribute – Dateien gesondert behandeln</a>
</span>
</dt>
<dt>
<span class="section">
<a href="ch08.html#sec.hooks">8.2. Hooks</a>
</span>
</dt>
<dt>
<span class="section">
<a href="ch08.html#sec.scripting">8.3. Eigene Git-Kommandos schreiben</a>
</span>
</dt>
<dt>
<span class="section">
<a href="ch08.html#sec.filter-branch">8.4. Versionsgeschichte umschreiben</a>
</span>
</dt>
</dl>
</dd>
<dt>
<span class="chapter">
<a href="ch09.html">9. Zusammenspiel mit anderen Versionsverwaltungssystemen</a>
</span>
</dt>
<dd>
<dl>
<dt>
<span class="section">
<a href="ch09.html#sec.subversion">9.1. Subversion</a>
</span>
</dt>
<dt>
<span class="section">
<a href="ch09.html#sec.fast-import">9.2. Eigene Importer</a>
</span>
</dt>
</dl>
</dd>
<dt>
<span class="chapter">
<a href="ch10.html">10. Shell-Integration</a>
</span>
</dt>
<dd>
<dl>
<dt>
<span class="section">
<a href="ch10.html#sec.bash-integration">10.1. Git und die Bash</a>
</span>
</dt>
<dt>
<span class="section">
<a href="ch10.html#sec.zsh-integration">10.2. Git und die Z-Shell</a>
</span>
</dt>
</dl>
</dd>
<dt>
<span class="chapter">
<a href="ch11.html">11. Github</a>
</span>
</dt>
<dt>
<span class="appendix">
<a href="apa.html">A. Installation</a>
</span>
</dt>
<dd>
<dl>
<dt>
<span class="section">
<a href="apa.html#linux">A.1. Linux</a>
</span>
</dt>
<dt>
<span class="section">
<a href="apa.html#sec.osx">A.2. Mac OS X</a>
</span>
</dt>
<dt>
<span class="section">
<a href="apa.html#sec.windows">A.3. Windows</a>
</span>
</dt>
</dl>
</dd>
<dt>
<span class="appendix">
<a href="apb.html">B. Struktur eines Repositorys</a>
</span>
</dt>
<dd>
<dl>
<dt>
<span class="section">
<a href="apb.html#sec.gc">B.1. Aufräumen</a>
</span>
</dt>
<dt>
<span class="section">
<a href="apb.html#sec.gc-performance">B.2. Performance</a>
</span>
</dt>
</dl>
</dd>
</dl></div>
<div class="navheader">
<table width="100%" summary="Navigation header">
<tr>
<td width="20%" align="left"><a accesskey="p" href="pr01.html">Zurück</a> </td>
<th width="60%" align="center"> </th>
<td width="20%" align="right"> <a accesskey="n" href="ch02.html">Weiter</a></td>
</tr>
</table>
<hr />
</div>
<div class="chapter">
<div class="titlepage">
<div>
<div>
<h1 class="title"><a id="ch.intro"></a>Kapitel 1. Einführung und erste Schritte</h1>
</div>
</div>
</div>
<p>Das folgende Kapitel bietet eine kompakte Einführung in Grundbegriffe
und Konfigurationseinstellungen von Git. Ein kleines Beispielprojekt
zeigt, wie Sie eine Datei mit Git unter Versionsverwaltung stellen und
mit welchen Kommandos Sie die wichtigsten Arbeitsschritte erledigen.</p>
<div class="section">
<div class="titlepage">
<div>
<div>
<h2 class="title" style="clear: both"><a id="sec.begriffe"></a>1.1. Grundbegriffe</h2>
</div>
</div>
</div>
<p>Einige wichtige Fachbegriffe werden im Folgenden immer wieder
vorkommen und bedürfen darum einer kurzen Erläuterung. Wenn Sie schon
Erfahrung mit einem anderen Versionskontrollsystem gesammelt haben,
werden Ihnen einige der damit verbundenen Konzepte bekannt sein, wenn
vielleicht auch unter anderem Namen.</p>
<div class="variablelist">
<dl class="variablelist">
<dt>
<span class="term">
<span class="emphasis"><em>Versionskontrollsystem</em></span> (<span class="emphasis"><em>Version Control System</em></span>, VCS)
</span>
</dt>
<dd>
<p class="simpara">
Ein System
zur Verwaltung und Versionierung von Software oder anderer digitaler
Informationen. Prominente Beispiele sind Git, Subversion, CVS,
Mercurial (hg), Darcs und Bazaar. Synonyme sind <span class="emphasis"><em>Software
Configuration Management</em></span> (SCM) und <span class="emphasis"><em>Revision Control System</em></span>.
</p>
<p class="simpara">Wir unterscheiden zwischen <span class="emphasis"><em>zentralen</em></span> und <span class="emphasis"><em>verteilten</em></span> Systemen. In
einem zentralen System, wie z.B. Subversion, muss es einen zentralen
Server geben, auf dem die Geschichte des Projekts gespeichert
wird. Alle Entwickler müssen sich mit diesem Server verbinden, um die
Versionsgeschichte einzusehen oder Änderungen vorzunehmen. In einem
verteilten System wie Git gibt es viele gleichwertige Instanzen des
Repositorys, so dass jeder Entwickler über sein eigenes Repository
verfügt. Der Austausch von Veränderungen ist flexibler und erfolgt
nicht zwingend über einen zentralen Server.</p>
</dd>
<dt>
<span class="term">
<span class="emphasis"><em>Repository</em></span>
</span>
</dt>
<dd>
Das Repository ist eine Datenbank, in der Git die
verschiedenen Zustände jeder Datei eines Projekts über die Zeit hinweg
ablegt. Insbesondere wird jede Änderung als Commit verpackt und
abgespeichert.
</dd>
<dt>
<span class="term">
<span class="emphasis"><em>Working Tree</em></span>
</span>
</dt>
<dd>
Das <span class="emphasis"><em>Arbeitsverzeichnis</em></span> von Git (in anderen Systemen
manchmal auch <span class="emphasis"><em>Sandbox</em></span> oder <span class="emphasis"><em>Checkout</em></span> genannt). Hier nehmen Sie alle
Modifikationen am Quellcode vor. Oft findet man dafür auch die
Bezeichnung <span class="emphasis"><em>Working Directory</em></span>.
</dd>
<dt>
<span class="term">
<span class="emphasis"><em>Commit</em></span>
</span>
</dt>
<dd>
Veränderungen am Working Tree, also z.B. modifizierte oder
neue Dateien, werden im Repository als Commits gespeichert. Ein Commit
enthält sowohl diese Veränderungen als auch Metadaten, wie den Autor
der Veränderungen, Datum und Uhrzeit, und eine Nachricht (<span class="emphasis"><em>Commit
Message</em></span>), die die Veränderungen beschreibt. Ein Commit referenziert
immer den Zustand <span class="emphasis"><em>aller</em></span> verwalteten Dateien zu einem bestimmten
Zeitpunkt. Die verschiedenen Git-Kommandos dienen dazu, Commits zu
erstellen, zu manipulieren, einzusehen oder die Beziehungen zwischen
ihnen zu verändern.
</dd>
<dt>
<span class="term">
<code class="literal">HEAD</code>
</span>
</dt>
<dd>
Eine symbolische Referenz auf den neuesten Commit im
aktuellen Branch. Von dieser Referenz hängt ab, welche Dateien Sie im
Working Tree zur Bearbeitung vorfinden. Es handelt sich also um den
„Kopf“ bzw. die Spitze eines Entwicklungsstrangs (nicht zu
verwechseln mit <code class="literal">HEAD</code> in Systemen wie CVS oder SVN).
</dd>
<dt>
<span class="term">
<span class="emphasis"><em>SHA-1</em></span>
</span>
</dt>
<dd>
Der <span class="emphasis"><em>Secure Hash Algorithm</em></span> erstellt eine eindeutige, 160
Bit lange Prüfsumme (40 hexadezimale Zeichen) für beliebige digitale
Informationen. Alle Commits in Git werden nach ihrer SHA-1-Summe
benannt (<span class="emphasis"><em>Commit-ID</em></span>), die aus dem Inhalt und den Metadaten des
Commits errechnet wird. Es ist sozusagen eine <span class="emphasis"><em>inhaltsabhängige</em></span>
Versionsnummer, z.B. <code class="literal">f785b8f9ba1a1f5b707a2c83145301c807a7d661</code>.
</dd>
<dt>
<span class="term">
<span class="emphasis"><em>Objektmodell</em></span>
</span>
</dt>
<dd>
Ein Git-Repository lässt sich als Graph von Commits
modellieren, der durch Git-Kommandos manipuliert wird. Durch diese
Modellierung ist es sehr einfach, die Funktionsweise von Git
detailliert zu beschreiben. Für eine ausführliche Beschreibung des
Objektmodells siehe <a class="xref" href="ch02.html#sec.objektmodell" title="2.2. Das Objektmodell">Abschnitt 2.2, „Das Objektmodell“</a>.
</dd>
<dt>
<span class="term">
<span class="emphasis"><em>Index</em></span>
</span>
</dt>
<dd>
Der Index ist eine Zwischenstufe zwischen Working Tree und
Repository, in der Sie einen Commit vorbereiten. Der Index
<span class="emphasis"><em>indiziert</em></span> also, welche Änderungen an welchen Dateien Sie als Commit
verpacken wollen. Dieses Konzept ist einzigartig in Git und bereitet
Anfängern und Umsteigern häufig Schwierigkeiten. Wir widmen uns dem
Index ausführlich in <a class="xref" href="ch02.html#sec.index" title="2.1.1. Index">Abschnitt 2.1.1, „Index“</a>.
</dd>
<dt>
<span class="term">
<span class="emphasis"><em>Clone</em></span>
</span>
</dt>
<dd>
Wenn Sie sich ein Git-Repository aus dem Internet
herunterladen, erzeugen Sie einen Klon (<span class="emphasis"><em>Clone</em></span>) dieses Repositorys.
Der Klon enthält alle Informationen, die im Ursprungsrepository
enthalten sind, vor allem also die gesamte Versionsgeschichte
einschließlich aller Commits.
</dd>
<dt>
<span class="term">
<span class="emphasis"><em>Branch</em></span>
</span>
</dt>
<dd>
Eine Abzweigung in der Entwicklung. Branches werden in der
Praxis verwendet, um beispielsweise neue Features zu entwickeln, Releases
vorzubereiten oder um alte Versionen mit Bugfixes zu versorgen.
Branches sind – ebenso wie das Zusammenführen von Branches (<span class="emphasis"><em>Merge</em></span>) – in Git extrem einfach zu handhaben und ein herausragendes Feature
des Systems.
</dd>
<dt>
<span class="term">
<code class="literal">master</code>
</span>
</dt>
<dd>
Da Sie zum Arbeiten mit Git mindestens
einen Branch brauchen, wird beim Initialisieren eines neuen
Repositorys der Branch <code class="literal">master</code> erstellt. Der Name ist eine
Konvention (analog zum <code class="literal">trunk</code> in anderen Systemen); Sie
können diesen Branch beliebig umbenennen oder löschen, sofern
mindestens ein anderer Branch zur Verfügung steht. Der
<code class="literal">master</code> unterscheidet sich technisch in keiner Weise von
anderen Branches.
</dd>
<dt>
<span class="term">
<span class="emphasis"><em>Tag</em></span>
</span>
</dt>
<dd>
Tags sind symbolische Namen für schwer zu
merkende SHA-1-Summen. Wichtige Commits, wie z.B. Releases,
können Sie mit Tags kennzeichnen. Ein Tag kann einfach nur ein
Bezeichner, wie z.B. <code class="literal">v1.6.2</code>, sein, oder zusätzlich
Metadaten wie Autor, Beschreibung und GPG-Signatur enthalten.
</dd>
</dl>
</div>
</div>
<div class="section">
<div class="titlepage">
<div>
<div>
<h2 class="title" style="clear: both"><a id="sec.erste-schritte"></a>1.2. Erste Schritte mit Git</h2>
</div>
</div>
</div>
<p>Zum Einstieg wollen wir an einem kleinen Beispiel den Arbeitsablauf
mit Git illustrieren. Wir erstellen ein Repository und entwickeln
darin einen Einzeiler, ein „Hello, World!“-Programm in Perl.</p>
<p>Damit Git einen Commit einem Autor zuordnen kann, müssen Sie Ihren
Namen und Ihre E-Mail-Adresse hinterlegen:</p>
<pre class="screen">$ <span class="strong"><strong>git config --global user.name "Max Mustermann"</strong></span>
$ <span class="strong"><strong>git config --global user.email "[email protected]"</strong></span></pre>
<p>Beachten Sie, dass bei einem Aufruf von Git ein <span class="emphasis"><em>Subkommando</em></span>
angegeben wird, in diesem Fall <code class="literal">config</code>. Git stellt alle
Operationen durch solche Subkommandos zur Verfügung. Wichtig ist
auch, dass bei einem Aufruf von <code class="literal">git config</code> kein Gleichheitszeichen verwendet wird. Folgender Aufruf ist also
<span class="emphasis"><em>falsch</em></span>:</p>
<pre class="screen">$ <span class="strong"><strong>git config --global user.name = "Max Mustermann"</strong></span></pre>
<p>Das ist besonders für Anfänger eine Stolperfalle, da Git keine
Fehlermeldung ausgibt, sondern das Gleichheitszeichen als zu setzenden
Wert übernimmt.</p>
<div class="section">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a id="sec.erstes-repo"></a>1.2.1. Das erste Repository</h3>
</div>
</div>
</div>
<p>Bevor wir mit Git Dateien verwalten, müssen wir ein Repository für das
Beispiel-Projekt erstellen. Das Repository wird <span class="emphasis"><em>lokal</em></span> erstellt,
liegt also nur auf dem Dateisystem des Rechners, auf dem Sie arbeiten.</p>
<p>Es empfiehlt sich generell, den Umgang mit Git zunächst lokal zu üben
und erst später in die dezentralen Eigenschaften und Funktionen von
Git einzutauchen.</p>
<pre class="screen">$ <span class="strong"><strong>git init beispiel</strong></span>
Initialized empty Git repository in /home/esc/beispiel/.git/</pre>
<p>Zunächst erstellt Git das Verzeichnis <code class="literal">beispiel/</code>, falls es
noch nicht existiert. Danach initialisiert Git ein leeres Repository
in diesem Verzeichnis und legt dafür ein Unterverzeichnis
<code class="literal">.git/</code> an, in dem interne Daten verwaltet werden. Sollte das
Verzeichnis <code class="literal">beispiel/</code> bereits existieren, erstellt Git darin
ein neues Repository. Gibt es bereits sowohl das Verzeichnis wie auch
ein Repository, macht Git gar nichts. Wir wechseln in das Verzeichnis und
schauen uns mit <code class="literal">git status</code> den aktuellen Zustand an:</p>
<pre class="screen">$ <span class="strong"><strong>cd beispiel</strong></span>
$ <span class="strong"><strong>git status</strong></span>
On branch master
Initial commit
nothing to commit (create/copy files and use "git add" to track)</pre>
<p>Git weist uns darauf hin, dass wir vor dem ersten Commit stehen
(<code class="literal">Initial commit</code>), hat aber nichts gefunden, was in diesen
Commit einfließen könnte (<code class="literal">nothing to commit</code>). Dafür liefert
es einen Hinweis, welche Schritte sich als nächste anbieten (das tun
übrigens die meisten Git-Kommandos): „Erstellen oder kopieren Sie
Dateien, und verwenden Sie <code class="literal">git add</code>, um diese mit Git zu
verwalten.“</p>
</div>
<div class="section">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a id="sec.erster-commit"></a>1.2.2. Der erste Commit</h3>
</div>
</div>
</div>
<p>Übergeben wir Git nun eine erste Datei zur Verwaltung, und zwar ein
„Hello World!“-Programm in Perl. Selbstverständlich
können Sie stattdessen auch ein beliebiges Programm in der
Programmiersprache Ihrer Wahl schreiben.</p>
<p>Wir erstellen zunächst die Datei <code class="literal">hello.pl</code> mit folgendem
Inhalt</p>
<pre class="screen">print "Hello World!\n";</pre>
<p>und führen das Script einmal aus:</p>
<pre class="screen">$ <span class="strong"><strong>perl hello.pl</strong></span>
Hello World!</pre>
<p>Damit sind wir bereit, die Datei mit Git zu verwalten. Schauen wir
uns vorher aber noch die Ausgabe von <code class="literal">git status</code> an:</p>
<pre class="screen">$ <span class="strong"><strong>git status</strong></span>
On branch master
Initial commit
Untracked files:
(use "git add <file>..." to include in what will be committed)
hello.pl
nothing added to commit but untracked files present (use "git add" to track)</pre>
<p>Zwar steht der erste Commit noch bevor, aber Git registriert, dass
sich nun bereits Dateien in diesem Verzeichnis befinden, die dem System
allerdings nicht bekannt sind – Git nennt solche Dateien
<code class="literal">untracked</code>. Es handelt sich hier natürlich um unser kleines
Perl-Programm. Um es mit Git zu verwalten, nutzen wir den Befehl
<code class="literal">git add <datei></code>:</p>
<pre class="screen">$ <span class="strong"><strong>git add hello.pl</strong></span></pre>
<p>Das <code class="literal">add</code> steht generell für „Änderungen hinzufügen“ – Sie werden es also immer dann benötigen, wenn Sie Dateien
bearbeitet haben, nicht nur beim ersten Hinzufügen!</p>
<p>Git liefert bei diesem Befehl keine Ausgabe. Mit <code class="literal">git status</code>
überprüfen Sie, ob der Aufruf erfolgreich war:</p>
<pre class="screen">$ <span class="strong"><strong>git status</strong></span>
On branch master
Initial commit
Changes to be committed:
(use "git rm --cached <file>..." to unstage)
new file: hello.pl</pre>
<p>Git wird die Veränderungen – also unsere neue Datei – beim nächsten
Commit übernehmen. Allerdings ist dieser Commit noch nicht vollzogen – wir haben ihn bisher lediglich vorbereitet.</p>
<p>Um genau zu sein, haben wir die Datei dem <span class="emphasis"><em>Index</em></span> hinzugefügt,
einer Zwischenstufe, in der Sie Veränderungen, die in den nächsten
Commit einfließen sollen, sammeln. Weitere Erklärungen zu diesem
Konzept in <a class="xref" href="ch02.html#sec.index" title="2.1.1. Index">Abschnitt 2.1.1, „Index“</a>.</p>
<p>Bei <code class="literal">git status</code> sehen Sie unter
<code class="literal">Changes to be committed</code> immer, welche Dateien sich im Index
befinden, also in den nächsten Commit übernommen werden.</p>
<p>Alles ist bereit für den ersten Commit mit dem Kommando
<code class="literal">git commit</code>. Außerdem übergeben wir auf der Kommandozeile die
Option <code class="literal">-m</code> mit einer Commit-Nachricht (<span class="emphasis"><em>Commit Message</em></span>),
in der wir den Commit beschreiben:</p>
<pre class="screen">$ <span class="strong"><strong>git commit -m "Erste Version"</strong></span>
[master (root-commit) 07cc103] Erste Version
1 file changed, 1 insertion(+)
create mode 100644 hello.pl</pre>
<p>Git bestätigt, dass der Vorgang erfolgreich abgeschlossen wurde und
die Datei von nun an verwaltet wird. Die etwas kryptische Ausgabe
bedeutet soviel wie: Git hat den initialen Commit
(<code class="literal">root-commit</code>) mit der entsprechenden Nachricht erstellt. Es
wurde eine Zeile in einer Datei hinzugefügt und die Datei mit den
Unix-Rechten <code class="literal">0644</code> angelegt.<a href="#ftn.idm45240359901920" class="footnote" id="idm45240359901920"><sup class="footnote">[8]</sup></a></p>
<p>Wie Sie mittlerweile sicher festgestellt haben, ist <code class="literal">git
status</code> ein unerlässliches Kommando in der täglichen Arbeit – wir
nutzen es an dieser Stelle noch einmal:</p>
<pre class="screen">$ <span class="strong"><strong>git status</strong></span>
On branch master
nothing to commit, working directory clean</pre>
<p>Unser Beispiel-Repository ist jetzt „sauber“, denn es gibt
weder Veränderungen im Working Tree noch im Index, auch keine Dateien,
die nicht mit Git verwaltet werden (<span class="emphasis"><em>Untracked Files</em></span>).</p>
</div>
<div class="section">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a id="sec.commits-einsehen"></a>1.2.3. Commits einsehen</h3>
</div>
</div>
</div>
<p>Zum Abschluss dieser kleinen Einführung stellen wir Ihnen noch zwei
sehr nützliche Kommandos vor, die Sie häufig einsetzen werden, um die
Versionsgeschichte von Projekten zu untersuchen.</p>
<p>Zunächst erlaubt <code class="literal">git show</code> die Untersuchung eines einzelnen
Commits – ohne weitere Argumente ist das der aktuellste:</p>
<pre class="screen">$ <span class="strong"><strong>git show</strong></span>
commit 07cc103feb393a93616842921a7bec285178fd56
Author: Valentin Haenel <[email protected]>
Date: Tue Nov 16 00:40:54 2010 +0100
Erste Version
diff --git a/hello.pl b/hello.pl
new file mode 100644
index 0000000..fa5a091
--- /dev/null
+++ b/hello.pl
@@ -0,0 +1 @@
+print "Hello World!\n";</pre>
<p>Sie sehen alle relevanten Informationen zu dem Commit: die
<span class="emphasis"><em>Commit-ID</em></span>, den Autor, das Datum und die Uhrzeit des Commits,
die Commit-Nachricht sowie eine Zusammenfassung der Veränderungen im
<span class="emphasis"><em>Unified-Diff</em></span>-Format.</p>
<p>Standardmäßig gibt <code class="literal">git show</code> immer den <code class="literal">HEAD</code> aus (ein
symbolischer Name für den aktuellsten Commit); Sie könnten aber auch
z.B. die Commit-ID, also die SHA-1-Prüfsumme des Commits, ein
eindeutiges Präfix davon oder den Branch (in diesem Fall
<code class="literal">master</code>) angeben. Somit sind in
diesem Beispiel folgende Kommandos äquivalent:</p>
<pre class="screen">$ <span class="strong"><strong>git show</strong></span>
$ <span class="strong"><strong>git show HEAD</strong></span>
$ <span class="strong"><strong>git show master</strong></span>
$ <span class="strong"><strong>git show 07cc103</strong></span>
$ <span class="strong"><strong>git show 07cc103feb393a93616842921a7bec285178fd56</strong></span></pre>
<p>Wollen Sie mehr als einen Commit einsehen, empfiehlt sich <code class="literal">git
log</code>. Um das Kommando sinnvoll zu demonstrieren, bedarf es weiterer
Commits; andernfalls würde sich die Ausgabe kaum von <code class="literal">git show</code>
unterscheiden, da das Beispiel-Repository im Moment nur einen einzigen
Commit enthält. Fügen wir also folgende Kommentarzeile dem „Hello
World!“-Programm hinzu:</p>
<pre class="screen"># Hello World! in Perl</pre>
<p>Schauen wir uns der Übung halber noch einmal mit <code class="literal">git status</code>
den aktuellen Zustand an:</p>
<pre class="screen">$ <span class="strong"><strong>git status</strong></span>
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: hello.pl
no changes added to commit (use "git add" and/or "git commit -a")</pre>
<p>Benutzen Sie danach, wie in der Ausgabe des Kommandos schon
beschrieben, <code class="literal">git add</code>, um die Veränderungen dem Index
hinzuzufügen. Wie bereits erwähnt, wird <code class="literal">git add</code> sowohl zum
Hinzufügen neuer Dateien wie auch zum Hinzufügen von Veränderungen an
Dateien, die bereits verwaltet werden, verwendet.</p>
<pre class="screen">$ <span class="strong"><strong>git add hello.pl</strong></span></pre>
<p>Erstellen Sie anschließend einen Commit:</p>
<pre class="screen">$ <span class="strong"><strong>git commit -m "Kommentar-Zeile"</strong></span>
[master 8788e46] Kommentar-Zeile
1 file changed, 1 insertion(+)</pre>
<p>Nun zeigt Ihnen <code class="literal">git log</code> die beiden Commits:</p>
<pre class="screen">$ <span class="strong"><strong>git log</strong></span>
commit 8788e46167aec2f6be92c94c905df3b430f6ecd6
Author: Valentin Haenel <[email protected]>
Date: Fri May 27 12:52:58 2011 +0200
Kommentar-Zeile
commit 07cc103feb393a93616842921a7bec285178fd56
Author: Valentin Haenel <[email protected]>
Date: Tue Nov 16 00:40:54 2010 +0100
Erste Version</pre>
</div>
</div>
<div class="section">
<div class="titlepage">
<div>
<div>
<h2 class="title" style="clear: both"><a id="chap.git-config"></a>1.3. Git konfigurieren</h2>
</div>
</div>
</div>
<p>Wie die meisten textbasierten Programme bietet Git eine Fülle an
Konfigurationsoptionen. Es ist daher jetzt an der Zeit, einige
grundlegende Einstellungen vorzunehmen. Dazu gehören Farbeinstellungen,
die in neueren Versionen standardmäßig bereits eingeschaltet sind und
die es Ihnen erleichtern, die Ausgabe von Git-Kommandos zu erfassen,
sowie kleine Aliase (Abkürzungen) für häufig benötigte Kommandos.</p>
<p>Git konfigurieren Sie über das Kommando <code class="literal">git config</code>. Die
Konfiguration wird einem Format ähnlich einer INI-Datei gespeichert.
Ohne Angabe weiterer Parameter gilt die Konfiguration nur für das
aktuelle Repository (<code class="literal">.git/config</code>). Mit der Option <code class="literal">--global</code> wird sie in
der Datei <code class="literal">.gitconfig</code> im Home-Verzeichnis des Nutzers abgelegt
und gilt dann für alle Repositories.<a href="#ftn.idm45240359864608" class="footnote" id="idm45240359864608"><sup class="footnote">[9]</sup></a></p>
<p>Wichtige Einstellungen, die Sie immer vornehmen sollten, sind Name
und E-Mail-Adresse des Benutzers:</p>
<pre class="screen">$ <span class="strong"><strong>git config --global user.name "Max Mustermann"</strong></span>
$ <span class="strong"><strong>git config --global user.email "[email protected]"</strong></span></pre>
<p>Beachten Sie, dass Sie Leerzeichen im Wert der Einstellung schützen
müssen (durch Anführungszeichen oder Backslashes). Außerdem folgt der
Wert direkt auf den Namen der Option – ein Gleichheitszeichen ist auch
hier nicht nötig. Das Ergebnis des Kommandos findet sich anschließend
in der Datei <code class="literal">~/.gitconfig</code>:</p>
<pre class="screen">$ <span class="strong"><strong>less ~/.gitconfig</strong></span>
[user]
name = Max Mustermann
email = [email protected]</pre>
<p>Die Einstellungen gelten nun „global“, also für alle
Repositories, die Sie unter diesem Nutzernamen bearbeiten. Wollen Sie
für ein bestimmtes Projekt eine andere E-Mail-Adresse als Ihre global
definierte angeben, ändern Sie dort einfach die Einstellung (diesmal
natürlich ohne den Zusatz <code class="literal">--global</code>):</p>
<pre class="screen">$ <span class="strong"><strong>git config user.email [email protected]</strong></span></pre>
<p>Bei der Abfrage einer Option geht Git so vor, dass es zuerst die
Einstellung im aktuellen Repository nutzt, sofern vorhanden,
andernfalls die aus der globalen <code class="literal">.gitconfig</code>; gibt es auch
diese nicht, wird auf den Default-Wert
zurückgegriffen.<a href="#ftn.idm45240359853104" class="footnote" id="idm45240359853104"><sup class="footnote">[10]</sup></a> Letzteren erhält man für alle Optionen in der Man-Page
<code class="literal">git-config</code>. Eine Liste aller gesetzten Einstellungen fragen
Sie per <code class="literal">git config -l</code> ab.</p>
<p>Sie können die Datei <code class="literal">.gitconfig</code> (bzw. im Repository
<code class="literal">.git/config</code>) auch von Hand editieren. Gerade zum Löschen
einer Einstellung ist das sinnvoll – zwar bietet <code class="literal">git config</code>
auch eine Option <code class="literal">--unset</code>, die entsprechende Zeile in einem
Editor zu löschen ist aber einfacher.</p>
<div class="tip" style="margin-left: 0; margin-right: 10%;">
<h3 class="title">Tipp</h3>
<p>Die Kommandos <code class="literal">git config -e</code> bzw. <code class="literal">git config --global -e</code> starten
den für Git konfigurierten Editor auf der lokalen bzw. globalen
Konfigurationsdatei.</p>
</div>
<p>Beachten Sie allerdings, dass Git beim <span class="emphasis"><em>Setzen</em></span> von Optionen
durch ein entsprechendes Kommando problematische Zeichen im Wert der
Option automatisch schützt, so dass keine fehlerhaften
Konfigurationsdateien entstehen.</p>
<div class="section">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a id="sec.git-alias"></a>1.3.1. Git Aliase</h3>
</div>
</div>
</div>
<p>Git bietet Ihnen über <span class="emphasis"><em>Aliase</em></span> die Möglichkeit, einzelne
Kommandos und sogar ganze Kommandosequenzen abzukürzen. Die Syntax lautet:</p>
<pre class="screen">$ <span class="strong"><strong>git config alias.<alias-name> <entsprechung></strong></span></pre>
<p>Um etwa <code class="literal">st</code> als Alias für <code class="literal">status</code> zu setzen:</p>
<pre class="screen">$ <span class="strong"><strong>git config --global alias.st status</strong></span>
$ <span class="strong"><strong>git st</strong></span>
On branch master
...</pre>
<p>Sie können auch Optionen in ein Alias einbauen, z.B.:</p>
<pre class="screen">$ <span class="strong"><strong>git config --global alias.gconfig 'config --global'</strong></span></pre>
<p>Weitere nützliche Aliase finden Sie im weiteren Verlauf des Buches;
wie Sie komplexere Aliase erstellen, ist in
<a class="xref" href="ch08.html#sec.git-erweiterte-aliase" title="8.3.8. Erweiterte Aliase">Abschnitt 8.3.8, „Erweiterte Aliase“</a> beschrieben. Vorab aber schon
einige nützliche Abkürzungen:</p>
<pre class="screen">[alias]
st = status
ci = commit
br = branch
co = checkout
df = diff
he = help
cl = clone</pre>
</div>
<div class="section">
<div class="titlepage">
<div>
<div>
<h3 class="title"><a id="chap.color-defaults"></a>1.3.2. Farbe einstellen</h3>
</div>
</div>
</div>
<p>Überaus hilfreich ist die Option <code class="literal">color.ui</code>, die prüft, ob Git
die Ausgabe diverser Kommandos einfärben soll. So erscheinen gelöschte
Dateien und Zeilen rot, neue Dateien und Zeilen grün, Commit-IDs
gelb usw. In neueren Git-Versionen (ab 1.8.4) ist diese Einstellung
bereits automatisch gesetzt, Sie müssen also nichts tun.</p>
<p>Die Option <code class="literal">color.ui</code> sollte auf <code class="literal">auto</code> gesetzt sein – erfolgt die Ausgabe von Git in ein Terminal, werden Farben
verwendet. Schreibt das Kommando stattdessen in eine Datei oder wird
die Ausgabe an ein anderes Programm gepipet, so gibt Git keine
Farbsequenzen aus, da das die automatische Weiterverarbeitung
behindern könnte.</p>
<pre class="screen">$ <span class="strong"><strong>git config --global color.ui auto</strong></span></pre>
</div>
<div class="section">
<div class="titlepage">
<div>
<div>