diff --git a/index.html b/index.html index 12d19aa..fa88ce8 100644 --- a/index.html +++ b/index.html @@ -6,13 +6,13 @@ Why Git is Better Than X - + - + - + @@ -75,12 +75,12 @@

Why Git is Better than X

This site is here because I seem to - be spending a lot of time lately defending Gitsters against + 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.
- +
Expand all | Collapse all @@ -99,28 +99,28 @@

Cheap Local Branching

- +
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 + 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.
- +
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.
- - + +
This means that you can do things like:
  • Create a branch to try out an idea, commit - a few times, switch back to where you branched from, apply a patch, + a few times, switch back to where you branched from, apply a patch, switch back to where you are experimenting, then merge it in.
  • Have a branch that always contains only what goes to production, @@ -137,9 +137,9 @@

- + branches flowchart - +
Importantly, when you push to a remote repository, you do not have to push all of your branches. You can only share one of your @@ -147,14 +147,14 @@

new ideas without worrying about having to plan how and when they are going to merge it in or share it with others.

- +
You can 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.
- + @@ -167,7 +167,7 @@

- +
svn @@ -176,12 +176,12 @@

Everything is Local

-
+
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 + of 'fetch', 'pull' and 'push' that communicates in any way with anything other than your hard disk.
@@ -190,40 +190,40 @@

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 + merge, commit and browse history of your project while on the plane or train is very productive.

- +
local repo to remote repo flowchart
- Even in Mercurial, common commands like 'incoming' and 'outgoing' hit + 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.
- +
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.
- +
- +
bzr svn perforce
- +

Git is Fast

- +
Git is fast. Everyone—even most of the hard core users of these @@ -231,11 +231,11 @@

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. + locally, Git is pretty fast.

- +
- Part of this is likely because it was built to work on the Linux + 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. @@ -251,14 +251,14 @@

then add network latency...

- +
init benchmarks add benchmarks status benchmarks - + diff benchmarks branching benchmarks @@ -273,14 +273,14 @@

small commit benchmarks

- +
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.)
- + @@ -349,7 +349,7 @@

39.411s
- +
The cold and hot branching numbers are the numbers for the first and second times that I branched a repo—the second number being @@ -364,8 +364,8 @@

other ops tested here (except for the large commit, possibly) are more indicative of things you might actually do day to day.

- - + +
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. @@ -376,34 +376,34 @@

  • svn checkout http://code.djangoproject.com/svn/django/trunk dj-svn

    • - +
    - - + +
    - +
    svn
    - +

    Git is Small

    - +
    - Git is really good at conserving disk space. Your Git directory will + 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).
    - +
    The following numbers were taken from clones of the Django project - in each of its semi-official Git mirrors at the same point in + in each of its semi-official mirrors at the same point in its history.
    - + @@ -427,7 +427,7 @@

    61M
    - +
    @@ -438,7 +438,7 @@

    svn perforce

    - +

    The Staging Area

    @@ -449,14 +449,14 @@

    you want your commit to look like before you commit it.
    - The cool thing about the staging area, and what sets Git apart + 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
    add commit workflow diagram
    - +
    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 @@ -471,7 +471,7 @@

    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.

    - +
    commit only workflow diagram
    @@ -490,11 +490,11 @@

    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 + 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.
    - This means that even + 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 @@ -530,50 +530,50 @@

    - +

    - - + +
    svn perforce
    - +

    Any Workflow

    - +
    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.
    - +

    Subversion-Style Workflow

    - +
    A very common Git workflow, especially from people transitioning - from a centralized system, is a centralized workflow. Git will + 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.
    - +
    subversion-style workflow

    - +

    Integration Manager Workflow

    - Another common Git workflow is where there is an integration + 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, + 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 + to pull in their changes. This is the type of development model you often see with open source or GitHub repositories.
    @@ -592,16 +592,16 @@

    Dictator and Lieutenants Workflow

    dictator and lieutenants workflow

    - +
    - Again, Git is entirely flexible about this, so you can mix and - match and choose the workflow that is right for you. + Again, Git is entirely flexible about this, so you can mix and + match and choose the workflow that is right for you.
    - +
    - - + +
    hg @@ -612,83 +612,83 @@

    Dictator and Lieutenants Workflow

    GitHub

    - +
    octocat
    - I may be biased here, given that I work for - GitHub, + I may be biased here, given that I work for + GitHub, but I added this section anyway because so many people say that GitHub itself was specifically why they chose Git.
    -
    - GitHub is a reason to use Git for many people because it is more +
    + 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.
    - -
    + +
    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. + 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 + make working with Git and GitHub a great combination for rapidly developing open source projects.
    -
    +
    This type of community is simply not available with any of the other SCMs.
    - - - - + - +
    perforce
    - +

    Easy to Learn

    - +
    -
    - 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 +
    + 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.
    -
    - Since this is difficult to prove objectively without some sort of +
    + 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 + identical (or nearly) between the two systems. (In Hg, if you type 'hg help', you get a list of 40-some commands.)
    - +
    - +

    Mercurial Help

     add        add the specified files ...
@@ -710,7 +710,7 @@ 
    Mercurial Help
    		- +

    Git Help

     add        Add file contents to the index
@@ -734,47 +734,47 @@ 
    Git Help
    
 show       Show various types of objects
 status     Show the working tree status
 tag        Create, list, delete or verify...
-
    +
    - -
    + +
    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 + 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.
    - -
    + +
    These days it's pretty hard to argue that Mercurial or Bazaar is any easier to learn than Git is.
    - +
    - +
    - - - -
    +
    Expand all | Collapse all
    - +
    This site is built and maintained by Scott Chacon, a GitHubber.
    - If you disagree with anything on the site and you have a good reason, please + If you disagree with anything on the site and you have a good reason, please email me so I can fix it.
    The source for this site is on GitHub—feel @@ -782,15 +782,15 @@

    Git Help

    - Also in : - German, - Spanish, - French, - Italian, - Lolcat, - Dutch, - Norwegian, - Portuguese, + Also in : + German, + Spanish, + French, + Italian, + Lolcat, + Dutch, + Norwegian, + Portuguese, Swedish, Simplified and Traditional Chinese @@ -824,7 +824,7 @@

    Git Help

    $('.section .contents').hide() showSectionsForSCM(this.innerHTML) document.location.hash = this.innerHTML - }) + }) if (document.location.hash) { var anchor = document.location.hash.substring(1)