-
Notifications
You must be signed in to change notification settings - Fork 0
/
Git-Book_3.html
1716 lines (1568 loc) · 400 KB
/
Git-Book_3.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
<!DOCTYPE html><html lang="en"><head>
<meta charset="UTF-8">
<meta http-equiv="X-UA-Compatible" content="IE=edge">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta name="generator" content="Asciidoctor 2.0.16">
<meta name="author" content="Valentin Haenel, Julius Plenz">
<title>Git Book — 2. The Basics</title>
<link rel="stylesheet" href="https://fonts.googleapis.com/css?family=Open+Sans:300,300italic,400,400italic,600,600italic%7CNoto+Serif:400,400italic,700,700italic%7CDroid+Sans+Mono:400,700">
<link rel="stylesheet" href="style0.css" type="text/css">
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/4.7.0/css/font-awesome.min.css">
<link rel="stylesheet" href="style1.css" type="text/css">
<link rel="stylesheet" href="asciidoctor-chunker.css" type="text/css"></head>
<body class="book toc2 toc-left">
<div id="header">
<h1>Git: Distributed Version Control for Code and Documents</h1>
<div class="details">
<span id="author" class="author">Valentin Haenel</span><br>
<span id="author2" class="author">Julius Plenz</span><br>
<span id="revnumber">version 3.0</span>
<br><span id="revremark">Beta Preview</span>
</div>
<div id="toc" class="toc2">
<div id="toctitle">Table of Contents</div>
<ul class="sectlevel1">
<li><a href="index.html">Title Page</a></li><li><a href="Git-Book_1.html">Preface</a>
<ul class="sectlevel2">
<li><a href="Git-Book_1.html#sec.reader">Who Is This Book Intended For?</a></li>
<li><a href="Git-Book_1.html#sec.structure">How to Read the Book?</a></li>
<li><a href="Git-Book_1.html#sec.conventions">Conventions</a></li>
<li><a href="Git-Book_1.html#sec.install-git-repo">Installation and “The Git-Repository”</a></li>
<li><a href="Git-Book_1.html#sec.docs">Documentation and Help</a></li>
<li><a href="Git-Book_1.html#sec.contact">Downloads and Contacts</a></li>
<li><a href="Git-Book_1.html#sec.acknowledgements">Acknowledgements</a></li>
<li><a href="Git-Book_1.html#sec.preface-2nd-edition">Preface to the 2nd Edition</a></li>
<li><a href="Git-Book_1.html#sec.preface-cc-edition">Preface to the Creative Commons Edition</a></li>
</ul>
</li>
<li><a href="Git-Book_2.html">1. Introduction and First Steps</a>
<ul class="sectlevel2">
<li><a href="Git-Book_2.html#sec.terminology">1.1. Basic Terminology</a></li>
<li><a href="Git-Book_2.html#sec.first-steps">1.2. First Steps with Git</a></li>
<li><a href="Git-Book_2.html#chap.git-config">1.3. Configuring Git</a></li>
</ul>
</li>
<li class="current"><a href="Git-Book_3.html">2. The Basics</a>
<ul class="sectlevel2">
<li class="current"><a href="Git-Book_3.html#sec.basics">2.1. Git Commands</a></li>
<li class="current"><a href="Git-Book_3.html#sec.object-model">2.2. The Object Model</a></li>
</ul>
</li>
<li><a href="Git-Book_4.html">3. Practical Version Control</a>
<ul class="sectlevel2">
<li><a href="Git-Book_4.html#sec.branches">3.1. References: Branches and Tags</a></li>
<li><a href="Git-Book_4.html#sec.undo">3.2. Restoring Versions</a></li>
<li><a href="Git-Book_4.html#sec.merge">3.3. Merging Branches</a></li>
<li><a href="Git-Book_4.html#sec.merge-conflicts">3.4. Resolving Merge Conflicts</a></li>
<li><a href="Git-Book_4.html#sec.cherry-pick">3.5. Taking over Individual Commits: Cherry Picking</a></li>
<li><a href="Git-Book_4.html#sec.visualization">3.6. Visualizing Repositories</a></li>
<li><a href="Git-Book_4.html#sec.reflog">3.7. Reflog</a></li>
</ul>
</li>
<li><a href="Git-Book_5.html">4. Advanced Concepts</a>
<ul class="sectlevel2">
<li><a href="Git-Book_5.html#sec.rebase">4.1. Moving commits — Rebase</a></li>
<li><a href="Git-Book_5.html#sec.rebase-i">4.2. Rewriting History — Interactive Rebase</a></li>
<li><a href="Git-Book_5.html#sec.blame">4.3. Who Made These Changes? — Git Blame</a></li>
<li><a href="Git-Book_5.html#sec.ignore">4.4. Ignoring Files</a></li>
<li><a href="Git-Book_5.html#sec.stash">4.5. Outsourcing Changes — Git Stash</a></li>
<li><a href="Git-Book_5.html#sec.notes">4.6. Annotating Commits — Git Notes</a></li>
<li><a href="Git-Book_5.html#sec.multi-root">4.7. Multiple Root Commits</a></li>
<li><a href="Git-Book_5.html#sec.bisect">4.8. Finding Regressions — Git Bisect</a></li>
</ul>
</li>
<li><a href="Git-Book_6.html">5. Distributed Git</a>
<ul class="sectlevel2">
<li><a href="Git-Book_6.html#sec.distributed-systems">5.1. How Does Distributed Version Control Work?</a></li>
<li><a href="Git-Book_6.html#sec.clone">5.2. Cloning Repositories</a></li>
<li><a href="Git-Book_6.html#sec.downloading-commits">5.3. Downloading Commits</a></li>
<li><a href="Git-Book_6.html#sec.uploading-commits">5.4. Uploading Commits: git push</a></li>
<li><a href="Git-Book_6.html#sec.remotes-check">5.5. Examining Remotes</a></li>
<li><a href="Git-Book_6.html#sec.multi-remote">5.6. Distributed Workflow with Multiple Remotes</a></li>
<li><a href="Git-Book_6.html#sec.managing-remotes">5.7. Managing Remotes</a></li>
<li><a href="Git-Book_6.html#sec.remote-tags">5.8. Exchanging Tags</a></li>
<li><a href="Git-Book_6.html#sec.patch-queue">5.9. Patches via E-mail</a></li>
<li><a href="Git-Book_6.html#sec.dictator">5.10. A Distributed, Hierarchical Workflow</a></li>
<li><a href="Git-Book_6.html#sec.subprojects">5.11. Managing Subprojects</a></li>
</ul>
</li>
<li><a href="Git-Book_7.html">6. Workflows</a>
<ul class="sectlevel2">
<li><a href="Git-Book_7.html#sec.workflows-user">6.1. User</a></li>
<li><a href="Git-Book_7.html#sec.branching-model">6.2. A Branching Model</a></li>
<li><a href="Git-Book_7.html#sec.releases-management">6.3. Release Management</a></li>
</ul>
</li>
<li><a href="Git-Book_8.html">7. Git Servers</a>
<ul class="sectlevel2">
<li><a href="Git-Book_8.html#sec.server">7.1. Hosting a Git Server</a></li>
<li><a href="Git-Book_8.html#sec.gitolite">7.2. Gitolite: Simple Git Hosting</a></li>
<li><a href="Git-Book_8.html#sec.git-daemon">7.3. Git Daemon: Anonymous Read-Only Access</a></li>
<li><a href="Git-Book_8.html#sec.gitweb">7.4. Gitweb: The Integrated Web Frontend</a></li>
<li><a href="Git-Book_8.html#sec.cgit">7.5. CGit — CGI for Git</a></li>
</ul>
</li>
<li><a href="Git-Book_9.html">8. Git Automation</a>
<ul class="sectlevel2">
<li><a href="Git-Book_9.html#sec.attributes">8.1. Git Attributes — Treating Files Separately</a></li>
<li><a href="Git-Book_9.html#sec.hooks">8.2. Hooks</a></li>
<li><a href="Git-Book_9.html#sec.scripting">8.3. Writing Your Own Git Commands</a></li>
<li><a href="Git-Book_9.html#sec.filter-branch">8.4. Rewriting Version History</a></li>
</ul>
</li>
<li><a href="Git-Book_10.html">9. Interacting with Other Version Control Systems</a>
<ul class="sectlevel2">
<li><a href="Git-Book_10.html#sec.subversion">9.1. Subversion</a></li>
<li><a href="Git-Book_10.html#sec.fast-import">9.2. Custom Importers</a></li>
</ul>
</li>
<li><a href="Git-Book_11.html">10. Shell Integration</a>
<ul class="sectlevel2">
<li><a href="Git-Book_11.html#sec.bash-integration">10.1. Git and the Bash</a></li>
<li><a href="Git-Book_11.html#sec.zsh-integration">10.2. Git and the Z-Shell</a></li>
</ul>
</li>
<li><a href="Git-Book_12.html">11. GitHub</a></li>
<li><a href="Git-Book_13.html">Appendix A: Installation</a>
<ul class="sectlevel2">
<li><a href="Git-Book_13.html#linux">A.1. Linux</a></li>
<li><a href="Git-Book_13.html#sec.osx">A.2. Mac OS X</a></li>
<li><a href="Git-Book_13.html#sec.windows">A.3. Windows</a></li>
</ul>
</li>
<li><a href="Git-Book_14.html">Appendix B: Repository Structure</a>
<ul class="sectlevel2">
<li><a href="Git-Book_14.html#sec.gc">B.1. Cleaning Up</a></li>
<li><a href="Git-Book_14.html#sec.gc-performance">B.2. Performance</a></li>
</ul>
</li>
</ul>
</div>
</div>
<div id="content"><div class="sect1">
<h2 id="ch.basics"><a class="anchor" href="Git-Book_3.html"></a>2. The Basics</h2>
<div class="sectionbody">
<div class="paragraph">
<p>In this chapter, we’ll introduce you to the most important Git commands that you can use to manage your project files in Git.
Understanding the Git object model is essential for advanced usage; we’ll cover this important concept in the second section of the chapter.
While these explanations may seem overly theoretical at first, we encourage you to read them carefully.
All further actions will be much easier for you with the knowledge of this background.</p>
</div>
<div class="sect2">
<h3 id="sec.basics"><a class="anchor" href="Git-Book_3.html#sec.basics"></a>2.1. Git Commands</h3>
<div class="paragraph">
<p>The commands you learned to get started (especially <code>add</code> and <code>commit</code>) work on the index.
In the following, we will take a closer look at the index and the extended use of these commands.</p>
</div>
<div class="sect3">
<h4 id="sec.index"><a class="anchor" href="Git-Book_3.html#sec.index"></a>2.1.1. Index</h4>
<div class="paragraph">
<p>The content of files for Git resides on three levels: the <em>working tree</em>, the <em>index</em>, and the Git <em>repository</em>.
The working tree corresponds to the files as they reside on your workstation’s file system — so if you edit files with an editor, search in them with <code>grep</code>, etc., you always operate on the working tree.</p>
</div>
<div class="paragraph">
<p>The repository is the repository for commits, that is, changes, with author, date, and description.
The commits together make up the <em>version history</em>.</p>
</div>
<div class="paragraph">
<p>Unlike many other version control systems, Git now introduces a new feature, the index.
It’s a somewhat elusive intermediate level between the working tree and the repository.
Its purpose is to prepare commits.
This means that you don’t always have to check in <em>all</em> the changes you have made to a file as commits.</p>
</div>
<div class="paragraph">
<p>The Git commands <code>add</code> and <code>reset</code> act (in their basic form) on the index, making changes to the index and deleting them again; only the <code>commit</code> command transfers the file to the repository as it is held in the index (<a href="Git-Book_3.html#fig.index">Figure 1, “Commands <code>add</code>, <code>reset</code> and <code>commit</code>”</a>).</p>
</div>
<div id="fig.index" class="imageblock text-center">
<div class="content">
<img src="data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHhtbG5zOnhsaW5rPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5L3hsaW5rIiB3aWR0aD0iNTYwcHQiIGhlaWdodD0iMTAwcHQiIHZpZXdCb3g9IjAgMCA1NjAgMTAwIj48ZGVmcz48c3ltYm9sIG92ZXJmbG93PSJ2aXNpYmxlIiBpZD0iYSI+PHBhdGggc3R5bGU9InN0cm9rZTpub25lIiBkPSJNNS4xNDggMCA0Ljk1LS45NDVINC45Yy0uMzMzLjQyMi0uNjY1LjcwMy0uOTkzLjg0Ny0uMzMyLjE0NS0uNzQyLjIxNS0xLjIzLjIyQzIuMDE2LjExNiAxLjUtLjA1MiAxLjEyOS0uMzg4Ljc1NC0uNzIzLjU2Ni0xLjIwMy41Ny0xLjgzNi41NjYtMy4xNzIgMS42NC0zLjg3NSAzLjc4NS0zLjk0bDEuMTI1LS4wNHYtLjQxYzAtLjUxNS0uMTEzLS45MDItLjMzNi0xLjE1Mi0uMjI2LS4yNS0uNTg2LS4zNzUtMS4wNzQtLjM3NS0uNTU1IDAtMS4xOC4xNzItMS44NzkuNTEybC0uMzA4LS43N2MuMzI4LS4xOC42ODMtLjMxNiAxLjA3NC0uNDE4YTUuMDAzIDUuMDAzIDAgMCAxIDEuMTc1LS4xNTJjLjc5LjAwNCAxLjM3Mi4xOCAxLjc1NC41MjcuMzguMzU2LjU3LjkxOC41NzUgMS42ODhWMFpNMi44NzUtLjcwN2MuNjI1LjAwNCAxLjExNy0uMTY4IDEuNDc3LS41MTYuMzU1LS4zNC41MzUtLjgyLjUzNS0xLjQ0MXYtLjYwMmwtMS4wMDQuMDQzYy0uODAxLjAzMi0xLjM4LjE1Ny0xLjczLjM3NS0uMzYuMjItLjUzNi41NjMtLjUzMiAxLjAyNC0uMDA0LjM2Ny4xMDYuNjQ0LjMyOC44MzIuMjE5LjE5NS41MjguMjg5LjkyNi4yODVabTAgMCIvPjwvc3ltYm9sPjxzeW1ib2wgb3ZlcmZsb3c9InZpc2libGUiIGlkPSJiIj48cGF0aCBzdHlsZT0ic3Ryb2tlOm5vbmUiIGQ9Ik01LjU4Mi0uODloLS4wNTVDNS4wNi0uMjIgNC4zNjcuMTE2IDMuNDQ1LjEyYy0uODY3LS4wMDQtMS41NDMtLjI5Ny0yLjAyNy0uODlDLjkzNC0xLjM2LjY5MS0yLjIwNC42OTUtMy4zMDJjLS4wMDQtMS4wOS4yMzktMS45NDEuNzI3LTIuNTQ3LjQ4LS42MDUgMS4xNTYtLjkwNiAyLjAyMy0uOTEuODk5LjAwNCAxLjU4Ni4zMjggMi4wNy45OGguMDc5bC0uMDQtLjQ3Ni0uMDI3LS40Njl2LTIuNjk5aDEuMDA4VjBoLS44MlpNMy41NzQtLjcyYy42ODQuMDA0IDEuMTgtLjE4MyAxLjQ4OS0uNTU4LjMwOC0uMzc1LjQ2LS45NzcuNDY0LTEuODEzdi0uMjFjLS4wMDQtLjkzOC0uMTYtMS42MS0uNDY4LTIuMDEzLS4zMTctLjQwMi0uODEzLS42MDUtMS40OTctLjYwNS0uNTkzIDAtMS4wNDYuMjMtMS4zNTUuNjg4LS4zMTYuNDYtLjQ3MyAxLjEwOS0uNDY5IDEuOTQtLjAwNC44NTMuMTUzIDEuNDkzLjQ2NSAxLjkyMy4zMTMuNDM3Ljc3LjY1MiAxLjM3MS42NDhabTAgMCIvPjwvc3ltYm9sPjxzeW1ib2wgb3ZlcmZsb3c9InZpc2libGUiIGlkPSJjIj48cGF0aCBzdHlsZT0ic3Ryb2tlOm5vbmUiIGQ9Ik00LjA5NC02Ljc1OGMuMjkzLjAwNC41NTguMDI4Ljc5My4wN2wtLjE0LjkzNGEzLjgyMyAzLjgyMyAwIDAgMC0uNzI3LS4wOWMtLjU0LjAwNC0xIC4yMjMtMS4zOC42NTctLjM4Mi40MzctLjU3NC45NzYtLjU3IDEuNjI1VjBIMS4wNjZ2LTYuNjM3aC44MjlsLjExNyAxLjIzaC4wNDdjLjI0Mi0uNDI5LjUzOS0uNzYxLjg5LTFhMi4wNSAyLjA1IDAgMCAxIDEuMTQ1LS4zNVptMCAwIi8+PC9zeW1ib2w+PHN5bWJvbCBvdmVyZmxvdz0idmlzaWJsZSIgaWQ9ImQiPjxwYXRoIHN0eWxlPSJzdHJva2U6bm9uZSIgZD0iTTMuODcxLjEyMWMtLjk4NC0uMDA0LTEuNzU4LS4zLTIuMzI0LS44OTRDLjk3Ny0xLjM3MS42OS0yLjIuNjk1LTMuMjY2Yy0uMDA0LTEuMDYyLjI1OC0xLjkxNC43OS0yLjU0Ni41MjMtLjYzIDEuMjM0LS45NDIgMi4xMjQtLjk0Ni44MjkuMDA0IDEuNDg1LjI3OCAxLjk3My44Mi40OC41NTEuNzIzIDEuMjcuNzI3IDIuMTY1di42MzZoLTQuNTdjLjAxOS43ODIuMjE0IDEuMzcxLjU5IDEuNzc0LjM2Ni40MDYuODk0LjYxIDEuNTc3LjYwNWE1LjI4MyA1LjI4MyAwIDAgMCAyLjEyMS0uNDQ5di44OThjLS4zNTkuMTU3LS42OTUuMjYyLTEuMDExLjMyOS0uMzE3LjA2Mi0uNy4wOTctMS4xNDUuMTAxWm0tLjI3My02LjAzOWMtLjUzNSAwLS45NjEuMTc2LTEuMjc4LjUyMy0uMzE2LjM0OC0uNTA0LjgyOS0uNTU4IDEuNDQySDUuMjNjLS4wMDMtLjYzMy0uMTQ0LTEuMTE3LS40MjUtMS40NTctLjI4Mi0uMzM2LS42ODQtLjUwOC0xLjIwNy0uNTA4Wm0wIDAiLz48L3N5bWJvbD48c3ltYm9sIG92ZXJmbG93PSJ2aXNpYmxlIiBpZD0iZSI+PHBhdGggc3R5bGU9InN0cm9rZTpub25lIiBkPSJNNS4zNDgtMS44MTNjLS4wMDQuNjI1LS4yMzUgMS4xMDItLjY5MiAxLjQzNC0uNDY1LjMzMi0xLjExLjQ5Ni0xLjkzNy41QzEuODM2LjExNyAxLjE0OS0uMDE5LjY2LS4yOTd2LS45MzNjLjMxNy4xNjQuNjU2LjI5MiAxLjAyNC4zODJhMy45MSAzLjkxIDAgMCAwIDEuMDU4LjE0MWMuNTI0LjAwNC45MjYtLjA3OCAxLjIxMS0uMjUuMjgxLS4xNjQuNDIyLS40MjIuNDI2LS43Ny0uMDA0LS4yNTMtLjExMy0uNDcyLS4zMzYtLjY2LS4yMjctLjE4LS42NjQtLjM5OC0xLjMxMy0uNjUyLS42MTctLjIzLTEuMDU4LS40My0xLjMxNi0uNjAyYTEuNjY1IDEuNjY1IDAgMCAxLS41ODItLjU4NiAxLjQ1OSAxLjQ1OSAwIDAgMS0uMTkxLS43OGMtLjAwNC0uNTQuMjE4LS45NjYuNjYtMS4yODIuNDM3LS4zMDkgMS4wMzktLjQ2NSAxLjgxMi0uNDY5LjcxMS4wMDQgMS40MS4xNDkgMi4wOTQuNDM0bC0uMzU1LjgyYy0uNjY4LS4yNzMtMS4yNzQtLjQxNC0xLjgxMy0uNDE0LS40OCAwLS44NC4wNzgtMS4wNzguMjI3LS4yNDYuMTUyLS4zNjcuMzU1LS4zNjMuNjE3YS42OTYuNjk2IDAgMCAwIC4xMzYuNDUzYy4wOS4xMjkuMjM1LjI1LjQzOC4zNi4yLjExNi41ODYuMjc3IDEuMTY0LjQ4OC43ODUuMjg5IDEuMzIuNTc4IDEuNTk4Ljg2Ny4yNzMuMjg5LjQxLjY1Ni40MTQgMS4wOTRabTAgMCIvPjwvc3ltYm9sPjxzeW1ib2wgb3ZlcmZsb3c9InZpc2libGUiIGlkPSJmIj48cGF0aCBzdHlsZT0ic3Ryb2tlOm5vbmUiIGQ9Ik0zLjIxLS43MDdhMi40NyAyLjQ3IDAgMCAwIC41MTMtLjA0Yy4xNjQtLjAyMy4yOTctLjA1LjM5NC0uMDgxdi43NjVhMS44NjggMS44NjggMCAwIDEtLjQ4LjEzMyA0Ljc3OCA0Ljc3OCAwIDAgMS0uNTc1LjA1MUMxLjc3OC4xMTcgMS4xMzctLjU1NSAxLjEzNy0xLjkwNnYtMy45NWgtLjk1di0uNDg0bC45NS0uNDE4LjQyNS0xLjQxOGguNTgzdjEuNTRINC4wN3YuNzhIMi4xNDV2My45MDdjMCAuNDAyLjA5My43MS4yODUuOTIyLjE4Ny4yMTguNDQ5LjMyNC43OC4zMlptMCAwIi8+PC9zeW1ib2w+PHN5bWJvbCBvdmVyZmxvdz0idmlzaWJsZSIgaWQ9ImciPjxwYXRoIHN0eWxlPSJzdHJva2U6bm9uZSIgZD0iTTMuNzE5LjEyMUMyLjc1NC4xMTcgMi4wMDgtLjE3NiAxLjQ4NC0uNzY2Ljk1NC0xLjM1Ni42OTEtMi4xOS42OTUtMy4yNzdjLS4wMDQtMS4xMDYuMjYyLTEuOTY1LjgwMS0yLjU3LjUzMS0uNjA2IDEuMjk3LS45MDcgMi4yOS0uOTEuMzE2LjAwMy42MzIuMDM4Ljk1Mi4xMDUuMzE3LjA3LjU2Ny4xNDguNzU0LjIzOGwtLjMwOC44NTVhNS4xMjggNS4xMjggMCAwIDAtLjcyNy0uMjE4IDMuNTcgMy41NyAwIDAgMC0uNjk1LS4wOWMtMS4zNTIuMDA0LTIuMDI4Ljg2My0yLjAyNCAyLjU3OC0uMDA0LjgyLjE2IDEuNDQ1LjQ5MiAxLjg3OS4zMjkuNDM3LjgxNy42NTYgMS40NjUuNjUyLjU1MS4wMDQgMS4xMTgtLjExNyAxLjctLjM1NXYuODljLS40NDYuMjI3LTEuMDA0LjM0LTEuNjc2LjM0NFptMCAwIi8+PC9zeW1ib2w+PHN5bWJvbCBvdmVyZmxvdz0idmlzaWJsZSIgaWQ9ImgiPjxwYXRoIHN0eWxlPSJzdHJva2U6bm9uZSIgZD0iTTYuNzkzLTMuMzI0Yy0uMDA0IDEuMDg2LS4yNzMgMS45My0uODE2IDIuNTM1LS41NDcuNjA1LTEuMzAxLjkwNi0yLjI1OC45MS0uNTk4LS4wMDQtMS4xMjUtLjE0LTEuNTgyLS40MThhMi43MzIgMi43MzIgMCAwIDEtMS4wNjctMS4yQy44MTYtMi4wMTEuNjkxLTIuNjIuNjk1LTMuMzIzYy0uMDA0LTEuMDc4LjI2Ni0xLjkyMi44MTMtMi41MjguNTM5LS42MDEgMS4yOTMtLjkwMiAyLjI1NC0uOTA2LjkyNS4wMDQgMS42Ni4zMTMgMi4yMS45MjYuNTQ0LjYyMS44MTcgMS40NTcuODIxIDIuNTA4Wm0tNS4wNTUgMGMtLjAwNC44NTEuMTY0IDEuNDk2LjUwOCAxLjkzNy4zMzYuNDUuODM2LjY3MiAxLjQ5Ni42NjguNjU2LjAwNCAxLjE1Ni0uMjE5IDEuNS0uNjY0LjM0LS40NDEuNTEyLTEuMDg2LjUxMi0xLjk0MSAwLS44NC0uMTcyLTEuNDgtLjUxMi0xLjkyMi0uMzQ0LS40MzgtLjg0Ny0uNjYtMS41MTItLjY2LS42NiAwLTEuMTU2LjIxOC0xLjQ5Mi42NDgtLjMzNi40MzgtLjUwNCAxLjA4Mi0uNSAxLjkzNFptMCAwIi8+PC9zeW1ib2w+PHN5bWJvbCBvdmVyZmxvdz0idmlzaWJsZSIgaWQ9ImkiPjxwYXRoIHN0eWxlPSJzdHJva2U6bm9uZSIgZD0iTTkuNTI3IDB2LTQuMzE2YzAtLjUyOC0uMTEzLS45MjYtLjM0LTEuMTkyLS4yMjYtLjI2NS0uNTc4LS4zOTgtMS4wNTQtLjM5OC0uNjI1IDAtMS4wOS4xOC0xLjM4Ny41MzktLjMwNS4zNi0uNDUzLjkxNC0uNDUgMS42NlYwSDUuMjk0di00LjMxNmMtLjAwNC0uNTI4LS4xMTctLjkyNi0uMzQtMS4xOTItLjIzLS4yNjUtLjU4Mi0uMzk4LTEuMDU4LS4zOTgtLjYzMyAwLTEuMDk0LjE5MS0xLjM4Ny41NjYtLjI5My4zODMtLjQ0MiAxLS40MzggMS44NlYwSDEuMDY2di02LjYzN2guODE3bC4xNjQuOTA3aC4wNDdjLjE4Ny0uMzIuNDU3LS41Ny44LS43NTQuMzQ0LS4xOC43MzEtLjI3IDEuMTY1LS4yNzQgMS4wMzUuMDA0IDEuNzE0LjM4IDIuMDM1IDEuMTI1aC4wNDdBMi4xIDIuMSAwIDAgMSA3LTYuNDUzYy4zNzEtLjIuOC0uMyAxLjI4NS0uMzA1Ljc1LjAwNCAxLjMwOS4xOTYgMS42ODQuNTc4LjM3LjM4Ny41NTggMS4wMDQuNTYyIDEuODUyVjBabTAgMCIvPjwvc3ltYm9sPjxzeW1ib2wgb3ZlcmZsb3c9InZpc2libGUiIGlkPSJqIj48cGF0aCBzdHlsZT0ic3Ryb2tlOm5vbmUiIGQ9Ik0yLjA3IDBIMS4wNjZ2LTYuNjM3SDIuMDdaTS45OC04LjQzOGMtLjAwMy0uMjI2LjA1NS0uMzk0LjE2OC0uNTAzYS42My42MyAwIDAgMSAuODQ0LjAwNGMuMTE3LjExMy4xNzYuMjc3LjE3Ni41IDAgLjIyNi0uMDU5LjM5OC0uMTc2LjUwN2EuNTUuNTUgMCAwIDEtLjQxOC4xNjguNTQ2LjU0NiAwIDAgMS0uNDI2LS4xNjhjLS4xMTMtLjExLS4xNzEtLjI4LS4xNjgtLjUwOFptMCAwIi8+PC9zeW1ib2w+PHN5bWJvbCBvdmVyZmxvdz0idmlzaWJsZSIgaWQ9ImsiPjxwYXRoIHN0eWxlPSJzdHJva2U6bm9uZSIgZD0iTTguOTQ1IDBoLTEuMDJMNi4xNDItNS45M2MtLjA4Ni0uMjYxLS4xODQtLjU5LS4yODYtLjk5Mi0uMTA5LS4zOTQtLjE2NC0uNjM3LS4xNjQtLjcxOWExNi4wMTMgMTYuMDEzIDAgMCAxLS40MjEgMS43NUwzLjUzNSAwSDIuNTJMLjE2NC04Ljg1NWgxLjA5bDEuMzk4IDUuNDY4Yy4xOTIuNzcuMzMyIDEuNDY1LjQyNiAyLjA4Ni4xMDItLjczOC4yNjYtMS40Ni40ODUtMi4xNjhsMS41ODUtNS4zODZoMS4wOWwxLjY2NCA1LjQzM2MuMTkyLjYyNS4zNTYgMS4zMzIuNDkzIDIuMTIxLjA3NC0uNTcuMjE4LTEuMjcuNDMzLTIuMDk3bDEuMzk1LTUuNDU3aDEuMDlabTAgMCIvPjwvc3ltYm9sPjxzeW1ib2wgb3ZlcmZsb3c9InZpc2libGUiIGlkPSJsIj48cGF0aCBzdHlsZT0ic3Ryb2tlOm5vbmUiIGQ9Ik0yLjA1OS0zLjM5OGMuMTcxLS4yNDMuNDM3LS41NjMuNzkzLS45N2wyLjE0NC0yLjI2OWgxLjE5MUwzLjUtMy44MDkgNi4zNzUgMEg1LjE2TDIuODE2LTMuMTM3bC0uNzU3LjY1M1YwaC0uOTkzdi05LjQyMmguOTkzdjQuOTk2Yy0uMDA0LjIyNy0uMDIuNTY3LS4wNDcgMS4wMjhabTAgMCIvPjwvc3ltYm9sPjxzeW1ib2wgb3ZlcmZsb3c9InZpc2libGUiIGlkPSJtIj48cGF0aCBzdHlsZT0ic3Ryb2tlOm5vbmUiIGQ9Ik01LjYxIDB2LTQuMjkzYy0uMDA1LS41MzktLjEyNi0uOTQxLS4zNzItMS4yMS0uMjUtLjI2Ny0uNjM2LS40MDMtMS4xNTYtLjQwMy0uNyAwLTEuMjA3LjE5MS0xLjUyNy41NjYtLjMyNS4zOC0uNDg5Ljk5Ni0uNDg1IDEuODZWMEgxLjA2NnYtNi42MzdoLjgxN2wuMTY0LjkwN2guMDQ3Yy4yMDMtLjMyNS40OTItLjU3NS44NjctLjc1OGEyLjkgMi45IDAgMCAxIDEuMjQyLS4yN2MuNzk3LjAwNCAxLjM5OS4xOTYgMS44MDUuNTc4LjM5OC4zODcuNjAxIDEuMDA0LjYwNSAxLjg1MlYwWm0wIDAiLz48L3N5bWJvbD48c3ltYm9sIG92ZXJmbG93PSJ2aXNpYmxlIiBpZD0ibiI+PHBhdGggc3R5bGU9InN0cm9rZTpub25lIiBkPSJNNi40OTYtNi42MzdWLTZsLTEuMjI2LjE0NWMuMTA5LjE0NC4yMS4zMjguMy41NTQuMDg2LjIzLjEzLjQ4OS4xMzMuNzctLjAwNC42NTYtLjIyNiAxLjE3Ni0uNjY4IDEuNTU4LS40NDUuMzkxLTEuMDUuNTgyLTEuODI0LjU4Mi0uMiAwLS4zODctLjAxNS0uNTU5LS4wNS0uNDMuMjMtLjY0NC41MTUtLjY0Ljg1NWEuNDE3LjQxNyAwIDAgMCAuMjIyLjQwMmMuMTQ1LjA4Ni40MDMuMTMuNzcuMTNINC4xOGMuNzE1IDAgMS4yNy4xNTIgMS42NTYuNDU2LjM4My4zMDUuNTc0Ljc0My41NzggMS4zMTctLjAwNC43MzQtLjMgMS4yOTctLjg4NyAxLjY4My0uNTkzLjM4My0xLjQ1My41NzUtMi41NzguNTc4LS44Ny0uMDAzLTEuNTM5LS4xNjQtMi4wMDgtLjQ4NEMuNDcgMi4xNzIuMjM0IDEuNzE1LjIzNCAxLjEyNWMwLS40MDYuMTMtLjc1OC4zODctMS4wNDcuMjU4LS4yOTcuNjIxLS40OTIgMS4wOTQtLjU5OGExLjAwMiAxLjAwMiAwIDAgMS0uNDMtLjM1OS45MjQuOTI0IDAgMCAxLS4xNzItLjU2MmMwLS4yNDMuMDYzLS40NTQuMTkyLS42MzcuMTI5LS4xOC4zMzItLjM1Ni42MTMtLjUyN2ExLjcyNSAxLjcyNSAwIDAgMS0uODM2LS43MiAyLjA1OCAyLjA1OCAwIDAgMS0uMzI0LTEuMTYzYy0uMDA0LS43MjcuMjE1LTEuMjg1LjY1Mi0xLjY4LjQzNC0uMzkgMS4wNS0uNTg2IDEuODU2LS41OS4zNDMuMDA0LjY1Ni4wNDMuOTM3LjEyMVptLTUuMjg5IDcuNzVjMCAuMzYuMTQ4LjYzLjQ1My44MTcuMjk3LjE4My43My4yNzcgMS4zLjI4Ljg0LS4wMDMgMS40NjYtLjEyOCAxLjg3Ni0uMzc4LjQwMi0uMjU0LjYwNS0uNTk4LjYxLTEuMDI3QzUuNDQuNDQgNS4zMzEuMTkgNS4xMDguMDU1Yy0uMjIyLS4xNC0uNjQtLjIwNy0xLjI1LS4yMDdIMi42NTJjLS40NTcgMC0uODEyLjEwOS0xLjA2Ni4zMjgtLjI1NC4yMTktLjM3OS41MzEtLjM3OS45MzdabS41NDMtNS42MjVjLS4wMDQuNDY1LjEyOS44MTcuMzk1IDEuMDU1LjI2MS4yMzguNjI1LjM2IDEuMDkzLjM1NS45OC4wMDQgMS40NzMtLjQ3MiAxLjQ3My0xLjQzIDAtLjk5MS0uNDk2LTEuNDkxLTEuNDg4LTEuNDk1LS40NzcuMDA0LS44NDQuMTMyLTEuMDk0LjM4Mi0uMjU4LjI1OC0uMzgzLjYzMy0uMzc5IDEuMTMzWm0wIDAiLz48L3N5bWJvbD48c3ltYm9sIG92ZXJmbG93PSJ2aXNpYmxlIiBpZD0icCI+PHBhdGggc3R5bGU9InN0cm9rZTpub25lIiBkPSJNMy45NDEgMEgyLjkxNHYtNy45MzhILjExdi0uOTE3aDYuNjM3di45MThIMy45NDFabTAgMCIvPjwvc3ltYm9sPjxzeW1ib2wgb3ZlcmZsb3c9InZpc2libGUiIGlkPSJxIj48cGF0aCBzdHlsZT0ic3Ryb2tlOm5vbmUiIGQ9Ik0xLjIxOSAwdi04Ljg1NWgxLjAyN1YwWm0wIDAiLz48L3N5bWJvbD48c3ltYm9sIG92ZXJmbG93PSJ2aXNpYmxlIiBpZD0iciI+PHBhdGggc3R5bGU9InN0cm9rZTpub25lIiBkPSJNMi42NjQtMy4zOTguMzU1LTYuNjM3SDEuNWwxLjc1NCAyLjU0MyAxLjc0Mi0yLjU0M0g2LjEzTDMuODItMy4zOTggNi4yNSAwSDUuMTFMMy4yNTMtMi42ODggMS4zNzUgMEguMjM1Wm0wIDAiLz48L3N5bWJvbD48c3ltYm9sIG92ZXJmbG93PSJ2aXNpYmxlIiBpZD0icyI+PHBhdGggc3R5bGU9InN0cm9rZTpub25lIiBkPSJNMi4yNDYtMy42ODRWMEgxLjIydi04Ljg1NWgyLjQyNmMxLjA4NS4wMDMgMS44ODYuMjEgMi40MDYuNjI1LjUyLjQxOC43ODEgMS4wNDMuNzgxIDEuODc4IDAgMS4xNzItLjU5NCAxLjk2NS0xLjc4MSAyLjM3Mkw3LjQ1MyAwSDYuMjM4TDQuMDk0LTMuNjg0Wm0wLS44ODJoMS40MWMuNzI3LjAwMyAxLjI1OC0uMTQxIDEuNTk4LS40MzQuMzQtLjI4NS41MTItLjcxOS41MTItMS4yOTcgMC0uNTgyLS4xNzYtMS4wMDQtLjUyLTEuMjY2LS4zNDgtLjI1Ny0uODk4LS4zODYtMS42Ni0uMzloLTEuMzRabTAgMCIvPjwvc3ltYm9sPjxzeW1ib2wgb3ZlcmZsb3c9InZpc2libGUiIGlkPSJ0Ij48cGF0aCBzdHlsZT0ic3Ryb2tlOm5vbmUiIGQ9Ik00LjE1Ni4xMjFBMi45ODMgMi45ODMgMCAwIDEgMi45Ny0uMTE3YTIuMTMgMi4xMyAwIDAgMS0uODk5LS43MzhIMmMuMDQzLjM5LjA2Ni43NTcuMDcgMS4xMDV2Mi43M0gxLjA2NnYtOS42MTdoLjgxN2wuMTQuOTA3aC4wNDdhMi4zMiAyLjMyIDAgMCAxIC45MDMtLjc4NmMuMzQtLjE2LjczNC0uMjM4IDEuMTgzLS4yNDIuODc1LjAwNCAxLjU1NS4zMDUgMi4wMzUuOTAzLjQ3Ny42MDUuNzE1IDEuNDQ5LjcyIDIuNTMtLjAwNSAxLjA5NS0uMjQ3IDEuOTM4LS43MzEgMi41NC0uNDg5LjYwMS0xLjE2NC45MDItMi4wMjQuOTA2Wm0tLjE0OC02LjAyN2MtLjY4IDAtMS4xNzIuMTkxLTEuNDczLjU2Ni0uMzA1LjM4LS40Ni45NzctLjQ2NSAxLjc5M3YuMjIzYy0uMDA0LjkzNy4xNTMgMS42MDUuNDY1IDIuMDA0LjMwOS40MDYuODA5LjYwNSAxLjQ5Ni42MDEuNTc0LjAwNCAxLjAyNC0uMjI2IDEuMzQ4LS42OTUuMzI0LS40NjEuNDg0LTEuMTAyLjQ4OC0xLjkyMi0uMDA0LS44MjQtLjE2NC0xLjQ2LS40ODgtMS45MDYtLjMyNC0uNDQyLS43ODEtLjY2NC0xLjM3MS0uNjY0Wm0wIDAiLz48L3N5bWJvbD48c3ltYm9sIG92ZXJmbG93PSJ2aXNpYmxlIiBpZD0idSI+PHBhdGggc3R5bGU9InN0cm9rZTpub25lIiBkPSJNLjAxMi02LjYzN0gxLjA5bDEuNDUzIDMuNzg1Yy4zMi44NjguNTE2IDEuNDkzLjU5NCAxLjg3MmguMDQ3Yy4wNS0uMjA0LjE2NC0uNTU1LjMzMi0xLjA1NS4xNjQtLjQ5Ni43MS0yLjAzMSAxLjY0NC00LjYwMmgxLjA3OEwzLjM4Ny45MjJjLS4yODUuNzQyLS42MTcgMS4yNzMtLjk5MiAxLjU4Ni0uMzguMzEyLS44NDQuNDY5LTEuMzkxLjQ3MmE0LjM4NiA0LjM4NiAwIDAgMS0uOTA2LS4xMDVWMi4wN2MuMjE4LjA0Ny40NjQuMDc1Ljc0Mi4wNzUuNjg3IDAgMS4xODMtLjM5MSAxLjQ4LTEuMTY1bC4zNjgtLjk0NVptMCAwIi8+PC9zeW1ib2w+PC9kZWZzPjxwYXRoIHN0eWxlPSJmaWxsLXJ1bGU6bm9uemVybztmaWxsOiNmZmY7ZmlsbC1vcGFjaXR5OjE7c3Ryb2tlLXdpZHRoOjA7c3Ryb2tlLWxpbmVjYXA6YnV0dDtzdHJva2UtbGluZWpvaW46bWl0ZXI7c3Ryb2tlOiMwMDA7c3Ryb2tlLW9wYWNpdHk6MTtzdHJva2UtbWl0ZXJsaW1pdDoxMCIgZD0iTTAgMGgyOHY1SDBabTAgMCIgdHJhbnNmb3JtPSJzY2FsZSgyMCkiLz48cGF0aCBzdHlsZT0iZmlsbDpub25lO3N0cm9rZS13aWR0aDouMjU7c3Ryb2tlLWxpbmVjYXA6YnV0dDtzdHJva2UtbGluZWpvaW46bWl0ZXI7c3Ryb2tlOiMwMDA7c3Ryb2tlLW9wYWNpdHk6MTtzdHJva2UtbWl0ZXJsaW1pdDoxMCIgZD0iTTcgMi41aDMuNDc1IiB0cmFuc2Zvcm09InNjYWxlKDIwKSIvPjxwYXRoIHN0eWxlPSJmaWxsLXJ1bGU6ZXZlbm9kZDtmaWxsOiMwMDA7ZmlsbC1vcGFjaXR5OjE7c3Ryb2tlLXdpZHRoOi4yNTtzdHJva2UtbGluZWNhcDpidXR0O3N0cm9rZS1saW5lam9pbjptaXRlcjtzdHJva2U6IzAwMDtzdHJva2Utb3BhY2l0eToxO3N0cm9rZS1taXRlcmxpbWl0OjEwIiBkPSJtMTAuNDc1IDIuNy40LS4yLS40LS4ydi40Wm0wIDAiIHRyYW5zZm9ybT0ic2NhbGUoMjApIi8+PGcgc3R5bGU9ImZpbGw6IzAwMDtmaWxsLW9wYWNpdHk6MSI+PHVzZSB4bGluazpocmVmPSIjYSIgeD0iMTY4Ljk2NSIgeT0iMzkiLz48dXNlIHhsaW5rOmhyZWY9IiNiIiB4PSIxNzUuODU5IiB5PSIzOSIvPjx1c2UgeGxpbms6aHJlZj0iI2IiIHg9IjE4My40NTciIHk9IjM5Ii8+PC9nPjxwYXRoIHN0eWxlPSJmaWxsOm5vbmU7c3Ryb2tlLXdpZHRoOi4yNTtzdHJva2UtbGluZWNhcDpidXR0O3N0cm9rZS1saW5lam9pbjptaXRlcjtzdHJva2U6IzAwMDtzdHJva2Utb3BhY2l0eToxO3N0cm9rZS1taXRlcmxpbWl0OjEwIiBkPSJNMTcuNSAyLjkyNWgzLjQ3NSIgdHJhbnNmb3JtPSJzY2FsZSgyMCkiLz48cGF0aCBzdHlsZT0iZmlsbC1ydWxlOmV2ZW5vZGQ7ZmlsbDojMDAwO2ZpbGwtb3BhY2l0eToxO3N0cm9rZS13aWR0aDouMjU7c3Ryb2tlLWxpbmVjYXA6YnV0dDtzdHJva2UtbGluZWpvaW46bWl0ZXI7c3Ryb2tlOiMwMDA7c3Ryb2tlLW9wYWNpdHk6MTtzdHJva2UtbWl0ZXJsaW1pdDoxMCIgZD0ibTE3LjUgMi43MjUtLjQuMi40LjJ2LS40Wm0wIDAiIHRyYW5zZm9ybT0ic2NhbGUoMjApIi8+PGcgc3R5bGU9ImZpbGw6IzAwMDtmaWxsLW9wYWNpdHk6MSI+PHVzZSB4bGluazpocmVmPSIjYyIgeD0iMzY0Ljg3MSIgeT0iNzguNSIvPjx1c2UgeGxpbms6aHJlZj0iI2QiIHg9IjM2OS45MyIgeT0iNzguNSIvPjx1c2UgeGxpbms6aHJlZj0iI2UiIHg9IjM3Ni44ODMiIHk9Ijc4LjUiLz48dXNlIHhsaW5rOmhyZWY9IiNkIiB4PSIzODIuODAxIiB5PSI3OC41Ii8+PHVzZSB4bGluazpocmVmPSIjZiIgeD0iMzg5Ljc1NCIgeT0iNzguNSIvPjwvZz48ZyBzdHlsZT0iZmlsbDojMDAwO2ZpbGwtb3BhY2l0eToxIj48dXNlIHhsaW5rOmhyZWY9IiNnIiB4PSIzNTguMDA4IiB5PSIzMS41Ii8+PHVzZSB4bGluazpocmVmPSIjaCIgeD0iMzYzLjkwNiIgeT0iMzEuNSIvPjx1c2UgeGxpbms6aHJlZj0iI2kiIHg9IjM3MS40MDYiIHk9IjMxLjUiLz48dXNlIHhsaW5rOmhyZWY9IiNpIiB4PSIzODIuOTQ5IiB5PSIzMS41Ii8+PHVzZSB4bGluazpocmVmPSIjaiIgeD0iMzk0LjQ5MiIgeT0iMzEuNSIvPjx1c2UgeGxpbms6aHJlZj0iI2YiIHg9IjM5Ny42MzciIHk9IjMxLjUiLz48L2c+PHBhdGggc3R5bGU9ImZpbGw6bm9uZTtzdHJva2Utd2lkdGg6LjI1O3N0cm9rZS1saW5lY2FwOmJ1dHQ7c3Ryb2tlLWxpbmVqb2luOm1pdGVyO3N0cm9rZTojMDAwO3N0cm9rZS1vcGFjaXR5OjE7c3Ryb2tlLW1pdGVybGltaXQ6MTAiIGQ9Ik0xNyAyLjA3NWgzLjQ3NSIgdHJhbnNmb3JtPSJzY2FsZSgyMCkiLz48cGF0aCBzdHlsZT0iZmlsbC1ydWxlOmV2ZW5vZGQ7ZmlsbDojMDAwO2ZpbGwtb3BhY2l0eToxO3N0cm9rZS13aWR0aDouMjU7c3Ryb2tlLWxpbmVjYXA6YnV0dDtzdHJva2UtbGluZWpvaW46bWl0ZXI7c3Ryb2tlOiMwMDA7c3Ryb2tlLW9wYWNpdHk6MTtzdHJva2UtbWl0ZXJsaW1pdDoxMCIgZD0ibTIwLjQ3NSAyLjI3NS40LS4yLS40LS4ydi40Wm0wIDAiIHRyYW5zZm9ybT0ic2NhbGUoMjApIi8+PHBhdGggc3R5bGU9InN0cm9rZTpub25lO2ZpbGwtcnVsZTpldmVub2RkO2ZpbGw6I2U5YTRkZTtmaWxsLW9wYWNpdHk6MSIgZD0iTTI2IDMwaDEwOHY0MEgyNlpNMjYgMzZ2LTZjLTMuMzEzIDAtNiAyLjY4OC02IDZoNlpNMTM0IDM2aDZjMC0zLjMxMy0yLjY4OC02LTYtNnY2Wm0wIDAiLz48cGF0aCBzdHlsZT0ic3Ryb2tlOm5vbmU7ZmlsbC1ydWxlOmV2ZW5vZGQ7ZmlsbDojZTlhNGRlO2ZpbGwtb3BhY2l0eToxIiBkPSJNMjAgMzZoMTIwdjI4SDIwWk0yNiA2NGgtNmMwIDMuMzEzIDIuNjg4IDYgNiA2di02Wk0xMzQgNjR2NmMzLjMxMyAwIDYtMi42ODggNi02aC02Wm0wIDAiLz48cGF0aCBzdHlsZT0iZmlsbDpub25lO3N0cm9rZS13aWR0aDouMTtzdHJva2UtbGluZWNhcDpidXR0O3N0cm9rZS1saW5lam9pbjptaXRlcjtzdHJva2U6IzAwMDtzdHJva2Utb3BhY2l0eToxO3N0cm9rZS1taXRlcmxpbWl0OjEwIiBkPSJNMS4zIDEuNWg1LjRNMS4zIDMuNWg1LjRNMS4zIDEuNWEuMy4zIDAgMCAwLS4zLjNNNyAxLjhhLjMuMyAwIDAgMC0uMy0uM00xIDEuOHYxLjRNNyAxLjh2MS40TTEgMy4yYS4zLjMgMCAwIDAgLjMuM002LjcgMy41YS4zLjMgMCAwIDAgLjMtLjMiIHRyYW5zZm9ybT0ic2NhbGUoMjApIi8+PGcgc3R5bGU9ImZpbGw6IzAwMDtmaWxsLW9wYWNpdHk6MSI+PHVzZSB4bGluazpocmVmPSIjayIgeD0iNDEuNDI2IiB5PSI1NS40ODgiLz48dXNlIHhsaW5rOmhyZWY9IiNoIiB4PSI1Mi45MSIgeT0iNTUuNDg4Ii8+PHVzZSB4bGluazpocmVmPSIjYyIgeD0iNjAuNDEiIHk9IjU1LjQ4OCIvPjx1c2UgeGxpbms6aHJlZj0iI2wiIHg9IjY1LjQ2OSIgeT0iNTUuNDg4Ii8+PHVzZSB4bGluazpocmVmPSIjaiIgeD0iNzEuOTczIiB5PSI1NS40ODgiLz48dXNlIHhsaW5rOmhyZWY9IiNtIiB4PSI3NS4xMTciIHk9IjU1LjQ4OCIvPjx1c2UgeGxpbms6aHJlZj0iI24iIHg9IjgyLjczNCIgeT0iNTUuNDg4Ii8+PHVzZSB4bGluazpocmVmPSIjbyIgeD0iODkuNTMxIiB5PSI1NS40ODgiLz48dXNlIHhsaW5rOmhyZWY9IiNwIiB4PSI5Mi43NTQiIHk9IjU1LjQ4OCIvPjx1c2UgeGxpbms6aHJlZj0iI2MiIHg9Ijk5LjYwOSIgeT0iNTUuNDg4Ii8+PHVzZSB4bGluazpocmVmPSIjZCIgeD0iMTA0LjY2OCIgeT0iNTUuNDg4Ii8+PHVzZSB4bGluazpocmVmPSIjZCIgeD0iMTExLjYyMSIgeT0iNTUuNDg4Ii8+PC9nPjxwYXRoIHN0eWxlPSJzdHJva2U6bm9uZTtmaWxsLXJ1bGU6ZXZlbm9kZDtmaWxsOiNhOWU1YTE7ZmlsbC1vcGFjaXR5OjEiIGQ9Ik0yMjYgMzBoMTA4djQwSDIyNlpNMjI2IDM2di02Yy0zLjMxMyAwLTYgMi42ODgtNiA2aDZaTTMzNCAzNmg2YzAtMy4zMTMtMi42ODgtNi02LTZ2NlptMCAwIi8+PHBhdGggc3R5bGU9InN0cm9rZTpub25lO2ZpbGwtcnVsZTpldmVub2RkO2ZpbGw6I2E5ZTVhMTtmaWxsLW9wYWNpdHk6MSIgZD0iTTIyMCAzNmgxMjB2MjhIMjIwWk0yMjYgNjRoLTZjMCAzLjMxMyAyLjY4OCA2IDYgNnYtNlpNMzM0IDY0djZjMy4zMTMgMCA2LTIuNjg4IDYtNmgtNlptMCAwIi8+PHBhdGggc3R5bGU9ImZpbGw6bm9uZTtzdHJva2Utd2lkdGg6LjE7c3Ryb2tlLWxpbmVjYXA6YnV0dDtzdHJva2UtbGluZWpvaW46bWl0ZXI7c3Ryb2tlOiMwMDA7c3Ryb2tlLW9wYWNpdHk6MTtzdHJva2UtbWl0ZXJsaW1pdDoxMCIgZD0iTTExLjMgMS41aDUuNE0xMS4zIDMuNWg1LjRNMTEuMyAxLjVhLjMuMyAwIDAgMC0uMy4zTTE3IDEuOGEuMy4zIDAgMCAwLS4zLS4zTTExIDEuOHYxLjRNMTcgMS44djEuNE0xMSAzLjJhLjMuMyAwIDAgMCAuMy4zTTE2LjcgMy41YS4zLjMgMCAwIDAgLjMtLjMiIHRyYW5zZm9ybT0ic2NhbGUoMjApIi8+PGcgc3R5bGU9ImZpbGw6IzAwMDtmaWxsLW9wYWNpdHk6MSI+PHVzZSB4bGluazpocmVmPSIjcSIgeD0iMjYzLjk0NSIgeT0iNTUuNDg4Ii8+PHVzZSB4bGluazpocmVmPSIjbSIgeD0iMjY3LjQwMiIgeT0iNTUuNDg4Ii8+PHVzZSB4bGluazpocmVmPSIjYiIgeD0iMjc1LjAyIiB5PSI1NS40ODgiLz48dXNlIHhsaW5rOmhyZWY9IiNkIiB4PSIyODIuNjE3IiB5PSI1NS40ODgiLz48dXNlIHhsaW5rOmhyZWY9IiNyIiB4PSIyODkuNTciIHk9IjU1LjQ4OCIvPjwvZz48cGF0aCBzdHlsZT0ic3Ryb2tlOm5vbmU7ZmlsbC1ydWxlOmV2ZW5vZGQ7ZmlsbDojYTFiYmU1O2ZpbGwtb3BhY2l0eToxIiBkPSJNNDI2IDMwaDEwOHY0MEg0MjZaTTQyNiAzNnYtNmMtMy4zMTMgMC02IDIuNjg4LTYgNmg2Wk01MzQgMzZoNmMwLTMuMzEzLTIuNjg4LTYtNi02djZabTAgMCIvPjxwYXRoIHN0eWxlPSJzdHJva2U6bm9uZTtmaWxsLXJ1bGU6ZXZlbm9kZDtmaWxsOiNhMWJiZTU7ZmlsbC1vcGFjaXR5OjEiIGQ9Ik00MjAgMzZoMTIwdjI4SDQyMFpNNDI2IDY0aC02YzAgMy4zMTMgMi42ODggNiA2IDZ2LTZaTTUzNCA2NHY2YzMuMzEzIDAgNi0yLjY4OCA2LTZoLTZabTAgMCIvPjxwYXRoIHN0eWxlPSJmaWxsOm5vbmU7c3Ryb2tlLXdpZHRoOi4xO3N0cm9rZS1saW5lY2FwOmJ1dHQ7c3Ryb2tlLWxpbmVqb2luOm1pdGVyO3N0cm9rZTojMDAwO3N0cm9rZS1vcGFjaXR5OjE7c3Ryb2tlLW1pdGVybGltaXQ6MTAiIGQ9Ik0yMS4zIDEuNWg1LjRNMjEuMyAzLjVoNS40TTIxLjMgMS41YS4zLjMgMCAwIDAtLjMuM00yNyAxLjhhLjMuMyAwIDAgMC0uMy0uM00yMSAxLjh2MS40TTI3IDEuOHYxLjRNMjEgMy4yYS4zLjMgMCAwIDAgLjMuM00yNi43IDMuNWEuMy4zIDAgMCAwIC4zLS4zIiB0cmFuc2Zvcm09InNjYWxlKDIwKSIvPjxnIHN0eWxlPSJmaWxsOiMwMDA7ZmlsbC1vcGFjaXR5OjEiPjx1c2UgeGxpbms6aHJlZj0iI3MiIHg9IjQ0OS4wMjMiIHk9IjU1LjQ4OCIvPjx1c2UgeGxpbms6aHJlZj0iI2QiIHg9IjQ1Ni42OTkiIHk9IjU1LjQ4OCIvPjx1c2UgeGxpbms6aHJlZj0iI3QiIHg9IjQ2My42NTIiIHk9IjU1LjQ4OCIvPjx1c2UgeGxpbms6aHJlZj0iI2giIHg9IjQ3MS4yNSIgeT0iNTUuNDg4Ii8+PHVzZSB4bGluazpocmVmPSIjZSIgeD0iNDc4Ljc1IiB5PSI1NS40ODgiLz48dXNlIHhsaW5rOmhyZWY9IiNqIiB4PSI0ODQuNjY4IiB5PSI1NS40ODgiLz48dXNlIHhsaW5rOmhyZWY9IiNmIiB4PSI0ODcuODEzIiB5PSI1NS40ODgiLz48dXNlIHhsaW5rOmhyZWY9IiNoIiB4PSI0OTIuMTg4IiB5PSI1NS40ODgiLz48dXNlIHhsaW5rOmhyZWY9IiNjIiB4PSI0OTkuNjg4IiB5PSI1NS40ODgiLz48dXNlIHhsaW5rOmhyZWY9IiN1IiB4PSI1MDQuNzQ2IiB5PSI1NS40ODgiLz48L2c+PC9zdmc+" alt="index" width="90%">
</div>
<div class="title">Figure 1. Commands <code>add</code>, <code>reset</code> and <code>commit</code></div>
</div>
<div class="paragraph">
<p>In the initial state, i.e. when <code>git status</code> outputs the message <code>nothing to commit</code>, the working tree and index are synchronized with <code>HEAD</code>.
The index is therefore not “empty”, but contains the files in the same state as they are in the working tree.</p>
</div>
<div class="paragraph">
<p>Usually, the workflow is then as follows: First, you make a change to the working tree using an editor.
This change is transferred to the index by <code>add</code> and finally saved in the repository by <code>commit</code>.</p>
</div>
<div class="paragraph">
<p>You can display the differences between these three levels using the <code>diff</code> command.
A simple <code>git diff</code> shows the differences between the working tree and the index — the differences between the (actual) files on your working system and the files as they would be checked in if you called <code>git commit</code>.</p>
</div>
<div class="paragraph">
<p>The <code>git diff --staged</code> command, on the other hand, shows the differences between the index (also called the staging area) and the repository, that is, the differences that a commit would commit to the repository.
In the initial state, when the working tree and index are in sync with <code>HEAD</code>, neither <code>git diff</code> nor <code>git diff --staged</code> produces output.</p>
</div>
<div class="paragraph">
<p>If you want to apply all changes to all files, there are two shortcuts: First, the <code>-u</code> or <code>--update</code> option of <code>git add</code>.
This transfers all changes to the index, but does not yet create a commit.
You can further abbreviate it with the <code>-a</code> or <code>--all</code> option of <code>git commit</code>.
This is a combination of <code>git add -u</code> and <code>git commit</code>, which puts all changes to all files into one commit, bypassing the index.
Avoid getting into the habit of using these options — they may be handy as shortcuts on occasion, but they reduce flexibility.</p>
</div>
<div class="sect4">
<h5 id="sec.diff-color-words"><a class="anchor" href="Git-Book_3.html#sec.diff-color-words"></a>2.1.1.1. Word-Based Diff</h5>
<div class="paragraph">
<p>An alternative output format for <code>git diff</code> is the so-called <em>Word-Diff</em>, which is available via the <code>--word-diff</code> option.
Instead of the removed and added lines, the output of <code>git diff</code> shows the added (green) and removed (red) words with an appropriate syntax and color-coded.<sup class="footnote">[<a id="_footnoteref_12" class="footnote" href="#_footnotedef_12" title="View footnote.">12</a>]</sup>
This is useful when you are only changing single words in a file, for example when correcting AsciiDoc or LaTeX documents, because a diff is difficult to read if added and removed lines differ by only one word:</p>
</div>
<div class="listingblock">
<div class="content">
<pre>$ <strong>git diff</strong>
...
- die Option `--color-words` zur Verfgung steht. Statt der entfernten
+ die Option `--color-words` zur Verfügung steht. Statt der entfernten
...</pre>
</div>
</div>
<div class="paragraph">
<p>However, if you use the <code>--word-diff</code> option, only words that have been changed will be displayed marked accordingly; in addition, line breaks are ignored, which is also very practical because a reorientation of the words is not included as a change in the diff output:</p>
</div>
<div class="listingblock">
<div class="content">
<pre>$ <strong>git diff --word-diff</strong>
...
--color-words zur [-Verfgung-]{Verfügung} steht.
...</pre>
</div>
</div>
<div class="admonitionblock tip">
<table>
<tbody><tr>
<td class="icon">
<i class="fa icon-tip" title="Tip"></i>
</td>
<td class="content">
<div class="paragraph">
<p>If you work a lot with continuous text, it is a good idea to set up an alias to abbreviate this command, so that you only have to type <code>git dw</code>, for example:</p>
</div>
<div class="listingblock">
<div class="content">
<pre>$ <strong>git config --global alias.dw "diff --word-diff"</strong></pre>
</div>
</div>
</td>
</tr>
</tbody></table>
</div>
</div>
</div>
<div class="sect3">
<h4 id="sec.add-p"><a class="anchor" href="Git-Book_3.html#sec.add-p"></a>2.1.2. Creating Commits Step by Step</h4>
<div class="paragraph">
<p>But why create commits step-by-step — don’t you always want to check in all changes?</p>
</div>
<div class="paragraph">
<p>Yes, of course, you usually want to commit your changes completely.
However, it can be useful to check them in step by step, for example, to better reflect the development history.</p>
</div>
<div class="paragraph">
<p>An example: You have worked intensively on your software project for the past three hours, but because it was so exciting, you forgot to pack the four new features into handy commits.
In addition, the features are scattered over various files.</p>
</div>
<div class="paragraph">
<p>At best, you want to be selective, that is, you don’t want to commit all changes from one file, but only certain lines (functions, definitions, tests, …), and from different files.</p>
</div>
<div class="paragraph">
<p>Git’s index provides the flexibility you need for this.
You collect some changes in the index and pack them into a commit — but all other changes are still preserved in the files.</p>
</div>
<div class="paragraph">
<p>We’ll illustrate this using the “Hello World!” example from the previous chapter.
As a reminder, the contents of the <code>hello.pl</code> file</p>
</div>
<div class="listingblock">
<div class="content">
<pre class="rouge highlight"><code data-lang="perl"><span class="c1"># Hello World! in Perl</span>
<span class="k">print</span> <span class="p">"</span><span class="s2">Hello World!</span><span class="se">\n</span><span class="p">";</span></code></pre>
</div>
</div>
<div class="paragraph">
<p>Now we prepare the file so that it has several independent changes that we <em>don’t</em> want to combine into a single commit.
First, we add a shebang line at the beginning.<sup class="footnote">[<a id="_footnoteref_13" class="footnote" href="#_footnotedef_13" title="View footnote.">13</a>]</sup>
We also add a line naming the author, and the Perl statement <code>use strict</code>, which tells the Perl interpreter to be as strict as possible in its syntax analysis.
It is important for our example that the file has been changed in several places:</p>
</div>
<div class="listingblock">
<div class="content">
<pre class="rouge highlight"><code data-lang="perl"><span class="c1">#!/usr/bin/perl</span>
<span class="c1"># Hello World! in Perl</span>
<span class="c1"># Author: Valentin Haenel</span>
<span class="k">use</span> <span class="nv">strict</span><span class="p">;</span>
<span class="k">print</span> <span class="p">"</span><span class="s2">Hello World!</span><span class="se">\n</span><span class="p">";</span></code></pre>
</div>
</div>
<div class="paragraph">
<p>With a simple <code>git add hello.pl</code> all new lines would be added to the index — so the state of the file in the index would be the same as in the working tree.
Instead, we use the <code>--patch</code> option or short <code>-p</code>.<sup class="footnote">[<a id="_footnoteref_14" class="footnote" href="#_footnotedef_14" title="View footnote.">14</a>]</sup>
This has the effect that we are interactively asked which changes we want to add to the index.
Git offers us each change one by one, and we can decide on a case-by-case basis how we want to handle them:</p>
</div>
<div class="listingblock">
<div class="content">
<pre>$ <strong>git add -p</strong>
diff --git a/hello.pl b/hello.pl
index c6f28d5..908e967 100644
--- a/hello.pl
+++ b/hello.pl
@@ -1,2 +1,5 @@
+#!/usr/bin/perl
# Hello World! in Perl
+# Author: Valentin Haenel
+use strict;
print "Hello World!\n";
Stage this hunk [y,n,q,a,d,/,s,e,?]?</pre>
</div>
</div>
<div class="paragraph">
<p>This is where Git shows all changes, since they’re very close together in the code.
If the changes are far apart or spread across different files, they’re offered separately.
The term <em>hunk</em> refers to loosely connected lines in the source code.
Some of the options we have at this point include the following:</p>
</div>
<div class="listingblock">
<div class="content">
<pre>Stage this hunk[y,n,q,a,d,/,s,e,?]?</pre>
</div>
</div>
<div class="paragraph">
<p>The options are each only one letter long and difficult to remember.
A small reminder is always given by <em>[?]</em>.
We have summarized the most important options below.</p>
</div>
<div class="hdlist">
<table>
<tbody><tr>
<td class="hdlist1">
<code>y</code> (<em>yes</em>)
</td>
<td class="hdlist2">
<p>Transfer the current hunk to the index.</p>
</td>
</tr>
<tr>
<td class="hdlist1">
<code>n</code> (<em>no</em>)
</td>
<td class="hdlist2">
<p>Don’t pick up the current hunk.</p>
</td>
</tr>
<tr>
<td class="hdlist1">
<code>q</code> (<em>quit</em>)
</td>
<td class="hdlist2">
<p>Do not pick up the current hunk or any of the following ones.</p>
</td>
</tr>
<tr>
<td class="hdlist1">
<code>a</code> (<em>all</em>)
</td>
<td class="hdlist2">
<p>Pick up the current hunk and all those that follow (in the current file).</p>
</td>
</tr>
<tr>
<td class="hdlist1">
<code>s</code> (<em>split</em>)
</td>
<td class="hdlist2">
<p>Try to split the current hunk.</p>
</td>
</tr>
<tr>
<td class="hdlist1">
<code>e</code> (<em>edit</em>)
</td>
<td class="hdlist2">
<p>Edit the current hunk.<sup class="footnote">[<a id="_footnoteref_15" class="footnote" href="#_footnotedef_15" title="View footnote.">15</a>]</sup></p>
</td>
</tr>
</tbody></table>
</div>
<div class="paragraph">
<p>In the example we split the current hunk and enter <code>s</code> for <em>split</em>.</p>
</div>
<div class="listingblock">
<div class="content">
<pre>Stage this hunk [y,n,q,a,d,/,s,e,?]? <strong>[s]</strong>
Split into 2 hunks.
@@ -1 +1,2 @@
+#!/usr/bin/perl
# Hello World! in Perl</pre>
</div>
</div>
<div class="paragraph">
<p>Git confirms that the hunk was successfully split, and now offers us a diff that contains only the shebang line.<sup class="footnote">[<a id="_footnoteref_16" class="footnote" href="#_footnotedef_16" title="View footnote.">16</a>]</sup>
We specify <code>y</code> for <em>yes</em> and <code>q</code> for <em>quit</em> on the next hunk.
To check if everything worked, we use <code>git diff</code> with the <code>--staged</code> option, which shows the difference between index and <code>HEAD</code> (the latest commit):</p>
</div>
<div class="listingblock">
<div class="content">
<pre>$ <strong>git diff --staged</strong>
diff --git a/hello.pl b/hello.pl
index c6f28d5..d2cc6dc 100644
--- a/hello.pl
+++ b/hello.pl
@@ -1,2 +1,3 @@
+#!/usr/bin/perl
# Hello World! in Perl
print "Hello World!\n";</pre>
</div>
</div>
<div class="paragraph">
<p>To see which changes are <em>not</em> yet in the index, a simple call to <code>git diff</code> is enough to show us that — as expected — there are still two lines in the working tree:</p>
</div>
<div class="listingblock">
<div class="content">
<pre>$ <strong>git diff</strong>
diff --git a/hello.pl b/hello.pl
index d2cc6dc..908e967 100644
--- a/hello.pl
+++ b/hello.pl
@@ -1,3 +1,5 @@
#!/usr/bin/perl
# Hello World! in Perl
+# Author: Valentin Haenel
+use strict;
print "Hello World!\n";</pre>
</div>
</div>
<div class="paragraph">
<p>At this point we could create a commit, but for demonstration purposes we want to start from scratch.
So we use <code>git reset HEAD</code> to reset the index.</p>
</div>
<div class="listingblock">
<div class="content">
<pre>$ <strong>git reset HEAD</strong>
Unstaged changes after reset:
M hello.pl</pre>
</div>
</div>
<div class="paragraph">
<p>Git confirms and names the files that have changes in them; in this case, it’s just the one.</p>
</div>
<div class="paragraph">
<p>The <code>git reset</code> command is in a sense the counterpart of <code>git add</code>: Instead of transferring differences from the working tree to the index, <code>reset</code> transfers differences from the repository to the index.
Committing changes <em>to</em> the working tree is potentially destructive, as your changes may be lost.
Therefore, this is only possible with the <code>--hard</code> option, which we discuss in <a href="Git-Book_4.html#sec.reset">Sec. 3.2.3, “Reset and the Index”</a>.</p>
</div>
<div class="paragraph">
<p>If you frequently use <code>git add -p</code>, it is only a matter of time before you accidentally select a hunk you didn’t want.
If the index was empty, this is not a problem since you can reset it to start over.
It only becomes a problem if you have already recorded many changes in the index and don’t want to lose them, i.e. you remove a particular hunk from the index without wanting to touch the other hunks.</p>
</div>
<div class="paragraph">
<p>Analogous to <code>git add -p</code> there is the command <code>git reset -p</code>, which removes single hunks from the index.
To demonstrate this, let’s first apply all changes with <code>git add hello.pl</code> and then run <code>git reset -p</code>.</p>
</div>
<div class="listingblock">
<div class="content">
<pre>$ <strong>git reset -p</strong>
diff --git a/hello.pl b/hello.pl
index c6f28d5..908e967 100644
--- a/hello.pl
+++ b/hello.pl
@@ -1,2 +1,5 @@
+#!/usr/bin/perl
# Hello World! in Perl
+# Author: Valentin Haenel
+use strict;
print "Hello World!\n";
Unstage this hunk [y,n,q,a,d,/,s,e,?]?</pre>
</div>
</div>
<div class="paragraph">
<p>As in the example with <code>git add -p</code>, Git offers hunks one by one, but this time all the hunks in the index.
Accordingly, the question is: <code>Unstage this hunk [y,n,q,a,d,/,s,e,?]?</code>, i.e. whether we want to remove the hunk from the index again.
As before, by entering the question mark we get an extended description of the available options.
At this point we press <code>s</code> once for <em>split</em>, <code>n</code> once for <em>no</em> and <code>y</code> once for <em>yes</em>.
Now only the shebang line should be in the index:</p>
</div>
<div class="listingblock">
<div class="content">
<pre>$ <strong>git diff --staged</strong>
diff --git a/hello.pl b/hello.pl
index c6f28d5..d2cc6dc 100644
--- a/hello.pl
+++ b/hello.pl
@@ -1,2 +1,3 @@
+#!/usr/bin/perl
# Hello World! in Perl
print "Hello World!\n";</pre>
</div>
</div>
<div class="admonitionblock tip">
<table>
<tbody><tr>
<td class="icon">
<i class="fa icon-tip" title="Tip"></i>
</td>
<td class="content">
<div class="paragraph">
<p>In the interactive modes of <code>git add</code> and <code>git reset</code>, you must press the <kbd>Enter</kbd> key after entering an option.
The following configuration setting will save you this extra keystroke.</p>
</div>
<div class="listingblock">
<div class="content">
<pre>$ <strong>git config --global interactive.singlekey true</strong></pre>
</div>
</div>
</td>
</tr>
</tbody></table>
</div>
<div class="paragraph">
<p>A word of warning: A <code>git add -p</code> may tempt you to check in versions of a file that are not executable or syntactically correct (e.g. because you forgot an essential line).
So don’t rely on your commit being correct just because <code>make</code> — which works on working tree files! -- runs successfully.
Even if a later commit fixes the problem, it will still be a problem, among other things, with automated debugging via bisect (see <a href="Git-Book_5.html#sec.bisect">Sec. 4.8, “Finding Regressions — Git Bisect”</a>).</p>
</div>
</div>
<div class="sect3">
<h4 id="sec.commit"><a class="anchor" href="Git-Book_3.html#sec.commit"></a>2.1.3. Creating Commits</h4>
<div class="paragraph">
<p>You now know how to exchange changes between working tree, index, and repository.
Let’s turn to the <code>git commit</code> command, which you use to “commit” changes to the repository.</p>
</div>
<div class="paragraph">
<p>A commit keeps track of the state of all the files in your project at any given time, and also contains meta-information:<sup class="footnote">[<a id="_footnoteref_17" class="footnote" href="#_footnotedef_17" title="View footnote.">17</a>]</sup></p>
</div>
<div class="ulist">
<ul>
<li>
<p>Name of the authors and e-mail address</p>
</li>
<li>
<p>Name of the committer and e-mail address</p>
</li>
<li>
<p>Creation date</p>
</li>
<li>
<p>Commit date</p>
</li>
</ul>
</div>
<div class="paragraph">
<p>In fact, the name of the author <em>does not</em> have to be the name of the committer (who commits).
Often, commits are integrated or edited by maintainers (for example, by rebase, which also adjusts the committer information, see <a href="Git-Book_5.html#sec.rebase">Sec. 4.1, “Moving commits — Rebase”</a>).
The committer information is usually of secondary importance, though — most programs only show the author and the date the commit was made.</p>
</div>
<div class="paragraph">
<p>When you create a commit, Git uses the <code>user.name</code> and <code>user.email</code> settings configured in the previous section to identify the commit.</p>
</div>
<div class="paragraph">
<p>If you call <code>git commit</code> without any additional arguments, Git will combine all changes in the index into one commit, and open an editor to create a commit message.
However, the message will always contain instructions commented out with hash marks (<code>#</code>), or information about which files are changed by the commit.
If you call <code>git commit -v</code>, you will still get a diff of the changes you will check in, below the instructions.
This is especially useful for keeping track of the changes, and for using the auto-complete feature of your editor.</p>
</div>
<div class="paragraph">
<p>Once you exit the editor, Git creates the commit.
If you don’t specify a commit message or delete the entire contents of the file, Git will abort and not create a commit.</p>
</div>
<div class="paragraph">
<p>If you only want to write one line, you can use the <code>--message</code> option, or short <code>-m</code>, which allows you to specify the message directly on the command line, thus bypassing the editor:</p>
</div>
<div class="listingblock">
<div class="content">
<pre>$ <strong>git commit -m "Dies ist die Commit-Nachricht"</strong></pre>
</div>
</div>
<div class="sect4">
<h5 id="sec.ci-amend"><a class="anchor" href="Git-Book_3.html#sec.ci-amend"></a>2.1.3.1. Improving a Commit</h5>
<div class="paragraph">
<p>If you rashly entered <code>git commit</code>, but want to make the commit slightly better, the <code>--amend</code> (“correct”) option helps.
The option causes git to “add” the changes in the index to the commit you just made.<sup class="footnote">[<a id="_footnoteref_18" class="footnote" href="#_footnotedef_18" title="View footnote.">18</a>]</sup>
You can also customize the commit message.
Note that the SHA-1 sum of the commit will change in any case.</p>
</div>
<div class="paragraph">
<p>The <code>git commit --amend</code> call only changes the current commit on a branch.
<a href="Git-Book_5.html#sec.rebase-onto-ci-amend">Sec. 4.1.9, “Improving a Commit”</a> describes how to improve past commits.</p>
</div>
<div class="admonitionblock tip">
<table>
<tbody><tr>
<td class="icon">
<i class="fa icon-tip" title="Tip"></i>
</td>
<td class="content">
<div class="paragraph">
<p>Calling <code>git commit --amend</code> automatically starts an editor, so you can edit the commit message as well.
Often, however, you will only want to make a small correction to a file without adjusting the message.
For authors, an alias <code>fixup</code> is useful in this situation:</p>
</div>
<div class="listingblock">
<div class="content">
<pre>$ <strong>git config --global alias.fixup "commit --amend --no-edit"</strong></pre>
</div>
</div>
</td>
</tr>
</tbody></table>
</div>
</div>
<div class="sect4">
<h5 id="sec.commit-msg"><a class="anchor" href="Git-Book_3.html#sec.commit-msg"></a>2.1.3.2. Good Commit Messages</h5>
<div class="paragraph">
<p>What should a commit message look like?
Not much can be changed in the outer form: The commit message must be at least one line long, but preferably no longer than 50 characters.
This makes lists of commits easier to read.
If you want to add a more detailed description (which is highly recommended!), separate it from the first line with a blank line.
No line should be longer than 76 characters, as is usual for email.</p>
</div>
<div class="paragraph">
<p>Commit messages often follow the habits or specifics of a project.
There may be conventions, such as references to the bug tracking or issue system, or a link to the appropriate API documentation.</p>
</div>
<div class="paragraph">
<p>Note the following points when writing a commit description:</p>
</div>
<div class="ulist">
<ul>
<li>
<p>Never create empty commit messages.
Commit messages such as <code>Update</code>, <code>Fix</code>, <code>Improvement</code>, etc. are just as meaningful as an empty message — you might as well leave it at that.</p>
</li>
</ul>
</div>
<div class="ulist">
<ul>
<li>
<p>Very important: Describe <em>why</em> something was changed and what the implications are.
<em>What</em> has been changed is always obvious from the diff!</p>
</li>
</ul>
</div>
<div class="ulist">
<ul>
<li>
<p>Be critical and note if you think there is room for improvement or the commit may introduce bugs elsewhere.</p>
</li>
</ul>
</div>
<div class="ulist">
<ul>
<li>
<p>The first line should not be longer than 50 characters, so the output of the version history always remains well formatted and readable.</p>
</li>
</ul>
</div>
<div class="ulist">
<ul>
<li>
<p>If the message becomes longer, a short summary (with the important keywords) should be in the first line.
After a blank line follows an extensive description.</p>
</li>
</ul>
</div>
<div class="paragraph">
<p>We can’t stress enough how important a good commit description is.
When committing, a developer remembers the changes well, but after a few days, the motivation behind them is often forgotten.
Your colleagues or project members will thank you, too, because they can commit changes much faster.</p>
</div>
<div class="paragraph">
<p>Writing a good commit message also helps to briefly reflect on what has been done and what is still to come.
You may find that you’ve forgotten one important detail as you write it.</p>
</div>
<div class="paragraph">
<p>You can also argue about a timeline: The time it takes you to write a good commit message is a minute or two.
But how much less time will the bug-finding process take if each commit is well documented?
How much time will you save others (and yourself) if you provide a good description of a diff, which may be hard to understand?
Also, the blame tool, which annotates each line of a file with the commit that last changed it, will become an indispensable tool for detailed commit descriptions (see <a href="Git-Book_5.html#sec.blame">Sec. 4.3, “Who Made These Changes? — Git Blame”</a>).</p>
</div>
<div class="paragraph">
<p>If you are not used to writing detailed commit messages, start today.
Practice makes perfect, and once you get used to it, the work will go quickly — you and others will benefit.</p>
</div>
<div class="paragraph">
<p>The Git repository is a prime example of good commit messaging.
Without knowing the details of Git, you’ll quickly know who changed what and why.
You can also see how many hands a commit goes through before it’s integrated.</p>
</div>
<div class="paragraph">
<p>Unfortunately, the commit messages in most projects are still very spartan, so don’t be disappointed if your peers are lazy about writing, but rather set a good example and provide detailed descriptions.</p>
</div>
</div>
</div>
<div class="sect3">
<h4 id="sec.git-mv-rm"><a class="anchor" href="Git-Book_3.html#sec.git-mv-rm"></a>2.1.4. Moving and Deleting Files</h4>
<div class="paragraph">
<p>If you want to delete or move files managed by Git, use <code>git rm</code> or <code>git mv</code>.
They act like the regular Unix commands, but they also modify the index so that the action is included in the next commit.<sup class="footnote">[<a id="_footnoteref_19" class="footnote" href="#_footnotedef_19" title="View footnote.">19</a>]</sup></p>
</div>
<div class="paragraph">
<p>Like the standard Unix commands, <code>git rm</code> also accepts the <code>-r</code> and <code>-f</code> options to recursively delete or force deletion.
<code>git mv</code> also offers an option <code>-f</code> (<em>force</em>) if the new filename already exists and should be overwritten.
Both commands accept the option <code>-n</code> or <code>--dry-run</code>, which simulates the process and does not modify files.</p>
</div>
<div class="admonitionblock tip">
<table>
<tbody><tr>
<td class="icon">
<i class="fa icon-tip" title="Tip"></i>
</td>
<td class="content">
<div class="paragraph">
<p>To delete a file from the index only, use <code>git rm --cached</code>.
It then remains in the working tree.</p>
</div>
</td>
</tr>
</tbody></table>
</div>
<div class="paragraph">
<p>You will often forget to move a file via <code>git mv</code> or delete it via <code>git rm</code>, and use the standard Unix commands instead.
In this case, simply mark the file (already deleted by <code>rm</code>) as deleted in the index, too, using <code>git rm <file></code>.</p>
</div>
<div class="paragraph">
<p>To rename the file, proceed as follows: First mark the old file name as deleted using <code>git rm <old-name></code>.
Then add the new file: <code>git add <new-name></code>.
Then check via <code>git status</code> whether the file is marked as “renamed”.</p>
</div>
<div class="admonitionblock tip">
<table>
<tbody><tr>
<td class="icon">
<i class="fa icon-tip" title="Tip"></i>
</td>
<td class="content">
<div class="paragraph">
<p>Internally, it doesn’t matter to Git whether you move a file regularly via <code>mv</code>, then run <code>git add <new-name></code> and <code>git rm <old-name></code>.
In any case, only the reference to a blob object is changed (see<a href="Git-Book_3.html#sec.object-model">Sec. 2.2, “The Object Model”</a>).</p>
</div>
<div class="paragraph">
<p>However, Git comes with a so-called <em>Rename Detection</em>: If a blob is the same and is only referenced by a different file name, Git interprets this as a rename.
If you want to examine the history of a file and follow it if it is renamed, use the following command:</p>
</div>
<div class="listingblock">
<div class="content">
<pre>$ <strong>git log --follow -- <file></strong></pre>
</div>
</div>
</td>
</tr>
</tbody></table>
</div>
</div>
<div class="sect3">
<h4 id="sec.grep"><a class="anchor" href="Git-Book_3.html#sec.grep"></a>2.1.5. Using Grep on a Repository</h4>
<div class="paragraph">
<p>If you want to search for an expression in all files of your project, you can usually use <code>grep -R <expression> .</code>.</p>
</div>
<div class="paragraph">
<p>However, Git offers its own grep command, which you can call up using <code>git grep <expression></code>.
This command usually searches for the expression in all files managed by Git.
If you want to examine only some of the files instead, you can specify the pattern explicitly.
With the following command you can find all occurrences of <code>border-color</code> in all CSS files:</p>
</div>
<div class="listingblock">
<div class="content">
<pre>$ <strong>git grep border-color -- '*.css'</strong></pre>
</div>
</div>
<div class="paragraph">
<p>The grep implementation of Git supports all common flags that are also present in GNU Grep.
However, calling <code>git grep</code> is usually an order of magnitude faster, since Git has significant performance advantages due to the object database and the multithreaded design of the command.</p>
</div>
<div class="admonitionblock tip">
<table>
<tbody><tr>
<td class="icon">
<i class="fa icon-tip" title="Tip"></i>
</td>
<td class="content">
<div class="paragraph">
<p>The popular <code>grep</code> alternative <code>ack</code> is characterized mainly by the fact that it combines the lines of a file matching the search pattern under a corresponding “heading”, and uses striking colors.
You can emulate the output of <code>ack</code> with <code>git grep</code> by using the following alias:</p>
</div>
<div class="listingblock">
<div class="content">
<pre>$ <strong>git config alias.ack '!git -c color.grep.filename="green bold" \
-c color.grep.match="black yellow" -c color.grep.linenumber="yellow bold" \
grep -n --break --heading --color=always --untracked'</strong></pre>
</div>
</div>
</td>
</tr>
</tbody></table>
</div>
</div>
<div class="sect3">
<h4 id="sec.git-log"><a class="anchor" href="Git-Book_3.html#sec.git-log"></a>2.1.6. Examining the Project History</h4>
<div class="paragraph">
<p>Use <code>git log</code> to examine the project’s version history.
The options of this command (most of which also work for <code>git show</code>) are very extensive, and we will introduce the most important ones below.</p>
</div>
<div class="paragraph">
<p>Without any arguments, <code>git log</code> will output the author, date, commit ID, and the full commit message for each commit.
This is handy when you need a quick overview of who did what and when.
However, the list is a bit cumbersome when you’re looking at a lot of commits.</p>
</div>
<div class="paragraph">
<p>If you only want to look at recently created commits, limit <code>git log</code>’s output to <em>n</em> commits with the <code>-<n></code> option.
For example, the last four commits are shown with:</p>
</div>
<div class="listingblock">
<div class="content">
<pre>$ <strong>git log -4</strong></pre>
</div>
</div>
<div class="paragraph">
<p>To display a single commit, enter:</p>
</div>
<div class="listingblock">
<div class="content">
<pre>$ <strong>git log -1 <commit></strong></pre>
</div>
</div>
<div class="paragraph">
<p>The <code><commit></code> argument is a legal name for a single commit, such as the commit ID or SHA-1 sum.
However, if you do not specify anything, Git automatically uses <code>HEAD</code>.
Apart from single commits, the command also understands so-called <em>commit ranges</em> (series of commits), see <a href="Git-Book_3.html#sec.commit-ranges-intro">Sec. 2.1.7, “Commit-Ranges”</a>.</p>
</div>
<div class="paragraph">
<p>The <code>-p</code> (<code>--patch</code>) option appends the full patch in Unified-Diff format below the description.
Thus, a <code>git show <commit></code> from the output is equivalent to <code>git log -1 -p <commit></code>.</p>
</div>
<div class="paragraph">
<p>If you want to display the commits in compressed form, we recommend the <code>--oneline</code> option: It summarizes each commit with its abbreviated SHA-1 sum and the first line of the commit message.
It is therefore important that you include as much useful information as possible in this line!
For example, this would look like this:<sup class="footnote">[<a id="_footnoteref_20" class="footnote" href="#_footnotedef_20" title="View footnote.">20</a>]</sup></p>
</div>
<div class="listingblock">
<div class="content">
<pre>$ <strong>git log --oneline</strong>
<strong>25f3af3</strong> Correctly report corrupted objects
<strong>786dabe</strong> tests: compress the setup tests
<strong>91c031d</strong> tests: cosmetic improvements to the repo-setup test
<strong>b312b41</strong> exec_cmd: remove unused extern</pre>
</div>
</div>
<div class="paragraph">
<p>The <code>--oneline</code> option is only an alias for <code>--pretty=oneline</code>.
There are other ways to customize the output of <code>git log</code>.
The possible values for the <code>--pretty</code> option are:</p>
</div>
<div class="hdlist">
<table>
<tbody><tr>
<td class="hdlist1">
<code>oneline</code>
</td>
<td class="hdlist2">
<p>Commit-ID and first line of the description.</p>
</td>
</tr>
<tr>
<td class="hdlist1">
<code>short</code>
</td>
<td class="hdlist2">
<p>Commit ID, first line of the description and author of the commit; output is four lines.</p>
</td>
</tr>
<tr>
<td class="hdlist1">
<code>medium</code>
</td>
<td class="hdlist2">
<p>Default; output of commit ID, author, date and complete description.</p>
</td>
</tr>
<tr>
<td class="hdlist1">
<code>full</code>
</td>
<td class="hdlist2">
<p>Commit ID, author’s name, name of the committer and full description — <em>no</em> date.</p>
</td>
</tr>
<tr>
<td class="hdlist1">
<code>fuller</code>
</td>
<td class="hdlist2">
<p>Like <code>medium</code>, but additionally date and name of the committer.</p>
</td>
</tr>
<tr>
<td class="hdlist1">
<code>email</code>
</td>
<td class="hdlist2">
<p>Formats the information from <code>medium</code> so that it looks like an e-mail.</p>
</td>
</tr>
<tr>
<td class="hdlist1">
<code>format:<string></code>
</td>
<td class="hdlist2">
<p>Any format can be adapted by placeholders; for details see the man page <code>git-log(1)</code>, section “Pretty Formats”.</p>
</td>
</tr>
</tbody></table>
</div>
<div class="paragraph">
<p>Independently of this, you can display more information about the changes made by the commit below the commit message.
Consider the following examples, which clearly show which files were changed in how many places:</p>
</div>
<div class="listingblock">
<div class="content">
<pre>$ <strong>git log -1 --oneline 4868b2ea</strong>
4868b2e setup: officially support --work-tree without --git-dir
$ git log -1 --oneline <strong>--name-status</strong> 4868b2ea
4868b2e setup: officially support --work-tree without --git-dir
M setup.c
M t/t1510-repo-setup.sh
$ git log -1 --oneline <strong>--stat</strong> 4868b2ea
4868b2e setup: officially support --work-tree without --git-dir
setup.c | 19
t/t1510-repo-setup.sh | 210 +++++++++++++++++------------------
2 files changed, 134 insertions(), 95 deletions(-)
$ git log -1 --oneline <strong>--shortstat</strong> 4868b2ea
4868b2e setup: officially support --work-tree without --git-dir
2 files changed, 134 insertions(+), 95 deletions(-)</pre>
</div>
</div>
<div class="sect4">
<h5 id="sec.git-log-dates"><a class="anchor" href="Git-Book_3.html#sec.git-log-dates"></a>2.1.6.1. Time Constraints</h5>
<div class="paragraph">
<p>You can restrict the time of the commits to be displayed using the <code>--after</code> or <code>--since</code> and <code>--until</code> or <code>--before</code> options.
The options are all synonymous, so they give the same results.</p>
</div>
<div class="paragraph">
<p>You can specify absolute dates in any common format, or relative dates, here are some examples:</p>
</div>
<div class="listingblock">
<div class="content">
<pre>$ <strong>git log --after='Tue Feb 1st, 2011'</strong>
$ <strong>git log --since='2011-01-01'</strong>
$ <strong>git log --since='two weeks ago' --before='one week ago'</strong>
$ <strong>git log --since='yesterday'</strong></pre>
</div>
</div>
</div>
<div class="sect4">
<h5 id="sec.git-log-files"><a class="anchor" href="Git-Book_3.html#sec.git-log-files"></a>2.1.6.2. File-Level Restrictions</h5>
<div class="paragraph">
<p>If you specify one or more file or directory names after a <code>git log</code> call, Git will only display the commits that affect at least one of the specified files.
Provided a project is well structured, the output of commits can be severely limited and a particular change can be found quickly.</p>
</div>
<div class="paragraph">
<p>Since filenames may collide with branches or tags, you should be sure to specify the filenames after a <code>--</code> which means that only file arguments follow.</p>
</div>
<div class="listingblock">
<div class="content">
<pre>$ <strong>git log -- main.c</strong>
$ <strong>git log -- *.h</strong>
$ <strong>git log -- Documentation/</strong></pre>
</div>
</div>
<div class="paragraph">
<p>These calls only output the commits in which changes were made to the <code>main.c</code> file, an <code>.h</code> file, or a file under <code>Documentation/</code>.</p>
</div>
</div>
<div class="sect4">
<h5 id="sec.git-log-grep"><a class="anchor" href="Git-Book_3.html#sec.git-log-grep"></a>2.1.6.3. Grep for Commits</h5>
<div class="paragraph">
<p>You can also search for commits in the style of <code>grep</code>, where the <code>--author</code>, <code>--committer</code>, and <code>--grep</code> options are available.</p>
</div>
<div class="paragraph">
<p>The first two options filter commits by author or committer name or address, as expected.
For example, list all commits that Linus Torvalds has made since early 2010:</p>
</div>
<div class="listingblock">
<div class="content">
<pre>$ <strong>git log --since='2010-01-01' --author='Linus Torvalds'</strong></pre>
</div>
</div>
<div class="paragraph">
<p>You can also enter only part of the name or e-mail address here, so searching for 'Linus' would produce the same result.</p>
</div>
<div class="paragraph">
<p>For example, you can use <code>--grep</code> to search for keywords or phrases in the commit message, such as all commits that contain the word “fix” (not case-sensitive):</p>
</div>
<div class="listingblock">
<div class="content">
<pre>$ <strong>git log -i --grep=fix</strong></pre>
</div>
</div>