forked from schacon/whygitisbetter
/
index.html
857 lines (731 loc) · 32.3 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
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
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>
<title>Why Git is Better Than X</title>
<link rel="stylesheet" href="blueprint/screen.css" type="text/css" media="screen, projection" />
<link rel="stylesheet" href="blueprint/print.css" type="text/css" media="print" />
<!--[if IE]><link rel="stylesheet" href="blueprint/ie.css" type="text/css" media="screen, projection"><![endif]-->
<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.2.6/jquery.min.js" type="text/javascript"></script>
<style type="text/css">
html { overflow-y: scroll; }
body { margin-top: 1.5em; }
.header h1 { font-size: 3.5em; color: #666; }
.expand_collapse_links { text-align: center; margin-bottom: 1.5em; display: none; }
.expand_collapse_links a { color: #555; }
img { margin-bottom: 10px; }
.center { text-align: center; }
.text, p { font-size: 1.2em; margin-bottom: 10px; text-align: justify;}
.intro { color: #444; }
ul li { margin-top: 10px; }
.section h2 { padding-left: 5px; background-color: #eee; cursor: pointer;}
.section h2 a { color: #333; text-decoration:none; display: block; }
.section { padding-bottom: 2px; }
.contents { padding: 0 10px; width: 610px; }
.args { float:right; }
.lang { padding: 3px; font-weight: bold;}
.section .lang { font-size: 0.8em; padding: 2px; font-weight: normal;}
.svn { color: hsl(260,57%,24%); background: hsl(260,57%,83%) }
.perforce { color: hsl(0,57%,24%); background: hsl(0,57%,83%) }
.bzr { color: hsl(60,57%,24%); background: hsl(60,57%,83%) }
.hg { color: hsl(190,57%,24%); background: hsl(190,57%,83%) }
.nowrap { white-space: nowrap; }
.sweet { color: #363; background: #beb; }
.compare { color: #663; background: #eeb; }
.help pre { font-size: 12px; }
.help td { vertical-align: top; }
code { font-size: 90%; }
.footer { text-align: center; color: #663; background-color: #eea; padding: 10px;}
.footer a { color: #440; }
.footer-lang { text-align: center; color: #443; background-color: #dda; padding: 5px; font-size: 90%; }
.footer-lang a { color: #330; }
.footer-badges { text-align: center; }
.footer-badges a { color: #777; }
.lang a {color: inherit; text-decoration: none;}
.note { text-decoration: italic; color: #666; padding: 1em; }
</style>
</head>
<body>
<div class="container">
<div class="span-24 header">
<table width="100%">
<tr><td>
<h1>Why Git is Better than X</h1>
</td><td align="right">
<div id="menu">
<span class="lang hg">hg</span>
<span class="lang bzr">bzr</span>
<span class="lang svn">svn</span>
<span class="lang perforce">perforce</span>
</div>
<img style="float: right" alt="where "x" is one of" src="images/wherex.gif" />
</td></tr>
</table>
</div>
<div class="span-24">
<div class="text intro">
This site is here because I seem to
be spending a lot of time lately defending Gitsters against
charges of fanboyism, bandwagonism
and koolaid-thirst. So, here is why people are switching to Git from
X, and why you should too. Just click on a reason to view it.
</div>
<div class="expand_collapse_links">
<a href="#" class="expand_all">Expand all</a> |
<a href="#" class="collapse_all">Collapse all</a>
</div>
</div>
<div class="span-24 section">
<div class="args">
<span class="lang hg">hg</span>
<span class="lang bzr">bzr</span>
<span class="lang svn">svn</span>
<span class="lang perforce">perforce</span>
</div>
<h2>
<a name="cheap-local-branching" href="#cheap-local-branching">Cheap Local Branching</a>
</h2>
<div class="contents">
<div class="text">
Probably Git's most compelling feature that really makes it stand
apart from nearly every other SCM out there is its branching
model. It is completely different from all of the models I'm
comparing it to here, most of which recommend that the best branch
is basically a clone of the repository in a new directory.
</div>
<div class="text">
Git does not work like that. Git will allow you to have multiple
local branches that can be entirely independent of each other and
the creation, merging and deletion of those lines of development
take seconds.
</div>
<div class="text">
This means that you can do things like:
<ul>
<li>Create a branch to try out an idea, commit
a few times, switch back to where you branched from, apply a patch,
switch back to where you are experimenting, then merge it in.
</li>
<li>Have a branch that always contains only what goes to production,
another that you merge work into for testing and several smaller
ones for day to day work
</li>
<li>Create new branches for each new feature you're working on, so
you can seamlessly switch back and forth between them, then delete
each branch when that feature gets merged into your main line.
</li>
<li>Create a branch to experiment in, realize it's not going to
work and just delete it, abandoning the work—with nobody else
ever seeing it (even if you've pushed other branches in the meantime)
</li>
</ul>
</div>
<img src="images/branches.png" alt="branches flowchart"/>
<div class="text">
Importantly, when you push to a remote repository, you do <em>not</em>
have to push all of your branches. You can only share one of your
branches and not all of them. This tends to free people to try
new ideas without worrying about having to plan how and when they
are going to merge it in or share it with others.
</div>
<div class="text">
You <em>can</em> find ways to do some of this with other systems, but the work
involved is much more difficult and error-prone. Git makes this
process incredibly easy and it changes the way most developers
work when they learn it.
</div>
<!-- TODO : (short screencast showing the awesomeness of git branches) -->
<!-- TODO : (show tweets somehow) -->
<div class="tweets">
<img alt='jamis twitter' width="300" src="http://twictur.es/i/1022811017.gif" />
<img alt='trevorturk twitter' width="300" src="http://twictur.es/i/1022886570.gif" />
<img alt='thillerson twitter' width="300" src="http://twictur.es/i/1022842917.gif" />
<img alt='boblmartens twitter' width="300" src="http://twictur.es/i/1022818467.gif" />
<img alt='mathie twitter' width="300" src="http://twictur.es/i/1022816942.gif" />
</div>
</div>
</div>
<div class="span-24 section">
<div class="args">
<span class="lang svn">svn</span>
<span class="lang perforce">perforce</span>
</div>
<h2>
<a name="everything-is-local" href="#everything-is-local">Everything is Local</a>
</h2>
<div class="contents">
<div class="text">
This is basically true of all the distributed SCMs, but in my
experience even more so with Git. There is very little outside
of 'fetch', 'pull' and 'push' that communicates in any way with
anything other than your hard disk.
</div>
<div class="text">
This not only makes most operations much faster than you may
be used to, but it also allows you to work on stuff offline.
That may not sound like a big deal, but I'm always amazed at
how often I actually do work offline. Being able to branch,
merge, commit and browse history of your project while on
the plane or train is very productive.
</div>
<div class="center"><img style="width: 500px" src="images/local-remote.png" alt="local repo to remote repo flowchart" /></div>
<div class="text">
Even in Mercurial, common commands like 'incoming' and 'outgoing' hit
the server, whereas with Git you can 'fetch' all the servers data
before going offline and do comparisons, merges and logs of data
that is on the server but not in your local branches yet.
</div>
<div class="text">
This means that it's very easy to have copies of not only your
branches, but also of everyone's branches that are working with
you in your Git repository without having to mess your own stuff
up.
</div>
</div>
</div>
<div class="span-24 section">
<div class="args">
<span class="lang bzr">bzr</span>
<span class="lang svn">svn</span>
<span class="lang perforce">perforce</span>
</div>
<h2>
<a name="git-is-fast" href="#git-is-fast">Git is Fast</a>
</h2>
<div class="contents">
<div class="text">
Git is fast. Everyone—even most of the hard core users of these
other systems—generally give Git this title. With Git, all
operations are performed locally giving it a bit of a leg up on
SVN and Perforce, both of which require network access for certain operations.
However, even compared to the other DSCMs that also perform operations
locally, Git is pretty fast.
</div>
<div class="text">
Part of this is likely because it was built to work on the Linux
kernel, which means that it has had to deal effectively with large
repositories from day one. Additionally, Git is written in C, reducing the
overhead of runtimes associated with higher-level languages.
Another reason that Git is so fast is that the primary developers
have made this a design goal of the application.
</div>
<div class="text">
The following are a number of benchmarks that I performed on three
copies of the Django source code repository in 3 different SCMs:
Git, Mercurial and Bazaar. I also tested some of this stuff in SVN,
but trust me, it's slower—basically take the Bazaar numbers and
then add network latency...
</div>
<table>
<tr><td class="nowrap">
<img src="http://chart.apis.google.com/chart?cht=bvs&chs=100x125&chd=t:2,5,60&chds=0,60&chxt=x&chco=4d89f9&chl=git|hg|bzr&chtt=Init" alt="init benchmarks" />
<img src="http://chart.apis.google.com/chart?cht=bvs&chs=100x125&chd=t:85,3,23&chds=0,100&chxt=x&chco=4d89f9&chl=git|hg|bzr&chtt=Add" alt="add benchmarks" />
<img src="http://chart.apis.google.com/chart?cht=bvs&chs=100x125&chd=t:45,194,1474&chds=0,1474&chxt=x&chco=4d89f9&chl=git|hg|bzr&chtt=Status" alt="status benchmarks" />
<img src="http://chart.apis.google.com/chart?cht=bvs&chs=100x125&chd=t:5,21,142&chds=0,142&chxt=x&chco=4d89f9&chl=git|hg|bzr&chtt=Diff" alt="diff benchmarks" />
</td><td rowspan="2">
<img src="http://chart.apis.google.com/chart?cht=bvg&chs=190x275&chd=t:1,123,390|11,946,820&chds=0,1210&chxt=x&chco=4d89f9,c6d9fd&chl=git|hg|bzr&chtt=Branching" alt="branching benchmarks" />
</td></tr>
<tr><td class="nowrap">
<img src="http://chart.apis.google.com/chart?cht=bvs&chs=100x125&chd=t:5,120,189&chds=0,230&chxt=x&chco=4d89f9&chl=git|hg|bzr&chtt=Tag" alt="tag benchmarks" />
<img src="http://chart.apis.google.com/chart?cht=bvs&chs=100x125&chd=t:7,26,90&chds=0,90&chxt=x&chco=4d89f9&chl=git|hg|bzr&chtt=Log" alt="log benchmarks" />
<img src="http://chart.apis.google.com/chart?cht=bvs&chs=100x125&chd=t:124,125,230&chds=0,230&chxt=x&chco=4d89f9&chl=git|hg|bzr&chtt=Commit+(Lg)" alt="large commit benchmarks" />
<img src="http://chart.apis.google.com/chart?cht=bvs&chs=100x125&chd=t:8,51,113&chds=0,113&chxt=x&chco=4d89f9&chl=git|hg|bzr&chtt=Commit+(Sm)" alt="small commit benchmarks" />
</td></tr>
</table>
<div class="text">
The end result was that for everything but adding new files, Git
was fastest. (Also really large commits, which Hg was basically the
same at, but the commit I tested was so large that you're unlikely
to ever do anything like it—normal commits are much faster in Git.)
</div>
<table>
<tr>
<th></th>
<th>Git</th>
<th>Hg</th>
<th>Bzr</th>
</tr>
<tr>
<th>Init</th>
<td class="sweet">0.024s</td>
<td>0.059s</td>
<td>0.600s</td>
</tr>
<tr>
<th>Add</th>
<td>8.535s</td>
<td class="sweet">0.368s</td>
<td>2.381s</td>
</tr>
<tr>
<th>Status</th>
<td class="sweet">0.451s</td>
<td>1.946s</td>
<td>14.744s</td>
</tr>
<tr>
<th>Diff</th>
<td class="sweet">0.543s</td>
<td>2.189s</td>
<td>14.248s</td>
</tr>
<tr>
<th>Tag</th>
<td class="sweet">0.056s</td>
<td>1.201s</td>
<td>1.892s</td>
</tr>
<tr>
<th>Log</th>
<td class="sweet">0.711s</td>
<td>2.650s</td>
<td>9.055s</td>
</tr>
<tr>
<th>Commit (Large)</th>
<td class="sweet">12.480s</td>
<td>12.500s</td>
<td>23.002s</td>
</tr>
<tr>
<th>Commit (Small)</th>
<td class="sweet">0.086s</td>
<td>0.517s</td>
<td>1.139s</td>
</tr>
<tr>
<th>Branch (Cold)</th>
<td class="sweet">1.161s</td>
<td>94.681s</td>
<td>82.249s</td>
</tr>
<tr>
<th>Branch (Hot)</th>
<td class="sweet">0.070s</td>
<td>12.300s</td>
<td>39.411s</td>
</tr>
</table>
<div class="text">
The cold and hot branching numbers are the numbers for the first
and second times that I branched a repo—the second number being
a branch with a hot disk cache.
</div>
<div class="text">
It should be noted that although the 'add' numbers are much slower,
this was for a massive add operation—over 2000 files. For the
majority of what most people do on a daily basis, add ops in any
of these systems will only take a fraction of a second. All of the
other ops tested here (except for the large commit, possibly) are
more indicative of things you might actually do day to day.
</div>
<div class="text">
These numbers are really not difficult to recreate, simply clone the Django
project in each of the systems and try out the same commands in each.
<ul>
<li><code>git clone git://github.com/brosner/django.git dj-git</code></li>
<li><code>hg clone http://hg.dpaste.com/django/trunk dj-hg</code></li>
<li><code>bzr branch lp:django dj-bzr</code></li>
<li><code>svn checkout http://code.djangoproject.com/svn/django/trunk dj-svn</code></li>
</ul>
</div>
</div>
</div>
<div class="span-24 section">
<div class="args">
<span class="lang svn">svn</span>
</div>
<h2>
<a name="git-is-small" href="#git-is-small">Git is Small</a>
</h2>
<div class="contents">
<div class="text">
Git is really good at conserving disk space. Your Git directory will
(in general) barely be larger than an SVN checkout—in some cases
actually smaller (apparently a lot can go in those .svn dirs).
</div>
<div class="text">
The following numbers were taken from clones of the Django project
in each of its semi-official Git mirrors at the same point in
its history.
</div>
<table>
<tr>
<th></th>
<th>Git</th>
<th>Hg</th>
<th>Bzr</th>
<th>SVN</th>
</tr>
<tr>
<td>Repo Alone</td>
<td class="sweet">24M</td>
<td>34M</td>
<td>45M</td>
<td>42M*</td>
</tr>
<tr>
<td>Entire Directory</td>
<td class="compare">43M</td>
<td>53M</td>
<td>64M</td>
<td class="compare">61M</td>
</tr>
</table>
<div class="text">
*The repository size for SVN was inferred based on the common source
size of 19M for all other repositories. Assuming the source code will
be the same size from the SVN repository, we find that 61-19=42.
</div>
</div>
</div>
<div class="span-24 section">
<div class="args">
<span class="lang hg">hg</span>
<span class="lang bzr">bzr</span>
<span class="lang svn">svn</span>
<span class="lang perforce">perforce</span>
</div>
<h2>
<a name="the-staging-area" href="#the-staging-area">The Staging Area</a>
</h2>
<div class="contents">
<div class="text">
Unlike the other systems, Git has what it calls the "staging area"
or "index". This is an intermediate area that you can setup what
you want your commit to look like before you commit it.
</div>
<div class="text">
The cool thing about the staging area, and what sets Git apart
from all these other tools, is that you can easily stage some of
your files as you finish them and then commit them without committing
all the modified files in your working directory, or having to list
them on the command line during the commit
</div>
<div class="center"><img src="images/index1.png" alt="add commit workflow diagram" /></div>
<div class="text">
This also allows you to stage only portions of a modified file. Gone are
the days of making two logically unrelated modifications to a file before
you realized that you forgot to commit one of them. Now you can just stage
the change you need for the current commit and stage the other change for
the next commit. This feature scales up to as many different changes to
your file as you need.
</div>
<div class="text">
Of course, Git also makes it pretty easy to ignore this feature
if you don't want that kind of control—just slap a '-a' to your
commit command in order to add all changes to all files to the staging area.
</div>
<div class="center"><img src="images/index2.png" alt="commit only workflow diagram" /></div>
</div>
</div>
<div class="span-24 section">
<div class="args">
<span class="lang svn">svn</span>
<span class="lang perforce">perforce</span>
</div>
<h2>
<a name="distributed" href="#distributed">Distributed</a>
</h2>
<div class="contents">
<div class="text">
One of the coolest features of any of the Distributed SCMs, Git included, is that it's
distributed. This means that instead of doing a "checkout" of the current tip of
the source code, you do a "clone" of the entire repository.
</div>
<div class="text">
This means that even
if you're using a centralized workflow, every user has what is essentially a full
backup of the main server, each of which could be pushed up to replace the main server
in the event of a crash or corruption. There is basically no single point of failure
with Git unless there is only a single point.
</div>
<div class="text">
This does not slow things down much, either. On average, an SVN checkout is only marginally
faster than any of the DSCMs. Of the DSCMs I tested, Git was the fastest.
</div>
<table>
<tr><td>
<img src="http://chart.apis.google.com/chart?cht=bvs&chs=200x150&chd=t:120,144,311,64&chds=0,320&chco=4d89f9&chl=git|hg|bzr|svn&chtt=Clone" alt="cloning benchmarks" />
</td><td style="width: 80%">
<table>
<tr>
<th>Git</th>
<td class="sweet">1m 59s</td>
</tr>
<tr>
<th>Hg</th>
<td>2m 24s</td>
</tr>
<tr>
<th>Bzr</th>
<td>5m 11s</td>
</tr>
<tr>
<th>SVN</th>
<td>1m 4s</td>
</tr>
</table>
</td></tr>
</table>
</div>
</div>
<div class="span-24 section">
<div class="args">
<span class="lang svn">svn</span>
<span class="lang perforce">perforce</span>
</div>
<h2>
<a name="any-workflow" href="#any-workflow">Any Workflow</a>
</h2>
<div class="contents">
<div class="text">
One of the amazing things about Git is that because of its distributed
nature and super branching system, you can easily implement pretty
much any workflow you can think of relatively easily.
</div>
<h3>Subversion-Style Workflow</h3>
<div class="text">
A very common Git workflow, especially from people transitioning
from a centralized system, is a centralized workflow. Git will
not allow you to push if someone has pushed since the last time
you fetched, so a centralized model where all developers push to
the same server works just fine.
</div>
<div class="center"><img src="images/workflow-a.png" alt="subversion-style workflow" /></div><br/>
<h3>Integration Manager Workflow</h3>
<div class="text">
Another common Git workflow is where there is an integration
manager—a single person who commits to the 'blessed' repository,
and then a number of developers who clone from that repository,
push to their own independent repositories and ask the integrator
to pull in their changes. This is the type of development model
you often see with open source or GitHub repositories.
</div>
<div class="center"><img src="images/workflow-b.png" alt="integration manager workflow" /></div><br/>
<h3>Dictator and Lieutenants Workflow</h3>
<div class="text">
For more massive projects, you can setup your developers similar to
the way the Linux kernel is run, where people are in charge of a
specific subsystem of the project ('lieutenants') and merge in all
changes that have to do with that subsystem. Then another integrator
(the 'dictator') can pull changes from only his/her lieutenants and
push those to the 'blessed' repository that everyone then clones from
again.
</div>
<div class="center"><img src="images/workflow-c.png" alt="dictator and lieutenants workflow" /></div><br/>
<div class="text">
Again, Git is entirely flexible about this, so you can mix and
match and choose the workflow that is right for you.
</div>
</div>
</div>
<div class="span-24 section">
<div class="args">
<span class="lang hg">hg</span>
<span class="lang svn">svn</span>
<span class="lang perforce">perforce</span>
</div>
<h2>
<a name="github" href="#github">GitHub</a>
</h2>
<div class="contents">
<img style="float:right; padding:10px" src="images/octocat.png" alt="octocat" />
<div class="text">
I <em>may</em> be biased here, given that I work for
<a href="http://github.com">GitHub</a>,
but I added this section anyway because so many people say that
GitHub itself was specifically why they chose Git.
</div>
<div class="text">
GitHub is a reason to use Git for many people because it is more
like a social network for code than a simple hosting site. People
find other developers or projects that are similar to the things
they are doing, and can easily fork and contribute, creating a very
vibrant community around Git and the projects that people use it
for.
</div>
<div class="text">
There exist other services, both for Git and for the other SCMs,
but few are user-oriented or socially
targeted, and none have anywhere near the user-base.
This social aspect of GitHub is killer, and this in combination of the above features
make working with Git and GitHub a great combination for rapidly
developing open source projects.
</div>
<div class="text">
This type of community is simply not available with any of the other SCMs.
</div>
</div>
</div>
<!--
OTHER IDEAS:
* easy merging
* easy server setup
* non destructive
-->
<!-- GIT MYTHS -->
<div class="span-24 section">
<div class="args">
<span class="lang perforce">perforce</span>
</div>
<h2>
<a name="easy-to-learn" href="#easy-to-learn">Easy to Learn</a>
</h2>
<div class="contents">
<div class="text">
This did not used to be true—early in Git's life, it was not really
an SCM so much as a bunch of tools that let you do versioned filesystem
work in a distributed manner. However, today, the command set and
learning curve of Git are pretty similar to any other SCM, and even
better than some.
</div>
<div class="text">
Since this is difficult to prove objectively without some sort of
study, I'll just show the difference between the default 'help' menu for the
Mercurial and Git commands. I've highlighted the commands that are
identical (or nearly) between the two systems. (In Hg, if you type 'hg help', you
get a list of 40-some commands.)
</div>
<table class="help">
<tr><td valign="top">
<h3>Mercurial Help</h3>
<pre>
<span class="compare">add</span> add the specified files ...
<span class="compare">annotate</span> show changeset informati...
<span class="compare">clone</span> make a copy of an existi...
<span class="compare">commit</span> commit the specified fil...
<span class="compare">diff</span> diff repository (or sele...
export dump the header and diff...
<span class="compare">init</span> create a new repository ...
<span class="compare">log</span> show revision history of...
<span class="compare">merge</span> merge working directory ...
parents show the parents of the ...
<span class="compare">pull</span> pull changes from the sp...
<span class="compare">push</span> push changes to the spec...
<span class="compare">remove</span> remove the specified fil...
serve export the repository vi...
<span class="compare">status</span> show changed files in th...
update update working directory
</pre>
</td><td valign="top">
<h3>Git Help</h3>
<pre>
<span class="compare">add</span> Add file contents to the index
<span class="compare">bisect</span> Find the change that introduce...
<span class="compare">branch</span> List, create, or delete branches
checkout Checkout a branch or paths to ...
<span class="compare">clone</span> Clone a repository into a new ...
<span class="compare">commit</span> Record changes to the repository
<span class="compare">diff</span> Show changes between commits, ...
fetch Download objects and refs from...
grep Print lines matching a pattern
<span class="compare">init</span> Create an empty git repository
<span class="compare">log</span> Show commit logs
<span class="compare">merge</span> Join two or more development h...
mv Move or rename a file, a direc...
<span class="compare">pull</span> Fetch from and merge with anot...
<span class="compare">push</span> Update remote refs along with ...
rebase Forward-port local commits to ...
reset Reset current HEAD to the spec...
<span class="compare">rm</span> Remove files from the working ...
show Show various types of objects
<span class="compare">status</span> Show the working tree status
<span class="compare">tag</span> Create, list, delete or verify...
</pre>
</td></tr>
</table>
<div class="text">
Prior to Git 1.6, all of the Git commands used to be in the executable
path, which was very confusing to people. Although Git still recognizes
all of those commands, the only command in the path is now 'git'.
So, if you look at Mercurial and Git, Git has a nearly identical
command set and help system—there is very little difference from
a beginning UI perspective today.
</div>
<div class="text">
These days it's pretty hard to argue that Mercurial or Bazaar is any
easier to learn than Git is.
</div>
</div>
</div>
<!--
THINGS GIT IS STILL NOT GOOD AT
* windows (all)
* large files (svn)
-->
<div class="span-24">
<div class="expand_collapse_links">
<a href="#" class="expand_all">Expand all</a> |
<a href="#" class="collapse_all">Collapse all</a>
</div>
</div>
<div class="span-24 footer">
This site is built and maintained by <a href="http://github.com/schacon">Scott Chacon</a>, a
<a href="http://github.com">GitHubber</a>.<br />
If you disagree with anything on the site and you have a good reason, please
<a href="mailto:schacon@gmail.com">email me</a> so I can fix it.<br />
The source for this site is <a href="http://github.com/schacon/whygitisbetter">on GitHub</a>—feel
free to send patches if you want to improve it. <br/>
</div>
<div class="span-24 footer-lang">
Also in :
<a href="http://de.whygitisbetterthanx.com">German</a>,
<a href="http://es.whygitisbetterthanx.com">Spanish</a>,
<a href="http://fr.whygitisbetterthanx.com">French</a>,
<a href="http://it.whygitisbetterthanx.com">Italian</a>,
<a href="http://lol.whygitisbetterthanx.com">Lolcat</a>,
<a href="http://nl.whygitisbetterthanx.com">Dutch</a>,
<a href="http://no.whygitisbetterthanx.com">Norwegian</a>,
<a href="http://pt.whygitisbetterthanx.com">Portuguese</a>,
<a href="http://sv.whygitisbetterthanx.com">Swedish</a>,
<a href="http://zh-cn.whygitisbetterthanx.com">Simplified</a> and
<a href="http://zh-tw.whygitisbetterthanx.com">Traditional Chinese</a>
</div>
<div class="span-24 footer-badges">
<a href="http://validator.w3.org/check?uri=referer">Valid XHTML</a>
</div>
</div>
<script type="text/javascript">
$(function() {
$('.section .contents').hide()
$('.contents .tweets').hide()
$('.expand_collapse_links').show()
$('.expand_collapse_links .expand_all').click(function() {
$('.section .contents').show()
})
$('.expand_collapse_links .collapse_all').click(function() {
$('.section .contents').hide()
})
$('.section h2').click(function() {
var hidden = $(this).next().is(':hidden')
$(this).next().slideToggle()
return hidden
})
$('#menu span').css('cursor', 'pointer').click(function() {
$('.section .contents').hide()
showSectionsForSCM(this.innerHTML)
document.location.hash = this.innerHTML
})
if (document.location.hash) {
var anchor = document.location.hash.substring(1)
$('.section h2 a[name=' + anchor + ']').parent('h2').click()
showSectionsForSCM(anchor)
}
function showSectionsForSCM(scm) {
$('.section .' + scm).parents('.section').find('.contents').show()
}
})
</script>
<script type="text/javascript">
var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");
document.write(unescape("%3Cscript src='" + gaJsHost + "google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E"));
</script>
<script type="text/javascript">
try {
var pageTracker = _gat._getTracker("UA-82337-13");
pageTracker._trackPageview();
} catch(err) {}</script>
</body>
</html>