forked from kdheepak/think-git
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathindex.html
812 lines (773 loc) · 57.6 KB
/
index.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
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<link rel="stylesheet" href="reveal.js/css/reveal.css">
<link rel="stylesheet" href="reveal.js/css/theme/simple.css" id="theme">
<link rel="stylesheet" href="css/custom.css">
<!-- d3.js -->
<script src='http://d3js.org/d3.v3.min.js'></script>
<!-- gitgraph.js -->
<script src="js/gitgraph.js"></script>
<title>Think Git</title>
</head>
<body>
<div class="reveal">
<div class="slides">
<section data-state="title-event" data-transition="slide">
<h1 class="title">think git</h1>
<div id="divchart">
<svg id="title-chart"></svg>
</div>
<aside class="notes">
This talk is about the software git
</aside>
</section>
<section data-transition="slide">
<section id="what-is-git" class="titleslide slide level1" data-transition="slide"><h1>What is git?</h1>
<aside class="notes">
Most you have have probably heard of git, but if you haven't -
git is a version control tool.
It's just a fancy way of saying you track what changes you are making to a file.
You've probably used a version control tool, or maybe even invented one that works for you.
</aside>
</section>
<section id="section" class="slide level2">
<p class="center">
<br>
<img src="http://www.phdcomics.com/comics/archive/phd101212s.gif" style="max-height: 15em">
<br>
<a href="http://www.phdcomics.com/comics/archive/phd101212s.gif" data-preview-link>Link</a>
</p>
<aside class="notes">
If you've ever worked on a paper using Word, you've probably created a verison control system that works for you by saving a file with different "version" tags.
The reason someone might do this is because they like having a backup of all their past changes. If someone wants to delete a paragraph, you keep a copy of the old version just in case
And when you are collaborating with someone, this becomes more challenging. Tracking changes and merging content added by different people is time consuming.
As you can imagine, this presents a problem in software development.
It is likely that multiple people will work on the same file sometimes even at the same time.
Even small software projects can have tens of files in multiple folders.
Additionally, developers frequently experiment with features and this should never affect the "master" copy of the project
</aside>
</section>
<section id="section" class="slide level2">
<p class="center">
<br>
<img src="http://imgs.xkcd.com/comics/git.png" style="max-height: 15em">
<br>
<a href="http://imgs.xkcd.com/comics/git.png" data-preview-link>Link</a>
</p>
<aside class="notes">
git to the rescue! Essentially what git can be is this, it can be a history of all changes you have made to every file in the project.
But, unfortunately you have to understand how it works to use it effectively.
Most people when introduced to git, are thrown into using it, and usually don't understand how it works. When something you have never encountered before occurs, you might not know what to do.
I know I've deleted projects and downloaded a fresh copy of a repo because I accidentally created a conflict of some sort.
With this talk, I'd like to introduce what I'm calling the big ideas of git that will help you understand how git works.
</aside>
</section>
<section>
<h3>git is a supplement to your workflow</h3>
<aside class="notes">The first thing to understand is that git is a supplement to your current workflow. You can work the way you usually work, and all you have to do is use git every time you want to save your progress</aside>
</section>
<section>
<h3>Workflow</h3>
<div style="text-align: center; width: 100%; display: inline-block"><code></code></div>
<div style="text-align: center; width: 100%; display: inline-block"></div>
<div style="text-align: center; width: 100%; display: inline-block"><code></code></div>
<div style="text-align: left; width: 45%; display: inline-block">Edit files</div>
<div style="text-align: center; width: 45%; display: inline-block" class="fragment" data-fragment-index="2"><code style="background-color: red; color: white; padding: .25em">$EDITOR</code></div>
<div style="text-align: center; width: 100%; display: inline-block"></div>
<div style="text-align: left; width: 45%; display: inline-block" ></div>
<div style="text-align: center; width: 45%; display: inline-block"></div>
<div style="text-align: center; width: 100%; display: inline-block"></div>
<div style="text-align: left; width: 45%; display: inline-block" ></div>
<div style="text-align: center; width: 45%; display: inline-block">
</div>
<div style="text-align: center; width: 100%; display: inline-block"></div>
<div style="text-align: left; width: 45%; display: inline-block">Save changes</div>
<div style="text-align: center; width: 45%; display: inline-block" class="fragment" data-fragment-index="5"><code style="background-color: black; color: white; border-radius: 5em; padding: .25em" >git commit</code></div>
<aside class="notes">
Before we talk about git, let's talk about workflow.
This is a simple example of a workflow. You edit a file and you save the file. SPC.
Once you reach what you consider a stable state, you can save the file as a different name as backup, or save it on dropbox or however you usually implement a version control system
When you use git however, you don't have to save a different version of the file.
When you are ready to save the current version of the file as a backup, you do that in git by taking a snapshot of the current state.
You can take a "snapshot" of the current state of a file by using a command called git commit.
What really happens is that when you can create a "snapshot", it records the current state of all the files in the directory being tracked.
</section>
<section data-state="demo1-event" data-transition="none">
<h3><code>git commit</code></h3>
<div class="fragment demo1-start" style="margin: 50px 0px;">
</div>
<div class="fragment demo1-git-commit-1" style="margin: 50px 0px;">
</div>
<div class="fragment demo1-git-commit-2" style="margin: 50px 0px;">
</div>
<div >
<svg id="demo1-chart"></svg>
</div>
<aside class="notes">
So what does a snapshot look like?
Let's assume that a snapshot looks like this circle over here.
As I mentioned earlier, a snapshot contains the current state of the file or directory.
When git creates a snapshot, it also creates a number and attaches that number to it.
git uses an algorithm to calculate this number and
this number is unique, it is very unlikely that two such numbers will be the same
Every snapshot / commit you create will have its own number attached to it. And this number is called a HASH. You can typically you can use the first 6 or 7 characters to uniquely identify a snapshot in your project.
Let's say you have created this first commit, and now you make more changes to the file. and want to save them.
When you make changes to your files, and save them using git commit, git creates a new snapshot with a new HASH.
git also does a few other things.
1) It allows you to create a message that goes along with that commit. A commit has to have a message!
2) When a new commit is created, it saves a reference to the parent commit. A snapshot can have multiple parents - i.e. you can take changes from two commits and merge them into one. The current commit HASH number depends on the path, i.e. it depends on what the parent is. If you change the parent hash i.e. change the content in the parent, every commit hash after that will be different.
3) Whatever commit represents the current project state, git stores a reference to that current commit in the label HEAD
In the word document VCS, we created multiple versions but we did not track how we got to each state. git allows us to do that by storing all this information
You may be wondering, where does git store all this - we will get to that.
This, as you can imagine, forms a graph.
</aside>
</section>
<section data-state="network" class="slide level2">
<h3>What's your story</h3>
<div class="fragment demo0-start" style="margin: 50px 0px;">
</div>
<div class="fragment demo0-git-story-1" style="margin: 50px 0px;">
</div>
<div class="fragment demo0-git-story-2" style="margin: 50px 0px;">
</div>
<div class="fragment demo0-git-story-3" style="margin: 50px 0px;">
</div>
<div class="fragment demo0-git-delete-merge" style="margin: 50px 0px;">
</div>
<div >
<svg id="demo0-chart"></svg>
</div>
<aside class="notes">
and like with any graph, you can choose to tell a story.
In this case, we want to work on a feature of a software, and while working on it we get a new idea.
You can go back to a previous state of the project, and branch off to work on a new idea - not affecting your current work.
And, when you are ready, you can pull these changes back to your master branch
You can go back and review individual changes made in any commit.
You can even undo changes, apply these changes to different state of your project.
You could also discard a branch entirely, or switch between branches.
Branches are awesome, and we'll talk more able branches a little later.
The point here is that this graph exists.
This graph is the documentation of how your project came to be, i.e. the history of your project is a graph that you can traverse at will.
</aside>
</section>
<section>
<h1>Big idea #1</h1>
git history is a graph
<aside class="notes">
So that's big idea number 1, git history is a graph that you can traverse, allowing you to move to any "saved" state in a project
</aside>
</section>
</section>
<section data-transition="slide">
<section id="so-really-what-is-git" class="titleslide slide level1" data-transition="slide">
<h1>git functions</h1>
</section>
<section>
<code>
<pre style="top: 25%; font-size: .2em; width: 100%">
git help --all
usage: git [--version] [--help] [-C <path>] [-c name=value]
[--exec-path[=<path>]] [--html-path] [--man-path] [--info-path]
[-p|--paginate|--no-pager] [--no-replace-objects] [--bare]
[--git-dir=<path>] [--work-tree=<path>] [--namespace=<name>]
<command> [<args>]
available git commands in '/Applications/Xcode.app/Contents/Developer/usr/libexec/git-core'
add clone fast-import interpret-trailers notes remote-testsvn submodule
add--interactive column fetch log p4 repack subtree
am commit fetch-pack ls-files pack-objects replace svn
annotate commit-tree filter-branch ls-remote pack-redundant request-pull symbolic-ref
apply config fmt-merge-msg ls-tree pack-refs rerere tag
archimport count-objects for-each-ref mailinfo patch-id reset unpack-file
archive credential format-patch mailsplit prune rev-list unpack-objects
bisect credential-cache fsck merge prune-packed rev-parse update-index
bisect--helper credential-cache--daemon fsck-objects merge-base pull revert update-ref
blame credential-osxkeychain gc merge-file push rm update-server-info
branch credential-store get-tar-commit-id merge-index quiltimport send-email upload-archive
bundle cvsexportcommit grep merge-octopus read-tree send-pack upload-pack
cat-file cvsimport gui--askpass merge-one-file rebase sh-i18n--envsubst var
check-attr cvsserver hash-object merge-ours receive-pack shell verify-commit
check-ignore daemon help merge-recursive reflog shortlog verify-pack
check-mailmap describe http-backend merge-resolve relink show verify-tag
check-ref-format diff http-fetch merge-subtree remote show-branch web--browse
checkout diff-files http-push merge-tree remote-ext show-index whatchanged
checkout-index diff-index imap-send mergetool remote-fd show-ref write-tree
cherry diff-tree index-pack mktag remote-ftp stage
cherry-pick difftool init mktree remote-ftps stash
citool difftool--helper init-db mv remote-http status
clean fast-export instaweb name-rev remote-https stripspace
git commands available from elsewhere on your $PATH
loglive
'git help -a' and 'git help -g' list available subcommands and some
concept guides. See 'git help <command>' or 'git help <concept>'
to read about a specific subcommand or concept.
</pre>
</code>
<aside class="notes">
So we know that git history is a graph, right? And
This graph that we created has to be stored somewhere, right?
This graph is stored in a .git folder
Every folder on your computer that has a .git folder is git repository.
There is only one such .git folder in a git repo.
all git commit does, is add content to that .git folder.
and git commit is only just one function that git provides
what if you wanted to do more, like manipulate an existing snapshot, delete a set of changes, reorder your history.
git offers you other tools to do that.
git is essentially a toolkit that contains a bunch of functions that help organize snapshots of content.
This is a list of all the functions available to you.
Note - git is not github. what is github? github stores git repository in the internet and that's basically all it does
So, as I was saying this is the list of functions
</aside>
</section>
<section>
<code>
<pre style="top: -25%; font-size: .2em; width: 100%">
git help --all
usage: git [--version] [--help] [-C <path>] [-c name=value]
[--exec-path[=<path>]] [--html-path] [--man-path] [--info-path]
[-p|--paginate|--no-pager] [--no-replace-objects] [--bare]
[--git-dir=<path>] [--work-tree=<path>] [--namespace=<name>]
<command> [<args>]
available git commands in '/Applications/Xcode.app/Contents/Developer/usr/libexec/git-core'
add clone submodule
add--interactive fetch log
am commit
annotate
apply tag
reset
archive format-patch
bisect merge
bisect--helper pull revert
blame gc push rm
branch
grep
gui--askpass rebase
daemon help reflog
diff remote
checkout
cherry-pick init stash
mv status
clean instaweb
git commands available from elsewhere on your $PATH
loglive
'git help -a' and 'git help -g' list available subcommands and some
concept guides. See 'git help <command>' or 'git help <concept>'
to read about a specific subcommand or concept.
</pre>
</code>
<aside class="notes">
But you don't have to use every one of the functions available. I've only every had to use a handful.
because Git was initially a toolkit for a VCS rather than a full user-friendly VCS, it has a bunch of verbs that do low-level work and were designed to be chained together UNIX style or called from scripts. These commands are generally referred to as “plumbing” commands, and the more user-friendly commands are called “porcelain” commands.
https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Porcelain
</aside>
</section>
<section>
<h3>Workflow</h3>
<div style="text-align: center; width: 100%; display: inline-block" class="fragment" data-fragment-index="1"><code></code></div>
<div style="text-align: center; width: 100%; display: inline-block" class="fragment" data-fragment-index="1"><code style="background-color: rgba(0, 0, 0, .25); color: white; border-radius: 5em; padding: .25em" >git init</code></div>
<div style="text-align: center; width: 100%; display: inline-block" class="fragment" data-fragment-index="1"><code></code></div>
<div style="text-align: left; width: 45%; display: inline-block">Edit files</div>
<div style="text-align: center; width: 45%; display: inline-block" class="fragment" data-fragment-index="2"><code style="background-color: red; color: white; padding: .25em">$EDITOR</code></div>
<div style="text-align: center; width: 100%; display: inline-block"></div>
<div style="text-align: left; width: 45%; display: inline-block" class="fragment" data-fragment-index="0">Group changes</div>
<div style="text-align: center; width: 45%; display: inline-block" class="fragment" data-fragment-index="3"><code style="background-color: black; color: white; border-radius: 5em; padding: .25em" >git add</code></div>
<div style="text-align: center; width: 100%; display: inline-block"></div>
<div style="text-align: left; width: 45%; display: inline-block" class="fragment" data-fragment-index="0">Review changes</div>
<div style="text-align: center; width: 45%; display: inline-block">
<code class="fragment" data-fragment-index="4" style="background-color: black; color: white; border-radius: 5em; padding: .25em" >git status</code>
</div>
<div style="text-align: center; width: 100%; display: inline-block"></div>
<div style="text-align: left; width: 45%; display: inline-block">Save changes</div>
<div style="text-align: center; width: 45%; display: inline-block" class="fragment" data-fragment-index="5"><code style="background-color: black; color: white; border-radius: 5em; padding: .25em" >git commit</code></div>
<aside class="notes">Let's talk about our workflow again. To actually use git we need to add a couple of steps to the workflow we talked about earlier. We group changes before committing them.
And we do this using the git add command.
if we open a folder and try to "git add" a file, git will throw us an error. it doesn't know where to add the file to. We need to create a .git folder first and we do that using git init. You only need to do this once for a project, at the every beginning. If a project is already using git, then that .git folder exists and you can run any git command.
the git add command, adds the content you specify to a "staging area"
You can add multiple files at the same time to the staging area
And then, when you call the git commit function, git takes everything that is in the staging area and pushes it into a new snapshot
Think of the content in the staging area as the changes you would like your next snapshot to represent
SPC
Before you commit these changes to a new snapshot, you might want to review your changes.
SPC
git status is used to review your changes,
SPC
And to actually save this snapshot you can use git commit
</aside>
</section>
<section>
<p class="center">
<img src="img/local.png" style="max-height: 15em;" alt="git operations">
<br>
<a href="https://github.com/schacon/git-presentations" data-preview-link>Link</a>
</p>
<aside class="notes">
Here is another way to look at this
The most important takeaway here is that you use git add to create what you want your next snapshot to look like.
The working directory is the files in your folder.
You make changes to your working directory and git add them to the staging area.
you can add multiple files
Next, you commit the staged files into a git repository
git commit updates the .git folder and thereby updating the graph
</aside>
</section>
<section data-background-video="https://github.com/kdheepak89/think-git/blob/gh-pages/img/git-tree.mov?raw=true" data-background-color="#000000">
<div class="fragment hide-on-current-fragment" style="background-color: rgba(0, 0, 0, 0.75); color: #fff; padding: 20px;">
<h3 style="color: white;">demo</h3>
</div>
<aside class="notes">
.git folder is the database of key value pairs that track your project history. You can start a git repository by typing `git init`. When you add a file, git runs a SHA1 hash on the file which returns a hash. This hash is stored in a tree object and a commit object. If you create a file on your machine called `readme` and write `# farm` in it, and `git add` it to an empty repo, you should get the following folder in your .git repo
├── b8
│ └── fa28116ec360ae79b59da237ca991ab31a696e
Computes the hash of the file.
Stores the contents of the README file using the hash of the file to name the file.
Adds a reference to the README file to the git index
because git only cares about content. git uses content as a heuristic to find if a file has been renamed. if too much of the content has been changed between two commits when a rename occured, git will think it is a different file. and you can manually set this heuristic, I believe the default is 50%.
When you git commit the staged file, git creates a blob and a tree.
git does calculate a diff though, only when it needs to push. Again, this can be set manually. You can say - take longer than you usually do, but make me the smallest patch you can.
</aside>
</section>
<section class="slide level2">
<p class="center">
<img src="img/commit-1.svg" style="max-height: 15em;" alt="commit structure">
<br>
<a href="https://github.com/schacon/git-presentations" data-preview-link>Link</a>
</p>
<aside class="notes">
This is the structure of a single commit/snapshot. snapshot (unofficial)==commit(git internal object).
Tree is like a directory and can link to other trees or blobs. blobs are like files.
</aside>
</section>
<section class="slide level2">
<p class="center">
<img src="img/commit-2.svg" style="max-height: 15em;" alt="commit structure">
<br>
<a href="https://git-scm.com/blog/2011/07/11/reset.html" data-preview-link>Link</a>
</p>
<aside class="notes">
If the bottom file was modified, and committed to the repository in a new snapshot, git will still use the same blobs for unmodified files
There are other things going on here, like the tag which is just a label. Every branch name is just a label too and we'll touch on that later. Now for a quick demo
</aside>
</section>
<section data-background-video="https://github.com/kdheepak89/think-git/blob/gh-pages/img/git-demo.mov?raw=true" data-background-color="#000000">
<div class="fragment hide-on-current-fragment" style="background-color: rgba(0, 0, 0, 0.75); color: #fff; padding: 20px;">
<h3 style="color: white;">demo</h3>
</div>
</section>
<section>
<h1>Big idea #2</h1>
Difference between Head, Index and Working directory
<br>
<a href="https://git-scm.com/blog/2011/07/11/reset.html" data-preview-link>Link</a>
</section>
</section>
<section data-transition="slide">
<section><h1>Branches</h1></section>
<section data-state="demo2-event" data-transition="none">
<h3><code>git branch master</code></h3>
<div class="fragment demo2-start" style="margin: 50px 0px;">
</div>
<div class="fragment demo2-git-branch" style="margin: 50px 0px;">
</div>
<div class="fragment demo2-git-commit" style="margin: 50px 0px;">
</div>
<div >
<svg id="demo2-chart"></svg>
</div>
<aside class="notes">
Let's talk about branches. Branches are just labels. The default branch is master. HEAD represents your current commit. When you add a snapshot succesfully, git will change the reference of the branch to the new HEAD, which is the new or current commit
</aside>
</section>
<section data-state="demo3-event" data-transition="none">
<h3><code>git checkout -b feature</code></h3>
<div class="fragment demo3-start" style="margin: 50px 0px;">
</div>
<div class="fragment demo3-git-checkout-b" style="margin: 50px 0px;">
</div>
<div class="fragment demo3-git-commit-0" style="margin: 50px 0px;">
</div>
<div>
<svg id="demo3-chart"></svg>
</div>
</section>
<section data-state="demo6-event" data-transition="none">
<h3><code>git checkout master</code></h3>
<div class="fragment demo6-start" style="margin: 50px 0px;">
</div>
<div class="fragment demo6-git-checkout-feature" style="margin: 50px 0px;">
</div>
<div >
<svg id="demo6-chart"></svg>
</div>
</section>
<section data-state="demo4-event" data-transition="none">
<h3><code>git merge master</code></h3>
<div class="fragment demo4-start" style="margin: 50px 0px;">
</div>
<div class="fragment demo4-git-fetch" style="margin: 50px 0px;">
</div>
<div class="fragment demo4-git-merge-feature" style="margin: 50px 0px;">
</div>
<div class="fragment demo4-git-checkout-feature" style="margin: 50px 0px;">
</div>
<div class="fragment demo4-git-merge-master" style="margin: 50px 0px;">
</div>
<div >
<svg id="demo4-chart"></svg>
</div>
</section>
<section>
<h1>Big idea #3</h1>
branches are just labels
</section>
</section>
<section data-transition="slide">
<section data-transition="slide">
<h1>Merge Conflict</h1>
</section>
<section data-background-video="https://github.com/kdheepak89/think-git/blob/gh-pages/img/git-mergetool.mov?raw=true" data-background-color="#000000">
<div class="fragment hide-on-current-fragment" style="background-color: rgba(0, 0, 0, 0.75); color: #fff; padding: 20px;">
<h3 style="color: white;">demo</h3>
</div>
<aside class="notes">
demo showing git mergetool
</aside>
</section>
<section>
<h3>Best Mergetools</h3>
<br>
<a href="http://stackoverflow.com/questions/572237/whats-the-best-three-way-merge-tool" data-preview-link>Link</a>
<aside class="notes">
There are mergetools out there other than vim, kdiff3 is open source and free on all platforms. p4merge is great.
</aside>
</section>
</section>
<section data-transition="slide">
<section data-transition="slide">
<h1>Changing history</h1>
</section>
<section data-state="demo5-event" data-transition="none">
<h3><code>git rebase master</code></h3>
<div class="fragment demo5-start" style="margin: 50px 0px;">
</div>
<div class="fragment demo5-git-fetch" style="margin: 50px 0px;">
</div>
<div class="fragment demo5-git-rebase-1" style="margin: 50px 0px;">
</div>
<div class="fragment demo5-git-rebase-2" style="margin: 50px 0px;">
</div>
<div >
<svg id="demo5-chart"></svg>
</div>
</section>
<section data-background-video="https://github.com/kdheepak89/think-git/blob/gh-pages/img/git-rebase.mov?raw=true" data-background-color="#000000">
<div class="fragment hide-on-current-fragment" style="background-color: rgba(0, 0, 0, 0.75); color: #fff; padding: 20px;">
<h3 style="color: white;">demo</h3>
</div>
<aside class="notes">
demo showing git rebase
</aside>
</section>
<section data-background-video="https://github.com/kdheepak89/think-git/blob/gh-pages/img/git-rebase-interactive.mov?raw=true" data-background-color="#000000">
<div class="fragment hide-on-current-fragment" style="background-color: rgba(0, 0, 0, 0.75); color: #fff; padding: 20px;">
<h3 style="color: white;">demo</h3>
</div>
<aside class="notes">
demo showing git rebase interactive
</aside>
</section>
<section>
<h1>Big idea #4</h1>
Local commits are yours to do with what you like
</section>
</section>
<section data-transition="slide">
<section><h1>Remote</h1></section>
<section>
<p class="center">
<img src="img/local-remote.svg" style="max-height: 15em;" alt="git operations">
<br>
<a href="https://github.com/schacon/git-presentations" data-preview-link>Link</a>
</p>
<aside class="notes">Everything we've seen so far has been local. </aside>
</section>
<section data-state="demo5-event" data-transition="none">
<h3><code>git pull = git fetch + git merge</code></h3>
</section>
<section data-background-video="" data-background-color="#000000">
<div class="fragment hide-on-current-fragment" style="background-color: rgba(0, 0, 0, 0.75); color: #fff; padding: 20px;">
<h3 style="color: white;">demo</h3>
</div>
<aside class="notes">
demo showing git fetch
</aside>
</section>
<section>
<h1>Big idea #5</h1>
Remote is special branch, but a branch nonetheless
</section>
</section>
<section data-transition="slide">
<section data-transition="slide">
<h1>Review of big ideas</h1>
</section>
<section id="commit-related-changes" class="slide level2">
<h3>git history is a graph</h3>
</section>
<section id="commit-often" class="slide level2">
<h3>Difference between working directory, staging area and .git repository</h3>
</section>
<section id="branches-are-inexpensive" class="slide level2">
<h3>Branches are just labels</h3>
</section>
<section id="commit-only-if-tests-pass" class="slide level2">
<h3>Remote is a branch too</h3>
</section>
<section id="write-good-commit-messages" class="slide level2">
<h3>Local history is whatever you make it</h3>
</section>
</section>
<section data-transition="slide">
<section data-transition="slide">
<h1>Best practices</h1>
</section>
<section id="commit-related-changes" class="slide level2">
<h3>Commit related changes</h3>
</section>
<section id="commit-often" class="slide level2">
<h3>Commit often</h3>
</section>
<section id="branches-are-inexpensive" class="slide level2">
<h3>Branches are inexpensive</h3>
</section>
<section id="commit-only-if-tests-pass" class="slide level2">
<h3>Push to master only if tests pass</h3>
</section>
<section id="write-good-commit-messages" class="slide level2">
<h3>Write good commit messages!</h3>
</section>
<section id="discuss-workflow-with-team" class="slide level2">
<h3>Discuss workflow with team</h3>
</section>
<section>
<h3>Less of this and more of this</h3>
<p class="center" style="position: absolute">
<img src="img/git-history.png" alt="git-history">
</p>
</section>
</section>
<section>
<h3>Source code for this presentation</h3>
<p class="center">
<a href="https://github.com/kdheepak89/think-git"><img class="no-shadow" style="border-radius: 50px; max-height: 2em; margin-top: 5em;" src="https://assets-cdn.github.com/images/modules/logos_page/GitHub-Mark.png" alt="git-repo"></a>
</p>
</section>
<section>
<h3>Additional slides</h3>
</section>
<section>
<section class="titleslide slide level1" data-transition="slide"><h1>Advantages of git</h1></section>
<section id="section" class="slide level2">
<h1></h1>
<ul>
<li>Free </li>
<li>Fast </li>
<li>Secure </li>
<li>Supports multiple non linear workflows</li>
<li class="fragment current-visible"><b>Easy to learn</b></li>
</ul>
<aside class="notes">
git is free, fast, secure and support different workflows.
Hit SPC
And most importantly it is easy to learn
</aside>
</section>
<section class="slide level2" >
<h3>Free as in [beer, speech]</h3>
<p class="center">
<br>
<img src="img/git-scm.png" style="max-height: 10em;" alt="git-scm">
<br>
<a href="https://git-scm.com/" data-preview-link>Link</a>
</p>
<aside class="notes">
Free to download for Windows, OSX, Linux. Free to modify under the GNU General Public License version 2.
</aside>
</section>
<section>
<h3>Small</h3>
The Mozilla project's CVS repository is about 3 GB; it's about 12 GB in Subversion's fsfs format. In Git it's around 300 MB.
<aside class="notes">
git repositories are usually smaller than CVS repository for the same source code and history. git is efficient at storing content and changes in content.
</aside>
</section>
<section class="slide level2" >
<h3>Fast</h3>
<table width="100%">
<tbody>
<tr>
<td>
<img src="https://chart.googleapis.com/chart?chxt=x&cht=bvs&chl=git|svn&chd=t:0.649,2.6&chds=0,2.6&chs=100x125&chco=E09FA0|E05F49&chf=bg,s,fcfcfa&chtt=Commit A" alt="init benchmarks">
</td>
<td>
<img src="https://chart.googleapis.com/chart?chxt=x&cht=bvs&chl=git|svn&chd=t:1.53,24.7&chds=0,24.7&chs=100x125&chco=E09FA0|E05F49&chf=bg,s,fcfcfa&chtt=Commit B" alt="init benchmarks">
</td>
<td>
<img src="https://chart.googleapis.com/chart?chxt=x&cht=bvs&chl=git|svn&chd=t:0.257,1.09&chds=0,1.09&chs=100x125&chco=E09FA0|E05F49&chf=bg,s,fcfcfa&chtt=Diff Curr" alt="init benchmarks">
</td>
<td>
<img src="https://chart.googleapis.com/chart?chxt=x&cht=bvs&chl=git|svn&chd=t:0.248,3.99&chds=0,3.99&chs=100x125&chco=E09FA0|E05F49&chf=bg,s,fcfcfa&chtt=Diff Rec" alt="init benchmarks">
</td>
<td>
<img src="https://chart.googleapis.com/chart?chxt=x&cht=bvs&chl=git|svn&chd=t:1.17,83.57&chds=0,83.57&chs=100x125&chco=E09FA0|E05F49&chf=bg,s,fcfcfa&chtt=Diff Tags" alt="init benchmarks">
</td>
<td>
<img src="https://chart.googleapis.com/chart?chxt=x&cht=bvs&chl=git*|git|svn&chd=t:21.0,107.5,14.0&chds=0,107.5&chs=100x125&chco=E09FA0|E09FA0|E05F49&chf=bg,s,fcfcfa&chtt=Clone" alt="init benchmarks">
</td>
</tr>
<tr>
<td>
<img src="https://chart.googleapis.com/chart?chxt=x&cht=bvs&chl=git|svn&chd=t:0.012,0.381&chds=0,0.381&chs=100x125&chco=E09FA0|E05F49&chf=bg,s,fcfcfa&chtt=Log (50)" alt="init benchmarks">
</td>
<td>
<img src="https://chart.googleapis.com/chart?chxt=x&cht=bvs&chl=git|svn&chd=t:0.519,169.197&chds=0,169.197&chs=100x125&chco=E09FA0|E05F49&chf=bg,s,fcfcfa&chtt=Log (All)" alt="init benchmarks">
</td>
<td>
<img src="https://chart.googleapis.com/chart?chxt=x&cht=bvs&chl=git|svn&chd=t:0.601,82.843&chds=0,82.843&chs=100x125&chco=E09FA0|E05F49&chf=bg,s,fcfcfa&chtt=Log (File)" alt="init benchmarks">
</td>
<td>
<img src="https://chart.googleapis.com/chart?chxt=x&cht=bvs&chl=git|svn&chd=t:0.896,2.816&chds=0,2.816&chs=100x125&chco=E09FA0|E05F49&chf=bg,s,fcfcfa&chtt=Update" alt="init benchmarks">
</td>
<td>
<img src="https://chart.googleapis.com/chart?chxt=x&cht=bvs&chl=git|svn&chd=t:1.91,3.04&chds=0,3.04&chs=100x125&chco=E09FA0|E05F49&chf=bg,s,fcfcfa&chtt=Blame" alt="init benchmarks">
</td>
<td>
<img src="https://chart.googleapis.com/chart?chxt=x&cht=bvs&chl=git|svn&chd=t:181,132&chds=0,181&chs=100x125&chco=E09FA0|E05F49&chf=bg,s,fcfcfa&chtt=Size" alt="init benchmarks">
</td>
</tr>
</tbody>
</table>
<br>
<a href="https://git-scm.com/about/small-and-fast" data-preview-link>Link</a>
<aside class="notes">
git repositories are fast. Table above shows some comparisons of svn vs git. svn requires a central repository to operate, whereas git is entirely local. This means no network latencies. This also means a few other things, the entire project is on your local machine i.e. EVERYONE that has cloned the repository has the entire history of the project on their machine as well. Distributed backup.
</aside>
</section>
<section data-transition="none">
<h3>Distributed non linear workflows</h3>
<p class="center" style="position: absolute">
Subversion-Style Workflow
<img src="https://git-scm.com/images/about/[email protected]" style="max-height: 10em;" alt="Workflow A">
<br>
<a href="https://git-scm.com/about/distributed" data-preview-link>Link</a>
</p>
<aside class="notes">
git allows you to use it the way you want. You can use it exactly like how you would svn.
</aside>
</section>
<section data-transition="none">
<h3>Distributed non linear workflows</h3>
<p class="center" style="position: absolute">
Integration Manager Workflow
<img src="https://git-scm.com/images/about/[email protected]" style="max-height: 10em;" alt="Workflow B">
<br>
<a href="https://git-scm.com/about/distributed" data-preview-link>Link</a>
</p>
<aside class="notes">
git also allows you to pick and compile specific changes from anyone else that has made their repository public
</aside>
</section>
<section data-transition="none">
<h3>Distributed non linear workflows</h3>
<p class="center" style="position: absolute">
Dictator and Lieutenants Workflow
<img src="https://git-scm.com/images/about/[email protected]" style="max-height: 10em;" alt="Workflow C">
<br>
<a href="https://git-scm.com/about/distributed" data-preview-link>Link</a>
</p>
<aside class="notes">
Workflow followed by Linux devs, where Linus has a repository on his local machine that no one else has access to.
</aside>
</section>
<section id="section-2" class="slide level2">
<h1></h1>
<ul>
<li>git is not GitHub</li>
<li>git is not Dropbox</li>
<li>git is not svn</li>
</ul>
<aside class="notes">
git is different from GitHub. GitHub a web service that host a public free remote copy of your repository. git is the toolkit that builds the repository. They are not the same, and there are loads of other places you can store your code remotely - gitlab, bitbucket etc. Why, you can even set up a computer in your home to act as a remote git server.
git is not Dropbox, and although it can be used for sharing word documents and pdfs, this may not be such a good idea - this will not scale well. git works best for text files.
</aside>
</section>
<section id="cvs" class="slide level2">
<h3>CVS</h3>
<figure>
<img src="https://git-scm.com/book/en/v2/book/01-introduction/images/deltas.png" style="max-height: 10em;" alt="" />
</figure>
<aside class="notes">
SVN stores differences in the form of deltas.
</aside>
</section>
<section id="git" class="slide level2">
<h3>Git</h3>
<figure>
<img src="https://git-scm.com/book/en/v2/book/01-introduction/images/snapshots.png" style="max-height: 10em;" alt="" />
</figure>
<aside class="notes">
git however, stores snapshots. People often assume that git stores the differences between files, but that is not true. git tracks content and not files. The way git wins, is by reusing the same "blob" in different snapshots if the file has not changed.
</aside>
</section>
</section>
<section>
<section id="a-brief-history-of-git" class="titleslide slide level1" data-transition="slide">
<h1>A brief history of Git</h1>
</section>
<section id="section-1" class="slide level2">
<ul>
<li><code>git</code> is British English slang for "unpleasant person".</li>
<p style="text-indent: 2em;"> - Linus Torvalds likes to name projects after himself</p>
</ul>
</section>
<section id="section" class="slide level2">
<p class="center">
The Parable by Tom Preston-Werner (Founder of GitHub)
<br>
<img src="img/git-parable.png" alt="The Git Parable">
<br>
<a href="http://tom.preston-werner.com/2009/05/19/the-git-parable.html" data-preview-link>Link</a>
</p>
<aside class="notes">
This article goes through the steps one may attempt to create a version control system. In this hypothetical scenario one may start off by creating multiple folders as a backup. The final VCS that is arrived at is very similar to git. The author is the founder of GitHub
</aside>
</section>
<section class="slide level2">
<p class="center">
<code>git blame README</code>
<img src="img/git-readme.png" style="max-height: 15em;" alt="git readme">
<br>
<a href="https://github.com/git/git/blame/master/README" data-preview-link>Link</a>
</p>
</section>
<section class="slide level2">
<p class="center">
<img src="img/git-2005-article.png" style="max-height: 15em;" alt="Article on Git in 2005">
<br>
<a href="http://www.pcworld.idg.com.au/article/129776/after_controversy_torvalds_begins_work_git_/" data-preview-link>Link</a>
</p>
<aside class="notes">
Linus on why he created git
</aside>
</section>
</section>
</div>
</div>
<script src="reveal.js/lib/js/head.min.js"></script>
<script src="reveal.js/js/reveal.js"></script>
<script src="js/data.js"></script>
<script src="js/data0.js"></script>
<script src="js/updatedisplay.js"></script>
<script src="js/updatedisplay0.js"></script>
</body>
</html>